**** BEGIN LOGGING AT Tue Jun 07 02:59:57 2011
Jun 07 05:27:21 <builder_> build #39 of ar7 is complete: Failure [failed shell_4]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/39
Jun 07 05:53:04 <builder_> build #39 of sibyte is complete: Failure [failed shell_4]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/39
Jun 07 06:26:12 <builder_> build #38 of avr32 is complete: Failure [failed shell_4]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/38
Jun 07 06:46:45 <builder_> build #49 of at91 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/49
Jun 07 06:47:27 <builder_> build #48 of ubicom32 is complete: Failure [failed compile_3]  Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/48
Jun 07 06:57:57 <builder_> build #44 of ramips is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/44
Jun 07 07:21:17 <builder_> build #43 of rb532 is complete: Failure [failed shell_4]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/43
Jun 07 08:37:42 <CIA-89> mirko * r27122 /trunk/toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch: [toolchain/gcc] remove empty file (patch went upstream and file didn't get deleted but only cleared)
Jun 07 08:51:32 <KanjiMonster> russell--: no
Jun 07 09:06:20 <mirko> MarkV: You're Mr Mentovai?
Jun 07 09:12:14 <mirko> I'm experiencing ICE's (gcc internal errors) with gcc 4.5.x with linaro enhancements when compiling openssl with -O3 - let's see whether this is the same with different flags / archs...
Jun 07 09:12:27 <mirko> (it's armv5te btw)
Jun 07 09:13:27 <russell--> KanjiMonster: that is unfortunate.
Jun 07 09:14:48 <russell--> or, at least, it might be
Jun 07 09:15:14 <KanjiMonster> mirko: I think "markmentovai" (as in "markmentovai [~markmento@nat/google/x-muzakeoxsujkpgnv] has quit IRC: Quit: markmentovai") is mark mentovai ;)
Jun 07 09:16:56 <KanjiMonster> russell--: unfortunately phy_drivers do not have the concept of platform_data
Jun 07 09:18:11 <russell--> somehow the 493g needs to be configured differently from the 450g
Jun 07 09:19:18 <russell--> unfortunately, i need to go fall asleep now
Jun 07 09:47:44 <KanjiMonster> Hauke: http://inuyasha.ath.cx/~jonas/0001-SSB-Add-Serial-Flash-support.patch - this doesn't compile in this state as this misses some more or less trivial changes: it uses the mtd_init_partitions from the parallel flash driver; and the parallel flash driver needs to check the chipco.capabilities for parallel flash, too
Jun 07 09:49:26 <KanjiMonster> Hauke: the mtd_partition_init should probably an mtd_partition_parser like ar7part for mainline inclusion
Jun 07 09:50:34 <Hauke> KanjiMonster: I haven't had a closer look at the flash stuff yet, but the actual parallel flash driver needs some work before it could be included into mainline
Jun 07 09:51:30 <Hauke> KanjiMonster: if you would like to work on the flash driver feel free to do so
Jun 07 09:51:49 <Hauke> I will not do anything till the weekend in that area
Jun 07 10:00:26 <KanjiMonster> Hauke: like? yes, should? no - I should first finish the other things I started - maybe later ;)
Jun 07 10:02:09 <KanjiMonster> Hauke: also there's still some #ifdef CONFIG_MTD_PARTITIONS in there, this should go away for mainline as this is now implicit with MTD
Jun 07 10:25:12 <CIA-89> mirko * r27123 /packages/libs/tokyocabinet/ (4 files in 2 dirs): [packages] add library 'tokyocabinet' - thanks to Obinou
Jun 07 10:25:15 <CIA-89> mirko * r27124 /packages/net/seeks/ (8 files in 3 dirs): [packages] add package 'seeks' - thanks to Obinou
Jun 07 12:49:11 <JugglerLKR> hello
Jun 07 12:49:54 <JugglerLKR> what do i have to change in uboot after upgrading flash chip from 4 to 8mb?
Jun 07 13:02:01 <[florian]> if the flash size is not hardcoded, nothing
Jun 07 13:02:13 <[florian]> supposing that your flash can be queried using cfi, it should be transparent
Jun 07 13:08:03 <atp131> router model?
Jun 07 14:00:00 <mazilo> Is there a way to put into an OpenWRT Makefile package so that it won't get compiled after X package has been compiled. That's if X package is also enabled.
Jun 07 14:00:28 <jow_laptop> yeah, its called a dependency
Jun 07 14:01:07 <mazilo> If I use dependency, then it will also compile package X which is not needed.
Jun 07 14:01:37 <jow_laptop> why do you need it then?
Jun 07 14:03:44 <mazilo> For instance, I ported unixodbc to OpenWRT. If I enable unixodbc as well as erlang packages (needed by FreeSWITCH), erlang package will break the compilation after unixodbc first gets compiled. I have to manually clean unixodbc and manually compile erlang and unixodbc packages in that order for both packages to get compiled without a problem.
Jun 07 14:04:03 <jow_laptop> you should fix the root cause then
Jun 07 14:04:17 <jow_laptop> enforcing dependencies will not help
Jun 07 14:04:36 <jow_laptop> someday a hypothetical package comes along which breaks it again
Jun 07 14:09:58 <mazilo> jow_laptop: I wish I know how to fix this problem. I am hoping you and/or anyone here can help. Anyway, here (http://pastebin.com/4jdsRpHC) is the log.
Jun 07 14:10:32 <jow_laptop> /usr/include/pthread.h
Jun 07 14:10:38 <jow_laptop> it pulls in host headers again
Jun 07 14:11:49 <mazilo> jow_laptop: That is from erlang package. However, it doesn't seem to do that if unixodbc package isn't compiled first.
Jun 07 14:12:30 <jow_laptop> this suggests that unixodb installs a *.pc or *-config file in staging_dir/target-*/ which contains invalid cflags or ldflags
Jun 07 14:12:40 <jow_laptop> if you remember you already had this with others
Jun 07 14:13:09 <mazilo> jow_laptop: But, I didn't get it resolved and forgot about it until now.
Jun 07 14:13:34 <jow_laptop> a *.la file could cause this too
Jun 07 14:14:37 <jow_laptop> whats in staging_dir/target-*/root-*/usr/lib/pkgconfig ?
Jun 07 14:16:25 <jow_laptop> also is there a staging_dir/target-*/root-*/usr/bin/odbc_config ?
Jun 07 14:16:47 <jow_laptop> or an odbc_config in any other dir within staging_dir/ ?
Jun 07 14:18:04 <mazilo> jow_laptop: There is a staging_dir/target-arm_v5te_uClibc-0.9.32_eabi/usr/bin/odbc_config file
Jun 07 14:18:11 <jow_laptop> ok, paste it
Jun 07 14:18:37 <mazilo> jow_laptop: It is an ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Jun 07 14:18:49 <jow_laptop> ok
Jun 07 14:19:03 <jow_laptop> anything else?
Jun 07 14:19:29 <jow_laptop> oh
Jun 07 14:19:40 <jow_laptop> and it looks like the macports have the exact same problem as you
Jun 07 14:19:48 <jow_laptop> https://trac.macports.org/ticket/16139
Jun 07 14:25:15 <mazilo> jow_laptop: According to the link you provided (macports), we need to create a new patch for erlang package on otp_src_R13A/lib/odbc/configure or otp_src_R13A/lib/odbc/configure.in file.
Jun 07 14:25:26 <jow_laptop> yes
Jun 07 14:27:38 <mazilo> jow_laptop: I took a look at the otp_src_R13A/lib/odbc/configure.in file on line #145, it allows to specify the odbc directory using with_odbc switch.
Jun 07 14:28:08 <jow_laptop> let me download the source
Jun 07 14:29:37 <mazilo> jow_laptop: With this, perhaps all we need is to add with_odbc="..." variable on the OpenWRT Makefile for erlang package.
Jun 07 14:29:42 <jow_laptop> maybe we should update to R14B first?
Jun 07 14:29:57 <mazilo> jow_laptop: Perhaps, taht is even better.
Jun 07 14:30:33 <mazilo> jow_laptop: Once you update to R14B, I will give a try to compile it with unixodbc present.
Jun 07 14:31:07 <mazilo> jow_laptop: If that works, then I can contact Travis to add unixodbc for me to maintain.
Jun 07 14:33:48 <jow_laptop> ok, in the menawhile try adding  with_odbc="$(STAGING_DIR)/usr" to the CONFIGURE_VARS
Jun 07 14:44:16 <mazilo> jow_laptop: The BUILD_LOG still shows the same error messages with using the /usr/include/pthread.h file. But, the V=99 screen capture shows differences as seen here (http://pastebin.com/kHFYxXcT).
Jun 07 14:46:48 <mazilo> jow_laptop: The screen capture shows error compilation on erlang package for host. So, perhaps we need to set the with_odbc="${STAGING_DIR_HOST}/usr/lib"
Jun 07 15:05:39 <mazilo> jow_laptop: I just realized the mistake I made. I put the with_odbc="$(STAGING_DIR)/usr" in the HOST_CONFIGURE_VARS. Now, that I put the with_odbc="$(STAGING_DIR)/usr" in the CONFIGURE_VARS, the compilation finished without a problem.
Jun 07 15:37:09 <CIA-89> hauke * r27125 /trunk/package/kernel/modules/block.mk: kernel: fix call of kmod-pata-cs5535 and kmod-pata-cs5536
Jun 07 15:39:32 <CIA-89> hauke * r27126 /trunk/package/kernel/modules/block.mk: kernel: fix description of kmod-pata-cs5535 and kmod-pata-cs5536
Jun 07 16:15:27 <JugglerLKR> hi
Jun 07 16:15:33 <JugglerLKR> any u-boot gurus here?
Jun 07 16:50:35 <tripolar> hi
Jun 07 16:50:37 <tripolar> ping nbd
Jun 07 16:53:32 <nbd> tripolar: pong
Jun 07 16:53:53 <tripolar> nbd can you apply the patch i sent to the ml for the network init script?
Jun 07 16:54:16 <tripolar> or what do i have to change to get it applied?
Jun 07 16:55:09 <nbd> "flash wearout v2"?
Jun 07 16:56:26 <tripolar> yeah
Jun 07 16:57:20 <nbd> looks good enough, i'll commit it
Jun 07 16:57:24 <tripolar> thanks
Jun 07 17:01:07 <CIA-89> nbd * r27127 /trunk/package/base-files/files/etc/init.d/network:
Jun 07 17:01:07 <CIA-89> base-files: do not write to /etc/config/wireless at boot time unless a new interface was found
Jun 07 17:01:07 <CIA-89> eliminates unnecessary flash write cycles at every boot
Jun 07 17:01:07 <CIA-89> patch by Peter Wagner (tripolar)
Jun 07 17:01:36 <nbd> btw. please send future patches in a format that can be used with git-am - with proper subject, description and signed-off-by
Jun 07 17:02:48 <tripolar> nbd can i create a patch like this?
Jun 07 17:02:53 <tripolar> nbd how can i create a patch like this?
Jun 07 17:03:33 <nbd> your subject line should be <component>: <short description>
Jun 07 17:04:02 <nbd> then the message body should be a long description (not repeating stuff from the short one)
Jun 07 17:04:23 <nbd> and then you can either keep your patch as an attachment, or send it inline (but careful about line wrapping)
Jun 07 17:04:53 <tripolar> okay next time i'll do it
Jun 07 17:07:32 <CIA-89> nbd * r27128 /trunk/target/linux/ar71xx/base-files/etc/inittab: ar71xx: override inittab to enable login on ttyATH0
Jun 07 17:40:17 <KanjiMonster> tripolar: easiest is to use git - it can even send emails for you ;)
Jun 07 17:40:59 <tripolar> KanjiMonster yeah, git is really nice
Jun 07 17:41:18 <KanjiMonster> the learning curve is quite steep though
Jun 07 17:43:11 <netprince> xMff: if I have a host in /etc/hosts with 5 names, ping segfaults.  Four names is ok.
Jun 07 17:43:27 <netprince> xMff: will you try it?  something like this: '192.168.1.1     one two three four five'
Jun 07 17:47:01 <tripolar> netprince: 192.168.1.2     a b c d e r - works here
Jun 07 17:47:44 <tripolar> netprince true - i get no segfault but
Jun 07 17:47:45 <tripolar> ping e
Jun 07 17:47:45 <tripolar> ping: bad address 'e'
Jun 07 17:47:55 <tripolar> a b c d works
Jun 07 17:49:16 <xMff> netprince: what uclibc version?
Jun 07 17:55:02 <netprince> tripolar: try pinging an internet address, not something from the hosts file
Jun 07 17:55:35 <tripolar> netprince works
Jun 07 17:55:39 <netprince> xMff: uclibcxx - 0.2.2-3
Jun 07 17:55:59 <xMff> netprince: the other one
Jun 07 17:57:10 <xMff> netprince: I can't reproduce it on current trunk and on rc5
Jun 07 17:57:15 <tripolar> netprince: opkg list|grep "libc "
Jun 07 17:57:27 <xMff> but I recall some old dns related uclibc issues
Jun 07 17:57:41 <netprince> libc - 0.9.32-71
Jun 07 17:57:48 <tripolar> xMff can you ping the fifth name when u add a host with at least 5 aliases?
Jun 07 17:57:58 <xMff> yes
Jun 07 17:58:16 <tripolar> xMff: im on trunk and here it doesnt work - compiled a few hours ago
Jun 07 17:58:27 <netprince> trunk here too
Jun 07 17:58:30 <netprince> ar71xx
Jun 07 17:59:03 <KanjiMonster> ah, I can reproduce it; it needs 6+ aliases though
Jun 07 17:59:13 <KanjiMonster> or names
Jun 07 17:59:22 <xMff> sorry, my test device is rc5 too
Jun 07 17:59:25 <KanjiMonster> ping e -> segmentation fault
Jun 07 17:59:28 <xMff> will reflash it
Jun 07 17:59:33 <KanjiMonster> (on trunk)
Jun 07 17:59:42 <xMff> there is more weird stuff going on
Jun 07 17:59:56 <xMff> dnsmasq has broken ptr records since a while
Jun 07 17:59:58 <xMff> maybe related
Jun 07 18:00:13 <KanjiMonster> if there's only 5, then ping e works
Jun 07 18:00:36 <netprince> KanjiMonster: I hadn't tried pinging the sixth name, it segfaults as well, nice catch
Jun 07 18:00:52 <tripolar> KanjiMonster: same for me - but i dont get a segfault i only have ping: bad address 'e' for at least 6 aliases and "e" is on the 5th place
Jun 07 18:01:04 <netprince> if I put in 5 names, I cant lookup names not in the hosts file
Jun 07 18:04:26 <tripolar> xMff but doesnt a ping e - look in the host file first befor it connects to the dns server?
Jun 07 18:04:51 <xMff> it all goes through crappy uclibc code
Jun 07 18:05:32 <tripolar> xMff maybe updating uclibc fixes the problem
Jun 07 18:05:48 <xMff> so far uclibc updates always introduced problems
Jun 07 18:07:14 <xMff> I'll take a look at it
Jun 07 18:12:20 <JugglerLKR> hey
Jun 07 18:12:41 <xMff> bah I hate compiling gdb
Jun 07 18:12:48 <xMff> its more gnu autoshit than actual compilation
Jun 07 18:13:12 <JugglerLKR> can you give mw some advices about uboot and mtds?
Jun 07 18:13:40 <JugglerLKR> does uboot know anything about mtds?
Jun 07 18:27:14 <xMff> netprince: #define MAXALIASES  (4)
Jun 07 18:28:35 <xMff> maxtokes is 6 (addr + name + maxaliases)
Jun 07 18:51:09 <xMff> netprince: hmm, this smells like a miscompilation
Jun 07 18:51:25 <xMff> I just replaced uclibc with a debug build and now I get "bad address"
Jun 07 18:55:23 * xMff retries with -O2 -ggdb3
Jun 07 19:03:10 <xMff> okay
Jun 07 19:03:14 <xMff> -O0 -> fine
Jun 07 19:03:18 <xMff> -Os -> segfault
Jun 07 19:03:49 <xMff> gcc seems to remove some boundary checks
Jun 07 19:04:48 <xMff> lets pinpoint it...
Jun 07 19:06:30 <KanjiMonster> xMff: not nice, but definitely interesting find
Jun 07 19:09:56 <xMff> wait
Jun 07 19:12:02 <xMff> there seems to be some unclean buffer or something
Jun 07 19:12:16 <xMff> __read_etc_hosts_r() is called twice
Jun 07 19:12:19 <xMff> the first time its okay
Jun 07 19:12:37 <xMff> the second time the last  char * token is set to 0x80 instead of 0x0
Jun 07 19:12:47 <xMff> which leads to the segfault
Jun 07 19:13:12 <netprince> I'm impressed, it would have taken me 2 days to figure that out
Jun 07 19:14:19 <xMff> I should write a howto debug uclibc
Jun 07 19:14:27 <xMff> ts actually quite easy
Jun 07 19:16:44 <xMff> here's the first and second invocation: http://pastebin.com/7wphHYnD
Jun 07 19:16:56 <xMff> I now suspect the error somewhere in config_read()
Jun 07 19:29:16 <xMff> hm question
Jun 07 19:29:34 <xMff> the offending buffer is allocated on the stack with alloca()
Jun 07 19:29:49 <xMff> are there any guarantees about that being zeroed out?
Jun 07 19:30:39 <KanjiMonster> afaik not
Jun 07 20:03:12 <voyo> xMff:  no, its not guaranted ,its not adviced to use alloca(),  use calloc() instead.
Jun 07 20:03:40 <xMff> well its what uclibc uses
Jun 07 20:04:49 <voyo> well. its smaller, thats the reason probaly ?
Jun 07 20:05:15 <xMff> I just try to track down an improperly cleared buffer
Jun 07 20:05:30 <xMff> and I have difficulties seeing through the pointer forest :)
Jun 07 20:06:36 <xMff> char ***tokens = (char **) parser->data; memset(*tokens, 0, sizeof(*tokens[0]) * ntokens);  <-- this does not seem to properly clear out the tokens array
Jun 07 20:06:49 <voyo> if poss, try to zero it manually (with memset() maybe? )
Jun 07 20:07:14 <voyo> hm
Jun 07 20:07:51 <xMff> char *** is a pointer to an array of chars, right?
Jun 07 20:08:11 <xMff> or rather a pointer to a pointer to an array of char pointers
Jun 07 20:08:18 <voyo> the second
Jun 07 20:08:30 <voyo> indeed, forest of pointers.. :-/
Jun 07 20:08:40 <netprince> pointer to pointer to an array, sheesh, is that really necessary ...
Jun 07 20:08:57 <xMff> the thing is
Jun 07 20:09:09 <xMff> in my specific testcase the tokens array has len = 6
Jun 07 20:09:52 <xMff> *tokens[6] is 0x80
Jun 07 20:10:05 <xMff> after the memset its still 0x80
Jun 07 20:10:13 <xMff> I would have expected it to be 0x0 then
Jun 07 20:10:44 <xMff> erm wait
Jun 07 20:10:45 <voyo> pointers always have const len (quite short), depending on architecture, its just address in memory
Jun 07 20:11:25 <xMff> I smell an off-by-one
Jun 07 20:11:48 <xMff> which properly does not happen with -O0 becase gcc clears the space behind the buffer or something
Jun 07 20:11:51 <voyo> maybe just hire gdb ? ;)
Jun 07 20:11:57 <xMff> I am in gdb
Jun 07 20:12:08 <xMff> but the codeflow is still hard to follow :P
Jun 07 20:12:20 <xMff> also because I have to step through -Os code
Jun 07 20:12:51 <xMff> and the pointer-pointer-pointer things make my head hurt
Jun 07 20:15:05 <voyo> too much beer makes my head hurt too, but I think I prefere it anyway ;)
Jun 07 20:15:27 <xMff> the difference is that beer only hurts tomorrow ;)
Jun 07 20:15:41 <voyo> I would replace this alloc with calloc, so far I know its usually badly implemented, and its not recomended  to use this func..
Jun 07 20:16:38 <voyo> well. gl with your pointers, I looked here only to close this window ;)
Jun 07 20:18:51 <aport> well
Jun 07 20:19:00 <aport> alloca allocates on the stack, while calloc allocates on the heap
Jun 07 20:19:05 <aport> very different syscalls
Jun 07 20:41:14 <xMff> netprince: ok, I have a fix
Jun 07 20:41:51 <xMff> and uclibcs handling of extraneous alias entries is ... innovative
Jun 07 20:42:01 <xMff> root@OpenWrt:/tmp# cat /etc/hosts
Jun 07 20:42:02 <xMff> 127.0.0.1 localhost
Jun 07 20:42:02 <xMff> 1.1.1.1 a b c d e f
Jun 07 20:42:06 <xMff> root@OpenWrt:/tmp# nslookup "e f"
Jun 07 20:42:06 <xMff> Server:    127.0.0.1
Jun 07 20:42:06 <xMff> Address 1: 127.0.0.1 localhost
Jun 07 20:42:06 <xMff> Name:      e f
Jun 07 20:42:06 <xMff> Address 1: 1.1.1.1 a
Jun 07 20:42:40 <xMff> it stops parsing after d (max num of aliases reached) and collapses the rest into one
Jun 07 20:44:23 <RealOpty> xMff, wanna help me get ipv6 going :) ?
Jun 07 20:45:24 <xMff> netprince, KanjiMonster: wget -qO- http://luci.subsignal.org/~jow/uclibc-alias-fix.patch | patch -p0 && make toolchain/uClibc/{clean,compile,install} package/base-files/{clean,compile,install} target/linux/install V=99
Jun 07 21:07:13 <builder_> build #49 of s3c24xx is complete: Failure [failed shell_4 compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/49
Jun 07 21:15:49 <JugglerLKR> how to figure out which kernel used for target?
Jun 07 21:15:56 <JugglerLKR> kernel version
Jun 07 21:19:46 <xMff> grep LINUX_VERSION target/linux/$arch/Makefile
Jun 07 21:43:37 * swalker wonders where the protobuf depends is for seeks
Jun 07 21:48:53 <CIA-89> swalker * r27129 /packages/net/seeks/Makefile: [packages] seeks: store the git hash in the PKG_REV variable
Jun 07 21:52:29 <CIA-89> swalker * r27130 /packages/net/freeswitch/Makefile: [packages] freeswitch: store the git hash in the PKG_REV variable
Jun 07 21:54:35 <CIA-89> jow * r27131 /trunk/toolchain/uClibc/patches-0.9.32/131-inet-fix-__read_etc_hosts_r-segfault.patch: [toolchain] uClibc: fix a crash in __read_etc_hosts_r() that occurs if more than five hostnames follow a dotted quad in /etc/hosts
Jun 07 22:55:57 <builder_> build #31 of mpc52xx is complete: Failure [failed shell_4 compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/31
Jun 07 23:26:05 <CIA-89> jow * r27132 /trunk/package/base-files/ (Makefile files/lib/network/config.sh files/sbin/ifup): [package] base-files: fix error reporting for unsupported protocols on virtual interfaces
Jun 07 23:27:13 <CIA-89> jow * r27133 /branches/backfire/package/base-files/ (Makefile files/lib/network/config.sh files/sbin/ifup): [backfire] merge r27132
Jun 07 23:32:37 <builder_> build #31 of gemini is complete: Failure [failed shell_4]  Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/31
**** ENDING LOGGING AT Wed Jun 08 02:59:56 2011