fetchmail-devel — Development related discussion

Re: [fetchmail-devel] Re: SVN woes :-(

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

Matthias Andree wrote:
> My access has been restored yesterday, the cause was that my home
> directory had world writable permissions and for some reason, SSH wasn't
> capable of properly logging this fact, it looked like I didn't know my
> password to the admin, so it took the admin, schily (Jörg Schilling, the
> cdrecord guy) rather long to figure.
>
> I haven't ever changed my home directory's permissions and never used
> the "chmod" command and am using a umask 0002, and it stopped working
> without prior warning, from one second to the next and without my doing
> anything else than svnadmin recover.

I've noticed that the home directories have tended to get other-writable 
permissions on their own way too often, as if one of their scripts has the 
sense of the permissions backwards.

I just checked and it looks fine now on my account, but not for 14 other 
users.  I wonder if their post-recovery scripts mess up.

-- 
==============================|   "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] Re: SVN woes :-(

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

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

> One is my general preference to avoid having anything dependent on a single 
> person.  On the other hand, it's starting to look like Berlios's SVN setup 
> is equivalent to an unreliable person we're dependent on.

My access has been restored yesterday, the cause was that my home
directory had world writable permissions and for some reason, SSH wasn't
capable of properly logging this fact, it looked like I didn't know my
password to the admin, so it took the admin, schily (Jörg Schilling, the
cdrecord guy) rather long to figure.

I haven't ever changed my home directory's permissions and never used
the "chmod" command and am using a umask 0002, and it stopped working
without prior warning, from one second to the next and without my doing
anything else than svnadmin recover.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: [fetchmail-devel] Re: SVN woes :-(

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

Graham Wilson wrote:
> If Rob agrees, I can probably get the repository set up pretty soon.

Can you set it up so that updates continue to get sent to the 
fet...@be... list?

-- 
==============================|   "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] Re: SVN woes :-(

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

Graham Wilson wrote:
> If Rob agrees, I can probably get the repository set up pretty soon.

I have two concerns.

One is my general preference to avoid having anything dependent on a single 
person.  On the other hand, it's starting to look like Berlios's SVN setup 
is equivalent to an unreliable person we're dependent on. If we grab 
regular dumps of the repository no matter where it is, then we can move 
whenever necessary.  (I made sure to grab a current dump last night, btw.)

The other concern is how confusing it would be to have the code hosted away 
from Berlios and everything else hosted there (or alternately whether we 
should move everything else too, which takes us back to concern #1).  Once 
we get an actual web page up, I suppose it shouldn't be too big a deal.

Ultimately I think I come down on the side of Go For It.  :-)

-- 
==============================|   "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: SVN woes :-(

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

On Wed, Jul 28, 2004 at 12:01:01PM +0200, Matthias Andree wrote:
> Graham Wilson <bo...@de...> writes:
> > I'd be more than willing to host the fetchmail Subversion repository on
> > my machine via Apache. The machine isn't too fast, but it is well
> > connected. Let me know what you guys think.
> 
> I can't estimate how much CPU horsepower SVN requires, otherwise, that
> would be fine with me but isn't my call.

I do fine with the handful of small repositories I have on there now.
Also, the load is pretty low on the machine, so I should have plenty of
processing capacity to spare.

If Rob agrees, I can probably get the repository set up pretty soon.

-- 
gram

Re: [fetchmail-devel] Re: SVN woes :-(

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

Graham Wilson <bo...@de...> writes:

> I'd be more than willing to host the fetchmail Subversion repository on
> my machine via Apache. The machine isn't too fast, but it is well
> connected. Let me know what you guys think.

I can't estimate how much CPU horsepower SVN requires, otherwise, that
would be fine with me but isn't my call.

Even "lowly" servers such as a P-II should suffice, I've looked after
such a server (P-II/233, 128 MB EDO RAM) with five regular and 30
occasional users over years that was mail
(SMTP+IMAP/SSL+POP3/SSL)/NFS/application/FTP/Apache (with CGI)/CVS
server, no problem - it was idling around 90%, not counting sendfile()
time though.

Its successor, an XP1700+ with 512 MB of RAM has spent 0.5% in each of
user and system space and 4% nice -- and only because it ran "john
-incremental" to reveal trivial passwords. The rest is idle time,
usually well above 97%.

The time when CPU horsepower matters is when the machine is either under
constant load or needs good response time for a bursty access profile.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: [fetchmail-devel] SVN woes :-(

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

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

> Matthias Andree wrote:
>> I've been rather patient with BerliOS in the past weeks, but their
>> service level isn't acceptable.
>
> I tend to agree.  I hold myself back from getting too upset with them by 
> remembering that they're providing a free service.

That free service has been as good as no service throughout those parts
of July when I had time to work on fetchmail.

>> Since last week, I'm (yet again!) unable to log into svn.berlios.de, so
>> no developer access SVN for me, and my local SVN refuses to switch to
>> anonymous SVN...
>
> At the moment my access seems fine.  I'm hoping to get back to work on 
> fetchmail later this week.

Yes, indeed it is SSH to cause my trouble, it crashed for me
last Thursday and I haven't been able to SSH into svn.berlios.de since,
neither straight with ssh nor via svn.

http://developer.berlios.de/support/?func=detailsupport&support_id=100927&group_id=1

>> It's now four days since I've filed "still doesn't work" -- add to that
>> the constant crashing of the data bases and a minor flaw in the SVN web
>> pages with major effect (the URLs lack the trailing /trunk/) that hasn't
>> been addressed in weeks.
>
> I'm willing to forgive the /trunk thing.  The totally ignored support 
> requests bother me, as does the extended inaccessability.

The forgotten /trunk/ makes an enormous difference - the difference
between checking out the tree once or checking out the tree for each and
every tag that it knows. That also contributes to server load. It's not
as though that was difficult to fix, two changes to a PHP document, see
http://developer.berlios.de/source.php?page_url=/svn/index.php

>> This isn't acceptable, how is development going to happen if we need to
>> recover the data base frequently, are cut off the SVN for several days
>> and so on?
>
> I wonder how much of this is subversion not really being ready, and how 
> much is Berlios not really being ready.

Reading the followups in this thread, it might be the svnserve stuff not
being ready, I'm not having any difficulties with the spamassassin or
subversion SVN services -- they don't use svn+ssh though but http.

And certainly BerliOS isn't ready if they're running a test phase
without anyone looking after the stuff.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: [fetchmail-devel] Re: SVN woes :-(

[Andreas <an...@co...>]

On Tue, Jul 27, 2004 at 05:26:56PM -0500, Graham Wilson wrote:
> However, I have been running Subversion locally for a year now, and
> recently via Apache over HTTPS and haven't had any trouble. This makes
> me think that the problem might be with svnserve.

Hmm. We use it via apache and mod_dav/mod_svn (in the setup I described
earlier).

[fetchmail-devel] Re: SVN woes :-(

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

On Tue, Jul 27, 2004 at 05:06:47PM -0400, Rob Funk wrote:
> Matthias Andree wrote:
> > This isn't acceptable, how is development going to happen if we need to
> > recover the data base frequently, are cut off the SVN for several days
> > and so on?
> 
> I wonder how much of this is subversion not really being ready, and how 
> much is Berlios not really being ready.

For reference, Debian uses Subversion (via svnserver over SSH, like
BerliOS) and has just as much trouble as we have been having. This makes
me think this is a Subversion problem.

However, I have been running Subversion locally for a year now, and
recently via Apache over HTTPS and haven't had any trouble. This makes
me think that the problem might be with svnserve.

I'd be more than willing to host the fetchmail Subversion repository on
my machine via Apache. The machine isn't too fast, but it is well
connected. Let me know what you guys think.

-- 
gram

Re: [fetchmail-devel] SVN woes :-(

[Andreas <an...@co...>]

On Tue, Jul 27, 2004 at 05:06:47PM -0400, Rob Funk wrote:
> I wonder how much of this is subversion not really being ready, and how 
> much is Berlios not really being ready.

subversion is ready. FYI, we use it here to host about 42Gb of data representing
dozens of thousands of rpm packages in source form.

Re: [fetchmail-devel] SVN woes :-(

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

Matthias Andree wrote:
> I've been rather patient with BerliOS in the past weeks, but their
> service level isn't acceptable.

I tend to agree.  I hold myself back from getting too upset with them by 
remembering that they're providing a free service.

> Since last week, I'm (yet again!) unable to log into svn.berlios.de, so
> no developer access SVN for me, and my local SVN refuses to switch to
> anonymous SVN...

At the moment my access seems fine.  I'm hoping to get back to work on 
fetchmail later this week.

> It's now four days since I've filed "still doesn't work" -- add to that
> the constant crashing of the data bases and a minor flaw in the SVN web
> pages with major effect (the URLs lack the trailing /trunk/) that hasn't
> been addressed in weeks.

I'm willing to forgive the /trunk thing.  The totally ignored support 
requests bother me, as does the extended inaccessability.

> This isn't acceptable, how is development going to happen if we need to
> recover the data base frequently, are cut off the SVN for several days
> and so on?

I wonder how much of this is subversion not really being ready, and how 
much is Berlios not really being ready.

> Can someone offer or recommend a more reliable Subversion hosting at
> another site?

If anyone comes up with anything I'd be happy to hear about it.

Sigh.

-- 
==============================|   "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] SVN woes :-(

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

Hi,

I've been rather patient with BerliOS in the past weeks, but their
service level isn't acceptable.

Since last week, I'm (yet again!) unable to log into svn.berlios.de, so
no developer access SVN for me, and my local SVN refuses to switch to
anonymous SVN...

I'd filed a support request last week, got a reply later that some
server (YP IIRC) got restarted and I should retry, but it hadn't helped,
which I immediately reported via the berlios support tracker.

It's now four days since I've filed "still doesn't work" -- add to that
the constant crashing of the data bases and a minor flaw in the SVN web
pages with major effect (the URLs lack the trailing /trunk/) that hasn't
been addressed in weeks.

This isn't acceptable, how is development going to happen if we need to
recover the data base frequently, are cut off the SVN for several days
and so on?

Can someone offer or recommend a more reliable Subversion hosting at
another site?

TIA,

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

[fetchmail-devel] RE: [fetchmail]Help with warning: Illegal address syntax

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

> -----Original Message-----
> From: fet...@li... 
> [mailto:fet...@li...] On Behalf Of Gary Sims
> 
> Clearly the return-path is broken, it looks like the 
> Received: header has been 
> pasted on the end. I would guess a memory corruption 
> somewhere as the closing 
> ">" is missing which would imply something is being 
> overwritten by something else.
> 
> I agree, the question now remains, is it my ISP's mail server 
> which is broken 
> or is it fetchmail in its fetching of the mail by POP3.

Unlikely to be fetchmail (but not impossible).  The address is stored in a
buffer defined as being BUFSIZ characters long.  This is an OS define.  On my
Mandrake 9.1 box it's defined by stdio.h as being _IO_BUFSIZ.  That appears to
be defined by libio.h as _G_BUFSIZ which appears to be defined by _G_config.h
as 8192.  Even a very long email address should be less than 8191 bytes :)

It could be some bizarre bug (so I've CCd to the -devel list so that the
experts can have a look) that's causing a lack of truncation only for really
long addresses (or possibly ones where the terminating > is missing), but the
fact that you're the only person to report it (so far anyway) makes me suspect
a cause elsewhere.

One test might be to hack rfc822.c such that at each invocation of nxtaddr()
it sets all bytes in address[] to be NULL.  Of course, you'll need to get a
hold of a known broken email to test with :(
 
> IMHO, I don't actually agree. The mail message was on a POP3 
> server somewhere 
> which means it has gone through some sort of processing and 
> has arrived. The 
> local delivery failed and the NDN failed. In my opinion this 
> message should 
> be saved to disk and a notification sent to the postmaster. A 
> few years back 
> I worked on several email gateways including X.400 to SMTP 
> and our golden 
> rule was that no message should ever be lost. Worse case it 
> should be written 
> to disk for later examination. Just my opinion.

Actually, I agree.  What I'd like is that any broken message be forwarded as a
plain text attachment to the postmaster.  I agree with the line "Be liberal in
what you accept, and conservative in what you send".  Right now however
fetchmail simply drops broken email on the floor (or leaves it behind and
ignores it).


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]My previous syntax error report and patch

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

Phil Endecott wrote:
> A while ago I posted a message describing a syntax error in Fetchmail's
> SMTP conversation, and included a patch to fix it.  I haven't had any
> replies at all, so I wonder if it actually reached the list.  It seems
> to be in the archive here:
> http://lists.ccil.org/pipermail/fetchmail-friends/2004-July/008937.html

Sorry, you caught us not only in the middle of a transition (which is going 
on longer than planned), but also in the middle of a server problem (which 
I think is fixed now).

These days code patches are best sent to fet...@be..., or 
filed at fetchmail's berlios project page:
  http://developer.berlios.de/projects/fetchmail/

As for your patch itself... I've gone ahead and committed it to the code 
repository.  Thanks!

-- 
==============================|   "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] svn is back

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

I just checked, and it looks like subversion works again.

-- 
==============================|   "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] Subversion repository?

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

Graham Wilson wrote:
> Is anybody else having trouble accessing the repository? I can't local
> access or remote access. Who, or what, do we prod to get these things
> working?

Yeah, I've been having problems for about the past week.  I submitted a 
support request on it:
http://developer.berlios.de/support/?func=detailsupport&support_id=100889&group_id=1

-- 
==============================|   "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] Subversion repository?

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

Is anybody else having trouble accessing the repository? I can't local
access or remote access. Who, or what, do we prod to get these things
working?

-- 
gram

[fetchmail-devel] NTLM/POP3 authentication

[Anuradha R. <ARa...@vi...>]

(This was first posted to fetchmail-friends list.)

Hi all,

I was trying to authenticate against a POP3 server (running Exchange or
whatever they call it ;-)) using NTLM using `--auth ntlm' and it failed.
And it turned out that fetchmail sends the string `AUTH MSN' instead of
`AUTH NTLM'.  However, changing this didn't help.  There seems to be
other small differences.

I am now trying to implement NTLM/POP3 authentication as explained in

    http://davenport.sourceforge.net/ntlm.html

What would be the best way of doing this?  I am thinking of renaming the
present `NTLM' authentation to something else (say `--auth msn').  Any
suggessions?

	Anuradha

-- 

http://www.linux.lk/~anuradha/




--------------------------------------------------------------------------------------------------
This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is intended for the addressee only.  Any unauthorized disclosure, use, dissemination, copying, or distribution of this message or any of its attachments or the information contained in this e-mail, or the taking of any action based on it, is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this message. 

[fetchmail-devel] Code quality - signedness

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

Dear fellow fetchmail interested,

I have recently compiled fetchmail with a decent set of warnings enabled
(i. e. -pedantic -W -Wextra and some more on gcc 3.3 or 3.4 or icc 8.0)
and I am _flooded_ by complaints about signedness mismatch. It is a bit
unfortunate this has been handled so laxly in the past, and this will
need to be fixed before a next release we can seriously recommend. It is
a task that will take a longer time because we'll effectively need to
align the types throughout the file with respect to signedness. Getting
the interfaces and data structures cleaned up would be the first step
and would require more eyeballs than just mine, and the second step
would then to cast the interface changes into .h files. After that, the
implementation cleanup would begin as a third step. It is a long-winded
effort, and tools I've come across in the past that can help us are:

- GCC with lots of warnings enabled, the more, the better.

Particularly useful to find ctype.h madness: GCC on Solaris 8, where in
32- or 64-bit mode (I don't recall as I usually test both) the ctype.h
is[]* functions are implemented as arrays, and GCC will complain if a
vanilla char is used as argument in is*() which leads to bogus results
on 8-bit data.

- ICC (Intel C++) 8.0. It's free for personal use, but a registration
  with Intel is required.

- Splint. It is probably a tad too early even with -weak to start with
  Splint.

Opinions solicited.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: [fetchmail-devel] Re: Can this stuff be removed?

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

Graham Wilson wrote:
> Would the webpage stuff be released in tarballs?

I wouldn't think so.

> Should I just move stuff now, and we can fix the scripts up as we use
> them, or the other way around?

I think it's fine to move stuff first.

> > If the libntlm and mime64 contents are not used in the actual fetchmail
> > code, we can probably get rid of them.  On the other hand, README.NTLM
> > seems to go with the copies of the libntlm files that we're actually
> > distributing, so should probably stay.
>
> I figured we could delete README.NTLM along with libntlm. README.NTLM
> was distributed with tarballs, whereas libtlm wasn't, at least that I
> can tell.

Err, I'm confused here.  README.NTLM was distributed.  libntlm files were 
distributed (not in the libntlm directory).  Why delete README.NTLM?

> > OPTIONS seems to belong in some sort of historical archive.
>
> Unless we plan on using it, I think we should delete it. Should we need
> it, the file will always be in the older version on version control.

True.

> > RFC/ could go in a document archive area (alongside OPTIONS?), or could
> > be considered redundant.  If deleted, I'd prefer to replace it with an
> > HTML file of links to canonical locations of the same documents.
>
> I would think we could just get rid of it outright; I doesn't seem that
> esr ever shipped it with tarballs, but rather only had it around for
> personal use.

Actually he did at one point ship RFCs, though there was never any point in 
putting them in version control.

Anyway, I think there's value in tracking which RFCs are relevant, even if 
we don't keep the text of them ourselves.

> > Isn't rh-config/ necessary for building the rpm?
>
> I wouldn't know. :)

Me either.

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

[fetchmail-devel] Re: Can this stuff be removed?

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

On Wed, Jun 30, 2004 at 04:02:40PM -0400, Rob Funk wrote:
> I'd be in favor of making a subdirectory for the web stuff though.  I need 
> to look at the index generatorscript to see how much we need to change 
> anyway.

Sounds fine. Would the webpage stuff be released in tarballs?

On Wed, Jun 30, 2004 at 04:02:40PM -0400, Rob Funk wrote:
> Graham Wilson wrote:
> > I think we should move the testing scripts (torturetest.* and test*)
> > should be moved to dist-tools/test/.
> >
> > The other scripts that esr used (getstats.py, growthplot, indexgen.sh,
> > listsize, makerelease, timeplot, timeseries, upload, and uploadfaq that
> > I can see) should be moved to dist-tools/.
> 
> Sounds good to me.  Paths will probably need to be changed in them though.
> (Some need even more work than that.)

Should I just move stuff now, and we can fix the scripts up as we use
them, or the other way around?

> I believe bighand.png is intended as the web page logo, so that should be 
> kept.

Alright, let's remember to put it in the web directory.

> I'm fine with dropping funny.html if nobody wants it in the new web page.  
> We might want to wait until we have such a web page built before actually 
> getting rid of it though.

I'd say let's just create a 'www' or 'web' subdirectory in the trunk
now, and move the current stuff into it. We can then decide about
'funny.html' later.

> If the libntlm and mime64 contents are not used in the actual fetchmail 
> code, we can probably get rid of them.  On the other hand, README.NTLM 
> seems to go with the copies of the libntlm files that we're actually 
> distributing, so should probably stay.

I figured we could delete README.NTLM along with libntlm. README.NTLM
was distributed with tarballs, whereas libtlm wasn't, at least that I
can tell.

> OPTIONS seems to belong in some sort of historical archive.

Unless we plan on using it, I think we should delete it. Should we need
it, the file will always be in the older version on version control.

> RFC/ could go in a document archive area (alongside OPTIONS?), or could be 
> considered redundant.  If deleted, I'd prefer to replace it with an HTML 
> file of links to canonical locations of the same documents.

I would think we could just get rid of it outright; I doesn't seem that
esr ever shipped it with tarballs, but rather only had it around for
personal use.

> Isn't rh-config/ necessary for building the rpm?

I wouldn't know. :)

-- 
gram

Re: [fetchmail-devel] Re: m4 directories?

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

Graham Wilson <bo...@de...> writes:

> However, if Rob is alright with having the automake changes in 6.2.6,
> I'll withdraw my criticisms.
>
> Did 6.2.5 work on Solaris?

It didn't compile with default options:

| cd intl; make
| make[1]: Entering directory `/var/tmp/fetchmail-6.2.5/intl'
| make[1]: *** No rule to make target `libintl.@l@a', needed by `all-yes'.  Stop.
| make[1]: Leaving directory `/var/tmp/fetchmail-6.2.5/intl'
| make: *** [@INTLDEPS@] Error 2

The workaround was --disable-nls.

The current fetchmail version from SVN compiles fine and passes a simple
smoke test (i. e. fetch local mail with IMAP, IMAP+SSL or POP3+SSL) on
the same machine.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: [fetchmail-devel] Re: Can this stuff be removed?

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

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

> Is CHANGES required for some autotools stuff?  It looks like a placeholder 
> to me.

Not to my knowledge. The canonical name for such a file is ChangeLog
(it's one of the files that automake will distribute even if it isn't
listed). It doesn't have useful content either.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)

Re: [fetchmail-devel] Re: Can this stuff be removed?

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

Graham Wilson wrote:
> I believe any of the website related stuff should be moved out of the
> trunk. If we still want to keep it under version control, we can create
> a new directory in the top-level of the repository for the files.

I'd prefer to keep the top level of the repository at just the trunk, 
branch, tag stuff.  That matches up best with the subversion documentation 
and various auxiliary tools.

I'd be in favor of making a subdirectory for the web stuff though.  I need 
to look at the index generatorscript to see how much we need to change 
anyway.

> > > Also, are we planning on using the testing framework and tools that
> > > esr used?
> >
> > Rob was pondering about how to reactivate the testing framework. As
> > far as I've read between the lines he wrote, he'd like to conduct
> > regression tests before releasing the next version.

Ideally I'd like to do that, but I'm not sure how much we'll be able to.  
There are lots of passwords that can't be shared, and I'm not even sure 
how many of the server owners are willing to transfer their permission for 
testing away from ESR to us.  I think some of the entries on the test list 
are even ESR's own accounts.

> I think we should move the testing scripts (torturetest.* and test*)
> should be moved to dist-tools/test/.
>
> The other scripts that esr used (getstats.py, growthplot, indexgen.sh,
> listsize, makerelease, timeplot, timeseries, upload, and uploadfaq that
> I can see) should be moved to dist-tools/.

Sounds good to me.  Paths will probably need to be changed in them though.
(Some need even more work than that.)


Is CHANGES required for some autotools stuff?  It looks like a placeholder 
to me.

I believe bighand.png is intended as the web page logo, so that should be 
kept.

I'm fine with dropping funny.html if nobody wants it in the new web page.  
We might want to wait until we have such a web page built before actually 
getting rid of it though.

If the libntlm and mime64 contents are not used in the actual fetchmail 
code, we can probably get rid of them.  On the other hand, README.NTLM 
seems to go with the copies of the libntlm files that we're actually 
distributing, so should probably stay.

OPTIONS seems to belong in some sort of historical archive.

RFC/ could go in a document archive area (alongside OPTIONS?), or could be 
considered redundant.  If deleted, I'd prefer to replace it with an HTML 
file of links to canonical locations of the same documents.

Isn't rh-config/ necessary for building the rpm?

-- 
==============================|   "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] Re: m4 directories?

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

Sorry it's taken me so long to get back into things here....

Graham Wilson wrote:
> On Sat, Jun 26, 2004 at 10:48:02AM +0200, Matthias Andree wrote:
> > Graham Wilson <bo...@de...> writes:
> > > Sorry for being persistent, I would just like to keep the tree as
> > > organized as possible.
> >
> > That's why I went with m4-local first :)
>
> Well, if we are going to keep the M4 files seperate, we should use
> m4-local, otherwise, we should just keep it in one file. Rob, what do
> you think we should do?

I'm no autotools expert, so I'm not sure whether it's better to have 
separate m4 files or a single one.  My intuition says separate though.

I definitely agree with your assessment about whether to use the 
subdirectory.  :-)

> More generally, I think the automake stuff should have been committed to
> a branch, not to the trunk.
>
> Rob identified that the goals for the next version of fetchmail was just
> incoroporating the backlog of well-tested patches. I don't think the
> automake stuff qualifies, and I think we should have spent more time
> going over it. It is still possible to push the automake stuff to a
> branch, and revert the changes from the trunk. I think that is what we
> should do until after 6.2.6.

I understand how you feel.  The main reason I didn't push the branch was 
that Matthias was testing on three different OSs, and the non-automake 
version wouldn't build on at least one of them.  (Though admittedly 
another factor was that I was on my way out for vacation.)

> For 6.2.6, I think we need to get the repository looking as close to
> esr's 6.2.5 tarball, plus the patches we have talked about.

We need to do extensive changes to the release scripts anyway, which 
touches the build system, so I'm not too concerned about making changes to 
the build system.

On the other hand, I want to minimize changes to the fetchmail code itself 
(i.e. C code) until after 6.2.6.

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