Should python3dist(...) provides generator fail when the version is =
0?
by Miro Hrončok
Hello Pythonistas,
today, I've looked up packages in rawhide providing python3dist(...) = 0 and I
opened bugzillas for them:
https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0
While version 0 (or equal versions like 0.0 or 0.0.0) is probably technically
valid, it most certainly indicates a packaging error (most likely but not
necessarily a downstream packaging error).
Should we prevent this error from happening by explicitly erroring (and failing
the build) when it happens? I think it would make the dependency generators
more robust.
In an unlikely scenario when packagers actually want to package version 0, they
can reach out and we can allow it via some configuration (but [YAGNI], so I
don't want to clutter the generator with yet another option right away).
[YAGNI] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 3 months
MinGW & building wheels
by Scott Talbert
Hi all,
Does anyone have any experience with using Fedora's MinGW stack to
cross-compile Python wheels for Windows?
Scott
1 year, 4 months
Undoing my screw-up with python-async-timeout
by Paul Wouters
Hi,
I screwed up python-async-timeout in Fedora 34 by pushing it from 3.x to 4.x.
I should not have bumped the major without significant more testing and
talking to people. I rushed it through and caused lots of breakage.
So first, I really do want to apologise for the mess I caused. And I'll
make sure it won't happen again. I will do some community service by
doing a bunch of outstanding package reviews we currently have open.
The biggest issues is breaking python-aiohttp. I've spend some time in
looking at bumping python-aiohttp to 3.8.x to match it up with
python-async-timeout 4, but both the python-aiohttp test cases fail as
well as my own $dayjob code using it.
There are a four more (known) packages that fail based on the API change
that could probably be fixed, but there would also be other python code
outside fedora that might fail on the API change. And since my attempted
use of the newer version of python-aiohttp in fedora 34 is also causing
issues, I think the safer choice is to roll back python-async-timeout
from 4.x to 3.x using Epoch.
An alternative could be to fixup python-aiohttp 3.7.x to work with
async-timout 4.x, but that still involves two API changes inflicted on
others as well:
- Support timeout.deadline
- Port timeout.timeout property that returns a relative timeout
based on the timeout object creation time to the absolute
timeout.deadline instead.
Although possibly a wrapper patch could be written to handle this to
give 3.x API compatibility back. But it would still require package
requirements that require < 4 to be respun to allow version 4.
Another alternative is to investigate why python-aiohttp 3.8.x %check
fails on wait_from() et all in f34/f35 but not in rawhide and port what
is needed there back to f35/f34. I looked at this briefly, and it is not
clear to me what is failing, and I would need help to look into this.
I do think undoing python-async-timeout with an Epoch is ugly but the
best path forward. I think due to the pythondist specific requires, we
would not need to carry the epoch into f35 or rawhide to preserve EVR?
I am looking for some guidance to ensure I don't break things even more
and I apologise for the extra work that I have and am causing everyone.
Paul
1 year, 4 months
Proposal: Make -r (include runtime deps) the default for
%pyproject_buildrequires
by Miro Hrončok
Hello Pythonistas.
When we invented the %pyproject_buildrequires BuildRequires generator, it
generated build-dependencies. Imediatelly we realized that for several reasons,
also generating the runtime dependencies as BuildRequires is needed:
- they are needed to run the test suite
- they are needed to run an import check
- they make the build fail when runtime dependencies are not found
Hence, %pyproject_buildrequires -r was introduced. This flag is implied by
other flags (-x, -t, -e) but it is not a default behavior.
However, as I've done a fair amount of new package reviews and pull request
reviews to convert packages to pyproject-rpm-macros, I've noticed packagers
have a tendency to forgot the -r flag when:
1) The currently packaged version has no runtime dependencies.
This is currently quite harmless, as when the package is updated with new
dependencies, the packager will notice and add the flag. However, if we ever
have some automation for updates, we better have forward-compatible specfiles.
2) The runtime dependencies are pulled in as transitive dependencies of
manually BuildRequired packages.
For example, if there is `BuildRequires: python3-pytest` and the package
runtime-requires toml, the tests will suceed with pytest 6 (requires toml) but
will error with pytest 7 (as it migrated from toml to tomli).
3) There is not a single check run in %check.
While technically forbidden by the new guidelines, this is not enforced and
hence packages use %pyproject_buildrequires but don't run any tests. This can
result in packages that are updated into an uninstallbale state. I'd rather the
build failed in that case.
Hence, I propose we make the -r flag the default. In case some package needs to
opt-out for legitimate reasons, a new flag would exist to disable it (most
likely -R).
While technically a backwards-incompatible change, I belive the negative impact
should be minimal -- at worst packages that fail to install will now also fail
to build (which is a good thing IMHO).
Thoughts?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 4 months
Re: [Python-Dev] [PSA] OpenSSL 3.0 support is preliminary and
experimental
by Miro Hrončok
On 09. 01. 22 19:39, Christian Heimes wrote:
> Hi,
>
> I would like to remind everybody that Python's support for OpenSSL 3.0 is
> preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda
> works. However there are known performance regressions, missing features (e.g.
> usedforsecurity flag), and potential bugs cause by API incompatibilities.
>
> Due to the experimental state I advise against using Python with OpenSSL 3.0 in
> production.
>
> It may take a while until Python gains full support for the next version of
> OpenSSL. I have shifted my personal OSS time to more fun topics like
> performance and WASM. My work time is currently limited, too.
Hello Christian.
Do you think we should switch Python in Fedora 36 to OpenSSL 1.1.1? Python was
naturally rebuilt with OpenSSL 3.0 when the distro upgraded OpenSSL. But the
older version is still available.
Note that Fedora 36 is also "preliminary" so we still have time to make this
decision until +- the beta freeze/release (end of February, early March this year).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 4 months
PyPy3.8 now available
by Miro Hrončok
Hello Pythonistas.
PyPy3.8 is now available in Fedora.
On rawhide, when you dnf install pypy3, or when you run the pypy3 command, you
will get PyPy3.8. PyPy3.7 is still available for the time being (pypy3.7
package and command).
On Fedora 35, when you dnf install pypy3, or when you run the pypy3 command,
you will still get PyPy3.7. pypy3.8 package will be available from updates
testing when the build finishes and I'll create the bodhi update.
On Fedora 34, when you dnf install pypy3, or when you run the pypy3 command,
you will still get PyPy3.6. pypy3.8 package will be available in updates
testing soon: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8e29bfb393
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 5 months
Fwd: Python SIG at Fedora Council Video Meeting
by Miro Hrončok
Hello, does anybody want to take this? If not, I will.
-------- Forwarded Message --------
Subject: Python SIG at Fedora Council Video Meeting
Date: Thu, 6 Jan 2022 16:06:17 -0500
From: Tom Callaway <spotrh(a)gmail.com>
To: Miro Hrončok <mhroncok(a)redhat.com>
Miro, I know you're in the Python SIG, please forward this on as needed.
The Fedora Council would like to invite your SIG to present at an upcoming
Fedora Council video meeting. If you're interested, what we'd be looking for
from you is:
* Someone to present (on camera in a virtual meeting room) a 10-15 minute
presentation (with slides) on the state of your SIG (past, present, future)
along with any calls to action that you might have.
* Stick around for 15+ minutes for Q&A discussion
These meetings are recorded and then shared on
youtube:https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow
<https://www.youtube.com/channel/UCnIfca4LPFVn8-FjpPVc1ow>
A small FAQ:
Q. When are these meetings held?
A. The video meetings are held monthly, on a Thursday, between 1800 - 1900 UTC.
Q. Do we have to do this?
A. No. It is an opportunity we're making available to you, but if you don't
want to (or cannot), feel free to decline (or ignore this email).
Q. Would the meeting be all about our SIG?
A. We also use some time to discuss council business, but you'd be the guest(s)
of honor.
Q. Okay, we're in. How do I sign-up?
A. You reply to this email and say "Our SIG would love to do this!" and I'll
get you scheduled.
Q. I have other questions, who can I ask?
A. You can ask me! You now have my email, or you can find me any of the other
obvious places I have presence on the internet and ask me there.
Thanks,
Tom "spot" Callaway, on behalf of the Fedora Council
1 year, 5 months
