bug#72967: PHP not building

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

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

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 issu

bug#72967: PHP not building

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

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

> 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

bug#72333: Magit/Transient error message

>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

bug#73214: swaylock-1.8.0 build failure

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

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

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.or

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

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-pyflak

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

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"

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

bug#73869: Cannot start EXWM without a display manager

> 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 t

bug#73869: Cannot start EXWM without a display manager

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

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 modul

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

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 th

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

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

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

> 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 >>> anyth

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

"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

bug#76959: Empty Scheme files in system generation,

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 i

bug#77086: Filesystems not unmounted on reboot

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

bug#77086: Filesystems not unmounted on reboot

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 k

bug#76959: Empty Scheme files in system generation,

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

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

>> 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

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

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 e

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

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

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

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 happ

bug#77086: Filesystems not unmounted on reboot

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)

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

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 th

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

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 ch

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

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

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

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 recon

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

crysys.hu has been removed.

bug#77086: Filesystems not unmounted on reboot

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 th

bug#76959: Closing issue

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 sh

bug#77086: Filesystems not unmounted on reboot

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 t

bug#78356: Broken system and home containers

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

bug#78356: Broken system and home containers

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 >

bug#78355: guix-ownership inconsistent state

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

bug#78356: Broken system and home containers

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 c

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

> 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

bug#78356: Broken system and home containers

Ludovic Courtès writes: > Hi, > > Rutherther writes: >> Here are the backtraces: >> guix system: > > Fixed in 437bb9ece55f37d4b5a62cafc98c0c3b848a53ce. Confirmed.

bug#78356: Broken system and home containers

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

bug#78356: Broken system and home containers

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

bug#78355: guix-ownership inconsistent state

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 reconfigur

bug#78356: Broken system and home containers

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 th

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

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-refer

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

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:

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

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