[00:16] <BarkingFish> ok guys, well I'm gonna have to head out. jsalisbury - if you see this, I'll stop by some other time - but I'm needed in ER, so I'm out for the night. See ya
[06:53] <jussi> hrm, Im on 12.10 and a kernel update is giving me issues. tbh, I quite scare to restart the machine...  paste of apt-get install -f http://paste.ubuntu.com/1615272/
[06:54] <jussi> its way too early in the morning, so forgive me if it is something simple
[07:14] <ashwini_> Can any one tell me the default stack size for kernel 3.x and 2.6.y (y < 31)???
[07:39] <ppisati> good morning Viet^W^W^W^Wworld
[07:47]  * jussi hugs ppisati and bribes him with coffee and breakfast for some help :D
[07:48] <ppisati> jussi: what's up?
[07:48] <jussi> [08:53:39] <jussi> hrm, Im on 12.10 and a kernel update is giving me issues. tbh, I quite scare to restart the machine...  paste of apt-get install -f http://paste.ubuntu.com/1615272/
[07:48] <jussi> [08:54:36] <jussi> its way too early in the morning, so forgive me if it is something simple
[07:49] <ppisati> jussi: gzip: stdout: No space left on device
[07:50] <jussi> ppisati: errr? this is my laptop... is that /boot ? or just my HDD  is full (shouldnt be...)
[07:50] <ppisati> jussi: dunno, df -h will tell you
[07:50] <ppisati> jussi: but i guess is /boot
[07:50] <jussi> /dev/sda1                   228M  226M     0 100% /boot
[07:51] <jussi> yep
[07:51] <jussi> right...
[07:51] <jussi> so I guess old kernels need moving on then? 
[07:51] <ppisati> dpkg -l | grep linux-image
[07:51] <jussi> http://paste.ubuntu.com/1615707/
[07:52] <ppisati> jussi: i think you know what to do from here
[07:52] <jussi> ppisati: yeah, I think so. --purge them, right? 
[07:53] <ppisati> jussi: except for the running one, yes
[07:54] <jussi> ppisati: what are the -extra images? 
[07:54] <ppisati> jussi: stuff that was moved out of linux-image
[07:54] <ppisati> jussi: dpkg -L will tell you
[07:57] <jussi> thanks ppisati, much appreciated.
[09:16] <caribou> where is the linux-meta package maintained ? In launchpad or somewhere in the kernel tree ?
[09:16] <smb> caribou, neither. In a git repo seperate to the kernel
[09:17] <caribou> smb: and how one propose a patch ? (can you see the linux-crashdump dependency on kdump-tools coming ;-) ) ?
[09:18] <smb> caribou, Right, I actually was thinking of submitting that soon
[09:18] <caribou> smb: ok, then, I won't bother
[09:18] <caribou> smb: afaik, once this is done, kdump-tools should be pulled in main
[09:19] <caribou> smb: since linux-crashdump will depend on it, and the makedumpfile source is already in main
[09:20] <smb> caribou, Not sure how strict dependency issues are for a meta package but it sounds reasonable to have those things that are core functions in main
[09:21] <caribou> smb: don't know about meta package either, I can check 
[09:21] <ashwini_> any clue regarding default stack size in the kernel 3.x and 2.6.28+ ?
[09:29] <smb> caribou, Talking to apw it sounds like having the dependency in meta will require some parts to be in main. Just not sure whether this can only be the source package or not. So maybe that should be resolved before changing the meta package.
[09:30] <smb> caribou, Just as for what needs to be in main and what would that mean (mostly security updates? and would we think there are?)
[09:30] <caribou> smb: I just pinged pitti in #ubuntu-devel; he seems to think so
[09:31] <caribou> smb: well, the security updates would make it in from makedumpfile which is already in main anyway, isn't it ?
[09:32] <smb> caribou, From that side yes. Guess the only thing I can think of right now is the tools placing dumps with not enough limited access...
[09:44] <apw> ashwini_, i belive they can be either 4K or 8K on x86 I believe we use 8K but i am struggling to find the confirmation
[09:47] <apw> ashwini_, THREAD_SIZE is the relevant define
[09:49] <ashwini_> apw: THREAD_SIZE is 8k, I belive in new kernels the stack size is 4k instead of 8k. just want to confirm once. Any way Thanks
[09:49] <apw> ashwini_, in v3.8-rc's it seems unchanged
[09:50] <ashwini_> apw : is STACK size 8k ? or THREAD_SIZE 8k ? any link?
[09:51] <apw> THREAD_SIZE is 8K, which is the kernel stack size, which is documented in kernel source in Documention/x86/x86_64/kernel-stacks and obviously set in the arch specific headers in the source
[09:52] <apw> arch/x86/include/asm/page_32_types.h:#define THREAD_SIZE_ORDER  1
[09:52] <apw> arch/x86/include/asm/page_64_types.h:#define THREAD_SIZE_ORDER  1
[09:52] <apw> here defined in allocator order, 0 == 4K 1 == 8K on x86
[10:13] <ashwini_> apw : Thanks, your help and pointers much appreciated
[10:13] <ashwini_> apw: it resolved my lot of doubts
[10:50] <ogra_> apw, one for us to test (later today) http://nv-tegra.nvidia.com/gitweb/?p=chromeos/kernel.git;a=commitdiff;h=b50bf5979036750891461a5824bb12273f04fe16 ... from bug 1080789
[10:50] <ubot2> Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,Confirmed] https://launchpad.net/bugs/1080789
[11:09] <apw> ogra_, sigh
[11:24] <ogra_> apw, no hurry for that one, itr only exposes if you have a mouse attached to the tablet, thats rather low prio and can well wait until the next upload happens anyway
[11:45]  * ppisati notices there's sun outside and goes out for lunch
[11:48] <smb> sun... lucky bastard
[11:57] <apw> ogra_, that patch looks to be from a completely different kernel version, cirtainly none of the things it changes seem to exist
[12:42] <apw> ogra_, after a fair bit of looking i cannot trivially find anything remotly similar to apply it by hand
[13:05] <ogra_> apw, ok
[13:14] <apw> ogra_, i recon it would be appropriate to do the testing as recommended in the bug
[13:14] <apw> ogra_, it can only eliminate something
[13:15] <AlexMG> Hi guys, I was trying to use the fetch=url parameter, to netboot filesystem from the ubuntu-livecd. But it seems as the fetch parameter is just ignored. Are changes needed inside the initrd or do I just use the wrong kernel options? KERNEL-Options loaded from iPXE: kernel http://192.168.1.50/httpboot/ubuntu-x64-live/vmlinuz boot=casper config fetch=http://192.168.1.50/httpboot/ubuntu-x64-live/filesystem.squashfs
[13:15] <ogra_> well, the kernel patch is for consoles, which dont work at all anyway (you cant switch to console once X is up, restriction of the driver )
[13:16] <ogra_> so i guess we can as well skip it
[13:27]  * henrix wanders if something killed a ppc build or it was a genuine build failure
[13:29] <rtg_> herton, henrix: did you notice the Quantal PPC FTBS ?
[13:29] <rtg_> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4277902/+files/buildlog_ubuntu-quantal-powerpc.linux_3.5.0-24.36_FAILEDTOBUILD.txt.gz
[13:29] <henrix> rtg_: yep, i was just complaining about that :)
[13:30] <henrix> rtg_: no idea what went wrong there...
[13:30] <henrix> i guess i'll just retry
[13:30] <herton> henrix, it's a build failure in alx driver
[13:30] <rtg_> henrix, looks like a bonafide linker error
[13:30] <henrix> hmmm?
[13:30] <herton>  /build/buildd/linux-3.5.0/ubuntu/alx/alx_main.c: In function 'alx_alloc_rings':
[13:31] <henrix> herton: oh, crap! you're right
[13:32] <henrix> looks like its failing only on ppc. amd64, i386 and armhf are fine
[13:32] <henrix> which doesnt' make sense
[13:37] <apw> henrix, could be believeable if it is a locking primative or similar which was changed between working and not; those are arch specific
[13:37] <apw> henrix, and have arch specific external symbol requirements
[13:38] <henrix> apw: yep. i'm rebuilding it in gomeisa as i deleted the build logs, just to make sure.
[13:39] <apw> henrix, or indeed that driver may be only on in PPC
[13:40] <apw> henrix, and isn't that a driver which was applied like only Feb 04
[13:40] <henrix> apw: yep, that's the one
[13:43] <apw> henrix, i don't see how this is valid on any release
[13:43] <apw> as it blatently uses vzmalloc without includeing vmalloc.h
[13:44] <henrix> apw: yeah, so maybe you're right: it may be built only for ppc. i'm investigating
[14:26] <henrix> apw: so, my theory is that one of the headers included by the alx driver will bring net/ip6_checksum.h and linux/vmalloc.h on some archs but not for powerpc
[14:27] <henrix> apw: if you look at the buildlogs for amd64 for example, the driver compiles successfully
[14:28] <henrix> apw: i'll test a patch on a ppc box that will just include these 2 headers (that should be in the driver anyway)
[14:28] <rtg_> henrix, I think perhaps you could just disable the alx driver build for all but x86'en
[14:29] <henrix> rtg_: well, that's another solution. would you prefer that? i guess it will be useless in ppc anyway
[14:29] <rtg_> henrix, Its the simplest.
[14:29] <henrix> rtg_: ack, will do that then. thanks
[15:06]  * henrix -> errand
[15:35]  * ogasawara back in 20
[15:49] <henrix> rtg_: fyi i'm going to apply the alx patch to Q master-next
[15:49] <rtg_> henrix, already did
[15:49] <henrix> rtg_: heh, cool. thanks
[15:57] <rtg_> jjohansen, henrix, rebooting tangerine for kernel update
[15:58] <henrix> rtg_: ack
[15:58] <jjohansen> rtg_: okay, give me one minute
[15:58] <jjohansen> hehe, or not
[15:58] <rtg_> jjohansen, go ahead
[15:58] <jjohansen> rtg_: no I'm good, I just wanted to make sure my editor was closed and saved, but I had already done that
[16:58] <slangasek> hi, can anyone here tell me if there's more debugging info that would be useful from the running process on bug #1117499, before I kill with fire?
[16:58] <ubot2> Launchpad bug 1117499 in linux (Ubuntu) "killall -9 firefox fails to work in raring" [Critical,New] https://launchpad.net/bugs/1117499
[17:00] <slangasek> bjf: ^^ any thoughts on this madness?
[17:03] <ohsix> would want to see the process state and wchan
[17:04] <slangasek> ohsix: shown how?
[17:05] <ohsix> /proc/<pid>/wchan, top displays it i think
[17:06] <ohsix> if it's waiting on something in the kernel it will have a name, it wouldn't be unkillable unless it's in a syscall that won't exit
[17:07] <slangasek> well, seems to be state 'R' - not state 'D' which is what I would normally expect to see for an unkillable process?
[17:09] <slangasek> so I guess the next question is, can I kill the X server or is it similarly wedged
[17:11] <ohsix> there's no transitive property of signal-undelivery between firefox and X or any other process i know of
[17:11] <slangasek> sure
[17:11] <ohsix> what's perf top say firefox is doing
[17:11] <slangasek> but the firefox and X processes seem to be in a similarly useless state
[17:11] <slangasek> (using lots of CPU according to top, but not using it for anything I would like it to)
[17:12] <slangasek> ohsix: I don't have perf installed and apt offers me two choices - linux-base and linux-tools-common.  Does it matter which I take?
[17:12] <slangasek> oh, looks like one of these might be a ghost and linux-tools-common is the right one
[17:12] <ohsix> it's in linux-tools-common
[17:12] <rtg_> slangasek, should be linux-tools-common
[17:13] <slangasek> er, except it isn't in fact
[17:13] <slangasek> packaging bug?
[17:13] <ohsix> i got that same offer after a reinstall, didn't look into why it suggested linux-base; there's a wrapper script and a versioned binary to go with the kernel, i'm guessing they moved around a little
[17:13] <infinity> slangasek: linux-tools-$(uname -r)
[17:13] <ohsix> perf_<tab> :)
[17:13] <slangasek> $ dpkg -L linux-tools-common | grep perf
[17:13] <slangasek> /usr/share/man/man8/x86_energy_perf_policy.8.gz
[17:13] <slangasek> /usr/bin/x86_energy_perf_policy
[17:13] <slangasek> infinity: ta
[17:14] <infinity> Err, or not.
[17:14] <slangasek> infinity: minus the -generic :)
[17:14] <infinity> linux-tools-3.8.0-4
[17:14] <infinity> Yeah.
[17:14] <infinity> There's a "linux-tools" metapackage that deals with that. :P
[17:14] <slangasek> er, that doesn't have it *either*
[17:15] <infinity> No, it sure doesn't... Did we disable perf again, due to libaudit deps?
[17:15] <rtg_> slangasek, infinity - I think so due to build issues. lemme recheck it
[17:16] <slangasek> linux (3.8.0-0.2) raring; urgency=low
[17:16] <slangasek>   * [packaging] Add macro to selectively disable building perf
[17:16] <slangasek>   * [packaging] Cannot depend on universe package libaudit-dev
[17:16] <infinity> It may be high time for us to just MIR audit.
[17:16] <rtg_> infinity, right, that kind of fell off my radar.
[17:16] <slangasek> infinity: it's been requested before but stalled for some reason I don't recall... I think I talked to jdstrand about it a while ago, maybe sync with him?
[17:16] <slangasek> I think we do want to get audit into main though, yeah
[17:16] <infinity> Yeah, there's been more than one MIR attempt for audit, IIRC.
[17:17] <infinity> But a ton of stuff depends on it these days.
[17:17] <infinity> (even glibc)
[17:17] <slangasek> pam wants it too
[17:17] <slangasek> and systemd of course
[17:18] <infinity> https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1026852
[17:18] <ubot2> Ubuntu bug 1026852 in audit (Ubuntu) "[MIR] audit (pulls in libprelude)" [Undecided,New]
[17:18] <ohsix> so you can't run perf? that's awesome
[17:18] <infinity> So, yeah, that's been stalled.  I'll poke the relevant folks.
[17:35] <ppisati> guess what?
[17:36]  * ppisati -> gym
[17:37] <slangasek> Penn and Taler
[17:37] <slangasek> hmm
[17:42] <slangasek> so, firefox finally saw fit to die on its own
[17:42] <slangasek> X is still frozen though
[17:45] <ohsix> if it really was not responding to SIGKILL, it finally was able to exit whatever syscall it was in _if_ thats' what it was, there's not much else you can do to keep SIGKILL from being delivered
[18:26]  * rtg_ burns a couple hours catching up with LKML
[18:28]  * rtg_ -> lunch
[18:31] <zequence> I have a problem with my debian/rules file. Meaning to update linux-lowlatency for precise. This is what happens:
[18:31] <zequence> fakeroot debian/rules clean
[18:31] <zequence> debian/rules.d/0-common-vars.mk:10: *** first argument to `word' function must be greater than 0.  Stop.
[18:32] <zequence> Been googling a bit, but I might need more stuff to go through all of it
[18:33] <zequence> apw: Something with the debian folder in lowlatency seems to be wacky. What would be the best way for me to circumvent this problem
[18:37] <apw> zequence, i think that might be caused by a corrupt versionlog
[18:37] <apw> zequence, check debian.lowlatency/changelog hasn't got wacked any
[18:38] <apw> zequence, ahh are you using the fixed version i published ?  
[18:38] <apw> zequence, i had to remove a blank line from your changelog to be able to upload it
[18:38] <apw> commit 9a282dd2cd0f7c85f62dea5fe8221940e26a0612
[18:38] <apw> Author: Andy Whitcroft <apw@canonical.com>
[18:38] <apw> Date:   Mon Jan 28 09:31:19 2013 +0000
[18:38] <apw>     UBUNTU: fix up blank lines in changelog
[18:39] <apw> zequence, i bet it is that which is breaking you, pull from the 'public' repo: git://kernel.ubuntu.com/apw/ubuntu-precise-lowlatency.git
[18:40] <zequence> apw: Oh. Thanks. Will try that
[19:05] <zequence> apw: Hope I didn't cause you too much trouble. I baked in your commit, updated, and pushed linux-precise-lowlatency
[19:07] <apw> zequence, sweet
[19:07] <apw> will look at it later thanks
[19:28] <infinity> apw: Your linux-lowlatency is missing a build-dep on openssl
[19:29] <infinity> apw: (Master has it, you might want to double-check if anything else is missing)
[20:45]  * rtg_ -> EOD
[23:29] <apw> infinity, thanks
[23:31] <infinity> apw: I'd have pointed it out when I fixed powerpc, but I didn't realise lowlatency was similarly broken. :P