[00:17] <MorkBork> still couldnt reproduce it with 24.43
[00:18] <MorkBork> so whatever's borked, it happened somewhere between 24.43 and 25.44
[00:38] <MorkBork> ive tried to look at nearly every commit that looks even remotely relevant
[01:03] <MorkBork> i guess ill try booting 25.44 with atapi_an=1
[01:03] <MorkBork> thats the only thing that seems generic enough to matter
[02:09] <MorkBork> about 40% though and no errors yet
[02:09] <MorkBork> although if libata.atapi_an=1 fixes it i have no idea why
[02:10] <MorkBork> typically the errors dont occur until 60-80ish though, but heres hopin'
[04:42] <MorkBork> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commitdiff;h=bf874fa732c8499a46f2f63a9f973322241955a9;hp=6455cfc45fbc60febd57b52720aa949f48bff6c7
[04:42] <MorkBork> looks like that is what was causing the issue
[04:42] <MorkBork> i cant reproduce the errors with libata.atapi_an=1
[05:05] <bjf[afk]> MorkBork, please file a bug
[05:48] <MorkBork> with kernel.org or ubuntu?
[05:48] <MorkBork> i originally came here because i thought it might be ubuntu specific but it looks like it isnt
[07:13]  * abogani waves all
[07:14] <abogani> Any DKMS guru here? :-)
[07:15]  * RAOF knows a bit
[07:22] <abogani> RAOF: I installed nvidia-current on my laptop which use real time kernel. When it is installing I can see that all things go well for -generic. When it try to build for real time kernel it incur in troubles: It try to build two times the driver from the same kernel. So the second attempt protest "This driver was already built for this kernel" and dpkg exit failing
[07:22] <abogani> Could you suggest something?
[07:24] <RAOF> Do you have logs?  It's quite possible that the nvidia driver won't actually build properly against -rt.
[07:26] <abogani> RAOF: I have patched it and it works if I installed compiled driver manually.
[07:29] <RAOF> It might be more obvious with the dkms log.
[07:32] <abogani> Log file is on my laptop at home. Unfortunately now I'm at work. Which is exactly the log file /var/log/dkms.log, right?
[07:37] <RAOF> That should be it, yeah.
[08:03] <abogani> RAOF: Thanks.
[08:37] <lucent> hey I just hit what I think might be the firewire related bug that bit me last week, again
[08:38] <lucent> http://pastebin.com/FmyR1DWF
[08:38] <lucent> what's going on there is I have 2 firewire adapters, one is internal and one is expresscard
[08:39] <lucent> I unplug the storage device from the expresscard firewire adapter, then plug it in to the built-in one
[08:39] <lucent> what do I do now, though?  
[13:05] <lucent> ping :)
[13:11] <smb> lucent, I am not sure I can tell you much you do not know already. I am not to deep in the firewire code. But apparently you disconnect your drive and it seems the cleanup is not complete. So when you plug it in again it tries to come up as sdb again, but it fails to even read the partition table from there.
[15:16] <abogani> http://trojmiasto.gazeta.pl/trojmiasto/51,35612,8465339.html?i=0
[15:51] <bjf> MorkBork, hey, if you are still around, file the bug with both ubuntu against the "linux" package and with upstream, we can tie the two together, also if you'd put the bug number in this channel, i'd appreciate it, thanks
[15:58] <tseliot> apw, smb: what command do you use to generate a kernel abi? Is there some script that does it?
[15:58] <tseliot> e.g. in debian.$MY_FLAVOUR/abi/2.6.35-5.0/i386/$MY_FLAVOUR
[15:59] <smb> tseliot, if you mean to get the abi files there is a script in debian/scripts/misc/get_abis. That requries the files to be uploaded though
[15:59] <tseliot> smb: yes, that's exactly what I meant to say
[16:01] <tseliot> smb: what shall I do if my kernel is based on maverick's? I have only created my own flavour starting from maverick -generic
[16:02] <tseliot> smb: it should be fine to use that script if I haven't changed anything else, I guess
[16:02] <smb> The files are also generated when you do a compile. So you could copy them for the flavor from the build
[16:03] <smb> I guess that flavor only is intended for i386 and amd64. So you not need to get compiles from porter
[16:03] <smb> s
[16:03] <manjo> bjf, do we have a meeting this week ? 
[16:03] <tseliot> smb: yes, it's just for i386
[16:03] <bjf> manjo, that's what the channel topic says, and my email from yesterday (yes we do)
[16:04] <manjo> bjf, ah thanks ... sorry missed that mail
[16:04] <bjf> manjo, this will be the last one for this dev cycle, the next won't be until after plumbers
[16:05] <manjo> bjf, got it thanks! 
[16:05] <smb> tseliot, actually, for the first run you would place ignore-abi and ignore.modules files to the right place in the abi directory
[16:05] <smb> tseliot, Which I have to look up myself, cause I forget everytime
[16:06] <smb> tseliot, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI should help there
[16:07] <bjf> ##
[16:07] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:07] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[16:07] <bjf> ##
[16:08] <tseliot> smb: right but I guess that's necessary if the files aren't on zync?
[16:11] <tseliot> smb: I built kernels ignoring the abi in the past but, since this branch will end up on zync, I was wondering if there's a way to generate proper abi files instead of overriding the abi check
[16:27]  * smb gets back
[16:27] <smb> tseliot, Right, that you basically do by run the compile once
[16:27] <tseliot> smb: ok, I'll do that. Thanks
[16:27] <smb> And then you find the abi files for that new version under debian.*/abi/i386/...
[16:27] <tseliot> right
[16:55] <bjf> smb,  there is the "xen typo" commit in 2.6.32.24 that i'd like to get applied, i've done it to ubuntu-lucid master branch and am doing a test build
[16:55] <bjf> smb, this needs to be applied to the ec2 branch and get a upload done right?
[16:56] <smb> bjf, Yes, it has likely the most impact for ec2
[16:57] <smb> bjf, What I am wondering about is whether we currently can or should rebase it
[16:57] <bjf> smb, normally we'd pick this patch up via a rebase of ec2
[16:57] <bjf> smb, how would you like to do it this time?
[16:58] <bjf> smb, we don't have a tag to rebase to right now
[16:58] <smb> bjf, Maybe for ec2 makeing a new upload with the same base and the patch on top would be best. It should resolve into nothingness when rebasing on top of a master that contains it.
[16:58] <bjf> smb, so just apply the patch to the tip of current ec2 and then do an upload with that, sounds good to me, i'll make it so
[16:59] <smb> bjf, Ok, yeah. Sounds like the best option for the moment
[16:59] <bjf> smb, that was my thinking as well, just wanted to dbl check
[17:01] <bjf> smb, in the rebase work that jj did it looks like that fix already got applied so nothing to do :-)
[17:02] <smb> bjf, Heh, perfect. Guess he fixed it on the fly then
[17:02] <bjf> smb, spoke too soon, just a sec
[17:02] <smb> oh ok
[17:02] <smb> It does not help that it is just a single letter added. :)
[17:03] <bjf> true :-)
[17:05] <bjf> smb, ah! ec2 has not been rebased with the stable update that was broken so the patch won't apply yet
[17:06] <jjohansen> heh, what is broken in ec2?
[17:06] <bjf> smb, that was in the most recent stable update which we have not done an upload for yet
[17:06] <bjf> jjohansen, nothing at this point
[17:06] <smb> Ah, so no action required either. And when we do, we have the whole set of patches to rebase to
[17:07] <jjohansen> ah, okay, then I won't feel obliged to stick around
[17:07] <bjf> smb, yup, but i've applied the patch to master and we'll be already when we next rebase ec2
[17:07] <smb> bjf, ack
[17:08] <bjf> jjohansen, nope, nothing to see here
[17:16] <lag> apw: Are you guys still around?
[17:17] <apw> lag hi
[17:17] <lag> apw: How easy would it be for you to create new new chroots on our build server?
[17:18] <apw> what you need
[17:18] <lag> natty
[17:18] <apw> on which
[17:18] <apw> there is no such thing
[17:19] <lag> Then how I compile for natty?
[17:19] <apw> there is no such thing ?
[17:19] <lag> Eh?
[17:19] <apw> natty doesn't exist yet so how could we build for it
[17:20] <apw> just build in maverick till the archive opens for natty
[17:21] <lag> Okay
[17:21]  * lag wonders how to fool his scripts into chrooting into a maverick chroot!
[17:22]  * apw has a line which does s/natty/maverick in his tooling
[17:22] <lag> Yeah, just doing the same thing here
[17:26] <penguin42> apw: That intel_ips bug - I wonder if the question that should actually have been asked was why can't it find that symbol?
[17:26] <apw> penguin42, do they have intel graphics ?
[17:27] <penguin42> apw: Isn't all that stuff for the i3/i5/small i7's that have combo graphics?
[17:29] <lag> apw: Would a symbolic link work? ln -s maverick-armel natty-armel
[17:29] <penguin42> apw: One of the reporters had an Acer Aspire 5820TG which is i7-620M (that has Intel graphics) but lists itslef as ATI Mobility Radeon
[17:40] <penguin42> apw: It could be a module load ordering problem or on a laptop with a choice of graphics cards depend which is in use
[17:40] <bjf> ##
[17:40] <bjf> ## Kernel team meeting in 20 minutes
[17:40] <bjf> ##
[17:59] <bjf> ##
[17:59] <bjf> ## Meeting starting now
[17:59] <bjf> ##
[18:14] <rsalveti> ogasawara: cooloney: I updated bug 607250 with the sru
[18:14] <ubot2> Launchpad bug 607250 in linux-linaro (Ubuntu) (and 2 other projects) "omapdss: VDDA_DAC regulator on IGEPv2 (affects: 2) (dups: 1) (heat: 68)" [Undecided,Confirmed] https://launchpad.net/bugs/607250
[18:14] <rsalveti> both patches are not applied upstream, so can be considered as sauce
[18:14] <rsalveti> ogasawara: do you want me to change the patch title or you can do that?
[18:14]  * rsalveti brb
[18:17] <ogasawara> rsalveti: I can do it
[19:00] <rsalveti> ogasawara: thanks :-)
[19:02] <cooloney> ogasawara, thanks for the omap things
[19:49] <njin> hello to all; in this case who is wrong, apport or python ?   apport[5800]: segfault at 10020 ip 00000000004542f3 sp 00007fffd9a4d670 error 4 in python2.6[400000+21a000]   Thanks
[20:02]  * ogasawara lunch
[20:16] <nou> what's ubuntu's equivalent for http://kernel-handbook.alioth.debian.org/ch-common-tasks.html ?
[20:18] <JFo> nou: http://wiki.ubuntu.com/Kernel/
[20:25] <JFo> I like Debian's layout though
[20:25] <JFo> very easy to find things
[20:25] <nou> i guess what i need is a mix of BuildYourOwnKernel and KernelForIdiots
[20:26] <nou> btw i'm used to irc topics :-)
[20:27] <JFo> heh
[20:27] <penguin42> nou: The one I've used is https://help.ubuntu.com/community/Kernel/Compile
[20:28]  * JFo needs to look at that page
[20:28] <JFo> didn't know it existed
[20:28] <JFo> oh man that is old
[20:29] <nou> penguin42: i went on this one, i quite of stopped reading when i saw the "Also note that this page describes how to do things for the Edgy (2.6.17)" sentence
[20:29] <penguin42> nou: Keep reading, it works for them all
[20:30] <JFo> The disclaimer is right though
[20:30] <nou> makes me think of debian's cdebootstrap not knowing more recent than hardy :)
[20:31] <JFo> heh
[20:31] <nou> anyway, thx for your answers
[20:33] <stenten> Is there a place to download old kernels (2.6.35-16 specifically) to see where a bug was introduced?
[20:35] <nou> using the git repository might be a way
[20:36] <stenten> I found the source as a tar file, but the packages have been taken down; I'm assuming they're not archived somewhere?
[20:37] <JFo> stenten, we have been discussing the utility of having an "old kernel storage"
[20:37] <JFo> but I think I remember there being a repository somewhere that we kept them for a time
[20:37] <JFo> not 100% on my memory though
[20:37] <JFo> and I can't find the link I thought I had
[20:38]  * JFo digs some more
[20:38] <stenten> hmm, maybe in the kernel-ppa? I'll search around, thanks....
[20:38] <JFo> I really need a better link library
[20:38] <JFo> stenten, nope looked there already
[20:38] <stenten> heh
[20:38] <JFo> I thought it was a LP link
[20:39] <stenten> I think I found the line in the changelog that probably caused the bug, so I'll just ask them to revert the config option in -22 and test it.
[20:40] <JFo> stenten, sounds good
[20:40] <stenten> thanks for your time, JFo~
[20:40] <JFo> stenten, my pleasure as always :)
[22:52] <manjo> anyone know when the kernel tracks will be up on https://blueprints.edge.launchpad.net/sprints/uds-n ?