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