HEADS UP: This package won't currently build on rawhide due to Python 3.11. The upstream dev is actively working on Python 3.11 support. https://github.com/beanbaginc/kgb/issues/9#issuecomment-1203252755 When using fedora-review on this you'll need to pass it a mock env representing f35, f36, epel8, or epel9. I can't find any docs stating that packages that won't build on rawhide can't be submitted...if there are docs on this please let me know where. Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.0-1.fc36.src.rpm Description: Ever deal with a large test suite before, monkey patching functions to figure out whether it was called as expected? It’s a dirty job. If you’re not careful, you can make a mess of things. Leave behind evidence. kgb’s spies will take care of that little problem for you. What are spies?Spies intercept and record calls to functions. They can report on how many times a function was called and with what arguments. They can allow the function call to go through as normal, to block it, or to reroute it to another function. Spies are awesome. (If you’ve used Jasmine, you know this.) Spies are like mocks, but better. You’re not mocking the world. You’re replacing very specific function logic, or listening to functions without altering them. Fedora Account System Username: jonathanspw
Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=90412332
Spec sanity check: > %{?!python3_pkgversion:%global python3_pkgversion 3} This should never be needed, why is it in the spec? > %global srcname kgb Setting and using this IMHO makes the spec file harder to read (I cannot for example copy-paste the URL to my web browser) with very little benefit. It's not like I can copy-paste the entire spec, change this macro, and ship that as another package, or is it? > # requested upstream add license https://github.com/beanbaginc/kgb/issues/10 > Source1: LICENSE Where is this file coming from in the meantime? > BuildRequires: python%{python3_pkgversion}-devel > BuildRequires: python%{python3_pkgversion}-setuptools > # Test dependencies: > BuildRequires: python3dist(pytest) > BuildRequires: python3dist(six) You choose to make the spec file more complex by using the %{python3_pkgversion} macro instead of literally using 3. But then you use python3dist(pytest) directly, discarding any potential benefit of using %{python3_pkgversion} in the first place. What is your motivation for using %{python3_pkgversion}? What EPEL versions and Python versions in that EPEL do you target here? Is it needed, or is it just copy-pasted from some other spec file? > %{?python_provide:%python_provide python3-%{srcname}} This is deprecated and SHOULD NOT be used. See the note at the end of https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/#_the_py_provides_macro > %if 0%{?fedora} || 0%{?rhel} > 8 > ... > %if 0%{?el8} The spec seems to mix two kinds of conditionals that mean the same in this context. I highly recommend choosing one and sticking to it. The old/new Python packaging style %id/%else is already hard to follow as it is. > %if 0%{?fedora} || 0%{?rhel} > 8 > %generate_buildrequires > %pyproject_buildrequires > %endif What is the benefit of using this, considering the package already needs to list all the deps for EPEL 8? > # move local module folder out of the way so pytest doesn't use the wrong one > %pytest --pyargs %{srcname} The comment does not seem to correspond to the actual usage. Is it outdated?
> %{python3_sitelib}/%{srcname}-%{version}.dev* This is also a bit weird. Why dev? I see the package is recognized as 7.0.dev0 by Python tools. Is that a packaging bug? Should this be plain 7.0?
(In reply to Miro Hrončok from comment #3) > > %{python3_sitelib}/%{srcname}-%{version}.dev* > > This is also a bit weird. Why dev? I see the package is recognized as > 7.0.dev0 by Python tools. Is that a packaging bug? Should this be plain 7.0? When I unpack the tarball and run: $ python -c 'import setuptools.build_meta; setuptools.build_meta.prepare_metadata_for_build_wheel(".")' I get: $ grep ^Version: kgb.dist-info/METADATA Version: 7.0.dev0.dev The build log is also full of: /usr/lib/python3.10/site-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 7.0.dev0.dev is an invalid version and will not be supported in a future release
From setup.cfg: [egg_info] tag_build = .dev Removing that makes the version paring work. You might want to use the tarball from PyPI which does not have that.
s/paring/parsing/
(In reply to Miro Hrončok from comment #2) > Spec sanity check: > > > > %{?!python3_pkgversion:%global python3_pkgversion 3} > Per our IRC chat...rpmdev-newspec -t python > > > > %global srcname kgb > > Setting and using this IMHO makes the spec file harder to read (I cannot for > example copy-paste the URL to my web browser) with very little benefit. It's > not like I can copy-paste the entire spec, change this macro, and ship that > as another package, or is it? I've seen it in a few other places as standard practice. It's not really needed or beneficial here. > > > # requested upstream add license https://github.com/beanbaginc/kgb/issues/10 > > Source1: LICENSE > > Where is this file coming from in the meantime? PyPI lists MIT on the package and it is controlled by upstream and their other projects are all MIT. I pulled a copy of their MIT license from https://github.com/beanbaginc/diffx/blob/master/LICENSE which is a project that pulls this as a dependency. I suspect they'll have the license added to the repo before this hits our prod repos. The dev has been very responsive. > > > BuildRequires: python%{python3_pkgversion}-devel > > BuildRequires: python%{python3_pkgversion}-setuptools > > # Test dependencies: > > BuildRequires: python3dist(pytest) > > BuildRequires: python3dist(six) > > > You choose to make the spec file more complex by using the > %{python3_pkgversion} macro instead of literally using 3. But then you use > python3dist(pytest) directly, discarding any potential benefit of using > %{python3_pkgversion} in the first place. What is your motivation for using > %{python3_pkgversion}? What EPEL versions and Python versions in that EPEL > do you target here? Is it needed, or is it just copy-pasted from some other > spec file? More rpmdev-newspec -t python defaults. > > %{?python_provide:%python_provide python3-%{srcname}} > > This is deprecated and SHOULD NOT be used. See the note at the end of > https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ > #_the_py_provides_macro More rpmdev-newspec -t python defaults > > %if 0%{?fedora} || 0%{?rhel} > 8 > > ... > > %if 0%{?el8} > > The spec seems to mix two kinds of conditionals that mean the same in this > context. I highly recommend choosing one and sticking to it. The old/new > Python packaging style %id/%else is already hard to follow as it is. I missed this when simplifying conditionals to just check 0?%{elX}. It was supposed to match the other two. > > %if 0%{?fedora} || 0%{?rhel} > 8 > > %generate_buildrequires > > %pyproject_buildrequires > > %endif > > What is the benefit of using this, considering the package already needs to > list all the deps for EPEL 8? This does properly install some deps, pip for example. I'll see about doing a PR upstream to get all the deps listed properly so the static BuildRequires can be removed. pip is grabbed on EPEL8 as a dep for something else (one of the other buildrequires in epel8 must be requiring it), but it's not on Fedora, so this take care of it on Fedora. > > # move local module folder out of the way so pytest doesn't use the wrong one > > %pytest --pyargs %{srcname} > > The comment does not seem to correspond to the actual usage. Is it outdated? Fixed. Was a leftover from trying to figure out how to work around a testing issue (thanks for your help with that BTW). (In reply to Miro Hrončok from comment #3) > > %{python3_sitelib}/%{srcname}-%{version}.dev* > > This is also a bit weird. Why dev? I see the package is recognized as > 7.0.dev0 by Python tools. Is that a packaging bug? Should this be plain 7.0? I see your comment about upstream issue in git. I'll PR it probably. (In reply to Miro Hrončok from comment #4) > (In reply to Miro Hrončok from comment #3) > > > %{python3_sitelib}/%{srcname}-%{version}.dev* > > > > This is also a bit weird. Why dev? I see the package is recognized as > > 7.0.dev0 by Python tools. Is that a packaging bug? Should this be plain 7.0? > > When I unpack the tarball and run: > > $ python -c 'import setuptools.build_meta; > setuptools.build_meta.prepare_metadata_for_build_wheel(".")' > > I get: > > $ grep ^Version: kgb.dist-info/METADATA > Version: 7.0.dev0.dev > > > The build log is also full of: > > /usr/lib/python3.10/site-packages/pkg_resources/__init__.py:116: > PkgResourcesDeprecationWarning: 7.0.dev0.dev is an invalid version and will > not be supported in a future release Guess this is an upstream issue that needs to be fixed? They've got it published as a full on release. I'll submit a PR to github and use PyPI for now. Fixed all spec mentioned issues and versioning issue. The spec file indeed looks a ton cleaner now. Thank you for the feedback. Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.0-2.fc36.src.rpm
> The spec file indeed looks a ton cleaner now. Awesome, indeed it does. A few more tiny nit-picks: ----------- > BuildRequires: python3-setuptools vs. > BuildRequires: python3dist(pytest) This is not consistent. Let's use python3dist(setuptools) and python3dist(pytest), or python3-setuptools and python3-pytest? ----------- > install -m 644 %{SOURCE1} LICENSE This is part of %install, but it does not install the LICENSE file to the package, it merely copies the file to $PWD. Semantically, this belongs to %prep. I'd probably use `cp -a` instead of `install` myself, but that's just my personal opinion. ----------- > %dir %{python3_sitelib}/kgb > %{python3_sitelib}/kgb/* This does not look like a namespace package. I'd use simpler: %{python3_sitelib}/kgb/ ----------- > %{python3_sitelib}/kgb-%{version}.dist-info* Does this work: %{python3_sitelib}/kgb-%{version}.dist-info/ ? It is more explicit. Also easy to spot that it is a directory. ----------- Approximatelly half of the pacakge is occupied by /usr/lib/python3.10/site-packages/kgb/tests/ -- consider either not packaging those at all, or moving them to a python3-kgb-tests subpackage.
(In reply to Miro Hrončok from comment #8) > > The spec file indeed looks a ton cleaner now. > > Awesome, indeed it does. > > > > A few more tiny nit-picks: > > ----------- > > > BuildRequires: python3-setuptools > > vs. > > > BuildRequires: python3dist(pytest) > > This is not consistent. Let's use python3dist(setuptools) and > python3dist(pytest), or python3-setuptools and python3-pytest? You know, I never would've typed the python3dist version if I did it myself. rpmdev-newspec is the gift that keeps on giving. > ----------- > > > install -m 644 %{SOURCE1} LICENSE > > This is part of %install, but it does not install the LICENSE file to the > package, it merely copies the file to $PWD. Semantically, this belongs to > %prep. I'd probably use `cp -a` instead of `install` myself, but that's just > my personal opinion. Moved to prep using cp. > ----------- > > > %dir %{python3_sitelib}/kgb > > %{python3_sitelib}/kgb/* > > This does not look like a namespace package. I'd use simpler: > > %{python3_sitelib}/kgb/ Indeed it works properly with the trailing / there. It didn't without it. > ----------- > > > %{python3_sitelib}/kgb-%{version}.dist-info* > > Does this work: > > %{python3_sitelib}/kgb-%{version}.dist-info/ > > ? > > It is more explicit. Also easy to spot that it is a directory. Yes indeed. > ----------- > > > Approximatelly half of the pacakge is occupied by > /usr/lib/python3.10/site-packages/kgb/tests/ -- consider either not > packaging those at all, or moving them to a python3-kgb-tests subpackage. I think I'd rather not package them versus a sub-package though all other python specs I've looked at they just leave them in the main package. I checked a few popular python libs such as python3-pandas, python-urllib3, and python3-numpy A quick `dnf search test` didn't yield any real precedent of sub-packages for tests nor could I find docs on it. Can we just leave them to be in line with other packages?
$ repoquery --repo=rawhide -a | pkgname | grep -E '^python3-.+(-|\+)tests?$' python3-aodhclient-tests python3-ara-tests python3-cliff-tests python3-cotyledon-tests python3-designateclient-tests python3-gensim-test python3-gnocchiclient-tests python3-ipyparallel-tests python3-ipython-tests python3-jupyter-kernel-test python3-keystoneclient-tests python3-kubernetes-tests python3-magnumclient-tests python3-metakernel-tests python3-neutronclient-tests python3-octaviaclient-tests python3-openstacksdk-tests python3-osc-lib-tests python3-oslo-concurrency-tests python3-oslo-context-tests python3-oslo-db-tests python3-oslo-log-tests python3-oslo-serialization-tests python3-oslo-utils-tests python3-pandas+test python3-process-tests python3-psutil-tests python3-psycopg2-tests python3-pyghmi-tests python3-rsd-lib-tests python3-rsdclient-tests python3-rustcfg-tests python3-samba-test python3-sport-activities-features-tests python3-subunit-test python3-sushy-tests python3-tinyrpc-tests python3-virtualbmc-tests python3-zmq-tests
Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.0-3.fc36.src.rpm
(discarding %doc, %license and epel8 for readability) ================================================ %files -n python3-kgb %{python3_sitelib}/kgb/*.py %{python3_sitelib}/kgb/__pycache__/ %{python3_sitelib}/kgb-%{version}.dist-info/ %files -n python3-kgb-tests %{python3_sitelib}/kgb/tests ================================================ This means nothing owns %{python3_sitelib}/kgb/ You can fix that by: ================================================ %files -n python3-kgb %dir %{python3_sitelib}/kgb/ %{python3_sitelib}/kgb/*.py %{python3_sitelib}/kgb/__pycache__/ %{python3_sitelib}/kgb-%{version}.dist-info/ %files -n python3-kgb-tests %{python3_sitelib}/kgb/tests ================================================ Or better yet: ================================================ %files -n python3-kgb %{python3_sitelib}/kgb/ %exclude %{python3_sitelib}/kgb/tests/ %{python3_sitelib}/kgb-%{version}.dist-info/ %files -n python3-kgb-tests %{python3_sitelib}/kgb/tests/ ================================================ ================================================ %package -n python3-kgb-tests Summary: Unit tests for python3-kgb Requires: python3-kgb BuildRequires: python3-pytest BuildRequires: python3-six ================================================ 1) Use `Requires: python3-kgb = %{version}-%{release} 2) I'd not personally hide the buildrequires here 3) should that package require six on runtime if it needs it on buildtime? ================================================ %files -n python3-kgb-tests %license LICENSE ... ================================================ There is no need for the LICENSE file here, see https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#subpackage-licensing
(In reply to Miro Hrončok from comment #12) > (discarding %doc, %license and epel8 for readability) > > ================================================ > %files -n python3-kgb > %{python3_sitelib}/kgb/*.py > %{python3_sitelib}/kgb/__pycache__/ > %{python3_sitelib}/kgb-%{version}.dist-info/ > > %files -n python3-kgb-tests > %{python3_sitelib}/kgb/tests > ================================================ > > This means nothing owns %{python3_sitelib}/kgb/ > > You can fix that by: > > ================================================ > %files -n python3-kgb > %dir %{python3_sitelib}/kgb/ > %{python3_sitelib}/kgb/*.py > %{python3_sitelib}/kgb/__pycache__/ > %{python3_sitelib}/kgb-%{version}.dist-info/ > > %files -n python3-kgb-tests > %{python3_sitelib}/kgb/tests > ================================================ > > Or better yet: > > ================================================ > %files -n python3-kgb > %{python3_sitelib}/kgb/ > %exclude %{python3_sitelib}/kgb/tests/ > %{python3_sitelib}/kgb-%{version}.dist-info/ > > %files -n python3-kgb-tests > %{python3_sitelib}/kgb/tests/ > ================================================ I thought this is how it should be (less the exclude part, wasn't aware of that macro) but I thought you said don't do it above (quoted below)? Perhaps I misunderstood what you meant. ----- > > %dir %{python3_sitelib}/kgb > > %{python3_sitelib}/kgb/* > > This does not look like a namespace package. I'd use simpler: > > %{python3_sitelib}/kgb/ ----- > ================================================ > %package -n python3-kgb-tests > Summary: Unit tests for python3-kgb > Requires: python3-kgb > BuildRequires: python3-pytest > BuildRequires: python3-six > ================================================ > > 1) Use `Requires: python3-kgb = %{version}-%{release} > 2) I'd not personally hide the buildrequires here > 3) should that package require six on runtime if it needs it on buildtime? 1) Done 2) Moved back to main section with the other BuildRequires. 3) six is actually not required at all. Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.0-4.fc36.src.rpm
Yeah, my original remark was for: %{python3_sitelib}/kgb/* only. The %files section looks sane now. So does the rest of the spec.
Updated to 7.1 which will build on rawhide/Python 3.11. Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.1-1.fc37.src.rpm Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=90504973
Updated to 7.1.1 which includes a license file from upstream. Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.1.1-1.fc37.src.rpm
I will take this review.
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/python-kgb See: https://docs.fedoraproject.org/en-US/packaging- guidelines/Naming/#_conflicting_package_names That's a message from fedora-review. That just means that this package has been in Fedora before, so this process has to be followed: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming - The python-kgb package seems odd. It simply duplicates the doc files and license file that are also in python3-kgb. Is there a reason to have this package? - Minor nitpick: in the 3rd paragraph of %_description, there should be a space after the question mark. ===== 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: "Unknown or generated", "MIT License", "*No copyright* MIT License". 33 files have unknown license. [x]: License file installed when any subpackage combination is installed. [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. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 81920 bytes in 6 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]: 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 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: [x]: 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]: Fully versioned dependency in subpackages if applicable. [?]: 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. [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]: 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 ------- python3-kgb-tests.noarch: W: no-documentation Rpmlint (installed packages) ---------------------------- python3-kgb-tests.noarch: W: no-documentation Source checksums ---------------- https://files.pythonhosted.org/packages/source/k/kgb/kgb-7.1.1.tar.gz : CHECKSUM(SHA256) this package : 74912c8761651f2063151c6c2a36ebe023393de491ec86744771a2888ab9845b CHECKSUM(SHA256) upstream package : 74912c8761651f2063151c6c2a36ebe023393de491ec86744771a2888ab9845b Requires -------- python-kgb (rpmlib, GLIBC filtered): python3-kgb (rpmlib, GLIBC filtered): python(abi) python3-kgb-tests (rpmlib, GLIBC filtered): python(abi) python3-kgb Provides -------- python-kgb: python-kgb python3-kgb: python-kgb python3-kgb python3.11-kgb python3.11dist(kgb) python3dist(kgb) python3-kgb-tests: python-kgb-tests python3-kgb-tests python3.11-kgb-tests Generated by fedora-review 0.9.0 (6761b6c) last change: 2022-08-23 Command line :/usr/bin/fedora-review -b 2114603 -m fedora-rawhide-x86_64 Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, Generic, Python Disabled plugins: Perl, R, Java, PHP, C/C++, Ruby, Haskell, SugarActivity, fonts, Ocaml Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH
> - Package does not use a name that already exists. > Note: A package with this name already exists. Please check > https://src.fedoraproject.org/rpms/python-kgb > See: https://docs.fedoraproject.org/en-US/packaging- > guidelines/Naming/#_conflicting_package_names > > That's a message from fedora-review. That just means that this package has > been in Fedora before, so this process has to be followed: > > https://docs.fedoraproject.org/en-US/package-maintainers/ > Package_Retirement_Process/#claiming Yep this is a re-review to get the package going again. I already have ownership of it but I can't request the new branches and re-package it until it's passed review since it was orphaned for over six weeks. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/ > - The python-kgb package seems odd. It simply duplicates the doc files and > license file that are also in python3-kgb. Is there a reason to have this > package? Uh, I don't think so. Nuked the files section for it so it doesn't get built. > - Minor nitpick: in the 3rd paragraph of %_description, there should be a > space > after the question mark. Fixed in my local copy :) Spec URL: https://jonathanspw.fedorapeople.org/python-kgb.spec SRPM URL: https://jonathanspw.fedorapeople.org/python-kgb-7.1.1-1.fc38.src.rpm
(In reply to Jonathan Wright from comment #19) > Uh, I don't think so. Nuked the files section for it so it doesn't get > built. That %files section is still in https://jonathanspw.fedorapeople.org/python-kgb.spec as of a moment ago. Make sure it is really gone before you import. This package is APPROVED.
FEDORA-2022-bcc7dada18 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-bcc7dada18
FEDORA-2022-bcc7dada18 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.