**** BEGIN LOGGING AT Mon Feb 15 02:59:57 2010 Feb 15 11:37:56 eno: at some packages file '.build' will removed on cleaning and on other packages not. is this necessary? than i add it always i note this missing line. Feb 15 11:38:16 also some packages have no .PHONY Feb 15 11:47:28 i add my unstage-proposal to zlib.mk / template.mk / template-cvs.mk. i hope you look at this and inform me about your mind. **** ENDING LOGGING AT Mon Feb 15 12:02:31 2010 **** BEGIN LOGGING AT Mon Feb 15 12:02:51 2010 Feb 15 16:47:31 jomaster: not all packages support "make uninstall" Feb 15 16:48:30 probably half of them don't Feb 15 16:49:30 that's much more than i thought Feb 15 16:50:20 but we have to test all package before commiting. Feb 15 16:50:30 i don't think we're at a phase to add -unstage to template.mk or template-cvs.mk yet Feb 15 16:50:55 ok. feel free to revert it Feb 15 16:51:15 it would just confuse new developers Feb 15 16:51:39 you are right Feb 15 16:52:00 maybe you can experiment on the packages that absolutely require -unstage Feb 15 16:52:09 such as mysql and mysql5 Feb 15 16:53:32 i rarely use the -clean target Feb 15 16:53:48 it's not used in official build either Feb 15 16:53:53 rssh.mk add "--with-cvs=/opt/bin/cvs" but don't depends on cvs or suggest it Feb 15 16:54:29 but if it will used removing '.build' is important? Feb 15 16:55:09 official build just uses scripts/optware-autoclean.pl and invokes -ipk Feb 15 16:55:25 i'd say if we remove -clean, nobody will notice Feb 15 16:55:50 so -clean is not important at all Feb 15 16:56:18 ok Feb 15 16:57:05 template-cvs.mk use "cvs" but should be better "$(CVS)", isn't it? Feb 15 16:57:08 you're right about rssh, please correct it Feb 15 16:57:33 probably suggest it Feb 15 16:58:23 it was implied that cvs in PATH Feb 15 16:58:37 in that case cvs or CVS makes no difference Feb 15 16:59:07 only in the context of using host tool, we need $(CVS) with full path Feb 15 16:59:20 but than defining $(CVS) at makefile doesn't make sense Feb 15 16:59:52 ok, only want to ask about a hidden reason. Feb 15 16:59:59 what do you mean? Feb 15 17:00:07 03jomaster * r11232 10optware/trunk/make/rssh.mk: rssh: add missing cvs suggesting Feb 15 17:00:46 oh i c Feb 15 17:01:01 there is a "CVS=cvs" line in Makefile Feb 15 17:01:02 nothing important. my english seems to bad for you :-D Feb 15 17:01:27 that predates my involvement with optware Feb 15 17:02:49 i will add $(CVS) to template-cvs.mk with my first host-tool-commit. Feb 15 17:03:57 so you're CVS as the first host tool example? Feb 15 17:05:01 yes, it is pretty easy. ;-) Feb 15 17:05:36 i'd hate to have to build svn as host-tool though Feb 15 17:05:47 futhermore, checking standard-tools and abort with an error-msg if one doesn't exist Feb 15 17:05:58 this would be my second tool :-D Feb 15 17:06:26 I think I have a different opinion on this Feb 15 17:07:10 cvs or subversion, these are fundamental development tools that all host build machine supports Feb 15 17:07:27 they're not giving us any trouble, why fix it? Feb 15 17:07:49 by using our own build, we might introduce problems Feb 15 17:08:12 how about working on something that DOES give us trouble? Feb 15 17:08:26 like autoconf? Feb 15 17:09:33 we need (maybe incorrectly) a specific version Feb 15 17:10:32 do you know how many dependencies subversion has (recursively)? Feb 15 17:11:12 I doubt we will ever do a better job than debian developers given the current resource Feb 15 17:11:33 in theory, everything can be built from scratch Feb 15 17:11:58 we have to work on things that matter Feb 15 17:13:18 you are right. but i think it isn't finished, if the build works without an error on the build-server Feb 15 17:14:55 on native build we should test for all tools at least. Feb 15 17:15:36 no, even for native build, we have cvs/svn included in optware-devel Feb 15 17:15:52 so we don't need to rebuild it Feb 15 17:16:15 neither cvs or svn is giving us ANY trouble at all Feb 15 17:16:34 so these are not priority Feb 15 17:17:04 i don't give a *** about theoretical perfection Feb 15 17:17:25 :-D Feb 15 17:18:04 i leave it out and go directly to aclocal... Feb 15 17:18:14 no cvs-commit Feb 15 17:18:22 thank you for understanding Feb 15 17:19:22 what about $(CVS) Feb 15 17:19:55 search all the .mk files, if it's not used, feel free to remove it Feb 15 17:20:14 but again, no rush (since nothing would be broken by it) Feb 15 17:26:42 03bzhou * r11233 10optware/trunk/make/ (template-cvs.mk template.mk): reverted template{,-cvs}.mk -unstage change, not to confuse new developers Feb 15 17:28:37 $(CVS) is used. Feb 15 20:40:21 03jomaster * r11234 10optware/trunk/Makefile: Makefile: add host-tool-stage for aclocal-1.9 / automake-1.9 if necessary Feb 15 20:41:36 03jomaster * r11235 10optware/trunk/make/ (autoconf.mk automake19.mk libtool.mk m4.mk): automake19 / autoconf / m4 / libtool: add host-tool-stage for aclocal-1.9 / automake-1.9 if necessary Feb 15 20:42:41 03jomaster * r11236 10optware/trunk/make/ipkg-opt.mk: ipkg-opt: use aclocal-1.9, automake-1.9 host-tool if necessary Feb 15 20:43:17 eno: what do you think about this? example is ipkg-opt. Feb 15 20:44:06 do we append host-staging-bin to PATH instead of calling $(ACLOCAL19)? Feb 15 21:47:59 jomaster: your change does not work on machine with aclocal-1.9/automake-1.9 Feb 15 21:48:36 if we can avoid conditionals, we should Feb 15 21:48:54 especially $(SHELL), these are expensive Feb 15 21:51:03 your change could send optware build into infinite loop Feb 15 22:02:01 * ka6sox shudders Feb 15 22:04:22 03bzhou * r11237 10optware/trunk/ (Makefile make/ipkg-opt.mk): correction on HOST_TOOL change Feb 15 22:10:18 its working! w00t Feb 15 22:10:35 i am so stupid. forget to test with automake-1.9 again Feb 15 22:11:15 ka6sox: thank you for fixing CIA and svn Feb 15 22:11:50 jomaster: it's alright, I'm testing the host_tool case on another build machine Feb 15 22:12:13 the change overall looks good Feb 15 22:12:44 little typos on automake Feb 15 22:13:54 03jomaster * r11238 10optware/trunk/Makefile: makefile: correction on HOST_TOOL_AUTOMAKE19_STAGE Feb 15 22:15:08 what about appending $PATH versus $(AUTOMAKE19)? Feb 15 22:15:45 it's late here. changing packages with aclocal-1.9 tomorrow. Feb 15 22:16:25 yeah, let's sleep on it Feb 15 22:18:18 eno, that would be rwhitby who did the fix. Feb 15 22:19:01 great Feb 15 22:19:52 * eno is wondering what's so special about aclocal-1.9 and automake-1.9 that we have to use this 1.9 particular version Feb 15 22:21:43 that was not my idea, really ;-) Feb 15 22:22:58 i read on automake-page that the versions aren't compatible in all cases. so sometimes a special version is required. Feb 15 22:23:21 but we can test the pages, working with current automake. Feb 15 22:25:24 i bet 90% of the places we don't need to use specific version Feb 15 22:25:40 just tested with ipkg-opt, and it builds fine Feb 15 22:26:21 but not always. i remember that i test a build for some months which don't work with current automake. Feb 15 22:26:51 (of course not ipkg-opt) Feb 15 22:28:27 to using $(shell is the idea of an experience-less non computer-scientist. seeing a better way makes me happy. Feb 15 22:29:22 (reference to me) Feb 15 22:30:42 about 50 packages using aclocal-1.9 Feb 15 22:31:07 good night. su Feb 15 22:33:27 night jomaster Feb 15 22:40:36 03bzhou * r11239 10optware/trunk/make/ipkg-opt.mk: ipkg-opt: use autoreconf, avoid specific version of aclocal/automake Feb 16 00:10:02 03bzhou * r11240 10optware/trunk/platforms/toolchain-cs08q1armel.mk: toolchain-cs08q1armel: set GNU_TARGET_NAME for both cross and native Feb 16 00:12:00 03bzhou * r11241 10optware/trunk/ (make/pkgconfig.mk sources/pkgconfig/configure.patch): pkgconfig: removed dependencies on automake-1.9 (specific version), now builds natively as well Feb 16 00:14:04 eno: awesome removing dependencies on automake-1.9 Feb 16 00:32:41 03bzhou * r11242 10optware/trunk/make/trickle.mk: trickle: removed dep on automake-1.9 specific version Feb 16 00:32:42 03bzhou * r11243 10optware/trunk/make/bip.mk: bip: rm some dead comment with ref to automake-1.9 Feb 16 00:32:44 03bzhou * r11244 10optware/trunk/make/ (upslug.mk upslug2.mk): upslug2: removed dep on automake-1.9 specific version Feb 16 00:36:52 rwhitby: thx for the CIA/svn fix Feb 16 00:37:25 eno: I didn't do anything. Feb 16 00:39:11 there was some time that CIA exited, and svn commit time out Feb 16 00:39:24 anyway, it's working again Feb 16 00:42:54 03bzhou * r11245 10optware/trunk/make/transmission.mk: transmission: removed some dead comment with ref to automake-1.9 Feb 16 00:50:12 CIA has been down for the last few days (everywhere) Feb 16 00:50:32 Reedy, I was reading that. Feb 16 00:50:48 The site was 404'ing, and i know the bots weren't about in other channels... Feb 16 00:50:54 Nothing in their blog though Feb 16 00:51:05 ya, it was causing problems with git-svn here. Feb 16 01:16:58 Reedy: thx for the info Feb 16 01:17:31 svn server should have some default timeout on post-commit-hook Feb 16 01:20:11 Indeed Feb 16 01:34:08 03bzhou * r11246 10optware/trunk/make/hello.mk: hello: 2.3 -> 2.5 Feb 16 01:39:25 03bzhou * r11247 10optware/trunk/make/libtasn1.mk: libtasn1: 2.1 -> 2.4 **** ENDING LOGGING AT Tue Feb 16 02:59:57 2010