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

YunQiang Su <[email protected]>
Newsgroups gmane.linux.debian.ports.mips
Message-ID <CAKcpw6URTq6vB1PO+WJizZ3LRgzWHA+GQaOwAScqJJMO6Oe2VQ@mail.gmail.com>
https://bugs.llvm.org/show_bug.cgi?id=32020
YunQiang Su <[email protected]> 于2018年9月28日周五 上午11:05写道:
>
> Ximin Luo <[email protected]> 于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 <[email protected]> 于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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.