On 02. 01. 20 15:36, Miro Hrončok wrote: > Hey EPEL experts. Could you please have a look at: > > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/13 > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14 > > Thanks. Is EPEL interested in Fedora compatibility? Or shall I stop caring and close them?

-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...

On 14. 04. 20 13:26, Stephen John Smoogen wrote: > Miro. > > EPEL is interested in Fedora compatibility but has 0 people staffed to it. I > got slammed by the datacentre move and dropped the ball on this. Troy took over > for me last month and has been trying to catch up on all the things we have > outstanding. Thank you for reminding us of this outstanding work. I appreciate that you care. My interest in EPEL is purely "best effort" as I am not an EPEL user myself -- I try to not break use cases for people who like to maintain packages in Fedora and EPEL alike, but sometimes it's really hard to guess what would work for EPEL best when there is no response. I would very much like to have some "EPEL <-> Python" representative/partner I could bring this sort of stuff to. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...

On 14. 04. 20 15:56, Troy Dawson wrote: > Hi Miro, > I've taken a look, but haven't done any testing. Thanks. > EPEL6 patch - no. Even if it works, I'd say no. We're at the last 7 > months before EOL and I don't want the EPEL6 stuff to have changes > like this. I could be outvoted by this, but I believe most of the > other EPEL packagers would feel this way. Makes perfect sense. > EPEL7 patch - This would require some testing. When we tried to turn > on the python automatic-dependency checking, there were things that > broke on EPEL7 so they never got implemented. What, or how they > broke, I don't currently know. I just know that they did, and there > wasn't a big enough demand to debug. As in zero demand. Nobody asked > for it in EPEL7, only EPEL8. So I'm not even sure this would be worth > the testing. Has anyone asked for this? Not yet. But If we want packagers to start using %pycached, I know there are some of them who would blindly merge their master branch to epel7 and they expect it will work. I suggest that we backport %pycached only, the name is unlikely to clash with anything. %python can be separated and not backported. Sounds good?

> EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora, > so I'm in favor of this. > I'm pretty sure the %pycached shouldn't be a problem. I agree. > What is %python supposed to resolve to? To me it looks like > /usr/bin/python ... which there isn't any in RHEL8. And, I thought > Fedora got rid of it also, in favor of specifically doing python2 or > python3. Or did that change? So the main idea was that based on some FPC and RPMdevs discussions about underscor-prefixed macros, packagers should not be using those directly, however our guidelines were full of referecens to %{__python3}. We have come up with a conclusion: Macros with underscores, such as %__python3 are intended to be reset to change bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m pytest`. Details: https://pagure.io/packaging-committee/issue/907 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comm... The only problem was the %{python} macro. When you redefine %__python to a sane (explicit) value, you want %{python} to work, because e.g. %{python_version} works. But we didn't want to encourage usage of "unversioned python" by adding %{python}. So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards compatible default), %{python} gives you an error. If %__python is anything else, %{python} gives that to you. Fedora 32: $ rpm --define '__python /usr/bin/python3.6' --eval '%python_version' 3.6 $ rpm --define '__python /usr/bin/python3.6' --eval '%python' /usr/bin/python3.6 $ rpm --eval '%python_version' 3.8 $ rpm --eval '%python' error: Cannot use %python if %__python wasn't redefined to something other than /usr/bin/python. EPEL 8: $ rpm --define '__python /usr/bin/python3.6' --eval '%python_version' 3.6 $ rpm --define '__python /usr/bin/python3.6' --eval '%python' %python $ rpm --eval '%python_version' error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly $ rpm --eval '%python' %python

-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

On 14. 04. 20 17:40, Troy Dawson wrote: > On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: >> >> On 14. 04. 20 15:56, Troy Dawson wrote: >>> Hi Miro, >>> I've taken a look, but haven't done any testing. >> >> Thanks. >> >>> EPEL6 patch - no. Even if it works, I'd say no. We're at the last 7 >>> months before EOL and I don't want the EPEL6 stuff to have changes >>> like this. I could be outvoted by this, but I believe most of the >>> other EPEL packagers would feel this way. >> >> Makes perfect sense. >> >>> EPEL7 patch - This would require some testing. When we tried to turn >>> on the python automatic-dependency checking, there were things that >>> broke on EPEL7 so they never got implemented. What, or how they >>> broke, I don't currently know. I just know that they did, and there >>> wasn't a big enough demand to debug. As in zero demand. Nobody asked >>> for it in EPEL7, only EPEL8. So I'm not even sure this would be worth >>> the testing. Has anyone asked for this? >> >> Not yet. But If we want packagers to start using %pycached, I know there are >> some of them who would blindly merge their master branch to epel7 and they >> expect it will work. I suggest that we backport %pycached only, the name is >> unlikely to clash with anything. %python can be separated and not backported. >> Sounds good? >> > > Yep, sounds good to me. Amended https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14 >>> EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora, >>> so I'm in favor of this. >>> I'm pretty sure the %pycached shouldn't be a problem. >> >> I agree. >> >>> What is %python supposed to resolve to? To me it looks like >>> /usr/bin/python ... which there isn't any in RHEL8. And, I thought >>> Fedora got rid of it also, in favor of specifically doing python2 or >>> python3. Or did that change? >> >> So the main idea was that based on some FPC and RPMdevs discussions about >> underscor-prefixed macros, packagers should not be using those directly, however >> our guidelines were full of referecens to %{__python3}. We have come up with a >> conclusion: >> >> Macros with underscores, such as %__python3 are intended to be reset to change >> bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on >> EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be >> used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m >> pytest`. >> >> Details: >> https://pagure.io/packaging-committee/issue/907 >> https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comm... >> >> The only problem was the %{python} macro. When you redefine %__python to a sane >> (explicit) value, you want %{python} to work, because e.g. %{python_version} >> works. But we didn't want to encourage usage of "unversioned python" by adding >> %{python}. >> >> So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards >> compatible default), %{python} gives you an error. If %__python is anything >> else, %{python} gives that to you. >> > > Ahh ... now that you explain it, I was reading it totally backwards. > I'd still like to test it on a variety of packages, but unless others > have some type of objection, as long as it passes the tests, I'm good > with it. What kind of packages would need the test? This is mostly backwards compatible. The only packages that could be problematic are packages that use a constructs like this: %{!?python:...} or %if %{defined python} -> previously %python was not defined, now it is and hence the conditional will have a different result Or like this: %global pyver_sitelib %python%{pyver}_sitelib -> previously %python was not defined, now it is and hence the code produces invalid result I suppose such cases could be figured out with a grep. Is there something like https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz but for epel branches?

On 14. 04. 20 18:46, Troy Dawson wrote: > Yep, I'm having a hard time finding anything relevant to test. > I have verified it doesn't conflict with any other rpm macro, but I'm > pretty sure you had already checked that. > So, I'm giving it a thumbs up. > And I'll give it a thumbs up on the pull requests as well. EPEL 7 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c0bec7842 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-24 EPEL 8 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2bb92fb39 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10 I've disabled both time based and karma based push. We can observe the EPEL builds and decide whether to push this or not in ~1 month.

In case something is needed for EPEL 8 Playground, please do so, I have no idea really, sorry about that.

I've never un-updated anything, and I'm not sure if it will make it possible for your packages to be pushed to stable.