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

[YunQiang Su]

https://bugs.llvm.org/show_bug.cgi?id=32020
YunQiang Su <wzssyqa at gmail.com> 于2018年9月28日周五 上午11:05写道：
>
> Ximin Luo <infinity0 at debian.org> 于2018年9月27日周四 下午12:06写道：
> >
> > Ximin Luo:
> > > Do you have a link to a more detailed description of the problem, so that the rest of us can understand it?
> > >
> > > For example James in message 29 gave a very detailed summary of other previous problems:
> > >
> > > [29] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845#29
> > >
> > > Nobody in this thread has stated what the supposed problem actually is with these Cavium/Octeon machines. FYI the builds failed recently on eberlin and manda-03, and has failed in the past on aql-01. These are all octeon, and the other mips64el buildd sil-01 is also octeon. So it seems all our buildds are affected by the bug. So the blacklist approach won't even work.
> > >
> >
> > Oh I take that back, it seems aql-01 and manda-01,02 are not octeon, I had previously assumed all the x-{01..03} machines would be the same.
> >
> > Still, please give us a link to the description of the problem.
>
> I cannot remember clear.
> It seems that no branch instruction can be in ll/sc pair on Octeon,
> while llvm does generate code like this.
>
> Loongson has no this problem. anyway, we should patch llvm.
>
>
> >
> > X
> >
> > > Also unless I can understand the problem, I don't feel happy using the blacklist as a temporary solution, even if it was going to work.
> > >
> > > X
> > >
> > > YunQiang Su:
> > >> It is still about llvm+octeon problem.
> > >>
> > >> Maybe we can ask pin rustc on Loongson machines.
> > >> Ximin Luo <infinity0 at debian.org> 于2018年9月24日周一 上午2:21写道：
> > >>>
> > >>> 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
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > GPG: ed25519/56034877E1F87C35
> > GPG: rsa4096/1318EFAC5FBBDBCE
> > https://github.com/infinity0/pubkeys.git
>
>
>
> --
> YunQiang Su



-- 
YunQiang Su