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 ea
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 f
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; thou
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 al
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 versio
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
> libra
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 binary
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 sup
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 e
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 actual
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 experimen
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 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 inte
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 desi
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 was
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
renames
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:
> > - dpkg
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'
> > > > P
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? S
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 bi
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
> - 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
> > packag
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 coul
31 matches
Mail list logo