**** BEGIN LOGGING AT Sun Nov 08 02:59:56 2009 Nov 08 11:01:32 [florian]: you were gonna "try something" Nov 08 11:04:27 <[florian]> sn9: yes and that did not work, but I know for sure that config/profile- does not work Nov 08 11:05:10 what actually does, if anything? Nov 08 11:05:37 <[florian]> it just searches for config files in subtargets and config-2.6.x.y and config-default Nov 08 11:07:13 grrrr Nov 08 11:07:51 it did not use to do this Nov 08 11:10:45 <[florian]> indeed, so we need to track down the exact changeset that broket it Nov 08 11:10:52 <[florian]> or convert profiles into subtargets Nov 08 11:11:02 already looking Nov 08 11:23:13 <[florian]> sn9: cannot we leave physmap and rdc3210 be enabled together, and physmap has the precedence over rdc3210, so it "should" fallback to rdc3210 for an airlink, what do you think? Nov 08 11:23:58 for ar525w, they need to work together temporarily Nov 08 11:24:50 platform.c tries to make sure the rdc3210 map takes precedence Nov 08 11:25:15 <[florian]> that's what I saw Nov 08 11:25:54 but yes, might as well disable physmap in the ar525w profile for the time being Nov 08 11:36:26 florian * r18339 /packages/ipv6/send/Makefile: [package] update to latest send version 0.2-5.4 Nov 08 12:05:53 florian * r18340 /packages/libs/db47/ (5 files in 2 dirs): [package] update sources to 4.7.25.3, bump release number (#6100) Nov 08 12:15:38 florian * r18341 /packages/net/rtorrent/patches/011-fix-bitfield-crash.patch: [package] add missing rtorrent patch from #6111 Nov 08 13:23:29 florian * r18342 /packages/net/openswan/patches/120-no_manpages.patch: [package] use no man patch from #5745 Nov 08 13:27:19 florian * r18343 /packages/net/openswan/ (Makefile patches/130-netdev_ops.patch): [package] update openswan to 2.6.23, convert to netdev_ops for 2.6.30+ kernels Nov 08 13:59:25 the speedport w500v bcm96348 device is available at pollin.de for 20 euros Nov 08 14:00:57 <[florian]> hu Nov 08 14:01:15 <[florian]> bcm6348 are now outdated, so I guess they just want to get rid of their last units Nov 08 14:04:03 marek * r18344 /packages/net/batman-advanced/Makefile: [batman-adv] update package to retrieve batman-adv 0.2 Nov 08 14:40:42 [florian]: it might be a cool toy, but there's no gpl voip driver, is there? Nov 08 14:41:45 <[florian]> danage: there is not indeed Nov 08 14:42:17 so it's not worth paying the money, there's better hardware at the same price Nov 08 15:25:21 [florian]: can you please test? http://openwrt.pastebin.com/f6d906bcf Nov 08 19:58:47 [florian]: can you commit this? http://openwrt.pastebin.com/f55751424 Nov 08 20:20:46 ping Kaloz Nov 08 21:19:00 <[florian]> sn9: no Nov 08 21:19:13 <[florian]> sn9: please split the rdc specific thing and the build specific things Nov 08 21:19:28 <[florian]> sn9: and send the build specific bits on the mailing-list Nov 08 21:23:19 [florian]: easily sortable by directory; only other affected target would be octeon Nov 08 21:23:48 <[florian]> sn9: then it's you to do the split and go through the usual review process :) Nov 08 21:24:44 can you test, first? Nov 08 21:27:34 [florian]: does it at least fix things on the ar525w this way? Nov 08 21:41:06 <[florian]> sn9: let me test sure Nov 08 21:41:38 note deleted/moved files Nov 08 21:57:02 hauke * r18345 /trunk/target/linux/ (8 files in 2 dirs): Nov 08 21:57:02 [amazon] Add some build fixes for kernel 2.6.21 and the infineon amazon target. Nov 08 21:57:02 Now it compiles with the new toolchain. Nov 08 21:57:02 These are mostly backports from mainline linux and newer linux kernels from openwrt. Nov 08 22:05:16 <[florian]> sn9: that seems to work Nov 08 22:05:45 commit rdc portion? Nov 08 22:08:50 [florian]: also, does the dmz light work as it should? Nov 08 22:28:04 <[florian]> sn9: I have not runtime tested it yet, but the config looks much bette rnow Nov 08 22:28:45 [florian]: ready for commit of the rdc portion? Nov 08 22:29:56 <[florian]> sn9: sure Nov 08 22:31:26 [florian]: make sure it's from the last one i pastebinned; i left out a couple of parentheses before Nov 08 22:31:58 <[florian]> sn9: it compiled fine for me, so I assume I have the latest version? Nov 08 22:32:30 it compiles file without the parentheses, but miscalculates offsets for sitecom images Nov 08 22:32:40 s/file/fine/ Nov 08 22:33:44 <[florian]> ah you mean in target/linux/rdc/image/Makefile? Nov 08 22:33:47 yes Nov 08 22:34:01 <[florian]> that seems to have passed that step too Nov 08 22:34:26 <[florian]> I do not think that we need to set FEATURES:=gpio Nov 08 22:34:30 <[florian]> that is autodetect Nov 08 22:34:39 this illustrates the correction: http://openwrt.pastebin.com/pastebin.php?diff=f55751424 Nov 08 22:44:36 [florian]: got it? Nov 08 22:46:25 <[florian]> sn9: yes I am doing other stuff atm Nov 08 22:48:21 florian * r18346 /trunk/target/linux/rdc/patches-2.6.30/ (004-yenta_mystery.patch 005-fix_amit_breakage.patch): [rdc] make sure rdc321x specific patches apply (CONFIG_X86_RDC321X), patch from sn9 Nov 08 22:49:30 florian * r18347 /trunk/target/linux/rdc/ (5 files in 4 dirs): [rdc] move headers to arch/x86/include/asm/, patch from sn9 Nov 08 22:50:00 <[florian]> sn9: I think ar525w also needs gzip'd ramdisk support Nov 08 22:50:08 nico * r18348 /branches/8.09/package/iproute2/Makefile: [8.09] iproute2: backport [15631] to 8.09 Nov 08 22:53:37 [florian]: i don't remember that, but if so, it can go in the profile config Nov 08 22:53:42 <[florian]> sn9: sure Nov 08 22:54:20 <[florian]> sn9: do we really need perl to make all our computations in target/linux/rdc/image/Makefile? Nov 08 22:54:35 <[florian]> I would rather avoid perl as a prereq even though most people have it already Nov 08 22:55:07 <[florian]> well people already have it since the kernel requires it to build Nov 08 22:55:22 [florian]: unless you'd prefer some more obscure way to generate the checksum... Nov 08 22:55:45 florian * r18349 /trunk/target/linux/rdc/ (Makefile config/profile-wl153 config-2.6.30 image/Makefile): [rdc] also support pcmcia Nov 08 22:55:54 <[florian]> sn9: it would not be very clear with any shell Nov 08 22:56:08 <[florian]> crap I committed the whole thing as a single commit :/ Nov 08 22:57:47 <{Nico}> [florian]: we already have a prereq on perl anyway (metadata.pl, feeds...) Nov 08 22:58:39 <[florian]> {Nico}: yes that's right Nov 08 22:59:06 [florian]: target/linux/rdc/config/profile-wl153 is deleted Nov 08 23:01:30 florian * r18350 /trunk/target/linux/rdc/config/profile-wl153: [rdc] remove empty wl153 profile after r18349 Nov 08 23:04:11 {Nico}, nbd: what do you think of this? http://openwrt.pastebin.com/f6fac3f3f Nov 08 23:04:47 progress on the rdc profiles :O Nov 08 23:15:50 sn9: i don't like per-profile kernel configs Nov 08 23:16:56 sn9: the CONFIG_BLK_DEV_INITRD change looks ok, though Nov 08 23:16:58 nbd: they've already been there for octeon and rdc, and i could have sworn they used to work, but i could find no evidence in svn that they were ever read Nov 08 23:17:19 if something *needs* kernel config changes for different devices, it should be done with subtargets Nov 08 23:18:04 the amit profile is going to need subprofiles before we're done Nov 08 23:18:12 <[florian]> they have also been used by ixp4xx Nov 08 23:18:22 [florian]: not currently Nov 08 23:18:44 <[florian]> sn9: oh right now it's a subtarget Nov 08 23:18:57 <[florian]> I am fine with converting profiles into subtargets Nov 08 23:18:58 nbd: I think I used subtargets for ixp4xx kernel differences, didn't I? Nov 08 23:20:06 yes Nov 08 23:22:56 actually, subtargets might also solve the amit issue Nov 08 23:24:05 nbd: what could be done about octeon? Nov 08 23:25:30 simply replace the profiles with subtargets Nov 08 23:26:14 at some point i'll also rework make kernel_menuconfig to be able to handle config sharing between subtargets Nov 08 23:26:39 the above patch kinda sorta does that Nov 08 23:26:48 no Nov 08 23:26:50 what i mean is Nov 08 23:27:10 that you can choose whether to store kernel_menuconfig changes in the per-subtarget overlay or in the base config Nov 08 23:27:49 the overlay should have its own menuconfig make target, then Nov 08 23:28:41 i was thinking about something like make kernel_menuconfig SUBTARGET=foo Nov 08 23:29:00 that would be good too Nov 08 23:29:44 no, it wouldn't Nov 08 23:29:52 ? Nov 08 23:30:31 the choice should be between the current subtarget and the overall target Nov 08 23:31:15 and there should be a menuconfig for generic-2.x, too Nov 08 23:31:33 the latter wouldn't really work Nov 08 23:33:17 yeah, you're right Nov 08 23:38:19 nbd: actually, it wouldn't really work for subtargets, either Nov 08 23:38:43 why not? Nov 08 23:39:39 how would the system decide what goes into the overlay and what is shared without comparing all the subtargets to each other every time? Nov 08 23:40:26 without that, the shared config may need options that only one subtarget will use Nov 08 23:40:54 kinda like generic-2.x, but on a smaller scale Nov 08 23:40:57 you run make kernel_menuconfig for the main target, it combines generic config + target config, runs menuconfig, diffs between generic config and resulting config Nov 08 23:41:15 for the subtarget replace generic config with generic config + target config and target config with subtarget config Nov 08 23:42:12 oh, i see, the main target is a profile, too Nov 08 23:42:22 yeah, that's good Nov 08 23:42:42 but then no invocation changes are necessary Nov 08 23:42:57 no, main target may not be selectable directly Nov 08 23:43:09 but it should be possible to run kernel_menuconfig for it anyway Nov 08 23:43:25 if you want to make specific changes for all variants Nov 08 23:43:25 if it is not selectable, there should be no shared config Nov 08 23:43:38 there should be, if there are only minor differences between subtargets Nov 08 23:43:44 makes keeping things in sync easier Nov 08 23:44:04 if the differences are minor, it should be selectable Nov 08 23:44:51 not implicitly Nov 08 23:44:58 by putting one of the profiles in the target rather than as a subtarget Nov 08 23:44:59 you could make a subtarget without its own config if you want that Nov 08 23:46:03 not every profile should need a subtarget even when subtargets are used Nov 08 23:46:14 ? Nov 08 23:46:26 profiles are assigned to subtargets Nov 08 23:46:35 or to a target if there are no subtargets Nov 08 23:46:51 they should be assignable to both at the same time Nov 08 23:47:13 some in the target, some in subtargets Nov 08 23:47:27 that makes the most sense here, imho Nov 08 23:47:33 where would you use the same profile for multiple subtargets? Nov 08 23:47:42 no, different profiles Nov 08 23:48:15 what i meant was where would you share profiles between subtargets? Nov 08 23:48:21 no Nov 08 23:48:53 ? Nov 08 23:49:10 hi guys Nov 08 23:49:14 a profile would be a single profile regardless of its place in the tree, but only subtarget ones would have overlays for kernel config Nov 08 23:49:40 Acinonyx: you're maintaining the olsrd quagga plugin? do you have a recent, working version for quagga 1.0-rc? Nov 08 23:50:04 i meant: either a target has no subtargets, then profiles belong to a target. or a target has subtargets, then profiles need to be put into the subtargets Nov 08 23:51:28 what if the profiles _can_ be assigned to a subtarget, or alternatively, the implied "generic" subtarget that would be signified by being in only the target? Nov 08 23:51:29 if you have a target that uses subtargets and you want the base kernel config without subtarget overrides to be selectable, you simply create a subtarget without a kernel config Nov 08 23:51:33 and move the profiles in there Nov 08 23:51:58 it works like this: Nov 08 23:52:16 the build system always pulls profiles from one profile dir Nov 08 23:52:25 i understand what you mean; the only difference would be where the files live Nov 08 23:52:28 when a subtarget is selected, it first checks whether the subtarget has a profiles dir Nov 08 23:52:31 and if it does, it uses that Nov 08 23:52:37 if not, it uses the main target's dir Nov 08 23:52:59 currently the same applies for the kernel config Nov 08 23:53:14 although i might change it for the kernel config to implement the config sharing stuff i talked about earlier Nov 08 23:53:39 does the above description match what you had in mind? Nov 08 23:54:17 how about simply requiring all targets with subtargets to supply a "generic" subtarget, even if it has no profiles? Nov 08 23:54:32 why requiring it? Nov 08 23:54:40 for some it makes sense, for some it doesn't Nov 08 23:54:45 baseline for the target Nov 08 23:55:01 there are cases where it does not make sense to have a generic subtarget Nov 08 23:55:03 for instance ramips Nov 08 23:55:10 you can either build for rt2880 or for 3052 Nov 08 23:55:31 what would those share in the kernel config? Nov 08 23:55:41 almost all of it Nov 08 23:56:19 except for the part that selects between 2880 and 3052 Nov 08 23:56:30 and which of the two would the shared config be for? Nov 08 23:56:43 ? Nov 08 23:57:11 the shared config without overlay -- would it say 2880, or 3052? Nov 08 23:57:25 if i can work out the details properly, for neither Nov 08 23:58:10 if it is neither, then it cannot be editable with a menuconfig without reference to a subtarget, just like for generic-2.x Nov 08 23:59:03 it'd pick the default for the missing options in kconfig and filter out common options when writing back the diff Nov 08 23:59:15 ah Nov 08 23:59:36 requires some extra ops in kconfig.pl Nov 08 23:59:40 but is entirely possible Nov 09 00:00:26 but then, the subtarget config has to exist first Nov 09 00:00:34 no Nov 09 00:00:46 oh, you're right Nov 09 00:01:07 for some specific cases you might need hand-editing initially Nov 09 00:01:24 but this brings us right back to the idea of a required generic subtarget Nov 09 00:01:29 for instance if you want to force the system to treat some options as filtered out for subtargets Nov 09 00:01:55 even if it is one that cannot generate a meaningful kernel Nov 09 00:01:56 for ramips there should be no third option in addition to 2880 and 3052 Nov 09 00:02:06 so making a subtarget will be adding confusion Nov 09 00:02:19 the third option would be the default, as you just described Nov 09 00:02:29 the default for what? Nov 09 00:02:32 in which place? Nov 09 00:05:02 brb, phone Nov 09 00:15:57 back Nov 09 00:16:55 nbd: yeah, i think the answer is to have a separate "make shared_kernel_config" Nov 09 00:17:07 err, shared_kernel_menuconfig" Nov 09 00:17:56 i was thinking of doing it with make kernel_menuconfig SHARED=1 instead Nov 09 00:18:02 less code duplication Nov 09 00:18:12 ok Nov 09 00:20:00 [florian]: can you convert the rdc profiles to subtargets for the time being? also, it may be prudent to rename the target from rdc to rdc321x Nov 09 00:32:47 nbd: how do you like this? http://openwrt.pastebin.com/f2698f159 Nov 09 00:33:13 takes care of everything Nov 09 00:35:00 wait Nov 09 00:42:30 nbd: much better: http://openwrt.pastebin.com/f4ac2ac3d Nov 09 00:43:24 i'll look into it later. right now i'm working on adding wds ap/sta support to mac80211 Nov 09 00:43:36 ok, good Nov 09 00:43:53 it's a very small patch, and should work Nov 09 00:44:21 [florian]: subtargets? Nov 09 00:44:23 why the ''+' $(LINUX_DIR)/.config.target /dev/null'? Nov 09 00:45:11 so that the config options can override the menuconfig rather than just being added Nov 09 00:45:23 what's the /dev/null for? Nov 09 00:45:40 otherwise, the m+ prevails for those as well Nov 09 00:46:02 huh? Nov 09 00:46:18 "'+' $(LINUX_DIR)/.config.target /dev/null" should be equivalent to $(LINUX_DIR)/.config.target Nov 09 00:46:25 nope Nov 09 00:46:40 it has stuff appended at the end Nov 09 00:47:02 yes, but it processes stuff recursively Nov 09 00:47:17 so it should resolve the "'+' $(LINUX_DIR)/.config.target /dev/null" before the m+ Nov 09 00:47:19 yes, if told to Nov 09 00:47:24 i mean as a part of the m+ input Nov 09 00:47:29 yes Nov 09 00:47:51 so at which point does it make a difference, then? Nov 09 00:48:19 but with the + there, the stuff appended is treated as + to .config.target, so that .config.override can still be m+ Nov 09 00:48:47 otherwise, it's all m+ Nov 09 00:48:49 you're appending /dev/null Nov 09 00:48:51 there's nothing in there Nov 09 00:48:56 doesn't matter Nov 09 00:49:21 the + does not care where one file ends and the next begins Nov 09 00:49:53 ah, i see what you're getting at now Nov 09 00:50:06 i'd prefer to solve this in a clean way, though Nov 09 00:50:34 but maybe your patch is fine for commit then, though better split as two separate commits Nov 09 00:50:42 i can handle the clean up later Nov 09 00:50:43 the only other clean way would be the way i did it in my original patch Nov 09 00:50:59 but this is actually cleaner than that, IM Nov 09 00:51:01 O Nov 09 00:51:58 i'll review this more carefully later or tomorrow Nov 09 00:52:10 might also need to check our subtargets and restructure some configs then Nov 09 00:53:28 rdc and octeon need per-profile configs converted to subtargets Nov 09 00:53:44 and rdc should be renamed to rdc321x Nov 09 00:58:41 nbd * r18351 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: mac80211: fix wifi detect with 11n cards that have multiple bands Nov 09 00:58:46 nbd * r18352 /trunk/target/linux/generic-2.6/patches-2.6.28/981-vsprintf_backport.patch: backport a recent version of vsprintf to linux 2.6.28 to fix mac80211 wifi interface detection **** ENDING LOGGING AT Mon Nov 09 02:59:56 2009