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:
real0m22,757s
user0m7,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:
real0m1,426s
user0m1,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 
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 
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#64852: Texlive errors and weird behavior

[Wojtek Kosior via Bug reports for GNU Guix]

Hello,

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.

#+BEGIN_EXAMPLE
urz@GuixPad /tmp/example$ guix describe
Generation 13   Jul 25 2023 11:46:08(current)
  guix 76e041f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 76e041f9eef85bb039c5251d3350c62ee2066883
urz@GuixPad /tmp/example$ ls
minimal.tex
urz@GuixPad /tmp/example$ cat minimal.tex 
\documentclass{article}
\title{somedoc}
\begin{document}

aaa

\end{document}
urz@GuixPad /tmp/example$ lualatex minimal.tex 
This is LuaHBTeX, Version 1.16.0 (TeX Live 2023/GNU Guix) 
 restricted system commands enabled.

kpathsea: Running mktexfmt lualatex.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/urz/.texlive2023/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under /home/urz/.texlive2023/texmf-var/web2c
mktexfmt [INFO]: Did not find entry for byfmt=lualatex skipped
mktexfmt [INFO]: total formats: 0
mktexfmt [INFO]: exiting with status 0
I can't find the format file `lualatex.fmt'!
#+END_EXAMPLE

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.

#+BEGIN_EXAMPLE
urz@GuixPad /tmp/example$ guix describe
Generation 13   Jul 25 2023 11:46:08(current)
  guix 76e041f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 76e041f9eef85bb039c5251d3350c62ee2066883
urz@GuixPad /tmp/example$ ls /tmp/example/
minimal.tex
urz@GuixPad /tmp/example$ cat minimal.tex 
\documentclass{article}
\title{somedoc}
\begin{document}

aaa

\end{document}
urz@GuixPad /tmp/example$ guix shell texlive coreutils which -C
urz@GuixPad /tmp/example [env]$ lualatex minimal.tex 
This is LuaHBTeX, Version 1.16.0 (TeX Live 2023/GNU Guix) 
 restricted system commands enabled.
(./minimal.tex
LaTeX2e <2022-11-01> patch level 1
 L3 programming layer <2023-02-22> 
(/gnu/store/vld5rj0438d7vfihvbhk7p56jigm71xk-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
(/gnu/store/vld5rj0438d7vfihvbhk7p56jigm71xk-profile/share/texmf-dist/tex/latex/base/size10.clo
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.)) 
(/gnu/store/vld5rj0438d7vfihvbhk7p56jigm71xk-profile/share/texmf-dist/tex/latex/l3backend/l3backend-luatex.def)
No file minimal.aux.
(/gnu/store/vld5rj0438d7vfihvbhk7p56jigm71xk-profile/share/texmf-dist/tex/latex/base/ts1cmr.fd)
 
[1{/gnu/store/vld5rj0438d7vfihvbhk7p56jigm71xk-profile/share/texmf-dist/fonts/map/pdftex/updmap/pdftex.map}]
 (./minimal.aux))
 406 words of node memory still in use:
   3 hlist, 1 vlist, 1 rule, 2 glue, 3 kern, 1 glyph, 4 attribute, 48 
glue_spec, 4 attribute_list, 1 write nodes
   avail lists: 2:23,3:4,4:2,5:22,6:2,7:34,9:18

Output written on minimal.pdf (1 page, 2610 bytes).
Transcript written on minimal.log.
urz@GuixPad /tmp/example [env]$ ls -a
 .   ..   minimal.aux   minimal.log   minimal.pdf   minimal.tex  '{'
urz@GuixPad /tmp/example [env]$ ls 
\{/gnu/store/vld5rj0438d7vfihvbhk7p56jigm71xk-profile/share/  
texmf-dist}  texmf-var
#+END_EXAMPLE

Best,
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)


pgplRPENXIJOk.pgp
Description: OpenPGP digital signature

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

[Isaac van Bakel]

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?


Best,

Isaac van Bakel

bug#64803: python-shiboken-6 fails

[Hilton Chain via Bug reports for GNU Guix]

Hello Formbi,

On Sun, 23 Jul 2023 19:26:11 +0800,
Formbi via Bug reports for GNU Guix wrote:
> The line in question (and the neighboring ones for context) looks
> like this:
>
> import base64
> import importlib
> import importlib.machinery as imachi
> import io
> import sys
> import traceback
> import zipfile

python-shiboken-6 inherits the definition of python-shiboken-2, which
has the following phase:
--8<---cut here---start->8---
(add-before 'configure 'workaround-importlib-error
  (lambda _
;; The following hack works around the error
;;   "module 'importlib' has no attribute 'machinery'"
;; when building python-pyside-2, which depends on
;; this package.
(substitute* "libshiboken/embed/signature_bootstrap.py"
  (("import importlib" all)
   (string-append
all
"\nimport importlib.machinery as imachi"))
  (("importlib.machinery.ModuleSpec")
   "imachi.ModuleSpec"
--8<---cut here---end--->8---

So python-shiboken-6 inherits the workaround as well, and that causes
the issue.


> How should I go about fixing this?

Delete the phase in python-shiboken-6 or rewrite it if necessarily. :)

There should be no need to keep it, as I can build python-pyside-6
with the following change:
--8<---cut here---start->8---
diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index a79338f84e..e8654eee44 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -4005,6 +4005,7 @@ (define-public python-shiboken-6
  (substitute-keyword-arguments (package-arguments python-shiboken-2)
((#:phases p)
 #~(modify-phases #$p
+(delete 'workaround-importlib-error)
 (replace 'use-shiboken-dir-only
   (lambda _ (chdir "sources/shiboken6")
((#:configure-flags flags)
--8<---cut here---end--->8---

I have sent the change to .

Thanks

bug#64856: guix shell cache doesn't consider grafts

[Maxim Cournoyer]

Hello,

While investigating https://issues.guix.gnu.org/64836, I discovered that
the cache of 'guix shell' doesn't take into account grafts for
subsequent invocations.

Consider, using Guix at commit 21b718f4d6c3ded8ef50d12f6e9ae6474f74620f:

--8<---cut here---start->8---
$ guix build gtk+
/gnu/store/6vqx7nip7r95h2nhvhb9vxzjpri581b9-gtk+-3.24.37

$ guix build --no-grafts gtk+
/gnu/store/2n2kprz35a19ibs5kbjsb3k4cdl69q2w-gtk+-3.24.37

$ guix shell gtk+ -- sh -c 'realpath $GUIX_ENVIRONMENT/lib/libgtk-3.so'
/gnu/store/6vqx7nip7r95h2nhvhb9vxzjpri581b9-gtk+-3.24.37/lib/libgtk-3.so.0.2405.32

$ guix shell --no-grafts gtk+ -- sh -c 'realpath 
$GUIX_ENVIRONMENT/lib/libgtk-3.so'
/gnu/store/6vqx7nip7r95h2nhvhb9vxzjpri581b9-gtk+-3.24.37/lib/libgtk-3.so.0.2405.32
--8<---cut here---end--->8---

The 'guix shell --no-grafts' invocation simply reused the same cache as
the previous command, so grafts are in use, which is non-intuitive.  The
reverse would be true as well:

--8<---cut here---start->8---
$ guix shell --rebuild-cache --no-grafts gtk+ -- sh -c 'realpath 
$GUIX_ENVIRONMENT/lib/libgtk-3.so'
/gnu/store/2n2kprz35a19ibs5kbjsb3k4cdl69q2w-gtk+-3.24.37/lib/libgtk-3.so.0.2405.32

$ guix shell gtk+ -- sh -c 'realpath $GUIX_ENVIRONMENT/lib/libgtk-3.so'
/gnu/store/2n2kprz35a19ibs5kbjsb3k4cdl69q2w-gtk+-3.24.37/lib/libgtk-3.so.0.2405.32
--8<---cut here---end--->8---

The ungrafted cache got reused by the invocation that should have used
grafted inputs.

-- 
Thanks,
Maxim

bug#64836: pygobject GTK modules lookup fails following CUPS graft

[Maxim Cournoyer]

Hello,

I initially thought the issue may be with the GTK .typelib files not
getting grafted correctly, but I've verified them and they appear
correct (there's a single file name for the shared library, and it
appears in the .typelib in full, gets grafted correctly).

So I'm now leaning toward a different explanation: wxWidgets or wxPython
retaining a reference to the ungrafted GTK library, loading it first,
then pygobject attempts to load the grafted GTK, and both conflict,
producing error messages such as "Warning: cannot register existing type
'GtkWidget'".

I'll now attempt to verify this potential cause.

-- 
Thanks,
Maxim

bug#64836: pygobject GTK modules lookup fails following CUPS graft

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hello,
>
> I initially thought the issue may be with the GTK .typelib files not
> getting grafted correctly, but I've verified them and they appear
> correct (there's a single file name for the shared library, and it
> appears in the .typelib in full, gets grafted correctly).
>
> So I'm now leaning toward a different explanation: wxWidgets or wxPython
> retaining a reference to the ungrafted GTK library, loading it first,
> then pygobject attempts to load the grafted GTK, and both conflict,
> producing error messages such as "Warning: cannot register existing type
> 'GtkWidget'".
>
> I'll now attempt to verify this potential cause.

I think I might have found something fishy; python-wxpython appears to
keep references to unexpected wxwidgets outputs, unless I am
misunderstanding how grafts appear.

Consider, for guix 21b718f:

--8<---cut here---start->8---
$ guix build wxwidgets
/gnu/store/dkj98zg7d7ijxiyymjxr6l4z2qb71cq4-wxwidgets-3.2.2.1-debug
/gnu/store/40a6chmcvn99dbz1vy16fy88bzfb6bj3-wxwidgets-3.2.2.1

$ guix build --no-grafts wxwidgets
/gnu/store/08mx5x1sblzb39ng9bj5ly2pibxzyx4s-wxwidgets-3.2.2.1-debug
/gnu/store/cm3pyzm7h8h3s4rxdcrfd1qhsby7g911-wxwidgets-3.2.2.1
--8<---cut here---end--->8---

The grafted version of wxwidgets is
'/gnu/store/cm3pyzm7h8h3s4rxdcrfd1qhsby7g911-wxwidgets-3.2.2.1', which
is the one I'd expect the grafted python-wxpython to refer to, but:

--8<---cut here---start->8---
$ guix build python-wxpython
/gnu/store/2fbdcwsif1ihb5ig3smcp4g79dh7wxwy-python-wxpython-4.2.0-debug
/gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0

$ guix gc -R /gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0 
| grep wxwidgets
/gnu/store/nj48sl6wdqh4m4yp8g8r04bx0mxmqfv3-wxwidgets-3.2.2.1
--8<---cut here---end--->8---

i.e. it refers to a different wxwidgets, which is not the above grafted
nor the ungrafted version (!?).

A grep such as

--8<---cut here---start->8---
grep --include='*.so' -rn --text wxwidgets-3.2 \
  /gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0
--8<---cut here---end--->8---

Indeed reveals that the only wxwidgets referred by the shared library
objects is /gnu/store/nj48sl6wdqh4m4yp8g8r04bx0mxmqfv3-wxwidgets-3.2.2.1.

What is going on here?  Or is this expected and my understanding of how
grafts work flawed?

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hi Bruno,

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.

OK.  I've dropped the change so as to not block the rest of the series.

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hi,

Bruno Victal  writes:

> On 2023-05-05 19:29, Maxim Cournoyer wrote:
>> -  (make-forkexec-constructor
>> -   (list #$(file-append package "/bin/mpd")
>> - "--no-daemon"
>> - #$config-file)
>> -   #:environment-variables '#$environment-variables)))
>> +   (start
>> +(with-imported-modules (source-module-closure
>> +'((gnu build activation)))
>
> How about adding '(gnu build activation) into %default-imported-modules
> (and %default-modules) at gnu/services/shepherd.scm?
> Services should be using the start field to perform these kinds of tasks
> anyways. (rather than extend activation-service-type which is incorrect use)

I think that's something to discuss outside the scope of this series,
which is already a bit unwieldy :-).  I think originally they were put
there because adding them to (guix build utils) would entail a world
rebuild.

>> +  #~(begin
>> +  (use-modules (gnu build activation))
>
> In general, rather than #~(begin (use-modules ...)), it's preferred to specify
> additional modules using the 'modules' field e.g.

I prefer to keep it the way it is, because the use-modules works in
tandem with the with-imported-modules.  I'd also have to wrap the stop
procedure in a second with-imported-modules if I used the 'global'
modules field, since it applies to both.

> (modules (cons '(gnu build activation)
> %default-modules))
>
>> +
>> +  (let ((user (getpw #$username)))
>> +
>> +(define (init-directory directory)
>> +  (unless (file-exists? directory)
>> +(mkdir-p/perms directory user #o755)))
>> +
>> +(for-each
>> + init-directory
>> + '#$(map dirname
>> + ;; XXX: Delete the potential "syslog"
>> + ;; log-file value, which is not a directory.
>> + (delete "syslog"
>> + (filter-map maybe-value
>> + (list db-file
>> +   log-file
>> +   state-file
>> +   sticker-file))
>
> Perhaps treat “syslog” as a symbol instead?
> Strings seem more adequate when the value is a path, with a symbol
> being a sign that the value is to be treated “specially”.
> (this aligns with how mympd handles this)

There no longer is a delete "syslog" in the code, reworked in "services:
mpd: Log to syslog by default."

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

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.

-- 
Thanks,
Maxim

bug#64862: [feature request] [shepherd] Specifying POSIX capabilities on services

[Maxim Cournoyer]

Hello,

It'd be useful to be able to specify POSIX capabilities a Shepherd
service should have, for example for an unprivileged process to be able
to bind to ports lower than 1024.

This came up while reviewing #63082, which patch 10/16 (now dropped
because of loss of functionality) suggested to let the user/group change
be effected by Shepherd instead of by MPD itself (see:
https://issues.guix.gnu.org/63082#98).

I know that NixOS has some mechanism to do that; I think it was a simple
shell script wrapper setting the capabilities, but that's all I
remember.

-- 
Thanks,
Maxim

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