=== hughhalf is now known as hugh_afk
[02:47] <calc> has anyone reported yet that the drm-intel-nightly builds are broken?
[02:48] <calc> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/
[02:49] <calc> it started back up yesterday but the build.log indicates its not finding the git commit for checkout
=== gerald is now known as Guest43864
=== AceLan_ is now known as AceLan
=== FreezingAlt is now known as FreezingCold
[08:59] <apw> calc (N,BFTL), seem so indeed, will investigate
[13:48] <Odd_Bloke> I'm running the ubuntu_ecryptfs tests in a pristine VM (using ./runner ubuntu_ecryptfs) and I'm seeing "/bin/bash: make: command not found" for every test it is running.
[13:48] <Odd_Bloke> Is there an expectation that make/build-essential will already be installed, or is the test missing some setup?
[13:52] <cking> Odd_Bloke, i believe build-essential is assumed, but I'm not sure what the ./runner is doing or meant to expect for the minimal install config 
[13:53] <cking> Odd_Bloke, if you want to just run the eCryptfs tests, perhaps the following notes are useful: http://smackerelofopinion.blogspot.co.uk/2012/08/testing-ecryptfs.html 
[13:55] <Odd_Bloke> cking: I'm working on running the kernel tests on cloud instances, and just chose one at random.  I'll ensure build-essential is installed. :)
[13:56] <cking> Odd_Bloke, have you also considered hammering it to death with stress-ng? http://kernel.ubuntu.com/~cking/stress-ng/
[14:00] <Odd_Bloke> cking: I haven't, but I will now. :)
[14:00] <cking> it can make the vm subsystem cry
[14:37] <bjf> Odd_Bloke, when running the tests i have a separate step for installing all the dependent pkgs
[14:45] <Odd_Bloke> bjf: Cool, noted.  I'm working on tooling around the kernel tests; are there any tests that run particularly quickly (so I can have a quick turn-around while testing Jenkins job wrappers etc.)?
[14:45] <bjf> Odd_Bloke, ubuntu_qrt_kernel_security
[14:53] <Odd_Bloke> Thanks!
=== tsimpson is now known as lubotu1
=== lubotu1 is now known as tsimpson
[19:20] <cmagina> so, the latest utopic-proposed kernel, 31.43 does not contain any of the stability fixes (specifically the arm64 fix), when can i expect those to land?
[19:20] <cmagina> they all appear to be in the 32.42 tag
[20:01] <infinity> cmagina: 32.42 and 31.43 will be merged into 32.44 (or similar), and the SRU cycle will continue.  This was a single-commit security update that superseded the SRU.
[20:04] <cmagina> infinity: i figured as much, just checking on a possible time table, thanks
[20:28] <mozmck> I would like to build a kernel with the preempt-rt patch and make .debs that would be widely compatible with ubuntu 14.04 systems.  Can I copy the debian and debian.master directories to a mainline kernel that is supported by preempt-rt patches and use that?
[20:28] <mozmck> Or would it be better to use make-kpkg?
[20:29] <mozmck> I would like to have the .config be as close to the same as the ubuntu kernel as I can.
[21:12] <DalekSec> apw: Hello, I'm unsure where to make the proposal, but can you add linux-initramfs-tool as an alt dep in the kernels to "fix" bug 1109029?
[21:12] <ubot5> bug 1109029 in linux (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Triaged] https://launchpad.net/bugs/1109029
[21:42] <apw> DalekSec, that is likely a viable thing to do, though i'd need to discuss the packaging ramifications before one could commit, which series would that affect??
[21:43] <apw> mozmck, we copy in the debian and debian.master from a "close" version when we make mainline builds for this
[21:43] <apw> mozmck, so it hsould be viable
[21:44] <infinity> apw: It's not a particularly useful thing to do, as nothing in userspace has changed, but that also means it's entirely harmless for you to do. :P
[21:44] <DalekSec> apw: Devel (vivid) would make the most sense, and FWIW I stripped out initramfs-tools, added dracut which regenerated the initrds, and rebooted.  Kernel worked.
[21:44] <infinity> (Since any normal Ubuntu system will pretty much be forced to have initramfs-tools, regardless of the kernel's alt dep)
[21:45] <apw> infinity, yeah i assumed this was to allow playing with dracult rather than a plan for us to change any time soon
[21:45] <apw> and that its just vivid seems ok for testing then
[21:45] <DalekSec> infinity: There's not all that much preventing it from functioning, plymouth needs a few things merged from Debian and just some alt deps missing.  I'm going to try in an encrypted LVM soon and see how badly that breaks. :D
[21:47] <infinity> DalekSec: I'm sure it more or less works, but we won't support it.  That's no reason to actively block people using it, however.
[21:47] <DalekSec> infinity: Excatly my thought, glad you agree.
[21:49] <infinity> DalekSec: I will confess, I'll never understand people's obsession with replacing working software with something else, though.  *shrug*
[21:49] <infinity> And, no, "it integrates with systemd" is not an argument, because a full-featured init in your initrd and pivoting back to your initrd because clean shutdowns are "hard" aren't features.
[21:49] <apw> infinity, because "someone" tells their s/w is the one and only way
[21:50] <infinity> apw: Harald hasn't typically had much of an ego about dracut, he and I have had many good talks about the differences between the two.  But it does seem that getting caught up in the systemd vortex has changed how lots of other people see it.
[21:50] <DalekSec> infinity: It's like playing with systemd before it's in Ubuntu.  Do I plan to play with dracut?  Sure.  Would it be interesting to see what one can do with it?  Sure.  Would I put it on a production system?  Heck no.
[21:51] <retabell> apw: will you have a look at 1426113, maybe it was the wrong place where i filled a bug
[21:51] <retabell> ?
[21:53] <apw> bug #1426113
[21:53] <ubot5> bug 1426113 in linux (Ubuntu) "devel: vbox drivers introduce symlinks which prevent use of orig.tar.gz" [High,Fix released] https://launchpad.net/bugs/1426113
[21:54] <apw> retabell, ? that is a bug i filed, and fixed
[21:54] <retabell> yes, i posted a patch, maybe wrong place..
[21:54] <retabell> check if symlink exist
[21:55] <apw> retabell, ok, that fix got applied separatly when it blew up for me later, whats in the repo now should have the same effective form
[21:57] <infinity> apw: Why does "[ ! foo ] && action" always bug me so much?
[21:57] <apw> retabell, let me know if not, in general when you find a new issue like that a new bug and mentioning it in the old is good
[21:58] <apw> infinity, becuase it is totally vile, but its short
[21:58] <infinity> apw: I know POSIX ignores failure in a pipe like that, so it's fine, but it feels like it's missing the "else".
[21:58] <infinity> apw: Yeah, I prefer the inverted (and shorter) form: "[ foo ] || action"
[21:58] <apw> infinity, i should have done it as a loop with a fully formed if in the thing
[21:59] <apw> then all of us would have been happy ... and i should have made that script read the debian/foo file which has the list in too
[21:59] <apw> and ... life shouldn't suck and it hsould cope with bloody links
[22:00] <infinity> apw: I wasn't at all arguing for readability or verbosity, just a serious OCD issue on my part with a pipe that obviously has a false evaluation in it and *should* fail, if POSIX wasn't broken. :P
[22:00] <retabell> apw ok thx
[22:02] <apw> retabell, thanks for reporting, if we hadn't noticed (because it was so severe) i would have been more appreciative :)
[22:03] <retabell> i think this only happens when build the source with quilt
[22:04] <retabell> rules clean seems to be called twice
[22:05] <apw> retabell, or if you clean your tree twice and make a tarball indeed
[22:05] <retabell> yes
[22:06] <apw> which is how i noticed it, someone here had a proceedure which did so, cleaning, then -S without -nc
=== hugh_afk is now known as hughhalf