Bug 188477

This is a *very* old version of maildrop - 2.0.2 is current and is vastly
improved on the old 1.x series.

However newer versions dependent on a courier-authlib package at both build and
runtime and no such package exists yet in Extras.

Additionally, fam-devel no longer exists in Core (replace that with gamin-devel)
and you might want to swap gdbm for db (--with-db=db in configure) as I find the
latter a little more reliable.

The spec definitely needs some work before it's ready for Extras (many of the
%defines are not needed or not desirable, "make install" is preferred of "make
install-strip" among others)

On the upside, I've been packaging both this and maildrop for a while now (and
courier-imap, but the spec file is a disaster area hence why I've not submitted
it) If you want to try a more modern version I'm happy to put my courier-authlib
package for review and you can build off of that.

You can also have a look at the spec if you like (it too is built off Sam's
distribution specfile but has been hacked around quite a bit since then)

http://www.enlartenment.com/packages/fedora/5/SRPMS/courier-authlib-0.58-1.fc5.mf.src.rpm
http://www.enlartenment.com/packages/fedora/5/SRPMS/maildrop-2.0.2-1.fc5.mf.src.rpm

I'm sorry, I meant maildrop-2.0.2. 
 
I didn't notice any need for courier-authlib.  I don't have it and am using 
maildrop fine - maybe I'm not using those features?  I'm only using it's mail 
filtering (as a procmail alternative). 
 
The spec file I used is from maildrop upstream with no change. 
 

I have looked at your suggestions and made a new version:  
 
http://nbecker.dyndns.org:8080/maildrop.spec 
http://nbecker.dyndns.org:8080/maildrop-2.0.2-2.5.src.rpm 
 
AFAICT, courier-authlib is an optional part.  Does anyone object to omitting 
it?   

Mass-block FE-NEEDSPONSOR for the six review requests¹ of Neal Becker. Neal, 
when you get sponsorship, you will have to unblock it for all your requests.

¹) Actually the four that do not block yet FE-NEEDSPONSOR.

(In reply to comment #3)
> AFAICT, courier-authlib is an optional part.  Does anyone object to omitting 
> it?   

I'm currently using maildrop with courier-authlib. When a new version of
maildrop (of courier-authlib) is released I manualy build and upgrade the RPMS.
I would appreciate support for courier-authlib in this maildrop package. As far
as i know courier-authlib is not yet in FE or under review. Can I do anything to
help with that? 

Does it make sense to package courier-authlib separately, or is it only a 
compile-time option?

(In reply to comment #6)
> Does it make sense to package courier-authlib separately, or is it only a 
> compile-time option?

I believe packaging a separate courier-authlib makes sense. From the courier
website: "The Courier Authentication Library is a generic authentication API
that encapsulates the process of validating account passwords. (...) The Courier
authentication library must be installed before building any Courier packages
that needs direct access to mailboxes.".

Besides that, packaging courier-authlib as a seperate package for FE makes it
possible/easier to package other courier software (i.e. courier-mta org
courier-imap) for FE.

Check this:

http://www.enlartenment.com/packages/fedora/5/SRPMS/courier-authlib-0.58-1.fc5.mf.src.rpm

(In reply to comment #8)
> Check this:

Looks great. In comment #1 Michael proposed to submit that package for review in
Extras. Is that offer still available? Otherwise I could make this my first
package contribution to FE, but I'm pretty confident that would take more time
then when Michael puts his package up for review.

In any case, I don't think courier-authlib is a blocker for this review. The
maildrop package can always be 'improved' when/if courier-authlib becomes
available in FE.

Removing FE-NEEDSPONSOR since Neal is in cvsextras

(In reply to comment #1)
> This is a *very* old version of maildrop - 2.0.2 is current and is vastly
> improved on the old 1.x series.
> 
> However newer versions dependent on a courier-authlib package at both build 
and
> runtime and no such package exists yet in Extras.
> 
> Additionally, fam-devel no longer exists in Core (replace that with 
gamin-devel)
> and you might want to swap gdbm for db (--with-db=db in configure) as I find 
the
> latter a little more reliable.
> 
> The spec definitely needs some work before it's ready for Extras (many of 
the
> %defines are not needed or not desirable, "make install" is preferred 
of "make
> install-strip" among others)
> 
> On the upside, I've been packaging both this and maildrop for a while now 
(and
> courier-imap, but the spec file is a disaster area hence why I've not 
submitted
> it) If you want to try a more modern version I'm happy to put my 
courier-authlib
> package for review and you can build off of that.
> 
> You can also have a look at the spec if you like (it too is built off Sam's
> distribution specfile but has been hacked around quite a bit since then)
> 
> 
http://www.enlartenment.com/packages/fedora/5/SRPMS/courier-authlib-0.58-1.fc5.mf.src.rpm
> 
http://www.enlartenment.com/packages/fedora/5/SRPMS/maildrop-2.0.2-1.fc5.mf.src.rpm


Mike, are you going to pursue submitting this to fedora-extras?

(In reply to comment #11)
> Mike, are you going to pursue submitting this to fedora-extras?

FYI: A courier-authlib RPM is the review process now #208064 

Yeah, I'll finish the review when I get a spare half hour (there's not much left
to do IIRC). I've been quite busy at work so spare time is a premium :-).

I might submit my courier-imap package once that's done, but getting it to play
nice with rpmlint could be challenging (the existing spec and upgrade methods
are... *interesting* as I try and keep Sam's way of doing things as best possible)

Then.. what is the status of this bug?

FYI: Version 2.0.3 of maildrop was released last December

Whoops. Restoring NEEDINFO for this review, as I accidently removed it

Recently procmail caused me some mail loss, and the bug is unfixable due to lack
of maintainership for the last 6 years, so I moved to maildrop. The URLs in this
report have went all bad, so I had to package from scratch.

I've placed the packages in ATrpms and would be more than willing to submit them
into Fedora.  Should I take over this report or create a new one?

I'm using maildrop-2.0.2.  Maybe you'd like to compare the spec file I've been 
using.  It is here:
https://nbecker.dyndns.org/RPM/maildrop.spec

(In reply to comment #18)
> I've placed the packages in ATrpms and would be more than willing to submit them
> into Fedora.  Should I take over this report or create a new one?

Since this review seems to be stalled, I see no problem when you take over this report.

Axel is there any progress in maildrop package submit?

Here it is

http://dl.atrpms.net/all/maildrop-2.0.3-2.at.src.rpm
http://dl.atrpms.net/all/maildrop.spec

But I think I'm supposed to reopen a new bugzilla ticket.

*** This bug has been marked as a duplicate of 241596 ***

It is now more than 1 year since I proposed adding this package and posted an 
RPM for review.  Since there has been no progress, I propose to resubmit this.

Here is an updated package:

https://nbecker.dyndns.org/RPM/maildrop-2.0.4-1.fc7.src.rpm
https://nbecker.dyndns.org/RPM/maildrop.spec

Neal, this bug is closed (duplicate) since *yesterday*, when Axel Trimm has 
submitted bug #241596.