librsvg & Rust

librsvg & Rust

[Ludovic Courtès]

Hello Guix!

guix-commits@gnu.org skribis:

> mbakke pushed a commit to branch staging
> in repository guix.
>
> commit ec47c07d0690653be35a75b346f3c3548a3e71d4
> Author: Marius Bakke <mbakke@fastmail.com>
> Date:   Wed Oct 24 15:26:10 2018 +0200
>
>     gnu: librsvg: Update to 2.44.12.
>     
>     * gnu/packages/gnome.scm (librsvg): Update to 2.44.12.
>     [arguments]: Replace patching phases with custom variants.  Delete five new
>     tests.
>     [native-inputs]: Add RUST-1.27 and RUST-1.27:CARGO.

This change was bound to happen since upstream switched to Rust, but
it creates a few issues.

First, that adds Rust to the base graphical applications, which
significantly increases build times and size:

--8<---------------cut here---------------start------------->8---
$ guix size librsvg | tail -1
total: 207.2 MiB
$ guix size librsvg rust | tail -1
total: 1052.9 MiB
--8<---------------cut here---------------end--------------->8---

Perhaps the size issue can be somewhat mitigated by adding a “lib”
output to the Rust package, but even then it would probably still be an
issue.

Also, is the new librsvg API-compatible with the old one?  IIUC it still
provides a C API, right?  Does guile-rsvg still work, for example?

What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
that architectures where Rust isn’t supported yet could still work:
<https://lwn.net/Articles/771355/>.

Anyway, lots of questions!

Thanks,
Ludo’.

Re: librsvg & Rust

[Marius Bakke]

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

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

> Hello Guix!
>
> guix-commits@gnu.org skribis:
>
>> mbakke pushed a commit to branch staging
>> in repository guix.
>>
>> commit ec47c07d0690653be35a75b346f3c3548a3e71d4
>> Author: Marius Bakke <mbakke@fastmail.com>
>> Date:   Wed Oct 24 15:26:10 2018 +0200
>>
>>     gnu: librsvg: Update to 2.44.12.
>>     
>>     * gnu/packages/gnome.scm (librsvg): Update to 2.44.12.
>>     [arguments]: Replace patching phases with custom variants.  Delete five new
>>     tests.
>>     [native-inputs]: Add RUST-1.27 and RUST-1.27:CARGO.
>
> This change was bound to happen since upstream switched to Rust, but
> it creates a few issues.
>
> First, that adds Rust to the base graphical applications, which
> significantly increases build times and size:
>
> --8<---------------cut here---------------start------------->8---
> $ guix size librsvg | tail -1
> total: 207.2 MiB
> $ guix size librsvg rust | tail -1
> total: 1052.9 MiB
> --8<---------------cut here---------------end--------------->8---
>
> Perhaps the size issue can be somewhat mitigated by adding a “lib”
> output to the Rust package, but even then it would probably still be an
> issue.

Librsvg does not depend on Rust at run-time, so the closure size should
be similar.  However I notice it has a 129MiB (!!) librsvg-2.a, which
should be removed.  I will do that later.

> Also, is the new librsvg API-compatible with the old one?  IIUC it still
> provides a C API, right?  Does guile-rsvg still work, for example?

I have not noticed any regressions since the switch.  The guile-rsvg
tests pass, at least!

> What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
> that architectures where Rust isn’t supported yet could still work:
> <https://lwn.net/Articles/771355/>.

I wanted to ask about this: is Rust supported on all the platforms we
support at the moment?

While depending on Rust for GTK/GNOME is unfortunate, I do think it's
inevitable.

By the way, the next version of librsvg will require Rust 1.33 or
thereabouts.

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

Re: librsvg & Rust

[ng0]

Marius Bakke transcribed 2.7K bytes:
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > Hello Guix!
> >
> > guix-commits@gnu.org skribis:
> >
> >> mbakke pushed a commit to branch staging
> >> in repository guix.
> >>
> >> commit ec47c07d0690653be35a75b346f3c3548a3e71d4
> >> Author: Marius Bakke <mbakke@fastmail.com>
> >> Date:   Wed Oct 24 15:26:10 2018 +0200
> >>
> >>     gnu: librsvg: Update to 2.44.12.
> >>     
> >>     * gnu/packages/gnome.scm (librsvg): Update to 2.44.12.
> >>     [arguments]: Replace patching phases with custom variants.  Delete five new
> >>     tests.
> >>     [native-inputs]: Add RUST-1.27 and RUST-1.27:CARGO.
> >
> > This change was bound to happen since upstream switched to Rust, but
> > it creates a few issues.
> >
> > First, that adds Rust to the base graphical applications, which
> > significantly increases build times and size:
> >
> > --8<---------------cut here---------------start------------->8---
> > $ guix size librsvg | tail -1
> > total: 207.2 MiB
> > $ guix size librsvg rust | tail -1
> > total: 1052.9 MiB
> > --8<---------------cut here---------------end--------------->8---
> >
> > Perhaps the size issue can be somewhat mitigated by adding a “lib”
> > output to the Rust package, but even then it would probably still be an
> > issue.
> 
> Librsvg does not depend on Rust at run-time, so the closure size should
> be similar.  However I notice it has a 129MiB (!!) librsvg-2.a, which
> should be removed.  I will do that later.
> 
> > Also, is the new librsvg API-compatible with the old one?  IIUC it still
> > provides a C API, right?  Does guile-rsvg still work, for example?
> 
> I have not noticed any regressions since the switch.  The guile-rsvg
> tests pass, at least!
> 
> > What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
> > that architectures where Rust isn’t supported yet could still work:
> > <https://lwn.net/Articles/771355/>.
> 
> I wanted to ask about this: is Rust supported on all the platforms we
> support at the moment?

x86_64-unknown-linux, i686-unknown-linux, aarch64-unknow-linux,
 armv7-unknown-linux, did I miss anything?

https://forge.rust-lang.org/platform-support.html
 
> While depending on Rust for GTK/GNOME is unfortunate, I do think it's
> inevitable.
> 
> By the way, the next version of librsvg will require Rust 1.33 or
> thereabouts.

Re: librsvg & Rust

[Mark H Weaver]

Marius Bakke <mbakke@fastmail.com> writes:
> I wanted to ask about this: is Rust supported on all the platforms we
> support at the moment?

On hydra.gnu.org, our rust packages can only successfully be built on
x86_64-linux.  They fail to build on i686-linux and armhf-linux.  I
don't know about aarch64-linux.

       Mark

Re: librsvg & Rust

[Efraim Flashner]

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

On Wed, Mar 06, 2019 at 06:55:18PM -0500, Mark H Weaver wrote:
> Marius Bakke <mbakke@fastmail.com> writes:
> > I wanted to ask about this: is Rust supported on all the platforms we
> > support at the moment?
> 
> On hydra.gnu.org, our rust packages can only successfully be built on
> x86_64-linux.  They fail to build on i686-linux and armhf-linux.  I
> don't know about aarch64-linux.
> 
>        Mark
> 

rust fails to build on aarch64 on staging, I haven't tested master
recently

-- 
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: librsvg & Rust

[Danny Milosavljevic]

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

Hi Mark,

On Wed, 06 Mar 2019 18:55:18 -0500
Mark H Weaver <mhw@netris.org> wrote:

> Marius Bakke <mbakke@fastmail.com> writes:
> > I wanted to ask about this: is Rust supported on all the platforms we
> > support at the moment?  
> 
> On hydra.gnu.org, our rust packages can only successfully be built on
> x86_64-linux.  They fail to build on i686-linux and armhf-linux.  I
> don't know about aarch64-linux.

Right.

I've talked to upstream and they acknowledge that there is a problem
but they haven't found it yet.

Since there was no improvement in a reasonable time frame, let's
re-add a binary-only bootstrap rust and use it in case of non-x86_64
in order to have working rust.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: librsvg & Rust

[Danny Milosavljevic]

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

Hi,

On Fri, 8 Mar 2019 02:52:05 +0100
Danny Milosavljevic <dannym@scratchpost.org> wrote:

> > On hydra.gnu.org, our rust packages can only successfully be built on
> > x86_64-linux.  They fail to build on i686-linux and armhf-linux.  I
> > don't know about aarch64-linux.  

Could we link to the hydra pages containing the respective log files in reports?
Using Hydra is like pulling teeth and it would be a lot easier for me to track
the failures that way.

http://hydra.gnu.org/build/3385267/nixlog/3/raw seems to be the latest
armhf-linux build attempt on master and it says:

building of `/gnu/store/xqwkq4hvc3wq7pvx4fcj3sws55zp64b7-rust-1.19.0.drv' timed out after 3600 seconds of silence

However, rust-1.19 on master has:

    (properties '((timeout . 72000)               ;20 hours
                  (max-silent-time . 18000)))     ;5 hours (for armel)

Why does it already time out after 3600 seconds of silence although it's configured to stand 18000 seconds of silence?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: librsvg & Rust

[Ludovic Courtès]

Hello!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> http://hydra.gnu.org/build/3385267/nixlog/3/raw seems to be the latest
> armhf-linux build attempt on master and it says:
>
> building of `/gnu/store/xqwkq4hvc3wq7pvx4fcj3sws55zp64b7-rust-1.19.0.drv' timed out after 3600 seconds of silence
>
> However, rust-1.19 on master has:
>
>     (properties '((timeout . 72000)               ;20 hours
>                   (max-silent-time . 18000)))     ;5 hours (for armel)
>
> Why does it already time out after 3600 seconds of silence although it's configured to stand 18000 seconds of silence?

Note that these properties are ignored by Cuirass, and I believe there
can be cases on Hydra where it’s not honored either (e.g., if
‘rust-1.19’ is built has a dependency of another job.)

Ludo’.

Re: librsvg & Rust

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> guix-commits@gnu.org skribis:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit ec47c07d0690653be35a75b346f3c3548a3e71d4
>>> Author: Marius Bakke <mbakke@fastmail.com>
>>> Date:   Wed Oct 24 15:26:10 2018 +0200
>>>
>>>     gnu: librsvg: Update to 2.44.12.
>>>     
>>>     * gnu/packages/gnome.scm (librsvg): Update to 2.44.12.
>>>     [arguments]: Replace patching phases with custom variants.  Delete five new
>>>     tests.
>>>     [native-inputs]: Add RUST-1.27 and RUST-1.27:CARGO.
>>
>> This change was bound to happen since upstream switched to Rust, but
>> it creates a few issues.
>>
>> First, that adds Rust to the base graphical applications, which
>> significantly increases build times and size:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ guix size librsvg | tail -1
>> total: 207.2 MiB
>> $ guix size librsvg rust | tail -1
>> total: 1052.9 MiB
>> --8<---------------cut here---------------end--------------->8---
>>
>> Perhaps the size issue can be somewhat mitigated by adding a “lib”
>> output to the Rust package, but even then it would probably still be an
>> issue.
>
> Librsvg does not depend on Rust at run-time, so the closure size should
> be similar.  However I notice it has a 129MiB (!!) librsvg-2.a, which
> should be removed.  I will do that later.

OK, good.

>> Also, is the new librsvg API-compatible with the old one?  IIUC it still
>> provides a C API, right?  Does guile-rsvg still work, for example?
>
> I have not noticed any regressions since the switch.  The guile-rsvg
> tests pass, at least!

One test would be to do ‘guix system vm-image --full-boot’ or something,
to generate the derivation that builds the GRUB background image, which
uses Guile-RSVG.

>> What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
>> that architectures where Rust isn’t supported yet could still work:
>> <https://lwn.net/Articles/771355/>.
>
> I wanted to ask about this: is Rust supported on all the platforms we
> support at the moment?

According to Efraim and Danny, we have a problem at the moment.
Presumably that can be worked around?

> While depending on Rust for GTK/GNOME is unfortunate, I do think it's
> inevitable.

Yeah.

> By the way, the next version of librsvg will require Rust 1.33 or
> thereabouts.

Oh so we’re lagging already?

Thanks,
Ludo’.

Re: librsvg & Rust

[Marius Bakke]

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

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

>>> Also, is the new librsvg API-compatible with the old one?  IIUC it still
>>> provides a C API, right?  Does guile-rsvg still work, for example?
>>
>> I have not noticed any regressions since the switch.  The guile-rsvg
>> tests pass, at least!
>
> One test would be to do ‘guix system vm-image --full-boot’ or something,
> to generate the derivation that builds the GRUB background image, which
> uses Guile-RSVG.

OK, good to know.  The background image is fine (I'm using this branch
on real hardware).

>>> What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
>>> that architectures where Rust isn’t supported yet could still work:
>>> <https://lwn.net/Articles/771355/>.
>>
>> I wanted to ask about this: is Rust supported on all the platforms we
>> support at the moment?
>
> According to Efraim and Danny, we have a problem at the moment.
> Presumably that can be worked around?

Right, Rust currently only works on x86_64.  In order to get this branch
started, let us either:

* Revert back to 2.40.20, or
* Conditionally use the new version on supported platforms

For the latter, I imagine something along the lines of...

(define-public librsvg
  (if (string-prefix? "x86_64" (or (%current-target-system)
                                   (%current-system)))
      librsvg-2.44
      librsvg-2.40))

Preferences?

>> While depending on Rust for GTK/GNOME is unfortunate, I do think it's
>> inevitable.
>
> Yeah.
>
>> By the way, the next version of librsvg will require Rust 1.33 or
>> thereabouts.
>
> Oh so we’re lagging already?

I was referring to the 2.46 series, but indeed 2.44.13 also fails with
Rust 1.27 (we're at 2.44.12).

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

Re: librsvg & Rust

[Ivan Petkov]

> On Mar 15, 2019, at 6:39 AM, Marius Bakke <mbakke@fastmail.com> wrote:
> 
>> 
>>> By the way, the next version of librsvg will require Rust 1.33 or
>>> thereabouts.
>> 
>> Oh so we’re lagging already?
> 
> I was referring to the 2.46 series, but indeed 2.44.13 also fails with
> Rust 1.27 (we're at 2.44.12).

I have a working patch ready for packaging 1.33, which I’ll submit after #34820
gets merged, so we won't be behind for long :)

—Ivan

Re: librsvg & Rust

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

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

[...]

>>> I wanted to ask about this: is Rust supported on all the platforms we
>>> support at the moment?
>>
>> According to Efraim and Danny, we have a problem at the moment.
>> Presumably that can be worked around?
>
> Right, Rust currently only works on x86_64.  In order to get this branch
> started, let us either:
>
> * Revert back to 2.40.20, or
> * Conditionally use the new version on supported platforms
>
> For the latter, I imagine something along the lines of...
>
> (define-public librsvg
>   (if (string-prefix? "x86_64" (or (%current-target-system)
>                                    (%current-system)))
>       librsvg-2.44
>       librsvg-2.40))

It would have to be a macro so that the conditional is evaluated in a
context where (%current-system) and (%current-target-system) have the
right value, like the ‘glibc’ macro we had until commit
2d546858b139e5fcf2cbdf9958a17fd98803ac4c.

> Preferences?

I have a slight preference for having the same librsvg on all platforms.

So we could add 2.44 alongside 2.40, but keep using 2.40 until our Rust
package works on all the platforms.

That said, if the chances are that Rust won’t work on all 4 platforms in
the foreseeable future, the other option (upgrading on platforms where
Rust is supported) may be preferable.

Your call!  :-)

Thanks,
Ludo’.

Re: librsvg & Rust

[Marius Bakke]

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

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

> Hi!
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>>> I wanted to ask about this: is Rust supported on all the platforms we
>>>> support at the moment?
>>>
>>> According to Efraim and Danny, we have a problem at the moment.
>>> Presumably that can be worked around?
>>
>> Right, Rust currently only works on x86_64.  In order to get this branch
>> started, let us either:
>>
>> * Revert back to 2.40.20, or
>> * Conditionally use the new version on supported platforms
>>
>> For the latter, I imagine something along the lines of...
>>
>> (define-public librsvg
>>   (if (string-prefix? "x86_64" (or (%current-target-system)
>>                                    (%current-system)))
>>       librsvg-2.44
>>       librsvg-2.40))
>
> It would have to be a macro so that the conditional is evaluated in a
> context where (%current-system) and (%current-target-system) have the
> right value, like the ‘glibc’ macro we had until commit
> 2d546858b139e5fcf2cbdf9958a17fd98803ac4c.

Right, thanks!

>> Preferences?
>
> I have a slight preference for having the same librsvg on all platforms.
>
> So we could add 2.44 alongside 2.40, but keep using 2.40 until our Rust
> package works on all the platforms.
>
> That said, if the chances are that Rust won’t work on all 4 platforms in
> the foreseeable future, the other option (upgrading on platforms where
> Rust is supported) may be preferable.
>
> Your call!  :-)

I don't have a strong opinion, so I restored the previous librsvg
variant for now and kept the Rust one as 'librsvg-next' with commit
f67417a1b4d3fbd3a2e1593d32422e0d901ba367.

Let's "freeze" and try to merge this branch soon.  Are there any pending
patches?

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

Re: librsvg & Rust

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

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

[...]

> I don't have a strong opinion, so I restored the previous librsvg
> variant for now and kept the Rust one as 'librsvg-next' with commit
> f67417a1b4d3fbd3a2e1593d32422e0d901ba367.

Great.

> Let's "freeze" and try to merge this branch soon.  Are there any pending
> patches?

I don’t think so, let’s try to merge ‘staging’!

Thanks,
Ludo’.