Re: 64-bit time_t transition in progress in unstable

[Julian Andres Klode]

On Fri, Mar 08, 2024 at 07:38:01AM +0100, Rene Engelhard wrote:
> Hi,
> 
> Am 08.03.24 um 00:12 schrieb Eric Valette:
> > On 07/03/2024 21:16, Rene Engelhard wrote:
> > ct more people.
> > > 
> > > But not so much for dependency issues like this. Which is my sole
> > > point. In 99,9% of cases this won't even migrate to testing. And
> > > unstable won't be released - testing will.
> > 
> > What is your point? Without known bugs or new versions packages migrate
> > from unstable to testing automatically.
> > 
> > 
> > > > You should be happy people debug code
> > > 
> > > *debug code*, yes. debug *actual* (dependency) issues, yes.
> > 
> > I did my part for example with this one, that maintainer denied first
> > but fixed later in his next upload as suggested...
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349
> 
> Well, you haven't seen the various discussion how to fix smbclient on IRC...
> 
> Not really. This is an affect of
> 
>    * d/genshlibs: run dh_makeshlibs on libsmbclient0
>  (Closes: #1065349)
> 
> where the side effect is that one gets the provides via
> 
> Package: libsmbclient0
> Provides: ${t64:Provides}
> X-Time64-Compat: libsmbclient
> 
> That is the correct fix (with a similar result of what you suggests), not
> what you suggested in the first mail, though.
> 
> Besides that your wrote:
> > You cannot install libsmbclient0 without breaking libsmbclient if the
> > version of libsmbclient is not at least 2:4.19.5+dfsg-3. It will then
> > replace libsmbclient.
> > 
> > BUT the package libsmbclient 2:4.19.5+dfsg-3 is never going to be
> > generated nor latter versions unless the names change back to
> > libsmbclient. So the condition will never happen.
> > 
> That is plain wrong. Breaks: is not waiting for anything be there. It's just
> a lesser version of Conflicts


That's how it works in practice with apt, but it's theoretically
incorrect. Breaks should only be used for forcing upgrades of
packages, and not as a "lesser Conflicts" because, while apt does
enforce removal of Breaks, this is not part of the policy or dpkg
- the dpkg behavior would be to deconfigure the package and leave it
around in a half installed state.

Hence you should always have an upgrade to install such that the package
is fully installed again; or use a Conflicts to make sure it is fully
removed.

Also note the Policy requires explicit use of Conflicts + Replaces
for fully replacing a package.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

On 08/03/2024 07:38, Rene Engelhard wrote:

Hi,


I did my part for example with this one, that maintainer denied first 
but fixed later in his next upload as suggested...


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349


Well, you haven't seen the various discussion how to fix smbclient on 
IRC...



I started my analysis in the comment of the above mentioned bug report 
when my suggestion to add "Provides" was politely denied  by:


"So Although I'm not a debian developer, I read this control file as:"



Not really. This is an affect of

    * d/genshlibs: run dh_makeshlibs on libsmbclient0
  (Closes: #1065349)


See above.

That is the correct fix (with a similar result of what you suggests), 
not what you suggested in the first mail, though.


...


That is plain wrong. Breaks: is not waiting for anything be there. It's just a 
lesser version of Conflicts


See above.

It still means the two packages cannot be co-installed no? So result is 
the same as far as the bug was concerned.


You are so determined to prove how dumb I am and how superior you, 
personally, are, that you do cannot even see these simple facts:


1) There was indeed a problem with this samba package set, that I spend 
time to report with a kind fix suggestion (from my point of view),
2) I said that a "Provides" was missing in control file, not how it 
should be added,
3) At the end "Provides:" has indeed been added, probably the "right" 
way as you suggest but still,


Insulting users is generally not very efficient, even for a non profit 
organisation. And believe me although on pre-retirement, with more time, 
and a lot of linux and debian user experience, this does not encourage 
me to take any package responsibility any time soon if that means 
dealing with people like you.


That said, I have a lot of respect and sympathy for debian developers in 
general. I selected this linux distrib because of that more than 20 
years ago.


-- eric

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Hi,

Am 08.03.24 um 00:12 schrieb Eric Valette:

On 07/03/2024 21:16, Rene Engelhard wrote:
ct more people.


But not so much for dependency issues like this. Which is my sole 
point. In 99,9% of cases this won't even migrate to testing. And 
unstable won't be released - testing will.


What is your point? Without known bugs or new versions packages 
migrate from unstable to testing automatically.




You should be happy people debug code


*debug code*, yes. debug *actual* (dependency) issues, yes.


I did my part for example with this one, that maintainer denied first 
but fixed later in his next upload as suggested...


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349


Well, you haven't seen the various discussion how to fix smbclient on IRC...

Not really. This is an affect of

   * d/genshlibs: run dh_makeshlibs on libsmbclient0
 (Closes: #1065349)

where the side effect is that one gets the provides via

Package: libsmbclient0
Provides: ${t64:Provides}
X-Time64-Compat: libsmbclient

That is the correct fix (with a similar result of what you suggests), 
not what you suggested in the first mail, though.


Besides that your wrote:

You cannot install libsmbclient0 without breaking libsmbclient if the
version of libsmbclient is not at least 2:4.19.5+dfsg-3. It will then
replace libsmbclient.

BUT the package libsmbclient 2:4.19.5+dfsg-3 is never going to be
generated nor latter versions unless the names change back to
libsmbclient. So the condition will never happen.

That is plain wrong. Breaks: is not waiting for anything be there. It's 
just a lesser version of Conflicts


> And as you state, if the time_t type is already 64 bits why should

package depending on libsmbclient need to be regenerated?

Here again you show that you don't get why this is done at all. And you 
again ignore release archs in your reasoning completely.


(Whether one likes that those are release archs or not, is not relevant 
here.):



Exactly because of armel/armhf where the time_t was not 64bit before.

libsmbclient r-deps *have* to be rebuilt. On armel/armhf for sure. For 
the rest there's Provides:



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Am 08.03.24 um 00:12 schrieb Eric Valette:

On 07/03/2024 21:16, Rene Engelhard wrote:
ct more people.


But not so much for dependency issues like this. Which is my sole 
point. In 99,9% of cases this won't even migrate to testing. And 
unstable won't be released - testing will.


What is your point? Without known bugs or new versions packages 
migrate from unstable to testing automatically.


Except if their dependencies break in testing. Or dependencies of other 
packages are broken by migrating.


That is something the testing scripts check - amongst other stuff.


Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

On 07/03/2024 21:16, Rene Engelhard wrote:
ct more people.


But not so much for dependency issues like this. Which is my sole point. 
In 99,9% of cases this won't even migrate to testing. And unstable won't 
be released - testing will.


What is your point? Without known bugs or new versions packages migrate 
from unstable to testing automatically.




You should be happy people debug code


*debug code*, yes. debug *actual* (dependency) issues, yes.


I did my part for example with this one, that maintainer denied first 
but fixed later in his next upload as suggested...


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065349

-- eric

Re: 64-bit time_t transition in progress in unstable

[Peter Pentchev]

On Thu, Mar 07, 2024 at 09:16:10PM +0100, Rene Engelhard wrote:
> Hi,
> 
> Am 07.03.24 um 21:07 schrieb Eric Valette:
> > On 07/03/2024 20:55, Rene Engelhard wrote:
> > 
> > > unstable is unstable. Don't use it if you can't handle stuff like
> > > this. And yes, be it even for more days or however it takes.
> > 
> > 
> > The usual mantra. However, if no one use unstable and debug it to make
> > it work correctly, maintainers will discover existing bug very late in
> > the process and they will impact more people.
> 
> But not so much for dependency issues like this. Which is my sole point. In
> 99,9% of cases this won't even migrate to testing. And unstable won't be
> released - testing will.
> 
> 
> > You should be happy people debug code
> 
> *debug code*, yes. debug *actual* (dependency) issues, yes.
> 
> Insisting on (bogus) bug reports about dependency issues out of maintainer
> control which will "magically" be solved once the release team does the
> required bin-NMU: no.

One might even go so far as to say that this - uncovering problems not
foreseen by the people who planned (and put a lot of work into that)
the transition, then started it (and put a lot of work into that, too), and
are now working every day on analyzing the problems that pop up and
resolving them ASAP - so, yeah, this is the *whole point* of unstable.
Catching *all* of these problems and making sure none of the libraries that
might cause them ever migrates to testing - this is the whole point.

So yeah, thanks a lot to the drivers of this transition, to the Release Team,
and to DDs (porters and otherwise) who help with that! IMHO, it is going
even better than I expected :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Hi,

Am 07.03.24 um 21:07 schrieb Eric Valette:

On 07/03/2024 20:55, Rene Engelhard wrote:

unstable is unstable. Don't use it if you can't handle stuff like 
this. And yes, be it even for more days or however it takes.



The usual mantra. However, if no one use unstable and debug it to make 
it work correctly, maintainers will discover existing bug very late in 
the process and they will impact more people.


But not so much for dependency issues like this. Which is my sole point. 
In 99,9% of cases this won't even migrate to testing. And unstable won't 
be released - testing will.




You should be happy people debug code


*debug code*, yes. debug *actual* (dependency) issues, yes.

Insisting on (bogus) bug reports about dependency issues out of 
maintainer control which will "magically" be solved once the release 
team does the required bin-NMU: no.



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

On 07/03/2024 20:55, Rene Engelhard wrote:

unstable is unstable. Don't use it if you can't handle stuff like this. 
And yes, be it even for more days or however it takes.



The usual mantra. However, if no one use unstable and debug it to make 
it work correctly, maintainers will discover existing bug very late in 
the process and they will impact more people.


You should be happy people debug code in advance and thanks them instead 
of using this mantra (and I dunno how many debian bugs (100+) I have 
reported and sometime fixed myself).


-- eric

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Hi,

Am 07.03.24 um 20:33 schrieb Eric Valette:
On 07/03/2024 19:58, Rene Engelhard wrote: 


> My point also was  that your reopening of the bug is wrong since the 
maintainer can't do anything about it.
E.g. if libreoffice wasn't rebuilt against most t64 r-deps since it a) 
also has libraries needing the rename which I b) did when the transition 
starts c) had a new release anyway. If that did't happen and LO wasn't 
rebuilt for the t64 libraries it now needs I'd have reacted the same way 
as for the bug you reopened. Can't do anything about that, the binNMUs 
will happen somwehen when ready.




And you probably need to get out of your amd64 bubble, see below


My "bubble" probably represent in volume 99% of debian 
users/installations so that is a big bubble! 
True. My laptop also is one (but incidentially runs stable as main 
system until the freeze when it will start running testing. rinse and 
repeat). I personally have a sid only in said sid VM.
I admit that unstable installation volume is far less than stable but 
the proportion of people using unstable on arm/xxx is probably 
identical as stable.


I don't think so, actually.  It's probably lesser on sid for arm than 
the stable vs. unstable ratio of amd64. But it doesn't really matter 
anyway. arm* is release architectures and so need to get the rebuilds 
anyway at some time.
I completely can understand that the RT doesn't do those bin-NMUs per 
arch (when?) but just when it's actually ready.


Well well, you annoy 99% of unstable debian users. 


unstable is unstable. Don't use it if you can't handle stuff like this. 
And yes, be it even for more days or however it takes.



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Steve Langasek]

On Thu, Mar 07, 2024 at 12:20:22AM -0500, Theodore Ts'o wrote:
> > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> > actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> > either the existing non-t64 library will be kept installed because nothing
> > yet needs the t64 version, or something does want the t64 version and apt
> > will accept it as a replacement for the non-t64 version because it Provides:
> > the non-t64 name.

> > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> > NOT working, I think we should want to see some apt output showing what's
> > not working.

> Sorry, I've been crazy busy so I didn't have time to object to
> libuuid1t64 as bewing compltely unnecessary before it had rolled out
> to unstable.  Similarly, libcom-err2 and libss2 don't use time_t, so
> the rename to ...t64 was completely unnecessary.

Yes, apologies, we can't assume any particular mapping from -dev packages to
runtime lib packages in packages that have multiple -dev packages, so
libcom-err2 and libss2 were swept up in the renaming and I only noticed
after the fact that this was unnecessary.

-- 
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: 64-bit time_t transition in progress in unstable

[Eric Valette]

On 07/03/2024 19:58, Rene Engelhard wrote:

I'm sure it will be done at some point. However, I just point out that 
on amd64


Maybe, though in my sid VM with all tasks installed plasma-workspace 
fails to upgrade, claiming about gdb-minmal | gdb not to be installed 
whereas both of that install, but that doesn't help it futher. Didn't 
debug, no KDE person.


If you look at my first post in this thread I explain how to install 
libelfxxx without removing gdb. Apt has problem finding a correct path 
for some T64 packages but if you explicitly put each packages apt 
naively and wrongly wants to remove in the install line it find the 
correct path. Other have confirmed this methods works (see in thread) 
and not only for libelf but many others problematic packages.


A bug or limitation of apt. Dunno.

My point also was  that your reopening of the bug is wrong since the 
maintainer can't do anything about it.




And you probably need to get out of your amd64 bubble, see below


My "bubble" probably represent in volume 99% of debian 
users/installations so that is a big bubble! I admit that unstable 
installation volume is far less than stable but the proportion of people 
using unstable on arm/xxx is probably identical as stable.


I completely can understand that the RT doesn't do those bin-NMUs per 
arch (when?) but just when it's actually ready.


Well well, you annoy 99% of unstable debian users. A choice that you are 
perfectly entitled to make, as I am for complaining of consequences 
because of having hard time to help apt to find a migration path (and 
time consuming solution). I imagine it is even worse on other arch.




-- eric

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Am 07.03.24 um 19:21 schrieb Eric Valette:

On 07/03/2024 18:57, Rene Engelhard wrote:

That one is tracked and will get appropriate bin-NMUs from  the 
release team, I am sure.


It is right that this uninstallability is "being part of the normal 
things due to transition".



I'm sure it will be done at some point. However, I just point out that 
on amd64


Maybe, though in my sid VM with all tasks installed plasma-workspace 
fails to upgrade, claiming about gdb-minmal | gdb not to be installed 
whereas both of that install, but that doesn't help it futher. Didn't 
debug, no KDE person.


My point also was  that your reopening of the bug is wrong since the 
maintainer can't do anything about it. He will not schedule the bin-NMU 
(actually can't, and a manual binary only build will just make it 
blocked from entering testing, requiring a bin-NMU _again_). As he said 
it IS "being part of the normal things due to transition".


Even if it it like that for a week now or longer.


And you probably need to get out of your amd64 bubble, see below

this is the last set of packages that are uninstallable currently on 
all my systems (except the one when i manually edited the control 
file) and this has been so since 29 february.


And I guess it will be for some longer since the archs where t64 
actually matters (armel/armhf) has most of the affected packages not 
being rebuilt since it's stuck behind uninstallable stuff and needs 
manual bootstrap uploads.



I completely can understand that the RT doesn't do those bin-NMUs per 
arch (when?) but just when it's actually ready.



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

On 07/03/2024 18:57, Rene Engelhard wrote:

That one is tracked and will get appropriate bin-NMUs from  the release 
team, I am sure.


It is right that this uninstallability is "being part of the normal 
things due to transition".



I'm sure it will be done at some point. However, I just point out that 
on amd64 this is the last set of packages that are uninstallable 
currently on all my systems (except the one when i manually edited the 
control file) and this has been so since 29 february.


-- eric

Re: 64-bit time_t transition in progress in unstable

[Rene Engelhard]

Am 07.03.24 um 09:55 schrieb Eric Valette:

On 07/03/2024 07:25, Kevin Bowling wrote:


As of this evening these are the packages that currently have broken
deps on amd64 for me:
gstreamer1.0-plugins-good gstreamer1.0-pulseaudio
libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc



Someone already opened a bug for libkf5akonadisearch-bin 
libkf5akonadisearch-plugins that has been closed as "being part of the 
normal things due to transition" but I reopened it as:


The maintainer transitionned the "abi name" to "abi name"t64 but many 
package still depend on old "abi name" and are not going to be rebuild 
unless someone force it.



https://release.debian.org/transitions/html/auto-akonadi-search.html


That one is tracked and will get appropriate bin-NMUs from  the release 
team, I am sure.


It is right that this uninstallability is "being part of the normal 
things due to transition".



Regards,


Rene

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

On 07/03/2024 07:25, Kevin Bowling wrote:


As of this evening these are the packages that currently have broken
deps on amd64 for me:
gstreamer1.0-plugins-good gstreamer1.0-pulseaudio
libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc



Someone already opened a bug for libkf5akonadisearch-bin 
libkf5akonadisearch-plugins that has been closed as "being part of the 
normal things due to transition" but I reopened it as:


The maintainer transitionned the "abi name" to "abi name"t64 but many 
package still depend on old "abi name" and are not going to be rebuild 
unless someone force it.


-- eric

Re: 64-bit time_t transition in progress in unstable

[Kevin Bowling]

On Wed, Mar 6, 2024 at 4:18 PM Russ Allbery  wrote:
>
> Eric Valette  writes:
>
> > You can force the migration by explicitly adding the package that it
> > propose to remove (e.g gdb for libelf, ...)
>
> > I managed to upgrade all packages you mention in your mail that
> > way. Only libkf5akonadisearch-bin libkf5akonadisearch-plugins
> > libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64
> > libkf5akonadisearchxapian5t64 are missing because there are bugs in the
> > Provides: for api /or the packe depending on the T64 ABI are not yet
> > rebuild. I opened a bug for that
>
> Ah, yes, that worked.  It took some experimentation to figure out which
> packages could be forced and which ones were causing removals.
>
> I'm down to only libzvbi-common having problems, which I can't manage to
> force without removing xine-ui.  If I attempt to install them both
> together, I get this failure:
>
> The following packages have unmet dependencies:
>  libxine2 : Depends: libxine2-plugins (= 1.2.13+hg20230710-2) but it is not 
> going to be installed or
>  libxine2-misc-plugins (= 1.2.13+hg20230710-2+b3) but it 
> is not going to be installed
>  libxine2-ffmpeg : Depends: libavcodec60 (>= 7:6.0)
>Depends: libavformat60 (>= 7:6.0)
>
> The apt resolver seems to be struggling pretty hard to make sense of the
> correct upgrade path.

As of this evening these are the packages that currently have broken
deps on amd64 for me:
gstreamer1.0-plugins-good gstreamer1.0-pulseaudio
libkf5akonadisearch-bin libkf5akonadisearch-plugins occt-misc

>
> --
> Russ Allbery (r...@debian.org)  
>

Re: 64-bit time_t transition in progress in unstable

[Theodore Ts'o]

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> 
> Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> either the existing non-t64 library will be kept installed because nothing
> yet needs the t64 version, or something does want the t64 version and apt
> will accept it as a replacement for the non-t64 version because it Provides:
> the non-t64 name.
> 
> So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> NOT working, I think we should want to see some apt output showing what's
> not working.

Sorry, I've been crazy busy so I didn't have time to object to
libuuid1t64 as bewing compltely unnecessary before it had rolled out
to unstable.  Similarly, libcom-err2 and libss2 don't use time_t, so
the rename to ...t64 was completely unnecessary.

On my todo list was to figuire out how to revert them, but given that
libuuid1t64 has been causing problems and has required the revert, I
was planning on waiting for the dust to settle before trying to fix up
libcom-err2 and libss2.

(None of this is intended to be a criticism of the team working on
time_t transition; I understand how it's hard to figure out whether a
library has a time_t exported in their interface.  Unfortunately, I
had less than a week to respond, and it happened while I was
travelling, so I didn't have time to review before I saw the upload to
unstable, and I figured out that it was too late for me to object.)

 - Ted

Re: 64-bit time_t transition in progress in unstable

[Russ Allbery]

Eric Valette  writes:

> You can force the migration by explicitly adding the package that it
> propose to remove (e.g gdb for libelf, ...)

> I managed to upgrade all packages you mention in your mail that
> way. Only libkf5akonadisearch-bin libkf5akonadisearch-plugins
> libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64
> libkf5akonadisearchxapian5t64 are missing because there are bugs in the
> Provides: for api /or the packe depending on the T64 ABI are not yet
> rebuild. I opened a bug for that

Ah, yes, that worked.  It took some experimentation to figure out which
packages could be forced and which ones were causing removals.

I'm down to only libzvbi-common having problems, which I can't manage to
force without removing xine-ui.  If I attempt to install them both
together, I get this failure:

The following packages have unmet dependencies:
 libxine2 : Depends: libxine2-plugins (= 1.2.13+hg20230710-2) but it is not 
going to be installed or
 libxine2-misc-plugins (= 1.2.13+hg20230710-2+b3) but it is 
not going to be installed
 libxine2-ffmpeg : Depends: libavcodec60 (>= 7:6.0)
   Depends: libavformat60 (>= 7:6.0)

The apt resolver seems to be struggling pretty hard to make sense of the
correct upgrade path.

-- 
Russ Allbery (r...@debian.org)  

Re: 64-bit time_t transition in progress in unstable

[Eric Valette]

My current list of unupgradable packages on amd64 is:

gir1.2-gstreamer-1.0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libegl-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgbm1/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgl1-mesa-dri/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglapi-mesa/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglx-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgstreamer1.0-0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libldb2/unstable 2:2.8.0+samba4.19.5+dfsg-4 amd64 [upgradable from: 
2:2.8.0+samba4.19.5+dfsg-1]
libspa-0.2-modules/unstable 1.0.3-1.1 amd64 [upgradable from: 1.0.3-1]
libzvbi-common/unstable 0.2.42-1.2 all [upgradable from: 0.2.42-1.1]
mesa-va-drivers/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
samba-libs/unstable 2:4.19.5+dfsg-4 amd64 [upgradable from: 2:4.19.5+dfsg-1]

Doing a bit of exploration, the root problems seem to be:

 libdebuginfod1 : Depends: libelf1 (= 0.190-1+b1)
 libdw1 : Depends: libelf1 (= 0.190-1+b1)
 libxine2-misc-plugins : Depends: libsmbclient (>= 2:4.0.3+dfsg1)
 libgl1-mesa-dri : Depends: libglapi-mesa (= 24.0.1-1)

I'm not sure what's blocking the chain ending in libelf1 since t64
versions of those libraries seem to be available, but attempting to force
it would remove gdb and jupyter if that helps.


You can force the migration by explicitly adding the package that it 
propose to remove (e.g gdb for libelf, ...)


I managed to upgrade all packages you mention in your mail that way. 
Only libkf5akonadisearch-bin libkf5akonadisearch-plugins 
libkf5akonadisearchcore5t64 libkf5akonadisearchpim5t64 
libkf5akonadisearchxapian5t64 are missing because there are bugs in the 
Provides: for api /or the packe depending on the T64 ABI are not yet 
rebuild. I opened a bug for that



-- eric

Re: 64-bit time_t transition in progress in unstable

[Russ Allbery]

Steve Langasek  writes:

> So once the libuuidt64 revert is done (later today?), if apt
> dist-upgrade is NOT working, I think we should want to see some apt
> output showing what's not working.

My current list of unupgradable packages on amd64 is:

gir1.2-gstreamer-1.0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libegl-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgbm1/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgl1-mesa-dri/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglapi-mesa/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libglx-mesa0/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
libgstreamer1.0-0/unstable 1.24.0-1 amd64 [upgradable from: 1.22.10-1]
libldb2/unstable 2:2.8.0+samba4.19.5+dfsg-4 amd64 [upgradable from: 
2:2.8.0+samba4.19.5+dfsg-1]
libspa-0.2-modules/unstable 1.0.3-1.1 amd64 [upgradable from: 1.0.3-1]
libzvbi-common/unstable 0.2.42-1.2 all [upgradable from: 0.2.42-1.1]
mesa-va-drivers/unstable 24.0.2-1 amd64 [upgradable from: 24.0.1-1]
samba-libs/unstable 2:4.19.5+dfsg-4 amd64 [upgradable from: 2:4.19.5+dfsg-1]

Doing a bit of exploration, the root problems seem to be:

 libdebuginfod1 : Depends: libelf1 (= 0.190-1+b1)
 libdw1 : Depends: libelf1 (= 0.190-1+b1)
 libxine2-misc-plugins : Depends: libsmbclient (>= 2:4.0.3+dfsg1)
 libgl1-mesa-dri : Depends: libglapi-mesa (= 24.0.1-1)

I'm not sure what's blocking the chain ending in libelf1 since t64
versions of those libraries seem to be available, but attempting to force
it would remove gdb and jupyter if that helps.

-- 
Russ Allbery (r...@debian.org)  

Re: 64-bit time_t transition in progress in unstable

[Sebastian Ramacher]

On 2024-03-06 12:53:02 -0800, Steve Langasek wrote:
> On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote:
> > On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > > > Are there instructions on how to progress an unstable system through
> > > > > this, or is the repo currently in a known inconsistent state?  I have
> > > > > tried upgrading various packages to work through deps but I am unable
> > > > > to do a dist-upgrade for a while.
> > > > Being unable to do a dist-upgrade is expected and some packages can't be
> > > > installed or can't be upgraded, but in general on amd64 you should be 
> > > > able
> > > > to upgrade a majority of them with `apt upgrade` and then manual
> > > > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > > > drop-in replacements for libfoo0, but in practice some packages have
> > > > additional abi deps for their plugins etc., plus the usual amd64-i386
> > > > skews, plus some unique problems in some packages).
> > > > Also debootstrapping sid is broken, or may be broken from time to time.
> > > > Install testing instead if that's good enough.
> 
> > > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, 
> > > I
> > > actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> > > either the existing non-t64 library will be kept installed because nothing
> > > yet needs the t64 version, or something does want the t64 version and apt
> > > will accept it as a replacement for the non-t64 version because it 
> > > Provides:
> > > the non-t64 name.
> 
> > > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade 
> > > is
> > > NOT working, I think we should want to see some apt output showing what's
> > > not working.
> > On my system there is currently only one problem not related to libuuid:
> > vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
> > uuid, I have several i386 libraries installed that depend on it.
> 
> That seems like a case where the maintainer (cc:ed) could add the
> vlc-plugin-abi-3-0-0f Provides: on 64-bit archs for backwards-compatibility
> to unblock.  Or someone can just request binNMUs for this package sooner
> rather than later.  (It's premature to request mass binNMUs yet while arm*
> are still being re-bootstrapped.)

The Provides in this case would not be enough as it directly maps to the
symbol postfix used by the plugin loader. I'd also need the
corresponding #ifdef to only switch the symbol postfix on the affected
architectures.

Cheers
-- 
Sebastian Ramacher

Re: 64-bit time_t transition in progress in unstable

[Steve Langasek]

On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote:
> On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > > Are there instructions on how to progress an unstable system through
> > > > this, or is the repo currently in a known inconsistent state?  I have
> > > > tried upgrading various packages to work through deps but I am unable
> > > > to do a dist-upgrade for a while.
> > > Being unable to do a dist-upgrade is expected and some packages can't be
> > > installed or can't be upgraded, but in general on amd64 you should be able
> > > to upgrade a majority of them with `apt upgrade` and then manual
> > > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > > drop-in replacements for libfoo0, but in practice some packages have
> > > additional abi deps for their plugins etc., plus the usual amd64-i386
> > > skews, plus some unique problems in some packages).
> > > Also debootstrapping sid is broken, or may be broken from time to time.
> > > Install testing instead if that's good enough.

> > Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> > actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> > either the existing non-t64 library will be kept installed because nothing
> > yet needs the t64 version, or something does want the t64 version and apt
> > will accept it as a replacement for the non-t64 version because it Provides:
> > the non-t64 name.

> > So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> > NOT working, I think we should want to see some apt output showing what's
> > not working.
> On my system there is currently only one problem not related to libuuid:
> vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
> uuid, I have several i386 libraries installed that depend on it.

That seems like a case where the maintainer (cc:ed) could add the
vlc-plugin-abi-3-0-0f Provides: on 64-bit archs for backwards-compatibility
to unblock.  Or someone can just request binNMUs for this package sooner
rather than later.  (It's premature to request mass binNMUs yet while arm*
are still being re-bootstrapped.)

-- 
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: 64-bit time_t transition in progress in unstable

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > Are there instructions on how to progress an unstable system through
> > > this, or is the repo currently in a known inconsistent state?  I have
> > > tried upgrading various packages to work through deps but I am unable
> > > to do a dist-upgrade for a while.
> > Being unable to do a dist-upgrade is expected and some packages can't be
> > installed or can't be upgraded, but in general on amd64 you should be able
> > to upgrade a majority of them with `apt upgrade` and then manual
> > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > drop-in replacements for libfoo0, but in practice some packages have
> > additional abi deps for their plugins etc., plus the usual amd64-i386
> > skews, plus some unique problems in some packages).
> > Also debootstrapping sid is broken, or may be broken from time to time.
> > Install testing instead if that's good enough.
> 
> Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> either the existing non-t64 library will be kept installed because nothing
> yet needs the t64 version, or something does want the t64 version and apt
> will accept it as a replacement for the non-t64 version because it Provides:
> the non-t64 name.
> 
> So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> NOT working, I think we should want to see some apt output showing what's
> not working.
On my system there is currently only one problem not related to libuuid:
vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
uuid, I have several i386 libraries installed that depend on it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Steve Langasek]

On Thu, Mar 07, 2024 at 12:46:24AM +0500, Andrey Rahmatullin wrote:
> On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote:
> > Are there instructions on how to progress an unstable system through
> > this, or is the repo currently in a known inconsistent state?  I have
> > tried upgrading various packages to work through deps but I am unable
> > to do a dist-upgrade for a while.
> Being unable to do a dist-upgrade is expected and some packages can't be
> installed or can't be upgraded, but in general on amd64 you should be able
> to upgrade a majority of them with `apt upgrade` and then manual
> installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> drop-in replacements for libfoo0, but in practice some packages have
> additional abi deps for their plugins etc., plus the usual amd64-i386
> skews, plus some unique problems in some packages).
> Also debootstrapping sid is broken, or may be broken from time to time.
> Install testing instead if that's good enough.

Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
actually would expect unstable to be dist-upgradeable on non-32-bit archs:
either the existing non-t64 library will be kept installed because nothing
yet needs the t64 version, or something does want the t64 version and apt
will accept it as a replacement for the non-t64 version because it Provides:
the non-t64 name.

So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
NOT working, I think we should want to see some apt output showing what's
not working.

-- 
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: 64-bit time_t transition in progress in unstable

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote:
> Are there instructions on how to progress an unstable system through
> this, or is the repo currently in a known inconsistent state?  I have
> tried upgrading various packages to work through deps but I am unable
> to do a dist-upgrade for a while.
Being unable to do a dist-upgrade is expected and some packages can't be
installed or can't be upgraded, but in general on amd64 you should be able
to upgrade a majority of them with `apt upgrade` and then manual
installing/upgrading, if you wish so (as in theory most libfoo0t64 are
drop-in replacements for libfoo0, but in practice some packages have
additional abi deps for their plugins etc., plus the usual amd64-i386
skews, plus some unique problems in some packages).
Also debootstrapping sid is broken, or may be broken from time to time.
Install testing instead if that's good enough.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Russ Allbery]

Kevin Bowling  writes:

> Are there instructions on how to progress an unstable system through
> this, or is the repo currently in a known inconsistent state?  I have
> tried upgrading various packages to work through deps but I am unable to
> do a dist-upgrade for a while.

It doesn't look like the migration is finished yet, so this is expected.
There are a whole lot of packages that need to be rebuilt and a whole lot
of libraries, so some edge cases will doubtless take a while to sort out.

-- 
Russ Allbery (r...@debian.org)  

Re: 64-bit time_t transition in progress in unstable

[Kevin Bowling]

On Mon, Feb 26, 2024 at 4:21 PM Steve Langasek  wrote:
>
> Dear developers,
>
> With the last known blockers resolved, I have now uploaded NMUs of the
> experimental versions of gcc-13 and gcc-14 to unstable, and a corresponding
> upload of dpkg changing the default build flags is expected to follow soon,
> probably within the day.
>
> As a result, the 64-bit time_t transition is now in progress in unstable.
>
> If your packages are any of the lists of those affected by the time_t ABI
> transition[0][1][2][3], it may be advisable to hold off uploads to unstable
> for the next few days in order to avoid any sort of accidental ABI skew on
> armel/armhf.
>
> And if your package is in the list of those requiring sourceful changes for
> the transition due to library package renames[0][1], PLEASE take care not to
> make uploads to unstable clobbering the NMUS and reverting the package
> renaming.  In case you missed it previously, dd-list output saying whether
> you have a package that is affected can be found at [4].
>
> To avoid pain for porters, the mass NMUs to unstable will only be started
> once gcc-13 and dpkg have been built on our 32-bit ports per
> .
>
> As a reminder, the wiki page for the release goal is here:
>
>https://wiki.debian.org/ReleaseGoals/64bit-time
>
> See also the various threads on debian-devel for a more in-depth accounting
> of the work up to this point.[5]

Are there instructions on how to progress an unstable system through
this, or is the repo currently in a known inconsistent state?  I have
tried upgrading various packages to work through deps but I am unable
to do a dist-upgrade for a while.

>
> Thanks,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world

Re: 64-bit time_t transition in progress

[Steve Langasek]

On Tue, Feb 06, 2024 at 05:33:22PM +, Alberto Garcia wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.

> I was having a look at two of the packages that I maintain that have
> t64 binaries in experimental and I noticed that while the binary
> package does have a different name the .so files themselves are the
> same. Is this expected when we're talking about an ABI break?

Yes.  There is longstanding precedent for this in Debian when doing
toolchain-driven ABI transitions where the upstream soname of the library
does not change (c102, c2, c2a, ldbl, v5...).

It is also an important part of ensuring this transition is NOT disruptive
on architectures where there is no ABI change (all 64-bit architectures +
i386).

-- 
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: 64-bit time_t transition in progress

[Steve Langasek]

Thank you for your rigorous scrutiny regarding the proposed plan.

It was a blindspot on my part that dpkg-buildflags was not a policy mandate,
because by this point I'm quite *used* to using dpkg-buildflags to manage
transitions in the default build flags for the compiler.

What I hadn't taken into account is that in those previous transitions, the
consequence of failing to use dpkg-buildflags in a small number of packages
was that those packages did not get certain improvements (in QA,
performance, security, etc) - whereas in this case the consequence of
missing these flags is instead a potentially critical crasher bug due to ABI
skew.

I am delayed in responding to this feedback in part because the realization
pulled me up short and caused me to have to take stock internally of the
overall transition plan.

I think we do need to change the default gcc behavior on our 32-bit archs to
correctly manage this transition.  I believe the correct sequence now should
be:

 - change (the default) gcc to emit the necessary preprocessor flags by
   default.
 - also change dpkg-buildflags to emit them by default (abi=+time64:
   -D[...]; abi=-time64: -U[...]).
 - do the mass uploads to unstable.

(I don't think the critical path here should block on changing the default
behavior of non-default compilers - either non-default gcc versions or llvm. 
Packages that *both* use a non-default C compiler to build *and* don't honor
dpkg-buildflags are a corner case, and we can identify any affected packages
retrospectively rather than having them delay the main event to the
detriment of other development in unstable.)

On Wed, Feb 07, 2024 at 10:12:33AM +, Bill Allombert wrote:
> Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit :
> > > I don't see any practical reason why not.

> > Because packages are not required to use dpkg-buildflags.

> And more generally, does this scheme will require to build third-party
> packages on 32bit Debian system to set
> CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
> or will this be made the default in gcc or glibc ?

On Thu, Feb 08, 2024 at 08:07:19PM +0100, Ansgar wrote:
> On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
> > Once all of these packages have built in experimental and we have identified
> > and addressed all adverse interactions with the usrmerge transition, the
> > plan is:

> >  - dpkg uploaded to unstable with abi=time64 enabled by default[5]

> How does this work when a user builds their own software using any
> library build with abi=time64? They will still get a 32bit time_t &
> others unless they use dpkg-buildflags as well, won't they?

> If we already change ABI, why not change this in the toolchain (glibc,
> gcc) so also user-build packages use the correct ABI? That was what
> happened for other ABI changes like the C++ ABI change as far as I
> remember.

Right: addressing this in the default behavior of the default compiler sorts
out the non-package build question also.

I (and colleagues on the Ubuntu Foundations team) will work with the gcc
maintainer to establish a timeline for when we can have such a change
landed.

-- 
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: 64-bit time_t transition in progress

[Bill Allombert]

On Fri, Feb 02, 2024 at 08:23:44PM +0100, Bill Allombert wrote:
> > > Relying on dpkg-buildflags alone cannot be sufficient.
> > 
> > I don't see any practical reason why not.
> 
> Because packages are not required to use dpkg-buildflags.

Also currently, there are about 20 lib*t64 packages in experimental
that are missing the actual library file: 

compare:
https://packages.debian.org/sid/amd64/libbigwig0/filelist
with
https://packages.debian.org/experimental/amd64/libbigwig0t64/filelist

and
https://packages.debian.org/sid/amd64/libbpp-core4/filelist
with
https://packages.debian.org/experimental/amd64/libbpp-core4t64/filelist

etc. (List below).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

--
libbigwig0t64
libbpp-core4t64
libbpp-phyl12t64
libbpp-phyl-omics3t64
libbpp-popgen8t64
libbpp-qt2t64
libbpp-raa4t64
libbpp-seq12t64
libbpp-seq-omics3t64
libcamp0.8t64
libcapi20-3t64
libc-client2007t64-dev
libhighwayhash0t64
libmems1t64
libpari-gmp-tls8t64
librostlab3t64
libslow5-0t64
libtabixpp0t64
libtecla1t64
libterralib3t64
libxqdbm3t64

Re: 64-bit time_t transition in progress

[Bill Allombert]

Le Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek a écrit :
> In my view, it's fine then to upload libfoo2 to unstable without the t64
> suffix as ABI compatibility with experimental is not really required.  In
> fact, none of the t64 binaries currently being uploaded to experimental have
> the final ABI either, we're just using experimental to clear binary NEW.

But then libfoo2t64 will need to clear binary NEW again.

Would not have been possible to send the list of new t64 package names
to approve to the ftp-master team directly, instead of using the NEW
queue and interferring with the maintainers use of experimental ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Peter Green]

So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?


The problem with doing this is that

1. A reverse dependency may depend on more than one library that uses time_t
   in it's API. Said reverse dependency would not be able to be sanely built
   if libfoo uses 32-bit time_t in it's API and libbar uses 64-bit time_t in
   it's API.
2. If any of your reverse dependencies are libraries that expose time_t in
   their API they would have a similar problem.

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Bill Allombert]

On Fri, Feb 09, 2024 at 05:36:53PM +0100, Ansgar wrote:
> Hi,
> 
> On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote:
> > when introducing a new soname (no just a new package name), then one
> > should move to time64 even on i386 ?
> 
> If you know all consumers of the package will be using appropriate
> compiler flags to get 64-bit time_t, then this is fine.
> 
> Otherwise provider and consumer would disagree about ABI and likely not
> work fully correct.
> 
> > But fundamentally, how do we know how third-party binaries are
> > compiled ?
> 
> They have to use `dpkg-buildflags` with equivalent ABI settings.

Third-party binaries might not be build on a Debian-based distro...

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Ansgar]

Hi,

On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote:
> when introducing a new soname (no just a new package name), then one
> should move to time64 even on i386 ?

If you know all consumers of the package will be using appropriate
compiler flags to get 64-bit time_t, then this is fine.

Otherwise provider and consumer would disagree about ABI and likely not
work fully correct.

> But fundamentally, how do we know how third-party binaries are
> compiled ?

They have to use `dpkg-buildflags` with equivalent ABI settings.

Ansgar

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Simon McVittie]

On Fri, 09 Feb 2024 at 15:24:50 +, Bill Allombert wrote:
> But fundamentally, how do we know how third-party binaries
> are compiled ?

We don't, but we can make some inferences.

If they are i386 binaries that already worked on Debian 12 or older,
and they call into time_t-sensitive ABIs (for instance X509_cmp_time()
in OpenSSL might be a good example), then they must have been compiled
with the expectation that time_t was 32-bit, because that's the ABI that
Debian 12 provided.

If they didn't already work on Debian 12 or older, then it isn't a
regression that they also don't work on Debian 13.

smcv

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Bill Allombert]

Le Fri, Feb 09, 2024 at 10:20:40AM +, Simon McVittie a écrit :
> On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> > if the maintainer
> > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> > it should enable it also on i386 (changed behavior).
> > 
> > The reason is that this does not now break ABI for any package (in Debian
> > or out of Debian) that might have already opted-in to that feature, it
> > does not require adding all the necessary flags manually if one wants
> > to opt-in on i386, and makes it possible to selectively enable time64
> > on [non-library] packages where the binary backwards compatibility make
> > no sense
> 
> I think this is a good improvement. Another advantage of this change is
> that libraries that use time_t internally, but have been confirmed not to
> break ABI when it's enabled and don't call time_t APIs in their non-glibc
> dependencies, can easily opt-in to enabling it on i386 too. Some do this
> upstream already (like dbus and libsdl3 in experimental) but many don't.
> 
> To put this another way, the argument for not doing the transition to
> time64-everywhere on i386 was "we don't want to break third-party i386
> binaries", but ideally we should still be enabling time64, even on i386,
> in the cases where it *won't* break third-party binaries.

So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?
But fundamentally, how do we know how third-party binaries are compiled ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Simon McVittie]

On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> if the maintainer
> has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> it should enable it also on i386 (changed behavior).
> 
> The reason is that this does not now break ABI for any package (in Debian
> or out of Debian) that might have already opted-in to that feature, it
> does not require adding all the necessary flags manually if one wants
> to opt-in on i386, and makes it possible to selectively enable time64
> on [non-library] packages where the binary backwards compatibility make
> no sense

I think this is a good improvement. Another advantage of this change is
that libraries that use time_t internally, but have been confirmed not to
break ABI when it's enabled and don't call time_t APIs in their non-glibc
dependencies, can easily opt-in to enabling it on i386 too. Some do this
upstream already (like dbus and libsdl3 in experimental) but many don't.

To put this another way, the argument for not doing the transition to
time64-everywhere on i386 was "we don't want to break third-party i386
binaries", but ideally we should still be enabling time64, even on i386,
in the cases where it *won't* break third-party binaries.

smcv

Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

[Guillem Jover]

Hi!

On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
> 
>  - dpkg uploaded to unstable with abi=time64 enabled by default[5]

> [5] https://bugs.debian.org/1037136

I just realized recently that I think it'd be better to change a bit
the semantics of the abi time64 feature on i386, where by default it
will not include the time64 flags (as before), but if the maintainer
has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
it should enable it also on i386 (changed behavior).

The reason is that this does not now break ABI for any package (in Debian
or out of Debian) that might have already opted-in to that feature, it
does not require adding all the necessary flags manually if one wants
to opt-in on i386, and makes it possible to selectively enable time64
on packages where the binary backwards compatibility make no sense
(such as dpkg itself, where this has already been requested and where
I mentioned in the libselinux report that I'd like to do that, and
where otherwise the port might be unable to install stuff at all).
Otherwise the majority of packages should have no need to explicitly
declare abi=+time64 as that's going to be the default (except for i386).

I've queued these updated semantics, including manual page updates and
unit tests into the next/time64 branch

(the previous semantics and incomplete commits are still in the
next/time64-default branch), which I'd be merging into main close to
the release, once there's agreement on the dpkg upload date.

If someone has issue with this, let me know and we can discuss the
merits of going some other way.

Thanks,
Guillem

Re: 64-bit time_t transition in progress

[Matthias Klose]

On 08.02.24 20:07, Ansgar wrote:

Hi,

On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:

Once all of these packages have built in experimental and we have identified
and addressed all adverse interactions with the usrmerge transition, the
plan is:

  - dpkg uploaded to unstable with abi=time64 enabled by default[5]


How does this work when a user builds their own software using any
library build with abi=time64? They will still get a 32bit time_t &
others unless they use dpkg-buildflags as well, won't they?

If we already change ABI, why not change this in the toolchain (glibc,
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.


for the GCC 5 changes (std::string ABI), libstdc++ provided the ABI for 
both the old and the new ABI, defaulting to the new ABI.


We can define that macro in GCC, however at the moment I'm unsure how to 
turn it off when passing explicitly -U.  When doing that in GCC, it also 
should be done in other compilers like clang.


And there should be an explicit document/wiki page, which architectures 
(including ports) will have this turned on.  For now I only know that it 
will be turned on for armhf, and not for i386.


Matthias

Re: 64-bit time_t transition in progress

[Ansgar]

Hi,

On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
> 
>  - dpkg uploaded to unstable with abi=time64 enabled by default[5]

How does this work when a user builds their own software using any
library build with abi=time64? They will still get a 32bit time_t &
others unless they use dpkg-buildflags as well, won't they?

If we already change ABI, why not change this in the toolchain (glibc,
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.

Ansgar

Re: 64-bit time_t transition in progress

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 8 Feb 2024 at 13:06, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Fri, 2 Feb 2024 at 13:22, Steve Langasek  wrote:
> >
> > Dear developers,
> >
> > A number of you will have noticed already that the 64-bit time_t transition
> > is now in progress in Debian experimental.
> [snip]
>
> >qt6-virtualkeyboard
> >qt-qml-models
>
> For all Qt packages, be it Qt 5 or 6, you only need to modify
> libqtXcoreX. The rest of the packages will just follow suite,
> **nothing** in Qt does not depends upon libQtCoreX. In fact I would
> say that by doing that you get even the whole KDE stack in.

And any other thing using Qt, be it libraries or not.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: 64-bit time_t transition in progress

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 2 Feb 2024 at 13:22, Steve Langasek  wrote:
>
> Dear developers,
>
> A number of you will have noticed already that the 64-bit time_t transition
> is now in progress in Debian experimental.
[snip]

>qt6-virtualkeyboard
>qt-qml-models

For all Qt packages, be it Qt 5 or 6, you only need to modify
libqtXcoreX. The rest of the packages will just follow suite,
**nothing** in Qt does not depends upon libQtCoreX. In fact I would
say that by doing that you get even the whole KDE stack in.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: 64-bit time_t transition in progress

[Bill Allombert]

Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit :
> > I don't see any practical reason why not.
> 
> Because packages are not required to use dpkg-buildflags.

And more generally, does this scheme will require to build third-party
packages on 32bit Debian system to set
CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
or will this be made the default in gcc or glibc ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: 64-bit time_t transition in progress

[Andreas Metzler]

On 2024-02-06 Alberto Garcia  wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.

> I was having a look at two of the packages that I maintain that have
> t64 binaries in experimental and I noticed that while the binary
> package does have a different name the .so files themselves are the
> same. Is this expected when we're talking about an ABI break?

Hello Alberto,

It is expected for this ABI break yes. Essentially we are just doing a
rebuild-everything-involved while making sure the package
interdependencies avoid a (breaking) mixture. This is similar what we
did when the C++ ABI changed.[1]

cu Andreas
https://lists.debian.org/debian-release/2005/04/msg00153.html
-- 
`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'

Re: 64-bit time_t transition in progress

[Alberto Garcia]

On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> In fact, none of the t64 binaries currently being uploaded
> to experimental have the final ABI either, we're just using
> experimental to clear binary NEW.

I was having a look at two of the packages that I maintain that have
t64 binaries in experimental and I noticed that while the binary
package does have a different name the .so files themselves are the
same. Is this expected when we're talking about an ABI break?

Berto

Re: postgresql-16; wrong NMU versions (Re: 64-bit time_t transition in progress)

[Otto Kekäläinen]

> $ grep mariadb results/*
> results/results_dumped.txt:libmariadb-dev
> results/results_failed.txt:libmariadbd-dev
> results/results_none.txt:libmariadb-dev
> $
>
> There was nothing unintentional here.  libmariadb-dev is clean wrt time_t.
> libmariadbd-dev failed to be analyzed because it has header ordering
> requirements which did not get resolved.
>
> https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libmariadbd-dev/base/log.txt
>
> Much better that there be a library transition only for the lesser-used
> library!

Ok, good. Thanks for the clarification!

Re: postgresql-16; wrong NMU versions (Re: 64-bit time_t transition in progress)

[Steve Langasek]

On Sun, Feb 04, 2024 at 04:08:43PM -0800, Otto Kekäläinen wrote:
> +1 for MariaDB for the above. Also I think the package name change was
> done for the wrong package, it should probably have been done for
> libmariadb3 and not for libmariabd19.

> apt-cache rdepends --no-recommends --no-suggests libmariadb3
> = 120 packages

> vs zero packages using libmariadbd (that library is useful mostly for
> embedded systems doing custom binaries)

$ grep mariadb results/*
results/results_dumped.txt:libmariadb-dev
results/results_failed.txt:libmariadbd-dev
results/results_none.txt:libmariadb-dev
$

There was nothing unintentional here.  libmariadb-dev is clean wrt time_t. 
libmariadbd-dev failed to be analyzed because it has header ordering
requirements which did not get resolved.

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libmariadbd-dev/base/log.txt

Much better that there be a library transition only for the lesser-used
library!

-- 
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: 64-bit time_t transition in progress

[Andrius Merkys]

Hi,

On 2024-02-05 09:05, Steve Langasek wrote:

On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote:

Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64
will be NMU'd directly to unstable. After that happens, will it be OK to
upload libfoo2 to unstable (as part of libfoo transition), or will it have
to carry t64 suffix, i.e., libfoo2t64?


In my view, it's fine then to upload libfoo2 to unstable without the t64
suffix as ABI compatibility with experimental is not really required.  In
fact, none of the t64 binaries currently being uploaded to experimental have
the final ABI either, we're just using experimental to clear binary NEW.


Got it, thanks for clarification.

Best,
Andrius

Re: 64-bit time_t transition in progress

[Steve Langasek]

On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote:
> On 2024-02-02 19:46, Steve Langasek wrote:
> > If there is no new version in experimental, or there is a new version BUT
> > the patch against unstable applies cleanly to the version in experimental
> > (no fuzz), we upload to experimental.

> > Otherwise, patches are sent to the BTS but we skip uploading to experimental
> > and will NMU directly to unstable at the next stage (handling binary NEW
> > there).

> Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64
> will be NMU'd directly to unstable. After that happens, will it be OK to
> upload libfoo2 to unstable (as part of libfoo transition), or will it have
> to carry t64 suffix, i.e., libfoo2t64?

In my view, it's fine then to upload libfoo2 to unstable without the t64
suffix as ABI compatibility with experimental is not really required.  In
fact, none of the t64 binaries currently being uploaded to experimental have
the final ABI either, we're just using experimental to clear binary NEW.

-- 
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: 64-bit time_t transition in progress

[Andrius Merkys]

Hello,

On 2024-02-02 19:46, Steve Langasek wrote:

If there is no new version in experimental, or there is a new version BUT
the patch against unstable applies cleanly to the version in experimental
(no fuzz), we upload to experimental.

Otherwise, patches are sent to the BTS but we skip uploading to experimental
and will NMU directly to unstable at the next stage (handling binary NEW
there).


Given libfoo1 in unstable and libfoo2 in experimental, I assume 
libfoo1t64 will be NMU'd directly to unstable. After that happens, will 
it be OK to upload libfoo2 to unstable (as part of libfoo transition), 
or will it have to carry t64 suffix, i.e., libfoo2t64?


Best,
Andrius

Re: postgresql-16; wrong NMU versions (Re: 64-bit time_t transition in progress)

[Otto Kekäläinen]

> Re: Steve Langasek
> > Christoph Berg 
> >postgresql-16 (U)
>
> Please do not upload postgresql-16 before I ack the diff.
>
> I'll also note that *ALL* nmu diffs I've seen so far are using the
> wrong version number in debian/changelog, missing the "~exp1" upload
> from the actual upload. I've imported some nmu diffs into the
> packaging gits, and now everything is wrong.

+1 for MariaDB for the above. Also I think the package name change was
done for the wrong package, it should probably have been done for
libmariadb3 and not for libmariabd19.

apt-cache rdepends --no-recommends --no-suggests libmariadb3
= 120 packages

vs zero packages using libmariadbd (that library is useful mostly for
embedded systems doing custom binaries)

I am ready to update/finalize the name change myself (draft at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68)
if I get a reply from Graham on how you wish to proceed with this.

postgresql-16; wrong NMU versions (Re: 64-bit time_t transition in progress)

[Christoph Berg]

Re: Steve Langasek
> Christoph Berg 
>postgresql-16 (U)

Please do not upload postgresql-16 before I ack the diff.

I'll also note that *ALL* nmu diffs I've seen so far are using the
wrong version number in debian/changelog, missing the "~exp1" upload
from the actual upload. I've imported some nmu diffs into the
packaging gits, and now everything is wrong.

Christoph

Re: 64-bit time_t transition in progress

[Steve Langasek]

On Sat, Feb 03, 2024 at 12:04:49PM +0100, Fabio Fantoni wrote:
> > debian-devel-announce wouldn't let me attach the file, but for those on
> > debian-devel at least, you can find the dd-list of to-be-NMUed source
> > packages attached.

> From what I understand, for most of the packages involved a rebuild is
> enough

This list of packages are the packages that require sourceful changes
because the runtime library packages must be renamed to declare the ABI
incompatibility (or, if a package rename is not appropriate, then managed
Breaks: against binaries built against the old ABI).

We have a list of the packages that need no-change-rebuilds, but it's not
this list.

> but this rebuild must be done after that of all their dependencies
> (dependencies of dependencies etc...) involved to avoid unexpected events
> that could cause crashes on some architectures (in cases ABI changes
> occurred in the underlying dependencies but the rebuild was done before
> one of those).

> Having a package that depends on many and that part of those are themselves
> involved in various other chains, how do NMU (when needed) to unstable and
> rebuilds of other packages happen?

> A single NMU on unstable or rebuild (for each package involved) but with
> such an order so that when it is done all dependencies are already rebuild,
> or with multiple rebuilds between the various migration chains involved?

Once all of the library packages have been uploaded to unstable and rebuilt,
we will push no-change rebuilds of all packages depending on the old runtime
library names.

There should be no need for multiple rounds of uploads; *all* packages with
dependencies on *any* of the renamed libraries will be triggered as a batch. 
There may be build failures if there are interdependencies between some of
these packages because of unsatisfiable build dependencies, but those will
be resolved semi-automatically in cooperation with the buildd maintainers
and only one round of builds will actually be required.

-- 
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: 64-bit time_t transition in progress

[Steve Langasek]

On Sat, Feb 03, 2024 at 03:22:33PM +0100, julien.pu...@gmail.com wrote:
> Le samedi 03 février 2024 à 10:16 +0100, julien.pu...@gmail.com a
> écrit :

> > About flint: if you need anything done, don't hesitate to ask me.

> In fact multi-arch is broken for flint and I can probably fix it: would
> a new upload go in your way or on the contrary help you ? [I'll refrain
> any move until you confirm I won't break your effort.]

We are currently only uploading to experimental, for clearing NEW and for
usrmerge analysis.  Once that is all done and dpkg is uploaded to unstable,
we will rebase all patches on whatever version of the library is in unstable
at that time.  You don't need to hold off on an upload to unstable for fear
of conflicts.

-- 
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: 64-bit time_t transition in progress

[Steve Langasek]

On Sat, Feb 03, 2024 at 10:16:48AM +0100, julien.pu...@gmail.com wrote:
> Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit :
> > The packages previously not reported are:

> >    flint
> >    flint-arb

> About flint: if you need anything done, don't hesitate to ask me.

> About flint-arb: its code has been merged into flint, so it's abandoned
> upstream. The package is in FTBFS... only the sagemath package prevents
> its removal. Don't get blocked by this mess, you already have enough on
> your plate.

Thanks.  These were added because flint 2.9.0-5 which was the current
version in December successfully analyzed and showed no ABI breakage, but
flint 3.01-2 which is now current can't be analyzed due to compilation
errors.

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libflint-dev/base/log.txt

So *maybe* a quirk could be added for a-c-c to let the headers be analyzed
and show that no change is needed.  Or maybe the analysis would show that
the new version has introduced new entry points that do depend on time_t
size.  I can't tell from here.

I'm not bothered either way, but by default we're going to wind up picking
this up in the mass NMUs and libflint18 will change to libflint18t64, which
will have no effect either way on users upgrading from stable releases since
this is a new soname since bookworm.

-- 
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: 64-bit time_t transition in progress

[Andreas Metzler]

On 2024-02-03 Sebastian Andrzej Siewior  wrote:
> On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote:

>> debian-devel-announce wouldn't let me attach the file, but for those on
>> debian-devel at least, you can find the dd-list of to-be-NMUed source
>> packages attached.

> OpenSSL is on the list. I did not see a NMU bug report. Was the bug
> missed or can it be removed the list of packages that require a NMU?

"These (0-day) NMUs started on Monday, and about 500 libraries have been
uploaded to experimental so far.  The goal is to get all source packages
that can be SRUed to experimental uploaded by this weekend."

The fact that no "We are done" message followed suggests that Steve and
his colleagues are still working on it and will get to OpenSSL in due
time.

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'

Re: 64-bit time_t transition in progress

[julien . puydt]

Le samedi 03 février 2024 à 10:16 +0100, julien.pu...@gmail.com a
écrit :
> 
> About flint: if you need anything done, don't hesitate to ask me.
> 

In fact multi-arch is broken for flint and I can probably fix it: would
a new upload go in your way or on the contrary help you ? [I'll refrain
any move until you confirm I won't break your effort.]

Cheers,

J.Puydt

Re: 64-bit time_t transition in progress

[Sebastian Andrzej Siewior]

On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote:
> Hello,
Hi,

> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.

OpenSSL is on the list. I did not see a NMU bug report. Was the bug
missed or can it be removed the list of packages that require a NMU?

> Thanks,

Sebastian

Re: 64-bit time_t transition in progress

[Sebastian Andrzej Siewior]

On 2024-02-02 10:12:18 [-0800], Steve Langasek wrote:
> Sorry, I mean to add: in the specific case of clamav, the source in
> experimental has a new soname.  So the patch will definitely not apply; and
> we will want to NMU clamav to unstable, with a rename of whatever runtime
> library package is there at the time the NMUs happen; so the version of
> clamav in experimental can ignore this transition and just use the new
> soname once it finally lands (is superseded by the next LTS version?)

I just updated the upload in experimental including the t64 changes. I
suggest to do the transition clamav at the same time.

Sebastian

Re: 64-bit time_t transition in progress

[Fabio Fantoni]

Il 02/02/2024 17:43, Steve Langasek ha scritto:

Hello,

debian-devel-announce wouldn't let me attach the file, but for those on
debian-devel at least, you can find the dd-list of to-be-NMUed source
packages attached.

Thanks,


Sorry to bother you (or anyone else who wants to answer) with a question 
that might be stupid, maybe I didn't understand something.


From what I understand, for most of the packages involved a rebuild is 
enough but this rebuild must be done after that of all their 
dependencies (dependencies of dependencies etc...) involved to avoid 
unexpected events that could cause crashes on some architectures (in 
cases ABI changes occurred in the underlying dependencies but the 
rebuild was done before one of those).


Having a package that depends on many and that part of those are 
themselves involved in various other chains, how do NMU (when needed) to 
unstable and rebuilds of other packages happen?


A single NMU on unstable or rebuild (for each package involved) but with 
such an order so that when it is done all dependencies are already 
rebuild, or with multiple rebuilds between the various migration chains 
involved?


Thanks for any reply and sorry for my bad english.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: 64-bit time_t transition in progress

[julien . puydt]

Hi,

Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit :
> The packages previously not reported are:
> 
>    flint
>    flint-arb

About flint: if you need anything done, don't hesitate to ask me.

About flint-arb: its code has been merged into flint, so it's abandoned
upstream. The package is in FTBFS... only the sagemath package prevents
its removal. Don't get blocked by this mess, you already have enough on
your plate.

Cheers,

J.Puydt

Re: 64-bit time_t transition in progress

[Alastair McKinstry]

Hi,

Since the time transition is going to require an openmpi transition, I 
suggest that the mpi-defaults transition happen simultaneously;


ie mpi-defaults to move 32-bit builds to mpich; openmpi 4.1.6-6 with t64 
libs builds against 64-bit libs only.


Note there is a 5.0.1-1 package in experimental for openmpi that is not 
ready for primetime; for the t64 transition use 4.1.6 not 5.0.1.


Thanks

Alastair

On 02/02/2024 16:43, Steve Langasek wrote:

Hello,

debian-devel-announce wouldn't let me attach the file, but for those on
debian-devel at least, you can find the dd-list of to-be-NMUed source
packages attached.

Thanks,


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie

Re: 64-bit time_t transition in progress

[Bill Allombert]

On Fri, Feb 02, 2024 at 10:58:51AM -0800, Steve Langasek wrote:
> Well, if this suggestion had come 6 months ago when this plan was laid out
> on debian-devel, I think it would have been worth exploring.
> 
> Though I would have still expected a large number of false-positives,
> because there would be differences for any library using time_t-derived
> types internally, *or* any filesystem access affected by LFS.

The idea was to compare the shared library binaries not the packages.

> > Do the libxxxt64 in experimental supposed to use the new ABI ?  Because it
> > does not seem to be always the case.  Is there a lintian test for that ?
> 
> No.  Earlier this had been the plan, but after discussing with Guillem we
> realized that wasn't actually relevant so we revised the plan on the fly and
> skipped dpkg in experimental.

So the libraries in experimental are going to have an incompatible ABI with the
ones in unstable ?

> > Relying on dpkg-buildflags alone cannot be sufficient.
> 
> I don't see any practical reason why not.

Because packages are not required to use dpkg-buildflags.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: 64-bit time_t transition in progress

[Steve Langasek]

On Fri, Feb 02, 2024 at 07:34:46PM +0100, Bill Allombert wrote:
> On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> > Dear developers,

> > As mentioned previously on debian-devel[6], we know that there are a number
> > of library packages being included in this transition which we have not
> > proven have an ABI affected by 64-bit time_t.  This is because the
> > engineering cost of analyzing the long tail of packages whose headers
> > out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> > than the cost of just changing the package name and moving forward with
> > rebuilds. 

> Why not use reproducible build on a 32bit platform and see whether the new
> library is different from the old one ?

Well, if this suggestion had come 6 months ago when this plan was laid out
on debian-devel, I think it would have been worth exploring.

Though I would have still expected a large number of false-positives,
because there would be differences for any library using time_t-derived
types internally, *or* any filesystem access affected by LFS.

> Do the libxxxt64 in experimental supposed to use the new ABI ?  Because it
> does not seem to be always the case.  Is there a lintian test for that ?

No.  Earlier this had been the plan, but after discussing with Guillem we
realized that wasn't actually relevant so we revised the plan on the fly and
skipped dpkg in experimental.

> Relying on dpkg-buildflags alone cannot be sufficient.

I don't see any practical reason why not.

-- 
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: 64-bit time_t transition in progress

[Bill Allombert]

On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> Dear developers,
> 
> As mentioned previously on debian-devel[6], we know that there are a number
> of library packages being included in this transition which we have not
> proven have an ABI affected by 64-bit time_t.  This is because the
> engineering cost of analyzing the long tail of packages whose headers
> out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> than the cost of just changing the package name and moving forward with
> rebuilds. 

Why not use reproducible build on a 32bit platform and see whether the new
library is different from the old one ?

Do the libxxxt64 in experimental supposed to use the new ABI ? Because it does 
not 
seem to be always the case. Is there a lintian test for that ?

Relying on dpkg-buildflags alone cannot be sufficient.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: 64-bit time_t transition in progress

[Steve Langasek]

Sorry, I mean to add: in the specific case of clamav, the source in
experimental has a new soname.  So the patch will definitely not apply; and
we will want to NMU clamav to unstable, with a rename of whatever runtime
library package is there at the time the NMUs happen; so the version of
clamav in experimental can ignore this transition and just use the new
soname once it finally lands (is superseded by the next LTS version?)

On Fri, Feb 02, 2024 at 09:46:10AM -0800, Steve Langasek wrote:
> On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote:
> > On February 2, 2024 4:43:52 PM UTC, Steve Langasek  
> > wrote:
> > >Hello,
> 
> > >debian-devel-announce wouldn't let me attach the file, but for those on
> > >debian-devel at least, you can find the dd-list of to-be-NMUed source
> > >packages attached.
> 
> > Thanks,
> 
> > How are you handling the case where there's already a version of the
> > package in experimental (this applies to clamav where we are tracking the
> > latest, non-LTS version in experimental)?
> 
> If there is no new version in experimental, or there is a new version BUT
> the patch against unstable applies cleanly to the version in experimental
> (no fuzz), we upload to experimental.
> 
> Otherwise, patches are sent to the BTS but we skip uploading to experimental
> and will NMU directly to unstable at the next stage (handling binary NEW
> there).
> 
> 
> Abridged citation from the code used, which probably explains as clearly as
> anything:
> 
>   apt-get source --only-source "$src"/unstable
>   cd "$src"-*
>   oldsrcver=$(dpkg-parsechangelog -S Version)
>   "$toolsdir"/time-t-me
>   dch -n 'Rename libraries for 64-bit time_t transition.'
>   dch -r -D experimental ''
>   sudo env APT_CONFIG=$APT_CONFIG mk-build-deps -i -r
>   dpkg-buildpackage -S -uc -us
>   srcver=$(dpkg-parsechangelog -S Version)
>   # make sure the package from unstable builds with the patch
>   # before we send it to the BTS
>   DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS nocheck" \
>   dpkg-buildpackage -uc -us
>   cd ..
>   debdiff "$src"_${oldsrcver#*:}.dsc "$src"_${srcver#*:}.dsc \
>   > nmu_"$src".debdiff || true
> 
>   # maybe there's a new version, or maybe we fall back to
>   # unstable
>   apt-get source --only-source "$src"/experimental \
>   || apt-get source --only-source "$src"/unstable
>   cd "$src"-*
> 
>   # we filter out debian/changelog and regenerate it with
>   # matching content, because if there is a new version then
>   # that part of the diff will fail to apply; but if everything
>   # else applies we should just upload to experimental anyway
>   # with an appropriate bumped version.
>   if ! filterdiff -x '*/debian/changelog' ../nmu_"$src".debdiff \
>   | patch -p1 -f -F0
>   then
>   cd ..
>   echo "$src: failed" >> upload-nmus.log
>   rm -f nmu_"$src".debdiff
>   rm -rf "$src"[_-]*
>   continue
>   fi
> 
> -- 
> 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

-- 
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: 64-bit time_t transition in progress

[Steve Langasek]

On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote:
> On February 2, 2024 4:43:52 PM UTC, Steve Langasek  wrote:
> >Hello,

> >debian-devel-announce wouldn't let me attach the file, but for those on
> >debian-devel at least, you can find the dd-list of to-be-NMUed source
> >packages attached.

> Thanks,

> How are you handling the case where there's already a version of the
> package in experimental (this applies to clamav where we are tracking the
> latest, non-LTS version in experimental)?

If there is no new version in experimental, or there is a new version BUT
the patch against unstable applies cleanly to the version in experimental
(no fuzz), we upload to experimental.

Otherwise, patches are sent to the BTS but we skip uploading to experimental
and will NMU directly to unstable at the next stage (handling binary NEW
there).


Abridged citation from the code used, which probably explains as clearly as
anything:

apt-get source --only-source "$src"/unstable
cd "$src"-*
oldsrcver=$(dpkg-parsechangelog -S Version)
"$toolsdir"/time-t-me
dch -n 'Rename libraries for 64-bit time_t transition.'
dch -r -D experimental ''
sudo env APT_CONFIG=$APT_CONFIG mk-build-deps -i -r
dpkg-buildpackage -S -uc -us
srcver=$(dpkg-parsechangelog -S Version)
# make sure the package from unstable builds with the patch
# before we send it to the BTS
DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS nocheck" \
dpkg-buildpackage -uc -us
cd ..
debdiff "$src"_${oldsrcver#*:}.dsc "$src"_${srcver#*:}.dsc \
> nmu_"$src".debdiff || true

# maybe there's a new version, or maybe we fall back to
# unstable
apt-get source --only-source "$src"/experimental \
|| apt-get source --only-source "$src"/unstable
cd "$src"-*

# we filter out debian/changelog and regenerate it with
# matching content, because if there is a new version then
# that part of the diff will fail to apply; but if everything
# else applies we should just upload to experimental anyway
# with an appropriate bumped version.
if ! filterdiff -x '*/debian/changelog' ../nmu_"$src".debdiff \
| patch -p1 -f -F0
then
cd ..
echo "$src: failed" >> upload-nmus.log
rm -f nmu_"$src".debdiff
rm -rf "$src"[_-]*
continue
fi

-- 
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: 64-bit time_t transition in progress

[Scott Kitterman]

On February 2, 2024 4:43:52 PM UTC, Steve Langasek  wrote:
>Hello,
>
>debian-devel-announce wouldn't let me attach the file, but for those on
>debian-devel at least, you can find the dd-list of to-be-NMUed source
>packages attached.

Thanks,

How are you handling the case where there's already a version of the package in 
experimental (this applies to clamav where we are tracking the latest, non-LTS 
version in experimental)?

Scott K