fetchmail-devel — Development related discussion

[fetchmail-devel] Re: m4 directories?

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

On Tue, Jun 29, 2004 at 06:37:48PM +0200, Matthias Andree wrote:
> My committing the patch was the practical approach. I'm willing to
> have it reverted the instant someone fixes the other build issues I
> was seeing and shows me that the conversion introduced a problem
> (regression).

I don't think the conversion necessarily introduces any problems. It
didn't seem to long to me between when you announce the changes and
committed them: I think we should've taken more time to go over the
changes.

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?

-- 
gram

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

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

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

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

The automake patch wasn't intended to go into 6.2.6 but was agreed to by
Rob because it allows us to fix build issues for instance on Solaris
8. I tried to fix just the build issues but something always broke :-/

My committing the patch was the practical approach. I'm willing to have
it reverted the instant someone fixes the other build issues I was
seeing and shows me that the conversion introduced a problem (regression).

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Re: m4 directories?

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

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?

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.

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.

-- 
gram

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

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

On Sat, Jun 26, 2004 at 10:45:38AM +0200, Matthias Andree wrote:
> Graham Wilson <bo...@de...> writes:
> > Will anybody miss the following if removed from the tree?
> >
> > bighand.png
> > CHANGES
> > FetchmailOfSatan.gif
> > fetchmail.png
> > fetchmail.ppm
> > fetchmail.py
> > fetchmail.xpm
> 
> The xpm is needed to build the RPM,

I use the XPM for the Debian package as well, so I guess it would be
alright to keep that.

> the pngs are probably used for the web site.

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 haven't looked at fetchmail.py

That seems to be esr's work on the Python fetchmail. I recommend that we
remove it.

> and .ppm.

This seems to me to be a copy (in portable pixmap format) of the X
pixmap file. I think we whould remove it as well.

> I personally wouldn't miss FetchmailOfSatan.gif.

Yes, that should certainly go.

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

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

Matthias, Rob, would you guys be alright this?

-- 
gram

[fetchmail-devel] Re: list reply-to

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

On Sat, Jun 19, 2004 at 03:47:49PM +0200, Matthias Andree wrote:
> Rob Funk <rf...@fu...> writes:
> > How's it sound to you, Matthias?
> 
> I object to reply-to munging throughout. If the people are uneducated,
> they can learn. Pressing G or clicking "reply all" is neither hard nor
> inexplicable.

I also object to reply-to munging.

And, for the record, I don't like subject tags either. I have a tool to
delete those though, so it's less of an issue for me.

-- 
gram

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

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

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

> On Sat, Jun 26, 2004 at 02:11:24AM +0200, Matthias Andree wrote:
>> I have taken this acinclude.m4 approach in bogofilter and am not very
>> happy with that, updating individual macros is then more effort than
>> necessary. I'd rather stick with a file per macro (or file per logic
>> group of macros, call it module if you like).
>
> Do you mean that you'd have to search through the global file, rather
> than replacing just a single file?

Yes, that's exactly it.

> If so, I'd rather go through that each time (I wouldn't think it would
> be too often) rather than have a bunch of M4 macro files laying
> around.

I've found that solution to be impractical and would rather have a set
of files lingering on the floor that I can nuke individually.

> Additionally, can't the license file be added to the top of the macro
> file, or to the COPYING file?

That might be doable but makes the COPYING file a bit lenghty and
cumbersome to read.

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

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

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

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

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

> Will anybody miss the following if removed from the tree?
>
> bighand.png
> CHANGES
> FetchmailOfSatan.gif
> fetchmail.png
> fetchmail.ppm
> fetchmail.py
> fetchmail.xpm

The xpm is needed to build the RPM, the pngs are probably used for the
web site. I haven't looked at fetchmail.py and .ppm. I personally
wouldn't miss FetchmailOfSatan.gif.

> funny.html
> libntlm-0.21/
> mime64/
> OPTIONS
> README.NTLM
> RFC/
> rh-config/

As to the other stuff, I'd wait for Rob's comments first.

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

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] Can this stuff be removed?

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

Will anybody miss the following if removed from the tree?

bighand.png
CHANGES
FetchmailOfSatan.gif
fetchmail.png
fetchmail.ppm
fetchmail.py
fetchmail.xpm
funny.html
libntlm-0.21/
mime64/
OPTIONS
README.NTLM
RFC/
rh-config/

Also, are we planning on using the testing framework and tools that esr
used?

-- 
gram

[fetchmail-devel] Re: m4 directories?

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

On Sat, Jun 26, 2004 at 02:11:24AM +0200, Matthias Andree wrote:
> Graham Wilson <bo...@de...> writes:
> > Also, would it be alright to move the macros from m4-local into one file
> > (acinclude.m4)? I don't see any need to add a new directory for just one
> > or a handful of new macros.
> 
> I have taken this acinclude.m4 approach in bogofilter and am not very
> happy with that, updating individual macros is then more effort than
> necessary. I'd rather stick with a file per macro (or file per logic
> group of macros, call it module if you like).

Do you mean that you'd have to search through the global file, rather
than replacing just a single file? If so, I'd rather go through that
each time (I wouldn't think it would be too often) rather than have a
bunch of M4 macro files laying around.

Additionally, can't the license file be added to the top of the macro
file, or to the COPYING file?

Sorry for being persistent, I would just like to keep the tree as
organized as possible.

-- 
gram

Re: [fetchmail-devel] m4 directories?

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

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

> What is the purpose of the m4 directory? I can only see that is has one
> file in it (Makefile.am)?

Graham,

the m4 directory is almost empty because the generated and copied files
are not stored in the Subversion repository and the m4 directory, as the
intl directory, is gettext's playground.

The directory will be populated with c. 30 files by autopoint (which is
part of GNU gettext and run from autogen.sh/autoreconf). The files are
part of the distribution that "make dist" creates however, hence the
Makefile.am in there.

> Also, would it be alright to move the macros from m4-local into one file
> (acinclude.m4)? I don't see any need to add a new directory for just one
> or a handful of new macros.

I have taken this acinclude.m4 approach in bogofilter and am not very
happy with that, updating individual macros is then more effort than
necessary. I'd rather stick with a file per macro (or file per logic
group of macros, call it module if you like).

Anyways you're right in that we needn't add a directory for the .m4 and
.txt files, so I've moved the two files to the top level and dropped the
m4-local directory and references to it. "make distcheck" still passes.
(SVN Revision 3923.)

Cheers,

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] m4 directories?

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

What is the purpose of the m4 directory? I can only see that is has one
file in it (Makefile.am)?

Also, would it be alright to move the macros from m4-local into one file
(acinclude.m4)? I don't see any need to add a new directory for just one
or a handful of new macros.

-- 
gram

RE: [fetchmail-devel] list reply-to

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

> -----Original Message-----
> From: fet...@be... 
> [mailto:fet...@be...] On Behalf Of Matthias Andree
> 
> I object to reply-to munging throughout. If the people are uneducated,
> they can learn. Pressing G or clicking "reply all" is neither hard nor
> inexplicable.

No, it's not hard for you, nor most techies.  However keep in mind that
many people who come to the -users list for help *aren't* techies.  Most
of them are unable to contemplate reading the man page, searching the
list archive or even using Google.

Expecting such people to understand the concept of managing the reply
addresses is, frankly, being overly optomistic.  If the reply-to is set
to the list address then it means that people who try to help don't get
bombarded with emails from people who assume that you are the list.
While in theory I could set the reply-to according to the list I'm
dealing with, when you're dealing with a number of lists that gets a
little silly.

Just remember, these days having a clue is an optional extra for using
Linux :)


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? 

Re: [fetchmail-devel] list reply-to

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

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

[reply-to for the clueless]
> How's it sound to you, Matthias?

I object to reply-to munging throughout. If the people are uneducated,
they can learn. Pressing G or clicking "reply all" is neither hard nor
inexplicable.

> (BTW, I finally found Kmail's Reply-To-List function.  Now I just need to 
> find some Mail-Followup-To support.)

KMail sucks *ducks*

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] vacation

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

I'll be away through June 28, so don't expect anything from me until then.

Graham Wilson <bo...@de...> has complete admin access to the project 
at Berlios.

When I return I'll work on finishing up the release scripts so we can get 
6.2.6 out.  If anyone wants to look at fixing up indexgen.sh (the web page 
generator) for the new site, that'd be great.  Otherwise I'll work on it 
when I do the release scripts.

-- 
==============================|   "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] list reply-to (was Re: automake migration)

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

Rob wrote:
> I would say that for the -devel list, leaving it as is should be fine,
> developers generally being somewhat more clueful.  For the general
> -users list, with it's higher percentage of less aware people, I'd be
> strongly in favour of setting the reply-to to be the list.

That's actually the guideline I most often go by when setting up a new 
list.

How's it sound to you, Matthias?


(BTW, I finally found Kmail's Reply-To-List function.  Now I just need to 
find some Mail-Followup-To support.)
-- 
==============================|   "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] list reply-to (was Re: automake migration)

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

> -----Original Message-----
> From: fet...@be... 
> [mailto:fet...@be...] On Behalf Of Rob Funk
> 
> That reminds me...
> The fetchmail-friends list didn't have replies set to go back 
> to the list, 
> and there are well-known arguments for that.  For those 
> reasons, I put it that way on the new lists.
> 
> But since these are new lists, it's reasonable to consider 
> switching to the 
> "munge reply-to" setting.  Are there any preferences either way?

Well, as you can probably guess from the line above my .sig, I'll argue
in favour.

Yes, having the reply-to set makes it slightly harder to contact
somebody directly about an issue, but only slightly.  What it does stop
is the all too common problem of somebody either mailing you directly,
and via the list, or as I often get, mailing me instead of the list.

I would say that for the -devel list, leaving it as is should be fine,
developers generally being somewhat more clueful.  For the general
-users list, with it's higher percentage of less aware people, I'd be
strongly in favour of setting the reply-to to be the list.


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? 

Re: [fetchmail-devel] list reply-to

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

Matthias Andree wrote:
> Rob Funk <rf...@fu...> writes:
> > But since these are new lists, it's reasonable to consider switching
> > to the "munge reply-to" setting.  Are there any preferences either
> > way?
>
> Yes, the answer is plain and simple "don't."
>
> Reply-To: serves no purpose makes replying off-list hard when there are
> valid reasons to reply off-list (for a chat or something), and it can
> cause embarrassment when the user's mailer doesn't warn the answer is
> redirected.

Well, I somewhat disagree, but I don't feel very strongly about it, so I'm 
fine with leaving it alone.

> <URL:http://www.unicom.com/pw/reply-to-harmful.html>

Yeah, that's the well-known argument page I was referring to.
There's also a reply-to-helpful answering page, but I won't continue the 
argument. I was just checking. :-)

-- 
==============================|   "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, drifting away to OT (sorry),

on Sat, 19 Jun 2004 05:07:21 +0200,
Matthias Andree <ma...@dt...> wrote:

> "R.O. Blättner" <com...@bl...> writes:
>
> >> 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.
> >
> > Will do so, when I'll be done with all my f*cked graphic cards
> > X11 configurations..   :-(
>
> I don't recall 7.3 details, but the 9.X SuSE versions are rather
> comfortable to configure with respect to X11, OTOH, I have cheap brand
> cards from the mainstream, Ati R128, Matrox G100/200/550, Intel embedded
> graphics and such stuff where drivers for 2D aren't an issue...

But ... I'm partly using veeeery old HW, so I was always forced to
do a lot of handycraft since I couldn't get full resolution (1280x1024)
on all my grafic cards/displays with SuSE/X11 config tools - some cards
aren't even supported by newer Xfree releases :-(((

> > Next time You don't need do address me personally since
> > I'm subscribed to fetchmail-devel too ...
>
> Then teach your mailer about Mail-Followup-To:, mine will follow your
> instructions. :-)

Since I'm yet exclusively using the (ancient-plain-commandline-)mail command
I've no clue how to tell'em such nice header lines   :-))
Sorry being a member of soon beeing extinct race of unconvincable
command line hackers .... :-))

THX for suggestions,

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

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

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

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

> Back when I ran Red Hat (around the same time I last programmed Berkeley 
> DB :-), root was required for creating rpms so that the ownerships and 
> permissions of the installed files would turn out right.  Eric's "go root 
> to make the rpm" release procedure is a remnant of that era, even though 
> things have changed since then.

Non-issue at least for RPM V3:

%files
%defattr(-,root,root)
bin/fetchmail
bin/fetchmailconf
...

I've committed a fix to specgen.sh that enables overrides for user,
name, domain and makes sure that date runs with C locale rather than
what I have configured - German month/week day names kill RPM in
%changelog.

-- 
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 22:25:39 -0400,
Rob Funk <rf...@fu...> wrote:

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

My failure :-)

> The tarballs we produce will be very much like ESR's tarballs.

Sounds good !

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

Hmm, may be I was wrong in believing autoconf running
while doing a "make config" (in ESR's releases).
Next Monday I'll do a more precise look at
logfiles of my last build process.

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

O.K., normally I'll not get the sources directly from SVN as long
as tarball releases are not too sparse in time..

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

Hope, I'll have time .. :-)

THX,

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

Re: [fetchmail-devel] list reply-to

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

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

> But since these are new lists, it's reasonable to consider switching to the 
> "munge reply-to" setting.  Are there any preferences either way?

Yes, the answer is plain and simple "don't."

Reply-To: serves no purpose makes replying off-list hard when there are
valid reasons to reply off-list (for a chat or something), and it can
cause embarrassment when the user's mailer doesn't warn the answer is
redirected.

<URL:http://www.unicom.com/pw/reply-to-harmful.html>

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: [fetchmail-devel] automake migration

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

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

>> 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.
>
> Will do so, when I'll be done with all my f*cked graphic cards
> X11 configurations..   :-(

I don't recall 7.3 details, but the 9.X SuSE versions are rather
comfortable to configure with respect to X11, OTOH, I have cheap brand
cards from the mainstream, Ati R128, Matrox G100/200/550, Intel embedded
graphics and such stuff where drivers for 2D aren't an issue...

> Next time You don't need do address me personally since
> I'm subscribed to fetchmail-devel too ...

Then teach your mailer about Mail-Followup-To:, mine will follow your
instructions. :-)

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

[fetchmail-devel] list reply-to (was Re: automake migration)

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

R.O. Blättner wrote:
> Next time You don't need do address me personally since
> I'm subscribed to fetchmail-devel too ...

That reminds me...
The fetchmail-friends list didn't have replies set to go back to the list, 
and there are well-known arguments for that.  For those reasons, I put it 
that way on the new lists.

But since these are new lists, it's reasonable to consider switching to the 
"munge reply-to" setting.  Are there any preferences either way?

-- 
==============================|   "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: r3905 - trunk/dist-tools/shipper

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

Matthias Andree wrote:
> 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.

Bleh.

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

Back when I ran Red Hat (around the same time I last programmed Berkeley 
DB :-), root was required for creating rpms so that the ownerships and 
permissions of the installed files would turn out right.  Eric's "go root 
to make the rpm" release procedure is a remnant of that era, even though 
things have changed since then.

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

Me too, but it'll have to wait until the end of the month.

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

On Sat, 19 Jun 2004 04:20:37 +0200,
Matthias Andree <ma...@dt...> wrote:

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

O.K., sounds good !

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

Will do so, when I'll be done with all my f*cked graphic cards
X11 configurations..   :-(

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

Reasoning above ..

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

Fine with the tarballs.
Sure, it's the right way for ongoing development.

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

Well spoken  :-)

Hi, Matthias, thanks for Your answers!

Next time You don't need do address me personally since
I'm subscribed to fetchmail-devel too ...

THX, bye,

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