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
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.
* 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.
+ package builds in mock (rawhide i386).
+ rpmlint is silent for SRPM and for RPM.
+ source files match upstream.
+ 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.
Manuel, I have added your comments to my TODO list for things to look into when
I'm preparing the next upstream Portecle release.
New Package CVS Request
Package Name: portecle
Short Description: Multipurpose keystore and certificate tool
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
Built for devel, closing.
portecle-1.4-2.fc10 has been submitted as an update for Fedora 10.
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.