bug#63313: python-txtorcon: Build failure (Sequence not in collection in Python 3.10)

[Juliana Sims]

The aforementioned patch has been merged.

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Csepp]

Csepp  writes:

> Josselin Poiret  writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi,
>>
>> Csepp  writes:
 I don't think there is, the biggest difference is that `guix system
 init` will copy stuff into the target store and initialize the basic
 directories for Guix, whereas reconfigure will just build everything in
 the current store.

 Best,
>>>
>>> I mean, that's the theory, but either Guix or GRUB seems to get the
>>> incorrect UUID from *somewhere*.
>>
>> You can manually check that the generated grub.cfg file contains the
>> expected UUID after the reconfigure, it should be in
>> /boot/grub/grub.cfg.
>>
>> Best,
>
> I did, I think I already wrote that it wasn't coming from there, but
> I'll check again when I next try it.

This is still happening.  Couldn't figure out a decent way to transfer
my system with btrfs send.
I checked the generated bootloader installer script that gets run, it
seems to refer to the correct device, but somehow the UUID of the booted
partition still gets accessed.
I guess I'll have to strace it.

bug#64772: TeXlive (specifically LuaLaTeX) has become terribly slow

[Wojtek Kosior via Bug reports for GNU Guix]

Hi,

I think I know what causes a subdirectory of '{' to be used for caches
— the 'share/texmf-dist/web2c/texmf.cnf' file in the
texlive-libkpathsea package has a

TEXMFROOT = {$GUIX_TEXMF}/..

line. It's a "runtime path configuration file for kpathsea" and in
general it supports brace expansion. However, in this case something
goes wrong. Maybe the expansion is only triggered when there's at least
one comma in between the braces? Idk. Btw, Guix uses ":" and not a
comma as path separator in 'GUIX_TEXMF' variable and I have no idea
whether kpathsea's brace expansion allows ":" to be used instead of ",".

Still, I'm pretty sure it is this line that causes the '{' directory
problem — I tried running lualatex after bind-mounting a modified
texmf.cnf over the one in the store. I replaced that line with

TEXMFROOT = $GUIX_TEXMF/..

and no '{' was created this time. Of course, it only worked because
GUIX_TEXMF was holding just one path — a general solution would need to
be different. Just in case, this is the part of texlive-kpathsea
definition in gnu/packages/tex.scm that prepares 'texmf.cnf':

```
  (add-after 'unpack 'customize-texmf.cnf
;; The default "texmf.cnf" file is provided by this package.
;; Every variable of interest is set relatively to the GUIX_TEXMF
;; environment variable defined via a search path below.
;;
;; This phase must happen before the `configure' phase, because
;; the value of the TEXMFCNF variable (modified along with the
;; SELFAUTOLOC reference below) is used at compile time to
;; generate "paths.h" file.
(lambda _
  (substitute* "texk/kpathsea/texmf.cnf"
(("^TEXMFROOT = .*")
 "TEXMFROOT = {$GUIX_TEXMF}/..\n")
(("^TEXMF = .*")
 "TEXMF = {$GUIX_TEXMF}\n")
(("\\$SELFAUTOLOC(/share/texmf-dist/web2c)" _ suffix)
 (string-append #$output suffix))
;; Don't truncate lines.
(("^error_line = .*$") "error_line = 254\n")
(("^half_error_line = .*$") "half_error_line = 238\n")
(("^max_print_line = .*$") "max_print_line = 1000\n"

```

Unfortunately, changes to 'texmf.cnf' don't affect the running time of
lualatex — it's still terribly slow

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


pgpY3brUPuj_7.pgp
Description: OpenPGP digital signature

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 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#64881: [translation] M-x texinfo-all-menus-update breaks translated cookbook

[Maxim Cournoyer]

Hi,

When attempting to run `M-x texinfo-all-menus-update' from Emacs on the
guix-cookbook.texi file, it builds fine, but auto-generated translated
variants do not, which breaks 'make as-derivation' (or 'guix pull').

The error reported by 'make as-derivation' is:

--8<---cut here---start->8---
guix.es.texi:19860: warning: `.' or `,' must follow @xref, not p
guix.es.texi:46332: warning: `.' or `,' must follow @xref, not p
guix.fr.texi:15422: warning: `.' or `,' must follow @xref, not p
Wide character in warn at 
/gnu/store/9d7c6c8id6dh0inpqvcgb708mmiqcj4c-texinfo-6.8/bin/makeinfo line 637.
guix.ru.texi:13064: warning: `.' or `,' must follow @xref, not д
guix-cookbook.de.texi:570: @menu reference to nonexistent node `A ``Hello 
World'' package'
guix-cookbook.de.texi:571: @menu reference to nonexistent node `Setup'
guix-cookbook.de.texi:572: @menu reference to nonexistent node `Extended 
example'
guix-cookbook.de.texi:573: @menu reference to nonexistent node `Other build 
systems'
guix-cookbook.de.texi:574: @menu reference to nonexistent node `Programmable 
and automated package definition'
guix-cookbook.de.texi:575: @menu reference to nonexistent node `Getting help'
guix-cookbook.de.texi:576: @menu reference to nonexistent node `Conclusion'
guix-cookbook.de.texi:801: @menu reference to nonexistent node `Local file'
guix-cookbook.de.texi:802: @menu reference to nonexistent node `Channels'
guix-cookbook.de.texi:1510: @menu reference to nonexistent node `Recursive 
importers'
guix-cookbook.de.texi:1511: @menu reference to nonexistent node `Automatic 
update'
guix-cookbook.de.texi:3358: @menu reference to nonexistent node `A Database 
Container'
guix-cookbook.de.texi:3657: @menu reference to nonexistent node `Basic setup 
with manifests'
guix-cookbook.de.texi:3658: @menu reference to nonexistent node `Required 
packages'
guix-cookbook.de.texi:3659: @menu reference to nonexistent node `Default 
profile'
guix-cookbook.de.texi:3660: @menu reference to nonexistent node `The benefits 
of manifests'
guix-cookbook.de.texi:116: @detailmenu reference to nonexistent node `A ``Hello 
World'' package'
guix-cookbook.de.texi:117: @detailmenu reference to nonexistent node `Setup'
guix-cookbook.de.texi:118: @detailmenu reference to nonexistent node `Extended 
example'
guix-cookbook.de.texi:119: @detailmenu reference to nonexistent node `Other 
build systems'
guix-cookbook.de.texi:120: @detailmenu reference to nonexistent node 
`Programmable and automated package definition'
guix-cookbook.de.texi:121: @detailmenu reference to nonexistent node `Getting 
help'
guix-cookbook.de.texi:122: @detailmenu reference to nonexistent node 
`Conclusion'
guix-cookbook.de.texi:129: @detailmenu reference to nonexistent node `Local 
file'
guix-cookbook.de.texi:130: @detailmenu reference to nonexistent node `Channels'
guix-cookbook.de.texi:137: @detailmenu reference to nonexistent node `Recursive 
importers'
guix-cookbook.de.texi:138: @detailmenu reference to nonexistent node `Automatic 
update'
guix-cookbook.de.texi:193: @detailmenu reference to nonexistent node `A 
Database Container'
guix-cookbook.de.texi:207: @detailmenu reference to nonexistent node `Basic 
setup with manifests'
guix-cookbook.de.texi:208: @detailmenu reference to nonexistent node `Required 
packages'
guix-cookbook.de.texi:209: @detailmenu reference to nonexistent node `Default 
profile'
guix-cookbook.de.texi:210: @detailmenu reference to nonexistent node `The 
benefits of manifests'
Backtrace:
   3 (primitive-load "/gnu/store/jcpsgx9pswha51a014fdi5rlpsk?")
In ice-9/eval.scm:
619:8  2 (_ #f)
In ice-9/boot-9.scm:
   260:13  1 (for-each # ?)
In guix/build/utils.scm:
812:6  0 (invoke "/gnu/store/9d7c6c8id6dh0inpqvcgb708mmiqcj4c-t?" ?)

guix/build/utils.scm:812:6: In procedure invoke:
ERROR:
  1. :
  program: 
"/gnu/store/9d7c6c8id6dh0inpqvcgb708mmiqcj4c-texinfo-6.8/bin/makeinfo"
  arguments: ("./guix-cookbook.de.texi" "-I" 
"/gnu/store/ah2fdy1vkac5blsdm2ai654h4gwgib21-doc" "-I" "." "-o" 
"/gnu/store/zb7vmqbbwl5s9i26zdhxpks1xrcr5npz-guix-manual/guix-cookbook.de.info")
  exit-status: 1
  term-signal: #f
  stop-signal: #f
builder for `/gnu/store/6fah4ipa15w46npk919f4i5hka5jhphg-guix-manual.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/x34kb0nk9h2mdjj6hydlvsjphdakakpr-guix-20230726.19.drv': 1 
dependencies couldn't be built
error: build of 
`/gnu/store/x34kb0nk9h2mdjj6hydlvsjphdakakpr-guix-20230726.19.drv' failed
make: *** [Makefile:7009 : as-derivation] Erreur 1
--8<---cut here---end--->8---

Would someone know how to get this to work?  Manually maintaining menus
in Texinfo is a pain.

-- 
Thanks,
Maxim

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 root77  1. Jan 1970  texmf-dist -> 
/gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/texmf-dist
lrwxrwxrwx   1 root root76  1. Jan 1970  texmf-var -> 
/gnu/store/31rs3m4fzdbal1v81qg1mvl29p39cyrp-texlive-20210325/share/texmf-var
lrwxrwxrwx   1 root root72  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 root72  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#64872: guix pull: po4a: build failed

[Christopher Baines]

Artyom Poptsov  writes:

> Huh, it seems that the problem not in "po4a" itself but in
> "texlive-hyphen-complete".
>
> When I try to access
>   
> https://www.tug.org/texlive/tags/texlive-2023.0/Master/texmf-dist//doc/generic/elhyphen
> I get 404 error.

Ok, well maybe try building
/gnu/store/g9xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv
and post the log.

Since quite recently, the subversion downloads should fallback to
talking to bordeaux.guix.gnu.org, which should be able to provide a nar
for this, even if you get a 404 from www.tug.org, but it would be good
to see if that is attempted.


signature.asc
Description: PGP signature

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#64872: guix pull: po4a: build failed

[Artyom Poptsov]

Huh, it seems that the problem not in "po4a" itself but in
"texlive-hyphen-complete".

When I try to access
  
https://www.tug.org/texlive/tags/texlive-2023.0/Master/texmf-dist//doc/generic/elhyphen
I get 404 error.

- avp

On Wed, 26 Jul 2023 at 18:08, Christopher Baines  wrote:
>
>
> Artyom Poptsov  writes:
>
> > Hello, Guixers.
> >
> > Recently I started to see this error on "guix pull" -- please see
> > the logs attached.
>
> Are you able to share the end of the build log for
> /gnu/store/qcjl6wfiy662s9knwvkb24vkrviw3jdn-po4a-0.68.drv ?
>
> It has been built at least, so you should be able to substitute it as
> well. You can try from bordeaux.guix.gnu.org if you can't use
> ci.guix.gnu.org.



-- 
Artyom V. Poptsov 
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F


xfx06xs21jnrsg7h42m5ggfg2zfdfg-texlive-hyphen-complete-66594-checkout.drv.gz
Description: application/gzip

bug#63082: mpd defaul configuration does not work ('No database' error)

[Maxim Cournoyer]

Hi,

Bruno Victal  writes:

> Hi Maxim,
>
> On 2023-07-25 21:48, Maxim Cournoyer wrote:
>> Hi Bruno,
>> 
>> Bruno Victal  writes:
>> 
>>> Hi Maxim,
>>>
>>> On 2023-05-05 19:28, Maxim Cournoyer wrote:
 * gnu/services/audio.scm (mpd-shepherd-service): Register a new update 
 action.
 * doc/guix.texi (Audio Services): Document it.
 ---
  doc/guix.texi  | 10 ++
  gnu/services/audio.scm | 11 +++
  2 files changed, 21 insertions(+)

>>>
>>> I've been looking at this part for the past few weeks in attempt to
>>> make it more robust and after countless hours, I'd advise against this
>>> (in its current form), reason being that this only works if your
>>> configuration happens to match the default values used by mpc.
>>>
>>> My attempts at getting the values from the configuration into
>>> something that mpc understands have been unsuccessful. Not only the
>>> decision “logic” of what values to pass is non-trivial, parsing the
>>> endpoints field has been so far a complete nightmare. (with interesting
>>> gems like IPv6 address formats that the daemon is happy to use yet
>>> mpc will reject)
>>>
>>> Having the proper hostname (and port) intelligently deduced from
>>> the endpoints field is a big minefield that is likely to end in
>>> unmaintainable spaghetti.
>>>
>>> Short of introducing additional fields like “internal-mpc-host” and
>>> “internal-mpc-port”, you could modify this to relay the
>>> 'environment-variables' field for mpc as well. (since it can make use
>>> of the MPD_HOST and MPD_PORT varibles if present)
>> 
>> Apologies if it's been a couple weeks, but was the above comment really
>> meant for patch 02/16 of this series ("services: mpd: Add an 'update'
>> action to trigger a database update.") ?  I don't see how they relate.
>
> Yes, since this action uses 'mpc' to issue the 'update' command and
> the way it works is that mpc is using a 'default' value to connect to MPD. 
>
> The 'default' works until you change the 'endpoints' to something that
> _doesn't_ match the defaults that 'mpc' uses (e.g. [fe80::1234%eno1],
> /var/run/mpd/not-your-expected-name.socket, 2001:db8::1, etc.)
>
> Since the 'endpoints' field is equivalent to MPDs 'bind_to_address'
> directive [1], you have to take into account the flexible formats it allows
> and the 'port' field as well. This makes it somewhat non-trivial to
> inspect the 'endpoints' and 'port' fields to select an address for the
> shepherd 'update' action to use. You also need to take into account that
> you have to pass the address and port separately (if needed) for 'mpc'.
>
> One additional avenue (from the ones originally listed) we could explore
> is to make the endpoints field no longer a maybe-type. We set a default
> value (that is aligned with upstream, like localhost:6600) and also set
> an “internal” unix socket to be used primarily by shepherd.
>
> [1]: 

Thanks for the analysis.  I've reverted the commit, as I don't intend to
work toward fixing it.

-- 
Thanks,
Maxim

bug#64827: Texlive has become slow

[Nicolas Goaziou]

Hello,

Andreas Enge  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 
> 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 

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

[Nicolas Goaziou]

Hello,

Andreas Enge  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#63082: [PATCH v3 10/16] services: mpd: Let Shepherd effect the user/group change.

[Maxim Cournoyer]

Hello,

Bruno Victal  writes:

> On 2023-05-05 19:29, Maxim Cournoyer wrote:
>> Relates to .
>> 
>> Quoting a MPD developer, regarding MPD's feature to switch user itself:
>> "that's legacy for the dark ages when proper service managers did not exist"
>> :-).
>> 
>> * gnu/services/audio.scm (mpd-serialize-user-account)
>> (mpd-serialize-user-group): Delete procedures.
>> * gnu/services/audio.scm (mpd-configuration) [user]: Do not serialize.
>> [group]: Likewise.
>> (mpd-shepherd-service): Provide the #:user, #:group and 
>> #:supplementary-groups
>> arguments.
>> (mympd-shepherd-service): Likewise, and remove the '--user' argument.
>> * doc/guix.texi (Audio Services): Update doc.
>> (mympd-configuration) [port]: Change default value to 8080.
>> [ssl-port]: Change default value to 443.
>> * gnu/tests/audio.scm (run-mympd-test): Adjust accordingly.
>> ---
>>  doc/guix.texi  | 12 +-
>>  gnu/services/audio.scm | 52 +-
>>  gnu/tests/audio.scm|  4 ++--
>>  3 files changed, 39 insertions(+), 29 deletions(-)
>
> This contains a submarine change that isn't easily spotted from the
> commit message, that mympd is getting its default port changed and that
> it can no longer bind to privileged ports, since although mympd can
> start as root in order to bind to possibly privileged ports, it will
> explicitly refuse to continue running as root afterwards.
>
> I think we can have shepherd effect for mympd, but only if (and after)
> shepherd gets support for POSIX capabilities (CAP_NET_BIND_SERVICE) or
> a suitable way to specify that “yes, the program invoked by the service
> should have CAP_NET_BIND_SERVICE” is provided.

As mentioned before, I've let go of this commit for now (though that
means supplementary-groups on a user-account are not honored anymore)
and other commits touching the current group mechanism until we've
implemented support for POSIX capabilities as mentioned in
https://issues.guix.gnu.org/64862.

We can thus close this issue for now, keeping on mind that some bits
could be salvaged at a later time when 64862 is done.

-- 
Thanks,
Maxim

bug#64872: guix pull: po4a: build failed

[Christopher Baines]

Artyom Poptsov  writes:

> Hello, Guixers.
>
> Recently I started to see this error on "guix pull" -- please see
> the logs attached.

Are you able to share the end of the build log for
/gnu/store/qcjl6wfiy662s9knwvkb24vkrviw3jdn-po4a-0.68.drv ?

It has been built at least, so you should be able to substitute it as
well. You can try from bordeaux.guix.gnu.org if you can't use
ci.guix.gnu.org.


signature.asc
Description: PGP signature

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  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#63082: mpd defaul configuration does not work ('No database' error)

[Bruno Victal]

Hi Maxim,

On 2023-07-25 21:48, Maxim Cournoyer wrote:
> Hi Bruno,
> 
> Bruno Victal  writes:
> 
>> Hi Maxim,
>>
>> On 2023-05-05 19:28, Maxim Cournoyer wrote:
>>> * gnu/services/audio.scm (mpd-shepherd-service): Register a new update 
>>> action.
>>> * doc/guix.texi (Audio Services): Document it.
>>> ---
>>>  doc/guix.texi  | 10 ++
>>>  gnu/services/audio.scm | 11 +++
>>>  2 files changed, 21 insertions(+)
>>>
>>
>> I've been looking at this part for the past few weeks in attempt to
>> make it more robust and after countless hours, I'd advise against this
>> (in its current form), reason being that this only works if your
>> configuration happens to match the default values used by mpc.
>>
>> My attempts at getting the values from the configuration into
>> something that mpc understands have been unsuccessful. Not only the
>> decision “logic” of what values to pass is non-trivial, parsing the
>> endpoints field has been so far a complete nightmare. (with interesting
>> gems like IPv6 address formats that the daemon is happy to use yet
>> mpc will reject)
>>
>> Having the proper hostname (and port) intelligently deduced from
>> the endpoints field is a big minefield that is likely to end in
>> unmaintainable spaghetti.
>>
>> Short of introducing additional fields like “internal-mpc-host” and
>> “internal-mpc-port”, you could modify this to relay the
>> 'environment-variables' field for mpc as well. (since it can make use
>> of the MPD_HOST and MPD_PORT varibles if present)
> 
> Apologies if it's been a couple weeks, but was the above comment really
> meant for patch 02/16 of this series ("services: mpd: Add an 'update'
> action to trigger a database update.") ?  I don't see how they relate.

Yes, since this action uses 'mpc' to issue the 'update' command and
the way it works is that mpc is using a 'default' value to connect to MPD. 

The 'default' works until you change the 'endpoints' to something that
_doesn't_ match the defaults that 'mpc' uses (e.g. [fe80::1234%eno1],
/var/run/mpd/not-your-expected-name.socket, 2001:db8::1, etc.)

Since the 'endpoints' field is equivalent to MPDs 'bind_to_address'
directive [1], you have to take into account the flexible formats it allows
and the 'port' field as well. This makes it somewhat non-trivial to
inspect the 'endpoints' and 'port' fields to select an address for the
shepherd 'update' action to use. You also need to take into account that
you have to pass the address and port separately (if needed) for 'mpc'.

One additional avenue (from the ones originally listed) we could explore
is to make the endpoints field no longer a maybe-type. We set a default
value (that is aligned with upstream, like localhost:6600) and also set
an “internal” unix socket to be used primarily by shepherd.

[1]: 


-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.

bug#64803: Close: bug#64803: python-shiboken-6 fails

[Hilton Chain via Bug reports for GNU Guix]

Fixed in e05dcecd0df49a397aba49585a626cae16a6306c.

bug#64783: Build of texlive-font-maps fails

[Nicolas Goaziou]

Hello,

Josselin Poiret via Bug reports for GNU Guix  writes:

> The `texlive` package contains the whole monolothic texlive
> distribution, and is different from the newer modular one.  You probably
> want `texlive-bin` instead.  `texlive-scheme-basic` is a meta-package
> propagating a basic set of tex packages that you might need.

Indeed, as suggested in the manual, one should install at least one
"scheme", or at least, a "collection", to use modular TeX Live.

Consequently, installing `texlive-bin' is not sufficient, and should be
avoided unless you want a very minimal system, with a lot of sweat. For
example, `texlive-bin' does not provide any ".fmt" file.

Regards,
-- 
Nicolas Goaziou

bug#64852: Texlive errors and weird behavior

[Nicolas Goaziou]

Hello,

Wojtek Kosior via Bug reports for GNU Guix  writes:

> I'm having some problems using texlive after the recent tex-team merge.
> On my system (with texlive installed in a profile, together with many
> other packages) the tools complain about 'lualatex.fmt', 'pdflatex.fmt',
> etc. missing. Before the merge I have been using texlive without ever
> experiencing such problems.

These files are provided by the `texlive-latex-bin' package. Your
profile should probably contain `texlive-collection-latex' to get it
along with some very important LaTeX packages.

Would you want to share the TeX Live packages you listed in your
profile?

> I tried to reduce it to a small, reproducible example using
> `guix shell -C`. Surprisingly, now I managed to compile this document
> inside a container. But also surprisingly, it took very long to do so.
> Also, lualatex automatically created a directory named '{' in the
> current working directory.

These two issues were reported in another bug report. Unfortunately, at
the moment, I do not know where they do come from.

Concerning the second issue, the "{" directory, I do know that
monolithic TeX Live modifies "texmfcnf.lua" (see `texlive-texmf'
package) whereas modular TeX Live (in `texlive-luatex' package) doesn't.

I think this "texmfcnf.lua" file should be modified in a proper way to
fix this issue, but I don't know how.

Regards,
-- 
Nicolas Goaziou

bug#64872: guix pull: po4a: build failed

[Artyom Poptsov]

Hello, Guixers.

Recently I started to see this error on "guix pull" -- please see
the logs attached.

- avp

-- 
Artyom V. Poptsov 
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F
$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to e05dcec (8 new commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   e05dcec
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
building 
/gnu/store/78ffvfhlaqj4kng3znx2x2s5fp942ya2-compute-guix-derivation.drv...
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 'http://ci.guix.ygg.trop.in'... 100.0%
substitute: updating substitutes from 

bug#64783: Build of texlive-font-maps fails

[Josselin Poiret via Bug reports for GNU Guix]

Hi Isaac,

Isaac van Bakel  writes:

> I had the same issue, with a pretty minimal manifest:
>
>
> (use-modules (gnu packages))
> (use-package-modules tex)
>
> (packages->manifest (list texlive texlive-amsmath texlive-txfonts))
>
>
> Based on the suggestion that the missing files are propagated by 
> texlive-bin, I added that to the manifest and found that the build 
> succeeded. So is the issue that texlive is not propagating 
> texlive-scripts correctly?

The `texlive` package contains the whole monolothic texlive
distribution, and is different from the newer modular one.  You probably
want `texlive-bin` instead.  `texlive-scheme-basic` is a meta-package
propagating a basic set of tex packages that you might need.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64858: ~guix shell -C -f guix.scm …~ should not always need ~--rebuild-cache~ option to build the expected environment.

[Pierre-Henry Fröhring]

Hello Guix!

As discussed the [[
https://logs.guix.gnu.org/guix/2023-07-21.log#142414][other day]], I'm
providing a more detailed description
(see below) of the unexpected behaviour and an archive containing
enough material to reproduce the bug.

* Experiment
** pkgex-1 -> /gnu/store/0yk3xz85…

The Guix package ~pkgex-1~ is built then its path (~/gnu/store/0yk3xz85…~)
is
shown from within a container (~guix shell -C -f guix.scm ripgrep fd
coreutils
emacs~).

#+begin_example
$ make build # equivalent to: guix build -f guix.scm
…
$ guix shell -C -f guix.scm ripgrep fd coreutils emacs
[env]$ ls -al $EMACSLOADPATH/
total 32
dr-xr-xr-x 2 65534 overflow 4096 Jan  1  1970 .
dr-xr-xr-x 3 65534 overflow 4096 Jan  1  1970 ..
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 guix-emacs.el ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/guix-emacs.el
lrwxrwxrwx 1 65534 overflow   91 Jan  1  1970 guix-emacs.elc ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/guix-emacs.elc
lrwxrwxrwx 1 65534 overflow   81 Jan  1  1970 pkgex-1 ->
/gnu/store/0yk3xz85gamig58iska1py6rvn9924ss-pkgex-1/share/emacs/site-lisp/pkgex-1
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 site-start.el ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/site-start.el
lrwxrwxrwx 1 65534 overflow   91 Jan  1  1970 site-start.elc ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/site-start.elc
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 subdirs.el ->
/gnu/store/75z28mg9fd0v3mjcg3jmrah9ihnziqcb-emacs-subdirs/share/emacs/site-lisp/subdirs.el
#+end_example

** /gnu/store/8k18bghzcijbps8kix3wqp34x4smfc5l-pkgex-1

This very file (~pkgex.el.org~) is updated with this content then the
package is
built again.

#+begin_example
$ make build # equivalent to: guix build -f guix.scm
…
/gnu/store/8k18bghzcijbps8kix3wqp34x4smfc5l-pkgex-1
#+end_example

** pkgex-1 -> /gnu/store/0yk3xz85…

Unexpectedly, the package linked from within the container using the same
command as above is not updated, we observe:

- ~pkgex-1 -> /gnu/store/0yk3xz85…~

instead of:

- ~pkgex-1 -> /gnu/store/8k18bghz…~

#+begin_example
$ guix shell -C -f guix.scm ripgrep fd coreutils emacs
[env]$ ls -al $EMACSLOADPATH/
total 32
dr-xr-xr-x 2 65534 overflow 4096 Jan  1  1970 .
dr-xr-xr-x 3 65534 overflow 4096 Jan  1  1970 ..
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 guix-emacs.el ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/guix-emacs.el
lrwxrwxrwx 1 65534 overflow   91 Jan  1  1970 guix-emacs.elc ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/guix-emacs.elc
lrwxrwxrwx 1 65534 overflow   81 Jan  1  1970 pkgex-1 ->
/gnu/store/0yk3xz85gamig58iska1py6rvn9924ss-pkgex-1/share/emacs/site-lisp/pkgex-1
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 site-start.el ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/site-start.el
lrwxrwxrwx 1 65534 overflow   91 Jan  1  1970 site-start.elc ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/site-start.elc
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 subdirs.el ->
/gnu/store/75z28mg9fd0v3mjcg3jmrah9ihnziqcb-emacs-subdirs/share/emacs/site-lisp/subdirs.el
#+end_example

** pkgex-1 -> /gnu/store/8k18bghz…

Nevertheless, if we build a new environment (because we added the
~tree~ package), then, the newly built package
(~/gnu/store/8k18bghz…~) is taken into account.

#+begin_example
$ guix shell -C -f guix.scm ripgrep fd coreutils emacs tree
…
[env]$ ls -al $EMACSLOADPATH/
total 32
dr-xr-xr-x 2 65534 overflow 4096 Jan  1  1970 .
dr-xr-xr-x 3 65534 overflow 4096 Jan  1  1970 ..
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 guix-emacs.el ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/guix-emacs.el
lrwxrwxrwx 1 65534 overflow   91 Jan  1  1970 guix-emacs.elc ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/guix-emacs.elc
lrwxrwxrwx 1 65534 overflow   81 Jan  1  1970 pkgex-1 ->
/gnu/store/8k18bghzcijbps8kix3wqp34x4smfc5l-pkgex-1/share/emacs/site-lisp/pkgex-1
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 site-start.el ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/site-start.el
lrwxrwxrwx 1 65534 overflow   91 Jan  1  1970 site-start.elc ->
/gnu/store/0ibk105zcyg27i9gifbf3lhgm6n78z66-emacs-28.2/share/emacs/site-lisp/site-start.elc
lrwxrwxrwx 1 65534 overflow   90 Jan  1  1970 subdirs.el ->
/gnu/store/n7yizf59v4gvjlr66swh3q3kkz3v1vag-emacs-subdirs/share/emacs/site-lisp/subdirs.el
#+end_example


1-bug.tar.gz
Description: application/gzip