[02:21] <jj-afk> back on later
[03:26] <dcordes__> hi
[03:26] <dcordes__> are there any release notes for http://cdimage.ubuntu.com/ports/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img ?
[03:28] <dcordes__> -sorry. I'm wondering about this here http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap.img.gz what is the user pass ?
[03:30] <persia> dcordes__: My guess would be "ubuntu"/<none>
[03:32] <dcordes__> persia: ubuntu/<none> ubuntu/ubuntu both don't work
[03:34] <persia> Oh, I remember.  It doesn't have one.  Boot it into X, and it will launch oem-config to set up the user/password.
[03:35] <dcordes__> persia: X doesn't seem to work
[03:35] <dcordes__> persia: I remember it has some platform specific accerlation thing
[03:36] <dcordes__> xf86-video-omap ?
[03:36] <persia> Hmmm.  I'm not sure then (and I don't have any hardware that can run that).  Try asking in #ubuntu-arm.
[03:38] <RAOF> dcordes__: Might you be thinking the xserver-xorg-video-omapfb binary package?
[03:39] <dcordes__> RAOF: sorry ?
[03:39] <RAOF> dcordes__: Your “platform-specific acceleration thing”
[03:40] <dcordes__> RAOF: yes what about it ?
[03:40] <RAOF> I uploaded a new version last Thursday, which (should have!) fixed installability and make it actually work.
[03:41] <dcordes__> you must be maintainer then. cool
[03:41] <dcordes__> many ubuntu staff people here
[03:42] <RAOF> If omapfb is not working on Maverick you should check that 0.1.1-3ubuntu2 is the version that's installed; the previous version won't work.
[03:43] <dcordes__> RAOF: s/on Maverick/on my device/ :)
[03:44] <dcordes__> don't have any omap dsps
[04:00] <dcordes__> Oliver Grawert  wrote on 2010-07-09:  	  #2  the netbook session should not be the default here, we need to add a proper settings package that makes it default to 2D once the mobile-m-lightweight-panel-for-efl spec is implemented
[09:15] <apw> morning all
[09:16] <cking_> morning apw
[09:16] <apw> cking_, having network fun today?
[09:17] <cking_> nope, just swizzling my connection directly to my server so I can run QEMU remotely more responsively
[09:17] <apw> heh sounds like a plan
[09:18] <cking_> darn this ubi-flu
[09:18] <apw> you too?  avoided it so far
[09:18] <cking_> rubbish cold, hot head, urgh, it hit me yesterday afternoon/evening
[09:19] <apw> yay
[09:20] <amitk> cking_: welcome to the club (*sniffle*)
[09:20]  * apw refuses to have it
[09:25]  * abogani waves
[09:25] <ikepanhc> good morning .eu :)
[09:26] <apw> ikepanhc, moin ... used your new instructions to update the wiki ... https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey ... and added an automatic menu generator
[09:27]  * ikepanhc looks good, thanks. I shall write the wiki
[09:27] <ikepanhc> wow, you have a script for it
[09:28] <apw> ikepanhc, yep ... slap on iso's run rebuild and done
[09:28] <apw> doesn't install grub thats still manual, but a one off
[09:29] <ikepanhc> I think it is ok. enough info in the wiki
[09:29] <apw> yeah i used your text in your email as a basis as it was nice and clear
[09:29] <apw> and added the rebuild script i just wrote while testing the instructions :)
[09:35] <apw> ikepanhc, thanks for writing that up its great
[09:36] <ikepanhc> :) I will have a presentation to all of us because it amazed me when I saw it
[09:37] <ikepanhc> I believe it can make our life easily
[09:37] <jk-> anyone have sudo on frylock?
[09:51] <abogani> apw, ping :-)
[09:52] <apw> jk-, not i
[09:52] <apw> jk-, tgardner i would thnk
[09:52] <apw> abogani, hi ya
[09:52] <abogani> apw, Do you have some news for me?
[09:55] <apw> abogani, gah ... no ... i will book some time with smb to get that done
[09:55] <abogani> apw, Ok thanks. Sorry for bother you so frequently.
[09:57] <apw> abogani, no no problem its lack of time is all ... but i see A3 in my ear and it neesd to be done before that
[10:06] <ericm|ubuntu> guys, silly question - how to extract the contents from an .img file (the file used to 'dd' onto a USB disk for installation) ?
[10:06] <ericm|ubuntu> mount -o loop doesn't work, I guess it's not simply a partition but a whole disk image
[10:06] <ikepanhc> I dont have a better way then dd into a usb disk
[10:08] <apw> ericm|ubuntu, you might be able to mount it if you do the looping back yourself
[10:08] <apw> as the underly loop mechanism is actually raw disk loopback
[10:09] <apw> ie it should find the partition table etc as far as i know
[10:09] <ericm|ubuntu> apw, what's the exact command - dude I'm a slack to find that out :-)
[10:09] <apw> its losetup i think
[10:11] <ericm|ubuntu> apw, let me have a try
[10:11] <apw> you may then have to use the offset stuff to map just the partition manually ... not sure
[10:11] <ericm|ubuntu> apw, ah that way I may prefer to use dd to get rid of the MBR from that .img file
[10:12] <ericm|ubuntu> though not exactly sure about whether the 1st partition starts right behind
[10:12] <ikepanhc> ericm|ubuntu: try iat
[10:12] <apw> ericm|ubuntu, if you know how far in the partition is you can just sue --offset
[10:12] <ikepanhc> ericm|ubuntu: it can convert .img to .iso, then mount iso
[10:12] <ericm|ubuntu> ikepanhc, apt-get install iat?
[10:13] <ikepanhc> yeah
[10:13] <ikepanhc> but apw is right, if we know the offset of the partition, mount with offset will be quickest
[10:13] <ericm|ubuntu> ikepanhc, I'd try apw's suggest first, I'm already a slack cannot depend on more tools now
[10:14] <ericm|ubuntu> :-)
[10:16] <ericm|ubuntu> yow, this works: sudo mount -o loop,offset=512 ~/canonical/wyse/images/hedley-usb-hdd-20100712-2.img /mnt
[10:17] <ericm|ubuntu> damn
[10:17] <apw> damn?
[10:21]  * ericm|ubuntu goes off to prepare some ice coffee
[10:28] <soren> ericm|ubuntu: You can use kpartx to access partitions in disk images.
[10:29] <ericm|ubuntu> soren, I did it in a silly way - losetup and fdisk :-)
[10:40] <soren> ericm|ubuntu: Yeah. kpartx is your friend. :)
[10:44] <ericm|ubuntu> soren, I might try that out later
[11:03]  * ericm|ubuntu be back in a minute
[11:34] <tseliot> apw: you backported drm from some newer kernel version in Lucid, right? Do you remember what version you backported it from?
[11:34] <apw> tseliot, originally 2.6.33, though it is following stable 33.y
[11:35] <tseliot> apw: this is a bit weird as I can reproduce a bug with radeon with 2.6.33 (from the mainline builds) or higher but not with Lucid's kernel
[11:36] <apw> tseliot, so you'd want to test the tip of the v2.6.33.y branch too ... maybe fixed there
[11:37] <tseliot> apw: I tried v2.6.33.6-maverick
[11:37] <apw> ok ... so then we must have something else fixing it :)  whats the bug
[11:38] <tseliot> apw: videoclips stutter every 16-17 second
[11:38] <tseliot> with any player and with or without compositing
[11:39] <tseliot> I also used ftrace to see what was going on
[11:39] <apw> so this is a maverick issue i assume ?
[11:39] <tseliot> yep
[11:39] <apw> how can i reproduce it?
[11:40] <apw> and are you saying its just radeon?
[11:40] <tseliot> apw: http://pastebin.ubuntu.com/469759/
[11:40] <tseliot> yes, it's radeon and it affects my RS880 chip
[11:41] <apw> so, what in that ftrace is indicating it?
[11:41] <tseliot> that's a good question ;)
[11:41] <apw> tseliot, also which maverick kernel are you testing?
[11:41]  * ericm-afk a long minute
[11:41] <tseliot> apw: currently it's 2.6.35-10-generic
[11:42] <tseliot> 2.6.32-22-generic is fine
[11:42] <apw> what version is that based on?  check /proc/version_signature last word
[11:42] <tseliot> Ubuntu 2.6.35-10.15-generic 2.6.35-rc5
[11:43] <tseliot> I've also tried the following kernels from mainline: 2.6.33.6, 2.6.34, 2.6.35
[11:43] <apw> there is no mainline 2.6.35
[11:44] <tseliot> and while the problem is less noticeable in 2.6.33.6 and 2.6.34 it's worse in 2.6.35
[11:44] <tseliot> then I must have compiled it from source
[11:44] <apw> well there are -rcN's there, but 2.6.35 itself isn't out yet
[11:45] <tseliot> this is what I tried: v2.6.35-rc5-maverick
[11:45] <tseliot> and v2.6.35-rc2-maverick/
[11:45] <apw> tseliot, ok there is now an -rc6 and the latest maverick kernel is on that too
[11:46] <tseliot> ah, -11
[11:46] <tseliot> I'll try that and let you know
[11:46] <apw> i am not expecting much tho
[11:46] <tseliot> yes, at this point there shouldn't be many changes
[11:52]  * apw notes that udev is getting plymouth up and attached to /dev/drm* before the i915 driver has even finished initialising
[11:53] <apw> that is never going to be a pretty thing
[11:54] <diwic> apw, that sounds quite bad
[11:55] <apw> i am not sure it is truly ready to be opened, a feeling backed up by the fact it panic's pretty soon after
[11:56]  * apw suspects he is only hitting this cause he has a fast SSD in this box
[11:58] <diwic> apw, is there something asynchronous in the i915 driver, or would something like while(1) { fopen('/dev/somedevice'); } make most devices go crazy?
[11:59] <diwic> apw, I mean all by definition, the device node for any device must be created before initialization finishes
[12:07] <apw> diwic, everything about module insertion is async, udev probed i915 in the background, and is responding to the dev files appearing by firing off plymouthd to open then
[12:14] <diwic> apw, so then the i915 driver should implement synchronisation/muteces that makes opening of the device node not to succeed before the i915 is fully initialized?
[12:15] <apw>  diwic indeed so ... now to find out what the heck is wrong with it
[13:23] <apw> tseliot, hey ... sconklin worked out you could turn on drm debug right?  did he document it?
[13:27] <tseliot> apw: right, I forgot about that
[13:28] <tseliot> apw: drm.debug=1 if I remember correctly
[13:28] <apw> or it might be i915.debug
[13:30] <tseliot> this is with radeon
[13:30] <tseliot> modprobe -v drm debug=1
[13:30] <tseliot> as they suggest here: http://www.x.org/wiki/radeonBuildHowTo
[13:31]  * tseliot wonders if he can do it on the fly by acting upon /sys
[13:31] <apw> yes you can, sconklin reported you could
[13:32] <tseliot> maybe echo 1 > /sys/module/drm/parameters/debug
[13:32] <apw> 1,2,4 bits have meaning
[13:32] <tseliot> ok
[13:33] <apw> #define DRM_UT_CORE             0x01
[13:33] <apw> #define DRM_UT_DRIVER           0x02
[13:33] <apw> #define DRM_UT_KMS              0x04
[13:33] <tseliot> hmm... maybe 2?
[13:34] <apw> well 7 was bad (too much output), 2 doesn't have what i need
[13:35] <apw> 1 has too much, 2 too little
[13:41] <tseliot> apw: maybe vblank has become too expensive? http://pastebin.ubuntu.com/469792/
[13:42] <tseliot> not that it has ever been cheap
[13:44] <tseliot> apw: actually this is what I got right after playing the video: http://pastebin.ubuntu.com/469795/
[13:45] <apw> tseliot, i am not sure what to make of that much outut
[13:45] <apw> do you have one from a good run ?
[13:48] <tseliot> apw: I could do it from 2.6.32 and compare it
[13:48] <apw> not sure what to suggest other than that
[13:49] <cooloney> anybody found the maverick daily build iso does not boot?
[13:49] <cooloney> apw: ^^
[13:49] <apw> not tried an iso recently no
[13:49] <cooloney> i tried to install it on my Samos machine
[13:51] <apw> i'd suggest trying it on your mac, but that never works anyhow right?
[13:52] <cooloney> apw: my mac needs a real cd disk. i am using usb boot disk now.
[13:52] <cooloney> i will reboot my desktop to try it. later
[13:53] <apw> * bjf[bjf] is now known as bjf
[13:53] <bjf> moin
[13:53] <apw> moin, interesting transition there
[13:53] <cooloney> apw: on my samos, SYSLINUX failed and said "Unknown keyword in configuration file."
[13:54] <apw> i'd suspect thats going to be wrong for everyone then
[13:54] <apw> i'd need to sync an image to confirm, it'l take 20 mins
[13:55] <cooloney> apw: yeah, i gonno to reboot my this desktop for testing. let you know the result soon
[13:56] <bjf> apw, i've got today's iso, will give it a spin
[13:59] <apw> bjf, ta
[14:02] <tseliot> apw: nothing too interesting with 2.6.32: http://pastebin.ubuntu.com/469807/
[14:03] <tseliot> maybe in 2.6.35 drm:r600_irq_process is causing the issue
[14:03] <apw> well vblank only shows up twice in that new one
[14:04] <tseliot> not here: http://pastebin.ubuntu.com/469795/
[14:04] <tseliot> and that's with 2.6.35
[14:04] <apw> [ 5229.289043] [drm:r600_irq_process], IH: D1 vblank
[14:04] <apw> there are millions of those in the .35 one
[14:05] <tseliot> right
[14:05] <dandel> i'm wondering is sleep is broken in the kernel.
[14:05] <cooloney> apw: it looks a common issue about syslinux
[14:05] <apw> dandel, seems unlikely generally
[14:05] <cooloney> the same maverick usb stick does boot my desktop and samos machine
[14:05] <dandel> http://pastebin.ubuntu.com/469810/ (Some code i have which shows this)
[14:05] <apw> cooloney, thanks, i am about to test, and bjf is testing ... so if we all fail
[14:06] <apw> dandel, and how does this program exhibit brokenness
[14:07] <cooloney> apw: no problem, i'm just going to test maverick on my samos, then found that. 
[14:08] <tseliot> dandel: were you referring to the vblank issue?
[14:08] <dandel> no.
[14:08] <dandel> actually, this is something else
[14:08] <dandel> 200000 usleep should be 0.2 seconds on the clock.
[14:09] <dandel> however, it's returning 0.0
[14:09] <maxb> I'm using schroot, and it's taking ages to exit a chroot. Does anyone know what might cause the umount syscall on a bindmount to take ~0.5seconds?
[14:10] <apw> maxb, lucid ?
[14:11] <maxb> apw: yes
[14:11] <apw> umounting anything currently triggers a pre-sync, to avoid a major performance issue in unmount
[14:11] <apw> you are likely hitting that ...
[14:11] <dandel> the first half of my program uses usleep to put the program to sleep for 0.2 seconds and the second half forces a busy wait for 0.2 seconds however the clock is showing no difference.
[14:11] <cyphermox> apw, I had noticed something like booting too quickly as well... there were issues with the hand-off between my netinstall system and booting to the disk. let me know if I can provide more info
[14:11] <maxb> oh. yes that sounds like it
[14:11] <apw> smb was looking at some patches
[14:12] <dandel> the broken part is that the top half registers 0.00 seconds.
[14:12] <apw> bjf, do you know what happened to the writeback patches for lucid ?
[14:12] <bjf> apw, were those the ext4 patches or others?
[14:12] <apw> the ones called 'writeback:' i am referring to i think :)
[14:13] <bjf> apw, will take a look
[14:14] <apw> dandel, well when i make it 2s then the Time Difference is still 0 on the usleep on
[14:15] <apw> and yet it visibly and clearly sleeps
[14:16] <dandel> i know, but for some reason there is a problem with the functions registering the change in clock time.
[14:16] <bjf> apw, cooloney daily iso busted for me as well
[14:16] <dandel> the time function i would expect this out of, however the clock should not be doing this.
[14:17] <apw> dandel, indeed, but the delay is occurng
[14:17] <apw> so ... something else is odd
[14:17] <cooloney> bjf: thx, too bad. so we need to file a bug for syslinux?
[14:17] <dandel> I need to find out where i am supposed to bug report this to.
[14:18] <apw> dandel, this isn't a bug, its correct
[14:18] <apw>        The clock() function returns an approximation of processor time used by
[14:18] <apw>        the program.
[14:18] <apw> clock() is telling how long you have been running, that won't increment when in a sleep
[14:22] <apw> dandel, ?
[14:22] <dandel> I'm looking into something.
[14:27] <apw> maxb, fyi you can confirm if thats the issue, by manually sync'ing before you hit exit
[14:28] <dandel> now it's somewhat working, although sometimes the program will get the values inverted (which is strange)
[14:32] <bjf> apw, are you referring to: https://lists.ubuntu.com/archives/kernel-team/2010-June/010889.html
[14:56] <cooloney> tgardner: just shot by your checkpatch email.
[14:56] <cooloney> tgardner: i'm wondering what's the right way to solve this issue
[14:59] <apw> bjf yep thats the series indeed
[14:59] <bjf> apw, sconklin and i are discussing it
[15:00] <sconklin> it appears to have fallen through a crack
[15:01] <tgardner> cooloney, make them fix their patches and resubmit ?
[15:02] <miked595> I'm running the i7-980x cpu which has 6 cores and with hyperthreading makes 12 threads. My cpuinfo and mpstat only see 8 threads. mpstat > Linux 2.6.32-24-generic-pae (sysops) 07/27/2010 _i686_ (8 CPU). I have tried setting maxcpus past 11 in grub but it has no effect. Any ideas on what I should try next?
[15:02] <cooloney> tgardner: yeah, i am going to do that
[15:02] <cooloney> tgardner: since sebjan will be on vacation, i will do that tomorrow. 
[15:03] <cooloney> tgardner: sorry for missing running checkpatch.pl,
[15:04] <tgardner> miked595, you are screwed: debian.master/config/i386/config.common.i386:CONFIG_NR_CPUS=8
[15:04] <mjg59> miked595: CONFIG_NR_CPUS=8
[15:04] <mjg59> miked595: Rebuild your kernel or run 64-it
[15:04] <mjg59> 64-bit
[15:04] <miked595> *sadface*
[15:05] <miked595> any easy way to upgrade to 64bit without a reinstall?
[15:10] <miked595> tgardner: mjg59 gonna take a stab at building my own kernel. thanks
[15:11] <tgardner> miked595, start here: https://wiki.ubuntu.com/Kernel
[15:11] <miked595> tgardner: I went there when I first got in this channel.. was kind of lost
[15:12] <tgardner> miked595, one of the pointers is to here: https://wiki.ubuntu.com/Kernel/Dev
[15:13] <miked595> tgardner: I'll read that too
[15:31] <apw> miked595, i am told you can get the 64bit kernel and force it on too, ignore the arch error ... not that i have ever tried it
[15:41] <miked595> found a tutorial going through "make menuconfig" now. anytips other then CONFIG_NR_CPUS
[15:41] <tgardner> miked595, it might be simpler to just edit it directly, then run debuild
[15:43] <miked595> tgardner: first time ever doing this. so all the previous options in the source would not already be selected here? It isnt me just editing the current option then?
[15:43] <miked595> it does show "Support for big SMP systems with more than 8 CPUs"
[15:43] <miked595> unchecked
[15:44] <tgardner> miked595, ah, I forgot about that one. you might be betrter off going through the editconfig phase
[15:44] <miked595> what is the diff between editconfig and menuconfig? tgardner
[15:45] <tgardner> miked595, editconfig uses menuconfig
[15:57] <diwic> meeting in three minutes, right?
[15:57] <diwic> in #ubuntu-meeting?
[15:57]  * apw hopes not
[15:57] <bjf> diwic, no in two hours
[15:58] <apw> its at 17:00 UTC i think
[15:58] <tgardner> diwic, methinks you forgot to restore yuor home timezone on google cal
[15:59]  * diwic thinks UbuntuPlatform/Kernel needs serious updating then
[15:59] <diwic> It says 1500 UTC then
[15:59] <diwic> s/then/there
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in two hours
[16:00] <bjf> ##
[16:00] <apw> diwic, yep, why that is info is duplicated on that page I do not know
[16:01] <apw> we should have one listing and one listing only ... will rmeove that reference and point it at the public wiki
[16:01] <diwic> yes please
[16:01] <apw> but no you are not going mad
[16:02]  * ogra thought that was a prereq for the kernel team 
[16:02] <ogra> or an aussie accent
[16:03] <apw> no just drinkiing
[16:03] <ogra> heh, k
[16:04] <apw> diwic, ok that errant copy is beating into submission
[16:06] <diwic> apw, put the old text in the pit! Just like in robot wars! 
[16:06] <miked595> tgardner: compiling
[16:06] <apw> yep and send in one of those spinning disk monsters to trash it
[16:07] <tgardner> miked595, you can shortcut the build process and only build the flavour you want, e.g., 'fakeroot debian/rules clean binary-generic-pae'
[16:07] <apw> bjf, did that stick boot ok ?
[16:08] <miked595> tgardner: i ran this "fakeroot make-kpkg --initrd --append-to-version=-sysops kernel-image kernel-headers"
[16:09]  * diwic reschedules the evening and will return in two hours.
[16:11] <tgardner> miked595, as a newbie you shouldn't stray off the reservation quite so far.
[16:11] <bjf> apw, having disk space issues, resolved now, am building stick
[16:11] <miked595> tgardner: hehe was just following the tutorial
[16:11] <bjf> apw, a live image from july 12, usb stick created on lucid, boots just fine
[16:11] <tgardner> miked595, indeed. Can you give me a pointer? make-kpkg is a bit outside our normal build process.
[16:12] <tgardner> we're in the process of cleaning up the wiki pages, so there is still some cruft around
[16:12] <bjf> apw, today's iso, usb stick created on maverick, is booting fine
[16:13] <apw> bjf ok thats about right as thats before the 13 days ago when the change occured
[16:13] <miked595> i think he they got their info from here https://help.ubuntu.com/community/Kernel/Compile tgardner which shows 'Now you can compile the kernel and create the packages:
[16:13] <miked595> make-kpkg clean # only needed if you want to do a "clean" build
[16:13] <miked595> fakeroot make-kpkg --initrd --append-to-version=-some-string-here kernel-image kernel-headers'
[16:13] <bjf> apw, so you have to have a maverick already, to create a maverick boot disk, sweet!
[16:14] <apw> bjf, hehe currently ... yes
[16:14] <tgardner> miked595, good luck with that. the only build method I'll support is in https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[16:14] <apw> it seems a pretty blocky type bug, so we need to figure out how to fix it
[16:15] <miked595> tgardner: Ill try that too. I didnt think the custom compiles were supported 
[16:15] <miked595> main reason I was trying to avoid it
[16:16] <tgardner> miked595, we'll help you out a bit as long as you aren't straying too far from the norm. a good deal of the info in  https://help.ubuntu.com/community is just shite.
[16:16] <maxb> apw: Thanks for the thought about sync, but unfortunately it doesn't work - the sync takes ~400ms, and then every subsequent umount *still* takes ~400ms
[16:16] <miked595> tgardner: nice I'll now to stay away from it
[16:17] <apw> maxb, ok ... tsk ... sconklin/bjf so do we have  a test kernel with the writeback stack applied for testing?  sounds like we have an avid tester
[16:18] <sconklin> apw, maxb: no, but I can spin one right now
[16:19] <maxb> Don't rush, I won't have time today, but feel free to leave me some instructions here to test something tomorrow
[16:19] <sconklin> maxb: good deal, I'll have one in a few hours then, and leave a pointer in irc
[16:20] <maxb> Or, just tell me what to build - that works too :-)
[16:20] <sconklin> maxb: I have access to a very fast build machine, and can turn this pretty fast
[16:21] <sconklin> besides, this will make it available to anyone else wanting to test
[16:22] <apw> sconklin, good plan
[16:30] <miked595> ok it's done wish me luck
[16:39] <apw> ok so this image issue is not trivial to fix as we need to run syslinux to install it onto the new image, which means it needs to be a locally runnable thing
[16:39] <apw> ie compatible with the host ...
[16:59] <apw> bjf, ok you can work round the incompatibility on the post-built images by running this on them
[16:59] <apw> sed -i -e 's/ui gfxboot/gfxboot/' /media/USBSTICK/syslinux/syslinux.cfg
[17:09] <shadeslayer> \o
[17:10] <shadeslayer> we recently got this mail http://pastebin.com/9X26M2ts
[17:10] <shadeslayer> and were wondering if /proc/sys/fs/inotify/max_user_watches can be increased
[17:10] <shadeslayer> currently its 8192
[17:11] <shadeslayer> whereas the suggested value is 524288, can something be done about it?
[17:25] <jjohansen> shadeslayer: you can set that value just by echo a value into it as root
[17:26] <jjohansen> echo 16384 >/proc/sys/fs/inotify/max_user_watches
[17:27] <jjohansen> you should also be able to throw a value into /etc/sysctl.conf
[17:28] <jjohansen> or /etc/sysctl.d/
[17:28] <jjohansen> see > man 5 sysctl.conf
[17:28] <jjohansen> rebooting
[17:36] <shadeslayer> wow.. long reboot ^
[17:36] <shadeslayer> or something went wrong :P
[17:38] <shadeslayer> also.. im on btrfs on maverick, but the boot takes alot of time, i think its because btrfs tools tries to fsck the partition but fails to do so, any suggestions ?
[17:53] <cnd> tgardner, in regards to linux-firmware licencing
[17:54] <cnd> I thought only licenses that were very large needed their own file
[17:54] <cnd> if it was a very small licence, like 2-4 lines, then putting it in WHENCE was fine
[17:54] <tgardner> cnd, what would Woodhouse do? Looks like they are all in their own LICENSE files.
[17:55] <cnd> tgardner, some of the existing firmware licenses are just like that
[17:55] <cnd> no LICENCE.* files
[17:55] <cnd> but the licence is in WHENCE
[17:55] <shadeslayer> jjohansen: i just wanted to make sure that if we modified it via our packages it would be fine for you 
[17:55] <shadeslayer> s/for/by
[17:55] <bjf> ##
[17:55] <bjf> ## Kernel team meeting in 5 minutes
[17:55] <bjf> ##
[17:56] <tgardner> cnd, do those license entries make it into the package?
[17:56] <cnd> tgardner, I'm not sure, does the WHENCE file make it in?
[17:57] <tgardner> cnd, I don't think so. I think to be compliant with debian policy we need to separate out those license entries so that they make it into the packaging.
[17:58] <cnd> tgardner, WHENCE is renamed to README when it's packaged
[17:58] <tgardner> cnd, hmm, I suppose thats just enough.
[17:58] <cnd> tgardner, https://code.launchpad.net/~private-sparsha-dev/sparsha/gesturetest
[17:58] <cnd> oops
[17:58] <cnd> argh
[17:58] <cnd> why does middle click never work right anymore
[17:58] <cnd> /usr/share/doc/linux-firmware/README.gz
[18:00]  * diwic listens to the outcome of this conversation.
[18:01] <tgardner> cnd, well, you can update the bug refuting my position
[18:01] <cnd> ok
[18:02] <tgardner> cnd, I'd still like to see a separate WHENCE.ubuntu for Maverick
[18:02] <cnd> tgardner, I think that's a good idea
[18:03] <cnd> I'll add it to me todo list :)
[18:03] <diwic> When must upstream merge it for us to avoid that whence-file?
[18:04] <cnd> diwic, we've had difficulty getting upstream to merge our additions
[18:04] <cnd> so unless something changes, I think we'll definitely need it one way or another
[18:07] <apw> cnd, you don't have a middle button ...
[18:09] <cnd> apw, I have shift+insert
[18:09] <cnd> (and I do on my magicmouse :)
[18:09] <cnd> same difference
[18:12] <diwic> cnd, tgardner: Just to clarify, do you currently expect me to do something?
[18:14] <cnd> diwic, I think your changes are fine
[18:14] <cnd> there aren't any long licenses there that I can remember
[18:15] <cnd> the other stuff is just firmware packaging maintenance that I will get to sooner or later
[18:51] <sconklin> maxb: kernels are here: http://kernel.ubuntu.com/~sconklin/kernels-bug543617/ I'll update the bug with the same link
[18:51]  * maxb prepares to afk for beer, but will investigate tomorrow
[18:56] <maxb> bug 543617
[18:56] <ubot2> Launchpad bug 543617 in linux (Fedora) (and 3 other projects) "Unmount of an fs with dirty cache buffers causes pathological slowdown (affects: 9) (dups: 2) (heat: 101)" [Unknown,Unknown] https://launchpad.net/bugs/543617
[18:59] <sconklin> apw: are the writeback patches in maverick? I'm trying to get the bug status sorted
[19:00] <maxb> sconklin: Does your build also revert the temporary SAUCE mentioned earlier in the bug?
[19:00] <sconklin> maxb: sigh. I'll check. I thought it had already been dropped
[19:00] <maxb> sconklin: oh, maybe it has
[19:00] <maxb> I didn't check
[19:01] <maxb> sconklin: The fact I'm seeing this problem at all is suggestive that it has _not_ been dropped.
[19:02] <sconklin> maxb: No, it wasn't dropped. I'll fix it.
[19:03] <sconklin> I wish (again for the 10,000th time) that launchpad would let me delete or edit a comment
[19:11] <manjo> please check your credit card statements & any accounts you logged in while in prague, I got some suspicious charges on mine, looks like it happened while I was connected to the hotel wireless (but that is just a guess)
[19:21]  * tgardner lunches
[19:24] <apw> sconklin, i think they may be in -rc6
[19:24] <sconklin> apw: ok, thanks. I'll just set that line in the bug to invalid. It was targeted for 10.04 anyway.
[19:24] <apw> or fix released as it was affected originally
[19:33] <ogasawara> pft, 2.6.35-12.17 on ia64 isn't queued to build for another 2 days.
[19:42] <shadeslayer> er... is anyone looking into btrfs issues?
[19:44] <apw> shadeslayer, do we have any btrfs issues ?
[19:44] <shadeslayer> apw: i do
[19:44] <apw> with which kernel
[19:45] <apw> and what sort of issues
[19:45] <shadeslayer>  Linux kubuntu 2.6.35-11-generic #16-Ubuntu SMP Sat Jul 24 21:37:44 UTC 2010 x86_64 GNU/Linux
[19:45] <shadeslayer> ok so when i boot, the boot seems to be stuck at btrfs tools trying to fsck the partition
[19:46] <shadeslayer> ive been informed that this is a reported bug and btrfs.fsck can only fsck when the partition is offline
[19:46] <shadeslayer> so something needs to be done to either fix btrfs tools, or not fsck at all ( which is a BAD option )
[19:46] <apw> hrm sounds like a major limition ... presumably that renders it unsuitable for a root fs
[19:46] <shadeslayer> ^ totally
[19:46] <ogasawara> jjohansen: I'm seeing build failures for armel with apparmor http://pastebin.ubuntu.com/469927/
[19:47] <shadeslayer> apw: so my boot goes from a 20-25 sec boot to 40 sec boot
[19:47] <shadeslayer> lemme see if i have a bootchart
[19:47] <apw> sounds like btrfs is just the bees-knees
[19:47] <shadeslayer> :P
[19:47] <jjohansen> ogasawara: okay, that should be an easy fi
[19:48] <jjohansen> s/fi/fix
[19:48] <shadeslayer> apw: http://imgur.com/fPdyF
[19:49] <shadeslayer> please guys.. can you fix it in alpha 3 ? :D
[19:49] <shadeslayer> ill be reformatting my system to ext4 this weekend because of this :S
[19:49] <apw> shadeslayer, shouldn't think so :/
[19:49] <apw> yeah its not ready for prime time is it
[19:49] <shadeslayer> had high expectations from BTRFS :(
[19:50] <shadeslayer> apw: yep
[19:50] <apw> the authors told us it would save us from world hunger ... its a bit short of that
[19:50] <shadeslayer> i really wouldnt give out that option in the installer, since its this sucky
[19:51] <shadeslayer> apw: so what can be done?
[19:51] <shadeslayer> im ready to test .. but only till this saturday
[19:51] <shadeslayer> then i format everything :P
[20:09]  * ogasawara lunch
[20:12]  * shadeslayer is still waiting for a answer from apw
[20:29] <kees> ... how does armel not have vmalloc?
[20:30] <kees> or is it just a missed include that only manifests on armel?
[20:30] <kees> jjohansen: ^^
[20:30] <jjohansen> kees: it does, its just missing from one of the includes, lib didn't include it directly
[20:30] <kees> *whew*
[20:31]  * jjohansen has patched and is setting up new pull request
[20:41] <jjohansen> -> Lunch
[21:27] <sconklin> ok maxb there are new test kernels
[22:58] <squarebracket> any chance we can get the newest linuxwacom module in the next kernel release? it sucks having to recompile every time, not to mention the fact that new users have no idea what that means
[23:09] <komputes> I'm having this issue with a Dell Precision T7500 Workstation - https://bugs.edge.launchpad.net/ubuntu/+bug/579572 - I have tried rootdelay=60 but that doesn't work
[23:09] <ubot2> Ubuntu bug 579572 in ubuntu "Lucid: Gave up waiting for root device (mptsas) resolved by rootdelay (affects: 3) (heat: 64)" [Undecided,New]
[23:23] <komputes> Second question, Can I install a mainline 386 kernel when a pae kernel was previously there?