Bug#954391: transition: protobuf
On Mon, Mar 23, 2020 at 10:16 AM Emilio Pozuelo Monfort
<pochu@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
Reply to: