**** BEGIN LOGGING AT Sat Jan 17 02:59:56 2009 Jan 17 06:36:57 is ntpclient broken in the current version in trunk? Jan 17 06:39:31 I'm trying to compile a package I contributed (bplay) on the latest trunk, and am getting this error: ld: cannot find -lgcc_s Jan 17 06:40:06 what does it mean? This worked on the openwrt version I downloaded about a month ago... Jan 17 06:49:54 This is really strange. Now I'm getting all kinds of error messages that I never got using the older version. things like "Nothing to be done for `compile'." and "configure: error: C compiler cannot create executables" .. what might be going on?? Jan 17 15:29:40 florian * r14067 /trunk/target/linux/brcm63xx/files/arch/mips/bcm63xx/cpu.c: [brcm63x] frequency is in Hz, thanks Joel Jan 17 16:20:44 hi Jan 17 16:20:50 puchu? Jan 17 16:20:55 could someone please apply this patch to trunk? https://dev.openwrt.org/ticket/4450 Jan 17 16:21:15 patch/patches Jan 17 18:34:31 h3sp4wn: ping Jan 17 18:55:56 nbd: Hello Jan 17 19:01:15 hanez * r14068 /feeds/desktop/ (. wm/ wm/openbox/ wm/openbox/Makefile): Created desktop feed in feeds and added wm/openbox to it. Jan 17 19:01:37 h3sp4wn: i'm looking into the eabi stuff again Jan 17 19:01:53 h3sp4wn: i think i saw somewhere that there were still some issues left with eabi and uclibc Jan 17 19:04:56 nbd: The issues are not significant I don't think (haven't tried stuff like Xorg and Gnome etc etc) Jan 17 19:05:20 ok, i noticed that the uclibcgnueabi suffix was missing from the compiler target name again Jan 17 19:05:27 did you add that one back when you did your test builds? Jan 17 19:05:34 or was it before it got reverted accidentally? Jan 17 19:05:50 That was before then Jan 17 19:06:01 ok Jan 17 19:06:42 i'm currently starting to play with eabi on the uncommitted 'goldfish' target (for some google emulator) Jan 17 19:06:53 will see if i run into any further issues Jan 17 19:07:14 hi Jan 17 19:07:21 hi Jan 17 19:07:51 hey Jan 17 19:08:36 h3sp4wn: so what kind of issues did you run into? Jan 17 19:08:41 just so i know when i hit them Jan 17 19:09:50 cyrus * r14069 /branches/8.09/feeds.conf.default: Switch to LuCI 0.8.4 Jan 17 19:14:07 hanez * r14070 /feeds/desktop/wm/karmen/ (. Makefile): Added Karmen window manager to feeds/desktop/wm. Karmen is very lightweight and depends only on libX11. Jan 17 19:15:49 nbd * r14071 /trunk/rules.mk: add eabi suffix to the target name Jan 17 19:20:21 nbd * r14072 /trunk/toolchain/gcc/patches/4.1.2/ (010-pr34130.patch 802-fix-ICE-in-arm_unwind_emit_set.patch): add gcc eabi patches from #3988 Jan 17 19:27:01 nbd: If I was using binutils-2.18 it produced technically duff binaries (something wrong with the elf header) Jan 17 19:27:30 in the flags? Jan 17 19:27:59 file foo.so - it was in the top part Jan 17 19:28:34 i only had problems with the elf binaries when i added -mabi=aapcs-linux instead of forcing gcc to the right target type Jan 17 19:28:43 at least that was back when i tested it with 2.17 Jan 17 19:28:58 That issue is gone if you use binutils 2.19 Jan 17 19:29:11 (or 2.18.50.0.x) Jan 17 19:29:20 interesting Jan 17 19:29:36 currently commiting your 2.19 version Jan 17 19:31:05 opkg was not working right unless it was over the network Jan 17 19:31:22 interesting Jan 17 19:31:38 should be easy to reproduce once i have my target running Jan 17 19:31:46 i.e if you scp'ed an ipk to /tmp and then tried to install it then it thought the file size was some huge number Jan 17 19:31:46 i'll look into it Jan 17 19:31:56 wasn't that fixed by the ftruncate fix? Jan 17 19:33:35 I don't know its not something I need to do often Jan 17 19:34:28 gcc-4.2.4 never gets past the mounting rootfs Jan 17 19:34:46 (with either eglibc or uclibc) Jan 17 20:30:48 nbd * r14074 /trunk/toolchain/uClibc/patches/220-libpthread_arm.patch: uclibc: fix the new libpthread implementation on arm Jan 17 20:32:29 nbd * r14073 /trunk/toolchain/uClibc/patches/ (3 files): add uclibc eabi patches from #3988 Jan 17 20:32:29 nbd * r14075 /trunk/toolchain/binutils/ (7 files in 2 dirs): add binutils 2.19 (patch from #4367) Jan 17 20:37:02 nbd * r14077 /trunk/rules.mk: Revert r14071 Jan 17 20:37:14 how to segregate eth0 and ath0 even after removing bridge Jan 17 20:37:22 it pings the other side Jan 17 20:50:58 just make a separate config for your wifi Jan 17 20:51:04 without the ifname part Jan 17 20:51:20 reference it from the appropriate wifi-iface section from /etc/config/wireless Jan 17 20:53:55 its not in the bridge Jan 17 20:54:01 option type is none on both Jan 17 20:54:25 did you check the firewall defaults? Jan 17 20:54:32 its disbled Jan 17 20:54:35 no rules Jan 17 20:54:48 then it defaults to ACCEPT for FORWARD Jan 17 20:54:55 which allows the traffic to go through Jan 17 20:54:56 one thing i saw i ping the other side and i don't get any traffic on forward chain Jan 17 20:55:18 it all remains on input chain Jan 17 20:55:50 with pinging the remote side did you mean pinging the local address of the other interface from your ap Jan 17 20:55:53 ? Jan 17 20:55:57 remote side Jan 17 20:56:13 pc ..... eth0:ath0 Jan 17 20:56:17 pinging the ath0 Jan 17 20:56:37 you mean from pc to the ip that is assigned to ath0? Jan 17 20:56:42 or something behind ath0? Jan 17 20:56:44 ya Jan 17 20:56:50 and i'm connected to eth0 Jan 17 20:56:51 which one? Jan 17 20:57:21 pc...........etho:2317:ath0 Jan 17 20:57:28 pinging the ath0 Jan 17 20:57:35 ok, that will always work Jan 17 20:57:45 since linux filters based on interface, not ip Jan 17 20:57:59 it'll still treat traffic to the ath0 ip as something destined for eth0 Jan 17 20:58:28 but shud i ping without natting or routing Jan 17 20:58:36 ye Jan 17 20:58:36 but shud it* Jan 17 20:58:37 yes Jan 17 20:59:01 normally never seen on hw with 2 lan cards Jan 17 20:59:11 u need to nat or route to reach the other side Jan 17 20:59:53 depends on whether rp_filter is on Jan 17 21:00:02 ok Jan 17 21:00:10 so i shud disable it then ? Jan 17 21:00:41 its disables already :( Jan 17 21:13:56 nbd i'll be posting the details on forum Jan 17 21:15:39 if rp_filter is on, it'll start blocking Jan 17 21:18:57 no i doesn't Jan 17 21:19:04 its something in hardware Jan 17 21:19:20 traffic flowing frm eth0 to ath0 shud pass thru forward chain Jan 17 21:19:22 am i rt sir Jan 17 21:19:53 no Jan 17 21:20:04 if you ping the ip of ath0 it's INPUT, not FORWARD Jan 17 21:20:15 since it's going to a local ip Jan 17 21:20:23 no its not going Jan 17 21:20:47 ? Jan 17 21:21:14 192.168.111.13...............192.168.111.1(eth0).....(ath0)192.168,201.2 Jan 17 21:21:33 13 is pc Jan 17 21:21:47 if i ping from pc to 192.168.201.2 Jan 17 21:21:47 you don't get what i'm saying Jan 17 21:21:51 eth0 and ath0 are on the same device Jan 17 21:22:05 even if its in routing mode ? Jan 17 21:22:08 thus if you ping the .2, you're still pinging the same device that's reachable over eth0 Jan 17 21:22:12 thus it's not routing Jan 17 21:22:18 it's accepting foreign traffic Jan 17 21:22:35 how to do it pure routing mode Jan 17 21:22:47 i don't have any bridge interface ? Jan 17 21:22:57 why is it important Jan 17 21:23:07 i want source routing Jan 17 21:23:17 i'd got multiple subnets on lan Jan 17 21:23:27 and wnat ot do natting and src routing Jan 17 21:23:37 then filter based on the ip for the interfaces and keep rp_filter enabled Jan 17 21:23:42 the uci firewall disables sourc routing by default Jan 17 21:23:46 if you add rules for that it should work Jan 17 21:24:07 firewall is disabled Jan 17 21:24:11 ok Jan 17 21:24:25 i did and i had some problem thts y i got confused Jan 17 21:25:44 rp filter enabled on all interface ? Jan 17 22:22:58 nico * r14080 /trunk/toolchain/uClibc/Makefile: [toolchain] fix linux headers & source paths at uClibc config stage Jan 17 23:07:04 --: /aux/src/openwrt/build_dir/target-i386_uClibc-0.9.29/luci-0.8.3/build/mkversion.sh: No such file or directory Jan 17 23:07:04 make[3]: *** [/aux/src/openwrt/bin/packages/i386/luci-core_0.8.3-1_i386.ipk] Error 127 Jan 17 23:07:41 update the feeds Jan 17 23:08:06 to what? Jan 17 23:08:17 luci 0.8.4 Jan 17 23:08:43 should that be in feeds.conf.default? Jan 17 23:08:48 yes Jan 17 23:08:53 isn't afaict Jan 17 23:09:11 it's since r14069 afaik Jan 17 23:10:13 https://dev.openwrt.org/browser/trunk/feeds.conf.default Jan 17 23:10:32 ah trunk Jan 17 23:10:40 moment Jan 17 23:18:55 hm, no issues, can you run: ./scripts/feeds update luci ? Jan 17 23:19:06 then try to build again Jan 17 23:19:47 i did a scripts/feeds update -a ; scripts/feeds install -a before Jan 17 23:19:57 when was before? Jan 17 23:20:14 before i got the error message above and then retried and got the same thing Jan 17 23:20:53 for kicks, i switched the feed to http://svn.luci.subsignal.org/luci/trunk/contrib/package/ and an retrying Jan 17 23:20:58 am Jan 17 23:21:24 ok, I think I found the problem, I forgot to bump the version in the makefile, therfor buildroot will re-use a previously checked out tarball with a newer makefile Jan 17 23:23:07 with luci trunk, i got some noise wrt asterisk-xip and gsm, so i scripts/feeds uninstall'd asterisk-xip Jan 17 23:25:04 I think I'll mark the asterisk-xip as broken Jan 17 23:25:57 the default feed should build now if you update the feed again, it should checkout a new copy now which has the missing files Jan 17 23:26:12 okay Jan 17 23:26:26 as soon as this build finishes i'll give it a try Jan 17 23:26:33 ty Jan 17 23:43:13 luci trunk minus asterisk-xip (and minus some other non-building things from before) and r14080 finished successfully, fwiw Jan 18 00:04:46 xMff: trunk with the src-svn luci http://svn.luci.subsignal.org/luci/branches/luci-0.8/contrib/package feed built okay with my build-failing exclusions Jan 18 00:05:04 good Jan 18 00:05:09 thanks for confirming Jan 18 00:05:28 (none of the exclusions are in the luci feed iirc) Jan 18 00:18:08 thepeople * r14081 /trunk/package/kernel/modules/netsupport.mk: fix compile of iptunnel4 for the 2.4 kernel Jan 18 02:00:07 nbd * r14082 /packages/utils/strace/ (9 files in 3 dirs): fix strace for eabi and newer kernel versions Jan 18 02:35:54 is rc2 done, time to update the room topic? Jan 18 02:36:17 rc2 isn't done yet Jan 18 02:36:41 the topic will be updated once it is **** ENDING LOGGING AT Sun Jan 18 02:59:57 2009