[08:07] infinity, jibel: no netboot on 14.04.5 [08:08] davmor2, in the tracker? [08:08] jibel: yeap [08:10] Edubuntu 14.04.5 LTS version 20160802 testing completed and marking as ready. [08:11] where does i965-va-driver get it's Section? it shows universe/oldlibs, while the package source has Section: video [08:34] tjaalton, if it is genuinly not from the package, then it may have overrides in te archive [08:35] apw: yeah.. [08:35] guess I can add ubuntu-archive to the bug [08:35] https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1603199 [08:36] Launchpad bug 1603199 in intel-vaapi-driver (Ubuntu) "i965-va-driver shouldn't be in oldlibs" [Undecided,New] [11:00] please accept libtest2-suite-perl, this way I can make also libgraphviz-perl migrate === s8321414_ is now known as s8321414 [14:00] will trusty receive any lts-yakkety stack? [14:02] in case, please reject https://launchpad.net/ubuntu/trusty/+queue virtualbox-lts-yakkety (source) [14:02] 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] LocutusOfBorg, it will in time, but that is not ready yet for sure [14:05] ok, so lets leave it in the queue [14:05] and accept when the other stuff is ready [14:05] so I don't have complainst about "hey vbox is not installable" [14:11] LocutusOfBorg: no, trusty won't [14:12] no it wont get a lts-yakkety release, it stops at the next lts (xenial) [14:12] because no more point releases, right? [14:14] because there is xenial [14:15] so, please reject virtualbox-lts-yakkety from trusty queue [14:15] pitti, ^^ :) [14:16] done [14:17] <3 [14:55] oh yeah, derp [15:03] so, why has the iso tracker just (yesterday) added tags to a bunch of ancient bugs? [15:04] seem to all be from tests done in 2012, so looks like they can be ignored [15:21] infinity: Any progress on the Nvidia front? [15:22] 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] powersj: ^ [15:24] rbasak, after or before daily? [15:24] Oh sorry, before. [16:33] 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] 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] so that qt 5.6 isn't stuck on kde [16:39] release team ^ ok from my side too, plus add to the list: kde-baseapps [16:40] unity8 fix should land soon so tomorrow we could see if we could get the migration to happen [16:43] yofel: What's the point of having tests if none of them work? :/ [16:44] 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] tjaalton: Did you and tseliot get a chance to look at the nvidia issues? [16:50] 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] dmj_s76: The other nvme bug should be fixed too (the ubiquity one). [16:53] infinity: I'll put one of the nvme drives in a bios machine and let you know the results [16:53] 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] 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] and then there's the tests that run on architectures that I cannot even debug even if I wanted... [16:56] 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] speaking of unusual combinations from autopkgtest, there's bug 1606983 [16:59] bug 1606983 in Auto Package Testing "test triggered from depwait package" [Undecided,New] https://launchpad.net/bugs/1606983 [17:01] Weird. pitti may have been playing. [17:07] 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] this time around there is actually less failing autopkgtests that than in some previous releases [17:08] We've had (nearly) all of them passing in the past, which is why britney's upset now. [17:08] It only blocks on regressions. [17:08] But I'll look a bit later. [17:18] infinity: cyphermox: I can confirm that nvme installs now work in bios mode using default partitioning! [17:19] tested on latest 14.04.5 iso [17:41] infinity: tseliot is looking into it [17:43] tjaalton: Kay. Time's a factor. :) [17:43] tjaalton: (I can delay the point release for this if I have to, but I'd prefer not to) [17:47] yeah he knows [18:57] infinity: do you suppose it's a bug that we have /var/log/apt/history.log in the liveCD's squashfs? [18:58] (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] 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] slangasek: Call it an accidental feature? :P [19:02] 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] slangasek: Do they not generally include that? apport ones, that is. [19:15] 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] 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] 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] It certainly could, if it doesn't currently. [19:19] 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] I wouldn't think so. [19:19] no? [19:20] it's not a kernel crash handle [19:20] Oh, maybe. I'm not sure how segv handlers resolve in that context. [19:20] it's a dpkg package handle [19:20] Oh. [19:20] Then perhaps it would be the chroot one. [19:20] In which case, the fix would be for us to copy the media info immediately after copying the squashfs. [19:20] Rather than at the end, with the logs. [19:22] * slangasek nods [19:23] (does it annoy anyone else that, in the context of storage, "media" has become both plural and singular?) [19:23] We should copy the MEDIUM info right after the squashfs. :P [19:24] it doesn't bother me at all, because I don't recognize it to be true ;-) [19:24] slangasek: No? Do you ever say "what medium did you use to install that?" [19:24] infinity: yes ;) [19:24] If so, you're rare. :P [19:25] ("What medium did you use?" ... "I didn't, I used the large. Took forever to download.") [19:31] infinity: don't mix things up, I keep having mediums call me at home.