bug#72967: PHP not building

[Rutherther via Bug reports for GNU Guix]

I am sorry, I forgot to put in the number of the issue, here it is #72943

bug#72968: [PATCH] gnu: php: Fix build.

[Rutherther via Bug reports for GNU Guix]

Hello Noé,

thanks for your patch. Unfortunately, I don't think this is the
way to go. The issue here is that gd package has these in Requires.private
in the pkg-config file. That means every package that wants libgd
also has to get these inputs. Not only php. So gd has to be fixed here.
See issue #72943 where I sent a patch to make gd propagated inputs
and Carlo Zancanaro proposed returning code that was mistakenly
removed as part of core-updates.

The other part are the tests, where I think we should look into why they
are failing, and figure out if there is any issue in Guix or not
rather than removing them without investigating the cause.

Regards,
Ruther

bug#72967: PHP not building

[Rutherther via Bug reports for GNU Guix]

Hello Andreas,

the main problem is a removed patch inside of core-updates.
See this issue #

A separate problem is that three tests, related to gd,
are not passing.

As a temporary workaround, you can use the attached code to obtain a
buildable php.

Regards,
Rutherther

---
(use-modules
 (guix packages)
 (gnu packages gd)
 (gnu packages php))

(define gd-fixed
  (package/inherit gd
(name "gd-fixed")
(propagated-inputs
 (package-inputs gd

(define php
  (package/inherit php
(inputs (modify-inputs (package-inputs php)
  (replace "gd" gd-fixed)

php

bug#57109: arm-none-eabi-toolchain atomic support is broken

[Rutherther via Bug reports for GNU Guix]

> Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix  
> writes:
> 
> > The following works though. No newlib or anything:
> >
> > guix shell --expression='((@ (gnu packages cross-base) cross-gcc) 
> > "arm-none-eabi")' -- \
> >bash -c "echo '#include ' \
> >  | arm-none-eabi-gcc -x c -o /dev/null -c -"
> >
> >
> > —
> > Jean-Pierre De Jesus DIAZ
> >

The reason this works is that the stdatomic.h is used from gcc itself,
instead of the stdatomic.h coming from newlib. It works even with the
arm-none-eabi gcc's coming from `gnu packages embedded`.

The newlib one seems to be broken, though I am unable to find any
discussion on newlib's part. I've tried toolchain coming from
developer.arm.com directly (through nixpkgs that packages the binaries)
and found out that they use stdatomic.h coming from gcc even in full toolchain.

The problem in the Guix ones is that since those use
CROSS_C_INCLUDE_PATH. The paths here get priority to the ones coming from gcc
itself. This then means the newlib stdatomic.h shadows the one coming
from (arm-none-eabi-)gcc:lib.

The toolchain from developer.arm.com does not have this issue, since it
relies on the paths directly from gcc, having the one with newlib as
last. When I try directly including stdatomic.h from newlib, I also
get this error even with that toolchain.

A solution could be to prepend the include path from gcc:lib into the
CROSS_C_INCLUDE_PATH to make it take priority, and prefer the packages
coming from there, or to stop relying on the env vars.

See the toolchain from Nix, the one not using env vars:
```
#include <...> search starts here:
 
/nix/store/v9njly0h3i308dgyxzcqb6lqf71q8mkl-gcc-arm-embedded-12.3.rel1/bin/../lib/gcc/arm-none-eabi/12.3.1/include
 
/nix/store/v9njly0h3i308dgyxzcqb6lqf71q8mkl-gcc-arm-embedded-12.3.rel1/bin/../lib/gcc/arm-none-eabi/12.3.1/include-fixed
 
/nix/store/v9njly0h3i308dgyxzcqb6lqf71q8mkl-gcc-arm-embedded-12.3.rel1/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/include
```

See Guix one:
```
#include <...> search starts here:
 /gnu/store/h5jxagsf8236ff3lbfcd4yk1qhk2bs4p-profile/arm-none-eabi/include
 
/gnu/store/pjc5ysriqs6w99ihkza7xgwm8clfpgp0-gcc-cross-sans-libc-arm-none-eabi-7-2018-q2-update-1.261907-lib/lib/gcc/arm-none-eabi/7.3.1/include
 
/gnu/store/pjc5ysriqs6w99ihkza7xgwm8clfpgp0-gcc-cross-sans-libc-arm-none-eabi-7-2018-q2-update-1.261907-lib/lib/gcc/arm-none-eabi/7.3.1/include-fixed
```

Regards,
Rutherther

bug#72333: Magit/Transient error message

[Rutherther via Bug reports for GNU Guix]

>From Liliana dmarie Prikler:
> It is a bug unique to our handling in Guix – upstream uses hashes to
> guard against it, but those break grafts.

Do we need to remove the whole hash? The path hash would definitely
break grafts, but why should the content hash break grafts? Having the
content hash would also solve this issue.

Here is the upstream explanation for the hash
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/comp.c?h=194a8f5c1406dd7e762376bdfde78d1b7d01b6b1#n4433
having two parts, path and content hash.

Regards,
Rutherther

bug#73214: swaylock-1.8.0 build failure

[Rutherther via Bug reports for GNU Guix]

Hello,

better solution is to use pam, and we resolved how
in the #guix IRC channel. But for completion, to fix
swaylock/no-pam, libxcrypt has to be added, see:

---
(use-modules
 (guix packages)
 (gnu packages crypto)
 (gnu packages wm))

(define-public swaylock/no-pam
(package
(inherit swaylock)
(name "swaylock-no-pam")
(inputs
 (modify-inputs (package-inputs swaylock)
   (delete "linux-pam")
   (append libxcrypt)

swaylock/no-pam

bug#73276: guix pull --no-substitutes never finishes, gcc-mesboot1-4.6.4.drv

[Rutherther via Bug reports for GNU Guix]

Hello Zelphir,

> 
> I first ran guix pull, which led to an error:
> 
> 
> ... (many lines of logs about downloading packages and so on) ...
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%guix 
> substitute: error: TLS error in procedure 'write_to_session_record_port': 
> Error in the push function.
> guix package: error: 
> `/gnu/store/438g5cz2l225d0zyhvzj3db3mjrkx8gn-guix-command substitute' died 
> unexpectedly
> 
> 
> Since I didn't know what else to do, I thought I would give the 
> --no-substitutes 
> a try. That does not run into an error, but simply seems to run forever:
>

Have you tried rerunning multiple times without this flag?
It could be just a single time error. Also you can try using just
one of the substitute servers. I have not encountered this error,
and unfortunately don't understand the cause.
But it's possible it's not linked directly to your specific config,
but rather to the network conditions or the conditions on the substitute
server.

> And at that build phase step of gcc-mesboot1 it is stuck forever.
> All the other steps finish rather quickly, but somehow that one
> ran for 2h and was still not finished. I cancelled it and ran the
> command again, after which the output looked like this:

It's not stuck forever, it just builds. The gcc packages can take
a long time, also depending on your hardware. It can also be important
what your --cores settings is set to, since if you are trying to build
this just on one core, it will also add additional time for the build.
You seem to be bootstrapping a lot from there, so even after gcc
mesboot1 will build it can still take a lot of time to get to the
end.

Regards,
Rutherther

bug#73304: Python in relocatable guix pack leads to wrong sys.path

[Rutherther via Bug reports for GNU Guix]

When I add both python and a python package (seems like any) to a
relocatable guix pack, the resulting python in the merged profile seems
to be broken. Specifically its `sys.path` contains missing paths.

To replicate:
```
mkdir -p /tmp/b && cd /tmp/b
tar xzvf $(guix pack -RR python python-pyflakes -S /profile=)`
```

Then try executing the python from merged profile, and see sys.path output
--8<---cut here---start->8---
./profile/bin/python3
>>> import sys
>>> print(sys.path)
['', 
'/tmp/b/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python310.zip', 
'/tmp/b/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python3.10', 
'/tmp/b/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python3.10/lib-dynload',
 
'/tmp/b/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python3.10/site-packages']
--8<---cut here---end--->8---

Now if you instead use the realpath of this python
--8<---cut here---start->8---
$(realpath ./profile/bin/python3)
>>> import sys
>>> print(sys.path)
['', 
'/tmp/b/gnu/store/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python310.zip',
 
'/tmp/b/gnu/store/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python3.10',
 
'/tmp/b/gnu/store/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python3.10/lib-dynload',
 
'/tmp/b/gnu/store/pwajwfiygrkmag8fm1wzn3cf362j7sri-python-3.10.7R/lib/python3.10/site-packages']
--8<---cut here---end--->8---

As can be observed, the first instance misses "gnu/store" in the path,
and instead points to a path that does not exist. I have not
investigated, at least not yet, where this discrepancy comes from.
I was not able to replicate this with anything else than relocatable
pack. So my guess would be something strange happens when making
bwrap/fakechroot etc.

Regards,
Rutherther

bug#73304: Python in relocatable guix pack leads to wrong sys.path

[Rutherther via Bug reports for GNU Guix]

As a workaround, the profile in gnu/store can be used instead
of the one exposed by -S symlink. Specifically, getting
`realpath ./profile` and using that as the profile instead
of `./profile` directly resolves the issue.

bug#73799: guix shell: error: symlink: File exists: "/bin/cc"

[Rutherther via Bug reports for GNU Guix]

Hey Marco,

that llvm.scm change is actually irrelevant to the problem. There
will never be cc in the llvm package itself before the condition.
It occurs prior to the profile merging.
There is no fhs in that case
so checking for /bin/cc does not make sense, moreover
it could pose a problem if one built without a sandbox
on a foreign distro. Then the package output could differ
because /bin/gcc or /bin/c++ exist.

As for the change in environment.scm, that is indeed
what causes the issue.
Since there is an if already, maybe it would make sense to
not introduce another condition statement, but to extend
the existing if?

Regards,
Rutherther

bug#73869: Cannot start EXWM without a display manager

[Rutherther via Bug reports for GNU Guix]

> If I add the startx service, the window manager is initialized but it does 
> not react to any keyboard or touchpad input.
>

Double check the startx you are starting is coming
from the service, and is not shadowed by another startx that
would come from other package like xinit. You can check that by
looking at the realpath of the executable you are executing
when you start startx. It should be under path with name
startx-wrapper, not under something else like xinit.


> I'm using this config for xorg:
>
> (service xorg-server-service-type)
> (set-xorg-configuration

Do not use set-xorg-configuration when using
startx-command-service-type. Instead, put the config
you had in set-xorg-configuration to startx-command-service-type.
set-xorg-configuration is specifically for a display manager
that comes with it.

> (xorg-configuration
> (keyboard-layout keyboard-layout)
> (extra-config
> '("Section \"InputClass\"\n"
> " Identifier \"libinput touchpad catchall\"\n"
> " Driver \"libinput\"\n"
> " MatchIsTouchpad \"on\"\n"
> " MatchDevicePath \"/dev/input/event*\"\n"
> " Option \"Tapping\" \"on\"\n"
> " Option \"TappingDrag\" \"on\"\n"
> " Option \"DisableWhileTyping\" \"on\"\n"
> "EndSection\n"
> "\n"
> "Section \"InputClass\"\n"
> " Identifier \"USB Mouse Pad USB Mouse Pad Mouse\"\n"
> " Driver \"libinput\"\n"
> " Option \"Middle Emulation\" \"on\"\n"
> " Option \"AccelSpeed\" \"1.0\""
> "EndSection\n"
> "\n"
> "Section \"Device\"\n"
> " Identifier \"Intel Graphics\"\n"
> " Driver \"intel\"\n"
> " Option \"TearFree\" \"True\"\n"
> " Option \"DRI\" \"2\"\n"
> " Option \"AccelMethod\" \"sna\"\n"
> "EndSection"
> "\n"
>
>  Original Message 
> On Oct 19, 2024, 09:15, Rutherther wrote:
>
>> That should be the minimal config, yes. You can pass the configuration to 
>> configure your keyboard layout and such. The config is very similar to 
>> gdm-service-type, but instead of giving out a display manager it gives out 
>> startx command that should be used, because it has proper paths to xorg 
>> modules, config... Oleander writes: > Hi Rutherther, > no, I haven't. Do I 
>> only need to add `(service startx-command-service-type)` to my services? > > 
>> Thank you! > >  Original Message  > On Oct 18, 2024, 22:30, 
>> Rutherther wrote: > >> Hello Oleander, so have you used the 
>> `startx-command-service-type` to get the proper startx command? Regards, 
>> Rutherther

bug#73869: Cannot start EXWM without a display manager

[Rutherther via Bug reports for GNU Guix]

Hello Oleander,

so have you used the `startx-command-service-type` to
get the proper startx command?

Regards,
Rutherther

bug#73869: Cannot start EXWM without a display manager

[Rutherther via Bug reports for GNU Guix]

That should be the minimal config, yes. You can pass
the configuration to configure your keyboard layout and such.
The config is very similar to gdm-service-type, but instead
of giving out a display manager it gives out startx command
that should be used, because it has proper paths to xorg
modules, config...

Oleander <7059...@protonmail.com> writes:

> Hi Rutherther,
> no, I haven't. Do I only need to add `(service startx-command-service-type)` 
> to my services?
>
> Thank you!
>
>  Original Message 
> On Oct 18, 2024, 22:30, Rutherther wrote:
>
>> Hello Oleander, so have you used the `startx-command-service-type` to get 
>> the proper startx command? Regards, Rutherther

bug#74089: Can't download libgcrypt source with Guix - Crysys.hu gnupg mirror strange behavior

[Rutherther via Bug reports for GNU Guix]

Hi,

currently I am unable to obtain libgcrypt source locally,
the first mirror artfiles.org gives 404, which is fine,
and is skipped. The second one also doesn't know about the file
(and upon looking at the page and links in it, I cannot find much
about it being a file mirror). The problem is that it doesn't give
out 404, but 200, with error message in body. This means guix thinks
it got the file, but all it got is a webpage. It then checks the
hash that doesn't match.

I am not sure what the best solution would be here - would it make
sense to move the mirror down in the list if it's behaving wrongly?
Is it still a mirror?

Regards,
Rutherther

bug#73304: Python in relocatable guix pack leads to wrong sys.path

[Rutherther via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Commit d5e0180805f52ef38a03ff9d6c11dd6174e3526b fixed a similar issue I
> think, discussed at .
>
> Not sure whether it’s a new problem here.  Konrad, Maxim, Josselin,
> WDYT? :-)

Hello Ludovic,

if I understand correctly this commit was merged to master with
the quite-recent core-updates merge? The experiment I did was
after this.

Moreover, I tried with newest master now to make sure,
and still the same behavior.

I will try to investigate this myself after I get some time (which may
be quite a while) if no one else will get to it until that time.

Regards,
Rutherther.

PS: sorry for the e-mail change, I recently set up self-hosted one, so
let's see how well it works with debbugs / your gnu.org address. :)

bug#73304: Python in relocatable guix pack leads to wrong sys.path

[Rutherther via Bug reports for GNU Guix]

> Hello,
>
> Konrad Hinsen  skribis:
>
>> Konrad Hinsen  writes:
>>
>>> I have changed my mind. In the sys.path outputs shown, there are no
>>> paths from add-on packages. It's just the Python standard library.
>>> Maybe our sitecustomize.py is not run at all, but if it is, it didn't do
>>> anything to sys.path. There must be a bug somewhere else.
>>
>> Our sitecustomize.py is indeed not run at all, so this definitely is a
>> different problem.
>>
>> Evidence: Run Rutherther's example, adding the -v option.  The long
>> output is attached, both for "./profile/bin/python3 -v" and "$(realpath
>> ./profile/bin/python3) -v". Search for "site-packages" to find the
>> interesting parts. If you don't use realpath, large parts of the
>> initialization are not done.
>>
>> There are lots of ../../ in the path shown in these log files. If Python
>> resolves them lexically, as the normpath function does, that would
>> probably explain most of these issues.

I am not sure I understand this right. I am looking at the output, and
it has `/tmp/b/profile/bin/../../hash-python-3.10.7R/{rest}`, omitting
the gnu/store even here. Why is it significant how these paths are
evaluated, if there is the gnu/store part missing already?

Regards,
Rutherther

bug#73304: Python in relocatable guix pack leads to wrong sys.path

[Rutherther via Bug reports for GNU Guix]

"Rutherther"  writes:

>> Hello,
>>
>> Konrad Hinsen  skribis:
>>
>>> Konrad Hinsen  writes:
>>>
 I have changed my mind. In the sys.path outputs shown, there are no
 paths from add-on packages. It's just the Python standard library.
 Maybe our sitecustomize.py is not run at all, but if it is, it didn't do
 anything to sys.path. There must be a bug somewhere else.
>>>
>>> Our sitecustomize.py is indeed not run at all, so this definitely is a
>>> different problem.
>>>
>>> Evidence: Run Rutherther's example, adding the -v option.  The long
>>> output is attached, both for "./profile/bin/python3 -v" and "$(realpath
>>> ./profile/bin/python3) -v". Search for "site-packages" to find the
>>> interesting parts. If you don't use realpath, large parts of the
>>> initialization are not done.
>>>
>>> There are lots of ../../ in the path shown in these log files. If Python
>>> resolves them lexically, as the normpath function does, that would
>>> probably explain most of these issues.
>
> I am not sure I understand this right. I am looking at the output, and
> it has `/tmp/b/profile/bin/../../hash-python-3.10.7R/{rest}`, omitting
> the gnu/store even here. Why is it significant how these paths are
> evaluated, if there is the gnu/store part missing already?
>
> Regards,
> Rutherther

Okay, I spent a bit of time on this, and I think I get it now.
This seems to boil down to something in Python wrongly handling
the argv0, where it looks at the path, being /tmp/a/profile/bin/python3,
substitutes the symlink 
/tmp/a/profile/bin/python3/../../hash-python-3.10.7/bin/python3, and then
probably calls something like normpath on it, and it becomes
/tmp/a/hash-python-3.10.7. Whereas the correct approach is to first get
the actual path /tmp/a/profile/bin/python3 is at, being
/tmp/a/gnu/store/hash-python-3.10.7R/bin/python3, and unwrap the symlink
from there. This happens even if python3 is called from PATH, I suppose
Python then looks through PATH and again finds the python3 file outside
of the store.

As a workaround,
diff --git a/gnu/packages/aux-files/run-in-namespace.c b/gnu/packages/aux-files/run-in-namespace.c
index 074befde46..5ce8032ed8 100644
--- a/gnu/packages/aux-files/run-in-namespace.c
+++ b/gnu/packages/aux-files/run-in-namespace.c
@@ -654,6 +654,11 @@ main (int argc, char *argv[])
   assert (size > 0);
   self[size] = '\0';
 
+  for (int i = 0; i < argc; i++) {
+printf("%s\n", argv[i]);
+  }
+  argv[0] = "@WRAPPED_PROGRAM@";
+
   /* SELF is something like "/home/ludo/.local/gnu/store/…-foo/bin/ls" and we
  want to extract "/home/ludo/.local/gnu/store".  */
   size_t index = strlen (self)
diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm
index 7f5a5f2aa7..f73d92b678 100644
--- a/guix/scripts/pack.scm
+++ b/guix/scripts/pack.scm
@@ -1343,7 +1343,20 @@ (define* (wrapped-package package
  (+ (string-length (%store-directory))
 1)
   (mkdir-p (dirname result))
-  (apply invoke #$compiler "-std=gnu99" "-static" "-Os" "-g0" "-Wall"
+  (call-with-output-file (string-append result ".comp")
+(lambda (port)
+  (format port
+  (apply string-append #$compiler "-std=gnu99" "-O0" "-g" "-Wall"
+ "run.c" "-o" result
+ (string-append "-DWRAPPER_PROGRAM=\""
+(canonicalize-path (dirname result)) "/"
+(basename result) "\"")
+ (append (if proot
+ (list (string-append "-DPROOT_PROGRAM=\""
+  proot "\""))
+ '())
+ (elf-loader-compile-flags program))) )))
+  (apply invoke #$compiler "-std=gnu99" "-O0" "-g" "-Wall"
  "run.c" "-o" result
  (string-append "-DWRAPPER_PROGRAM=\""
 (canonicalize-path (dirname result)) "/"
@@ -1353,6 +1366,7 @@ (define* (wrapped-package package
   proot "\""))
  '())
  (elf-loader-compile-flags program)))
+  (copy-file "run.c" (string-append result ".run.c"))
   (delete-file "run.c")))
 
   (setvbuf (current-output-port) 'line)

bug#76959: Empty Scheme files in system generation,

[Rutherther via Bug reports for GNU Guix]

Hello everyone,

so I noticed a new bug has been reported
in both #guix IRC channel and on debbugs (#77086).
This bug reports that filesystems are not
unmounted cleanly on reboot.

So I wanted to raise my concern that there isn't really
a bug which would make guix write zeros to files,
but that it's a corruption of files steming from the
filesystems not being unmounted cleanly.

I cannot really find anything that would make this
explanation implausible in this thread. Am I missing something?
Were you guys somehow able to actually *verify* it's guix writing zeros
and not the files getting corrupted afterwards?

If you reconfigure and then reboot right after, I think it's feasible
some of the data might not be written to the disk yet, and this is the
way most folks do it.

If there isn't currently a way to rule out this concern,
I think best course of action would be to get a reproducer
for this guix writing zeros if it's possible. I am not sure
if you kept the incorrect guix on your disks or removed everything
in which case it's probably impossible to get a reproducer.

Moreover if you remember that you got fsck, then I would treat
the cause being corrupted files by not properly unmounting as more
likely than the current explanation that guix is somehow writing empty
files.

Regards,
Rutherther

bug#77086: Filesystems not unmounted on reboot

[Rutherther via Bug reports for GNU Guix]

Hello guys,

so I started looking into this a bit (not promising any results though),
and I can pretty confidently say that there is indeed an issue in the
unmount.

I have created a VM system, tried rebooting a few times and it was fine,
however then I tried reconfiguring, and for that run I got an error upon
reboot. Not only that, I can't boot it anymore :) the filesystem got
corrupted in a way that prevents boots. Welp.

I can't really say at current moment what is causing this, but the
problem is that the root device is busy so it can't be unmounted.
I have a hypothesis given the log I see: that the root filesystem
is being unmounted first rather than last like it should be.
Could the reconfigure throw shepherd off? I am also CCing Ludovic,
I hope he won't mind.

I would like to also point out an e-mail in the
guix-devel sent recently that someone got a timer service running after
reconfigure, but not after reboot, where after reboot the timer module
is not imported by default unless put to service's modules, but after
reconfigure it works, so this leaves me with yet another point for the
impression that shepherd behaves differently on reboot as opposed to
reconfigure reload.

I will try digging more, but I am not that knowledgeable about
shepherd yet, so it will take longer time.

I am attaching both log (starting after reboot command)
and the configuration used for the vm.

[ 2532.130331] shepherd[1]: Terminating system log service.
[ 2532.138540] shepherd[1]: Service system-log stopped.
[ 2532.145581] shepherd[1]: Service system-log is now stopped.
[ 2532.149364] shepherd[1]: Closing 4 system log ports.
[ 2532.151578] shepherd[1]: Service term-console is not running.
[ 2532.154795] shepherd[1]: Service term-tty1 is not running.
[ 2532.159702] shepherd[1]: Service term-tty2 is not running.
[ 2532.165720] shepherd[1]: Service term-tty3 is not running.
[ 2532.174412] shepherd[1]: Service term-tty4 is not running.
[ 2532.176655] shepherd[1]: Service term-tty5 is not running.
[ 2532.179148] shepherd[1]: Service term-tty6 is not running.
[ 2532.182485] shepherd[1]: Stopping service loopback...
[ 2532.194841] shepherd[1]: Registering new logger for loopback.
[ 2532.245307] shepherd[1]: Service loopback might have failed to stop.
[ 2532.247610] shepherd[1]: Service loopback is now stopped.
[ 2532.257829] shepherd[1]: Stopping service guix-daemon...
[ 2532.262768] shepherd[1]: Service guix-daemon stopped.
[ 2532.269632] shepherd[1]: Service guix-daemon is now stopped.
[ 2532.274953] shepherd[1]: Stopping service timer...
[ 2532.277806] shepherd[1]: Service timer stopped.
[ 2532.279442] shepherd[1]: Service timer is now stopped.
[ 2532.283475] shepherd[1]: Stopping service transient...
[ 2532.287844] shepherd[1]: Service transient stopped.
[ 2532.28] shepherd[1]: Service transient is now stopped.
[ 2532.293995] shepherd[1]: Stopping service log-cleanup...
[ 2532.297223] shepherd[1]: Terminating timer 'log-cleanup' with 0 processes 
running.
[ 2532.300247] shepherd[1]: Service log-cleanup stopped.
[ 2532.301978] shepherd[1]: Service log-cleanup is now stopped.
[ 2532.306241] shepherd[1]: Stopping service user-processes...
[ 2532.311358] shepherd[1]: sending all processes the TERM signal
[ 2532.315239] shepherd[1]: Service udev has been disabled.
[ 2536.356551] shepherd[1]: all processes have been terminated
[ 2536.365466] shepherd[1]: Service user-processes stopped.
[ 2536.374333] shepherd[1]: Service user-processes is now stopped.
[ 2536.378815] shepherd[1]: Stopping service urandom-seed...
[ 2536.386166] shepherd[1]: Service urandom-seed might have failed to stop.
[ 2536.389012] shepherd[1]: Service urandom-seed is now stopped.
[ 2536.391950] shepherd[1]: Service guix-daemon is not running.
[ 2536.399246] shepherd[1]: Service nscd is not running.
[ 2536.402536] shepherd[1]: Stopping service log-rotation...
[ 2536.408077] shepherd[1]: Terminating timer 'log-rotation' with 0 processes 
running.
[ 2536.412356] shepherd[1]: Service log-rotation stopped.
[ 2536.415228] shepherd[1]: Service log-rotation is now stopped.
[ 2536.418957] shepherd[1]: Service timer is not running.
[ 2536.426109] shepherd[1]: Service transient is not running.
[ 2536.429836] shepherd[1]: Service log-cleanup is not running.
[ 2536.436242] shepherd[1]: Service udev is not running.
[ 2536.439446] shepherd[1]: Service pam is not running.
[ 2536.444939] shepherd[1]: Service user-processes is not running.
[ 2536.449993] shepherd[1]: Stopping service file-systems...
[ 2536.454141] shepherd[1]: Service file-systems stopped.
[ 2536.457264] shepherd[1]: Service file-systems is now stopped.
[ 2536.462044] shepherd[1]: Stopping service file-system-/var/lib/gdm...
[ 2536.469161] shepherd[1]: Service file-system-/var/lib/gdm stopped.
[ 2536.477353] shepherd[1]: Service file-system-/var/lib/gdm is now stopped.
[ 2536.482038] shepherd[1]: Stopping service 
file-system-/var/cache/fontconfig...
[ 2536.489787] shepherd[1]: Service file-system-/var/cac

bug#77086: Filesystems not unmounted on reboot

[Rutherther via Bug reports for GNU Guix]

Hello,

I was testing on commmit Ian sent to reproduce, and now moved to
newest guix, seems to have been solved (at least the specific error I
was getting),
possibly by shepherd 1.0.3 update.

With newest guix both the first reconfigure of guix system image
and subsequent ones are fine.

Let me know if you're still experiencing this issue after updating
and I might try harder to reproduce if I got a different issue on first
try. I am afraid this will be hard to debug on real hw as you don't
really get the log in /var/log/messages for shutting down the system, I
had to get it through a serial line via stdout of qemu.

Also I was able to reproduce the issue on the older
guix just by running the shepherd services upgrade scm script,
no need for full reconfigure, this shows that something has gone
wrong when shepherd was reloading the services. Do we have some kind of
a test for this in guix / shepherd so it can't happen anymore in the future?

bug#76959: Empty Scheme files in system generation,

[Rutherther via Bug reports for GNU Guix]

Hi again,

"Rutherther"  writes:

>
> If you reconfigure and then reboot right after, I think it's feasible
> some of the data might not be written to the disk yet, and this is the
> way most folks do it.

So, I was trying out in a VM because of the issue #77086 and
I actually have got this empty derivation error during that.

And I am pretty confident the cause for me has been what I decribed
here:
1. reconfigure successfully completes, nothing is corrupted
2. user reboots
3. the reboot doesn't properly commit data to the disk because root file
system is not unmounted cleanly
4. the user boots, gets fsck and the files are corrupted, from step 3

How I made sure of this is: I have a qcow image and I started two times
from the same image, both times first reconfiguring to same
configuration.scm file. After the reconfigure, the steps differ

First time: reboot, got error with empty derivations and I can no longer
reconfigure, because what was corrupted is kexec reboot derivation.
Second time: guix gc --verify=contents, reporting no issues, reboot then.

The second time I didn't get these errors after booting again,
and I am pretty confident that is because of so many reads and time it
took to make them, the data were commited already.

I am able to consistently, with the same image and roughly same
timing (doing it manually) replicate the same issue multiple times.
Specifically I am getting corrupted
kexec-load-system derivation. But I don't think that matters much,
it's just something that has been written recently. What it will be
depends on the fs, on the timing, on other operations to the disk etc.

Conclusion: I see it as more likely you guys were affected by bug
#77086 (root fs is not cleanly unmounted), not that guix would
mysteriously write zeros.

If you see it otherwise, please let me know what led you to believe
otherwise.

Regards,
Rutherther

bug#77415: Native Messaging in librewolf doesn't work

[Rutherther via Bug reports for GNU Guix]

>> Okay, I was wrong. The problem is only when ICECAT_SYSTEM_DIR is unset.
>> When it's set to anywhere, like /, it works fine for me as well.
>
> Great!
>
> Closing :)

Should this really be closed? I think it's a bug that ought to be fixed.
Or at least the user's should get to know somehow they have to set it.
If user is not using any extensions via Guix, they won't be able to use
native messaging unless they know about this culprit.

bug#77415: Native Messaging in librewolf doesn't work

[Rutherther via Bug reports for GNU Guix]

Clément Lassieur  writes:

> On Mon, Apr 07 2025, Rutherther via Bug reports for GNU Guix wrote:
>
>> I think you've discovered the actual bug. The issue is that
>> .librewolf/native-messaging-hosts is not checked, instead
>> ICECAT_SYSTEM_DIR is, with no fallback even if it's empty. When I set
>> ICECAT_SYSTEM_DIR to $HOME/.librewolf all is working fine again.
>
> I don't think so, because on my computer,
>
> $HOME/.librewolf/native-messaging-hosts/passff.json
>
> works (without changing ICECAT_SYSTEM_DIR)
>
> and if I remove that file it doesn't work anymore.

>
> So just to make it clear: I can't reproduce the bug.

Okay, I was wrong. The problem is only when ICECAT_SYSTEM_DIR is unset.
When it's set to anywhere, like /, it works fine for me as well.

Regards,
Rutherther

bug#77415: Native Messaging in librewolf doesn't work

[Rutherther via Bug reports for GNU Guix]

Hello Konrad,

I would like to confirm the same behavior on my end. This happens with
every native messaging extension I tried, doesn't seem to be just some.
Actually, it used to work, then after something updated in Guix it
stopped working. The same for Firefox from nonguix.

I have no idea how to debug this since Firefox apparently decided to
print the most helpful message ever for any and every error in the
native hosting! Sigh. That's why I haven't even reported it, because I
wanted to share at least some information about it, but could find
nothing. My only other idea was to look through the librewolf
compilation log, maybe it will print a warning about a missing/wrong
dependency etc.

Regards,
Rutherther

bug#77415: Native Messaging in librewolf doesn't work

[Rutherther via Bug reports for GNU Guix]

Hi Clément,

Clément Lassieur  writes:

> Hi all,
>
> Did you try the guix passff-icecat package?
>
> $ guix shell icecat-minimal passff-icecat
> then you start icecat, and it works
>
> Same if you replace icecat-minimal with mullvadbrowser or torbrowser.
>
> With librewolf there is an extra step due to a librewolf package bug:
>
> $ guix shell librewolf passff-icecat
> then
> - you start librewolf
> - [extra step] you go to about:addons and enable passff
> - then it works
>
> As to why it does not work with your non-guix extension, I imagine it's
> because your native-messaging-hosts path is wrong?
>
> Did you try either
> - ~/.librewolf/native-messaging-hosts
> - $ICECAT_SYSTEM_DIR/native-messaging-hosts
>

I think you've discovered the actual bug. The issue is that
.librewolf/native-messaging-hosts is not checked, instead
ICECAT_SYSTEM_DIR is, with no fallback even if it's empty. When I set
ICECAT_SYSTEM_DIR to $HOME/.librewolf all is working fine again.

Since I use Guix Home to symlink the native messaging hosts json file
anyway, I will change it on my end and am happy with that, but I still
think it's a packaging bug.

Thanks,
Rutherther

> ?
>
> Cheers,
> Clément Lassieur
>
>
> On Mon, Mar 31 2025, Rutherther via Bug reports for GNU Guix wrote:
>
>> Hello Konrad,
>>
>> I would like to confirm the same behavior on my end. This happens with
>> every native messaging extension I tried, doesn't seem to be just some.
>> Actually, it used to work, then after something updated in Guix it
>> stopped working. The same for Firefox from nonguix.
>>
>> I have no idea how to debug this since Firefox apparently decided to
>> print the most helpful message ever for any and every error in the
>> native hosting! Sigh. That's why I haven't even reported it, because I
>> wanted to share at least some information about it, but could find
>> nothing. My only other idea was to look through the librewolf
>> compilation log, maybe it will print a warning about a missing/wrong
>> dependency etc.
>>
>> Regards,
>> Rutherther

bug#77086: Filesystems not unmounted on reboot

[Rutherther via Bug reports for GNU Guix]

Hi,

recently I switched from power-profiles-daemon to tlp. I am experiencing
this issue from time to time! I don't know the exact trigger nor am able
to 'reproduce' it, it happens just sometimes.
I wasn't experiencing this issue before.

This seems to me that tlp could be (one of the) trigger(s) of this bug, somehow.

I checked tlp's systemd service and it seems to be working the same way
the shepherd one does, so I don't really get why that would happen.

Ludovic Courtès  writes:

> Felix Lechner  skribis:
>
>> On Tue, Apr 01 2025, Ludovic Courtès wrote:
>>
>>> I believe I’m still experiencing it on my laptop
>>
>> Unmounting properly is great, but would it also make sense to add a call
>> to sync(2) after a reconfigure since some people reboot quickly?
>
> The ‘root-file-system’ service calls ‘sync’ when shutting down.

Why then are people ending up with corrupt store, I don't really get it.
Is sync really doing full sync to the disk? Shepherd doesn't shutdown
the system until the service stops, successfully or not, right? So it
should be called on every shutdown/reboot.

Regards,
Rutherther

bug#78152: [guix-daemon] Build user's pw_dir != HOME

[Rutherther via Bug reports for GNU Guix]

Hi,

imo the latter approach is better, because the advantage of using
/homeless-shelter is that you can clearly see it in error log if the
package you're building tries to use the HOME. If it was just /, we
would lose the ability to tell why the package chose to access something
under root of the filesystem - is it accessing a hard coded path or
accessing $HOME?

bug#67707: Fresh installation leaks details about ISO build environment

[Rutherther via Bug reports for GNU Guix]

Hi Ludo',

> That the URL is wrong doesn’t have any impact because it’s not used by
> ‘guix pull’ or anything, but it’s obviously not great.

this is not exactly true. It might be used, by the forward update check
on guix system reconfigure.
When the user hasn't pulled yet, they don't have any checkout, and a new
one is being created by looking at the folder
/home/ludo/src/guix/version/... That will end up with an error.

Maybe the installation-os should not use (current-guix) as that can lead
to issues like this? Could we instead just detect the commit and change
the url to the savannah/codeberg one?
Or will it just be ensured next time that the channels used to build it
point to the hosting url and not at a local one?

Regards
Rutherther

bug#67707: Fresh installation leaks details about ISO build environment

[Rutherther via Bug reports for GNU Guix]

Hi Ludo',

Ludovic Courtès  writes:

> Hi,
>
> Rutherther via Bug reports for GNU Guix  writes:
>
>> What I had in mind in the first place was replacing it just in the
>> install.scm, I didn't even think about changing it here.
>
> Oh right, it’s probably best to change it there.  Something like this?

Yes, that is exactly what I had in mind. Btw I am wondering, is there a
policy on (not) updating the released iso?

>
> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
> index 15ea401f1c..50320a6698 100644
> --- a/gnu/system/install.scm
> +++ b/gnu/system/install.scm
> @@ -35,6 +35,11 @@ (define-module (gnu system install)
>#:use-module ((guix packages) #:select (package-version 
> supported-package?))
>#:use-module (guix platform)
>#:use-module (guix utils)
> +  #:use-module (guix packages)
> +  #:use-module ((guix channels)
> +#:select (%default-guix-channel
> +  channel
> +  channel-commit))
>#:use-module (gnu installer)
>#:use-module (gnu system locale)
>#:use-module (gnu services avahi)
> @@ -392,7 +397,13 @@ (define* (%installation-services #:key (system (or (and=>
>  
>   ;; Install and run the current Guix rather than an older
>   ;; snapshot.
> - (guix (current-guix
> + (guix (let ((guix (current-guix)))
> + (package
> +   (inherit guix)
> +   (source (channel
> +(inherit %default-guix-channel)
> +(commit (channel-commit
> + (package-source 
> guix))
>  
> ;; Start udev so that useful device nodes are available.
> ;; Use device-mapper rules for cryptsetup & co; enable the CRDA 
> for
>
>
>> Related to this issue, I am playing with an idea to introduce a new
>> option to guix system reconfigure that would skip the forward update
>> check. While it makes sense, especially lately it shows how problematic
>> it can get. […]
>
> I’m not sure I follow: even if one uses a mirror of Savannah, downgrade
> prevention works fine.  Or are you referring to some other motivation?

I agree that the prevention works fine even with a mirror. What I wanted
to say is that sometimes it can't work. Like if a repository hosting is
down or you don't have internet connection. That is, if the checkout
(usually the one of root) doesn't contain the commit. Lately, it shows
because savannah is down very often. So one pulls successfully, but then
can't reconfigure, because savannah is down again. This is because root
has a separate checkout. Even if it didn't, if the checkouts are
removed, the user can't reconfigure if repo hosting is down.
This just feels like an unnecessary limitation - why not allow the user
to say: yes, this is a forward update, don't check,
ie. --disable-forward-update-check.

Workaround for savannah being down is to use a mirror. Thankfully the
check uses the currently configured source of the repository, so just
pulling out of the mirror, and then reconfiguring works.

Thanks
Rutherther

bug#67707: Fresh installation leaks details about ISO build environment

[Rutherther via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

>
> Rutherther  writes:
>
>>> That the URL is wrong doesn’t have any impact because it’s not used by
>>> ‘guix pull’ or anything, but it’s obviously not great.
>>
>> this is not exactly true. It might be used, by the forward update check
>> on guix system reconfigure.
>> When the user hasn't pulled yet, they don't have any checkout, and a new
>> one is being created by looking at the folder
>> /home/ludo/src/guix/version/... That will end up with an error.
>
> True.
>
>> Maybe the installation-os should not use (current-guix) as that can lead
>> to issues like this? Could we instead just detect the commit and change
>> the url to the savannah/codeberg one?
>> Or will it just be ensured next time that the channels used to build it
>> point to the hosting url and not at a local one?
>
> I think so.  It should be as simple as this:
>
> diff --git a/gnu/packages/package-management.scm 
> b/gnu/packages/package-management.scm
> index f0a9b39e25..46cf9b8512 100644
> --- a/gnu/packages/package-management.scm
> +++ b/gnu/packages/package-management.scm
> @@ -1,5 +1,5 @@
>  ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2013-2024 Ludovic Courtès 
> +;;; Copyright © 2013-2025 Ludovic Courtès 
>  ;;; Copyright © 2015, 2017, 2020, 2021, 2022, 2023 Ricardo Wurmus 
> 
>  ;;; Copyright © 2017 Muriithi Frederick Muriuki 
>  ;;; Copyright © 2017, 2018 Oleg Pykhalov 
> @@ -673,7 +673,8 @@ (define-public current-guix-package
>  ((? channel? source)
>   (package
> (inherit guix)
> -   (source source)
> +   (source (channel (inherit %default-guix-channel)
> +(commit (channel-commit source
> (build-system channel-build-system)
> (inputs '())
> (native-inputs '())
>
> Maybe there are cases where it’s not desirable (someone maintaining a
> fork for example), but those are hypothetical edge cases.
>
> WDYT?

What I had in mind in the first place was replacing it just in the
install.scm, I didn't even think about changing it here.

I don't know, it feels a bit icky. This might be a good default - one
commonly uses (current-guix) for putting to virtual machines and you
don't want to end up with a local folder there. On the other hand,
there are cases when you do want the same channels and will get more
complicated with this change since one will have to get to know
repository->guix-channel and current-source-directory. What about making
two procedures, one that replaces with the default channel url and one
that doesn't?

Btw given the current state of things, I think this is quite 'dangerous'
as savannah is commonly failing, and people using (current-guix) end up
with it. This will hopefully be resolved in the future (either by switch
to codeberg or hopefully savannah will get better), but if this was
merged now I think it can cause more confusion.

Related to this issue, I am playing with an idea to introduce a new
option to guix system reconfigure that would skip the forward update
check. While it makes sense, especially lately it shows how problematic
it can get. There are people who cannot reconfigure because they have
savannah in their channels, they first have to pull from codeberg, and
even that is just a workaround (thankfully the forward update check will
use the repository you currently have configured instead of the older
one). This could happen even with other channels, not just guix.
Additionally it's also not so good for virtual machines where you
are just quickly testing something, and have to wait for a full checkout
fetch just because you decided to reconfigure. (maybe if the commit is
the same one as the old one there should be an additional check so that
nothing is fetched in the first place)

Thanks
Rutherther

bug#74089: Closing, as it has been removed.

[Rutherther via Bug reports for GNU Guix]

crysys.hu has been removed.

bug#77086: Filesystems not unmounted on reboot

[Rutherther via Bug reports for GNU Guix]

Hello guys,

I am writing with an update, because not everything I wrote in the first
e-mail was true exactly. Please let me know if updates distrub you and I
won't be CCing you again.

"Rutherther"  writes:

>
> I have created a VM system, tried rebooting a few times and it was fine,
> however then I tried reconfiguring, and for that run I got an error upon
> reboot. Not only that, I can't boot it anymore :) the filesystem got
> corrupted in a way that prevents boots. Welp.

This wasn't the case, I just haven't realized the correct partition to
boot from is /dev/vda2, not /dev/vda1, I copied the image from guix repo
and haven't realized it's wrong (I suppose it haven't used efi before,
but switched to it?). Since the images get the FS replaced by custom
partitions, this error was visible only after reconfigure. After
changing it to /dev/vda2 I am able to boot, but fsck is ran to repair
damage done.

>
> I am attaching both log (starting after reboot command)
> and the configuration used for the vm.
>

Since this was the first reconfigure after the system obtained by guix
system image, the log isn't exactly accurate to what would happen on
subsequent reconfigures.

The previous time the error was that / is busy. Maybe it was because of a
change in the filesystem services from the initial image to custom
config with `file-systems`
While that is definitely an issue as well, it might not be completely
related to the issue reported here by others. (imo there should be a way
for cases where the user is making big changes like changing file
systems to tell reconfigure to not apply it to the running system, to
only apply the bootloader and switch only after boot)

I am attaching log of reboot/halt after subsequent reconfigures where
the issue is manifested a bit differently. It is not / that would be
busy, but /run/user that is busy. I still think it could be because of
wrong order of stopping services, /run/user/0 is unmounted last,
but root file system tries to be unmounted prior to that.

Note that this doesn't happen without a reconfigure, I get this behavior
only after a reconfigure. The reconfigure can happen with no changes to
the config nor guix instance ran. I get this behavior consistently
on every reconfigure ran!

[  202.675565] shepherd[1]: Ignoring error while stopping root-file-system: 
(system-error "umount" "~S: ~A" ("/run/user" "Device or resource busy") (16))

Regards,
and apologies for two messages when it could've been one if I paid
more attention.
Rutherther

[ 2532.130331] shepherd[1]: Terminating system log service.
[ 2532.138540] shepherd[1]: Service system-log stopped.
[ 2532.145581] shepherd[1]: Service system-log is now stopped.
[ 2532.149364] shepherd[1]: Closing 4 system log ports.
[ 2532.151578] shepherd[1]: Service term-console is not running.
[ 2532.154795] shepherd[1]: Service term-tty1 is not running.
[ 2532.159702] shepherd[1]: Service term-tty2 is not running.
[ 2532.165720] shepherd[1]: Service term-tty3 is not running.
[ 2532.174412] shepherd[1]: Service term-tty4 is not running.
[ 2532.176655] shepherd[1]: Service term-tty5 is not running.
[ 2532.179148] shepherd[1]: Service term-tty6 is not running.
[ 2532.182485] shepherd[1]: Stopping service loopback...
[ 2532.194841] shepherd[1]: Registering new logger for loopback.
[ 2532.245307] shepherd[1]: Service loopback might have failed to stop.
[ 2532.247610] shepherd[1]: Service loopback is now stopped.
[ 2532.257829] shepherd[1]: Stopping service guix-daemon...
[ 2532.262768] shepherd[1]: Service guix-daemon stopped.
[ 2532.269632] shepherd[1]: Service guix-daemon is now stopped.
[ 2532.274953] shepherd[1]: Stopping service timer...
[ 2532.277806] shepherd[1]: Service timer stopped.
[ 2532.279442] shepherd[1]: Service timer is now stopped.
[ 2532.283475] shepherd[1]: Stopping service transient...
[ 2532.287844] shepherd[1]: Service transient stopped.
[ 2532.28] shepherd[1]: Service transient is now stopped.
[ 2532.293995] shepherd[1]: Stopping service log-cleanup...
[ 2532.297223] shepherd[1]: Terminating timer 'log-cleanup' with 0 processes 
running.
[ 2532.300247] shepherd[1]: Service log-cleanup stopped.
[ 2532.301978] shepherd[1]: Service log-cleanup is now stopped.
[ 2532.306241] shepherd[1]: Stopping service user-processes...
[ 2532.311358] shepherd[1]: sending all processes the TERM signal
[ 2532.315239] shepherd[1]: Service udev has been disabled.
[ 2536.356551] shepherd[1]: all processes have been terminated
[ 2536.365466] shepherd[1]: Service user-processes stopped.
[ 2536.374333] shepherd[1]: Service user-processes is now stopped.
[ 2536.378815] shepherd[1]: Stopping service urandom-seed...
[ 2536.386166] shepherd[1]: Service urandom-seed might have failed to stop.
[ 2536.389012] shepherd[1]: Service urandom-seed is now stopped.
[ 2536.391950] shepherd[1]: Service guix-daemon is not running.
[ 2536.399246] shepherd[1]: Service nscd is not running.
[ 2536.402536] shepherd[1]: Stopping service log-rotation...
[ 

bug#76959: Closing issue

[Rutherther via Bug reports for GNU Guix]

Closing this issue as it was found out this is not an issue
of itself, just a manifestation of wrongly unmounted root file system,
which is why Guix has seen more file corruptions recently.

See #77086 for more details. Moreover this shouldn't be an issue
anymore as it seems a recent update of shepherd has resolved it.

Rutherther

bug#77086: Filesystems not unmounted on reboot

[Rutherther via Bug reports for GNU Guix]

Hello Ludo,

Ludovic Courtès  writes:

> Hi,
>
> Rutherther  skribis:
>
>> I was testing on commmit Ian sent to reproduce, and now moved to
>> newest guix, seems to have been solved (at least the specific error I
>> was getting),
>> possibly by shepherd 1.0.3 update.
>>
>> With newest guix both the first reconfigure of guix system image
>> and subsequent ones are fine.
>
> I believe I’m still experiencing it on my laptop (but it’s harmless, I
> only briefly see e2fsck saying “recovering journal” at boot time), but
> of course, not the slightest clue in /var/log/messages.

To make it more clear, what I was able to get in the VM was full disk
recovery that was clearing wrong inodes, every time and I even got disk
corruptions for the files produced during reconfigure (which was the
last thing I did before reboot). So I am not sure if this is the same
thing, do you know, is this one line printed only when there is
something wrong with the journal, or is it printed every time like sort
of a 'welcome' message?

>
>> Let me know if you're still experiencing this issue after updating
>> and I might try harder to reproduce if I got a different issue on first
>> try. I am afraid this will be hard to debug on real hw as you don't
>> really get the log in /var/log/messages for shutting down the system, I
>> had to get it through a serial line via stdout of qemu.
>>
>> Also I was able to reproduce the issue on the older
>> guix just by running the shepherd services upgrade scm script,
>> no need for full reconfigure, this shows that something has gone
>> wrong when shepherd was reloading the services. Do we have some kind of
>> a test for this in guix / shepherd so it can't happen anymore in the future?
>
> There’s a system test, “root-unmount” in (gnu tests base), but it
> succeeds: .

Thanks for pointing out this test, good to know about it, although it's
not exactly what I had in mind. I was able to reproduce previously by
running the upgrade-shepherd-services.scm that is ran upon reconfigure,
without it, root fs unmounted cleanly. So the test I had in mind would
be to test that when shepherd is upgraded like this, there aren't
changes to how the services are stopped.

>
> Perhaps the problem only shows up with more complex system configs?
> My root partition is on a LUKS device, but I think the problem is more
> something like EBUSY upon ‘umount’ due to stale processes.

I've tried reproducing with bjoli's config last friday, they were
experiencing it and sent their config to IRC chat. I was unable to
reproduce (though I have to confess I changed the fs to ext4 for my
convenience).
So I am not sure if it is reproducible even given a config (though maybe
something is relevant on the vm vs real machine boot, but I wouldn't
expect it...)

I have yet to try Ian's config, but it's going to take me some time to
get to it as their config is more complicated, mainly the network disk,
which I would like to not skip any disk related stuff (and I think Ian
is missing file-systems requirement on their shepherd autofs service,
but it shouldn't really cause this issue as root filesystem unmount
should be recursive).

Regards,
Rutherther

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Hi Ludo

Ludovic Courtès  writes:
>
> What command did you run, precisely?  I cannot experience it:

For home, I tried my own config, and since I was pretty sure any system
container is affected (tried a simple one, my one and I know one other
person reported this in Matrix channel), I didn't try anything simpler
and just assumed all homes are going to be affected as well.
Now trying simpler config you mentioned, that one works fine.

The command was `guix home container -L ./home/modules 
./home/home-container.scm`
in my repository. It's here https://git.ditigal.xyz/~ruther/guix-config.
Any idea what service could cause this behavior with lock-mounts? Would
be good to isolate it, but I am not sure where to start.

Here is the unshare error I was talking about earlier:
> guix home: error: unshare: 268566528: Invalid argument
Now I am getting it consistently, before it was missing sometimes.
Currently on
```
> ./target/guix/bin/guix describe
  guix 300d29e
repository URL: https://codeberg.org/guix/guix-mirror
branch: master
commit: 300d29e69988caf23684f08effa51f621c7ec083
  nonguix 1940698
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 19406981a9bf9d0b140180f1f3008cb91f716b4b
  ruther 1a49e47
repository URL: https://git.ditigal.xyz/~ruther/guix-exprs
branch: main
commit: 1a49e4760bd922237532fa2eee44bc9e1fe42399
  rde bf8f628
repository URL: https://git.sr.ht/~abcdw/rde
branch: master
commit: bf8f628c4deb9acc94e261db80d301048ea1f0a2
```

Thanks
Rutherther

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Hi,
>
> Rutherther  writes:
>
>> The command was `guix home container -L ./home/modules 
>> ./home/home-container.scm`
>> in my repository. It's here https://git.ditigal.xyz/~ruther/guix-config.
>> Any idea what service could cause this behavior with lock-mounts? Would
>> be good to isolate it, but I am not sure where to start.
>>
>> Here is the unshare error I was talking about earlier:
>>> guix home: error: unshare: 268566528: Invalid argument
>> Now I am getting it consistently, before it was missing sometimes.
>
> Could you copy paste the command and its output, to be sure there’s no
> misunderstanding?

Sure

--8<---cut here---start->8---
[ruther:~/.setup] main(+68/-13)* 15s ± 
> ./target/guix/bin/guix home container -L ./home/modules 
> ./home/home-configuration.scm 
guix home: warning: failed to load '(ruther home channels-emacs)':
no code for module (ruther home channels-emacs)
ruther/home/channels-emacs.scm:1:0: warning: module name (channels) does not 
match file name 'ruther/home/channels-emacs.scm'
hint: File `./home/modules/ruther/home/channels-emacs.scm' should probably 
start with:

 (define-module (ruther home channels-emacs))

guix home: warning: ambiguous package specification `font-ubuntu'
guix home: warning: choosing font-ubuntu@0.83 from ruther/home/fonts.scm:8:2
guix home: error: unshare: 268566528: Invalid argument
Backtrace:
  18 (primitive-load "/home/ruther/.setup/./target/guix/bin/…")
In guix/ui.scm:
   2369:7 17 (run-guix . _)
  2332:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
859:3 14 (_)
839:4 13 (call-with-status-report _ _)
In guix/scripts/home.scm:
547:4 12 (_)
In ice-9/boot-9.scm:
  1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   690:37 10 (thunk)
   1331:8  9 (call-with-build-handler _ _)
   1331:8  8 (call-with-build-handler _ _)
   1331:8  7 (call-with-build-handler # …)
  2212:25  6 (run-with-store # …)
In guix/scripts/home.scm:
   465:14  5 (_ _)
In gnu/system/linux-container.scm:
   349:17  4 (_ _)
In gnu/build/linux-container.scm:
485:7  3 (call-with-container _ _ #:namespaces _ #:host-uids _ # …)
In unknown file:
   2 (waitpid #f #)
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 (expecting exact integer): #f
θ61° [ruther:~/.setup] main(+68/-13)* 58s 1 ± 
> ./target/guix/bin/guix describe   
>
  guix 300d29e
repository URL: https://codeberg.org/guix/guix-mirror
branch: master
commit: 300d29e69988caf23684f08effa51f621c7ec083
  nonguix 1940698
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 19406981a9bf9d0b140180f1f3008cb91f716b4b
  ruther 1a49e47
repository URL: https://git.ditigal.xyz/~ruther/guix-exprs
branch: main
commit: 1a49e4760bd922237532fa2eee44bc9e1fe42399
  rde bf8f628
repository URL: https://git.sr.ht/~abcdw/rde
branch: master
commit: bf8f628c4deb9acc94e261db80d301048ea1f0a2
--8<---cut here---end--->8---

>
> This is on Guix System, right?

Yes

>
> Thanks,
> Ludo’.

bug#78355: guix-ownership inconsistent state

[Rutherther via Bug reports for GNU Guix]

There are reports from users with inconsistencies in ownership, it seems that at
least /var/guix is sometimes left with wrong owner, but maybe even parts
of the store? I cannot verify that.

The guix-ownership service checks /gnu/store ownership to check if the
whole store and all files important for the daemon (/etc/guix,
/var/guix) are owned by the appropriate user.

If the folder isn't owned by appropriate user, it moves to those steps:
1. Fix permissions in /gnu/store - first under it, then /gnu/store
itself as last step
2. Fix /var/guix
3. Fix /etc/guix
4. Fix /var/log/guix

So from those laid out steps it should be obvious that if guix-ownership
service somehow stops between steps 1 and 2, it will never recover
ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
change owner as last.

On the other hand it feels much of a coincidence users would be
consistently hitting reboots between those steps. So maybe I am
overlooking another thing. I checked the file-system-fold, it goes to
/gnu/store as last, so that would mean putting step 1 after 4 should fix
that. Still, maybe only /gnu/store itself should be skipped instead of moving
the step, and done as last, step 5 to ensure it's fine even if
file-system-fold somehow changed the ordering? Not sure how exactly it
should behave in that regard.

Regards
Rutherther

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Seems that the recent commit 'Lock mounts by default'
a57ed987ffd1452ba5a4d70feb54893e99b8e076 has broken both guix system
container and guix home container. For system container, the system
container command finishes fine, but then running the run-container
script fails. For home container the command itself errors out, since
it's what is starting the container as well.

Here are the backtraces:
guix system:
```
Backtrace:
   7 (primitive-load "/gnu/store/p3m2srwhv49gv1lk2yi4i73b9mn…")
In gnu/build/linux-container.scm:
368:8  6 (call-with-temporary-directory #)
   476:16  5 (_ "/tmp/guix-directory.DGavex")
 62:6  4 (call-with-clean-exit #)
   323:22  3 (_)
215:2  2 (initialize-user-namespace 1 65536 #:host-uid _ # _ # _ …)
In ice-9/ports.scm:
435:6  1 (call-with-output-file _ _ #:binary _ #:encoding _)
In unknown file:
   0 (close-port #)

ERROR: In procedure close-port:
In procedure fport_write: Operation not permitted
system container is running as PID #f
Run 'sudo guix container exec #f /run/current-system/profile/bin/bash --login'
or run 'sudo nsenter -a -t #f' to get a shell into it.

Backtrace:
   3 (primitive-load "/gnu/store/p3m2srwhv49gv1lk2yi4i73b9mn…")
In gnu/build/linux-container.scm:
368:8  2 (call-with-temporary-directory #)
485:7  1 (_ "/tmp/guix-directory.DGavex")
In unknown file:
   0 (waitpid #f #)
```

guix home:
```
Backtrace:
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  13 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 12 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 11 (_ #(#(#)))
In ice-9/command-line.scm:
   185:19 10 (_ #)
In unknown file:
   9 (eval (begin (use-modules (guix build utils) (# ?)) # ?) ?)
In ice-9/eval.scm:
619:8  8 (_ #f)
In unknown file:
   7 (primitive-load "/gnu/store/9kr07956x74cs9cql5jj3kdvb7f?")
In ice-9/eval.scm:
619:8  6 (_ #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
   626:19  5 (_ #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
619:8  4 (_ #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In unknown file:
   3 (primitive-load "/gnu/store/j7v0sgg2grb9x8n6h2xh2cyvyf7?")
In ice-9/eval.scm:
   293:34  2 (_ #(#(#(#(#(#(# ?) ?) ?) ?) ?) ?))
In ice-9/ports.scm:
   450:11  1 (call-with-input-file _ # ?)
In unknown file:
   0 (open-file # "r" #:encoding #f # #f)

ERROR: In procedure open-file:
Wrong type (expecting string): #
```

Additionally at one moment I was able to get an error message with guix
home that unshare has gotten an invalid argument, the argument was just
a number.

Unfortunately I was not able to understand what the issue is to fix it.

Regards
Rutherther

bug#78363: Home is read-only in guix shell container

[Rutherther via Bug reports for GNU Guix]

> I am not sure whether this is intended behavior, but it seems weird to 
> me. Inside e.g.
> 
> guix shell -Cu test coreutils
> 
> /home/test is mounted read-only and I do not see any way to make it 
> writable without sharing a host directory.

Yes this is intentional. The root has been changed to read only
recently. See the guix news. Use --writable-root to restore the previous 
behavior.

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Hi,
>
> Rutherther  writes:
>> Here are the backtraces:
>> guix system:
>
> Fixed in 437bb9ece55f37d4b5a62cafc98c0c3b848a53ce.

Confirmed.

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Hi,
>
> Rutherther  writes:
>
>> --8<---cut here---start->8---
>> [ruther:~/.setup] main(+68/-13)* 15s ± 
>>> ./target/guix/bin/guix home container -L ./home/modules 
>>> ./home/home-configuration.scm 
>> guix home: warning: failed to load '(ruther home channels-emacs)':
>> no code for module (ruther home channels-emacs)
>> ruther/home/channels-emacs.scm:1:0: warning: module name (channels) does not 
>> match file name 'ruther/home/channels-emacs.scm'
>> hint: File `./home/modules/ruther/home/channels-emacs.scm' should probably 
>> start with:
>>
>>  (define-module (ruther home channels-emacs))
>>
>> guix home: warning: ambiguous package specification `font-ubuntu'
>> guix home: warning: choosing font-ubuntu@0.83 from ruther/home/fonts.scm:8:2
>> guix home: error: unshare: 268566528: Invalid argument
>
> Is this from within a container?

No.

>
> Does ‘guix shell -C coreutils’ work?

Yes, shell containers work fine for me, it was just home and system
where I saw an issue. As I pointed out earlier the home container in
guix source tree works for me. So it's triggered by something in my home
setup.

>> --8<---cut here---start->8---
[ruther:~/doc/projects/git_clones/guix] issue/78308(9)* 130 ±
> ~/.setup/target/guix/bin/guix home container doc/he-config-bare-bones.scm 
substitute: looking for substitutes on 'https://substitutes.nonguix.org'... 
100.0%
substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: looking for substitutes on 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/1d031p7xkmhhcjw4qqs0cwhfh8p004q7-shepherd-timer.scm.drv
  /gnu/store/54csgxblx2i5c8r03ywxpda1wv8blz61-shepherd-transient.scm.drv
  /gnu/store/k8s4j84qrly49hd1adihjcq106hx0a6c-shepherd-log-rotation.scm.drv
  /gnu/store/ni8rlk32hbr7s6gyps0dr0lfy7g9c5dl-shepherd.conf.drv
  /gnu/store/4khnkn4rab0p6vv9h99n9yfmk2lm1jwj-on-first-login.drv
  /gnu/store/6as6qxw72lcr90gml6wk8mjib5rj8j87-files.drv
  /gnu/store/as14p3xl0n3hgxi5lac7w0gdcjilbr2g-provenance.drv
  /gnu/store/dqlgr0jg3kiyzbbc4pmd9vk188sl3kh1-activate.drv
  /gnu/store/nkhmbvy8hkwkafb7fq1f14by0mrnd046-home.drv

building /gnu/store/as14p3xl0n3hgxi5lac7w0gdcjilbr2g-provenance.drv...
building 
/gnu/store/k8s4j84qrly49hd1adihjcq106hx0a6c-shepherd-log-rotation.scm.drv...
building /gnu/store/1d031p7xkmhhcjw4qqs0cwhfh8p004q7-shepherd-timer.scm.drv...
building 
/gnu/store/54csgxblx2i5c8r03ywxpda1wv8blz61-shepherd-transient.scm.drv...
building /gnu/store/ni8rlk32hbr7s6gyps0dr0lfy7g9c5dl-shepherd.conf.drv...
building /gnu/store/dqlgr0jg3kiyzbbc4pmd9vk188sl3kh1-activate.drv...
building /gnu/store/6as6qxw72lcr90gml6wk8mjib5rj8j87-files.drv...
building /gnu/store/4khnkn4rab0p6vv9h99n9yfmk2lm1jwj-on-first-login.drv...
building /gnu/store/nkhmbvy8hkwkafb7fq1f14by0mrnd046-home.drv...
WARNING: (guile-user): imported module (guix build utils) overrides core 
binding `delete'
WARNING: (guile-user): imported module (guix build utils) overrides core 
binding `delete'
Symlinking /home/ruther/.bash_profile -> 
/gnu/store/gghay5fzpad5w7082nnk6z9lj7q00drv-bash_profile... done
Symlinking /home/ruther/.profile -> 
/gnu/store/vvxqfhlkpi90bgmfh1b03kkwfq7pmfkk-shell-profile... done
Symlinking /home/ruther/.bashrc -> 
/gnu/store/b9ppn0jdrda5h88mw5x35m2jvms8izw6-bashrc... done
Symlinking /home/ruther/.config/test.conf -> 
/gnu/store/i8wsnvh1q8lbgyf50vapfsn2rfj7a2nc-tmp-file.txt... done
Symlinking /home/ruther/.config/fontconfig/fonts.conf -> 
/gnu/store/mw4clgkwj3rvlnfv0gd694aabvamr0sa-fonts.conf... done
Symlinking /home/ruther/.config/shepherd/init.scm -> 
/gnu/store/ysg5icpancicn1hi2gfd1q3xvmmgb8lf-shepherd.conf... done
 done
Finished updating symlinks.

Comparing /gnu/store/non-existing-generation/profile/share/fonts and
  
/gnu/store/84kwxidarhpibps26xyqbdpj5lfk1s37-home/profile/share/fonts... done 
(same)
Evaluating on-change gexps.

On-change gexps evaluation finished.

This is the Z Shell configuration function for new users,
zsh-newuser-install.
You are seeing this message because you have no zsh startup files
(the files .zshenv, .zprofile, .zshrc, .zlogin in the directory
~).  This function can help you with a few settings that should
make your use of the shell easier.

You can:

(q)  Quit and do nothing.  The function will be run again next time.

(0)  Exit, creating the file ~/.zshrc containing just a comment.
 That will prevent this function being run again.

(1)  Continue to the main menu.

--- Type one of the keys in parentheses --- 0
--8<---cut here---end--->8---

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Hi,
>
> Rutherther  skribis:
>
>>> ./target/guix/bin/guix home container -L ./home/modules 
>>> ./home/home-configuration.scm 
>> guix home: warning: failed to load '(ruther home channels-emacs)':
>> no code for module (ruther home channels-emacs)
>> ruther/home/channels-emacs.scm:1:0: warning: module name (channels) does not 
>> match file name 'ruther/home/channels-emacs.scm'
>> hint: File `./home/modules/ruther/home/channels-emacs.scm' should probably 
>> start with:
>>
>>  (define-module (ruther home channels-emacs))
>>
>> guix home: warning: ambiguous package specification `font-ubuntu'
>> guix home: warning: choosing font-ubuntu@0.83 from ruther/home/fonts.scm:8:2
>> guix home: error: unshare: 268566528: Invalid argument
>
> What’s weird is that this seems to happen even before activation.
>
> I cannot audit the whole thing but apparently something in the config
> tries to connect to the outside:
>
> --8<---cut here---start->8---
> 
> Updating channel 'guix' from Git repository at 
> 'https://codeberg.org/guix/guix-mirror'...
> guix home: error: failed to load 'home/home-configuration.scm':
> web/client.scm:338:10: In procedure open-socket-for-uri:
> In procedure getaddrinfo: Servname not supported for ai_socktype
> --8<---cut here---end--->8---

So this is after the build? I have added inferiors recently for using
Emacs 30, that would explain it before build, but after build I am
clueless why that would happen. Though if it's before build, I am
surprised you got an error like that, unless you were purposefully in
environment without network. I added the inferiors just yesterday,
commit 819ee341ab6bcc9846b099572af185c781b82a1d shouldn't be downloading
anything.

>
> Probably use of ‘current-guix’?
>
> Anyway, do you think you could boil it down to a minimal reproducer?

I will definitely try to, but probably not today, in a few days,
hopefully by the end of the week.

>
> Thanks,
> Ludo’.

bug#78355: guix-ownership inconsistent state

[Rutherther via Bug reports for GNU Guix]

Hi Ben,

I am CCing you to get more information about the inconsistent ownership,
if you could help with that.

The most important questions are probably:
0. Are you sure the service actually ran after you reconfigured to root?
  It should definitely run after reboot, not sure if after reconfigure
  as the service already exists, it's just modified
1. Do you think you could've killed the service when it was running
after you reconfigured back to privileged daemon, ie. by rebooting when
it was running?
2. Do you know what folders had wrong owners?
  - Was everything under /var/guix fully owned by 971?
  - Was everything under /etc/guix fully owned by 971?
  - Was everything under store fully owned by 971?

Hi Ludo,

Ludovic Courtès  writes:

> Hi,
>
> Rutherther  writes:
>
>> There are reports from users with inconsistencies in ownership, it seems 
>> that at
>> least /var/guix is sometimes left with wrong owner, but maybe even parts
>> of the store? I cannot verify that.
>
> Would be nice to get their reports here, otherwise we’re left
> speculating.

I am afraid we will be left speculating either way, that's why I chose
this approach. That is because none of the users I know of took time to
debug it and just fixed it. CCing Ben Sturmfels who
encountered it (see
https://lists.gnu.org/archive/html/help-guix/2025-05/msg00052.html).
For the other user I know of, I don't know their e-mail.

Note that on IRC I recommended the user to chown $USER /gnu/store
($USER just cause it's easiest, any non-root user would be fine) and
herd start guix-ownership and that fixed the issue. So the service
definitely is doing its job. See here 
https://logs.guix.gnu.org/guix/2025-05-10.log#171215

>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Well, the fundamental assumption is that ‘guix-ownership’ is not
> interrupted during its work; manual intervention is needed to repair
> things if it is interrupted.

I think it would at least be good if there was a script to do what
guix-ownership does, but force it without the /gnu/store ownership
check, to make it easier for users to recover. Maybe even an optional argument 
to
guix-ownership, where you could `sudo herd start guix-ownership 1` and
that would force the chown'ing?

>
> I don’t see any way around that but perhaps we should warn about it more
> clearly?

That would definitely be great, I think you can easily oversee that the
service has started. Now I am not sure if one-shot services are started
after change when you reconfigure, if they are, I think it's going to be
a common issue - people reconfigure & reboot! Meaning they will usually
stop the service, or am I mistaken here?

>
>> On the other hand it feels much of a coincidence users would be
>> consistently hitting reboots between those steps. So maybe I am
>> overlooking another thing. I checked the file-system-fold, it goes to
>> /gnu/store as last, so that would mean putting step 1 after 4 should fix
>> that. Still, maybe only /gnu/store itself should be skipped instead of moving
>> the step, and done as last, step 5 to ensure it's fine even if
>> file-system-fold somehow changed the ordering? Not sure how exactly it
>> should behave in that regard.
>
> Doing /gnu/store last is a good idea because it reduces the window
> during which the inconsistent state could go undetected.

I think it completely removes it. Or why do you think not?
If it really doesn't I think it would be good if we came up with an
approach that would remove this window. The best way to achieve no
inconsistence-window would be to just check all of the permissions, but
that's probably an overkill.
For example creating a 'stamp'
somewhere that says it was done, at the end, and checking if that stamp
file matches what we expect.

>
> Feel free to propose a patch; otherwise I’ll give it a try, but not
> before next week.
>
> Thanks,
> Ludo’.

Thanks
Rutherther

bug#78356: Broken system and home containers

[Rutherther via Bug reports for GNU Guix]

Hi,

hiecaq  writes:

>
> I'm getting this "unshare: 268566528: Invalid argument" error just 
> using `guix shell -C -m manifest.scm` when I was trying to develop 
> a local Haskell package today, and I think it might be relevant to 
> this bug.  Here is the backtrace:

I can confirm I can get this with your manifest as well. But not
consistently, I have to rerun the shell container multiple times to get
it. Also, from simple trial it seems it's the development inputs of
xmobar-hiecaq that cause this. I am not getting the issue when I comment
everything else in the manifest. But I haven't tried minimizing this
even more to a specific input.

Regards
Rutherther

bug#78649: (recursive? #t) doesn't seem to be part of the source hash

[Rutherther via Bug reports for GNU Guix]

Hi nomike,

> Hi!
> 
> I'm currently working on a package definition and again stumbled upon an 
> issue:
> 
> I had the flag `(recursive? #t)` added to `source`:
> 
> ```scheme
>        (source
>         (origin
>           (method git-fetch)
>           (uri (git-reference
>                 (url "https://github.com/openscad/openscad";)
>                 (commit commit)
>                 (recursive? #t)))
>           (sha256
>            (base32 
> "1bkzrjjp0qvfg7pj24j5pa0i6zj0zsqjb5z4w3l6pjdb5q9in0qi"))
>           (file-name (git-file-name name version
> ```
> 
> I then removed the recursive flag and continued on working on my 
> package, which is based on a commit-ID of the upstream project. Once I 
> switched to a newer commit, I got strange build errors from cmake. I 
> switched back the original commit, everything worked again.
> It took me a while to remember, that in such a case, guix is not 
> re-downloading the source as the source hash doesn't change.
> 
> IMHO this hash should also contain flags like recursive.
> 
> When  `git clone foo` is changed to `git clone --recursive foo` the 
> source has obviously changed (unless the repo doesn't have submodules 
> perhaps), so it doesn't make sense that the sha256 hash stays the same.
> 
> Is this something we can address?

I don't think so. For FOD the store path is created from:
- path to gnu store
- hash of the derivation
- name of the package

So when speaking about origin, uri doesn't matter at all. Only file-name
and sha256 does.

That means it is responsibility of the user to change the hash to a new
one when nothing from those changes, but the source is supposed to
change. Ie. if commit is changed to different one without having it in
the file-name, if recursive is changed...

When you change the source, also change the hash to a correct one (or an
invalid one and let it fail to tell you new hash)

> 
> Or is this an issue as it would invalidate all current source hashes at 
> once?

Change like adding the uri to the creation of the hash would definitely
invalidate all source hashes. But it is exactly the point of FOD to not
depend on the uri. If uri is changed, but sha256 stays the same, that
implies the new uri is supposed to fetch the same source => no need for
a redownload.
 
> 
> Thanks
> 
> nomike

Rutherther

bug#78717: New etc-profile-d-service-type test fails, breaking many other tests

[Rutherther via Bug reports for GNU Guix]

Hi 45mg,

> I noticed this when I ran the 'encrypted-home-os-key-file' test to test
> a new patch to  [1], and it failed due to the
> '/etc/profile.d is sourced' test failing. Eventually I figured out that
> it fails on the latest master as well, and the latest CI run confirms
> this:
> 
> https://ci.guix.gnu.org/build/10936896/details
> 
> Looking at the log file, you can see the failing test:
> 
> https://ci.guix.gnu.org/build/10936896/log/raw
> --8<---cut here---start->8---
> ...
> Test begin:
>   test-name: "/etc/profile.d is sourced"
>   source-file: 
> "/gnu/store/178h83msb53wf8v57zabi8s4q4ksfid8-encrypted-home-os-builder"
>   source-line: 1
>   source-form: (test-assert "/etc/profile.d is sourced" (zero? 
> (marionette-eval (quote (system "\n. /etc/profile\nset -e -x\ntest -f 
> /etc/profile.d/test_profile_d.sh\ntest \"$PROFILE_D_OK\" = yes")) 
> marionette)))
> Test end:
>   result-kind: fail
>   actual-value: #f
>   ...
> --8<---cut here---end--->8---
> 
> Looking at some of the other failing tests, you can see that they fail
> in exactly the same way:
> 
> encrypted-root-os
> https://ci.guix.gnu.org/build/10936887/details
> encrypted-home-os
> https://ci.guix.gnu.org/build/10936894/details
> jfs-root-os
> https://ci.guix.gnu.org/build/10936890/details
> btrfs-root-os
> https://ci.guix.gnu.org/build/10936905/details
> 
> Before this, the last CI run that ran to completion was on commit
> 85b5c2c, which was before the etc/profile.d test was added. In total,
> there are 23 new failing tests from this CI run:
> 
> https://ci.guix.gnu.org/eval/2062380?status=newly-failed
> 
> The strange thing is, the etc/profile.d test passes if I run it normally
> as part of the basic tests, like this:

I don't think this is a strange thing at all. The basic test runs with
test-basic-os operating-system, this os has the
etc-profile-d-service-type. The other tests still use run-basic-test
that checks basic stuff, including /etc/profile.d sourcing, but use
different os definition, without the etc-profile-d-service-type.

So there needs to happen one of those two things:
1. The run-basic-test procedure has to be modified to not expect
/etc/profile.d always
2. The other tests have to use the os with etc-profile-d-service-type
services, ie. by concating the services from basic-test-os.

> --8<---cut here---start->8---
> guix shell -D guix --pure -- make check-system TESTS=basic
> --8<---cut here---end--->8---
> 
> 
> [1] https://yhetil.org/guix/87jz7rsu49@gnu.org/

Rutherther

bug#74396: System guix masks modules from pulled 3rd-party channels

[Rutherther via Bug reports for GNU Guix]

Hi Tomas,

> Hi,
> 
> when system guix produced by the guix-for-channels procedure is
> installed, modules in any channel (except in the 'guix) will shadow the
> same modules acquired via `guix pull'.

Ah right, this is because GUILE_LOAD_PATH is set to
/run/current-system/... The load path will shadow everything except the
guix that cannot really be shadowed, it's treated kind of specially.
This variable is there because both guix and guile are installed to the
profile, see `guix shell guix guile --search-paths`.

I think the easiest and maybe only solution is to also add the search
path to ~/.config/guix/current. This could be done either by installing
guile into it as well, or by installing a dummy package with
GUILE_LOAD_PATH. This would have to be coded into profile made by guix pull.

Since system profile is sourced first, and ~/.config/guix/current after
it, the env var would have the ~/.config/guix/current first and
/run/current-system second. That means the modules from
~/.config/guix/current are used.

Still, if you do pull as user without some of the channels that are
available in system, those channels will still be available to you.
While that might not be preferred behavior, I am not sure there can be
something done about it. The problem is that users definitely do want
the GUILE_LOAD_PATH to be respected, for their own projects etc. ...
So it cannot just be ignored/unset. Another solution would be to
uninstall guile from the system profile, but again, that is not a good
default, so the bug would happen by default.

Regards
Rutherther