> "Ansgar" == Ansgar writes:
Ansgar> As far as I understand this approach will break any consumer
Ansgar> on a library whose ABI changes to to the ABI changes
Ansgar> introduced here unless the consumer is built with the flags
Ansgar> from `dpkg-buildflags` (which would now
On Sat, 6 Jan 2024 19:38:42 -0800 Steve Langasek wrote:
> - dpkg will be uploaded to experimental with 64-bit time_t in the
default
> flags
As far as I understand this approach will break any consumer on a
library whose ABI changes to to the ABI changes introduced here unless
the consumer is
Hi Colin,
On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote:
> On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > > Also a problem is that experimental
On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote:
> On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> > On 05-01-2024 17:36, Rene Engelhard wrote:
> > > Also a problem is that experimental also might already contain totally
> > > unrelated updates like new upstream
On Mon, 08 Jan 2024 at 15:01:11 -0800, Steve Langasek wrote:
> If a maintainer ignores the NMU and drops the rename, they'll be introducing
> a new library transition again on 32-bit archs. Won't they also be caught
> again in binary NEW, for those packages that don't have the same runtime
>
On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> Hi Steve,
> On 05-01-2024 17:36, Rene Engelhard wrote:
> > Also a problem is that experimental also might already contain totally
> > unrelated updates like new upstream versions...
> I share this worry. Have you thought about how to
On Mon, Jan 08, 2024 at 04:12:42PM +0100, Julian Andres Klode wrote:
> > - once these packages have all cleared binary NEW, the new dpkg defaults
> > will be uploaded to unstable
> What happened to the plan to workaround this by doing dak database
> shenanigans prior to uploading to avoid
Hey Steve,
On Sat, Jan 06, 2024 at 07:38:42PM -0800, Steve Langasek wrote:
> On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> > Hi,
>
> > Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > > default
Hi,
Am 07.01.24 um 04:38 schrieb Steve Langasek:
The ordering here would be:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t") and do not already have
versions in
Hi,
Am 07.01.24 um 02:01 schrieb Steve Langasek:
If you say you are going to fix eventual breakage (and not ignoring
the test
results!) and if that means fixing asm on all affected archs, then it's OK
:)
Well, yes; though I hope we would see some help from e.g. arm porters if
there were
On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> Hi,
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > default
> > > > flags
> > [...]
> > What about the suggestion to not push changes to
On Sat, Jan 06, 2024 at 09:07:15AM +0100, Rene Engelhard wrote:
> Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > - dpkg will be uploaded to experimental with 64-bit time_t in the
> > > > default
> > > > flags
> > > I think at that point in time one should know what breaks and whatnot.
Hi,
Am 06.01.24 um 06:51 schrieb Steve Langasek:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
[...]
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
Hi Steve,
Am 06.01.24 um 06:51 schrieb Steve Langasek:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
I think at that point in time one should know what breaks and whatnot.
Archive rebuild?
(Probably in stages)
What kind of breakage are you looking to
On Fri, Jan 05, 2024 at 05:36:10PM +0100, Rene Engelhard wrote:
> > My strawman proposal is to give this thread 2 weeks from today for feedback
> > and further refinement, and also to further reduce the number of
> > false-positives included in the transition. Then, starting on Jan 18:
> > -
Hi Steve,
On 05-01-2024 17:36, Rene Engelhard wrote:
Also a problem is that experimental also might already contain totally
unrelated updates like new upstream versions...
I share this worry. Have you thought about how to handle the cases where
you don't have experimental to upload to? How
Hi Steve
> - perl will also get a sourceful upload, to manually handle 'perlapi'
> Provides.
Can we combine this one with the upcoming perl transition? See #1055955.
Here are some more comments on individual packages.
> 22 libobs-dev
That's a change to the plugin ABI only.
> 14 gnuradio
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote:
> On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote:
> > - In multi-library packages, there is no reliable way to map from a set of
> > headers in a dev package to specific shared libraries in a runtime library
> >
Hi,
Am 05.01.24 um 09:17 schrieb Steve Langasek:
- Packages that could not be analyzed for whatever reason are still
assumed to have an ABI that's sensitive to time_t and have to be included
in the transition. Happily, due to improvements in this run of the number
of packages that
On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote:
> - In multi-library packages, there is no reliable way to map from a set of
> headers in a dev package to specific shared libraries in a runtime library
> package that's not additionally computationally prohibitive; we therefore
>
Hi folks,
Once again, coming back around to the question of an archive-wide migration
for time_t[0].
We have a clear path forward on the toolchain side
(https://bugs.debian.org/1037136), and we have an updated ABI analysis done
against current Debian unstable as of 2023-12-18, superseding the
21 matches
Mail list logo