On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort <po...@debian.org> wrote: > On 22/03/2020 12:34, Emilio Pozuelo Monfort wrote: > > On 22/03/2020 08:33, László Böszörményi (GCS) wrote: > >> Thanks, uploaded. Built on all primary architectures and on secondary > >> ones that have ruby2.7 - only sparc64 regressed if that's the correct > >> phrase as it fails with "fatal error: error writing to > >> /tmp/ccC8qVCe.s: No space left on device". Package grpc also built on > >> all primary architectures. Built on an other sparc64 buildd with more disk space successfully. Hurd is a question. I've seen it stuck on 'Maybe-Successful' and checking the buildd log it was compiled correctly. Now someone initiated a binNMU and the buildd is stuck with it for five hours now (normal build time is around thirty minutes on Hurd).
> Things seem to be in a good shape, except for astroidmail which needs an > upload > from experimental as you said, and protobuf itself which is failing its > autopkgtests: > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/protobuf/4635215/log.gz Meanwhile astroidmail went 'sid only' as its RC bug made it removed from testing. Fixed autopkgtests in my latest upload looking for its results on the buildd network. An other question is opencv as in the transition tracker its marked unknown status (?) as '?!'. Manually checking its binNMU logs reveals it built correctly on all supported architectures. Previously mentioned under-maintained packages ignition-msgs and ignition-transport: these build correctly but their autopkgtests are failing. What should be done with packages that have 1.0.0 vs 5.0.0 and 4.0.0 vs 8.0.0 versions in the Debian archives vs upstream latest stable release. May these be removed from testing until their DM update the packages? No point on keeping these for the next Debian release as is. Cheers, Laszlo/GCS