[HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
by Tomas Hrnciar
Hello,
in order to deliver Python 3.12, we are running a coordinated rebuild in a
side tag.
https://fedoraproject.org/wiki/Changes/Python3.12
We anticipate starting this rebuild sometime this week.
If you see a "Rebuilt for Python 3.12" (or similar) commit in your package,
please don't rebuild it in regular rawhide or another rawhide side tag. If
you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be
able to build it in the side tag via:
on branch rawhide:
$ fedpkg build --target=f39-python
$ koji wait-repo f39-python --build <nvr>
Note that it will take a while before all the essential packages are
rebuilt, so don't expect all your dependencies to be available right
away. Please,
don't attempt to build your package in the side tag before we do.
When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping
me (thrnciar) or Miro (mhroncok) if you need to talk to us.
Builds:
https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&orde...
Please avoid any potentially disturbing or major changes in Python packages
until the rebuild is over.
Thanks. Let us know if you have any questions.
9 months, 2 weeks
Circular import issue in F37
by Sandro
Hi again,
I'm trying to understand why I'm getting a circular import error running
tests only in F37 [1].
It's an easy fix adding an empty __init__.py in %prep, but why are F38
and rawhide buildroots happy not having that file, while F37 complaints?
The versions of the involved packages only differ in minor / patch
versions between F37 and F38, if at all. With python-setuptools-wheel
being the only package with a different major version.
python3-devel 3.11.3-2.fc37 3.11.3-2.fc38
python3-pytest 7.1.3-2.fc37 7.2.2-1.fc38
pyproject-rpm-macros 1.8.0-1.fc37 1.8.0-1.fc38
python-rpm-macros 3.11-5.fc37 3.11-10.fc38
python-pip-wheel 22.2.2-3.fc37 22.3.1-2.fc38
python-setuptools-wheel 62.6.0-3.fc37 65.5.1-2.fc38
[1] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6002232/
Cheers,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
9 months, 3 weeks
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag
this week
by Miro Hrončok
On 18. 06. 23 15:17, Barry Scott wrote:
>
>
>> On 17 Jun 2023, at 10:50, Miro Hrončok <mhroncok(a)redhat.com> wrote:
>>
>> Please avoid further rawhide builds of them until the side tag is merged.
>
> I have been fixing pycxx and pysvn for python 3.12.
> I have released new pycxx and pysvn upstream that fix the 3.12 issues.
>
> But I did not see your message about not building in rawhide, sorry.
>
> python-pycxx was buildt in rawhide.
> I have not built pysvn in rawhide.
>
> For both packages I have pushed updates to sources and spec file that are needed
> for 3.12 support.
>
> For pycxx need to have conditional access to _Py_PackageContext and replace use
> of distutils.
>
> For pysvn fix a SEGV when the process exits.
>
I'v attempted to rebuild python-pycxx:
Traceback (most recent call last):
File "/builddir/build/BUILD/pycxx-7.1.8/setup.py", line 3, in <module>
from distutils.command.install import install
ModuleNotFoundError: No module named 'distutils'
The distutils module eas removed from the Python standard library.
You should be able to fix this by BuildRequiring python3-setuptools.
Cannot build pysvn yet, as it is blocked by the above.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10 months
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag
this week
by Miro Hrončok
On 16. 06. 23 12:07, Nikita Popov wrote:
> We have a conflicting python-lit build sitting in another side tag -- we'll
> discard that one and rebuild once your side tag is merged.
If it's already built and ready to be shipped, do it. Our side tag will last
for ~1 week at least. Happy to bump python-lit once again to make your side tag
work unblocked. Just let us know.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10 months
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag
this week
by Miro Hrončok
On 16. 06. 23 9:57, Bastien Nocera wrote:
>
>
> On Fri, 16 Jun 2023 at 09:48, Miro Hrončok <mhroncok(a)redhat.com
> <mailto:mhroncok@redhat.com>> wrote:
>
> On 16. 06. 23 9:41, Bastien Nocera wrote:
> > Scolding people that haven't seen your original message for limitations
> in the
> > build system isn't nice.
>
> Apologies for not being nice enough. However, we need to notify the folks who
> do that and ask them to stop, because as you say, the system is not perfect.
>
> If you have specific suggestions, please speak up.
>
>
> Yes, tell folks that they might have missed an email instead of sending a
> scolding " Please, don't do that."
Thanks for the suggestion. I honestly had no idea that "please, don't do that"
could be considered unfriendly, but I hope that's language/cultural barrier
(rather than me being a sociopath). I've adjusted my wording in the followup
emails.
> > I fixed my missing the devel-announce email by subscribing to the list
> (though
> > this should probably be implemented somewhere in the accounts system)
> but I'm
> > afraid I cannot do anything about the build system not allowing for
> specific
> > blocking of builds in circumstances such as yours.
>
> I kindly ask you not to submit rawhide builds of packages that have been
> already built in our side tag, until the side tag is merged. If you cannot do
> that, I kindly ask you not to build any packages until the side tag is merged.
> Unfortunately, asking people is the only thing I am able to do.
>
>
> I'm talking about limitations in the build system that don't allow you to
> automatically do what you're trying to get *people* to do instead.
>
> People are fallible, and filing an RFE for the build system would go some way
> to shifting the burden to a computer.
This has actually been discussed on this list several times already, but Fabio
was kind enough to file that RFE today:
https://pagure.io/koji/issue/3847
That said, most of Fedora's RFEs to Koji that would make things easier for
packagers seem to linger, presumably due to capacity reasons.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10 months
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag
this week
by Miro Hrončok
On 16. 06. 23 9:41, Bastien Nocera wrote:
> Scolding people that haven't seen your original message for limitations in the
> build system isn't nice.
Apologies for not being nice enough. However, we need to notify the folks who
do that and ask them to stop, because as you say, the system is not perfect.
If you have specific suggestions, please speak up.
> I fixed my missing the devel-announce email by subscribing to the list (though
> this should probably be implemented somewhere in the accounts system) but I'm
> afraid I cannot do anything about the build system not allowing for specific
> blocking of builds in circumstances such as yours.
I kindly ask you not to submit rawhide builds of packages that have been
already built in our side tag, until the side tag is merged. If you cannot do
that, I kindly ask you not to build any packages until the side tag is merged.
Unfortunately, asking people is the only thing I am able to do.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10 months
nest: python package still setup.py; also needs to be built for MPI
by Ankur Sinha
Hi folks,
I'm in the process of updating the nest package to the latest release.
It uses cmake as its build system, but then the cmake calls `python
setup.py install` and so on to install the Python API. So, we strip that
bit out and call these commands ourselves in the right places in the
spec[1,2,3].
As you'll also see from the spec, nest supports MPI, so we build it 3
times:
- without MPI
- once with openmpi
- once with mpich
For the MPI builds, we need to pass the `--install-lib=$MPI_SITEARCH`
option to `python setup.py install` to get it to install the bits in the
right MPI related locations.
I've noticed that using this system now gives us deprecation warnings
during the build since calling `setup.py ...` explicitly is deprecated.
However, I can't figure out how I would replicate the build using the
`pyproject` macros. I guess `pyproject_wheel` usage is straightforward
(?), but how do I get `pyproject_install` to install in the
$MPI_SITEARCH locations, and then how do I get `pyproject_save_files` to
store the files in three different lists that I can use in the different
`%files` sections?
[1]
https://src.fedoraproject.org/rpms/nest/blob/rawhide/f/0001-Disable-pytho...
[2]
https://src.fedoraproject.org/rpms/nest/blob/rawhide/f/nest.spec#_342
[3]
https://src.fedoraproject.org/rpms/nest/blob/rawhide/f/nest.spec#_424
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
10 months, 1 week
python macros inconsistency between Fedora and EPEL9
by Mattia Verga
In the test section of libindi package I use this to run tests:
%ctest --test-dir %_vpath_builddir/test
This translates in Fedora as:
+ /usr/bin/ctest --test-dir redhat-linux-build --output-on-failure --force-new-ctest-process -j6 --test-dir redhat-linux-build/test
Internal ctest changing into directory: /builddir/build/BUILD/indi-2.0.2/redhat-linux-build/test
While on EPEL (at least, in COPR):
+ /usr/bin/ctest --output-on-failure --force-new-ctest-process -j2 --test-dir redhat-linux-build/test
Internal ctest changing into directory: /builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test
Failed to change working directory to "/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test" : No such file or directory
I'm not sure against what package I should report this. Python-rpm-macros seems a Fedora package only, I don't see any epel9 build there.
And, most important, I don't know if I'm doing something wrong or if is indeed something to report.
Can anyone clarify me these two things?
Thanks
Mattia
10 months, 2 weeks
pyproject-rpm-macros 1.9.0: Support for passing config_settings to
the build backend
by Miro Hrončok
Hello Pythonistas,
Let me announce the release of pyproject-rpm-macros 1.9.0.
The new version is available in Rawhide+ELN Koji and updates are penfing for
older Fedora releases. A sync to c9s is in progress but will require a review,
so it might take longer.
The new version has the following changes compared to 1.8.0:
Allow passing config_settings to the build backend
==================================================
Contributed by Maxwell G (@gotmax23), thank you!
From the README:
-------------------------------------------------------------------------------
The %pyproject_buildrequires and %pyproject_wheel macros accept a -C flag to
pass configuration settings [1] to the build backend. Options take the form of
-C KEY, -C KEY=VALUE, or -C--option-with-dashes. Pass -C multiple times to
specify multiple options. This option is equivalent to pip's --config-settings
flag. These are passed on to PEP 517 hooks' config_settings argument as a
Python dictionary.
The %pyproject_buildrequires macro passes these options to the
get_requires_for_build_wheel and prepare_metadata_for_build_wheel hooks.
Passing -C to %pyproject_buildrequires is incompatible with -N which does not
call these hooks at all.
The %pyproject_wheel macro passes these options to the build_wheel hook.
Consult the project's upstream documentation and/or the corresponding build
backend's documentation for more information. Note that some projects don't use
config settings at all and other projects may only accept config settings for
one of the two steps.
Note that the current implementation of the macros uses pip to build wheels. On
some systems (notably on RHEL 9 with Python 3.9), pip is too old to understand
--config-settings. Using the -C option for %pyproject_wheel (or
%pyproject_buildrequires -w) is not supported there and will result to an error
like:
Usage:
/usr/bin/python3 -m pip wheel [options] <requirement specifier> ...
...
no such option: --config-settings
[1] https://peps.python.org/pep-0517/#config-settings
-------------------------------------------------------------------------------
Previously, packagers needed to patch for this:
https://src.fedoraproject.org/rpms/python-scikit-misc/c/3dda47b4b7
On Python older than 3.11, use tomli instead of deprecated toml
===============================================================
All currently supported Fedora releases have Python 3.11, so this has not a big
effect except for EL 9. However, all packages had generated this BuildRequires:
(python3dist(toml) if python3-devel < 3.11)
This will now be:
(python3dist(tomli) if python3-devel < 3.11)
Such build requirements in Fedora manifests themselves in the results of dnf
repoquery --wahtrequires python3-toml(i).
Fix literal % handling in %{pyproject_files} on RPM 4.19
========================================================
If your package has files with literal % signs in the filenames, it was briefly
broken on Fedora Rawhide, because RPM 4.19 now requires 2 % signs to escape
them in the filelist (it was 8 in RPM 4.16 and 4.17). This has now been fixed.
Unfortunately, to support both RPM 4.19 and older ones, there is a conditional
in %pyproject_save_files which checks the Fedora version. If you run old RPM on
Fedora 39 or new RPM on older Fedoras and ahve literal % signs in filenames, it
will break. I have requested an %rpmversion macro from RPM and it was added
upstream. Once propagated to Fedora, the conditional will be replaced.
Happy packaging!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10 months, 2 weeks
