**** BEGIN LOGGING AT Tue Oct 07 03:00:00 2014 Oct 07 04:12:34 build #94 of ramips.rt3883 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/94 Oct 07 05:54:03 build #741 of ramips is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/741 Oct 07 06:50:03 build #709 of ppc44x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/709 Oct 07 06:52:47 build #209 of cns21xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/209 Oct 07 07:36:08 rmilecki r42828 trunk/target/linux/generic/patches-3.14/ (7 files) * kernel: move old "rootfs" splitter into separated file Oct 07 08:49:34 build #678 of sibyte is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/678 Oct 07 09:31:47 build #755 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/755 Oct 07 09:52:26 build #690 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/690 Oct 07 10:38:00 nbd r42829 trunk/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c * cns3xxx: fix register for enabling MMC/SD pins Oct 07 10:38:38 nbd r42830 trunk/target/linux/cns3xxx/patches-3.10/310-pci_isolated_interrupts.patch * cns3xxx: fix shared PCI interrupt mapping Oct 07 12:57:24 is there any reason to pad the squashfs images using the jffs2 padding format and end of filesystem mark, even when using just ubi and ubiblock? Oct 07 17:36:11 hi Oct 07 17:36:29 how is the policy for comminting stuff into packages that belong to another maintainer? Oct 07 17:40:34 I usually try to avoid it Oct 07 17:40:54 but if its security critical... Oct 07 17:40:59 W. Michael Petullo enabled ldap by default in dovecot and added it. as i don't use ldap i cant maintain his changes Oct 07 17:41:26 what should i do? kick his changes and tell him he should introduce a new package if he wants dovecot with LDAP? Oct 07 17:41:34 tripolar: the "nice" way is to just create a pull request so the maintainer can pick it up Oct 07 17:42:35 KanjiMonster jow_laptop : as i don't use ldap here i can't maintain the change, so is it okay to revert the change and tell him to create a new dovecot-ldap package? Oct 07 17:43:36 it's 13af207aaa89a6241435b9b6d8ee17890d5870ee Oct 07 17:43:41 just seens it Oct 07 17:43:46 well certainly not nice Oct 07 17:43:50 -s Oct 07 17:45:10 nice from me when i revert it? Oct 07 17:45:14 on the other hand it makes no sense to have dovecot & dovecot-ldap with different maintainers Oct 07 17:45:32 no I mena not nice for someone to push stuff behind your back Oct 07 17:45:58 i mean i can't maintain it and i won't install ldap here to test it Oct 07 17:46:21 personally I'd simply leave the feature in as long as it builds and if it ever causes troubles simply remove it Oct 07 17:47:15 okay i will write him a mail that he should stop doing this the next time he commits something in one of my packages that isn't an update/fixes a compile error i will revert it, at least i will disable ldap by default Oct 07 17:47:35 that sounds good to me Oct 07 17:49:33 jow_laptop: who is responsible for the packages github repo? could the person write a mail to tell everyone that it should be avoided to commit stuff in packages that belong to another person, only urgent fixes are fine to push other commits should be done by the maintainer Oct 07 17:54:08 tripolar: I think there is no sole responsible person, but we can probably write a mail to sort it out Oct 07 17:54:51 jow_laptop: okay i will do this Oct 07 17:55:00 thanks for the tips :) Oct 07 17:55:03 tripolar I guess he figured you are currently away for a long time with other stuff since there were pull requests (also fixes for CVEs) for your packages without you acting on them; I probably would have done the same eventually Oct 07 17:55:32 s/with other stuff// Oct 07 18:12:58 KanjiMonster you are right but no fixes for CVEs just enhancements at least what i found when i look in the commits Oct 07 18:13:48 tripolar: see e.g. https://github.com/openwrt/packages/issues/190 Oct 07 18:14:26 didn't see this one thanks Oct 07 18:21:10 tripolar: we have a general rule in our guidelines that you shouldn't simply commit stuff to other's packages Oct 07 18:24:12 but to be fair we have to make some sort of decision if the maintainer is not available / responding for a month or so Oct 07 18:25:09 but then again such changes should go through PRs at least so that a few other people can acknowledge them on behalf of the one that is not available Oct 07 18:25:59 okay Oct 07 18:26:59 another question is someone familiar with c++11? i get this error when compiling a package: Oct 07 18:27:02 error: 'alnum' is not a member of 'std::ctype_base' { return use_facet >(__loc).is(ctype_base::alnum, __c); } Oct 07 18:27:18 is gcc 4.8 too old to handle this or am i missing something? Oct 07 18:27:43 i get a bunch of other "is not a member of 'std::ctype_base'" errors too Oct 07 18:30:34 alnum should be c98 Oct 07 18:30:56 i mean c++98 Oct 07 18:31:06 and still valid in c++11 Oct 07 18:31:50 though might be issue with uclibcs c++ code Oct 07 18:32:10 maybe using standard libstdcpp would help Oct 07 18:32:39 should probably check the locales-header Oct 07 18:35:12 cyrusff: thanks Oct 07 18:47:27 tripolar: if you are using uclibc++ then it doesn't support any c++11 stuff, and likely even older ones not completely Oct 07 18:48:06 also avoid the map implementation at any costs, it is reaaally inefficient in uclibc++ Oct 07 18:48:37 KanjiMonster: how do i force the build system to not use uclibc++? Oct 07 18:49:36 tripolar: for a single package or globally? Oct 07 18:49:44 single package Oct 07 18:50:21 then you shouldn't need to do anything special (except linking against -lstdc++) Oct 07 18:50:59 okay, but i get his compile errors before i link Oct 07 18:51:20 it's -luClibc++ that requires all the hoops (like -nostdinc++ for the CXXFLAGS) Oct 07 19:04:24 okay thanks Oct 07 20:21:58 build #554 of octeon is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/554 Oct 08 01:13:54 build #95 of ramips.rt3883 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/95 Oct 08 01:31:49 build #97 of ar71xx.mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/97 Oct 08 02:44:27 build #742 of ramips is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/742 **** ENDING LOGGING AT Wed Oct 08 03:00:00 2014