Re: [PATCH] GNU/kOpenSolaris port
On Mon, Jan 19, 2009 at 11:24:07PM +0100, Ralf Wildenhues wrote: * Robert Millan wrote on Mon, Jan 19, 2009 at 11:45:24AM CET: kopensolaris-gnu was accepted in GNU config. I adjusted my patch to use that, see attachment. Thanks for carrying this through, pushed as below. I've added you to THANKS. Thank you Ralf! Btw, do you expect a new release soon? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all.
Re: [PATCH] GNU/kOpenSolaris port
Hi,
kopensolaris-gnu was accepted in GNU config. I adjusted my patch to use
that, see attachment.
Can it be included now?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
2009-01-19 Robert Millan r...@aybabtu.com
* libltdl/m4/libtool.m4: Recognize GNU/kOpenSolaris
(kopensolaris*-gnu).
* libltdl/m4/ltdl.m4: Likewise.
index b7b566d..c8dfa77 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2380,7 +2380,7 @@ linux*oldld* | linux*aout* | linux*coff*)
;;
# This must be Linux ELF.
-linux* | k*bsd*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu)
version_type=linux
need_lib_prefix=no
need_version=no
@@ -3014,7 +3014,7 @@ irix5* | irix6* | nonstopux*)
;;
# This must be Linux ELF.
-linux* | k*bsd*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu)
lt_cv_deplibs_check_method=pass_all
;;
@@ -3635,7 +3635,7 @@ m4_if([$1], [CXX], [
;;
esac
;;
- linux* | k*bsd*-gnu)
+ linux* | k*bsd*-gnu | kopensolaris*-gnu)
case $cc_basename in
KCC*)
# KAI C++ Compiler
@@ -3919,7 +3919,7 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
-linux* | k*bsd*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu)
case $cc_basename in
# old Intel for x86_64 which still supported -KPIC.
ecc*)
@@ -4300,7 +4300,7 @@ _LT_EOF
_LT_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols $output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
;;
-gnu* | linux* | tpf* | k*bsd*-gnu)
+gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
tmp_diet=no
if test $host_os = linux-dietlibc; then
case $cc_basename in
@@ -5792,7 +5792,7 @@ if test $_lt_caught_CXX_error != yes; then
_LT_TAGVAR(inherit_rpath, $1)=yes
;;
- linux* | k*bsd*-gnu)
+ linux* | k*bsd*-gnu | kopensolaris*-gnu)
case $cc_basename in
KCC*)
# Kuck and Associates, Inc. (KAI) C++ Compiler
index a2b1a4e..2dbefed 100644
--- a/libltdl/m4/ltdl.m4
+++ b/libltdl/m4/ltdl.m4
@@ -468,7 +468,7 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
freebsd* | dragonfly*)
lt_cv_sys_dlopen_deplibs=yes
;;
- gnu* | linux* | k*bsd*-gnu)
+ gnu* | linux* | k*bsd*-gnu | kopensolaris*-gnu)
# GNU and its variants, using gnu ld.so (Glibc)
lt_cv_sys_dlopen_deplibs=yes
;;
Re: [PATCH] GNU/kOpenSolaris port
On Mon, Dec 29, 2008 at 11:40:55PM +0100, Ralf Wildenhues wrote: I think the patch is mostly ok, but some details matter: you are not adjusting _LT_ENABLE_LOCK, which probably means $LD is not getting an appropriate '-m $emul' flag set, right? This only appears to be an issue for biarch arches like x86_64, powerpc or s390, am I right? Note that this port is i386 only for now. Secondly, at a glance I don't see support for your system's canonical name in config.guess/config.sub. Have you already sent a patch to the config-patc...@gnu.org address for that? I'm afraid it was rejected. The config maintainer has changed his policy and is now very strict about assigning new triplets. He requires a fully featured system with a user community, etc. And I suppose you understand that libtool support is essential before we can consider archieving this goal. This matters because while matching *-gnu might be the right thing for all systems with glibc, the ordering in the file may matter in that we shouldn't by accident have some other case branch that matches it earlier (this is mostly so we don't regress accidentally in the future). We're using 'i386-pc-kopensolaris-gnu' as triplet. I don't think it's likely that we match anything else by accident. As for non-glibc systems matching *-gnu, I verified (by inspecting config.guess) that the only possibilities are: - Linux-based systems (not a problem since you're matching them in the same checks anyway). - The old non-glibc Debian GNU/NetBSD port. I believe it is now defunct (I can confirm if you like), but even if it's not, it'd be possible to keep it happy by matching it before the generic *-gnu test. Thanks! -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all.
[PATCH] GNU/kOpenSolaris port
Hi,
I ported libtool to GNU/kOpenSolaris [1]. Because the checks are
always the same for all Glibc-based systems, and having to wait for
libtool to propagate to every package out there is a PITA, I propose
using a generic '*-gnu' match.
Attached is a patch for libtool (with ChangeLog entry) and a
make check log.
[1] Glibc-based system on kernel of Opensolaris, see:
http://csclub.uwaterloo.ca/~dtbartle/opensolaris/
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
2008-12-22 Robert Millan r...@aybabtu.com
* libltdl/m4/libtool.m4: Recognize all Glibc-based GNU variants
by matching $host_os against `*-gnu'.
* libltdl/m4/ltdl.m4: Likewise.
index b7b566d..c8dfa77 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2380,7 +2380,7 @@ linux*oldld* | linux*aout* | linux*coff*)
;;
# This must be Linux ELF.
-linux* | k*bsd*-gnu)
+linux* | *-gnu)
version_type=linux
need_lib_prefix=no
need_version=no
@@ -3014,7 +3014,7 @@ irix5* | irix6* | nonstopux*)
;;
# This must be Linux ELF.
-linux* | k*bsd*-gnu)
+linux* | *-gnu)
lt_cv_deplibs_check_method=pass_all
;;
@@ -3635,7 +3635,7 @@ m4_if([$1], [CXX], [
;;
esac
;;
- linux* | k*bsd*-gnu)
+ linux* | *-gnu)
case $cc_basename in
KCC*)
# KAI C++ Compiler
@@ -3919,7 +3919,7 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
-linux* | k*bsd*-gnu)
+linux* | *-gnu)
case $cc_basename in
# old Intel for x86_64 which still supported -KPIC.
ecc*)
@@ -4300,7 +4300,7 @@ _LT_EOF
_LT_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols $output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
;;
-gnu* | linux* | tpf* | k*bsd*-gnu)
+gnu* | linux* | tpf* | *-gnu)
tmp_diet=no
if test $host_os = linux-dietlibc; then
case $cc_basename in
@@ -5792,7 +5792,7 @@ if test $_lt_caught_CXX_error != yes; then
_LT_TAGVAR(inherit_rpath, $1)=yes
;;
- linux* | k*bsd*-gnu)
+ linux* | *-gnu)
case $cc_basename in
KCC*)
# Kuck and Associates, Inc. (KAI) C++ Compiler
index a2b1a4e..2dbefed 100644
--- a/libltdl/m4/ltdl.m4
+++ b/libltdl/m4/ltdl.m4
@@ -468,7 +468,7 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
freebsd* | dragonfly*)
lt_cv_sys_dlopen_deplibs=yes
;;
- gnu* | linux* | k*bsd*-gnu)
+ gnu* | linux* | *-gnu)
# GNU and its variants, using gnu ld.so (Glibc)
lt_cv_sys_dlopen_deplibs=yes
;;
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/sh.test
PASS: tests/suffix.test
PASS: tests/tagtrace.test
PASS: tests/cdemo-static.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-static.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-static.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-static.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/cdemo-conf.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-conf.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/demo-deplibs.test
PASS: tests/depdemo-conf.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/mdemo-conf.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/mdemo-dryrun.test
PASS: tests/mdemo2-conf.test
PASS: tests/mdemo2-make.test
PASS: tests/mdemo2-exec.test
PASS: tests/pdemo-conf.test
PASS: tests/pdemo-make.test
PASS: tests/pdemo-exec.test
PASS: tests/pdemo-inst.test
PASS: tests/demo-nofast.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-inst.test
PASS: tests/demo-unst.test
PASS: tests/depdemo-nofast.test
PASS: tests/depdemo-make.test
PASS: tests/depdemo-exec.test
PASS: tests/depdemo-inst.test
PASS: tests/depdemo-unst.test
PASS: tests/demo-pic.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/demo-nopic.test
PASS: tests/demo-make.test
PASS: tests/demo-exec.test
PASS: tests/cdemo-shared.test
PASS: tests/cdemo-make.test
PASS: tests/cdemo-exec.test
PASS: tests/demo-shared.test
PASS: tests/demo-make.test
PASS: tests/demo
Re: libtool pre-1.5b tests fail on 9 debian arches
On Tue, Oct 07, 2003 at 04:36:47PM +0100, Gary V. Vaughan wrote: My apologies for having taken so long to respond to this thread. My hacking time is short, and the thread was growing faster than I could read it... :-) No problem. libtool maintainers: Would you consider giving either Scott or me (preferably both) with CVS access? That'd help a lot getting libtool in shape for all architectures without having to maintain such a debian fork of libtool. Absolutely. The FSF will inform me when the paperwork is done, Ok. I'll take care about the paperwork. Scott, will you go through this too? You must also agree not to commit anything for which you do not have knowledge of the author, and the author has exchanged paperwork with the FSF, except for very small patches. No problem. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote: Actually if it was branch-1-5 you were testing, that'd be the new 1.5.0a (1.5.1) release. 1.5b would be on HEAD (as far as I understand the esoteric version numbering upstream use) and a pre-release of libtool 1.6 (which we know Gary wants to get out of the door alongside Autoconf 2.58 and Automake 1.8). Gary asked me to test branch-1-5, although he didn't put it very clear wether that branch is for 1.5b or 1.5.0a. Gary, please could you clarify? Use the Debian libtool package, not only do I currently track CVS rather than use the pure 1.5 release, there are additional Debian patches added to make it work on some of the architectures. It's not the Debian libtool package which is (generaly) used by upstream maintainers to update their libtools. My concern is with upstream packages using upstream libtool, hence the Debian package is not relevant. Getting these patches accepted upstream is tricky though, I've sent some bug fixes through. A few days ago I decided to have a go getting some of the portability patches (some of which are large) accepted, I mailed the smallest (yet one of the more far-reaching ones) to -patches; haven't had any follow-up yet though. My patch sending policy involves pinging them after a week of not responding, then periodicaly pinging them at increased rate. It's quite effective. Could you try merging all the other patches, so that we can reliably test libtool on all of Debian's arches? FWIW, I've run the same tests on Debian unstable with the Debian libtool 1.5-2 package. I've also tried to ascertain *why* tests are failing, it would've been nice if you could've done the same (or perhaps you're working on that?) Actualy not. I don't have time to do that, nor experience with cpu porting thingies like endianess, alignment or such. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 08:04:55PM +0100, Scott James Remnant wrote: Or an even better one, just from build failures in the last few days ... upstream placing the contents of libtool.m4 in acinclude.m4, so even after aclocal runs the old version is still used. One thing about maintaining a GNU auto tools package, you certainly see some brain dead practises by other upstream developers. Do these guys not read the manuals? :) Many of them don't, and we have to live with that. We should start doing that, and I can help. Just requested copyright papers myself (I assume you've already done that). libtool maintainers: Would you consider giving either Scott or me (preferably both) with CVS access? That'd help a lot getting libtool in shape for all architectures without having to maintain such a debian fork of libtool. I brought it up about six months ago (about the same time I sorted through all the patches), I'm quite willing to undergo the paper signing -- consider this a request. Assigning copyright and being given CVS access is not necessarily related: - If you send too many patches for review without having CVS access, then you might consider assigning copyright so that you can send more patches for review. - Sometimes GNU maintainers agree to give you CVS access before the actual paper signing process is complete, provided that you agree not to commit more code of your own than you're allowed to. (this is my current situation with GNU GRUB, for example). Scott: IMO all Debian maintainers of GNU software should do this as part of their maintaining task. Please request assigning copyright for past and future changes to libtool by emailing [EMAIL PROTECTED]. libtool maintainers: On having CVS access, I myself would agree to apply only non-conflictive patches (such as my GNU/K*BSD stuff) unless otherwise discussed in the list (I believe the same applies to Scott). If you need credentials, I'm member of Debian and have already access to GRUB CVS. Does all this sound ok for you? Let's reopen it. Gary, Peter, Bob? Probably the best compromise all round would be to add something like this to libtool.texi below the current permission statements: [...] When I suggested to reopen it, I thought you were referring to the patch submission issue, not the GFDL stuff. GNU libtool is copyrighted by the FSF and only the FSF may license it under additional terms. It's not something you should discuss with libtool's maintainers, nor something that should be discussed on this list. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sun, Sep 28, 2003 at 10:17:34AM -0500, Bob Friesenhahn wrote: - If you send too many patches for review without having CVS access, then you might consider assigning copyright so that you can send more patches for review. The FSF guidelines specify allow to 14 lines of *total* contribution from an author without copyright assignment. It doesn't take many small patches to reach this level. That's right.. well I always try to assign copyright after my first patch of commited code. - Sometimes GNU maintainers agree to give you CVS access before the actual paper signing process is complete, provided that you agree not to commit more code of your own than you're allowed to. (this is my current situation with GNU GRUB, for example). I believe that this practice is contrary to the agreement we sign with the FSF. If word-of-mouth and personal trust was sufficient, then there would be no need for paper contracts. The SCO/Linux situation is evidence that these are not minor issues. Uhm.. Perhaps Okuji was confused on this. Well my signed papers for GRUB are fortunately on the way back. I'll make sure this error doesn't happen with me again. Scott: IMO all Debian maintainers of GNU software should do this as part of their maintaining task. Please request assigning copyright for past and future changes to libtool by emailing [EMAIL PROTECTED]. Very good idea. However, always keep in mind that if someone sends a patch to a person with signed paperwork, then the recipient is not the author of the patch and the situation has not significantly improved. I'm well aware of this. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS head requires am-1.8 and ac-2.58
Hi! I just noticed that with latest Gary's commit running the bootstrap script from libtool CVS HEAD now requires automake 1.8 and autoconf 2.58. As I already commented on this list, I'm going through the task of testing libtool on a variety of CPUs and asking the Debian port maintainers for help fixing the various problems encountered. Since none of autoconf 2.58 or automake 1.8 are released yet, it's a bit impractical for us to prepare a CVS snapshot for testing and it'd be more convenient if a pre-release tarball was available. Please, could you provide a pre-release tarball with that doesn't require unreleased autotools versions? That'd help much my current testing efforts. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 04:30:15AM +0100, Scott James Remnant wrote: On Sat, 2003-09-27 at 06:06, Robert Millan wrote: It's not the Debian libtool package which is (generaly) used by upstream maintainers to update their libtools. My concern is with upstream packages using upstream libtool, hence the Debian package is not relevant. Which therefore makes me wonder why you Cc'd the various Debian ports lists. We've had an unofficial policy for some time now that porters will request/require package maintainers to use the Debian libtool package if things break. Which is an oddly insane policy. Updating libtool is a non-trivial task most of the times and not a simple libtoolize run as you could pretend, I can give you examples if you like. I'm asking myself why some Debian porters prefer spending hours mass-filing update libtool bugs everytime libtool breaks for them, instead of fixing libtool properly in upstream. We're all VERY well aware that upstream libtool isn't portable across all Debian architectures, it doesn't work on arm at all -- and until recently didn't work on mips, mipsel or m68k either! This is precisely why Debian's libtool package contains so many additional patches, so when things do break we can just tell the maintainers to update the package with the libtool installed on their system. Great. So if libtool is broken in upstream and breaks for all the non-Debian world we just don't care? Isn't this a violation of the Debian Social Contract? We will feed back bug-fixes, improvements, user requests, etc. to the \upstream\ authors of software included in our system. (http://www.debian.org/social_contract) It can be, but very often patches or mails I've sent are simply ignored. I'm almost positive the pass_all patch will be rejected, if it's ever even considered. And yet without that patch, Linux ARM and libtool won't be friends. [...] Not to mention the various copyright problems that GNU will care about ... a fair chunk is my copyright, but some of the patches which have fixed Debian problems have come from others -- quite a few off the -patches list which upstream also ignored, and yet they fixed problems. I'm aware of all this. And I can help you if you like. There's also the problem that Debian may not be able to continue distributing the upstream libtool tar file at all, because it contains non-free material (the GNU FDL licensed documentation) -- at which point I'll simply fork Debian libtool and maintain it by merging every so often with GNU libtool. So you want to fork a project because it contains non-free components? I've been maintaining Bochs and Plex86 in Debian for quite some time now. They have _always_ come with the non-free VGA BIOS, and I just removed it with every update. Never considered forking for such a reason. I don't see the distinction between testing with Debian's libtool package, or the upstream libtool with Debian's patches applied? Nor do I. But you can't ask all developers of packages using libtool to start using either of these instead of the official libtool releases. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote: Updating to any later version of Libtool is the same amount of work, whether it be the Debian-patched version or not. Most of the time, when build failures occur, the package upstream is using either an insanely out of date version anyway and needs updating whatever the case. That implies asking upstream to update their libtool using upstream libtool in first place, then replacing it with debian's libtool. Asides from the time-consuming effort this represents, the following are examples of problems that may (and usualy do) occur: - libtool.m4 is in a non-standard location or even with a different name; go search for it. - aclocal.m4 won't regenerate with your version of aclocal, and the version upstream used is not present in Debian (e.g: 1.7.6) - configure won't regenerate with your version of autoconf, and the version upstream used is not present in Debian (e.g: 2.53) Add here the fact that upstream is not responsive, and you get a whole can of worms. And this is only _one_ package, porters have to port hundreds of them. Of course, this is only for the situation when upstream updates their upstream libtool for you. When you have to update between different versions of libtool, you'll hit incompatibility errors (missing --tag option, anyone?). The reason porters tell maintainers to use the Debian libtool package and not the upstream version is simple... They've generally grabbed me on IRC and we've gone through the build logs, and in some cases our libtool package has been patched and uploaded first. Agreed. When a broken libtool has already been released, there's not much thing to do other than maintaining all these patches in Debian. Getting appropriate patches submitted upstream is a difficult task, and I'm not the only person who believes so, it is something I want to do and have been trying to do, but it's proving hard work to get replies half the time! We should start doing that, and I can help. Just requested copyright papers myself (I assume you've already done that). libtool maintainers: Would you consider giving either Scott or me (preferably both) with CVS access? That'd help a lot getting libtool in shape for all architectures without having to maintain such a debian fork of libtool. [...] If that makes sense? I wasn't intending to infer a new libtool project, I was trying to indicate we wouldn't be able to use the original upstream tar file in the package anymore. Yep, it makes sense now. (it's just the same I've been doing for Bochs) I sent an e-mail over a month ago to open a discussion about this problem, and it went unanswered. Let's reopen it. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
automake 1.4-p5 is not new enough
Hi, I'm checking files from CVS and generating the autotools stuff using the ./bootstrap script. My first attempt failed with automake 1.4-p6, then I tried again with automake 1.7 and the result is that it works with 1.7 but doesn't with 1.4-p6 or older. So the note in ./bootstrap script should be fixed, it currently says automake1.4-p5 and later are supported: # helps bootstrapping libtool, when checked out from CVS # requires at least GNU autoconf 2.50 and GNU automake1.4-p5 -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
