=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[04:28] <jbicha> mwhudson: could you nominate bug 1432271 bug 1484785 and bug 1586708 for wily and xenial please?
[04:28] <ubottu> bug 1432271 in One Hundred Papercuts "[SRU] Abiword always starts after logging in" [High,Triaged] https://launchpad.net/bugs/1432271
[04:28] <ubottu> bug 1484785 in abiword (Ubuntu) "language selector text cut off in abiword" [High,Fix released] https://launchpad.net/bugs/1484785
[04:28] <ubottu> bug 1586708 in abiword (Ubuntu) "Abiword icon has extra smaller icons included" [Undecided,Fix released] https://launchpad.net/bugs/1586708
=== _salem is now known as salem_
=== athairus is now known as afkthairus
[06:49] <slangasek> LocutusOfBorg: yes, it's possible to demote botch or ignore its testsuite; please tell us which is the more correct here and why :)
=== marcusto_ is now known as marcustomlinson
=== salem_ is now known as _salem
=== _salem is now known as salem_
[07:42] <slangasek> LocutusOfBorg: fwiw the disabling of botch autopkgtest was already done as of 0.16-2ubuntu2 in xenial, this was not a behavior change introduced in the new merge.
[08:22] <pitti> slangasek: can you please approve to yakkety and set an adequate priority, παρακαλώ? https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml
[08:40] <seb128> cyphermox, hey, could you look at bug #1591622? it might be a regression from your console-setup xenial SRU which is in proposed currently
[08:40] <ubottu> bug 1591622 in console-setup (Ubuntu) "Can't login to system, system is booting up error" [High,Confirmed] https://launchpad.net/bugs/1591622
=== pete-woods[fail] is now known as pete-woods
[09:00] <flexiondotorg> I'm working on getting the Ubuntu MATE seeds to follow recommends.
[09:01] <flexiondotorg> I have indicator-session in the Ubuntu MATE live seed. When recommends are followed this pulls in gnome-control-center or unity-control-center.
[09:02] <flexiondotorg> However, because MATE uses (proxies) the same namespaces for session management, no code changes are required in indicator-session.
[09:02] <ogra_> yeah, recommends are fun :)
[09:02] <flexiondotorg> Only a debian/control change is required.
[09:02] <flexiondotorg> So, which would be best debdiff or merge proposal?
[09:10] <slangasek> pitti: you mean 'παρακαλώ;' ;)
[09:11] <pitti> slangasek: you mean the semicolon is mandatory?
[09:14] <slangasek> pitti: (done)
[09:14] <slangasek> pitti: ?-(Greek)->;
[09:16] <seb128> flexiondotorg, you want a merge request for indicator-session changes
[09:17] <seb128> it's maintained in a bzr vcs and landing through ci
[09:17] <infinity> flexiondotorg: What are you trying to fix?
[09:18] <flexiondotorg> infinity, That unity or gnome control-center or pulled in which also pulls in their session manager.
[09:18] <infinity> flexiondotorg: What's the proposed fix?
[09:18] <flexiondotorg> So in Ubiquity DM, the GNOME or Unity session manager is used in preference to MATEs.
[09:18] <flexiondotorg> Meaning none of the MATE settings are used.
[09:19] <flexiondotorg> infinity, unity-control-center | gnome-control-center | mate-control-center in debian/control for Recommends.
[09:19] <flexiondotorg> I'm just testing locally to be sure this fix is correct.
[09:19] <infinity> Ahh, yeah.  That'd probably do.  Don't forget the unity-control-center-signon bit too.
[09:20] <flexiondotorg> infinity, Yes, I was going to pull in gnome-control-center-signon, but I'm not sure that will help.
[09:20] <flexiondotorg> There is no MATE alternative for to signon however.
[09:21] <infinity> flexiondotorg: Well, if you don't need that bit, just make the signon stuff also depend "| mate-control-center"
[09:21] <flexiondotorg> And it is not required, so I am considering making that unity-control-center-signon | gnome-control-center-signon | mate-settings-daemon
[09:21] <flexiondotorg> infinity, Yeah, or your idea seems more sensible :-)
[09:22] <infinity> libaccount-plugin-1.0-0 will also cause you some issues there.
[09:22] <infinity> Maybe.
[09:23] <infinity> Or maybe that's just a loop.
[09:23] <infinity> Yeah, that might just be a loop.
[09:33] <cyphermox> seb128: looking
=== salem_ is now known as _salem
[10:04] <flexiondotorg> seb128, yelp recommends gnome-user-guide. mate-user-guide also uses yelp.
[10:05] <flexiondotorg> So I want to change that Recommends to gnome-user-guide | mate-user-guide
[10:05] <Unit193> Drop to suggests. >_>
[10:05] <flexiondotorg> Unit193, Or that.
[10:05] <flexiondotorg> I'd prefer that.
[10:05] <Unit193> Xubuntu wants neither, honestly.
[10:05] <flexiondotorg> Indeed.
[10:09] <flexiondotorg> seb128, Laney Looks like I can't upload or make a merge proposal for https://code.launchpad.net/~ubuntu-desktop/yelp/ubuntu
[10:09] <flexiondotorg> Will a debdiff do?
[10:10] <Laney> Do a branch and ask someone to merge it manually if you can't do a merge proposal
[10:20] <flexiondotorg> Laney, OK, merge proposal is possible :-)
[10:20] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/yelp/mate-compatibility/+merge/297171
[10:20] <flexiondotorg> Unit193, ^^^
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[12:11] <cpaelzer> rbasak: do you have a minute for a few best practise hints on package upgrade testing?
[12:11] <cpaelzer> I'm not getting lucky with piuparts and I start to think my case is too special
[12:12] <rbasak> cpaelzer: sure.
[12:13] <cpaelzer> rbasak: thanks - anybody else feel free to jump in if you want to share a better approach :-)
[12:13] <cpaelzer> rbasak: I wanted to test the clamav fix we were discussing next week before going SRU with it
[12:13] <cpaelzer> TL;DR case:
[12:14] <cpaelzer> A-old in Trusty, A-new-broken in W&X, A-new-fixed local (sbuild)
[12:14] <cpaelzer> I'd like to test a Trusty -> Xenial Upgrade (with A-new-fixed)
[12:20] <cpaelzer> would need something like a do-release-upgrade + ppa
[12:20] <cpaelzer> probably not the most important case here, but I can discuss and learn in this case as much as in any critical one later on
[12:20] <cpaelzer> rbasak: ^^
[12:22] <rbasak> cpaelzer: piuparts is a tool that may be able to help. I'm not sure if it's an exact fit to your problem though.
[12:23] <cpaelzer> as I wrote, so far it didn't make me happy :-)
[12:23] <rbasak> cpaelzer: to do it manually, then a PPA with dist-upgrade (not sure how to use a PPA with do-release-upgrade but dist-upgrade is close enough for most purposes).
[12:23] <cpaelzer> if anything I think I spottet only unrelated issues in piuparts
[12:23] <rbasak> Oh, sorry, I missed that.
[12:23] <rbasak> Instead of a PPA you can use a local repository.
[12:24] <rbasak> apt-ftparchive can create the packages and releases files.
[12:24] <cpaelzer> hmm, the problem will be that due to dependencies I'd need to build almost the full distro
[12:24] <cpaelzer> since the newer packages depend on Xenial things
[12:24] <cpaelzer> do you suggest building the new package, but for Trusty?
[12:25] <cpaelzer> let me read apt-ftparchive ...
[12:25] <rbasak> http://paste.ubuntu.com/17288886/ is what I use
[12:25] <rbasak> gpg is optional - you can use [trusted=yes] in sources.list instead.
[12:26] <cpaelzer> ok, with that I could go to a trusty container and build my local archive for the packages - thanks
[12:26] <cpaelzer> that is similar to what we used for the nis test back in manchester
[12:26] <rbasak> cpaelzer: build the proposed fixed package in Xenial using a Xenial chroot, and then put it in its own repository. Start a Trusty machine (container should do), dist-upgrade to latest Trusty, then s/trusty/xenial/ in sources.list, add your local archive to override the new A, and then dist-upgrade.
[12:27] <rbasak> cpaelzer: you can verify what apt sees with "apt-cache policy"
[12:27] <cpaelzer> ok, now I see how you avoided do-release update
[12:27] <cpaelzer> thanks
[12:27] <cpaelzer> nice plan
[12:27] <cpaelzer> will give that a try
[12:28] <rbasak> It would be nice if do-release-upgrade grew a feature for a third party apt source for testing purposes.
[12:29] <rbasak> cpaelzer: if using lxd you may hit bug 1580984.
[12:29] <ubottu> bug 1580984 in systemd (Ubuntu) "procps postinst fails when inside lxd" [Medium,Confirmed] https://launchpad.net/bugs/1580984
[12:31] <cpaelzer> thanks for making me aware before I ran too deep into it rbasak
[12:45] <jbicha> dholbach: could you target bug 1484785 and bug 1586708 for wily and xenial too? thanks
[12:45] <ubottu> bug 1484785 in abiword (Ubuntu) "language selector text cut off in abiword" [High,Fix released] https://launchpad.net/bugs/1484785
[12:45] <ubottu> bug 1586708 in abiword (Ubuntu) "Abiword icon has extra smaller icons included" [Undecided,Fix released] https://launchpad.net/bugs/1586708
[12:47] <dholbach> sure
[12:51] <flexiondotorg> cjwatson, I am right in thinking that adding a Recommended package to blacklist in the seeds should prevent that package ever being listed in the germinate output?
[12:51] <cjwatson> flexiondotorg: blacklist entries should almost never be used
[12:51] <flexiondotorg> cjwatson, Yes. I read that too.
[12:51] <cjwatson> flexiondotorg: the problem with them is that it is extremely difficult to cause them to be in sync with the output of apt
[12:51] <cjwatson> flexiondotorg: so no, I don't think you're right
[12:51] <flexiondotorg> I'm trying to understand if they actually work at all.
[12:52] <cjwatson> flexiondotorg: their only useful purpose is to cause a hard error if something sneaks in that definitely shouldn't
[12:52] <flexiondotorg> I've seen Xubuntu and Ubuntu MATE are trying to use blacklist to prevent unnecessary Recommends: gettings seeded.
[12:52] <cjwatson> flexiondotorg: please don't waste much time investigating them, 99% of attempts to use them are wrong
[12:52] <flexiondotorg> gnome-user-guide for example.
[12:52] <flexiondotorg> I've been filing merge proposals to fix some of the at source.
[12:53] <cjwatson> yeah that's really what you have to do
[12:53] <flexiondotorg> But still puzzled what blasklist does, versus what it is intended to do.
[12:54] <flexiondotorg> What do you mean by "hard error"? Where would that be visible?
[12:55] <flexiondotorg> cjwatson, I'm trying to make Ubuntu MATE seeds follow recommends, mostly to ensure the live seed never breaks. Which is has in the past.
[12:56] <cjwatson> Sorry, I can't really remember the details right now
[12:56] <cjwatson> The blacklisting support was added in order to be able to ensure that libavcodec never got onto Ubuntu images
[12:56] <flexiondotorg> But I would actually like the desktop seed to no-follow-recommends.
[12:56] <flexiondotorg> Can I just add  * Feature: no-follow-recommends to the desktop seed?
[12:57] <cjwatson> I suspect it's not actually a germinate-level error, but it results in incomplete images that are uninstallable (because it just ignores that bit of the dependency tree)
[12:57] <cjwatson> I never bothered to gold-plate it very much
[12:57] <flexiondotorg> Or does it also require "feature no-follow-recommends" in STRUCTURE?
[12:57] <cjwatson> flexiondotorg: You *must* keep that in sync with how livecd-rootfs builds your image
[12:57] <cjwatson> You will get very very very confused if it's not in sync
[12:58] <cjwatson> flexiondotorg: "feature no-follow-recommends" in STRUCTURE doesn't do anything
[12:58] <flexiondotorg> cjwatson, Good to know.
[12:58] <flexiondotorg> So if I want one seed to not follow recommends is that possible?
[12:59] <cjwatson> At the germinate level, yes; but as I say, you must keep that in sync with what apt is going to do.
[12:59] <cjwatson> Think of germinate sort of like a cheap apt simulator.
[13:00] <cjwatson> So you should first look at whether you can implement what you're asking for in livecd-rootfs when it builds the image, and then look at keeping the seeds in sync with that.
[13:00] <flexiondotorg> cjwatson, livecd-rootfs for Ubuntu MATE does currently instruct apt to not follow recommends.
[13:00] <flexiondotorg> Not sure if that is for all seeds?
[13:00] <cjwatson> I don't know, you'll have to work that out.
[13:00] <flexiondotorg> cjwatson, OK, thanks for the time.
[13:01] <flexiondotorg> I think I've learned the Blacklists won't do what I require.
[13:01] <cjwatson> It can be difficult to make that per-seed.
[13:01] <cjwatson> Because apt doesn't really know about seeds, so things may get confusing on upgrade.
[13:01] <flexiondotorg> I'll test desktop seed not following recommends.
[13:01] <flexiondotorg> OK. I'll give it a good test.
[13:01] <flexiondotorg> See what works.
[13:01] <cjwatson> Remember that when you upgrade a system it's going to upgrade (say) ubuntu-standard and ubuntu-mate-desktop at the same time, and follow recommends for either both or neither.
[13:02] <flexiondotorg> Right.
[13:02] <flexiondotorg> Understood.
[13:02] <cjwatson> This is why I think that attempts to tweak Recommends following on a per-flavour basis are mostly doomed to eventual failure.
[13:02] <cjwatson> Even if it doesn't seem so at first.
[13:02] <cjwatson> So you *can* do it, but you have been warned :-)
[13:02] <flexiondotorg> Warning heeded.
[13:03] <flexiondotorg> The objective is to get everything in Ubuntu MATE following recommends.
[13:03]  * cjwatson nods
[13:03] <cjwatson> Good good
=== _salem is now known as salem_
[13:33] <kgunn> stgraber: hey there, i know you solved the xenial boot on phone lxc issue...just wanted to check, where we need to track the change?
[13:33] <kgunn> assuming it was prollly specific to android lxc
[13:53] <happyaron> infinity: mind to accept the network-manager-applet SRU to -proposed? version 1.2.0-0ubuntu0.16.04.3
=== alvesadrian is now known as adrian
[14:02] <cpaelzer> rbasak: fortunately the tests worked in containers (my uvt-kvm has issues recently)
[14:02] <cpaelzer> rbasak: the good thing, it unveiled the debdiff was incomplete - there were even more file moves than reported in the bug :-)
[14:03] <cpaelzer> rbasak: integrated in the next debdiff and a reproducible testcase available now
[14:03] <cpaelzer> rbasak: thanks for your help with the local repo and normal upgrade instead of do-release-upgrade path
[14:05] <smoser> doko, thank you for fix to bug 1584147. it seems fixed on my end.
[14:05] <ubottu> bug 1584147 in python3.5 (Ubuntu) "cloud-init hangs on boot as Python waits for sufficient randomness to start" [High,Confirmed] https://launchpad.net/bugs/1584147
[14:08] <smoser> pitti, ^ fyi
[14:09] <infinity> tdaitx: FWIW, the bug you want to file is actually https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811181 (ie: it's already filed)
[14:09] <ubottu> Debian bug 811181 in apt "apt: Please document auth.conf" [Wishlist,Open]
[14:10] <infinity> tdaitx: You want /etc/apt/auth.conf with a format like "machine ppa.lp.net/foo/bar/ubuntu\nlogin username\npassword 12345"
[14:10] <infinity> tdaitx: Then your sources.list can drop the creds and be 644.
[14:16] <pitti> smoser: yes, I noticed; I also stopped getting "instance timed out waiting for ssh" worker death mails \o/
=== salem_ is now known as _salem
[15:07] <stgraber> kgunn: it's just one file that needs to be updated in the lxc-android-config package and uploaded to the archive, looked like someone was tracking this in the bug report
[15:07] <kgunn> excellent and thanks for the help stgraber
[15:10] <stgraber> np, glad that we finally got to the bottom of this one
[15:31] <nacc> rbasak: just an fyi, the upload of phpunit-mock-object is a 'known-to-fail' build due to needing to bootstrap. So the merge is still good, in case you were wondering.
[15:39] <rbasak> nacc: I thought it might be something like that. Thank you for confirming.
[15:45] <nacc> rbasak: np, sorry for not warning you ahead of time
[15:50] <nacc> infinity: --^ so the version of phpunit-mock-object has been uploaded to proposed. Not sure if you got a chance to look at the bootstrap yet.
[17:28] <nacc> infinity: slangasek: let me know if either of you are able to look at that bootstrap request for phpunit. I assume it requires an AA to do it.
[17:33] <nacc> Logan: in case you missed it, I figured out last week what's needed to get phpunit (php-codecoverage/phpunit-mock-object) working. It requires a bootstrap build in the archive of those three packages.
=== afkthairus is now known as athairus
[19:40] <nacc> infinity: slangasek: fwiw, I filed LP: #1592139 to keep track of it (for myself)
[19:40] <ubottu> Launchpad bug 1592139 in phpunit-mock-object (Ubuntu) "Please bootstrap build phpunit, phpunit-mock-object and php-codecoverage" [Undecided,New] https://launchpad.net/bugs/1592139
[19:41] <nacc> cjwatson: --^ i did subscribe ~ubuntu-archive to that bug, because I believe I need an AA to help out. Not sure if that's appropriate or not, please CMIIW
[19:41] <nacc> cjwatson: only directing at you, as you're listed as the owner of said group :)
[19:42] <cjwatson> Yeah, it's appropriate
[19:42] <cjwatson> If nobody else gets round to it first then I'll do the bootstrap tomorrow
[19:42] <nacc> cjwatson: ok, thanks -- didn't find much documentationa about this specific case
[19:42] <cjwatson> I suspect it is entirely in a few people's heads
[19:42] <nacc> cjwatson: thanks! i know folks are sprinting and such, but this will hopefully clear up a bunch of php* stuff in -proposed
[19:42] <cjwatson> I'm not sprinting, so :)
[19:43] <nacc> :)
[19:43] <cjwatson> (But I am on vacation today, so on principle I should leave it till tomorrow ...)
[19:43] <nacc> cjwatson: totally fine by me
[19:43] <tsimonq2> I have a question relating to the chromium-browser package, it is currently FTBFS, but there has been an upstream release. Would it be appropriate to update to the upstream release, then see if there is still an FTBFS, if not, then ask for that to be sponsored? Or should the FTBFS be fixed, then the upstream release?
[19:44] <tsimonq2> but in Debian, the chromium package is updated to where it needs to be
[19:45] <tsimonq2> I don't know if it comes from Debian, if so, I'll update the Ubuntu package with Debian revisions
[19:45] <tsimonq2> thoughts?
[19:45] <dobey> tsimonq2: i think you need to talk to qengho on #ubuntu-desktop
[19:46] <tsimonq2> dobey: okay, thank you
[19:46] <dobey> i think he's still the one doing chromium related stuff
[19:52] <nacc> tsimonq2: reading the launchpad page(s) and rmadison output, it seems like yakkety needs either a merge or sync by someone
[19:52] <nacc> tsimonq2: as debian is currently at 51.0.2704.79-1 and yakkety-proposed is at 50.0.2661.102-0ubuntu1.1242
[19:53] <tsimonq2> yeah
[19:55] <nacc> tsimonq2: but yeah, it seems like qengho was TIL, so that's probably the right place to start, might just need a re-merge if that FTBFS has already been fixed.
[19:55] <tsimonq2> nacc: well it builds fine in Debian, so maybe :)
[19:55] <jbicha> tsimonq2: chromium in Debian and chromium in Ubuntu are managed rather differently; they aren't kept in sync at all
[19:55] <tsimonq2> oh really jbicha? how so?
[19:55] <nacc> that's what i was going to ask next
[19:55] <nacc> tsimonq2: all the ubuntu versions have -0ubuntu suffixes
[19:56] <jbicha> you should probably talk in #ubuntu-desktop about that...
[19:58] <elbrus> nacc: autopkgtest for cacti on armhf improved a tiny bit. At least you can now see in the artifacts that apache crashes.
[19:58] <elbrus> *** Error in `/usr/sbin/apache2': double free or corruption (fasttop): 0xb7359660 ***
[19:58] <elbrus> [Mon Jun 13 02:22:16.497596 2016] [core:notice] [pid 13694] AH00052: child pid 13699 exit signal Aborted (6)
[19:59] <nacc> elbrus: heh, cool -- any ideas why? (haven't looked yet myself)
[19:59] <elbrus> nacc: lots of php timeouts before that.
[19:59] <nacc> elbrus: looking
[19:59] <elbrus> so I suspect the server is overloaded
[20:00] <nacc> elbrus: yeah, and the armhf machine maybe slower anyways, so i wonder if that 30s timeout is appropriate
[20:00] <nacc> might just need to be a known-bad test on armhf, as it is marked now (for php7.0)
[20:00] <elbrus> well, that is the default I guess
[20:01] <elbrus> should I try to increase the timeout then (on armhf?)
[20:01] <elbrus> going to be ugly...
[20:01] <nacc> i'm honestly not sure; it seems like that might fix things, but it feels super-hacky
[20:01] <elbrus> indeed
[20:01] <nacc> and might end up masking a real error eventually
[20:01] <elbrus> but it succeeded in the past
[20:01] <nacc> yeah, i wonder what changed, if anything, with the machine
[20:02] <elbrus> maybe just more used
[20:03] <elbrus> any idea who to ask to have a look? pitti?
[20:03] <dosaboy> bdmurray: is there anything i need to do to get this moving - https://bugs.launchpad.net/ubuntu/+source/python-os-brick/+bug/1521396
[20:03] <ubottu> Launchpad bug 1521396 in python-os-brick (Ubuntu Wily) "[SRU] Fix iopsLimit parameter in ScaleIO connector" [Medium,New]
[20:03] <nacc> elbrus: i was just thinking about that ... not sure
[20:07] <bdmurray> dosaboy: looking
[20:10] <bdmurray> dosaboy: accepted it
[20:11] <dosaboy> bdmurray: \o/
[20:11] <dosaboy> thanks
[20:21] <Logan> nacc: figured as much - best of luck!
[20:22] <tsimonq2> !info snapd yakkety
[20:22] <ubottu> snapd (source: snapd): Tool to interact with Ubuntu Core Snappy.. In component main, is optional. Version 2.0.2 (yakkety), package size 2745 kB, installed size 14700 kB
[20:22] <tsimonq2> !info snapd xenial-updates
[20:22] <ubottu> 'xenial-updates' is not a valid distribution: kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-proposed, unstable, utopic, utopic-backports, utopic-proposed, vivid, vivid-backports, vivid-proposed, wily, wily-backports, wily-proposed, xenial, xenial-backports, xenial-proposed, yakkety, yakkety-backports, yakkety-proposed
[20:22] <tsimonq2> !info snapd xenial
[20:23] <ubottu> snapd (source: snapd): Tool to interact with Ubuntu Core Snappy.. In component main, is optional. Version 2.0.8 (xenial), package size 3581 kB, installed size 17156 kB
[21:23] <nacc> Logan: thanks :)
[21:28] <juliank> infinity: Around? I'm preparing for the apt 1.2.13 xenial SRU. I unfortunately forgot to open a SRU placeholder bug and reference it in the changelog, so we cannot sync this way, but there's #1573547 that we could reuse as the SRU tracking bug (it's the only bug in launchpad closed by the upload anyway). Opinion?
[21:29] <juliank> Probably should sync 1.3~exp2 to yakkety first, though :/
[21:29]  * juliank wishes apt would autosync from experimental if available
[21:42] <juliank> I now updated bug 1573547 to include the SRU part, makes more sense than to create another bug and makes the uploading easier :)
[21:42] <ubottu> bug 1573547 in apt (Ubuntu) "Apt's bash completion is incomplete" [Low,Fix committed] https://launchpad.net/bugs/1573547
[21:44] <juliank> APT yakkety sync: bug 1592171
[21:44] <ubottu> bug 1592171 in apt (Ubuntu) "Sync apt 1.3~exp2 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1592171
[21:49] <juliank> I feel like requestsync does not work well for syncing as an SRU
[21:49] <juliank> It would just create a "Sync apt 1.2.13 (main) from Debian unstable (main)" subject, and the only place it mentions xenial is in "Changelog entries since current xenial version 1.2.12~ubuntu16.04.1"
[21:50] <juliank> I feel like that would just confuse people and end up with them trying to sync 1.2.13 to yakkety