[04:00] <infinity> Logan:  http://launchpadlibrarian.net/275043606/funny-manpages_1.3-5.1ubuntu1_1.3-5.1ubuntu2.diff.gz <-- What's wrong with this diff? ;)
[04:47] <infinity> pitti: amd64 autopkgtest queues seem stuck.
[05:19] <infinity> pitti: Oh, lcy01 is completely dead.  If amd64 autopkgtest uses that region exclusively, that would explain the stall.
[05:21] <infinity> pitti: And while I'm pinging you, there seem to be a mess of trusty langpacks sitting in the queue.  I kinda assumed you'd be dealing with those. :)
[05:51] <pitti> infinity: yes, Qt 5.6 + dead lcy01 == tests take forever..
[05:51] <pitti> infinity: oh, I thought I accepted all trusty langpacks
[05:51] <pitti> infinity: sorry, will process the rest
[05:59] <pitti> infinity: meh, the cleanup/restart script stumbled over "nova list" failing; fixed that now, so the other clouds keep running
[06:41] <infinity> pitti: Seemed curious to me that the i386 queue emptied before the amd64 one.  I would have expected them to drain in parallel.
[06:42] <infinity> pitti: We were very careful about this with shared queues in lp-buildd land, FWIW, to make sure that, all things being vaguely equal, upload 1 would get all its builds out before upload 2, etc.
[06:42] <pitti> infinity: britney issues the requests in architecture order, so i386 is always a bit ahead indeed
[06:42] <pitti> maybe this could use some more shuffling
[06:42] <pitti> the main source of imbalance is the retry-autopkgtest-regressinos script though
[06:43] <infinity> pitti: Ahh, see, I'd expect "testing foo triggered by bar" would queue foo/trigger on all arches, then move to quux/trigger all arches, etc.
[06:43] <pitti> that generates stuff sorted by architecture first
[06:43] <infinity> pitti: So, for shared pool arches, they'd together.
[06:43] <infinity> Ish.
[06:43]  * infinity shrugs.
[06:43] <pitti> britney is per-excuse first, then per architecture, then all the triggered tests for that excuse
[06:43] <infinity> pitti: Minor frustration to be waiting on one arch column for all packages instead of two arch columns for half the packages.
[06:44] <pitti> yes, indeed; but it's not nearly as bad
[07:21] <infinity> pitti: Oh, not sure if I told you, but mvo and I sat down and fixed snapd autopkgtests.
[07:21] <infinity> pitti: I'm waiting to see the results on amd64 before I close LP: #1599799 but the successes on i386 and ppc64el look promising.
[07:28] <mwhudson> ooh
[07:29] <mwhudson> infinity: what was the problem?
[07:29] <pitti> nice!
[07:29] <infinity> mwhudson: Exactly what they error message no one read said the problem was.
[07:29] <infinity> (They created new units and didn't run daemon-reload)
[07:29] <mwhudson> heh
[07:30] <mwhudson> i did _ask_ about that
[07:30] <mwhudson> but i didn't check
[07:30] <infinity> I consider it a pretty glaring misfeature in systemd that they wrote a *Linux-specific* init system and didn't think to, I dunno, leverage inotify correctly.
[07:30] <infinity> But whatever.
[07:30] <infinity> The number of times we reload that daemon to clear the cobwebs from its internal state is insane.
[07:30] <pitti> this wasn't the error I saw in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799/comments/12
[07:30] <pitti> basic-binaries.block[12533]: unable to bind /snap/ubuntu-core/current//bin to /bin. errmsg: Permission denied
[07:31] <pitti> that wasn't a missing daemon-reload
[07:31] <mwhudson> i think that one was a snap-confine bug
[07:31] <infinity> Yeah, different bug than the one originally reported.
[07:31] <infinity> But both seem fixed.
[07:32]  * pitti stares at the autopkgtest queue and o_O's
[07:32] <pitti> ooh, new perl
[07:32] <infinity> Yeah.
[07:33] <infinity> I shouldn't have retried the arm64 build. ;)
[07:33] <infinity> Now I have no chance of getting my own retries in.
[07:33] <infinity> Oh well.
[07:33] <pitti> infinity: if it's blocking, I can remove all the perl tests and we re-trigger them later
[07:33] <infinity> pitti: Shouldn't be.  I'm just waiting for the snapd/amd64 result, which is currently in limbo.
[07:34] <infinity> pitti: If it comes back successful, I'm happy.
[07:34] <pitti> weird, it hasn't run yet and it's not in the queue
[07:34] <infinity> It disappeared from the queue about 10m ago.
[07:34] <infinity> I assumed that meant it would, I dunno, run.
[07:34] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety?format=plain&prefix=yakkety/amd64/s/snapd
[07:34] <pitti> nothing from today yet
[07:35] <pitti> I suppose an lcy01 worker tried to catch it and is now caught in its "retry three times until I give up" loop or so
[07:35] <infinity> What happend after that?  End of the queue, or punted to another builder, or dropped on the floor?
[07:35] <pitti> ah no, it's working
[07:35] <pitti> err, running
[07:35] <infinity> s/happend/happens/
[07:36] <pitti> it just doesn't show on running.shtml for some reason
[07:36] <infinity> Because running.shtml is 10m old?
[07:36] <infinity> Err.
[07:36] <infinity> Older.
[07:36] <infinity> 18m.
[07:36] <pitti> 18 mins
[07:38] <infinity> pitti: I'm curious why the debci pages are static generated instead of cgi.  Just trying to be load-friendly?
[07:39] <pitti> infinity: I suppose so; it's quite expensive to generate them, as it shows the entire history of a package
[07:39] <infinity> pitti: Hrm.  But, it seems to generate them even when it doesn't have to, so I'm not sure I buy the load argument now. ;)
[07:40] <infinity> pitti: Picking, say, http://autopkgtest.ubuntu.com/packages/p/postgresql-9.5/ at random, no tests run for two days, but page generated 15m ago.
[07:40] <pitti> well, I don't know :)
[07:41] <infinity> pitti: Given the relative infrequency of tests, it would seem smarter to do a shallow "when was the last test run?" compare to a timestamp of a cached earlier-generated page, serve from cache if not stale, generate on the fly if stale.
[07:41] <infinity> Ish.
[07:42] <pitti> infinity: I can't say I like the current design either; it creates literally millions of little files which keeps hitting the "max inodes" ceiling
[07:42] <pitti> and it's expensive to generate indeed
[07:42] <infinity> xfs to the rescue?
[07:42] <pitti> but yeah, it was that or "write it yourself" :)
[07:43] <infinity> I'd have been inclined to write it as a perl/python/php/cgi/whatever and dynamically generate the mess from a DB.  But that probably says more about my background than my taste.
[07:45] <pitti> infinity: I think excuses.html is the main thing devs should look at (and it's completely independent of debci); other than that, I could cobble together a simple CLI thing to query past results, but I'm afraid I'm too loaded with other stuff to rewrite a web UI :/
[07:45] <infinity> pitti: Heh, I'm not suggesting you fix it, just making idle banter.
[07:45] <infinity> pitti: Besides, every page does point me at the git repository, if it really pisses me off enough.
[07:46] <infinity> pitti: Not that I'd go replacing the backend, ain't no one got time for that, but fixing the caching mechanism to not be constantly uselessly stale wouldn't be too hard.
[07:46] <pitti> infinity: it actually would be -- this would be changing the thing from the ground up
[07:46] <infinity> (Though, as it scales up, replacing the backend with a proper DB seems sane)
[07:47] <pitti> infinity: so, I don't think there's any way around downloading the entire metadata from swift as that takes an awful amount of time
[07:47] <pitti> but generating html and the indexes dynamically would be great indeed
[07:47] <pitti> right, sqlite or so would certainly beat individual files :)
[07:47] <mwhudson> i'm sure there's some shiny nosql db we could use
[07:48] <infinity> I need to read up on nosql stuff to understand why I'm supposed to like it.
[07:48] <infinity> THere's enough psql deployed in Debian and Canonical that that would have been my first choice.
[07:48] <pitti> infinity: no prob to add psql to the charm for sure
[07:51] <infinity> pitti: But, in the current architecture, the obvious fix would be to trigger page generation on incoming scraped results, rather than batch regenerating the world on a timer.
[07:52] <infinity> "Oh look, a psql result" -> regen psql page.
[07:52] <infinity> As it is, it does ALL the pages.
[07:52] <infinity> Which is daft.
[07:54] <pitti> infinity: so if we can talk slangasek into allocating three days for that, we should invite terceiro and fix this up properly
[07:54] <pitti> infinity: I know terceiro has also hit the inode limit, and I'm sure the load on ci.debian.net is similarly high
[07:56] <infinity> pitti: Hahaha.  That reminds me.
[07:56] <pitti> infinity<EMAIL_ADDRESS>[07:56] <pitti> PASS
[07:56] <infinity> pitti: ci.ubuntu.com still has a link in the top bar ([Proposed]) to the old jenkins-driven autopkgtest infra.
[07:56] <infinity> pitti: Who owns that?
[07:56] <infinity> pitti: It should point to autopkgtest.ubuntu.com, probably.
[07:57] <pitti> uh, oh, look behind! a three-headed monkey!
[07:57] <pitti> jibel: do you know who owns http://ci.ubuntu.com/ ?
[07:57] <infinity> pitti: And yay on the pass!
[07:57] <pitti> this looks so out of date, I doubt it's still useful at all
[07:59] <infinity> pitti: Hrm, indeed.  http://ci.ubuntu.com/smokeng/ seems to stop at wily.
[08:10] <infinity> pitti: How did the user session sprint go?
[08:10] <infinity> pitti: Will we reduce 'reverse-depends upstart' to zero by release?
[08:10] <infinity> Well, zero except for the things with 'upstart' in the name. :P
[08:10] <pitti> infinity: yes, we should; with the PPA the only thing that still needs it is the lightdm unity greeter session, which isn't too hard to fix
[08:11] <pitti> infinity: we converted most things and they are currently being landed
[08:11] <infinity> pitti: Awesome.
[08:11] <pitti> there's a big CI train silo, and landing gnome-session/xubuntu-default-settings etc. is blocked on landing upstart in -proposed and systemd 231-1
[08:12] <infinity> upsart seems to just be waiting on autopkgtests.
[08:12] <pitti> which is in turn blocked by apparmor in -proposed and the new mdadm xnox is working on (although if that doesn't happen soon enough it's simple enough to upload a workaround in systemd itself until that happens)
[08:12] <pitti> so, just a few days unti the dust settles
[08:12] <infinity> Though, I'm suspicious that the upstart autopkgtests may have disappeared.
[08:13] <infinity> Since I don't buy that the ppc64el tests have been "in progress" since yesterday.
[08:13] <pitti> infinity<EMAIL_ADDRESS>[08:13] <pitti> apt segfault and corrupted cache, I retried it this morning
[08:13] <pitti> before the perl flood I think
[08:13] <pitti> anyway, I have an eye on it
[08:21] <jibel> pitti, no idea, it used to be ev's team
[09:56] <Oni_Shadow> G'day, I am runnig ubuntu-devel since it's availibilyty and have a quite nasty package dependency I do not know how to solve...
[09:56] <Oni_Shadow> (it there the right place?)
[09:57] <nacc> Oni_Shadow: what is "ubuntu-devel"?
[09:57] <Oni_Shadow> my unity8 session was uninstalled by last upgrade and I did not pay attention and now, everything qt related cannot be installer because of unmet dependency whilst my package system is not broken
[09:57] <nacc> Oni_Shadow: do you mean 16.10?
[09:57] <Oni_Shadow> well devel is a codenam for developement i suppose that points on the lastest nightly builds, currently yaketty.
[09:58] <nacc> Oni_Shadow: you want #ubuntu+1
[09:58] <Oni_Shadow> I just want to get qt stuff (like unity8 and konversation) installable again
[09:58] <Oni_Shadow> on my ubuntu-devel machine
[09:58] <nacc> Oni_Shadow: right, ask in #ubuntu+1
[09:59] <nacc> Oni_Shadow: this channel is for development of Ubuntu itself (see /topic)
[09:59] <Oni_Shadow> ok cheers !
[09:59] <Oni_Shadow> sorry about that then
[10:15] <juliank> pitti: Did you have time to look at the apport autopkgtest failure yet? I don't really have much time at the moment, but I definitely need to get the apt 1.3 stuff in; and apport fails (and click and ubuntu-make fail for the fixed python-apt - which is likely not my fault, as I only made python-apt work with the new apt)
[10:16]  * juliank is supposed to hand in some master thesis plan soon, otherwise he would have more time to look at things
[10:16] <juliank> GPG error: http://ddebs.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C8CAB6595FDFF622
[10:16] <juliank> that's the apport failure
[10:17] <juliank> It does say freeze now, I suppose that's for the alpha 2s tomorrow?
[10:18] <juliank> click just says: "Cannot install /tmp/tmpv7h7mjfk/org.example.debsig-valid-sig_1.0_all.click: Signature verification error: debsig: No applicable policy found." - Not sure what the problem is there
[10:19] <juliank> And ubuntu-make has some jquery coverage issues
[10:19] <juliank> "Couldn't find static file 'jquery.ba-throttle-debounce.min.js'"
[10:36] <pitti> juliank: no, I didn't, sorry; not sure why the new apt doesn't accept the signature, does ddebs.u.c. need to chagne its archive layout somehow?
[10:36] <juliank> pitti: I'm not sure what's going on on ddebs, I thought you might know more. DonKult flipped the switch to treat the warnings as errors in the new release, that's all I know
[10:37] <juliank> Then again, signature ver. issues should have been errors before too
[10:38] <pitti> juliank: indeed, like in<EMAIL_ADDRESS>[10:38] <pitti> it's a  warning there
[10:39] <juliank> right.
[10:39] <juliank> that's the add repository, install keyring, update again scenario
[10:39] <juliank> That now requires --allow-insecure or --allow-unauthenticated
[10:39]  * juliank is never sure which is whicht
[10:40] <juliank> (or [allow-insecure=true] in the sources.list)
[10:41] <pitti> juliank: do you know about the python-apt failure?
[10:41] <juliank> this one is easy to fix then. the click and ubuntu-make regressions are far more annoying, as they are completely unrelated to the python-apt upload that triggered them
[10:42] <pitti> I'll put the apport thing on my TODO list
[10:42] <juliank> pitti: the python-apt failure is fixed (should be at least, maybe there's some stderr output I need to get rid of), but the new python-apt is prevented from migrating by click and ubuntu-make which went rogue on their own
[10:43] <juliank> That is, they also fail for other test suite triggers
[10:43] <pitti> right
[10:43] <pitti> so, fine for me to ignore these two
[10:44] <pitti> juliank: for now I'll requeue a retry of proposed python-apt against proposed apt, that should clear up that part
[10:45] <pitti> juliank: will take a bit though, look at the queues on http://autopkgtest.ubuntu.com/running.shtml :/
[10:45] <juliank> OK
[10:47] <pitti> juliank: p-apt hinted, p-apt for apt retried
[10:48] <xnox> pitti, infinity - can one emulate ppc64el on non-ppc64el hardware? or how do i get my hands onto such a system? need to debug claims that installing with btrfs as root, does not work on ppc64el.
[10:48] <pitti> oh, so a cloud instance won't do for that
[10:49] <pitti> nested qemu perhaps
[10:49] <pitti> (on a cloud instance)
[10:51] <infinity> xnox: You can emulate, yes.
[10:52] <infinity> xnox: It's not fast, mind you.
[10:52] <infinity> xnox: qemu-system-ppc64 -M pseries
[10:52] <infinity> xnox: Or ask slangasek how to get at real hardware, where you can add --enable-kvm to that and not hate yourself. ;)
[10:53] <xnox> in virtmanager i do get architecture ppc64le and pseries option. let me see if i can boot that at all.
[10:53] <xnox> asks for an iso image
[10:54]  * xnox goes to get coffee whilst download is in progress. 90s left.
[10:58] <xnox> fonts look odd but it seems to be working
[10:58] <infinity> xnox: Emulating video too?  Brave.
[10:59] <infinity> xnox: I'd have opted for qemu-system-ppc64 -M pseries -m 2G -vga none -nographics -hda foo.img -cdrom ubuntu.iso
[10:59] <xnox> using defaults in libvirt
[10:59] <infinity> xnox: And just enjoy the text.
[10:59] <infinity> libvirt and I don't get along.
[11:00] <xnox> i think video crashes.
[11:00] <davmor2> testing123
[11:01] <infinity> s/nographics/nographic/
[11:01] <xnox> serial looks better.
[11:01] <davmor2> wrong window ah that's better now it pings me in pm
[11:02] <xnox> i get kernel panic trying to boot of yakkety-server.iso and it goes into reboot loop =(
[11:02]  * xnox tries xenial
[11:05]  * infinity gets 12MB/s from cdimage, and wonders if this is a sign of the apocalypse.
[11:07] <xnox> qemu-system-ppc64le -M pseries -cdrom yakkety-server-ppc64el.iso -m 2048 -nographic
[11:07] <xnox> doesn't get me d-i :-(
[11:10] <infinity> emu-system-ppc64 -M pseries -cpu POWER8 -m 2G -vga none -nographic -hda disk.img.server -cdrom ubuntu-16.04.1-server-ppc64el.iso
[11:10] <infinity> xnox: -cpu needs to be POWER8, we don't support lower.  Also, -vga none is a good idea if you're -nographic.
[11:10] <infinity> (The above worked for me here)
[11:11] <xnox> that got me grub
[11:11] <infinity> yakkety boots with that commandline too.
[11:11] <infinity> But yeah.  It ain't quick.
[11:11] <xnox> i see d-i \o/
[11:12] <infinity> Be prepared for some very slow menu transitions.
[11:12]  * infinity goes to bed.
[11:46] <smoser> rbasak, thanks for your help yesterday.
[11:47] <smoser> xnox, 'xkvm' from curtin makes the qemu cmdline easier.
[11:47] <smoser> and should pretty easily dtrt for power
[11:47] <smoser> rbasak, so Fixes LP: #bug1, bug2
[11:47] <smoser> or Fixes LP: #bug1, #bug2
[11:51] <rbasak> smoser: any need for "Fixes"?
[11:52] <smoser> there is not.
[11:52] <smoser> maybe Fixes-bug:
[11:52] <smoser> it isnt necessary, but it seems reasonable to put sanely formated data.
[11:53] <smoser> maybe i should just accept arbitrary string searching
[11:53] <smoser> from
[11:53] <smoser>  zgrep -E LP: /usr/share/doc/*/changelog.Debian.gz | grep -e "#[0-9]\+[ ]*[ ,]\+[#*][0-9]\+"
[11:53] <smoser> it seems like LP: #NN, #NN
[11:53] <smoser> is pretty common in changelogs
[11:53] <smoser> so for multiple bugs i'll do
[11:53] <smoser> LP: #BUG, #BUG
[11:53] <cjwatson> Both '#' characters are necessary, yes.
[11:53] <rbasak> The problem is that you're making something up that is likely to be non-standard.
[11:54] <rbasak> You say Fixes, someone else says Closes, etc. So I don't think you get any benefit there unless someone defines something.
[11:54] <rbasak> I'd just put "LP: #NNN" on a line on its own.
[11:54] <cjwatson> It's still not absolutely settled what Launchpad will recognise, but if it's anything like the changelog syntax then it will likely be exactly the same as the changelog syntax, not a slight variant of it.
[11:55] <rbasak> (or "LP: #XXX, #YYY" of course)
[11:56] <rbasak> The nice thing about that is that it also matches the pseudo-header syntax that others tend to use.
[11:56] <smoser> well, because i'm in the position where i can actually make consistency for this, it seems better to do it.
[11:56] <rbasak> You can't make consistency for this.
[11:57] <rbasak> You'll end up with a history that does one thing, and a future that potentially does something else.
[11:57] <smoser> i surely can for my repo.
[11:57] <rbasak> Or, if you stick to the same thing, you'll have cloud-init doing a special thing that no other repo does, which will be confusing for contributors.
[11:57] <rbasak> I'm just saying that you shouldn't arbitrarily invent anything here.
[11:59] <smoser> the thing i'm bothered by is that 'LP: #XXX' does not differenciate from Fixes LP: #XXX and 'this is fallout of a fix for LP: #XXXX'
[11:59] <nacc> the latter is not correct syntax
[11:59] <nacc> aiui
[11:59] <rbasak> debian/changelog has the same issue. You can't fix it by adding "Fixes LP". The regexp that Colin proposed will still match it.
[11:59] <nacc> it should be LP #XXXX in that case
[11:59] <nacc> LP: is "special"
[11:59] <cjwatson> The traditional approach in changelogs is as nacc says.
[12:00] <cjwatson> It's maybe not ideal, but it's pretty established.
[12:00] <rbasak> "Fixes LP" also breaks the RFC822-style headers the git community tends to use.
[12:00] <xnox> oh wow.
[12:00] <smoser> Fixes: LP: # does not.
[12:01] <rbasak> It might be worth looking into whether git-dch can parse that.
[12:02] <rbasak> I know it parses "LP: #XXX" on a line on its own fine.
[12:02] <smoser> alright. i'll go with just LP: # as new line.
[12:03] <rbasak> Thanks. I feel that this has the most potential to become a future de facto standard.
[13:25] <semiosis> Odd_Bloke: i see bug 1565985 is filed in this week's milestone for cloud-images.  does that mean that the yakkety images will start to be built with the fixes soon?
[14:33] <smoser> rbasak, so.. i tried that mono bzr fast-export rewriter... had issues.
[14:33] <smoser> i could not get it to work for me
[14:33] <smoser> however, this does work:
[14:33] <smoser>  http://paste.ubuntu.com/21144779/
[14:33] <smoser> and seems much better sutied for the task. ie, i just modified fastexport in bzr to update the messages.
[14:35] <rbasak> smoser: seems reasonable
[14:35] <rbasak> smoser: it might be sensible to send that upstream, too. Though your code is a little hacky IMHO.
[14:56] <LocutusOfBorg> can anybody please try to clean ppc64el builders space?
[14:56] <LocutusOfBorg> objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN[.rodata]: No space left on device
[14:56] <LocutusOfBorg> objcopy:./usr/lib/python2.7/dist-packages/itk/st93riGN: No space left on device
[14:56] <LocutusOfBorg> or should I do something else
[14:57] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-1ubuntu1/+build/10520384
[15:03] <smoser> rbasak, agreed on both counts. hacky and would be nice to have that as an option.
[15:03] <smoser> you'd have to provide some option for how to translate some template or something.
[15:05] <rbasak> smoser: IMHO, for the sake of consistency there shouldn't be a configurable template option. Just do the one thing one way.
[15:09] <Odd_Bloke> semiosis: The next yakkety build should have them.
[15:09] <Odd_Bloke> semiosis: (Thanks for the ping though, I'd forgotten to push a button)
[15:12] <smoser> rbasak, but there are different bug sources
[15:12] <smoser> not everyone uses launchpad
[15:12] <smoser> i know, its hard to believe :)
[15:13] <rbasak> smoser: sure, but the bzr metadata knows the bug source, right? So it wouldn't need to be configurable, just individual support in the code.
[15:13] <smoser> well, sort of
[15:13] <smoser> bzr knows the bug url
[15:13] <smoser> so it could quite easily do:
[15:14] <smoser> fixes-bug: bugurl
[15:14] <smoser> fixes-bug: bugurl2
[15:14] <smoser> but extracting the bug number out of any bug systems url is more complex.
[15:14] <smoser> and that assumes good data in those urls
[15:14] <smoser> consistent url formats across every committer
[15:18] <dobey> well, it's easy enough for launchpad to handle launchpad bug urls
[15:18] <dobey> beyond that, you just have a url which is generally good enough
[15:19] <dobey> see url, click url, get bug
[15:22] <dobey> *** Error in `/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner': free(): invalid pointer: 0x01f5c390 ***
[15:22] <dobey> well, that sucks
[15:23] <dobey> oops
[15:34] <bregma> have the main inclusion requirements as documented in https://wiki.ubuntu.com/UbuntuMainInclusionRequirements changed?  In particular, are build-deps still required to be in main, or was that not recently relaxed?
[15:36] <jbicha> bregma: universe b-depends are ok now: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html
[15:36] <bregma> I ask because I'm looking at having to MIR 114 packages to get Unity 8 into main *without* the build-deps
[15:37] <bregma> jbicha, what about packages needed only for running autopkgtests?
[15:37] <jbicha> that's a good email list to subscribe to if you don't already
[15:37] <pitti> bregma: test dependencies can come from any component
[15:38] <bregma> I'm subscribed, so I was peripherally aware of the change but the wiki documentation is not up to date
[15:40] <dobey> build-deps are ok being in universe, if they don't create binary deps on things in universe
[15:48] <semiosis> Odd_Bloke: glad to hear it.  thank you!
[16:30] <mterry> @pilot in
[17:56] <mterry> jamespage, in pacemaker 1.1.14~rc4-2ubuntu1 for 16.04, you wrote "d/control: Promote crmsh | pcs to Recommends for upgraders from 14.04." -- what did you mean about upgraders from 14.04?  Do we still need that change post-16.04?