**** BEGIN LOGGING AT Sun Jul 31 02:59:57 2011 Jul 31 09:46:24 build #42 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/42 Jul 31 10:55:40 if cshore or nico appear, or if someone else wants to look at it, please poke them with this.. https://dev.openwrt.org/ticket/9857 Jul 31 10:55:48 not a massive issue really. Jul 31 10:59:39 EqUaTe: "Remember to report logs between {{{ and }}}" ;p Jul 31 10:59:49 ahh Jul 31 10:59:53 * EqUaTe whistles Jul 31 11:00:08 i'd edit it, but there doesn't appear to be that option Jul 31 11:00:26 but i see you just did that Jul 31 11:03:40 thanks KM. Jul 31 11:05:02 i only mentioned it as it was the only package to fail to build with ccache enabled so far. Jul 31 11:39:24 hmm where must i look for the reason that enable "-Werror" in packages like ubus and collectd something thats new to me ? Jul 31 11:39:44 just happends in those 2 packages using trunk r27840 Jul 31 11:40:52 right now do apply patches fixing it but there must be a other reason Jul 31 11:44:25 nut 100% sure if i can blame cmake for this Jul 31 11:49:08 testrun glibc 2.13 + gcc 4.6.1 @ R27840, build error free. Jul 31 11:50:18 the reason is that the authors decided to do so to force the code to be as clean as possible Jul 31 11:50:39 one downside of -Werror in shipped code is that it may fail with newer gcc version due to stricter checks Jul 31 11:50:52 like the recently "defined but unused" warnings Jul 31 11:50:58 *recently added Jul 31 11:52:47 jup Jul 31 11:53:18 set but not used [-Werror=unused-but-set-variable] Jul 31 11:53:33 -I/mnt/backup1/willie/openwrt/r27840/trunk/staging_dir/target-i386_glibc-2.13/usr/include -DNDEBUG -Os -Wall -Werror --std=gnu99 -g3 -o CMakeFiles/ubus-example.dir/ubus-example.c.o Jul 31 11:54:04 removed the Werror Cflags from the upstream shipped config files by adding patches. Jul 31 11:54:22 now look if everything still works and boot :) Jul 31 11:54:41 make clean; make runs now at one shot no error.. Jul 31 11:55:06 and 8M total packages size.. no need for +300M images :) Jul 31 11:55:30 dunno if this is with or without stripping (including gcc 4.6.1 later) Jul 31 11:56:00 CONFIG_NO_STRIP=y Jul 31 11:56:28 package dir content looks like this http://pastebin.com/tjdHHw3D Jul 31 11:57:01 dunno if 8M or 16M was the size limit :) Jul 31 11:58:10 jow_laptop: also i do think about upgrade this x2 7750 for a phenom ii x6 1090t will speedup these builds a lot. Jul 31 12:06:21 jow * r27843 /trunk/package/dropbear/ (3 files in 3 dirs): Jul 31 12:06:21 [package] dropbear: Jul 31 12:06:21 - split port argument at the rightmost colon, allows binding to specific IPv6 addresses Jul 31 12:06:21 - don't use uci ipaddr var but resolve ifname and get addresses from it (#9853) Jul 31 12:06:49 jow * r27844 /branches/backfire/package/dropbear/ (3 files in 3 dirs): [backfire] merge r27843 Jul 31 12:46:27 jogo * r27845 /packages/net/madwimax/ (Makefile patches/ patches/001-fix_detection_on_be.patch): Jul 31 12:46:27 [packages] madwimax: fix detection for big endian systems Jul 31 12:46:27 closes #7510. Jul 31 12:52:52 jow * r27846 /branches/packages_10.03.1/net/madwimax/ (Makefile patches/): [packages_10.03.1] merge r27845 Jul 31 13:00:49 jow_laptop: thanks Jul 31 13:01:33 hmm where is $(HOST_SUBDIR) pointing to by default in target/$package/Makefikle.in ? Jul 31 13:01:54 Makefile.in (damn keys) Jul 31 13:03:37 have been looking in the automake manuals can't find it there. Jul 31 13:08:39 jow_laptop: have have you disabled gcc depending on gmp/mpfr/mpc in the toolchain ? Jul 31 13:09:22 since i do run into a problem that is more a autoconf/automake problem here.. gmp.h is availible and it says it is not.. Jul 31 13:09:51 i hate those problems when have no clue where the used variables are pointing to. Jul 31 13:11:15 or someone else.. Jul 31 13:12:07 ? Jul 31 13:12:15 what about posting some logs Jul 31 13:12:24 I have no idea what you mean Jul 31 13:12:26 hmm Jul 31 13:12:31 moment cleaning my desk here.. Jul 31 13:12:38 *rant* damn coffee Jul 31 13:12:57 config.log is enough i hope ? Jul 31 13:13:12 since thats unrealated to my question :s Jul 31 13:14:30 jow_laptop: wat i asked if "they" used $(HOST_SUBDIR) in a Makefile.in where is that pointing to or need that var to be defined in the same automake include file ? Jul 31 13:15:08 i can post logs but then you can fix my gcc problem also.. o try to understand why it can't find something that is there and no idea how it is checking for the existing files in the first place. Jul 31 13:15:24 also when i say build gcc in target image you will ignore me right :s Jul 31 13:16:08 if configure says it cannot find a header despite it being there it is usually because it couldn't compile the corresponding conftest.c file Jul 31 13:16:19 config.log will then reveal why Jul 31 13:16:34 no idea about HOST_SUBDIR, seems to be a binutils or gcc invention Jul 31 13:16:48 never seen it in the wild Jul 31 13:17:13 cleaning desk moment, config.log is here http://pastebin.com/E1anz4pQ Jul 31 13:17:53 hmm without knowing where that points to then i dunno where it is looking for subdir gmp/gmp.h instaid of include/gmp.h Jul 31 13:18:13 these issues are to simple to whaste half days on seeking for a defined variable in autoconf scripts :S Jul 31 13:18:51 "Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify Jul 31 13:18:52 their locations." Jul 31 13:19:18 -> CONFIGURE_ARGS += --with-mpfr=$(STAGING_DIR)/usr/include ... Jul 31 13:19:47 jow_laptop: can you have a look at http://pastebin.com/bpFsmCCa , I'm not sure why it fails. Is it because of #define b64_ntop __b64_ntop in resolv.h? Jul 31 13:22:01 jow_laptop: and that must be added to Makefile.in ? Jul 31 13:22:07 loswillios: more likely because tty.c does not #include Jul 31 13:22:11 WillieNL: no Jul 31 13:22:18 WillieNL: to the calling makefile Jul 31 13:22:20 since i do think the test part fails by looking wrong. Jul 31 13:22:31 makefiles are autogenerated by makefile.in or .am Jul 31 13:22:40 well it uses a cross compiler to search for mpfr/gmp etc. Jul 31 13:22:45 it make no sense edit the makefile it self directly when depending on autotools Jul 31 13:22:52 the cross compiler searches only in its toolchain dir and in staging_dir Jul 31 13:22:57 guess you will know that better then i do Jul 31 13:23:01 jow_laptop: it does, see at the end of the pastebin Jul 31 13:23:04 yes and it have it there :s Jul 31 13:23:05 it will never attempt to use your system mpfr Jul 31 13:23:31 loswillios: then the declaration is apparently not reachable, see if it is protected by #ifdefs Jul 31 13:23:34 thats why i say it is there but autotools are blind Jul 31 13:23:43 WillieNL: so where is mpfr.h ? Jul 31 13:24:09 it will check for mpfr afther this lib :s Jul 31 13:24:19 then where is gmp.h ? Jul 31 13:24:21 so that is next error Jul 31 13:24:30 gmp is in /mnt/backup1/willie/openwrt/r27840/trunk/staging_dir/host/lib/ Jul 31 13:24:37 host != target Jul 31 13:25:15 you will need a gmp / mpfr etc. package compiled for the target Jul 31 13:25:29 hmm /mnt/backup1/willie/openwrt/r27840/trunk/staging_dir/target-i386_glibc-2.13/include/ is empty indeed.. Jul 31 13:25:34 which installs its headers into staging_dir/target-*/usr/include with InstallDev Jul 31 13:25:36 and i wonder why is it like that Jul 31 13:25:49 since i do have selected and compiled those packages before gcc Jul 31 13:26:10 jow_laptop: hm, yes, with "if 0". What's that? Jul 31 13:26:26 hmm Jul 31 13:26:52 aha Jul 31 13:27:00 gmp.h in /mnt/backup1/willie/openwrt/r27840/trunk/staging_dir/target-i386_glibc-2.13/usr/include/ Jul 31 13:27:15 but no mpfr (checking again) Jul 31 13:28:03 hmm weird was that one of those packages i was not able to find in the package lists.. Jul 31 13:28:33 jow_laptop: gmp depends on mpfr and without mpfr it will say no gmp found ? Jul 31 13:28:46 yes, because at the time the gcc package was made there was no need for mpfr Jul 31 13:28:58 no gcc is lightyears ahead and the pacakge was never updated Jul 31 13:29:11 therfore there was also never an mpfr packages Jul 31 13:29:20 you'll run into much more issues like that down the road Jul 31 13:29:59 can i just copy the host mpfr stuff to staging for now ? Jul 31 13:30:14 as quick fix. Jul 31 13:30:21 host i486 target i486 anyway Jul 31 13:30:25 no Jul 31 13:30:27 debian == i486 Jul 31 13:30:30 probably not Jul 31 13:30:38 well you can try Jul 31 13:30:42 it seems if 0 is used to save space? Jul 31 13:30:54 loswillios: ?? Jul 31 13:31:08 loswillios: you mean #if 0 ? Jul 31 13:31:30 loswillios: copy the full resolv.h header somewhere Jul 31 13:32:10 jow_laptop: http://git.uclibc.org/uClibc/plain/include/resolv.h Jul 31 13:32:43 look for b64_ntop Jul 31 13:32:55 loswillios: they usually do that if they do not actually support the corresponding api Jul 31 13:33:27 or if there are no users for it Jul 31 13:33:56 either convince your failing program to not use b64_ntop related functionality as it will most likely not work with uclibc Jul 31 13:34:16 or if it is indeed only needing the conversion function, you can use this as drop-in replacement: Jul 31 13:35:25 view-source:ftp://ftp.irisa.fr/pub/OpenBSD/src/usr.sbin/nsd/compat/b64_ntop.c Jul 31 13:35:35 oops ftp://ftp.irisa.fr/pub/OpenBSD/src/usr.sbin/nsd/compat/b64_ntop.c Jul 31 13:37:32 ok, thanks Jul 31 13:39:05 aha Jul 31 13:39:29 jow_laptop: is these point to staging_dir/host instaid of the target it will fail Jul 31 13:39:30 --with-gmp=/mnt/backup1/willie/openwrt/r27840/trunk/staging_dir/host --with-mpfr=/mnt/backup1/willie/openwrt/r27840/trunk/staging_dir/host Jul 31 13:45:07 jow_laptop: thanks Jul 31 13:49:42 hmm still the same :s Jul 31 14:14:54 jow_laptop: copy host/lib/mp* and host/include/mp* to staging/usr/lib and staging/usr/include and add 3 lines to the makefile. http://pastebin.com/y6sbDxfP Jul 31 14:15:12 configure is not failing it is compiling right now.. will se where it fails next :D Jul 31 14:20:52 hmm pretty neat bootstrap and compile in a cross compile env :p Jul 31 14:26:00 jow_laptop: hmm gcc build complete :) Jul 31 14:26:10 it's included in the target vbox image :p Jul 31 14:26:22 time to check rrdtool's automake typo's ;-) Jul 31 14:26:38 anyone seen issues getting asterisk 1.8.x to build? it's failing with the chan_mgcp part for me. Jul 31 14:26:58 since i do not want -march=x86_64 on perl shared libs :) Jul 31 14:27:31 <_trine> EqUaTe, I have in the past built asterisk Jul 31 14:27:47 <_trine> but not for a month or so Jul 31 14:27:54 1.8 ? Jul 31 14:27:57 <_trine> yes Jul 31 14:28:15 <_trine> Iuse it on my dockstar Jul 31 14:28:46 i get: install: cannot stat `/home/equate/source/openwrt/trunk/build_dir/target-mips_r2_uClibc-0.9.32/asterisk-1.8.4.4/ipkg-install/usr/lib/asterisk/modules/chan_mgcp.so': No such file or directory Jul 31 14:28:57 so it clearly isn't building that module Jul 31 14:29:06 or failed at that mod Jul 31 14:29:06 but i can't see anything that says why Jul 31 14:30:30 WillieNL: can't say that until i can find /why/ it isn't building it. Jul 31 14:31:43 EqUaTe: dunno if i can help mutch, but by checking if the module is there (posible patch typo), and look the build logs if you have those enabled. Jul 31 14:32:04 also you get that error during the ipkg install part or building the ipkg file ? Jul 31 14:32:28 i believe this is building the package Jul 31 14:32:44 seeing as the next line after that is: make[2]: *** [/home/equate/source/openwrt/trunk/bin/ar71xx/packages/asterisk18-chan-mgcp_1.8.4.4-1_ar71xx.ipk] Error 1 Jul 31 14:34:05 the patch that added mgcp is 5 months old, so i'm fairly sure it isn't a patch issue, unless someone broke some other part of the build :) Jul 31 14:36:40 where would i find the build logs, and where would i turn them on if they're not? :) Jul 31 14:36:59 nm, found it Jul 31 14:37:17 make package/asterisk-1.8.x/{clean,compile} V=99 2>&1 1>error.log Jul 31 14:38:52 <_trine> what does chan_mgcp do Jul 31 14:39:03 <_trine> I didnt have that slected Jul 31 14:39:12 <_trine> in my make menuconfig Jul 31 14:39:20 jow_laptop: that wouldn't give me anything that i didn't see in my terminal Jul 31 14:39:30 EqUaTe: a log would neither Jul 31 14:39:52 pretty much what i thought Jul 31 14:39:55 I assumed it just failed to link chan_* and skipped over it Jul 31 14:40:02 there's nowt of use, it looks like it doesn't even try to build it Jul 31 14:40:04 like Yate does when a module fails to compile Jul 31 14:40:16 the first mention of mgcp in the log/terminal is when it installs the config sample Jul 31 14:40:35 then check the config.log in build_dir/target-*/asterisk-*/ Jul 31 14:40:48 <_trine> why do you need chan_mgcp Jul 31 14:41:17 i don't, i'm trying to build as per the config in the ar71xx dir on the website. Jul 31 14:41:36 it's useful from the perspective of finding things that don't work Jul 31 14:41:40 <_trine> I dont think you would need it Jul 31 14:43:06 <_trine> I am trying a build again with out it Jul 31 14:43:16 i'm fairly sure it'll build w/o it Jul 31 14:43:19 <_trine> in 2.6.39.2 kernel Jul 31 14:43:26 but if it doesn't build, then i'd like to be able to report that :) Jul 31 14:43:34 ideally, with some answer as to why Jul 31 14:43:37 <_trine> who too :) Jul 31 14:43:56 asterisk is orphaned again? Jul 31 14:44:50 <_trine> dunno Jul 31 14:45:05 <_trine> did it ever have a real mum and dad Jul 31 14:45:10 good question Jul 31 14:45:17 i'm not sure this package was added properly Jul 31 14:45:21 no, afair Zandbelt is caring for it after everything got consolidated into 1.8.x Jul 31 14:46:08 I can also confirm that I was able to compile it on all architectures during the rc5 release builds Jul 31 14:46:40 so its not known to be broken either (in contrast to FS) Jul 31 14:47:02 jow_laptop: does the rc5 build include the mgcp package? Jul 31 14:47:22 yes Jul 31 14:47:29 hm Jul 31 14:47:33 interesting Jul 31 14:47:44 ven on brcm-2.4 Jul 31 14:47:46 *even Jul 31 15:10:27 Does anyone here know who should I contact to have the the quota of private message space on my OpenWRT Forum account increase? Jul 31 15:20:19 loswillios * r27847 /packages/utils/tmux/ (Makefile patches/ patches/010-backport-b64_ntop-fix.patch): [packages] tmux: update to 1.5 Jul 31 15:20:20 loswillios * r27848 /packages/utils/tmux/Makefile: [packages] tmux: change dependency to libevent2 Jul 31 16:01:41 any suggestions for where to look with this package? Jul 31 16:03:11 at config.log ? Jul 31 16:05:04 again no mention of mgcp in the config.log.. Jul 31 16:05:10 which i think is a little odd. Jul 31 16:11:59 looks like it is implicitely built by some generic make rule Jul 31 16:17:53 they scan for *.c and *.cc files within a specific dir and turn those into build targets Jul 31 16:18:31 so it should have attempted to build chan_mgcp.so in any case (if there is a chan_mgcp.c) Jul 31 16:20:52 there is Jul 31 16:27:22 any idea how i can try and replicate the build for just that module, so i can see why it's failing? Jul 31 16:28:10 hm Jul 31 16:28:17 no Jul 31 16:28:31 I would need to dig through the various makefile includes Jul 31 16:29:12 however you can try to poke around in Makefile.moddir_rules and dump the value of LOADABLE_MODS etc. Jul 31 16:30:41 ok Jul 31 16:33:43 i wonder if this has something to do with it: http://pastie.org/private/szw51gaocr12ko4nvtspxa Jul 31 16:34:52 wouldn't fail anything then? Jul 31 16:35:28 immediately after that is the asterisk ascii logo, and then stuff about it doing cross compilation Jul 31 16:36:39 crazy Jul 31 16:37:28 yeah Jul 31 16:37:34 going to find that bit in config.log Jul 31 16:41:24 <_trine> EqUaTe, I am trying a compile Jul 31 16:41:43 _trine: with mgcp enabled? Jul 31 16:41:49 <_trine> no Jul 31 16:41:57 ok Jul 31 16:42:08 <_trine> but did either you or Jow say it would be compiled anyway Jul 31 16:42:47 <_trine> I'll compile this up and add the other afterwards Jul 31 16:42:56 <_trine> if it compiles ok Jul 31 16:43:03 yes, but it won't fail to build the package if the package isn't enabled Jul 31 16:43:24 the failure is when building the package because the module doesn't build. but there's nothing with that that stops asterisk itself from building Jul 31 16:46:33 jow_laptop: interestingly, the 'checking whether the C compiler works...' string only appears in the logs once, and the result appears to be yes.. odd. Jul 31 16:58:44 ok, so it isn't trying to build it. i'm pretty certain now. Jul 31 16:58:48 now to see why not. Jul 31 17:10:27 build #65 of at91 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/65 Jul 31 17:33:03 build #63 of ubicom32 is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/63 Jul 31 17:44:06 moo Jul 31 17:45:00 I wonder what would happen if I installed portage on openwrt Jul 31 17:45:05 :G Jul 31 17:45:18 the universe implodes. Jul 31 17:45:19 you'd run out of space real quick Jul 31 17:45:33 I've got a 500GB external drive on it Jul 31 17:50:05 I almost bought a 3TB drive for it last night.. Jul 31 17:50:36 at the point where you run portage on openwrt there is no point in using it anymore Jul 31 17:50:49 instead of debian or gentoo or whatever Jul 31 17:51:31 I see.. Jul 31 17:52:22 sometimes people just use the kernel, like debwrt Jul 31 17:52:39 in case the hw in question is not supported upstream, like the rspro Jul 31 17:59:14 jogo * r27849 /trunk/package/kernel/modules/fs.mk: Jul 31 17:59:14 package/kernel: move kmod-fs-mbcache into fs-ext4 Jul 31 17:59:14 mbcache is only needed if xattr support is enabled, but this is only true Jul 31 17:59:14 for ext4 on 2.6.37+, so just bundle it with ext4 when needed. Jul 31 17:59:53 nbd * r27850 /trunk/tools/squashfs4/patches/160-expose_lzma_xz_options.patch: squashfs4: add missing include for freebsd (patch from #9842) Jul 31 17:59:58 nbd * r27851 /trunk/tools/squashfs4/patches/160-expose_lzma_xz_options.patch: squashfs4: fix a compile error on big-endian systems (patch from #9842) Jul 31 18:00:02 nbd * r27852 /trunk/tools/quilt/Makefile: quilt: make it possible to override the path to getopt (based on patch from #9842) Jul 31 18:04:23 nbd: thanks Jul 31 18:06:19 Chocky: again thanks for #9483 -> trunk r27840, target-i386, glibc-2.13, gcc-4.6.1 builds fine now. Jul 31 18:06:46 brb diner time here :( will fireup that image afther diner vbox it self fails right now no boot medium :s brb Jul 31 18:12:51 nbd * r27853 /trunk/target/linux/generic/ (8 files): kernel: enable inotify by default (#8055) Jul 31 18:31:22 :o Jul 31 18:31:22 * Chocky pokes ndb et al Jul 31 18:31:22 also, nbd Jul 31 18:32:17 * nbd looks around Jul 31 18:33:30 look way back in history for what I saw with swconfig Jul 31 18:33:30 if you haven't already Jul 31 18:34:36 did you get a backtrace? Jul 31 18:35:28 yes, but not much it in. It segfaults on the 2nd call to swlib_call in genlmsg_put Jul 31 18:35:57 I have an immediate need to make something work, so I did a rebuild with older compiler, testing right now. If that doesn't work, I'll have to roll back the arch changes. Jul 31 18:37:49 quite odd that it segfaults there Jul 31 18:38:04 sutre Jul 31 18:38:35 I'm pretty sure I never had a complete working system with new compiler, so let's see Jul 31 18:40:02 hm Jul 31 18:41:22 that confirms it Jul 31 18:41:45 definitely the compiler Jul 31 18:52:43 interesting Jul 31 18:53:13 which compiler are you building your eglibc stuff with? Jul 31 18:54:36 i use the default compiler Jul 31 18:55:42 I have dealt with so many systems/compilers, I have no idea what that is ;-) But I presume it's the other one, the Linaro compiler Jul 31 18:56:08 default one is the linaro one, yes Jul 31 18:58:21 oh yes. gdb depends on libexapt, but that's not a package dependency Jul 31 19:08:05 hmm ok my grub setup failed really odd stage1 and stage2 mismatch.. Jul 31 19:08:39 but my problem here is how can i rebuild/clean grub Jul 31 19:08:51 package/grub/clean is not removing the stage1 and stage2 file :( Jul 31 19:09:02 and dirclean is not an option right now Jul 31 19:09:52 aw Jul 31 19:10:03 ok, gonna try an eglibc build Jul 31 19:10:50 nbd: which version of eglibc? Jul 31 19:13:20 WillieNL: make package/grub/host/clean Jul 31 19:14:42 jow_laptop: thanks alot saved me 3 hours redo :) Jul 31 19:15:36 the grub stage file stuff used to cause problems in the past as well Jul 31 19:15:45 esp. on 64bit host systems Jul 31 19:16:09 <_trine> EqUaTe, it compiles for me Jul 31 19:16:49 jow_laptop: i have rebuild this build a few times to make everything working untill it did build at one shot incl all patches :) Jul 31 19:17:02 at last grub refused :p Jul 31 19:17:13 also gcc is included in the target ;-) Jul 31 19:17:19 * WillieNL won't giveup :p Jul 31 19:17:29 * Chocky pokes nbd Jul 31 19:18:31 * WillieNL 's last tested eglibc build was r27840/trunk/eglibc-2.13-r13055 Jul 31 19:20:56 hm Jul 31 19:21:08 worked segfault free in vbox :) Jul 31 19:21:12 2.13 it is then Jul 31 19:21:20 afther fixing permissions in /usr/lib Jul 31 19:21:54 not shure if i did something weird or triggered a part untested code :) Jul 31 19:21:58 shure/sure* Jul 31 19:22:20 the whole "build every ar71xx arch under the sun" still annoys me gretly Jul 31 19:22:24 greatly Jul 31 19:22:40 cos it ends up building images for stuff that I don't have, and for which the image would be too big. Jul 31 19:23:32 hmm why annoys ? openwrt project is going for small as posible with mutch as posible features. Jul 31 19:23:52 that's entirely beside the point Jul 31 19:24:14 the images I have include software I need for my project. I can't help if it that makes images for hardware I will never use too big Jul 31 19:24:45 like i do with rrdtool + cairo for my own personal use ? Jul 31 19:25:01 and it makes no sense to build them all anyway. it just eats many MB of space and takes longer to build Jul 31 19:25:07 tobig for embedded perfect for everything with atleast 64m storage Jul 31 19:25:07 I have no idea what you do there Jul 31 19:26:04 so, if, zomg! my image is 10MB, of course it's not going to fit on 8MB machines. but I'm not building for those. Jul 31 19:26:05 my goal is running a router + fancy ui and mutch more from ramdisk and look wat the results are and how far that can push limits Jul 31 19:26:24 Chocky: you building for wat arch if i may ask ? Jul 31 19:26:35 i think x86 like i do.. but not 100% sure Jul 31 19:26:36 G300NH Jul 31 19:26:54 I already said ar71xx above Jul 31 19:26:55 whats the problem? it emits a warning that the iamge is too big and skips over it Jul 31 19:27:02 its not like it fails the build or something Jul 31 19:27:03 jow: not in all cases. Jul 31 19:27:47 in fact, it does fail the build sometimes. And eats lots of space. And image builder fails if you don't hack it up Jul 31 19:28:02 then provide logs Jul 31 19:28:11 and configs to reproduce Jul 31 19:28:22 and attach them to a bug report Jul 31 19:28:27 sigh Jul 31 19:28:32 jow_laptop: hmm afther clean grub like you said and how i did will it overwrite build_dir/linux-x86_generic/e2fs_stage and build_dir/linux-x86_generic/stage* ? Jul 31 19:28:32 I'm trying to have a disucssion Jul 31 19:28:39 they where not cleaned. Jul 31 19:28:54 no, you're whining ;) Jul 31 19:29:00 jow: give it a break Jul 31 19:29:04 * Chocky tired of attitude here Jul 31 19:29:10 ? Jul 31 19:29:16 can we have a grown up discussion for once? Jul 31 19:29:43 yes, I'll do a bug report. but can we consider the issues first? Jul 31 19:30:13 never mind that I'm still waiting, waiting waiting for my glibc issues to be addressed. Jul 31 19:30:26 discussing would be "I think extra images should not be built if a specific device profile is selected, in particular I think its unintended to fail the build if a specific image exceeds the capacity. A log of the observed problem can be found at ..." Jul 31 19:30:31 All I get it commentary about how it's bloated/buggy, blah blah Jul 31 19:30:36 not "It annoys me greatly that foo does bar" Jul 31 19:31:32 also why do you pick an uclibc based distributation for a glibc project and then demand that people fix your issues? Jul 31 19:31:35 jow: you're looking for a certain solution that I don't agree with. Please don't try and frame my comments to date. I have more to say Jul 31 19:31:51 oh good grief, let's step back the accusations Jul 31 19:32:04 21:29 < Chocky> never mind that I'm still waiting, waiting waiting for my glibc issues to be addressed. Jul 31 19:32:27 *I* have fixed the issues. I've said on multiple occasions I will work with anyone to fix them. I've had offers from you, and others to put my patches in. Jul 31 19:33:00 when you start making personal commentary, it does downhill very rapidly. Chill already Jul 31 19:33:10 I'm not going to get into that. Jul 31 19:33:43 can we start over, please? Jul 31 19:35:05 sigh. Jul 31 19:36:30 jow_laptop: http://pastebin.com/SKf2h0mb Jul 31 19:37:00 so. Jul 31 19:37:26 even in the case where the ar71xx arch build doesn't fail, it still builds ~20 sub arch images. Which is time and space. Jul 31 19:37:50 jow_laptop: i'll rebuild this from scratch without later added stuff like hacky build-essentials included this is tomutch diffrent topics inside one task for me will try to do this one by one :( Jul 31 19:38:05 * WillieNL thinks that gcc 4.6.1 and grub triggers something fresh here.. Jul 31 19:38:15 stupid that i bump into this afther 16hr :9 Jul 31 19:38:45 Yes, it's possible to provide PROFILE=, and there's some hack you can make to the image builder Makefile. But it's a hack. Jul 31 19:39:23 it seems that this can also be triggered by other issues, such as a readonly target device Jul 31 19:39:24 Chocky: you do not have to build "all" image types when you need just one.. posible 3 are ok base image + packet variant for your platform. Jul 31 19:39:42 willie: please tell that to the ar71xx build system Jul 31 19:39:43 jow_laptop: hmm this grub prob ? Jul 31 19:39:53 WillieNL: yes Jul 31 19:39:58 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html Jul 31 19:40:03 WillieNL: there is no point in cleaning everything here Jul 31 19:40:23 jow_laptop: hmm the partitions are not write protected .. Jul 31 19:40:29 building on a single hdd.. Jul 31 19:40:30 it was an example Jul 31 19:40:34 no fancy flash raid :) Jul 31 19:40:46 willie: in general, your statement is wrong. I do have work arounds to at least mitigate some of it, but it's still bad. Jul 31 19:40:50 but i do understand the hint Jul 31 19:41:33 Chocky: hmm not sure if i do understand your point but openwrt is not a ready to use product like a dlink router out of da box. even if it works way better in 9 out of 10 times when working Jul 31 19:41:56 willienl: if you are unsure of what I'm on about, I'd much prefer you ask rather than guess. Jul 31 19:42:18 WillieNL: you didn't upgrade grub by any chance? Jul 31 19:42:33 My job is to *make* a real product out of OpenWrt. For a specific hardware for sure. I can't live in OSS fantasy land forever Jul 31 19:43:03 Chocky: i don't judge, i just give a hint posible idea of wat can go wrong like i have been building the full blown all packages stuff faster then a buildbot for no reason.. Jul 31 19:43:05 I happen to be very good at making OSS stuff work as real products, but I need a tiny bit of help from devs. ndb has certainly helped to date. Jul 31 19:43:21 jow_laptop: nope thats why i'm curious about doing a dirclean/distclean Jul 31 19:43:21 nbd, too Jul 31 19:44:04 Chocky: also a lot questions we and a lot others ask in here are already be asked and fixed in the mailing lists.. Jul 31 19:44:25 Chocky: even i do get ignored in those cased for not looking in a mailing list :) Jul 31 19:44:37 willie: that's not my experience. but then, I'm not a regular user Jul 31 19:45:05 cased/cases* and not saying this as a bad thing but as a point where in the end we are 2 out of many asking the same stuff. Jul 31 19:45:09 Yes, I'm doing something a little bit unusual. story of my life with OSS. That's fine, and I'll deal with the consequences. but it does mean I often find shortcomings with systems. Jul 31 19:46:05 The point is, the image generation with ar71xx is not very satisfactory. But I don't know what the rationale behind it is, if any. Jul 31 19:46:08 jow_laptop: hmm posible i messedup with gcc/glibc and rebuilding afther building the toolchain.. guess best i can do now is redo the same thing again in a other directory and look where i failed.. Jul 31 19:47:00 since i do find this out afther including build-essentials and not before patching/hacking. Jul 31 19:48:28 as for the mailing list, I subscribe a few days ago, and am waiting for confirmation/whatever. so, that's a no-go at present Jul 31 19:48:37 subscribe ? Jul 31 19:48:44 and for bug reports, my experience of them being responded to is rather poor. Jul 31 19:48:48 hmm i google true mailing lists.. Jul 31 19:49:02 swalker * r27854 /packages/utils/tmux/Makefile: [packages] tmux: correct the 1.5 platform renaming Jul 31 19:49:04 um. Jul 31 19:49:18 mosthly i love google for seeking at redhat+debian+gentoo+openwrt mailing lists Jul 31 19:49:23 I don't know what "true" lists are, and I can google all I want, but I need to post directly Jul 31 19:49:42 since I assume that's where most of the dev discussion takes place, apart from here Jul 31 19:50:27 for my old work i was only fixing bugtrack tickets and nothing else to keep everything clean and clear. Jul 31 19:50:39 can we stick to the matter of openwrt, please? Jul 31 19:50:40 else it will become as fuzzy as my mind is. Jul 31 19:50:57 :D Jul 31 19:51:10 bbl anyway.. back to console. Jul 31 19:51:17 jow_laptop also thanks Jul 31 19:53:19 jow: do you agree/disagree with any of this? Jul 31 19:53:35 or do I have to threaten to give sloppy kisses again Jul 31 20:17:26 https://dev.openwrt.org/ticket/9861 Jul 31 20:21:50 build #40 of octeon is complete: Exception [exception interrupted] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/40 Jul 31 20:21:50 build #67 of brcm63xx is complete: Exception [exception interrupted] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/67 Jul 31 20:21:52 build #65 of s3c24xx is complete: Exception [exception interrupted] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/65 Jul 31 20:21:54 build #63 of brcm47xx is complete: Exception [exception interrupted] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/63 Jul 31 20:25:33 jow_laptop: seeking true my logs and found the reason why my grub is borked. it is my own error by running make -j4 for the host tools and toolchain by hoping to speedup started multithreading while deps where not ready yet . Jul 31 20:25:48 ok Jul 31 20:25:54 hoping/hope Jul 31 20:26:43 i really need a cpu upgrade and some money for 4G ddr2 ram modules :) Jul 31 20:26:59 Or speed up the OpenWrt build Jul 31 20:27:21 x2 7750 -> phenon II x6, + 4G->16G ram make 10G ramdisk availible -> result lightspeed :) Jul 31 20:27:44 yes, let's throw more power at the problem, instead of improving the software. sigh. Jul 31 20:28:10 Chocky: ever build gentoo from scratch on a pentium 3 ? Jul 31 20:28:17 no, because it's stupid Jul 31 20:28:25 and I don't care about Gentoo Jul 31 20:28:27 *sigh* man i'm already happy with this nowdays. Jul 31 20:28:43 compared to the clusterfuck from distcc nodes and untested code. Jul 31 20:29:32 unfortunately, much of the world has been condition by Intel etc, etc to think that it's just a case of throwing faster hardware at problems. But that usually only gives small linear improvements Jul 31 20:29:45 Chocky: how do you wanna speedup openwrt it sounds weird to me when thinking about the idea behind openwrt. Jul 31 20:29:47 gentoo always reminds me of https://bugs.gentoo.org/show_bug.cgi?id=35890 Jul 31 20:30:22 Chocky: rerun a test in 40 minutes or 3 hours do make a diff in fixing 15 problems a day or 2 problems. Jul 31 20:30:32 willie: we spend the last 10 minutes discuss just one aspect of this. Jul 31 20:31:02 jup while my tasks continue in the background else i was not chatting right now. Jul 31 20:31:08 willie: your comment is completely without context to me. Jul 31 20:31:47 los: quite. Strains of "Endless September" Jul 31 20:32:28 Chocky: hmm i do not really know for sure if i do understand you "today" since the glibc ticket helped me and a lot others verry well and now you sound like not like openwrt for some reason.. Jul 31 20:32:35 loswillios: hmm nice joke :p Jul 31 20:32:56 willie: I must insist you stop making assumptions about me. You are just commenting randomly about stuff. Ask, don't assume. Jul 31 20:33:50 hmm ok then i say nothing at all if saying "i think posible" == assuming to you .. Jul 31 20:33:59 mhei_: ping Jul 31 20:33:59