<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
<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>https://paste.debian.net/1243391 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
<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>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.
<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
<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.
<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
<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
<ulfvonbelow>jpoiret: it seems the directories in question need to have ICDs to point to a vendor libEGL.so 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)
<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/libEGL.so: 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.
<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.
<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.
<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
<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'"
<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.
<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 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.
<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.
<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)
<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
<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?
<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
<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
<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.
<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.
<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
<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
<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’.