***jess-o-lantern is now known as jess
<ryanprior>Lots of things in the vlang package assume that you have `cc` on your PATH, since the upstream community considers that to be a prerequisite to using the v tooling <ryanprior>Our vlang package depends on gcc-toolchain but doesn't install a program called cc, because there's no Guix package afaik that provides such <ryanprior>I proposed to create packages like `gcc-wrapper` or `tcc-wrapper` that would provide `cc`, but that solution is rejected. <ryanprior>Anybody have ideas how I can provide a better out-of-the-box experience for people who install the package? <ryanprior>Right now a typical session might go like: install vlang package, try to run v repl, fail with an error msg about can't find cc so you should install a compiler <nckx>ryanprior: So ‘-cc’ is deliberately hit-and-miss? <ryanprior>But people don't necessarily know to do that <ryanprior>One thought I've had is to write a wrapper script for v that provides `-cc=gcc` by default <ryanprior>Seems like a kluge but I'm open to consider anything <nckx>My first idea is to make V always use the compiler with which is was built (and tested!), not whatever toolchain it finds in the environment. That would fix the problem at the expense of some patching, since you can't just use wrap-program. Has that been discussed and/or shot down? Would it be acceptable? <nckx>What I meant by ‘hit and miss’ is that even ‘v -cc gcc repl’ doesn't work, even with .27. <ryanprior>Hmm darn, I was pretty sure I had it working with .27 but I didn't document exactly what I'd done <ryanprior>The idea of patching v to use by default the compiler it's built with was not shot down, and sounds reasonable to me. <bavier[m]1>our Idris package has a similar problem, which requires users to set `IDRIS_CC=gcc` in their environment. ***daviid is now known as Guest64483
***Guest64483 is now known as daviid
<ryanprior>Okay so good news: vlang has a `build-tools` command that builds all its bundled tools (like the repl) eagerly instead of waiting to build them lazily as they're used <ryanprior>However, some of the tools have dependencies outside the main vlang source tree. So we've got to decide how we want to deal with that. <Brendan[m]2>wow, ludo defined quite-guile. desperate times call for desparate measures. <HelloFriends>Hello friends. I'm a newbie to Linux and thought I'd try GNU Guix in addition to Debian. When I installed Guix on a partition, I lost Debian from the bootloader. Would a kind soul be able to help? <g_bor[m]1>HelloFriends: Do you have a working system then, just lost debian boot from the boot menu? <HelloFriends>Yes, GNU Guix works, and I see my other partitions using fdisk -l <HelloFriends>I see there's a section on bootloader config in the help file, but I'm not sure if I'm supposed to create a fresh file and reconfigure guix from there, or if there's a file I can generate for myself and then edit <g_bor[m]1>The operating system configuration file from your installation should still be available. You can modify that, but I usually create a new file, based on that and put it under version control. <g_bor[m]1>You will need to add a menu entry for your other system in the config. <HelloFriends>That makes sense. I see the menu entry command. Thanks for your help! I'm still looking for the default configuration file, but I suppose I can just write up a new one from scratch since it's more important that I get Debian back at the moment. <xelxebar>HelloFriends: When your Guix System is running, you can find the currently active configuration under /run/current-system/configuration.scm. <xelxebar>Let us know if you need help setting up your bootloader. <HelloFriends>Thanks @xelxebar. That's helpful. I'm about to rebuild and see if that will do the trick. <xelxebar>Let us know how it goes. For a Linux newbie, you have excellent taste in distros :p <xelxebar>Hrm... The build of guile-static for armhf-linux is failing for me: <xelxebar>while setting up the build environment: executing `/gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile': No such file or directory <xelxebar>That guile binary exists, as does the ld-linux-armhf interpreter it refers to. <Brendan[m]2>xelxebar i think when that mysterious file doesnt exit error happens for files that really do exist, its do with the linker not working right <xelxebar>Brendan[m]2: Yeah, you see the same (confusing) error when your elf points to a loader that doesn't exist. In this case however, it does... <xelxebar>You said linker, though, not loader... Are you thinking of a different issue? <Brendan[m]2>Hmm. I sorta feel set-xorg-configuration should not have the optional login-manager-service-type and should be explicit. i was wondering why i was accidently downloading all this GDM stuff for a different greeter and realised it defaults to gdm-service-type <Brendan[m]2>xelxebar i only have vague understanding of this, so i dont know the different between linker and loader <xelxebar>Oh okay. The linker is just what glues object files (foo.o, bar.o, etc.) together into an executable. <xelxebar>The loader is what sets up stuff at the beginning of execution for "dynamic linking" <HelloFriends>Well, looks like I'm stuck here a bit. I feel that I should add a menu-entry for debian in the bootloader configuration, but I'm not sure what to pass as the argument to "linux". It looks like my debian partition isn't mounted, so I can't go look. I tried adding the debian partition to the file system with my uuid, ran guix system ... as root, that <Brendan[m]2>Is there any barrier to setting WaylandEnable=true for GDM? <msavoritias[m]1>I installed guix yesterday and after I installed the updates. Which I had to start a lot for some reason btw. It says "cannot determine provenance for current system". When I do guix system reconfigure. <xelxebar>HelloFriends: Is your /boot on a separate partition? <xelxebar>HelloFriends: Either way, it's probably easier to just manually mount the partition (with the `mount' command) and peek at the grub/grub.cfg under there. <HelloFriends>Yeah, I think there's an old /boot on the debian partition, and I think that running the graphic install instead of manual made this one the boot drive. Not too familiar with the details of bootloaders, so take that statement with a grain of salt. <HelloFriends>Working on figuring out mount now, thanks for following up. :) <xelxebar>HelloFriends: Your mount command will look something like this: mount /dev/sdx1 /mnt/foo. The /dev/sdx1 is the partition where your boot files exist and /mnt/foo is the mount point (i.e. the base of the filesystem hierarchy for that device). <HelloFriends>I got it! Thanks. A question, do you think maybe I could just use fdisk or something to put the boot flag back on my debian partition, and it would load the old bootloader? I'd then add GNU Guix from the Debian side <xelxebar>HelloFriends: No, the boot flag won't help in this case. Let me explain. <xelxebar>The boot flag is mostly for ms-dos/windows. In your case, I guess the bootloader is grub. So we need to tell grub where to find your different partitions---one for debian, and another for guix. <xelxebar>Grub is usually configured by looking at grub/grub.cfg in the boot partition. <xelxebar>HelloFriends: The problem you are experiencing is this: Both Debian and Guix are creating that grub.cfg automatically; however, neither of them know of the existence of the other, thus they obliterate the menu entries for the other guy. <Brendan[m]2>when a shepherd service fails, shepherd still says "service ... has been started", only afterwards does it say failed to start <xelxebar>HelloFriends: If you want seamless dual-boot between the two, we will need to configure *both* guix *and* debian. <xelxebar>HelloFriends: Is this making any sense so far? <HelloFriends>@xelxebar Ah, ok. Boot flag is meaningless here. Your explanation makes sense. I'm curious how I can use the other bootloader if I have multiple partitions on a hard drive, with other their own /boot directory, but I was able to mount the debian filesystem and I can see the grub.cfg file there to find the initrd and kernel path. Do I use the mounte <HelloFriends>d path in my config.scm, or can I use something like /dev/sdaX/boot/initrd.img-4.19.0-10-amd64? <HelloFriends>I'm surprised to hear that I'd need to configure debian's bootloader as well, considering that my computer seems to boot into guix? I'd load into Debian, restart and it'd load debian's config, and Guix would be gone? <xelxebar>HelloFriends: The path needs to be relative to the root of the parition where those files exist... If you don't have separate boot partitions, then yes, this means just use the full path for where those files exist. <xelxebar>HelloFriends: Well, once you get guix's bootloader section configured correctly, then all should work just fine for now. <HelloFriends>@xelxebar When you say relative to the root of the partition where those files exist, I do think I need to start with '/boot/vmlinuz-4.19.0-10-amd64' for the kernel for example. Considering I mounted my files to /temp, and /boot is right in there <xelxebar>Well, once you get guix's bootloader setup, then it should work for now. But the issue is that Debian will eventually try to reconfigure/update grub.cfg once it updates a kernel, grub, etc. <xelxebar>So at the moment, you probably have two grub.cfg's lying around, one for Guix (living under /gnu/store somewhere) and one for Debian (living under /boot/grub/grub.cfg in the debian partition). <xelxebar>The most flexible (and easiest?) fix is probably tell each distro to put a "source (some-partition)/path/to/other/distros/grub.cfg" line in it's grub.cfg. <efraim>the easiest option would probably be to add a menu-entry to chainload the debian grub from guix, but i'm also not sure how that works if you install a new kernel in debian, if that sets debian as the default and you need to add a chainloader from there back to guix <xelxebar>Hrm. That might work. I successfully use the "source" option to maintain a custom grub.cfg "wrapper" that points to several other OSes. <xelxebar>Not that familiar with chainloading, but sourcing seems lighter, maybe? <efraim>i don't really know. I just know that chainloading is A Thing™ and sounds like it could work. It's been many years since I've had more than one OS on any machine I've owned. <HelloFriends>Hmm, this gives me some stuff to search for later. Still trying to configure my .csm file, getting an type error on the menu-entry portion <HelloFriends>is it (menu-entries (menu-entry ...)) or is there a separate syntax for arrays? <nckx>HelloFriends: (menu-entries (list (menu-entry ...) (menu-entry ...))) <HelloFriends>Ah, list. Thank you @nckx! That makes sense...shows my experience with functional programming. :P *nckx wanted to say that Lisp famously stands for Array Processing Language but 't would sound snarkier than intended. First, coffee. <Brendan[m]2>Maybe thats what the Carp lisp is. Carp ARray processor <nckx>efraim: Are you planning meson-build-system cross-compilation support as a surprise for 1.2.0? <HelloFriends>Hey again, just wanted to thank you @g_bor @xelxebar and @nckx for your help with my questions :) I got my bootloader configured properly thanks to your help. <efraim>I have an untested patch to allow meson to install lib to a separate output based on nix's patch <xelxebar>efraim: Speaking of. I went ahead and spun up a beefy GCP instance to try building the bbb image. If you're still building and would like to kill it, please feel free :) <efraim>xelxebar: I wish you luck! I feel like it shouldn't be this hard to build an install image <efraim>have you thought of creating an os image instead to flash to it? it might go better <nckx>HelloFriends: How did you set it up? Guix's menu-entries don't yet support ‘configfile’ and such, right? <xelxebar>efraim: Hrm. Either way I want to install on the internal flash. Naively, I just figured and pre-made install image would be easiest... <xelxebar>Any idea why guile-static may be failing with the above error? <xelxebar>"while setting up the build environment: executing `/gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile': No such file or directory" <nckx>Assuming the above file exists, is it really static (=is it not trying to load a nonexistent ld/library)? <xelxebar>nckx: The bin/guile exists as well as the loader it points to (/gnu/store/<hash>-glibc-2.3/lib/ld-linux-armhf.so.3). <xelxebar>I really just need to lern me sum debugin skilz. <HelloFriends>@nckx Sorry I missed your message, it looks like I got disconnected as well. I was able to mount the debian partition to find the location of parameters needed for the bootloader-configure options in the main config.scm file I used, to manually add Debian back to the GNU Guix bootloader <xelxebar>HelloFriends: Guess you just added the linux and initrd fields directly? <HelloFriends>@xelxebar Yes, indeed. That's the only way I thought I could do it! :) <nckx>HelloFriends: Aha. Won't those parameters change when you update your Debian kernel/initrd? Or do they maintain some kind of /boot/bzImage → /boot/blah-5.8.2-deb145 symlinks? <HelloFriends>No, they likely will change based on what xelxebar had mentioned earlier. But for now, I have my main workspace back, which was my urgent need...haha :) <HelloFriends>The future plan will be to see if I can add GNU Guix to the Debian grub.cfg in some way. Looks like Debian automatically maintains it when it runs update-grub. I'll make a note to look into symlinks for that as well. <nckx>I recommend using ‘configfile /path/to/guix-grub.cfg’ from the Debian side, letting Debian install the main GRUB, and using ‘(installer #~(const #t))’ to disable Guix's GRUB installation every time you run ‘guix system reconfigure’. Guix will still update its own grub.cfg. <nckx>But play with that when you can afford to. <HelloFriends>That makes sense! Thank you for the helpful recommendation! <nckx>Of course the real fix is to add configfile support to Guix, but that's worth doing properly and probably why it hasn't been hacked together yet. <Brendan[m]2>make-forkexec-constructor lets me provide a command, but how can i provide a command with arguments? <nckx>Something like this untested mess: (make-forkexec-constructor (list (string-append #$bash "/bin/bash") "-c" (string-append #$foo "/bin/foo --blah=\"$blah\" --blergh") ...)) <nckx>I assume ‘shell variable’ == ‘environment variable’? <Brendan[m]2>hmm ok. I just found an example like what i wanted that used #$@ to simplify a bit <nckx>but I can't recommend it. You should be huffing environment variables at this level IMO. <Brendan[m]2>what the hell kind of jargon is huffing an environment variables <msavoritias[m]1>Anyone know if the warning cannot detect provenance for current system means? <nckx>msavoritias[m]1: Probably that your system was built by a Guix so ‘old’ that /run/current-system/provenance doesn't exist, and the current Guix can't guarantee that it's not being downgraded. <nckx>It's a relatively new feature (months?) so that's not unheard of. <msavoritias[m]1>But how is that possible since I used the latest iso and not the stable one? <nckx>Probably reconfiguring once. <msavoritias[m]1>I did. But it didn't solve anything. Hmm. But I did with my options on top. I all try with the vanilla reconfigure <nckx>guix pull && sudo guix system reconfigure. <nckx>And add your /etc/your/system.scm to the end. ***jess is now known as jess-o-lantern
<xelxebar>Of course bin/guile is missing... in the qemu environment. I was building for a non-native arch using binfmt-misc... doh <nckx>o/ high-five another, who just wasted a quarter of an hour laboriously substitute*ing the wrong arm of an if-expression. *nckx ruins joke, eats cookie. <sneek>Welcome back divoplade, you have 1 message! <sneek>divoplade, divoplade says: Anonymous message :) <nckx>sneek: divoplade gave you a botsnack - be polite <nckx>sneek only listens when you address them, unless you randomly say ‘x is something’, then it'll remember that eternal truth for bloody ever. <nckx>Guix is pretty neat, it has all the packages and doesn't afraid of anything. <nckx>Hmph, of course now it doesn't work. <sneek>Guix is pretty neat, it has all the packages and doesn't afraid of anything. <nckx>sneek: The bot is a lie. <nckx>sneek: Guix is a functional package manager for the GNU system and beyond. <nckx>Let's leave a more useful message for future generations. <Brendan[m]2>hmmm, i made a user with (group "users) and (supplementary-groups '("wheel")) but it only got put in the wheel group, not users <nckx>dsmith has recently done some work on sneek. Some of her more, er, ‘charming’ sides may've been filed off. <nckx>Brendan[m]2: How are you checking? <nckx>Ah. The primary group is specified in /etc/passwd. <Brendan[m]2>im dealing with the most annoying bug where text input in the tty shell is buggy, most key presses dont register, i have to hold a button in and wait for it to work, and then try backspacing accidental extra inputs <nckx>So like something else is swallowing a (random) half of your keypresses? <divoplade>Do you have a cat sitting on the side of your keyboard? <nckx>I've had that happen when I ^C out of a gnupg password prompt and pinentry-tty keeps running in the background. I have to kill it or wait for it to eventually die. <Brendan[m]2>and only after logging in with this new greeter i packaged agreety <sneek>I could be wrong, but nckx is a nice 👤️ <nckx>That could've gone horribly wrong. <leoprikler>We haven't forgotten about your sneaky activities to undermine GNU ;) <nckx>^C is handled lower down the stack, at least on VTs, IIRC. *nckx still waiting for that paycheque. <leoprikler>Yeah, Soros is quite slow when it comes to paying protesters. *nckx was already wondering above if ‘the GNU system and beyond’ could in any way be deliberately misconstrued to mean ‘and better’, sigh. <nckx>Hey you, get in the back of the queue. <nckx>It knows what's good for it. <leoprikler>sneek, this paycheque thing is nothing you should worry about. <divoplade>sneek, later ask nckx sneek, what is this paycheque thing? <sneek>Someone once said this paycheque thing is nothing you should worry about. <Blukunfando>Indeed—worrying about something that won’t come is a waste of time. <divoplade>sneek, later ask nckx /me, what is this paycheque thing? <sneek>I've heard this paycheque thing is nothing you should worry about. <nckx>sneek knows who pays for the botsnacks, that's all I'll say. <nckx>I'd complain but I don't know to whom. Microsoft? Bill Nye? The FSF, notorious haters of free software? For a global conspiracy with money to burn, the admin is a right mess. <divoplade>sneek, later ask nckx /me, divoplade is a good person <sneek>nckx, divoplade says: /me, divoplade is a good person <nckx>‘/command’ isn't actually IRC, it's a client-side convention, which I'm sure sneek doesn't self-implement. <nckx>With that hint, I will take brief leave. <sneek>Welcome back divoplade, you have 1 message! <sneek>divoplade, divoplade says: /msg sneek help <divoplade>sneek, later ask divoplade sneek, tell divoplade there is a message <sneek>Welcome back divoplade, you have 1 message! <sneek>divoplade, divoplade says: sneek, tell divoplade there is a message <leoprikler>sneek remind divoplade in 5 minutes pizza is ready <OriansJ>divoplade: well no, that would enable inject attacks *raghavgururajan couldn't find pizza at 07:30, so orders 3-egg omelette <sneek>divoplade, divoplade says: something <sneek>/me, divoplade says: something <mothacehe>cbaines: could the coordinator submit-build method be called over HTTP? <mothacehe>I'm considering running the GBC on berlin, Cuirass on hydra-guix-101 and use all the other machines as GBC agents. <mothacehe>ok so that could be done by Cuirass about the same way I guess <mothacehe>but we would also need a mechanism to notify Cuirass of build success / failure <cbaines>mothacehe, the hooks might work for that <mothacehe>right, if we implement some routes for that in Cuirass <mothacehe>other question while you here. I see that there are publishing hooks, but the build outputs are not registered in the coordinatore Guix store are they? <nckx>xelxebar: Check is already an input (although it should probably be native-, but that's by the by). <nckx>Time to figure out why it's not found 😉 <nckx>...and its other input, libxkbcommon, isn't actuall used... <nckx>xelxebar: Finding the packages isn't the problem, it's the ‘uknown’ platform stuff that goes wrong at the beginning with CMAKE_DETERMINE_COMPILER_ID et al. <nckx>Failing to find the packages at the end is just a symptom of general fuckedness. <nckx>I wish I knew enough about CMake to tell you where to start. <kmicu>Is it possible to get (and pay for) a Linode server without executing proprietary code? <civodul>kmicu: i assume so, but i admit i haven't done it myself <madage>hello guix! When inside a build phase, how does one access a binding that's outside it? <madage>I've tried using let outside the package and also using package properties, but I only get unbound variable errors... <nckx>Pasting your code to a bin would help heaps. <madage>nckx: I'll give a brief and then post it. something like: <madage>(define-public package-name (let ((myname "thisismyname")) (package ... (add-after 'phase 'other-phase (let ((localname myname)) (do something <xelxebar>nckx: Oh. Cheers for taking a look. Luckily the cmake backtraces make it easy to figure out what's falling over. <madage>or (package .. (properties '((myname "thisismyname"))) (add-after.. (let ((localname (assoc-ref properties 'myname)) (do something <nckx>madage: You're missing a (λ ...) around the let. And a , before myname, but there's no reason in that limited example for the inner let localname. Just use ,myname directly. <nckx>I doubt properties are the way to go. <nckx>xelxebar: Happy to hear that, to me it's just gibberish. <nckx>Something is empty; death. <madage>nckx: ok, I only tried it because I was not being able to use let, but indeed I did not try to ',myname' <nckx>Make sure you have (arguments `(... and not (arguments '(... for that to work. <madage>nckx: I'll try it, if I still can't do it I'll post the code.. thanks <vits-test>Hello Guixen. Do someone know, if the groups "audio" and "video" needed at all for graphical sessions? And with elogind? <Jonathan[m]4>the package im trying to build is feverishly dependent on `libsystemd`, where can i include this into a package for build-time dependency? <nckx>Jonathan[m]4: You patch out every feverish remnant. <vits-test>nckx: Hello, and: what, we have no libsystemd? <nckx>Not that I'm aware. And hi 🙂 <madage>nckx: ha!, it did the trick.. foolish madage scanning docs and code all around and forgetting the basics <nckx>You're welcome. Don't worry, these details will become second nature soon enough. <nckx>Bwuh, we don't have a Go importer? ***jonsger1 is now known as jonsger
<Zambonifofex>Hello, everyone! I’m new to Guix, and I have been trying to get a satisfactory set up with it using QEMU for a couple days. I have decided to try using Sway, and I have been trying to get it to be started by a display manager (any is fine). <Zambonifofex>It seems GDM *can* launch Wayland sessions nowadays, but only if it runs on Wayland itself, which Guix seems to disallow for some reason. Is there any technical reason for it to not be able to run on Wayland, or is it just that no-one has put the necessary work into it? <Zambonifofex>It seems lprndn was working on a LightDM service, but that seems to have stalled a couple months ago. It seems that it is in a “good enough” working state. Would anyone mind helping me with trying it out for myself? (I’m not too familiar with Scheme.) <Zambonifofex>I was not able to install and use SDDM. The closest I got was getting it to show up, display “Sway” as an option, but freezing entirely when I click the “login” button. In my latest try, it shows a black screen after booting successfully. ***jonsger1 is now known as jonsger
<roptat>I don't use sway myself, but I don't think there's any technical reason why gdm can't launch sway, except nobody worked on it <roptat>I know there are other sway users here, and I think they simply run it from a tty <Zambonifofex>Hello, roptat! I have been able to run it from a tty, but only when I use `%desktop-services`, which means I have to manually switch to a tty, because it seems to automatically put me on GDM by default. ***jonsger1 is now known as jonsger
<Zambonifofex>Which is not a big problem, I suppose, it’s just a bit annoying, I think. <Zambonifofex>nckx: Do you prepend this to `%base-services` or `%desktop-services`? <nckx>I use a manual list of services based on a subset of %desktop-services. Haven't kept up with %desktop-services, but you can remove (say) gdm using modify-services without copying the lot. <nckx>There's an example in the manual but make sure you import the right module for ‘remove’; the Scheme world had the bright idea to have 2 incompatible removes in common use 🙂 <msavoritias[m]1>If we run gdm on Wayland could it theoretically run also X sessions? <msavoritias[m]1>If that happens we could work around supporting two versions of gdm. <stikonas>msavoritias[m]1: desktop manager and sessions are unrelated, X desktop manager can run wayland sessions and vice versa <vits-test>Zambonifofex: for sway to work U technically need only (service elogind-service-type) added to Ur services in config.scm <Zambonifofex>vits-test: I see! I will hopefully try it out soon, thank you! <vits-test>Zambonifofex: I not remember well, U may need to reboot(?) after `reconfigure`. *raghavgururajan peeps in 👀 <vits-test>raghavgururajan: yay! more bsddaemon jokes awaits! ***daviid is now known as Guest63596
<raghavgururajan>vits-test, Btw, your previous ping about something bite you, what was that about? ***jess-o-lantern is now known as jess
<simbaclaw>should I just install my guix system without encryption to circumvent the problem? <roptat>can't you configure libreboot to start grub from the disk? <roptat>no idea, maybe chainload? I don't use libreboot, so I'm not really sure <jayspeer>simbaclaw: I don't know 'bout the libreboot, but afaik coreboot can use grub as a payload <simbaclaw>well basically the bug I showed in the channel shows that you can chainload it but there is a specific hash that gets changed every time you update guix or change packages <simbaclaw>which means any time I update my system I'd have to manually update grub <simbaclaw>I rather just install a unencrypted guix I guess <nckx>That's not what chainloading means. simbaclaw: can you not use ‘configfile’ from Libreboot's GRUB to load Guix's grub.cfg? <nckx>That doesn't answer my question though. <pinoaffe>so I'm trying to install guix on another machine using the manual process, and I keep getting an error "in procedure getpw: entry not found" - anyone know what I'm doing wrong? <simbaclaw>I'll try to figure out how that can be done, I'm a bit of a noob when it comes to libreboot, this is my first libreboot system <nckx>raghavgururajan: Any idea? You wrote that Guide. <simbaclaw>the post installation part doesn't come up for me :/ "On reboot, as soon as you see the libreboot graphic art choose the option load operating system [o]" "Enter LUKS Key, for libreboot's grub, as prompted." well I'm not seeing any prompts, it's not coming up at all. <nckx>simbaclaw: Well, it's the same guide, but... different, so who knows. <simbaclaw>it doesn't look like anything grub related was changed in the guide though <nckx>simbaclaw: Wait, you're not seeing any Libreboot prompts? <simbaclaw>I'm seeing libreboot, but not any prompts when selecting load operating system [o] with full disk encryption <simbaclaw>it just stays at the graphic art of libreboot and does nothing <simbaclaw>I saw the other person in the bug report say that if you install it unencrypted it would work :/ I could give that a try <nckx>‘there's only visible a blank page with the artwork and it does nothing’ was ambiguous enough that I assumed that it was the Guix artwork. <nckx>So if the manual ‘cryptomount (ahci0,gpt1) … boot’ commands work, Libreboot is doing too much or something different, you'd have too look at the code (hitting ‘e’ on "Load Operating System (incl. fully encrypted disks)", not return). I don't have Libreboot myself. raghavgururajan does, I'm still hoping they see this. <simbaclaw>I'll give it another look. Perhaps I could try copying the bootloader part from config.scm <nckx>I cloned the libreboot repository; here's what its GRUB actually does when you select that option <nckx>That's what runs instead of the ‘cryptomount (ahci0,gpt1) … boot’ that worked for the bug reporter. <nckx>Hm, by the way, ‘cryptomount (ahci0,gpt1)’ - that isn't a ‘fully encrypted disk’ at all... is it? <nckx>But it's in the guide so fine. ***lle-bout_ is now known as lle-bout
<roptat>that's encrypted root fs I guess <simbaclaw>I'm reinstalling right now with raghavgururajan his bootloader configuration in config.scm <Zambonifofex>I tried adding the `elogind` service with `(service elogind-service-type)`, and that seems to have worked, but I can see no reference to it in the manual. The closest thing was an `elogind-service` “procedure”, but that seems distinct. Is it normal for it to not be in the manual? <nckx>Zambonifofex: Unfortunately not abnormal enough. The manual is, er, manually kept in sync with the code. Here, it wasn't. <nckx>And wow, elogind-service-type was added just over 5 years ago, so you're the first to notice or at least complain. <nckx>Maybe back then they weren't expected to replace the procedural style. <EventualVisitor>I've been trying to create a package specification for a golang package that depends on GO111MODULE environment variable, but it's hardcoded to "off" because current build system doesn't seem to support otherwise. <EventualVisitor>Sorry if my question has an obvious answer. I've just learned today what Guix is. <jackhill>EventualVisitor: As I understand it, the go-build-system dates from a pre-modules time, and we haven't implemented a module suporting system. The go-build-system works, but is known to be non-ideal <jackhill>A package that doesn't support being built with it off (interesting, I didn't know those existed) might be good motivation for improving the build system. Maybe you can start a new bug or thread on guix-devel? <jackhill>EventualVisitor: a hand-wavey description of the current build system is that it takes the dependencies and symlinks them into GOPATH. <EventualVisitor>Some packages have a hard dependency on the new module system. At least, github.com/ethereum/go-ethereum has this quirk. <EventualVisitor>Can you point me to some documentation that allows me to understand how to modify go-build-system.scm in a running system (apparently a sacrilege!) or after building a new image from scratch? <EventualVisitor>I'll open a bug thread just in case, and I'm looking ahead to hack a patch together if the rabbit hole is shallow enough. <ryanprior>EventualVisitor: I'm not sure what you mean - to modify it on your own system, or to modify it dynamically at package build time on other people's systems? <jackhill>Welcome to Guix by the way! I've found developing Guix to be very enjoyable and hope you do too. <ryanprior>I looked at go-ethereum recently and it's definitely a motivating case for improving the go tooling, both to make the build system module-aware and to get an importer in place. <ryanprior>I estimated go-ethereum probably has ~300 indirect dependencies, which is gonna take a long time to package without an importer. <ryanprior>I've built up some Emacs macros for go packaging during the last month of my work on Hugo, but that's not near as efficient as a decent importer would be. <jackhill>I agree, I think both modules and an importer would be nice improvements <nckx>I was surprised earlier today that there wasn't a Go importer yet. <ryanprior>There is a patch to add one in the tracker, but it's "flaky" according to a comment (I haven't tried it) <nckx>I thought Guix support for Go & Rust was advancing at about the same speed. <nckx>Well, the Rust importer's pretty flakey, maybe that's still true. <nckx>Welcome++, EventualVisitor. <EventualVisitor>After giving another try to the building from git instructions, I'm stuck at "Guile-JSON is missing" when running `./configure`. I'm sure it's me, but not sure how <nckx>Not sure where the sacrilege would lie; Guix is made for hacking. The only thing we really don't like is when people modify the read-only store. <nckx>That's less a moral judgment than a ‘please stop juggling flamethrowers, we won't be able to help you after that.’ <nckx>EventualVisitor: Are you running the build inside a ‘guix environment’? <ryanprior>EventualVisitor: did you run `guix environment --pure guix` before running configure? <ryanprior>If you just installed Guix today, you might have an old version still. <nckx>Yes. I've had to explicitly add --ad-hoc guile-json in the past but not recently. <ryanprior>Okay, exit your env shell and run `guix pull` then try again. <nckx>After pulling, make sure to run ‘hash guix’ and that ‘type guix’ refers to /home/nckx/.config/guix/current/bin/guix. <ryanprior>Warning, it may take an hour or more depending on your machine power. <nckx>Then re-enter the previous Guix environment and try again. <nckx>Has anyone tried including a build system in a channel? Is that expected to work? <EventualVisitor>It's running on VirtualBox with a old Haswell i7 top-notch (from its era) processor, and it should be fine, but internet connection is flaky and I'm pretty sure about that hour estimation <ryanprior>nckx: I haven't tried it but my understanding of how channels work is that they overlay the entire Guix system, such that you could modify any part of it including the build system. *kmicu is sad Haswell is considered old now. <ryanprior>The omnipotence of channels is part of what makes the limited design of Potluck so interesting to me :) <nckx>'s Also my understanding (and experience) but so's there being a world of difference between that & practice 🙂 <ryanprior>Oh yeah I wouldn't want to bet on it until I'd tried it. I'm very hands on that way =D <nckx>That is unfortunate because flakey networks are still one of Guix's weak points. If it would fail with a backtrace, just try again. <EventualVisitor>Do you know what's the approximate size of the pulled data? I might be able to use a (metered) mobile connection instead. <nckx>I'm not sure enough to say. <nckx>The Guix itself is in the order of tens of megabytes at most but I've no idea which dependencies would be downloaded during your first pull. <ryanprior>I think the dependencies are rather heftier, definitely in the hundreds of megabytes if not a few gb. <ryanprior>This would be a cool thing to calculate & publish on the Guix data service, filing that away :) <nckx>With a connection like that ☝ I fear they might not have the greatest Guix time. <FlakyConnectionU>:wave: I'm the go-ethereum user. The connection died unexpectedly and so I did, but it seems to be working again after a few retries <nckx>Uh, guix system reconfigure ripped down my Wayland session, wasting an hour of linux-libre building. <nckx>I wonder why it did that and how it must never happen ever again. <nckx>raghavgururajan: Dunno, haven't heard from them since. <FlakyConnectionU>Getting the same error after `guix pull` and even running `guix environment guix --pure --ad-hoc guile-json`. I'm going to repeat the process with a fresh virtual machine, just in case. <ryanprior>FlakyConnectionU: it's possible that `guix` after guix-pull is still pointing to your old one. Did you do `hash guix` afterwards and check the version? <ryanprior>I recently tried to build some packages on the Guix System VM from Vagrant Boxes and found I had to run `guix pull` /twice/ for some reason <ryanprior>It would be nice to put out a new version of Guix anyhow, 1.1 is feeling long in the tooth imho <raghavgururajan>sneek, later tell simbaclaw: If booting technique under 'post-installation' doesn't work for first time, try the booting technique (first 6 points) under 'completion' heading. <FlakyConnectionU>I'm using VirtualBox as a virtual machine, it was the easiest, quickest and old-school option I could find <ryanprior>If you've just run `guix pull`, doing it again should think for ~20 seconds and then tell you there's no work to be done. <ryanprior>If it does anything else, then either new commits just came in (possible) or it somehow didn't finish everything the first time. <nckx>Then, paste the output of ‘guix describe’ to paste.debian.net (or just share the commit here). <nckx>If it fails to determine a commit you're still using the old guix command. <sneek>Welcome back joshuaBPMan, you have 1 message! <sneek>joshuaBPMan, nckx says: Congratulations on (and thank you for) the blog post! \o/ <joshuaBPMan>sneek: thanks! Chris did most of the writting and Ludo did a fair amount of editing (and patiently waiting for me to re-submit patches). <joshuaBPMan>civodul: haha! Editors make publishing possible civodul :) <rekado>FlakyConnectionU: make sure you use the expected “bin/guix” <rekado>is this ~/.config/guix/current/bin/guix? <rekado>if not: try running “~/.config/guix/current/bin/guix describe” <rekado>then figure out why “guix” isn’t ~/.config/guix/current/bin/guix <rekado>FlakyConnectionU: root is just another user account. <rekado>if you run things as root you’ll get the root user’s “guix”, which is distinct from all the other user accounts’ “guix” programs <rekado>the first time you run “guix pull” successfully it should ask you to augment PATH and run “hash guix” <FlakyConnectionU>For the record: I've added ~/.config/guix/current/bin to my .bash_profile and sourced it ***amfl_ is now known as amfl
<FlakyConnectionU>Running again `guix environment guix --pure` triggered some downloads, including Python 3.8 (versus 3.7 on some previous install logs) <FlakyConnectionU>My $PATH inside the "virtual environment" only includes "/gnu/store/···/bin" and "/gnu/store/···/sbin"