[08:07] <davmor2> infinity, jibel: no netboot on 14.04.5
[08:08] <jibel> davmor2, in the tracker?
[08:08] <davmor2> jibel: yeap
[08:10] <highvoltage> Edubuntu 14.04.5 LTS version 20160802 testing completed and marking as ready.
[08:11] <tjaalton> where does i965-va-driver get it's Section? it shows universe/oldlibs, while the package source has Section: video
[08:34] <apw> tjaalton, if it is genuinly not from the package, then it may have overrides in te archive
[08:35] <tjaalton> apw: yeah..
[08:35] <tjaalton> guess I can add ubuntu-archive to the bug
[08:35] <tjaalton> https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1603199
[11:00] <LocutusOfBorg> please accept libtest2-suite-perl, this way I can make also libgraphviz-perl migrate
[14:00] <LocutusOfBorg> will trusty receive any lts-yakkety stack?
[14:02] <LocutusOfBorg> in case, please reject https://launchpad.net/ubuntu/trusty/+queue  virtualbox-lts-yakkety (source)
[14:02] <LocutusOfBorg> I followed the advice "upload and we accept when the stack is uploaded", but I didn't check if the stack was on the todo
[14:03] <apw> LocutusOfBorg, it will in time, but that is not ready yet for sure
[14:05] <LocutusOfBorg> ok, so lets leave it in the queue
[14:05] <LocutusOfBorg> and accept when the other stuff is ready
[14:05] <LocutusOfBorg> so I don't have complainst about "hey vbox is not installable"
[14:11] <tjaalton> LocutusOfBorg: no, trusty won't
[14:12] <Sarvatt> no it wont get a lts-yakkety release, it stops at the next lts (xenial)
[14:12] <LocutusOfBorg> because no more point releases, right?
[14:14] <tjaalton> because there is xenial
[14:15] <LocutusOfBorg> so, please reject virtualbox-lts-yakkety from trusty queue
[14:15] <LocutusOfBorg> pitti, ^^ :)
[14:16] <tjaalton> done
[14:17] <LocutusOfBorg> <3
[14:55] <apw> oh yeah, derp
[15:03] <slangasek> so, why has the iso tracker just (yesterday) added tags to a bunch of ancient bugs?
[15:04] <slangasek> seem to all be from tests done in 2012, so looks like they can be ignored
[15:21] <dmj_s76> infinity: Any progress on the Nvidia front?
[15:22] <rbasak> infinity: looks like the Ubuntu server 14.04.5 test URLs from http://iso.qa.ubuntu.com/qatracker/milestones/365/builds/127727/downloads are wrong, and need "trusty/" inserted after "daily/".
[15:22] <rbasak> powersj: ^
[15:24] <powersj> rbasak, after or before daily?
[15:24] <rbasak> Oh sorry, before.
[16:33] <yofel> what would be an easy way to force-badtest all kde packages in proposed? like, permanently? Some tests are known-broken, some tests are regularly building with unsupported package combinations, or different versions across architectures, ...
[16:35] <yofel> or please at least badtest kwin marble kde-cli-tools libkscreen kdepim-runtime kxmlgui extra-cmake-modules kconfigwidgets okteta akonadi-search kidentitymanagement kdelibs4support kwayland libkscreen
[16:35] <yofel> so that qt 5.6 isn't stuck on kde
[16:39] <Mirv> release team ^ ok from my side too, plus add to the list: kde-baseapps
[16:40] <Mirv> unity8 fix should land soon so tomorrow we could see if we could get the migration to happen
[16:43] <infinity> yofel: What's the point of having tests if none of them work? :/
[16:44] <infinity> yofel: And "unsupported package combinations" shouldn't happen.  If it can happen in testing, it can happen for users too.  ie: your dependencies are wrong.
[16:46] <infinity> tjaalton: Did you and tseliot get a chance to look at the nvidia issues?
[16:50] <dmj_s76> I can confirm that the initramfs-tools related nvme bug is fixed in the latest iso, and the nvidia login-loop issue remains.
[16:51] <infinity> dmj_s76: The other nvme bug should be fixed too (the ubiquity one).
[16:53] <dmj_s76> infinity: I'll put one of the nvme drives in a bios machine and let you know the results
[16:53] <yofel> infinity: it's not that none work, but some don't and some testbeds are broken (we mostly got the autopkgtest stuff from debian and don't know what to do with it)
[16:53] <yofel> infinity: after a closer look the package versions are actually ~ok this time - at least inside a package set, but I still see tests where some architectures build for a new version, and some for the old one, which makes all latter architectures useless to me
[16:53] <yofel> and then there's the tests that run on architectures that I cannot even debug even if I wanted...
[16:56] <yofel> it's not that I consider the tests a bad thing, but they're kind of in the way if there's nobody that will fix them
[16:59] <jbicha> speaking of unusual combinations from autopkgtest, there's bug 1606983
[17:01] <infinity> Weird.  pitti may have been playing.
[17:07] <Mirv> yeah Kubuntu has huge amount of tests but if they don't have people to fix the inherited-from-Debian tests, they should be overridden if casual look at them and manual testing doesn't reveal any functionality problems in the said packages (and that has been done)
[17:07] <Mirv> this time around there is actually less failing autopkgtests that than in some previous releases
[17:08] <infinity> We've had (nearly) all of them passing in the past, which is why britney's upset now.
[17:08] <infinity> It only blocks on regressions.
[17:08] <infinity> But I'll look a bit later.
[17:18] <dmj_s76> infinity: cyphermox: I can confirm that nvme installs now work in bios mode using default partitioning!
[17:19] <dmj_s76> tested on latest 14.04.5 iso
[17:41] <tjaalton> infinity: tseliot is looking into it
[17:43] <infinity> tjaalton: Kay.  Time's a factor. :)
[17:43] <infinity> tjaalton: (I can delay the point release for this if I have to, but I'd prefer not to)
[17:47] <tjaalton> yeah he knows
[18:57] <slangasek> infinity: do you suppose it's a bug that we have /var/log/apt/history.log in the liveCD's squashfs?
[18:58] <slangasek> (it does happen to have ultimately come in handy for identifying the install media used in a number of bug reports against shim-signed, where the rest of the data included was lacking...)
[19:01] <infinity> slangasek: It's perhaps an itty bitty bit of wasted space, but I'm not sure I'd see it as a bug.  As you say, it's (very) occasionally useful for debugging, and it'll get rotated into oblivion on an installed system.
[19:01] <infinity> slangasek: Call it an accidental feature? :P
[19:02] <slangasek> infinity: well, I would prefer bug reports that actually show me the version of the install media, instead of having to reverse-engineer this based on dates in that log :)
[19:13] <infinity> slangasek: Do they not generally include that?  apport ones, that is.
[19:15] <infinity> slangasek: Anyhow, I have no strong feeling either way.  It's technically a live-build bug any time it leaves cruft behind that isn't needed for the live or target system, but I also don't have the patience to hunt down every 3k file that we've missed.  Feel free to fix it if you want. :)
[19:16] <slangasek> infinity: they're meant to, but at least for some of these bugs where the install itself is failing (so, before installer logs are copied over), seems not
[19:17] <slangasek> bdmurray: ^^ do you know if apport is meant to know how to report the install image version in a case of a package installation failure before the install is done (e.g., bootloader)?
[19:18] <infinity> It certainly could, if it doesn't currently.
[19:19] <slangasek> at a random guess, the apport that triggers is in the context of the target chroot, so doesn't see the install media at all at that point?
[19:19] <infinity> I wouldn't think so.
[19:19] <slangasek> no?
[19:20] <slangasek> it's not a kernel crash handle
[19:20] <infinity> Oh, maybe.  I'm not sure how segv handlers resolve in that context.
[19:20] <slangasek> it's a dpkg package handle
[19:20] <infinity> Oh.
[19:20] <infinity> Then perhaps it would be the chroot one.
[19:20] <infinity> In which case, the fix would be for us to copy the media info immediately after copying the squashfs.
[19:20] <infinity> Rather than at the end, with the logs.
[19:22]  * slangasek nods
[19:23] <infinity> (does it annoy anyone else that, in the context of storage, "media" has become both plural and singular?)
[19:23] <infinity> We should copy the MEDIUM info right after the squashfs. :P
[19:24] <slangasek> it doesn't bother me at all, because I don't recognize it to be true ;-)
[19:24] <infinity> slangasek: No?  Do you ever say "what medium did you use to install that?"
[19:24] <slangasek> infinity: yes ;)
[19:24] <infinity> If so, you're rare. :P
[19:25] <infinity> ("What medium did you use?" ... "I didn't, I used the large.  Took forever to download.")
[19:31] <cyphermox> infinity: don't mix things up, I keep having mediums call me at home.