=== ghostcube_ is now known as ghostcube
=== JanC_ is now known as JanC
[11:39] <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:40] <Laney> It's in -extra- but that's not installed
[11:42] <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:45] <apw> Laney, i can see no reason it would not have also been in linux-image-extra-* in vivid also
[11:47] <apw> the inclusion list is not different in scsi space, hmmm
[11:49] <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:50] <Laney> there -> in -extra-
[11:50] <apw> ahh ... well ... erp
[11:51] <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
[12:15] <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:16] <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 :-/
[13:37] <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
=== trippeh_ is now known as trippeh
[13:42] <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:43] <apw> (coming soon from TJ- once he has the bug #)
[13:49] <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
=== zyga is now known as zyga-afk
[14:11] <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:12] <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:14] <jsalisbury> apw, ack
[14:15] <jsalisbury> Sarvatt, thanks for updating the bug
[14:16] <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:18] <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:21] <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:23] <Sarvatt> they're in v3.19.8-ckt3, current vivid kernel is based on the v3.19.8-ckt2 stable release
[14:25] <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:26] <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:27] <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:28] <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:30] <TJ-> I've attached the IRC log for clarity
[14:38] <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:39] <apw> jsalisbury, does the other get reverted in -ckt3 by any chance
[14:39] <jsalisbury> apw, I'll take a look
[14:42] <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:43] <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:44] <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:45] <jsalisbury> It looks like it was never added
[14:46] <apw> jsalisbury, well it must be no, else it couldn't revert off
[14:48] <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:49] <apw> Sarvatt, yep in the ~ubuntu-kernel-test ppa pre-proposed in theory
[14:54] <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:56] <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:58] <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:59] <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/
=== zyga-afk is now known as zyga
[18:31] <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:32] <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:33] <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:34] <infinity> Oh.  It probably should.
[18:35] <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:36] <rtg> infinity, then just upload directly to the archive ?
[18:36] <infinity> rtg: Yeah.
[18:37] <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:59] <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
[19:04] <infinity> rtg: That's a very confused version number you have there. ;)
[19:06] <infinity> rtg: Oh, actually, looking at the debian changelog, we probably just want a backport of the wily version anyway.
[19:07] <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:11] <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:12] <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:13] <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:21] <rtg> infinity, you'd better have a look before I upload this: http://people.canonical.com/~rtg/blktap-dkms/
[19:22] <infinity> rtg: Fine, except that should be LP: not Bug:
[19:23] <infinity> rtg: You know you got the bug closure wrong if you don't get a Launchpad-Bug-Fixed: stanza in your .changes
[19:24] <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:25] <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:29] <infinity> rtg: So, good news, your wily upload fixed the autopkgtest failure at least.  Yay.
[19:30] <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:31] <infinity> rtg: Looks perfect, upload away.
[19:31] <rtg> done
[19:32] <rtg> now, what was I doing before all this ?
[19:32] <infinity> rtg: Knowing your schedule, probably EODing?
[19:32] <rtg> getting close :)
[19:33] <rtg> looks like a great afternoon for some single tracking