=== yofel_ is now known as yofel
=== Guest60966 is now known as NCommander
=== NCommander is now known as Guest28960
[16:24] <ockham> okay, gourmet 0.17.0 has landed in sid, see https://bugs.launchpad.net/ubuntu/+source/gourmet/+bug/1286073. can i get an FFe, please?
[16:24] <ubot2`> Launchpad bug 1286073 in gourmet (Ubuntu) "[FFe] Please update gourmet to 0.17.0" [Undecided,New]
[16:41] <infinity> ockham: Done.
[16:51] <ockham> infinity: thx a lot!
[16:58] <teward> infinity: i doubt nginx 1.4.6 would qualify for an FFe, right?  Because it adds new features?  (debian changelog: http://metadata.ftp-master.debian.org/changelogs//main/n/nginx/nginx_1.4.6-1_changelog )
[16:58] <teward> (I ask because nginx mir is 1.4.5 and latest nginx stable is 1.4.6)
[16:58] <teward> (nginx mir being the version in the process of being considered for main inclusion)
[16:59] <infinity> teward: Well, the MIR still had the isssue that we can't do it without disabling lua for all flavours, or porting to lua5.2
[16:59] <teward> infinity: we're already dropping lua
[16:59] <teward> for the MIR
[16:59] <teward> that's already been decided
[16:59] <teward> (if they need Lua they can use the nginx team ppa)
[17:00] <infinity> teward: Are we?  Okay.  People do realise this is for *all* flavours, right, not just the one in main?
[17:00] <teward> infinity: the moment the MIR is approved i'm going to preemptively make a bug about it, and Won't Fix it.  So we can point people to that.  And maybe we should add a NEWS entry
[17:00] <teward> but that's outside the scope of the question i asked here
[17:01] <infinity> teward: So, as to the 1.4.5->1.4.6, I'd need to see the upstream diff and changelog, the Debian one isn't helpful.
[17:01] <teward> i can probably find that
[17:01] <teward> would a full debdiff between 1.4.5 and 1.4.6 work?
[17:01] <infinity> Well, just a debdiff between Debian 1.4.5-1 and 1.4.6-1 is enough for me to go hunting through.
[17:01] <infinity> Jinx.
[17:01] <teward> :p
[17:02] <teward> infinity: my concern is these lines in the debian changelog:      + Enable realip module for nginx-light.   + Enable debug module for nginx-light and nginx-extras.
[17:02] <teward> those add new modules (i.e. new features) to those flavors
[17:02] <infinity> That's fine.  *shrug*
[17:02] <teward> standby for debdiff then
[17:02] <infinity> I mean, if the overall changeset is otherwise fine, that probably is.
[17:03] <infinity> rsalveti: Are you going to get the kernel team to toss hammerhead in git and do the uploads, or will you be maintaining it seperately?
[17:04] <teward> infinity: http://paste.ubuntu.com/7062711/ is the debdiff between debian 1.4.5-1 and 1.4.6-1
[17:05] <infinity> apw: Do you have any context on the hammerhead AOSP kernel?
[17:05] <teward> if you're willing to approve an FFe, I'll file a bug requesting the merge, and see if cjwatson can merge it (they helped with the last merge)
[17:05] <teward> then rebase the MIR debdiff on 1.4.6
[17:07] <infinity> teward: Ahh, kay, to the point of that was module normalisation between the flavours, and the addition of a common_config.  I totally support that change.
[17:08] <teward> infinity: if you can post on https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1290063 about an FFe being approved, after you review the debdiff, then I'll poke cjwatson :)
[17:08] <ubot2`> Launchpad bug 1290063 in nginx (Ubuntu) "[FFe needed] Please merge nginx 1.4.6-1 (universe) from Debian unstable (main)" [Undecided,New]
[17:08] <teward> (and it's a merge because we have a version string delta)
[17:09] <infinity> Right, so, let's see the merge, and then the MIR patch updated to use the new debian/rules structure, and get it all done today.
[17:10] <infinity> I don't think Colin will in any way care to be involved, he's TIL on nginx by accident, not design.
[17:10] <teward> okay
[17:10] <teward> infinity: i may not be able to do the merge, the last time i tried it FTBFS in sbuild
[17:11] <teward> so i probably did something wrong
[17:11] <infinity> Let me have a poke at it.
[17:11] <teward> infinity: thank you kindly.
[17:12] <teward> infinity: and RE the Lua drop in all the flavors for the MIR, I'm going to post on my own blog about it, and it'll end up on planet.u.c so then there'll at least be some visibility there
[17:13] <teward> besides, when Ubuntu comes up in #nginx they poke me xD
[17:13] <teward> (same for #ubuntu-server)
[17:14] <infinity> teward: Yeah.  I wish there was some indication of how widely that feature was used.
[17:15] <infinity> teward: If we're crippling something a lot of people relie on just for the sake of putting it in main, the MIR is completely pointless, IMO.
[17:16] <infinity> I suppose I should correct attribution on this branding patch while I'm in here...
[17:20] <infinity> I should probably make it smarter, so it can be submitted to Debian.
[17:21] <infinity> Though, I suppose now that we'll have a delta for the new flavour, that's a bit less interesting. :/
[17:26] <infinity> teward: Merge uploaded.
[17:43] <rsalveti> infinity: will maintain it separately, as it's not officially supported by them
[17:43] <infinity> rsalveti: Well, none of them are "officially supported", AFAIK, but does it really make sense to have one exist outside where the rest are?
[17:44] <rsalveti> infinity: well, the kernel team is responsible for the other ones :-)
[17:44] <rsalveti> infinity: I can ping them tomorrow and see if they can/want to manage that branch together with the other ones
[17:44] <infinity> rsalveti: Right, I'd argue that they should all live in the same repo with the same level of responsibility.
[17:45] <infinity> rsalveti: We've never had a good track record with forked kernels maintaining coherent CONFIG_ options, etc.
[17:45] <infinity> Or security fixes, blah blah.
[17:45] <rsalveti> right, this one is at least following the same configs and containing the same sauce as we currently have for the other flavors
[17:46] <infinity> rsalveti: Key word "current".  They diverge pretty quickly if people aren't very careful.
[17:46] <rsalveti> right, but at least I'm mostly involved with any other sauce or config change we get anyway
[17:51] <infinity> teward: Aaaand, uploaded again to fix the FTBFS on ppc64el.
[17:51] <infinity> teward: So, if you want to rebase your MIR patches on top of 1.4.6-1ubuntu2, I can review and sponsor.
[17:52] <infinity> rsalveti: That will immediately stop being true if we decide we want to do post-release (SRU/security) support for them.
[17:52] <infinity> rsalveti: Which is probably still up in the air, but we've been looking at how painful it would be.
[17:53] <infinity> rsalveti: Anyhow, the N5 being one of the only Nexus devices you can actually buy, it seems odd if that's the only kernel our kernel team DOESN'T maintain. :)
[17:57] <rsalveti> infinity: right, but only mako, manta and flo are officially supported (by the canonical kernel team), the rest is all community supported
[17:58] <rsalveti> infinity: and how should we do then if we want to include any other kernel tree that the community wants to support?
[17:58] <infinity> rsalveti: Oh, I'm not against community supported kernels, I just question this specific one.
[17:58] <rsalveti> I was thinking initially to maintain them at https://code-review.phablet.ubuntu.com/gitweb?p=ubuntu/kernel/trusty.git;a=summary (same place we're currently using for nexus 5)
[17:59] <infinity> rsalveti: Is that a git repo you can give external access to?
[17:59] <rsalveti> oh, ok, so it's more a question if we want to keep this as a community supported device or if we'll end up officially supporting it later on
[17:59] <infinity> (If not, the "community" part of that is a bit of a joke)
[17:59] <rsalveti> infinity: they can all use it via gerrit
[17:59] <infinity> rsalveti: So, we don't "officially" support anything, but we also officially support some things.  Unofficially.
[17:59] <rsalveti> propose patch series and so on
[17:59] <rsalveti> indeed :-)
[18:00] <infinity> rsalveti: But the N5 seems like it should be on that unofficially official list.
[18:00] <rsalveti> nothing from touch is officially supported, but the canonical kernel team has the reponsability to maintain the tress for mako, manta and flo (doing security fixes, bug fixes, and maintaining the latest apparmor in there as well)
[18:01] <infinity> rsalveti: Given that mako is in that list, and I can't actually buy a mako, but I can buy a hammerhead...
[18:01] <rsalveti> right, but this is more a question for rick I'd guess
[18:01] <infinity> rsalveti: So, yeah.  I think we should have a chat with apw/rtg and get hammerhead in the same repo as mako/manta/flo
[18:02] <rsalveti> no worries, will ping them tomorrow
[18:02] <infinity> rsalveti: I don't see how Rick is involved...
[18:02] <rsalveti> rick, together with asac, made the decision to keep only supporting mako and not support hammerhead (from the canonical side)
[18:02] <infinity> rsalveti: I mean, what you guys (the phonedations folks) decide to advertise as supported *images* is up to you and your management, but I think the *kernel* should be in the kernel team's repo, that's all.
[18:03] <infinity> (Would definitely be nice, if all the bits can fit together in time, to support N5 *images*, but that's more work than just a kernel, so I understand if it's not a realistic goal)
[18:03] <rsalveti> yeah
[18:04] <rsalveti> would need to buy a bunch of devices to put in the qa lab and so on
[18:04] <rsalveti> but anyway, we can have this discussion tomorrow with the kernel team
[18:04] <infinity> Well, at least they exist. :P
[18:04] <infinity> And hey, if you give me an N5 image that doesn't suck, I might actually run it.
[18:04] <rsalveti> :-)
[18:07] <infinity> rsalveti: Anyhow, this is all best-practices source management talk.  It doesn't really affect the MIR.
[18:07] <infinity> rsalveti: As I said on the MIR bug, if you build against the same orig, so I can easily check deltas and review it (and if it passes AA review), the MIR is fine.
[18:08] <rsalveti> yeah, makes sense
[18:08] <infinity> Erm, though rtg might not have switched to using a common orig yet.  He told me he was going to.
[18:09] <infinity> Ahh, manta uses the orig.  mako doesn't yet.
[18:09] <rsalveti> yeah, I don't think they are using a common tree yet
[18:09] <infinity> What a fine mess this all is.
[18:09] <rsalveti> indeed
[18:18] <apw> infinity, they don't use an orig (mako) cause it has some binary crap in it which is "different" so cannot be represented
[18:18] <apw> needs figureing out
[18:20] <infinity> apw: Oh, ick.
[18:48] <teward> infinity, i'll rebase the patches as soon as my parents give me some [censored] freedom... until then i have insufficient internet strength to download the latest changes you've done.
[18:48] <teward> s/done/uploaded/
=== slangase` is now known as slangasek