THIS FILE IS A RUNDOWN OF HOW EACH MANUAL TEST IS ADDRESSED FOR THE EXAMPLE PACKAGE python-sphinxemoji []: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. SHANE: Okay so this one is talking about software licenses. Software is considered a form of intellecutal property in many places, and as such requires licensing in distribution. There are many different software licenses, and not all of them are appropriate for open source software. Since fedora is an open source project, the software we package is required to be licensed with open-source compatible license. In my limited experience, information about the licensing of the software being packaged is recorded in the .spec file mentioned earlier. To manually check the test, find the license information in the spec file on the line starting with "License" and check it against the list of compatible licenses found here: https://fedoraproject.org/wiki/Licensing:Main [ ]: 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. SHANE: Looking at the spec file, we can see that the '%license' macro does not appear whatsoever. The test requires %license if and only if the srpm includes a file containing the license text, so in this case we need to check and make sure that there are no files containing the license text in the srpm. Within the test folder the contents of the srpm can be found in the 'srpm-unpacked' folder. In order to browse the source code files being distributed by the srpm, we need to uncompress the tar file. You can do this by running 'tar -xof [name of tar file]' within srpm-upacked. We then browse the directory resulting from our tar command, and make sure there are no files named 'LICENSE', as this is where the license text would be stored for python packages(and as far as I know, any other package). Since in this case there are no LICENSE files, we can check this one off our list. [ ]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated". 15 files have unknown license. Detailed output of licensecheck in /home/shaneallcroft/software_source/fedora/reviews/2010053-python- sphinxemoji/licensecheck.txt SHANE: Okay so this one requires that we investigate the "actual license." This test is basically a check to make sure the software license type posited by the .spec file is accurate to the reality of the software project being packaged. We can check this information by visiting the web pages directly linked with the project. The spec file gives us the pypi.org link for the project https://pypi.org/pypi/sphinxemoji. Visiting this link we can see that there's not really any licensing information, there is however a link to the project's github that can be found in the sidebar under 'project links'. Going there, we can see that the github lists BSD as the software's license, this is congruous with the spec file, so we can check this off the list. [ ]: Package contains no bundled libraries without FPC exception. SHANE: Package bundling is when a single package contains multiple distinct upstream projects. There are many problems that can arise from package bundling. You can read about them here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries By looking through the srpm unpacked we can see that the contents really only contain the files from the sphinx emoji source code, thus we can check this one off our list too. [ ]: Changelog in prescribed format. SHANE: The changelog should be addressed at the bottom of the spec file. We can see that it is, and that the %autochangelog macro is used that can be read about here(https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping) it's used correctly, everything checks out, we can check this one off our list. [ ]: Sources contain only permissible code or content. SHANE: impermissble content is outlined in https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping by going through the contents of this package, we can see nothing matches fedora's functional definition of impermissible and therefore, the package only contains permissible content. This test gets a pass too. [ ]: Package contains desktop file if it is a GUI application. SHANE: A GUI Application in the context of packaging would mean the software being packaged, when run, creates a window for with which the end user to interact. Reading the documentation (on the github or the README.rst file), we can see that this software is entirely based around text, doesn't include any information or screenshots about a GUI, and so conceivably wouldn't create a GUI of anykind. Thus, we can conclude that this isn't a GUI application. The srpm doesn't contain any .desktop files so this checks out, we can cross this one off too. [ ]: Development files must be in a -devel package SHANE: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages (devel packages can be read about here) This package is a python package. A notable quirk of python packages is that all of them are required by the fedora python packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/) to be -devel packages. This is specified by the line in the spec file "BuildRequires: python3-devel" There are no non python files in this package to worry about whether or not they're addressed correctly, so we can check this off. [ ]: Package uses nothing in %doc for runtime. runtime means https://en.wikipedia.org/wiki/README Looking at the spec file, we can see that the only file referenced by %doc is the README, which is by definition a documentation file that is apart from the source code, so we can check this off. [ ]: Package consistently uses macros (instead of hard-coded directory names). https://stackoverflow.com/questions/1895789/what-does-hard-coded-mean here's an example of a hardcoded directory "/home/shaneallcroft/software_source/fedora/reviews/2010053-python-sphinxemoji" Looking through the software source and spec file, we can see that there's no instance of a hard coded directory, so we can check this one off too. [ ]: Package is named according to the Package Naming Guidelines. SHANE: https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines As a python package, the guidelines require the package name to start with 'python-' looking at the .spec file we can see this is true. Looking through the other guidelines, we can see its true in other areas as well. [ ]: Package does not generate any conflict. SHANE: https://fedoraproject.org/wiki/Packaging:Conflicts conflicts can be read about here^^^^ When two different packages have resources that are named the same, conflicts can arise. 'dnf search python-sphinx' shows us that there are no python-shinxemoji related packages, and that we're in the clear vis a vis naming conflicts [ ]: Package obeys FHS, except libexecdir and /usr/target. SHANE: FHS stands for File System Hierarchy Standard, this can be read about here https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/s1-filesystem-fhs.html [ ]: If the package is a rename of another package, proper Obsoletes and Provides are present. SHANE: to answer this we need to check and make sure this isn't already packed in fedora. To do this, we can run 'dnf search sphinx' and make sure nothing is this emoji support package, reading the output, we can see that indeed this software is assuming proper documentation from other packagers, is not a package already. [ ]: Requires correct, justified where necessary. SHANE: "Requires correct" means that the requirements for the package listed in the spec file are correct, and justified where necessary. [ ]: Spec file is legible and written in American English. SHANE: Prima facie we can see this test is passed. [ ]: Package contains systemd file(s) if in need. SHANE: https://fedoraproject.org/wiki/Packaging:Systemd#Packaging systemd regarding packaging for fedora can be read about here, there's nothing about this package that would require systemd files, and no systemd files are present, so we can cross this off [ ]: Package is not known to require an ExcludeArch tag. SHANE: "ExcludeArch" is used when a package should not be installed on a specific computer architecture (https://en.wikipedia.org/wiki/Computer_architecture) The github documentation/README.mst file mention nothing about exclusivity to a specific architecture, so we can check this off. [ ]: 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. SHANE: By running 'du -h *', we can see that none of the items approach the 1MB mark. Since this check only concerns files larger than, we can check this test off our list. To learn more about the 'du' command, run 'man du' in your terminal [ ]: Package complies to the Packaging Guidelines SHANE: This test is pretty nebulous, the packaging guidelines can be read about here: https://docs.fedoraproject.org/en-US/packaging-guidelines/ This document is really dense, and don't worry at this stage about reading all of it or understanding every bit of minutiae. It's is great if something about a package seems off and/or if you have any questions about the process though. This test is essentially an umbrella to catch any remaining flaws / slights against the packaging guidelines that might remain.