Spec URL: https://pagure.io/digidoc4-client/blob/master/f/digidoc4.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/cserpentis/open-eid/fedora-rawhide-x86_64/00768885-digidoc4-client/digidoc4-client-4.0.0-2.fc29.src.rpm Description: Application for digitally signing and encrypting documents; the software includes functionality to manage Estonian ID-card - change pin codes, update certificates etc Fedora Account System Username: cserpentis This is a complete rewrite of an application qdigidoc and is replacing existing applications qdigidoc and qesteidutil as a unified application for handling everything related to Estonian ID card including management of the card and it's certificates, giving and validating digital signatures as well as encryption.
SPEC is 404.
Sorry, I've just moved it to https://pagure.io/digidoc4-client/blob/master/f/digidoc4-client.spec in order to comply with review guidelines.
(In reply to Robert-André Mauchin from comment #1) > SPEC is 404. Since I've just renamed the spec file a couple of minutes before your comment (in order to comply to review guidelines) and am unable to edit initial comment - should I re-open the request for review or is this one acceptable?
No, no need to reopen. It just need a reviewer. I'm taking a few days off til next Monday, if it isn't reviewed by then I'll have a look. Just remind me if you don't see me by then.
(In reply to Robert-André Mauchin from comment #4) > No, no need to reopen. It just need a reviewer. I'm taking a few days off > til next Monday, if it isn't reviewed by then I'll have a look. Just remind > me if you don't see me by then. OK, thanks for the explanation and taking a look.
*** I have not officially taken the review *** 1) Spec file name must be: digidoc4-client.spec
(In reply to Germano Massullo from comment #6) > *** I have not officially taken the review *** > > 1) Spec file name must be: digidoc4-client.spec As I've indicated in the first comment #2 - I cannot change the description, so the move I've made is not reflected in the initial description of the ticket. Should I re-create the review request with fixed links? Also, the SHA256 of the sources tarball will not match with upstream, as released version does not include git submodules which prevents it from being built, so sources tarball is pulled from upstream git with --recursive flag. There is a bug opened upstream to fix it (https://github.com/open-eid/DigiDoc4-Client/issues/259)
(In reply to Dmitri Smirnov from comment #7) > (In reply to Germano Massullo from comment #6) > > *** I have not officially taken the review *** > > > > 1) Spec file name must be: digidoc4-client.spec > > As I've indicated in the first comment #2 - I cannot change the description, > so the move I've made is not reflected in the initial description of the > ticket. Do you mean > Spec URL: https://pagure.io/digidoc4-client/blob/master/f/digidoc4.spec ? If yes there is no problem, just fix everything in next comment
I'll just post full new description here: Spec URL: https://pagure.io/digidoc4-client/blob/master/f/digidoc4-client.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/cserpentis/open-eid/fedora-rawhide-x86_64/00768885-digidoc4-client/digidoc4-client-4.0.0-2.fc29.src.rpm Description: Application for digitally signing and encrypting documents; the software includes functionality to manage Estonian ID-card - change pin codes, update certificates etc Fedora Account System Username: cserpentis This is a complete rewrite of an application qdigidoc and is replacing existing applications qdigidoc and qesteidutil as a unified application for handling everything related to Estonian ID card including management of the card and it's certificates, giving and validating digital signatures as well as encryption. The SHA256 of the sources tarball will not match with upstream, since released version does not include git submodules which prevents it from being built, so sources tarball is pulled from upstream git with --recursive flag. There is a bug opened upstream to fix it (https://github.com/open-eid/DigiDoc4-Client/issues/259)
As promised, Monday review: Source0: %{url}/releases/download/v%{version}/%{upstream_name}-%{version}.tar.gz The Source0 must be the same as in the SRPM. So if you need to d/l the git submodules separately, I think you should just use: Source0: %{upstream_name}-%{version}.tar.gz But then you need to add in comment how you generate the archive with the submodules: # git clone --recursive https://github.com/open-eid/DigiDoc4-Client/ # cd DigiDoc4-Client # git checkout v4.0.0 # git submodule update # cd .. # mv DigiDoc4-Client/ DigiDoc4-Client-4.0.0/ # tar zcvf DigiDoc4-Client-4.0.0.tar.gz --exclude-vcs DigiDoc4-Client-4.0.0/ - Split the description for the nautilus subpackage: digidoc4-client-nautilus.x86_64: E: description-line-too-long C The digidoc4-client-nautilus package contains the digidoc4-client extension for the Package otherwise approved. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "GPL (v3) LGPL (v3)", "*No copyright* Ms-RL", "BSD (3 clause)", "LGPL (v2.1 or later)", "*No copyright* LGPL (v2.1 or later)", "*No copyright* Apache (v2.0)". 368 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/digidoc4-client/review- digidoc4-client/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/share/mime, /usr/share/kde4/services, /usr/share/mime/packages, /usr/share/kde4 [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: The spec file handles locales properly. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 10240 bytes in 3 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop-file-validate if there is such a file. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: digidoc4-client-4.0.0-2.fc29.x86_64.rpm digidoc4-client-nautilus-4.0.0-2.fc29.x86_64.rpm digidoc4-client-debuginfo-4.0.0-2.fc29.x86_64.rpm digidoc4-client-debugsource-4.0.0-2.fc29.x86_64.rpm digidoc4-client-4.0.0-2.fc29.src.rpm digidoc4-client-nautilus.x86_64: E: description-line-too-long C The digidoc4-client-nautilus package contains the digidoc4-client extension for the digidoc4-client-nautilus.x86_64: W: no-documentation digidoc4-client.src: W: invalid-url Source0: DigiDoc4-Client-4.0.0.tar.gz 5 packages and 0 specfiles checked; 1 errors, 2 warnings.
New files with fixed issues brought out in the previous comment: SPEC file: https://pagure.io/digidoc4-client/blob/master/f/digidoc4-client.spec SRPM: https://copr-be.cloud.fedoraproject.org/results/cserpentis/open-eid/fedora-rawhide-x86_64/00770857-digidoc4-client/digidoc4-client-4.0.0-3.fc29.src.rpm And the whole copr build from the sources in pagure: https://copr.fedorainfracloud.org/coprs/cserpentis/open-eid/build/770857/
Upstream released the digidoc 4.0 https://github.com/open-eid/DigiDoc4-Client/releases/tag/v4.0.0 and the source file name is qdigidoc4_4.0.0.tar.gz Rather than making a new package, I would change the package review request into a simple "Fedora change review request" https://fedoraproject.org/wiki/Changes A Fedora change review request is generally required for packages major updates My example of Fedora change https://fedoraproject.org/wiki/Changes/Darktable_2_0
Just to cast my vote from a user perspective - it would be great to preserve the same name for non-deprecated version of this identity software.
Dmitri could you please reupload the spec file? The URLs return 404 error. Thank you
Since upstream has released a new version and a name of the tarball has been more consistent with previous version, I've changed the name of spec file. I'm also currently not sure whether it makes more sense to update existing package (as subpackages conflict with qdigidoc version 3 anyways and both cannot be installed in parallel and it seems like developers intend it this way and want v4 to replace v3). Please suggest on what way to proceed would make most sense? Anyways, new spec and SRPM for qdigidoc-4.1.0: Spec URL: https://pagure.io/digidoc4-client/blob/master/f/qdigidoc4.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/cserpentis/open-eid/fedora-29-x86_64/00826752-qdigidoc4/qdigidoc4-4.1.0-1.fc29.src.rpm
Tomorrow I will start working on updating the qdigidoc package, since it is the better way to move to digidoc4
Feel free to include the patch and spec from pagure (https://pagure.io/digidoc4-client/tree/master), The sandbox compilation patch needs a bit adjustment as qt-common file has changed and so have the respective lines. I'm currently experiencing SIGSERV in the built version and will try to investigate what might be going wrong there, but my C++ knowledge is limited and I might need support there.
As soon upstream clarifies https://github.com/open-eid/DigiDoc4-Client/issues/402 I will push everything into Fedora repository
Awesome to hear these news from you guys. I hope to use this new version soon to extend validity of my eID. :)
(In reply to Anatoli Babenia from comment #19) > Awesome to hear these news from you guys. I hope to use this new version > soon to extend validity of my eID. :) Meanwhile, if you have any urgency you can use Dmitri Copr repository https://copr.fedorainfracloud.org/coprs/cserpentis/open-eid
My card is valid until 19.01.2019, and this may become handy. Thanks!
To unify the package with upstreams' views I've decided to rename it to qdigidoc4, as per sources tarball generated by upstream as well as the binary name and informal referral used by developers as well as the fact that it a rewrite of qdigidoc utility. Spec URL: https://pagure.io/DigiDoc4-Client/blob/master/f/qdigidoc4.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/cserpentis/open-eid/fedora-rawhide-x86_64/00836136-qdigidoc4/qdigidoc4-4.2.0-2.fc30.src.rpm The build itself from the sources in the repository and from the spec file: https://copr.fedorainfracloud.org/coprs/cserpentis/open-eid/build/836136/
Issue resolved by reusing existing qdigidoc package, since the devs see this also as organic update of the existing application as well.