=== rickspencer3_ is now known as rickspencer3
[08:27] <jibel> there is no desktop image for the last 3 days. can anyone have a look ?
[08:33] <Daviey> the cronjob suggests it's currently building
[08:40] <jibel> Daviey, could it be a problem with ppc ? I don't have a view on the builder but from the date of the livefs build logs, the 8th ppc was built 14h after x86, 8h on the 9th, and there is no log for PPC yesterday and today. and there is no cd build log at all for all arch since the 10th
[08:50] <Daviey> jibel: I see build logs for 09,10,11,12 ?
[08:50] <cjwatson> There's certainly some kind of backlog, judging from nusakan's process list
[08:50] <Daviey> jibel: cd images dated today http://cdimage.ubuntu.com/daily/current/ ?
[08:51] <Daviey> there are indeed a bunch of powerpc blocking
[08:51] <cjwatson> Daviey: not live CDs, so not relevant
[08:51] <jibel> Daviey, but no desktop http://cdimage.ubuntu.com/daily-live/
[08:51] <Daviey> cjwatson: That was an intentional oversight, and i was wondering who would spot it.
[08:52] <Daviey> Perhaps related, the machine was rebooted 3 days ago.
[08:52] <Daviey> 4 now
[08:53] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/lubuntu/latest/livecd-20120609-powerpc.out - stuck in update-initramfs maybe?
[08:53] <cjwatson> (that was the oldest, I killed it)
[08:56] <cjwatson> OK, so I've killed a bunch of the backlog.  The three currently trying to build are livecd-base/quantal, ubuntu/daily-live/precise, and ubuntu/daily-live/quantal
[08:56] <cjwatson> So we'll see whether those repeat the problem
[08:56] <jibel> thanks
[08:56] <cjwatson> Failing that, it'll probably need somebody like infinity to investigate
[09:01]  * Daviey leaves it then.
=== rickspencer3_ is now known as rickspencer3
[11:08] <Riddell> no daily CDs since the 9th?
[11:11] <cjwatson> see scrollback
[11:12] <cjwatson> At this point I can't see what's going on on royal, and am waiting for infinity to wake up to assist
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest63012
[14:06] <xnox> infinity: thanks for the libconfig rebuild/transition =)
[14:07] <infinity> xnox: NP.
[14:13] <pgraner> infinity, ppc hw info pls </friendly reminder>
[14:14] <xnox> yeah ppc is slow =) my boost1.49 transition is lagging due to ppc =((((((
[14:15] <pgraner> xnox, poke infinity then :-)
[14:15] <Laney> why is ross disabled?
[14:16] <xnox> Laney: see notes on the builder
[14:16] <xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005699 RT#51115
[14:16] <ubot2> Launchpad bug 1005699 in linux "tg3: reports "eth0: DMA Status error. Resetting chip.", fails to work" [High,Confirmed]
[14:16] <infinity> Because it was upgraded to precise and ran into a kernel bug.
[14:16] <Laney> builders have notes?
[14:16] <infinity> ^
[14:16] <infinity> Laney: They do when I add them. :P
[14:16] <xnox> Laney: just below the status on this page https://launchpad.net/builders/ross
[14:16] <Laney> I didn't even know that was a thing
[14:16] <Laney> ta
[14:25] <cjwatson> infinity: Speaking of powerpc, can you tell what's happening on royal?
[14:29] <infinity> cjwatson: No, but webops can.
[14:30] <infinity> cjwatson: I haven't had direct access to buildds since I came back.
[14:31] <cjwatson> infinity: Ah, my bad, I thought you did.
[14:31] <infinity> Wish I still did.  Would make my life easier. :P
=== Guest63012 is now known as Ursinha
=== Ursinha is now known as Guest90889
=== Guest90889 is now known as Ursula
=== rickspencer3 is now known as rickspencer3_
[16:45] <seb128> skaet, slangasek: should bug #987220 we tracked for the lts maybe? it seems a quite frequent complain
[16:45] <ubot2> Launchpad bug 987220 in upstart "no complete shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/987220
[16:45] <seb128> not sure who,what team would be the best placed to look at that
[16:47] <slangasek> seb128: is it reproducible, tractable?
=== rickspencer3_ is now known as rickspencer3
[16:48] <slangasek> seb128: there are probably separate issues here - the users saying "halt doesn't work" have an incorrect expectation of the behavior of 'halt', and that's probably most of the interest in the bug
[16:49] <slangasek> so I guess the question is... is GNOME incorrectly calling 'halt' as well :)
[16:49] <slangasek> GNOME and/or indicator-session
[16:50] <seb128> slangasek, well, let's say I hit an issue at least once a week where shutdown does trigger a shutdown (i.e session closing, init going to the corresponding level, services being stopped, but the machine actually never power off), I was wondering if that's the same issue
[16:50] <seb128> slangasek, I've seen quite some people complaining about that "never power off"
[16:50] <slangasek> seb128: it may be... do you know what command indicator-session is calling to shut down?
[16:51] <seb128> slangasek, hints on how to debug would be welcome
[16:51] <slangasek> code inspection
[16:51] <slangasek> if it's related, then it's because something is calling 'halt' based on the same wrong assumption of the meaning of this command
[16:52] <seb128> slangasek, I need to check but I think indicator-session justs uses the gnome-session interface, which might call consolekit or the login manager
[16:53] <seb128> slangasek, well, I doubt indicator-session call different commands according to the day so it's not as simple as "it's calling a buggy command" I guess
[16:56] <slangasek> well, we should probably be sure anyway.  Do you know what package that code lives in?
[17:02] <seb128> slangasek, so indicator-session does a call to gnome-session's RequestShutdown dbus interface ... checking what that does
[17:04] <slangasek> seb128: does it?  When I looked at indicator-session I saw it pointing at consolekit
[17:05] <slangasek> and consolekit calls the correct interface
[17:06] <seb128> slangasek, you looked to consolekit_fallback()?
[17:06] <seb128> 	} else if (action == LOGOUT_DIALOG_TYPE_SHUTDOWN) {
[17:06] <seb128> 		g_debug("Asking Session manager to 'RequestShutdown'");
[17:06] <seb128> 		res = dbus_g_proxy_call_with_timeout (sm_proxy, "RequestShutdown", INT_MAX, &error,
[17:06] <seb128> 											  G_TYPE_INVALID, G_TYPE_INVALID);
[17:06] <seb128>  
[17:06] <seb128> slangasek, that seems the normal action in gtk-logout-helper.c
[17:06] <seb128> ck seems the be the fallback
[17:07] <seb128> slangasek, but gnome-session uses ck as well
[17:07] <seb128>         res = dbus_g_proxy_call_with_timeout (manager->priv->ck_proxy,
[17:07] <seb128>                                               "Stop",
[17:08] <slangasek> seb128: I was looking in src/gtk-logout-helper.c
[17:08] <seb128> slangasek, right, you looked at consolekit_fallback() which is a the top of this file
[17:08] <seb128> slangasek, down the file there is the code I copied, anyway they both call ck Stop
[17:08] <slangasek> ah
[17:08] <slangasek> ok
[17:09] <slangasek> seb128: have you reproduced this bug yourself?
[17:10] <seb128> slangasek, as said it happens to me once a week
[17:10] <slangasek> hmm
[17:10] <seb128> my laptop goes all the way down like it was stopping but never actually power off when that happens
[17:10] <seb128> I'm not 100% sure that's what all those users have but it seems similar
[17:10] <slangasek> many of the users are seeing user error
[17:11] <slangasek> and I never shut down my laptop, I reboot it or suspend it... so I can't say if your experience is typical
[17:11] <slangasek> what % of the time do you hit the issue?
[17:11] <seb128> ok
[17:11] <seb128> random guess; 5%
[17:11] <slangasek> crazy
[17:12] <seb128> well "rought estimation"
[17:12] <slangasek> and the GUI shuts down, leaving you at a kernel console, and fails to power off?
[17:12] <seb128> I usually power off my laptop once a day
[17:12] <seb128> the guy shut off, I see the typical vt "stopping ..." lines
[17:12] <seb128> then at the point it would normally power off it "sits" there
[17:12] <seb128> I need to press the power button 5 seconds to power it off at this point
[17:13] <slangasek> I guess I would like to see a screen capture of the hung state
[17:13] <seb128> guy->gui
[17:13] <slangasek> to rule out it being a userspace issue... but it's probably a kernel issue
[17:13] <seb128> ok, I will take one next time it happens
[17:13] <slangasek> cheers
[17:13] <seb128> can I get any other useful info when the system is in this state?
[17:13] <seb128> or after reboot?
[17:14] <slangasek> maybe, but I don't want to have you do a bunch of extra debugging that's speculative... want to know what's on the screen and see where we should go from there
[17:16] <seb128> slangasek, ok, I will ping you back with those infos when I get them ;-)
[17:17] <slangasek> seb128: sounds good, thanks :)
[17:18] <seb128> slangasek, thank *you* for helping ;-)
[18:44] <SpamapS> can somebody queue-jump this build: https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.25-0ubuntu2/+build/3570349 .. the archive is already skewed badly for mysql and i386 landing well before amd64 will just skew it worse.
[18:45] <infinity> SpamapS: I already did.
[18:45] <SpamapS> oh
[18:45] <infinity> Oh, I can jump it harder. ;)
[18:45] <SpamapS> did you mean to push it back behind the others?
[18:45] <infinity> No.
[18:45] <SpamapS> As I was typing that I thought 'huh.. 999999 looks odd'
[18:46] <infinity> Higher = better.
[18:46] <infinity> But let me give it a disabled buildd. :P
[18:46] <SpamapS> ok
[18:46] <infinity> There.
[18:46] <infinity> Jumped with prejudice.
[18:46] <infinity> Here's hoping the MySQL testsuite doesn't rely heavily on perl.
[18:46] <SpamapS> Well I think it should be ok.. the uninstallability is coming from >='s not =='s
[18:47] <SpamapS> so actually i386 landing early should be fine
[18:47] <SpamapS> infinity: no they rewrote it in scala
[18:47] <SpamapS> with an erlang backend and node-js for stats
[18:47] <infinity> Tell me that's a joke.
[18:47] <SpamapS> mysql is web scale ;)
[18:47] <micahg> lol
[18:47] <infinity> Please.
[18:48] <SpamapS> perl, its all perl
[18:48] <infinity> Right, well, we'll see if it explodes.
[18:48]  * SpamapS will bring marshmallows
[18:48] <infinity> hardy kernels and quantal's perl have disagreements.
[18:48] <infinity> And I think I confused allspice.
[18:49]  * infinity tries another.
[18:51] <SpamapS> thats the problem with calling an LTS "hardy" .. sysadmins just don't want to replace their hardy old friend with some lucid hippie or a precise git.
[18:51] <infinity> No, the real problem was that we dropped Xen support in the interim LTS. :/
[18:52] <infinity> Thankfully, it's back.
[18:53] <SpamapS> we're just kvm haters? ;)
[18:53] <SpamapS> rpl.rpl_ssl1 'mix' [ pass ] 3613
[18:53] <SpamapS> hooray
[18:53] <infinity> We had pretty valid reasons for going with Xen back in the day.
[18:53] <SpamapS> Xen was better than kvm for a long time
[18:54] <infinity> Most of those reasons aren't particularly important anymore, but changing one's infrastructure for the flavour of the month is silly.
[19:10] <micahg> infinity: I guess you don't want mysql built before tomorrow :P
[19:10] <infinity> micahg: ?
[19:10] <micahg> yellow is soooooo slow
[19:10] <infinity> Oh, bah.  It's not THAT bad.
[19:11] <infinity> It builds in 3.3h on a Panda, yellow's not slower than that. :P
[19:11] <micahg> I guess as long as no = are breaking badly, it doesn't matter much anyways
[19:11] <micahg> ah, fine, I thought it was much worse than that
[21:54] <micahg> could I get the apparmor security updates above approved?
[22:32] <micahg> infinity: are you still around?
[22:32] <infinity> micahg: Nope.
[22:32] <micahg> infinity: can you approve my apparmor -security syncs?
[22:35] <infinity> micahg: To which releases?
[22:36] <micahg> lucid, natty, oneiric, precise (I used copyPackage from the security PPA)
[22:36]  * infinity is so grumpy that those have no diffs.
[22:36] <infinity> micahg: What are you fixing in apparmor in the Mozilla PPA? :P
[22:36] <micahg> infinity: abstractions, diffs are in that PPA if you want
[22:39] <infinity> micahg: Kay, in the middle of a meeting right now, but I'll poke it shortly.
[22:40] <micahg> infinity: thanks
[23:05] <infinity> skaet: Can you mail out the raw notes/minutes to everyone who was in that meeting just now?  I don't want to have to remember some URL to a Google doc. ;)
[23:06] <skaet> infinity,  will do.
[23:07] <Daviey> skaet: can you send it to a wider audience please? :)
[23:08] <skaet> Daviey,  ack.   Needs to be made prettier though first.