Hi Sebastian,
On Tue, Jan 09, 2024 at 10:49:23AM +0100, Sebastian Ramacher wrote:
> > > > > > 22 libobs-dev
> > > > > That's a change to the plugin ABI only.
> > > > Can you explain how you've reached that conclusion? This is a package
> > > > that failed to be analyzed in the latest run; an
Hi,
On 20-01-2024 23:22, Steve Langasek wrote:
So I think an algorithm for deciding the uploads to experimental looks like
this:
- download source from unstable.
- apply the packagename conversion to the source.
- grab the debdiff.
- submit the NMU diff to the BTS.
- download the source again
On Sun, Jan 07, 2024 at 09:30:37AM +0100, Rene Engelhard wrote:
> 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;
Hi again,
On Sun, Jan 07, 2024 at 01:09:48PM +0100, Rene Engelhard wrote:
> 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
>
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
>
Hi Steve
On 2024-01-05 20:26:56 -0800, Steve Langasek wrote:
> On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote:
> > On 2024-01-05 11:06:09 -0800, Steve Langasek wrote:
> > > On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote:
> > > > Hi Steve
>
> > > > > - perl
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
On 2024-01-05, Sebastian Ramacher wrote:
>> libpoppler-cpp0v5
>> libpoppler-glib8
>> libpoppler-qt5-1
>> libpoppler-qt6-3
>> libpoppler126
Poppler core (126ish) changes SONAME by release and is in general not
supposed to be used by well-behaving applications.
the frontentds (cpp,glib,Qt*) is
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.
On Sat, Jan 06, 2024 at 10:01:30AM -0700, Sam Hartman wrote:
> > "Steve" == Steve Langasek writes:
> >> At one level, krb5-multidev only has an rdep of 5, but I suspect
> >> the rdep count for libkrb5-dev is somewhat larger:-) I don't know
> >> how many packages would be removed
On Sun, Jan 07, 2024 at 02:23:32AM +0900, Simon Richter wrote:
> > Aren't all these problems just inherent in Debian's lack of a mandated
> > packaging tooling and workflow [1,2]?
>
> We have a mandated tooling and workflow.
>
> The tooling follows an interface that is defined in Policy. The
Hi,
On 06.01.24 22:15, Gioele Barabucci wrote:
Aren't all these problems just inherent in Debian's lack of a mandated
packaging tooling and workflow [1,2]?
We have a mandated tooling and workflow.
The tooling follows an interface that is defined in Policy. The
interface is deliberately
> "Steve" == Steve Langasek writes:
>> At one level, krb5-multidev only has an rdep of 5, but I suspect
>> the rdep count for libkrb5-dev is somewhat larger:-) I don't know
>> how many packages would be removed from the transition if we
>> decide most of the krb5 libraries do
Oops, should have waited sending...
On 06-01-2024 14:30, Paul Gevers wrote:
On 06-01-2024 14:15, Gioele Barabucci wrote:
Aren't all these problems just inherent in Debian's lack of a mandated
packaging tooling and workflow [1,2]?
Might be, but that doesn't mean that problem goes away.
I
Hi Gioele,
On 06-01-2024 14:15, Gioele Barabucci wrote:
Aren't all these problems just inherent in Debian's lack of a mandated
packaging tooling and workflow [1,2]?
Might be, but that doesn't mean that problem goes away.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 05/01/24 21:17, Paul Gevers wrote:
Another worry, how will you provide the required changes to the
maintainers of the packages? Via BTS? For those working on salsa: MR?
Both? Something else? Obviously we should not end in the situation that
a new upload goes back to the old name (or are the
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
On Fri, Jan 05, 2024 at 12:23:00AM -0800, Steve Langasek wrote:
> I am also attaching here the dd-list output for the packages that will need
> to be sourcefully NMUed for the transition, for your review.
I could readily identify a number of packages (incomplete) also affected
by DEP17. Whenever
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 02:23:59PM -0700, Sam Hartman wrote:
> > "Steve" == Steve Langasek writes:
> Steve> - In multi-library packages, there is no reliable way to map
> Steve> from a set of headers in a dev package to specific shared
> Steve> libraries in a runtime library
On Fri, Jan 05, 2024 at 05:28:37PM +0100, Guillem Jover wrote:
> > Guillem Jover
> >libaio
> >libmd
> >liburing
> I checked these, and it looks like libmd and liburing are
> false-positives?
> * libmd uses AC_SYS_LARGEFILE, and on 32-bit arches it is already built
>with LFS,
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:
> > -
On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote:
> On 2024-01-05 11:06:09 -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote:
> > > Hi Steve
> > > > - perl will also get a sourceful upload, to manually handle 'perlapi'
> > > >
On Fri, Jan 05, 2024 at 06:59:20PM +0100, Sebastian Ramacher wrote:
> > > > I am also attaching here the dd-list output for the packages that will
> > > > need
> > > > to be sourcefully NMUed for the transition, for your review.
> > > Why do the need sourceful NMUs if they just need to be
> "Steve" == Steve Langasek writes:
Steve> - In multi-library packages, there is no reliable way to map
Steve> from a set of headers in a dev package to specific shared
Steve> libraries in a runtime library package that's not
Steve> additionally computationally prohibitive;
[Sorry for breaking the thread; my previous message exceeded a size limit for
debian-devel so I'm having to re-send with some of the attachments removed
and put on a website instead.
This mail also includes an updated 'sorted-revdep-count' list; I
inadvertently had a stale local mirror in my sid
On 2024-01-05 11:06:09 -0800, Steve Langasek wrote:
> On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote:
> > Hi Steve
>
> > > - perl will also get a sourceful upload, to manually handle 'perlapi'
> > > Provides.
>
> > Can we combine this one with the upcoming perl transition?
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
On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote:
> 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.
Pros and cons of combining:
- it will save another
Hi Steve
On 2024-01-05 09:42:06 -0800, Steve Langasek wrote:
> Hi Sebastian,
>
> On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote:
> > On 2024-01-05 00:23:00 -0800, Steve Langasek wrote:
> > > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > > > == Results ==
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 Sebastian,
On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote:
> On 2024-01-05 00:23:00 -0800, Steve Langasek wrote:
> > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > > == Results ==
> > > The overall findings of this analysis are 1,745 "dev" packages
On 2024-01-05 00:23:00 -0800, Steve Langasek wrote:
> On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > == Results ==
> >
> > The overall findings of this analysis are 1,745 "dev" packages which either
> > are confirmed to have ABI changes or could not be checked; mapping to
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
Hi!
[ It seems the original post didn't get through to debian-devel (yet?),
I found it on debian-release though
https://lists.debian.org/debian-release/2024/01/msg00033.html,
you might want to repost it here though, so that it can be commented
on properly? :) ]
On Fri, 2024-01-05 at
43 matches
Mail list logo
