<bdju>did anyone else hit that blender build failure yet? the log was too big for me to paste anywhere I think. I haven't been able to do a successful guix upgrade in ages because of all the build failures lately <risu>Hi, I've some problems to get guix booting on the liveusb due to grub failing to start properly. Could someone tell me how to build a bootable image with extlinux/syslinux from a foreign distro? I've been fiddling with install.scm but I always end up building an image with grub :( <jpoiret>sneek, later tell dlowe: are you trying to use u2f from your browser? If so, you might need to help it find the libraries it needs by hand, since i don't think they're included in the browser packages <jpoiret>yarl: i think it is, and while i also think that adding it as a phase to gnu-build-system is a bit unsatisfactory, it's still the best way currently <jpoiret>there are still many people hitting these kinds of issues <risu>jpoiret: yes, that's what I tried first. By replacing `grub-bootload' https://github.com/lfam/guix/blob/master/gnu/system/install.scm#L455 by `extlinux-bootloader' and adding the corresponding module import. But `guix system image -t iso9660 ...` kept producing image with grub. I think I am not selecting the good os-definition in the file but I don't really know what additional option I should give <yarl>jpoiret, the issue is old, why was this solution, even if it is imperfect, not chosen? <jpoiret>risu: from what i'm reading `-t iso9660` always replaces the bootloader with grub <jpoiret>yarl: as ludo said, you wouldn't be able to selectively remove that behavior, and gexp->derivation doesn't look like the place for it <risu>jpoiret: I am not completly sure why it is failing. It stops at "Welcome to GRUB" and hangs. I think it can't properly set up a resolution for my screen. I've tried to blindly navigate the menu. Assuming that even though I don't see it might be working nonetheless. But that does not seem to work either. <risu>I've tried to change the option passed to grub by modifying the bootloader options. It works and the modifications are correctly reflected in the grub.cfg found on the image but for some reason, GRUB continues to get stuck on the welcome screen <risu>despite hard coding a screen resolution in the grub.cfg <risu>That's why I would like to try with syslinux <yarl>jpoiret, sorry, have been disconnected. I might have misunderstood you. You said "i also think that adding it as a phase to gnu-build-system is a bit unsatisfactory, it's still the best way currently" but this is not currently implemented, right? What I have seen in package declarations that need children reaping is a combo of tini and <yarl>I may have missed other solutions? <jpoiret>no, it is not, but the given patch changes gexp->derivation while it'd be better to add it as a phase of gnu-build-system <yarl>Oh, and what about the patch given by Ludo? <yarl>I didn't really get the guile version problem... <PurpleSym>Doesn’t child-reaping belong into the daemon? It’s my understanding that it sets up the Linux container, right? <jpoiret>iiuc, the daemon is not PID 1 inside the build env, just the builder <PurpleSym>Ah, maybe it’s doing just an `exec` after setting up the environment and then the builder becomes PID 1. <yarl> If we're building in a chroot, then also set up private <yarl> namespaces for the build: <yarl> - The PID namespace causes the build to start as PID 1. <yarl> Processes outside of the chroot are not visible to those on <yarl> the inside, but processes inside the chroot are visible from <yarl> the outside (though with different PIDs). <yarl>in DerivationGoal::startBuilder() <PurpleSym>Is there any scenario which requires the builder to be PID 1? <jpoiret>PurpleSym: yep, just looked that up, it execs the builder <jpoiret>i'm not sure the builder requires PID1, i don't think it would break reproducibility <jpoiret>if some build systems manage to capture the PID of the builder then they'd have something to fix :p <jpoiret>although if you add that to the daemon it would be harder (if not outright impossible) to disable it for specific packages <PurpleSym>Sure, but I can’t think of an example where that would be required right now. <jpoiret>i don't think having child subreaping would break any build systems though, the ones that manage to create zombie processes should already know and manage them <yarl>jpoiret I think using a pid namespace is a must. Of course it is not "required", but... <jpoiret>yarl: what PurpleSym and i were talking about was rather that the daemon could run as PID1 after having cloned, and just spawn the builder as a new process inside the namespace <jpoiret>so that it could reap zombies while the builder does its thing <PurpleSym>Or just put `tini` in between. Doesn’t matter in the end, as long as *someone* is doing it. <jpoiret>PurpleSym, yarl: seems like nix doesn't reap zombies either <jpoiret>tini has a very small source, and most of it takes care of mostly irrelevant things like tty leaders and the like, which we shouldn't need for build processes <jpoiret>child reaping should be pretty straightforward <PurpleSym>But nix calls some `sandbox-exec` for sandboxed builds. No idea what that executable does though. <jpoiret>PurpleSym: that's a macOS specific thing <PurpleSym>Ah, you’re right. It’s part of a big `#ifdef`. <jpoiret>hmmm, time to get back to my grub patch <jpoiret>adding the child reaping to the builder would also avoiding making a world-rebuild right? <jpoiret>ideally it ought to since it changes the build semantics but well <risu>jpoiret: I don't have any uefi support, it is a pretty old thing, an hp pavillon dv6000 from circa 2010 <risu>but technically syslinux works with legacy bios so if only I could use syslinux <risu>otherwise, I wonder it is possible to do the install from another distribution, and then wipe out everything needed by the old distribution and replacing the init process by sheperd <jpoiret>guix's default grub config uses gfxterm, let me see if you can use native instead <jpoiret>can you try to add (terminal-outputs '(native)) to your bootloader-configuration? <risu>I've tried them before (except native) and it was still stuck on the welcome screen which was very strange <risu>it's like the grub.cfg does not have any influence (I need to check if grub really reads that file or that file is merely a configuration file that is used to generate a more low-level representation) <risu>oh, and while I am it, could you tell me where did you see that `guix image -t iso9660` default to (and override the bootloader to) grub. I've missed this info in the manual. <jpoiret>risu: people have complained about that time and time again but uhm..... by reading the source :p <jpoiret>gnu/system/image.scm and gnu/build/image.scm are what you're looking for <jpoiret>risu: what grub.cfg are you talking about? <jpoiret>it's generated from your config.scm file, and then put in /boot/grub/, and grub directly reads that file <jpoiret>i think the issue arises with insmod gfxterm, not just with terminal_output gfxterm, so you'd need to remove all that if you're directly modify grub.cfg (although i don't recommend it, you should modify your config.scm instead if you're using that) <risu>yes, i'm editing the install.scm which generates grub.cfg <risu>i'll try to get rid of insmod gfxterm when i'll try again tonight <jpoiret>risu: iiuc the code that generates the grub.cfg, if you have (terminal-outputs '(console)) it shouldn't add insmod gfxterm at all <yarl>jpoiret (and maybe others), sorry about these questions but 1/ is "#ifdef __linux__" necessary? Guix is supposed to run and be compiled only on linux, right? 2/ Is guix daemon still pulling from nix? I understood it is completely on its own now? There is this "rewriting daemon in guile" goal in roadmap. <yarl>jpoiret, these ifdef are only relevant if they are part of this separation between linux and hurd, not if they are there since the nix fork. What do you think? <jpoiret>i think those ifdef linux correspond to linux specific features only, so they're not here for no reason ***stikonas_ is now known as stikonas
<afr>Hi! I'm trying to install Guix on the Acer Aspire One a repair org has lent me, but I can't go to the graphical installer (using ctrl+alt+F1), it doesn't bring me to TTY; the F1 key, however, is detected by the default TTY (Guile prompt) <afr>It does work with OpenBSD and Alpine Linux <afr>Plugging an external keyboard doesn't fix the issue <afr>(i.e. pressing Ctrl+Alt+F1 with the external keyboard, plugged to the computer) <jpoiret>afr: what do you mean by "it doesn't bring me to TTY"? <jpoiret>by default, it should boot and show you tty1 <jpoiret>when you say guile prompt, did the image boot you in a guile prompt? if so, there has definitely been an error during early boot, and you haven't pivoted to the root filesystem <afr>jpoiret: thanks for the answer, it says: "ice-9/boot-9.scm:1669:16: In procedure raise-exception: failed to resolve partition "31393730-3031-3031-3139-343934363833"" <afr>I… will try to download the image again (couldn't verify it on Windows) <apteryx>afr: I'd try using the latest "development" image instead; 1.3.0 has some bugs to read partitions if I recall <jpoiret>i suggest using rufus, and not things that customize things like yumi/multiboot/ventoy and friends <afr>I used rufus indeed. Thanks apteryx, I'll do this. <lechner>Hi, has anyone had issues hotplugging keyboards with GDM in Guix? <lechner>Also, what is the preferred way to prevent suspension on servers with GNOME installed, please? <jpoiret>lechner: are you using wayland or X gdm? <jpoiret>in my experience, libinput is better than X at hotplugging <lechner>jpoiret: i just switched. not sure if it's related <jpoiret>the input library used by wayland (also X if you include the relevant module), it manages keyboards, mouses, trackpoints, etc... <lechner>my most pressing issue is that the server stops responding to network requests after twenty minutes or so. GNOME is installed bu no one is logged in <lechner>i also no longer see the "unmanaged wired" connection <lechner>but my overall experience with wayland has been great. i haven't used X in years. i think my issues are related to GNOME <lechner>jackhill bjc: you were right! enabling wayland makes sway show up in GDM. thanks so much! <lechner>sorry about all my questions here lately. i am totally in love with Guix! I converted all my equipment, eight machines in all <jackhill>lechner: re: stopping responding to network requests. Is the server perhaps entering suspend mode? I think that's the default GDM behaviour if no one is logged in. <lechner>jackhill: not in this case. gdm shows the login screen. maybe it's related to network manager <lechner>as for suspend, does herd handle it or should i otherwise deactivate the ACPI states? <lechner>also, my GDMs start up with 3x25 sec delays from udev/freedesktop. is there a solution for that? <jpoiret>elogind should be the one handling suspends/lid close/etc... <lechner>jpoiret: i meant the masking of the suspend states at the system level. for some reason i think systemd does, but i am not sure <nckx>diffoscope: AttributeError: 'list' object has no attribute 'get_reverse' <nckx>Every. Single. Hole. Has. A. Bun. In. It. <jpoiret>i don't really understand what you mean by "masking of the suspend states" <jpoiret>in any case, elogind should have most of the same suspending features as systemd <nckx>I dunno. Anyway, if so, check out elogind-service in (guix)Desktop Services. <jpoiret>we're still missing pre/post-suspend actions in elogind, i'm planning to add them eventually <jpoiret>my touchscreen requires a manual ACPI call to revive it after suspends, and i've just been `sudo bash -c ...` ing it manually all this time :p <nckx>Really? As in acpi-call-linux-module? Just ACPI things. <jpoiret>yeah! it's either that or s0i3 suspend which drains all of my battery <nckx>I distinctly remember thinking nobody else but me would need that weird package when I added it. Turns out, no, the world really is doomed. <jgibbons[m]>Working on modernizing Mono. The build process is trying to clone a lot of external git sources. Not good for reproducibility. <nckx>You want modern, you get ‘modern‘. ☹ *nckx is a real ray o' sunshine today, aren't I? Off I go. <unmatched-paren>jgibbons[m]: i believe the only way to remove that would be to find some way to build mono with dotGNU pnet <dirtcastle>trying to uninstall guix on foreign distro. sudo rm -rf /gnu or any other folder doesn't work <jgibbons[m]>dirtcastle: /gnu is mounted as a read-only directory. You need to unmount it. Using systemd? <jgibbons[m]>There should be a fs service you need to stop as well. <jgibbons[m]>I forgot what it's called. Look for services with "guix" or "gnu" in the name <jgibbons[m]>unmatched-paren: I disabled some of the external features, and I'm running it in a container without network so it can't get the garbage it's designed to say it needs. I think it can use the current version of mono as a compiler. I'll see if that's enough. <dirtcastle>jgibbons[m]: didn't find a service with guix in the name <nckx>Because it's called gnu-store.mount I believe. <nckx>It just bind-mounts /gnu/store over itself, you can probably undo that by hand (if systemd doesn't helpfully redo it). <jgibbons[m]>I think that's what I was referring to. gnu-store.mount <jpoiret>trying to test some grub patches, i installed a new system and now it seems that on boot, the EFI partition is being fsck'd on loop for no reason, and hangs <jpoiret>even though there's nothing wrong with it or the other partition for that matter, i've fscked and mounted them on a live image <nckx>jgibbons[m]: Sure, you said nothing incorrect! <nckx>jpoiret: On loop? Hm. Does it go away when booting with fsck.mode=skip? <jgibbons[m]>undefined reference to `ves_icall_System_Globalization_CompareInfo_internal_compare' <nckx>jpoiret: I don't understand where the loop comes from. Guix should not restart fscks no matter what they return, so unless fsck.vfat does that on its own accord, I'm not sure what's going on. <jpoiret>yeah, that's what i was wondering too, looking at the different places they might happen <jpoiret>and also, fsck.vfat -v -n using a live iso does exit with 0, so it shouldn't prevent anything <jpoiret>maybe it's the file-systems shepherd service that gets started multiple times but fails to <jpoiret>since it ends up being a dependency of user-processes *nckx nods. It's very fragile. *nckx will never get used to writing '(#$@(…)), I don't think (on a completely different note). <jpoiret>does guix really fsck on every mount? <jpoiret>seems like the mount call is failing silently, i wonder why <nckx>‘fsck’ as in call the fsck tool in ‘quick sanity check’ for file systems that recommend it, yes. Nothing trad distros don't/didn't do. <nckx>s/for file/mode for file/ <lechner>i also saw an fsck on mount, although unrepeated, and was surprised <nckx>lechner: Is that no longer standard? <nckx>I've been out of trad distro land a while now :) <lechner>nckx: i am not sure. it used to be a mix of time passed and number of mounts, but with journals everything changed <lechner>it probably was always standard via /etc/fstab but the messages were less conspicuous <lechner>Hl, what's the right 'device' setting for an NFS mount, please? server:export does not work <jpoiret>civodul: great that you managed to get a fix for that! i was observing it from afar <jpoiret>nckx: i'm not used to debugging things that early <nckx>There isn't really a pleasant way. <nckx>I think the only way to get it from the bournish prompt is cat /proc/kmsg? Something very horrible like that. Unless things have improved. <jpoiret>yeah, i'm trying to use qemu's serial console <jpoiret>lord, i had never seen the linux-libre logo <jpoiret>i wonder why it displayed when i raised the loglevel <nckx>The kernel logic is bizarre. <nckx>I had to reverse some of it here to got a nice boot splash. <dirtcastle>still facing this error. is this anything to do with me using fish? <civodul>jpoiret: yeah it's definitely annoying to debug, but in the end there's no big surprise <nckx>dirtcastle: Can you remove /home/bkk/.cache/guix entirely and try again? <lechner>Hi, why would 'reboot' not reboot, please? <dirtcastle>bruh. it worked. I uninstalled and installed for this... <nckx>You *might* have run something akin to ‘sudo -E guix pull’, it's hard to say now of course. <nckx>guix should print a warning but TODO :) <nckx>Files in ~/.cache being root-owned is odd enough to warrant that. *nckx .oO Maybe a good first patch… <jpoiret>hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm is this just not me giving "fat" instead of "vfat"? <Lembrun>is everyone running guix on ssd? it feels so painful on an hdd <civodul>Lembrun: i'm running it on an SSD but i heard that it is indeed painful on a spinning drive :-/ <cbaines>Lembrun, what aspect is painful? Some of the servers that Guix uses use HDDs, so it's definately possible <cbaines>I'm excited to see what the fix for #55441 is civodul :) <civodul>cbaines: i guess on low-end HDDs some of the i/o-intensive bits are slow <civodul>like grafting, or even just loading files, as with "guix search" <Lembrun>when do a guix reconfigure home/system.scm it does take ages, and you can't iterate quickly <nckx>It's… not *that* much faster on an SSD, although one certainly helps. <nckx>I couldn't iterate if I were limited to ‘guix pull’. Brr. <jpoiret>reconfigure is not really made for iteration <jpoiret>system reconfigurations do take a bit of time on an ssd as well <jpoiret>so apparently yes, just because i had put fat instead of vfat as the fs type in my test config.scm, the system didn't boot at all <jpoiret>it doesn't help that the code responsible for the fsck actually checks if "fat" is a suffix of the type, even though anything other than "vfat" won't work <nckx>Eh? Is ‘fat’ even a valid file system type? Not on my system. <nckx>grep fat /proc/filesystems → vfat <nckx>Where did you get the ‘fat’ type from? <jpoiret>nowhere, i had typed a test config.scm from memory <jpoiret>it's completely my fault but it's annoying that there's no way to see that this is the root issue <nckx>To both, but mainly the latter 😛 <nckx>(Changing the suffix check would not have made your system any more bootable.) <nckx>(But looking at check-procedure, I wonder why it's so substring-heavy? Just in case IBM releases xfs2?) <jpoiret>but maybe guix would've complained that fat isn't a valid fs type <jpoiret>i mean, there's no reason not to do string=? type "vfat" <nckx>Guix doesn't validate file system types, no should it. <nckx>All that would do is skip fsck. <nckx>And it wasn't the fsck that was failing. <jpoiret>sure, but maybe just printing "Warning: guix doesn't know how to check filesystem 'fat'" would've been useful, or something of the sort <jpoiret>but right, people may want to use some out-of-tree fses or such <nckx>Guix is way too chatty as it is. <nckx>Er, also: (format (current-error-port) "No file system check procedure for ~a; skipping~%" device) <nckx>That's exactly the kind of stuff I think should begone, but it's there :) <nckx>Or at least it should only trigger when the user/admin requests FORCE?. <jpoiret>but that would help diagnosing such issues <nckx>It's there; it didn't help you. <jpoiret>combine that with a more conservative type identification <jpoiret>checking prefixes and suffixes clearly seems wrong here <jpoiret>even if there ends up being a new fs type that shares a substring, it might not have the same fsck command <nckx>Ah, right, it didn't trigger for you. <nckx>We agree about the suffix/prefix madness. <jpoiret>what i saw was fsck.vfat spouting perfectly fine diagnostics 20 times in a row <jpoiret>well, maybe i'll have a look later and make these more stringent <nckx>((string-prefix? "ext" type) check-ext2-file-system) <nckx>spot the obvious 2022 bug. <nckx>jpoiret: I already have, I'm just terrified of breaking somebody's boot by having missed one… <nckx>I wanna match on ext[0-9]+ — clearly we need to switch to extended regexps in the initrd. <nckx>What I think we *should* do is drop this fragile mess in check-procedure, make sure the initrd includes all fsck.TYPE symlinks that upstreams already maintain for us, and simply invoke those that exist. Doesn't that make more sense jpoiret? <nckx>That way, if fsck.vfat ever does support exfat (it won't), upstream will add a symlink and we'll magically DTRT. Same for fsck.ntfs4. <nckx>Although on the flip side, names like xfs_repair/btrfs/… are deliberately non-standard because they don't want to be invoked lightly. We don't, but it still breaks my proposed scheme. <nckx>Maybe manual exceptions for those. <jpoiret>they shouldn't be invoked lightly, so why should we? <jpoiret>well, if force? is #t we do for btrfs <nckx>See the code. We invoke them only if FORCE?, and IMO that is correct. <jpoiret>but still, fsck.btrfs won't do us any good <nckx>I want to be able to force a btrfs check in the initrd, because btrfs is a fragile mess, and btrfs upstream can't convince me otherwise. <nckx>No, we'd keep the custom check procedures for btrfs and such. It was more about automatically growing support for *unknown* types when they appear upstream, which is the only motivation I can think of that guix has all these string-suffix/prefix matches in the first place. <dirtcastle>how to make guix use substitutes instead of building. I ran guix build emacs --dry-run. and it said downloading which means guix uses substitutes by default. but when I run guix pull it is building. some stuff of the stuff. <davidl>dirtcastle: "guix pull" builds your local "guix" ifself. guix build <package>, builds a package defined by guix. You can have a look at guix build --help, and/or info guix <dirtcastle>can I use substitutes instead of building everything myself <jpoiret>note that `guix pull` will also use substitutes <davidl>dirtcastle: Are you asking why guix pull can't just give you a "guix" substitute binary without building anything at all locally? <davidl>other ppl are much more qualified to answer that than me. <dirtcastle>or if there is an option to use substitutes as much as possible, is it already enabled or how to enable it. <jpoiret>guix needs to bootstrap itself, and that step requires some local computations <jpoiret>but then, you should be substituting all of the .drvs <jpoiret>the part that takes a while is the "Computing guix derivation" <davidl>jpoiret: "requires some local computations" - can you give examples? <jpoiret>the newly pulled build-aux/build-self.scm will use guix/self.scm to create derivations that will build guix with its (possibly) updated dependencies <jpoiret>the "Computing guix derivation" step is exactly that, it's guix/self.scm looking at the guix source and generating a derivation that will build it <jpoiret>(there are actually multiple derivations) <jpoiret>once the derivations are computed, the running guix daemon takes over and is able to substitute the results <risu>dirtcastle: you need to add ci.guix.gnu.org with guix archive --authorize in order to fetch substitute instead of building from source <jpoiret>ci.guix.gnu.org and bordeaux are available by default <risu>and if you're on a foreign distro, not forget to enable the nsswitch service <davidl>jpoiret: so you can say (I think) that the seed required to build guix is an earlier version of guix itself, by default this earlier version is whatever local version you already have installed. IF that is true - maybe Im wrong - then why can't this be served as a binary still? <jpoiret>it is served (not as a binary, but as multiple derivation substitutes) <jpoiret>but those derivations need to be created first <jpoiret>you can't substitute something that's not a derivation <jpoiret>(and you will also locally build a profile at the end, but that's because all profiles should be locally built and they're not costly anyways) <davidl>jpoiret: why does it take so long to run the step "compute-guix-derivations"? There's the term "fixed-output-derivation" - which I suppose "guix" is not, or maybe at least not when you run guix pull? Is guix not a fixed-output-derivation - if so why isn't it? <davidl>jpoiret: also, Im sorry for my lack of general guix knowledge. I am reading and rereading what you already wrote to figure this out and understand you better. <jpoiret>fixed output derivations are a way to say: "okay, I know what the end result should be (ie the download of some source code), so let me use the network/non-stateless methods to fetch that and you'll check that it does result in what I claimed" <jpoiret>those derivations contain the hash of the end result, which isn't the case for all derivations at all <jpoiret>other derivations, you don't know beforehand what they'll build to, but you can still download their result if it's already built <jpoiret>theoretically, we could make everything in guix a fixed-output-derivation, that would download prebuilt binaries with the proper hashes, but then guix would not be reproducible and source-based <davidl>"other derivations, you don't know beforehand what they'll build to, but you can still download their result if it's already built" - right, so comparing a package with guix itself - why can't you know beforehand that if you run guix pull --commit=XXXXXX that it should build to "SOMETHING", while, when running guix build X for some package with a git-download source you would know what SOMETHING is? *davidl potentially missing something obvious <civodul>apteryx: i've pushed the 'guix' package update so i'm ready to reconfigure berlin; lemme know how to proceed! <civodul>if there's nothing special, i'm fine doing it myself <jpoiret>davidl: well, the result of building guix depends on the guix source, right? <jpoiret>ah, the difference with a usual package is that the source is not fixed, ie when you `guix pull` you fetch the latest commits, so you need to compute the derivation based on that, whereas packages come from fixed-output-derivations <jgibbons[m]>guix shell --container -D mono --export-manifest should give me a manifest including everything required to develop mono, correct? <jpoiret>no need for --container with --export-manifest <jpoiret>although, the standard caveat is that sometime source checkouts and tarballs differ, ie you may need autotools in addition to that to hack on the latest commit <jgibbons[m]>I think it should output something like (package->development-manifest (specifications->package "mono")) <jgibbons[m]>It outputs that in the call (concatinate-manifests) if I add another package to the list to include <davidl>jpoiret: "the result of building guix depends on the guix source, right?" - i suppose it may affect the derivation hash, since you build guix with guix (and it's dependencies), though if ur user is on guix commit 123456 and runs guix pull --commit=234567 then building 234567 from 123456 should be a "known situation" that you can provide a substitute for IIUC. While packages - well they have inputs that would ruin the output by linking (or <davidl>referencing) to other packages all the time - so any single package may have a different build derivation output differing based on the current guix commit. <apteryx>was there updates needed to cuirass as well? <davidl>jpoiret: In my understanding: If all combinations of guix pull "from commit=ABCDEF to commit=123456" were pre-calculated (their output derivations and corresponding binary substitutes), then new versions of guix could be substituted during a guix pull - but all those combinations (from commit=ABCDEF to commit=123456) are too many and thats why it can't be substituted <apteryx>civodul: ah, that'd be captured in the guix updated package right <jpoiret>davidl: what i am saying is that, we do have substitutes for the derivations that need to be built <jpoiret>but we need to create the derivations first, and that takes a bit of time <civodul>apteryx: right, so we just need to "guix pull && guix system reconfigure" <jpoiret>unless you've pulled 1 min after someone committed, in which case CI most likely won't have built the substitutes <jpoiret>civodul: i've just finished working on my grub/luks2 patches, i'll be looking at the installer issues now <apteryx>civodul: do you remember how to do that? I can do it, but it's trivial now: 'guix pull' on berlin as your user, checkout the latest commit of guix-maintenance, cd hydra and 'sudo guix system reconfigure -L modules berlin.scm' <apteryx>and finall 'herd restart postgres' should take care of restarting postgresql and cuirass <apteryx>thanks for debugging and fixing the issue! <cbaines>apteryx, I think using the maintenance checkout within the root user is better than individual checkouts, this is also what the motd says <civodul>apteryx: yup, i'd usually run "guix pull" in the root account and work from there, but yes <civodul>i have to go afk for a bit but i can do that later today <apteryx>cbaines: why? it encourages people to leave uncommitted cruft which the next person has no way to know if it worthy of being committed or not <apteryx>if we work as our users I see two benefits: 1. important bits get committed 2. we can keep track of who did what if you use sudo instead of root <cbaines>apteryx, I guess everyone using the same checkout allows for some coordination, especially regarding the uncommitted cruft. While it's not ideal to have things not committed, there's usually a reason why changes are made. <cbaines>anyway, I don't usually touch the berlin configuration, so this isn't an issue for me at least <apteryx>civodul: with the latest Guix, when I try reconfiguring berlin I get: error: sysadmin-service-type: unbound variable <cbaines>apteryx, have you tried the -L modules after reconfigure? <apteryx>I'm guessing some change that added required description for the service records perhaps, and a badly reported failure <risu>i've rebuild the image with (terminal-outputs '(console)), it does indeed start in console mode, but it is still stuck there, haha, I guess I'm gonna use guix on funtoo for a while rather than installing it fully .-. <risu>funny thing though, I had not paid attention on that before but after the timeout my fans go all out, so I think that guix is starting even though the screen keeps printing "welcome to grub" <risu>maybe i'ma try, configuring an image with ssh, and ssh into it <risu>that's a parameter for grub, so that it does not try anything fancy with the framebuffer. <unmatched-paren>btw, does anyone know how well guix system does on a framework laptop? i'm considering it as my next computer once this one goes (I know that the wifi probably wouldn't work, but I can easily work around that) <cehteh>hehe i just came from the GPN and spotted some frame.work laptops there, still dunno how it works with the linux libre kernel ***lukedashjr is now known as luke-jr
<dlowe>I'm running guix on a framework and I'm pretty pleased <sneek>Welcome back dlowe, you have 1 message! <sneek>dlowe, jpoiret says: are you trying to use u2f from your browser? If so, you might need to help it find the libraries it needs by hand, since i don't think they're included in the browser packages <Tcache[m]>so one day ill be comfertable enough to take the move <davidl>lembrun[m]: "is everyone running guix on ssd? it feels so painful on an hdd": I feel you man. I used HDD for years and it sucks. Then I finally got a librem for puri.sm with and nvme, and it's a different life. I was putting my x200 laptops out in the snow for the guix pull and guix package -u because the webkit-gtk wasn't building on the CI so I had to build locally and stuff. It was horriblea. <risu>compiling webkit-{gtk,qt} is a penitence <risu>(even though compiling libreoffice is even worth) <midgardian[m]><davidl> "lembrun: "is everyone running..." <- Can you not have SSD on an X200? <morganw>I'm using a T400 and it is really slow to boot and the Shepherd service timeouts are too short. If there was an option to start services one at a time I would take it. <davidl>midgardian[m]: you can and I have one with and one without. I think they are SATA2 though and not SATA3. Either way, the switch to a Librem laptop with NVME was dramatic. <bdju>ah I see... the rakudo version packaged is so old (2019.03.1) that the repl is launched with `perl6` and not `raku` <unmatched-paren>bdju: i at one point attempted to update it. couldn't be bothered at the time, but it shouldn't be too hard <civodul>apteryx: oh right, it could be that service types under sysadmin/ are missing the 'description' field <civodul>thus the module(s) in question cannot be loaded <civodul>i'm surprised there's not even a warning though