<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.gnome.apps.pan.user">
    <title>gmane.comp.gnome.apps.pan.user</title>
    <link>http://blog.gmane.org/gmane.comp.gnome.apps.pan.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13414"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13413"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13412"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13411"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13410"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13409"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13408"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13407"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13406"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13405"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13404"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13403"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13402"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13401"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13400"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13399"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13398"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13397"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13396"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13395"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13414">
    <title>Re: Small portability issue</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13414</link>
    <description>&lt;pre&gt;Hey,

On Wed, 09 May 2012 19:33:30 +0200 Heinrich Mueller wrote:


intltool really seems like some sort of black magic at times. Pan uses
standard configuration when it comes to i18n (that is, glib-gettext +
intltool for strings extraction), however, the same configuration is used
for many other GNOME apps and tools, so I suppose that the check would fail
for other apps too. Not sure what to do with that, we could probably switch
from glib-gettext directly to gettext to see whether that would help, but
last time I checked this configuration, it added some complexity (and build
failures too :-) 


Cheers,
Petr Kovar
&lt;/pre&gt;</description>
    <dc:creator>Petr Kovar</dc:creator>
    <dc:date>2012-05-22T14:13:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13413">
    <title>Re: cached articles marked as read?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13413</link>
    <description>&lt;pre&gt;Duncan posted on Tue, 22 May 2012 07:27:51 +0000 as excerpted:


[History and ideal functional description deleted...]


As I mentioned, there's two very different routines for handing binaries, 
the direct-save-as-you-go method, which was pan's original design, and 
the pre-cache-to-go-thru-later method, which on a slow/bad connection 
where on-demand downloading of text doesn't work well, can be used for 
text, as well.

The pre-cache method was certainly for Charles NOT his primary way of 
working, thus the 10 MB default cache size which in new-pan until 
recently didn't even have a GUI config option, you had to directly edit 
the config file to increase it.  I don't actually know what the current 
devs use or if they do binaries at all (tho HM's quick addition of the 
binary uploading feature suggests he probably does at least a little of 
that), but direct-download-and-save would appear to continue to be the 
predominate method.

Which would leave pre-cache functionality less tested, at least at the 
first testing level, by the devs themselves.

Which brings us to what may be the issue.  For those who primary do 
direct-save, the pre-cache functionality is a bit of an afterthought.  
I'm quite sure it wasn't in the original "actions" proposal all those 
years ago, but as I used it myself, when I (re)proposed actions in the 
post that became the trigger for HM's implementation, I requested it.  Of 
course, that was only a few months ago and I've not actually done 
binaries in years, so I've not actually tested the new functionality to 
see how it compares against the proposal.

So here's what I suspect might be happening:

When HM did his implementation, he probably coded and tested the download-
and-save function first.  As you've likely observed, when you save 
attachments pan marks the post as read.

He then probably took the pre-cache code from the direct-save code, and 
just cut out the save.  I don't think I ever specified that the pre-cache 
action wasn't supposed to mark-read, as it didn't occur to me that it 
would.  And if he normally uses direct-save, not pre-cache, it probably 
didn't occur to him that pre-caching shouldn't mark-read as direct-save 
obviously did, so he didn't think to skip that bit when he skipped the 
save step on the pre-cache implementation.

That would be a bug, but as I said, this is a relatively new feature, one 
that I (re)requested but haven't actually tested as I haven't done 
binaries in years[1], so you're the first to report it.

Make sense?

----
[1] I keep trying to say I don't do binaries any more, but that's not 
quite right in the figurative sense even if it (currently) is in the 
literal, so I keep changing it to haven't done... .  It's not that I ever 
decided /not/ to.  It's simply that I /really/ enjoy text group 
discussion, and that and other things just gradually took the time that I 
had been doing binaries with.  Of course, now days ISPs don't generally 
provide news service like they used to, and I long ago let the paid 
subscription that I've occasionally carried drop, so the barrier to 
getting back into it is higher than it used to be, but I still /think/ of 
myself as a binary user, even if I've not done it in years and don't have 
a way to do it now without doing the whole account signup thing again.  
All I have now is the gmane list2news service, primarily text discussion 
of course, tho there's the occasional screen shot or whatever, where I do 
this list/newsgroup, among others.

If I /did/ get back into it, and I've been thinking about it, I'd 
probably go with one of those big unexpiring block accounts, say a TB for 
$100 or whatever (blocknews.net or astraweb.com, astra seems to have 1000 
gig for $50, now).  If I continued to do primarily text, that would 
likely hold me for life... or until the nntp services went the way of 
gopher servers, anyway.  It'd almost certainly last me well over a year, 
two and a half-ish even if I got back into the gig-a-day or so I used to 
do, making that a better choice than trying to do even a relatively cheap 
per-month thing.

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-22T08:56:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13412">
    <title>Re: cached articles marked as read?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13412</link>
    <description>&lt;pre&gt;Duncan posted on Tue, 22 May 2012 06:37:19 +0000 as excerpted:


[History deleted...]

OK, looking at the actions tab in preferences, I now see that the text 
description isn't quite as clear as I envisioned.  I'm not sure if the 
functionality works the way I had envisioned, or more like it actually 
states.  As I said in the previous post, while I (re)described from and 
old discussion what HM implemented, I've not actually tested it as I 
haven't done binaries in years and text doesn't really need at least the 
auto-cache/download as much.

The way it's /supposed/ to work, you tell me if it does...

The four actions work on scores (that much should be clear), with each 
acting independently of the others, except of course that if a message is 
deleted, that's obviously it, the other actions won't have a chance to 
take place.

The two "negative" actions, delete and mark-read, are supposed to work on 
messages scored AT OR BELOW the specified score category, while the two 
positive actions, cache and download, should work with messages scored AT 
OR ABOVE the specified score categories.  The AT OR BELOW, AT OR ABOVE 
bit isn't clear in the current interface, and as I've not tested, I 
actually don't know if it works that way or not, but that's how it's 
SUPPOSED to work.

So if you set CACHE articles scoring at... zero/new, then it should CACHE 
articles scored above zero as well.

Does it?

Meanwhile...

You didn't specifically mention... what are the other three actions set 
to?  Are they all disabled, or do you have them set to a score category?  
Obviously, the mark-read action is the one we're most interested in here, 
but deleted would also have potential to interfere.  Just making sure we 
don't have unintended interference.

The general idea, meanwhile, was to allow something like this:

Automatically:

Delete messages scoring at or below: [-9999] (ignored)

Mark-read messages scoring at or below: [-1] (negative)

Cache messages scoring at or above: [0/new] (all not negatively scored)

Download attachments for messages scored at or above: [+9999] (watched)


But, by having the configuration available, people who wanted to could 
disable all actions, or for instance set delete on anything negative, 
auto-mark-read 0, leave +1 to +9998 alone, and auto-cache (for text) or 
auto-save-attachments (for binaries) watched.

Of course, that would also allow someone to set both delete up thru +9998 
and auto-save down thru zero, if they wanted, which obviously couldn't 
work, as the messages in the overlap would be deleted before they could 
be saved.  But we trusted people to be smart enough not to do stuff like 
that, except possibly for testing, to see that it would actually delete 
before save and not crash or something.

Also, not directly related, but *IMPORTANT:*

Pan's cache is only 10 MB by default.  For binary message caching, you 
*WILL* need that larger.  While that's a decent number of text messages, 
if you're trying to cache binaries at all, that's TINY!

I routinely run a cache of several gigs for both my text and binary 
instances (which I keep separate).  On the text instance, I have messages 
set to never expire, with a multi-gig cache (tho only a bit less than a 
gig actually used) to ensure that my text message archive of several 
years stays around.

Back when I ran binaries, I had an entire partition of some 12 gigs 
dedicated to binary cache.  My routine was to grab overviews/headers, 
download a message here or there to get a sample, delete what I knew I 
didn't want, and set the rest to download to cache.  Then I'd go to work 
or to sleep or whatever and come back later, when everything was cached 
locally, to sort thru things and actually save them off somewhere, or 
delete them.  I remember when I first started with pan, being confused 
because I had set it to download a bunch of stuff, but when I came back, 
very little of it was still there, because the cache was only 10 MB and 
it had deleted stuff as fast as it came in, after that!

By contrast, the original intent (from long before pan even had scoring) 
was obviously to have people directly download and save off attachments.  
For that, a 10 MB cache is generally sufficient, enough to decode and 
save off the binary as it reaches completely cached, then delete the 
individual message parts composing it to make room for the next one.

So, if you're caching binaries, be *SURE* you have pan's cache (first 
page of prefs, behavior) set large enough for the binaries you want to 
cache!

But if none of that's the problem I think I might know what is.  Next 
post...

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-22T07:27:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13411">
    <title>Re: cached articles marked as read?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13411</link>
    <description>&lt;pre&gt;Vito 'ZeD' De Tullio posted on Mon, 21 May 2012 20:02:36 +0000 as
excerpted:


This is quite new code, this year, and hasn't had a lot of testing yet.  

"Old-pan", 0.14.x (the old C code, before the C++ rewrite) had what it 
called "rules", that allowed various automatic actions including mark-
read, delete, auto-cache, auto-download (plus some others like expiry 
that are handled entirely differently in the C++ rewrite) to be 
programmed based on scores, age of posts, etc.

Until this year (or perhaps late last year), that was about the only 
feature of old-pan that didn't have a corresponding new-pan version as 
well.  That changed with the introduction of actions.

But in the mean time, pan's long-time primary/lead developer and the 
person that undertook the rewrite in the first place, Charles Kerr, moved 
on to other things.  For many years pan development was all but 
abandoned, until KHalay and now Heinrich Mueller, along with Petr Kovar 
as release manager, keeper of the pan website and official Gnome 
representative, brought back pan from "the dead".  Heinrich's the guy who 
has taken the strongest interest in actually adding new features, 
including this one.  (I'm also a long-time pan guy as you can see by the 
history here, but I'm not a coder, so most of my activity is here on this 
list trying to contribute where my skills let me, and after around a 
decade at it with the original coders gone and new ones come, I've been 
described as pan's institutional memory, as well.)

Meanwhile, the reason no parallel to "rules" was committed to the rewrite 
back when Charles was still in charge was that he thought the way rules 
worked was too complex and confusing to configure (with some reason, we 
had a lot of questions on it, and I'd guess it was one of the least used 
features /because/ rules were so hard to work with, back then), and we 
needed a simpler interface to expose that automation.

There was some discussion of the idea back then that ended up with 
roughly the interface idea as currently implemented, and both Charles and 
I agreed that it was much easier and more intuitive to work with than the 
old rules interface.

Unfortunately, by that time Charles was losing interest and about to move 
on, and pan code sat basically abandoned for a couple years, the 
interface sort of decided but never implemented.

Which brings us almost to the present "new" implementation.  People kept 
asking for some way to automate such things, and personally, I always 
thought that ignored posts should at least be automatically marked read 
if not deleted, so when it came up again probably late last year, I again 
explained (as I had a number of times before) the GUI idea that had been 
discussed those several years ago, but that it had never been 
implemented...

Well, being the "lets stop wasting time and just code it" guy he is, 
Heinrich took that as an invitation to implement. =:^)  He's actually 
implemented quite a few new features as well, including the other long 
requested feature, binary uploading.  After all those long years waiting 
and discussing and explaining, I still have a hard time actually 
believing these features are actual reality, now, but they're still new 
enough not all the bugs have been worked out.

As to this actual feature, while I was the one who (re)described the 
interface and functionality as pan now implements it, I've not actually 
been active with binaries in years.  These days I mostly use pan on gmane, 
to follow various mailing lists such as this one, so my use is nearly all 
text, and with a reasonably good cable internet connection, I simply 
download messages on-demand, to read and reply to as necessary.

So while I (re)proposed the user interface and functionality, I've not 
actually tested it.  And I've not seen many other regulars mention it 
either.  So I'm not actually sure that the implementation actually works 
as intended.

You're really the first actual usage feedback I've seen on it!  That 
means you can help us fix it, tho I'm not yet sure whether it's the 
functionality that's not quite right, or whether it's not quite as 
intuitive as I (and whoever actually came up with the idea originally, it 
was long enough ago I'm honestly not sure if it was me or someone else) 
had hoped.

With that, the history's out of the way.  But my computer isn't quite 
stable these days, so let me send this before I crash, then I'll take a 
closer look at your actual question, and we'll see if it's your 
understanding that's not correct, or a bug in the still new 
implementation.  More coming!

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-22T06:37:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13410">
    <title>cached articles marked as read?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13410</link>
    <description>&lt;pre&gt;Hi.

I have a bad connection, and I want to automagically fetch all new 
headers + body of the newsgroup I subscribed.

I found at "Edit" -&amp;gt; "Edit preferences" -&amp;gt; "Actions" a way to cache new 
articles, settings the value "Only new (score == 0)" at the third drop 
down menu (labeled "Cache articles scoring at").


Unfortunately, I found that the messages are also marked as read! If I do 
&amp;lt;shift&amp;gt;+a ("get new headers in subscribed news") I can see the layout 
pane with some new messages, but if I select a newsgroup I found no 
unread messages! 


Is this intentional? Is a bug? Is there a "correct" way to cache all new 
messages in all subscribed groups?

Thank you

&lt;/pre&gt;</description>
    <dc:creator>Vito 'ZeD' De Tullio</dc:creator>
    <dc:date>2012-05-21T20:02:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13409">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13409</link>
    <description>&lt;pre&gt;Ed Fletcher posted on Sat, 19 May 2012 22:24:21 -0300 as excerpted:


FWIW, much has changed since then... in all of Linux, and in computers in 
general.  Quad-cores with 8 gigs RAM are almost standard, now days, 
parallel makes are standard as well, and they GREATLY speed up the build 
process.  I first switched to gentoo with a dual socket first gen opteron 
and a gig of ram, and remember kde (alone) taking about a day (8-ish 
hours) to build and install.  Now days (with the same mobo and dual-
socket, but upgraded to top-of-their-line dual-core opteron 290s, so 2x2-
core, with six gig ram, with the scratch build space in in tmpfs/ram as 
well)  I do an a kde upgrade in about two hours, three for the first in a 
series (4.x.0 except that I've been running the betas and rcs recently as 
well, so 4.(x-1).80) or if something goes wrong that I need to fix and 
redo some of the builds that failed as a result.  2-3 hours means I can 
do other things that day as well.  And a full emptytree world rebuild is 
only about a day.

The first gentoo install I tried wasn't quite 10 years ago yet, 2004.0.  
But it was the first one to have NPTL (now standard, native POSIX 
threading libraries, instead of the old Linux-threads), and I was trying 
to build directly to it, and failed.  So I stuck around on the lists and 
answered questions where I could for a couple months, learning all the 
time, and I still don't know what they fixed but 2004.1 installed just 
fine. =:^)

Now days of course they have automated weekly-updated stage-three 
snapshot builds.  I've done a couple of those, one in a 32-bit chroot on 
my main machine, building for my gen 1.5 acer aspire one netbook (before 
the netbooks switched to that stupid chipset with the graphics Intel 
outsourced and thus couldn't do proper freedomware drivers for), a couple 
for a friend.  Stage-3 builds are much easier, and the weekly snapshots 
means that they're pretty current, too.  For stable users (I always run ~/
testing, here), it means that first rebuild is generally the same version 
or a very small update, and "just works".

But I never tried gentoo on a single-core under a gig of ram (except on 
my netbook, but I build for it in a chroot on my quad-core) and I'd not 
recommend it.  Even dual-cores require a lot of patience, and you really 
do want a gig per core these days, so a dual-core should be two-gigs, 
minimum, ram-wise.  The quad-core with 6 gigs on my main rig is quite 
reasonable.  Below that, you'll need quite a bit of patience, and below 
dual-core w/ 2 gig ram, I'd not recommend for newbies at all, unless 
they're masochists.  Unless you have a bigger machine to build on as I do 
for my netbook, that's binary distro territory.  But on a modern quad-
core, 4+ gigs ram, I'd argue that an automated build-from-source like 
gentoo is ideal, the best of both worlds, the flexibility of building 
from source, with the automation of setting it up the way you want and 
then upgrades are less trouble than they'd be elsewhere, as the builds 
might take a bit more time but they're all automated, and the rolling 
release bit means a few upgrades at a time, no huge new distro version 
flag-days where you never know what broke that which was working just 
fine, before.

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-20T19:07:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13408">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13408</link>
    <description>&lt;pre&gt;Am Sat, 19 May 2012 20:38:18 -0300 schrieb Ed Fletcher:


unlink hasn't got anything to do with ssl, it's a standard lib routine.
the fact that the compiler doesn't know about it means a missing include 
_or_ something very strange going on with your include paths.
can you try to add a "#include &amp;lt;unistd.h&amp;gt; on the top of cert-store.cc and 
see if this error persists?

thanks
&lt;/pre&gt;</description>
    <dc:creator>Heinrich Müller</dc:creator>
    <dc:date>2012-05-20T07:08:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13407">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13407</link>
    <description>&lt;pre&gt;

There is another, much more crude, unsanctioned, and possibly deadly fix 
for this. But I used it and I'm not dead yet, nor has Pan crashed or 
behaved psychotically or sent dragons to flash-fry and eat me or anything.

Namely, lie. My primary Pan system is still using Fedora 15 and a 
formidable combination of sloth and inertia prevent me from upgrading it 
to F16, and the gnutls in F15's repos is 2.10.5.

So I changed configure.in line 53 to read: GNUTLS_REQUIRED=2.10.5

...after the git pull but before ./autogen.sh

Heinrich said he had segfaults with earlier gnutls versions, but I 
haven't, through numerous builds including 0.137, and I'm currently using 
Pan 0.138 Der Gerät (GIT bb6d29a git://git.gnome.org/pan2; i686-pc-linux-
gnu).

So I heartily endorse lying about gnutls ;-)



_______________________________________________
Pan-users mailing list
Pan-users&amp;lt; at &amp;gt;nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
&lt;/pre&gt;</description>
    <dc:creator>Lacrocivious Acrophosist</dc:creator>
    <dc:date>2012-05-20T04:29:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13406">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13406</link>
    <description>&lt;pre&gt;
I did edit the gnutls.pc and gnutls-extras.pc files, but not correctly. 
  I (think) I've now got them the way they should be.  And I moved the 
include files, as I did the 2.12.7 libs.  But it still fails to compile. 
  I think I'm going to throw in the towel and wait for Slackware-current 
to get a newer version of GnuTLS.  I don't want to end up with a system 
that has more problems than I know how to fix.  Right now, I can still 
put everything back where it belongs.  And pan compiled just fine 
without the gnutls flag.  So I think I'll stick to using stunnel for a 
little while longer.

I tried Gentoo a long time ago.  Like ten or twelve years, I think, 
maybe more.  The only thing I can remember from that experience is that 
after four or five days of compiling absolutely everything multiple 
times, I never did get a system that I could use.  I would think that 
it's a lot better now.

Thanks very much for your help.  And thanks to everyone else who chipped 
in with advice.

As Schwarzenegger said, I'll be back.

Ed
&lt;/pre&gt;</description>
    <dc:creator>Ed Fletcher</dc:creator>
    <dc:date>2012-05-20T01:24:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13405">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13405</link>
    <description>&lt;pre&gt;Ed Fletcher posted on Sat, 19 May 2012 20:38:18 -0300 as excerpted:



Yes, cert-store has to do with storing the certificates pan receives for 
a secure connection, so indeed, it's ssl-related.

My guess is that it's still finding the old include files since you 
didn't mention moving them or editing the *.pc file.  The *.pc file 
should give the correct paths, but in the actual compilation, it's likely 
the system paths are coming first, in ordered to be able to find other 
libs, so the build is using the headers in those system paths, which are 
still the old headers since that version wasn't removed.

Meanwhile, in the other subthread you mentioned possibly building the new 
version, pointed at the system location, thereby replacing the old one 
already there.  That should work for pan since you're rebuilding it now, 
but do be aware that it may well break other apps/libs depending on 
gnutls.  They'd likewise be fixed with a rebuild (possibly with a patch 
or of a newer version), but I'd at least check to see what packages you 
actually have linked against gnutls, so you have some idea of how big the 
hole you're digging might get.

That's one good thing about gentoo and similar managed-build-from-source 
distros.  Since everything's built from source, and at least gentoo has a 
tool called revdep-rebuild that can automatically scan for such broken 
dependencies and tell you what to rebuild, breaking such dependencies due 
to update is no big deal, you simply run the tool and let it rebuild what 
it needs to, afterward, and since everything's built from source already, 
there's no worry about having to manually bring in whole lists of missing 
build dependencies and resolve everything one manual build and test at a 
time.  I remember running mandrake and having to do that manually, and 
how nice it was when I first started on gentoo, having it all "just 
work", because the whole set of assumptions were different when you were 
building /everything/ from sources.

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-20T00:04:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13404">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13404</link>
    <description>&lt;pre&gt;
Bingo!  Found /usr/local/lib/pkgconfig/ with the two files in it.  Moved 
them to /usr/lib64/pkgconfig/ and now the ./configure file in pan can 
see the newer version of GnuTLS.

Hmph.  Now make fails:

make[3]: Entering directory `/root/pan2/pan/data'
   CXX    article.o
   CXX    article-cache.o
   CXX    encode-cache.o
   CXX    cert-store.o
cert-store.cc: In member function 'void 
pan::CertStore::remove_hard(const pan::Quark&amp;amp;)':
cert-store.cc:302:22: error: 'unlink' was not declared in this scope
make[3]: *** [cert-store.o] Error 1

I take it from the cert-store.o that it something to do with TLS.  Maybe 
I broke something by moving the files around by hand.

Ed
&lt;/pre&gt;</description>
    <dc:creator>Ed Fletcher</dc:creator>
    <dc:date>2012-05-19T23:38:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13403">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13403</link>
    <description>&lt;pre&gt;
Ok, we're closing in on this.

I have all the new libs, 20 of them, in /usr/local/lib.  And there's 
nothing else in there.  I have 16 old libs in /usr/lib64.  If I delete 
the old ones and move the new ones to /usr/lib64, will that do it or 
will I break something else?

Or should I recompile the GnuTLS package with a pointer to the correct 
location?  ./configure --prefix=/usr  But I'm not sure they wouldn't end 
up in /usr/lib rather that /usr/lib64

I just tried moving them and pan still configure still won't recognize 
gnutls v2.12.19.  It still sees v2.12.7 for some reason.

Ed
&lt;/pre&gt;</description>
    <dc:creator>Ed Fletcher</dc:creator>
    <dc:date>2012-05-19T23:14:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13402">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13402</link>
    <description>&lt;pre&gt;Ed Fletcher posted on Sat, 19 May 2012 18:29:58 -0300 as excerpted:


Often/normally from pkgconfig files, which are replacing the old libtool 
methods, etc.

Look in /usr/lib(64)?/pkgconfig/ (standard location, distro may change 
it) for a gnutls.pc file.  Whatever that's pointing to is very likely to 
be what's detected.  Also check the include files at (again, standard 
location) /usr/include/gnutls/* , as those are likely to be the headers 
built against.

FWIW, gentoo doesn't have anything even /close/ to that old still in the 
tree at all.  The oldest version, stable on all archs, is 2.12.18.  Also 
available are 2.12.19 and 3.0.18 and 3.0.19, with the last one the one 
I'm using for pan (and everything else depending on gnutls) here.  
However, there were some dependency changes around the 2.12.16 or so 
point -- gnutls started depending on nettle -- and between that and minor 
changes that require patching older versions of many packages depending 
on gnutls, it took awhile for distros to bump beyond that, and you appear 
to be on an older one that hasn't, yet.

I actually unmasked the newer versions here, as pan needed the latest 
(3.0.12 or some such) when it first switched from the initial openssl 
secure connection implementation (openssl is problematic for gpled apps 
like pan due to gpl incompatibilities in its license, so most of the 
distros would have failed to activate the security option if pan had 
stayed with openssl, in ordered to actually be able to legally distribute 
it).  In ordered to do that, I had to dig up patches and apply them or 
unmask newer versions of some of the other gnutls depending packages, in 
ordered to get them to build.  AFAIK I still have one (claws-mail) that I 
have to revert to an older gnutls in ordered to be able to build, then I 
can upgrade gnutls again and the app will run, it just won't build with 
the newer version yet.  Fortunately, after he got the initial 
implementation working, HM was able to relax the gnutls requirements a 
bit, but obviously it's still too high for what slack is running ATM.

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-19T23:07:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13401">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13401</link>
    <description>&lt;pre&gt;
My guess is you now have both installed (maybe in different places) and 
it's finding the older one first. I don't know what package manager 
slackware uses (it had none when I last used it but that was a very long 
time ago). In Debian or Ubuntu, you can go into synaptic and see right 
away what version you have, but here's another way (I'm sure there must 
be better ways): Go into /usr/lib (or probably /usr/lib64 if you have a 
64-bit system) and do something like:

  find . -name 'libgnutls*' -print

In my case, that showed me that I'm getting it out of 
/usr/lib/i386-linux-gnu.
One of the files in there is libgnutls.a. So I did this:

  strings libgnutls.a | grep ^Version

That showed several lines, but the interesting one was:

  Version: OpenPrivacy 2.12.14%s

which agrees with what synaptic told me my version was. Do the same thing 
in /usr/local/lib (or /usr/local/lib64) and see if there's another one 
there. If you built 2.12.19 from source, that's probably where it is 
since /usr/local is normally the default prefix. Now, if you do have more 
than one version, maybe you can delete the older version (watch out for 
dependencies -- a package manager would help here). I don't know whether 
you can use LD_LIBRARY_PATH to tell configure where to look first, if you 
need to keep both versions.
&lt;/pre&gt;</description>
    <dc:creator>David Shochat</dc:creator>
    <dc:date>2012-05-19T22:08:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13400">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13400</link>
    <description>&lt;pre&gt;

On 05/18/2012 11:09 PM, David Shochat wrote:

It turns out that Slackware come with GnuTLS v2.12.7 and Pan needs 
2.12.10 or greater.  (I never saw the error until I read config.log.) 
So I've installed GnuTLS v2.12.19 but the configure script is still 
picking up 2.12.7 for some reason.

Requested 'gnutls &amp;gt;= 2.12.10' but version of GnuTLS is 2.12.7

Where does configure get the version information?

Ed
--
"Money is like manure; it's not worth a thing unless
it's spread around encouraging young things to grow."
- Thornton Wilder
&lt;/pre&gt;</description>
    <dc:creator>Ed Fletcher</dc:creator>
    <dc:date>2012-05-19T21:29:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13399">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13399</link>
    <description>&lt;pre&gt;
Did you remember to say --with-gnutls when you ran configure? It is not 
the default. If you did remember to do that, look at what it says about 
gnutls when configure is done. If it says "no", you have to look back to 
see what it wanted but did not find, install that, and try again.
&lt;/pre&gt;</description>
    <dc:creator>David Shochat</dc:creator>
    <dc:date>2012-05-19T02:09:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13398">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13398</link>
    <description>&lt;pre&gt;
On 2012-05-14, at 12:52 AM, Duncan &amp;lt;1i5t5.duncan-j9pdmedNgrk&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:


Ok, I found the configure script after installing gnutls dev packages.  It seemed to be set correctly (and no errors) but the compiled executable still didn't have an SSL option.  

However, due to some other larger problems, I've dumped Mint and am now using Slackware.  So I now have Pan 134 running over stunnel again.  

I have a fair bit of configuration to do and I have to relearn Slackware again while doing it.  (It's been years.)  But once that's done, I'm going to have another whack or two at this if only for my own satisfaction. 

Thanks to all.  I'll post again when I try to compile Pan with TLS (and it doesn't work for me).
&lt;/pre&gt;</description>
    <dc:creator>Ed Fletcher</dc:creator>
    <dc:date>2012-05-19T01:52:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13397">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13397</link>
    <description>&lt;pre&gt;Ed Fletcher posted on Sun, 13 May 2012 01:35:13 -0300 as excerpted:


There's a configure option to enable it, and of course you need an 
appropriate gnutls (with devel package if you're on a binary distro that 
splits them out) to link against.

At the appropriate point, try running ./configure --help to get a list of 
available options.

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-14T03:52:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13396">
    <title>Deleting headers  Was: Pan-users Digest, Vol 112,Issue 13</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13396</link>
    <description>&lt;pre&gt;jimmckenzie-ihVZJaRskl1bRRN4PJnoQQ posted on Sat, 12 May 2012 13:53:16
-0400 as excerpted:

jimmckenzie-ihVZJaRskl1bRRN4PJnoQQ posted on Sat, 12 May 2012 13:53:16
-0400 as excerpted:


Please don't top post, at least on the pan lists!  There's a reason pan
warns about it, and it's worthwhile noting that some of us use pan to do
our subscribed lists (via gmane.org's list2news service).

Digest mode makes it a bit tedious, but you can still edit to just the
post you are replying to, perhaps the segment of the post if it's a long
one like the ones I often post, and reply below that in context.  If you
don't do it, you just make the person replying do it to try to bring
things back into sanity, and they may instead decide it's simply not worth
the bother.

Below I did your work for you.


Can't follow instructions in the digest either, it seems.  Could you
follow instructions if I posted help?  Maybe we'll find out.

(Quoting level doctored.)




(reinserting the below quote in the context where it belongs)


Absent that option (and I've only been doing text groups where I keep
headers "forever" for some years, but I used to do it this way when I did
binaries), you can at least use the multi-select feature, to select a
whole group (or several) of headers at once, then hit delete just once for
the entire group.

The usual shift-click/ctrl-click multi-select functionality should work.
If you prefer keyboard-only, shift-arrow/ctrl-arrow (and space to select)
works.

You can change the column sort order and toggle threaded/unthreaded to get
better grouping.

Also note that actions (see preferences) can now take advantage of scores
to auto-delete ignored posts, for instance, as well as auto-download
watched and/or auto-mark-read negative-scores that aren't yet ignored...
but you can set the action to whatever score-zone you like.
That way, you don't have to ever see ignored posts at all, and they don't
sit there still marked unread if you have the view filter set to not show
them.  I THINK that feature made it into 0.136.  If not, you have
something to look forward to for the next upgrade. =:^)

&lt;/pre&gt;</description>
    <dc:creator>Duncan</dc:creator>
    <dc:date>2012-05-14T03:48:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13395">
    <title>Re: In Pan 0.136 is there a way to default to yes when deleting headers and it ask for a confirmation?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13395</link>
    <description>&lt;pre&gt;Am Sat, 12 May 2012 07:57:40 +0000 schrieb Bob:


This should be the appropriate option.
&lt;/pre&gt;</description>
    <dc:creator>Heinrich Müller</dc:creator>
    <dc:date>2012-05-13T13:25:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13394">
    <title>Re: SSL on Pan 137</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13394</link>
    <description>&lt;pre&gt;
On 2012-05-08, at 10:39 AM, Heinrich Mueller &amp;lt;eddie_v&amp;lt; at &amp;gt;gmx.de&amp;gt; wrote:

Hmm, I just tried compiling Pan myself using the 'git clone ...' info on pan.rebelbase.com/download/ and although I got an executable that runs, it doesn't have SSL either. It reports itself as version 0.138, btw. 

Did miss something?

Ed
_______________________________________________
Pan-users mailing list
Pan-users&amp;lt; at &amp;gt;nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
&lt;/pre&gt;</description>
    <dc:creator>Ed Fletcher</dc:creator>
    <dc:date>2012-05-13T04:35:13</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gnome.apps.pan.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gnome.apps.pan.user</link>
  </textinput>
</rdf:RDF>

