Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

Helmut Grohne
Hi gregor,

On Mon, Jun 24, 2019 at 06:57:12PM +0200, gregor herrmann wrote:
> On Mon, 24 Jun 2019 10:11:21 +0700, Nguyen Hoang Tung wrote:
> > libcrypt-openssl-dsa-perl fails to cross build because it does not pass
> > cross build tools to configure and to make. Adding
> > /usr/share/dpkg/buildtools.mk lib and re-define linkers and compilers can
> > solve this problem.

If you include (not "-include") buildtools.mk, you must add an
appropriate versioned dependency on dpkg-dev.

> While I like to support improving crossbuildability, I have the
> impression that the issue you address in these 2 patches affects
> hundreds of packages, and that adding boilerplate code to all
> debian/rules files is the wrong approach (and doesn't scale). I guess
> this needs to be tackled at a deeper level, probably the two perl
> buildsystems in debhelper.

I fully agree. I've spared lib*-perl packages thus far, because I think
that they should be fixed at the tooling layer, but I have no clue how
to do that. I was hoping that eventually some perl guy would ask me for
help ...

> Incidentally, Niko look at crossbuilding arch:any perl packages at
> our recent sprint briefly. What I find in our gobby notes is

... or takes it in his own hands. This is great news!

> | implement debhelper support for cross building XS module packages?
> | effectively make debhelper run 'perl -I /usr/lib/<arch>/perl/cross-config-5.28.1 Makefile.PL' when it detects a cross build
>
> which points in the same direction. And I'm sure Niko can add more on
> this topic than I :)

This is quite precisely the information I was missing thus far. I think
the major question now is: Who wants to turn this into a debhelper
patch? The second question is: Why do we need the perl version in that
part? (Can it be renamed to something without the version?) If there is
a reason: How do we compute the correct version?

Getting this into debhelper post-buster has the potential to fix
hundreds of perl packages indeed.

Can I use this opportunity to ask the Debian Perl Group for a favour? If
you want to help with cross building, please annotate any Build-Depends
that are only used for testing (i.e. droppable when
DEB_BUILD_OPTIONS=nocheck) with "<!nocheck>". As maintainers, you'll
have a good intuition for which dependencies are candidates. For
reproducible packages, you can build once with DEB_BUILD_OPTIONS=nocheck
DEB_BUILD_PROFILES=nocheck, then without these vars, and compare the
binary packages to verify correctness of the annotations. Thank you for
your support.

I've added d-cross@ and d-perl@ into the loop and dropped the individual
bugs.

Helmut

Reply | Threaded
Open this post in threaded view
|

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

gregor herrmann-3
On Mon, 24 Jun 2019 22:37:49 +0200, Helmut Grohne wrote:

> > While I like to support improving crossbuildability, I have the
> > impression that the issue you address in these 2 patches affects
> > hundreds of packages, and that adding boilerplate code to all
> > debian/rules files is the wrong approach (and doesn't scale). I guess
> > this needs to be tackled at a deeper level, probably the two perl
> > buildsystems in debhelper.
> I fully agree. I've spared lib*-perl packages thus far, because I think
> that they should be fixed at the tooling layer,

Great.

> > | implement debhelper support for cross building XS module packages?
> > | effectively make debhelper run 'perl -I /usr/lib/<arch>/perl/cross-config-5.28.1 Makefile.PL' when it detects a cross build
> >
> > which points in the same direction. And I'm sure Niko can add more on
> > this topic than I :)
>
> This is quite precisely the information I was missing thus far. I think
> the major question now is: Who wants to turn this into a debhelper
> patch? The second question is: Why do we need the perl version in that
> part? (Can it be renamed to something without the version?) If there is
> a reason: How do we compute the correct version?
I guess the version is there because:
    % dpkg -S /usr/lib/x86_64-linux-gnu/perl/cross-config-5.28.1
    libperl5.28:amd64: /usr/lib/x86_64-linux-gnu/perl/cross-config-5.28.1
and libperl5.xx are meant to be co-installable.

If we only need the version of the currently running perl then that's
easy: Luckily debhelper is written in perl so we can just ask it,
e.g. with

#v+
#!/usr/bin/perl

use strict;
use warnings;
use Config;

my $perlversion = $Config{'version'};
print "$perlversion\n";
#v-
 
> Can I use this opportunity to ask the Debian Perl Group for a favour? If
> you want to help with cross building, please annotate any Build-Depends
> that are only used for testing (i.e. droppable when
> DEB_BUILD_OPTIONS=nocheck) with "<!nocheck>".

Yup, I've seen your bug reports, and they are on my TODO list for
post-buster.

And during the Sprint I worked on teaching dh-make-perl to
automatically add "<!nocheck>" to test dependencies. This is not
finished yet (i.e. it seems to work for new packages but only
partially for updating existing ones) but I guess we'll sort it out
:)

> As maintainers, you'll
> have a good intuition for which dependencies are candidates.

For well-curated CPAN distributions that's actually simple, as the
META specification distinguishes between build requirements, test
requirements and runtime requirements.

> For
> reproducible packages, you can build once with DEB_BUILD_OPTIONS=nocheck
> DEB_BUILD_PROFILES=nocheck, then without these vars, and compare the
> binary packages to verify correctness of the annotations. Thank you for
> your support.

Thanks for these hints (I always tend to forget or confuse all those
variables).
 


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
   `-   NP: Arlo Guthrie: Gypsy Davy

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

Niko Tyni-3
In reply to this post by Helmut Grohne
On Mon, Jun 24, 2019 at 10:37:49PM +0200, Helmut Grohne wrote:
 
> > | implement debhelper support for cross building XS module packages?
> > | effectively make debhelper run 'perl -I /usr/lib/<arch>/perl/cross-config-5.28.1 Makefile.PL' when it detects a cross build
> >
> > which points in the same direction. And I'm sure Niko can add more on
> > this topic than I :)

Yeah, this stuff has been in place for a while now but I haven't really
advertised it anywhere. Sorry about that.

> This is quite precisely the information I was missing thus far. I think
> the major question now is: Who wants to turn this into a debhelper
> patch? The second question is: Why do we need the perl version in that
> part? (Can it be renamed to something without the version?) If there is
> a reason: How do we compute the correct version?

I was hoping to look at the debhelper part of XS module cross builds
during the sprint but ended up converting src:perl debian/rules to dh
instead :) It's certainly on my TODO list but time is scarce nowadays.
Happy if anybody else wants to take over of course.

The way most Perl module builds work is that Makefile.PL (or rather
ExtUtils::MakeMaker) looks up the compiler, linker, install paths etc. in
Config.pm during the build process. The Config.pm module is shipped as
part of the Perl build and is very much version and architecture specific.

For cross builds, the host architecture version of Config.pm needs to
be on the Perl search path before the build architecture version one.
However, we can't just point the build architecture Perl at the host
architecture modules directory because any binary modules (for example
Cwd) in there will not be functional.

So we need to ship a directory with just Config.pm and let the build
architecture perl use the build architecture modules for all other
tasks. Somewhat surprisingly this seemed to work, at least in my limited
tests.

As noted, Config.pm is Perl version specific so it needs to be shipped in
a versioned package and directory. Gregor already showed that computing
the right path is not particularly hard.

One piece that I haven't got in place yet is how the cross build should
pull in the host architecture libperl5.28 package (which contains
/usr/lib/<arch>/perl/cross-config-5.28.1/ with Config.pm). We definitely
don't want build dependencies with hardcoded Perl versions on the
packages. I originally had libperl5.xx Provide perl-cross-config with
the idea that builders could depend on that, but I see I've since moved
that Provides entry to perl (along with others due to #899110). I think
this move was probably wrong and made the perl-cross-config virtual
package useless.

Even with that fixed, adding build dependencies on 'perl-cross-config
<cross>' to all the XS module packages we're targetting with this seems
like a rather arduous undertaking, but doable for bullseye if this is
deemed to be the right approach.

As for the patch in #930980 which just overrides LD and CC: does that
really work as far as installing the generated files in the correct
paths? I'd expect them to end up in the build architecture path instead,
as that comes from the build architecture Config.pm.

Hope I'm making sense, happy to have more eyeballs on this stuff :)
--
Niko

Reply | Threaded
Open this post in threaded view
|

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

Helmut Grohne
Hi Niko,

On Thu, Jun 27, 2019 at 12:02:52AM +0300, Niko Tyni wrote:
> For cross builds, the host architecture version of Config.pm needs to
> be on the Perl search path before the build architecture version one.
> However, we can't just point the build architecture Perl at the host
> architecture modules directory because any binary modules (for example
> Cwd) in there will not be functional.

This is similar to how Python 2.x does it. The directory to put on the
search path is /usr/lib/python2.7/plat-<archspecific>/ and the module to
import is called _sysconfigdata_nd.py there. I've also seen something
similar in the ruby world, but don't remember the details currently. I'm
explaining this here, because I hope we can learn from them.

> So we need to ship a directory with just Config.pm and let the build
> architecture perl use the build architecture modules for all other
> tasks. Somewhat surprisingly this seemed to work, at least in my limited
> tests.

Exactly how Python 2.x does it. In 3.X, the module is on the standard
search path and has an architecture-dependent name. This approach has a
distinct advantage: You can import the module for two architectures
(e.g. build and host) simultaneously in theory. I haven't actually seen
anyone using this, so the current approach for perl is likely good
enough.

> One piece that I haven't got in place yet is how the cross build should
> pull in the host architecture libperl5.28 package (which contains
> /usr/lib/<arch>/perl/cross-config-5.28.1/ with Config.pm). We definitely
> don't want build dependencies with hardcoded Perl versions on the
> packages. I originally had libperl5.xx Provide perl-cross-config with
> the idea that builders could depend on that, but I see I've since moved
> that Provides entry to perl (along with others due to #899110). I think
> this move was probably wrong and made the perl-cross-config virtual
> package useless.

Again, let me compare this to the Python world. The config module is
shipped with libpythonX.Y-minimal (ignore the -minimal part), which is
similar to how perl does it. When packaging Python extensions, it was
common to Build-Depends: python-all-dev (or for one version python-dev).
For cross building we now have to replace that with libpython-all-dev,
python-all-dev:any and this is a pain. If we can fix this for perl
without updating each and every build dependency, that would be great.

> Even with that fixed, adding build dependencies on 'perl-cross-config
> <cross>' to all the XS module packages we're targetting with this seems
> like a rather arduous undertaking, but doable for bullseye if this is
> deemed to be the right approach.

I'd like to avoid <cross> dependencies whereever reasonable. I think
they should be an exception and not a common case, because it is
something that we easily get wrong. It is often easier to use a M-A:same
package as the "entry point" and forward to M-A:foreign packages from
there. Things that are in the M-A:same dependency tree get installed for
the host architecture. Things that are in the M-A:foreign subtree get
installed for the build architecture. For Python it would have been
possible to subtly reroute dependencies such that python-all-dev would
become M-A:same instead of M-A:allowed, but we didn't do that. Now the
imporant question kinda is: What is this "entry point" for perl? What is
the common dependency for all perl extensions? Is there one? Can we
repurpose it in this way?

If that's not possible and we have to update each and every perl
extension, I'm in favour of fixing this in a more generic way. I suggest
updating the perl policy to say that every perl extension must build
depend on e.g. perl-ext-build (name up to colouring). This is not
cross-specific in any way, but a generic concept. Then we can use that
dependency to implement the cross case without bothering maintainers.
Such a rule should be lintian-enforced eventually.

The gist of this is that I try to make cross builds and native builds
differ as little as possible. Maintainers shouldn't have to remember the
cross use case. Rather, it should just work. It should be as close to
the normal processes as possible.

So I think that the first step is getting this dependency issue sorted
out in a conceptual way. Still the present discussion has already gotten
us quite far.

Thank you

Helmut

Reply | Threaded
Open this post in threaded view
|

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

Niko Tyni-3
On Thu, Jun 27, 2019 at 07:01:52AM +0200, Helmut Grohne wrote:
 

> On Thu, Jun 27, 2019 at 12:02:52AM +0300, Niko Tyni wrote:
> > For cross builds, the host architecture version of Config.pm needs to
> > be on the Perl search path before the build architecture version one.
> > However, we can't just point the build architecture Perl at the host
> > architecture modules directory because any binary modules (for example
> > Cwd) in there will not be functional.
>
> This is similar to how Python 2.x does it. The directory to put on the
> search path is /usr/lib/python2.7/plat-<archspecific>/ and the module to
> import is called _sysconfigdata_nd.py there. I've also seen something
> similar in the ruby world, but don't remember the details currently. I'm
> explaining this here, because I hope we can learn from them.

Cool. It's been a while since I set up the current perl implementation,
not sure how much research I did wrt. other language ecosystems. I see
there's a note from doko about the Python implementation in #717433.

Anyway, sounds like the solutions are very similar which is encouraging.

BTW I'd mostly forgotten about this but we've used liblocale-gettext-perl
as a guinea pig in the archive for the current implementation, so you
might want to have a look at it. Obviously the stuff in debian/rules
should be moved to debhelper eventually.

> > So we need to ship a directory with just Config.pm and let the build
> > architecture perl use the build architecture modules for all other
> > tasks. Somewhat surprisingly this seemed to work, at least in my limited
> > tests.
>
> Exactly how Python 2.x does it. In 3.X, the module is on the standard
> search path and has an architecture-dependent name. This approach has a
> distinct advantage: You can import the module for two architectures
> (e.g. build and host) simultaneously in theory. I haven't actually seen
> anyone using this, so the current approach for perl is likely good
> enough.

I think something like this for Perl would mean major work upstream and
is unlikely to happen.

> I'd like to avoid <cross> dependencies whereever reasonable. I think
> they should be an exception and not a common case, because it is
> something that we easily get wrong. It is often easier to use a M-A:same
> package as the "entry point" and forward to M-A:foreign packages from
> there. Things that are in the M-A:same dependency tree get installed for
> the host architecture. Things that are in the M-A:foreign subtree get
> installed for the build architecture. For Python it would have been
> possible to subtly reroute dependencies such that python-all-dev would
> become M-A:same instead of M-A:allowed, but we didn't do that. Now the
> imporant question kinda is: What is this "entry point" for perl? What is
> the common dependency for all perl extensions? Is there one? Can we
> repurpose it in this way?

I can see that having <cross> dependencies be an exception rather than
the norm would be good.

Unfortunately, packages building Perl extensions ("XS modules") are not
currently required to Build-Depend on anything else than "perl", which
has sort of double role as it mainly means "the set of packages for a
standard perl installation". It's currently M-A: allowed because of this
double role and doesn't seem like a candidate for M-A:same (I think).

The only M-A:same package from src:perl is currently libperl5.28, though
libperl-dev could also be made M-A:same if needed. (Despite the promising
name, libperl-dev in its current form is not the entry point needed here:
it's about building packages that embed a Perl interpreter and therefore
link against libperl.so, not about building Perl extensions.)

> If that's not possible and we have to update each and every perl
> extension, I'm in favour of fixing this in a more generic way. I suggest
> updating the perl policy to say that every perl extension must build
> depend on e.g. perl-ext-build (name up to colouring). This is not
> cross-specific in any way, but a generic concept. Then we can use that
> dependency to implement the cross case without bothering maintainers.
> Such a rule should be lintian-enforced eventually.

This looks like the way to go, though I think it would be better to
just start it within pkg-perl packages first and amend the policy to a
'should' once there's a decent use base. Possibly 'perl-xs-build' would be
a good name but I'm happy with whatever. I suppose it could be provided
by libperl5.xx, so the dependency would be a no-op on native builds.
(Unless there's a need for a separate real package that I don't see?)

I'm not sure about the "generic concept" part as I see no benefits to this
dependency outside cross building. Consequentially, I'm not quite sure
how useful it is to add the dependency to all Perl extension packages
regardless of whether they are otherwise cross buildable or not. But
maybe there's worth in keeping those things separate and divide the big
aim into smaller steps?

I see ~500 source packages in the archive building XS modules (based on
binary packages dependening on perlapi-5.x.x), with the pkg-perl group
maintaining ~400 of them. So if all of them are to be touched, most of
the work unsurprisingly falls on the pkg-perl group.

My feeling is that a decent coverage (maybe 50% or so?) could be achieved
for bullseye "just" by updating the tooling and doing a mass commit
early in the release phase, so packages would acquire the dependency
when they are uploaded for other reasons.

Getting adoption to 100% for the pkg-perl packages would need a
concentrated uploading effort of course.
--
Niko

Reply | Threaded
Open this post in threaded view
|

Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

Helmut Grohne
Hi Niko,

On Thu, Jul 04, 2019 at 03:35:01PM +0300, Niko Tyni wrote:
> BTW I'd mostly forgotten about this but we've used liblocale-gettext-perl
> as a guinea pig in the archive for the current implementation, so you
> might want to have a look at it. Obviously the stuff in debian/rules
> should be moved to debhelper eventually.

I noticed it earlier, but didn't fully understand it. Meanwhile,
liblocale-gettext-perl is not cross-satisfiable due to its dependency on
perl-cross-config. I think you recently pointed out that it got messed
up. For the sake of experimentation, I replaced it with libperl5.28 and
doing so results in a cross buildable liblocale-gettext-perl. So yeah, I
confirm that this functionality should move to debhelper.

> I think something like this for Perl would mean major work upstream and
> is unlikely to happen.

I was not trying to suggest that perl should follow the Python 3.X
approach. I was merely pointing it out to have more context.

> Unfortunately, packages building Perl extensions ("XS modules") are not
> currently required to Build-Depend on anything else than "perl", which
> has sort of double role as it mainly means "the set of packages for a
> standard perl installation". It's currently M-A: allowed because of this
> double role and doesn't seem like a candidate for M-A:same (I think).

I'm left wondering why a standard perl installation would include 7MB
worth of C headers but no C compiler. Likely this has good reasons and
I'm not the first one to ask. If you happen to know a place to read up
on the rationale, please point me at it.

In the unlikely case of absence of reasons, I'm in favour of shrinking
the standard perl installation. Of course these headers would be needed
for building xs modules, so doing this would come at the cost of adding
a new Build-Depends to (you counted) 500 source packages.

> The only M-A:same package from src:perl is currently libperl5.28, though
> libperl-dev could also be made M-A:same if needed. (Despite the promising
> name, libperl-dev in its current form is not the entry point needed here:
> it's about building packages that embed a Perl interpreter and therefore
> link against libperl.so, not about building Perl extensions.)

I think M-A:same is not exactly what we need here. It's easier to say
that we need M-A:same, but what we need is the foreign Config.pm to be
coinstallable with the native perl. M-A:same is sufficient, but not
strictly necessary to get there.

> This looks like the way to go, though I think it would be better to
> just start it within pkg-perl packages first and amend the policy to a
> 'should' once there's a decent use base. Possibly 'perl-xs-build' would be
> a good name but I'm happy with whatever. I suppose it could be provided
> by libperl5.xx, so the dependency would be a no-op on native builds.
> (Unless there's a need for a separate real package that I don't see?)

Let us not confuse the final solution with the way to get there. When I
say that we should have some package that all xs-modules build depend
on, then that's the final solution. Obviously, we won't get there over
night. Starting with a few packages and scale up once we are confident
that it generally works. When to update policy is an interesting
question, but I think the final goal should be using a "must" here. If
all goes very well, we might be able to do that after buster+1 is
released.

> I'm not sure about the "generic concept" part as I see no benefits to this
> dependency outside cross building. Consequentially, I'm not quite sure
> how useful it is to add the dependency to all Perl extension packages
> regardless of whether they are otherwise cross buildable or not. But
> maybe there's worth in keeping those things separate and divide the big
> aim into smaller steps?

Yeah, this is part of the final goal vs. how to get there. Still, I
think that if 90% of perl extensions carry this new dependency, then
consistency is in favour of just adding it everywhere.

> I see ~500 source packages in the archive building XS modules (based on
> binary packages dependening on perlapi-5.x.x), with the pkg-perl group
> maintaining ~400 of them. So if all of them are to be touched, most of
> the work unsurprisingly falls on the pkg-perl group.

I'm in favour of starting way smaller: Making the debhelper part work
seems required to me. The next step seems to be updating
liblocale-gettext-perl. Once that works, we maybe try another 10
packages. After establishing confidence, mass-committing the 400
pgk-perl packages may be reasonable, but not any earlier.

> My feeling is that a decent coverage (maybe 50% or so?) could be achieved
> for bullseye "just" by updating the tooling and doing a mass commit
> early in the release phase, so packages would acquire the dependency
> when they are uploaded for other reasons.

I think agreeing on a schedule will not be a problem. In all of my cross
porting work, I've generally preferred the slow route that yields
maintainable solutions.

> Getting adoption to 100% for the pkg-perl packages would need a
> concentrated uploading effort of course.

Sounds like something we can discuss during the bookworm cycle.

Let me try to build consensus here from what we've learned thus far:
 * We'll have to do "something" about perl-cross-config as it presently
   does not "work".
 * The things that liblocale-gettext-perl's debian/rules does should be
   handled by debhelper.
 * To facilitate cross building of xs modules, we'll have those xs
   modules gain a new build dependency. This dependency has to ensure
   that the host architecture Config.pm is available.

Then non-consensus:
 * We need to decide the name of the new dependency. I vaguely proposed
   perl-ext-build, but am now unconvinced of that. You refined it it to
   perl-xs-build. I am now convinced that the -build suffix is not a
   good idea as we usually call this -dev. What about perl-xs-dev?
 * Having libperlX.YZ provide the new name is going to be problematic
   during perl transitions as the package will be provided by multiple
   libperlX.YZ, but only the one matching perl can be used. I guess we
   need this to be a real package.
 * Who is going to write the debhelper patch? I think I'd be able to do
   it, but I presently lack the time to do it. Do you want to handle
   this, Niko?
 * Can we retire the virtual perl-cross-config package?
 * We still disagree on whether all xs modules should carry the new
   dependency or whether only those that are cross buildable should have
   it.

Can you confirm or refine my consensus call and comment on the
non-consensus?

Helmut