bug#36221: Make GDM *not* restart 504 times on failure
Hi, "pelzflorian (Florian Pelz)" skribis: > If GDM does not start for whatever reason, it attempts to restart 504 > more times which all fail and overwrite all five old logs. It > probably should not attempt to restart at all. I think the auto-restart code that’s triggered is in GDM itself, no? Ludo’.
bug#36238: Problems cross-compiling on core-updates
Hello, --8<---cut here---start->8--- starting phase `check' [...] CC examples/c/lexcalc/lexcalc-scan.o ./examples/c/reccalc/scan.l:13:10: fatal error: parse.h: No such file or directory #include "parse.h" ^ compilation terminated. [...] command "make" "check" "-j" "48" failed with status 2 --8<---cut here---end--->8--- Looks like the same issue. Could you try adding: #:parallel-tests? #f to ‘bison’? Thanks, Ludo’.
bug#36240: indent-code.el is not aware of (package (inherit ...)) style
Hi Robert, Robert Vollmert skribis: > When encountering a package definition that starts > > (package (inherit other-package)) > > etc/indent-code.el will indent the rest of the package body > to align with the start of (inherit. That seems to be a > common idiom, used in roughly half of the instances: > > guix/gnu/packages$ git grep '(inherit ' | wc -l > 905 > guix/gnu/packages$ git grep '(inherit ' | grep package | wc -l > 425 It’s a corner case, and one of the reasons I (and others, I think) are now usually writing: (package (inherit p) …) I’m not sure we can teach Emacs the other rule; maybe sometimes we have to accept limitations like this one. :-) Ludo’.
bug#36242: Repacked source checkouts get a misleading file name
Hello, Marius Bakke skribis: > From 0c44561d0d45de91f4674d659b86d740642ae801 Mon Sep 17 00:00:00 2001 > From: Marius Bakke > Date: Sun, 16 Jun 2019 10:50:15 +0200 > Subject: [PATCH] packages: Keep full version in file name when repacking > source checkouts. > > * guix/packages.scm (patch-and-repack): If ORIGINAL-FILE-NAME is a source > checkout, drop the '-checkout' part so the version-detecting code works. LGTM! For ‘core-updates’, right? Thanks, Ludo’.
bug#36238: Problems cross-compiling on core-updates
Carl Dong writes: > Unfortunately b1593c1c4fd8f4fc6df4c43cab51334426e3aa76 still doesn't work, > I've > attached the log. Drat. Plain text log: --8<---cut here---start->8--- Making check in . make[2]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1' GEN doc/bison.help make examples/c/calc/calc examples/c/lexcalc/lexcalc examples/c/mfcalc/mfcalc examples/c/reccalc/reccalc examples/c/rpcalc/rpcalc examples/c++/calc++/calc++ examples/c++/simple examples/c++/variant examples/c++/variant-11 ./tests/bison tests/atconfig tests/atlocal make[3]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1' YACC examples/c/calc/calc.c YACC examples/c/lexcalc/parse.c LEX examples/c/lexcalc/scan.c YACC examples/c/mfcalc/mfcalc.c YACC examples/c/reccalc/parse.c YACC examples/c/rpcalc/rpcalc.c YACC examples/c++/calc++/parser.stamp LEX examples/c++/calc++/scanner.cc YACC examples/c++/simple.cc make[3]: 'tests/bison' is up to date. make[3]: Nothing to be done for 'tests/atconfig'. make[3]: 'tests/atlocal' is up to date. YACC examples/c++/variant.cc YACC examples/c++/variant-11.cc CC examples/c/reccalc/reccalc-scan.o CC examples/c/lexcalc/lexcalc-scan.o ./examples/c/reccalc/scan.l:13:10: fatal error: parse.h: No such file or directory #include "parse.h" ^ compilation terminated. make[3]: *** [Makefile:4148: examples/c/reccalc/reccalc-scan.o] Error 1 make[3]: *** Waiting for unfinished jobs examples/c/lexcalc/scan.l:10:10: fatal error: parse.h: No such file or directory #include "parse.h" ^ compilation terminated. make[3]: *** [Makefile:4106: examples/c/lexcalc/lexcalc-scan.o] Error 1 --8<---cut here---end--->8--- Hopefully fixed in 2c35ae82192fd6f1732b15fa41aec87aa61a1879, thanks for reporting it! signature.asc Description: PGP signature
bug#36215: guix system docker-image fails when store items contain non-ascii characters
Hi Björn, Björn Höfling skribis: > On Fri, 14 Jun 2019 23:05:06 +0200 > Björn Höfling wrote: > >> qemu-system-x86_64: warning: hub 0 is not connected to host network > > [..] > >> ERROR: In procedure lstat: >> In procedure lstat: No such file or directory: >> "/guixsd-system-root/gnu/store/6w65nzbc3ah30y5kr4zx9rcgknpjr1f5-nss-certs-3.43/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem" >> ^MESC[Kregistering 177 items [ 152.952990] Kernel panic - not >> syncing: Attempted to kill init! exitcode=0x0100 [ > > I looked a bit around the code, added some debugging outputs and found > out that finally in gnu/build/vm.scm in procedure load-in-linux-vm a > QEMU VM is started where the docker image will be created in. > > To test things, I entered a container with qemu-minimal: > > guix environment -N -C --share=/dev/kvm --share=/tmp/.X11-unix/ --ad-hoc > coreutils less findutils emacs qemu-minimal nss-certs > > And started an existing VM with the store being available over virtfs: > > [env] $ qemu-system-x86_64 -m 2048 -smp 2 \ >-boot menu=on \ >-drive file=guixsd0.2018-02-19.qcow2 \ >-drive format=raw,file=swap.img \ >-virtfs > local,id=store_dev,path=/gnu/store,security_model=none,mount_tag=store > > In that machine, I mounted the fs: > > mount -t 9p -o trans=virtio store /mnt > > When I then looked at /mnt/...nss-certs.../..., the non-ascii > characters are looking all good. > > I think the encoding-problem is more in the script. Yes, it looks similar to what 9c941364bfc0120e3ab5c5c4cc71a9a302d59a2b fixed. Fixed in ed504cafa23c34bfa1823a4d5abf3ad55205484b. Thanks! Ludo’.
bug#36261: Does not reboot after guix init system
As manual says 'Once that command has completed—and hopefully succeeded!—you can run reboot and boot into the new system.', guix really does not reboot every time after manual installation.
bug#36262: cannot install bootloader to root partition
Hello! I was not able to install Guix having 2 partitions: /dev/sda1 ext4 Linux filesystem /dev/sda2 Linux Swap `guix system init` says in this case: guix system: error: failed to install bootloader Screen: http://0x0.st/zeLs.jpg
bug#35998: Typo on guix blog. ATTN: Ludovic Courtès
Hello David, David Loyall skribis: > Hi. I think there is a typo on this blog post: > https://www.gnu.org/software/guix/blog/2019/gnu-guix-1.0.1-released/ > > The link on the text "The installer can now create Btrfs file systems" > points to bug #35716, but I think it was supposed to point to some > other one like maybe #35657. Indeed, this is now fixed. Thanks and apologies for the delay! Ludo’.
bug#36262: cannot install bootloader to root partition
Hi, which grub is that? grub-efi? pgpWU7ufzDsqF.pgp Description: OpenPGP digital signature
bug#36264: shepherd doesn't capture service stdout/stderr
On a pretty fresh Guix System install, I see some regular sshd error messages on tty1 (which I guess means they’re written to /dev/console). Also, setting up a regular shepherd service via make-forkexec-constructor for a program that logs to stderr (postgrest which I’m in the process of packaging), all output goes to tty1. Compare the discussion at https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00186.html
bug#36262: cannot install bootloader to root partition
Danny, Danny Milosavljevic wrote: which grub is that? grub-efi? i386-pc, so ‘BIOS’ (which means it's trying to use blocklists, which is fragile & won't work without --force). Kind regards, T G-R signature.asc Description: PGP signature
bug#36262: cannot install bootloader to root partition
I have another laptop (Lenovo G50-30) where Guix works on this partition layout I've made manually: # fdisk -l /dev/sda ... Device Boot Start End Sectors Size Id Type /dev/sda12048 23000 229997953 109.7G 83 Linux /dev/sda2 23640 234441647 4441008 2.1G 82 Linux swap / Solaris But all the new installations on other two notebooks with the same layout do not work. June 17, 2019 5:07 PM, "Tobias Geerinckx-Rice" wrote: > Znavko, > > zna...@disroot.org wrote: > >> bug#36262: cannot install bootloader to root partition > > Installing GRUB to your root partition isn't supported, and should > never be necessary anyway. > >> Hello! I was not able to install Guix having 2 partitions: >> /dev/sda1 ext4 Linux filesystem >> /dev/sda2 Linux Swap > > This is a strange partition layout; it's missing a ‘BIOS boot > partition’ and can never work without forcing GRUB to do something > it doesn't like to do. > > Did you create this layout manually? If so, why? > > Kind regards, > > T G-R
bug#36262: cannot install bootloader to root partition
Znavko, zna...@disroot.org wrote: bug#36262: cannot install bootloader to root partition Installing GRUB to your root partition isn't supported, and should never be necessary anyway. Hello! I was not able to install Guix having 2 partitions: /dev/sda1 ext4 Linux filesystem /dev/sda2 Linux Swap This is a strange partition layout; it's missing a ‘BIOS boot partition’ and can never work without forcing GRUB to do something it doesn't like to do. Did you create this layout manually? If so, why? Kind regards, T G-R signature.asc Description: PGP signature
bug#36262: cannot install bootloader to root partition
Yes, I use Bios grub everywhere. June 17, 2019 5:10 PM, "Tobias Geerinckx-Rice" wrote: > Danny, > > Danny Milosavljevic wrote: > >> which grub is that? grub-efi? > > i386-pc, so ‘BIOS’ (which means it's trying to use blocklists, > which is fragile & won't work without --force). > > Kind regards, > > T G-R
bug#36267: Stable bootstrap sources
Guix, I noticed that 'tcc-boot0' from (gnu packages commencement) is downloaded from what appears to be a GitLab-generated tarball (this is on the 'core-updates' branch). To ensure that any revision of Guix can be easily bootstrapped "forever", it would be great to mirror this and adjust the URL in case GitLab generates a new one, like we've seen GitHub do in the past. signature.asc Description: PGP signature
bug#36264: shepherd doesn't capture service stdout/stderr
Hello guix, Robert Vollmert ezt írta (időpont: 2019. jún. 17., Hét 18:55): > On a pretty fresh Guix System install, I see some regular > sshd error messages on tty1 (which I guess means they’re > written to /dev/console). Also, setting up a regular > shepherd service via make-forkexec-constructor for a > program that logs to stderr (postgrest which I’m in the > process of packaging), all output goes to tty1. > This is also on my todo list for a while, so I can provide some additional information. I noticed this on two services I was using: ntp-service-type with default config and prometheus-node-exporter-service-type with default config. I hope that helps somewheat. > Compare the discussion at > > https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00186.html Best regards, g_bor > > > > >
bug#36262: cannot install bootloader to root partition
Hi Tobias, Tobias Geerinckx-Rice writes: > zna...@disroot.org wrote: >> bug#36262: cannot install bootloader to root partition > > Installing GRUB to your root partition isn't supported, and should > never be necessary anyway. > >> Hello! I was not able to install Guix having 2 partitions: >> /dev/sda1 ext4 Linux filesystem >> /dev/sda2 Linux Swap > > This is a strange partition layout; it's missing a ‘BIOS boot > partition’ and can never work without forcing GRUB to do something it > doesn't like to do. > > Did you create this layout manually? If so, why? FWIW, I used this partition layout for years, including on Guix systems, and it worked fine. Long ago, bootloaders were only able to access the first 8 GB or so of the disk, because of limitations in the old INT 13h BIOS interface. Maybe this is still an issue on some ancient machines, but I tend to use older hardware (my best laptop is ~11 years old, and that's typical for me) and I've not had this issue in recent memory. The only reason I started using a separate boot partition again is because I now encrypt my root partition. Mark
bug#36262: cannot install bootloader to root partition
Znavko, zna...@disroot.org wrote: I have another laptop (Lenovo G50-30) where Guix works on this partition layout I've made manually: # fdisk -l /dev/sda ... ^ You removed the most important part, please don't do this on help lists. Still, we can tell that this is an ‘mbr’ layout: Device Boot Start End Sectors Size Id Type /dev/sda12048 23000 229997953 109.7G 83 Linux /dev/sda2 23640 234441647 4441008 2.1G 82 Linux swap / Solaris ^^^ But all the new installations on other two notebooks with the same layout do not work. They aren't the same: the one in your screenshot is a completely different ‘gpt’ layout. Hence my unanswered question: Did you create this layout manually? If so, why? Although now I suspect there was no reason and that the installer isn't to blame. So you can either: - throw away your existing layout and create new MBR disklabel. Your partitioning software will ask you or provide an option somewhere. Since modern partitioning software leaves a huge gap before the first partition, GRUB will nestle cosily into that first unused ~MiB. - keep it as GPT (it has some minor features MBR doesn't), and create an additional GPT ‘BIOS boot partition’ as recommended before. It only needs to be a few 100 KiB, so I use the space before the first partition (= before the first megabyte; turning off ‘alignment’ in your partitioning software). This tiny partition is for use by GRUB, and GRUB alone: do not format or mount it. Both options work equally well, but you need to choose. Kind regards, T G-R signature.asc Description: PGP signature
bug#36262: cannot install bootloader to root partition
Mark H Weaver wrote: FWIW, I used this partition layout for years, including on Guix systems, and it worked fine. Impossible, sorry. Kind regards, T G-R signature.asc Description: PGP signature
