<KarlJoad>The partitions are fine, everything is still there, and I can confirm that if I boot a USB. But I need to perform either a guix system init or a guix system reconfigure to make the disk listed in the EFI boot options again. <KarlJoad>The odd thing is, this problem does not happen on my laptop. <nckx>One guess the first machine somehow invalidates boot variables that it (questionably) considers ‘stale’, because the drive/file to which it points is ‘gone’, so that when you plug your Guix SSD back in the firmware has forgot that there was an entry for Guix, and where to find the boot loader. You could verify this hypothesis by running ‘efibootmgr’ right after reconfiguring Guix, then remove the Guix SSD and run it again (from a different d <nckx>istro). If anything changes, well, your firmware is being [even more than usually] stupid. <nckx>(Why are you swapping out your SSD that much?) <nckx>If that hypothesis doesn't work out I'm sure we can come up with 3 others, because the world of UEFI firmware is a world of bizarre bugs. <nckx>Although Guix hardly cooperates; for example, it doesn't handle removable drives in the way it should (by installing \EFI\BOOT\BOOTX64.EFI instead of GRUBX64.EFI). <nckx>Simply renaming the latter to the former is likely to fix your boot problems in this case, IME. I had a desktop like that once. <KarlJoad>nckx: I switch them out for boot reasons. On the last computer it was easier to switch disks than work with the UEFI. <KarlJoad>It might be important that this is a server motherboard too, not a desktop one. A SuperMicro H12. <nckx>Is Guix still offered as a boot option when you've removed & reattached the Guix drive? <KarlJoad>The disk has completely disappeared. It does not show up in the boot list at all. Only the boot-over-ethernet devices and the UEFI shell. <nckx>‘Disks’ aren't bootable, though. Files are. If it forgot to look for grubx64.efi and there's no ‘standard’ bootx64.efi there, it won't be able to boot. I'm curious if renaming (or copying) grubx64.efi to bootx64.efi before pulling it out helps any. <KarlJoad>I just finished a reconfigure. I'll check the efibootmgr and see what's up. I'll also check for the grubx64.efi file too. <patched[m]>What's the best way for finding what to import to refer to a specific package I can find with guix search? E.g., I want to know what I need to import to get gcc-toolchain. <nckx>patched[m]: guix show gcc-toolchain, the ‘location’ field is the name of the module. <KarlJoad>nckx: After a reconfigure, Guix shows up as boot option 0000*, and is the first in the boot order. The grubx64.efi is located at /boot/efi/EFI/Guix, where /boot/efi is partition /dev/sdb1. <nckx>No boot/bootx64.efi, right? <nckx>(Could be, from a previous OS.) <nckx>patched[m]: foo/bar/mod.scm → (foo bar mod), always <KarlJoad>On NixOS, I have /boot/EFI/BOOT/BOOTX64.EFI and UEFI OS (which is NixOS) as boot option 0009* as the first option in the boot order. But boot entry 0000* is nowhere to be found. <nckx>It should be persistent for you to be able to boot Guix next. If it's gone, the firmware will look *only* for \EFI\BOOT\BOOTX64.EFI (the UEFI spec default) on any new drive. It does not recursively search EFI or anything. It will never see \EFI\Guix\GRUBX64.EFI, and will not be able to boot Guix. <nckx>So you could mkdir /boot/efi/EFI/BOOT && cp /boot/efi/EFI/Guix/GRUBX64.EFI /boot/efi/EFI/BOOT/BOOTX64.EFI as a hack. Drawback is that the copy will never be updated. I can say only that it worked for me in practice. <nckx>Interesting that NixOS just claims the default name, doesn't try to play nice with other OSes. <nckx>But then they don't use GRUB anymore, do they? <nckx>I'm rambling, because it's past my bed time. Good night all. <KarlJoad>Back on the Guix installer, boot entry 0000* is still not there, but the USB key is first in the boot order. But the EFI file is still in the same spot. So I will try the copy you mentioned. <nckx>Right, the EFI file won't go anywhere, but it seems the firmware is amnesiac and loses the pointer (in NVRAM) to it after each drive swap, so it becomes invisible. <KarlJoad>That is... odd... The NixOS entry 0009 has been replaced by USB KEY, so something must be remembered somewhere. I guess this leads into the question, why does Guix put its EFI file in a non-specification location? <KarlJoad>nckx: Your solution of copying the boot EFI file to /boot/efi/EFI/BOOT/BOOTX64.EFI worked. Now I guess, why does Guix put the EFI file in a non-standard location? <nckx>sneek: later ask KarlJoad: Why do you say ‘Guix puts the EFI file in a non-standard location’? <nckx>sneek: later ask KarlJoad: If this is because of me saying \EFI\BOOT\BOOTX64.EFI is the *default* earlier: if every OS used the same location, what would be the point? You could never multi-boot that way. <nckx>sneek: later tell KarlJoad: What could help in your unusual situation would be to add ‘--removable’ support to Guix's grub-efi-bootloader. <nckx>sneek: later tell KarlJoad: This treats the drive like removable storage (as you do), by (1) not bothering with the current machine's NVRAM and (2) instead installing GRUB to BOOTX64.EFI (overwriting any previous OS there, which is why it must be opt-in). ***Server sets mode: +Ccntz
<KarlJoad>sneek: later ask nckx I think see what you mean by that preventing multi-boot. I am going to try the grub-efi-netboot-bootloader, to see if that works. <sneek>Welcome back KarlJoad, you have 4 messages! <sneek>KarlJoad, nckx says: Why do you say ‘Guix puts the EFI file in a non-standard location’? <sneek>KarlJoad, nckx says: If this is because of me saying \EFI\BOOT\BOOTX64.EFI is the *default* earlier: if every OS used the same location, what would be the point? You could never multi-boot that way. <sneek>KarlJoad, nckx says: What could help in your unusual situation would be to add ‘--removable’ support to Guix's grub-efi-bootloader. <sneek>KarlJoad, nckx says: This treats the drive like removable storage (as you do), by (1) not bothering with the current machine's NVRAM and (2) instead installing GRUB to BOOTX64.EFI (overwriting any previous OS there, which is why it must be opt-in). ***Server sets mode: +Ccntz
***Server sets mode: +Ccntz
***Server sets mode: +Ccntz
<apteryx>is anyone having the "55444 - elogind startup race between shepherd and dbus-daemon" bug? ***roptat is now known as Guest8848
***toluene5 is now known as toluene
<apteryx>or better, does someone have a repro to trigger it? <fcw>In package definitions, am I allowed to use `system` instead of `invoke` to run scripts? `invoke` uses `system*` which ignores SIGINT and SIGQUIT. Apparently, the package I am building (smlnj) behaves differently if SIGINT is ignored during the build. <jpoiret>sneek, later tell KarlJoad: There's no way to directly access the --removable option of grub right now unfortunately, but you could use --no-bootloader and manually install grub (easy but annoying), or just code up a new bootloader that would be the same as grub-efi but its install-grub-efi procedure would use --removable <efraim>fcw: 'invoke' is a wrapper around '(zero? (system* ...' to check the return value. If you want to use `system` specifically then leave a comment explaining why and it should be fine <attila_lendvai>hrm... maybe i could temporarily duplicate the patched version of define-configuration in my channel in a new module... <jpoiret>gnome should work well though, since it's the "default" <zeta_reticuli>jpoiret: how impressive. I use it too. But haven't fully adjusted <fcw>efraim: Noted. Thanks. <attila_lendvai>bovid_19, thanks for the feedback! since then i have moved a duplicate of it into my channel and testing it now. this way i can publish my code while the Guix maintainers catch up with that patchset. <aadcg>hi guix. why does M-x guix-hidden-packages show xorg-server as a hidden package? <bovid_19>attila_lendvai: Is it possible that I know your name from around Common Lisp? It seems to ring a bell. <aadcg>I ask, since xorg-server doesn't seem to be define as a hidden-package, in the way that gcc, for instance. is <attila_lendvai>bovid_19, yep, i'm one of the dwim.hu guys. but i'm not too active in CL nowadays... <bovid_19>aadcg: maybe because of `xorg-server-for-tests'? It uses a hidden package that inherits `xorg-server' <bovid_19>What's the logic behind the module being public and the package hidden? Is it so you can refer to it as a dependency without e.g. it appearing in package searches? <sneek>Welcome back nckx, you have 3 messages! <sneek>nckx, KarlJoad says: I think see what you mean by that preventing multi-boot. I am going to try the grub-efi-netboot-bootloader, to see if that works. <sneek>nckx, KarlJoad says: In this case, overwriting previous OS's GRUB by using removable is OK, because there is no other OS on this disk. That was kind of the point. Change OS by changing disk, prevents other OSs (Windows) from tampering with my Linux. <sneek>nckx, KarlJoad says: Ok, so I misunderstood the netboot variant. How would I go about making a removable version then? I don't see any easy way to add the --removable flag. <aadcg>bovid_19: I thought of it too, but doesn't it look fishy? gcc-toolchain inherits from a hidden package, gcc, and it's hidden <nckx>It's separate from xorg-server because there's no urgent reason to rebuild all users (which are numerous) when xorg-server gets a bump. <nckx>aadcg: Does emacs-guix give location information? <nckx>It's strangely slow to install here… <bovid_19>nckx: none. I meant `xorg-server-for-tests', but I realized that it wasn't a module. <aadcg>nckx: I see, but I'm still confused... shouldn't xorg-server be non-hidden and xorg-server-for-tests hidden <nckx>Oh, because it's building. <aadcg>nckx: emacs-guix does give location information, it's very helpful <nckx>aadcg: I'm still installing it, but if it deals with package names (rather than variable names), the -for-tests one might be ‘masking’ the regular one. They both have the same package name, xorg-server. <bovid_19>aadcg: couldn't the one you find as hidden be the `xorg-server' from `xorg-server-for-tests'? <nckx>aadcg: Aha! And where does it think ‘xorg-server’ is defined? 5251-ish or 5376-ish? <aadcg>nckx: makes sense. I find it a bit undesirable that xorg-server is hidden since I can't read its manpages for instance <nckx>Not according to Guix, I mean. <nckx>Now ‘Starting Guix REPL…’ is taking forever… <bovid_19>aadcg: doesn't `guix show xorg-server' return anything for you? <aadcg>what happens when you run man xorg? <nckx>I'd need to guix install xorg-server for that. Sec. <nckx>aadcg: I get the Xorg(1) man page. <aadcg>nckx: right, you need to install xorg-server <aadcg>my point is that if the program is there somewhere, the manpages should be available <aadcg>for instance, I have installed elogind explicitly and I can read its manpages <nckx>Something probably propagates it, or somesuch (I didn't check). <aadcg>ok, it all makes sense now. thank you nckx <nckx>Note I just logged on and am answering random questions, if there's a big picture I didn't read far enough back to see it yet. :) <nckx>‘guix-geiser-eval: Sorry, the evaluation is aborted because it has taken too much time.’ <nckx>This is not a slow machine. Hm. <aadcg>btw, does M-x guix-command work for you? <bovid_19>I've been wondering about the documentation (info, man) for a while. Is there a default method to install the documentation of a package? <nckx>aadcg: I can't say, because of that previous failure. <nckx>guix-geiser-eval: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception: <nckx>/home/nckx/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:169:7: Unknown # object: "#~" <nckx>That didn't paste because of the leading / <nckx>bovid_19: The default (well, convention) in Guix is to include documentation in the main output. So you shouldn't need to install it separately. A few packages that have particularly chonky docs split them out into :doc outputs, but that's more for HTML and stuff, not info/man, and very rare. <nckx>If you mean ‘install only manpages without the rest of the output’: no. <nckx>It's nothing unique to deploy.scm, if I remove the #~ and friend there I get: guix/scripts/home.scm:279:10: Unknown # object: "#~" <nckx>Why the hell are readers broken in Geiser? <nckx>It's too early for me to want to know. <nckx>Maybe later, with a drink. <civodul>efraim: hey! i just noticed that %gcc-10-armhf-micro-architectures includes armv8 option, but AFAIK armv8 = aarch64 <civodul>i guess we can move them to %gcc-10-aarch64-micro-architectures? <nckx>civodul: You asked a while back about ‘git am’ being picky. Perhaps the answer you wanted was ‘--patch-format mboxrd’. <nckx>That fixes most mumi failures for me. <nckx>I just realised I've actually memorised it as mboxricar-do. <civodul>nckx: actually, i think i found the reason: Gnus or article-mode treats "--" specially, as something that introduces a signature <civodul>when you have a patch in a patch, you're likely to have a literal "--" line <civodul>solution: pipe the raw message into git am <nckx>…it treats the entire patch as a signature? <bovid_19>nckx: Allright. Having missed aadcg's correction from "I have installed elogind <bovid_19>explicitly and I can read its manpages" to "[I] haven't [...]" and seeing your <bovid_19>reply "Ideally, you wouldn't" had me a bit confused. The documentation I've been missing is probably part of other packages that are not installed. For example, I expected to have the docs for xorg available since it is part of my system, but it seems like I need to explicitly install `xorg-server'. There might also be buggy definitions, but <bovid_19>I'm glad to know now that they should be installed. <civodul>nckx: re Geiser, if you start by doing C-c C-k in (guix gexp), it prolly works <civodul>that should happen automatically though, since files that use gexps imports (guix gexp) <nckx>So I can't be ‘in’ anything, I think. <foobarxyz>nckx: thanks for including the extra tools in clang@14 <sneek>Welcome back foobarxyz, you have 1 message! <sneek>foobarxyz, nckx says: clang@14 now includes the extras in the main output just like previous versions. Pull! <nckx>Sorry: M-x guix-command <- civodul <nckx>It bugged me once I noticed :) <foobarxyz>Now i've got a guix installation that is 20 days old <foobarxyz>I've done a guix pull and I was expecting to find clang@14 afterwords with guix search <foobarxyz>I was expecting a git pull to pick the latest packages, but it is not the case for me <nckx>‘guix search’ doesn't handle NAME[@VERSION] ‘specs’, it takes a REGEXP that matches 0 or more package names. <nckx><but it is not the case for me> Probably not true, hence. <foobarxyz>yes, sorry I meant to say guix search clang does not list version 14 <foobarxyz>and guix install clang@14 returns with "error: clang: pckage not found for version 14" <foobarxyz>am i right in my expectation a git pull should pick the latest versions of packages instaallable? <nckx>That's it's raison d'etre. <nckx>That is literally the same commit I'm on now. <foobarxyz>sorry, this is slightly different from a request to include extras in clang@14; my old guix installation which was 20 days old and I've just pulled now does not list clang@14 as version i can install <nckx>guix show clang@14 — I don't know how to break this to you — shows clang@14 <nckx>foobarxyz: Yes, I get it. <foobarxyz>Computing Guix derivation for 'x86_64-linux'... - <foobarxyz> 864 new packages: alfis, archivebox, atomic-queue, avizo, aws-c-sdkutils, barrier, bart, bloomberg-bde, <nckx>But the question is: why does my identical guix show it. <foobarxyz> 1,732 packages upgraded: acpica@20220331, agda@2.6.2.2, aircrack-ng@1.7, akku@1.1.0, anonip@1.1.0, <foobarxyz> apache-arrow@7.0.0, apl@1.8-r1550, aptdec@1.7-2.5140597, arb@2.22.1, artanis@0.5.1, assimp@5.2.2, asymptote@2.80, … <nckx>foobarxyz: Please don't paste walls of text in the channel. <nckx>Use paste.debian.net for anything > about 3 lines. <nckx>foobarxyz: Can you confirm that ‘guix show clang@14’ shows ‘guix show: error: clang@14: package not found’ ? <nckx>And if so, paste.debian.net your ‘guix describe’ output, as well as that of ‘command -v guix’ (although the former should imply the latter, let's make sure). <foobarxyz>guix install clang@14 : "guix install: error: clang: package not found for version 14" <nckx>You've ‘guix install’d guix. <nckx>guix remove guix and we shall never speak of this again. <nckx>(You should never guix install guix, although really there should be a warning to that effect :) <nckx>You ran ‘guix install guix’ or the equivalent (put ‘guix’ as a package in a manifest) at one point. <nckx>Then run ‘hash guix’ and ‘command -v guix’ again. It should point to .config/guix/current. <nckx>Using guix to install a (potentially very old) version of itself never ends well, and should really be warned about. You shouldn't have been expected to know this. (Although I always wonder what drives people to install guix using guix…) <civodul>nckx: hmm not sure; M-x guix works for me, except for service lookup (i haven't investigated) <nckx>foobarxyz: Another weird thing: you should make sure that /home/xyz/.config/guix/current/bin is in your $PATH, before /home/xyz/.guix-profile/bin, but Guix System should do this automatically. <nckx>civodul: I meant guix-command, sorry. <foobarxyz>I can also see clangd installed, so all good, thank you so much for your help! <nckx>I don't have much experience with that. If you know where PATH is set up, you should try correcting that, but I can't say more. <nckx>foobarxyz: Happy to (finally) be of service. <efraim>civodul: it's been a while since I looked deeply into it, but there is the possibility of 32-bit armv8 chips. Also, by having armv8 in armhf it allows us to have armhf binaries that are optimized to run on aarch64 machines (like i686 -> x86_64). <efraim>but mostly I got it by looking at the GCC code, and it also lists the armv8 options there for optimizations <bjc>nckx: if you do end up figuring out how to get geiser to deal with #~, let me know. drives me craze *civodul borked their Emacs, had to reboot it <nckx>The true test of ‘is it an OS?’. <bjc>i think i saw someone complain about getting “error: #<<platform> target: "x86_64-linux-gnu" system: "x86_64-linux" linux-architecture: "x86_64" glibc-dynamic-linker: "/lib/ld-linux-x86-64.so.2">: invalid G-expression input” yesterday <bjc>was that ever resolved? <mothacehe>bjc: yes jpoiret sent a patch about it, i'm reviewing it atm <bjc>ah great. do you have a bug number for it? <patched[m]>If a software provides a .tar.gz with vendored dependencies, should I use this or is it better to create packages for all dependencies individually? Many of the deps seem to be forks that the developer has created of other libraries for some reason. <civodul>bjc: the peril of exwm + type-break + pinentry fighting to get keyboard input, and in the end, everybody loses <bjc>i love emacs, but i use tramp way too much to ever entertain the notion of exwm <bjc>sway + emacs is about as close as i can get <aadcg>bjc: why does exwm make tramp less ussable? <bjc>it's not that, it's that tramp makes everything less usable <bjc>and i can't have my window manager hanging indefinitely or crashing <nckx>patched[m]: And this is why bundling is always bad ☹ Does the package really need the weird NIH forks? In Guix, we oppose bundling and prefer using separate packages whenever possible. <mothacehe>jpoiret: thanks for the platform patchset :). i tried "make as-derivation", guix build & guix system image commands, everything seems fine. OK for you if i proceed? <patched[m]><nckx> "patched: And this is why..." <- What is NIH? <patched[m]>I don't know if it really requires the forked version as dependencies, I can ask the creator. It's a go package and I don't have much experience with those or why somebody would maintain their own forks of deps. *nckx urges jpoiret to say yes. :) Can't be worse than the current situation. <mothacehe>mmh there's a suspicious error in tests/gexp.scm <nckx>patched[m]: NIH = ‘Not invented here’, implying an eagerness to fork without good reason. <nckx>patched[m]: Don't Go packages use URL-like qualified package names? So we could package the fork without clashes or ugly foo-for-bar names. <nckx>I think Go's poor design encourages forking/bundling, might not be the author's ‘fault’ here. <patched[m]>Yeah, I could do that, just feels unnecessary to add like 10 packages just for one program. <apteryx>civodul: hi! we don't happen to have a way to reproduce "elogind startup race between shepherd and dbus-daemon" (#55444), do we? <jpoiret>was gone for a while, mothacehe: what is that error you're talking about? <mothacehe>in (test-gexp) there are several tests assuming that mips64el-linux is a triplet <mothacehe>leading to a #f in (lookup-platform-by-target target) of cross-kernel-headers procedure <mothacehe>s/mips64el-linux/mips64el-linux-gnu/ solves it <mothacehe>tests/guix-pack.sh and tests/guix-packages.sh are also failing <nckx>I'm running check-system and ‘guile \ /home/nckx/guix/scripts/guix build -m ./etc/system-tests.scm -K’ has used 20 CPU-minutes so far. Is that fishy? This process alone is running @ 200%; it has no children. <nckx>strace is just endless newfstatat calls that look (at first glance) like a big repeating loop. <qzdlns[m]>wow TIL one may launch R sessions under guix shell in org-mode <qzdlns[m]># -*- eval: (progn (add-hook 'before-save-hook 'org-babel-tangle nil t) (setq-local org-babel-R-command (format "cd %s && guix shell -- R --slave --no-save" default-directory))) <civodul>apteryx: hi! you can see the "elogind already running" messages when booting a %desktop-services kind of machine (or VM), but most of the time it's harmless: you get your GDM screen and all <civodul>on slow machines though, you can occasionally end up without Xorg <civodul>perhaps we can reproduce it in a VM without -enable-kvm, who knows <jpoiret>running the test-suite right now to see what's up <civodul>apteryx, mothacehe, nckx, rekado_: i'm about to reconfigure berlin to get Cuirass evaluations back up (as written on guix-sysadmin) *nckx logs in just in case. <jpoiret>great! i'll look at the pack and packages tests *nckx su - 's just in case. <civodul>mothacehe: this patch LGTM (those target strings were probably unintentionally "wrong") <jpoiret>lgtm as well if that matters :p i was about to do the same <jpoiret>once that's sorted out, ill try reconfiguring on staging <jpoiret>shouldn't lookup-platform-by-target error out instead of returning #f if it cannot find a corresponding platform? <apteryx>civodul: so the desktop test should have that message? I think I tried but failed to see it <apteryx>civodul: should be safe provided your at the tip of the master branch of maintenance :-) <civodul>re elogind, you can see it when booting interactively <civodul>not sure if you can see it in the output of the test though <apteryx>I think I couldn't. I'll try a more vanilla config + VM <jpoiret>mothacehe: i don't have any errors in guix-package.sh, the guix-pack.sh one is again a wrong target string <jpoiret>mothacehe: want me to pick up your changes and send a patch? <mothacehe>jpoiret: sure thanks :) i also cannot reproduce the guix-package.sh failure <Lembrun>Anyone succeded in making xdg-portal works under sway? Running dbus-monitor shows that some interfaces that are supposed to be provided by xdg-desktop-portal are missing for whatever reasons <Lembrun>use case is running flameshot with sway <civodul>berlin reconfigured, Cuirass restarted! <apteryx>in /var/log/messages: May 24 17:26:48 localhost postgres[106582]: [6-1] 2022-05-24 15:26:48.061 GMT [106582] ERROR: duplicate key value violates unique constraint "pg_statistic_relid_att_inh_index" <jpoiret>you need to `dbus-update-activation-environment WAYLAND_DESKTOP` <jpoiret>then start xdg-desktop-portal-wlr, pipewire, wireplumber and xdg-dekstop-portal <Lembrun>exec --no-startup-id dbus-update-activation-environment --all and this should be enough right? it's at the bottom of my sway config <jpoiret>i'd favor to only update WAYLAND_DISPLAY *apteryx looks at the jami system tests failures <civodul>bah, looks like evaluation 341098 hung, just differently :-/ <maximed>Does someone know where the GPL compatibility page is located? I cannot find it anymore. <maximed>the table with (L/A/)GPL v2/v3 only/or-later <civodul>oh actually it's "okay": the evaluation is failure because of: #<&gexp-input-error input: #<<platform> target: "x86_64-linux-gnu" system: "x86_64-linux" linux-architecture: "x86_64" glibc-dynamic-linker: "/lib/ld-linux-x86-64.so.2">>>) <zeta_reticuli>how can I use locate command in Guix System? It can't create mlocated.db in /gnu/store/ <apteryx>attila_lendvai: I've read the whole thread now, thanks. Seems perhaps it's best to wait for Shepherd 0.9.1 :-) <civodul>apteryx: it's out but it doesn't fix this particular issue (the fact that 'start' can start the same thing several times) <civodul>in the meantime, we could fix the Jami tests by using a different method to determine whether the service is up <civodul>for example by checking whether the PID file is there, or whether the port is opened <civodul>(i have plans for a fix but i'd like to focus on working towards a Guix release first) <apteryx>civodul: this would make it pass, but the problem would remain, right (multiple daemons actually being started?) <civodul>apteryx: multiple daemons are started, but only if you explicitly start several times concurrently while it's being started <civodul>so it's definitely not great, but not something that normally happens <apteryx>I see, so right now the "problem" is that it's doing (start-service 'jami) to check the status of the service (e.g. 'running) <apteryx>but this causes the service to start multiple times if it isn't yet up <apteryx>(a behavior change introduced in Shepherd 0.9.0) <apteryx>OK, I'll look if something simple can be done, thanks <apteryx>it was also mentioned somewhere whether Shepherd should always do waitpid in the stop action <apteryx>as otherwise it goes on to restart a new process which may while the previous one is still running, causing problems <apteryx>I'm doing this as a custom stop action for Jami, but it seems it should be handled by Shepherd itself <civodul>apteryx: shepherd calls waitpid by itself upon SIGCHLD (fortunately :-)) <civodul>but maybe there's an issue i'm unaware of? <civodul>in general, the 'stop' action should just terminate processes <apteryx>(kill pid SIGKILL) would also have the parent sent a SIGCHLD, I suppose? <apteryx>(i.e., SIGKILL vs SIGTERM doesn't matter here?) <apteryx>Seems it should just work... hm. I'll need a new round of investigation to determine whether there's still a problem if I don't manually invoke waitpid :-). Thanks. <apteryx>I think I can query D-Bus instead of Shepherd as a workaround, using the already available dbus-service-available? <attila_lendvai>apteryx, FWIW, i remember coming to the conclusion about half a year ago that herd restart some-service was broken because it invoked the start action while the stop did not finish yet, and the daemon binary complained <apteryx>attila_lendvai: that's what I recall too w.r.t jami, but based on civodul reply above, it shouldn't happen <apteryx>(because Shepherd is supposed to do waitpid itself upon SIGCHLD, as they wrote) <KarlJoad>nckx: I looked into it last night, it appears my BIOS had several updates in the past year. I am testing to see if that fixes the issue today. <sneek>Welcome back KarlJoad, you have 1 message! <sneek>KarlJoad, jpoiret says: There's no way to directly access the --removable option of grub right now unfortunately, but you could use --no-bootloader and manually install grub (easy but annoying), or just code up a new bootloader that would be the same as grub-efi but its install-grub-efi procedure would use --removable ***stikonas_ is now known as stikonas
<attila_lendvai>what is printing "error in finalization thread: Success" at boot? looks weird... <unmatched-paren>"Houston! We have a problem!" "What is it?" "The spacecraft WORKS!" "Oh no!" <vagrantc>attila_lendvai: pretty sure that odd message has been there in the several years i've used guix. it confuses/delights me every time i notice it. <KarlJoad>Sounds like one of those good old threading issues... <jpoiret>unmatched-paren, attila_lendvai, vagrantc: basically, there's a separate thread for all guile processes that's in charge of the gc, which communicates with the other threads, and when we do a raw exec (which happens when early userspace hands off to the shepherd after pivoting root) the gc thread doesn't really understand <jpoiret>it thinks it has got an error from reading the pipe because it read 0 bytes, but the read call itself doesn't error, that's why you get "error in finalization thread: Success" <jpoiret>your reaction is exactly why it hasn't been fixed yet :p <KarlJoad>Perhaps change the error message? "error in finalization thread: Enjoy Guix!"? <jpoiret>it's guile-related, guix has no control over that message <unmatched-paren>KarlJoad: if i'm not mistaken, it's a standard error message that would be hard to change? <attila_lendvai>dunno, it's all funny now, but my first impression as a Guix newcomer was that it's kinda lame... <apteryx>a clean boot without silly innocuous errors would be great <apteryx>another old one is the pcspkr module being already loaded <lechner>Hi, how do I get /gnu/store/m4k7bzbys9c5cic2chk03rdi2zfn71hs-nyacc-1.06.5/share/guile/site/3.0/scripts/compile-ffi.scm to show up in /run/current-system/profile/share/guile/site/3.0/ please? <lechner>Hi Guix, does the linux-pam package ship the pkg-config file pam.pc please? I cannot find it. <nckx>lechner: (1) if it really must be in that specific directory: by adding nyacc to your system package list and reconfiguring; (2) find $(guix build linux-pam) -name \*.pc → nope. If it's included in the sources, we should install it, and a patch to that effect would be welcome! <lechner>dirtcastle: Hi, do you use the fish shell? <jts>I'm still getting the error "guix system: erreur : #<<platform> target: "x86_64-linux-gnu" system: "x86_64-linux" linux-architecture: "x86_64" glibc-dynamic-linker: "/lib/ld-linux-x86-64.so.2"> : entrée G-expression invalide". I double-checked to make sure there were no changes in my guix config.scm since the last successful reconfigure, and there were not. Anyone know what might be the issue? <unmatched-paren>lechner: i use fish. is there an issue you're having? (back btw, i'll help you now `:)`) <unmatched-paren>What you want to do is modify it to add a new phase that installs the .pc file <unmatched-paren>So, inside the arguments list, add: #:phases (modify-phases %standard-phases) <unmatched-paren>(modify-phases) takes some phases and modifies them according to the specification you give it. e.g. (delete 'phase), (add-before 'phase 'new-phase (lambda* (...) ...)), (add-after [same as before]), etc <unmatched-paren>so you'll want to do (modify-phases %standard-phases (add-after 'install 'install-pkg-config)). <lechner>unmatched-paren: thanks, but isn't pam.pc part of make install? *unmatched-paren cloning the linux-pam repo <bjc>jts: it's issue 55602. people are testing the patch for it, but i don't think its been merged yet <jts>oh, good, thanks! I was worried I'd somehow broken things by importing a Guix module in my upgrade script ***Server sets mode: +Ccntz
<risu>hi, do you know if there is something akin to /etc/system.scm when running guix from a foreign distro, or at least an scm describing the current install? <unmatched-paren>risu: no, there isn't. if you were to use one in a foreign distro, it would effectively be transformed into a guix system <bjc>you can create manifests from your currently installed packages, or use guix home, as unmatched-paren says, to try and mimic what the system configuration does for guix on bare metal <risu>thanks! in the end, I plan to transform my foreign distro into guix <risu>i'll have a look at guix home. <unmatched-paren>risu: i'd advise you install guix system from scratch, if that's what you mean <jts>in the last five months I've been using Guix, breakage seems to be a mensual occurrence. it might be worthwhile to consider stricter testing before a commit is made, and probably just having stricter requirements for patches in general <risu>i wish i could but I can't get the live usb to boot with my laptop from ancient times .-. <risu>I've a weird bug with GRUB <risu>I could flash my bios if I was brave enough. <unmatched-paren>jts: yes, it's unfortunate. I am guilty of occasionally breaking guixrus when I commit to it :) we need better unit tests imo ***Server sets mode: +Ccntz
<unmatched-paren>once, guix pull broke, which would probably have been avoided by even a brief testing session. There should be a standard procedure for testing your changes, and perhaps some scripts to Automate(TM) the whole process.. <apteryx>civodul: was the commit that allowed reusing inferiors connections critical? (e.g., more critical than a working CI? :-)) if not, perhaps the best thing to do would be to revert it until we have a multi-threaded scenario test that works <bjc>dominicm: conceptually, guix is a source distro, and the ci system that makes the binaries is only loosely coupled with it. as soon as someone pushes, there's a new release, and the ci has to catch up to verify it. theoretically, you could wait for the ci to finish before minting a new stable, but given how long the ci takes (and that sometimes, like now, it has trouble completing at all), that's not really feasible <civodul>and for some reason cuirass-remote-server is not building them <civodul>apteryx: the inferior change did fix an actual bug that one could see with "make cuirass-jobs" <unmatched-paren>I wonder why the CI breaks so often? is there a problem with the servers or their setup? <risu>unmatched-paren: thanks, guix-home looks like exactly why I was looking for. <civodul>apteryx: before that it wasn't working, if you remember :-) <risu>lechner: no, i've only usb 2.0 ports on this machine <civodul>unmatched-paren: there's been a series of bugs and issues as of late... <lechner>risu: can you boot from other ISOs on USB? <dominicm>bjc: yeah I totally agree with building packages that aren't ready yet. I mean scenarios when big software like ungoogled-chromium is currently in a failed state (not in-progress), and instead of assuming that the build is borked it tries to build it locally. <unmatched-paren>but it does seem to me (someone who has never administrated a server, btw) like there might be some deeper issue than "uh oh, boot hung!". Of course, everyone who runs the CI does excellent work, and I'm not suggesting they're incompetent or anything. <unmatched-paren>s/boot hung/(boot hung!|services failed!|file system is corrupted!)/ <dominicm>(I name ungoogled-chromium only because it's what I've experienced the most breakage with) <jts>dominicm: I managed to build ungoogled-chromium and ungoogled-chromium/wayland just fine the other day; might be worth a shot if you use it often (I just need to test webpages in it from time to time) <risu>lechner: yes, syslinux-based isos are fine. all the ones i tried with grub failed. <lechner>The current complaints are a sign that Guix is ready for prime time. It is no longer experimental. Congratulations, everyone! <lechner>risu: did you type ls in the grub shell? <risu>i'm stuck before the grub shell :'( <risu>unless there is a magical keybinding from the welcome screen to the grub shell? <unmatched-paren>lechner: sorry, i'm having some issues with configuring linux-pam (not an auto* expert at all...) ***Server sets mode: +Ccntz
<risu>well, i can't be completely sure it freezes because after the timeout (5 seconds in my settings) the fans go all out <risu>so maybe something happens but I can't see <lechner>unmatched-paren: did you guix install autoconf automake libtool ? <unmatched-paren>lechner: yes, running in `guix shell autoconf automake m4 libtool make gcc-toolchain texinfo gettext bison flex autoconf-archive` just to be sure <apteryx>unmatched-paren: I'm mostly responsible for the boot issues, having bet that a Btrfs RAID10 6x drives array would work alright. And it does in a virtualized environment (QEMU -- we have a system test for it) but for some reasons the boot is flaky on the the Dell PowerEdge server equipped with a PERC730p RAID/HBA card; the drives appear unready by the time 'btrfs device scan' runs, and it fails to <bjc>my experience with grub is that it doesn't pause the cpu during idle loops. it literally spins a no-op. so the fans will wail until you get to the kernel or reboot <unmatched-paren>lechner: somehow this shifted from me helping you to you helping me :) <bjc>well, it's probably not a no-op, but just polling input devices and stuff in a tight loop <lechner>apteryx: btrfs raid may not recover well. please consider btrfs on top of mirrored mdadm <apteryx>what do you mean? btrfs raid is fine outside of RAID 5 and 6, long known to have the memory hole issue <civodul>well, except for non-x86 machines where i'm not root <apteryx>great! when must we kick start the workers this way? <lechner>apteryx: okay, maybe it's fine now. i once tried to recover and wne tback to mdadm <bjc>kicking workers?! time to unionize them <KarlJoad>My guix system seems to be hanging on both a system reconfigure and a home reconfigure after updating substitutes. No CPU cycles used, but they did do something for a while. Has anyone seen this before? <nckx>KarlJoad: It's thrashing. <KarlJoad>Gotcha. It looks like my Guix is hanging on trying to connect to bordeaux. <lechner>risu: Do you have a legacy / fast toggle for USB in your BIOS? ***Server sets mode: +Ccntz
<apteryx>nckx: ah! that explains why my machine seemingly was getting hung up on updating substitutes from bordeaux *attila_lendvai is grateful for nckx for answering his not yet asked question... :) <lechner>unmatched-paren: via guix package --install-from-file= ? <nckx>I was running check-system on it, which presumably is causing this thrashing. I'm surprised at that though. <nckx>attila_lendvai: Which was? <attila_lendvai>nckx, the issue with the substitute server. my reconfigure was sitting there hung, without a word <nckx>It's not a great failure mode. <attila_lendvai>no, it's not. especially that --verbosity=1000000 didn't change anything <nckx>Why do people… there aren't even 4 😃 <civodul>nckx: "make check-system" without any arguments runs all the tests and all that ends up building disk images, which is i/o-intensive <nckx>OK, yes, sure, agreed, I know, but then there's… this. <civodul>that reconfigure was hanging, sounds bad, agreed <nckx>Oh, I meant that it brings the machine to its knees. The handling can certainly be improved but I wasn't criticising. <nckx>I've run this on my own machines, including a RAID-5 on spinning drives, and it's just *slow* (hence my using bayfront), but not unresponsive. <apteryx>civodul: I'm wondering; would running (make-forexec-constructor ...) in a start slot no longer block in shepherd 0.9 ? <civodul>nckx: ah but that's a Linux i/o scheduling issue then <civodul>apteryx: it just returns a lambda, so that's ok; that lambda before 0.9 would only block if it had to wait for a PID file <civodul>nowadays waiting for a PID file is non-blocking <apteryx>to be clear; *running* the returned procedure as done in the start of the jami-service *would* block, right, pre or post Shepherd 0.9.0? I <attila_lendvai>linux has a tendency to thrash even with zero swap enabled. when low on memory, it can start swapping the read-only mmapped files (e.g. code blocks in binaries!). i had to power cycles my swapless linux installs way too many times because of this... the alternative is to wait indefinitely for the OOM, and it often ends up killing the gnome session... <lechner>Hi, is there a Hoogle type search for unbound variables in Guix? Maybe Guigle, or Giggle? <civodul>apteryx: the one in telephony.scm:525, right? <risu>lechner: thanks, i was not aware of that! i don't have win7 anymore though but at least it seems there is a better firmware for my pc. <civodul>apteryx: with-retries uses (@ (guile) sleep), which blocks <risu>i kind of think that the safest is simply to install guix by using `guix system reconfigure` at some point. <civodul>(gnu build secret-service) has a trick, but i don't recommend copying it <apteryx>FWIW, I'm in the VM created with "./pre-inst-env guix system vm --no-graphic -e '(@@ (gnu tests telephony) %jami-os)' --no-offload --no-substitutes" an launched with /gnu/store/5a0cy5i1g9bnvx840an0x7j7gwm65iwb-run-vm.sh -m 512 -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22, and I see: <apteryx>I see in /var/log/messages: May 24 17:07:10 localhost shepherd[1]: Failed to start jami in the background <lechner>risu: you can do it from anywhere. i did it from Debian, but that ISO does not boot on your system either. <apteryx>and the service appears as "stopped" <apteryx>and 'herd start jami' prints -> herd: exception caught while executing 'start' on service 'jami':\n Throw to key `match-error' with args `("match" "no matching pattern" #f)'. <civodul>that's on master or with some changes? <maximed>lechner: Not that I am awere of, though you can look in the Guile and Guix manual and use info's search functionality <maximed>and there are some Guile REPL commands but I don't know their names or how to use them <apteryx>civodul: mostly master, only gnu/tests/telephony.scm has been more heavily edited <lechner>where do i find license:bsd-3 ? i do not get it with (guix licenses). sorry, i'm new <cbaines>has anyone got a connection to bayfront? it's run out of RAM and swap <civodul>(1) do we really need to wait on /var/run/jami/bus? <maximed>lechner: bsd-3 is defined in (guix license) <maximed>To get license:bsd-3, you need #:prefix <maximed>Search for #:prefix in some package modules for examples <civodul>and (2) this needs to be changed to use (guix least-authority) instead of make-forexec-constructor/container at some point <maximed>Basically, the reason is that there both exists a 'expat' package and an 'expat' license so the ambiguity needs to be resolved somehow 
