Packages depending on (guix build syscalls)

Packages depending on (guix build syscalls)

[Ludovic Courtès]

Hello Guix!

(Resending to the right mailing list, oops!)

Quite a few packages depend on (guix build syscalls), starting from
‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
in 2018) up to GNOME-related packages such as ‘mutter’ (commit
d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).

It’s great that we can reuse this module in different contexts!  The
downside is that the module evolves quite often, because it’s a
foundation for Guix System and other things.  As a result, all these
packages get rebuilt every time we change it.

Maybe the only recommendation I would have is that we should make sure
we really need it before having a package deep down the graph depend on
it.  I wouldn’t want us to do ‘staging’ cycles when we need a change in
(guix build syscalls).

Thoughts?

Ludo’.

Re: Packages depending on (guix build syscalls)

[Ludovic Courtès]

Ludovic Courtès <ludo@gnu.org> skribis:

> Quite a few packages depend on (guix build syscalls), starting from
> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).

An issue is that GNOME now depends on Java:

--8<---------------cut here---------------start------------->8---
$ guix graph gnome --path icedtea
gnome@42.4
font-abattis-cantarell@0.303
python-cffsubr@0.2.9.post1
python-afdko@3.9.1
antlr4@4.10.1
antlr3@3.5.2
antlr2@2.7.7
icedtea@3.19.0
--8<---------------cut here---------------end--------------->8---

It is great to have ‘font-abattis-cantarell’ built from source (since
commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly.

There’s probably not much we can do, unless the python-afdko -> icedtea
dependency is optional.

Ideas?

Ludo’.

Re: Packages depending on (guix build syscalls)

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Fri, Oct 21, 2022 at 11:03:18AM +0200, Ludovic Courtès wrote:
> Ludovic Courtès <ludo@gnu.org> skribis:
> 
> > Quite a few packages depend on (guix build syscalls), starting from
> > ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
> > in 2018) up to GNOME-related packages such as ‘mutter’ (commit
> > d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).
> 
> An issue is that GNOME now depends on Java:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix graph gnome --path icedtea
> gnome@42.4
> font-abattis-cantarell@0.303
> python-cffsubr@0.2.9.post1
> python-afdko@3.9.1
> antlr4@4.10.1
> antlr3@3.5.2
> antlr2@2.7.7
> icedtea@3.19.0
> --8<---------------cut here---------------end--------------->8---
> 
> It is great to have ‘font-abattis-cantarell’ built from source (since
> commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly.
> 
> There’s probably not much we can do, unless the python-afdko -> icedtea
> dependency is optional.
> 
> Ideas?

I looked into this one since it was causing mate to not appear for
i686-linux. I wasn't able to remove the java dependency for the font,
generating the font explicitly imports cffsubr. Python-cffsubr needs
python-afdko for the 'tx' command. I suppose we could re-bundle it but I
haven't gone down that rabbit hole yet.

Or we could just make that font optional.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packages depending on (guix build syscalls)

[Maxim Cournoyer]

Hello,

Efraim Flashner <efraim@flashner.co.il> writes:

[...]

>> It is great to have ‘font-abattis-cantarell’ built from source (since
>> commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly.
>> 
>> There’s probably not much we can do, unless the python-afdko -> icedtea
>> dependency is optional.
>> 
>> Ideas?
>
> I looked into this one since it was causing mate to not appear for
> i686-linux. I wasn't able to remove the java dependency for the font,
> generating the font explicitly imports cffsubr. Python-cffsubr needs
> python-afdko for the 'tx' command. I suppose we could re-bundle it but I
> haven't gone down that rabbit hole yet.
>
> Or we could just make that font optional.

The later sounds easiest, but is it really problematic to have Java as a
transitive native input to GNOME?  I mean, it already depends on Rust,
and OpenJDK builds orders of times faster than Rust.

-- 
Thanks,
Maxim

Re: Packages depending on (guix build syscalls)

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On Wed, Oct 26, 2022 at 11:31:36PM -0400, Maxim Cournoyer wrote:
> Hello,
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> [...]
> 
> >> It is great to have ‘font-abattis-cantarell’ built from source (since
> >> commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly.
> >> 
> >> There’s probably not much we can do, unless the python-afdko -> icedtea
> >> dependency is optional.
> >> 
> >> Ideas?
> >
> > I looked into this one since it was causing mate to not appear for
> > i686-linux. I wasn't able to remove the java dependency for the font,
> > generating the font explicitly imports cffsubr. Python-cffsubr needs
> > python-afdko for the 'tx' command. I suppose we could re-bundle it but I
> > haven't gone down that rabbit hole yet.
> >
> > Or we could just make that font optional.
> 
> The later sounds easiest, but is it really problematic to have Java as a
> transitive native input to GNOME?  I mean, it already depends on Rust,
> and OpenJDK builds orders of times faster than Rust.

Having java as a transitive dependency is unfortunate but it doesn't get
pulled into the enclosure, so I suppose it doesn't really matter, and
the java part really doesn't change that often.

The Java problem seems to have resolved itself, now we're at
python-afdko isn't passing its test suite on i686. Looking at the GitHub
actions and the issue tracker it looks like they don't do testing or
building wheels anymore for 32-bit platforms.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packages depending on (guix build syscalls)

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

Ludovic Courtès <ludo@gnu.org> skriver:

> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Quite a few packages depend on (guix build syscalls), starting from
>> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
>> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
>> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).

It seems the usage of (guix build syscalls) in java.scm and
ant-build-system is solely for 'mkdtemp!'.  Guile 3.0.6 gained
'mkdtemp', so I suppose we can switch to that?

If there are backwards-compatibility concerns it seems possible to
modify these procedures to not need to 'mkdtemp' at all.

I can prepare a patch along these lines, but not sure if we need to
maintain backward compatibility in (gnu packages).

> An issue is that GNOME now depends on Java:

[...]

> There’s probably not much we can do, unless the python-afdko -> icedtea
> dependency is optional.

This relationship was added in b0ddbb05729e86ce4efb7eac8909317e16d7bed7
and is possible to trade at a purity cost.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Packages depending on (guix build syscalls)

[Ludovic Courtès]

Hi!

Marius Bakke <marius@gnu.org> skribis:

> Ludovic Courtès <ludo@gnu.org> skriver:
>
>> Ludovic Courtès <ludo@gnu.org> skribis:
>>
>>> Quite a few packages depend on (guix build syscalls), starting from
>>> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
>>> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
>>> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).
>
> It seems the usage of (guix build syscalls) in java.scm and
> ant-build-system is solely for 'mkdtemp!'.  Guile 3.0.6 gained
> 'mkdtemp', so I suppose we can switch to that?

I think so.

> If there are backwards-compatibility concerns it seems possible to
> modify these procedures to not need to 'mkdtemp' at all.
>
> I can prepare a patch along these lines, but not sure if we need to
> maintain backward compatibility in (gnu packages).

In (gnu packages)?

The only thing to keep in mind is that (guix build gnu-build-system) is
used by packages in commencement.scm, which run on Guile 2.0; thus
gnu-build-system.scm cannot rely on features that appeared in Guile 3.0.
However, for ant-build-system.scm it’s fine to rely on those.

Thanks,
Ludo’.

Re: Packages depending on (guix build syscalls)

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Ludovic Courtès <ludo@gnu.org> skriver:

> Hi!
>
> Marius Bakke <marius@gnu.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> skriver:
>>
>>> Ludovic Courtès <ludo@gnu.org> skribis:
>>>
>>>> Quite a few packages depend on (guix build syscalls), starting from
>>>> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
>>>> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
>>>> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).
>>
>> It seems the usage of (guix build syscalls) in java.scm and
>> ant-build-system is solely for 'mkdtemp!'.  Guile 3.0.6 gained
>> 'mkdtemp', so I suppose we can switch to that?
>
> I think so.

Pushed in fa9ad4b4822d..e6f5b9f7321925.

However it is only a temporary measure because on the 'core-updates'
branch, (guix build syscalls) is used by polkit (for
SET-CHILD-SUBREAPER!) and thus get nearly 3k dependents.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Packages depending on (guix build syscalls)

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> (Resending to the right mailing list, oops!)
>
> Quite a few packages depend on (guix build syscalls), starting from
> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).
>
> It’s great that we can reuse this module in different contexts!  The
> downside is that the module evolves quite often, because it’s a
> foundation for Guix System and other things.  As a result, all these
> packages get rebuilt every time we change it.
>
> Maybe the only recommendation I would have is that we should make sure
> we really need it before having a package deep down the graph depend on
> it.  I wouldn’t want us to do ‘staging’ cycles when we need a change in
> (guix build syscalls).

As mentioned by others, I think merging more general purpose things from
Guix to Guile would be the best way forward.  Every time I write a
simple Guile script, I reach to Guix utils for simple things, which
ought to be in Guile proper.  Alternatively, there's at least 4 packages
depending on (guix build syscalls) for working around a bug where dead
processes are not reaped by PID1 in the Guix build container, causing
some test suites to fail [0].  If we were to fix it, we could remove
these workarounds.

[0]  https://issues.guix.gnu.org/30948

-- 
Thanks,
Maxim

Re: Packages depending on (guix build syscalls)

[Maxim Cournoyer]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> (Resending to the right mailing list, oops!)
>
> Quite a few packages depend on (guix build syscalls), starting from
> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).

The (guix build syscalls) dependency of Mutter can go away after we fix
https://issues.guix.gnu.org/30948.

-- 
Thanks,
Maxim