IRC channel logs


back to list of 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.
<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>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
<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>yessss, got a report that 'guix publish' is working as advertised.
<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>'make install' does spawn many processes, all doing i/o
<civodul>is it NFSv4?
<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.
<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
<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 >.<
<amz3>looks like a rage quit
<amz3>both monitors works with slim/xfce and slim/dwm
<amz3>davexunit: bravo for the release of containers :)
<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