Shengjing Zhu <zhsj@debian.org> writes: > On Wed, Jan 24, 2024 at 10:56 PM Simon Josefsson <simon@josefsson.org> wrote: >> >> Shengjing Zhu <zhsj@debian.org> writes: >> >> > On Wed, Jan 24, 2024 at 7:30 PM Simon Josefsson <simon@josefsson.org> wrote: >> >> Shengjing Zhu, what do you think, can we request removal of this package >> >> from unstable? >> >> >> > >> > Why would you bother with packages that are only in unstable? >> > I'm not sure how best to handle removal for team maintained packages. >> > I'm not the one who introduced this package. It's just a leaf package. >> > So leave it in unstable and if someone wants to pick it up, they don't >> > need to go through the NEW queue. >> > Previously I only requested removal of some team maintained packages >> > that upstream are gone, and I'm pretty sure they will not be used any >> > more. >> >> Okay, I understand. It makes it a bit hard to tell if a new version of >> a package that cadvisor depends on causes the build failure or if it was >> there before. Maybe if a package already FTBFS then causing another >> FTBFS in it is not worth checking for. >> >> Perhaps we can just collectively establish a list of packages that we no >> longer care about as a team, and cadvisor seems to be one, and not let >> problems with it stop progress on other packages. > > IMO, it's well established, not only for go-team, packages that are > not in testing wouldn't block others. That is true! So that covers 'cadvisor' and 'gitlab-ci-multi-runner'. Next example of such a packages is 'crowdsec'. It happens to be both in testing and unstable, and it has a FTBFS bug filed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057549 Should we ignore 'crowdsec' too when checking builds of reverse dependencies? At least in this example, with an updated 'golang-opentelemetry-otel' package it causes the same FTBFS problem in 'crowdsec', but confirming it is the same FTBFS for each build takes some resources. /Simon
Attachment:
signature.asc
Description: PGP signature