Spec URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa.spec SRPM URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa-2.15.3-1.fc32.src.rpm?raw=true COPR Project: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/ Description: Seven Kingdoms is a real-time strategy (RTS) computer game developed by Trevor Chan of Enlight Software. The game enables players to compete against up to six other kingdoms allowing players to conquer opponents by defeating them in war (with troops or machines), capturing their buildings with spies, or offering opponents money for their kingdom. Seven Kingdoms: Ancient Adversaries is a free patch provided by Interactive Magic and added three new cultures, the Egyptians, the Mughals and the Zulus, and a new war machine, Unicorn. rpmlint: ============= $ rpmlint SPECS/7kaa/7kaa.spec SRPMS/7kaa* RPMS/*/7kaa* 7kaa-data.noarch: W: no-documentation 7kaa-music.noarch: W: no-documentation 7kaa-music.noarch: W: no-manual-page-for-binary 7kaa-data-installer 7kaa-music.noarch: W: dangerous-command-in-%postun rm 7kaa.x86_64: W: no-manual-page-for-binary 7kaa 6 packages and 1 specfiles checked; 0 errors, 5 warnings.
BuildRequires: gcc-c++ BuildRequires: SDL2-devel, SDL2_net-devel BuildRequires: enet-devel BuildRequires: openal-soft-devel, autoconf BuildRequires: gettext-devel BuildRequires: desktop-file-utils BuildRequires: ImageMagick BuildRequires: libcurl-devel BuildRequires: automake It is a matter of taste, but I'd put one dependency per line and sort alphabetically. It's easier to follow and makes diffs smaller in case of dependency changes. %postun music if [ $1 -eq 0 ] ; then ## When Uninstall rm -fr %{prj_music_dir} fi This is unnecessary (and rpmlint warns about it being dangerous). You can get the list of files that autodownloader will download and include it with %ghost marker instead. cd /tmp/%{name}-music tar xjvf /tmp/%{name}-music/%{name}-music.tar.bz2 sudo install -v -m 644 /tmp/%{name}-music/%{name}-music/music/* %{_datadir}/%{name}/music sudo install -v -m 644 /tmp/%{name}-music/%{name}-music/*.txt %{_docdir}/%{name}-music This should use mktemp instead of a hard-coded directory name. Moreover, /tmp is an in-memory file system and may not have enough space. mktemp -p /var/tmp -d looks like a good solution here. Also, you should not assume that sudo will be configured.
Hi! I am in a similar situation as you do... not a developer... yet... and having resurrected (at least for me) 7kaa, about 1 or 2 months ago. I had/have the feeling that you have to come with your own package to request to become a Fedora developer, rathern than unretire... so as to show your skills. So I was/am still searching a project to package... and got entangled with the release of Fedora 32, and trying to catch up with the devel mailing list. I did use other distros info when I made my 7kaa package... in part for the description... that I stole from OpenSuse ... I think. Anyway... I think I will just attach my spec file here... as a point of comparison ... I did not even try to compare with yours yet.
Created attachment 1690304 [details] Paul Dufresne... version 1 (for this bug) of 7kaa.spec
Thank you very much for feedback, both of you. I introduced quite some improvements to the spec file: - Cleaned up the BuildRequired section for the main package - Removed the invalid %postun section - Used wget instead of the autodownloader script + its own external config to allow music downloading post-install - Removed superfluous 7kaa-data package definition - Removed dependency on ImageMagick in favor of the new icon supplied with the sources - Other minor fixes Spec URL: Spec URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa.spec SRPM URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa-2.15.3-2.fc32.src.rpm?raw=true COPR Project: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/ @Paul Per my understanding of the Fedora docs on joining the project, claiming ownership of an orphaned/retired package is also acceptable. If that's not the case, I actually have another gaming project in mind already :).
About downloading the music, see: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_network_access "Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet. Packages must not depend or or use any network resources that they don’t themselves create (i.e., for tests). In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository." So I think you are supposed to add a source line for the music files.
In fact, I believe that by making music a sub-package of your package, you are tainting your package with the license of the music... Which I can read from: https://fedora.pkgs.org/31/fedora-x86_64/7kaa-music-2.14.7-6.fc31.noarch.rpm.html: is "Redistributable, no modification permitted" ... and I don't think you want to add that to your package, because the game would become non-free (not allowing modification to source code). So I think they "must" be separate packages. But... I am just a newbie to packaging and I am frankly unsure of what I am saying.
The license for the music is describe in a file in the zip (or bzip2) archive shown at: https://7kfans.com/?p=96
Created attachment 1691766 [details] License file for the music of 7KAA (apparently original music of the game)
The music license is non-free because it only allows use in conjunction with the game. This is not acceptable for Fedora: https://fedoraproject.org/wiki/Licensing:Main#Content_Licenses It think it may be OK for RPM Fusion though. You wouldn't need the downloader script for a package there either, you could just package the music tarball directly. If such a music package had "Supplements: 7kaa" then users with the additional repo enabled would get the music installed when they installed 7kaa. Another possible approach would be to use autodownloader: https://src.fedoraproject.org/rpms/autodownloader
Thanks for feedback, guys! @Paul Dufresne I think there is a bit of confusion here. The .spec file doesn't violate the policy stated here: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_network_access. The 7kaa-music package merely provides a downloader script to get the music. The .spec file instructs rpm that the music files should be owned by the 7kaa package so that there are no leftovers after package uninstallation. I am always very careful about licensing issues, since they're a big no-go in open-source communities :). I know many game packages use various download script gimmicks, even relying on scriplets which run post-installation (so the licensed content isn't inserted into the source nor binary rpm package itself). @Paul Howarth The autodownloader was used before, but I removed it, since it required an extra .autorc config. I think a regular Bash script using wget is sufficient. However, I think splitting off the music package entirely and moving it to RPM Fusion might be a safer option. Would it be okay to keep the main 7kaa package in the Fedora repositories and move 7kaa-music to RPM Fusion? I would then draft another .spec for a separate music package and submit a new report to RPM Fusion directly.
I think keeping 7kaa in Fedora is fine because the license is OK and I believe the game plays OK without the music. Before committing to this approach though, I would check over at RPM Fusion that they think it's the best approach too. I tried to find an example of something similar but couldn't.
I don't think keeping the music in RPM Fusion is gonna fly, since Fedora's Packaging Guidelines say: >All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies So unless you try doing some shenanigans like keeping Fedora's 7kaa-music at some fake, low NVR, so that the RPM Fusion 7kaa-music is always detected as higher version, and thus preferred by dnf - I don't think it's gonna work. You could maybe patch the program to display some tidbit of info saying "to enable music, download package XXX from RPM Fusion", but that's not the best user experience. If anything, you can always try asking FE-LEGAL for their opinion.
I wasn't suggesting having a dependency on 7kaa-music from the main package, I was suggesting having a reverse dependency from the 7kaa-music package back to the 7kaa package. This is the sort of case that reverse dependencies are designed for. From: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ "Reverse dependencies are mainly designed for 3rd party vendors who can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages." The Fedora package would not include the music at all (and works without it).
@Artur Iwicki Thanks a lot for pointing this out! I read the page on weak dependencies Paul linked, but I somehow missed the subtlety of the section you linked. @Paul Howarth I think Artur is right, actually. "Weak" dependencies are for packages within Fedora's official repositories. What we could leverage in the case of 7kaa would be "hints". "Enhances:" might be acceptable, correct? I wrote to the rpmfusion-developers.org mailing list to ask for opinion, but I noticed that the phrasing in the COPYING file for the 7kaa music is critical here. Since the music files can be used *only* in conjunction with the game, they should theoretically *not* be distributed in a way that would allow their independent use.
So far I haven't received any news from RPMFusion. Meanwhile, I removed the use of licensed music files from the spec file. Latest spec and build logs are available here: Spec URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa.spec CORP builds: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/build/1475177/ Is there anything I should still change?
- Use install -p to keep timestamps - Use a better name for your archive: https://github.com/the3dfxdude/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz - There is some BSD code: BSD 3-clause "New" or "Revised" License --------------------------------------- 7kaa-2.15.3/include/misc_uuid.h 7kaa-2.15.3/src/misc_uuid.cpp Add it to the license field and add a comment explaining the licenses breakdown: # Main program: GPLv2+ # misc_uuid: BSD License: GPLv2+ and BSD - Own this dir by removing the glob: %{_datadir}/%{name}/ - Split the data into a noarch data subpackage that you Requires from the main package: [!]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 105809920 bytes in /usr/share 7kaa-2.15.3-5.fc33.x86_64.rpm:105809920 See: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines Requires: %{name}-data = %{version}-%{release} Requires: hicolor-icon-theme […] %package data BuildArch: noarch Summary: In-Game data Seven Kingdoms: Ancient Adversaries Requires: %{name} = %{version}-%{release} Requires: hicolor-icon-theme %description data In-Game data Seven Kingdoms: Ancient Adversaries. […] %files data %{_datadir}/%{name} Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package does not use a name that already exists. Note: A package with this name already exists. Please check https://src.fedoraproject.org/rpms/7kaa See: https://docs.fedoraproject.org/en-US/packaging- guidelines/Naming/#_conflicting_package_names ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [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. [!]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "GNU Lesser General Public License", "Unknown or generated", "GPL (v2 or later)", "GNU Lesser General Public License (v2.1 or later)", "BSD 3-clause "New" or "Revised" License", "FSF All Permissive License". 733 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/7kaa/review-7kaa/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/7kaa [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 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 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 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. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: 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]: 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: [!]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 105809920 bytes in /usr/share 7kaa-2.15.3-5.fc33.x86_64.rpm:105809920 See: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines [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]: Package should not use obsolete m4 macros [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: 7kaa-2.15.3-5.fc33.x86_64.rpm 7kaa-debuginfo-2.15.3-5.fc33.x86_64.rpm 7kaa-debugsource-2.15.3-5.fc33.x86_64.rpm 7kaa-2.15.3-5.fc33.src.rpm 7kaa.x86_64: W: no-manual-page-for-binary 7kaa 4 packages and 0 specfiles checked; 0 errors, 1 warnings.
Super big thanks for such a thorough review :) (In reply to Robert-André Mauchin 🐧 from comment #16) > - Use install -p to keep timestamps Done > - Use a better name for your archive: > > https://github.com/the3dfxdude/%{name}/archive/v%{version}/%{name}- > %{version}.tar.gz Done. > > - There is some BSD code: > > BSD 3-clause "New" or "Revised" License > --------------------------------------- > 7kaa-2.15.3/include/misc_uuid.h > 7kaa-2.15.3/src/misc_uuid.cpp > > Add it to the license field and add a comment explaining the licenses > breakdown: > > # Main program: GPLv2+ > # misc_uuid: BSD > License: GPLv2+ and BSD Done. I also re-ran licensecheck on the entire sources, since a new version came out this weekend. There are some mentions of FSF All Permissive License for m4 files. Should that also be included? > > - Own this dir by removing the glob: > > %{_datadir}/%{name}/ I always mess this up. Done. > - Split the data into a noarch data subpackage that you Requires from the > main package: > > [!]: Large data in /usr/share should live in a noarch subpackage if package > is arched. > Note: Arch-ed rpms have a total of 105809920 bytes in /usr/share > 7kaa-2.15.3-5.fc33.x86_64.rpm:105809920 > See: > > https://fedoraproject.org/wiki/Packaging: > ReviewGuidelines#Package_Review_Guidelines > (...) This is totally my fault. The original package would split out music and data files. No idea why I merged the data package back into the main package. Fixed. > Issues: > ======= > - Package does not use a name that already exists. > Note: A package with this name already exists. Please check > https://src.fedoraproject.org/rpms/7kaa > See: https://docs.fedoraproject.org/en-US/packaging- > guidelines/Naming/#_conflicting_package_names Makes sense, since the package was orphaned :). SPEC URL: https://raw.githubusercontent.com/AndyMender/7kaa-rpm/f32/7kaa.spec SRPM URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa-2.15.4-1.fc32.src.rpm?raw=true COPR build: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/build/1518257/
> Done. I also re-ran licensecheck on the entire sources, since a new version came out this weekend. There are some mentions of FSF All Permissive License for m4 files. Should that also be included? If it's not in the resulting binary, it doesn't matter. M4 files are just artifacts for building, they don't matter. Package approved. You still need to find a sponsor: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
Sponsored!
FEDORA-2020-cd5132634d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cd5132634d
FEDORA-2020-cd5132634d has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-cd5132634d \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cd5132634d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-703852634d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-703852634d
FEDORA-2020-703852634d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-703852634d \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-703852634d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-cd5132634d has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-2a1d5acd00 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2a1d5acd00
FEDORA-2020-703852634d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-2a1d5acd00 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2a1d5acd00` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2a1d5acd00 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-8799364879 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8799364879
FEDORA-2020-8799364879 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8799364879` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8799364879 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-2a1d5acd00 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-8799364879 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-8a63eb6948 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a63eb6948
FEDORA-2020-021483c324 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-021483c324
FEDORA-2020-ba4ff0908c has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ba4ff0908c
FEDORA-2020-8a63eb6948 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8a63eb6948` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a63eb6948 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-021483c324 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-021483c324` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-021483c324 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-ba4ff0908c has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ba4ff0908c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ba4ff0908c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Can you please stop adding this bug to your updates in bodhi? It should remain closed as the review is done.
Apologies, will do!
FEDORA-2020-021483c324 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-8a63eb6948 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-ba4ff0908c has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.