IRC channel logs


back to list of logs

<festerdam>Shouldn't the guix downloads page give instructions on how to verify the provided signatures?
<mange>The instructions are in the manual: "(guix) Binary Installation" point 1, and "(guix) USB Stick and DVD Installation".
<festerdam>mange: Maybe one should directly link those chapters in the downloads page. I think it would be a bigger encouragement to verify the signatures. It also doens't cover the qemu image (despite the steps being about the same).
<Aurora_v_kosmose>Has Guix any offline mode of sorts?
<Aurora_v_kosmose>I know it didn't last I checked but that was over a year ago.
<mange>What do you mean by "offline mode"?
<Aurora_v_kosmose>Similarly to apt-cache, save that in this case I'd be more interested in the build dependencies for everything rather than the built substitutes.
<AwesomeAdam54321>Aurora_v_kosmose: `guix build --sources $PACKAGE` downloads all the source code needed to build the package offline
<Aurora_v_kosmose>Noted. How would you suggest proceeding for transfer to another non-networked machine?
<mange>There's also Guix archive which is documented in the manual: "(guix) Invoking guix archive". It lets you package up packages/profiles and move them between machines.
<Aurora_v_kosmose>(Let's assume thumbdrives are an option)
<Aurora_v_kosmose>Ah. Neat.
<mange>In principle you could use "guix system build" to build a system, and "guix archive" to package it for another machine, but I can't see a way to directly instantiate that operating system on the other machine. You might also need to include the current Guix version in the archive to run a reconfigure.
<Aurora_v_kosmose>Would you need to use the names of the source packages so that guix archive exports them as sources or is --sources compatible with it?
<mange>Looks like --sources is only for build, but it outputs the names to stdout so you can hook them up. Also, I think you need --sources=transitive to get everything. I think this might work? guix archive $(guix build --sources=transitive $package ...)
<Aurora_v_kosmose>Definitely going to try that as I finally get my systems back up.
<mange>I've never tried it, so I'm not certain it will all work properly, but it seems at least plausible.
<adanska>Hi Guix!
<futurile>heya adanska - heya all
<efraim>o/ everyone!
<spnjorfz>Hi, I want to start using Guix System and I was wondering, is there a way to declaratively define disk partitioning, like Disko on NixOS? I looked for it but I couldn't find much info
<wingo>good morning :)
<wingo>i wonder, how do i get screen sharing to work on wayland + gnome? install a pipewire service somehow?
<wingo>or do i just install pipewire package
<wingo>removing pulseaudio, i guess?
<Altadil>wingo: There is a home service for pipewire, but I don’t know if it sets anything for screen sharing. ^^
<wingo>ACTION should read up about home services...
<rekado>spnjorfz: no, there is no way to declare the disk partitioning in the operating-system record.
<ayatsfer>hello :) Today's report: I've started to mix guix and git in the CLI, I just tried to do a guix checkout and guix by accident ....
<ayatsfer>- and guix fetch
<jpoiret>wingo: screensharing in what?
<jpoiret>it depends on the app you use
<dale>Is something funny going on with An awful lot seems to be failing.
<sneek>dale, you have 1 message!
<sneek>dale, nckx says:
<peanuts>"IRC channel logs"
<jpoiret>apteryx: we'll probably revert the pkgconf patches and keep them for after the merge.
<jpoiret>it'd be good to organized a concerted effort to also remove all the propagated-inputs from everywhere in that case.
<jpoiret>ayatsfer: happens to the best of us
<jpoiret>guix/git pull doesn't help
<civodul>📢 hear hear! there’s a security patch that could use some more review and testing here:
<peanuts>"[PATCH security] daemon: Protect against FD escape when building fixed-output derivations (CVE-2024-27297)."
<civodul>the goal is to push it by the end of the day, the problem being serious enough
<fnat>Hi jpoiret, I've been testing your patches as per Things seem to build correctly. I've created an image and I'm now testing it on a spare machine of mine.
<peanuts>"LUKS2 support in Guix"
<fnat>What would you suggest as cryptsetup options? `cryptsetup luksFormat --type luks2 /dev/XXX`? Would you still recommend to specify pbkdf2?
<jpoiret>fnat: if you use GRUB, don't use --type luks2 for now
<jpoiret>you'll be able to upgrade to luks2 in place once grub is updated to 2.12
<jpoiret>i didn't read the first message sorry 😝
<fnat>jpoiret: Yes, I'm testing 2.12. (Thanks to your patches!)
<jpoiret>yeah, pbkdf2 is still mandatory, because argon2 is not supported by grub
<jpoiret>so --type luks2 --pbkdf pbkdf2
<fnat>Nice, thank you, I'll make sure I specify the derivation function then. Cool, tx.
<jpoiret>what i'm mainly concerned with with those patchsets is archs other than x86_64
<fnat>Ah... I might not be super-helpful on that front, but let me do an end-to-end round with x86, then we see once I'm more familiar with the process.
<cdo256>Hey Guix, is there a flag that I can pass to guile/make to get build symbols and line numbers? At the moment the backtraces aren't providing the names and source line numbers of a lot of frames, making it tricky to debug.
<janneke>jpoiret: either `screen' is a new dependency for a bare-bones system on core-updates, or the recent merge broke the build; ideas?
<janneke>/tmp/guix-build-screen-4.9.1.drv-0/screen-4.9.1/process.c:6500:(.text+0xdcc): undefined reference to `crypt'
<rekado>this looks like the glibc change
<janneke>ah, maybe i didn't build bare-bones on core-updates-glibc-2.39
<janneke>apparently not, both screen is a dependency there, and fails too
<jpoiret>janneke: core-updates is the most up-to-date one
<jpoiret>i think screen is explicitely in the (packages ...) field of bare-bones
<jpoiret>in any case it's just a matter of adding libxcrypt to screen's inputs if screen does use it
<janneke>jpoiret: yes, thanks
<janneke>ACTION pushes fix
<andrewzhurov3>Is there a way for a package to extend output of another package? Say we have rust-1.75, could a new rust-1.75-with-wasm32-unknown-unknown take the files output of rust-1.75 and drop in some more files there? I guess `inherit` could be used to add more build-phases, but then, I think, rust would be built from scratch + that newly added build-phase.
<andrewzhurov3>Wondering whether it's possible to use the build output of a package as a kind of input to another one
<ekaitz>andrewzhurov3: you can make a new package that installs rust-1.75 and also installs other things
<ekaitz>andrewzhurov3: or you can extend rust, add your extra stuff as another input, and modify the phases to install your extra stuff too
<apteryx>(define-public autoconf autoconf-2.69) -> should we switch this to the latest on core-updates?
<civodul>apteryx: hi! i guess we can try
<civodul>though there’s again a potential for breakage, so perhaps we should have an autotools branch instead?
<apteryx>that'd be an expensive branch to build (world rebuild), no?
<apteryx>jpoiret: oh, are the .la files *newly* including -lzstd? I would have thought this was already the case
<apteryx>jpoiret: in any case the easiest would be to remove the .la files, like most distributions do
<andrewzhurov3>Ah, right, getting out file system of a package is as easy adding it as an input. Oh, me! Thx, @ekaitz
<ekaitz>andrewzhurov3: <3 give it a go and let me know if it works for you
<apteryx>jpoiret: for an example, see bf6db08118
<civodul>apteryx: yes, it’s expensive, but the alternative (lumping together many unrelated changes) may well be worse
<apteryx>jpoiret: confirmed that info: "libtool does not distinguish between static and dynamic linking, always passing the complete list of dependencies." c.f.:
<peanuts>"pkg-config - Wikipedia"
<jpoiret>apteryx: yes, I would've expected -lzstd to be there before too
<apteryx>jpoiret: in other words, I don't think the move to pkgconf is related to that; except if you've pruned some propagated libs that were (extraneously) needed by libtool
<jpoiret>apteryx: well, it was building before and now it's not
<apteryx>interesting. I'll check
<jpoiret>removing .la files would be welcome, as well as use-less propagated-inputs, but we're piling too many things onto c-u
<jpoiret>apart from the glibc locale fix, i could run the whole desktop.tmpl image
<jpoiret>I'm thinking we cut our losses for now, revert pkgconf and finish ironing out the rough edges of c-u before shipping it. We'll be able to focus on a pkgconf branch later on
<civodul>s/revert/branch before the change/ maybe?
<civodul>but yes, i think “we” should focus on getting it merged
<jpoiret>i would prefer a rebasing workflow for c-u, re-resolving the same merge conflicts is so annoying
<jpoiret>civodul: ah, that's a good idea
<apteryx>you can configure your git to remember merge conflicts resolution
<jpoiret>yeah, that's what I've done
<jpoiret>haven't got the chance to use it since i've enabled it though :p
<apteryx>jpoiret: what's the fastest path (package) to trigger the problem?
<apteryx>libblockdev ?
<jpoiret>civodul: did you see ?
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<jpoiret>apteryx: that's the first one i've encountered, yes
<jpoiret>even though it seems like a problem with kmod
<civodul>jpoiret: i hadn’t; what’s the context?
<jpoiret>but well, i think it's mostly about the interaction between pkg-config and libtool: kmod first gets resolved through pkg-config (correctly, without -lzstd added on), but the -lkmod then goes through libtool and adds the spurious header
<jpoiret>it's annoying that things processed by pkg-config end up being reprocessed
<jpoiret>civodul: the default locpath was never added through compute_locale_search_path if GUIX_LOCPATH wasn't set
<jpoiret>it would simply not touch the argz list, but then when actually finding the proper locale to use it would yet again default to _nl_default_locale_path. But now that we're also adding something to the path unconditionally, _nl_default_locale_path was never added to the path
<jpoiret>s/but then/later on in some other part of the code/
<jpoiret>an argz list (NULL, 0) is not invalid, just empty, so it didn't actually make sense to check if (*locale_path != NULL)
<civodul>jpoiret: oh, good catch! thanks for fixing it!
<civodul>let’s hope there’s no buffer overflow or anything like that that would require a world rebuild (i made one such mistake back in the day :-))
<jpoiret>civodul: we'll rewrite it in Rust™
<apteryx>jpoiret: on master, these are the references kept to zstd for kmod:
<peanuts>"debian Pastezone"
<apteryx>it's listed in Libs.private, which wouldn't be used by pkgconf unless queried with 'pkg-config --static'
<jpoiret>but i don't understand how it was working before
<apteryx>I don't currently understand how this works on master
<jpoiret>i've looked at the commit log
<jpoiret>and it was working before the pkgconf switch
<jpoiret>maybe there's another thing that magically propagated zstd for libblockdev before
<jpoiret>but none of the commits stand out
<apteryx>that should be shown by 'guix graph --path libblockdev zstd' on master, right? (propagation)
<apteryx>ah, but $ guix gc -R /gnu/store/6mq8d1krjm8dfwk8hlng4xhnw6hfcnyj-libblockdev-2.28 | grep zstd has it
<apteryx>yep, it was propagated somewhere earlier
<apteryx>on master has zstd in its RUNPATH, so it must have linked to it
<apteryx>I'd be interesting to find which package stopped propagating zstd that broke it; must be a change on my branch
<apteryx>I mean in my latest commits, since it was working before
<apteryx>my hunch is on 5fed33113e (gnu: eudev: Update to 3.2.14.), though zstd was added there rather than removed
<fnat>jpoiret: GRUB 2.12 patches successfully tested, although on x86 which might not be super helpful.
<fnat>I sent a note on the ML.
<fnat>What's the next most useful step? Testing them on some non-x86 machine?
<apteryx>jpoiret: ah, it could be pkgconf itself which does some optimizations to reduce overlinking, causing purely pkg-config built binaries to record (propagate) less stuff in their RUNPATH
<apteryx>so probably one of the lower level libraries no longer has zstd in its RUNPATH, which trips libtool
<peanuts>"GitHub - pkgconf/pkgconf at b6e04e2d47b4ca093632b9efde6303a137ea0634"
<ayatsfer>hello, there's this project called "tensorboard". Apparently they use bazel for the build, so is it possible to instead take a pre-built wheel from pypi and just patch it automatically?
<jpoiret>fnat: yes. The "Modernizing" one has to be refactored I think
<jpoiret>apteryx: ah, right!
<jpoiret>libblockdev probably won't be the only one to fall to this
<apteryx>there was 2 occurences thus far, testing building mpv (gtk land) and plasmatube (qt land)
<apteryx>nice thing is it's fixed at the root by removing the problematic .la files. For now we can copy the 'remove-libtool-archives' phase to where needed, such as for kmod here.
<apteryx>(I'd commit this already but I'm building guile on core-updates for reasons)
<gabber>this link (latest Guix System iso download) is broken
<gabber>how can i filter the ci to get a Guix System iso build?
<gabber>figured it out (spec:images system:x86_64-linux)
<gabber>unfortunately this yields the same link - which doesn't work
<ekaitz>efraim: m4 segfaults in riscv
<ekaitz>oh but only in some weird setup with qemu
<RavenJoad>Guixers that use Wayland, what do you use for key remapping? I want caps-lock to be escape or control on my laptop keyboard. Guix's keyboard-layout only applies to X, because Wayland does not have an xkb equivalent.
<podiki>RavenJoad: in hyprland at least you can specify some xkb options
<apteryx>we always configure LINUX_MODULE_DIRECTORY to be /run/booted-system/kernel/lib/modules, right?
<apteryx>is it useful to have it configurable via an environment variable rather than hard-coded at build time?
<apteryx>(kmod 32 allows selecting it at build time with --with-module-directory=)
<apteryx>all the setenv we use set it to that
<xd1le>RavenJoad, I actually haven't tried it on guix system yet, but interception-tools should be able to do this
<RavenJoad>podiki: I have heard good things about hyprland, and I may look at it in the future, but I am aiming for a desktop environment-agnostic way of doing this. I use Plasma normally, but want to use mahogany (StumpWM's wayland successor) when it is ready.
<RavenJoad>xd1le: I had not heard of that one. I'll add it to the list of keyd, kmonad, kbct, and evdevremapkeys. I'm just not sure which one makes the most sense for using with Guix System.
<podiki>xremap is a wayland key remapper to (and in guix)
<podiki>setting e.g. ctrl:nocaps should be possible in all compositors, not sure how they do it or if there is a compositor agnostic way to do ti
<podiki>anyway, have to run!
<xd1le>interception tools just uses evdev, so evdevremapkeys sounds like the same idea
<xd1le>kmonad looks cool! but I wish configuration language was haskell
<RavenJoad>podiki: I have "(keyboard-layout "us" #:options '("ctrl:nocaps"))" in my config, but it does not take effect in Wayland Plasma.
<RavenJoad>xd1le: Yeah. I just need to figure out which one makes the most sense. In a perfect world, I would not need to modify the operating-system definition all of my computers derive from to get this key-remapping in both X and Wayland, but I will settle for just getting Wayland key-remapping working first.
<xd1le>the ones that use evdev will work for both x and wayland (and also tty)
<xd1le>but I guess guix operating-system definition wouldn't have in-built support for these
<RavenJoad>Not having operating-system support for generic remapping is fine. I can write my own service-type to do what I want. My concern was for something like keyd, which runs a daemon and exposes a virtual keyboard, making sure that the DE actually picks up the virtual keyboard input /dev node, since things can get wonky on Guix.
<xd1le>yeah it's weird, you have to run the daemon with niceness -20 or something like that
<xd1le>I don't know if there is a wayland-specific way
<Gooberpatrol66>Does guix try to de-vendor git submodules into separate packages?
<podiki>RavenJoad: i know, I meant that option can be used in hyprland's configuration. what it does under the hood i don't know, but there is whatever xkb's successor in wayland that uses that? i don't know details. but yes would be good to have guix system config handle that too
<civodul>Gooberpatrol66: yes!
<Gooberpatrol66>civodul: do you have an example of a package that does that?
<civodul>not off the top of my head, but there should be plenty of them
<civodul>kind reminder: i’m looking for feedback on
<peanuts>"[PATCH security] daemon: Protect against FD escape when building fixed-output derivations (CVE-2024-27297)."
<rekado>apteryx: I think it's preferrable to have more feature branches. It's also easier to see new breakage when it's not all tangled up with unrelated changes.
<pranavats>Hello, is there a way to have packages for both 32bit and 64bit arch in a single guix container? I need gnu/stubs-32.h (from gcc-toolchain for i686-linux) in an otherwise amd64 `guix shell` container for cross-compilation.
<RavenJoad>Why does gcc-toolchain not include libstdc++ and libgcc_s? I need to access GCC's lib output to get them.
<pranavats>RavenJoad: You mean you need help with accessing the lib output? if you're using a manifest, you can use the expression `(,(@@ (gnu packages gcc) gcc) "lib") in a packages->manifest form.
<andrewzhurov3>@ekaitz adding rust as an input and copying its files into out worked fine. Managed to add wasm32 files as well. However, copied bin/rustc is a shell script with hard-coded absolute paths to the stuff in rust package. So rust-with-wasm32/bin/rustc would behave as rust/bin/rustc, not seeing the added wasm32.
<andrewzhurov3>Just FYI, in case you're curious.:)
<andrewzhurov3>Overriding sysroot of rustc by passing --sysroot ./path/to/sysroot works. However, wasm-pack does not respect it while performing wasm32 lookup, searching under the original path.
<andrewzhurov3>Will try to build rust with wasm32 from scratch. As well will try to patch hard-coded paths of rust-with-wasm32/bin/rustc to point to stuff under rust-with-wasm32. I bet the former should work, latter - no.
<apteryx>rekado: I agree; but I also weary about the build farm not coping with it (for world rebuilding changes) and/or producing lots of false positive failures making the results of questionable quality
<RavenJoad>pranavats: No, I figured that out with some Internet searching. I was wondering why gcc-toolchain does not include those libraries, and why I needed to resort to (list gcc "lib") to get them.
<vivien>Hello Guix! QA is failing to build the gnome-team merge requert with “no space left on device”:
<vivien>This is annoying, as I’m relying on it to discover new build failures.
<festerdam>How much memory does the Guix qemu image need? The virtual machine runs out of memory when I do guix pull and I gave it 2048 MiB as instructed in
<peanuts>"Running Guix in a VM (GNU Guix Reference Manual)"
<festerdam>It gets to 97.5 % memory usage, and if it doesn't freeze, guix fails saing that the build of /gnu/store/*-profile.drv failed. I imagine it happens due to it running out of memory.
<lispmacs[work]>hi, when booted up into the installer: if I do some things in the shell first, can I still launch the installer with some command?
<festerdam>Isn't the installer always running in tty1?
<lispmacs[work]>appears so
<attila_lendvai>civodul, any word on (the definitions in shepherd's support module are visible in service start GEXPs)
<attila_lendvai>did anyone try ? it's nREPL for guile... is it a better experience than geiser? or is it too young still?
<peanuts>"~abcdw/emacs-arei -
<old>attila_lendvai: have not tried it. but there was a prensentation by its author during Emacs Conf 2023
<attila_lendvai>ACTION really misses the slime experience from the CL universe
<vivien>Does guile-hoot work on guix? I get lots of errors about wrong bytecode version
<old>I think its killer feature is that you can interupt expression that hang indefinetely, which typically ends up in a kill buffer for Geiser
<ekaitz>andrewzhurov3: yeah, inheriting, adding some other sources and then building a modified version might work better
<rekado>vivien: you need the latest and greatest Guile, so better run it in an environment that doesn't have any other Guile load path set.
<vivien>(echo ",use (hoot compile)" ; echo "(compile 42)") | guix shell --container guile guile-hoot -- guile prints 42 (i.e. it’s the guile 'compile function, not hoot’s)
<podiki>civodul: thanks for pushing the security fix!
<podiki>we should reconfigure all our build machines and restart the daemon
<civodul>podiki: yup!
<civodul>i’m updating the ‘guix’ package right now
<civodul>(checking that it builds)
<civodul>podiki: what about this news entry?
<peanuts>"debian Pastezone"
<podiki>i have a nearly complete blog post, just need a few tweaks and details and will send for comment (a question or two)
<podiki>civodul: looks good but should specify that users need to restart guix-daemon or reboot, right?
<civodul>oh, right
<civodul>i added “herd restart guix-daemon”
<podiki>sure. though perhaps sudo for both reconfigure and herd if we want (though maybe making users think before they do a sudo is good)
<civodul>yes, ‘sudo’ to both
<civodul>had the same thought :-)
<podiki>on the security front, i wasn't sure if the hash checking worked the same as noted in the nix proof of concept. in our case prior to this fix would a fixed-output derivation that has been altered mean the store contents don't match the expected hash and this could be used as-is by other packages?
<vagrantc>oh fun. i hope that is easy to backport that security fix to guix 1.4.x :)
<podiki>in other words, does guix (the store database i guess) think all is good since the hash was checked prior to the store writing?
<podiki>vagrantc: now you know why i was asking about security updates to e.g. debian guix package :)
<vagrantc>heh. :)
<vagrantc>i'm in the middle of finally applying the patch for:
<peanuts>"guix-daemon.service and guix-publish.service use deprecated StandardError/StandardOutput features"
<vagrantc>only reported ~3 years ago, and submitted a trivial patch this past july :)
<vagrantc>this looks like the only guix daemon security fix since 1.4.x at least ...
<vagrantc>there were a couple others a while back...
<podiki>yeah I can't think of any guix daemon related updates in a while, though not usually on my radar
<vagrantc>and it applies without problems, yay!
<vagrantc>although, guix does not currently build in Debian unstable ... but this is a security update for stable...
<civodul>vagrantc: thank you for looking into it!!
<podiki>yes, thanks vagrantc!
<civodul>ACTION still running the test suite of the update ‘guix’ package, crossing fingers
<podiki>civodul: in searching for a lost discussion about fixed-output derivations (can't remember now, something about their use in guix on guix-devel) i found this message from you:
<peanuts>"Re: Can unprivileged users corrupt the store with bad tarballs?"
<podiki>which brings me back to the question of what happens once an altered derivation (in this security advisory) is in the store. does everything treat it as having the correct hash and will just use it seeing the derviation in the store?
<podiki>10 years later someone found a loophole!
<civodul>yes, if the derivation output is registered as “valid”, then the daemon does not question its validatity until you run ‘guix gc --verify’
<civodul>but at that point it’s too late because anything could have happened
<podiki>okay, that's what i thought
<civodul>initially i thought cluster setups with GUIX_DAEMON_SOCKET=guix:// were fine, but they’re not
<podiki>i guess we could all run a --verify now :)
<civodul>so of course the real risk if you’re building untrusted fixed-output derivations
<civodul>if you use only the ‘guix’ channel (say), you should be fine
<civodul>and if you’re the only user of your machine
<podiki>right. or at least there is a layer of review and public auditing
<podiki>but a random channel or a "hey, just do a guix build -f not-a-suspcious-file-at-all.scm" is more risky in general of course
<civodul>but the .scm file itself can do anything in the first place, unless you run it in a container or something
<podiki>thanks for the clarifications, was just adding some info to the blog post about what the danger is here
<vagrantc>what sort of tests does one do to verify that the patch is effective?
<podiki>i believe civodul did some traces to see that the copy/delete/write happens
<civodul>vagrantc: there’s a Nix PoC but i didn’t try to “translate” it
<podiki>we don't have a proof of concept for guix as far as I know, there is one for nix but written "in nix"
<peanuts>"FOD sandbox bypass - HackMD"
<podiki>i didn't look at the details but the basic idea is pretty simple/clever loophole: pass around a file descriptor via a unix socket
<civodul>so yes, we should test it, though i’m more concerned about copyFileRecursively being subtly broken than anything else (the actual fix is 2 lines in