<joehillen>on GuixSD "shutdown -h now" returns "command not found". How do I turn this thing off? <joehillen>mark_weaver: thanks, I also notice "ip" is missing. Any idea why GuixSD is so different from other Linuxes? <mark_weaver>joehillen: 'ip' is part of the 'iproute2' package. you need to install it <joehillen>I see. Any reason it's not part of %base-packages? <mark_weaver>it may be that we should add it. I think it's not there because relatively few people are in the habit of using those commands instead of the older 'ifconfig', 'route', etc. <joehillen>yeah, I forced myself out of the habit in the last year, so it's odd to be teleported back in time ;) <mark_weaver>joehillen: I'd like to get in the habit of using them too. *kete was wondering where ip was. thanks <effa`>Hi, I noticed that hydra attempted to build the GHC libraries that I submitted yesterday for mips64el. However, the package 'ghc', which is an implicit input of the 'haskell-build-system', specifies "(supported-systems '("i686-linux" "x86_64-linux"))". Shouldn't Guix only build those libraries for the two platforms specified in the 'ghc' package? <effa`>actually 'ghc' is the default compiler, not an implicit input. <civodul>the problem is that package-transitive-supported-systems doesn't take implicit inputs into account <civodul>effa`: yes, we need to fix package-transitive-supported-systems :-) <civodul>it should operate on "bags" rather than packages <wingo>civodul operates on higher level than us normal people :) <civodul>(or was that a Frenchism on my side?) *kete works harder than most people, too. <nully>civodul: I'm sureyou heard about thecool work MH was up to? <civodul>nully: yes, i was about to thank you & mark_weaver for the good news! <nully>i told you i'd figure `something' out lol <civodul>and also for the extra disk space that you added recently <nully>no worries, i'll be reclaiming it all eventually <nully>when i kick u guise off my volumes, onto your own <nully>takes slowness offyour build times <wingo>civodul, no it's just that you are a wizard :) <nully>So what is left,idk if MH told you guise whats up <nully>Hes gotta recompile coreboot for the box, and then we shouldbe ready to do some testing <nully>then i'll dump it in a colo witha fat pipe <wingo>i think the other day i did "deco enable foo bar baz" and it made init die and the kernel panicked <taylanub>rekado_: the .pc files generated by the Makefile are inadequate. most distributions add one themselves. so far I was able to work around problems in other ways. I bothered the Lua ML a bit and maybe in the next release they'll start installing proper .pc files. <taylanub>I think it happened twice that I had problems due to Lua not providing a .pc file, yet the build process of some software trying to detect Lua via pkg-config. maybe I should have patched our Lua package(s) to provide .pc files instead of fixing the build processes of the other software. <rekado_>taylanub: I was going to build the optional Lua module for shogun and then noticed that Lua cannot be found with the Cmake build system. <rekado_>all it does is try to make sure the required Lua version exists. <rekado_>so I think even a minimal pc file would be useful in these cases. <taylanub>yeah, that's at least issue #3, so I guess it would be better to put .pc files in our lua packages than to fix all the build processes assuming they're there <taylanub>(and my issues were with autotools- and waf-using software, so can't give advice on cmake) <ph4nt0mas>I am waiting till tomorrow and I will rebase my local simplified wip-hurd branch on wip-hurd and push it. <ph4nt0mas>Have some new patches, will send them to the mailing list tomorrow <ph4nt0mas>the hurd guys are working on updating their glibc to 2.21 <davexunit>if these shirts are in-demand enough, we should talk to the FSF about selling them instead. <davexunit>that way it raises money for the FSF/GNU project *ph4nt0mas considers buying some extra to gift them to a couple of friends that starting using windows recently, maybe then, they will return to the light side!! <civodul>wingo: re deco, that's fun indeed, glad you liked it ;-) <civodul>i don't remember having problems like this <civodul>but one known issue is that if a service definition is broken, you get a kernel panic on boot <wingo>yeah i think i got that at one point <civodul>yeah not so nice, but easily fixed i guess <wingo>i had to step back from guix for a while; need to get other things done... <wingo>looking forward to core-updates landing tho <wingo>then i can be a bit less abnormal :P <civodul>we had that armhf fix, so now it should be a matter of 2-3 days <wingo>i think icecat is preventing that site from showing me the back of that shirt :) <davexunit>librejs has *major* flaws that must be fixed before it can be considered usable <davexunit>I'm used to more limited color palette options <davexunit>in either case, I can throw $20 at this and see how it turns out <davexunit>civodul: interested in your thoughts about that <mark_weaver>nully: can you remind me again of the irc proxy program you told me about? <freaj>Weechat is the best, the only one, it must be weechat... <nully>i switched from irssi to erc 2 days ago <nully>i have a lot of weechat users who are my friends <mark_weaver>nully: thanks! and the thing that blocks addresses that try to log in via ssh? <civodul>davexunit: it seems a bit heavyweight to me, that applications comes with their deps *mark_weaver is forgetful :) <freaj>I have to see some screenshots of ERC.. I'm tempted to be in Emacs world <civodul>davexunit: it seems to be proprietary-app inspired as well <nully>its okay, i will file a FOIA request with the NSA for transcripts of our convo :D <davexunit>civodul: maybe we're biased, but every time a new project like this crops up, I just think that guix solves the problem better. <davexunit>civodul: bundling is always inspired by proprietary applications, who can't be bothered to work with distributions. <davexunit>in theory, guix could just as well be used to generate those bundles. <davexunit>build your application as a guix package, and package up the closure for distribution <davexunit>the second "package" is a misnomer, I mean "stuff it into a tarball or zip or something" <mark_weaver>so, I noticed that we lack mdadm in guix currently. I added a package last night (not yet posted), but I wonder if we'll need to add something to our initrd to auto-assemble arrays <civodul>davexunit: right, that's someting that can be done with 'guix archive --export' <joehillen>hey guys, I'm around if you want to talk about authorized keys <civodul>mark_weaver: could be, i don't really know what it takes <civodul>or maybe "i really don't know" is more accurate <davexunit>I haven't run a RAID in awhile, but you need something to generate the mapped devices <civodul>joehillen: sure, or the mailing list is fine, because it's archived and gives more time for thoughts :-) <civodul>davexunit: we already have support for mapped devices though <davexunit>civodul: okay, so maybe nothing is needed, as long as we have the right kernel module <joehillen>civodul: well, I'd like to get a quick and dirty solution so that I can keep moving forward with my current project before something is added officially. Is there anything you can suggest? <davexunit>my initial reaction to this issue is that we need to add a field to <user-account> that specifies files that should appear in the user's home dir. <joehillen>mark_weaver: I need to be able to manage users ssh authorized keys at the (operating-system ...) level so they can ssh in when the system boots. <mark_weaver>I have mixed feelings about making ~/.ssh/authorized_keys part of the state managed at the OS level <mark_weaver>from a technical standpoint, it would be straightforward enough to list the authorized keys for each user, and then either overwrite or merge those into ~/.ssh/authorized_keys at activation time <mark_weaver>s/to list/to have the user-account include a list of/ <mark_weaver>I guess we should have something like this, since it is often quite desirable <civodul>joehillen: something like what davexunit & mark_weaver suggest sounds good <civodul>then comes the question of the format: OpenSSH? lsh? <mark_weaver>this reminds me of the idea of declaring the set of wireless networks to connect to in the OS config. some users will want it, and some very much won't want it. <civodul>for OpenSSH, it's just a matter of populating ~/.ssh/authorized_keys <civodul>for lsh once needs to run 'lsh-authorize' <davexunit>mark_weaver: well, if the user doesn't want it, they don't configure it, and guix doesn't touch anything in their home dir. <civodul>so it's a simple feature but it has ramifications <mark_weaver>maybe the answer is to have an 'ssh-authorized-keys' field in the user-account that defaults to #f, in which case it is not touched <civodul>joehillen: note that a quick hack is to add a service that just creates ~/.ssh/authorized_keys <mark_weaver>or it can be a list, in which case ~/.ssh/authorized_keys (and the lsh equivalent) are overwritten during activation <civodul>joehillen: see 'configuration-template' in (gnu system install) for such a hack <davexunit>I'm still curious about if we should specialize on SSH keys, or provide a more general facility <civodul>right, there could be something more general <civodul>like a 'files' field in 'user-account' <davexunit>a more general mechanism would allow me to create servers whose users have a bashrc setup just the way I like it or something <mark_weaver>davexunit, civodul: sure, seems quite reasonable. maybe that's the better way. <civodul>well there's the "skeletons" for bashrc <davexunit>civodul: but this would be more than a skeleton, more specific. <davexunit>I want the 'dave' user to have this particular bashrc (and other dotfiles) <civodul>yeah so 'files' in 'user-account' probably <davexunit>now, I don't think this satisfies the lsh thing, though <davexunit>I wouldn't want to allow for calling arbitrary commands, because they may not be reproducible <joehillen>I'd definitely want 'files' for bashrc etc, too <davexunit>joehillen: yeah, I think the 'files' idea should be implemented, regardless of the solution for the lsh thing. <davexunit>joehillen: thanks for pushing the issue. I would have wanted this feature soon enough anyway. <davexunit>so hopefully by the time i deploy a guixsd server the feature has been added. :) ***boegel is now known as boegel|afk
<jxself>Oh, there are t-shirts? Exciting. <davexunit>lol homebrew ("the missing package manager for OS X") is getting a GNU/Linux port <davexunit>homebrew - the missing package manager for GNU/Linux... <civodul>wingo: i think you forgot to send upower, needed by gnome-settings-daemon <wingo>for many of these dbus services it's a bit irritating to have to specify a service <wingo>because they can be activated by the bus as needed <wingo>the service is just needed to make sure they have their /var/lib/upower or whatever <wingo>that's the case for colord too i think, and geoclue <Steap>Do we want the update of Python to be in master or in core-updates ? <wingo>my entrance to guix was a big mess :) <civodul>a big patch set as well, which is cool :-) <civodul>not sure how we should handle /var/lib/upower and such <civodul>Steap: can go to core-updates if you can test it relatively quickly <civodul>otherwise we can make a separate branch <civodul>core-updates has seen so many changes that i'm a bit concerned ;-) <Steap>civodul: well my patch works on master, but I can only test on x86_64 <Steap>the patch does not apply on top of core-updates, so it's a bit of a pain to adapt it and later merge it <civodul>(you can actually use "-s i686-linux" too) <civodul>still, would it be possible to adapt it to core-updates? <civodul>the problem that i see is that it needs a full rebuild <Steap>k, I'll do that on top of core-updates <civodul>wingo: was upower-builddir.patch posted upstream? *bavier is wondering whether to put another patch in core-updates <bavier>there's a patch from nixpkgs for a core perl module that appears crucial to running an eventual hydra package <civodul>that would have to wait for the next cycle <bavier>yes, one of the core modules from perl <bavier>I'm not sure I can get hydra ready in time <civodul>we have to freeze the branch at some point otherwise we're stuck in an infinite loop <mark_weaver>blah, someone changed emacs-24.5-rc3.tar.xz in place, without changing the version number