Re: Confusion over t64 migration
On 2/10/24 13:40, Holger Levsen wrote: On Sat, Feb 10, 2024 at 12:16:48PM +, Holger Levsen wrote: I'm also of the opinion that *someone* should do this for all these bugs but I am too lazy to do it myself. sebas...@debian.org has thankfully done this, 15min before I wrote the above. Note that the severity was only downgraded for the "NMU diff for 64-bit time_t transition" bugreports, there are still a few serious ones left: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=time-t#_0_2_2 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=time-t#_0_2_4 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Confusion over t64 migration
On Sat, Feb 10, 2024 at 12:16:48PM +, Holger Levsen wrote: > I'm also of the opinion that *someone* should do this for all these bugs > but I am too lazy to do it myself. sebas...@debian.org has thankfully done this, 15min before I wrote the above. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Der Mensch is' gut, aber die Leut' san a G'sindel! signature.asc Description: PGP signature
Re: Confusion over t64 migration
On Fri, Feb 09, 2024 at 10:01:06AM -0600, John Goerzen wrote: > So at the moment, I am unclear why there are bugs filed with severity > serious that apparently cannot be fixed. Shouldn't they be normal with > a tag wontfix until the relevant dpkg changes are in unstable? I've downgraded those in packages I care about to "important" once the autoremoval mail arrived. I'm also of the opinion that *someone* should do this for all these bugs but I am too lazy to do it myself. > To put it another way, I'm not seeing why we are reporting RC bugs > against a bunch of packages before it is possible to fix them. indeed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The people who refer to the pandemic in the past tense and climate change in the future tense are the reason everything is going to shit. signature.asc Description: PGP signature
Can we switch off the testing removal messages related to t64 migration? (Was: Confusion over t64 migration)
Hi, Am Fri, Feb 09, 2024 at 06:46:58PM +0100 schrieb Andreas Metzler: > Looking at "your" bug #1062097 it looks like you were unlucky, mine all > had a fat warning "NOTICE: these changes must not be uploaded to > unstable yet!". I also was trapping into that pitfall when I was intending to fix an RC bug quickly and simply failed to read the whole message. Just happens and was reverted soon. > There was a little bit of discussion about the delay on > https://lists.debian.org/debian-release/2024/02/msg00272.html but it > has not yielded a plan yet. I perfectly understand that complex things might lead to delays. However, given that I'm in several teams with lots of libraries my mailbox gets filled with lots of messages about testing removals which are absolutely useless since I can't do anything about this. I wonder how we can get rid of these messages. Two things come into my mind: 1. Demote severity of the time_t related bugs to non-RC 2. Patch the script that sends testing removal warnings to ignore time_t related bugs It would be very convinient if this could be solved. Currently I simply remove all mails containing the pattern "testing removal" since I can't handle the current amount sensibly. Unfortunately that way I'm missing perfectly valid messages caused by "real" RC bugs. Just using the chance to thank all people working on time_t transition and release team for the generally helpful mails Andreas. -- http://fam-tille.de
Re: Confusion over t64 migration
On 2024-02-09 John Goerzen wrote: [...] > So at the moment, I am unclear why there are bugs filed with severity > serious that apparently cannot be fixed. Shouldn't they be normal with > a tag wontfix until the relevant dpkg changes are in unstable? > To put it another way, I'm not seeing why we are reporting RC bugs > against a bunch of packages before it is possible to fix them. [...] Hello John, Afaiui the transition has been delayed unexpectly. (#1063329). I *think* the priority was also chosen as signal to avoid unstable uploads for the already staged packages. Stuff should have happened quickly, before we entered the autoremoval timer. Looking at "your" bug #1062097 it looks like you were unlucky, mine all had a fat warning "NOTICE: these changes must not be uploaded to unstable yet!". There was a little bit of discussion about the delay on https://lists.debian.org/debian-release/2024/02/msg00272.html but it has not yielded a plan yet. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Confusion over t64 migration
Hi everyone, Thanks to all that have put so much time and thought into the time_t migration. I am late to this party and am trying to figure my way through it. Quite a few of my packages are marked for removal from testing because time_t migration bugs have been filed with severity serious. Some of these are filed against my own packages, but most are filed against other packages which are dependencies of ones I maintain. I am an uploader for gensio, which had a bug #1062097 reported for this issue. Like the others, it was reported as severity serious, tagged found in the version in unstable. This, of course, prevents migrations to testing and also leads to removals from testing. I uploaded a package with the enclosed patch quickly, but then was told that was not the right thing to do. I then uploaded a new version of gensio with the change removed... but again (and I'm not even sure how this is the case, since the bug was resolved) it is marked for autoremoval from testing. So at the moment, I am unclear why there are bugs filed with severity serious that apparently cannot be fixed. Shouldn't they be normal with a tag wontfix until the relevant dpkg changes are in unstable? To put it another way, I'm not seeing why we are reporting RC bugs against a bunch of packages before it is possible to fix them. A key use case for me is uploading to bookworm-backports. Of course, that requires being in testing first. What will happen with time_t in bookworm-backports? Thanks! - John
