bug#73831: dvilualatex binary nowhere to be found

2024-10-17 Thread Nicolas Goaziou via Bug reports for GNU Guix 
Hello,

Justin Veilleux  writes:

> Hello. I created and installed a dummy package that adds a symlink to
> lualatex named dvilualatex in /bin. My use case for dvilualatex is
> mostly to render latex previews in org mode, and when I run the command,
> I get the following log:

Org contains no reference whatsoever to "dvilualatex". How did you
manage to make Org call it?

> Could I fix this by setting some environment variable? the file seems to
> be present in texlive-latex-bin

What TeX Live packages have you installed?
What is the return value of `kpsewhich -engine=/ dvilualatex.fmt'?

Regards,
-- 
Nicolas Goaziou

bug#73601: failed to compute the derivation for Guix

2024-10-17 Thread Fabrice Tudoret 

Hi Simon,

I'm still struggling with the issue, but I found a kind of work around.

When I create the user home dir manually, the "guix pull" work's fine. 
So the trouble could come from a disorder with the automatic home dir 
creation.


I wish it's the right track. I keep digging.

Regards,

Fabrice TUDORET

Laboratoire du Traitement du Signal et de l'Image
INSERM U-1099. Université de Rennes 1
Campus de Beaulieu. Bât 22. 35042.  Rennes.  France

Le 14/10/2024 à 14:03, Fabrice Tudoret a écrit :


Hi Simon,

Thanks again for your involvement.

I did my best to fullfill the tests you suggest. I put the output in 
your text.


Essentially the output are the same for the root and the users, so the 
situation does not seem clearer to me, but I’m sure it will be 
different for you.


Regards

Fabrice T
Le 11/10/2024 à 18:30, Simon Tournier a écrit :

Hi Fabrice,

On Fri, 11 Oct 2024 at 15:13, Fabrice Tudoret 
wrote:


GUIX seem's to work fine with the root account and the local users but
not with ldap users.

Ah, that doesn’t ring a bell but maybe it’s related.  I don’t know.



1-

Just to be sure and since you have reinstalled, what is your Guix
revision?

[root@cluster24 ~]# guix --version
guix (GNU Guix) 7888351b9edd7b0199a973c75bc1c35897d9d7ef
Copyright (C) 2024 the Guix authors
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.




On a side note, since it seems fine for the root account and here you
run it as root, I guess all is fine. :-)  Although I don’t have the
same… 🤔


[root@cluster24 ~]# cat 
/gnu/store/jc3vgcsplqsim3na80b0n2iilna5j6gx-Python-3.5.9.tar.xz.drv  | sed 
's/)/)\n/g'
Derive([("out","/gnu/store/cv4h89n30myf3nhjqnnahlbij2gaw21z-Python-3.5.9.tar.xz","","")
],[("/gnu/store/21c7pjahkh20mmzq2ivki57zwwvp6nwn-bootstrap-binaries-0.drv",["out"])
,("/gnu/store/5gf7f8awndhnf2gn2mzbfbqr3ix9aj80-module-import-compiled.drv",["out"])
,("/gnu/store/g08l2msvnivyi6x5nw52ak8n17sw9lzr-guile-bootstrap-2.0.drv",["out"])
,("/gnu/store/lb5b7svdmfj1ijnzrripsjcv0bhqzpwb-Python-3.5.9.tar.xz.drv",["out"])
],["/gnu/store/1s8jdafkyhz0p81l0j37yih9gbrb5gix-module-import","/gnu/store/h58cvdcdak4d87lw0fkvmkhan95ssljx-Python-3.5.9.tar.xz-builder"],"x86_64-linux","/gnu/store/lgi9x15a0w35mcpd7g1kb9274r6wy4pv-guile-bootstrap-2.0/bin/guile",["--no-auto-compile","-L","/gnu/store/1s8jdafkyhz0p81l0j37yih9gbrb5gix-module-import","-C","/gnu/store/gz5rcilhcsc5amgxcgyxvn0s5px8sg80-module-import-compiled","/gnu/store/h58cvdcdak4d87lw0fkvmkhan95ssljx-Python-3.5.9.tar.xz-builder"],[("guix
 properties","((type . origin)
  (patches . 0)
)
")
,("out","/gnu/store/cv4h89n30myf3nhjqnnahlbij2gaw21z-Python-3.5.9.tar.xz")
])


2 -The script builder
/gnu/store/ykqckrxcmifvxz0nb58lv2drgd14l377-Python-3.5.9.tar.xz-builder
is well present in /gnu/store.

Ouf. :-)


Well, since it works as expected when run as root (#) and it fails when
run as a regular ($), I propose to diff various files in order to spot
what could be wrong.

Some details about some internals – well my understanding and I’m
perhaps missing important points –, then maybe they will explain the
logic behind the exploration. :-)

Roughly speaking, the items in the store look like:

 /gnu/store/-foobar-1.2.3

where ’foobar-1.2.3’ is a “label” corresponding to the package and
’xxx…’ is some hash.  This hash is the core of the content-addressed;
the one that allow the substitution, i.e., download the artefacts.

Basically, this hash is computed by hashing the inputs and the script
builders.  Therefore somehow it builds a chain and the roots are named
fixed-outputs.  Fixed-outputs are items for which we known beforehand
the resulting hash.  Else we cannot know the hash beforehand because
it’s hard to know beforehand the checksum of the artefact since the
artefact is the result of the build process (compilation, etc.).

In other words, the expectation is: the same inputs and the same builder
script returns the same store item.  And the derivation captures that.
Well, for sure the content of the store item on two machines is the same
only if the process is fully deterministic; another story. ;-)

All that to say: if we scrutinize the derivations and the builder
scripts, then we will spot what introduces a difference.

Aside, please note that two different derivations might produce the same
store item, see for example [1].

Let’s go! :-)


a) Both root and regular must use the exact same Guix revision.

   # As root
   # readlink -f (type -P guix)
   # guix describe


[root@cluster24 ~]# readlink -f guix

/root/guix

[root@cluster24 ~]# type -P guix

/root/.config/guix/current/bin/guix

[root@cluster24 ~]# guix describe

Generation 3 Oct 14 2024 08:46:12 (current)

guix 7888351

repository URL:https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 7888351b9

bug#73852: $GUIX_LOCPATH unset on Guix system installation, warnings to install locales and set it.

2024-10-17 Thread Oscar Chevalier 
While locales are installed for the current system, guix commands cause
this error to be produced, prompting to install glibc-locales and set the
variable.

My understanding is that this should only need to be done for guix
installations on other systems.