Spec URL: http://dl.atrpms.net/all/maildrop.spec SRPM URL: http://dl.atrpms.net/all/maildrop-2.0.3-2.src.rpm Description: maildrop is the mail filter/mail delivery agent that's used by the Courier Mail Server. This is a standalone build of the maildrop mail filter that can be used with other mail servers. maildrop is a replacement for your local mail delivery agent. maildrop reads a mail message from standard input, then delivers the message to your mailbox. maildrop knows how to deliver mail to mbox-style mailboxes, and maildirs.
*** Bug 188477 has been marked as a duplicate of this bug. ***
Maildrop version 2.0.4 was released last April. Can you update to the latest version? When trying to rebuild this srpm with mock I end up with a error: . maildrop/uidgid ; test -z "$gid" && exit 0; test -w /etc || exit 0; cd /var/tmp/maildrop-2.0.3-2.fc7- root/usr/bin && chgrp $gid maildrop lockmail chgrp: changing group of `maildrop': Operation not permitted chgrp: changing group of `lockmail': Operation not permitted make[2]: *** [install-maildrop] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/maildrop-2.0.3' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/builddir/build/BUILD/maildrop-2.0.3' make: *** [install-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.39432 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.39432 (%install) Error building package from maildrop-2.0.3-2.fc7.src.rpm, See build log
(In reply to comment #2) > Maildrop version 2.0.4 was released last April. Can you update to the latest version? OK, will do so. > When trying to rebuild this srpm with mock I end up with a error: > > . maildrop/uidgid ; test -z "$gid" && exit 0; test -w /etc || exit 0; cd /var/tmp/maildrop-2.0.3-2.fc7-root/usr/bin && chgrp $gid maildrop lockmail > chgrp: changing group of `maildrop': Operation not permitted > chgrp: changing group of `lockmail': Operation not permitted I don't see that here, and according to the above: o you don't have root privileges (that's perfectly OK), but o you are allowed to write in /etc nonetheless So something looks wrong in the chroot setup. Is /etc in there really writable by the mock user? If so, fix this and the build should succeed.
Spec URL: http://dl.atrpms.net/all/maildrop.spec SRPM URL: http://dl.atrpms.net/all/maildrop-2.0.4-3.src.rpm * Sat Aug 4 2007 Axel Thimm <Axel.Thimm> - 2.0.4-3 - Update to 2.0.4.
I just only tried to rebuild 2.0.4-3 and it seems okay. http://koji.fedoraproject.org/koji/taskinfo?taskID=89925
Well, I retried and this time the rebuild failed... http://koji.fedoraproject.org/koji/taskinfo?taskID=121364
Axel, would you recheck the build log on my comment 6 and upload a new srpm?
So the difference in the two builds on rawhide was just the age of rawhide? E.g. something that entered rawhide from the 5th to the 23rd broke maildrop? I'm currently officially afk with Ville looking over my packages - don't know if that includes my review requests. I think this is important to find out why it fails, as it may be a rawhide regression, but I won't be able to look into it during the next 10 days or even more. Could you dig into this? Thanks!
After checking maildrop/buffer.C (where compilation failed) and configure, it turned out that this was due to "BuildRequies: gawk" :( I think the compilation log should be more verbose, not just showing the message "Compiling maildirmake.c" or so so that we can check if compilation flags are honored correctly. The following should work (see http://koji.fedoraproject.org/koji/taskinfo?taskID=144270 ) ------------------------------------------------- for f in `find . -name Makefile.in` ; do sed -i.silent -e 's|@echo |echo |' -e 's|@rm |rm |' $f done ------------------------------------------------- I will check later if there are any issues else to be fixed later
For 2.0.4-3: * Missing BR: - Add "gawk" for BuildRequires. * Compilation log - Make compilation log verbose so that we can check if Fedora specific compilation flags are honored correctly. * rpmlint: From rpmlint: A. -------------------------------------------------------- E: maildrop setuid-binary /usr/bin/maildrop root 06755 (and similar lines) -------------------------------------------------------- ? Just to confirm, would you explain why these binaries should have setuid/setgid? B. --------------------------------------------------------- W: maildrop invalid-license GPL --------------------------------------------------------- - Please update license tag. C. --------------------------------------------------------- W: maildrop undefined-non-weak-symbol /usr/lib/librfc2045.so.0.0.0 rfc2047_qp_allow_any W: maildrop undefined-non-weak-symbol /usr/lib/librfc822.so.0.0.0 unicode_ISO8859_1 ( and similar lines omittted) --------------------------------------------------------- - libraries in -devel subpackage contains undefined non-weak symbols (also can be checked by "ldd -r"). This is unpleasant because this causes linkage failure.
ping?
ping again?
(In reply to comment #10) > E: maildrop setuid-binary /usr/bin/maildrop root 06755 > (and similar lines) > -------------------------------------------------------- > ? Just to confirm, would you explain why these binaries > should have setuid/setgid? See http://www.courier-mta.org/maildrop/maildrop.html for details, but in short: Every MTA that runs as a non-root user need an MDA that is suid root, otherwise you would never be able to put mails into users' mboxes/maildirs etc.
So would you fix the rest issues?
http://dl.atrpms.net/all/maildrop-2.0.4-4.src.rpm http://dl.atrpms.net/all/maildrop.spec I forgot to fix the license tag, consider this part of "-5". :)
Still the following issues are not fixed. (In reply to comment #10) > * Compilation log > - Make compilation log verbose so that we can check if > Fedora specific compilation flags are honored correctly. > > * rpmlint: > B. > --------------------------------------------------------- > W: maildrop invalid-license GPL > --------------------------------------------------------- > - Please update license tag. > > C. > --------------------------------------------------------- > W: maildrop undefined-non-weak-symbol /usr/lib/librfc2045.so.0.0.0 > rfc2047_qp_allow_any > W: maildrop undefined-non-weak-symbol /usr/lib/librfc822.so.0.0.0 unicode_ISO8859_1 > ( and similar lines omittted) > --------------------------------------------------------- > - libraries in -devel subpackage contains undefined non-weak > symbols (also can be checked by "ldd -r"). > This is unpleasant because this causes linkage failure.
As said in comment #15 please consider the license tag fixed in the next iteration (befor e the import). I don't think it will be better to increase verbosity - in general the more verbose the logs the worse SNR you get and the more errors can slip. As to the non-weak symbols - what do you suggest to do to fix it? maildrop seems to work well. Perhaps these symbols are even undefined on purpose in case there are multiple possible variants for them. At least that is a valid use of undefined symbols.
(In reply to comment #17) > As to the non-weak symbols - what do you suggest to do to fix it? maildrop seems > to work well. Perhaps maildrop itself can be used with these undefined non-weak symbols are left. The problem is that these undefined non-weak symbols make it impossible that the libraries in maildrop are linked from other libraries/applications. So if you want to provide -devel package, this must be fixed. > Perhaps these symbols are even undefined on purpose in case there > are multiple possible variants for them. This is not because unicode_ symbols are provided by the codes under unicode/ subdirectory in maildrop, and the others are also provided by the codes in maildrop. So simply linking is not correct for these libraries. I found the related discussion here: http://www.nabble.com/Problems-using-rfc822-and-rfc2045-libraries-tf3292776.html#a9158612
> I found the related discussion here: > http://www.nabble.com/Problems-using-rfc822-and-rfc2045-libraries-tf3292776.html#a9158612 This discussion revolves around building it all static, which is not a favoured Fedora model. :/ From the surface it looks like the bug is in not installing libunicode when asking for shared libs, do you agree? I'll try to get upstream's POV on that.
(In reply to comment #19) > From the surface it looks like the bug is in not installing libunicode when > asking for shared libs, do you agree? I'll try to get upstream's POV on that. Yes, this is one of the problem. When libunicode is installed properly as a shared library, linkage must be fixed according to that.
Any response from upstream?
I recontacted upstream on the list this time.
The resolve is that these (small) libs were never intended to be shared (and used by anything else but myildrop itself) - autotooling the project just popped out the --enable-shared option. There are two ways to fix it: o patch up the sources to really allow shared libs - but upstream is not interested in doing so - they might actually even shut down shared libs in general. o go static I think I prefer the latter, would you agree?
I prefer to go static.
I have a maildrop-2.0.4 srpm. It builds on f8, only has a couple of (easily fixed) rpmlint warnings (nothing about weak symbols). I put it here: https://nbecker.dyndns.org/RPM/maildrop-2.0.4-1.fc8.src.rpm I also have courier-authlib. It has a number of rpmlint errors. Feel free to fix them. I don't really use this lib myself, so have little incentive.
Just a note here as I am using Axel's 2.0.4-5 SRPM on my EL5 system. I wanted to use maildrop with virtual users which you can either hand-code logic for in your maildroprc file or make use of courier-authlib. I wanted to use courier-authlib. Issues I ran in to: * courier-authlib isn't yet packaged for Fedora/EL (easy enough to fix this) * maildrop appears to only build in support for courier-authlib if courier-authlib is already on the system. I built the courier-authlib RPM from the included .spec file and installed the courier-authlib-devel package and _then_ built Axel's maildrop RPM and was able to end up with a maildrop that supports courier-authlib. Anyways, just something to keep in mind -- especially for a future packager of courier-authlib.
There is no progress on this package. Please, would someone else like to take over this?
Once setting NEEDINFO to Axel. Would you package static archive (if shared library is impossible for now) and reupload the new srpm?
The package was fixed shortly after comment #25 http://dl.atrpms.net/all/maildrop.spec http://dl.atrpms.net/all/maildrop-2.0.4-5.src.rpm * Sun Jan 13 2008 Axel Thimm <Axel.Thimm> - 2.0.4-5 - Go static.
For 2.0.4-5: * License tag - License tag "GPL" is no longer valid for Fedora. http://fedoraproject.org/wiki/Packaging/LicensingGuidelines http://fedoraproject.org/wiki/Licensing * Static archive only -devel subpackage packaging - For static archive only -devel subpackage, please follow "Packaging Static Libraries" subsection of http://fedoraproject.org/wiki/Packaging/Guidelines * /sbin/ldconfig - Why is calling of /sbin/ldconfig on %post/%postun needed? * Header file include: - For example, /usr/include/rfc2045.h contains: --------------------------------------------------------------- 12 #include "../rfc2045/rfc2045_config.h" /* VPATH build */ --------------------------------------------------------------- but rfc2045_config.h does not exist. ! fedora specific compilation flags - Well, now from build.log, I cannot check if Fedora specific compilation flags are correctly honored (from the output like below:) --------------------------------------------------------------- 1932 make[2]: Entering directory `/builddir/build/BUILD/maildrop-2.0.4/numlib' 1933 Compiling atotimet.c 1934 Compiling atouidt.c 1935 Compiling changeuidgid.c 1936 Compiling strdevt.c 1937 Compiling strgidt.c --------------------------------------------------------------- Please make the build.log more verbose so that we can check how compiler flags are used from build.log. ! /usr/bin/sendmail - Well, perhaps no one except for me may complain about this, however currencly sendmail license is in question (ref: bug 409361). Is it possible to make this package avoid sendmail?
Thanks for the review, all points are valid, and are connected to the static vs shared setup, but the sendmail issue: Even if sendmail is not part of the distro /usr/bin/sendmail has become a canonical call to the MTA. exim, postfix etc. replace that symlink with alternatives to pointing to themselves. E.g. any MTA will offer /usr/bin/sendmail and any package needing a local MTA uses it be that maildrop or mutt etc.
(In reply to comment #32) > Even if sendmail is not part of the distro > /usr/bin/sendmail has become a canonical call to the MTA. exim, postfix etc. > replace that symlink with alternatives to pointing to themselves. > > E.g. any MTA will offer /usr/bin/sendmail and any package needing a local MTA > uses it be that maildrop or mutt etc. Ah, exactly. Thanks!
http://dl.atrpms.net/all/maildrop.spec http://dl.atrpms.net/all/maildrop-2.0.4-6.src.rpm * Sat Mar 8 2008 Axel Thimm <Axel.Thimm> - 2.0.4-6 - Try a better license tag. - Remove all devel parts - this is not upstream-ready yet. - Make the build verbose.
Well - Please don't use http://prdownloads. URL so that we can download source directly by wget -N, for example. The following is fine. http://downloads.sourceforge.net/courier/maildrop-2.0.4.tar.bz2 - The license tag is okay with "GPLv2 with exceptions". (Current accepted license tags are listed in /usr/share/rpmlint/config). Other things are okay. ------------------------------------------------------------------------ This package (maildrop) is APPROVED by me ------------------------------------------------------------------------
Thanks Mamoru! New Package CVS Request ======================= Package Name: maildrop Short Description: Mail delivery agent with filtering abilities Owners: athimm Branches: F-7 F-8 InitialCC: Cvsextras Commits: no (too many people in this group)
cvs done.
The license tag used[1] in the checked in spec file is invalid. I think simply using GPLv2 with exceptions would be sufficient, though there isn't an entry on the Licensing guidelines page specifically covering the openssl exception. Perhaps there ought to be such an entry. Spot? [1] GPLv2 with OpenSSL exception
maildrop-2.0.4-6.fc7 has been submitted as an update for Fedora 7
maildrop-2.0.4-6.fc8 has been submitted as an update for Fedora 8
(In reply to comment #38) > The license tag used[1] in the checked in spec file is invalid. I think simply > using GPLv2 with exceptions would be sufficient, though there isn't an entry on > the Licensing guidelines page specifically covering the openssl exception. > Perhaps there ought to be such an entry. Spot? > > [1] GPLv2 with OpenSSL exception This doesn't merit a specific entry in the guideline, just change the License tag to be: License: GPLv2 with exceptions
maildrop-2.0.4-6.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
maildrop-2.0.4-6.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
I'm still seeing maildrop lacks of courier-authlib support - seems you didn't have courier-authlib-devel installed while building maildrop, as mentioned in Comment #27. And maildrop built here is using different versioning compare with what Courier recommended, I have to bump up version by changing spec file in bz2 download from courier to make sure it won't be "upgraded" by yum.
(In reply to comment #44) > I'm still seeing maildrop lacks of courier-authlib support - > ........ (all snip) Please file a RFE against maildrop and don't use this review.
Package Change Request ====================== Package Name: maildrop New Branches: EL-4 EL-5 Owners: nb
Axel has indicated that he does not wish to participate in EPEL, so I've branched this without awiting for an ack from him. CVS done.