IRC channel logs


back to list of logs

<nckx>Ugh. Gthings.
<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.
<nckx>ACTION → 😴💤
<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>I have a rather simple question about GNU MCron. To specify execution time of a task, I'm considering to do this:... (full message at <>)
<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"
<apteryx>is someone using wireguard here?
<ulfvonbe`>yes but not using wireguard-service-type
<ulfvonbe`>and only for a server in a container
<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?
<ulfvonbelow>. ~/.guix-profile/etc/profile ?
<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.
<futurile>cbaines: looks like it is python-wxpython -
<cbaines>futurile, I think there should be a substitute for that, at least for x86_64-linux
<cbaines>bordeaux has yet to build the latest revision but I think that's available from ci
<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.
<ChocolettePalett>Must be hackers or DDoS
<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.
<attila_lendvai>for someone from the python team: (fixes for python-daemon and Trezor support)
<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?
<nckx>Patches are welcome.
<cfields>nckx: thanks.
<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
<lispmacs[work]>or freeze up, rather
<lispmacs[work]>having Gnome crash in the middle of my workday is not fun
<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>janneke: from a git checkout?
<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>hi guix!
<vagrantc>ACTION waves
<podiki>(now connecting via heisenbridge, run locally)
<nckx>Still on a potato?
<podiki>(wasn't able to send via matrix to irc yesterday/today so bit the bullet and spent 5 minutes setting up locally)
<podiki>yes, on the Pi :-)
<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 → 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>< 3 : 3
<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
<podiki>I see
<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….
<Guest28>, does that mean if I need to add an package, i need to copy over all inputs?
<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
<podiki>RavenJoad: --image-size maybe?
<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
<podiki>here's a random one:
<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.