GNU bug report logs - #75510
Building grub-image.png.drv fails with rsvg

Previous Next

Package: guix;

Reported by: Roman Scherer <roman.scherer <at> burningswell.com>

Date: Sun, 12 Jan 2025 10:00:02 UTC

Severity: normal

Done: Efraim Flashner <efraim <at> flashner.co.il>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#75510: closed (Building grub-image.png.drv fails with rsvg)
Date: Sun, 26 Jan 2025 07:42:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Sun, 26 Jan 2025 09:41:43 +0200
with message-id <Z5XnN4a4MQuDXvCK <at> 3900XT>
and subject line Re: bug#75510: Building grub-image.png.drv fails with rsvg
has caused the debbugs.gnu.org bug report #75510,
regarding Building grub-image.png.drv fails with rsvg
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
75510: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75510
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Roman Scherer <roman.scherer <at> burningswell.com>
To: bug-guix <at> gnu.org
Subject: Building grub-image.png.drv fails with rsvg
Date: Sun, 12 Jan 2025 10:58:54 +0100
[Message part 3 (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)]
[Message part 5 (message/rfc822, inline)]
From: Efraim Flashner <efraim <at> flashner.co.il>
To: Roman Scherer <roman.scherer <at> burningswell.com>
Cc: vicvbcun <guix <at> ikherbers.com>, Leo Famulari <leo <at> famulari.name>,
 75510-done <at> debbugs.gnu.org
Subject: Re: bug#75510: Building grub-image.png.drv fails with rsvg
Date: Sun, 26 Jan 2025 09:41:43 +0200
[Message part 6 (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)]

This bug report was last modified 114 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.