Closed Bug 1871132 Opened 1 year ago Closed 1 year ago

MacOSX14.0 SDK fails to download

Categories

(Firefox Build System :: Toolchains, defect)

defect

Tracking

(firefox121 wontfix, firefox122 fixed, firefox123 fixed)

RESOLVED FIXED
123 Branch
Tracking Status
firefox121 --- wontfix
firefox122 --- fixed
firefox123 --- fixed

People

(Reporter: afranchuk, Assigned: glandium)

References

Details

Attachments

(4 files, 2 obsolete files)

When cross-compiling for macos on a linux host, the bootstrapping of the macos SDK fails. Older versions seem to work (though they are below the minimum supported SDK at the time of this writing), but 14.0 fails to download with a 403 Forbidden being returned when the URL in the taskcluster configuration is fetched (https://swcdn.apple.com/content/downloads/48/60/042-46120-A_N66A5VQ6BX/qoleua6b09wgn0qyb8ci301cmwe3q0r8i6/CLTools_macOSNMOS_SDK.pkg).

This prevents the build from working easily, and forces the user to manually get the 14.0 SDK and point to it with --with-macos-sdk.

Component: Bootstrap Configuration → Toolchains

Apple now only provides an older version of the macos SDK 14.0 (from xcode 15.0 beta 7), or SDK 14.2 (from xcode 15.1). Stephen, what do you think?

Flags: needinfo?(spohl.mozilla.bugs)

Is this still the case? The link seems to work for me.

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(afranchuk)

It returns an empty file for me.

Actually, it's an empty 403.

$ curl --head https://swcdn.apple.com/content/downloads/48/60/042-46120-A_N66A5VQ6BX/qoleua6b09wgn0qyb8ci301cmwe3q0r8i6/CLTools_macOSNMOS_SDK.pkg
HTTP/1.1 403 Forbidden
Server: dlb/1.0.2
Date: Fri, 22 Dec 2023 00:01:14 GMT
Content-Type: application/octet-stream
Content-Length: 0
Strict-Transport-Security: max-age=31536000; includeSubDomains;
Via: 17.42.252.35, http/1.1 jptyo5-vp-vst-007.ts.apple.com (acdn/111.14403), https/1.1 jptyo5-vp-vfe-009.ts.apple.com (acdn/111.14403), https/1.1 jptyo5-edge-lx-003.ts.apple.com (acdn/111.14403), https/1.1 jptyo5-edge-bx-010.ts.apple.com (acdn/111.14403), http/1.1 jptyo5-edge-bx-010.ts.apple.com (acdn/111.14403)
Age: 0
X-Cache: miss, miss, miss, miss, none
CDNUUID: 0b358af4-b85a-475e-bdea-a20fc4a01aca-2499754966
Connection: keep-alive
Flags: needinfo?(afranchuk) → needinfo?(spohl.mozilla.bugs)

Oh hmm, it downloads fine from a browser. But curl does indeed return the same thing for me as it does for you.

(In reply to Mike Hommey [:glandium] [OOO Dec 30-Jan 8] from comment #1)

Apple now only provides an older version of the macos SDK 14.0 (from xcode 15.0 beta 7), or SDK 14.2 (from xcode 15.1). Stephen, what do you think?

What's the question exactly? If we should use one of the older versions instead?

Flags: needinfo?(spohl.mozilla.bugs)

it downloads fine from a browser.

It doesn't for me. Usually, that means is that the file is disappearing from the CDN servers, but not all of them have been affected, but eventually, the file will be gone for good.

What's the question exactly? If we should use one of the older versions instead?

Would you prefer we go "back" to a beta SDK, or to upgrade to SDK 14.2?

(In reply to Mike Hommey [:glandium] [OOO Dec 30-Jan 8] from comment #6)

it downloads fine from a browser.

It doesn't for me. Usually, that means is that the file is disappearing from the CDN servers, but not all of them have been affected, but eventually, the file will be gone for good.

Or could it be that they detect these downloads, by user agent for example, and block them? And the problem would continue if we switched to a different SDK once they block the next URL? fwiw, the downloads still work for me in a browser.

What's the question exactly? If we should use one of the older versions instead?

Would you prefer we go "back" to a beta SDK, or to upgrade to SDK 14.2?

An upgrade to the 14.2 SDK seems preferable.

Or could it be that they detect these downloads, by user agent for example, and block them?

I doubt it.

And the problem would continue if we switched to a different SDK once they block the next URL?

The problem will continue, there is no doubt about it.

fwiw, the downloads still work for me in a browser.

fwiw, they don't work for me in any browser, not even safari on a mac.

(In reply to Stephen A Pohl [:spohl] from comment #7)

(In reply to Mike Hommey [:glandium] [OOO Dec 30-Jan 8] from comment #6)
An upgrade to the 14.2 SDK seems preferable.

Let's go with a two-phase thing, so that we get a patch that is upliftable to beta/release:

  • First phase: get the 14.0 SDK on CI and "revert" to the 14.0 beta SDK for local builds
  • Second phase: upgrade central to 14.2 SDK.
Blocks: 1871894

For some reason, in some files, file elements are under file elements.
Python's ElementTree's findall doesn't work like DOM's
getElementsByTagName, and doesn't find them. So manually recurse.

Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED

As the 14.0 SDK is not available on the Apple CDN anymore, I did the
following:

  • downloaded the Command Line Tools for Xcode 15 from
    developer.apple.com (requires an account)
  • extracted the .pkg file that the above .dmg contains
  • uploaded said .pkg to tooltool

The pkg is not equivalent to the pkg that was previously available, but
it does contain the same SDK at the same location, as validated by
comparison of the existing artifact from the macosx64-sdk-14.0 task
to that of the new one.

For local builds, we go back to a beta SDK, which is the closest
publically available SDK.

This patch is mainly aimed at being uplifted to beta/release. Central is
ultimately going to upgrade to 14.2 SDK.

Updating the documentation was left out on purpose, because this is a
one-off.

Blocks: 1871895
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/dfaaf393c911 Recursively find all file elements in xar toc. r=gsvelto https://hg.mozilla.org/integration/autoland/rev/97a27d8a860d Get the mac SDK from tooltool and the closest publically available for local builds. r=firefox-build-system-reviewers,ahochheiden

For some reason, in some files, file elements are under file elements.
Python's ElementTree's findall doesn't work like DOM's
getElementsByTagName, and doesn't find them. So manually recurse.

Original Revision: https://phabricator.services.mozilla.com/D197278

Attachment #9370382 - Flags: approval-mozilla-beta?

As the 14.0 SDK is not available on the Apple CDN anymore, I did the
following:

  • downloaded the Command Line Tools for Xcode 15 from
    developer.apple.com (requires an account)
  • extracted the .pkg file that the above .dmg contains
  • uploaded said .pkg to tooltool

The pkg is not equivalent to the pkg that was previously available, but
it does contain the same SDK at the same location, as validated by
comparison of the existing artifact from the macosx64-sdk-14.0 task
to that of the new one.

For local builds, we go back to a beta SDK, which is the closest
publically available SDK.

This patch is mainly aimed at being uplifted to beta/release. Central is
ultimately going to upgrade to 14.2 SDK.

Updating the documentation was left out on purpose, because this is a
one-off.

Original Revision: https://phabricator.services.mozilla.com/D197279

Attachment #9370383 - Flags: approval-mozilla-beta?

For some reason, in some files, file elements are under file elements.
Python's ElementTree's findall doesn't work like DOM's
getElementsByTagName, and doesn't find them. So manually recurse.

Original Revision: https://phabricator.services.mozilla.com/D197278

Attachment #9370384 - Flags: approval-mozilla-release?

As the 14.0 SDK is not available on the Apple CDN anymore, I did the
following:

  • downloaded the Command Line Tools for Xcode 15 from
    developer.apple.com (requires an account)
  • extracted the .pkg file that the above .dmg contains
  • uploaded said .pkg to tooltool

The pkg is not equivalent to the pkg that was previously available, but
it does contain the same SDK at the same location, as validated by
comparison of the existing artifact from the macosx64-sdk-14.0 task
to that of the new one.

For local builds, we go back to a beta SDK, which is the closest
publically available SDK.

This patch is mainly aimed at being uplifted to beta/release. Central is
ultimately going to upgrade to 14.2 SDK.

Updating the documentation was left out on purpose, because this is a
one-off.

Original Revision: https://phabricator.services.mozilla.com/D197279

Attachment #9370385 - Flags: approval-mozilla-release?

:glandium this needs an uplift request form too for review.
Not sure what steps you followed, but you can add one by selecting Change Uplift Request form from the Action dropdown in the phabrictor revision.

Flags: needinfo?(mh+mozilla)

I used lando for the uplift, and it asked me nothing, which I asked about on #Conduit... thanks for the pointer.

Flags: needinfo?(mh+mozilla)

Uplift Approval Request

  • Explanation of risk level: This makes no practical difference on automation.
  • Steps to reproduce for manual QE testing: N/A
  • Is Android affected?: no
  • Code covered by automated testing: yes
  • Risk associated with taking this patch: None
  • String changes made/needed: N/A
  • Needs manual QE test: no
  • User impact if declined: None
  • Fix verified in Nightly: yes

Uplift Approval Request

  • Steps to reproduce for manual QE testing: N/A
  • Is Android affected?: no
  • Explanation of risk level: This makes no practical difference on automation.
  • User impact if declined: None
  • Fix verified in Nightly: yes
  • Code covered by automated testing: yes
  • Risk associated with taking this patch: None
  • Needs manual QE test: no
  • String changes made/needed: N/A

Uplift Approval Request

  • Explanation of risk level: This makes no practical difference on automation.
  • Steps to reproduce for manual QE testing: N/A
  • Is Android affected?: no
  • Code covered by automated testing: yes
  • Risk associated with taking this patch: None
  • String changes made/needed: N/A
  • Needs manual QE test: no
  • User impact if declined: None
  • Fix verified in Nightly: yes

Uplift Approval Request

  • String changes made/needed: N/A
  • Needs manual QE test: no
  • Code covered by automated testing: yes
  • Risk associated with taking this patch: None
  • Fix verified in Nightly: yes
  • User impact if declined: None
  • Explanation of risk level: This makes no practical difference on automation.
  • Is Android affected?: no
  • Steps to reproduce for manual QE testing: N/A
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch
Attachment #9370382 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9370383 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9370384 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9370385 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9370384 - Flags: approval-mozilla-release+ → approval-mozilla-release?
Attachment #9370385 - Flags: approval-mozilla-release+ → approval-mozilla-release?
Attachment #9370384 - Attachment is obsolete: true
Attachment #9370384 - Flags: approval-mozilla-release? → approval-mozilla-release-
Attachment #9370385 - Attachment is obsolete: true
Attachment #9370385 - Flags: approval-mozilla-release? → approval-mozilla-release-
See Also: → 1887728
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: