Uh oh!
There was an error while loading. Please reload this page.
Generate XZ-compressed tarballs - #41600
Conversation
instead of combining the component and target into a URL.
The same unavailable target value is used in two different places. Abstracting it makes it easier to update it and recognise its purpose.
rust-highfive
commented
Apr 28, 2017
(rust_highfive has picked a reviewer for you, use r? to override) |
I tried to add the required packages to the CI infrastructure, but I am not very confident that everything is in place. I trust the CI itself to warn about such issues. |
ishitatsuyuki
commented
Apr 28, 2017
You can use ALLOW_PR to get rapid feedback; doing it on one of the builders (preferably x86_64-linux-gnu) doesn't jam the queue so much. Make sure you add some sort of WIP tag. |
nikomatsakis
commented
Apr 28, 2017
Who should review this? Not, I think, me. |
nikomatsakis
commented
Apr 28, 2017
r? @alexcrichton -- feel free to pick someone else, I figured you'd know the right person tho |
alexcrichton
left a comment
There was a problem hiding this comment.
Looks excellent to me, thakns @ranma42!
Right now if this gets past bors then we unfortunately don't have many guarantees. It should exercise all xz-producing code but doesn't exercise the manifest generator, that'll happen when the next nightly is built.
You can also run everything locally (at least container-wise) with ./src/ci/docker/run.sh arm-android (etc)
There was a problem hiding this comment.
This doesn't currently validate that the xz file actually exists, could that be done as an extra sanity check?
There was a problem hiding this comment.
self.digests should only contain digests for existing files. Do you expect the file to be deleted between the digest computation and the construction of the manifest?
There was a problem hiding this comment.
Oh good point yeah, but that means that the url could be specified and the digest could be none, right? Could we statically prevent a situation such as that?
There was a problem hiding this comment.
xz_url: xz_digest.as_ref().map(|_| self.url(&xz_filename)) makes sure that the url is only specified if the digest is Something (and that its contents are based on the filename, not on the digest value).
There was a problem hiding this comment.
A bunch of containers don't actually produce tarballs, only the dist-* ones do I believe. Could this package be left out of all the containers (like this one) not producing tarballs?
There was a problem hiding this comment.
Uhm... Actually I might have removed one too many: does the cross image also produce tarballs? Even if it is not dist-*, it is flagged DEPLOY=1.
There was a problem hiding this comment.
Oops yes sorry DEPLOY=1 is the marker to look for.
alexcrichton
commented
Apr 28, 2017
cc @brson |
mattico
commented
Apr 28, 2017
Out of curiosity: why are you using p7zip rather than xz-utils (which is already being installed)? |
ranma42
commented
Apr 28, 2017
@mattico 7z is available on AppVeyor (where it is somewhat harder to install software). See rust-lang/rust-installer#57 (comment) |
alexcrichton
commented
Apr 29, 2017
Ok everything looks great to me @ranma42! Want to squash and remove '[WIP]' and r+? |
ranma42
commented
Apr 29, 2017
Squashed and renamed :) |
alexcrichton
commented
Apr 30, 2017
@bors: r+ |
bors
commented
Apr 30, 2017
📌 Commit 36b9ab7 has been approved by |
bors
commented
Apr 30, 2017
⌛ Testing commit 36b9ab7 with merge 5616298... |
bors
commented
Apr 30, 2017
💔 Test failed - status-travis |
ranma42
commented
Apr 30, 2017
Uh, of course |
alexcrichton
commented
Apr 30, 2017
@bors: r+ |
bors
commented
Apr 30, 2017
📌 Commit bf4082a has been approved by |
bors
commented
May 3, 2017
⌛ Testing commit 6bf71f0 with merge d5948bd... |
bors
commented
May 3, 2017
💔 Test failed - status-travis |
TimNN
commented
May 3, 2017
Looks legitimate: (https://travis-ci.org/rust-lang/rust/jobs/228215768) @bors r- |
MacOSX does not ship `7z` nor `xz`. Let's use `xz`, just like on the other *nix systems.
I must have messed up when squashing the update of the rust-installer submodule, sorry. It should be fixed by my latest push. |
alexcrichton
commented
May 3, 2017
@bors: r+ |
bors
commented
May 3, 2017
📌 Commit 5e522d7 has been approved by |
Generate XZ-compressed tarballs Integrate the new `rust-installer` and extend manifests with keys for xz-compressed tarballs. One of the steps required for rust-lang#21724
bors
commented
May 3, 2017
⌛ Testing commit 5e522d7 with merge 234472d... |
aidanhs
commented
May 3, 2017
Think this caused a rollup failure in #41725 on the osx xcode 7 builders
Can't decipher why from the logs, but both of the osx xcode 7 builders failed, so I suspect it'll fail here as well. |
alexcrichton
commented
May 3, 2017
@aidanhs oddly enough all builders have gotten past the xz installation stage here ... |
alexcrichton
commented
May 3, 2017
alexcrichton
commented
May 3, 2017
@bors: retry |
Wrap the installation on macOS with `travis_retry`.
ranma42
commented
May 3, 2017
I added |
alexcrichton
commented
May 3, 2017
@bors: r+ Yeah I also found that log... interestingly ordered |
bors
commented
May 3, 2017
📌 Commit 98dd82c has been approved by |
Generate XZ-compressed tarballs Integrate the new `rust-installer` and extend manifests with keys for xz-compressed tarballs. One of the steps required for rust-lang#21724
bors
commented
May 4, 2017
As of rust-lang/rust#41600 we now need `xz` to build Rust from HEAD.
Integrate the new
rust-installerand extend manifests with keys for xz-compressed tarballs.One of the steps required for #21724