IRC channel logs


back to list of logs

<jxself>Yay, so potentially 4.0 next weekend.
<jxself>The ability to update the kernel without rebooting seems interesting. Would be nice if Guix could make use of that.
<davexunit>yes, indeed!
<davexunit>once we don't have to reboot after a reconfigure due to dmd
<cmhobbs>why are there SRFIs included with guix?
<cmhobbs>sorry for the ignorant question
<mark_weaver>cmhobbs: we include SRFI-64 because it was not included in Guile until 2.0.11 and Guix supports Guile as far back as 2.0.5
<mark_weaver>(mainly because that's what's in Debian Wheezy and Ubuntu 12.04 LTS
<mark_weaver>cmhobbs: we include SRFI-37 because the SRFI-37 implementation in Guile before 2.0.9 had a bug <>
<{}grant>mark_weaver: Yeah, ty, that worked. But yeah having a symlink or similar probably isn't a bad idea.
<mark_weaver>oh, right, the strange name for it.
<mark_weaver>I wonder why upstream uses such an unfamiliar name.
<mark_weaver>yeah, we should probably add that symlink, indeed
<{}grant>mark_weaver: Yeah, it's very odd ... especially in every distro I've used (Debian, Arch, Fedora, etc) "loadkeys colemak" worked 'out of the box'.
<{}grant>I just assumed that colemak didn't ship with the standard distribution generally, and they had some sort of layered system for 'most common', 'not-so common', to 'obscure' packages. :^P
<mark_weaver>{}grant: would you like to propose a patch?
<{}grant>mark_weaver: I mean, I'd practically just be rephrasing Alex's initial comment -- no? I could do so surely in the next day or-so, if need be, in any case.
<mark_weaver>{}grant: did he produce a patch?
<{}grant>mark_weaver: Ah, I think I see my issue here. I took "propose a patch" as a formal request on the mailing-list with an explinatation for such a thing -- rather than producing one, by effect, because I think it's worthwhile.
<{}grant>Yeah, I don't see a patch by Alex.
<mark_weaver>if you could write and test a patch, and then post it, then we could include it
<mark_weaver>it's harder for me to test such a thing, because I'm not familiar with colemak. I fear that if I switched my layout to it, I might have a hard time switching it back :)
<{}grant>Ludo posted in that thread, in response to this "I think we should stick to upstream, except if it turns out that unanimously massively contradicts upstream."
<mark_weaver>hmm, okay
<mark_weaver>well, you could try to convince upstream to make "loadkeys colemak" work.
<mark_weaver>as you say, it seems that most distros have made that change already
<mark_weaver>you could also use a customized 'kbd' package on your system.
<mark_weaver>guix makes that kind of thing rather easy
<{}grant>I mean in any case, we could always have an OS EDSL function that is (keyboard-layout "colemak") or something that can set the default to whatever layout somefactor of "globally" via console and xorg that automatically maps en-latin9 to colemak on it's end and not at the kbd level. :^P
<mark_weaver>probably the best thing is to define a service to set the keyboard layout
<{}grant>mark_weaver: A combined service, for both xorg/console or just console and leave the defining of xorg layout in .xsession or a seperate service?
<mark_weaver>in my OS config <> I define several services right in that file, one of which turns caps lock into control.
<{}grant>"Too many ways to skin a cat". :^P
<mark_weaver>it would be even easier to make one that calls load-keys
<mark_weaver>{}grant: my 'powertop-auto-tune-service' and 'sound-volume-service' are two examples of services that just run a single command.
<mark_weaver>you could just copy one of those and modify it to run load-keys
<{}grant>mark_weaver: Ah, I see; Very neat, ty, will save and play with tomorrow. :^)
<mark_weaver>and if you made it take the layout as an argument, then it could be suitable for taking upstream
<{}grant>mark_weaver: True.
*{}grant will brb.
<{}grant>Well, wicd-service I can't fudge to work tonight -- probably too braindead on my end, so will mess with it tomorrow. Afk. o/
<mark_weaver>{}grant: you also need to add 'wicd' to your 'packages' field in the OS config, and add 'wicd' to the list passed to 'dbus-service', and add 'netdev' to the 'supplementary-groups' of all users who should be allowed to configure the network.
<rekado>solfege crashes when it cannot find the default locale.
<rekado>so I installed glibc-locales, set LC_ALL to en_US.UTF-8 and LOCPATH to /gnu/store/...-glibc-locales-2.21/lib/locale/ and now it works.
<rekado>glibc-locales does not suggest a search path.
<rekado>I think it should.
<mark_weaver>it is glibc that declares a search-patch for LOCPATH
<rekado>oh, I see.
<mark_weaver>I think the set of packages consulted for search-path specs should probably be broadened
<mark_weaver>openssl declares search paths for SSL_CERT_DIR and SSL_CERT_FILE, but I suspect it is rare for anyone to get a reminder about that one either, because people don't tend to install openssl directly in their profile
<rekado>may solfege have glibc-locales as an input or should this be avoided?
<mark_weaver>so yeah, I agree there are issues here to be solved
*rekado goes afk for a few minutes
<mark_weaver>rekado: I think it should probably be avoided, but civodul is the one to ask
<mark_weaver>lots of things won't work if locales cannot be found
<mark_weaver>granted, most packages don't crash, but lots of stuff will be broken
<mark_weaver>so I think we should focus on making sure that users have LOCPATH set properly
<mark_weaver>glibc-locales is huge
<rekado>okay, I commented on this on the ML and did without making an explicit dependency on glibc-locales.
<civodul>Hello Guix!
<wingo_>morning civodul :)
<rekado_>I'm attempting to remove a few packages from my profile and noticed a couple of things:
<rekado_>- it tries to update the list of substitutes --- odd, because I'm only removing stuff.
<rekado_>- it fails doing so.
<rekado_>here's the error:
<rekado_>I get around this error with "guix package --no-substitutes -r ...", but I think I'll have trouble using substitutes when this also happens during installation.
<civodul>rekado_: is it reproducible, or a transient server error?
<civodul>(it looks for substitutes because it needs Guile to create the profile)
<rekado_>I can reproduce it. I also see it with "guix package -u"
<civodul>what Guile version is it?
<civodul>so substitutes in general are broken, right?
<civodul>could it be something with the neworking/firewall settings?
<rekado_>I now get different numbers: ("EOF while reading response body: ~a bytes of ~a" (8192 4469))
<rekado_>it could always be networking/firewall settings-related, of course :) But I don't think I've changed anything.
<rekado_>I'll try to reproduce this on my workstation.
<civodul>could you "strace -s 345 -p $(pidof guix-daemon) -f -o log", then reproduce it, and post "log"?
<rekado_>"log" is 5M.
<wingo>civodul, i am getting a lot of test suite failures due to e.g. "ERROR: In procedure scm_to_sockaddr: unix address path too long: /tmp/nix-build-guix-
<wingo>at least with the builder
<civodul>wingo: usually we use a shorter commit id, otherwise we run into these limits
<wingo>and indeed there seems to be a static limitation in struct sockaddr_un
<civodul>normally this one should be detected at configure time though
<wingo>that's why you truncated the commit id
<wingo>ok :)
*wingo had updated his guix-devel package locally
<civodul>that's not *the* reason, but that's one reason ;-)
<civodul>wingo: did configure say "socket file name limit may be exceeded when running tests"?
<civodul>admittedly, that's just a warning, so it's not that helpful
<civodul>but we can't error out, because the user might want to skip tests
<wingo>civodul, yes
<wingo>probably just need a comment in the "guix-devel" package definition
<wingo>because the normal monkey-type thing is just to paste the full commit hash
<civodul>i had never thought of this, because i use C-w in magit, and that copies the short commit id
<rekado_>civodul: here's the part of the log where it makes a connection to hydra and produces the error:
<wingo>for some reason with the edited patch in master, "guix system vm" is building the linux-libre kernel
<wingo>whereas i have specified my own
<wingo>i understand that specifying (kernel linux-foo) in the operating system is sufficient?
<civodul>wingo: it is
<wingo>i think because system-qemu-image should be applying (operating-system-initrd os)
<wingo>instead of base-initrd
<civodul>no, because it wants base-initrd specifically
<wingo>but that will use linux-libre
<wingo>because it's not passing #:linux to it
<wingo>not sure how delegation works there tho
<civodul>wingo: #:linux is in REST no?
<wingo>civodul, not sure :) maybe you're right
<wingo>i guess you are right
<wingo>dunno why it is building linux-libre then
<wingo>perhaps for some other output of linux-libre
<civodul>rekado: what was the error corresponding to this particular strace log?
<civodul>wingo: could be
<civodul>wingo: does 'guix system build config.scm' build it as well?
<wingo>civodul, no, guix system build os-config.scm does not build linux-libre
<wingo>for me
<wingo>and for my os-config.scm
<civodul>so that sounds good
<civodul>maybe linux-libre is used for one of the vm-specific things
<civodul>yes, it's used by expression->derivation-in-linux-vm, used by qemu-image
<civodul>it's the thing that builds the tiny VM image, when using 'guix system vm'
<civodul>so everything is alright, i think
*wingo has built a gnome-settings-daemon :)
<civodul>wingo: yay!
<civodul>thanks for working on it!
<rekado_>I still have the problem with substitution. In all cases the error is that for some reason guix wants to read more bytes than there are.
<rekado_>I'm make clean'ing the whole thing and rebuild.
<wingo>mark_weaver, somehow i got gnome-terminal able to change and save its preferences
<wingo>i am not sure how tbh
<wingo>maybe just via installing gnome-settings-daemon without running it even? strange
<davexunit>kinda spooky that you need a special daemon around just to configure things
<davexunit>it gives me flashbacks of the Windows registry
<wingo>i don't actually know that what i said is the reason
<wingo>it's a bit of a mystery to me
<civodul>rekado_: if it's reproducible, can you redo the whole strace thing, and mail both the relevant strace excerpt and the corresponding error message + backtrace?
<civodul>has this machine ever worked since the HTTP pipelining change?
<rekado_>civodul: pipelining came with d3a652037, and I have used it at bfe3c68.
<civodul>ok, so it must have worked before :-)
<rekado_>yes, seems so.
<rekado_>in the meantime system updates have been installed and the machine has been rebooted.
<rekado_>then guix has been rebuilt and installed.
<civodul>was Guile upgraded?
<civodul>hmm normally the workarounds in (guix http-client) apply as needed, with a run-time check
<civodul>so that must not be the issue
<rekado_>guile was not upgraded
<wingo>iyzsong, awesome work packaging webkitgtk+ !!!
<wingo>that's great :-))
<wingo>iyzsong, wdyt about splitting modules at this point? gnome.scm is getting huge
<wingo>webkitgtk.scm might make sense, and epiphany could go there
<wingo>perhaps that could sit below gnome at some point
<davexunit>will we start making a hierarchy at some point?
<davexunit>like (gnu packages gnome webkit)
*wingo doesn't really believe in hierarchies
<wingo>not for software...
<wingo>dunno tho :)
<davexunit>as an organizational strategy :)
<davexunit>for teh codes
<davexunit>the directory is huge.
<davexunit>lots o' modules
<wingo>thing is, hierarchy often gets in the way
<wingo>it's easier to refactor a flat structure
<davexunit>fair point
<wingo>and often you don't know what the hierarchy should be
<wingo>or if one exists
<wingo>that's especially the case for packages that could go under multiple roots
<civodul>yes, i agree with wingo
<civodul>having experienced the deeeep hierarchy in Nixpkgs
<civodul>i found that it doesn't really help
<davexunit>you've convinced me :)
<iyzsong>wingo: I'm ok with webkitgtk.scm or webkit.scm, but think epiphany should belong gnome.scm. btw, I haven't got it built.
<iyzsong>for gnome-terminal, dconf is used as gsettings backend. I think it just work fine when you have dconf in profile under Xfce, doesn't?
<civodul>so there's gconf, dconf, gsettings, and gnome-settings
*civodul is confused
<wingo>gconf is deprecated
<wingo>there is no gnome-settings
<iyzsong>yes, replaced with dconf/gsettings
<wingo>so it's just dconf/gsettings
<wingo>gnome-settings-daemon is the xsettings provider for gnome
<wingo>same as xfsettingsd
<wingo>gnome-settings-daemon also handles other x session util things, like media keys and the like
<civodul>okay, thanks for the clarification :-)
<civodul>media keys?
<wingo>lol introducing "xsettings" is not a clarification ;)
<civodul>like xmodmap?
<civodul>indeed :-)
<wingo>civodul, play/next/pause, etc
<civodul>right, but that seems kind of unrelated
<civodul>i mean, compared to application settings
<wingo>gnome-settings-daemon isn't for application settings
<wingo>it's for the session
<civodul>but gsettings is, no?
*wingo just attempted to pipe some patches to sendmail; we'll see how that goes :P
<civodul>we need 'git send-email'
*davexunit needs to learn to use that better
<wingo>or magit-send-email
<wingo>if that exists :)
<davexunit>civodul: you know 'git send-email' exists, right?
<wingo>ah i thought it was as-yet unpackaged :)
*wingo has used git send-email in the past, but forgotten how it works
<civodul>davexunit: yes, which is why i say we need it
<civodul>our git package doesn't provide it currently
<civodul>i think we were missing a perl dependency or something
<civodul>we probably have it now, thanks to bavier ;-)
<Sleep_Walker>wingo: thanks for that initrd patch - I could drop some of my locally maintained commits
<davexunit>civodul: ohhhh I understand now
<Sleep_Walker>wingo: will you also make kernel configuration configurable? ;)
<wingo>Sleep_Walker, civodul should get most of the credit :)
<Sleep_Walker>wingo: well, you started that change
<wingo>Sleep_Walker, i just needed some things from the latest kernel ;) not aiming on doing more there
<Sleep_Walker>I was looking at that code for some time already
<iyzsong>'git send-email' have serve me for a long time on GuixSD, with sendemail.smtpserver = '/path/to/msmtp'.
<davexunit>every time i try to use it, it nags me for details I feel like I don't need to provide
<davexunit>and it CCs myself
<davexunit>I don't get it.
<davexunit>so I stopped trying to use it.
<civodul>iyzsong: oh right, it's actually there!
<civodul>so it just works?
<wingo>lol at my patches being mailed all out of order, whee
<wingo>i guess rebasing messed up the dates
<wingo>it should be suid root
<wingo>what is the story about that?
<rekado_>I'm confused. In a REPL session (guix-substitute "--query") with "have /gnu/store/cgwlkh0bz5swb4ahnnrdvcg951flvksg-glibc-locales-2.21" just does what it should: fetches narinfo and prints a path.
<rekado_>but on the shell it fails immediately: substitute: updating list of substitutes from ''... 0.0%
<rekado_>(and then the backtrace)
<rekado_>ah, now I can reproduce this in the REPL session.
<rekado_>there's a long list of paths that's passed to guix-substitute --query "have" and at least one of them triggers the crash.
<wingo>civodul, so, i configured a system with polkit and which made pkexec be setuid root
<wingo>it wants to check that $SHELL is in /etc/shells
<wingo>i don't know why
<wingo>but it's not because $SHELL is the precise shell
<wingo>and /etc/shells is just a list of symlinks
<wingo>like /run/current-profile/...
<wingo>instead of /gnu/store/...
<wingo>wondering what to do :)
<wingo>i guess the point of that is to see if the user has a shell
<wingo>or is a no-login user
<wingo>indeed /etc/passwd has full shell paths
<wingo>at least for me and root
<civodul>wingo: would it work if you install $SHELL in the global profile?
<civodul>/etc/shells is really silly in many ways
<civodul>or you could change the 'user-account' decls to use the /run/... file name
<civodul>rekado_: nice that you got this deep! could you mail the details?
<rekado_>civodul: I'll try to make sense of this first, but once I've got some result I'll write the ML.
<civodul>excellent, thanks for investigating
<rekado_>It seems that "have path1 path2 path3" fails, whereas "have path1", "have path2", "have path3" does not.
<rekado_>(I mean as command to "guix-substitute --query")
<civodul>really sounds like an HTTP pipelining issue
<civodul>but then i wonder why nobody complained before
<rekado_>I wonder why *I* didn't complain before. I mean, it worked fine for quite a few commits.
<civodul>yeah that's weird
<mark_weaver>wingo, iyzsong: yeah, simply installing dconf in my profile fixed gnome-terminal so I can change its settings, yay!
<mark_weaver>i didn't even have to restart my session
<mark_weaver>civodul: http-pipelining has been performing very well for me, fwiw
<civodul>good to hear
<mark_weaver>I had a vague recollection of a performance problem once when I first tried it (before it was merged into master), but that might have been hydra itself. in any case, it has worked very well since
<civodul>it's very dependent on whether narinfos are cached in nginx or not
<civodul>but i think it's ok indeed
*mark_weaver just switched to gnome terminal, is glad to be rid of xterm
<mark_weaver>iyzsong: do you think there's a reasonable way to make gnome-terminal able to get what it needs from dconf without dconf being in the user profile?
<joehillen><3 gnome-terminal. I've tried every other terminal and I keep coming back
*mark_weaver too
<davexunit>xterm is a real pain
<davexunit>xfce4-terminal was better
<davexunit>now gnome-terminal is best
<mark_weaver>I couldn't use xfce4-terminal because the meta key didn't work in emacs
<mark_weaver>wingo: regarding the /etc/shells thing: maybe we should just patch the code to ignore /etc/shells in that case
<davexunit>I hadn't tried emacs in the shell
<davexunit>I do most emacsing via the GTK version
<mark_weaver>I basically live in emacs, not only on my local machine, but on the machines I log into remotely as well
<mark_weaver>(if I'm doing any non-trivial work on them)
<davexunit>yeah, I have a few remote emacs sessions
<davexunit>I'm having a strange issue in both xterm and xfce4-terminal that leads me to believe it's not the terminal emulator's fault
<mark_weaver>davexunit: what issue?
<davexunit>where the first character of the command after the prompt...
<wingo>mark_weaver, we could do that
<davexunit>just sticks around
<wingo>i'll look into it
<davexunit>like, if I press the up arrow to see the previous command I ran and press C-a
*wingo afk for a little bit
<davexunit>it will bring the cursor back to what looks like the 2nd character
<mark_weaver>davexunit: maybe something wrong with your PS1 setting?
<davexunit>perhaps that's it
<wingo>so should gnome-terminal have dconf as a propagated input?
*wingo doesn't know how all that works
*wingo really afk :)
<mark_weaver>wingo: making it a propagated-input would certainly work, but it would be preferable to find a solution that doesn't add dconf to the user profile
<mark_weaver>it might be sufficient to simply make it a normal input
<mark_weaver>(adding 'dconf' as a propagated-input would cause 'dconf' to be added to any profile that contains 'gnome-terminal')
<davexunit>2059: the year of the HURD port of GNU Guix :)
<mark_weaver>it's a rather bleak set of near term predictions though
<davexunit>BloodDrone doesn't sound too pleasant
<mark_weaver>hi wingo!
<mark_weaver>civodul: in wingo's colord package, he passed "--disable-bash-completion" to configure with the comment "Wants to install to global completion dir; punt"
<mark_weaver>civodul: I know you've done a bunch of work on bash completion lately in guix. what's the right way to do this?
*mark_weaver suspects that you just let it install bash completion rules in the output dir, and they will all be merged together when building the profiles
*wingo suspects something similar
<wingo>actually maybe it just works
<wingo>however colord wants to install to the dir in the bash-completion.pc file
<wingo>which doesn't work :)
<mark_weaver>wingo: see be3ed52d7b and 16629c8adf
*wingo reboots, brb
<civodul>mark_weaver: completions should go to $prefix/etc/bash_completion.d and ignore what "pkg-config bash-completion --variable=xxx" has to say (since it's broken)
<mark_weaver>civodul: thanks!
<mark_weaver>wingo: ^^
<civodul>mark_weaver: BTW, i'll hopefully be pushing the last fix to core-updates
<civodul>although i don't have an answer to the armhf yet
<civodul>so maybe it's the next-to-last fix
<civodul>who knows
<mark_weaver>wingo: also, the return value of substitute* is not specified, whereas phases should return a boolean indicating whether the phase succeeded. so ideally phases should not end with a call to substitute*
<mark_weaver>civodul: ah, good!
<wingo>mark_weaver, ACK
<mark_weaver>wingo: in practice, substitute* tends to return a true value, but it's not clean
<wingo>maybe in guix we can patch hexchat to complete by default with ":" instead of "," :P
<wingo>so i am wondering what a minimal gnome package looks like
<wingo>gnome-settings-daemon + gnome-shell + gnome-control-center ?
<wingo>+ gnome-session
<civodul>i would think it needs more than this, but really i don't know
<civodul>isn't there formalized meta-data for GNOME package deps, BTW?
<wingo>good question
<wingo>there used to be these "DOAP" rdf files
<civodul>that might be something so reduce work
<wingo>sure, but for core components i don't see the advantage yet -- i.e. gnome-shell is special enough that things can be done by hand
<wingo>so one big thing is that a lot of gnomey bits want the org.freedesktop.login1 interface
<wingo>is there a systemd-logind shim somewhere?
<civodul>not yet
<civodul>is it something that we can just take and spawn and it does its job?
<civodul>(sounds like a stupid question ;-))
<wingo>i understand the perspective :)
<wingo>so it's the evolution of consolekit
<wingo>which is marked as "unmaintained upstream"
<civodul>what do the Gentoo people do?
<wingo>things that fall back to consolekit do so by also depending on other, older parts of systemd, it appears
*wingo checks
<wingo>i think they just install systemd
<civodul>oh, ok
*wingo is ok with systemd, fwiw; no strong perspective
<wingo>but, any non-systemd distro will need a logind
<wingo>too many things depend on it these days
<wingo>gnome won't allow a user to suspend their machine without it, for example :P
<Sleep_Walker>I believe that they put that simple - if you want systemd-less system, your choices will be reduced
<wingo>polkit will have trouble too knowing what users are "active" and what users are not
*mark_weaver wonders how hard it would be to reimplement logind in dmd
<civodul>i wonder if it even has to be tied to the init system
<wingo>mark_weaver, good question!
<wingo>also civodul good question :)
<mark_weaver>well, as a service I mean
<Sleep_Walker>do you really consider logind as good design?
<mark_weaver>not part of dmd core
<wingo>iiui logind is a separate process
<mark_weaver>well, in guile then :)
<wingo>not sure what privileged relationship it has with systemd
<wingo>systemd/src/login is not large
<wingo>there are some references to login1 throughout the rest of the source tho
<mark_weaver>we could start with just a rudimentary stub service for now
<civodul>so what about systemd-logind shim?
<joehillen>I get getting "ERROR: In procedure getaddrinfo: System error" for different packages when I try to do "guix system disk-image --image-size=850MiB gnu/system/install.scm" on guix master
<joehillen>if I rerun the command, it resumes like there is no problem
<joehillen>I assume this is a bug in the nix-daemon
<civodul>joehillen: it seems like a networking issue
<civodul>(getaddrinfo is the function that resolve host names)
<joehillen>I know, but I'm not having any networking issues. I'm running nslookup in watch just to be sure
<civodul>does "getent hosts" succeed?
<civodul>could you paste the full command and output somewhere?
<joehillen>haha, it's the full build log
<civodul>ah no, not the full build log
<civodul>just the lines around the error
<joehillen>here is the most recent one:
<joehillen>here is the one before that:
<joehillen>as you can see, it's a diffent package each time
<civodul>substitutes are disabled, right?
<civodul>also there seem to be many parallel jobs (--max-jobs)
<civodul>"System error" here could be ENOMEM or something like that
<joehillen>I'm just running "guix system disk-image --image-size=850MiB gnu/system/install.scm" out of the git master
<joehillen>I haven't changed any settings
<civodul>guix-daemon is from master, without any --max-jobs flags?
<civodul>and substitutes are disabled?
<joehillen>I didn't disable them
<joehillen>I was running guix-daemon as root, maybe that did it
<civodul>but you didn't enable them either? ;-)
<joehillen>now, I'm relaunching it
<joehillen>oh, I see
<joehillen>so I definitely want substitutes
<joehillen>why isn't that the default?
<civodul>good question
<civodul>it's the default on GuixSD, but we should also make it the default in raw Guix
<mark_weaver>or at least mention it more prominently in the installation docs
<mark_weaver>right now it's in a separate section all by itself as I recall, easy to miss
<mark_weaver>(unless you're looking for it)
***pfo_ is now known as pfo
<joehillen>that would also be good, I was following this
<civodul>mark_weaver: yes, you're right
<joehillen>btw, the guix documentation is fantastic so far. Documentation is part of the reason I gave up on Nix and am now trying Guix
<civodul>joehillen: thanks!
<wingo>mark_weaver, so about logind
<wingo>it seems that it would be feasible to pull logind out to a separate binary
<wingo>oh i thought you were interested :) must have mixed that up
<mark_weaver>yes, I am!
<wingo>oh ok!
<mark_weaver>sorry, the hmm was unclear
<wingo>so logind doesn't live in the cgroup tree or the process tree of anything else
<wingo>it's just a service on the dbus that knows things about users and sessions and such
<wingo>it does manage virtual terminals
<wingo>as a detail
<wingo>but it gets its info about who is logged in via a pam module
<paroneayea>wingo: that's good to hear re: separate binary
<mark_weaver>sounds very promising!
<wingo>the pam module presumably makes d-bus calls to the login service
<wingo>the login daemon
<mark_weaver>just as eudev is a fork of udev for those who don't want to use systemd, I guess we should have a fork of logind
<wingo>yes probably
<mark_weaver>there seem to be no shortage of people who would be interested in such a project
<mark_weaver>e.g. the BSD folks, Hurd folks, and others who strongly dislike systemd
<wingo>i don't understand what the relationship is between logind and "inhibition" or providing users with a hibernation/suspend facility
<wingo>but i guess it is what gnome is using these days
<mark_weaver>(I'm not one of the latter group, but I want to be able to support the Hurd at least)
<wingo>given that you can't suspend from gnome without systemd these days
<wingo>yeah i kinda like systemd :)
<wingo>but i like guix also :)
*civodul looks iyzsong's message about "Secret Service API"
<civodul>isn't it that thing called "the Internet"?
<mark_weaver>heh :)
<paroneayea>the angry systemd haters have done a better job of selling systemd than anyone else :)
<paroneayea>I am happy to see many advancements in areas that systemd are doing, though I also like seeing work on things like dmd, etc, and it's too bad that it's hard to not sound like one of the angrier parts of the internet when what you really want is to support other systems too
<mark_weaver>I have some gripes about systemd, mainly that they have no interest in portability to other kernels and yet are killing off the more portable competition
<mark_weaver>but yeah, the haters are way beyond rationality, IMO.
<mark_weaver>it reminds me a little of all of the GNOME 3 haters
*wingo -> zzzz
<mark_weaver>but there's a lot of great stuff in systemd too. I would just rather have it implemented in Scheme, and supporting the Hurd and other kernels.
<paroneayea>gnite wingo !
<mark_weaver>wingo: good night!
<wingo>haha to go to sleep i have to cat something to something in sys
<wingo>sudo bash -c 'echo mem > /sys/power/state'
<paroneayea>mark_weaver: in some ways, systemd is implementing a lot of ideas from the hurd in a linux-only way ;)
<mark_weaver>paroneayea: what ideas are from the hurd?
<paroneayea>mark_weaver: not really ideas "from the hurd", but if you look at it seems to me that some of them being a message-bus-between-programs (not systemd itself, but the push for kdbus), something similar to journald seems posted in the hurd paper, same with consoled
<paroneayea>a bunch of non-kernel daemons for these things
<paroneayea>plus I think there's something along the lines of more fine grained access control mentioned in poettering's paper on container / application sandboxing support
<paroneayea>which doesn't seem too far off from some of the hurd capability stuff
<paroneayea>I'm not an expert in either of these
<paroneayea>jsut observing from 1000 feet up :)
<civodul>remember those in the 90's who said that IPC is slow etc. etc.?
<civodul>in the 2000's, the same people came up with dbus & co.
<paroneayea>civodul: yeah
<civodul>something which is an order of magnitude slower than what even Mach achieves
<paroneayea>that was partly along the lines of thought I was thinking :)
<civodul>hence kdbus
<civodul>still slower but getting better
*civodul -> zZz
<paroneayea>nice to see the hurd becomes the winning OS far in the future in :)