bug#60892: texlive-latex-ms description is incorrect -- doesn't contain everyshi

[Maxime Devos]

Hi,

I'm trying to use 'pdfjam' from texlive-tiny.

When I run it, I get a message that 'pdfpages' wasn't installed, so I 
add texlive-latex-pdfpages to the environemnts.  Likewise, I add 
texlive-latex-eso-pic.  Then it says that everyshi isn't found, so I try 
to add that as well.


According to the second search result of "guix search everyshi", 
everyshi can be found in texlive-latex-ms:



name: texlive-latex-ms
version: 59745
outputs:
+ out: everything
systems: x86_64-linux i686-linux
dependencies: 
location: gnu/packages/tex.scm:8471:2

homepage: https://ctan.org/pkg/ms
license: LPPL 1.3c+
synopsis: Various LATEX packages by Martin Schröder  
description: A bundle of LATEX packages by Martin Schröder; the collection comprises:
+ 
+* `count1to', make use of fixed TEX counters;
+ 
+* `everysel', set commands to execute every time a font is selected;
+ 
+* `everyshi', set commands to execute whenever a page is shipped out;
+ 
+* `multitoc', typeset the table of contents in multiple columns;
+ 
+* `prelim2e', mark typeset pages as preliminary; and
+ 
+* `ragged2e', typeset ragged text and allow hyphenation.

relevance: 2


However, when I add this to the environment, I get the same 'not 
installed' error message.  Going by the contents "guix build 
texlive-latex-ms", it only contains 'count1to' and 'multitoc', so the 
other items should be removed from the list, or the other LaTeX packages 
must be made part of this Guix package.


(Also, standard capitalisation (*) is LaTeX and TeX, not LATEX or TEX.)

Then, I try the first search result: texlive-everyshi, which appears to 
work.  (I have to add 'texlive-pdflscape', 'texlive-generic-iftex' too, 
but that's another matter.).


Greetings,
Maxime.

(*) As used on https://www.latex-project.org/ and https://tug.org/index.html

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#60890: least-authority-wrapper and make-forkexec-constructor composition problem

[Maxim Cournoyer]

Hi,

I'm creating a bug to keep track of a problem that was uncovered when
attempting to migrate the jami-service-type service to use the
least-authority-wrapper [0], to avoid forgetting about it.

It was found that using something like:

--8<---cut here---start->8---
(make-forkexec-constructor
  (least-authority
(list (file-append coreutils "/bin/true"))
(mappings (delq 'user %namespaces))
  #:user  "nobody"
  #:group "nobody"))
--8<---cut here---end--->8---

Would fail with EPERM, because in order to be able to drop the user
namespace, the CAP_SYS_ADMIN capability is required, but in the above
case, make-forkexec-constructor has already changed the user to
"nobody", which lacks such capability.

The solution proposed by Ludovic in would be to [1]:

> [...] add #:user and #:group to ‘least-authority-wrapper’ and
> have it call setuid/setgid.  ‘make-forkexec-constructor’ doesn’t need to
> be modified, but the user simply won’t pass #:user and #:group to it.

[0]  https://issues.guix.gnu.org/54786#16
[1]  https://issues.guix.gnu.org/54786#17

-- 
Thanks,
Maxim

bug#60831: Are our graphs okay?

[Maxim Cournoyer]

Liliana Marie Prikler  writes:

> The ‘patch-compilation-driver’ phase pulls in libgccjit even though it has
> been deliberately removed from emacs-minimal.
>
> * gnu/packages/emacs.scm (emacs)[#:phases]: Delete ‘patch-compilation-driver’.
> ---
> Thanks Josselin for pointing this out.

I'd add the following git tag "Reported-by: Josselin Poiret "
instead, but otherwise LGTM.

-- 
Thanks,
Maxim

bug#25235: [PATCH 1/1] build-system/pyproject: Do not wrap native-inputs.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Fixes .
>>
>> * guix/build/pyproject-build-system.scm (wrap) [native-inputs]: New argument.
>> Filter out native inputs from the values in GUIX_PYTHONPATH.
>
> Yay, great to see this fixed!
>
>>  guix/build/pyproject-build-system.scm | 16 
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/guix/build/pyproject-build-system.scm 
>> b/guix/build/pyproject-build-system.scm
>> index a66c1fb34a..cd418f7ec9 100644
>> --- a/guix/build/pyproject-build-system.scm
>> +++ b/guix/build/pyproject-build-system.scm
>> @@ -445,7 +445,7 @@ (define* (add-install-to-pythonpath #:key native-inputs 
>> outputs
>>"A phase that just wraps the 'add-installed-pythonpath' procedure."
>>(add-installed-pythonpath native-inputs outputs))
>>
>> -(define* (wrap #:key inputs outputs #:allow-other-keys)
>> +(define* (wrap #:key native-inputs inputs outputs #:allow-other-keys)
>>(define (list-of-files dir)
>>  (find-files dir (lambda (file stat)
>>(and (eq? 'regular (stat:type stat))
>> @@ -464,9 +464,17 @@ (define bindirs
>>(define %guile (delay (search-input-file inputs "bin/guile")))
>>(define (guile) (force %guile))
>>
>> -  (let* ((var `("GUIX_PYTHONPATH" prefix
>> -,(search-path-as-string->list
>> -  (or (getenv "GUIX_PYTHONPATH") "")
>> +  ;; Use the same strategy to compute the native-input file names.
>> +  (define %native-input-dirs (delay (match native-inputs
>> +  (((_ . dir) ...)
>> +   dir
>> +  (define (native-input-dirs) (force %native-input-dirs))
>> +
>> +  (let ((var `("GUIX_PYTHONPATH" prefix
>> +   ,(remove (lambda (x)
>> +  (any (cut string-prefix? <> x) 
>> (native-input-dirs)))
>> +(search-path-as-string->list
>> + (or (getenv "GUIX_PYTHONPATH") ""))
>
> I think there’s no need to delay+thunk things since we’re using them
> right away.  How about:
>
>   (define native-input-directories
> (match native-inputs
>   …))
>
>   (let ((var `("GUIX_PYTHONPATH" prefix
>,(remove (lambda (x) … native-input-directories …) …
> …)
>
> ?

It's a (small) optimization, that was intended to delay things until
they are really needed that was already used for %bash (now %guile) in
the wrap phase of (guix build python-build-system).

The idea is to delay the evaluation of native-input-directories or the
lookup for guile in the inputs until it's really necessary.  For
example, the computations are avoided when there are no "bin" or "sbin"
sub-directories in the outputs.

> (Same for ‘%guile’ above, but I don’t see it in ‘master’; maybe that’s
> from another branch?)

Yes, the change build on both #60847 (Enable cross-compilation for the
pyproject-build-system) and #60868 (Use wrap-script instead of
wrap-program), which should be applied first.  %guile appears in #60868,
and changes that make the above easy (native-inputs always appearing as
native-inputs, even for native builds) are from #60847.

-- 
Thanks,
Maxim

bug#60141: Stack smashing detected after first guix pull on fresh Ubuntu 22.04 guix install

[Ludovic Courtès]

Hi,

"Andrews, Kyle (KC)"  skribis:

> My system administrator let me know that the terminal I was presented with 
> was sandboxed by RStudio Server (not running on Guix) and that this was 
> responsible for causing the error.
>
> I was able to run the hello command from an unsandboxed shell. I was also 
> able to pull the latest version of guix using the same method.

Thanks for reporting back.  My guess would be that RStudio Server was
setting ‘LD_LIBRARY_PATH’, which in turn caused ‘guix’ to use the wrong
shared library at run-time, leading to that segfault.

I gather we can close this issue now, thanks.

Ludo’.

bug#60852: git-authenticate edge case for certain key setup.

[Ludovic Courtès]

Hi,

Hilton Chain  skribis:

> I encountered the issue when adding a new key to my Guix channel.  Though I
> haven't figured out what happened exactly, I'm currently able to reproduce the
> issue with the following steps.

Fishy.  Would you be able to write a script to reproduce the whole
scenario?  That’d make it easier to test and we’d be sure we’re talking
about the same thing.

Thanks for reporting it!

Ludo’.

bug#60875: Grafting breaks with clang-toolchain@13

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> On Tue, Jan 17, 2023 at 11:23:42AM +0100, Ludovic Courtès wrote:
>> The file exists but it’s a dangling symlink:
>> 
>> --8<---cut here---start->8---
>> $ ls -l 
>> /gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
>> lrwxrwxrwx 1 guixbuilder01 guixbuild 74 Jan 17 10:36 
>> /gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
>>  -> 
>> /gnu/store/v8d7j5i02nfz951x1szbl9xrd873vc3l-zlib-1.2.12/lib/libz.so.1.2.11
>> $ stat -L 
>> /gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
>> stat: cannot statx 
>> '/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11':
>>  No such file or directory
>> --8<---cut here---end--->8---
>
> Merged with 

Fixed in c4a8762e529dc3f8af89dde5dbcbb82f2a4088a3.

Now it would be good to see why ‘clang-toolchain’ has this dangling
symlink.

Thanks,
Ludo’.

bug#60879: `guix pull` profile reproducibility issues

[Lars-Dominik Braun]

Hi,

here at ZPID we “cache” Guix pull profiles (via `guix pull -p`) in project
directories, which can be shared between users. I’ve been trying to
ensure that a given Guix pull profile corresponds to a given channels.scm
file, i.e. it has not been tampered with, because calls to the Guix binary
currently run outside of the project sandbox (`guix shell -C`). Doing
so I discovered two reproducibility issues:

1) `guix pull` and `guix time-machine` currently do not produce the same
   Guix profile, even with exactly the same channels.scm
   file. Unfortunately time-machine does not print the profile path
   anywhere, but this can be reproduced implicitly by looking at the
   output of cached-channel-instance, which the time-machine uses. Looking
   at `guix describe` vs `guix time-machine -C channels.scm -- describe`
   reveals a reversed channel order. Thus channel order matters when
   using a channels.scm, when it really should not.
2) `guix pull` seems to depend on the host `guix` and produces
   different profile paths depending on which `guix` command
   was used to pull. In the following example `guix` is at commit
   f094c3831f382b7299a2aaa04d85f4b27320e9ec and we’re pulling commit
   5fd9d3ba82faddf8393027655d4a10a1562dac47 through the attached
   channels.scm. These commits were selected carefully, because the
   problem is more likely for older commits pulled from newer commits.

   $ guix pull -C channels.scm -p guix-level1
   $ ./guix-level1/bin/guix pull -C channels.scm -p guix-level2
   $ readlink -f guix-level1
   /gnu/store/3fr7rlx9hm29a5c0mh0lnxpqg8prfvw7-profile
   $ readlink -f guix-level2
   /gnu/store/4gyv6m8v47f6wpmrq86iy6wgvivm2sh8-profile
   $ diffoscope guix-level1 guix-level2
   […]
   │ │   --- guix-level1/etc/profile
   │ ├── +++ guix-level2/etc/profile
   │ │ @@ -4,8 +4,8 @@
   │ │  #
   │ │  #  GUIX_PROFILE=/path/to/profile ; \
   │ │  #  source /path/to/profile/etc/profile
   │ │  #
   │ │  # When GUIX_PROFILE is undefined, the various environment variables 
refer
   │ │  # to this specific profile generation.
   │ │
   │ │ +export 
PATH="${GUIX_PROFILE:-/gnu/store/4gyv6m8v47f6wpmrq86iy6wgvivm2sh8-profile}/bin${PATH:+:}$PATH"
   │ │ -export 
PATH="${GUIX_PROFILE:-/gnu/store/3fr7rlx9hm29a5c0mh0lnxpqg8prfvw7-profile}/bin${PATH:+:}$PATH"
  
   The only visible difference is the adjusted PATH, which means there
   actually is no difference. Pulling again from level2 results in the
   same profile as level2, so clearly something is leaking from our
   original `guix` into level1. The .drv files for both reveal that
   fonts-dir.drv is different, because mkfontdir and mkfontscale
   differ. These are part of the profile generation code, which apparently
   comes from the host Guix, when the newly built Guix should be used.

Cheers,
Lars

-- 
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate

www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964

bug#60875: Grafting breaks with clang-toolchain@13

[Leo Famulari]

On Tue, Jan 17, 2023 at 11:23:42AM +0100, Ludovic Courtès wrote:
> The file exists but it’s a dangling symlink:
> 
> --8<---cut here---start->8---
> $ ls -l 
> /gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
> lrwxrwxrwx 1 guixbuilder01 guixbuild 74 Jan 17 10:36 
> /gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
>  -> /gnu/store/v8d7j5i02nfz951x1szbl9xrd873vc3l-zlib-1.2.12/lib/libz.so.1.2.11
> $ stat -L 
> /gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
> stat: cannot statx 
> '/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11':
>  No such file or directory
> --8<---cut here---end--->8---

Merged with 

bug#60875: Grafting breaks with clang-toolchain@13

[Ludovic Courtès]

Here’s what happens:

--8<---cut here---start->8---
$ guix build clang-toolchain@13
The following grafts will be made:
   /gnu/store/gsh6dsafxmkh5wp3cq57czmlz2rc0a7m-clang-toolchain-13.0.1.drv
   /gnu/store/2wa74gbigf0p9ma395qb88983vlwr1w3-clang-runtime-13.0.1.drv
   /gnu/store/iq9n0432xiqnvspwcdy5lskckfzd8jv9-clang-13.0.1.drv
applying 1 graft for clang-runtime-13.0.1 ...
grafting '/gnu/store/qlv8wj8xs8n0ix3843zqzv6xzrk1sf0m-clang-runtime-13.0.1' -> 
'/gnu/store/jx5c9lii5m44ghj054n9vyl3sxsg8z4h-clang-runtime-13.0.1'...
successfully built 
/gnu/store/2wa74gbigf0p9ma395qb88983vlwr1w3-clang-runtime-13.0.1.drv
applying 6 grafts for clang-13.0.1 ...
grafting '/gnu/store/zfs41ixykm4z9162gajgs1ndc6bsbcqr-clang-13.0.1' -> 
'/gnu/store/iv4y7b4rl5bqjib4zna35wc9g61599zm-clang-13.0.1'...
successfully built /gnu/store/iq9n0432xiqnvspwcdy5lskckfzd8jv9-clang-13.0.1.drv
applying 5 grafts for clang-toolchain-13.0.1 ...
grafting 
'/gnu/store/ahg9050hcbcajlyh8hxg3vpawh96s6mz-clang-toolchain-13.0.1-debug' -> 
'/gnu/store/d6ayplxcfv94qs42rdfd5pcjmszzx2hh-clang-toolchain-13.0.1-debug'...
grafting '/gnu/store/0wrp34pb4hrd1vvs7hm4aylx11bipyi9-clang-toolchain-13.0.1' 
-> '/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1'...
grafting 
'/gnu/store/6yl60fk3ph988gxj40h95cck88ya2cvg-clang-toolchain-13.0.1-static' -> 
'/gnu/store/axvgyspibna9q487axjbkn22ghvsgvri-clang-toolchain-13.0.1-static'...
Backtrace:
In ice-9/boot-9.scm:
 160: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2412: 9 [save-module-excursion #]
4089: 8 [#]
1734: 7 [%start-stack load-stack ...]
1739: 6 [#]
In unknown file:
   ?: 5 [primitive-load 
"/gnu/store/axv2m1ck8xnkhgpzzz8bw7jfz9v1164i-clang-toolchain-13.0.1-builder"]
In srfi/srfi-1.scm:
 616: 4 [for-each # #]
In guix/build/debug-link.scm:
 195: 3 [graft-debug-links (# # #) (# # #) (# # # # ...) ...]
In srfi/srfi-1.scm:
 643: 2 [append-map # ...]
 575: 1 [map # ...]
In unknown file:
   ?: 0 [filter # 
#]

ERROR: In procedure filter:
ERROR: In procedure open-file: No such file or directory: 
"/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11"
builder for 
`/gnu/store/gsh6dsafxmkh5wp3cq57czmlz2rc0a7m-clang-toolchain-13.0.1.drv' failed 
with exit code 1
build of /gnu/store/gsh6dsafxmkh5wp3cq57czmlz2rc0a7m-clang-toolchain-13.0.1.drv 
failed
View build log at 
'/var/log/guix/drvs/gs/h6dsafxmkh5wp3cq57czmlz2rc0a7m-clang-toolchain-13.0.1.drv.gz'.
guix build: error: build of 
`/gnu/store/gsh6dsafxmkh5wp3cq57czmlz2rc0a7m-clang-toolchain-13.0.1.drv' failed
$ guix describe
Generation 241  Jan 16 2023 00:26:44(current)
  guix 5c92197
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 5c921977179489caef4a9e54ada6696fc86d2f0b
--8<---cut here---end--->8---

The file exists but it’s a dangling symlink:

--8<---cut here---start->8---
$ ls -l 
/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
lrwxrwxrwx 1 guixbuilder01 guixbuild 74 Jan 17 10:36 
/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
 -> /gnu/store/v8d7j5i02nfz951x1szbl9xrd873vc3l-zlib-1.2.12/lib/libz.so.1.2.11
$ stat -L 
/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11
stat: cannot statx 
'/gnu/store/12wnswvdc1mk9cr498dxflxim4qm2pyq-clang-toolchain-13.0.1/lib/libz.so.1.2.11':
 No such file or directory
--8<---cut here---end--->8---

Ludo’.

bug#25235: [PATCH 1/1] build-system/pyproject: Do not wrap native-inputs.

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Fixes .
>
> * guix/build/pyproject-build-system.scm (wrap) [native-inputs]: New argument.
> Filter out native inputs from the values in GUIX_PYTHONPATH.

Yay, great to see this fixed!

>  guix/build/pyproject-build-system.scm | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/guix/build/pyproject-build-system.scm 
> b/guix/build/pyproject-build-system.scm
> index a66c1fb34a..cd418f7ec9 100644
> --- a/guix/build/pyproject-build-system.scm
> +++ b/guix/build/pyproject-build-system.scm
> @@ -445,7 +445,7 @@ (define* (add-install-to-pythonpath #:key native-inputs 
> outputs
>"A phase that just wraps the 'add-installed-pythonpath' procedure."
>(add-installed-pythonpath native-inputs outputs))
>  
> -(define* (wrap #:key inputs outputs #:allow-other-keys)
> +(define* (wrap #:key native-inputs inputs outputs #:allow-other-keys)
>(define (list-of-files dir)
>  (find-files dir (lambda (file stat)
>(and (eq? 'regular (stat:type stat))
> @@ -464,9 +464,17 @@ (define bindirs
>(define %guile (delay (search-input-file inputs "bin/guile")))
>(define (guile) (force %guile))
>  
> -  (let* ((var `("GUIX_PYTHONPATH" prefix
> -,(search-path-as-string->list
> -  (or (getenv "GUIX_PYTHONPATH") "")
> +  ;; Use the same strategy to compute the native-input file names.
> +  (define %native-input-dirs (delay (match native-inputs
> +  (((_ . dir) ...)
> +   dir
> +  (define (native-input-dirs) (force %native-input-dirs))
> +
> +  (let ((var `("GUIX_PYTHONPATH" prefix
> +   ,(remove (lambda (x)
> +  (any (cut string-prefix? <> x) 
> (native-input-dirs)))
> +(search-path-as-string->list
> + (or (getenv "GUIX_PYTHONPATH") ""))

I think there’s no need to delay+thunk things since we’re using them
right away.  How about:

  (define native-input-directories
(match native-inputs
  …))

  (let ((var `("GUIX_PYTHONPATH" prefix
   ,(remove (lambda (x) … native-input-directories …) …
…)

?

(Same for ‘%guile’ above, but I don’t see it in ‘master’; maybe that’s
from another branch?)

Thanks,
Ludo’.