bug#34181: guile-hall: no code for module (config)
Hi RicardoOn 25 Jan 2019 5:24 PM, Ricardo Wurmus wrote: Hi Jack, > On Wed, 23 Jan 2019, Alex Sassmannshausen wrote: > >> Hi Jack, >> >> Thanks for your bug report — this is super helpful to debug the >> guile-build-system in guix! >> >> Jack Hill writes: >> >>> The guile-hall package appears to be broken. All hall commands that I >>> run result in a "no code for module (config)" error. >> >> The Guile build system propagates installs of dependent >> modules. Guile-Hall depends on Guile-Config, and it looks like it is >> built fine as part of the built process. >> >> What I'm curious about is whether your search paths are set correctly? >> >> Would you mind trying the following commands: >> $ guile -c "(use-modules (config))" >> $ guile -c "(use-modules (hall clean))" > > Both of these end produce a backtrace that ends in "no code for module > (config)" or "… (hall clean)" > >> $ echo $GUILE_LOAD_PATH +++ $GUILE_LOAD_COMPILED_PATH > > /run/current-system/profile/share/guile/site/2.2 and > /run/current-system/profile/lib/guile/2.2/site-ccache > > So it looks like my environment variables aren't set correctly? > > Is this a user error on my part? I had hoped that guix environment > would set these if needed. I also tried installing guile-hall in my > profile, and a warning about needed vars didn't get printed nor where > they added to my profile's etc/profile. This is likely a problem with the guile-hall package. It should wrap the executables in GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH. I don't think it is, please see my emails on this patch.The binary wraps the paths.It's actually to do with the user needing both guile and the desired guile module in profile/environment.HthAlex Would you like to send a patch to fix this? -- Ricardo
bug#34207: grantlee fails to build
Grantlee has two test failures:
--8<---cut here---start->8---
FAIL! : TestFilters::testDateBasedFilters(date01) Compared values are not the
same
Actual (result): ""
Expected (output): "01"
Loc:
[/tmp/guix-build-grantlee-5.1.0.drv-0/grantlee-5.1.0/templates/tests/testfilters.cpp(117)]
FAIL! : TestFilters::testDateBasedFilters(date02) Compared values are not the
same
Actual (result): ""
Expected (output): "Jan. 1, 2008"
Loc:
[/tmp/guix-build-grantlee-5.1.0.drv-0/grantlee-5.1.0/templates/tests/testfilters.cpp(117)]
--8<---cut here---end--->8---
The tests in templates/tests/testfilters.cpp look like this:
--8<---cut here---start->8---
Dict dict;
…
QDateTime d(QDate(2008, 1, 1));
dict.clear();
dict.insert(QStringLiteral("d"), d);
QTest::newRow("date01") << "{{ d|date:\"MM\" }}" << dict
<< QStringLiteral("01") << NoError;
QTest::newRow("date02") << QStringLiteral("{{ d|date }}") << dict
<< d.toString(QStringLiteral("MMM. d, "))
<< NoError;
--8<---cut here---end--->8---
The following test for “date03” passes:
--8<---cut here---start->8---
dict.insert(QStringLiteral("d"), QStringLiteral("fail_string"));
QTest::newRow("date03") << "{{ d|date:\"MM\" }}" << dict << QString()
<< NoError;
--8<---cut here---end--->8---
IIUC this means: some non-date is injected and the template resulted in
the empty string.
--
Ricardo
bug#34208: xboing fails to start
Starting “xboing” I only get an error message: --8<---cut here---start->8--- /gnu/store/0im1vkwpnj10ix064s71yladv1wmhgvp-xboing-2.4/bin/xboing XBoing - Please wait rekado, initialising xboing ... XBoing - Error: Xlib Error: BadMatch (invalid parameter attributes) Please read `/gnu/store/0im1vkwpnj10ix064s71yladv1wmhgvp-xboing-2.4/docs/problems.doc' document for help. --8<---cut here---end--->8--- “problems.doc” does not mention this error. -- Ricardo
bug#33999: CP437: Invalid Argument on init
My guix installation appears to be working now. Thanks for all your help! I'm not sure if the underlying issue causing the encoding error has been identified; if there's anything else you need from me let me know. It appears that this error is not causing any bad behavior, however. On Wed, Jan 23, 2019 at 7:42 AM Bryan Ferris wrote: > I am indeed using flash storage, specifically a Samsung Evo 850 (it's a > few years old and has had many distress installed and reinstalled on it; > now that I'm thinking about it, it wouldn't surprise me at all if this was > the underlying issue). I'm trying your recommendation of reinstalling and > waiting now. I doubt the installation will finish before I leave for work, > so it will certainly sit for at least 5min. > > Is there any way that we can verify that the files have finished writing? > It seems difficult if the hardware is willing to straight-up lie to us... > > On Mon, Jan 21, 2019, 02:16 Danny Milosavljevic wrote: > >> Hi Ludo, >> Hi Bryan, >> >> On Mon, 21 Jan 2019 10:50:41 +0100 >> Ludovic Courtès wrote: >> >> > It’s not surprising to .lock files to be empty. >> >> I agree. But I didn't filter them out because it would be confusing. >> >> > But where are those >> > files you’re talking about? Surely there’s no /gnu/store on the VFAT >> > EFI partition, right? >> >> Oh, these empty files are on the root partition Bryan provided - there >> are lots and lots of empty files, including very important ones like the >> pam configuration files and the elogind configuration files (which is why >> the login didn't work). >> >> It looks like something crashed or sync(2) wasn't called before reboot or >> something. >> >> Some flash storage devices like to lie about whether they synced something >> (they'll say they did sync but they really didn't yet). If one then cuts >> the power it leads to data loss. But that's all speculation. >> >> @Bryan: Would you be up to doing the installation again but then before >> the >> reboot do a manual invocation of "sync" and then wait 5 min before >> rebooting? >> Is it flash storage? >> >> I didn't check the contents of the ESP partition because they don't >> matter. >> What matters is whether the ESP partition is dirty (it was) and whether a >> manual invocation of "fsck.vfat" succeeds on it (it does). >> >> Out of curiousity I checked ESP anyway now. It has: >> >> EFI >> EFI/GuixSD >> EFI/GuixSD/grubx64.efi >> >> $ ls -l EFI/GuixSD/grubx64.efi >> -rwxr-xr-x 1 root root 155136 11. Jan 16:52 >> /mnt/tmp/EFI/GuixSD/grubx64.efi >> >> That's all there is in the ESP partition. >> >
bug#34211: error running container: mingetty cannot find ttys
On Fri, Jan 25, 2019 at 06:46:48PM +0100, Giovanni Biscuolo wrote: > Hi guix! > > I'm experimenting with my first "system container": it builds but it > fails running > > I build the container using this operating system definition: > > --8<---cut here---start->8--- > $ guix system container ../labs/configuration/container-minimal.scm -r > container-minimal > /localhome/g/guix/labs/configuration/container-minimal.scm:41:19: warning: > 'dhcp-client-service' is deprecated, use 'dhcp-client-service-type' instead > guix system: warning: Your Guix installation is 9 days old. > guix system: warning: Consider running 'guix pull' followed by > 'guix system reconfigure' to get up-to-date packages and security updates. > > /gnu/store/n3577q00rwzccbc50cqhlwhsnkpd1lrr-run-container > --8<---cut here---end--->8--- > > then I start the container as root > > --8<---cut here---start->8--- > $ sudo -E ./container-minimal > [sudo] password for g: > making '/gnu/store/5px51fc8nspwkhni8kprpxcjl6mxznd5-system' the current > system... > setting up setuid programs in '/run/setuid-programs'... > populating /etc from /gnu/store/0a7gn00mqzg5kyrwwd9dyjyvan9vlxsa-etc... > adding user 'root'... > adding group 'root'... > adding group 'wheel'... > adding group 'users'... > adding group 'nogroup'... > adding group 'tty'... > adding group 'dialout'... > adding group 'kmem'... > adding group 'input'... > adding group 'video'... > adding group 'audio'... > adding group 'netdev'... > adding group 'lp'... > adding group 'disk'... > adding group 'floppy'... > adding group 'cdrom'... > adding group 'tape'... > adding group 'kvm'... > adding group 'guixbuild'... > adding group 'sshd'... > usermod: no changes > adding user 'gbiscuolo'... > adding user 'nobody'... > adding user 'guixbuilder01'... > adding user 'guixbuilder02'... > adding user 'guixbuilder03'... > adding user 'guixbuilder04'... > adding user 'guixbuilder05'... > adding user 'guixbuilder06'... > adding user 'guixbuilder07'... > adding user 'guixbuilder08'... > adding user 'guixbuilder09'... > adding user 'guixbuilder10'... > adding user 'sshd'... > registering public key > '/gnu/store/vv1kkj9aqpv1akk7l7vp2kkd695wgxcr-guix-0.16.0-8.7ba2b27/share/guix/hydra.gnu.org.pub'... > registering public key > '/gnu/store/vv1kkj9aqpv1akk7l7vp2kkd695wgxcr-guix-0.16.0-8.7ba2b27/share/guix/berlin.guixsd.org.pub'... > `/gnu/store/cyh3fv8fi86nx4pw8gh4r4hdzi5w31cm-openssh-authorized-keys/gbiscuolo' > -> `/etc/ssh/authorized_keys.d/gbiscuolo' > ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 > nscd: 178 monitoring file `/etc/hosts` (1) > nscd: 178 monitoring directory `/etc` (2) > nscd: 178 monitoring file `/etc/resolv.conf` (3) > nscd: 178 monitoring directory `/etc` (2) > nscd: 178 monitoring file `/etc/services` (4) > nscd: 178 monitoring directory `/etc` (2) > failed to start service 'console-font-tty1' > failed to start service 'console-font-tty2' > failed to start service 'console-font-tty3' > failed to start service 'console-font-tty4' > failed to start service 'console-font-tty5' > failed to start service 'console-font-tty6' > Jan 25 18:30:37 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[191]: > tty5: No such file or directory > Jan 25 18:30:37 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[190]: > tty6: No such file or directory > Jan 25 18:30:37 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[193]: > tty3: No such file or directory > Jan 25 18:30:37 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[194]: > tty2: No such file or directory > Jan 25 18:30:37 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[195]: > tty1: No such file or directory > Jan 25 18:30:37 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[192]: > tty4: No such file or directory > Jan 25 18:30:43 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[200]: > tty6: No such file or directory > Jan 25 18:30:43 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[202]: > tty4: No such file or directory > Jan 25 18:30:43 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[201]: > tty5: No such file or directory > Jan 25 18:30:43 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[204]: > tty2: No such file or directory > Jan 25 18:30:43 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[205]: > tty1: No such file or directory > Jan 25 18:30:43 localhost > /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[203]: > tty3: No such file or directory > Jan 25 18:30:48 localhost > /gnu/st
bug#33517: Problem booting when using btrfs subvolume for /gnu/store
The subvolume and the mount point are independent issues.
For example, I have a subvolume named @ as root volume:
(file-system
(device "/dev/mapper/hd")
(mount-point "/")
(type "btrfs")
(options "compress=lzo,ssd,subvol=@"))
It also appears that the subvolume name must be prepended to the path as if it
just was an ordinary directory (grub.cfg):
…
linux /@/gnu/store/…
…
I could not yet confirm this from documentation, but it works like that for me.
(I semi-manually edit the generated grub.cfg currently.)
So, additionally to stripping the mount point, the subvolume needs to be
prepended (grub.scm):
(let ((kernel (prepend-subvol device-subvol
(strip-mount-point device-mount-point
kernel)))
(initrd (prepend-subvol device-subvol
(strip-mount-point device-mount-point
initrd
…)
This would mean that the menu-entry structure needs the subvol information.
However, I wouldn't want to parse this from the options field in the file-system
entry, so I'd propose allowing a list there, maybe like this:
(file-system
(device "/dev/mapper/hd")
(mount-point "/")
(type "btrfs")
(options '(("compress" . "lzo")
"ssd"
("subvol" . "@"
On the other hand, it might be surprising that declaring the options like this
would work for subvols, while using a string doesn't, especially when some older
documentation/blogs/gists is still hanging around on the internet, so maybe it
would be necessary to parse the options anyway (to this list structure).
I'm lacking experience in guix and guile, so making this work and submit a patch
will take me some time.
Do you think this is sensible?
--
Svante von Erichsen
GPG fingerprint: A78A D4FB 762F A922 A495 57E8 2649 9081 6E61 20DE
signature.asc
Description: Digital signature
