I thought about it a little bit more and I prefer adding breaks against
the old version of libiso9660, instead of libdevice-cdio-perl. I think
it makes more sense, because even though libdevice-cdio-perl is the
only package, in Debian, that is affected by the issue, other software
(that are not Deb
On 24/03/2025 16:52, Gabriel F. T. Gomes wrote:
* Gabriel F. T. Gomes:
libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
On second thought... This will make it impossible to have both
libiso9660 versions (libiso9660-12 and libiso9660-11t64) at the same
time.
We could have a breaks against
* Gabriel F. T. Gomes:
>
> libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
On second thought... This will make it impossible to have both
libiso9660 versions (libiso9660-12 and libiso9660-11t64) at the same
time.
We could have a breaks against libdevice-cdio-perl as you suggested...
I just thi
* Emilio Pozuelo Monfort:
>
> Can't we fix this by using breaks, as I suggested? That'd be way simpler than
> reverting the transition.
Yes, we can.
It would be a breaks between libcdio sub-packages, though, e.g.:
libcdio19 (>= 2.2.0) breaks libiso9660 (< 2.2.0)
since the mixing of these tw
On 24/03/2025 02:52, Gabriel F. T. Gomes wrote:
Emilio,
My recommendation is that we indeed stop this transition and resume
once trixie is released.
Can't we fix this by using breaks, as I suggested? That'd be way simpler than
reverting the transition.
Cheers,
Emilio
Emilio,
My recommendation is that we indeed stop this transition and resume
once trixie is released.
I have a few updates below:
* Gabriel F. T. Gomes:
>
> the problem does not seem to be related to libdevice-cdio-perl, but a
> problem with libcdio itself.
I was able to remove libdevice-cdio-pe
I like the fact that autopkgtests are detecting this issue. The older
libiso9660 should work with the newer libcdio, because libcdio did not
break its ABI. I was thinking of investigating this further (e.g. with
a minimal reproducer, if I can make one) and even involve upstream if
something is inde
On Wed, 19 Mar 2025 10:25:50 +0100, Emilio Pozuelo Monfort wrote:
> > This did not help the test. :/
…
> > I don't think that there's anything I can do, from libcdio, to fix this.
My gut feeling still says that we are seeing an artifact of how
autopkgtests are run, and that libcdio and libdevice
On 18/03/2025 19:49, Gabriel F. T. Gomes wrote:
* Gabriel F. T. Gomes:
Alternatively, we could make libiso9660 (and libiso9660++) explicitly
depend on the newer version of libcdio.
This did not help the test. :/
libdevice-cdio-perl in testing (i.e.: libdevice-cdio-perl i386
2.0.0-2+b4) owns
* Gabriel F. T. Gomes:
>
> Alternatively, we could make libiso9660 (and libiso9660++) explicitly
> depend on the newer version of libcdio.
This did not help the test. :/
libdevice-cdio-perl in testing (i.e.: libdevice-cdio-perl i386
2.0.0-2+b4) owns /usr/lib/i386-linux-gnu/perl5/5.40/perliso9660
On 14/03/2025 06:09, Gabriel F. T. Gomes wrote:
* Emilio Pozuelo Monfort:
I assume at this point that means bumping the shlibs to get proper
dependencies.
That was my initial idea, too, but I have given additional thought to
this and I think that this is not the right thing to do. Just to mak
* Emilio Pozuelo Monfort:
>
> I assume at this point that means bumping the shlibs to get proper
> dependencies.
That was my initial idea, too, but I have given additional thought to
this and I think that this is not the right thing to do. Just to make
sure we are all discussing the same thing, th
On Thu, 13 Mar 2025 16:47:08 +0100, Emilio Pozuelo Monfort wrote:
This is wrong. libcdio itself doesn't have to be installed during the
build of libiso9660. The dependency is taken from the symbols file, and
I did not update debian/libcdio.symbols to be 2.2.0.
This would fix the dependency confu
On 13/03/2025 16:37, Gabriel F. T. Gomes wrote:
* Gabriel F. T. Gomes:
This is probably due to the fact that libiso9660 is built from the same
source as libcdio; thus, when libiso9660 is built, it is linked against
the version of libcdio installed on the build system, which is version
2.1.0-5.
* Gabriel F. T. Gomes:
>
> This is probably due to the fact that libiso9660 is built from the same
> source as libcdio; thus, when libiso9660 is built, it is linked against
> the version of libcdio installed on the build system, which is version
> 2.1.0-5.
This is wrong. libcdio itself doesn't hav
* gregor herrmann:
>
> % apt-cache --no-all-versions show libiso9660-12
> Package: libiso9660-12
>
> Source: libcdio
> Version: 2.2.0-1
> Installed-Size: 76
> Maintainer: Gabriel F. T. Gomes
> Architecture: amd64
>
On Tue, 11 Mar 2025 16:44:14 -0700, Gabriel F. T. Gomes wrote:
1. Maybe my worries about the ABI break and libdevice-cdio-perl were
not actually too conservative.
2. Why does using an old version of libcdio (not libiso9660) is
causing the issue? Should libcdio's SONAME have been bumped (by
upstr
* Gabriel F. T. Gomes:
>
> I said this before, but I found this hacky way of doing it to pin-point
> (somewhat) the source of the test failures.
With this hacky setup, where libcdio.so.19 is from version 2.1.0-5, the
segmentation fault is caused by the ABI change, as can be seen in the
following G
* gregor herrmann:
>
> No, they are green all across the board (for tests _within_ testing
> or unstable):
> https://ci.debian.net/packages/libd/libdevice-cdio-perl/
Thanks for pointing this out.
* Paul Gevers:
>
> I'm the first to admit that properly testing transitions in the Debian
> CI setu
Hi,
On 11-03-2025 00:41, Gabriel F. T. Gomes wrote:
I think it is impossible to do what you're suggesting. And I agree with
Gregor Herrmann that it doesn't make sense. Shouldn't we test the new
package?
I'm the first to admit that properly testing transitions in the Debian
CI setup is a hard
On Mon, 10 Mar 2025 10:43:52 +0100, Emilio Pozuelo Monfort wrote:
> On 10/03/2025 01:36, Gabriel F. T. Gomes wrote:
> > I'm seeing autopkgtest failures for libdevice-cdio-perl in the tracker
> > for libcdio (excuses panel):
> >https://tracker.debian.org/pkg/libcdio
> > The failures are in 32-b
On 10/03/2025 01:36, Gabriel F. T. Gomes wrote:
I'm seeing autopkgtest failures for libdevice-cdio-perl in the tracker
for libcdio (excuses panel):
https://tracker.debian.org/pkg/libcdio
The failures are in 32-bits architectures, e.g., for i386:
https://ci.debian.net/packages/libd/libde
On Mon, 10 Mar 2025 16:41:41 -0700, Gabriel F. T. Gomes wrote:
> * Emilio Pozuelo Monfort:
> > So perhaps the test is broken,
> > although I'm not sure why it segfaults on those arches and not others, and
> > that
> > may be a real bug.
> I agree that it could be a real bug, but do you think th
* Emilio Pozuelo Monfort:
>
> Did you run it against testing packages, except for libcdio from unstable?
If I install libdevice-cdio-perl from testing, it will automatically
install libcdio from testing, as well, because of the dependency on the
old SONAME.
$ apt depends libdevice-cdio-perl
<...>
I'm seeing autopkgtest failures for libdevice-cdio-perl in the tracker
for libcdio (excuses panel):
https://tracker.debian.org/pkg/libcdio
The failures are in 32-bits architectures, e.g., for i386:
https://ci.debian.net/packages/libd/libdevice-cdio-perl/testing/i386/58673931/
Since it's so
Control: tags -1 confirmed
On 05/03/2025 20:35, Gabriel F. T. Gomes wrote:
Not a lot of replies on the Perl Team's end. I did not follow-up either,
because I didn't fin the time to review the code further.
What I can say is:
1. Nothing on Debian depends on libdevice-cdio-perl (its rdepends i
On Wed, 05 Mar 2025 19:35:14 +, Gabriel F. T. Gomes wrote:
Not a lot of replies on the Perl Team's end. I did not follow-up
either, because I didn't fin the time to review the code further.
I thought there were more discussions than in this thread but
probably this was on IRC only.
What
. T. Gomes; 1094...@bugs.debian.org
Subject: Re: Bug#1094736: transition: libcdio
On 10/02/2025 02:44, Gabriel F. T. Gomes wrote:
> I sent a new message to the perl team, now to the right mailing list:
>
> https://lists.debian.org/debian-perl/2025/02/msg6.html
What's the result
On 10/02/2025 02:44, Gabriel F. T. Gomes wrote:
I sent a new message to the perl team, now to the right mailing list:
https://lists.debian.org/debian-perl/2025/02/msg6.html
What's the result? Are we good to proceed? The transition freeze is around the
corner.
I sent a new message to the perl team, now to the right mailing list:
https://lists.debian.org/debian-perl/2025/02/msg6.html
* Gabriel F. T. Gomes:
> That I did and the tests pass. However, since I'm not sure that the
> tests test the changed ABI, let's wait for the Perl Team opinion.
Though we can still wait for the Perl Team's opinion, I recently
learned more about SWIG and taking care of these API changes in data
typ
* Emilio Pozuelo Monfort:
>
> Have you contacted them?
I hadn't, but I did now
https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2025-January/180083.html
> Maybe you can run libdevice-cdio-perl's autopkgtest after it is
> rebuilt?
That I did and the tests pass. However, since I'm n
On 30/01/2025 16:30, Gabriel F. T. Gomes wrote:
Apart from the test builds, I manually reviewed the uses of the changed
ABI items (public structs iso9660_stat_t and iso_rock_statbuf_t). All
uses, expect on libdevice-cdio-perl-2.0.0, are made with libcdio
functions or by struct member/field name,
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libc...@packages.debian.org, gabr...@inconstante.net.br,
gabr...@debian.org
Control: affects -1 + src:libcdio
User: release.debian@packages.debian.org
Usertags: transition
Dear Debian Release Team,
I would like to have a transition f
34 matches
Mail list logo
