[08:15] <LLStarks> hi, how do i build my own kernel ppa?
[10:34] <dileks> hi
[10:35] <dileks> LLStarks: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[10:35] <dileks> BTW, see topic :-)
[11:17] <LLStarks> dileks, if i want to ppa really exotic and bleeding edge code without a debian folder, am i screwed?
[11:17] <LLStarks> cuz i  suck at packaging
[11:23] <dileks> LLStarks: whats your goal?
[11:24] <LLStarks> dileks, drm-next is packaged, but i want to package airlie's drm-dmabuf2 tree
[11:25] <LLStarks> i can build the debs, but i have to clue how to translate that to a ppa
[11:25] <dileks> dunno if all patches from ubuntu apply then
[11:25] <LLStarks> it's a vanilla kernel
[11:26] <LLStarks> plus his upstream work
[11:26] <dileks> I am building with 'make deb-pkg'
[11:26] <dileks> its fine for (fast) testing from any kernel GIT tree
[11:27] <LLStarks> not make-kpkg?
[11:27] <dileks> build_linux-with-deb-pkg.sh: http://paste.ubuntu.com/981526/
[11:28] <dileks> dunno if make-kpkg still works, it was never my 1st choice
[11:29] <LLStarks> concurrency 1-
[11:29] <LLStarks> *10
[11:30] <LLStarks> isn't that excessive even on a quadcore with ht?
[11:30] <LLStarks> gonna pass out while this builds
[11:31] <dileks> a wise man gave me that empirical formula (longterm experiences): max_make_jobs = core(s) x2 +1
[11:32] <LLStarks> is that assuming threads>cores?
[11:32] <dileks> you can reduce make-jobs-no of course
[11:32] <dileks> even on pentium-m =5 was OK
[11:33] <LLStarks> either way, j8 takes at least 20 minutes to build a full ubuntu kernel and this is a 2630qm
[11:33] <LLStarks> too afraid to strip stuff
[11:33] <dileks> BTW...
[11:34] <dileks> http://nopaste.snit.ch/139833
[11:35] <dileks> if you dont need... CONFIG_DEBUG_INFO=n
[11:35] <LLStarks> thx
[11:35] <LLStarks> sleep time
[11:35] <dileks> it gets huge
[11:35] <dileks> not only deb-files
[11:35] <dileks> your local build-dir explodes to some GiB
[11:36] <dileks> IIRC there is one debug-info-reduce kernel-config. dunno how much space this saves and whats with "all" debug-symbols
[11:37] <dileks> CONFIG_DEBUG_INFO_REDUCED
[18:17] <JanCeuleers> Guys, I would like to highlight the RAID corruption bug introduced in upstream commit c744a65c1e2d59acc54333ce8 and fixed by commit 30b8aa9172dfeaac6d77897c67ee9f9fc574cdbb
[18:18] <JanCeuleers> The md subsystem maintainer (Neil Brown) observes today on the linux-raid mailing list that Ubuntu appears to be more susceptible to this problem than other distros
[18:18] <JanCeuleers> Would it be possible to expedite deployment of the fix?
[18:18] <JanCeuleers> The problem causes RAID metadata to be damaged upon shutdown, so that the array can't be reassembled after reboot
[19:42] <sforshee> JanCeuleers, the fix is already in the kernel in precise-proposed, so it will be in the next update
[19:53] <JanCeuleers> That's great, thank you.
[19:53] <JanCeuleers> Just want to mention that the longer it takes for the fix to become official, the more people will get stung by this.
[19:54] <JanCeuleers> (I'm not one of them)
[22:28] <dileks> https://01.org/powertop/blogs/ceferron/2012/powertop-v2.0-release
[23:16] <luc4_mac> Hi! I'm experiencing network shutdowns when system is inactive. Anyone who knows if this is something known?
[23:16] <dileks> looked into logs?
[23:18] <luc4_mac> dileks: yes, I posted those in a bugreport, I couldn't see anything strange. The fact is that I just reproduced the problem now in an hour and I noticed it is sufficient that the kernel recognizes a plugged mouse to restore the network.
[23:18] <luc4_mac> bugreport is 997767
[23:19] <luc4_mac> I didn't think it was kernel-related, but now I'm starting to think it might
[23:19] <luc4_mac> only think I see in dmesg is the mouse plugged in
[23:21] <dileks> [68627.945751] TCP: Possible SYN flooding on port 6882. Sending cookies.  Check SNMP counters.
[23:21] <luc4_mac> dileks: yes, I have it now as well.
[23:21] <luc4_mac> do you think it may be related?
[23:23] <dileks> dunno
[23:23] <dileks> you tried static-IP setup instead of dhcp?
[23:24] <luc4_mac> dileks: you mean stopping the dhcp server?
[23:25] <dileks> for static-IP you dont need a dhcp-server
[23:27] <luc4_mac> dileks: yes, but this box also has a dhcp server that I don't think I'm using anymore. Do you mean I have to try to stop the server or that I have to configure the ethernet interface to not use the real dhcp server?
[23:29] <dileks> dont start services you dont need
[23:29] <luc4_mac> dileks: it is a temporary situation… anyway ok, I can try to stop that and to configure static assignment
[23:31] <luc4_mac> Oh… I see from dmesg that isc-dhcp-server terminated incorrectly many times.
[23:33] <dileks> yupp, thats why I asked you to try static-IP
[23:34] <luc4_mac> 6882 is related to torrent i see… maybe I should also stop anything related to that...
[23:41] <luc4_mac> dileks: I didn't mention anyway that without X/KDE I couldn't reproduce the problem
[23:43] <dileks> doesnt kde has a nm-frontend (nm-service)?
[23:43] <luc4_mac> yes
[23:44] <luc4_mac> I mean that I simply shutdown X and KDE and the connection stayed up for the entire day.
[23:49] <dileks> sounds like wake-on-lan is activated in your bios
[23:50] <luc4_mac> possible. Why?
[23:52] <dileks> if you say shutdown computer
[23:53] <luc4_mac> sorry, maybe I explained myself the wrong way. I shutdown the X server. I remained in the terminal without X running.
[23:55] <dileks> inspect with netstat 
[23:56] <luc4_mac> what exactly? This problem has started with 12.04. Never had this problem before. This desktop stays up 24h.
[23:57] <dileks> open ports/connections
[23:57] <dileks> network*
[23:59] <luc4_mac> At the moment I have less than 20 connections. The problem is that when the problem occurs I cannot debug. Pluggin a mouse in the port is sufficient to start the network and solve the issue.