[Pkg-rust-maintainers] Upstream has changed the bootstrap process

[Angus Lees]

So long as we can build from both rustc-1.9 and rebuild the resulting
rustc-1.10 from rustc-1.10 (ie: once rustc-1.9 is replaced in the archive),
then I agree, there's no reason to delay an upload.

You have a bunch of make_orig-dl_tarball changes in your commit - are we
still using a dl tarball at all with this release?

Re bootstrap key: yes, that's the one.  Chasing through where
CFG_BOOTSTRAP_KEY is used in the makefiles, I *think* we can avoid
modifying stage0.txt by using ./configure --enable-local-rebuild if
rebuilding with the same version.  If that doesn't work, we may be able to
just pass CFG_BOOTSTRAP_KEY=e8edd0fd env var to makefiles directly, or
patch the makefiles until one of those works ;)    That key is the same
CFG_FILENAME_EXTRA used on libraries, fwiw.  If we want to calculate it
ourselves, it's: `printf '%s' 1.10.0 | md5sum | cut -c 1-8`

(and thanks again!)
 - Gus

On Sun, 10 Jul 2016 at 08:15 Ximin Luo <infinity0 at debian.org> wrote:

> Ximin Luo:
> > Angus Lees:
> >> Thanks Ximin!  I've been poking at it myself over the last few nights,
> and
> >> got to roughly where you are.  The big outstanding issue for me is
> >> verifying that we can (re)build with the same release, since this will
> >> require a different path into the build system (aiui).  I think I know
> how
> >> this needs to work, but I'm only now at the point where I can actually
> try
> >> it :/
> >
> > I just built 1.10.0 by bootstrapping from 1.9.0. Then I installed this
> 1.10.0 and tried to build the same version again by bootstrapping from
> itself. This is what I got:
> >
> > $ dpkg-buildpackage -b
> > [..]
> >
> CFG_LLVM_LINKAGE_FILE=/media/xda1/data/infinity0/tmp/rust/rebuild/rustc-1.10.0+dfsg1/x86_64-unknown-linux-gnu/rt/
> llvmdeps.rs
> LD_LIBRARY_PATH=/media/xda1/data/infinity0/tmp/rust/rebuild/rustc-1.10.0+dfsg1/x86_64-unknown-linux-gnu/stage0/lib:/usr/lib/llvm-3.7/lib:$LD_LIBRARY_PATH
>  x86_64-unknown-linux-gnu/stage0/bin/rustc --cfg stage0 -C
> link-args=-Wl,-z,relro -O --cfg rtopt -C rpath -C prefer-dynamic -C
> no-stack-check --target=x86_64-unknown-linux-gnu   -L
> "x86_64-unknown-linux-gnu/rt" -L native="/usr/lib/llvm-3.7/lib"
>  --out-dir
> x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib -C
> extra-filename=-e8edd0fd -C metadata=e8edd0fd src/libcore/lib.rs
> > src/libcore/lib.rs:63:1: 63:37 error: #[feature] may not be used on the
> stable release channel
> > src/libcore/lib.rs:63 #![feature(allow_internal_unstable)]
> >                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [..]
> > etc more errors like the above
> > [..]
> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > 2
> >
> > which sounds like the problem I ran into a few emails ago. There is
> something called a "bootstrap key" that lets you "unlock" unstable features
> of a particular compiler, so we would have to do something with this - see
> my earlier email for more details.
> >
>
> OK, I can make the build work again by applying this patch:
>
> --- a/src/stage0.txt
> +++ b/src/stage0.txt
> @@ -12,6 +12,6 @@
>  # tarball for a stable release you'll likely see `1.x.0-$date` where
> `1.x.0` was
>  # released on `$date`
>
> -rustc: 1.9.0-2016-05-24
> -rustc_key: d16b8f0e
> -cargo: nightly-2016-04-10
> +rustc: 1.10.0-2016-07-07
> +rustc_key: e8edd0fd
> +cargo: nightly-0
>
> This seems fairly easy to automate in a generic way in debian/rules, I
> will have a go at it soon. After that, I'd suggest we upload, then figure
> out how to automate the build+testing (that you mentioned) separately.
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
>
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20160711/2b65e836/attachment.html>