Debian Bug report logs - #796256
Please consider packaging a Rust version that allows #![feature(...)]

Reply or subscribe to this bug.

Toggle useless messages

Message #3 received at submit@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Please consider packaging a Rust version that allows #![feature(...)]

Date: Thu, 20 Aug 2015 12:59:51 -0700

Package: rustc
Version: 1.2.0+dfsg1-1
Severity: wishlist

Quite a bit of the Cargo ecosystem makes use of #![feature(...)] to
enable unstable features.  Rust release builds prohibit this by default:

/home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/lib.rs:12:1: 12:18 error: #[feature] may not be used on the stable release channel
/home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/lib.rs:12 #![feature(libc)]
                                                                                ^~~~~~~~~~~~~~~~~

Please consider providing a package of rustc that allows these feature-gates.
(That doesn't necessarily have to be a nightly version.)

- Josh Triplett

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rustc depends on:
ii  libc6            2.19-19
ii  libstd-rust-dev  1.2.0+dfsg1-1

Versions of packages rustc recommends:
pn  rust-gdb | rust-lldb  <none>

Versions of packages rustc suggests:
pn  rust-doc  <none>

-- no debconf information

Message #8 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Angus Lees <gus@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 796256@bugs.debian.org

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Fri, 21 Aug 2015 02:29:40 +0000

[Message part 1 (text/plain, inline)]

tags 796256 upstream wontfix
close 796256
thanks

On Fri, 21 Aug 2015 at 06:03 Josh Triplett <josh@joshtriplett.org> wrote:

> Quite a bit of the Cargo ecosystem makes use of #![feature(...)] to
> enable unstable features.  Rust release builds prohibit this by default:
>
>
> /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/lib.rs:12:1:
> 12:18 error: #[feature] may not be used on the stable release channel
> /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/
> lib.rs:12 #![feature(libc)]
>
>       ^~~~~~~~~~~~~~~~~
>
> Please consider providing a package of rustc that allows these
> feature-gates.
> (That doesn't necessarily have to be a nightly version.)
>

Hrm.  I think this means you're asking for a rustc-nightly.deb - or some
other arbitrary periodically updated snapshot of rustc compiled with
--channel=nightly to "unlock" opt-in unstable features.

I can completely understand this desire, but I think this inconvenience is
a completely desired outcome of the "Stability as a Deliverable" Rust
strategy[1].  As a *distribution* I feel like shipping a nightly package
would be directly subverting this strategy and as such I consider this a
wishlist bug against the upstream policy/mechanism.

Personally, I'm reluctant to break the release-channels experiment so close
to the 1.0 release.  We may well declare it failed and do something
different in future, but right now I think Debian has an important role to
play in demonstrating what the "stable" Rust world looks like and providing
pressure for upstreams to avoid unstable features.

I hope you can understand why I'm going to close this upstream+wontfix - at
least for now.  Please feel free to reopen and/or continue the discussion
if you disagree.

[1] http://blog.rust-lang.org/2014/10/30/Stability.html

 - Gus

[Message part 2 (text/html, inline)]

Message #19 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Angus Lees <gus@debian.org>

Cc: 796256@bugs.debian.org

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Fri, 21 Aug 2015 01:33:17 -0700

On Fri, Aug 21, 2015 at 02:29:40AM +0000, Angus Lees wrote:
> On Fri, 21 Aug 2015 at 06:03 Josh Triplett <josh@joshtriplett.org> wrote:
> > Quite a bit of the Cargo ecosystem makes use of #![feature(...)] to
> > enable unstable features.  Rust release builds prohibit this by default:
> >
> >
> > /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/lib.rs:12:1:
> > 12:18 error: #[feature] may not be used on the stable release channel
> > /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/
> > lib.rs:12 #![feature(libc)]
> >
> >       ^~~~~~~~~~~~~~~~~
> >
> > Please consider providing a package of rustc that allows these
> > feature-gates.
> > (That doesn't necessarily have to be a nightly version.)
> >
> 
> Hrm.  I think this means you're asking for a rustc-nightly.deb - or some
> other arbitrary periodically updated snapshot of rustc compiled with
> --channel=nightly to "unlock" opt-in unstable features.
> 
> I can completely understand this desire, but I think this inconvenience is
> a completely desired outcome of the "Stability as a Deliverable" Rust
> strategy[1].  As a *distribution* I feel like shipping a nightly package
> would be directly subverting this strategy and as such I consider this a
> wishlist bug against the upstream policy/mechanism.

I *don't* think such a package should be in the stable distribution.
However, having it in experimental would be wildly useful.  I *really*
don't want to go grab binaries from upstream; I'd much rather install
through Debian.

> Personally, I'm reluctant to break the release-channels experiment so close
> to the 1.0 release.  We may well declare it failed and do something
> different in future, but right now I think Debian has an important role to
> play in demonstrating what the "stable" Rust world looks like and providing
> pressure for upstreams to avoid unstable features.

I don't think this would be breaking release-channels.  Rather, this
would be demonstrating the value of that model.  Debian unstable, and
thus testing and eventually stable, would get stable Rust releases.
Debian experimental would get Rust builds with experimental features
turned on.  Software uploaded to Debian unstable, for instance, would
still have to build with stable Rust.

As a related example, Debian ships Firefox "Extended Support Release"
builds in unstable, which migrate to testing and eventually stable.  But
in experimental, you can get the latest non-ESR release, and sometimes
betas.

> I hope you can understand why I'm going to close this upstream+wontfix - at
> least for now.  Please feel free to reopen and/or continue the discussion
> if you disagree.

I do disagree, as stated above.  I agree completely with Rust's
release-channel model; however, I think it's appropriate to ship
unstable Rust in experimental, and stable Rust in
unstable/testing/stable.

That said, I can completely understand if the Rust team doesn't have the
bandwidth to maintain an extra set of packages.  (Though, using it as a
canary seems like it may help you anticipate future upstream issues.)

- Josh Triplett

Message #26 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 796256@bugs.debian.org, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Sun, 30 Aug 2015 21:42:10 +0200

On 21/08/15 10:33, Josh Triplett wrote:
>> Personally, I'm reluctant to break the release-channels experiment so close
>> to the 1.0 release.  We may well declare it failed and do something
>> different in future, but right now I think Debian has an important role to
>> play in demonstrating what the "stable" Rust world looks like and providing
>> pressure for upstreams to avoid unstable features.
> 
> I don't think this would be breaking release-channels.  Rather, this
> would be demonstrating the value of that model.  Debian unstable, and
> thus testing and eventually stable, would get stable Rust releases.
> Debian experimental would get Rust builds with experimental features
> turned on.  Software uploaded to Debian unstable, for instance, would
> still have to build with stable Rust.
> 

I'm trying this now, going to upload to mentors.debian.net if I succeed. Wish me luck!

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Message #31 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 796256@bugs.debian.org, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 00:22:28 +0200

[Message part 1 (text/plain, inline)]

On 30/08/15 21:42, Ximin Luo wrote:
> On 21/08/15 10:33, Josh Triplett wrote:
>>> Personally, I'm reluctant to break the release-channels experiment so close
>>> to the 1.0 release.  We may well declare it failed and do something
>>> different in future, but right now I think Debian has an important role to
>>> play in demonstrating what the "stable" Rust world looks like and providing
>>> pressure for upstreams to avoid unstable features.
>>
>> I don't think this would be breaking release-channels.  Rather, this
>> would be demonstrating the value of that model.  Debian unstable, and
>> thus testing and eventually stable, would get stable Rust releases.
>> Debian experimental would get Rust builds with experimental features
>> turned on.  Software uploaded to Debian unstable, for instance, would
>> still have to build with stable Rust.
>>
> 
> I'm trying this now, going to upload to mentors.debian.net if I succeed. Wish me luck!
> 

I built these source packages using the attached script:

Version 1.2.0.20150812.beta+dfsg1-1
Version 1.2.0.20150830.nightly+dfsg1-1
https://mentors.debian.net/package/rustc

I haven't yet built binary packages out of them, though - the tests keep failing. Next, I will play around with giving DEB_BUILD_OPTIONS=nocheck to cowbuilder.

Some notes:

- we could probably come up with a better system for the version strings
- for the nightly, I dropped debian/patches/fix-test-llvm-3.6.diff which seems to have been applied upstream
- for some reason we bundle a src/etc/snapshot.pyc in the .debian.tar.gz and force it to be ignored with debian/source/include-binaries, wtf?
- both beta and nightly have upgraded to jquery 2.1.4 but my upgrade script doesn't account for this
- pretty sure we can symlink jquery.js in debian/rust-doc.links instead of having debian/rules explicitly do it
- not sure what to do with the libstd-rust-xxxx stuff. I couldn't find the id anywhere in the upstream source, even in the current debian sid version. Also, will we continue to keep adding the old package versions to Replaces/Breaks? This seems unsustainable.

I'm sure there's lots of other things, have fun playing with what I have so far. It'll probably take me a couple of weeks to return to this.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

[upgrade-rust.sh (application/x-shellscript, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #36 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Sylvestre Ledru <sylvestre@debian.org>

To: Ximin Luo <infinity0@debian.org>, 796256@bugs.debian.org, Josh Triplett <josh@joshtriplett.org>, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 08:59:46 +0200

[Message part 1 (text/plain, inline)]

Le 31/08/2015 00:22, Ximin Luo a écrit :
> On 30/08/15 21:42, Ximin Luo wrote:
>> On 21/08/15 10:33, Josh Triplett wrote:
>>>> Personally, I'm reluctant to break the release-channels experiment so close
>>>> to the 1.0 release.  We may well declare it failed and do something
>>>> different in future, but right now I think Debian has an important role to
>>>> play in demonstrating what the "stable" Rust world looks like and providing
>>>> pressure for upstreams to avoid unstable features.
>>> I don't think this would be breaking release-channels.  Rather, this
>>> would be demonstrating the value of that model.  Debian unstable, and
>>> thus testing and eventually stable, would get stable Rust releases.
>>> Debian experimental would get Rust builds with experimental features
>>> turned on.  Software uploaded to Debian unstable, for instance, would
>>> still have to build with stable Rust.
>>>
>> I'm trying this now, going to upload to mentors.debian.net if I succeed. Wish me luck!
>>
> I built these source packages using the attached script:
>
> Version 1.2.0.20150812.beta+dfsg1-1
> Version 1.2.0.20150830.nightly+dfsg1-1
> https://mentors.debian.net/package/rustc
>
> I haven't yet built binary packages out of them, though - the tests keep failing. Next, I will play around with giving DEB_BUILD_OPTIONS=nocheck to cowbuilder.
What kind of failure?
>
> Some notes:
>
> - we could probably come up with a better system for the version strings
dates + changeset?
> - for the nightly, I dropped debian/patches/fix-test-llvm-3.6.diff which seems to have been applied upstream
Indeed.
> - for some reason we bundle a src/etc/snapshot.pyc in the .debian.tar.gz and force it to be ignored with debian/source/include-binaries, wtf?
Please avoid using "wtf" in this kind of discussion.
About the issue itself, I saw it too but didn't bother investigating it.
No big deal anywayy.
> - both beta and nightly have upgraded to jquery 2.1.4 but my upgrade script doesn't account for this
should be trivial.
> - pretty sure we can symlink jquery.js in debian/rust-doc.links instead of having debian/rules explicitly do it
I would be happy to apply a patch.
> - not sure what to do with the libstd-rust-xxxx stuff. I couldn't find the id anywhere in the upstream source, even in the current debian sid version. Also, will we continue to keep adding the old package versions to Replaces/Breaks? This seems unsustainable.
We are aware of this and we decided to take this approach on purpose for
now. This is not perfect but as rust is a moving target,
we took this shortcut. We hope they will be able to improve/fix that
upstream in the near future.

Sylvestre

[signature.asc (application/pgp-signature, attachment)]

Message #41 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: Sylvestre Ledru <sylvestre@debian.org>, 796256@bugs.debian.org, Josh Triplett <josh@joshtriplett.org>, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 10:37:13 +0200

On 31/08/15 08:59, Sylvestre Ledru wrote:
> Le 31/08/2015 00:22, Ximin Luo a écrit :
>> I built these source packages using the attached script:
>>
>> Version 1.2.0.20150812.beta+dfsg1-1
>> Version 1.2.0.20150830.nightly+dfsg1-1
>> https://mentors.debian.net/package/rustc
>>
>> I haven't yet built binary packages out of them, though - the tests keep failing. Next, I will play around with giving DEB_BUILD_OPTIONS=nocheck to cowbuilder.
> What kind of failure?

From building 1.2.0.20150812.beta+dfsg1-1 (I haven't yet tried nightly):

failures:

---- [run-pass] run-pass/issue-26468.rs stdout ----
	
error: test run failed!
status: exit code: 101
command: x86_64-unknown-linux-gnu/test/run-pass/issue-26468.stage2-x86_64-unknown-linux-gnu 
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `42`, right: `19`)', /tmp/buildd/rustc-1.2.0.20150812.beta+dfsg1/src/test/run-pass/issue-26468.rs:37

------------------------------------------

thread '[run-pass] run-pass/issue-26468.rs' panicked at 'explicit panic', /tmp/buildd/rustc-1.2.0.20150812.beta+dfsg1/src/compiletest/runtest.rs:1490


---- [run-pass] run-pass/wait-forked-but-failed-child.rs stdout ----
	
error: test run failed!
status: exit code: 101
command: x86_64-unknown-linux-gnu/test/run-pass/wait-forked-but-failed-child.stage2-x86_64-unknown-linux-gnu 
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', src/libcore/result.rs:732

------------------------------------------

thread '[run-pass] run-pass/wait-forked-but-failed-child.rs' panicked at 'explicit panic', /tmp/buildd/rustc-1.2.0.20150812.beta+dfsg1/src/compiletest/runtest.rs:1490



failures:
    [run-pass] run-pass/issue-26468.rs
    [run-pass] run-pass/wait-forked-but-failed-child.rs

test result: FAILED. 2179 passed; 2 failed; 4 ignored; 0 measured

>>
>> Some notes:
>>
>> - we could probably come up with a better system for the version strings
> dates + changeset?
>> - for the nightly, I dropped debian/patches/fix-test-llvm-3.6.diff which seems to have been applied upstream
> Indeed.
>> - for some reason we bundle a src/etc/snapshot.pyc in the .debian.tar.gz and force it to be ignored with debian/source/include-binaries, wtf?
> Please avoid using "wtf" in this kind of discussion.
> About the issue itself, I saw it too but didn't bother investigating it.
> No big deal anywayy.

well, it is probably against policy.

>> - both beta and nightly have upgraded to jquery 2.1.4 but my upgrade script doesn't account for this
> should be trivial.
>> - pretty sure we can symlink jquery.js in debian/rust-doc.links instead of having debian/rules explicitly do it
> I would be happy to apply a patch.
>> - not sure what to do with the libstd-rust-xxxx stuff. I couldn't find the id anywhere in the upstream source, even in the current debian sid version. Also, will we continue to keep adding the old package versions to Replaces/Breaks? This seems unsustainable.
> We are aware of this and we decided to take this approach on purpose for
> now. This is not perfect but as rust is a moving target,
> we took this shortcut. We hope they will be able to improve/fix that
> upstream in the near future.
> 

How is the hash generated and how do we guarantee that our hash matches with upstream's hash? Is there a way to calculate the hash *before* doing the build?

FWIW, the hash for beta 20150812.beta is 198068b3, so anyone building the about source package I made, needs to make further edits to change it so. I can currently build only using cowbuilder because of the libstdc++6 transitions, so looks like I will have to do it again, sigh.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Message #46 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Sylvestre Ledru <sylvestre@debian.org>

To: Ximin Luo <infinity0@debian.org>, 796256@bugs.debian.org, Josh Triplett <josh@joshtriplett.org>, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 10:58:56 +0200

Le 31/08/2015 10:37, Ximin Luo a écrit :
> On 31/08/15 08:59, Sylvestre Ledru wrote:
>> Le 31/08/2015 00:22, Ximin Luo a écrit :
>>> I built these source packages using the attached script:
>>>
>>> Version 1.2.0.20150812.beta+dfsg1-1
>>> Version 1.2.0.20150830.nightly+dfsg1-1
>>> https://mentors.debian.net/package/rustc
>>>
>>> I haven't yet built binary packages out of them, though - the tests keep failing. Next, I will play around with giving DEB_BUILD_OPTIONS=nocheck to cowbuilder.
>> What kind of failure?
> From building 1.2.0.20150812.beta+dfsg1-1 (I haven't yet tried nightly):
>
> failures:
>
> ---- [run-pass] run-pass/issue-26468.rs stdout ----
> 	
> error: test run failed!
> status: exit code: 101
> command: x86_64-unknown-linux-gnu/test/run-pass/issue-26468.stage2-x86_64-unknown-linux-gnu 
> stdout:
> ------------------------------------------
>
> ------------------------------------------
> stderr:
> ------------------------------------------
> thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `42`, right: `19`)', /tmp/buildd/rustc-1.2.0.20150812.beta+dfsg1/src/test/run-pass/issue-26468.rs:37
>
> ------------------------------------------
>
> thread '[run-pass] run-pass/issue-26468.rs' panicked at 'explicit panic', /tmp/buildd/rustc-1.2.0.20150812.beta+dfsg1/src/compiletest/runtest.rs:1490
>
>
> ---- [run-pass] run-pass/wait-forked-but-failed-child.rs stdout ----
> 	
> error: test run failed!
> status: exit code: 101
> command: x86_64-unknown-linux-gnu/test/run-pass/wait-forked-but-failed-child.stage2-x86_64-unknown-linux-gnu 
> stdout:
> ------------------------------------------
>
> ------------------------------------------
> stderr:
> ------------------------------------------
> thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', src/libcore/result.rs:732
Do you know which file it was looking for?
> ------------------------------------------
>
> thread '[run-pass] run-pass/wait-forked-but-failed-child.rs' panicked at 'explicit panic', /tmp/buildd/rustc-1.2.0.20150812.beta+dfsg1/src/compiletest/runtest.rs:1490
>
>
>
> failures:
>     [run-pass] run-pass/issue-26468.rs
>     [run-pass] run-pass/wait-forked-but-failed-child.rs
>
> test result: FAILED. 2179 passed; 2 failed; 4 ignored; 0 measured
You should report a bug upstream about this.
>>> Some notes:
>>>
>>> - we could probably come up with a better system for the version strings
>> dates + changeset?
>>> - for the nightly, I dropped debian/patches/fix-test-llvm-3.6.diff which seems to have been applied upstream
>> Indeed.
>>> - for some reason we bundle a src/etc/snapshot.pyc in the .debian.tar.gz and force it to be ignored with debian/source/include-binaries, wtf?
>> Please avoid using "wtf" in this kind of discussion.
>> About the issue itself, I saw it too but didn't bother investigating it.
>> No big deal anywayy.
> well, it is probably against policy.
Probably but is that a big deal?
>> We are aware of this and we decided to take this approach on purpose for
>> now. This is not perfect but as rust is a moving target,
>> we took this shortcut. We hope they will be able to improve/fix that
>> upstream in the near future.
>>
> How is the hash generated and how do we guarantee that our hash matches with upstream's hash? Is there a way to calculate the hash *before* doing the build?
We are using upstream hash.

S

Message #51 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: Sylvestre Ledru <sylvestre@debian.org>, 796256@bugs.debian.org, Josh Triplett <josh@joshtriplett.org>, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 11:26:13 +0200

(I'll answer the other things later)

On 31/08/15 10:58, Sylvestre Ledru wrote:
> Le 31/08/2015 10:37, Ximin Luo a écrit :
>> On 31/08/15 08:59, Sylvestre Ledru wrote:
>>> We are aware of this and we decided to take this approach on purpose for
>>> now. This is not perfect but as rust is a moving target,
>>> we took this shortcut. We hope they will be able to improve/fix that
>>> upstream in the near future.
>>>
>> How is the hash generated and how do we guarantee that our hash matches with upstream's hash? Is there a way to calculate the hash *before* doing the build?
> We are using upstream hash.
> 

You could have been a bit more helpful. In fact the hash is generated only from the upstream version string, and *not* in the contents of the files (which is the first reasonable thought for things that are hashes). 

debian/rules:RUST_HASH := $(shell printf '%s' $(DEB_VERSION_UPSTREAM) | sed -e 's/\+dfsg[0-9]*$$//' | md5sum | head -c 8)
configure:    CFG_HASH_COMMAND="$CFG_MD5 -q | cut -c 1-8"
configure:    CFG_HASH_COMMAND="$CFG_MD5SUM | cut -c 1-8"
mk/main.mk:CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) | $(CFG_HASH_COMMAND))

So this actually contains no extra information than the strings (e.g.) "1.3.0" or "1.3.0-beta.3" or "1.3.0-nightly" etc, but has the disadvantage of not being comparable. I am wondering if we should just (a) patch this to use $(CFG_RELEASE) instead, and maybe (b) call the package libstd-rust-1, since semantic versioning is supposed to mean backwards compatibility between 1.3.0 and 1.2.0. That would be more sane, and I've asked in #rust about it.

At the very least, debian/rules should refuse to build if libstd-rust-xxxx in the control file doesn't match RUST_HASH. I'll fix that up.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Message #56 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Sylvestre Ledru <sylvestre@debian.org>

To: Ximin Luo <infinity0@debian.org>, 796256@bugs.debian.org, Josh Triplett <josh@joshtriplett.org>, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 11:54:30 +0200

Le 31/08/2015 11:26, Ximin Luo a écrit :
> (I'll answer the other things later)
> 
> On 31/08/15 10:58, Sylvestre Ledru wrote:
>> Le 31/08/2015 10:37, Ximin Luo a écrit :
>>> On 31/08/15 08:59, Sylvestre Ledru wrote:
>>>> We are aware of this and we decided to take this approach on purpose for
>>>> now. This is not perfect but as rust is a moving target,
>>>> we took this shortcut. We hope they will be able to improve/fix that
>>>> upstream in the near future.
>>>>
>>> How is the hash generated and how do we guarantee that our hash matches with upstream's hash? Is there a way to calculate the hash *before* doing the build?
>> We are using upstream hash.
>>
> 
> You could have been a bit more helpful. In fact the hash is generated only from the upstream version string, and *not* in the contents of the files (which is the first reasonable thought for things that are hashes). 
Oups, my bad, sorry. As you can guess, I didn't work on that :)

Sylvestre

Message #61 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Angus Lees <gus@debian.org>

To: Ximin Luo <infinity0@debian.org>, Sylvestre Ledru <sylvestre@debian.org>, 796256@bugs.debian.org, Josh Triplett <josh@joshtriplett.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Mon, 31 Aug 2015 13:22:27 +0000

[Message part 1 (text/plain, inline)]

On Mon, 31 Aug 2015 at 19:26 Ximin Luo <infinity0@debian.org> wrote:

> On 31/08/15 10:58, Sylvestre Ledru wrote:
> > Le 31/08/2015 10:37, Ximin Luo a écrit :
> >> On 31/08/15 08:59, Sylvestre Ledru wrote:
> >>> We are aware of this and we decided to take this approach on purpose
> for
> >>> now. This is not perfect but as rust is a moving target,
> >>> we took this shortcut. We hope they will be able to improve/fix that
> >>> upstream in the near future.
> >>>
> >> How is the hash generated and how do we guarantee that our hash matches
> with upstream's hash? Is there a way to calculate the hash *before* doing
> the build?
> > We are using upstream hash.
> >
>
> You could have been a bit more helpful. In fact the hash is generated only
> from the upstream version string, and *not* in the contents of the files
> (which is the first reasonable thought for things that are hashes).
>
> debian/rules:RUST_HASH := $(shell printf '%s' $(DEB_VERSION_UPSTREAM) |
> sed -e 's/\+dfsg[0-9]*$$//' | md5sum | head -c 8)
> configure:    CFG_HASH_COMMAND="$CFG_MD5 -q | cut -c 1-8"
> configure:    CFG_HASH_COMMAND="$CFG_MD5SUM | cut -c 1-8"
> mk/main.mk:CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) |
> $(CFG_HASH_COMMAND))
>
> So this actually contains no extra information than the strings (e.g.)
> "1.3.0" or "1.3.0-beta.3" or "1.3.0-nightly" etc, but has the disadvantage
> of not being comparable.
>

This is the case for libstd, but not for other dylibs.  The idea is that
it's a hash of the ABI - that is, the compiler version and the version of
every dependent library. For rustc/std itself, there are no dependent
libraries, hence this is just a hash of the compiler version.  I think it
would be wrong in the general case to make this just the source version
string.  In addition, ordering makes no sense on the library files -
"1.3.0" is potentially totally different symbol mangling and embedded LLVM
bitcode to "1.3.1", and there is no meaning to sorting the two, except that
it probably corresponds to the file mtime order.

I actually think the hash thing is a pretty neat take on symbol
versioning.  I'm not sure how much of the original vision is going to
survive whatever is required to declare ABI stability, however.

 - Gus

[Message part 2 (text/html, inline)]

Message #66 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 796256@bugs.debian.org, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Wed, 02 Sep 2015 16:53:27 +0200

[Message part 1 (text/plain, inline)]

On 31/08/15 00:22, Ximin Luo wrote:
> On 30/08/15 21:42, Ximin Luo wrote:
>> On 21/08/15 10:33, Josh Triplett wrote:
>>>> Personally, I'm reluctant to break the release-channels experiment so close
>>>> to the 1.0 release.  We may well declare it failed and do something
>>>> different in future, but right now I think Debian has an important role to
>>>> play in demonstrating what the "stable" Rust world looks like and providing
>>>> pressure for upstreams to avoid unstable features.
>>>
>>> I don't think this would be breaking release-channels.  Rather, this
>>> would be demonstrating the value of that model.  Debian unstable, and
>>> thus testing and eventually stable, would get stable Rust releases.
>>> Debian experimental would get Rust builds with experimental features
>>> turned on.  Software uploaded to Debian unstable, for instance, would
>>> still have to build with stable Rust.
>>>
>>
>> I'm trying this now, going to upload to mentors.debian.net if I succeed. Wish me luck!
>>
> 
> I built these source packages using the attached script:
> 
> Version 1.2.0.20150812.beta+dfsg1-1
> Version 1.2.0.20150830.nightly+dfsg1-1
> https://mentors.debian.net/package/rustc
> 
> I haven't yet built binary packages out of them, though - the tests keep failing. Next, I will play around with giving DEB_BUILD_OPTIONS=nocheck to cowbuilder.
> 

1.4.0~~nightly.20150901+dfsg1-1 built for amd64, all tests passing, uploaded here in experimental:

https://people.torproject.org/~infinity0/apt/ 

Note that it contains an incomplete debian/changelog which I can't be bothered fixing right now. I built it by running 

$ DEBDIR=./rust/debian CHANNEL=nightly ./upgrade-rust.sh 

using the attached script, against the current rust.git debian packaging repo, then fixing debian/copyright to remove obsolete references to valgrind, then:

$ sudo cowbuilder --build rustc_1.4.0~~nightly.20150901+dfsg1-1.dsc

If people like it, I can upload a version to Debian experimental tomorrow.

> Some notes:
> 
> - we could probably come up with a better system for the version strings
> - for the nightly, I dropped debian/patches/fix-test-llvm-3.6.diff which seems to have been applied upstream
> - for some reason we bundle a src/etc/snapshot.pyc in the .debian.tar.gz and force it to be ignored with debian/source/include-binaries, wtf?
> - both beta and nightly have upgraded to jquery 2.1.4 but my upgrade script doesn't account for this
> - pretty sure we can symlink jquery.js in debian/rust-doc.links instead of having debian/rules explicitly do it
> - not sure what to do with the libstd-rust-xxxx stuff. I couldn't find the id anywhere in the upstream source, even in the current debian sid version. Also, will we continue to keep adding the old package versions to Replaces/Breaks? This seems unsustainable.
> 

All these points have been fixed in the above package, as well as in git. I've kept the hash-based library name for now.

I also made a beta version here, but haven't yet had time to build it:

http://mentors.debian.net/debian/pool/main/r/rustc/rustc_1.3.0~beta.3.20150812+dfsg1-1.dsc

"It should work", though. Enjoy!

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

[upgrade-rust.sh (application/x-shellscript, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #71 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Luca Bruno <lucab@debian.org>

To: pkg-rust-maintainers@lists.alioth.debian.org, Ximin Luo <infinity0@debian.org>, 796256@bugs.debian.org

Cc: Josh Triplett <josh@joshtriplett.org>, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Wed, 02 Sep 2015 19:47:53 +0200

[Message part 1 (text/plain, inline)]

On Wednesday 02 September 2015 16:53:27 Ximin Luo wrote:

> 1.4.0~~nightly.20150901+dfsg1-1 built for amd64, all tests passing, uploaded
> here in experimental:
> 
> https://people.torproject.org/~infinity0/apt/
> If people like it, I can upload a version to Debian experimental tomorrow. 

 
> I also made a beta version here, but haven't yet had time to build it:
> 
> http://mentors.debian.net/debian/pool/main/r/rustc/rustc_1.3.0~beta.3.201508
> 12+dfsg1-1.dsc

I have to agree with Angus here, I think that having nightlies in the archive 
is really a bad idea, even if just in experimental.
Features are gated for a reason (still being discussed, to be soon removed, 
etc.) and it is counterproductive to easily provide them to the wide audience.

Moreover, due to soname versioning, this means multiple trips through NEW 
every release cycle (6 weeks), and I honestly think it's a waste of project's 
resources.

However, I fully see the benefits of building beta channel in order to catch 
regressions/bugs earlier (but that one too doesn't expose unstable features 
IIRC), and if we have some time we'd better coordinate the efforts for that.

Regarding the specific initial issue (gated libc), doc explicitly tells to use 
the external "libc" crate instead. Even with nightly channel, the other 
project would still need to be patched. 

Cheers, Luca  

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT) debian.org
`. `'`                          | GPG: 0xBB1A3A854F3BBEBF
  `-     http://www.debian.org 	| Debian GNU/Linux Developer

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: Luca Bruno <lucab@debian.org>, 796256@bugs.debian.org

Cc: Angus Lees <gus@debian.org>, Josh Triplett <josh@joshtriplett.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Wed, 02 Sep 2015 20:06:21 +0200

On 02/09/15 19:47, Luca Bruno wrote:
> On Wednesday 02 September 2015 16:53:27 Ximin Luo wrote:
> 
>> 1.4.0~~nightly.20150901+dfsg1-1 built for amd64, all tests passing, uploaded
>> here in experimental:
>>
>> https://people.torproject.org/~infinity0/apt/
>> If people like it, I can upload a version to Debian experimental tomorrow. 
> 
>  
>> I also made a beta version here, but haven't yet had time to build it:
>>
>> http://mentors.debian.net/debian/pool/main/r/rustc/rustc_1.3.0~beta.3.201508
>> 12+dfsg1-1.dsc
> 
> I have to agree with Angus here, I think that having nightlies in the archive 
> is really a bad idea, even if just in experimental.
> Features are gated for a reason (still being discussed, to be soon removed, 
> etc.) and it is counterproductive to easily provide them to the wide audience.
> 

But rust upstream is *already* providing them to a wide audience... I would be more convinced of this argument if they *didn't* release nightlies. Not many projects do this; they made an explicit decision to.

> Moreover, due to soname versioning, this means multiple trips through NEW 
> every release cycle (6 weeks), and I honestly think it's a waste of project's 
> resources.
> 
> However, I fully see the benefits of building beta channel in order to catch 
> regressions/bugs earlier (but that one too doesn't expose unstable features 
> IIRC), and if we have some time we'd better coordinate the efforts for that.
> 

OK, I'll leave this decision to the rest of the team; I don't mind either way. My "switch-channel" script can cope with the beta/nightly builds just as easily, it's just a matter of giving it different parameters. (I will keep updating my personal repo with the nightlies as much as I care to, which may or may not be that often.)

However, I will point out that the beta channel, ironically will change the hash name *more often* than the nightly, because it contains a "prerelease" number, i.e.:

$ echo -n "1.4.0-nightly" | md5sum | head -c8
35017696
$ echo -n "1.3.0-beta.3" | md5sum | head -c8
42429799
$ echo -n "1.3.0-beta.2" | md5sum | head -c8
6eca8e2b

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Message #81 received at 796256@bugs.debian.org (full text, mbox, reply):

From: josh@joshtriplett.org

To: Ximin Luo <infinity0@debian.org>

Cc: Luca Bruno <lucab@debian.org>, 796256@bugs.debian.org, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Wed, 2 Sep 2015 13:37:35 -0700

On Wed, Sep 02, 2015 at 08:06:21PM +0200, Ximin Luo wrote:
> On 02/09/15 19:47, Luca Bruno wrote:
> > On Wednesday 02 September 2015 16:53:27 Ximin Luo wrote:
> > 
> >> 1.4.0~~nightly.20150901+dfsg1-1 built for amd64, all tests passing, uploaded
> >> here in experimental:
> >>
> >> https://people.torproject.org/~infinity0/apt/
> >> If people like it, I can upload a version to Debian experimental tomorrow. 
> > 
> >  
> >> I also made a beta version here, but haven't yet had time to build it:
> >>
> >> http://mentors.debian.net/debian/pool/main/r/rustc/rustc_1.3.0~beta.3.201508
> >> 12+dfsg1-1.dsc
> > 
> > I have to agree with Angus here, I think that having nightlies in the archive 
> > is really a bad idea, even if just in experimental.
> > Features are gated for a reason (still being discussed, to be soon removed, 
> > etc.) and it is counterproductive to easily provide them to the wide audience.
> > 
> 
> But rust upstream is *already* providing them to a wide audience... I would be more convinced of this argument if they *didn't* release nightlies. Not many projects do this; they made an explicit decision to.

Right, exactly.  Rust provides precompiled binaries of nightly versions,
rather than just saying "if you need these, you should build from source
yourself".  But Debian users shouldn't have to download and run binaries
provided elsewhere; there are *huge* advantages to doing so through
Debian packages instead.  I absolutely agree that rust nightly binaries
should never appear in unstable/testing/stable, but experimental seems
perfectly sensible.

- Josh Triplett

Message #86 received at 796256@bugs.debian.org (full text, mbox, reply):

From: josh@joshtriplett.org

To: Luca Bruno <lucab@debian.org>

Cc: pkg-rust-maintainers@lists.alioth.debian.org, Ximin Luo <infinity0@debian.org>, 796256@bugs.debian.org, Angus Lees <gus@debian.org>

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Wed, 2 Sep 2015 13:42:58 -0700

On Wed, Sep 02, 2015 at 07:47:53PM +0200, Luca Bruno wrote:
> I have to agree with Angus here, I think that having nightlies in the archive 
> is really a bad idea, even if just in experimental.
> Features are gated for a reason (still being discussed, to be soon removed, 
> etc.) and it is counterproductive to easily provide them to the wide audience.

Having access to gated features allows testing them and providing
feedback.  And, as far as I can tell, many packages in the cargo
ecosystem do so.

> Moreover, due to soname versioning, this means multiple trips through NEW 
> every release cycle (6 weeks), and I honestly think it's a waste of project's 
> resources.

GCC provides self-contained snapshot packages ("gcc-snapshot"), which
bundle all components in a single package.  That seems sensible here as
well.  Since no package in the archive should build-depend on
rust-nightly, the soname versioning doesn't need to appear in the
package name; the shared library can just go in the same rust-nightly
package.

> Regarding the specific initial issue (gated libc), doc explicitly tells to use 
> the external "libc" crate instead. Even with nightly channel, the other 
> project would still need to be patched. 

I'm not the maintainer of the external projects on cargo that use those
features, and that was not by any means the only such feature the
package used.

- Josh Triplett

Message #91 received at 796256@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>

To: josh@joshtriplett.org, 796256@bugs.debian.org

Subject: Re: [Pkg-rust-maintainers] Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

Date: Wed, 10 Feb 2016 15:34:21 +0100

I just made these:

https://launchpad.net/~infinity0/+archive/ubuntu/rust-beta
https://launchpad.net/~infinity0/+archive/ubuntu/rust-nightly

The packages were built using this script:

https://anonscm.debian.org/cgit/pkg-rust/rust.git/tree/debian/build-preview-dsc.sh

At a later date I'll play with setting up a cron job to update these PPAs regularly, or you can do that if you have time first. :)

I haven't done anything fancy, they will upgrade (overwrite) the existing Debian rustc packages. But they work fine, at least so far for me.

Note that i386 builds are failing everywhere due to #812825.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Send a report that this bug log contains spam.