GNU bug report logs -
#75510
Building grub-image.png.drv fails with rsvg
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75510 in the body.
You can then email your comments to 75510 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Sun, 12 Jan 2025 10:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Roman Scherer <roman.scherer <at> burningswell.com>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Sun, 12 Jan 2025 10:00:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Sun, 12 Jan 2025 20:31:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 75510 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Sun, 12 Jan 2025 22:13:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Leo Famulari <leo <at> 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
> 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?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Mon, 13 Jan 2025 03:21:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 75510 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Mon, 13 Jan 2025 09:14:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Leo,
here is the `guix desribe` run as my normal user account.
```
[roman <at> 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 <at> 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 <at> 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 <at> 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?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Thu, 16 Jan 2025 17:40:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Roman Scherer <roman.scherer <at> 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 <at> 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 <at> 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 <at> 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 <at> 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?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Fri, 17 Jan 2025 14:49:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Roman Scherer <roman.scherer <at> burningswell.com> writes:
Hmm, but it looks I'm now stuck using --no-grafts all the time. Any
ideas how to solve that?
> Roman Scherer <roman.scherer <at> 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 <at> 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 <at> 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 <at> 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 <at> 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?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Fri, 17 Jan 2025 19:23:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 75510 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 17, 2025 at 03:48:04PM +0100, Roman Scherer wrote:
> Roman Scherer <roman.scherer <at> 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?
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Tue, 21 Jan 2025 09:29:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[bisect-log.txt (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Tue, 21 Jan 2025 12:30:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> ikherbers.com> writes:
> 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]...
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Tue, 21 Jan 2025 23:53:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 75510 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Fri, 24 Jan 2025 08:42:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
--
Efraim Flashner <efraim <at> 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
[0001-bootloader-grub-Create-grub-background-image-with-un.patch (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Fri, 24 Jan 2025 09:56:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Fri, 24 Jan 2025 21:59:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 75510 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Fri, 24 Jan 2025 22:01:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Alright, thank you Leo!
Leo Famulari <leo <at> famulari.name> writes:
> 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.
[signature.asc (application/pgp-signature, inline)]
Reply sent
to
Efraim Flashner <efraim <at> flashner.co.il>:
You have taken responsibility.
(Sun, 26 Jan 2025 07:42:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Roman Scherer <roman.scherer <at> burningswell.com>:
bug acknowledged by developer.
(Sun, 26 Jan 2025 07:42:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 75510-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Sun, 26 Jan 2025 07:50:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 75510-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you Efraim!
On Sun, Jan 26, 2025, 08:41 Efraim Flashner <efraim <at> flashner.co.il> wrote:
> 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 <at> 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 <at> 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
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Sun, 26 Jan 2025 22:43:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 0.17.8.tar.gz:out gnu/packages/crates-crypto.scm:4207
clang <at> 13.0.1:out gnu/packages/llvm.scm:241
gcc <at> 11.4.0:lib gnu/packages/gcc.scm:743
isl <at> 0.24:out gnu/packages/gcc.scm:1404
libstdc++-headers <at> 11.4.0:out gnu/packages/gcc.scm:1068
libstdc++@11.4.0:out gnu/packages/gcc.scm:965
mpc <at> 1.3.1:out gnu/packages/multiprecision.scm:139
elfutils <at> 0.187:out gnu/packages/elf.scm:54
clang-runtime <at> 13.0.1:out gnu/packages/llvm.scm:145
go <at> 1.21.5:out gnu/packages/golang.scm:822
go <at> 1.17.13:out gnu/packages/golang.scm:486
go <at> 1.4-bootstrap-20171003:out gnu/packages/golang.scm:117
gcc <at> 11.4.0:lib gnu/packages/commencement.scm:3227
gawk <at> 5.3.0:out guix/build-system/gnu.scm:151
make <at> 4.4.1:out gnu/packages/commencement.scm:3460
pkg-config <at> 0.29.2:out gnu/packages/commencement.scm:3453
; note this visit to glibc!
glibc <at> 2.39:out gnu/packages/commencement.scm:3103
glibc <at> 2.39:static gnu/packages/commencement.scm:3103
binutils-gold <at> 2.41:out gnu/packages/base.scm:778
bc <at> 1.07.1:out gnu/packages/algebra.scm:668
ed <at> 1.20.1:out gnu/packages/text-editors.scm:123
lzip <at> 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
[dependencies-order.scm (text/plain, attachment)]
[before-6975b1871b.txt (text/plain, attachment)]
[after-6975b1871b.txt (text/plain, attachment)]
[fold-bag-dependencies-list.scm (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#75510; Package
guix.
(Tue, 28 Jan 2025 09:42:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 75510 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> ikherbers.com> writes:
> 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 <at> 0.17.8.tar.gz:out gnu/packages/crates-crypto.scm:4207
> clang <at> 13.0.1:out gnu/packages/llvm.scm:241
> gcc <at> 11.4.0:lib gnu/packages/gcc.scm:743
> isl <at> 0.24:out gnu/packages/gcc.scm:1404
> libstdc++-headers <at> 11.4.0:out gnu/packages/gcc.scm:1068
> libstdc++@11.4.0:out gnu/packages/gcc.scm:965
> mpc <at> 1.3.1:out gnu/packages/multiprecision.scm:139
> elfutils <at> 0.187:out gnu/packages/elf.scm:54
> clang-runtime <at> 13.0.1:out gnu/packages/llvm.scm:145
> go <at> 1.21.5:out gnu/packages/golang.scm:822
> go <at> 1.17.13:out gnu/packages/golang.scm:486
> go <at> 1.4-bootstrap-20171003:out gnu/packages/golang.scm:117
> gcc <at> 11.4.0:lib gnu/packages/commencement.scm:3227
> gawk <at> 5.3.0:out guix/build-system/gnu.scm:151
> make <at> 4.4.1:out gnu/packages/commencement.scm:3460
> pkg-config <at> 0.29.2:out gnu/packages/commencement.scm:3453
>
> ; note this visit to glibc!
> glibc <at> 2.39:out gnu/packages/commencement.scm:3103
> glibc <at> 2.39:static gnu/packages/commencement.scm:3103
>
> binutils-gold <at> 2.41:out gnu/packages/base.scm:778
> bc <at> 1.07.1:out gnu/packages/algebra.scm:668
> ed <at> 1.20.1:out gnu/packages/text-editors.scm:123
> lzip <at> 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]...
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 25 Feb 2025 12:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 113 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.