Review request: https://bugzilla.redhat.com/show_bug.cgi?id=1519346
Notable difference here: the specfile can be used to produce this
python37 flat package or "normal" python3, python3-libs, python3-tools
etc. packages. Once we will update python3 to 3.7 in Fedora, we should
be able to use this without much changes (change name, summary, flip a
On 28.11.2017 07:20, Sumantro Mukherjee wrote:
> Hey Miro,
> Like discussed I would like to propose a test day
> for the changeset and test python3 in general.
> It will be awesome to have a date fixed from your end and
> I can go ahead , setup the rest of Test Day Resources.
> Going forward the idea is to have atleast one python testday each
Not sure if test days are supposed to be performed on changes already
released in stable Fedoras, but if so, why not. I have no idea what this
actually requires from my/our side, but I'd be happy to help given
specific enough instructions.
One Python testday per cycle sounds great!
I'd recommend not to communicate with me alone, but to use the
python-devel mailing list (CC'ed) instead, where plenty of other
Pythonistas will be happy to help as well.
If anyone has built the development version of CPython on Fedora in
recent weeks you've likely received the following message:
The necessary bits to build these optional modules were not found:
This is a consequence of the new uuid accelerator module introduced in
https://bugs.python.org/issue11063, which means there's a new optional
build dependency in 3.7 that "sudo dnf builddep python3" won't pick up
The first way that this can fail is simply because the new build
dependency is missing:
$ ./configure | grep uuid
checking for uuid_generate_time_safe... no
The fix for that is to install libuuid-devel:
$ sudo dnf install libuuid-devel
$ ./configure | grep uuid
checking for uuid_generate_time_safe... yes
However, there was also a bug in the build time check for the
existence of `uuid.h` and I've only just submitted the PR to fix that:
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Some of you may have noticed RPMs called `platform-python-foo` on your
Fedora 27, and even others may have noticed that these have recently
been removed from rawhide. This is expected, read on if you'd like to
The `platform-python-*` RPMs are part of a F27 [Fedora Change] called
the Platform Python Stack. This change was aimed primarily to support
the F27 Modular Server release, specifically to create a completely
separate Python stack that would be parallelly installable with Python
from the `python3` module. This Platform-Python stack was needed to run
DNF that lived in the Platform module, so that Fedora would continue
working even when no modules were installed. The change was also
deployed to mainline Fedora so that DNF would not behave differently on
the two platforms.
In the end, however, the change was not successful. To make the
Platform-Python stack completely separate, its files had to be forced to
non-standard locations which, among other things, created enormous
problems when trying to build C extensions for it. On top of this,
Platform turned out to house many more Python tools and building all the
Python dependencies for them was just too costly in this manner. F27
Modular Server therefore ended up shipping the normal Python 3 stack in
the Platform module, and `platform-python-*` packages were made obsolete
in rawhide. Though they are not actually used for anything, the packages
shall remain in F27 as it would be risky (and probably impossible) to
remove them from a live release.
[Fedora Change] https://fedoraproject.org/wiki/Changes/Platform_Python_Stack
The need for a Python stack in the Platform is still there, however, and
thus we'll need to revise Platform-Python for F28. Currently we're
trying to make the Platform-Python and the modular Python stacks share
one internal implementation behind the scenes, eliminating the need for
a costly new independent stack that has to be maintained separately and
in non-standard paths. We'd like to post our current plan to
python-devel ML soon.
All the best,
I've recently noticed that in some of the python packages I maintain,
there are now additionally byte-compiled files that appear to be from
[swt2c@rawhide-test ~][PROD]$ rpm -ql python3-pytest-xdist | grep PYTEST
It seems that these files must be generated when running the tests for the
package. I have a hunch they might be problematic, though, because they
contain the buildroot's path in them:
[swt2c@rawhide-test ~][PROD]$ strings
| grep builddir
What are these special PYTEST byte compiled files? Should they be
packaged in the first place? And if so, how can I avoid having the
build root path hard-coded in them?
So - is it possible to build rpms with flit?
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
I want to sponsor Aivar Annamaa . I would like him to review some
packages first. Are you working on something? Anyone who will need a
package review, please ping us (Aivar is CC'ed and also subscribed to
this list). Python packages would be appreciated, but anything at least
a bit related would do.