Spec URL: https://jskarvad.fedorapeople.org/rtlsdr-scanner/rtlsdr-scanner.spec SRPM URL: https://jskarvad.fedorapeople.org/rtlsdr-scanner/rtlsdr-scanner-1.0.22298.18049-1.fc23.src.rpm Description: Frequency scanning GUI for RTL2832 based DVB-T dongles. In other words a cheap, simple Spectrum Analyser. Fedora Account System Username: jskarvad
- Please, leave a comment about the patch- - Create an appdata file. - Installation instruction says: >Newer kernels have a DVB driver included which won't work with the RTLSDR driver Kernel module 'dvb_usb_rtl28xxu' has to be balcklisted, and this software needs rtl-sdr to work. 'rtl-sdr' is required. Right ?
(In reply to Antonio Trande from comment #1) Thanks for taking the review. > - Please, leave a comment about the patch- This is fedora distro specific patch updating paths and modularizing the package (because AFAIK the package cannot be installed into fedora non-modularized). I thought that the -fedora suffix is enough, but no problem, I added short description. I am also planning to generalize it and propose upstream. > > - Create an appdata file. Sorry, what do you mean? > > - Installation instruction says: > > >Newer kernels have a DVB driver included which won't work with the RTLSDR driver > > Kernel module 'dvb_usb_rtl28xxu' has to be balcklisted, and this software > needs rtl-sdr to work. 'rtl-sdr' is required. Right ? This is frontend to rtl-sdr which IIRC should handle the kernel DVB-T driver conflict for some time. It should unbind the driver and rebind later. So I think the blacklist instructions are obsoleted (but you can still do it). Regarding rtl-sdr requirement, the package requires python2-pyrtlsdr, which is python binding to rtl-sdr and it requires rtl-sdr, so the deps should be OK. But maybe there are some missing deps, I havent tested the package in chroot (to bo honest I haven't tested the functionality yet, because I don't have here the required HW, I will test the functionality later today). Due to the minor change I updated the package silently without release bump, sorry about it :)
(In reply to Jaroslav Škarvada from comment #2) > (In reply to Antonio Trande from comment #1) > Thanks for taking the review. > > > > > - Create an appdata file. > Sorry, what do you mean? > > > http://fedoraproject.org/wiki/Packaging:Guidelines#AppData_files
(In reply to Antonio Trande from comment #3) > (In reply to Jaroslav Škarvada from comment #2) > > (In reply to Antonio Trande from comment #1) > > Thanks for taking the review. > > > > > > > > - Create an appdata file. > > Sorry, what do you mean? > > > > > > > http://fedoraproject.org/wiki/Packaging:Guidelines#AppData_files Sorry, I have never heard about it, upstream provides none, and it's SHOULD for fedora, so it's not blocker.
(In reply to Jaroslav Škarvada from comment #4) > (In reply to Antonio Trande from comment #3) > > (In reply to Jaroslav Škarvada from comment #2) > > > (In reply to Antonio Trande from comment #1) > > > Thanks for taking the review. > > > > > > > > > > > - Create an appdata file. > > > Sorry, what do you mean? > > > > > > > > > > > http://fedoraproject.org/wiki/Packaging:Guidelines#AppData_files > > Sorry, I have never heard about it, upstream provides none, and it's SHOULD > for fedora, so it's not blocker. Yes, it's for Fedora; it is a modest work but useful.
(In reply to Antonio Trande from comment #5) > (In reply to Jaroslav Škarvada from comment #4) > > (In reply to Antonio Trande from comment #3) > > > (In reply to Jaroslav Škarvada from comment #2) > > > > (In reply to Antonio Trande from comment #1) > > > > Thanks for taking the review. > > > > > > > > > > > > > > - Create an appdata file. > > > > Sorry, what do you mean? > > > > > > > > > > > > > > > http://fedoraproject.org/wiki/Packaging:Guidelines#AppData_files > > > > Sorry, I have never heard about it, upstream provides none, and it's SHOULD > > for fedora, so it's not blocker. > > Yes, it's for Fedora; it is a modest work but useful. Nothing against, I was just lazy/busy :) Maybe I will try to create something.
I forwarded the patch (including description of ideas behind) and desktop file to the upstream.
(In reply to Jaroslav Škarvada from comment #6) > (In reply to Antonio Trande from comment #5) > > (In reply to Jaroslav Škarvada from comment #4) > > > (In reply to Antonio Trande from comment #3) > > > > (In reply to Jaroslav Škarvada from comment #2) > > > > > (In reply to Antonio Trande from comment #1) > > > > > Thanks for taking the review. > > > > > > > > > > > > > > > > > - Create an appdata file. > > > > > Sorry, what do you mean? > > > > > > > > > > > > > > > > > > > http://fedoraproject.org/wiki/Packaging:Guidelines#AppData_files > > > > > > Sorry, I have never heard about it, upstream provides none, and it's SHOULD > > > for fedora, so it's not blocker. > > > > Yes, it's for Fedora; it is a modest work but useful. > > Nothing against, I was just lazy/busy :) Maybe I will try to create > something. Sorry, I am unable to provide it because: - the appdata contains update contact. I am not upstream and I don't want to be the update contact. - I can't host the screenshots and I think it should be hosted upstream So I think the request should be forwarded upstream. According to the packaging guidelines it's not blocker for the review.
(In reply to Jaroslav Škarvada from comment #8) > > > > > > Yes, it's for Fedora; it is a modest work but useful. > > > > Nothing against, I was just lazy/busy :) Maybe I will try to create > > something. > > Sorry, I am unable to provide it because: > - the appdata contains update contact. I am not upstream and I don't want to > be the update contact. Your are not upstream, you are responsible of the package and so of the appdata file on Fedora. > - I can't host the screenshots and I think it should be hosted upstream Your space on fedorapeople.org ? > > According to the packaging guidelines it's not blocker for the review. If you really don't want, okay.
(In reply to Antonio Trande from comment #9) > (In reply to Jaroslav Škarvada from comment #8) > > > > > > > > Yes, it's for Fedora; it is a modest work but useful. > > > > > > Nothing against, I was just lazy/busy :) Maybe I will try to create > > > something. > > > > Sorry, I am unable to provide it because: > > - the appdata contains update contact. I am not upstream and I don't want to > > be the update contact. > > Your are not upstream, you are responsible of the package and so of the > appdata file on Fedora. > Regarding appdata I am afraid it's not written anywhere. Please see the upstream specification: https://people.freedesktop.org/~hughsient/appdata/ i.e.: > ...we have defined a new data file, which the upstream project can optionally translate using the same technique as GSetting schemas or Desktop files. So this should be addressed upstream the same way as .desktop files are. And upstream knows the best how to create cool screenshots of their project. > > - I can't host the screenshots and I think it should be hosted upstream > > Your space on fedorapeople.org ? > Well, this is really strange idea. In case it should be managed by package maintainers there should be some official infrastructure for it in Fedora.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ==== Issues ===== - hicolor-icon-theme as Requires package is missing - -doc sub-package does not provide an own license file ===== MUST items ===== 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: "GPL", "Unknown or generated". 4 files have unknown license. Detailed output of licensecheck in /home/sagitter/1356048-rtlsdr- scanner/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [!]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/share/icons/hicolor/256x256/apps(hicolor-icon-theme, fedora- logos), /usr/share/icons/hicolor/256x256(hicolor-icon-theme, fedora- logos), /usr/share/icons/hicolor(hicolor-icon-theme, fedora-logos) [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 [-]: Package uses nothing in %doc for runtime. [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. [!]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: gtk-update-icon-cache is invoked in %postun and %posttrans if package contains icons. Note: icons in rtlsdr-scanner [x]: Package is not known to require an ExcludeArch tag. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 10240 bytes in 1 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 must own all directories that it creates. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [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 Python: [x]: Python eggs must not download any dependencies during the build process. [x]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Binary eggs must be removed in %prep ===== 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). [-]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in rtlsdr- scanner-doc [ ]: 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]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: rtlsdr-scanner-1.0.22298.18049-1.fc25.noarch.rpm rtlsdr-scanner-doc-1.0.22298.18049-1.fc25.noarch.rpm rtlsdr-scanner-1.0.22298.18049-1.fc25.src.rpm rtlsdr-scanner.noarch: W: no-manual-page-for-binary rtlsdr_scan 3 packages and 0 specfiles checked; 0 errors, 1 warnings. Rpmlint (installed packages) ---------------------------- rtlsdr-scanner.noarch: W: no-manual-page-for-binary rtlsdr_scan 2 packages and 0 specfiles checked; 0 errors, 1 warnings. Requires -------- rtlsdr-scanner (rpmlib, GLIBC filtered): /bin/sh /usr/bin/python2 numpy pyserial python(abi) python-pillow python2-matplotlib python2-matplotlib-wx python2-pyrtlsdr wxPython rtlsdr-scanner-doc (rpmlib, GLIBC filtered): rtlsdr-scanner Provides -------- rtlsdr-scanner: application() application(rtlsdr-scanner.desktop) rtlsdr-scanner rtlsdr-scanner-doc: rtlsdr-scanner-doc Source checksums ---------------- https://github.com/EarToEarOak/RTLSDR-Scanner/archive/v1.0.22298.18049.tar.gz#/RTLSDR-Scanner-1.0.22298.18049.tar.gz : CHECKSUM(SHA256) this package : 8e6eeb4e9337b54871390282e291fc78cebbdce902ee757e3e9a75ddf9e957b3 CHECKSUM(SHA256) upstream package : 8e6eeb4e9337b54871390282e291fc78cebbdce902ee757e3e9a75ddf9e957b3 Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02 Command line :/usr/bin/fedora-review -m fedora-rawhide-i386 -b 1356048 Buildroot used: fedora-rawhide-i386 Active plugins: Python, Generic, Shell-api Disabled plugins: Java, C/C++, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
(In reply to Antonio Trande from comment #11) Thanks for the review. > - hicolor-icon-theme as Requires package is missing > Also it was wrongly packaged to own directories it shouldn't own, fixed. > - -doc sub-package does not provide an own license file Why it should provide its own license file? The docs are licensing under the same license as the main package and it's dependent on the main package, from the doc: > Both this document and the RLTSDR Scanner is licensed under the GNU General > Public License version 3 (http://www.gnu.org/licenses/gpl.html). According to [1]: > If a subpackage is dependent (either implicitly or explicitly) upon a base > package (where a base package is defined as a resulting binary package from the > same source RPM which contains the appropriate license texts as %license), > it is not necessary for that subpackage to also include those license > texts as %license. Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ as stated on the different place of the sources. I took the documentation as more authoritative source and fixed the resulting license to be GPLv3, but I will query upstream about their intention. [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_Licensing
Spec URL: https://jskarvad.fedorapeople.org/rtlsdr-scanner/rtlsdr-scanner.spec SRPM URL: https://jskarvad.fedorapeople.org/rtlsdr-scanner/rtlsdr-scanner-1.0.22298.18049-2.fc23.src.rpm
Opened upstream ticket regarding the resulting license: https://github.com/EarToEarOak/RTLSDR-Scanner/issues/26
(In reply to Jaroslav Škarvada from comment #12) > (In reply to Antonio Trande from comment #11) > > Why it should provide its own license file? The docs are licensing under the > same license as the main package and it's dependent on the main package, > from the doc: > > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > Public License version 3 (http://www.gnu.org/licenses/gpl.html). > > According to [1]: > > If a subpackage is dependent (either implicitly or explicitly) upon a base > > package (where a base package is defined as a resulting binary package from the > > same source RPM which contains the appropriate license texts as %license), > > it is not necessary for that subpackage to also include those license > > texts as %license. Ah sorry, I didn't seen the dependency. But does it really need main package? > > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > as stated on the different place of the sources. I took the documentation as > more authoritative source and fixed the resulting license to be GPLv3, but I > will query upstream about their intention. > > [1] > https://fedoraproject.org/wiki/Packaging: > LicensingGuidelines#Subpackage_Licensing They should not be dependent among them and should have different License tags in any case. - Does not work for me: $ rtlsdr_scan Import error: No module named rtlsdrtcp Error importing libraries Press [Return] to exit
(In reply to Antonio Trande from comment #15) > (In reply to Jaroslav Škarvada from comment #12) > > (In reply to Antonio Trande from comment #11) > > > > Why it should provide its own license file? The docs are licensing under the > > same license as the main package and it's dependent on the main package, > > from the doc: > > > > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > > Public License version 3 (http://www.gnu.org/licenses/gpl.html). > > > > According to [1]: > > > If a subpackage is dependent (either implicitly or explicitly) upon a base > > > package (where a base package is defined as a resulting binary package from the > > > same source RPM which contains the appropriate license texts as %license), > > > it is not necessary for that subpackage to also include those license > > > texts as %license. > > Ah sorry, I didn't seen the dependency. But does it really need main package? > %package doc Summary: Documentation files for rtlsdr-scanner Requires: %{name} = %{version}-%{release} BuildArch: noarch Requires is the explicit dependency, i.e. you cannot install the doc subpackage without the main package. > > > > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > > as stated on the different place of the sources. I took the documentation as > > more authoritative source and fixed the resulting license to be GPLv3, but I > > will query upstream about their intention. > > > > [1] > > https://fedoraproject.org/wiki/Packaging: > > LicensingGuidelines#Subpackage_Licensing > > They should not be dependent among them and should have different License > tags in any case. > What? There is clearly written that both are licensed under one (i.e. the same) license. The question is whether it is GPLv3 or GPLv3+, I bet it's only typo (or copy and paste error ) or upstream just didn't think about the nuance of v3 vs v3+. From the data available you *cannot* deduce that the doc is licensed under GPLv3 and the code under GPLv3+. > - Does not work for me: > > $ rtlsdr_scan > Import error: No module named rtlsdrtcp > > Error importing libraries > Press [Return] to exit You need python2-pyrtlsdr package from testing, namely: python-pyrtlsdr-0.2.2-6.fc25
(In reply to Jaroslav Škarvada from comment #16) > (In reply to Antonio Trande from comment #15) > > (In reply to Jaroslav Škarvada from comment #12) > > > (In reply to Antonio Trande from comment #11) > > > > > > Why it should provide its own license file? The docs are licensing under the > > > same license as the main package and it's dependent on the main package, > > > from the doc: > > > > > > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > > > Public License version 3 (http://www.gnu.org/licenses/gpl.html). > > > > > > According to [1]: > > > > If a subpackage is dependent (either implicitly or explicitly) upon a base > > > > package (where a base package is defined as a resulting binary package from the > > > > same source RPM which contains the appropriate license texts as %license), > > > > it is not necessary for that subpackage to also include those license > > > > texts as %license. > > > > Ah sorry, I didn't seen the dependency. But does it really need main package? > > > > %package doc > Summary: Documentation files for rtlsdr-scanner > Requires: %{name} = %{version}-%{release} > BuildArch: noarch > > Requires is the explicit dependency, i.e. you cannot install the doc > subpackage without the main package. Yes, I understand but why? :) > > > > > > > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > > > as stated on the different place of the sources. I took the documentation as > > > more authoritative source and fixed the resulting license to be GPLv3, but I > > > will query upstream about their intention. > > > > > > [1] > > > https://fedoraproject.org/wiki/Packaging: > > > LicensingGuidelines#Subpackage_Licensing > > > > They should not be dependent among them and should have different License > > tags in any case. > > > What? There is clearly written that both are licensed under one (i.e. the > same) license. The question is whether it is GPLv3 or GPLv3+, I bet it's > only typo (or copy and paste error ) or upstream just didn't think about the > nuance of v3 vs v3+. From the data available you *cannot* deduce that the > doc is licensed under GPLv3 and the code under GPLv3+. In fact, from PDF file: License Both this document and the RLTSDR Scanner is licensed under the GNU General Public License version 3 But readme.rd disagrees. > > > - Does not work for me: > > > > $ rtlsdr_scan > > Import error: No module named rtlsdrtcp > > > > Error importing libraries > > Press [Return] to exit > > You need python2-pyrtlsdr package from testing, namely: > python-pyrtlsdr-0.2.2-6.fc25 Okay.
(In reply to Antonio Trande from comment #17) > (In reply to Jaroslav Škarvada from comment #16) > > (In reply to Antonio Trande from comment #15) > > > (In reply to Jaroslav Škarvada from comment #12) > > > > (In reply to Antonio Trande from comment #11) > > > > > > > > Why it should provide its own license file? The docs are licensing under the > > > > same license as the main package and it's dependent on the main package, > > > > from the doc: > > > > > > > > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > > > > Public License version 3 (http://www.gnu.org/licenses/gpl.html). > > > > > > > > According to [1]: > > > > > If a subpackage is dependent (either implicitly or explicitly) upon a base > > > > > package (where a base package is defined as a resulting binary package from the > > > > > same source RPM which contains the appropriate license texts as %license), > > > > > it is not necessary for that subpackage to also include those license > > > > > texts as %license. > > > > > > Ah sorry, I didn't seen the dependency. But does it really need main package? > > > > > > > %package doc > > Summary: Documentation files for rtlsdr-scanner > > Requires: %{name} = %{version}-%{release} > > BuildArch: noarch > > > > Requires is the explicit dependency, i.e. you cannot install the doc > > subpackage without the main package. > > Yes, I understand but why? :) Sorry, are you joking or what? > > > > > > > > > > > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > > > > as stated on the different place of the sources. I took the documentation as > > > > more authoritative source and fixed the resulting license to be GPLv3, but I > > > > will query upstream about their intention. > > > > > > > > [1] > > > > https://fedoraproject.org/wiki/Packaging: > > > > LicensingGuidelines#Subpackage_Licensing > > > > > > They should not be dependent among them and should have different License > > > tags in any case. > > > > > What? There is clearly written that both are licensed under one (i.e. the > > same) license. The question is whether it is GPLv3 or GPLv3+, I bet it's > > only typo (or copy and paste error ) or upstream just didn't think about the > > nuance of v3 vs v3+. From the data available you *cannot* deduce that the > > doc is licensed under GPLv3 and the code under GPLv3+. > > In fact, from PDF file: > > License > Both this document and the RLTSDR Scanner is licensed under the GNU General > Public License > version 3 > > But readme.rd disagrees. > How is this different from what I wrote earlier?
(In reply to Jaroslav Škarvada from comment #18) > (In reply to Antonio Trande from comment #17) > > (In reply to Jaroslav Škarvada from comment #16) > > > (In reply to Antonio Trande from comment #15) > > > > (In reply to Jaroslav Škarvada from comment #12) > > > > > (In reply to Antonio Trande from comment #11) > > > > > > > > > > Why it should provide its own license file? The docs are licensing under the > > > > > same license as the main package and it's dependent on the main package, > > > > > from the doc: > > > > > > > > > > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > > > > > Public License version 3 (http://www.gnu.org/licenses/gpl.html). > > > > > > > > > > According to [1]: > > > > > > If a subpackage is dependent (either implicitly or explicitly) upon a base > > > > > > package (where a base package is defined as a resulting binary package from the > > > > > > same source RPM which contains the appropriate license texts as %license), > > > > > > it is not necessary for that subpackage to also include those license > > > > > > texts as %license. > > > > > > > > Ah sorry, I didn't seen the dependency. But does it really need main package? > > > > > > > > > > %package doc > > > Summary: Documentation files for rtlsdr-scanner > > > Requires: %{name} = %{version}-%{release} > > > BuildArch: noarch > > > > > > Requires is the explicit dependency, i.e. you cannot install the doc > > > subpackage without the main package. > > > > Yes, I understand but why? :) > > Sorry, are you joking or what? -doc sub-package provides a PDF file only, it does not need base package. Just for example: 'gle-doc' (that contains PDFs and license) does not depend by 'gle' $ repoquery -l gle-doc /usr/share/doc/gle-doc /usr/share/doc/gle-doc/GLEusersguide.pdf /usr/share/doc/gle-doc/gle-manual.pdf /usr/share/licenses/gle-doc /usr/share/licenses/gle-doc/LICENSE.txt $ repoquery --requires gle-doc #No output > > > > > > > > > > > > > > > > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > > > > > as stated on the different place of the sources. I took the documentation as > > > > > more authoritative source and fixed the resulting license to be GPLv3, but I > > > > > will query upstream about their intention. > > > > > > > > > > [1] > > > > > https://fedoraproject.org/wiki/Packaging: > > > > > LicensingGuidelines#Subpackage_Licensing > > > > > > > > They should not be dependent among them and should have different License > > > > tags in any case. > > > > > > > What? There is clearly written that both are licensed under one (i.e. the > > > same) license. The question is whether it is GPLv3 or GPLv3+, I bet it's > > > only typo (or copy and paste error ) or upstream just didn't think about the > > > nuance of v3 vs v3+. From the data available you *cannot* deduce that the > > > doc is licensed under GPLv3 and the code under GPLv3+. > > > > In fact, from PDF file: > > > > License > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > Public License > > version 3 > > > > But readme.rd disagrees. > > > How is this different from what I wrote earlier? Jaroslav, we agree about this point; I had not read well the PDF file. No problem.
(In reply to Antonio Trande from comment #19) > (In reply to Jaroslav Škarvada from comment #18) > > (In reply to Antonio Trande from comment #17) > > > (In reply to Jaroslav Škarvada from comment #16) > > > > (In reply to Antonio Trande from comment #15) > > > > > (In reply to Jaroslav Škarvada from comment #12) > > > > > > (In reply to Antonio Trande from comment #11) > > > > > > > > > > > > Why it should provide its own license file? The docs are licensing under the > > > > > > same license as the main package and it's dependent on the main package, > > > > > > from the doc: > > > > > > > > > > > > > Both this document and the RLTSDR Scanner is licensed under the GNU General > > > > > > > Public License version 3 (http://www.gnu.org/licenses/gpl.html). > > > > > > > > > > > > According to [1]: > > > > > > > If a subpackage is dependent (either implicitly or explicitly) upon a base > > > > > > > package (where a base package is defined as a resulting binary package from the > > > > > > > same source RPM which contains the appropriate license texts as %license), > > > > > > > it is not necessary for that subpackage to also include those license > > > > > > > texts as %license. > > > > > > > > > > Ah sorry, I didn't seen the dependency. But does it really need main package? > > > > > > > > > > > > > %package doc > > > > Summary: Documentation files for rtlsdr-scanner > > > > Requires: %{name} = %{version}-%{release} > > > > BuildArch: noarch > > > > > > > > Requires is the explicit dependency, i.e. you cannot install the doc > > > > subpackage without the main package. > > > > > > Yes, I understand but why? :) > > > > Sorry, are you joking or what? > > -doc sub-package provides a PDF file only, it does not need base package. > > Just for example: > > 'gle-doc' (that contains PDFs and license) does not depend by 'gle' > > $ repoquery -l gle-doc > /usr/share/doc/gle-doc > /usr/share/doc/gle-doc/GLEusersguide.pdf > /usr/share/doc/gle-doc/gle-manual.pdf > /usr/share/licenses/gle-doc > /usr/share/licenses/gle-doc/LICENSE.txt > > $ repoquery --requires gle-doc > #No output Well, sorry I cannot imagine situation when you would need doc sub package and not the main package, according to the Fedora Packaging Guidelines [1]: > Subpackages are often extensions for their base package and in that > case they should require their base package. It's talking about extension of the package, not extension of the functionality, so the documentation counts. And from the Package Review Guidelines [2]: > SHOULD: Usually, subpackages other than devel should require the base package > using a fully versioned dependency I would recommend you reading the guidelines. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package [2] https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
Is there still any blocker?
(In reply to Jaroslav Škarvada from comment #12) > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > as stated on the different place of the sources. I took the documentation as > more authoritative source and fixed the resulting license to be GPLv3, but I > will query upstream about their intention. > > [1] > https://fedoraproject.org/wiki/Packaging: > LicensingGuidelines#Subpackage_Licensing I guessed it right, according to upstream it's GPLv3 and it's already fixed upstream.
(In reply to Jaroslav Škarvada from comment #22) > (In reply to Jaroslav Škarvada from comment #12) > > Well, I have now a dilemma, whether the resulting license is GPLv3 or GPLv3+ > > as stated on the different place of the sources. I took the documentation as > > more authoritative source and fixed the resulting license to be GPLv3, but I > > will query upstream about their intention. > > > > [1] > > https://fedoraproject.org/wiki/Packaging: > > LicensingGuidelines#Subpackage_Licensing > > I guessed it right, according to upstream it's GPLv3 and it's already fixed > upstream. https://github.com/EarToEarOak/RTLSDR-Scanner/issues/26
(In reply to Jaroslav Škarvada from comment #20) > > > > > > > > > > > > > > > > %package doc > > > > > Summary: Documentation files for rtlsdr-scanner > > > > > Requires: %{name} = %{version}-%{release} > > > > > BuildArch: noarch > > > > > > > > > > Requires is the explicit dependency, i.e. you cannot install the doc > > > > > subpackage without the main package. > > > > > > > > Yes, I understand but why? :) > > > > > > Sorry, are you joking or what? > > > > -doc sub-package provides a PDF file only, it does not need base package. > > > > Just for example: > > > > 'gle-doc' (that contains PDFs and license) does not depend by 'gle' > > > > $ repoquery -l gle-doc > > /usr/share/doc/gle-doc > > /usr/share/doc/gle-doc/GLEusersguide.pdf > > /usr/share/doc/gle-doc/gle-manual.pdf > > /usr/share/licenses/gle-doc > > /usr/share/licenses/gle-doc/LICENSE.txt > > > > $ repoquery --requires gle-doc > > #No output > > Well, sorry I cannot imagine situation when you would need doc sub package > and not the main package, according to the Fedora Packaging Guidelines [1]: > > > Subpackages are often extensions for their base package and in that > > case they should require their base package. > > It's talking about extension of the package, not extension of the > functionality, so the documentation counts. You are interpreting guidelines in your favor. A generic "extension" like you think should be true in both directions (doc is an extension of base package and viceversa). Instead, an user could want install documentation without install software; if your interpretation was true, wouldn't be useful make a -doc sub-package. > > And from the Package Review Guidelines [2]: > > > SHOULD: Usually, subpackages other than devel should require the base package > > using a fully versioned dependency This example is inappropriate. > > I would recommend you reading the guidelines. > > [1] > https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package > [2] https://fedoraproject.org/wiki/Packaging:ReviewGuidelines Thank you for this tip. However, this is not a great problem. Package approved.
(In reply to Antonio Trande from comment #24) > (In reply to Jaroslav Škarvada from comment #20) > > > > > > > > > > > > > > > > > > > %package doc > > > > > > Summary: Documentation files for rtlsdr-scanner > > > > > > Requires: %{name} = %{version}-%{release} > > > > > > BuildArch: noarch > > > > > > > > > > > > Requires is the explicit dependency, i.e. you cannot install the doc > > > > > > subpackage without the main package. > > > > > > > > > > Yes, I understand but why? :) > > > > > > > > Sorry, are you joking or what? > > > > > > -doc sub-package provides a PDF file only, it does not need base package. > > > > > > Just for example: > > > > > > 'gle-doc' (that contains PDFs and license) does not depend by 'gle' > > > > > > $ repoquery -l gle-doc > > > /usr/share/doc/gle-doc > > > /usr/share/doc/gle-doc/GLEusersguide.pdf > > > /usr/share/doc/gle-doc/gle-manual.pdf > > > /usr/share/licenses/gle-doc > > > /usr/share/licenses/gle-doc/LICENSE.txt > > > > > > $ repoquery --requires gle-doc > > > #No output > > > > Well, sorry I cannot imagine situation when you would need doc sub package > > and not the main package, according to the Fedora Packaging Guidelines [1]: > > > > > Subpackages are often extensions for their base package and in that > > > case they should require their base package. > > > > It's talking about extension of the package, not extension of the > > functionality, so the documentation counts. > > You are interpreting guidelines in your favor. A generic "extension" like > you think should be true in both directions (doc is an extension of base > package and viceversa). > Instead, an user could want install documentation without install software; > if your interpretation was true, wouldn't be useful make a -doc sub-package. > Sorry I can't imagine why anybody would need to install documentation without the base package. The reason why doc sub packages exists is to support users who don't need the documentation to save some bits. I.e. it's clearly written in the guides, that you need to split the package to -doc if the documentation is too big. > > > > And from the Package Review Guidelines [2]: > > > > > SHOULD: Usually, subpackages other than devel should require the base package > > > using a fully versioned dependency > > This example is inappropriate. > How it is inappropriate? It's *clearly* written there. If you have some problem with it, open ticket against FPC. > > > > I would recommend you reading the guidelines. > > > > [1] > > https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package > > [2] https://fedoraproject.org/wiki/Packaging:ReviewGuidelines > > Thank you for this tip. > > However, this is not a great problem. > Package approved. Thanks.
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/rtlsdr-scanner
rtlsdr-scanner-1.0.22298.18049-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3b377966e7
rtlsdr-scanner-1.0.22298.18049-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dfdda0cb3
rtlsdr-scanner-1.0.22298.18049-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3dfdda0cb3
rtlsdr-scanner-1.0.22298.18049-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3b377966e7
rtlsdr-scanner-1.0.22298.18049-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
rtlsdr-scanner-1.0.22298.18049-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.