<leoprikler>I understand, but it still feels somewhat underdocumented <nckx>Sure. If we integrate this at the distro level we accept a lot of responsibility. <leoprikler>so (swap-devices (stuff)) (kernel-arguments (list (string-append "resume=" (car swap-devices)))) should do what I want? <leoprikler>oh well, instead of list I should cons %default-kernel-arguments <nckx>BTW, we *could* put automagic in the initrd: if no resume= is specified, scan all swap-devices for hibernation images, and resume any one found. Slick, and not guaranteed not to corrupt all file systems in certain failure scenarios. <mbakke>whoops, I replied to the expat thread without seeing the replies :P <nckx>It would have been funnier without it. Both meanings are the same. <jackhill>I wonder what other distros do/what protections they have. Maybe only do the automagic stuff if there is only one swap? Or perhaps just ask people in the installer? <nckx>‘Slick, and your root file system will probably survive most of the time!’ <leoprikler>okay but how does this differ from say resume=/my/favourite/partition if /my/favourite/partition is actually not the one I should resume from? *mbakke is venturing into core-updates land <nckx>I didn't mean that resuming from the ‘wrong’ partition is a likely risk. Resuming twice from the same image is what would really murder data. <nckx>I'd need to read the swsusp code again. It's been over a year. <leoprikler>Hmm, but doesn't resuming once "invalidate" that image, so that it won't be resumed again? <leoprikler>of course, depending on when the image is invalidated, you could get into resume → power outage → data loss <nckx>I don't have an unpatched/git kernel handy; checking out an upstream Linux takes ~15 mins here. <leoprikler>okay, what do I do when /var/run structure needs cleaning? <nckx>Put it on tmpfs like a sane modern dis^C <nckx>I think that depends entirely on what you mean by cleaning, leoprikler. <nckx>fsck your root file system now. <leoprikler>should I be worried about the state of hibernate in guix? <leoprikler>and perhaps as a follow-up, why is /var/run not tmpfs in Guix? <lfam>vagrantc: The Debian installer can't seem to find the macchiatobin's network interface, even when I select the right driver. Is this something you can give advice about? <lfam>I tried 'debian-10.9.0-arm64-xfce-CD-1.iso' and 'mini.iso' <lfam>But I'm not sure if I need to do something with that <lfam>Or does it indicate that I built the Tianocore / UEFI / EDK2 incorrectly? <lfam>I'm totally out of my depth <lfam>Maybe I should try the RC for the upcoming Debian release <nckx>leoprikler: You did the equivalent of pulling the power cord by not resuming the hibernated image. And this is why hibernation isn't advertised 😉 <nckx>It was always possible to hibernate, but now possible to resume without corruption if you know what you're doing. <leoprikler>I can write a hibernate image to swap. Then reboot from the hibernate image and my file system is probably safe. <lfam>vagrantc: Great, it's working with the Bullseye RC1 <lfam>I use hibernation a few times a day on Debian leoprikler. I think it's super-reliable as long as you are careful to always boot from the hibernation image <lfam>But, my impression is that it's not something that gets a lot of attention in the kernel. And if it breaks, well, obviously that ruins your day <leoprikler>Well, that's what I wanted to do, but for some reason booting from the hibernation image is not the default in Guix. <nckx>It *is* reliable; it's not plug & play <lfam>Yeah, we should see about improving that <nckx>leoprikler: Then add it? Just make sure it's safe. <nckx>* make it the default, I mean. <lfam>I never had to do anything "special" to set it up on Debian. Somehow, Debian have instrumented GRUB (or something else?) to always boot from the hibernation image if it exists <lfam>So, it's definitely possible to make things work <nckx>lfam: There's no resume= in /proc/cmdline? <lfam>It's just this: "BOOT_IMAGE=/vmlinuz-5.12.2 root=/dev/mapper/jasmine--vg-root ro quiet acpi_osi=" <drakonis>lfam: which package definition provides cc? <lfam>drakonis: Is it for a package definition? <lfam>In general, nothing provides `cc`. GCC provides `gcc` <drakonis>can't compile some dependencies that need it <nckx>I have 0 interest in adding this to Guix but there's no reason we can't do the same. The kernel interface is simple and stupid and reliable. <lfam>You can invoke Make with CC=gcc <lfam>That's what we do in Guix packages that needs cc <lfam>Well, there is no such thing as a compiler named 'cc' <lfam>Or, run Make with CC=gcc <lfam>It's an upstream bug if the Makefile (or other build scripts) doesn't respect that flag <lfam>You can also patch the build scripts, or make the symlink yourself <leoprikler>yay, and the loginctl hibernate resume seems to hang <drakonis>its for building openblas in a opam build <nckx>leoprikler: Now *that's* a bug! \o/ Did a previous one succeed? I didn't follow everything. <leoprikler>the manual method did work safe for the power cord thing <lfam>I'm setting up a build machine that has 8 GB of RAM. I'm wondering about partitioning. I normally make /tmp a tmpfs, but I usually have more RAM than this <nckx>Well, it didn't resume, though. So it likely {c,w}ould have hung as well. <lfam>I guess that page cache should work okay even if /tmp is on disk <nckx>And this is the 3rd, which hangs? <nckx>Attempt, counting the first reboot that didn't resume. <leoprikler>Well, you would have to count more reboots that didn't resume, because I'm normally using a bluetooth keyboard, that GRUB doesn't handle. <nckx>OK, I chose a very confusing metric. <nckx>Anyway, I gather ‘it resumed once even though it restored stale data’ + ‘it resumed once and hung’. <drakonis>interestingly enough, the opam importer takes care of the dependencies <drakonis>dont even have to mess around with symlinks, how wonderful. <nckx>Reading backlog: Using the older-school /var/run instead of tmpfs /run could be some anti-systemd posturing, but I doubt it. I doubt a well-tested patch to use a tmpfs /run + compatibility symlink would be vigorously rejected. <lfam>IRC is such a riot. One person is despairing over a corrupted filesystem, while another person is magically imported an entire dependency graph <nckx>leoprikler: Might be coincidence. I'm not sure what would be the least bad answer. <nckx>I don't even know what a consistent difference between echo | tee and loginctl would *mean*. <nckx>Knowing nothing of the latter. <lfam>With loginctl, the authentication can be integrated with the rest of the systems privilege management stuff <nckx>lfam: It's not Real IRC® until someone starts preaching unsolicitedly about 1-2-3 back-ups. <leoprikler>I know one thing, that's not to my liking, which is that resume after echo | tee brings me back into action without requiring login <nckx>lfam: Right, I meant the raw hibernation mechanics. <lfam>leoprikler: That's kind of the point of hibernation. It puts you back exactly where you stopped <lfam>You can use LUKS to add a layer of privacy <nckx>No let's patch the kernel to invoke swaylock. <nckx>But yeah, this is the job of your DE/hibernation script, not loginctl or lower. <nckx>I'm almost certain that getting loginctl to work reliably is the first step towards that. <nckx>Only problem is, it seems very reliable here. <leoprikler>4th attempt: loginctl via dbus (which is what the GNOME shell extension does) <leoprikler>I get a more or less black screen with two lines saying "tmp_try_transmit: send(): error -62" <leoprikler>The first line has been there since my first attempt to hibernate via loginctl. <nckx>Are you on a ThinkPad? My TPM chip doesn't like being suspended either, but it's probably ‘harmless’ as in unrelated to any hangs/panics. <nckx>I don't use the thing but never remember to disable it in Setup. <nckx>...OTOH I see that I do rmmod "tpm" "tpm_tis_core" "tpm_tis" before hibernating. <nckx>Maybe it was *almost* always harmless :) *nckx adds comment to add more comments to private scripts... <leoprikler>I don't trust this tpm stuff anyway, so disabling it sounds good. <nckx>Apart from that forgotten (sorry) gem, there's no real secret sauce in there: rfkill+DPMS+full CPU speed to save a tiny bit of power during image writing; swaylock before hibernation; undo stuff on the way out. <nckx>leoprikler: In the firmware set-up interface. F-something at boot but we have a fancy GRUB option now, too. <nckx>Or if you mean removing the module: I literally just have a ‘zz’ bash script that does all of the above. No fancy hook system. <leoprikler>I actually meant that as in disabling the module from guix.scm <leoprikler>ahh well, it's already getting late and i need some sleep <lfam>I hope that your consciousness resumes from hibernation successfully tomorrow ;) <nckx>leoprikler: modprobe.blacklist=... in kernel-arguments. <lfam>Hilarious message from the newly installed macchiatobin, after invoking `systemctl poweroff`: "ERROR: a8k_system_off: needs to be implemented" <lfam>I guess the point is to use it, not turn it off *nckx should also zz to beat them by .5h... <lfam>"IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" <mekeor>hello. i'm working on a guix channel (which i might end up submitting to upstream). when i try `guix pull` (with my own guix channel added), the "build of /gnu/store/…-guix-package-cache.drv fail[s]". the error message says: (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python-ipaddress)) (value #f)) – but i have imported (gnu packages python-xyz) where python-ipaddress is exported. <mekeor>so do you have any other ideas what might be causing this error? <lfam>Lol vivien_. That's another good one <lfam>Somebody should make a song or poem out of these <lfam>mekeor: From what I can see, there is no package variable in Guix called "python-ipaddress" <lfam>There is a python2-ipaddress <lfam>When you do ("python-ipaddress" ,python-ipaddress), the first part is a label that you can put any value in, and the second part is the variable name. <lfam>The Scheme variable is different from the Guix package name <mekeor>yes, i had an old checkout of the guix-repo locally, where python-ipaddress existed :( <lfam>I think there is a way to "pin" your channel to that older Guix revision <lfam>But, it sounds like python-ipaddress is part of Python itself now <lfam>See commit 165786bb7a4d44303e76b1b6fb7ad1e678d45340 <mekeor>ah, cool :D awesome! i should have checked the logs :D <mekeor>btw, the same with python-enum34 was the case <lfam>It's tricky if your program is using Python 3 but hasn't been updated since CPython swallowed these programs *lfam runs `guix pull` on the Macchiatobin <lfam>I don't have much experience with channels so I can't tell you exactly how to handle htis <lfam>Of course, someone else should know :) <mekeor>noo it's fine, i just needed to figure out what you pointed me to! thank you :)) <drakonis>welp, gonna try to make my django project work with guix and switch my vps to it <mekeor>drakonis: sounds like an awesome project :D <lfam>vagrantc: There are substitutes for linux-libre-arm64-generic-5.10.35 now too. The source and the compiled kernel <drakonis>since i have a arch container running in it <mekeor>lfam: omg my channel built successfully :O so happy now *.* <drakonis>are user namespaces enabled by default on guix? <mekeor>drakonis: do containers work without user-namespaces? <drakonis>but it does not grant them a separate view of users <mekeor>drakonis: maybe you just need to add a config-flag to the existing linux-package :D <lfam>drakonis: If you can advise on what it takes to get them working, we could see about adding them as an option <drakonis>maybe its because pflask hasnt been updated in years now? <drakonis>hmm, maybe its because i need to raise the uid and gid limit for pflask to work <drakonis>same issues i'd run into with lxc i think? <drakonis>sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory <drakonis>i'll work out how to get it functioning as expected <drakonis>i'd honestly like to use something like pflask within guix or shepherd <drakonis>its ideally what i'd use over something like systemd-nspawn <drakonis>welp, i know what i'll be doing over next week <lfam>We do have some containerization in `guix environment --container` and `guix container` <drakonis>it only deals with packages available on the repository <drakonis>i was aiming to use it for containerizing single applications and entire systems <drakonis>for aiding me with developing in distributions that aren't guix <drakonis>this is all about being able to quickly migrate to guix <apteryx>lfam: about wget vs guix download; newcomers wouldn't know that the later is a suitable replacement of the former; they're used to wget and wonder why it's not part of the default install (there was 2 reports of it missing on the bug tracker) <lfam>Yeah, those are good points <lfam>Maybe in the long run we could remove it from %base-packages and provide it in the installer itself, but it's not a big deal <lfam>We should fix bugs. That's the important thing <lfam>I used the binary installer script on aarch64 a few minutes ago, all good <lfam>That was on Debian Bullseye (release candidate) <apteryx>other GNU/Linux distributions include it by default (it is in Debian for example), so many scripts take it for granted that wget is there. <lfam>How are you feeling about the release? <admas>In case this is helpful to others, I figured out that my XDG init file wasn't loading because I had an .emacs file and emacs.d file that must have been auto created the first time I opened emacs. <lfam>apteryx: I tried running the command in step #1 from your 1.3.0rc2 announcement email. Bash misinterprets the '?' characters in the wget invocation. I think the URL should be quoted <apteryx>lfam: "only" the NEWS + blog post + announcements are left to do <apteryx>eh, I thought I had removed that wget command and just pointed the link. Guess I forgot to remove it. <lfam>That's an even better idea <apteryx>by the way, does someone have a readily available VM of 1.3.0rc2 to test? I can't seem to change the keyboard layout in Xfce, at least in the Xfce menus. <lfam>I wonder, is that supposed to work? Or does it come from keyboard-layout in xorg-configuration? I don't really know about these things <lfam>Before the first `guix pull` you see warnings like this: "guix install: warning: Your Guix installation is 18757 days old." <drakonis>i'm impressed, installing packages is much faster now <lfam>The HTTP requests are pipelined so downloading things goes a lot more quickly <drakonis>the latest tagged version is missing 4 years of commits <drakonis>there was a breaking change in the kernel since <lfam>No releases in a long time? <apteryx>lfam: my understanding is that it should work as long as the user hasn't explicitly specified a layout in their config or at least until the next reboot/login <drakonis>this one seems to be maintained and achieves the same task <vagrantc>lfam: glad you got the macchiatobin on bullseye ... due for a release any day now and comes with guix available :) <lfam>It didn't work out of the box on Buster :) <vagrantc>apparently need something like PERLPATH set or something <lfam>I'm going to compile the kernel as a benchmark <lfam>And also to test how much this things works the way that I'm used to <vagrantc>really gotta get apt in guix now, to really complete the cycle ... and to get mmdebstrap (an apt-based debootstrap alternative) into guix :) <karmayogi>Hi! I am trying to look for something like LXD in guix to manage container in cluster. Is there anyway to use guix deploy to launch and manage containers created using guix on ubuntu. <mekeor>note to future self: if you want to `git clone ssh://some-guix-system-machine:/path/to/repository`, make sure git is in your system-wide packages, otherwise you'll get an error stating: "git-upload-pack: command not found" :) <lfam>It should work from your own packages too <lfam>It may be a case of GIT_EXEC_PATH not being set <vagrantc>mekeor: to workaround that i sometimes use sshfs <vagrantc>workaround that sort of thing ... e.g. git not installed at the remote <karmayogi>mekeor: Thanks for the link it seems this is targeted towards Docker. I am looking for some help with LXD (https://linuxcontainers.org/). At present I am using ansible to manage LXD cluster and containers within it. I was planning to replace the whole tooling with guix, but don't know where to start. <clacke>mekeor: I have my .bashrc check if the parent process is sshd and if it is I do things like add certain things to my PATH <clacke>I have a ~/.ssh/bin with trampoline scripts for e.g. git-annex <vagrantc>linux-libre@5.12.2 is working on the mustang, fwiw :) <lfam>I'm building it here too <vagrantc>haven't quite figured out exactly how i want to set this up to guix publish <vagrantc>probably a caching proxy on some internet facing host with some wireguard inbetween <lfam>You definitely want a proxy if it's for public use <vagrantc>and then set up a virtual armhf machine ... <vagrantc>and just set them up to build a few system images that i care about <vagrantc>or ... should i just install Debian and use the guix there... <vagrantc>oh, i can offload to the virtual machine, right... <lfam>Is the virtualization efficient? <vagrantc>it uses kvm, but disables 64-bit support so it's almost like "real" 32-bit hardware <vagrantc>they've been performing really nicely for reproducible builds tests <logiz>hey I'm using guix in virt-manager and trying to get multi displays over spide using video qxl. If I try a fedora iso I can get multiple displays by setting the qxl heads to 2, but for guix this doesn't seem to work. is there anything special I need to do, other than install vdagent for spice? <logiz>I feel like I jumped into a conversation about what I'm asking :D <vagrantc>logiz: not exactly, but interesting parallels :) <lfam>I'm not sure, I was about to ask apteryx <vagrantc>i should try to replicate my virt-manager 32-bit armhf VMs running Guix System (both for the host machine and the VMs) <vagrantc>basically, i wrote a wrapper script that does: /usr/bin/qemu-system-aarch64 $@ -enable-kvm -machine virt,gic-version=host,kernel_irqchip=on -cpu host,aarch64=off <vagrantc>runs debian's armhf kernel fine, so will see if i can get guix's linux-libre running on it <vagrantc>hrm. linux-libre@5.12 no video on pinebook pro :/ <drakonis>oh great, i have a library that has a a dependency on rust nightly <drakonis>i take there's no rustup in the repos, yeah? <logiz>"Fatal could not create the server socket /run/spice-vdagentd/spice-vdagent-sock: Error binding to address: No such file or directory" any idea how to debug this? <drakonis>by the way, since recursive derivations came up a while back <drakonis>it is also useful for dealing with builds that require multiple languages <drakonis>i have run into a python dependency that requires rust nightly <vagrantc>aha, 5.12.2 didn't apply the pinebook pro lcd patch from 5.10.x and 5.11.x ... ***iyzsong- is now known as iyzsong
<bdju>anyone wanna take a stab at packaging a rofi fork with wayland support? it seems like upstream is in no hurry to implement the stuff themselves, and wofi feels like a big downgrade from rofi <davidl>Hi, anyone who wants to review an old patch of mine: #47898 - it is for CORE-UPDATES, and tested the build and passes lint-check (if I recall correctly). <efraim>Does anyone have icecat working on wayland? I can't get it to recognize my mouse but it displays just fine for me <rekado_>I really don’t like that “guix gc --list-dead” will remove gc root links to targets that the daemon cannot access right now. <leoprikler>nckx: I've managed to disable TPM, now I simply get a black screen when resuming after hibernate <rekado_>would it be okay if we moved the deletions behind an obviously named command line option? <leoprikler>imo --list-* should always imply --dont-go-deleting-stuff <rekado_>same goes for the daemon deleting things from the store when the localstatedir is not correct <civodul>rekado_: yeah, 'guix gc' invokes the GC, and that includes that phase to remove "stale links" <leoprikler>i also think, that the gc should do much less when only asked to delete some specific file(s) <efraim>the remove_disk_images script I have specifically calls 'guix gc --list-dead' first and then works on the list because it locks the database and can take a while <rekado_>civodul: I just sent email to guix-devel with a proposal to improve “guix gc” for cluster deployments. <civodul>roptat: hi! should we run "make download-po" or similar before the release? <civodul>i took a stab at NEWS on version-1.3.0 but i feel like i must be missing important things <civodul>can anyone a favorite feature of theirs that's not mentioned? <karthik[m]>raghavgururajan: should i create an environment before building a package? <efraim>speaking of NEWS, someone with power9 hardware should check mesa to see if they get graphics. I just made sure it would build correctly <efraim>is the recursive importer new since 1.2.0? <bone-baboon>When I try to run `guix copy --to=<username>@<ip-address> hello` it fails with this error "guix copy: error: SSH authentication failed for <ip-address>". I have run `guix package --install guile-ssh` on both the sending and receiving computers. I have added the ssh public key of each computer to the other computers ~/.ssh/authorized_keys file. I have run `sudo herd restart ssh-daemon` on both computers. Any suggestions on <vivien_>bonne-baboon, I think you need to configure the authorized keys in the system configuration <apteryx>bone-baboon: you need a working ssh setup ('ssh the-box' logs you in) <vivien_>like (service openssh-service-type (openssh-configuration ... (authorized-keys `(("user" ,(plain-file "key" "ssh-rsa xxxx me@some.place"))))) <vivien_>You have only one N sorry bone-baboon <bone-baboon>apteryx: I am able to ssh into each computer from the other but I have to enter a password. I thought adding a public key to ~/.ssh/authorized_keys allowed ssh connections without entering a password. <apteryx>is your SSH key encrypted (password-protected?) <apteryx>you can use 'ssh -v' to see what authentication mechanism it uses <vivien_>bone-baboon, I think you should try setting the authorized key in the system config of your foreign box <apteryx>vivien_: that's nicer but not a requirement <apteryx>the good old ssh-copy-id script should do too :-) <bone-baboon>apteryx: I have run ssh-copy-id on both computers. It says the keys already exist on the remote system. When I look at ~/.ssh/authorized_keys the public keys are in those files. <bone-baboon>apteryx: When I created the ssh keys I did not enter a password and just pressed enter when prompted for them. <bone-baboon>Could this be because I used `ssh-keygen -t ed25519`? <bone-baboon>Okay so after looking more carefully at the -v output of ssh I found out that the reason it was using password authentication was because I had renamed the public and private keys. After changing them back to their default names I no longer need to enter a password to make a ssh connection. <bone-baboon>Now when I run `guix copy --to=<username>@<ip-address> hello` I get a new guix copy error of "guix copy: error: failed to authenticate server at '<ip-address>': not-know". ***rekado_ is now known as rekado
<bone-baboon>I deleted the ~/.ssh/known_hosts and making a ssh connect created a nwe ~/.ssh/known_hosts. <bone-baboon>Now when I run `guix copy --to=<username>@<ip-address> hello` I get this new error message "guix copy: error: failed to connect over SSH to daemon at '<ip-address>', socket /var/guix/daemon-socket/socket". <Formbi>is there a texlive-minimal in Guix? <derivates>Hello, any ideas why boot-up (waiting for login manager screen) takes a long time? (this is a fresh install) <sneek>derivates, you have 1 message! <sneek>derivates, apteryx says: ratpoison because it uses 5 MiB of RAM and doesn't get in my way <efraim>not a lot of time has been spent making the boot-up process faster. help wanted! :) <derivates>I was kinda wondering if it was services taking up time but like I said this is base install <simonsouth>derivates: I've found this is often related to the network connection taking a while to come up. <simonsouth>...which in turn has been sometimes related to the firmware for my Wi-fi adapter taking a while to load. Not sure why that happens though. <simonsouth>You could try hitting Ctrl-Alt-F12 from a virtual console right after boot to see a log of kernel messages as they're printed. That might offer some clues. <derivates>also, any ideas on how to make ~/.xinitrc file work <simonsouth>I'm not so far along as to have X up and running so someone else will have to advise on that. <roptat>civodul, yes, we should run "download-po" <efraim>looking at my own dmesg, the following line is 11.25 seconds after the previous line [ 24.707382] 0000:08:00.0: Missing Free firmware (non-Free firmware loading is disabled) <efraim>9.174289 for Service root started, 29.636890 for zram, so about 20 seconds in shepherd from the start of PID1 until the last pre-login event I can find <raingloom>i'm still struggling with g-expressions in services, maybe someone knows the answer: how do i run a command from an ungexped package with the correct environment variables? <raingloom>i get that derivations are supposed to have environment variable info, but i have no clue how i'd run one. i looked at some packages in the guix sources but couldn't find a good example of what i'm trying to do. <vivien_>It would be useful if you could find an example. <raingloom>nope, the package works as expected inside guix environment, but has missing dependencies when run inside the service <vivien_>If you run the command outside the environment as /gnu/store/xxx-package/bin/command, does it work? <raingloom>so the only reasonable explanation seems to be that propagated inputs are not found <apteryx>civodul: what kind of quotes do you use in the NEWS file? around for example ‘qemu-binfmt-service-type’; apart from not knowing how to type these, could we make use Org markup, e.g.: ~code~ ? <roptat>raingloom, I think in a gexp, guix doesn't set any environment variable for you <vivien_>raingloom, if /gnu/store/xxx-package/bin/command does not work when you invoke it outside the environment, then it’s broken <vivien_>It should set its own environment variables with wrap-program <roptat>vivien_, not if the environment variable is to find plugins and such <raingloom>these are chez scheme modules to be precise. <roptat>yeah, you wouldn't like to wrap chez to only find exactly one library :) <raingloom>well, the inputs are libraries, the command is a chez script. <raingloom>but the final package also has an internal library that needs to be found. <roptat>you'll have to set CHEZSCHEMELIBDIRS to something like lib/csv (package-version chez-scheme) -site (see "guix edit chez-scheme") <vivien_>In (guix packages), you have the transitive-inputs function <raingloom>maybe i should just look at (guix scripts environment) and see how that does it. >_> <vivien_>If you consider all your inputs to be plugins, you can use this to create a somewhat meaningful value for CHEZSCHEMELIBDIRS <vivien_>(I trust roptat for the environment variable name ^^) <roptat>and I trust other contributors to have set the correct native-search-path :) <raingloom>yeah, the search path is correct, i use the same path to install the modules. <vivien_>You should have a list of chez scheme plugins. Call this function on each of them, get the libdir for all of them, set up the environment variable with setenv and it should work :) <raingloom>it's so weird that there is no canonical way to go `guix environment --pure --ad-hoc my-chez-script -- my-chez-script` <raingloom>i mean, i know that would work, but at that point i'm duplicating functionality that guix already provides in other places. <vivien_>Note though that the transitive-inputs function will add a lot of noise to CHEZSCHEMELIBDIRS, because it has no way to know for sure that an input is a chez scheme module. <roptat>raingloom, do you expect my-chez-script to ever need more than its inputs? <roptat>if not, you should wrap it a vivien_ suggested in the beginning <roptat>then when you use it in the g-exp, it will work immediately <raingloom>oh. hm. i guess it doesn't use anything else, not to my knowledge at least. so i guess wrapping it is. <roptat>it'll make things much easier for you <raingloom>well... i mean, it does need to find libc to do some FFI calls, but i guess wrapping can take care of that too? <vivien_>That’s managed by rpath I think, so you don’t need to do anything <roptat>if you can, either set rpath or hard-code the library location in the binary <roptat>well, it's a script, so maybe no rpath for you <lfam>apteryx, civodul: Should I push changes to NEWS to the version-1.3.0 branch? <vivien_>I mean, the chez interpreter should know how to find libc, right? <raingloom>vivien_ , roptat: thanks, gonna try wrap-program. UwU <roptat>apteryx, civodul I see two new sentences in guix.pot :/ <apteryx>I'm currently screening the commits for anything forgotten <apteryx>with something like: git log --invert-grep --grep=[Uu]pdate --oneline v1.2.0.. <apteryx>the node build system was rewritten but I'm not sure what improvements it brought <lfam>There are so many changes and improvements but it's hard to decide right at the last minute what is noteworthy <apteryx>yeah, the easy ones a from etc/news.scm; civodul has done a good job at listing those already <raghavgururajan>If I use native-search-patch, that variable will become available in the system's env-var list right? <lfam>apteryx: bcachefs support? <lfam>Is it considered "fully supported" in Guix now? <nckx>Connect to IRC, type ‘Good mo’, get pinged. <lfam>Should we mention bcachefs support in NEWS for 1.3.0? <nckx>Hi all. Ehm, well, it's fully *working* AFAIK (I've been using bcachefs root for over a year), but it's not an upstream Linux file system yet: none of our kernels provide it. <nckx>So I don't think we should claim it's supported. <nckx>Nice thing is, as soon as it's upstreamed, boom, Guix support. But that will take a while. Kent isn't super great at playing the LKML game. <apteryx>I don't see anything for the HTTP pipelining that improved the substitutes fetching performance? <lfam>I'm looking at a different revision of the file. I don't see a "New services" for 1.3.0 on the version-1.3.0 branch <nckx>Oh, so is bcachefs, and with a wording we can defend :) <lfam>apteryx: The substitutes perf gains are mentioned as "Substitute installation has been optimized" <lfam>Hm, I guess I checked out an old revision of the branch <civodul>lfam: i think bcachefs is mentioned already <nckx>leoprikler: That's a relative luxury. Anything in dmesg? <efraim>raingloom: would something like the rshiny-service work? <lfam>I was looking at an old copy of the branch civodul. Sorry for the confusion <civodul>roptat: oh, what are these new sentences? <roptat>;; This is an operating system configuration generated ;; by the graphical installer. <civodul>roptat: ah yes, it was missing before, so i added it <civodul>so it'll be translated next time, so i thought <roptat>also "name should use hyphens instead of underscores" <civodul>i don't think we cherry-picked it from master, did we? <leoprikler>nckx: Nothing useful, I blame the graphics card. <roptat>I have the string in my version-1.3.0 branch that I pulled just now <leoprikler>Given that it's a blobby one already, I don't think there's much Guix can do. <roptat>civodul, I see it in the branch history to, as c68070e4eefd25118b368bd7af872f65ab739fc7 <nckx>I agree with your last line, leoprikler. <lfam>Hey maintainers, what is the standard for adding machines to the build farm? Do they have to run Guix System? Or is it okay it's another distro with linux-libre? <nckx>leoprikler: I'd discard the entire problem as an uninteresting kernel/proprietary garbage bug if it weren't for that little hook. Hmm. <civodul>roptat: that's on version-1.3.0 or master, though? <civodul>roptat: BTW, while building the manual, i noticed paren mismatches in translations (there are warnings) <roptat>unless it was pushed to master before the fork? <leoprikler>Do other Guix successfully hibernate through loginctl? <leoprikler>I'd be perfectly honest to accept, that it's just my machine acting up. <nckx>I did once by accident yesterday 😛 I'll save my work and try again. <civodul>roptat: i think that was pre-fork, yes <nckx>It's a relatively Linux-friendly ThinkPad with i915 graphics etc. <nckx>Not using my convenience script (so no rmmod etc.) either. <leoprikler>Guess I'll have to accept that thing is not suitable for hibernation <lfam>I feel like most operating systems have stopped supporting hibernation. Suspension is seen as good enough <nckx>Which is horrible but tangential. <lfam>Or maybe I just stopped looking for it. MacOS definitely doesn't expose it to the user <civodul>roptat: for the mismatched parens in translations of the manual, do you think this is something you could fix? <roptat>I can fix any issues with the French translation, but only code issues for other languages <roptat>when are we releasing the new version? <nckx>lfam: It's since been freed, but my partner's then-Windows ThinkPad needed a command-line command run to enable it. Sad, sad, bad, sad. <lfam>I guess that batteries / low power support is good enough that you can go weeks or even months on suspend to RAM <lfam>But obviously that's no good for a workstation <lfam>MacOS actually does hibernate automatically if your battery gets low while suspended ***sneek_ is now known as sneek
<nckx>Linux calls it hybrid sleep: it writes a hibernation image to swap, then suspends to RAM instead of entering S4/off. If you resume from RAM, the hibernation image is never used, but if your battery dies you don't lose data. It's not well-implemented but it's there. <apteryx>civodul: if there were commits breaking the string freeze, we can simply drop them from version-1.3.0, no? <lfam>nckx: That's pretty nice <lfam>I wonder if "random laptop" have good enough power management for it to be worth it, compared to Macbooks. It wouldn't be great if your battery died every night <lfam>IME with Macbooks it takes a long time before it kicks in <nckx>lfam: There's a loginctl wrapper for that, too 😉 Haven't tried it yet but it ’can't’ be buggy if your suspend to RAM/disk already work. <civodul>apteryx: i don't think that's the case, but i'll let roptat confirm <roptat>I don't think anything broke string freeze <civodul>there's one additional string that i added (for the generated config.scm); we can revert that commit if needed <civodul>roptat: re parens, these are mismatches in @lisp snippets in the manual/cookbook <roptat>ok, then I can definitely fix them <roptat>how can I generate those warnings? <civodul>"guix build -f doc/guix.scm" i think <roptat>ok, how much time do I have before release? <civodul>it's the HTML syntax-highlighting code that detects them <civodul>apteryx: what's a good target date for you? tomorrow? <roptat>as long as we don't release today, I should be able to fix them :) <civodul>you're in roughly the same TZ as apteryx i believe <apteryx>roptat: I was aiming to release later today but it can be tomorrow as well, no problem. <roptat>great, I'll fix these warnings this evening, then we can "download-po" one last time and release tomorrow :) <roptat>apteryx, I'll ping you when I'm done with the warnings, and then you decide when to release <civodul>apteryx: IWBN to release before 5-6PM CEST, so people in Europe have a chance to see the announcement <civodul>that probably means you have to upload the day before in the evening or so (your time) <civodul>we'll need someone to reconfigure berlin too <apteryx>is that something any guix-sysadmin should be able to do? Or are there things to watch for outside of simply running guix system reconfure? <yoctocell>Is it just me or is the `emacs' package broken? `./pre-inst-env guix environment --ad-hoc emacs -- emacs --version' <yoctocell>/gnu/store/as4fpcyq6qjngp6433w68v09x5znhh10-profile/bin/emacs: error while loading shared libraries: libm17n-core.so.0: cannot open shared object file: No such file or directory <derivates>Whenever I add .xinitrc file GDM will just ignore but if I rename it to .xsession it will crash GDM and wont login, any ideas on how to execute programs on X startup? <pkill9>I think the main issue with hibernating with guix is loading the hibernation, rather than going into hibernation <pkill9>since guix rejects statefulness, it doens't load the hibernated state <apteryx>civodul: you've done a terrific job with the NEWS file, thank you! <lfam>This is for future releases, but I was thinking it would be nice to release with a default kernel that has long-term support <lfam>I'll keep it in mind and start a conversation after the release <civodul>apteryx: i may have forgotten stuff, though! <civodul>apteryx: re reconfiguring berlin, that's something several of the guix-sysadmin folks can do <apteryx>civodul: I just screened the commits using git log --invert-grep --grep='\([Uu]pdate\|Add\)' --oneline v1.2.0.. and didn't find anything missing <civodul>i'll be away for a couple of hours in the CEST afternoon tomorrow, but nckx, rekado, or someone else can also do it <apteryx>I'll just add these to the **Distribution section: "The Guix System demonstration VM now supports the SPICE protocol" and "The installation script can now run in a fully automated manner", if that looks OK? <rekado>yoctocell: I tried “guix environment --pure --ad-hoc emacs -- emacs --version” with Guix on commit 8b0ae1eb72d2844d83c5da2b3393088446bc73d1, and I cannot reproduce this. <yoctocell>rekado: I tried it on the latest commit (87b4b0e4385149b40ee87ae2d57712679452746b), I will try with an ealier one to see if it works. <raghavgururajan>nckx: Yo! Declaring a variable in (native-search-paths) of pack-def, will make that var as env-var in shell after install right? <vivien_>raghavgururajan, not necessarily, I had a problem with XML_CATALOG_FILES that would not be set until after I installed libxml2 to my profile <nckx>raghavgururajan: Yes, if there are packages in the same profile that provide matching files. <nckx>vivien_: That sounds correct? <nckx>libxml2: (variable "XML_CATALOG_FILES") <yoctocell>rekado: I just tried it on commit 8b0ae1eb72d2844d83c5da2b3393088446bc73d1, and it works fine. Something must have broken it in the last few days/weeks. <nckx>raghavgururajan: Remember/note that native-search-paths are a property of the *consumer*, not the provider! E.g. FOO_PLUGIN_DIRECTORY is a native-search-path of foo, not foo-brainfuck-plugin. If you install foo-brainfuck-plugin into a profile *without* foo, FOO_PLUGIN_DIRECTORY won't be set. <vivien_>nckx, that’s what I experienced with XML_CATALOG_FILES, but for XML_CATALOG_FILES, I would expect different independent programs to use that variable, without this consumer / provider distinction <nckx>Those ‘independent programs’ that use it should declare it. Unfortunately, there's currently no way for libraries like libxml2 to automatically ‘propagate’ their search-paths to every user of that library in a sane fashion. If there is a sane fashion. <nckx>Horrible hack to that effect in intel-vaapi-driver that I'm not proud of. <nckx>Well, ‘hacky practices defended in a comment’. <pkill9>qutebrowser needs python-adblock added :) <pkill9>now it has support for adblock lists <lfam>Great news, the Macchiatobin's GbE NIC works with linux-libre <lfam>I doubt the SFP NICs work, but we don't need them <bone-baboon>Previously I did not get errors when I ran `cabal new-build`. <pkill9>yea that's the method I'm talking about, the one that requires python-adblock <pkill9>yea i guess it needs to be added as a guix package <gnutec>Just a clue. openspade <-- I have to shutdown the audio but is great. <nckx>raghavgururajan: n-s-p usage *looks* good! <raghavgururajan>nckx: When I install both remmina and remmina:plugins, I don't see the variable when doing `env`. <raghavgururajan>I saw the gajim's `os.getenv` hack. But thats in python. Not sure what the glib equivalent. *raghavgururajan goes into the world-wide-web <nckx>raghavgururajan: The n-s-p works fine. As you've discovered in the meantime, REMMINA_RUNTIME_PLUGINDIR is a compile-time constant, not a supported environment variable. You'll have to add support for that yourself by patching the code and ideally getting that patch upstreamed. <nckx>Correction: you should write a patch to support a REMMINA_PLUGIN_PATH (colon-separated list of directories), not DIR, which limits users to a single plug-in directory for no good reason. <nckx>(Omit _RUNTIME_, environment variables are always run-time.) <pkill9>can anyone get musescore to play instruments? <pkill9>it can play metronome, but doesn't play the score <pkill9>is there something I need to do? <nckx>You could probably (ab)use g_find_program_in_path() here to avoid rolling your own, because the plug-ins happen to be executable 😈 <vivien_>Hi, I noticed I cannot use the guile web client when SSL_CERT_DIR is set to /run/current-system/profile/etc/ssl/certs:/run/current-system/profile/etc/ssl/certs (duplicated), but I can when it is set to /run/current-system/profile/etc/ssl/certs <vivien_>So if I happen to have nss-certs installed both globally and in my profile (or I sourced the profile too many times), the client is broken <vivien_>So either, SSL_CERT_DIR is not supposed to hold a path (i.e., dir names separated by :) or there’s a bug in guile <nckx>Neither. _DIR originally pointed to a directory (hence the name), then some common users extended it into a colon-separated path instead. It seems Guile didn't follow suit (yet). <nckx>* Or neither. Of course it's possible that Guile intended to support paths and fails horribly at it... <vivien_>I don’t know from where SSL_CERT_DIR is set to be honest, neither /etc/profile nor .guix-profile/etc/profile set it <vivien_>But wherever it is set, maybe it should replace the value and not colon-append the new one *nckx imagines a ‘whence’ command for environment variables. <mbakke>several Shepherd tests are failing with Guile 3.0.5 <nckx>That might surprise users used to being able to ‘stack’ environments. Dunno. I actually think teaching Guile to treat it as a path is the way of the future. <vldn>hi there :) how to add channels to my operating system config.scm and not have them in a seperate home folder file? <vivien_>vldn, you can use /etc/guix/channels.scm <nckx>‘guix edit gnome’, even :) <karthik[m]>nckx: oh, OK. It seems to very bug scm file & has lot of packages build code (I assume) at a first glance <nckx>No, the specific ‘gnome’ package at the top of your screen when you run that, not the entire file. <nckx>Guix's version of a meta-package is just some metadata and some propagated-inputs. *karthik[m] is trying to read the code <roptat>karthik[m], note in my case, it's not at the top of the file, but the pointer is at the right position. It's the block that starts with "(define-public gnome" <roptat>see how there's a name and version, but not source (#f), and the builder simply create an empty directory <nckx>Good point. I think it depends on your configured editor. <nckx>Guix ‘points’ it to the right line, how it deals with that is up to it. <karthik[m]>so, the CI builds every package independently from the gnome.scm source file ? <karthik[m]>But, still points to gnome.scm#package-name when when we use guix edit package-name <nckx>Well it *is* a package in its own right, just one that literally ‘installs’ an empty directory. <nckx>Then tells Guix ‘I need this stuff installed next to me’. <nckx>This stuff being all packages listed in propagated-inputs. <vagrantc>can you match newlines with (substitute* filename (("a\nb") "a\nc")) ? <vagrantc>or do i need to do a real patch to match across multiple lines? *raghavgururajan looks around for leoprikler <nckx>raghavgururajan: You'd use both, g_getenv to get the "/blah:/blooh" string value of REMMINA_PLUGIN_PATH, and g_find_program (or your own code) to actually look up the files in each directory. <apteryx>vagrantc: no, substitutes* is line-oriented <leoprikler>hum, REMMINA_PLUGIN_DIR seems to be a single directory <vagrantc>i've successfully *added* lines with (substitute* ... don't suppose there's another relatively simple option for monkey-patching across multiple lines? <raghavgururajan>nckx: I see. I think the project uses g_dir_open for looking up files. <leoprikler>so IIUC, they load plugins from their cmake installation directory <leoprikler>and by traditional distro voodoo you can put other stuff in there as well to extend it <raghavgururajan>So I am thinking, inbetween lines 318 and 319, we could use g_getenv(REMMINA_PLUGIN_PATH) then g_dir_open(REMMINA_PLUGIN_PATH). <raghavgururajan>That way, the upstreams option of using compile-time var is preserved at lines 316. <leoprikler>I'm not quite sure what you're trying to achieve here <nckx>raghavgururajan: No, I said g_find_program, not g_dir_open, because g_dir_open is of absolutely no use here. <leoprikler>if you want a real PATH variable instead of a simple DIR you need more code <leoprikler>you can't just substitute* that in, look at all the GUIX_environment_variable patches <raghavgururajan>> so IIUC, they load plugins from their cmake installation directory <nckx>And g_find_program was just to save you some effort because it would happen to work here. Feel free to reimplement your own, but then it's up to you to actually do so. <leoprikler>raghavgururajan: you have to look at those lines in tandem; they work together to achieve one thing <raghavgururajan>leoprikler: Yeah, I am looking to adding code via patch, not via substitute. <raghavgururajan>> you have to look at those lines in tandem; they work together to achieve one thing <raghavgururajan>Yes. cmake sets the value of REMMINA_RUNTIME_PLUGINDIR to the value of REMMINA_PLUGINDIR. The former is then used in remmina_plugin_manager.c <raghavgururajan>The v3 patch sets the EMMINA_PLUGINDIR to [plugins]/lib/remmina/plugins and removes setting of value for REMMINA_RUNTIME_PLUGINDIR. The latter var become NULL. *raghavgururajan looks at pidgin <efraim>how can I prevent a gexp from being garbage collected? <jlicht>efraim: symlink to it manually as a gcroot? <efraim>symlinking it to /var/guix/profiles/per-user/efraim/foo worked <pkill9>that's all you have to do efraim? just symlink it in that directory? nice <efraim>pkill9: I was hoping to be able to symlink it in $XDG_RUNTIME_DIR but without 'guix package -p' it's not protected <roptat>efraim, usually, it's /var/guix/gcroots (but that's owned by the root user, so maybe the per-user directory is more convenient) <apteryx>rekado: ah, directly in the generated html <efraim>I was hoping add-indirect-root would work <efraim>ok, I got add-indirect-root to work, when do things get removed from /var/guix/gcroots/auto? <efraim>ok, I think I got what I'm looking for with register-root and tmpnam <civodul>hmm "guix environment --ad-hoc texlive-tiny" fails for me (specifically the texlive configuration hook fails) <civodul>seems to be because texlive-configuration adds texlive-bin to the mix, which collides with texlive-tiny <apteryx>civodul: I just finished updating the release post draft <apteryx>Thanks for laying down most of its content! <nckx>efraim: Thank you for updating my Tor node 😊 <efraim>current error is "Unbound variable: %stowable-home-bits" when executing the script it creates <civodul>roptat: i wanted to suggest a change in the French translation, but Weblate told me "The translation has come to an end" <civodul>(typos, gender neutrality, and non-breakable spaces) <TheAsdfMan>Is there a way to change the /bin/sh symlink in the os definition? <civodul>TheAsdfMan: i think it's from extra-special-files <civodul>so you can use modify-services to change the config of special-files-service-type <civodul>apteryx: in the blog post there's a couple of items left: guix system image, GUIX_EXTENSIONS_PATH, and channel-with-substitutes-available <civodul>apteryx: if you can't take care of these, i can take a look tomorrow morning (my time) <apteryx>civodul: oh, I somehow fail to see that :-). I'll try to expand on these items too <apteryx>mhh, I could probably use your help for GUIX_EXTENSIONS_PATH though; I don't have much context w.r.t. what was the problem and how it got fixed. <apteryx>I'll try anyway! Probably be super generic and brief though ;-) <civodul>apteryx: it allows extensions of Guix, like the Guix Workflow Language (GWL), to "mesh" with the rest of Guix <civodul>does Guix Home use GUIX_EXTENSIONS_PATH? <apteryx>is there no Guix blog post on the image API? <civodul>yoctocell: but... does it work if you use it as a channel? <civodul>i forgot the details, but i thought new 'guix' commands would not be found <apteryx>is it OK to link to Mathieu's blog from the release blog article? <yoctocell>civodul: I am currently setting $GUILE_LOAD_PATH to my checkout of the rde git repo, but some people are using it as a channel <civodul>i think the command itself came after 1.2.0 <apteryx>so the only thing that changed is that we made use of it to replace the vm and disk-image actions of 'guix system', right? <civodul>ee2a5da80a9bda25542c00a7a35a9ddddcbd58af and e74baa124592428f05b17562f180469e405037f3 <ss2>hi! What does this error mean: guix offload: error: failed to connect over SSH to daemon at 'host', socket /var/guix/daemon-socket/socket? <ss2>Just had to reinstall my laptop again, and it now always fails to connect. <ss2>the signing keys haven't changed, and I can connect to the other host. guix offload status works too. <roptat>civodul, "the translation has come to an end" means you finished all the strings it had for you (if you do a search and translate the last sentence it found for instance) <roptat>civodul, so the suggestion is actually visible, thank you :) <bone-baboon>ss2: I get the same error when I try to do a guix copy. I am not sure what the solution is yet. <ss2>hm.. this is a fresh machine, and it simply fails.. <ss2>yes, both hosts are. <ss2>and ssh is working too. <ss2>the only difference is, that the client is a fresh install <ss2>and I copied the keys over, thinking I'd have littlest hassle possible. <ss2>I mean I took them over from the old installation. <nckx>This is a new bug in Guix. I wonder what changed. <apteryx>civodul: question: how do you post to a newsgroup like comp.lang.scheme (release.org) ? I have Gnus, but IIRC, I need a usenet server to be able to post to a usenet group (?). <nckx>...or whether it's client- or server-side... <ss2>I'll try to get avahi with publishing working then.. <nckx>Maybe 3270308? Just a guess. <nckx>That's a git commit, since it's suspiciously decimal :) <ss2>This is a new installation. I can't revert back. :/ <nckx>You can try pulling to commit dd14678b9b9843be20e2bbb98ceb30d2433dab82 and reconfigure. <nckx>ss2: guix pull --commit=dd14678b9b9843be20e2bbb98ceb30d2433dab82 <yoctocell>apteryx: I think you can just add `news.gwene.org' to `gnus-secondary-select-methods': (setq gnus-secondary-select-methods '((nntp "news.gwene.org"))) <ss2>*rolling back* and downgrading <ss2>huh? guix-daemon is offloading! <ss2>but me as user can't. <apteryx>does it make use of the GUIX_EXTENSIONS_PATH? <raghavgururajan>leoprikler: Do you know why `g_strjoin(testpath, "/", name);` inserts '/' at the beggining instead of between testpath and name? <nckx>This is not string-append ☺ *raghavgururajan tries concat <nckx>You're asking it to join "/" and name with the ‘separator‘ "testpath". <nckx>Why not just call g_strjoin correctly? g_strjoin("/", testpath, name). <civodul>apteryx: actually i stopped posting to newsgroups some time ago because servers would reject me or something <zimoun>apteryx, lfam, civodul: running “guix pull --branch-version-1.3.0 -p /tmp/foo”, I note that the spinner eats the final ’e’ of ’'check' phase’. <zimoun>and substitutable derivations seem missing. <zimoun>BTW, big thank you for the release! <ss2>nckx: thanks, that did the trick! <nckx>My slow lappy is still building, but glad to hear! <ss2>I'm so glad about the package distribution of avahi too. <apteryx>zimoun: I've noticed oddities with the spinner too <ss2>but I always have to reboot the daemon to activate discovery. <apteryx>it seems to cause my terminal to flash (but I'm not too sure as I use xterm with fastscroll on -- perhaps that's expected) <nckx>Either via the Web for or by mailing 48240 at debbugs.gnu.org. <zimoun>apteryx: thanks, I have not “recently” checked the bug tracker or the commits, so maybe it is already reported and fixed. Just to notice. :-) <bandali>hey zimoun, nice seeing you here again :-) <apteryx>civodul: I just pushed a new commit for the release blog post to guix-artwork, if you'd like to check <ss2>wow, this is so cool just to have everything available next door and you can fetch it for your local machine. :) <civodul>perhaps we should mention translations in the last section (or in the first one?) <nckx>raghavgururajan: I think so, but setting it to <subdirectory of /gnu/store/-remmina- that will never exist> will have the same (non-)effect. Do whatever's simplest. <nckx>If removing it makes your additions easier to follow, go ahead.