| 00:16.50 | *** join/#nslu2-linux yvasilev (n=yvasilev@201.102.140.70) |
| 00:48.51 | oleo | How long will take this postfix testing? |
| 02:21.46 | *** join/#nslu2-linux jacques (n=jacques@71.30.174.205) |
| 02:27.18 | *** join/#nslu2-linux afs2 (i=afs@h-67-101-107-247.lsanca54.dynamic.covad.net) |
| 02:43.09 | *** join/#nslu2-linux mithro (n=tim@lester.mithis.com) |
| 03:07.51 | afs2 | hmm, anyone here? |
| 03:09.41 | NAiL | sometimes ;) |
| 03:10.01 | afs2 | hmm, has anyone got lm-sensors to compile natively? |
| 03:10.28 | NAiL | slugos or unslung? |
| 03:10.40 | afs2 | unslung |
| 03:10.42 | NAiL | I got it to compile on openslug long ago IIRC |
| 03:11.03 | afs2 | hm, probably should just switch to openslung then |
| 03:12.28 | NAiL | you got *nix experience? :) |
| 03:12.43 | afs2 | enough to compile something... heh |
| 03:13.15 | afs2 | or get around |
| 03:13.45 | afs2 | all i really want is to get this temperature sensor i've connected via i2c to work |
| 03:14.17 | NAiL | well, it is a bit more likely you'll succeed with openslug/debianslug |
| 03:14.31 | NAiL | it's 05:15 :P |
| 03:14.55 | afs2 | lol, night |
| 03:15.04 | afs2 | er, morning |
| 04:01.20 | *** join/#nslu2-linux DrZimmerman (n=theo@84-72-116-112.dclient.hispeed.ch) |
| 04:07.39 | *** join/#nslu2-linux gDx (n=Sinclair@p54A0926F.dip0.t-ipconnect.de) |
| 05:17.35 | *** join/#nslu2-linux mithro (n=tim@lester.mithis.com) |
| 05:35.27 | *** join/#nslu2-linux jacques (n=jacques@cpe-66-69-157-96.houston.res.rr.com) |
| 06:05.03 | *** join/#nslu2-linux l0c4lh0st (n=a@f178138.upc-f.chello.nl) |
| 06:34.37 | oleo | rwhitby, We can talk about buildroot integration for new targets, if you've read my recent email. |
| 07:15.37 | rwhitby | oleo: at work at the moment - will you be around in about three hours? |
| 07:17.11 | CIA-6 | 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 |
| 07:27.20 | CIA-6 | 03oleo * r3660 10optware/trunk/Makefile: |
| 07:27.22 | CIA-6 | optware: WL500G promote ctcs cvs enhanced-ctorrent libgc metalog nail py-axiom |
| 07:27.24 | CIA-6 | py-epsilon py-lxml py-mantissa py-nevow py-paste py-psycopg2 py-twisted |
| 07:27.26 | CIA-6 | unslung-devel and demote postfix - WL_500G_BROKEN_PACKAGES searched from scratch |
| 07:27.36 | *** join/#nslu2-linux philpem (n=philpem@81-86-139-157.dsl.pipex.com) |
| 07:28.28 | oleo | rwhitby, OK |
| 07:43.41 | rwhitby | oleo: ping |
| 07:47.13 | oleo | rwhitby Gu |
| 07:47.41 | oleo | yes. |
| 07:50.07 | rwhitby | oleo: see private message in other window |
| 07:50.15 | oleo | huh. Not a BitchX guru. Instruct me how to open it |
| 07:50.23 | rwhitby | oh, are you registered with FreeNode? |
| 07:50.35 | rwhitby | i.e. can you "/msg rwhitby foo" ? |
| 07:50.44 | oleo | yes |
| 07:51.07 | rwhitby | have you logged in to NickServ? |
| 07:51.46 | rwhitby | ah, you need to "/msg nickserv identify oleo <password>" |
| 07:52.06 | oleo | it looks like I am not registered. But I have nick reserved. |
| 07:52.52 | rwhitby | "/msg nickserv register oleo <password>" |
| 08:24.40 | *** join/#nslu2-linux kolla_ (n=kolla@eduroam-dhcp10.uninett.no) |
| 08:41.54 | *** join/#nslu2-linux kolla__ (i=kolla@firda.uninett.no) |
| 08:45.54 | *** join/#nslu2-linux kolla__ (i=kolla@firda.uninett.no) |
| 09:34.31 | *** join/#nslu2-linux rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 09:38.11 | *** join/#nslu2-linux mithro (n=tim@ppp246-117.static.internode.on.net) |
| 09:56.25 | *** join/#nslu2-linux bullet (n=bullet@213.27.79.83.cust.bluewin.ch) |
| 10:10.59 | *** join/#nslu2-linux ChanServ (ChanServ@services.) |
| 10:10.59 | *** mode/#nslu2-linux [+o ChanServ] by irc.freenode.net |
| 10:15.00 | *** join/#nslu2-linux EvilDevil_ (n=miau@p54A6D1BC.dip.t-dialin.net) |
| 10:18.50 | rwhitby | oleo: ping |
| 10:35.19 | CIA-6 | 03rwhitby * r3661 10optware/trunk/make/crosstool.mk: crosstool: fixed dirclean target |
| 10:40.29 | *** join/#nslu2-linux vmaster_ (i=vmaster@p549B7A73.dip.t-dialin.net) |
| 10:43.37 | *** join/#nslu2-linux kfm (n=kfm82@p54BED753.dip.t-dialin.net) |
| 11:12.42 | oleo | rwhitby pong |
| 11:13.00 | rwhitby | oleo: I've started to look at the buildroot work. Very nice work! |
| 11:13.23 | rwhitby | We can start experimenting in place with a new wrt54g target, right? |
| 11:13.38 | rwhitby | (I'm building buildroot right now) |
| 11:14.14 | *** join/#nslu2-linux philpem (n=philpem@81-86-139-157.dsl.pipex.com) |
| 11:14.15 | oleo | yes. Target naming is in question here. |
| 11:14.42 | rwhitby | so we have existing wl500g, and we have new wl500g and new wrt54g. is that correct? are there any other options? |
| 11:15.26 | rwhitby | 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? |
| 11:15.29 | oleo | Options? nslu2, Openwrt, ... To my testing it can coexist with glibc. |
| 11:16.02 | rwhitby | So you're saying that buildroot can replace crosstool for all existing targets too? |
| 11:16.14 | oleo | yes |
| 11:16.27 | rwhitby | what is the main difference between a new wl500g target and a new wrt54g target? |
| 11:16.56 | oleo | just linux-headers. |
| 11:17.15 | rwhitby | Does that affect the resulting binaries? |
| 11:17.40 | oleo | But this is not a cruical point. I would also like to get this answer. |
| 11:18.35 | rwhitby | what would you call the options if you had to give them really long names (my question above)? |
| 11:18.47 | oleo | I've think of binary comparing resulting ipkg to see percentage of affected apps. |
| 11:19.42 | oleo | nslu2-armeb-uclibc-linux |
| 11:20.34 | rwhitby | is the final -linux necessary? |
| 11:21.02 | oleo | I have little experience with this multiple platforms building. |
| 11:21.20 | oleo | s/platform/targets/ |
| 11:21.32 | rwhitby | ok, so let's look at this from a feeds perspective too |
| 11:21.57 | rwhitby | we currently have feeds/optware/{nslu2,wl500g,...}/{stable,unstable} |
| 11:22.12 | rwhitby | however, unstable is just a symlink to stable in all cases at the moment |
| 11:23.10 | rwhitby | what would the new long names be for the existing wl500g feed, compared to the new wl500g feed? |
| 11:23.49 | oleo | this is not a good engineering as I have two different uClibc which will be messed with ifeq statements in .mk files |
| 11:24.29 | rwhitby | So some packages will be built with one version of uclibc, and others will be built with a different version? |
| 11:24.29 | oleo | I think its better to name it by firmware. |
| 11:24.52 | *** join/#nslu2-linux drif (n=drif@82-203-186-106.dsl.gohome.fi) |
| 11:25.25 | rwhitby | well, the current wl500g feed is for oleg's firmware, as is the new wl500g feed based on buildroot ... |
| 11:25.52 | rwhitby | 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 |
| 11:26.09 | oleo | It looks like. I've asked Oleg several times to upgrade to latest. But hi is unwilling to include full feature uClibc support. |
| 11:26.43 | rwhitby | even if Oleg was willing to upgrade (and I understand his reasoning), then there would still be people with old firmware versions. |
| 11:27.27 | oleo | I think to leave wl500g as is and introduce new targets in some smart way. |
| 11:27.32 | rwhitby | 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? |
| 11:27.43 | oleo | yes. |
| 11:27.45 | rwhitby | s/wl500gx/wl500g/ |
| 11:28.16 | oleo | but with old uClibc we are unable to support many apps. |
| 11:28.36 | rwhitby | but you are right, we also need the firmware name in there, so there can be optware packages on wl500g-openwrt ... |
| 11:29.12 | rwhitby | although I am hesitant to support multiple firmware targets for each device ... |
| 11:29.44 | rwhitby | Optware is meant to be for the vendor-compatible firmware. OpenWRT is not really a valid Optware target. |
| 11:30.21 | oleo | 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. |
| 11:30.23 | rwhitby | (unless the charter of Optware changes ...) |
| 11:31.09 | rwhitby | can you explain that last sentence more? I'm not sure I fully understand. |
| 11:32.38 | oleo | I suggest uclibc target as this is firmware independent. Only uclibc and buildroot will be compiled separately for target firmware. |
| 11:32.52 | oleo | More clearly: |
| 11:33.18 | oleo | .mk files will have ifdef(uclibc only. |
| 11:34.38 | oleo | 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 |
| 11:36.12 | oleo | Unfortunate case of wl500g with old uClibc will remain as is. |
| 11:37.05 | oleo | Or will be replaced with uclibc when compiles on both. |
| 11:38.21 | rwhitby | how many packages compile with old uClibc toolchain, but do not compile with new buildroot uClibc toolchain? |
| 11:38.31 | oleo | none |
| 11:39.08 | rwhitby | So every wl500g package in the existing feed can be replaced with a new version that depends on a uclibc runtime being installed? |
| 11:39.21 | oleo | yes |
| 11:39.25 | rwhitby | (and in fact, you can mix and match from old feed and new feed)? |
| 11:40.10 | rwhitby | (cause old feed binaries use the oleg libs and new feed binaries use the new libs ...) |
| 11:40.12 | oleo | feeds cannod be mixed as many "old" wl500g have -rpath/opt/lib precompiled |
| 11:40.13 | rwhitby | is that correct? |
| 11:40.52 | rwhitby | 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. |
| 11:41.45 | rwhitby | 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. |
| 11:41.47 | oleo | yes. The solution could be to push new uClibc somewhere else. |
| 11:42.21 | rwhitby | 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. |
| 11:42.50 | oleo | no |
| 11:43.31 | rwhitby | ok, please explain the ifdef uclibc again for me. |
| 11:44.28 | rwhitby | (I think it is ok to have a new wl500g-uclibc-oleg feed which is completely incompatible with the old wl500g feed) |
| 11:45.34 | oleo | I just say that in .mk files ifeq ($(OPTWARE_LIB), uclibc) could be used when needed or ifeq ($(OPTWARE_TARGET),uclibc) |
| 11:46.18 | oleo | which is better? |
| 11:47.52 | rwhitby | well, we currently have $(GNU_TARGET_NAME) which holds that information (plus some more) |
| 11:48.14 | rwhitby | but we would create a $(TARGET_LIBSTYLE) or something like that. |
| 11:48.37 | rwhitby | but what if two different targets need two different versions of uclibc to work? |
| 11:48.52 | oleo | Should there be OPTWARE_UCLIBC_FIRMWARE describing uclibc or glibc? |
| 11:49.06 | rwhitby | and then the .mk file for a package needs to do different things for those two different versions of uclibc? |
| 11:49.41 | rwhitby | I don't understand what OPTWARE_UCLIBC_FIRMWARE means. |
| 11:50.14 | oleo | mistake. I've ment OPTWARE_UCLIBC_FIRMWARE=dd-wrt for example. |
| 11:51.02 | rwhitby | 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. |
| 11:51.36 | rwhitby | (i.e. each OPTWARE_TARGET currently has a CROSS_CONFIGURATION variable defined. |
| 11:51.39 | oleo | Isnt it $(GNU_TARGET_NAME) Strict GNU naming without room for firmware name. |
| 11:52.05 | rwhitby | correct. we wouldn't be able to change GNU_TARGET_NAME |
| 11:52.36 | rwhitby | what is GNU_TARGET_NAME for the new wl500g feed binaries? |
| 11:53.53 | oleo | mipsel-linux-uclibc |
| 11:54.13 | rwhitby | really? |
| 11:54.27 | oleo | if you look into trunk/toolchain/buildroot/build_mipsel/staging_dir/bin binaries |
| 11:55.39 | rwhitby | hmm, I see. |
| 11:55.41 | oleo | and all mipsel-linux-* are relinked to mipsel-linux-uclibc-* |
| 11:56.11 | rwhitby | 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) |
| 11:57.43 | rwhitby | Is there any chance of making buildroot install into $(TOOL_BUILD_DIR)/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/bin ... ? |
| 11:57.49 | oleo | TARGET_FIRMARE var should not occur in .mk files except in buildroot.mk |
| 11:58.37 | rwhitby | 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 |
| 11:58.51 | rwhitby | why would TARGET_FIRMWARE be used in buildroot.mk? |
| 11:59.22 | rwhitby | 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) |
| 11:59.53 | rwhitby | In particular, the first three lines of buildroot.mk should be moved to the top-level optware Makefile |
| 11:59.57 | oleo | right. |
| 12:00.39 | rwhitby | apart from the linux headers, is there anywhere else in buildroot.mk where the target firmware is needed to be known? |
| 12:01.11 | oleo | huh. At present this three lines are only informational for building .ipk |
| 12:01.27 | *** join/#nslu2-linux l0c4lh0st (n=a@f178138.upc-f.chello.nl) |
| 12:01.27 | rwhitby | BUILDROOT_GCC=3.4.6 |
| 12:01.27 | rwhitby | BUILDROOT_BINUTILS=2.16.1 |
| 12:01.27 | rwhitby | UCLIBC_VERSION=0.9.28 |
| 12:01.39 | rwhitby | those three should be in top-level Makefile, not in buildroot.mk |
| 12:01.49 | rwhitby | So you can define them differently for different targets |
| 12:01.50 | oleo | maybe BUILDROOT_GCC:=3.4.6 would be beter for override. |
| 12:02.34 | rwhitby | e.g.: |
| 12:02.35 | oleo | Right now they are pretty useless. |
| 12:02.37 | rwhitby | CROSS_CONFIGURATION_GCC_VERSION=3.4.6 |
| 12:02.38 | rwhitby | CROSS_CONFIGURATION_UCLIBC_VERSION=0.9.28 |
| 12:02.38 | rwhitby | CROSS_CONFIGURATION_GCC=gcc-$(CROSS_CONFIGURATION_GCC_VERSION) |
| 12:02.38 | rwhitby | CROSS_CONFIGURATION_UCLIBC=uclibc-$(CROSS_CONFIGURATION_UCLIBC_VERSION) |
| 12:02.38 | rwhitby | CROSS_CONFIGURATION = $(CROSS_CONFIGURATION_GCC)-$(CROSS_CONFIGURATION_UCLIBC) |
| 12:03.40 | rwhitby | then buildroot.mk uses those variables that have been defined at the top level |
| 12:04.52 | oleo | Ok. I understand this. And there should be TARGET_FIRMWARE also with default generic to include 2.4.25 headers. |
| 12:05.01 | rwhitby | yes |
| 12:06.25 | oleo | THis engineering, except for naming is already in buildroot. I am using BUILDROOT_CUSTOM_HEADERS variable for TARGET_FIRMWARE |
| 12:07.04 | rwhitby | yes, but you are selecting HEADERS_OLEG in buildroot.mk instead of in the top-level Optware Makefile. |
| 12:07.15 | rwhitby | the top-level should make the decision, and then just tell buildroot what to do. |
| 12:07.32 | rwhitby | I agree all the plumbing is there - just some decisions need to be moved up one level. |
| 12:07.33 | oleo | yes, yes. |
| 12:08.27 | rwhitby | perhaps there should be a linux-libc-headers.mk which stages the correct headers based on TARGET_FIRMWARE ... |
| 12:08.39 | rwhitby | then buildroot.mk just uses whatever headers have been staged for it. |
| 12:09.12 | rwhitby | and the top-level toolchain target then just depends on linux-libc-headers and buildroot |
| 12:09.26 | rwhitby | (or, for glibc stuff, on crosstool) |
| 12:09.55 | oleo | this would split buildroot.mk . |
| 12:10.40 | rwhitby | yes. Note that other packages may need linux headers - that is the reason for the split. |
| 12:11.03 | oleo | linux-libc-headers-ipk isn't really needed but buildroot-ipk is complete package for native compilation. |
| 12:11.55 | rwhitby | does buildroot-ipk include the headers or not? |
| 12:12.09 | oleo | yes |
| 12:12.19 | oleo | I think so. |
| 12:14.17 | oleo | There is opt/include/linux directory in buidroot-ipk |
| 12:14.39 | rwhitby | So why can't it just depend on linux-libc-headers-ipk which installs them? |
| 12:16.10 | *** join/#nslu2-linux l0c4lh0st (n=a@f178138.upc-f.chello.nl) |
| 12:16.20 | oleo | It can be this way. Cross tool for example downloads the wole linux and use just headers. |
| 12:16.29 | rwhitby | (run-time depend, as well as compile-time depend) |
| 12:17.39 | rwhitby | 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 ... ? |
| 12:17.40 | oleo | But as I've saw Oleg headers ane not the stock one. Same goes to dd-wrt. |
| 12:17.57 | rwhitby | i.e. just like we do currently for the crosstool case? |
| 12:19.21 | oleo | not sure that this is the right way for cross tool too? |
| 12:19.49 | rwhitby | 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. |
| 12:20.20 | rwhitby | back in a bit, need to get my 1.5yr old daughter back to sleep |
| 12:20.22 | rwhitby | ... |
| 12:25.19 | oleo | $(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/ |
| 12:30.38 | oleo | and then symlinked if needed |
| 12:34.27 | rwhitby | ok, back |
| 12:35.18 | oleo | but then maybe it can be set up this way. I'am jus testing this right now. |
| 12:38.45 | rwhitby | 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. |
| 12:39.34 | rwhitby | ok, now for optware_target names. |
| 12:39.49 | oleo | so far so good with building with new scheme |
| 12:40.30 | rwhitby | nslu2 -> nslu2-glibc-unslung |
| 12:40.57 | rwhitby | wl500g -> wl500g-stock-oleg |
| 12:41.05 | rwhitby | nslu2 -> nslu2-stock-unslung |
| 12:41.20 | rwhitby | then new wl500g is called wl500g-uclibc-oleg |
| 12:41.35 | rwhitby | or wl500g-uclibc-ddwrt |
| 12:42.03 | oleo | not following this scheme. |
| 12:42.06 | rwhitby | "stock" means whatever libc the vendor uses |
| 12:42.18 | rwhitby | "uclibc" means the new uclibc toolchain based on buildroot |
| 12:42.29 | rwhitby | glibc means the crosstool glibc toolchain |
| 12:42.43 | rwhitby | so it's <machine>-<libc>-<firmware> |
| 12:43.05 | rwhitby | OPTWARE_TARGET=nslu2-stock-unslung |
| 12:43.08 | oleo | I do not want long target names for OPTWARE_TARGET |
| 12:43.43 | rwhitby | but OPTWARE_TARGET is used primarily to distinguish the resulting feeds |
| 12:44.00 | rwhitby | so how do you distinguish wl500g with oleg from wl500g with ddwrt? |
| 12:44.20 | oleo | Can we first introduce target OPTWARE_TARGET=uclibc and then subverion feed fit TARGET_FIRMWARE? |
| 12:45.14 | rwhitby | not easily, cause it needs to be driven from the autobuild scripts, so they need a single target to hit for each feed. |
| 12:45.31 | rwhitby | (they currently use OPTWARE_TARGET for that) |
| 12:46.39 | oleo | I see. |
| 12:46.44 | rwhitby | 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 |
| 12:47.49 | rwhitby | how about <machine>[-<libc>[-<firmware>]] |
| 12:48.26 | rwhitby | so we have nslu2, wl500g, wl500g-uclibc-oleg, wl500g-uclibc-ddwrt, wrt54g-uclibc-ddwrt, wrt54g-uclibc-openwrt, ... |
| 12:48.29 | oleo | looks better. But this long names are hard to remember. |
| 12:48.59 | oleo | and to include in ifdef($(OPTWARE_TARGET)) |
| 12:49.31 | rwhitby | well, instead of switching on OPTWARE_TARGET, you would switch on OPTWARE_MACHINE, OPTWARE_LIBC, or OPTWARE_FIRMWARE ... |
| 12:49.51 | rwhitby | (which are defined in the top-level Makefile, based on OPTWARE_TARGET) |
| 12:50.34 | rwhitby | 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 ... |
| 12:50.36 | oleo | ok. Understand. |
| 12:51.57 | rwhitby | I prefer OPTWARE_TARGET to be the final configuration. |
| 12:52.04 | oleo | we issuse make OPTWARE_TARGET=uclibc-dd-wrt |
| 12:52.43 | rwhitby | no, we issue "make OPTWARE_TARGET=nslu2" or "make OPTWARE_TARGET=wl500g-uclibc-oleg" |
| 12:53.15 | rwhitby | or "make OPTWARE_TARGET=wl500g-uclibc-ddwrt" |
| 12:53.54 | oleo | wl500g is somewhat missleading with dd-wrt |
| 12:54.05 | rwhitby | why? |
| 12:54.20 | rwhitby | there would be a separate "make TARGET=wrt54g-uclibc-ddwrt" |
| 12:54.32 | oleo | it is better make OPTWARE_TARGET=brcm-uclibc-ddwrt |
| 12:55.05 | oleo | because dd-wrt runs on WRT, Bufallo, Asus, ... |
| 12:55.15 | rwhitby | what if there are package modifications required depending if ddwrt is on each different machine? |
| 12:56.48 | oleo | At present only Broadcom is supported, with provisions of mikrotik routerboards. |
| 12:57.19 | rwhitby | 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. |
| 12:57.51 | rwhitby | 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) |
| 12:58.51 | oleo | 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. |
| 12:59.32 | rwhitby | what about a routing package which needs to know whether the hardware has eth0 or eth0 and eth1 or ixp0 ? |
| 13:00.12 | rwhitby | (and needs to install a different configuration file for the user based on that information) |
| 13:00.34 | oleo | This could be the case. Solved by ipkg maybe. |
| 13:01.08 | rwhitby | could possibly be done by a very smart postinstall script which interrogates the hardware. |
| 13:01.39 | rwhitby | but we intentionally did nslu2, ds101, etc .. instead of a generic ixp4xx optware target. |
| 13:02.01 | oleo | Or very smart end user. |
| 13:02.12 | rwhitby | if two feeds turn out to be identical, then we just symlink them |
| 13:02.38 | rwhitby | optware packages are intended to always install with a default configuration that works out of the box |
| 13:02.53 | rwhitby | (we don't always achieve that goal, but that's the goal) |
| 13:03.04 | oleo | so? Can we live with OPTWARE_TARGET=uclibc-oleg then? |
| 13:03.51 | rwhitby | no, cause wlhdd-uclibc-oleg might need different packages to wl500g-uclibc-oleg or wl700g-uclibc-oleg |
| 13:04.38 | rwhitby | if we didn't want the machine, we would just say unslung-glibc or oleg-uclibc |
| 13:05.37 | rwhitby | 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. |
| 13:05.49 | oleo | I do not see the case with different packages for wl500g-uclibc-oleg and wl700g-uclibc-oleg |
| 13:07.04 | rwhitby | I don't have a wl700g, so am only surmising there. |
| 13:07.26 | rwhitby | But my gut feel (based on two years experience in this project) is that the machine is needed. |
| 13:07.27 | oleo | The case would be only if oleg changed to new kernel. Then we would call this oleg2. |
| 13:08.17 | oleo | machine names expires. There is nslu3 in the way! |
| 13:08.42 | rwhitby | 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? |
| 13:09.24 | rwhitby | 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 |
| 13:09.29 | oleo | yes. |
| 13:10.42 | rwhitby | 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). |
| 13:11.31 | rwhitby | 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) |
| 13:13.10 | rwhitby | 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. |
| 13:13.43 | rwhitby | 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) |
| 13:13.49 | oleo | 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" |
| 13:14.40 | rwhitby | why not? that is what a user of the wl500gP or wl500gE would be looking for |
| 13:14.57 | rwhitby | Most of the users do not know about Broadcom, and quite a few will not know Oleg's name/ |
| 13:15.04 | oleo | I would rather say that "oleg" is the firmware and packages are for both. |
| 13:15.29 | rwhitby | sorry, no. oleg can be appended, but the machine name must be in there. |
| 13:16.55 | rwhitby | as soon as oleg creates new firmware for a completely different device, then a naming scheme with only machine or only firmware breaks down |
| 13:16.55 | oleo | dd-wrt support at least 20 machines. Oleg supports 7 of them. |
| 13:17.32 | rwhitby | ok, how about this: |
| 13:17.54 | rwhitby | for vendor-firmware-compatible optware targets, we use the machine name (and nothing else is required). |
| 13:17.57 | oleo | All dd-wrt and Oleg firmwares are the same looking from Optware point. |
| 13:18.23 | rwhitby | for custom-firmware optware targets, we use the firmware name (and nothing else is required). |
| 13:18.42 | rwhitby | so we have nslu2, wl500g, oleg and ddwrt as the optware targets. |
| 13:19.19 | oleo | OK. |
| 13:20.22 | rwhitby | ok, let's go ahead with that and see how it looks. |
| 13:21.24 | oleo | Then we stick with naming OPTWARE_TARGET=dd-wrt and then set OPTWARE_LIB and so on |
| 13:23.01 | oleo | It look like trunk/toolchain/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/ is possible and will be introduced today. |
| 13:33.10 | rwhitby | yep. good. |
| 13:33.15 | rwhitby | night oleo |
| 13:34.03 | rwhitby | (BTW, what you call the trunk directory, I call /home/slug/optware/nslu2, cause that's where the MasterMakefile puts it). |
| 13:34.46 | rwhitby | (replace 'nslu2' with OPTWARE_TARGET in each case) |
| 13:39.25 | oleo | bye |
| 15:42.29 | *** join/#nslu2-linux EvilDevil_ (n=miau@p54A6DBEE.dip.t-dialin.net) |
| 15:48.22 | CIA-6 | 03oleo * r3662 10optware/trunk/make/buildroot.mk: buildroot: add gcc and binutils config handling, move staging_dir location to toolchain/ |
| 17:24.19 | *** join/#nslu2-linux AdamBaker (n=aab@userch028.dsl.pipex.com) |
| 17:59.47 | *** join/#nslu2-linux blomma (n=blomma@c-199b72d5.014-202-6e6b701.cust.bredbandsbolaget.se) |
| 18:02.37 | *** join/#nslu2-linux blomma (n=blomma@c-199b72d5.014-202-6e6b701.cust.bredbandsbolaget.se) |
| 18:53.25 | *** join/#nslu2-linux caplink811-log (n=caplink8@dslb-088-073-123-138.pools.arcor-ip.net) |
| 18:59.35 | *** join/#nslu2-linux mithro (n=tim@ppp246-117.static.internode.on.net) |
| 19:10.26 | *** join/#nslu2-linux Blastur (i=Blastur@81-235-235-202-no92.tbcn.telia.com) |
| 20:29.43 | *** join/#nslu2-linux _kaenat (n=ringlej@va-65-40-217-47.sta.embarqhsd.net) |
| 20:36.40 | *** join/#nslu2-linux bullet (n=bullet@141.48.76.83.cust.bluewin.ch) |
| 20:40.01 | *** join/#nslu2-linux _kaenat (n=ringlej@va-65-40-217-47.sta.embarqhsd.net) |
| 21:02.51 | *** join/#nslu2-linux llagendijk (n=louis@lagendijk.xs4all.nl) |
| 22:23.05 | *** join/#nslu2-linux odoc (i=odoc@is.borntobooze.de) |
| 22:34.31 | CIA-6 | 03gda * r3663 10optware/trunk/make/postfix.mk: postfix: depends on ipk findutils not on the command find |
| 22:41.21 | *** part/#nslu2-linux odoc (i=odoc@is.borntobooze.de) |
| 23:42.03 | *** join/#nslu2-linux jbot_ (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 23:42.03 | *** topic/#nslu2-linux is nslu2-linux developer channel - use #nslu2-general for end-user questions |