**** BEGIN LOGGING AT Wed Sep 30 02:59:59 2015
Sep 30 08:39:48 <builder_> build #95 of kirkwood is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/95
Sep 30 08:49:42 <builder_> build #93 of ar71xx is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/93
Sep 30 09:17:02 <builder_> build #94 of lantiq.xrx200 is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/94
Sep 30 09:30:49 <karlp> _trine: wasn't there someone hopping up and down on the list a few months ago about how they were absolutely going to take over maintaining this essential aircrack-ng package? they were't on IRC iirc.
Sep 30 09:31:31 <_trine> karlp, was that Zero_Chaos ?
Sep 30 09:32:07 <_trine> or was it DataHead
Sep 30 09:32:09 <karlp> sounds right?
Sep 30 09:32:13 <karlp> zerochaos I think.
Sep 30 09:32:33 <_trine> maybe he is unavailable right now
Sep 30 09:34:46 <karlp> file a ticket on packages, tag them.
Sep 30 11:27:38 <karlp> is there a single "right" way to handle LD flags -rpath?  I see a mix of "nothing", "-rpath-link,$(STAGING_DIR)/usr/lib" and --disable-rpath.  Are those all just different solutions?
Sep 30 11:33:19 <jow_lapt1p> -rpath-link is usually a workaround for broken build systems
Sep 30 11:33:48 <jow_lapt1p> --disable-rpath sounds like a libtool flag (useful, to prevent it from embedding absolute host paths in every solib)
Sep 30 11:34:28 <jow_lapt1p> -rpath is required in rare cases (e.g. if a program has its own /usr/lib/foo/ search path) but should not be used to embed host paths
Sep 30 11:34:46 <jow_lapt1p> so no easy answer and more context is needed
Sep 30 11:35:22 <karlp> oh, was just seeing -rpath-link staging stuff in a new package, and thought it should be unecessary, but there does seem to be lots of -rpath-link pacakges in the feed already
Sep 30 11:35:47 <jow_lapt1p> it is usually required for fixing up indirect depends
Sep 30 11:35:58 <jow_lapt1p> say e.g. a program links liblua using -llua
Sep 30 11:36:06 <jow_lapt1p> liblua in turn depends on libm
Sep 30 11:36:15 <jow_lapt1p> so the proper linker cmdline would be -llua -lm
Sep 30 11:36:30 <jow_lapt1p> however many build systems are not aware of the extra required -lm
Sep 30 11:36:50 <jow_lapt1p> in the past the linker used to fix that up automatically
Sep 30 11:37:06 <jow_lapt1p> eventually it got stricter and required all dependant libs to be passed explicitely
Sep 30 11:37:36 <jow_lapt1p> a workaround is to pass --rpath-link which will instruct the linker to search that given directory for required but not explicitely mentioned libraries
Sep 30 11:38:01 <jow_lapt1p> so -llua -lm is correct
Sep 30 11:38:09 <jow_lapt1p> while -llua alone would fail
Sep 30 11:38:41 <jow_lapt1p> and -llua -Wl,-rpath-link=$(STAGING_DIR)/usr/lib would work too
Sep 30 11:39:07 <karlp> ok, so that seems to be what quite a few packages are doing then.  so that's all ok.
Sep 30 11:39:12 <jow_lapt1p> this is often more practical than fixing up broken build systems, especially autogenerated ones
Sep 30 11:39:36 <jow_lapt1p> and you cannot do something like a global LDFLAGS += -lm because you might not want to link *every* object against libm
Sep 30 11:40:30 <jow_lapt1p> rpath-link is usually fine, rpath alone should be checked carefully
Sep 30 11:40:35 <karlp> CONFIGURE_ARGS += --enable-static --disable-rpath sounds like workaroudns too then right? "fuck it, let's statically link it all"
Sep 30 11:40:38 <jow_lapt1p> because that ends up in binaries
Sep 30 11:41:00 <jow_lapt1p> karlp: yes, the above would be a good fit for host utility builds
Sep 30 11:41:11 <jow_lapt1p> considering the relocatability of those executables
Sep 30 12:14:31 <txomon|sauron> anyone knows if libubox or similar has something to reverse endianess?? i want to avoid writing endianess reversing code :(
Sep 30 12:15:44 <txomon|sauron> ok, found <endian.h> =)
Sep 30 13:14:44 <saik0> If I want to set up some routes dynamically I shoul dbe looking at netifd?
Sep 30 13:24:22 <saik0> yes.
Sep 30 13:24:46 <txomon|sauron> the name suggests so :P
Sep 30 13:49:56 <karlp> what's the IFD meant to stand for?
Sep 30 13:51:11 <zorun> network interface daemon?
Sep 30 14:00:45 <attila_lendvai> it suggests it for people who grew up on the linux/unix/gnu way of abbrviatng things, but not for anybody else...
Sep 30 14:03:59 <karlp> nor that it should be involved in magically creating routes.
Sep 30 14:04:04 <karlp> but that's minor :)
Sep 30 14:54:48 <xeem> is it possible to have wifi roaming by wpa supplicant while broadcasting an AP?
Sep 30 14:54:55 <xeem> *by using
Sep 30 15:02:16 <builder_> build #95 of avr32 is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/95
Sep 30 15:55:34 <Zero_Chaos> karlp: _trine: yes, I'm maintaining aircrack-ng, what is the issue?
Sep 30 16:03:01 <_trine> <_trine> aircrack-ng no longer compiles >>> https://paste.debian.net/313827/
Sep 30 16:11:29 <Zero_Chaos> _trine: libnl is on the deps list, did the genl component get broken out for some strange reason?
Sep 30 16:21:26 <_trine> Zero_Chaos, libnl is in the depends of the Makefile and libnl depends on libnl-genl so I don't know what the problem is
Sep 30 16:24:30 <Zero_Chaos> _trine: maybe some kind of parallel issue? is it replicatable with -j1?
Sep 30 16:24:45 <_trine> of course
Sep 30 16:25:35 <Zero_Chaos> tripolar: well, that sucks
Sep 30 16:26:29 <_trine> make package/aircrack-ng/{clean,compile} gives the same result
Sep 30 16:28:13 <_trine> I also notice my Makefile is still set at rc1 however I also tried rc2 as well,, same result but I didn't expect it to be different
Sep 30 16:28:30 <Zero_Chaos> tripolar: unable to replicate here using CC
Sep 30 16:28:54 <_trine> Zero_Chaos, I am trine  and I am using trunk
Sep 30 16:29:05 <Zero_Chaos> lol, sorry bad tab
Sep 30 16:33:15 <karlp> Zero_Chaos: fyi, DD/trunk has diverged a _long_ way from CC already...
Sep 30 16:35:31 <Zero_Chaos> karlp: I am aware, but the question is, why is this broke?
Sep 30 16:36:14 <karlp> jsut saying that "works for me on CC" isn't very useful for most people :)
Sep 30 16:36:46 <Zero_Chaos> karlp: perhaps
Sep 30 16:37:06 <Zero_Chaos> _trine: DD/trunk has genl as a dep for libnl still?
Sep 30 16:37:18 <_trine> not sure
Sep 30 16:37:28 <_trine> I think it should
Sep 30 16:38:31 <Zero_Chaos> looks like no
Sep 30 16:39:09 <_trine> (1) -> Libraries                                                                                   │
Sep 30 16:39:09 <_trine>   │   Defined at tmp/.config-package.in:26310                                                          │
Sep 30 16:39:09 <_trine>   │   Selects: PACKAGE_libpthread [=y] && PACKAGE_libnl-genl [=y] && PACKAGE_librt [=y] && PACKAGE_lib │
Sep 30 16:39:09 <_trine>   │   Selected by: PACKAGE_ibrcommon [=n] || PACKAGE_bmon [=n] || PACKAGE_keepalived [=n] || PACKAGE_w │
Sep 30 16:39:10 <_trine>   │                                                                                                    │
Sep 30 16:39:45 <_trine> so yes
Sep 30 16:40:03 <Zero_Chaos> _trine: for fun, can you specifically add libnl-genl to the deps and test again?
Sep 30 16:40:14 <_trine> yes
Sep 30 16:44:44 <_trine> Zero_Chaos, same >>> https://paste.debian.net/313956/
Sep 30 16:47:19 <Zero_Chaos> _trine: if openwrt is failing to pull in deps properly I am not sure what I can do
Sep 30 16:49:11 <_trine> I have just done a new CO and will try again with that
Sep 30 16:49:31 <_trine> I will let you know the result
Sep 30 16:51:05 <Zero_Chaos> _trine: thanks
Sep 30 17:37:53 <stintel> ah meh
Sep 30 17:38:03 <stintel> just updated my 2nd rspro, now also uses random mac address
Sep 30 17:40:43 <saik0> Trying to setup policy routing, when a new default route is added to the (non-main) table the router stops replying to ARP reuqests, though I cna route through it.
Sep 30 18:28:39 <stintel> sigh, trying to bisect the random MAC address bug, but old version no longer compiles
Sep 30 18:30:07 <_trine> Zero_Chaos, here is your result on a new CO >>> https://paste.debian.net/313971/
Sep 30 18:30:39 <Zero_Chaos> _trine: looks the same, confusing
Sep 30 18:30:48 <_trine> it is the same
Sep 30 18:37:21 <zorun> is the UCI-based firewall config supposed to handle a stateful firewall *without* NAT?
Sep 30 18:38:35 <zorun> ah, right, that's the "conntrack" option!
Sep 30 18:41:17 <stintel> ok I can fix the compile of older openwrt with WANT_AUTOMAKE=1.11
Sep 30 18:46:33 <stintel> pfft. now libtool version mismatch
Sep 30 20:10:54 <karlp> autotools, working around compatibilities of everything except themselves....
Sep 30 20:15:27 <txomon|sauron> karlp: we should probably move to scons o cmake
Sep 30 20:15:32 <txomon|sauron> like everyone
Sep 30 20:20:18 <nbd> don't use scons
Sep 30 20:20:19 <nbd> it's crap
Sep 30 20:20:49 <mrkiko> exiting, sorry
Sep 30 20:35:03 <stintel> hmm. someone should make fstools a required package :P
Sep 30 20:43:19 <stintel> I hope I can sysupgrade without fstools installed, because I totally don't remember how to recover my rspro from a bad flash
Sep 30 20:44:31 <stintel> deselecting many packages to hopefully speed up the bisect
Sep 30 20:44:33 <stintel> yeah right :)
Sep 30 20:44:46 <stintel> goddamnit this sucks
Sep 30 21:05:45 <swalker> stintel: dependency happened a day or two ago :)
Sep 30 21:07:55 <ausjke> if i chose to use eglibc, should I also prefer stdc++ instead of uclibc++?
Sep 30 21:08:06 <ausjke> are they related in any way?
Sep 30 21:08:34 <ausjke> I'm having wierd fork() issues with uclibc and like to try eglibc and see if that helps...
Sep 30 21:10:41 <stintel> swalker: ok
Sep 30 21:10:49 <stintel> I just wish I noticed this random MAC sooner
Sep 30 21:11:02 <stintel> but I didn't use my RSPro's anymore until recently
Sep 30 21:11:40 <ausjke> stintel: RSPro user here...
Sep 30 21:12:04 <stintel> ausjke: getting random MAC addresses with trunk
Sep 30 21:12:20 <stintel> doing a git bisect, but that is turning out to be a horrible PITA
Sep 30 21:12:59 <ausjke> running CC on one RSPro another one for trunk, is this issue new?
Sep 30 21:13:14 <txomon|sauron> nbd: it isn't, you do actually have to use it properly, but doesn't have magic on it
Sep 30 21:13:18 <stintel> ausjke: as I said, I have not used the RSPro's for a while until recently
Sep 30 21:13:28 <txomon|sauron> no strange syntax, and you can actually program your builder because it's plain python
Sep 30 21:13:29 <stintel> ausjke: https://dev.openwrt.org/ticket/20642
Sep 30 21:13:50 <stintel> ~3200 revisions between my known good and bad
Sep 30 21:17:20 <ausjke> stintel: what's the /proc/cmdline
Sep 30 21:17:51 <ausjke> stintel: and the MAC under redboot:fconfig
Sep 30 21:20:11 <ausjke> stintel: and I checked my CC-RSPro-dmesg, it also reports the same Random-MAC, so it's not just trunk
Sep 30 21:20:56 <stintel> ausjke: hmm, working revision has ethaddr=00.15.6d.c3.31.57 in cmdline, other rspro with non-random mac has no ethaddr= there
Sep 30 21:25:36 <stintel> ausjke: feel free to add to the ticket that CC is also broken
Sep 30 21:32:16 <ausjke> mach-ubnt.c does mention some ubnt device has MAC issues and this 'random MAC' is from arch/mips/ath79/dev
Sep 30 21:32:19 <ausjke> -eth.c
Sep 30 21:33:28 <ausjke> and arch/mips/ath79/mach-ubnt.c; i would just bi-sect these few files instead of the whole git
Sep 30 21:34:23 <stintel> I had looked in git log for those file
Sep 30 21:34:30 <stintel> and git show'd the commits that changed them
Sep 30 21:34:50 <stintel> but didn't really see anything
Sep 30 21:35:33 <ausjke> to get the random MAC ubut has either to present a multi-case or all-zero MAC, I guess it's probably all-zero for some reason, then it generates a random MAC
Sep 30 21:35:48 <ausjke> s/multi-case/multicast
Sep 30 21:37:49 <stintel> ugh and that flash on the rspro is so damn slow
Sep 30 22:32:19 <stintel> ausjke: bisect almost complete, it's likely the switch to 4.1 kernel
Sep 30 22:32:33 <stintel> ausjke: but that makes no sense if you see the problem on CC ?
Sep 30 22:44:39 <stintel> I am going to bet it's 506-MIPS-ath79-prom-parse-redboot-args.patch
Oct 01 01:14:53 <ausjke> tcp_wrapper can not be built when eglibc is used, missing libnsl
Oct 01 01:16:41 <ausjke> https://github.com/openwrt/packages/issues/456   musl had similar issue
Oct 01 01:19:08 <stintel> meh, now my build is failing with this: http://pastebin.com/3hhK0Rg7
Oct 01 01:20:02 <ausjke> removed -lnsl from Makefile works
Oct 01 01:21:22 <stintel> ugh fuck it, bedtime, almost 3:30AM
Oct 01 01:26:36 <builder_> build #98 of netlogic is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/98
Oct 01 01:41:54 <builder_> build #96 of arm64 is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/arm64/builds/96
**** ENDING LOGGING AT Thu Oct 01 02:59:58 2015