IRC channel logs


back to list of logs

<civodul>Hello Guix!
<civodul>mark_weaver: has been making progress, so now we won't touch the branch until it can be merged
***civodul changes topic to 'GNU Guix | | things to package: | hackathon on Sep. 27-28:'
<davexunit>morning #guix
<civodul>hello, davexunit!
*civodul spams gnu-system-discuss for the hackathon
<mark_weaver>civodul: sounds good, regarding core-updates.
<mark_weaver>there was a segfault during the build of guile-reader-for-guile_2.0.11-0.6:
<civodul>oh, "interesting"
<civodul>if it's an isolated failure, hopefully it's just a guile-reader bug
<mark_weaver>more importantly, the python-3 build on i686-linux core-updates failed, causing a lot of other dependency failures.
<civodul>this one may be more problematic
***Steap__ is now known as Steap
<mark_weaver>FAIL: test_initgroups, OSError: [Errno 38] Function not implemented
<mark_weaver>maybe related to the glibc-2.20 update
<mark_weaver>well, a lot of that same OSError
<mark_weaver>interestingly, the same build succeeded on x86_64
<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.
<civodul>an impurity
<mark_weaver>I'll try the same build on my X60 running linux-3.16
<civodul>would be nice
<mark_weaver>(which is i686)
<mark_weaver>(there are some X60 machines with x86_64 though, for the record :)
<civodul>didn't know that
<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>yes, that's what i'd like to do
<civodul>but currently, we can't really install the system on the slaves
<civodul>not just because it's unstable ;-)
<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?
<mark_weaver>ah, he left.
<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.
<sneek>Will do.
<mark_weaver>sneek: botsnack
<Steap>mark_weaver: so, in core-updates, did we upgrade glibc from 2.18 to 2.20 ?
<mark_weaver>Steap: yes
<Steap>In 2.18, sysdeps/unix/sysv/linux/i386/setresuid.c contains what looks like a regular syscall
<Steap>oh no, also in 2.20, my bad
<mark_weaver>do you have guix running on a i686 to test on?
<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>yeah, it's kinda weird
<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>see if that works
<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: okay, I'll try it.
<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>(so same compiler, glibc, etc)
<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 test_setresuid
<Steap>should work
<mark_weaver>where is the python I should run? it's not in PATH
<Steap>find . -name python :)
<Steap>it must be somewhere
<mark_weaver>well, there's a python executable in the toplevel build directory, so I tried "./python 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/
<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>Steap: okay, that worked. I have an strace.
<mark_weaver>it looks like it's calling invalid syscalls.
<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>to be more precise, it calls getresuid32
<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>(and getresuid32([1000], [1000], [1000]) = 0)
<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.
<civodul>ah, good
<civodul>do you don't see ENOSYS?
<mark_weaver>for a few excerpts of the python 3 strace output.
<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.
<Steap>that's weird
<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
<mark_weaver>Steap: can you find the python code for setresuid?
<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.
<civodul>that's an i686 strace, right?
<mark_weaver>and the setresuid returns successfully from the C program.
<mark_weaver>I ran the python tests within gdb.
<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?
<civodul>i think it'll reproduce the problem
<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.
<mark_weaver>but there's no error printed after that one.
<mark_weaver>civodul: okay, I'll try.
<mark_weaver>civodul: you're right, it does!
<civodul>ah ah!
<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>(for the setresuid call)
*mark_weaver unpacks the glibc source
<mark_weaver>so this is a glibc bug?
*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>well, it's enough to file a bug report anyway
<mark_weaver>hmm, is there an irc channel when glibc hackers hang out?
<Steap>these macros are fantastic
<mark_weaver>every time I look at the glibc source, I'm intimidated by it.
<civodul>it's intimidating, indeed
<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>that should be enough
<mark_weaver>I do
<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.
<mark_weaver>s/is fails/it fails/
<civodul>and 2.19?
<mark_weaver>civodul: thanks for the excellent hint!
<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 ?
<mark_weaver>civodul: sorry, when I wrote 2.18 I meant 2.19
<mark_weaver>I didn't test with 2.18
<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
<Steap>it feels like it never ends
<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.
<jxself>It must eventually though?
<jxself>End I mean.
<mark_weaver>no, it's macros all the way down!
<Steap>jxself: yeah, but I'll die from exhaustion before that
<civodul>jxself: nobody really knows ;-)
<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.
<mark_weaver>Guix was mentioned during the Q&A.
<jxself>And how the Debian Project will replace their package manager for Guix right? :)
<jxself>er with Guix
<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.
<civodul>what are the "other parts"?
<civodul>the non-technical aspects?
<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.
<jxself>'tis the future I says.
<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.
<davexunit>me either
<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.
<jxself>It was that memorable?
<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.
<davexunit>ah, yes. that was it.
<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>"its unique developer"
<civodul>crap, we're actually several people :-)
<jxself>We're not all civodul?
<Steap>Ludovic Court├Ęs <> (2587):
<Steap>Andreas Enge <> (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.
<civodul>Steap: that must change :-)
<civodul>mark_weaver: yeah, right
<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>it's refreshing, even
<civodul>because otherwise we tend to remain in a cabal of crazy people who don't realize how crazy this is ;-)
<mark_weaver>well, good point :)
<Steap>oh, you mean, like GNU ?
<Steap>Accidentally trolling.
<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?
<civodul>is that possible?
<civodul>(honest question)
<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 ?
<Steap>something like that, yes
<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>that's so simple
<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.
<mark_weaver>(though I would write it as "geeks")
<tadni>Steap: Well, that would be "geex" would it not? :^P
<civodul>it's like "guile"
<civodul>some native speakers get it wrong, for some reason
<tadni>civodul: Native english speakers get Guile wrong?
<tadni>It's a known word...
<civodul>yeah, dunno why
<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
<mark_weaver>I suspect that's an unusual mistake.
<davexunit>the pronunciation of guix is natural from the perspective of a french speaker, right?
<civodul>yes :-)
<civodul>but heck, it's like Qt, TeX, etc.
<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"
<civodul>not at all!
<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.
*civodul made the pronunciation more visible:
<tadni>civodul: Yah!
<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, you can run "guix build --log-file /gnu/store/...-glibc-2.20"