**** BEGIN LOGGING AT Sun Sep 26 02:59:57 2010 Sep 26 03:43:08 build #111 of octeon is complete: Failure [failed compile_7] Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/111 Sep 26 03:57:40 what is the primary use of IPT raw in openwrt? Sep 26 03:58:07 suppress connection tracking to achieve higher throughput Sep 26 03:58:30 a.k.a. NOTRACK Sep 26 04:01:34 I know its used in the prerouting chain, but are there any default rules to use it, or places in Luci or webif to accomplish its usage? Sep 26 04:01:49 no (not yet) Sep 26 04:02:15 the firewall scripts will establish notrack rules between zones that don't have masquerading enabled Sep 26 04:02:26 automatically Sep 26 04:02:48 there's an option to enforce conntracking (and thus disable notrack) but its not covered in the ui yet Sep 26 04:03:38 which default zones are using it currently? Sep 26 04:03:53 none in the default config Sep 26 04:07:01 if you disable masq on lan you'd have a notrack rule for -i lan -o wan Sep 26 04:07:06 *masq on wan Sep 26 04:08:13 what is the config option to enforce conntrack? Sep 26 04:08:23 option conntrack {1,0} Sep 26 04:08:48 see wiki.openwrt.org/doc/uci/firewall Sep 26 04:08:58 all existing options are outlined there Sep 26 04:14:52 "NOTRACK will render certain ipables extensions unusable, ... the state match will not work! " - State meaning, established, etc ? Sep 26 04:14:58 yes Sep 26 04:16:31 build #93 of kirkwood is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/93 Sep 26 04:31:30 ooh, not sure thats a good trade off, unless conntrack is hammered between wan-lan. Seems odd that you would have load a module to modify another, instead of loading conntrac with some option like --ignore-interface = eth0 Sep 26 04:32:28 well notrack can do more Sep 26 04:32:51 like "do not track connection from wan directed to port 80 for dest address 1.2.3.4" Sep 26 04:33:00 a simple module parameter won't cut it Sep 26 04:34:57 also module parameters are impractical for a generic solution Sep 26 04:35:14 or frequently changing demands Sep 26 04:35:18 true, its just that losing the state capability that seems amiss to me Sep 26 04:35:26 its the whole point Sep 26 04:35:37 state keeping implies a hughe overhead Sep 26 04:35:45 cpu and memory wise Sep 26 04:36:18 notrack was specifically developed to kill state keeping Sep 26 04:36:38 its its only purpose and not a bug Sep 26 05:01:48 ACK - There is wisdom in punching holes in conntrack for trusted traffic, but the lack of masq doesn't always mean implicit trust ;) Sep 26 05:06:47 build #139 of ppc40x is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ppc40x/builds/139 Sep 26 05:23:51 build #96 of adm5120 is complete: Failure [failed shell_6] Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/96 Sep 26 05:41:44 build #133 of ppc44x is complete: Failure [failed shell_3] Build details are at http://tksite.gotdns.org:8010/builders/ppc44x/builds/133 Sep 26 05:41:47 build #84 of xburst is complete: Failure [failed svn compile_12] Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/84 Sep 26 05:44:00 build #80 of x86 is complete: Failure [failed shell_3 compile_1 shell_10] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/80 Sep 26 05:57:40 build #85 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/85 Sep 26 07:16:44 Hi, Backfire 10 can compile on kernel 2.6.29 ? Sep 26 07:18:42 I'm porting a net target, soon online for the community from kamikaze to backfire. This was build and patched with the old kernel, so I'm dividing the work in two steps: 1) port 2) update and patch for the latest kernel 2.6.32 Sep 26 07:19:04 This is to avoid problems of incompatibility between some functions I find in the two kernel calls. Sep 26 07:19:12 can someone answer me please ? Sep 26 07:59:28 Alicemirror: compiling it with 2.6.29 is not a good idea Sep 26 07:59:35 because then you'd have to backport the openwrt patches Sep 26 07:59:47 which may or may not be more work than forward porting your target to a more recent kernel Sep 26 07:59:54 in any case, it's a waste of time Sep 26 07:59:56 nbd: I was thinking about this. Sep 26 08:00:36 what kind of target is it by the way? Sep 26 08:00:43 nbd: actually I have already completed the port of application patches and everything seems to work fine with 2.6.32 Sep 26 08:01:37 nbd: the target is for the wode board, "Wii Optical Disk Emulator" that should be released as open wode open wrt platform. Based on backfire. Sep 26 08:01:49 interesting Sep 26 08:02:11 Initially my customer choiched to take "close" this apps, because there is some part (packages) of the firmware that shoud work with wii. Sep 26 08:03:19 another thing is: we don't really accept new targets for backfire anymore Sep 26 08:03:25 it's pretty much in bugfix-only mode Sep 26 08:03:33 so your target should be added to trunk Sep 26 08:04:27 The fact that you don't accept any new targets really isn't a limitation, I think. Sep 26 08:04:55 ok, good Sep 26 08:05:15 I can also ad the target to another site, the fact remains that this is a target for a very popular platform based on open WRT. Sep 26 08:06:47 for backfire, it can live on another site. for trunk we should add it Sep 26 08:08:41 nbd: The question is: when I compile the new target, I find errors where the same function in 2.6.29 have only one parameter and in 2.6.32 have two. Sep 26 08:09:00 which function? Sep 26 08:09:25 arch/arm/kernel/process.c: In function 'arm_machine_restart': Sep 26 08:09:26 arch/arm/kernel/process.c:103: error: too many arguments to function 'arch_reset' Sep 26 08:11:10 i.e. this function has a second parm "cmd" in 2.6.32 Sep 26 08:11:17 yeah, you need to adjust that in your mach header file (system.h) Sep 26 08:13:13 ndb: in fact I need a little help about. To be sure that the procedure is correct. Sep 26 08:13:34 In this case, changing the files in the target dir, is a good choice ? Sep 26 08:14:00 Or I need to create some thing of patches ? This is what I have no clear. Sep 26 08:15:50 the change needs to be made in a file that was added for your target Sep 26 08:16:29 so if you're using the files/ directory, you don't need to make a kernel patch for that Sep 26 08:17:17 you should have your own arch/arm/mach-/include/mach/system.h Sep 26 08:17:28 which defines an arch_reset() function Sep 26 08:17:34 that function needs to be changed Sep 26 08:17:42 to look like this: Sep 26 08:17:43 static inline void arch_reset(char mode, const char *cmd) Sep 26 08:22:54 nbd: Ok, so the problem is in my internal proto and defs. I have no clear the means of mach directories. Sep 26 08:23:45 should be quite easy to fix Sep 26 08:23:52 let me know if you run into any other issues Sep 26 08:24:18 ok, thank you. I'm working on just now. Sep 26 08:26:03 I should also like to know more about targets and the method I need/can release open targets to the community Sep 26 08:47:09 nbd: n effect I changed the file in my target. Note that arch_reset was a function already defined here. But recompiling make, I obtained the same error. How can I do to force make to rebuild something? It's strange, because changing the include te system should update automatically sources and related files. Or not ? Sep 26 08:48:29 nbd: I changed in target/linux//files/arch/arm/mach-/include/mach/system.h Sep 26 08:48:41 here there was already the same function defined inline. Sep 26 08:52:05 files from there are not automatically copied to the build_dir Sep 26 08:52:25 so do that manually when you change it Sep 26 08:52:26 so I should copy also to build dir. ok Sep 26 09:14:36 nbd: changed and following analogue changes in other sources, evidentiating similar problems. Sep 26 09:28:34 nbd: now, the last problem is little different: Sep 26 09:30:01 nbd: In last error I receive Sep 26 09:30:01 In file included from arch/arm/boot/compressed/misc.c:240: Sep 26 09:30:01 arch/arm/boot/compressed/../../../../lib/decompress_unlzma.c:329:54: error: macro "flush" passed 2 arguments, but takes just 0 Sep 26 09:30:01 In file included from arch/arm/boot/compressed/misc.c:240: Sep 26 09:30:01 the file misc.c is only in the kernel package, downloaded during the build toolchain, and I have no reference in my target. How can I correct this? Sep 26 09:33:30 one of your header files defines a flush() macro which conflicts with another use of the name in decompress_unlzma.c Sep 26 09:34:23 turn that macro into an inline function and it should work Sep 26 09:34:50 it's probably mach/uncompress.h Sep 26 09:40:33 Thank you. :) Sep 26 09:45:47 packages and image created ! Sep 26 09:46:15 Next week I release openwode backfire on kernel 2.32 Sep 26 09:46:49 nbd: If you have time, can you explain me how I should do to put that target (if it interest to owrt) ? Sep 26 09:56:42 Alicemirror: you can submit the target as a patch and send it to the openwrt-devel list Sep 26 09:57:46 Ok, but I have no clear how can I build a patch with a lot of dirs, files, config, patches etc. Sep 26 09:58:29 are you using svn or git? Sep 26 09:59:01 both Sep 26 10:00:08 with git you can just 'git add' everything that you changed Sep 26 10:00:25 and then run git diff --cached > patch.txt Sep 26 10:01:21 gah, when is wgt634u going to get fixed ... i reported the breaking revision nearly 2 months ago. Sep 26 10:01:39 ok, after the git download from owrt git repo ? Sep 26 10:01:59 russell--: which rev broke it? Sep 26 10:02:03 Alicemirror: yes Sep 26 10:02:59 ok then announce on the devel ml that it is there. it's right ? Sep 26 10:03:12 yes Sep 26 10:04:38 nbd: looking Sep 26 10:05:29 nbd: thank you very much. To avoid troubles on your git I alk john to help me in the steps :) Sep 26 10:06:21 nbd: r22296 (bisected and reported on august 2) Sep 26 10:07:43 russell_: please talk to hauke then Sep 26 10:07:49 give him some details on your issues Sep 26 10:07:54 i just built r23118 from scratch and still problems Sep 26 10:08:04 yeah, he's kind of been unresponsive Sep 26 10:09:17 tried email? Sep 26 10:10:42 we have corresponded. he knows generally about the problem. Sep 26 10:10:55 * russell_ has offered to help Sep 26 10:11:07 (ie, providing info, testing) Sep 26 10:18:25 maybe he forgot Sep 26 10:18:41 unfortunately my wgt634u died a long time ago, so i can't really help Sep 26 10:18:50 i've been reminding him periodically ;-) Sep 26 10:18:54 ok Sep 26 10:19:42 i am having trouble debugging it myself because the console goes away during boot Sep 26 10:20:03 i get as far as: Starting program at 0x80001000 Sep 26 10:20:08 and then it goes silent Sep 26 10:23:00 it appears that currently broadcaom-diag doesn't detect the board correctly and i don't follow how that is supposed to work/fit in with everything else to discover quite what the problem is. Sep 26 10:23:23 ok, and before that rev the console still worked, right? Sep 26 10:23:30 yes Sep 26 10:23:38 22295 was okay Sep 26 10:24:13 there seemed to be two problems, one masking the other one Sep 26 10:24:20 i'll try to make a better diff between the two Sep 26 10:24:23 one was the console, the other was the flash Sep 26 10:24:27 maybe i'll spot the problem Sep 26 10:25:51 * russell_ is presuming that board detection problem was allowing the nvram block to get overwritten, which would cause boot problems on the next boot (cfe would puke because it didn't have the info it needed) Sep 26 10:26:13 on the board i am testing on, for some reason, that doesn't not currently seem to be the problem Sep 26 10:27:03 although, maybe because it panics or something before it can overwrite the flash block Sep 26 10:27:10 (invisibly) Sep 26 10:30:16 russell_: heh, that commit seems to remove cfe env support entirely for some reason Sep 26 10:30:51 or at least the init part seems to be missing Sep 26 10:31:05 what. was. he. thinking. Sep 26 10:31:07 ;-) Sep 26 10:31:53 oh, wait. it seems to be replaced by some upstream code Sep 26 10:32:00 i wonder if that code has even been tested Sep 26 10:32:21 upstream, like in vanilla linux kernel? Sep 26 10:32:54 yeah Sep 26 10:33:08 ugh, that cfe_getenv stuff that he used doesn't parse the cfe environment Sep 26 10:33:14 it makes function calls to cfe Sep 26 10:41:12 russell_: please show me the contents of your cfe environment Sep 26 10:41:24 http://wiki.personaltelco.net/WgtRecovery Sep 26 10:41:56 i can give you what a pristine mtdblock4 looks like too Sep 26 10:42:06 no need to Sep 26 10:42:09 i already found a bug Sep 26 10:42:13 cool Sep 26 10:42:24 cool Sep 26 10:42:25 at least i think so Sep 26 10:42:41 * russell_ is more than happy to test Sep 26 10:43:38 dunno if that bug is still present in recent versions Sep 26 10:43:43 i'll do a build so i can run compile tests Sep 26 10:43:46 then i'll do another code review Sep 26 10:43:53 and send patches for testing your way Sep 26 10:44:57 awesome Sep 26 10:46:19 CFE> printenv also gives me "boardtype bcm95365r" Sep 26 10:46:56 which i would assume would be unique to the wgt634u, but ... i don't know that. Sep 26 10:47:29 i think the problem isn't detecting the wgt634u itself Sep 26 10:47:33 okay Sep 26 10:47:46 the problem is that hauke moved the cfe vs nvram distinctions to the individual callsites Sep 26 10:47:54 and forgot to update some of those callsites to use cfe Sep 26 10:48:00 at least that was the case in the early rev Sep 26 10:48:11 i'll take a look at the new rev soon to see if some of that got fixed over time Sep 26 10:48:25 but one of those callsites where i found it is specifically related to serial port handling on wgt634u Sep 26 10:49:11 because what i remember from years ago is that the wgt634u has a swapped serial port Sep 26 10:49:25 and there is some code that swaps it based on nvram/cfe env contents Sep 26 10:49:47 btw, how do you grep -r the buildroot without getting lost in dev land? Sep 26 10:49:56 git grep Sep 26 10:49:58 ;) Sep 26 10:50:02 ah, cool Sep 26 11:59:02 build #86 of ps3 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/86 Sep 26 12:51:12 mb * r23120 /trunk/target/linux/omap24xx/patches-2.6.36/ (2 files): omap24xx: Export certain n8x0 GPIO switches as input device Sep 26 12:53:40 mb * r23121 /trunk/target/linux/omap24xx/Makefile: omap24xx: Upgrade to linux-2.6.36-rc5 Sep 26 12:56:52 <_trine> why is it that Europe/London has been missed out of the list in LuCi for timezones ? Sep 26 12:57:40 <_trine> ah I have found it now it just does not show in the drop down list Sep 26 13:00:52 <_trine> I have just tried LuCi again after a long period of using webif and I must say luCi has improved a lot Sep 26 13:13:45 _trine: it shows up for me. Let me guess, you are using firefox? ;) Sep 26 13:22:23 <_trine> KanjiMonster, I am Sep 26 13:23:03 _trine: seems like firefox doesn't quite like luci's comboboxes, see https://dev.openwrt.org/ticket/7781 Sep 26 13:23:49 <_trine> KanjiMonster, its ok anyway I soon found you could just use the up/down keys on the keyboard to see the other options Sep 26 13:24:42 <_trine> LuCi used to be slow and heavy now its much better and more responsive Sep 26 13:26:20 <_trine> I am trying out sta mode and trying to do a scan but it doesnt seem to work Sep 26 13:35:16 <_trine> KanjiMonster, have you tried to scan for wifi in LuCi? Sep 26 13:37:34 _trine: scanning in ath9k is not possible at all yet through luci Sep 26 13:37:47 s/in/with/ Sep 26 13:37:48 <_trine> ah ok thanks Sep 26 13:37:53 I work on it Sep 26 13:37:59 <_trine> great Sep 26 13:38:47 <_trine> xMff, luCi is much improved you are doing a good job Sep 26 13:39:29 <_trine> I jst decided it was a good time to flash my wrt160nl's Sep 26 13:39:37 <_trine> just* Sep 26 13:43:25 build #40 of at91 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/40 Sep 26 13:44:29 _trine: tbh, I don't even know how to scan with luci ;) Sep 26 14:02:08 KanjiMonster: its well hidden ;) Sep 26 14:07:37 build #129 of atheros is complete: Failure [failed shell_6] Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/129 Sep 26 14:14:10 xMff: do I have to enable the wireless for it to show up? Sep 26 14:14:23 yes, yet Sep 26 14:14:58 (and why does luci restart the whole network stuff If I only do some minor changes for wifi; like setting a country code) Sep 26 14:16:07 bacuse such fine grained apply stuff would triple the code size Sep 26 14:20:37 hm, I'm seeing the same problem as stintel with regards to user regdomain, except I have only one card, and I use ath5k Sep 26 14:22:28 xMff: hm, scanning shows 0 results Sep 26 14:22:42 ath9k ? Sep 26 14:23:04 ath5k Sep 26 14:23:21 probably not implemented ;) Sep 26 14:24:19 'iw dev wlan0 scan' returns device or recource busy Sep 26 14:24:36 ap or client mode? Sep 26 14:24:49 client mode Sep 26 14:25:44 wpa_cli -p /var/run/wpa_supplicant-wlan0 -i wlan0 scan Sep 26 14:25:52 sleep 1 Sep 26 14:25:53 wpa_cli -p /var/run/wpa_supplicant-wlan0 -i wlan0 scan_results Sep 26 14:27:08 I have no wpa_cli Sep 26 14:27:19 install it Sep 26 14:28:25 okay, let me first compile it Sep 26 14:29:49 wpa_cli is just a conveninence wrapper to talk to wpa_supp's domain socket Sep 26 14:29:53 I suppose socat would work too Sep 26 14:30:01 or a ~20 line C program Sep 26 14:31:11 should I select something as encryption? I currently selected none Sep 26 14:31:25 no, it should always use wpa_supp Sep 26 14:31:32 even for open networks Sep 26 14:45:40 scanning with wpa_cli works Sep 26 14:46:45 yes I know, I wrote a library for luci which encapsulates the various hacks and workarounds for bcm-wl/madwifi/ath9k, just haven't it integrated yet Sep 26 14:48:09 so scanning with luci just doesn't work with atk5k? Sep 26 14:48:19 correct, not yet Sep 26 14:48:31 either wpa_supp is sitting on it or hostapd Sep 26 14:48:46 ah, I see Sep 26 14:48:53 got a separate workaround for the hostapd case Sep 26 14:49:51 do I see it right that user regdomain completely disables any restrictions and offers any channel the phy is capable of? Sep 26 14:50:26 no Sep 26 14:50:38 it just allows you to choose more liberal countries Sep 26 14:50:53 to completely lift restrictions you'd need to hack regulatory.bin and/or the driver Sep 26 14:51:01 many drivers override the regdb internally Sep 26 14:51:02 because I set it to DE, but I can choose channel 14 Sep 26 14:52:43 ah wait, luci offers 14, but iw phy info says 0 dBm Sep 26 14:54:25 otoh channel 140 is supposed to be allowed (26 dBm), but luci's highest channel is 136 Sep 26 14:57:56 the current version parses iwlist chan Sep 26 14:58:25 ah, I see Sep 26 14:58:56 for gui stuff the linux wireless userspace utils are pure crap Sep 26 14:59:22 incomplete, bugged, inconsistent and a different for each driver Sep 26 14:59:47 I wrote about 10.000 lines of C just to get consistent basic wifi info for all openwrt supported wifi drivers Sep 26 14:59:59 ouch Sep 26 15:02:01 will commit it soon and add a littlce cli frontend for it, then one has a "iwinfo-esque" output and can scan with all drivers Sep 26 15:02:22 *iwconfig I mean Sep 26 15:03:49 build #122 of brcm63xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/122 Sep 26 15:34:52 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/uscan.shtml Sep 26 15:39:33 hi. What is the difference between the pcnet32 driver present in the kernel and the one used by openwrt? Sep 26 15:40:02 there should be none. We just package whatever upstream Linux contains Sep 26 15:41:12 xMff: hmm, ok. when I try to insmod pcnet32.ko it says that it's incompatible. I'm trying to do a make clean before rebuilding with a new kernel. Sep 26 15:41:41 if you enabled/compiled the mod after you compiled (and flashed) the kernel it won't work Sep 26 15:41:57 it will introduce new symbols not present in the running linux image Sep 26 15:42:25 I'm using the ramdisk on qemu mips malta Sep 26 15:42:41 so they should get build together Sep 26 15:42:51 then post the dmesg output Sep 26 15:43:25 I didn't save it and I just did a make clean. Anyway, it was a relocation overflow. Sep 26 15:43:43 odd Sep 26 15:43:59 also shouldn't malta enable pcnet32 by default? Sep 26 15:44:38 yup Sep 26 15:46:14 and, besides...I actually compiled it IN the kernel, but it shows up as a module. (nm vmlinux | grep pcnet32 doesn't show anything) Sep 26 15:49:57 russell_: hm, the serial port issue was already fixed Sep 26 15:56:21 dtatulea_: Y in openwrt means included in the image, not in the kernel (unless you use kernel_menuconfig) Sep 26 15:56:45 and what doesn M mean then? included in a package? Sep 26 15:57:04 buid the package, but don't include it Sep 26 15:57:13 *build Sep 26 15:57:52 ah, ok. sorry for the misinterp. Sep 26 15:59:57 build #104 of etrax is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/104 Sep 26 18:57:41 build #104 of gemini is complete: Failure [failed shell_6] Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/104 Sep 26 19:27:59 regular dependencies are not guaranteed to be compiled before the package that depends on them? Sep 26 19:28:03 or for that I have to specify a PKG_BUILD_DEPENDS? Sep 26 19:29:47 mb * r23122 /packages/Xorg/app/pwrtray/Makefile: pwrtray: Update to support lock button Sep 26 19:30:31 nbd: hmm Sep 26 19:31:01 nunojpg: You only need PKG_BUILD_DEPENDS, if there's no regular dependency but the build (not the runtime) depends on the other package Sep 26 19:31:52 if the runtime and the build both depends, I have to specify both? Sep 26 19:32:05 no Sep 26 19:56:43 mb__: I've not yet undestood the entire picture. Looking for example at https://dev.openwrt.org/browser/trunk/package/hostapd/Makefile Sep 26 19:57:16 22 PACKAGE_kmod-madwifi:madwifi, what is the meaning of the colon? Sep 26 19:57:45 26 CONFIG_WPA_SUPPLICANT_NO_TIMESTAMP_CHECK, what does mean to depend on a config variable? Sep 26 19:58:15 foo:bar means depend on bar if foo is selected Sep 26 20:04:21 iptables -A PREROUTING -s 192.168.0.123/255.255.255.0 -p tcp -j DNAT --to-destination 64.111.96.38 Sep 26 20:04:44 xMff, will that ^ only redirect the client 192.168.0.123 ? Sep 26 20:04:52 yes Sep 26 20:04:58 kk Sep 26 20:05:00 xMff, ty Sep 26 21:36:47 build #105 of mpc52xx is complete: Failure [failed shell_6] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/105 Sep 26 22:03:39 mb * r23123 /trunk/target/linux/omap24xx/config-2.6.36: omap24xx fb: Do not omit init Sep 26 22:04:06 mb * r23124 /packages/Xorg/app/pwrtray/ (Makefile files/etc/pwrtray-backendrc): pwrtray: Add support for FB blanking Sep 26 22:05:34 mb__: what will do PKG_CONFIG_DEPENDS:= CONFIG_WPA_SUPPLICANT_NO_TIMESTAMP_CHECK ? Sep 26 22:05:55 nunojpg: It will rebuild the package, if CONFIG_WPA_SUPP.... changes Sep 26 22:10:44 mb__: thanks, and just to confirm, if the package have a regular dependency, the dependencies are compiled first? Sep 26 22:11:36 yes Sep 26 22:56:55 build #114 of sibyte is complete: Failure [failed shell_6] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/114 Sep 26 23:04:35 mb__: that is true, but if the dependency is an "Config.in" "select", is is not always compiled first Sep 26 23:04:44 so they are handled in a different way Sep 26 23:05:21 or that "select pacage_x" is not the same as a "depends +pacage_x" Sep 26 23:06:24 nunojpg: kconfig selects are not a dependency at all. Sep 26 23:06:51 it makes no dependency guarantees at all Sep 26 23:08:19 sorry, because it's just not implemented, or because it doesn't make sense? Sep 27 00:12:01 build #106 of cobalt is complete: Failure [failed shell_6] Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/106 Sep 27 01:48:16 build #130 of atheros is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/130 **** ENDING LOGGING AT Mon Sep 27 02:59:57 2010