fetchmail-devel — Development related discussion

[fetchmail-devel] automake migration

[Matthias A. <ma...@dt...>]

Dear fellow hackers,

I've automake-ified fetchmail, but haven't commited the (huge!) change
set yet. The reason I've done this before 6.2.6 is that I have been
unable to compile the current intl/ stuff on Solaris and FreeBSD, and
haven't been able to fix this. So I was fed up, upgraded gettext,
switched to automake and voilà it works on SuSE Linux 8.2 x86 (with GCC
3.4 and ICC 8.0), on Solaris 8 SPARC (with GCC 3.4 and Sun Workshop) and
on FreeBSD 4.10 i386.

I believe I have tested this well, checked it is fully self-contained
and am confident that after the commit, the package will still build.

A bug the commit would also fix is the generation of text from HTML,
which can currently create empty files if lynx isn't installed.

Please let me know what you think.

Rob, does this get your OK? If you can tell me how to fork a branch and
commit that stuff to a branch, I'll do that, for the time being, I have
exported the repository to a directory and packaged it as
http://home.pages.de/~mandree/fetchmail/.hidden/fetchmail-6.2.6.svn+automake.tar.bz2

Building it after "autoreconf -is" with the software mentioned below
works for me:

This is what the new README.svn file reads:

| In order to be able to build from the subversion repository (working
| directory), some files need to be (re-)generated.
| 
| Note that these generated files will be shipped with "make dist",
| so the end user will not need these packages.
| 
| The prerequisite packages are:
| 
| - GNU autoconf >= 2.54
| - GNU automake >= 1.7
| - GNU gettext >= 0.13
| - GNU m4
| - bison or yacc
| - flex or lex
| 
| If you have these installed, type:
| 
| $ rm -r -f autom4te.cache
| $ autoreconf -i -s
| 
| This will take a while and may print a lot of messages containing
| "warning: unquoted definition of..." which are harmless.
| 
| After that, build as usual, with
| 
| $ ./configure --with-options
| $ make
| (become root)
| # make install-strip
| 
| -- Matthias Andree, 2004-06-18

This is what svn status prints:

D      ABOUT-NLS
A      Makefile.am
D      Makefile.in
A      README.svn
D      config.guess
D      config.sub
M      configure.in
A      dist-tools/Makefile.am
A      html2txt.sh
D      intl/ChangeLog
D      intl/Makefile.in
D      intl/VERSION
D      intl/bindtextdom.c
D      intl/cat-compat.c
D      intl/dcgettext.c
D      intl/dgettext.c
D      intl/explodename.c
D      intl/finddomain.c
D      intl/gettext.c
D      intl/gettext.h
D      intl/gettextP.h
D      intl/hash-string.h
D      intl/intl-compat.c
D      intl/l10nflist.c
D      intl/libgettext.h
D      intl/linux-msg.sed
D      intl/loadinfo.h
D      intl/loadmsgcat.c
D      intl/localealias.c
D      intl/po2tbl.sed.in
D      intl/textdomain.c
D      intl/xopen-msg.sed
A      m4
A      m4/Makefile.am
D      mkinstalldirs
D      po/Makefile.in.in
A      po/Makevars
M      po/ca.po
D      po/cat-id-tbl.c
M      po/cs.po
M      po/da.po
M      po/de.po
M      po/el.po
M      po/es.po
D      po/fetchmail.pot
M      po/fr.po
M      po/gl.po
M      po/ja.po
M      po/pl.po
M      po/pt_BR.po
M      po/sk.po
D      po/stamp-cat-id
M      po/tr.po

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] why one person hates fetchmail

[Brian C. <B.C...@po...>]

On Thu, Jun 17, 2004 at 01:08:38PM -0700, Perry Hutchison wrote:
> As long as we have the ability to hand off to a specified agent,
> I would think it preferable -- at least, more modular -- to use a
> different external agent for each type of local mail store, rather
> than to try to amalgamate the lot of them into fetchmail.  You can
> have fetchmail invoke the same local delivery program that sendmail
> would use to write to a maildir.

You still use *sendmail* ?? 

:-)

[fetchmail-devel] Re: why one person hates fetchmail

[Rob F. <rf...@fu...>]

Perry Hutchison wrote:
> > and the only way I can make a poll of account 2 is by editing the
> > config file before polling.
>
> I thought the cure for that sort of thing was to run two (or more)
> instances of fetchmail, each with a different setting of FETCHMAILHOME.

You must admit, though, that that's a bit of an ugly hack.

> > The config language is a nightmare, and pretty illogical (e.g.
> > settings which I think should be settable globally and inherited
> > by all accounts, like 'ssl' for example, aren't; and working out
> > which settings apply to hosts and which to users has had me
> > digging in the source code more than once).
>
> I haven't been reduced to digging in the source, but have had some
> trial and error finding out whether certain settings are "host" or
> "user".  This is largely a matter of incomplete documentation :(

Yeah, one big thing that we need to do is fix the documentation to separate 
the categories of settings.

Ideally I'd love to figure out a way to fix the config language to make 
this more explicit, but that has a lot of problems.  Fixing the docs would 
go a long way.

> > To be fair to fetchmail, in the olden days it *did* offer direct
> > to mailbox delivery, and it was ESR's decision that the design
> > would be made much cleaner by having delivery to a local SMTP
> > daemon instead. Then slowly, things crept back in like delivery
> > via a pipe to procmail, delivery by invoking an MTA command-line
> > directly, delivery by LMTP... but things I *actually* want, like
> > delivery to a Maildir, aren't there.

You could have procmail deliver to a maildir.

> As long as we have the ability to hand off to a specified agent,
> I would think it preferable -- at least, more modular -- to use a
> different external agent for each type of local mail store, rather
> than to try to amalgamate the lot of them into fetchmail.  You can
> have fetchmail invoke the same local delivery program that sendmail
> would use to write to a maildir.

True.  On the other hand....
ESR would hate the idea, but I actually think that maildir is a decent 
candidate for inclusion because it doesn't have the locking headaches that 
other formats have.

Of course, I was the one who successfully fought to get mda support put 
back into fetchmail after ESR removed it way back when.
-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

Re: [fetchmail-devel] why one person hates fetchmail

[Perry H. <phu...@be...>]

> ... In particular, I have
>
> poll pop3.mydomain.com  ... account 1 settings
> skip pop3.mydomain.com  ... account 2 settings
>
> and the only way I can make a poll of account 2 is by editing the
> config file before polling.

I thought the cure for that sort of thing was to run two (or more)
instances of fetchmail, each with a different setting of FETCHMAILHOME.

> The config language is a nightmare, and pretty illogical (e.g.
> settings which I think should be settable globally and inherited
> by all accounts, like 'ssl' for example, aren't; and working out
> which settings apply to hosts and which to users has had me
> digging in the source code more than once).

I haven't been reduced to digging in the source, but have had some
trial and error finding out whether certain settings are "host" or
"user".  This is largely a matter of incomplete documentation :(

> To be fair to fetchmail, in the olden days it *did* offer direct
> to mailbox delivery, and it was ESR's decision that the design
> would be made much cleaner by having delivery to a local SMTP
> daemon instead. Then slowly, things crept back in like delivery
> via a pipe to procmail, delivery by invoking an MTA command-line
> directly, delivery by LMTP... but things I *actually* want, like
> delivery to a Maildir, aren't there.

As long as we have the ability to hand off to a specified agent,
I would think it preferable -- at least, more modular -- to use a
different external agent for each type of local mail store, rather
than to try to amalgamate the lot of them into fetchmail.  You can
have fetchmail invoke the same local delivery program that sendmail
would use to write to a maildir.

Re: [fetchmail-devel] why one person hates fetchmail

[Brian C. <B.C...@po...>]

On Thu, Jun 17, 2004 at 12:44:07PM -0400, Rob Funk quoted:
> For me, getting fetchmail to do this was far from trivial, but then I
> have to admit I do not find the fetchmail user interface (command line
> options and configuration file) to be at all intuitive, so I may not be
> understanding. I found that fetchmail did not seem to be happy about
> running multiple instances at once, about delivering directly to a
> Maildir, about having multiple independent POP accounts on the same
> host, and about running without a configuration file, all things which I
> think should just work right out of the box for a program called
> "fetchmail".

Yep, that's pretty fair. In particular, I have

poll pop3.mydomain.com  ... account 1 settings
skip pop3.mydomain.com  ... account 2 settings

and the only way I can make a poll of account 2 is by editing the config
file before polling.

The config language is a nightmare, and pretty illogical (e.g. settings
which I think should be settable globally and inherited by all accounts,
like 'ssl' for example, aren't; and working out which settings apply to
hosts and which to users has had me digging in the source code more than
once).

To be fair to fetchmail, in the olden days it *did* offer direct to mailbox
delivery, and it was ESR's decision that the design would be made much
cleaner by having delivery to a local SMTP daemon instead. Then slowly,
things crept back in like delivery via a pipe to procmail, delivery by
invoking an MTA command-line directly, delivery by LMTP... but things I
*actually* want, like delivery to a Maildir, aren't there.

Regards,

Brian.

[fetchmail-devel] why one person hates fetchmail

[Rob F. <rf...@fu...>]

This came up at LWN.net.... I thought it might be useful to bring it over 
here.  I have to admit I agree with at least a few of his complaints.

----------  Forwarded Message  ----------
> I'm interested in why you hate fetchmail.

Put succinctly, because I think it does not make simple things simple.
For example I would expect what I consider to be a trivial thing, get
new messages from a POP account and put them into a Maildir, to be
trivially simple, essentially something like

 fetchmail --mailbox my/maildir/path/ pop3://username:password@host

For me, getting fetchmail to do this was far from trivial, but then I
have to admit I do not find the fetchmail user interface (command line
options and configuration file) to be at all intuitive, so I may not be
understanding. I found that fetchmail did not seem to be happy about
running multiple instances at once, about delivering directly to a
Maildir, about having multiple independent POP accounts on the same
host, and about running without a configuration file, all things which I
think should just work right out of the box for a program called
"fetchmail".

-----------

[fetchmail-devel] Re: Putting the Debian package in the repository

[Graham W. <bo...@de...>]

On Wed, Jun 16, 2004 at 02:22:51AM +0200, Matthias Andree wrote:
> Graham Wilson schrieb am 2004-06-15:
> > The current Debian package of fetchmail is a patched version of
> > fetchmail, with the addition of a debian directory in the toplevel
> > of the source. Now, that development has picked up again, I'd like
> > to either merge or drop the Debian-specific patches into the trunk,
> > so that the Debian package only ends up as the trunk plus the debian
> > directory.
> > 
> > The reason I'd like to keep this in the same repository as fetchmail
> > is because it would make merging stuff from the Debian package to
> > and from the main fetchmail source easy. This will facilitate me
> > updating the Debian package, as well as me working on merging
> > Debian-specific patches into the trunk.
> > 
> > So, what do you guys think?
> 
> I don't have general objections - but let's review the patches first :-)

That was my plan. When I import the Debian source tree I can start
looking at the differences.

> I wonder if the Debian directory should also be here if that made
> sense.

The general consensus among other developers is that doing so is not a
good idea, since fixes only to the Debian directory might require new
releases. Also, those downloading the tarball, or checking out a copy
from CVS would have a Debian directory that they wouldn't be interested
in.

Additionally, I might (for some reason or other) need to patch the
fetchmail source tree in a way that only affects Debian, and I wouldn't
want to have to put the patch in the trunk.

-- 
gram

Re: [fetchmail-devel] Re: Putting the Debian package in the repository

[Matthias A. <mat...@gm...>]

Graham Wilson schrieb am 2004-06-15:

> The current Debian package of fetchmail is a patched version of
> fetchmail, with the addition of a debian directory in the toplevel of
> the source. Now, that development has picked up again, I'd like to
> either merge or drop the Debian-specific patches into the trunk, so
> that the Debian package only ends up as the trunk plus the debian
> directory.
> 
> The reason I'd like to keep this in the same repository as fetchmail is
> because it would make merging stuff from the Debian package to and from
> the main fetchmail source easy. This will facilitate me updating the
> Debian package, as well as me working on merging Debian-specific patches
> into the trunk.
> 
> So, what do you guys think?

I don't have general objections - but let's review the patches first :-)

I wonder if the Debian directory should also be here if that made sense.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Re: Putting the Debian package in the repository

[Graham W. <bo...@de...>]

On Fri, Jun 11, 2004 at 11:58:44PM +0200, Matthias Andree wrote:
> Graham Wilson schrieb am 2004-06-11:
> > I would like (if everyone agrees that it is alright) to put the Debian
> > package under version control with the rest of fetchmail at Berlios.
> > 
> > This would entail creating a branches/debian directory for the Debian
> > packaging branch. This would keep all Debian related changes specific to
> > this one branch directory. Under the directory would be (for example):
> 
> Is the branch a modified fetchmail version or a separate package? If it
> is separate, the branch may not be the optimal way to formulate what it
> is.

I am not sure what you mean, but I'll describe the current situation and
let you guys decide.

The current Debian package of fetchmail is a patched version of
fetchmail, with the addition of a debian directory in the toplevel of
the source. Now, that development has picked up again, I'd like to
either merge or drop the Debian-specific patches into the trunk, so
that the Debian package only ends up as the trunk plus the debian
directory.

The reason I'd like to keep this in the same repository as fetchmail is
because it would make merging stuff from the Debian package to and from
the main fetchmail source easy. This will facilitate me updating the
Debian package, as well as me working on merging Debian-specific patches
into the trunk.

So, what do you guys think?

-- 
gram

Re: [fetchmail-devel] Putting the Debian package in the repository

[Matthias A. <mat...@gm...>]

Graham Wilson schrieb am 2004-06-11:

> I would like (if everyone agrees that it is alright) to put the Debian
> package under version control with the rest of fetchmail at Berlios.
> 
> This would entail creating a branches/debian directory for the Debian
> packaging branch. This would keep all Debian related changes specific to
> this one branch directory. Under the directory would be (for example):

Is the branch a modified fetchmail version or a separate package? If it
is separate, the branch may not be the optimal way to formulate what it
is.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Putting the Debian package in the repository

[Graham W. <bo...@de...>]

I would like (if everyone agrees that it is alright) to put the Debian
package under version control with the rest of fetchmail at Berlios.

This would entail creating a branches/debian directory for the Debian
packaging branch. This would keep all Debian related changes specific to
this one branch directory. Under the directory would be (for example):

 $ svn ls svn+ssh://svn.berlios.de/svnroot/repos/fetchmail/branches/debian
 6.2.5-9
 6.2.6-1
 current

where current is the current Debian package (unreleased) and the other
listings are tags for older Debian packages. 

Thoughts?

-- 
gram

[fetchmail-devel] Re: fetchmail loaded into berlios svn repository; mailing lists

[Matthias A. <ma...@dt...>]

Rob Funk <rf...@fu...> writes:

> Matthias Andree wrote:
>> Makefile.in.in is a generated file.
>
> In that case I guess we should remove it from svn.  I'm sure there are 
> more.  (I've already noticed that some diffs and .orig/.rej files made it 
> in there and should be removed.)

They're gone now:

|Deleting       fetchmail.diff
|Deleting       fr.po.orig
|Deleting       fr.po.rej
|Deleting       pl.po.orig
|Deleting       pl.po.rej
|
|Committed revision 3884.

I'm not comfortable with removing Makefile.in.in, it appears to have
local changes by ESR, and replacing it with the one from gettext 0.13
broke the build horribly. This is one of the files that needs a
"--force" to generate (in gettextize) besides that, as I figured.

IOW, this is delicate, I'm not touching it, for I know too little about
gettext and don't want to learn gettext this month if I can help it.

>> gettext.info suggests listing the source file rather than a generated
>> file, hence:
>> The newer autoconf versions are better, but I wonder if you would want
>> the bild super structure replaced, I'd suggest deferring that to 6.2.7.
>
> Of course, one problem with removing generated files from svn is that we 
> end up with different autoconf versions being used.  I have autoconf
> 2.59.

So do I.

>> I've commited the ok = 0 initialization in one change, the warning fixes
>> in another and haven't yet committed the POTFILES.in patch, different
>> suggestion above. It adds an xgettext warning but fixes the build.
>
> It'd be nice to get rid of the warning if possible, but if the resulting 
> code handles translation properly then it's probably no big deal.

We'd introduce more local changes into files that gettextize has
provided, which isn't very sensible as it is maintenance intensive.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] Re: [fetchmail]fetchmail loaded into berlios svn repository; mailing lists

[Rob F. <rf...@fu...>]

Matthias Andree wrote:
> Makefile.in.in is a generated file.

In that case I guess we should remove it from svn.  I'm sure there are 
more.  (I've already noticed that some diffs and .orig/.rej files made it 
in there and should be removed.)

> gettext.info suggests listing the source file rather than a generated
> file, hence:
>
> Index: po/POTFILES.in
> ===================================================================
> --- po/POTFILES.in	(revision 3883)
> +++ po/POTFILES.in	(working copy)
> @@ -18,7 +18,7 @@
>  opie.c
>  options.c
>  pop3.c
> -rcfile_y.c
> +rcfile_y.y
>  report.c
>  rfc822.c
>  rpa.c

That looks good to me.

> > Argh.  autoconf is great for the user, but quite a pain for the
> > developer.
>
> The newer autoconf versions are better, but I wonder if you would want
> the bild super structure replaced, I'd suggest deferring that to 6.2.7.

Of course, one problem with removing generated files from svn is that we 
end up with different autoconf versions being used.  I have autoconf 2.59.

> I've commited the ok = 0 initialization in one change, the warning fixes
> in another and haven't yet committed the POTFILES.in patch, different
> suggestion above. It adds an xgettext warning but fixes the build.

It'd be nice to get rid of the warning if possible, but if the resulting 
code handles translation properly then it's probably no big deal.

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

[fetchmail-devel] Re: [fetchmail]fetchmail loaded into berlios svn repository; mailing lists

[Matthias A. <ma...@dt...>]

Rob Funk <rf...@fu...> writes:

> Matthias Andree wrote:
>> - in pop3_getpartialsizes, we may return uninitialized data iff first >
>> last (I don't know if this can happen, but I'd like to make the function
>> itself surprise free.)
>
> Good plan.

Committed (separate from the warning fixes).

>> - in po/POTFILES.in we're effectively listing rcfile_y.c a second
>>   time. It is in Makefile.in.in with proper path (top_builddir) and in
>>   POTFILES.in again, which makes gettext's makefile prepend top_srcdir -
>>   which fails, because rcfile_y.c is generated and hence in builddir.
>
> Odd.  I wonder how got that way and how (if) it ever worked properly.  

It works when builddir = srcdir.

> There's no RCS history on either of those files, but they were like that 
> in 6.2.5.

Makefile.in.in is a generated file.

> Will the rcfile_y strings be properly translated if you do this?

Dunno. I presume yes becasue Makefile.in.in still lists the file, but
I have just failed at soldering gettext 0.13 into the build, so I'll
quit that, I'm not going to waste time here. We can use automake first.

> Wait a minute.... every other file listed in POTFILES.in already exists.  
> So I'm not sure that this is the proper fix....

gettext.info suggests listing the source file rather than a generated
file, hence:

Index: po/POTFILES.in
===================================================================
--- po/POTFILES.in	(revision 3883)
+++ po/POTFILES.in	(working copy)
@@ -18,7 +18,7 @@
 opie.c
 options.c
 pop3.c
-rcfile_y.c
+rcfile_y.y
 report.c
 rfc822.c
 rpa.c

>>  To reproduce the problem:
>>  make distclean
>>  mkdir build
>>  cd build
>>  ../configure
>>  make
>
> I can't get past the ../configure -- it keeps telling me I need to make 
> distclean in the source directory, even though I did.

Some file must be lying in the way, but I don't know which ../configure
tests for.

> Argh.  autoconf is great for the user, but quite a pain for the
> developer.

The newer autoconf versions are better, but I wonder if you would want
the bild super structure replaced, I'd suggest deferring that to 6.2.7.

>> Is this OK to commit?
>
> I generally prefer that separate issues be committed separately, but other 
> than POTFILES.in, this stuff looks good to me.  I'm still trying to figure 
> out the autoconf and gettext stuff so I can even see the rcfiles_y 
> problem.

I've commited the ok = 0 initialization in one change, the warning fixes
in another and haven't yet committed the POTFILES.in patch, different
suggestion above. It adds an xgettext warning but fixes the build.

> BTW, the uni-dortmund address you sent this from isn't subscribed to 
> fetchmail-devel so I had to approve the message there.

Subscribed & set to nomail.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Re: [fetchmail]fetchmail loaded into berlios svn repository; mailing lists

[Rob F. <rf...@fu...>]

Matthias Andree wrote:
> - in pop3_getpartialsizes, we may return uninitialized data iff first >
> last (I don't know if this can happen, but I'd like to make the function
> itself surprise free.)

Good plan.

> - in po/POTFILES.in we're effectively listing rcfile_y.c a second
>   time. It is in Makefile.in.in with proper path (top_builddir) and in
>   POTFILES.in again, which makes gettext's makefile prepend top_srcdir -
>   which fails, because rcfile_y.c is generated and hence in builddir.

Odd.  I wonder how got that way and how (if) it ever worked properly.  
There's no RCS history on either of those files, but they were like that 
in 6.2.5.

Will the rcfile_y strings be properly translated if you do this?

Wait a minute.... every other file listed in POTFILES.in already exists.  
So I'm not sure that this is the proper fix....

>  To reproduce the problem:
>  make distclean
>  mkdir build
>  cd build
>  ../configure
>  make

I can't get past the ../configure -- it keeps telling me I need to make 
distclean in the source directory, even though I did.

Argh.  autoconf is great for the user, but quite a pain for the developer.

> The rest is just word flipping to shut up GCC 3.4.

Definitely a good thing.

> Is this OK to commit?

I generally prefer that separate issues be committed separately, but other 
than POTFILES.in, this stuff looks good to me.  I'm still trying to figure 
out the autoconf and gettext stuff so I can even see the rcfiles_y 
problem.


BTW, the uni-dortmund address you sent this from isn't subscribed to 
fetchmail-devel so I had to approve the message there.
-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

[fetchmail-devel] Re: [fetchmail]fetchmail loaded into berlios svn repository; mailing lists

[Matthias A. <ma...@dt...>]

NB: please CC: all replies to this mail.

Rob Funk <rf...@fu...> writes:

> 3. Eric's release scripts include lots of things that were intended for his 
> environment but will not work at all in the new environment.  This is the 
> first thing that will need to be fixed.  After this is fixed, we should be 
> about ready for a 6.2.6 release.

I have some patches I'd like to commit before 6.2.6, two important, the rest
trivial and cosmetic to reduce screen scatter (compiler warnings) a bit.

The important ones are: 

- in pop3_getpartialsizes, we may return uninitialized data iff first >
last (I don't know if this can happen, but I'd like to make the function
itself surprise free.)

- in po/POTFILES.in we're effectively listing rcfile_y.c a second
  time. It is in Makefile.in.in with proper path (top_builddir) and in
  POTFILES.in again, which makes gettext's makefile prepend top_srcdir -
  which fails, because rcfile_y.c is generated and hence in builddir.

  To reproduce the problem:
  make distclean
  mkdir build
  cd build
  ../configure
  make

The rest is just word flipping to shut up GCC 3.4.

Is this OK to commit?

Index: getpass.c
===================================================================
--- getpass.c	(revision 3881)
+++ getpass.c	(working copy)
@@ -56,9 +56,9 @@
 #endif
 #endif
 
-void static save_tty_state(void);
-void static disable_tty_echo(void);
-void static restore_tty_state(void);
+static void save_tty_state(void);
+static void disable_tty_echo(void);
+static void restore_tty_state(void);
 static RETSIGTYPE sigint_handler(int);
 
 char *fm_getpassword(prompt)
Index: pop3.c
===================================================================
--- pop3.c	(revision 3881)
+++ pop3.c	(working copy)
@@ -219,7 +219,7 @@
 
 
 
-static int capa_probe(sock)
+static int capa_probe(int sock)
 /* probe the capabilities of the remote server */
 {
     int	ok;
@@ -916,7 +916,7 @@
 static int pop3_getpartialsizes(int sock, int first, int last, int *sizes)
 /* capture the size of message #first */
 {
-    int	ok, i;
+    int	ok = 0, i;
     char buf [POPBUFSIZE+1];
     unsigned int num, size;
 
@@ -1179,7 +1179,7 @@
     return(ok);
 }
 
-const static struct method pop3 =
+static const struct method pop3 =
 {
     "POP3",		/* Post Office Protocol v3 */
 #if INET6_ENABLE
Index: etrn.c
===================================================================
--- etrn.c	(revision 3881)
+++ etrn.c	(working copy)
@@ -119,7 +119,7 @@
     return(gen_transact(sock, "QUIT"));
 }
 
-const static struct method etrn =
+static const struct method etrn =
 {
     "ETRN",		/* ESMTP ETRN extension */
 #if INET6_ENABLE
Index: imap.c
===================================================================
--- imap.c	(revision 3881)
+++ imap.c	(working copy)
@@ -1110,7 +1110,7 @@
     return(gen_transact(sock, "LOGOUT"));
 }
 
-const static struct method imap =
+static const struct method imap =
 {
     "IMAP",		/* Internet Message Access Protocol */
 #if INET6_ENABLE
Index: odmr.c
===================================================================
--- odmr.c	(revision 3881)
+++ odmr.c	(working copy)
@@ -207,7 +207,7 @@
        return(PS_SUCCESS);
 }
 
-const static struct method odmr =
+static const struct method odmr =
 {
     "ODMR",		/* ODMR protocol */
 #if INET6_ENABLE
Index: driver.c
===================================================================
--- driver.c	(revision 3881)
+++ driver.c	(working copy)
@@ -69,8 +69,8 @@
 flag peek_capable;	/* can we peek for better error recovery? */
 int mailserver_socket_temp = -1;	/* socket to free if connect timeout */ 
 
-volatile static int timeoutcount = 0;	/* count consecutive timeouts */
-volatile static int idletimeout = 0;	/* timeout occured in idle stage? */
+static volatile int timeoutcount = 0;	/* count consecutive timeouts */
+static volatile int idletimeout = 0;	/* timeout occured in idle stage? */
 
 static jmp_buf	restart;
 
Index: po/POTFILES.in
===================================================================
--- po/POTFILES.in	(revision 3881)
+++ po/POTFILES.in	(working copy)
@@ -18,7 +18,6 @@
 opie.c
 options.c
 pop3.c
-rcfile_y.c
 report.c
 rfc822.c
 rpa.c


-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Greetings and some patches

[Brian C. <B.C...@po...>]

Hello, just subscribed to the new list on Berlios. Only annoying thing is
that all the links point to https://lists.berlios.de/, but it doesn't have
a valid certificate. So in lynx at any rate, I get 
SSL error:unable to get local issuer certificate-Continue? (y) 
every time I follow a link.

Anyway, attached is my current small set of patches against 6.2.5. There's a
short description of what they do at the top; a much longer description was
posted to the old fetchmail-friends a couple of months ago.

Regards,

Brian.

RE: [fetchmail-devel] fetchmail loaded into berlios svn repository; mailing lists

[Rob <rob...@ho...>]

> -----Original Message-----
> From: fet...@be... 
> [mailto:fet...@be...] On Behalf Of Rob Funk
> 
> Oh, we'll also need to set up a web page, which will be at 
> http://fetchmail.berlios.de/.  Eric's old web page would be a good 
> starting point, but would need editing.  It would be nice if 
> we could have that done for the 6.2.6 release.

My raw HTML is a little rusty these days (getting to used to using
Fusion), but if nobody else steps forwards I'll volunteer to put
something together.


PLEASE - keep list traffic on the list.  Email sent directly to me may
be ignored utterly.

-- 
Rob | What part of "no" was it you didn't understand? 

[fetchmail-devel] Re: fetchmail loaded into berlios svn repository; mailing lists

[Eric S. R. <es...@th...>]

Rob Funk <rf...@fu...>:
> Oh, we'll also need to set up a web page, which will be at 
> http://fetchmail.berlios.de/.  Eric's old web page would be a good 
> starting point, but would need editing.  It would be nice if we could have 
> that done for the 6.2.6 release.

That page in generated.  You actually want to edit the indexgen.sh script.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[fetchmail-devel] fetchmail loaded into berlios svn repository; mailing lists

[Rob F. <rf...@fu...>]

Thanks to Eric Raymond's cooperation, I've been able to load the fetchmail 
code into a Subversion repository at berlios.de, complete with his 
revision history going from the 1996 popclient days up to what he was 
about to release as fetchmail 6.2.6.

The berlios project page is:
  http://developer.berlios.de/projects/fetchmail/
Information about accessing the Subversion repository is at:
  http://developer.berlios.de/svn/?group_id=1824

There are some caveats about the code repository.

1. There were some files in Eric's tarball that were not under version 
control, and I tried to add the ones that were necessary without adding 
any generated files, but there may be a few extraneous or missing files.
2. Eric's torturetest script depends on a list of test servers that I've 
omitted from the repository since it has account passwords that should not 
be made public.  We'll need to figure out a way to deal with this.
3. Eric's release scripts include lots of things that were intended for his 
environment but will not work at all in the new environment.  This is the 
first thing that will need to be fixed.  After this is fixed, we should be 
about ready for a 6.2.6 release.


I've also set up new mailing lists at berlios.org:
fetchmail-announce
fetchmail-users
fetchmail-devel
fetchmail-svn

I've also requested the fetchmail-friends and fetchmail-announce email 
address lists from ccil.org, but had no reponse yet other than a promise 
to send them "later today" (which was almost a week ago). I still have 
hope, and have sent a reminder.


Oh, we'll also need to set up a web page, which will be at 
http://fetchmail.berlios.de/.  Eric's old web page would be a good 
starting point, but would need editing.  It would be nice if we could have 
that done for the 6.2.6 release.

-- 
==============================| "A slice of life isn't the whole cake
 Rob Funk <rf...@fu...> | One tooth will never make a full grin"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"