Building grub-image.png.drv fails with rsvg

Done

Details

5 participants

Efraim Flashner
vicvbcun
Leo Famulari
Roman Scherer
Roman Scherer

Owner: unassigned

Submitted by: Roman Scherer

Severity: normal

Roman Scherer wrote on 12 Jan 10:58 +0100

Recipients:(address . bug-guix@gnu.org)

Message-ID:86bjwcs68x.fsf@burningswell.com

Hello Guix,

I can't reconfigure my (aarch64) system anymore. When building
/gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:

```
building /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv...
Backtrace:
           2 (primitive-load "/gnu/store/3rcg4ann6607iqsh1aj84cqdnw8?")
In gnu/build/svg.scm:
     53:6  1 (svg->png "/gnu/store/41841pid2mmsvar44vy9xafsrf3cyb9i?" ?)
In unknown file:
           0 (rsvg-handle-render-cairo #<rsvg-handle fffff770ae60> #)

ERROR: In procedure rsvg-handle-render-cairo:
Wrong type (expecting finalized smob): #<cairo-context fffff770ad90>
builder for `/gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv' failed with exit code 1
build of /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv failed
View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
applying 4 grafts for asahi-scripts-20240623 ...
cannot build derivation `/gnu/store/mnavmxm513zwy16m1lyz2yppdgjbam3l-grub.cfg.drv': 1 dependencies couldn't be built
guix system: error: build of `/gnu/store/mnavmxm513zwy16m1lyz2yppdgjbam3l-grub.cfg.drv' failed
```

Any ideas how to fix this?

Leo Famulari wrote on 12 Jan 21:30 +0100

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)(address . 75510@debbugs.gnu.org)

Message-ID:Z4QmT1tGJj5hhvPu@jasmine.lan

On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote:

Toggle quote (4 lines)

> I can't reconfigure my (aarch64) system anymore. When building

> /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:

[...]

Toggle quote (2 lines)

> View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.

Can you share this log?

Roman Scherer wrote on 12 Jan 23:12 +0100

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 75510@debbugs.gnu.org)

Message-ID:865xmj8ywa.fsf@burningswell.com

Leo Famulari <leo@famulari.name> writes:

Hi Leo,

the log only contains the backtrace from my previous mail, it is this:

-----------------------------------------------------------------------------

Backtrace:

2 (primitive-load "/gnu/store/3rcg4ann6607iqsh1aj84cqdnw8?")

In gnu/build/svg.scm:

53:6 1 (svg->png "/gnu/store/41841pid2mmsvar44vy9xafsrf3cyb9i?" ?)

In unknown file:

0 (rsvg-handle-render-cairo #<rsvg-handle fffff770ae60> #)

ERROR: In procedure rsvg-handle-render-cairo:

Wrong type (expecting finalized smob): #<cairo-context fffff770ad90>

-----------------------------------------------------------------------------

Roman

Toggle quote (10 lines)> On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote:
>>
>> I can't reconfigure my (aarch64) system anymore. When building
>> /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
>
> [...]
>
>> View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
>
> Can you share this log?

Leo Famulari wrote on 13 Jan 04:20 +0100

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)(address . 75510@debbugs.gnu.org)

Message-ID:Z4SGazuOKCWp6Z61@jasmine.lan

On Sun, Jan 12, 2025 at 03:30:07PM -0500, Leo Famulari wrote:

Toggle quote (11 lines)> On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote:
> > 
> > I can't reconfigure my (aarch64) system anymore. When building
> > /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
> 
> [...]
> 
> > View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
> 
> Can you share this log?

Okay, thanks.

Also, from the environment where you try to reconfigure, can you also

share the results of `guix describe`?

What I mean by that is, for example, if you log in to the root account

to reconfigure, run `guix describe` from there.

Another example: if you do `sudo -i guix system reconfigure [...]`, run

`sudo -i guix describe`.

Does that make sense?

Roman Scherer wrote on 13 Jan 10:12 +0100

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 75510@debbugs.gnu.org)

Message-ID:86zfjv6prg.fsf@burningswell.com

Hi Leo,

here is the `guix desribe` run as my normal user account.

```

[roman@m1 guix-home]$ guix describe

Generation 305 Jan 12 2025 09:17:24 (current)

asahi 2a6f8b5

repository URL: https://github.com/asahi-guix/channel

branch: main

commit: 2a6f8b59d97a3451639f128ff1c53d9009897e45

guix 5d6c876

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 5d6c8767f67885bc9b2c8f18ab1f667d0065346b

nonguix 565d287

repository URL: https://gitlab.com/nonguix/nonguix

branch: master

commit: 565d287b7502ef9435b2fba38622d0a8f458677b

r0man-guix 9bb5571

repository URL: https://github.com/r0man/guix-channel

branch: main

commit: 9bb55710a8dc61a23c6cc4e8d2bcdc9503008492

```

As this user I usually run the following command to reconfigure my

system.

```

sudo guix system reconfigure -L modules modules/r0man/guix/system/m1.scm

-v 5

```

I don't use the -i flag when reconfiguring. Is that problematic?

So here's the guix describe I usually get when I'm reconfiguring my

system:

[roman@m1 guix-home]$ sudo guix describe

asahi 2a6f8b5

repository URL: https://github.com/asahi-guix/channel

branch: main

commit: 2a6f8b59d97a3451639f128ff1c53d9009897e45

guix 5d6c876

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 5d6c8767f67885bc9b2c8f18ab1f667d0065346b

nonguix 565d287

repository URL: https://gitlab.com/nonguix/nonguix

branch: master

commit: 565d287b7502ef9435b2fba38622d0a8f458677b

r0man-guix 9bb5571

repository URL: https://github.com/r0man/guix-channel

branch: main

commit: 9bb55710a8dc61a23c6cc4e8d2bcdc9503008492

And this is the "guix describe" with the -i flag:

[roman@m1 guix-home]$ sudo -i guix describe

guix 121e96d

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 121e96dca273ab407df11725da0026ee34abdf79

Reconfiguring with the -i flag does not work, because I'm missing some

modules from the channels that aren't listed there.

I'm also linking my config, just in case:

https://github.com/r0man/guix-home/blob/main/modules/r0man/guix/system/m1.scm

Thanks for your help, Roman.

Leo Famulari <leo@famulari.name> writes:

Toggle quote (24 lines)> On Sun, Jan 12, 2025 at 03:30:07PM -0500, Leo Famulari wrote:
>> On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote:
>> >
>> > I can't reconfigure my (aarch64) system anymore. When building
>> > /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
>>
>> [...]
>>
>> > View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
>>
>> Can you share this log?
>
> Okay, thanks.
>
> Also, from the environment where you try to reconfigure, can you also
> share the results of `guix describe`?
>
> What I mean by that is, for example, if you log in to the root account
> to reconfigure, run `guix describe` from there.
>
> Another example: if you do `sudo -i guix system reconfigure [...]`, run
> `sudo -i guix describe`.
>
> Does that make sense?

Roman Scherer wrote on 16 Jan 18:39 +0100

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 75510@debbugs.gnu.org)

Message-ID:86ed12vesy.fsf@burningswell.com

Roman Scherer <roman.scherer@burningswell.com> writes:

So, it looks like this issue might be related to:

- https://issues.guix.gnu.org/47853

- https://issues.guix.gnu.org/47115

I reconfigured my system now with --no-grafts, and this time it worked.

Toggle quote (101 lines)> <#secure method=pgpmime mode=sign>
>
> Hi Leo,
>
> here is the `guix desribe` run as my normal user account.
>
> ```
> [roman@m1 guix-home]$ guix describe
> Generation 305	Jan 12 2025 09:17:24	(current)
>   asahi 2a6f8b5
>     repository URL: https://github.com/asahi-guix/channel
>     branch: main
>     commit: 2a6f8b59d97a3451639f128ff1c53d9009897e45
>   guix 5d6c876
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 5d6c8767f67885bc9b2c8f18ab1f667d0065346b
>   nonguix 565d287
>     repository URL: https://gitlab.com/nonguix/nonguix
>     branch: master
>     commit: 565d287b7502ef9435b2fba38622d0a8f458677b
>   r0man-guix 9bb5571
>     repository URL: https://github.com/r0man/guix-channel
>     branch: main
>     commit: 9bb55710a8dc61a23c6cc4e8d2bcdc9503008492
> ```
>
> As this user I usually run the following command to reconfigure my
> system.
>
> ```
> sudo guix system reconfigure -L modules modules/r0man/guix/system/m1.scm
> -v 5
> ```
>
> I don't use the -i flag when reconfiguring. Is that problematic?
>
> So here's the guix describe I usually get when I'm reconfiguring my
> system:
>
> [roman@m1 guix-home]$ sudo guix describe
>   asahi 2a6f8b5
>     repository URL: https://github.com/asahi-guix/channel
>     branch: main
>     commit: 2a6f8b59d97a3451639f128ff1c53d9009897e45
>   guix 5d6c876
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 5d6c8767f67885bc9b2c8f18ab1f667d0065346b
>   nonguix 565d287
>     repository URL: https://gitlab.com/nonguix/nonguix
>     branch: master
>     commit: 565d287b7502ef9435b2fba38622d0a8f458677b
>   r0man-guix 9bb5571
>     repository URL: https://github.com/r0man/guix-channel
>     branch: main
>     commit: 9bb55710a8dc61a23c6cc4e8d2bcdc9503008492
>
> And this is the "guix describe" with the -i flag:
>
> [roman@m1 guix-home]$ sudo -i guix describe
>   guix 121e96d
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 121e96dca273ab407df11725da0026ee34abdf79
>
> Reconfiguring with the -i flag does not work, because I'm missing some
> modules from the channels that aren't listed there.
>
> I'm also linking my config, just in case:
>
> https://github.com/r0man/guix-home/blob/main/modules/r0man/guix/system/m1.scm
>
> Thanks for your help, Roman.
>
> Leo Famulari <leo@famulari.name> writes:
>
>> On Sun, Jan 12, 2025 at 03:30:07PM -0500, Leo Famulari wrote:
>>> On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote:
>>> >
>>> > I can't reconfigure my (aarch64) system anymore. When building
>>> > /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
>>>
>>> [...]
>>>
>>> > View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
>>>
>>> Can you share this log?
>>
>> Okay, thanks.
>>
>> Also, from the environment where you try to reconfigure, can you also
>> share the results of `guix describe`?
>>
>> What I mean by that is, for example, if you log in to the root account
>> to reconfigure, run `guix describe` from there.
>>
>> Another example: if you do `sudo -i guix system reconfigure [...]`, run
>> `sudo -i guix describe`.
>>
>> Does that make sense?

Roman Scherer wrote on 17 Jan 15:48 +0100

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 75510@debbugs.gnu.org)

Message-ID:861px1jy3f.fsf@burningswell.com

Roman Scherer <roman.scherer@burningswell.com> writes:

Hmm, but it looks I'm now stuck using --no-grafts all the time. Any

ideas how to solve that?

Toggle quote (110 lines)> Roman Scherer <roman.scherer@burningswell.com> writes:
>
> So, it looks like this issue might be related to:
>
> - https://issues.guix.gnu.org/47853
> - https://issues.guix.gnu.org/47115
>
> I reconfigured my system now with --no-grafts, and this time it worked.
>
>> <#secure method=pgpmime mode=sign>
>>
>> Hi Leo,
>>
>> here is the `guix desribe` run as my normal user account.
>>
>> ```
>> [roman@m1 guix-home]$ guix describe
>> Generation 305	Jan 12 2025 09:17:24	(current)
>>   asahi 2a6f8b5
>>     repository URL: https://github.com/asahi-guix/channel
>>     branch: main
>>     commit: 2a6f8b59d97a3451639f128ff1c53d9009897e45
>>   guix 5d6c876
>>     repository URL: https://git.savannah.gnu.org/git/guix.git
>>     branch: master
>>     commit: 5d6c8767f67885bc9b2c8f18ab1f667d0065346b
>>   nonguix 565d287
>>     repository URL: https://gitlab.com/nonguix/nonguix
>>     branch: master
>>     commit: 565d287b7502ef9435b2fba38622d0a8f458677b
>>   r0man-guix 9bb5571
>>     repository URL: https://github.com/r0man/guix-channel
>>     branch: main
>>     commit: 9bb55710a8dc61a23c6cc4e8d2bcdc9503008492
>> ```
>>
>> As this user I usually run the following command to reconfigure my
>> system.
>>
>> ```
>> sudo guix system reconfigure -L modules modules/r0man/guix/system/m1.scm
>> -v 5
>> ```
>>
>> I don't use the -i flag when reconfiguring. Is that problematic?
>>
>> So here's the guix describe I usually get when I'm reconfiguring my
>> system:
>>
>> [roman@m1 guix-home]$ sudo guix describe
>>   asahi 2a6f8b5
>>     repository URL: https://github.com/asahi-guix/channel
>>     branch: main
>>     commit: 2a6f8b59d97a3451639f128ff1c53d9009897e45
>>   guix 5d6c876
>>     repository URL: https://git.savannah.gnu.org/git/guix.git
>>     branch: master
>>     commit: 5d6c8767f67885bc9b2c8f18ab1f667d0065346b
>>   nonguix 565d287
>>     repository URL: https://gitlab.com/nonguix/nonguix
>>     branch: master
>>     commit: 565d287b7502ef9435b2fba38622d0a8f458677b
>>   r0man-guix 9bb5571
>>     repository URL: https://github.com/r0man/guix-channel
>>     branch: main
>>     commit: 9bb55710a8dc61a23c6cc4e8d2bcdc9503008492
>>
>> And this is the "guix describe" with the -i flag:
>>
>> [roman@m1 guix-home]$ sudo -i guix describe
>>   guix 121e96d
>>     repository URL: https://git.savannah.gnu.org/git/guix.git
>>     branch: master
>>     commit: 121e96dca273ab407df11725da0026ee34abdf79
>>
>> Reconfiguring with the -i flag does not work, because I'm missing some
>> modules from the channels that aren't listed there.
>>
>> I'm also linking my config, just in case:
>>
>> https://github.com/r0man/guix-home/blob/main/modules/r0man/guix/system/m1.scm
>>
>> Thanks for your help, Roman.
>>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> On Sun, Jan 12, 2025 at 03:30:07PM -0500, Leo Famulari wrote:
>>>> On Sun, Jan 12, 2025 at 10:58:54AM +0100, Roman Scherer wrote:
>>>> >
>>>> > I can't reconfigure my (aarch64) system anymore. When building
>>>> > /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
>>>>
>>>> [...]
>>>>
>>>> > View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
>>>>
>>>> Can you share this log?
>>>
>>> Okay, thanks.
>>>
>>> Also, from the environment where you try to reconfigure, can you also
>>> share the results of `guix describe`?
>>>
>>> What I mean by that is, for example, if you log in to the root account
>>> to reconfigure, run `guix describe` from there.
>>>
>>> Another example: if you do `sudo -i guix system reconfigure [...]`, run
>>> `sudo -i guix describe`.
>>>
>>> Does that make sense?

Leo Famulari wrote on 17 Jan 20:22 +0100

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)(address . 75510@debbugs.gnu.org)

Message-ID:Z4qt2iNzoLLsmzB_@jasmine.lan

On Fri, Jan 17, 2025 at 03:48:04PM +0100, Roman Scherer wrote:

Toggle quote (5 lines)

> Roman Scherer <roman.scherer@burningswell.com> writes:

> Hmm, but it looks I'm now stuck using --no-grafts all the time. Any

> ideas how to solve that?

That's not great. I don't really understand this bug. Is it a problem in

Guile? That would seem hard to fix in the short term.

I wonder what is the current status of "ungrafting" efforts in Guix?

vicvbcun wrote on 21 Jan 10:28 +0100

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)

Message-ID:Z49oywSPyExSDssV@lambda

Hi,

On 2025-01-12T10:58:54+0100, Roman Scherer wrote:

Toggle quote (27 lines)>
>Hello Guix,
>
>I can't reconfigure my (aarch64) system anymore. When building
>/gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
>
>```
>building /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv...
>Backtrace:
>           2 (primitive-load "/gnu/store/3rcg4ann6607iqsh1aj84cqdnw8?")
>In gnu/build/svg.scm:
>     53:6  1 (svg->png "/gnu/store/41841pid2mmsvar44vy9xafsrf3cyb9i?" ?)
>In unknown file:
>           0 (rsvg-handle-render-cairo #<rsvg-handle fffff770ae60> #)
>
>ERROR: In procedure rsvg-handle-render-cairo:
>Wrong type (expecting finalized smob): #<cairo-context fffff770ad90>
>builder for `/gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv' failed with exit code 1
>build of /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv failed
>View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
>applying 4 grafts for asahi-scripts-20240623 ...
>cannot build derivation `/gnu/store/mnavmxm513zwy16m1lyz2yppdgjbam3l-grub.cfg.drv': 1 dependencies couldn't be built
>guix system: error: build of `/gnu/store/mnavmxm513zwy16m1lyz2yppdgjbam3l-grub.cfg.drv' failed
>```
>
>Any ideas how to fix this?

I have the same problem on my server, also aarch64-linux.  A minimal 
reproducer that fails on both my server and my laptop (x86_64-linux) is

     guix build -s aarch64-linux -e '
     (begin
      (use-modules (gnu bootloader)
                   (gnu bootloader grub))
      ((@@ (gnu bootloader grub) grub-background-image)
       (bootloader-configuration
        (bootloader grub-efi-bootloader))))
     '

I have tried bisecting it with this (see the attached log) and ended up 
at commit
     6975b1871b (gnu: rust-ring-0.17: Build source using trivial-build-system., 2024-12-15)
If I revert this commit and additionally
     584c79d5df (gnu: rust-ring-0.13: Build source using trivial-build-system., 2024-12-17)
     57be7a0184 (gnu: rust-ring-0.14: Build source using trivial-build-system., 2024-12-17)
     7db675130f (gnu: rust-ring-0.16: Build source using trivial-build-system., 2024-12-17)
(make fails when reverting only 6975b1871b) on top of commit
     87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)
I get no error.  No idea what that has to do with grafts though.

vicvbcun

git bisect start
# status: waiting for both good and bad commits
# good: [af07f6bfe94bb3dac1f46533e586d4186d7e59b6] gnu: python-trio-websocket: Update to 0.11.1.
git bisect good af07f6bfe94bb3dac1f46533e586d4186d7e59b6
# status: waiting for bad commit, 1 good commit known
# bad: [87045f0982bd7aebb07b380cbf322651227546f4] gnu: paritwine: Update to 0.2.1.
git bisect bad 87045f0982bd7aebb07b380cbf322651227546f4
# bad: [312c7d4b7bb084a54a6d39273c1e1da37dc9971e] gnu: zoxide: Update to 0.9.6.
git bisect bad 312c7d4b7bb084a54a6d39273c1e1da37dc9971e
# bad: [db99452d7d776f69a3745b6e072b63d212c9cd1e] gnu: rust-derive-arbitrary-1: Update to 1.4.1.
git bisect bad db99452d7d776f69a3745b6e072b63d212c9cd1e
# good: [701159efe0ad0cae514c5bd690ff2d897d2633eb] gnu: rust-http-body-util-0.1: Update to 0.1.2.
git bisect good 701159efe0ad0cae514c5bd690ff2d897d2633eb
# bad: [a7950bf0699ae1faa763b1220c76fec08898936d] gnu: rust-git-testament-0.2: Update to 0.2.6.
git bisect bad a7950bf0699ae1faa763b1220c76fec08898936d
# good: [a7af54ec322297cd171000fbe9df6fe70f59a482] gnu: Add rust-pyo3-0.23.
git bisect good a7af54ec322297cd171000fbe9df6fe70f59a482
# bad: [979839cf777b42675db22d4df2cb38a4b5835256] gnu: x265: Link together all library variants.
git bisect bad 979839cf777b42675db22d4df2cb38a4b5835256
# bad: [57ed4771e9c0d571510e613f70f3fc578901fd60] gnu: rust-ruzstd-0.7: Update to 0.7.3.
git bisect bad 57ed4771e9c0d571510e613f70f3fc578901fd60
# good: [5c48aa9954085b276491e85f0980a817ac8f2c7d] gnu: alacritty: Skip a test.
git bisect good 5c48aa9954085b276491e85f0980a817ac8f2c7d
# bad: [584c79d5dfb10208a9704a01f79af79f7d012544] gnu: rust-ring-0.13: Build source using trivial-build-system.
git bisect bad 584c79d5dfb10208a9704a01f79af79f7d012544
# bad: [7db675130fca0a17e3d7e9631a117c3bba883d22] gnu: rust-ring-0.16: Build source using trivial-build-system.
git bisect bad 7db675130fca0a17e3d7e9631a117c3bba883d22
# bad: [6975b1871bce10a5aeffc49aa37271d7a7555ca1] gnu: rust-ring-0.17: Build source using trivial-build-system.
git bisect bad 6975b1871bce10a5aeffc49aa37271d7a7555ca1
# first bad commit: [6975b1871bce10a5aeffc49aa37271d7a7555ca1] gnu: rust-ring-0.17: Build source using trivial-build-system.

Roman Scherer wrote on 21 Jan 13:29 +0100

Recipients:(name . vicvbcun)(address . guix@ikherbers.com)

Message-ID:86v7u8uz7v.fsf@burningswell.com

Hi vicvbcun,

thanks looking into this! Good to know when this started failing, but

I'm still lost understanding what the issue is, why it works without

grafts, or how to fix it.

Maybe Efraim has an idea? I put him on CC.

Thanks for your help!

Roman

vicvbcun <guix@ikherbers.com> writes:

Toggle quote (57 lines)> Hi,
>
> On 2025-01-12T10:58:54+0100, Roman Scherer wrote:
>>
>>Hello Guix,
>>
>>I can't reconfigure my (aarch64) system anymore. When building
>>/gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv I see the following backtrace:
>>
>>```
>>building /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv...
>>Backtrace:
>>           2 (primitive-load "/gnu/store/3rcg4ann6607iqsh1aj84cqdnw8?")
>>In gnu/build/svg.scm:
>>     53:6  1 (svg->png "/gnu/store/41841pid2mmsvar44vy9xafsrf3cyb9i?" ?)
>>In unknown file:
>>           0 (rsvg-handle-render-cairo #<rsvg-handle fffff770ae60> #)
>>
>>ERROR: In procedure rsvg-handle-render-cairo:
>>Wrong type (expecting finalized smob): #<cairo-context fffff770ad90>
>>builder for `/gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv' failed with exit code 1
>>build of /gnu/store/bpda8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv failed
>>View build log at '/var/log/guix/drvs/bp/da8gfvxm6iv3mc6n8sf3ydxc5b6zi9-grub-image.png.drv.gz'.
>>applying 4 grafts for asahi-scripts-20240623 ...
>>cannot build derivation `/gnu/store/mnavmxm513zwy16m1lyz2yppdgjbam3l-grub.cfg.drv': 1 dependencies couldn't be built
>>guix system: error: build of `/gnu/store/mnavmxm513zwy16m1lyz2yppdgjbam3l-grub.cfg.drv' failed
>>```
>>
>>Any ideas how to fix this?
>
> I have the same problem on my server, also aarch64-linux.  A minimal
> reproducer that fails on both my server and my laptop (x86_64-linux)
> is
>
>     guix build -s aarch64-linux -e '
>     (begin
>      (use-modules (gnu bootloader)
>                   (gnu bootloader grub))
>      ((@@ (gnu bootloader grub) grub-background-image)
>       (bootloader-configuration
>        (bootloader grub-efi-bootloader))))
>     '
>
> I have tried bisecting it with this (see the attached log) and ended
> up at commit
>     6975b1871b (gnu: rust-ring-0.17: Build source using trivial-build-system., 2024-12-15)
> If I revert this commit and additionally
>     584c79d5df (gnu: rust-ring-0.13: Build source using trivial-build-system., 2024-12-17)
>     57be7a0184 (gnu: rust-ring-0.14: Build source using trivial-build-system., 2024-12-17)
>     7db675130f (gnu: rust-ring-0.16: Build source using trivial-build-system., 2024-12-17)
> (make fails when reverting only 6975b1871b) on top of commit
>     87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)
> I get no error.  No idea what that has to do with grafts though.
>
> vicvbcun
>
> [2. text/plain; bisect-log.txt]...

vicvbcun wrote on 22 Jan 00:52 +0100

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)

Message-ID:Z5AzOQu6Pv0k0We6@lambda

Hi,

below are my current findings.

As of commit

87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)

guile-rsvg depends on a version of guile-cairo different from the one I

get by simply building guile-cairo:

$ ./pre-inst-env guix build guile-cairo

⇒ /gnu/store/k4kglplg98098y78flnw0f9wjyyc9zk2-guile-cairo-1.11.2

whereas

$ guix gc --references "$(./pre-inst-env guix build guile-rsvg)" | grep guile-cairo

⇒ /gnu/store/lz8cv73yzzrbwrhafzadixnwgmspz2cg-guile-cairo-1.11.2

(gnu build svg) loads both (rsvg) and (cairo) which causes two different

libguile-cairo.so's to be loaded (interestingly enough the order

matters: loading (cairo) first would hide the issue):

Toggle snippet (12 lines)

./pre-inst-env guix shell --no-cwd -C guile guile-cairo guile-rsvg -- \

guile -s /dev/stdin <<EOF | grep libguile-cairo

(begin

(use-modules (ice-9 textual-ports)

;; order matters!

(rsvg)

(cairo))

(display (call-with-input-file "/proc/self/maps" get-string-all)))

EOF

shows two different libguile-cairo.so's. The only difference between

the two guile-cairo derivation is that they graft cairo to different

derivations, which in turn differ only in grafting fontconfig-minimal to

different versions which finally only graft glibc and expat in different

order.

All this confirms the hypothesis Mark expressed in [0].

My guess is that the change to rust-ring somehow changes how it

interacts with grafting. Perhaps it is added / not added to some

hashtable, causing iteration order to change?

0: https://issues.guix.gnu.org/47115#23

Efraim Flashner wrote on 24 Jan 09:41 +0100

Recipients:

Message-ID:Z5NSPJWIbktkIXlq@3900XT

On Wed, Jan 22, 2025 at 12:52:25AM +0100, vicvbcun wrote:

Toggle quote (47 lines)> Hi,
> 
> below are my current findings.
> 
> As of commit
>     87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)
> guile-rsvg depends on a version of guile-cairo different from the one I get
> by simply building guile-cairo:
> 
>     $ ./pre-inst-env guix build guile-cairo
>     ⇒ /gnu/store/k4kglplg98098y78flnw0f9wjyyc9zk2-guile-cairo-1.11.2
> 
> whereas
> 
>     $ guix gc --references "$(./pre-inst-env guix build guile-rsvg)" | grep guile-cairo
>     ⇒ /gnu/store/lz8cv73yzzrbwrhafzadixnwgmspz2cg-guile-cairo-1.11.2
> 
> (gnu build svg) loads both (rsvg) and (cairo) which causes two different
> libguile-cairo.so's to be loaded (interestingly enough the order matters:
> loading (cairo) first would hide the issue):
> --8<---------------cut here---------------start------------->8---
> ./pre-inst-env guix shell --no-cwd -C guile guile-cairo guile-rsvg -- \
>     guile -s /dev/stdin <<EOF | grep libguile-cairo
> 
> (begin
>  (use-modules (ice-9 textual-ports)
>               ;; order matters!
>               (rsvg)
> 	            (cairo))
> 
> (display (call-with-input-file "/proc/self/maps" get-string-all)))
> EOF
> --8<---------------cut here---------------end--------------->8---
> shows two different libguile-cairo.so's.  The only difference between the
> two guile-cairo derivation is that they graft cairo to different
> derivations, which in turn differ only in grafting fontconfig-minimal to
> different versions which finally only graft glibc and expat in different
> order.
> 
> All this confirms the hypothesis Mark expressed in [0].
> 
> My guess is that the change to rust-ring somehow changes how it interacts
> with grafting.  Perhaps it is added / not added to some hashtable, causing
> iteration order to change?
> 
> 0: https://issues.guix.gnu.org/47115#23

I tried setting rust-ring's sources to #:target #f but that didn't make
any difference.  I feel like it shouldn't make a difference, and should
probably be #:target #f anyway, but that can be a different time.

I'm attaching a patch that creates the grub image using ungrafted
inputs.  I think it would make sense to go through and figure out which
derivations actually need to use grafted inputs and which ones don't
matter, but I'm not sure it's worth the maintenance burden to check them
regularly.

The image also seems like something that could be #:target #f and we
could cheat by getting a generated image built on a different
architecture, but that's never seemed to work that way, only for
cross-building.

-- 
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

From 5d617f45c32834fb645975787c4e364fc603e2cb Mon Sep 17 00:00:00 2001

Message-ID: <5d617f45c32834fb645975787c4e364fc603e2cb.1737707855.git.efraim@flashner.co.il>

inputs.

This fixes bug https://issues.guix.gnu.org/75510.

* gnu/bootloader/grub.scm (image->png): Create the grub-image using

ungrafted inputs.

Change-Id: Ia23dd081d9711c703b7bf795dc376e024bb5caff

---

gnu/bootloader/grub.scm | 7 ++++++-

1 file changed, 6 insertions(+), 1 deletion(-)

Toggle diff (24 lines)diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index c2462d5d036..e136482c541 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -140,7 +140,12 @@ (define* (image->png image #:key width height)
                              (svg->png #+image #$output
                                        #:width #$width
                                        #:height #$height))
-                           (copy-file #+image #$output))))))
+                           (copy-file #+image #$output))))
+                 ;; Work around a bug in grafts where different versions of
+                 ;; guile-cairo are loaded from (gnu build svg).
+                 ;; As seen in https://issues.guix.gnu.org/47115#23 and
+                 ;; in https://issues.guix.gnu.org/75510.
+                 #:options '(#:graft? #f)))
 
 (define* (grub-background-image config)
   "Return the GRUB background image defined in CONFIG or #f if none was found.

base-commit: 97fe03d53635de996028562da9e65b697eedf0f5
-- 
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

Roman Scherer wrote on 24 Jan 10:55 +0100

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:86zfjg359l.fsf@burningswell.com

Hi Efraim,

thanks for looking into this! Much appreciated. I just tried your patch

and reconfigured my system as usual without using --no-grafts and I can

confirm that it is working again.

I'm not very familiar with grafts and have a question. When no grafts

are used for building the Grub image, does it mean it uses packages with

no security updates applied, or is it just that the grafts are not used

and the packages are built from scratch using the latest security

updates?

Thanks, Roman.

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

Toggle quote (62 lines)> On Wed, Jan 22, 2025 at 12:52:25AM +0100, vicvbcun wrote:
>> Hi,
>>
>> below are my current findings.
>>
>> As of commit
>>     87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)
>> guile-rsvg depends on a version of guile-cairo different from the one I get
>> by simply building guile-cairo:
>>
>>     $ ./pre-inst-env guix build guile-cairo
>>     ⇒ /gnu/store/k4kglplg98098y78flnw0f9wjyyc9zk2-guile-cairo-1.11.2
>>
>> whereas
>>
>>     $ guix gc --references "$(./pre-inst-env guix build guile-rsvg)" | grep guile-cairo
>>     ⇒ /gnu/store/lz8cv73yzzrbwrhafzadixnwgmspz2cg-guile-cairo-1.11.2
>>
>> (gnu build svg) loads both (rsvg) and (cairo) which causes two different
>> libguile-cairo.so's to be loaded (interestingly enough the order matters:
>> loading (cairo) first would hide the issue):
>> --8<---------------cut here---------------start------------->8---
>> ./pre-inst-env guix shell --no-cwd -C guile guile-cairo guile-rsvg -- \
>>     guile -s /dev/stdin <<EOF | grep libguile-cairo
>>
>> (begin
>>  (use-modules (ice-9 textual-ports)
>>               ;; order matters!
>>               (rsvg)
>> 	            (cairo))
>>
>> (display (call-with-input-file "/proc/self/maps" get-string-all)))
>> EOF
>> --8<---------------cut here---------------end--------------->8---
>> shows two different libguile-cairo.so's.  The only difference between the
>> two guile-cairo derivation is that they graft cairo to different
>> derivations, which in turn differ only in grafting fontconfig-minimal to
>> different versions which finally only graft glibc and expat in different
>> order.
>>
>> All this confirms the hypothesis Mark expressed in [0].
>>
>> My guess is that the change to rust-ring somehow changes how it interacts
>> with grafting.  Perhaps it is added / not added to some hashtable, causing
>> iteration order to change?
>>
>> 0: https://issues.guix.gnu.org/47115#23
>
> I tried setting rust-ring's sources to #:target #f but that didn't make
> any difference.  I feel like it shouldn't make a difference, and should
> probably be #:target #f anyway, but that can be a different time.
>
> I'm attaching a patch that creates the grub image using ungrafted
> inputs.  I think it would make sense to go through and figure out which
> derivations actually need to use grafted inputs and which ones don't
> matter, but I'm not sure it's worth the maintenance burden to check them
> regularly.
>
> The image also seems like something that could be #:target #f and we
> could cheat by getting a generated image built on a different
> architecture, but that's never seemed to work that way, only for
> cross-building.

Leo Famulari wrote 7 days ago

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)

Message-ID:Z5QNDAdJnPyuUS0p@jasmine.lan

On Fri, Jan 24, 2025 at 10:55:34AM +0100, Roman Scherer wrote:

Toggle quote (6 lines)

> I'm not very familiar with grafts and have a question. When no grafts

> are used for building the Grub image, does it mean it uses packages with

> no security updates applied, or is it just that the grafts are not used

> and the packages are built from scratch using the latest security

> updates?

If you use '--no-grafts', then you will not receive the security

updates.

Roman Scherer wrote 7 days ago

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 75510@debbugs.gnu.org)

Message-ID:86cygboosj.fsf@burningswell.com

Alright, thank you Leo!

Leo Famulari <leo@famulari.name> writes:

Toggle quote (9 lines)> On Fri, Jan 24, 2025 at 10:55:34AM +0100, Roman Scherer wrote:
>> I'm not very familiar with grafts and have a question. When no grafts
>> are used for building the Grub image, does it mean it uses packages with
>> no security updates applied, or is it just that the grafts are not used
>> and the packages are built from scratch using the latest security
>> updates?
>
> If you use '--no-grafts', then you will not receive the security
> updates.

Efraim Flashner wrote 5 days ago

Recipients:(name . Roman Scherer)(address . roman.scherer@burningswell.com)

Message-ID:Z5XnN4a4MQuDXvCK@3900XT

On Fri, Jan 24, 2025 at 10:55:34AM +0100, Roman Scherer wrote:

Toggle quote (80 lines)> 
> Hi Efraim,
> 
> thanks for looking into this! Much appreciated. I just tried your patch
> and reconfigured my system as usual without using --no-grafts and I can
> confirm that it is working again.
> 
> I'm not very familiar with grafts and have a question. When no grafts
> are used for building the Grub image, does it mean it uses packages with
> no security updates applied, or is it just that the grafts are not used
> and the packages are built from scratch using the latest security
> updates?
> 
> Thanks, Roman.
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > On Wed, Jan 22, 2025 at 12:52:25AM +0100, vicvbcun wrote:
> >> Hi,
> >>
> >> below are my current findings.
> >>
> >> As of commit
> >>     87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)
> >> guile-rsvg depends on a version of guile-cairo different from the one I get
> >> by simply building guile-cairo:
> >>
> >>     $ ./pre-inst-env guix build guile-cairo
> >>     ⇒ /gnu/store/k4kglplg98098y78flnw0f9wjyyc9zk2-guile-cairo-1.11.2
> >>
> >> whereas
> >>
> >>     $ guix gc --references "$(./pre-inst-env guix build guile-rsvg)" | grep guile-cairo
> >>     ⇒ /gnu/store/lz8cv73yzzrbwrhafzadixnwgmspz2cg-guile-cairo-1.11.2
> >>
> >> (gnu build svg) loads both (rsvg) and (cairo) which causes two different
> >> libguile-cairo.so's to be loaded (interestingly enough the order matters:
> >> loading (cairo) first would hide the issue):
> >> --8<---------------cut here---------------start------------->8---
> >> ./pre-inst-env guix shell --no-cwd -C guile guile-cairo guile-rsvg -- \
> >>     guile -s /dev/stdin <<EOF | grep libguile-cairo
> >>
> >> (begin
> >>  (use-modules (ice-9 textual-ports)
> >>               ;; order matters!
> >>               (rsvg)
> >> 	            (cairo))
> >>
> >> (display (call-with-input-file "/proc/self/maps" get-string-all)))
> >> EOF
> >> --8<---------------cut here---------------end--------------->8---
> >> shows two different libguile-cairo.so's.  The only difference between the
> >> two guile-cairo derivation is that they graft cairo to different
> >> derivations, which in turn differ only in grafting fontconfig-minimal to
> >> different versions which finally only graft glibc and expat in different
> >> order.
> >>
> >> All this confirms the hypothesis Mark expressed in [0].
> >>
> >> My guess is that the change to rust-ring somehow changes how it interacts
> >> with grafting.  Perhaps it is added / not added to some hashtable, causing
> >> iteration order to change?
> >>
> >> 0: https://issues.guix.gnu.org/47115#23
> >
> > I tried setting rust-ring's sources to #:target #f but that didn't make
> > any difference.  I feel like it shouldn't make a difference, and should
> > probably be #:target #f anyway, but that can be a different time.
> >
> > I'm attaching a patch that creates the grub image using ungrafted
> > inputs.  I think it would make sense to go through and figure out which
> > derivations actually need to use grafted inputs and which ones don't
> > matter, but I'm not sure it's worth the maintenance burden to check them
> > regularly.
> >
> > The image also seems like something that could be #:target #f and we
> > could cheat by getting a generated image built on a different
> > architecture, but that's never seemed to work that way, only for
> > cross-building.

I've pushed the commit, so it should work on master now.

Now to go and pull and reconfigure my pinebook pro :)

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

Closed

Roman Scherer wrote 5 days ago

Recipients:

Message-ID:CAEc_D28Mu7Thy-8RmXhN=Zb--h6vhwatLucfA0euSPB84O1-bQ@mail.gmail.com

Thank you Efraim!

On Sun, Jan 26, 2025, 08:41 Efraim Flashner <efraim@flashner.co.il> wrote:

Toggle quote (101 lines)> On Fri, Jan 24, 2025 at 10:55:34AM +0100, Roman Scherer wrote:
> >
> > Hi Efraim,
> >
> > thanks for looking into this! Much appreciated. I just tried your patch
> > and reconfigured my system as usual without using --no-grafts and I can
> > confirm that it is working again.
> >
> > I'm not very familiar with grafts and have a question. When no grafts
> > are used for building the Grub image, does it mean it uses packages with
> > no security updates applied, or is it just that the grafts are not used
> > and the packages are built from scratch using the latest security
> > updates?
> >
> > Thanks, Roman.
> >
> > Efraim Flashner <efraim@flashner.co.il> writes:
> >
> > > On Wed, Jan 22, 2025 at 12:52:25AM +0100, vicvbcun wrote:
> > >> Hi,
> > >>
> > >> below are my current findings.
> > >>
> > >> As of commit
> > >>     87045f0982 (gnu: paritwine: Update to 0.2.1., 2025-01-17)
> > >> guile-rsvg depends on a version of guile-cairo different from the one
> I get
> > >> by simply building guile-cairo:
> > >>
> > >>     $ ./pre-inst-env guix build guile-cairo
> > >>     ⇒ /gnu/store/k4kglplg98098y78flnw0f9wjyyc9zk2-guile-cairo-1.11.2
> > >>
> > >> whereas
> > >>
> > >>     $ guix gc --references "$(./pre-inst-env guix build guile-rsvg)"
> | grep guile-cairo
> > >>     ⇒ /gnu/store/lz8cv73yzzrbwrhafzadixnwgmspz2cg-guile-cairo-1.11.2
> > >>
> > >> (gnu build svg) loads both (rsvg) and (cairo) which causes two
> different
> > >> libguile-cairo.so's to be loaded (interestingly enough the order
> matters:
> > >> loading (cairo) first would hide the issue):
> > >> --8<---------------cut here---------------start------------->8---
> > >> ./pre-inst-env guix shell --no-cwd -C guile guile-cairo guile-rsvg --
> \
> > >>     guile -s /dev/stdin <<EOF | grep libguile-cairo
> > >>
> > >> (begin
> > >>  (use-modules (ice-9 textual-ports)
> > >>               ;; order matters!
> > >>               (rsvg)
> > >>                (cairo))
> > >>
> > >> (display (call-with-input-file "/proc/self/maps" get-string-all)))
> > >> EOF
> > >> --8<---------------cut here---------------end--------------->8---
> > >> shows two different libguile-cairo.so's.  The only difference between
> the
> > >> two guile-cairo derivation is that they graft cairo to different
> > >> derivations, which in turn differ only in grafting fontconfig-minimal
> to
> > >> different versions which finally only graft glibc and expat in
> different
> > >> order.
> > >>
> > >> All this confirms the hypothesis Mark expressed in [0].
> > >>
> > >> My guess is that the change to rust-ring somehow changes how it
> interacts
> > >> with grafting.  Perhaps it is added / not added to some hashtable,
> causing
> > >> iteration order to change?
> > >>
> > >> 0: https://issues.guix.gnu.org/47115#23
> > >
> > > I tried setting rust-ring's sources to #:target #f but that didn't make
> > > any difference.  I feel like it shouldn't make a difference, and should
> > > probably be #:target #f anyway, but that can be a different time.
> > >
> > > I'm attaching a patch that creates the grub image using ungrafted
> > > inputs.  I think it would make sense to go through and figure out which
> > > derivations actually need to use grafted inputs and which ones don't
> > > matter, but I'm not sure it's worth the maintenance burden to check
> them
> > > regularly.
> > >
> > > The image also seems like something that could be #:target #f and we
> > > could cheat by getting a generated image built on a different
> > > architecture, but that's never seemed to work that way, only for
> > > cross-building.
>
> I've pushed the commit, so it should work on master now.
>
> Now to go and pull and reconfigure my pinebook pro :)
>
> --
> 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: file

Closed

vicvbcun wrote 5 days ago

Recipients:

Message-ID:Z5a6SXYeQ5yjeCiX@lambda

Hello Guix!

I think that I now have some understanding for how these differently

grafted packages can arise: The grafting code in `bag-grafts' uses

`fold-bag-dependencies' to collect all the replacements that could

affect a package. That function visits all packages in the dependency

tree depth first and exactly once. Consider the following example tree:

A → C, B

B → D, C

Package A references packages C and B while package B references D and

C, in that order. If both C and D have replacements, then the grafting

order for package B depends on whether we are considering it on its own

or as a dependency of package A. See also the attached dummy packages.

I think that the correct solution to this problem is to sort the grafts

somewhere before ungexp'ing them in `graft-derivation/shallow'. While

package inputs should be sorted by name, they are split into `inputs',

`native-inputs' and `propagated-inputs', build systems can add packages

and G-expressions inputs are sorted by lexical appearance.

However the issue with guile-cairo and guile-rsvg seems to be a bit

different. `fold-bag-dependencies' only considers packages and changes

to rust-ring turn its source into a package, causing

`fold-bag-dependencies' to inspect the dependencies. Specifically, on

aarch64-linux `fold-bag-dependencies' the following packages and outputs

are visited near the end:

Toggle snippet (27 lines)rust-ring@0.17.8.tar.gz:out        gnu/packages/crates-crypto.scm:4207
clang@13.0.1:out                   gnu/packages/llvm.scm:241
gcc@11.4.0:lib                     gnu/packages/gcc.scm:743
isl@0.24:out                       gnu/packages/gcc.scm:1404
libstdc++-headers@11.4.0:out       gnu/packages/gcc.scm:1068
libstdc++@11.4.0:out               gnu/packages/gcc.scm:965
mpc@1.3.1:out                      gnu/packages/multiprecision.scm:139
elfutils@0.187:out                 gnu/packages/elf.scm:54
clang-runtime@13.0.1:out           gnu/packages/llvm.scm:145
go@1.21.5:out                      gnu/packages/golang.scm:822
go@1.17.13:out                     gnu/packages/golang.scm:486
go@1.4-bootstrap-20171003:out      gnu/packages/golang.scm:117
gcc@11.4.0:lib                     gnu/packages/commencement.scm:3227
gawk@5.3.0:out                     guix/build-system/gnu.scm:151
make@4.4.1:out                     gnu/packages/commencement.scm:3460
pkg-config@0.29.2:out              gnu/packages/commencement.scm:3453

; note this visit to glibc!
glibc@2.39:out                     gnu/packages/commencement.scm:3103
glibc@2.39:static                  gnu/packages/commencement.scm:3103

binutils-gold@2.41:out             gnu/packages/base.scm:778
bc@1.07.1:out                      gnu/packages/algebra.scm:668
ed@1.20.1:out                      gnu/packages/text-editors.scm:123
lzip@1.23:out                      gnu/packages/compression.scm:703

Notice the visit of glibc.  It is also visited earlier but not 
recognized as duplicate by `fold-bag-dependencies', even though it maps 
to the same derivation (This is `glibc-final', there also is a version 
of glibc created by `package-with-bootstrap-guile' earlier).  expat is 
visited before without any change.  The packages with replacements are 
cons'ed so that glibc ends up in front of expat in the grafting order. 
guile-cairo doesn't depend on rust-ring and it just so happens that 
glibc is visited before expat and they and up in the opposite order.

I don't know where these different versions of glibc come from, but 
sorting grafts should also get rid of any problems they might pose.

So why doesn't the bug appear on x86_64-linux?  Here the change only 
causes the visits of `fold-bag-dependencies' up to gawk, in particular 
the visit to glibc doesn't happen and for both guile-cairo and 
guile-rsvg expat ends up in front of glibc in the grafting order.  This 
should be related to the full-source bootstrap.

vicvbcun

;;; A depends on a version of B different from the one obtained ;;; building simply B (use-modules (guix tests) (guix gexp) (guix packages) (guix build-system trivial)) (define-syntax-rule (dummy-package* name fields ...) (package (inherit (dummy-package name)) (build-system trivial-build-system) (arguments (list #:builder #~(with-output-to-file #$output (lambda () ;; Make sure to keep references, so that ;; grafts really are necessary. (display %build-inputs) (newline))))) fields ...)) (define C (dummy-package* "C" (replacement C/fixed))) (define C/fixed (dummy-package* "C")) (define D (dummy-package* "D" (replacement D/fixed))) (define D/fixed (dummy-package* "D")) (define B (dummy-package* "B" (inputs (list D C)))) (define A (dummy-package* "A" (inputs (list C B)))) (list A B)

Attachment: before-6975b1871b.txt

Attachment: after-6975b1871b.txt

(use-modules (gnu packages gtk) (guix packages) (guix derivations) (guix diagnostics) (ice-9 pretty-print)) (define fold-bag-dependencies (@@ (guix packages) fold-bag-dependencies)) (fold-bag-dependencies (lambda (package output result) (format #t "~a@~a:~a~50t~a:~a~%" (package-name package) (package-version package) output (location-file (package-location package)) (location-line (package-location package)))) #f (package->bag guile-rsvg))

Roman Scherer wrote 3 days ago

Recipients:(name . vicvbcun)(address . guix@ikherbers.com)

Message-ID:87o6zre0ml.fsf@burningswell.com

Hi vicvbcun,

thanks for looking into this. I'm afraid I canb't help much on this, but

I find your investigation very interesting. Keep us posted.

Roman

vicvbcun <guix@ikherbers.com> writes:

Toggle quote (88 lines)> Hello Guix!
>
> I think that I now have some understanding for how these differently
> grafted packages can arise: The grafting code in `bag-grafts' uses
> `fold-bag-dependencies' to collect all the replacements that could
> affect a package.  That function visits all packages in the dependency
> tree depth first and exactly once.  Consider the following example
> tree:
>
> A → C, B
>
> B → D, C
>
> Package A references packages C and B while package B references D and
> C, in that order.  If both C and D have replacements, then the
> grafting order for package B depends on whether we are considering it
> on its own or as a dependency of package A.  See also the attached
> dummy packages.
>
> I think that the correct solution to this problem is to sort the
> grafts somewhere before ungexp'ing them in `graft-derivation/shallow'.
> While package inputs should be sorted by name, they are split into
> `inputs', `native-inputs' and `propagated-inputs', build systems can
> add packages and G-expressions inputs are sorted by lexical
> appearance.
>
> However the issue with guile-cairo and guile-rsvg seems to be a bit
> different. `fold-bag-dependencies' only considers packages and changes
> to rust-ring turn its source into a package, causing
> `fold-bag-dependencies' to inspect the dependencies.  Specifically, on
> aarch64-linux `fold-bag-dependencies' the following packages and
> outputs are visited near the end:
> --8<---------------cut here---------------start------------->8---
> rust-ring@0.17.8.tar.gz:out        gnu/packages/crates-crypto.scm:4207
> clang@13.0.1:out                   gnu/packages/llvm.scm:241
> gcc@11.4.0:lib                     gnu/packages/gcc.scm:743
> isl@0.24:out                       gnu/packages/gcc.scm:1404
> libstdc++-headers@11.4.0:out       gnu/packages/gcc.scm:1068
> libstdc++@11.4.0:out               gnu/packages/gcc.scm:965
> mpc@1.3.1:out                      gnu/packages/multiprecision.scm:139
> elfutils@0.187:out                 gnu/packages/elf.scm:54
> clang-runtime@13.0.1:out           gnu/packages/llvm.scm:145
> go@1.21.5:out                      gnu/packages/golang.scm:822
> go@1.17.13:out                     gnu/packages/golang.scm:486
> go@1.4-bootstrap-20171003:out      gnu/packages/golang.scm:117
> gcc@11.4.0:lib                     gnu/packages/commencement.scm:3227
> gawk@5.3.0:out                     guix/build-system/gnu.scm:151
> make@4.4.1:out                     gnu/packages/commencement.scm:3460
> pkg-config@0.29.2:out              gnu/packages/commencement.scm:3453
>
> ; note this visit to glibc!
> glibc@2.39:out                     gnu/packages/commencement.scm:3103
> glibc@2.39:static                  gnu/packages/commencement.scm:3103
>
> binutils-gold@2.41:out             gnu/packages/base.scm:778
> bc@1.07.1:out                      gnu/packages/algebra.scm:668
> ed@1.20.1:out                      gnu/packages/text-editors.scm:123
> lzip@1.23:out                      gnu/packages/compression.scm:703
> --8<---------------cut here---------------end--------------->8---
>
> Notice the visit of glibc.  It is also visited earlier but not
> recognized as duplicate by `fold-bag-dependencies', even though it
> maps to the same derivation (This is `glibc-final', there also is a
> version of glibc created by `package-with-bootstrap-guile' earlier).
> expat is visited before without any change.  The packages with
> replacements are cons'ed so that glibc ends up in front of expat in
> the grafting order. guile-cairo doesn't depend on rust-ring and it
> just so happens that glibc is visited before expat and they and up in
> the opposite order.
>
> I don't know where these different versions of glibc come from, but
> sorting grafts should also get rid of any problems they might pose.
>
> So why doesn't the bug appear on x86_64-linux?  Here the change only
> causes the visits of `fold-bag-dependencies' up to gawk, in particular
> the visit to glibc doesn't happen and for both guile-cairo and
> guile-rsvg expat ends up in front of glibc in the grafting order.
> This should be related to the full-source bootstrap.
>
> vicvbcun
>
> [2. text/plain; dependencies-order.scm]...
>
> [3. text/plain; before-6975b1871b.txt]...
>
> [4. text/plain; after-6975b1871b.txt]...
>
> [5. text/plain; fold-bag-dependencies-list.scm]...

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 75510@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 75510

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date