IRC channel logs
2024-04-17.log
back to list of logs
<jamesvasile>instructions for GuixOS and Guix package manager on a non-Guix linux system. Thank you. <rekado>jamesvasile: if you intend to contribute your changes (please do!) please see the Contributing section in the manual. <jamesvasile>rekado: Sure, assuming I discover a workflow that gets me a useful package, I'll look into that. <JerseyJoe>I installed the musescore package but cannot actually find the executable for musescore anywhere on my system. <dthompson>hmmm blender fails to export to gltf citing missing numpy... but python-numpy is an input <dthompson>also we should have a fresh blender package and not only the lts <dthompson>figured out the blender issue. needs the executable wrapped to set GUIX_PYTHONPATH <axioms>Hello, I've been using guix for a couple months now and I am really enjoying it. It's my favourite GNU/Linux distribution! I am interested in ways I could contribute to the project? I am building my first home server and was wondering if it was possible to become a server for substitutes? I had encountered an instance once a couple weeks ago when the substitutes server wasn't working so I had to do guix reconfigure --no-subtitutes. <axioms>So I thought I might be able to help by adding an extra substitute node myself. <axioms>I also have been considering trying to contribute my first package to guix, but I haven't yet put in the time to try and make my first package or contribution. But I do know of at least one open source package I use that guix is missing that I could add, but I haven't yet learned how to. <futurile>axioms: if you're interested in getting involved with packaging doing some reviews is a good place to start - we're running sessions learning as a group <axioms>Okay thanks! I am very interested in doing that. <axioms>So I sign up on meetup.com and then join a video call via jitsi where the review takes place? <futurile>axioms: yes, we do a call on Jitsi and basically chat through reviews or look at how to do different things. <futurile>axioms: there's full instructions on how to do reviews on that Wiki page, so you're also welcome to start using those instructions - if you get stuck ask here, or on the mailing list - or come along to the Jitsi call with your question - whatever works :-) <futurile>axioms: for the substitute server - you should ask on the mailing list probably - not sure how you get involved there <axioms>futurile: Okay great thank you for the information. I am going to look into that. I am going to join the mailing list too, that seems to be where a lot of the main development takes place. <futurile>axioms: yes, definitely a lot of the discussion takes place on the two lists - there's also a public inbox instance at https://yhetil.org/ <fnat>Those functions seem to have a pretty general value, is there anything in Guix that does that already? <darosior>Is there a simple way to workaround for using musl as the libc to the fact that gcc-toolchain references the "static" subpackage that musl doesn't provide? <darosior>Basically this: guix build: error: reference to invalid output 'static' of derivation '/gnu/store/q8gsshh5yg51jnsf2rwr2z1cvjf6l21x-musl-1.2.4.drv' <civodul>darosior: oh, i guess we should change musl so it has a “static” output too <civodul>mesa-updates, congrats podiki & all! <darosior>civodul: i'm writing an email to help-guix but while you're here would you have any idea why trying to `guix build` with `--with-input=glibc=glibc@2.29` would fail with a dependency cycle against perl? Is rewriting inputs even supported for something as fundamental as glibc? <darosior>For a simple repro: `guix build rust-log --with-input=glibc=glibc@2.29` <civodul>darosior: good question; i suspect it’s not really supported <sham1>I'm a bit curious about what sorts of file system configurations people here have. Mainly for desktop and laptop usage <sham1>I'm looking for new inspiration so I don't just go with btrfs again <oriansj>sham1: well there is zfs, whole volume encrypted luks, lvm managed subvolumes and classic vanilla ext4 setups <oriansj>and bcachefs is now available in guix but generally people don't get too creative with their filesystem setups as they don't want to lose all of their files and data <aldum>I'd go zfs, bcachefs is nowhere near battle-tested enough <saper>one can run traditional filesystems on zfs zvols, pretty neat setup sometimes <dariqq>for a package would it make sense to put 0.2 MB of gtk-docs to a docs output? <mekeor>hello. does anyone have a (perhaps work-in-progress) package for lean version 4? <GNUtoo>Hi, I've the latest Guix revision ('858c40ced4 gnu: mullvadbrowser: Update to 13.0.14 [security fixes].') in a git and I did guix shell -D guix and inside ./bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc && make and then './pre-inst-env guix system image -t iso9660 --label="test-image" --system=x86_64-linux --fallback gnu/system/install.scm' and it gives me that error: <GNUtoo>ice-9/boot-9.scm:1685:16: In procedure raise-exception: Git error: cannot locate remote-tracking branch 'origin/keyring' <GNUtoo>So is this expected? And if so is there another way to build the installer from git? <GNUtoo>My use case is that I want to modify the installer to repurpose it for something else and so I need to test and build it. <GNUtoo>Basically I'd like to build an iso with some tools and reuse the keyboard selection from the installer. <civodul>GNUtoo: hey! you need to make sure the ‘keyring’ branch is available, for instance by running ‘git fetch’ <GNUtoo>It's at '1b6a6d6b24 Add the key of Oleg (sharlatanus). <GNUtoo>Though the last key seems to have some strange linebreaks <GNUtoo>Ah many keys also have strange linebreaks <GNUtoo>Anyway thanks for the answer, because as I understand it it means that it's supposed to work somehow. <GNUtoo>So I could try guix 1.4.0 and try to debug it a bit to see why it fails. <civodul>or maybe the remote is not called ‘origin’ in your checkout? <GNUtoo>Outside of the guix shell, git show --show-signature origin/keyring even shows a valid signature <GNUtoo>This is why it's strange and why I asked <GNUtoo>And I don't know if there is something specific in the release process because here that gnu/system/install.scm is not any random system definition, <GNUtoo>As I understand it will reuse the installer that is in gnu/installer and that is not a package <GNUtoo>Outside of the git the command to generate installers seems to work though <GNUtoo>I don't remember which command I typed to do that but guix system build generated a rootfs, I didn't test it though. <redacted>Does the guix shell -D switch automatically build inputs with debugging info (as --with-debug-info= would)? <civodul>redacted: no, you would have to pass this flag explicitly <rekado>the linux-libre deblob scripts are incredibly slow. I'm building a customized kernel for my aarch64 system for the second day in a row and the deblob script takes longer to run than the kernel build. <redacted>Is it possible to specify that packages should be built with debug info in the guix.scm file? I know things like glibc:debug exist, but lots of packages don't have a "debug" output. <civodul>redacted: you could try “guix shell -D whatever --with-debug-info=foo --export-manifest > manifest.scm” for a starting point <civodul>we should document a ready-to-use recipe for that <civodul>it’s quite natural to expect debugging symbols for development :-) <GNUtoo>For linux-libre doing the deblobging by hand is also slow, so I wonder if there could be a way to cache somehow the output of the process, like provide a substitute for the deblobbed sources for instance, so people that don't need to modify the deblob process can just recompile kernels with different options for instance, or patch it afterward. <GNUtoo>(by hand means running the script manually) <redacted>civodul: what should I expect that manifest to contain? I tried `guix shell -D nano --with-debug-info=ncurses --export-manifest` and got `(package->development-manifest (specification->package "nano"))` <redacted>I'm not hacking on nano, it was just as an experiment with a package to make sure my own package wasn't messed up. <civodul>so you could see what ‘guix shell nano --with-debug-info=ncurses --export-manifest’ does (without -D) <futurile>hmm is ci.guix.gnu.org OK? I'm getting a gateway timeout <futurile>it seems like it's idle and not building, but master failed <darosior>how long does it take for an email to arrive on help-guix? I assume it's moderated as i sent one this morning and it's still not showing on the lists.gnu.org archive. <Altadil>darosior: if it’s the first time, it needs manual approval, I believe. <redacted>It looks like I can't export a manifest for a package I loaded into guix shell with -f. Is that correct? <redacted>`guix shell -f guix.scm --export-manifest` gives an empty manifest <redacted>specifically `(concatenate-manifests (list))` <redacted>`guix shell <package-name> -f guix.scm --export-manifest` fails to find the package (which makes sense) <futurile>redacted: you can see what was created in the environment with $GUIX_ENVIRONMENT I think <redacted>For a more complete picture: I'm developing my own software with a guix.scm file in the software's repo. I'm using `eval $(guix shell --search-paths)` in a direnv file to set everything up for Emacs. Ideally I'd find some way to map over the inputs and replace them with versions that retain debugging symbols in my development environment. <futurile>redacted: so you have a package that you've created in a guix.scm, but you want all the inputs to be built with debug symbols? <podiki>civodul futurile: thanks! now to remember to close/update all the issue numbers... <futurile>podiki: now you want my bts package so you can do a bunch from the command line ;-)) <podiki>the fanciest I got was once recording an emacs macro to automate a bunch of closing messages; i felt very smart for such a simple thing (i'm not a keyboard macro person usually) <redacted>While I'm developing it the package anyway <redacted>Yeah, right now I'm thinking the best approach would be to define a package variant in a guix-dev.scm file and transform all the inputs. <GNUtoo>civodul: ah maybe I know why: no space left on device <GNUtoo>ah no, same thing, and same thing with 1.4.0 git too <mccd>Heya, what's the correct way of referencing a package? I'm trying to setup greetd to run dbus-run session, and wrote the folowing (greetd-agreety-session (command (file-append dbus-run-session "/bin/dbus-run-session"))), but it naturally complains that there is no dbus-run-session variable <mccd>but it does know about the existence of zsh which perplexed me a bit <civodul>mccd: the ‘dbus-run-session’ program is part of the ‘dbus’ package <civodul>so that’d be (file-append dbus "/bin/dbus-run-session") <mccd>ah makes sense, ty @civodul <lispmacs[work]>Hi, folks are busy I'm sure, but was hoping I could draw extra attention to this bug, since it was holding up some much needed upgrades on my server: <lispmacs[work]>git blame doesn't show any changes to the agate service/configuration definitions in the last year, from what I could tell, so it is not obvious to me what is going on <lispmacs[work]>I think the agate software itself has not changed either in that time <lispmacs[work]>oh wait, there were actual some changes upstream, so maybe that ties into it <civodul>futurile: should be fixed with 7bed290fdfd830d690daf065de6d2ecab73309d9 <yewscion>Hello Guix, I'm having another occurrence of an issue I've encountered a few times before on my VPS: Upon reboot, I get an error saying that `chmod` doesn't exist, and I am dropped into the recovery shell. This occurs no matter which of the entries I boot to, and on an installation that was booting successfully before. <yewscion>I am a bit out of my depth here, though, as I've never used the early boot repl before. Is there a guide somewhere to help me troubleshoot, or is there another vector I can take to figure out what is causing this? <futurile>yewscion: I'm not going to be much help here - but did you try and rollback? <yewscion>I cannot boot, unfortunately. I tried using each of my grub entries, and messing around with the boot manually a bit, to no avail. Same issue in each case. <efraim>lispmacs[work]: I see that in the intervening time between your two generations agate was upgraded from 2.x to 3.x <lispmacs[work]>though, the service definition compiles, so I suppose that would have to be an issue with the service definition <futurile>yewscion: oh so you're in a 'grub' recovery 'shell' then I gues? <efraim>from a very quick look through it looks like cert and key should be combined into certs, pointing at the directory both are inside of <efraim>I'll see if I can put together a proof-of-concept patch, but I can't test it with my current setup <lispmacs[work]>efraim: I'm glad to help with testing, if I can. I have gemini content and certs. I'm not quite clear exactly how the cert naming is handled in the new agate system - will have to look into that <Retropikzel>I'm trying to compile things inside guix shell and it complains it cannot find -lm and -lc, what package do I need to add to the shell for those? <civodul>i tried the x86_64-linux-gnux32 cross-compilation target that efraim added in Guix <efraim>x32 has always been a fiddley target. I'm pretty sure I could see the horror through the mailing lists when someone suggested adding ilp32 for aarch64 <yewscion>futurile: I make it out of grub, but not to a usable operating system. Here's the text I can copy through OCR; I'm using a WebGL shell that doesn't allow copying, currently: https://paste.debian.net/1314385/ <podiki>btw, added to the mesa-updates merge commit a short list of major package updates, since it was easy for this branch <futurile>yewscion: sorry I'm not turning up anything useful in the guix-help mailing list on what you can actually do with the 'early guile repl' <yewscion>futurile: That's okay, thanks for looking anyway! <futurile>yewscion: maybe try mailing the mailing list see if someone know what you can do from there <yewscion>Will do, after I get done what I actually need to work on today, haha ;^_^ <janneke>ACTION posts v4 of the second patch series for reproducible tarballs (#70380) <janneke>and is very grateful for eps. pelzflorians' prompt and apt reviews! <janneke>it' crept up to 6 patches by now, oh well <bigbookofbug>what would be the correct way to mound a share in the config file? i attempted the following: <bigbookofbug>(file-system (device "//IP/share") (mount-point "/mnt/share") (type "cifs")) <bigbookofbug>but it seems not to accept "//IP/share" as a valid dev name due to it being remote <sham1>janneke: jokes aside, this seems to be a good step not only towards more reproducibility but also reducing supply-chain attacks. Very exciting! <sham1>Meanwhile I'm coming back from my Guix hiatus on one of my laptops <jab>I am trying to update my guix system linode. <jab>guix deploy stopped working for me a while ago. <jab>so I am going to build guix from source on the linode. <jab>that's the plan anyway <podiki>has anyone seen this message before (on a reconfigure dry run): GC Warning: Repeated allocation of very large block (appr. size 135168): May lead to memory leak and poor performance <lechner->Hi, I lost the ability to reconfigure one of my machines. 'guix system reconfigure' simply hangs. What's a good way to investigate, please? <jab>lechner-: here's how I "fixed" that lately... <jab>I built guix from source (from a fresh clone), then sudo -E ./pre-install-env guix system reconfigure <jab>then guix clone worked. <jab>oh and I also deleted my system and package generations and did a guix gc <Guest36>I have as shebang this "#!/gnu/store/jyw1a3grkkn10hq35laq04l4h3w49n2n-emacs-29.3/bin/emacs -Q --script" and basically want to run this: https://github.com/emacs-exwm/xelb/blob/master/xelb-gen but it returns "\nGenerating xcb-xproto.el...emacs: standard input is not a tty" and I don't understand why. I want to upgrade emacs-exwm to the latest Git <jab>I've got a bug report that talks about it. I can try to find it if you want to take a look. <lechner->jab / unfortunately, that won't work for me. I use extra channels <podiki>you can use extra channels with a local guix <lechner->i was told pulling was the gold standard <podiki>I think just passing -L /path/to/channels if you have them locally, otherwise I think passing a channels file <podiki>i rarely do it and have to look it up when I do, but that's what i remember <podiki>you can also pull using your local guix, just from using pre-inst-env I believe? <podiki>(likely get some provenance warnings later) <jab>podiki: after you build guix from source via ./configure && make... <podiki>but i've just used my pre-inst-env guix and passed channels/load paths to do a reconfigure. or even to install packages temporarily <jab>can you do a 'sudo make install' ? <podiki>do we have an install target? i never looked <jab>podiki: I don't know...I know that a lot of the "serious" guix developers don't bother using guix pull. They just build from source all the time. <podiki>i don't usually pull from my local guix, no, but do use that guix to install/reconfigure/etc. sometimes <podiki>mostly because my sense of time and history I think will get confusing mixing my local guix with usual guix pull <podiki>but you can pull to a different profile as well <jab>podiki: profiles are confusing to me. Most things in guix are super easy to use...ie: I love that we deprecated 'guix environment' and created 'guix shell'. guix shell is soo much easier to use. <Guest36>lechner- things have changed since the last release <podiki>jab: well I can't help you with guix pull profiles as I've only ever pulled to a /tmp profile to test that i didn't break guix pull; not sure if/how people use that in practice. i do use profiles for managing my packages though <jab>podiki: I wish it was much easier to use. like "guix package new-profile 'emacs-packages' && guix package " <jab>"guix package -i emacs-geiser" and those would auto be put in that profile <jab>and your local emacs can auto use those packages <podiki>we could certainly make profiles more of a first class citizen, so to speak, and make managing multiple profiles easier than having your own shell script loop <jab>aka I wish guix profiles would modify your path to add each profile by default <podiki>lilyp had a proposal for multiple profiles but sadly didn't pick up steam. would love to see better use of profiles <podiki>none of that or improvements should be difficult, just no one has done them (yet!) <jab>podiki: yeah I can't complain. I still need to do more work to update guix's opensmtpd service <podiki>you are also allowed and encouraged to submit patches :) <jab>well, I would rather encourage and thank the guix developers. or maybe I should be willing to complain, but only after I submit a patch or too. :) <podiki>(i'm guilty of having quite a few locally that need to be submitted: peroxide service (protonmail bridge), extending our oci-container service, various packages...) <jab>podiki: you can submit your patches to guixrus <jab>that's where my opensmtpd service currently sits. <jab>also 'guix shell --pure --check -D guix' is taking 10+ minutes so far. <jab>I guess my server is really outdated. <podiki>yes thanks, am aware of guixrus but have not delved in. more of that I have things that work, just needs polishing for inclusion anywhere really <jab>guix shell guix is not building nss :) <rekado>ACTION still waits for "Scanning the generated tarball for blobs..." before the kernel can be compiled <sham1>Oh good grief, apparently I can't have /gnu/store be ext4, because grub doesn't know how to cope with that <jab>sham1: are you sure? I use ext4 for /gnu/store <vagrantc>sham1: you mean /gnu/store as it's own partition, or part of / ? <sham1>Yeah, /gnu/store as its own thing <sham1>Wait, why would it care if /gnu/store is in its own partition? The grub.cfg script seemed that it should just work <sham1>How would doing things like mounting / as a tmpfs work then <vagrantc>because it loads the kernel and initramfs from /gnu/store ... or did that change? <vagrantc>some of the workarounds involve copying the kernel initramfs etc. to /boot ... <vagrantc>sham1: it's not that it cares so much as the code does not handle that perfectly reasonable use-case <sham1>Yeah, it does actually try to look up the kernel relative to the /gnu/store partition <sham1>So that shouldn't be a problem <vagrantc>and yet you get "unknown filesystem" ... which might be a red herring as to what is actually wrong <sham1>Well I dropped down to the grub shell <podiki>yes, very annoying that grub doesn't support ext4 settings from many years ago <podiki>i turned on large_dir (I think) and made it so i couldn't boot <lechner->ACTION thinks the kernel definitely resides in the store <sham1>Anyway, I did `ls (hd0,gpt5)` which is the partition where /gnu/store resides, and it tells me that it's an unknown filesystem. FWIW I also got "unknown filesystem" from grub-install when I tried to have /boot on my root partition at first, since / was on ext4 and I didn't have a separate /boot <lechner->or maybe it's just the large_dir thing again? <sham1>Yeah, I suspect that it might be the large_dir thing <sham1>Now I'm wondering if XFS might be better. I've done btrfs before, but eh <sham1>And yeah, btrfs worked when I had /gnu/store be its own subvolume <lechner->don't try bcachefs; i don't think we support it yet <sham1>I literally only gave the mkfs.ext4 the label of the filesystem as a flag <sham1>But yeah, it really shouldn't matter what the root filesystem or /home or whatever is, as long as grub can look inside /gnu/store, it should just work <sham1>So this seems more like a grub bug than anything <lechner->sham1 / are you sure you booted with the latest grub? for GPT, sometimes an old version resides on the MBR. <podiki>if i recall, large_dir is nice since /gnu/store gets very large <podiki>unfortunately when i checked, grub does not work with large_dir ext4, despite that being a feature from manyyears ago <podiki>there were some bugs/emails about this on guix when i hit it, very annoying <podiki>i may have even emailed the grub list about it? but didn't hear back if i did <podiki>well i did email the grub bug (ha) list and never got a response <sham1>Because even if guix wouldn't allow for /gnu/store to be its own partition (in which case the manual should really mention that and it should probably barf at you for the misconfiguration), it's weird that grub doesn't even recognise the filesystem, so I'm leaning more towards it being a grub problem rather than not being able to cope with a separate FS <podiki>and this is known (if you search for large_dir and grub) and is old. i say blame grub <podiki>but we should document since i think large_dir is useful for guix, and if it was a default, then we really need to warn <podiki>we could also work around it somehow but i'm no expert here <podiki>other messages for grub and large_dir go back to 2019 <sham1>Oh wells, I suppose xfs might be a good fit <sham1>Should handle loads of files quite well at any rate <sham1>I'll just probably have to add some xfsprogs and it should be good <jab>guix shell -D guix is still on the check phase for nss. grrr. I'll be patient... <civodul>jab: hmm you’re not getting substitutes for nss? <civodul>on x86_64 at least there are substitutes <lechner->jab / can you identify whether your deploy problem is on the local or on the remote equipment? <jab>civodul: I am trying to update my linode guix system. It hasn't updated since Aug of last year. <lechner->civodul / this may be the same issue i have <jab>I noticed that it wasn't updated a while ago, when guix deploy stopped working. <jab>I am currently trying to build guix from source on my linode. <jab>lechner-: I am not certain how I would prove if the problem is my local laptop or my server... <lechner->i tried system reconfigure locally, but that also hung <sham1>Anyway, I reformatted the store FS into xfs and grub now recognises it. I'll reinstall the stuff there later <sham1>It's almost 1 o'clock and I need to wake up in about 6 hours <sham1>I'll see then if grub still fails to do its job. If it does, then I'll admit defeat, but not yet, damn it! <sham1>And if I admit defeat, I'll just combine / and /gnu/store <bjc>you can have /gnu/store on a separate fs? <bjc>i always assumed it had to be on / <podiki>lechner-: at the time large_dir wasn't default for ext4, but no idea if anything changed. i had added it manually when i was getting too many files in a directory. then disaster because of aforementioned grub not supporting a standard feature from years ago <lechner->jab / i believe my pull issues shows only upon reboot of the remote <jab>lechner that issue in that bug report was detailing my laptop. <jab>I guess I should create a bug report for the guix deploy bug that we are facing? <jab>jab is my guix system nick and gnucode is my hurd nick. <jab>I am about to go walking with some friends. I'll be back in a few hours.