IRC channel logs
2024-03-11.log
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). <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. <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 ...) <mange>I've never tried it, so I'm not certain it will all work properly, but it seems at least plausible. <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>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 .... <dale>Is something funny going on with qa.guix.gnu.org/patches? An awful lot seems to be failing. <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. <civodul>the goal is to push it by the end of the day, the problem being serious enough <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 <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 <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>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 <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 <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 <apteryx>you can configure your git to remember merge conflicts resolution <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? <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 :-)) <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>and it was working before the pkgconf switch <jpoiret>maybe there's another thing that magically propagated zstd for libblockdev before <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 libblockdev.so 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 <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>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>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>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 <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>not off the top of my head, but there should be plenty of them <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>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>This is annoying, as I’m relying on it to discover new build failures. <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? <old>attila_lendvai: have not tried it. but there was a prensentation by its author during Emacs Conf 2023 <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>i’m updating the ‘guix’ package right now <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? <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) <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>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>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!! <civodul>ACTION still running the test suite of the update ‘guix’ package, crossing fingers <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 <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" <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 build.cc)