[04:10] <ppisati> yo
[06:46] <smb> ppisati, no! (too early)
[07:49] <apw> yeah that is far toooo early
[07:50] <RAOF> But not too early for the BEES!
[07:55] <amitk> apw: any chance of this patch getting into trusty? https://bugs.freedesktop.org/show_bug.cgi?id=58378
[07:55] <ubot2> Freedesktop bug 58378 in Driver/nouveau "[NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.5.x (and RHEL 6.5) or later" [Normal,Resolved: fixed]
[07:56] <amitk> apw: I've not been able to use the ubuntu dashboard (switched to i3) due to corruption issues since 12.04
[07:56] <amitk> the patch made it into 3.14-rc1
[07:59] <amitk> related ubuntu bug I filed (and ignored eventually): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158689
[07:59] <ubot2> Launchpad bug 1158689 in linux (Ubuntu) "10de:0422 bringing up dash causes screen corruption on nouveau" [Medium,Incomplete]
[08:01] <amitk> or perhaps you look into graphics RAOF?
[08:02] <RAOF> If you need a kernel patch, you need apw!
[08:02] <apw> well there is little change for the release kernel, but ... for an sru i can have a look
[08:02] <RAOF> (Or someone else on the kernel team ☺)
[08:02] <apw> amitk, could you add the details to the bug as well
[08:02]  * smb wonders whether amitk remembers that deadline thing in general
[08:03] <amitk> apw: what details do you need? I'll link to the freedesktop bug
[08:03] <apw> amitk, that'll do i recon
[08:03] <amitk> smb: its done when its done ;) I can't promise deadlines for scheduler changes ;)
[08:04] <smb> amitk, Just wondering about a patch that you say made it into 3.14-rc1. Thought that was a bit ago. 
[08:06] <amitk> smb: I haven't tracked this bug for a while since I don't use the ubuntu dashboard anymore. This came up again when I was testing out Trusty images over the weekend and I decided to look if it was fixed anywhere
[08:06] <amitk> smb: and I knew you were getting close to a release, but no I didn't know when exactly
[08:07] <amitk> :)
[08:07] <smb> amitk, So quick to forget. :)
[08:09] <amitk> smb: hardly forgotten, more like I don't upgrade my devbox on a 6-monthly cadence anymore ;)
[08:10] <amitk> apw: done linking against the upstream bug
[08:15] <apw> amitk, this is going to be a hard ask, it is rather large:
[08:15] <apw>  33 files changed, 500 insertions(+), 308 deletions(-)
[08:18] <amitk> apw: did you look at commit 4019aaa2b314a5be9886ae1db64ff8c6d3c060ed?
[08:19] <amitk> apw: I only see  17 files changed, 287 insertions(+), 35 deletions(-)
[08:19] <amitk> apw: or is there a dependency patch that I missed?
[08:20] <apw> amitk, yes, there are two, one of which 'rewrites most of the quirk init code'
[08:20] <amitk> apw: aah
[08:20] <apw> though even the 17 is pretty invasive
[08:20] <amitk> apw: true
[08:22] <amitk> apw: the patch itself is important for nouveau users that are currently seeing errors in their logs because the driver tries to use HW blocks that aren't even present
[08:23] <amitk> apw: I'll just switch to mainline kernels
[08:27] <apw> amitk, i'll spin a test kernel and you can test it, at least we will know for sure it is the fix
[08:27] <apw> i can then propose it and see what happens
[08:32] <amitk> apw: thanks
[09:15] <jpds> Can someone take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1303419 ? I found a workaround but it'll be nice to have it as default.
[09:15] <ubot2> Launchpad bug 1303419 in linux (Ubuntu) "Brightness keys don't work on HP Elitebook Folio 1040 G1" [Undecided,Confirmed]
[09:18] <apw> jpds, will have a look
[09:35] <jpds> apw: Thanks.
[09:56] <apw> amitk, test kernels linked in the bug
[10:11] <amitk> apw: will test soon and get back, thanks again
[10:35] <apw> jpds, possible fix applied to test kernels, urls in the bug
[10:37] <jpds> apw: Testing...
[10:40] <apw> jpds, it is not 100% clear from the description which ids are covered, so it may not, we shall see
[10:41] <jpds> apw: It worked.
[10:45] <jpds> \o/
[10:45] <apw> jpds, ok ta, put that in the bug for me
[10:46] <jpds> apw: Already done.
[10:50] <apw> jpds, submitted to our list for consideration, shame you didn't get this in before freeze, but hey
[10:51] <jpds> apw: I got the laptop yesterday!
[10:51] <jpds> ;-)
[11:21] <apw> jpds, heh
[13:14] <apw> rtg, i just slammed head to fix a bug number in one of my patches
[13:16] <rtg> apw, ack
[13:16] <rtg> apw, did I mark the wrong bug fix committed then ?
[13:17] <apw> rtg, you did on my error, i fixed that up as well
[13:17] <rtg> cool
[13:17] <apw> rtg, you seem to have skipped over "rds: prevent dereference of a NULL device in rds_iw_laddr_check", i was going to apply that if you arn't doing it ... its a big heap of applying i don't want to duplicate :)
[13:18] <rtg> apw, I just haven't gotten to it yet, but go ahead.
[13:18] <apw> rtg, ack
[13:18] <rtg> I was busy updating kernels and such.
[13:18] <rtg> in fact, I'm about to reboot now.
[14:54] <brendand> is there a difference between checking for 'mem' in /sys/power/state vs using pm-is-supported --suspend?
[14:54] <brendand> i'm sure there is a difference, but i'd like to know what that is
[14:55] <brendand> if mem exists but pm-is-supported fails, does that mean suspend *can't* work on that system, or might it mean there's a bug?
[14:56] <brendand> similarly, if mem doesn't exist, might it be possible for pm-is-supported to succeed?
[15:10] <apw> brendand, it checks mem in /sys/power/state as one of the options, there are two others, so to answer your questions, yes and yes
[15:11] <apw> it is not clear how pm-is-supports --suspend could fail if mem is in /sys/power/state however
[15:14] <rtg> apw, when installing from the server ISO having a driver referenced in d-i/modules/nic-modules should be sufficient for network access, right ? For example, 'debian.master/d-i/modules/nic-modules:mlx4_en ?'. 
[15:14] <apw> rtg, i believe so indeed
[15:15] <rtg> apw, and it _should_ get bundled into the initrd when the kernel is installed on the target disk.
[15:15] <apw> the criteria there are unrelated, networking is not normally seen as boot essential is it ?
[15:16] <rtg> apw, Infiniband might be. Guess I'd better find out.
[15:16] <apw> nor would it normally be, given you open the real disk, and find the drivers there
[15:16] <apw> yeah ... that
[15:16] <smb> apw, netboot?
[15:16] <brendand> oh dear, if pm-suspend can't do real hybrid sleep then it cheats :/
[15:17] <apw> smb, that has a different initrd
[15:17] <apw> brendand, "oh dear" ?
[15:17] <smb> apw, hopefully one that considers networking as boot essential
[15:17] <apw> hopefully nideed
[15:18] <brendand> apw, from the point of view of someone testing that hybrid sleep works, yes
[15:19] <apw> smb, i just updated "clark" and rebooted, on startup i can now seem my old VMs, good, but they do not start
[15:19] <apw> Error starting domain: internal error: libxenlight failed to create new domain 'grovel-r64'
[15:20] <smb> apw, Would be nice to have some more useful messages. Unfortunately those hide usually in /var/log/libvirt/libxl/... on the host
[15:21] <rtg> tseliot, have you heard any howling about 4K monitor support getting broken with this last nVidia-331 update ?
[15:21] <apw> smb, yeah that is crap, it may be an old VM with "pre VG rename" paths in it
[15:22] <bjf> rtg, i don't think it's 4k support. i think nvidia is borked
[15:22] <bjf> rtg, i'm guessing you are in low-res mode
[15:22] <smb> apw, True. Well it could be anything. Sadly the error reporting through virt-manager is... suboptimal
[15:22] <bjf> rtg, and your jumbo-tron doesn't have a low-res support
[15:22] <tseliot> rtg: the driver we have in Ubuntu is not the latest from Nvidia. I haven't tested it with 4K but 2560x1440 works fine here
[15:22] <rtg> bjf, oh, you mean altogether borked ? I'm in "no mode" black screen
[15:23] <apw> rtg, is your monitor "black" or "off", mine seems to be off
[15:23] <apw> smb, ok this was "my fault"
[15:23] <rtg> apw, black
[15:23] <apw> they seem converted just fine
[15:23] <bjf> rtg, i'm in low-res on a "normal" monitor which might be different on the jumbo-tron
[15:23] <tseliot> rtg: in the latest update I only added support for Linux 3.14
[15:23] <smb> apw, Uh, what kept them from starting then?
[15:24] <apw> somewhen back in the mists of time (read more than 2 weeks back) i renamed my datavg to clarkvg
[15:24] <apw> and this had the old, you cannot have inserted the wrongo path
[15:25] <smb> apw, Ah! Ok, makes some sense then. Just not the nicest thing on earth when it comes to errors. As much as a python stackrace can ever be called nice
[15:26] <apw> ok this was a raring machine, that makes sense being as it isn't supported any mroe, /me tries an s instance
[15:26] <smb> apw, No the convertion should not change anything there
[15:26] <apw> smb, ok my S which i had fixed previously appears correctly and starts correctly.  i'd say that is success, got a bug # i can report that testing in ?
[15:29] <smb> apw, No, I probably should open one... and maybe ... hm... just occured to me that re-creating those VMs that are in the old path but not the new may be annoyingly bringing back things on every upgrade
[15:30] <apw> smb, you have to mark that you have done it and do it just once indeed
[15:30] <smb> apw, except maybe when adding a '--force'
[15:31] <apw> smb, or rename the previous ones to .old sort of thing
[15:31] <apw> so you can rename them back if you need to but only process the ones not .old
[15:32] <smb> apw, I would be careful there. As I cannot be 100% sure what the old xend does with those.
[15:34] <apw> smb, move them from like /foo/bar/machines/* to /foo/bar/machines.old/*
[15:36] <smb> apw, If I do that, and someone switches back to the old toolstack, the domains are gone there. 
[15:38] <apw> smb, yes but i may have changed them anyhow, so you need to convert them back
[15:38] <apw> smb, which is why i think we should convert them, pop somethign up to tell you that, so you arn't supprised they are gone when you downgrade
[15:39] <apw> smb, but overall they work well so that at least is good
[15:39] <smb> apw, it already tells you about the conversion in the log. And I rather won't go on a reverse. Thats deprecated anyhow
[15:40] <smb> And adds too much complexity
[15:40] <apw> smb, right that is why i don't think we care that they are gone if you go back, that can be documented on something the log points to perhaps
[15:40] <apw> like a wiki for downgraders
[15:40] <apw> or something
[15:41] <apw> smb, though your bug should have a release notes task so we can warn people this is going to happen to them in advance as well
[15:42] <smb> apw, Hm, I am rather adding something preventing a second convertion. Feels more straight forward
[15:44] <apw> we should still release note the conversion so people can think about the risks, as they will be higher than normal for xen use, which is almost noone of course
[15:46] <smb> apw, Agreed. I think that bug I am reporting right now can also get a release-notes task
[15:51] <apw> smb, yeah agree
[15:52] <smb> apw, bug 1303886 created
[15:52] <ubot2> Launchpad bug 1303886 in xen (Ubuntu) "[Trusty] Xend managed domains disappear after upgrade" [Undecided,New] https://launchpad.net/bugs/1303886
[15:54] <smb> apw, Oh one thing that prevents the renaming. Unfortunately I have to take care about xen only and xen with libvirt and I would not know in the postinst which case
[15:55] <apw> smb, i've added the release notes task
[15:55] <smb> apw, ok
[15:55] <apw> smb, if you can only "do it" once ever that seems fine, and safer
[16:00]  * cking drops in to listen to the canonical "plan" via icecast.. 
[16:00] <cking> oops
[16:01] <smb> cking, New level of annoying elevator musak
[16:01] <cking> arggh
[16:34] <amitk> apw: bugfix confirmed and commented on bug
[16:34] <amitk> apw: thanks
[18:45] <bjf> zequence, BenC new SRU cycle just started
[18:58] <zequence> bjf: Yep. I'm all done except for testing.