Re: Bug#881845: rustc: FTBFS on mips*: test failures

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Bug#881845: rustc: FTBFS on mips*: test failures

James Cowgill
Hi,

On 15/11/17 17:30, Emilio Pozuelo Monfort wrote:

> Source: rustc
> Version: 1.21.0+dfsg1-3
> Severity: important
>
> Hi,
>
> Sometime ago I asked about rustc bootstrap status on mips*:
>
> 17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, i didn't want to ship it, i haven't had time to check since
>
>>From https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips&ver=1.14.0%2Bdfsg1-3&stamp=1484077706&raw=0
>
> test net::tcp::tests::timeouts ... FAILED
> test net::udp::tests::timeouts ... FAILED
> test sys::imp::ext::net::test::timeouts ... FAILED
>
> Looks like timeouts are broken on rust/mips?
>
> mips64el has different errors:
>
> test f32::f32::tanh_0 ... FAILED
> test f64::f64::tanh_0 ... FAILED
> test io::error::Error::from_raw_os_error_0 ... FAILED
>
> Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
> errors are for 1.14.0, you'll want to try with a newer version first and
> see what's the current status.
I just tried building the latest rustc on mips64el. As I expected, I hit
this LLVM bug again where any code using atomics will hang:

https://bugs.llvm.org/show_bug.cgi?id=32020

I'll see if I can get Simon to have a look at it again.

James


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#881845: rustc: FTBFS on mips*: test failures

Emilio Pozuelo Monfort-4
On 17/11/17 13:25, James Cowgill wrote:

> Hi,
>
> On 15/11/17 17:30, Emilio Pozuelo Monfort wrote:
>> Source: rustc
>> Version: 1.21.0+dfsg1-3
>> Severity: important
>>
>> Hi,
>>
>> Sometime ago I asked about rustc bootstrap status on mips*:
>>
>> 17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, i didn't want to ship it, i haven't had time to check since
>>
>> >From https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips&ver=1.14.0%2Bdfsg1-3&stamp=1484077706&raw=0
>>
>> test net::tcp::tests::timeouts ... FAILED
>> test net::udp::tests::timeouts ... FAILED
>> test sys::imp::ext::net::test::timeouts ... FAILED
>>
>> Looks like timeouts are broken on rust/mips?
>>
>> mips64el has different errors:
>>
>> test f32::f32::tanh_0 ... FAILED
>> test f64::f64::tanh_0 ... FAILED
>> test io::error::Error::from_raw_os_error_0 ... FAILED
>>
>> Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
>> errors are for 1.14.0, you'll want to try with a newer version first and
>> see what's the current status.
>
> I just tried building the latest rustc on mips64el. As I expected, I hit
> this LLVM bug again where any code using atomics will hang:
>
> https://bugs.llvm.org/show_bug.cgi?id=32020
>
> I'll see if I can get Simon to have a look at it again.

FTR:

According to our conversation over IRC, there's a patch for the above bug, but
mips64el is now affected by https://github.com/rust-lang/rust/issues/47290

mips(el) may be fine now with that patch, or they may not :P

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: Bug#881845: rustc: FTBFS on mips*: test failures

Emilio Pozuelo Monfort-4
On 02/02/18 13:14, James Cowgill wrote:

> Hi,
>
> On 11/01/18 20:16, Emilio Pozuelo Monfort wrote:
>> On 17/11/17 13:25, James Cowgill wrote:
>>> Hi,
>>>
>>> On 15/11/17 17:30, Emilio Pozuelo Monfort wrote:
>>>> Source: rustc
>>>> Version: 1.21.0+dfsg1-3
>>>> Severity: important
>>>>
>>>> Hi,
>>>>
>>>> Sometime ago I asked about rustc bootstrap status on mips*:
>>>>
>>>> 17:08 < infinity0> mips* fail many tests last time i tried, ~3 months ago, i didn't want to ship it, i haven't had time to check since
>>>>
>>>> >From https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips&ver=1.14.0%2Bdfsg1-3&stamp=1484077706&raw=0
>>>>
>>>> test net::tcp::tests::timeouts ... FAILED
>>>> test net::udp::tests::timeouts ... FAILED
>>>> test sys::imp::ext::net::test::timeouts ... FAILED
>>>>
>>>> Looks like timeouts are broken on rust/mips?
>>>>
>>>> mips64el has different errors:
>>>>
>>>> test f32::f32::tanh_0 ... FAILED
>>>> test f64::f64::tanh_0 ... FAILED
>>>> test io::error::Error::from_raw_os_error_0 ... FAILED
>>>>
>>>> Maybe the mips porters can take a look? (debian-mips@ on Cc). Note those
>>>> errors are for 1.14.0, you'll want to try with a newer version first and
>>>> see what's the current status.
>>>
>>> I just tried building the latest rustc on mips64el. As I expected, I hit
>>> this LLVM bug again where any code using atomics will hang:
>>>
>>> https://bugs.llvm.org/show_bug.cgi?id=32020
>>>
>>> I'll see if I can get Simon to have a look at it again.
>>
>> FTR:
>>
>> According to our conversation over IRC, there's a patch for the above bug, but
>> mips64el is now affected by https://github.com/rust-lang/rust/issues/47290
>>
>> mips(el) may be fine now with that patch, or they may not :P
>
> I have been looking at the state of rust support on mips over the last
> weeks or so. These are the major issues:
>
> Hanging atomics (mips, mipsel, mips64el)
> ====
> This is an LLVM bug which happens on all mips.
>
> https://github.com/rust-lang/rust/issues/39013
> https://bugs.llvm.org/show_bug.cgi?id=32020
>
> I have attached the most recent iteration of Simon's LLVM fix for this
> along with some of my adjustments to it and a backport to LLVM 4.0 I
> used for testing with rust.
>
> LLVM 128-bit integer isues (mips, mipsel)
> ====
> 128-bit integer arithmetic is broken in LLVM 4 on 32-bit MIPS. This has
> been fixed in LLVM 5. Unfortunately this bug has caused the upstream
> stage0 compiler to break badly so you may need to apply the fix and
> cross build your own stage0 until upstream binaries have moved to LLVM >= 5.
>
> https://github.com/rust-lang/rust/issues/41222
> https://bugs.llvm.org/show_bug.cgi?id=32713
> https://reviews.llvm.org/rL305389
>
> llvm.powi.f64 broken (mips64el)
> ====
>>>> test f32::f32::tanh_0 ... FAILED
>>>> test f64::f64::tanh_0 ... FAILED
>
> This is caused by the llvm.powi.f64 intrinsic being broken for negative
> powers. Thankfully this is not a very serious bug.
>
> Fixed here:
> https://bugs.llvm.org/show_bug.cgi?id=36061
> https://reviews.llvm.org/D42537
>
> No 64-bit Rust ABI support (mips64el)
> ====
> The biggest issue with Rust itself is the lack of working FFI support
> for 64-bit mips.
>
> My attempt at implementing this:
> https://github.com/rust-lang/rust/issues/47290
> https://github.com/rust-lang/rust/pull/47964
>
> Other issues
> ====
>>>> test net::tcp::tests::timeouts ... FAILED
>>>> test net::udp::tests::timeouts ... FAILED
>>>> test sys::imp::ext::net::test::timeouts ... FAILED
>
> As I wrote in https://github.com/rust-lang/rust/issues/39013, these are
> big endian specific. I haven't had the chance to test rust on big endian
> yet.
>
>>>> test io::error::Error::from_raw_os_error_0 ... FAILED
>
> Fixed in https://github.com/rust-lang/rust/pull/47874
>
> Some FPU errors only happen on Loongson. In theory, enabling FPXX in
> LLVM should have fixed this, but I have not investigated it very far.
>
> There are a few other failing tests where the test itself is broken. I
> will try to submit fixes to ignore / adjust the tests soon.

Any progress on these issues? I see that rust built on mips64el but it now
hangs. And mips/el are still uncompiled.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
On 05/28/2018 08:52 AM, Emilio Pozuelo Monfort wrote:
> Any progress on these issues? I see that rust built on mips64el but it now
> hangs. And mips/el are still uncompiled.

I have not been able to build rustc natively on mips/mipsel because the process
always runs out of memory when I try on minkus and eller.

I tried the workaround from [1] to disable debuginfo for the standard library
but that didn't help either.

Adrian

> [1] https://github.com/rust-lang/rust/issues/45854

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures

Emilio Pozuelo Monfort-4
Hi Adrian,

On 28/05/18 10:33, John Paul Adrian Glaubitz wrote:
> On 05/28/2018 08:52 AM, Emilio Pozuelo Monfort wrote:
>> Any progress on these issues? I see that rust built on mips64el but it now
>> hangs. And mips/el are still uncompiled.
>
> I have not been able to build rustc natively on mips/mipsel because the process
> always runs out of memory when I try on minkus and eller.
>
> I tried the workaround from [1] to disable debuginfo for the standard library
> but that didn't help either.

Ok. I wonder if there are other options for us here. At what point does it run
out of memory? Do you have a log?

BTW mips64el is failing to build on the buildds. It only built there once, on
eberlin. Is that the only mips64el buildd with an FPU? That could explain the
timeouts.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
On 07/15/2018 12:33 PM, Emilio Pozuelo Monfort wrote:
> Ok. I wonder if there are other options for us here. At what point does it run
> out of memory? Do you have a log?

I don't have a log, unfortunately, because I'm always building on eller or
minkus where I cannot use sbuild but just run dpkg-buildpackage directly. I
can, however, run the output through "tee" to get a logfile.

The error looked very similar to the one we have seen on 32-Bit ARM targets,
see [1]. The same workaround used for arm* in the debian/rules file didn't
help on mips* though.

> BTW mips64el is failing to build on the buildds. It only built there once, on
> eberlin. Is that the only mips64el buildd with an FPU? That could explain the
> timeouts.

No idea. I just know there is apparently still a bug in the atomics code
on mips* in LLVM, see [2].

Adrian

> [1] https://github.com/rust-lang/rust/issues/45854
> [2] https://bugs.llvm.org/show_bug.cgi?id=32020

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Ximin Luo-5
In reply to this post by Emilio Pozuelo Monfort-4
Emilio Pozuelo Monfort:
> [..]
>
> Ok. I wonder if there are other options for us here.

As the main rust maintainer IMO it's best to just RM the mips binaries so that testing migration works again. The LLVM bug on mips has been fixed recently with an insanely large patch, so it will eventually get in, but unless someone wants to spend their own time backporting it, mips is going to continue to fail and there's really no point keeping on trying to build it.

Please RM it so other architectures get into Debian testing. We can try again later when the patch lands in LLVM.

X

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

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz


> On Jul 15, 2018, at 4:53 PM, Ximin Luo <[hidden email]> wrote:
>
> Please RM it so other architectures get into Debian testing. We can try again later when the patch lands in LLVM.

No need to reject, the packages already got rejected.

Also, if there is a patch for LLVM to backport, I can do that, I have commit access.

After that, I would start with mips64el first to avoid the memory issues.

Adrian
Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Aron Xu-3
In reply to this post by Ximin Luo-5
On Sun, Jul 15, 2018 at 11:18 PM Ximin Luo <[hidden email]> wrote:

>
> Emilio Pozuelo Monfort:
> > [..]
> >
> > Ok. I wonder if there are other options for us here.
>
> As the main rust maintainer IMO it's best to just RM the mips binaries so that testing migration works again. The LLVM bug on mips has been fixed recently with an insanely large patch, so it will eventually get in, but unless someone wants to spend their own time backporting it, mips is going to continue to fail and there's really no point keeping on trying to build it.
>
> Please RM it so other architectures get into Debian testing. We can try again later when the patch lands in LLVM.
>

As a temporary solution to unblock, I've built the package on a
loongson-3a box and uploaded. It is the same hardware as eberlin.d.o,
which in turn suggests this could be related to Cavium hardware.

Cheers,
Aron

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
On 07/17/2018 02:29 PM, Aron Xu wrote:
> As a temporary solution to unblock, I've built the package on a
> loongson-3a box and uploaded. It is the same hardware as eberlin.d.o,
> which in turn suggests this could be related to Cavium hardware.

Unless DSA is willing to blacklist the rustc package on the buildd hardware
where it doesn't build (if that's actually the case), this won't work and
will cause the package to FTBFS if it hits the wrong buildd.

For Debian Ports, this would be acceptable. Don't know about release architectures
though. The policy could be different there.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Aron Xu-3
On Tue, Jul 17, 2018 at 10:36 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:

>
> On 07/17/2018 02:29 PM, Aron Xu wrote:
> > As a temporary solution to unblock, I've built the package on a
> > loongson-3a box and uploaded. It is the same hardware as eberlin.d.o,
> > which in turn suggests this could be related to Cavium hardware.
>
> Unless DSA is willing to blacklist the rustc package on the buildd hardware
> where it doesn't build (if that's actually the case), this won't work and
> will cause the package to FTBFS if it hits the wrong buildd.
>
> For Debian Ports, this would be acceptable. Don't know about release architectures
> though. The policy could be different there.
>

Binary only upload from porter is allowed but not encouraged, it works
similar to an initial upload with source+binary. As said this is
temporary, blacklisting is needed and we are just relaxing Rust
maintainers from being worried too much about migration.

Cheers,
Aron

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Aron Xu-3
In reply to this post by John Paul Adrian Glaubitz
On Tue, Jul 17, 2018 at 10:36 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:

>
> On 07/17/2018 02:29 PM, Aron Xu wrote:
> > As a temporary solution to unblock, I've built the package on a
> > loongson-3a box and uploaded. It is the same hardware as eberlin.d.o,
> > which in turn suggests this could be related to Cavium hardware.
>
> Unless DSA is willing to blacklist the rustc package on the buildd hardware
> where it doesn't build (if that's actually the case), this won't work and
> will cause the package to FTBFS if it hits the wrong buildd.
>
> For Debian Ports, this would be acceptable. Don't know about release architectures
> though. The policy could be different there.
>

Want to add that, on Debian Ports porters are allowed to include some
trivial patches to make the package build/useful, while what I have
done is a binary-only build without any source package change.

Regards,
Aron

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
In reply to this post by Aron Xu-3
On 07/17/2018 04:43 PM, Aron Xu wrote:
> Binary only upload from porter is allowed but not encouraged, it works
> similar to an initial upload with source+binary.

Yes, I am fully aware how that works. I am a very active porter :).

> As said this is temporary, blacklisting is needed and we are
> just relaxing Rust maintainers from being worried too much
> about migration.

And you are missing an important part. The next time a new version
of rustc gets upload, the package can end up on the wrong buildd
and fail to build from source meaning that testing migration will
be stuck. This is what my original mail was about.

Unless you actively blacklist rustc from being built on the affected
buildds through the buildds local configuration file, your workaround
will not work.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
In reply to this post by Aron Xu-3
On 07/17/2018 04:45 PM, Aron Xu wrote:
> Want to add that, on Debian Ports porters are allowed to include some
> trivial patches to make the package build/useful, while what I have
> done is a binary-only build without any source package change.

Aron, with all due respect:

1) You assume I don't know how any of this works even though I have
   probably done much more in this field in Debian than you.

2) I don't think you understand what the actual problem is here.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Aron Xu-3
On Tue, Jul 17, 2018 at 10:48 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:

>
> On 07/17/2018 04:45 PM, Aron Xu wrote:
> > Want to add that, on Debian Ports porters are allowed to include some
> > trivial patches to make the package build/useful, while what I have
> > done is a binary-only build without any source package change.
>
> Aron, with all due respect:
>
> 1) You assume I don't know how any of this works even though I have
>    probably done much more in this field in Debian than you.
>
> 2) I don't think you understand what the actual problem is here.
>

I think you are too much defensive, while I don't mean offensive any how.

The thing to fix this forever is either of:
1) Fix the software to make it build on all hardware;
2) Blacklist the package on hardware that fails to build it.

You are just blaming blindly here, and this will be my last response
to you on this very specific argument.

Have a nice day,
Aron

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
On 07/17/2018 04:51 PM, Aron Xu wrote:
> I think you are too much defensive, while I don't mean offensive any how.

Maybe you shouldn't automatically assume then that the other person
doesn't know what they are talking about?

> The thing to fix this forever is either of:
> 1) Fix the software to make it build on all hardware;
> 2) Blacklist the package on hardware that fails to build it.
>
> You are just blaming blindly here, and this will be my last response
> to you on this very specific argument.
Neither 1) nor 2) have happened, yet you decided to upload the
package to unstable. Did you check back with the rust maintainers?

rustc and cargo were already uploaded for mips64el and later removed
because of the LLVM bug which made the package FTBFS on the buildds.
I don't understand why you just went ahead and uploaded the package
without seemingly checking back with the Rust maintainers.

(Cross-)building and uploading rustc for a new architecture is not
hard. Making the native compuiler actually work properly, on the
other hand, is.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Ximin Luo-5
John Paul Adrian Glaubitz:

> On 07/17/2018 04:51 PM, Aron Xu wrote:
>> I think you are too much defensive, while I don't mean offensive any how.
>
> Maybe you shouldn't automatically assume then that the other person
> doesn't know what they are talking about?
>
>> The thing to fix this forever is either of:
>> 1) Fix the software to make it build on all hardware;
>> 2) Blacklist the package on hardware that fails to build it.
>>
>> You are just blaming blindly here, and this will be my last response
>> to you on this very specific argument.
> Neither 1) nor 2) have happened, yet you decided to upload the
> package to unstable. Did you check back with the rust maintainers?
>
> rustc and cargo were already uploaded for mips64el and later removed
> because of the LLVM bug which made the package FTBFS on the buildds.
> I don't understand why you just went ahead and uploaded the package
> without seemingly checking back with the Rust maintainers.
>
> (Cross-)building and uploading rustc for a new architecture is not
> hard. Making the native compuiler actually work properly, on the
> other hand, is.
>

Aron, the next version 1.27.1 is already in binary-NEW so the same issue will block testing migration again, when that gets accepted.

Earlier you said "Binary only upload from porter is allowed [..]" but I am not sure the other porters have access to a loongson-3a box. Will you continue to run builds of new rustc versions on your box? I think that is the key point here.

X

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

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Aron Xu-3
On Wed, Jul 18, 2018 at 12:04 AM Ximin Luo <[hidden email]> wrote:

>
> John Paul Adrian Glaubitz:
> > On 07/17/2018 04:51 PM, Aron Xu wrote:
> >> I think you are too much defensive, while I don't mean offensive any how.
> >
> > Maybe you shouldn't automatically assume then that the other person
> > doesn't know what they are talking about?
> >
> >> The thing to fix this forever is either of:
> >> 1) Fix the software to make it build on all hardware;
> >> 2) Blacklist the package on hardware that fails to build it.
> >>
> >> You are just blaming blindly here, and this will be my last response
> >> to you on this very specific argument.
> > Neither 1) nor 2) have happened, yet you decided to upload the
> > package to unstable. Did you check back with the rust maintainers?
> >
> > rustc and cargo were already uploaded for mips64el and later removed
> > because of the LLVM bug which made the package FTBFS on the buildds.
> > I don't understand why you just went ahead and uploaded the package
> > without seemingly checking back with the Rust maintainers.
> >
> > (Cross-)building and uploading rustc for a new architecture is not
> > hard. Making the native compuiler actually work properly, on the
> > other hand, is.
> >
>
> Aron, the next version 1.27.1 is already in binary-NEW so the same issue will block testing migration again, when that gets accepted.
>
> Earlier you said "Binary only upload from porter is allowed [..]" but I am not sure the other porters have access to a loongson-3a box. Will you continue to run builds of new rustc versions on your box? I think that is the key point here.
>

Will do that and see if we can get the issue either fixed or have a
blacklist placed at the same time.

Cheers,
Aron

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

John Paul Adrian Glaubitz
In reply to this post by Ximin Luo-5
On 07/17/2018 06:03 PM, Ximin Luo wrote:
> Aron, the next version 1.27.1 is already in binary-NEW so the same issue will block testing migration again, when that gets accepted.

Well, I have to partially take my criticism back. Aron has pointed out on IRC
that rustc was not yet removed for mips64el, I thought that had happened but
indeed that wasn't the case, just cargo was removed.

So, his upload didn't really change anything in this regard.

> Earlier you said "Binary only upload from porter is allowed [..]" but I am not sure the other porters have access to a loongson-3a box. Will you continue to run builds of new rustc versions on your box? I think that is the key point here.

DSA could blacklist rustc from being built on buildds other than eberlin
but I assume they won't agree to applying such a hack.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

Ximin Luo-5
In reply to this post by Aron Xu-3
Aron Xu:

> [..]
>>
>> Aron, the next version 1.27.1 is already in binary-NEW so the same issue will block testing migration again, when that gets accepted.
>>
>> Earlier you said "Binary only upload from porter is allowed [..]" but I am not sure the other porters have access to a loongson-3a box. Will you continue to run builds of new rustc versions on your box? I think that is the key point here.
>>
>
> Will do that and see if we can get the issue either fixed or have a
> blacklist placed at the same time.
>

I have just uploaded 1.29.0 to unstable. It will need manual building with a non-buggy mips machine, to unblock us for Debian Testing. The previous build 1.29.0+dfsg1-1~exp1 failed due to hanging atomic tests:

https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=mips64el&ver=1.29.0%2Bdfsg1-1%7Eexp1&stamp=1537686627&raw=0

test sync.rs - sync::Arc (line 124) ... test sync.rs - sync::Arc (line 124) has been running for over 60 seconds
test sync.rs - sync::Arc<T>::downgrade (line 418) ... test sync.rs - sync::Arc<T>::downgrade (line 418) has been running for over 60 seconds
test sync.rs - sync::Arc<T>::get_mut (line 856) ... test sync.rs - sync::Arc<T>::get_mut (line 856) has been running for over 60 seconds
test sync.rs - sync::Arc<T>::make_mut (line 769) ... test sync.rs - sync::Arc<T>::make_mut (line 769) has been running for over 60 seconds
E: Build killed with signal TERM after 150 minutes of inactivity

I still think we should just RM rustc on mips64el.

X

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

12