IRC channel logs

<civodul>that's the first code snippet you could post: something that shows a list of packages, and just lets us navigate it, and perhaps select stuff or hit RET

<civodul>yes

<kindahero>I am kind of free with lab work for couple of weeks now on.

<civodul>that's good news :-)

<civodul>so let's keep in touch during that time frame

<kindahero>yes, I will do

<kindahero>Last time I told you about udunits packaging

<civodul>right

<civodul>how goes?

<phant0mas>good morning civodul:

<phant0mas>the errors I get in linking,shouldn't exist, so I am starting to believe that something in the linker doesn't work quite well

<civodul>and how's your Guix installation in general?

<kindahero>I try to post that on list today

<civodul>ok

<kindahero>Guix installation, well, it seems was working,

<kindahero>but there seems to be lot of things going on devel side

<civodul>phant0mas: note that Debian most likely uses an older version of Binutils

<kindahero>about changing store to gnu thing

<civodul>ah, right

<civodul>the easiest thing would be to start with a fresh install

<civodul>though i don't like to give this kind of answer, but hey ;-)

<kindahero>so I was waiting things to settle down

<phant0mas>civodul: so you think it may be a problem with the binutils version?

<civodul>the /gnu/store thing has definitely settled down for years to come :-)

<kindahero>also I may need to put it in a VM instead of doing on my main system.

<civodul>phant0mas: most likely it's a problem with the Savannah libpthread repo, but i mentioned it just so you keep it in mind ;-)

<civodul>it could be a problem

<civodul>kindahero: well it's not very intrusive, so you can safely put it on your main system IMO

<kindahero>Oh that's nice.

<civodul>i mean everything goes to /gnu

<civodul>so the main system shouldn't be altered

<phant0mas>civodul: imagine that normally libpthread should inform of the subdir sysdep tree, but running configure while it seems to find it it says that no usefull sysdep tree found

<kindahero>okay. I also need to understand different arguments (in the user space)

<kindahero>before making a layer on top of them

<phant0mas>should inform glibc configure*

<civodul>phant0mas: configure doesn't say anything about the libpthread add-on?

<phant0mas>no no it found it normally

<phant0mas>it justs doesn't want to accept it's subdir sysdep tree

<phant0mas>its*

<phant0mas>it says configured as an addon but no usefull sysdep tree found from addons

<phant0mas>I will work on that

<phant0mas>configure:3841: running configure fragment for add-on libpthread

<phant0mas>configure:4299: WARNING: add-on ports contributed no sysdeps directories

<phant0mas>I was just working around it till now, but I think I should fix it

<civodul>hmm

<phant0mas>civodul: I don't think the enviroment has the problem, there's something wrong on the configure scripts

<phant0mas>have a look at this http://pastebin.com/raw.php?i=BS8aSLMW

<civodul>pastebin.com doesn't allow access over Tor, you should prefer paste.lisp.org or similar

<Steap>civodul: why is that ?

<civodul>phant0mas: the log mentions "add-on ports", not "add-on libpthread"

<civodul>Steap: it's a "your IP is banned"

<civodul>Google does something similar, but it has CAPTCHA to get over it

<Steap>civodul: yes, but why does it do that ? Is rejecting traffic from Tor on purpose ?

<Steap>I don't get it.

<civodul>it has an IP black list, which happens to make it difficult/impossible to access it via Tor

<civodul>because some correspond to exit nodes

<mark_weaver>so it turns out that gdb passes its test suite on the Loongson 3A machine, but not on the YeeLoong (Loongson 2F).

<mark_weaver>I just tried to compare build logs, but they are hard to compare because the Loongson 3A build was done in parallel.

<mark_weaver>I'll have to disable parallel and try again.

<civodul>oh, ok

<civodul>thanks for investigating!

<mark_weaver>np! Maybe it's a timeout issue, or maybe some difference in /dev.

<mark_weaver>any news on the python-3 tests?

<civodul>i just started looking at the remaining test failure

<civodul>nothing obvious though

<civodul>it's about semaphores

<civodul>Steap: do you know how to run a single test of Python's test suite?

<Steap>civodul: I'd love to.

<civodul>Steap: ./python ./Lib/test/test_multiprocessing.py

<Steap>makes senses, since they seem to define a "main" method every time

<civodul>yup

<civodul>i just posted a my "findings"

<civodul>Steap: we need you help now :-)

<civodul>ttyl

<zacts>lo

<mark_weaver>civodul: I rebuilt gdb in the Loongson 3A with parallel-build and parallel-tests disabled, and this time it failed, just as on a Loongson 2F.

<mark_weaver>so I guess I'm inclined to simply disable the tests on MIPS for now.

<mark_weaver>WDYT?

<civodul>mark_weaver: sounds good to me

<civodul>is there an error message that shows up reproducibly when it fails?

<civodul>something to stick in the comments, for future reference

<mark_weaver>actually, now it makes me wonder whether it just fails on any single-core machine. I'll try disabling parallel build/tests on my x86_64 machine.

<civodul>ok

<mark_weaver>"make check" in gdb is so full of failures and errors that I have no idea which ones are causing the real failure.

<civodul>BTW, i get "FAIL: memblock-test" for PulseAudio

<civodul>that's the one you were getting, no?

<civodul>oh it was 'thread-test'

<mark_weaver>I haven't had a problem with pulseaudio except for the too-short-timeout on thread-test

<civodul>ok

<mark_weaver>one thing I see a lot of in the gdb "make check", even when the build ultimately succeeds, is "ERROR: no fileid for localhost"

<mark_weaver>I see that 1734 times

<mark_weaver>there are 3559 lines in the log that contain "ERROR:"

<mark_weaver>(this is the successful one)

<mark_weaver>it's not clear to me why all of those errors are essentially ignored, and yet some others cause "make check" to fail.

<civodul>i don't know either

<civodul>i think sorting it out will need a fair amount of work

<civodul>grr PA succeeds on my machine and fails on hydra

<civodul>"shm_open() failed: Function not implemented"

<civodul>a déjà vu :-)

<mark_weaver>impurities

<civodul>yup

<civodul>that was on hydra.gnunet.org

<bavier>civodul: I thought there was a patch for the chroot builder that fixed the shm thing

<civodul>bavier: there's a footnote in the manual, rather :-)

<civodul>but like any other user, i forgot to follow that when setting up hydra.gnunet.org

<civodul>ah but wait

<mark_weaver>bavier: btw, your recent massive patch to clean things up broke the texlive build. it would be good if you could test all the packages you modified, to make sure nothing else is broken.

<mark_weaver>(I appreciate the cleanups, btw :)

<civodul>bavier: no you're actually right, but hydra.gnunet.org runs an older daemon

<bavier>civodul: I admit texlive was the one package I did not check :|

<mark_weaver>bavier: I fixed the texlive bug here: http://git.savannah.gnu.org/gitweb/?p=guix.git;a=commitdiff;h=67880c8e2bdd6d9d3a9a9dc3fe242d115f711ce9

<bavier>mark_weaver: thank you!

<mark_weaver>np

<mark_weaver>so you tested all the others?

<bavier>I believe so, yes

<mark_weaver>okay

<civodul>mark_weaver: just emailed an issue with union.scm

*mark_weaver looks

<civodul>"for your consideration" ;-)

<mark_weaver>ah, okay :)

<mark_weaver>I actually thought about that case, and about then empty-profile case, but thought it would be okay. forgot about the manifest.

<mark_weaver>s/about then/also about the/

<mark_weaver>I'll take care of it soon.

<civodul>cool, thanks :-)

<mark_weaver>civodul: I just created a test-profile (to test the new union.scm), and then I deleted the symlinks and now want to remove it from the store with "guix gc --delete", but it says it's still alive. where's the link that's keeping it alive?

<mark_weaver>(I deleted both 'test-profile' and 'test-profile-1-link' from my home)

<mark_weaver>oh, I just noticed that even after installing the new file-5.18, I still have file-5.16 installed.

<mark_weaver>I guess that's intended, but I found it surprising.

<Steap>civodul: I really don't know why the KeyboardInterrupt isn't raised in your test

<Steap>I don't even know why it should be raised :D

<mark_weaver>I wonder how many other old packages I have in my profile :)

<mark_weaver>oh, it's because I have an old intltool that has the old file as a propagated-input.

<civodul>Steap: the child process is supposed to send SIGINT, which the parent process is supposed to receive

<civodul>and SIGINT == KeyboardInterrupt, i presume

<civodul>mark_weaver: the profile should be dead once you've removed test-profile*

<Steap>hum

<Steap>civodul: why would you think that ?

<Steap>I must admit I do not know much about signals in Python

<civodul>Steap: in the snippet i posted, the child does kill(ppid, SIGINT)

<Steap>ok

<civodul>not that i'm a Python expert, tho ;-)

<Steap>oh damn, you're right

<Steap>self.assertRaises(KeyboardInterrupt, c.wait, 10) <- c.wait(10) should raise KeyboardInterrupt

<Steap>or call os.kill(some_pid, signal.signint)

<civodul>maybe KeyboardInterrupt is actually EINTR

<civodul>who knows

<civodul>but that's the same idea

<Steap>I can't see the path it's supposed to take

IRC channel logs

2014-04-03.log