fetchmail-devel

[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"

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] 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] 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...>]

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

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