[02:47]  * infinity runs out of reasons to still be awake and goes to remedy the situation.
[03:34] <TheDrums> henrix: Howdy, still alive?
[10:11] <tjaalton> drop xorg-server, I'll do a proper merge this time..
[10:11] <tjaalton> including the latest upload
[10:22] <tjaalton> fixed version uploaded
[12:17] <lool> hey there
[12:18] <lool> I'm pushing a block hint on system-image to stage a build in -proposed
[12:20] <lool> uploaded system-image now, let's see if I got that right
[12:20] <cjwatson> looks syntactically fine
[12:21] <lool> I think I might keep it and tell barry to stage upcoming system-image bits there since there is no change of blocking other stuff from migration
[12:21] <lool> didrocks: ^
[12:21] <lool> *chance
[12:29]  * cjwatson cancels libreoffice on sulfur and gives it to sagari instead
[12:31] <zul> can a archive admin approve, glance, keystone and ceilometer please
[12:34] <lool> zul: s/approve/review/  :-P
[12:34] <zul> lool:  yes please :)
[12:34]  * lool is not an archive admin though; sorry
[12:35] <lool> (it's release team really)
[12:38] <xnox> there is now two upstart uploads in saucy-proposed/main.
[12:39] <xnox> can you please reject either of them, both are equivalent, pick whichever you prefer best.
[12:47] <lool> also hinted block lxc-android-config; only seeded in touch
[13:10] <didrocks> lool: sounds good, did you get a chance to test it?
[13:10] <didrocks> lool: so not for next image for system-image?
[13:19] <lool> hinted system-image and lxc-android-config in
[13:19] <lool> after they go in, I will keep the system-image block but lift the lxc-android-config one
[13:20] <smartboyhw> Can somebody have a look at Bug 1234669?
[13:20] <ubot2> Launchpad bug 1234669 in Ubuntu "FFe: Sync ardour3 3.4~dfsg-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1234669
[13:27] <seb128> Laney, do you know if anyone is looking at the intel driver update FFe?
[13:27] <Laney> no I don't
[13:29] <seb128> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1234027 if somebody wants to look at it
[13:29] <ubot2> Launchpad bug 1234027 in xserver-xorg-video-intel (Ubuntu) "FFe: new upstream release 2.99.903" [Wishlist,Confirmed]
[13:29] <seb128> it fixes several issues, including the "screenshots are blank" one
[13:29] <seb128> would be nice to get in saucy (or at least get the fixes backported if we don't get the ffe for the update)
[13:30]  * Laney resets it to New so that it gets on the list
[13:30] <Laney> that auto-confirm feature is the worst (at least for process bugs)
[13:31] <seb128> Laney, thanks
[13:36] <tjaalton> I've just subscribed u-r so probably why it wasn't on the radar..
[13:37] <Laney> that'll do it
[13:38] <tjaalton> now that seb128 will test it on gen5 the testing should be complete
[13:38] <tjaalton> :)
[13:38] <seb128> ;-)
[13:39] <brainwash> seb128: can you have a look at bug 1231978 please? a fix has been committed upstream
[13:39] <ubot2> Launchpad bug 1231978 in gvfs (Ubuntu) "Thunar 1.6.3 locks when browsing Trash with Xubuntu 13.10 Beta 2 and following dailies" [Critical,Confirmed] https://launchpad.net/bugs/1231978
[13:40] <seb128> brainwash, yes, alex (upstream) already pinged about it, it's on my list for today
[13:40] <brainwash> seb128: thanks :)
[13:40] <seb128> brainwash, yw
=== psivaa is now known as psivaa-afk
=== psivaa-afk is now known as psivaa
[14:24] <cjwatson> Could somebody have a look at my apt SRUs?  We need to get them done before Launchpad can safely be upgraded to precise, so I'd like to get the clock ticking as early as possible
[14:47] <lool> unblocked lxc-android-config/0.106
[14:54] <rsalveti> libhybris: bugfix for video seek, if anyway can approve :-)
[14:57] <Laney> ScottK: Riddell: One of you two might want to review kubuntu-settings
[14:57] <Laney> I don't want to go through all of those maintainer script changes
[14:58] <Laney> are they all necessary to do now?
[14:58] <slangasek> cjwatson: apt> done, but could you add an explicit test case to the bugs?
[14:58] <Laney> hmm, a nova stack
[14:59] <cjwatson> slangasek: OK, I'll come up with something after the meeting.  Thanks
[14:59] <Laney> Reminds me that I was going to ask if we should now add another server person to the RT
[17:06] <lool> dbus above seems a critical bug fix for flavors using dbus in user sessions; IIUC, we are starting jobs using dbus before dbus is really ready and that breaks them
[17:07] <infinity> lool: Accepted.
[17:07] <lool> thanks
[17:08] <zul> can we get a release team member to review the openstack please (nova, glance, keystone, ceilometer, etc)
[17:09] <infinity> zul: Are there FFes for all these massive diffs?
[17:10] <zul> infinity:  its my understanding  that they dont need one since their all point releases for bugs fixes etc
[17:10] <zul> jamespage:  ^^^
[17:11] <infinity> They're not point releases...
[17:11] <infinity> beta -> rc is development releases, and there are certainly some massive changes in here.
[17:11] <infinity> (Not that I'm arguing against us pushing toward the final upstream releases, but it would be nice to know someone's gone through and tested some of this, cause I can't review a 3MB diff)
[17:11] <jamespage> infinity, we can raise a FFe if required; the target for saucy has always been 2013.2
[17:13] <infinity> jamespage: Verbal confirmation that this has seen some sort of testing and sanity checking would be alright.  I don't need a formal process, just reassurance. :P
[17:13] <zul> infinity: it has been tested and sanity checked
[17:13] <jamespage> infinity, sure - bearing in mind the insane upstream gating of commits and the fact we also build/test against trunk in our CI lab I'm pretty comfortable with this :-)
[17:14] <jamespage> infinity, I also have a full openstack environment just waiting to test these again once they land in distro - all running b3 right now
[17:16] <xnox> cjwatson: Laney: do you have your codesearch instance URL handy?
[17:17] <cjwatson> xnox: http://162.213.35.4/
[17:19] <xnox> cjwatson: thanks.
[18:12] <infinity> stgraber: Is the reboot-required postinst thing really necessary, given that it's a one-time thing and people who run devel releases either (a) reboot constantly anyway or (b) ignore reboot-required?
[18:12] <stgraber> infinity: slangasek asked for it, I added it :)
[18:13] <infinity> (To be fair, I'm not even sure how I'm supposed to know reboots are required anymore... The gear doesn't turn red anymore, and I see no visual indicator that I need a reboot, despite clearly having upgraded rebooty packages in the last 11 days)
[18:13] <slangasek> reboots are always one-time things
[18:13] <slangasek> infinity: you're failing to use update-manager :P
[18:13] <infinity> slangasek: I meant the postinst is a one-time thing.
[18:14] <infinity> slangasek: True, I don't use update-manager.  If it's the only thing that usefully displays reboot notifications at the GUI level, that seems like a regression to me.
[18:14]  * infinity shrugs.
[18:15] <infinity> The system menu used to be fairly obvious about it, which seemed useful.
[18:16] <infinity> Since you might ignore u-m's initial recommendation (cause you're running some long-running process or whatever) and want a constant nag.
[18:16] <slangasek> I don't remember if that's a deliberate behavior change, or if the gear not changing color is a regression
[18:16] <slangasek> bdmurray: ^^ do you know?
[18:16] <slangasek> infinity: currently, the "constant nag" is that you can't dismiss u-m's notification, you can only click 'reboot'
[18:17] <slangasek> but I don't know if that's intentional
[18:17] <infinity> slangasek: It used to change the color *and* have a "reboot required" string in the menu itself, near the logout/suspend entries.  Both are gone.  I assumed it was a deliberate design decision.
[18:17] <infinity> slangasek: You can't close u-m with the X? :P
[18:17] <slangasek> having update-manager keeping a memory-hogging window open as a reminder somewhere on your desktop is annoying
[18:17] <slangasek> infinity: there's no X
[18:17] <infinity> Oh.
[18:17] <infinity> Shows how long it's been since I ran u-m.
[18:18] <infinity> Hah.  Damnit.
[18:18] <infinity> And running u-m kicked me immediately to the reboot dialog.
[18:18] <infinity> At least it's not modal...
[18:41] <xnox> infinity: slangasek: gear not changing red is intentional change.
[18:41] <xnox> infinity: there is also MOTD that reboot is required on console logins.
[18:42] <xnox> infinity: these days update manager insist on reboot required, it says that at the end of installing updates and only has shutdown-now button and no other way to close it. (one can minimise it)
[18:42] <infinity> xnox: Sure, but that doesn't address the GUI nag issue.  I almost never log in to a console on my laptop, except when debugging why the GUI broke. :P
[18:42] <xnox> for me update-manager shakes and goes to foreground with "reboot now" button ....
[18:43] <infinity> Oh well.  I pretty much never win arguments with design people, so I don't think I'll bother trying.
[18:43]  * xnox actually uses update-manager. it became useful after mpt's grouping of packages and now i catch deadly updates more often with my eyes then apt-get's output.
[18:44] <slangasek> xnox: MOTD is only shown if you have a console login; it doesn't constitute a persistent reminder that the reboot is required, so if you ignore the initial "reboot required" from u-m (or are refusing to dogfood, like infinity), you get no ongoing reminder
[18:57] <slangasek> stgraber: and android-tools made it into saucy with no problems
[19:02] <stgraber> slangasek: good
[19:41] <infinity> slangasek: I'm not even sure it's an intentional refusal to dogfood, update-manager just no longer pops up for me.  I assume that's something I did that changed that, but it seemed a pleasant enough change for someone who prefers to run apt-get anyway. :P
[19:44] <balloons> so for the final rc images, builds planning to start on the 10th? what to make sure everything is lined up properly
[19:55] <infinity> balloons: Final Freeze is the 10th, so that would be the beginning of the RC week, yeah.  Unless we're working magic, I wouldn't expect those to be the final images, mind you.  But we'll want heavy testing regardless.
[19:56] <balloons> infinity, :-) Just wanted to make sure before I pushed on everyone to be ready on the 10th
[20:01] <slangasek> infinity: hmmm, I wonder what changed to make update-manager not pop up for you; there was a flag for a while that you could use to say "I want this in the indicators, not as a pop-up", but then that stopped working, so I believe we now ignore the flag
[20:02] <slangasek> infinity: in any event, update-manager is how we expect people to use our "constantly-usable" devel series, and there are u-m-specific issues with conflicts/replaces that require certain gardening; it would be good to have more people dogfooding u-m generally
[20:06] <infinity> slangasek: Yeah, I'm not sure either.  I haven't seen it pop in ages, and assumed it was something I did locally, as others would have complained if it was a global thing.
[20:07] <slangasek> infinity: does running 'update-manager --no-update' work from the commandline?
[20:08] <infinity> Hah, no.  That crashes.
[20:08] <slangasek> well, there ya go then
[20:08] <infinity> Works without the --no-update switch.
[20:10] <infinity> http://paste.ubuntu.com/6189674/
[20:10] <infinity> apport claims it's bug #1219414
[20:10] <ubot2> Launchpad bug 1219414 in update-manager (Ubuntu) "update-manager crashed with AttributeError in start(): 'NoneType' object has no attribute 'set_functions'" [Medium,Confirmed] https://launchpad.net/bugs/1219414
[20:13] <stgraber> https://errors.ubuntu.com/problem/10857477ccaa1e6f187c2f983099ea169dfa10af and https://errors.ubuntu.com/problem/9bfd367a2cf6a93d63e1a12e877d629ef90ead0f
[20:16] <infinity> So, started happening in 0.190, if errors is to be believed.
[20:17] <infinity> 189 seems more likely.  Maybe that didn't live long enough to get installed anywhere.
[20:19] <slangasek> infinity: ironically, that backtrace points to a bug in showing the 'needs restart' dialog
[20:20] <infinity> slangasek: Which works if I call it without --no-update.
[20:21] <infinity> Could also explain why more people don't see it.  Cause you'd have to get into a restart-needed state without update-manager before it tries to run.
[20:21]  * slangasek nods
[20:21] <slangasek> so, it's caused by xnox's refactor? :)
[20:21] <infinity> And I suspect not everyone haphazardly mixes apt-get and update-manager like I do.
[20:23] <infinity> Though, this doesn't explain why I haven't seen the dialog in months.
[20:23] <infinity> I can't possibly always be in a restart-needed state.
[20:23] <infinity> Well, maybe I am almost all the time. :P
[20:23] <infinity> Hard to say for sure.
[20:24] <slangasek> infinity: want to try a one-line change, to add self.window_main.realize() before the self.window_main.get_window() ?
[20:25] <infinity> I've closed the backtrace.  Which file and line was that?
[20:25] <infinity> Oh, wait, it's up there.
[20:25] <slangasek> /usr/lib/python3/dist-packages/UpdateManager/Dialogs.py:285
[20:26] <infinity> slangasek: That did it.
[20:27] <slangasek> infinity: bug reproduced here, fix confirmed; I'll go ahead and upload
[20:27] <infinity> I have mixed feelings about this being fixed.
[20:27] <infinity> Now I'll see u-m again. :P
[20:28] <infinity> But, happy that my anecdote led to a bug fix.
[20:36] <infinity> slangasek: Hrm, my testing methodology might be faulty, though.
[20:36] <infinity> slangasek: Removing that line, it still works.
[20:36] <slangasek> infinity: mine wasn't :)
[20:36] <infinity> slangasek: Maybe running u-m succesfully changed its state somehow.
[20:37] <slangasek> sudo /usr/share/update-notifier/notify-reboot-required; update-manager --no-update --> confirm failure; edit; update-manager --no-update --> confirm success
[20:38] <infinity> slangasek: Yeah, see, I removed the line here now, and "sudo /usr/share/update-notifier/notify-reboot-required; update-manager --no-update" doesn't crash anymore.
[20:38] <infinity> slangasek: So, WTF is up with that? :P
[20:39] <slangasek> infinity: oh.  you ran 'update-manager' in between without the '--no-update' option?
[20:39] <infinity> slangasek: I did at some point, yes.
[20:39] <slangasek> and it showed you a list of available updates to apply?
[20:40] <infinity> slangasek: But now I just redid notify-reboot-required and update-manager --no-update with no update-manager in between, and still works (without the fix).
[20:40] <slangasek> so it's not trying to show you the 'reboot required' dialog now because you have a list of available updates to apply ;)
[20:40] <infinity> slangasek: Oh, right.  Drawing a different window first.  Check.
[20:40] <infinity> If I dist-upgrade, that should go away.
[20:40] <infinity> Let's see.
[20:40] <slangasek> yep
[20:40] <slangasek> or if, y'know, you *use update-manager*
[20:40] <infinity> If apt-listchanges and update-manager still got along, maybe I'd use it more.
[20:41] <infinity> Or did that ever get fixed?
[20:41] <slangasek> wasn't aware that they didn't get along
[20:41] <slangasek> regardless
[20:41] <slangasek> u-m in queue, please review
[20:42] <infinity> Okay, reproduced and verified fixed after an upgrade.
=== seb128_ is now known as seb128