[00:16] <xnox> i wonder if we could squeeze trusty into 700MB limit.
[00:17] <xnox> with qt4 gone, most of python2 gone, and now with ubuntu-meta&empathy uploads gstreamer0.10 would be gone...
[00:27] <infinity> xnox: qt4 is gone?
[00:28] <xnox> infinity: yeah, u1 is gone.
[00:28] <infinity> Oh, that was the only consumer?  Helpful.
[00:29] <xnox> u1 is something like 98MB of qt4, python-qt4, webkit qt4, and python-qt4-webkit
[00:29] <xnox> and ofcourse gstreamer0.10 etc.
[00:29] <infinity> xnox: Which would be aweome if we didn't still have qt5, qt5webkit and oxide-qt. ;)
[00:29] <xnox> infinity: mind reviewing empathy & ubuntu-meta uploads? those should kick out gstreamer0.10
[00:29] <xnox> infinity: one webkit removal at the time, please!
[00:30] <infinity> xnox: Looking.
[00:32] <infinity> xnox: That empathy one looks like a feature freezy thing.
[00:32] <infinity> (Though, I'm not sure I disagree with the rationale, so maybe should JFDI anyway)
[00:32] <infinity> xnox: Is there a reason those account pluging can't be ported to gst1.0?
[00:32] <xnox> infinity: it's not the account plugins, but their dependencies.
[00:33] <xnox> infinity: both of those depends on telepathy-haze, which depend on libpurple0, which is from pidgin and our pidgin is not gstreamer1.0 ported
[00:33] <xnox> infinity: upstream snapshot is, but that's not ready for LTS.
[00:33] <infinity> xnox: Well, we don't need a new upstream version for that if we can cherrypick the API porting bits.  But meh.
[00:34] <xnox> infinity: i work on ubuntu-touch, ubuntu touch doesn't have pidgin =))))))))
[00:34] <infinity> As for bluez-gst, why was it seeded if it's useless?
[00:34] <infinity> xnox: Really, when did you leave Foundations?
[00:34] <xnox> infinity: history, it's going back from before we migrated to using seeds.
[00:35] <xnox> infinity: and cyphermox tested extensively that it doesn't do anything useful or required bluetoothy.
[00:36] <xnox> infinity: Foundations is full force behind making tablet edition this cycle =) then again your team "Continuous Intoxication" should know all about it anyway =)
[00:36] <xnox> or are you back at the dark side?
[00:36] <infinity> xnox: So, did you drop bluez-gstreamer from ubuntu-gnome too?  If it really is a useless thing to install by default, I imagine they also don't want it.
[00:37] <xnox> i just did now.... why don't they share the seed for common stuff....
[00:45] <xnox> infinity: ^ matching ubuntu-gnome
[00:47] <infinity> xnox: Ta.
[02:18] <slangasek> infinity: ^^ perhaps you'd be interested in reviewing these two
[02:19] <slangasek> right, I mean /those/ two ^^ ;)
[02:21] <slangasek> oops, missed a debian/copyright fix on the last one, self-rejecting
[02:35] <infinity> slangasek: I would, but you already did? :P
[02:35] <infinity> slangasek: Oh, unapproved, not new.
[02:35] <slangasek> hmm?
[02:36] <slangasek> nah, somebody else accepted libvpd out of unapproved
[02:36] <infinity> slangasek: Yes, that someone would have been a bot. :)
[02:36] <infinity> (unseeded, etc)
[02:37] <slangasek> ok
[02:37]  * infinity reviews the binaries instead.
[02:37] <slangasek> at last, we have been replaced with very small python scripts
[02:38] <slangasek> we can finally retire
[02:38] <infinity> Weird SONAME.
[02:39] <slangasek> not the all-time weirdest
[02:39] <infinity> No, not by a long shot. :)
[02:40] <infinity> Was just double-checking that the SONAME matches the filenames.
[02:41] <infinity> slangasek: So, that udev rule touches /var/lib/lsvpd/run.vpdupdate, but you don't ship that directory.
[02:41] <slangasek> hah
[02:41]  * slangasek ponders
[02:41] <slangasek> infinity: so if the directory doesn't exist and the udev rule therefore fails, does that do any harm?
[02:42] <infinity> slangasek: Dunno.  But wouldn't it make sense to just ship the dir?
[02:43] <slangasek> because really, the only reason we need that file to exist is if there's some process running that needs to update the db; and whatever needs to update the db /will/ create the directory on its own
[02:43] <slangasek> infinity: maybe, but a) I don't really want to reupload, and b) I'm on to sherry for the evening
[02:44] <infinity> slangasek: The upstream makefile even installs that dir and file on "make install"...
[02:45] <infinity> So, I guess just adding 'var' to the .install file would fix it.
[02:45] <slangasek> sure; but in practice it will be autocreated by the first revdep that actually wants to (and has perms to) create the db
[02:46] <infinity> slangasek: Yeah, and then it won't be removed on package removal, cause it's unowned.  Another fair argument for having it in the package.
[02:46] <slangasek> and it's a runtime lib package, so 'rm -rf /var/lib/lsvpd' is inappropriate, unless we split out a runtime package
[02:46] <infinity> (And, in fact, for shipping the empty file too, not just the dir)
[02:46] <slangasek> hmm
[02:47] <infinity> Though, I guess if a DB ends up in there too, that wouldn't be purged without a postrm.
[02:47] <slangasek> indeed
[02:47] <slangasek> the flag file is used solely to determine when the .db needs refreshed
[02:47] <infinity> Anyhow, I have no idea what the consequences of not shipping the udeb rule's target might be (except possibly log noise), but wouldn't seem to hurt to do so.
[02:47] <slangasek> so short of postrm + splitting out a lib runtime package, I don't think it's worth changing anything
[02:47] <infinity> udev, even.
[02:48] <infinity> Oh, right, the *file* couldn't be owned by it regardless.
[02:48] <infinity> The directory could be, though.
[02:48] <infinity> Which would prevent the udev rule failing.
[02:48] <infinity> So, maybe I'll just reupload with a .dirs file.
[02:49]  * infinity blinks.
[02:49] <slangasek> reasonably certain that RUN failures don't even get logged anywhere, but if you feel strongly enough to reupload, ok
[02:49] <infinity> Is sqlite really public domain?
[02:51] <infinity> Oh, was going license incompat hunting, but this is LGPL anyway, not CPL like half their other stuff.
[02:52] <infinity> slangasek: Also, no symbols file.  Intentional laziness, or just forgot?
[02:52] <infinity> slangasek: (It's something I'll make them do before I sponsor it to Debian anyway :P)
[02:53] <infinity> Although, whee, C++
[02:53] <slangasek> infinity: forgot, and retroactively lazy
[02:54] <happyaron> can you have a look at ubuntukylin-default-settings in queue? well they are waiting for it to generate iso...
[02:54] <slangasek> (best practice of course, but nothing I consider a blocker)
[02:54] <slangasek> happyaron: looking
[02:54] <happyaron> thanks
[03:23] <infinity> That so needed a bug ref..
[03:23] <infinity> Or, wait.  No.  It had one.
[03:23] <infinity> I'm not awake.
[03:25] <maclin> cjwatson，hi，there is a problem of rebuilding state of Ubuntu Kylin on ISO tracker. We cannot rebuild an ISO
[03:25] <maclin> could you help to confirm it?
[03:26] <darkxst> our daily image gained the entire unity-control-center/UOA stack today ;( Bug 1301712
[03:26] <ubot2> Launchpad bug 1301712 in shotwell (Ubuntu) "shotwell is pulling in unity-control-center and UOA on Ubuntu GNOME" [Undecided,New] https://launchpad.net/bugs/1301712
[03:27] <infinity> maclin: What's the problem?  The tracker says you're rebuilding, are you saying that's a lie?
[03:28] <infinity> And indeed, it looks like a lie.
[03:29] <maclin> the rebuilding state has been there for two days. I make  a new  request just now, But it takes no effect.
[03:29] <infinity> maclin: It's taking effect, but the builds are failing.
[03:29] <infinity> slangasek: I thought you fixed the pinyin-android thing?
[03:30] <maclin> infinity, if the build fails, the rebuilding state will be kept on tracker?
[03:31] <infinity> maclin: Yeah.
[03:33] <infinity> Ahh, it might work after the new ubuntukylin-default-settings migrates from proposed.
[03:34] <infinity> darkxst: Hrm.  I'm not even sure why that recommends was added.
[03:34] <maclin> we have uploaded the default-setting to solve the problem. It may hit trusty after a while. Then can I make a new requset on tracker?
[03:34] <infinity> maclin: Yeah.  Should work.  Or your daily build will happen.
[03:35] <infinity> darkxst: I assume from your patch that gnome-online-accounts is functionally equivalent to unity-control-center-signon?
[03:38] <infinity> darkxst: If not, I'd suggest we just drop that recommends entirely, not add to it.
[03:38] <maclin> infinity, thanks. I will try it now:)
[03:39] <infinity> maclin: Now?  It's not in the release pocket yet.
[03:41] <maclin> oh，sorry,  how to check wheather it's ready?
[03:42] <darkxst> infinity, oh actually shotwell doesnt have gnome-online-accounts integration
[03:43] <infinity> (base)adconrad@cthulhu:~$ rmadison ubuntukylin-default-settings | grep trusty
[03:43] <infinity>  ubuntukylin-default-settings | 1.1.1  | trusty/universe          | source, all
[03:43] <infinity>  ubuntukylin-default-settings | 1.1.2  | trusty-proposed/universe | source, all
[03:43] <infinity> maclin: ^
[03:43] <infinity> darkxst: Kay, so probably saner to just demote that recommends to a suggests, I'd say.
[03:44] <infinity> darkxst: Given that it's not a hard dep, I assume it works fine without, and on a full Ubuntu desktop, ubuntu-whatever-signon-thing should be there, so meh.
[03:44] <darkxst> infinity, ok will do that
[03:44] <maclin> thanks infinity, we will wait for it^_^
[03:45] <infinity> darkxst: Except, you'll still have it pulled in via libaccount-plugin-1.0-0, it looks like.
[03:46] <darkxst> that is pretty unavoidable I think
[03:47] <infinity> darkxst: So... Nothing to change here then?
[03:47] <infinity> Oh, wait.  That's a circular dep.
[03:48] <infinity> Probably the only reason libaccount-plugin-1.0-0 is there is because of unity-control-center-signon
[03:48] <infinity> Right, let's try fixing shotwell and see how that pans out. :P
[03:52] <infinity> darkxst: Alright, uploaded that change.  Want to review it in the queue for me so I don't feel guilty about self-accepting? :P
[03:54] <darkxst> infinity, sure, looks good
[04:04] <slangasek> infinity: mm?
[04:04] <slangasek> infinity: I just accepted the ubuntukylin-default-settings, sure; I hadn't fixed it
[04:05] <infinity> slangasek: Right, I thought the discussing of the pinyin removal was leading to you fixing it, I misunderstood. :)
[04:06] <infinity> slangasek: The extra irony, it appears, is that it didn't break because they wanted to have it installed, it broke because they had a hook that tried to forcefully remove it. :P
[04:06] <slangasek> evidently
[04:14] <infinity> BTW, that d-i upload won't build correctly until systemd is built.
[04:22] <stgraber> infinity: d-i upload looks good, feel free to self-accept once systemd is built and published
[06:15] <maclin> infinity, hi, the default-setting package is ready, I request a rebuild again but it takes no effect. I find the crontab but only exist a daily build task for Ubuntu Kylin.
[07:10] <infinity> maclin: Let me kick off a manual build to unstick it.
[07:14] <maclin> infinity, thanks
[07:31] <maclin> infinity, is it suit to request a rebuild now?
[07:32] <infinity> maclin: Well, a rebuild just happened manually, so requesting another wouldn't make much sense.
[07:33] <infinity> ... unless it failed again.
[07:33]  * infinity looks.
[07:34] <maclin> ok, you mean a manual build for ubuntu kylin is working?
[07:34] <infinity> maclin: A manual build just happened and failed.  Digging out the logs now to see why.
[07:38] <infinity> dpkg-query: no packages found matching fonts-thai-tlwg
[07:38] <infinity> maclin: ^-- That's how your build fails.
[07:39] <maclin> ok, we will check it, thanks
[09:08] <maclin> infinity, we analyze the default-setting script and find the problem appears at:  [ `dpkg -l $line | grep -c "^ii"` != 0 ] && apt-get purge --auto-remove -y $line
[09:10] <maclin> the command dpkg -l  will fail when the package not exist. The operation can succeed in our test environment.
[09:11] <maclin> I wonder the building script will fail when any script fail in the process?
[09:11] <cjwatson> It may fail, but unless you're using bash set -o pipefail nothing will care
[09:13] <cjwatson> (which you aren't)
[09:14] <infinity> cjwatson: And yet, their livefs builds fail, so something cares.
[09:14] <cjwatson> Sure
[09:14] <cjwatson> Just saying it doesn't appear to be that
[09:16] <cjwatson> Although I would say that   dpkg -l "$line" | grep -q ^ii && apt-get ...   is more idiomatic shell
[09:16] <cjwatson> Shouldn't be relevant to this though
[09:18] <cjwatson> http://paste.ubuntu.com/7197874/ with a version modified locally to not do anything dangerous to my system - that exits 1
[09:18] <infinity> Also somewhat inefficient to run apt 30 times in a row, instead of "apt-get purge --auto-remove $(dpkg -l $(cat /usr/share/ubuntukylin-default-settings/remove-package.list) | awk '/^i/ {print $2}'" or similar.
[09:19] <infinity> Missing a closing bracket in there, but you get the idea.
[09:19] <cjwatson> So I think set -e trips on "read line" returning false, which is odd given that it's guarded by a while
[09:20] <cjwatson> Or maybe there's a subshell in there and it returns its last exit code
[09:20] <infinity> cjwatson: There is a subshell, yes.  That messed it up, I suspect.
[09:20] <cjwatson> Heh, so this is another case where the idiom we were talking about the other day is better
[09:21] <infinity> Anyhow, doing it all in one dpkg pass and one apt pass would be much saner.
[09:21] <infinity> And would avoid the if entirely.
[09:21] <cjwatson> maclin: Could be improved as discussed above, but http://paste.ubuntu.com/7197888/ is a minimal fix.
[09:23] <maclin> thanks cjwatson and infinity, we will improve the script as above:)
[09:24] <infinity> foo=$(cat test.list)
[09:24] <infinity> bar=$(dpkg -l $foo | awk '/^i/ {print $2}')
[09:24] <infinity> apt-get purge --auto-remove $bar
[09:24] <infinity> maclin: ^-- This works for me in a local test with the advantage of only making one dpkg call and one apt call.
[09:25] <cjwatson> Make that last line   [ -z "$bar" ] || apt-get purge --auto-remove $bar
[09:25] <infinity> cjwatson: Fair point, if their removal list really drops to zero. ;)
[09:25] <cjwatson> It's possible.  May as well guard against it while we remember.
[09:30] <infinity> maclin: http://paste.ubuntu.com/7197925/ <-- The diff for my more efficient version.
[09:31] <maclin> there are so complicated scripts I never know, lol
[09:31] <infinity> (That will still output missing packages, but not error, you could redirect dpkg's stderr to /dev/null if you wanted to shut that up, but for debugging purposes, it's probably nice to know which ones aren't needed anymore)
[09:31] <maclin> I have to spend more time on script learning^_^
[09:32] <maclin> if set -e take effect, the dpkg -l will cause the whole script exit, right? redirect dpkg's stderr to /dev/null can solve this problem?
[09:32] <cjwatson> No.
[09:32] <cjwatson> None of the above.
[09:33] <cjwatson> Only the last part of a pipeline has any effect on set -e; and redirecting stderr achieves precisely nothing here except making it harder to debug (it has no effect on the exit code).
[09:34] <infinity> You can see it in action here, except for the part where apt fails because I'm intentionally not running as root, cause I kinda like my computer: http://paste.ubuntu.com/7197933/
[09:34] <cjwatson> This is not about dpkg -l's exit code.  The failure is because if "foo" returns false, then "foo && bar" also returns false; "cat foo | while read line; do ...; done" creates a subshell whose exit code is that of the last command executed; and *that* exit code trips set -e.
[09:35] <cjwatson> My minimal fix is to invert it to "not-foo || bar", whose exit code is independent of foo.
[09:36] <cjwatson> But I agree that infinity's approach is more efficient.
[09:37] <infinity> I feel like mine would win a useless use of cat award, but I'm too tired to rewrite it to remove that fork.
[09:37] <cjwatson> xargs -l1 dpkg -l </usr/share/ubuntukylin-default-settings/remove-package.list   probably, or something like that
[09:37] <cjwatson> But whatever
[09:37] <infinity> And removing 20 or 30 dpkg and apt calls was enough optimization for me. :P
[09:38] <cjwatson> Er, except that's wrong, drop the -l1
[09:38] <cjwatson> Yeah, no need to micro-optimise this, just go with your pastebinned version
[09:52] <maclin> infinity, cjwatson, I have to take a time to learn the discussed above :P
[09:57] <maclin> thanks for your good solutions, we will improve it after supper^_^
[10:29] <dbarth> hello, i come to talk about the fix for https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1300864" which is now in the unapproved queue
[10:29] <ubot2> Launchpad bug 1300864 in libunity-webapps (Ubuntu) "Duplicate webapps launcher confuses bamf" [High,In progress]
[10:29] <dbarth> i think that it is an important fix for the desktop; let me know if you need more infos to review it
[11:41] <cjwatson> proposed-migration et al stopping for battery replacement on their host
[12:13] <doko> please can somebody ignore the pytables autopkg test? always fails, and always failed
[12:17] <elfy> infinity jibel: remember bug 1284635 - we (xubuntu) are in the position where we need to decide if we stop shipping it with RC rapidly approaching, I've approached aron xu - who's aware of it but has other stuff with higher priority - we're not completely sure of what issues we're going to cause people if we do just drop it - any idea of who we could approach about it?
[12:17] <ubot2> Launchpad bug 1284635 in ibus (Ubuntu Trusty) "Keyboard layout changes after login" [High,Confirmed] https://launchpad.net/bugs/1284635
[12:25] <infinity> doko: How about we just fix it instead?
[12:28] <doko> infinity, sure, you're welcome
[12:28] <infinity> doko: Looking.  It's probably just some missing deps.  Testing that theory.
[12:32] <infinity> doko: Fixing the FTBFS on ppc64el would be nice too.  It used to work in an older version. :/
[12:33] <infinity> Oh, I may have found that bug too.
[12:33] <doko> infinity, there are a lot of ppc64el regressions. oce, python-regexp, ... already tried to build with -O2, but the issue persists
[12:33] <infinity> Oh, no, didn't find the bug, that was me getting exited over a grep. :P
[12:34] <infinity> doko: Yeah, I've had the oce failure sitting in a terminal window for a week or three, and never seem to be in the right zone to figure it out.
[12:41] <jdstrand> stgraber: hi! can you comment on comment #12 in bug #1298611
[12:41] <ubot2> Launchpad bug 1298611 in lxc (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,In progress] https://launchpad.net/bugs/1298611
[12:45] <cjwatson> proposed-migration back up, btw
[12:52] <dbarth> \o/
[13:11] <doko> Riddell, shadeslayer_: calligra needs a no-change upload, okular abi bump
[13:11] <shadeslayer_> ohm
[13:11] <shadeslayer_> doko: will do
[13:12] <shadeslayer_> doko: I was just checking out how the builds were doing, seems like things are looking ~pretty good?
[13:16] <shadeslayer_> doko: plz approve from queue ^^
[13:18] <shadeslayer_> Riddell: ^^ In case you're around
[13:18] <Riddell> onto it
[13:26] <jpds> Can someone put that through NEW? The nex git-annex version build-depends on it.
[13:27] <doko> done
[14:01] <stgraber> jdstrand: looking
[14:04] <stgraber> jdstrand: looks good, replied in bug
[14:04] <jdstrand> stgraber: thanks!
[14:06] <jdstrand> stgraber: fyi, we are coordinating via the security-proposed ppa with all packages ending up in a silo to all bu pushed together. I'll do the upload there as you suggested then keep you posted
[14:12] <happyaron> stgraber: can you have a look at ubuntukylin-default-settings? JackYu is waiting for it...
[14:14] <xnox> please reject empathy 3.8.6-0ubuntu9
[14:17] <infinity> xnox: Kay.  Why? :P
[14:17] <xnox> infinity: because i'll be revert ubuntu8 upload as well.
[14:18] <xnox> infinity: seb128 Laney and I agreed that users don't care about gstreamer, but they care to possible have an option to login into Yahoo!Messenger and AOL AIM
[14:18] <xnox> s/possible/possibly/
[14:19] <xnox> infinity: and if i really want to drop gst0.10 i should instead polish-up and make the gst1.0 patch for pidgin work.
[14:19] <infinity> xnox: I'm inclined to agree that pidgin should be ported, yes.
[14:19] <infinity> xnox: If that's been done upstream already, it can't be too hard to cherrypick?
[14:19] <xnox> infinity: the kicker is that gst audio/video plugin in pidgin is disabled by default, and that functionality is not at all expose to empathy via libpurple & -haze =(
[14:20] <xnox> infinity: it compiles, but doesn't succeed in doing the call ;-)
[14:20] <Laney> They did it on a new series which isn't trivially backportable
[14:20] <Laney> Certainly possible but will require some thought
[14:20] <Laney> Mediumly risky at this stage of the release
[14:43] <cjwatson> xnox: Doesn't look like we get rid of Qt 4 off the Ubuntu desktop image after all; unity -> indicator-appmenu -> appmenu-qt -> libqtgui4
[14:44] <xnox> cjwatson: i thought there were cunning provisions done to make sure we don't depend on qt4 yet ship appmenu-qt.
[14:45] <xnox> (e.g. overriding depends)
[14:45] <xnox> cause it's only loaded by qt4 apps, and by that time qt4 would be present on the image.
[14:45] <xnox> s/image/system/
[14:46] <cjwatson> no such provisions afaics
[14:46] <cjwatson> not even sure what shape they would take
[14:46] <infinity> cjwatson: Well, I assume they'd take the shape of an awful sed against shlibs to remove the qt4 deps.
[14:46] <infinity> Which is vile.
[14:47] <xnox> cjwatson: so in appmenu-qt5 sources, all qt5 libs are listed in suggests. (including a 5.1 qt5core5) and the intention is for those not to end up in depends, but they at the moment do.
[14:48] <cjwatson> ah, well, it's not in place yet anyway :)
[14:48] <infinity> xnox: The "solution" would just be to move shlibs:Depends from Depends to Suggest, then.
[14:48] <xnox> infinity: actually, yeah =))))
[14:48] <infinity> xnox: So the suggests remain properly versioned and such.
[14:48] <infinity> Still going to say that's completely vile.
[14:48] <infinity> But in this case, I can sort of see the argument.
[14:49] <cjwatson> Right, or dpkg-shlibdeps -dSuggests and shlibs:Suggests
[14:49] <cjwatson> But same difference in this case, probably
[14:49] <infinity> cjwatson: That's way more effort than just the control diff. :)
[14:49] <cjwatson> Yeah
[14:50] <cjwatson> It only makes a difference if you have multiple objects
[14:50]  * infinity nods.
[14:50] <cjwatson> Worth knowing that the facility exists though :)
[14:50] <xnox> i guess it's also more fool-proof, with intentions if one renames the field. nice trick i did not know about.
[15:25] <JackYu> stgraber, hi, could you take a look at  ubuntukylin-default-settings? we are waiting for it to respin our iso and start QA. There were more than two days it did't work:(.
[15:26] <stgraber> JackYu: not available at the moment, I'm not the only release team member though
[15:26] <JackYu> stgraber, I see:).
[15:27] <JackYu> Hi release team, who could help to review the ubuntukylin-default-settings 1.1.3 ? thanks in advance.
[15:42] <xnox> so plymouth FFe got approval, subject to review. jodh did review it before, but more code reviews are desired. Luckily most of the people who can/should review plymouth are also in the release team =) ( slangasek, cjwatson, stgraber, infinity...) hence uploading it. It's well tested in variety of configuration and it looks all good. I'm happy to assist in the review queries as needed.
[15:42] <slangasek> xnox: so you got your bug fixed?
[15:42] <xnox> ideally we do want it for 14.04 due to a hi-dpi (x2) theme and improved upstart integration.
[15:43] <xnox> slangasek: after cleansing my machine of stale in-place modified plymouth bits, it was all good.
[15:43] <slangasek> ok
[15:43] <xnox> slangasek: so the package was fine, it's just i boggered up my dev machine.
[15:43] <slangasek> ack - happy for you to upload, then
[15:44] <slangasek> JackYu: ubuntukylin-default-settings accepted
[15:44] <xnox> if this doesn't make it into trusty-final, i'd be pushing for all of those changes as SRUs. Cause it's all bugfixes we'd want to have in trusty under upstart, and the hardware that trusty will ship on.
[15:46] <slangasek> is that a threat? ;)
[15:46] <JackYu> slangasek, great, thank you so much.
[15:46] <slangasek> I'm sure we'll find the time to review it before 14.04 is out
[15:48] <JackYu> slangasek, yep. but we need time to do QA work:).
[15:48] <slangasek> JackYu: right, that comment was directed at xnox actually :)
[15:50] <JackYu> slangasek, oh. Anyway, I owe you one beer (according to the title of this channel:) ).
[15:50] <slangasek> heh
[15:52] <xnox> yeah, after mt.gox closed bird seeds stopped getting accepted. I still have a lot of those, should not have purchased in bulk.
[16:02] <cyphermox> hi, could I please have a freeze exception for changes in NM for MMS support? these would need to happen to go with other Touch-specific changes sergio pointed out on the blanket exception (https://bugs.launchpad.net/ubuntu/+bug/1282590), my bug is https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1302037
[16:02] <ubot2> Launchpad bug 1282590 in Ubuntu "[FFe] standing freeze exception in trusty for Ubuntu Touch-specific packages" [Undecided,Confirmed]
[16:02] <ubot2> Launchpad bug 1302037 in network-manager (Ubuntu) "[FFE] Add support for creating host route to MMS proxy" [Medium,New]
[16:02] <rsalveti> stgraber: generic_x86 rootfs worked fine
[16:07] <stgraber> rsalveti: cool, I'll renumber it later today then
[16:25] <sil2100> Hello release team! We released unity8 today again, we would need someone to bump the package version to make it migrate out of -proposed ;)
[16:26] <sil2100> From what didrocks said sadly we need to poke on -release on every unity8 package release to make britney happy
[16:26] <sil2100> Could anyone take a look?
[16:26] <didrocks> (background: unity8 is a fauxpackage)
[16:29] <Laney> ok
[16:32] <infinity> sil2100: I'll fix that up.
[16:33] <infinity> cjwatson: Might be nice to sort out if that's still needed and, if so, what we need to fix...
[16:33] <infinity> sil2100: Done.
[16:34] <Laney> Oh, you beat me
[16:35] <sil2100> infinity: thank yoU!
[16:37] <cjwatson> 11:11 <cjwatson> I think it's indicator-network
[16:37] <cjwatson> 11:12 <cjwatson> introduced in indicator-network r291
[16:37] <cjwatson> infinity: ^- That
[16:38] <infinity> Oh, it depends on unity8.  Whee.
[16:38] <infinity> Isn't it sort of backwards for indicators to depend on window managers?
[16:38] <seb128> unity8 includes more than the wm :/
[16:38] <seb128> like they have the notification framework there
[16:38] <cjwatson> It seemed to be for a specific feature ("secret-agent", IIRC)
[16:38] <seb128> which is what the indicator needs
[16:39] <seb128> or/and that
[16:39] <infinity> seb128: I realize it's more than just a wm.  The point was that I thought indicator frameworks were meant to be portable to other DEs, not tied to just one.
[16:39] <cjwatson> And indicator-network <- ubuntu-system-settings
[16:40] <seb128> infinity, yeah, that would be nice :/
[16:40] <cjwatson> Hopefully there's somewhere in this chain that we can break it and make something optional and arch-specific
[16:42] <infinity> cjwatson: Make indicator-network build-dep on unity8 and call it done?
[16:42] <infinity> (Or fix it to not require unity8..)
[16:42] <cjwatson> There's quite a chain behind that.
[16:43] <cjwatson> It might be easier to break it at ubuntu-system-settings?  I haven't looked in detail
[16:43] <cjwatson> Removing the chain would take us back to all the account-plugins pain, and I'd rather not
[16:44] <Laney> It's for the wifi panel
[16:44] <Laney> I guess you could do that
[16:44] <infinity> Well, I guess there's always the "port unity8" option. :P
[16:45] <infinity> Which translates to "port mir".
[16:46] <ogra_> to what ? Xorg ?
[16:46] <cjwatson> arm64 support is / should be on lp:mir/devel; ppc64el needs a look; powerpc needs big-endian support in GLPixelBuffer
[16:47] <cjwatson> It shouldn't be intractable but it won't be for 14.04
[16:47] <cjwatson> (Except maybe arm64)
[16:47] <infinity> Meh, if it's not too invasive, I'd totally self-accept my weekend miracle port.
[16:48] <infinity> Anyhow, I need to sleep before parts of me melt off and other bits explode.
[16:49] <infinity> cjwatson: And keeping the FauxPackages mess until release day may well be preferable to trying to remove all the binaries affected.  Some uninst on arches people aren't likely to be testing unity8 on don't matter terribly in the grand scheme of things.
[16:49] <infinity> (Would still be nice to clean up, though)
[16:49] <cjwatson> Right
[16:50] <cjwatson> It's a minor hassle but not awful
[16:50] <didrocks> yeah, I remember the landing team to ping the release team for any unity8 upload we have so that it's not getting unnoticed
[16:50] <didrocks> thanks for looking again infinity, cjwatson, Laney :)
[16:51] <matttbe> Hello, I'm part of the Cairo-Dock team.  Two months ago, I uploaded the latest version of Cairo-Dock in Ubuntu 14.04 repos but both the main dev and I, we are currently too busy to fix some annoying bugs and other design problems... We tried but... to much works :(
[16:52] <matttbe> Sadly, we think that the best solution is to reupload the previous version and cherry-pick 2 or 3 patches. What do I need to do that? Add a new dequest for FFe?
[16:52] <matttbe> *a new request
[16:54] <matttbe> I guess it's a FeatureFreeze for new upstream versions but there is no new feature
[18:33] <stgraber> would be nice if someone could review that systemd upload soonish, it's fixing two rather major problems with the cgmanager support...
[18:33]  * stgraber reviews the rest of the queue
[18:35] <stgraber> Riddell, ScottK: is one of you looking at all those kde langpacks?
[18:35] <Daviey> stgraber, done
[18:36] <stgraber> Daviey: thanks
[18:46] <stgraber> would be so nice if the UI would show us a diffstat, would make reviewing those translation uploads much simpler
[18:55] <Daviey> stgraber: Sounds like you volunteered to make a richer helper tool.  If you do, fancy putting the d/changelog unconditionally at the top? :)
[18:56] <stgraber> Daviey: I wrote a quick 5 lines scripts for now, I can dump all the URLs in it, it'll grab, gzip -d, diffstat, hide me all the .po and tell me it's fine if the only thing there's is the auto-generated debian/changelog
[18:57] <stgraber> so I'm just leaving the queue those that aren't strictly translation updates (there are maybe a dozen of those)
[21:38] <stgraber> slangasek: ^ for your reviewing pleasure (or not).
[22:05] <jdstrand> infinity: hi!
[22:06] <jdstrand> infinity: I think we are ready for the review of bug #1298611
[22:06] <ubot2> Launchpad bug 1298611 in lxc (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,In progress] https://launchpad.net/bugs/1298611
[22:07] <jdstrand> infinity: we've been updating the description and things look good from our end. my plan is to 1. have you review/ack the FFe, 2. to get a silo and copy the packages from security-proposed there, 3. retest with those packages and 4. finish the landing
[22:08] <jdstrand> infinity: for '1', debdiffs are in the bug for your review. please talk to tyhicks and jjohansen if you have questions
[22:09] <jdstrand> infinity: at a high level, it all works as designed with touch (non-ipc kernel) and desktop/server (non-ipc and current kernels)
[22:09] <jdstrand> infinity: we added policy to the base abstraction which made it so that most policy doesn't need updating (ie, updating apparmor is enough)
[22:10] <jdstrand> infinity: libvirt, lxc and lightdm needed updating. stgraber ackd the lxc change, I performed the libvirt change and tyhicks the lightdm (guest session)
[22:11] <jdstrand> infinity: finally, there is apparmor-easyprof-ubuntu which doesn't technically need updating today, but the change is needed for oxide when we update the touch kernels
[22:12] <jdstrand> infinity: I think that's it. I need to step away for a bit, but tyhicks is up on all the FFe details and jjohansen can answer specific questions about the patches in apparmor
[22:15] <jdstrand> infinity: just for full disclosure-- two tests are currently running and expected to pass. I asked tyhicks to put the debdiff up for your review-- we'll obviously fix the issue if the test doesn't pass
[22:16] <tyhicks> I'll mention the results of the tests when the finish up in ~15 minutes
[22:17] <jdstrand> tyhicks: I've got to step away (dinner, stuff)
[22:17] <jdstrand> I'll be back later to do the silo dance
[22:17] <tyhicks> jdstrand: no problem - thanks for explaining everything
[22:17] <jdstrand> (and the testing, etc)
[22:53] <tyhicks> infinity, jdstrand, jjohansen: the final two apparmor tests that jdstrand mentioned were successful
[22:54] <tyhicks> (and by two tests, I mean two full runs of QRT's test-apparmor.py, which is a large set of pretty extensive tests)
[22:57] <jdstrand> tyhicks: nice :)
[22:57] <jdstrand> ok, really gone
[23:30] <tyhicks> jjohansen: I need to step away for a couple hours - please keep an eye out for any apparmor ffe questions until you go EOD
[23:30] <tyhicks> I'll check back in when I get home
[23:30] <jjohansen> tyhicks: ack
[23:53] <slangasek> xnox: why did you add ttf-ubuntu-font-family as a dependency of plymouth-theme-ubuntu-logo, instead of replacing the dependency on fonts-dejavu-core already in plymouth-label?
[23:58] <slangasek> xnox: I know we discussed this, so maybe there was a good reason in terms of glyph coverage to continue to include dejavu; so I won't consider this a blocker since I believe we currently already have both fonts everywhere theme-ubuntu-logo is used, but if we can drop the dejavu dep I'd like to do so