[00:02] <JackYu> xnox, hi, Did ubuntu-kylin-software-client and ubuntukylin-default-settings get accepted? Maybe I miss something from the queuebot:)
[00:02] <xnox> JackYu: i didn't get email, let me check queue
[00:02] <JackYu> sorry, ubuntu-kylin-software-center (not client):(
[00:03] <xnox> JackYu: ubuntu-kylin-software-center is still in the new queue.
[00:03] <roaksoax> slangasek: sounds good to me! thanks
[00:03] <JackYu> xnox, oh, thanks.
[00:03] <slangasek> JackYu, xnox: I'm reviewing ubuntu-kylin-software-center now
[00:04] <xnox> JackYu: ubuntukylin-default-settings 1.1.4 is in the arhive since 8th of april
[00:04] <slangasek> xnox: yes, but there's one in unapproved that goes in once uksc is accepted
[00:04] <JackYu> slangasek, great! It's 8 am here. Our QA team is waiting for the latest ISO:)
[00:05] <xnox> slangasek: ah, yeah i see it now.
[00:05] <slangasek> hmm, is archive.ubuntukylin.com:10006 the production port for the service?
[00:05] <xnox> slangasek: queue names like search thing is not substring based search =(
[00:05] <JackYu> xnox, slangasek, yep. We will upgrade something in ubuntukylin-default-settings 1.1.5.
[00:06] <JackYu> slangasek, yep.
[00:06] <slangasek> ok
[00:07] <xnox> my old job only allowed 80, 443 and 22 out =)
[00:07] <wgrant> Yeah, that sounds pretty bad for firewalls...
[00:07] <xnox> and 443 had to be ssl traffic, they inspected it.
[00:07] <slangasek> wgrant: there's only one firewall that matters for this particular archive, and it's the one at the border ;)
[00:07] <wgrant> Heh
[00:07] <xnox> wgrant: it's like kees "ssh over dns queries" backdoor into buildds =)
[00:09] <wgrant> xnox: +queue text search is a per-term prefix search, not a full substring search, for performance reasons.
[00:09] <slangasek> xnox: was the switch to a native package discussed with upstream? Because upstream did have a tarball release on LP
[00:10] <xnox> slangasek: the upstream had "_2.9.2.orig.tar.gz" and debs uploaded into 2.9.2 release that did not match their trunk branch -> and clearly came from a daily recipe builds that generated the tarball.
[00:10] <slangasek> xnox: ah, ok
[00:10] <slangasek> xnox: but - you did also discuss this change with upstream, right? :-)
[00:10] <xnox> slangasek: and upstream accepted my merge proposal to switch to native.
[00:10] <slangasek> ok good
[00:10] <xnox> slangasek: and i'm upstream committer now as well
[00:11] <xnox> slangasek: i should merge that reviewed branch now =)
[00:12] <xnox> slangasek: done, upstream trunk is tagged 0.2.9.1 and matches the upload.
[00:12] <slangasek> xnox: aren't you missing some from __future__ import print_function here?
[00:12] <slangasek> I see an awful lot of print->print() changes, but no print_function anywhere
[00:12] <slangasek> not a NEWing consideration, but it might be useful if the app doesn't fail immediately with python backtraces
[00:14] <xnox> slangasek: i did not do that. let me check.
[00:15] <xnox> slangasek: yeah i see that introduced / used refactored in a few places.
[00:15] <slangasek> xnox: you want to fix/upload?
[00:16] <xnox> slangasek: yeah.
[00:17] <xnox> slangasek: shokingly "pyflakes" doesn't tell me about them.
[00:17] <slangasek> otherwise, the package as a whole looks fine, so accepted
[00:17] <slangasek> xnox: right, I noticed because it was in the debdiff vs. the previous version
[00:17] <slangasek> (that I had been poking at locally)
[00:21] <xnox> slangasek: clearly i didn't manage to generate any exceptions while testing it =) cause they'd crash
[00:30] <JackYu> slangasek, xnox, thanks a lot. Would you help to take a look the ubuntukylin-default-settings 1.1.5?
[00:35] <xnox> slangasek: i'm opting in for revert - http://paste.ubuntu.com/7232982/
[00:36] <xnox> slangasek: adding "from __future__  import print_function" results in invalid syntax errors, as only a handful of print's are functions, the rest are statements. Refactoring everything to print function is a huge diff, better done as part of porting to python3.
[00:36] <xnox> slangasek: and the revert to a consistent print statement is smaller diff.
[00:36] <xnox> and i'd rather have 1 style through all code base.
[00:36] <slangasek> xnox: ack
[00:38] <xnox> ./ui/uksc.py:140: undefined name 'data'
[00:38] <xnox> ./backend/search.py:315: undefined name 'get_query_for_pkgnames'
[00:38] <xnox> ./backend/search.py:366: undefined name 'time'
[00:38] <xnox> ./backend/search.py:369: undefined name 'time'
[00:38] <xnox> ./backend/search.py:375: undefined name 'log_traceback'
[00:38] <xnox> ./backend/aptdaemon/dbus_service/apt_dbus_service.py:408: undefined name 'Daemon'
[00:38] <xnox> hm....
[00:39] <slangasek> JackYu: does ubuntukylin-default-settings still need an upload sponsored, too?
[00:39] <xnox> slangasek: i see one in rejected.
[00:40] <xnox> slangasek: also did keyring got sorted out?
[00:40] <slangasek> xnox: yes
[00:40] <slangasek> hmm, yes, it is in rejected
[00:40] <JackYu> slangasek, happyaron uploaded 1.1.5
[00:40] <slangasek> who rejected that?
[00:40] <JackYu> oh...
[00:40] <slangasek> ok, I'll look - but am on the way to dinner right now, so it'll be a little bit
[00:41] <xnox> JackYu: that's fine, sometimes reviewers stash things into rejected, which are waiting for some other packages to be uploaded.
[00:42] <JackYu> xnox, sure. lol.
[00:43] <JackYu> slangasek, have dinner first:) I think it's middle night at United States.
[00:43] <xnox> JackYu: usa - west coast is 6 PM =) middle of the night is here in the UK for me - 2AM
[00:48] <JackYu> xnox, :)
[00:49] <xnox> JackYu: please review https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/invalid-syntax/+merge/215325
[00:50] <xnox> JackYu: and please assign / get warnings from https://bugs.launchpad.net/ubuntu-kylin-software-center/+bug/1306313 fixed - i'm not familiar with the code and somebody who understand it better should address those
[00:50] <ubot2> Launchpad bug 1306313 in Ubuntu Kylin Software Center "pyflakes serious warnings" [Undecided,New]
[00:52] <JackYu> xnox, got it. Thanks. We will review it asap.
[04:45] <xnox> i'll poke ubiquity after i wake up =)
[04:59] <JackYu> xnox, good night:)
[05:36] <jamespage> slangasek, uh - yes - I did indeed add the breaks/replaces to the wrong package and I did use the wrong version - apologies
[05:37] <slangasek> jamespage: no worries.  The adjusted version is still waiting in the unapproved queue for a second set of eyes; maybe you'd like to check it over and do some upgrade tests, and if it looks ok I can accept it?
[05:56] <jamespage> slangasek, ack - will do.  Oddly enought I did upgrade test this - does the fact that its only conffiles moving package make a difference?  I def had no problems
[05:57] <jamespage> slangasek, either that or my mind is playing tricks on me
[05:58] <slangasek> jamespage: well, if you happened to get the packages unpacked in the right order, it would've worked even without the Replaces
[05:59] <jamespage> slangasek, the combination with the new conflicts might have done that
[06:06] <jamespage> slangasek, certainly looks right - testing now
[06:21] <slangasek> jamespage: how's the testing?  I'm afraid it's bedtime here
[06:28] <Daviey> alangasek, if this is for neutron.. i don't mind taking over.
[06:28] <Daviey> err, slangasek ^
[07:28] <oSoMoN> hello all
[07:28] <oSoMoN> can I have an ETA on when webbrowser-app will leave the unapproved queue?
[07:29] <jamespage> Daviey, is slangasek is now eod that would be appreciated
[07:34] <Daviey> jamespage: how did the testing go?
[07:35] <jamespage> Daviey, +1
[07:35] <jamespage> Daviey, I tested an upgrade from 0ubuntu1 -> 0ubuntu3 with both the vpn and l3 agents installed; upgraded OK - l3 agent bumped off the install (as expected - I installed the vpn-agent)
[07:37] <Daviey> jamespage: silly question.. but has upgrade from 12.04 been tested? Essex, and UCA versions?
[07:38] <jamespage> Daviey, I've tested the upgrade path via the UCA from folsom->grizzly->havana->icehouse
[07:38] <jamespage> Daviey, upgrading straight from essex is hard as the overall architecture of openstack has changed - specifically neutron (grizzly) and cinder (folsom)
[07:39] <Daviey> jamespage: if it has to be sequential updates is this documented?
[07:39] <jamespage> Daviey, it will be - I'll make sure it gets into the release notes
[07:40] <jamespage> Daviey, technically I think nova is the only bit that needs that - its the only project that has rolled up db migrations
[07:40] <jamespage> Daviey, we can jump other things directly
[07:40] <Daviey> (i can't imagine anyone is still using Essex.. but you never know, right)
[07:40] <jamespage> Daviey, you do never know - I triaged a bug report from a 12.04 user who had tried to go essex->havana the other day
[07:41] <Daviey> oh. ;)
[07:41] <jamespage> Daviey, not in a serious way - they just happened to have nova-common installed from 12.04 at the time
[07:42] <Daviey> That makes more sense.
[08:04] <dbarth> good morning, i'm pinging about the last webbrowser-app upload in the approval queue; we have (sorry) other webbrowser-app fixes stuck in silos after that
[08:05] <dbarth> thanks for your attention if you can rview those this morning
[08:10] <seb128> hey release team ;-)
[08:10] <seb128> xdg-user-dirs and shared-mime-info uploads are translation updates from launchpad (they don't use langpacks)
[08:11] <seb128> those didn't get uploaded yesterday because the DoS/launchpad downtime made I didn't get the exports before my eod
[08:16] <Laney> dbarth: you know we're in final freeze?
[08:16] <Laney> seb128: looking
[08:17] <seb128> Laney, thanks
[08:19] <didrocks> Laney: I guess the goal was to open as soon as we can't get things into the release pocket for seeded packages -updates pocket for things seeded in desktop and touch
[08:20] <didrocks> that's the plan cjwatson discussed about. However, he talked about Monday
[08:20] <didrocks> so unsure for today, but we'll need to find something IMHO
[08:21] <dbarth> Laney, didrocks: let me know if we can still land updates today and next week, or if we need another approach for continuing to accumulate fixes for a potential SRU
[08:22] <didrocks> dbarth: nothing will change from your POV as long as you do bug fixes
[08:22] <dbarth> i totally understand the need to stabilize the distro before the release, just need a direction
[08:22] <dbarth> ok
[08:22] <didrocks> we just need to find which channel it's going to :p
[08:28] <Laney> I don't know how such redirection works so I'm going to leave things like that for now
[08:49] <Daviey> dbarth: erm, why is the source PPA for webbrowser-app showing depwait?
[08:49] <Daviey> Ie, build failure
[08:50] <dbarth> uh, not sure; let me check with oSoMoN
[08:50] <Daviey> Hmm, Arm64, armf,  PowerPC and ppc64
[08:51] <Laney> It doesn't build on those arches
[08:51] <oSoMoN> that’s because oxide itself doesn’t build on those arches
[08:51] <Laney> not armhf
[08:51] <cjwatson> Not armhf.  But yes, that's expected
[08:51] <Daviey> I assumed armf at least was a release goal for this stuff?
[08:51] <Daviey> Oh yes
[08:51] <cjwatson> It only needs to build on the arches listed in "rmadison -s trusty -S webbrowser-app"
[08:52] <dbarth> ah right, that's the same issue as before
[08:53] <Daviey> Right, no worse.  My mistake, should have looked closer.
[08:58] <cjwatson> I think we need to do a block-all in p-m, selectively unblock things that are allowed, and sru-release (or equivalent) anything else
[08:59] <cjwatson> block-all source rather
[09:00] <cjwatson> last time round we did that on 2013-10-15
[09:00] <cjwatson> so this is a bit earlier, but meh
[09:00] <didrocks> block-all source - stuff that are only seeded on touch and for the rest, go on a case by case? (either release or -updates?)
[09:00] <Laney> Could do it for the intersection of touch and <stuff>, or something
[09:00] <didrocks> - being "minus"?
[09:01] <seb128> ^ telepathy-indicator is a small diff that should fix empathy online status in the indicator
[09:01] <cjwatson> I don't have a mechanism for that, but we can do it manually
[09:01] <seb128> would be nice to get in for release
[09:01] <cjwatson> and for that matter the touch release team have unblock hint access
[09:01] <didrocks> cjwatson: the FFe bug for Touch is a good list of things being "seeded in Touch only"
[09:01] <didrocks> I'm happy to unblock on those
[09:01] <seb128> https://code.launchpad.net/~larsu/telepathy-indicator/lp1103438/+merge/215271 is the corresponding merge request
[09:01] <cjwatson> didrocks: there's no code for "block-all except stuff"
[09:01] <didrocks> ah
[09:01] <cjwatson> and I'm not going to write any now
[09:02] <didrocks> so, then, it's only hints
[09:02] <didrocks> from the release team?
[09:02] <cjwatson> "block-all source" applied now, so ~ubuntu-release and ~ubuntu-touch-release should unblock as needed
[09:02] <didrocks> yeah
[09:02] <cjwatson> (in the latter case, for touch-only stuff)
[09:02] <didrocks> so I can unblock all packages that are touch-only
[09:02] <didrocks> listing them
[09:02] <cjwatson> yes
[09:02] <didrocks> one by one
[09:02] <didrocks> ok, I'm using the FFe bug
[09:02] <cjwatson> well, no, unblocks are versioned
[09:02] <cjwatson> stop
[09:02] <didrocks> ah
[09:02] <cjwatson> you have to unblock selected uploads
[09:02] <didrocks> that's going to be really painful
[09:03] <cjwatson> deal with it :)
[09:03] <didrocks> thanks
[09:03] <didrocks> ok, let's say current Touch is finale then
[09:03] <cjwatson> I wouldn't expect it'll take that long
[09:03] <cjwatson> the need for any hints will be obvious in excuses
[09:03] <cjwatson> that's an overreaction
[09:04] <didrocks> well, "deal with it" as well
[09:04] <cjwatson> it's first thing in my morning and I wake up to everyone shouting at me ...
[09:05] <cjwatson> I would suggest that we can continue to unblock touch stuff pretty freely until Tuesday or Wednesday or so
[09:05] <didrocks> cjwatson: I don't think I shouted at you, I just hinted you from that discussion and didn't jump on you on purpose on that one to let you catch up
[09:05] <cjwatson> my point is that it is not really painful to unblock uploads
[09:05] <cjwatson> if you don't want to bother I'm happy to
[09:06] <didrocks> it's still for each package -> I have to check it's seeded only on touch only
[09:06] <cjwatson> (you or your team)
[09:06] <didrocks> then unblock
[09:06] <cjwatson> like I say, if you (plural) don't want to bother I'll do it
[09:06] <cjwatson> it's not a big deal
[09:06] <didrocks> or beg the release team beyond upstream
[09:06] <didrocks> for get things in
[09:06] <didrocks> I would prefer not deal with those and get into -updates if needed
[09:07] <cjwatson> I would prefer not to use -updates until we need to
[09:07] <cjwatson> it's harder to track correctness there
[09:07] <cjwatson> because the only check we have is "valid candidate" in excuses, we won't get the uninstallability check from the output phase
[09:08] <didrocks> ok, that's a valid one if that's not supported by p-m
[09:08] <cjwatson> we have -updates as an escape hatch, and we can use it when things are on both touch and something else and we decide we'd rather not take the risk elsewhere; but it's not a free pass, we don't have as good tools for it
[09:08] <cjwatson> (unfortunately)
[09:08] <cjwatson> using it is going to require extra manual checks
[09:08] <cjwatson> so people shouldn't be labouring under the assumption that it's easier / less work
[09:09] <didrocks> cjwatson: the issue is that the "you" plural is singular most of the time as the only one active on the list would be cyphermox, ogra and I
[09:09] <cjwatson> like I say I have no problem helping out with that
[09:09] <cjwatson> and I'm sure others could as well
[09:10]  * ogra_ finds an old hints branch and sees kenvandine in there too
[09:10] <didrocks> ogra_: yeah, ken isn't active on that though
[09:10] <ogra_> ah, k
[09:10] <ogra_> i just saw he has a file in there
[09:11] <didrocks> cjwatson: well, seeing the amount of work you have to review unapproved already, I'm unsure the RT will have time to deal with it
[09:11] <ogra_> hmpf ... and i seem to never have bzr pulled in that branch
[09:11] <ogra_> what was the upstream url for it again ?
[09:11] <cjwatson> didrocks: based on past experience it's fine
[09:11] <cjwatson> ogra_: lp:~ubuntu-touch-release/britney/hints-ubuntu-touch you mean?
[09:11] <ogra_> thanks !
[09:12] <cjwatson> didrocks: also, generally unblocking can be done at the same time as accepting through unapproved, so it doesn't require thinking about it twice
[09:12] <cjwatson> (IME)
[09:12] <didrocks> cjwatson: so, anyway, seems there is no alternative, so I'll list all with versions
[09:12] <didrocks> one by one
[09:12] <didrocks> cjwatson: I wonder though
[09:13] <didrocks> can't I set unblock <packagename>, then I just amend with a version?
[09:13] <didrocks> or that will make the system bugging?
[09:13] <cjwatson> if you do that right now I believe you'll crash proposed-migration
[09:13] <didrocks> ok
[09:13] <cjwatson> I would like unversioned unblocks to work
[09:13] <didrocks> even commented?
[09:13] <cjwatson> But I'd prefer not to mess with that code a week before release
[09:13] <didrocks> I just want to have the list handy
[09:13] <didrocks> so that I know if it's touch only or not
[09:13] <cjwatson> just keep it in your homedir or in some other file in that branch
[09:13] <cjwatson> proposed-migration only looks at a specific named list of files
[09:13] <didrocks> ok, if you think the parser will be at risk
[09:14] <cjwatson> commented is fine too
[09:14] <didrocks> ok, let me create a file in that branch then
[09:14] <cjwatson> but it'd be clearer for other people if it wasn't in your personal hints file, IMO
[09:14] <didrocks> yeah
[09:14] <didrocks> like touch-only.list
[09:14] <cjwatson> yep
[09:14] <didrocks> ok, doing this
[09:15] <ogra_> i assume i can safely flush the entries from last release from my file in that branch ?
[09:15] <didrocks> ogra_: I did for mine some time ago
[09:15] <Laney> I'm seeing if I can quicly extend generate-freeze-block to come up with this list
[09:15] <didrocks> Laney: well, I think cjwatson's "don't risk production code" before release makes sense
[09:15] <cjwatson> generate-freeze-block isn't production code as such
[09:16] <didrocks> cjwatson: so, for the webbrowser-app one, this will be reviewed as usual and unblock if RT is happy with it?
[09:16] <cjwatson> that would be replacing block-all with a gigantic block that affects the whole archive
[09:16] <cjwatson> or something
[09:16] <cjwatson> ogra_: yes
[09:16] <ogra_> done, thanks
[09:16] <didrocks> but you are not afraid with britney crashing with the gigantic block list?
[09:16] <cjwatson> no
[09:16] <cjwatson> we use gigantic block lists elsewhere
[09:18] <cjwatson> sigh, KDE didn't all clear through automatically so we'll have to unblock that
[09:18]  * cjwatson looks through the ftbfs pile
[09:26] <cjwatson> Laney: thinking about it, I think we only applied block-all last time once we needed the archive to quiesce for release
[09:26] <cjwatson> Laney: so maybe your big freeze block approach would in fact be better for this
[09:27] <cjwatson> not that it isn't helpful for people to remember how to unblock stuff, but :)
[09:32] <Laney> cjwatson: Yeah, I think so
[09:33] <Laney> Trying to get the logic right
[09:33] <didrocks> Laney: if you need any help from me, I'm happy to check with you
[09:33] <Laney> I'll share a list when I get one that I think is right
[09:34] <didrocks> ok
[09:34] <cjwatson> It would certainly be nicer to do less work even if it's not too hard :)
[09:39] <didrocks> cjwatson: Laney: seems there is again 2 new MPs for webbrowser-app coming which are the same kind of fixes than the one in UNAPPROVED. So that you don't have to review the same package 3 times as upstream planned at first, I asked them to get that in one landing
[09:40] <didrocks> so I'm kicking out the current version in UNAPPROVED
[09:40] <cjwatson> mkay
[09:41] <cjwatson> didrocks: do you know if qtcreator-plugin-remotelinux got prenewed?
[09:41] <didrocks> cjwatson: yeah, I did that
[09:41] <Laney> http://paste.ubuntu.com/7234140/ ?
[09:41] <didrocks> (some worth and back and checked that my concerns were fixed in latest versions)
[09:41] <Laney> Packages which are on touch and some other image
[09:41] <Laney> Hopefully
[09:41] <didrocks> Laney: looking
[09:42] <cjwatson> Laney: for actually putting this in p-m, don't we need the list of all packages on any image other than touch?
[09:43] <Laney> Depends what you want to block, I guess
[09:43] <didrocks> Laney: so, you are also dealing with build-deps from what I see, right? (like autopilot)
[09:44] <Laney> hrm, how did that get in there?
[09:45] <Laney> It's not there when I run it again ...
[09:45] <didrocks> *magic*
[09:45] <didrocks> lxc-android-config?
[09:45] <didrocks> that looks weird
[09:45] <Laney> oh
[09:46] <cjwatson> didrocks: yeah, looks ok, accepted (q-p-r)
[09:46] <Laney> that's because I forgot the flag when I ran this
[09:46] <Laney> http://paste.ubuntu.com/7234167/
[09:47] <cjwatson> so, yeah, last time round we apparently didn't block anything for final freeze, only in the unseeded freeze right at the end
[09:47] <Laney> so I was thinking the idea was to let touchies carry on as normal ish, blocking their shared things in proposed so that they can be considered as discussed earlier
[09:47] <didrocks> cjwatson: thanks!
[09:48] <cjwatson> it wasn't what I was initially thinking, but it makes sense
[09:48] <Laney> for everything else use the unapproved queue
[09:48] <Laney> then use the block-all source instead at T-2 days as for Saucy
[09:48] <cjwatson> yep, bit confusing but I can deal with that
[09:49] <Laney> Might be worth a mail
[09:50] <didrocks> Laney: this list is what is seeded on touch and desktop it seems?
[09:50] <didrocks> not things that are seeded on any flavor (but Touch only)?
[09:51] <didrocks> like I would have except to see some unity-lens-*
[09:51] <didrocks> or gnome-*
[09:51] <Laney> right
[09:51] <Laney> it's shared touch and other things components
[09:52] <didrocks> ok, and so, desktop-only will be blocked by something else?
[09:52] <didrocks> (taking ubuntu desktop as an example)
[09:52] <darkxst> Laney, I would rather the touchies didnt touch anything on our image now, given it won't be tested before upload
[09:52] <Laney> unapproved
[09:52] <Laney> darkxst: this block catches that
[09:53] <Laney> but really it's mainly about the CI train stuff
[09:53] <Laney> Qt possibly to a lesser extent
[09:53] <darkxst> Laney, there is stuff in that list seeded on our images
[09:54] <cjwatson> darkxst: this is a list to block, not a list to allow
[09:54] <Laney> darkxst: that's good, it's the list of things that will get blocked
[09:54] <darkxst> ah, ok
[09:54] <didrocks> but the unapproved -> autoaccept already had the interesect of Touch + any other flavor?
[09:54] <didrocks> intersect*
[09:54]  * didrocks is probably silly, but doesn't understand
[09:55] <cjwatson> auto-accept is: not in a package set, not listed in seeded-in-ubuntu other than ubuntu-touch
[09:55] <didrocks> unapproved -> autoaccept was for Touch-only
[09:55] <didrocks> yeah
[09:55] <Noskcaj> Is it ok for me to make a upload of parole for a missing recommends? It fixes a high importance bug, and xubuntu (where it's seeded) approves the change
[09:55] <cjwatson> didrocks: I think the idea is that this allows people to accept touch-related stuff (touch-only or not) into -proposed without having to carefully check whether it affects desktop
[09:56] <cjwatson> didrocks: and then anything that isn't touch-only out of that, we can have in -proposed in a place where we can then move it to -updates if we need to
[09:56] <cjwatson> Noskcaj: sounds fine
[09:56] <didrocks> cjwatson: ok, this makes sense to me
[09:56] <cjwatson> it's a bit twisty
[09:56] <cjwatson> but I think it ultimately makes sense
[09:56] <didrocks> right, I get it now
[09:56] <Laney> I think so, if it turns out not to in practice then it's only a text file to edit
[09:57] <Laney> the volume should be low at this point anyway :)
[09:57] <didrocks> Laney: the list looks to be the right one to me :)
[09:57] <didrocks> Laney: *if* only
[09:57] <Laney> mini troll, sorry
[09:57] <Laney> that Friday feeling
[09:58] <didrocks> heh ;)
[09:58] <didrocks> seems that some people committed still to features and so, features + stabilization is expected
[09:58] <didrocks> (sure, so easy)
[09:58] <didrocks> but that's out of my hands as you know…
[09:59] <didrocks> Laney: thanks for building that list, after a second look, nothing bleeds through my eyes
[09:59] <didrocks> (I thought we stopped shipping zg though=
[09:59]  * didrocks checks
[10:00] <Laney> It'll be interesting when it comes to trying to release a product on such a fast moving base (especially if the base of that is a development release)
[10:00] <Laney> 'bleeds through my eyes' sounds funny to me - is that a translation of a French expression?
[10:00] <didrocks> Laney: yeah, you know how French rules to directly translate expressions :p
[10:01] <didrocks> Laney: and +1 on the "it will be interesting" :p
[10:01] <didrocks> we still (ship zg-core in touch oh my)
[10:02] <Laney> ok, updated hint pushed
[10:02] <cjwatson> cool, thanks
[10:03] <didrocks> thanks!
[10:04] <cjwatson> I'm working on clearing out component-mismatches, BTW, it's just fairly slow going
[10:05] <cjwatson> lots of checking ...
[10:05] <cjwatson> NBS is clear at last
[10:15] <Laney> what's happening with icedtea-web?
[10:20] <didrocks> oSoMoN: you do have a FFe for https://code.launchpad.net/~michael-sheldon/webbrowser-app/file-upload/+merge/212605?
[10:20] <didrocks> (I saw you approved it)
[10:21] <didrocks> as webbrowser-app is not seeded by Touch-only, it's not in the blanket Touch FFe
[10:25] <oSoMoN> didrocks, I don’t
[10:25] <oSoMoN> didrocks, can you point me to a template FFe so I can file one?
[10:29] <sil2100> Hi release team! There's a low-risk packaging fix upload of libaccounts-qt in -proposed - it fixes a packaging conflict - could anyone push it further to the archive?
[10:29] <Laney> I'm going to be polling excuses for blocked packages and I expect others will too
[10:30] <didrocks> oSoMoN: https://wiki.ubuntu.com/FreezeExceptionProcess
[10:30] <oSoMoN> didrocks, thanks
[10:30] <didrocks> yw
[10:32] <didrocks> sil2100: Mirv: we need this FFe to ba acked before publishing the webbrowser-app silo ^
[10:33] <sil2100> didrocks: ok, will remember that, let me put up a comment
[10:33] <sil2100> Laney: thanks o/
[10:38] <Mirv> right
[10:41] <infinity> So, looks like mochikit still needs an MIR, or python3-paste needs neutering?
[10:41] <infinity> Everything else wanting main promotion looks like fallout from bugs or FTBFS packages.
[10:43] <oSoMoN> didrocks, here goes the FFe: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528 , let me know if additional information is required
[10:43] <ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New]
[10:45] <sil2100> oSoMoN: adding it to the landing
[10:46] <oSoMoN> didrocks, oh wait, I just realized that this MR (file-upload) introduces a runtime dep that’s in universe: qtdeclarative5-ubuntu-content0.1
[10:47] <didrocks> oSoMoN: yeah, you're going to fix/amend this?
[10:48] <oSoMoN> didrocks, well I’m not really sure how to fix that, I would have expected qtdeclarative5-ubuntu-content0.1 to be in main… :/
[10:49] <oSoMoN> I could make it a suggests instead of a direct dep, that would work because on desktop it’s not used and on devices the content hub is guaranteed to be there
[10:49] <didrocks> oSoMoN: that would be better
[10:49] <oSoMoN> but I’d like to get some input from Elleo and Ken as to why it’s not in main
[10:49] <didrocks> oSoMoN: I guess it's too late for a MIR on content-hub
[10:49] <oSoMoN> sounds way too late indeed
[10:50] <didrocks> oSoMoN: maybe prepare both?
[10:50] <didrocks> downgrade to suggest/rebuild
[10:50] <didrocks> ensure it's still fine on desktop without it
[10:51] <oSoMoN> didrocks, another option is to simply remove the dependency from debian/control: since it’s only loaded dynamically at run time and only on devices where the content hub is guaranteed to be installed, it won’t make a difference
[10:52] <oSoMoN> (instead of a suggests which wouldn’t make sense on desktop anyway)
[10:52] <didrocks> oSoMoN: fine with me as well, your pick
[10:52] <oSoMoN> didrocks, I’ll go for that one
[10:52] <didrocks> ok, great, thanks!
[10:55] <didrocks> oSoMoN: while you are doing that, let's see if you get an answer soon on your FFe :)
[10:56] <oSoMoN> didrocks, I
[10:56] <infinity> cjwatson: Want to make some seed vs. demote decision on the 300 new grub binaries?
[10:56] <oSoMoN> didrocks, I’ve pinged Elleo who’s the owner of the branch to do the change, if he doesn’t answer in the next 10 min I’ll branch and submit a MR myself, to speed things up
[10:57] <cjwatson> infinity: yeah, I was going to seed those
[10:57] <cjwatson> somewhere
[10:57] <cjwatson> I'll do it after coffee :)
[11:01] <infinity> cjwatson: Oh, err, you're not doing overrides right now, are you?
[11:01] <infinity> (Before I hit enter on this gtk-sharp and jquery* demotion and double-override the world...)
[11:02]  * infinity takes the selince as a no.
[11:03] <cjwatson> infinity: not right now
[11:08] <oSoMoN> didrocks, Elleo acked the request, he’s working on the change as we speak
[11:08] <didrocks> grea t;)
[11:09] <infinity> Alright, knocked out maybe 10 or 15 lines from c-m, time for breakfast while that settles.
[11:11] <seb128> Laney, ^ unity
[11:11] <Laney> I see it
[11:11] <seb128> ;-)
[11:19] <seb128> Laney, thanks ;-)
[11:20] <Laney> yw
[11:52] <Daviey> infinity: Hey, do you have a view on bug 1305839?
[11:52] <ubot2> Launchpad bug 1305839 in maas (Ubuntu) "FFe: Support for Third Party Driver Installation" [Critical,New] https://launchpad.net/bugs/1305839
[11:53] <Daviey> infinity: did you 'unofficially approved the FFe'?
[11:57] <oSoMoN> didrocks, dependency issue fixed for the file-upload branch of webbrowser-app
[11:57] <didrocks> oSoMoN: great, keep us posted on the FFe status!
[11:59] <oSoMoN> didrocks, it hasn’t been updated yet, who can I ping to get it reviewed?
[11:59] <didrocks> oSoMoN: normally, the release team pick up the FFe list. I think enough of them are in the channel to notice that discussion, or you can click on the team you subscribe and try to ping them :)
[12:00] <oSoMoN> nah, I’ll trust we’ve made enough noise in this channel already :)
[12:05] <infinity> Daviey: Not in so many words, no.  I told them the reasons why I would flat our reject the upload (FFe or not), and they went and tried to fix those.
[12:05] <infinity> s/our/out/
[12:08]  * cjwatson does a few more bits of c-m
[12:08] <Daviey> infinity: Hmm, Well. I guess as you had a prior discussion - can you follow up? I added my thoughts to the bug.
[12:10] <infinity> Daviey: I followed up to the bug to clear up the invocation of my name.  If they can test the everliving crap out of it, I'm perhaps inclined to let them slip it in, but yeah, 1.5mo after FF is probably not the time for features. :P
[12:10] <infinity> cjwatson: I'll keep my fingers out for a bit, then.
[12:13] <cjwatson> done for now, will let that settle
[12:19] <knome> hey release team! i'm personally unaware of how the process goes, but we have made a change in the xubuntu seed (dropping ibus to avoid 1284635 for now) and it's ready in the branch; should i just file a 'regular' sponsorship bug to get it in, and also, do you approve this change under the final freeze?
[12:19] <knome> (process being process with seed changes, and more exactly, if we need any special ACK's)
[12:23] <cjwatson> yes and yes
[12:23] <knome> ok, will get that done, and thanks
[12:23] <cjwatson> except that somebody already uploaded xubuntu-meta for that
[12:24] <knome> oh!
[12:24] <cjwatson> https://launchpad.net/ubuntu/+source/xubuntu-meta/2.180
[12:24] <knome> hmm, weird, it's not showing on today's ISO..
[12:24] <knome> maybe it'll propagate down tomorrow
[12:25] <knome> that was quick and smooth
[12:25] <cjwatson> you sure?  http://cdimage.ubuntu.com/xubuntu/daily-live/pending/trusty-desktop-amd64.manifest shows xubuntu-desktop 2.180
[12:25] <cjwatson> but ibus is there for some other reason
[12:26] <knome> elfy, ^
[12:26] <knome> harumpf.
[12:26] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.trusty/desktop shows recommends from unity-settings-daemon
[12:26] <knome> i guess we need to look at that then..
[12:26] <knome> why do we even ship something like that
[12:27] <cjwatson> follow the dependencies/recommendations back ...
[12:27] <knome> yeah, will have to look at that
[12:27] <knome> thanks for the pointer
[12:27] <infinity> Hrm.
[12:28] <knome> gnome-bluetooth, hmm..
[12:28] <infinity> That alacarte upload in the queue... Doesn't that leading debian/control newline come from a broken gnome-tools (or whatever) version, and cause issues with some other parsers?
[12:28] <knome> wondering if that should really recommend unity-control-center
[12:28] <cjwatson> it's an alternate dependency
[12:29] <cjwatson> you could try seeding gnome-control-center instead?
[12:29] <cjwatson> though I see you don't have that right now
[12:29] <knome> hmph, will have to look at the dependencies of that...
[12:29] <cjwatson> you probably want to run germinate locally for this kind of thing
[12:29] <knome> yes yes :)
[12:40] <knome> cjwatson, would it sound completely insane to mark xfce4-settings-manager as another alternative?
[12:42] <cjwatson> knome: I don't have enough experience around there to know
[12:45] <ochosi> cjwatson: i've got a proposal for this problem
[12:45] <knome> huzzah
[12:45] <ochosi> we could hide the menuitem "bluetooth settings..." in xubuntu and put xfce4-settings-manager as an alternative depends
[12:45] <ochosi> thing is: xfce doesn't have a separate bluetooth settings dialog anyway
[12:46] <cjwatson> I don't have any more thoughts to offer on this; I wouldn't be able to review such a change
[12:46] <ochosi> but the indicator offers all the core functionality
[12:46] <ochosi> cjwatson: hm, who would? larsu?
[12:46] <cjwatson> I don't know
[12:46] <cjwatson> Sorry, I'm really not a desktop hacker :)
[12:47] <ochosi> ok, np, i'll ask around ;)
[12:47] <cjwatson> I was just looking at the raw dependency structure
[12:47] <knome> thanks cjwatson :)
[12:48] <cjwatson> infinity: ^- re discussion yesterday.  we'll need to bump ubiquity to include that
[12:51] <infinity> xnox: You pulled the trigger on that d-i upload a little too quickly, keener. :P
[12:52] <cjwatson> infinity: that was me ... why was it too quick?
[12:53] <xnox> infinity: i didn't upload anything =)
[12:53] <cjwatson> oh, I suppose it will want to have the new grub2-signed in it
[12:53] <infinity> Oh, it was Colin who uploaded. :P
[12:53] <infinity> cjwatson: And yeah, grub2-signed.
[12:53] <cjwatson> I thought you were referring to partman-auto, which isn't in the initrd.
[12:54] <xnox> infinity: and i still need d-i with that kernel to test the updated block-devices udeb. to make sure it works on the hardware it is suppose to enable.
[12:54] <infinity> I think it might be time to re-examine my goal of adding (= ver) depends to debian-install-udebs.
[12:54] <infinity> Just hard block migration until it's definitely in sync.
[12:54] <infinity> installer*
[12:54] <cjwatson> Probably won't help with grub2-signed.
[12:54] <infinity> xnox: Right, I'll get it built as soon as grub2-signed settles.
[12:54] <cjwatson> We'd need proper Built-Using support for that.
[12:55] <infinity> cjwatson: Oh, does it not get it from the udeb?
[12:55] <cjwatson> What udeb?
[12:55] <infinity> Right. :P
[12:55] <infinity> Is that perhaps a mistake?
[12:55] <cjwatson> It's used quite differently from normal udebs.
[12:56] <infinity> Fetching from the archive EFI location (and thus relying on the archive layout) seems wrong.
[12:56] <cjwatson> d-i doesn't fetch from there, grub2-signed does.
[12:57] <cjwatson> Oh, hey, it does.  I wonder why I did that.
[12:57] <cjwatson> Maybe it was to avoid yet another archive cycle ...
[12:57] <cjwatson> So I'm not sure d-i needs to wait for grub2-signed at all
[12:58] <infinity> Yeah, you're probably right, now that I've thought it through.
[12:58] <cjwatson> If we were going to change that, B-Ding on grub-efi-amd64-signed would make more sense than adding a udeb, I think, but that has extra settle-time problems.
[12:58] <cjwatson> We do B-D on shim-signed; that changes less often though
[12:58] <cjwatson> Dunno
[12:59] <infinity> But also guarantees consistency, if done right.
[12:59] <infinity> But meh.
[12:59] <infinity> What we have works, it just seems hackish.
[12:59]  * cjwatson does some more c-m
[12:59] <cjwatson> Yeah
[13:01] <seb128> could somebody britney unblock unity?
[13:02] <seb128> why do we have britney blocks during the freeze? if things are approved from unapproved they should probably be good to get in?
[13:03] <Laney> It was discussed earlier - things will be unblocked as appropriate
[13:03] <cjwatson> so that we can let overlapping touch/desktop stuff into -proposed and aim it at -updates rather than release if we need to
[13:03] <cjwatson> it's only for the overlap
[13:03] <cjwatson> though I don't know why unity is in that overlap
[13:04] <Laney> unity-services binary package
[13:04] <cjwatson> ah
[13:04] <Laney> I unblocked unity now anyhow
[13:06] <seb128> cjwatson, Laney: thanks
[13:07] <cjwatson> another batch of c-m done, letting it settle again
[13:09] <infinity> doko: Are you going to fix gnat on powerpc?
[13:16] <infinity> Err, wha?  That mochikit thing shouldn't be happening.
[13:17] <infinity> Oh, derp.  py3-paste was promoted this cycle, and the Rec->Sug drop only happened on py-paste.
[13:17]  * infinity fixes.
[13:17] <seb128> would http://paste.ubuntu.com/7234846/ be an acceptable ubiquity change to land for release?
[13:18] <seb128> see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1306598
[13:18] <ubot2> Launchpad bug 1306598 in ubiquity (Ubuntu) "Handle better missing indicators" [Undecided,New]
[13:18] <seb128> basically make place to get https://code.launchpad.net/~ted/indicator-keyboard/startup-cleanup/+merge/207768 landing as a SRU maybe later
[13:18] <seb128> (we missed to switch that indicator to upstart job and we might want to fix in a SRU since we are past the freeze)
[13:18] <cjwatson> looks ok to me
[13:19] <cjwatson> we have another ubiquity landing coming up for the partman-auto change - I'll include that
[13:23] <infinity> ^-- That clears up the only legitimate universe->main promotion on c-m.
[13:23] <cjwatson> seb128: well, except that's wrong, i isn't the full path
[13:23] <cjwatson> I'll fix it
[13:24] <seb128> cjwatson, oh, didrocks was about to mp his change
[13:24] <didrocks> doing it
[13:24] <didrocks> sorry
[13:25] <cjwatson> didrocks: I was just going to commit it directly, unless you've already done it
[13:25] <xnox> cjwatson: kylin downloads on ubuntu.com should point at http://cdimage.ubuntu.com/ubuntukylin/releases/14.04/release/ubuntukylin-14.04-desktop-i386.iso for final release?
[13:26] <cjwatson> xnox: er, sounds right but I haven't double-checked, check 13.10 and substitute?
[13:26] <xnox> cjwatson: is http://china-images.ubuntu.com/releases/ - a deprecated location? (hosted only Ubuntu Chinese)
[13:26] <didrocks> cjwatson: ah ok
[13:26] <cjwatson> xnox: yes
[13:26] <didrocks> cjwatson: please go ahead then
[13:26] <seb128> cjwatson, what about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1306604 ?
[13:26] <ubot2> Launchpad bug 1306604 in ubiquity (Ubuntu) "ubiquity-dm is missing the power indicator" [Undecided,New]
[13:26] <seb128> cjwatson, adding indicator-power/indicator-power-service to that list
[13:26] <xnox> cjwatson: right, that's what i did. so yeah if it looks roughly correct - that's good.
[13:29] <cjwatson> xnox: any reason I shouldn't add indicator-power-service, that you know of?
[13:31] <xnox> cjwatson: probably got lost when indicators transitioned to use profiles. As long as it declares ubiquity profile in /usr/share/unity/indicators/com.canonical.indicator.power it should be loaded.
[13:31] <xnox> cjwatson: and added in ubiquity for loading.
[13:31] <cjwatson> $ grep -i ubiquity /usr/share/unity/indicators/com.canonical.indicator.power
[13:31] <cjwatson> $
[13:31] <cjwatson> so that would have to be fixed first?
[13:32] <infinity> cjwatson: Do you still need your 18G of crap on am1?
[13:32] <cjwatson> infinity: probably not, I'll clear it out shortly
[13:32] <infinity> cjwatson: Ta.
[13:32] <seb128> cjwatson, xnox: I can get a landed up for the ubiquity profile
[13:32] <cjwatson> I might keep the 7.8->7.6 bootstrap one of those trees, for future reference
[13:33] <seb128> landed -> landing
[13:33] <cjwatson> seb128: adding a task for that then
[13:33] <seb128> cjwatson, thanks
[13:37] <xnox> cjwatson: so if ubiquity profile is not declared, upon trying to launch/load indicator it will just exit. Once the profile has landed, it would start loading. So this can be fixed in any order.
[13:38] <cjwatson> ah.  let me just try running this here ...
[13:38] <cjwatson> actually, I think I'd be more comfortable if we could test that the power indicator comes up before including that code in ubiquity
[13:40] <xnox> cjwatson: ack.
[13:40] <xnox> cjwatson: do you want me to do this?
[13:40] <cjwatson> sure, if seb128 isn't already on it
[13:40] <cjwatson> I want to upload what I have in ubiquity though, we can do this separately
[13:40] <seb128> I'm on adding the profile to the indicator
[13:40] <seb128> not on changing ubiquity
[13:41] <xnox> seb128: ok. please point me to the indicator profile branch/commit/patch
[13:41] <seb128> what would happen if we had the indicator to the list without having a profile? error? or just no indicator?
[13:41] <xnox> seb128: "<cjwatson> actually, I think I'd be more comfortable if we could test that the power indicator comes up before including that code in ubiquity"
[13:41] <cjwatson> I dunno, if y'all really think it's safe then I can stick it in this upload
[13:41] <cjwatson> it would just be easier to test the other way round
[13:42] <xnox> seb128: so point me to profile, i'll apply it locally and will patch ubiquity locally, test it. and then land ubiquity after indicator lands, and this way it will be all tested before uploading anything.
[13:42] <cjwatson> ok, uploading ubiquity without that now then
[13:43] <cjwatson> seb128: I didn't know for sure which is why I was reticent :)
[13:43] <xnox> seb128: you gonna use desktop_greeter mode for ubiquity? we have been mostly recycling that for ubiquity profile.
[13:43] <seb128> xnox, I was going to use "desktop", do you prefer the greeter?
[13:43] <seb128> xnox, desktop have entry points to the settings panel for configuration
[13:45] <xnox> seb128: hm, let me logout and compare the two. I don't think we want configuration ui to be exposed in ubiquity-dm. people can laucnh "try ubuntu" to get "full" experience.
[13:45] <seb128> xnox, ok, let me use the greeter one then
[13:45] <xnox> seb128: yeah the greeter one is better - just the power level indicator.
[13:58] <oSoMoN> Hi gentle release team, any chance someone could have a look at this FFe (bug #1306528) and give me some feedback?
[13:58] <ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New] https://launchpad.net/bugs/1306528
[14:04] <knome> infinity, heyyy... what about release notes, where do we put those, do we still do flavor-specific subpages?
[14:09] <infinity> knome: I'd prefer single-page, with flavours just having their own sections in the notes.  Most of you probably only have a few bullet points to list on top of the Ubuntu generic ones.
[14:09] <infinity> (new XFCE version, bug X in GNOME, edubuntu now ships actual children with every CD, etc)
[14:10] <knome> http://pad.ubuntu.com/Xubuntu1404Final has our stuff for notes (scroll to bottom)
[14:10] <knome> but we could probably cut that down a bit if it was for single notes page
[14:11] <infinity> knome: Yeah, that seems reasonable (and perhaps cut down a tad) to stuff in a Xubuntu subsection of the primary page.
[14:11] <knome> i understand the pros to both ways of doing it... for xubuntu users, i think a separate subpage is clearer, because we can only show stuff that affects our users most (and can strip off some of the stuff from the main page, and link to it), otoh, i can see why a generic release note pages would be better
[14:12] <knome> i guess my only worry about a shared page is that stuff will get lost easier... users are already having "problems" reading the release notes
[14:12] <infinity> knome: The obvious pro to the single page approach is not having everyone's release notes duplicate most of the content.
[14:12] <infinity> knome: Wait, you have users that actually read the release notes? :)
[14:12] <darkxst> knome, why not have your super glorious release notes page linked from the generic sub-page!
[14:13] <knome> infinity, yeah, that's what i'm saying ;)
[14:13]  * darkxst is pretty certain our users don't read them
[14:13] <knome> making it a TL;DR page for most developers as well probably doesn't help the cause
[14:13] <infinity> So, for Saucy, it looks like we just linked to external notes for everyone.
[14:13] <knome> hmph,
[14:14] <knome> here's what i think
[14:14] <infinity> I'm okay with that, too.  Just not with the duplication of data.
[14:14] <knome> we could make the regular release note page better
[14:14] <knome> eg. improve the "table of contents"
[14:14] <infinity> https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes/Xubuntu was nice and Xubuntu-specific, without any generic stuff, and the generic page linked to it.
[14:14] <knome> add some semi-graphical element to it
[14:15] <knome> the current table of contents is pretty baffling..
[14:15] <knome> and i guess i have slight problems having the new features and known issues separated and pulled so long apart
[14:15] <knome> it's much harder to get an overview of the xubuntu stuff
[14:16] <knome> (ok, granted, the release announcement should do that)
[14:16] <infinity> Oh, wow, people have actually inserted content in the release notes.
[14:16] <infinity> Look at that.
[14:17] <darkxst> infinity, I did hear a rumour our docs team work working on something!
[14:18] <infinity> knome: Would it perhaps make more sense to add "5. Flavours" to the TOC, and have new Xubuntu features and Xubuntu known issues be subcategories of that, so they're closer together?
[14:18] <knome> infinity, yeah, that would probably be saner
[14:18] <knome> infinity, what do you think of a more "graphical" toc somewhere?
[14:18] <knome> let me dig up an example...
[14:18] <infinity> Though, half the "generic" known issues also apply to everyone.
[14:18] <infinity> So, I dunno.  Maybe it makes more sense the way it is right now.
[14:19] <knome> https://wiki.ubuntu.com/Xubuntu/Processes#Release_Cycle
[14:19] <knome> something like that?
[14:19] <infinity> It is a bit long, though, I agree.
[14:19] <knome> i don't know...
[14:19] <knome> it would help to cut it in smaller pieces with something else than just text headers..
[14:20] <infinity> knome: So, like, if the "known issues" section had a header that listed "General | Ubuntu Desktop | Ubuntu Server | Xubuntu | Edubuntu | Confubuntu | Etc"?
[14:21] <knome> yeah.. or a header that lists the general subsections and then another that lists flavors
[14:21] <infinity> I wouldn't be against someone doing that to the page. :)
[14:21] <knome> something that makes the notes actually more "navigateable"
[14:21] <infinity> Anything to make it prettier and more navigable is fine by me, really.
[14:22] <knome> currently it's a wall of top-down text, take it or leave it
[14:22] <knome> ok, i'll look into improving that in a sandbox page and then ping back to you
[14:22] <infinity> But the more I look at it, the more I think "features" and "issues" should be separate sections, as they are now.
[14:23] <infinity> If you care about issues, you'll look.  And if you look, you're as interested in "general" as you are in "lubuntu".
[14:23] <darkxst> and for maybe 80% issues are shared amongst all flavours!
[14:23] <infinity> Probably more interested in general, really, since those are the really scary ones (kernel sets you mouse on fire, mouse runs around installing Fedora in protest", etc.
[14:23] <infinity> )
[14:24] <knome> hah
[14:24] <darkxst> infinity, really? best I had was dog taking mouse...
[14:24] <knome> maybe some internavigation links between xubuntu issues and features then
[14:25] <infinity> knome: That might do.  Or even every feature subheading could just have a quick link to "also see known issues" that goes to the top of the issues anchor.
[14:25] <infinity> knome: So, I go check on cool new stuff in Ubuntu GNOME, and then see "hrm, maybe I should check out bugs", and zoom, there I am.
[14:26] <knome> yep
[14:26] <knome> but that leads to the question
[14:26] <knome> is there any reason why the ubuntu gnome stuff can't be at one place
[14:26] <knome> and then just have a link to general bugs?
[14:26] <infinity> knome: Anyhow, documentation and navigation thereof are really not my forte.  I welcome any improvement to the current state of affairs, just really want to try to avoid a twisty maze of interdependent pages, if we can avoid it.
[14:26] <knome> ...and that leads to the question that would it be just sane to keep what we have now, because that would help keep the main notes page from being a wall of text
[14:27] <knome> the current stuff isn't too bad... the xubuntu subpage only do one include
[14:27] <knome> as long as the main page can keep relatively clean, we wouldn't need more
[14:27] <infinity> knome: If by "what we have now", you mean "the Saucy method, of a general page, and links to subpages with only flavour-specific stuff", I'm not sure that was terrible.  But it wasn't ideal.
[14:28] <jdstrand> I'm testing a fix for bug #1306560 (and bug #1298021)
[14:28] <ubot2> Launchpad bug 1306560 in lightdm (Ubuntu) "Oxide-based containers don't work in the guest session" [High,In progress] https://launchpad.net/bugs/1306560
[14:28] <ubot2> Launchpad bug 1298021 in lightdm (Ubuntu) "Google Chrome (not chromium) won't start in guest session" [Undecided,In progress] https://launchpad.net/bugs/1298021
[14:28] <jdstrand> it is a simple apparmor profile update in lightdm
[14:28] <jdstrand> ok to upload?
[14:28] <knome> infinity, that, or https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Beta1/Xubuntu
[14:28] <knome> but i'm fine with either...
[14:29] <knome> anyway, i'll look at it and bother my head with it
[14:30] <darkxst> )knome, I am well out of the loop on the docs stuff, but feel free to chat with Ali and the rest of our (ubuntu GNOME) docs/wiki crew
[14:33] <infinity> jdstrand: Yeah.
[14:33] <jdstrand> infinity: thanks!
[14:33] <knome> darkxst, i will look at general stuff, flavors can then adapt
[14:33] <darkxst> knome, maybe the word should be collaborate
[14:35] <knome> darkxst, well there's not much else i can do to set up the basic structure and tell others to use it
[14:35] <darkxst> "adapt" is rather harsh!
[14:35] <knome> what more do you expect me to do then?
[14:36] <darkxst> knome, collaborate!
[14:36] <knome> how?
[14:36] <knome> or, on what?
[14:36] <darkxst> chat with Ali + co, about your whole release not conundrum
[14:37] <darkxst> ^note
[14:37] <knome> they should take part in the discussion here if they have specific requirements
[14:38] <superm1> can we get a respin of mythbuntu?  all 3 of the fixes from yesterday have landed in the archive and want to double confirm them
[14:38] <knome> if i improve it, naturally i will make sure the links are up for every flavor; it would be insane not to do that
[14:38] <knome> i fail to see what else i could do to help other flavors
[14:39] <darkxst> knome, this is getting way off topic for -release, however I don't think that is a good attitude to take
[14:39] <knome> except maybe send a mail to the -release list, which is again something that should be done only after we've actually landing stuff
[14:39] <darkxst> knome, work together with other flavours maybe?
[14:39] <knome> i'll take it to PM.
[14:51] <stgraber> so we are expecting an upload of both LXC and systemd to fix bug 1303649‎
[14:51] <ubot2> Launchpad bug 1303649 in systemd (Ubuntu) "systemd-logind spins in cgmanager_ping_sync()" [High,Confirmed] https://launchpad.net/bugs/1303649
[14:51] <stgraber> hallyn is currently testing a fix
[14:53] <seb128> xnox, cjwatson: ^ indicator-power with ubiquity profile
[14:56] <xnox> seb128: ah, excellent =)
[14:56] <xnox> seb128: will upload ubiquity shortly then.
[15:10] <dbarth> sorry, me again about https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528
[15:10] <ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New]
[15:10] <dbarth> i'd like to see if we should aim for the archive (if you ok) or for -updates instead
[15:10] <dbarth> see my last comment https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528/comments/1
[15:11] <dbarth> explaining that we are adressing a feature parity issue with the previous browser/container
[15:11] <dbarth> let me know
[15:11] <dbarth> (i know you guys are spammed with requests, so sorry again)
[15:11] <bdmurray> infinity / slangasek: can we get some post 14.04 milestones set up? trusty-updates, 14.04.1?
[15:12] <infinity> Yeah.
[15:17] <infinity> bdmurray: Done.  No dates set yet, but we'll sort that soon.
[15:19] <bdmurray> infinity: thanks!
[15:20] <doko> infinity, probably not this weekend (PyCon)
[15:32] <Laney> dbarth: What are the chances you will want to upload this again?
[15:34] <dbarth> Laney: webbroser-app? hmm, we will have other fixes next week i'm sure
[15:35] <dbarth> Laney: but i assume those will go into -updates
[15:35] <dbarth> as to avoid disturbing the final freeze
[15:35] <dbarth> (let me verify what's still in silos)
[15:36] <dbarth> alex-abreu: ping?
[15:38] <dbarth> no more in silos, and but we have 2 bugs, and one whci could be a x-day sru to fix some popup redirections (will be usefull on phone and desktop, but more minor)
[15:38] <dbarth> Laney: hope that helps you judge the request
[15:52] <dbarth> Laney: ahem, as a matter of fact, i'm told that a rebuild is indeed needed, ahem...
[15:52] <dbarth> Laney: so apologies, please don't consider the packages in the queue right now
[15:53] <Laney> nothing's in the queue yet
[15:53]  * dbarth goes hiding now
[15:53] <dbarth> ok
[16:33] <jdstrand> that ^ is the apparmor profile updates I mentioned
[16:33] <jdstrand> (for oxide and google-chrome)
[16:39] <alex-abreu> dbpong
[16:43] <infinity> jdstrand: Looking.
[16:43] <infinity> How is "apt-listchanges" in "core"?  Meh.
[16:43] <infinity> Someone want to look at that one for me?
[16:44] <infinity> stgraber: Shall I trade you for one of your uploads?
[16:46] <stgraber> infinity: sure, you can take lxc
[16:46] <oSoMoN> alex-abreu, I would have written dbong, for an even shorter contraction of "dbarth: pong" :)
[16:47] <alex-abreu> oSoMoN, ahah ... right 1 byte less :)
[16:47] <dbarth> Laney: webbrowser-app packaging issues resolved now FYI, so the FFE is back for your consideration
[16:48] <Laney> I'm replying now
[16:48] <dbarth> ok thanks
[16:49] <dbarth> alex-abreu: noticed youtube also needs the accounts.google.com treatment to be able to upload
[16:50] <alex-abreu> dbarth, ok need a branch now?
[16:50] <dbarth> alex-abreu: will silo on monday, no rush
[16:51] <alex-abreu> ok
[16:55] <infinity> stgraber: Yeah, already was looking at lxc, and then got distracted by some amazing drama.  Back to the review now. :P
[16:57] <Laney> zul: did you manually cherry-pick those tgt patches or something?
[16:58] <zul> Laney:  yeah
[16:59]  * Laney hands zul git format-patch
[17:00] <zul> Laney:  yeah that boo boo was really stupid of me
[17:05] <infinity> Laney: When you were reviewing that, did you happen to notice that the one patch hunk jumped from patching one file to patching a completely different one?  I was going to ask zul wtf was up with that.
[17:05] <infinity> zul: ^
[17:05] <zul> infinity:  i totally applied the patch to the wrong file
[17:06] <infinity> zul: Brilliant.
[17:06] <zul> infinity:  not my finest moment
[17:11] <slangasek> infinity: at what point are we freezing britney, to let us start staging SRUs in -proposed without automigration?
[17:16] <slangasek> xnox: thanks for the plymouth fix!
[17:17] <slangasek> xnox: I notice that bug #1298938 is marked as 'fix committed'; are you planning another upstart upload soon?
[17:17] <ubot2> Launchpad bug 1298938 in upstart (Ubuntu Trusty) "grep: /etc/init/plymouth-shutdown.override: No such file or directory" [Medium,Fix committed] https://launchpad.net/bugs/1298938
[17:19] <xnox> slangasek: it's fix committed in "SRU" speak.
[17:20] <xnox> slangasek: it's in trusty-proposed.
[17:20] <xnox> slangasek: oh, it looks like upstart built halted all buildds =)
[17:20] <slangasek> mm?
[17:21] <xnox> infinity: can you check what's hanging in all of https://launchpad.net/ubuntu/+source/upstart/1.12.1-0ubuntu2 ?
[17:21] <xnox> slangasek: it does not take 3h+ to build upstart.
[17:21] <slangasek> right
[17:21]  * xnox ponders if my new dbus tests have left run-away processes again.
[17:22] <cjwatson> xnox: that would be a plausible cause of this symptom, yes
[17:23] <slangasek> jodh, xnox: erm, bug #1306361 - do we really want *hourly* rotation of log files?
[17:23] <ubot2> Launchpad bug 1306361 in upstart (Ubuntu Trusty) "~/.cache/upstart/ logs are not rotated often enough" [Medium,Fix committed] https://launchpad.net/bugs/1306361
[17:23] <slangasek> AIUI that means we'll have less than a day's worth of logs retained
[17:25] <oSoMoN> Laney, hey, thanks for ack’ing the webbrowser-app FFe, the package is now in the unapproved queue, we’re gonna need someone to accept it
[17:26]  * ScottK suggests that if you think you want hourly rotation, the problem isn't having faster rotation, but the logs being too chatty.
[17:27] <infinity> xnox: I'll have a poke.
[17:28] <infinity> xnox: http://paste.ubuntu.com/7235878/
[17:29] <slangasek> ScottK: yeah, I don't know where this "hourly" has come from
[17:29] <slangasek> I think that's way too frequent
[17:29] <ScottK> Always important to solve the right problem.
[17:30] <infinity> xnox: Same story on other machines.
[17:30] <infinity> xnox: So, uhm, what did you do? :P
[17:31] <infinity> xnox: I'm going to keep one machine in this state in case you want some debugging info from it, and kill the other 5 builds.
[17:32] <infinity> (But I assume this should be readily reproducible locally)
[17:41] <robru> Laney, webbrowser-app FFe uploaded, please accept  https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528
[17:41] <ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,Triaged]
[18:18] <infinity> xnox: Did you disappear on me? :P
[18:19] <ScottK> Caught in a twisty turny maze of bdus tests.
[18:20] <knome> bdus?
[18:20] <jodh> slangasek: ironically, that's the problem with using cron. My first MP for this issue is better in that an admin or each user can modify the rotation period using a .override: http://bazaar.launchpad.net/~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate/revision/1538#debian/user-conf/periodic-logrotate.conf
[18:20] <slangasek> jodh: I don't follow.  What's the problem with using cron?
[18:20] <slangasek> you certainly can do daily rotation instead of hourly with cron, which should be more than sufficient
[18:21] <jodh> slangasek: I mean a cron snippet - the user can't easily change the behaviour.
[18:21] <infinity> I doubt the user would want to change the behaviour if the default was sane.
[18:21] <slangasek> jodh: making it configurable does not address my point
[18:21] <slangasek> which is that hourly rotation is unreasonably frequent
[18:21] <jodh> slangasek: the reason for hourly is to attempt to combat all the "upstart at my 20TB disk" bugs.
[18:22] <infinity> jodh: Just how much space can upstart eat in a day?
[18:22] <slangasek> jodh: that goes to ScottK's point, that if your 20TB disk is full of logs in a day, log rotation is the wrong solution
[18:22] <jodh> slangasek: hourly would work for me, but I'd personally prefer a solution that allowed the period to be changed since a server may have different requirements to a phone :)
[18:23] <xnox> infinity: i think it is my new tests, cause they are testing initctl.
[18:23] <xnox> infinity: killall test_initctl to hopefully succeed the builds
[18:23] <xnox> infinity: and i'll look into fixing the tests
[18:23] <jodh> infinity: not upstart (yet it gets the blame of course), but the apps it's running :)
[18:23] <infinity> xnox: Yeah, not going to do that.
[18:23] <infinity> xnox: I cancelled the builds.
[18:23] <xnox> infinity: thanks!
[18:23] <infinity> xnox: (As I already said)
[18:24] <infinity> xnox: I have one buildd still hung intentionally if you want debugging info, but I assume you can reproduce locally.
[18:24] <xnox> infinity: kill it
[18:24] <slangasek> jodh: a) we don't have user sessions on servers so that's a non-issue, b) on any client, you don't want the logs rotating away that quickly
[18:25] <infinity> Would be a massive power draw on phones to rotate logs hourly too.
[18:25] <infinity> (Or ever, really, truncating would be better)
[18:25] <jodh> infinity: exactly - that's why my original solution allowed a .override to modify the period :)
[18:25] <slangasek> jodh: my previous login session lasted 35 days (hurray for a new and functional laptop) - having any logs from the start of my session rotate off the disk after 8 hours is not reasonable
[18:25] <infinity> jodh: ...
[18:25] <infinity> jodh: The default would still be wrong, even if someone could fix it. :P
[18:26] <slangasek> infinity: not really /massive/, these logs should all be small
[18:26] <infinity> slangasek: Waking up to do log rotation hurts phone-like objects a lot, even if they're small.
[18:26] <jodh> slangasek: I have no problem with you changing it to daily, but will that work reliably for devices that are suspended a lot?
[18:27] <xnox> jodh: yes, cause it would be anacron handled.
[18:27] <jodh> infinity: so disable the job entirely, or specify 'console none' in the noisy jobs
[18:27] <slangasek> infinity: phones wake up more often than once an hour anyway, and the rotation only happens if there's been something logged that needs rotating; so I'm not convinced this has real impact
[18:27] <infinity> jodh: I'm not thinking about what programmers/packagers should do, just about what's sane for a user's device.
[18:27] <slangasek> jodh: yes, as xnox says, anacron handles the jobs on wake-up
[18:27] <xnox> jodh: so "daily" means at most daily, cron still wakes up regularly to kick off daily if it wasn't run.
[18:28] <slangasek> xnox: so shall I push a cron.daily->cron.hourly change to bzr for inclusion in your next upload?
[18:28] <jodh> slangasek: as I say, if you want to change it, I have no problems. But clearly, a single logrotate per session has proven to be inadequate
[18:28] <xnox> slangasek: i'm not planning any more uploads.
[18:28] <slangasek> jodh: right, the "per session" being inadequate is understandable - I log out as little as possible
[18:28] <infinity> xnox: Yes you are.
[18:28] <infinity> xnox: Unless you don't plan to fix your hanging tests...
[18:28] <xnox> infinity: oh right, the dbus tests, yes.
[18:28] <slangasek> xnox: :-)
[18:29] <slangasek> you don't /have/ to upload it, you can pass the buck to me if you prefer :)
[18:29] <slangasek> but I'd appreciate it if you fixed your tests
[18:30] <xnox> slangasek: with dbus test-suite fixes?! =) i'm happy to pass it on to you ;-)
[18:30] <xnox> slangasek: snap.
[18:30] <slangasek> yeah ;)
[18:32] <slangasek> jodh, xnox: fwiw I think we should also have a 'maxage' setting in the logrotate.conf
[18:32] <slangasek> oh, n/m
[18:32] <slangasek> that doesn't help the problem I'm trying to solve
[18:33] <slangasek> (which is, basically, the generic form of bug #1306736)
[18:33] <ubot2> Launchpad bug 1306736 in update-notifier (Ubuntu) "update-notifier upstart job should be silent by default" [Undecided,New] https://launchpad.net/bugs/1306736
[19:03] <sconklin> question: Once freeze hits, is another 'release' made like beta1 and beta2, or are the dailies all that's available? Specifically, will something appear here?: http://uec-images.ubuntu.com/query/trusty/server/released-dl.current.txt
[19:15] <xnox> fixed test_initctl's left around, locally i also see 2 test_job left around, but that was not in infinity's paste. will upload soon.
[19:19] <ScottK> sconklin: The dailies.
[19:19] <sconklin> ScottK: Thanks
[19:34] <infinity> xnox: I don't like the sounds of that...
[19:34] <infinity> xnox: If you have other hanging tests, could those maybe also be fixed? :P
[19:45] <xnox> infinity: well, if i manage to reproduce it yeah.
[20:13] <xnox> infinity: i've rebooted my machine into trusty's upstart and i cannot reproduce the hanging test_job anymore.
[20:14] <infinity> xnox: Fun.  Though, I hope it's not dependent on the *host* upstart somehow, cause that's very much not trusty on the buildds. ;)
[20:15] <xnox> infinity: so i think my unit-test got reparented to pid1, which was broke cgroups enabled one, and that one did not reap/sigcont it. But yeah, our tests are not meant to talk to pid1....
[20:15] <xnox> infinity: yeah, scary, _meh_
[20:16] <infinity> Fun, fun.
[20:16] <infinity> xnox: Well, if the thing I had hanging on my machines is fixed, we're probably good.
[20:18] <xnox> yeah, i did reproduce left around test_initctl processes and those are all cleaned up.
[20:23] <infinity> xnox: Kay, cool.  Gimme, then.
[20:25] <infinity> xnox: Oh, it's in the queue.  Derp.
[20:36] <xnox> infinity: digging deeper, it seems to be caused by launching a chroot build from an upstart user session (which is also cgroups contained by logind/cgmanager) i've raised bug #1306799 for jodh to look into....
[20:36] <ubot2> Launchpad bug 1306799 in upstart (Ubuntu) "test_job hangs" [Undecided,New] https://launchpad.net/bugs/1306799
[20:36] <xnox> infinity: you love user and chroot sessions, don't ya =)
[20:37] <infinity> xnox: Oh, ugh.  You guys never inverted the chroot session default for me, did you? :(
[20:37] <xnox> infinity: you were meant to send a merge proposal, no?!
[20:38] <infinity> Which means all trusty-based buildds need --disable-sessions on the kernel commandline, or they get a useless ringbuffer full of vomit.
[20:38] <infinity> xnox: Thanks, Lennart.
[20:38] <cjwatson> Ouch
[20:38] <infinity> xnox: In the real world, filing bugs is enough. :P
[20:40] <xnox> infinity: well, everyone seemed to disliked my --no-sessions=true idea, so i didn't make a merge proposal.
[20:42] <infinity> xnox: Would it have been so hard to just invert the default and add --enable-sessions?
[20:42]  * infinity sighs.
[20:42] <infinity> Oh well.
[20:42] <infinity> Whatever.
[20:43] <infinity> I thought your bikeshedding about it was you being sarcastic.
[20:56] <xnox> infinity: i am very rarely sarcastic =)
[20:57] <xnox> infinity: it built \o/
[21:02] <doko> In file included from src/mlx5.h:40:0,
[21:02] <doko>                  from src/buf.c:44:
[21:02] <doko> /usr/include/infiniband/arch.h:120:2: error: #warning No architecture specific defines found. Using generic implementation. [-Werror=cpp]
[21:02] <doko>  #warning No architecture specific defines found.  Using generic implementation.
[21:02] <doko>   ^
[21:02] <doko> cc1: all warnings being treated as errors
[21:02] <doko> xnox, ^^^
[21:03] <xnox> doko: and which package is that?
[21:03] <doko> ohh, I thought you were talking about libmlx5 before ...
[21:04] <xnox> doko: nah, upstart.
[21:05] <doko> disabling werror for these architectures
[21:06] <infinity> xnox: Soomething like this is what I had in mind: http://paste.ubuntu.com/7236725/
[21:09] <infinity> doko: I'd just toss out "CFLAGS="$CFLAGS -Werror"" from configure.in .. It wasn't in the previous version of the same driver.
[21:10] <doko> infinity, ok, better
[21:11] <infinity> doko: You doing that, or shall I?
[21:11] <doko> doing
[21:12] <infinity> I already made Chris use dh-autoreconf, so that one-liner should do it, I'd think.
[21:13] <infinity> doko: Try to avoid reading any of the source for this.  It's nightmare-inducing.  I've struggled hard to not waste hours fixing this, and the application it's a driver for. :P
[21:16]  * infinity lunches.
[21:26] <infinity> doko: That seemed to do the trick, thanks.
[21:27] <oSoMoN> hello again, the upload of webbrowser-app corresponding to FFe bug #1306528 is sitting in the unapproved queue, I’d appreciate if someone could accept it
[21:27] <ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,Triaged] https://launchpad.net/bugs/1306528
[21:27] <oSoMoN> thanks!
[21:28] <xnox> infinity: all tests pass, and the change looks good. committed upstream.
[21:29] <infinity> I can haz cherry-pick closing the Ubuntu bug?
[21:34] <olli> hey there, do we have an official RC image yet? would that be the 4/10 or 4/11 one?
[21:35] <xnox> olli: there don't make RC images. there is final beta, and the next released images will be final 14.04 LTS release.
[21:35] <xnox> s/there/we/
[21:35] <bfiller> xnox: can we get the webbrowser-app promoted out of the unapproved queue please?
[21:36] <olli> xnox, ok, I guess he got confused by https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[21:36] <olli> xnox, thx
[21:36] <xnox> bfiller: i'm not release team member.
[21:36] <xnox> olli: it's a milestone, but without published images.
[21:36] <bfiller> xnox: who could do that?
[21:36] <xnox> bfiller: people who are in http://pad.lv/~ubuntu-release
[21:36] <xnox> bfiller: aka Ubuntu Release Team
[21:36] <bfiller> thanks
[21:37] <bfiller> Laney: can we get the webbrowser-app promoted out of the unapproved queue please?
[21:37] <xnox> olli: see https://wiki.ubuntu.com/ReleaseCandidate "During the week leading up to the final release, the images produced are all considered release candidates."
[21:37] <cjwatson> has it been tested on desktop as well as on touch?
[21:37]  * olli goes rtfming
[21:38] <knome> just wondering if it would make sense to mention that the RC doesn't have any specific images on the release notes itself (briefly), since many people have come asking for the images around the channels
[21:38] <cjwatson> I guess we probably want the google calendar change on desktop
[21:38] <bfiller> cjwatson: yes it has
[21:38] <cjwatson> Laney: (stand down)
[21:38] <xnox> olli: it's linkified from the release schedule. each link/milestone/freeze explains what it means in ubuntu. as the terms are very generic.
[21:38] <cjwatson> bfiller,oSoMoN: reviewing, give me a few minutes
[21:38] <olli> xnox, stop rubbing it in ;)
[21:38] <bfiller> cjwatson: great, thanks
[21:39] <oSoMoN> cjwatson, awesome, thanks
[21:40] <xnox> EOW see you on monday =)
[21:41] <cjwatson> bfiller,oSoMoN: not a new problem or anything but for future reference literal "." characters in regexes should be escaped, to avoid matching "mailagoogle.com" or whatever
[21:41] <bfiller> cjwatson: noted
[21:42] <ogra_> oSoMoN, bfiller, i assume that doesnt have the OOM fix yet ?
[21:42] <oSoMoN> cjwatson, good point, I’m making a note to fix that on Monday
[21:42] <cjwatson> ogra_: the changelog says it fixes bug 1306037, which seems relevant
[21:42] <ubot2> Launchpad bug 1306037 in webbrowser-app "[webapp-container] Do not load qtwebkit libs (used as fallback) when they are not needed" [Medium,Triaged] https://launchpad.net/bugs/1306037
[21:42] <ogra_> oh !
[21:42] <ogra_> great
[21:43] <ogra_> the MP hasnt changed
[21:43] <oSoMoN> ogra_, it should address at least partially the issue
[21:43] <ogra_> yeah, we also need the upstart-app-launch change
[21:44] <ogra_> https://code.launchpad.net/~ted/upstart-app-launch/process-group-kill/+merge/215475
[21:44] <ogra_> both together seem to work fine for me
[21:44] <oSoMoN> cool
[21:44] <cjwatson> bfiller,oSoMoN: accepted/unblocked
[21:44] <cjwatson> (since we've had plenty of other desktopy fixes today)
[21:44] <bfiller> cjwatson: great, thank you
[21:45] <oSoMoN> thanks a bunch
[21:46] <ogra_> cjwatson, what are my chances to get the MP above in ? (and why is upstart-app-launch seeded in the desktop ?)
[21:46] <infinity> xnox: Did you review that yourself before applying it, or just trust my angry programming skills? :P
[21:46] <cjwatson> ogra_: well, um, I'm going to bed shortly so probably not my decision :-)
[21:46] <ogra_> (i can alternatively ship an override in lxc-android-config so that it would only affect touch)
[21:47] <ogra_> ah, k
[21:47] <cjwatson> ogra_: I'd actively prefer not to have an override though
[21:47] <ogra_> yeah
[21:47] <infinity> cjwatson: Can you give a quick review of the upstart in the queue?  It's my patch, so I probably shouldn't. :P
[21:47] <ogra_> me too
[21:47] <cjwatson> libupstart-app-launch2 has an rdepends tree that probably ends up in desktop somehow
[21:47] <ogra_> but its my last resort to have the phone usable without affecting desktop
[21:48] <ogra_> in case thats needed
[21:48] <cjwatson> infinity: I think it would be worth finding Laney's codesearch thing and searching for --no-sessions in it
[21:48] <bdmurray> slangasek: could you have a look at update-manager in precise-proposed?
[21:48] <infinity> cjwatson: upstart gracefully ignores unknown options.
[21:49] <cjwatson> ah, hm, ok
[21:49] <infinity>         /* Ignore invalid options */
[21:49] <infinity>         { '-', "--", NULL, NULL, NULL, NULL, NULL },
[21:49] <infinity> cjwatson: If that hadn't been there, I would have left the old option as a no-op.
[21:51] <darkxst> infinity, bug 1300464
[21:51] <ubot2> Launchpad bug 1300464 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Ubuntu GNOME Trusty Slides Update" [Undecided,New] https://launchpad.net/bugs/1300464
[21:52] <infinity> darkxst: Given that the point of UIF is to protect OS changes from affecting documentation like the slideshows, I'm going to go with the slideshow itself not needing a UIFe. ;)
[21:53] <cjwatson> infinity: accepted/unblocked
[21:54] <cjwatson> ogra_: We've evidently had this conversation before (not necessarily you and I, but in general), because upstart-app-launch is explicitly whitelisted for auto-accept, and it isn't part of the freeze block.
[21:54] <cjwatson> ogra_: So any upload should sail in.
[21:54] <ogra_> oh, sweet !
[21:54] <cjwatson> (Presumably because it's present on desktop for linkage reasons but not actually really used much in practice.)
[21:54] <ogra_> thanks ... i could have checked the freeze exception bug
[21:55] <darkxst> infinity, ok, that works for me
[21:55] <cjwatson> I thought the slideshows got screenshotted elsewhere
[21:55] <darkxst> anychance you can upload?
[21:56] <cjwatson> I would say it's probably fine but a note to ubuntu-doc or whatever wouldn't go amiss
[21:56] <cjwatson> Ah, Gunnar signed off already
[21:56] <darkxst> cjwatson, alfredo already sent that
[21:56] <cjwatson> So I guess that's fine
[21:56] <infinity> cjwatson: For Ubuntu, that might be true, I doubt it is for the flavours in any way that they wouldn't already be prepared to take care of or not care about.
[21:57]  * cjwatson nods
[21:57] <infinity> I think what the slideshow needs is a screenshot of a web browser showing the help.ubuntu.com page with a screenshot of the slideshow.
[21:57] <infinity> And no one can ever change anything, ever again.
[21:58] <cjwatson> You just have to construct a quine slideshow
[21:58] <cjwatson> https://github.com/mame/quine-relay
[21:58] <darkxst> infinity, you can keep your help.u.c! we would of course have to use help.gnome.org :)
[21:59] <infinity> cjwatson: I'd very nearly forgotten that horror^wwonder existed.
[22:00] <cjwatson> It has "PLEA SEGIVEUP" buried in the middle of it, which I think says it all
[22:01] <cjwatson> darkxst: Put a screenshot of help.u.c on help.g.o
[22:03] <slangasek> bdmurray: looking
[22:04]  * darkxst can only imagine the shock and horror that would occur if I requested that from my artwork team!
[22:37] <darkxst> infinity, cjwatso, so can one of upload? or should I go begging on -devel?
[22:48] <cjwatson> darkxst: I'm going to bed pretty soon, I'm afraid.
[22:49] <cjwatson> Just waiting to get into the next round of this package bootstrap
[23:22] <bdmurray> slangasek: I've verified bug 1274704 now if we want to expedite the SRU
[23:22] <ubot2> Launchpad bug 1274704 in update-manager (Ubuntu Precise) "apport does not upload apt-clone_system_state.tar.gz (permission denied)" [High,Fix committed] https://launchpad.net/bugs/1274704
[23:22] <slangasek> bdmurray: releasing, thanks