GNU bug report logs - #51428
core-updates-frozen-batched-changes built and ready to merge

Previous Next

Full log

Message #119 received at 51428 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
Cc: 51428 <at> debbugs.gnu.org
Subject: Re: [bug#51428] core-updates-frozen-batched-changes built and ready
 to merge
Date: Fri, 05 Nov 2021 01:06:04 -0400

Hi Thiago,

Thiago Jung Bauermann <bauermann <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.