Spec URL: https://mdriu.fedorapeople.org/itpp.spec SRPM URL: https://mdriu.fedorapeople.org/itpp-4.3.1-1.fc22.src.rpm Successful koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=11156194 Description: IT++ is a C++ library of mathematical, signal processing and communication classes and functions. Its main use is in simulation of communication systems and for performing research in the area of communications. The kernel of the library consists of generic vector and matrix classes, and a set of accompanying routines. Such a kernel makes IT++ similar to MATLAB, GNU Octave or SciPy. Fedora Account System Username: mdriu Other information: This library used to be packaged for Fedora, but there is no packet maintenance since 2011. Talking about this on #fedora, randomuser convinced me to try to become the maintainer. I already contacted upstream, which of course is happy with that. This is my first package and hence I need a sponsor.
Hi Marco and welcome. Some initial comments about your SPEC file. ##libitpp - The ITPP libraries are compiled and named as 'libitpp'; using this name for your package is the best choice. - Use Source0 for the source code archive. - All documentation files are easily packaged by using '%doc'. - Make sure that 'Make' is verbose by using the CMAKE_VERBOSE_MAKEFILE:BOOL=TRUE option. - "make -C build install DESTDIR=%{buildroot}" is better than cd build make install DESTDIR=%{buildroot} cd .. ##libitpp-devel - There is an arch-specific dependence between -devel and main package; Append Requires: %{name}%{?_isa} = %{version}-%{release} - These BuildRequires calls are already listed for the main package. Redundant here: Requires: fftw-devel Requires: blas-devel Requires: lapack-devel ##libitpp-doc - HTML documentation is not arch-specific. Append "BuildArch: noarch" - It's a stand-alone package that does not need the main one - Use the RPM built-in macro: /usr/bin/itpp-config is %{_bindir}/itpp-config and you don't need to set its permission explicitely. Also, you're packaging extra files in /usr/share/itpp for Octave and Python i think. I don't know if they are still under development (http://sourceforge.net/p/itpp/git/ci/master/tree/extras/) and if their packaging is useful.
Hi Antonio, thanks for your comments. I hope you don't mind some questions before the updated spec and SRPM. > ##libitpp > - The ITPP libraries are compiled and named as 'libitpp'; using this name > for your package is the best choice. Ok, that was a doubt I had in writing the spec. IT++ was formerly called itpp in Fedora, but in other distributions (Ubuntu, Arch, openSUSE) it is called libitpp, so let's go for libitpp, which make more sense also to me. > - All documentation files are easily packaged by using '%doc'. I did not used %doc because "use of %doc with relative paths and installation of files directly into %_pkgdocdir in the same source package is forbidden" (https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation). Indeed, using %doc under the %files section caused the automatic inclusion of %{_pkgdocdir} in the main packet, resulting in html documentation both in itpp and itpp-doc. So, what is the common practice in this case? > ##libitpp-devel > - These BuildRequires calls are already listed for the main package. > Redundant here: > Requires: fftw-devel > Requires: blas-devel > Requires: lapack-devel These were not intended to be BuildRequires, but actual Requires for itpp-devel, since IT++ headers include headers from fftw, blas, and lapack. But maybe I'm missing something. > ##libitpp-doc > - Use the RPM built-in macro: > /usr/bin/itpp-config is %{_bindir}/itpp-config > and you don't need to set its permission explicitely. Here I explicitly set the permission because itpp-config comes out from %build with permissions 555, and rpmlint complains. Do you think I have to fix this in a previous phase, e.g. as a patch? > Also, you're packaging extra files in /usr/share/itpp for Octave and Python > i think. I don't know if they are still under development > (http://sourceforge.net/p/itpp/git/ci/master/tree/extras/) and if their > packaging is useful. I think their packaging is useful because they are (python and octave) scripts for loading and saving variables (from python and octave) using the binary file format of IT++. Apart from that, many thanks again for the comments, and I will update the spec very soon.
>> - All documentation files are easily packaged by using '%doc'. >I did not used %doc because "use of %doc with relative paths and installation >of files directly into %_pkgdocdir in the same source package is forbidden" >(https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation). Indeed, >using %doc under the %files section caused the automatic inclusion of >%{_pkgdocdir} in the main packet, resulting in html documentation both in itpp >and itpp-doc. So, what is the common practice in this case? Prevent installation of documentation or remove the directory automatically created. %install make -C build install DESTDIR=%{buildroot} ##Removing the documentation directory automatically created. rm -rf %{buildroot}%{_pkgdocdir} %check LD_LIBRARY_PATH=$PWD/build/itpp build/gtests/itpp_gtests %post -p /sbin/ldconfig %postun -p /sbin/ldconfig %files %{_libdir}/%{libname}.so.* %{_datadir}/%{name}/ %doc AUTHORS ChangeLog NEWS README VERSION %license COPYING %files devel %{_bindir}/itpp-config %{_mandir}/man1/itpp-config* %{_includedir}/%{name} %{_libdir}/pkgconfig/itpp.pc %{_libdir}/%{libname}.so %files doc %license COPYING %doc build/html
(In reply to Antonio Trande from comment #1) > ##libitpp > - The ITPP libraries are compiled and named as 'libitpp'; using this name > for your package is the best choice. As you suggested, I'm changing the name of the package to libitpp. But I have a question. Do I have to change also all the directories names to libitpp? E.g. %{_includedir}/libitpp , %{_datadir}/libitpp ? This should be the logic thing to do, but doing so causes many problems in the devel and doc packages, because: - all IT++ headers uses 'itpp', e.g. #include <itpp/base/factory.h> - all the IT++ HTML documentation is written accordingly, and hence it is plenty of #include <itpp/...> So, at this stage, I think we have two choices: 1) use itpp as the name of the package, as suggested at the beginning, regardless of the fact that the lib file name is libitpp.so; 2) use libitpp as the name of the package, but leaving the include dir named as %{_includedir}/itpp Earlier versions of the itpp package for fedora (back in 2011) used choice 1). OpenSUSE spec uses choice 2). What do you think?
Ok, at the moment I chose 1 (i.e., use 'itpp' as the package name, regardless of the lib file name), and I updated the spec according to Antonio's suggestions. Spec URL: https://mdriu.fedorapeople.org/itpp.spec SRPM URL: https://mdriu.fedorapeople.org/itpp-4.3.1-1.fc22.src.rpm Successful koji scratch build: koji.fedoraproject.org/koji/taskinfo?taskID=11169649 Further revisions are more than welcome :)
>Do I have to change also all the directories names to libitpp? E.g. >%{_includedir}/libitpp , %{_datadir}/libitpp ? It's not necessary. >2) use libitpp as the name of the package, but leaving the include dir named as >%{_includedir}/itpp Okay so.
(In reply to Antonio Trande from comment #6) > >Do I have to change also all the directories names to libitpp? E.g. >%{_includedir}/libitpp , %{_datadir}/libitpp ? > It's not necessary. > >2) use libitpp as the name of the package, but leaving the include dir named as >%{_includedir}/itpp > Okay so. OK, choice 2, now package name is libitpp. Here new spec and SRPM: Spec URL: https://mdriu.fedorapeople.org/libitpp.spec SRPM URL: https://mdriu.fedorapeople.org/libitpp-4.3.1-1.fc22.src.rpm Successful koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=11175788 I hope you don't mind Antonio, I also sent a mail on the devel list for asking other opinions about most appropriate package name (also for understanding myself which are the naming criteria in cases like this).
Switched back to plain 'itpp', according to discussion on fedora-devel mailing list -> https://lists.fedoraproject.org/pipermail/devel/2015-September/214855.html Here the last version of spec and SRMP. Spec URL: https://mdriu.fedorapeople.org/itpp.spec SRPM URL: https://mdriu.fedorapeople.org/itpp-4.3.1-1.fc22.src.rpm Successful koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=11191565
Two findings not covered by the guidelines: >> Prevent installation of documentation or remove the directory >> automatically created. > # remove htlm doc dir to prevent installation in main packet > rm -rf %{buildroot}%{_docdir}/itpp In the majority of cases, it is more clear and convenient to _move_ such documentation files into $(pwd) and then pass them to a local %doc statement: %install … rm -rf __tmp_doc ; mv %{buildroot}%{_docdir}/itpp $(pwd)/__tmp_doc %files doc … %doc __tmp_doc/* That way you don't risk losing any files installed during make install. And you don't need to clean up the local build dir included via %doc, which may contain files you don't want to be included in the package. > # fix wrong permission for itpp-config > %attr (755,root,root) %{_bindir}/%{name}-config Prefer chmod in %prep or %install as a short-term work-around. And try getting the fix applied upstream. Why not %attr? Well, it's like using a chisel to remove dust. It cannot be denied that %attr works in this case, too, but (755,root,root) is default access permission for all installed executables and directories, and you only want to add +w anyway. Typically one uses %attr for special cases only, such as non-root ownership, setuid/setgid and similar scenarios. And if it were more than one files you needed to fix temporarily, %attr would be overhead and would decrease readability of the spec file.
Thanks Michael for your review, find below the links for the updated spec, SRPM and build. Spec URL: https://mdriu.fedorapeople.org/itpp.spec SRPM URL: https://mdriu.fedorapeople.org/itpp-4.3.1-1.fc22.src.rpm Successful koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=11281128
I performed an unofficial review for my sponsorship process: https://bugzilla.redhat.com/show_bug.cgi?id=1266429
Info for sponsorship process: find below the link to a bug for which I submitted a patch and an updated spec, which have been used by the maintainer for releasing an update. https://bugzilla.redhat.com/show_bug.cgi?id=1268289
Michael: Were you going to complete this review?
I'd like to see this package return to Fedora (it was orphaned back in F15). Unfortunately I cannot sponsor... That said, maybe I can find someone who can sponsor you. I did do a quick automated review and found these issues. Perhaps you could address them? Issues: ======= - All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. Note: These BR are not needed: gcc-c++ See: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 - 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. Note: License file copyright.html is not marked as %license See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text If you can fix these issues (should be a quick fix) I'll try to find someone to sponsor you. Thanks!
> Michael: Were you going to complete this review? No. Comment 9 has only been a drive-by comment.
Hi Eric, and thanks for the help. Concerning your comments: - I think gcc-c++ is actually needed as a BuildRequires, since itpp is a C++ library. Otherwise, how can you build without C++ compiler?! I cannot find the exception you mentioned..can you explain a bit more? - It's true that copyright.html is not marked as %license, but itpp-doc already has its own license file (included as %license COPYING). If I include copyright.html in %license, then this will be moved to a different folder wrt the rest of the html documentation, and this will break all the html links referring to it. Given that itpp-doc already has a license file, do you think this is strictly necessary? Meanwhile, I only updated the srpm to f24 and did a fresh scratch build. Spec URL: https://mdriu.fedorapeople.org/itpp.spec SRPM URL: https://mdriu.fedorapeople.org/itpp-4.3.1-1.fc24.src.rpm Successful koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=15633052
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.
Thanks for the helpful tips. I hope this helps with the math. I've always had trouble with it. At university, I started using a service https://essays.studymoose.com/write-my-paper-for-me to write my papers for students. It helped me get rid of math homework and concentrate on other subjects.