On Wed, Jul 18, 2018 at 12:04 AM Ximin Luo <infini...@debian.org> 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
