<?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://permalink.gmane.org/gmane.comp.gnome.apps.pan.user">
    <title>gmane.comp.gnome.apps.pan.user</title>
    <link>http://permalink.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/13415"/>
        <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: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/13415">
    <title>Re: cached articles marked as read?</title>
    <link>http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/13415</link>
    <description>&lt;pre&gt;
Great sNiping machine in use...
This will also do the 0/new.  Just make sure your cache is set high enough.
SnIP


Bob
&lt;/pre&gt;</description>
    <dc:creator>Bob</dc:creator>
    <dc:date>2012-05-24T12:45:35</dc:date>
  </item>
  <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 
fi&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 downl&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 Gno&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 &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'&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 &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&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&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)


Ab&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>
  <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>

