<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>once we don't have to reboot after a reconfigure due to dmd <cmhobbs>why are there SRFIs included with guix? <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 <{}grant>mark_weaver: Yeah, ty, that worked. But yeah having a symlink or similar probably isn't a bad idea. <{}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 <{}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. <{}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. <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>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. <{}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>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>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. <mark_weaver>it is glibc that declares a search-patch for LOCPATH <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? *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 <rekado>okay, I commented on this on the ML and did without making an explicit dependency on glibc-locales. <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_>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>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"? <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-0.8.1.6e1bb64201b94d4d1a802a5c4340bf5da54a40ca.drv-1/source/test-tmp/var/9951/daemon-socket/socket <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 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>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 <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? <wingo>i think because system-qemu-image should be applying (operating-system-initrd os) <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 <wingo>civodul, not sure :) maybe you're 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: does 'guix system build config.scm' build it as well? <wingo>civodul, no, guix system build os-config.scm does not build linux-libre <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' *wingo has built a gnome-settings-daemon :) <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>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_>in the meantime system updates have been installed and the machine has been rebooted. <rekado_>then guix has been rebuilt and installed. <civodul>hmm normally the workarounds in (guix http-client) apply as needed, with a run-time check <wingo>iyzsong, awesome work packaging webkitgtk+ !!! <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? *wingo doesn't really believe in hierarchies <wingo>thing is, hierarchy often gets in the way <wingo>it's easier to refactor a flat structure <wingo>and often you don't know what the hierarchy should be <wingo>that's especially the case for packages that could go under multiple roots <civodul>having experienced the deeeep hierarchy in Nixpkgs <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 <wingo>so it's just dconf/gsettings <wingo>gnome-settings-daemon is the xsettings provider for gnome <wingo>gnome-settings-daemon also handles other x session util things, like media keys and the like <civodul>okay, thanks for the clarification :-) <wingo>lol introducing "xsettings" is not a clarification ;) <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 just attempted to pipe some patches to sendmail; we'll see how that goes :P *davexunit needs to learn to use that better <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 <Sleep_Walker>wingo: will you also make kernel configuration configurable? ;) <wingo>Sleep_Walker, civodul should get most of the credit :) <wingo>Sleep_Walker, i just needed some things from the latest kernel ;) not aiming on doing more there <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 <civodul>iyzsong: oh right, it's actually there! <wingo>lol at my patches being mailed all out of order, whee <wingo>i guess rebasing messed up the dates <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_>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>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>i guess the point of that is to see if the user has a shell <wingo>indeed /etc/passwd has full shell paths <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. <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. <mark_weaver>wingo, iyzsong: yeah, simply installing dconf in my profile fixed gnome-terminal so I can change its settings, yay! <mark_weaver>civodul: http-pipelining has been performing very well for me, fwiw <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 *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>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 <mark_weaver>I basically live in emacs, not only on my local machine, but on the machines I log into remotely as well <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 <davexunit>where the first character of the command after the prompt... <wingo>mark_weaver, we could do that <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? <wingo>so should gnome-terminal have dconf as a propagated input? *wingo doesn't know how all that works <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 <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 <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) <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 ld.so yet <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>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 ? <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>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>is it something that we can just take and spawn and it does its job? <wingo>i understand the perspective :) <wingo>so it's the evolution of consolekit <wingo>which is marked as "unmaintained upstream" <wingo>things that fall back to consolekit do so by also depending on other, older parts of systemd, it appears <wingo>i think they just install systemd *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>also civodul good question :) <wingo>iiui logind is a separate process <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 <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 <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 hydra.gnu.org" succeed? <joehillen>18.4.89.46 20121227-hydra.gnu.org hydra.gnu.org <civodul>could you paste the full command and output somewhere? <joehillen>as you can see, it's a diffent package each time <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 <civodul>guix-daemon is from master, without any --max-jobs flags? <joehillen>I was running guix-daemon as root, maybe that did it <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 ***pfo_ is now known as pfo
<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 <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 <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>but it gets its info about who is logged in via a pam module <wingo>the pam module presumably makes d-bus calls to the login service <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 <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 :) *civodul looks iyzsong's message about "Secret Service API" <civodul>isn't it that thing called "the Internet"? <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>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. <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 ;) <paroneayea>mark_weaver: not really ideas "from the hurd", but if you look at http://www.gnu.org/software/hurd/hurd-paper.html 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>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 <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. <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 :)