[EPEL-devel] Re: fop for epel 8
Naively cloning f30 branch and performing a local build: ant is available as module No match for apache-commons, avalon-framework, batik, fontbox, javapackages-local, junit, qdox, servlet, xmlgraphics-commons, xmlunit I guess there's some work to do... ___ 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] fop for epel 8
I'd like to package fop for epel-8, but not sure how to do that (haven't done epel in the new era). There are epel8 and epel8-playground branches but they look like incomplete modularity support. Is normal rpm packaging for fop a fool's errand for epel8? Can one of the admins add me as a contributor so I can package rpm/module for epel8? Regards, Tim fas: ttorling ___ 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] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 24 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4 ansible-2.9.6-1.el8 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-79bd0a6b28 chromium-80.0.3987.149-1.el8 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f16ad37b5e tor-0.4.2.7-1.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2cb1029c5a okular-18.12.2-2.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-913d6d1779 coturn-4.5.1.1-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing cros-guest-tools-1.0-0.30.20200330git61d9c12.el8 easy-rsa-3.0.7-1.el8 haxe-4.0.5-5.el8 heimdal-7.7.0-6.el8 libuInputPlus-0.1.4-5.el8 python-jaraco-classes-2.0-7.el8 python-more-itertools-7.2.0-3.el8 python-plugnplay-0.5.4-1.el8 python-polib-1.0.7-10.el8 python-requests-unixsocket-0.1.5-5.el8 python-rst-linker-1.11-4.el8 python-sphinx-testing-1.0.1-6.el8 python-trustme-0.5.2-4.el8 python-zc-lockfile-2.0-2.el8 Details about builds: cros-guest-tools-1.0-0.30.20200330git61d9c12.el8 (FEDORA-EPEL-2020-18beef383d) Chromium OS integration meta package Update Information: Update to master git61d9c12 ChangeLog: easy-rsa-3.0.7-1.el8 (FEDORA-EPEL-2020-6206ecd60f) Simple shell based CA utility Update Information: 3.0.7 ChangeLog: * Tue Mar 31 2020 Gwyn Ciesla - 3.0.7-1 - 3.0.7 * Tue Jan 28 2020 Fedora Release Engineering - 3.0.6-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild haxe-4.0.5-5.el8 (FEDORA-EPEL-2020-770e78b463) Multi-target universal programming language Update Information: Fix Haxe compiler (was not working at all). https://github.com/HaxeFoundation/haxe/issues/9275 ChangeLog: * Tue Mar 31 2020 Andy Li - 4.0.5-5 - Fix build command to avoid accidentially building to OCaml bytecode. - Add test that runs the Haxe compiler. - Add missing BuildRequires: ocaml-gen-devel. * Sun Mar 8 2020 Richard W.M. Jones - 4.0.5-4 - Bump and rebuild for camlp5 7.11. * Sun Mar 1 2020 Richard W.M. Jones - 4.0.5-3 - Rebuild for OCaml 4.10.0 final. * Wed Jan 29 2020 Fedora Release Engineering - 4.0.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild heimdal-7.7.0-6.el8 (FEDORA-EPEL-2020-6fac986c3d) A Kerberos 5 implementation without export restrictions Update Information: Release heimdal-7.7.0 for EPEL8. ChangeLog: libuInputPlus-0.1.4-5.el8 (FEDORA-EPEL-2020-ae4bb70b45) A C++ wrapper around libuinput Update Information: new package ChangeLog: References: [ 1 ] Bug #1808276 - Review request: libuInputPlus - C++ wrapper around libuinput https://bugzilla.redhat.com/show_bug.cgi?id=1808276 python-jaraco-classes-2.0-7.el8 (FEDORA-EPEL-2020-38f85b1cbc) Utility functions for Python class constructs Update Information: this is a dependency for python-jaraco-functools, for the ceph project ChangeLog: --
[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7
On 01. 04. 20 0:06, Miro Hrončok wrote: On 31. 03. 20 23:40, Erinn Looney-Triggs wrote: Interestingly... no it did not and the reason is I built against rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro override for epel-7-x86_64 hence why I was getting a dependency against python3-dbus. Correct. Ok so this would be a bug to file against the package then. Thanks. I'm just gonna do it rigth away. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0745794f21 -- 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: What is the proper way to handle python3 python36 in RHEL7
On 31. 03. 20 23:40, Erinn Looney-Triggs wrote: Interestingly... no it did not and the reason is I built against rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro override for epel-7-x86_64 hence why I was getting a dependency against python3-dbus. Correct. Ok so this would be a bug to file against the package then. Thanks. I'm just gonna do it rigth away. -- 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: What is the proper way to handle python3 python36 in RHEL7
On 3/31/20 3:23 PM, Miro Hrončok wrote:
%{python3} = python3
%{python3} = /usr/bin/python3
At least in Fedora. In EPEL, most likely as well.
See https://bugzilla.redhat.com/show_bug.cgi?id=1812665
There's a bug in the macros.
But that bug has nothing to do with either %python3 or
%python3_pkgversion.
Requires: %{python3}
Requires: %{python3}-dbus
What does this supposed to evaluate to?
Yeah my apologies I left out the most important part of the spec file:
%global python3 python%{python3_pkgversion}
%global python3_other python%{python3_other_pkgversion}
Anyway, the inconsistency problem is:
python36-dbus on EPEL 7 does not provide python3-dbus (can be fixed by
adding %python_provide %{name} to the EPEL package)
Ok so this would be a bug to file against the package then. Thanks.
python3-dbus in RHEL 8 does not provide python36-dbus (can be fixed by
changing RHEL's %python_provide and rebuilding the RHEL package, not
sure if that will go trough)
Understandably.
I am looking into python3_pkgversion macro but that doesn't seem to
be correct either.
This should work on both EPEL 7 and EPEL 8:
Requires: python%{python3_pkgversion}-dbus
Doesn't it?
$ mock -r epel-7-x86_64 shell
sh-4.2# rpm --eval '%python3_pkgversion'
36
$ mock -r epel-8-x86_64 shell
sh-4.4# rpm --eval '%python3_pkgversion'
3
Interestingly... no it did not and the reason is I built against
rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro
override for epel-7-x86_64 hence why I was getting a dependency against
python3-dbus.
I finally ended up doing this for the moment, which I do not like very
much and I will probably fix here shortly:
%if 0%{?rhel} == 7
Requires: python36-dbus
%else
Requires: %{python3}-dbus
%endif
Thanks all for all the good information, it is appreciated.
-Erinn
___
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: What is the proper way to handle python3 python36 in RHEL7
%{python3} = python3
%{python3} = /usr/bin/python3
At least in Fedora. In EPEL, most likely as well.
See https://bugzilla.redhat.com/show_bug.cgi?id=1812665
There's a bug in the macros.
But that bug has nothing to do with either %python3 or %python3_pkgversion.
Requires: %{python3}
Requires: %{python3}-dbus
What does this supposed to evaluate to?
Anyway, the inconsistency problem is:
python36-dbus on EPEL 7 does not provide python3-dbus (can be fixed by adding
%python_provide %{name} to the EPEL package)
python3-dbus in RHEL 8 does not provide python36-dbus (can be fixed by changing
RHEL's %python_provide and rebuilding the RHEL package, not sure if that will go
trough)
I am looking into python3_pkgversion macro but that doesn't seem to be correct
either.
This should work on both EPEL 7 and EPEL 8:
Requires: python%{python3_pkgversion}-dbus
Doesn't it?
$ mock -r epel-7-x86_64 shell
sh-4.2# rpm --eval '%python3_pkgversion'
36
$ mock -r epel-8-x86_64 shell
sh-4.4# rpm --eval '%python3_pkgversion'
3
--
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: What is the proper way to handle python3 python36 in RHEL7
The correct way in EPEL7 is to use
python%{python3_pkgversion}
%{python3} = python3
python%{python3_pkgversion} = python36
python%{python3_other_pkgversion} = python34 ?? (I think, maybe python38)
On Tue, Mar 31, 2020 at 11:47 AM Erinn Looney-Triggs
wrote:
>
> Thanks for the quick reply. Disappointing, but it happens.
> ___
> 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: What is the proper way to handle python3 python36 in RHEL7
Thanks for the quick reply. Disappointing, but it happens. ___ 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: What is the proper way to handle python3 python36 in RHEL7
On Tue, Mar 31, 2020 at 12:51 PM Erinn Looney-Triggs
wrote:
>
> I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL
> (for RHEL 7) package python36-dbus the requires section goes like so:
> Requires: %{python3}
> Requires: %{python3}-dbus
>
> This puts in a requirement for python3-dbus for RHEL 7 which doesn't exist,
> the package is actually python36-dbus, however short of a conditional saying
> if rhel 7 then package name is python36-dbus is there a clean and scalable
> way to make sure the package version is correct?
>
> I am looking into python3_pkgversion macro but that doesn't seem to be
> correct either. Does anyone know how I should do this now with a single spec
> file for both RHEL 7 and 8 that doesn't contain a conditional expression?
See https://bugzilla.redhat.com/show_bug.cgi?id=1812665
There's a bug in the macros.
___
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] What is the proper way to handle python3 python36 in RHEL7
I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL
(for RHEL 7) package python36-dbus the requires section goes like so:
Requires: %{python3}
Requires: %{python3}-dbus
This puts in a requirement for python3-dbus for RHEL 7 which doesn't exist, the
package is actually python36-dbus, however short of a conditional saying if
rhel 7 then package name is python36-dbus is there a clean and scalable way to
make sure the package version is correct?
I am looking into python3_pkgversion macro but that doesn't seem to be correct
either. Does anyone know how I should do this now with a single spec file for
both RHEL 7 and 8 that doesn't contain a conditional expression?
Thanks,
-Erinn
___
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: RHEL8 package list
On Tue, Mar 31, 2020 at 7:55 AM Kevin Fenzi wrote: > > On Tue, Mar 31, 2020 at 06:49:45AM -, Mattia Verga wrote: > > > On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi > To be clear, I didn't write this, Troy did. ;) > > > > > > > Please file a bug in bugzilla, requesting both of these to be added to > > > EPEL8. > > > It's possible that we might need to use the older version from Fedora > > > 30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4) > > > > > > Troy > > Yes, currently there are old versions of both in epel8-playground (those > > you built some time ago)... I only wanted to check if there was the > > possibility to upgrade them to the latest version, but util-linux is still > > too old to support them. > > > > Mattia > > kevin I can now elaborate a little bit more. A few weeks ago I tried to update kpmcore and kde-partitionmanager in my preparation for the qt5/kde update that is coming with RHEL 8.2. But with no luck. Even when I forced the rpm build to try to use the older util-linux, things didn't build properly. So, in summary, I will try to get pdmcore and kde-partitionmanager into regular EPEL8, and not just playground. During the upcoming qt5/kde/plasma update that is going to happen with RHEL 8.2, those two packages will not be updated. The testing I have done (not extensive) shows that, although older, they still work. 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: RHEL8 package list
On Tue, Mar 31, 2020 at 06:49:45AM -, Mattia Verga wrote: > > On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi > > > Please file a bug in bugzilla, requesting both of these to be added to > > EPEL8. > > It's possible that we might need to use the older version from Fedora > > 30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4) > > > > Troy > Yes, currently there are old versions of both in epel8-playground (those you > built some time ago)... I only wanted to check if there was the possibility > to upgrade them to the latest version, but util-linux is still too old to > support them. > > Mattia kevin signature.asc Description: PGP signature ___ 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: RHEL8 package list
> On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi > Please file a bug in bugzilla, requesting both of these to be added to EPEL8. > It's possible that we might need to use the older version from Fedora > 30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4) > > Troy Yes, currently there are old versions of both in epel8-playground (those you built some time ago)... I only wanted to check if there was the possibility to upgrade them to the latest version, but util-linux is still too old to support them. Mattia ___ 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
