| davmor2 | infinity, jibel: no netboot on 14.04.5 | 08:07 |
|---|---|---|
| jibel | davmor2, in the tracker? | 08:08 |
| davmor2 | jibel: yeap | 08:08 |
| highvoltage | Edubuntu 14.04.5 LTS version 20160802 testing completed and marking as ready. | 08:10 |
| tjaalton | where does i965-va-driver get it's Section? it shows universe/oldlibs, while the package source has Section: video | 08:11 |
| apw | tjaalton, if it is genuinly not from the package, then it may have overrides in te archive | 08:34 |
| 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 | 08:35 |
| ubot5 | Launchpad bug 1603199 in intel-vaapi-driver (Ubuntu) "i965-va-driver shouldn't be in oldlibs" [Undecided,New] | 08:36 |
| LocutusOfBorg | please accept libtest2-suite-perl, this way I can make also libgraphviz-perl migrate | 11:00 |
| === s8321414_ is now known as s8321414 | ||
| LocutusOfBorg | will trusty receive any lts-yakkety stack? | 14:00 |
| 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:02 |
| apw | LocutusOfBorg, it will in time, but that is not ready yet for sure | 14:03 |
| 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:05 |
| tjaalton | LocutusOfBorg: no, trusty won't | 14:11 |
| 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:12 |
| tjaalton | because there is xenial | 14:14 |
| LocutusOfBorg | so, please reject virtualbox-lts-yakkety from trusty queue | 14:15 |
| LocutusOfBorg | pitti, ^^ :) | 14:15 |
| tjaalton | done | 14:16 |
| LocutusOfBorg | <3 | 14:17 |
| apw | oh yeah, derp | 14:55 |
| slangasek | so, why has the iso tracker just (yesterday) added tags to a bunch of ancient bugs? | 15:03 |
| slangasek | seem to all be from tests done in 2012, so looks like they can be ignored | 15:04 |
| dmj_s76 | infinity: Any progress on the Nvidia front? | 15:21 |
| 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:22 |
| powersj | rbasak, after or before daily? | 15:24 |
| rbasak | Oh sorry, before. | 15:24 |
| 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:33 |
| 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:35 |
| Mirv | release team ^ ok from my side too, plus add to the list: kde-baseapps | 16:39 |
| Mirv | unity8 fix should land soon so tomorrow we could see if we could get the migration to happen | 16:40 |
| infinity | yofel: What's the point of having tests if none of them work? :/ | 16:43 |
| 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:44 |
| infinity | tjaalton: Did you and tseliot get a chance to look at the nvidia issues? | 16:46 |
| 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:50 |
| infinity | dmj_s76: The other nvme bug should be fixed too (the ubiquity one). | 16:51 |
| 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:53 |
| 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:56 |
| jbicha | speaking of unusual combinations from autopkgtest, there's bug 1606983 | 16:59 |
| ubot5 | bug 1606983 in Auto Package Testing "test triggered from depwait package" [Undecided,New] https://launchpad.net/bugs/1606983 | 16:59 |
| infinity | Weird. pitti may have been playing. | 17:01 |
| 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:07 |
| 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:08 |
| dmj_s76 | infinity: cyphermox: I can confirm that nvme installs now work in bios mode using default partitioning! | 17:18 |
| dmj_s76 | tested on latest 14.04.5 iso | 17:19 |
| tjaalton | infinity: tseliot is looking into it | 17:41 |
| 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:43 |
| tjaalton | yeah he knows | 17:47 |
| slangasek | infinity: do you suppose it's a bug that we have /var/log/apt/history.log in the liveCD's squashfs? | 18:57 |
| 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...) | 18:58 |
| 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:01 |
| 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:02 |
| infinity | slangasek: Do they not generally include that? apport ones, that is. | 19:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| infinity | It certainly could, if it doesn't currently. | 19:18 |
| 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:19 |
| 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:20 |
| * slangasek nods | 19:22 | |
| 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:23 |
| 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:24 |
| infinity | ("What medium did you use?" ... "I didn't, I used the large. Took forever to download.") | 19:25 |
| cyphermox | infinity: don't mix things up, I keep having mediums call me at home. | 19:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!