Re: are pyproject rpm macros supposed to pick up the license automatically?
Karolina, Miro, thank you both for the explanation. I added that information in the review request. Felix -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
are pyproject rpm macros supposed to pick up the license automatically?
While I was reviewing python-pypdf [1] I noticed that the produced rpm
(python3-pypdf) does not contain the license file, that is "rpm -q
--licensefiles" comes up empty.
As far as I can tell the package follows the example spec file [2] which does
not feature an explicit %license tag so I guess the %pyproject macros are
supposed to pick these up automatically?
As for python-pypdf, the license file IS present in Python's dist-info
directory.
The release tarball uses pyproject.toml with the following line:
license = { file = "LICENSE" }
Am I misunderstanding something here or could this be a shortcoming in the
current macros?
Felix
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2279080
[2]
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_example_spec_file
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
Am 25.01.24 um 20:34 schrieb Miro Hrončok:
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
...
python-pydyf-0:0.8.0-1.fc40.src
...
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core
Indeed, python-pydyf and weasyprint build just fine with flit-core so I
changed that.
Felix
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: MinGW & building wheels
Am 21.01.22 um 23:12 schrieb Scott Talbert: I'm using the mingw stack to cross-compile a Windows binary which shipped as part of an otherwise platform neutral Python wheel. The main problem I had with Fedora's mingw Python was that I could not create a Windows wheel. Yep, that's the same thing I'm trying to figure out. The compiling part works fine - it's the mechanics of cross-building a wheel that don't seem as clear. I figured I needed to run the mingw Python (with wine) to get an actual Windows wheel. That part would require a virtualenv for my package. However I can avoid that problem alltogether as my wheel just needs to contain an exe file (as "data") so I can use the Linux Python 3 to create a platform-neutral wheel. I think the venv part would require some more serious patching in Fedora (and I would love to see this but unfortunately I can't spend time getting this fixed). Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
question about review process excemptions for Python 3
Hi, the packaging guidelines have a few excemptions for the package review process [1]. I'm working on updating certbot to Python 3 in EPEL 7 (rhbz 1797129, [2]). I need some additional Python 3 packages in EPEL 7 to achieve that and my question is which of these packages should get a proper review. A) python3-augeas https://bugzilla.redhat.com/show_bug.cgi?id=2043744 This is mostly the Fedora spec with just on additional bugfix (already upstream). B) python3-josepy intended spec file: https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-josepy/python-josepy.spec I did not want to upgrade the existing EPEL 7 package as the required version is Python 3 only. We can not use some newer macros like %pytest but otherwise the spec is the same as in Fedora. C) python3-boto3 python-boto3 (Python 2) version is in RHEL and won't get a Python3 package. intended spec file: https://github.com/FelixSchwarz/certbot-epel7-python3/blob/rawhide/python3-boto3/python3-boto3.spec The spec file is very close to the RHEL spec file just with some customizations removed. Should I try to get reviews for each of the three packages or can I skip some of these according to the Fedora review policy? Felix [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797129 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: MinGW & building wheels
Am 21.01.22 um 15:59 schrieb Scott Talbert: Does anyone have any experience with using Fedora's MinGW stack to cross-compile Python wheels for Windows? I'm using the mingw stack to cross-compile a Windows binary which shipped as part of an otherwise platform neutral Python wheel. The main problem I had with Fedora's mingw Python was that I could not create a Windows wheel. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Make -r (include runtime deps) the default for %pyproject_buildrequires
Am 10.01.22 um 13:55 schrieb Miro Hrončok: 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). +1 Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HEADS UP: Slightly more robust Python Requires generated by RPM
Am 30.10.21 um 21:42 schrieb Gordon Messmer: I'd suggest that we should instead strongly encourage the use of PyPI URLs. I agree that pypi downloads are usually preferable. However I had to use github tarballs sometimes as upstream did not ship the test suite for pypi tarballs... Just my 2 ¢ Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Macro to smoke-test-import a Python module in %check
Am 28.06.21 um 21:44 schrieb Miro Hrončok: The semantics is quite simple: %check %py3_check_import mymodule mymodule.submodule Looks great! Thank you. Please let us know when we should start adding that to our Python packages. :-) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to track the build failure built on f35-python
Am 07.06.21 um 09:49 schrieb Chenxiong Qi: I just noticed that python-social-auth-core-4.1.0-2.fc35 keeps failing to build on f35-python. I'm wondering if there is any mechanism to report a bug in Bugzilla automatically, or how do we usually track such failure? The main Python wranglers (Miro, Tomas, ...) will eventually file bugzilla issues. As far as I understand they'll try a couple of rebuilds because initially quite a few builds fail due to missing dependencies which are not yet build (or some dependencies which need to be fixed before they can be built). Just let them do their magic, they'll let you know (via bugzilla) when you should take a closer look. Felix PS: Do not build anything Python-related in Rawhide in the mean time, see Tomas' mail. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction | Harsh Mangal
Am 19.02.21 um 16:13 schrieb Harsh Mangal: I am Harsh having intermediate experience working with Python and I am interested in contributing to this SIG can anyone help me out on "How to get started". I could use some help e.g. with WeasyPrint/cairo: The latest cairo in Fedora 34+ did change something so that rendering slightly off which trips up WeasyPrint's test suite. If you like you could dig into that. Send me an email if you like to get some more infos. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Plan to deprecate pytz in Fedora 35+
Hi Miro, I can understand the desire to remove pytz and I have to mention that I don't have any specific upstream feedback. However certbot/babel do support pretty old versions of Python. Adding a separate code path for Python 3.x+ might be a pretty tough sell and might contribute to the "let's advertise snaps only for distribution" mindset. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: %pyproject_install: .dist-info vs .egg-info
On 30.11.20 10:54, Miro Hrončok wrote: Hence wrt backwards compatibility: pip might now refuse to uninstall the RPM installed package, while previously it would have done so happily. That is an improvement, but technically is not 100% backwards compatible behavior. Oh, I can live with THAT :-) Most of the bugs we are getting related to certbot is actually users messing around with pip manually (or adding incompatible third-party repos) so I'm all for users not breaking their system python install :-) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: %pyproject_install: .dist-info vs .egg-info
Am 29.11.20 um 23:11 schrieb Donald Stufft: Unless there’s something fedora specific going on, that should be correct. Upstream side, anytime pip installs from a Wheel it produces a dist-info instead of a egg-info, so if there was some compatibility issue, it should have been exposed awhile ago. Indeed, thank you. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
%pyproject_install: .dist-info vs .egg-info
Hey, I just noticed that the new packaging macros create a .dist-info directory instead of .egg-info. Just to be sure: There is no incompatibility between these two, right? So setuptools-based code can still retrieve all the package metadata in .dist-info directories? (If so I can just update the package in Fedora as that dist-info change itself does not break any backwards compatibility as far as other packages are concerned.) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: help wanted with modern Python packaging macros (%generate_buildrequires, %tox)
Hi Miro, just wanted to say thank you. It took me much longer than expected to actually try your suggestions but they were spot-on. :-) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
help wanted with modern Python packaging macros (%generate_buildrequires, %tox)
Hi, I wanted to update python-dns-lexicon. Version 3.4 uses poetry and tox so I thought it would be a good idea to get a grip on %generate_buildrequires, %tox etc. Unfortunately I'm a bit stuck at the moment. Maybe this is just because I'm starring for too long on some spec file (and probably my knowledge of tox+macros is lacking). I pushed the current state to: https://src.fedoraproject.org/fork/fschwarz/rpms/python-dns-lexicon/commits/master My main problem is shown at the end of this mail: Somehow the Python extras subpackage name is bad but I don't know how to debug this (without spending a lot of time). Additionally (but lower priority) just using %tox in %check fails (I think it tries to download dependencies?). Any help/pointers appreciated. Felix $ fedpkg --release=f33 mockbuild … Obsoletes: python-dns-lexicon < 3.4.0-1.fc33 Processing files: python3-dns-lexicon+easyname-3.4.0-1.fc33.noarch Error: The package name contains an extras name `easyname` that was not found in the metadata. Check if the extras were removed from the project. If so, consider removing the subpackage and obsoleting it from another. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Error: The package name contains an extras name `easyname` that was not found in the metadata. Check if the extras were removed from the project. If so, consider removing the subpackage and obsoleting it from another. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Provides: python-dns-lexicon+easyname = 3.4.0-1.fc33 python3-dns-lexicon+easyname = 3.4.0-1.fc33 python3.9-dns-lexicon+easyname = 3.4.0-1.fc33 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Obsoletes: python-dns-lexicon+easyname < 3.4.0-1.fc33 RPM build errors: absolute symlink: /usr/bin/lexicon-3 -> /usr/bin/lexicon-3.9 Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Finish: rpmbuild python-dns-lexicon-3.4.0-1.fc33.src.rpm Finish: build phase for python-dns-lexicon-3.4.0-1.fc33.src.rpm ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
ability to move just some Python files (+pyc) in subpackage?
Hi, I'm working towards updating python-dns-lexicon. It can handle many different dns APIs and for some APIs the code needs additional libraries (some of these are not packaged for Fedora). Upstream handles this by using "extras" requirements and the CLI throws an error message if you try to use a provider which needs additional dependencies. lexicon.client.ProviderNotAvailableError: This provider (transip) has required dependencies that are missing. Please install lexicon[transip] first. Ideally I'd like to move the provider's Python file (just a single file) AND the generated .pyc to a RPM subpackage where I could add the required dependencies (if possible). All provider files are located in the same directory. Is that possible with Fedora's RPM macros? Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
how to depend on 'requests[security]'?
Hey, I'm trying to update a package which now depends on "requests[security]" instead of just "requests". If I understand https://fedoraproject.org/wiki/Changes/PythonExtras correctly there no mechanism right now to pull in "requests[security]" (along with its dependencies) so I need to patch setup.py and (Build)Require the additional packages? Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Please BuildRequire python3-setuptools explicitly
Am 23.06.20 um 18:26 schrieb Tomas Hrnciar: > fschwarz pdfarranger python-ndg_httpsclient python-pdfrw python-pyrfc3339 > python-tinycss2 I fixed python-ndg_httpsclient, python-pdfrw, python-pyrfc3339 and python-tinycss2 dreua fixed pdfarranger. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
How to deal with remaining Python 2 packages in F33?
What is the Fedora policy regarding Python 2 packages in F33? If there was a Fesco exception for some package last year can we assume that we can/should keep the package also in F33? I did not find anything about the assumed scope of these Fesco exceptions. Specifically this is about bug 1737930: https://bugzilla.redhat.com/show_bug.cgi?id=1737930#c44 We added a conditional in babel so the Python 2 subpackage is not present anymore in master/F33. However trac maintainers ask if we could re-add the Python 2 package for babel in rawhide. Should I do that? Non-issues: - Babel supports Python 2 just fine. I could re-enable/maintain the subpackage without major issues. - For some (non-Fedora) $PROJECTS I'm still using Python 2 so I have sympathy for other who need Python 2 as well. I'm not on a crusade to wipe Python 2 from Fedora. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Newbie introduction to Python SIG
Hi Jens,
Am 05.05.20 um 21:28 schrieb Adrian Adrian:
> I was looking to join Fedora development, and as I'm most familiar with
> Python, I thought the Python SIG would be my way to go. Following the
> https://fedoraproject.org/wiki/SIGs/Python/JoinSIG guide, it suggests to post
> a self-introduction to the mailing list, so that's what I'm doing now :)
Welcome :-)
I guess there is a lot of important stuff where you can help out (both in
Fedora and/or upstream).
Just in case you don't find anything and you want to go more into packaging
you could check out blocking bugs for issue 1797129 ("certbot in EPEL 7 should
use Python 3"):
https://bugzilla.redhat.com/buglist.cgi?bug_id=1797129_id_type=anddependson=tvp_id=11041137#
(click "Expand all" for the full horror show ;-)
There are a lot of bugs to fix but most fixes are really easy as it means
adding Python 3 subpackages for EPEL 7 and usually the EPEL 7 version already
works with Python 3.
However there is a good chance (50% maybe?) you find outdated/ancient
packaging which I try to clean up while working on a package:
- no tests
executed during builds even though upstream has a suitable test
suite (this can involve a bit of digging upstream as sometimes you just need
1-2 additional patches to make it work in Fedora)
- e.g. bad licensing information
- using modern macros
If you want to look a bit at upstream Python work which could also help Fedora
(+other distros) you might want to check out python-betamax.
Currently Fedora can not run the test suite during package builds because it
requires internet access. Changing network endpoints are also a reason why the
upstream test suite breaks sometimes so it would be beneficial to mock all
network interaction.
There are two upstream tickets for this:
https://github.com/betamaxpy/betamax/issues/145
https://github.com/betamaxpy/betamax/issues/184#issuecomment-612632563
Once that is fixed ideally there is an upstream release which we can package
in Fedora. You might want to ping the maintainer so he knows that there is
something extra than just bumping the version.
Another pet peeve of mine is GPG verification during package builds as
described here:
https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatures#Source_file_verification
The issue is finding software which has signed releases and tweaking the spec
files accordingly.
Just a word of caution: The most frustrating thing when contributing to Fedora
(for me) is waiting for maintainers after submitting pull requests etc.
This can even affect seemingly high-profile packages like "mesa". For example
this pull request of mine did not get any reaction even though it is open for
about 1/2 year and I think its benefits are clear cut:
https://src.fedoraproject.org/rpms/mesa/pull-request/6
Pagure lists 15 maintainers and I sent several private emails but did not get
any response.
Most of the times I can get my changes in as needed. Even though I'm not a
sponsor feel free to ping me if you have questions or if you feel stuck. I'll
try to guide you to the right people/places to get you unblocked.
Felix
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: RFC: Python minimization in Fedora
Am 16.01.20 um 21:15 schrieb Zbigniew Jędrzejewski-Szmek: >> Accommodating component versioning would mean deploying >> >> /usr/lib/pythonxx/site-packages/something-semver.zip > > This path includes xx, which contains the major and minor numbers. So > adding "semver" would only allow accommodating different patch levels. > Would that be useful? Different patch levels are supposed to be about > bug fix only changes, so there's usually very little reason to carry > anything except the latest one for any specific major.minor combination. If I understood Nicolas correctly this was about installing multiple versions of the same *library* in the global Python site-packages directory? Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Is retrace.fedoraproject.org useless for Python exceptions?
Am 11.12.19 um 13:08 schrieb Lumir Balhar: > I don't know these tools but you can guess what happened from the file/line > combination in the stack and from the error name which contains the name of > the exception. Well, unfortunately this is not the case for certbot. It crashes in a generic import helper from python-requests which it uses to support both vendored and system libraries. Only the exception content would tell us which library is missing... :-( (Unfortunately this matches my previous experience with retrace/Python crashes.) > It'd be better to have also a content of an exception. I filed https://github.com/abrt/faf/issues/856 - hopefully that is the right place. (I'm a bit pessimistic though as I think the feature I am looking for already has a ticket - which has been open for more than 6 years.) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Is retrace.fedoraproject.org useless for Python exceptions?
I'm wondering if there is a way to get the Python exception message via retrace/abrt? From what I can see the web interface only shows the call stack but without a specific exception there is not much I can do. (I saw the exception message when a user created a bugzilla bug) Example: https://retrace.fedoraproject.org/faf/reports/2609546/ thanks, Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Python Annual Release Cycle adjusted to match odd-numbered Fedora releases
Am 07.11.19 um 13:31 schrieb Miro Hrončok: > "[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 That's a good time to say "thank you, Miro". :-) (also on behalf of the upstream projects where I am involved and where you submitted Python 3.8 patches) Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
