**** BEGIN LOGGING AT Wed Feb 06 02:59:58 2013 Feb 06 04:32:35 build #162 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/162 Feb 06 04:35:34 build #162 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/162 Feb 06 04:52:10 build #174 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/174 Feb 06 05:14:47 build #167 of uml is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/167 Feb 06 05:19:25 build #152 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/152 Feb 06 06:38:01 build #149 of ixp4xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/149 Feb 06 09:38:15 build #137 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/137 Feb 06 09:53:17 build #134 of gemini is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/134 Feb 06 10:21:11 hmm, encountering tracert6 troubles, apparently the same as this: https://dev.openwrt.org/ticket/8153 Feb 06 10:31:56 swalker seems to have been the last to comment about 13 months ago Feb 06 12:11:26 build #157 of avr32 is complete: Failure [failed compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/157 Feb 06 14:57:06 hauke r35507 trunk/target/linux/ brcm47xx/patches-3.6/760-bgmac-fixes.patch brcm47xx/patches-3.6/720-eth-backport.patch Feb 06 14:57:06 brcm47xx: bgmac: make it possible to set the devices into promisc mode when it is already up Feb 06 16:22:51 build #125 of octeon is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/125 Feb 06 18:29:33 soma, ping Feb 06 18:32:36 pong russell-- Feb 06 18:32:49 saw your wgt634u message on the mailing list ... thinking this might explain our cpu's melting with substantial openvpn traffic Feb 06 18:33:40 can openvpn use the hardware crypto on the wgt? Feb 06 18:33:49 not sure, actually Feb 06 18:34:02 but our cpus are melting ;-) Feb 06 18:34:35 we started sending ipv6 over openvpn for aggregation purposes and it's causing up som trouble Feb 06 18:34:42 hm yes, also they were never the fastest at all. Feb 06 18:35:15 although, it's been motivating people to upgrade to the 680MHz buffalo wzr600dhp's, which isn't entirely bad Feb 06 18:38:24 yes. i think wgt will be usable for one or two more years. but it isn't much fun, takes 5 minutes here to boot Feb 06 18:39:25 anywayys, you could manually install the ocf packages and see if it helps Feb 06 18:40:17 Hauke: did you see that fix? Feb 06 18:40:42 yes, i'll probably give that a try Feb 06 18:41:03 the kmod-crypto-ocf patch? Feb 06 18:41:27 yes Feb 06 18:41:45 yeah Feb 06 18:42:05 in target/linux/brcm47xx/profiles/WGT634U.mk Feb 06 18:45:02 I will apply it soon Feb 06 20:10:59 hmm. problem. I typically build an CONFIG_ALL=y and put the packages in a repository, and then build a trimmed down squashfs image to deploy, but when i try to install kmod-* stuff, i get complaints about "Cannot satisfy the following dependencies for kmod-$foo", what is the solution for that? Feb 06 21:00:19 russell--: probably clean the kernel before rebuilding Feb 06 21:02:57 i think the hash will still be different and it'll balk Feb 06 21:04:02 moo Feb 06 21:04:14 yes, sometimes you just need to rebuild the entire kernel Feb 06 21:07:11 that kind of sucks Feb 06 21:07:42 doesn't take too long, but it's a consistency thing. And as such, kind of a hassle soemtimes Feb 06 21:10:32 i have 30 devices, i want a common repo to pull from, i need pre-cooked images for each device to flash remotely so they come up clean Feb 06 21:11:01 not too long * 30 == too long Feb 06 21:11:01 right Feb 06 21:11:28 I don't know what the precise rules are Feb 06 21:11:53 i think if i could just override the checks it would work fine Feb 06 21:12:01 very likely Feb 06 21:12:02 it comes from the identical source afterall Feb 06 21:13:19 russell--: how about building an image builder with CONFIG_ALL=y, then use that one to build the trimmed down squashfs images? that should keep the kernel config intact Feb 06 21:13:45 russell: you aren't doing something "normal". expect sarcasm from the maintainers :p Feb 06 21:14:32 KanjiMonster: /me grumpy about modifying his workflow Feb 06 21:14:52 russell--: also it should work in theory with you building the squash images with the normal tree as long as you keep the kmods as =m, and don't deselect them completely Feb 06 21:15:16 russell: see how it comes around with you guys comment on my issue yesterday :p Feb 06 21:15:17 i normally save the entire bin directory each time i flash Feb 06 21:15:43 so having a fat one is unsatisfying Feb 06 21:16:44 Chocks: lol, your thing yesterday just sounded wrong. do you have a bootlog demonstrating that's what happens? Feb 06 21:17:08 sure, it sounds wrong, but jow confirm my analysis Feb 06 21:17:24 not sure I can generate a credible bootlog Feb 06 21:17:56 but give me a little credit. I've been doing embedded Linux as long as anyone here, I just don't breath openwrt every day. ;-) Feb 06 21:21:13 russell--: anyway, the most important part is to keep all kmods selected as =m; that should be "small enough" and keep the kernel hash the same Feb 06 21:23:11 * russell-- suggests a CONFIG_ALLKMOD or something Feb 06 21:23:20 so i can do that in one line Feb 06 21:24:52 the alternative would be to loosen the kmod rules (like i think they used to be) Feb 06 21:25:06 an* alternative Feb 06 21:25:27 the other alternative is to not care about me whining about it ;-) Feb 06 21:27:05 yes, a ALLKMOD would be nice to have ;) Feb 06 21:33:02 <[florian]> §win 18 Feb 06 21:33:05 <[florian]> miss Feb 06 21:35:20 scripts/metadata.pm seems to be where the magic happens Feb 06 21:35:45 cue: TWSS Feb 06 22:17:18 nbd r35508 trunk/package/network/services/openvpn-easy-rsa/Makefile * openvpn-easy-rsa: fix typo in version (#12958) Feb 06 22:20:39 russell--: i don't understand your problem. do you do a full rebuild for every device to customise it? Feb 06 22:21:11 if not, why do the checksums change on the kmods? Feb 06 22:35:02 soma, i do a CONFIG_ALL=y build, then immediately after i do a build for each device with a trimmed down .config. later i want to opkg install kmod-$foo packages from the CONFIG_ALL build that i didn't 'rebuild' with the trimmed down .config. and that install fails. Feb 06 22:36:17 and when i say 'later' i mean today when i wanted to test the kmod-crypto-ocf thing ;-) Feb 06 22:38:56 the "full rebuild" only takes a couple minutes, because the packages are all built already, so it's mostly just traversing the dependencies confirming things are up-to-date and the constructing the image. Feb 06 22:39:38 sounds like you should use the image generator Feb 06 22:39:48 maybe so Feb 06 22:40:10 but it never seemed worth the bother, since the rebuilds are so fast Feb 06 22:40:13 but also there you need to do a full kernel rebuild everytime something in the kernel changed and keep the repositories Feb 06 22:40:29 with image generator a rebuild is done in 30s or so Feb 06 22:40:48 only the kmod-$foo seem to have this problem Feb 06 22:41:38 30s isn't significantly faster than 2m, to me anyway Feb 06 22:41:51 considering the other steps involved Feb 06 22:51:30 hauke r35509 trunk/target/linux/brcm47xx/profiles/WGT634U.mk * brcm47xx: fix name of kmod-ocf-ubsec-ssb Feb 06 22:59:43 thanks hauke. can yyou also baclport this to AA? Feb 06 23:01:21 soma: yes I will do, I just have to check for the AA status before Feb 06 23:02:12 ok. i built some images with the patch and they work, but its better you also check that again **** ENDING LOGGING AT Thu Feb 07 02:59:58 2013