[00:34] <akgraner> kirkland, alrighty I'll start tracking people down
[00:44] <akgraner> zul, ping per kirkland he said to see if you could maybe lead the server Q&A tomorrow since he can't?
[01:31] <grapz> hi, i'm having some issues with 10.04 and the MCP89 chipset on a MacBook Pro trying to boot 10.04 LiveCD
[04:27] <maxb> Can anyone tell me what 'invalid opcode: 0000 [#1] SMP' in dmesg means?
[04:41] <jk-> max: something tried to execute an invalid instruction
[04:41] <jk-> can you pastebin the whole dmesg?
[06:22] <bullgard4> '~$ ps -ef | grep flush; root       252     2  0 May05 ?        00:00:00 [flush-8:0]' What process spawns this process? Where is described the function of this process?
[06:26] <RAOF> I'm pretty sure that no userspace process spawns that process, and it's a kernel thread to handle the write-queue to one of your block devices.
[06:31] <CytotoxicTCell> What IO scheduler does ubuntu 10.4 use?
[06:38] <bullgard4> RAOF As the [] clearly states, it is a kernel process.
[06:39] <bullgard4> RAOF: Where can I find additional information about it?
[06:40] <RAOF> Didn't we have this coversation before?
[06:40] <RAOF> Ah, yes “look for a definition of stuct file_operations in the filesystem implementation, it should have a line like '.flush = ext4_flush'”
[06:58] <bullgard4> RAOF: I havew found a generic definition of the structure in  /usr/src/linux-source-2.6.32/Documentation/filesystems/vfs.txt but not yet the specific definition in the ext3 filesystem implementation. 
[06:59] <RAOF> grep ext3_flush **/*.c might help. :)
[07:21] <psurbhi> good morning!
[07:22] <jk-> hey psurbhi
[07:23] <jk-> psurbhi: why the change from csurbhi?
[07:33] <psurbhi> jk, no such reason.. just made it aligned to my name :)
[07:33]  * psurbhi compiles the patch for 543617
[07:50] <psurbhi> jk, when are you traveling to brussels?
[07:52] <jk-> psurbhi: 2 days time
[07:56] <psurbhi> ok
[08:08]  * apw waves to jk- 
[08:08] <apw> o/ all
[08:13] <jk-> heya apw
[08:14] <apw> long time no see ... hows DT going
[08:14] <jk-> yeah, good! looking forward to some intresting discussions at UDS :)
[08:15] <jk-> still getting my head around how to best handle the crazy ARM clocks though
[08:15] <jk-> i think the clock configuration on imx51 is turing-complete
[08:16] <apw> heh now that is an interesting thought
[08:16] <jk-> yeah, maybe I can calculate a fibonacci sequence using only the clocks
[08:16] <apw> sounds like a nightmare
[08:17] <jk-> naw, it's ok. just trying to figure out a way to represent it that isn't going to bite us later
[08:17] <apw> bjf, you 'there' already ?
[08:17] <bjf> apw, yup
[08:17] <apw> bjf they run out of beer yet?
[08:18] <bjf> apw, the first run at them was tried last not, but they held out
[08:18] <bjf> s/not/night/
[08:18] <jk-> have the breweries been informed that the kernel team is coming to town?
[08:19] <apw> bjf, i have low expectations sadly
[08:19] <apw> jk-, we always try and tell them to order 3x, they always laugh, until the end of the first night
[08:19] <bjf> apw, low for what?
[08:19] <jk-> aha
[08:19] <bjf> ah
[08:19] <apw> bjf, the beer holding out
[08:20] <bjf> lots of good hiking/walking trails in the forest
[08:20] <bjf> the showers are _AWSOME_
[08:20] <bjf> need to figure out the laundry setup
[08:21] <persia> Anyone happen to have a link to best-practice for reporting fail-to-boot bugs?  Someone in #ubuntu-bugs wants to report one, and I'm not sure `apport-bug linux` is the right answer.
[08:24] <persia> Oh well, normal bug then :)
[08:24] <cooloney> apw: i am trying to cross build ti-omap kernel, but failed 
[08:24] <cooloney> pls help me take a look here
[08:24] <cooloney> http://pastebin.ubuntu.com/428760/
[08:25] <cooloney> even with skipabi=true and skipmodule=true
[08:25] <apw> yep you have to have validly formed abi/module info even with skips enabled
[08:26] <apw> skip just says "if the result is bad, ignore it" it doesn't mean "don't do the checks"
[08:26] <cooloney> apw: right, i know that.
[08:27] <cooloney> apw: i just fresh git clone the tree
[08:27] <apw> which one?
[08:27] <cooloney> and checkout ti-omap branch
[08:27] <cooloney> and cross build it 
[08:27] <cooloney> then failed like this
[08:27] <cooloney> looks like the build scripts corrupt
[08:27] <apw> ok ... i'll try it here
[08:27] <cooloney> apw: ok, thanks.
[08:28] <apw> cooloney, looks more like the abi info is corrupt to my eye, but let me try here
[08:30] <cooloney> apw: thanks, dude
[08:32] <apw> cooloney, building now, will be about 10 mins
[08:32] <apw> cooloney, what is the sha1 of your tip
[08:32] <apw> or the base you are using which ever
[08:32] <cooloney> apw: cool, your build machine is powerful enough
[08:32] <apw> arm cross builds are about 2x the speed of native ones, go figure
[08:33] <cooloney> apw: oh, you mean the ti-omap branch of main?
[08:33] <cooloney> apw: it is 841b9542344b64c7d7607404ca9fd54a8ce72a74
[08:33] <apw> yeah just wanted to know where you are working from, to confirm its the same
[08:34] <cooloney> apw: the default thing, i did not change anything before cross building
[08:34] <cking> morning
[08:34] <psurbhi> cking, apw, morning :)
[08:34] <cooloney> cking: morning, 
[08:43] <apw> cooloney, ok this happens here for me as well, will investigate
[08:47] <cooloney> apw: you are the man
[08:47] <cooloney> thanks
[08:49] <apw> np ...
[09:14] <apw> cooloney, ok i think i have this sorted out ... give me a couple to confirm
[09:16] <apw> bjf, whats the network like there?  you able to work on it?
[09:17]  * psurbhi breaks
[09:23] <cking> apw, asking bjf if the network works is a little premature - once we have a gazallion developers on the network it's gonna suck
[09:24] <apw> cking, indeed was more interested as he is there for 3 days before 
[09:27] <bjf> apw, i'm in the conference area now, on the wireless and it's working nicely right now
[09:28]  * apw wonders where smb is
[09:28] <bjf> apw, don't know what it's going to be like when the riff-raff show up :-)
[09:28] <apw> bjf, we'll kill it in the face in 10s of arriving i am sure
[09:29] <bjf> apw, there is a design team sprint happening right now and somehands going one
[09:29] <apw> bjf, yeah so not so many people i guess
[09:29] <bjf> apw, nope, not yet
[09:30] <apw> smb, yo ... you got anything pending for the ti-omap lucid branch?  i've just found a packaging bug in it thats stopping all builds and i want to slam it in
[09:30] <bjf> apw, we've taken over the hotel wireless as usuall, it's our folks managing it
[09:30] <apw> thats something at least
[09:30] <smb> apw, Nope nothing for that as far as i can remember
[09:30] <bjf> apw, kind of have the run of the place to myself, very nice actually
[09:30] <apw> ok, you ok with me pushing it?  right now its not possible to build ti-omap at all
[09:31] <apw> bjf, must be very odd
[09:31] <smb> apw, sure go for it
[09:31] <bjf> apw, it is a bit
[09:31] <cooloney> smb: yeah, that also affects me as apw said
[09:31] <apw> which floor shall i work from today
[09:31] <bjf> cking, you mentioned someplace for me to do my conference writeup?
[09:32] <smb> cooloney, you also running ti-omap stuff?
[09:32] <bjf> apw, they have a very nice coffee bar room with lots of 'snacks' 
[09:32] <cooloney> bjf: https://wiki.canonical.com/KernelTeam/Conferences/
[09:32] <apw> bjf, sounds like a a disaster
[09:32] <cooloney> smb: right, i try to cross build it today
[09:32] <cooloney> and met such issue which apw should slove it now
[09:32] <bjf> cooloney, thanks
[09:33] <apw> smb, cooloney, ok pushed ti-omap ... cooloney could you rebase on that and test
[09:33] <cooloney> apw: no problem, 
[09:33] <apw> if it builds ok for you as well then i'll call it good and send out the patches
[09:34] <cooloney> apw: synced and building now on emerald
[09:35] <smb> apw, Any other known disasters. I partially try to recover from upgrading to lucid on my main netbook
[09:35] <apw> smb, na thats the only one i know about at least
[09:36]  * smb wants his high resolution back on the external lcd
[09:36] <apw> smb, so very picky
[09:36] <cooloney> apw: so i am just wandering what's the CONFIG_UNUSED_SYMBOLS? 
[09:37] <apw> it makes EXPORT_UNSED_SYMBOLS produce things which are meaningful in the ABI
[09:37] <cooloney> apw: it will cause the abi checking fail, interesting..
[09:37] <smb> apw, I am not even starting about thunderbird loosing all of lightning in that process. 'cause I know you don't care. :-P
[09:37] <apw> only cause the abi-checker is itself broken
[09:46]  * psurbhi tests the patch for lp543617
[09:55] <cooloney> apw and smb, the new CONFIG_UNUSED_SYMBOLS patch fixed this building issue of ti-omap.
[09:55] <cooloney> thanks
[09:56] <psurbhi> apw, what do you mention in a patch taken from kernel bugzilla? (which is not yet upstream)
[09:56] <psurbhi> as in, instead of commit <sha-id> upstream
[09:56] <apw> OriginalLocation: perhaps
[09:56] <psurbhi> ok
[09:56] <psurbhi> thanks
[09:58] <smb> psurbhi, In case it is in linux-next you could take that sha and linux-next
[09:58] <smb> psurbhi, Or i would say cherry-picked from <url to bugzilla>
[10:01] <psurbhi> smb, thanks :)
[10:15] <psurbhi> smb, apw, there seems to be a second patch which has come in just now from Jens Axboe
[10:15] <psurbhi> https://bugzilla.kernel.org/show_bug.cgi?id=15906
[10:15] <psurbhi> I tested Dmitrys patch and that works fine
[10:16] <ubot3> psurbhi: Error: Could not parse XML returned by bugzilla.kernel.org: The connect operation timed out
[10:16] <apw> psurbhi, interesting
[10:16] <smb> Hm someone mentioned another patch yesterday
[10:16] <psurbhi> smb, its just come in today
[10:16] <psurbhi> infact i could not see this posting till morning
[10:17] <smb> When kees was asking yesterday, someone pointed to a mail thread
[10:17]  * apw still can't see it cause its taking so long
[10:17] <smb> http://www.spinics.net/lists/linux-ext4/msg18780.html
[10:17] <psurbhi> apw, yeah.. its taking a long while..to open for me too
[10:18] <psurbhi> smb, ok.. it was posted on kernel bugzilla today.. anyway.. i think we will wait for a while?
[10:18] <smb> I would suggest you make a kernel with both of them and give it to kees for testing
[10:18] <psurbhi> and meanwhile also test this new patch
[10:18] <apw> psurbhi, well i guess if the patch looks reasonable we want to test both together, and get them to kees
[10:18] <apw> for testing
[10:18] <psurbhi> smb, apw ok
[10:19] <psurbhi> where do i keep the kernels? i have one on emerald now
[10:19] <apw> psurbhi, people.canonical.com ?
[10:19] <psurbhi> apw, ok
[10:20] <apw> psurbhi, i normally make like lpNNNN-lucid in mine and put them there
[10:24] <psurbhi> ok
[10:27] <psurbhi> Dmitrys patch is a very small change.. and is tested ..whereas the patch by Jen Axboe introduces some new status "WB_SYNC_NONE"  to fix this one..and its untested by anyone so far
[10:27] <psurbhi> apw, smp ^^
[10:27] <apw> psurbhi, so is jens' patch a replace ment for dmitry's ?
[10:28] <psurbhi> apw, yes, his version fixes the bug in the proper way.. whereas dmitrys patch is sort of a hack
[10:28] <apw> damn, so it depends if jens is intending on CC: stable his
[10:29] <psurbhi> how about taking dmitrys patch as of now and then later reverting that to jens one.. once it goes to stable?
[10:29] <apw> i guess we could consider taking Dmitries with the revert of the hack we have and then move to jens' if we get it via stable
[10:29] <psurbhi> ok :)
[10:29]  * cking wonders if electioneering allowed on voting day
[10:29] <psurbhi> so do you think, i should send the email out on u-k mailing list?
[10:30] <apw> cking, what does that mean?
[10:30] <smb> psurbhi, apw Hm, yeah. We want to move as quickly to a solution that does not regress other cases and solves the long umount
[10:30] <smb> and then later probably revert that in favour of Jens' patch when it is in stable
[10:30] <psurbhi> smb, yep...so do i send out the email with dmitrys patch?
[10:30] <psurbhi> ok..cool.. so i will do it right away..
[10:30] <apw> seems like a plan then ... so yes get it out on the list
[10:31]  * smb hopefully remembers untils then
[10:31] <cking> apw, just got a phone call from Labour giving me some push to vote for them. That's not allowed is it?
[10:31] <psurbhi> so, then i will put a note in the patch email saying we wait for Jens patch and later revert to it
[10:31] <apw> cking, it seems rather unethical to me, but i suspect they are just calling all not yet voted people to encourage them which is techinically allowed
[10:31] <smb> cking, "Thanks you for calling. I would have voted for you, but now that you call..."
[10:31] <apw> psurbhi, yeah please do put a note
[10:32] <psurbhi> heh..
[10:32] <cking> smb, my response exactly
[10:33] <smb> psurbhi, And clearly make it a SAUCE patch
[10:45] <bjf> cking, you have it soo easy, you can't believe all the calls we get when it's election "season" here, and it goes on and on and on and ...
[10:45] <bjf> cking, what's nice in oregon is that we can vote by mail, and once you vote, it's marked in the roles and they stop calling you :-)
[10:46] <bjf> cking, the rule is "vote early, vote often"
[10:46] <cking> bjf, 6 weeks is enough for me - didn't see one doorstep visit at all and got just 2 phone calls
[10:46] <bjf> cking, can't remember how many people i had at the door
[10:47] <bjf> cking, what's funny/annoying is i'm registered democrat, the wife is registered republican, we get it from both
[10:48] <bjf> cking, she doesn't vote republican, just too lazy to change her registration
[10:50] <cking> bjf, I think because I did a postal vote I got zero hassle from the parties this week
[11:01] <cnd_mini> apw: the CONFIG_UNUSED_SYMBOLS on mvl-dove isn't set, does it need to be, including any trees based on it?
[11:02] <apw> cnd, it should be, but it clearly doesn't break anything so you don't need to worry
[11:02] <apw> it will get fixed naturally as we move forward
[11:02] <cnd> ok, thanks
[11:02] <apw> cnd is it not very early where you are?
[11:03] <cnd> apw: I'm transitioning to brussels time
[11:03] <cnd> so it's not as terrible on the first day or so
[11:03] <apw> are you mad :)
[11:03] <cnd> ?
[11:03] <apw> that sounds a bit mad, waking up early voluntarily
[11:04] <cnd> that, and my wife is in ob/gyn rotation
[11:04] <cnd> meaning she gets up at 4:15 am
[11:04] <apw> nnng
[11:04] <cnd> she just put in a 30 hr day non stop yesterday...
[11:04] <apw> so safe for her patients
[11:04] <cnd> got up at 4:15 on tuesday, came home at 8 am on wed
[11:05] <apw> mental, they do that here, one does not want to be in a hospital i cannot do a thing that tired
[11:05] <cnd> she's just a med student so she doesn't really DO too much yet
[11:05] <cnd> I don't know if attendings and residents work off the same schedule
[11:05] <cnd> but they may
[11:06] <apw> heh i bet she is giving drugs and the like ... its all stupid
[11:06] <cking> apw, it's only people's lives at stake. apw, you need to be alert so you don't break millions of PCs
[11:06] <cnd> nah, doesn't have that power yet
[11:06] <cnd> is that what caused the EC breakage?
[11:06] <cnd> apw, do you need more caffeine?
[11:07] <cnd> :)
[11:07] <apw> i always need more of that
[11:07]  * apw got up at 7 to vote, and i am already useless ... 
[11:07] <cnd> apw, when do you normally get up?
[11:07] <cking> keenie
[11:07] <apw> lass was going and made me go too
[11:08] <apw> more like 8
[11:08] <cnd> my stomach gets all discombobulated when I get up any more than an hour earlier than usual
[11:08] <cnd> so I'm hoping to head that off by doing a slower transition of sorts
[11:09] <cnd> this is really just a test to see how well this works
[11:09] <cking> apparently beer softens the blow 
[11:09] <apw> cnd, sounds bad ... though getting up at 4 for a week before you get there sounds bad too
[11:09] <cnd> I just remember going to a conference in greece a few years ago, and I was dead tired all the time
[11:10] <apw> yeah throw in beer till any sickness can be attributed to that
[11:10] <cnd> apw, I've actually been inching my way
[11:10] <apw> yeah figured you might
[11:10] <cnd> an hour earlier to bed and to rise each day
[11:10] <apw> still mad
[11:11] <cking> cnd, you will get used to it after a few years of travel around the globe
[11:11] <cnd> perhaps
[11:11] <cnd> I'm starting to become very jealous of sabdfl's private jet :)
[11:12] <cnd> and I haven't even done any international travel yet!
[11:13] <apw> even his jet doesn't get rid of the timezone change
[11:14] <cnd> yeah, but at least he isn't packed like a sardine
[11:14] <cnd> maybe he can get some sleep?
[11:14] <cnd> I never am able to
[11:16] <cnd> argh, marvell hal driver build infrastructure is utter crap
[11:16] <cnd> it breaks on anything higher than -j1
[11:16] <cnd> anyone know of a way to force one specific subdir of the kernel to be -j1?
[11:17] <cnd> they do this stupid thing where they have a dummy.o target at the front of all the real targets, and dummy.o depends on their rule to make all the makefiles for the rest of the targets
[11:18] <cnd> which breaks horrendously as soon as you do -j2 and it tries to compile the first real target before it has a Makefile
[11:21] <apw> cnd, hrm ... t
[11:21] <apw> there must be a way
[11:21] <baptistemm> Hello & good morning
[11:22] <apw> hi
[11:22] <baptistemm> hi manjo
[11:22] <baptistemm> manjo, good bet for bug 416487
[11:22] <cnd> apw, what I tried is generating the Makefiles myself, and then committing that result
[11:22] <ubot3> Malone bug 416487 in bluez "Bluetooth Doesnt Work - Eee PC 1005HA-P" [Undecided,Incomplete] https://launchpad.net/bugs/416487
[11:22] <apw> cking, hey checkout google.co.uk graphic
[11:22] <cnd> of course the generated makefiles use absolute directories in their -I statements...
[11:22] <apw> gah
[11:22] <cnd> though it may just be one Makefile
[11:23] <cnd> so I might be able to patch that to $(src)
[11:23] <cking> apw, nice google image of No.10
[11:24] <apw> cnd can't you just fix the makefile so that all of the files depend on dummy.o's depenacies
[11:25] <cnd> apw: seems logical, and I've tried to think of ways, but I can't figure it out
[11:25] <cnd> apw: it's like: obj-y := dummy.o dir1/ dir2/ dir3/ dummy_end.o
[11:25] <apw> cnd, how come our mvl-dove trees do not have this issue
[11:25] <cnd> where dummy_end.o goes and deletes all the Makefiles!
[11:26] <cnd> apw, perhaps they don't build these drivers?
[11:26] <apw> they definatly make new makefiles and delete them
[11:26] <cnd> I'm not sure
[11:26] <apw> bjf, was it you who did mvl-dove originally ... does this ring a bell
[11:26] <bjf> apw, just catching up with the discussion
[11:27] <apw> cnd, are you starting from mvl-dove or making your own tree ?
[11:27] <cnd> apw, starting from mvl-dove, and applying some patches on top
[11:28] <apw> i ask because mvl-dove is configured differently as it cannot build 'out of tree'
[11:28] <bjf> apw, cnd, yes i remember that there were some big issues with mvl-dove builds
[11:28] <apw> ok so you should have that
[11:28] <bjf> apw, cnd, one of the things is it wouldn't build out-of-tree
[11:28] <cnd> in fact, it's all mergeable into mvl-dove except that we need to build uImages instead of zImages
[11:28] <cnd> bjf: well, I'm trying to build in-tree
[11:28] <cking> bjf, that's a tad unpleasant
[11:28] <apw> cnd, well thats normal, all arm use those
[11:28] <bjf> apw, cnd, that's why you see at the beginning of the build, we rsync the code over to the build directory
[11:29] <apw> bjf yep, if cnd is based of mvl-dove that should be turned on anyhow
[11:29] <cnd> apw, only if they use uboot
[11:29] <cnd> does anyone use redboot?
[11:29] <cnd> if not, then we should just switch over to making uImages
[11:29] <apw> i mean we generate the uImages as they are flashed as i recall ...
[11:29] <bjf> cnd, it sounds like you started with their tree and are bringing it back into ours
[11:30] <cnd> cause our current build process doesn't allow building different outputs for different flavours
[11:30] <bjf> cnd, how about starting with our tree and applying their changes ontop of ours
[11:30] <apw> ogra, am i right in thinking the kernel-flash extracts the uImage and we fake install zImage for arm generally ?
[11:30] <persia> Lots of folks use redboot
[11:30] <persia> apw: Yes, kernel-flash should mask the platform-specific kernel installation hackery when it doesn't boot from /boot
[11:31] <cnd> bjf, that's what I'm doing, starting with mvl-dove and applying patches
[11:31] <bjf> cnd, switching from uImages to zImages or vice versa is easy
[11:31] <apw> cnd ... so we probabally should do the same for this
[11:31] <ogra> apw, not really, zImage is the source for generating the uImage
[11:31] <ogra> apw, so its not really a fake 
[11:31] <cnd> bjf, yeah, but integration into the oem builds is what concerns me
[11:31] <bjf> cnd, i don't know what that means
[11:31] <cnd> bjf, well I don't really know all it entails either yet :)
[11:31] <apw> ogra, yeah i more meant we still just generate zImage for arm and put that in /boot, and do the uImage step at 'update-<bootloader>' time instread
[11:32] <ogra> persia, apw, and its flash-kernel :)
[11:32] <ogra> apw, its a kernel postinst thing yes
[11:32] <apw> cnd, ^^ make sense?
[11:32] <bjf> apw, no, we were generating uImages at one point for uboot targets
[11:32] <ogra> controlled by /etc/kernel-img.conf
[11:32] <cnd> apw: yes, for the uImage part
[11:32] <ogra> as well as by update-initramfs
[11:32] <cnd> bjf: http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=commit;h=844a81b8f6332ba7ce701ca7ae79d784d9ef4ab1
[11:33]  * persia consistently calls that the wrong thing except when prefaced by apt-get source :(
[11:33] <apw> bjf, yeah but we have switched to consistenty using the same
[11:33] <bjf> apw, ah
[11:33] <ogra> cnd, where does your kernel live on your device ? 
[11:33] <apw> cnd seems reasonable
[11:34] <ogra> got flash or in a partition
[11:34] <cnd> ogra: we're still just in the board bringup phase, but right now I've been putting it in /boot/uImage
[11:34] <cnd> and made a simple uboot boot script to load it using ext2load
[11:34] <ogra> cnd, is your u-boot capable of reading ext2/3 ?
[11:34] <ogra> ah
[11:34] <cnd> most of this is going to change
[11:34] <cnd> this is just for board bringup really
[11:35] <ogra> yeah, that should work fine, the dove way of doing things should work
[11:35] <ogra> for NAND take a look at the omap version :)
[11:35] <cnd> we just got lucid up on it two days ago
[11:35] <ogra> the important bit is the flash-kernel-installer.postinst 
[11:35] <ogra> that does the initial system setup from ubiquity/d-i
[11:36] <cnd> apw: bjf: this is what I didn't catch when I statically generated the Makefiles: http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=blob;f=arch/arm/plat-orion/mv_hal_drivers/mv_hal/pmu/Makefile;h=60933f5425f1487d90dad88264d79fb9919c1d90;hb=844a81b8f6332ba7ce701ca7ae79d784d9ef4ab1
[11:36] <cnd> ogra: yeah, I don't know myself how the live image build process works yet
[11:36] <cnd> I've been putting that off
[11:37] <cnd> since I haven't got a kernel building outside my home dir yet :)
[11:37] <ogra> cnd, bring the device to UDS we can take a look together
[11:37] <bjf> cnd, i remember them reaching all over their tree with relative paths to get to objs
[11:37] <ogra> should be quick to get it going
[11:37] <ogra> and i can add all bits to flash-kernel then, i'm just merging it anyway :)
[11:37] <cnd> ogra: I don't know we'll have the time though, cking was suggesting to leave it at home...
[11:38] <ogra> well, there are the evenings ... 
[11:38] <ogra> we just shouldnt spill beer into it ;)
[11:38] <cnd> heh
[11:38] <cnd> I'll think about it
[11:38] <cnd> honestly, I'm not sure whether it's strictly my area anyways
[11:38] <apw> a good oppotunity to get ogra to fix it for you
[11:38] <cnd> I'm the kernel hwe guy for the project
[11:38] <cnd> there are other people working on the rest of course
[11:39] <ogra> sure, as you like :)
[11:40]  * cking hates bringing hwe work to UDS as it eats into valuable UDS time
[11:41] <cnd> that and it's a sizeable hunk of metal I don't want to deal with unless I really must
[11:41] <cking> ..and the parts are limited too
[11:50] <fqh> helli, I run command "hdparm -B 128 /dev/sda", but after a while, it restores to 254 automatically. Anyone meet this? 
[12:25] <apw> fqh, which release you on ?  that sounds like something laptop-tools might do
[12:26] <apw> lag, yo
[12:27] <apw> smb, cking-afk  .... meet lag (Lee)
[12:27] <smb> hey lag 
[12:27] <apw> he seems to have settled on a nick at last, and one  i can spell finally too
[12:28] <smb> apw, And one you can even live. :-P
[12:28] <apw> heh
[12:35] <apw> Rejected:
[12:35] <apw> Cannot build any of the architectures requested: any
[12:35] <apw> smb, does ^^ mean anything to you in a PPA upload response ?
[12:36] <smb> apw, Hmm, not immediatly
[12:36] <apw> sounds like something a bit mad to me
[12:36] <apw> Distribution: maverick
[12:36] <apw> have i spelt maverick right?
[12:37] <smb> apw, I thought so. Looked better than me doing Maverik
[12:38] <smb> apw, Can I look at the dsc or build log?
[12:38] <apw> smb, the reject email is in your inbox as it was the maverick pre-proposed which failed
[12:39] <apw> linux_2.6.34-1.6~pre201005061100_source.changes rejected
[12:41] <smb> apw, Does not look any other than all of the previous ones to me...
[12:41] <cking> lag, hiya!
[12:42] <apw> yeah i suspect its right, and i suspect we may not yet have chroots or something ... but someone needs to tell me :)
[12:42] <cking-afk> back in 10
[12:42] <smb> apw, Yeah maybe there is no buildd for maverick that volunteers for building
[12:42] <apw> yeah something like that i suspect
[12:45] <lag> apw, smb, eking: Hello =:-)
[12:45] <apw> eeeeeking :)
[12:45] <apw> its a 'c'
[12:45] <smb> apw, The e-commerce version of cking. :-)
[12:46] <lag> cking: Sorry, and hello
[12:46] <lag> smb: We've met haven't we
[12:46] <lag> cking: We haven't met yet
[12:46] <apw> i likes the idea of him squeaking like that
[12:47] <apw> lag, spot on
[12:47] <smb> lag, Yeah, /me was the quiet one at the end of the table
[12:48] <apw> suffering from .en overload :)
[12:49] <smb> More from music overload I think
[12:49] <lag> smb: Yes, I remember you
[12:50] <lag> apw: Who is 'the technical one' you wanted me to meet?
[12:50] <lag> Is that cking?
[12:50] <apw> yeah cking is the detail guy :)
[12:53] <cking> me? detailed? nah
[12:53] <apw> yeah right
[12:53]  * apw notes he is 2 foot tall
[12:53] <cking> yeah yeah yeah
[12:56]  * cking is a troll that likes shiny hardware
[13:02] <apw> cnd, about ?  mumble test ?
[13:02] <cnd> apw, one sec
[13:04] <fqh> apw, I am running ubuntu-10.04. 
[13:07]  * lag is off to make the most of his final weekdays off for 3.5 months!
[13:07] <fqh> apw, my usb-disk /dev/sdb  can keep the setting, but the disk inside the laptop can't.
[13:07] <lag> cking: Nice to meet you
[13:09] <cking> lag, hope to catch up with you face-to-face sometime :-)
[13:15] <apw> fqh, the internal one is the one on we might expect things to manage
[13:16] <apw> if its 10.04 its likely pm-utils
[13:17] <lag> cking: I think apw is planning a meet up-town in the next upcoming weeks. It would be good to meet then?
[13:24] <fqh> apw, I tried pm-powersave, but "hdparm -B /dev/sda" tell me that pm-powersave did not change the "APM_level".
[13:29] <cking> lag, I'm up for it sometime after UDS :-)
[13:41] <ogra> apw, your ports mail doesnt refer to omap and friends, does it ? 
[13:42] <apw> ogra, nope, literally what used to be linux-ports
[13:42] <ogra> thats what i thought
[13:42] <ogra> just wanted to make sure 
[13:42] <apw> omap et al are already in there and with stable
[13:42] <apw> ports is an anomoly as it used to be separate and now half isn't
[13:53] <cnd> from lwn:
[13:53] <cnd> The question about regularly used distributions led to some interesting results, with Ubuntu (54%) and Debian (44%) far ahead of any of the rest. The next tier was led by Fedora (24%), followed by Red Hat Enterprise Linux (21%), other OS (20%), CentOS (19%), and other Linux (15%). All of the rest came in at less than 10%: Gentoo, openSUSE, SUSE Linux Enterprise Server, Mandriva, and Oracle Unbreakable Linux (with 13 responde
[13:53] <cnd> nts) in that order.
[13:53] <cnd> woot!
[13:56] <ogra> wow, the low suse value is intresting
[14:11] <JFo> pgraner-afk, or apw how should I respond now that 'the man' has commented on bug 575518
[14:11] <ubot3> Malone bug 575518 in linux "linux kernel contains GPL violations" [Undecided,Incomplete] https://launchpad.net/bugs/575518
[14:12] <apw> JFo, lets look into it at UDS
[14:12] <JFo> apw, ok
[14:13] <apw> i think we are doing mostly all we can do in that vein as it is
[14:14] <JFo> I thought so too, but it sounds like he wants more maybe
[14:14] <JFo> at any rate, shelved till UDS
[14:16] <mjg59> JFo: The list of files he provides *all* have source
[14:16] <mjg59> Every single one of them
[14:16] <mjg59> Close it as notabug
[14:17] <mjg59> drivers/char/ser_a2232fw.ax is the source for drivers/char/ser_a2232fw.h, for instance
[14:17] <apw> yeah from discussions we had the other day i suspect most of his noise is noise
[14:18] <apw> we should do a formal review like mjg59 is showing and confirm/deny his allegations etc before enflaming any further
[14:18] <mjg59> Now, admittedly, there isn't always a toolchain included with the source
[14:18] <apw> though i think we will close it not a bug in the end, i think its best to have the the full list of limitations
[14:18] <mjg59> But gcc isn't in the kernel source either
[14:19] <apw> indeed so
[14:19] <apw> and as you pointed out yesterday they are being ripped out over time, and will gone either way
[14:19] <mjg59> And how can anyone claim that drivers/scsi/sym53c8xx_2/sym_fw1. is a binary?
[14:19] <apw> by reading and believeing the militant fringe produces mostly
[14:20] <mjg59> Anyway. If you look at his list, the second one each time is the source for the previous file
[14:21] <mjg59> Some searching actually indicates that the linux-libre deblob tool leaves those files in because they have source, so it's just factually incorrect rather than any kind of legitimate complaint
[14:21] <mjg59> I suspect that those ones will stay in the kernel, given that they're GPLed and have source and there's no reason to move them out
[14:21] <apw> mjg59, typical ... and now we have to tip-toe round to get it closed ... ahh well
[14:21] <apw> mjg59, yeah seems so
[14:22] <mjg59> But Launchpad seems to refuse to send me my password or let me create a new account for reasons I haven't determined
[14:22] <mjg59> Let me see if I can rectify that
[14:22] <apw> mjg59, hrm ... should bitch at them on #launchpad
[14:23] <mjg59> Ah, hang on, there's the address I used
[14:38] <erUSUL> it is true performance is default governor in lucid ?
[14:38] <erUSUL> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
[14:38]  * erUSUL did not upgrade yet but someone in #ubuntu claims it
[14:39] <cnd> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
[14:42] <ogra> erUSUL, aLeSD just asked the same in #ubuntu-devel and got an answer
[14:43] <erUSUL> that being? nvm will find the logs ...
[15:02] <greg-g> test
[15:02] <ogra> fail
[15:02] <greg-g> :(
[15:04] <greg-g> a bug reporter is trying to ask a question in this channel, but he is getting a "cannot send to channel" response. he is communicating just fine in -bugs.
[15:04] <ogra> still ? 
[15:04] <ogra> that was changed recently
[15:05] <ogra> the channel auto-banned unregged people somehow 
[15:05] <greg-g> yuck
[15:05] <ogra> but its +t since a few days
[15:05] <apw> greg-g, you used to have to be registered, i thought that was fixed when this came under the IRC council
[15:05] <cnd> apw: smb: http://www.jrin.net/2010_02_06/how-to-dismantle-and-upgrade-dell-mini-1012
[15:06] <greg-g> apw: thanks.
[15:06] <ogra> apw, i'd say it is ... i havent seen any issues
[15:06] <greg-g> cshong: see above discussion which you can probably read but not respond to :)
[15:08] <ogra> cshong, try to leave the channel and re-join it theoretically there is no reason you cant speak
[15:09] <ogra> better ? 
[15:10] <greg-g> ogra: he said the same thing happens (he's in -bugs also)
[15:10] <ogra> i know :)
[15:11] <greg-g> ;)
[15:11]  * ogra wonders why there is no ChanServ in here 
[15:11] <JFo> apw, ogra, chase had issues the other day when his nick was cnd-mini
[15:11] <persia> ogra: It's built-in: it is a managed channel
[15:11] <JFo> as that nick is not registered
[15:12] <JFo> but when he changed it back to cnd, it was fine
[15:12] <ogra> JFo, yes, but that was supposed to be fixed since the -n was dropped
[15:12] <persia> Right.  Looking at channel modes, it needs to be a registered nick here.
[15:12] <JFo> looks like it is still an issue
[15:12] <apw> then its still not fixed and we need to figure out quite how it is changed
[15:12] <Pici> See /mode +q
[15:12] <apw> persia, how can you tell
[15:12] <ogra> i had similar probs when my nick changed to ogra_ during reconnects
[15:12] <Pici> /mode -q $~a
[15:12] <ogra> but that was gone with the change
[15:12] <persia> apw: /cs info #ubuntu-kernel and /cs access #ubuntu-kernel list are the commands I usually use.  You ought have powers to fix it.
[15:13] <apw> i have powers on this channel, Pici what does that one do ?
[15:14] <Pici> apw: It removes the mute (quiet) on all unregistered users
[15:14]  * ogra looks in awe to apw ...
[15:14] <ogra> so powerful
[15:14] <JFo> apw owns all
[15:14] <apw> i wish :)
[15:14] <apw> Pici, where can i find the docs for that :)
[15:14] <JFo> who's your big bad channel daddy?
[15:14]  * apw slaps JFo 
[15:14] <Pici> apw: http://freenode.net/using_the_network.shtml
[15:14]  * JFo giggles
[15:15] <ogra> heh
[15:16] <persia> apw: Nice work.
[15:16] <apw> Pici, thanks ... hopefully that'll fix it once and for all
[15:16] <MyXelf_> hello
[15:16] <Pici> apw: I hope so too
[15:16] <MyXelf_> i have a framebuffer dude
[15:16] <MyXelf_> could anyone guide me, plz?
[15:17] <sconklin> apw: While not a KMS bug, here's a performance bug that appears to also exist in mainline that we need to figure out https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/555595
[15:17] <ubot3> Malone bug 555595 in linux "Intel graphics performance regression in 2.6.32-19 lucid kernel update (was: Firefox Slows Down Compiz)" [Medium,Triaged] 
[15:17] <apw> sconklin, sounds like loads of fun
[15:18] <cshong> testing
[15:18] <persia> cshong: We see your message.
[15:18] <cshong> ok.
[15:19] <MyXelf_> anyone?
[15:19] <MyXelf_> it is related to the framebuffer modules in lucid lynx
[15:19] <apw> MyXelf_, asking if you can ask questions takes up more space than just asking the question
[15:19] <apw> if someone knows they'll chime in i am sure
[15:19] <MyXelf_> oops, thanks
[15:19] <MyXelf_> here i go
[15:20]  * apw sighs
[15:20] <MyXelf_> i installed a fresh lucid, on the first boot
[15:21] <MyXelf_> i can see the framebuffer using 1280x800 resolution
[15:21] <MyXelf_> the splash and the ttys
[15:21] <MyXelf_> checking with fbset the current driver, it says is using radeondrmfb
[15:22] <MyXelf_> (1280x800 isn't a recognized resolution in hwinfo --framebuffer, neither in grub2 vbeinfo)
[15:22] <MyXelf_> but i'm able to use it
[15:22] <cshong> I reported a bug #575783 about the kernel. Then, someone leave a comment and request me to test whether the bug exist in the latest kernel mainline built. .....
[15:22] <ubot3> Malone bug 575783 in linux "Cannot eject DVD/CD-ROM drive with the hotkey button" [Undecided,New] https://launchpad.net/bugs/575783
[15:22] <MyXelf_> after installing fglrx drivers from repo
[15:22] <JFo> cshong, that was probably me
[15:23] <MyXelf_> i can't use that resolution anymore
[15:23] <MyXelf_> fbset says is using EFI fb
[15:23] <MyXelf_> i have 2 questions
[15:23] <cnd> MyXelf_: is this x86?
[15:23] <MyXelf_> nope
[15:23] <MyXelf_> amd64
[15:23] <cshong> After install the latest mainline built and restart, my computer freeze if I boot into ubuntu with the installed mainline kernel.
[15:24] <MyXelf_> 1- can i force somehow another fb module?
[15:25] <JFo> cshong, did you use the information from https://wiki.ubuntu.com/KernelMainlineBuilds ?
[15:25] <apw> JFo, bear in mind the latest daily may well be a duffer,  cshong which version did you install?
[15:25] <JFo> ah true
[15:26] <MyXelf_> 2- what is preventing fglrx from using the same resolution as the other driver?
[15:26] <cshong> 2.6.34-999
[15:26] <MyXelf_> i tried using uvesafb, to no avail
[15:27] <mjg59> MyXelf_: Sounds like a bug in the fglrx drivers
[15:27] <mjg59> MyXelf_: Which are closed source, so not fixable by Ubuntu developers
[15:27] <apw> yeah i'd say get a bug files on fgrlx i recon
[15:29] <MyXelf_> can i force using another fb module?
[15:29] <apw> MyXelf_, the framebuffer is normally selected by the drivers
[15:30] <MyXelf_> but i was looking that through grub you can force it somehow
[15:31] <MyXelf_> using video:<fbmodule>:mode_option= ...
[15:32] <mjg59> MyXelf_: Only to modes in your vesa bios. 1280x800 isn't.
[15:33] <mjg59> You need to use radeon to set the mode to 1280x800, and that means you can't use fglrx
[15:33] <ogra> you could knock on AMDs door and ask for KMS support :)
[15:34] <MyXelf_> lol
[15:34] <ogra> they are only what, a year or two behind here ? 
[15:34] <cshong> What I downloaded and installed are these 3 files: linux-headers-2.6.34-999-generic_2.6.34-999.201005061008_i386.deb, linux-headers-2.6.34-999_2.6.34-999.201005061008_all.deb, and linux-image-2.6.34-999-generic_2.6.34-999.201005061008_i386.deb.
[15:37] <MyXelf_> i'm a little bit confused with all those terms KMS / DRM / DRI
[15:37] <JFo> KMS-kernel modesetting
[15:38] <ogra> thats what your radeon driver uses to give you the shiny resolution
[15:38]  * ogra sighs about all these grub2 bugs ... 
[15:38] <ogra> why cant people stop editing /etc/default/grub and make typos
[15:39] <JFo> ogra, you want me to answer that? :0
[15:39] <apw> we failed to ship the finger cutter with the CDs ?
[15:39] <ogra> ah, thats it !
[15:39] <JFo> apw,  +1
[15:39] <ogra> Running postinst hook script /usr/sbin/update-grub.
[15:39] <ogra> Generating grub.cfg ...
[15:39] <ogra> insmod: can't read 'png': No such file or directory
[15:39] <ogra> mumble
[15:40] <ogra> at least thats a new one :)
[15:41] <sconklin> MyXelf_: DRM == Direct Rendering Manager, DRI == Direct Rendering Infrastructure
[15:41] <Zobjo_O> hi
[15:41]  * JFo notes those two as I was not 100% sure of them :)
[15:41] <Zobjo_O> hello JFo 
[15:42] <cshong> More information: Before I found the bug, I install Ubuntu 32-bit version by using wubi on Windows 7 Home Premium 64-bit version. I download 32 bit version of Ubuntu because I do need to install it on older 32-bit computer also. To save bandwidth, I didn't download the 64-bit version.
[15:42] <ubot3> cshong: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 2112, column 8
[15:42] <JFo> Zobjo_O, the reason I asked you to post here is so others get the benefit of the conversation :)
[15:42] <JFo> hi Zobjo_O 
[15:43] <Zobjo_O> JFo, i meet the same pb that the bug 572249on my asus eeepc 1201n under ubuntu 10.04 l... it's freeze when i download big files across transmission
[15:43] <ubot3> Malone bug 572249 in linux "Hard freeze on large file transfers with Atheros AR8132 / L1c" [Medium,Triaged] https://launchpad.net/bugs/572249
[15:43] <JFo> ok
[15:43] <cshong> Before I found the bug, I install Ubuntu 32-bit version by using wubi on Windows 7 Home Premium 64-bit version. I download 32 bit version of Ubuntu because I do need to install it on older 32-bit computer also. To save bandwidth, I didn't download the 64-bit version.
[15:43] <ubot3> cshong: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 2112, column 8
[15:43] <sconklin> MyXelf_ JFo: https://wiki.ubuntu.com/X/Architecture
[15:43] <JFo> Zobjo_O, do you have the same hardware profile as the original reporter?
[15:43] <JFo> thx sconklin 
[15:43] <MyXelf_> going to rtfm
[15:44] <cshong> Error in sending message here again. "Could not parse XML returned by Ubuntu: mismatched tag: line 2112, column 8"
[15:44] <Zobjo_O> not exactly but i belive the same network card
[15:46] <Zobjo_O> Atheros AR8132 / L1c
[15:46] <cshong> Before, I install Ubuntu 32-bit version by using Wubi even though my Windows 7 is 64-bit version. Will this relate to the bug I reported?
[15:47] <ubot3> cshong: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 2112, column 8
[15:47] <cshong> Before, I install Ubuntu 32 bit version by using Wubi even though my Windows 7 is 64 bit version. Will this relate to the bug I reported?
[15:50] <cking> cshong, I cannot see why Ubuntu 32 bit won't work on a 64 bit Win 7 system.
[15:50] <ubot3> cking: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 2112, column 8
[15:50] <Zobjo_O> where can i find a new driver for Atheros AR8132 / L1c
[15:50] <MyXelf_> thanks everybody
[15:51] <MyXelf_> i feel enlightened
[15:51] <cshong> Thanks cking
[15:52] <cshong> And, since I cannot boot Ubuntu with the latest kernel mainline built i downloaded (version 2.6.34-999), is this a bug? Do I need to report?
[15:53] <JFo> Zobjo_O, ok
[15:53] <cking> cshong, Wubi just shoves a ubuntu image into a file in the NTFS partition, so it does not matter if you are using 32 or 64 bit Windows, or 32 or 64 bit ubuntu
[15:53] <Zobjo_O> JFo, ??
[15:53]  * ogra wonders what confuses ubot3
[15:53] <ogra> likely Ubuntu 32
[15:53] <ubot3> ogra: Error: Could not parse XML returned by Ubuntu: mismatched tag: line 2112, column 8
[15:53] <ogra> heh
[15:53] <JFo> Zobjo_O, just finished looking at the bug
[15:54] <Zobjo_O> who, you ?
[15:54] <JFo> have you filed a bug for your issue and added it as a duplicate of this one?
[15:54] <JFo> I prefer for all affected to file separate bugs
[15:54] <JFo> yes, me
[15:54] <ogasawara> akgraner: are you gonna do a thurs morning kick off blurb for UOW, or can apw and I just start on the hour
[15:55] <Zobjo_O> JFo, it's the same pb
[15:55] <akgraner> ogasawara, classbot will voice everyone and change the topic
[15:55] <akgraner> then I'll intro you all :-)
[15:55] <ogasawara> akgraner: cool, thanks
[15:56] <akgraner> you're welcome :-)
[15:57] <JFo> Zobjo_O, all the same, I'd still like a bug from you. Just in case you are not solved by the same fix that solves them
[15:57] <JFo> that does happen often
[15:57] <cshong> Tomorrow, I will report another bug about the latest downloaded Kernel mainline. 
[15:57] <JFo> cshong, that may not be necessary
[15:57] <JFo> as we use the mainline for testing only
[15:58] <JFo> it is not a released kernel
[15:58] <cshong> ok.
[15:58] <JFo> thanks for offering though :-)
[15:58] <cshong> Then, I change my mind.
[15:58] <JFo> heh
[15:59] <apw> akgraner, are you handlng the question bot thing for us ?
[15:59] <akgraner> I can or you all can 
[15:59] <akgraner> either way is fine with me
[15:59] <apw> ogasawara, you ever done it?  i don't think i've taled to the bot before perhaps we should let akgraner  ?
[16:00] <ogasawara> apw: yah, the using the bot to field questions is new to me, I'm fine if akgraner wants to help with that
[16:00] <akgraner> we can try it 
[16:00] <akgraner> and adjust fire as necessary :-)
[16:01] <Zobjo_O> JFo, i always write a comments about my pb 
[16:01]  * JFo shifts right 10 degrees
[16:01] <JFo> Zobjo_O, what do you mean?
[16:02] <Zobjo_O> i write a comment about my pb (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/572249)
[16:02] <ubot3> Malone bug 572249 in linux "Hard freeze on large file transfers with Atheros AR8132 / L1c" [Medium,Triaged] 
[16:03] <cshong> As a computer science student, I do understand that fixing a bug may need a lot of time. I can still boot into Ubuntu if I select the original kernel version during booting. And, I can still eject my DVD drive by using "eject" command. So, I will be very patient to wait for my reported bug to be fixed.
[16:03] <JFo> I see, but I prefer you open a new bug for your issue Zobjo_O as it could turn out to be slightly different from the one reported
[16:04] <JFo> cshong, thank you :)
[16:04] <Zobjo_O> JFo, how can i do to open a new bug (i'm sorry but i'm beginer on ubuntu)
[16:06] <cshong> Hope that I have a chance to contribute to Ubuntu's development after I graduate.
[16:07] <JFo> from a terminal (Applications -> Accessories -> Terminal) run the command: apport-bug linux
[16:07] <JFo> Zobjo_O, ^
[16:07] <JFo> cshong, I am sure you will. Good luck in your studies :)
[16:08] <cshong> Thank you.
[16:08] <JFo> Zobjo_O, if you are interested in learning more about the apport command I have given you above, you can look here: http://man.he.net/man1/apport-bug
[16:12] <cshong> For bug #575783, if anyone do feel that I need to report the bug to the main Linux kernel development team ( http://www.kernel.org/ ), or have anything need me to do, just leave a comment on the bug web page. It is night time in my country. I need to sleep now. Good night.
[16:12] <ubot3> Malone bug 575783 in linux "Cannot eject DVD/CD-ROM drive with the hotkey button" [Medium,Triaged] https://launchpad.net/bugs/575783
[16:13] <JFo> good night cshong 
[16:14] <Zobjo_O> JFo, thanks i try to create a new bug
[16:14] <JFo> thank you Zobjo_O 
[16:14] <JFo> just let me know the bug number here and i can take a look
[16:28]  * cking goes to look at his sick server box
[17:09] <JFo> Support Escalation: bug 576064
[17:10] <ubot3> JFo: Error: Could not parse data returned by Malone: list index out of range
[17:10] <JFo> ubot3, you are broken
[17:10] <ubot3> Factoid you are broken not found
[17:10] <JFo> http://bugs.launchpad.net/ubuntu/+bug/576064
[17:11] <JFo> nm, you aren't broken
[17:11] <JFo> apw, ogasawara ^^
[17:12] <cking> horray, disks fsck'd ok, and upgrade worked fine, server no longer sick
[17:19] <manjo> wow
[17:21] <manjo> JFo, how do they expect us to fix it without much info... 
[17:21] <JFo> no idea manjo 
[17:23]  * manjo wonders how much more time does 8.04 have support wise ? 
[17:24] <manjo> I think its a pretty bad idea to go with a product launch on a pretty old lts like 8.04
[17:25] <ogra> manjo, http://www.ubuntu.com/products/ubuntu/release-cycle
[17:25] <ogra> one year
[17:25] <ogra> (for desktops)
[17:26] <manjo> wow lts server support until 2013
[17:26] <manjo> probably in 3yrs we will have 2.7
[17:26] <manjo> s/in/within/
[17:27] <ogra> yeah
[17:28] <manjo> I can understand if they have certified apps on 8.04 otherwise it might be better off to move them to 8.04
[17:29] <smb> manjo, You could say that 8.04 was the latest LTS up to some days ago
[17:29] <manjo> true
[17:30] <manjo> but looks like they are launching a new product based on 8.04+
[17:30] <manjo> planning seems to lack forsight 
[17:38] <manjo> smb, I sent an SRU your way
[17:39] <smb> manjo, I might ignore it for a bit while finishing other stuff, why?
[17:39] <manjo> smb, fix minor rtl8192se driver makefile isse
[17:40] <manjo> minor fix rather 
[17:41] <apw> manjo, more bloody fixes for that driver ... what sort of heap of crap is it?
[17:41] <smb> manjo, Minor rather in the sense of complexity than size
[17:41] <smb> manjo, but ok
[17:41] <smb> Though I would let others have looks on it
[17:41] <manjo> apw, right less complex fix, upgrade of that driver caused a makefile break
[17:42] <cking> one presumes the driver is getting better over time..
[17:44] <apw> cking, we can only hope
[17:45] <manjo> its still not upstream yet... I should talk to my contact in realtek to get them into staging atleast
[17:46] <cking> indeedy
[18:12] <apw> http://tools.ietf.org/html/draft-ietf-tcpm-frto-02
[18:12] <cnd_mini> how can I build a kernel from the git tree exactly (or close to) how it's built in the archive?
[18:13] <cnd> meaning including the d-i packages and everything
[18:13] <cnd> does just running 'fdr clean && debuild' do it?
[18:16] <apw> cnd, you need 1) to build the binary-arch target
[18:16] <apw>  fdr binary-arch
[18:16] <apw> second the chroot needs to declare itself a buildd
[18:16] <apw> touch /CurrentlyBuilding
[18:16] <apw> else you don't get udebs regardless
[18:17] <persia> Is there a reasonable way to have that not depend on /CurrentlyBuilding ?
[18:17] <persia> I'm not convinced that this wouldn't be absent in a future Soyuz.
[18:17] <apw> persia, we'll notice that when the CDs stop building i guess
[18:18] <apw> currently the build does depend on that a lot, and i have plans to pull it all into one place
[18:18] <cking> sigh, another day, another 2 BIOS issues
[18:18] <persia> OK.  I've seen traffic indicating plans to make it go away, so take care :)
[18:18] <apw> so that instead of needing to add a /currently/building one can say like 'fdr fake_buildd=yes binary-arch and it will do the right thing
[18:19] <apw> persia, heh well i am sure they will tell us, as we depend on it in anohter way to know the ddeb mechanism to select ... so they will have to tell us for that
[18:19] <apw> but yes it sucks so i plan to make it be a selection in one place
[18:19] <persia> Can you not depend on the presence/absence of pkg-create-dbgsyms for the ddeb mechanism?
[18:19] <apw> so we can make it sensible later
[18:20] <apw> persia, depends what the presence/absence of that means
[18:21] <persia> That package tends to only be installed in buildd chroots.
[18:21] <JFo> cking, I enjoyed your comment about BIOS QA :)
[18:21] <apw> persia, well the key issue is that the offical way to tell right now is that file
[18:21] <persia> But /CurrentlyBuilding exists because of an awkward hack in some Soyuz wrapper scripts in launchpad, which is more fragile.
[18:21] <apw> so us using it is right, that is very ahrd to change it now, and no way to fake it is mental
[18:21] <persia> apw: For what value of "official"?
[18:22] <apw> persia, for the value of us asking the archive admins how to tell and them saying that was the way
[18:22] <cking> JFo, yea, it's getting me down - these guys are shipping before testing IMHO
[18:22] <JFo> yep
[18:22] <persia> Heh.  OK.  I suspect there's a soyuz-hackers/archive-admin gap, but if that's the advice they're giving, it probably ought be stable for a bit :)
[18:23]  * cking feels sorry for JFo having to see my stream of consciousness pass by him all day in Emails
[18:23] <persia> I'm unsure whether the Soyuz sbuild transition is happening for lucid or LTS+1, so it might be in July/August, or it might be in two years that the change happens.
[18:23] <apw> persia, i care not what the mechanism is, and i also recognise we are in a bad place should they change
[18:24] <JFo> cking, actually i gain a lot from it
[18:24] <persia> OK.  Just wanted to make sure you weren't relying on a discovered hack that wasn't recorded somewhere.  If you've been specifically advised, I'll expect someone is caring for some stability in the interface.
[18:25] <cking> JFo, glad to see you gain from my pain ;-)
[18:25] <JFo> heh
[18:25]  * JFo lives off the tears of others
[18:25] <cking> heh
[18:26] <JFo> <-lunch
[18:26] <apw> persia, no working on their recommendation, but also we are revamping and fixing our crap so its 1) more common, 2) easier to fix, and 3) use that easier to fix to make things like /CB easier to isolate and change
[18:27] <persia> Cool!
[18:30] <ogasawara> cnd: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter#Cross-compiling for ARM (should maybe make sure that is up to date if you're looking to document)
[18:30] <cnd> ogasawara: hrm... how did I miss that...
[18:30] <apw> wiki search sucks ?
[18:30] <cnd> oh, I think I was looking in KernelMaintenance
[18:30] <cnd> I don't think I tried ..Starter
[18:31] <ogasawara> cnd: yah, definitely not the easiest thing to find
[18:31] <cnd> hmmm, that has 'export DEB_BUILD_ARCH=armel'
[18:31] <cnd> but dpkg-architecture -aarmel spits out:
[18:32] <cnd> DEB_BUILD_ARCH=amd64
[18:32] <cnd> which seems more correct...
[18:32] <cnd> or =i386 in the i386 chroot
[18:35]  * manjo needs food 
[18:42] <apw> cnd possibly so
[18:43] <cnd> apw: No module interdependencies found. This probably means your modules.dep is broken.
[18:43] <cnd> If this is intentional, touch /home/cndougla/hedley/ubuntu-lucid/debian/build/no-modules
[18:44] <cnd> apw: https://pastebin.canonical.com/32018/
[19:04] <eagles0513875> hey guys im having some super serious issues with getting kubuntu installed not sure if im in the right place 
[19:05] <apw> #ubuntu is normally the first port of call for any support issues, here is the right place for kernel issues
[19:05] <eagles0513875> when installing with ubiquity withough being in debug mode i get a lot of .so objects and messages saying that the version is older then what is on the cd
[19:05] <eagles0513875> apw: i have been everywhere from kubuntu to ubuntu 
[19:05] <eagles0513875> i guess ill try ask the foundations team like rgreening suggested :( 
[19:06] <apw> if its ubuiquity errros then here is unlikely to be the right place either, if i was gettting ubiquity errors i'd probabally start with foundaations on #ubuntu-devel
[19:06] <eagles0513875> apw: its shared object errors
[19:06] <apw> those are all userspace things :)
[19:07] <eagles0513875> apw: but after a certain point thoguh the installation failes completely
[19:07] <apw> eagles0513875, not sure how that makes it a kernel issue
[19:08] <eagles0513875> apw: ok
[19:08] <apw> seeing the errors like a picture or something may help someone decide
[19:08] <apw> but if its .so errors, sounds like userspace to me
[19:08] <eagles0513875> thanks anyway apw 
[19:08] <eagles0513875> :)
[19:08] <apw> good luck
[19:08] <eagles0513875> thanks i need it 
[19:08] <eagles0513875> im getting super frustrated :( with this
[19:12] <Delemas> I need Ubutu 10.04 LTS w/ support for the 3ware 9750 4i. What is the recommended means of getting that? Run one of the kernel team's 2.6.33 based kernel? Or is there a cleaner solution I'm missing?
[19:21] <manjo> Delemas, on server install ? we do have the 3w-9xxx driver not sure if that works for this card or not 
[19:22] <kamal> apw: hiya - Can you unconfuse me about kernel-ppa-pre-proposed?  My "Dell hang on resume" patch appeared in that PPA (2.6.32-22.33~preNNNN...) so I guessed it would appear in the 2.6.32-22.33 release kernel -- that's out now but it doesn't include many of the patches from 33~pre, including mine.  Do we know when it will be released?
[19:23] <federico1> hi all
[19:23] <federico1> I'm looking for chase douglas
[19:23] <federico1> does he hang around here?
[19:23] <Delemas> manjo, I believe the required driver is 3w-sas which is added in 2.6.33 and available as a source download for 2.6.8 to 2.6.32 from 3ware. I guess what I'm asking is was the 3w-sas driver added as a separate package or in another repository I've missed. 
[19:24] <apw> kamal, right it was planned to be in there, but then there was an emergency day-0 kernel which was released
[19:24] <kamal> federico1: Chase is nick ' cnd ', and yes, he is normally in this channel.
[19:24] <smb> kamal, It might be the pre-proposed was build from the whole stack of updates before we picked urgent ones for immediate release
[19:24] <federico1> kamal: thanks!
[19:24] <federico1> cnd: ping :)
[19:24] <cnd> federico1: what's up?
[19:25] <apw> assuming smb doesn't have to do a security in the middle it will be in the next upload
[19:25] <federico1> cnd: I'm looking at bgo#610482 and your patch there - pretty interesting!
[19:25] <apw> though that is quite likely ...
[19:25] <federico1> cnd: so we have a few bugs, I think:
[19:25] <smb> apw, kamal I would not assume that not
[19:25] <manjo> Delemas, not sure we carry that driver ... 
[19:25] <federico1> 1. g-s-d gets more than 1 input event for XF86Display
[19:25] <federico1> 2. the timestamps in those events are reversed
[19:25] <kamal> apw, smb: ok great -- I was somewhat less confused than I thought -- thanks guys.  :-)
[19:26] <cnd> federico1: is that bug # on fdo?
[19:26] <federico1> cnd: bugzilla.gnome.org
[19:26] <federico1> cnd: ubuntu bug 484186
[19:26] <ubot3> federico1: Error: Could not parse XML returned by Ubuntu: HTTP Error 404: Not Found
[19:26] <manjo> apw, wonder why we don't carry the 3w-sas driver, seem to be added to mainline in October 09
[19:27] <apw> it seems unlikely its not in our source
[19:27] <cnd> federico1: ahh, ok
[19:27] <apw> manjo, its either its not enabled cause 1) error, or 2) known issues
[19:27] <cnd> federico1: give me a minute to context switch in this bug
[19:27] <Delemas> apw: I would love to know why....
[19:28] <cnd> federico1: ok, yes
[19:28] <cnd> I think we put b in lucid
[19:28] <apw> as noone has noticed in the whole of the release cycle i assume its not widespread
[19:28] <cnd> because it fixed an issue for me
[19:28] <apw> manjo, what config option is it
[19:28] <cnd> where sometimes when opening the lid and resuming it wouldn't switch back
[19:28] <federico1> cnd: argh, one sec, phone call...
[19:29] <cnd> federico1: we may want to take this elsewhere as well
[19:29] <cnd> a quieter channel?
[19:29] <manjo> apw, we don't even have the src ./drivers/scsi/3w-sas.c
[19:29] <Delemas> apw: CONFIG_SCSI_3W_SAS
[19:30] <Delemas> as of 2.6.33.1
[19:30] <apw> manjo, we don't delete source files ?
[19:30] <apw> if its in 33.0 then its not in lucid
[19:30] <manjo> apw, yep I am confused 
[19:30] <manjo> apw, git log says 3w-sas: Add new driver for LSI 3ware 9750 Fri Oct 23 14:52:33 2009 -0700
[19:30] <manjo> apw, that is mainline
[19:31]  * manjo confused
[19:31] <Delemas> That is what I was hoping for. i.e. the addon driver for 2.6.32 and lower...
[19:31] <manjo> apw, something we can add to backport modules ? 
[19:31] <apw> its somewhat too late for lucid now, these are things that need to be found in early testing
[19:32] <apw> manjo, perhaps ... why does noone test before release?
[19:32] <manjo> heh
[19:32] <Delemas> Weird 'cause there is a download from 3ware for 9.10...
[19:33] <manjo> ogasawara, apw, we should open up a channel where people can request drivers to be added 
[19:33] <manjo> for M
[19:33] <apw> not particualarly wierd, there are 100s of dodgy vendor drivers out ther
[19:33] <ogasawara> manjo: it's called kernel-team@lists.ubuntu.com :)
[19:33]  * apw assignes manjo to man the channel
[19:33]  * manjo ducks
[19:33] <Delemas> well there are lots of 3ware cards in linux boxes... *shrugs*
[19:34] <apw> luckily ii pired pretty low
[19:34]  * manjo belly got in the way
[19:34] <apw> Delemas, its hard to suck up all the card drivers in the world, we need user requests and justifications for them
[19:34] <apw> as many are just crack
[19:35] <manjo> Delemas, so as of now I don't think there is support for that card ... but you could try the main line build of our kernel and see if that wroks for you ... but that kernel is unsupported 
[19:35] <Delemas> I'm just checking the build for the module now...
[19:36] <manjo> apw, in the mean time we could perhaps consider adding that crack to backport moules package 
[19:36] <apw> you could indeed, you'd want to evaluate how good it is as well, we don't want to support something which doesn't really work 
[19:36] <manjo> apw, right 
[19:37] <manjo> apw, do we support s**t that gets packaged in backport modules ? 
[19:37] <Delemas> Fruit you guys have it turned off in that kernel too even though it supports it....
[19:37] <manjo> Delemas, that can be fixed easily
[19:37] <apw> Delemas, then the default in mainline must be off
[19:38]  * manjo spoke too soon
[19:38] <apw> and that normally indicates its low quality
[19:39] <manjo> I can see Tejun Heo cleaned up a bunch of stuff in that driver recently 
[19:40] <federico1> cnd: sorry - my dad was calling
[19:40] <cnd> federico1: np
[19:40] <federico1> cnd: so, thanks for debugging that
[19:40] <apw> manjo, wahts the default selection for the option?
[19:40] <apw> i'd check if my machine wasn't rattling my teeth doning a sync
[19:40] <federico1> cnd: I think I'd feel more comfortable just ignoring the warped event, rather than trying to set the configuration again
[19:41] <federico1> cnd: I thought that we were passing bogus values to XRRSetCrtcConfig(); never imagined that the timestamps would be the problem
[19:41] <federico1> (it's also pretty hard to reproduce, at least on my end...)
[19:41] <cnd> federico1: yes, I felt the same way, except:
[19:41] <cnd> I ran into an issue with my new dell mini
[19:42] <cnd> when I open the lid, it emits the two events (opening the lid resumes the machine from suspend, btw)
[19:42] <manjo> looking 
[19:42] <cnd> if I had a vga cable plugged in on suspend
[19:42] <cnd> then on resume, if we ignored the first event then it somehow wasn't switching off vga
[19:42] <apw> manjo, where is the damn driver?
[19:42] <manjo> scsi
[19:42] <cnd> and if you were in only-vga mode, you had no screen
[19:43] <cnd> so for ubuntu at least, we went with sending the event twice
[19:43] <apw> if the config option Delemas quoted is right its not in 34-rc6
[19:43] <manjo> config SCSI_3W_SAS
[19:43] <manjo>         tristate "3ware 97xx SAS/SATA-RAID support"
[19:43] <manjo>         depends on PCI && SCSI
[19:43] <manjo>         help
[19:43] <manjo>           This driver supports the LSI 3ware 9750 6Gb/s SAS/SATA-RAID cards.
[19:43] <manjo>           <http://www.lsi.com>
[19:43] <manjo>           Please read the comments at the top of
[19:43] <manjo>           <file:drivers/scsi/3w-sas.c>.
[19:43] <cnd> cause it's better in my mind to get my screen back, even if it flickers someone else's an extra time
[19:43] <federico1> cnd: so, plug vga and make it the only enabled monitor, suspend, unplug, unsuspend -> no display?
[19:43] <cnd> but who knows how many people see both events too?
[19:44] <cnd> maybe it's a buggy graphics card, and few others see them
[19:44] <Delemas> apw: I wish I could find something concrete about issues. Yes that's the option...
[19:44] <cnd> federico1: correct, on your repro scenario
[19:44] <cnd> as far as I can remember
[19:44] <cnd> it was a while ago :)
[19:46] <federico1> cnd: that's weird.  It *could* be that something is settling down, and in the first event, the VGA still reports as being connected, when in fact it's not.  That *could* be that old bug in the intel driver which made it say that VGA was connected when it wasn't (or is that code too new to be that bug?)
[19:46] <cnd> federico1: that very well could be the issue
[19:46] <apw> 3ware 97xx SAS/SATA-RAID support (SCSI_3W_SAS) [N/m/y/?] (NEW) 
[19:46] <cnd> I didn't have time to fiddle with the driver itself
[19:46] <cnd> and there's some weird stuff in there about not honoring the lid switch in older cards
[19:47] <apw> manjo, it defaults off: 3ware 97xx SAS/SATA-RAID support (SCSI_3W_SAS) [N/m/y/?] (NEW) 
[19:47] <cnd> so I figured we might as well just do the best we can in userspace
[19:49] <federico1> cnd: yeah, lids are a big problem right now
[19:49] <federico1> cnd: so, I'll push your patch
[19:50] <cnd> federico1: ok, thanks :)
[19:50] <Delemas> Murphy's law everything else supports it but what I want to run... :)
[19:50] <federico1> cnd:  something to keep in mind - one thing I've been wanting to do to reduce flicker is that when we are going to change the RANDR parameters, first fade all monitors to black, then do the switch, then fade back in
[19:50] <federico1> cnd: macos does that and it looks very smooth
[19:50] <federico1> cnd: so *that* fading may give us enough time to let hardware and drivers to settle down
[19:50] <cnd> ahh, yes
[19:51] <manjo> Delemas, looks like its not a stable driver, so supporting it in an LTS is not a good idea
[19:51] <cnd> federico1: well, we can change this behavior when we get to that point
[19:51] <cnd> I certainly don't care whether we ignore or readjust the second
[19:51] <cnd> I just want things to work :)
[19:52] <manjo> Delemas, I think its an easy call not to deal with that driver until it gets stable
[19:52] <Delemas> manjo, it's in the stable kernel, not marked experimental and available for bsd and el5 etc....
[19:52] <federico1> cnd: well, if it didn't work for you when ignoring the second, let's re-emit the change
[19:52] <federico1> cnd: give me a few minutes and I'll push it
[19:52] <cnd> federico1: np
[19:53] <cnd> like I said, we applied the patch to ubuntu pre release
[19:53] <cnd> so there's no urgency from us
[19:53] <apw> manjo, Delemas, as for the mainline builds they just take the default from upstream which is off ... which needs some thinking about to fix there
[19:53] <cnd> federico1: thanks for following up on this!
[19:54] <cnd> sorry to drag you into the kernel den
[19:54] <federico1> cnd: np - I want to get to the core of these oddities; otherwise multi-monitor support looks like a total fail
[19:54] <cnd> yeah
[19:54] <cnd> and honestly, the patch fixes an error warning, but no bad behavior
[19:54] <cnd> so if you see any whiff of regression, let us know
[19:55] <cnd> we should both revert it if it there's any regression
[19:55] <federico1> sure
[19:55] <cnd> I guess, no bad behaviour other than the vga suspend no-vga resume case
[19:56] <federico1> cnd: any ideas on where the two input events may come from?
[19:56] <cnd> federico1: nope
[19:56] <cnd> didn't get that far
[19:57] <cnd> I'd assume from the i915 module though
[19:57] <manjo> Delemas, I just checked the readme on lsi, fedora & suse include this driver as unsupported ... 
[19:57] <manjo> apw, ^
[19:58] <manjo> imho better of going for a better supported raid card in linux
[19:58] <apw> i guess the right thing to do is get a bug opened asking for it, and we can decide what if anything we can do about it now we are released as a team
[20:00] <manjo> apw, +1
[20:00] <manjo> Delemas, ^
[20:01] <Delemas> ya this is really being an uphill battle.I guess I'll just get a 9690SA instead.
[20:02] <apw> Delemas, i'll add trying to make those drivers self enable in mainline builds to my todo list
[20:03] <Delemas> apw Thanks. Eventually that card will replace the 9690SA so support would be good.
[20:13] <grapz> Hi. I'm trying to get 10.04 to work with the new MacBook Pro (7,1), but there seems to be a problem with the MCP89 chipset, as in it doesn't find any SATA drives. Should this be reported at Launchpad or at bugzilla.kernel.org ?
[20:13] <manjo> grapz, yep
[20:13] <grapz> as in both ?? :)
[20:13] <manjo> right 
[20:14] <grapz> excellent :)
[20:19] <manjo> grapz, looks likes there is no upstream support either...
[20:20] <grapz> well, i know some MCP89 support was added back in 2.6.29 or so in ahci.c
[20:20] <manjo> grapz, is that an audio chipset... looks like there is one by that name .. 
[20:20] <mjg59> manjo: It's a motherboard chipset
[20:21] <mjg59> Includes audio, sata and other stuff
[20:21] <grapz> the latest from nVidia
[20:21] <manjo> oh no!
[20:21] <manjo> :) 
[20:21] <grapz> or, one of the latest..
[20:22] <manjo> grapz, probably a matter of device ids? can you open a bug ? 
[20:22] <cnd> apw: argh... I'm really pissed off at kernel-wedge
[20:22] <cnd> it's so opaque
[20:22] <grapz> manjo: yeah, i will. is there a site that sais what logs i should add with it ?
[20:22] <cnd> but I *think* I've got my issues fixed
[20:23] <manjo> grapz, use from command line ubuntu-bug linux 
[20:23] <manjo> that will upload all the logs 
[20:23] <manjo> we need 
[20:23] <grapz> ahh, excellent, cool...
[20:23] <manjo> grapz, can you give me device id ? I can quickly look in src 
[20:25] <grapz> manjo: here is a lspci from yesterday: http://codepad.org/XCodPSbX
[20:25] <manjo> looking 
[20:28] <manjo> cnd, don't you have a macbook pro? 
[20:28] <cnd> manjo: a macbook and a dell mini 10
[20:28] <cnd> manjo: why?
[20:29] <manjo> cnd, <grapz> Hi. I'm trying to get 10.04 to work with the new MacBook Pro (7,1), but there seems to be a problem with the MCP89 chipset, as in it doesn't find any SATA drives. Should this be reported at Launchpad or at bugzilla.kernel.org ?
[20:29] <cnd> manjo: yeah, likely different innards in that one
[20:29] <cnd> I have a Macbook (5,1)
[20:29] <manjo> ah
[20:29] <cnd> and the major versions (7 vs 5) are comparable
[20:29] <grapz> the 7,1 got released 2 weeks ago in Eurpoe atleast
[20:29] <cnd> aren't comparable
[20:29] <Delemas> meh 9690SA doesn't support 6Gbps drives....
[20:31] <grapz> manjo: i'll reboot into livecd and make the bug, back in a bit
[20:31] <manjo> grapz, sure
[20:32] <manjo> cnd, what is your host bridge (lspci) ? 
[20:32] <manjo> 7.1 is Host bridge: nVidia Corporation Device 0d60
[20:33] <cnd> manjo: 00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
[20:33] <cnd> manjo: 00:00.0 Host bridge [0600]: nVidia Corporation MCP79 Host Bridge [10de:0a82] (rev b1)
[20:37] <manjo> ok so found both in http://pciids.sourceforge.net/pci.ids
[20:38] <manjo> Grapz, found it in http://pciids.sourceforge.net/pci.ids
[20:38] <manjo> 0d85  MCP89 SATA Controller
[20:38] <manjo> 	0d89  MCP89 SATA Controller (AHCI mode)
[20:38] <manjo> 	0d8d  MCP89 SATA Controller (RAID mode)
[20:39] <Grapz> manjo, was it ubuntu-bug -s i should use?
[20:39] <manjo> ubuntu-bug linux
[20:40] <Grapz> heh, that option isn`t mentioned in ubuntu-bug --help
[20:41] <manjo> oops ubuntu-bug -p linux then
[20:41] <Delemas> Anyone have a suggestion for high performance SAS2 controller which is Lucid Lynx friendly?
[20:50] <Grapz> manjo, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/576601
[20:50] <ubot3> Malone bug 576601 in linux "mcp89 sata not detected" [Undecided,New] 
[20:56] <manjo> Grapz, you will need to open a bugzilla.kernel.org report as well, looks like it needs upstream work to get the driver working 
[20:56] <Grapz> manjo, ok, so should i reference it to the bug at launchpad or?
[20:56] <manjo> sure
[20:56] <Grapz> will do
[20:58] <Grapz> manjo, what category should I post it in? Drivers?
[20:59] <manjo> yes
[21:01] <bjf> apw, voting goes on until 10:00 p.m.?
[21:01] <bjf> apw, should be closing right about now
[21:01] <manjo> bjf, ?
[21:01] <bjf> manjo, UK elections
[21:01] <manjo> :)
[21:02] <manjo> indications are towards a hung parliament
[21:02] <Grapz> manjo, should I just attach all the logs from the Ubuntu bug?
[21:03] <manjo> yes that will help 
[21:03] <manjo> or they should be able to reference it from launchpad 
[21:04] <manjo> apw, is it going to be Cameron ? 
[21:05] <apw> bjf, another hour
[21:05] <apw> hung to cameron slight i suspect
[21:07] <federico1> cnd: ping
[21:07] <cnd> federico1: pong
[21:07] <Grapz> manjo, https://bugzilla.kernel.org/show_bug.cgi?id=15923
[21:07] <ubot3> bugzilla.kernel.org bug 15923 in Other "SATA doesn't work on MCP89 chipset" [Normal,New] 
[21:07] <federico1> cnd: I'm confused - you said this bug happened when you just open the laptop's lid to unsuspend?
[21:08] <cnd> yes
[21:08] <federico1> cnd: and did you actually press XF86Display, or do those keypress events just come out of nowhere?
[21:09] <cnd> federico1: they came from somewhere, but I did not press any XF86Display buttons
[21:09] <federico1> (i.e. why is this patch in handle_fn_f7() rather than on_randr_event())
[21:09] <cnd> federico1: I assume someone in the kernel is generating the events
[21:09] <cnd> I don't really know
[21:10] <bjf> apw, right i forgot i'm an hour ahead of you :-)
[21:10] <federico1> ok, *that* is weird :)
[21:10] <manjo> bjf, where are you?
[21:10] <bjf> i'm in belgium (uds-m location)
[21:11] <manjo> ah in somehands?
[21:11] <apw> i think he is just there in the location
[21:11] <bjf> manjo, just hanging with mark, he called me up and asked me to come over
[21:12] <manjo> funny guys
[21:12] <apw> who was being funny, no it
[21:12] <apw> not i, even
[21:12] <manjo> bjf & mark
[21:12] <bjf> manjo, according the the kernel calendar :-) I was at a linux audio conference in utrecht, the netherlands and then came down to uds-m
[21:13] <bjf> manjo, rather than fly home and turn around and fly back
[21:13] <manjo> apw, looks like its a 1/2 hr flight for you
[21:13] <bjf> manjo, right now there are the folks and somehands, the design team sprint and then me
[21:13] <bjf> s/and/at/
[21:14] <apw> manjo, 2 hours on the train, three including the ends i hope
[21:14] <manjo> ah train even
[21:14] <apw> yep, avoid the ash at all costs
[21:14] <manjo> heh 
[21:14] <manjo> hear now the ash is in scotland
[21:14] <manjo> they stopped talking at it in the US media
[21:18] <cnd> someone shoot me
[21:19] <cnd> I'm so tired of this kernel wedge issue
[21:19]  * manjo shoots cnd
[21:20] <cnd> oh thank goodness, my kernel finally built right...
[21:20] <manjo> s**t I just shot you 
[21:22] <manjo> apw, when do you guys mumble on thu ? 
[21:23] <manjo> ogasawara, ^
[21:23] <apw> manjo, not sure we've done it recent cause of release week etc
[21:23] <manjo> ah ok
[21:28] <manjo> ogasawara, so you need separate patches for maverick? or can you apply the sru patch from lucid ?
[21:33] <apw> manjo, i think ogasawara is afk for a couple of hours this afternoon
[21:36] <akgraner> apw, ogasawara thank you again for your session this morning!
[21:36] <akgraner> sorry it got a little nuts for a few mins
[21:52] <apw> akgraner, seemed to go better than average
[21:53] <akgraner> oh good 
[21:54] <akgraner> thanks again for running the open week session...
[21:58] <bjf> akgraner, wish you were here, have noone to hang with :-)
[21:59] <bjf> akgraner, i'm at uds-m location already 
[21:59] <bjf> akgraner, everyone else off doing their "somehands" thing
[22:01] <akgraner> bjf, big kid table 
[22:02] <akgraner> bjf, you reserved it right
[22:02] <bjf> akgraner, ACK!
[22:03] <akgraner> bjf, good!  glad you remembered
[22:04] <akgraner> bjf, what's the weather there temp wise?
[22:05] <cnd> apw: in case you are interested, see all the changes in the latest release at http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=summary
[22:05] <cnd> maybe we want to pull the UBUNTU commit to the Ubuntu kernel tree?
[22:06] <bjf> akgraner, 50s
[22:07] <akgraner> apw - Rikki said the proposed kernel is working well for her and he wireless stuff is working like it should - she said to send a Thank you to and I quote "the bestest kernel team"
[22:07] <bjf> akgraner, it's cool but dry right now, i think thats supposed to chage (supposed to get wet)
[22:07] <akgraner> bjf, thanks - :-) now I need to find a bigger suitcase 
[22:15] <manjo> akgraner, load the suitecase with taquilla ? 
[22:15] <akgraner> manjo, nah - just stopping a the duty free area on the way in 
[22:16] <akgraner> JFo,  is on the same flight he can carry it :-)
[22:17] <manjo> akgraner, entourage 
[22:17] <akgraner> hehe
[22:18] <manjo> akgraner, buy him a big mac will you 
[23:05] <manjo> out for a bit
[23:38] <ogasawara> manjo: the SRU re the rtl8192se fix ups? Usually just mention in the email that you want it applied to maverick as well.
[23:38] <ogasawara> I assume it should apply cleanly
[23:39] <ogasawara> manjo: so if you can, just reply to your email that you want it for maverick also so it doesn't fall off my radar
[23:40] <ogasawara> manjo: ah nm, as I'm catching up on my email I see you've already done this :)