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?
Hi Paul, Am Fri, Mar 15, 2024 at 09:52:06PM +0100 schrieb Paul Gevers: > For bookkeeping purposes, please usertag downgraded bugs with user > release.debian@packages.debian.org and usertag time_t-downgrade. > > Please be careful with downgrading RC bugs. I agree with Ian that it might make sense that Steve, who probably has a complete list of the bugs, can do this more safely than individual maintainers. (BTW, thanks again to Steve for doing all the work.) I think this migration has shown another problem which was not yet dicussed here. In Debian Med and R pkg team we identified packages where a time_t transition would be a) complex (there was no patch provided by time_t people) b) not helpful for users since usage on 32bit is probably zero Thus we considered it a good idea to remove 32bit architectures of those packages and its dependencies. This has shown that removing packages is a similarly time consuming way of dealing with this. The method to file individual bug reports for every single package on the side of the maintainer as well as dealing with the actual removal done by ftpmaster is quite inefficient. The removal bug for emboss[1] was filed six weeks ago (1 Feb 2024) and countless testing removal warnings were sent to the maintainer list since it is not fixed until now. Even worse for r-bioc-rhtslib[2] which had quite a tree of rdepends and kept several people (including ftpmaster) busy. Please understand me correctly: It is not blaming ftpmaster to be slow with ROM requests. Maybe I could have adjusted severity somehow - I just don't know any documentation what is appropriate or not. I made mistakes myself when filing ROM bugs against rdepends. My point is: I as a maintainer have control about what is inside the pool. But once a package is there I have a hard time to get it removed again. This does not make sense. We have tools who can generate a dependency tree. So filing separate bugs on one hand and deal with separate bugs on the other hand is somehow a rudiment from last century. I wished we could solve this more elegantly. Kind regards Andreas. [1] https://bugs.debian.org/1062371 [2] https://bugs.debian.org/1063376 -- http://fam-tille.de
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.
Re: Package marked for autoremoval due to closed bug?
Hi zigo, On 16-03-2024 12:31 a.m., Thomas Goirand wrote: But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I'm not aware that we reduced autoremoval times in recent history. Are you maybe confusing it with the time needed for packages to be out-of-sync [1]? That still requires someone (me) to file RC bugs and I have stopped doing that during this transition exactly to avoid autoremoval while the transition is in progress. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 07:14, Andreas Tille wrote: I simply remove all those testing removal warnings in my mailbox to cope with this and by doing so I'm probably missing real issues I should rather care about. I know what you're talking about: anyone that maintains a lot of packages always receive waves of multiple dozens of email, and often, it's hardly actionable. Then I just end up ignoring them, hoping the fix is already under way by the person in charge of that new dependency I never heard of before. I hope one day, someone will have the skill/time/courage to refactor these messages into something humanly readable. One message per day per DD, with a summary of the possible AUTORM pointing at the list of RC bugs with links, would be a way more useful than ONE message per package, for example. Thanks to all who are involved in this complex migration Yeah, +1 Thomas Goirand (zigo)
Re: Package marked for autoremoval due to closed bug?
On 3/15/24 21:52, Paul Gevers wrote: Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: 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? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul Hi Paul, I leave this to your own judgement, of course (with your "release team hat"). But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I didn't dare to express myself about it at the time, as maybe you knew better. My thinking was: after all, people should fix their bugs, no? Plus release team people must know better... But after a few months with the shorter AUTORM period, my opinion is growing firmer: the previous one (whatever it was) seemed more appropriate to me with the way Debian is being developed (ie: largely by volunteers on their free time), and for those of us in charge of maintaining a long (and sometimes complicated) chain of dependencies. Now, with this type of (breaking) transition, would growing back the AUTORM period (to what it used to be) help? Or are you still in the opinion making it shorter was a good move? Your thoughts? Cheers, Thomas Goirand (zigo)
Re: Package marked for autoremoval due to closed bug?
Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: 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? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug?
Am Thu, Mar 14, 2024 at 10:15:18PM -0700 schrieb Steve Langasek: > > 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? I'm in favor of important severity for those bugs maintainer can't do anything about. It creates a lot of noise with testing removal warnings. I simply remove all those testing removal warnings in my mailbox to cope with this and by doing so I'm probably missing real issues I should rather care about. Thanks to all who are involved in this complex migration Andreas. -- http://fam-tille.de
Re: Package marked for autoremoval due to closed bug?
On Fri, Mar 15, 2024 at 05:03:55AM +, Scott Kitterman wrote: > On March 15, 2024 3:54:05 AM UTC, Steven Robbins wrote: > >According to the "action needed" section for nifticlib [1], it is: > >Marked for autoremoval on 31 March: #1063178 > >But that bug is fixed for the version in unstable. > >Why does that cause the package to be removed? > >[1] https://tracker.debian.org/pkg/nifticlib > Because the bug still exists in Testing. Once the package in Unstable > migrates, all is well. 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? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Package marked for autoremoval due to closed bug?
On March 15, 2024 3:54:05 AM UTC, Steven Robbins wrote: >According to the "action needed" section for nifticlib [1], it is: > >Marked for autoremoval on 31 March: #1063178 > >But that bug is fixed for the version in unstable. >Why does that cause the package to be removed? > >[1] https://tracker.debian.org/pkg/nifticlib Because the bug still exists in Testing. Once the package in Unstable migrates, all is well. Scott K
