[00:28] apw: got it, thanks. BTW, I always use lts-backport-xxx branch on precise and trusty tree :p === gerald is now known as Guest75447 [10:21] Hello kernel friends; I have a task for adding PTS/smoke testing in to the CPC image testing. Is this something I can run with the kernel-testing/autotest stuff, or is this a different beast? [10:24] apw, bjf: ^ ? [10:25] Odd_Bloke, not quite sure what you are asking there, are you asking if running the kernle tests would be a good smoke test ? [10:25] and remind me what PTS means [10:25] apw: That makes two of us. ;) [10:26] apw: I _think_ PTS==Phoronix Test Suite. [10:27] But if it's not obvious to you, then I should probably check what utlemming meant by it. [10:38] Odd_Bloke, could be, not a phrase i use most days for sure [10:39] Odd_Bloke, smoke testing is mormally "basic does it boot and give me a prompt" style testing [10:41] Yeah; I think this is a bit of a confused task. [10:41] I'll check with Ben when he's back in on Monday. [10:41] apw: Sorry for the noise! :) [10:42] Odd_Bloke, np and good luck with that [12:17] Greetings - A question about packaging, that I'm hoping someone can help with: Is there a way to do an iterative kernel build, without doing a clean? I'm debugging something that is part of the kernel proper (i.e., not a module) - and have been trying to avoid doing a full clean / build cycle...but so far have been unsuccessful. Despite placing a #error in a .c file as a test, my compile happily packages everything up, seemingly without recompiling [12:17] this file. I'm using "AUTOBUILD=1 NOEXTRAS=1 skipabi=true skipconfig=true skipmodule=true fakeroot debian/rules binary" as a compile line, if it matters. [12:19] I suspect there's a wiki page out there somewhere, but I've been unable to find it. [12:43] bguthro, you need to remove the build stamp, and then you can rerun the command, stamps are in debian/stamps [12:44] apw, fantastic - thank you much! === JanC_ is now known as JanC [15:29] apw: Turns out http://bazaar.launchpad.net/~server-workload-testing-team/server-workload-testing/trunk/files/head:/pts/ is what we were talking about. :) [15:31] Odd_Bloke, so it is phoronix, just a local copy [15:33] It's a wrapper around the Ubuntu package. [15:33] (TIL there's an Ubuntu package for Phoronix) [16:04] I been discussing https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/ with cjwatson in #ubuntu-devel [16:04] Ubuntu bug 1368784 in virtualbox (Ubuntu) "Vivid and Utopic Virtualbox guest gets only up to resolution of 640x480" [High,Confirmed] [16:04] I've got the following work around - https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/comments/17 [16:05] cjwatson is prepare to update grub-gfxpayload-lists if someone here can confirm "fixing" this issue at a kernel level is hopeless. [16:05] So, thoughts? [16:09] ogasawara, Can you direct me to someone I can discuss the above with please? === chuck_ is now known as zul [16:24] flexiondotorg, "fixing" at the kernel level, do we know what the issue is ? [16:24] flexiondotorg, the implication of the (admittedly older) comments is that you need virtualbox-guest-x11 [16:31] flexiondotorg, and indeed i can confirm that installing the said package does sort things out, who knows what i has in it mind [16:38] seems it has a vbox specific video drivers [16:48] i wonder if they should be being installed by jockey [16:49] apw, So the issue is the default resolution when virtualbox-guest-x11 is not installed. [16:50] the default resolution is that offered by the vesa settings i assume ? [16:50] apw, The vmware video devices are already blacklisted by grub-gfxpayload-lists [16:50] ok, so then it sounds like whatever this is using now is a candidate for blacklisting ? [16:50] apw, Must be. vesa is used by vbox when the guestadditions-x11 is absent. [16:51] so that is a vbox issue really, offering stupid resolutions by default [16:51] apw, Since 14.04. Yes. [16:51] apw, The 640x480 thing started sometime during 14.10. [16:51] and presumably it does that because they don't care about you if you don't install their video driver [16:52] apw, I couldn't possibly comment ;) [16:52] i wonder why i makes a difference to blacklist it in grub though, vesa must be very broken [16:52] and so i would think rather than being a fallback option to blacklist more things in grub, it might [16:52] be the appropriate option instead [16:53] apw, It is odd because when booting from the live media, resolution is 1024x768. [16:53] But on first install, resolution is 640x480. [16:53] right, that doesn't use grub, nor initialise the display [16:53] it uses syslinux [16:53] apw, Indeed. [16:53] grub initialises the display, because you know the vesa modes offered should be the preferred size of your display, so setting it up early makes sense and makes things prettier [16:53] unless your vesa config is spam [16:54] and has "1 1024x768 2 640x480 (default)" in it ... or equiv [16:54] So, possibly a regression in what Virtualbox provides. [16:55] but if we are blacklisting for vbox video anyhow, it may well make sense to blacklist everything when vbox is found [16:55] which is what i assume the wildcard you added does [16:55] apw, Yes. [16:55] Although, AKAIK, vbox have only ever used one device ID for video. [16:56] flexiondotorg, not that i really know why one would use vbox if you had any other choice [16:56] The other "work around" is to configure grub to use 'console' for all video output. [16:56] apw, It is very popular with people who just want to test. Low barrier of entry. [16:57] flexiondotorg, i don't find virtmgr any more complex to drive, and it idoesn't have these issue at least [16:57] apw, Agreed. [16:57] and i don't need 30k lines of random out of tree junk loaded into my kernle to make it work either [16:57] But, people do use vbox. Clearly the Ubuntu GNOME team do who reported this issue. [16:58] apw, So the question is. Is this fixable by the kernel team? Seems like a big fat "No" based on what we've discussed? [16:58] well they had much more ufn, they were just exploding in the host when they tried [16:59] flexiondotorg, i am not sure what we would fix, grub handed us a configured terminal, and we continued to use it as instructed [16:59] flexiondotorg, and presumably because vesa, it was at a stupid resolution [16:59] apw, That is a good answer. [16:59] i'll try your workaround on that same gnome image in vbox and see how it looks [17:00] apw, So I think that blacklisting the vbox video device in grub is the way forward. [17:00] apw, OK. Thanks for testing. [17:01] apw, I am the maintainer of Ubuntu MATE BTW. This issue was flagged up in Beta 2 QA and I decided to take a peek. [17:04] flexiondotorg, and i think the behaviour with the blacklist seems more useful, and i assume if i install the -guest-x11 i'll get go faster stripes [17:05] apw, Yes with guest-x11 install you get dynamic resizing and such. [17:05] flexiondotorg, but yes, i htink my prefrered option is this blacklist, and if it fixes the issues you have with locked disks that sounds liek a win [17:07] apw, Agreed. Although the inability to enter encryption pass phrases affects actual hardware too. By blacklisting vbox for grub you get a text mode plymouth which always works. [17:07] flexiondotorg, yeah, i assume we have a lot of issues there now we have systemd fun to play with [17:08] i guess i ought to reinstall some of my kit with that to find out [17:11] apw, systemd isn't to blame for passphrase entry. That was present in 14.10 also. [17:11] apw, My "solution" was not to ship a graphical plymouth theme in 14.10. That way only test mode available and pass phrase entry worked. [17:21] apw, Are you still testing this on an Ubuntu GNOME image or have we concluded that blacklisting is the solution? [17:29] i think we concur blacklisting is the way forward for the size issue [17:29] the plymouth not working is separate [17:38] apw, Thanks for your time. [17:38] flexiondotorg, thanks for paying attention to it :) [17:38] apw, I'll report back to cjwatson and he can make the blacklist change. [17:39] apw, Most welcome :) [17:39] ack, thanks === megabrutal is now known as MegaBrutal [22:13] I'd like to test a recent mainline bugfix that was "queued for 4.0". Someone on the launchpad bug page said "no longer affects: linux-lts-vivid". Can someone explain what that means? [22:14] The lts and vivid part confuses me. I'm on 14.04.2 - can I install that kernel build? Or do I go to 15.04 vivid and install it (why the lts)? [22:15] This is the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1414930?comments=all [22:15] Ubuntu bug 1414930 in HWE Next "[Lenovo ThinkPad X1 Carbon 20BT] Buttons of Synaptics trackpad doesn't work" [Medium,In progress] [22:58] Is this more of a dev chat? [23:37] squirrel