[09:09] <tjaalton> apw: I noticed that you were assigned to bug 256296
[09:09] <ubot3> Malone bug 256296 in linux "USB id 0af0:6911 should use hso and not 'option' driver" [Medium,Fix committed] https://launchpad.net/bugs/256296
[09:09] <apw> tjaalton, hrm ... 
[09:09] <tjaalton> I've got a similar(ish) device, id 0af0:7011 that uses option by default, but removing it and loading hso doesn't seem to work
[09:09] <tjaalton> :)
[09:10] <apw> hm i didn't remember it, as it seems to have been one where a stable update fixed it for us
[09:10] <apw> so i didn't really do anything to it :)
[09:11] <tjaalton> bummer
[09:11] <tjaalton> this one doesn't work in jaunty, but I'll go hunt a patch for it
[09:11] <apw> when you say removing it and loading hso, do you mean litteraly just rmmod modprobe?
[09:11] <tjaalton> yes
[09:12] <tjaalton> probably isn't enough
[09:12] <apw> that i wouldn't expect to do anything, one of them will be tied to that PCI id
[09:12]  * apw checks
[09:12] <tjaalton> right..
[09:12] <Kano> hi, is anybody working on 2.6.29 today
[09:12] <Kano> the acpi dir is missing from header package
[09:13] <apw> yeah hso has those usb id's in it
[09:14] <apw> drivers/net/usb/hso.c:	{default_port_device(0x0af0, 0x7011)},
[09:14] <apw> so i would have expected that one to be loaded not option
[09:14] <apw> but that is what you wanted me thinks?
[09:14] <tjaalton> does it need an entry in unusual_devs.h?
[09:14] <apw> is it a disk?
[09:14] <tjaalton> both
[09:14] <apw> that is for storage
[09:15] <tjaalton> the storage part has windows drivers..
[09:15] <apw> it only needs an entry there if is its broken
[09:15] <apw> ie non-standard in some way
[09:15] <tjaalton> https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004498.html
[09:15] <apw> thats not the same id's tho
[09:16] <tjaalton> no, but similar fashion
[09:17] <apw> you could try duplicating that one
[09:17] <apw> and putting your id's on it
[09:18] <apw> assuming you have nothing on it you care about
[09:18] <tjaalton> nope
[09:21] <apw> you presumably are ok making your own kernels to test this?
[09:21] <apw> you should file a bug for this either way of course
[09:22] <tjaalton> yes, sure
[09:28] <tjaalton> sigh, hal should've picked it up but didn't
[09:32] <tjaalton> or maybe it really needs the kernel patch first
[09:40] <apw> Keybuk, hey ... was it you who told me they had tried booting in OnDemand and it was slower
[09:44] <Kano> tjaalton: do you play with aufs?
[09:46] <tjaalton> Kano: no
[09:46] <Kano> anybody else?
[09:55] <tjaalton> apw: silly question; how do I get the correct hex values for UNUSUAL_DEV? the first two are obvious, but the rest aren't
[09:57] <apw> the first two are the usb id, the next two are the bcdDevice range, low, high
[09:57] <apw> i see in the one you are copying they are 0000 and 9999 so use those
[09:57] <apw> ie _all_ devices in that id
[09:58] <tjaalton> ok, thanks
[11:09] <tjaalton> apw: tried this http://users.tkk.fi/~tjaalton/foo/option-7011.diff but it didn't seem to work
[11:10] <tjaalton> duh
[11:10] <apw> ?
[11:10] <tjaalton> maybe I should've used US_FL_IGNORE_DEVICE instead of 0
[11:10] <apw> heh
[11:11] <tjaalton> because jaunty doesn't have option_ms_init, the "0" was a leftover from the other patch
[11:21] <_ruben> when having just ssh access at your disposal .. how can one increase the entropy pool? .. generating a 2048 rsa key on a remote seems to have stalled
[11:36] <lool> apw: Given you last touched the prerm, I think you'd be the best person to review the proposed changes to fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/348395
[11:36] <ubot3> Malone bug 348395 in linux "Leaves /lib/modules/$(uname -r)/*.bin files behind" [Undecided,New] 
[11:37] <apw> lool ack
[11:37] <apw> as in i'll look
[11:37] <NCommander> The lpia configuration currently has CONFIG_ATA as a module, can we change that to be compiled in? Its causing the installer to break down and cry since it can't find the HDD or the CD-ROM
[11:37] <apw> lool there is no fix on there
[11:38] <NCommander> (I'd actually like to copy the current i386 config to lpia, since there are quite a few differences it seems
[11:38] <apw> but its also a duplicate of a bug which is in progress
[11:38] <apw> i'll get it sorted out
[11:38] <lool> apw: There's a description of what to change, which is to list the three files in the @files_to_remove array
[11:39] <apw> lool.  yes indeed
[11:39] <lool> Which I think is as long to do for someone than merging a patch or a git tree, but really much faster for me
[11:39] <apw> thanks for the heads up
[11:39] <lool> apw: Didn't find the duplicate though, sorry
[11:40] <apw> don't worry i never ever find anything in launchpad either
[11:40] <apw> its search and i do not get on
[11:40] <lool> (I only found users with this issue in forums etc. when googling)
[11:40] <apw> dammit launchpad is soooo slow
[11:40] <lool> (removed quotes in topic)
[11:41] <lool> apw: Today?
[11:41] <lool> :-P
[11:41] <apw> now, always,
[11:41] <apw> you watch anyone who uses it a lot
[11:41] <apw> and they have loads of tab based tricks to get round its immense slowness
[11:41] <apw> prefetching bugs and stuff
[11:42] <lool> Yeah, I don't think I would notice if it becomes fast in the future, I'll continue loading pages in the background while context switching to something else
[11:42] <apw> heh see, you do it too
[11:43] <lool> Yeah, and my ADSL doesn't help, it's sluggish and loses packets; anyway => lunch &
[11:48] <NCommander> second question, is there an easy way to build the lpia kernel on amd64?
[12:05] <tjaalton> apw: huh, hso claims that "not our device" when modprobing it
[12:05] <tjaalton> sorry, "Not our interface"
[12:06] <tjaalton> looking at hso.c doesn't list the id as USB_DEVICE
[12:06] <Kano> hi rtg , did you get what i worte yesterday, that the acpi dir is missing from 2.6.29 header package? I have no idea how to fix it, please do
[12:06] <apw> Kano, wahts the bug number
[12:07] <Kano> i guess there is none,because the error is in git only
[12:07] <Kano> but the result of this problem is that: http://www.phoronix.com/forums/showthread.php?t=16173
[12:07] <Kano> the correct fglrx patch does not work due to missing files
[12:07] <apw> if the headers package is missing files, then its a bug on your machine.  so lets get a bug filed
[12:08] <apw> we have someone looking at a different missing header at the moment and would make sense to fix both at the same time
[12:08] <Kano> the headers are installed, that dir is new and missing
[12:08] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=tree;f=include/acpi;h=5ef3a2cd591223bf069be60037f2c576023752aa;hb=HEAD
[12:08] <Kano> thats new
[12:09] <apw> bang all that info in a bug and let me know the number
[12:10] <Kano> but somehow i do not even see that acpica subdir in it...
[12:11] <apw> the directories which get put in there are selected manually
[12:15] <Kano> i guess that acpica sub dir inside acpi is created when you compile it
[12:17] <Kano> or it is completely missing there as it is in drivers/acpi/acpica/acconfig.h
[12:17] <Kano> but fglrx needs those includes somehow
[12:19] <IntuitiveNipple> apw: ping (re bug #337929)
[12:19] <ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Medium,In progress] https://launchpad.net/bugs/337929
[12:20] <apw> IntuitiveNipple, hi ... wassup?
[12:20] <IntuitiveNipple> apw: got a couple of minutes to discuss ^^^
[12:20] <apw> sure
[12:21] <IntuitiveNipple> apw: I debugged it last evening based on max's oops log and building the same version lbm and tracing the disassembly.
[12:22] <apw> ok, what did yo ufind
[12:22] <apw> can't say i've done much with it as yet
[12:22] <IntuitiveNipple> apw: It got to the point I was bog/bug-eyed and not clear in my thinking because I chased down several false trails, *but* I think the reason for the bug is an off-by-one or out-of-bounds write issue
[12:23] <apw> ok makes sense
[12:23] <rtg> IntuitiveNipple: I think you ought to be able to produce the same result with 2.6.29. If thats the case, you could annoy the upstream guys with this bug.
[12:24] <IntuitiveNipple> The crux of the issue *seems* to be that in wiphy_update_regulatory() at the end is a test on wiphy->reg_notifier
[12:24] <IntuitiveNipple> If that is non-zero it is expected to be a function call-back pointer
[12:25] <apw> and what we putting in there
[12:25] <IntuitiveNipple> I may be wrong here because I was getting tired, but I'm pretty sure what is happening is in the wiphy struct that pointer is stored immediately after the bands[xxx] array pointers, and the value in it is 0x00000004 - I *think* bands[xxxxx] is going out of bounds and writing into reg_notifier
[12:26] <IntuitiveNipple> causing the attempt to call the function 
[12:26] <apw> that would be bad ... will have a look
[12:27] <IntuitiveNipple> It's annoying to trace, I got lost in all the back-n-forth. 
[12:27] <IntuitiveNipple> My other question about it is, find out what max has in the module options setting - is the setting he has for the lbm_cw_cfg80211 module or cfg80211 
[12:28] <apw> yeah its not at all clear fromt ehb ug
[12:28] <apw> though he's not dumb
[12:28] <apw> it should fail to laod if its for the normal module
[12:28] <apw> you filed the bug for that one i think
[12:29] <IntuitiveNipple> Because there is another potential issue I discovered: when we have OLD_REGULATORY enabled *and* CRDA in use, there's some unusual code paths and potential forced changes to the domain/bands that could potentially lead to this issue. I didn't find evidence of that, but had the suspicion
[12:30] <IntuitiveNipple> No, you misunderstand me... I was wondering if the module option was being picked up by lbm_cw_cfg80211 even though it is set for cfg80211. I wondered that because at one point I was doubting the symbol munging
[12:30] <Keybuk> apw: yes
[12:31] <IntuitiveNipple> Later I resolved some of those doubts but... :)
[12:31] <apw> Keybuk, i forget what i asked, damn
[12:31] <Keybuk> apw: whether I said booting with ondemand was slower
[12:31] <apw> ahh yes, thanks
[12:32] <apw> Keybuk, that needs recording somewhere so we don't think its a good idea to undo it again
[12:32] <Keybuk> do we have somewhere where we record kernel config decisions?
[12:32] <apw> i am suspecting not, and that we should
[12:33] <apw> rtg do we have a wiki page with anything about our config that you remember?
[12:33] <rtg> apw: we did something for the last UDS, but I've lost track of it.
[12:34] <apw> yeha we did didn't we
[12:34] <apw> we could do with a meta something pointing to that
[12:34] <apw> and listing generaly things like this
[12:35] <IntuitiveNipple> was it this? https://wiki.ubuntu.com/KernelTeam/Specs/BootPerformance
[12:35] <IntuitiveNipple> which links to: https://wiki.ubuntu.com/KernelTeam/2.6.28-2-generic-config
[12:35] <apw> yeah that later one
[12:37] <tjaalton> apw: ok, adding the usb id in hso.c makes it load the module, but it still says "Not our interface", grr
[12:40] <Kano> rtg: http://kanotix.com/files/kernel/unused-patches/2.6.29-ubuntu-aufs-compile-fix.patch
[12:41] <Kano> rtg: that patch works against current git, please commit
[12:43] <apw> Keybuk, ok have recorded it here: https://wiki.ubuntu.com/KernelTeam/KernelConfig
[12:48] <mdz> apw: can I get an update on bug 319825?  it's in progress / assigned to you
[12:48] <ubot3> Malone bug 319825 in linux "acer_wmi in Jaunty on Aspire One exposes non-functional (always disabled) rfkill device" [Medium,In progress] https://launchpad.net/bugs/319825
[12:50] <smb_tp> mdz, I believe the current state is that we are intending to selectively disable the software rfkil for the aa1
[12:50] <mdz> smb_tp: thanks, so it should be fixed shortly after beta?
[12:51] <smb_tp> mdz, Yes
[12:51] <apw> mdz.  it looks very much like t
[12:51] <apw> the rfkill is not required, and we will want to quirk it away for this device
[12:51] <apw> oh what smb_tp said ... doh
[12:52] <smb_tp> apw, sorry I thought I jump in for you
[12:52] <apw> i have half a patch to do that.  need to clean it up and get smb_tp to re-test
[12:52] <apw> smb_tp, no was fine, just not reading whats in front of me
[13:03] <rtg> apw: I'm feeling dumb this morning. How do I rebase a branch _onto_ master, assuming I've checked out the branch under consideration?
[13:03] <apw> is you want all the non common commits then its just git rebase master
[13:03] <apw> if you are doing a rebase of the top 20 commits from here to master
[13:04] <apw> its git rebase --onto master <last commit before the ones you want> <branch name>
[13:05] <rtg> apw: where '<last commit before the ones you want>' is on the branch ?
[13:05] <apw> yeah, say you want the last three then its the pointer to the commit before those
[13:05] <apw> HEAD~4 sort of thing
[13:05] <rtg> apw: ok, thats a bit more intuitive
[13:06] <apw> for next time you can tag the new place
[13:06] <apw> ie tag master now with 'base-point'
[13:06] <apw> and then it become git rebase --onto master base-point <branch>
[13:11] <rtg> apw: ok, that ain't working for me. what I want is to take the 4 extra commits that I have on my branch and plop them on top of master. 'git checkout lp152626;git rebase --onto master HEAD~4 lp152626' didn't do the right thing.
[13:12] <apw> hrm what did it do instead?
[13:12] <rtg> apw: it sis some shit, but not what I wanted. master did not end up with those 4 commits.
[13:12] <rtg> s/sis/did/
[13:13] <apw> hrm, that should be the right incantion as far as i understand the world
[13:13] <apw> it should reset to master, then move the commits which git log HEAD~4..lp152626 would have shown
[13:14] <apw> if you have the text it produced on your window i'd like to see it
[13:14] <rtg> apw: if I checkout master, HEAD is _not_ one of the commits from the branch.
[13:14] <apw> right, but its supposed to be expanded before the command starts
[13:15] <rtg> apw: here it is exactly:
[13:15]  * apw goes test
[13:15] <rtg> rtg@lochsa:~/jaunty/kern/ubuntu-jaunty$ git rebase --onto master HEAD~4 lp152626
[13:15] <rtg> First, rewinding head to replay your work on top of it...
[13:15] <rtg> Applying Revert Staging: at76_usb: update drivers/staging/at76_usb w/ mac80211 port
[13:15] <rtg> Applying Staging: at76_usb: fix bugs introduced by "Staging: at76_usb: cleanup dma on stack issues"
[13:15] <rtg> Applying Staging: at76_usb: Add support for OQO Model 01+
[13:15] <rtg> Applying UBUNTU: Enabled drivers/staging/at76_usb
[13:15] <apw> and are those 4 commits the ones you wanted?
[13:15] <rtg> yep
[13:15] <apw> so that looks like it did the right thing to me
[13:15] <rtg> should I be _on_ master when I rebase?
[13:16] <apw> nope on lp152626
[13:16] <apw> and you should end up on thre still
[13:16] <apw> ie the lpNNN is modified to be based on master
[13:16] <rtg> correct, but none of those commits ended up in master anywhere
[13:17] <apw> right master is not modified
[13:17] <apw> you asked for this branch to be remade relative to master
[13:17] <apw> now it will merge into master as a fast-forward
[13:17] <rtg> apw: no, what I want is for the unique commits in the branch to get plopped on top of master.
[13:18] <apw> ok there is no single command to do that that i know of
[13:18] <apw> what i would do is the rebase that you did
[13:18] <apw> and then git checkout master; git merge lpNNNN
[13:18] <apw> and it should simply fast-forward master
[13:18] <apw> and you are done
[13:19] <rtg> I really dislike merging.
[13:19] <apw> as a complete asside from the man page the last lpNNNN on the rebase is optional as you are on there
[13:19] <apw> rtg rigth, but it won't be a merge
[13:19] <apw> if it makes a merge, ie. does not say fast-forward then it went wrong
[13:19] <apw> and in the fast-forward case master is effectivly
[13:19] <apw> git reset --hard lpNNNN
[13:20] <apw> git merge which says fast-forward is not a merge at all
[13:21] <rtg> apw: the merge appears to have done what I wanted. How do I get rid of the 'Merge branch' message? It doesn't mean anything outside of my local repo
[13:22] <apw> did it not say fast-forward?
[13:22] <apw> there will be no merge commit in that case
[13:22] <apw> if there is a merge commit it did not do what you wanted
[13:22] <apw> as you just rebased lpNNN onto master, ie it should be relative to master and based on master
[13:22] <rtg> apw: nope, it did not say fast-forward. 
[13:23] <apw> a merge cannot be anything other than a fast-forwar
[13:23] <apw> if it makes a merge life has gone bad
[13:23] <apw> the way i do an update is as follows
[13:23] <apw> git checkout master
[13:23] <rtg> which is why I dislike merges. maybe I'll just go with cherry-picking
[13:23] <apw> git merge origin/master
[13:23] <apw> git checkout lpNNN; git rebase master
[13:24] <apw> git checkout master; git merge lpNNN
[13:24] <apw> none of that ever should make a real merge commit, ever
[13:24] <apw> and then push
[13:25] <apw> the first two make my master the same as upstream.  git checkout master; git reset --hard origin/master in effect
[13:25] <apw> then i get my branch connected to the tip of master, and then merge it in
[13:25] <apw> and that can never be a real merge
[13:25] <rtg> apw: ok, that worked as expected. I think its the 'git checkout lpNNN; git rebase master' step that syncs the root commit tree
[13:26] <cooloney_> apw, i submitted the patch to fix that missing files to remove
[13:26] <apw> right that line is rebuiliding things from master upwards
[13:26] <apw> then it can only ever be a ff of master
[13:26] <apw> by definition, and thus merge will do the right thing
[13:26] <apw> the reason i use merge instead of reset, is if i have done something wrong
[13:26] <apw> i get a merge commit and go OOOPS and can unpick it easily
[13:28] <apw> cooloney_, sounds good
[13:29] <cooloney> apw, my nick is a typo. -:))
[13:29] <apw> heh
[13:29] <IntuitiveNipple> This works for me with master=1,2,5 wip=3,4 ... git rebase --onto master HEAD~2 wip ends up with 1,2,5,3,4
[13:30] <cooloney> actually, it takes me a long time to recompile the jaunty kernel and tested it on my amd64 machine
[13:32] <Kano> rtg: that patch works against current git, please commit
[13:32] <Kano> err, did not want to repeat it ;) but would be nice if you would do
[13:33] <Kano> i checked that the driver/acpi/acpia makefile is in the header package but no header
[13:33] <apw> right headers other than those which are exposed via the official userspace headers are manually selected
[13:33] <apw> file a bug asking for them and we can get then in there
[13:34] <Kano> apw: tell me where to add those
[13:34] <Kano> then i will try
[13:34] <apw> do you have a fobia of bug trackers?
[13:34] <rtg> Kano: I've already said that _if_ aufs is enabled, it won't happen until _after_ I talk to the installer people about upstream alternatives.
[13:34] <Kano> that kernel is not released, so how to make a bug against it
[13:34] <apw> there is a bug in progress right now to re-add some headers which are missing
[13:35] <apw> it would go in the same spot, there is a commit in the hardy tree to export
[13:35] <apw> some drm headers for lum
[13:35] <Kano> rtg: you can use something else,but what hurts if a module is built?
[13:35] <apw> it will be similar to those
[13:35] <Kano> the module works
[13:35] <Kano> if you want to fix unionfs or use whatever that is not important
[13:36] <Kano> but it is needed to have a least one of those modules to build live images
[13:37] <apw> kano, the patch to put the first set of headers in has this subject: UBUNTU: Copy header files for various kernel media
[13:39] <Kano> ok, found it, will try
[13:42] <Kano> mandriva simply adds all .h files to the devel package
[13:43] <Kano> apw: can you tell me how to disable the virtual package when you build the server kernel?
[13:44] <apw> not sure there is any way without editing the configs
[13:44] <apw> that makes the thing double in size, i have already starrted the discussion on whether that is acceptable
[13:45] <Kano> i see no real reason to have got the same kernel in 2 packages
[13:46] <Kano> if it is stripped from some modules or not, that does not really matter
[14:01] <NCommander> rtg, ping, I'd like to discuss with you changing the lpia config to match that of the i386, especially w.r.t.  to CONFIG_ATA which should hopefully fix d-i on lpia; unfortunately, making that config change would cause an ABI bump, so I'm not sure the best solution. Any ideas?
[14:07] <apw> IntuitiveNipple, which version of lbm were you seeng this regulatory oops with?
[14:09] <IntuitiveNipple> I haven't reproduced it 'in real life' - I was reverse-engineering the oops in the report, using the same build as max reported (2.6.28-8 I think?)
[14:11] <IntuitiveNipple> That's my next step. I've just put a build-server together to produce custom debug builds
[14:11] <apw> i jsut tried it here on 2.6.28-11 and it lets me do it
[14:11] <apw> and it also even seems to work
[14:11] <IntuitiveNipple> is your module-list comparable to the list in the oops report?
[14:12] <apw> i am only loading the base cfg driver which explodes
[14:12] <rtg> NCommander: send a pull request to the k-t list. I assume you've coordinated this request with sconklin ?
[14:13] <apw> IntuitiveNipple, the problem is is don't have an ath9k ... so its not 100% trivial to test
[14:14] <apw> IntuitiveNipple, i am not convinced that this is the call at the bottom of the function btw
[14:14] <sconklin> rtg, NCommander: no. This would be a good one to review at the sprint, since it falls right into the netbook repo changeover
[14:14] <NCommander> rtg, no, I've need working out what specifically has gone boom with d-i on lpia, and I got pointed to you.
[14:14] <apw> as the fault is not a jump to 0x000004 but a data reference to 0x00004
[14:15] <NCommander> sconklin, I have a branch which has the updated config, but I'm not sure what to do about the ABI bump (its too large to ignore, since a lot of things move around, and a LOT of new symbols ...)
[14:16] <sconklin> NCommander: that's why it needs to be reviewed by the kernel-team mailing list, an ABI bump touches a lot of projects at the moment.
[14:17] <sconklin> so please do a git-format-patch, and send that to the mailing list. Which hardy repo is your change against? (I hate that I even have to ask that)
[14:17] <NCommander> sconklin, er, this is jaunty.
[14:17] <NCommander> not hardy
[14:18] <sconklin> NCommander: Oh, well then that's a lot easier. Still send a patch to the mailing list, but it's much less complicated from a project management view
[14:18] <NCommander> sconklin, sure, I haven't finished doing a test build with the bumped ABI, so I'll probably push it in an hour or so
[14:19] <sconklin> NCommander: cool, thanks
[14:19] <rtg> sconklin: why are we caring about Jaunty lpia? do we have products based on it? 
[14:21] <apw> IntuitiveNipple, bah no this is only triggered if you have a card reporting a phy
[14:22] <IntuitiveNipple> ahhh, what hardware were you testing on?
[14:22]  * NCommander sighs
[14:22] <NCommander> EE: Missing modules (start begging for mercy)
[14:22] <apw> something without wifi :)
[14:22] <sconklin> No, I only care about jaunty lpia because 1) I'm responsible in a general sense for lpia maintenance and 2) Future development projects will soon be based on jaunty. There's nothing in progress that would affect a decision about lpia in jaunty.
[14:22] <NCommander> Now what do I do?
[14:22] <IntuitiveNipple> apw: :p
[14:22] <apw> add a modules.ignore file listing the modukes wh
[14:23] <apw> which are gone to the abi directory
[14:23] <apw> IntuitiveNipple, heh i tried :)
[14:23] <rtg> NCommander: I'm not at all interested in ABI bumping config changes for no particular reason, other then homogenizing i386 and lpia
[14:24] <IntuitiveNipple> apw: I'll carry on with the debug once I've got the server to behave... installed Jaunty on it earlier, great. Then decided to move the live /var to a separate LVM, but now, for some reason, mountkernfs.sh fails to mount the varrun and varlock tmpfs so networking doesn't start. Interesting Times.
[14:25] <apw> do you have the h/w ?
[14:25] <IntuitiveNipple> apw: Yeah... tons of it
[14:25] <apw> heh one day i need to sit you down with some beer ...
[14:25] <IntuitiveNipple> orange juice is better for you :)
[14:26] <IntuitiveNipple> right... back to the cold windy shed to fix the server :(
[14:38] <apw> IntuitiveNipple, ok i think i have found a very compelling bug
[14:39] <apw> i will build a fixed version (i hope) and upload it for testing
[14:39] <IntuitiveNipple> The lbm_cw_cfg80211 ?
[14:40] <apw> the regulatory oops in in lbm yes.
[14:40] <apw> think i can see how it can happen
[14:40] <apw> not that i can trigger it without an ath5k
[14:41] <apw> will write it up in the patch, so you can see what i found
[14:41] <IntuitiveNipple> ok :)
[14:51] <rtg> IntuitiveNipple: speaking of wireless, I think huaxu.wan@linux.intel.com awaits an updated patch from you for the rfkill oops.
[14:52] <IntuitiveNipple> rtg: Apparently the whole rfkill patch series isn't upstream yet. I got the impression the alternate work-around was being done
[14:54] <IntuitiveNipple> rtg: it's still sloppy programming having work queued after the module is exiting
[14:54] <rtg> IntuitiveNipple: Helmut's comment didn't make _any_ sense to me. Regardless, we still have this problem for 2.6.28.
[14:55] <rtg> IntuitiveNipple: I think it goes a bit beyond sloppy :)
[14:55] <IntuitiveNipple> rtg: I'll test a V2 of my patch for you, and get it posted to the list
[14:55] <IntuitiveNipple> rtg: I was trying to be polite, since we're being logged :D
[14:55]  * maxb waves: I may not be immediately responsive, but I'm semi-around if you want testing for that lbm regulatory oops
[14:56] <IntuitiveNipple> maxb: whilst you're here. The module option... is it "options lbm_cw_cfg80211 ieee802.... " ?
[14:59] <maxb> ieee80211_regdom=EU
[15:02] <IntuitiveNipple> maxb: this is in /etc/modprobe.d/options.conf ? I want to verify the module name specified is lbm_cw_cfg80211
[15:03] <maxb> Yes (I may have had one of the underscores as a hyphen, but IIUC those are equivalent in module names)
[15:05] <IntuitiveNipple> no, that's fine. I had a suspicion it was matching on cfg8011 because the symbol munging looked 'off' but that answers that one :)
[15:39] <Kano> rtg: cp -a drivers/acpi/acpica/*.h $(indep_hdrdir)/drivers/acpi/acpica
[15:39] <Kano> please add that
[15:40] <Kano> mainly for fglrx
[15:40] <Kano> 2.6.29 only
[15:43] <Kano> you just added some others, i never needed em but why not.
[15:49] <mjg59> What the fuck is fglrx doing consuming stuff from acpica?
[15:49] <mjg59> That's so far outside the exported API it's not even funny
[15:53] <Kano> well there is no official patch for 2.6.29 + fglrx, but the unofficial ones needs it
[15:53] <mjg59> Then it's very, very broken
[15:53] <Kano> i guess you have to wait 3 month for a real one ;)
[15:54] <Kano> when 2.6.30 out or so *g*
[15:54] <mjg59> The only code that should be using the acpica headers is acpica itself
[15:55] <mjg59> There's defined exported interfaces for interacting with the acpica code
[15:55] <Kano> you are free to create a better 2.6.29 patch
[15:56] <Kano> if you do that, no problem
[16:05] <Kano> what would be the include line for something that is in driver dir <acpi.. > does not seem to work
[16:06] <mjg59> There isn't one
[16:06] <mjg59> You can't #include stuff that's not in the exported API
[16:07] <Kano> well ../drivers works ;)
[16:07] <mjg59> If you're inside the source tree, yes
[16:07] <mjg59> But that means you're doing something wrong
[16:09] <Kano> mjg59: it is not my fglrx patch, how about providing one?
[16:09] <mjg59> All I'm saying is that the code is horribly roken
[16:09] <mjg59> I'm not interested in rewriting stuff for a closed driver
[16:16] <mjg59> Oh, wow, this code is horrific
[16:17] <mjg59> It changes internal kernel state without any locking
[16:17] <mjg59> Utterly, utterly insane
[16:18] <mjg59> Kano: It can't be fixed without having the soure code to the binary component
[16:19] <mjg59> But it's also racy and likely to cause oopses under certain circumstanes
[16:22] <Kano> well those parts are only the the wrapper
[16:23] <mjg59> So?
[16:24] <Kano> couldnt you fix that part?
[16:24] <mjg59> No
[16:25] <mjg59> Not without modifying the closed part
[16:54] <apw> IntuitiveNipple, pushed the LBM packages for bug #337929, URL is in the bug
[16:54] <ubot3> Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Medium,Incomplete] https://launchpad.net/bugs/337929
[16:54] <apw> if you have a test bed, then it would be good if you can test
[16:59] <rtg> apw: I'd kind of like to see the patch too, can you attach it to the LP report?
[16:59] <apw> rtg its in the rookery link
[17:00]  * maxb wonders if apw meant to publish udebs, not debs ?
[17:00] <maxb> and empty udebs, at that
[17:00] <IntuitiveNipple> apw: I was just off out. I'll take a look later :)
[17:00] <apw> maxb, no he did not.  arrg
[17:01]  * apw goes hit the build system with larger hammers
[17:01] <maxb> hehe
[17:01] <IntuitiveNipple> well that'll fix it for sure!
[17:01] <apw> rtg, does one need anything other than the headers as reported as build deps to build lbm?
[17:02]  * maxb will fetch coffee and then build locally
[17:02] <rtg> apw: that patch is kind of a stop-gap measure, which will disappear when next LBM is updated. Can you bug folks on linux-wireless as well?
[17:02] <apw> maxb, cool.  will try and resolve why my build are bust
[17:02] <rtg> apw: just the kernel headers
[17:02] <apw> rtg, sure this is just to get this tested by those with the issue
[17:02] <apw> if its works, i will propose a cleaner version upstream
[17:03] <apw> FATAL: Could not load /lib/modules/2.6.28-11-generic/modules.dep: No such file or directory
[17:03] <apw> i am getting those in the build ... yet the build doesn't complain
[17:03] <apw> does one need the kernel installed too?
[17:03] <rtg> apw: its just bitchy, but build anyway
[17:04] <apw> heh nice
[17:05] <apw> who chose ^Q for blow my application away violently, and ^W for close this window and keep running
[17:06] <IntuitiveNipple> apw: I built lbm against just the headers
[17:06] <apw> dpkg-deb: --extract takes at most two arguments (.deb and directory)
[17:06] <apw> Type dpkg-deb --help for help about manipulating *.deb files;
[17:06] <apw> Type dpkg --help for help about installing and deinstalling packages.
[17:06] <apw> make[1]: *** [do-binary-udebs] Error 2
[17:06] <apw> make[1]: Leaving directory `/home/apw/local/git2/ubuntu-jaunty-lbm'
[17:06] <apw> make: *** [binary-udebs] Error 2
[17:06] <apw> dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2
[17:06] <apw> 	  dpkg -x $(ls ../linux-backports-modules-$i\_*i386.deb) \
[17:06] <apw> i _HATE_ debian packaging
[17:07] <rtg> apw: c;ean out the .debs in the directory above ubuntu-jaunty-lbm
[17:08] <apw> thats soooo annoying
[17:08] <rtg> apw: I'll fix it
[17:08] <apw> rtg you are a scolar ... pints++
[17:08] <apw> EOVERFLOW
[17:09] <rtg> apw: I've done it several times now, but evidently missed this one.
[17:09] <apw> we have a large number of packages sadly
[17:09] <apw> and annoyingly i've fixed my kernels build to ship the branch into a nice clean empty build directory separated from all other build to avoid this ever happening
[17:10] <apw> but the automation doesn't work for this thing
[17:10] <apw> yet anyhow
[17:11] <IntuitiveNipple> I've been setting up a cross-compiling distributed build server network. hopefully it'll cut build times down and increase the range I can work with.
[17:12] <maxb> IntuitiveNipple: fancy! What software are you using? I looked at buildd and cringed a bit
[17:12] <apw> i do something similar using a couple of bigger servers
[17:13] <apw> and my laptop can also be a client of itself
[17:13] <IntuitiveNipple> maxb: distcc and gcc
[17:13] <IntuitiveNipple> What I'm trying to do is create a package to manage it all for deployment to EC2
[17:13] <maxb> Ah, compile farm, rather than package building network
[17:13] <IntuitiveNipple> maxb: both
[17:14] <IntuitiveNipple> but cross-compilation is the biggest hurdle to solve
[17:20] <apw> IntuitiveNipple, maxb, ok hopefully there are some actual .deb's at that URL now
[17:24] <rtg> apw: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty-lbm.git;a=commit;h=3988ab032ae12e86da8228945299bc4cd84f4f95
[17:24] <apw> rtg most excellent
[17:25] <rtg> apw: when did you last update from  the LBM repo? I pushed the current wireless-testing about 1.5 hours ago.
[17:25] <apw> ahh crap about 2.5 hours ago
[17:26] <apw> though the code in error was the same in upstream testing
[17:26] <maxb> Fortunately I updated *my* lbm before I started my build :-)
[17:26] <apw> so i belive the issue is till there and the fix the same
[17:26] <maxb> rebooting with apw's patch now
[17:26] <apw> fingers crossed
[17:34] <maxb> apw: well.... wifi worked.... but I don't see your printk either
[17:35] <apw> ?
[17:35] <apw> hrm
[17:35] <apw> you got the appropriate option?
[17:35] <apw> or in-appropriate in this case
[17:35] <maxb> So it's possible something unrelated in the latest wireless-testing/compat-wireless fixed the bug
[17:35] <apw> yep is possible
[17:36] <apw> maxb, perhaps try the module i built which should have missed that update
[17:36] <maxb> I'll fetch your .deb *without* those changes and see if that helps, and build the latest without your patch
[17:36] <apw> maxb, sound plan, thanks
[17:42] <maxb> ah, yup, now I see your printk
[17:46] <apw> hrm.  so it may be fixed some other way now
[17:46] <apw> ok will take that to look at
[17:48] <maxb> Build of master-2009-03-24 for verification is in progress
[17:56] <apw> maxb, thanks a lot
[17:57]  * maxb gets the do-binary-udebs error you got, and says bad things about the buildsystem
[17:58]  * apw hands maxb a hand full of rm
[17:59] <rtg> maxb: buildsystem issues fixed and pushed
[18:06] <maxb> apw: Confirming bug gone (or at least, no longer reproducing) in unpatched ubuntu-jaunty-lbm.git, i.e. master-2009-03-24
[18:07] <apw> maxb, thanks ... grumble... should have ignored it for longer
[18:07] <apw> rtg are we looking to have an lbm update shortly give you are updating it
[18:19] <Kano> rtg: how about a patched drm radeon driver for 2.6.29?
[18:19] <Kano> anything against that?
[21:30] <yago> hi all people. I would like ask if is it possible make a kernel write all in "ada"?
[21:56] <tannewt> could someone enlighten me about the correlation between linux version numbers in ubuntu and the version numbers released on kernel.org?
[21:56] <tannewt> ubuntu released version 2.6.27.7.11 before upstream released 2.6.27.7
[21:58] <johanbr> the ".7" in those two kernels have no relation to each other
[22:01] <tannewt> johanbr: ah, that makes sense, shouldn't it be part of the package revision then?
[22:03] <johanbr> tannewt: no, the Ubuntu ".7" is increased whenever the ABI changes.
[22:04] <tannewt> johanbr: based on patches?
[22:04] <johanbr> yes
[22:04] <tannewt> johanbr: okay, are there any packages the correspond more closely to upstream numbers?
[22:05] <johanbr> there is a build service that builds packages of the upstream kernel
[22:05] <johanbr> if that's what you're looking for
[22:06] <johanbr> if you'd like to know which 2.6.27.X upstream kernel has been included in the ubuntu kernel, you'll have to read the changelog.
[22:07] <tannewt> johanbr: ah, okay, I'm studying the mgiration of packages from upstream to downstream and like to assume version number correlations
[22:13] <johanbr> tannewt: alright. Keeping an eye on the ubuntu kernel mailing list can also be helpful.
[22:14] <tannewt> johanbr: thanks for the tip but I'm automating it all, I'll just note it'll be wrong ;-D
[22:14] <johanbr> oh :)
[22:17] <tannewt> johanbr: pretty interesting stuff,  also have gripes about ubuntu version numbers that include the word "really" :-)
[22:19] <johanbr> tannewt: I think those are a trick to fool the build system.
[22:20] <tannewt> johanbr: I believe that, a way of dealing with weird version numbers like I'm trying to deal with
[22:23] <johanbr> if a kernel is uploaded with too high a version number, I think the build machines won't accept a kernel with the correct (lower) version number, so that's why
[22:23] <johanbr> or something like that
[22:28] <tannewt> hmm, weird
[23:34] <maxb> tannewt: It's not really weird. Fundamentally, version numbers can't go backwards.
[23:34] <maxb> The 'really' hack is just about the only way to accomplish that when an upstream version must be reverted.
[23:34] <maxb> I agree it's ugly though
[23:35] <maxb> Debian has epoch's for this purpose, but Ubuntu can't use them without sacrificing all possibility of automatedly syncing the package from Debian again in the future