IRC channel logs

<jxself>You should have said something. You could have stayed at my hotel (the kendall next to the conference) for free. That doesn't help with getting there but maybe it'd have been something.

<davexunit>mark_weaver: I'm sure you can attend free of charge if you would like.

<mark_weaver>I already live within easy bicyling distance

<davexunit>given your history with the FSF and GNU.

<davexunit>if you'd like to show up, just let me know and I'll talk to registration.

<mark_weaver>thanks, davexunit

<paron_remote>mark_weaver: if you do make it by I'd love to say hello and meet you

<mark_weaver>paron_remote: that would be nice! I'll have to see if I can get some time away from my child care duties

<Sleep_Walker>FYI http://curl.haxx.se/mail/archive-2015-03/0026.html

<civodul>Hello Guix!

<mark_weaver>hi civodul!

<hellekin>mark_weaver: go with your child(ren) :)

<mark_weaver>civodul: did you notice the build failures in core-updates?

<mark_weaver>lots of occurrences of [string-append #f "/bin" ":" #f "/bin"]

<mark_weaver>ERROR: In procedure string-append: Wrong type (expecting string): #f

<mark_weaver>e.g. http://hydra.gnu.org/build/320333/nixlog/4/tail-reload

*mark_weaver is sorely tempted to temporarily change hydra's configuration to add more i686 build slots, just to finish building the openssl-update

<mark_weaver>we really need to rewrite hydra. I want to enhance it in several ways, but am not enthusiastic to brush up on my perl :-/

<davexunit>'guix publish' is a step in that direction :)

<Sleep_Walker>perl?

<Sleep_Walker>oh noes, we're screwed

<mark_weaver>heh :)

<mark_weaver>davexunit: indeed!

*mark_weaver temporarily swapped the number of build slots allocated to x86_64 and i686.

<mark_weaver>x86_64 now only has 3 build slots, and i686 has 7.

<afleck>can I add a user in GuixSD without updating my configuration?

<les>surely you can just use useradd in Guix SD...?

<davexunit>yeah, you can do it.

<davexunit>it won't be managed by the system, though

<davexunit>where 'the system' is guix

<afleck>davexunit: useradd isn't available to root

<davexunit>afleck: you can install it

<afleck>davexunit: I see that updating the config adds the user without the need for rebooting

<davexunit>yes, that can be done.

<davexunit>it's best to keep everything in the system config

<davexunit>for reproducibility's sake.

<afleck>davexunit: understood

<civodul>mark_weaver: i hadn't noticed, thanks for the heads-up!

<mark_weaver>np!

<alezost>/me likes that his latest system is called /gnu/store/day856bhxmq5jc4l5l3wscbqznm1jw7s-system

<alezost>I have several "/gnu/store/*day*" but only one "/gnu/store/day*" :-)

<Sleep_Walker>heh

<mark_weaver>:)

<Sleep_Walker>it reminds me one phoronix test parody, where they were comparing hash of installation DVDs of various distributions

<Sleep_Walker>openSUSE got better since previous version!

<Sleep_Walker>with they .... they improved MD5 but SHA256 is still low

<Sleep_Walker>btw. another day boot with dbus-system stale pid file :(

<mark_weaver>Sleep_Walker: I have a fix for that in my own private branch, but it's not quite a proper fix.

<Sleep_Walker>in bash I'd just write:

<Sleep_Walker>[ -f /var/run/dbus/pid -a -d /proc/$(cat /var/run/dbus/pid)/ -a "$(tr '\\0' ' ' < /proc/$(cat /var/run/dbus/pid)/cmdline)" != "dbus-daemon --system" ] && rm

<Sleep_Walker>/var/run/dbus/pid

<Sleep_Walker>in scheme I need to run shell :b

<mark_weaver>here's what I'm using for now: http://paste.lisp.org/+34Z5

<Sleep_Walker>well, that is quite aggressive approach for one stale pid file :)

<mark_weaver>well, that's what pretty much every POSIX system does at boot time

<Sleep_Walker>please, make it at least optional

<mark_weaver>really??

<Sleep_Walker>yes

<mark_weaver>you don't want /tmp and /var/run clean up at boot time, like every other system I've ever seen does?

<Sleep_Walker> /tmp is directory where guix-daemon have it's space

<Sleep_Walker>so failing builds are there as well

<civodul>"every" might be a bit strong, i've seen some that don't do it

<Sleep_Walker>and some just rely on tmpfs

<Sleep_Walker>but I have seen bug reports that their /tmp was wiped

<mark_weaver>okay, we can all have our systems the way we want them. I can always continue using my private patch if needed.

<davexunit> /tmp is always cleared on every gnu/linux system I use

<mark_weaver>I apologize for my reaction

<davexunit>if you want to keep a failed build, 'cp -r'

<mark_weaver>it just caught me by surprise

*davexunit wishes he had time to demo guix to folks at LP

<mark_weaver>I'm really surprised that guix master still has no provision to clean up /tmp and /var/run. the number of times I had to manually clean everything up and either restart a bunch of deamons or reboot was too high for me.

<mark_weaver>but I guess it's not bothering too many users, or else we'd hear more complaints

<davexunit>I think we should have something

<davexunit>looking back on what I thought were random startup errors, I think they were a result of this

<civodul>mark_weaver: i thought you would add a service to clean up /tmp, and we'd handle /var/run when the blocking issue is fixed, no?

<Sleep_Walker>davexunit: seriously you want me to make extra action to conform something I don't want? :)

<Sleep_Walker>(ad 'cp -r')

<mark_weaver>civodul: /var/run is the thing that prevents daemons from starting up about 95% of the time.

<mark_weaver>it's relatively rare that /tmp prevents X from starting up

<Sleep_Walker>it happend to me only once - moment ago

<mark_weaver>I needed something to make my own system come up cleanly after a crash.

<civodul>mark_weaver: sure, but there's a bug to fix for that

<davexunit>yeah, my display manager fails to start frequently

<Sleep_Walker>ok, I'll ask in different way - do we agree that setting up service should be part of service code?

<civodul>(i hope you're not "surprised" that the bug is not fixed)

<Sleep_Walker>e.g. service definition should be responsible for dealing with reasons leading to not starting the service...

<civodul>davexunit: BTW, how's everything at LP?

<davexunit>civodul: crazy, but going pretty well.

<davexunit>we have technical issues with streaming, which I anticipated, but right now each of the 3 rooms is streaming live pretty well

<mark_weaver>at first, I wanted to make this clean-up job its own service, but I found no reasonable way to specify the needed constraints to make it run at the right time.

<davexunit>one room as desynced audio, but we can live with that for today at least

<mark_weaver>I posted about my difficulties.

<civodul>mark_weaver: i replied, no?

<mark_weaver>I agree that there's a better fix for this, but I was impatient to get *something* that did the job I needed first.

<civodul>yes, i can understand

<mark_weaver>civodul: yes, you did. I think your proposed way forward sounded good.

<civodul>ok

<Sleep_Walker>I can't find the mail you're talking about right now - I'm asking in advance if such patch would be accepted

<Sleep_Walker>that's all

<Sleep_Walker>I really don't feel like distribution architect written in some crazy language (like scheme :)

<mark_weaver>I think it's a bad idea to just delete pid files before trying to start a daemon. what is the daemon is actually running? there's a reason why daemons refuse to start when there's a pid file around.

<mark_weaver>*what if

<Sleep_Walker>my approach was the one written in bash

<Sleep_Walker>read pid

<Sleep_Walker>check if it is running

<Sleep_Walker>check if it is dbus system service

<Sleep_Walker>in all other cases - delete

<Sleep_Walker>when this can fail?

<mark_weaver>so you're opposed to cleaning /var/run at startup?

<Sleep_Walker>and what will happen if DBUS would sigsegv?

<Sleep_Walker>cleaning /var/run on boot should be problematic

<Sleep_Walker>*shouldn't

<Sleep_Walker>sorry :)

<mark_weaver>good :)

*davexunit almost has cleaned up 'guix publish' patches

<mark_weaver>I have to go afk for a while

<Sleep_Walker>but it doesn't mean that pid file removal shouldn't go there as well :)

<Sleep_Walker>sorry, I just got attention of badger from curl project about the problem I wrote

<civodul>davexunit: yay!

<civodul>mark_weaver: the core-updates issue should be fixed now

<civodul>i guess i had only built the "commencement" stuff, which is why i didn't notice :-/

<mark_weaver>civodul: thanks!

<Sleep_Walker>I'd like to build curl from git snapshot, where is (obviously) no configure etc, how can I add libtool into `guix environment curl' without editing package definition?

<civodul>Sleep_Walker: currently you can't

<civodul>i happen to have the autotools in my main profile

<civodul>so i also get them in 'guix environment'

<Sleep_Walker>so do I

<Sleep_Walker>I need libtool

<civodul>yeah i have that in my profile, so it works for me

<civodul>but 'guix environment' doesn't help currently

<Sleep_Walker>ok

<Sleep_Walker>./configure: line 6869: syntax error near unexpected token `GUILE,'

<Sleep_Walker>./configure: line 6869: `PKG_CHECK_MODULES(GUILE, guile-2.0 >= 2.0.5)'

<Sleep_Walker>chm

<Sleep_Walker>configure fails for me now in `guix environment guix'

<Sleep_Walker>Can't exec "autopoint": No such file or directory at /gnu/store/899iy9q1k58y13cbb7sqvf07qxllk136-autoconf-2.69/share/autoconf/Autom4te/FileUtils.pm line 345.

<Sleep_Walker>(autoreconf -ifv fails)

<mark_weaver>Sleep_Walker: that indicates that pkg-config was not installed when you ran autoreconf

<Sleep_Walker>I'd say the same

<Sleep_Walker>but it is present in ACLOCAL_PATH in current environment

<Sleep_Walker>but not in other PATH

<mark_weaver>PATH is not relevant for this issue

<mark_weaver>autoreconf was unable to find pkg.m4 when it built configure

<Sleep_Walker>chm

<Sleep_Walker>after re-running aclocal and autoconf it seems to be built correctly

<mark_weaver>Sleep_Walker: autopoint is part of 'gettext'. I guess you need that package also

<mark_weaver>(the name of the variable is 'gnu-gettext')

<Sleep_Walker>thanks

<Sleep_Walker>native-inputs should be available in `guix environment <package>' as well, right?

<mark_weaver>if not, that's a bug :)

<davexunit>Sleep_Walker: should be

<Sleep_Walker>my fault completely

<Sleep_Walker>I have source /etc/profile in .bashrc

<davexunit>we call 'bag-transitive-inputs', which should get inputs, native-inputs, and propagated-inputs

<davexunit>ahhhh yeah

<davexunit>so it clobbered your paths

<Sleep_Walker>yup

<Sleep_Walker>damn

<mark_weaver>I don't set any environment variables in .bashrc, for that reason

<mark_weaver>I set them in .bash_profile

<Sleep_Walker>I needed to learn it hard way :)

<Sleep_Walker>I always wondered why these profile scripts are so overly complicated

*civodul looks at the 54 stashes in his repo, thinking it's really too much

<mark_weaver>54!! :)

<mark_weaver>admittedly, I have some big guile work that I've never submitted

<davexunit>my stashes are also piling up

<Sleep_Walker>heh, I put them into branches already :b

<davexunit>I have a lot of branches too

<civodul>i try to remove those that have become irrelevant once in a while

<civodul>maybe i should be more aggressive or something ;-)

<mark_weaver>so far, hydra has spent 2 hours and 15 minutes generating an evaluation for master

IRC channel logs

2015-03-21.log