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 <efr...@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
Description: PGP signature
