**** BEGIN LOGGING AT Mon Jan 17 02:59:57 2011
Jan 17 03:03:17 <xMff> mazilo: I think it is a parallel build issue
Jan 17 03:03:41 <xMff> mazilo: try PKG_BUILD_PARALLEL:=0 in the Makefile
Jan 17 03:04:30 <xMff> mazilo: definitely parallel issue, see http://bugs.gentoo.org/show_bug.cgi?format=multiple&id=255378
Jan 17 03:05:42 <mazilo> xMff: You are right. I use 'make -j 4 package/xmlrpc-c/compile' to build and it crashed as shown. After you mentioned it, I tried to rebuild without the '-j' switch without a problem. So, can you please commit a new Makefile with 'PKG_BUILD_PARALLEL:=0'?
Jan 17 03:07:34 <CIA-77> jow * r25030 /packages/libs/xmlrpc-c/Makefile: [packages] xmlrpc-c: package is not safe for parallel build
Jan 17 03:11:58 <mazilo> xMff: Thanks.
Jan 17 03:15:26 <philipp64|laptop> damn it all to hell.
Jan 17 03:15:52 <philipp64|laptop> e2fsprogs won't build with PKG_BUILD_PARALLEL=0 ... so it's not within e2fsprogs... it's an external dependency.
Jan 17 03:16:13 <xMff> well there is tools/e2fsprogs and package/e2fsprogs
Jan 17 03:16:21 <xMff> are you sure you look at the right one?
Jan 17 03:19:37 <philipp64|laptop> no change... it's the host version that's building, but I think it fails to find gcc because it hasn't yet been built.
Jan 17 03:32:03 <cshore> philipp64: are you trying to build the toolchain with QUILT=1 or something.  I found QUILT=1 during toolchain build killed the buld
Jan 17 03:37:32 <philipp64|laptop> I'm doing "make -j6 V=99" and that's it.
Jan 17 03:40:22 <cshore> last week I built that way with no problem
Jan 17 03:40:27 <cshore> including e2fsprogs
Jan 17 03:41:06 <philipp64|laptop> it's been broken for me for over a week.
Jan 17 03:42:57 <philipp64|laptop> If I'm building 2.6.37, do I still need compat-wireless?
Jan 17 03:43:56 <cshore> oh wait, maybe your problem is tools/e2fsprogs for a ext4 image - I didn't do that
Jan 17 03:44:38 <cshore> and that should be built with the host's gcc not the OpenWRT gcc (tools is built before toolchain)
Jan 17 03:46:19 <philipp64|laptop> so.... why does configure try to find gcc?
Jan 17 03:47:15 <cshore> you mean why does it fail to find your host gcc?
Jan 17 03:48:30 <philipp64|laptop> no, why is it looking for the target CC?
Jan 17 03:48:59 <cshore> is this for creating an ext4 image, or for having e2fsprogs in the image?
Jan 17 03:49:04 <philipp64|laptop> it has, for instance, TARGET_CFLAGS += $(FPIC)
Jan 17 03:49:22 <cshore> for tools/e2fsprogs?
Jan 17 03:49:56 <cshore> not package/e2fsprogs?
Jan 17 03:50:57 <xMff> what is the actual error anyway?
Jan 17 03:51:43 <xMff> configure fails? then upload build_dir/host/e2fsprogs-*/config.log
Jan 17 04:19:40 <philipp64|laptop> pasting the entire build logs first... ftp://ftp.redfish-solutions.com/pub/openwrt.log
Jan 17 04:24:00 <cshore> that's not a gcc problem I don't think
Jan 17 04:24:16 <philipp64|laptop> actually, it seems to be qemu that's puking
Jan 17 04:25:50 <philipp64|laptop> here's the interesting part http://fpaste.org/ZDGa/
Jan 17 04:26:15 <philipp64|laptop> not sure why qemu is needed...
Jan 17 04:26:31 <cshore> yeah, it's the uuid feature for qemu that's the issue from the looks of it
Jan 17 04:27:23 <philipp64|laptop> so --disable-uuid or what?
Jan 17 04:27:38 <cshore> don't know....not sure what the deal is with qemu
Jan 17 04:28:07 <cshore> maybe for generating the emulator images?
Jan 17 04:42:05 <philipp64|laptop> so libuuid is built as part of e2fsprogs... but e2fsprogs gets build *after* qemu.
Jan 17 04:42:13 <philipp64|laptop> so qemu needs to depend on e2fsprogrs.
Jan 17 04:43:17 <philipp64|laptop> where are the dependencies expressed for packages?
Jan 17 04:49:54 <philipp64|laptop> cshore: I think I got it.
Jan 17 04:49:58 <philipp64|laptop> it's a one liner.
Jan 17 04:56:07 <philipp64|laptop> cshore: just emailed out the fix.
Jan 17 04:59:55 <philipp64|laptop> any committers around?
Jan 17 05:20:48 <cshore> let me look
Jan 17 05:24:42 <cshore> philipp64: shouldn't that just be $(curdir)/qemu/compile := $(curdir)/e2fsprogs/install
Jan 17 05:24:42 <cshore> that will call $(curdir)/automake/install via the previous dependency
Jan 17 05:27:13 <philipp64|laptop> it doesn't hurt to have it be both direct and indirect... and if the dependency on libuuid ever goes away... it will still be needed.
Jan 17 05:29:14 <cshore> I think it really should be only the one....otherwise you could argue the same way about most of the dependencies, and it break the exiting pattern.
Jan 17 05:30:31 <philipp64|laptop> well, all I know is it works as I sent it.
Jan 17 05:33:04 <philipp64|laptop> what about the other patch? the CONFIG_ symbols?
Jan 17 05:34:19 <philipp64|laptop> I got them stacking up 3 deep...
Jan 17 05:34:46 <cshore> The CONFIG looks okay
Jan 17 05:36:15 <cshore> patches you mean?
Jan 17 05:36:24 <philipp64|laptop> yeah...
Jan 17 05:36:53 <philipp64|laptop> I'm working with one of the netdev folks, and need to have the patches get in so he can reliably build.
Jan 17 05:37:14 <philipp64|laptop> without me sending him 5 patches just to build an image... sigh.
Jan 17 05:42:03 <cshore> hmmm.....you patch seems to have files that don't exist yet, but doesn't create them (.eg. target/linux/x86/config-default
Jan 17 05:42:25 <cshore> oh wait, I see
Jan 17 05:42:31 <cshore> wrong level start on the patch
Jan 17 05:44:10 <cshore> failed with rejects
Jan 17 05:44:54 <cshore> lets try that again
Jan 17 05:45:41 <cshore> do you have any patches that need to be applied before the CONFIG one?
Jan 17 05:47:50 <cshore> ok, how do I get the patch without the mail headers?
Jan 17 05:48:21 <cshore> cut-n-paste tends to screw up whitespace, so it's not a good option
Jan 17 05:48:30 <philipp64|laptop> sorry, I have two sets of patches from the file target/linux/x86/config-default
Jan 17 05:48:43 <philipp64|laptop> let me try again...
Jan 17 05:49:08 <cshore> ah, ok, maybe it was genuine rejects then
Jan 17 05:49:18 <cshore> not just email to patch problems
Jan 17 05:51:21 <philipp64|laptop> try: ftp://ftp.redfish-solutions.com/pub/missing-symbols.patch
Jan 17 05:52:28 <cshore> ok, that worked
Jan 17 05:54:10 <CIA-77> cshore * r25031 /trunk/target/linux/ (generic/config-2.6.37 x86/config-default):
Jan 17 05:54:10 <CIA-77> [x86]: Missing symbols for CONFIG_xxx ..
Jan 17 05:54:10 <CIA-77> Thanks Philip Prindeville
Jan 17 05:55:10 <philipp64|laptop> thanks!
Jan 17 05:55:16 <philipp64|laptop> now I'm down to 2.  :-)
Jan 17 05:55:25 <philipp64|laptop> plus the leds_geos thing.
Jan 17 05:56:57 <cshore> philipp64: someone already fixed the qemu thing
Jan 17 05:57:10 <philipp64|laptop> well, if you want to tweak the qemu patch to have a single dependency, that's fine too.
Jan 17 05:57:20 <philipp64|laptop> as long as they both work.
Jan 17 05:58:32 <cshore> philipp64: it's already fixed in trunk
Jan 17 06:00:11 <philipp64|laptop> how do you figure?
Jan 17 06:00:13 <cshore> by kaloz in 20478
Jan 17 06:00:24 <cshore> sorry 24078
Jan 17 06:00:53 <cshore> $(curdir)/qemu/compile := $(curdir)/e2fsprogs/install is in current trunk
Jan 17 06:01:54 <cshore> in fact I don't see where the other one is coming from....hmmm....
Jan 17 06:02:03 <jow_laptop> its broken
Jan 17 06:02:06 <blogic> morning
Jan 17 06:02:13 <jow_laptop> o/
Jan 17 06:02:37 <jow_laptop> cshore: someone added an automake dep a few lines below and broke it
Jan 17 06:02:52 <cshore> ah, ok, wrong line?
Jan 17 06:02:56 <philipp64|laptop> 24865
Jan 17 06:03:26 <philipp64|laptop> Hauke broke it I think with a regression.
Jan 17 06:03:31 <cshore> ah, I see....
Jan 17 06:03:46 <CIA-77> jow * r25032 /trunk/tools/Makefile: [tools] remove bogus qemu dependency
Jan 17 06:04:16 <jow_laptop> cshore: the second instance is overwriting the first
Jan 17 06:04:24 <cshore> right, I didn't see it
Jan 17 06:04:35 <jow_laptop> so after evaluation, qemu only depended on automake, not e2fsprogs
Jan 17 06:04:36 <cshore> until you pointed out there was nother one
Jan 17 06:26:17 <philipp64|laptop> will he?  won't he?
Jan 17 06:28:16 <cshore> philipp64? jow fixed it
Jan 17 06:48:58 <philipp64|laptop> no, I meant for the cs5535 stuff...
Jan 17 06:49:16 <philipp64|laptop> the module loads up, but... no devices are being created...
Jan 17 06:49:27 <philipp64|laptop> trying to figure out why.
Jan 17 07:07:17 <philipp64|laptop> jow_laptop: still around?
Jan 17 07:07:28 <philipp64|laptop> enabled debugging for hotplug.... seeing: Jan 17 06:55:03 OpenWrt daemon.info hotplug: name=cs5535_gpio, path=/module/cs5535_gpio
Jan 17 07:08:34 <philipp64|laptop> would that have matched the first entry in /etc/hotplug2-common.rules?
Jan 17 07:12:13 <xMff> looking
Jan 17 07:12:45 <xMff> no
Jan 17 07:13:11 <xMff> uhm sorry, yes
Jan 17 07:13:20 <xMff> assuming that name = DEVICENAME
Jan 17 07:18:57 <philipp64|laptop> ok, so we do a makedev /dev/cs5535_gpio 0666
Jan 17 07:19:52 <philipp64|laptop> but nothing gets created.
Jan 17 07:22:02 <xMff> wait
Jan 17 07:22:14 <xMff> no, the pattern does not match
Jan 17 07:22:24 <xMff> the expressions are anchored
Jan 17 07:22:38 <xMff> you need to add |cs5535_gpio
Jan 17 07:23:44 <xMff> any reason the driver calls it this way?
Jan 17 07:23:49 <xMff> special api?
Jan 17 07:25:11 <CIA-77> jow * r25033 /packages/net/xtables-addons/patches/003-redundant-bracket.patch: [packages] xtables-addons: remove m4 syntax error (#8593)
Jan 17 07:28:03 <philipp64|laptop> I pasted the logger line from the comment section into the first section... rebooting.
Jan 17 07:29:47 <philipp64|laptop> no, they're matching.
Jan 17 07:30:22 <russell_> what is the likelihood of capturing a kernel panic with a network console?
Jan 17 07:31:32 <philipp64|laptop> xMff: but...  pppd didn't come back up
Jan 17 07:31:56 <xMff> I lost context
Jan 17 07:39:07 <philipp64|laptop> jump on 97.120.16.248 .... do "head -n20 /etc/hotplug2-common.rules"
Jan 17 07:39:34 <philipp64|laptop> then "logread | grep hotplug" and "ls -l /dev/*gpio*"
Jan 17 07:45:26 <philipp64|laptop> see what I'm talking about?
Jan 17 07:55:09 <philipp64|laptop> xMff: we're missing soloscli...
Jan 17 08:00:30 <philipp64|laptop> but that's a different issue. anyway: Jan 17 07:44:30 OpenWrt daemon.info hotplug: name=cs5535_gpio, path=/module/cs5535_gpio, major=%MAJOR%, minor=%MINOR%, subsystem=module
Jan 17 08:00:43 <philipp64|laptop> which tells me that MAJOR and MINOR aren't being set.
Jan 17 08:05:32 <philipp64|laptop> ok, well, bedtime for me. I'll look at it more tomorrow.
Jan 17 08:05:46 <philipp64|laptop> ls /etc/init.d/
Jan 17 08:05:50 <philipp64|laptop> doh.
Jan 17 09:03:05 <Acinonyx> gmorning
Jan 17 09:41:17 <Acinonyx> bbl
Jan 17 17:18:58 <builder> build #59 of ps3 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/59
Jan 17 18:58:19 <builder> build #61 of pxcab is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/61
Jan 17 19:27:35 <mazilo> xMff: I have just posted this (https://forum.openwrt.org/viewtopic.php?pid=125742#p125742) and am hoping you and/or others can help me out to resolve patching issue.
Jan 17 19:39:18 <philipp64|laptop> very quiet today.
Jan 17 19:39:49 <philipp64|laptop> didn't know that Martin Luther King day was a holiday in Europe as well. :-)
Jan 17 19:54:35 <theMIROn> rly? it explains almost everything today...
Jan 17 19:59:01 <EqUaTe> philipp64|laptop: it wasn't last time i looked..
Jan 17 19:59:14 <EqUaTe> i think everyones just busy :P
Jan 17 20:50:19 <OutBackDingo> EqUaTe: hell i need to clone myself 3 more times
Jan 17 20:50:51 * xMff too
Jan 17 20:51:18 <EqUaTe> OutBackDingo: don't we all?
Jan 17 20:51:28 <EqUaTe> seriously, if anyone here comes up with cloning tech, please share.
Jan 17 20:51:51 <OutBackDingo> EqUaTe: see dolly :)
Jan 17 20:51:53 <OutBackDingo> baaaaaaaaaa
Jan 17 20:52:00 <EqUaTe> _USABLE_ cloning tech :P
Jan 17 20:52:28 <EqUaTe> good luck cloning a bloke with what they used :P
Jan 17 20:53:23 <theMIROn> no need to clone, just speed up ur local time against the common outter
Jan 17 20:54:27 <EqUaTe> no thanks, i don't want to die prematurely.
Jan 17 20:57:07 <theMIROn> yeah, this side issue isn't fixed yet
Jan 17 21:28:25 <roh> re
Jan 17 22:19:45 <EqUaTe> hrm.. should sysupgrade work when changing archs? ie brcm47xx to brcm-2.4
Jan 17 22:20:31 <EqUaTe> (or vice versa)
Jan 17 22:27:24 <KanjiMonster> I wouldn't count on it
Jan 17 22:27:45 <KanjiMonster> I never tried, though
Jan 17 22:28:43 <EqUaTe> hairy muff
Jan 17 22:35:15 <philipp64|laptop> not sure what that has to do with anything.
Jan 17 22:36:58 <EqUaTe> philipp64|laptop: rhyme it.
Jan 17 22:37:56 <philipp64|laptop> scary stuff?
Jan 17 22:38:19 <EqUaTe> fair enough
Jan 17 22:39:18 <philipp64|laptop> and this is why I wasn't born Cockney.
Jan 17 22:40:44 <EqUaTe>  lol
Jan 17 22:40:47 <EqUaTe> nor was i
Jan 17 22:41:02 <EqUaTe> the more family-friendly version is fairy fluff
Jan 17 23:28:12 <stuffa> does any one know what function the broadcom "ctf" module performs
Jan 18 01:50:29 <neutronscott> clear
Jan 18 01:50:37 <neutronscott> oops :)
Jan 18 02:41:19 <builder> build #62 of gemini is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/62
**** ENDING LOGGING AT Tue Jan 18 02:59:57 2011