| RAOF | apw: Hey, ho! Need any bees? | 06:40 |
|---|---|---|
| apw | RAOF, send me a whole container please .. it is going to be a hard day | 07:54 |
| RAOF | apw: | 08:00 |
| RAOF | apw: Would you have any idea at all why http://paste.ubuntu.com/8257535/ will reliably fail the first 383 times and then successfully create a tmpfile on the 384th time? | 08:01 |
| apw | RAOF, that is mad | 08:05 |
| RAOF | Correct! | 08:05 |
| RAOF | Would you like a kernel bug about it? :) | 08:06 |
| RAOF | (Is it reproducible on your system? It seems that it fails - until the 384th time - on three different Mir developers' systems) | 08:06 |
| apw | RAOF, nope, i'd file a bug on your code :) | 08:07 |
| apw | yep it reproduced just the same, but its your fault :) | 08:07 |
| apw | O_TMPFILE requires a mode | 08:07 |
| apw | fd = open(argv[1], O_TMPFILE | O_RDWR | O_EXCL, 0644); | 08:07 |
| apw | change it to that, and it succeeds on the first one, stack junk being passed | 08:07 |
| apw | RAOF, ^ | 08:08 |
| RAOF | apw: For added bonus giggles, run it as root :) | 08:09 |
| apw | i don't think i want to know what it does hten | 08:09 |
| apw | $ ./X PREFIX | 08:10 |
| apw | succeeded at iteration 1 | 08:10 |
| RAOF | So, that's a glibc bug then; either not translating open(foo, options) into open(foo, options, mode) when passed O_TMPFILE or in the documentation (which does not say you need mode, and gives an example without it)? | 08:11 |
| apw | it is doecumented in the manual page as being required | 08:12 |
| apw | mode specifies the permissions to use in case a new file is created. This argument must be supplied when O_CREAT or O_TMPFILE is specified in flags; if neither O_CREAT nor | 08:12 |
| apw | O_TMPFILE is specified, then mode is ignored. The effective permissions are modified by the process's umask in the usual way: The permissions of the created file are | 08:12 |
| apw | (mode & ~umask). Note that this mode applies only to future accesses of the newly created file; the open() call that creates a read-only file may well return a read/write | 08:12 |
| apw | file descriptor. | 08:12 |
| apw | open is so very special, i am not sure there is any other c abi which has an optional parameter | 08:13 |
| apw | and the example in the manual page for it has a mode: | 08:14 |
| apw | char path[PATH_MAX]; | 08:14 |
| apw | fd = open("/path/to/dir", O_TMPFILE | O_RDWR, | 08:14 |
| apw | S_IRUSR | S_IWUSR); | 08:14 |
| apw | so where are you seeing an example without | 08:14 |
| RAOF | I'm misreading that example :) | 08:15 |
| RAOF | Thanks! | 08:15 |
| apw | ahh good, thats fine then :) | 08:15 |
| apw | it is very rare to see modes spelt out, rather than just octal | 08:15 |
| zyga | good morning | 08:34 |
| apw | RAOF, and to close the loop, that succeeds on the 384th iteration because your iterator is in the mode slot on the stack, and 386 -> 0600 | 08:38 |
| apw | 384 even | 08:38 |
| === JanC_ is now known as JanC | ||
| zyga | hey | 14:05 |
| zyga | __bjf: ping? | 14:05 |
| === __bjf is now known as bjf | ||
| bjf | zyga, what's up? | 14:05 |
| apw | !contentless pings ... | 14:05 |
| ubot2` | apw: I am only a bot, please don't think I'm intelligent :) | 14:05 |
| ubot5 | apw: I am only a bot, please don't think I'm intelligent :) | 14:05 |
| rtg | apw has awakened the bot storm | 14:06 |
| zyga | bjf: hey | 14:08 |
| zyga | bjf: we'd like to shrink the 3.2 test pool for SRU | 14:08 |
| zyga | bjf: currently it's around 40 systems | 14:08 |
| zyga | bjf: would that be okay with you? | 14:08 |
| rtg | smoser, have you tried the 3.16.0-13.19 on your GM45 yet ? | 14:09 |
| rtg | 3.16.0-13.19 kernel* | 14:09 |
| bjf | zyga, in general i'm rarely ok with shrinking the test pool .. is there a good reason for doing so? | 14:25 |
| bjf | zyga, are any of these systems server class or are they all laptops? | 14:26 |
| zyga | bjf: IIRC we want to reduce the load on the team | 14:27 |
| zyga | bjf: I don't think there are any severs | 14:27 |
| zyga | bjf: I'll check and let you know | 14:28 |
| bjf | zyga, it's all automated | 14:28 |
| zyga | bjf: that's a good point, let me check why we wanted to do that first | 14:28 |
| zyga | bjf: launching tests is still not automatic, we need to power up each box, etc | 14:31 |
| zyga | bjf: there are issues with the number of machines and our AP (access point) capacity | 14:32 |
| zyga | bjf: there are no severs in the 3.2 pool that we are testing in taipei, there are some in other labs | 14:32 |
| zyga | bjf: the reason for this request is that ara wants us to prioritize on 12.04.5 testing | 14:34 |
| zyga | bjf: and SRUs still take a lot of our time to run and check | 14:34 |
| bjf | zyga, i'm trying to figure out how to say this nicely ... it really sounds like you folks are going to make this change and are just telling me about it. i really don't get to say "no" | 14:36 |
| zyga | bjf: no, we're actually asking | 14:37 |
| zyga | bjf: so if you want us to keep doing this, it's okay to say no | 14:37 |
| zyga | bjf: and we won't shrink it | 14:37 |
| bjf | zyga, give me a bit to think about it | 14:38 |
| bjf | zyga, how many machines would this leave in the 3.2 test pool after the reduction? | 14:38 |
| zyga | bjf: we'd like to cut the number of machines by half | 14:39 |
| bjf | zyga, ok, but i don't know how many systems you have now so half of an unknown is an unknown | 14:40 |
| zyga | bjf: ah, sorry, it's about 40 systems currently | 14:41 |
| zyga | bjf: 46 to be precise | 14:41 |
| bjf | zyga, ok, so you'd go down to 20 .. ok, i'll think on it and get back to you soon | 14:41 |
| zyga | bjf: thanks | 14:41 |
| bjf | zyga, sorry ... i see that you told me 40 earlier .. my bad | 14:43 |
| bjf | zyga, will you still be doing testing with the precise kernel or will it just be lts-backport-trusty testing? | 14:44 |
| bjf | zyga, the way i'm reading this it sounds like you will still do precise on those 20 systems .. i just want to make sure i understand correctly | 14:45 |
| zyga | bjf: we're only trying to limit the number of systems, we're going to test all the kernels as usual | 14:45 |
| zyga | bjf: and after the 12.04.5 tests are done we will probably get back to the full pool (IIRC that's what ara wanted) | 14:45 |
| zyga | bjf: yes, we plan to test the same set of kernels as usual | 14:46 |
| zyga | bjf: so precise, precise-lts, trusty and perhaps lucid | 14:46 |
| bjf | zyga, are you saying this is a temp. think (one time only) or a permanent change? | 14:46 |
| bjf | s/think/thing/ | 14:46 |
| zyga | bjf: IIRC it's the temp change, let me check | 14:46 |
| bjf | zyga, ok i *completely* misunderstood you. *yes* i'm ok with a limited test pool for this cycle. | 14:47 |
| bjf | zyga, apparently i'm still asleep | 14:48 |
| zyga | bjf: I just confirmed, it is only temporary | 14:48 |
| zyga | bjf: that's okay, I'm about to get sleepy so we're even :> | 14:48 |
| zyga | :-) | 14:48 |
| bjf | zyga, that makes me much happier, yes i'm ok with it | 14:48 |
| zyga | bjf: thank you | 14:48 |
| zyga | bjf: just a heads up, if we have the time this cycle, we'll test with the full pool | 14:49 |
| zyga | (and I know I just keep poppin up new facts) | 14:49 |
| zyga | bjf: so the half-pool is an option we merely _may_ take | 14:49 |
| bjf | zyga, sounds good | 14:49 |
| zyga | bjf: sorry, still getting used to everything here :) | 14:50 |
| === bdmurray_ is now known as bdmurray | ||
| === apb_ is now known as apb1963 | ||
| hallyn | sforshee: do you have a kernel built with the fuse patches? | 16:48 |
| sforshee | hallyn: hmm... I have some debs here that probably have the patches, but I didn't do good enough bookkeeping to be sure without trying them out | 16:50 |
| hallyn | sforshee: ok i can always push them to ppa | 16:50 |
| sforshee | hallyn: I can get you a build much faster than that | 16:50 |
| hallyn | :) | 16:50 |
| sforshee | do you care what kernel version it's based on? | 16:50 |
| hallyn | sforshee: not particularly. | 16:54 |
| hallyn | i'll just run it in a vm to play with | 16:54 |
| sforshee | hallyn: building, should be done in ~10 minutes | 16:57 |
| hallyn | sforshee: thanks - i probably won't have time to actually set it up today, but hopefully tonight or this weekend | 16:58 |
| rtg | jsalisbury, when you have a minute, could you provide some bisect assistance with bug #1363313. I think he got steered off into the weeds. | 17:00 |
| ubot5 | bug 1363313 in linux (Ubuntu) "mpt2sas not loaded with LSISAS2008 card in trusty 14.04.1" [Medium,Confirmed] https://launchpad.net/bugs/1363313 | 17:00 |
| jsalisbury | rtg, sure | 17:01 |
| hallyn | sforshee: so any hints on how you would test the functionality? could you maybe put a simple example at wiki.ubuntu.com/FUSE_userns? then I can flesh it out as I use it. | 17:07 |
| sforshee | hallyn: http://people.canonical.com/~sforshee/fuse-userns-build/ | 17:18 |
| sforshee | hallyn: I suppose I could put up some of the things I was doing to test | 17:18 |
| hallyn | sforshee: thanks! looking forward to testing that build :) | 17:22 |
| === Mikee_C_ is now known as Mikee_C | ||
| === hatch__ is now known as hatch | ||
| sforshee | hallyn: I got started on https://wiki.ubuntu.com/FuseUserns but there's only a couple of test cases now. I need to go for now but I'll try to add more tests over the weekend. | 21:43 |
| hallyn | sforshee: awesome, thanks | 21:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!