IRC channel logs

<civodul>Hello Guix!

<Sleep_Walker>morning

<Sleep_Walker>hm, I'm afraid I was correct

<Sleep_Walker>it first tries to mount filesystems and then run udev

<Sleep_Walker>I need to mount base filesystems

<Sleep_Walker>then start udev

<Sleep_Walker>and then mount other mounts

<civodul>right, udev is started after switch-root

<civodul>is it a problem?

<Sleep_Walker>I need to mount filesystems after starting udev

<civodul>including root?

<Sleep_Walker>no, root is mounted already from initrd

<civodul>ah sorry, i see

<Sleep_Walker>I'm mounting some additional mounts, /home is among them

<civodul>file-system-service has a #:requirements parameter that you could use to have them depend on udev

<civodul>but there's some chicken-and-egg issue i'm afraid

<civodul>well dunno, you should try :-)

<Sleep_Walker>I'm afraid that I need to split file-system-service for base (%base-file-systems) and rest

<Sleep_Walker>so there is root-file-system-service, base-file-system-service, file-system-service

<Sleep_Walker>and file-system-service will depend on udev

<civodul>i don't think it needs to be split, there's already a #:requirements parameter for that

<civodul>but what i wonder is whether file system services can just depend on udev

<Sleep_Walker>if I won't split it, it can't

<Sleep_Walker>I'll give a try and see

<Sleep_Walker>whether #:requirements will help

<Sleep_Walker>I'm so close! :)

<civodul>good! :-)

<Sleep_Walker>so, I won't use filesystem structure, but service part of configurtion, right?

<civodul>well, do whatever seems appropriate

<civodul>what do you mean?

<Sleep_Walker>file-system doesn't seem to support #:requirements http://www.gnu.org/software/guix/manual/guix.html#File-Systems

<Sleep_Walker>it's implemented on services level http://www.gnu.org/software/guix/manual/guix.html#Services

<Sleep_Walker>so I need to define file-system-service instance in services section of system configuration instead

<civodul>file-system-service, not file-system

<civodul>see (gnu services base)

<Sleep_Walker>yes, that's is what I mean

<civodul>for a start, you could just change other-file-system-services to always pass #:requirements `(udev ,@requirements)

<Sleep_Walker>OK!

<Sleep_Walker>I made it into:

<Sleep_Walker>- #:requirements (requirements fs)

<Sleep_Walker>+ #:requirements (cons eudev (requirements fs))

<civodul>should be (cons 'udev (requirements fs))

<civodul>the dmd service is called udev, not eudev

<Sleep_Walker>OK

<toothbrush0>hey all, is it normal that hydra.gnu.org is slower than treacle in winter? or is that to do with the core update merge? (it might also be PEBKAC though..)

<sturai>Hello, I am new to this topic and of course I am an amateur to programming. I would like to know if there is some website where I can see the Guix running as an OS

<iyzsong>sturai: Hi, I'm running Guix (or GuixSD, the distro name) as an OS. By website, you mean image, video or product server?

<Tsutsukakushi>i think he might mean just a webpage that's being hosted on GSD

<civodul>toothbrush0: "slower than treacle in winter"? :-)

<civodul>toothbrush0: but yeah, i'm afraid it's "normal" :-/

<civodul>i logged in and load is relatively low, everything seems normal

<civodul>so presumably it's the other VMs on that machine that are slowing it down...

<toothbrush0>civodul: ah, it's an idiom -- treacle is a sort of syrup

<toothbrush0>so it's a thing that is slow. and in winter it's cold, so it's slower :p

<toothbrush0>i was getting like 0-5Kb/s :/ it stalled every time i tried to install a package

<civodul>sounds like a Canadian expression

<civodul>nully: any idea what makes hydra.gnu.org so slow today?

<civodul>nully: to me it really sounds like the problem currently is with other VMs on that machine

<civodul>today is Gateway Time-out day

<civodul>it takes a great deal of code to implement it

<civodul>but here it is: http://hydra.gnu.org/jobset/gnu/core-updates

<iyzsong>civodul: I have build 'mariadb' both on master and core-updates, both missing 'libgcc_s.so'.

<iyzsong>But without '-DBUILD_CONFIG=mysql_release', it was ok (linked with libgcc_s.so) IIRC..

<civodul>iyzsong: can you give the full details, like which binary, what does ldd say, objdump -x |grep PATH, etc.

<civodul>could you paste the build log then?

<civodul>they might be using --disable-new-dtags or something

<iyzsong>the build failed when it try to run './gen_lex_hash', reported "error while loading shared libraries: libgcc_s.so.1: ..."

<iyzsong>I run ldd and patchelf to check, all executables built has linked with libstdc++.so and a not found item for libgcc_s.so. it does has a RUNPATH to gcc-lib.

<civodul>iyzsong: could you paste the build log, or at least the part where gen_lex_hash is linked?

<iyzsong>sure. ./sql/CMakeFiles/gen_lex_hash.dir/link.txt => http://codepad.org/8rAjD0cB

<iyzsong>I have the failed build saved ;-)

<iyzsong>and 2.3M build log: https://gist.github.com/813564c837aa2ed8d62a

<civodul>ooh -static-libgcc

<civodul>(what's the point?)

<civodul>iyzsong: could you email bug-guix@gnu.org with this command and the resulting issue?

<iyzsong>civodul: sure.

<civodul>thanks!

<bavier>debugging this hydra package is a bit of a pain. It takes "forever" to calculate the derivation.

<civodul>it's an opportunity for optimization :-)

<bavier>I have an inkling that it's all the propagated inputs

<civodul>could be

<civodul>so i think we can merge core-updates now?

<mark_weaver>bah, an unexpected pass causes "make check" to fail? :-/

*mark_weaver tries again to fix the test-async-cancel test failures....

<mark_weaver>civodul: I just merged 'master' into 'core-updates', and there are a bit over 100 builds per platform in the queue

<mark_weaver>including things like emacs

<mark_weaver>and icecat

<civodul>oh emacs too?

<mark_weaver>I'm actually surprised how many rebuilds happened. not sure which package it was that caused this.

<civodul>ok will wait a bit longer :-)

<civodul>dunno

<mark_weaver>anyway, I think we should wait for those things to build

<civodul>well it's ok to not have 100% built, but emacs is a good indication that we should wait more

<mark_weaver>and icecat too

<mark_weaver>icecat takes a long time to build, and most everyone wants it

<civodul>yeah

<mark_weaver>blah, it's a pain to disable a single test without running automake again

<civodul>yeah but it's still worth doing it

<mark_weaver>I was so pleased to find the XFAIL_TESTS make variable, but that only works if the test *always* fails.

<civodul>you're looking at a random failure?

<mark_weaver>yeah, the test-async-cancel test in gnome-vfs sporadically fails, and not just for us. it's a known problem, but that module is deprecated and the problem will apparently never be fixed upstream.

<mark_weaver>for months, I've been manually restarting those builds until the test passes, but I've had enough of that

<civodul>i see :-)

<mark_weaver>during 'make install', there are a large number of these warnings in gnome-vfs:

<mark_weaver>WARNING: failed to install schema `/schemas/system/http_proxy/port', locale `eo': Unable to store a value at key '/schemas/system/http_proxy/port', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /gnu/store/3j7099a1yabpmpk8kpc5i9k235k34abp-gconf-3.2.6/etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two

<mark_weaver>gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove

<mark_weaver>~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage

<mark_weaver>locations such as ~/.gconf

<civodul>scary

<civodul>it seems to be something inherently imperative no?

<mark_weaver>I haven't yet taken the time to try to understand it, but it's a lot of output

<mark_weaver>civodul: did you see that qemu failed on x86_64 in core-updates?

<mark_weaver> http://hydra.gnu.org/build/379838

<mark_weaver>oh, it was a transient failure, nevermind.

<mark_weaver>I had restarted it and forgot

<bavier>yay first hydra package build! \\o/

<mark_weaver>bavier: oooh! :)

<mark_weaver>woohoo!!

<davexunit>bavier: whoa!