**** BEGIN LOGGING AT Thu Jun 29 02:59:57 2006 Jun 29 05:55:37 placid_ , it was terminfo check causing the trouble. Jun 29 06:18:11 aha Jun 29 06:29:23 03marcusb * r30 10debian/ixp400-accesslib/branches/upstream/ (86 files in 54 dirs): Imported new upstream release 2.1.1. Jun 29 08:04:11 03oleo * r3525 10optware/trunk/ (Makefile make/setpwc.mk): optware: setpwc initial import Jun 29 17:02:12 hey, are there any devs here that can help me? Jun 29 17:02:31 i'm trying to develop a new package, but i'm unsure how i can test it Jun 29 17:02:52 i am cross compiling, my compile machine is ubuntu run through vmware Jun 29 17:03:14 so when i run make, i think i am getting an x86 binary Jun 29 17:03:22 which wont work on the slug Jun 29 17:03:35 is this correct? Jun 29 17:05:01 is it actually possible to test a package before you commit it to svn if you are not compiling natively? Jun 29 17:05:26 hey, AdamBaker, could you give me a little advice (again) :) Jun 29 17:06:59 i'm developing my package through cross compilation. so when i make, i build an x86 binary that doesn't work on the slug. is this correct? Jun 29 17:07:38 so i run make -ipk; i get an ipk file; i use ipkg -install to install it Jun 29 17:07:51 should this binary work on the slug? Jun 29 17:23:44 whois iwo Jun 29 17:23:50 oops sorry :) Jun 29 17:25:40 <[1]gandhijee> iwo: you can not run x86 code on the slug Jun 29 17:25:45 <[1]gandhijee> you need a crosscompiler Jun 29 17:27:26 ah, i get the impression that the optware .mk template handles crosscompiling? Jun 29 17:27:58 since i just compiled gzip on my ubuntu cross compiling maching, and it works when i load it onto the slug Jun 29 17:28:20 gandhijee: i get the impression that the optware .mk template handles crosscompiling? Jun 29 17:28:28 since i just compiled gzip on my ubuntu cross compiling maching, and it works when i load it onto the slug. Jun 29 17:28:57 i dunno then, i have no idea how thier scripts work Jun 29 17:28:59 so if i have edited the .mk template for my package, the binary it builds *should* work on the slug Jun 29 17:29:11 ye Jun 29 17:29:18 which means that the app just doesn't work :z Jun 29 17:29:21 :\ Jun 29 17:29:35 is your gzip app reporting that it is for x86? Jun 29 17:29:47 no, it works Jun 29 17:30:15 run file on it Jun 29 17:30:23 file gzip Jun 29 17:30:54 "file: No such file or directory" Jun 29 17:31:12 when i run file on my dev machine agains't busybox i get thise Jun 29 17:31:13 busybox: ELF 32-bit MSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.3, dynamically linked (uses shared libs), stripped Jun 29 17:31:31 this is the command i used on the devel machine Jun 29 17:31:32 file busybox Jun 29 17:32:27 ah, on my ubuntu machine i can use file Jun 29 17:33:19 right, for gzip i get: Jun 29 17:33:57 ELF 32-bit MSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.3, dynamically linked (uses shared libs), not stripped Jun 29 17:34:05 for my app i get: Jun 29 17:34:59 ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped Jun 29 17:35:09 so we can see the problem her ;) Jun 29 17:35:14 here Jun 29 17:36:50 yea Jun 29 17:37:03 so apparently the script wasn't edited properly Jun 29 17:38:09 ah, i think i see my problem, i think i have removed the bit about setting the target opts Jun 29 17:42:37 the reason i commented out this section, is that the app i'm porting doesn't have a 'configure' script :\ Jun 29 17:45:31 what app is it? Jun 29 17:46:33 extract-xiso Jun 29 17:47:30 what's the most simple optware package? (like the smallest, crappiest, most basic package) Jun 29 17:47:52 maybe i can look at the configure script for that Jun 29 17:48:47 adduser must be pretty basic Jun 29 17:50:19 no idea Jun 29 17:50:30 i work on diff hardware Jun 29 17:50:47 just in this room to get help from devs on the compiler and hardware drivers Jun 29 17:50:57 hmm, maybe not :\ (hundreds of files building) Jun 29 17:57:37 you might wanna just study how the scripts work instead of modifying them Jun 29 17:57:40 and write your own Jun 29 18:00:26 my problem is that the extract-xiso Makefile just gets the target OS from the shell Jun 29 18:00:29 (using uname) Jun 29 18:00:49 so it just assumes that your build platform is your target platform Jun 29 18:01:24 so i really need to modify the make file so that it uses a target that has been configured (through ./configure) Jun 29 18:01:56 that is modify the extract-xiso Makefile (not my optware .mk file) Jun 29 18:20:04 iwo__, you have build your cross compile environment with http://www.nslu2-linux.org/Makefile ? Jun 29 18:20:36 i just did it by making one of the existing packages (gzip) Jun 29 18:21:05 it took an hour or something, and downloaded the whole set of cross compile tools Jun 29 18:21:35 then have a look at make/wakelan.mk, which is realy simple as an example Jun 29 18:23:50 nice. the configure file is like 15 lines :D Jun 29 18:35:29 what is the tool used to create .patch files? Jun 29 18:35:35 diff i think Jun 29 18:35:44 i was in another room Jun 29 18:43:26 has anyone ever had trouble with the /usr/sbin/umount_flash binary or with /etc/rc.d/rc.halt in general? the filesystems on my unslung flashdrive get corrupted when during power cycles, but are not affected by reboots. Jun 29 18:43:43 -when Jun 29 19:16:42 err no, that binary must be for the internal flash... Jun 29 19:58:26 is there a way to use variables defined in the main optware Makefile, in my package's Makefile? Jun 29 19:58:33 like, e.g. TARGET_CC Jun 29 19:58:45 or even ${TARGET_CC) Jun 29 20:06:17 no idea Jun 29 23:01:50 placid_: any luck with rtorrent? Jun 29 23:12:32 pvh: been busy with other things. what's wrong with the version currently in the stream? Jun 29 23:19:08 placid_: can't monitor a directory with this version. Jun 29 23:19:45 placid_: i'm trying to set up hands-off torrent downloading for the household Jun 29 23:20:04 pvh: ok. well it almost builds with the latest version but I have one incorrect lib path that I need to resolve Jun 29 23:26:58 placid_: well, i'm looking forward to it. if you don't mind, i'll keep reminding you every day or two. ;) Jun 29 23:27:08 pvh: np Jun 30 00:17:38 03bzhou * r3526 10optware/trunk/make/py-sqlalchemy.mk: py-sqlalchemy: upstream upgrade to 0.2.4 Jun 30 00:18:14 03bzhou * r3527 10optware/trunk/make/py-curl.mk: py-curl: upstream upgrade to 7.15.4.1 Jun 30 00:30:11 rwhitby, as Intel changed the licence for the ixp4xx-2.1.1-libraries to BSD, is it still necessary to have the click-through intel-licence-agreement for newer HEAD-images? Jun 30 00:30:35 yes - the license on the microcode has not changed. Jun 30 00:32:06 rwhitby, thanks for the info. do you think something like http://www.nslu2-linux.org/wiki/FAQ/FirmwareMatrix is usefull? Jun 30 00:32:59 sure Jun 30 00:35:10 ok, i'll try to keep the table up to date ;) Jun 30 00:46:02 EvilDevil: sweet Jun 30 01:26:29 rwhitby, I just noted that the announcement in the News paragraph on www.slug-firmware.net is somehow wrong: 2006-03-11 - DebianSlug Release <- but it should be Debian/NSLU2 Jun 30 01:38:28 strange... if i build the ixp4xx-kernel-2.6.17 w/o DVB support, the size of the kernel image = 951kb, if DVB support is enabled, the size is 949kb, -2kb *??* Jun 30 01:45:58 weird, makes no sense Jun 30 01:49:44 -CONFIG_INPUT_EVDEV=m +CONFIG_INPUT_EVDEV=y (first .config: w/ DVB, second w/o DVB) Jun 30 02:08:22 hmm... i must have somehow set EVDEV to m... EVDEV=y && DVB=y results in the same size (951kbytes) Jun 30 02:17:44 03bzhou * r3528 10optware/trunk/make/py-lxml.mk: py-lxml: upstream upgrade to 1.0.2 Jun 30 02:17:48 -rw-r--r-- 1 evildevil evildevil 973532 2006-06-30 04:33 debianslug/tmp/deploy/images/zImage-nslu2le Jun 30 02:17:48 -rw-r--r-- 1 evildevil evildevil 973536 2006-06-30 04:23 /tmp/kernel-dvb Jun 30 02:19:06 rwhitby-away, wouldn't it be nice to spend 4 bytes to support DVB-devices on SlugOS? ;) Jun 30 02:50:20 03bzhou * r3529 10optware/trunk/make/swi-prolog.mk: swi-prolog: upstream upgrade to 5.6.15 **** ENDING LOGGING AT Fri Jun 30 02:59:57 2006