IRC channel logs


back to list of logs

<peterpolidoro>if we contribute an update to a guix package, should we also try to build every dependent of that package to make sure that none break? or is that not necessary?
<johnjaye>i guess what i meant was how much of guix is about "let's get all these packages working" vs "let's do things in scheme"
<johnjaye>although technically i guess guile and guix are separate projects
<vagrantc>peterpolidoro: i believe that is standard practice, yes. guix refresh --list-dependent PACKAGE ... should give you a list of what to rebuild
<vagrantc>peterpolidoro: you'll also need that to figure out if it goes to master, staging (300+ ?) or core-updates (... a lot)
<vagrantc>peterpolidoro: more details in the manual
<peterpolidoro>will running make on the guix repository catch all of those broken packages automatically?
<peterpolidoro>or do I ned to run --list-dependent and check each result manually?
<vagrantc>no, running make will just build your local copy of guix ... you need to ./pre-inst-env guix build PACKAGE PACKAGE1..PACKAGEN
<vagrantc>johnjaye: in guix, guile is ..."just" an implementation detail.
<lechner>yeah, right!
<peterpolidoro>thanks vagrantc
<vagrantc>any suggestions ... vtk@7 inherits from vtk@9, and i struggle with adding my typical modify-phases to it ...
<vagrantc>peterpolidoro: read the contributing section in the manual for more information about how to set that up
<johnjaye>how do i verify the reconfigure and upgrade worked?
<johnjaye>it says something about term-console and user-homes services restarting
<vagrantc>reboot is the ultimate test that reconfigure worked :)
<johnjaye>i don't get you
<vagrantc>guix system reconfigure ?
<johnjaye>on debian i would look at dpkg -l for the version of some package like emacs or xorg to be upgraded
<vagrantc>guix system list-generations
<vagrantc>should list a new generation each time you run reconfigure (presuming you made any actual changes)
<johnjaye>it shows generation 1 several days ago. generation 2 now
<vagrantc>guix system describe ... tells you what generation you're currently running (although occasionally some processes aren't really fully changed until after a reboot)
<johnjaye>last one was 5.11.15 linux libre, now it is 5.17.12 linux libre
<vagrantc>sounds promising
<vagrantc>especially if you're currently running linux-libre 5.11.x
<johnjaye>guix install htop succeeded. i can run htop. that is very satisfying
<johnjaye>how do i tell the kernel version currently running?
<vagrantc>uname -a
<johnjaye>ah ok. yes it says 5.11
<peterpolidoro>I am trying to write a guix package for a python package and the build fails saying "ModuleNotFoundError: No module named 'SCons'". Including "scons" in either the native-inputs or propagated-inputs does not help
<johnjaye>well looks good. now i can enable sshd hopefully and do this from the other room
<peterpolidoro>it uses setuptools to build the python package, but I think the python package uses scons to build other software
<vagrantc>peterpolidoro: you picked a tricky one
<peterpolidoro>I am trying to package python-platformio
<peterpolidoro>but perhaps it is too advanced for me
<vagrantc>afraid i might not be savvy enough to help you further peterpolidoro
<johnjaye>oh sweet ssh is enabled already.
<johnjaye>curious. gcc doesn't exist. didn't it need to download that to build the system?
<vagrantc>it's not in your PATH, probably, but i bet you it's in /gnu/store somewhere :)
<johnjaye>it says i have 7.5 and 10.3
*johnjaye wonders why it's necessary to print these hashes everytime
<DynastyMic> /exit
<DynastyMic>wait wut?
<vagrantc>the /gnu/store/HASH-PACKAGE-VERSION thing is... pretty fundamental to how guix works
<johnjaye>well everything is marked by a hash sure. but it seems like a lot of space to print it constantly
<johnjaye>i think i will refer to these hashes by the first 4 digits
<KarlJoad>johnjaye: If you are inside Emacs, there is a minor-mode to shorten them.
<johnjaye>the gcc 7.5 is in /gnu/store/01b4*-gcc-7.5.0-lib/gcc for example
<johnjaye>ah i actually wanted /gnu/store/069a*-gcc-10.3.0/bin/gcc
<vagrantc>if you shorten it, you'll get something else.
<johnjaye>so do i need to change path or do i need to refer to it with that long name everytime i use it
<vagrantc>the full hash is actually intrinsic to how it works
<vagrantc>johnjaye: if you want to call gcc from your user's account, you can install gcc-toolchain in your profile
<vagrantc>e.g. guix install gcc-toolchain
<vagrantc>and it may or may not use the ones you found in the store
*vagrantc waves
<johnjaye>well... ok then
<peterpolidoro>do guix packages ever set environment variables or is that not allowed?
<mitchell>python sets PYTHON_PATH
<peterpolidoro>oh good point. looking up the python package definition shows me there is a setenv function
<apteryx>mitchell: you mean GUIX_PYTHONPATH :-)
<johnjaye>hrm. how do i set x11 forwarding on or off? config.scm?
<johnjaye>it says sshd is running but i didn't add a line to config.scm to do that
<KarlJoad>Yes, config.scm. There is an openssh-configuration field for X11 forwarding.
<johnjaye>ok. i'll have to read the manual i guess. but i see a bunch of files in /etc
<johnjaye>which traditionally is where you configure such things. like /etc/sshd_config
<KarlJoad>Correct. Many of those files in /etc are generated by Guix and should not be managed directly (if they even can).
***KE0VVT is now known as KE0VVT_he-him_21
***KE0VVT_he-him_21 is now known as KE0VVT_he-him_ov
***KE0VVT_he-him_ov is now known as Kolev_he-him_26
<johnjaye>ah well apparently x11 forwarding is the default. so that's good
<johnjaye>now that guix is installed and updated, i can read the manual.
<apteryx>is it possible to have /boot on a distinct partition on Guix System?
<apteryx>there doesn't seem to be documentation explaining how to achieve that
<apteryx>perhaps I just define an explicit mount point for /boot and the rest is taken care of automagically?
<mitchell> Here is my file-systems entry. To achieve this I created the directory structure i needed under /mnt, i.e. /mnt/gnu /mnt/home /mnt/boot/efi. Then i mounted each parition at the correct spot and followed the manual installation instructions
<mitchell>with herd start cow-store /mnt
<mitchell>and guix system init config.scm /mnt
<apteryx>OK, that's for an EFI system; I guess it works similarly for a distinct /boot on BIOS machine though, thanks!
<apteryx>I'll try it
<mitchell>yes its almost exactly the same for bios
<mitchell>just you the regular grub-bootloader instead of grub-efi-bootloader
<mitchell>and /mnt/boot instead of /mnt/boot/efi
<apteryx>my system is already running, so I'll just need to adapt my config.scm I think
<apteryx>(/boot is currently part of the root file system)
<mitchell>you need to mount the boot parition at /boot first
<apteryx>OK! ah, otherwise it won't write to it
<apteryx>makes sense
<mitchell>if you want it on a separate parition
<mitchell>Just when you go from the live cd you need to mount everything under<mitchell> Here is my file-systems entry. To
<mitchell> achieve this I created the directory structure i needed under /mnt,
<mitchell> i.e. /mnt/gnu /mnt/home /mnt/boot/efi. Then i mounted each parition
<mitchell> at the correct spot and followed the manual installation
<mitchell> instructions [20:58]
<mitchell><mitchell> with herd start cow-store /mnt
<mitchell><mitchell> and guix system init config.scm /mnt
<mitchell><apteryx> OK, that's for an EFI system; I guess it works similarly for a
<mitchell> distinct /boot on BIOS machine though, thanks! [20:59]
<mitchell><apteryx> I'll try it
<mitchell><mitchell> yes its almost exactly the same for bios
<apteryx>sneek: later tell mitchell from a live Guix System, I didn't need to premount /boot myself; 'guix system reconfigure' took care of it :-)
<sneek>Will do.
***LispyLights is now known as Aurora_v_kosmose
<KarlJoad>Is there a good way to programmatically get the Linux hash from the version defined in the guix package for it? Right now I must TOFU the hash.
<KarlJoad>Can Cuirass' remote build mechanism be run on the same machine? Meaning the remote-server and remote-worker are on the same computer.
<phodina[m]>Morning Guix,
<phodina[m]>can I ask how to properly replace this sexp with gexp? `(string-append (assoc-ref inputs "gcc:lib") "/lib"))`
<phodina[m]>I have it declared in the inputs like this: ``(,gcc "lib")`
<phodina[m]>s/``/` `/, s/`/\`/
<phodina[m]>s/``/` \`/, s/`/\`/
<phodina[m]>s/``/``` `/, s/`/\```/
<phodina[m]>s/``/``` `/, s/`/```/
<KarlJoad>I don't know the broader context, but I think you could just prefix the entire sexp with #~ to get a gexp.
<phodina[m]>KarlJoad: It's already prefixed with `#~`. The main point is to replace the `assoc-ref` as I have simplifed inputs and the code now does not unfortunately work
<KarlJoad>Shouldn't Guix handle evaluating the assoc-ref, not the builder?
<phodina[m]>Without simplified inputs the code works. But the change then breaks the code in modify-inputs
<phodina[m]>Okay, I formulated my question incorrectly.
<phodina[m]>I have this piece of code in the modify-phases `(string-append (assoc-ref inputs "gcc:lib")`. It works as long as I keep the inputs like this `("gcc:lib" ,gcc "lib")`. If I simplify them to ``` `(,gcc "lib")``` the code breaks. What to do to fix it?
<phodina[m]> * I have this piece of code in the modify-phases `(string-append (assoc-ref inputs "gcc:lib") "/lib")`. It works as long as I keep the inputs like this `("gcc:lib" ,gcc "lib")`. If I simplify them to `` `(,gcc "lib")`` the code breaks. What to do to fix it?
<phodina[m]>I've attempted to rewrite it like se `(string-append #$gcc "/lib")` though this does not work :-/
<KarlJoad>Ahhh... That is a new one for me. This feels like a weird issue due to the new way to define package inputs.
<johnjaye>unmatched-paren: by the way thanks again for the assistance.
<johnjaye>i literally had no idea what i was doing
<phodina[m]>Also is `pyproject.toml` by `python-build-system`?
<Aurora_v_kosmose>If only a single package needs a forked dependency of a project that is otherwise packaged (but incompatible due to work modifications), what's the typical way to define the fork so it's only accessible to the package that needs it?
<Aurora_v_kosmose>Let's say... Kaldi. Vosk needs vosk!kaldi and won't work with (normal!)Kaldi.
<vivien>Aurora_v_kosmose, can you make a package that inherits kaldi, and use that one instead of kaldi as an input?
<Aurora_v_kosmose>Inherit kaldi and add vosk!kaldi-specific modifications? Yes.
<vivien>I’m not sure what the character "!" means though.
<Aurora_v_kosmose>Ah, just consider that as "modified by".
<Aurora_v_kosmose>Basically, vosk-kaldi != kaldi, and vosk depends on vosk-kaldi.
<Aurora_v_kosmose>As for why users (or myself) would want vosk... it's basically the only FOSS fully offline speech-to-text library around.
<Aurora_v_kosmose>At least, one of the very few that's still maintained.
<Aurora_v_kosmose>Most "alternatives" I've found rely on SaaSS which is obviously not okay.
<phodina[m]><KarlJoad> "Ahhh... That is a new one for me..." <- I've figured that out `(string-append #$gcc:lib "/lib")`
<pmk>Hello guix! I have recently started using guix in a foreign distro (Arch Linux specifically), but there is some friction. For example programs installed with the distro's package manager pick up guix's libc which is a different version and this sometimes causes isuses. I am wondering if this is a somewhat common issue and if there are best practices with regards to this issue. One workaround I've found is to launch "native" programs
<pmk>from a terminal where the PATH variable does not contain any guix specific paths, but this is a bit annoying and error prone.
<nckx>Aurora_v_kosmose: If both packages are in the same file, use 'define' not to export v-k. Otherwise, use 'hidden-package' to hide it from the UI.
<abrenon>hey guix
<Aurora_v_kosmose>nckx: Alright. Thanks.
<nckx>Hi abrenon.
<abrenon>hi nckx
<abrenon>how are you ?
***w1gz_ is now known as w1gz
<ulfvonbelow>does our libglvnd work with egl? A program I'm trying to package is trying to access /gnu/store/sv6rr1i7b6jfknla4h68vbwj0bz8vn8m-libglvnd-1.3.4/etc/glvnd/egl_vendor.d and /gnu/store/sv6rr1i7b6jfknla4h68vbwj0bz8vn8m-libglvnd-1.3.4/share/glvnd/egl_vendor.d, neither of which exist, at which point eglGetDisplay() is returning EGL_NO_DISPLAY.
<jpoiret>pmk: do you have a specific example in mind, with a simple program? if so, can you do `LD_DEBUG=libs <program>`?
<jpoiret>I remember one person having this issue because the program they were launching was hijacking ld behaviour
<jpoiret>ulfvonbelow: looks like these folders are missing from our package, but that's for good reason I think
<jpoiret>from what i understand, these folders have ICD configuration files, to load the proprietary nvidia drivers
<jpoiret>the corresponding debian package is marked as non-free
<pmk>jpoiret: LD_DEBUG is pretty neat I did not know about it. Thanks!
<jpoiret>yes, it's pretty unknown but very useful!
<pmk>So here's the relevant output of `yay -S volt`:
<pmk>the readline library is installed "natively" as well.
<jpoiret>yes, i'm looking at fakeroot source to see if that may be the cause
<jpoiret>fakeroot hijacks default LD behaviour as well
<pmk>I see, makes sense actually. So I guess there are some programs for which this is unavoidable currently. The workaround I mentioned earlier (running these programs in an environment where PATH does not contain guix specific paths) seems to work for me.
<pmk>Thanks jpoiret!
<jpoiret>this is weird though
<jpoiret>the program somehow inherits the /etc/ of guix's bash
<jpoiret>pmk: does the bug occur before you input your password?
<pmk>No, it happens at the very end of execution.
<jpoiret>while building I assume?
<pmk>(of what a "normal" execution would be)
<pmk>yes, while building
<mothacehe>jpoiret: good job with the uvesafb fix! I like your wayland compositor idea to maybe get rid of kmscon. On aarch64 the problem would be that the install procedures are very hardware dependant though.
<jpoiret>right, although that wouldn't change compared to what we have now right? since we need kms either way
<jpoiret>or is kms not sufficient?
<mothacehe>we would probably need kms either way. however we could get rid of the dirty kmscon keymap update hack if the installer was started in a proper virtual terminal
<jpoiret>pmk: what I'm thinking of, is that fakeroot sets LD_PRELOAD and all child processes inherit it, then at some point `yay` calls `bash`, which is searched in your PATH and ends up loading Guix's one, but first injecting libfakeroot
<jpoiret>mothacehe: oh right, i never saw that, but it does look dirty
<jpoiret>although, if it is started in a vt on Wayland, we'd need to inform the compositor somehow
<mothacehe>anyone using gnus + gmail? looks the password based authentication is not supported anymore :(
<mothacehe>jpoiret: true, plus managing the vt would be quite tricky, if the user closes it in the middle of the install process for instance :)
<jpoiret>although you could prevent that with cage
<jpoiret>it's made for kiosks
<mothacehe>oh interesting!
<jpoiret>about gnus+gmail, apparently there was a change and apteryx set it up recently, let me find the logs
<jpoiret> it's perfect for that kind of use
<jpoiret>by the way, there's a typo in lookup-platform-by-target
<jpoiret>i'll send it now
<jpoiret>(the patch)
<mothacehe>fixed, thanks jpoiret & apteryx ;)
<jpoiret>just sent it
<ulfvonbelow>jpoiret: it seems the directories in question need to have ICDs to point to a vendor regardless of whether that vendor is nvidia or mesa. Some packages insist on using the libglvnd interface, and that will fail for egl unless an ICD is specified (fun fact, I have no idea what ICD even stands for because libglvnd's repository never documents that)
<jpoiret>installable client driver
<pmk>yes jpoiret. This sound plausible, and explains why not having guix paths in the environment seems to work. Thanks again for the help!
<mothacehe>oops, good catch
<mothacehe>there's also a platform issue pointed out my Ekaitz & maximed
<FriendFX>Hey Guix, how do I get the version of a package which is part of the system configuration? Specifically, I was wondering about the `thunar-volman` package, which I found at `/run/current-system/profile/bin/thunar-volman` (I am running XFCE). I am looking for something like `guix package --list-installed` but for system packages.
<ulfvonbelow>anyway, I tried setting __EGL_VENDOR_LIBRARY_FILENAMES=/tmp/makeitwork.json, but then I got /gnu/store/x7wl4qvw5fazdhv1df0x542ggkpcb9pw-mesa-21.3.2/lib/ error: symbol lookup error: undefined symbol: __egl_Main (fatal)
<ulfvonbelow>it seems mesa needs to be built with libglvnd support, but at least there doesn't appear to be a circular dependency.
<jpoiret>FriendFX: you can do `guix package -p /run/current-system/profile/ --list-installed`
<jpoiret>the system's profile is just like any other profile, although it's not mutable
<mothacehe>nckx: looks like the upgraded sudo package doesn't cross-compile anymore
<FriendFX>jpoiret: Thanks for the explanation about selecting a profile, but there's nothing in there about `thunar-volman`, or even just `thunar`... now I'm confused.
<ulfvonbelow>what's the highest /tmp/guix-build-<wip-package>.drv-N anybody here's ever reached?
<jpoiret>it's not installed in the profile then :(
<jpoiret>i suggest guix gc -R $(readlink -f /run/current-system/) | grep thunar then
<ulfvonbelow>I managed to get to 60 before getting a successful build of pcsx2
<jpoiret>FriendFX: or if you haven't guix pull'd since, you can just do `guix show thunar-volman`
<jpoiret>ulfvonbelow: right
<jpoiret>i don't think it would be that hard to add glvnd support, although it has to go through core-updates
<jpoiret>but maybe there needs to be a search-path or something similar to find the glvnd libraries
<jpoiret>mothacehe: i know it seems crazier, but i don't think we should raise an exception there
<jpoiret>rather, cross-libc should take a platform argument instead
<jpoiret>that would require a bunch of refactoring though
<mothacehe>agreed, ekaitz can just remove the "-unknown" part of the triplet to mitigate the issue for now
<jpoiret>i really don't like having %current-target-system as a parameter
<jpoiret>it's annoying
<jpoiret>and up until that aforementioned uvesafb patch, all the services in the install image couldn't match properly on the system iirc
<jpoiret>since the (define ...) was evaluated at top-level
<jpoiret>although maybe the parameter was already correctly set by then, who knows :)
<FriendFX>jpoiret: `guix show thunar-volman` worked... but what does this have to do with `guix pull`?
<jpoiret>FriendFX: if you reconfigure your system with, let's say, guix pull generation N, then thunar-volman will come from that generation, so you can just lookup the guix version of that package
<jpoiret>but if you reconfigured with guix pull generation N-1, then if thunar-volman got updated in between, maybe you'll still be running the old one compared to the one packaged in gen N
<FriendFX>Ah, I think I understand - if I pull and there's a newer version available than the one I've already got, it'll show the newer version instead of the installed one. In my case, they're the same, but it would (for that reason) to be good to know how to find out the _installed_ package version.
<jpoiret>the above `guix gc ` cmdline should give you the store path of the thunar used by the system
<jpoiret>which hopefully contains the version number
<jpoiret>another way should be to `guix time-machine --commit=<sha> -- guix show thunar` for the guix commit used for that generation
<jpoiret>you can find this by reading /run/current-system/provenance
<FriendFX>As you suggested, `guix gc -R $(readlink -f /run/current-system/) |grep thunar-volman` showed the path to the gnu store, which includes the version number... this feels a bit hackish, but what do I know :-)
<nckx>mothacehe: It doesn't build natively on aarch64 either, which is worse.
*civodul tries to merge master in core-updates
<ekaitz>mothacehe: thanks for noting that! I'll try without the -unknown and see if it works
<jpoiret>mothacehe: what's the difference between system and target by the way?
<nckx>jpoiret: Where?
<jpoiret>i meant in general, what distinguishes a system and a target field for a platform?
<jpoiret>are they just 1-to-1
<efraim>oh, I just came to comment about sudo not cross compiling
<efraim>to aarch64-linux
<nckx>jpoiret: Systems are ‘Nix systems’, I don't know if they are documented beyond the daemon code. Targets are GNU triplets.
<AwesomeAdam54321>jpoiret: A target is the target architecture for compilation, the system refers to the architecture of the host computer
<nckx>jpoiret: Now… is there a sane technical need for that? No, probably not :)
<ekaitz>mothacehe: I adjusted my code and realized (cross-binutils) works with the -unknown part but (cross-libc) doesn't, does that make sense?
<nckx>I've wondered what would happen if we just switched to using triplets everywhere, dropping Nix systems entirely.
<nckx>Apart from a flag day.
<littleme>triplets? i don't get the point
<kaelyn>So for fun before going back to bed, I just kicked off "./pre-inst-env guix refresh -r -u" for all of the packages in my system and home profiles. :)
<ulfvonbelow>looks like share/glvnd/egl_vendor.d would be the place to look, and __EGL_VENDOR_LIBRARY_DIRS would be the environment variable. Adding that search path to libglvnd and enabling glvnd support in mesa should be all it takes, I would think.
<nckx>littleme: Consistency. Low-level but constant user confusion here & on MLs. Etc.
***jesopo is now known as jess
<mothacehe>nckx: yeah i guess we could use triplets everywhere with an extra flag indicating if we are willing to cross-compile or to build natively.
<mothacehe>but that would imply a massive rework
<nckx>Hum, do we ever dispatch cross/non-cross builds based on how many hypens are in the name? :-/ I don't get it.
<nckx>*hyphens, even.
<nckx>Why would you not use unambiguous SYSTEM and/or TARGET parameters already?
<nckx>Regardless of the valid values, that sounds like a good idea.
<nckx>IOW, I was describing the first part but you lose me at why ‘an extra flag’ would be needed.
<Guest11>`guix pull` fails: guix is unable to "produce output path: /gnu/store/<hash>-guix-package-cache". what do i do now?
<Guest11>is it possible to figure out why that fails?
<nckx>It should print 'see this log file.gz' which you can cat with zcat or less with zless.
<nckx>That often helps.
*nckx AFX
<nckx>*AFK, FFS, but I have good taste in music too.
<jpoiret>nckx, mothacehe: Yeah, i think you could just parameterize the native-build inputs %current-target to be the native triplet instead of the target one
<Guest11>thanks! the incredibly short log-file (just 3 lines) mentions "unbound variable" python2-pygtk.  do i have to remove said package from all profiles to fix pulling? i don't think i installed that package (it doesn't show up in `guix package --list-installed`). btw i'm on a debian host
<jpoiret>are you using non-default channels?
<Guest11>i've tried adding one now, but i get the same error when i remove the channels.scm file
<Guest11>does that break `guix pull`?
<jpoiret>are you sure? I don't see python2-pygtk in the git repo, so it might be your channel
<jpoiret>the channel might be referring to python2-pygtk, but that has been removed
<Guest11>i'm re-running now (without the extra channel). i get the same error. and there is also the same message in the log.
<apteryx>anyone using a separate /boot partition with Guix System? I mean, it works, but it doesn't address having the initrd and kernel on /boot.
<jpoiret>Guest11: i'm building right now to see if i have the same issue
<civodul>apteryx: hey! why would you need the kernel and initrd on /boot?
<Guest11>jpoiret: TIA
<efraim>overdrive1 seems to be working ATM
<pmk>I am trying to create a container using `guix shell --container -m manifest.scm`, in order to compile a program. The manifest contains a number of dependencies using `specifications->manifest` and specifically `"gcc-toolchain"` and `"gcc-toolchain:debug"` are in the list. The container is created without issue, I can run cmake to configure the codebase but then compilation fails because `/usr` (and thus `/usr/include` does not exist.
<apteryx>civodul: I'm not sure, but I think I've pushed my BIOS to its limits, with a 2.5 TiB file system. GRUB complains "error: attempt to read or write outside of disk `proc'"
<jpoiret>Guest11: weird, it built for me
<jpoiret>pmk: the container is not FHS compatible
<Guest11>hrmpf. thanks anyways! any idea how i can resolve my quasi-broken guix state? should i pull a specific commit?
<jpoiret>if the build script assumes FHS, it won't work
<apteryx>the odd thing; it drops me to a rescue shell, and from there I can 'cryptomount -a', 'insmod normal', 'normal' and it successfully reach the GRUB menu (and boot normally thereafter)
<jpoiret>Guest11: i'm not sure it's a specific commit though
<jpoiret>unless you're using a specific commit
<Guest11>i don't think so either. does `guix pull` cache stuff? can i empty that cache or somehow force guix to pull from a clean slate
<pmk>Thanks jpoiret. The build script is CMakeLists.txt, but I am not using "cmake-build-system". I guess this might solve the issue, but I am not sure if it would be possible to do that in a container.
<jpoiret>i can't even find pygtk
<jpoiret>Guest11: `guix pull` only caches the git checkout
<jpoiret>and the successfully built derivations of course
*civodul merged master in core-updates \o/
<civodul>hope i didn't mess up resolving conflicts
<apteryx>thanks, civodul!
<civodul>next step: merging master in staging
<civodul>it's merge day here :-)
<jpoiret>pmk: I'm not a specialist wrt cmake-build-system differences to plain cmake, but it may be that some file paths are hardcoded in your CMakeLists.txt
<jpoiret>what are you trying to build?
<civodul>hopefully after that: merging staging into master!
<jpoiret>python2-pygtk was removed ~1 week ago Guest11
<Guest11>yeah, i didn't pull for like 8 days
<Guest11>so should i first pull an older commit and then try the current one?
<civodul>jpoiret, mothacehe: will you be available in the coming days/weeks for installer work? :-)
<apteryx>civodul: apparently on BIOS systems the kernel can't appear above the 2 TiB mark
<civodul>i think we have a couple of bugs to fix, plus we need to start a testing campaign
<mothacehe>civodul: yes, i'll try to find some time. I'd like to have a look to the parted 3.5 upgrade issue you reported
<jpoiret>yup, should have some time for it
<apteryx>which is why I'd like to have an option to say "copy all boot things to my boot partition" in Guix System
<civodul>apteryx: thing is, you can't really have the kernel on /boot
<mothacehe>so that we can ship with an up to date parted
<civodul>yay, that'd be great
<jpoiret>Guest11: no, it shouldn't matter, the guix derivations don't really care about your current guix (or they shouldn't at least)
<pmk>I am trying to build MonetDB:
<Guest11>jpoiret: mkay :) the more i understand the more weirder this feels
<jpoiret>pmk: seems that the Cmake list hardcodes the only possible location for headers
<pmk>for the record I have been able to build it in a pure environment with the same dependencies
<jpoiret>are you on a foreign distro?
<jpoiret>if so, you might've compiled with the foreign distro's headers
<jpoiret>Guest11: right, me too :)
<jpoiret>`guix pull` should be reproducible
<jpoiret>we're even on the same arch
<pmk>yes I am, that's what I think is happening :)
<Guest11>jpoiret: but i'm assuming you're running guix system?
<jpoiret>yes, but the guix builds should be isolated from your own distro even
<apteryx>civodul: why is that the kernel couldn't live on /boot? If I recall previous systems, setting a /boot partition would do just that.
<jpoiret>Guest11: can you find the folder for the guix checkout in ~/.cache/guix/checkouts/, and then run `grep -r . "python2-pygtk"` in it?
<avalenn>is there a way to declaratively chose the channels used by guix-home during for home-configuration packages ?
<jpoiret>you should only find something in the NEWS file
<jpoiret>avalenn: No
<jpoiret>well, for specific packages, you can use an inferior
<jpoiret>but in general no
<avalenn>Thank you. I will address this independently then.
<nckx>apteryx: That has never been handled by upstream Guix.
<nckx>apteryx: It can live there, but you have to put it there yourself.
<nckx>To boot bcachefs, say :)
<apteryx>nckx: do you have a recipe handy? Perhaps it could make it to the Cookbook
<apteryx>for what it's worth, I tried manually testing things by hacking my /boot/grub/grub.cfg by hand and copying everything needed for my first entry (adjusting paths to /boot/...), and it somehow wasn't used
<apteryx>this issue by vagrant requests such support, if I understand correctly:
<civodul>having a separate /boot partition is supported (there's an installation system test IIRC); however, having the kernel + initrd there is problematic
<civodul>first because if you want the ability to boot older generations, you basically need to copy the closures of those store items to /boot
<apteryx>yes, it'd need to be a subdirectory copy per menu entry. Not great, but doable.
<civodul>"closures of those items" is more than a subdirectory tho
<civodul>you'd need a subset of the store on /boot
<nckx>Adding /boot sounds wrong. From memory, because unfortunately I don't apteryx. There should be one in the maintenance repository for berlin IIRC?
<nckx>*Adding /boot to names in grub.cfg
<civodul>it's doable of course, but it's heavyweight
<apteryx>I thought these boot things (initrd and kernel, say) are self contained (statically linked)
<nckx>I think you have to remove the ‘search’ line too, or it will try to be clever.
<nckx>That's all I remember, sorry.
<civodul>they should be self-contained, yes
<nckx>civodul: All you need is the bzImage & initrd.
<apteryx>well, I still want my fancy background
<nckx>Two files per gen. GRUB keymap + splash if you want to get fancy.
<nckx>Yes :)
<nckx>I live without one like a pheasant.
<apteryx>doesn't it remind you of the blue screen of death on each boot?
<jpoiret>the artwork is useful for me: if i don't see it then my luks passphrase was wrong
<nckx>I have quite a few patches on my GRUB. It's not blue, for one.
<nckx>jpoiret: But then adding it to /boot would remove that signal?
<jpoiret>nckx has been hiding GRUB3 from us all this time
*apteryx gives another try at the hand-hacked /boot/grub/grub.cfg for a self-contained /boot
<nckx>Anyway. The principle is simple: each generation in grub.cfg needs the bzImage + initrd copied to /boot/gnu/store/$original_file_name, nothing more (so don't work with store items — they're huge). Then you can boot any generation. Don't add /boot to the linux … or initrd … lines, since there's no /boot prefix when you're booting.
<nckx>Looking at a Guix System grub.cfg that isn't mine, the search line before each linux/initrd line can stay.
<apteryx>oh, that's even easier than I though, thanks to Guix already uniquely prefixing each file.
<apteryx>thanks for pointing that
<nckx>LUKS might need more grub.cfg hackery (dunno) but it should work too, as you said the initrd is self-contained.
<apteryx>I left /boot unencrypted for now, one problem at a time :-)
<nckx>If it doesn't, it might be because GRUB is somehow misconfigured at install time (not ‘seeing’ that it will need to embed crypto modules). There was something about that on the bug tracker, no idea if it applies here.
<apteryx>so if I have a self-contained, unencrypted /boot, there shouldn't be a need for the GRUB luks modules, right?
<apteryx>the kernel will be the one taking care of the LUKS business
<apteryx>(my root partition *is* still encrypted)
<jpoiret>nckx: if /boot is unencrypted, it's all ok
<jpoiret>in any case, that issue wouldn't be solved by modifying grub.cfg
<nckx>Yeah, it's a core image problem IIRC.
<jpoiret>yeah, the core image needs to embed them if /boot is encrypted
<Guest11>jpoiret: no luck with that grep command. but ack points to some wicd.scm
<Guest11> i guess i'll delete that?
<apteryx>how about these lines: search --fs-uuid --set 2e97fbbd-fa4e-4858-948b-XXXXXXX; they still point to my encrypted root partition?
<jpoiret>no, don't modify anything there
<apteryx>won't that trigger LUKS decryption?
<jpoiret>Guest11: can you find the relevant line in that file?
<jpoiret>wicd.scm doesn't exist anymore
<jpoiret>but still exists in your checkout?
<nckx>Guest11: That file was removed from upstream Guix so that's odd.
<apteryx>time for 'git clean -xfdd'
<nckx>Guix caches pull checkouts, yes, but it should still update them.
***rgherdt_ is now known as rgherdt
<jpoiret>yeah, i'm just wondering if the cache updating does a hard reset or not
<nckx>git tracks removals, y'know :)
<jpoiret>right, but here the cache is obviously not consistent and guix pull doesn't complain
<nckx>Imagine having to hard-reset your tree every time upstream removes a file. That's just a bug in libgit then.
<nckx>Guest11: Move .cache/guix/checkouts somewhere else and try again.
<nckx>If that ‘helps’, keep the old cache, it might have some clue…
*nckx needs a therapeutic nature walk in the woods >:( cy'all
<jpoiret>well, update-cached-checkout doesn't try to see if the checkout has a clean worktree
<jpoiret>it's weird though that wicd.scm slipped through the cracks like that
<civodul>jpoiret: it's "normally impossible" for a cached checkout to not be clean
<civodul>that is, as long as (guix git) is the only one touching it
<Guest11>it worked!
<Guest11>thanks you wonderful guix!
<Guest11>if i can do anything to hunt a possible bug down just let me know. i'm happy to help with the little expertise i have
<jpoiret>we'll just attribute it to a cosmic ray bit flip, unless someone else experiences the same issue
<pmk>jpoiret you were correct. One of the CMakeLists unnecessarily added the directory /usr/include to the include directories. I was able to build the source in a container. Thanks!
*nckx met a hedgehog & two storks :)
<scisssssssors83>hello! does anyone know if guix home supports symlink management for arbitrary directories? i'd love to replace gnu stow with it
<pmk>I have only very recently started migrating from stow to guix home, so this is probably not the best practice, but it seems to work:
<scisssssssors7>thanks for sharing. it's a good solution, but with amount of files i have in my dotfiles it will become unmanageable rather quickly
<scisssssssors7>i've noticed there is symlink manager module but it does not provide an interface to specify needed directories if I understand the code correctly (which i probably don't because i'm very new to guile)
<lechner>civodul: thanks for nyacc yesterday!
<pmk>scisssssssors7: you could probably hack something in scheme that recursively walks through your dotfiles directory and uses the guix home API for every interesting file.
<scisssssssors7>yes, you are right. i was just hoping there is already some built-in service/function for dotfiles installation. it just came to me that in order for generations to work properly it's better to copy files instead of symlinking them
<scisssssssors7>thank you for your help :)
<nikola`>What licenses are considered appropriate for guix packages
<nckx>nikola`: Not an exhaustive list, but a good start: <>.
<nckx>Any licence considered free software by the FSF.
<nckx> <>
<nikola`>Thanks nckx
<patched[m]>I generally default to AGPLv3+ for all software I write
<nckx>I recommend (A)GPL3+ for any new software, but that wasn't how I read the question.
<apteryx>nckx: here's a rough Bash script that copies images to /boot and adjust grub.cfg, in case that's useful:
<patched[m]>Mm, I think I misread the question nckx
<nckx>Or I did!
<nckx>apteryx: How is that so much shorter than mine :-/
<apteryx>I haven't tested it (yet)
<nckx>Oh right, because I was paranoid of SSD writes, mainly. They are probably identical in function. I don't see anything missing.
<apteryx>I uses about 26 MiB per entry
<nckx>No, I think it does the job apteryx, but I'm 100% certain that I don't s,/gnu,/boot, so wonder what we're doing different there.
<nckx>Yes, Guix initrds are probably needlessly big bois.
<apteryx>oh, right, you told me the /boot prefix was unnecessary
<nckx>‘Room for improvement’.
<nckx>Well, IME.
<nckx>☝ re: /boot
<nckx>Maybe your layout is somehow different.
<apteryx>I'll test without /boot (haven't tested yet)
<nckx>LMK & GL. 🤞
<nckx>If /boot even works, we are not the same. s,/gnu,/boot, would break mine.
<nckx>Or s,/gnu,/boot&, any such change.
<nikola`>nckx: i use gpl for all of my code too, but i was thinking about packing some other project
<nckx>Right. If the licence isn't in that list or it's not clear, feel free to ask here for opinions.
<nckx>We have them.
<nikola`>I gathered that much lol, thanks
<nckx>Hi (again) abrenon! Sorry I was away earlier. I am well :) You?
<abrenon>so tired… 😴
<pmk>scisssssssors7 Reading the documentation about local files it turns out that you can include directories recursively: You can even include files conditionally based on a user defined predicate.
<KarlJoad>How easy is it to create cross-platform development environments? I want a GCC to run on x86 and compile for RISC-V. I also need tools like "make" to run (on x86 again).
<unmatched-paren>KarlJoad: i believe it's trivial if you write a guix package for the thing you're compilin
<unmatched-paren>guix build --target=riscv64-linux-gnu
<unmatched-paren>or something
<unmatched-paren>`make` is a native-input, so it'll be run on the host anyway
<KarlJoad>Trouble is, I am not trying to compile it, but have an interactive development environment for testing. Writing a package for this would be non-trivial as it is research software.
<ekaitz>KarlJoad: you can also generate a development environment with all you need for riscv, I have a manifest.scm that might be useful if you want
<ekaitz>something like that would generate a fully featured environment but you can remove the qemu or things like that
<KarlJoad>That's exactly what I am looking for! So much easier than trying to make it work in Nix.
<ekaitz>no problem!
<apteryx>nckx: I've incorporated some optimization (SSD-friendly): and dropped /boot prefix
<apteryx>uh, more like
<nckx>Nice. Just running ‘cmp >/dev/null’ seems simpler & is more efficient in the mismatch case, not that it should happen(?).
<nckx>‘We’ should really port it to Guile but I get it, mine's in bash too…
<nckx>I might do so if nothing comes up.
<apteryx>oh right, you mean the m5dsum is overkill? I totally agree.
<apteryx>or I mean just checking if the file is there should be enough... else it wouldn't have the same hash prefix
<apteryx>when I get to it I'll try adding a switch to bootloader-configuration or something to have this builtin Guix proper
<apteryx>the final, hack the actual file version: thanks for the ideas!
<apteryx>civodul: do you see this on reconfigure? "shepherd: Evaluating user expression (and (defined? (quote transient?)) (map (# ?) ?))."
<unmatched-paren>apteryx: i see that when i reconfigure
<kaelyn>So for fun before going back to bed, I just kicked off "./pre-inst-env guix refresh -r -u" for all of the packages in my system and home profiles. :)
<kaelyn>wow, ignore that message. I must've accidently hit up arrrow as I was posting.
<kaelyn>As I meant to say the first time, that guix refresh hung but even after filtering out bogus updates I have four dozen package version updates to go through
<maximed>kaelyn: bogus updates sound bogus
<maximed>Do you have some examples, such that "guix refresh" can be changed to not do bogus updates?
<vagrantc>hrm. there were a couple commits i pushed that disabled parallel building ostensibly to fix reproducibility issues, and it seemed to work locally, but not once ci and bordeaux built them ... should i revert them?
<nckx>If they don't help.
<kaelyn>Unforunately I've already discarded them. But they were things like libsig++-2 and I think gtk+-2 being updated to the latest 3.x versions, or weird version tags like xmms1.0.3 being seen as newer
<vagrantc>nckx: ok ...
<nckx>sudo's on the ball. New p1 release incorporating ‘our’ (their) fix already.
<nckx>Shouldn't be notable but it is.
<nckx>vagrantc: No?
<vagrantc>nckx: now maybe i misunderstood
<kaelyn>ah, there's the xmms-foo one... it tried to update libvisual from 0.4.0 to xmms-0.2.0
<maximed>kaelyn: right, "guix refresh gtk+@2" should only update within the 2. series because a separate gtk+@3 exists
<nckx>vagrantc: You sounded disappointed. My reasoning is, why disable parallel builds if the effect isn't there?
<vagrantc>nckx: yeah, that's what i got
<vagrantc>of course i'm disappointed :)
<vagrantc>just that they didn't work
<kaelyn>maximed: indeed, but I was also doing "guix refresh -r -u" with the gtk and libsig++ updates being some of the recursive updates
<maximed>Maybe a (required-major-version . 2) / (required-major-version . 3) / likewise for 4 property could be added to gtk+@2/3/4
<kaelyn>(neither gtk, libsig++, nor libvisual were in the explicit list of packages)
<maximed>with appropriate modifications to "guix refresh"
<nckx>(filter-version . (lambda (version) …)) — overkill?
<nckx>Would handle the even/odd weirdness too.
<maximed>xmms doesn't seem to be packaged in Guix (or my Guix is old)
<nckx>It's not.
<maximed>nckx: There's no kill like overkill :p
<kaelyn>currently going through the captured stdout of the commands.... gtkmm was another where the 3.x version was updated to 4.x
<nckx>(XMMS — there's a blast from the past. First reaction: is that still maintained? Answer seems to be: no.)
<nckx>Final release: 1.2.11 (November 16, 2007; 14 years ago)
<maximed>kaelyn: the gtk+@3 / gtk+@2 / gtk+@4 thing could be reported as a bug I think
<kaelyn>oh, and for both gtk+@2 and gtk+@3, it updated them to 3.94.0 which iiuc is a 4.0 prerelease version
<kaelyn>Another case of weird version tags (potentially) throwing off "guix refresh": sane-backends was updated from 1.0.32 to 1.9.TO.RELEASE.1.0.3
<kaelyn>and vulkan-headers from 1.2.164 to ksc1.0.10
<maximed>kaelyn: FWIW you can add 'release-tag-prefix' / 'release-tag-suffix' and 'release-tag-version-delimiter''
<kaelyn>those are the main ones I still have record of
<nckx>There's only so much upstream weirdness we can filter out generally. maximed's properties are sounding better by the moment.
<maximed>those properties should help with vulkan-headers
<nckx>I can't get over 1.9.TO.RELEASE.1.0.3.
<maximed>nckx: That tag seens to travel back in time
<kaelyn>nckx: yeah, that was the most surprisingly confusing one
<maximed>‘We have version 1.9, now let's make a branch for working on the 1.0.3 release, but forget about the existence of branches and use a tag instead’
<maximed>that's what it sounds like for me from a distance
<kaelyn>for the git updater, would it be possible/feasible to check that a "new" version is not an ancestor of the current version?
<maximed>kaelyn: That would make "guix refresh" a lot slower
<maximed>because currently, "guix refresh" only has to ask the extern git repo ‘what commit corresponds to each tag’
<maximed>Actually cloning everything (to check ancestor-hood) would take much disk and network I/O (and maybe CPU?)
<maximed>Also, upstream might do force pushes or such.
<maximed>Technically possible, but IMO with a too large cost.
<maximed>Unless the check only happens for "guix package -u"?
<maximed>(maybe with a warning "set this property to ignore those tags to prevent pointless I/O")
<kaelyn>maximed: I think it only doing it for "guix package -u" when it checks out the tree to generate a hash would be a reasonable compromise between performance and accuracy
<maximed>kaelyn: agreed, except that commits of new versions are not necessarily descendents of commits of old versions
<maximed>though maybe that can be resolved with a (newer-versions-are-descendents? . #false/#true) attribute
<maximed>defaulting to #true
<maximed>Also serves as a basic check that the previous person updating the software hasn't silently replaced the commit with the commit of a fork.
<maximed>nevermind, that doesn't hold
<scisssssssors7> pmk thanks, i'll try it
<kaelyn>maximed: what I had in mind was more a sanity check / heuristic: when doing "guix refresh -u", give a warning or error instead of applying an update if the new version is an ancestor of the old. Trying to determine if commit A represents a newer version than commit B is definitely difficult in general, but I think a direct rollback to a previous point in the same branch of the history graph would be an obvious red flag.
<maximed>kaelyn: Right, checking for new is not an ancestor of old, instead of checking old is an ancestor of new
<maximed>That shouldn't have problems I think
<apteryx>nckx: I posted my tested script to, in case it helps
<apteryx>I ended up removing the cryptsetup -u directives, they would interfere
<nckx>Helps with?
<apteryx>the 'search' directives would throw errors without the cryptsetup -u lines, so I removed them as well
<apteryx>in case it helps someone*
<lilyp>Does `guix refresh -u' even commit anything?
<apteryx>it just edits the source
<lilyp>I think careful review might be a more reasonable approach :)
<lilyp>you should also check that it builds and isn't a supply chain attack for one
<apteryx>I found something fun too; the first LUKS passphrase prompted by the kernel, Linux always fail; I need to clear the input buffer with backspaces
<apteryx>I'll open a bug with that
<apteryx>I always thought I was goofy, after having typed a couple times my passphrase in GRUB already, eh
<Christoph[m]>Hi guixers! Guix tries to download gpg keys with gpgv, but it fails. The stated reason is that the new key contains no user ID and is therefore skipped. The internet says that that is due to a privacy feature of the keyserver, which requires the key owner to allow the user ID to be public.
<Christoph[m]>IIUC, guix does not need the user id of the key to check the integrity of the download, but gpg just refuses store the key anyway. Is there a way to convince gpg to do its job properly? Or can gpg be substituted, maybe by pEp ?
<Christoph[m]>Oh, I tried `guix import gnu unifont`, that's when I ran into that problem.
<Christoph[m]>(Also, each time I try again, unifont-14.0.04.tar.gz is downloaded again, even though it is already in the store - that seems unnecessary.)
<bjc>is there an installer available that's newer than 1.3?
<bjc>(for guix system)
<unmatched-paren>bjc: yeah, but it isn't guaranteed to work
<bjc>that's fine. 1.3 also doesn't work sometimes ;)
<unmatched-paren>"These images are development snapshots, you might prefer to use well-tested released images that can be found here."
<lilyp>"well-tested" 😄️
<maximed>I modified /etc/systemd/system/guix-daemon.service but I think I broke it, does someone know where a pristine version of that configuration file can be located on Debian?
<maximed>Found it in /lib/systemd/system
<maximed>Though why does Debian's guix use the locale data from /var/guix/profiles/per-user/root? Shouldn't it use Debian's glibc's locale data?
<jpoiret>maximed: wouldn't it be possible to have mismatched locales then? since the guix daemon uses guix's glibc
<maximed>jpoiret: Sounds like a problem on Debian
<maximed>I use the guix daemon compiled by Debian.
<maximed>Which is presumably linked against Debian's glibc.
<jpoiret>right, then that should be Debian's
<maximed>So I'd expect it to need Debian glibc's locales.
<maximed>Currentl I get locale warnings:
<maximed>* Currently
<maximed>Sme tests:
<maximed>* Some
<maximed>No locale warning: LC_ALL=nl_BE.UTF-8 /usr/bin/guix --help
<maximed>locale warning: LC_ALL=en_US.utf8 /usr/bin/guix --help
<maximed>No locale warning: LC_ALL=nl_BE.utf8 /usr/bin/guix --help
<maximed>no locale warning: LC_ALL=C.UTF-8 /usr/bin/guix --help
<maximed>Removing GUIX_LOCPATH and changing LC_ALL=en_US.utf8->C.UTF-8 fixes things
<jpoiret>daily reminder that utf8 does not specify a locale, it should be UTF-8
<nckx>jpoiret: I call your bluff. Source.
<nckx>(There is none, have fun.)
<jpoiret>* there is no spec, but some scripts n code expect UTF-8
<nckx>Right. So clearly, it should be .utf8, not .UTF-8.
<nckx>Ah, the I have a buggy script defense. Hmm.
<jpoiret>there's no theoretical reason to prefer utf8 over UTF-8, but in practice i've seen locale bugs with the first
<vagrantc>maximed: C.UTF-8 is an invalid locale in guix's glibc, until you get a newer glibc ...
<nckx>And there are bugs with the latter in practice too, that's my point.
<maximed>vagrantc: The bug is about Debian's guix, not guix' guix, so guix's glibc is irrelevant here
<maximed>anyway, I'm writing a mail (reportbug etc.)
<vagrantc>maximed: which package version? i thought i fixed that in the 1.3.x Debian guix packages
<maximed>vagrantc: 1.2.X (I think I'm using Debian stable?)
<apteryx>can't we have more than one openssh service running?
<nckx>‘You should use UTF-8 over utf8’ is misinfo that merely hides the bugs, especially in Guix/glibc, because .utf8 is expected to work.
<lilyp>Isn't UTF-8 vs utf8 merely de gustibus in practice?
<jpoiret>hmmm, i've never looked at it that way
<lilyp>like how hard can it be to manage symlinks?
<vagrantc>maximed: in general, unless it's a security or serious problem, things do not get fixed in debian stable
<nckx>lilyp: It should be, and glibc normalises any reasonable nonsense you throw at it to ‘utf8’, but as jpoiret said, crappy software.
<maximed>vagrantc: If the UTF-8 locale cannot be loaded, then substitution doesn't work properly if the store item contains a non-ASCII file name
<apteryx>re, multiple openssh-service-type services: guix system: error: service 'ssh-daemon' provided more than once
<maximed>you'll end up with ? characters or a ‘cannot encode string ...’ error or such
<vagrantc>maximed: curious
<vagrantc>python 3 often just falls down with non-UTF-8 locales lately
<maximed>does that count as ‘serious problem’ in Debian?
<maximed>Does someone know how to extract the password from evolution?
<vagrantc>maximed: worth filing a bug report, at the very least, and we can sort out severity from there
<apteryx>I wanted some dummy openssh service to serve with password authentication serving on a distinct port to my main openssh service
<maximed>* nevermind, found it in seahorse
<vagrantc>maximed: it's been a long time since i looked at the guix 1.2.x packages :)
<maximed>hm, should I switch to "unstable"?
<maximed>(for comparison, Guix' level of stability would be sufficient for my purposes)
<maximed>vagrantc: has been sent!
<unmatched-paren>maximed: 1.2.x is incredibly ancient, so i guess yes... or just use guix pull i guess
<unmatched-paren>unless i'm missing context, which i so often am
<maximed>unmatched-paren: but then I have to remember to run "guix pull" as root
<unmatched-paren>maximed: why as root? isn't guix pull usually used without root?
<maximed>or point the ExecStart line at the guix-daemon in ~/.config/guix/...
<maximed>unmatched-paren: to update the daemon.
<unmatched-paren>maximed: ah
<unmatched-paren>ok, ignore me
<Aurora_v_kosmose>Is Guix's substitute store down?
<nikola_>So it is a good idea to guix pull as root
<nikola_>From time to time
<unmatched-paren>nikola_: not on guix system i think
<Aurora_v_kosmose> It seems to be causing issues upstream too.
<unmatched-paren>guix system reconfigure probably updates it
<maximed>unmatched-paren: that's the case
<unmatched-paren>but on a foreign distro you can't use system reconfigure of course
***lilyp_ is now known as lilyp
<nikola_>Ah right, fair enough
<maximed>Guix System will use the 'guix' that's put in the configuration record as guix daemon
<maximed>which points to somewhere in (gnu packages ...) by default
<Aurora_v_kosmose>On foreign distros you have to guix pull as root?
<maximed>Aurora_v_kosmose: depends on how you install guix.
<Aurora_v_kosmose>maximed: Via Debian's package?
<maximed>On Debian, you can set-up the guix daemon with "apt-get install guix"
<Aurora_v_kosmose>So, install with apt and upgrade with "sudo guix pull"?
<maximed>Aurora_v_kosmose: depends
<maximed>By default, Debian's systemd file for guix points to /usr/bin/guix-daemon.
<maximed>So that is only upgraded by "sudo apt-get upgrade".
<maximed>However, some people change the systemd file to point at /var/guix-profiles/...root.../bin/guix-daemon
<Aurora_v_kosmose>Ah I see.
<maximed>in that case, it can be upgraded with "guix pull" as root.
<maximed>(In the past I did the latter)
<catern>it's practical-software-freedom time
<Aurora_v_kosmose>maximed: So in the meantime that means that Guix on Debian is partly frozen to the version the package is at without such modfification correct?
<catern>(I just like how perfectly concise this is)
<Aurora_v_kosmose>What would it generally do for the user-level guix to be updated to recent versions while the system version is stuck at Debian versions?
<nckx>Generally nothing.
<maximed>Aurora_v_kosmose: Debian has backported a few changes, but otherwise, yes
<nckx>The protocol is very stable.
<Aurora_v_kosmose> seems to be related to the issue I'm having with substitutes.
<maximed>Aurora_v_kosmose: to update the user-level guix: "guix pull" (and set up ~/.bash_profile etc appropriately as always)
<Aurora_v_kosmose>maximed: Indeed.
<Aurora_v_kosmose>nckx: So the Guix daemon itself only has relatively limited tasks?
<nckx>catern: I like the doubling down in the reply. I'm with you, by the way.
<nckx>Aurora_v_kosmose: Yes, compared to the rest of Guix. Fixes happen (and if guix pull news tells you to upgrade, upgrade) but they aren't close to the number & severity of those you'll ‘guix pull’ daily.
<nckx>Good bot.
<nckx>maximed: maximedsnack.
<maximed>(can be read without javascript, and doesn't seem to have any trackers
<nckx>Bad bot.
<nckx>Have a ).
*maximed barfs snack back :p
<Aurora_v_kosmose>nckx: I see. I would imagine setting up the guix-daemon systemd task rewrite would still be advisable?
<unmatched-paren>--actually a `!nojs URL` bot isn't a bad idea--
<lilyp>The problem with Nix and Guix is that neither are written in Racket. That's why we need Denxi :)
<nckx>Aurora_v_kosmose: Well, stable doesn't guarantee no CVEs or other urgent upgrades, so I guess? I don't know enough about Debian to know if apt would take care of those. I'd expect it to.
<unmatched-paren>i bet that exists somewhere...
<nckx>We could use a nice (non-spammy), extensible bot.
<nckx>sneek is only the former.
<nckx>(No ‘noted’? OK.)
<nckx>sneek: you are special and you are loved.
<nckx>…does sneek not do definitions anymore?
<nckx>sneek: What is Guix?
<sneek>I've heard guix is a functional package management tool for the GNU system
<catern>(what about fsbot?
<unmatched-paren>it would be nice if i could do something like:
<maximed>sneek: What is nitter?
<unmatched-paren>sneek: eval (display "Hello, world!") (newline)
<lilyp>sneek is a JS hellhole and should be replaced with
<sneek>Got it.
<unmatched-paren>sneek: what is
<sneek>I could be wrong, but is a JS hellhole and should be replaced with
<nckx>Sure. Plenty of bots that do that.
<lilyp>I suppose people here understand the JS acronym, otherwise someone else should spell it out
<nckx>raghavgururajan introduced a bot here once, but I was a bit too mean to it… (in my defence, it was annoying, and it gaslit me.)
*lilyp → bed
<maximed>sneek: What is love?
<sneek>From what I understand, love is a very complicated thing.
<maximed>sneek: Love is what you should give to sneek.
<Aurora_v_kosmose>Hmm... given my templated VMs, I think I might have to indirect using some script, since the daemon won't start if I rewrite the systemd files before first running a root pull so that /var/guix...profiles.../root exists
<sneek>Got it.
<maximed>oops, sneek already had an entry for that
<nckx>sneek: What is love?
<sneek>Last time I checked love is baby don't hurt me, don't hurt me, no more.
<maximed>it can have multiple entries?
<maximed>sneek: What is love?
<sneek>I've heard Love is what you should give to sneek.
<nckx>That is the least concerning explanation.
<nckx>The most concerning is self-aware AI.
<unmatched-paren>sneek: sneek is a self-aware robot that secretly plots to take over the world
<sneek>Got it.
<nckx>sneek: What are you?
<nckx>…we're safe.
<unmatched-paren>sneek: what is sneek?
<sneek>I could be wrong, but sneek is a self-aware robot that secretly plots to take over the world
<nckx>I think you are.
<unmatched-paren>sneek: what is guile?
<sneek>Its been said that Guile is fantastic, sneek
<maximed>sneek: Skynet is definitely not me, you don't have any proof.
<maximed>sneek: what is skynet?
<sneek>Skynet is definitely not me, you don't have any proof.
<unmatched-paren>huh, it wasn't uncertain about that one
<vagrantc>is it plausible to have a guix-daemon build without ... the rest of guix?
<unmatched-paren>sneek: reality just IS
<maximed>sneek: Best bot is sneek.
<unmatched-paren>sneek: what is reality
<maximed>vagrantc: Maybe see the (non-public) 'guix-daemon' package.
<vagrantc>maximed: if i could package guix-daemon separately from the rest of guix, it would be feasible to provide newer versions via debian's backports, and also dramatically simplify patches to go to stable
<maximed>All the daemon needs is "guix substitute", "guix-daemon", "guix perform-download" and the Guile modules dependencies AFAIK
<unmatched-paren>sneek: the nature of reality is <mnbro ocg0elrhprguucehumabjj>
<unmatched-paren>sneek: what is the nature of reality?
<maximed>I don't think sneek understands compositions of words [replace by proper linguistic term]
<unmatched-paren>sadly, sneek does not yet have AI, apparently. Disappointing, considering lisp's history.
<maximed>sneek: What is sneek?
<sneek>I've heard Sneek is forgetful
<vagrantc>i'm guessing guix substitute and guix perform-download ... might be hard to extract out of guix
<maximed>sneek: sneek is me.
<sneek>I'll keep that in mind.
<vagrantc>maximed: the guile modules are going to be difficult to keep up to date
<maximed>vagrantc: Would a "./configure --only-the-daemon" option be sufficient?
<vagrantc>hard enough keeping up with the guile modules for debian testing/unstable/experimental
<vagrantc>maximed: maybe? :)
<maximed>(which only compiles and installs the guile modules required for the daemon)
<civodul>maximed: it also needs "guix offload" (optionally)
<unmatched-paren>sneek: sneek is there is no sneek
<sneek>Got it.
<unmatched-paren>sneek: what is sneek
<sneek>Last time I checked sneek is a self-aware robot that secretly plots to take over the world
<unmatched-paren>sneek: what is sneek
<sneek>Last time I checked sneek is a good bot
<unmatched-paren>sneek: what is sneek
<sneek>From what I understand, Sneek is forgetful
<unmatched-paren>(i'll move over to guix-offtopic :)
<vagrantc>my other fantasy would be ./configure --enough-to-guix-pull
<vagrantc>if i had a ./configure --with-guix-daemon --with-guix-pull --without-everythingelse ... i could simplify the Debian package a lot
<civodul>./configure --just-what-i-need :-)
<vagrantc>civodul: exactly!
<vagrantc>./configure --what-vagrantc-wants
<unmatched-paren>./configure --enable-mind-reading
<civodul>we could provide an option to get what the 'guix-daemon' package provides, somehow
<KarlJoad>Can Cuirass' remote build mechanism be run on the same machine? Meaning the remote-server and remote-worker are on the same computer.
<civodul>KarlJoad: yes, i think so
<vagrantc>an alternate guix offload|substitute|perform-download implementaton ?
<civodul>ah right, these three things are not provided by the 'guix-daemon' package
<civodul>dunno, might be trickier after all
<vagrantc>civodul: past you was very skeptical when i've asked about it in the past :)
<civodul>vagrantc: it may be that i just had unjustified optimistic vibes then :-)
<vagrantc>all this said, guix is having a rough time in debian ... some git related test suites started failing ... presumably due to changing dependencies
<civodul>vagrantc: there were time-dependent tests! (how ironic!)
<civodul>turns out the gpg keys used by gpg/auth tests had an expiration date
<civodul>see <>
<vagrantc>civodul: aha!
<vagrantc>i hope whatever fixes are easy to backport...
<maximed>civodul: There were some patches for time namespaces in the guix daemon (albeit with no support for the 'realtime' clock)
<vagrantc>i didn't think time namespaces supported realtime clock yet anywhere
<civodul>maximed: time namespaces are not what we'd like them to be tho
<civodul>it's pretty useless
<maximed>would not namespacing the realtime clock, lead to any problems?
<vagrantc>last i looked at it basically just allowed you to change the clock that uptime reports
<civodul>the other way: namespacing it or not won't make much of a difference
<maximed>so it doesn't impact the output of, say, 'date'?
<vagrantc>though what i read was they'd be interested in timespaced realtimeclock if there were valid use-cases
<nckx>sneek: what is there?
<vagrantc>i *totally* have valid use-cases! :)
<maximed>So time namespaces would be useful if the realtime clock was supported by time namespaces?
<vagrantc>maximed: not in my experience
<vagrantc>maximed: YES!
*vagrantc is not much for all caps, but that seemed warranted.
<nckx>How does time work in such a namespace? Number of executed instructions?
<nckx>Hm no that wouldn't work with SMP.
<vagrantc>maximed: i was looking into this recently for reproducible buuilds related time stuff
<maximed>vagrantc: Could we cheat by using seccomp filtering or such to silently replace CLOCK_REALTIME{_VARIANT} by CLOCK_MONOTONIC?
<vagrantc>maximed: dunno!
<nckx>Or is the point not to have predictable time, but to always just start the build on Jan 1, 2022 or whatever?
<maximed>nckx: For me, the point is to avoid the expiring certificate problem.
<maximed>(it's not really helpful for "it embeds the output of `date`" irreproducibility)
<nckx>Wouldn't LD_PRELOAD or whatever else libfaketime provides suffice for that?
<maximed>nckx: Sounds more fragile than proper time namespaces (e.g., what if it unsets LD_PRELOAD), but I suppose yes?
<nckx>I thought the problem was time namespaces did everything but what was actually needed by Guix.
<nckx>I skimmed but that was what I gathered.
<vagrantc>nckx: for me, the point would be to start the clock 396days into the future on a second build of a particular package
<maximed>A benefit of (realtime) time namespaces would be that we could ‘retroactively’ fix the expiring certificate problem of gnutls and the test problem of libgit2 (or was it git)?
<nckx>You could do cool stuff.
<vagrantc>nckx: libfaketime is very error prone
<maximed>nckx: Problem was that only the non-realtime clocks were supported by namespacing, while the realtime clock is the most important.
<nckx>But it exists.
<maximed>Hence my proposal to do system call rewriting tricks to automatically rewrite CLOCK_REALTIME->CLOCK_MONOTONIC
<vagrantc>exists, but doesn't always work correctly
<nckx>vagrantc: Yes, it is. And worstly, unpredictably so.
<vagrantc>maximed: that might have the same problems as libfaketime, though ...
<vagrantc>at some point, i guess the best thing is to try to break things, er, test things
<nckx>vagrantc: Not necessarily, it might be more robust (but rest assured, not prettier — wanna buy some BPF?).
<maximed>vagrantc: I'm not really seeing what problems the rewriting tricks could have (except for not recognising the latest syscalls or such)
<vagrantc>nckx: i love Best Practices Fun
<maximed>Maybe the guix-daemon should restrict the list of syscalls for reproducibility. And if the builder wants more syscalls, they have to tell the daemon by setting a property in the derivation appropriately?
<vagrantc>civodul: oh, just remove the expirations on the keys, thanks!
<vagrantc>lately, i seem to not be involved in #guix much, or involved in 3-5 concurrent conversations
<vivien>I love guile because stuff like the clock can be a parameter and I don’t have to care about it except at both "ends" of the control flow.
<nckx>maximed: The reaction to ENOSYS is close to never ‘okidoke no problem I'll just happily continue working fine’.
<maximed>vagrantc: I now see a potential problem with rewriting syscalls: clock_getcpuclockid would return CLOCK_MONOTONIC even if the program asked for CLOCK_REALTIME.
<nckx>Certainly not something I'd like to inject into the build of 22k packages.
<maximed>I don't know if that's a problem in practice though.
<vagrantc>also got a curious bug when "less" isn't available guix: Guix command uses less but less does not exist in dependent software
<maximed>nckx: If we just make a list of all syscalls in current Linux, then use those as default list, then for now there shouldn't be a problem I think?
<nckx>vagrantc: That'll be fixed soon.
<maximed>And future packages would automatically be tested for supporting ENOSYS.
<nckx>Ah. I was still thinking about clocks, specifically.
<nckx>Turning Guix into a test suite of what we consider best practices is…
<maximed>I had no plans for returning ENOSYS for (current!) clock things syscalls
<vivien>maximed, I think the semantic web can also have something to propose for configuration files, but I have to make some experiments first !
<nckx>I'm not sure ambitious is the word I'm looking for.
<lechner>Hi, anyone know an example for removal of files from a package before building, please?
<nckx>lechner: knot, for a snippet (== ‘naughty’ files).
<maximed>My reason for the syscall filtering is for reproducibility (if it compiles on a new kernel, it should also compile on an old kernel, unless it specifically asks for the new stuff).
<nckx>You could do so in a phase with the same code, but you wouldn't need to explicitly import (guix build utils).
<maximed>Acting as a test suite for best practices (I'd even say bugs) would be a side benefit (albeit rather ... ambitious, as you say)
<vivien>(with-batteries-included #~(invoke guix build utils stuff))
<lechner>nckx: thanks!
<vivien>I wish (guix build utils) were available anywhere
<vivien>Without having to import it
<nckx>The inconsistency is annoying.
<nckx>maximed: I didn't mean to sound negative, I'm merely being incredibly selfish: I don't want you to be distracted from antioxidant by compiling an exhaustive syscall list :)
<nckx>And dealing with seccomp.
<nckx>Graveyard of many fine young minds.
<maximed>FWIW, antioxidant seems largely finished (except for space & optimisation optimisations, and actually building and running tests and building examples)
<maximed>What remains is porting the crate packages to antioxidant
<maximed>which either requires updating some crates etc, or keeping the current multiple version messiness
<maximed>Also enabling requires features which antioxidant cannot do fully automatically, unlike cargo-build-system.
<maximed>Also the importer needs to be adjusted and "guix style" needs to be taught to perform the source code changes ...
<nckx>Guess I expected a longer tail than you do.
***LispyLights is now known as Aurora_v_kosmose
<KarlJoad>Is there a good way to programmatically get the Linux hash from the version defined in the guix package for it? Right now I must TOFU the hash, and I do not want to do that.
<civodul>the linux-libre package is written in a complicated way
<civodul>in general, that'd be (origin-hash (package-source PACKAGE))
<civodul>but it's not that simple here
<KarlJoad>Yeah. I need the hash so I can pass new configuration flags for some modules that are left out of the default linux-libre compile.
<PotentialUser-19>hi, i am new to guix. where can i find signature files for the development images of the guix system? the manual only explains how to obtain signatures for the releases.