[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 01. 05. 20 20:32, Troy Dawson wrote: 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. It wont. Just please make sure my commit eventually gets pushed in some update and that there is a buildroot override until that happens. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On Fri, May 1, 2020 at 9:36 AM Miro Hrončok wrote: > > On 14. 04. 20 19:04, Miro Hrončok wrote: > > 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. > > My EPEL 8 update got overridden by a new one. > Ya, sorry about the timing for that. I kept your changes in, but I wanted something in override fairly quick so packages that needed python could build. I guess I should have just done the override, and not bodhi. It's second nature for me to push things to bodhi when I build them so I don't forget about them. I haven't heard or seen any problems with your macros. And what I have up there probably isn't going to be the final fix for the python36/38 problem. 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. But, if there is a simple way, I'm fine with pushing your updates out to stable for epel8 > I suggest I push the EPEL 7 one, there was no reported breakage. > Sounds good. > > In case something is needed for EPEL 8 Playground, please do so, I have no > > idea > > really, sorry about that. > > Still no idea what is the story there. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 19:04, Miro Hrončok wrote: 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. My EPEL 8 update got overridden by a new one. I suggest I push the EPEL 7 one, there was no reported breakage. In case something is needed for EPEL 8 Playground, please do so, I have no idea really, sorry about that. Still no idea what is the story there. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
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. Thanks, Troy. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On Tue, Apr 14, 2020 at 9:27 AM Miro Hrončok wrote:
>
> On 14. 04. 20 17:40, Troy Dawson wrote:
> > On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok 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#comment-30941
> >>
> >> 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?
>
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.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 17:40, Troy Dawson wrote:
On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok 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#comment-30941
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok 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.
> > 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#comment-30941
>
> 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
>
>
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.
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
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#comment-30941
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
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
Hi Miro, I've taken a look, but haven't done any testing. 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. 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? 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. 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? On Tue, Apr 14, 2020 at 5:42 AM Miro Hrončok wrote: > > 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@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On Tue, 14 Apr 2020 at 06:08, Miro Hrončok wrote: > 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. 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. > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org > -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
[EPEL-devel] Python macro backports for EPEL reviews needed
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 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/40 Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Re: Reviews needed
On Wed, Jan 2, 2019 at 2:41 PM Tom Callaway wrote: > > When I wasn't looking, asymptote grew a new dependency, which means I > have two new packages that need reviews. > > python-speg: https://bugzilla.redhat.com/show_bug.cgi?id=1663036 > python-cson: https://bugzilla.redhat.com/show_bug.cgi?id=1663037 > > They're very small, very simple packages. Should take about a minute to > review. > > Will trade reviews or other packaging favors. > I'll grab these. In the near future, I will have reviews needed for getting Cavil into Fedora... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reviews needed
When I wasn't looking, asymptote grew a new dependency, which means I have two new packages that need reviews. python-speg: https://bugzilla.redhat.com/show_bug.cgi?id=1663036 python-cson: https://bugzilla.redhat.com/show_bug.cgi?id=1663037 They're very small, very simple packages. Should take about a minute to review. Will trade reviews or other packaging favors. tia, ~tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reviews needed: perl-Mail-Message and perl-Mail-Transport
These new components came out of perl-Mail-Box at 3.000. I need them reviewed to update Mail::Box. https://bugzilla.redhat.com/show_bug.cgi?id=1420099 https://bugzilla.redhat.com/show_bug.cgi?id=1420100 ~tom == Red Hat ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Python reviews needed
Hi On Wed, May 1, 2013 at 2:15 PM, Orion Poplawski wrote: I have some python packages that need reviewing: python-traitsui - https://bugzilla.redhat.com/**show_bug.cgi?id=829580https://bugzilla.redhat.com/show_bug.cgi?id=829580 python-envisage - https://bugzilla.redhat.com/show_bug.cgi?id=958523 I have taken the latter. Please review https://bugzilla.redhat.com/show_bug.cgi?id=917388 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python reviews needed
I have some python packages that need reviewing: python-traitsui - https://bugzilla.redhat.com/show_bug.cgi?id=829580 python-envisage - https://bugzilla.redhat.com/show_bug.cgi?id=958523 There may be more to come in the dep chain as well. These are needed to repair the broken Mayavi visualization tool package. I can swap for some reviews as well. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
netcdf 4.2 update coming - package split, reviews needed
I'm building netcdf 4.2-rc2 in rawhide now. This splits out the C++ and Fortran APIs into separate packages. Not sure I have time to do a swap, but I need the following reviews done: https://bugzilla.redhat.com/show_bug.cgi?id=742605 - netcdf-cxx4 https://bugzilla.redhat.com/show_bug.cgi?id=744334 - netcdf-fortran Especially the latter one. This used to be part of the netcdf package but has been split off. They should be pretty straightforward. netcdf-cxx the old deprecated C++ api is already reviewed and in. Packages that need these will need to add a BR on netcdf-api-devel as appropriate. After these are reviewed I'll be pushing 4.2 into F17 as well. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quite a few reviews needed :)
On Tue, 2011-06-28 at 20:13 +0200, Mario Blättermann wrote: Am 27.06.2011 20:03, schrieb Ankur Sinha: Hello, I've recently been packaging applications for the fedora medical initiative. There are quite a few of them. If you have some time to spare, please review a few (or just one). Even if you're not a sponsored packager, I encourage you to please review them unofficially. It will improve your understanding of the guidelines, and also pick out quite a few errors and help me :) Of course, if you accept a ticket, I will review a package for you in return :) Please have a look at the following url: https://bugzilla.redhat.com/show_bug.cgi?id=673841 I've picked up toothchart for the time being, some more reviews will follow probably. My open reviews: https://bugzilla.redhat.com/buglist.cgi?query_format=advancedproduct=Fedoraversion=rawhidecomponent=Package+Reviewquery_format=advancedbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=MODIFIEDkeywords_type=allwordskeywords=emailreporter1=1emailtype1=exactemail1=mariobl%40freenet.de Cheers, Mario Hi Mario, I've taken wmSun. https://bugzilla.redhat.com/show_bug.cgi?id=701079 Thanks! Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quite a few reviews needed :)
Am 27.06.2011 20:03, schrieb Ankur Sinha: Hello, I've recently been packaging applications for the fedora medical initiative. There are quite a few of them. If you have some time to spare, please review a few (or just one). Even if you're not a sponsored packager, I encourage you to please review them unofficially. It will improve your understanding of the guidelines, and also pick out quite a few errors and help me :) Of course, if you accept a ticket, I will review a package for you in return :) Please have a look at the following url: https://bugzilla.redhat.com/show_bug.cgi?id=673841 I've picked up toothchart for the time being, some more reviews will follow probably. My open reviews: https://bugzilla.redhat.com/buglist.cgi?query_format=advancedproduct=Fedoraversion=rawhidecomponent=Package+Reviewquery_format=advancedbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=MODIFIEDkeywords_type=allwordskeywords=emailreporter1=1emailtype1=exactemail1=mariobl%40freenet.de Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
On 2011-06-06 11:17, Tom Callaway wrote: As usual, I will swap reviews or favors (within limits) for reviews on some new packages for me: mono-reflection: https://bugzilla.redhat.com/show_bug.cgi?id=711181 pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 gambas3: https://bugzilla.redhat.com/show_bug.cgi?id=710203 As soon as I clarify the licensing, I will also have gnome-shell-extension-pidgin up for review. I can have a look at pyrit. I need to iron out some issues with my next package submission before I can ask anyone to review anything for me, though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
Tom Callaway wrote: pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 SARCASMOh great, because a tool to parasite wireless connections which the owners went out of the way to secure with the best available protocol is EXACTLY what we need…/SARCASM Use of this tool is probably against the law in most of the world. (Some countries even ban using unencrypted wireless networks without explicit permission.) And I fail to see any legitimate use for this tool. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
On Tue, Jun 07, 2011 at 03:12:19PM +0200, Kevin Kofler wrote: Tom Callaway wrote: pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 SARCASMOh great, because a tool to parasite wireless connections which the owners went out of the way to secure with the best available protocol is EXACTLY what we need…/SARCASM Use of this tool is probably against the law in most of the world. (Some countries even ban using unencrypted wireless networks without explicit permission.) And I fail to see any legitimate use for this tool. White hats and black hats require the exact same tools to do their job. Penetration testing is a huge part of what security researchers do. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
On Tue, Jun 07, 2011 at 03:12:19PM +0200, Kevin Kofler wrote: Tom Callaway wrote: pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 SARCASMOh great, because a tool to parasite wireless connections which the owners went out of the way to secure with the best available protocol is EXACTLY what we need…/SARCASM Use of this tool is probably against the law in most of the world. (Some countries even ban using unencrypted wireless networks without explicit permission.) And I fail to see any legitimate use for this tool. I don't think we should be making judgements about what people use programs for. Otherwise where will it end? 'nmap'? 'cp'? (And yes, I *do* want to run this tool on my own wireless connection at some point now I know it exists) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
On 06/07/2011 12:29 PM, Richard W.M. Jones wrote: On Tue, Jun 07, 2011 at 03:12:19PM +0200, Kevin Kofler wrote: Tom Callaway wrote: pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 SARCASMOh great, because a tool to parasite wireless connections which the owners went out of the way to secure with the best available protocol is EXACTLY what we need…/SARCASM Use of this tool is probably against the law in most of the world. (Some countries even ban using unencrypted wireless networks without explicit permission.) And I fail to see any legitimate use for this tool. I don't think we should be making judgements about what people use programs for. Otherwise where will it end? 'nmap'? 'cp'? (And yes, I *do* want to run this tool on my own wireless connection at some point now I know it exists) This remind me SQLninja issue, BTW we should not ban security auditing apps if they meet fedora standards. https://fedoraproject.org/wiki/Meeting:Board_meeting_2010-11-08 https://bugzilla.redhat.com/show_bug.cgi?id=637402 -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package Reviews Needed
As usual, I will swap reviews or favors (within limits) for reviews on some new packages for me: mono-reflection: https://bugzilla.redhat.com/show_bug.cgi?id=711181 pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 gambas3: https://bugzilla.redhat.com/show_bug.cgi?id=710203 As soon as I clarify the licensing, I will also have gnome-shell-extension-pidgin up for review. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
