Re: Pagure for EL8 (EPEL8)
by Neal Gompa
On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > I've done an early build locally to determine what's needed to make
> > this possible. The following report from DNF indicates the missing
> > packages that need to be added to EPEL 8 before I can introduce Pagure
> > into EPEL8:
> >
> > Problem 1: conflicting requests
> > - nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch
> > Problem 2: conflicting requests
> > - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(binaryornot) needed by
> > pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(flask-wtf) needed by pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(straight.plugin) needed by
> > pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(wtforms) needed by pagure-5.8-1.el8.noarch
> > - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
> > pagure-5.8-1.el8.noarch
> > Problem 3: conflicting requests
> > - nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch
> >
> > One of the reasons I'd like to have this done sooner rather than later
> > is so that we can drop Python 2 support from Pagure with version 6.0.
> > I think it's quite reasonable to say that version 6.0 isn't going to
> > happen until we can get our Pagure servers running on EL8 using Python
> > 3.
> >
> > So now, I need some help making this happen. I already own trololio,
> > and I'm going to make that available in EPEL 8 ASAP. Can anyone help
> > with some of the other dependencies here?
>
> Can you give a list with maintainers? I'm not sure off hand how many of
> those are maintained by me/infra-sig, but any I can I would be happy to
> add in. There's a few that are in testing I think already...
>
Sure, here's a list so far (package: maintainer):
* gitolite3: limb
* python-jenkins: cottsay
* python-binaryornot: pingou
* python-celery: bowlofeggs
* python-flask-wtf: pingou
* python-redis: kevin
* python-straight-plugin: pingou
* python-wtforms: kumarpraveen
* python-pygit2: pwalter
* python-trololio: ngompa
I've already got trololio going:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd
--
真実はいつも一つ!/ Always, there's only one truth!
3 years, 6 months
Pagure for EL8 (EPEL8)
by Neal Gompa
Hey all,
In the interest of helping to modernize the infrastructure Fedora runs
on, I'm working on introducing Pagure into EPEL8. This will hopefully
allow us to upgrade our Pagure instances to use RHEL 8 instead of RHEL
7, and notably, make the transition (mostly) complete for moving all
Python software Fedora runs to Python 3.
I've done an early build locally to determine what's needed to make
this possible. The following report from DNF indicates the missing
packages that need to be added to EPEL 8 before I can introduce Pagure
into EPEL8:
Problem 1: conflicting requests
- nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch
Problem 2: conflicting requests
- nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(binaryornot) needed by
pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(flask-wtf) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(straight.plugin) needed by
pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(wtforms) needed by pagure-5.8-1.el8.noarch
- nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
pagure-5.8-1.el8.noarch
Problem 3: conflicting requests
- nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch
One of the reasons I'd like to have this done sooner rather than later
is so that we can drop Python 2 support from Pagure with version 6.0.
I think it's quite reasonable to say that version 6.0 isn't going to
happen until we can get our Pagure servers running on EL8 using Python
3.
So now, I need some help making this happen. I already own trololio,
and I'm going to make that available in EPEL 8 ASAP. Can anyone help
with some of the other dependencies here?
Thanks in advance,
Neal
--
真実はいつも一つ!/ Always, there's only one truth!
3 years, 10 months
Re: Python bindings for protobuf on RHEL/CentOS/EPEL 8
by Petr Viktorin
On 2019-11-14 16:13, Denis Arnaud wrote:
>
>
> Thanks Petr for your answer!
>
> Let's give the COPR short-term solution a try, then :)
>
> What is frustrating is that we cannot get our hands on the package
> source for Protobuf for RHEL/CentOS, and we cannot therefore know who
> maintains it at RedHat.
The maintainer is (usually, effectively) also the Bugzilla assignee.
> For Boost for instance, which is also a RedHat
> core package, I know the RedHat maintainer (Jon Wakely) and can
> co-maintain Boost with him and have an influence on (non-EPEL)
> RHEL/CentOS Boost.
In my personal opinion, that's the way it should be; it benefits both
Red Hat and the community.
> At least, we get visibility on when, why and how
> Boost is rebuilt on RHEL/CentOS. It would be nice to achieve the same
> with Protobuf. But I have no clue on how to identify who at RedHat is
> (are) the main maintainer(s) of Protobuf. I am sure they would be
> interested if I/we can build protobuf with Python bindings for
> RHEL/CentOS 8 (at least on EPEL).
> And it seems strange to me that RHEL/CentOS misses Python bindings for
> Protobuf (which is the cornerstone to many frameworks (e.g., gRPC)). I
> wonder how many applications work at all. Or maybe those Python bindings
> are build-time only in the new modularization framework?
> It would help to have a way, for Fedora/EPEL volunteers, to be able to
> reach out to RedHat core package maintainers, at least for
> cross-awareness, knowledge sharing and potential collaboration.
>
> Kind regards
>
> Denis
>
>
> 14 Nov. 2019 15:27, Petr Viktorin <pviktori(a)redhat.com
> <mailto:pviktori@redhat.com>> wrote:
>
> On 2019-11-11 11:45, Denis Arnaud wrote:
> > Hi,
> >
> > the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for
> the
> > protobuf package (https://src.fedoraproject.org/rpms/protobuf).
> > A bug request has been created on Bugzilla
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as
> no status
> > has been given, I was wondering whether someone could shed
> some light on
> > the context.
> >
> > Since protobuf is a RedHat core package (maintained by RedHat
> and
> > therefore not managed by Fedora/EPEL), it appears as a kind
> of black box
> > from Fedora perspective. On Fedora (Rawhide, 31), the Python (3)
> > bindings are generated/packaged (see for instance
> >
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3a662fe8b and
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=19440119),
> but for
> > some reason, those Python bindings are not generated by
> RedHat for
> > RHEL/CentOS 8.
> >
> > 1. Would anyone from RedHat be able to provide some heads up
> on why
> > those Python 3 bindings are missing for Protobuf, and/or an
> approximate
> > timeline for when it would be generated?
>
> Hi!
> We just talked about this among Red Hat python-maint. (Sorry for
> the
> delay!) We don't have influence over this package; unfortunately we
> can't help directly.
>
> > 2. Would RedHat need help with packaging protobuf on
> RHEL/CentOS/EPEL 8?
>
> At this level "Red Hat" is not a single entity. You're probably not
> reaching the right people on this list.
> If the packager isn't active in Fedora or on Bugzilla, then
> unfortunately, the way to get them to respond is to file a customer
> support ticket.
> Another way to approach this is change EPEL rules somehow to
> make it
> possible to build subpackages like this. From what I understand,
> it's
> being discussed, but it'll take time to get sorted out.
>
> > 3. Would you recommend another way for Fedora packagers/users
> to get
> > their hands on the python3-protobuf/protobuf-python3 package?
> For
> > instance, through COPR, or some module we may have missed.
>
> Building a replacement protobuf package in COPR is the best
> short-term
> solution.
>
> Sorry I couldn't be more helpful.
>
3 years, 10 months
Python bindings for protobuf on RHEL/CentOS/EPEL 8
by Denis Arnaud
Hi,
the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the protobuf package (https://src.fedoraproject.org/rpms/protobuf).
A bug request has been created on Bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as no status has been given, I was wondering whether someone could shed some light on the context.
Since protobuf is a RedHat core package (maintained by RedHat and therefore not managed by Fedora/EPEL), it appears as a kind of black box from Fedora perspective. On Fedora (Rawhide, 31), the Python (3) bindings are generated/packaged (see for instance https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3a662fe8b and https://koji.fedoraproject.org/koji/rpminfo?rpmID=19440119), but for some reason, those Python bindings are not generated by RedHat for RHEL/CentOS 8.
1. Would anyone from RedHat be able to provide some heads up on why those Python 3 bindings are missing for Protobuf, and/or an approximate timeline for when it would be generated?
2. Would RedHat need help with packaging protobuf on RHEL/CentOS/EPEL 8?
3. Would you recommend another way for Fedora packagers/users to get their hands on the python3-protobuf/protobuf-python3 package? For instance, through COPR, or some module we may have missed.
Kind regards
Denis
3 years, 10 months
Python Annual Release Cycle adjusted to match odd-numbered Fedora
releases
by Miro Hrončok
Hello,
I'd like to inform you that [PEP 602] "Annual Release Cycle for Python" has been
approved and [PEP 596] "Python 3.9 Release Schedule" is pending approval:
tl;dr New Python 3.X versions will be released annually, with RC period adjusted
to make it possible to update Python in odd-numbered Fedora releases. We plan to
submit the Python 3.9 change proposal for Fedora 33 after the first Python 3.9
alpha (expected in ~2 weeks).
The Python 3.8 update was postponed from Fedora 31 to Fedora 32 because the
schedule was too tight. With 3.9 and the recent adjustments, we expect that
Fedora 33 is a reasonable target release, but we are prepared to reevaluate that
after branching.
Like with 3.8, we plan to rebuild Fedora packages with Python 3.9 pre-releases,
file bugs, and coordinate fixes both to Python and the software that uses it. We
hope to make that process smoother, but even more effective at finding and
resolving incompatibilities. With the shorter cycle, we anticipate less
incompatibilities.
Quotes from PEP 602:
(Rationale and Goals)
"This change provides the following advantages: ... allows for synchronizing the
schedule of Python release management with external distributors like Fedora
who've been historically very helpful in finding regressions early not only in
core Python but also in third-party libraries, helping moving the community
forward to support the latest version of Python from Day 1"
(Rejected Ideas)
"While [keeping 4 betas over 4 months and a final month for the release
candidate] would make the release calendar a bit cleaner, it would make it very
hard for external distributors like Fedora to release the newest version of
Python as soon as possible. We are adjusting Python's calendar here in the hope
that this will enable Fedora to integrate the newest version of Python with the
newest version of Fedora as both are being developed which makes both projects
better."
Quotes from the [python-dev] mailing list:
"...in order to give the community enough time to provide feedback in the betas
while having enough time to thoroughly test the RC and to prep for the final
release so the delay from Python's final release to any new project releases is
minimal. It should also fit into the release schedule of Linux distributions
like Fedora better than previously proposed so the distributions can test the RC
when they start preparing for their own October releases."
-- Brett Cannon, Python Steering Council member
"[2 months for RCs instead of 1] allows for synchronizing the schedule of Python
release management with Fedora. They've been historically very helpful in early
finding regressions not only in core Python but also in third-party libraries,
helping moving the community forward. It seems like a bargain to make a slight
adjustment of our schedule to help Fedora help us make 3.9 and beyond better
releases."
-- Łukasz Langa, Python 3.8 and 3.9 Release Manager
[PEP 596] https://www.python.org/dev/peps/pep-0596/
[PEP 602] https://www.python.org/dev/peps/pep-0602/
[python-dev]
https://mail.python.org/archives/list/python-dev@python.org/thread/KE7OS4...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 10 months
Building the python executable statically with libpython*.a for
better performance
by Miro Hrončok
Hello,
we've been recently approached by a colleague from Red Hat working on
performance (CCed).
According to their testing, Fedora Python performance could be improved by ~15%
by building /usr/bin/python* statically with libpython*.a. That sounds like a
worthy thing to do.
https://bugzilla.redhat.com/show_bug.cgi?id=1749479
Since Python 3.8 Python extension modules are no longer linked to libpython.so
and we can do the following:
* build /usr/bin/python3(.8) statically with libpython*.a
* build and ship libpython3.8.so.1.0 for packages that "embed" Python
The change in the python3 package is trivial:
https://src.fedoraproject.org/rpms/python3/pull-request/133
However it can have serious impact on Python extension modules that are linked
to libpython3.8.so.1.0 by various "nonstandard" build mechanisms or by compiling
code for Python extension module and code that embeds Python into one file.
We will likely propose a Fedora 32 Change for this, however I'm opening this
topic for discussion before we do so.
Testing the proposed Pull Request with your code is also helpful. Let me know
how can we make that easier (e.g. if you want a Copr or a Fedora 30/31 python38
package with this change).
WDYT?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 10 months