[10:31] <LocutusOfBorg> hi, can anybody pretty-please look at virtualbox-lts-vivid?
[10:31] <LocutusOfBorg> I  would be happy to answer to any question you might have :)
[11:00] <apw> LocutusOfBorg, (not that i can approve it, but) is there a reason it has to be a seaparate package, that the support for the vivid kernels cannot be folded into the original ?
[11:00] <LocutusOfBorg> apw, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769
[11:01] <ubot5`> Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [High,Triaged]
[11:01] <LocutusOfBorg>   virtualbox-guest-x11 : Depends: xorg-video-abi-15
[11:01] <LocutusOfBorg>                         Depends: xserver-xorg-core (>= 2:1.14.99.902)
[11:01] <LocutusOfBorg> so I had to add a new package specially built against the -lts-vivid package
[11:01] <LocutusOfBorg> because it changed ABI, so it isn't installable
[11:01] <LocutusOfBorg> and I'm talking about the guest- package
[11:02] <LocutusOfBorg> not the host, this is why I'm building only virtualbox-guest-*, and so on
[11:02] <apw> LocutusOfBorg, ahh against xorg-lts-vivid ... then that makes perfect sense, thank you
[11:05]  * LocutusOfBorg was hoping about and answer like "hey dumb maintainer, there is this bit that fixes all the mess for you" :)
[11:06] <LocutusOfBorg> I spent months in debugging this issue, and for sure I would like to avoid having to maintain a new package :(
[11:30] <apw> we have an initramfs-tools siting in New, which it might be prudent to leave there until (say) Monday as there is also a kernel in flight
[11:59] <cjwatson> slangasek: launchpad-buildd isn't entirely trivial to set up, but it's indeed perhaps better to not have a script getting gradually staler.
[14:41] <rbasak> Is it possible to have one architecture binary package in main, but the others in universe?
[14:41] <rbasak> We're wondering in relation to DPDK and what commitment we want to make for support in main for ppc64el.
[14:42] <cjwatson> rbasak: It is technically possible in Launchpad, but makes various reports get upset and I think it's a bad idea.
[14:43] <cjwatson> rbasak: As general advice I would suggest not relying solely on the main/universe distinction to express supportedness.
[14:46] <rbasak> cjwatson: OK. Any advice on this one please? ppc64el support isn't upstream but there is a patch. We definitely want dpdk in main for amd64 for ovs, but also don't want to block anyone from having ppc64el working in dpdk but aren't sure we (Canonical) want to commit to support that (considering options).
[14:47] <cjwatson> AIUI Canonical is perfectly capable of having its support guarantees be out-of-band with the archive
[14:47] <cjwatson> Perhaps talk to STS?
[14:47] <rbasak> OK, thanks!
[14:48] <cjwatson> I think the security team still want everything in main to be supportable, but it seems quite unlikely to end up with an architecture-specific vulnerability.
[17:11] <bdmurray> slangasek: I'm not seeing Supported info for packages any more in Xenial.
[17:31] <slangasek> cjwatson, infinity: ^^ so Supported seems to have disappeared from the xenial packages files, about the time I merged the change to make xenial == trusty... where does the output of this get logged?
[17:31] <cjwatson> I didn't deploy it until yesterday, FWIW
[17:32] <cjwatson> anyway, try pepo:/srv/launchpad.net/production-logs/lp_publish/publish-ftpmaster.log
[17:33] <cjwatson> Laney: speaking of which, rsync appstream.ubuntu.com::appstream/ -> "@ERROR: Unknown module 'appstream'" - looks like your rsync fragment has somehow ended up not in /etc/rsyncd.conf
[17:33] <cjwatson> Running maintenance-check for xenial...  done
[17:33] <cjwatson> slangasek: ^- that's all it says I'm afraid
[17:34] <Laney> cjwatson: ah FFS
[17:34] <Laney> cjwatson: I just deployed the nrpe thing which exposes things over rsync, bet that clobbered it
[17:36] <cjwatson> slangasek: ah, in fact /srv/launchpad.net/ubuntu-archive/ubuntu-germinate/_maintenance-check.xenial.stderr
[17:38] <cjwatson> oh god this is a fractal of wrong
[17:39] <teward> with regards to snappy core, how is that affected by the 15.04 EOL?
[17:39] <teward> s/core//
[17:41] <cjwatson> slangasek: I think I have bodged this to not be entirely wrong.  lp:ubuntu-archive-publishing r77
[17:41] <cjwatson> bdmurray: ^-
[17:41] <cjwatson> deployed, hopefully will recover in a bit
[17:42] <cjwatson> slangasek: (the wrongness wasn't of your origin, you just tickled it by adding ppc64el/s390x)
[17:42] <slangasek> heh ok
[17:42] <slangasek> cjwatson: thanks :)
[17:42] <slangasek> fractal of wrong> I didn't *think* I was writing python...
[17:42] <slangasek> er, I mean, php
[17:43] <bdmurray> cjwatson: okay, thanks
[18:08] <Laney> cjwatson: should be back
[18:14]  * cjwatson fixes lp:ubuntu-archive-publishing harder
[18:14] <cjwatson> Laney: thanks
[18:15] <Laney> I should document the right place to get that charm from so the next person doesn't have to feel around in the dark
[18:30] <slangasek> infinity, cjwatson: should our d-i stop build-depending on cramfsprogs? (obsolete, removed in Debian)
[18:32] <slangasek> and the build-dep is powerpc only, which is why I ask you two
[18:36] <infinity> slangasek: I'd have to look at why it thinks it needs the build-dep, but I'm willing to believe it's not being used.
[18:37] <slangasek> infinity: ./build/config/powerpc/powerpc/floppy/net-drivers.cfg, ./build/config/powerpc/powerpc/floppy/cd-drivers.cfg seems to use it, are you building powerpc floppies? :)
[18:37] <infinity> slangasek: Hrm.  Or maybe it does, indeed, think it's being used.  But it certainly shouldn't need it.
[18:38] <infinity> slangasek: We're not building floppies, but I'm not convinced that "floppy" means "floppy" in that context, given the filenames.  Will have to trace through a little bit.
[18:54] <xnox> slangasek, common, we still use punchcards too, and tape =)
[18:54] <xnox> floppy is so advanced!
[19:01] <cjwatson> slangasek: fine by me if we track down any associated debris
[22:41] <cjwatson> bdmurray,slangasek: I've checked and there are in fact Supported fields for xenial now, and I think correct for the recent changes
[22:41] <cjwatson> (only checked very lightly though)
[22:57] <slangasek> cjwatson: great, thanks!