IRC channel logs

<davexunit>I wonder how much work it will take to get a mediagoblin package.

*paroneayea is so sick of people relying on python packages that break all the time because dependencies change every day and hit weird conflicts, and the depgraph sucks! :)

<paroneayea>anyway, Real Soon Now we should have Debian packaging. guix packaging would also be good I think :)

<davexunit>that's great.

<davexunit>we can learn from the .deb

<davexunit>step one would be packaging all of the python libraries that mediagoblin needs.

<paroneayea>ya

<davexunit>guix still pales in comparison to the vastness of the debian package repos.

<davexunit>a lot of stuff to package.

<paroneayea>makes sense

<paroneayea>btw, since guix is guile-based, I guess it can probably ingest the DSL similar to the nix dsl, right?

<davexunit>what DSL are you referring to here?

<paroneayea>heh, admittedly I haven't looked into nix in depth

<paroneayea>I remember it having its own package-description format

<paroneayea>it was a long time since I looked at it

<davexunit>guix uses it's own.

<davexunit>guile replaces the custom nix language.

<paroneayea>davexunit: yeah

<davexunit>and since guix is a guile library, you can take full advantage of that if you decide to explore configuration management with guix.

<paroneayea>sorry, was thinking out loud about how you can "write" guile in other kinds of syntax that gets converted to actual guile sexps, was wondering if that was in plans to convert the custom nix language over to actual guile similarly. Not important :)

<paroneayea>yeah

<davexunit>oh, I see.

<zacts>lo

<davexunit>mark_weaver: the novena laptop is having a crowd funding campaign: https://www.crowdsupply.com/kosagi/novena-open-laptop

<mark_weaver>davexunit: ooh, thanks for letting me know!

<davexunit>it's very expensive, but I feel like it's worth reaching deeper into my pockets to support this.

<davexunit>although I guess it requires a blob for the graphics processor? :(

<mark_weaver>civodul: I just pushed the sqlite upgrade/fix and the new union.scm. At this point, there are just two things that I think should be fixed before 0.6: fix or disable the tests of python-3 and gdb.

<civodul>cool!

<civodul>Steap: python-3?

<civodul>those or gdb are harmless though, no?

<civodul>(harmless in that they don't exit 1)

<mark_weaver>they aren't harmless. they mean that 2/3 of our platforms can't build gdb, and many users including bavier and I can't build python-3 or anything that depends on python 3, which is quite a lot.

<civodul>yes, agreed for Python 3

<civodul>but gdb doesn't build at all?

<mark_weaver>well, the build recipe fails because make check fails.

<civodul>oh, ok, i understood differently

<mark_weaver>I can't get guix to install gdb without disabling the tests.

<civodul>meanwhile, could you post the relevant part of the Python 3 build log?

<mark_weaver>okay.

<mark_weaver>civodul: Steap == Cyril, right?

<civodul>yes :-)

<civodul>he put quite some effort into getting those tests in shape, so he may have a clue

<mark_weaver>I asked him about it here on channel the other day, and he can't reproduce the problem on his system (Debian Sid in a VM).

<civodul>oh, ok

<mark_weaver>I posted the tail of the build log where it fails on my systems.

<civodul>well, at worst we'll just disable the tests again

<mark_weaver>(same failure on my x86_64 and MIPS systems)

<mark_weaver>can we disable the tests of gdb also, at least on non-x86_64 ?

<mark_weaver>or are they working on i686 now? last I checked, hydra wasn't able to build it on 686.

<mark_weaver>I have to go afk for a while.

<civodul>actually http://hydra.gnu.org/job/gnu/master/python-3.3.3.i686-linux and http://hydra.gnu.org/job/gnu/master/python-3.3.3.x86_64-linux are green

<mark_weaver>now I'm talking about gdb.

<civodul>ok, well same then

<mark_weaver>the python-3 problem seems to be somewhat different, perhaps related to the system it's hosted on. what is the host OS for hydra.gnu.org?

<civodul>Trisquel

<mark_weaver>interesting.

<civodul>could it be a /dev/shm issue?

<civodul>or /dev/pts

<mark_weaver>pts seems more likely, but I really don't know.

<mark_weaver>it fails on Trisquel 6.0 for bavier.

<civodul>it's Trisquel 4.0 here

<civodul>but really, apart from /dev issues, i don't see what could be making a difference

<civodul>well, the kernel of course

<civodul>it's an old one here

<Steap>yes, the Python test looks for /dev/pty[p-zP-T][0-9a-f]

<Steap>and if it can't find something that matches, it raises the "out of pty devices" error

<mark_weaver>My x86_64 system has Linux 3.2.0-1 (Debian stock), and the Loongson 3A system has Linux 3.12 (home-built).

<mark_weaver>both of those systems give the same error in the python-3 tests.

<Steap>mark_weaver: how many tests fail because of that ?

<civodul>howdy Steap :-)

<Steap>civodul: hey

<Steap>Talk about Python, and I show up

<civodul>right in time!

<mark_weaver>Steap: I should probably just post the entire build log. I find the test output somewhat confusing.

<Steap>I'm relaunching a build

<Steap>I think we could just skip test_pty if we can't get to the bottom of this

<mark_weaver>Steap: http://www.netris.org/~mhw/7a9dv96kb1z7547ms4k9bcywg4c0pf0j-python-3.3.3.drv.bz2

<mark_weaver>that's from my x86_64 box.

<mark_weaver>the failure from the MIPS box look the same to me, from a casual glance.

<mark_weaver>civodul: okay, I see that hydra can build gdb-7.7 now, so maybe we should just disable the tests on MIPS.

<mark_weaver>WDYT?

<civodul> master, slave = os.openpty()

<civodul>FileNotFoundError: [Errno 2] No such file or directory

<civodul>mark_weaver: sounds good, yes

<Steap>grmbl, you have 3 failing tests

<Steap>So, build reproducibility is nice

<Steap>but it would be good if it could happen

<mark_weaver>civodul: can you remind me how to disable tests for a particular target, or point to an example?

<mark_weaver>I'm also going to try one more time to build gdb with tests enabled on the Loongson 3A machine, with current master.

<mark_weaver>oh, I can't do that until I have python 3. time to disable tests on python :)

*mark_weaver just noticed that there are 54 python build dirs in his /tmp

<civodul>mark_weaver: #:tests? ,(not (string=? (or (%current-target-system) (%current-system)) "mips64el-linux"))

<mark_weaver>thanks!

<Steap>I have no idea of what's happening in that pty stuff

<civodul>could it be that some of these files are missing in the chroot?

<Steap>civodul: I don't think I'm even running the tests actually

<mark_weaver>heh, well, that would explain why you're unable to reproduce the problem.

<mark_weaver>civodul: there's one other thing that would be nice to get into 0.6. gnu: gnutls: Configure location of system-wide trust store.

<Steap>I still don't understand why the build on your box does not behave like mine

<mark_weaver>Steap: on your box, the tests aren't run?

<Steap>mark_weaver: they are

<Steap>I'm just afraid I never get into _open_terminal()

<Steap>they're not marked as skipped, so I probably run them

<civodul>mark_weaver: right, i'm fine with it, but probably need to re-read the thread

<mark_weaver>Steap: on the system where you're doing these tests, do you have /dev/pts ? is it a mount point?

<civodul>are you both running the latest guix-daemon?

<mark_weaver>civodul: as I recall, Andreas wasn't in favor of it, but I think he was willing to give in on it.

<Steap>mark_weaver: I have /dev/pts indeed

<Steap>civodul: I've recompiled from master yesterday

<mark_weaver>I'm reasonably sure I was running a fresh guix-daemon, but I'll recompile everything from scratch just in case.

<civodul>ok

<Steap>not sure whether I have /dev/pts in the chroot though

<mark_weaver>The Loongson 3A is now trying to build gdb-7.7 with tests on fresh master, and my x86_64 is rebuilding guix after "make clean" and will soon try the python 3.3.3 build again.

*mark_weaver goes afk for a while.

<civodul>Steap: it is, see nix/libstore/build.cc:2071

*civodul starts a local build

<Steap>ok

<Steap>I guess mark_weaver's forkpty sucks

<Steap>in Lib/pty.py, in fork(), I do not call openpty()

<Steap>because os.forkpty works

<civodul>oh

<Steap>it probable return an AttributeError or OSError for mark_weaver

<Steap>now, why does it do that

<Steap>I have no idea

<civodul>hmm, forkpty doesn't do much more than openpty

<Steap>still, taht's a difference

<Steap>it calls forkpty()

<Steap>instead of trying all dev/pt* stuff

*mark_weaver is back

<mark_weaver>my forkpty sucks? this is debian wheezy

<mark_weaver>in any case, lots of people run debian derivatives that aren't as new as sid :)

<civodul>the wording was unfortunate ;-)

<Steap>huhu

<Steap>os.forkpty() fails on your system

<mark_weaver>nah, I didn't take it personally :)

<Steap>for some reason

<civodul>good news: it fails on mine too!

<bavier>and mine! ;)

<Steap>that is not good news!

<civodul>yay, party time!

<civodul>:-)

<mark_weaver>heh :)

<mark_weaver>well, I'm in good company anyway :)

<civodul>yeah, it fails wonderfully

<civodul>lemme see

<civodul>we have /dev/ptmx -> /dev/pts/ptmx but the latter has perms 0

<civodul>which is Bad

*civodul tries with that fix

<mark_weaver>same on my YeeLoong and x86_64 system. on the Loongson 3A (also Debian Wheezy), /dev/ptmx is not a symlink, but just a device node with 666 perms.

<civodul>Steap: what kernel do you have?

<civodul>mark_weaver: yes, but build.cc is written to not mention major/minor explicitly

<civodul>hence the symlink

<civodul>(my guess)

<civodul>libc's getpt.c doesn't matter

<civodul>*doesn't care if it's a symlink or not

<mark_weaver>right, but this raises the question of why the tests fail on the Loongson 3A.

<Steap>civodul: 3.10-3

<civodul>i have 3.0.43 here

<civodul>maybe the newer devpts creates /dev/pts/ptmx with 666

<mark_weaver>I have 3.12 on the Loongson 3A, and 3.2 on my x86_64.

<civodul>oh, so my hypothesis doesn't hold

<mark_weaver>on the Loongson 3A, /dev/pts/ptmx doesn't even exist.

<civodul>Steap: i still have this:

<civodul>1 test failed:

<civodul> test_multiprocessing

<civodul>mark_weaver: can you try a fresh mount and see: mount -t devpts foo bar && ls -l bar/ptmx

<Steap>civodul: did you fix the pty issue ?

<civodul>Steap: yes, but we still need to see if it works for other people

<mark_weaver>civodul: even with a fresh mount, it doesn't exist.

<civodul>blech

<civodul>ah yes, you don't have CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

<civodul>that's what the comment in build.cc says

<mark_weaver>that's lemote's kernel for the Loongson 3A, which has a bunch of patches that aren't upstream.

<mark_weaver>(but I did build it from source, anyway)

<civodul>without /dev/pts/ptmx, one is screwed, the way things are done currently

<mark_weaver>indeed, CONFIG_DEVPTS_MULTIPLE_INSTANCES is unset on the Loongson 3A's kernel here.

<mark_weaver>well, I could rebuild it with that option set.

*civodul -> zZz

IRC channel logs

2014-04-02.log