[00:55] <Q-FUNK> ogasawara: is there any new kernel for me to test on this Geode LX? :)
[00:56] <ogasawara> Q-FUNK: building it right now
[00:56] <Q-FUNK> ah, ok :)
[00:56] <Q-FUNK> I would give it a spin before going to bed
[00:56] <ogasawara> Q-FUNK: sorry for the delay.  I'll post a link in the bug when it's ready
[00:56] <Q-FUNK> alright :)
[01:05] <Q-FUNK> ogasawara: I dunno if this is relevant but, just for the heck, I tried using kernel-package on a 2.6.30 tarball with the 2.6.31-rc5 patch and that LKML guy's config and it failed to build on Karmic.  GCC kept on complaining about truncated files during build.
[01:06] <Q-FUNK> it built fine using the GCC on Jaunty, though.
[09:15]  * ogra scratches head, so why are all udebs built for linux-fsl ?
[09:16] <ogra> i thought tim disabled them
[11:00] <apw> ogra i thought there was much upset that they were missing
[11:00] <apw> i think they got reenabled cause cjwatson kindly fixed up kernel-wedge to make getting them to work possible in one lifetime
[11:10] <ogra> apw, yeah, it helps a lot, else i would have had to hack around it in the builder scripts, now i'm only missing meta and am done :)
[11:10] <apw> i assume that'll be a simple one
[11:10] <apw> now that the names are acceptable
[11:10] <apw> i assume the kernel works?
[11:13] <ogra> havent tested yet
[11:13] <ogra> i'll do so after i rolled a rootfs/bootloader for amitk 
[11:14] <apw> too late to change it a assume now anyhow?
[11:22] <ogra> well, its broken anyway
[11:23] <ogra> no USB and no NIC 
[11:23] <apw> ya
[11:23] <ogra> but it should boot
[11:23] <ogra> as long as it does that i'm happy
[11:40] <apw> its probabally to late to do anything about it even if it doesn't boot
[11:40] <apw> i assume the archive is basically frozen from today?
[11:41] <ogra> later today, yes
[11:41] <ogra> but our kernel is in universe ;)
[11:41] <ogra> i hacked up the builder scripts, so freeze doesnt affect us ;)
[11:41] <ogra> we could upload changes until last minute if needed
[11:42] <ogra> but i'm confident it boots, its amits config which i tested already and i dont belive the packaging trashed anything
[12:00] <amitk> the lange boards don't have ethernet :/
[12:00]  * amitk looks for usb-ethernet adapters
[12:01] <amitk> apw: did unison work for you?
[12:02] <apw> amitk, yeah did thank you, only used it for a small shared directory syncing back the accumulated sprint delta to it,but it seemed to work for me
[12:02] <apw> i'll need a bit more time to work out how i want to use it in my existing framework, but its looking useful
[12:05] <Q-FUNK> ogasawara: seems that we found our winner :)
[12:07] <amitk> apw: I have a .AMIT dir in $HOME. I move all my configs into that dir and symlink it from $HOME. e.g. .muttrc, .xemacs, etc. Then I sync .AMIT to all my machines.
[12:07] <amitk> ugly hack, but works.
[12:07] <apw> yeah i have something similar going on in general
[12:08] <apw> just the sync was mostly one sided there, and this makes it more bi directionally capable
[12:10] <ogra> amitk, did the redboot work for you ? 
[12:11] <amitk> yes
[12:12] <ogra> good to know 
[12:12] <ogra> i was told the lange requires a different redboot
[12:12] <ogra> but lool was wrong (or wrongly informed) then
[12:12] <apw> it may be documented to require a different one 
[12:13] <ogra> yes, though it might differ between lange 5.1 and 5.2 
[12:13] <apw> indeed
[12:18] <amitk> confusing
[12:19] <ogra> it gets funnier if you think about the fact that 5.1 is newer than 5.2 :)
[12:22] <lool> ogra: Hardware might not work if you're not using Lange's redboot with Lange boards
[12:23] <ogra> lool, ah, well, i think the 5.2 is still close enough to the babbage to work with TO2
[12:23] <lool> It might mostly work
[12:23] <ogra> 5.1 had more changes afaik
[12:23] <lool> 5.1 and 5.2 share the same lange52 tree in the sources we got
[12:23] <ogra> as long as it gets the kernel to run it should be fine
[12:24] <lool> No
[12:24] <ogra> not in redboot
[12:24] <lool> In RedBoot too
[12:24] <ogra> the redboot i have seen had two binary trees 
[12:24] <ogra> not sure how much they differ though
[12:24] <lool> Yeah one for lange31 and the other for lange 5.x named lange52
[12:24]  * ogra admits he didnt look very close
[12:26] <lool> Ok don't state that I was wrong then
[12:26] <lool> (Sorry but it's a bit annoying)
[12:27] <ogra> sorry
[12:27] <lool> amitk: Lange 5.1 does have Ethernet on the board but it's wired over the USB bus
[12:27] <lool> i.e. it's an USB Ethernet adpater soldered on the board
[12:27] <ogra> he only has 5.2
[12:28] <ogra> and no babbage anymore
[12:28] <ogra> 5.2 only has wireless and no driver 
[12:30] <amitk> yeah, it is a PITA to develop one since I can't get my kernel over http
[12:30] <amitk> s/one/on
[12:31] <ogra> thats why i set up the rootfs to be able to use flash-kernel
[12:31] <amitk> true, but it requires me to build .debs I guess.
[12:31] <ogra> no
[12:32] <amitk> ohh?
[12:32] <amitk> just copy it to /boot and  run flash-kernel, then?
[12:32] <ogra> just cp your zImage over the /boot/vmlinuz-2.6.31-0-babbage
[12:32] <amitk> cool
[12:32] <ogra> then run flash-kernel and reboot
[12:32] <ogra> i forgot to install linux-firmware, you might need that if you want to use a usb NIC
[12:33] <lool> ogra: I was responding to the comment that "< amitk> the lange boards don't have ethernet :/"
[12:33] <ogra> lool, yeah, i know
[12:34] <lool> amitk: You might want to script some fis based script to update your SD card and take it out to write the kernel
[12:34] <lool> (In case your kernel doesn't boot and you can't run flash-kernel)
[12:35] <lool> That's shorter than serial port pushes
[12:35] <lool> amitk: These are old notes I have to do that by hand: http://paste.ubuntu.com/251307/
[12:35] <ogra> amitk, http://paste.ubuntu.com/251308/
[12:36] <lool> You need the redboot-tools package for the fis command
[12:36] <ogra> thats what i use with the same setup i gave you
[12:36] <ogra> from my laptop
[12:36] <lool> amitk: You don't need the padding
[14:31] <ogra> rtg, my babbage images will build from universe, that should give us some extra hours for the meta (we can slip the freeze a bit)
[14:31] <rtg> bjf, you probably ought to update the meeting page https://wiki.ubuntu.com/KernelTeam/Meeting
[14:32] <rtg> ogra, I'll get the fsl meta package done today
[14:32] <ogra> cool
[14:33] <rtg> I live to serve
[14:38] <bjf> rtg, done, I just had the date of the next meeting hosed, the rest of the info is up to date
[14:38] <rtg> bjf, 'tanks
[14:43] <lool> rtg: Hey Marvell currently pushed kernel trees to kernel.u.c; do you think it would be an issue if they pushed u-boot as well?
[14:44] <rtg> lool, we've plenty of disk. 
[14:44] <lool> Ok thanks
[14:45] <rtg> lool, in general, anything they push should be gplv2. other then that I don't much care.
[14:45] <lool> rtg: I'm not sure it's GPL *v2*
[14:45] <rtg> lool, its some open source license, right?
[14:45] <lool> I rather suspect it's a mixture of GPL versions and perhaps LGPL along; but it's as opensource as u-boot is
[14:45] <lool> It is
[14:46] <mjg59> A mix of GPL and LGPL is GPL
[14:46] <lool> mjg59: A mix of GPL and LGPL is a mix of GPL and LGPL  :)
[14:46] <lool> You might mean the binaries are effectively GPL
[14:46] <mjg59> No, I mean the work is GPL. Sections of it may have additional permissions.
[14:48] <ogra> rtg, btw, i changed the buildscripts already to use linux-babbage, if you pick any other binary name for meta, please let me know before the freeze is in effect (that has to go to min)
[14:48] <ogra> *main
[14:49] <rtg> ogra, in fact, I was just researching that. 
[14:49] <ogra> well, if you use another name, tell me what it will be, livecd-rootfs needs to know the name of the binary for building
[14:50] <rtg> ogra, what about updates from Jaunty? the previous meta package binary was linux-image-imx51, etc.
[14:50] <ogra> you will need to add conflicts and replaces line in your new control file for the old names
[14:51] <ogra> *lines
[14:51] <lool> rtg: I personally have objections to the fsl-imx51/babbage names but I think we should fix that post a4
[14:51] <rtg> lool, ogra: well, I'm doing the meta package right now. I might as well choose the names that you guys want.
[14:51] <lool> rtg: I'd rather we change the linux image name back to imx51 after a4, but because that was already uploaded and we're in a hurry, it's best to defer to post a4 I think
[14:52] <lool> rtg: The linux-image names are incorrect; I prefer if both match at all times and we'll fix it after A4
[14:52] <ogra> rtg, well linux-imx51 would indeed be best and cause least hassle
[14:52] <lool> I mean the ABI versionned names
[14:52] <lool> I'm not sure it's a good idea to go for a mismatch at this point
[14:52] <ogra> lool, lets not confuse this conversation to much, its currently only about meta 
[14:53] <lool> We might not be seeing the consequences if the ABI versionned name and the meta name dont match
[14:53] <ogra> because meta will go in the archive now, while the actual binaries are in already
[14:53] <rtg> ok, but I'm getting different input from amitk. How about you guys get together and decide on the final names? In the meantime I'll just name the meta packages *imx51*
[14:53] <lool> amitk: What's your input?
[14:53] <ogra> ok, i'll change livecd-rootfs back 
[14:54] <lool> ogra: ?
[14:54] <rtg> ogra, just wait until you actually see what gets produced.
[14:54] <ogra> rtg, i need to do it before freeze 
[14:54] <lool> ogra: You dont know what the name will be; just leave it alone until you do?
[14:54] <ogra> it affects other arches if i make a typo or something, livecd-rootfs is used by all live images across the board (and in main)
[14:55] <rtg> ogra, then tell me the exact package names upon which your livecd build depends.
[14:55] <lool> It does not affect other arches if your build fails
[14:55] <ogra> lool, i had to add universe today already
[14:55] <amitk> lool: send me an email in writing that all imx51 flavours will run on a single kernel and I'll agree to your proposal. IMHO, the distro should only concentrate on the dev boards, not OEM ones.
[14:55] <lool> But it does if you do a syntax error yes
[14:55] <lool> amitk: Ok
[14:55] <ogra> lool, so i changed to what the description of the linux image package says (linux-babbage) with a note that i will change back to what it actually will be
[14:56] <lool> amitk: I think the way you present it makes it highly political instead of being simpl technical but I have no problem in putting my views in an email
[14:56] <ogra> i just dont want to change livecd-rootfs after the freeze
[14:57] <amitk> lool: it _is_ political. Someone is going to come in a few months wanting to enable an OEM board that doesn't work off the same binary.
[14:57] <amitk> then we do the naming dance again.
[14:57] <rtg> amitk, how can all imx51 flavours run from one kernel? We've already got 2 ARM kernel trees.
[14:58] <rtg> aren't they both imx51 variants?
[14:58] <amitk> rtg: you are confusing single SoC, multiple boards vs. a branch for each SoC. I think.
[14:58] <amitk> in theory, multiple boards _can_ run from a single kernel binary. If the code is written such.
[14:59] <rtg> amitk, you are right in that I'm confused :)
[14:59] <ogra> rtg, currently all babbage boards run from the imx51 tree ... we would like to add support for lange as well as its the same arch effectively 
[14:59] <rtg> where does dove fit into that mess?
[14:59] <ogra> the current naming scheme would men to have a -babbage flavour and a -lange flavour
[14:59] <amitk> rtg: dove == separate SoC from marvell
[14:59] <ogra> dove is a different thing
[15:00] <rtg> its not imx51 compatible?
[15:00] <amitk> ogra: or a -lange flavour aliases to -babbage if that is possible.
[15:00] <ogra> having a -babbage and a -lange flavour would effectively enforce us to build two images for each of them (rootf images i mean)
[15:01] <ogra> having simply a binary that supports all of imx51 would not cause such probs 
[15:01] <ogra> and currently it doesnt look like we would actually need any -lange flavour at all, the patches all apply to the imx51 tree without touching babbage stuff afaik
[15:02] <ogra> having that two name setup effectively binds the double amount of ressources, costs the double space for images and twice the amount of maintenance
[15:02] <amitk> rtg: please don't get distracted by this naming issue for A4. This conversation should _really_ have been brought up after A4.
[15:02] <ogra> right
[15:03] <ogra> it's nothing to have now, binary kernels are up now and wont change atm
[15:03] <rtg> amitk, ogra: ok, I'm gonna email the meta naming convention so that you have it in writing.
[15:03] <ogra> thanks
[15:04] <lool> amitk: There you go
[15:04] <lool> amitk: I agree this should all be post A4
[15:04] <levonshe> Hi guys, sorry to interrupt your discusssin, just simple question -  Please explain why ubuntu kernel ftp site lists separate mdules, like virtio-modules-2.6.31-5-generic-di_2.6.31-5.24_i386.udeb . I thought these modules should be a product of kernel compilation?  
[15:04] <lool> amitk: Do you agree we should just use babbage in meta as well now for a$?
[15:04] <lool> a$
[15:04] <lool> grr
[15:05] <lool> a4
[15:05]  * ogra doesnt care as long as he gets told the right name :)
[15:05] <amitk> lool: agreed. It will be easier to rename everything if we decide to.
[15:06] <ogra> rtg, so call it linux-babbage for now and we'll adjust post A4
[15:07] <ogra> rtg, and dont care about upgrade paths for now, its only important that we have solved that for final, A4 is only first shot 
[15:12] <rtg> ogra, email sent
[15:13] <ogra> rtg, agreed for A4 ...
[15:14] <rtg> ogra, cool. when you want the names changed post A4 please start an LP bug so that we're all reading the same page.
[15:14] <ogra> yeah, good idea
[15:14] <ogra> lool, mind to file it since you are the driving power here ? 
[15:15] <rtg> ogra, lool: make sure you assign it to me lest I not see it in the blizzard of bug reports.
[15:15] <ogra> indeed :)
[15:16] <lool> Sorry I'm in a call
[15:16] <lool> File a bug on the renaming?
[15:16] <lool> Sure can do
[15:16] <ogra> great, thanks
[15:16]  * ogra would do it but you have the best arguments :)
[15:19] <apw> levonshe, those .udeb files are the result of kernel compilation
[15:20] <lool> rtg: What's the package name for meta?
[15:20] <ogra> levonshe, they are not used in normal systems though
[15:20] <lool> rtg: I mean same meta?
[15:20] <ogra> lool, linux-babbage says the mail
[15:20] <lool> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/411968
[15:20] <ubot3> Malone bug 411968 in linux-fsl-imx51 "Please rename babbage to imx51, just like in jaunty" [Undecided,New] 
[15:20] <ogra> lool, meta isnt uploaded yet
[15:20] <lool> ogra: I mean the source
[15:25] <rtg> apw, re: bug #350789. I though we fixed it?
[15:25] <ubot3> Malone bug 350789 in linux "AppArmor Debug: Hook being called from interrupt context" [Medium,Triaged] https://launchpad.net/bugs/350789
[15:26] <jjohansen> rtg: we did
[15:26] <apw> yeah its only on our lists cause its in an odd state
[15:26] <jjohansen> rtg: status is updated
[15:27] <apw> jjohansen, ta
[15:27] <apw> jjohansen, is the fix applicable to Karmic, or already applied there?
[15:27] <jjohansen> apw: already applied
[15:27] <apw> and released?
[15:28] <jjohansen> apw: yeah, it actually has a slightly alternate fix in it from the start
[15:28] <apw> so its already uploaded in karmic?  then the linux(ubuntu) task should be Fix Released
[15:28] <jjohansen> ah okay
[15:29] <apw> and i don't think it can be assigned to a jaunty milestone
[15:32] <Q-FUNK> TheMuso: it appears that those changes in alsa-utils and pulseaudio to rely upon udev features have bombed majorly.  how can we fix them?
[16:26] <rtg> ogra, linux-meta-fsl-imx51 uploaded. perhaps you could annoy the various mobile team archive admins in order to get this package processed through NEW ? I'm off onto the next big thing...
[16:26] <ogra> will do, i'll yank your chain if it fails to build though ;)
[16:27] <rtg> ogra, I would expect no less.
[16:59] <bjf> >>
[16:59] <bjf> >> Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:59] <bjf> >>
[17:48] <ogra> rtg, james_w had some complaints aout meta but left it through
 ogra: I don't think there's a need for it to explain the history of linux in debian/copyright given that it's just a metapackage
 plus, Vcs-Git is invalid
[17:48] <ogra> (for the next round :) )
[17:49] <rtg> ogra, what's wrong with 'Vcs-Git: http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-karmic-meta.git fsl-imx51' ?
[17:50] <ogra> no idea, i havent complained
[17:50] <apw> rtg, i've got a couple of karmic updates dropping stuff from ubuntu as per discussions at sprint... is the tree up to date?
[17:51] <rtg> apw, nail it
[17:52] <rtg> apw, and while you're at it, make sure I haven't wrecked anything. there are a few packaging changes
[17:53] <apw> will do ... i'll be uploading it to my preview ppa so that'll be a good test
[17:53] <rtg> ogra, the copyright does seem a bit over the top, but then its been there since Feisty AFAIK
[17:54] <ogra> well, lets ask james for the actual final meta, i dont think we need to care for that one at all
[18:42] <apw> rtg ok i've just uploaded karmic tip to my daily PPA
[18:43] <apw> we'll know shortly if its all spagetti
[18:46] <rtg> apw, well, I _did_ build it here before I pushed :)
[18:50] <maco> iwlagn is currently using 101% of CPU on my system. this has to be bug.  have any of you run into it?
[18:52] <rtg> maco, seems like a lot. have you contacted anyone on the wireless mailing list?
[18:53] <maco> no, id thought it stopped. i dont think it was doing it with -3 but its there in -5 again
[18:53] <rtg> sconklin, I'll see your comment, and raise you by one. https://launchpad.net/bugs/412039
[18:53] <ubot3> Malone bug 412039 in linux-backports-modules-2.6.28 "ath5k: Add LED support for Acer device" [Medium,In progress] 
[18:54] <rtg> maco, does it still happen with Karmic LBM ?
[18:55] <maco> rtg: its nondeterministic. if i modprobe -r and then modprobe, itll stop
[18:56] <maco> "i dont think it happened on -3" means "i dont recall getting annoyed at my keystrokes not being registered in the last couple weeks...uh...."
[18:56] <maco> (when it pegs my cpu, and i try to type, some keystrokes just get dropped)
[18:57] <rtg> maco, that kind of implies an interrupt storm
[18:57] <maco> i can try installing lbm, but since i dont have any nice reproducible way to get it to happen...
[18:57] <maco> im behind a nat, so i doubt anyone's trying to DoS my laptop and actually reaching it
[18:58] <maco> if thats what you mean by interrupt storm....that the interface is being hammered
[18:58] <rtg> maco, no, I mean that the firmware might be misbehaving and generating too many interrupts. Hence, your loss of keyboard inputs
[18:59] <maco> ah.  i was surprised to see iwlagn being a process of its own
[18:59] <maco> would lbm have new firmware? i didnt think it did
[18:59] <rtg> maco, I think iwlagn still uses their own rate selection process, so perhaps its that thread running amok
[19:00] <rtg> I'm checking on firmware versions 'cause I can't remember
[19:01] <rtg> maco, i4965 is one minor rev newer. everything else looks the same.
[19:01] <maco> alright, ill give it a try then
[19:02] <rtg> doh, i4965 is the same. I'm dislexic. 
[19:02] <maco> oh
[19:02] <rtg> the biggest difference with LBM will be in the driver itself.
[19:02] <rtg> its worth a shot
[19:03] <maco> ok any suggestions on why Xorg is using 58% of CPU (now.... before iwlagn started acting up it was using 98%) when ive got compositing off? or should i ask #ubuntu-x that one?
[19:04] <rtg> maco, definitely an X question
[19:04] <maco> (yay dual core! actually makes it possible for wireless to use 100%, graphics to use 60% and my mail client to use 40%)
[19:04] <rtg> maco, you're kind of hell on battery life :)
[19:06] <maco> rtg: well none of the above SHOULD use as much cpu as they do
[19:06] <rtg> maco, hence my amusement.
[19:07] <maco> if i wanted to compile anything, id be screwed
[19:07] <maco> itd take a week
[19:08] <maco> actually, i find my cpu spins up all hot and crazy when i compile things on a remote system over ssh and dont even have that ssh screen visible (so drawing the compile output isnt the issue)
[19:08] <maco> rtg: maybe iwlagn goes stupid when there's lots of small amounts of data going through?
[19:09] <rtg> maco, it still generates plenty of network traffic (lots of small packets)
[19:09] <rtg> maco, try using screen on the remote, then disconnect
[19:09] <maco> so maybe IRC is the ame way?
[19:09] <maco> *same
[19:09] <rtg> hmm, IRC generates such a small amount of traffic.
[19:09] <maco> when in 35 channels?
[19:10] <rtg> even so, unless someone is pasting a boatload of stuff, there really isn't that much.
[19:10] <maco> im trying to think...maybe the combination of IRC + KMail syncing + apt = iwlagn :(
[19:11] <rtg> maco, possibly. I'd drop a not to the wireless folks. perhaps they've already seen something similar.
[19:11] <rtg> note*
[19:12] <maco> ok
[19:59] <Q-FUNK> ogasawara: seems that I got bingo on that Bug #396286 
[19:59] <ubot3> Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
[20:00] <ogasawara> Q-FUNK: I'm building the next test kernel, just have to give it a while to finish building
[20:00] <ogasawara> Q-FUNK: as usual, I'll post to the bug when it's ready
[20:01] <Q-FUNK> ogasawara: ok. I was just curious to hear about possible causes I should watch for.
[20:01] <ogasawara> Q-FUNK: that's what we're narrowing down
[20:01] <ogasawara> Q-FUNK: there's 71 commits left to bisect
[20:05] <Q-FUNK> oh
[20:06] <Q-FUNK> between 999.200908071658 and 999.200908110142 you meant?
[20:08] <Q-FUNK> as 2.6.30.999.200908110142 crashes during boot while 2.6.30.999.200908071658 didn't
[20:09] <ogasawara> Q-FUNK: right, narrowing it down between those two
[20:27] <Kev__> hi
[20:28] <Kev__> there is a problem with the configuration of the ubuntu kernel which lets a system freeze completely
[20:32] <Kev__> it concerns the configure symbol CONFIG_SATA_PMP which has some bug that will freeze some systems under heavy IO Load
[21:01] <mcasadevall> apw, I have a config patch for SPARC for you (it just built off the latest head as of a few hours ago)
[21:01] <mcasadevall> (I fear if I send it to the list, I'll hit the moderation queue again)
[21:40] <Noble> Hi, I've got a MSI notebook with UNR installed. Some kid told me that using the 2.6.30 kernel would improve speed. How do I go about installing it?
[22:10] <Kev__> speed of what?