GNU bug report logs - #39949
[core-updates] rust@1.20 fails tests

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39949 in the body.
You can then email your comments to 39949 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: bug-guix <at> gnu.org
Subject: [core-updates] rust <at> 1.20 fails tests
Date: Fri, 06 Mar 2020 15:33:29 +0100

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

Rust 1.20 fails a test on core-updates, possibly because of the new
version of GNU Make (4.3).

I suppose we can disable that test for the bootstrap builds as long as
it works for the latest version of Rust.

Log output:

     Running build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/jobserver-dd0c6bf78d70e32b

running 3 tests
test jobserver_and_j ... ok
test jobserver_exists ... ok
test makes_jobserver_used ... FAILED

failures:

---- makes_jobserver_used stdout ----
        running `make -j2`
thread 'makes_jobserver_used' panicked at '
Expected: execs
    but: exited with exit code: 2
--- stdout
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/cargo build

--- stderr
   Compiling d1 v0.0.1 (file:///tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/cit/t2/foo/d1)
   Compiling d2 v0.0.1 (file:///tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/cit/t2/foo/d2)
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.20.0 running on x86_64-unknown-linux-gnu

thread 'rustc' panicked at 'failed to acquire jobserver token: Error { repr: Os { code: 11, message: "Resource temporarily unavailable" } }', src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.20.0 running on x86_64-unknown-linux-gnu

thread 'rustc' panicked at 'failed to acquire jobserver token: Error { repr: Os { code: 11, message: "Resource temporarily unavailable" } }', src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: failed to acquire jobserver token

Caused by:
  Resource temporarily unavailable (os error 11)
make: *** [Makefile:2: all] Error 101
', src/vendor/hamcrest/src/core.rs:31:12
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    makes_jobserver_used

test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test jobserver'


command did not execute successfully: "/gnu/store/c3jc4rlyj1b50djxny0ldpbpywaf5apr-rust-1.19.0-cargo/bin/cargo" "test" "-j" "1" "--target" "x86_64-unknown-linux-gnu" "--release" "--frozen" "--manifest-path" "/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/tools/cargo/Cargo.toml"
expected success, got: exit code: 101


failed to run: /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/build/bootstrap/debug/bootstrap -j1 test src/tools/cargo
Build completed unsuccessfully in 0:09:46
command "./x.py" "-j1" "test" "src/tools/cargo" failed with status 1
builder for `/gnu/store/dxrkx2iqr0vhan7m0lfczw3b8rpyw8z8-rust-1.20.0.drv' failed with exit code 1

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

Message #10 received at 39949-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: 39949-done <at> debbugs.gnu.org
Subject: Re: [core-updates] rust <at> 1.20 fails tests
Date: Tue, 31 Mar 2020 16:04:03 +0200

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

Marius Bakke <mbakke <at> fastmail.com> writes:

> Rust 1.20 fails a test on core-updates, possibly because of the new
> version of GNU Make (4.3).
>
> I suppose we can disable that test for the bootstrap builds as long as
> it works for the latest version of Rust.

Fixed by giving Rust an earlier version of GNU Make in commit
47cd0febe957b698cc2ae28978bdc3bc89e787f9.

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

Message #13 received at 39949 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: 39949 <at> debbugs.gnu.org, mbakke <at> fastmail.com
Subject: Re: bug#39949: [core-updates] rust <at> 1.20 fails tests
Date: Tue, 31 Mar 2020 23:46:01 +0200

Hi Marius,

On +2020-03-31 16:04:03 +0200, Marius Bakke wrote:
> Marius Bakke <mbakke <at> fastmail.com> writes:
> 
> > Rust 1.20 fails a test on core-updates, possibly because of the new
> > version of GNU Make (4.3).
> >
> > I suppose we can disable that test for the bootstrap builds as long as
> > it works for the latest version of Rust.
> 
> Fixed by giving Rust an earlier version of GNU Make in commit
> 47cd0febe957b698cc2ae28978bdc3bc89e787f9.

ISTM this kind of "fixed" is not the same as e.g. an upstream upgrade that
"fixes" "the problem" -- so I'm wondering if work-flow-wise
you have a way to tell some upgrade-watching robot to notify you (or your s/w[1])
when the inevitable revision to your "fix" should be done.

Are there any general standards for subscribing interest in being notified
when a particular package or file gets upgraded/revised/etc in any "distro"
your package may be dependent on?

[1] Is there such a thing as a derivation/service that sits and waits for such
a notification, and maybe sends you a patch when it does get notified?

Just curious how the world works :)

-- 
Regards,
Bengt Richter

Message #16 received at 39949 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Bengt Richter <bokr <at> bokr.com>, 39949 <at> debbugs.gnu.org
Subject: Re: bug#39949: [core-updates] rust <at> 1.20 fails tests
Date: Thu, 02 Apr 2020 21:16:27 +0200

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

Bengt Richter <bokr <at> bokr.com> writes:

> Hi Marius,
>
> On +2020-03-31 16:04:03 +0200, Marius Bakke wrote:
>> Marius Bakke <mbakke <at> fastmail.com> writes:
>> 
>> > Rust 1.20 fails a test on core-updates, possibly because of the new
>> > version of GNU Make (4.3).
>> >
>> > I suppose we can disable that test for the bootstrap builds as long as
>> > it works for the latest version of Rust.
>> 
>> Fixed by giving Rust an earlier version of GNU Make in commit
>> 47cd0febe957b698cc2ae28978bdc3bc89e787f9.
>
> ISTM this kind of "fixed" is not the same as e.g. an upstream upgrade that
> "fixes" "the problem" -- so I'm wondering if work-flow-wise
> you have a way to tell some upgrade-watching robot to notify you (or your s/w[1])
> when the inevitable revision to your "fix" should be done.

I don't know of any such service, but would probably use it if it
exists!  Often fixes are already available in upstream repositories, so
it's a matter of locating it and checking the log on the file in
question.

In this case I was too lazy as Rust 1.20 is already ancient and there is
work on bootstrapping 1.29 directly in another issue.

> Are there any general standards for subscribing interest in being notified
> when a particular package or file gets upgraded/revised/etc in any "distro"
> your package may be dependent on?

I do subscribe to a bunch of mailing lists and Atom feeds to get
notified of new releases and encourage others to do the same for
packages they care about.  Pro tip: both GitLab and GitHub offers
release feeds on these URLs:

https://gitlab.com/project/package/tags?format=atom
https://github.com/project/package/releases.atom

> [1] Is there such a thing as a derivation/service that sits and waits for such
> a notification, and maybe sends you a patch when it does get notified?
>
> Just curious how the world works :)

IME best way to learn how something works is to take part in it!  I have
learned a whole lot since I got involved with Guix, both personally and
professionally, and don't intend to stop any time soon!  :-)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.