[Debian-iot-maintainers] Bug#1062257: Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-iot-maintainers/attachments/20240201/fca03f3f/attachment.sig>