IRC channel logs

2024-10-18.log

back to list of logs

<yvs>gdb gave some more info: wayland crashed at adding screen
<yvs>#6 InitOutput (screen_info=screen_info@entry=0x636800 <screenInfo>, argc=argc@entry=17, argv=argv@entry=0x7fff8bca2f88) at ../xwayland-23.2.5/hw/xwayland/xwayland.c:435
<yvs>#5 FatalError (f=f@entry=0x58fb87 "Couldn't add screen\n") at ../xwayland-23.2.5/os/log.c:1017
<amano>I want guix shell --container to let me keep supplementary groups, pick a network namespace, filter dbus with xdg-dbus-proxy, and write application profiles.
<amano>xdg-dbus-proxy can probably run as a shepherd service in `guix develop` which is being developed?
<amano>Without granular control points, guix shell --container isn't useful for application sandboxing.
<amano>Right now, I may just run firejail outside guix shell --container.
<mange>Reading the manual, I feel like "guix shell" isn't intended to be a general purpose mechanism for sandboxing. It's a way to construct a temporary "software environment" (read: profile), and --container is a convenience for getting some sorts of programs working (e.g. with --emulate-fhs or --link-profile).
<mange>I'd be wary of adding too many options taking it in the direction of sandboxing. That seems like a different concern, which may be solved better with another tool (I'm not familiar with firejail, but plausibly that?).
<amano>guix shell --container only leaves you with necessary folders in /gnu/store. Firejail can't do that.
<amano>Apparmor can't do that...
<amano>I wish guix shell just restricts /gnu/store and leaves the rest to firejail.
<amano>guix requires its own sandboxing soution.
<amano>guix requires its own sandboxing solution.
<amano>I want guix to have its own sandboxing solution that can substitute for firejail and apparmor.
<amano>I don't let a web browser run artibrary code outside an application sandbox.
<amano>I don't let a web browser run arbitrary code outside an application sandbox.
<amano>Perhaps, somebody can write a guix software that creates apparmor profiles for guix.
<amano>or a guix software can write firejail profiles for other guix softwares.
<amano>However, it would be better for guix to have its own solution that's independent from apparmor and firejail.
<amano>Guix is just too unique for apparmor and firejail.
<amano>mange: --container drops supplementary groups which are required to make some things work.
<mange>Okay. I don't know anything about firejail, but based on a quick read I imagine it would be possible to write a firejail profile that would expose everything you need (e.g. exposing only necessary parts of /gnu/store).
<amano>How?
<amano>Firejail doesn't understand /gnu/store.
<amano>A guix software would have to write a firejail profile...
<amano>Guix understands /gnu/store.
<amano>That means a firejail profile for a guix package would be yet another guix package...?
<mange>Firejail understands lists of things to expose in the jail. You could write a firejail profile for the specific software you want to run.
<amano>I cannot know the paths to /gnu/store directories in advance. That has to come from guix itself.
<amano>A guix package for a firejail profile should be written for another guix package.
<amano>That means firejail profiles and apparmor profile have to come from guix packages....
<mange>Once you know what you want to run, you can get the paths. "guix build $package" will get you the path for the package, then "guix gc --references" can get you the rest (from memory... I might be wrong about which gc flag to use).
<mange>Sure, I'm saying "write a firejail profile for the specific software you want to run".
<amano>So, I have to change firejail profiles whenever the paths in /gnu/store change?
<amano>I don't want to manually write paths.
<mange>I have no idea how firejail works.
<amano>I would have to manually write `whitelist /gnu/store/xxxxxx-firefox-11.2` in a firejail profile if I write firejail profiles by hand.
<amano>That path will change over time.
<mange>You could write a script to call Guix to get the relevant paths, and then call firejail with the right file/arguments.
<amano>It's better for a guix package to dynamically generate a firejail profile....
<amano>mange: That is going to be slower than a pre-rendered firejail profile installed from a guix package.
<mange>Okay.
<amano>That said, guix shell --container should have an option to keep supplementary groups which are sometimes required.
<mange>The code for that is the function launch-environment/container in guix/scripts/environment.scm if you want to give it a shot.
<amano>I don't know how to write guile scheme. I don't really know the details of gnu guix. I just know surface concepts.
<amano>I'm only good at playing with concepts.
<amano>I already submitted an email about making guix shell --container keep supplementary groups to guix-dev mailing list.
<amano> https://lists.gnu.org/archive/html/guix-devel/2024-10/msg00050.html talks about adding an option to make guix shell --container keep suppelementary groups.
<amano> https://lists.gnu.org/archive/html/guix-devel/2024-10/msg00048.html talks about turning guix shell --container into an application sandboxing solution, but I found ways to make firejail and apparmor support gnu guix system.
<amano>With firejail and apparmor, I get application sandboxing.
<mange>Just to make sure I understand the situation: you can do what you want with firejail/apparmor, except for exposing directories in /gnu/store. I suggested a way to get the list of /gnu/store things to expose (which might be wrong - I haven't tried anything), and your response was "that will be slower".
<mange>It sounds, to me, like you have a choice of tradeoff: you can spend time learning Guile, or you can run something slower (which you can likely cache).
<mange>Or you can wait for someone else to implement your feature request, when they have the time and inclination.
<amano>mange: Calculating relevant /gnu/store directories in a script is slower. Writing those directories in a guix package is faster at runtime.
<amano>Pre-rendering saves time.
<amano>Many 3D engines let you pre-render things to save resources.
<amano>I said guix should pre-render those directories and save them in guix packages.
<amano>Making a run-time script calculate necessary /gnu/store directories is going to be slow.
<mange>Hence your trade off: you can have it "slow", but quickly based on the tools Guix already gives you; or you can have it "faster", but later (either from you learning Guile, or from someone else choosing to do it).
<amano>Both options require extensive knowledge of gnu guile and gnu guix.
<amano>I will have to wait anyway.
<amano>You don't understand how unintuitive gnu guix alrady is.
<amano>GUI is intuitive. API isn't.
<amano>It's easy to just click update button on mac os. It's insanely unintuitive to write a guix script for calculating necessary /gnu/store directories.
<amano>I just conceptually understand that it can be done. I don't know how I can do it, yet.
<amano>I'm just a king of concepts.
<amano>GNU guix forces you to become a part-time OS developer. OS development is convoluted and non-intuitive for people who are not developers.
<amano>If you want to do other things in life, perhaps mac os or PopOS.
<amano>Is it possible to trigger a service whenever there are changes in kernel arguments, kernel version, kernel config, initrd, firmware, and bootloader?
<amano>I want to run some guile code whenever there are such changes.
<civodul>Hello Guix!
<user_oreloznog>Good morning Guix!
<civodul>ACTION just reviewed the AppImage backend for ‘guix pack’
<civodul>cool stuff!
<dthompson>civodul: ohh??? news to me but I was wondering about this recently. exciting!
<civodul>it’s new! https://issues.guix.gnu.org/73842
<civodul>as in “not committed yet” :-)
<dthompson>this is cool!
<dthompson>the docs answered all the questions I had about how it works
<dthompson>very neat
<dthompson>I haven't had time but I have wanted to revisit making minimal bundles with guix, which would go nicely with an appimage packer
<civodul>oh yes
<dthompson>for a brief period of time, many years ago before the bitrot, I had a "normal" gcc that didn't do hardcoded store paths and I had my own small graph of C libraries + guile built with it so I could use guix to build stuff with the intention of shipping them to non-guix machines
<mehrad>This AppImage addition is amazingly cool and also handy
<dthompson>since the bitrot, I've gone the unfortunately standard route of building on a VM running the oldest supported ubuntu to minimize glibc incompatibility on unknown machines
<dthompson>would love to instead just have a small channel of guix packages built for this purpose using an older glibc
<mehrad>One of the burdens I've been dealing with some colleagues is that they don't want to install stuff with huge dependencies, and don't like docker either. This would make it much easier o give them executable binaries (yes, apptainer is there too :P )
<dthompson>guix packs are typically overinflated with a bunch of unnecessary stuff like documentation
<dthompson>making a more minimal one requires package transformation to strip away all the unnecessary parts
<civodul>yup! exactly my though
<civodul>*thought
<civodul>i starting fiddling with a package transformation on a train trip a while back
<civodul>but never got around to finishing it
<nikolar>i mean it would be nicer if the documentation was separate from the package proper
<civodul>dthompson: re shipping to non-Guix machines, -R should do the trick
<nikolar>so you don't have things like ffmpeg depending on inkscape
<civodul>(we use it a lot at work)
<nikolar>you're using guix at work?
<dthompson>civodul: yes but I don't want to ship the world :)
<civodul>oh you mean your packs would refer for ex. to the system libc?
<dthompson>yes
<civodul>ah yes, nice
<civodul>well, “handle with care” :-)
<dthompson>and guix is theoretically happy to help me there, I need a separate toolchain
<civodul>yeah
<dthompson>building on an old ubuntu vm works but... ugh
<dthompson>I don't want to do that
<apteryx>is it just me or the sudo method of TRAMP in Emacs (e.g.: C-x C-f /sudo::/var/log/messages) doesn't work? It seems to expect an SSH server listening on port 22.
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, roptat says: lieserl is back on 10.0.0.14, its wireguard service was down
<apteryx>roptat: thanks
<dthompson>building flatpaks with guix would also be handy
<civodul>roptat: yay, thanks!
<civodul>apteryx: “sudo:root@localhost:/…” works for me
<civodul>a bit verbose though
<old>^ documentation but also translation. You might need translation for your main software, but not all the dependencies if the goal is to ship a single software to end users
<apteryx>civodul: thanks for checking; I guess I used to have a local ssh allowing root user for the /ssh:: shortcut to work. Odd! Thank you.
<apteryx>civodul: hm, still failing for me: Tramp: Opening connection nil for root@localhost using sudo...failed
<apteryx>in the *Messages* buffer I also see: Tramp: ‘getconf PATH’ not successful, using default value "/bin:/usr/bin".
<civodul>uh
<civodul>i think i have glibc in my profile, that’s why :-)
<civodul>(for ‘getconf’)
<civodul>we should change Tramp’s default PATH
<civodul>i thought we already did
<apteryx>I also have 'getconf' available in my environment
<apteryx>I think the TRAMP paths must remain unpatched otherwise it breaks when accessing foreign distribution over SSH, if I recall correctly
<apteryx>although it was refined to have both local paths and remote paths in recent versions, so maybe that's no longer true (for the local paths)
<apteryx>(that's all on the top of my head without rechecking the facts, so take it with a big grain of salt)
<apteryx>question to GNOME users: is the screensaver/sleep feature always reliable for you? In my case, there are (relatively) rare occurrences where it won't enable even when I'm not touching the PC, and if I'm not careful the monitor may remain active for hours.
<apteryx>I've learned to physically turn off my monitor to avoid burn in, but that's suboptimal ;-)
<apteryx>in fact, that was already the case with my old ratpoison + Xorg environment (now on GNOME/Wayland), so perhaps that's a larger issue than just the screensaver feature in GNOME.
<omniscient>Hey I'm super new to guix. Been test driving it as a package manager on debian and trying to get shepherd working running as a regular user. Kinda curious, what exactly is guix pull doing when you first run it that takes so long?
<mehrad>It will download the latest guix as far as I understand it. My suggestion is to also provide `--cores=$(nproc --ignore 1)` to use the most our of your time
<mehrad>and to my limited understanding, you need to do `guix upgrade` to upgrade the software you have installed with Guix. That also accepts --core
<mehrad>My suggestion: wait until someone else confirms or rejects my understanding :)
<Rutherther>omniscient: there is a couple of things that takes up time. Mainly the build itself that sometimes can happen if the substitutes are not yet available. This can be quite common if there was a commit recently
<omniscient>Ah okay. I'll try the --cores directive next time!
<Rutherther>mehrad: that upgrade is for packages you install with guix install, but if you were using something like guix-home, or guix system, it's appropriate to use their methods, ie. guix home reconfigure
<Rutherther>guix pull just pulls the guix itself - new package declarations, and commands
<dariqq>civodul: just sent a v2 where i added a simple test for which I adapted my example with privileging hello (also i am bad at naming things so everything is called hello). Also decided to add a case for chowning files for new accounts which also requries that the account creating script has run before it.
<dariqq>When run on current master the test machine fails to boot with : 'In procedure getpw: entry not found' (which is from the privileging script trying to find the not yet existing user)
<getstate>Is there an on-going attempt at updating tree-sitter & neovim?
<getstate>Would like to work on a patch, I'm guessing I have to also update the tree-sitter grammars?
<Rutherther>getstate: yeah the grammars would also have to be updated. There is a pending patch, but it's outdated now
<apteryx>ugh, emacs-elpy is broken again (test suite)
<rynn>So I installed emacs-gruvbox-theme, but it doesn't show up under customize themes. Is there something extra that needs to be done in order for it to be usable?
<Rutherther>rynn: do you have emacs installed in the same profile?
<Rutherther>rynn: also of course you need to load it (require / use-package etc) in emacs, just installing it with guix makes it available for emacs to use.
<rynn>Oh, I see. I'm really new to emacs, so it's been a learning curve.
<Rutherther>rynn: I would recommend use-package tbh, it's quite nice to setup packages with that generally. For themes it's no big deal, but for other packages it has nice stuff like deferring load of package (speeds up open time), customizing variables of the package, executing code after it loads and stuff like that. It's built into emacs.
<rynn>Thanks Rutherther, I'm using the GUI emacs to learn and was able to find it after some digging; I installed the package and after restarting emacs I was able to see and enable it.
<civodul>ACTION reconfigures lieserl
<getstate>Rutherther: Thanks, will try to get something submitted soon.
<silicius>welp it finally happened, telegram-desktop started segfaulting
<noe>civodul: thanks !
<noe>Looking into PackageKit integration now, I will see if its not too hard to do
<shcv>hello; how do I force certbot to run? I tried to add a configuration for a new subdomain, but it doesn't seem to have done anything yet
<nckhexen>shcv: A very hacky answer: 'sudo herd schedule mcron', then run the certbot command there (as root).
<Rutherther>if I wanted to contribute theme package to guix that has multiple variants, what is the idiomatic way to package it? for my own channel I made it a function, see https://git.ditigal.xyz/~ruther/guix-exprs/tree/main/item/ruther/home/packages/themes.scm#L20
<silicius>multiple outputs maybe
<Rutherther>I don't think building 60 outputs makes sense when everyone will realistically use just one
<oriansj>well there is: https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html
<ieure>Rutherther, I agree with your approach.
<silicius>only one of them is build at a time, but 60 is a lot to show on guix show
<Rutherther>oriansj: I am asking for currently possible solutions
<Rutherther>silicius: all outputs are built when the package is built
<Rutherther>ieure: I will try to submit it to guix-patches soon and see what others think
<ieure>Rutherther, I don't think there's "an idiomatic way" to do this, because it's a pretty niche need which most packages simply don't have.
<ieure>Rutherther, Where it is as configurable as what you have there, I agree with what you've done -- perhaps with the addition of one package using the defaults, which mentions that you can customize it.
<silicius>Rutherther: that's crazy, the documentation claims it saves space. So is every other output discarted?
<Rutherther>silicius: yes, the outputs can be discarded
<Rutherther>but you cannot build just one output if the package has more. That is due to the way it works - you have just one definition of the package build process, and you copy the build results to different output locations after you collect the stuff to put there. The outputs that do not have gc roots will be garbage collected.
<silicius>Never realized that, though I used it before a couple of times
<silicius>I like the parameterized packages idea
<Rutherther>it's quite nice. Unfortunately seems the author has not communicated for months after sending it to the guix devel list for discussing improvements
<silicius>from the author's blog: "I worked on Parameterized Packages as a GSoC intern at GNU Guix." past tense and doing it for gsoc tells me there might be no more updates
<silicius>No, I take it back. He;s still active and keeping the love for scheme on multiple sites of his
<shcv>nckhexen: honestly, that's almost what I did; I reverse-engineered the command from the certbot logs, but that looks easier