Texlive-biber not installable

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

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

I had the similar issue. It seams the manual install of the

`texlive-bin` package helped with that.

--

With best regards,

Igor Gajsin

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

with that problem.

--

With best regards,

Igor Gajsin

Hi Andreas,

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

--

Ricardo

Hello,

Am Tue, Jul 25, 2023 at 12:09:06AM +0200 schrieb Ricardo Wurmus:

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>

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>

gnu: biber -> texlive-biber.

which moves from perl-build-system to texlive-build-system.

Andreas

Hello,

Andreas Enge <andreas@enge.fr> writes:

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

Regards,

--

Nicolas Goaziou

Am Wed, Jul 26, 2023 at 04:51:06PM +0200 schrieb Nicolas Goaziou:

Yes. Compilation works now, but I still cannot install texlive and

texlive-biber concurrently, and the incredible slowness also remains.

Andreas

Hello,

Andreas Enge <andreas@enge.fr> writes:

Interesting!

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

This was exactly the same before "texlive-team-next" merge. I just

renamed `texlive-bin' as `texlive-bin-full'.

`texlive-bin-full' should be equivalent to `texlive-bin' before the

merge. It contains all binaries, and all scripts.

I think scripts in "bin/" are symlinks to real scripts in

"share/texmf-dist".

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.

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

I don't think so, per above. This commit, which may be imperfect, is

essential to the modularization of the TeX Live system.

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

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.

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

Hello,

Andreas Enge <andreas@enge.fr> writes:

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

Hello!

Am Wed, Jul 26, 2023 at 05:25:59PM +0200 schrieb Nicolas Goaziou:

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

see what it was...

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.

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.

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.

Clues, yes, but not a full understanding yet.

Thanks for the explanations,

Andreas

Am Wed, Jul 26, 2023 at 06:33:51PM +0200 schrieb Andreas Enge:

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

Am Wed, Jul 26, 2023 at 08:17:02PM +0200 schrieb Andreas Enge:

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

---

111c111

< TEXMF = {$GUIX_TEXMF}

---

575c575

< /gnu/store/h8vmxcbvk8n25y6zjj17qsq0fncansxs-texlive-libkpathsea-20230313/share/texmf-dist/web2c,\

---

872,874c872,874

< error_line = 254

< half_error_line = 238

< max_print_line = 1000

---

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

Hello again,

Am Wed, Jul 26, 2023 at 09:51:49PM +0200 schrieb Andreas Enge:

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

Am Wed, Jul 26, 2023 at 11:21:23PM +0200 schrieb Andreas Enge:

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

commit dfdc002c9bf86270941823a96abded0aa5d44088

Author: Ricardo Wurmus <rekado@elephly.net>

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>

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

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:

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.

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

tedious.

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.

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

Hello,

Am Thu, Jul 27, 2023 at 11:55:01AM +0200 schrieb Nicolas Goaziou:

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

Well, I also just saw this and solved it by calling the packages

"texlivebin" and "texlivetexmf" without a dash... Primitive, but

working.

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.

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?

Am Thu, Jul 27, 2023 at 12:59:21PM +0200 schrieb Andreas Enge:

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

Andreas

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

Am Mon, Aug 07, 2023 at 06:16:04PM +0200 schrieb Andreas Enge:

And two more tests can also be dropped; I have compiled the package

successfully on i686 and armhf without them.

Andreas

Hello,

Andreas Enge <andreas@enge.fr> writes:

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

Hello,

Am Wed, Aug 09, 2023 at 06:35:22PM +0200 schrieb Nicolas Goaziou:

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.

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

Hello,

Andreas Enge <andreas@enge.fr> writes:

I was talking about changes ported to the modular `texlive-bin'. Those

need a dedicated branch. You're right, the changes are clear enough.

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

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

Hello,

Vinicius Monego <monego@posteo.net> writes:

[...]

Have you tried with a recent guix?

Regards,

--

Nicolas Goaziou

Am Sun, Aug 13, 2023 at 10:48:16PM +0200 schrieb Nicolas Goaziou:

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

Am Thu, Aug 17, 2023 at 01:54:58PM +0200 schrieb Andreas Enge:

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

Hello,

Andreas Enge <andreas@enge.fr> writes:

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.

Sure.

Regards,

--

Nicolas Goaziou

Am Thu, Aug 17, 2023 at 03:17:55PM +0200 schrieb Nicolas Goaziou:

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.

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

this bug now.

Andreas