Spec URL: https://rebus.fedorapeople.org/python-dsinternals.spec SRPM URL: https://rebus.fedorapeople.org/python-dsinternals-1.2.4-1.fc39.src.rpm Description: Directory Services Internals Library. Python native library containing necessary classes, functions and structures to interact with Windows Active Directory. Installation python3 -m pip install dsinternals ContributingPull requests are welcome. Feel free to open an issue if... Fedora Account System Username: rebus
This package built on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=112144545
Copr build: https://copr.fedorainfracloud.org/coprs/build/6937237 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2259466-python-dsinternals/fedora-rawhide-x86_64/06937237-python-dsinternals/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Hello Michal, Is there a reason why this package doesn't use the %pyproject_buildrequires macro to build the python requirements (Ref: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_build_macros)?
Hello Steve, I would love to use the pyproject macros, but I plan to use the package acros the EPELs as well and pyproject is not on epel7 and having some issues on rhel8. I would preffer to have one spec for all supported platforms.
Would it then be possible to logicgate the sections, i.e. have el7 use the current version, but have el8+ and fedora use the new macros?
Spec URL: https://rebus.fedorapeople.org/python-dsinternals.spec SRPM URL: https://rebus.fedorapeople.org/python-dsinternals-1.2.4-2.fc39.src.rpm Hello, here the attempt to run the %generate_buildrequires/%pyproject_buildrequires if available https://copr.fedorainfracloud.org/coprs/rebus/infosec/build/6942085/ It is still failing on epel8 even it should not. Spec is requesting python%{python3_pkgversion}-setuptools, which on epel3 gets resolved as python3-setuptools, but then the build complains about missing setuptools ... probably module for python 3.11 I am thinking of swithcing back to legacy py3_build/py3_install ... that one would work even on rhel7 :(...
Created attachment 2010000 [details] The .spec file difference from Copr build 6937237 to 6944190
Copr build: https://copr.fedorainfracloud.org/coprs/build/6944190 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2259466-python-dsinternals/fedora-rawhide-x86_64/06944190-python-dsinternals/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
(In reply to Michal Ambroz from comment #6) > Spec URL: https://rebus.fedorapeople.org/python-dsinternals.spec > SRPM URL: > https://rebus.fedorapeople.org/python-dsinternals-1.2.4-2.fc39.src.rpm > > Hello, > here the attempt to run the %generate_buildrequires/%pyproject_buildrequires > if available > https://copr.fedorainfracloud.org/coprs/rebus/infosec/build/6942085/ > > It is still failing on epel8 even it should not. > Spec is requesting python%{python3_pkgversion}-setuptools, which on epel3 > gets resolved as python3-setuptools, but then the build complains about > missing setuptools ... probably module for python 3.11 > > I am thinking of swithcing back to legacy py3_build/py3_install ... that one > would work even on rhel7 :(... The el7 build seems to be failing because of ``` Error: No Package found for pyproject-rpm-macros ``` As far as el8 goes, yeah I would probably just revert back to the old python macros for that specific version, I'm guessing your haunch is right here. I'm not sure what Fedora's guidelines are as far as using a mixed legacy/pywheel macro set in a spec meant to be used in older versions of epel, to be 100% honest here.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
yep, still interested
epel7 is EOL now and epel8+ should support required macros: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ Can you please try to follow document above?
Helo Terje, please can you be more specific on which rules you believe the spec-file is not following the python guidelines? For fedora it is using %generate_buildrequires and pyproject macros to build the package. Even when removing the epel7 stuff, the epel8 has the pyproject macros, but the %generate_buildrequires doesn't work there and %pyproject_wheel is not able to build even if the dependencies are explicitly stated. At this point the package builds well only on fedora and rhel >= 9 . Spec URL: https://rebus.fedorapeople.org/python-dsinternals.spec SRPM URL: https://rebus.fedorapeople.org/python-dsinternals-1.2.4-3.fc43.src.rpm - here is the attempt with the EPEL7 stuff (mostly) removed, still doesn't build on EPEL8 (here is the failed EPEL8 scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=139543221 ) - it builds well on Fedora and RHEL9/10, (https://copr.fedorainfracloud.org/coprs/rebus/infosec/build/9852455/) Best regards Michal Ambroz
Created attachment 2116850 [details] The .spec file difference from Copr build 6944190 to 9852733
Copr build: https://copr.fedorainfracloud.org/coprs/build/9852733 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2259466-python-dsinternals/fedora-rawhide-x86_64/09852733-python-dsinternals/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Created attachment 2116876 [details] python-dsinternals build log Actually, it seems Michal is right here: https://docs.fedoraproject.org/en-US/epel/epel-packaging/#_python i.e.: `EPEL 8 Python packages MUST use the older guidelines.` Mainly because the new python scripts are not in EPEL8. Some suggestions:: This section: # python3-tox-current-env package is not available on EPEL8 # https://src.fedoraproject.org/rpms/python-tox-current-env %if 0%{?fedora} || ( 0%{?rhel} && 0%{?rhel} >= 9 ) BuildRequires: python%{python3_pkgversion}-tox-current-env %endif Can be removed. The `%pyproject_buildrequires -t` macro, specifically the -t part, gets the tox BRs automatically. So it is redundant. In the %check section: # EPEL8 missing tox dependency used for tests %if 0%{?fedora} || ( 0%{?rhel} && 0%{?rhel} >= 9 ) python3 -m unittest discover -v %tox %endif You don't need both %tox and the python tests, they both run the same tests. %tox is fine. No need for the python3 unittest module to be ran. There's other choices though, up to you. I would see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_tests for more information. But with that being said, I also tried to build this on epel8, and I get an error with dnf not finding setuptools (See attached log). Looking at the dnf logs, it seems to sometimes get python3.12-specific packages, and sometimes just python3 ones, maybe that's why? NOTE: To build, I used the same exact spec you provided in your last comment.
Oh and, if it helps, I used the following config to build with mock on epel8: /etc/mock/centos-stream+epel-8-x86_64.cfg
For EPEL8 these BuildRequires: python%{python3_pkgversion}-pyOpenSSL BuildRequires: python%{python3_pkgversion}-pycryptodomex are available as python3-pyOpenSSL python3-pycryptodomex which means Python 3.6 version, however Python 3.6 don't seems to be compatible with %pyproject* macros?
So, to be completely honest here, I do not know about packaging python to epel. But on fedora, you will find python3.XX-nameofpackage packages to support non-mainline python versions (For example, on F43, I think Python 3.14 is mainline, but you can find some Python3.13 and Python3.12 libraries. Not many though). If Epel works the same way, by specifying the minor version in the package name, you are potentially forcing said version. Again though I might be wrong -- I don't know how things work in epel8 world. Someone in the Fedora epel matrix room might be able to help with that.
Spec URL: https://rebus.fedorapeople.org/python-dsinternals.spec SRPM URL: https://rebus.fedorapeople.org/python-dsinternals-1.2.4-5.fc43.src.rpm I have tried to polish the buildrequires in such a way that it builds from RHEL8 to rawhide with pyproject macros. It builds well localy on my RHEL8 machine with python3.12-setuptools-68.2.2-5.el8_10 (https://access.redhat.com/errata/RHSA-2025:11044), but for some reason it doesn't build correctly with koji scratch build or copr environment: https://copr.fedorainfracloud.org/coprs/rebus/infosec/build/9862684/ https://kojipkgs.fedoraproject.org//work/tasks/5650/139655650/root.log
How do you build it for Fedora? To try to replicate the koji buildroot as much as humanely possible, I always simply use mock to build. In Fedora, you can install the fedora-packager meta package, and run fedpkg mockbuild --mock-config /etc/mock/<distro/release-arch>.cfg and it'll simply use a container environment to build with dnf.
Hello, > How do you build it for Fedora? I am not sure whether I understand the question right. Building this package on modern Fedora for the purpose of the new package review is not a problem. 1) mock build Your way = mockbuild, is the recommended way as you have reasonable say on what is in the mock-build root, but you do that compilation in chroot environment preventing it doing any acciental or even malicious changes to your testing system. it can be invoked directly with mock -r fedora-rawhide-x86_64 --rebuild python-dsinternals-1.2.4-5.fc43.src.rpm There are also other options like: 2) scratch build For review it is also recommended to do the "scratch build": fedpkg build --scratch --target rawhide --srpm python-dsinternals-1.2.4-5.fc43.src.rpm or directly with the koji command: koji build --scratch rawhide python-dsinternals-1.2.4-5.fc43.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=139666364 3) copr build you can upload the src.rpm to https://copr.fedorainfracloud.org/ and have it rebuilt there 4) local rpmbuild - least secure !!! rpmbuild --rebuild python-dsinternals-1.2.4-5.fc43.src.rpm or rpmbuild -ba python-dsinternals.spec
Created attachment 2117343 [details] The .spec file difference from Copr build 9852733 to 9863309
Copr build: https://copr.fedorainfracloud.org/coprs/build/9863309 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2259466-python-dsinternals/fedora-rawhide-x86_64/09863309-python-dsinternals/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.