**** BEGIN LOGGING AT Wed Jul 26 02:59:57 2006 Jul 26 06:13:43 rwhitby, We can talk about buildroot integration for new targets, if you've read my recent email. Jul 26 06:54:43 oleo: at work at the moment - will you be around in about three hours? Jul 26 06:56:17 03oleo * r3659 10optware/trunk/ (make/postfix.mk sources/postfix/sys_defs.h.patch): postfix:update hard paths to utils - uClibc 0.9.19 on wl500g lacks required res_search() whereas 0.9.28 builds OK Jul 26 07:06:25 03oleo * r3660 10optware/trunk/Makefile: Jul 26 07:06:27 optware: WL500G promote ctcs cvs enhanced-ctorrent libgc metalog nail py-axiom Jul 26 07:06:29 py-epsilon py-lxml py-mantissa py-nevow py-paste py-psycopg2 py-twisted Jul 26 07:06:31 unslung-devel and demote postfix - WL_500G_BROKEN_PACKAGES searched from scratch Jul 26 07:07:34 rwhitby, OK Jul 26 07:22:46 oleo: ping Jul 26 07:26:18 rwhitby Gu Jul 26 07:26:47 yes. Jul 26 07:29:13 oleo: see private message in other window Jul 26 07:29:20 huh. Not a BitchX guru. Instruct me how to open it Jul 26 07:29:29 oh, are you registered with FreeNode? Jul 26 07:29:40 i.e. can you "/msg rwhitby foo" ? Jul 26 07:29:49 yes Jul 26 07:30:12 have you logged in to NickServ? Jul 26 07:30:51 ah, you need to "/msg nickserv identify oleo " Jul 26 07:31:11 it looks like I am not registered. But I have nick reserved. Jul 26 07:31:58 "/msg nickserv register oleo " Jul 26 09:57:54 oleo: ping Jul 26 10:14:23 03rwhitby * r3661 10optware/trunk/make/crosstool.mk: crosstool: fixed dirclean target Jul 26 10:51:47 rwhitby pong Jul 26 10:52:04 oleo: I've started to look at the buildroot work. Very nice work! Jul 26 10:52:27 We can start experimenting in place with a new wrt54g target, right? Jul 26 10:52:42 (I'm building buildroot right now) Jul 26 10:53:20 yes. Target naming is in question here. Jul 26 10:53:46 so we have existing wl500g, and we have new wl500g and new wrt54g. is that correct? are there any other options? Jul 26 10:54:31 if you were to give the targets really long names (like nslu2-armeb-softfloat-linux, or something like that), what would those names be for each of the potential options? Jul 26 10:54:34 Options? nslu2, Openwrt, ... To my testing it can coexist with glibc. Jul 26 10:55:06 So you're saying that buildroot can replace crosstool for all existing targets too? Jul 26 10:55:18 yes Jul 26 10:55:31 what is the main difference between a new wl500g target and a new wrt54g target? Jul 26 10:56:00 just linux-headers. Jul 26 10:56:19 Does that affect the resulting binaries? Jul 26 10:56:44 But this is not a cruical point. I would also like to get this answer. Jul 26 10:57:39 what would you call the options if you had to give them really long names (my question above)? Jul 26 10:57:51 I've think of binary comparing resulting ipkg to see percentage of affected apps. Jul 26 10:58:46 nslu2-armeb-uclibc-linux Jul 26 10:59:38 is the final -linux necessary? Jul 26 11:00:06 I have little experience with this multiple platforms building. Jul 26 11:00:24 s/platform/targets/ Jul 26 11:00:26 oleo meant: I have little experience with this multiple targetss building. Jul 26 11:00:36 ok, so let's look at this from a feeds perspective too Jul 26 11:01:01 we currently have feeds/optware/{nslu2,wl500g,...}/{stable,unstable} Jul 26 11:01:16 however, unstable is just a symlink to stable in all cases at the moment Jul 26 11:02:14 what would the new long names be for the existing wl500g feed, compared to the new wl500g feed? Jul 26 11:02:53 this is not a good engineering as I have two different uClibc which will be messed with ifeq statements in .mk files Jul 26 11:03:33 So some packages will be built with one version of uclibc, and others will be built with a different version? Jul 26 11:03:34 I think its better to name it by firmware. Jul 26 11:04:30 well, the current wl500g feed is for oleg's firmware, as is the new wl500g feed based on buildroot ... Jul 26 11:04:56 so I don't think just firmware is enough, unless we want to force all wl500g optware users to upgrade firmware at the same time Jul 26 11:05:14 It looks like. I've asked Oleg several times to upgrade to latest. But hi is unwilling to include full feature uClibc support. Jul 26 11:05:47 even if Oleg was willing to upgrade (and I understand his reasoning), then there would still be people with old firmware versions. Jul 26 11:06:32 I think to leave wl500g as is and introduce new targets in some smart way. Jul 26 11:06:36 aren't we still producing a current wl500g feed and a new wl500gx feed, which both still work with any of oleg's firmware versions? Jul 26 11:06:48 yes. Jul 26 11:06:49 s/wl500gx/wl500g/ Jul 26 11:06:50 rwhitby meant: aren't we still producing a current wl500g feed and a new wl500g feed, which both still work with any of oleg's firmware versions? Jul 26 11:07:20 but with old uClibc we are unable to support many apps. Jul 26 11:07:40 but you are right, we also need the firmware name in there, so there can be optware packages on wl500g-openwrt ... Jul 26 11:08:16 although I am hesitant to support multiple firmware targets for each device ... Jul 26 11:08:48 Optware is meant to be for the vendor-compatible firmware. OpenWRT is not really a valid Optware target. Jul 26 11:09:25 the problem with naming with firmware is that it should be only uclibc version for .mk and target will be prodiced with appropriate toolchain for given target. Jul 26 11:09:27 (unless the charter of Optware changes ...) Jul 26 11:10:13 can you explain that last sentence more? I'm not sure I fully understand. Jul 26 11:11:42 I suggest uclibc target as this is firmware independent. Only uclibc and buildroot will be compiled separately for target firmware. Jul 26 11:11:56 More clearly: Jul 26 11:12:22 .mk files will have ifdef(uclibc only. Jul 26 11:13:42 When autobuilding for firmware we say: prepare buildroot for this firmware and compile everything with it. This way firmwares will be hidden in buildroot.mk Jul 26 11:15:17 Unfortunate case of wl500g with old uClibc will remain as is. Jul 26 11:16:10 Or will be replaced with uclibc when compiles on both. Jul 26 11:17:25 how many packages compile with old uClibc toolchain, but do not compile with new buildroot uClibc toolchain? Jul 26 11:17:36 none Jul 26 11:18:11 So every wl500g package in the existing feed can be replaced with a new version that depends on a uclibc runtime being installed? Jul 26 11:18:25 yes Jul 26 11:18:29 (and in fact, you can mix and match from old feed and new feed)? Jul 26 11:19:14 (cause old feed binaries use the oleg libs and new feed binaries use the new libs ...) Jul 26 11:19:16 feeds cannod be mixed as many "old" wl500g have -rpath/opt/lib precompiled Jul 26 11:19:17 is that correct? Jul 26 11:19:56 ah, ok. it will pick up the wrong uclibc library if you run an old feed package after you have installed the new uclibc package. Jul 26 11:20:49 I'm going to paraphrase what you wrote after "More clearly:" to make sure that I understand correctly. Please tell me if I get anything wrong. Jul 26 11:20:51 yes. The solution could be to push new uClibc somewhere else. Jul 26 11:21:25 You're saying that the .mk file for each package, will have an ifdef that switches between building with the existing crosstool glibc toolchain, and an alternate buildroot uclibc toolchain. Jul 26 11:21:54 no Jul 26 11:22:35 ok, please explain the ifdef uclibc again for me. Jul 26 11:23:32 (I think it is ok to have a new wl500g-uclibc-oleg feed which is completely incompatible with the old wl500g feed) Jul 26 11:24:38 I just say that in .mk files ifeq ($(OPTWARE_LIB), uclibc) could be used when needed or ifeq ($(OPTWARE_TARGET),uclibc) Jul 26 11:25:23 which is better? Jul 26 11:26:56 well, we currently have $(GNU_TARGET_NAME) which holds that information (plus some more) Jul 26 11:27:17 but we would create a $(TARGET_LIBSTYLE) or something like that. Jul 26 11:27:41 but what if two different targets need two different versions of uclibc to work? Jul 26 11:27:57 Should there be OPTWARE_UCLIBC_FIRMWARE describing uclibc or glibc? Jul 26 11:28:10 and then the .mk file for a package needs to do different things for those two different versions of uclibc? Jul 26 11:28:44 I don't understand what OPTWARE_UCLIBC_FIRMWARE means. Jul 26 11:29:18 mistake. I've ment OPTWARE_UCLIBC_FIRMWARE=dd-wrt for example. Jul 26 11:30:06 We currently have OPTWARE_TARGET, which is a mnemonic for the combination of a MACHINE (nslu2, mss, wl500g), a library style (glibc, uclibc), and versions of gcc, glibc (or uclibc), and binutils. Jul 26 11:30:40 (i.e. each OPTWARE_TARGET currently has a CROSS_CONFIGURATION variable defined. Jul 26 11:30:43 Isnt it $(GNU_TARGET_NAME) Strict GNU naming without room for firmware name. Jul 26 11:31:09 correct. we wouldn't be able to change GNU_TARGET_NAME Jul 26 11:31:40 what is GNU_TARGET_NAME for the new wl500g feed binaries? Jul 26 11:32:57 mipsel-linux-uclibc Jul 26 11:33:17 really? Jul 26 11:33:31 if you look into trunk/toolchain/buildroot/build_mipsel/staging_dir/bin binaries Jul 26 11:34:39 hmm, I see. Jul 26 11:34:45 and all mipsel-linux-* are relinked to mipsel-linux-uclibc-* Jul 26 11:35:15 we would need to have a TARGET_FIRMWARE variable to indicate the firmware (in case you can use the same firmware on two different machines, and you need to do the same thing in a .mk file for that firmware irrespective of which machine the firmware is running on) Jul 26 11:36:47 Is there any chance of making buildroot install into $(TOOL_BUILD_DIR)/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/bin ... ? Jul 26 11:36:53 TARGET_FIRMARE var should not occur in .mk files except in buildroot.mk Jul 26 11:37:40 TARGET_FIRMWARE might be used, for instance, when init files need to be put in a different place for unslung vs oleg vs ddwrt vs openwrt - so it is used in the .mk file for a package Jul 26 11:37:55 why would TARGET_FIRMWARE be used in buildroot.mk? Jul 26 11:38:25 All configuration of buildroot.mk should be done in the top-level Makefile (just before the toolchain target where all the CROSS_CONFIGURATION and TARGET_CROSS variables are defined) Jul 26 11:38:57 In particular, the first three lines of buildroot.mk should be moved to the top-level optware Makefile Jul 26 11:39:01 right. Jul 26 11:39:43 apart from the linux headers, is there anywhere else in buildroot.mk where the target firmware is needed to be known? Jul 26 11:40:15 huh. At present this three lines are only informational for building .ipk Jul 26 11:40:31 BUILDROOT_GCC=3.4.6 Jul 26 11:40:31 BUILDROOT_BINUTILS=2.16.1 Jul 26 11:40:31 UCLIBC_VERSION=0.9.28 Jul 26 11:40:43 those three should be in top-level Makefile, not in buildroot.mk Jul 26 11:40:53 So you can define them differently for different targets Jul 26 11:40:54 maybe BUILDROOT_GCC:=3.4.6 would be beter for override. Jul 26 11:41:38 e.g.: Jul 26 11:41:39 Right now they are pretty useless. Jul 26 11:41:41 CROSS_CONFIGURATION_GCC_VERSION=3.4.6 Jul 26 11:41:42 CROSS_CONFIGURATION_UCLIBC_VERSION=0.9.28 Jul 26 11:41:42 CROSS_CONFIGURATION_GCC=gcc-$(CROSS_CONFIGURATION_GCC_VERSION) Jul 26 11:41:42 CROSS_CONFIGURATION_UCLIBC=uclibc-$(CROSS_CONFIGURATION_UCLIBC_VERSION) Jul 26 11:41:42 CROSS_CONFIGURATION = $(CROSS_CONFIGURATION_GCC)-$(CROSS_CONFIGURATION_UCLIBC) Jul 26 11:42:44 then buildroot.mk uses those variables that have been defined at the top level Jul 26 11:43:56 Ok. I understand this. And there should be TARGET_FIRMWARE also with default generic to include 2.4.25 headers. Jul 26 11:44:04 yes Jul 26 11:45:29 THis engineering, except for naming is already in buildroot. I am using BUILDROOT_CUSTOM_HEADERS variable for TARGET_FIRMWARE Jul 26 11:46:08 yes, but you are selecting HEADERS_OLEG in buildroot.mk instead of in the top-level Optware Makefile. Jul 26 11:46:19 the top-level should make the decision, and then just tell buildroot what to do. Jul 26 11:46:36 I agree all the plumbing is there - just some decisions need to be moved up one level. Jul 26 11:46:37 yes, yes. Jul 26 11:47:30 perhaps there should be a linux-libc-headers.mk which stages the correct headers based on TARGET_FIRMWARE ... Jul 26 11:47:43 then buildroot.mk just uses whatever headers have been staged for it. Jul 26 11:48:16 and the top-level toolchain target then just depends on linux-libc-headers and buildroot Jul 26 11:48:30 (or, for glibc stuff, on crosstool) Jul 26 11:48:59 this would split buildroot.mk . Jul 26 11:49:44 yes. Note that other packages may need linux headers - that is the reason for the split. Jul 26 11:50:07 linux-libc-headers-ipk isn't really needed but buildroot-ipk is complete package for native compilation. Jul 26 11:50:59 does buildroot-ipk include the headers or not? Jul 26 11:51:13 yes Jul 26 11:51:23 I think so. Jul 26 11:53:21 There is opt/include/linux directory in buidroot-ipk Jul 26 11:53:43 So why can't it just depend on linux-libc-headers-ipk which installs them? Jul 26 11:55:24 It can be this way. Cross tool for example downloads the wole linux and use just headers. Jul 26 11:55:32 (run-time depend, as well as compile-time depend) Jul 26 11:56:43 ok, for the cross-compilation case, can we install the resulting toolchain which will be used to compile all the packages under $(TOOL_BUILD_DIR)/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/bin ... ? Jul 26 11:56:44 But as I've saw Oleg headers ane not the stock one. Same goes to dd-wrt. Jul 26 11:57:01 i.e. just like we do currently for the crosstool case? Jul 26 11:58:25 not sure that this is the right way for cross tool too? Jul 26 11:58:53 it means that you can test a new version of the toolchain for some packages, while still building all the other packages with the old version. Jul 26 11:59:24 back in a bit, need to get my 1.5yr old daughter back to sleep Jul 26 11:59:26 ... Jul 26 12:04:23 $(TOOL_BUILD_DIR)/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/bin cannot be implemented easily. But it can be $(TOOL_BUILD_DIR)/buildroot/build_$(TARGET_ARCH)-gcc-3.4.6-uclibc-0.9.28/staging_dir/bin/ Jul 26 12:09:42 and then symlinked if needed Jul 26 12:13:31 ok, back Jul 26 12:14:22 but then maybe it can be set up this way. I'am jus testing this right now. Jul 26 12:17:48 as long as it has $(GNU_TARGET_NAME) and $(CROSS_CONFIGURATION) in it somewhere, then just make it as close as can be. It should be at the top-level of toolchain if possible, not under the buildroot dir. Jul 26 12:18:37 ok, now for optware_target names. Jul 26 12:18:53 so far so good with building with new scheme Jul 26 12:19:33 nslu2 -> nslu2-glibc-unslung Jul 26 12:20:00 wl500g -> wl500g-stock-oleg Jul 26 12:20:09 nslu2 -> nslu2-stock-unslung Jul 26 12:20:23 then new wl500g is called wl500g-uclibc-oleg Jul 26 12:20:39 or wl500g-uclibc-ddwrt Jul 26 12:21:07 not following this scheme. Jul 26 12:21:10 "stock" means whatever libc the vendor uses Jul 26 12:21:21 "uclibc" means the new uclibc toolchain based on buildroot Jul 26 12:21:32 glibc means the crosstool glibc toolchain Jul 26 12:21:47 so it's -- Jul 26 12:22:09 OPTWARE_TARGET=nslu2-stock-unslung Jul 26 12:22:12 I do not want long target names for OPTWARE_TARGET Jul 26 12:22:46 but OPTWARE_TARGET is used primarily to distinguish the resulting feeds Jul 26 12:23:04 so how do you distinguish wl500g with oleg from wl500g with ddwrt? Jul 26 12:23:24 Can we first introduce target OPTWARE_TARGET=uclibc and then subverion feed fit TARGET_FIRMWARE? Jul 26 12:24:17 not easily, cause it needs to be driven from the autobuild scripts, so they need a single target to hit for each feed. Jul 26 12:24:35 (they currently use OPTWARE_TARGET for that) Jul 26 12:25:43 I see. Jul 26 12:25:47 you still need the machine name in the OPTWARE_TARGET anyway, cause you can't use the same feed for wl500g-uclibc and mss-uclibc Jul 26 12:26:53 how about [-[-]] Jul 26 12:27:30 so we have nslu2, wl500g, wl500g-uclibc-oleg, wl500g-uclibc-ddwrt, wrt54g-uclibc-ddwrt, wrt54g-uclibc-openwrt, ... Jul 26 12:27:33 looks better. But this long names are hard to remember. Jul 26 12:28:03 and to include in ifdef($(OPTWARE_TARGET)) Jul 26 12:28:35 well, instead of switching on OPTWARE_TARGET, you would switch on OPTWARE_MACHINE, OPTWARE_LIBC, or OPTWARE_FIRMWARE ... Jul 26 12:28:54 (which are defined in the top-level Makefile, based on OPTWARE_TARGET) Jul 26 12:29:38 either that, or we leave OPTWARE_TARGET to mean the machine, and add a new OPTWARE_FEED which combines OPTWARE_TARGET, OPTWARE_LIBC and OPTWARE_FIRMWARE ... Jul 26 12:29:40 ok. Understand. Jul 26 12:31:00 I prefer OPTWARE_TARGET to be the final configuration. Jul 26 12:31:08 we issuse make OPTWARE_TARGET=uclibc-dd-wrt Jul 26 12:31:46 no, we issue "make OPTWARE_TARGET=nslu2" or "make OPTWARE_TARGET=wl500g-uclibc-oleg" Jul 26 12:32:19 or "make OPTWARE_TARGET=wl500g-uclibc-ddwrt" Jul 26 12:32:58 wl500g is somewhat missleading with dd-wrt Jul 26 12:33:08 why? Jul 26 12:33:23 there would be a separate "make TARGET=wrt54g-uclibc-ddwrt" Jul 26 12:33:36 it is better make OPTWARE_TARGET=brcm-uclibc-ddwrt Jul 26 12:34:09 because dd-wrt runs on WRT, Bufallo, Asus, ... Jul 26 12:34:19 what if there are package modifications required depending if ddwrt is on each different machine? Jul 26 12:35:52 At present only Broadcom is supported, with provisions of mikrotik routerboards. Jul 26 12:36:22 i.e. a package might need to be configured differently depending on whether it is running on ddwrt on wrt or ddwrt on asus, due to hardware differences. Jul 26 12:36:54 so the hardware name must be in the optware_target definition, as well as the firwmare name (if there is more than one optware supported firmware for that hardware) Jul 26 12:37:55 yes. You are right. But for optware this is not the case and we are not building kernel modules and so. So I think that boader name coverage is appropriate. Jul 26 12:38:35 what about a routing package which needs to know whether the hardware has eth0 or eth0 and eth1 or ixp0 ? Jul 26 12:39:16 (and needs to install a different configuration file for the user based on that information) Jul 26 12:39:38 This could be the case. Solved by ipkg maybe. Jul 26 12:40:11 could possibly be done by a very smart postinstall script which interrogates the hardware. Jul 26 12:40:42 but we intentionally did nslu2, ds101, etc .. instead of a generic ixp4xx optware target. Jul 26 12:41:05 Or very smart end user. Jul 26 12:41:15 if two feeds turn out to be identical, then we just symlink them Jul 26 12:41:41 optware packages are intended to always install with a default configuration that works out of the box Jul 26 12:41:57 (we don't always achieve that goal, but that's the goal) Jul 26 12:42:08 so? Can we live with OPTWARE_TARGET=uclibc-oleg then? Jul 26 12:42:55 no, cause wlhdd-uclibc-oleg might need different packages to wl500g-uclibc-oleg or wl700g-uclibc-oleg Jul 26 12:43:41 if we didn't want the machine, we would just say unslung-glibc or oleg-uclibc Jul 26 12:44:40 we are going through this exercise cause the original naming scheme for wl500g is not powerful enough. let's not make ourselves go through it again later for the sake of shorter names now. Jul 26 12:44:53 I do not see the case with different packages for wl500g-uclibc-oleg and wl700g-uclibc-oleg Jul 26 12:46:07 I don't have a wl700g, so am only surmising there. Jul 26 12:46:30 But my gut feel (based on two years experience in this project) is that the machine is needed. Jul 26 12:46:31 The case would be only if oleg changed to new kernel. Then we would call this oleg2. Jul 26 12:47:21 machine names expires. There is nslu3 in the way! Jul 26 12:47:46 take openwrt as an example. can you guarantee that packages for wl500g-uclibc-openwrt will run unchanged out of the box on wrt54g-uclibc-openwrt or mn700-uclibc-openwrt? Jul 26 12:48:27 all the more reason to have the machine name. if nslu2 packages work on nslu3, then it's just a symlink in the feeds dir. if they don't then you need nslu3-glibc-unslung Jul 26 12:48:32 yes. Jul 26 12:49:45 Optware was designed to be the vendor-firmware-compatible package repository. So the naming is based on the hardware (where a certain hardware only has one vendor firmware). Jul 26 12:50:34 Now we are extending Optware to be used for custom non-vendor-compatible firmware (like dd-wrt or openwrt) and custom non-vendor-compatible libc (like the new uclibc) Jul 26 12:52:13 So optware naming is based on hardware (using the name that the consumers understand - i.e. wrt54g, not brcm) first, and then for that hardware which has multiple non-vendor-compatible firmware or libc, the name gets longer with those variables appended. Jul 26 12:52:46 if multiple devices really can use the same feed, then it is just a symlink in the feeds directory (no need to compile the packages twice) Jul 26 12:52:53 I do not want the naming which says: Wh have two new machines wl500gP an wl550gE and only one Optware aware firmware which is the same for both and we will call it "wl500g" Jul 26 12:53:43 why not? that is what a user of the wl500gP or wl500gE would be looking for Jul 26 12:54:00 Most of the users do not know about Broadcom, and quite a few will not know Oleg's name/ Jul 26 12:54:08 I would rather say that "oleg" is the firmware and packages are for both. Jul 26 12:54:32 sorry, no. oleg can be appended, but the machine name must be in there. Jul 26 12:55:58 as soon as oleg creates new firmware for a completely different device, then a naming scheme with only machine or only firmware breaks down Jul 26 12:55:58 dd-wrt support at least 20 machines. Oleg supports 7 of them. Jul 26 12:56:36 ok, how about this: Jul 26 12:56:59 for vendor-firmware-compatible optware targets, we use the machine name (and nothing else is required). Jul 26 12:57:01 All dd-wrt and Oleg firmwares are the same looking from Optware point. Jul 26 12:57:27 for custom-firmware optware targets, we use the firmware name (and nothing else is required). Jul 26 12:57:45 so we have nslu2, wl500g, oleg and ddwrt as the optware targets. Jul 26 12:58:23 OK. Jul 26 12:59:25 ok, let's go ahead with that and see how it looks. Jul 26 13:00:27 Then we stick with naming OPTWARE_TARGET=dd-wrt and then set OPTWARE_LIB and so on Jul 26 13:02:04 It look like trunk/toolchain/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/ is possible and will be introduced today. Jul 26 13:12:14 yep. good. Jul 26 13:12:17 night oleo Jul 26 13:13:07 (BTW, what you call the trunk directory, I call /home/slug/optware/nslu2, cause that's where the MasterMakefile puts it). Jul 26 13:13:49 (replace 'nslu2' with OPTWARE_TARGET in each case) Jul 26 13:14:03 * rwhitby goes to bed Jul 26 13:18:29 bye Jul 26 15:27:24 03oleo * r3662 10optware/trunk/make/buildroot.mk: buildroot: add gcc and binutils config handling, move staging_dir location to toolchain/ Jul 26 22:13:31 03gda * r3663 10optware/trunk/make/postfix.mk: postfix: depends on ipk findutils not on the command find **** ENDING LOGGING AT Thu Jul 27 02:59:56 2006