GNU bug report logs - #63043
texlive-font-maps.drv build failure when profiles lacks texlive-* packages

Previous Next

Package: guix;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Sun, 23 Apr 2023 23:08:02 UTC

Severity: normal

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63043 in the body.
You can then email your comments to 63043 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to maxim.cournoyer <at> gmail.com, bug-guix <at> gnu.org:
bug#63043; Package guix. (Sun, 23 Apr 2023 23:08:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ludovic Courtès <ludo <at> gnu.org>:
New bug report received and forwarded. Copy sent to maxim.cournoyer <at> gmail.com, bug-guix <at> gnu.org. (Sun, 23 Apr 2023 23:08:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: texlive-font-maps.drv build failure when profiles lacks texlive-*
 packages
Date: Mon, 24 Apr 2023 01:07:15 +0200
Hi!

(Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)

I have Guile as a channel, which provides guile <at> 3.0.99-git.  Trying to
add this guile package to a profile leads to a ‘texlive-font-maps.drv’
build failure:

--8<---------------cut here---------------start------------->8---
$ guix describe -f channels
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (branch "master")
        (commit
          "74e96c4cb171b17949f638d8b452d047a8f2dc6f")
        (introduction
          (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
              "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
      (channel
        (name 'guile)
        (url "https://git.savannah.gnu.org/git/guile.git")
        (branch "main")
        (commit
          "1ae50a7f80654f04d93d900e17f3160205700a75"))
      (channel
        (name 'shepherd)
        (url "https://git.savannah.gnu.org/git/shepherd.git")
        (branch "master")
        (commit
          "ab0c7ec989d3afe1933aebb2e03c1d6ecb558ca6")
        (introduction
          (make-channel-introduction
            "788a6d6f1d5c170db68aa4bbfb77024fdc468ed3"
            (openpgp-fingerprint
              "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5")))))
$ guix build guile
/gnu/store/1cssq3p4ndi4rvly5w607q7chrg2sj3v-guile-3.0.99-git-debug
/gnu/store/qndx3hp7cv5z8mv899k58gr9ampaa4g0-guile-3.0.99-git
$ guix show guile <at> 3.0.99-git |grep location
location: guile-package.scm:51:4
$ guix shell guile -- guile
The following derivation will be built:
  /gnu/store/pih50yd938jz3h6zkz0kd5jffkxagp3l-profile.drv

builder for `/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps' failed previously (cached)
build of /gnu/store/6h3k74mn5wpgcy0mqzh1zfa6r207jsqf-texlive-font-maps.drv failed
View build log at '/var/log/guix/drvs/6h/3k74mn5wpgcy0mqzh1zfa6r207jsqf-texlive-font-maps.drv.gz'.
cannot build derivation `/gnu/store/pih50yd938jz3h6zkz0kd5jffkxagp3l-profile.drv': 1 dependencies couldn't be built
guix shell: error: build of `/gnu/store/pih50yd938jz3h6zkz0kd5jffkxagp3l-profile.drv' failed
--8<---------------cut here---------------end--------------->8---

The log file for texlive-font-maps.drv ends with:

--8<---------------cut here---------------start------------->8---
updmap: open() failed: No such file or directory at /gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-texlive-bin-20210325/bin/updmap line 2158.
updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]:         dvips35.map (in builtin)
updmap [ERROR]:         pdftex35.map (in builtin)
updmap [ERROR]:         ps2pk35.map (in builtin)
updmap [ERROR]: Did you run mktexlsr?

        You can disable non-existent map entries using the option
          --syncwithtrees.

Backtrace:
           2 (primitive-load "/gnu/store/pnzmvmbx1smragwnw3rlq4n6zd6?")
In ice-9/eval.scm:
    619:8  1 (_ #(#(#(#<directory (guile-user) 7ffff5fdbc80> #) #) #))
In guix/build/utils.scm:
    762:6  0 (invoke "/gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-t?" ?)

guix/build/utils.scm:762:6: In procedure invoke:
ERROR:
  1. &invoke-error:
      program: "/gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-texlive-bin-20210325/bin/updmap-sys"
      arguments: ("--cnffile=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/web2c/updmap.cfg" "--dvipdfmxoutputdir=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/fonts/map/dvipdfmx/updmap" "--dvipsoutputdir=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/fonts/map/dvips/updmap" "--pdftexoutputdir=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/fonts/map/pdftex/updmap")
      exit-status: 1
      term-signal: #f
      stop-signal: #f
--8<---------------cut here---------------end--------------->8---

The ‘texlive-font-maps-builder’ file starts with:

--8<---------------cut here---------------start------------->8---
(begin
  (use-modules
   (guix build utils)
   (guix build union)
   (ice-9 popen))
  (union-build "/tmp/texlive"
	       (quote
		())
	       #:create-all-directories? #t #:log-port
	       (%make-void-port "w"))
  (setenv "PATH"
	  (string-append "/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin" ":" "/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin" ":" "/gnu/store/zhd6blbfz40xp62i4d1rcgbyrpkynbkc-sed-4.8/bin"))
  (setenv "PERL5LIB" "/gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-texlive-bin-20210325/share/tlpkg")
  (setenv "GUIX_TEXMF" "/tmp/texlive/share/texmf-dist")
--8<---------------cut here---------------end--------------->8---

So the failure is caused by the fact that /tmp/texlive is in fact empty.

How does this happen?  I think there’s a logic failure in this bit of
‘texlive-font-maps’ in (guix profiles):

  (mlet %store-monad ((texlive-base (manifest-lookup-package manifest "texlive-base")))
    (if texlive-base
        (gexp->derivation "texlive-font-maps" build
                          #:substitutable? #f
                          #:local-build? #t
                          #:properties
                          `((type . profile-hook)
                            (hook . texlive-font-maps)))
        (return #f)))

In this case, ‘texlive-base’ is found among the native inputs of
guile <at> 3.0.99-git.

However, the profile itself contains zero texlive-* packages, hence the
failure.

There are probably two things to fix:

  1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
     passed to ‘union-build’.

  2. Perhaps the builder shouldn’t fail anyway when given an empty
     /tmp/texlive.
  
Thoughts?

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#63043; Package guix. (Mon, 24 Apr 2023 01:22:02 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 63043 <at> debbugs.gnu.org
Subject: Re: bug#63043: texlive-font-maps.drv build failure when profiles
 lacks texlive-* packages
Date: Sun, 23 Apr 2023 21:20:59 -0400
Hello!

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi!
>
> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)

Did you checked with Ricardo?  They were the author of that hook, per
git blame :-).

> I have Guile as a channel, which provides guile <at> 3.0.99-git.  Trying to
> add this guile package to a profile leads to a ‘texlive-font-maps.drv’
> build failure:
>
> $ guix describe -f channels
> (list (channel
>         (name 'guix)
>         (url "https://git.savannah.gnu.org/git/guix.git")
>         (branch "master")
>         (commit
>           "74e96c4cb171b17949f638d8b452d047a8f2dc6f")
>         (introduction
>           (make-channel-introduction
>             "9edb3f66fd807b096b48283debdcddccfea34bad"
>             (openpgp-fingerprint
>               "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
>       (channel
>         (name 'guile)
>         (url "https://git.savannah.gnu.org/git/guile.git")
>         (branch "main")
>         (commit
>           "1ae50a7f80654f04d93d900e17f3160205700a75"))
>       (channel
>         (name 'shepherd)
>         (url "https://git.savannah.gnu.org/git/shepherd.git")
>         (branch "master")
>         (commit
>           "ab0c7ec989d3afe1933aebb2e03c1d6ecb558ca6")
>         (introduction
>           (make-channel-introduction
>             "788a6d6f1d5c170db68aa4bbfb77024fdc468ed3"
>             (openpgp-fingerprint
>               "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5")))))
> $ guix build guile
> /gnu/store/1cssq3p4ndi4rvly5w607q7chrg2sj3v-guile-3.0.99-git-debug
> /gnu/store/qndx3hp7cv5z8mv899k58gr9ampaa4g0-guile-3.0.99-git
> $ guix show guile <at> 3.0.99-git |grep location
> location: guile-package.scm:51:4
> $ guix shell guile -- guile
> The following derivation will be built:
>   /gnu/store/pih50yd938jz3h6zkz0kd5jffkxagp3l-profile.drv
>
> builder for `/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps' failed previously (cached)
> build of /gnu/store/6h3k74mn5wpgcy0mqzh1zfa6r207jsqf-texlive-font-maps.drv failed
> View build log at '/var/log/guix/drvs/6h/3k74mn5wpgcy0mqzh1zfa6r207jsqf-texlive-font-maps.drv.gz'.
> cannot build derivation `/gnu/store/pih50yd938jz3h6zkz0kd5jffkxagp3l-profile.drv': 1 dependencies couldn't be built
> guix shell: error: build of `/gnu/store/pih50yd938jz3h6zkz0kd5jffkxagp3l-profile.drv' failed
>
>
> The log file for texlive-font-maps.drv ends with:
>
> updmap: open() failed: No such file or directory at /gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-texlive-bin-20210325/bin/updmap line 2158.
> updmap [ERROR]: The following map file(s) couldn't be found:
> updmap [ERROR]:         dvips35.map (in builtin)
> updmap [ERROR]:         pdftex35.map (in builtin)
> updmap [ERROR]:         ps2pk35.map (in builtin)
> updmap [ERROR]: Did you run mktexlsr?
>
>         You can disable non-existent map entries using the option
>           --syncwithtrees.
>
> Backtrace:
>            2 (primitive-load "/gnu/store/pnzmvmbx1smragwnw3rlq4n6zd6?")
> In ice-9/eval.scm:
>     619:8  1 (_ #(#(#(#<directory (guile-user) 7ffff5fdbc80> #) #) #))
> In guix/build/utils.scm:
>     762:6  0 (invoke "/gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-t?" ?)
>
> guix/build/utils.scm:762:6: In procedure invoke:
> ERROR:
>   1. &invoke-error:
>       program: "/gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-texlive-bin-20210325/bin/updmap-sys"
>       arguments: ("--cnffile=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/web2c/updmap.cfg" "--dvipdfmxoutputdir=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/fonts/map/dvipdfmx/updmap" "--dvipsoutputdir=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/fonts/map/dvips/updmap" "--pdftexoutputdir=/gnu/store/8d71qslw04hz3dc9gk8yfp0gcp9z03bx-texlive-font-maps/share/texmf-dist/fonts/map/pdftex/updmap")
>       exit-status: 1
>       term-signal: #f
>       stop-signal: #f
>
>
> The ‘texlive-font-maps-builder’ file starts with:
>
> (begin
>   (use-modules
>    (guix build utils)
>    (guix build union)
>    (ice-9 popen))
>   (union-build "/tmp/texlive"
> 	       (quote
> 		())
> 	       #:create-all-directories? #t #:log-port
> 	       (%make-void-port "w"))
>   (setenv "PATH"
> 	  (string-append "/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin" ":" "/gnu/store/hrgqa7m498wfavq4awai3xz86ifkjxdr-grep-3.6/bin" ":" "/gnu/store/zhd6blbfz40xp62i4d1rcgbyrpkynbkc-sed-4.8/bin"))
>   (setenv "PERL5LIB" "/gnu/store/fd38qipvckr2jkkq2xja1n3rb9xz334r-texlive-bin-20210325/share/tlpkg")
>   (setenv "GUIX_TEXMF" "/tmp/texlive/share/texmf-dist")
>
> So the failure is caused by the fact that /tmp/texlive is in fact empty.
>
> How does this happen?  I think there’s a logic failure in this bit of
> ‘texlive-font-maps’ in (guix profiles):
>
>   (mlet %store-monad ((texlive-base (manifest-lookup-package manifest "texlive-base")))
>     (if texlive-base
>         (gexp->derivation "texlive-font-maps" build
>                           #:substitutable? #f
>                           #:local-build? #t
>                           #:properties
>                           `((type . profile-hook)
>                             (hook . texlive-font-maps)))
>         (return #f)))
>
> In this case, ‘texlive-base’ is found among the native inputs of
> guile <at> 3.0.99-git.
>
> However, the profile itself contains zero texlive-* packages, hence the
> failure.
>
> There are probably two things to fix:
>
>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>      passed to ‘union-build’.

I think this is the problem to fix.  It's non-intuitive that
manifest-lookup-package transitively looks for things instead of looking
at the profile.  I actually got tripped by that as well when I authored
gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
file that reads:

             ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
             ;; every input referenced by the manifest, while MANIFEST-INPUTS
             ;; only retrieves the immediate inputs as well as their
             ;; propagated inputs; to avoid causing an empty output derivation
             ;; we must ensure that the inputs contain at least one
             ;; loaders.cache file.  This is why we include gdk-pixbuf or
             ;; librsvg when they are transitively found.

I think we need a 'manifest-lookup-inputs' or similar that stops at the
profile, to work at the same depth as manifest-inputs.  Then it wouldn't
find texlive-base and the hook wouldn't run (and fail).

What do you think?

-- 
Thanks,
Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#63043; Package guix. (Mon, 24 Apr 2023 21:16:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 63043 <at> debbugs.gnu.org
Subject: Re: bug#63043: texlive-font-maps.drv build failure when profiles
 lacks texlive-* packages
Date: Mon, 24 Apr 2023 23:15:35 +0200
[Message part 1 (text/plain, inline)]
Hello!

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi!
>>
>> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)
>
> Did you checked with Ricardo?  They were the author of that hook, per
> git blame :-).

I didn’t even look at ‘git blame’, I thought you were the one behind
this iteration :-), but Ricardo and I discussed it briefly on IRC.
Anyway, extending Cc!

>> There are probably two things to fix:
>>
>>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>>      passed to ‘union-build’.
>
> I think this is the problem to fix.  It's non-intuitive that
> manifest-lookup-package transitively looks for things instead of looking
> at the profile.  I actually got tripped by that as well when I authored
> gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
> file that reads:
>
>              ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
>              ;; every input referenced by the manifest, while MANIFEST-INPUTS
>              ;; only retrieves the immediate inputs as well as their
>              ;; propagated inputs; to avoid causing an empty output derivation
>              ;; we must ensure that the inputs contain at least one
>              ;; loaders.cache file.  This is why we include gdk-pixbuf or
>              ;; librsvg when they are transitively found.
>
> I think we need a 'manifest-lookup-inputs' or similar that stops at the
> profile, to work at the same depth as manifest-inputs.  Then it wouldn't
> find texlive-base and the hook wouldn't run (and fail).

There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
was to take whichever glib/GDK we’d find in the dependency graph, and
pick the command we need from it.  That way, we wouldn’t introduce any
additional dependency.  That was the reasoning.

Thinking about, this particular case might be easier: we can make things
consistent like so:

[Message part 2 (text/x-patch, inline)]
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 03333785f9..41f3e25bb3 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1786,6 +1786,8 @@ (define entry->texlive-input
            (cons (gexp-input thing output)
                  (append-map entry->texlive-input deps))
            '()))))
+  (define texlive-inputs
+    (append-map entry->texlive-input (manifest-entries manifest)))
   (define texlive-bin
     (module-ref (resolve-interface '(gnu packages tex)) 'texlive-bin))
   (define coreutils
@@ -1809,8 +1811,7 @@ (define build
           ;; that TeX live can resolve the parent and grandparent directories
           ;; correctly.  There might be a more elegant way to accomplish this.
           (union-build "/tmp/texlive"
-                       '#$(append-map entry->texlive-input
-                                      (manifest-entries manifest))
+                       '#$texlive-inputs
                        #:create-all-directories? #t
                        #:log-port (%make-void-port "w"))
 
@@ -1867,7 +1868,7 @@ (define build
               (install-file (string-append b "/ls-R") a))))))
 
   (mlet %store-monad ((texlive-base (manifest-lookup-package manifest "texlive-base")))
-    (if texlive-base
+    (if (and texlive-base (pair? texlive-inputs))
         (gexp->derivation "texlive-font-maps" build
                           #:substitutable? #f
                           #:local-build? #t
[Message part 3 (text/plain, inline)]
That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
graph) *and* we have texlive-* packages in the manifest.

Thoughts?

Ludo’.

Information forwarded to bug-guix <at> gnu.org:
bug#63043; Package guix. (Tue, 25 Apr 2023 01:43:01 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 63043 <at> debbugs.gnu.org
Subject: Re: bug#63043: texlive-font-maps.drv build failure when profiles
 lacks texlive-* packages
Date: Mon, 24 Apr 2023 21:41:53 -0400
Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hi!
>>>
>>> (Cc: Maxim who may be familiar with the ‘texlive-font-maps’ hook.)
>>
>> Did you checked with Ricardo?  They were the author of that hook, per
>> git blame :-).
>
> I didn’t even look at ‘git blame’, I thought you were the one behind
> this iteration :-), but Ricardo and I discussed it briefly on IRC.
> Anyway, extending Cc!
>
>>> There are probably two things to fix:
>>>
>>>   1. The ‘manifest-lookup-package’ check seems inconsistent with what’s
>>>      passed to ‘union-build’.
>>
>> I think this is the problem to fix.  It's non-intuitive that
>> manifest-lookup-package transitively looks for things instead of looking
>> at the profile.  I actually got tripped by that as well when I authored
>> gdk-pixbuf-loaders-cache-file, so there's now a comment in that same
>> file that reads:
>>
>>              ;; XXX: MANIFEST-LOOKUP-PACKAGE transitively searches through
>>              ;; every input referenced by the manifest, while MANIFEST-INPUTS
>>              ;; only retrieves the immediate inputs as well as their
>>              ;; propagated inputs; to avoid causing an empty output derivation
>>              ;; we must ensure that the inputs contain at least one
>>              ;; loaders.cache file.  This is why we include gdk-pixbuf or
>>              ;; librsvg when they are transitively found.
>>
>> I think we need a 'manifest-lookup-inputs' or similar that stops at the
>> profile, to work at the same depth as manifest-inputs.  Then it wouldn't
>> find texlive-base and the hook wouldn't run (and fail).
>
> There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
> was to take whichever glib/GDK we’d find in the dependency graph, and
> pick the command we need from it.  That way, we wouldn’t introduce any
> additional dependency.  That was the reasoning.
>
> Thinking about, this particular case might be easier: we can make things
> consistent like so:
>
> diff --git a/guix/profiles.scm b/guix/profiles.scm
> index 03333785f9..41f3e25bb3 100644
> --- a/guix/profiles.scm
> +++ b/guix/profiles.scm
> @@ -1786,6 +1786,8 @@ (define entry->texlive-input
>             (cons (gexp-input thing output)
>                   (append-map entry->texlive-input deps))
>             '()))))
> +  (define texlive-inputs
> +    (append-map entry->texlive-input (manifest-entries manifest)))
>    (define texlive-bin
>      (module-ref (resolve-interface '(gnu packages tex)) 'texlive-bin))
>    (define coreutils
> @@ -1809,8 +1811,7 @@ (define build
>            ;; that TeX live can resolve the parent and grandparent directories
>            ;; correctly.  There might be a more elegant way to accomplish this.
>            (union-build "/tmp/texlive"
> -                       '#$(append-map entry->texlive-input
> -                                      (manifest-entries manifest))
> +                       '#$texlive-inputs
>                         #:create-all-directories? #t
>                         #:log-port (%make-void-port "w"))
>  
> @@ -1867,7 +1868,7 @@ (define build
>                (install-file (string-append b "/ls-R") a))))))
>  
>    (mlet %store-monad ((texlive-base (manifest-lookup-package manifest "texlive-base")))
> -    (if texlive-base
> +    (if (and texlive-base (pair? texlive-inputs))
>          (gexp->derivation "texlive-font-maps" build
>                            #:substitutable? #f
>                            #:local-build? #t
>
>
> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
> graph) *and* we have texlive-* packages in the manifest.

That is equivalent, but it doesn't address the core problem in my
opinion.  There's no use to run hooks for things which aren't propagated
at the level of the profile, I think.  If texlive-base in is the
profile, the person wants to use tex and friends.  But if it's wrapped
by some package deep down, we shouldn't care.

I see it the same way as when using libraries and compilers in a
profile; the compiler (consumer) needs to be present else no search path
is created.

Does it make sense?

-- 
Thanks,
Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#63043; Package guix. (Sun, 30 Apr 2023 20:52:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 63043 <at> debbugs.gnu.org
Subject: Re: bug#63043: texlive-font-maps.drv build failure when profiles
 lacks texlive-* packages
Date: Sun, 30 Apr 2023 22:51:37 +0200
Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

>> There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
>> was to take whichever glib/GDK we’d find in the dependency graph, and
>> pick the command we need from it.  That way, we wouldn’t introduce any
>> additional dependency.  That was the reasoning.
>>
>> Thinking about, this particular case might be easier: we can make things
>> consistent like so:

[...]

>> +    (if (and texlive-base (pair? texlive-inputs))
>>          (gexp->derivation "texlive-font-maps" build
>>                            #:substitutable? #f
>>                            #:local-build? #t
>>
>>
>> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
>> graph) *and* we have texlive-* packages in the manifest.
>
> That is equivalent, but it doesn't address the core problem in my
> opinion.  There's no use to run hooks for things which aren't propagated
> at the level of the profile, I think.  If texlive-base in is the
> profile, the person wants to use tex and friends.  But if it's wrapped
> by some package deep down, we shouldn't care.
>
> I see it the same way as when using libraries and compilers in a
> profile; the compiler (consumer) needs to be present else no search path
> is created.
>
> Does it make sense?

I agree with the reasoning; I think it doesn’t apply to the GLib schemas
and GDK pixbuf caches though.

For TeX Live font maps, maybe it applies, though I’m not entirely sure
(I wouldn’t be surprised if things other than ‘texlive-base’ are
consumers of font maps).  Plus, since the patch I proposed is simple,
I’m inclined to just do that.

Thoughts?

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#63043; Package guix. (Mon, 01 May 2023 12:26:02 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 63043 <at> debbugs.gnu.org
Subject: Re: bug#63043: texlive-font-maps.drv build failure when profiles
 lacks texlive-* packages
Date: Mon, 01 May 2023 08:24:52 -0400
Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>>> There were cases (like GDK pixbuf, GLib schemas, and all that) where the idea
>>> was to take whichever glib/GDK we’d find in the dependency graph, and
>>> pick the command we need from it.  That way, we wouldn’t introduce any
>>> additional dependency.  That was the reasoning.
>>>
>>> Thinking about, this particular case might be easier: we can make things
>>> consistent like so:
>
> [...]
>
>>> +    (if (and texlive-base (pair? texlive-inputs))
>>>          (gexp->derivation "texlive-font-maps" build
>>>                            #:substitutable? #f
>>>                            #:local-build? #t
>>>
>>>
>>> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the
>>> graph) *and* we have texlive-* packages in the manifest.
>>
>> That is equivalent, but it doesn't address the core problem in my
>> opinion.  There's no use to run hooks for things which aren't propagated
>> at the level of the profile, I think.  If texlive-base in is the
>> profile, the person wants to use tex and friends.  But if it's wrapped
>> by some package deep down, we shouldn't care.
>>
>> I see it the same way as when using libraries and compilers in a
>> profile; the compiler (consumer) needs to be present else no search path
>> is created.
>>
>> Does it make sense?
>
> I agree with the reasoning; I think it doesn’t apply to the GLib schemas
> and GDK pixbuf caches though.

It does, for the simple reasons that both GDK pixbufs and GLib schemas
are collected using manifest-inputs, which means only direct inputs from
the profile and the ones they propagate.  So if you look deep in the
profile graph for the 'glib-compile-schemas' command, there is a chance
that it is found while no schemas were collected, and this is the kind
of case that'd lead to an empty derivation output (because there's no
schema to compile).

> For TeX Live font maps, maybe it applies, though I’m not entirely sure
> (I wouldn’t be surprised if things other than ‘texlive-base’ are
> consumers of font maps).  Plus, since the patch I proposed is simple,
> I’m inclined to just do that.
>
> Thoughts?

I still think that my proposition is better, but I don't mind if you
apply your fix now and we revisit this at a later time.  If we get to
it, this change could be reverted as it wouldn't be necessary anymore.

-- 
Thanks,
Maxim




Reply sent to Ludovic Courtès <ludo <at> gnu.org>:
You have taken responsibility. (Thu, 04 May 2023 11:16:01 GMT) Full text and rfc822 format available.

Notification sent to Ludovic Courtès <ludo <at> gnu.org>:
bug acknowledged by developer. (Thu, 04 May 2023 11:16:01 GMT) Full text and rfc822 format available.

Message #25 received at 63043-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 63043-done <at> debbugs.gnu.org
Subject: Re: bug#63043: texlive-font-maps.drv build failure when profiles
 lacks texlive-* packages
Date: Thu, 04 May 2023 13:14:55 +0200
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>>> That is equivalent, but it doesn't address the core problem in my
>>> opinion.  There's no use to run hooks for things which aren't propagated
>>> at the level of the profile, I think.  If texlive-base in is the
>>> profile, the person wants to use tex and friends.  But if it's wrapped
>>> by some package deep down, we shouldn't care.
>>>
>>> I see it the same way as when using libraries and compilers in a
>>> profile; the compiler (consumer) needs to be present else no search path
>>> is created.
>>>
>>> Does it make sense?
>>
>> I agree with the reasoning; I think it doesn’t apply to the GLib schemas
>> and GDK pixbuf caches though.
>
> It does, for the simple reasons that both GDK pixbufs and GLib schemas
> are collected using manifest-inputs, which means only direct inputs from
> the profile and the ones they propagate.  So if you look deep in the
> profile graph for the 'glib-compile-schemas' command, there is a chance
> that it is found while no schemas were collected, and this is the kind
> of case that'd lead to an empty derivation output (because there's no
> schema to compile).

Ah yes, that’s right.

I was looking at it the other way around: GLib and GDK caches need to be
built even if glib/gdk-pixbuf does not appear in the manifest.

>> For TeX Live font maps, maybe it applies, though I’m not entirely sure
>> (I wouldn’t be surprised if things other than ‘texlive-base’ are
>> consumers of font maps).  Plus, since the patch I proposed is simple,
>> I’m inclined to just do that.
>>
>> Thoughts?
>
> I still think that my proposition is better, but I don't mind if you
> apply your fix now and we revisit this at a later time.  If we get to
> it, this change could be reverted as it wouldn't be necessary anymore.

Right.

I pushed it as 916c6e5716bd14cb328f7dcce5405ba9100bb908.

Thanks,
Ludo’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 01 Jun 2023 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 330 days ago.

Previous Next


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