XPost: linux.debian.devel.release

* 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.so,
which is linked against the older libiso9660.so file, as can be seen
below:

$ ltrace -s128 perl t/07.iso2.t 2>&1 | grep -E "^dlopen.*iso9660"
dlopen("/usr/lib/i386-linux-gnu/perl5/5.40/perliso9660.so", 1) = 0x57582f10

$ readelf --dynamic /usr/lib/i386-linux-gnu/perl5/5.40/perliso9660.so | grep NEEDED | grep libiso9660
0x00000001 (NEEDED) Shared library: [libiso9660.so.11]

I don't think that there's anything I can do, from libcdio, to fix this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

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-cdio-perl should
probably migrate together.

Can't you add a breaks against the old libdevice-cdio-perl version?

That also sounds like a good idea, just that - if I'm not mistaken -
a Breaks on the (differing) binNMU versions doesn't work.

If it helps I'm happy to upload libdevice-cdio-perl 2.0.0-3 in order
to enable a versioned Breaks against "<< 2.0.0-3".


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- BOFH excuse #318: Your EMAIL is now being delivered by the USPS.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

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 indeed broken. The reason why I want to do this is that
the problem does not seem to be related to libdevice-cdio-perl, but a
problem with libcdio itself.

This would most likely delay the transition after the trixie release.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

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-perl from the equation with the
following program:

#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <cdio/cdio.h>
#include <cdio/iso9660.h>
int
main(void)
{
CdIo_t *cdio;
iso9660_stat_t *stat;
cdio = cdio_open("isofs-m1.cue", DRIVER_UNKNOWN);
if (cdio == NULL)
err(EXIT_FAILURE, "unable to open disk file");
stat = iso9660_fs_find_lsn(cdio, 26);
if (stat == NULL)
err(EXIT_FAILURE, "unable to find LSN");
cdio_destroy(cdio);
return 0;
}

The data files (isofs-m1.cue and isofs-m1.bin) can be found in libdevice-cdio-perl, e.g.:

https://sources.debian.org/src/libdevice-cdio-perl/2.0.0-2/data/

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 indeed broken.

I sent upstream a message (I don't see it in their mailing list archive yet)

Cheers,
Gabriel

PS: This was a nice catch by the CI and libdevice-cdio-perl's autopkgtest. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

* 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 think that this might feel like hiding the problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

* 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 two versions is what causes the segfault
(even if we remove libdevice-cdio-perl from the equation), as explained
in the message to upstream:

https://lists.gnu.org/archive/html/libcdio-devel/2025-03/msg00000.html

I'm happy with fixing it with breaks if you think that this is preferred.

Cheers,
Gabriel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)