[06:19] <ppisati> moin
[08:04]  * apw yawns
[08:05]  * smb waits for his coffee to be ready...
[08:08]  * apw watches the kettle boil
[10:35]  * ppisati -> laundry + out for lunch
[12:37] <apw> henrix, did you get your packages signed ?
[12:53] <henrix> apw: yeah, sorry... forgot to give you an update
[12:54] <apw> good enough
[12:54] <henrix> apw: since natty was urgent, bjf took a look at it, signed and i uploaded it
[12:54] <apw> thats great
[12:54] <henrix> apw: anyway, we may need to re-start the cycle...
[12:55] <henrix> with the leap-sec patches
[12:55] <henrix> sru cycle is kind of stalled atm
[13:06] <smb> Perfect time then to slip in even more "stuff" :-P
[13:39] <apw> bjf, it seems there is a v3 of the leap patches: https://lkml.org/lkml/2012/7/2/530
[13:39] <apw> henrix, its nor clear why we would restart the cycle for them, there won't be another leap second for 6m minimum
[13:40] <henrix> apw: yeah, i know. its just that were some discussions about this yesterday 
[13:41] <henrix> apw: and it wasn't clear if we wanted to have this in in this cycle
[13:41] <henrix> apw: we still have time for that, but i guess it's not urgent :)
[13:42] <henrix> anyway, we have a few kernels already on the ppa, and some more pkgs ready for signing
[13:42] <ogasawara> henrix, apw: I'd agree it's not urgent at this point since the leapsecond has already passed and won't happen in the immediate future.  However I think there is a bit of a fire drill going on with some of our customer facing groups who would like to be able to communicate a fix is being applied in and available in the next cadence.
[13:44] <henrix> yeah, i understood that. the only issue at this point is that the fix seems to be still under discussion. 
[13:47] <ogasawara> henrix:  at this point, if a final version of the patch set emerges in time to hit this SRU window, let's land it.  but if it's still being discussed, it would seem reasonable to me to wait for the next cadence cycle.
[13:48] <henrix> ogasawara: makes sense
[14:12] <smb> ogasawara, How much beating (or are we allowed at all) would it cost to get rid of some deprecated acpi procfs files in quantal (to catch the fallout) that potentially were scheduled to be removed long ago...?
[14:13] <ogasawara> smb: if we want to yank anything, I think now would be the time
[14:14] <ogasawara> smb: if you have a patch, I'll likely take it
[14:14] <smb> Then maybe to turn ACPI_PROCFS_POWER off would be a good opportuinity
[14:14] <cking> ..and see what breaks :-)
[14:15] <smb> Ok, can whip up a patch quickly... Though I probably want to make sure it still builds... before I send it
[14:15] <ogasawara> smb: ack
[14:28] <bjf> apw, sweet, will look at that in a bit when i'm more awake
[14:36] <apw> bjf, np, no idea if its a final of course
[14:37]  * ogasawara back in 20
[14:46] <bjf> apw, reading that mail thread it seem a little premature to be rushing any set of patches out the door at this point
[14:47] <apw> bjf, i tend to agree; the next leap is also at least 6m away
[15:42] <ppisati> brb
[16:24] <ppisati> do we have any official where we are going to stay for the kernel sprint?
[16:25] <ogasawara> ppisati: yes, I'll send a quick email to everyone right now
[16:25] <ogra_> you guys get travel approval for sprints ?!?
[16:25] <ogra_> lucky you
[16:26] <ogasawara> ogra_: your team should too
[16:27] <ogra_> well, our sprints are virtual and many nowadays :)
[18:49]  * ogasawara lunch
[20:03] <cking> bjf, so I won't be needing waldorf, I've managed to reproduce the issue on my local boxes now
[20:04] <bjf> cking, nice
[20:05] <cking> bjf, actually, it's two issues compounded into one bizarre characteristic :-/
[20:34]  * cking --> EOD
[22:09] <nhm> Can a linux-tools package be produced with make-kpkg?