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

From: Efraim Flashner <[email-masked]>
Date: Sun, 26 Jan 2025 09:41:43 +0200

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