Spec URL: http://michich.fedorapeople.org/openCryptoki/openCryptoki.spec SRPM URL: http://michich.fedorapeople.org/openCryptoki/openCryptoki-2.2.8-2.fc11.src.rpm Description: openCryptoki implements the PKCS#11 specification v2.11. It includes support for cryptographic hardware such as the Trusted Platform Module (TPM) as well as a software token for testing. Scratch build in Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1489377 rpmlint output: openCryptoki.src: W: strange-permission pkcs_slot.sh 0755 openCryptoki.src: W: strange-permission pkcs11_startup.sh 0755 -- 0755 is reasonable permission for executable scripts. openCryptoki-devel.x86_64: W: no-documentation -- True, but I don't think it's necessary to include the PKCS#11 specification in the package. openCryptoki.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opencryptoki/stdll/libpkcs11_sw.so openCryptoki.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opencryptoki/libopencryptoki.so openCryptoki.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opencryptoki/stdll/libpkcs11_tpm.so -- The *.so files are needed for openCryptoki to work as expected. The pkcs11_startup script must find /usr/lib64/opencryptoki/stdll/*.so , otherwise the daemon won't run. And the documentation suggests that applications should dlopen PKCS11_API.so (which is a symlink to libopencryptoki.so). openCryptoki.x86_64: W: non-standard-gid /var/lib/opencryptoki pkcs11 openCryptoki.x86_64: E: non-standard-dir-perm /var/lib/opencryptoki 0770 -- /var/lib/opencryptoki is owned by root:pkcs11. The pkcs11 group is created in %pre scriptlet. openCryptoki.x86_64: W: dangling-relative-symlink /usr/lib64/opencryptoki/methods ../../sbin openCryptoki.x86_64: W: dangling-relative-symlink /usr/lib64/pkcs11/methods ../../sbin -- The symlinks point to /usr/sbin, which is always present (owned by the "filesystem" package). openCryptoki.x86_64: W: non-conffile-in-etc /etc/ld.so.conf.d/opencryptoki-x86_64.conf openCryptoki.x86_64: W: incoherent-init-script-name pkcsslotd ('opencryptoki', 'opencryptokid') -- This is intentional, pkcsslotd is the name of the daemon. There was a review request for openCryptoki some time ago, but it was abandoned (bug 426152). BTW, openCryptoki can provide access to interesting cryptographic hardware on s390, but it's not what I'm focusing on for now.
(In reply to comment #0) > BTW, openCryptoki can provide access to interesting cryptographic hardware on > s390, but it's not what I'm focusing on for now. And I am interested exactly in the s390(x) stuff and have an almost ready package too :-)
My spec: http://fedora.danny.cz/s390/openCryptoki.spec
Updated spec and SRPM: http://michich.fedorapeople.org/openCryptoki/opencryptoki.spec http://michich.fedorapeople.org/openCryptoki/opencryptoki-2.2.8-4.fc11.src.rpm
*** Bug 426152 has been marked as a duplicate of this bug. ***
One more update: http://michich.fedorapeople.org/openCryptoki/opencryptoki.spec http://michich.fedorapeople.org/openCryptoki/opencryptoki-2.2.8-5.fc11.src.rpm The only change from -4 is that opencryptoki now Requires opencryptoki-libs using arch-specific dependency.
formal review is here, see the notes below: OK source files match upstream: c20e52f19a22cb9695b8298ca11481f3106e3c8d opencryptoki-2.2.8.tar.bz2 OK package meets naming and versioning guidelines. OK specfile is properly named, is cleanly written and uses macros consistently. OK dist tag is present. OK license field matches the actual license. OK license is open source-compatible (CPL). License text included in package. OK latest version is being packaged. OK BuildRequires are proper. OK compiler flags are appropriate. OK %clean is present. OK package builds in mock (Rawhide/x86_64). OK debuginfo package looks complete. OK rpmlint is silent. OK final provides and requires look sane. N/A %check is present and all tests pass. OK no shared libraries are added to the regular linker search paths - extra ld.so.conf file added OK owns the directories it creates. OK doesn't own any directories it shouldn't. OK no duplicates in %files. OK file permissions are appropriate. OK correct scriptlets present. OK code, not content. OK documentation is small, so no -docs subpackage is necessary. OK %docs are not necessary for the proper functioning of the package. OK headers in devel OK no pkgconfig files. OK no libtool .la droppings. OK not a GUI app. - rpmlint complains a bit: opencryptoki.x86_64: W: non-standard-gid /var/lib/opencryptoki pkcs11 opencryptoki.x86_64: E: non-standard-dir-perm /var/lib/opencryptoki 0770 => this is correct setup opencryptoki.x86_64: W: incoherent-init-script-name pkcsslotd ('opencryptoki', 'opencryptokid') => harmless, can be ignored opencryptoki-libs.x86_64: W: non-conffile-in-etc /etc/ld.so.conf.d/opencryptoki-x86_64.conf => this is OK, the file shouldn't be edited by user opencryptoki-libs.x86_64: W: dangling-relative-symlink /usr/lib64/opencryptoki/methods ../../sbin opencryptoki-libs.x86_64: W: dangling-relative-symlink /usr/lib64/pkcs11/methods ../../sbin => this is OK opencryptoki-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opencryptoki/stdll/libpkcs11_tpm.so opencryptoki-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opencryptoki/stdll/libpkcs11_sw.so opencryptoki-libs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opencryptoki/libopencryptoki.so => explained in spec as required, libs should be dlopen-ed probably due license compatibility reasons this package is APPROVED
New Package CVS Request ======================= Package Name: opencryptoki Short Description: Implementation of the PKCS#11 (Cryptoki) specification v2.11 Owners: michich sharkcz Branches: F-10 F-11 InitialCC:
cvs done.
Package imported and built. Thank you.
opencryptoki-2.2.8-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/opencryptoki-2.2.8-5.fc11
opencryptoki-2.2.8-5.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/opencryptoki-2.2.8-5.fc10
opencryptoki-2.2.8-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.