[01:44] <cesarb> I just noticed that the builds from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc5/ do not have CONFIG_MEDIA_SUPPORT set, which makes it harder to test anything webcam-related.
[01:45] <cesarb> Should I report it somewhere?
[10:16] <Q-FUNK> howdy!
[10:17] <Q-FUNK> I'm wondering what is the correct syntax for declaring the framebuffer size on grub cmdline, these days?  vga=794 no longer works, it seems.
[10:18] <Q-FUNK> have we reverted to hex values again?
[11:15] <apw> Keybuk, hey ... floppies ... do you think its reasonable to automatically scan those for partitions?  or more specificially do you think its unreasonable to not scan them?
[11:17] <Keybuk> err, floppies can't have partitions
[11:17] <apw> Q-FUNK, i've alway seen hex used, i have also seen vga=ask which lists them and lets you select
[11:17] <apw> they really can
[11:17] <Keybuk> no they can't
[11:17] <apw> they have an mbr, therefore they can have a partition table, as far as i know
[11:17] <apw> but i am happy to hear scanning them is stupid in your opinion :)
[11:18] <Keybuk> actually that's not correct ;)
[11:18] <Keybuk> floppy disks have a volume boot sector
[11:18] <apw> please educate me, it not being possible is very handy
[11:18] <Keybuk> not an mbr
[11:18] <Q-FUNK> apw: found the solution.  it just seems that fbdev used to be compiled-in on ubuntu kernels. not anymore.  plus, it's blacklisted in some modprobe.d config.
[11:19] <Q-FUNK> öö.. vesafb
[11:19] <Keybuk> apw: just to confirm
[11:19] <Keybuk> we're talking about the legacy floppy controller here
[11:19] <Keybuk> not IDE or SCSI "floppy" drives, right?
[11:19] <apw> yes, the legacy isa one, not scsi etc
[11:19] <Keybuk> you don't mean ISA do you?
[11:19] <Keybuk> hard-wired one?
[11:19] <apw> i mean the crappy old one most of us don't have :)
[11:19] <Keybuk> right
[11:20] <apw> so i think thats the cause of the boot delays, devkit-disk is running on the floppy
[11:20] <Keybuk> really?
[11:20] <apw> and trying to find the partition table, even when there is no media, and its takign 48 seconds
[11:20] <Keybuk> that's probably
[11:20] <apw> i had someone time it, 48s to run devkit-disks on it
[11:20] <Keybuk> that devkit-disks rules is causing a *lot* of problems
[11:21] <apw> (this is the case when you dont have a floppy drive)
[11:21] <apw> cool.  then i think i can simply justify skipping those checks on a floppy
[11:21] <Keybuk> yeah
[11:21] <Keybuk> talk to upstream though
[11:21] <Keybuk> don't patch the rules locally
[11:22] <apw> upstream being debian i assume
[11:22] <Keybuk> no
[11:22] <Keybuk> upstream being devkit-disks upstream
[11:22] <Keybuk> we have a strong policy of not shipping modified udev rules for any of the plumbing layer
[11:22] <apw> oh are the rules coming from there... hrm
[11:22] <apw> ok ...
[11:23] <Keybuk> https://bugzilla.redhat.com/show_bug.cgi?id=489083
[11:23] <ubot3> bugzilla.redhat.com bug 489083 in DeviceKit-disks "devkit-disk tortures my good old floppy drive" [Medium,Closed: errata] 
[11:24] <Keybuk> looks from that like davidz is quite happy with the "ignore legacy floppy" approach
[11:24] <Keybuk> and this is just an omission
[11:25] <Keybuk> interestingly
[11:25] <Keybuk> in 60-persistent-storage.rules:
[11:25] <Keybuk> KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*", GOTO="persistent_storage_end"
[11:25] <Keybuk> but in 95-devkit-disks.rules:
[11:25] <Keybuk> KERNEL=="mtd*|nbd*|gnbd*|btibm*", GOTO="probe_parttable_end"
[11:25] <Keybuk> so they don't quite match
[11:25] <Keybuk> I'll chat to David when he wakes up
[11:26] <apw> Keybuk, thanks
[11:26] <apw> yeah my proposal was to add fd* to the latter one
[11:27] <Keybuk> right
[11:27] <Keybuk> that would be the fix
[11:27] <Keybuk> let me get it fixed upstream though ;)
[11:27] <apw> fair enough for me
[11:27] <apw> less work :)
[11:27] <apw> i should mark the bug for devkit-disks i guess ... will do that
[11:28] <Keybuk> yup
[11:43] <apw> Keybuk, done
[13:24] <mhatch> Two quick questions:  1.  Why is the AHCI and ATA drivers compiled directly into the kernel in 9.04 Server, and 2.  Is there a way to change the order in which these drivers are loaded?  I could do this with modules in the past but I have yet to determine if it's possible when the drivers were compiled directly into the kernel.
[13:33] <amitk> who is our squashfs expert?
[13:33] <amitk> I've got a problem with the fsl live image: http://pastebin.ubuntu.com/252472/
[13:33] <rtg> amitk, apw did the port
[13:34] <amitk> squashfs had to be ported?
[13:34] <rtg> well, integrated I guess
[13:34]  * apw looks up... huh?
[13:35] <apw> that pastebin think looks like there is no filesystem?
[13:36] <amitk> apw: squashfs, bug, http://pastebin.ubuntu.com/252472/, clue?
[13:36] <apw> SQUASHFS error: squashfs_read_data failed to read block 0x0
[13:36] <apw> it panicing after a read error might be reasonable
[13:36] <apw> where is the squashfs stored?
[13:36] <ogra> vfat partition
[13:37] <ogra> on mmc
[13:38] <apw> rtg squashfs went upstream didn't it?
[13:38] <apw> it was compcache i ported
[13:38] <rtg> apw, uh, right. I was confusing it with AUFS
[13:45] <apw> amitk, ogra that error is nearly useless it can mean one of at least 5 different failures
[13:45] <apw> probabally a decompression failure
[13:46] <apw> how do we build these squashfs things?
[13:46] <ogra> a simple mksquashfs
[13:46] <apw> do we have a userspace tool to check its integrity like we do with initrds?
[13:46] <ogra> apt-get source livecd-rootfs ... see the bottom of the livefs.sh script
[13:47] <ogra>     mksquashfs ${ROOT} livecd.${FSS}.squashfs -sort livecd.${FSS}.sort
[13:47] <ogra>     chmod 644 livecd.${FSS}.squashfs
[13:49] <apw> ogra, i guess the first test is to pull the MMC and see if you can successffuly run unsquashfs on it
[13:49]  * ogra does so
[13:51] <apw> there is no real error before to say it failed to load anything
[13:54] <ogra> hmm, trying to unsuqsh on i386 doesnt work so far
[13:55] <ogra> http://paste.ubuntu.com/252484/
[13:55]  * ogra copies the file over to an arm board
[13:56] <ogra> takes a moment ...
[13:57] <amitk> squashfs data shouldn't really be arch-specific, should it?
[13:57] <ogra> no
[13:57] <krgn> hi
[13:58] <ogra> amitk, but to be sure i'll try it anyway, the squashfs was built on armel
[13:58] <ogra> though it will take another 10min to copy 
[13:58] <krgn> if I need to build a kernel from vanilla for some reason, how to initialise the source tree so I have all the build scripts in debian/ etc?
[13:59] <amitk> krgn: you could just use the pre-built vanilla kernels if you don't need extra patches
[14:00] <krgn> amitk: I do need extra patches though
[14:00] <krgn> amitk: is there a script that creates debian/ ?
[14:01] <rtg> krgn, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[14:03] <krgn> amitk: thanks for the link
[14:07] <amitk> krgn: you could also look at https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds and just download the source .deb of the last mainline build
[14:09] <ogra> amitk, though i shouldnt get an oops (i dont get one on i386) even with a corrupted fs
[14:10] <ogra> i can properly reproduce the oops with mount -o loop -t squashfs filesystem.squashfs /cdrom ... in the initramfs
[14:11] <amitk> ogra: that bug should go upstream through kerneloops/apport
[14:11] <ogra> complicated :P 
[14:12] <ogra> we dont have kerneloops in initramfs 
[14:12] <amitk> I can see the same issue trying to mount the squashfs on my laptop
[14:12] <amitk> and it triggers kerneloops ;)
[14:15] <amitk> it would be interesting to see how the armel liveimage squashfs differs from the i386
[14:16] <amitk> ogra: ^
[14:16] <ogra> OH !
[14:16] <ogra> ogra@dove:~/temp$ file filesystem.squashfs 
[14:16] <ogra> filesystem.squashfs: Squashfs filesystem, little endian, version 4.0, 179630923519 bytes, 113897 inodes, blocksize: 41 bytes, created: Sun Jan 15 06:02:56 1967
[14:16] <ogra> thats pre-epoch
[14:17] <amitk> heh
[14:17] <ogra> i wonder if that has any influence
[14:17] <ogra> it definately shouldnt but you never know
[14:17] <amitk> I guess I should refuse to work on things that were created before I was born ;)
[14:18] <ogra> heh
[14:21] <amitk> ogra: BTW squashfs isn't oopsing. It is a warning.
[14:21] <ogra> cant they make their warnings look like warnings ? 
[14:22] <ogra> its confusing to have a stacktrace in a warning
[14:22] <amitk> they do, WARNING: at /build/buildd/linux-fsl-imx51-2.6.31/fs/inode.c:699 unlock_new_inode+0x40/0x4c()
[14:22] <ogra> yeah, but attach a stacktrace below
[14:32] <rtg> apw, I'm having a brain fade. How do you get the SHA1 of HEAD for the branch you are on?
[14:32] <apw> git show has it
[14:32] <apw> to get just the raw one there is a command
[14:33] <apw> git show-ref HEAD
[14:34] <apw> hmm not sure that does what you might hope
[14:34] <rtg> apw, ah, thats it.
[14:34] <apw> hmmm no thats not getting the right head
[14:35] <rtg> apw, 'tis for me
[14:35] <apw> whats the second word tho.
[14:35] <apw> on mine its a remote ref
[14:35] <apw> 73aa74e5a55563ac54c161f307f8fc282a8f4e47 refs/remotes/origin/HEAD
[14:36] <rtg> you're right, but its OK in my case.
[14:36] <rtg> I guess you could always 'git log |head -n1 ...'
[14:37] <apw> apw@penfold:~/git2/ubuntu-karmic$ git log --pretty=format:%H HEAD^..HEAD
[14:37] <apw> 3844ea1e7161a8883a1a52b7b176d5f6c29be463
[14:37] <apw> looks to me one way
[15:21] <cking> amitk, ogra, so is this really a squashfs kernel error or not?
[15:21] <ogra> cking, i start to suspect its userspace induced
[15:22] <ogra> i cant loop mount the squashfs anywhere nor can i unsquash
[15:22] <cking> it's not some weird endianess issue?
[15:22] <ogra> we didnt have endianess issues in jaunty
[15:23] <ogra> it was the very same script we used to build images
[15:23] <ogra> just with squashfs-tools 3.0 
[15:23] <ogra> or 3.3 or whatever
[15:23] <ogra> while we use 4.0 now
[15:24] <cking> ARM specific or a generic issue?
[15:24] <ogra> works on the ubuntu livecds and i guess also on UNR vfat images
[15:32] <apw> ogra, hrm, so unsquashfs failed too?  at least the kernel isn't going mad
[15:32] <ogra> right, mount fails as well as unsquashfs
[15:33] <ogra> i'm just rebuilding the image on the build servers to see if it was a temporary hiccup or something
[15:33] <ogra> i'll also rebuild one locally
[15:33] <apw> ogra, sensible but a bit scarey
[15:39] <cking> apw, I'm getting audio clicks after ~10 seconds of not using audio on karmic on my HP mini - you referred to this a while ago - do you know what the workaround is?
[15:40] <apw> thats the amps going off, there is new code to do that, power them down to save power
[15:42] <apw> bug #380892 is where it was turned on and lists how to supress it
[15:42] <ubot3> Malone bug 380892 in alsa-driver "[9.10 regression] HDA power_save=10"" [Undecided,New] https://launchpad.net/bugs/380892
[15:42] <rtg> cking, thats the patch I showed you while in Dublin
[15:43] <cking> rtg, of course, that's the one - I'm kind of fuzzy headed at the moment - I'm pain killer'd out and had a tooth worked on earlier today ;-)
[15:44] <rtg> cking, dude - you should be napping :)
[15:45] <cking> maybe in a couple of hours :-)
[15:45] <cking> anyhow, the pain in the mouth has gone so that's a result!
[15:48] <apw> cking, heh ... its funny how good one feels when a pain you had is gone
[15:49] <apw> of course in your case the pop is thought to be a known issue with your specific lappy, so we don't want to fix it generally
[15:50] <cking> I think there could be a work around by tweaking the EAPD pin and waiting 250ms.. hrmm..
[15:53] <rtg> ogra, new crack in the Karmic Dove branch, rebased against -rc5
[15:54] <ogra> cool
[15:54] <ogra> i'll update my local stuff soon then
[16:11] <apw> cking, ? i thought we always did that (the turn offy wait thing)
[16:15] <cking> apw, not sure for karmic.
[16:15]  * cking goes and has a peep
[16:15] <apw> i think i've missunderstood, i though the EAPD thing was a std and supported ... clearly not
[16:16]  * cking does some vague handywavy statement : possibly, it depends.
[16:16]  * apw adds cking to ubuntu-audio, *whistles*
[16:16] <cking> no - taint me not
[16:17] <apw> toooooo late
[16:17] <cking> humbug
[16:20] <cking> apw, we probably should add the clicky audio pop power check to those manjo tests
[16:21] <apw> yeah how would one test that i wonder
[16:21] <cking> make a sound, wait 20 seconds, "do you hear a pop?"
[16:22] <apw> heh yeah i guess so
[16:22]  * apw notes that firefox has become a crashy pos today, and i didn't even update it
[16:23] <cking> Must be the flash-tastic sites you're looking at
[16:23] <apw> freshly started no flash
[16:24] <cking> Hrm. I'm now on 3.5.2 - it's been as solid as the previous 3.0.x version
[16:25] <apw> 3.0.13, and its new behaviour today.  and as far as i know i've not installed any fixes
[16:26] <cking> if only one had "apt-unget  yesterday" 
[16:56] <manjo> carefully applying all the audio patches that dtchen suggested did not fix sound on xps1300
[16:56] <manjo> 1330
[16:57] <ogra> probably be less careful ?
[17:03]  * manjo plugs ogra's babbage 2.5 board into the network and watches it die
[17:04] <ogra> :P
[17:28] <cking> apw, what's the story behind the broadcom b43 driver on Karmic - where can I peek at the driver?
[17:29] <apw> cking, hrm which one is that.  there are so many broadcom ones
[17:29] <apw> is that the one which drives BCM43xx devices?
[17:29] <apw> the one on the mini for instance?
[17:30] <cking> That's what I'm confused about. I've just installed karmic in a HP mini 1000 and it's grumbling at me.
[17:30] <apw> and not working?
[17:30] <apw> there seem to be three options
[17:30] <cking> ..yep - no workies. 
[17:30] <apw> there is b43 and b43legacy in the kernel
[17:30] <cking> 3 options(!)
[17:31] <apw> plus there is bcmwl-kernel-source which is a dkms thingy which carries some binary blob
[17:31] <apw> that is the one which works on my mini10
[17:31] <apw> 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
[17:32] <cking> how does one get the bcmwl-kernel-source installed?
[17:33] <apw> i installed it by hand using apt-get i think
[17:33] <cking> bit tricky w/o a network connecton
[17:33] <apw> i think that was sufficient, reboot required i think
[17:33] <apw> i used an ethernet cable to install it
[17:33] <cking> that don't work either. This is a tad regression bound at the mo
[17:33] <apw> a usb stick for someone at sprint
[17:34] <apw> i just got the .deb from the pool and shoved it on
[17:34] <cking> OK. That's a cunning plan
[17:34]  * apw looks up cunning ... hmmm
[17:38]  * cking wonders how the average punter is gonna handle this 
[17:42] <zul_> has anyone seen this before?
[17:42] <zul_> /usr/bin/ld.real: kernel image bigger than KERNEL_IMAGE_SIZE
[17:44] <apw> zul_, not seen that no
[17:44] <apw> cking, they arn't
[17:45] <apw> thats why oem ship their own installs
[17:45] <apw> cking, so any idea what an ssb id is ?
[17:45] <cking> what's the context?
[17:46] <apw> the b43 driver is using ssb ids for matching not pci vendory things as normal
[17:46] <apw> looks to be some kind of bridgey thing
[17:47] <cking> yeah "b43: probe of ssb0:0 failed with error -95"...
[17:47] <apw> is that from the default kernel modules?
[17:47] <cking> yep. use the source luke
[17:47] <apw> now i am lost as i don't have an lsssb -nnvv to get them
[17:50]  * apw is using the source and getting moany :)
[17:50] <apw> cking, i wonder if lbm would help here, as it has wireless more up to date in it
[17:51] <cking> maybe
[17:51] <apw> that might be worth a go
[17:51] <cking> urgh.. running out of time..
[17:51]  * apw looks at the lbm to see what it has in it
[19:19] <krgn> hey all
[19:20] <krgn> I have the following scenario: I have a vanilla source tree but use the debian/ dir from karmic git
[19:20] <krgn> actually I get this error too with jaunty
[19:21] <krgn> but when I execute debian/rules binary-generic or binary-arch it just tells me that binary-generic isn't defined
[19:21] <krgn> make: *** No rule to make target `binary-generic', needed by `binary-debs'.  Stop.