bug#36951: guile-sly will not build
When I try `guix build guile-sly` it gives the error "configure: error: freeimage not found." When I try to manually build guile-sly, I get additional information: ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc- profile/lib/libfreeimage.so: undefined reference to `PerfTimerStart' ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc- profile/lib/libfreeimage.so: undefined reference to `PerfTimerCopyStartTime' ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc- profile/lib/libfreeimage.so: undefined reference to `PerfTimerGetResults' ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc- profile/lib/libfreeimage.so: undefined reference to `PerfTimerStop' ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc- profile/lib/libfreeimage.so: undefined reference to `PerfTimerDelete' ld: /gnu/store/86mrl4m1i90wirwzxrri7xybk5nki7hc- profile/lib/libfreeimage.so: undefined reference to `PerfTimerNew' collect2: error: ld returned 1 exit status I looked into freeimage. The missing function reference should be defined in the libjxr bundled with freeimage. Some related history: - commit a5d4c96b8d90b8bb87e07bd6a7be78991db91bc9 (http://git.savannah. gnu.org/cgit/guix.git/commit/gnu/packages/image.scm?id=a5d4c96b8d90b8bb 87e07bd6a7be78991db91bc9) gnu: freeimage: Remove bundled libraries. - commit f347c24acc14e080dc2801561edca0d525a90257 (http://git.savannah. gnu.org/cgit/guix.git/commit/gnu/packages/image.scm?id=f347c24acc14e080 dc2801561edca0d525a90257) gnu: freeimage: Use bundled libjxr. - bug #28261 (https://issues.guix.gnu.org/issue/28261) freeimage uses bundled libraries - commit 37dc29200c44adc0474476b8df46ed44e8a1d41a (http://git.savannah. gnu.org/cgit/guix.git/commit/gnu/packages/maths.scm?id=37dc29200c44adc0 474476b8df46ed44e8a1d41a) gnu: Add opencascade-occt. - bug #34013 (https://issues.guix.gnu.org/issue/34013) [PATCH 1/2] gnu: libjxr: Build and install shared library. It seems commit f347c24acc14e080dc2801561edca0d525a90257 was an attempt to fix guile-sly, but it looks like it was unsuccessful. Commit 37dc29200c44adc0474476b8df46ed44e8a1d41a mentions a similar issue and has a work-around. I do not think the configure script will be as cooperative with this work-around because it checks for FreeImage unconditionally. - bug #34013 was a patch submitted in January but nobody has responded to it. I don't know if it will fix this issue, but it's worth reviewing. -- -Jesse
bug#36942: Reconfigure broke GRUB
Hi Jakob, On Tue, 06 Aug 2019 15:48:43 -0400 zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) wrote: > Danny Milosavljevic writes: > > > Hi, > > > > I've examined /var/guix/gcroots without #36947 and I get: > > > > lrwxrwxrwx 1 root root 18 24. Jul 11:32 profiles -> /var/guix/profiles > > lrwxrwxrwx 1 root root 19 24. Jul 11:32 current-system -> > > /run/current-system > > lrwxrwxrwx 1 root root 18 24. Jul 11:32 booted-system -> > > /run/booted-system > > lrwxrwxrwx 1 root root 26 29. Jul 22:26 bootcfg -> > > //var/guix/gcroots/bootcfg > > > > So I guess I'm one "guix gc" away from also destroying my > > installation. > > Was this fixed after applying #36947? Yes. > > The double slash looks very suspicious... > > Any reason in particular? The second slash is there because > '%gc-roots-directory' has a leading slash, and that gets appended to > 'target', which in this case is '/'. Ah okay. pgpKgBY478aW8.pgp Description: Digitale Signatur von OpenPGP
bug#36855: guix system switch-generation doesn't
Could we get some input on this bug?
Maybe I’m misunderstanding something, but it seems that a core guix
feature (atomic rollbacks) doesn’t work…
> On 30. Jul 2019, at 12:00, Robert Vollmert wrote:
>
> What I see:
>
> 1. edit ~/pzprnode/pzprnode
>
> rob@garp ~/pzprnode$ git diff
> diff --git a/pzprnode b/pzprnode
> index 612e6a8..d8ef0ea 100755
> --- a/pzprnode
> +++ b/pzprnode
> @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {
> });
>
> server.listen(port, hostname, () => {
> + console.log("updated version");
> console.log(`Server running at http://${hostname}:${port}/`);
> });
>
> 2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm
> 3. sudo herd restart pzprnode
> 4. less /var/log/messages
>
> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped.
> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started.
> Jul 30 11:46:58 localhost pzprnode[4954]: updated version
> Jul 30 11:46:58 localhost pzprnode[4954]: Server running at
> http://127.0.0.1:3456/
>
> 5. sudo guix system list-generations
>
> Generation 151Jul 30 2019 10:37:06
> file name: /var/guix/profiles/system-151-link
> canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system
> label: GNU with Linux-Libre 5.2.1
> bootloader: grub
> root device: label: "guix-root"
> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
> Generation 152Jul 30 2019 11:43:13(current)
> file name: /var/guix/profiles/system-152-link
> canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system
> label: GNU with Linux-Libre 5.2.1
> bootloader: grub
> root device: label: "guix-root"
> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
>
> 6. sudo guix system switch-generation 151
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivation will be built:
> /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv
> building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...
> switched from generation 152 to 151
>
> 7. sudo herd restart pzprnode
> 8. less /var/log/messages
>
> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped.
> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started.
> Jul 30 11:48:03 localhost pzprnode[4994]: updated version
> Jul 30 11:48:03 localhost pzprnode[4994]: Server running at
> http://127.0.0.1:3456/
>
> The line with “updated version” should not be there.
>
> Presumably, this is due to switch-generations not calling
> upgrade-shepherd-services.
>
bug#36855: guix system switch-generation doesn't
Could we get some input on this bug?
Maybe I’m misunderstanding something, but it seems that a core guix
feature (atomic rollbacks) doesn’t work…
> On 30. Jul 2019, at 12:00, Robert Vollmert wrote:
>
> What I see:
>
> 1. edit ~/pzprnode/pzprnode
>
> rob@garp ~/pzprnode$ git diff
> diff --git a/pzprnode b/pzprnode
> index 612e6a8..d8ef0ea 100755
> --- a/pzprnode
> +++ b/pzprnode
> @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {
> });
>
> server.listen(port, hostname, () => {
> + console.log("updated version");
>console.log(`Server running at http://${hostname}:${port}/`);
> });
>
> 2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm
> 3. sudo herd restart pzprnode
> 4. less /var/log/messages
>
> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped.
> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started.
> Jul 30 11:46:58 localhost pzprnode[4954]: updated version
> Jul 30 11:46:58 localhost pzprnode[4954]: Server running at
> http://127.0.0.1:3456/
>
> 5. sudo guix system list-generations
>
> Generation 151Jul 30 2019 10:37:06
> file name: /var/guix/profiles/system-151-link
> canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system
> label: GNU with Linux-Libre 5.2.1
> bootloader: grub
> root device: label: "guix-root"
> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
> Generation 152Jul 30 2019 11:43:13(current)
> file name: /var/guix/profiles/system-152-link
> canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system
> label: GNU with Linux-Libre 5.2.1
> bootloader: grub
> root device: label: "guix-root"
> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
>
> 6. sudo guix system switch-generation 151
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivation will be built:
> /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv
> building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...
> switched from generation 152 to 151
>
> 7. sudo herd restart pzprnode
> 8. less /var/log/messages
>
> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped.
> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started.
> Jul 30 11:48:03 localhost pzprnode[4994]: updated version
> Jul 30 11:48:03 localhost pzprnode[4994]: Server running at
> http://127.0.0.1:3456/
>
> The line with “updated version” should not be there.
>
> Presumably, this is due to switch-generations not calling
> upgrade-shepherd-services.
>
bug#36942: Reconfigure broke GRUB
Hi Danny, Danny Milosavljevic writes: > Hi, > > I've examined /var/guix/gcroots without #36947 and I get: > > lrwxrwxrwx 1 root root 18 24. Jul 11:32 profiles -> /var/guix/profiles > lrwxrwxrwx 1 root root 19 24. Jul 11:32 current-system -> > /run/current-system > lrwxrwxrwx 1 root root 18 24. Jul 11:32 booted-system -> /run/booted-system > lrwxrwxrwx 1 root root 26 29. Jul 22:26 bootcfg -> > //var/guix/gcroots/bootcfg > > So I guess I'm one "guix gc" away from also destroying my > installation. Was this fixed after applying #36947? > The double slash looks very suspicious... Any reason in particular? The second slash is there because '%gc-roots-directory' has a leading slash, and that gets appended to 'target', which in this case is '/'. Regards, Jakob signature.asc Description: PGP signature
bug#36942: Reconfigure broke GRUB
Hi, I've examined /var/guix/gcroots without #36947 and I get: lrwxrwxrwx 1 root root 18 24. Jul 11:32 profiles -> /var/guix/profiles lrwxrwxrwx 1 root root 19 24. Jul 11:32 current-system -> /run/current-system lrwxrwxrwx 1 root root 18 24. Jul 11:32 booted-system -> /run/booted-system lrwxrwxrwx 1 root root 26 29. Jul 22:26 bootcfg -> //var/guix/gcroots/bootcfg So I guess I'm one "guix gc" away from also destroying my installation. The double slash looks very suspicious... pgpVkjj_lufoH.pgp Description: Digitale Signatur von OpenPGP
bug#36876: guix system delete-generations removes custom boot menu entries
Hi Danny, Danny Milosavljevic writes: > Hi Jakob, > > keep in mind that switching back to a previous generation could also entail a > switch of bootloader projects. It does you no good to parse the grub config > to > find menu entries and then append them to u-boot. > > Fundamentally, it would be best if either the bootloader is part of the state > that guix manages (and each time uses), or it isn't; not both. > > Current situation: > > * If you select a previous generation in the boot menu, then the state that is > selected does NOT include the bootloader (i.e. it doesn't change the > bootloader > or the bootloader config). > > * If you do "guix system reconfigure", the state that is saved includes only > the bootloader in the boot sector (simplified) but not the bootloader > installer > or the bootloader derivation. > > * If you do "guix system delete-generations", the state that is restored does > not include the bootloader installer and previous bootloader configuration. > > Clearly, it's not nice to have these different things happen. > > It would be better if we retained the generation's bootloader installer > and bootloader config and reinstalled it on each of those. > > So, I would suggest to retain the following for each system generation: > > * The bootloader package derivation > * The bootloader config derivation > * The bootloader installer derivation > > And to install the bootloader each time using the latter. > > This introduces cycles--not sure whether that's a problem or not. > For the GC I think it's not a problem. Thank you for your comments -- after reading this and Jesse's suggestion, I'm quite confident that this is the way to go about it. Regards, Jakob signature.asc Description: PGP signature
bug#36924: fixing GDM + GNOME Shell
Mark H Weaver writes: > It's interesting that I've never run into this problem, not even once, > in all my years of running GNOME on Guix systems. Since recently > reverting to mostly using GNOME under X and GDM (whereas for a while I > was mostly launching GNOME manually under Wayland), I've run into some > other problems, e.g. GDM suspending my system automatically, sometimes > immediately after logging out, but I've *never* had to remove my caches. Interesting. > I wonder if this is related to my use of Btrfs instead of Ext4. Whereas > system crashes cause file system corruptions under Ext4 (usually in the > form of some files being left empty after a crash), I've never seen any > evidence of corruption from crashes under Btrfs. I haven’t had a system crash on this machine. I didn’t use it for a month, upgraded, rebooted, and then had GDM + GNOME Shell problems. -- Ricardo
bug#36870: was: date bug -> locale inconvenience -> suggestion :)
On +2019-08-06 02:54:03 -0400, Mark H Weaver wrote: > Hi Bengt, > > I'm sorry that I didn't have time to fully read your messages, but if I > understand correctly from my quick skimming, the 'date' command from > Guix is failing to access the zoneinfo. I think I see your problem. > > Bengt Richter writes: > > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n:g' > > openat(AT_FDCWD, > > > > "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles", > > O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > > The file name above suggests that your TZDIR variable is not set > correctly to allow Guix-built binaries to find the zoneinfo files. > > On Guix systems, /etc/environment includes an entry that sets TZDIR to > the equivalent of "$(guix build tzdata)/share/zoneinfo". > > When using Guix on top of another distro, an alternative choice might be > to set TZDIR to "/usr/share/zoneinfo". I'm not sure which setting is > preferable on non-Guix systems. > > Can you try setting TZDIR and see if that solves the problem for you? > > Regards, >Mark Thanks, that works using either /usr/... or /gnu/... but I am thinking everything guix should be accessed via some profile if it's configurable? There is already a suggestion to source like this: GUIX_PROFILE="$HOME/.guix-profile" . "$GUIX_PROFILE/etc/profile" I think it would be nice if that were the only ~/.bash_profile mod a foreign-system user would have to make to tie into the guix packages such user installs with guix install. So what about having that GUIX_PROFILE profile -- at its end -- source ~/.guixrc if it exists, and then when some installation wants to suggest some environment settings, just automatically append commented-out code to ~/.guixrc. Then the friendly hints at then end of an install could suggest: ┌──┐ │ "Consider uncommenting some of the new │ │ lines we just added at the end of ~/.guixrc" │ └──┘ (sorry if utf8 box-drawing characters are a nono here -- are they? ;-/ ) I had noticed the TZDIR name looking with "guix edit tzdata", and was trying to figure out why installing had not hinted that I might need to do what you suggest above :) Thanks again. Regards, Bengt Richter
bug#36876: guix system delete-generations removes custom boot menu entries
Addition: * If you do "guix system switch-generation", the state that is restored does not include the bootloader installer and previous bootloader configuration. pgpARsn4jtDjg.pgp Description: Digitale Signatur von OpenPGP
bug#36876: guix system delete-generations removes custom boot menu entries
Hi Jakob, keep in mind that switching back to a previous generation could also entail a switch of bootloader projects. It does you no good to parse the grub config to find menu entries and then append them to u-boot. Fundamentally, it would be best if either the bootloader is part of the state that guix manages (and each time uses), or it isn't; not both. Current situation: * If you select a previous generation in the boot menu, then the state that is selected does NOT include the bootloader (i.e. it doesn't change the bootloader or the bootloader config). * If you do "guix system reconfigure", the state that is saved includes only the bootloader in the boot sector (simplified) but not the bootloader installer or the bootloader derivation. * If you do "guix system delete-generations", the state that is restored does not include the bootloader installer and previous bootloader configuration. Clearly, it's not nice to have these different things happen. It would be better if we retained the generation's bootloader installer and bootloader config and reinstalled it on each of those. So, I would suggest to retain the following for each system generation: * The bootloader package derivation * The bootloader config derivation * The bootloader installer derivation And to install the bootloader each time using the latter. This introduces cycles--not sure whether that's a problem or not. For the GC I think it's not a problem. pgp8xrpBs_fmk.pgp Description: Digitale Signatur von OpenPGP
bug#36924: fixing GDM + GNOME Shell
Hi Ricardo, Ricardo Wurmus writes: > Today I again couldn’t log into my workstation after upgrading the > system. I’m using GDM + GNOME Shell. > > At first GDM wouldn’t start. I knew what to do: remove /var/lib/gdm, > because some state must have accumulated there. > > GDM came up after a reboot, but I still couldn’t log in. Instead I was > thrown back to the login screen without any error message. I looked in > ~/.cache/gdm/session.log for information, but it only told me that > gnome-shell was killed. Thanks. > > After removing both .local/share and .cache out of the way I could log > in again. > > This happens whenever I upgrade the system. This makes the system > rather frustrating to use. I don’t know if booting into an older system > generation would result in the same problem, but my guess is that it > would because both GDM and GNOME Shell appear to be leaving some binary > files behind that cause different versions to crash unceremoneously. > > What can we do to make GDM and GNOME Shell more reliable? It's interesting that I've never run into this problem, not even once, in all my years of running GNOME on Guix systems. Since recently reverting to mostly using GNOME under X and GDM (whereas for a while I was mostly launching GNOME manually under Wayland), I've run into some other problems, e.g. GDM suspending my system automatically, sometimes immediately after logging out, but I've *never* had to remove my caches. I wonder if this is related to my use of Btrfs instead of Ext4. Whereas system crashes cause file system corruptions under Ext4 (usually in the form of some files being left empty after a crash), I've never seen any evidence of corruption from crashes under Btrfs. Mark
bug#36942: Reconfigure broke GRUB
Hi ison, Thanks for opening a new ticket for tracking this. ison writes: > Continuing this issue from https://issues.guix.gnu.org/issue/36878 > > guix reconfigure recently broke GRUB for me. When rebooting I get > dropped to a "grub rescue>" shell with an error about > "grub_file_filters" being an unknown symbol. > If I try doing the usual commands to tell GRUB how to boot I just > see the above error repeated, or "unknown command" when I run > things such as insmod or "configfile". > > So to fix the problem I can boot to a Guix install disk and do > "guix init" which rebuilds the system using older package > definitions from the disk. > That allows me to get a working system, but if I do another > "guix pull" and reconfigure using the same config file it breaks > GRUB again when I reboot. "guix describe" shows that my latest > attempt was with commit 35600cd. > > Here is the bootloader and filesystem sections of my config: > (bootloader (bootloader-configuration > (bootloader grub-efi-bootloader) > (target "/boot/efi"))) > (file-systems (cons* (file-system > (device "/dev/sda2") > (mount-point "/boot/efi") > (type "vfat")) >(file-system > (device (file-system-label "guixsd-root")) > (mount-point "/") > (type "ext4")) >%base-file-systems)) This narrows it down quite a bit -- I suspect that we're broken for 'grub-efi-bootloader', since I've been able to successfully reconfigure with 'grub-bootloader' on both of my machines. > I should make a note that I usually don't use efi, and I'm not > completely confident it's all set up properly. I do have a > "BIOS boot" partition on /dev/sda1 too, is that even needed with > efi? I don't believe so. I think the ESP partition on /dev/sda2 is all you need. > Although, I have been using this setup, and the above > definitions, for about 6 months now without any bootloader or > filesystem issues. And the same config is being used to fix the > system when GRUB breaks as well as to reconfigure afterward > (causing the breakage). So my guess is some new update is the > culprit. It certainly sounds like it, and I'm the last person to have touched the bootloader installation code :) I'll look into this ASAP. Thanks again for the bug report! Regards, Jakob signature.asc Description: PGP signature
bug#36876: guix system delete-generations removes custom boot menu entries
Jesse Gibbons writes: > Alternatively, we could save in the store a derivation for the the grub > config generated from the bootloader of the configuration. When the > user calls "guix system delete-generations", the derivation can be run, > and the remaining system generations (if any) can be appended in a menu > like when the user calls "guix system reconfigure". (Although it does > not work for me right now, I'm assuming "guix system delete-generations > 2m" as described in the manual will be implemented in the future.) > > The immediate downsides I see to my solution: > > - It would take space in the store per generation, which can add up if > the user does not often call "guix system delete-generations" and calls > "guix system reconfigure" on a healthy basis. The user could just be > reminded to call "guix system delete-generations" occasionally, and any > official service that automatically updates the system via "guix > system reconfigure" can (and considering how large a generation with a > lot of updated system packages can get, probably should) also be > configured to call "guix system delete-generations". > > - If someone hand-edits the grub config the changes would be lost. This > is the case as it is right now, and grub options can be edited in the > configuration, so I'm not too concerned about this. > > -It would be much simpler to identify menu entries generated by guix > that are no longer in the store and remove them, and remove all empty > submenus. Parsing would make hand-editing grub.cfg more dangerous than > a solution that simply scraps the hand-made changes and rebuilds as I > propose, because the user doing the hand-editing would not necessarily > be aware what patterns the parser checks. It would also be > inconsitent: edits to grub.cfg being scrapped when "guix system > reconfigure" is called, but not when 'guix system delete-generations" > is called looks to me like a good way to introduce a bug to the more > adventurous "Murphy's Law"-type users down the road. I haven't tried it yet, but 'menuentry' seems as though it would be a fairly simple structure to parse. > These are just my thoughts. I would love to hear other downsides to my > solution. I prefer your suggestion to mine and think that the benefits may outweigh the costs in this case. This seems to fit into the Guix idea of purity a bit better than parsing a grub.cfg that may have been overwritten by another system. Regards, Jakob signature.asc Description: PGP signature
bug#36944: Xfce Panel shortcuts after updates might not work
Hello! Sometimes, when Icecat or Pcmanfm-qt update, I am not able to run them from shortcuts I've add to panel as Items (right mouse click - Panel - Add new Item). This is because applications addresses were changed after update (because guix adds hash to application folder). This makes me need to delete shortcut and add again. Xfce is not in account in this. Xfce does not use /home/user/.giux-profile/bin folder for those shortcuts. Xfce uses /gnu/store/hashhashahsh-icecat-60.1/bin/icecat instead. And this is my trouble. Do you think we can solve this?
bug#36909: CVE-2017-837{2,3,4} patches for libmad from Debian
Hi, ma...@secmail.pro wrote: > I think that package "libmad" should be updated to include fixes for the > following vulnerabilities: > https://security-tracker.debian.org/tracker/CVE-2017-8372, > https://security-tracker.debian.org/tracker/CVE-2017-8373, > https://security-tracker.debian.org/tracker/CVE-2017-8374. > This can be done by applying md_size.diff from Debian and replacing > libmad-frame-length.patch with length-check.diff from Debian. I've applied the updates that you recommended in commit aac6c53a7bc9a8d22e88a490ebc99ec79d64a05b on our 'master' branch. Thanks very much for bringing this to our attention. Best, Mark
bug#36870: was: date bug -- really locale bug or ??
Hi Bengt, I'm sorry that I didn't have time to fully read your messages, but if I understand correctly from my quick skimming, the 'date' command from Guix is failing to access the zoneinfo. I think I see your problem. Bengt Richter writes: > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n:g' > openat(AT_FDCWD, > > "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles", > O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) The file name above suggests that your TZDIR variable is not set correctly to allow Guix-built binaries to find the zoneinfo files. On Guix systems, /etc/environment includes an entry that sets TZDIR to the equivalent of "$(guix build tzdata)/share/zoneinfo". When using Guix on top of another distro, an alternative choice might be to set TZDIR to "/usr/share/zoneinfo". I'm not sure which setting is preferable on non-Guix systems. Can you try setting TZDIR and see if that solves the problem for you? Regards, Mark
