| Message ID | 5311476.e0r0s4ehiO@popigai |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#51428] core-updates-frozen-batched-changes built and ready to merge | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
Hi Thiago, Thiago Jung Bauermann <bauermann@kolabnow.com> writes: > Hello again, > > Em sexta-feira, 29 de outubro de 2021, às 17:10:03 -03, Maxim Cournoyer > escreveu: >> In other news I've added a polkit-duktape package on the cufbc branch. >> Feel free to try it (with some transformation applied, or by hacking >> s/polkit/polkit-duktape/ manually in your checkout). > > Thank you for providing that package. I tried it with the patch at the end > of this message, and GTK+ built! Though I don’t think I have a way to test > whether polkit-duktape works well. > > I was even able to build Emacs, but when I tried to install it there was > this error: > > guixp9: ./pre-inst-env guix package -p /tmp/profile -i emacs > ⋮ > building /gnu/store/cm09wbm7wj7k237df58rny22ghkmmcg8-emacs-27.2.drv... > building CA certificate bundle... > listing Emacs sub-directories... > building fonts directory... > generating GdkPixbuf loaders cache... > builder for `/gnu/store/w3bmrsz4v0bcz1s5gsd6dl83jrn0yk7n-gdk-pixbuf-loaders-cache-file.drv' failed to produce output path `/gnu/store/g4pj8hm97bl3fwnbami0j3g5ycvnh559-gdk-pixbuf-loaders-cache-file' > build of /gnu/store/w3bmrsz4v0bcz1s5gsd6dl83jrn0yk7n-gdk-pixbuf-loaders-cache-file.drv failed > View build log at '/var/log/guix/drvs/w3/bmrsz4v0bcz1s5gsd6dl83jrn0yk7n-gdk-pixbuf-loaders-cache-file.drv.bz2'. > cannot build derivation `/gnu/store/7hd26alx72spjadmfhs6ssfd6zs815l7-profile.drv': 1 dependencies couldn't be built > guix package: error: build of `/gnu/store/7hd26alx72spjadmfhs6ssfd6zs815l7-profile.drv' failed > > > The build log is just a bzip2-compressed empty file, though: > > guixp9: ls -l /var/log/guix/drvs/w3/bmrsz4v0bcz1s5gsd6dl83jrn0yk7n-gdk-pixbuf-loaders-cache-file.drv.bz2 > -rw-r--r-- 1 root root 14 Nov 2 23:10 /var/log/guix/drvs/w3/bmrsz4v0bcz1s5gsd6dl83jrn0yk7n-gdk-pixbuf-loaders-cache-file.drv.bz2 > guixp9: bzcat /var/log/guix/drvs/w3/bmrsz4v0bcz1s5gsd6dl83jrn0yk7n-gdk-pixbuf-loaders-cache-file.drv.bz2 > guixp9: > > Unfortunately I’ve been having less time to work on Guix lately, and > I wasn’t able yet to investigate this issue further. Also, I will be on > travel for about a week with very little access to the internet, so I won’t > be able to respond or experiment further until I’m back. > > This was based on c.u.f.b.c. commit eae3355ec8ad. Ah, I could reproduce this! It seems to happen when no loader libraries were found amongst the inputs. As a workaround, you could install e.g. gdk-pixbuf (which itself provides loaders) in the profile. I'll see how this can be fixed, but at least we won't need to rebuild the world as it's a problem at the level of the profile hook. --8<---------------cut here---------------start------------->8--- (define (gdk-pixbuf-loaders-cache-file manifest) "Return a derivation that produces a loaders cache file for every gdk-pixbuf loaders discovered in MANIFEST." (define gdk-pixbuf ;lazy reference (module-ref (resolve-interface '(gnu packages gtk)) 'gdk-pixbuf)) (mlet %store-monad ((%gdk-pixbuf? (manifest-lookup-package manifest "gdk-pixbuf")) (gdk-pixbuf-bin -> (file-append gdk-pixbuf "/bin"))) (define build (with-imported-modules (source-module-closure '((guix build glib-or-gtk-build-system))) #~(begin (use-modules (guix build glib-or-gtk-build-system)) (setenv "PATH" (string-append #$gdk-pixbuf-bin ":" (getenv "PATH"))) (generate-gdk-pixbuf-loaders-cache '#$(manifest-inputs manifest) (list #$output))))) (if %gdk-pixbuf? (gexp->derivation "gdk-pixbuf-loaders-cache-file" build #:local-build? #t #:substitutable? #f #:properties '((type . profile-hook) (hook . gdk-pixbuf-loaders-cache-file))) (return #f)))) --8<---------------cut here---------------end--------------->8--- It's curious that it would occur though, because I thought that when gdk-pixbuf was found with `manifest-lookup-package', it meant it'd also be part of the manifest inputs? Apparently it isn't the case. Weird! Thanks for the report! Maxim
Hello Maxim, Em sexta-feira, 5 de novembro de 2021, às 02:06:04 -03, Maxim Cournoyer escreveu: > It's curious that it would occur though, because I thought that when > gdk-pixbuf was found with `manifest-lookup-package', it meant it'd also > be part of the manifest inputs? Apparently it isn't the case. Weird! I’m glad you found out what the problem was. I didn’t know where to start investigating it! > Thanks for the report! Thank you for looking into it. Should I open a bug report about it?
Hi Thiago, Thiago Jung Bauermann <bauermann@kolabnow.com> writes: > Hello Maxim, > > Em sexta-feira, 5 de novembro de 2021, às 02:06:04 -03, Maxim Cournoyer > escreveu: >> It's curious that it would occur though, because I thought that when >> gdk-pixbuf was found with `manifest-lookup-package', it meant it'd also >> be part of the manifest inputs? Apparently it isn't the case. Weird! > > I’m glad you found out what the problem was. I didn’t know where to start > investigating it! > >> Thanks for the report! > > Thank you for looking into it. Should I open a bug report about it? No, the commit 20e3dd052d7e4f59273e3646d3533d43c87c30b0 contains a workaround guarding against such situation. Thanks :-).
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index 5f7d3a953dcb..7345a3518b63 100644 --- a/gnu/packages/gnome.scm +++ b/gnu/packages/gnome.scm @@ -5303,7 +5303,12 @@ (define-public colord-minimal ("gusb" ,gusb-minimal) ("libgudev" ,libgudev) ("libusb" ,libusb) - ("polkit" ,polkit) + ;; polkit pulls in rust because of mozjs, so it’s only available on + ;; x86_64. Use polkit-duktape on other arches, which uses duktape + ;; instead. + ("polkit" ,(if (target-x86-64?) + polkit + polkit-duktape)) ("python" ,python-wrapper) ("sqlite" ,sqlite) ("sane-backends" ,sane-backends)))