**** BEGIN LOGGING AT Sun Jun 26 02:59:57 2011
Jun 26 03:32:42 <builder_> build #36 of rdc is complete: Failure [failed compile_7]  Build details are at http://buildbot.openwrt.org:8010/builders/rdc/builds/36
Jun 26 11:39:29 <mirko> philipp64|laptop: pong
Jun 26 12:39:32 <builder_> build #57 of at91 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/57
Jun 26 12:58:20 <builder_> build #55 of ubicom32 is complete: Failure [failed compile_3]  Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/55
Jun 26 13:12:24 <^Willie^> ehm using snapshots/backfire/10.03.1-RC5-testing i noticed some issues that are related to libuclibc using opkg while trying to force reinstall a package
Jun 26 13:12:27 <^Willie^> Jun 25 15:53:09 OpenWrt user.info kernel: opkg[31803]: segfault at 63656863 ip b776da21 sp bfaff46c error 4 in libuClibc-0.9.30.1.so[b7745000+46000]
Jun 26 13:13:03 * ^Willie^ was thinking this only happened in my own compiled builds but looks like also happend with the prebuild x86 images.
Jun 26 13:14:02 <xMff> you didn't try to force it resinstalling libc by any chance?
Jun 26 13:14:18 <^Willie^> nope luci-app-statistics without deps
Jun 26 13:15:05 <^Willie^> --force-maintainer worked for me.. but using forced-reinstall resulted in a segfault
Jun 26 13:16:29 <^Willie^> *argh* pastebin.ca is broken again.. removed that bookmark for good..
Jun 26 13:17:08 <^Willie^> completer pastebin -> http://pastebin.com/7MHMXrXM
Jun 26 13:18:24 <^Willie^> onething for shure there is a bug in uclibc :D
Jun 26 13:18:58 <^Willie^> my diy builded collectd daemon keeps also segfaulting on uclibc
Jun 26 13:19:29 <^Willie^> but the collectd package from snapshots works ..
Jun 26 13:23:35 <^Willie^> xMff: also adding "more" modules to luci-app-statistics by supplying a patch file is ok for you ?
Jun 26 13:23:48 <xMff> sure
Jun 26 13:23:59 <^Willie^> if i make a patch per module then i endup in a kind of patch order :)
Jun 26 13:24:26 <^Willie^> easyer just adding the modules and run a patch from that.
Jun 26 14:25:37 <CIA-89> nbd * r27289 /trunk/toolchain/uClibc/ (3 files in 2 dirs): uclibc: make powerpc e500 support independent of the target name, always use it if the spe_fpu feature flag is set
Jun 26 17:41:54 <mazilo_> I notice Asterisk package resides in feeds/packages/net/asterisk-1.8.x directory and its Makefile has PKG_NAME:=asterisk18. When I tried to compile asterisk, 'make package/asterisk18/compile' spit out an error message saying NO such package. However, 'make package/asterisk-1.8.x/compile' is happily compiling the asterisk package. Does this make sense?
Jun 26 17:42:11 <philipp64|laptop> mirko: did you have a look at http://patchwork.midlink.org/patch/1120/ ?
Jun 26 17:55:09 <builder_> build #57 of s3c24xx is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/57
Jun 26 18:05:48 <philipp64|laptop> mazillo: yeah, the target naming isn't always obvious. I had the same issue with libiwinfo. the target name should match the CONFIG_PACKAGE_xxx name but sometimes doesn't.
Jun 26 18:06:28 <^Willie^> *argh* this is a long time ago stupid kate crash when delete folded code :S
Jun 26 18:06:57 <^Willie^> was just at the point and remove these 2 lines then save..
Jun 26 18:19:59 <mazilo_> philipp64|laptop: IIRC, it wasn't like that before.
Jun 26 18:28:26 <swalker> mazilo_: so use package/feeds/packages/<foo> and tab completion instead?
Jun 26 18:35:53 <philipp64|laptop> nbd: any idea why "struct ucred" would be missing from libnl-tiny when compiled with eglibc but not under uclibc?
Jun 26 18:55:08 <mazilo_> swalker: That's is what I use from now on. Thanks.
Jun 26 19:01:18 <swalker> updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html
Jun 26 19:31:15 <philipp64|laptop> anyone seen thepeople?
Jun 26 19:39:59 <mazilo_> I was looking around at the svn download trunk on yate packages for ar71xx, brcm47xx, Kirkwood, and did not find any. So, I set out to compile it myself and ended up with some error messages of 'dn_skipname' was not declared in this scope (http://pastebin.com/neRPu1se). Doe anyone here have a clue on how to fix this?
Jun 26 19:40:05 <^Willie^> philipp64|laptop:  NickServ [NickServ@services.]: Last seen  : Jun 17 10:31:21 2011 (1 week, 2 days, 09:05:47 ago)
Jun 26 19:40:16 <^Willie^> ;)
Jun 26 19:41:15 <mazilo_> The error messages are shown on lines #263 and #264 of http://pastebin.com/neRPu1se
Jun 26 19:41:56 <mazilo_> Perhaps, here is a missing library dependency.
Jun 26 19:47:46 <philipp64|laptop> I'm trying to build with eglibc but something looks like it's trying to build uclibc++ ... I can't tell what, though, and it's not explicitly turned on in my .config file.
Jun 26 19:48:43 <philipp64|laptop> is there a way to see what all packages depend on it?
Jun 26 19:48:56 <philipp64|laptop> either directly or indirectly?
Jun 26 20:49:21 <^Willie^> philipp64|laptop: hmm dunno about that builded plain glibc based 2 or 3 times and also had issues like library's linked to /lib and /var/lib mixed, i guess due misconfig in the advanced settings.
Jun 26 21:43:09 <philipp64|laptop> ^Willie^: is all of that still broken, or is any of it being fixed?
Jun 26 21:45:25 <^Willie^> i did not look further at the "Glibc" based build since the regulair uclibc builds do fine for my needs
Jun 26 21:48:02 <^Willie^> philipp64|laptop: anyway why do you need eglibc for ?
Jun 26 21:49:57 <CIA-89> mirko * r27290 /trunk/toolchain/eglibc/Makefile: [toolchain/eglibc] eglibc CAN be compiled with -Os after all - flags however need to be stated in $EGLIBC_CFLAGS as well
Jun 26 22:14:38 <philipp64|laptop> ^Willie^: did you see my posting on the mailing list?
Jun 26 22:15:31 <philipp64|laptop> there are codec's for Asterisk that are only released in binary format by their respective owners (Skype's skype codec, Digium's g729 codec, etc) that link against the eglibc ABI.
Jun 26 22:15:42 <philipp64|laptop> mirko: thanks!
Jun 26 22:17:38 <^Willie^> hmm ok
Jun 26 22:29:03 <philipp64|laptop> ok, running: grep 'asterisk-1.8.x/compile' tmp/.packagedeps
Jun 26 22:29:16 <philipp64|laptop> gets me some very weird results. why would compiling asterisk require mysql???
Jun 26 22:32:50 <philipp64|laptop> where do the compile dependencies get expressed?
Jun 26 22:53:47 <mirko> philipp64|laptop: you're welcome
Jun 26 23:03:02 <^Willie^> philipp64|laptop: not in package/asterisk/Makefile ?
Jun 26 23:03:37 <^Willie^> philipp64|laptop: or one of the patches if there are any..
Jun 26 23:06:31 <philipp64|laptop> no, there's some flat file somewhere that contains all of the host dependencies, etc.
Jun 26 23:07:11 <^Willie^> hmm not in tmp i think.. that can be overwriten/wiped when rebuild
Jun 26 23:09:36 <^Willie^> more likely that it is one of the asterisk deps that call for uclibc
Jun 26 23:15:24 <philipp64|laptop> tools/Makefile ...
Jun 26 23:20:19 <^Willie^> i have no idea in wat directory you looking when thinking from trunk/feeds/packages/net/asterisk-1.8.x/
Jun 26 23:25:07 <^Willie^> philipp64|laptop: wich mailing list article do you talk about right now ?
Jun 26 23:25:36 <philipp64|laptop> ummm... for which thread?
Jun 26 23:26:03 <^Willie^> jup
Jun 26 23:26:26 <philipp64|laptop> sorry, reset. what?
Jun 26 23:28:17 <^Willie^> your building against eglibc for asterisk and its deps and "something" calls for uclibc right ?
Jun 26 23:29:11 <^Willie^> dunno if you run make with V=99 or without.. normal you can se in the build process wat happends.
Jun 26 23:30:18 <philipp64|laptop> it apparently depends on uclibcxx and mysql.
Jun 26 23:30:34 <philipp64|laptop> I always build with V=99.
Jun 26 23:30:40 <^Willie^> wat i have seen here it is using mysql client yes.
Jun 26 23:30:50 <philipp64|laptop> it tells me what it's building. it doesn't tell me *why* it's building it.
Jun 26 23:31:45 <xMff> mysql is selected by asterisk
Jun 26 23:31:53 <xMff> uclibc++ is selected by mysql
Jun 26 23:32:00 <^Willie^> ahh tada..
Jun 26 23:32:20 <xMff> mysql is selected because someone did not specify it as conditional depdendency
Jun 26 23:32:58 <xMff> must be  +PACKAGE_asterisk18-mysql:libmysqlclient  instead of  +libmysqlclient
Jun 26 23:33:08 <xMff> same for all other deps of asterisk modules
Jun 26 23:33:27 <philipp64|laptop> no, wait... mysql is selected by asterisk-mysql. it should not be selected by asterisk "tout court".
Jun 26 23:33:54 <xMff> depdendencies are aggregated on a per-source base
Jun 26 23:34:06 <xMff> asterisk and asterisk-random-addon are fro mthe same source package
Jun 26 23:34:38 <philipp64|laptop> that's counter-intuitive.
Jun 26 23:35:39 <xMff> thats how it works. the DUMP phase which collects inter-package-depends has no concept of "enabled" or "disabled" items
Jun 26 23:35:52 <xMff> in fact there is not even a .config at this point
Jun 26 23:36:03 <xMff> so it cannot even evaluate those deps
Jun 26 23:36:22 <xMff> that is why they're aggregated on a per-source base
Jun 26 23:36:51 <xMff> by using the conditional depends syntax, the dependency evaluation is deferred until build time (when a .config is available)
Jun 26 23:37:03 <xMff> so that unneeded stuff is not built
Jun 26 23:37:17 <xMff> doing it "intuitively" would massively slow down the whole process
Jun 26 23:37:32 <xMff> its almost unbearable right now with caching and all modules enabled
Jun 26 23:38:29 <xMff> as far as the buildsystem is concerned, the inner organization of a package is a black box
Jun 26 23:38:45 <xMff> it only cares about the total sum of possible depdendencies
Jun 26 23:39:36 <philipp64|laptop> can we add a couple of tools to query the dependency database?
Jun 26 23:39:43 <xMff> grep
Jun 26 23:39:45 <philipp64|laptop> "showdep xxx" and showinvdep xxx"?
Jun 26 23:39:55 <xMff> took me 10 seconds to find the dependsa
Jun 26 23:39:59 <philipp64|laptop> that only shows a direct dependency.
Jun 26 23:40:04 <xMff> grep uclibc++ tmp/.packagedeps
Jun 26 23:40:06 <philipp64|laptop> it doesn't show an entire chain.
Jun 26 23:40:12 <xMff> propose some
Jun 26 23:40:24 <xMff> you can use scripts/metadata.pl as reference
Jun 26 23:40:34 <philipp64|laptop> also, when do you grep for "uclibc++" and when do you look for "uclibcxx"? that's not obvious either.
Jun 26 23:42:40 <xMff> what matters is the PKG_NAME
Jun 26 23:43:12 <xMff> uclibcxx is just the folder name which is only used in the internal representation of make targets
Jun 27 00:01:56 <mazilo_> Does anyone know the difference between CXXFLAGS and CPPFLAGS? When to use either one?
Jun 27 00:02:38 <nbd> one is for c++ and one is for the c preprocessor
Jun 27 00:03:55 <mazilo_> I gathered CPPFLAGS is for c++ and CXXFLAGS is for C preprocessor?
Jun 27 00:04:14 <xMff> the other way around
Jun 27 00:04:21 <xMff> CPP - C-Pre-Processor
Jun 27 00:04:24 <mazilo_> nbd: Thanks.
Jun 27 00:04:26 <xMff> CXX - C-+-+
Jun 27 00:04:38 <mazilo_> xMff: Thanks.
Jun 27 00:06:12 <mazilo_> I am trying to figure out why feeds/package/net/yate is broken and stumble upon the CXXFLAGS.
Jun 27 00:17:02 <philipp64|laptop> xMff: just confirmed that http://fpaste.org/IcQa/ works. can you please commit it?
Jun 27 00:17:32 <xMff> it contains a typo
Jun 27 00:18:00 <xMff> but yes, I can fix it
Jun 27 00:18:12 <philipp64|laptop> great. thanks.
Jun 27 00:18:56 <xMff> or maybe not
Jun 27 00:19:02 <xMff> its way more complex than that
Jun 27 00:19:14 <xMff> mysql must also be correctly disabled in configure
Jun 27 00:19:36 <xMff> otherwise the resulting binary might depend on it even if it was not enabled only because mysql happened to be around in staging_dir
Jun 27 00:19:42 <xMff> same for others
Jun 27 00:23:11 <xMff> we had similar problems already, for example witrh wget and libidn
Jun 27 00:24:56 <philipp64|laptop> ok, so then.... what's the fix?
Jun 27 00:25:18 <nbd> 02:16 < xMff> mysql must also be correctly disabled in configure
Jun 27 00:25:19 <xMff> auditing the asterisk 1.8 source and see when it depends on what
Jun 27 00:25:23 <nbd> that's the fix
Jun 27 00:25:24 <nbd> ;)
Jun 27 00:25:40 <xMff> though I just seen that the mysql part is already handled
Jun 27 00:26:17 <philipp64|laptop> I ask because I thought that line 207 already took care of all that.
Jun 27 00:30:26 <philipp64|laptop> on another subject... I've been staring at libnl-tiny and I can't figure out why it's not finding the definition of "struct ucred" when it builds iwinfo with eglibc.
Jun 27 00:37:49 <nbd> philipp64|laptop: well, it needs it defined by libc for nl.c anyway
Jun 27 00:38:47 <philipp64|laptop> why? what does it have to do with libc or stdlib?
Jun 27 00:39:05 <nbd> it's not something defined by libnl
Jun 27 00:39:11 <philipp64|laptop> it's defined in linux/include/linux/socket.h right?
Jun 27 00:39:25 <nbd> yeah, i meant libc+kernel-headers
Jun 27 00:39:37 <nbd> since libc usually carries the kernel headers along
Jun 27 00:39:56 <philipp64|laptop> right, so it comes from the kernel headers... that's what's so vexing.
Jun 27 00:40:08 <philipp64|laptop> why should changing the version of libc affect it? it makes no sense.
Jun 27 00:40:50 <nbd> the kernel header file does not seem to make it available to user space
Jun 27 00:41:01 <nbd> so it's probably up to the libc to provide it
Jun 27 00:41:13 <philipp64|laptop> merde alors!
Jun 27 00:41:28 <nbd> in the kernel tree that i'm looking at, it's inside a #ifdef __KERNEL__
Jun 27 00:41:48 <nbd> uclibc provides that struct in bits/socket.h
Jun 27 01:13:16 <philipp64|laptop> actually, the eglibc version of bits/socket.h is bracketed by #ifdef __USE_GNU ...
Jun 27 01:13:58 <xMff> bah, propaganda again
Jun 27 01:14:05 <philipp64|laptop> eh?
Jun 27 01:14:22 <xMff> they force you to state  "USE GNU" in all your code ;)
Jun 27 01:14:44 <philipp64|laptop> that's not just propaganda, that's forceful recruitment into a religious cult!
Jun 27 01:15:56 <xMff> anyway, you probably have to pass -D_GNU_SOURCE to the CFLAGS
Jun 27 01:16:17 <xMff> which then eventually results in #define __USE_GNU somewhere down the include chain
Jun 27 01:19:17 <philipp64|laptop> just for iwinfo, right?
Jun 27 01:20:09 <xMff> one could argue here
Jun 27 01:20:13 <xMff> iwinfo just uses libnl
Jun 27 01:20:33 <xMff> but if its the only package failing with the then probably yes
Jun 27 01:21:57 <philipp64|laptop> just tried this.. it builds... http://fpaste.org/tNW1/
Jun 27 01:22:52 <Weedy_lappy> >fedora
Jun 27 01:22:58 <Weedy_lappy> >forceful recruitment into a religious cult!
Jun 27 01:23:42 <xMff> the gnu source define is not harmful, no need to make it conditional
Jun 27 01:27:44 <philipp64|laptop> I'm just now trying to compile against libnl instead....
Jun 27 01:31:17 <xMff> ok I added the flag
Jun 27 01:31:32 <philipp64|laptop> this also works: http://fpaste.org/p75v/
Jun 27 01:33:54 <xMff> http://luci.subsignal.org/trac/changeset/7247
Jun 27 01:34:03 <philipp64|laptop> Weedy_lappy: well, as a contributor to both, I think Fedora is a lot less coercive.
Jun 27 01:34:40 <philipp64|laptop> xMff: I saw your fix, but I was wondering if it's necessarily the best choice, that's all.
Jun 27 01:34:53 <xMff> I'm not going to switch to libnl
Jun 27 01:35:08 <xMff> if libnl-tiny causes problems elsewhere the define can be moved there
Jun 27 01:35:53 <philipp64|laptop> would love to see x86/alix2 being built with eglibc and CONFIG_ALL=y ... just to help shake down such issues.
Jun 27 01:36:51 <philipp64|laptop> maybe thepeople can get that onto the build-bot roster.
Jun 27 01:43:20 <philipp64|laptop> nbd: can you please commit http://patchwork.midlink.org/patch/1150/ ? thanks.
Jun 27 01:45:16 <CIA-89> jow * r27291 /trunk/target/linux/x86/geos/base-files/etc/uci-defaults/: [geos] remove remaining uci-defaults
Jun 27 02:09:38 <philipp64|laptop> xMff: thanks!
Jun 27 02:28:00 <philipp64|laptop> I'm thinking that Asterisk has an unexpressed dependency on the crypto modules... http://fpaste.org/jHPN/
**** ENDING LOGGING AT Mon Jun 27 02:59:57 2011