| === ghostcube_ is now known as ghostcube | ||
| === JanC_ is now known as JanC | ||
| Laney | Anyone know what changed in cloud images to make 'scsi_debug' go away? https://jenkins.qa.ubuntu.com/view/Wily/view/AutoPkgTest/job/wily-adt-udisks2/ARCH=amd64,label=adt/48/console | 11:39 |
|---|---|---|
| Laney | It's in -extra- but that's not installed | 11:40 |
| apw | Laney, not of the top of my head, its not something i recall being done deliberatly | 11:42 |
| apw | perhaps it got split out or something | 11:42 |
| apw | Laney, i can see no reason it would not have also been in linux-image-extra-* in vivid also | 11:45 |
| apw | the inclusion list is not different in scsi space, hmmm | 11:47 |
| Laney | apw: just booting a vivid instance to check | 11:49 |
| apw | Laney, and indeed in the latest vivid linux-image-extra-* it is in there too | 11:49 |
| Laney | but it is there in vivid | 11:49 |
| apw | ? | 11:49 |
| Laney | and the cloud manifests of vivid vs wily look the same | 11:49 |
| apw | well that file is in linux-image-extras-* so that is confusing | 11:49 |
| apw | ask dpkg what installed it | 11:49 |
| Laney | there -> in -extra- | 11:50 |
| apw | ahh ... well ... erp | 11:50 |
| apw | Laney, perhaps the tests have changed and would fail on vivid too | 11:51 |
| Laney | I see cloud-init is downloading it | 11:51 |
| Laney | OK, probably Not Your Problem. :) | 11:51 |
| Laney | go deal with doko :P | 11:51 |
| marga | infinity, I've added more data to https://bugs.launchpad.net/fedora/+bug/1124250 (I don't understand why this says fedora in the URL, it's marked as affecting linux on trusty and utopic) | 12:15 |
| ubot5 | Ubuntu bug 1124250 in linux (Ubuntu Utopic) "Partially incorrect uid mapping with nfs4/idmapd/ldap-auth" [Low,Fix released] | 12:15 |
| marga | chiluk, ^My last comment in that bug should show the current state. It seems like the bug is not fixed for Trusty after all. I'm not sure if I can be of any other help :-/ | 12:16 |
| TJ- | I've just helped a Vivid amd64 user with a radeon GPU. The recent 3.19.0.23 update (from 3.19.0-22) has caused a regression causing a blank monitor. Cause is the default mode is 1920x1080@60.0 but that fails in the latest kernel, but 1920x1080@59.9 will work (monitor offers @50, @59.9, @60). Looks like the (intel)drm and radeon patches could be the cause (bug #1460674) | 13:37 |
| ubot5 | bug 1460674 in linux (Ubuntu Vivid) "[i915_bpo] Rebase driver to 4.2~pre" [High,Fix released] https://launchpad.net/bugs/1460674 | 13:37 |
| === trippeh_ is now known as trippeh | ||
| apw | TJ-, i think we'll need to get some bisect action on that, but we'd need to original user for that, and a bug to work in | 13:42 |
| TJ- | apw: I'm awaiting their bug report number | 13:42 |
| apw | TJ-, great, jsalisbury one for the bisect machine me thinks | 13:42 |
| apw | (coming soon from TJ- once he has the bug #) | 13:43 |
| TJ- | bug #1477587 | 13:49 |
| ubot5 | bug 1477587 in linux (Ubuntu) "One black screen of two when both on 1080p60" [High,Confirmed] https://launchpad.net/bugs/1477587 | 13:49 |
| === zyga is now known as zyga-afk | ||
| Sarvatt | TJ-, apw: updated that bug, some upstream stable reverts for radeon that came in that stable release update, its not related to the i915_bpo stuff | 14:11 |
| Sarvatt | err, we got some radeon stable updates in the regressing kernel that were reverted in other stable releases i mean | 14:12 |
| Sarvatt | most likely that :D | 14:12 |
| jsalisbury | apw, ack | 14:14 |
| jsalisbury | Sarvatt, thanks for updating the bug | 14:15 |
| TJ- | Sarvatt: the radeon change mentions the Turks GPU, I noticed. The reason I mentioned the (intel)frm was I saw a specific drm/atmoic CRTC patch | 14:16 |
| TJ- | s/frm/drm/ | 14:16 |
| Sarvatt | https://bugzilla.kernel.org/show_bug.cgi?id=99651 | 14:18 |
| ubot5 | bugzilla.kernel.org bug 99651 in Video(DRI - non Intel) "third monitor connected via dvi does not work on radeonhd 7770" [High,New] | 14:18 |
| TJ- | Those 2 mentioned commits aren't in the vivid release though, are they? "git describe --all --contains a10f0df0615 ==> tags/cod/tip/drm-intel-nightly/2015-05-29~6^2~1^2~2" | 14:21 |
| Sarvatt | they're in v3.19.8-ckt3, current vivid kernel is based on the v3.19.8-ckt2 stable release | 14:23 |
| TJ- | Maybe I'm misunderstanding then, but as I read the bugzilla report those 2 commits need reverting to fix that issue... whereas our user has a kernel without those commits so in theory our issue is something different? | 14:25 |
| apw | jsalisbury, sounds like we need confirmation of the version in the bug and confirming if those two are in it or not | 14:26 |
| TJ- | Our user does have an HDMI+audio, DVI-D though, so the configuration is similar | 14:26 |
| TJ- | apw: The affected version is -23, and the working version is -22 ... kernel upgrade today initiated the problem | 14:27 |
| Sarvatt | http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/commit/drivers/gpu/drm/radeon?id=5385d2affc40d9a4f465ebd4dc3c1e6e0b6c1b0f different sha1 in the ubuntu repo | 14:27 |
| Sarvatt | The good kernel version was linux_3.19.0-21.21. | 14:27 |
| Sarvatt | This Problem occurred in kernel linux_3.19.0-22.22 and linux_3.19.0-23.24. | 14:27 |
| TJ- | apw: In fact, the info the reporter gives as to kernel versions doesn't seem to match what I was told (see above for what I was told) | 14:27 |
| jsalisbury | apw, ProcVersionSignature: Ubuntu 3.19.0-23.24-generic 3.19.8-ckt2 I can ask them to test: 3.19.8-ckt3 | 14:28 |
| apw | TJ-, thats not ... yeah that | 14:28 |
| TJ- | I've attached the IRC log for clarity | 14:30 |
| jsalisbury | apw, Sarvatt I see only one of those commits was added in 3.19.0-22: | 14:38 |
| jsalisbury | http://kernel.ubuntu.com/git/ubuntu/linux.git/commit/?h=linux-3.19.y&id=bdb01a9532b5a985631d04aefc10e0a421284f28 | 14:38 |
| apw | jsalisbury, does the other get reverted in -ckt3 by any chance | 14:39 |
| jsalisbury | apw, I'll take a look | 14:39 |
| jsalisbury | apw, looks like it does: | 14:42 |
| jsalisbury | bde11f3 Revert "drm/radeon: don't share plls if monitors differ in audio support" | 14:42 |
| Sarvatt | http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y&ofs=250 about 20 down | 14:42 |
| jsalisbury | git describe --contains bde11f3 | 14:42 |
| jsalisbury | v3.19.8-ckt3~20 | 14:42 |
| jsalisbury | Sarvatt, :-) good timing | 14:42 |
| apw | jsalisbury, ok so the next update should have it, so ... i'd say ram that commit on a test kernel for them | 14:43 |
| apw | and confirm that that is enough to make them right again | 14:43 |
| TJ- | I love it when it's simple :) | 14:44 |
| jsalisbury | apw, what's strange is I don't see the original commit in Vivid that should be reverted. | 14:44 |
| jsalisbury | 52dfc11 drm/radeon: don't share plls if monitors differ in audio support | 14:44 |
| jsalisbury | It looks like it was never added | 14:45 |
| apw | jsalisbury, well it must be no, else it couldn't revert off | 14:46 |
| jsalisbury | apw, hmm, I can't find it with 'git log' or in the changelog, but a git revert on a Vivid tree using the upstream SHA1 does work | 14:48 |
| Sarvatt | are there any automated vivid master-next builds in a ppa somewhere? | 14:48 |
| apw | Sarvatt, yep in the ~ubuntu-kernel-test ppa pre-proposed in theory | 14:49 |
| jsalisbury | apw, Sarvatt I looked directly at the source and mainline commit a10f0df0615 was never applied to Vivid. So the revert(Mainline commit 6fb3c025) won't do anything. | 14:54 |
| apw | jsalisbury, or it might do somethig bad like readd it, what does the commit actually contain in stable | 14:54 |
| apw | as you can't easily commit a null commit | 14:54 |
| henrix | jsalisbury: looks like that commit is only in vivid master-next branch, so there was never a kernel released with it | 14:56 |
| henrix | actually, both the commit *and* the revert are in master-next, which is kind of pointless... :-) | 14:56 |
| jsalisbury | apw, so maybe a revert of ebb9bf18 is all that is needed, which is comming in 3.19.8-ckt3. I can build a vivid test kernel with just that change | 14:58 |
| TJ- | My reading of it was the user *needs* the commit that splits PLLs when one output has HDMI, as is the case | 14:59 |
| TJ- | s/HDMI/HDMI + audio/ | 14:59 |
| === zyga-afk is now known as zyga | ||
| rtg | apw, infinity, I uploaded blktap-dmks to https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa if you'd like to have a look | 18:31 |
| infinity | rtg: That seems nice and simple. If it fixes it, yay. And we'll also want that SRUed to trusty (for lts-w/lts-x kernels) | 18:32 |
| rtg | infinity, oh, hadn't thought about the SRU. Guess I'll do that too. | 18:33 |
| * infinity wonders why that doesn't build for arm64... | 18:33 | |
| infinity | Oh. It probably should. | 18:34 |
| rtg | infinity, in the meantime, would you pocket copy to wily for me when it is done building ? | 18:35 |
| infinity | rtg: While you're in there, want to s/i386 amd64 armhf powerpc ppc64el/linux-any/ on the Arch list so we don't have to keep adding arches for every new port? :P | 18:35 |
| rtg | infinity, then just upload directly to the archive ? | 18:36 |
| infinity | rtg: Yeah. | 18:36 |
| infinity | rtg: And happy if both those changes get SRUed. The Arch list change in trusty will just magically make some packages installable, which won't hurt my feelings. | 18:37 |
| rtg | infinity, uploaded blktap-dkms to trusty, bug #1477718 | 18:59 |
| ubot5 | bug 1477718 in blktap-dkms (Ubuntu Trusty) "blktap-dkms FTBS on kernels >= 4.1" [Undecided,In progress] https://launchpad.net/bugs/1477718 | 18:59 |
| infinity | rtg: That's a very confused version number you have there. ;) | 19:04 |
| infinity | rtg: Oh, actually, looking at the debian changelog, we probably just want a backport of the wily version anyway. | 19:06 |
| infinity | blktap-dkms (2.0.93-0.3) unstable; urgency=medium | 19:07 |
| infinity | * Add patch for compatability with kernel 3.14+ | 19:07 |
| rtg | infinity, do you just pocket copy that ? | 19:07 |
| infinity | No. Hold on. Lemme look closer. | 19:07 |
| infinity | rtg: Yeah. We definitely want all the changes from trusty to wily. Simplest would just be to take the wily source, tack ~14.04.1 to the version, and add the bug closure. | 19:11 |
| rtg | infinity, I can do that. reject my upload ? | 19:11 |
| infinity | rtg: Done. | 19:11 |
| infinity | rtg: Looks like current trusty blktap is already broken with lts-u and lts-v because we never bothered to backport, so this'll fix those, plus lts-w. Not bad for a few minutes' work. | 19:12 |
| rtg | infinity, that is prolly an indicator of how many folks actually use this driver, i.e., almost nobody | 19:13 |
| infinity | rtg: Or the intersection of people who use this driver and lts kernels. | 19:13 |
| infinity | rtg: The vast majority of non-cloud server-type people I know tend to prefer the kernel we actually support for 5y. | 19:13 |
| rtg | infinity, you'd better have a look before I upload this: http://people.canonical.com/~rtg/blktap-dkms/ | 19:21 |
| infinity | rtg: Fine, except that should be LP: not Bug: | 19:22 |
| infinity | rtg: You know you got the bug closure wrong if you don't get a Launchpad-Bug-Fixed: stanza in your .changes | 19:23 |
| rtg | infinity, it must only look at the first changelog entry | 19:24 |
| infinity | rtg: Oh, it looks at all the changelog entries you tell it to. | 19:24 |
| infinity | rtg: You want dpkg-genchanges -S -v$(last_trusty_version) > ../foo.changes | 19:25 |
| infinity | rtg: Then you get a nice .changes with everything in it. | 19:25 |
| rtg | ok, lemme update that | 19:25 |
| infinity | rtg: So, good news, your wily upload fixed the autopkgtest failure at least. Yay. | 19:29 |
| infinity | rtg: Going to lift the block tag on your tracking bug and let your kernel in. | 19:30 |
| rtg | infinity, just refreshed that changes file if you'd like to have another look | 19:30 |
| infinity | rtg: Looks perfect, upload away. | 19:31 |
| rtg | done | 19:31 |
| rtg | now, what was I doing before all this ? | 19:32 |
| infinity | rtg: Knowing your schedule, probably EODing? | 19:32 |
| rtg | getting close :) | 19:32 |
| rtg | looks like a great afternoon for some single tracking | 19:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!