[06:40] <RAOF> apw: Hey, ho! Need any bees?
[07:54] <apw> RAOF, send me a whole container please .. it is going to be a hard day
[08:00] <RAOF> apw: 
[08:01] <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:05] <apw> RAOF, that is mad
[08:05] <RAOF> Correct!
[08:06] <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:07] <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:08] <apw> RAOF, ^
[08:09] <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:10] <apw> $ ./X PREFIX
[08:10] <apw> succeeded at iteration 1
[08:11] <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:12] <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:13] <apw> open is so very special, i am not sure there is any other c abi which has an optional parameter
[08:14] <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:15] <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:34] <zyga> good morning
[08:38] <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
[14:05] <zyga> hey
[14:05] <zyga> __bjf: ping?
[14:05] <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:06] <rtg> apw has awakened the bot storm
[14:08] <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:09] <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:25] <bjf> zyga, in general i'm rarely ok with shrinking the test pool .. is there a good reason for doing so?
[14:26] <bjf> zyga, are any of these systems server class or are they all laptops?
[14:27] <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:28] <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:31] <zyga> bjf: launching tests is still not automatic, we need to power up each box, etc
[14:32] <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:34] <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:36] <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:37] <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:38] <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:39] <zyga> bjf: we'd like to cut the number of machines by half
[14:40] <bjf> zyga, ok, but i don't know how many systems you have now so half of an unknown is an unknown
[14:41] <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:43] <bjf> zyga, sorry ... i see that you told me 40 earlier .. my bad
[14:44] <bjf> zyga, will you still be doing testing with the precise kernel or will it just be lts-backport-trusty testing?
[14:45] <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:46] <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:47] <bjf> zyga, ok i *completely* misunderstood you. *yes* i'm ok with a limited test pool for this cycle.
[14:48] <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:49] <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:50] <zyga> bjf: sorry, still getting used to everything here :)
[16:48] <hallyn> sforshee: do you have a kernel built with the fuse patches?
[16:50] <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:54] <hallyn> sforshee: not particularly.  
[16:54] <hallyn> i'll just run it in a vm to play with
[16:57] <sforshee> hallyn: building, should be done in ~10 minutes
[16:58] <hallyn> sforshee: thanks - i probably won't have time to actually set it up today, but hopefully tonight or this weekend
[17:00] <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:01] <jsalisbury> rtg, sure
[17:07] <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:18] <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:22] <hallyn> sforshee: thanks!  looking forward to testing that build :)
[21:43] <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:44] <hallyn> sforshee: awesome, thanks