**** BEGIN LOGGING AT Sun May 30 02:59:56 2010 May 30 03:20:29 cshore * r21632 /trunk/target/linux/adm5120/base-files/lib/preinit/ (05_set_preinit_face_adm5120 05_set_preinit_iface_adm5120): adm5120: Fixed name of preinit_iface scriptlet May 30 03:20:40 cshore * r21633 /trunk/target/linux/adm5120/base-files/lib/preinit/05_preinit_do_adm5120.sh: adm5120: Added preinit script to set vars based on cpuinfo during preinit main; This fixes a bug in which the per-board vars were not set due to cpuinfo not being mounted when the adm5120.sh was run May 30 03:20:51 cshore * r21634 /trunk/target/linux/ar71xx/base-files/lib/preinit/03_preinit_do_ar71xx.sh: ar71xx: Added preinit scriptlet to set vars based on cpuinfo during preinit_main. This fixes a bug in which the vars were not set due to /proc not being mounted when ar71xx.sh was sourced May 30 03:21:02 cshore * r21635 /trunk/target/linux/ramips/base-files/lib/preinit/ (. 03_preinit_do_ramips.sh): ramips: Added preinit scriptlet to set vars based on cpuinfo during preinit_main. This fixes a bug in which the vars were not set due to /proc not being mounted when ramips.sh was sourced May 30 03:21:12 cshore * r21636 /trunk/target/linux/brcm-2.4/base-files/lib/preinit/05_failsafe_config_switch_brcm: brcm-2.4: preinit: Removed duplicate failsafe switch config file May 30 03:21:26 cshore * r21637 /trunk/target/linux/brcm-2.4/base-files/lib/preinit/ (20_failsafe_net_echo 20_failsafe_net_echo_brcm): brcm-2.4: preinit: Renamed failsafe echo scriplet to reflect that it is brcm-specific May 30 03:48:54 ping nbd May 30 05:16:58 how can i determine the conditions where the kernel-headers-prepare target causes the kernel tree to be removed and freshly untarred? May 30 05:18:01 I am experiencing this happen every time I run "make" or "make V=99" from the top-level on an X86 target build May 30 05:45:45 build #47 of ar7 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/47 May 30 07:12:12 build #72 of atheros is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/72 May 30 08:51:36 build #68 of ar71xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ar71xx/builds/68 May 30 09:24:12 build #48 of au1000 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/48 May 30 12:28:03 [florian]: ping May 30 12:55:22 <_trine> I flashed the newest trunk and could not get my wifi to work on it so I have had to go back to KAMIKAZE (bleeding edge, r21568) May 30 12:55:50 <_trine> on my wndr3700 May 30 12:56:25 <_trine> as far as I can tell I have all that is required for wifi to work May 30 12:56:43 <_trine> KAMIKAZE (bleeding edge, r21568) works ok May 30 14:36:01 cshore: sed -ne 's/^CONFIG_PACKAGE_\(.*\)=[ym]/\1/p' .config May 30 14:36:36 _trine: thats not enough detail to work with May 30 14:40:05 <_trine> xMff, yes sorry but I panicked a bit and went right back to the working version because I needed my connection for something May 30 14:41:23 <_trine> xMff, there was also another problem which manifested itself with my psybnc connection constantly resetting which was causing a nuisance to others on IRC May 30 14:41:46 <_trine> so I felt I could not let that happen May 30 14:42:42 _trine: :) May 30 14:45:06 <_trine> yeah May 30 14:47:30 <_trine> the newest trunk is most likely the openwrt version od mkd3 May 30 14:47:30 <_trine> :) May 30 14:47:41 <_trine> /s/od/of May 30 17:23:59 I am having build issues with the x86 target on the most recent build from trunk. $toplevel/build_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1/linux-2.6.32.14/include/asm-x86/ does not exist and causes the build to fail in kernel-headers-prepare May 30 17:25:20 If I try to create this directory, and re-run "make V=99", the kernel-headers-prepare wipes my kernel directory and re-extracts the kernel tarball May 30 17:56:02 okay, anyone know git-svn? I want to have a git tree for luci that keeps up to date with luci svn, and which I can push onto my git server, then, in another machine, use nbd's gsc to take the git repository and the luci svn and end up with a commitable tree. May 30 17:57:27 cshore: Please also sign the petition to the openwrt developers. May 30 17:57:36 The one about moving to git, I mean. ;) May 30 17:58:03 there's a git mirror May 30 17:58:17 and the main repo will not be switched to git anytime soon May 30 17:58:21 xMff: not of luci May 30 17:58:23 Is not the same think as git. May 30 17:58:31 thing May 30 17:58:48 cshore: http://nbd.name/gitweb.cgi?p=luci.git;a=summary May 30 17:58:59 ah, ok, thanks May 30 17:59:35 xMff: you told me there wasn't one :P May 30 18:05:47 none from me May 30 18:23:49 jow * r21638 /trunk/package/base-files/ (4 files in 4 dirs): May 30 18:23:50 [package] base-files: May 30 18:23:50 - use add_dns() and remove_dns() for when changing resolv.conf.auto for static or dhcp interfaces May 30 18:23:50 - force 0644 permissions when creating resolv.conf.auto, fixes dnsmasq permissions denied problem with pppd interfaces May 30 18:23:50 - revert dns servers in /sbin/ifdown May 30 18:23:50 - bump package revision May 30 18:40:24 jow * r21639 /branches/backfire/package/base-files/files/ (3 files in 3 dirs): [backfire] merge r21638 May 30 19:06:10 <_trine> I have just compiled and flashed trunk and wifi works again on the wndr3700 May 30 19:50:10 hi May 30 19:50:41 i am running into a strange problem when compiling a *default* backfire for x86 Alix May 30 19:51:27 http://pastebin.com/SuSqP8rN May 30 19:51:54 seems like grub can't be built but must be somehow connected to me compiling it on x86_64 (which is weird) May 30 19:54:43 and this is the config.log file: http://pastebin.com/NhVQDadu May 30 19:54:52 anyone encountered this or have a clue? May 30 20:05:20 hmmm May 30 20:05:45 even a simple ./configure in the grub dir breaks on x86 in backfire May 30 20:05:51 can't be... May 30 20:05:59 *wonder* May 30 20:25:30 aroscha: are you using grsec-patch on your build machine? afair there were some problems with grub and grsec. *just_guessing* May 30 20:25:56 soma: not knowingly May 30 20:26:14 I am using ubuntu 10.04 May 30 20:26:24 then most probably not May 30 20:26:32 ok May 30 20:27:20 point is, if I change into the build_dir/host/grub-0.97 dir and do a simple ./configure, it will already complain that gcc can not create files May 30 20:27:26 I digged further into it May 30 20:27:35 looks like the parameter -V is used May 30 20:27:44 which suddenly expects a parameter May 30 20:28:10 configure:2422: checking for C compiler default output file name May 30 20:28:12 configure:2425: gcc -m32 conftest.c >&5 May 30 20:28:38 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/libgcc.a when searching for -lgcc May 30 20:28:51 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/libgcc.a when searching for -lgcc May 30 20:29:07 /usr/bin/ld: cannot find -lgcc May 30 20:29:09 ok May 30 20:29:12 so that is one error May 30 20:29:17 the second being: May 30 20:29:28 configure:2396: gcc -V &5 May 30 20:29:29 gcc: '-V' option must have argument May 30 20:29:48 wait! May 30 20:29:51 I think I have it May 30 20:29:56 I need the 32bit gcc libs May 30 20:30:00 grr May 30 20:30:01 aroscha: right May 30 20:30:02 right May 30 20:30:06 so simple May 30 20:30:09 sorry May 30 20:30:33 sometimes you stare at things for 1h and if you try to explain it to someone it jumps at your face :) May 30 20:34:26 ok May 30 20:34:44 so here is a fix for the docu for ubuntu 10.04 on X86_64: May 30 20:34:47 first do sudo aptitude install gcc-4.4-multilib May 30 20:34:51 :) May 30 20:34:53 thx everybody ! May 30 20:35:03 for helping to think this through May 30 20:44:09 Are you folks actually using ccache for speeding up compilation or not? May 30 20:44:28 or a simple "make -j $NUM_CPUs" ? May 30 20:44:48 * xMff uses -j $NCPUS + 1 May 30 20:44:58 why the +1 ? May 30 20:45:23 threads are often stalled while downloading stuff or unpack .tgzs May 30 20:45:28 ah right May 30 20:45:31 true May 30 20:46:14 also moving my buildroot away from the system disk helped a lot May 30 20:48:43 xMff: what is currently the default httpd for luci? uhttpd? May 30 20:49:21 soma: yes, uhttpd May 30 20:50:30 xMff: i see, thx May 30 20:50:33 ok, because i noticed that when installing luci-freifunk-community the depency to it seems to be missing. but i'll have to investigate that further May 30 20:51:10 soma: that is certainly true May 30 20:51:35 which part of it? May 30 20:54:05 the -community packages has no dependency on any httpd May 30 20:54:29 there is a new meta-package "luci" or "luci-ssl" which depends on all the common stuff May 30 20:54:52 the community one should either depend on one of those meta packages or on the httpd directly May 30 20:55:07 hm ok, but before 10.03 it was enough to just install it May 30 20:55:39 yeah because there was always the busybox httpd May 30 20:55:51 since backfire there is no httpd anymore by default May 30 20:55:52 yes, thats what i also tried so far, adding depencies to it May 30 20:56:51 i just was not sure if that would be desired. because then one can't probably use another httpd with it, but no idea if somebody needs this May 30 21:12:04 one thing that gets me a bit confused... we have 3 different olsrd packages May 30 21:12:29 i guess I should talk with Saverio and jow if we can merge those May 30 21:12:34 somehow May 30 21:12:40 otherwise it might be confusing May 30 21:13:04 where is the thrid one? May 30 21:13:45 hm, Saverio maintains it somewhere on his server but asks people to pull in his feed May 30 21:13:59 I have no objections in gettings all versions merged May 30 21:14:08 jow, is there anything special in yours? May 30 21:14:20 like special for the FF nets? May 30 21:14:20 only the sven-ola stripdown May 30 21:14:23 k May 30 21:14:28 and two minor patches May 30 21:14:37 hmmm May 30 21:14:41 plus one openwrt specifc May 30 21:16:15 ah May 30 21:16:21 some magic arprefresh stuff May 30 21:16:26 never knew what its good for May 30 21:16:39 I took the initial patch series from the FFF May 30 21:18:37 for our servers we always grabbed the release tarball from olsr.org and compiled that May 30 21:18:42 no issues noticed May 30 21:18:55 i see May 30 21:18:59 so I think vanilla will be fine in the network too May 30 21:19:13 okay, that would be the very best I guess May 30 21:19:17 the strip down stuff can be purged May 30 21:19:30 should we ask sven-ola first? May 30 21:19:38 there is one openwrt patch that disables the sysctl stuff in olsrd May 30 21:19:42 I know for sure he invested lots of time into that :) May 30 21:19:56 you could ask him May 30 21:19:59 will do May 30 21:20:11 I still have no clue whats the definitive codebase for FF networks nowadays May 30 21:20:18 hehe May 30 21:20:26 I guess that is a bit mixed :) May 30 21:20:28 all I know is that its not the one from olsr.org :) May 30 21:20:47 makes it harder to fix and debug stuff May 30 21:21:42 anyway... I did not hear much complaints about olsr from the freifunk networks May 30 21:22:12 that could mean a) henning (mostly him) and markus did a realy good job for the latest releases or ... b) nobody cares anymore :) May 30 21:22:49 I am a bit out of the loop, our network is shrinking here May 30 21:22:57 ahh May 30 21:23:01 i see May 30 21:23:22 i just can tell for our nodes that there were no real problems since maybe 0.5.4. but its small, only 20-25 nodes May 30 21:23:26 funkfeuer is also looking more into fibre lately May 30 21:23:37 soma: I see May 30 21:24:01 soma: yes, with these number of nodes (provided that layer 2 is OK) most anything will be OK I guess May 30 21:24:18 aroscha: however, we're helping two smaller networks in two villages, they have a very homogenous setup May 30 21:24:28 aroscha: they plan to roll out 0.6.0 at some point May 30 21:24:33 on all nodes at once May 30 21:24:36 xMff: i see. nice! May 30 21:24:46 I am curious on feedback May 30 21:25:21 the next step (and everybody is afraid of it) will be to forward merge 0.6.x code to the experimental branch May 30 21:25:56 some important things are fixed in the experimental branch (such as MPR) but the patches for stability are all in 0.6.x May 30 21:26:10 wil be a crazy amount of work May 30 21:26:41 we need more participants/coders at olsr.org . Henning and Markus alone is ... well, it is really a lot May 30 21:26:55 speaking of general stuff: May 30 21:27:04 well we all need more coders :) May 30 21:27:14 will you be coming to the wireless summit (http://www.wirelesssummit.org) ? May 30 21:27:24 in case you need travel stipends, let me know May 30 21:27:49 I would like to have all community wi-fi folks worldwide meet there May 30 21:27:55 okay. I am not yet sure. Buried with (paid) work May 30 21:28:03 we got a bit of budget to fly in people May 30 21:28:06 i see May 30 21:28:17 well, try to reserve it ok? May 30 21:28:28 I'll keep it in mind May 30 21:28:29 the earlier you can tell me, the better May 30 21:28:33 yes, please May 30 21:28:53 it (the summit) lives from the people and the exchange hapening there May 30 21:29:09 it is AFAIK the only such truly international one May 30 21:29:36 last year we had 144 people from realy all over the world (india, south america, etc) May 30 23:49:50 jow * r21640 /trunk/package/firewall/ (4 files in 2 dirs): [package] firewall: fix support for netranges in redirect and rule sections May 31 00:38:49 Here is a log of my build failure when making an x86 target http://openwrt.pastebin.ca/1874483 May 31 00:40:58 Once I get to this point of the build, every time i run make, it re extracts the whole kernel tarball and gives me the same error. May 31 00:41:41 i am using a git tree and i ran a git clean -x -r -f prior to this build May 31 00:58:18 republic: try reverting https://dev.openwrt.org/changeset/21567 May 31 00:59:15 ok xMff i'll give that a shot May 31 01:22:39 jow * r21641 /trunk/package/base-files/files/etc/hotplug2-common.rules: [package] base-files: don't skip subsequent hotplug rules when doing makedev for tun or tap interfaces - this fixes support for uci managed OpenVPN interfaces and other externally created tuntap devices May 31 01:34:49 jow * r21642 /trunk/package/firewall/files/lib/ (config.sh fw.sh): [package] firewall: change the order of IPv4/IPv6 address detection, fixes mixed notation v6 improperly detected as v4 address May 31 01:53:30 updated openwrt/upstream, http://home.comcast.net/~sdwalker/uscan/uscan.shtml **** ENDING LOGGING AT Mon May 31 02:59:56 2010