IRC channel logs

<davexunit>I'll remember the --cover-letter flag next time around.

<davexunit>I've came up with a clickbait blog style title for this: "15 reasons why a GNU hacker is declaring war on Docker and CoreOS"

<civodul>fun :-)

<davexunit>that'll get us on the HN front page for sure ;)

<civodul>haha :-D

<civodul>let me know when you're ready to post

<civodul>i also wanted to post a news entry on GSoC, but we mustn't do both at the same time :-)

<davexunit>civodul: I'm not actually going to post a real article about this for awhile.

<davexunit>I'm rather exhausted. I'll blog about it after my vacation I think.

<Steap>hahahah

<civodul>davexunit: ok, np!

<davexunit>that failing test has been sapping me of all my hack strength.

<civodul>yeah, i sympathize

<civodul>there's a failing test in tests/packages.scm currently on master

<civodul>and it's draining my energy, too

<davexunit>:(

<davexunit>rekado: do you have a description of your guix + nfs setup?

<davexunit>I have someone that might be interested in this setup for the time being.

<davexunit>civodul: would it be possible for someone to run their own hydra instance to build custom packages but pull other substitutes from hydra.gnu.org?

<davexunit>ideally, we need to have the daemon accept multiple substitution sources.

<rekado_>davexunit: the only description I have is in this old blog post.

<rekado_>little has changed since then.

<rekado_>I'm still rather unhappy with the performance.

<davexunit>rekado_: we're going to take a different approach with 'guix publish'

<davexunit>thanks, though!

<rekado_>I'm building texlive-texmf again, directly on NFS, and it's been sitting there since hours.

<rekado_>I've disabled deduplication, but I'm not seeeing much of a difference, unfortunately.

<davexunit>:(

<davexunit>yessss, got a report that 'guix publish' is working as advertised.

<davexunit>victory.

<civodul>davexunit: re hydra, it should be possible, but yeah, 'guix substitute' needs support for multiple sources

<civodul>davexunit: good news re 'guix publish'!

<rekado_>after the install phase started and nothing happened for much too long I attached strace to the build process and only saw this:

<rekado_>select(16, [15], NULL, NULL, {998971, 779701}

<rekado_>just waiting for something, I suppose.

<civodul>rekado_: the build itself is on /tmp, which is not on NFS, right?

<civodul>ah but the install phase, indeed

<civodul>rekado_: also, are you sure you're stracing the right process?

<civodul>see 'pstree'

<rekado_>It's now finally doing something again, lots of lchown, lstat, chmod...

<rekado_>yes, I'm pretty sure it's the right process.

<civodul>ok

<civodul>'make install' does spawn many processes, all doing i/o

<civodul>is it NFSv4?

<rekado_>NSFv3.

<rekado_>(I don't know why central IT insists on version 3)

<rekado_>I also see that geteuid() is called repeatedly and often. That's not a performance concern, but I find it noteworthy.

<rekado_>for each file I get the same syscalls: geteuid (twice), lchown, lstat, chmod, utimensat.

<rekado_>I hope that installing something into a profile is faster now without deduplication than before. texlive may just be an extreme case.

<civodul>rekado_: is it 'make install' that's taking time, or is it the daemon's own stuff that is done afterwards? (that includes scanning each and every file for store references, resetting their mtime, etc.)

<civodul>--disable-deduplication certainly makes the daemon's part faster

<rekado_>I didn't keep track. I just started this a couple of hours ago and it's still working. Right now the last output I see is "phase `texmf-config' succeeded after 70 seconds".

<rekado_>I had to build texlive with max-silent-time set to a very large value, because it is silent for a very long time.

<mark_weaver>davexunit: regarding running your own hydra instance: if what you want is just to do large builds without bogging down your laptop, maybe 'offloading' is the right tool for you?

<davexunit>mark_weaver: yeah, I've considered that, too.

<davexunit>there's various ways to go about this. not sure if that's good or bad. :)

<mark_weaver>hydra is a continuous integration tool.

<mark_weaver>it's for when you want to build everything, all the time.

<mark_weaver>I'm not sure that's what you need, is it?

<mark_weaver>hydra uses the offloading mechanism itself. I don't think there's a redundancy here.

<davexunit>yeah each method is different.

<davexunit>there's just many to consider for a given situation.

<davexunit>the way that seems to work best here is using 'guix publish'

<Bert_Gold>Where can I find the xorg.conf file on guixsd?

<mark_weaver>Bert_Gold: there is no global xorg.conf file on GuixSD. It is an immutable file in the store, generated as part of 'slim-service'.

<mark_weaver>if you really want to see it, I can help you find it, but it's not trivial, and you can't edit it directly.

<mark_weaver>what are you trying to do?

<Bert_Gold>Trying to set up a second monitor

<Bert_Gold>What would be the least painful way to do that?

<mark_weaver>xrandr is the tool you should look at

<mark_weaver>or just use the GUI configuration tool in XFCE.

<Bert_Gold>I tried xrandr and it just crashes X

<Bert_Gold>ill try the xfce tool though, thank you!

<mark_weaver>xrandr crashes X? that's not good :-(

<mark_weaver>I think the XFCE tool probably uses the same xrandr interface.

<Bert_Gold>:(

<mark_weaver>but anyway, in XFCE, from the settings menu, choose "Display"

<mark_weaver>the code that generates the xorg.conf file is in gnu/services/xorg.scm

<Bert_Gold>ok

<mark_weaver>if you needed to change what's in that file, that's the code that should be edited (in a git checkout of guix), and then it would take effect when you run "guix system reconfigure" using the guix from the git checkout.

<mark_weaver>and if it turns out that people legitimately need to change what's in that file, then we should consider adding some relevant arguments to 'slim-service' in the OS config file.

<mark_weaver>but my understanding is that in modern times, most things are handled automatically.

<alezost>not everything is handled automatically (for example, my monitor's EDID is dead, so I have to configure it in a conf file), also I prefer to set up standby/suspend/... time and keyboard/mouse settings in a conf file instead of using xset or setxkbmap.

<alezost>but it's not the issue for me as I don't use slim service

<Bert_Gold>Changing the xfce display settings crashes X on start now >.<

<Bert_Gold>ddd

<amz3>looks like a rage quit

<amz3>both monitors works with slim/xfce and slim/dwm

<amz3>davexunit: bravo for the release of containers :)

<amz3>brb

<mark_weaver>I should probably rebase my 'wip-xorg-server-1.17' branch. the main issue at the time was that some of the bit-rotted drivers wouldn't compile against the new server. as I recall, arch+parabola simply dropped those drivers.

<mark_weaver>but yeah, on my X60 and X200, multi-monitor works fine in my experience.

<davexunit>amz3: it ain't released yet. ;)

<zacts>hi guix

<codemac>Question about making packages: I just created a package for rc - and I noticed that the autoreconf rule of (guix build gnu-dist) isn't exported, and many packages define their own autoreconf routines that are all very similar.

<davexunit>codemac: might be nice to deduplicate if that procedure could indeed be made public.

<jackdaniel>I really like how I can easily switch between package versions with guix

<jackdaniel>:)

IRC channel logs

2015-07-06.log