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 <https://buildd.debian.org/status/package.php?suite=sid&p=gcc-13>.
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]
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
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.
Are there instructions on how to progress an unstable system throughBeing 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
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.
On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote:
Are there instructions on how to progress an unstable system throughBeing 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
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.
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.
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 forAre 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 unableBeing 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).
to do a dist-upgrade for a while.
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 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 isOn 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.
NOT working, I think we should want to see some apt output showing what's not working.
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.)
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 isOn 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
NOT working, I think we should want to see some apt output showing what's not working.
uuid, I have several i386 libraries installed that depend on it.
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.
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
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.
Eric Valette <eric.valette@free.fr> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
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.
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.
On 07/03/2024 19:58, Rene Engelhard wrote:E.g. if libreoffice wasn't rebuilt against most t64 r-deps since it a)
My point also was that your reopening of the bug is wrong since themaintainer can't do anything about it.
True. My laptop also is one (but incidentially runs stable as mainAnd 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.
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.
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.
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
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.
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
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.
And as you state, if the time_t type is already 64 bits why should
package depending on libsmbclient need to be regenerated?
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 29:52:01 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,352,934 |