bug#58859: profile contents depends on package order

[John Kehayias via Bug reports for GNU Guix]

Hi Guix,

(I'm cc'ing the devel list for this bug report as I think some wider input and 
commentary would be worthwhile.)

While investigating a bug with the --emulate-fhs option (bug report 
forthcoming) I noticed that the profile contents can depend on the order of 
packages given as input to guix shell. The FHS bug is also due to argument 
order, but I think is clearly a bug and not expected behavior (wrong glibc 
included in the container). Though maybe we want to look around for other 
argument order problems or have some tests?

Actually, this is true for profiles more generally, as I just quickly tested 
the first example with "guix install" rather than just shell. My examples are 
all with shell, but I guess it comes down to the same thing. I think this is 
trickier with shell and the -D option, as we'll see in the second example.

First example, where we might expect something to happen, though personally I 
expected a profile collision error:

--8<---cut here---start->8---
❯ guix shell ffmpeg@4 ffmpeg@5

❯ ls -la $(which ffmpeg)
lrwxrwxrwx 1 root root 67 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/bin/ffmpeg -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/bin/ffmpeg*

❯ ls -la $GUIX_ENVIRONMENT/lib/libavdevice.so*
lrwxrwxrwx 1 root root 75 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.58 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58*
lrwxrwxrwx 1 root root 85 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.58.13.100
 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58.13.100*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.59 -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59*
lrwxrwxrwx 1 root root 84 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.59.7.100 
-> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59.7.100*
--8<---cut here---end--->8---

Note that the last specified package, ffmpeg@5, takes precedence here for bin, 
and the lib directory contains a mixture (as there are some unique filenames as 
well).

To compare, we do the same thing with the order of ffmpeg versions switched. As 
we might guess, the profile was not cached; this is a different profile.

--8<---cut here---start->8---
❯ guix shell ffmpeg@5 ffmpeg@4
The following derivation will be built:
  /gnu/store/2273cnn0wpgid93na7wbhzijrz0r0hlx-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
generating GLib schema cache...
building directory of Info manuals...
building XDG desktop file cache...
building XDG MIME database...
building profile with 2 packages...

❯ ls -la $(which ffmpeg)
lrwxrwxrwx 1 root root 67 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/bin/ffmpeg -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/bin/ffmpeg*

❯ ls -la $GUIX_ENVIRONMENT/lib/libavdevice.so*
lrwxrwxrwx 1 root root 75 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.58 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58*
lrwxrwxrwx 1 root root 85 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.58.13.100
 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58.13.100*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.59 -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59*
lrwxrwxrwx 1 root root 84 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.59.7.100 
-> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59.7.100*
--8<---cut here---end--->8---

This confirms the ordering of inputs to guix shell matters.

As a rather contrived example we might expect the user is paying attention with 
this explicit package input conflict. However, this also happens when that is 
not clear from the package names without inspecting package definitions.

See this second example, where the sdl2 package given to guix shell does not 
match the sdl2-2.0 input of ffmpeg@4 (with the -D argument):

--8<---cut 

bug#58861: guix shell emulate-fhs option can have wrong glibc package

[John Kehayias via Bug reports for GNU Guix]

Hi Guixers,

(cc'ing Ludo’ as author of the commit referenced below)

After commit 

 I noticed a changed in behavior of guix shell with the emulate-fhs option for 
a container. I tracked it down to the wrong glibc package appearing in the 
container, i.e. the standard Guix version rather than glibc-for-fhs (which 
reads a global ld cache).

The cause I believe is related to , namely 
that package input order for a profile can matter. But it is slightly different 
here since the glibc-for-fhs package is added internally.

We can see this demonstrated by comparing the FHS container with a -D input so 
that a glibc package is implicitly included (here from the gnu-build-system):

--8<---cut here---start->8---
❯ guix shell -CFD hello coreutils
john@narya ~/Files/UPenn/canvasgrading [env]$ ls /lib/ld* -la
lrwxrwxrwx 1 65534 overflow 69 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 79 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2
--8<---cut here---end--->8---

Note that the loader comes from the standard glibc package. This means it won't 
read from the global cache.

However, if we change the order, placing the FHS option after the (implicit) 
glibc input, we do get the glibc-for-fhs package. This is similar to #58859 
which I just reported:

--8<---cut here---start->8---
❯ guix shell -CD hello -F coreutils
The following derivation will be built:
  /gnu/store/1hvdkgp68nak827qx6vhmrixdixnl6yl-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building profile with 23 packages...

[env]$ ls /lib/ld* -la
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2
--8<---cut here---end--->8---

Here the ld loader is as it should be for the FHS container.

This was not the behavior before 8b192c5550213911f930594f4fd7386f36618237, 
where the option handling was moved to shell rather than environment for 
emulate-fhs. Reverting this commit and doing the same thing, I get

--8<---cut here---start->8---
❯ ./pre-inst-env guix shell -CFD hello coreutils

[env]$ ls -la /lib/ld*
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2

[env]$ exit

❯ ./pre-inst-env guix shell -CD hello -F coreutils

[env]$ ls -la /lib/ld*
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2
--8<---cut here---end--->8---

Both cases have the expected behavior. The glibc-for-fhs package being added to 
the profile is done last, when creating the manifest, so I think it is the last 
package in the list and thus "wins out" over the glibc from the --development 
input (in keeping with the behavior noted in #58859).

Further, I don't reproduce the bug that the commit above was supposed to fix: 
running the same FHS container shell multiple times (so the profile is cached) 
does not give me any errors. Although I didn't test for this specifically 
before the final FHS patches, I did (and do) use the same cached profiles 
repeatedly.

Was the bug in using the --profile option in combination with --emulate-fhs? I 
haven't tested that, but I could see that being the problem instead.

Assuming there is a problem with profiles and emulate-fhs, what is the best fix 
here? My guess is to put the glibc-for-fhs package always last to make sure it 
is the glibc of the profile in this case to always have the same (expected) 
behavior.

Thanks!
John

bug#47949: Failed to produce output path for guix-package-cache

[Vagrant Cascadian]

On 2022-10-26, Vagrant Cascadian wrote:
> On 2022-10-26, zimoun wrote:
>> On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian  wrote:
>>
>>> It is consistently the same errors in the log, though on further looking
>>> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed
>>> files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow
>>> related. I did remove all the evidence, so so if stale checkouts is
>>> somehow the issue, it will be hard to reproduce again... oops.
...
>>> I did manage again to use an old commit to pull up to a more recent
>>> master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new
>>> commits now so will try again. Will see.
>>
>> What is your hackish workflow?  You do,
>>
>> guix pull --commit= && guix pull
>
> To use the older generations I used:
>
>   /var/guix/profiles/per-user/vagrant/current-guix-138-link/bin/guix pull ...
>
>
>> right?  From your recent pull, does this
>>
>> guix time-machine --commit= -- help
>>
>> work?  where  is newer than your current revision.
>
> Oh yeah, that reminds me to add to the confusion, "guix time-machine
> --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't
> successfully work with guix pull.
>
> Maybe that's a clue pointing to the crufty .cache directories?

Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem
again, with several successful pulls.

This suggests to me that guix should make sure to not use a dirty
checkout to prevent this in the future ... either exporting the guix
tree it's working with to a temporary location, or something like
running "git clean -dfx" before using the checkout...


live well,
  vagrant


signature.asc
Description: PGP signature

bug#58841: Acknowledgement (repl ignores modules from the channel added to time-machine)

[alexander barakin (aka sash-kan)]

explanation:

## current configuration:
$ guix describe --format=channels
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "a0751e3250dfea7e52468c8090e18c3118d93a60")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")

## add guix-hpc channel (for illustration purposes only; you can use any other 
channel):
$ cat channels.scm
(list
  (channel
(name 'guix-hpc)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;))
  (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "a0751e3250dfea7e52468c8090e18c3118d93a60")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")

## both channels - guix and guix-hpc - are available:
$ guix time-machine --channels=channels.scm -- describe
  guix a0751e3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: a0751e3250dfea7e52468c8090e18c3118d93a60
  guix-hpc 1a6af9f
repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
branch: master
commit: 1a6af9f0154f57dc5a31bf535bb09db63e3a8d03

## but repl does not see guix-hpc modules:
$ guix time-machine --channels=channels.scm -- repl
...
scheme@(guix-user)> (use-modules (airbus solvers))
While compiling expression:
no code for module (airbus solvers)
scheme@(guix-user)> %load-path
$1 = 
("/gnu/store/dfm3k2qc0s4f8vi5il3gvrr0650p65k3-guix-module-union/share/guile/site/3.0"
 "/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/3.0" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/3.0" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/site/3.0" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/site" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile" 
"/home/user/.guix-profile/share/guile/site/3.0" 
"/home/user/.guix-profile/share/guile/site/3.0")

-- 
wbr, alexander barakin aka sash-kan.
-- 
i will be very thankful to you if you will use order,
that natural for the human:
first question, then the answer.


signature.asc
Description: PGP signature

bug#58841: repl ignores modules from the channel added to time-machine

[alexander barakin (aka sash-kan)]

see the attached file report.txt with explanations.## current configuration:
$ guix describe --format=channels
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "a0751e3250dfea7e52468c8090e18c3118d93a60")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")

## add guix-hpc channel (for illustration purposes only; you can use any other 
channel):
$ cat channels.scm
(list
  (channel
(name 'guix-hpc)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;))
  (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "a0751e3250dfea7e52468c8090e18c3118d93a60")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")

## both channels - guix and guix-hpc - are available:
$ guix time-machine --channels=channels.scm -- describe
  guix a0751e3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: a0751e3250dfea7e52468c8090e18c3118d93a60
  guix-hpc 1a6af9f
repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
branch: master
commit: 1a6af9f0154f57dc5a31bf535bb09db63e3a8d03

## but repl does not see guix-hpc modules:
$ guix time-machine --channels=channels.scm -- repl
...
scheme@(guix-user)> (use-modules (airbus solvers))
While compiling expression:
no code for module (airbus solvers)
scheme@(guix-user)> %load-path
$1 = 
("/gnu/store/dfm3k2qc0s4f8vi5il3gvrr0650p65k3-guix-module-union/share/guile/site/3.0"
 "/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/3.0" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/3.0" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/site/3.0" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/site" 
"/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile" 
"/home/user/.guix-profile/share/guile/site/3.0" 
"/home/user/.guix-profile/share/guile/site/3.0")

bug#47584: [PATCH 1/3] guile-next: Update to 3.0.8-793fb46.

[Maxime Devos]

* gnu/packages/guile.scm (guile-next): Update to 3.0.8, commit 793fb46.
[arguments]: Remove 'skip-failing-tests', as presumably the issues are fixed
in the new version.
---
 gnu/packages/guile.scm | 21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index fcdf75051c..936fc8649f 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -431,11 +431,11 @@ (define-public guile-3.0/fixed
 ;  when heavily loaded)
 
 (define-public guile-next
-  (let ((version "3.0.7")
+  (let ((version "3.0.8")
 (revision "0")
-(commit "d70c1dbebf9ac0fd45af4578c23983ec4a7da535"))
+(commit "793fb46a1e69fa2156805e4a97b340cf62e096a6"))
 (package
-  (inherit guile-3.0)
+  (inherit guile-3.0-latest)
   (name "guile-next")
   (version (git-version version revision commit))
   (source (origin
@@ -447,19 +447,10 @@ (define-public guile-next
 (file-name (git-file-name name version))
 (sha256
  (base32
-  "05rsk9lh5kchbav3lwfwgvgybrykqqjmkkc6689fhb3mjr5m3dqj"
-  (arguments
-   (substitute-keyword-arguments (package-arguments guile-3.0)
- ((#:phases phases '%standard-phases)
-  `(modify-phases ,phases
- (add-before 'check 'skip-failing-tests
-   (lambda _
- (substitute* "test-suite/standalone/test-out-of-memory"
-   (("!#") "!#\n\n(exit 77)\n"))
- (delete-file "test-suite/tests/version.test")
- #t))
+  "0x42qhsdgx7mg6ap2zgbpbj3f5yhjapyr3xkpzb1z6f2yc8rdlsw"
   (native-inputs
-   (modify-inputs (package-native-inputs guile-3.0)
+   (modify-inputs (package-native-inputs guile-3.0-latest)
+ (replace "guile" this-package) ; for cross-compilation
  (prepend autoconf
   automake
   libtool

base-commit: 31a56967e2869c916b7a5e8ee570e8e10f0210a5
prerequisite-patch-id: 2712efb97bf33985fd0658e4dd8e936dc08be5fe
prerequisite-patch-id: 9d2409b480a8bff0fef029b4b095922d4957e06f
prerequisite-patch-id: 51a32abca3efec1ba67ead59b8694c5ea3129ad3
prerequisite-patch-id: 9092927761a340c07a99f5f3ed314a6add04cdee
prerequisite-patch-id: d0af09fbd5ee0ef60bdee53b87d729e46c1db2ca
prerequisite-patch-id: c2b101598fa5b6f93470ae41d51a983dcb931b04
-- 
2.38.0

bug#47584: [PATCH 1/3] guile-next: Update to 3.0.8-793fb46.

[Maxime Devos]

On 28-10-2022 18:04, Maxime Devos wrote:

(native-inputs
-   (modify-inputs (package-native-inputs guile-3.0)
+   (modify-inputs (package-native-inputs guile-3.0-latest)
+ (replace "guile" this-package) ; for cross-compilation


I forgot to mention this in the commit message.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#47584: [PATCH 3/3] activation: Fix TOCTTOU in mkdir-p/perms.

[Maxime Devos]

I removed the 'Based upon mkdir-p from (guix build utils)'
comment because it's quite a bit different now.

* gnu/build/activation.scm (verify-not-symbolic): Delete.
(mkdir-p/perms): Rewrite in terms of 'openat'.
---
 gnu/build/activation.scm | 90 +---
 1 file changed, 57 insertions(+), 33 deletions(-)

diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index 10c9045740..29c6f2ce4c 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -5,7 +5,7 @@
 ;;; Copyright © 2015, 2018 Mark H Weaver 
 ;;; Copyright © 2018 Arun Isaac 
 ;;; Copyright © 2018, 2019 Ricardo Wurmus 
-;;; Copyright © 2021 Maxime Devos 
+;;; Copyright © 2021, 2022 Maxime Devos 
 ;;; Copyright © 2020 Christine Lemmer-Webber 
 ;;; Copyright © 2021 Brice Waegeneire 
 ;;;
@@ -64,46 +64,70 @@ (define %skeleton-directory
 (define (dot-or-dot-dot? file)
   (member file '("." "..")))
 
-;; Based upon mkdir-p from (guix build utils)
-(define (verify-not-symbolic dir)
-  "Verify DIR or its ancestors aren't symbolic links."
+(define (mkdir-p/perms directory owner bits)
+  "Create directory DIRECTORY and all its ancestors.
+
+Additionally, verify no component of DIRECTORY is a symbolic link,
+without TOCTTOU races.  However, if OWNER differs from the the current
+(process) uid/gid, there is a small window in which DIRECTORY is set to the
+current (process) uid/gid instead of OWNER.  This is not expected to be
+a problem in practice.
+
+The permission bits and owner of DIRECTORY are set to BITS and OWNER.
+Anything above DIRECTORY that already exists keeps
+its old owner and bits.  For components that do not exist yet, the owner
+and bits are set according to the default behaviour of 'mkdir'."
   (define absolute?
-(string-prefix? "/" dir))
+(string-prefix? "/" directory))
 
   (define not-slash
 (char-set-complement (char-set #\/)))
 
-  (define (verify-component file)
-(unless (eq? 'directory (stat:type (lstat file)))
-  (error "file name component is not a directory" dir)))
+  ;; By combining O_NOFOLLOW and O_DIRECTORY, this procedure automatically
+  ;; verifies that no components are symlinks.
+  (define open-flags (logior O_CLOEXEC ; don't pass the port on to subprocesses
+ O_NOFOLLOW ; don't follow symlinks
+ O_DIRECTORY)) ; reject anything not a directory
 
-  (let loop ((components (string-tokenize dir not-slash))
- (root   (if absolute?
- ""
- ".")))
+  (let loop ((components (string-tokenize directory not-slash))
+ (root (open (if absolute? "/" ".") open-flags)))
 (match components
   ((head tail ...)
-   (let ((file (string-append root "/" head)))
- (catch 'system-error
-   (lambda ()
- (verify-component file)
- (loop tail file))
-   (lambda args
- (if (= ENOENT (system-error-errno args))
- #t
- (apply throw args))
-  (() #t
-
-;; TODO: the TOCTTOU race can be addressed once guile has bindings
-;; for fstatat, openat and friends.
-(define (mkdir-p/perms directory owner bits)
-  "Create the directory DIRECTORY and all its ancestors.
-Verify no component of DIRECTORY is a symbolic link.
-Warning: this is currently suspect to a TOCTTOU race!"
-  (verify-not-symbolic directory)
-  (mkdir-p directory)
-  (chown directory (passwd:uid owner) (passwd:gid owner))
-  (chmod directory bits))
+   (let retry ()
+ ;; In the usual case, we expect HEAD to already exist.
+ (match (catch 'system-error
+  (lambda ()
+(openat root head open-flags))
+  (lambda args
+(if (= ENOENT (system-error-errno args))
+#false
+(begin
+  (close-port root)
+  (apply throw args)
+   ((? port? new-root)
+(close root)
+(loop tail new-root))
+   (#false
+;; If not, create it.
+(catch 'system-error
+  (lambda _
+(mkdirat root head))
+  (lambda args
+;; Someone else created the directory.  Unexpected but fine.
+(unless (= EEXIST (system-error-errno args))
+  (close-port root)
+  (apply throw args
+(retry)
+  (()
+   (catch 'system-error
+ (lambda ()
+   (chown root (passwd:uid owner) (passwd:gid owner))
+   (chmod root bits))
+ (lambda args
+   (close-port root)
+   (apply throw args)))
+   (close-port root)
+   (values)
 
 (define* (copy-account-skeletons home
  #:key
-- 
2.38.0

bug#47584: [PATCH 2/3] WIP gnu: Change the Guile used for activation to one that has 'openat'.

[Maxime Devos]

TODO: when doing "make check-system TESTS=ldap", I get a build failure
of openssl@1.1.1l, I suspect it's a situation like
 again, though I haven't investigated yet.

Test Summary Report
---
../test/recipes/80-test_ssl_new.t(Wstat: 256 Tests: 29 Failed: 
1)
  Failed test:  12
  Non-zero exit status: 1
Files=158, Tests=2636, 157 wallclock secs ( 2.29 usr  0.18 sys + 104.74 cusr 
28.04 csys = 135.25 CPU)
Result: FAIL
make[1]: *** [Makefile:208: _tests] Error 1
make[1]: Leaving directory '/tmp/guix-build-openssl-1.1.1l.drv-0/openssl-1.1.1l'
make: *** [Makefile:205: tests] Error 2

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test") exit-status: 2 
term-signal: #f stop-signal: #f>
phase `check' failed after 157.1 seconds
command "make" "test" failed with status 2
note: keeping build directory `/tmp/guix-build-openssl-1.1.1l.drv-1'
builder for `/gnu/store/jhijsrxqh586l8ck61ppkhydkb158hj0-openssl-1.1.1l.drv' 
failed with exit code 1
build of /gnu/store/jhijsrxqh586l8ck61ppkhydkb158hj0-openssl-1.1.1l.drv failed
[...]

This is required by the next patch, in which 'mkdir-p/perms'
uses 'openat'.

* gnu/packages/guile.scm (guile-for-activation): New variable.
* gnu/services.scm (activation-script)[actions]: Set #:guile to
guile-for-activation.
* gnu/packages/make-bootstrap.scm (%guile-static-stripped/initrd):
New variable.
* gnu/system/linux-initrd.scm (expression->initrd): Use
%guile-static-stripped/initrd instead of %guile-static-stripped.
---
 gnu/packages/guile.scm  |  5 +
 gnu/packages/make-bootstrap.scm | 15 ---
 gnu/services.scm|  5 -
 gnu/system/linux-initrd.scm |  4 ++--
 4 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 936fc8649f..1d1b0bd77b 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -460,6 +460,11 @@ (define-public guile-next
   gperf)))
   (synopsis "Development version of GNU Guile"
 
+;; The important thing here is that this Guile has 'openat' and friends
+;; for (gnu build activation), which at time of writing isn't available
+;; in any release yet.
+(define-public guile-for-activation guile-next)
+
 (define* (make-guile-readline guile #:optional (name "guile-readline"))
   (package
 (name name)
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 4ea97368a9..8852caa406 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2019, 2020 Marius Bakke 
 ;;; Copyright © 2020 Mathieu Othacehe 
 ;;; Copyright © 2021 Pierre Langlois 
+;;; Copyright © 2022 Maxime Devos 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -57,7 +58,8 @@ (define-module (gnu packages make-bootstrap)
 %mes-bootstrap-tarball
 %bootstrap-tarballs
 
-%guile-static-stripped))
+%guile-static-stripped
+%guile-static-stripped/initrd))
 
 ;;; Commentary:
 ;;;
@@ -794,14 +796,21 @@ (define* (make-guile-static-stripped static-guile)
 (synopsis "Minimal statically-linked and relocatable Guile")))
 
 (define %guile-static-stripped
-  ;; A stripped static Guile 3.0 binary, for use in initrds
-  ;; and during bootstrap.
+  ;; A stripped static Guile 3.0 binary, for use during bootstrap.
   (make-guile-static-stripped
(make-guile-static guile-3.0
   '("guile-2.2-default-utf8.patch"
 "guile-3.0-linux-syscalls.patch"
 "guile-3.0-relocatable.patch"
 
+;; Like %guile-static-stripped, but for use in initrds.
+(define %guile-static-stripped/initrd
+  (make-guile-static-stripped
+   (make-guile-static guile-for-activation
+  '("guile-2.2-default-utf8.patch"
+"guile-3.0-linux-syscalls.patch"
+"guile-3.0-relocatable.patch"
+
 (define (tarball-package pkg)
   "Return a package containing a tarball of PKG."
   (package
diff --git a/gnu/services.scm b/gnu/services.scm
index 2abef557d4..e051f9e821 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2021 raid5atemyhomework 
 ;;; Copyright © 2020 Christine Lemmer-Webber 
 ;;; Copyright © 2020, 2021 Brice Waegeneire 
+;;; Copyright © 2022 Maxime Devos 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -41,6 +42,7 @@ (define-module (gnu services)
   #:use-module (guix utils)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bash)
+  #:use-module ((gnu packages guile) #:select (guile-for-activation))
   #:use-module (gnu packages hurd)
   #:use-module (gnu system setuid)
   #:use-module (srfi srfi-1)
@@ -610,7 +612,8 @@ (define* (activation-service->script service)
 (define (activation-script gexps)
   "Return the system's activation script, which evaluates 

bug#47584: [DRAFT PATCH v2 0/4] Fix race condition in mkdir-p/perms

[Maxime Devos]

> TODO: change the Guile used for activation to some
> commit that has openat etc, [...]

This is done now, but "make check-system" now fails due to an openssl 
build failure, see latest patch, so not yet appliable ...


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58221: (no subject)

[Alexandre Hannud Abdo]

Ni! I'm facing the same issue at 5dda4c69f075dcee020e51f4559cb3df4d2336c4 
(Posting to follow thread).

bug#58836: pull failed on Debian bullseye

[Kristian Nygaard Jensen]

hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
package and

defining `GUIX_LOCPATH', along these lines:

 guix install glibc-utf8-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 95d44c0 (26,769 new 
commits)...

Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git    95d44c0
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/sflmgcfcdwizj7iyd3pfksdvrkc3pskb-config.scm.drv...
building /gnu/store/7k17dvmcrdicjsdxmpvhss4p3i3d70j5-git.scm.drv...
building /gnu/store/j9s3n7iqvh8pqkxkwy91nq3qynr1nby7-hash.scm.drv...
building /gnu/store/a9pyc6s8wk3y8lglvdca4azs6s3j608m-module-import.drv...
building /gnu/store/r857iy1wyhrigmgxv5m3cx344sngzzdd-module-import.drv...
building 
/gnu/store/7f9m50by35nrvk7hbln6m79xzydjz0yn-module-import-compiled.drv...
building 
/gnu/store/142ffhlv13lajan1f82fskb5aj9nf4ks-module-import-compiled.drv...
building 
/gnu/store/j68lg4zxlanqrd5hbkzixh1d7jmw6i1r-compute-guix-derivation.drv...

Computing Guix derivation for 'x86_64-linux'... -Backtrace:
  13 (primitive-load 
"/gnu/store/42s1sikdv0xhv3rxshks8bz4f05a3jg7-compute-guix-derivation")

In ice-9/eval.scm:
    155:9 12 (_ _)
    159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:
    152:2 10 (with-fluid* _ _ _)
    152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2170:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)

   1998:8  7 (_ _)
In ./guix/gexp.scm:
   299:22  6 (_ _)
   1180:2  5 (_ _)
   1046:2  4 (_ _)
    892:4  3 (_ _)
In ./guix/store.scm:
  2055:12  2 (_ #)
   1403:5  1 (map/accumulate-builds #7fabbd46ddc0> # ?)

  1419:15  0 (_ # _ _)

./guix/store.scm:1419:15: ERROR:
  1. :
  message: 
"`/gnu/store/0iii8i1lc4wg3wccs1db7y7d8lg80i04-guix-1.3.0/bin/guix 
substitute' died unexpectedly"

  status: 1
guix pull: error: You found a bug: the program 
'/gnu/store/42s1sikdv0xhv3rxshks8bz4f05a3jg7-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"95d44c0586873d79e897e1f84f7644bdd4696a58"; system: "x86_64-linux";

host version: "1.3.0"; pull-version: 1).



OpenPGP_0x1A87642CDE11C51C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58770: guix pull: error: You found a bug: the program '/gnu/store/9kyha1l1a1ynh9nni8428bqdanajck1b-compute-guix-derivation'

[Mark Felt]

I'm trying to build/use Guix as a package manager on top of the Linux
distribution (container) provided by Chrome OS:
https://chromeos.dev/en/linux

All I do to get the error is:

   1. install Guix from the distro's package manager
   2. run 'guix pull' (which doesn't complete because of the error.)


Specific Device Information:
rustdog@penguin:~$ uname -a
Linux penguin 5.10.136-19393-g8d1faf8b57d7 #1 SMP PREEMPT Wed Oct 5
03:09:18 PDT 2022 aarch64 GNU/Linux

Guix package info for the Linux system:
rustdog@penguin:~$ sudo apt info guix
Package: guix
Version: 1.2.0-4
Priority: optional
Section: admin
Maintainer: Vagrant Cascadian 
Installed-Size: 271 MB
Depends: guile-2.2-libs, libbz2-1.0, libc6 (>= 2.28), libgcc-s1 (>= 3.0),
libgcrypt20 (>= 1.8.0), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 5.2),
zlib1g (>= 1:1.2.6), guile-2.2, guile-gcrypt (>= 0.3.0-3~), guile-git (>=
0.4.0-2~), guile-gnutls (>= 3.6.15-5~), guile-json (>= 4.3.2), guile-lzlib,
guile-ssh (>= 0.13.1), guile-sqlite3 (>= 0.1.3-2~), guile-zlib, libssh-dev
Recommends: nscd, systemd
Homepage: https://guix.gnu.org/
Download-Size: 41.8 MB
APT-Manual-Installed: yes
APT-Sources: https://deb.debian.org/debian bullseye/main arm64 Packages
Description: GNU Guix functional package manager
 Guix is an advanced distribution of the GNU operating system
 developed by the GNU Project—which respects the freedom of computer
 users.
 .
 Guix supports transactional upgrades and roll-backs, unprivileged
 package management, and more. When used as a standalone distribution,
 Guix supports declarative system configuration for transparent and
 reproducible operating systems.
 .
 It provides Guile Scheme APIs, including high-level embedded
 domain-specific languages (EDSLs) to define packages and whole-system
 configurations.



On Tue, Oct 25, 2022, 6:51 AM Christopher Baines  wrote:

>
> Mark Felt  writes:
>
> > building /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv...
> > | 'build' phasebuilder for
> `/gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv' failed with
> exit code 1
> > build of /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv
> failed
> > Backtrace:
> > View build log at
> '/var/log/guix/drvs/5s/1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv.bz2'.
>
> Hi Mark,
>
> It's not obvious to me why the build of gnutls failed from the log.
>
> It has been built by a substitute server, so providing you're fetching
> substitutes from bordeaux.guix.gnu.org, you shouldn't have to build this
> locally.
>
> Chris
>

bug#58838: Bug report

[EricR Rasmussen]

~ $ guix pull
Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to d520fde (521 new
commits)...
Updating channel 'nonguix' from Git repository at '
https://gitlab.com/nonguix/nonguix'...
Authenticating channel 'nonguix', commits 897c1a4 to 7c26b20 (4 new
commits)...
Building from these channels:
  nonguix   https://gitlab.com/nonguix/nonguix 7c26b20
  guix  https://git.savannah.gnu.org/git/guix.git d520fde
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
100.0%
 config.scm  501B

  12KiB/s 00:00 [##] 100.0%
 git.scm  101B

  161KiB/s 00:00 [##] 100.0%
 hash.scm  130B

   5KiB/s 00:00 [##] 100.0%
 module-import  2KiB

  374KiB/s 00:00 [##] 100.0%
 module-import  2KiB

  440KiB/s 00:00 [##] 100.0%
 module-import-compiled  1.2MiB

 1.2MiB/s 00:01 [##] 100.0%
 module-import-compiled  1.2MiB

 2.9MiB/s 00:00 [##] 100.0%
building
/gnu/store/rcg9m4djxv9jbn6gf68xhm3glg7nznn6-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... |Backtrace:
  17 (primitive-load
"/gnu/store/kiiasri3ygd4c6k3r9ljyf0m2mcnidhs-compute-guix-derivation")
In ice-9/eval.scm:
155:9 16 (_ _)
159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 14 (with-fluid* _ _ _)
152:2 13 (with-fluid* _ _ _)
In ./guix/store.scm:
  2170:24 12 (run-with-store #
# ?)
   1998:8 11 (_ #)
In ./guix/gexp.scm:
   299:22 10 (_ #)
   1180:2  9 (_ #)
   1046:2  8 (_ #)
892:4  7 (_ #)
In ./guix/store.scm:
  2055:12  6 (_ #)
   1403:5  5 (map/accumulate-builds #
# ?)
  1419:15  4 (_ #
("/gnu/store/j48v18vdw9zmgp2grdk5xdkylh8zzy2l-guile-ssh-?" ?) ?)
  1419:15  3 (loop #f)
   713:11  2 (process-stderr # _)
In ./guix/serialization.scm:
   102:11  1 (read-int #)
 80:6  0 (get-bytevector-n* # 8)

./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
ERROR:
  1. :
  file: #f
  port: #
guix pull: error: You found a bug: the program
'/gnu/store/kiiasri3ygd4c6k3r9ljyf0m2mcnidhs-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"d520fdec3c7a11bc70ab83d0ebc6372389992d04"; system: "x86_64-linux";
host version: "3734857fc55df2c599c2fe5cc4ae49f5d47879fc"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#28240: bad backtrace on “guix archive -x”

[zimoun]

Hi Ricardo,

On Thu, 27 Oct 2022 at 13:30, Ricardo Wurmus  wrote:
> zimoun  writes:
>
>>> guix archive: error: corrupt input while restoring '/tmp/ci' from #>> file 0>
>>
>> The situation is still the same.  Well, is the “guix archive” error the
>> point of this bug report?
>
> The point is the terrible backtrace.  While this error is a little
> better it’s also not great.

About lzip, the error is catched by call-with-error-handling (guix ui),

--8<---cut here---start->8---
 ((nar-error? c)
  (let ((file (nar-error-file c))
(port (nar-error-port c)))
(if file
(leave (G_ "corrupt input while restoring '~a' from ~s~%")
   file (or (port-filename* port) port))
(leave (G_ "corrupt input while restoring archive from 
~s~%")
   (or (port-filename* port) port)
--8<---cut here---end--->8---


> But my primary concern is to prevent ’guix archive’ from printing a bad
> backtrace.  Doesn’t matter what we feed it.

In the case of gzip,

--8<---cut here---start->8---
Backtrace:
  12 (primitive-load "/home/simon/.config/guix/current/bin/guix")
In guix/ui.scm:
   2263:7 11 (run-guix . _)
  2226:10 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/status.scm:
835:3  8 (_)
815:4  7 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   656:37  5 (thunk)
   1295:8  4 (call-with-build-handler # …)
In guix/serialization.scm:
   416:21  3 (fold-archive # …)
In unknown file:
   2 (utf8->string #vu8(0 3 236 189 13 120 92 87 121 46 58 182 147 96 
13 73 228 144 244 212 64 40 59 # …))
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:
Throw to key `decoding-error' with args `("scm_from_utf8_stringn" "input locale 
conversion error" 0 #vu8
--8<---cut here---end--->8---

the error is incorrectly handled.  If I read correctly, the handled
errors are,

  (guard* (c ((package-input-error? c)
  ((package-cross-build-system-error? c)
  ((gexp-input-error? c)
  ((profile-not-found-error? c)
  ((missing-generation-error? c)
  ((unmatched-pattern-error? c)
  ((profile-collision-error? c)
  ((nar-error? c)
  ((store-connection-error? c)
  ((store-protocol-error? c)
  ((derivation-missing-output-error? c)
  ((file-search-error? c)
  ((invoke-error? c)
   ((formatted-message? c)
   ((message-condition? c)

so this ’decoding-error’ is not handled earlier.  Well, the only catch
of ’decoding-error’ is by maybe-utf8->string from (guix status).


Cheers,
simon

bug#25752: go incremental builds broken

[zimoun]

Hi,

On Thu, 27 Oct 2022 at 12:21, Maxime Devos  wrote:

> A reproducer was given in
> :
>
> guix environment --ad-hoc go -- bash -c 'export t=$(mktemp -d); cd
> $t && export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go install cmd/go; cd
> && rm -rf $t'

--8<---cut here---start->8---
$ guix shell -C go bash coreutils -- bash -c 'export t=$(mktemp -d); cd $t && 
export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go install cmd/go; cd && echo $t'
[...]

# runtime/cgo
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH
/tmp/tmp.srzPbcMLCc

$ guix shell -C go bash coreutils gcc-toolchain -- bash -c 'export t=$(mktemp 
-d); cd $t && export GOPATH=$(pwd) GOBIN=$(pwd)/bin && go install cmd/go; cd && 
echo $t'
[...]

go install cmd/go: copying /tmp/go-build1675975230/b001/exe/a.out: open 
/gnu/store/82adn4rx1h5fc7zms5g0ymwr8dk060nh-go-1.19.1/lib/go/bin/go: read-only 
file system
/tmp/tmp.qOfxzeZDxH
--8<---cut here---end--->8---

Well, as I am not a Go user, what is the expected result of the command?


Efraim commented:

I actually spent a bit of time on this today/yesterday. I
modified the go-build-system to copy the pkg and src folders
from build to build (instead of just the src folders) and the
pkg folders were ignored.  Upstream documentation isn't clear
about when the pkg folder is used and when it is ignored.





Cheers,
simon

bug#58802: On guix pull: failed to compute the derivation for Guix (ERROR: In procedure %resolve-variable:)

[zimoun]

Hi,

On Wed, 26 Oct 2022 at 19:07, Wiktor Żelazny  wrote:
> --8<---cut here---start->8---
>
> Updating channel 'guix-wz' from Git repository at 
> 'file:///home/w/guix/guix-wz-git'...
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from these channels:
>   guix  https://git.savannah.gnu.org/git/guix.git c07b55e
>   guix-wz   file:///home/w/guix/guix-wz-git   ca5b233

[...]

> ERROR: In procedure %resolve-variable:
> error: #{\x0;\x0;\x0;\x0}#: unbound variable
> Computing Guix derivation for 'x86_64-linux'...  guix pull: error: You found 
> a bug: the program 
> '/gnu/store/gfp2fp64pva2skb4iqdjzwfyns4ghyzl-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652"; system: "x86_64-linux";
> host version: "86ec52f66735b122b9035eba56516fd16f3be958"; pull-version: 1).
> Please report the COMPLETE output above by email to .
>
> --8<---cut here---end--->8---

Using Guix 00ff6f7 and running,

--8<---cut here---start->8---
$ guix time-machine --commit=86ec52f66735b122b9035eba56516fd16f3be958 \
 -- time-machine --commit=c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 \
 -- help
--8<---cut here---end--->8---

then it works for me.


Cheers,
simon

bug#27515: Closing old bugs

[Nicolas Graves via Bug reports for GNU Guix]

This bug report is outdated as there is no package texlive-texmf-minimal
anymore. 

-- 
Best regards,
Nicolas Graves