[00:28] <AceLan> apw: got it, thanks. BTW, I always use lts-backport-xxx branch on precise and trusty tree :p
[10:21] <Odd_Bloke> 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] <Odd_Bloke> apw, bjf: ^ ?
[10:25] <apw> 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] <apw> and remind me what PTS means
[10:25] <Odd_Bloke> apw: That makes two of us. ;)
[10:26] <Odd_Bloke> apw: I _think_ PTS==Phoronix Test Suite.
[10:27] <Odd_Bloke> But if it's not obvious to you, then I should probably check what utlemming meant by it.
[10:38] <apw> Odd_Bloke, could be, not a phrase i use most days for sure
[10:39] <apw> Odd_Bloke, smoke testing is mormally "basic does it boot and give me a prompt" style testing
[10:41] <Odd_Bloke> Yeah; I think this is a bit of a confused task.
[10:41] <Odd_Bloke> I'll check with Ben when he's back in on Monday.
[10:41] <Odd_Bloke> apw: Sorry for the noise! :)
[10:42] <apw> Odd_Bloke, np and good luck with that
[12:17] <bguthro> 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] <bguthro>  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] <bguthro> I suspect there's a wiki page out there somewhere, but I've been unable to find it.
[12:43] <apw> bguthro, you need to remove the build stamp, and then you can rerun the command, stamps are in debian/stamps
[12:44] <bguthro> apw, fantastic - thank you much!
[15:29] <Odd_Bloke> 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] <apw> Odd_Bloke, so it is phoronix, just a local copy
[15:33] <Odd_Bloke> It's a wrapper around the Ubuntu package.
[15:33] <Odd_Bloke> (TIL there's an Ubuntu package for Phoronix)
[16:04] <flexiondotorg> I been discussing https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/ with cjwatson in #ubuntu-devel
[16:04] <flexiondotorg> I've got the following work around - https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/comments/17
[16:05] <flexiondotorg> cjwatson is prepare to update grub-gfxpayload-lists if someone here can confirm "fixing" this issue at a kernel level is hopeless.
[16:05] <flexiondotorg> So, thoughts?
[16:09] <flexiondotorg> ogasawara, Can you direct me to someone I can discuss the above with please?
[16:24] <apw> flexiondotorg, "fixing" at the kernel level, do we know what the issue is ?
[16:24] <apw> flexiondotorg, the implication of the (admittedly older) comments is that you need virtualbox-guest-x11
[16:31] <apw> 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] <apw> seems it has a vbox specific video drivers
[16:48] <apw> i wonder if they should be being installed by jockey
[16:49] <flexiondotorg> apw, So the issue is the default resolution when virtualbox-guest-x11 is not installed.
[16:50] <apw> the default resolution is that offered by the vesa settings i assume ?
[16:50] <flexiondotorg> apw, The vmware video devices are already blacklisted by  grub-gfxpayload-lists
[16:50] <apw> ok, so then it sounds like whatever this is using now is a candidate for blacklisting ?
[16:50] <flexiondotorg> apw, Must be. vesa is used by vbox when the guestadditions-x11 is absent.
[16:51] <apw> so that is a vbox issue really, offering stupid resolutions by default
[16:51] <flexiondotorg> apw, Since 14.04. Yes.
[16:51] <flexiondotorg> apw, The 640x480 thing started sometime during 14.10.
[16:51] <apw> and presumably it does that because they don't care about you if you don't install their video driver
[16:52] <flexiondotorg> apw, I couldn't possibly comment ;)
[16:52] <apw> i wonder why i makes a difference to blacklist it in grub though, vesa must be very broken
[16:52] <apw> and so i would think rather than being a fallback option to blacklist more things in grub, it might
[16:52] <apw> be the appropriate option instead
[16:53] <flexiondotorg> apw, It is odd because when booting from the live media, resolution is 1024x768.
[16:53] <flexiondotorg> But on first install, resolution is 640x480.
[16:53] <apw> right, that doesn't use grub, nor initialise the display
[16:53] <apw> it uses syslinux
[16:53] <flexiondotorg> apw, Indeed.
[16:53] <apw> 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] <apw> unless your vesa config is spam
[16:54] <apw> and has "1 1024x768 2 640x480 (default)" in it ... or equiv
[16:54] <flexiondotorg> So, possibly a regression in what Virtualbox provides.
[16:55] <apw> but if we are blacklisting for vbox video anyhow, it may well make sense to blacklist everything when vbox is found
[16:55] <apw> which is what i assume the wildcard you added does
[16:55] <flexiondotorg> apw, Yes.
[16:55] <flexiondotorg> Although, AKAIK, vbox have only ever used one device ID for video.
[16:56] <apw> flexiondotorg, not that i really know why one would use vbox if you had any other choice
[16:56] <flexiondotorg> The other "work around" is to configure grub to use 'console' for all video output.
[16:56] <flexiondotorg> apw, It is very popular with people who just want to test. Low barrier of entry.
[16:57] <apw> flexiondotorg, i don't find virtmgr any more complex to drive, and it idoesn't have these issue at least
[16:57] <flexiondotorg> apw, Agreed.
[16:57] <apw> and i don't need 30k lines of random out of tree junk loaded into my kernle to make it work either
[16:57] <flexiondotorg> But, people do use vbox. Clearly the Ubuntu GNOME team do who reported this issue.
[16:58] <flexiondotorg> 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] <apw> well they had much more ufn, they were just exploding in the host when they tried
[16:59] <apw> 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] <apw> flexiondotorg, and presumably because vesa, it was at a stupid resolution
[16:59] <flexiondotorg> apw, That is a good answer.
[16:59] <apw> i'll try your workaround on that same gnome image in vbox and see how it looks
[17:00] <flexiondotorg> apw, So I think that blacklisting the vbox video device in grub is the way forward.
[17:00] <flexiondotorg> apw, OK. Thanks for testing.
[17:01] <flexiondotorg> 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] <apw> 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] <flexiondotorg> apw, Yes with guest-x11 install you get dynamic resizing and such.
[17:05] <apw> 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] <flexiondotorg> 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] <apw> flexiondotorg, yeah, i assume we have a lot of issues there now we have systemd fun to play with
[17:08] <apw> i guess i ought to reinstall some of my kit with that to find out
[17:11] <flexiondotorg> apw, systemd isn't to blame for passphrase entry. That was present in 14.10 also.
[17:11] <flexiondotorg> 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] <flexiondotorg> apw, Are you still testing this on an Ubuntu GNOME image or have we concluded that blacklisting is the solution?
[17:29] <apw> i think we concur blacklisting is the way forward for the size issue
[17:29] <apw> the plymouth not working is separate
[17:38] <flexiondotorg> apw, Thanks for your time.
[17:38] <apw> flexiondotorg, thanks for paying attention to it :)
[17:38] <flexiondotorg> apw, I'll report back to cjwatson and he can make the blacklist change.
[17:39] <flexiondotorg> apw, Most welcome :)
[17:39] <apw> ack, thanks
[22:13] <bubba2> 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] <bubba2> 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] <bubba2> This is the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1414930?comments=all
[22:58] <bubba2> Is this more of a dev chat?
[23:37] <bubba2> squirrel