[Top][All Lists]

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

[Pan-users] Re: Pan cannot handle large numbers of headers?

From: Duncan
Subject: [Pan-users] Re: Pan cannot handle large numbers of headers?
Date: Sun, 14 Aug 2005 07:21:43 -0700
User-agent: Pan/ (As She Crawled Across the Table)

Rinaldi J. Montessi posted <address@hidden>, excerpted
below,  on Sun, 14 Aug 2005 09:27:21 -0400:

> John Wendel wrote:
>> Phillip Pi wrote:
>>> Hello,
>>> Is it me or does Pan v0.14.2.91 fail to handle large numbers of headers 
>>> from a newsgroup? I 
>>> tried to download about 3,044,000 headers from alt.binaries.hdtv newsgroup. 
>>> My computer choked 
>>> at about 1,900,000 headers when I came back from a 30 minutes break. HDD 
>>> light was spinning, m 
>>> KDE v3.3.4 was frozen and not responsive. I had to kill Pan via SSH. Of 
>>> course that was slow as 
>>> heck too. I eventually to kill X server because stuff was broken.
>>> I am using an Athlon XP 2200+ with 1 GB of RAM. Isn't that enough or is Pan 
>>> not optimized for 
>>> this big number of headers?
>>> Thank you in advance. :)
>> Known problem, mostly fixed in the CVS version.  Just run these commands 
>> to build yourself a version that works (with a few random bugs).
>>  >export CVSROOT=":pserver:address@hidden:/cvs/gnome"
>>  >cvs login
>>  >cvs -z3 checkout pan
>>  >cd pan
>>  >./
> Fails.  Apparently Pan depends on older versions?
> ~/tmp/pan$ ./
> /usr/local/bin/
> checking for autoconf >= 2.53...
>    testing autoconf2.50... not found.
>    testing autoconf... found 2.59
> checking for automake >= 1.4...
>    testing automake-1.4... not found.
> ***Error***: You must have automake >= 1.4 installed
>    to build Pan.  Download the appropriate package for
>    from your distribution or get the source tarball at

I'd imagine so.  automake is one of those weird apps where pretty much
each /minor/ version is incompatible.  Where a normal app would change
major version if it needed to break backward compatibility, automake
apparently changes minor version.  autoconf is similar, but not as bad.

I can't say I know the details, but I do run Gentoo, and compile
everything, so am likely to have all the various versions still in normal
use, at least, for both packages.  Here's what equery says I have
installed (the wrapper for each package is a script that will normally
figure out which one is needed, and arrange for it to be the one the make
process finds):

$ equery list automake

[ Searching for package 'automake' in all categories among: ]
 * installed packages
[I--] [  ] sys-devel/automake-1.7.9-r1 (1.7)
[I--] [  ] sys-devel/automake-1.8.5-r3 (1.8)
[I--] [  ] sys-devel/automake-1.5 (1.5)
[I--] [  ] sys-devel/automake-wrapper-1-r1 (0)
[I--] [  ] sys-devel/automake-1.4_p6 (1.4)
[I--] [  ] sys-devel/automake-1.6.3 (1.6)
[I--] [  ] sys-devel/automake-1.9.6 (1.9)

$ equery l autoconf

[ Searching for package 'autoconf' in all categories among: ]
 * installed packages
[I--] [  ] sys-devel/autoconf-2.59-r7 (2.5)
[I--] [  ] sys-devel/autoconf-wrapper-3.1 (0)
[I--] [  ] sys-devel/autoconf-2.13 (2.1)


The number in parenthesis is the "slot" number.  Zero means portage
doesn't slot that package, otherwise, it indicates a package where a
sysadmin is likely to want two or more versions installed at the same
time.  Thus, for automake, there are separate slots for versions 1.4, 1.5,
1.6, 1.7, 1.8, and 1.9.  You'll probably need automake 1.4.x or
possibly 1.5.x. (Note that the _p6 indicates upstream patch-level six. 
Why they can't make it 1.4.6, or, I couldn't tell you, but there
you have it.)

Do note that /some/ distributions make a single all-inclusive package,
that includes one copy of each minor version, with the package versioned
the same as the highest included version.  Thus, it's possible you won't
find automake 1.4.x, only a 1.9.x package, that includes a copy of 1.4.x.

Finally, note that while many distributions have wrappers, sometimes the
wrapper makes a mistake.  It's possible you have all versions installed,
but need to set a variable or command line option, to point it at
the correct version.  Unfortunately, I don't know as much about doing that
as I'd like to, so it'd be hit and miss, here, as well.  

If your distrib uses a wrapper, --version would normally return the
highest version installed.  Here, automake --version returns 1.9.6,
despite my having all sorts of versions installed.)

$automake --version
automake (GNU automake) 1.9.6


$automake-1.4 --version
automake (GNU automake) 1.4-p6

Try using tab-completion on automake, see if it offers you several

automake      automake-1.4  automake-1.5  automake-1.6  automake-1.7 
automake-1.8  automake-1.9

If so, investigate the autogen script (and your wrapper script, assuming
it's a wrapper) and see what you need to do to change the version it
points to, or, alternatively, temporarily move your "automake" and create
a symlink automake, pointing at automake-1.4.

> checking for glib-gettext >= 2.2.0...
>    testing glib-gettextize... found 2.6.5
> checking for intltool >= 0.25...
>    testing intltoolize... found 0.30
> checking for pkg-config >= 0.14.0...
>    testing pkg-config... found 0.15.0
> /usr/local/bin/ line 154: --print-ac-dir: command not found
> Checking for required M4 macros...
>    glib-gettext.m4 not found
>    intltool.m4 not found
>    pkg.m4 not found
> Checking for forbidden M4 macros...
> ***Error***: some autoconf macros required to build Pan
>    were not found in your aclocal path, or some forbidden
>    macros were found.  Perhaps you need to adjust your
> ~/tmp/pan$ automake --version
> automake (GNU automake) 1.9.5

FWIW, here are the packages that contain those files, here:

$ equery belongs glib-gettext.m4

[ Searching for file(s) glib-gettext.m4 in *... ]
dev-libs/glib-2.6.5 (/usr/share/aclocal/glib-gettext.m4)

$ equery belongs intltool.m4

[ Searching for file(s) intltool.m4 in *... ]
dev-util/intltool-0.34.1 (/usr/share/aclocal/intltool.m4)

$ equery belongs pkg.m4

[ Searching for file(s) pkg.m4 in *... ]
dev-util/pkgconfig-0.18.1-r1 (/usr/share/aclocal/pkg.m4)


However, it's likely all you have to do is set a variable or command line
option, pointing the script at the correct location, as you probably
already have them, or at least glib-gettext.m4 (unless it's in a -devel
package you don't have installed, that's one thing Gentoo doesn't have to
worry about, since we normally compile and install from source, anyway,
meaning splitting a package into run-time and devel packages would simply
be a lot of work for very little gain).

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in

reply via email to

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