On Sun, 2022-06-05 at 04:26 +0200, Jacob Kroon wrote:
On Sat, 4 Jun 2022, 19:40 Richard Purdie,
On Sat, 2022-06-04 at 17:12 +0200, Jacob Kroon wrote:
On 6/4/22 16:55, Khem Raj wrote:It is a fair point. We may as well add it to perl/perl-native.
My master build is already building make-native due to a
On Sat, Jun 4, 2022 at 6:23 AM Richard Purdie
On Sat, 2022-06-04 at 13:36 +0100, Richard Purdie via
> On Sat, 2022-06-04 at 13:51 +0200, Alexander Kanavin
> > Here's something I didn't think of before. Has this
> > else except Ubuntu 18.04?
> I'm struggling to get the data out from the old builds,
> ubuntu1604, there is an ubuntu1804 on both x86 and arm
> It is possible this is an ubuntu specific make issue or
a make bug.
Ubuntu 18.04 uses make 4.1 which is old (Oct 2014).
I noticed these patches from 2016:
I think we may want to mandate a modern make for both this
issues and also perhaps for better loadavg support to keep
control on the autobuilders.
I'm torn, on the one hand we need to test the distros
people use, on
the other we do need to remove sources of intermittent
issues. I think
this bug must be some issue with make itself.
Adding a make-native dependency to perl would "hurt"
people on modern
Make perhaps does not have many complex dependency needs so it
be as bad
glibc, since 2018:
Don't know if that dependency is still valid though.
still has make 3.82 but I think we now already require buildtools
tarball there so we could probably drop the glibc dependency on
Would it be a bad idea to add make-native to DEPENDS depending on
whether the host version of make is new enough or not ? Would it
break sstate cache reuse in some way ?
We can't have a conditional dependency like that, the task checksums as
implemented today wouldn't work and it would break ssttate reuse.