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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
>
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
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
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
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
> > > >
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
> > >
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
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
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
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
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.
>
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
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
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
>
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
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
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.
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
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
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
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
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
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]
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.
>
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
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
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
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
> $ 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
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
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
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
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
> 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.
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
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
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
>
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
68 matches
Mail list logo
