Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
Am 01.02.24 um 09:30 schrieb Steve Langasek: What is the rationale behind rising a bug report at 9:51pm my time and firing a *direct* NMU upload just 11min later (according to the time stamps from the emails)? There are 1200+ source packages that require NMUing and the Debian archive is a moving target. In the past 3 days the list of packages requiring uploads has been regenerated 3 times with changes each time due to archive removals, new sonames in unstable, etc. Churning through the list of 1200 packages is at this rate going to take at least a week (after 4 days we've gotten bugs filed and NMUs to experimental completed for less than 400 of the 1200 packages). It is not practical to leave a gap of any significant length of time between the filing of bugs in patches and the uploads to experimental. Then the text of the email that was raised against any package makes no real sense to me. Who should I reach out ASAP? In which time span. No sorry, I can't follow. And I still see no real reason for rushing now anything. We had other similar transitions that worked also without that rather rude behavior to me. And yes, unstable is a moving target, but that it is for more than 2 decades every day. So that's the normal case. There will be a pause between the uploads to experimental, and the uploads to unstable, which gives space for maintainer feedback while we run analysis against the contents of experimental with regards to usrmerge. That doesn't really helping me, as this set just pressure on me . Again, I've nothing against this technically, but the communication about what is happening and why this is happening is terrible as it just doesn't exit to me. This is an ABI change resulting from a change to compiler flags. You will see the diff includes no changes to upstream source. There is nothing to forward. Great, would be good if that was also communicated by the email. Since this has only been uploaded to experimental, I would expect this does not interfere with your CVE handling? Well, not directly, but at a time this all needs to get melt together. And this take time on my side as *I* need then to grab the other things manually to get this into the VCS. -- Regrads Carsten
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 07:45:57AM +0100, Carsten Schoenert wrote: > Hello Steve, > Am 31.01.24 um 21:59 schrieb Steve Langasek: > ... > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. > ^^ > > Although > > this package will be uploaded to experimental immediately, there will be a > > period of several days before we begin uploads to unstable; so if > > information > > becomes available that your package should not be included in the > > transition, > > there is time for us to amend the planned uploads. > I'm a bit puzzled and disappointed. > libcopap3 isn't a package that is within the QA group nor is it bit rotting. > What is the rationale behind rising a bug report at 9:51pm my time and > firing a *direct* NMU upload just 11min later (according to the time stamps > from the emails)? There are 1200+ source packages that require NMUing and the Debian archive is a moving target. In the past 3 days the list of packages requiring uploads has been regenerated 3 times with changes each time due to archive removals, new sonames in unstable, etc. Churning through the list of 1200 packages is at this rate going to take at least a week (after 4 days we've gotten bugs filed and NMUs to experimental completed for less than 400 of the 1200 packages). It is not practical to leave a gap of any significant length of time between the filing of bugs in patches and the uploads to experimental. There will be a pause between the uploads to experimental, and the uploads to unstable, which gives space for maintainer feedback while we run analysis against the contents of experimental with regards to usrmerge. > I as the uploader for libcoap have no chance to do any action on this bug > report! This behavior I'm not expecting within Debian. > What are the plans now with forwarding the underlying issue to upstream? > Upstream is very responsive and I've good contacts to the upstream authors, > but who is doing this work now? This is an ABI change resulting from a change to compiler flags. You will see the diff includes no changes to upstream source. There is nothing to forward. > I read the wiki page mentioned from the initial email again, also there I > can't find a written plan that would explain me why the bug reporting > together with a direct upload did happen. I see no plan there what will > happen on what time. > Why no usual muss bug filling did happen so groups and maintainers would > have some knowledge about these planned changes? BTW: I've no problem with > the technical thing what is happen, but I need to deal also with other > things too like a CVE fix for libcopa3. Since this has only been uploaded to experimental, I would expect this does not interfere with your CVE handling? -- 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: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
On 2024-02-01, Carsten Schoenert wrote: > What is the rationale behind rising a bug report at 9:51pm my time and > firing a *direct* NMU upload just 11min later (according to the time > stamps from the emails)? > I as the uploader for libcoap have no chance to do any action on this > bug report! This behavior I'm not expecting within Debian. > What are the plans now with forwarding the underlying issue to upstream? > Upstream is very responsive and I've good contacts to the upstream > authors, but who is doing this work now? I'm mostly a bystander here. But there is no underlying issue to forward to upstream. Ex. The debian toolchain has been changed on most 32bit architectures to produce different code if time-related types are involved. This involves doing a giant library transition involving a 4 digit number of source packages, and it will while the transition is ongoing, be a *nightmare* of crashes for anyone with a machine on one of the involved 32bit architectures, so it need to happen in a very short timeframe. We should just be happy that there is at least 4 people working in shifts around the clock trying to get this done in less than a week of calendar time. /Sune
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
Hello Steve, Am 31.01.24 um 21:59 schrieb Steve Langasek: ... Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. ^^ Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. I'm a bit puzzled and disappointed. libcopap3 isn't a package that is within the QA group nor is it bit rotting. What is the rationale behind rising a bug report at 9:51pm my time and firing a *direct* NMU upload just 11min later (according to the time stamps from the emails)? I as the uploader for libcoap have no chance to do any action on this bug report! This behavior I'm not expecting within Debian. What are the plans now with forwarding the underlying issue to upstream? Upstream is very responsive and I've good contacts to the upstream authors, but who is doing this work now? I read the wiki page mentioned from the initial email again, also there I can't find a written plan that would explain me why the bug reporting together with a direct upload did happen. I see no plan there what will happen on what time. Why no usual muss bug filling did happen so groups and maintainers would have some knowledge about these planned changes? BTW: I've no problem with the technical thing what is happen, but I need to deal also with other things too like a CVE fix for libcopa3. -- Regards Carsten
