fetchmail-devel — Development related discussion

Re: [fetchmail-devel] Re: [fetchmail-svn] r3905 - trunk/dist-tools/shipper

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

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

> Matthias Andree at BerliOS wrote:
>> Modified:
>>    trunk/dist-tools/shipper/buildrpms
>> Log:
>> Try fallback to rpm (in case rpm is version 3).
>>
>> -rpmbuild --rcfile "$RCFILE" $ARCH -ta $TARBALL
>> +rpmbuild --rcfile "$RCFILE" $ARCH -ta $TARBALL \
>> +|| rpm --rcfile "$RCFILE" $ARCH -ta $TARBALL
>
> How old is rpm version 3?  Isn't it old enough to ignore by now?  Doesn't 
> rpm v3 require building the rpm file as root?

RPM v3 is still in use on supported SuSE versions, for instance 8.2, and
they have a nifty "patch RPM" feature for their online update - so it's
not old enough yet unfortunately.

I'm not aware of RPM requiring "root" - that's just a matter of
permissions on directories and all that. RPM v3 supports BuildRoot and
all that is needed.

> One of my next steps was going to be removing the references to building 
> the rpm as root.

I'm looking forward to those changes. :-)

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

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

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

> Whenever you run "configure", that configure script was produced by 
> autoconf. In the past it was ESR's installation of autoconf that produced 
> the configure script.  Autoconf itself never actually runs on your machine 
> when you compile fetchmail, only the script it produces.  Now it will be 
> our (the main developers) installations of autoconf that produce the 
> configure script.

BTW, the automake change has been committed.

Cc: me on reports of all failures.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Re: [fetchmail-svn] r3905 - trunk/dist-tools/shipper

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

Matthias Andree at BerliOS wrote:
> Modified:
>    trunk/dist-tools/shipper/buildrpms
> Log:
> Try fallback to rpm (in case rpm is version 3).
>
> -rpmbuild --rcfile "$RCFILE" $ARCH -ta $TARBALL
> +rpmbuild --rcfile "$RCFILE" $ARCH -ta $TARBALL \
> +|| rpm --rcfile "$RCFILE" $ARCH -ta $TARBALL

How old is rpm version 3?  Isn't it old enough to ignore by now?  Doesn't 
rpm v3 require building the rpm file as root?

One of my next steps was going to be removing the references to building 
the rpm as root.

-- 
==============================|   "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] automake migration

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

R.O. Blättner wrote:
> Did I get it right that this is opposed to ESR's tarballs where
> always some auto* stuff was running while doing "make config" ?

I'm not sure I understand your question....
The tarballs we produce will be very much like ESR's tarballs.

Whenever you run "configure", that configure script was produced by 
autoconf. In the past it was ESR's installation of autoconf that produced 
the configure script.  Autoconf itself never actually runs on your machine 
when you compile fetchmail, only the script it produces.  Now it will be 
our (the main developers) installations of autoconf that produce the 
configure script.

Except now our installations of automake will also contribute, which makes 
things easier for us.  That change will not be very noticable to you 
unless you pay attention to the makefiles or get the code from the 
Subversion repository.

> Hi, Rob, many THX for Your quick and enlightening response !

You're welcome!

> So I may continue to test (nearly) every release
> as I've done in the past ...   :-)
>
> When time permits I may contribute some fixes too in the future.

Looking forward to 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"

Re: [fetchmail-devel] automake migration

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

"R.O. Blättner" <com...@bl...> writes:

> Hmmpf, does this mean I've to do a reinstall of all those auto* stuff
> ?

You only need all that stuff if you intend to develop fetchmail.  If
you're only downloading some .tar.gz, compile and use it, this is not
relevant to you.

> Currently I'm running SuSE 7.3 with

SuSE Linux 7.3 has been unmaintained and has unfixed security bugs in
kernels and daemons that make it unsuitable for use in networks, even as
a client. Upgrade as soon as possible.

> I'm used to NOT reinstall every new distribution release on my boxes.

?`

> And I usually grapped every new fetchmail tarball from ESR and could
> compile it like a charme although I've somtimes not the cutting edge
> of generation software installed.

tarballs will continue to work the same way for you, but the whole
development is easier for us in the long run.

> Question: Isn't it possible to apply the changes in a manner that
> enables generation with older auto* tools too ?

Nope. Unless you pay, that is. I believe you don't care any longer after
the answers given above :)

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

[R.O. B. <com...@bl...>]

On Fri, 18 Jun 2004 21:35:28 -0400,
Rob Funk <rf...@fu...> wrote:

> R.O. Blättner wrote:
> > I'm used to NOT reinstall every new distribution release on my boxes.
> >
> > And I usually grapped every new fetchmail tarball from ESR and could

Sorry, typo: I wanted to type "grabbed" ...

> > compile it like a charme although I've somtimes not the cutting edge
> > of generation software installed.
> 
> You'll still be able to compile the released tarball just fine; you don't 
> need that list of tools to do that.  Autoconf and the rest are necessary 
> for going from what's in the code repository to what you see in the 
> release tarball.  But after that, none of that stuff is necessary.

Sounds good  :-)

> In other words, if you only work from releases, nothing will change for 
> you.  But now we have the ability to get involved in the process before 
> release, and that's where autoconf et al come in.

Fine !

Did I get it right that this is opposed to ESR's tarballs where
always some auto* stuff was running while doing "make config" ?

Hi, Rob, many THX for Your quick and enlightening response !

So I may continue to test (nearly) every release
as I've done in the past ...   :-)

When time permits I may contribute some fixes too in the future.

Bye,

Rolf
-- 
Dipl.phys. Rudolf Otto Blättner,
D 91074 Herzogenaurach, Germany.

Re: [fetchmail-devel] automake migration

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

R.O. Blättner wrote:
> I'm used to NOT reinstall every new distribution release on my boxes.
>
> And I usually grapped every new fetchmail tarball from ESR and could
> compile it like a charme although I've somtimes not the cutting edge
> of generation software installed.

You'll still be able to compile the released tarball just fine; you don't 
need that list of tools to do that.  Autoconf and the rest are necessary 
for going from what's in the code repository to what you see in the 
release tarball.  But after that, none of that stuff is necessary.

In other words, if you only work from releases, nothing will change for 
you.  But now we have the ability to get involved in the process before 
release, and that's where autoconf et al come in.

-- 
==============================|   "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] automake migration

[R.O. B. <com...@bl...>]

Hi, dear hackers,

On Fri, 18 Jun 2004 22:51:10 +0200,
Matthias Andree <ma...@dt...> wrote:

> I've automake-ified fetchmail, but haven't commited the (huge!) change
[ ... snip ... ]
> 
> | The prerequisite packages are:
> | 
> | - GNU autoconf >= 2.54
> | - GNU automake >= 1.7
> | - GNU gettext >= 0.13
> | - GNU m4
> | - bison or yacc
> | - flex or lex
[ ... snip ... ]

Hmmpf, does this mean I've to do a reinstall of all those auto* stuff ?

Currently I'm running SuSE 7.3 with

  autoconf (GNU Autoconf) 2.52
  automake (GNU automake) 1.4-p5
  gettext (GNU gettext) 0.10.37
  GNU m4 1.4o
  GNU Bison version 1.28
  ...

I'm used to NOT reinstall every new distribution release on my boxes.

And I usually grapped every new fetchmail tarball from ESR and could
compile it like a charme although I've somtimes not the cutting edge
of generation software installed.

Question: Isn't it possible to apply the changes in a manner that
enables generation with older auto* tools too ?

THX for Your efforts

Rolf
-- 
Dipl.phys. Rudolf Otto Blättner,
D 91074 Herzogenaurach, Germany.

Re: [fetchmail-devel] FYI: recovered SVN repository

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

Back on the automake issue, I have difficulties with AC_REPLACE_FUNCS()
which does not ship the corresponding sources. It does for bogofilter.

I'm at a loss - I can of course force automake to ship these, but this
is annoying. :-/

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] FYI: recovered SVN repository

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

Matthias Andree wrote:
> I don't know what caused it. I aborted a commit that would have been too
> broad, if this cause the SVN server stuff to die from SIGPIPE or
> something, that might explain it - but I have no idea how to reproduce
> this.

Makes sense.

> > Ah, in that case I have a book on that to sit down with.  It's changed
> > a lot since I last worked with it.
>
> SVN uses the "transactional" store so it can recover from write errors
> or application crashes or server crashes. This stuff dates back to at
> least Berkeley DB 3.2.

Heh, the last time I did any programming with Berkeley DB was in 1997.
I think it was around the transition from version 1.something to 2.0.

-- 
==============================|   "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] FYI: recovered SVN repository

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

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

> Matthias Andree wrote:
>> Rob Funk <rf...@fu...> writes:
>> > Yeah, I've had to do that once or twice before.  It's a bit disturbing
>> > that it happens though.  I wish I knew why.  Luckily recovery seems to
>> > be pretty easy.
>>
>> All it takes is an unclean shutdown of some server software.
>
> Hmm, that means we can blame Berlios sysadmins?  Seems like a bad
> sign.

I don't know what caused it. I aborted a commit that would have been too
broad, if this cause the SVN server stuff to die from SIGPIPE or
something, that might explain it - but I have no idea how to reproduce
this.

>> > I'm really looking forward to sitting down with the subversion
>> > book....
>>
>> That's inherited from Berkeley DB.
>
> Ah, in that case I have a book on that to sit down with.  It's changed a 
> lot since I last worked with it.

SVN uses the "transactional" store so it can recover from write errors
or application crashes or server crashes. This stuff dates back to at
least Berkeley DB 3.2.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] FYI: recovered SVN repository

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

Matthias Andree wrote:
> Rob Funk <rf...@fu...> writes:
> > Yeah, I've had to do that once or twice before.  It's a bit disturbing
> > that it happens though.  I wish I knew why.  Luckily recovery seems to
> > be pretty easy.
>
> All it takes is an unclean shutdown of some server software.

Hmm, that means we can blame Berlios sysadmins?  Seems like a bad sign.

> > I'm really looking forward to sitting down with the subversion
> > book....
>
> That's inherited from Berkeley DB.

Ah, in that case I have a book on that to sit down with.  It's changed a 
lot since I last worked with 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"

Re: [fetchmail-devel] FYI: recovered SVN repository

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

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

> Yeah, I've had to do that once or twice before.  It's a bit disturbing that 
> it happens though.  I wish I knew why.  Luckily recovery seems to be 
> pretty easy.

All it takes is an unclean shutdown of some server software.

>> I've also taken the opportunity to compress unused log files:
>>
>> svnadmin list-unused-dblogs /svnroot/repos/fetchmail | xargs gzip -9f
>
> Hmm, I wasn't aware of that being any sort of issue.
>
> I'm really looking forward to sitting down with the subversion book....

That's inherited from Berkeley DB.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

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

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

> I'm OK with intermediate steps that aren't really tested. I like to be able 
> to see the process.  I'm not one who worries about each committed revision 
> being usable.

The process is virtually inseparable. Splitting out singular changes
doesn't make sense, it's really one large sweep. The po/ changes require
automake, and intl/ is just a cleanup that has to come with the po/
update :-/

> I'll say go ahead and commit it.  You may want to put it on an AUTOMAKE 
> branch, but I'll leave that up to you.   If you put it on the trunk I'd 
> suggest making a PRE_AUTOMAKE tag first.

I'll do. I'll also add a bootstrap.sh first because I found some
peculiarities without.

> Well, the bootstrap script I'm talking about would just codify what you're 
> writing into the README.svn, particularly autoreconf and the options to 
> use with it.  That way it's visible without looking too hard, and is 
> callable from things like makerelease.  If we ever need to change the 
> autoreconf options I only want to change it in one place.

OK.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] FYI: recovered SVN repository

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

Matthias Andree wrote:
> the SVN repository required recovery, visible in that svn ls printed
> "DB_RUNRECOVERY" embedded in a longish error message.
>
> The remedy was:
> ssh svn.berlios.de
> svnadmin recover /svnroot/repos/fetchmail
>
> NOTE! This is a dangerous operation in that it may only be conducted on
> a quiet repository, as data base recovery does not serialize (lock)
> against concurrent execution of svnadmin recover, which may fail and
> potentially cause corruption.

Yeah, I've had to do that once or twice before.  It's a bit disturbing that 
it happens though.  I wish I knew why.  Luckily recovery seems to be 
pretty easy.

> I've also taken the opportunity to compress unused log files:
>
> svnadmin list-unused-dblogs /svnroot/repos/fetchmail | xargs gzip -9f

Hmm, I wasn't aware of that being any sort of issue.

I'm really looking forward to sitting down with the subversion book....

-- 
==============================|   "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] automake migration

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

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

> Matthias Andree wrote:
>> >> A      dist-tools/Makefile.am
>> >
>> > I wouldn't think we'd need a makefile there.
>>
>> We can get away without if we ship the generated file.
>
> I don't expect to need to ship dist-tools/ at all.

We won't. :-)

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

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

Matthias Andree wrote:
> >> A      dist-tools/Makefile.am
> >
> > I wouldn't think we'd need a makefile there.
>
> We can get away without if we ship the generated file.

I don't expect to need to ship dist-tools/ at all.

-- 
==============================|   "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] FYI: recovered SVN repository

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

Hi,

the SVN repository required recovery, visible in that svn ls printed
"DB_RUNRECOVERY" embedded in a longish error message.

The remedy was:

ssh svn.berlios.de
svnadmin recover /svnroot/repos/fetchmail

NOTE! This is a dangerous operation in that it may only be conducted on
a quiet repository, as data base recovery does not serialize (lock)
against concurrent execution of svnadmin recover, which may fail and
potentially cause corruption.

I've also taken the opportunity to compress unused log files:

svnadmin list-unused-dblogs /svnroot/repos/fetchmail | xargs gzip -9f

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

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

Matthias Andree wrote:
> I had to add this to get "make distcheck" working.

I get it.

> In the long run, it
> might be worthwhile converting the documentation to DocBook XML where
> appropriate, I believe ESR's doclifter can help with that, which will
> directly open PDF, man and HTML output formats.

Yeah, good idea.

> I fear the whole stuff is fairly atomic in the sense that I've only
> tested with the full change set applied, not in separate.

I'm OK with intermediate steps that aren't really tested. I like to be able 
to see the process.  I'm not one who worries about each committed revision 
being usable.

I'll say go ahead and commit it.  You may want to put it on an AUTOMAKE 
branch, but I'll leave that up to you.   If you put it on the trunk I'd 
suggest making a PRE_AUTOMAKE tag first.

> > It might be good to create a "bootstrap" script that removes that
> > cache directory and does the autoreconf.  And then change the
> > makerelease script to call that instead of "aclocal && autoconf".
>
> I don't like custom bootstrap scripts much.
> I have yet to see one that is better than "autoreconf" - and
> autom4te.cache will only need to be removed after a system upgrade, but
> not on a fresh checkout, so most people will get away without rm -rf.

Well, the bootstrap script I'm talking about would just codify what you're 
writing into the README.svn, particularly autoreconf and the options to 
use with it.  That way it's visible without looking too hard, and is 
callable from things like makerelease.  If we ever need to change the 
autoreconf options I only want to change it in one place.

> >> A      dist-tools/Makefile.am
> >
> > I wouldn't think we'd need a makefile there.
>
> For the time being we'll need one if you want "make distcheck" to work,

OK, no big deal.

> autopoint will create the intl/ directory and populate it if you have
> gettext 0.13.0 or newer installed - this is the "generated files"
> category (copied files actually) - just try the tarball and you'll see.
>
> No jinx here, good magic. :)

Got it.  Cool.

-- 
==============================|   "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] automake migration

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

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

> Meanwhile, be sure to test actually running the result.  (Argh, I still 
> have to figure out how to deal with the torturetest server list, with its 
> unpublishable passwords.)

[X] Done
[X] configured --with-ssl=...
[X] worked with POP3 UIDL SSL KEEP
[X] worked with IMAP SSL KEEP

>> A      dist-tools/Makefile.am
>
> I wouldn't think we'd need a makefile there.

We can get away without if we ship the generated file.

I'll commit RSN.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

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

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

>> 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.
>
> I was actually wondering about moving that generation out of the makefile 
> and into the makerelease script.  Not sure though.  That was mainly 
> prompted by the conversion of the man page to HTML, which requires some 
> infrastructure that we're not only not distributing, but isn't all that 
> common.  (Mainly the manServer.pl script I added to the dist-tools 
> directory.  Note that I don't intend for dist-tools to be included in the 
> release, and I hope to move a bunch of Eric's release scripts into there.) 
> I figured that if that conversion doesn't work with the distributed 
> tarball, it's worth thinking about the same situation with the rest of the 
> HTML generation.

I had to add this to get "make distcheck" working. In the long run, it
might be worthwhile converting the documentation to DocBook XML where
appropriate, I believe ESR's doclifter can help with that, which will
directly open PDF, man and HTML output formats.

>> Rob, does this get your OK?
>
> The general idea sounds good, especially the fact that you've tested on 
> multiple platforms.  The number of files touched is a bit scary, and I 
> have minor reservations about some fringes of the process, but I think we 
> can work those out later.

Most of the stuff is auto-generated and will be copied into the build
directory by autopoint, some will be copied by automake --add (this is
all automatic by running autoreconf -i)

> Unfortunately I'm going on an 8-day camping trip in a couple days and don't 
> have time to look closely at this before I go.  So I'll just suggest that 
> you go ahead and commit it, but try to commit in coherent chunks if 
> possible.

I fear the whole stuff is fairly atomic in the sense that I've only
tested with the full change set applied, not in separate. configure.in
and Makefile.am in particular track the po/ intl/... changes, and using
automake/aclocal only enables us to use the m4/ subdirectory which takes
the aclocal.m4 maintenance entirely off our shoulders.

> That is, see if you can separate the automake stuff, the HTML
> generation, and the gettext stuff.  I understand if that's not really 
> possible though.

automake and gettext is coupled, and HTML generation is a minor change,
effectively, the separate lines have been consolidated in a shell script.

> Meanwhile, be sure to test actually running the result.  (Argh, I still 
> have to figure out how to deal with the torturetest server list, with its 
> unpublishable passwords.)

Will do.

> It might be good to create a "bootstrap" script that removes that cache 
> directory and does the autoreconf.  And then change the makerelease script 
> to call that instead of "aclocal && autoconf".

I don't like custom bootstrap scripts much.
I have yet to see one that is better than "autoreconf" - and
autom4te.cache will only need to be removed after a system upgrade, but
not on a fresh checkout, so most people will get away without rm -rf.

>> A      dist-tools/Makefile.am
>
> I wouldn't think we'd need a makefile there.

For the time being we'll need one if you want "make distcheck" to work,
which I'd recommend as it greatly simplifies testing if the generated
tarball is self-contained. We can still remove the stuff later if we
have a good solution before the release.

>> D      intl/ChangeLog
>> D      intl/Makefile.in
>> D      intl/VERSION
>> D      intl/bindtextdom.c
> .... and so on
>
> Where's this intl functionality now?

autopoint will create the intl/ directory and populate it if you have
gettext 0.13.0 or newer installed - this is the "generated files"
category (copied files actually) - just try the tarball and you'll see.

No jinx here, good magic. :)

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] Greetings and some patches

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

Sorry it's taken me so long to respond to this....

Brian Candler wrote:
> 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.

Ouch.  Try submitting a request/bug to Berlios support.  Their bug system 
extends to covering their own site.
(Or see if either "links" or "w3m" handles it any better than lynx.)

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

Thanks.  I think some of this is already fixed in the current subversion 
repository, and I'm not sure yet how much of the rest is 6.2.6 material.
I'm hoping we can get 6.2.6 out, with the obvious bugs fixed, after getting 
the build/release system working properly.  After that, maybe another 
bug-fix release, and tackling some bigger code issues.

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

> > > > You can have fetchmail invoke the same local delivery program
> > > > that sendmail would use to write to a maildir.
> > >
> > > You still use *sendmail* ?? 
> > 
> > Yes, is that a problem?
> > 
> >     s/sendmail/your local MTA/
> > 
> > if you  prefer :)
>
> I use Exim, and it doesn't invoke any local delivery program.
> (It *can*, but in a normal configuration there's no need).
>
> All I'm trying to say is, you can't rely on the existence of a separate
> local delivery program on the system where you install fetchmail.

Aha.  *That* is a good point, which I had not picked up from the
previous discussion.  (I have heard of Exim, but know essentially
nothing about it.)

I'm still inclined toward the modular approach, but this suggests
a need for the fetchmail documentation to include suggestions of
where to find simple LDA's for various formats.  Certainly procmail
is one possibility, but not everyone who needs to use an LDA rather
than the local MTA will need the full capabilities (and attendant
configuration requirements) of procmail.

Re: [fetchmail-devel] automake migration

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

Matthias Andree wrote:
> I've automake-ified fetchmail,

Sounds scary, but it's something that crossed my mind last night.

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

Awesome!

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

I was actually wondering about moving that generation out of the makefile 
and into the makerelease script.  Not sure though.  That was mainly 
prompted by the conversion of the man page to HTML, which requires some 
infrastructure that we're not only not distributing, but isn't all that 
common.  (Mainly the manServer.pl script I added to the dist-tools 
directory.  Note that I don't intend for dist-tools to be included in the 
release, and I hope to move a bunch of Eric's release scripts into there.) 
I figured that if that conversion doesn't work with the distributed 
tarball, it's worth thinking about the same situation with the rest of the 
HTML generation.

> Rob, does this get your OK?

The general idea sounds good, especially the fact that you've tested on 
multiple platforms.  The number of files touched is a bit scary, and I 
have minor reservations about some fringes of the process, but I think we 
can work those out later.

> If you can tell me how to fork a branch and
> commit that stuff to a branch, I'll do that,

Heh, that's an area of svn I haven't explored yet.  Check here for that 
info:  http://svnbook.red-bean.com/
(I'm eagerly awaiting the print release of the book, which should get 
shipped to me when it comes out.)

Unfortunately I'm going on an 8-day camping trip in a couple days and don't 
have time to look closely at this before I go.  So I'll just suggest that 
you go ahead and commit it, but try to commit in coherent chunks if 
possible.  That is, see if you can separate the automake stuff, the HTML 
generation, and the gettext stuff.  I understand if that's not really 
possible though.

Meanwhile, be sure to test actually running the result.  (Argh, I still 
have to figure out how to deal with the torturetest server list, with its 
unpublishable passwords.)

And I encourage everyone else to test building and running too.

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

It might be good to create a "bootstrap" script that removes that cache 
directory and does the autoreconf.  And then change the makerelease script 
to call that instead of "aclocal && autoconf".

> A      dist-tools/Makefile.am

I wouldn't think we'd need a makefile there.

> D      intl/ChangeLog
> D      intl/Makefile.in
> D      intl/VERSION
> D      intl/bindtextdom.c
.... and so on

Where's this intl functionality now?

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

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

On Fri, Jun 18, 2004 at 11:07:09AM -0700, Perry Hutchison wrote:
> > > You can have fetchmail invoke the same local delivery program
> > > that sendmail would use to write to a maildir.
> >
> > You still use *sendmail* ?? 
> 
> Yes, is that a problem?
> 
>     s/sendmail/your local MTA/
> 
> if you  prefer :)

I use Exim, and it doesn't invoke any local delivery program. (It *can*, but
in a normal configuration there's no need).

All I'm trying to say is, you can't rely on the existence of a separate
local delivery program on the system where you install fetchmail.

Regards,

Brian.