http://scop.fedorapeople.org/packages/portecle.spec http://scop.fedorapeople.org/packages/portecle-1.3-1.fc9.src.rpm Portecle is a user friendly GUI application for creating, managing and examining keystores, keys, certificates, certificate requests, certificate revocation lists and more. F9+ only because bouncycastle >= 1.38 is needed. rpmlint is silent.
Should add gtk-update-icon-cache scriptlet http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda Any reason for not adding doc directory to %doc?
any timeline for releasing bouncycastle >= 1.38?
(In reply to comment #2) > any timeline for releasing bouncycastle >= 1.38? sorry its already in rawhide. I checked on F-8 system.
http://scop.fedorapeople.org/packages/portecle.spec http://scop.fedorapeople.org/packages/portecle-1.3-2.fc8.src.rpm * Thu Jan 10 2008 Ville Skyttä <ville.skytta at iki.fi> - 1.3-2 - Update GTK icon cache in post(un)install scriptlets (#425834). Good catch, thanks. Stuff in doc/ is not included as %doc because practically all of it is online help which is already packaged inside the jar and accessible through Portecle's "Help" menu. I don't have that strong opinions about it though; if you think it's better to include a second copy of the whole docs set as %doc, I can add it.
Sometimes (many times actually) I prefer to read the docs from a browser or using less without starting the application. Maybe a portecle-docs including just the docs, which can be installed by those like me who want the docs and don't care about the space on disk would be suited here? Plus a short polite note (in %desc for instance) "the docs are also available in a separate package, use yum install blablah to install them". And I would not impose any requires between the base and the -docs package, since they would be quite independent of each other.
I don't like the -docs subpackage idea. BTW, all the docs are available also on the portecle.sf.net website. I'm thinking about looking into what kind of patchwork would it be to install the docs to /usr/share/doc/$name-$version-$release and to have the Portecle online help system use them from there instead of from inside the jar.
I meant to say that I'll look into the patchwork mentioned in comment 6 if you think it's necessary to get the package approved - personally I think this is fine as is. Let me know if you consider it a blocker; I'm leaving the package as is until then.
Review: + package builds in mock (rawhide i386). + rpmlint is silent for SRPM and for RPM. + source files match upstream. cc32721356f60caa12517dbc82538af8 portecle-1.3-src.zip + package meets naming and packaging guidelines. + specfile is properly named, is cleanly written + Spec file is written in American English. + Spec file is legible. + dist tag is present. + build root is correct. + license is open source-compatible. + License text is included in package. + %doc files present. + BuildRequires are proper. + Compiler flags used correctly. + defattr usage is correct + %clean is present. + package installed properly. + Macro use appears rather consistent. + Package contains code. + no static libraries. + no .pc file present. + no -devel subpackage exists. + no .la files. + no translations are available. + Does owns the directories it creates. + no duplicates in %files. + file permissions are appropriate. + gtk-update-icon-cache and update-desktop-database scriptlets are used. + Desktop file installed correctly. + GUI app. APPROVED.
Thanks! Manuel, I have added your comments to my TODO list for things to look into when I'm preparing the next upstream Portecle release. http://portecle.svn.sourceforge.net/viewvc/portecle/trunk/TODO.txt?r1=456&r2=468 New Package CVS Request ======================= Package Name: portecle Short Description: Multipurpose keystore and certificate tool Owners: scop Cvsextras Commits: yes
Thanks for taking it into consideration. My idea was just to provide a means to see the docs even if - you are offline (i.e. no net access, maybe on a laptop), and - for whatever reason you do not wish to run the application itself. This however should not impede using the help system of the application. Your idea about the merge (comment #6) seems perfect, if feasible without too much hassle.
cvs done.
Built for devel, closing. http://koji.fedoraproject.org/koji/buildinfo?buildID=31789
portecle-1.4-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/portecle-1.4-2.fc10
portecle-1.4-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.