texlive-font-maps.drv build failure when profiles lacks texlive-* packages

> Hi!

>

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

> I have Guile as a channel, which provides guile@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@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@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’.

> Ludovic Courtès <ludo@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 :-).

>> 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).

> Hello!

>

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

>

>> Ludovic Courtès <ludo@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.

>> 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?

> Hi,

>

> Maxim Cournoyer <maxim.cournoyer@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?

> Ludovic Courtès <ludo@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).

>> 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.