MacOSX14.0 SDK fails to download
Categories
(Firefox Build System :: Toolchains, defect)
Tracking
(firefox121 wontfix, firefox122 fixed, firefox123 fixed)
People
(Reporter: afranchuk, Assigned: glandium)
References
Details
Attachments
(4 files, 2 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
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
.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 1•1 year ago
|
||
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?
Comment 2•1 year ago
|
||
Is this still the case? The link seems to work for me.
Assignee | ||
Comment 3•1 year ago
|
||
It returns an empty file for me.
Assignee | ||
Comment 4•1 year ago
|
||
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
Comment 5•1 year ago
|
||
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?
Assignee | ||
Comment 6•1 year ago
|
||
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?
Comment 7•1 year ago
|
||
(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.
Assignee | ||
Comment 8•1 year ago
|
||
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.
Assignee | ||
Comment 9•1 year ago
|
||
(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.
Assignee | ||
Comment 10•1 year ago
|
||
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.
Updated•1 year ago
|
Assignee | ||
Comment 11•1 year ago
|
||
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.
Comment 12•1 year ago
|
||
Assignee | ||
Comment 13•1 year ago
|
||
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
Updated•1 year ago
|
Assignee | ||
Comment 14•1 year ago
|
||
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
Updated•1 year ago
|
Assignee | ||
Comment 15•1 year ago
|
||
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
Updated•1 year ago
|
Assignee | ||
Comment 16•1 year ago
|
||
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
Updated•1 year ago
|
Comment 17•1 year ago
|
||
: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.
Assignee | ||
Comment 18•1 year ago
|
||
I used lando for the uplift, and it asked me nothing, which I asked about on #Conduit... thanks for the pointer.
Comment 19•1 year ago
|
||
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
Comment 20•1 year ago
|
||
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
Comment 21•1 year ago
|
||
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
Comment 22•1 year ago
|
||
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
Comment 23•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/dfaaf393c911
https://hg.mozilla.org/mozilla-central/rev/97a27d8a860d
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 24•1 year ago
|
||
uplift |
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Description
•