IRC channel logs
2023-03-05.log
back to list of logs
<rekado>civodul: a few months ago we tried to upgrade all the hurd things, but we had to give up because it was too difficult to figure out what set of unreleased packages were supposed to work together. <rekado>IIRC this was all started with an innocent looking patch to upgrade one of the hurd packages <rekado>the const thing doesn’t sound familiar, but the lack of releases or known-to-work checkpoints is a familiar refrain <jab>rekado: what hurd things need to be updated? <civodul>rekado: yeah, lack of releases is terrible; there are tags in the mig repo, and you can guess they're used as the basic for Debian <bjc>reading about the hurd always makes me depressed. i remember installing it on my 486 in the 90s and it seems like it's made precious little progress since then <bjc>it's such a neat idea <Guest48>I thought it wouldn't be a big deal to get Guix running, but I've been fighting issues with grub and the encrypted disk since I came back to fiddling. <Guest48>Tried CSM mode, tried a bunch of things. Grub just sits there after I type the passphrase. <bjc>hmm. at some point ‘doas guix system reconfigure’ started failing because now git needs ‘safe.directory’. using ‘sudo -E’ works, but bare sudo doesn't <cel7t>should the port-encoding of tty be UTF-8? <jab>Guest48: I personally have to use a number only password for grub. <jab>my keyboard layout makes it hard. <jab>bjc: I did just get the Hurd running on a T46 (I think). It is running just the base OS. And the bug-hurd mailing list has gotten a lot of activity recently. <cel7t>Is it possible to get Guix to expose a REPL? <cel7t>I'd like to make and test out tiny changes to Guix and a REPL, or the ability to get it to evaluate tiny bits of scheme code would be a very nice way to get that done <mirai>its not guaranteed to work with all of the code you write <mirai>but it should be enough to evaluate some snippets <cel7t>Yep. What's the usual way that developers work on Guix, by the way? <NewUser-Basic-Qu>Hi all. Am new to GUIX. Installed it in a VM. Trying to get familiar with it. Is there a simple way to see why my system is the way it is. For example typing guix edit <some-package> opens an editor with nano. Where is nano defined? is it a system setting? <jab>I personally never understood the purpose of guix edit...suppose you run "guix edit emacs". Can you save the resulting changes? <oriansj>aaaa_bbbb: qemu works quite well; virtualbox however is not packaged <iyzsong[m]>jab: in a checkout, with 'pre-inst-env guix edit' it can <NewUser-Basic-Qu>the_tubular If i understand it correctly then %base-packages only defines that nano is part of the system/world...whatever...that it is present at all but i don't get it why a command like "guix edit <somepackage>" opens automatically with nano...where is it defined that nano is used for the task? <the_tubular>I'm not sure, but it probably is define by your $EDITOR <next4th>NewUser-Basic-Qu: it's defined in guix/guix/scripts/edit.scm as '%editor' <winter>efraim: Do you mind explaining why you've added/committed the addition of newer Rust compilers that aren't in-use and aren't public (e.g. in 45ae3c830fec8022e077538c72ce59b7df45e8a1)? Thanks! <winter>looks like a commit in the last week broke the shell-based installer (at least in my QEMU setup) 🙃 <NewUser-Basic-Qu>next4th found edit.scm about 22 times in store and 3x in "/root/cache" ...not sure which is the one currently used by system...Thanks for pointing to file. Guess i have a steep learning curve ahead of me <next4th>NewUser-Basic-Qu: well, the current one can be find by run '(search-path %load-path "guix/scripts/edit.scm")' in 'guix repl'. <lechner>sneek / later tell lfam / trademarks are intended to eliminate confusion among consumers. there is nothing wrong in principle about two companies using the same name for unrelated products (but the 'unrelated' part gets argued over a lot) <NewUser-Basic-Qu>next4th It prints "$1 = (search-path %load-path "guix/scripts/edit.scm")" .. .will most probably have to read up on guix repl <next4th>NewUser-Basic-Qu: it returns $1 = "/gnu/store/XXXXXX/edit.scm" for me, in the repl my input (after (guix-user)>) is: scheme@(guix-user)> (search-path %load-path "guix/scripts/edit.scm") <NewUser-Basic-Qu>next4th okioki...correct. "$1 = "/gnu/store/dam9jy58gncrwr68i83icn4d29y24rxq-guix-module-union/share/guile/site/3.0/guix/scripts/edit.scm" ... oki...see...i have no plan...thnaks for helping <rdrg109_>[Q] I created a new user in /etc/config.scm, run $ guix system reconfigure /etc/config.scm, but the user is not shown in my display manager. What I'm doing wrong? <next4th>rdrg109_: does the user be a system (with a uid < 1000) one? display manager only list normal users. also the display manager (or accountsservice, a dbus system service) may need a restart, so you can try a system reboot to ensure that... <juli>I'm not sure if my messages went through earlier because I was using an unfamiliar irc client, but does anyone have advice on repairing a borked guix system? Specifically how I might chroot in to reconfigure the system <NewUser-Basic-Qu>juli nope...not me. Just about to borl mine by enlarging Disk and resizing partition <next4th>juli: does the guix installed grub broken? if so I'll first try load its grub.cfg from a working grub, and do a boot. i think chroot into guix is complex to setup and use.. <juli>The specific issue I'm having is that once the system boots to a TTY, nothing works because there are "too many layers of symlinks" <juli>Idk what you mean by load its grub.cfg from a working grub. Like boot an older generation? <next4th>yes, the goal is try order generations <juli>Alas, I am a dingus and erased older generations before realizing there was no network for a reconfigure <juli>More precisely, i thought deleting all system generations would not include the one i booted, which is apparently incorrect <lechner>it should not delete the one marked (current), which is not necessarily the one you booted <juli>Anyway I'm chrooted in and everything but when I run reconfigure I'm told "failed to connect to /var/guix/daemon-socket/socket: connection refused" <juli>I can't run herd because its socket connection is similarly refused... <rdrg109_>next4th: Thanks for the help! Solved it! I executed $ passwd <<user>> as root and set the password, I killed the tty where the display manager was being run (by default, 7), visit the tty again and the user was being shown. Apparently, it is necessary for a user to have a password in order to be shown by the display manager. <juli>lechner: what am I looking for here? <next4th>rdrg109_: ah, okay, i didn't know that passwd too. cool! <rdrg109_>next4th: btw, I didn't have to reboot my system <next4th>juli: which system you chroot from? the guix install iso? anyway, in the chroot i don't think you can't shepherd as pid 1, so you need run guix-daemon manually. <next4th>you can't shepherd -> you can run shepherd <juli>The guix install iso, yes <juli>Hm okay so I... How do I run the daemon manually lol <winter>hmm, Guix resubstitued something it definitely already had in the store. <bumble[m]>how does one check disk space usage on a guix system? trying du -sh / shows many messages like this "du: cannot access '/proc/1012/fd/3" <NewUser-Basic-Qu>I'm astonished that resizing VM qcow2 from 20 -> 50, mounting via nbd and the standard partition resize procedure just simply worked ... was not sure if it will somehow ess up boot <rdrg109_>bumble[m]: My answer might me simplistic, but I think suits your need. If not, please let me know why it doesn't. <bumble[m]>@rdrg109 thank you :) yes that works well for me <NewUser-Basic-Qu>somehow it seems that my VM is beeing suspended regularely. elogind seems to be somehow involved but i am not getting where this might betriggered or configured <jackhill>NewUser-Basic-Qu: do you have GNOME's display manager/login screen configured to run by chance? <NewUser-Basic-Qu>jackhill No. Initially installed i3. Beahvior detected shortly after initiall installation. My first steps were trying to replyce i3 with sway but missing to many Guix-Basics to be successfull .Currently trying to reconfigure to headless system but gdm is still started <jackhill>NewUser-Basic-Qu: so do I understand that GDM is running? I think it's part of the default set of %desktop-services. GDM's default behaviour it so suspend if no one is logged in graphically. Have a look at the auto-suspend? service option. Also, GDM will only start wayland sessions if it is running under wayland as well, to the wayland? option is also valuable. <jackhill>otherwise, I've found starting sway from a test console with `dbus-run-session sway` works fine <NewUser-Basic-Qu>jackhill Thanks for the dbus-run-session hint. Had to "export WLR_RENDERER_ALLOW_SOFTWARE=1" first but then it came up working from tty <NewUser-Basic-Qu>Guys...i apologize in advance for stupid questions but i think you see that i am still poking around with a stick to see what happens a.s.o. Jackhill pointed out "%desktop-services" which i see in /etc/config.scm and next4th pinted out edit.scm. Is there a way to edit content of whatever seems in these sets using some specific guix workflow? <next4th>NewUser-Basic-Qu: /etc/config.scm is used for 'guix system', it can be named anything and put anywhere by your choose.. in config.scm, you use guile modules provided by guix, to edit those modules, see the guix manual 'Contributing' section for a start. <next4th>yeah, which files are you going to edit and for what? <winter>next4th: They're definitely better off looking at the Guix System section of the manual over the Contributing one, unless there's context I'm missing that makes that section better. <next4th>winter: okay, i think they're going to edit guix modules, if only the system configuration (config.scm) then yes, "Guix System" section is the right one. <next4th>NewUser-Basic-Qu: um, seems i misunderstand your question, what you are looking for are 'modify-services' in "12.1 Using the Configuration System" and in jackhill's paste :) <apoorv569[m]>I need gtk3 headers and libs for a project I am making, but I only one gtk package that is version 4.8.1. I don't see any other version. <next4th>apoorv569[m]: the 'gtk+' package is 3.24, while 'gtk' package is version 4 <NewUser-Basic-Qu>next4th We'll i try to to see if i can make somehow simple adaptions to the system so i guess something like 'modify-services' sounds about right. It is clear that if settings of any form must be present and editable in some form. E.g. file edit.scm you pointed out previously was of course not writeable so i guess there must be a workflow apart <NewUser-Basic-Qu>from the simple one with confi.scm to manipulate these. I guess this is where your hint to Guix Contributing might come in... <NewUser-Basic-Qu>anyways thanks to all(Jack and next esp.) for taking me a little bit by the hand <next4th>yes, the system can be configured by config.scm in a 'operating-system' record, while the record and its configurable settings are provided guix. if there are things not configurable or missing function from the interfaces provided guix, you'd hacking into guix. <bumble[m]>is guix package --delete-generations sufficient to remove unused parts of the guix system? or are there other comands to use when trying to keep the system tidy? <next4th>there is also guix system delete-generations, and 'guix gc' to actually free the disk space. <sneek>sarg, nckhexen says: Be sure to report that upstream, they should fix the test so it's skipped if IPv6 isn't available, but still fatal if it is. Requiring local networking in builds is fine, and packages with networking functions *should* test them — that's good! <NewUser-Basic-Qu>jackhill , next4th ...just checked jackhills example. there are references to "%default-authorized-guix-keys" and "%desktop-services" . the "%" freaks me out a bit. If you guys wanted to see hwat is inside/behind these you would use specific guix commands? <next4th>well, i don't know such command.. they are documented in the guix manual, which you can find out the guile module it belong to, eg: %desktop-services is in (gnu services desktop), then you can find it in a guix source checkout. <jackhill>agree, I usually look for thing in the guix source. Another way to explore is to use `guix repl` which will open a interactive Guile session with the guix modules loaded, then you can print out various values or try out some of the helper funcitons like modify-services to get a feel. <jackhill>I know it's a lot to dive into if you're new. Sometimes you just need to borrow working configs from others and learn parts of it over time. Once it clicks though, it's great! <NewUser-Basic-Qu>Thanks Guys up to this point. You'll see me again. @jackhill I think you are right I will make it "click" ... <efraim>winter: the new rust compilers get added as a preclude to them being promoted to the 'rust' package at a later date. In theory they should work for building packages but are actually untested. in the rust-team branch rust is updated to 1.67 and I hope to merge it into master soon <apoorv569[m]>What is easiest way to modify the password-store package definition to use my own custom build of dmenu instead? <vivien>Hello guix :) Can I abuse qa.guix.gnu.org, send a glib update and see what happens? <vivien>I’m asking because that would lead to a lot of stuff being rebuilt <apoorv569[m]>lilyp: I see. Can you share some example or point me to the documentation? <apoorv569[m]>There is delete append and prepend so do I have to first delete dmenu and append my own custom package? <TristanCottam[m]>Hi guys, I'm running Guix System with GNOME, and whenever I launch GNOME on Wayland, I seem to get problems with GLib, including losing access to gsettings and glib- commands, among others. <TristanCottam[m]>For instance, launching GNOME Web (Epiphany) from the terminal keeps printing errors similar to this one: <TristanCottam[m]>(WebKitWebProcess:2): Gdk-WARNING **: 09:31:38.800: Failed to read portal settings: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files <lilyp>apoorv569[m]: replace also exists <lilyp>TristanCottam[m]: I'm still running Xorg, so I can't really help you, but do those processes die a sudden unexpected death? <lilyp>I just checked with d-spy, no desktop portal is running on Xorg either <lilyp>Since portal is meant for flatpaks et al. I don't think it'll be a huge issue <lilyp>now the gsettings/glib thing looks more worrying, what are the errors here? <TristanCottam[m]>But I don't get an error on Xorg, and again, commands like gsettings or those starting with glib- aren't available <lilyp>apoorv569[m]: yes, but you really want to use package-input-rewriting to do this for more than one package, trust me <lilyp>TristanCottam[m]: not all commands are visible in a typical user profile <TristanCottam[m]>But why only on Wayland? Switching to Xorg without changing the configuration fixes all issues I mentioned <lilyp>e.g. not just for password-store, but other stuff that depends on it <lilyp>TristanCottam[m]: I'm really missing the details here. Which command is not found and where should it be found? What do your environment variables look like and do they appear sane? <lilyp>irrelevant, my gdm uses wayland as well <TristanCottam[m]>lilyp: `gsettings` and all `glib-` commands aren't found, don't know how to tell if my environment variables look sane (checked with `env`) <lilyp>does your .guix-profile pop up in env | grep PATH would be a no-brainer for starters <TristanCottam[m]>/home/tristan/.guix-profile/bin and /home/tristan/.guix-profile/sbin both appear <lilyp>okay, but the glib commands won't be in there <lilyp>this appears to actually be a bug in the xorg installation: glib leaks into terminal <TristanCottam[m]> * So `gsettings` should just be installed manually? Are all my "issues" actually expected behavior? <lilyp>I don't think it needs to be installed manually. <lilyp>You can just run `guix shell gsettings' and it'll work fine <lilyp>Ehm, `guix shell glib -- gsettings' <lilyp>The question is whether anything else depends on gsettings being visible in PATH <lilyp>I hope not, but you never know <lilyp>oops, should have been glib:bin <lilyp>as I said, it's a known bug that glib leaks into Terminal on Xorg, thus folks might not be aware of it <lilyp>I'm kinda wondering why it doesn't happen on wayland, but I don't want to debug it either <lilyp>you can also do (list (cons ...)) <lilyp>also package-input-rewriting delivers you a procedure <lilyp>i.e. you do (define use-apoorv-dmenu (package-input-rewriting ...)) <lilyp>and then you run (use-apoorv-dmenu password-store) <tux_life>Hi! Does anyone know why some DNS servers don't work for me with dnscrypt-proxy? It seems that all servers that support DNS Security Extensions give me this error: Sun Mar 5 10:00:55 2023 [ERROR] Unable to retrieve server certificates. Other servers work. <tux_life>I try to use dnscrypt-proxy. All servers that support DNS Security Extensions give me this error: Sun <tux_life> Mar 5 10:00:55 2023 [ERROR] Unable to retrieve server certificates. <tux_life>Other servers work. It is not firewall-related. Any idea? <rekado>tux_life: can you get it to log more verbosely? <tux_life>rekado I dont' know how. I try with "sudo dnscrypt-proxy -R SERVER_NAME -m 7", but the output is the same <tux_life>Sorry...I missed an answer. In any case I have no idea how to get verbose output with dnscrypt-proxy <jpoiret>apoorv569[m]: well, you should check `guix describe` to see if your current guix has the right commit <jpoiret>if you use `guix shell`, can you `,use (nebula packages password-utils)` and see if it's available from there? <mirai>tux_life: that's the server settings <tux_life>mirai Thak you! I have this issue with all servers with DNSSEC... Is there anything I can do? <mirai>I've seen those warnings when I used dnscrypt before <mirai>I no longer use dnscrypt nowadays <mirai>either DoH/DoT (or self hosted resolver) <mirai>the landscape with dnscrypt is unfortunate <mirai>there's dnscrypt and dnscrypt v2, which are very different <mirai>and the first one has been unmaintained for a long time <msavoritias>isnt dnscrypt also obsolete because of dnssec and dane nowdays? <namcsi>Hey folks. Anybody know if guix has a package that builds git's info files? Would love to browse them from Emacs:) <namcsi>It seems to me that the git package doesn't build the info files, and building them manually has not panned out <namcsi>I may just be missing an output that has them built, pretty new to guix <mirai>namcsi: does git build them by default? <cel7t>Why is guix system reconfigure building gnome-shell and mutter for me? I'm just using openbox <mirai>something is pulling them in <cel7t>Is there a way to investigate what's pulling them? <namcsi> mirai: I don't think that the git package has a build phase that installs the info files <namcsi>But the instructions for building git from source includes installing the info files <namcsi>It would be nice to patch the git package definition so the info files are also build by default:) <namcsi>Though I'm a guix noob so not sure how to do that out of gate <namcsi>I assume you'd need to modify the build phases and add (invoke "make" "install-info") somewhere <Guest74>i can't create a vm in virt-manager since /var/run/virtlogd.sock is missing <Guest40>Hi :) I'm trying to connect to wifi using connman, and it does not even see wifi technology. Does anyone has an example of working setup where connman is able to use wifi? <apoorv569[m]>Guest40: Maybe your `WiFi` chipset is not supported by `FOSS` drivers. Check hardware compatibility. <Guest40>I see wwan0 in the interfaces, I assumed that would be the wifi <apoorv569[m]>I have not used connman so cannot say. Maybe try NetworkManager? <apoorv569[m]>can also you wpa_supplicant or iwctl there should be plenty of guides online for using these tools. <Guest74>if you are running guix on a modern latop there is a high change of driver issues. just because you see it doesn't mean it works <Guest40>Hm ok different question. Does anyone has an example how to recompile the kernel changing some config options? <Guest40>hm, I see, thank you. So I'll try something like `(corrupt-linux linux-libre-5.15 #:configs '(("CONFIG_MT7921E" . m)))` and see if that works. Thanks :) <Guest74>apoorv569[m]: okay i fixed it, you need to add (service virtlog-service-type) to your system config and now it works (kinda feel stupid for asking since I misread it as libvirt all the time) <Kabouik>What would be the equivalent of `echo "uinput" > /etc/modules-load.d/uinput.conf` for config.scm? I didn't find how to add kernel modules in the doc. <Kabouik>Would that be (kernel-argments (cons* "uinput=1" %default-kernel-arguments))? <tux_life>So...we have dnscrypt-proxy 1 on Guix and I'm trying to install dnscrypt-proxy 2, to see if the servers that give me the error "[ERROR] Unable to retrieve server certificates" work. I defined the dnscrypt-proxy2 package, but "guix build -K --file=dnscrypt-proxy2.scm" gives me this error: https://paste.debian.net/1273025/ Sorry...I am totally <lechner>tux_life / i think the build log might be more interesting /var/log/guix/drvs/2x/ghsaw09mr9dqanbbljv585ikgzfrrv-dnscrypt-proxy2-2.1.4.drv.gz <winter>Anyone know if issue authors are intended to receive emails sent to <bug number>@debbugs, or if they're only supposed to be visible on the web interface? (See top of https://issues.guix.gnu.org/61959#18 for context.) <lechner>winter / as far as i know, debbugs copies no one automatically, except the submitter when the bug is being closed <lechner>mirai / i want to help with your connection <lechner>tux_life / it isn't "package .: no Go files in /tmp/guix-build-dnscrypt-proxy2-2.1.4.drv-0" "Building '' failed." <tux_life>lechner "no Go files...". Immagino che devo correggere la definizione del pacchetto. Ma come? :-) <tux_life>lechner (Sorry.... English...not italian....) I guess I have to fix the package definition. But how? :-) <winter>efraim: Got it, thanks. Follow up: is there any reason why the new compilers don't have their own "Verified this doesn't compile with N - 1, e.g.: ..." comment? Should those be added for posterity, as all of the other versions up to the recent additions did? <lechner>tux_life / please note in particular the use of #:import-path <Guest74>apoorv569[m] do a "guix install dconf" and virt-manager will save the connection. now you don't need to add it manually all the time <winter><jpoiret> it should be in /run/current-system/profile/share/guile/.../guix/config.scm <-- sysconfdir is indeed not /etc <winter>let me see if it's directly what ./configure says <tux_life>lechner Thanks, but no...that's not something I can manage to do. <apoorv569[m]>Guest74: Thank you! You have helped me with multiple things today. <rekado>should abiword and goffice use librsvg-for-system instead of librsvg? <rekado>as it is abiword cannot be built for i686-linux <lechner>Hi, should staging branch be rebased onto 1.4.0? <winter>lechner: do you mean master? it was rebased onto master from ~a month ago, so i assume you mean it should be updated? <lechner>winter / maybe i am misreading my magit. i thought it said that only 1.3.0 was reachable, but can't verify that right now <winter>so I'd assume something is up on your end <lechner>winter / yeah, i see it now. it was not rebased but merged with a merge commit. is that really the right way? <nckx>It is what is done, yes. <nckx>‘It was like that when I got here’, and also Savannah is configured to disallow force-pushing. <nckx>(Hence the song & dance involved both times a bogus commit signature was pushed.) <lechner>for feature branches, i think that policy is debatable <nckx>Debate it, I'd say! (Here/both is fine but this feels more like an ML matter.) <Guest74>guix style -f has no autocompletion support but guix build -f and guix package -f has. intentionally or forgotten? <lfam>Instead of force pushing, you delete the branch and then push it <sneek>lfam, lechner says: / trademarks are intended to eliminate confusion among consumers. there is nothing wrong in principle about two companies using the same name for unrelated products (but the 'unrelated' part gets argued over a lot) <lechner>i am more worried about the glacial speed of upstreaming. every six weeks, really? <nckx>It's much longer in practice. <lfam>That sounds about right. From my perspective, 6 weeks was always aspirational, but collaboration really broke down during the pandemic <lechner>anyone figured out why? there was so much less to do <lfam>It takes a lot of work to get those "catch-all" branches over the finish line, and so it also takes a lot of motivation, energy, etc <Guest74>okay, another question for autocompletion. it even autcompletes file that are not ending with .scm. isn't this dumb since it gives an error msg if you enter that cmd anyways <lfam>There may have been less to do for some people, but *much* more for others. Consider the lack of schools / childcare in the US <lfam>Suddenly, parents have their children at their side 24/7 <lechner>lfam / i think we should do partial merges periodically, and force-push what did not work---for the next cycle <lfam>Many people's jobs became an order of work more busy <lfam>I joined this conversation halfway through, so I don't quite get what it's about <lfam>But I can promise you, there's no benefit to trying to force these branches through. None of us are paid <lechner>like nckx, the mailing list may be a better place. i merely asked why the 1.4.0 tag was not reachable from staging after a reported rebase <lfam>We definitely *should* have finished these branches sooner. But, nobody has implemented the magic wand yet <lfam>What is a partial merge? <winter>Okay so yeah current-guix is definitely more impure than it should be. <lfam>lechner: You mean, cherry-pick some commits, leave some for later? <lechner>it's a quicker turn-around. all this stuff is stale <lfam>It's been done! But knowing which commits are the right ones to keep and which should be postponed requires almost the same amount of effort as doing the whole branch <winter>how can I view build logs for a given derivation? <lfam>However, this general problem is one of the primary reasons I advocated for ditching the staging process entirely, reducing core-updates to actual core packages (defined in %core-packages), and using feature branches instead <lechner>well, the comment was just my version of "perfect is the enemy of good" <lfam>Doing these big branches is just too hard <lfam>Feature branches will be easier to find motivated workers for, since the branches won't exist unless the motivated person decides to create them ;) <lechner>would those feature branches be rebased via vast-forward, or would they receive upstream updates via merge commits? can we then remain with savannah given their policy against force-pushing? <lfam>If there is some specific and coherent set of changes you'd like to see deployed within the next ~2 weeks, I recommend creating a patchset and sending it to guix-patches with a request to start a feature branch. You'll be the leader of the effort, shepherding the process by using the CI and QA info, along with managing any volunteers <lfam>Don't worry about force pushing. We just delete the branch and recreate it if we want to rebase <lfam>Name the branch with 'wip-$branch-name' to indicate that history may be rewritten <lfam>I think a feature branch that is well-managed could hit the master branch in 2 weeks, barring any major breakage <lfam>I'd recommend budgeting 3 hours a day to the effort <lfam>This is based on my experience having landed big branches several times <lfam>The key is to keep the set of patches somehow topically coherent. Like, some python changes, or changes to mesa and mesa-related things <lechner>i'll have to leave the pushing to others since i do not have those rights, but how about these two modest Golang updates? #58658 It is a prerequisite for Gocryptfs in #58768 (which I am updating later today because a fix resulted in a four-times speedup for NFS) <lfam>lechner: Yeah, I spoke from my own perspective re: pushing. With qa.guix.gnu.org, you can simply send a versioned patch series (using --reroll-count), and the server will do the right thing <lfam>Those patches look okay for the master branch, right? I don't count many dependents <lechner>lfam / last time i checked i counted 919 58768 <lfam>How did you calculate that? <lfam>For me, `guix refresh -l go-golang-org-x-net` says "Building the following 16 packages would ensure 43 dependent packages are rebuilt [...]" <lechner>lfam / the patch also changes 'go-golang-org-x-sys' "1015 dependent packages are rebuilt" <lfam>Okay, we might as well use a feature branch to help test. For Go, I often break the limits because the builds are so cheap <lechner>both patches together could be the "gocryptfs" feature branch (after i update the second) <lfam>Please, put a single patch series together and CC <guix-sysadmin@gnu.org> asking for a feature branch and associated jobset for ci.guix.gnu.org <lfam>I guess it's a problem that QA won't build such a large patches series, but you can't push to guix.git, which is necessary to efficiently use ci.guix.gnu.org <lfam>Mention that in your email to guix-sysadmin <lfam>We'll come up with something <winter>(out of curiosity, do patches get stuck often? e.g. that fairly simple looking Go bump has been sitting since January without activity.) <lfam>If you say which patch, I can give insider speculation on how it hasn't landed <winter>i guess that Go one linked above as an example <bjc>we're coming up on a year. i'm planning a bump as a celebration <winter>actually never mind i agree with bjc, i wanna hear why that one hasn't seen any activity :D <lfam>Dunno about that one specifically, I don't use Tramp or Emacs. But I'd never spend time looking at a patch that's seen no activity since May 22 <lfam>I'd assume that it's stale, no longer applies, or something like that. It just doesn't seem like a good use of time <bjc>it still applies. i still use it. just been rebasing it forward all this time <lfam>That's great! But it helps if you would say so. From the reviewer's perspective, it has been abandoned <lfam>lechner: The Go patch appears to have been unfinished when it was submitted, since it caused breakage. Then, it came to depend on some other patches. It's great that they have been linked, but it's just a bit of extra friction for reviewers to collect all the patches rather than have them in the same ticket. Then, it was determined that it should go on the staging branch, which looks like a black hole <bjc>there's no bump policy. from my perspective, this is a trivial, extremely low-risk patch that no one even bothered to look at. i feel like a bother for bumping it <ae_chep>How long should a patch submitter wait before they ask for an update? <lfam>I don't recommend asking for an update. I recommend re-testing the patch on current master and sharing the results. <lfam>bjc: Now that I've applied your patch, I notice that the commit message hasn't been written. Annoying for me to say that, but it's another thing that dissuades reviewers <lfam>I'll write it as best I can <lfam>bjc: Just to clarify, since you didn't mention it, does this change require people using dir-locals.el to change their workflow at all? <lfam>Or will they be able to ignore this change? <bjc>the change only has effect for people using tramp. ‘file-local-name’ is a no-op otherwise <lfam>Right, but will those tramp users have to change their workflow? <bjc>no, because it's currently broken with tramp <bjc>ie, there's no workflow <lfam>Okay, I've pushed it. Your patch submission would have been more likely to get reviewed if you the context we just discussed had been included in the email. For example, "The workflow this code is intended to support is currently broken. I've fixed it with this change and it works fine for me." <lfam>That helps people who don't use the feature review it <lfam>Otherwise, we see the patch and think, "Huh, I dunno about this!" <lfam>I know that patch review is a problem. It's a very difficult problem without any easy answers. But it's usually possible to help encourage review by clarifying the context and potential impact of the change <bjc>ok, but there's also no discussion of this in the guidelines. and those comments wouldn't have been welcome in the diff (i think? again, it's not mentioned, and most diffs don't have that level of detail), which means a multi-step submission process <bjc>and that's for a tiny patch. it was also my first, so having *any* feedback would have been useful. thankfully i stuck with things, but it wasn't a great start <bjc>i am a little sad my anniversary post won't happen now ;) <bjc>thank you for pushing it <lfam>From my point of view, it's generally about "how to ask strangers to do something for you". In general, that takes some effort <lfam>It's a skill that is honed with time <bjc>this is far from my first open source submission. i've been doing this for decades. this was one of the worst, though <bjc>i'm not saying that to be mean, it's just how it was <lfam>I keep saying there's no easy answer. As a reviewer, I simply can't do any more reviewing than I already do. And that's the case for all the reviewers <lfam>There are hundreds of patches sent every day <bjc>i know it's. it's tough, and guix has an undersized team for the work it does. the infrastructure needs work, because the current process is too slow and cumbersome for the already overworked volunteers <lfam>I mean... how could they possibly all get reviewed? <bjc>i don't have a good answer for the infrastructure, either. github is decent, but obviously can't be used directly, so that means someone would have to implement it in a way guix/gnu can use <lfam>Github is definitely slicker. But I see the same problems in Github projects that receive a lot of pull requests. They simply don't get handled unless the reviewers are professionals (i.e. employed) <Guest74>lfam: with an AI system altough that AI system would need work too (but just once) <lfam>Sure, but nobody has implemented the magic wand yet ;) <bjc>ultimately guix just needs more reviewers/committers. another hard problem <lfam>It's largely a problem of communication and management <lfam>I wonder if every Linux patch gets reviewed or if things get ignored <lfam>It's a similar model to Guix <bjc>i get the impression linux is way more structured than guix. it definitely has much more corporate support <mirai>start with reducing the bus factor? <lfam>Yes, Linux hackers are employed <lfam>Do you see how your suggestion to the problem of "there's too much work to do" is basically "do more work"? <mirai>make it good enough to reduce the cost of training "new maintainers/reviewers" <mirai>lfam: I see it as "investments" <lfam>Yeah, that's a good way to look at it <bjc>writing documentation is often harder than doing the initial work that requires it, ime. it's hard to do and never ending. not that it shouldn't be done, but it's a lot <mirai>outside from the dream world, we can't really create improvements from thin air <mirai>it doesn't need to be complete <mirai>I'm setting the bar to "good enough" for ROI (defined as faster/cheaper training process) <lfam>Yeah, it would be really beneficial for the project. Way more important than improving the software or updating packages <lfam>I agree with you, bjc, that writing effective docs can be much harder than anything else. <ellysone[m]>I hope guix will attract more people if we have just enough cool services and packages, a declarative mail server/sourcehut would be amazing. <lfam>I agree, "cool service in a box" is a "killer app" for Guix <ellysone[m]>I have a friend that chose nix over guix because more people , more doc <bjc>it feels to me like we're already at an inflection point, where there's more interest than the current “staff” can handle reasonably <lfam>It's true, but it's a friendly competition. And, we are leading in some areas, like user interfaces <lfam>I think the QA server can help a lot, but automating the basics of review <lfam>Already, I've found it useful <mirai>doc writing is usually "boring" work <mirai>the software doesn't work any better than it does now <ellysone[m]>I don't know I don't have a good answer besides pumping enough posts/videos/services that will attract more people. <ellysone[m]>one thing that could be improved on the contributor side <bjc>i wonder if making a wiki, arch-style, would help farm out the documentation a little bit better <mirai>unless you see doc writing as 'investments' (long term kind) the incentives are nearly none <lfam>I always resisted the wiki idea, but maybe it's worth a try. Idk <bjc>not as a replacement for texinfo, but as (a large) supplement <jcmdln>for more contributors/reviewers for packages, the scope could be narrowed a bit to specific packages or ecosystems. ie packaging something from Go/Rust/etc <jcmdln>even on lkml sometimes emails go unanswered. even with corporate-sponsored developers they generally are focused on the needs of their company which is to be expected. <ellysone[m]>would be to simplify the whole process, instead of reading pages and pages of ocntributing, you'd just do ./setup-isolated-environment -> do changes -> ./test-changes that is a big one for me, having to be sure that you ticked all the 16 boxes is not fun -> send changes <mirai>bjc: I think the ML approach is good enough if... doc reviews are faster <lfam>We are putting together "teams" of people who cover specific parts of the codebase, jcmdln. So, there is a Rust team, for example <bjc>the texinfo documentation isn't a good place for howto-style information, imho, whereas that's a perfect fit for a wiki, and something a lot of people would find useful <ellysone[m]>also does anyone knows what the situation is with the devel/ not devel doc? Like is there any plan to set up some js to warn you that you're not viewing the most recent doc? <lfam>bjc: Yeah, that was sort of the idea with the cookbook. But a cookbook isn't a wiki <mirai>which __shouldn't__ be a big problem since they don't break any software component <mirai>cookbook, wiki are good for "recipe" kind of information <mirai>but are of little interest for how the internals work <bjc>ellysone[m]: i think nckx said something about pushing that forward a couple days ago. i don't think there's any disagreement that at least a popup would be good <mirai>and is of bigger interest for training maintainers <msavoritias>I wonder how much more work its going to be to maintain the wiki though. managing accounts, maintaining the thing. <jpoiret>bjc, lfam, mirai: i'm currently trying to revamp the "Contributing" section of the manual <jpoiret>like, moving things around, redoing the checklist, that kind of stuff <jpoiret>can you believe the checklist contains "Run `guix style`" twice? <bjc>jpoiret: since i know that's thankless work: thanks =) <rdrg109_>[Q] How to disable pager in "guix search"? I'm running shell commands in a shell-mode buffer within Emacs and it is somewhat annoying having that warning <mirai>my undertakings with guix.texi have mostly been confined to "give it some coherency on @-commands used and structuring" <jpoiret>rdrg109_: setting "PAGER=" works for me <bjc>i set it to ‘cat’, just in case some program gets funny ideas about what i mean <jcmdln>I also set my pager to cat in my emacs config <mirai>lfam: the wiki could serve as a "brewing ground" for docs that can be included in the manual/cookbook/etc. if "adequate" <rdrg109_>Thanks everyone. Executing => export PAGER= <= in the shell-mode solved the issue. I guess I'll add it to my init.el file. <rdrg109_>jcmdln: Could you share the statement in your Emacs config that do this? <bjc>one thing i'd like, as someone who doesn't know hardly anything about texinfo but has to edit it sometimes, is a testing guide. like: 1) make edits 2) make texinfo 3) open browser at … to check 4) run info … <lechner>lfam / thanks for all the advice. the go patch was updated to address the issues raised, but QA never ran again (or did not complete) <mirai>but maybe we should call it "guix scratchpad" rather than a wiki in that case <bjc>i'm currently just editing, triple checking, and praying <jpoiret>I just open the freshly-minted manual using C-u C-h i <bjc>i don't know how to do that with in-progress edits <mirai>I type what I have to and test with info -f guix.info <bjc>what's the make target for it? doc? <winter>jpoiret: by the way, re our convo from a few days ago: #61987 <bjc>this is kinda what i mean. we have documentation for code edits at this level, but there's nothing for texinfo <mirai>bjc: either we include a a cursory introduction to texinfo in the manual <winter>i'd try to take a look, but i cannot get guix build -e to build current-guix <mirai>or we refer to the gnu texinfo manual <bjc>i've tried reading the gnu manual. it's very gnu circa 1990 <winter>i've tried '(@ (gnu packages package-management) current-guix)' but that doesn't work because current-guix itself is a function that takes nothing. if i add a random parameter to the call, it doesn't fix it <bjc>but there's still guix-specific stuff that'd be useful as a starting point <mirai>part of the idea on harmonizing the @-commands in guix.texi are to make this less painful <jpoiret>winter: doesn't `((@ (gnu packages package-management) current-guix))` work? <winter>jpoiret: i haven't tried the ((...)), only single parens. why would double fix it? <mirai>bjc: the serviceland has many utilities that help you generate documentation <cbaines>lechner, have you got a link to the issue? <jpoiret>because `(@ (some module) var)` gives you what the variable is bound to in that module, but here that variable is bound to a procedure, which you want to call, so you put it between parens <mirai>but regular docs still rely on texi knowledge <winter>yeah that would do it, i'll give it a try later <jpoiret>i'm not sure texinfo is the main problem here <jpoiret>actually writing the docs is just painful <winter>guess I'll repost this other question too: how would I view the logs of a given derivation? i know the daemon stores logs, but i can't find a command like Nix's `nix log` <mirai>tbh there's the option for contributors to simply write their mind to the MLs (with a [DOCUMENTATION] prefix in the subject) and someone would properly format it <bjc>mirai: am i missing something in the manual? i swear i've tried to find it. what's ‘serviceland’? <mirai>maybe it can be made more prominent that this is also a valid form of contribution <mirai>bjc: :))) its not an actual component <mirai>there's configuration->documentation procedure which can automate some texi work <bjc>what module is that in? <mirai>(gnu services configuration) <mirai>very neat if you use define-configuration <bjc>oh, i see. i was thinking more of internals docs, since that's what i've had to mess with most. but still good to know about <mirai>the internals should receive documentation too <mirai>that will require some planning of course <Guest40>So it seems herd restart dbus-system is not a greatest idea. It seemed to kill pretty much everything. Is there a way beside restart correctly restart it? <mirai>Guest40: I don't expect for dbus to be cleanly restartable <ellysone[m]>Does translation has an impact? I would have guessed that most people using guix are fine with english. <Guest40>mirai: Hm that is slightly annoying given guix's design. Well I'll remember to do this via reboot. <mirai>ellysone[m]: I want to answer with 'no' but given that I've seen people using guix with non-english locales I can't assert that <mirai>I think they'd prefer the manual be in the same language as the system <winter>lfam: <tongue-in-cheek> Maybe you should have applied those guidelines to this commit ;) (as in, explaining why you think these guidelines are good to have) </tongue-in-cheek> <mirai>Guest40: do other distros allow it? <lechner>lfam / should i file a new patch and close the two others? <mirai>stopping dbus on fedora just makes it go unresponsive <mirai>so I don't think this is a guix design problem <lfam>lechner: Yes, it will help reviewers if all the patches that you want to deal with concurrently are in the same ticket <lfam>Urgh lilyp, thanks for pointing it out <Guest40>mirai: Other distros do not need to restart it, since the security policies (.service files) are loaded from fixed place on a filesystem. So if I install wpa_supplicant into a running system, will just work(tm) on archlinux, but on guix (the policies are compile into single directory in the store) I need to restart dbus (which I now know should be <mirai>lilyp: lfam is already thinking in the long-term :) <Guest40>Not a deal breaker, but it took me a while to figure our why wpa_supplicant refuses to work :/ <mirai>Guest40: I'm interested in hearing about this issue <lfam>That's generous. Hardly thinking, really <mirai>what exactly did you do and what are you trying to do / expect <winter><lfam> I snapped, winter <-- (wdym?) <Guest40>mirai: I've added (service wpa-supplicant-type) into my configuration.scm (since connman could not use wifi) and run system reconfigure. The wpa-supplicant service refused to start and in /var/log/message I found error (from dbus) about permission errors fi.w1.wpa_supplicant1). <mirai>Guest40: I think those messages are a red herring <Guest40>I would expect the wpa-supplicant service to start after the reconfigure, but that just did not work until reboot <mirai>are you running with the latest guix pull <mirai>does rebooting make these messages go away? <Guest40>Well, those message are right though no? Since dbus runs with previous configuration, one that does not include fi.w1.wpa_supplicant1.service file in it. <mirai>if there's no issues open for it, file one <mirai>but it can be made to work if some kind of directory union is used <Guest74>if I want to see logs for libvirtd or other daemons, would I need to view the log file manually or is there some command for it? <Guest40>mirai: Will report once my laptop is to the point of browser and email working :) <Guest74>like for example I would have used systemctl status libvirtd that shows some erorr msg or if the service is down <lfam>Something like journald / journalctl is in the "Help wanted!" stage here <lfam>It's one of the best things about systemd <Guest74>guix system: error: aborting reconfiguration because commit 01fd830f2fdd388f56e6e00df747f052bbde3906 of channel 'guix' is not a descendant of 4775460ba9a60c3c09966216da10686a70b8fadb; does someone know how to fix this without forcing downgrade? really annoying; I already tried guix pull and hash guix which fixed it 10 mins ago but now I have it <winter><ellysone[m]> sudo herd doc <service> list-actions <-- won't that just show e.g. start, stop, and nothing wrt logs? <winter>right, guess i'm just not seeing how that relates to their question (i assume it doesn't and you were just giving them some related info) <ellysone[m]>Guest74: Had the same problem on a vm don't know why though ; ( <civodul>lfam: re communicating with reviewers, neat! <lfam>civodul: I found that often, when a patch had never been reviewed, I was asking these questions <civodul>lfam: what would like to take from journald? like "herd log SERVICE" to view the log of a service? <lfam>Yeah, that's a start. It has sophisticated filtering and querying features. It stores the logs in a database so the sky is the limit in terms of how you can interact with them. <lfam>Something I use often is date-based and boot-based filtering <lfam>Like, "show me the logs of sshd from the last 3 boots" <bjc>my main use is the ‘-f’ flag <lfam>Guest74: Try logging out and logging back in. <lfam>Oh, yeah, like `tail -f logfile`, right? <Guest74>lfam will try next time it occurs, already forced downgrade <bjc>lets just not make the mistake of binary logging if we can avoid it =) <lfam>Okay. It does appear that you've downgraded your system <lfam>Eh, to me the tradeoff was worth it :) <lfam>I guess you trade disaster recovery for ease of use <bjc>i like journald's interface, in general, but i still miss plain text for some things <bjc>hmm. does emacs have a journalctl mode yet? <Guest74>do you have resources for learning scheme as a beginner? <Guest74>plan todo something similar since there is nothing on the internet <jpoiret>strong opinion ahead: those braindumps and org-mode that I keep seeing online never seem to contain anything more than just cursory bits and pieces of information <jpoiret>they never look like anything remotely useful <bjc>i use org-roam quite a bit. it's the first time one of these things has ever clicked with me <Guest74>I changed my samba config and again I get that stupid descendant error <bjc>i wouldn't publish anything in there, though. the reason its useful is because its basically just a note-taking dumping ground that's pretty unique to me <Guest74>could it be because of TRAMP? on my actual system I do not have those problems <bjc>tramp and samba shouldn't have anything to do with each other <jpoiret>the fact that they're almost always about AI, deep learning, cryptos or ... how to learn things better (pretty funny) just makes it worse <Guest74>well it worked on the tty from my vm <Guest74>it is something with the shell from TRAMP I think <bjc>jpoiret: the mind-mapping stuff predates the crypto/ai scam by at least a few years. i think it's part of an ur-scam in the vein of "life hacks" <jpoiret>right, maybe I only encountered it later then <lechner>Hi, how may I include custom channels when deploying a system with Guix from Git, please? <gnucode>hey guix people! I just ran the installer script to install guix on top of fedora. <gnucode>after I ran the guix installer I get an error "failed to connect to "/var/guix/daemon-socket/socket"...time to go start the guix daemon via systemctl <gnucode>it seems like the default selinux policy of fedora is making it hard to easily install guix... <tux_life>Hi! One question: on Guix is it possible to disable the root user with "sudo passwd --lock root"? Or does that cause any problems? <Guest40>Is it possible to configure elogind to suspend the machine on external power disconnect? So far I found handle-lid-switch-external-power, which prevent suspend when power is connected (good!), now I want to also suspend when the power is disconnected. Is that possible? Or do I need to also use acpid next to the elogind? <lechner>gnucode / maybe they are being anti-competitive? <Guest74>Guest40 Guix has no acpid service yet (just so you are ware of it) <Guest40>Guest74: I did not know. How is reacting to power events done in guix then? <lechner>Guest74 / i think the issue is the same for 'reconfigure' <Guest74>Guest40 I don't know, but I wanted to install it and saw it is not yet implemented <tux_life>Is there anyone on Guix System who has disabled root login? Would I have problems, after a "sudo passwd --lock root" ? <winter>Guest74: i sent that to them above, though they haven't responded yet :) <lechner>tux_life / are you in the wheel/sudoers group, and have you tested sudo? <Guest74>ah didn't see it, kiwi irc has a annoying scroll behaviour <lechner>i guess it works at least for passwd, but that can technically be the only authorized command <lechner>also, as for the default in Guix are you sure your root login is unlocked? <tux_life>lechner Yes, I can login as root. And yes...sudo works fine! I think I can disable root just fine, but I wanted to be sure. <NewUser-Basic-Qu>There is explained how functions can be declared and values can be assigned.. etc... If i try to output "x" i can type it and get my previously defined value printed. Is there a a way/command to show me everyhting i have defined? <tux_life>lechner ok I just learned something new. I didn't know the chage command... Thanks! :] <lechner>Hi, how many folks per day struggle to boot Guix on a system root with LUKS full-disk encryption? <Guest40>lechner: the double password input is annoying, but I would not call it a struggle <rekado>lechner: I have been using full disk encryption for years and haven’t had any problem like that. <rekado>I even installed a new system on a new laptop a week ago, also with full disk encryption. No problems. <lechner>i think we see a fair number of people. Perhaps it's worth a blog post. I'm sure the Guix collective will accept it <lechner>that's funny! i could not live without it <rekado>I used to use LVM in my Fedora days, but I haven’t needed it for over ten years. <civodul>ACTION also uses full-disk encryption without LVM <mirai>guix has a small wart with LUKS that you don't get with fedora <mirai>but that's because fedora bundles a key in the initrd image? <Guest40>I always assumed that it is due to grub being slow (== not that optimized). <mirai>I'm not too sure about this but dracut does some magic to make LUKS easier <Guest40>Lot of installers do not put the /boot itself into encrypted storage, so then you have both 1. just one password 2. faster unlock since it is handled just by cryptsetup instead of grub's built-in functions. <rekado>I finally figured out how to access files from disk in the Sugar desktop environment; by default it hides the hierarchical file system and only shows you the “Journal”, a flat, time-based file+activity log. <rekado>to access files from disk you need to have “xdg-user-dir DOCUMENTS” return a location that is not HOME. <bjc>rekado: sugar? like the olpc operating system? <rekado>only then does it display a flat list of files from ~/Documents <Guest40>> Assigning bugs I will soon send patches for to myself (where soon = a few days) <bjc>rekado: cool. didn't know that was still alive. the default being a journal made sense there, imho <rekado>bjc: I’ve been packaging a few Sugar things recently to prepare an old i686 netbook for my kid <rekado>the system is a little disorienting at first, but I can see how it would be fun to use in a classroom context. <civodul>mirai: re "slow to decrypt", there was a discussion on the list a few years ago and some claimed that the slowness was unavoidable <bjc>cool. i'll have to look into it. i have some spare kid-appropriate hardware and my xo laptop is unfortunately extremely old now and not up to doing much <mirai>civodul: perhaps changes at the GRUB front can ease this? <mirai>but interestingly, fedora does not suffer from this <mirai>whatever they're doing it I can guarantee that it takes a lot less time than 5-10 secs <Guest40>I'm always surprised people care about boot time that much <lechner>after switching to Guix, i hardly reboot <mirai>worth checking out and perhaps smuggle some ideas into guix <mirai>Guest40: 5-10 seconds boot time doesn't sound that bad for *nix computers given the fame of "not rebooting frequently" <civodul>mirai: interesting that; i wonder what makes it slow then <civodul>we should re-investigate because it's annoying <mirai>Guest40: yeah, you'll get annoyed soon once you have to reboot somewhat frequently to test out some guix patches <mirai>and god forbid you have more than 1 luks drive <Guest40>Is the /boot on the fedora machine encrypted as well? Or rather, is the initrd stored in encrypted location? <Guest40>mirai: Yeah, I plan to work on support for keyfile unlock *before* I migrate my home server with ~10 drives. :) <mirai>and the rest of the drives get unlocked with the file <mirai>iirc guix does things differently <mirai>and I couldn't get it to use a keyfile <Guest40>Yeah that is how my current alpine setup works as well. But to keep my sanity I will need to figure this out in guix as well somehow :) <mirai>I'd classify as a priority task for "laptop support" <mirai>since those typically get power-cycled much more frequently than say, a desktop <lechner>ACTION recommends Gocryptfs for home <Guest40>Is that true? I think most people just suspend their portable machines no? <Guest40>I turn off my work laptop once a week, on Friday, before I stuff it into a backpack for the weekend. <mirai>eh, I have (had) poor luck with suspend <mirai>so idk what's the landscape nowadays <Guest40>Different topic: 1. Does /etc/elogind/system-sleep hook directory work for anyone? I can't get it to run scripts in there. 2. Is `man loginctl' rendered correctly for you? <mirai>I've noticed this for a while <mirai>though idk if it's already fixed <mirai>since I think its a core-update change <Guest40>Ah, one more reason to look forward for core-update merge <lechner>mirai / cam i use custom channels when reconfiguring with a Guix from Git? <mirai>lechner: I don't know, I haven't used channels (yet™) <winter>I feel like that could probably be written better <mirai>lechner: you can snip some 'not' aways with de morgan's laws <mirai>I'd write the logic in a piece of paper first <mirai>and see what other equivalent expressions are there <Guest40>Hm I would expect it to be either all on one line or on four line. Not sure if either would help though. <winter><mirai> since I think its a core-update change <-- (is man broken for every page, or just loginctl?) <mirai>it's to do with some docbook funkyness <lechner>thanks, i know that. more vexingly, i am trying figure out why I am seeing this message with a FUSE home folder that is inaccessible root. does the directory-exists? not work as intended? http://paste.debian.net/1273063 <Guest40>`man elogind' is fucked up as well for example