IRC channel logs
2025-06-27.log
back to list of logs
<ieure>Is there a Guix Home equivalent of `guix package -I'? <ieure>I would like to see the specific versions of packages installed in different home generations. <ieure>Okay, I see, `guix home describe --list-installed' <meaty>what's a good program to fill in PDF forms? <hlp>hello, I am trying to build a Guix package for a finalized SRFI that doesn't have an existing definition. I cannot get the package to compile with guild due to my lack of familiarity with how the SRFI code is structured. Are there any write-ups on how this works? <bavier>meaty: Gnome's Evince usually fills in PDF forms well for me. <dtx>when using "guix shell" when should I use -f vs -m ? They seem like they accomplish the same thing? <ieure>dtx, Similar, but different. `guix shell -m' lets you reproduce some other environment, ex. one created with `guix package --export-manifest'. `guix shell -f' lets you create a shell with arbitrary packages, including ones defined in the provided file. <ieure>Unless you're doing arbitrary-package stuff, probably easier to write a manifest and use that. <dtx>is there a way to define environment variables inside of the guix shell from manifest.scm? I would like to append to PATH but not wipe out what's there, and I want to call commands in the shell directly not just open up a subshell in it. <dtx>in a container shell I mean <ieure>dtx, I'm not aware of any facility which lets you define environment variables from either a manifest or a file of packages. You can use --preserve / --expose to set environment variables from the parent shell in the container, but you can't append to the $PATH the shell creates. <ieure>dtx, This sort of thing is generally unnecessary, since `guix shell' is designed to run guix-packaged software, and any packages available in the subshell get put on $PATH automatically. <reepca>two things I have learned today: 1. in 2025, glibc still uses socketcall on x86 unless explicitly configured to assume a kernel newer than 4.3 2. strace will lie about this and pretend it's using whatever the multiplexed system call is instead <reepca>looks like glibc by default doesn't assume any kernel features newer than 3.2.0 <reepca>I had assumed that it would be designed to first try the dedicated system call, and then if that returns ENOSYS, fall back to socketcall <untrusem>dtx: I also had to use php for a project, but it seems no one does php in guix, resources are very scarce on php <janneke>ACTION works to trying to resurrect cross build of guix [to the hurd] <janneke>adding a guix-for-build to the guix package... <Noisytoot>guix pull: error: aborting update of channel 'guix' to commit bc3ce40ee72d10e180afd32786d6b5fc7ad02dfd, which is not a descendant of ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <Noisytoot>hint: This could indicate that the channel has been tampered with and is trying to force a roll-back, preventing you from getting the latest updates. If you think this is not the case, explicitly allow <mange>There was a commit accidentally pushed to Savannah after the Codeberg migration. I think you can either allow downgrades, or you can "guix pull --rollback" then "guix pull" again. <janneke>yay, by guix-for-build guix-1.4.0-39.837ddb0 finally built...now seeing if the hurd cross build fix actually works... <janneke>hmm; build: Do not generate 'CODEOWNERS' when cross-compiling. <janneke>that's also a "solution" of course... <janneke>oh welll, why not; probably better than my configure/make/guix guix-for-build work <janneke>it would be nice if they would align things on irc... :( <civodul>oh you were also working on fixing this? <z572>janneke: I think we should communicate under codeberg's issues, such as setting "Assign to me". Since no one was going to fix this problem, I went to fix it <janneke>civodul: yeah, someone advised me to reconfigure asap...but i my childhurd's don't build yet <janneke>z572: ah, there already was a bug opened for this...my bad then <janneke>ACTION hasn't really gotten into the codeberg thingy <janneke>ACTION agrees that aligning on irc can only be a courtesy and hardly be mandadet...but it used to work pretty beautifully before, most of the time... <z572>janneke: I think it's mainly because our time zones are different. It's 4 p.m. here now. :) <janneke>z572: yeah, that probably also makes alignment more interesting :) <janneke>i've just pushed a guix package update so that it may actually be effectuated for a system reconfigure <z572>i think a idea is add a page on guix.gnu.org about current gcd status? <futurile>z572: yeah, Noe has worked on something, I think they're close to being able to do that <civodul>we could have it at consensus.guix.gnu.org <z572>I'm very glad to know this <z572>maybe add a WIP pr to #guix/artwork? It has always been very difficult for me to search for content in irc <z572>daemon: conditionally disable seccomp filter on socketcall systems <noe>We can transfer it to Guix <noe>civodul, if we set the gcd frontend on Guix infrastructure how do I update the site? Would I need to ask every time for someone to push the changes? <futurile>noe: you'd be added to the infrastructure repo (or website one) so you could push updates <yelninei>janneke: thanks for the libgit2 revert and the guix update. Also cross compiling guix should now be a lot faster and it is not taking 30mins to translate the manuals <untrusem>How do we folks use guix shell? I mainly use it to open program like librewolf, keepassxc etc. <untrusem>What would be the benefit of them opening in guix shell rather than using them in a home manager? <futurile>untrusem: if you're concerned about security then guix shell isn't really designed for that. It might provide a bit of protection since you can limit what apps can see. But, it's not a security tool like some of the others out there <futurile>guess it depends on how secure you want to be <untrusem>One advantage I see of that is that their updates won't hinder reconfiguring update when we have no substitue <ieure>untrusem, I use guix shell for developing guix itself, for testing packages I write, for running software I use infrequently enough that I don't want to install it. <ieure>untrusem, I wouldn't use it for programs I use every day, since it makes the startup slower and much more variable. <untrusem>i see, So it's not isolating like flat back <futurile>untrusem: correct - I think it would be fair to say that Flatpak was designed with isolation in mind. I assume someone in RedHat / SUSE has looked at it reasonably deeply. <futurile>untrusem: whereas guix shell was/is really designed for running an application easily - technically it's not a security tool <untrusem>Can we have a security related program based on geeks? <futurile>untrusem: honestly, I think people go off the deep end iwth regards to security, so I'm personally comfortable using guix shell and I actually don't limit my browser <untrusem>futurile: I see, the reason being I am very fascinated by qubes <futurile>untrusem: we could if someone was willing to do the work - they're both using the same underlying Linux tech (namespaces etc) <untrusem>so it was either qubes or guix for my thinkpad t480 and I chose guix :) <futurile>untrusem: yup, qubes is a nice idea - I read their web pages, I just haven't spent any time on them myself. <futurile>untrusem: I loosely looked into integrating bubblewrap or one of the security systems into Guix and decided I wouldn't be in it for the long-haul <futurile>untrusem: funnily enough it wasn't something that could be done on a Friday afternoon over a cup of tea and a biscuit heh heh heh <ieure>Qubes is a cool idea that really doesn't fit how I like to use the computer at all. <futurile>do you run any of your apps jailed in some way ieure? <untrusem>ieure, qubes is very cool thought, but would need a hefty machine <untrusem>it doesn't very much with permacomputing.net <futurile>yeah landrun looked nice from an hour of browsing <identity>running everything in a vm sounds like a bad idea unless you have a lot of ram and do not know what to do with it <ieure>Well, I assume they're using built-in namespaces to run programs directly, which is about as lightweight as you can get for this sort of thing. <ieure>It seems like a fine tradeoff for those who want the strong isolation it offers. <reepca>having "a lot of ram and not knowing what to do with it" actually prompted a rather funny thought experiment <ieure>Just a taste thing, but I prefer the big blob of junk where all the bits can talk to each other. <reepca>which is cheaper on resources: running modern software bare metal or running software from 2005 in a vm? <janneke>yelninei: yw, hope it helps. trying to build both guix's at the moment as it seems the build farm hasn't picked/caught up yet? <identity>ieure: Qubes runs on Xen, which is essentially a bare-metal VM manager; you can run whatever OS under that, Debian, Fedora, windows, whatever <identity>(including multiple of them under any combination at the same time, if that was not clear) <ruther>wondering what a good way to not crash services when compositor exits... currently it kills my session. Should I not use exec and let bash be the managing process, or are there better ways with elogind? Seems that simple enable-linger doesn't allow persisting shepherd, shepherd is still killed <futurile>viaken: yes, I think firejail is still around. When I searched firejail, bubblewrap and landrun were all mentioned - it was difficult to tell which one(s) were best or most integratable <jakef>civodul: i nominated you to review a PR updating insight-toolkit because image-processing.scm doesn't have a team, and i saw that you and Ricardo are the ones who've contributed to ITK. not meaning to come across as impatient; there's no urgency whatsoever