Hi Travis,

Quoting Travis Wrightsman (2021-10-27 01:19:13)

Dear Debian cross-builders,

After fixing #996699, the libpurple0 dependency for chatty resolves
correctly during cross-building. Unfortunately this seems to have
uncovered further issues down the dependency chain. I'm now getting the following error while attempting to cross-build chatty with pbuilder:

The following packages have unmet dependencies:
libpurple0:arm64 : Depends: pidgin-data:arm64 (< 2.14.8-z) but it is not installable
Depends: pidgin-data:arm64 (>= 2.14.8) but it is not installable
Depends: perl-base:arm64 but it is not installable
Depends: perlapi-5.32.1:arm64
E: Unable to correct problems, you have held broken packages.
E: pbuilder-satisfydepends failed.

I believe #828759 relates to this for pidgin-data

yes. Marking pidgin-data as M-A:foreign is the right fix as it is also suggested by the multiarch-hinter. See the "action needed" items at https://tracker.debian.org/pkg/pidgin

and #717882 for perl-base and perlapi.

I'm not sure on the correct fixes for these packages. It looks like the
perl bug is especially tricky?

I'm adding debian-perl@lists.debian.org to the recipients as I'm not familiar with Perl in a cross-build context. Maybe the Perl maintainers have a solution for you.

I'm a bit confused that debhelper ${perl:Depends} adds an unversioned dependency on perl-base even though it's essential: https://salsa.debian.org/debian/debhelper/-/blob/main/dh_perl#L152

Thanks!

cheers, josch
--==============27449418250539628=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmF5DucACgkQ8sulx4+9 g+FNLQ/8CR1NhR2u+eeyZmaQcE/YFd1szwSeUAGCdSDBvh1Nx/ViIthgEQg+ij3h G4HZLxOdV5cQEaDKPV6rMuGEL9hKvgu5dHQg4MLHOL7ktzG9ZIX06ida5sPceaAU IRTi9pByzS4w0kTFXCKnb65WZnsh9Gb95X9ecQ1qF9/EFXHFm+MkkLovaTwQ55io jO5pZG96NqnQ9y7XYZ9pliCOqTGxNt5+Ciwq6imerYXi+a4dOZUqUPteBJLrcMVH kgIOTLutc7Tb/WvKTleakdBzehqh2oMJ7c9kzgpuyCxICVV5eYK6LIKWjUP8O0gD xr4BizqMWlymqXv9GqNqQVd599Crltb35Ml6aXjhzp1mDs88LW0+eWcsqgt5cjRT t2zShLrQ6fxyOMXpr47EVRxI6rSbEjTOCWxoTunHKc1CMeQw2kyq8W01lgFK56Lx fb+AjflPMfLBMUpm70+exUiE5UGA6nidQkm0PgsjUCI47SKgQGaGFJF6Iz7OIldC ZeuIE8tMxS8Zgsxd1ZmvJFLlWtTFCIaS+RsGG00UBCsPVErTFZniqGlAPi5o+F08 qFUw4JhuWMZsSzjSukZDsL8sKeNJWLjPAg0Le0gma/5DpvRpH9GbDyAN577sX8py NlYts9swErhkUarFy89VWTvYhIvInihXYPBPfq1BZ5anp7DXwBs=
=62s1
-----END PGP SIGNATURE-----

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

On Wed, Oct 27, 2021 at 10:33:49AM +0200, Johannes Schauer Marin Rodrigues wrote:

Quoting Travis Wrightsman (2021-10-27 01:19:13)

and #717882 for perl-base and perlapi.

I'm not sure on the correct fixes for these packages. It looks like the perl bug is especially tricky?

I'm adding debian-perl@lists.debian.org to the recipients as I'm not familiar with Perl in a cross-build context. Maybe the Perl maintainers have a solution
for you.

Indeed perl-base / perlapi-* is not multi-arch compatible and things
are tricky. I doubt that's going to change any time soon and I don't
think anybody is working on that.

Binary Perl modules can currently only be installed for the native
architecture as they need to be compatible with /usr/bin/perl from
perl-base.

I didn't look at the pidgin specifics at all and can't say how much of
a showstopper this is. There's some information on cross building Perl
bits in /usr/share/doc/libperl-dev/README.cross in case that helps.

I'm a bit confused that debhelper ${perl:Depends} adds an unversioned dependency on perl-base even though it's essential: https://salsa.debian.org/debian/debhelper/-/blob/main/dh_perl#L152

This is a bug in dh_perl introduced a year ago. I've just reported
#997961 about it. Thanks for noticing!
--
Niko Tyni ntyni@debian.org

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

Hi Travis,

On Tue, Oct 26, 2021 at 07:19:13PM -0400, Travis Wrightsman wrote:

The following packages have unmet dependencies:
libpurple0:arm64 : Depends: pidgin-data:arm64 (< 2.14.8-z) but it is not installable
Depends: pidgin-data:arm64 (>= 2.14.8) but it is not installable

I confirm what josch and the hinter said: pidgin-data should be
m-a:foreign.

Depends: perl-base:arm64 but it is not installable
Depends: perlapi-5.32.1:arm64
E: Unable to correct problems, you have held broken packages.
E: pbuilder-satisfydepends failed.

I believe #828759 relates to this for pidgin-data and #717882 for
perl-base and perlapi.

Yes, #828759 looks good to me. #717882 looks essentially unfixable to
me.

I'm not sure on the correct fixes for these packages. It looks like the
perl bug is especially tricky?

While Niko said something on the perl side, I think we need to better understand how pidgin/purple uses perl before we can figure out how to
fix it.

How exactly does libpurple0 use perl?

Let me try to answer this. Please confirm or correct and extend my understanding.

libpurple0 primarily contains libpurple.so.0 to be linked. That library
can be extended with plugins at runtime. One of those plugins is the
perl.so plugin. It actually seems like purple has two plugin mechanisms.
A C/.so based mechanism and a perl-based mechanism that is enabled via
the perl.so plugin. Upon loading a perl-based plugin, a private library
is extended, which enables "use Purple;". As such libpurple0 also
contains a pure perl module Purple backed by a perl extension module Purple::Purple. In particular, libpurple0 does not use the main perl interpreter /usr/bin/perl, but it does use libperl.so.N and standard
perl modules.

Now I'm trying to draw conclusions from the above. Any errors in the
above void the below of course.

What libpurple0 really needs is the embeddable perl interpreter and the
perl relevant perl modules. That should result in a dependency on
libperlN.M at least. Indeed, libpurple0 contains such a dependency. Now
the question is: Why it needs those other dependencies? Niko mentioned
the perl policy and ABI, so presumably the version constraint on
libperlN.M generated from dpkg-shlibdeps is insufficient. Unfortunately, ensuring that constraint using perlapi-VER makes foreign installation impossible. So if we want to allow embedding a foreign perl interpreter
(which is not the same thing as a foreign /usr/bin/perl), the perl
packaging must change and move the provides of perlapi-VER to some
M-A:same package.

Possibly we can repurpose #717882 to ask for allowing the installation
of a foreign embedded perl interpreter? That seems fixable.

Helmut

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

On Sun, Oct 31, 2021 at 01:36:41PM +0100, Helmut Grohne wrote:

Hi Travis,

On Tue, Oct 26, 2021 at 07:19:13PM -0400, Travis Wrightsman wrote:

The following packages have unmet dependencies:
libpurple0:arm64 : Depends: pidgin-data:arm64 (< 2.14.8-z) but it is not installable
Depends: pidgin-data:arm64 (>= 2.14.8) but it is not installable

I confirm what josch and the hinter said: pidgin-data should be
m-a:foreign.

Depends: perl-base:arm64 but it is not installable
Depends: perlapi-5.32.1:arm64
E: Unable to correct problems, you have held broken packages.
E: pbuilder-satisfydepends failed.

I believe #828759 relates to this for pidgin-data and #717882 for
perl-base and perlapi.

Yes, #828759 looks good to me. #717882 looks essentially unfixable to
me.

I'm not sure on the correct fixes for these packages. It looks like the perl bug is especially tricky?

While Niko said something on the perl side, I think we need to better understand how pidgin/purple uses perl before we can figure out how to
fix it.

How exactly does libpurple0 use perl?

That's a great question; Unfortunately I don't know libpurple well
enough to answer that so I've added the maintainer to this email chain. Hopefully Richard has some insight here.

Let me try to answer this. Please confirm or correct and extend my understanding.

libpurple0 primarily contains libpurple.so.0 to be linked. That library
can be extended with plugins at runtime. One of those plugins is the
perl.so plugin. It actually seems like purple has two plugin mechanisms.
A C/.so based mechanism and a perl-based mechanism that is enabled via
the perl.so plugin. Upon loading a perl-based plugin, a private library
is extended, which enables "use Purple;". As such libpurple0 also
contains a pure perl module Purple backed by a perl extension module Purple::Purple. In particular, libpurple0 does not use the main perl interpreter /usr/bin/perl, but it does use libperl.so.N and standard
perl modules.

Now I'm trying to draw conclusions from the above. Any errors in the
above void the below of course.

What libpurple0 really needs is the embeddable perl interpreter and the
perl relevant perl modules. That should result in a dependency on
libperlN.M at least. Indeed, libpurple0 contains such a dependency. Now
the question is: Why it needs those other dependencies? Niko mentioned
the perl policy and ABI, so presumably the version constraint on
libperlN.M generated from dpkg-shlibdeps is insufficient. Unfortunately, ensuring that constraint using perlapi-VER makes foreign installation impossible. So if we want to allow embedding a foreign perl interpreter (which is not the same thing as a foreign /usr/bin/perl), the perl
packaging must change and move the provides of perlapi-VER to some
M-A:same package.

Possibly we can repurpose #717882 to ask for allowing the installation
of a foreign embedded perl interpreter? That seems fixable.

Helmut

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