pan-users
[Top][All Lists]
Advanced

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

[Pan-users] Achy Breaky Make


From: Peter B. Steiger
Subject: [Pan-users] Achy Breaky Make
Date: Fri, 03 Jan 2003 18:46:02 -0600

Actually, I have two problems, and I know it's something I'm doing on my end 
because smart people already have 0.13.3 running with only the most minor of 
problems.

First is the error trying to run make from /usr/src/pan-0.13.3 (also 13.2):
make[2]: Entering directory `/usr/src/pan-0.13.3/po'
make[2]: *** No rule to make target `caNONE', needed by `all-yes'.  Stop.
make[2]: Leaving directory `/usr/src/pan-0.13.3/po'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/pan-0.13.3'
make: *** [all-recursive-am] Error 2

I can make the individual subdirectories (gmime, pan, and tests) without any 
errors, 
but if I try to run make from the source root or if I try to make just the /po 
subdirectory, I get that same error.  I'm guessing it is something I left out 
of the 
configuration.  I ran:
./configure --prefix=/usr --disable-gtkspell

I'm on RH 7.3 with the kernel updated to 2.4.20, gtk2 2.0.6-8.  There is indeed 
a 
caNONE in the Makefile for the po directory; in fact it looks like all the 
(language? 
country?) definitions in CATALOGS are set to xxNONE.  I can get around this by 
editing the configure script to read ALL_LINGUAS="" but I assume that is 
breaking 
something vital to the build.

The other problem, which I encountered with all 13.* binaries and those 
compiled 
straight from 13.x source, is that pan seems to be dropping posts.  The freaky 
thing 
is, it's a sporadic problem.  I figured I should have some debug logs handy in 
case 
anyone asked, so I ran a few tests.  My first ten tests to alt.test, 
comp.os.linux.test, 
and a local (wyo.general) newsgroup all failed and I had no debug logs to show 
what 
happened.  So I ran it with pan --debug --debug-sockets (I don't know if that's 
redundant, but I wanted to be sure)... and the flippin' thing worked perfectly. 
 Ran 
another test with debug turned off... and it failed.

I should clarify that when it fails, there are no error messages on the console 
or in a 
window; it doesn't crash; everything else works fine.  I should also add that 
it's not a 
connectivity problem because older versions of pan (11.* and 12.*) post OK 
consistently, and I can telnet to port 119 and manually post without any 
problems.

Anyhow, I also turned on a packet sniffer (ngrep) and dumped the whole dialogue 
from port 119 to a log file.  Again, my test posts worked beautifully.

Over the past two hours, I have run about 20 tests using different builds and 
different 
command line options and different combinations of --debug and/or ngrep and/or 
both and/or neither, and there just isn't a consistent pattern.  Just when I 
decided that 
the debug environment was causing it to work, I had one post with everything 
turned 
off that worked, and several that failed with the debug diagnostics turned on.

At least the ones that failed when I had debug turned on give me something.  
ngrep 
shows that it connected (got the 200 Welcome message), it sent a MODE READER 
command, and got another welcome message... but never issued the POST 
command or wrote a message.  Stranger, the message does show up in the 
pan.sent directory afterwards.  There is no other strange behavior... the X 
display is 
fine, it retrieves messages and downloads binaries without any trouble, etc.

Has anyone else seen this?  Would a dump of the --debug log help (about 72K), 
or 
can I dig through it looking for relevant useful information?

Let's see... platform is RH 7.3 with the kernel bumped up to 2.4.20, using 
XFree86 
4.2.0-8 without KDE or Gnome... the only wm involved is blackbox.  In some of 
my 
tests I launched pan from an xterm window; in others I launched it through a 
blackbox menu option.  Behavior was the same (or at least equally inconsistent) 
both 
ways.  Anything else I should mention?

pbs
--------
Peter B. Steiger
Cheyenne, WY






reply via email to

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