[10:58] <\sh> moins
[10:58] <apw> moin
[10:59] <\sh> guys, somehow I'm missing a module in 3.2.0-* ubuntu kernel  series in precise
[11:00] <\sh> and this module is named "aufs.ko" it's in 3.0.0-* series in oneiric but somehow I don't find it in the modules directory of 3.2.0-*
[11:00] <apw> \sh, yep, thats gone
[11:00] <\sh> woot?
[11:00] <\sh> what's the replacement?
[11:00] <apw> we are using overlayfs for our livecds
[11:00] <ashish__> can i calc the cpu usage from stat file by reading it once 
[11:01] <\sh> apw, that's a nice one...so live-boot from debian is broken now, because they are still using aufs
[11:01] <ashish__> as i m geetting some skipped results
[11:01] <apw> \sh, well i think we use live-boot too now, so i assume we have a fix for that somewhere
[11:02] <apw> \sh, else we'd not be able to make cds ourselves
[11:03] <apw> ashish__, skilled results ?
[11:05] <ashish__> apw:skipped as in i am not getting the usage when the usage graph moves suddenly up n is down soon
[11:05] <\sh> apw, well, I would like to see the fix ;) but why are we not building the module anymore...replaceing aufs with something better ok, but removing a module is not ok ;) somebody could rely on the availability of this module ;)
[11:05] <apw> \sh, because it is an out of tree module which required a large amount of support effort to maintain
[11:06] <apw> \sh, overlayfs is slated to be the replacement, and we don't want to have to support both for 5 years in P
[11:06] <ashish__> i would like to know hw top gives dynamic usage 
[11:06] <apw> \sh, and the only way to find out if people are using it is to remove it and see if they can use overlayfs
[11:06] <apw> ashish__, dynamic useage of CPU?  as in instantaneous load ?
[11:06] <\sh> ok...so how do we fix live-boot to use overlayfs
[11:07] <apw> \sh, i have no idea ;)
[11:07] <\sh> or how do I compile the aufs module by myself ;) 
[11:07] <apw> \sh, well the code isn't going to be in the tree for much longer, as we have yet to find anything which can't be converted over
[11:07] <apw> \sh, so you'd be porting it yourself to the tree to use it
[11:08] <apw> \sh, as i say i believe we are using live-boot for our CDs, and i don't think its needed in the making just the booting of them in the default configuration
[11:08] <apw> \sh, and we definatly have fixes in ubuntu to allow use of overlay in preference
[11:09] <apw> \sh, now our liveCDs are made by the foundations lot who might be able to clarify my ramblings
[11:09] <apw> \sh, they hang out on #ubuntu-devel, asking there about live-boot might get you closer
[11:09] <\sh> cjwatson in charge for this?  :)
[11:09] <ogra_> apw, dont mix live-boot with live-build :)
[11:10] <apw> ogra_, heh i may be :)  if so then they will know :)
[11:10] <ogra_> i dont think we use live-boot (that would replace casper i think)
[11:10] <ogra_> but we use live-build to roll the rootfs
[11:11] <apw> ogra_, ahh, then ... 
[11:11] <ogra_> so \sh should send a patch to debian ;)
[11:11] <\sh> ogra_, there was one
[11:11] <\sh> http://live.debian.net/devel/rfc/overlayfs/
[11:11] <\sh> but the patch is gone 
[11:11] <ashish__> stat file gives me data but shld i include irq,iowait,softirq too  or they are included in user ,nice ,sys processes
[11:12] <apw> \sh, thats handy indeed, perhaps it went in
[11:12] <\sh> apw, no
[11:12] <tkamppeter> Did someone already have a look into bug 917148? Working USB printing is essentially important.
[11:12] <ubot2`> Launchpad bug 917148 in linux "Kernel problems when accessing USB printers" [Critical,Confirmed] https://launchpad.net/bugs/917148
[11:13] <apw> \sh, thats unhelpful
[11:13] <\sh> apw, it's WiP and the patch is gone from paste.d.n
[11:13] <ogra_> \sh two solutions, use casper for your live images or fix debian :) 
[11:13] <\sh> wait
[11:14] <\sh> ogra_, I'm trying to get FAI working ;)
[11:14] <\sh> no casper for me here ;)
[11:14] <ogra_> well, then fix debian :)
[11:14] <apw> tkamppeter, how do we know this is a kernel issue?
[11:15] <\sh> ogra_, looks like the fix is in live-boot...now I need to find a way to enable it
[11:15] <ogra_> aha
[11:16] <apw> \sh, the fix is applied already ?
[11:16] <\sh> apw, looks like...I just made a simple grep for overlayfs in the live-boot-initramfs-tools..and found it
[11:16] <\sh> so I'm trying to enable it
[11:16] <apw> \sh, so i think that rfc page has the incantation at the bottom
[11:16] <apw> --bootappend-live union=overlayfs \
[11:17] <\sh> apw, yeah...I'll play with it nwo
[11:17] <\sh> now even
[11:18] <apw> tkamppeter, how do we know this is a kernel issue? i can't tell from the bug how we have decided that
[11:19] <smb> tkamppeter, Just skipping over it I see libusb segfaulting and some devices not properly attach as highspeed which sometimes is a hw fault
[11:19] <tkamppeter> apw, I have used several different access methods (CUPS USB backend with old libusb 0.1.x, CUPS USB backend with new libusb 1.0.x, HP's packet mode, multiplex USB backend) and always get the same problem, the data stream breaks even at the same position in the file.
[11:20] <tkamppeter> smb, all devices under test worked until Natty.
[11:21] <tkamppeter> smb, can you see which libusb is segfaulting? 0.1.x? 1.0.x? Both?
[11:21] <smb> tkamppeter, in the dmesg you provided in the bug: 1.0 it seems
[11:22] <smb> segfault at 0 ip 00007f1e2f866ed8 sp 00007fff205f8970 error 6 in libusb-1.0.so.0.0.0[7f1e2f863000+d000]
[11:23] <apw> tkamppeter, as this has been since natty it might also be worth checking precise too
[11:23] <smb> tkamppeter, It would help to have a dmesg of something that just boots up starts a print job and fails
[11:23] <apw> the precise kernel works well for me on oniric userspace for a quick test
[11:26] <tkamppeter> apw, perhaps I should downdate libusb to Natty and repeat the HP backend and USB-libusb-0.1.x test.
[11:26] <apw> tkamppeter, that is another good test to try
[11:32] <diwic> ogasawara / apw, upstream has committed my fixes for bug 923316, bug 923409 and bug 924320. Should I wait a week for it to reach Linus's tree, or should I do something now for you to get it quicker?
[11:32] <ubot2`> Launchpad bug 923316 in linux "[regression] Speakers are not muted while plugin the headphone " [Medium,In progress] https://launchpad.net/bugs/923316
[11:32] <ubot2`> Launchpad bug 923409 in linux "[Both front and rear Line-In] No sound (codec parsing fails)" [Medium,Fix committed] https://launchpad.net/bugs/923409
[11:32] <ubot2`> Launchpad bug 924320 in linux "[HDA Intel] output to hdmi:0 is heard through internal speakers as well" [Undecided,In progress] https://launchpad.net/bugs/924320
[11:32] <apw> diwic, in precise or earlier, we've missed A2 now so there is little rush
[11:33] <diwic> apw, ok so that means wait a week (i e until linus has pulled takashi's tree)?
[11:34] <diwic> apw, and then I'll propose cherry-picks/backports to the k-t ML
[11:34] <diwic> ?
[11:34] <diwic> (yes, it's 12.04)
[11:34] <tkamppeter> Didi someone have a look into bug 900802?  It is a trivial "add another device ID" bug. I have the iPhone 4S and it works great.
[11:34] <ubot2`> Launchpad bug 900802 in ipheth "PATCH: Got the USB tethering of the iPhone 4S working" [Undecided,Fix released] https://launchpad.net/bugs/900802
[11:47] <tkamppeter> apw, now I did a simple attempt to reproduce the bug on stock Oneiric, with the HP backend which uses libusb 0.1.x. I do not observe a segfault, but both dmesg and syslog say:
[11:47] <tkamppeter> Did not find alt setting 1 for intf 0, config 1
[11:48] <apw> tkamppeter, ok so if its failing in that configuration, without the segfault, then i would say get a natty kernel and boot that up, and see if just changing that fixes the issue
[11:48] <tkamppeter> So good part of the job printed, meaning that the communication worked and suddenly it is not able any more to find the channel to the printer which it used for the already printed part of the job.
[11:49] <apw> tkamppeter, the alt settng message is an initialising error, not something i would expect mid communication
[11:49] <apw> anyhow the logical test now is get and boot a natty kerenl, leaving everything else the same, and re-test
[11:58] <tkamppeter> apw, will do so now ...
[12:07] <tkamppeter> apw, smb, I have booted the old kernel and it stops the same way. Seems that I have to try a libusb downdate now.
[12:12] <apw> tkamppeter, ok so it sounds like its not a kernel level issue then ... 
[12:18] <tkamppeter> apw, also downgrading libusb to Natty's does not help. The HP backend always says: unable to write data, 45 second io timeout
[12:21] <apw> tkamppeter, so whats left thats not been changed :/
[12:22] <apw> tkamppeter, it may be an interaction between libusb and another system library for instance
[12:26] <tkamppeter> apw, on a Lucid VM it works.
[12:26] <apw> one way to eliminate t
[12:27] <apw> things might be install a Natty system and upgrade the various parts one at a time till it breaks
[12:32] <tkamppeter> apw, on a Precise VM it does not work, so it broke somewhere on the way and virtualization does not unbreak it (then I would feature-request that a standard installation would install a minimum Linux with the real Linux in a VM).
[12:32] <tkamppeter> apw, so the best to do now is to install a Natty VM ...
[12:40] <apw> tkamppeter, yeah sounds like a plan
[12:43] <tkamppeter> apw, I am doing so now ...
[13:22]  * tgardner is repairing chroots on gomeisa
[13:24]  * tgardner is rebooting tangerine in 5 minutes
[13:48] <arges> smb, hello! question about bug 881542. do you know when this fix is planning on being released?
[13:48] <ubot2`> Launchpad bug 881542 in linux "Ubuntu 10.04 LTS as guest freezes after xm restore" [Medium,Fix committed] https://launchpad.net/bugs/881542
[13:49] <smb> arges, when it is out of proposed? :-P
[13:49] <smb> arges, But seriously, let me check
[13:49] <arges> smb, : )
[13:49] <arges> smb, thanks
[13:54] <smb> arges, Hm, this actually looks like it should be released already. Might just have failed to auto-update the bug because the patch from upstream stable replaced the sauce patch
[13:55] <smb> 2.6.32-37.80 seems to be the release
[13:55] <arges> smb, ok that's good to know. i can check that too 
[13:56] <arges> smb, yes see 676dc3cf5 in ubuntu-lucid. 
[13:57] <smb> arges, yep, I'll update the bug right now
[13:57] <arges> cool. thanks
[14:20] <tkamppeter> apw, smb, Installed Natty, sent the job, works ...
[14:30] <tkamppeter> apw, smb, upgrading only libusb, still works ...
[14:38] <tkamppeter> apw, smb, still there?
[14:38] <apw> tkamppeter, and the kernel as well ?
[14:39] <apw> it may be an interaction between those two both being updated, or a third thing
[14:40] <tkamppeter> Trying to install the 3.0.0-15 kernel on Natty, but this does not work, when the postinst script generates the initrd, it gives a Python traceback, in /usr/bin/nvidia-detector.
[14:40] <tkamppeter> And my VM is most probably not emulating an NVidia card on a system with Intel GPU.
[14:40] <tkamppeter> apw ^^
[14:42] <tkamppeter> apw, trying to also update the nvidia-common package ...
[14:42] <tkamppeter> apw, now kernel installation completes.
[14:43] <apw> yeah there was some bug or other in the detection back then, interesting
[14:43] <tkamppeter> apw, seems to be missing versioned package dependency in kernel package.
[14:44] <apw> i think it was ok as we never expect those combinations to ever exist together
[14:44] <apw> those kernels arn't supported back there
[14:45] <tkamppeter> apw, new kernel up and running, job sent ...
[14:46] <tkamppeter> apw, job succeeded.
[14:47] <apw> ok so its neither of those then, its something else ... now ... what is harder
[14:48] <tkamppeter> apw, ldd /usr/lib/libusb-0.1.so.4 shows only linux-vdso, libc, and ld-linux=x86-64, so no non-standard libs libusb is depending on ...
[14:48] <apw> well i guess we need to update those one by one till it stops
[14:49] <tkamppeter> apw, so next candidates to update seem HPLIP and CUPS, where I cannot imaging that CUPS can break it. It is on USB communication level.
[14:49] <apw> tkamppeter, well it could be an app->libc interaction, a bug in either
[14:49] <apw> so i'd be interested in upgrading the underlying layers too
[14:50] <apw> tkamppeter, i assume we know the job is the same binary data in the working and non-working cases
[14:51] <tkamppeter> apw, so I am trying to upgrade these standard libs now.
[14:52] <tkamppeter> apw, there is no binary file in the whole distro with vdso in its name. So it seems that linux-vdso is a part of the kernel and therefore is already upgraded.
[14:53] <apw> tkamppeter, yeah that makes sense, its instantiated by the running kernel
[14:53] <tkamppeter> apw, the other two are part of libc6, so this is the next package to update.
[14:57] <apw> tkamppeter, ok
[14:58] <tkamppeter> apw, this pulls a lot of other libs and all compilers: cpp-4.5, g++-4.5, gcc-4.5, gcc-4.5-base, lib32gcc1, lib32stdc++6, libc-bin, libc-dev-bin, libc6, libc6-dev, libc6-i386, libgcc1, libgomp1 libstdc++6, libstdc++6-4.5-dev, make, pkg-config
[14:59] <tkamppeter> apw, the compilers, dev, and 386 packages are probably irrelevant. Should I try to update the others one by one until it breaks or should I simply update libc6?
[15:02] <vanhoof> apw: ogasawara: my hair looks absolutely fabulous today
[15:03]  * ogasawara is worried
[15:06] <vanhoof> ogasawara: finally got it cut :)
[15:18] <apw> tkamppeter, i think i'd go for libc
[15:22] <tgardner> vanhoof, we need photographic proof.
[15:25] <vanhoof> tgardner: http://ubuntuone.com/62ljS1z8foknvmaOG1dZep
[15:26] <vanhoof> tgardner: :)
[15:26] <tgardner> vanhoof, hmm, looking pretty clean cut :)
[15:27] <jsalisbury> vanhoof == vanwho
[15:27] <jsalisbury> :-)
[15:27] <vanhoof> tgardner: i feel like a new man :)
[15:28] <tgardner> vanhoof, I always marvel at how much less shampoo it takes right after a new haircut.
[15:30] <tkamppeter> apw, installing libc6 ...
[15:30] <vanhoof> tgardner: seriously
[15:31] <tgardner> vanhoof, seriously, TMI ?
[15:31] <vanhoof> tgardner: was having to pull the whole grandma trick of putting water in the bottle to make it last longer ;)
[15:31] <vanhoof> lol
[15:33] <tkamppeter> apw, sent job again, printing is still working.
[15:37] <vanhoof> tgardner: you didn't notice the extra set of ears :)
[15:37] <tkamppeter> apw, rebooted now to make everything using libc6 use the new version, another print job, still printed.
[15:40]  * ogasawara back in 20
[16:13]  * jsalisbury --> reboot
[17:49]  * apw watches tooo many upgrades in profress ...
[17:52] <apw> tkamppeter, hmmm, must be one of the other deps then
[18:34] <tkamppeter> apw, trying to update HPLIP, but probability is low as the problem occurs also with CUPS USB backend.
[18:36] <tkamppeter> apw, still prints correctly.
[18:38] <apw> gargle
[18:38] <apw> tkamppeter, then its something else, any other libraries the binaries use there?
[18:40] <apw>  /b -x
[18:42] <tkamppeter> apw, having updated CUPS, which pulled Ghostscript and now it seems that it has stopped.
[18:44] <tkamppeter> apw, this changes the binary stream as Poppler is replaced by Ghostscript at one point, but in the rasterization produced by HPLIP's hpcups driver only randomn bits should different which should not break USB communication.
[18:49] <apw> hmmm
[18:49] <apw> tkamppeter, well we need to keep replacing bits till somethign tilts
[18:49] <apw> tkamppeter, however unlikely
[19:16] <tkamppeter> apw, now I can switch between the good state and the broken state: with Ghostscript it is broken and with Poppler it works.
[19:17] <apw> tkamppeter, so perhaps something coming out of the gs version is malformatted and upsets the remote printer
[19:17] <apw> and perhaps its not a transport thing at all
[19:19]  * tgardner --> lunch
[20:52]  * tgardner -> EOD
[21:49] <emgent> hello guys
[21:49] <emgent> kees: around ?
[22:06] <noahmehl> I need some help with bridge-utils
[22:06] <noahmehl> anyone here familiar?
[22:27] <jono> jsalisbury, btw, still no network dropping issues with the Oneiric kernel
[22:27] <jono> so it must be an issue in Precise
[22:27] <jono> I will test the kernel switches next
[22:28] <jsalisbury> jono, cool, it will be great to hear if the issue happens with n disabled
[22:28] <jono> totally, will wrap this call and then try that
[22:28] <jsalisbury> great
[22:29] <jono> jsalisbury, want me to boot the latest 3.2 kernel and then run: sudo modprobe -r iwlagn;sudo modprobe iwlagn 11n_disable=1
[22:29] <jono>  ?
[22:29] <jsalisbury> jono, yes, thanks
[22:29] <jono> jsalisbury, cool, will do
[22:29] <jono> will update the bug report if I see an issue
[22:31] <jsalisbury> thanks