irclog2html for #nslu2-linux on 20060726

00:16.50*** join/#nslu2-linux yvasilev (n=yvasilev@
00:48.51oleoHow long will take this postfix testing?
02:21.46*** join/#nslu2-linux jacques (n=jacques@
02:27.18*** join/#nslu2-linux afs2 (
02:43.09*** join/#nslu2-linux mithro (
03:07.51afs2hmm, anyone here?
03:09.41NAiLsometimes ;)
03:10.01afs2hmm, has anyone got lm-sensors to compile natively?
03:10.28NAiLslugos or unslung?
03:10.42NAiLI got it to compile on openslug long ago IIRC
03:11.03afs2hm, probably should just switch to openslung then
03:12.28NAiLyou got *nix experience? :)
03:12.43afs2enough to compile something... heh
03:13.15afs2or get around
03:13.45afs2all i really want is to get this temperature sensor i've connected via i2c to work
03:14.17NAiLwell, it is a bit more likely you'll succeed with openslug/debianslug
03:14.31NAiLit's 05:15 :P
03:14.55afs2lol, night
03:15.04afs2er, morning
04:01.20*** join/#nslu2-linux DrZimmerman (
04:07.39*** join/#nslu2-linux gDx (
05:17.35*** join/#nslu2-linux mithro (
05:35.27*** join/#nslu2-linux jacques (
06:05.03*** join/#nslu2-linux l0c4lh0st (
06:34.37oleorwhitby, We can talk about buildroot integration for new targets, if you've read my recent email.
07:15.37rwhitbyoleo: at work at the moment - will you be around in about three hours?
07:17.11CIA-603oleo * r3659 10optware/trunk/ (make/ 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.20CIA-603oleo * r3660 10optware/trunk/Makefile:
07:27.22CIA-6optware: WL500G promote ctcs cvs enhanced-ctorrent libgc metalog nail py-axiom
07:27.24CIA-6py-epsilon py-lxml py-mantissa py-nevow py-paste py-psycopg2 py-twisted
07:27.26CIA-6unslung-devel and demote postfix - WL_500G_BROKEN_PACKAGES searched from scratch
07:27.36*** join/#nslu2-linux philpem (
07:28.28oleorwhitby, OK
07:43.41rwhitbyoleo: ping
07:47.13oleorwhitby Gu
07:50.07rwhitbyoleo: see private message in other window
07:50.15oleohuh. Not a BitchX guru. Instruct me how to open it
07:50.23rwhitbyoh, are you registered with FreeNode?
07:50.35rwhitbyi.e. can you "/msg rwhitby foo" ?
07:51.07rwhitbyhave you logged in to NickServ?
07:51.46rwhitbyah, you need to "/msg nickserv identify oleo <password>"
07:52.06oleoit looks like I am not registered. But I have nick reserved.
07:52.52rwhitby"/msg nickserv register oleo <password>"
08:24.40*** join/#nslu2-linux kolla_ (
08:41.54*** join/#nslu2-linux kolla__ (
08:45.54*** join/#nslu2-linux kolla__ (
09:34.31*** join/#nslu2-linux rwhitby (n=rwhitby@nslu2-linux/rwhitby)
09:38.11*** join/#nslu2-linux mithro (
09:56.25*** join/#nslu2-linux bullet (
10:10.59*** join/#nslu2-linux ChanServ (ChanServ@services.)
10:10.59*** mode/#nslu2-linux [+o ChanServ] by
10:15.00*** join/#nslu2-linux EvilDevil_ (
10:18.50rwhitbyoleo: ping
10:35.19CIA-603rwhitby * r3661 10optware/trunk/make/ crosstool: fixed dirclean target
10:40.29*** join/#nslu2-linux vmaster_ (
10:43.37*** join/#nslu2-linux kfm (
11:12.42oleorwhitby pong
11:13.00rwhitbyoleo: I've started to look at the buildroot work.  Very nice work!
11:13.23rwhitbyWe can start experimenting in place with a new wrt54g target, right?
11:13.38rwhitby(I'm building buildroot right now)
11:14.14*** join/#nslu2-linux philpem (
11:14.15oleoyes. Target naming is in question here.
11:14.42rwhitbyso we have existing wl500g, and we have new wl500g and new wrt54g.  is that correct?  are there any other options?
11:15.26rwhitbyif 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.29oleoOptions? nslu2, Openwrt, ... To my testing it can coexist with glibc.
11:16.02rwhitbySo you're saying that buildroot can replace crosstool for all existing targets too?
11:16.27rwhitbywhat is the main difference between a new wl500g target and a new wrt54g target?
11:16.56oleojust linux-headers.
11:17.15rwhitbyDoes that affect the resulting binaries?
11:17.40oleoBut this is not a cruical point. I would also like to get this answer.
11:18.35rwhitbywhat would you call the options if you had to give them really long names (my question above)?
11:18.47oleoI've think of binary comparing resulting ipkg to see percentage of affected apps.
11:20.34rwhitbyis the final -linux necessary?
11:21.02oleoI have little experience with this multiple platforms building.
11:21.32rwhitbyok, so let's look at this from a feeds perspective too
11:21.57rwhitbywe currently have feeds/optware/{nslu2,wl500g,...}/{stable,unstable}
11:22.12rwhitbyhowever, unstable is just a symlink to stable in all cases at the moment
11:23.10rwhitbywhat would the new long names be for the existing wl500g feed, compared to the new wl500g feed?
11:23.49oleothis is not a good engineering as I have two different uClibc which will be messed with ifeq statements in .mk files
11:24.29rwhitbySo some packages will be built with one version of uclibc, and others will be built with a different version?
11:24.29oleoI think its better to name it by firmware.
11:24.52*** join/#nslu2-linux drif (
11:25.25rwhitbywell, the current wl500g feed is for oleg's firmware, as is the new wl500g feed based on buildroot ...
11:25.52rwhitbyso 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.09oleoIt looks like. I've asked Oleg several times to upgrade to latest. But hi is unwilling to include full feature uClibc support.
11:26.43rwhitbyeven if Oleg was willing to upgrade (and I understand his reasoning), then there would still be people with old firmware versions.
11:27.27oleoI think to leave wl500g as is and introduce new targets in some smart way.
11:27.32rwhitbyaren'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:28.16oleobut with old uClibc we are unable to support many apps.
11:28.36rwhitbybut you are right, we also need the firmware name in there, so there can be optware packages on wl500g-openwrt ...
11:29.12rwhitbyalthough I am hesitant to support multiple firmware targets for each device ...
11:29.44rwhitbyOptware is meant to be for the vendor-compatible firmware.  OpenWRT is not really a valid Optware target.
11:30.21oleothe 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.23rwhitby(unless the charter of Optware changes ...)
11:31.09rwhitbycan you explain that last sentence more?  I'm not sure I fully understand.
11:32.38oleoI suggest uclibc target as this is firmware independent. Only uclibc and buildroot will be compiled separately for target firmware.
11:32.52oleoMore clearly: files will have ifdef(uclibc only.
11:34.38oleoWhen autobuilding for firmware we say: prepare buildroot for this firmware and compile everything with it. This way firmwares will be hidden in
11:36.12oleoUnfortunate case of wl500g with old uClibc will remain as is.
11:37.05oleoOr will be replaced with uclibc when compiles on both.
11:38.21rwhitbyhow many packages compile with old uClibc toolchain, but do not compile with new buildroot uClibc toolchain?
11:39.08rwhitbySo every wl500g package in the existing feed can be replaced with a new version that depends on a uclibc runtime being installed?
11:39.25rwhitby(and in fact, you can mix and match from old feed and new feed)?
11:40.10rwhitby(cause old feed binaries use the oleg libs and new feed binaries use the new libs ...)
11:40.12oleofeeds cannod be mixed as many "old" wl500g have -rpath/opt/lib precompiled
11:40.13rwhitbyis that correct?
11:40.52rwhitbyah, 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.45rwhitbyI'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.47oleoyes. The solution could be to push new uClibc somewhere else.
11:42.21rwhitbyYou'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:43.31rwhitbyok, please explain the ifdef uclibc again for me.
11:44.28rwhitby(I think it is ok to have a new wl500g-uclibc-oleg feed which is completely incompatible with the old wl500g feed)
11:45.34oleoI just say that in .mk files ifeq ($(OPTWARE_LIB), uclibc) could be used when needed or ifeq ($(OPTWARE_TARGET),uclibc)
11:46.18oleowhich is better?
11:47.52rwhitbywell, we currently have $(GNU_TARGET_NAME) which holds that information (plus some more)
11:48.14rwhitbybut we would create a $(TARGET_LIBSTYLE) or something like that.
11:48.37rwhitbybut what if two different targets need two different versions of uclibc to work?
11:48.52oleoShould there be OPTWARE_UCLIBC_FIRMWARE describing uclibc or glibc?
11:49.06rwhitbyand then the .mk file for a package needs to do different things for those two different versions of uclibc?
11:49.41rwhitbyI don't understand what OPTWARE_UCLIBC_FIRMWARE means.
11:50.14oleomistake. I've ment OPTWARE_UCLIBC_FIRMWARE=dd-wrt for example.
11:51.02rwhitbyWe 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.36rwhitby(i.e. each OPTWARE_TARGET currently has a CROSS_CONFIGURATION variable defined.
11:51.39oleoIsnt it $(GNU_TARGET_NAME) Strict GNU naming without room for firmware name.
11:52.05rwhitbycorrect. we wouldn't be able to change GNU_TARGET_NAME
11:52.36rwhitbywhat is GNU_TARGET_NAME for the new wl500g feed binaries?
11:54.27oleoif you look into trunk/toolchain/buildroot/build_mipsel/staging_dir/bin binaries
11:55.39rwhitbyhmm, I see.
11:55.41oleoand all mipsel-linux-* are relinked to mipsel-linux-uclibc-*
11:56.11rwhitbywe 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.43rwhitbyIs 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.49oleoTARGET_FIRMARE var should not occur in .mk files except in
11:58.37rwhitbyTARGET_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.51rwhitbywhy would TARGET_FIRMWARE be used in
11:59.22rwhitbyAll configuration of 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.53rwhitbyIn particular, the first three lines of should be moved to the top-level optware Makefile
12:00.39rwhitbyapart from the linux headers, is there anywhere else in where the target firmware is needed to be known?
12:01.11oleohuh. At present this three lines are only informational for building .ipk
12:01.27*** join/#nslu2-linux l0c4lh0st (
12:01.39rwhitbythose three should be in top-level Makefile, not in
12:01.49rwhitbySo you can define them differently for different targets
12:01.50oleomaybe BUILDROOT_GCC:=3.4.6 would be beter for override.
12:02.35oleoRight now they are pretty useless.
12:03.40rwhitbythen uses those variables that have been defined at the top level
12:04.52oleoOk. I understand this. And there should be TARGET_FIRMWARE also with default generic to include 2.4.25 headers.
12:06.25oleoTHis engineering, except for naming is already in buildroot. I am using BUILDROOT_CUSTOM_HEADERS variable for TARGET_FIRMWARE
12:07.04rwhitbyyes, but you are selecting HEADERS_OLEG in instead of in the top-level Optware Makefile.
12:07.15rwhitbythe top-level should make the decision, and then just tell buildroot what to do.
12:07.32rwhitbyI agree all the plumbing is there - just some decisions need to be moved up one level.
12:07.33oleoyes, yes.
12:08.27rwhitbyperhaps there should be a which stages the correct headers based on TARGET_FIRMWARE ...
12:08.39rwhitbythen just uses whatever headers have been staged for it.
12:09.12rwhitbyand the top-level toolchain target then just depends on linux-libc-headers and buildroot
12:09.26rwhitby(or, for glibc stuff, on crosstool)
12:09.55oleothis would split .  
12:10.40rwhitbyyes.  Note that other packages may need linux headers - that is the reason for the split.
12:11.03oleolinux-libc-headers-ipk isn't really needed but buildroot-ipk is complete package for native compilation.
12:11.55rwhitbydoes buildroot-ipk include the headers or not?
12:12.19oleoI think so.
12:14.17oleoThere is opt/include/linux directory  in buidroot-ipk
12:14.39rwhitbySo why can't it just depend on linux-libc-headers-ipk which installs them?
12:16.10*** join/#nslu2-linux l0c4lh0st (
12:16.20oleoIt can be this way. Cross tool for example downloads the wole linux and use just headers.
12:16.29rwhitby(run-time depend, as well as compile-time depend)
12:17.39rwhitbyok, 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.40oleoBut as I've saw Oleg headers ane not the stock one. Same goes to dd-wrt.
12:17.57rwhitbyi.e. just like we do currently for the crosstool case?
12:19.21oleonot sure that this is the right way for cross tool too?
12:19.49rwhitbyit 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.20rwhitbyback in a bit, need to get my 1.5yr old daughter back to sleep
12:25.19oleo$(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.38oleoand then symlinked if needed
12:34.27rwhitbyok, back
12:35.18oleobut then maybe it can be set up this way. I'am jus testing this right now.
12:38.45rwhitbyas 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.34rwhitbyok, now for optware_target names.
12:39.49oleoso far so good with building with new scheme
12:40.30rwhitbynslu2 -> nslu2-glibc-unslung
12:40.57rwhitbywl500g -> wl500g-stock-oleg
12:41.05rwhitbynslu2 -> nslu2-stock-unslung
12:41.20rwhitbythen new wl500g is called wl500g-uclibc-oleg
12:41.35rwhitbyor wl500g-uclibc-ddwrt
12:42.03oleonot following this scheme.
12:42.06rwhitby"stock" means whatever libc the vendor uses
12:42.18rwhitby"uclibc" means the new uclibc toolchain based on buildroot
12:42.29rwhitbyglibc means the crosstool glibc toolchain
12:42.43rwhitbyso it's <machine>-<libc>-<firmware>
12:43.08oleoI do not want long target names for OPTWARE_TARGET
12:43.43rwhitbybut OPTWARE_TARGET is used primarily to distinguish the resulting feeds
12:44.00rwhitbyso how do you distinguish wl500g with oleg from wl500g with ddwrt?
12:44.20oleoCan we first introduce target OPTWARE_TARGET=uclibc and then subverion feed fit TARGET_FIRMWARE?
12:45.14rwhitbynot easily, cause it needs to be driven from the autobuild scripts, so they need a single target to hit for each feed.
12:45.31rwhitby(they currently use OPTWARE_TARGET for that)
12:46.39oleoI see.
12:46.44rwhitbyyou 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.49rwhitbyhow about <machine>[-<libc>[-<firmware>]]
12:48.26rwhitbyso we have nslu2, wl500g, wl500g-uclibc-oleg, wl500g-uclibc-ddwrt, wrt54g-uclibc-ddwrt, wrt54g-uclibc-openwrt, ...
12:48.29oleolooks better. But this long names are hard to remember.
12:48.59oleoand to include in ifdef($(OPTWARE_TARGET))
12:49.31rwhitbywell, instead of switching on OPTWARE_TARGET, you would switch on OPTWARE_MACHINE, OPTWARE_LIBC, or OPTWARE_FIRMWARE ...
12:49.51rwhitby(which are defined in the top-level Makefile, based on OPTWARE_TARGET)
12:50.34rwhitbyeither 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.36oleook. Understand.
12:51.57rwhitbyI prefer OPTWARE_TARGET to be the final configuration.
12:52.04oleowe issuse make OPTWARE_TARGET=uclibc-dd-wrt
12:52.43rwhitbyno, we issue "make OPTWARE_TARGET=nslu2" or "make OPTWARE_TARGET=wl500g-uclibc-oleg"
12:53.15rwhitbyor "make OPTWARE_TARGET=wl500g-uclibc-ddwrt"
12:53.54oleowl500g is somewhat missleading with dd-wrt
12:54.20rwhitbythere would be a separate "make TARGET=wrt54g-uclibc-ddwrt"
12:54.32oleoit is better  make OPTWARE_TARGET=brcm-uclibc-ddwrt
12:55.05oleobecause dd-wrt runs on WRT, Bufallo, Asus, ...
12:55.15rwhitbywhat if there are package modifications required depending if ddwrt is on each different machine?
12:56.48oleoAt present only Broadcom is supported, with provisions of mikrotik routerboards.
12:57.19rwhitbyi.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.51rwhitbyso 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.51oleoyes. 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.32rwhitbywhat about a routing package which needs to know whether the hardware has eth0 or eth0 and eth1 or ixp0 ?
13:00.12rwhitby(and needs to install a different configuration file for the user based on that information)
13:00.34oleoThis could be the case. Solved by ipkg maybe.
13:01.08rwhitbycould possibly be done by a very smart postinstall script which interrogates the hardware.
13:01.39rwhitbybut we intentionally did nslu2, ds101, etc .. instead of a generic ixp4xx optware target.
13:02.01oleoOr very smart end user.
13:02.12rwhitbyif two feeds turn out to be identical, then we just symlink them
13:02.38rwhitbyoptware packages are intended to always install with a default configuration that works out of the box
13:02.53rwhitby(we don't always achieve that goal, but that's the goal)
13:03.04oleoso? Can we live with OPTWARE_TARGET=uclibc-oleg then?
13:03.51rwhitbyno, cause wlhdd-uclibc-oleg might need different packages to wl500g-uclibc-oleg or wl700g-uclibc-oleg
13:04.38rwhitbyif we didn't want the machine, we would just say unslung-glibc or oleg-uclibc
13:05.37rwhitbywe 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.49oleoI do not see the case with different packages for  wl500g-uclibc-oleg and wl700g-uclibc-oleg
13:07.04rwhitbyI don't have a wl700g, so am only surmising there.
13:07.26rwhitbyBut my gut feel (based on two years experience in this project) is that the machine is needed.
13:07.27oleoThe case would be only if oleg changed to new kernel. Then we would call this oleg2.
13:08.17oleomachine names expires. There is nslu3 in the way!
13:08.42rwhitbytake 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.24rwhitbyall 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:10.42rwhitbyOptware 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.31rwhitbyNow 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.10rwhitbySo 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.43rwhitbyif 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.49oleoI 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.40rwhitbywhy not?  that is what a user of the wl500gP or wl500gE would be looking for
13:14.57rwhitbyMost of the users do not know about Broadcom, and quite a few will not know Oleg's name/
13:15.04oleoI would rather say that "oleg" is the firmware and packages are for both.
13:15.29rwhitbysorry, no.  oleg can be appended, but the machine name must be in there.
13:16.55rwhitbyas 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.55oleodd-wrt support at least 20 machines. Oleg supports 7 of them.
13:17.32rwhitbyok, how about this:
13:17.54rwhitbyfor vendor-firmware-compatible optware targets, we use the machine name (and nothing else is required).
13:17.57oleoAll dd-wrt and Oleg firmwares are the same looking from Optware point.
13:18.23rwhitbyfor custom-firmware optware targets, we use the firmware name (and nothing else is required).
13:18.42rwhitbyso we have nslu2, wl500g, oleg and ddwrt as the optware targets.
13:20.22rwhitbyok, let's go ahead with that and see how it looks.
13:21.24oleoThen we stick with naming OPTWARE_TARGET=dd-wrt and then set OPTWARE_LIB and so on
13:23.01oleoIt look like trunk/toolchain/mipsel-linux-uclibc/gcc-3.4.6-uclibc-0.9.28/ is possible and will be introduced today.
13:33.10rwhitbyyep. good.
13:33.15rwhitbynight oleo
13:34.03rwhitby(BTW, what you call the trunk directory, I call /home/slug/optware/nslu2, cause that's where the MasterMakefile puts it).
13:34.46rwhitby(replace 'nslu2' with OPTWARE_TARGET in each case)
15:42.29*** join/#nslu2-linux EvilDevil_ (
15:48.22CIA-603oleo * r3662 10optware/trunk/make/ buildroot: add gcc and binutils config handling, move staging_dir location to toolchain/
17:24.19*** join/#nslu2-linux AdamBaker (
17:59.47*** join/#nslu2-linux blomma (
18:02.37*** join/#nslu2-linux blomma (
18:53.25*** join/#nslu2-linux caplink811-log (
18:59.35*** join/#nslu2-linux mithro (
19:10.26*** join/#nslu2-linux Blastur (
20:29.43*** join/#nslu2-linux _kaenat (
20:36.40*** join/#nslu2-linux bullet (
20:40.01*** join/#nslu2-linux _kaenat (
21:02.51*** join/#nslu2-linux llagendijk (
22:23.05*** join/#nslu2-linux odoc (
22:34.31CIA-603gda * r3663 10optware/trunk/make/ postfix: depends on ipk findutils not on the command find
22:41.21*** part/#nslu2-linux odoc (
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

Generated by by Jeff Waugh - find it at! Modified by Tim Riker to work with blootbot logs, split per channel, etc.