***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | things to package: http://libreplanet.org/wiki/Group:Guix/Wishlist | hackathon on Sep. 27-28: http://libreplanet.org/wiki/Group:Guix/Hackathon-09-2014'
*civodul spams gnu-system-discuss for the hackathon <civodul>if it's an isolated failure, hopefully it's just a guile-reader bug ***Steap__ is now known as Steap
<mark_weaver>FAIL: test_initgroups, OSError: [Errno 38] Function not implemented <civodul>in libc 2.20 these are just plain syscall wrappers <civodul>so it could be that the kernel on the machine that built it lacked setresuid32 & co. <mark_weaver>I'll try the same build on my X60 running linux-3.16 <mark_weaver>(there are some X60 machines with x86_64 though, for the record :) <mark_weaver>at some point, it would be good to have an official 'operating-system' configuration for hydra build slaves, and to actually have them run standalone guix. <civodul>but currently, we can't really install the system on the slaves <civodul>i mean, we don't have enough admin control <mark_weaver>I vaguely recall hearing that there was a way to declare "features" provided by build slaves, and the features required by specific jobs, so that hydra could, e.g. only offload python-3 builds to a slave that had a new enough kernel. is that right? <jxself>He does seem to like doing that. :) <mark_weaver>I can hardly blame him. He gets so many questions while he's here it must be hard to get anything else done :) <mark_weaver>sneek: later tell civodul the python-3.3.5 build failed on my i686 box running guix's stock linux-3.16.1 kernel, with the same test failures as on hydra. <Steap>mark_weaver: so, in core-updates, did we upgrade glibc from 2.18 to 2.20 ? <Steap>In 2.18, sysdeps/unix/sysv/linux/i386/setresuid.c contains what looks like a regular syscall <Steap>was just looking at the libc <Steap>because on Python, these calls return ENOSYS <Steap>and some of the setresuid implementations in glibc just set errno to ENOSYS and return -1 <Steap>not sure exactly how one is supposed to read the glibc code ,though :D <mark_weaver>yeah, I never learned my way around the glibc source tree either. it seems a bit intimidating. <Steap>and setting up a box is a bit long :/ <mark_weaver>at some point we'll probably need to set up some porter boxes <Steap>would be cool to be able to just SSH a box <mark_weaver>I wrote a non-trivial python program about 20 years ago, but haven't touched it since. I'd rather not start debugging it now :-/ <mark_weaver>unfortunately, no python-3 means no emacs for me either, at least not in guix :-/ <mark_weaver>Steap: I have a failed python-3 build dir on my laptop (from running guix build -K). how would I rerun the test under strace? <Steap>mark_weaver: if it's an i686 box, it'd help to compile a C file that calls setresuid() <Steap>I think it should return -1, and errno should be ENOSYS, if you use glibc 2.20 <jxself>Oh, I confused sneek and steap for a moment and was thinking "Wow, this is a very interactive bot." <mark_weaver>Steap: I wrote a simple C program that does the same thing as the python test: it calls getresuid to get the three ids, and then calls setresuid to set the ones it just got. it returns result 0, no error, on both glibc 2.18 and 2.20 <mark_weaver>I did this outside of the build container, but using the same environment variables that were used for the python build. <mark_weaver>I also used ldd to verify that it linked to glibc-2.20 <mark_weaver>so maybe I should try running the python test within strace? <Steap>something like python setup.py test_setresuid <mark_weaver>well, there's a python executable in the toplevel build directory, so I tried "./python setup.py test_setresuid" from there, and it gave me a usage message, and said "invalid command: test_setresuid" <Steap>LD_LIBRARY_PATH=/tmp/nix-build-python-3.3.5.drv-0/Python-3.3.5: ./python ./Tools/scripts/run_tests.py <Steap>that should re-run everything <Steap>passing "test_posix" as an argument might help <mark_weaver>well, if I wanted to rerun everything, I could just run "make check", but that's not exactly practical for running within strace. <mark_weaver>*grump* am I to be responsible for maintaining all packages on both the mips64el and i686 architectures? <Steap>mark_weaver: have you tried adding "test_posix" to the command line ? <mark_weaver>when I run my C program, linked against glibc 2.20, under strace, it shows that it calls both getresuid and setresuid. <mark_weaver>when I run the python tests under strace, it shows that it calls getresuid, but it never calls setresuid. <mark_weaver>however, I see several suspicious logs in the strace: syscall_3073558272(0x3e9, ...) = -1 (errno 38) <mark_weaver>as if python is trying to issue the syscall directly (not via glibc), and mucking it up. <mark_weaver>and those suspicious syscalls are immediately above the bits where it writes error messages about setresuid/setresgid <mark_weaver>sometimes the first argument is 0x3e9, sometimes 0x3e8 <mark_weaver>maybe one of those is when it's trying to call setresuid, and the other is trying to call setresgid ? <Steap>return INLINE_SYSCALL (getresuid32, 3, ruid, euid, suid); <- that's the i386 code in the glibc, so I'm ok with getresuid32 <mark_weaver>(the strace shows more arguments where I wrote "...") <mark_weaver>so, when the C program calls setresuid, I see a nice "setresuid32(1000, 1000, 1000) = 0" in the strace output. <mark_weaver>in the python strace, the getresuid32 is the same, but these mystery syscalls don't have 1000 anywhere in them. <civodul>mark_weaver: is this on your machine? <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, mark_weaver says: the python-3.3.5 build failed on my i686 box running guix's stock linux-3.16.1 kernel, with the same test failures as on hydra. <mark_weaver>when running the equivalent program in C, compiled in the same environment as python 3 was compiled in, the strace is what you would expect, and the setresuid succeeds without error. <mark_weaver>(i.e. there is setresuid32(1000, 1000, 1000) = 0 instead of that strace mystery syscall) <Steap>it means it's not using the same function, or something like that <Steap>that syscall_ thing is a mystery <Steap>mark_weaver: it's in Modules/posixmodule.c <Steap>but it's just calling the setresuid from the libc <Steap>you could add debug messages there <mark_weaver>we need porter boxes. I don't want to have to debug every mips64el/i686 problem myself, becuase everyone else is on x86_64. <civodul>mark_weaver: it seems that strace doesn't know how to parse the syscall <civodul>but it does show 38, which is ENOSYS <mark_weaver>civodul: it parses it correctly when I run the equivalent C program within strace, built within the same environment. <mark_weaver>and the setresuid returns successfully from the C program. <mark_weaver>with a breakpoint on Python's posix_setresuid function. <Steap>can you print rgid, egid, sgid ? <mark_weaver>its called twice. the first time, I see that PyArg_ParseTuple returns the correct values (1000, 1000, 1000), and it apparently calls setresuid with those values, but after continuing, the test program prints an ERROR reporting test_setresuid_exception <civodul>mark_weaver: can you try the link the C version with -pthread? <mark_weaver>then it's called a second time, and this time PyArg_ParseTuple returns (1001, 4294967295, 4294967295) <mark_weaver>and it again calls setresuid with those bogus values. <civodul>see INLINE_SETXID_SYSCALL in sysdeps/nptl/setxid.h <mark_weaver>and when compiled with -pthread, the strace output contains the same bogosity. *mark_weaver unpacks the glibc source *tadni is working on a generic vm image and probably going to get hosting for it, eventually. <civodul>dunno, i'm trying to understand what this is about <mark_weaver>hmm, is there an irc channel when glibc hackers hang out? <mark_weaver>every time I look at the glibc source, I'm intimidated by it. <Steap>Do people really understand that ? <civodul>mark_weaver: if you have the reduced test case in C, you can probably put it on the Bugzilla <civodul>cool, thanks for investigating etc.! <mark_weaver>it simply does getresuid and then setresuid with the same values. the program works on glibc 2.18 with or without -pthread, but on glibc-2.20 is fails with -pthread. <civodul>apparently the keyword here is "setxid", but i don't understand what that is <Steap>civodul: how did you come up with that "-pthread" thing ? <civodul>Steap: the setresuid uses INLINE_SETXID_SYSCALL, which does different things depending on whether it's single-threaded or not <Steap>I love the fact that these macros just call other macros <Steap>which in turn call othe macros <civodul>now we need to write a patch that skips the offending tests in Python, with a reference to the glibc bug report <mark_weaver>also, with glibc-2.19 and -pthread, strace is able to correctly parse the setresuid syscall. <Steap>jxself: yeah, but I'll die from exhaustion before that <Steap>I've pinged a core CPython dev, about this issue, I'll see whether he's aware of it <mark_weaver>in joey hess' talk at debconf14 "seeing debian through a functional lens", while we was showing the /run/current-system/sw on a nix system, someone asked if those were symlinks, and he said something like "yes, it's symlinks all the way down", which triggered quite a bit of laughter. <jxself>And how the Debian Project will replace their package manager for Guix right? :) <davexunit>one of the audience members also used the phrase "kiss of death" in regards to the GNU system. <mark_weaver>heh, unlikely, but joey seems to think that there are some useful ideas to draw from anyway. <davexunit>he seemed to like the functional stuff in nix, but other parts not so much. <mark_weaver>yeah, I think that was the main thing he was interested in. he pointed out that git, docker, nix are all essentially based on functional programming ideas (immutability, copy-on-write, generations), and that debian should think about moving in that direction too. <civodul>it's nice to see these ideas percolate <mark_weaver>someone in the audience mentioned that symlinks have a lot of problems, and asked why nix used them instead of something like a union filesystem or some such. <mark_weaver>I'm actually not entirely sure what problems he was referring to. <Steap>not sure that you can turn apt into something that looks like Nix :/ <davexunit>civodul: they had a good chuckle at one of nix's man pages that seemed to go on for ages, joey thought that nix's command line interface is unintuitive, and he said things like "not suitable for debian" <davexunit>it's worth watching the talk if you get the chance to draw your own conclusions. I can't remember a lot of the details and I only watched it yesterday. <davexunit>it was good, I just have a bad recollection. <mark_weaver>it was the man page for "the" (single) configuration file for a nixos system. <mark_weaver>they thought it was pretty funny that the entire system config was in one file, and hence the manual page as big as a book. <davexunit>I have never really seen nixos demoed before, so it was cool to see. <davexunit>I think our command line interface is better. :) <mark_weaver>I don't know that I'd necessarily recommend the talk. Joey is a smart guy, and it's good that he recognizes that git/docker/nix are essentially based on functional programming and suggests that debian learns from it, but it was also clear that his knowledge of nix is very limited, and a lot of it sounds kind of ignorant too, IMO. <Steap>davexunit: wait for the new features :) <civodul>crap, we're actually several people :-) <Steap>Ludovic Courtès <ludo@gnu.org> (2587): <Steap>Andreas Enge <andreas@enge.fr> (462): <mark_weaver>also, although guix was mentioned, its name was not actually spoken as I recall. only that "there's a version based on guile" <Steap>First two most active contributors :) <jxself>Oh why not? I'll go break out wget and watch it on the way home after work. <Steap>civodul: yes, please stop committing that much <civodul>but i think it's good to hear how people not very knowledgeable about Nix/Guix describe it <civodul>because otherwise we tend to remain in a cabal of crazy people who don't realize how crazy this is ;-) <civodul>Steap: so, what's the status of that Python patch again? :-) <davexunit>mark_weaver: yeah guix wasn't mentioned. was it because people can't pronounce it? <davexunit>people end up saying it like goo-ix or even gnu-ix. some insert an invisble 'n' into the name. <mark_weaver>I was actually impressed that Guix was even mentioned. I wonder who that was who mentioned it? Maybe rlb? I don't know what he looks like. <civodul>well they pronounce it wrong, but they pronounce it *DusXMT just can't help but call it goo-ix, it's just so much more natural to say <Steap>civodul: remember how Andreas pronounces it ? <tadni>Unless you append it "like geek (it's french)" no one is going to pronounce it correctly. It's not an ideal title. <Steap>it's just "geek" but with an "x", as in "Unix" <mark_weaver>we should probably mention how it's pronounced on the main page, in a prominent place. <tadni>Steap: Well, that would be "geex" would it not? :^P <civodul>some native speakers get it wrong, for some reason <tadni>civodul: Native english speakers get Guile wrong? <tadni>I mean heck, it's even in pop culture still due to Street Fighter. *DusXMT reads "guile" similar to the german word `geil', but with a tiny bit less contrast <DusXMT>How is it supposed to be pronounced? <mark_weaver>civodul: guile is already an english word, pronounced the same way. I think it's probably rare for english speakers to mispronounce it. guix is more likely to be Mispronounced, i think. <civodul>IIRC jmd says "goo-ile", for instance <davexunit>the pronunciation of guix is natural from the perspective of a french speaker, right? <civodul>good names need to be have an unguessable prononciation <civodul>and one you know how to pronounce "TeX", you think you know how to pronounce "LaTeX" and "Texinfo" <davexunit>I think we should just mention that it's french pronunciation (for lack of correct term), not english. <civodul>davexunit: the manual has it somewhere, but we could make it more prominent, yes <davexunit>once I realized that it was french, the name made sense. <civodul>well, above all, it started as "guile + nix" <civodul>and "guile" turns out to be like french pronunciation *tadni though is was "Guhix" until he saw Ludo's first talk on it. *DusXMT wasn't sure what exactly "geeks" was when he watched the first talk, it only later in the video got to him. <mark_weaver>civodul: is there a way for me to access the build log (from hydra) of the glibc that was used to build python-3? <mark_weaver>it seems that one is sort of hidden, since it doesn't have a job of its own. <mark_weaver>(I'd like to be able to provide details of the glibc-2.20 build for filing the bug report) <civodul>mark_weaver: on hydra.gnu.org, you can run "guix build --log-file /gnu/store/...-glibc-2.20"