Steve Langasek writes ("Re: Package marked for autoremoval due to closed bug?"): > Migration to testing is largely out of control of the maintainers at this > point, it's very much dependent on folks rebootstrapping armel and armhf > against the new library names. Should these bugs be downgraded again to > important severity?
Yes. It seems we have consensus on this. Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"): > For bookkeeping purposes, please usertag downgraded bugs with user > release.debian....@packages.debian.org and usertag time_t-downgrade. Rather than every maintainer affected by unactionable autoremoval warnings[1][2] doing this by hand: Steve, could you please do this for *all* the time_t transition RC bugs? That will reduce the scope for individual slips and mistakes, fulfilling Paul's request: > Please be careful with downgrading RC bugs. [1] IMO unactionable autoremoval warnings are extremely undesirable. The autoremoval system has two purposes: one is to get rid of things that are in the way of other work, or just rotten. Another is to spur action where action is needed. Action by a responsible maintainer, or failing that by anyone else. An unactionable autoremoval warning represents, at best, a robot shouting at a human to do something that cannot be done. That can lead to many humans from afar all turning up being confuseed at the same problem trying to "help" (or at least, to try to stop the screaming). If the autoremovals were to actually occur, it would be automated destruction of non-broken stuff. To preserve autorm's usefulness, unactionable autoremoval warnings must be very rare. In this situation, Debian's processes have failed to ensure this, and there hasn't been an effective backstop. I suggest that when a widely-applicable problem is generating unactionable autoremovals, the whole autoremoval system should be suspended. The problem is particularly severe when an underlying cause is that some package, which contains the underlying RC bugfix, isn't migrating. This seems to be becoming more common. [2] In my case src:dgit depends on git-buildpackage. The autoremoval robot wants to remove git-buildpackage because of the time_t bugs against rpm, xdelta, and pristine-tar. One root cause is that src:dpkg isn't migrating because of #1066952. The logic of the autoremoval system is that as an affected maintainer I ought to go and involve myself with #1066952. And all of this is nonsense since surely we're not going to autorm git-buildpackage, but right now we have a giant klaxon saying that's what's going to happen. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.