IRC channel logs
2025-02-06.log
back to list of logs
<mra>the patches were sent with git send-email, and some context was in an email sent to <issue number>@debbugs.gnu.org, which i understand to be all that's required <mra>just wanted to check that i didn't do something wrong, since it's been a couple of hours and they havent appeared on the webpage <podiki>the issues frontend hasn't updated in a while, it is not you <mra>podiki: ah, thanks for letting me know! <podiki>no worries, i actually hadn't noticed until today either <mra>i just assumed that i was losing my mind or missing some permissions or something <mra>but that makes perfect sense. having one bug tracker for all of gnu seems a bit absurd to me though <mra>i'm sure I'm not the first person to suggest that though <podiki>well issues is just a frontend guix runs <podiki>there is the actual debbugs site for everything <podiki>(just the frontend is behind as far as i know) <coyotes4ys>i need to config my gtk, how do i know what version all my applications use? <mra>podiki: my emails also don't seem to have appeared on the debbugs backend. I guess either that's also behind or else I really did screw up <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, eikcaz says: No worry! Thanks for the offer to review #75959. Let me know if you have any other questions or concerns. Configuring Syncthing from Guix has been neat, so I hope to share that. <vagrantc>mra: is the bug marked as closed? it may not accept new content until reopening it... <look>mra: IIRC if its your first time sending an email to a specific list it has to be approved manually the first time, next time (after the approval) it will be automatic <coyotes4ys><coyotes4ys> but it says Xorg: command not found <coyotes4ys><coyotes4ys> is this not the way to do it? is there a different package/command? <coyotes4ys>why is the guix manual seemingly wrong regarding guix system X window? <wakyct>I'm not sure but that's an old version of the manual <wakyct>I think you need the xorg-server package for the Xorg command <wakyct>what is it that you want to do though? <wakyct>the up to date manual has 'devel' in the URL <coyotes4ys>i need to change the font (size especially) in all programs <wakyct>on the Guix site in the top bar nav from Help go to Manual (latest) btw <coyotes4ys>lxappearance, various gtk configs and the qt config <coyotes4ys>or gdm package in guix seems to be the way for guix geeks <coyotes4ys>is that a decent understanding of the situation? <coyotes4ys>if so i'll install gdm which for some reason is not installed <lfam>I'm starting to write a configuration for a VM image to test your syncthing contributions <eikcaz>Oh wow, neat. I originally tested with guix home container <eikcaz>I did something like: guix shell -D guix -CPW -- ./pre-inst-env guix home container --share=/home/zacchae/tmp/guix empty-config.scm -- cp /home/zacchae/.config/syncthing/config.xml /home/zacchae/tmp/guix/empty-config.xml <eikcaz>also leaving the container running shows that syncthing does not clobber the config <coyotes4ys>anyone, how do you configure themes/fonts for X window? <eikcaz>At this point, I have deployed that service across my devices and it is working as expected. <lfam>eikcaz: That's a neat way to test it, but I don't use Guix home and learning it would only slow this process down :) And I have plenty of experience with Guix VMs. I'll try using your code to add a device to my Syncthing cluster and see how it goes <lfam>I noticed your updated patch, clever <eikcaz>Thanks. Makes configuring even simpler <lfam>coyotes4ys: Regarding fonts, did you see that the Guix xorg-configuration has a fonts field? <coyotes4ys>the manual says to use gdm it appears. but no i don't have xorg installed <lfam>GDM can use Wayland or Xorg. So, you must have one of them if you are using GDM <lfam>It looks like openbox uses Xorg <lfam>So, it's available on your system. <coyotes4ys>the package Xorg is not on my system it appears. can't tab to it, command not found <lfam>Does your Guix System configuration file say anything like "%desktop-services"? <coyotes4ys>i can't find in the manual how tto access my guix system configuration file <lfam>You should be able to find it at '/run/current-system/configuration.scm' <coyotes4ys>anyway i just installed gdm but it install like 100 programs and/or libs <lfam>You don't need to install GDM like that <lfam>On Guix, you don't install system programs like GDM. Instead, you create services (like GDM) in your configuration file and reconfigure the system. <lfam>But, I don't think you need GDM at all <lfam>Does your Guix System configuration file say anything like "%desktop-services"? <coyotes4ys>hopefully it will remove all that stuff it installed with it <coyotes4ys>man that was super quick compared to all the time it took to install all that stuff. but i guess it justt changed sector headers and removes references to the packages/libs in other programs? shrug <coyotes4ys>anyway lfam the answer to your question is yes, i find this in my configuration.scm <lfam>Okay, if you are using Openbox with that configuration, then you are using Xorg <lfam>It's a program that lets you have multiple windows <lfam>It will probably take some effort to set up <lfam>That's okay, you don't need to use the Xorg command for this <coyotes4ys>thank you for taking me throuogh all this, lfam and wakyct too <lfam>I recommend you send an email explaining what you want to do, along with your configuration file, to <help-guix@gnu.org> <lfam>It will be easier to get help with this via email <coyotes4ys>what if i just guix install lxappearance? or is that also something that i shouldn't need and i should make a service <lfam>Hm, not sure about that. I would install it and see what happens <coyotes4ys>and that did it for vlc which apparently uses qt <coyotes4ys>perhaps there is a similar thing i can do for gtk? <podiki>you can of course use guix home to set env things, but there is no guix-system for any of these in particular that i know of <podiki>i just mean nothing is particular to guix at this point <coyotes4ys>thank you that middle comment was illuminating podiki! <zamfofex>Hey Guix! I’m trying to install Guix System with the Hurd on a Vultr VPS (using the installer), and it seems to be failing to build the ‘hurd’ package. I looked into the build logs, and it seems to be missing ‘-lpciaccess’ when linking something during the build. I wonder if anyone might have any hints about what might be wrong. <lfam>My impression is it's possible but there are a lot of rough edges. If you don't get an answer here, please report it to <bug-guix@gnu.org> <podiki>this was a recent issue, are you on a current commit? <podiki>i think commit beb9ad2cf7e83b747781b47cdde2f75a19cd3a1b <podiki>and possibly some commits just after that <zamfofex>Hmm. I’m using the installer very recently downloaded from: https://guix.gnu.org/download/latest/ It says “7w8666y9g15r48cxn3ib542mzcmb88zm-image.iso”. ‘guix describe’ tells me I’m on d48da2d21610f9cf5f76cd846703b12beedb1fd5, which seems indeed older. <podiki>not sure, there is something about the guix package/in installer compared to guix pull bu t i don't remember <zamfofex>podiki: Yeah, looking more closely into ‘guix describe’ output, it has as its repository as directory name in the store, which seems unusual! <zamfofex>I wonder if I might be able to “cheese it” by runnning ‘guix pull’ (perhaps with some flag to specify the repository) before commencing the installation properly. <podiki>it has something to do with how guix provides itself...? it comes up but not sure what key words to give you to find out <podiki>i think if you do a guix pull and then maybe "hash guix" and run commands with that guix...? <lfam>That would be the move to get up to date <podiki>sadly not familiar with the details of how the installer and guix package work <lfam>The problem is, if you build the installer from commit 123456, it can't contain a copy of Guix that corresponds to commit 123456, but only an older one <lfam>It's a limitation of the functional model <podiki>maybe the installer images are a bit old since cuirass was stuck recently...might just be unlucky timing <lfam>Yeah, solving this puzzle is the purpose of the 'guix' package <lfam>We basically only update it in response to bug reports like this one ;) <zamfofex>But it seems Guix on the installer is newer than the ‘guix’ package itself, so it seem to come from elsewhere. <lfam>I must remember the details incorrectly <lfam>What commit is it? (`guix describe` <vhns>I'm trying to get docker running with a user namespace. That requires, amongst many things, for it to have access to the `getent` command. So far, what I did is this: https://paste.debian.net/1348649/ . Yet, /var/log/docker.log still reports me not being able to find getent. From what I could gather, I'd need to add an entry for getent here: <zamfofex>lfam: On the installer, ‘guix describe’ tells d48da2d21610f9cf5f76cd846703b12beedb1fd5 <lfam>vhns: It's possible to only change patch-paths phase of the Docker package definition, but it's going to be much faster to just copy it <lfam>And, maybe it's worth a patch to <guix-patches> <lfam>Somehow it's able to do (guix (current-guix)) in the guix-service-type <zamfofex>Hmm, I saw! I guess that’s probably why it has a repository pointing to the store. <zamfofex>So, I guess ultimately, the “proper” way to solve my issue is to either wait for a new installer image to build, or to install it in some other way. <lfam>I'm not sure how the latest installer gets built <lfam>But, it's defined in gnu/system/install.scm <lfam>I mean, I can give you an example of how to build it yourself. But I don't know what part of our infrastructure is supposed to be building it <zamfofex>sneek: later tell lfam: I imagine the installer might be built by the “images” job. <zamfofex>sneek: later tell lfam: Thanks for the help, anyway! <apteryx>lechner, lilyp: I've rebased and submitted a modified fix to #63508 <euleritian>There was this blog post 16 months ago promising regular updates on how things go with the guix daemon in Guile. Has there been any development? <euleritian>The blog post says that they have money to work on it for a year, so by now they should have run out of money. <sneek>Welcome back lfam, you have 2 messages! <sneek>lfam, zamfofex says: I imagine the installer might be built by the “images” job. <sneek>lfam, zamfofex says: Thanks for the help, anyway! <zamfofex>lfam: Aha. Interesting coincidence that you revealed those messages just now, I was actually about to share some updates on that. <zamfofex>Some further thoughts about my Hurd endeavors: I noticed there was a more recent build of the installer image just a few hours before the last conversation ended. I eventually got it to complete the installation! But with a DOS partition table, which Vultr doesn’t seem to support at all. I tried to install it with a GPT partitition table, but then the installation failed when installing GRUB. <lfam>If it's GRUB that fails, it can't be too hard to figure out how to tell GRUB what to do <zamfofex>I think I figured out the issue. It seems Vultr requires UEFI, but the system configuration was using ‘grub-minimal-bootloader’ rather than ‘grub-efi-bootloader’. It seems the ‘-efi-’ variant doesn’t actually build properly, because of peer dependency ‘efivar’, which seems to be specific to Linux. <zamfofex>s/peer dependency/indirect dependency/ (I think I’m too sleepy now.) <zamfofex>(I’m not even sure it’s indirect now that I think about it.) <zamfofex>A final piece of thought for today: I don’t think Vultr actually requires UEFI, but it does require a GPT partition table. but I can’t get the installer to generate anything that GRUB recognises as a boot partition. I could probably do manual partitioning from the command line, I suppose, but I’m not very familiar with it. In any case, sleepy tiem for me for today! <mra>question about the patches workflow: i'm trying to resolve a stagnant issue, so i sent some stuff to the relevant issue on debbugs. would it be appropriate to send an email to the guix-patches mailing list to let people know about it, or should i just wait? <mra>i'm somewhat new to the whole email-based workflow <Rutherther>mra: no, because sending email to guix patches is going to open new issue <simendsjo>Ref my problems building webkitgtk yesterday, trying with -c1 (overnight) worked. Otherwise it was non-deterministic and failed at different points. <efraim>I made some minimal adjustments to get go cross-compiling of binaries to work but the inputs I'm substituting are from the host, not the target <mra>Rutherther: ah, thanks. good to know. <hapst3r>I've been wondering about this several times now: how do I ensure that SOME programs prefer OS-provided stuff over Guix stuff? <hapst3r>I am trying to re-setup the gnome nextcloud integration and it always loads the GIO modules from Guix, even when GIO_EXTRA_MODULES is set to the module folder provided by the OS (in .zshenv) <csantosb>civodul: great news, thanks ! Is there any other guix repo expected to be mirrored at codeberg too ? I understand that pulling happens automatically, right ? <yelninei>hi, does anyone know why the guix-locate test is failing for me: sqlite-exec 8 "attempt to write a readonly database" . It is working correctly when i run it in a guix shell container <yelninei>i tried anything from removing the guix and guile cache and even recloning the repository <hapst3r>Follow-up: I set the environment variable in the desktop file of the gnome integrations service <ennoausberlin>While issues.guix.gnu.org is not updated I noticed that llvm is broken with a lot of consequences due to dependencies. Is someone working on that? <efraim>how is llvm broken? I recently fixed it (i think) so that we can cross-build mesa again <civodul>csantosb: there’s a job running on Guix infra that periodically updates the repo (every other hour) <civodul>and no, i don’t think there are plans to mirror others <civodul>this one is the most critical, since Savannah has been broken every other day lately <civodul>yelninei: could you figure out which file it’s attempting to write to? <civodul>should be ~/.cache/guix/locate/db.sqlite by default <Deltafire>i'm having difficulty with a package. It's failing to find any of it's 'inputs' when doing the RUNPATH check at the end <yelninei>civodul: it fails at the last line in the test 'guix locate --clear'. Stracing that reveals that it is trying to write to /var/cache/guix/locate/db.sqlite (and ofc failing) <yelninei>(i have the package-database-service-type in my system config which is where i guess this comes from) <efraim>ok, I think I'm going to split the release manifest into 2 manifests: one for the installer and one for "these packages really all need to build" <efraim>maybe more manifests, I don't really need to have it all in one I guess <yelninei>(oh guix locate --clear fails even normally because it is trying to clear the root owned db) <efraim>maybe you ran sudo guix locate at some point and now root owns the database? <efraim>ACTION only read the last message, feel free to ignore if it doesn't make any sense <yelninei>efraim: i think this expected from the package-database-service-type which updates the global database as a (root) cron job. But guix locate --clear is trying to use that and ofc failing <civodul>yelninei: oh i see; could you report a bug for this? <yelninei>moving the /var/cache/guix/locate/db.sqlite out of the way fixes the test/issue <yelninei>civodul: have now registered a free mail and will send once the account is approved (might take 1-2 days) <civodul>yelninei: out of curiosity, would you be more likely to create an account on Codeberg than to fiddle with email? <ennoausberlin>efraim: I tried llvm 2 days ago but did not pull since then. When did you fix it? <efraim>ennoausberlin: I made sure that it could be cross compiled about 2 weeks ago. how is it broken? <yelninei>civodul: I dont have a problem with email per se other than the problem of exposing my personal mail in public lists <ennoausberlin>efraim: I am not infront of the computer right now. It is an aarch64 machine. And now substitutes available. How can I check on the CI if there are successful builds available? <efraim>`guix weather llvm` will check if there are substitutes available for llvm <yelninei>(i already have an account at codeberg because gitlab asked for a credit card or phonenumber to filter out spam registrations) <ennoausberlin>efraim: guix weather almost always fails for aarch64 packages. <efraim>substitute availability has been low recently on aarch64 <civodul>yelninei: right, ok; i’m asking because we often hear about reluctance to create an account, shown as an advantage of email (i’m in that category) <ennoausberlin>efraim: We should prioritize the large packages known to fail more often on the CI and ignore others that can be build locally. Having some watchdog on these packages would be nice. Is this technically possible? Building rust, go, llvm webkit etc on a local machine is quite annoying and burns CPU cycles worldwide for nothing. <efraim>ennoausberlin: as part of the Upcoming Release™ I'm updating the manifests of packages we Need™ to be available <ennoausberlin>efraim: Sounds interesting. Can you elaborate a little on that? <efraim>right now we have a release manifest which lists all the packages that should have substitutes available at release time. I'm splitting it up into packages we need for the installer and packages which are needed for cross-building an OS config and ones which are needed in general <efraim>we don't have an installer for aarch64 but I'll probably add it to the installer manifest to make sure it works, since there's a sizable group that use Guix System on aarch64 and the same packages should build as in the installer <gabber>how can i get the store path of a package from within a (home) service? <ennoausberlin>efraim: Nice. Are the manifests available in one of the repos? <efraim>the current release manifest is in the guix repo at etc/manifests/release.scm, the others aren't public yet <yelninei>civodul: I would tend to agree as one already needs to have an email to register the account at the various forges. The main difference is that with a mailing list i need to disclose my mail with the whole world as apposed to the forge admins only <civodul>yelninei: right, that makes sense to me <civodul>it also seems to be more common these days to contribute anonymously to free software <civodul>that wasn’t the case a decade ago (or more) <efraim>do we have a grub that will run on BIOS or EFI? <civodul>well, from anecdotal evidence anyway <efraim>i'll try it. I'd like to replace grub-bootloader in install.scm <jakef>after a month long packaging stint, guix gc deleted 217 GiB xD <csantosb>I was wondering whether there is a way to trace back contributions ? For example, commit a53bd6f27b originates in #76056. Is that possible ? <civodul>csantosb: in theory, ‘Change-Id’ was added for that purpose <civodul>in practice, none of the tools uses it currently <nutcase>Hi, my "sudo herd status" hangs with 0% cpu <nutcase>I booted my computer with date set to 2020 (probably due to cmos battery missing). That led to 100% CPU and i was unable to reboot. I switched off the computer, set the date in my BIOS/UEFI and booted into GNU Guix. Now, I can't use "sudo herd status". It simply does not return <nutcase>what could be broken, (how do I debug) and what can I do to fix it? <nutcase>related: halt / reboot also don't work / return. <seek52>Hi folks, I'm having trouble with disk encryption (LUKS). The encryption is for the root filesystem, so the disk needs to be decrypted at boot. <seek52>I'm trying to decrypt the disk with a key file located on a USB drive. <seek52>Right now, when the system boots, it only asks for a password once before the GRUB menu appears. <efraim>janneke or anyone else, is isc-dhcp supported on the hurd? <janneke>efraim: it is installed on debian/hurd so in princible yes <efraim>thanks. it currently fails to cross-compile to i586-gnu and I wanted to make sure it's supposed to build <janneke>isc-dhcp-client/now 4.4.3-P1-1.1+hurd.1 hurd-amd64 [installed,local] <janneke> DHCP client for automatically obtaining an IP address <efraim>I'll try to check it out later, right now I'm messing with some manifests <janneke>ACTION has no idea what might be needed for integration <hanker>Can I force connman to favor my dns servers over the dns servers it gets with DHCP? <Z572>hi, what status about core-packages-team branch? <civodul>i haven’t been able to look into it since FOSDEM <Z572>If core-packages-team isn't ready yet, maybe next queue first? <civodul>oh crap, i hadn’t realized it was next in queue <civodul>or maybe yes, let’s gnome-team go first <Z572>I also want to merge some base package upgrades to core-packages-team, like #76085 #75797 #75028 <civodul>Z572: please feel free to merge them if you consider them ready <mra>if people are merging things, may i recommend #55231 👀 <cbaines>civodul, can you remind me how to manually load/eval shepherd stuff on bayfront? <cbaines>I think the paste you previously sent has disapeared now <civodul>cbaines: i sent the trick on guix-sysadmin, this time for berlin :-) <civodul>herd eval root '(register-services (list (primitive-load …)))' <cbaines>haha, I had that email open, I just hadn't read it yet :) <civodul>replace the ellipses with the /gnu/store/*-sphepherd*.scm thing <civodul>cbaines: BTW, should “we” propose subscription of a Hetzner server for web services, as discussed in Brussels? <cbaines>civodul, I'd still like to stop personally renting the machine for data.guix.gnu.org, so maybe that's a good candidate for something to move across <civodul>cbaines: oh, what was the blocker here? <cbaines>maybe it's possible to pay Hetzner through the SumUp thing, although I don't know how long that would last for given there's problems topping up the funds from the FSF <civodul>let’s let Foundation folks figure out how to get things paid <xelxebar>Uh, that's not normal: /gnu/store/49ygdzi7w51dimqdhlbzq3lw7na0c2wr-module-import-compiled.drv is an empty file. <cbaines>civodul, I can try and send an email about it, I think the next steps are for someone to create a Hetzner account for the foundation and try and setup the billing/invoice side of things <xelxebar>As is /gnu/store/gcplqqyiqvpszgq0f46x6s1ys7wh3fm7-kexec-load-system.scm.drv, the sole referrer of the above. <xelxebar>Causing my guix system reconfigure to fail right at the end. <civodul>cbaines: right, if you can provide detailed instructions for that, that may help; probably email both guix-sysadmin and guix-europe (public) <dariqq>wanted to test the greetd changes and i am getting an error during the activation script: guix system: error: mkdir: File exists "/run/user" when i reconfigure <look>dariqq: I am getting the same trying to reconfigure <zamfofex>Hello, Guix! Some updates on my Hurd endeavors from last night: I got GRUB to detect a boot partition properly (by just making it sufficiently small, it seems), but it seems to fail installing some locale files to it (because it is too small!) It seems if I make it too large, GRUB doesn’t recognise it, and if I make it too small, it can’t install the locale files to it. <zamfofex>Not sure what’s the expected way to go about resolving this, hrmph. <look>dariqq: I applied something around those lines to my local guix, guix pulling right now, will let you know if it works <dariqq>wait this does not work, mkdir-p has no second argument <dariqq>look: Should I send my patch or do you want to send yours? <look>dariqq: you can do it, no problem <olndrxyz>Hi, i3status is not applying my configuration on Guix. The config is in ~/.config/i3status/i3status.conf and I'm pretty sure everything is correct. In my ~/config/i3/config I have `bar { status_command i3status }`. If I set in the `general` module of the i3status.conf the `colors` directive to false and then reload the config, colors are still displayed. Can anyone confirm this behavior or provide a working config as an example? I manage my dotfiles with <Rutherther>olndrxyz: the correct path is $XDG_CONFIG_HOME/i3status/config, you have the name wrong. It's in the man page of i3status <olndrxyz>if I use that path I get an error that I don't remember now and the bar is not loaded at all. <Rutherther>if you get error with that path, my guess would be the config has been loaded, but it's wrong. So I am not sure what you're trying to say... <zamfofex>I have realised that the “BIOS boot partition” and the “/boot partition” are not the same thing at all. I have also learned that Vultr does require UEFI boot as of somewhat recently after all. I have read that you can request for disabling UEFI boot to their support team, and that they respond reasonably quickly, so I might try that. <nckx>So wait, you were marking your smol /boot partition as also of type ‘BIOS Boot’ and GRUB was… clobbering itself? That sounds like a gem of a UX bug. <zamfofex>I couldn’t find a way to mark a partition as “BIOS boot” from the installer image at all. So I was just assuming that creating a partition for ‘/boot’ would have been enough. <lfam>Might have to do that kind of stuff "by hand" in the console <nckx>Does the installer image not use cfdisk or whatever? <nckx>ACTION doesn't know which installer image is even being discussed, tho. <nckx>It's trivial in most partition editors. <coyotes4ys>i can't find /etc/xdg folder to get the openbox menu file <hanker>everything's in /gnu/store/something <nckx>zamfofex: I always use (c)fdisk when installing Guix but I don't know if the 'guided installer' does. <zamfofex>Well, in any case, I managed to get Vultr support to disable UEFI, and it seems to boot to GRUB now. I noticed (backed up by info the blog post) that it hard codes the boot device, though, which doesn’t work. Currently I’m trying to figure out what /dev/vda on Linux would be on the Hurd. <ieure>nckx, The installer correctly sets up the boot partition. <hanker>you can do `guix shell openbox` and all the openbox files will be in `$GUIX_ENVIRONMENT` <nckx>zamfofex: I hope vda doesn't imply virtio (unlike an emulated SCSI drive sda) or that the Hurd speaks virtio. <ieure> zamfofex, The installer does this stuff for you automatically, not sure what all you'd have to do to change from UEFI to legacy boot, though. <nckx>ieure: Set up how? I think it only creates a BBP when booted in BIOS/CSB mode. <nckx>So what you said in the meantime with very different words. <coyotes4ys>hanker i accidentally did that as root first, then exited, then did it as user. did i do a bad? <zamfofex>nckx: Hmm, are you saying you suspect the Hurd might simply not support it at all? <ieure>nckx, Yeah, if you're changing from UEFI to legacy or vice-versa, likely going to invalidate your setup. But I think that's the same on any Linux distro. <zamfofex>ieure: I couldn’t manage to get an UEFI install working at all, so I installed a normal DOS MBR setup, and asked Vultr support to disable UEFI. <ieure>zamfofex, Odd. I've never had an issue with installing in UEFI mode. <hanker>> hanker i accidentally did that as root first, then exited, then did it as user. did i do a bad? <ieure>zamfofex, But, yeah, the BIOS doesn't/cannot know how partitions correspond to FS mountpoints. For UEFI systems, the partition type determines whether that's the boot partition. Legacy mbr partitions have a per-pertition bootable flag. Not sure how things work with a legacy boot on GPT partition table. <ieure>No idea about hurd, never tried it. <ieure>Was looking at different messages, I think. <hanker>guix shell just makes a bunch of symlinks in `/gnu/store` and sets a bunch of environment variables so you can get access to a program "without" installing it <coyotes4ys>but after i did guix shell openbox it's showing coyotes4ys@localhost ~ [env]$ but if i ls it just shows the normal folders, same for cp showing the normal folders for that <hanker>when you exit `guix shell` the environment variables don't hangaround <nckx>zamfofex: I do suspect it but based only on experience with Linux, so it may not hold! …I hope. <coyotes4ys>i am a curious combination on n00b and experienced, sorry <lfam>sneek: later tell eikcaz: I applied your recent patch on master, with the clever "take devices from folders" logic. I copied the syncthing-service-type example from the manual, imported (gnu services syncthing), used full device IDs, and tried to build an image based on this. But it fails with "error: folders: unbound variable". Ditto for devices, when I try making a simpler syncthing-config-file that only registers some devices <nckx>Don't let me discourage you but keep it in mind if the Hurd refuses to see your drive at all. <hanker>> i am a curious combination on n00b and experienced, sorry <hanker>dw everyone's a noob before being experienced <coyotes4ys>you will see what i mean if we talk enough LOLOL <coyotes4ys>but what of my comment about ls showing normal folders, how do i access the openbox files after guix shell openbox <lfam>sneek: later tell eikcaz: Also, let me know if you'd rather move to email for this stage of the review <hanker>> but what of my comment about ls showing normal folders, how do i access the openbox files after guix shell openbox <ieure>coyotes4ys, Openbox (or whatever) binaries will be in your $PATH within the `guix shell', so, you can just enter commands. <ieure>coyotes4ys, Ditto man pages etc. If you need to see other stuff, `guix build openbox' will print the paths to it in the store, and you can poke around in there. <zamfofex>nckx: Hmm, I see. I’m currently trying to decipher how I can get to know what it even sees at all. <coyotes4ys>if i copy the whole /xdg/ folder to my own /etc/ will that do any bad? <ieure>coyotes4ys, I wouldn't recommend that. What are you trying to do? <coyotes4ys>i want the openbox config files. i guess i could just copy them to my .config <ieure>coyotes4ys, Most stuff in /etc should be placed by a declarative system service. <ieure>coyotes4ys, What are you trying to do? <coyotes4ys>if i copy autostart to my .config/openbox is that useful? <ieure>Openbox config should all happen inside your home dir. <ieure>I do not know if copying autostart (what autostart?) to ~/.config/openbox is useful, it depends on what you want to do. <coyotes4ys>i know. it said to pull it from etc/ so i thought of copying it there in case i read another tutorial and forget how to guix shell openbox etc <coyotes4ys>to answer my question yes autostart is useful, it is the config file for autostart not some other rando thing <nckx>Worse, I can't find anything on-line implying that virtio is optional on Vultr (or how it could be switched to emulated SCSI/SATA). <coyotes4ys>ratpoison? yes i shall try that soon i installed it also <mra>wahey, i got the zfs kernel module on my initramfs! <nckx>However don't use Vultr myself. <zamfofex>nckx: It’s not impossible things would work more transparently if I used a “dedicated CPU” instance, but those are a fair bit more exepensive. Honestly, I just wanted to use QEMU locally, but I’m currently using NetBSD, and it seems QEMU has failed to build on the latest MNX update, because pkgin doesn’t pick it up. (This is the only reason I’m trying to use Vultr rather than just using QEMU.) <nckx>Achso. Well, thank you for your service, at least… o7 <zamfofex>Well, I said I’d try to help submitting patches to packages once networking was fixed, and it seems to be, so I (perhaps ambitiously) wanted to see if I could get e.g. velox working (swc/Wayland compositor). But it seems I couldn’t even get it to boot at all. <nckx>ACTION notices that ‘guix system reconfigure’ is rebuilding doom for the initrd; suck that, ZFS. <nckx>zamfofex: What's swc in this context? <coyotes4ys>curious, why do ppl call it, "the Hurd" not just Hurd? <civodul>the GCD process is ratified, my friends <eikcaz>lfam: I see, looks like it's a bug in the documentation. Replace (syncthing-config-file (folders ...)) with (syncthing-config-file (syncthing-config-file (folders ... ))) and make sure you add any missing closing parens at the end <sneek>eikcaz, you have 2 messages! <sneek>eikcaz, lfam says: I applied your recent patch on master, with the clever "take devices from folders" logic. I copied the syncthing-service-type example from the manual, imported (gnu services syncthing), used full device IDs, and tried to build an image based on this. But it fails with "error: folders: unbound variable". Ditto for devices, when I try making a simpler syncthing-config-file that only registers some devices <sneek>eikcaz, lfam says: Also, let me know if you'd rather move to email for this stage of the review <hanker>> the GCD process is ratified, my friends <lfam>No, just to have a decision making process <nckx>Just the GCD process itself. <lfam>eikcaz: Okay, I'll do that. It seems rather redundant, no? <eikcaz>lfam: that is how it is normally done. the syncthing-config-file field of syncthing-configuration should be a syncthing-config-file object (or a file-like object, or #f) <lfam>I see, maybe we can adjust the naming to make it a little more clear <vagrantc>civodul: oops. meant to reply to that with a generally favorable response :) <vagrantc>ACTION proposes a GCD to change GCD to Guix Consensus Decision <coyotes4ys>i web searched but several different places on guix.gnu.org came up, can someone link me <ieure>coyotes4ys, Look in the guix-devel ML archives. <lfam>Huh, looks like my email in support was never delivered! <vagrantc>curious what the numbers panned out to be... it seemed like a fairly small number of people actually replied <lfam>I guess because I replied all, it got bounced by info-guix <eikcaz>lfam: maybe the rename the syncthing-configuration syncthing-config-file field should be changed to config-file? <eikcaz>"config-file"? not "config-file?" <eikcaz>I see that pattern in other guix services <eikcaz>e.g. (connman-configuration (general-configuration (connman-general-configuration ...))) <lfam>It's ironic that I sent mail to support the GCD process, it got bounced, and I didn't know, and the first GCD under discussion is about leaving behind the email workflow. <nckx>lfam: I didn't approve any of the many replies CC'ing info-guix@. I don't believe that's how it's supposed to be used. Your mail should have been broadcast through some other address, though. The others were. <lfam>Well, it was one of many addresses in CC, I just did 'reply-all' <lfam>It wasn't clear to me that it wouldn't be delivered to the bug ticket either <nckx>You just mentioned info-guix@ so I wanted to make that clear. <lfam>Yeah, I don't expect to be able to send mail to info-guix. But for some reason, it also didn't get delivered to debbugs <lfam>It doesn't matter, I'm just being salty <lfam>eikcaz: Now, the example fails with "In procedure string-join: Wrong type argument in position 1: "/home/leo" <lfam>(I adjusted the name to be my own <lfam>Is "~/home" expected to work? <coyotes4ys>what's the lightest-weight terminal and is terminator anywhere close? <lfam>Terminator is not light weight <eikcaz>lfam, yes I just found that bug. It's specific to guix system over guix home, so I missed it. Should be string-append not string-join. Lemme quickly resubmit the patch with that fixed and documentation fixed <eikcaz>lfam: I submitted the updated patch. The annotation at the beginning says it all <coyotes4ys>lfam, i can't get terminator to show any cpu usage in htop, so i guess i <coyotes4ys>it is a great processor but i thought at least terminator would show a little. not even a 0.1% <lfam>I don't think that the choice of terminal will have a big impact on your resource consumption <coyotes4ys>neither did i but i wanted to be pretty extreme since i want to run a daw on this <Deltafire>could anyone help me with some RUNPATH issues I am experiencing while trying to package a large cmake project? <eikcaz>Deltafire: feel free to ask away. Expertise is mixed here, so hopefully someone will have some insight on your issue. If not, you can always email your question to help-guix@gnu.org <Deltafire>okay.. i've managed to get the project to successfully compile and link an executable, but then the runpath checker is failing. The dependencies listed in the 'inputs' section are not being found <Deltafire>I'm not sure at what stage the various store directories are supposed to be added to the runpath <civodul>vagrantc: i counted 22 replies from team members, which is half of them <eikcaz>Deltafire: I'm not really familiar, but if you can't find something at runtime, maybe you should include it in "propagated-inputs" instead of "inputs"? <Deltafire>hmm.. i think that would work, but i was unsure whether this is the correct way of doing it <ieure>eikcaz, The runpath checker runs as a build phase, so I don't think this is a runtime issue. <ieure>Deltafire, My guess is that you have stuff in native-inputs that belongs in inputs. <ieure>Deltafire, How long does it take to build? Asking to gauge my level of regret at trying to reproduce. <Deltafire>about 50 minutes on this rather old i5-4590 @ 3.3GHz <vagrantc>civodul: thanks! read in the post since :) <ieure>Deltafire, Hmm, not sure I have the time for it today, but probably a good idea to share the package definition and paste the build output. <lfam>Deltafire, et al: Just because something is a Guix package input, it will not necessarily be added to the binary RUNPATH. The package's own build tooling must add things to RUNPATH, and if it doesn't then we have to help the build tools do so. But it's not automatic <lfam>So, the details depend on what build tools the program uses, and how it uses them <lfam>I'm guessing it's a CMake system <lfam>Right, so either the CMake scripts made by the developers of the thing you are packaging don't aim to include these inputs, or they are kinda half-baked and we have to persuade them <lfam>The ideal CMake usage will properly find and create these RUNPATH references to all the necessary dependencies but, in my experience, there's a big range of quality <Deltafire>should i add them to CMAKE_INSTALL_RPATH myself? <lfam>I'm not a CMake expert. I'd start by... hoping an expert chimes in now :) And also by grepping in our packages to see what other people have done <lfam>Like, grep for CMAKE_INSTALL_RPATH <lfam>Also, I'd look at the upstream CMakeLists.txt to see if it mentions these dependencies or not <lfam>Also I'd check upstream bug reports, and how other distros package this, if they do. Arch and Nix are what I usually look at for comparison, sometimes Gentoo <Deltafire>the nix one doesn't seem to do anything special.. grepping gnu/packages turns up this potentially useful setting: set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) <lfam>Yeah, could be! After years of packaging things, CMake still never clicked for me. It's always a slog when it doesn't work the first time <Deltafire>a guile-based build tool would be cool, perhaps replacing autotools :) <lfam>Autotools is usually super easy to package! Go figure <lfam>I think it would be hard to replace at this point. Might as well make a new kernel ;) <lfam>How do you actually set a user password in config.scm? I can't figure it out <ieure>lfam, I'm also interested in this. I kinda-sorta know how, but not really. <lfam>Like, I tried adapting the example in the manual but it did not work <ieure>I'm not sure it's advisable. <eikcaz>I do it. Not sure I recommend it <lfam>It's for testing your patch, in fact :) <lfam>It's like, the first field is the plain-text password, and then a salt, right? <ieure>I thought you could only stick a hashed password in there. <eikcaz>open up /etc/passwd and copy the column $6$... up to (not including) the colon <hanker>Is there a way to run an `oci-container` with a git repository/a local directory with a Dockerfile? <lfam>"Encrypt key, with the addition of salt (both strings), using the crypt C library call. " <lfam>There's no hash to be entered <lfam>eikcaz: Hm, I'm trying to generate a new system here <eikcaz>Mine looks like (user-account ... (password "$6$bzL...k1")) <eikcaz>No because I didn't want a file living in my file system with my password as plain-text <lfam>Like, is the documentation incorrect? I feel like I'm losing my mind here <lfam>I always tested things in VMs with root, but I wanted to use a regular user for this <eikcaz>the example has you put your actual password and (crypt ...) turns it into the hash. I skipped that step and just provided the hashed password, which I obtained from /etc/shadow <eikcaz>why do you need to set a user password? Just start it as root, then su to the user. root can su to user without a password <lfam>Right, that's my understanding. But it didn't work <lfam>Yeah, I could do that. Just seems like a PITA when I could just log in as a user <lfam>And it's hard to ignore these kinds of UX bugs, you know <lfam>And like, if root has no password to log in... how can I do that for the regular user? <eikcaz>oh, if it doesn't work, maybe the user name is part of the salt? <eikcaz>so if you are extracting from /etc/shadow, maybe make sure the user in your new system has the same username? 
