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