Subject: bug#75510: closed (Re: bug#75510: Building grub-image.png.drv fails with rsvg)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 26 Jan 2025 07:42:02 +0000

Your bug report

#75510: Building grub-image.png.drv fails with rsvg

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
75510: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75510
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#75510: Building grub-image.png.drv fails with rsvg
From: Efraim Flashner <[email-masked]>
To: Roman Scherer <[email-masked]>
Cc: vicvbcun <[email-masked]>, Leo Famulari <[email-masked]>, [email-masked]
Date: Sun, 26 Jan 2025 09:41:43 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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 <[email-masked]> 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   <[email-masked]>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Subject: Building grub-image.png.drv fails with rsvg
From: Roman Scherer <[email-masked]>
To: [email-masked]
Date: Sun, 12 Jan 2025 10:58:54 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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?