IRC channel logs


back to list of logs

<rekado>Sleep_Walker: you can generate /etc/guix/channels.scm in the system config
<luke-jr>do I really need to ptrace guix and pause it after tar completes just to hook post-unpack? -.-
<wone>podiki: thank you
<wone>i'll try testing it out today. i really need to learn enough vulkan/c/shadertech to write a hot pixels module for vkdt, and then i'd be able to basically get rid of dt/ansel
<luke-jr>where is the actual loop through the build phases implemented?
<mirai>(guix build …)
<sneek>Yey! nckx is back
<wone>Does your copy of ansel have opencl support, podiki?
<wone>Tried repackaging with some goofy habits that I didn't fully understand. I was uncertain if "inherit darktable" would bring in the phase modifications that are used for making opencl available.
<wone>No dice, though.
<rekado>luke-jr: in the build system code, see gnu-build in guix/build-system/gnu.scm
<janneke>hello #guix!
<lrustand>I'm having trouble doing my first ever guix system reconfigure. I have just added a few packages, no changes other than that. It fails when installing grub with: "Could not prepare Boot variable: No such file or directory" and "error: efibootmgr failed to register the boot entry: Input/output error.". I did not find anyone with this exact error online, only a similar one. Any suggestions on how to fix this?
<mothacehe>lrustand: i think i had a similar issue because there were no space left to create new efi boot entries
<lrustand>Yes, that was the similar error that I found online. But I have "No such file or directory" instead of "No space left on device". So I don't think it is the same problem
<lrustand>Also I have only two efi boot entries on my machine, and I believe there should be space for many more
<mothacehe>You could maybe try to invoke efibootmgr manually and see if you have the same error message
<lrustand>After reboot the previous boot entry is now gone and I am unable to boot back in. What is the easiest way to restore it?
<lrustand>I would normally just chroot into it from a live cd and reinstall grub, but I'm guessing this is not the way to do it on guix?
<bumble>if anyone here has powers to handle patch requests please facilitate this one which resolves the issue described this bug report
<bumble>for CJK users, the bug is very annoying and it would be great if it were resolved
<bumble>when using guix update or guix reconfigure the download bar animation generates hundreds of new lines of shell output noise for the loading bar
<lrustand>mothacehe: I invoked efibootmgr manually and had the same error, but grub-install was succesfull if I added "--no-nvram"
<mothacehe>what version of efibootmgr is that? according to version 17 fixed a similar issue
<lrustand>I would guess it is the latest? I installed guix today, and also did a guix pull before doing reconfigure
<lrustand>It is slightly inconvenient for me to check, because every time I switch inputs on my KVM I need to reboot Guix to get display output again
<lrustand>On a different note, how can I make xrandr recognize my display output? Right now it just shows Screen 0, but there are no actual outputs there so I can't configure my resolution.
<lrustand>On a normal machine it would show a list of DP-1, DP-2 etc
<Argyro>Hello, i run Guix on top of opensuse and the qt applications installed with guix aren't themed properly. I use the Kvantum thingy for QT app theming, works with applications installed "natively" through zypper. Any ideas/suggestions on how to fix this?
<iyzsong>Argyro: you can try 'guix shell qtbase@5 kvantum -- foo', or 'guix install qtbase@5 and kvantum' (which set QT_PLUGIN_PATH for guix packages, but may break your host applicatinos).
<Sleep_Walker>rekado: that is rather easy, yes, but with that file I still can't use definitions in the system configuration itself, right? oh, you mean that I can ensure that this file always exists for each execution? My common use is `guix system build` && `guix system init` - on different distribution and `guix reconfigure` on GuixSD when I'm happy with the result - so if the file exists in different distribution and in GuixSD, I can use the
<Sleep_Walker>definitions in system configuration?
<rekado>Sleep_Walker: as long as you ran “guix pull” with a channel file in place you can refer to definitions provided by these channels in your system configuration.
<Sleep_Walker>excellent, thank you for confirmation!
<Sleep_Walker>Will this ever be single file configuration? It seems that to me a bit like chicken-egg problem and I'm curious :)
<jpoiret>it's not really chicken-egg: the channels.scm file has to exist before pulling
<jpoiret>I agree that single file configuration here is more of a "mindset" than a guarantee, esp. if you're using channels
<jpoiret>and if you have user profiles you also need a separate file
<Argyro>iyzsong: Thx that worked. :)
<minima>hi, i've created a small test.scm example file inside a guix checkout; i then do `guix shell --container --link-profile --development guix'; then `./configure && make' (and `make authenticate' too at some point in the process); then `./pre-inst-env guix build -f test.scm'
<bilke>Hi guix-people,
<bilke>at the end of a `guix pack`-command (the package was successfully built) I almost always get the following error:
<bilke>updating substitutes from ''... 0.0%
<bilke>guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.
<bilke>guix pack: error: `/usr/bin/guix substitute' died unexpectedly
<bilke>What does it mean? I get this on multiple machines.
<minima>i get an error that says: failed to connect to `/usr/local/var/guix/daemon-socket/socket'
<civodul>oh oh! <- cbaines \o/
<civodul>minima: hi! if you’re building from source, make sure to pass --localstatedir=/var:
<jpoiret>lechner: did you intentionally post your phone number to a public mailing list??
<minima>civodul: ah super, thanks!!
<jpoiret>minima: and --sysconfdir=/etc as well
<minima>cool, jpoiret, ty!
<civodul>bilke: hi! it looks like you’re using the ‘guix’ package provided by the distro, right/
<civodul>which version is it?
<bilke>civodul: Ah, that might the right direction... I am checking...
<cbaines>civodul, yep, unfortunately there's not a more general talk about Guix, so I think I'm going to have to try and fit that and some QA stuff in to 25 minutes :)
<jpoiret>bilke: you should be able to do `/usr/bin/guix describe`
<civodul>cbaines: heh, too bad there’s no other talk!
<civodul>since it’s a specialized conference, you can hopefully squeeze the Guix intro somewhat
<bilke>$ /usr/bin/guix describe
<bilke>guix describe: error: failed to determine origin
<bilke>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.3.0.
<bilke>I currently running sudo -i guix pull ...
<bilke>as descibed here:
<civodul>bilke: but since the initial Guix was installed with the other distro, you’ll need to adjust the guix-daemon startup file (systemd) so that it refers to the pulled Guix instead of /usr/bin/guix
<civodul>hmm i feel like i’m not being super clear
<bilke>No I fully got it.
<bilke>Thanks! Will try..
<bilke>civodul: So I ran guix pull, so you mean I shall update my guix-daemon to use e.g. `/gnu/store/xz8czw7r790yb6fwv3gm564zzlrg2x03-guix-command` instead of `/usr/bin/guix`, right?
<bilke>I guess it must be e.g. `/gnu/store/kv6qyi6c4f8p0k5qig8jbj13m20dvvbd-guix-daemon`
<jpoiret>bilke: usually on foreign distros you would also guix pull as root (so that the daemon always comes from a "root-vetted" source), and you would use /var/guix/profiles/per-user/root/current-guix/bin/guix as the guix executable
<jpoiret>you could also consider using your user's guix instead, to avoid `guix pull`ing as root to update the daemon
<jpoiret>don't use the full store path as that would require you to change it each time you want to update
<bilke>jpoiret: Ah thanks, I was not aware of /var/guix/profiles/per-user/... Yes will use those profile paths.
<graywolf>Is a script for automated guix installation considered a derivative work, even if it just calls the guix cli commands?
<graywolf>I would hope not? But want to make sure.
<civodul>cbaines: i killed ‘guix gc’ on bayfront; it had been running for ~2h and i needed a web site update
<attila_lendvai>there's no netperf for guix? is that because of the licence? i thought it's some base utility
<attila_lendvai>ACTION attempts a 5 min packaging
<civodul>cbaines: there’s no ‘guix gc’ process running, yet “waiting for the build lock”
<civodul>so i’m restarting guix-daemon
<nckx>attila_lendvai: I'd never heard of netperf, so definitely not a base utility.
<attila_lendvai>ACTION wants to use flent (that depends on netperf) to measure the
<attila_lendvai>and then set up an upstream bandwidth limit, which will probably mean more packaging... :/
<nckx>‘Yaay.’ (for us.)
<civodul>hey! happy to announce the Guix-HPC workshop program!
<nckx>That's awesome.
<civodul>i think so!
<civodul>known names among the speakers, too
<nckx>ACTION wonders what jpoiret does by night…
<nckx>(Please, keep it a mystery.)
<attila_lendvai>so, the last tag of netperf is from 2015. shall i package a recent commit instead?
<attila_lendvai>ACTION goes with the latest
<nckx>attila_lendvai: I'd say so:
<nckx>(Despite the date/version there, makes me suspicious: it's not in 2.7.0.)
<attila_lendvai>it's such an old tag that i think regardless of anything we should go with the latest
<attila_lendvai>not even the latest commit has a --version... :/
<lrustand>Guix system reconfigure hangs after "guix system: bootloader successfully installed on '(/boot/efi)'"
<lrustand>It just hangs there forever, but it doesn't seem to be doing anything. Checked in htop and it uses no resources, and there are no child processes either
<lrustand>Also, it somehow killed ssh, so I am not able to open new connections to the machine, but the one I already had open still works. Also nmap still shows port 22 as open on the machine
<lrustand>Tried increasing the verbosity of guix system reconfigure, but there are no additional messages
<lrustand>I was able to do reconfigure without problem, then I made some seemingly unrelated edits and then the problem came. I have since reverted back to the version of my config file that previously worked, but the problem still exists
<cbaines>civodul, ok, no problem
<cbaines>I assume the website update has happened, so I've got the GC going again now
<civodul>cbaines: yes, it’s done; thanks!
<civodul>GC apparently ran early this morning, so i wonder whether it failed to free enough space or something
<cbaines>civodul, GC isn't particularly quick on bayfront, and in this case it was attempting to free quite a bit of space (as I've changed the configuration to try and reduce the store size)
<ekaitz>efraim: you are a protonmail user, right? do you have the bridge packaged for guix?
<Altadil>ekaitz: I don’t know if that’s ok for your needs, but I can confirm the flatpak version of the bridge works fine on guix.
<ekaitz>Altadil: thanks for the info (i don't like flatpak though :))
<civodul>looks like every packaging-related conference decided to publish its program today, uh
<attila_lendvai>i'd like to try wondershaper. there's a pending patch all the way back from 2021:
<nckx>Anybody using Guix with 256 MiB of RAM?
<attila_lendvai>what's the guix-y way to have an ifup script? i'd like to run a tc command to limit the bandwidth whenever a network interface comes up. it's managed by network-manager.
<peterpolidoro>is there any way for a guix package to set command line options when running an executable created in that package? would it need to generate a shell script or something that would get run to call the executable with command line options set? I assume there is no way for a package to create something like an alias
<attila_lendvai>peterpolidoro, wrappers may help you, but they are mostly used to set env variables
<attila_lendvai>peterpolidoro, grap for wrap-executable to see examples
<attila_lendvai>FTR, here's how to set traffic control with network manager: nmcli connection modify 'Wired connection 1' tc.qdiscs 'root tbf rate 2000000 burst 512000 latency 50000'
<peterpolidoro>oh interesting, thanks. The problem I am having is that a package binary does not have an environment variable that I would like the package to set. It instead expects a command line argument. I want to pass the profile path to the executable with a search path environment variable. I would either need to modify the executable source to read that
<peterpolidoro>environment variable or pass that environment variable in as a command line argument when running the executable
<podiki>wone: I haven't tried ansel but I do have opencl in darktable
<attila_lendvai>peterpolidoro, unfortunately, a quick look at define.*wrap-program suggests that it's only for setting env vars
<peterpolidoro>maybe modifying the source code is the cleanest option
<lnnk>Did trisquel change its gnome look in the past week ? I reinstalled gnome and it looks different? Note I did not use any configfile I just installed through net installer. Can anyone please explain it?
<peterpolidoro>I am trying to package plugins for an executable and each plugin path would need to be passed as a command line argument when running the executable. that could get messy with lots of plugins installed. it would be great if the executable could just find those automatically
<peterpolidoro>the executable is looking in the package path for the installed plugins, not the profile path. I would need to trick the executable into looking at the profile path instead
<avalenn-42>Hello, I am trying to package libvarlink which uses meson as a build and it fails with a "Program or command '/bin/sh' not found or not executable" error
<avalenn-42>the /bin/sh is used at
<nckx>substitute* lib/ to use (which "sh") rather than /bin/sh.
<avalenn-42>We don't have /bin/sh in build containers ?
<nckx>Or even better, if Meson supports it: (substitute* "lib/" (("/bin/sh") "sh") — if that works, this could be fixed upstream.
<nckx>avalenn-42: No.
<avalenn-42>As we have it in "guix shell -C", I thought build containers were the same. I stand corrected.
<avalenn-42>I will need to find the exact invocation of modify-phase to use but no I know. Thanks nckx
<nckx>(arguments (list #:phases #~(modify-phases %standard-phases (add-after 'unpack 'patch-/bin/sh (lambda _ (substitute* "lib/" (("/bin/sh") "sh"))))) should work. Just add newlines™.
<nckx>*should work if Meson respects PATH. Otherwise, "sh" → (which "sh").
<minima>do i still use `./configure --localstatedir=/var --sysconfdir=/etc' as indicated here when running in a container? i use `guix shell --container --link-profile --development guix help2man git strace inetutils guix' instead of `--pure'
<minima>is the expectation of using a container here legitimate in the first place
<avalenn-42>Thanks nckx, it just worked. even without newlines ;-)
<nckx>minima: Do you mean the expectation that building in a container would change standard directories? No, they are hard-coded by design. (
<nckx>Yes, the standard *defaults* aren't the standard *system locations*, it's annoying, but GNU-wide.
<nckx>That said, enough people think that being non-compliant would be an improvement, so if you started a crusade you might win (within the Guix project, that is).
<civodul>nckx: yeah maybe we should just do that, after all
<civodul>(says the guy who’s been blocking the change :-))
<minima>nckx: thanks!
<minima>hm, i still get this error where i try to build something in a container and it says "guix build: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory"
<minima>where "something" is a scheme file within a guix repo checkout
<minima>and the "container" is what i get with `guix shell --container --link-profile --development guix ...'
<minima>i made sure the repo was "initialised" with `./configure --localstatedir=/var --sysconfdir=/etc' as per the docs
<minima>could it be a matter of restarting my machine?
<bost>Hi. Does anybody know why 'guile -c' and 'guix repl' produce different result?
<bost>code='(use-modules (gnu packages) (guix packages)) (format #t "~a\n" (package-version (car (find-packages-by-name "linux-libre"))))'
<bost>guile -c "${code}" # returns 6.4.11
<bost>echo ${code} | guix repl # returns 6.4.14
<attila_lendvai>bost, guile -C runs based on your local checkout (?), while guix repl is running the latest you have guix pull'ed into your profile
<bost>attila_lendvai: hmmm, your explanation makes no sense to me. In the working directory I have no local checkout.
<unmatched-paren>afternoon, guix :)
<bumble>今日は guix!
<nckx>An afternoon Guix would taste lovely.
<nckx>bost, attila_lendvai: s/based on your local checkout/the ‘guix’ package providing Guix modules in your GUILE_LOAD_PATH — usually the system profile at /run/current-system/profile. That's why it's older.
<nckx>If you change the GUILE_LOAD_ paths to point to ~/.config/guix/current — voilà, identical versions.
<nckx>Put differently: this isn't ‘Guix weirdness’ per se, it's the environment, because we chose not to construct $PATH and $GUILE_LOAD*_PATH the same way. You could do so. I don't know what the drawbacks/gotchas are.
<bost>nckx: eeeee but if I run this then I get the same paths:
<bost>code='(format #t "~a\n" (getenv "GUILE_LOAD_PATH"))'
<bost>guile -c "${code}"
<bost>echo ${code} | guix repl
<bost>and I also checked the GUILE_LOAD_COMPILED_PATH and PATH variables.
<bost>nckx: oh wait please... there's some difference in my shell setup(s).
<nckx>You've lost me with the getenv. Try (pk %load-path).
<nckx>I never said that ‘guix repl’ setenvs GUILE_LOAD_PATH.
<nckx>You can set GUILE_LOAD_COMPILED_PATH to *emulate* ‘guix repl’'s customisations in a ‘naked’ guile REPL. That doesn't mean that this is how ‘guix repl’ is implemented (it's not).
<ekaitz>hi, is anyone using arm-none-eabi-toolchain with C++ projects?
<ekaitz>I'm having issues to build simple programs
<ekaitz>I found a message in the ML by rekado
<ekaitz>I have a similar issue now, but I'm working on a guix shell
<ekaitz>my exact problem is `include_next<stdlib.h>` doesn't resolve
<ekaitz>even if CROSS_C_INCLUDE_PATH is properly set in my shell
<roptat>hi guix!
<civodul>hello roptat!
<bumble>roptat: hola!
<bost>nckx: Ah! (pk %load-path) shows different values. (getenv "GUILE_LOAD_PATH") is the same in both cases. Thanks for your help!
<nckx>When guile starts, it sets %load-path based on (getenv "GUILE_LOAD_PATH"). ‘guix repl’ makes modifications to %load-path. It doesn't keep GUILE_LOAD_PATH in sync because why would it, it's never used again.
<nckx>I think that's as clear as I get. :)
<podiki>hi guix
<podiki>i want to read the big devel thread that's ongoing, but I keep putting it off and each time I do it seems to grow exponentially...
<ngz>Hi Guix!
<atuin>I have defined a couple of channels, but when running guix repl they are not part of the guix-module-union, is that expected?
<attila_lendvai>atuin, did you guix pull, too?
<atuin>I have them in the /gnu/store indeed
<atuin>but they are not in %load-path when i run guix repl
<atuin>they are there: /gnu/store/gz0dywbndsag99zwv1vy7llc9lg7vc3r-atuin-guix listed in channels.scm
<atuin>when using guix repl I can see that (current-channels) has all of them
<nckx>ACTION stumbles upon
<atuin>(manifest-entry-item (cadr (current-profile-entries))) <- that povides the entry in the store, not sure if that's how I am supposed to add to %load-path
<lilyp>hey, is our mumi patch-set thingy broken?
<attila_lendvai>if i use tar --gzip from a system service, then tar will (try to) call gzip from the current PATH, right? it fails for me in the service, but the same works from the terminal.
<jbnote>Hi, has anyone experience setting up NFS diskless GuixSD clients from a GuixSD host server? From what i'm reading it should "just work" by exporting the root of the server over NFS, but i'm weary that /var/run and /run are going to be shared across all clients. Am I missing some magic happening during init that is going to localize these directory
<jbnote>for each client?
<jbnote>i'm wary of course ;)
<lilyp>looking at mount, it doesn't appear as though those directories are set up to be tmpfs or anything else
<lilyp>though you should be able to set them up as such
<jbnote>okay, i'll try to set them up as tmpfs on the host first then.
<reily>Would it be possible for someone here to look at the patch for It is a minor bug in a format string producing configuration for wireguard-service.
<attila_lendvai>it looks straightforward
<Altadil>Hi, I have a noob question: I’m trying to make a package. Currently, it fails during the install phase, because it tries to create /usr (and of course gets a permission error). I guess that’s because it cannot see the filesystem, being in the build environment. Is there any doc on how to handle this situation ? I’m not even sure of what to do, let alone how. ^^
<nckx>Hi Altadil. All Guix packages install *only* to /gnu/store/${hash}-name-version. You'll want to set that as the ‘prefix’ instead of your package's default /usr. How that's done depends entirely on the build system. Can you share your package?
<reily>Altadil: In the build environment, the gexp `output` should refer to the output of the package. So if your package's configure script accepts an install location as an argument, you could provide something like `(string-append #$output "/bin")`.
<Altadil>Here is the package so far:
<Altadil>thanks for your help !
<Wurt>Altadil: You should alter the `arguments' slot on the package definition. See for example the lightdm-gtk-greeter definition on gnu/packages/display-managers.scm. You should also check the sections 9.2.1 and 9.5.
<nckx>Altadil: Import (guix gexp) and add a make flag:
<Altadil>Wurt: reily: nckx: Thanks everyone! I feel like I’m finally starting to make sense of all this, and that’s all thanks to you! You rock. :)
<nckx>Good night, Guix.
<vagrantc>guix good night --help
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, nckx says: It is cached. ‘guix time-machine --commit=abcd…’ should be almost instant after the first invocation, even if the subcommand changes.
<vagrantc>it is cached, but certainly not instant ... at least not on slow machines ... seems it still has to calculate weather it matches what is cached?
<graywolf>How does guix time-machine with --commit works when I have multiple channels? What channels are searched for the commit?
<apteryx>it's always the default one, 'guix'
<graywolf>I see, so for time-machining other channels I need to use the -C argument.