Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
On 3/21/24 11:47 AM, Ian Jackson wrote:
Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and 1
more messages]"):
Steve, could you please do this for *all* the time_t transition RC
bugs?
IMO things are currently ON FIRE.
Exaggeration is an art.
If no-one else has put this fire out by 24h from now, I will attempt
to find which are the relevant bugs and downgrade them all.
The time-t usertag of debian-...@lists.debian.org is your friend.
I've downgraded all the closed "NMU diff for 64-bit time_t transition"
bugreports with serious severity to important and usertagged them as
requested by elbrus.
There are still 19 serious "NMU diff for 64-bit time_t transition"
bugreports that aren't closed, 60 serious bugreports that aren't "NMU
diff for 64-bit time_t transition" ones, and 21 serious bugreports that
are pending upload. I'll leave dealing with these bugreports to someone
else.
I personally wouldn't mind seeing armel & armhf in the britney
OUTOFSYNC_ARCHES to unblock testing migration for the 64 bit
architectures until they've caught up, but this may be a bit of a dick
move towards the ARM porters.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
On Thu, Mar 21, 2024 at 10:47:21AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug?
> [and 1 more messages]"):
> > Steve, could you please do this for *all* the time_t transition RC
> > bugs?
> IMO things are currently ON FIRE.
I'd rather call it a very large smoldering fire, so far. ;)
> If no-one else has put this fire out by 24h from now, I will attempt
> to find which are the relevant bugs and downgrade them all.
I've sent a few contentless pings today to some of those bugs today,
which will keep the smoldering fire smoldering (=delay autoremovals
further). I agree that is far from ideal, but as I understand things,
it's better than possibly letting such buggy packages migrate *to* testing.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
I don't want to see your smile.
I want to see your intelligence, compassion, integrity, and consideration.
(@1goodtern)
signature.asc
Description: PGP signature
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and
1 more messages]"):
> Steve, could you please do this for *all* the time_t transition RC
> bugs?
IMO things are currently ON FIRE.
If no-one else has put this fire out by 24h from now, I will attempt
to find which are the relevant bugs and downgrade them all.
Ian.
--
Ian JacksonThese 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.
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Hi! On Tue, 2024-03-19 at 10:32:04 +, Ian Jackson wrote: > [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. Just to clarify, I've now closed that report as I mentioned I'd be doing, but this will have no effect, because dpkg and gcc-* are not migrating primarily because they are being used by the release team to gate the transition, to avoid having them get into testing and potentially then getting things to build with the wrong ABI there > The logic of the autoremoval system is that as an affected maintainer > I ought to go and involve myself with #1066952. Perhaps the release team blocks should be listed more prominently at the beginning of the tracker page and perhaps be somewhat linkified (I'll file a report)? (Or maybe you got this information from somewhere else, which lacks that information or is also listed at the end?) Regards, Guillem
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Hi,
On 19-03-2024 11:32 a.m., Ian Jackson wrote:
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.
I was informed that time_t-downgrade isn't a valid usertag. Please use
time-t-downgrade instead.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
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 JacksonThese 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.
