Re: Help Packaging Incudine (Common Lisp)

2023-10-23 Thread Guillaume Le Vaillant 
Hi.

It looks like there's a bug in "contrib/cl-sndfile/cffi-sndfile.lisp".
The 'make-sndinfo' function definition tries to get the size of the
'info' foreign structure before this foreign structure is defined.

After moving the definition of 'make-sndinfo' at the end of the file,
compilation works.

I think you can report this issue upstream.


signature.asc
Description: PGP signature

Re: [RFC]: Skipping rust crate tests by default

2023-10-23 Thread Efraim Flashner 
On Wed, Oct 18, 2023 at 02:46:57PM -0400, Maxim Cournoyer wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> 
> [...]
> 
> >> This sounds good except I don't understand how disabling the tests by
> >> default help to "make sure that the packages have the correct inputs" ?
> >
> > When the tests are disabled, if a package shows red on the CI it means
> > that either:
> > A) there was a bundled shared/static library in the sources which need
> > to be removed
> > B) The inputs weren't correct and need to be fixed.
> > What we're skipping is C) the test suite failed.
> >
> > When we get to the 'build phase of the cargo-build-system, cargo first
> > checks that it has all of the crates listed in the Cargo.toml file, and
> > that all of those crates have all of their (cargo-input) dependencies,
> > and so on. If any of them are missing then the build will fail. This is
> > also why we need to set #:skip-build? #t when we don't include the
> > desired cargo-development-inputs.
> >
> > The change is mainly a quality of life improvement; it decreases the
> > time that guix people and CI spend building these crates, and it makes
> > it easier to see which, if any, rust packages need to be checked for
> > brokenness (with the assumption that a broken or bit-rotted test suite
> > isn't a problem).
> 
> I understand that maintaining the large fleet of cargo crates packaged
> in Guix is a lot of work, but I think we can try some things before
> #:tests? #f; I gathered some idea below.
> 
> > My premise is that the test suite of crates doesn't necessarily pass
> > when built and run with a newer rust and that we shouldn't be concerned
> > about it.
> >
> >> You've explained the rationale here:
> >> ,
> >> saying we sometimes use a newer Rust than the package tests are
> >> expecting; how does it work in the Rust world?  Don't they always build
> >> even older versions against the most recent compiler?  What about the
> >> test suites then?  Are these not typically run by users/distributions?
> >
> > In general, since rust expects all of the crates to be in source form,
> > the tests are only run by developers when the crate is being developed.
> > If someone comes along and uses that crate as a dependency for their
> > project then they don't run the tests. If they continue using that crate
> > (at that version) for several years then the developer using that older
> > crate as a dependency still only compiles the part of the crate they
> > need for their project and they only run the tests for their project,
> > not for the crates which they've used as dependencies.
> 
> OK.
> 
> > As far as distributions, I can talk for Debian that they only provide
> > the crates as -dev packages, that is, as the source crates. They make
> > sure that they compile (and probably that they pass the test suite) at
> > the time that they are packaged, but no one is distributing pre-compiled
> > crates as packages to be used as inputs for further packages.
> 
> I believe that's the more useful comparison for our discussion; I gather
> that even -dev crates are built and have their test suite run when
> submitted, but since source packages are not rebuilt (they are a static
> archive, right?) then there's no checking that the test suite continues
> working in time.

The source packages are effectively repackaged tarballs. They've made
sure there's no issues with the DFSG, maybe applied some patches, built
and tested the crates, and then repackaged the tarballs.

> >
> > For an example of a failing doc-test, from the rust-nalgebra-0.21 crate:
> >
> >
> >Doc-tests nalgebra
> > error: unnecessary parentheses around index expression
> >   --> 
> > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:45:47
> >|
> > 45 | conv[i] += self[u_i] * kernel[(i - u_i)];
> >|   ^   ^
> >|
> > note: the lint level is defined here
> >   --> 
> > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/lib.rs:78:9
> >|
> > 78 | #![deny(unused_parens)]
> >| ^
> > help: remove these parentheses
> >|
> > 45 - conv[i] += self[u_i] * kernel[(i - u_i)];
> > 45 + conv[i] += self[u_i] * kernel[i - u_i];
> >|
> >
> > error: unnecessary parentheses around index expression
> >   --> 
> > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:49:53
> >|
> > 49 | conv[i] += self[u] * kernel[(i - u)];
> >| ^ ^
> >|
> > help: remove these parentheses
> >|
> > 49 - conv[i] += self[u] * kernel[(i - u)];
> > 49 + conv[i] += self[u] * kernel[i - u];
> >|
> >
> > error: aborting due to 2 previous errors
> >
> > error: doctest failed, to rerun pass `--

Re: Order of manifest and overlapping binaries

2023-10-23 Thread Greg Hogan 
On Tue, May 16, 2023 at 4:55 PM Csepp  wrote:
>
>
> Greg Hogan  writes:
>
> > I could not find documentation on this circumstance or how to resolve.
> > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> > can go in the $GUIX_PROFILE.
> >
> > Creating a container, the latter package overshadows the former
> > package, as below. Unclear if this is consistent. In my manifest the
> > former package overshadows the latter (I'd prefer to have parallel's
> > parallel, but by default I have sorted the listing alphabetically). Is
> > there a better way to fix this?
> >
> > Greg
> >
> > --8<---cut here---start->8---
> > $ guix shell --container moreutils parallel which coreutils
> > [env]$ readlink -f `which parallel`
> > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
> >
> > guix shell --container parallel moreutils which coreutils
> > [env]$ readlink -f $(which parallel)
> > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> > --8<---cut here---end--->8---
> >
> >
> > This is operating from a recent guix pull:
> >
> > --8<---cut here---start->8---
> > $ guix describe
> > Generation 44   May 11 2023 17:02:53(current)
> >   guix d6f6b57
> > repository URL: https://git.savannah.gnu.org/git/guix.git
> > branch: master
> > commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> > --8<---cut here---end--->8---
>
> You could create a package that just copies the contents of moreutils
> to $output, but renames some files, then include the resulting package
> in your manifest.  If moreutils is not propagated from any other
> package, then you don't even have to do an input rewrite.

I'm still cutting my teeth on Scheme, and this looks like a simple
error, but the following from my manifest results in the error below.
The function accepts a package to inherit from and a list of files to
rename by appending the package name. This works if I change to pass
in a single string and create the list within the for-each argument.

(define (rename-files parent-package files)
  (package/inherit parent-package
(arguments
 (substitute-keyword-arguments (package-arguments parent-package)
   ((#:phases phases #~%standard-phases)
 #~(modify-phases #$phases
 (add-after 'install 'rename-files
   (lambda* (#:key outputs #:allow-other-keys)
 (let ((out #$output) (name #$(package-name parent-package)))
   (for-each
 (lambda (file)
   (rename-file (string-append out "/" file)
(string-append out "/" file "-" name)))
 #$files))

(define moreutils-decollide
  (rename-files moreutils (list "bin/parallel")))

--8<---cut here---start->8---
starting phase `rename-files'
error: in phase 'rename-files': uncaught exception:
wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") ("bin/parallel")
phase `rename-files' failed after 0.0 seconds
Backtrace:
   9 (primitive-load "/gnu/store/qrj9l194a552vpg2234xx55k76j…")
In guix/build/gnu-build-system.scm:
908:2  8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  6 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   929:23  4 (_)
In ice-9/eval.scm:
159:9  3 (_ #(#(#(#) (#)) …))
159:9  2 (_ _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: "bin/parallel"
--8<---cut here---end--->8---

Re: Order of manifest and overlapping binaries

2023-10-23 Thread Kaelyn 
Hi,

--- Original Message ---
On Monday, October 23rd, 2023 at 6:18 AM, Greg Hogan  wrote:

> 
> On Tue, May 16, 2023 at 4:55 PM Csepp raingl...@riseup.net wrote:
> 
> > Greg Hogan c...@greghogan.com writes:
> > 
> > > I could not find documentation on this circumstance or how to resolve.
> > > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> > > can go in the $GUIX_PROFILE.
> > > 
> > > Creating a container, the latter package overshadows the former
> > > package, as below. Unclear if this is consistent. In my manifest the
> > > former package overshadows the latter (I'd prefer to have parallel's
> > > parallel, but by default I have sorted the listing alphabetically). Is
> > > there a better way to fix this?
> > > 
> > > Greg
> > > 
> > > --8<---cut here---start->8---
> > > $ guix shell --container moreutils parallel which coreutils
> > > [env]$ readlink -f `which parallel`
> > > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
> > > 
> > > guix shell --container parallel moreutils which coreutils
> > > [env]$ readlink -f $(which parallel)
> > > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> > > --8<---cut here---end--->8---
> > > 
> > > This is operating from a recent guix pull:
> > > 
> > > --8<---cut here---start->8---
> > > $ guix describe
> > > Generation 44 May 11 2023 17:02:53 (current)
> > > guix d6f6b57
> > > repository URL: https://git.savannah.gnu.org/git/guix.git
> > > branch: master
> > > commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> > > --8<---cut here---end--->8---
> > 
> > You could create a package that just copies the contents of moreutils
> > to $output, but renames some files, then include the resulting package
> > in your manifest. If moreutils is not propagated from any other
> > package, then you don't even have to do an input rewrite.
> 
> 
> I'm still cutting my teeth on Scheme, and this looks like a simple
> error, but the following from my manifest results in the error below.
> The function accepts a package to inherit from and a list of files to
> rename by appending the package name. This works if I change to pass
> in a single string and create the list within the for-each argument.
> 
> (define (rename-files parent-package files)
> (package/inherit parent-package
> (arguments
> (substitute-keyword-arguments (package-arguments parent-package)
> ((#:phases phases #~%standard-phases)
> #~(modify-phases #$phases
> (add-after 'install 'rename-files
> (lambda* (#:key outputs #:allow-other-keys)
> (let ((out #$output) (name #$(package-name parent-package)))
> (for-each
> (lambda (file)
> (rename-file (string-append out "/" file)
> (string-append out "/" file "-" name)))
> #$files))
> 
> (define moreutils-decollide
> (rename-files moreutils (list "bin/parallel")))
> 
> --8<---cut here---start->8---
> 
> starting phase `rename-files' error: in phase 'rename-files': uncaught 
> exception: wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") 
> ("bin/parallel") phase` rename-files' failed after 0.0 seconds

This error is because using gexps adds an extra layer of expansion on top of 
normal scheme. The error is coming from the use of "#$files"... specifically in 
the subform "(for-each (lambda (file) ...) #$files)", #$files is replaced--in 
the usage example--with exactly ("bin/parallel"), resulting in:
   (for-each (lambda (file) ...) ("bin/parallel"))

Because it is a gexp, #$file is replaced with ("bin/parallel") and then the 
resulting form is evaluated on the builder. Since ("bin/parallel") now looks 
like a function call, it tries to treat it as one. The three main options that 
I know of are to
1) quote the argument when calling rename-files so that "list" is first in the 
literal list:
(rename-files moreutils '(list "bin/parallel"))
2) quote the list within the gexp:
(for-each (lambda (file) ...) '#$files)
3) build the list within the gexp:
(for-each (lambda (file) ...) (list #@$files)

In my opinion the second option is probably the easiest and safest to work 
with. #1 and #3 both suffer from needing to specially craft the incoming 
argument to handle being evaluated twice. For #1, the argument has to be a list 
after being evaluated twice (the first evaluation is of the quote, the second 
occurs after the gexp was expanded and calls list with the string arguments). 
For #3, the expectation of a list is more explicit, but the argument has to 
evaluate to a list where all of the elements have to then evaluate to something 
meaningful (not too much of an issue for this case as strings evaluate to 
themselves). #2 should only require that the evaluated argument has a printable 
representation that can be read back in, which at least to me feels more 
natural to work with.

Hope my early

Re: [RFC]: Skipping rust crate tests by default

2023-10-23 Thread Maxim Cournoyer 
Hi Efraim!

Efraim Flashner  writes:

[...]

>> > error: unnecessary parentheses around index expression
>> >   --> 
>> > /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:49:53
>> >|
>> > 49 | conv[i] += self[u] * kernel[(i - u)];
>> >| ^ ^
>> >|
>> > help: remove these parentheses
>> >|
>> > 49 - conv[i] += self[u] * kernel[(i - u)];
>> > 49 + conv[i] += self[u] * kernel[i - u];
>> >|
>> >
>> > error: aborting due to 2 previous errors
>> >
>> > error: doctest failed, to rerun pass `--doc`
>> >
>> >
>> > crates.io lists this version as being released more than 3 years ago and
>> > targeting the 2018 edition of rust. When built with our current
>> > rust-1.68.2 the doc test passes but not with 1.70.0.  The current
>> > upstream version of nalgebra is 0.32.3, so it's unlikely that they'd
>> > release a new version with the doc tests fixed, but I haven't contacted
>> > them about it.
>> 
>> OK.  Asking in ##rust on libera chat (unofficial channel), I got as 
>> suggestion
>> to call 'carge test' with the '--cap-lints=allow' option documented
>> here [0], which should effectively disable just the lint checks, which
>> is better than disabling the full test suite.
>> 
>> [0]  https://doc.rust-lang.org/rustc/lints/levels.html
>
> I checked the cargo-build-system and we do actually use
> --cap-lints=allow for building and for testing.

Ah!  It must be something recent, as it was not the case (and still
isn't) when I checked on the master branch.  Or else I fail to see
where/how it's specified.

And nalgebra still fails lint tests with the above --caps-lints=allow
option?  If that's so that'd suggest that packages can enforce their own
settings and that this overrides cargo flags given at the command
line... which sounds like a cargo bug.

-- 
Thanks,
Maxim

x2goclient packaging help

2023-10-23 Thread Nicolas Débonnaire 
Hello,
I'm trying to package x2goclient.
You can find my attempt in the two following files that i'm using in a
local guix channel for testing purpose. x2goclient.scm is the main package
file. nx-libs.scm is a dependency.
While those files build well and x2go gui launch perfectly, It seems that I
can't connect to a remote desktop with x2go gui.
(define-module (x2goclient)
  #:use-module (man2html)
  #:use-module (nx-libs)
  #:use-module (gnu packages man)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (guix build utils)
  #:use-module (gnu packages perl)
  #:use-module (gnu packages xorg)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages openldap)
  #:use-module (gnu packages ssh)
  #:use-module (gnu packages commencement)
  #:use-module (gnu packages cups)
  #:use-module (gnu packages ssh)
  #:use-module (gnu packages base)
  #:use-module (gnu packages qt)
  #:use-module (guix build-system gnu)
  #:use-module (guix download))

(define-public x2goclient
  (package
(name "x2goclient")
(version "4.1.2.3")
(source (origin
  (method url-fetch)
  (uri (string-append "https://code.x2go.org/releases/source/x2goclient/x2goclient-"; version ".tar.gz"))
  (sha256
   (base32
"0g6aba8kpsixq4486a8mga945lp31y0mzwa2krs5qqiiip3v72xb"
(build-system gnu-build-system)
(arguments
 `(#:tests? #f
   #:phases
 (modify-phases %standard-phases
	(delete 'configure)
	(add-before 'build 'fix-makefile
	 (lambda* (#:key outputs #:allow-other-keys)
		(let* ((out (assoc-ref outputs "out"))
		   (etc (string-append out "/etc")))
			(mkdir-p etc)
		(substitute* "Makefile"
		  (("= 4") "= 5") ;; use qt5 instead of qt4
		  (("-o root -g root") "") ;; not sure why but this is on archlinux recipe so I copied it
		  (("/usr/local") out)
		  (("/etc/x2go") etc)
		  ;; (("lrelease") (which "lrelease"))
		  ;; A KLUDGE to turn off invoking lrelease on the
		  ;; project for now, because it fails consistently
		  ;; with "WARNING: Could not find qmake spec
		  ;; 'default'". See below.
		  ;; KLUDGE taken from the guix package smplayer
		  (("lrelease") "true")
		  (("qmake") (which "qmake")))
		;; (substitute* "src/onmainwindow.cpp"
		;; 	 (("/usr/sbin/sshd") (which "sshd")))
		#t)))
;; src/onmainwindow.cpp --replace "/usr/sbin/sshd" "${openssh}/bin/sshd"
	;; TODO: build html_man
	(replace 'build
		 (lambda _
		   (invoke "make" "build_client")
		   #t))
	(add-after 'build 'build-man
		 (lambda _
		   (invoke "make" "install_man")
		   #t))
	;; Due to the above, we must run lrelease separately on each .ts file
;; (as opposed to running `lrelease-pro smplayer.pro` for the entire
;; project, as the Makefile does normally without the above kludge).
(add-after 'build 'compile-ts-files
  (lambda _
(for-each (lambda (file)
(invoke "lrelease" file))
  (find-files "./" "\\.ts$")))
(native-inputs (list pkg-config man2html qttools-5 which qtbase-5 qtx11extras qtsvg-5 libssh cups libxpm openldap gcc-toolchain))
(propagated-inputs (list perl nx-libs openssh))
(synopsis "Remote Desktop/Remote Application solution.")
(description "Remote Desktop/Remote Application solution.")
(home-page "http://x2go.org/";)
(license gpl2)))

;; TODO: substituteInPlace src/onmainwindow.cpp --replace "/usr/sbin/sshd" "${openssh}/bin/sshd"
(define-module (nx-libs)
  ;; #:use-module (gnu packages man)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (guix build utils)
  #:use-module (gnu packages perl)
  #:use-module (gnu packages xdisorg)
  #:use-module (gnu packages autotools)
  #:use-module (gnu packages xorg)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages python)
  #:use-module (gnu packages xml)
  #:use-module (gnu packages image)
  #:use-module (gnu packages onc-rpc)
  #:use-module (gnu packages base)
  #:use-module (gnu packages patchutils)
  #:use-module (gnu packages commencement)
  ;; #:use-module (gnu packages cups)
  ;; #:use-module (gnu packages base)
  ;; #:use-module (gnu packages qt)
  #:use-module (guix build-system gnu)
  #:use-module (guix download))

(define-public nx-libs
  (package
(name "nx-libs")
(version "3.5.99.27")
(source (origin
  (method url-fetch)
  (uri (string-append "https://github.com/ArcticaProject/nx-libs/archive/"; version "/nx-libs-" version ".tar.gz"))
  (sha256
   (base32
"1smyvnz50jwp3717wfj4w5m4ny8832ga6yvv1i4yax94cy5d5lq5"
(build-system gnu-build-system)
(arguments
 `(#:tests? #f
   #:phases
   (modify-phases %standard-phases
	(delete 'configure)
	(add-before 'build 'fix-makefile
	 (lambda* (#:key outputs #:allow-other-keys)

Re: Building from git

2023-10-23 Thread Nicolas Débonnaire 
Hi,
Looks like it's working.
I was able to complete the "building from git" section of the documentation
after an update of guix.
Thanks everyone.

Le sam. 9 sept. 2023 à 11:01, Simon Tournier  a
écrit :

> Hi,
>
> On Thu, 07 Sep 2023 at 19:45, wolf  wrote:
>
> >> The Makefile does not run ‘guix git authenticate’ using ./pre-inst-env.
> >> And that’s probably to ensure the source of trust.  If one corrupt the
> >> commit that is built, then ’make authenticate’ would authenticate the
> >> corruption because it would run the corrupted newly built guix command.
> >> Currently, ’make authenticate’ run one guix command that had already
> >> been authenticated.  Well, that’s my understanding.
> >
> > Hmm, but the recipe for the authenticate rule comes from the (possibly)
> > compromised source, no?  So the attacker can just modify the recipe
> instead of
> > the command going the authentication.  Am I missing something?
>
> Yes, the corruption of Makefile.am can be the corruption I was talking
> about.
>
> Well, for more explanations one can maybe read:
>
> [bug#57909] bug#57910: [PATCH] Add link to 'pre-inst-env' from
> 'installing from git' docs
> Ludovic Courtès 
> Sat, 24 Sep 2022 17:58:29 +0200
> id:87k05s7oii.fsf...@gnu.org
> https://issues.guix.gnu.org//57910
> https://issues.guix.gnu.org/msgid/87k05s7oii.fsf...@gnu.org
> https://yhetil.org/guix/87k05s7oii.fsf...@gnu.org
>
> [bug#57909] bug#57910: [PATCH] Add link to 'pre-inst-env' from
> 'installing from git' docs
> Maxime Devos 
> Sat, 24 Sep 2022 18:23:10 +0200
> id:ec49e6c2-a542-7d95-0d73-10b2816c5...@telenet.be
> https://issues.guix.gnu.org//57910
>
> https://issues.guix.gnu.org/msgid/ec49e6c2-a542-7d95-0d73-10b2816c5...@telenet.be
>
> https://yhetil.org/guix/ec49e6c2-a542-7d95-0d73-10b2816c5...@telenet.be
>
> Cheers,
> simon
>

Re: Proposal to introduce a Change-Id in our commit messages

2023-10-23 Thread Simon Tournier 
Hi,

On Sat, 14 Oct 2023 at 11:21, Maxim Cournoyer  wrote:

> As was discussed in [1], a proposal that emerged is adding a new
> commit-msg hook to our auto-configuration, so that a 'Change-Id' git
> trailer would always get added to new commits.
>
> This part has been implemented already bug#66027; if you have
> comments/concerns, now is a good time to share them!

For the record, it seems merged with:

fb3707762d * etc: teams: Parse 'From' commit more leniently.
f44fa21c3e * gnu: patman: Apply patch for new Change-Id setting.
8005e09b26 * build: Add a commit-msg hook that embeds Change-Id in commit 
messages.


Cheers,
simon

Re: Order of manifest and overlapping binaries

2023-10-23 Thread Simon Tournier 
Hi,

On Tue, 16 May 2023 at 16:41, Greg Hogan  wrote:

> I could not find documentation on this circumstance or how to resolve.
> Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> can go in the $GUIX_PROFILE.
>
> Creating a container, the latter package overshadows the former
> package, as below. Unclear if this is consistent. In my manifest the
> former package overshadows the latter (I'd prefer to have parallel's
> parallel, but by default I have sorted the listing alphabetically). Is
> there a better way to fix this?
>
> --8<---cut here---start->8---
> $ guix shell --container moreutils parallel which coreutils
> [env]$ readlink -f `which parallel`
> /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
>
> guix shell --container parallel moreutils which coreutils
> [env]$ readlink -f $(which parallel)
> /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> --8<---cut here---end--->8---

Command-line is parsed from right to left.  Therefore, it is consistent.

However, when using manifest, it is parsed from left to right.  See
#43585 [1].  Compare:

--8<---cut here---start->8---
$ cat moreutils-parallel.scm
(specifications->manifest
 (list "moreutils" "parallel"))

$ guix shell -C -m moreutils-parallel.scm coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel

$ guix shell -C moreutils parallel coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/wi3j9z1s5pdna43ccyjf6c5pa1gnpg4x-parallel-20230622/bin/parallel
--8<---cut here---end--->8---

versus

--8<---cut here---start->8---
$ cat parallel-moreutils.scm
(specifications->manifest
 (list "parallel" "moreutils"))

$ guix shell -C -m parallel-moreutils.scm coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/wi3j9z1s5pdna43ccyjf6c5pa1gnpg4x-parallel-20230622/bin/parallel

$ guix shell -C parallel moreutils coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
--8<---cut here---end--->8---

Well, I do not know if it is a feature or a bug. :-)

Especially when command-lines are not all consistent.

--8<---cut here---start->8---
$ guix show moreutils parallel | recsel -Cp name
name: moreutils
name: parallel

$ guix show parallel moreutils | recsel -Cp name
name: parallel
name: moreutils
--8<---cut here---end--->8---


Cheers,
simon


1: https://issues.guix.gnu.org/43585#2