IRC channel logs
2023-08-03.log
back to list of logs
<nckx>bdju: When you're fat & sassy, could you verify that at least this works for you: guix shell --pure dbus gdk-pixbuf {adwaita,hicolor}-icon-theme python{-axolotl,} gajim{-omemo,} -- gajim <nckx>If that works, and it really should, then installing all four python{-axolotl,} gajim{-omemo,} to your manifest should really work, too. <bdju>nckx: sorry for bad timing, but it does work with that guix shell command. omemo seems to be enabled when it launches. I will experiment a bit more I guess <bdju>will start by reapplying my manifest <bdju>same issue. I guess there's something in my environment messing it up <bdju>darn. I moved the plugins dir elsewhere in case I had bad stuff there messing with it. no change <ChocolettePalett>Nevermind, it doesn't comply with GNU Guix specifications (impossible to do) <ChocolettePalett>Nevermind x2, it now seems obvious how to do this after learning about "ungexp" <nckx>bdju: Is GUIX_PYTHONPATH set to something containing within it python-axolotl? <futurile>Q: is there some way you can do a guix pull to get an earlier version of Guix - I was thinking something like --commit=HEAD~3 <futurile>It's a pain finding the commit has from the guix repository <futurile>I'm really trying to find a way to do a guix pull to a version that has the substitutions built <cbaines>futurile, what substitutes are you currently missing? <bdju>nckx: oh, I'm starting to get an idea of what the problem might be. that variable has pathes in it with python3.9 as a directory but when I go looking in ~/.guix-profile/lib, it's not there, I have a python3.10 directory instead <bdju>so I'm guessing a reboot or maybe logout/login would fix that but is there any other way? <bdju>ulfvonbelow: thanks! that works. I usually like to launch it from bemenu, but at least for now I can do this until I feel like rebooting again <nckx>But Guix should have told you to do that. 🤔 <bdju>maybe it did at some point <bdju>if it's that message that always appears after you install stuff I would've just ignored it <bdju>I remember being misled at one point into puting a bunch of env vars in my .profile because of that post-install message <nckx>I'll never understand doing either of those. <bjorn3[m]>Is it expected that in the QEMU Image version guix system reconfigure takes several minutes to compute the guix derivation? <nckx>You've miffed me into adding 'in the current shell' to that message but ignoring it remains at ones peril. <nckx>Maybe an ASCII skull would convey the latter. A tasteful one. <cbaines>futurile, I think there should be a substitute for that, at least for x86_64-linux <next4th>cbaines: hi, can you help to create a kde-updates job on CI? z572 had confirm plasma packages and the desktop service working fine, and i think it's in a good shape. <nckx>Vieta[m]11111114: Any idea why you, in particular, are cursed? Other Matrix users on the same bridge are (by its standards) fine. <nckx>But you keep joining and parting in a glorious loop. <nckx>That would be more interesting than the truth, which is extremely buggy software. <nckx>That's the root cause—I just thought perhaps Vieta was doing something extra special that made them the target of one more bug. <cfields>I haven't seen any activity/patches for llvm16, which has been out for a while. Would patches be welcome, or is someone working on that already? <apteryx>hm, the elogind-updates branch looks fine for x86_64; should I build it for powerpc64le and aarch64 as well? <janneke>do we have a nice way yet to compute a `guix hash -rx' for a specific commit? <lispmacs[work]>hi, I have this problem where if I try to build something with Guix that requires a lot of memory, sometimes the build will get killed, but sometime instead Gnome will just crash <ieure>This is a "doctor, it hurts when I do this" problem. <ieure>Simplest thing other than not building large things during your workday is to add swap, or increase the amount you have. <ieure>The Linux kernel's OOM killer is what decides which process to kill in an OOM situation, it's outside Guix's control, and has no way of knowing which thing *you* would prefer to get killed. So it's common for the "wrong" thing to get killed in these circumstances. <attila_lendvai>but you can configure the earlyoom-service-type with a prefer-regexp parameter. it behaves much better than the kernel OOM killer (kills before exessive thrashing on the disk). <attila_lendvai>swap makes the kernel OOM killer only slightly better in that you have a few more seconds to close something before the machine locks up <mirai>apteryx: could you mail me your rebased docbook branch? (I think its just one patch that needed to be rebased) <mirai>I did a rebase on my end but I think I might have missed some finer changes <vagrantc>janneke: beyond the obvious of checkout out the repository and running 'guix hash -rx' on it? :) <vagrantc>janneke: i presume you mean something like guix download, but with git support? <janneke>vagrantc: something like guix hash -rx --commit=abcd <vagrantc>but with a different commit from the checkout? <samplet>The script would have to create a temporary checkout. You can get the Git directory hash with ‘git rev-parse COMMIT:’, but there’s no way to make a nar hash from that. <janneke>i was thinking guile-git / libgit or something <vagrantc>i have often felt the dance a little silly to ... git fetch && git merge && git tag -l && git checkout SOMETAG && guix hash -rx . <vagrantc>something that shortened that chain would be welcome :) <vagrantc>although i often do git diff between that and the previous version or some such just as a quick eyeball of code sanity or license updates or whatnot <podiki>(now connecting via heisenbridge, run locally) <podiki>(wasn't able to send via matrix to irc yesterday/today so bit the bullet and spent 5 minutes setting up locally) <nckx>Apparently, Matrix → IRC is just broken at this time. Or at least it is for most people. It's bad. <podiki>if i understand correctly this is just a local bouncer and i'm hoping is more reliable, or at least I can debug/restart <nckx>ACTION clarifies: EMS Matrix bridge → Libera.chat IRC is broken. The abstract concept is not, unless you want to get snarky. <podiki>i have to say, heisenbridge was super easy: one command to generate registration, add it/restart synapse, run heisenberg, and then just connect <nckx>Good to know. If EMS doesn't get their junk together, I might consider setting up our own bridge. <podiki>back to guix: i've noticed sometimes we don't package example configurations (e.g. alacritty's which i have a local patch for now); i'm assuming generally we would in docs and this is an oversight? <podiki>I'll keep you updated how this heisenbridge fares <nckx>‘Oversight’s a bit strong but I'm a proponent of including them. Either in /etc or in /share/doc. <podiki>nckx: actually tried to PM you earlier but maybe that never went through either <podiki>i also like having them instead of trying to dig it out of e.g. github (especially if it is generated through building) <podiki>I'll submit my patch rather than just push it anyway <nckx>How much earlier? Your last PM I can find is from July 20th. <nckx>You'll have to resend anything newer, sorry. <podiki>< 3 hours ago. it's okay, it is out of date now that I gave up on the matrix/irc plumbing for now <nckx>It never arrived, through either channel (I happen to have Element open but never count on that). <podiki>i guess it goes through the ems/libera bridge? not sure how that is handled going forward <nckx>What a mess. The near-collapse of the Matrix bridge is not a consequence of the deportalling and the move to plumbed rooms (it's the opposite), but good luck convincing innocent bystanders of that. <nckx>podiki: If you were PM'ing me through your ‘old’ podiki[m] account, yes, that would likely have got stuck in the bridge. <podiki>and the whole EMS mess ends up reflecting badly on Matrix as a protocol/ecosystem <nckx>podiki: PM received! \o/ <nckx>podiki: I don't mean to sound mean, but I hope it does, because that's at least fair. Casual users just as easily blame Libera, partially due to Matrix's own propa^Wmessaging of IRC as a ‘legacy’ protocol and Matrix as ‘modern’. Libera has been the stable network throughout all this. A replacement that adds emojo support and gifs but *can't deliver messages* isn't one. <nckx>I'm sorry. This is an off-topic rant brought on by recent events. I apologise. <podiki>no, I hear you, and I think there's well deserved criticism here (i know it can't be as easy as it seems on the outside, but still, really? can't properly interact with irc? in 2023?) <podiki>no apology necessary and thanks for helping out on all this <bjc>anyone have any advice for managing a local branch which incorporates a good half-dozen or so pending patches that need to be rebased periodically? <bjc>right now i rebase all my patch branches, reset ‘master’ to ‘origin/master’ and merge them all in, but it's a real pain and error-prone <podiki>you mean you don't just have one branch with all the patches and rebase that branch? <bjc>if i did that then that branch's patches would get out of sync with the feature branches <bjc>sometimes i need to update them due to conflicts or mistakes <bjc>but that is what i'm shooting for, just with less headache than i currently have <podiki>beyond my git skills, but did see there is multi branch rebase in git using --update-refs if that helps <bjc>yeah, i think that's just for when you have a branch B which is rooted on A, and A is rooted on master. when you rebase A onto the new master, it will update B's root to the new A when you use ‘--update-refs’ <bjc>at least, that was my reading <bjc>most of my branches are independent, though, so it doesn't work for me <t400[m]><t400[m]> "Does guix do anything that might..." <- Quick update to this, Intellij IDEA runs great on the Guix live image running with QEMU. One step closer to feeling confident to install Guix on my main work computer…. <RavenJoad>Can the size of the overlay file system that is created by a system image be increased? <podiki>Guest28: no, if you don't put in inputs it uses the inherited packages; you can also add/remove/replace from input lists <Guest28>podiki: Ah perfect thanks. Is there something for phases as well? <podiki>Guest28: yes, you can modify-phases on the inherited ones; let me see if i have a quick example <podiki>look for substitute-keyword-arguments <Guest28>With that, I can reuse the original phases and need only add my phase? <RavenJoad>podiki: That did not work. I am using an ISO and uploading it to a VM on proxmox to test Cuirass. Inside the VM, the / overlay fs has 4GiB. Using --image-size did not change that. <podiki>Guest28: yes, you can modif-phases #$phases and just add your new phase for example <Guest28>podiki: Awesome. Makes it way more clean. Thanks for the fast help <podiki>RavenJoad: you can't use a guix system vm directly? not sure, sorry, haven't played with that much but would have thought image-size is what you want :-| <RavenJoad>Maybe. I need to check, because Cuirass was a little funky with a system VM last I checked. <Altadil>Hi, does someone have experience with usb passthrough in gnome-boxes ? Is there something specific to Guix that needs to be done ? My USB device is listed but trying to enable it does not work. <RavenJoad>podiki: The problem is because Cuirass in a system vm wants to create a lock file in /gnu/store, which is read-only.