**** BEGIN LOGGING AT Thu Sep 17 02:59:59 2015 Sep 17 03:03:39 build #89 of x86.kvm_guest is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/89 Sep 17 04:05:37 build #89 of ar7 is complete: Failure [failed shell_4] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/89 Sep 17 04:33:58 build #89 of x86 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/89 Sep 17 04:51:43 build #93 of ar71xx.nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/93 Sep 17 08:39:26 is there a porting guide from uClibc to musl? seems kismet is getting some things wrong under musl (e.g. recording signal strength) Sep 17 08:43:16 lol, the musl-libc.org webpage is so tiny on my display that I thought the top like said "How to sue", which i was considering ;-) Sep 17 08:44:28 russell--: usually musl does things correctly but does not identify itself with a define like __uclibc__ or __glibc__ Sep 17 08:44:43 russell--: therfore programs fall back to broken backup code paths or bsd semantics Sep 17 08:45:00 * russell-- is trying uClibc on ubnt where i was seeing strangeness Sep 17 08:45:30 the most frequent issues with musl are: Sep 17 08:45:44 - kernel / userspace header conflicts Sep 17 08:45:53 - missing indirect includes on musl Sep 17 08:46:12 - missing glibc-isms Sep 17 08:46:24 these were runtime problems, not build failures Sep 17 08:46:38 it depends on the nature of the code Sep 17 08:46:45 whether it uses different libc functions Sep 17 08:46:47 etc. Sep 17 08:46:51 (and still very vague at the moment, still mapping the space) Sep 17 08:47:07 stuff like extrackting bits from an integer will work the same on any libc obviously Sep 17 08:47:15 *extracting Sep 17 08:47:18 right Sep 17 08:47:37 i like your spelling better Sep 17 08:47:43 wrong signal reporting could hint at header mismatches Sep 17 08:48:14 or maybe some standard struct not present due to a missing include or wrong code assumptions (#ifdef glibc) and then redeclaring own mismatching variants Sep 17 08:48:23 i did see some warnings about __attribute__((packed)), but i thought i fixed those Sep 17 08:48:35 that could break stuff too Sep 17 08:48:48 * russell-- will continue digging Sep 17 08:50:56 in a slight panic to get a working kismet-drone rig set up, as i'm going war-sailing in a week or so Sep 17 09:22:00 jow_laptop: er, why require static zlib on the host? Sep 17 09:29:42 to avoid issues with the relocatable toolchain we attempt to build important utilities (mksquashfs, make-ext4fs, ...) statically linked Sep 17 09:32:39 we cannot use LD_LIBRARY_PATH (abi mismatches) Sep 17 09:32:42 hm, ok. Sep 17 09:32:46 we cannot use rpath (libtool issues) Sep 17 09:32:49 I'll just revert that locally Sep 17 09:33:19 we cannot use host libraries (debian host utils crash at runtime on redhat systems) Sep 17 09:33:35 *dynamic host libraries Sep 17 09:33:56 that's a little concerning Sep 17 09:34:33 if the soname matches, it ought to be ABI-compatible Sep 17 09:35:25 example failure: svn: /home/user00/openwrt/trunk/staging_dir/host/lib/liblzma.so.5: no version information available (required by /lib64/libselinux.so.1) Sep 17 09:35:42 that happens when we attempt to use LD_LIBRARY_PATH Sep 17 09:35:52 jow_laptop: for kernel patches like the one I just posted... should I actually be posting a patch against the (15.05) openwrt.git repository, adding that file in target/linux/x86/patches-3.18 and a separate patch for trunk adding it in whichever patches-4.x directory is built for x86 today? Sep 17 09:35:57 or is just sending the kernel patch sufficient? Sep 17 09:36:23 when we rely on libtools rpath, the tools become non-relocatable as it is hardcodes the absolute path (e.g. /home/builder/openwrt/build_dir/host/lib/...) Sep 17 09:37:04 at this point since I'm building for x86, I don't even care too much about openwrt-built tools on the *main* system. Let alone building an SDK that can be taken elsewhere :) Sep 17 09:37:16 attempting to funnel "$ORIGIN" through various layers of makefiles, shell escaping and broken non quoted sub-invocations is futile (do I need $$$$$$ORIGIN or $$\$$\$$\$$\$$ORIGIN...) Sep 17 09:37:32 I'm frowning at the trunk build (which I'm doing for testing) building its own set of tools when 15.05 built *its* own yesterday and they're right there.... but it's easier just to go get another coffee and wait :) Sep 17 09:37:40 hehehe Sep 17 09:37:57 f%$&*&^$RIGIN Sep 17 09:39:11 as for the need of host tools at all... yeah, dependecies keep creeping in. Like tar --sort=name which is only available in the most recent version Sep 17 09:39:37 or an lzma-enabled mksquashfs which is not available at all in distro packages, or at least not widely Sep 17 09:39:45 I run Fedora. I'm not stuck in the 20th century with Debian stuff. I have --sort=name :) Sep 17 09:40:07 and my target today uses ext4 Sep 17 09:40:28 but yeah, I appreciate that's a very esoteric use case and there's not a lot of call for just using the host tools Sep 17 09:40:28 for that we need make-ext4fs Sep 17 09:40:43 getext2fs has certain limitations which make it unusable Sep 17 09:41:00 cc -o make_ext4fs allocate.o canned_fs_config.o contents.o crc16.o ext4fixup.o ext4_sb.o ext4_utils.o extent.o indirect.o make_ext4fs_main.o make_ext4fs.o sha1.o uuid.o wipe.o libsparse/libsparse.a -Wl,-Bstatic -lz -Wl,-Bdynamic Sep 17 09:41:00 /usr/bin/ld: cannot find -lz Sep 17 09:41:08 hm, reverting that one patch didn't help :) Sep 17 09:41:40 ah, Fedora *does* have a zlib-static package. I'm surprised Sep 17 09:41:52 mostly static libraries are anathema Sep 17 09:42:30 I'd love to stick to dynamic libraries Sep 17 09:42:43 but that requires libtool support first Sep 17 09:42:50 * dwmw2 shudders Sep 17 09:43:11 I'm going to try to ignore tools issues. All I wanted to do was udpate my router :) Sep 17 09:45:54 hm gr Sep 17 09:45:54 [ 4029.028922] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 dev_watchdo Sep 17 09:45:54 g+0x198/0x1b0() Sep 17 09:45:54 [ 4029.037460] NETDEV WATCHDOG: eth1 (8139cp): transmit queue 0 timed out Sep 17 09:45:54 I had noticed that 8139cp was built-in now. Which concerned me because I used to have to unload it and reload it occasionally, after a TX timeout like that. Sep 17 09:45:55 I see we have solved that issue. The box just rebooted after the tx timeout. Sep 17 09:45:55 I'm not sure I approve. Sep 17 09:46:56 nbd r46984 trunk/ package/kernel/lantiq/ltq-atm/src/ltq_atm.c target/linux/generic/patches-4.1/652-atm_header_changes.patch target/linux/generic/patches-3.18/652-atm_header_changes.patch target/linux/generic/patches-4.0/652-atm_header_changes.patch Sep 17 09:46:56 kernel: remove lantiq specific ATM API hacks and their kernel space users (fixes #20523) Sep 17 09:49:47 i wonder if the 'cp' part in '8139cp' is short for 'crap' Sep 17 09:50:42 but i guess not, it's already implied since the chip is made by realtek ;) Sep 17 09:56:19 yeah Sep 17 09:57:16 I have several 8111s and 8169s in service and haven't had any issues with them. Sep 17 09:58:02 I didn't have problems with the 8139 before I updated the switch it's connected to, IIRC Sep 17 09:58:08 although nothing else has issues with the switch Sep 17 09:58:15 it *ought* to recover from a tx timeout. Sep 17 09:58:20 certainly shouldn't crash the box :) Sep 17 09:58:22 Indeed. Sep 17 10:02:19 dwmw2: btw. a long time ago i sent some patches for jffs2 to add RENAME_WHITEOUT and RENAME_EXCHANGE support Sep 17 10:02:26 to the linux-mtd list Sep 17 10:02:33 never got any response and stuff doesn't seem to have been merged Sep 17 10:02:55 should i just resend that? Sep 17 10:03:09 which of the many instances of overlay/union/etc does that go with? :) Sep 17 10:03:18 overlayfs Sep 17 10:03:50 I had mostly been ignoring such patches on the basis that they go along with the instance they work with Sep 17 10:03:54 but we merged overlayfs, didn't we? Sep 17 10:03:55 userspace can also use it, as far as i know Sep 17 10:04:03 so yeah, I suppose those can go upstream. Sep 17 10:04:23 there's an outstanding argument about whether we do something stupid like 0,0 chardevs to represent whiteouts. Sep 17 10:04:24 isn't there? Sep 17 10:04:25 quite a few filesystems support those already Sep 17 10:04:35 e.g. ext4, f2fs, xfs Sep 17 10:04:47 can you cc me directly, and also dhowells@redhat.com please? Sep 17 10:04:52 ok, will do Sep 17 10:05:10 overlayfs does use chardevs as whiteouts Sep 17 10:05:15 I have a patch outstanding to dramatically speed up the mount-time GC run that happens on jffs2, too. Sep 17 10:05:15 so i guess that part has been settled Sep 17 10:05:39 RENAME_WHITEOUT uses it as well Sep 17 10:06:03 nice Sep 17 10:06:16 nbd: I believe the requirement is that whiteouts are represented as chardev to VFS, not that thhey are stored that way on the file system Sep 17 10:06:39 but I haven't been involved in that discussion or what the pros/cons are Sep 17 10:07:02 with that requirement it does make sense to store the whiteouts that way as well Sep 17 10:07:09 Linus' requirement was that they be shown that way to userspace Sep 17 10:07:23 it ended up being *implemented* that way in file systems too, which is a little silly Sep 17 10:07:43 it means an actual inode lookup, when all you really needed to see was the dirent Sep 17 10:07:52 ah right Sep 17 10:09:15 i was lazy and just used jffs2_mknod in my patch ;) Sep 17 10:09:27 me no like Sep 17 10:09:30 I want DT_WHT Sep 17 10:09:53 ok, i won't have any time to rework this any time soon though Sep 17 10:09:58 ok Sep 17 10:10:27 send it anyway. I'll bitch about it not having DT_WHT and we can hopefully get the generic part of that sorted out so it's easy in the fs Sep 17 10:10:42 let me know if you want the mount-time GC patch to be included in openwrt as well, to give it some more test exposure Sep 17 10:10:53 ah, my x86 build went through now, so i can merge your geode patch Sep 17 10:11:05 ta Sep 17 10:11:12 my trunk build is still building tools :) Sep 17 10:13:20 nbd: I have a config patch for x86 too, about to send... Sep 17 10:13:47 sent Sep 17 10:16:57 nbd r46985 trunk/target/linux/x86/patches-3.18/001-x86-platform-Fix-Geode-LX-timekeeping-in-the-generic.patch * x86: fix Geode LX timekeeping (#20531) Sep 17 10:17:03 ta Sep 17 10:17:04 nbd r46986 trunk/target/linux/x86/geode/config-default * x86/geode: enable DMI and Geos support (fixes #20512) Sep 17 10:17:50 nbd r46987 branches/chaos_calmer/target/linux/x86/patches-3.18/001-x86-platform-Fix-Geode-LX-timekeeping-in-the-generic.patch * x86: fix Geode LX timekeeping (#20531) Sep 17 10:17:54 nbd r46988 branches/chaos_calmer/target/linux/x86/geode/config-default * x86/geode: enable DMI and Geos support (fixes #20512) Sep 17 11:03:53 hm Sep 17 11:04:10 after that tx timeout, the box isn't even responding to sysrq on the serial console. Then it reboots (perhaps due to watchdog) Sep 17 11:04:47 i'd like to update x86 to 4.1 soon Sep 17 11:05:02 maybe it'll improve things a bit Sep 17 11:05:22 I'm actually using 4.2 on this, because I updated to ensure that IPv6 panic was still happening. Sep 17 11:05:29 ok Sep 17 11:06:07 I'll disable the hardware watchdog, enable nmi watchdog (which should give me a backtrace not just a reset) and enable lock debugging Sep 17 11:09:07 build #88 of lantiq.xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/88 Sep 17 12:15:32 build #91 of brcm63xx.smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/91 Sep 17 13:02:32 build #88 of ramips.mt7620 is complete: Failure [failed shell_4 compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/88 Sep 17 13:03:04 build #88 of ramips.rt305x is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt305x/builds/88 Sep 17 13:09:01 jow r46989 trunk/tools/mtd-utils/patches/310-add-static-linking-option.patch * tools/mtd-utils: avoid linking libm statically Sep 17 13:41:14 build #87 of ar71xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/87 Sep 17 13:53:24 build #97 of brcm47xx.legacy is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/97 Sep 17 14:07:45 build #96 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/96 Sep 17 14:11:38 build #96 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/96 Sep 17 14:15:24 build #96 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/96 Sep 17 14:15:49 build #96 of brcm47xx is complete: Failure [failed shell_4 compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/96 Sep 17 14:36:25 build #87 of au1000 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/87 Sep 17 15:32:58 jow r46990 trunk/package/network/config/firewall/Makefile * firewall: depend on kmod-ipt-conntrack (#20542) Sep 17 15:33:43 jow r46991 branches/chaos_calmer/package/network/config/firewall/Makefile * CC: firewall: depend on kmod-ipt-conntrack (#20542) Sep 17 15:39:59 nbd r46992 trunk/target/linux/ generic/patches-3.18/082-ipv6-ip6_fragment-fix-headroom-tests-and-skb-leak.patch generic/patches-3.18/667-ipv6-Fixed-source-specific-default-route-handling.patch generic/patches-4.1/080-ipv6-ip6_fragment-fix-headroom-tests-and-skb-leak.patch * kernel: ipv6: ip6_fragment: fix headroom tests and skb leak Sep 17 15:40:10 nbd r46993 trunk/target/linux/ generic/patches-3.18/083-solos-pci-Increase-headroom-on-received-packets.patch generic/patches-4.1/081-solos-pci-Increase-headroom-on-received-packets.patch * kernel: solos-pci: Increase headroom on received packets Sep 17 15:55:23 jow_laptop: https://github.com/openwrt/packages/pull/1416 Sep 17 15:56:44 DonkeyHotei: feel free to revert it Sep 17 15:56:55 or rather try reverting it locally and see if it works then Sep 17 15:57:04 jow_laptop: i'm wondering what you meant though Sep 17 15:57:25 with musl you cannot mox kernel and userspace headers Sep 17 15:57:50 when a compilation unit includes e.g. both net/if.h and linux/if_tun.h it will fail due to redeclared structs and types Sep 17 15:58:32 but if_tun.h is needed Sep 17 15:58:38 the exclusion of in_tun probably led vpnc to believe that it cannot do something (like creating arbritarily named ifaces) Sep 17 15:59:06 we patched the kernel headers now to ease coexistance with musl userspace Sep 17 15:59:36 so it is possible that the one hunk https://github.com/openwrt/packages/pull/1416/files#diff-3a83b0987e038f6f220dca750e155e51R27 here can be reverted Sep 17 16:00:00 the one that comments out if_tun.h? Sep 17 16:00:47 yeah, basically try removing the # if defined(__GLIBC__) || defined(__UCLIBC__) guard again Sep 17 16:01:04 and see if vpnc builds then or fails horribly Sep 17 16:40:15 build #87 of at91 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/87 Sep 17 16:44:01 nbd r46994 branches/ chaos_calmer/target/linux/generic/patches-3.18/082-ipv6-ip6_fragment-fix-headroom-tests-and-skb-leak.patch chaos_calmer/target/linux/generic/patches-3.18/667-ipv6-Fixed-source-specific-default-route-handling.patch * kernel: ipv6: ip6_fragment: fix headroom tests and skb leak Sep 17 16:44:07 nbd r46995 branches/chaos_calmer/target/linux/generic/patches-3.18/083-solos-pci-Increase-headroom-on-received-packets.patch * kernel: solos-pci: Increase headroom on received packets Sep 17 16:45:07 build #95 of pxa is complete: Failure [failed shell_4 shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/95 Sep 17 16:58:26 nbd: can you please backport r46962 to CC? thanx Sep 17 17:12:01 build #96 of rb532 is complete: Exception [exception shell_4] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/96 Sep 17 17:22:28 nbd r46996 branches/chaos_calmer/package/system/procd/Makefile * procd: update to latest git revision Sep 17 18:42:22 jow_laptop: yeah it doesn't build that way. any idea how to get if_tun with musl? Sep 17 18:56:40 tcp_wrapper failed to build for CC, can not find -lnsl Sep 17 18:56:56 this was fine before Sep 17 18:57:10 i'm trying eglibc however Sep 17 18:58:42 ok I removed -lnsl from Makefile and it builds fine for eglibc for now Sep 17 19:05:31 DonkeyHotei: related: https://github.com/voidlinux/void-packages/issues/2483 Sep 17 19:06:48 seems like other musl libc project - alpine linux or gentoo hardened or buildroot project do not have vpnc Sep 17 19:07:07 s/project/distros Sep 17 19:07:53 plntyk: that's the same underlying issue but i don't see a solution Sep 17 19:09:20 yeah - sometimes other distros have faster fixes for these issues Sep 17 19:10:26 rewriting vpnc/changing the api is too much ? maybe vpnc is only using some minor definitions Sep 17 19:10:37 it's not even vpnc-specific, really. just there needs to be a way to access if_tun with musl Sep 17 19:11:07 it's using a *linux* api Sep 17 19:11:19 and it's being compiled for linux Sep 17 19:11:46 musl needs to not interfere Sep 17 19:14:24 DonkeyHotei: its no problem to access if_tun if its not mixed with netinet/* stuff from the libc Sep 17 19:14:41 i see Sep 17 19:14:45 build #88 of ath25 is complete: Failure [failed shell_4] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/88 Sep 17 19:14:59 change the netinet/... stuff completely to linux/... stuff Sep 17 19:15:02 I'll take a look as well later Sep 17 19:24:02 build #87 of ar71xx.mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/87 Sep 17 19:31:32 hm, i cannot compile trunk Sep 17 19:31:34 Build dependency: Please install a static zlib. (Missing libz.a or zlib.h) Sep 17 19:31:54 # ls -l /usr/include/zlib.h Sep 17 19:31:55 -rw-r--r-- 1 root root 87952 Sep 27 2013 /usr/include/zlib.h Sep 17 19:38:53 jow_laptop: i guess it's after "prereq-build: test for static zlib availability" Sep 17 19:40:00 ok, I installed "zlib-devel-static" and it's OK now Sep 17 19:40:12 this package provides /usr/lib64/libz.a Sep 17 19:40:24 jow_laptop: do we really need a static version Sep 17 19:40:26 ?? Sep 17 19:50:30 plntyk: the linux/... stuff does not appear to stand without netinet/... Sep 17 20:33:35 build #86 of mvebu is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/86 Sep 17 20:46:56 build #95 of x86.64 is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/x86.64/builds/95 Sep 17 20:54:04 build #98 of brcm63xx is complete: Exception [exception] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/98 Sep 17 23:35:34 jow_laptop: is it possible (in a practical sort of way) to have luci use an admin username of 'admin' instead of 'root'? Sep 17 23:41:12 build #96 of ramips.rt3883 is complete: Failure [failed shell_4 compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/96 Sep 17 23:42:34 build #96 of ramips.mt7628 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/96 Sep 17 23:43:58 build #95 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/95 Sep 18 00:27:51 build #86 of mpc85xx is complete: Failure [failed shell_4] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/86 **** ENDING LOGGING AT Fri Sep 18 02:59:58 2015