Spec Url: http://silassewell.googlecode.com/svn/trunk/projects/packages/rpms/lamson/lamson.spec SRPM Url: http://silassewell.googlecode.com/files/lamson-0.8.4-1.fc10.src.rpm Description: Lamson is a modern Pythonic mail server built like a web application server. rpmlint [silas@silas rpmbuild]$ rpmlint /var/lib/mock/fedora-10-i386/result/*.rpm 2 packages and 0 specfiles checked; 0 errors, 0 warnings.
This seems to be an interesting project - nice to have it packaged for Fedora. I will look forward to play with it. I have looked briefly at the package. Upstream tar contains GPLv3 LICENSE file. But PKG-INFO has "License: UNKNOWN" and I can't find any other references to what role the LICENSE file has - if it is GPLv3 only or if later versions also can be used. Why are you using the license tag GPLv3+? Anyway: Upstream should be asked to clarify the license. Upstream has released 0.9.3 - please base the package on that version. Or perhaps go directly to one of the 1.0 pre releases where the chances of getting changes upstreamed are bigger. The package installs a python library and a management binary. I am not familiar with lamson (except for quick browsing through the fine documentation), but using Fedora terminology i would call it an mail application server framework. The application group you have chosen supports that. It can easily generate a mail server which can and should be customized, but that doesn't make it a mail server. It isn't a running server in which you can create mail applications, but it can create individual "servers" for each application. I suggest that you make that clearer in the description. I would expect a mail server to be integrated with Fedora, with for example init.d script and logging to /var/log, and it should only require minimal configuration to get up and running. Obviously those who use lamson as a framework doesn't want that. But perhaps that could be placed in a subpackage? And perhaps a default mail server in an (other?) subpackage? Perhaps the main package could contain an init.d scripts which starts the lamson servers listed in a sysconfig file? I expect lamson mail servers to have issues with SElinux. Have you tried or any opinion on that? But again, as long as the lamson package is a framework and not a server then SElinux isn't its business... -- reviews/sponsor wanted for tortoisehg on bug 509936
(In reply to comment #1) > This seems to be an interesting project - nice to have it packaged for Fedora. > I will look forward to play with it. I have looked briefly at the package. > > Upstream tar contains GPLv3 LICENSE file. But PKG-INFO has "License: UNKNOWN" > and I can't find any other references to what role the LICENSE file has - if it > is GPLv3 only or if later versions also can be used. Why are you using the > license tag GPLv3+? Anyway: Upstream should be asked to clarify the license. The README specifies the license as GPLv3 and does not add the later clause. I have removed the "+" from the spec. > Upstream has released 0.9.3 - please base the package on that version. Or > perhaps go directly to one of the 1.0 pre releases where the chances of getting > changes upstreamed are bigger. When I originally submitted this it was the latest package, I've updated to 1.0pre1. > The package installs a python library and a management binary. I am not > familiar with lamson (except for quick browsing through the fine > documentation), but using Fedora terminology i would call it an mail > application server framework. The application group you have chosen supports > that. It can easily generate a mail server which can and should be customized, > but that doesn't make it a mail server. It isn't a running server in which you > can create mail applications, but it can create individual "servers" for each > application. I suggest that you make that clearer in the description. Updated summary and description. > I would expect a mail server to be integrated with Fedora, with for example > init.d script and logging to /var/log, and it should only require minimal > configuration to get up and running. Obviously those who use lamson as a > framework doesn't want that. But perhaps that could be placed in a subpackage? > And perhaps a default mail server in an (other?) subpackage? > > Perhaps the main package could contain an init.d scripts which starts the > lamson servers listed in a sysconfig file? > > I expect lamson mail servers to have issues with SElinux. Have you tried or any > opinion on that? But again, as long as the lamson package is a framework and > not a server then SElinux isn't its business... Upstream recommends using another "dequeue server ... if you feel you need that security", so I'm going to keep it in the current category for now. http://lamsonproject.org/docs/faq.html
SRPM: http://silassewell.googlecode.com/files/lamson-1.0.0-0.1.pre1.fc12.src.rpm Spec Diff: http://code.google.com/p/silassewell/source/diff?spec=svn289&r=289&format=side&path=/trunk/projects/packages/rpms/lamson/lamson.spec&old_path=/trunk/projects/packages/rpms/lamson/lamson.spec&old=272 rpmlint [silas@fox ~]$ rpmlint /var/lib/mock/fedora-rawhide-i386/result/*.rpm 2 packages and 0 specfiles checked; 0 errors, 0 warnings. NOTE: lamson now requires python-daemon which is only in devel. python-daemon is also currently broken because it requires python-lockfile which is not available in Fedora for yet. I've packaged and submitted a review request for python-lockfile ( https://bugzilla.redhat.com/show_bug.cgi?id=513544 ) and filed a bug against python-daemon ( https://bugzilla.redhat.com/show_bug.cgi?id=513546 ). If you want to test lamson 1.0pre1 you'll need to: - Have Fedora 11+ - rpm -i http://kojipkgs.fedoraproject.org/packages/python-daemon/1.4.6/1.fc12/noarch/python-daemon-1.4.6-1.fc12.noarch.rpm - build and install http://silassewell.googlecode.com/files/python-lockfile-0.8-1.fc12.src.rpm - build and install lamson
Could you please add the appropriate requires and update to the new release pre6 upstream? Then, I'll review this. It would also be great, if you put the documentation into a subpackage, because it's as big as the main programm on its own. Ok, both 'only' 500k, but a matter of point of view.
SPEC http://github.com/silas/rpms/raw/master/lamson/lamson.spec SRPM http://cloud.github.com/downloads/silas/rpms/lamson-1.0-0.2.pre6.fc13.src.rpm I moved the examples directory into the doc subpackage and included the documentation although it isn't very useful without something like: pushd /usr/share/doc/lamson-doc-1.0/output/; python -m SimpleHTTPServer; popd rpmlint [silas@sewell rpmbuild]$ rpmlint /var/lib/mock/fedora-rawhide-i386/result/lamson-*.rpm 3 packages and 0 specfiles checked; 0 errors, 0 warnings.
Review: Good: - License ok, but you should query upstream to add headers in .py files - %files section ok - permissions ok - BR/R ok - contains permissable content - contains %check section - name 'pre' is not in the guidelines examples, but I consider this as completely ok - noarch - no locales to handle - no .la files - no devel needed - macros everywhere - no header files - no pc files - doc package ok - no gui -> no .desktop Needswork: - https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define - group is wrong: System Environment/Daemons would fit better - I talked upstream to correct the nasty %prep commands. It's tracked in http://support.lamsonproject.org/tktview/6e717821c1e513ce888252276ef8b6524861d9d0 The author of lamson said, he wants to have a release out later today. __________________________________ These are only minor issues, so I'll approve this now, but only import the next release into cvs... __________________________________ APPROVED
I fixed the global vs define issue. I disagree on your assertion that it should be assigned to the "System Environment/Daemons" group. I consider Lamson analogous to frameworks like Tornado, Django and CherryPy. Example Django Usage 1. django-admin.py startproject helloworld 2. cd helloworld 3. python manage.py runserver 4. etc... Example Lamson Usage 1. lamson gen -project helloworld 2. cd helloworld 3. lamson start 4. etc.. For both Django and Lamson they recommend using an external server for relaying/proxing traffic (http/nginx for Django and Postfix for Lamson). ====================================================================== Lamson FAQ http://lamsonproject.org/docs/faq.html ====================================================================== Why does Lamson send messages to a relay host? Lamson doesn’t have to deliver to a relay host, but it is a smarter more practical use of the technology. Lamson is written in Python and does actually run slower than the established mail servers. In addition, Lamson is hopefully doing something more than just routing email around to people. It is probably processing messages, crafting replies, querying databases, hitting REST interfaces, and all the other things you’d want to do with a modern application. This takes time and resources and are probably more valuable operations than just simple delivery. For this reason, you want to use a dumb workhorse like Postfix to do your actual delivery, and reserve the smart processing that has value for Lamson.
Hmm, yes, then it's my fault... I wanted to use Lamson as a 'workhorse' itself and therefore the daemon group... Development/Languages is ok. Just had a wrong imagination of that group, it's clear now... Thanks.
New Package CVS Request ======================= Package Name: lamson Short Description: A Python SMTP server Owners: silas Branches: F-12 InitialCC:
cvs done.
Built and submitted to F-12 testing. Thanks Thomas and Kevin.
Orphaning per upstreams request. > ... > > I would actually prefer it if Lamson not be included in Fedora, but this > being a GPL project you are free to do what you want with it. However, > my strict policy on the various linux distros is that I provide no > support to people who use your packages because your modifications and > practice of carving projects into multiple disconnected pieces increases > my support load. > > If you do package it, then I'll be sending people who have bugs and use > your package to you. > > Again, not trying to be mean, just trying to avoid problems that come > from package management.