**** BEGIN LOGGING AT Fri Jun 19 02:59:59 2015 Jun 19 07:01:49 build #34 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/34 Jun 19 07:02:18 build #34 of ep93xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/34 Jun 19 07:08:12 build #35 of rb532 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/35 Jun 19 08:07:13 build #34 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/34 Jun 19 08:14:44 meh.. etherwake pulles by luci-app-wol breaks because of musl.. Jun 19 08:20:47 well its the common header conflict thingy Jun 19 08:21:07 see http://wiki.musl-libc.org/wiki/FAQ#Q:_why_am_i_getting_.22error:_redefinition_of_struct_ethhdr.2Ftcphdr.2Fetc.22_.3F Jun 19 08:25:25 seems like davfs2 asame. thanks, let me check it Jun 19 08:31:52 dape: regarding that there you can either remove that functionality of error.h or do sth. like whats mentioned on the first 2 google search hits (musl error.h) - stub that functionality etc. Jun 19 08:34:50 interesting, reboot isn't rebooting on recent ramips (asiarf awm002) Jun 19 08:35:18 dash eff worked (i.e. reboot -f) Jun 19 08:35:18 kaloz r46061 trunk/package/kernel/mwlwifi/Makefile * mwlwifi: upgrade to 10.3.0.3 Jun 19 08:36:03 kaloz r46062 branches/chaos_calmer/package/kernel/mwlwifi/Makefile * mwlwifi: upgrade to 10.3.0.3 (backport of r46061) Jun 19 08:40:27 build #35 of lantiq is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/35 Jun 19 09:10:07 build #34 of octeon is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/34 Jun 19 09:39:36 hmm. only once. better now Jun 19 09:41:27 ah, it was on a factory reset Jun 19 09:45:00 jffs2reset -y && reboot & (the reset part doesn't work) Jun 19 09:48:26 that seems to be the current command in base-files Jun 19 09:48:41 maybe a musl thing? Jun 19 10:25:48 russell--: maybe, I can confirm the (non-)behaviour on bcm63xx on trunk with musl Jun 19 10:43:09 build #35 of mpc85xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/35 Jun 19 11:12:49 jogo r46063 trunk/ (45 files in 5 dirs) * kernel: update 4.0 to 4.0.5 Jun 19 13:30:23 cyrus r46064 trunk/package/network/utils/iproute2/Makefile * iproute2: honor LDFLAGS Jun 19 13:45:54 cyrus r46065 trunk/package/libs/libtool/ patches/160-passthrough-ssp.patch patches * libtool: enable passthrough for SSP options Jun 19 14:06:17 Hi, I'm working on a patch to fix mac80211 hwsim for the UML target.. it's broken because of include guards https://gist.github.com/glycoknob/f633fe131c3bd5b60112 - maybe someone will take a look if that's good enough for submitting? Jun 19 14:09:08 cyrus r46066 trunk/package/libs/uclibc++/ ++/Makefile ++/patches/010-honor-ldflags.patch * uclibc++: honor ldflags, disable SSP Jun 19 14:36:43 cyrus r46067 trunk/package/libs/uclibc++/Makefile * uclibc++: only disable SSP for ppc Jun 19 14:59:12 build #36 of lantiq.xrx200 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/36 Jun 19 17:07:19 cyrus r46068 trunk/package/network/ services/ppp/patches/530-pppoe_send_padt.patch services/ppp/patches/001-honor-ldflags.patch services/ppp/Makefile services/ppp/patches/140-pppoe_compile_fix.patch * ppp: honor LDFLAGS Jun 19 17:15:58 is x86_64 really broken with musl & stack protector ? seems really strange since this is obviously the main target of alpine or sabotage linux ... - "arch/x86/Makefile:114: stack-protector enabled but compiler support broken" Jun 19 17:19:04 plntyk: is it broken? Jun 19 17:19:39 well I get this message when I try to compile for x86-64 with 4.8 and 4.9 gcc Jun 19 17:19:58 interesting Jun 19 17:19:58 in trunk Jun 19 17:20:09 will try later Jun 19 17:20:32 i had fun fixing packages not honoring LDFLAGS for a while now Jun 19 17:20:39 but this seems to be another issue Jun 19 17:35:15 build #34 of ar71xx.mikrotik is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/34 Jun 19 17:42:11 cyrusff: looking at the asm code & searching : it seems this issue is reported at the bugtracker of gcc /redhat too: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491 Jun 19 17:48:18 nbd r46069 trunk/toolchain/musl/patches/110-read_timezone_from_fs.patch * musl: read the timezone from /etc/TZ Jun 19 18:53:24 cp -fpR /home/danielg4/openwrt-test/staging_dir/toolchain-i386_i486_gcc-4.8-linaro_musl-1.1.10/lib/libssp.so.* /home/danielg4/openwrt-test/build_dir/target-i386_i486_musl-1.1.10/toolchain/ipkg-x86/libssp/lib/ Jun 19 18:53:24 cp: cannot stat '/home/danielg4/openwrt-test/staging_dir/toolchain-i386_i486_gcc-4.8-linaro_musl-1.1.10/lib/libssp.so.*': No such file or directory Jun 19 18:53:24 make[3]: *** [/home/danielg4/openwrt-test/bin/x86/packages/base/libssp_4.8-linaro-1_x86.ipk] Error 1 Jun 19 18:53:57 clean your toolchain Jun 19 18:54:22 make toolchain/clean? Jun 19 18:54:34 better do make dirclean Jun 19 18:55:30 it seems the transition to musl is going smooth so far Jun 19 19:05:33 what world are you living in? Jun 19 19:06:01 build #34 of adm5120 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/34 Jun 19 19:09:04 karlp could be worse, no? Jun 19 19:28:11 sure. Jun 19 19:28:41 but that doesn't really mean smooth :) Jun 19 19:30:52 karlp is musl better than uclibc or just.. different? Jun 19 19:31:13 plntyk: can't reproduce your gcc-failure Jun 19 19:31:50 using fresh trunk and selecting x86_64 (keeping musl and SSP=regular) toolchain builds Jun 19 19:31:51 Devastator: probably just different, but just because most upstream packages now know that uclibc exists, and many fo them hav efixed things, doesn't necessarily mean that it's time to go and toss it out and make them learn about the existance of another :) Jun 19 19:32:05 I'm sure musl is better than uclibc, I like the idea of musl a lot. Jun 19 19:32:29 the last uclibc release is >3 years old Jun 19 19:32:35 I'd kinda like to see a little more time spent on the reaching out to upstream before hard switching and patching locally. Jun 19 19:33:06 other distros have switched quite a while ago Jun 19 19:33:22 and have started to nag upstream about fixing their code Jun 19 19:33:34 what other distros? Jun 19 19:33:35 buildroot switched to uclibc-ng this month Jun 19 19:33:40 e.g. alpine linux Jun 19 19:33:47 gentoo also has some musl support Jun 19 19:33:52 though it's not used by default there of course Jun 19 19:33:58 plntyk: buildroot and uclibc are same project Jun 19 19:34:02 iirc Jun 19 19:34:16 related, but not the same Jun 19 19:34:16 like I said, I like the idea of musl, it's great thing, but I wouldn't say it' sbeen "smooth" Jun 19 19:34:20 well they have 2 different repos and ppl Jun 19 19:34:24 http://lists.busybox.net/pipermail/buildroot/2015-June/130161.html Jun 19 19:34:26 afaik libc is still the most used, no? Jun 19 19:34:28 karlp: i agree that it hasn't been smooth Jun 19 19:34:39 karlp: but i didn't see any way to make a smooth transition without dragging things on for years Jun 19 19:34:51 i guess enabling SSP didn't make it exactly smoother but well had to be done at some point Jun 19 19:35:12 nbd: I think maybe just not having all the patches applied straight away locally, but having more of them broken, for a while, toget more pressure from users as well on upstreams Jun 19 19:35:28 ie, jow's done great work, but almost none of it was sent upstream at the same time. Jun 19 19:35:35 karlp: imho openwrt doesn't generate much pressure for upstream projects Jun 19 19:35:45 it's too exotic for that Jun 19 19:35:52 at least filing the bug usptream would have been a good start Jun 19 19:36:10 and particularly for the easy things like, "you dind't include fcntl.h like you should have" Jun 19 19:36:25 did that for some projects as well Jun 19 19:36:35 I don't find openwrt exotic, because it contributes with lots of things upstream Jun 19 19:36:37 e.g. babeld released new version with musl support yesterday or so Jun 19 19:36:49 Devastator: compared to mainstream distros it's quite exotic Jun 19 19:36:50 yeah, and plenty of projects will, _if_ they know there's a problem. Jun 19 19:37:24 i don't think leaving things broken until upstream fixes stuff is the way to go Jun 19 19:37:32 doesn't have to be forever Jun 19 19:37:39 but jow was fixing things within hours, Jun 19 19:37:47 there was no chance for upstream to even know. Jun 19 19:37:50 well, if things are broken, openwrt users nag us, not the upstream projects Jun 19 19:38:00 seems to me most problems are legacy code + tests that fail because nobody dared to produce a libc without some "__MAJOR__" version macros Jun 19 19:38:27 i could start rant about general brokenness of many projects buildsystems Jun 19 19:38:35 and that too Jun 19 19:38:43 hell i fixed like a dozen packages that didn't honor LDFLAGS correctls Jun 19 19:38:48 nbd: given taht we've only _just_ forked, it feels like at least a week or two would have been suitable maybe? Jun 19 19:39:14 karlp: you mean delaying the switch, or leaving packages broken? Jun 19 19:39:18 cyrusff: c-ares actually complains if you put -D (from fortify_source) into CFLAGS instead of into CPPFLAGS :) Jun 19 19:39:26 nbd: leaving packages broken a little longer Jun 19 19:39:32 karlp: what's the point? Jun 19 19:39:42 as i said, the resulting pressure does not make it to upstream projects Jun 19 19:39:46 to give upstreams a _chance_ of being involved? Jun 19 19:39:48 it stays within openwrt, where it is counterproductive Jun 19 19:40:04 it stays within openwrt, because jow was fixing them and not even _notifying_ upstream Jun 19 19:40:08 karlp: i will tackle FORTIFY_SOURCE at some point, but i need to import a libc-agnostic version of it first Jun 19 19:40:10 so of course it doesn't make it upstream Jun 19 19:40:33 cyrusff: no big deal, I think c-ares is being overly anal about it anyway, Jun 19 19:40:52 at the moment FORTIFY_SOURCE will probably do nothing on musl Jun 19 19:40:57 karlp: i still don't see how leaving things broken makes any difference wrt. notifying upstream projects Jun 19 19:40:59 since its simply not implemented Jun 19 19:41:06 well, having trunk half broken at least serves as a nice incentive to try out the latest rc of CC ;D Jun 19 19:41:26 +1 to that ^^ Jun 19 19:41:27 plntyk: okay could confirm your issue now Jun 19 19:41:32 nbd: because it lets package maintainers for openwrt deal with upstream as the maintainers they are, instead of it just being "fixed" overnight before people even know it was broken. Jun 19 19:41:55 plntyk: seems it happens at link-time of kernel Jun 19 19:42:28 KanjiMonster: it's not _half_ broken, it's really not that many packages at all I don't think, it's maybe not been _smooth_ but it's far from a disaster :) Jun 19 19:42:40 speaks well to musl how well it has gone :) Jun 19 19:43:07 karlp: package maintainers were already asked to deal with musl months ago, before it was made the default Jun 19 19:43:10 some did Jun 19 19:43:13 some didn't Jun 19 19:43:28 where was that? I'm on the mailing list and I don't remember it at all Jun 19 19:43:36 and i think most maintainers would probably just have patched the packages, often without notifying upstream Jun 19 19:43:49 i don't remember exactly, it was too long ago Jun 19 19:43:55 maintainers that don't notify upstream don't deserve to be maintaining things :| Jun 19 19:44:07 i just know that there was some activity on fixing musl related issues afterwards Jun 19 19:44:10 but that's out of scope of course :) Jun 19 19:44:21 was it before the openwrt packages moved to github? Jun 19 19:44:25 no Jun 19 19:44:26 after Jun 19 19:45:50 i remember there was week or so where we got like a dozen PRs and Issues there wrt. musl Jun 19 19:46:25 it's certainly gone better than procd ;) Jun 19 19:51:53 build #36 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/36 Jun 19 19:51:59 build #36 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/36 Jun 19 19:52:13 build #36 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/36 Jun 19 19:53:00 hahaha true, but procd is doing a good job nowadays Jun 19 20:05:59 build #36 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/36 Jun 19 20:12:30 nowadays, sure. :) Jun 19 20:31:40 build #35 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/35 Jun 19 20:31:44 build #36 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/36 Jun 19 21:25:52 build #35 of netlogic is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/35 Jun 19 21:59:49 build #35 of x86 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/35 Jun 19 22:02:53 build #36 of x86.64 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86.64/builds/36 Jun 19 22:38:37 build #35 of x86.kvm_guest is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/35 Jun 19 23:49:42 build #35 of x86.xen_domu is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86.xen_domu/builds/35 Jun 19 23:52:50 build #35 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/35 Jun 20 01:01:28 cyrusff: can you run https://github.com/slimm609/checksec.sh on your build tree? http://pastebin.com/raw.php?i=0xyvvESy **** ENDING LOGGING AT Sat Jun 20 02:59:58 2015