Package maintainer docs: Package Retirement: `git rm` all files in the other branches

Hello, As part of the effort to move the Package Maintainer docs to docs.fedoraproject.org [1], I have been reviewing the existing wiki documentation. I would like to ask for insight on the following item: Page _How to remove a package at end of life_ [2] first says that retirement is done b

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 6/14/21 03:51, Miro Hrončok wrote: On 08. 06. 21 1:01, Miro Hrončok wrote: On 02. 06. 21 10:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.10, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.10

Re: Seeking advice with rust packing guidelines

Hey Fabio, On 11/06/2021 15.38, Fabio Valentini wrote: On Fri, Jun 11, 2021 at 6:28 AM Fabio M. Di Nitto wrote: Hey everyone, I have been reading the current guideline here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ and for the most it´s pretty clear when packaging a

Fedora-Cloud-33-20210614.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210613.0): ID: 907429 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 14. 06. 21 9:26, Chenxiong Qi wrote: On 6/14/21 03:51, Miro Hrončok wrote: On 08. 06. 21 1:01, Miro Hrončok wrote: On 02. 06. 21 10:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.10, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

Dne 14. 06. 21 v 9:07 Otto Urpelainen napsal(a): Hello, As part of the effort to move the Package Maintainer docs to docs.fedoraproject.org [1], I have been reviewing the existing wiki documentation. I would like to ask for insight on the following item: Page _How to remove a package at end

Fedora-Cloud-34-20210614.0 compose check report

No missing expected images. Failed openQA tests: 8/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210613.0): ID: 907440 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/907440 ID: 907441 Test: x86_64 Cloud_Base-

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

Congrats, that's amazing! :-) Let's fix remaining broken packages! Victor On Sun, Jun 13, 2021 at 9:52 PM Miro Hrončok wrote: > > On 08. 06. 21 1:01, Miro Hrončok wrote: > > On 02. 06. 21 10:02, Tomas Hrnciar wrote: > >> Hello, in order to deliver Python 3.10, we are running a coordinated > >>

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On ma, 14 kesä 2021, Victor Stinner wrote: Congrats, that's amazing! :-) Let's fix remaining broken packages! Right now the biggest broken package to us (FreeIPA) is mod_wsgi which relied on Python C API which was removed in Python 3.10. The same API was used by uWSGI as well, so it would reall

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On Sun, Jun 13, 2021 at 9:52 PM Miro Hrončok wrote: > > And we have a successful compose, so Python 3.10 is now the main Python on > Rawhide. Awesome, thanks for working on this, as always. Python version updates are always scary, but you guys handle them so well. I see one problem with the Rus

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 14. 06. 21 13:40, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Victor Stinner wrote: Congrats, that's amazing! :-) Let's fix remaining broken packages! Right now the biggest broken package to us (FreeIPA) is mod_wsgi which relied on Python C API which was removed in Python 3.10. The same A

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 14. 06. 21 13:53, Fabio Valentini wrote: On Sun, Jun 13, 2021 at 9:52 PM Miro Hrončok wrote: And we have a successful compose, so Python 3.10 is now the main Python on Rawhide. Awesome, thanks for working on this, as always. Python version updates are always scary, but you guys handle th

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 14. 06. 21 14:17, Miro Hrončok wrote: - AttributeError: module 'unicodedata' has no attribute 'ucnhash_CAPI' https://docs.python.org/3.10/whatsnew/3.10.html#removed """ Removed the unicodedata.ucnhash_CAPI attribute which was an internal PyCapsule object. The related private _PyUnicode_Nam

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On Mon, Jun 14, 2021 at 2:21 PM Miro Hrončok wrote: > > On 14. 06. 21 14:17, Miro Hrončok wrote: > >> - AttributeError: module 'unicodedata' has no attribute 'ucnhash_CAPI' > > > > https://docs.python.org/3.10/whatsnew/3.10.html#removed > > > > """ > > Removed the unicodedata.ucnhash_CAPI attribut

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On ma, 14 kesä 2021, Miro Hrončok wrote: On 14. 06. 21 13:40, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Victor Stinner wrote: Congrats, that's amazing! :-) Let's fix remaining broken packages! Right now the biggest broken package to us (FreeIPA) is mod_wsgi which relied on Python C API wh

Azure CLI + SDK, side tags, and metapackages

Hey there, I'd like to provide an update on my packaging work for the Azure SDK and CLI[0] and ask for some help. Current status: * All non-Azure deps are packaged in rawhide 🎉 * SDK + CLI components now co-exist in a COPR repository[1] * Base SDK components (azure-core, azure-common) a

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 14. 06. 21 14:17, Miro Hrončok wrote: I see one problem with the Rust bindings for CPython / libpython, where the test suite now fails with Python 3.10: https://koschei.fedoraproject.org/package/rust-cpython? Looking at the build log, the new test failures seem to be caused by either API remo

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On Mon, Jun 14, 2021 at 2:54 PM Miro Hrončok wrote: > > On 14. 06. 21 14:17, Miro Hrončok wrote: > >> I see one problem with the Rust bindings for CPython / libpython, > >> where the test suite now fails with Python 3.10: > >> https://koschei.fedoraproject.org/package/rust-cpython? > >> > >> Looki

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On 14. 06. 21 14:40, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Miro Hrončok wrote: On 14. 06. 21 13:40, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Victor Stinner wrote: Congrats, that's amazing! :-) Let's fix remaining broken packages! Right now the biggest broken package to us (FreeI

Re: Azure CLI + SDK, side tags, and metapackages

On 14. 06. 21 14:40, Major Hayden wrote: My python-azure-common package that just finished a review[3] is version 1.1.27, so I would assume that the python-azure-common package would supersede the python-azure-sdk package since it provides a newer version of the azure-common module. (Is this tr

F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x == Summary == The Python Packaging guidelines will be rewritten, with the major changes being '''PyPI parity''' and usage of '''upstream metadata'''. A new set of macros, {{package|pyproject-rpm-macros}}, written in mind with th

Re: Azure CLI + SDK, side tags, and metapackages

On 6/14/21 8:30 AM, Miro Hrončok wrote: Not sure what you mean by "supersede" in this context, but I assume it wouldn't. Let me break it down: Would the python3-azure-common package automatically replace python3-azure-sdk during upgrades? No. Would the python3-azure-common package implicitl

Re: Azure CLI + SDK, side tags, and metapackages

On 14. 06. 21 15:36, Major Hayden wrote:   2) How do I convert the python-azure-sdk package into a no-files metapackage that brings in all of the SDK components? I.   Bump the metadata to a newer version-release (artificial?). II.  Remove all sources and contents of %prep/%build/%install.

Re: What are https://src.fedoraproject.org/container ?

On Sat, Jun 12, 2021 at 08:00:15AM -0400, Neal Gompa wrote: > At build-time, libguestfs copies the content of the kernel package > along with binaries of various filesystem tools into itself to run a > custom appliance for manipulating VMs. The Fedora-based libguestfs > package can handle Btrfs eve

Re: Self Introduction: Odilon Junior

On Fri, Jun 11, 2021 at 07:00:52PM -0300, Odilon Junior wrote: My name is Odilon Junior, Hi :) I'm also introducing myself because I want to become a maintainer of a new package in Fedora/EPEL, the new package is called obal[2], there's already one version of the package in copr. This package

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Questions, questions ... These new guidelines seem to be fine for pure Python packages, but I'm maintaining a couple of packages where Python bindings are built as subpackages of existing C libraries: https://src.fedoraproject.org/rpms/libnbd https://src.fedoraproject.org/rpms/libguestfs [Yes th

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe se

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? From the proposed guidelines: If a test suite exists upstream, it MUST be run in the %check section and/or in Fedor

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 17:56, Miro Hrončok wrote: Assuming that *all the tests* require network access, you should run them on Fedora CI instead. And if I don't want to patch tests in downstream or not interested in runing tests at all? For example my package wloc[1] has upstream tests, but they cann

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: > > On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: > > On 14.06.2021 15:32, Ben Cotton wrote: > >> Running upstream tests is mandatory. > > > > What about tests that require network access? > > From the proposed guidelines: > > > If a tes

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 18:35, Neal Gompa wrote: On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? From the proposed g

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 18:32, Vitaly Zaitsev via devel wrote: On 14.06.2021 17:56, Miro Hrončok wrote: Assuming that *all the tests* require network access, you should run them on Fedora CI instead. And if I don't want to patch tests in downstream or not interested in runing tests at all? For exampl

go-rpm-integration and symlinks

I'm attempting to package github.com/rjeczalik/notify[1] as an RPM. This package includes a utility function[2] that determines whether a path is a symlink, and resolves it to an absolute path. This function clearly has merit, as the package is an abstraction wrapper around inotify. There are te

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 19:16, Miro Hrončok wrote: That is exactly the thing we need to avoid. Python packages without tests always cause trouble when we measure impact of our changes. E.g. when we continuously rebuild packages with the next Python release, pure Python packages with incompatibilities but

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

I agree that running the tests wherever practical is the best practice. I do put my time where my mouth is—I maintain 17 packages that now use the pyproject-rpm-macros, and you’ll find that in general I’ve added a lot of %check sections to packages that were previously lacking them. However, le

Re: Preventing supply chain attacks via rekor

On Sat, Jun 12, 2021 at 10:29:50AM +0200, Marius Schwarz wrote: > Am 12.06.21 um 02:51 schrieb Kevin Fenzi: > > > > > Also, not having it available has made it *very* hard to prioritize > > > getting the issues fixed in DNF. So being able to improve this is > > > predicated on the existence of sig

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

On Mon, Jun 14, 2021 at 10:07:27AM +0300, Otto Urpelainen wrote: > Hello, > > As part of the effort to move the Package Maintainer docs to > docs.fedoraproject.org [1], I have been reviewing the existing wiki > documentation. I would like to ask for insight on the following item: > > Page _How to

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On ma, 14 kesä 2021, Neal Gompa wrote: On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: > On 14.06.2021 15:32, Ben Cotton wrote: >> Running upstream tests is mandatory. > > What about tests that require network access? From the propose

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 19:35, Benjamin Beasley wrote: I’m still in favor of running every test that is even vaguely practical in %check, but upstream Python packaging practices are wildly diverse (arguably, a mess) and it seems like a strongly worded SHOULD with a fallback of “trust the packager” would

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On ma, 14 kesä 2021, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x == Summary == The Python Packaging guidelines will be rewritten, with the major changes being '''PyPI parity''' and usage of '''upstream metadata'''. A new set of macros, {{package|pyproj

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021, at 2:07 PM, Miro Hrončok wrote: > On 14. 06. 21 19:35, Benjamin Beasley wrote: > However I think we should at least strictly require a smoke test (such as > %python3 -c "import foo, foo.bar") in such cases, for reasons described > below... > […] > > It’s also not clear to

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 20:28, Ben Beasley wrote: On Mon, Jun 14, 2021, at 2:07 PM, Miro Hrončok wrote: On 14. 06. 21 19:35, Benjamin Beasley wrote: However I think we should at least strictly require a smoke test (such as %python3 -c "import foo, foo.bar") in such cases, for reasons described below...

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 20:09, Alexander Bokovoy wrote: PyPI Parity Machine-readable metadata (''distribution'' names in dist-info directories on disk and the corresponding python3.Xdist(foo) RPM provides) will match the Python Package Index (PyPI). This solves a ''namespace'' issue. Python pac

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

On 14. 06. 21 19:50, Kevin Fenzi wrote: It might be somehow 'fedpkg retire' doesn't handle this case? While the wiki probably predates this feature, `fedpkg retire` will refuse to retire a package on a stable Fedora branch and it does not appear to have a --force switch. -- Miro Hrončok --

Re: Improving Fedora sponsors discoverability

Dne 11. 06. 21 v 17:03 Jakub Kadlcik napsal(a): Do you have any idea if there is a way to generate such areas and tie people to them based on some already existing information within the Fedora infrastructure? What about adopting the approach we use for Fedora Planet:   https://fedoraproject.o

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

Miro Hrončok kirjoitti 14.6.2021 klo 22.05: On 14. 06. 21 19:50, Kevin Fenzi wrote: It might be somehow 'fedpkg retire' doesn't handle this case? While the wiki probably predates this feature, `fedpkg retire` will refuse to retire a package on a stable Fedora branch and it does not appear to

Re: go-rpm-integration and symlinks

On 6/14/21 7:22 PM, Link Dupont wrote: I'm attempting to package github.com/rjeczalik/notify[1] as an RPM. This package includes a utility function[2] that determines whether a path is a symlink, and resolves it to an absolute path. This function clearly has merit, as the package is an abstrac

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Miro Hrončok writes: > On 14. 06. 21 19:35, Benjamin Beasley wrote: >> I’m still in favor of running every test that is even vaguely practical in >> %check, but upstream Python packaging practices are wildly diverse >> (arguably, a mess) and it seems like a strongly worded SHOULD with a >> fal

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 3:05 PM Miro Hrončok wrote: > > On 14. 06. 21 20:09, Alexander Bokovoy wrote: > >> PyPI Parity > >> > >> Machine-readable metadata (''distribution'' names in > >> dist-info directories on disk and the corresponding > >> python3.Xdist(foo) RPM provides) will match

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 6/14/21 1:53 PM, Neal Gompa wrote: This is completely unreasonable. The dist-info/egg-info data of a Python module is for generating dependencies, not for forcing people to deal with PyPI. I don't think we can reasonably separate the two. https://medium.com/@alex.birsan/dependency-confusio

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer wrote: > > On 6/14/21 1:53 PM, Neal Gompa wrote: > > This is completely unreasonable. The dist-info/egg-info data of a > > Python module is for generating dependencies, not for forcing people > > to deal with PyPI. > > > I don't think we can reasonabl

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 6/14/21 5:11 PM, Neal Gompa wrote: On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer wrote: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 It's not terribly different from how organizations may have private Python package indexes that may use whatever names they want for Pyt

Ways to contact wakko666 / Brett Lentz

Hello Fedorans. I wanted to NEEDINFO Brett, but Bugzilla says: You can't ask Brett Lentz because that account is disabled. Do you know any alternate ways to contact them? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 8:35 PM Gordon Messmer wrote: > > On 6/14/21 5:11 PM, Neal Gompa wrote: > > On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer > > wrote: > >> https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 > > It's not terribly different from how organizations may have pri

openvdb 8.1.0 update

Openvdb 8.1.0 is built on rawhide with so version updated to 8.1. Dependent packages like OpenImageIO needs updates to resolves their dependencies. See https://bodhi.fedoraproject.org/updates/FEDORA-2021-485cc4387a -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer _

Re: openvdb 8.1.0 update

On Mon, Jun 14, 2021 at 9:56 PM Luya Tshimbalanga wrote: > Openvdb 8.1.0 is built on rawhide with so version updated to 8.1. > Dependent packages like OpenImageIO > needs updates to resolves their dependencies. > > See https://bodhi.fedoraproject.org/updates/FEDORA-2021-485cc4387a Did I miss th

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 6/14/21 6:07 PM, Neal Gompa wrote: That only worked because public was default, not private. That's not how it works for Fedora packages at all. You're much more experienced in this area than I am, so I'm inclined to think that you're right and I'm missing something. The guidelines do mak

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On Mon, 2021-06-14 at 15:40 +0300, Alexander Bokovoy wrote: > > > > The fact that this blocks FreeIPA was indeed only discovered by chance > > while the side tag rebuild was already in progress (and about to be > > merged). I wonder haw can we improve the process to ensure problems > > like thi

Re: [HEADS UP] Fedora 35 Python 3.10 rebuilds have started in a side tag

On ma, 14 kesä 2021, Adam Williamson wrote: On Mon, 2021-06-14 at 15:40 +0300, Alexander Bokovoy wrote: > > The fact that this blocks FreeIPA was indeed only discovered by chance > while the side tag rebuild was already in progress (and about to be > merged). I wonder haw can we improve the proc

Re: Ways to contact wakko666 / Brett Lentz

Try https://twitter.com/brett_lentz or https://github.com/blentz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/proj