**** BEGIN LOGGING AT Mon Nov 13 02:59:57 2006 Nov 13 03:03:55 03bzhou * r4461 10optware/trunk/make/php.mk: php: upgrade to 5.2.0 Nov 13 04:46:16 03bzhou * r4462 10optware/trunk/make/pcre.mk: pcre: upgrade from ancient 5.0 to 6.7, php 5.2 requires pcre > 6.6 Nov 13 04:51:20 03rwhitby * r4463 10optware/trunk/make/rsync.mk: rsync: Updated to version 2.6.9 Nov 13 05:21:08 03rwhitby * r571 10kernel/trunk/ (Makefile patches/apex/defconfig): apex: Now builds an apex that boots Nov 13 05:36:02 03rwhitby * r572 10kernel/trunk/Makefile: apex: Now works little endian too Nov 13 08:26:58 * rwhitby is adding apex support to slugos Nov 13 08:33:57 good move Nov 13 08:34:28 It would appear that the initial kernel solution wasn't a good move after all, especially considering booting from usb. Nov 13 08:35:48 getting apex to boot from usb might happen someday ;-) Nov 13 09:13:28 Anyone got a clue what might be the problem when I try to use buildroot to compile uClibc 0.9.27 and get this: http://rafb.net/paste/results/RJF0Aw50.html ? Nov 13 09:19:17 nope Nov 13 09:25:27 hi there. i am mindbender from linkstationwiki.net. i wanted to ask what exactly would be needed to do to to create custom optware packages...i suppose we have to supply a working cross toolchain and a patch for the main makefile.....would we have to modify every makefile of each compiled package? Nov 13 09:27:31 hi mindbender Nov 13 09:27:43 no, you don't need to change each .mk file Nov 13 09:28:24 only the top makefile? Nov 13 09:28:29 yep Nov 13 09:28:33 cool. Nov 13 09:28:44 and maybe a few .mk files and patches here and there if the packages don't work on the new arch Nov 13 09:28:56 we currently support at least 8 different targets Nov 13 09:29:14 well..."new arch".....it is ppc & mips....you already have feeds for that Nov 13 09:30:04 right, but your targets will need some tweaks - startup scripts, etc Nov 13 09:31:12 true. but wouldn`t that interfere with other targets? i mean...you mentioned patches... Nov 13 09:31:26 we conditionalise on ${OPTWARE_TARGET} Nov 13 09:31:34 (at both build, and run time) Nov 13 09:32:00 i c. which is a good thing. Nov 13 09:32:01 have you had a look through the optware build repo? Nov 13 09:32:55 i looked at the main makefile until now....and i remember how to use the whole stuff because i was one of the first ten guys compiling debianslug and flashing it.. Nov 13 09:33:18 right, but the optware .mk stuff is different from the OE stuff Nov 13 09:33:38 kk. tell me what i should look at and i will do. Nov 13 09:34:08 look in optware/Makefile and search for OPTWARE_TARGET in optware/make/*.mk and in optware/sources/*/* Nov 13 09:34:49 i will. thx. Nov 13 09:35:05 and choose some good names for OPTWARE_TARGET for your targets Nov 13 09:35:45 kk. thx for your help. Nov 13 09:36:11 * NAiL suspects mindbender read his post on the forum from yesterday Nov 13 09:37:20 mindbender: the ppc linkstation uses glibc? Nov 13 09:38:28 yes i read it...if you are repvik :) Nov 13 09:38:43 yup ;) Nov 13 09:39:57 the Synology DS101G feed mentioned here http://www.nslu2-linux.org/wiki/Unslung/OptwarePlatforms works on all ppc-based linkstations. Nov 13 09:40:18 yeah, and it should be easy to copy and adapt to the linkstation Nov 13 09:41:04 in fact the ppc based linkstations have the same board but only 4 mb of flash....and they use ide.....mostly a kernel thing which all was done already.... Nov 13 09:41:17 we have the latest 2.6-kernel on all ppc boxes already... Nov 13 09:42:00 nice Nov 13 09:44:09 a japanese guy has written a kernel module which allows to load a new kernel and jump into the kernel on the fly....we have it for ppc & for mips. this may be interesting for anyone here... Nov 13 09:45:43 kexec? Nov 13 09:48:36 yes..something like that. does kexec work on other platforms besides x86? Nov 13 09:49:33 we recently added kexec support to our repo Nov 13 09:50:24 is there no assembler stuff needed for kexec? we had to rewrite powerpc-assembler to mipsel-assembler to make the loader working on the LS2.. Nov 13 09:50:25 so it works on arm Nov 13 09:50:50 I've got no idea ;) Nov 13 09:52:22 hm...how is kexec support integrated? i suppose there was some work needed on the kernel? Nov 13 09:56:28 http://www.rpsys.net/openzaurus/patches/kexec-arm-r1.patch <-- the patch for arm to get kexec Nov 13 09:58:46 ah i understand..well....our future goes with UBoot on all boxes anyway so testing kernels won`t be a problem anymore. only the mips-box and the terastations are lacking UBoot but this is only a matter of time. thx guys! Nov 13 09:59:02 np Nov 13 10:10:49 NAiL: slugos (my local copy) boots again, via apex. still a couple of things to iron out before I commit. Nov 13 10:14:22 03rwhitby * r573 10kernel/trunk/patches/2.6.19/43-nslu2-mtd-microcode.patch: 43-nslu2-mtd-microcode.patch: Read microcode from FIS directory Nov 13 10:22:24 rwhitby: cool Nov 13 10:41:30 * rwhitby flashes another image which should read microcode from FIS directory. Nov 13 10:42:25 jbowler always impresses me. The funky progress meter in upslug2 even works inside an Emacs shell buffer! Nov 13 10:42:53 neat :) Nov 13 10:51:58 Hmm - FIS directory partition (shortened to 0x1000) no longer covers the area of the microcode. Nov 13 10:52:30 I didn't get that Nov 13 10:52:45 catch 22 - if I set it to 0x20000 then the microcode would be found, but the parser would get confused. if I set it to 0x1000, then the microcode is not found (cause it's not in the FIS directory partition) Nov 13 10:58:47 * rwhitby tries with a full-block FIS directory, just to prove the hypothesis. Nov 13 11:01:49 yep, parsing fails. Nov 13 11:03:29 * rwhitby loves his remote serial power control box :-) Nov 13 11:03:34 hehe Nov 13 11:03:45 I guess I should set up something like that too Nov 13 11:03:51 I've even got remote jtag hooked up, just in case :-) Nov 13 11:12:47 03rwhitby * r574 10kernel/trunk/patches/2.6.19/43-nslu2-mtd-microcode.patch: Moved microcode to SysConf partition for NSLU2 Nov 13 11:27:54 I'm going to reserve 32Kb for the microcode. Nov 13 11:28:08 (for the NSLU2, which only has one interface) Nov 13 11:28:51 (minus 16 bytes for the header) Nov 13 11:30:48 according to Christian: Nov 13 11:30:57 The maximum data and code size for NPE-B and NPE-C on IXP425 is 16K. Nov 13 11:30:58 For NPE-A on IXP425 it is 24k. Nov 13 11:30:58 On ixp465 CPUs it is 24K for every NPE. Nov 13 11:31:31 current microcode we are using is 11964. Nov 13 11:34:59 well, NPE-A isn't used on the slug at all, is it? Nov 13 11:36:17 correct. Nov 13 11:36:40 I might even go down to 16Kb, and use some space for an Apex environment. Nov 13 11:36:53 (also in sysconf, so it is preserved across flashing) Nov 13 11:37:55 Hmm - I just realised that since a normal flash doesn't touch sysconf, then my microcode won't get written in this flash ... Nov 13 11:40:48 damn. Nov 13 11:40:58 too many catch-22's Nov 13 11:41:40 hmm Nov 13 11:42:54 does the jffs2 fs have to fill the entire partition, or could the microcode be tacked on the end and written to that partition? Nov 13 11:43:16 then jffs2 changes would clobber it Nov 13 11:43:34 (unless you take a full block away from the Flashdisk partition) Nov 13 11:44:34 a full block is 128kb? Nov 13 11:44:38 yep Nov 13 11:45:15 which of the NPE's were possible to use to speed up LE networking? Was that -A or -C? Nov 13 11:45:29 A I think Nov 13 11:45:48 but I don't think that was feasible Nov 13 11:45:54 oh :-\ Nov 13 11:46:56 Is there anything else we could put into that 128kb? Nov 13 11:47:55 I don't see the reduction of the jffs2 fs by 128kb as a disaster, but it's a shame if we can only use 11kb of it. Nov 13 11:49:48 03rwhitby * r77 10slugimage/trunk/slugimage: Fixed an allocation bug, and moved the Microcode to 0x7f0000 Nov 13 11:50:05 where is 0x7f0000? Nov 13 11:50:08 I think we should be able to fix the FIS dir parsing Nov 13 11:50:11 in the FIS dir Nov 13 11:50:25 an entry of all FF's is a good terminator Nov 13 11:50:31 ok Nov 13 11:50:49 also need to fix the swap detection code to handle sizes other than a full block size Nov 13 12:17:54 Hmm - upslug2 -k option no longer makes sense with a second stage bootloader Nov 13 12:18:32 * rwhitby senses an upslug3 might be required ... Nov 13 12:19:41 upslug hasn't had any changes for a long time ;-) Nov 13 12:25:37 03rwhitby * r575 10kernel/trunk/patches/2.6.19/43-nslu2-mtd-microcode.patch: Moved Microcode back into FIS directory Nov 13 12:26:09 03rwhitby * r78 10slugimage/trunk/slugimage: Set FIS directory back to full erase block size Nov 13 12:27:10 53 RedBoot partitions found on MTD device IXP4XX-Flash.0 Nov 13 12:27:10 Creating 53 MTD partitions on "IXP4XX-Flash.0": Nov 13 12:27:10 0x00000000-0x00040000 : "RedBoot" Nov 13 12:27:10 nslu2 mac: 00:04:5a:0f:b2:c6 Nov 13 12:27:10 0x00040000-0x00060000 : "SysConf" Nov 13 12:27:11 0x00060000-0x00080000 : "Loader" Nov 13 12:27:15 0x00080000-0x001c0000 : "Kernel" Nov 13 12:27:17 0x001c0000-0x007e0000 : "Flashdisk" Nov 13 12:27:19 0x007e0000-0x00800000 : "FIS directory" Nov 13 12:27:21 npe: searching for firmware... Nov 13 12:27:23 npe: found at 0x10010, IXP425/NPE-B func: 00, rev: 2.1, size: 11964, id: 01000201 Nov 13 12:27:25 npe: firmware loaded to NPE-B, func: 00, rev: 2.1, status: 80c00000, crc: 875e Nov 13 12:27:27 0xaeedf00d-0xaeedfbb9 : "" Nov 13 12:27:29 mtd: partition "" is out of reach -- disabled Nov 13 12:27:31 Just have to terminate the FIS directory correctly, and we're done. Nov 13 12:28:10 ooh, nice Nov 13 12:35:00 which is a two-line addition to drivers/mtd/redboot.c Nov 13 12:35:35 (first byte of entry == 0xff -> deleted entry, first two bytes of entry == 0xff -> end of table) Nov 13 12:43:42 03rwhitby * r576 10kernel/trunk/patches/2.6.19/02-mtdpart-redboot-byteswap-partition-truncate.patch: 02-mtdpart-redboot-byteswap-partition-truncate.patch: now terminates on two bytes of 0xff - this allows us to store microcode in the FIS dir Nov 13 12:48:25 great work :) Nov 13 12:52:09 the best patches are the shortest ones :-) Nov 13 12:55:38 kernels take so long to compile when you're waiting ... Nov 13 13:07:43 ok course, an even better patch is one that works. Nov 13 13:09:12 heh, it didn't work as expected? Nov 13 13:09:36 look at the order of the tests ... Nov 13 13:10:58 03rwhitby * r577 10kernel/trunk/patches/2.6.19/02-mtdpart-redboot-byteswap-partition-truncate.patch: Helps if you test for the second byte before continuing the loop Nov 13 13:13:11 Hmm - still didn't work. Nov 13 13:13:26 ok, it's past midnight - this one will need some other eyes on it. Nov 13 13:13:57 night all Nov 13 13:16:24 nite Nov 13 13:23:05 rwhitby: for reference, apex tests for 0xffffffff to detect the end of table (apex/apex-1.4.7/src/drivers/drv-fis.c) Nov 13 14:23:17 anyone alive for a tcpdump question? Nov 13 14:23:31 im trying to debug firefly/mtdaapd on the nslu2 Nov 13 14:23:46 as theres a known bug with how it talks to xbmc Nov 13 14:24:27 when i use tcpdump on the slug i only seem to record inbound traffic. im using the syntax tcpdump -i eth0 -w raw.cap Nov 13 14:24:31 am i being stupid? Nov 13 14:34:40 barnseenio: I don't think you're stupid. Nor missing anything. I thing that should just work... Nov 13 14:34:51 do you have serial on your slug? Nov 13 14:34:57 no Nov 13 14:35:05 so i run tcpdump with above command Nov 13 14:35:12 then run tcpflow -r raw.cap Nov 13 14:35:12 yeah Nov 13 14:35:23 and it bangs out a file per communication Nov 13 14:35:26 old intel driver or new open npe driver? Nov 13 14:35:34 and mine are always client > server Nov 13 14:35:36 old intel Nov 13 14:35:46 this is debianslug btw Nov 13 14:36:18 maybe tcpflow is where im going wrong then Nov 13 14:37:30 im just using tcpflow -r raw.tcp Nov 13 14:38:51 I'm not familiar with tcpflow, so I can't say Nov 13 14:39:03 but my guess would be that it replays both incoming and outgoing... Nov 13 14:39:18 yeah just says in the man it dumps out a tcpdump file Nov 13 14:39:20 it might be a bug in the network driver though.. Intels code was Bad (TM). Nov 13 14:39:29 ugg Nov 13 14:39:34 Might be interesting testing on a new driver Nov 13 14:39:54 You subscribed to the mailinglist? Nov 13 14:40:04 sure yes Nov 13 14:40:27 are you on a linux box now? Nov 13 14:40:38 if you run tcpdump do you get inbound and outbound traffic? Nov 13 14:40:40 send a mail and ask someone with the new npe driver to try using tcpdump/tcpflow and see if it works. Nov 13 14:40:45 two secs Nov 13 14:43:18 odd Nov 13 14:43:25 m? Nov 13 14:43:30 I get a lot of packages going ">" Nov 13 14:43:39 but just a very, very few going "<" Nov 13 14:43:46 but some Nov 13 14:43:46 even when sending traffic towards the box Nov 13 14:43:59 have you run it through tcpflow? Nov 13 14:44:04 one every few hundred packages it seems Nov 13 14:44:15 I didn't get any output from tcpflow at all Nov 13 14:44:25 your tcpdump command? Nov 13 14:44:31 tcpdump -i eth0 -w raw.cap Nov 13 14:44:36 your tcpflow command? Nov 13 14:44:37 and tcpflow -r raw.cap Nov 13 14:44:40 ls -la Nov 13 14:44:47 16 -rw-r--r-- 1 root root 15358 Nov 13 16:04 raw.cap Nov 13 14:44:52 ugg Nov 13 14:44:59 it should create a file per host Nov 13 14:45:13 ouch Nov 13 14:45:14 213.132.130.136.42880-192.168.000.003.04680 Nov 13 14:45:14 216.196.180.049.04722-192.168.000.003.41414 Nov 13 14:45:14 216.196.180.049.30094-192.168.000.003.04985 Nov 13 14:45:14 217.075.122.242.02430-192.168.000.003.41414 Nov 13 14:45:17 that kinda format Nov 13 14:45:35 uh Nov 13 14:45:37 and i get none where slug (003) is on the left Nov 13 14:45:42 hang on Nov 13 14:46:14 067.167.004.050.01123-192.168.007.003.06667 Nov 13 14:46:31 looking good Nov 13 14:46:34 irc ;-) Nov 13 14:46:47 yup, not my session though :-P Nov 13 14:46:50 heh Nov 13 14:47:01 I'm logged into a server somewhere far away ;) Nov 13 14:47:59 yeah lol Nov 13 14:48:11 so, any traffic with 003 on the left? Nov 13 14:48:34 i just keep thinking my logics flawed somewhere Nov 13 14:48:35 not anything that tcpflow shows, no Nov 13 14:48:53 i wonder could setup a filter in tcpdump to only catch outbound traffic Nov 13 14:50:46 oh Nov 13 14:50:47 gotta run Nov 13 14:50:48 later Nov 13 15:06:10 03bzhou * r4464 10optware/trunk/make/busybox.mk: busybox: update with latest template to trigger a rebuild of secondary packages Nov 13 15:21:15 03bzhou * r4465 10optware/trunk/Makefile: marked php-thttpd broken for wl500g and uclibc targets for now, will come back to it Nov 13 15:25:28 Hey guys, I'm trying to build a newer version of an ipk file I want for Unslung 6.8b. I keep getting an error when I do 'make filename'. Forgive the long cut-n-paste: Nov 13 15:25:29 checking for openssl... gnome-config: No such file or directory Nov 13 15:25:29 gnome-config: No such file or directory Nov 13 15:25:29 Package openssl was not found in the pkg-config search path. Nov 13 15:25:29 Perhaps you should add the directory containing `openssl.pc' Nov 13 15:25:30 to the PKG_CONFIG_PATH environment variable Nov 13 15:25:32 No package 'openssl' found Nov 13 15:25:34 configure: error: Could not find openssl's crypto library Nov 13 16:28:23 I've posted the same message to the mailing list - maybe someone who has experience building packages will be able to help. Nov 13 16:37:34 03bzhou * r4466 10optware/trunk/make/dspam.mk: dspam: trigger rebuild with latest template to recovery secondary ipks Nov 13 16:41:08 03bzhou * r4467 10optware/trunk/make/emacs.mk: emacs: trigger rebuild with latest template to recovery secondary ipks Nov 13 16:43:02 03bzhou * r4468 10optware/trunk/make/imap.mk: imap: trigger rebuild with latest template to recovery secondary ipks Nov 13 16:46:12 03gda * r4469 10optware/trunk/make/cyrus-sasl.mk: cyrus-sasl: 2.1.22 Nov 13 16:46:56 03gda * r4470 10optware/trunk/make/postfix.mk: postfix: 2.3.4 Nov 13 16:47:37 scarolan: i can help, just today right now is not a good time Nov 13 16:48:44 eno: No problem, this is not mission-critical stuff. Just email or ping me on IRC when you do have time Nov 13 16:49:14 scarolan: you probably want to look at other packages that openssl-stage and use that as example Nov 13 16:49:14 eno: I would like to contribute the package back into the feed if I can get it working, because I think others could use it. Nov 13 16:49:28 scarolan: that would be great Nov 13 16:50:35 rwhitby, great work with all the latest commits. It's looking great. Nov 13 16:50:46 I'm looking forward to alpha testing this. Nov 13 16:54:07 eno: how can i find other packages that use openssl-stage? Do I just grep the optware/make directory? Nov 13 16:54:35 scarolan: yeah, grep will do Nov 13 16:56:34 I get this: Nov 13 16:56:35 bash-3.1# grep openssl.pc * Nov 13 16:56:35 openssl.mk: install -m 644 $(OPENSSL_BUILD_DIR)/openssl.pc $(STAGING_DIR)/opt/lib/pkgconfig Nov 13 16:58:48 scarolan: grep PKG_CONFIG_PATH make/*.mk Nov 13 17:00:21 ok, everything that matches this search has: Nov 13 17:00:23 xchat.mk: PKG_CONFIG_PATH="$(STAGING_LIB_DIR)/pkgconfig" \ Nov 13 17:00:32 (xchat is just one example) Nov 13 17:00:58 scarolan: try do the same for your package, set it before your configure call Nov 13 17:08:44 Ok, i've done that and it seems to be compiling. . . keeping my fingers crossed Nov 13 17:23:27 How come the slug appears to build a whole bunch of other stuff just to make one package? Nov 13 17:36:35 scarolan, bitbake -v will show you the dependencies as they are analyzed. Nov 13 17:37:54 HopsNBarley, so in other words once all the dependencies are built, it should not have to make those again for future packages? Nov 13 17:38:46 exactly. Nov 13 17:40:49 dependencies are cached, AFAIK. Nov 13 17:42:38 HopsNBarley: you already have a PPC toolchain within OE? Nov 13 17:44:01 yeah! Nov 13 17:44:18 seems to work okay with glibc 2.5, too. Nov 13 17:44:43 hey, are any of you folks in the bay area? It would be fun to get together and compare notes, war stories, etc. Nov 13 17:48:07 scarolan, i'd offer an alternative explanation: it's not so much that dependencies are cached, it's that the record of their sucessful build is noted in the tmp/stamps/module-version.do_* files. Nov 13 17:48:26 splitting hairs, i know. Nov 13 17:49:34 Ok, that is more accurate explanation. I was just wondering because my build environment is on the slug itself, and the little guy is doing his best but slooooowly Nov 13 17:50:21 I tried to set it up on my laptop running Ubuntu edgy, but the tools wouldn't build properly Nov 13 17:52:01 Debian stable should work for cross-compiling, right? Nov 13 17:52:52 i dunno. i'm using gentoo. *should* work almost anywhere, but will probably take some tweaking. what error are you hitting? Nov 13 17:53:06 let me check that now Nov 13 18:01:34 I did a "make rtorrent" on my laptop to see - wow it's a LOT faster than the slug Nov 13 18:02:17 probably 20-50x (-; Nov 13 18:08:09 does this IRC channel have a pastebot? Nov 13 18:09:49 anyway here are one of the errors i get Nov 13 18:09:50 /home/scarolan/slug/optware/toolchain/crosstool/build/armv5b-softfloat-linux/gcc-3.3.5-glibc-2.2.5/build-glibc/csu/version-info.h:1:1: missing terminating " character Nov 13 18:10:27 it spits out about four missing terminating " character messages, then finally exits with Error 2 Nov 13 18:33:21 scarolan, sorry, dunno. i'm not using crosstool or optware. Nov 13 18:34:03 HopsNBarley, well I'll give it another shot here. By the way, are you actually running gentoo on your slug? Nov 13 18:34:26 no, but i sorta wish i was... Nov 13 18:34:36 Wouldn't take like 6 months to install? Nov 13 18:35:15 i'm assuming i could cross compile packages, but i don't know about emerge and cross compiling. Nov 13 18:45:43 HopsNBarley: nice to hear about powerpc working, I'll get myself a qnap ts-101 probably to work with OE/PPC. Nov 13 18:50:20 i'd be happy to share my BB recipies for getting the toolchain up, at least. Nov 13 18:54:58 HopsNBarley: if you can share them, pls. do. I think the most neat way is to post them as attachments in the bug tracker of OE. But I would welcome a copy in my email box :-) Nov 13 18:56:07 HopsNBarley: did you get a quote on the 8343 parts from your distributor? I'm asking them for one tomorrow. (and on the 8347 as well). Nov 13 18:56:19 them = my distributor Nov 13 18:56:38 likewise, i think we were talking with freescale directly. hold on, lemme ask my HW guy. Nov 13 18:56:54 HopsNBarley: consumer numbers, right... Nov 13 19:00:15 likewise, no answer... you were also curious on mips/W, right? Nov 13 19:00:53 HopsNBarley: well, I could deduce the mips/W from the datasheet, I just wanted to check what I could expect in term of $ per part. Nov 13 19:01:15 HopsNBarley, I think we pay $20 for a 533MHz XScale IXP420 Nov 13 19:05:27 likewise, that seems like a good price. Nov 13 19:17:37 likewise: tried compiling a "correct" toolchain with buildroot, but it bombs out on uclibc Nov 13 19:17:49 http://rafb.net/paste/results/RJF0Aw50.html Nov 13 19:18:34 NAiL: lemme check my local build (which stopped at hdparm) Nov 13 19:19:36 NAiL: i got my other friend to capture some data using tcpdump, and it captured both inbound and outbound, i also sent him my capture file and tcpflow gave the same results, so it seems my tcpdump on nslu2/debianslug isnt capturing outbound traffic Nov 13 19:20:22 barnseenio: that is quite... odd Nov 13 19:20:26 isnt it! Nov 13 19:21:07 have you got a slug there? Nov 13 19:21:25 NAiL: hmm, resolve.o is not in my build. let's restart it... Nov 13 19:24:56 L0C4LH0ST: hello Nov 13 19:30:11 <[g2]> HopsNBarley are you building BB with glibc or uclibc ? Nov 13 19:30:23 glibc 2.5 Nov 13 19:30:58 <[g2]> crispy fresh :) Nov 13 19:31:15 so far so good.... Nov 13 19:31:30 <[g2]> are you building for XScale at all or just PPC ? Nov 13 19:31:33 it's on my menu to run the test suite, but so far relying on the existence proof. Nov 13 19:31:47 both xscale (slug) and ppc (storcenter) Nov 13 19:32:21 <[g2]> did you use buildroot to make the toolchain ? Nov 13 19:32:46 <[g2]> and are you running BE on the slug ? Nov 13 19:33:39 i am running BE on the slug, and i don't know what buildroot is (-; Nov 13 19:34:17 <[g2]> HopsNBarley how did you create your toolchain ? crosstool ? Nov 13 19:35:13 i used BB... with all the PREFERRED providers set right in a distro/conf. but this is probably buildroot, right? Nov 13 19:35:29 <[g2]> nod. Nov 13 19:36:05 <[g2]> There's buildroot that builds the toolchain, tools, rootfs, and then there's busybox which is really stand-alone Nov 13 19:36:23 [g2], is there a "migration" of sorts to tasks in OE? Nov 13 19:36:25 <[g2]> the buildroot stuff just helps ppl get setup to run busybox Nov 13 19:36:53 <[g2]> HopsNBarley how do you mean migration ? Nov 13 19:37:27 away from meta and towards tasks. tasks just seems.. newer, but i've not seen discussion on the matter Nov 13 19:37:53 [g2], where does buildroot live? I don't see a class or a package file. Nov 13 19:38:10 HopsNBarley: [g2] is wrong here, buildroot is not part of BB/OE. Nov 13 19:38:55 find openembedded/ -name \*buildroot\* returns nothing. Nov 13 19:39:14 HopsNBarley: buildroot has nothing to do with openembedded. Nov 13 19:39:24 likewise, thanks. Nov 13 19:40:22 HopsNBarley: buildroot is a package build framework, a bit dumber than OE, but simpler as well. It lives here: http://buildroot.busybox.net/ Nov 13 19:40:25 <[g2]> likewise where did I say buildroot was part of busybox ? Nov 13 19:41:01 [g2]: you gave a nod, right after a Q of HopsNBarley. That's were all confusion started. Might be a badly timed nod though. Nov 13 19:41:19 likewise, thanks, good tip. i like OE but always nice to have other tools in the bag. Nov 13 19:41:43 [g2]: 14 lines back (15 by now :-) ) Nov 13 19:42:03 <[g2]> likewise Ah...l yeah... I was nodding to the running 'BE and don't know what buildroot is Nov 13 19:42:24 HopsNBarley: there's crosstool: the tool to create cross toolchains, buildroot, the tool to create toolchains + packages, and then there's a whole bunch of derivates of these. Nov 13 19:42:53 thank goodness buildroot is not in OE. I would have been concerned for myself. (-; have used crosstool previouslly. Nov 13 19:43:18 HopsNBarley: NAiL is trying to have buildroot build a uclibc toolchain for PowerPC now. Nov 13 19:43:53 HopsNBarley: could you put your .bb on a web page, or email them to us? I would very much like to test at least whether it builds OK here. Nov 13 19:44:40 so, you'll need the distro and machine .conf, as well as the kernel and rootfs bb's. Nov 13 19:45:15 HopsNBarley: whatever you want to share. Nov 13 19:45:57 just want to get you a complete set. do you just want the toolchain stuff? Nov 13 19:46:32 HopsNBarley: rootfs and kernel are fine with me too. Nov 13 19:46:39 (-; Nov 13 19:47:26 first, a big fat caveat: this is alpha stuff. there are still various problems and warnings and incompatibilities with the slugos stuff, on which the rootfs is based. Nov 13 19:48:19 <[g2]> HopsNBarley it sounds like you are building the tools with OE then correct ? Nov 13 19:48:45 NAiL: check this: http://www.busybox.net/lists/buildroot/2006-October/000262.html Nov 13 19:49:07 as an aside, we should be looking at ways to make slugos a more general purpose OS with no slug dependencies - or maybe i should be making a debain based solution... opinions solicited. Nov 13 19:49:19 [g2], yes. Nov 13 19:49:32 [g2]: got a sec for a quick question? Nov 13 19:49:53 <[g2]> barnseenio ask away Nov 13 19:49:58 HopsNBarley: then probably we should define the minimal machine features the machine must have in order to be supported in the distro. Nov 13 19:50:42 <[g2]> HopsNBarley it really depends on your goals for the distro Nov 13 19:50:48 HopsNBarley: and then the slugos could be made to match with whatever is available on the different machines (I mean, NAS devices are popping up faster than I can switch gears). Nov 13 19:51:27 im trying to debug mt-daapd between nslu2 and xbox. theres a known bug. when i run tcpdump on my nslu2 (debianslug) i get no outbound data recorded, i.e. from slug to itunes client. when my friend tries on a linux box, he see's two way network traffic recorded by tcpdump. can you think of a reason why im not seeing outbound traffic using tcpdump/tcpflow? Nov 13 19:51:57 there are several difficulties. Nov 13 19:52:34 first are the init scripts, which are quite HW dependent. Fair enough, it IS the slugos-initscripts i'm working from. Nov 13 19:52:52 <[g2]> barnseenio are you running netfilter or anything like that on the slug ? Nov 13 19:53:03 not intentionally Nov 13 19:53:06 second are the use cases. i don't want to build the X11 stuff, yet certain OE dependencies essentially make it hardwired. Nov 13 19:53:17 <[g2]> barnseenio lsmod is your friend Nov 13 19:53:21 this seems to be addressed (an initial cut) in the tasks/ packages Nov 13 19:53:23 HopsNBarley: I have a solution for the X11 deps Nov 13 19:53:23 im using the intel network stuff Nov 13 19:53:57 likewise, yeah? Nov 13 19:54:14 NSUL2:/home/bb# lsmod Nov 13 19:54:14 Module Size Used by Nov 13 19:54:14 af_packet 18408 2 Nov 13 19:54:14 ixp400_eth 17980 0 Nov 13 19:54:14 ixp400 946852 1 ixp400_eth Nov 13 19:54:17 ext3 104232 2 Nov 13 19:54:19 jbd 46612 1 ext3 Nov 13 19:54:22 mbcache 5540 1 ext3 Nov 13 19:54:40 <[g2]> barnseenio pls pastebin > 4 lines Nov 13 19:54:48 sorry [g2] Nov 13 19:54:56 mean much to you ;-) ? Nov 13 19:55:09 <[g2]> np, it's a fyi not a wrist slap Nov 13 19:55:16 HopsNBarley: I am using an overlay of .bb files that have no X dependencies. This was before the task/feature stuff. Nov 13 19:56:57 <[g2]> barnseenio did you compare the two different incoming packets (one from the mac, one from the linux box) ? Nov 13 19:57:13 likewise, i've been keeping my own tree based on OE a few months ago. i've merged in some changes from the mainline as i have time. your solution seems a good one. Nov 13 19:57:25 <[g2]> I'd guess that the daemon is rejecting the packets from itunes for some reason Nov 13 19:57:44 sorry you misunderstand Nov 13 19:57:56 itunes server runs fine Nov 13 19:58:15 when i run tcpdump i see no data which is server > client, i only see incoming requests to slug Nov 13 19:58:47 <[g2]> barnseenio i don't think you understood my reply Nov 13 19:58:49 HopsNBarley: depends on the number of packages you need without X11 deps Nov 13 19:58:54 * [g2] tries again Nov 13 19:59:09 sorry, i am stupid Nov 13 19:59:16 <[g2]> barnseenio not at all Nov 13 19:59:25 03gda * r4471 10optware/trunk/make/asterisk.mk: asterisk: 1.2.13 Nov 13 19:59:31 <[g2]> barnseenio we just have a communication to clean up Nov 13 19:59:33 likewise, i haven't hit that many... cause i'm just a fileserver. Nov 13 20:00:06 its just the same tcpdump command on a different box seems to capture client>server and server>client (im guessing this because when i run the output through tcpflow if see only traffic the one way) Nov 13 20:00:18 <[g2]> barnseenio in summary, when the linux box talks to the mt-dapp server on the slug the slug replies, the itunes box doesn't correct ? Nov 13 20:00:34 no Nov 13 20:01:03 sorry, i think i started with a confusing statement ;-) Nov 13 20:01:04 <[g2]> barnseenio I meant the slug doesn't reply when the itunes box tries Nov 13 20:01:25 client > slug(itunes server) all works Nov 13 20:01:27 likewise, i gotta take a lunch break. i'll catch you later and get you those files. Nov 13 20:01:28 HopsNBarley: then the package overlay approach works fine. I have been using it for freetype, cairo, pango, gtk+-pixbuf Nov 13 20:01:40 likewise, with CVS or something? Nov 13 20:01:40 cya, thanks. Nov 13 20:01:53 however when i run tcpdump i never see any outbound traffic from slug (even though it works and data is obviously sent from slug to client) Nov 13 20:01:55 HopsNBarley: no, I'll explain next time Nov 13 20:02:00 cool. later. Nov 13 20:02:59 in fact if you take itunes out of the equation, i can never seem to use tcpdump to see any tcp traffic from slug>caller Nov 13 20:03:26 happen to know if its some limitation/bug/something with intel network driver for nslu2 Nov 13 20:04:04 <[g2]> barnseenio Ok... so the issue is simply that you are not seeing output on the slug from tcpdump Nov 13 20:04:11 yes, sorry Nov 13 20:04:25 i run tcpdump -i eth0 -w file.crap Nov 13 20:04:30 then tcpflow file.crap Nov 13 20:04:40 and all output is client>slug never slug>client Nov 13 20:05:14 then tcpflow -r file.crap Nov 13 20:05:15 NAiL: ping. Somehow, my buildroot builds uClibc. Nov 13 20:05:50 NAiL: the daily snapshot of uClibc though. Nov 13 20:22:04 happen to think of a reason why that may be [g2] ? have you ever dumped tcp on your slug(s) and seen two way traffic? Nov 13 20:23:09 <[g2]> barnseenio I remember seeing the input Nov 13 20:23:25 <[g2]> I haven't looked closely for the output Nov 13 20:24:06 i see, maybe i'll try on the mailing list, see if anyone can help Nov 13 20:24:35 <[g2]> barnseenio I guess it'd be simple issue to check out Nov 13 20:24:56 <[g2]> 1) run a ping -c 5 from some other box Nov 13 20:25:14 <[g2]> 2) watch for the packets in and out Nov 13 20:25:23 <[g2]> I'm sure the ifconfig stats are correct Nov 13 20:25:53 <[g2]> and it's really a question of where libpcap taps the ip output Nov 13 20:26:10 <[g2]> barnseenio does that make any sense ? Nov 13 20:28:34 yes and no Nov 13 20:28:45 im not sure what ifconfig is Nov 13 20:28:57 <[g2]> ifconfig eth0 Nov 13 20:29:09 <[g2]> you'll see information about the interface Nov 13 20:29:47 <[g2]> there are packet and byte count RX (receive) and TX(transmit) plus other stuff Nov 13 20:30:36 k i see that stuf Nov 13 20:30:37 f Nov 13 20:30:54 what am i looking for that would indicate whether i can see packets out as well as packets in? Nov 13 20:31:36 likewise: yeah, daily can probably compile. But it won't work on the ts101 :-\ Nov 13 20:32:07 i guess i should go read up a bit more. im still frustrated that running exactly the same thing on another linux box yields different results, although i appreciate there could be lots of reasons why! Nov 13 20:32:37 NAiL: did you choose 2.6.18 kernel headers? Nov 13 20:32:49 likewise: I'm also using older kernel headers, so for the time being it won't make a difference Nov 13 20:34:26 <[g2]> barnseenio on a quiet network, none of the counts move Nov 13 20:34:43 none of the counts move Nov 13 20:34:46 <[g2]> then you can ping -c 5 the device and see the packet counts in and out Nov 13 20:34:50 oh the ifconfig counts? Nov 13 20:34:54 <[g2]> yeah Nov 13 20:34:54 i see Nov 13 20:36:11 how do i differentiate in and out? Nov 13 20:36:14 in ifconfig Nov 13 20:37:59 NAiL: I cannot find the option where I specify the uClibc version (mine is 0.9.28 if I do not build from a snapshot) Nov 13 20:38:01 when i ping it, before and after in ifconfig all the numbers change (RX,TX etc) Nov 13 20:40:18 sorry i'll stfu .. i'll go read some stuff before blurting linux 101 networking guff Nov 13 20:52:57 likewise: Yeah, I had to edit the uclibc.mk file Nov 13 20:53:06 and replace .28 with .27 Nov 13 20:53:12 NAiL: ok Nov 13 21:21:32 likewise: have you tried recompiling? Nov 13 21:21:51 yeah, same error, I am looking into why .28 works, .27 not Nov 13 21:36:06 03bzhou * r4472 10optware/trunk/make/php-thttpd.mk: php-thttpd: patch for uclibc platform Nov 13 21:37:41 03bzhou * r4473 10optware/trunk/Makefile: php-thttpd should be ok now for wl500g and uclibc platforms Nov 13 23:09:18 03bzhou * r4474 10optware/trunk/make/apache.mk: apache: trigger rebuild with latest template to recovery secondary ipk Nov 13 23:11:20 03bzhou * r4475 10optware/trunk/make/apache.mk: apache: small Makefile fix Nov 13 23:35:39 03bzhou * r4476 10optware/trunk/make/cyrus-imapd.mk: cyrus-imapd: trigger rebuild with latest template to recovery secondary ipks Nov 13 23:39:48 03bzhou * r4477 10optware/trunk/make/fcgi.mk: fcgi: trigger rebuild with latest template to recovery secondary ipk **** ENDING LOGGING AT Tue Nov 14 02:59:57 2006