https://bugzilla.redhat.com/show_bug.cgi?id=1110386 --- Comment #4 from František Dvořák <valtri@xxxxxxxxxx> --- (In reply to Richard Shaw from comment #3) > > > Maybe it is not needed to instal it, or alternativelly you can use GPLv2 > > license for the -example subpackage? In eihter way, you can ask upstream > > about licensing: they are intended to use LPGL for codec2 project and maybe > > they would rather relicense the menu.sh file under the same licesne? > > I'll ask but I may just change it. While I am not specifically a programmer, > I am a contributor and have commit access to upstream as I wrote and now > maintain their cmake build system. > OK. Maybe there can be needed the original author to confirm? But it is only a small script anyway contribued to LGPL project... > > > > For example (release field): 1.20140616svn1657 > > The is more or less 0.3 official (as it gets) we don't yet do formal release > archives. The irony of the guidelines is that svn1657 tells you exactly what > svn revision it is, but it's not required, but the date of the checkout is > required. I disagree with the guidelines here but the rules are the rules so > I'll fix it. > OK, thanks. > > > 6) Is the build inside build_linux needed? (I guess you use it because it is > > mentioned in READMEs?) > > Both cmake and I prefer out of source builds. It's in the readme because I > wrote it. :) > OK, I understand. :-) Plus cmake is not able to do distclean, right? > > > 7) It is recommended to track major version of the libraries in %files, like: > > > > %{_libdir}/libcodec2.so.0 > > %{_libdir}/libcodec2.so.0.* > > I can change it if you feel strongly about it but I actually manage the > soversion so I'm not too worried. > OK. You know about it already, it's up to you what to prefer. :-) > > > 8) ChangeLog, NEW, AUTHORS are empty files, they're not needed to install > > I usually include them even if they are empty because they may not always be > empty and who actually checks for that during the update process? > Rpmlint cries loudly about it. But if you have it in other packages too, I'm not for breaking uniformity. > > > 9) README.cmake is only about build instrutions and it is not needed > > I should have caught that since I wrote it :) > :-) > > > 10) codec2-examples should have dependency on "%{name} = > > %{version}-%{release}", not the -devel. Was there any reason for that? > > Maybe I should rename the package to codec2-devel-examples? It's not needed > for the main package at all. > It's not needed IMHO. I think users will understand codec2-examples is not needed for functionality of the codec. It is only the Require, I think there should be "%{name} = %{version}-%{release}" instead of "%{name}-devel = %{version}-%{release}"... > > > Enhancements: > > > > > > 14) Is possible to use something in %check? > > > > There is a testsuite, but if I understand corretly, it is not intended for > > automatic testing. (it is more for codec developers?) It could be commented > > in the .spec file that the testsuite exists, but it can't be used. > > It's not designed to be automated yet. My plan is to add automatic testing > via ctest but the current developer is more interested in codec2-dev than > codec2 so I'm not sure if it will happen anytime soon. > > In fact, I'm moving the binaries to the devel package as they are not > terribly useful except for development (and testing) purposes. > Maybe examples could be better place? codec2-devel subpackage could be for developers using the codec2, or BR for other packages. > > > 15) man-pages: there is recommended (but not required) man-page for each > > binary in /usr/bin > > I would like them to have one as well but I doubt I can get upstream to > write them. > That's not so strong excuse since you're upstream co-maintainer. ;-) But it's OK. :-) > I'll try to get a new SRPM and SPEC posted today if I have time. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review