<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. <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>on debian i would look at dpkg -l for the version of some package like emacs or xorg to be upgraded <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>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? <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>afraid i might not be savvy enough to help you further peterpolidoro <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 wonders why it's necessary to print these hashes everytime <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>and it may or may not use the ones you found in the store <peterpolidoro>do guix packages ever set environment variables or is that not allowed? <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> 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 <apteryx>OK, that's for an EFI system; I guess it works similarly for a distinct /boot on BIOS machine though, thanks! <mitchell>yes its almost exactly the same for bios <mitchell>just you the regular grub-bootloader instead of grub-efi-bootloader <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 <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><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><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 :-) ***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]>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")` <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]>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? <vivien>I’m not sure what the character "!" means though. <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>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. ***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 <pmk>jpoiret: LD_DEBUG is pretty neat I did not know about it. Thanks! <jpoiret>yes, it's pretty unknown but very useful! <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. <jpoiret>the program somehow inherits the /etc/ld.so.cache 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. <pmk>(of what a "normal" execution would be) <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 <jpoiret>about gnus+gmail, apparently there was a change and apteryx set it up recently, let me find the logs <jpoiret>by the way, there's a typo in lookup-platform-by-target <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) <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>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. <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>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>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? <jpoiret>i meant in general, what distinguishes a system and a target field for a platform? <efraim>oh, I just came to comment about sudo not cross compiling <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. <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>Hum, do we ever dispatch cross/non-cross builds based on how many hypens are in the name? :-/ I don't get it. <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>*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 <Guest11>i've tried adding one now, but i get the same error when i remove the channels.scm file <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? <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>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>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 <civodul>next step: merging master in staging <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 <civodul>hopefully after that: merging staging into master! <jpoiret>python2-pygtk was removed ~1 week ago Guest11 <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 <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 <jpoiret>Guest11: no, it shouldn't matter, the guix derivations don't really care about your current guix (or they shouldn't at least) <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>if so, you might've compiled with the foreign distro's headers <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>well, for specific packages, you can use an inferior <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 <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. <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>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. <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 <apteryx>how about these lines: search --fs-uuid --set 2e97fbbd-fa4e-4858-948b-XXXXXXX; they still point to my encrypted root partition? <jpoiret>Guest11: can you find the relevant line in that file? <nckx>Guest11: That file was removed from upstream Guix so that's odd. <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>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 <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 <nikola`>What licenses are considered appropriate for guix packages <nckx>Any licence considered free software by the FSF. <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. <nckx>apteryx: How is that so much shorter than mine :-/ <nckx>Oh right, because I was paranoid of SSD writes, mainly. They are probably identical in function. I don't see anything missing. <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>Maybe your layout is somehow different. <apteryx>I'll test without /boot (haven't tested yet) <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>Hi (again) abrenon! Sorry I was away earlier. I am well :) You? <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 <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. <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>civodul: do you see this on reconfigure? "shepherd: Evaluating user expression (and (defined? (quote transient?)) (map (# ?) ?))." <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>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 <nckx>sudo's on the ball. New p1 release incorporating ‘our’ (their) fix already. <nckx>Shouldn't be notable but it is. <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? <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) <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>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. <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>I ended up removing the cryptsetup -u directives, they would interfere <apteryx>the 'search' directives would throw errors without the cryptsetup -u lines, so I removed them as well <lilyp>Does `guix refresh -u' even commit anything? <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 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]>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>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." <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>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. <maximed>So I'd expect it to need Debian glibc's locales. <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>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 <vagrantc>maximed: it's been a long time since i looked at the guix 1.2.x packages :) <maximed>(for comparison, Guix' level of stability would be sufficient for my purposes) <unmatched-paren>maximed: 1.2.x is incredibly ancient, so i guess yes... or just use guix pull i guess <maximed>unmatched-paren: but then I have to remember to run "guix pull" as root <maximed>or point the ExecStart line at the guix-daemon in ~/.config/guix/... <maximed>unmatched-paren: to update the daemon. <nikola_>So it is a good idea to guix pull as root ***lilyp_ is now known as lilyp
<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 <maximed>Aurora_v_kosmose: depends on how you install guix. <maximed>On Debian, you can set-up the guix daemon with "apt-get install guix" <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 <maximed>in that case, it can be upgraded with "guix pull" as root. <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? <maximed>Aurora_v_kosmose: Debian has backported a few changes, but otherwise, yes <nckx>The protocol is very stable. <Aurora_v_kosmose>55848@debbugs.gnu.org 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) <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. <maximed>(can be read without javascript, and doesn't seem to have any trackers *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? <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. <nckx>We could use a nice (non-spammy), extensible bot. <nckx>sneek is only the former. <nckx>sneek: you are special and you are loved. <nckx>…does sneek not do definitions anymore? <sneek>I've heard guix is a functional package management tool for the GNU system <lilyp>sneek twitter.com is a JS hellhole and should be replaced with nitter.net <sneek>I could be wrong, but twitter.com is a JS hellhole and should be replaced with nitter.net <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.) <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>oops, sneek already had an entry for that <sneek>Last time I checked love is baby don't hurt me, don't hurt me, no more. <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>I could be wrong, but sneek is a self-aware robot that secretly plots to take over the world <sneek>Its been said that Guile is fantastic, sneek <maximed>sneek: Skynet is definitely not me, you don't have any proof. <sneek>Skynet is definitely not me, you don't have any proof. <vagrantc>is it plausible to have a guix-daemon build without ... the rest of guix? <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>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. <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 <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 <maximed>(which only compiles and installs the guile modules required for the daemon) <civodul>maximed: it also needs "guix offload" (optionally) <sneek>Last time I checked sneek is a self-aware robot that secretly plots to take over the world <sneek>Last time I checked sneek is a good bot <sneek>From what I understand, Sneek is forgetful <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>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. <vagrantc>an alternate guix offload|substitute|perform-download implementaton ? <civodul>ah right, these three things are not provided by the 'guix-daemon' package <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 <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 <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 <maximed>So time namespaces would be useful if the realtime clock was supported by time namespaces? *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? <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. <maximed>nckx: Problem was that only the non-realtime clocks were supported by namespacing, while the realtime clock is the most important. <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) <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. <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)) <vivien>I wish (guix build utils) were available anywhere <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)) <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.