Subject: [bug#51428] core-updates-frozen-batched-changes built and ready to merge

From: Maxim Cournoyer <[email-masked]>
Date: Fri, 05 Nov 2021 01:06:04 -0400

Hi Thiago,

Thiago Jung Bauermann <[email-masked]> 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