bug#64827: Texlive-biber not installable

bug#64827: Texlive-biber not installable

[Andreas Enge]

Hello,

the latest texlive update (cudos!) has left texlive-biber broken, at least
in conjunction with the monolithic texlive:

$ guix shell texlive texlive-biber
The following derivation will be built:
  /gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building TeX Live font maps...
/builder for `/gnu/store/07yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv' failed with exit code 1
build of /gnu/store/07yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv failed
View build log at '/var/log/guix/drvs/07/yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv.gz'.
cannot build derivation `/gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv': 1 dependencies couldn't be built
guix shell: error: build of `/gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv' failed


Here is the end of
/var/log/guix/drvs/07/yvc85w6piyggplfmmb211ljfp4kvqp-texlive-font-maps.drv.gz
(not reproducing all the warnings at the beginning of the file):
Use of uninitialized value $fn in concatenation (.) or string at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2158.
Use of uninitialized value $fn in concatenation (.) or string at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
updmap: open() failed: No such file or directory at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
Use of uninitialized value $fn in concatenation (.) or string at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2158.
Use of uninitialized value $fn in concatenation (.) or string at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
updmap: open() failed: No such file or directory at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
Use of uninitialized value $fn in concatenation (.) or string at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2158.
Use of uninitialized value $fn in concatenation (.) or string at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
updmap: open() failed: No such file or directory at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
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/zdmcg1a44zijbcf5a1p4bd030lc?")
In ice-9/eval.scm:
    619:8  1 (_ #(#(#(#<directory (guile-user) 7ffff77f7c80> #) #) #))
In guix/build/utils.scm:
    812:6  0 (invoke "/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-t?" ?)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. &invoke-error:
      program: "/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap-sys"
      arguments: ("--cnffile=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/web2c/updmap.cfg" "--dvipdfmxoutputdir=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/fonts/map/dvipdfmx/updmap" "--dvipsoutputdir=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/fonts/map/dvips/updmap" "--pdftexoutputdir=/gnu/store/m8pgn9zabl8h3pgaqs7hxj8y9z4mvxhs-texlive-font-maps/share/texmf-dist/fonts/map/pdftex/updmap")
      exit-status: 1
      term-signal: #f
      stop-signal: #f

Andreas

bug#64827: Acknowledgement (Texlive-biber not installable)

[Andreas Enge]

Well, it looks like all of texlive broke for me. In a profile with texlive,
I now get this:

$ pdflatex xyz.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix) (preloaded format=pdflatex)
 restricted \write18 enabled.

kpathsea: Running mktexfmt pdflatex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence order):
mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes:
mktexfmt:   /home/enge/.texlive2023/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under /home/enge/.texlive2023/texmf-var/web2c
mktexfmt [INFO]: Did not find entry for byfmt=pdflatex skipped
mktexfmt [INFO]: total formats: 0
mktexfmt [INFO]: exiting with status 0
I can't find the format file `pdflatex.fmt'!

Andreas

bug#64827: Acknowledgement (Texlive-biber not installable)

[Ricardo Wurmus]

Hi Andreas,

> I can't find the format file `pdflatex.fmt'!

This sounds like a sibling of https://issues.guix.gnu.org/64729

-- 
Ricardo

bug#64827: Texlive has become slow

[Andreas Enge]

Hello,

Am Tue, Jul 25, 2023 at 12:09:06AM +0200 schrieb Ricardo Wurmus:
> > I can't find the format file `pdflatex.fmt'!
> This sounds like a sibling of https://issues.guix.gnu.org/64729

it looks similar indeed. But notice that I use the monolithic package
"texlive".

And I just tried it again and - it just works! In the meantime, I have
rebooted. And while I thought I had done it, I must have forgotten to
include $GUIX_PROFILE/etc/profile for updating environment variables.

However, it has become extremely slow. When compiling a 42 page document:
real	0m22,757s
user	0m7,243s
sys	0m15,370s
Before it even outputs the first page of the document, I get pages and
pages of screen output looking like lisp code:
(/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amstext.sty (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) ...

This is compared to before:
real	0m1,426s
user	0m1,191s
sys	0m0,113s
Where the lisp style lines look like this:
(/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
-dist/tex/latex/amsmath/amstext.sty
(/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
-dist/tex/latex/amsmath/amsgen.sty))

The difference is that before, /home/enge/.guix-profile/share/texmf-dist
was directly a symbolic link into the store. Now it is a directory, and
each file in it is its own symbolic link to a file in the store, and
resolving them apparently takes a lot of time.

I am confused as to why this happens.
/home/enge/.guix-profile/share/texmf-dist contains 28 symbolic links,
26 of which point to directories and 2 to files (ls-R and README) in
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/
Then there is the "physical" directory web2c. It contains 47 separate
symbolic links to files and directories in
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c.

I do not understand why not the complete texmf-dist is a symbolic link
as before, as the content seems to be the same, which should be handled
during the profile creation.
Maybe because of this in the definition of the texlive package:
      ;; Build the union of texlive-bin-full and texlive-texmf, but take the
      ;; conflicting subdirectory share/texmf-dist from texlive-texmf.
What is the role of texlive-bin-full? Why does it contain share/texmf-dist?
The basic architecture was to separate the binaries in texlive-bin (which
needed compilation) from the tex files in texlive-texmf (which mainly needed
copying, plus the black tex magic of format and font map creation), and
their union was texlive.

My impression is that
commit 19fd1004138b60c4479d7516aa0cee261c0b6b57
Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Date:   Mon Jun 26 12:00:51 2023 +0200
    gnu: Externalize libkpathsea in texlive and texlive-bin.
poses problems. Which problem is it supposed to solve?

What is the idea of the new architecture? Having texlive-libkpathsea,
texlive-bin and texlive-bin-full, all the three with very long package
definitions, looks very complex to me.
Would it be possible and make sense to revert this commit?

I considered opening a new bug, since this one looked distinct from
not being able to install texlive-biber; but I wonder if texlive-biber
is not simply a symptom of the same problem.

The error message is
updmap: open() failed: No such file or directory at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
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?

Notice the location of the updmap script. The one in my profile points to
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/bin/updmap
of the texlive package and the missing .map files are there at
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/fonts/map/dvips/tetex/dvips35.mapand so on.

So my impression is that the new way of packaging breaks the monolithic
texlive package, and that the texlive-biber package by using the
texlive-build-system has become incompatible with the monolithic texlive.
This comes from commit
commit 3aeca58073eff8b7a835f6492e735dd152d9dc99
Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Date:   Mon Jun 19 14:43:56 2023 +0200
    gnu: biber -> texlive-biber.
which moves from perl-build-system to texlive-build-system.

Andreas

bug#64827: Texlive has become slow

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> However, it has become extremely slow. When compiling a 42 page document:
> real	0m22,757s
> user	0m7,243s
> sys	0m15,370s
> Before it even outputs the first page of the document, I get pages and
> pages of screen output looking like lisp code:
> (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amstext.sty (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) ...
>
> This is compared to before:
> real	0m1,426s
> user	0m1,191s
> sys	0m0,113s
> Where the lisp style lines look like this:
> (/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
> -dist/tex/latex/amsmath/amstext.sty
> (/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
> -dist/tex/latex/amsmath/amsgen.sty))
>
> The difference is that before, /home/enge/.guix-profile/share/texmf-dist
> was directly a symbolic link into the store. Now it is a directory, and
> each file in it is its own symbolic link to a file in the store, and
> resolving them apparently takes a lot of time.

Interesting!

> I am confused as to why this happens.
> /home/enge/.guix-profile/share/texmf-dist contains 28 symbolic links,
> 26 of which point to directories and 2 to files (ls-R and README) in
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/
> Then there is the "physical" directory web2c. It contains 47 separate
> symbolic links to files and directories in
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c.
>
> I do not understand why not the complete texmf-dist is a symbolic link
> as before, as the content seems to be the same, which should be handled
> during the profile creation.

Monolithic TeX Live is (and always was) unrelated to profiles.

> Maybe because of this in the definition of the texlive package:
>       ;; Build the union of texlive-bin-full and texlive-texmf, but take the
>       ;; conflicting subdirectory share/texmf-dist from texlive-texmf.

This was exactly the same before "texlive-team-next" merge. I just
renamed `texlive-bin' as `texlive-bin-full'.

> What is the role of texlive-bin-full?

`texlive-bin-full' should be equivalent to `texlive-bin' before the
merge. It contains all binaries, and all scripts.

> Why does it contain share/texmf-dist?

I think scripts in "bin/" are symlinks to real scripts in
"share/texmf-dist".

> The basic architecture was to separate the binaries in texlive-bin (which
> needed compilation) from the tex files in texlive-texmf (which mainly needed
> copying, plus the black tex magic of format and font map creation), and
> their union was texlive.

This should still be the same. The main difference is that `texlive-bin'
was renamed `texlive-bin-full'. Any other change was probably not intended.

> My impression is that
> commit 19fd1004138b60c4479d7516aa0cee261c0b6b57
> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date:   Mon Jun 26 12:00:51 2023 +0200
>     gnu: Externalize libkpathsea in texlive and texlive-bin.
> poses problems. Which problem is it supposed to solve?
>
> What is the idea of the new architecture? Having texlive-libkpathsea,
> texlive-bin and texlive-bin-full, all the three with very long package
> definitions, looks very complex to me.

It is not. Maybe the comment at the beginning of "tex.scm" would help
you understand it better. In a nutshell `texlive-bin' is for modular TeX
Live, whereas `texlive-bin-full' is for monolithic TeX Live. Both rely
on `texlive-libkpathsea', which can also be used to build other
executables (such as xindy) and remove them from `texlive-bin'.

> Would it be possible and make sense to revert this commit?

I don't think so, per above. This commit, which may be imperfect, is
essential to the modularization of the TeX Live system.

> I considered opening a new bug, since this one looked distinct from
> not being able to install texlive-biber; but I wonder if texlive-biber
> is not simply a symptom of the same problem.

I don't think the issue is related to `texlive-biber'.

> The error message is
> updmap: open() failed: No such file or directory at /gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap line 2159.
> 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?
>
> Notice the location of the updmap script. The one in my profile points to
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/bin/updmap
> of the texlive package and the missing .map files are there at
> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/fonts/map/dvips/tetex/dvips35.mapand so on.

Profile hook `texlive-font-maps' is triggered by modular TeX Live, i.e.,
any "texlive-" prefixed package in the profile. If you don't install
any, it should not be run.

When it is run, however, it uses tools from modular TeX Live, not from
monolithic TeX Live.

I think the issue here may be that you are conflating the two TeX Live
systems currently provided by Guix, i.e., you both install `texlive' and
some "texlive-" package.

> So my impression is that the new way of packaging breaks the monolithic
> texlive package, and that the texlive-biber package by using the
> texlive-build-system has become incompatible with the monolithic texlive.
> This comes from commit
> commit 3aeca58073eff8b7a835f6492e735dd152d9dc99
> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date:   Mon Jun 19 14:43:56 2023 +0200
>     gnu: biber -> texlive-biber.
> which moves from perl-build-system to texlive-build-system.

Coming from modular TeX Live, `texlive-biber' is certainly incompatible
with monolithic TeX Live, which, being monolithic, is expected to
include "biber" executable anyway.

Basically, if you install `texlive' package, you probably shouldn't
install any "texlive-" prefixed package. If, for some reason, you do,
you should ensure "texlive-" prefixed packages form a coherent system,
i.e., they are expected to provide some collection or scheme.

Regards,
-- 
Nicolas Goaziou

bug#64827: Texlive-biber not installable

[Andreas Enge]

Hello!

Am Wed, Jul 26, 2023 at 05:25:59PM +0200 schrieb Nicolas Goaziou:
> This should still be the same. The main difference is that `texlive-bin'
> was renamed `texlive-bin-full'. Any other change was probably not intended.

Okay, I understand. It looks like there was another change, but I do not
see what it was...

> I think the issue here may be that you are conflating the two TeX Live
> systems currently provided by Guix, i.e., you both install `texlive' and
> some "texlive-" package.

Okay. In my profile, I only have texlive and biber.

Since biber is deprecated by texlive-biber, updating the profile leads to
texlive and texlive-biber being there, which causes this conflict.
I think the solution will simply be to reinstate the previous biber
package to go with the monolithic texlive and keep it next to texlive-biber.

> Coming from modular TeX Live, `texlive-biber' is certainly incompatible
> with monolithic TeX Live, which, being monolithic, is expected to
> include "biber" executable anyway.

No, biber was not part of the monolithic texlive. Probably because it is
an additional binary which is not part of texlive-bin. Or maybe it was not
part of the texlive distribution in the past? We used to download it
separately from CPAN. Re-adding the biber package will be an easy fix,
I think; indeed maybe it should be added by default to the monolithic
texlive, assuming that its source code is part of the texlive distribution.
Apart from that, I have no strong opinion either way.

> Monolithic TeX Live is (and always was) unrelated to profiles.

Well, these symlinks to files or directories in the store are created
when the profile is put together. And for efficiency, the links are
to the highest level directory that is not merged from two different
packages. So what is linked depends on what is in the profile, and
for instance splitting a package in two can lead to files being linked
rather than directories. But this does not seem to be the case here,
I do not quite understand yet what is happening.

> You seem to have some clues about the slowness; you reported there are
> too many symlinks in monolithic TeX Live. This is not intended and
> should be fixed.

Clues, yes, but not a full understanding yet.

Thanks for the explanations,

Andreas

bug#64827: Texlive-biber not installable

[Andreas Enge]

Am Wed, Jul 26, 2023 at 06:33:51PM +0200 schrieb Andreas Enge:
> > You seem to have some clues about the slowness; you reported there are
> > too many symlinks in monolithic TeX Live. This is not intended and
> > should be fixed.
> Clues, yes, but not a full understanding yet.

To clear things up, I have removed biber from my profile.

So now there is only texlive@2021, which contains this in
.guix-profile/share/ related to tex:
$ ll .guix-profile/share/ | grep texlive
lrwxrwxrwx   1 root root    77  1. Jan 1970  texmf-dist -> /gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/texmf-dist
lrwxrwxrwx   1 root root    76  1. Jan 1970  texmf-var -> /gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/texmf-var
lrwxrwxrwx   1 root root    72  1. Jan 1970  tlpkg -> /gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/tlpkg

If I update to texlive@2023:
dr-xr-xr-x   3 root root  4096  1. Jan 1970  texmf-dist/
lrwxrwxrwx   1 root root    72  1. Jan 1970  tlpkg -> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/tlpkg

And as mentioned before, texmf-dist contains symlinks of the kind
tex -> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/tex
as well as a "physical" subdirectory web2c with symlinks such as
xetex -> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c/xetex

Whereas strangely, the texlive package itself has only this:
texmf-dist -> /gnu/store/s6w8r5q3aql1bhasv0nmwr5xgjv6qnhh-texlive-texmf-20230313/share/texmf-dist

Weird, where does the split come from?


Note that we also lost texmf-var compared to the previous release.
Actually things that used to be in texmf-var - the format file
texmf-var/web2c/xetex/xetex-fmt, for instance, can now be found in
texmf-dist.
This is another clue, since the split of the links happens along web2c
(but I still do not understand why).

From https://www.tug.org/texlive/doc/texlive-en/texlive-en.html section 2.3
I surmise that we need the texmf-var directory back; this is where the
formats are supposed to reside.

It probably disappeared in commit 19fd1004138b60c4479d7516aa0cee261c0b6b57:
...
    (texlive-texmf)[build-system]: Use COPY-BUILD-SYSTEM.
    [arguments]: Set #:INSTALL-PLAN accordingly.  Replace TEXLIVE-BIN with
    TEXLIVE-BIN-FULL.
...
+      #:install-plan #~'(("texmf-dist/" "share/texmf-dist"))
...
+                     (web2c (string-append texmf-dist "/web2c"))
...
-                (invoke "fmtutil-sys" "--all")))))))
+                (invoke (string-append texlive-bin "/bin/fmtutil-sys")
+                        "--cnffile" fmtutil.cnf
+                        "--all"
+                        "--fmtdir" web2c)))))))

I suspect these to be the main difference between the old and the new
texlive-texmf.

There is also a somewhat suspicious
+                (setenv "GUIX_TEXMF" texmf-dist)
and
-                (setenv "TEXMFCNF" texmfroot)
of which I do not know what the results are.
And a lacking
-                (invoke "mktexlsr")
which is probably not very important.

Oh wait...
Before:
$ ll $HOME/.guix-profile/share/texmf-dist/ls-R
-r--r--r-- 5 root root 4812162  1. Jan 1970  /home/andreas/.guix-profile/share/texmf-dist/ls-R
After:
lrwxrwxrwx 1 root root 82  1. Jan 1970  /home/andreas/.guix-profile/share/texmf-dist/ls-R -> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/ls-R

Notice the difference in size. The latter gives only the names of the
subdirectories, the former all files.

I think the slowness comes from the fact that now with the monolithic
texlive every file needs to be searched for, instead of being just
picked up from the list in ls-R.

So I would suggest to revert dropping texmf-var by adding it to the
#:install-plan and not putting '"--fmtdir" web2c', and to re-add
running mktexlsr.

Now the question is, will this mktexlsr run disturb the modular texlive?
I suppose not.

In the worst case, we would need separate texlive-texmf for the two
texlive versions.

Andreas

bug#64827: texlive is broken

[Andreas Enge]

Am Wed, Jul 26, 2023 at 08:17:02PM +0200 schrieb Andreas Enge:
> Oh wait...
> Before:
> $ ll $HOME/.guix-profile/share/texmf-dist/ls-R
> -r--r--r-- 5 root root 4812162  1. Jan 1970  /home/andreas/.guix-profile/share/texmf-dist/ls-R
> After:
> lrwxrwxrwx 1 root root 82  1. Jan 1970  /home/andreas/.guix-profile/share/texmf-dist/ls-R -> /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/ls-R
> 
> Notice the difference in size. The latter gives only the names of the
> subdirectories, the former all files.

No, I was wrong here. 82 is the size of the symlink, the file itself does
contain all the file names.

But there is also this now as part of the texlive package:
+    (propagated-inputs (list texlive-libkpathsea))

texlive-libkpathsea contains
   /gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c/texmf.cnf
texlive (as a symlink to texlive-texmf) contains
   /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c/texmf.cnf
They are not the same:
$ diff /gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c/texmf.cnf /gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c/texmf.cnf
62c62
< TEXMFROOT = {$GUIX_TEXMF}/..
---
> TEXMFROOT = $SELFAUTOPARENT
111c111
< TEXMF = {$GUIX_TEXMF}
---
> TEXMF = {$TEXMFAUXTREES$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFLOCAL,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDIST}
575c575
< /gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c,\
---
> $SELFAUTOLOC/share/texmf-dist/web2c,\
872,874c872,874
< error_line = 254
< half_error_line = 238
< max_print_line = 1000
---
> error_line = 79
> half_error_line = 50
> max_print_line = 79

I think with the propagation of texlive-libkpathsea, there is a conflict
in the profile, which appears to be resolved in favour of texlive;
however, this probably explains why texmf-dist in the profile is no more
just a symlink. In principle it could contain files from two distinct
packages, those just happen to be in conflict.


By the way, the following also fails:
   $ guix shell --container --pure -D texlive
The following derivation will be built:
  /gnu/store/rdrqavbga5rg9l20vpr1ac79psdndj4d-profile.drv
building TeX Live font maps...
/builder for `/gnu/store/bnyjd9vgyqniarynlvcia5vnm36pik9i-texlive-font-maps.drv' failed with exit code 1
build of /gnu/store/bnyjd9vgyqniarynlvcia5vnm36pik9i-texlive-font-maps.drv failed
View build log at '/var/log/guix/drvs/bn/yjd9vgyqniarynlvcia5vnm36pik9i-texlive-font-maps.drv.gz'.
cannot build derivation `/gnu/store/rdrqavbga5rg9l20vpr1ac79psdndj4d-profile.drv': 1 dependencies couldn't be built
guix shell: error: build of `/gnu/store/rdrqavbga5rg9l20vpr1ac79psdndj4d-profile.drv' failed

The log file contains lots of messages of the form:
warning: collision encountered:
  /gnu/store/yzsq1dykjv96h88pcja0hcjbagn2vjxv-texlive-bin-full-20230313/share/texmf-dist/scripts/l3build/l3build.lua
  /gnu/store/s6w8r5q3aql1bhasv0nmwr5xgjv6qnhh-texlive-texmf-20230313/share/texmf-dist/scripts/l3build/l3build.lua
warning: choosing /gnu/store/yzsq1dykjv96h88pcja0hcjbagn2vjxv-texlive-bin-full-20230313/share/texmf-dist/scripts/l3build/l3build.lua

So here the conflicts are made directly visible.


With the propagation of texlive-libkpathsea, texlive is clearly not just
the composition of (the former) texlive-bin and texlive-texmf any more,
where nothing was propagated as far as I can remember. Also, ls-R is now
created as part of texlive instead of texlive-texmf, which may make a
difference. And texmf-var has disappeared, and I have not yet understood
where it has gone. These are a lot of subtle changes, and they do break
the monolithic texlive.

What could be a way forward to restore the texlive package?

Would it be feasible to revert these commits, or is everything too
mixed now?

If the merge cannot be reverted, how about creating the two packages
(texlive-bin and texlive-texmf) required for the monolithic
texlive completely separately as before and reinstating texlive to be
built from scratch without links with the modular texlive? 

Andreas

bug#64827: texlive is broken

[Andreas Enge]

Hello again,

Am Wed, Jul 26, 2023 at 09:51:49PM +0200 schrieb Andreas Enge:
> Would it be feasible to revert these commits, or is everything too
> mixed now?

I confirm that going back to commit
   0561616a3208aa17fe5b1f9c425c44fe00218b08 ,
which is one before
   19fd1004138b60c4479d7516aa0cee261c0b6b57
results in a working monolithic texlive, with texmf-dist in the user
profile being a symlink to the corresponding directory of texlive,
itself a symlink to the corresponding directory of texlive-texmf;
and similarly for texmf-var.

However,
   ./pre-inst-env guix shell --container --pure -D texlive
still does not work any more. It prints
   building TeX Live font maps...
(which looks like something a monolithic texlive should not do),
and it shows conflicts such as between
  /gnu/store/y72v93b7f12nx8xq0ljwlzj9yn5b07vk-texlive-bin-20230313/share/texmf-dist/scripts/chktex/deweb.pl
  /gnu/store/l8g23z46mpzzbq7isnjk65vcx47i2cgf-texlive-texmf-20230313/share/texmf-dist/scripts/chktex/deweb.pl

I will go back in time (without exactly bisecting, just by gut feeling)
to find a commit where this command works.

Andreas

bug#64827: texlive is broken

[Andreas Enge]

Am Wed, Jul 26, 2023 at 11:21:23PM +0200 schrieb Andreas Enge:
> still does not work any more. It prints
>    building TeX Live font maps...
> (which looks like something a monolithic texlive should not do),
> and it shows conflicts such as between
>   /gnu/store/y72v93b7f12nx8xq0ljwlzj9yn5b07vk-texlive-bin-20230313/share/texmf-dist/scripts/chktex/deweb.pl
>   /gnu/store/l8g23z46mpzzbq7isnjk65vcx47i2cgf-texlive-texmf-20230313/share/texmf-dist/scripts/chktex/deweb.pl

Actually the roots of this go back a very long time!

commit dfdc002c9bf86270941823a96abded0aa5d44088
Author: Ricardo Wurmus <rekado@elephly.net>
Date:   Mon Jul 15 19:07:40 2019 +0200
    gnu: texlive-bin: Include scripts.
    * gnu/packages/tex.scm (texlive-bin)[inputs]: Add texlive-scripts.
    [arguments]: Let fmtutil.pl reference scripts directory.

This commit includes into texlive-bin files not taken from the tarball,
but downloaded via subversion. This is only needed for the modular texlive,
I suppose, since in the monolithic one these files will be taken from
texlive-texmf. However, this has been working nevertheless for a long time.

Then there is
commit 04a0b1e09abce99857e7930336421ca6d15ae630 (HEAD)
Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date:   Mon Jan 11 11:08:15 2021 -0500
    gnu: texlive-bin: Enable the use of multiple TeX Live trees.
    Attempting to compose multiple TeX Live trees (such as can happen when using a
    texlive-union generated package) proved problematic; only the texmf.cnf
    configuration file from the union would be honored, causing other TeX Live
    components to be ignored.
    This change does away with TeX Live unions, instead relying on the default
    texmf.cnf configuration file provided by the texlive-bin package to honor
    individual TeX Live trees referred to via the newly introduced GUIX_TEXMF
    variable, and replacing the texlive-union procedure by texlive-updmap.cfg, to
    explicit that generating the fonts map configuration is now its sole purpose.

This introduces the GUIX_TEXMF environment variable, and the commit is
clearly only useful for the modular texlive.


Going back to commit 9fadbf759c7ae0c4555bf43883f3f0a0d8a4e6a6 is not
enough to get "guix shell -D texlive".

Going back to commit ad457d01147b8d6fcb4ee64b2dc2d699caa1d1ee of July 17
(this one happens to be a day I did a "guix pull") works for "guix shell".
I do not quite understand why - here also both packages have collisions
in the script files as above.

Given how much the current texlive-bin and texlive-kpathsea and thus
probably the derived texlive-bin-full cater to the needs of modular
texlive, I wonder whether for a monolithic package it would not be easier
to start from scratch on a clean slate, using modern source and an
old package recipe.

Now the question is whether we still want a monolithic package in the
distribution. Historically it is there because it was the easiest to
package. But I must say that while I find it a bit painful to install
(all these gigabytes of data to copy!), I have also come to find it
tremendously useful. All of texlive with me all the time! So I am quite
certain I would want to maintain it.

Andreas

bug#64827: texlive is broken

[Nicolas Goaziou]

Hello,

I'm sorry as I have limited time and bandwidth right now to help you
solve this issue. It doesn't seem too bad, tho.

Andreas Enge <andreas@enge.fr> writes:

> Actually the roots of this go back a very long time!
>
> commit dfdc002c9bf86270941823a96abded0aa5d44088
> Author: Ricardo Wurmus <rekado@elephly.net>
> Date:   Mon Jul 15 19:07:40 2019 +0200
>     gnu: texlive-bin: Include scripts.
>     * gnu/packages/tex.scm (texlive-bin)[inputs]: Add texlive-scripts.
>     [arguments]: Let fmtutil.pl reference scripts directory.
>
> This commit includes into texlive-bin files not taken from the tarball,
> but downloaded via subversion. This is only needed for the modular texlive,
> I suppose, since in the monolithic one these files will be taken from
> texlive-texmf. However, this has been working nevertheless for a long time.
>
> Then there is
> commit 04a0b1e09abce99857e7930336421ca6d15ae630 (HEAD)
> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date:   Mon Jan 11 11:08:15 2021 -0500
>     gnu: texlive-bin: Enable the use of multiple TeX Live trees.
>     Attempting to compose multiple TeX Live trees (such as can happen when using a
>     texlive-union generated package) proved problematic; only the texmf.cnf
>     configuration file from the union would be honored, causing other TeX Live
>     components to be ignored.
>     This change does away with TeX Live unions, instead relying on the default
>     texmf.cnf configuration file provided by the texlive-bin package to honor
>     individual TeX Live trees referred to via the newly introduced GUIX_TEXMF
>     variable, and replacing the texlive-union procedure by texlive-updmap.cfg, to
>     explicit that generating the fonts map configuration is now its sole purpose.
>
> This introduces the GUIX_TEXMF environment variable, and the commit is
> clearly only useful for the modular texlive.
>
>
> Going back to commit 9fadbf759c7ae0c4555bf43883f3f0a0d8a4e6a6 is not
> enough to get "guix shell -D texlive".

I think this may be fixed by tweaking `texlive-font-maps' function in
"profiles.scm". This function should only be used for modular TeX Live,
and the criteria used for it is very gross: it checks the presence of
a "texlive-" prefixed package among the entries.

Unfortunately, when using "guix shell -D texlive", `texlive-libkpathsea'
is among the entries, and `texlive-font-maps' is activated.

> Going back to commit ad457d01147b8d6fcb4ee64b2dc2d699caa1d1ee of July 17
> (this one happens to be a day I did a "guix pull") works for "guix shell".
> I do not quite understand why - here also both packages have collisions
> in the script files as above.

Collisions are harmless. It is possible to avoid them, but a bit
tedious.

> Given how much the current texlive-bin and texlive-kpathsea and thus
> probably the derived texlive-bin-full cater to the needs of modular
> texlive, I wonder whether for a monolithic package it would not be easier
> to start from scratch on a clean slate, using modern source and an
> old package recipe.

I don't think you can do away with the dichotomy between
`texlive-bin-full' (previously texlive-bin) and `texlive-texmf'. The
former is used to build the executables and the latter contains
everything else. I don't think there exists a way to merge these two
steps into one.

> Now the question is whether we still want a monolithic package in the
> distribution. Historically it is there because it was the easiest to
> package. But I must say that while I find it a bit painful to install
> (all these gigabytes of data to copy!), I have also come to find it
> tremendously useful. All of texlive with me all the time! So I am quite
> certain I would want to maintain it.

Note that modular `texlive-scheme-full' (not yet packaged!) would be
equivalent to monolithic `texlive'. At some point, we may be able to
drop `texlive' (and `texlive-bin-full'). Even if we do not hit 100%
coverage (who really needs that?), it is still possible to install
a complete TeX Live system using the genuine TeX Live installer.

Meanwhile, fixing `texlive' should not be too hard, and monolithic and
modular TeX Live are still pretty much independent from each other.
n
In particular, `texlive-libkpathsea' is not indispensable for
`texlive-bin-full'; it was introduced, along with inheritance from
`texlive-bin', to reduce code duplication. IOW, it should possible to
partly revert 19fd1004138b60c4479d7516aa0cee261c0b6b57 — i.e., make
`texlive-bin-full' a copy of previous `texlive-bin', barring the update,
and some related fixes such as disabling parallel tests — should fix
monolithic's issue.

Would you have some time to try it?

Regards,
-- 
Nicolas Goaziou

bug#64827: texlive is broken

[Andreas Enge]

Hello,

Am Thu, Jul 27, 2023 at 11:55:01AM +0200 schrieb Nicolas Goaziou:
> I'm sorry as I have limited time and bandwidth right now to help you
> solve this issue. It doesn't seem too bad, tho.

no problem, this is also my last day before vacations.

> I think this may be fixed by tweaking `texlive-font-maps' function in
> "profiles.scm". This function should only be used for modular TeX Live,
> and the criteria used for it is very gross: it checks the presence of
> a "texlive-" prefixed package among the entries.
> Unfortunately, when using "guix shell -D texlive", `texlive-libkpathsea'
> is among the entries, and `texlive-font-maps' is activated.

Well, I also just saw this and solved it by calling the packages
"texlivebin" and "texlivetexmf" without a dash... Primitive, but
working.

> I don't think you can do away with the dichotomy between
> `texlive-bin-full' (previously texlive-bin) and `texlive-texmf'. The
> former is used to build the executables and the latter contains
> everything else. I don't think there exists a way to merge these two
> steps into one.

No, I agree. But I think the current texlive-bin-full inherits lots of
things needed only for the modular system. Thus my suggestion to start
it from scratch again without inheritance.

> Meanwhile, fixing `texlive' should not be too hard, and monolithic and
> modular TeX Live are still pretty much independent from each other.
> In particular, `texlive-libkpathsea' is not indispensable for
> `texlive-bin-full'; it was introduced, along with inheritance from
> `texlive-bin', to reduce code duplication. IOW, it should possible to
> partly revert 19fd1004138b60c4479d7516aa0cee261c0b6b57 — i.e., make
> `texlive-bin-full' a copy of previous `texlive-bin', barring the update,
> and some related fixes such as disabling parallel tests — should fix
> monolithic's issue.
> Would you have some time to try it?

Yes, I am on it!

The first commit is in the branch
   wip-texlive-mono
It drops everything monolithic from tex.scm, un-deprecates biber there,
and essentially reinstates commit ad457d01147b8d6fcb4ee64b2dc2d699caa1d1ee
in a new file texlive.scm, including the biber package.

In particular, it reverts the monolithic package back to 2021.

I have tested it by compiling my current favourite latex file (very fast
again) and "guix shell -C --pure -D texlive" (which works due to the dirty
trick above). I have not tested biber, which I normally do not need and
do not even know how it works (I happened to just have to use it blindly
in a project with other people through a Makefile or latexmk or so).

The next step I would like to try is to simplify the package by dropping
things introduced for the modular system. And eventually update it to 2023.
But given that each run easily takes an hour (unfortunately texlivetexmf
suffers from a graft, which takes a long time to go through more than 3GB!),
this can take a while. Definitely longer than today. But since we seem to
be on the same page and your suggestion above corresponds to what I had
already started on my side, the work will not be for nothing, and I am
motivated to hopefully finish it over the summer.

All the best,

Andreas

PS: While trying to push I noticed that there is a branch wip-texlive
    from January 2022; I suppose this can be deleted now?

bug#64827: texlive is broken

[Andreas Enge]

Am Thu, Jul 27, 2023 at 12:59:21PM +0200 schrieb Andreas Enge:
> PS: While trying to push I noticed that there is a branch wip-texlive
>     from January 2022; I suppose this can be deleted now?

Done. The branch appears to have been merged around that time.

Andreas

bug#64827: texlive is broken

[Andreas Enge]

Hello,

my suggestion for the monolithic texlive package is in the branch
wip-texlive-mono. It is now updated to the latest version from 2023.
Two phases and the --with-system-libgs configure flag can be dropped
(which will also be the case for the modular package).

So far, everything is in a separate module, texlive; I would be fine with
leaving it there or moving it to the tex module.

Also, it would probably be better to make the texlivebin and texlivetexmf
packages non-public again.

Apart from that, I think the commits can be applied on top of master.

Andreas

bug#64827: texlive is broken

[Andreas Enge]

Am Mon, Aug 07, 2023 at 06:16:04PM +0200 schrieb Andreas Enge:
> Two phases and the --with-system-libgs configure flag can be dropped
> (which will also be the case for the modular package).

And two more tests can also be dropped; I have compiled the package
successfully on i686 and armhf without them.

Andreas

bug#64827: texlive is broken

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> Am Mon, Aug 07, 2023 at 06:16:04PM +0200 schrieb Andreas Enge:
>> Two phases and the --with-system-libgs configure flag can be dropped
>> (which will also be the case for the modular package).
>
> And two more tests can also be dropped; I have compiled the package
> successfully on i686 and armhf without them.

It would be nice to list what simplifications can be done on
`texlive-bin', so we can apply them on a new "texlive-team" branch.

On a different topic, it is now possible to install both `texlive' and
`texlive-biber' in a manifest, so re-instating the old `biber' package
may introduce code duplication without much benefit. WDYT?

Regards,
-- 
Nicolas Goaziou

bug#64827: texlive is broken

[Andreas Enge]

Hello,

Am Wed, Aug 09, 2023 at 06:35:22PM +0200 schrieb Nicolas Goaziou:
> It would be nice to list what simplifications can be done on
> `texlive-bin', so we can apply them on a new "texlive-team" branch.

see the last commit on the wip-texlive-mono branch; the commit message
and the diff should be quite clear. Concerning the branch itself, it
can be directly applied to master once it is in shape, as nothing depends
on the monolithic texlive.

> On a different topic, it is now possible to install both `texlive' and
> `texlive-biber' in a manifest, so re-instating the old `biber' package
> may introduce code duplication without much benefit. WDYT?

You mean the old/new monolithic texlive from the wip branch and
texlive-biber work together? In that case we should indeed drop biber.

Andreas

bug#64827: texlive is broken

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> see the last commit on the wip-texlive-mono branch; the commit message
> and the diff should be quite clear. Concerning the branch itself, it
> can be directly applied to master once it is in shape, as nothing depends
> on the monolithic texlive.

I was talking about changes ported to the modular `texlive-bin'. Those
need a dedicated branch. You're right, the changes are clear enough.

> You mean the old/new monolithic texlive from the wip branch and
> texlive-biber work together? In that case we should indeed drop biber.

I don't know if the monolithic texlive from the wip branch does, but the
current monolithic `texlive' can be installed without fuss alongside
`texlive-biber'. I don't expect additional issues with `texlive' from
the "wip" branch, tho.

Regards,
-- 
Nicolas Goaziou

bug#64827: texlive is broken

[Andreas Enge]

Am Sun, Aug 13, 2023 at 10:48:16PM +0200 schrieb Nicolas Goaziou:
> I don't know if the monolithic texlive from the wip branch does, but the
> current monolithic `texlive' can be installed without fuss alongside
> `texlive-biber'. I don't expect additional issues with `texlive' from
> the "wip" branch, tho.

This was the starting point of the bug report; for instance
   guix shell texlive texlive-biber
does not work, since having a package named "texlive-..." triggers the
texlive font map creation profile hook, which does not work with the
monolithic texlive.

Interestingly, it does seem to work with my new monolithic texlive and
texlive-biber.

Hm, it also works on the master branch; so this has apparently been solved
between commit 56667ee55cd7f3368cbff169352fe440f4f93da5 of ten days ago
and now.

Okay then, fine to remove biber again!

Andreas

bug#64827: texlive is broken

[Andreas Enge]

Am Thu, Aug 17, 2023 at 01:54:58PM +0200 schrieb Andreas Enge:
> Okay then, fine to remove biber again!

Done in wip-texlive-mono. I also dropped disabling tests for mips64,
as anyway we have no means of testing the architecture any more, so I see
no point in complicating the build recipe.

Where shall we go from here?

Are you okay with me either pushing the package in its own texlive module
where it is now, or moving the definition back into the tex module?
In either case it would probably be a good idea to make the texlivebin
and texlivetexmf variables private again.

Andreas

bug#64827: texlive is broken

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> Are you okay with me either pushing the package in its own texlive module
> where it is now, or moving the definition back into the tex module?

I think it is simpler to to use a new module, as there's currently much
work going on in "tex.scm".

Indeed, I'm currently in the process in packaging `texlive-scheme-full'
(and could use some help, as I might lose my sanity along the way). Once
this is done (if it is ever!), we will be able to remove monolithic Tex
Live completely.

> In either case it would probably be a good idea to make the texlivebin
> and texlivetexmf variables private again.

Sure.

Regards,
-- 
Nicolas Goaziou

bug#64827: texlive is broken

[Andreas Enge]

Am Thu, Aug 17, 2023 at 03:17:55PM +0200 schrieb Nicolas Goaziou:
> I think it is simpler to to use a new module, as there's currently much
> work going on in "tex.scm".

As nothing depends on it, I have just pushed the changes to master and
deleted the wip branch. Thanks for your comments, Nicolas!

As a last change, I have tried to use the current ruby instead of ruby@2.7
for building texlivebin, but it did not work.

> Indeed, I'm currently in the process in packaging `texlive-scheme-full'
> (and could use some help, as I might lose my sanity along the way). Once
> this is done (if it is ever!), we will be able to remove monolithic Tex
> Live completely.

Something to be discussed in a separate forum; guix-devel? I am closing
this bug now.

Andreas

bug#64827: Acknowledgement (Texlive-biber not installable)

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> Well, it looks like all of texlive broke for me. In a profile with texlive,
> I now get this:
>
> $ pdflatex xyz.tex
> This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix) (preloaded format=pdflatex)
>  restricted \write18 enabled.
>
> kpathsea: Running mktexfmt pdflatex.fmt
> mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence order):
> mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes:
> mktexfmt:   /home/enge/.texlive2023/texmf-config/web2c/fmtutil.cnf

Would it be possible to remove the ".texlive2023" directory?

Regards,
-- 
Nicolas Goaziou

bug#64827: Acknowledgement (Texlive-biber not installable)

[Andreas Enge]

Am Wed, Jul 26, 2023 at 04:51:06PM +0200 schrieb Nicolas Goaziou:
> Would it be possible to remove the ".texlive2023" directory?

Yes. Compilation works now, but I still cannot install texlive and
texlive-biber concurrently, and the incredible slowness also remains.

Andreas

bug#64827: Acknowledgement (Texlive-biber not installable)

[Nicolas Goaziou]

Hello,

Andreas Enge <andreas@enge.fr> writes:

> Am Wed, Jul 26, 2023 at 04:51:06PM +0200 schrieb Nicolas Goaziou:
>> Would it be possible to remove the ".texlive2023" directory?
>
> Yes. Compilation works now, but I still cannot install texlive and
> texlive-biber concurrently, and the incredible slowness also remains.

As explained in another message, it may not be a good idea to install
`texlive' and `texlive-biber' concurrently. If it must be, I suggest to
install `texlive', `texlive-biber', _and_ `texlive-scheme-basic'. This
way, you get both monolithic and a valid modular TeX Live on your system
(`texlive-biber' alone does not make up for a valid modular TeX Live).

You seem to have some clues about the slowness; you reported there are
too many symlinks in monolithic TeX Live. This is not intended and
should be fixed.

HTH,

Regards,
-- 
Nicolas Goaziou

bug#64827: Acknowledgement (Texlive-biber not installable)

[Igor Gajsin via Bug reports for GNU Guix]

I had the similar issue. It seams the manual install of the
`texlive-bin` package helped with that.

--
With best regards,
Igor Gajsin

bug#64827: (no subject)

[Igor Gajsin via Bug reports for GNU Guix]

Hi, I had a similar issue and install the «texlive-bin» package helped
with that problem.

--
With best regards,
Igor Gajsin

bug#64827: Texlive-biber not installable

[Vinicius Monego]

Hi,

I have a similar issue when trying to modify a profile containing
jupyter or python-jupyterlab-server:

guix shell jupyter python-jupyterlab-server

Error:

building TeX Live font maps...
-builder for `/gnu/store/q6gakg3lp5rgmcyhmlf5fz7vnhw0vvaz-texlive-font-
maps.drv' failed with exit code 1
a compilação de /gnu/store/q6gakg3lp5rgmcyhmlf5fz7vnhw0vvaz-texlive-
font-maps.drv falhou
Veja o log de compilação em
"/var/log/guix/drvs/q6/gakg3lp5rgmcyhmlf5fz7vnhw0vvaz-texlive-font-
maps.drv.gz".
cannot build derivation `/gnu/store/j98hmraklblr70ggasarp49pk9jgih0d-
profile.drv': 1 dependencies couldn't be built
guix package: erro: build of
`/gnu/store/j98hmraklblr70ggasarp49pk9jgih0d-profile.drv' failed

Content of the decompressed the log file:

Backtrace:
 3 (primitive-load "/gnu/store/4msdwzccfp51zhmnkr61vvpdllz?")<br><br>
In ice-9/eval.scm:
 619:8 2 (_ #f)
In ice-9/boot-9.scm:
 140:2 1 (dynamic-wind #<procedure 7ffff2f3b080 at ice-9/eval.s?> ?)
In unknown file:
 0 (chdir "/tmp/texlive/share/texmf-dist")

ERROR: In procedure chdir:
In procedure chdir: No such file or directory

Vinicius

bug#64827: Texlive-biber not installable

[Nicolas Goaziou]

Hello,

Vinicius Monego <monego@posteo.net> writes:
>
> I have a similar issue when trying to modify a profile containing
> jupyter or python-jupyterlab-server:
>
> guix shell jupyter python-jupyterlab-server

[...]

> ERROR: In procedure chdir:
> In procedure chdir: No such file or directory

Have you tried with a recent guix?

Regards,
-- 
Nicolas Goaziou