Spec URL: https://gitlab.com/musicinmybrain/abseil-py-rpm/-/raw/f7a4a20aa1bf6d569ff57acfec7168d8fc64cddb/python-absl-py.spec SRPM URL: https://kojipkgs.fedoraproject.org//work/tasks/5820/56285820/python-absl-py-0.11.0-1.fc34.src.rpm Description: This repository is a collection of Python library code for building Python applications. The code is collected from Google’s own Python code base, and has been extensively tested and used in production. Features: • Simple application startup • Distributed commandline flags system • Custom logging module with additional features • Testing utilities Fedora Account System Username: music Koji builds: F34: https://koji.fedoraproject.org/koji/taskinfo?taskID=56285814 F33: https://koji.fedoraproject.org/koji/taskinfo?taskID=56285934 F32: https://koji.fedoraproject.org/koji/taskinfo?taskID=56286025 EPEL8: https://koji.fedoraproject.org/koji/taskinfo?taskID=56286240 EPEL7: https://koji.fedoraproject.org/koji/taskinfo?taskID=56286391 I want this package as a dependency for gftools (Google Fonts Tools). Here are some other projects that use it: https://www.wheelodex.org/projects/absl-py/rdepends/
I don't have much experience with packaging for EPEL so please excuse some of my questions :). > URL: https://github.com/abseil/%{reponame}/ > Source0: https://github.com/abseil/%{reponame}/archive/pypi-v%{version}/%{reponame}-pypi-v%{version}.tar.gz You can re-use URL in Source0 as %{url}. > %package -n python%{python3_pkgversion}-%{srcname} Is the %{python3_pkgversion} macro actually needed? Can these calls be replaced with simply python3-%{srcname} as is the case for the python2 packages? > %if 0%{?epel} != 7 > BuildRequires: %{py3_dist setuptools} > BuildRequires: %{py3_dist six} > %else > BuildRequires: python%{python3_pkgversion}-setuptools > BuildRequires: python%{python3_pkgversion}-six > > Requires: python%{python3_pkgversion}-six > %endif What about using "%if 0%{?epel} > 7" as a condition? I know you're not technically targeting EPEL6, but... > %if 0%{?epel} != 7 > BuildRequires: %{py3_dist setuptools} > BuildRequires: %{py3_dist six} > %else > BuildRequires: python%{python3_pkgversion}-setuptools > BuildRequires: python%{python3_pkgversion}-six > > Requires: python%{python3_pkgversion}-six > %endif Not sure about the use of %pyX_dist above. Would the format "pythonXdist(foo)" work in either/both cases? > %if 0%{?epel} != 7 > BuildRequires: %{py2_dist setuptools} > BuildRequires: %{py2_dist six} > BuildRequires: %{py2_dist enum34} > %else > BuildRequires: python2-setuptools > BuildRequires: python2-six > BuildRequires: python2-enum34 > > Requires: python2-six > Requires: python2-enum34 > %endif Same here. Full review matrix: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package installs properly. Note: Installation errors (see attachment) See: https://docs.fedoraproject.org/en-US/packaging-guidelines/ ===== MUST items ===== Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt packages [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: "Unknown or generated", "*No copyright* GNU General Public License", "Apache License 2.0". 25 files have unknown license. Detailed output of licensecheck in /data/rpmbuild/SPECS/python-absl- py/python-absl-py/licensecheck.txt [x]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/python3.8, /usr/lib/python3.8/site-packages [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: 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. [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]: 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 20480 bytes in 6 files. [x]: Package complies to the Packaging Guidelines [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 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]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [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]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [!]: Reviewer should test that the package builds in mock. [-]: 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). [x]: 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. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [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: [!]: Rpmlint is run on all installed packages. Note: Mock build failed See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_use_rpmlint Installation errors ------------------- INFO: mock.py version 2.6 starting (python version = 3.8.6)... Start: init plugins INFO: selinux enabled Finish: init plugins INFO: Signal handler active Start: run Start: chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: enabled package manager cache Start: cleaning package manager metadata Finish: cleaning package manager metadata INFO: enabled HW Info plugin Mock Version: 2.6 INFO: Mock Version: 2.6 Finish: chroot init INFO: installing package(s): /data/rpmbuild/SPECS/python-absl-py/python3-absl-py-0.11.0-1.fc32.noarch.rpm ERROR: Command failed: # /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 34 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk install /data/rpmbuild/SPECS/python-absl-py/python3-absl-py-0.11.0-1.fc32.noarch.rpm --setopt=tsflags=nocontexts Rpmlint ------- Checking: python3-absl-py-0.11.0-1.fc32.noarch.rpm python-absl-py-0.11.0-1.fc32.src.rpm python3-absl-py.noarch: W: spelling-error %description -l en_US startup -> start up, start-up, upstart python3-absl-py.noarch: W: spelling-error %description -l en_US commandline -> command line, command-line, commandment python-absl-py.src: W: spelling-error %description -l en_US startup -> start up, start-up, upstart python-absl-py.src: W: spelling-error %description -l en_US commandline -> command line, command-line, commandment 2 packages and 0 specfiles checked; 0 errors, 4 warnings. Source checksums ---------------- https://github.com/abseil/abseil-py/archive/pypi-v0.11.0/abseil-py-pypi-v0.11.0.tar.gz : CHECKSUM(SHA256) this package : 3d6df995991b8209ab113427544009ea77437d2aee76ffb5b75c802dd0d96b7c CHECKSUM(SHA256) upstream package : 3d6df995991b8209ab113427544009ea77437d2aee76ffb5b75c802dd0d96b7c Requires -------- python3-absl-py (rpmlib, GLIBC filtered): python(abi) python3.8dist(six) Provides -------- python3-absl-py: python-absl-py python3-absl-py python3.8dist(absl-py) python3dist(absl-py)
> You can re-use URL in Source0 as %{url}. Good idea; done. > Is the %{python3_pkgversion} macro actually needed? Can these calls be replaced with simply python3-%{srcname} as is the case for the python2 packages? This is a standard EPEL’ism, unfortunately; see https://fedoraproject.org/wiki/PackagingDrafts:Python3EPEL. > Not sure about the use of %pyX_dist above. Would the format "pythonXdist(foo)" work in either/both cases? Yes, since there aren’t any modules with odd names for py3_dist to adjust, this would be fine. > What about using "%if 0%{?epel} > 7" as a condition? I know you're not technically targeting EPEL6, but... This would be OK, although it would have to be "%if 0%{?epel} > 7 || ! 0%{?epel}" to avoid catching Fedora. > - Package installs properly. > Note: Installation errors (see attachment) > See: https://docs.fedoraproject.org/en-US/packaging-guidelines/ Looking at the command that failed, > # /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 34 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk install /data/rpmbuild/SPECS/python-absl-py/python3-absl-py-0.11.0-1.fc32.noarch.rpm --setopt=tsflags=nocontexts it was trying to install a Fedora 32 package into a Fedora 34/Rawhide root. No wonder it did not work! Any idea what caused this OS version mismatch? I think you have inadvertently convinced me that, for Python packages like this in particular, it would be better to submit a clean Fedora package, then introduce EPEL-specific cruft only in the relevant branches once the package is created, rather than littering the initial submission and the Fedora master with excessive conditionals. New Spec URL: https://gitlab.com/musicinmybrain/abseil-py-rpm/-/raw/9d4a6a4a/python-absl-py.spec New SRPM URL: https://kojipkgs.fedoraproject.org//work/tasks/9640/56289640/python-absl-py-0.11.0-2.fc34.src.rpm New Koji builds: F34: https://koji.fedoraproject.org/koji/taskinfo?taskID=56289639 F33: https://koji.fedoraproject.org/koji/taskinfo?taskID=56289660 F32: https://koji.fedoraproject.org/koji/taskinfo?taskID=56289694 I guess the EPEL versions are now technically out of scope of the review, but you’re welcome to look over https://gitlab.com/musicinmybrain/abseil-py-rpm/-/raw/86f21d51bc792bc94e1ecd334f0b75cd829447f9/python-absl-py.spec, which works for both EPEL7 and EPEL8.
> This is a standard EPEL’ism, unfortunately; see https://fedoraproject.org/wiki/PackagingDrafts:Python3EPEL. I see, yes. Thanks for the link! > it was trying to install a Fedora 32 package into a Fedora 34/Rawhide root. No wonder it did not work! Any idea what caused this OS version mismatch? This one's on me. Apologies! I grabbed the wrong Koji build. > New Spec URL: https://gitlab.com/musicinmybrain/abseil-py-rpm/-/raw/9d4a6a4a/python-absl-py.spec > %package -n python3-%{srcname} > Summary: %{summary} > %if 0%{?fedora} < 33 > %py_provides python3-%{srcname} > %endif I would probably remove this check, since F33 is on its way out. > I think you have inadvertently convinced me that, for Python packages like this in particular, it would be better to submit a clean Fedora package, then introduce EPEL-specific cruft only in the relevant branches once the package is created, rather than littering the initial submission and the Fedora master with excessive conditionals. I think there are pros and cons to that. Would keeping the EPEL files in separate branches not make their git trees (EPEL7 and EPEL8) diverge from master and then require extra fiddling to keep the common bits in-sync with Fedora packages? On the other hand, it does make the SPEC files vastly more readable. > I guess the EPEL versions are now technically out of scope of the review, but you’re welcome to look over https://gitlab.com/musicinmybrain/abseil-py-rpm/-/raw/86f21d51bc792bc94e1ecd334f0b75cd829447f9/python-absl-py.spec, which works for both EPEL7 and EPEL8. Double-checked it with the extra EPEL guidelines and this looks good! I also haven't found any information on whether it's allowed or not to let Fedora and EPEL git trees diverge on purpose. From my side the package is approved :).
> I think there are pros and cons to that. Yes, I agree. In the end, the EPEL versions are separate branches in Pagure either way; they may or may not have the same contents as the Fedora branches. The question is whether to handle the divergence in spec file syntax and so on with conditionals, or at the point of merging changes from Fedora master. I’ve seen both practices “in the wild.” I think I’m starting to believe in the latter. > I also haven't found any information on whether it's allowed or not to let Fedora and EPEL git trees diverge on purpose. I think this follows from the EPEL updates policy (https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies); Fedora Rawhide always wants the latest version of everything, while packages in EPEL are expected to avoid disruptive updates over the release lifecycle of as much as a decade. Divergence over time is thus guaranteed in almost all cases on the basis of differing package versions alone.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/python-absl-py
Package already in Fedora 32, 33 and Rawhide.