Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ssmtp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188400 ------- Additional Comments From pertusus@xxxxxxx 2006-10-09 09:35 EST ------- (In reply to comment #25) > At the first glance (therefore I might be wrong) Debian's v8 patch includes > - LIBS="$LIBS -lssl" > + LIBS="$LIBS /usr/lib/libgnutls-openssl.so" > which I think that breaks x86_64 compatibility. That's exactly what I was referring to when saying that the switch to gnutls wasn't done cleanly. > I was not able to find an URL for the version of patch I use, the only ones > still available seem to be revisions 2, 8 and 9. I have included a commented > line in the spec which points to the current Debian patch. Ok. > As I have said, I prefer to have the patches named similar to the other patches > used by the RH packaging system (where the filenames end in "patch" rather then > "diff"). Patches may perfectly be named with .diff. But I have no problem if you prefer .patch. You should post an url to the updated src.rpm when you have changed it. I knew where to search but it is much less convenient, and a reviewer coming at the end of the review wouldn't find it. I still see one issue, the %{version} in Patch0 will lead to something wrong if it changes. It seems more prudent to hardcode the version instead. Not a blocker. And also some compiler warning may seem worrisome, stil not a blocker in my opinion. Here is the formal review: * rpmlint output is ignorable (right symlinks, virtual provides, alternative provide): W: ssmtp unversioned-explicit-provides MTA W: ssmtp unversioned-explicit-provides smtpdaemon W: ssmtp unversioned-explicit-provides %{_sbindir}/sendmail W: ssmtp symlink-should-be-relative /usr/sbin/sendmail.ssmtp /usr/sbin/ssmtp W: ssmtp symlink-should-be-relative /usr/bin/newaliases.ssmtp /usr/sbin/ssmtp W: ssmtp symlink-should-be-relative /usr/bin/mailq.ssmtp /usr/sbin/ssmtp * follows naming and packaging guidelines * free software, licence included * spec legible * source match upstream: 957e6fff08625fe34f4fc33d0925bbc9 ../SOURCES/ssmtp_2.61.orig.tar.gz * %files section right * use almost latest version, as the latest version corresponds with a debian patchset which may not be straightforward to include * sane provides: Provides: /usr/sbin/sendmail MTA config(ssmtp) = 2.61-8 smtpdaemon There is a controversy about smtpdaemon, so it is right to leave it to the packager. This is potentially approved once you are sponsored. You seem to be ready to follow the guidelines, you have the required skills. The most important thing is to be sure that you'll remain interested in maintaining your packages in fedora. I guess this will be the case since you didn't abandoned the submission after 5 months... I am almost ready to sponsor you. To be sure I would prefer if you could show even more interest in fedora extras by doing things advertized there: http://fedoraproject.org/wiki/Extras/HowToGetSponsored -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review