[04:58]  * shuduo is away: auto-away
[05:05]  * shuduo is back (gone 00:07:21)
[05:38]  * shuduo is away: auto-away
[05:56]  * shuduo is back (gone 00:17:53)
[05:58] <RAOF> !away > shuduo 
[05:58] <ubot2> shuduo, please see my private message
[07:43] <ppisati> moin
[08:55]  * apw yawns widly
[08:55] <smb> morning
[08:55] <apw> morning
[12:50] <ppisati> herton: when you are awake, can you tell me if shank bot changes that yopu mentiond in the email are already effective? IOW, shall i fiddle with "upload to ppa" or "prepare pkg" for the already opened tracking bugs?
[13:00] <herton> ppisati, just change upload-to-ppa, bot should be running with the changes now
[13:45] <apw> herton, oh i have to change upload-to-ppa still
[13:49]  * henrix -> late lunch
[13:50] <herton> apw, yep, but it's not a big issue, the bot just ignores it for now and will move tasks forward independent of it
[13:51] <rtg_> apw, so I saw in a recent status that you decided the parallel boot patches were no longer helping, right ?
[13:52] <apw> rtg_, that is possibly unfair, i think they are contributing a very small proportion compared to what they did in precise
[13:52] <apw> rtg_, but of the order of a low enough amount as they are it may not really be worth the risk
[13:52] <rtg_> apw, do you think they are worth the effort anymore then? 
[13:52] <apw> rtg_, i intend to get back to that and confirm, and make a proposal, probabally early next week
[13:52] <rtg_> I'd vote no unless they make a substantial difference
[13:52] <apw> rtg_, they may not be really, but for very time critical platform they might
[13:53] <rtg_> do we have one of those ?
[13:53] <apw> we may, not sure
[13:53] <rtg_> hmm
[13:53] <rtg_> back in a sec
[13:53] <apw> rtg_, they have become ineffective because people have (correctly) added a lot of modprobes in drivers
[13:54] <apw> rtg_, and we have to sync the initramfs immediatly in that case, which essentially undoes most of the potential savings
[13:55] <apw> rtg_, my investigation was about whether some of those are essentially async and could thus avoid holding up the mainline
[13:55] <apw> rtg_, as in many cases they are 'we might need this sometime, probe it just in case' style modprobes
[14:40]  * rtg_ -> eye doc appt
[15:06] <ppisati> brb
[15:35]  * ogasawara back in 20
[17:03]  * apw calls it a day
[17:08]  * smb decides thats a good idea
[17:12] <kamal> rtg_: so...   CONFIG_ALX *did* break the quantal build, eh?:   UBUNTU: [Config] CONFIG_ALX=m for x86 only
[17:12] <rtg_> kamal, yep, but we don't expect you to airlift beer to us.
[17:12]  * ppisati -> goes for some pain
[17:12] <ppisati> IOW -> EOW
[17:12] <kamal> rtg_: ok but how come the same "for x86 only" fix applied to raring too?
[17:13] <kamal> *sigh*
[17:13] <kamal> how come the same fix is *not* also applied to raring, I mean.
[17:13] <rtg_> kamal, it was PPC that failed. we don't build PPC for raring
[17:13] <kamal> rtg_: good answer
[17:13] <rtg_> which is why it would have been hard for you to detect
[17:13] <kamal> um... *yeah* that's the ticket!  ;-)
[17:14] <rtg_> don't sweat it. the process is working.
[17:14] <kamal> and somehow bjf didn't come after my head over this?  *sweet*!
[17:14] <rtg_> I put the stinkeye on him. I've got your back :)
[17:14] <bjf> kamal, nope, didn't reach for the shank
[17:14] <kamal> rtg_: my hero!
[17:15] <kamal> thanks bjf!  ("no regressions, guaranteeeeeed!")
[17:16] <bjf> kamal, noone cares about PPC
[17:16] <kamal> *cough*
[17:16] <rtg_> except BenC (and some other folks)
[18:07]  * henrix realises pubs are closing in < 9 hours. better run!
[18:25]  * rtg_ -> lunch
[20:02]  * ogasawara lunch
[20:38]  * rtg_ -> EOW
[23:20] <sconklin> ogasawara: ping