IRC channel logs
2025-01-22.log
back to list of logs
<sneek>Welcome back lfam, you have 1 message! <lfam>sneek: later ask dariqq: Any ideas why I'd be unable to configure CONFIG_OF off? No matter what I do, it always turns on, and I don't even get asked about when doing `make oldconfig`. It's just automatically set to Y <lfam>And of course anyone else is welcome to answer as well :) <elb>so I'm deploying a headless server using guix for the first time, and I want it to be as quickly reproducible as possible, but the current path seems ... slow, and I'm hoping someone can give me a hint as to how to make it faster <elb>I have the system configuration file, that's fine, but starting from a bare machine to that configuration takes a WHILE and is somewhat painfully manual, because the only way I know to get the process started is to start with the 1.4.0 install ISO <elb>which means an interminable guix pull, then an interminable reconfigure, then a restart, and _then_ applying my configuration <elb>is there a way to build something like an install image from my configuration, that will just blast itself onto hardware? <jmes>elb: You're probably looking for `guix system image` <elb>I tried to build a system image, I don't remember exactly what the failure mode was there <elb>oh ... I think it was meant to build a single virtual hard disk image, and I have multiple physical drives and some other stuff going on <lfam>There is also `guix deploy` <elb>hmmm will that work from the 1.4.0 install ISO? <lfam>Also, if you want to build an install image, it's defined in the file 'gnu/system/install.scm' in our source code <lfam>I don't recall when `guix deploy` was invented. So I can't say if it's supported in 1.4.0 <elb>oh my concern more is that my config probably doesn't _work_ on 1.4.0 <elb>like it would need to deploy guix now, not guix 2022 or whatever <elb>what I'm hearing is that this is not a thing, an that people install ancient guix and then put up with the hour-long update <elb>perhaps I should do the install once and then take a clean machine image and use an imaging tool to blast it on there <lfam>Probably some minor issues that most people wouldn't care about, like deterministic /dev/urandom at first boot <lfam>Also, I don't think it would even be deterministic. The seed would be identical but the kernel helps with that <lfam>You might have issues with SSH host keys if you are using SSH <elb>actually preserving the ssh host keys is probably ideal in this particular case <elb>but that's a good point <lfam>The thing with releasing a new installer... we need to do it. But it always take a little while to whip the installer code into shape and add support for new Guix features. *If* you feel like building and using an installer from current Guix, it would be a useful service to the project to report bugs and give feedback <lfam>I know there is a lot of muttering on this topic... people are thinking of ways to release way more frequently, specifically to ease the pain of what you are trying to do <elb>yeah I have seen some discussions on the list about releasing more frequently <elb>the existing installer seems to have some misfeatures, too, like I've had trouble getting it to install a working EFI bootloader if I don't let it do the partitioning itslef <elb>(might be operator error) <lfam>It's not so easy to test all different ways to install the bootloader, so there could definitely be bugs in the installer <nathan-web>Hello. I'm using `greetd-wlgreet-sway-session` and I am trying to configure autologin. Is there a straight forward way to add a `[initial_session]` section to the config produced by `make-greetd-terminal-configuration-file`? <jaft_r>Does using time-machine (particular with source) cause any need for something extra to sufficiently garbage collect? My store, which generally hovers around ~15Gb free, is down to only ~2Gb and I've deleted all past generations down to yesterday from all profiles and =guix gc= still won't clean anything up more than that. <meatus>What's the "right" way to integrate a project with Guix? The manual mentions both 'guix.scm' and 'manifest.scm', what's the right way to set up a project to use guix to its fullest? <meatus>nvm, just found the cookbook entry <jaft_r>Nvm; I've, actually, got 92Gb free in store. It's my other partition that's got only about 2Gb free so building under /tmp is running into issues. <apteryx>hm, the new 'reboot --kexec' option seems to hang my system <sneek>apteryx, you have 1 message! <sneek>apteryx, lilyp says: releng yaml file, but yeah <lilyp>I'm currently using them manually, but yeah, parsing them would be preferable <apteryx>does --with-git-url preserve or overrides existing patches/snippets ? <apteryx>seems it removes them, as I'd expect... but that --with-patch cannot be made to work with --with-git-url ? <efraim>apteryx: what if you reverse the order of your with-git-url and with-patch flags? <ArneBab>Since the last update I get errors when starting Emacs (and Emacs does not start — that’s critical for me): Warning (native-compiler): Error: circular-list (("/gnu/store/f8zrssfkk0bl84jw99f7jnv6d4qacb1i-emacs-auctex-14.0.8/lib/emacs/native-site-lisp" "/gnu/store/qvwhyxyj7hrv4582mf8dmmmwbgf6m5vi-emacs-elpher-3.6.4/lib/emacs/native-site-lisp" "/gnu/store/2f89ygldzm5ikrgd8fip7wjlz0q791jl-emacs-exwm-0.32/lib/emacs/native-site-lisp" "/gnu/ <ArneBab>store/8gy6vjlqqd7hbiqz53afgh5cai87idbd-emacs-xelb-0.20/lib/emacs/native-site-lisp" "/home/arne/.guix-profile/lib/emacs/native-site-lisp" "/home/arne/.guix-profile/lib/emacs/native-site-lisp" "/gnu/store/f8zrssfkk0bl84jw99f7jnv6d4qacb1i-emacs-auctex-14.0.8/lib/emacs/native-site-lisp" "/gnu/store/qvwhyxyj7hrv4582mf8dmmmwbgf6m5vi-emacs-elpher-3.6.4/lib/emacs/native-site-lisp" "/gnu/store/2f89ygldzm5ikrgd8fip7wjlz0q791jl-emacs-exwm-0.32/lib/ <ArneBab>emacs/native-site-lisp" "/gnu/store/8gy6vjlqqd7hbiqz53afgh5cai87idbd-emacs-xelb-0.20/lib/emacs/native-site-lisp" "/home/arne/.guix-profile/lib/emacs/native-site-lisp" "/home/arne/.guix-profile/lib/emacs/native-site-lisp" . #6)) <UncleRRR>Are you sure you update by guix pull and guix package -u ? I suggest doing that to avoid dependency traps but honestly I haven't seen your error and personally still on emacs 29 <efraim>looks like there were some patches added to emacs-next on the 19th <ArneBab>UncleRRR: I update via guix pull && guix package -m ~/guix.manifest <ArneBab>maybe I shouldn’t use emacs-next for now … <ArneBab>… no, also happens in the account without emacs-next. <ArneBab>it even happens with /gnu/store/7ns4357i8is0fd5x83fpk5612xqkb4sx-emacs-next-30.0.92-0.881d593/bin/.emacs-30.0.92-real -Q <ArneBab>temporary workaround: EMACSNATIVELOADPATH="" emacs <csantosb>Hey Guix ! It's great to have something like `guix refresh -L . -s module:"(gnu packages fpga)"` to check updates <csantosb>Do we also have `guix refresh -L . -s module:"(gnu packages)"` to check all modules inside packages dir ? <stochastic>Hi, I have a root hard drive and a home hard drive, both encrypted with LUKS. <stochastic>How am I supposed to use the luks-device-mapping-with-options to get the key available after unlocking the first drive? <stochastic>I don't want to type yet another boot password, but it has come to my attention that (local-file "/home.key") places the home key in the initramfs <stochastic>I don't want to type yet another boot password, but it has come to my attention that (local-file "/home.key") places the home key in the initrd <hako>stochastic: See documentation for bootloader-configuration's extra-initrd field. <Rutherther>stochastic: it doesn't put the key to initrd, it puts it to the gnu store <Rutherther>stochastic: and to answer your question, if the key is on the root partition, you just put in the path to it, ie #:key-file "/path/to/the/key.key" <Rutherther>relative to the 'source' that is in 'mapped-device' <Rutherther>stochastic: it should work with an absolute path, as long as the disk containing it is already mounted. <stochastic>It seems like the initrd tries to unlock home before mounting root <apteryx>efraim: I think I tried that, and couldn't make it work <jakef>anyone know a package in guix that runs the test suite pretending not to be root? <Rutherther>jakef: do you mean the one that pretends to be root? fakeroot? I don't know why you would 'pretend not to be root', the tests are not ran as root <jakef>Rutherther: oh ok, i had the wrong assumption <damjan94>I need help trying to run an AppImage. When I try to run it, it says bash: ./Buttercup-linux-x86_64.AppImage: No such file or directory <damjan94>and kinda managed to make it run with this command <damjan94>`guix shell --network --container --development ungoogled-chromium gcc-toolchain libsecret --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY --preserve='^DBUS_' --expose=/var/run/dbus --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri --emulate-fhs --preserve='^XDG_RUNTIME_DIR$' --expose=$XDG_RUNTIME_DIR -- ./Buttercup-linux-x86_64.AppImage --appimage-extract-and-run --enable-features=UseOzonePlatform --ozone-platform=wayland` <damjan94>The problem is that the app is supposed to open another window to let me login to dropbox. It usually just opens a blank screen. but once it actually asked me for credentials, and then just kept on spining forever. <damjan94>The app gives some errors regarding dbus `Failed to connect to the bus: Failed to connect to socket /tmp/dbus-J7a32Qk1nk: No such file or directory` <damjan94>I want to open an issue on buttercup github page, but I'm unsure if this is me not knowing how appimages work, or if it's something related to guix shell. <Rutherther>it is related to guix not being an fhs, whereas the appimage assumes fhs <Rutherther>not really, because then you are in a container, so of course if the app expects something else from the outside and you don't give it to it, it won't work <Rutherther>since you seem to be trying to run it with ozone platform, you should also preserve WAYLAND_DISPLAY env var. Another thing I see is that you might be missing your dbus file, see what folder DBUS_SESSION_BUS_ADDRESS points to, and you should --share that folder as well <Rutherther>if that doesn't fix it, you would probably need to debug further. Or maybe someone else has an idea on what else could be missing <stochastic>> It seems like the initrd tries to unlock home before mounting root <stochastic>Yup, it tries to unlock the second drive before mounting the first <damjan94>that got rid of the dbus error, sweet. Now gotta figure out the `Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed` and `Passthrough is not supported, GL is egl, ANGLE is` errors. But I'll have to do those tonight. Thanks for your help, cheers :) <stochastic>> Yup, it tries to unlock the second drive before mounting the first <stochastic>The fix was to make the root file system depend only on the root cryptsetup invocation with the `(dependencies` field and the home file system with the home mapped devices <stochastic>that's one of those things that makes sense in hindsight <stochastic>especially since all mapped devices have to go in `(mapped-devices` <stochastic> (source (uuid "12345678-1234-abcd-1234-12345678abcd")) <stochastic> (source (uuid "00000000-0000-0000-0000-000000000000")) <PotentialUser-24>After I install a package, what would be the best way to get the /store path in which it was installed? I would like to lookup a name of a file it installs. <divya>PotentialUser-24: Do `guix locate package-name` <Rutherther>PotentialUser-24: the best way to get the path you actually have installed, is to look at the profile - "guix package --list-installed" <PotentialUser-24>Thank you. It works on a normal profile, but from inside a guix shell I am having trouble with it. <janneke>divya: did you mean `guix build <package-name>'? <janneke>PotentialUser-24: it would...but as it's already been built, it just gives the store file name <divya>janneke: Not really, but guix locate gives us the path where this package is used/stored? <Rutherther>PotentialUser-24: it does work on guix shell as well, just specify the profile with -p, specifically $GUIX_ENVIRONMENT is the profile <janneke>divya: nope, it shows the absolute file name of installed files <janneke>divya: try: guix locate coreutils, for examle (yes, it may "seem" to work for a package like bash ;) <divya>Ah, it's deceiving like that <janneke>dunno, it's the equivalent of plain locate, no? <divya>janneke: Thanks, that clears things up. But isn't guix build a roundabout way to get an installation path? <janneke>what you suggest might be a feature to have, dunno <divya>I didn't know guix locate is wrapped around the locate unix tool <Deltafire>i think the manual suggests guix build for this <janneke>divya: no, it isn't, but it mimicks the behavior, at least that's how i interpreted it <divya>Hmmm, I think there should be a better way to locate installation paths <gabber>is it normal that renew-certbot-certificates service creates a /etc/letsencrypt/live/DOMAIN-000N directory instead of populating /etc/letsencrypt/live/DOMAIN with the (symlinks to) the renewed certs? <PotentialUser-24>Rutherther I'm afraid I did not fully understand your suggestion. Add the argument -p $GUIX_ENVIRONMENT to what? <Rutherther>PotentialUser-24: to the command I suggested. guix package <gabber>gabber: no, it is not. i helped myself by deleting the whole /etc/letsencrypt and restarting the service, which sets it all up again correctly from scratch <gabber>gabber: this happens when re-rolling backups that copy files instead of symlinks <PotentialUser-24>I located the absolute path of the file I was looking for. I have updated the variable that needs to point to the file in Emacs and it works fine. But, after an update, the path could change. Is there a smart way to handle this? <Rutherther>PotentialUser-24: what variable are you talking about? <Rutherther>in general, it's much better to rely on search paths, like PATH in cases like this, so if you just install it, you can just look through path to locate it in your init el <Rutherther>if the jar file is not in bin folder and the path is not in any other search path, you could still make your own search path variable that will point to its folder, with a custom package you install <PotentialUser-24>Rutherther Indeed the jar is not in a bin folder. I'm afraid I don't follow the rest of what you said. I'm sorry, I'm still a noob. <PotentialUser-24>I could imagine that, as a last resort, I could call "guix build" and look for a jar under that path, in elisp, and set the variable to that. Or do what I just did every time I notice that calls to ditaa breaks. <PotentialUser-24>The bit about my own search path variable with a custom package is a bit over my head, I'm afraid. I'm sorry for the trouble. <mirai_>when you use a key-file in the initrd, is the key-file left unencrypted? (i.e. can someone else just come along and boot a liveCD and grab the key?) <Rutherther>mirai_: the key file is left in the gnu store. So if your store is encrypted, the key is encrypted. <mirai_>perhaps I'm misunderstanding how this works, but it says that its not stored in the store <PuercoPop>I'm trying to build guix from a checkout. In the past I `guix shell -D guix` would be enough to get everything I need to run `make` sucessfully. But this time its complaining it is not finding guile 3.0 <Rutherther>mirai_: right sorry. It's not stored in the store, it is stored in the encrypted drive, wherever <mirai_>I'm not aware of this initrd business but whatever's in it is it also encrypted? <mirai_>what prevents someone from coming along with a liveCD, booting it and copying the secrets to decrypt the drive? <mirai_>or is this all encrypted/password protected by grub <Rutherther>mirai_: what prevents that is that it resides on an encrypted partition <Rutherther>and no, the file itself is not encrypted, that would defeat the purpose, you would still have to enter password second time <potatoespotatoes> I'm running into an issue where a derivation for a cross-compiled gcc doesn't build, depending on which machine I build the derivation on <potatoespotatoes>i'm trying to build gcc-cross-sans-libc-aarch64-none-elf on an aarch64 machine <potatoespotatoes>gah! I am trying to dig up bootstrap.scm again to mention where the problem is, the main thing is that I'm getting 'dynamic linker name not known for this system "aarch64-elf"' but according to bootstrap.scm's global-dynamic-library(?) any system ending in "-elf" should be handled <potatoespotatoes>okay, sorry a more concrete question: How do I import %current-target-system in guix repl? <gabber>potatoespotatoes: i think this is defined in (guix utils) <Rutherther>but it's not so easy. It is usually parameterized during build, if the build is a cross compilation build <potatoespotatoes>okay, good to know, maybe I'll try to fiddle with this in a build script instead <potatoespotatoes>One more debugging question: If I am looking at a stack trace with a line that looks like 'In gnu/packages/bootstrap.scm:\n 339:11 1 (_)'. but line 339 is a comment, do I assume that the line numbers are an over-approximation and comments are being removed, or do I assume that my guix trunk is really out of date? <potatoespotatoes>I've run guix pull a few times since hitting this error, but it's possible that i'm missing something? <ieure>potatoespotatoes, It's been my experience that Guile stack traces are very rarely useful. <Rutherther>maybe the issue could be that the files are actually compiled and there is wrong mapping? I am not really sure though <ieure>potatoespotatoes, `guix describe' should tell you if your Guix is out of date. <ieure>Indirectly, anyway -- you can look up the commit and see how old it is. <potatoespotatoes>but I was just guix pulling and assuming that I would be using the pulled guix channel as the base for the derivation. Is that an incorrect assumption? I'm also on debian for this machine <potatoespotatoes>(guix pull say's I am only 66 commits out of date, guix describe says that I am on 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 ) <ieure>potatoespotatoes, Did you `hash -r' or log out / back in after your `guix pull'? If not, the shell's cache will point you to the old guix binary, instead of the one built during the pull. <ieure>Rutherther, They said they're on Debian. <potatoespotatoes>restarting has the same guix describe output, so I'm still pinned to 1.4.0. I'm assuming that guix describe needs to be on master for the update to actually be in effect, right? IIRC guix only maintains one trunk at a time <Rutherther>okay. Then you probably never source the profile <Rutherther>you should "source ~/.config/guix/current/etc/profile", with setting GUIX_PROFILE variable to $HOME/.config/guix/current prior to the source. This should usually be done in your shell's profile <Rutherther>and guix pull should even tell you that as a warning <potatoespotatoes>great! I switched from bash to zsh recently, so this makes total sense -- everything was working before and I must have forgotten to add those to the zshrc <gabber>potatoespotatoes: most of us are most of the time <gabber>that's why we thrive in helping each other out (: <gabber>do i have to take any special action in making fail2ban service work? i configured it (like in the official example) for "sshd", i reconfigured the system, the service is up and running - but that party that constantly tries logging into the machine from the same IP is not banned. <lilyp>ArneBab, efraim: that looks like native-comp-eln-load-path but no idea why it's circular <graywolf>Hello Guix! I am trying to built the html documentation locally and I am not sure how. I tried make doc/guix.html, which does build *something*, but it is not the single page documentation, and the links are not correct. <graywolf>Would anyone know what make target should I use for this? <graywolf>Hm, that does produce multiple language versions, but still with broken links. <janneke>graywolf: Are you working on a v2 for #73660? Now that there's a review comment we (i) will need to revert/remove your initial patch from core-packages-team but I'd be very happy to [re-]include v2 <janneke>i wonder where guix's htmlref.cnf is <graywolf>Sorry I was out with influenza for almost a week (yeey, today is day 2 with no fever), I will take a look likely tomorrow. <janneke>ah that figure, good that you're getting better <graywolf>janneke: Well, I "solved" that by `ln -s doc/htmlxref.cnf ./', but that is why I decided to ask what the correct process to build the html version is, because it seems like it should *not* be necessary step <graywolf>Should I just send v2 to the same bug? I assume it will just replace the v1 in the core-packages-team branch, correct? <janneke>i'll manually update core-packages-team (if civodul doesn't race me to it) <janneke>ah, there's doc/build.scm which is being used by the maintenance scripts <janneke>graywolf: so i guess: ./pre-inst-env guix build -f doc/build.scm <PotentialUser-24>When I run "guix shell package_A", and package_A depends on package_B, does package_B get added to PATH? <Rutherther>PotentialUser-24: usually not. But it could be a propagated input, and then it does <PotentialUser-24>plantuml depends on icedtea, but it says it could not find "java", despite icedtea being installed, just not on PATH. <Rutherther>I would consider that a bug. Applications should be wrapped so that the java doesn't have to be installed as well. As a workaround, just put icedtea to the shell as well <PotentialUser-24>Now, Emacs is getting quite confused with paths. Is that normal for Guix System? <PotentialUser-24>I started a shell with Emacs and emacs-plantuml-mode (that pulled in ditaa and other dependencies). <PotentialUser-24>But it was creating its output (image files) at ~/.config/emacs/.local/straight/repos/lsp-mode/docs/tutorials/images/reactjs/hello-world.png <PotentialUser-24>I was expecting it was created at ~/documents, the CWD when I called Emacs. <PotentialUser-24>I understand it may be reusing Emacs from my profile, but still... I have like 2 lines on my Emacs config! Nothing to justify lsp-mode or .config! <simendsjo>Any patchelf experts here? I have a couple of binaries which fails when patching both interpreter and libstd++.so.6 it seems. ldd crashes, and so does the binary. Could it be a bug in patchelf? Or something special about these binaries? <Rutherther>simendsjo: there definitely is a bug in patchelf, that's why 0.16 is still available in guix as well. But whether you are hitting that bug I can't say <simendsjo>Rutherther: Wow! I should have asked this question many, many, many hours ago! Thanks! 0.16 worked flawlessy. I got a lot of cleanup to do now. <ieure>graciousgnu, Ping me in ~2 hours if you havne't solved it by then. Mean time, I'd suggest reading the bit in the manual about debugging failed builds. <ieure>graciousgnu, This is happening during the `configure' build phase? Or after? <vhns>is there a recommended way to have XDG run-time directories being built/mounted? this is in a server scenario <vhns>I'm trying to configure my home with `guix home` but,as it's a server barebones install, there is no /run/user/ID/shepherd <vhns>I'll go with elogind for now, I guess <Rutherther>vhns: either elogind, or the greeter, or just manually, ie. in ~/.profile simple mkdir with 700 perms and set of XDG_RUNTIME_DIR. Though then you would probably have to change the guix home a bit since as far as I remember it assumes /run/user/$UID by default <vhns>I'll stick with elogind then, thanks <vhns>I don't think greeter is the fix here since it's only accessed through ssh and not a physical erminal <PotentialUser-24>About guix home... I saw is supports a service for log rotation. But isn't log rotation a service thing and guix home a user kind of thing? I do not see any overlap. Where am I wrong? <ieure>PotentialUser-24, Plenty of stuff you run as a user produces logs. Xorg is one example. <ieure>PotentialUser-24, $XDG_DATA_HOME, usually, which is ~/.local/share. <PotentialUser-24>And does log-rotate (I think that is the name) know about them or do you have to list the log files it should handle? <ieure>PotentialUser-24, I don't know. <PotentialUser-24>One more question: what she-bang should I use for a shell script to run on Guix System? <ieure>PotentialUser-24, `#!/bin/sh' or `#!/usr/bin/env bash', depending on what flavor of script you're writing. /usr/bin/env and /bin/sh are some of the only things Guix System puts in the FHS locations. <vhns>PotentialUser-24: #!/usr/bin/env PROGRAM <vhns>you can also use gexp or something and have the actual place for the program being written in your script <ieure>You definitely want to follow vhns' suggestion for other stuff, like executable Python scripts. <PotentialUser-24>"gexp" means "G-expression"? The guile thing I read about in some discussions and see in documentation? <ieure>Won't launch the GUI at all, just prints an error and exits. `emacs -nw' comes up, but puts the error in *Messages*, and doesn't load my init.el. <ieure>Also, weirdly, `default-directory' in *Messages* is /tmp/guix-build-emacs-29.4.drv-0/src/ <TheWalkingDad>ieure: I'm not an expert but I have (sort of) migrated my emacs setup from nix to guix (guix running on NixOS (for now), but I don't think it should matter), let me try to do a guix pull and see if I'm affected aswell <ieure>TheWalkingDad, Thank you, much appreciated! <TheWalkingDad>ieure: it looks like it's working fine on my end (although I only use emacs in a terminal).