[06:40] apw: Hey, ho! Need any bees? [07:54] RAOF, send me a whole container please .. it is going to be a hard day [08:00] apw: [08:01] 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:05] RAOF, that is mad [08:05] Correct! [08:06] Would you like a kernel bug about it? :) [08:06] (Is it reproducible on your system? It seems that it fails - until the 384th time - on three different Mir developers' systems) [08:07] RAOF, nope, i'd file a bug on your code :) [08:07] yep it reproduced just the same, but its your fault :) [08:07] O_TMPFILE requires a mode [08:07] fd = open(argv[1], O_TMPFILE | O_RDWR | O_EXCL, 0644); [08:07] change it to that, and it succeeds on the first one, stack junk being passed [08:08] RAOF, ^ [08:09] apw: For added bonus giggles, run it as root :) [08:09] i don't think i want to know what it does hten [08:10] $ ./X PREFIX [08:10] succeeded at iteration 1 [08:11] 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:12] it is doecumented in the manual page as being required [08:12] 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] 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] (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] file descriptor. [08:13] open is so very special, i am not sure there is any other c abi which has an optional parameter [08:14] and the example in the manual page for it has a mode: [08:14] char path[PATH_MAX]; [08:14] fd = open("/path/to/dir", O_TMPFILE | O_RDWR, [08:14] S_IRUSR | S_IWUSR); [08:14] so where are you seeing an example without [08:15] I'm misreading that example :) [08:15] Thanks! [08:15] ahh good, thats fine then :) [08:15] it is very rare to see modes spelt out, rather than just octal [08:34] good morning [08:38] 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] 384 even === JanC_ is now known as JanC [14:05] hey [14:05] __bjf: ping? === __bjf is now known as bjf [14:05] zyga, what's up? [14:05] !contentless pings ... [14:05] apw: I am only a bot, please don't think I'm intelligent :) [14:05] apw: I am only a bot, please don't think I'm intelligent :) [14:06] apw has awakened the bot storm [14:08] bjf: hey [14:08] bjf: we'd like to shrink the 3.2 test pool for SRU [14:08] bjf: currently it's around 40 systems [14:08] bjf: would that be okay with you? [14:09] smoser, have you tried the 3.16.0-13.19 on your GM45 yet ? [14:09] 3.16.0-13.19 kernel* [14:25] zyga, in general i'm rarely ok with shrinking the test pool .. is there a good reason for doing so? [14:26] zyga, are any of these systems server class or are they all laptops? [14:27] bjf: IIRC we want to reduce the load on the team [14:27] bjf: I don't think there are any severs [14:28] bjf: I'll check and let you know [14:28] zyga, it's all automated [14:28] bjf: that's a good point, let me check why we wanted to do that first [14:31] bjf: launching tests is still not automatic, we need to power up each box, etc [14:32] bjf: there are issues with the number of machines and our AP (access point) capacity [14:32] bjf: there are no severs in the 3.2 pool that we are testing in taipei, there are some in other labs [14:34] bjf: the reason for this request is that ara wants us to prioritize on 12.04.5 testing [14:34] bjf: and SRUs still take a lot of our time to run and check [14:36] 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:37] bjf: no, we're actually asking [14:37] bjf: so if you want us to keep doing this, it's okay to say no [14:37] bjf: and we won't shrink it [14:38] zyga, give me a bit to think about it [14:38] zyga, how many machines would this leave in the 3.2 test pool after the reduction? [14:39] bjf: we'd like to cut the number of machines by half [14:40] zyga, ok, but i don't know how many systems you have now so half of an unknown is an unknown [14:41] bjf: ah, sorry, it's about 40 systems currently [14:41] bjf: 46 to be precise [14:41] zyga, ok, so you'd go down to 20 .. ok, i'll think on it and get back to you soon [14:41] bjf: thanks [14:43] zyga, sorry ... i see that you told me 40 earlier .. my bad [14:44] zyga, will you still be doing testing with the precise kernel or will it just be lts-backport-trusty testing? [14:45] 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] bjf: we're only trying to limit the number of systems, we're going to test all the kernels as usual [14:45] 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:46] bjf: yes, we plan to test the same set of kernels as usual [14:46] bjf: so precise, precise-lts, trusty and perhaps lucid [14:46] zyga, are you saying this is a temp. think (one time only) or a permanent change? [14:46] s/think/thing/ [14:46] bjf: IIRC it's the temp change, let me check [14:47] zyga, ok i *completely* misunderstood you. *yes* i'm ok with a limited test pool for this cycle. [14:48] zyga, apparently i'm still asleep [14:48] bjf: I just confirmed, it is only temporary [14:48] bjf: that's okay, I'm about to get sleepy so we're even :> [14:48] :-) [14:48] zyga, that makes me much happier, yes i'm ok with it [14:48] bjf: thank you [14:49] bjf: just a heads up, if we have the time this cycle, we'll test with the full pool [14:49] (and I know I just keep poppin up new facts) [14:49] bjf: so the half-pool is an option we merely _may_ take [14:49] zyga, sounds good [14:50] bjf: sorry, still getting used to everything here :) === bdmurray_ is now known as bdmurray === apb_ is now known as apb1963 [16:48] sforshee: do you have a kernel built with the fuse patches? [16:50] 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] sforshee: ok i can always push them to ppa [16:50] hallyn: I can get you a build much faster than that [16:50] :) [16:50] do you care what kernel version it's based on? [16:54] sforshee: not particularly. [16:54] i'll just run it in a vm to play with [16:57] hallyn: building, should be done in ~10 minutes [16:58] sforshee: thanks - i probably won't have time to actually set it up today, but hopefully tonight or this weekend [17:00] 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] bug 1363313 in linux (Ubuntu) "mpt2sas not loaded with LSISAS2008 card in trusty 14.04.1" [Medium,Confirmed] https://launchpad.net/bugs/1363313 [17:01] rtg, sure [17:07] 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:18] hallyn: http://people.canonical.com/~sforshee/fuse-userns-build/ [17:18] hallyn: I suppose I could put up some of the things I was doing to test [17:22] sforshee: thanks! looking forward to testing that build :) === Mikee_C_ is now known as Mikee_C === hatch__ is now known as hatch [21:43] 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:44] sforshee: awesome, thanks