Re: [Pan-users] Re: pcre error (was: undefined reference to iconv)

[Phil Grundig]

Thank you Duncan for keeping list users in the loop concerning development 
status, and for all your hard work on this list.

I suppose the OP does know that, if one can stomach non-OSS software, that both 
Agent and XNews will run under Wine.  I think some dlls have to be added for 
yEnc in the case of one of these.  Either can crash randomly.

Both are formidable programs with many features, but both are also a bit too 
complex interface-wise for my liking and have learning curves, esp XNews - Pan 
seems far simpler to use.



--- On Mon, 12/1/09, Duncan <address@hidden> wrote:

> From: Duncan <address@hidden>
> Subject: [Pan-users] Re: pcre error (was: undefined reference to iconv)
> To: address@hidden
> Date: Monday, 12 January, 2009, 9:22 AM
> "arnuld uttre" <address@hidden>
> posted
> address@hidden,
> excerpted below, on  Mon, 12 Jan 2009 10:17:41 +0530:
> 
> >> On Fri, Jan 9, 2009 at 10:33 PM, Duncan
> >> <address@hidden> wrote:
> > 
> >> The recommendation is therefore to try the latest
> pan, 0.133.
> > 
> > okay, I thought PAN has 2 branches: stable and
> testing. I did not know
> > that 0.14 was obsolete. Web-site did not offer much
> information on it.
> 
> Yes, that has been a bit of a frustration, both for me
> personally and for 
> Charles, pan's primary developer.  
> 
> Charles had intended to have a stable new version, actually
> making it 
> 1.0, long before now.  Truth be told, with the C++ rewrite
> he restarted 
> the versioning at 0.90 and I think they were supposed to be
> 1.0 betas and 
> he didn't expect to ever hit triple digits before 1.0. 
> For over a year 
> he released nearly weekly betas, rather burning himself out
> in the 
> process, I guess.
> 
> But he obviously /waaayyy/ underestimated the amount of
> work necessary to 
> get pan in shape for a real "worthy" 1.0.  The
> idea was that because the 
> new C++ version was new code and modular, it would be MUCH
> easier to work 
> with (and I think it was), and that all the features of the
> old code and 
> more could be easily added back in.  Well, it's true...
> but there was 
> simply vastly more work there than I guess he thought there
> was, and that 
> along with sorting out some pretty tough bugs along the
> way, well...
> 
> So some 40 nearly weekly beta releases and a bit over a
> year later, I 
> guess Charles decided, probably from shear burnout, that he
> had to take a 
> break.  The last of those versions was 0.132, released on
> August 1, 
> 2007.  A year later to the day, he release 0.133 on August
> 1, 2008.  It 
> included several patches that had been applied to 0.132 by
> various 
> distributions and were thus submitted by the community. 
> One of these was 
> a security patch, others included patches to fix pan's
> compiling with 
> gcc-4.3+ and against glib 2.16+, and various i18n&l10n
> updates.  However, 
> he's evidently not yet ready to get back into the
> grind, as there was 
> little new code beyond community submitted patches, and as
> of a week or 
> so ago, there had been nothing (beyond a handful of l10n
> updates, the 
> work of GNOME's i18n team, not Charles) done in the
> subversion repository 
> since.
> 
> Meanwhile, at least one major feature, the
> "rules" that allowed auto-mark-
> read/delete/download, has yet to be ported to the rewrite. 
> According to 
> discussions Charles has participated in, he doesn't
> intend to port it 
> directly because the previous implementation was simply too
> complex to be 
> practical for many users (it was, we helped quite a few
> users with it 
> here over the years), but to reimplement the auto-actions,
> the bit that's 
> actually practical in the new version, with the GUI as
> another tab in 
> preferences, with options for each of the three
> auto-actions triggered 
> based on the same score categories used on the color tab.
> 
> With that and some documentation, plus random bug fixes and
> maybe a way 
> to categorize the subscribed groups into at least one
> additional level on 
> the groups tree (the other most requested item, the
> workaround in old-
> pan, multiple "servers" that could actually point
> to the same one, 
> doesn't work in new-pan due to the full multi-server
> integration), pan 
> would be pretty much ready for a 1.0.
> 
> However, that's likely to be another several months of
> coding and bug-
> fixing all the bugs in the new code before it would be
> ready.  Charles 
> has debate a 1.0 with basically what we have... but that
> hasn't happened 
> either, maybe because he has decided my argument that to do
> so before the 
> rewrite has at least something to replace the auto-actions
> possible using 
> the rules in the old implementation, would be a big
> disappointment to 
> those who have used pan in the past, and have waited so
> long for a 1.0.
> 
> But... Charles /had/ at least the intention of 1.0 being
> the next stable 
> version, so here we sit.  The rewrite is by now certainly
> as stable as 
> the old code ever was, scales VASTLY better than the old
> code ever did, 
> and has some nice new features, but OTOH, still lacks at
> least that one, 
> from the old code.
> 
> I've wished for years that some other developer with
> the necessary skills 
> would take an interest and be able to work closely enough
> with Charles to 
> take some of the pressure off, and hopefully get pan out of
> the fits and 
> spurts cycle where it goes great guns for awhile, then all
> but stops, 
> then goes great guns again, but it hasn't happened.  I
> wish I had the 
> necessary skills.  I don't.  I don't know if
> it's that Charles is hard to 
> work with, he hasn't seemed so from what I've
> worked with him, but as I 
> said, I'm not a dev, and it'd be different if I
> was, or if there's simply 
> not very many people, at least devs, interested in news any
> more, at 
> least the GTK/GUI binary downloader text poster niche that
> pan fills.
> 
> I'm sure you can read between the lines some of the
> frustration, at 
> myself for not having the skills, at those who do for not
> being 
> interested, at Charles, tho I too would have been burned
> out after a year 
> of weekly betas, etc, and can't really throw stones as
> I don't have the 
> skills myself.
> 
> Meanwhile, pan remains in many ways the best solution out
> there, 
> certainly for gtk (arguably klibido on the KDE side is a
> worth comparison 
> as just a binary bulk downloader, and there are other
> clients for text), 
> and while I can't code and help the project that way, I
> continue to 
> volunteer here, helping at the level I can.  I've not
> tracked whether I'm 
> the most senior active list regular or not, tho I expect
> I'm close, and I 
> believe I am the most active, hopefully helping...
> 
> Not that all that's much help for your particular
> problems of the 
> moment... but it should give you some background, for
> whatever /that's/ 
> worth.
> 
> >> how old Centos 4.4 is, either.  If it's >4
> years old, old-pan should
> >> fit right in.
> > 
> > yes, CentOS 4.0 was released on March 2nd of 2005. The
> 4.x are just with
> > new security updates keeping the base system same.
> Anyway, I tried
> > installing 0.133 and got this error:
> 
> 
> If it's that old and you've not updated them, then
> the gcc/glib/gtk are 
> likely equally old, and old-pan may indeed be a better fit.
>  New-pan 
> should work too tho as it's in theory backward
> compatible well beyond 
> that.  Unfortunately theory isn't matching reality for
> you at this point 
> and you're having problems getting either old or new
> pan to work.  
> Frustrating!
> 
> > checking for PCRE... configure: error: Package
> requirements (libpcre
> >    >= 5.0) were not met:
> > 
> > Package libpcre was not found in the pkg-config search
> path. [etc]
> > 
> > address@hidden pan-0.133]$ pcretest -s
> > PCRE version 4.5 01-December-2003
> 
> OK, so you need libpcre 5.x and only have 4.x.  As I said,
> with something 
> that old, maybe the old-pan would be easier, but either
> way, you're 
> having problems and need to fix one or the other to work.
> 
> > If I install the newer pcre in /usr/local , will it
> break my existing
> > system. I can't take the risk as its office
> computer, not mine. Or you
> > guys can suggest some other older version or some
> other older
> > Newsreader.
> 
> The problem I'm running into helping you directly is
> that I'm not a 
> CentOS/RH/Fedora guy, tho I did run Mandrake, which was
> supposed to be 
> Red Hat compatible, years ago. I switched away, to Gentoo,
> in 2004, and 
> remain quite happy with it today.  But Gentoo works best
> for those who 
> keep relatively up-to-date, which I do and that's one
> of the reasons it 
> works so well for me, so I've long forgotten what
> versions of various 
> things were current back in 2005.  So not only am I
> fighting "impedance 
> mismatches" due to the distribution cultural
> differences, but I'm 
> fighting the time gap as well and thus am finding I'm
> not as much help to 
> you as I'd like to be.
> 
> FWIW, currently available Gentoo libpcre versions are 7.7
> and 7.8... (I'm 
> on unstable/beta/testing, which Gentoo calls ~arch, so am
> of course 
> running 7.8) that's the gap we're trying to bridge.
>  So 5.x looks pretty 
> ancient from here, yet it's newer than what you have.
> 
> What I was hoping to see were two or more different major
> versions, say 
> 5.x and 6.x, so I could check to see if they were slotted
> differently.  
> Slotting allows installation of both, so it's a good
> hint that you 
> /should/ be able to install 5.x without messing up 4.x. 
> But both 
> available versions here are 7.x, and both the same slot,
> 3.x, which 
> indicates that there has been parallel installation
> available in the 
> past, but isn't now.  I've therefore no direct clue
> on whether 4.x and 
> higher could be installed together without interfering with
> each other, 
> or if indeed, 5.x might actually be backward compatible
> with 4.x.
> 
> FWIW, meanwhile, there's a Fedora regular here too, who
> contributes where 
> he can, but he's not particularly technically inclined,
> so that's not 
> going to help much either.
> 
> So we gotta go a different way...
> 
> Let's backup a bit.  You haven't mentioned knowing
> about pan's overall 
> requirements, so I'm guessing you haven't seen
> pan's requirement page, 
> here:
> 
> http://pan.rebelbase.com/requirements/
> 
> Taking a look at that list, is the pcre 5+ requirement all
> you're lacking 
> on the 0.90+ requirements?  If you are lacking several of
> them (and 
> they're not easily available from the CentOS or
> equivalent repositories), 
> it's probably easiest to shoot for 0.14.x, even if it
> is not any longer 
> officially supported.  If pcre's all you're
> lacking, fixing that and 
> being able to run a current pan will likely be better, and
> may well be 
> easier.
> 
> Next question, CentOS 4.4, what does that correspond to for
> Red Hat 
> version, and if you know, Fedora version?  Perhaps we can
> find you some 
> compatible repositories and pan and dependencies can be
> filled from 
> binaries from them.  While we're at it, what
> repositories do you have 
> configured, currently?
> 
> As for news client alternatives, there's lots of them
> out there, but few 
> filling the generally well rounded niche pan does anywhere
> near as well.  
> But if you're not using much of what pan offers anyway,
> there may well be 
> a client either more lightweight, or better suited to the
> specific 
> purpose you had in mind.  I had avoided asking earlier as
> you hadn't 
> volunteered it and I had no need to know, but to answer
> this one, I do, 
> what sort of groups are you intending to use your reader,
> once you get 
> one, with?  Only binary groups?  Only text/discussion
> groups?  A mix?  If 
> binary do you know if yEnc posting is common in those
> groups or not?  
> (Many clients don't do yEnc.)  Are you mainly
> interested in a binary 
> harvester only or do you plan on posting, and if so, text
> posts only, 
> binary only, or a mixture?  If binary, mostly single-part
> such as jpeg 
> groups, mostly multi-part such as ISO, movie, and to a
> lessor extent MP3 
> groups, or both?  If you do both text and binary, would a
> separate client 
> for each be a big bother or do you strongly prefer a single
> well-rounded 
> client such as pan?  Are you most comfortable with a GUI or
> would you 
> find a terminal mode client usable?  Do you do EMACS?  (If
> so, you may 
> find gnus a good fit.)  Do you have GNOME installed?  GTK
> (presumably yes 
> on that since pan uses it)?  KDE?  Are they available and
> do you mind 
> installing them if they aren't installed already? 
> Which versions 
> (major.minor)?
> 
> Obviously, answering these questions will help in
> recommending suitable 
> pan alternatives.
> 
> -- 
> 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
> 
> 
> 
> _______________________________________________
> Pan-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/pan-users