=== ezri is now known as rww
[00:36] <phillw> yikes!!.. Well, back in 14.04 kernel time when I built a non-pae kernel it worked, but would not work under "LiveCD" install. I was told about 'aufs' and we did build successful kernel http://phillw.net/isos/non-pae/  is there a link for the 4.4 kernel ?
[00:41] <apw> phillw, link for what exactly?
[00:44] <phillw> apw: That link will build a kernel and stuff, but there was something to do with aufs that was needed. I'm really sorry that I have updated / changed my computer and I do not keep the inks on the wiki page. 
[00:45] <apw> phillw, sadly i don't think i know waht that means ..
[00:47] <phillw> apw: have a look at   http://aufs.sourceforge.net/
[00:47] <phillw> it has the list
[00:49] <apw> phillw, i don't understand what you are asking?  our 4.4 kernel has aufs applied
[00:49] <phillw> the AUFS is required to have an ISO that can run from CD / DVD / USB
[00:49] <phillw> apw: that was the question!!!
[00:50] <utlemming> hey guys...I'm using the mainline 4.5 kernel (i915 is unstable on 4.2). I've noticed high load on the 4.4 and 4.5 kernels for my Intel Mobile processor. I just filed https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1544798
[00:50] <ubot5`> Launchpad bug 1544798 in linux-meta (Ubuntu) "high load with 4.4 and 4.5 kernels for Intel Mobile processors" [Undecided,New]
[00:50] <apw> phillw, overlayfs is required for the iso
[00:51] <apw> phillw, but clearly whatver is needed is in our kernel else our iso's would not boot
[00:51] <phillw> apw: so, if I take the ubuntu 4.4 and knock it back to non-pae what does it need
[00:52] <apw> phillw, it needs PAE configuration turned off
[00:52] <apw> in the config
[00:52] <phillw> apw: the kernel would boot, I apologise as I'm going back to 3.13 which was 14,04
[00:52] <utlemming> just thought that I would let you guys know to get this on the radar for 16.04
[00:53] <apw> utlemming, well its filed againsts the wrong package, so a good job you did bring it up
[00:53] <apw> are we sure this isn't the load being reported higher becuase the cpu is being clocked slower to save power that cking investigated though
[00:53] <apw> jsalisbury, ^ a bug for investigation perhaps, and moving to linux
[00:54] <jsalisbury> apw, ack, I'll take a look
[00:54] <utlemming> apw: whoops, and thank you :)
[00:54] <phillw> apw: I have that part, it worked well, but the kernel so produced needed aufs - that part of the instructions I have lost over the last couple of years. I know that non-pae is not high on the list and I reckon I could still manage that, but the aufs for live CD boot I'm 2 years behind on.
[00:55] <apw> phillw, iso does not require aufs, it requires overlayfs, but both of those are in the ubuntu 4.4 kernel and enabled
[00:55] <apw> phillw, so i still do not know what you are asking me
[00:58] <phillw> apw: would you be so kind as to look over https://wiki.ubuntu.com/phillw/non-pae and either write a long list of where things have changed, or have an edit. It's not the biggest job. 
[00:59] <phillw> apw: I'll buy you coffee :D
[01:02] <apw> it looks close enough
[01:03] <phillw> apw: so, we do not need to add in aufs now.. it is in the main kernel? ... I'm starting to remember that it was actually a bug back then :)
[01:04] <apw> phillw, all of our kernel sources have the bits they need to make an ISO work, and it all enaled
[01:04] <apw> enabled
[01:04] <phillw> apw: I owe you coffee.. please email me your ppal name to phillw@linuxpadawan.net 
[01:04] <apw> phillw, no need
[01:05] <phillw> apw: do we still turn off the CONFIG_DEBUG_INFO
[01:05] <apw> phillw, if you are building out of PPA yes, in PPA no
[01:06] <phillw> apw: Why does a local build produce such enormous packages? Our build includes CONFIG_DEBUG_INFO in order to produce linux-debug-image packages. We then manually strip the modules after build.
[01:07] <apw> it is about those being 5GB in size
[01:07] <phillw> maybe a little large for a cd :)
[01:08] <phillw> hehe... thanks a lot. i will be honest, I was expecting "you want to do WHAT?!!", instead you have told me that I can at least have a 1st roll of the 4.4 kernel
[01:10] <phillw> apw: last big ask... what is the link for xenial 4.4 as opposed to  https://launchpad.net/ubuntu/trusty/+source/linux/3.13.0-8.27/+files/linux_3.13.0.orig.tar.gz ?
[01:11] <apw> phillw, you should work from the git repo, apply the config delta, then you can rebase it later
[01:15] <phillw> apw: that will make more sense to a padawan who wants to learn deeper kernel, But with others sniggering in other channel as I explain I do not understand. could you explain "you should work from the git repo, apply the config delta, then you can rebase it later" to some one who does not use git ?
[01:18] <phillw> wxl: and it appears that aufs is now enabled by default, instead of what melodie and my self had to do with the  3.13 kernel for 14,04
[01:19] <apw> phillw, git is a version control system, i am suggsting you get your source from our master git repo
[01:19] <apw> do the configuration edit in that tree
[01:19] <apw> and then commit that, as that is then rebasable
[01:21] <phillw> apw: all I need to do is alter the " High Memory Support" from 64GB to 4 GB and then respin the kernel.
[01:21] <apw> sounds abut right
[01:22] <phillw> the requirement for non-PAE kernel is growing smaller, but as lubuntu and other teams do support older kit.. I do make available such a kernel for community repsins.
[01:23] <apw> phillw, it woul dmake sense to do that via a PPA imo
[01:25] <phillw> apw: Well, I'd have to ask for help on that... it is an area well out of my known stuff..... But, I do have a guy who knows c, etc building debs etc and would like to get to understand kernel building a lot more.
[01:26] <phillw> It is actually having him as a padawan that reminded me that I may may be due to make a new 4.4 kernel (at least ubuntu and kernel are back in sync)
[01:27] <apw> phillw, all you need to do is apply the delta change, and build a src package as normal (you do that already for other packages) and upload that to a ppa
[01:28] <phillw> okies, great!!
[05:55] <rui1> \exit
[09:16] <ppisati_> smb: it's me, for real!
[09:17] <ppisati_> ppisati: who are you? liar!
[09:19] <smb> ppisati_, suffering from (net) split personalities
[13:16] <cristian_c> jsalisbury: hi
[18:19] <lamont> jsalisbury: 4.4.0-040400rc1-generic == FAIL
[18:20] <lamont> jsalisbury: holler when you have your first kernel in the bisect series for me?
[18:35] <jsalisbury> lamont, I'll start the build now
[18:38] <lamont> kewl
[18:40] <lamont> jsalisbury: curious -- how long is your buildtime?
[18:41] <jsalisbury> lamont, probably about 20 minutes
[18:41]  * lamont as an appt that he will be leaving for in about 5 minutes, back in about 2 hours or so..
[18:41] <jsalisbury> lamont, there will be about 10 of them to test, so I'll just keep posting links in the bug
[18:41] <lamont> which is to say, I'll test it when I get back...
[18:41] <lamont> jsalisbury: works for me
=== Elimin8er is now known as Elimin8or
[20:42] <cristian_c> jsalisbury: hi, again
[20:44] <jsalisbury> cristian_c, hey
[20:48] <cristian_c> jsalisbury: I've read your question in launchpad
[20:54] <cristian_c> jsalisbury: sorry, I've never created a patch file
[20:57] <jsalisbury> cristian_c, that's not a problem.  I can submit it, I wasn't sure if you discussed the fix with upstream or not.
[20:59] <cristian_c> jsalisbury: ok
[21:03] <lamont> jsalisbury: empty directory at your lin
[21:03] <lamont> link
[21:03] <jsalisbury> lamont, ok, let me check
[21:05] <jsalisbury> lamont, ok, they are there now.
[21:05] <lamont> yep
[21:13] <lamont> jsalisbury: updating the bug: good kernel
[21:13] <jsalisbury> lamont, great, I'll build the next one
[21:14] <lamont> bonus points if you put it somewhere I can rsync...
[21:14] <lamont> will this next one be 4.3.0-040301?
[21:14] <lamont> or should I clear out the test each round?
[21:16] <jsalisbury> lamont, the script used to build the kernels puts a date stamp in the name, and it could start with 4.4 as it bounces back and forth between good and bad kernels.
[21:16] <lamont> ack
[21:16]  * lamont clears out the cruft, just to be sure
[21:26] <jsalisbury> lamont, The next kernel is building.  I just scp the .deb files to that public web server.  I can scp them anywhere you want, as long as I have access.
[21:32] <lamont> jsalisbury: mombin.c.c:~/lamont would be a fine target
[21:37] <jsalisbury> lamont, is that accessable from the Canonical network?  I can't seem to get there
[21:38]  * lamont is going over the vpn, but it should otherwise be reachable
[21:38] <lamont> alternatively, sftp to people.u.c
[21:39] <lamont> which doesn't help me..  so nm people.u.c
[21:40] <jsalisbury> lamont, I can get to mombin, so I'll put them in your home directory
[21:40] <lamont> ~/lamont, not ~lmaont
[21:40] <lamont> that is, toss 'em where you can put them (write perms being such), and I'll pul from your home dir
[21:40] <lamont> we have read access to each other's directories, but not write
[21:41] <jsalisbury> lamont, ok, I'll just put em in my home dir
[21:45] <jsalisbury> lamont, looks like my build server can't get to mombin or people, but my desktop can.  The next kernel is ready so I'll just scp it to kernel.ubuntu.com and see if I can figure out a way for you to rsync
[21:45] <lamont> sure
[21:46] <lamont> jsalisbury: from the land of hahaha lamont, I have a login on kernel.u.c, beacuse of kernel-team
[21:46] <lamont> rather, kernel_devs
[21:46] <lamont> so definitely just throw it somehwere there
[21:47] <jsalisbury> lamont, ok, next kernel is there.  I posted to the bug to, so I can keep track of where we are in the bisect and what kernels were good/bad
[21:47] <lamont> yep
[21:52] <lamont> jsalisbury: good.  updated.