**** BEGIN LOGGING AT Tue Nov 02 02:59:57 2010
Nov 02 08:17:18 <tommie> WARNING: at /home/openwrt/backfire/build/ar71xx/build_dir/linux-ar71xx/compat-wireless-2010-07-29/drivers/net/wireless/ath/ath9k/xmit.c:148 0x81b67bf0()
Nov 02 08:17:30 <tommie> | Call Trace:[<8007dccc>] 0x8007dccc
Nov 02 08:17:30 <tommie> | [<800683a4>] 0x800683a4
Nov 02 08:17:30 <tommie> | [<800683a4>] 0x800683a4
Nov 02 08:17:35 <tommie> hm, anyone seen that?
Nov 02 08:19:57 <tommie> https://forum.openwrt.org/viewtopic.php?pid=119090 hm, I see...
Nov 02 09:49:27 <danage> [florian]: quick question, is there ethernet support for bcm6345 in trunk? i flashed a snapshot today and the roboswitch doesn't find any eth device
Nov 02 09:49:42 <[florian]> danage: nope, still no support for it
Nov 02 09:49:55 <danage> [florian]: okie thanks :)
Nov 02 11:18:34 <nbd> tommie: old bug, fixed in recent versions
Nov 02 11:28:05 <CIA-76> dingo * r23769 /packages/net/n2n/Makefile: [patch-team] n2n update to release 3875 - Signed-off-by: hanno.schupp@gmail.com
Nov 02 11:45:43 <tommie> nbd: how recent? Some SVN version?
Nov 02 11:46:07 <nbd> was fixed a while ago in backfire SVN, yes
Nov 02 11:49:54 <tommie> ah ok, so not in the release version?
Nov 02 11:50:55 <tommie> nbd: But I'm not sure whether this correlates to my real problem, I have a notebook with another ath9k chip which loses connectivity now and then - although wpa_supplicant still lists the device as asosciated, no data is transported
Nov 02 11:51:15 <tommie> reassoc in wpa_cli then fixes that temporarily
Nov 02 11:54:25 <CIA-76> kaloz * r23770 /trunk/target/linux/generic/config-2.6.36: add some additional 2.6.36 symbol
Nov 02 11:55:48 <CIA-76> kaloz * r23771 /trunk/target/linux/ (2 files in 2 dirs): this is not a platform specific patch
Nov 02 11:57:14 <CIA-76> kaloz * r23772 /trunk/target/linux/generic/patches-2.6.36/990-arm_export_dma_set_coherent_mask.patch: [generic/arm]: add a patch to export dma_set_coherent_mask
Nov 02 12:06:48 <CIA-76> kaloz * r23773 /trunk/target/linux/ixp4xx/ (6 files in 4 dirs): [ixp4xx]: support only 2.6.32 and 2.6.36
Nov 02 12:21:58 <CIA-76> kaloz * r23774 /trunk/target/linux/ixp4xx/patches-2.6.36/ (3 files): [ixp4xx]: remove unneeded patches
Nov 02 12:25:51 <CIA-76> kaloz * r23775 /trunk/target/linux/ixp4xx/patches-2.6.36/402-ixp4xx_gpiolib.patch: [ixp4xx]: update the gpiolib patch
Nov 02 12:26:24 <CIA-76> kaloz * r23776 /trunk/target/linux/ixp4xx/patches-2.6.36/ (18 files): [ixp4xx]: refresh 2.6.36 patches
Nov 02 12:27:37 <CIA-76> kaloz * r23777 /trunk/target/linux/ (ppc40x/config-default ppc44x/config-default): [ppc4xx]: add additional config symbols
Nov 02 12:33:26 <CIA-76> kaloz * r23778 /trunk/target/linux/generic/config-2.6.36: more 2.6.36 config symbols..
Nov 02 12:48:18 <builder> build #16 of xburst is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/16
Nov 02 13:01:56 <CIA-76> kaloz * r23779 /trunk/toolchain/uClibc/ (9 files in 7 dirs): [toolchain]: remove support for uClibc 0.9.30.2 and 0.9.30.3
Nov 02 14:02:00 <CIA-76> kaloz * r23780 /trunk/toolchain/binutils/Config.in: [toolchain]: switch to binutils 2.20.1 (except for avr32 and ubicom32)
Nov 02 14:02:50 <CIA-76> kaloz * r23781 /trunk/toolchain/uClibc/ (Config.in Config.version): [toolchain]: switch to uClibc 0.9.31
Nov 02 15:35:24 <CIA-76> mb * r23782 /packages/net/horst/patches/100-compile-fixes.patch: horst: Fix parallel build. The "buildstamp" rule runs "make clean" in parallel with the objects build. This obviously is no good. Simply remove the stamp.
Nov 02 15:52:29 <CIA-76> mb * r23783 /packages/net/horst/Makefile: horst: Enable parallel build
Nov 02 16:10:25 <CIA-76> mb * r23784 /packages/net/ekg/patches/ (. 100-compile-fixes.patch): ekg: Fix internal dependencies
Nov 02 16:11:01 <CIA-76> mb * r23785 /packages/net/ekg/Makefile: ekg: Enable parallel build
Nov 02 16:19:19 <CIA-76> flyn * r23786 /packages/libs/libdmapsharing/Makefile: Update libdmapsharing to 2.1.8
Nov 02 16:22:27 <CIA-76> flyn * r23787 /packages/net/krb5/Makefile: Fix krb5 category and add maintainer
Nov 02 16:23:07 <CIA-76> flyn * r23788 /packages/net/netatalk/Makefile: Add maintainer to netatalk Makefile
Nov 02 16:24:05 <CIA-76> flyn * r23789 /packages/libs/db47/Makefile: Add maintainer to db47 Makefile
Nov 02 16:27:13 <CIA-76> flyn * r23790 /packages/libs/openldap/Makefile: Add maintainer to openldap Makefile
Nov 02 16:31:51 <CIA-76> nbd * r23791 /trunk/ (Config.in target/Config.in): make the display support feature flag selectable
Nov 02 16:33:05 <CIA-76> nbd * r23792 /branches/backfire/ (Config.in target/Config.in): make the display support feature flag selectable (backport from r23791)
Nov 02 16:37:12 <CIA-76> nbd * r23793 /packages/Xorg/xorg/lib/libX11/Makefile: libX11: depend on DISPLAY_SUPPORT
Nov 02 16:38:12 <CIA-76> nbd * r23794 /packages/Xorg/lib/gtk2/Makefile: gtk2: depend on DISPLAY_SUPPORT
Nov 02 16:41:39 <CIA-76> nbd * r23795 /packages/Xorg/lib/qt4/Makefile: qt4: depend on DISPLAY_SUPPORT
Nov 02 16:43:51 <CIA-76> nbd * r23796 /trunk/package/Makefile: make IGNORE_ERRORS apply to deselected packages as well (typically triggered through dependencies)
Nov 02 16:45:00 <CIA-76> nbd * r23797 /branches/backfire/package/Makefile: make IGNORE_ERRORS apply to deselected packages as well (backport from r23796)
Nov 02 17:01:06 <CIA-76> nbd * r23798 /packages/lang/pyqt4/Makefile: pyqt4: select qt4-gui
Nov 02 17:01:08 <CIA-76> nbd * r23799 /packages/Xorg/lib/qt4/Makefile: qt4: move the @DISPLAY_SUPPORT dependency to qt4-gui, however do not enable any qt4 package by default unless qt4-gui is also enabled
Nov 02 17:11:18 <philipp64|laptop> [florian]: ping
Nov 02 17:33:28 <alicemirror1> Hi to all. I have a strange problem compiling Backfire for a target I'm developing (that should be released next december :) ) After I have set the last kernel configuration (using make kernel_menuconfig) I receive the following error:
Nov 02 17:33:28 <alicemirror1> build_dir/.../linux-2.6.32/drivers/mmc/core/mmc_core.ko 'No such file or directory'
Nov 02 17:33:28 <alicemirror1> In this directory is only present the file mmc_core.o what can I do?
Nov 02 17:58:52 <Wipster> [florian], ping
Nov 02 18:50:54 <_trine> is there any possibility to have a package for failtoban
Nov 02 20:14:44 <CIA-76> mb * r23800 /packages/libs/matrixssl/patches/ (5 files): matrixssl: Fix compile on uClibc-0.9.31
Nov 02 20:15:49 <CIA-76> mb * r23801 /packages/libs/matrixssl/Makefile: matrixssl: Enable parallel build
Nov 02 20:47:38 <aroscha> xMff: ping
Nov 02 20:50:10 <aroscha> xMff: I seem to have a problem with luci - it seems to show the admin interface but a) the main menus are in german b) not all main menus are visible so you can not navigate for example to the admin-> interfaces page
Nov 02 20:54:05 <xMff> aroscha: did you include the freifunk stuff? If yes you're probably seeing the public portion right now
Nov 02 20:54:32 <xMff> there should be an admin link in the upper right corner which reveals the actual stuff
Nov 02 20:55:06 <aroscha> xMff: no, i did not include the freifunk stuff. Yes, I clicked the Admin link upper right hand side
Nov 02 20:55:28 <xMff> odd
Nov 02 20:56:00 <aroscha> yes, i have the feeling I have some wrong setting somewhere and as a result it does not display correctly
Nov 02 20:56:11 <xMff> luci 0.9 ?
Nov 02 20:56:12 <aroscha> i guess I misconfigured some uci setting in config/*
Nov 02 20:58:58 <aroscha> xMff: yes, 0.9 r6342
Nov 02 20:59:13 <xMff> opkg list_installed | grep i18n
Nov 02 20:59:43 <aroscha> english und italian
Nov 02 20:59:55 <aroscha> +svn6383-1
Nov 02 21:00:22 <xMff> hmm
Nov 02 21:00:31 <aroscha> it worked before with these two
Nov 02 21:00:34 <xMff> uci get luci.main.lang
Nov 02 21:00:46 <aroscha> en
Nov 02 21:00:59 <aroscha> aber ein paar menu eintraege sind deutsch :)
Nov 02 21:01:04 <aroscha> main menus
Nov 02 21:01:20 <xMff> yes, this happens if the translation failed to load (on 0.9)
Nov 02 21:01:25 <aroscha> Uebersicht, Status, Dienste
Nov 02 21:01:26 <aroscha> ahhh
Nov 02 21:01:26 <xMff> the german names are relicts in the code
Nov 02 21:02:01 <xMff> opkg list_installed luci
Nov 02 21:02:07 <xMff> opkg list_installed | grep luci
Nov 02 21:03:41 <aroscha> luci - 0.9+svn6383-1
Nov 02 21:04:30 <xMff> the grep thing too
Nov 02 21:04:55 <aroscha> coming
Nov 02 21:05:56 <aroscha> http://pastebin.com/kLjXY85K
Nov 02 21:06:17 <aroscha> as said - these packages where there and already running
Nov 02 21:06:41 <xMff> rm /tmp/luci-indexcache  and reload
Nov 02 21:06:50 <xMff> if the issue persists, I have no idea
Nov 02 21:06:52 <aroscha> point is, some change in etc/config/* must have changed it I guess
Nov 02 21:07:16 <xMff> you can also try  uvl verify network
Nov 02 21:08:04 <aroscha> thanks, i think this way I can find the bug
Nov 02 21:08:16 <aroscha> BTW: there was no /tmp/luci-indexchache
Nov 02 21:08:27 <aroscha> s/chache/cache/
Nov 02 21:09:15 <aroscha> hmmm... uvl verify wireless
Nov 02 21:09:17 <aroscha> unknown error
Nov 02 21:09:26 <aroscha> seems to be the case for all /etc/config files
Nov 02 21:10:07 <xMff> uhm
Nov 02 21:11:35 <aroscha> something is weird...
Nov 02 21:11:42 <xMff> yes
Nov 02 21:11:48 <aroscha> uci set system.hostname=flatterbart
Nov 02 21:11:50 <aroscha> uci commit
Nov 02 21:12:03 <aroscha> # uci commit
Nov 02 21:12:03 <aroscha> uci: Parse error (too many arguments) at line 38, byte 32
Nov 02 21:12:03 <aroscha> uci: Parse error (invalid character in field) at line 2, byte 8
Nov 02 21:12:06 <aroscha> wtf :)
Nov 02 21:12:32 <xMff> did you recently restore the config?
Nov 02 21:12:49 <aroscha> you mean via webinterface (backup/restore)?
Nov 02 21:12:58 <xMff> or via ssh or something
Nov 02 21:13:08 <aroscha> yes, the config was changed slightly
Nov 02 21:13:17 <aroscha> seems like parsing is failing badly now
Nov 02 21:13:31 <aroscha> i can try to bisect the changes and see when it happened
Nov 02 21:14:07 <xMff> do the configs look normal in vi / cat ?
Nov 02 21:15:31 <aroscha> yes
Nov 02 21:15:33 <aroscha> sure
Nov 02 21:15:44 <aroscha> if you want i can send them
Nov 02 21:16:01 <xMff> whats in /tmp/.uci ?
Nov 02 21:16:17 <aroscha> system and ucitrack
Nov 02 21:16:20 <aroscha> both 0 bytes
Nov 02 21:16:28 <xMff> ok and in /var/state ?
Nov 02 21:18:11 <aroscha> firewall network
Nov 02 21:18:25 <aroscha> firewall is 0 bytes
Nov 02 21:18:32 <aroscha> network is 362 bytes
Nov 02 21:19:11 <xMff> are the versions of uci / libuci and libuci-lua in sync?
Nov 02 21:20:49 <aroscha> 2 mins
Nov 02 21:24:53 <CIA-76> mb * r23802 /packages/ipv6/wide-dhcpv6/ (Makefile patches/002-fix-dprintf-clash.patch):
Nov 02 21:24:53 <CIA-76> wide-dhcpv6: Compile for for uClibc-0.9.31.
Nov 02 21:24:53 <CIA-76> We need -D_GNU_SOURCE. However, that also introduces a "dprintf" prototype, which clashes with our local dprintf. We use an ugly workaround. (Don't want to touch every caller of dprintf, because the patch would be huge.)
Nov 02 21:27:46 <aroscha> xMff: yes, I am pretty sure the versions are in sync
Nov 02 21:27:48 <aroscha> let me check
Nov 02 21:29:51 <aroscha> libuci is ./build_dir/target-i386_uClibc-0.9.30.1/uci-2010-09-28.2/ipkg-x86/libuci
Nov 02 21:32:55 <aroscha> libuci-lua: ./build_dir/target-i386_uClibc-0.9.30.1/uci-2010-09-28.2/ipkg-x86/libuci-lua
Nov 02 21:32:58 <aroscha> seems to be ok
Nov 02 21:40:56 <aroscha> xMff: ok, very very strange
Nov 02 21:41:08 <aroscha> i made a new image, settings look sane
Nov 02 21:41:13 <aroscha> but still the same behaviour
Nov 02 21:41:30 <aroscha> is there some version of uci / luci that I should svn checkout which is sane and OK
Nov 02 21:41:36 <aroscha> so that I can narrow it down?
Nov 02 21:41:44 <aroscha> or any other way I can narrow down the problem?
Nov 02 21:42:54 <aroscha> xMff: another interesting thing (maybe a hint?) : I have a text " : 0" left of the "Administration" link (upper right side)
Nov 02 21:49:33 <xMff> do you still see uci errors?
Nov 02 21:50:57 <aroscha> yes
Nov 02 21:50:59 <aroscha> same stuff
Nov 02 21:51:09 <aroscha> uci set system.hostname=foobar
Nov 02 21:51:10 <builder> build #19 of etrax is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/19
Nov 02 21:51:16 <aroscha> # uci commit
Nov 02 21:51:16 <aroscha> uci: Parse error (too many arguments) at line 38, byte 32
Nov 02 21:51:16 <aroscha> uci: Parse error (invalid character in field) at line 2, byte 8
Nov 02 21:51:35 <xMff> what is at /etc/config/system, line 38 ?
Nov 02 21:52:17 <Memphiz> is there any solution for accessing the forum and dev site without https? can only use http at work ...
Nov 02 21:52:52 <aroscha> xMff: hmm. .... somthing wrong
Nov 02 21:52:54 <aroscha> # cat system
Nov 02 21:52:54 <aroscha> config 'system'
Nov 02 21:52:54 <aroscha> 	option 'hostname' 'mgb-1'
Nov 02 21:52:55 <aroscha> 	option 'timezone' 'UTC'
Nov 02 21:52:55 <aroscha> config 'led'
Nov 02 21:52:55 <aroscha> 	option 'name' 'blinki'
Nov 02 21:52:56 <aroscha> 	option 'sysfs' 'alix:1'
Nov 02 21:52:56 <aroscha> 	option 'default' '1'
Nov 02 21:52:56 <aroscha> 	option 'trigger' 'heartbeat'
Nov 02 21:52:57 <aroscha> config 'rdate'
Nov 02 21:52:57 <aroscha> 	option 'interface' 'lan'
Nov 02 21:52:57 <aroscha> config 'foobar' 'hostname'
Nov 02 21:53:24 <xMff> no thats fine
Nov 02 21:53:30 <aroscha> ok
Nov 02 21:53:38 <mb__> xMff: See etrax build failure for pthread failure :D
Nov 02 21:53:38 <Memphiz> config 'foobar' 'hostname'? ... wtf
Nov 02 21:53:39 <Memphiz> ;)
Nov 02 21:54:06 <aroscha> yeah, like should't it be the other way round? ;-)
Nov 02 21:54:19 <Memphiz> hostname is defined some lines above ...
Nov 02 21:54:28 <Memphiz> looks like a placeholder instead ...
Nov 02 21:54:57 <xMff> aroscha: uci set foo.bar=baz -> config 'baz' 'bar'
Nov 02 21:54:59 <aroscha> memphiz: maybe I am too tired now / stupid whatever, but I tried to uci set system.hostname=foobar before
Nov 02 21:55:04 <xMff> it is
Nov 02 21:55:11 <aroscha> ah ok
Nov 02 21:55:14 <xMff> uci set system.@system[0].hostname=foobar
Nov 02 21:55:19 <aroscha> ok
Nov 02 21:55:30 <aroscha> so that is my mistake / misinterpretation now. srry
Nov 02 21:55:42 <aroscha> does not affect the luci web interface problem thogh
Nov 02 21:55:46 <xMff> however it does not explain the uci parse errors
Nov 02 21:55:48 <xMff> right
Nov 02 21:56:01 <xMff> does uci show system  work ?
Nov 02 21:56:46 <aroscha> it does
Nov 02 21:56:52 <aroscha> when the wrong foobar line is removed
Nov 02 21:56:58 <aroscha> I still get the same error with uci commit
Nov 02 21:57:12 <aroscha> same error line
Nov 02 21:57:19 <aroscha> root@mgb-1:/etc/config# uci commit
Nov 02 21:57:19 <aroscha> uci: Parse error (too many arguments) at line 38, byte 32
Nov 02 21:57:19 <aroscha> uci: Parse error (invalid character in field) at line 2, byte 8
Nov 02 21:58:00 <xMff> hm let me see
Nov 02 21:58:32 <xMff> please repeat the uci show for any file in /etc/config
Nov 02 22:01:37 <xMff> it would help if uci would report the file the parse error occured in...
Nov 02 22:01:58 <CIA-76> mb * r23803 /trunk/scripts/deptest.sh: deptest: Fix indent
Nov 02 22:03:03 <aroscha> do
Nov 02 22:03:07 <aroscha> doh!
Nov 02 22:03:19 <CIA-76> mb * r23804 /trunk/scripts/deptest.sh: deptest: Add shbang
Nov 02 22:03:36 <aroscha>  /etc/config/olsr broke at line 38 ;-)
Nov 02 22:04:03 <xMff> but that should not affect all other configs :-/
Nov 02 22:05:18 <EqUaTe> aroscha: has fixing that sorted both errors?
Nov 02 22:06:52 <aroscha> 1 min
Nov 02 22:11:31 <EqUaTe> i'd imagine not..
Nov 02 22:32:03 <aroscha> EqUaTe, xMff: nope
Nov 02 22:32:08 <aroscha> same issue with the luci webif
Nov 02 22:39:07 <aroscha> xMff: got it!
Nov 02 22:39:17 <aroscha>   /etc/config/timeserver was wrong in addition
Nov 02 22:39:35 <xMff> that one is not even used by the ui
Nov 02 22:40:24 <aroscha> yup
Nov 02 22:40:25 <aroscha> might be
Nov 02 22:40:42 <aroscha> but I was missing a option hostname foo.bar.com
Nov 02 22:40:52 <aroscha> actually the "hostname" in the above line was missing
Nov 02 22:40:56 <aroscha> config timeserver
Nov 02 22:41:06 <aroscha>    option hostname foo.bar.com
Nov 02 22:41:12 <aroscha> the hostname was missing
Nov 02 22:41:18 <xMff> hmm
Nov 02 22:41:28 <CIA-76> mb * r23805 /trunk/scripts/deptest.sh: deptest: Also create "failed" stamps. This makes it easier to check what failed after the script finished.
Nov 02 22:53:25 <CIA-76> mb * r23806 /trunk/scripts/deptest.sh: deptest: Also make sure the toolchain is built in the initialization step. This makes it possible to run the script from within a fresh tree.
Nov 02 22:54:01 <aroscha> xMff: still no changes however with the webif
Nov 02 22:55:16 <aroscha> xMff: what is the best way to check out a stable clean luci feed?
Nov 02 22:55:32 <aroscha> scripts/feeds update -a ; scripts/feeds install luci?
Nov 02 22:55:34 <aroscha> make clean
Nov 02 22:55:35 <xMff> yes
Nov 02 22:55:37 <aroscha> make V=99 ?
Nov 02 22:56:00 <aroscha> because I did that
Nov 02 22:56:52 <xMff> I do not know whats up in your tree
Nov 02 22:57:05 <xMff> tbh I do not even know where to start searching
Nov 02 22:57:22 <aroscha> me neither that is why I am asking you in the hope that you know ;-)
Nov 02 22:57:40 <aroscha> ok, i could check out a clean backfire + feeds
Nov 02 22:57:43 <aroscha> and try again
Nov 02 22:57:52 <aroscha> and narrow down the differences
Nov 02 22:58:07 <xMff> I suspect the generation of the language files failed for some reason
Nov 02 22:58:13 <aroscha> hmm
Nov 02 22:58:20 <aroscha> ok, so i take out the languages
Nov 02 22:58:22 <builder> build #19 of ep93xx is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/19
Nov 02 22:58:29 <xMff> thats a bad idea
Nov 02 22:58:35 <xMff> you should at least have english :)
Nov 02 22:58:39 <aroscha> yes
Nov 02 22:58:40 <aroscha> hehe
Nov 02 22:58:44 <aroscha> i meant the other languages
Nov 02 22:58:54 <xMff> can you send me a few files from /usr/lib/lua/luci/i18n/ ?
Nov 02 22:59:05 <xMff> *.lmo files
Nov 02 22:59:32 <aroscha> ok, can do
Nov 02 22:59:36 <xMff> base.en.lmo in particular
Nov 02 23:00:41 <aroscha> could this be the reason?
Nov 02 23:00:42 <aroscha> [15212.872229] luac[30489]: segfault at 20 ip 000000000040e243 sp 00007fffce06e7c0 error 4 in luac[400000+1d000]
Nov 02 23:00:49 <aroscha> from $ dmesg
Nov 02 23:00:53 <xMff> yes
Nov 02 23:00:56 <aroscha> crap!
Nov 02 23:00:57 <aroscha> ok
Nov 02 23:01:06 <xMff> Bartman007 seen that one too
Nov 02 23:01:14 <xMff> hmm
Nov 02 23:02:00 <xMff> anyway, in menuconfig LuCI -> Libraries -> Build Target, change from precompiled to full source
Nov 02 23:04:08 <aroscha> back (battery was empty ) :)
Nov 02 23:04:17 <aroscha> ok, i will try to go to full source
Nov 02 23:04:39 <aroscha> BTW: I am on ubuntu 10.10 (64 bit)
Nov 02 23:04:41 <xMff> if it still fails then I'm out of ideas ;)
Nov 02 23:04:57 <aroscha> maybe bartman007 has the same setup - that would be a hint in the right direction
Nov 02 23:25:51 <aroscha> xMff: ich check mal die allerletzte luci aus und baue nochmals alles neu
Nov 02 23:27:29 <CIA-76> mb * r23807 /trunk/scripts/deptest.sh: deptest: Better detection of base directory
Nov 02 23:47:24 <aroscha> xMff: ok, same thing
Nov 02 23:47:34 <aroscha> i'll send you now the base.en.lmo
Nov 02 23:48:06 <aroscha> ahh!!!
Nov 02 23:48:10 <aroscha>  /usr/lib/lua/luci/i18n/ is empty
Nov 02 23:48:35 <xMff> in this case I need the full log of  make package/luci/{clean,compile} V=99
Nov 02 23:48:54 <xMff> probably some 64bit compile issue
Nov 02 23:54:00 <Bartman007> aroscha, xMff: debian squeeze, 64-bit. IIRC I may have seen this error back when I was running 64-bit lenny xen domU's also.
Nov 02 23:54:49 <xMff> might be an issue of 64bit host lua vs. 32bit target lua
Nov 02 23:56:18 <xMff> the hostlua is used for bootstrapping
Nov 02 23:56:18 <xMff> I need to review the datatypes
Nov 02 23:56:18 <xMff> iirc it uses stuff like "int" instead of "int32_t"
Nov 03 00:01:26 <aroscha> xMff: ok, will send you the logs
Nov 03 00:01:32 <aroscha> thx for your time!!!!
Nov 03 00:01:37 <aroscha> I really appreciate it
Nov 03 00:04:37 <CIA-76> mb * r23808 /packages/net/openswan/patches/250-resolv-compile-fix.patch: openswan: Fix uClibc-0.9.31 build failure
Nov 03 00:04:44 <aroscha> xMff: try http://texas.funkfeuer.at/~aaron/jow.log
Nov 03 00:07:34 <xMff> you ran that with -j, right?
Nov 03 00:08:10 <xMff> it looks a concurrency issue
Nov 03 00:08:28 <xMff> it compiles the lanaguage compiler is compiled
Nov 03 00:08:39 <xMff> *language files before the
Nov 03 00:14:00 <aroscha> xMff: yes!
Nov 03 00:14:09 <aroscha> okay!
Nov 03 00:14:12 <aroscha> that could explain it
Nov 03 00:14:17 <xMff> ping mb__
Nov 03 00:14:20 <aroscha> i can re-test with -j1
Nov 03 00:14:24 <aroscha> or without -j
Nov 03 00:14:33 <aroscha> gut gut... will do :)
Nov 03 00:17:19 <xMff> aroscha: you should see some Generate ... done lines instead of all empty
Nov 03 00:18:58 <aroscha> ok
Nov 03 00:19:34 <mb__> 404 not found?
Nov 03 00:19:59 <xMff> mb__: what was the variable to make a package as unsafe for -j ?
Nov 03 00:20:04 <xMff> *mark
Nov 03 00:20:41 <xMff> PKG_BUILD_PARALLEL:=0 ?
Nov 03 00:23:29 <mb__> yes
Nov 03 00:24:12 <mb__> This is just for the internal package parallelization, however
Nov 03 00:24:22 <xMff> yes
Nov 03 00:24:26 <mb__> The global -j that you pass to make is not affected
Nov 03 00:24:49 <xMff> but that should not parallelize the package internal stuff (unless PKG_JOBS is passed)
Nov 03 00:24:58 <xMff> erm MAKE_JOBS or so
Nov 03 00:25:29 <mb__> it will parallelize only, if the default build rule is used(called) or PKG_JOBS is passed to submake
Nov 03 00:25:40 <xMff> ok, not the case here
Nov 03 00:26:11 <mb__> So you can use PKG_BUILD_PARALLEL:=0, if you use the default build rule and want to force parallel build off
Nov 03 00:27:19 <aroscha> BTW: talking of -j and such... does any one of you prefer to use ccache?
Nov 03 00:27:35 <aroscha> usually I do, but I wonder if it pays off for openwrt
Nov 03 00:28:06 <mb__> didn't try for a long time
Nov 03 00:29:11 <CIA-76> mb * r23809 /trunk/scripts/deptest.sh: deptest: Install the kernel at init stage
Nov 03 00:32:46 <CIA-76> mb * r23810 /trunk/scripts/deptest.sh: deptest: Check for .config
Nov 03 00:33:28 <aroscha> xMff: I verified it now! Yes, it was the -j
Nov 03 00:33:28 <aroscha> now the whole luci webif works again :)
Nov 03 00:33:52 <xMff> aroscha: I added the no-parallel flag to the makefile now
Nov 03 00:34:03 <xMff> so you can use -j again
Nov 03 00:34:43 <xMff> wasn't aware that it uses the default build rule...
Nov 03 00:34:57 <xMff> the joy of inherited code bases :)
Nov 03 00:35:30 <Wipster> ahha, I see in the ar7 image Makefile that the sErCoMm entry for making netgear .img's has been commented out, anyone remember why?
Nov 03 00:36:02 <xMff> maybe because the target image was broken
Nov 03 00:36:50 <mb__> xMff: Do you guys have CONFIG_PKG_DEFAULT_PARALLEL set? Because that's the only case where nonvoluntary (PKG_BUILD_PARALLEL not set to 1) parallel build could fail.
Nov 03 00:37:10 <xMff> mb__: I believe aroscha had, you gave him the tip a few days ago
Nov 03 00:37:17 <mb__> ah yeah ok.
Nov 03 00:37:29 <mb__> Most of the time it's safe. But not always :)
Nov 03 00:37:56 <xMff> I currently only mess around on my target so I don't notice build issues
Nov 03 00:38:33 <xMff> Wipster: looks like it has been committed out all the time back to when it was initially committed
Nov 03 00:38:40 <xMff> *commented out
Nov 03 00:39:31 <xMff> maybe because it needs an "adam2.bin" which can't be distributed
Nov 03 00:39:36 <xMff> (only guessing here)
Nov 03 00:39:52 <aroscha> xMff: thanks again :)
Nov 03 00:39:56 <aroscha> need to go to sleep hehe
Nov 03 00:40:04 <aroscha> have to wake up at 8:00 am
Nov 03 00:40:12 <xMff> me too :-/
Nov 03 00:41:35 <Wipster> xMff, ahh that sounds probable thanks for looking weird that it needs a copy of the loader... wonder if I can get away with padding it
Nov 03 00:42:46 <xMff> Wipster: ejka committed it back then, maybe he can shed some light on this
Nov 03 00:43:32 <xMff> ok, I'm out. bbl
Nov 03 00:43:41 <Wipster> xMff, thanks
Nov 03 01:15:49 <CIA-76> mb * r23811 /trunk/scripts/deptest.sh: deptest: Add optional blacklisting
Nov 03 01:32:56 <CIA-76> mb * r23812 /packages/Xorg/lib/fltk2/patches/ (002-honor-cppflags 100-compile-fixes.patch): fltk2: uClibc-0.9.31 fixes
Nov 03 01:36:14 <CIA-76> mb * r23813 /packages/Xorg/lib/fltk2/Makefile: fltk2: Enable parallel build
Nov 03 01:41:17 <CIA-76> mb * r23814 /packages/Xorg/lib/fltk2/Makefile: fltk2: Add missing dependency
Nov 03 01:53:30 <Wipster> sweet working .img thats going to save alot of hassle
Nov 03 01:55:22 <Wipster> night
**** ENDING LOGGING AT Wed Nov 03 02:59:57 2010