[04:34] <jpds> infinity / slangasek: I have no intentions of putting efitools in main.
[04:35] <jpds> infinity / slangasek: I just want it in universe of Secure Boot work of mine.
[04:35] <jpds> infinity: But yeah, https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages says to file an FFE.
[04:36] <jpds> slangasek: And yes, I have an enterprise customer that needs them. :)
[04:37] <jpds> But I think they'll live with them being in universe.
[05:47] <infinity> jpds: I guess I'm curious about why they're "needed".
[05:53] <jpds> infinity: To manage their own enterprise keys.
[05:54] <infinity> jpds: Do we not already have tools that let people do that?
[05:55] <jpds> infinity: I think there's sbsigntool, but efitools seems to complement it.
[05:55]  * infinity shrugs.
[05:55] <infinity> Kay.
[05:55] <infinity> It'll get reviewed.  I was just concerned about the "people need this" wording in the FFe.
[05:56] <infinity> Cause if it's needed for platform support, it belongs in main.  If it's not, it probably doesn't need to exist.  So... Whee.
[05:57] <jpds> Well, I doubt most people want to maintain their own enterprise key sets.
[05:57] <jpds> Some of us, do. :)
[10:33] <didrocks> do you have any time to look at the apport change? We don't have reliable Touch image test results on the number of crashes we get until that one went in?
[10:45] <seb128> does https://bugs.launchpad.net/ubuntu/+bug/1294891 need a ffe?
[10:45] <seb128> (that's a new package)
[10:45] <seb128> no bugbot?
[10:45] <ubot2> Launchpad bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Triaged]
[10:45] <seb128> (oh, just some lag)
[10:45] <Laney> Yeah, but if you're fine to NEW review it then what evs, I'll ack it
[10:46] <seb128> well, I can't sponsor and NEW it as well... ;-)
[10:46] <seb128> dholbach reviewed it, let me see if he wants to upload so I can NEW and you can ack it
[10:46] <Laney> the dream team
[10:47] <seb128> indeed!
[10:54] <xnox> Hello =) Can ~sru please release debian-installer into precise-updates? Maybe, arges_ =)
[11:14] <didrocks> sorry to reping, but we are really blocked on Touch on the apport change to get reliable and useful crash test results, can anyone look at it?
[11:15] <Laney> am looking
[11:15] <Laney> do you know which fix is the relevant one?
[11:15] <didrocks> Laney: yeah, https://code.launchpad.net/~xnox/apport/fix-cgroup/+merge/212282
[11:16] <Laney> nod
[11:16] <didrocks> Laney: just some additional space, what can happen wrongly? :)
[11:20] <didrocks> thanks Laney
[11:21] <Laney> yw, good luck ;-)
[11:22] <infinity> xnox: Ahh, didn't notice the d-i there when I did the kernels.  Will copy.
[11:22] <xnox> infinity: thanks.
[11:36] <Laney> I think that fcitx-qimpanel upload might be a mistake
[11:37] <Laney> rejecting, happyaron can come back if not
[12:19] <Laney> Anyone feel qualified to look at https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093 ?
[12:19] <ubot2> Launchpad bug 1295093 in docker.io (Ubuntu) "[FFe] Sync docker.io 0.9.0 from Debian unstable" [Undecided,Confirmed]
[13:14] <rbasak> Can someone look at the juju-quickstart FFe for me, please? Bug 1282630.
[13:14] <ubot2> Launchpad bug 1282630 in juju-quickstart (Ubuntu Trusty) "[FFe] Upgrade juju-quickstart to new upstream release 1.3.0" [High,New] https://launchpad.net/bugs/1282630
[13:45] <tjaalton> I've just uploaded new sssd to fix a ftbfs (stupid lp), and autofs to build-depend on sssd-common so that it'll build support for sssd backend
[13:46] <tjaalton> but it'll mean finally fixing the sssd MIR
[13:46] <tjaalton> which is bug 903752
[13:46] <ubot2> Launchpad bug 903752 in sssd (Ubuntu) "[MIR] sssd" [Undecided,Fix committed] https://launchpad.net/bugs/903752
[13:47] <tjaalton> so if someone has cycles to add sssd to the supported seed that would be great, I never succeeded in that when gave germinate a try..
[14:01] <roaksoax> infinity: howdy!! any chance you could look at the MAAS FFe and process it from the unapproved queue?
[14:02] <ScottK> roaksoax: You aren't supposed to upload until after an FFe is approved.
[14:06] <roaksoax> ScottK: I'm aware... but its been open for over a month
[14:06] <ScottK> How does that change if you should upload it?
[14:06] <roaksoax> ScottK: it doesn't, but it is a  way for someone to notice it
[14:07] <ScottK> Noticed and rejected.
[14:07] <roaksoax> ScottK: Thanks for being so helpful
[14:07] <roaksoax> gaughen: ^^
[14:09] <ScottK> I don't have an opinion on the FFe itself.  If it gets approved, we can later accept it from the rejected queue.  In the mean time, it won't get processed in the queue by someone who might not realize it has a pending FFe.
[14:09] <gaughen> roaksoax, what just got rejected for maas?
[14:09] <ScottK> This doesn't hurt you at all, it just protects the release team from the possible effects of your inappropriate upload.
[14:11] <roaksoax> ScottK: agreed, but something else you could have done was to review the FFe. It is not the first time I see a package being uploaded before having the FFe approved, in fact, I've been recommended to upload packages many teams before having FFe/MIR approvals to have it in the queue. But anyways, that's a completely different matter. Thanks for rejecting it!
[14:12] <roaksoax> gaughen: FFe not approved.. it was filed over a month ago
[14:12] <roaksoax> gaughen: so the package has been sitting in the queue since friday
[14:12] <ScottK> The best way not to get blocked on FFe approval is to get stuff in before feature freeze.
[14:13] <roaksoax> ScottK: agreed! but unfortunately all the work needed to be done couldn't be completed before FF
[14:15] <roaksoax> ScottK: hence we filed the FFe early for all the incoming features
[14:20] <stgraber> tjaalton: added to the supported seed, we'll see if all goes well with the next c-m run
[14:20] <tjaalton> stgraber: whoa, thanks!
[14:22] <stgraber> tjaalton: btw, something must be wrong with sssd's upstart job somehow. I had it get stuck a few times to the point where I had to reboot the system for upstart to get a clean state again...
[14:22] <stgraber> tjaalton: this happens when sssd starts and dies which can happen if you have a sssd.conf but no keytab or something along those lines
[14:23] <tjaalton> stgraber: yeah I think I've seen that too at some point..
[14:23] <tjaalton> when debugging something
[14:23] <stgraber> tjaalton: I was wondering if it may be worth forcing sssd to stay in the foreground and then drop "expect fork", that should fix that kind of problem
[14:24] <tjaalton> could be
[14:25] <gaughen> ScottK, now that your mind is on maas, you going to have a peak at the maas FFe?
[14:28] <ScottK> You probably would rather I didn't.  Given maas's track record for having a development schedule aligned to Ubuntu's I would approach it very skeptically.
[14:29] <jdstrand> infinity: hi! fyi, bug #1298611 has the testing documented
[14:29] <ubot2> Launchpad bug 1298611 in libvirt (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,Triaged] https://launchpad.net/bugs/1298611
[14:29] <jdstrand> infinity: not sure why it picked up libvirt there...
[14:30] <jdstrand> infinity: anyhoo-- the kernel is ready to be reviewed
[14:30] <jdstrand> infinity: apparmor userspace, libvirt, et all will come later in the week (again, they can be separate from the kernel)
[15:11] <stgraber> tjaalton: sssd now showed up on c-m, I promoted it to main so the next run should let us know if everything is clean or if it's trying to bring other things in main with it. I guess some of the binary packages may also want to move back to universe, we'll look into those then.
[15:16] <stgraber> tjaalton: looks like sssd is trying to pull at least libpam-pwquality and libsasl2-modules-ldap into main
[15:53] <stgraber> tjaalton: the following packages also want to move back to universe, any reason to seed any of those? python-libipa-hbac python-libsss-nss-idmap sssd-tools
[16:02] <tjaalton> stgraber: i'll check those in 3h when i'm back home. could be i need to change the packaging a bit to avoid pulling the world in main..
[16:20] <tjaalton> stgraber: pwquality mir should be accepted somewhere, the pam module too
[16:25] <ScottK> Should we have a transition tracker for rebuilding python extensions to support 3.4 only?
[16:26] <cjwatson> Sounds like a plan; there are a couple like that already ...
[16:29] <ScottK> I think it's mostly bad have depends python3* >= 3.3 and good being >= 3.4, IIRC.
[17:02] <slangasek> jpds: why do they need these SB tools, instead of the ones we already have in main?
[17:02] <slangasek> ah, n/m, read the scrollback
[17:04] <tjaalton> stgraber: a quick glance shows that the non-main deps of the python libs and sssd-tools are from sssd itself
[18:09] <xnox> android-tools upload ^ is a one-liner fix, which makes "adb shell" have a system locale set and behave less brain-dead. This unbreaks a few things that try to decode everything in POSIX/ascii at the moment.
[18:09] <xnox> it's been well-tested since january, but never uploaded.
[18:10] <zul> can someone reject the ceilometer upload please?
[18:21] <xnox> ScottK: good catch, about 58 packages are like that.
[18:25] <ScottK> xnox: Did you set up a tracker?
[18:26] <xnox> ScottK: yeah, created a tracker, which ends up listing 19 source packages. Will work on uploading them.
[18:32] <ScottK> xnox: You can skip pykde4 if it's on the list since it'll be uploaded again anyway.
[18:32] <xnox> ScottK: thanks. ditoo pyqt?
[18:32] <xnox> and sip4?
[18:33] <ScottK> No immediate plans on those, you may as well go ahead.
[18:33] <ScottK> You can skip qscintilla2 though.
[18:35] <xnox> ScottK: right, thanks. I'll fire off local rebuild and check it after dinner and do mass dput
[19:05] <zul> ScottK:  can you reject ceilometer for me please?
[19:05] <ScottK> Sure.
[19:06] <ScottK> zul: .
[20:10] <xnox> ScottK: please accept python-levenshtein (source) for the no-change rebuilds
[22:12] <rtg> infinity, just uploaded a kernel if you would be so kind as to accept it for building.
[22:13] <infinity> rtg: No more kernels for you.
[22:14] <rtg> infinity, there will be at least one more. sorry.
[22:14] <infinity> rtg: Especially not ones with 6MB diffs.  Is your tree clean?
[22:14] <rtg> well, lemmecheck
[22:14] <rtg> infinity, looks clean
[22:14] <infinity> I suppose that's plausible, given the .8 rebase.
[22:14] <infinity> Lemme look.
[22:15] <rtg> infinity, it was a pretty big stable update
[22:15] <rtg> which is why I wanted some mileage on it before freeze
[22:16] <infinity> rtg: Oh, whee, this is also the apparmor FFe?
[22:16] <rtg> infinity, yup to AA. 47 stable patches.
[22:16] <rtg> misc config changes as well
[22:16] <infinity> jjohansen: Is alpha6 still the one you wanted there?
[22:17] <infinity> rtg: Kay, so this AA FFe needs some attention before I JFDI on the accept, but I'll get there.
[22:17] <rtg> infinity, jjohansenassured me that it was backward compatible regardless of user space support.
[22:17] <infinity> rtg: Right, he's assured me the same thing.  We've been talking (at length) about it.
[22:17] <jjohansen> infinity: well I could give you a bigger diff that I guarantee will break things
[22:18] <infinity> jjohansen: Gee, what a swell offer.
[22:18] <jjohansen> yes that kernel has been tested on precise
[22:19] <infinity> jjohansen: Okay, can you triple-check the diff in the queue and make sure it's what you wanted?  And then I'll get to abusing the FFe.
[22:20] <jjohansen> infinity: sure
[22:20] <infinity> rtg: And why did ZSWAP go away?
[22:21] <rtg> infinity, it isstill experimental, so I thought I'd rather be safe then sorry.
[22:21] <rtg> the help text is actually a little scary.
[22:21] <infinity> rtg: Hrm.  Kay, but it was on for the whole cycle, that might confuse.  Scary help text is a good enough reason, though.
[22:22] <rtg> infinity, we're having some random oops in some cases, though I have no hard evidence that ZSWAP is related. the feature is relatively new (3.11)
[22:22] <infinity> rtg: *nod*... Fair enough.  Better safe than sorry.
[22:23]  * infinity lolz at -CONFIG_VERSION_SIGNATURE="Ubuntu 3.11.0-0.1-powerpc-e500mc 3.11.0-rc5"
[22:23] <infinity> Dear Ben, Oops?
[22:23] <rtg> right
[22:26] <jjohansen> infinity: that it looks good to me
[22:26] <infinity> rtg: Alright, looks sane enough to me.  When the security team and I sort out the AA FFe, I'll either accept or reject and make you pull their patches.
[22:26] <infinity> (But I'm leaning to accept)
[22:26] <infinity> jjohansen: Kay, good deal.
[22:48] <slangasek> hmmm, anyone know where ibus-pinyin-db-android went?  ubuntukylin builds apparently depend on it and it's gone from trusty
[23:04] <infinity> slangasek: They do?  I thought I fixed all its rdeps.
[23:04] <infinity> slangasek: It was absorbed into ibus, IIRC, though I did the NBS mangling for that a while ago now.
[23:05] <infinity> slangasek: Oh, this could have something to do with them being the only flavour that isn't seed-based?  I fixed the seeds/meta for everyone else.
[23:06] <slangasek> infinity: right, they're not seed-based; if it's been absorbed into the main package, huzzah
[23:07] <infinity> slangasek: libpyzy-1.0-0: /usr/share/pyzy/db/android.db
[23:07] <infinity> slangasek: Which is a dep of ibus-pinyin
[23:08] <infinity> slangasek: Why *aren't* they seed-based? :P
[23:08] <infinity> (This also means we can't mark them as an LTS in LP very easily)
[23:11] <slangasek> because when they were first getting started, pitti's other thing was presented to them as the quick'n'easy way to localize an ISO that has a small delta to Ubuntu Desktop, and they have yet to transition off
[23:12] <slangasek> they in fact have expressed interest in switching to seeds, but this hasn't materialized for reasons unbeknownst to me; it's possible they've felt blocked on governance to make this switch
[23:13] <stgraber> if they want to swtich to using seeds, they should probably grep for edubuntu in the relevant branches and use that as an example seeing how we're also just a tiny overlay (well, a GB or so, but that doesn't really matter) on top of Ubuntu desktop
[23:16] <infinity> slangasek: So, out of curiosity, where did this pinyin-android change need to be made?  I'm a bit miffed that I didn't pick up on it in my NBS culling of the binary.
[23:16] <infinity> (ie: nothing depends on it)
[23:16] <slangasek> infinity: the ubuntukylin-default-settings package
[23:18] <infinity> Oh, bah.  Which is then installing it directly to the image, thus a lack of actual deps.
[23:18] <infinity> So, yeah, them having a meta that depends on things would be vaguely useful.