**** BEGIN LOGGING AT Mon Mar 29 02:59:57 2010 Mar 29 03:07:56 nbd * r20569 /trunk/include/kernel.mk: prevent kernel.mk from defining PATCH_DIR and FILES_DIR for regular packages Mar 29 03:38:44 nbd * r20570 /trunk/include/autotools.mk: add a new helper macro to deal with conditional ./configure flags Mar 29 03:40:18 looks like rhk's umlaut in feeds/packages/libs/clearsilver/Makefile is wrong, missing mime-type? Mar 29 03:58:19 nico * r20571 /trunk/package/base-files/files/etc/rc.common: [package] base-files: fix shell syntax (prevent error messages when activating initscripts in IB) Mar 29 05:12:01 build #35 of adm5120 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/35 Mar 29 05:37:06 build #29 of x86 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/29 Mar 29 05:54:20 Is there a handy way to detect the end of the kernel? Mar 29 05:54:48 nvm....realized I don't need it Mar 29 05:54:56 florian * r20572 /trunk/package/e2fsprogs/ (Makefile patches/001-fix_abs_shlibs_symlinks.patch): [package] update e2fsprogs to 1.41.11 (#6896) Mar 29 05:55:41 [florian]: the changes I'm making to get rid of the tag id union are pretty invasive....do you want me to wait to apply them until after release? Mar 29 05:56:15 <[florian]> cshore: the idea is not to freeze trunk even in a release, so, no you can go ahead :) Mar 29 05:56:28 [florian]: ok, cool Mar 29 05:56:52 [florian]: it's not ready quite yet, but I'm making good progress Mar 29 05:58:05 [florian]: this make upstream acceptance more likely I think Mar 29 05:58:15 <[florian]> cshore: I am sure you do, tell me if you want additionnal testing, like on bcm6338 for instance Mar 29 06:00:13 ok....the biggest things I think will need testing is the flashing on various devices....the image generation has to change to support this (since the imagetag is changing to a unified format) Mar 29 06:01:29 <[florian]> we have a pretty big community of users despite the absence of dsl, so I am sure we will have the testing done Mar 29 06:02:27 btw how are the talks for the dsl with Broadcom? Mar 29 06:03:45 <[florian]> more or less at the same point I am afraid, I will write a mail about that later Mar 29 06:04:46 that's disappointing Mar 29 07:18:17 build #45 of brcm47xx is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/45 Mar 29 07:19:40 <[florian]> cshore: a little yes Mar 29 07:21:01 build #47 of brcm63xx is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/47 Mar 29 08:24:43 ping rtz2 Mar 29 08:39:44 build #33 of rdc is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/rdc/builds/33 Mar 29 08:43:17 build #33 of ramips is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/33 Mar 29 08:46:02 build #33 of au1000 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/33 Mar 29 09:10:55 build #33 of ar7 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/33 Mar 29 09:26:04 jow * r20573 /trunk/package/uhttpd/ (Makefile src/uhttpd-cgi.c src/uhttpd-lua.c): [package] uhttpd: fix a signal related race condition exposed by LuCI on fast machines Mar 29 09:42:44 Hi. How I can download 10.03-rc1 source from svn? Mar 29 09:44:20 dkostousov: check out trunk Mar 29 09:44:54 it is trunk @ r20254 Mar 29 10:34:12 build #31 of xburst is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/31 Mar 29 10:42:24 build #41 of ep93xx is complete: Failure [failed compile_7] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/41 Mar 29 11:03:23 florian * r20574 /packages/lang/urbi/ (Makefile patches/005-fix-gcc_4_3-compile.patch): [package] fix urbi compilation failure on octeon (#6987) Mar 29 11:03:25 florian * r20575 /packages/utils/scponly/ (Makefile patches/ patches/001-elif_else_replacement.patch): [package] fix scponly compilation failure (#6986) Mar 29 11:03:28 florian * r20576 /packages/net/pcapsipdump/ (Makefile patches/002-elif_else_replacement.patch): [package] fix pcapsipdump compilation failure (#6983) Mar 29 11:03:29 florian * r20577 /packages/libs/libxapian/ (5 files in 2 dirs): [package] fix libaxpian build failure (#6982) Mar 29 11:03:31 florian * r20578 /packages/libs/libtorrent/ (Makefile patches/130-missing_inttypes.patch): [package] fix libtorrent build failure (#6981) Mar 29 11:03:34 florian * r20579 /packages/utils/bemused/ (Makefile patches/110-missing_includes.patch): [package] fix bemused compilation failure (#6980) Mar 29 11:20:39 <|KanjiMonster|> is there any way to profile applications in openwrt? I don't think nmap is supposed to take 22 minutes for parsing its nmap-services, and I want to find out why Mar 29 11:22:12 <[florian]> you can try oprofile, which is packaged Mar 29 11:22:19 <[florian]> and works on mips, arm etc ... Mar 29 11:22:25 <[florian]> otherwise, strace might help as well Mar 29 11:26:00 <|KanjiMonster|> with strace i saw its the parsing of the nmap-services thats slow, but not why Mar 29 11:26:25 <[florian]> allright Mar 29 11:26:27 <|KanjiMonster|> i'll try oprofile Mar 29 11:26:48 <[florian]> it might simply be the compilation options and/or the compiler not correctly optimizing that parsing section Mar 29 11:26:52 <|KanjiMonster|> btw, I'm trying to run nmap 5.21, not the original 4.20 Mar 29 11:27:07 4.20 is fine Mar 29 11:28:22 I somehow have a hunch its the stl/uclibc++ (commenting out the duplicate check for the map already cut the time in half) Mar 29 11:28:48 <[florian]> oh Mar 29 11:30:09 but 11 minutes is still too long, especially if its run on a rs pro ;) Mar 29 11:30:26 <[florian]> yes, there is something wrong I agree Mar 29 11:30:28 blogic * r20580 /trunk/package/uboot-lantiq/patches/210-compile.patch: [ifxmips] fixes uboot compile error Mar 29 11:58:25 build #33 of orion is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/33 Mar 29 12:19:00 blogic * r20581 /trunk/toolchain/kernel-headers/files/: temporary fix to make toolchain build properly, this is broken since [20569] Mar 29 12:47:07 build #43 of sibyte is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/43 Mar 29 13:06:21 nico * r20582 /trunk/include/download.mk: [include] download.mk: fix bzr download method Mar 29 13:09:32 build #33 of rb532 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/33 Mar 29 14:12:06 hello Mar 29 14:31:28 ping xMff Mar 29 14:31:57 pong cshore Mar 29 14:38:32 xMff: for the applet to show the firmware image filename used to flash the device, and for the imagetag crc fixup, I am thinking of doing conditional compile of mtd based on the target_bcm63xx (or whatever the exact flag is) make variable, so that brcm63xx mtd has two features (the fixup, and the firmware file information display) that are target-specific but aren't built for the non-63xx targets (to avoid bloating mtd for arch's wh Mar 29 14:39:52 cshore: post was truncated after "for arch's" Mar 29 14:40:03 conditional compilation sounds good Mar 29 14:40:34 ok, I also want to do this: I am also thinking of adding a platform.sh for sysupgrade and an additional mtd information that checks the CRC of an image against the imagetag header to verify the image before flashing. Do you think this is okay as long as the code is only compile for 63xx? Mar 29 14:42:03 yes Mar 29 14:42:31 I'd say combine verification and suggestion then and let platform.sh use that Mar 29 14:42:56 ok, makes sense Mar 29 14:44:33 also, for the suggestion, what do you think of being able to display it on the LuCI System page....is there way to detect arch so that that additional information is only displayed for 63xx? Mar 29 14:45:53 we'll see Mar 29 14:46:27 I could try to call "mtd suggest" or something and if that fails display the standard boilerplate text Mar 29 14:46:45 ok Mar 29 14:51:09 I could conditionally make mtd suggest or whatever return either the 63xx results or "Does not apply to this arch" Mar 29 14:54:03 maybe with either a success exit code or a non-zero exit code Mar 29 14:56:09 use 0 for valid image, 1 for invalid with suggestion, 2 for no suggestion or something Mar 29 14:58:38 acinonyx * r20583 /packages/net/wget/Makefile: (log message trimmed) Mar 29 14:58:38 [packages] wget: Fix installation and cleanup package makefile (#6990) Mar 29 14:58:38 * wget package binary installed at /usr/bin/wget-ssl Mar 29 14:58:38 * wget-nossl package binary installed at /usr/bin/wget-nossl Mar 29 14:58:38 * allows both packages to co-exist without conflict Mar 29 14:58:38 * busybox symlink is replaced with symlink to newest package binary Mar 29 14:58:39 * symlink is restored when removing package with the following preference: Mar 29 15:16:20 nbd * r20584 /trunk/toolchain/kernel-headers/Makefile: fix kernel-headers build Mar 29 15:28:51 cshore: ping Mar 29 15:57:57 nbd: ping Mar 29 16:02:47 rtz2: pong Mar 29 16:05:09 nbd: I tried to compile a gcc 4.4.3 toolchain for rdc Mar 29 16:05:37 nbd: and during the configure run for libgcc and libstdc++, I get lot's of errors like that in config.log: Mar 29 16:06:00 build_dir/toolchain-i386_gcc-4.4.3_uClibc-0.9.30.1/gcc-4.4.3-final/./gcc/cc1: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory Mar 29 16:06:10 nbd: does this ring any bells for you? Mar 29 16:06:45 nope, never seen stuff like that Mar 29 16:07:09 nbd: ahh crap Mar 29 16:07:13 nbd: had to ask Mar 29 16:07:46 bbl Mar 29 16:08:50 nbd: do you know, if there are any platforms, that work with 4.4.3? Mar 29 16:08:58 no idea Mar 29 16:09:03 haven't played with it yet Mar 29 16:09:49 well, I will see what I can find out Mar 29 16:17:59 nbd: does 4.4.1 or 4.4.2 does work with something? Mar 29 16:40:21 wow time to get out of the monkeysuit :) Mar 29 16:41:06 stintel: how did it go? Mar 29 16:41:44 rtz2: it seemed to go very well, been there for two hours Mar 29 16:42:24 but today I got several email for possible projects as freelance, I start with one tomorrow, for two days, then we'll see if we continue Mar 29 16:42:55 so I am not sure if should take the job as employee or continue as freelance (with the risk I am out of work again in some months) Mar 29 16:42:58 tough decision Mar 29 16:45:26 I prefer freelance, but I have to think of my future too, can't live with my parents forever and all Mar 29 17:52:17 build #39 of cobalt is complete: Failure [failed shell_3 compile_6 shell_19] Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/39 Mar 29 18:33:51 hauke * r20585 /trunk/package/mac80211/patches/300-fix-mesh.patch: Mar 29 18:33:51 mac80211: fix mesh. Mar 29 18:33:51 This fixes #6774 Mar 29 18:51:05 fix mesh or fix mess? Mar 29 18:51:11 :P Mar 29 18:56:51 Hauke: Btw, is there still a reson to use robin for mesh deployment, or just go with a stock openwrt? Mar 29 18:57:07 xl0_msk: your joking right? Mar 29 18:57:31 xl0_msk: what is robin? Mar 29 18:57:54 xl0_msk: theres a much easier way yo deploy mesh Mar 29 18:58:00 Hauke: trust me you dont want to know Mar 29 19:02:18 Hauke: An openwrt fork with mesh support. Probably something from the old days. Mar 29 19:02:33 Neverming, it just pops high in google. Mar 29 19:02:58 xl0_msk: I have googled for it Mar 29 19:10:03 ping [florian] Mar 29 19:18:04 <[florian]> cshore: pong Mar 29 19:21:22 xl0_msk: I think the only remaining big reobin feature is the contral management Mar 29 19:21:36 argh spelling fail Mar 29 19:21:53 *robin *central Mar 29 19:22:32 Do you know what broadcom code versions you have stock firmware and routers for? Mar 29 19:23:02 <[florian]> cshore: humm not, it's really been a while since I do not flash anything stock on these Mar 29 19:23:21 xMff: not anymore :P Mar 29 19:23:21 I'd like to test my changes with 2.21, 3.1X, and Pirelli Mar 29 19:23:42 OutBackDingo: ? Mar 29 19:24:42 [florian]: hmmm....do you know what routers you have had those broadcom code versions when they were stock? Mar 29 19:25:16 <[florian]> cshore: I think the first two you mentionned Mar 29 19:26:41 [florian]: ok, could I fire over the patch and get you to test on routers with those two....it will at least make sure that the CFE doesn't complain about the CRC on first boot after flashing (second boot is my next trick, for the routers that complain about that right now) Mar 29 19:31:12 [florian]: the patch is here: http://pastebin.com/KK7HWVJH If you've got any comments before trying it, please let me know Mar 29 20:01:22 <[florian]> cshore: if Image/Build/CFE requires less parameters to the macro, re-order them maybe? Mar 29 20:02:14 <[florian]> cshore: otherwise I am fine with these changes Mar 29 20:02:16 so that the two only sometimes parameters are last? Mar 29 20:02:46 <[florian]> something like this, yes Mar 29 20:04:30 <[florian]> cshore: that's minor Mar 29 20:14:22 [florian]: http://openwrt.pastebin.com/UikGdupD ... images seem to build okay with the parameter reorder ... should I wait for you to try flashing a few images, or shall I commit? Mar 29 20:14:37 [florian]: I've flashed here Mar 29 20:15:05 cshore: does it fix any current issues or is it an enhancement? Mar 29 20:15:36 xMff: It's the groundwork for fixing the second boot causes CRC error for some routers Mar 29 20:16:05 ah, otherway I'd say hold it off until after the backfire release Mar 29 20:16:19 there is just not enough time remaining to test it all - imo Mar 29 20:21:46 <[florian]> cshore: go ahead, I will test once this reachs trunk Mar 29 20:36:39 [florian]: I can't commit it, I don't have access to firmware-utils Mar 29 20:36:53 [florian]: just tried Mar 29 20:36:54 <[florian]> cshore: right, want me to do it? Mar 29 20:37:09 [florian]: yes, please Mar 29 20:37:39 <[florian]> http://openwrt.pastebin.com/UikGdupD <- last version right? Mar 29 20:38:17 yes, and the comment I was using was Mar 29 20:38:17 brcm63xx: flashmap and image generation: reduced union bcm_tag to a single struct, Mar 29 20:38:17 combing the elements so that it is no longer necessary to create an openwrt-only Mar 29 20:38:17 tagid and tagcrc, and elimate the tagid detection and switch statements which Mar 29 20:38:17 made dealing with imagetags overly complicated, especially since the logic would Mar 29 20:38:17 need analogs in all code that touched the imagetag. Mar 29 20:39:49 florian * r20586 /packages/utils/mtd-utils/Makefile: [package] fix mtd-utils compilation with 2.4 kernels (#6985) Mar 29 20:39:53 florian * r20587 /packages/libs/libv4l/Makefile: [package] restrict v4l to 2.6 kernels only since it uses v4l2 includes (#6972) Mar 29 20:39:55 florian * r20588 /packages/net/openl2tp/Makefile: [package] restrict openl2tp to 2.6 kernels (#6970) Mar 29 20:39:58 florian * r20589 /packages/libs/libtorrent/Makefile: [package] libtorrent can only be built with gcc-4.2.1, which is provided by linux 2.6, so make it linux-2.6 specific Mar 29 20:44:11 <[florian]> cshore: your patch does not apply to imagetag.c Mar 29 20:44:40 <[florian]> cshore: want to see the rej file? Mar 29 20:44:44 yes please Mar 29 20:45:08 <[florian]> oh it's trivail Mar 29 20:45:55 <[florian]> http://openwrt.pastebin.com/9vc1auYR Mar 29 20:45:58 <[florian]> I will fix it by hand Mar 29 20:47:27 thank you Mar 29 20:47:41 I'm not sure why it didn't create the right diff for that Mar 29 20:48:23 <[florian]> I think it got line-wrapped when sent to the pastebin Mar 29 20:48:59 ah, that would do it, or a space/tab thing Mar 29 20:49:29 <[florian]> yup Mar 29 21:02:17 hauke * r20590 /trunk/package/kernel/modules/ (other.mk usb.mk): Mar 29 21:02:17 kernel: fix dependencies for x86 target Mar 29 21:02:17 kmod-hid and kmod-input-core are directly build into the kernel for the Mar 29 21:02:17 x86 target. No package on x86 should depend on it. Mar 29 21:02:17 This fixes #6963 Mar 29 21:05:46 <[florian]> cshore: I got a segfault when generating bcm6345 images Mar 29 21:05:58 <[florian]> --: line 1: 28886 Segmentation fault /home/florian/dev/openwrt/trunk/staging_dir/host/bin/imagetag -i /home/florian/dev/openwrt/trunk/build_dir/linux-brcm63xx/vmlinux.lzma.cfe -f /home/florian/dev/openwrt/trunk/build_dir/linux-brcm63xx/root.jffs2-64k -o /home/florian/dev/openwrt/trunk/bin/brcm63xx/openwrt-96345GW2-generic-jffs2-64k-cfe.bin -b 96345GW2 -c 6345 -e 0x80010000 -l 0x80010000 -d "" Mar 29 21:07:32 let me do a clean checkout Mar 29 21:09:31 <[florian]> sure Mar 29 21:20:39 florian * r20591 /trunk/target/linux/generic-2.4/patches/629-netlink_types_h.patch: [package] fix ndisc compilation failure (#6984) Mar 29 21:23:40 <[florian]> cshore: I got to wash my dish, bbl Mar 29 21:23:50 ok Mar 29 21:32:03 <[florian]> cshore: I am back Mar 29 21:32:44 I'm compiling....trying to see if I repeat the error here....I don't see anything obvious Mar 29 21:33:21 <[florian]> make target/linux/install V=99 leds you directly to the kernel/image generation Mar 29 21:35:34 I was doing that before I sent the patch, and didn't have a problem...I'm building the toolchain and then image for a fresh checkout to see of the patch missed something Mar 29 21:36:16 <[florian]> I do not think you did Mar 29 21:39:15 Another possibility is an error in the pirelli detection logic (strings in C can be a pain) Mar 29 21:42:44 but I'm trying to reproduce the error so that when I try a couple things I think might wrong I know the difference between fixed and no change Mar 29 21:48:50 <[florian]> cshore: I am off to bed now, update me with anything you have and I will have a look at it when I wake up Mar 29 21:57:23 ok Mar 29 23:14:49 jow * r20592 /trunk/package/openssl/ (Makefile patches/400-cve-2010-0740.patch): [package] openssl: add patch for CVE-2010-0740 ("Record of death") vulnerability Mar 30 01:23:48 thepeople: are the new package maintainers going to be added to the Makefiles? Mar 30 01:27:16 swalker: they can add themselves to the makefiles Mar 30 01:27:48 swalker: here is a list of them anyhow https://dev.openwrt.org/wiki/packages Mar 30 01:27:51 thepeople: where should we add ourselves; will there be an email? Mar 30 01:30:31 cshore: add a MAINTAINER:=MYNAMEHERE to the package definition Mar 30 01:37:27 cshore: in the makefile of your packages of course Mar 30 01:44:51 that I knew....I didn't know about the MAINTAINER field Mar 30 01:58:24 http://pastebin.org/128262, maintainers diff Mar 30 02:00:05 swalker: where is that at? Mar 30 02:01:08 "that" being? Mar 30 02:02:16 that diff, where do you find that file Mar 30 02:03:16 * thepeople scraches head Mar 30 02:08:00 there's a maintainer column on my html page, sort by maintainer, ctrl-select the package cells with maintainers, do the same with the wiki page, diff the two files Mar 30 02:08:53 oh :-) Mar 30 02:09:30 grep -m 1 MAINTAINER:= package/*/Makefile package/feeds/packages/*/Makefile basically and then compare Mar 30 02:14:42 yea, I just didn't know what you were referencing with that list becuase I had never seen it before Mar 30 02:16:53 ping rtz2 Mar 30 02:17:04 cshore: pong Mar 30 02:17:18 for the wrt160nl crc fix patch, what arch is it? Mar 30 02:18:33 cshore: ar71xx Mar 30 02:18:45 rtz2: I'm making the fixtrx frxcrc and doing conditional compilation on arch so it doesn't bloat irrelevant archs (and using fixcrc for brcm63xx crc fix too) Mar 30 02:19:38 cshore: you also need to patch then length field Mar 30 02:20:01 rtz2: which length field? Mar 30 02:20:02 cshore: and it may be useful for brcm47xx too Mar 30 02:20:13 cshore: image length in the trx header Mar 30 02:20:13 rtz2: that I knew Mar 30 02:20:47 ok Mar 30 02:20:50 rtz2: oh, I'm using different code....we don't use a trx...the crc fixup is different Mar 30 02:21:21 ahh, ok I thought you wanted to merge it together Mar 30 02:21:42 or do you? Mar 30 02:21:46 rtz2: well kind of....I'm using the fixcrc command as a multiple choice thing Mar 30 02:22:00 cshore: ahh, ok Mar 30 02:22:16 rtz2: basically same name, some shared code, but different crc fixup Mar 30 02:25:42 cshore: do you want to autodetect it or use a command line argument? Mar 30 02:25:55 compile-time ifdef Mar 30 02:26:36 cshore: you sure this won't blow up with an architecture which needs two different methods? Mar 30 02:27:25 rtz2: so far it's only brcm63xx and ar71xx Mar 30 02:28:16 rtz2: if there is some arch that needs more complicated handling I'll let person adding it figure it out Mar 30 02:28:29 cshore: ok Mar 30 02:28:50 cshore: rdc could also use it, the ar525w has some checksum Mar 30 02:29:07 but it's a partial one only Mar 30 02:31:15 and at the moment computed in-kernel Mar 30 02:31:24 cshore: when do you plan to merge it? Mar 30 02:31:29 rtz: I figure they'll all be different, so even though the function shares the same name, it's really different code for each (at present with the exception of a couple of basic sanity checks, and end of function error messages) Mar 30 02:31:42 rtz2: I'll leave that up to Florian...I'm not done yet **** ENDING LOGGING AT Tue Mar 30 02:59:57 2010