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