Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gabr...@debian.org, sergi...@debian.org, vasek.ge...@gmail.com
Severity: normal
Hi,
libcdio needs a transition (upstream bumped the SONAME without ABI break).
I built all the packages repo
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu: flightgear_1:2018.3.2+dfsg-2 . ANY . unstable . -m "rebuild against
libsimgear-dev 1:2018.3.2+dfsg-5"
Fetching of 'live weather' data was broken on flightgear, as reported in
https://b
* 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
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 thes
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
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
* 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 suggest
* 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/p
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 libde
* 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
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
* 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
<...>
* 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
u/libcdio.so.19.0.0
Re-run `autopkgtest -B . -- null' and check that it now fails!
Finally, installing a freshly built version of libdevice-cdio-perl (one
that is linked against the new version of libcdio (2.2.0-1)), makes the
test pass again.
* Gabriel F. T. Gomes:
> I think it is imposs
* 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
17.
In my opinion, my concerns about this transition for libdevice-cdio-perl were
too conservative, and the transition should be allowed.
Cheers.
Gabriel
From: Emilio Pozuelo Monfort on behalf of Emilio Pozuelo
Monfort
Sent: 05 March 2025 00:31
To: Gabriel F
* 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. Gome
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
* 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
20 matches
Mail list logo
