<Apteryx>Is is tormal that 'xfontsel' doesn't find any font?
<Apteryx>Probably. It's so old, it must be looking for fonts in another format (1989).
<Apteryx>I'd like to try the "terminus" font in Xterm, but haven't been able to figure out how to configure my .Xresources file's XTerm*font parameter. I always get a message: couldn't find the font terminus
<Apteryx>I'm not setup with a git checkout yet, so I'm copying the freedesktop.scm file the udisks package is defined in in my ~/devel, making the changes to it (Emacs), and then how would I test an install of it? I thought "guix package -f freedesktop.scm", but I'd like to select just the "udisks" package of the freedestop.scm file?
<Digit>things have been going wrong for me here in my devuan. ... it may please some of you to know, that in this panicked alarmed state of "oh no, it's gonna die", it's GuixSD i find myself reaching for. :)
<rekado>Digit: have you been using Guix on top of Devuan so far?
<Digit>i had been using GuixSD prior. i do have Guix installed on this devuan and have used it for a small handful of packages.
<Digit>this was kinda unexpected for me. i didnt realise GuixSD had become my "go-to" distro.
<Digit>:/ hrm. "ping: unknown host", tried setting up wired connection. what does one do when this happens? the install documentation doesnt cover this. i was using the connection minutes ago on that machine using an old pendrive os, so it should work.
<civodul>different number, but it's probably similar
<Digit>o_O curious and curiouser. just as i was starting to suspect my change of isp... while running through this from a fresh reboot, now instead of ping returning just the one line "ping: unknown host", it "works", 3 packets transmitted, but 0 packets received. *scratches head further*
<Digit>oops, forgot the .org that time. lol. works. idk wth i could have done wrong first time. excuse my pebkac bilge.
<Digit>only thing different i did, afaict, was use a different usb port. o_O
<davexunit>civodul: so does this break call-with-container completely on newer kernels?
<civodul>davexunit: no, not at all; it's just that 'pivot-root' test that relies on this behavior
<civodul>so in a way, we don't seem to have a "use case"
<davexunit>all guix needs to do is make a bunch of bind mounts from /gnu/store into the container file system.
<Digit>ACTION wondering how necessary xfce-desktop-service (or some such) is, but doesnt want the bloat... usually happy without any DE, oft just using slim login manager... unsure how to configure initially
<catern>davexunit: right, but then you can just copy that result out
<davexunit>Apteryx: the store has nothing to do with it
<davexunit>the guix code itself has all of the information needed to compute the hash
<davexunit>the store is merely a place to store the results of actually building these things
<Apteryx>So, suppose I have package C depending on package python-2, and I already have /gnu/store/83er...-python-2 in my store. Will it use that one, or will it use whatever the db of guix currently holds (Which is refreshed with `guix pull`) ?
<Apteryx>So when a package requires an input, guix doesn't care about a specific hash for that input. But the inputs hashes will go into the computed hash obtained for the package being installed. for the bpackage
<catern>if I performed a binary installation of Guix, how would I update the daemon?
<catern>I assume I would need root to update the daemon?
<rekado>catern: the big difference is that Guix is a library. If you can think of just one case where this might be useful go with Guix.
<rekado>catern: the daemon runs as root, so although you don’t need root to build it (just do “guix pull”) you need root to start the new daemon.
<catern>don't I also need root to point root's profile at the new updated daemon?
<catern>my question ultimately boils down to this: if my method of installing Guix is with a Debian package and no other use of privileges, I'll need another updated Debian package to update Guix. right?
<catern>well... I guess that's true. perhaps my "updated package" then would just perform a "guix pull" as root, restart the daemon, and nothing else
<rekado>catern: you can have regular user who does “guix pull” and set up the service such that it uses that user’s daemon.
<rekado>catern: I’m not saying this to recommend this approach, but it shows that you don’t need root to update the daemon.
<catern>rekado: hmm, but restarting the daemon would still need root I guess, if you want it to be run with systemd/sysvinit/whatever
<catern>(although you could always restart the whole box...)
<rekado>Right, as the daemon runs as root and the systemd runs as root you’d need root to restart it.
<catern>rekado: is there something wrong with the approach of having a dedicated user, whose profile you run the daemon out of? that seems like a pretty good way to do it, then you don't need root to update the daemon, you just need access to that user
<janneke>aaarghhh: at the very end guile/gnu build system says: WARNING: 'makeinfo' is missing on your system.
<Exagone313>Hi, I'm reading parts of GNU Guix manual, it seems an interesting approach to have that per-user basis. I have a question about it, about network-based accounts, in an enterprise or school. Users are commonly not advanced, and administrators want users to use the latest version of software for security reason. Also, having multiple versions of the same tool (let's say of the same major version) makes
<Exagone313>potentially excess use of space. Is there something about that use-case?