IRC channel logs
2014-04-02.log
back to list of 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>step one would be packaging all of the python libraries that mediagoblin needs. <davexunit>guix still pales in comparison to the vastness of the debian package repos. <paroneayea>btw, since guix is guile-based, I guess it can probably ingest the DSL similar to the nix dsl, right? <paroneayea>heh, admittedly I haven't looked into nix in depth <paroneayea>I remember it having its own package-description format <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 :) <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>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. <mark_weaver>well, the build recipe fails because make check fails. <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? <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). <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>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>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>but really, apart from /dev issues, i don't see what could be making a difference <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 ? <Steap>Talk about Python, and I show up <mark_weaver>Steap: I should probably just post the entire build log. I find the test output somewhat confusing. <Steap>I think we could just skip test_pty if we can't get to the bottom of this <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. <civodul>FileNotFoundError: [Errno 2] No such file or directory <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")) <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 <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. <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>I guess mark_weaver's forkpty sucks <Steap>in Lib/pty.py, in fork(), I do not call openpty() <Steap>it probable return an AttributeError or OSError for mark_weaver <civodul>hmm, forkpty doesn't do much more than openpty <Steap>instead of trying all dev/pt* stuff <mark_weaver>in any case, lots of people run debian derivatives that aren't as new as sid :) <Steap>os.forkpty() fails on your system <civodul>we have /dev/ptmx -> /dev/pts/ptmx but the latter has perms 0 *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>mark_weaver: yes, but build.cc is written to not mention major/minor explicitly <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. <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. <mark_weaver>on the Loongson 3A, /dev/pts/ptmx doesn't even exist. <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 <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. <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.