[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool pre-1.5b tests fail on 9 debian arches

From: Dalibor Topic
Subject: Re: libtool pre-1.5b tests fail on 9 debian arches
Date: Sat, 27 Sep 2003 16:59:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Hi Scott,

I appreciate the hard work you're doing on keeping libtool in shape on debian. I can feel with you a little bit, as I'm hacking on kaffe's build system, and kaffe (in theory, at least) builds on 50+ platforms, a few of which I ocassionally get to test, and fix/let people fix libtool on. A few months ago I started feeding back kaffe's libtool patches into the main tree. It was hard work: it took about 2 months to get all of the 5 patches in, of which a few only changed a single line, almost all required a 'ping! single line patch uncommented for 2 weeks, does anyone maintain libtool?' mails and so on. I was angry at times, so angry that I considered forking libtool myself.

I didn't. In a small part because all of our patches are now in libtool. In a much larger part because I realized that the libtool maintainers have a huge task on their hands: maintaining a crucial bit of GNU infrastructure, that has become an immensely popular tool for building free software on dozens of platforms. Given the size of task, and the comparatively small size of the libtool maintainer team, it's no wonder that patches apparently sometimes go straight from libtool-patches to /dev/null. And of course, I didn't get to fork libtool, because at the end of the day I want to hack on kaffe, not on libtool ;)

So I kept pinging the libtool-patches list until the maintainers managed to get some time to look at the patches and check them in. In my experience, a catchy subject line like "Single Line Patch to fix i386-OpenBSD 3.3 libtool linking problem, ChangeLog included" has a much higher chance of being picked up by the maintainers, than "Fix for linking issue". When pinging about a patch, make sure you put the "unreviewed for X days" line in, it may touch someone's heart to take a look into your patch evetually ;)

Since my last rant about the issue, the libtool team has attracted at least one new member, and gary has also made a massive come-back ;), so I find them more responsive now. From what I can see on libtool-patches, patch pings for patches that haven't been reviewed for weeks have become a thing of past, which is great.

On the other hand, I'd still like to point out, that it would be beneficial to both libtool, and the respective ports, if the libtool maintainer team broadened to include maintainers of libtool packages on debian, fresbsd, openbsd, netbsd, and other operating systems with many pending patches to libtool. Last time around I made an effort to show how much of the interesting stuff is out there, how much good work has been done by packagers and hasn't entered libtool yet. If the libtool team could make the effort to accept more libtool package maintainers as contributors, I think all sides would profit. Kaffe too ;)

thanks for reading,
dalibor topic

Scott James Remnant wrote:
(Removed debian lists from Cc, I don't see how this is relevant to the

On Sat, 2003-09-27 at 06:06, Robert Millan wrote:

On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote:

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.

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.

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

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.

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.

Could you try merging all the other patches, so that we can reliably test
libtool on all of Debian's arches?

Only once I've had some degree of success in getting some of the trivial
patches applied will I actually worry about untangling the various
changes and making them into patches.  It's a non-trivial amount of work
for each patch, and there are more than a dozen now -- a few of them
quite large.

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.

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.

If you're interested whether upstream's libtool releases are portable
between Linux architectures, you've already done that test and seen that
they are not.

I don't see the distinction between testing with Debian's libtool
package, or the upstream libtool with Debian's patches applied?

Debian's package "works" (except for the ia64 test problems, which I
strongly suspect are problems in the test code not libtool) which is why
when things break we tell maintainers to use our package instead
whatever random version upstream found on their hard drive.



Libtool mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]