[HEADS UP]: libtommath major version pre-release testing
by Denis Fateyev
Greetings,
We are preparing a major update for 'libtommath' library [1]. The last
stable release happened more than 5 years ago, so there are a lot of
changes and improvements over the time.
Although there are still some open requests in upstream, the current
library state looks pretty stable to me. Along with multiple enhancements
the core contributors removed a lot of deprecated stuff from the code, and
we cleaned up makefiles and the Fedora package spec to bring more logic in
there.
All 'libtommath' shared library and bundled version users are encouraged to
test their code and/or packages against the current development version of
the library.
There is a Copr repo with packages for the development version [2].
Any feedback and suggestions are very welcome.
Known issues:
---------------------
1) Build permanently fails for epel7 ppc64le. It's a bug in 'ghostscript'
[3], and there was even a workaround in epel7 branch [4];
2) Build appeared to be failing in rawhide, I suspect there is broken
'texlive'.
Both problems can be avoided with excluding pdf docs from the package, and
I do hope that 'texlive' will be fixed in rawhide soon (I haven't checked
the problem in details though).
[1] https://github.com/libtom/libtommath
[2] https://copr.fedorainfracloud.org/coprs/dfateyev/libtommath/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1243784
[4]
http://pkgs.fedoraproject.org/cgit/rpms/libtommath.git/commit/?h=epel7&id...
Thanks,
--
wbr, Denis.
7 years, 10 months
Additional python34 components for epel7
by Denis Fateyev
Hello there,
To package some python3-based stuff I need 'msgpack', 'llfuse', 'Cython'
modules built for Python 3.4 which is the current version of Python 3 in
epel7.
Would it be reasonable to file a bug against 'python-msgpack', et al. in
epel7 to adapt the package spec and get 'python34-msgpack' etc. packages,
or there are any objections against that?
Thanks,
--
wbr, Denis.
7 years, 10 months
python-rpm-macros - splitting out the macros
by Orion Poplawski
On 01/08/2016 11:27 AM, bugzilla(a)redhat.com wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1294904
>
> Antonio Trande <anto.trande(a)gmail.com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Flags|fedora-review? |fedora-review+
>
>
>
> --- Comment #12 from Antonio Trande <anto.trande(a)gmail.com> ---
> Package approved.
>
I still have heard nothing from the main python maintainers, and I'd like to
get some kind of an ack for the following plan:
- Dropping the python3-pkgversion-macros package, replaced with
python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
and epel-rpm-macros (in EPEL).
- Dropping the python-macros sub-package from python, replace by Requires:
python-rpm-macros from above package. python3 requires this as well.
- Dropping macros.python2 from python-devel, replaced with Requires:
python2-rpm-macros from above package.
- Dropping macros.python3 from python3-devel, replaced with Requires:
python3-rpm-macros from above package.
This achieves the goal of decoupling modifying/updating the python macros from
updating the main python package, which has become a serious hindrance to
developing new python rpm macros.
The reviewed package contains the Fedora macros. macros will be changed on
the EPEL branches.
I've requested a side tag to do the build in here -
https://fedorahosted.org/rel-eng/ticket/6331
as I think the timing is tricky and the possibility of breaking the buildroot
moderate.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
7 years, 10 months
[PLEASE TEST] Update python-cffi in F23
by Nathaniel McCallum
I submitted an update in F23 to python-cffi 1.4.2. [1]
I do not anticipate any issues. However, because so many packages
depend on python-cffi, I would like some intentional testing before I
push the update.
PLEASE TEST YOUR PACKAGE WITH THIS UPDATE
For more information on the reasons behind the update, see the bugs
attached to the update. Thanks!
[1] - https://bodhi.fedoraproject.org/updates/python-cffi-1.4.2-1.fc23
7 years, 11 months
Which python3 versions to package for EPEL7?
by Orion Poplawski
So, I've started packaging up a bunch of python3 only packages for EPEL7
for packages that were already in RHEL7. I've started by packaging the
latest version of the modules:
python34-py.noarch 1.4.30-2.el7 epel-testing
python34-setuptools.noarch 19.2-3.el7 epel-testing
But these are much newer than the python2 versions:
python-py.noarch 1.4.27-1.el7
python-setuptools.noarch 0.9.8-4.el7
I'm afraid I was motivated by the possibilities of supporting newer
python3 code, but Matthias RUnge makes the valid point that this may
cause confusion and other problems[1].
What's the consensus here?
1 - https://bugzilla.redhat.com/show_bug.cgi?id=1294865#c3
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
7 years, 11 months
python-macros review
by Orion Poplawski
I've submitted a review for a separate python-macros package here:
https://bugzilla.redhat.com/show_bug.cgi?id=1294904
This is what the FPC approved here
https://fedorahosted.org/fpc/ticket/567#comment:12 to be added to the Fedora
buildroots to provide the %python3_pkgversion macro needed for compatibility
with the EPEL Python3 packaging guidelines.
It also serves the much more important goal of getting the python macros out
of the the individual python? packages to make it easier to update them.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
7 years, 11 months
