Re: Retiring python-pytest-flake8
On Fri, Jul 28, 2023 at 11:39:56AM -0500, Michel Alexandre Salim wrote:
> On Fri, Jul 28, 2023 at 12:17:54AM +0200, Sandro wrote:
> > On 27-07-2023 22:57, Sandro wrote:
> > > On 27-07-2023 21:02, Michel Alexandre Salim wrote:
> > > > Thanks Miro!
> > > >
> > > > On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> > > > > On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > > > > > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > > > > > enablerepo=fedora-source --whatrequires python-pytest-flake8
> > > > >
> > > > > Always use the actual binary package name for queries like this, as
> > > > > only the
> > > > > actual package name will show all dependencies that happen to require
> > > > > a
> > > > > differetn virtual provide:
> > > > >
> > > > > $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> > > > > pytest-flake8
> > > > > cvise-0:2.4.0-3.fc36.src
> > > > > python-cssutils-0:2.6.0-2.fc38.src
> > > > > python-nashpy-0:0.0.37-1.fc39.src
> > > > > python-pyunicorn-0:0.6.1-12.fc38.src
> > > > >
> > > > >
> > > > nashpy is fixed, but I'll take a look at the others. Given the disttags
> > > > they look like they FTBFSed anyway (cvise is fc36, ouch!)
> > >
> > > I can take care of pyunicorn. It looks simple enough.
> >
> > Consider pyunicorn fixed. The package itself is still broken, but that's
> > numpy related not due to the removal of pytest-flake8.
> >
> Thank you!
>
> I'll check cvise and cssutils.
>
cvise has an open PR that fixes it (and get it to build again):
https://src.fedoraproject.org/rpms/cvise/pull-request/3
python-cssutils is fixed in
https://src.fedoraproject.org/rpms/python-cssutils/pull-request/2
python-pytest-flake8 is now retired. Thanks for everyone who patched the
dependent packages!
Best,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
___
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: Retiring python-pytest-flake8
On Fri, Jul 28, 2023 at 12:17:54AM +0200, Sandro wrote:
> On 27-07-2023 22:57, Sandro wrote:
> > On 27-07-2023 21:02, Michel Alexandre Salim wrote:
> > > Thanks Miro!
> > >
> > > On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> > > > On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > > > > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > > > > enablerepo=fedora-source --whatrequires python-pytest-flake8
> > > >
> > > > Always use the actual binary package name for queries like this, as
> > > > only the
> > > > actual package name will show all dependencies that happen to require
> > > > a
> > > > differetn virtual provide:
> > > >
> > > > $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> > > > pytest-flake8
> > > > cvise-0:2.4.0-3.fc36.src
> > > > python-cssutils-0:2.6.0-2.fc38.src
> > > > python-nashpy-0:0.0.37-1.fc39.src
> > > > python-pyunicorn-0:0.6.1-12.fc38.src
> > > >
> > > >
> > > nashpy is fixed, but I'll take a look at the others. Given the disttags
> > > they look like they FTBFSed anyway (cvise is fc36, ouch!)
> >
> > I can take care of pyunicorn. It looks simple enough.
>
> Consider pyunicorn fixed. The package itself is still broken, but that's
> numpy related not due to the removal of pytest-flake8.
>
Thank you!
I'll check cvise and cssutils.
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
___
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: Retiring python-pytest-flake8
Thanks Miro!
On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > enablerepo=fedora-source --whatrequires python-pytest-flake8
>
> Always use the actual binary package name for queries like this, as
> only the
> actual package name will show all dependencies that happen to require
> a
> differetn virtual provide:
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> pytest-flake8
> cvise-0:2.4.0-3.fc36.src
> python-cssutils-0:2.6.0-2.fc38.src
> python-nashpy-0:0.0.37-1.fc39.src
> python-pyunicorn-0:0.6.1-12.fc38.src
>
>
nashpy is fixed, but I'll take a look at the others. Given the disttags
they look like they FTBFSed anyway (cvise is fc36, ouch!)
I won't retire pytest-flake8 until after checking the dependents, just
in case we still need to hotfix it (though my preference will be to
drop it as it should never have been run)
Best,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: This is a digitally signed message part
___
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
Retiring python-pytest-flake8
Dear all, We are retiring python-pytest-flake8. It FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2226304 and abandoned upstream: https://github.com/tholo/pytest-flake8/issues/98 (some suggest using ruff instead) and in addition, running linters in %check is discouraged anyway: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters I did a dependency analysis a couple of days ago and only python-nashpy popped up, this was a leftover because of manually specified test dependencies since fixed in https://src.fedoraproject.org/rpms/python-nashpy/pull-request/2 And there are no more dependents. If I miss anything in this query -- your package is FTBFS already anyway after the mass rebuild, so please remove the dependency. ``` michel in fedora/reviews/other took 13m39s ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --enablerepo=fedora-source --whatrequires python-pytest-flake8 Fedora rawhide - x86_64 19 MB/s | 73 MB 00:03 Fedora rawhide - Source 7.2 MB/s | 8.1 MB 00:01 Fedora rawhide - x86_64 - Updates 1.2 MB/s | 1.7 MB 00:01 Last metadata expiration check: 0:00:01 ago on Thu Jul 27 11:21:52 2023. michel in fedora/reviews/other took 37s ⬢ [fedora-toolbox:38] ❯ ``` Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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
Need eyes on Django 4.2.3 PR
Dear all, I just put up a PR to update Django in Rawhide to 4.2.3: https://src.fedoraproject.org/rpms/python-django/pull-request/33 Also - Fedora 37 and 38 are on Django 4.0.x, which is no longer supported - should we just update them to 4.2.x as well? Any version before 4.1.10 and 4.2.3 are affected by this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2219383 https://nvd.nist.gov/vuln/detail/CVE-2023-36053 NIST NVD gave it a base score of 7.5; and once we switch series anyway, maybe we might as well jump to 4.2 which is an LTS, while 4.1 reaches end of extended support in Dec 2023 (when Fedora 38 will still be supported) https://www.djangoproject.com/download/ To update to 4.2, asgiref needs to be updated as well, but that seems to be the only dependency that is too old. If we decide against bumping Django on stable releases, we can see if the CVE fix can be easily backported to 4.0 or not. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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: [EPEL-devel] Selenium 4 tarball woes
Hi, On Sun, Oct 02, 2022 at 04:11:43PM -0500, Michel Alexandre Salim wrote: > When going over my packager dashboard, I noticed that Selenium has not > been updated for a while. > > I cleaned up and redid > https://src.fedoraproject.org/rpms/python-selenium/pull-request/3, and then > converted the package to rpmautospec to make future PRs easier to > merge, and also requested the epel 9 branch that's been requested > several times. > > But when looking at bumping the version for Rawhide, it turned out > that... selenium authors no longer upload their source tarballs to PyPI, > and on GitHub they now only provide giant multi-lingual blobs: > https://github.com/SeleniumHQ/selenium/releases > > Looks like Debian is also stuck, their Selenium is the first alpha of > Selenium 4: > https://packages.debian.org/sid/python3-selenium > > There's an upstream issue, and apparently it's now intermittently > working, so I'll build the last 3.x series for all active releases (the > last version finally has a LICENSE file) and then build the last 4.x > tarball I can find on PyPI for Rawhide. If it works for rebuilding > Django then I will also build that for EPEL 9. > Forgot to link the upstream issue: https://github.com/SeleniumHQ/selenium/issues/9917 alas, it seems no tarball was ever uploaded for any release since 4.0.0.a7: https://pypi.org/pypi/selenium/json -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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
Selenium 4 tarball woes
When going over my packager dashboard, I noticed that Selenium has not been updated for a while. I cleaned up and redid https://src.fedoraproject.org/rpms/python-selenium/pull-request/3, and then converted the package to rpmautospec to make future PRs easier to merge, and also requested the epel 9 branch that's been requested several times. But when looking at bumping the version for Rawhide, it turned out that... selenium authors no longer upload their source tarballs to PyPI, and on GitHub they now only provide giant multi-lingual blobs: https://github.com/SeleniumHQ/selenium/releases Looks like Debian is also stuck, their Selenium is the first alpha of Selenium 4: https://packages.debian.org/sid/python3-selenium There's an upstream issue, and apparently it's now intermittently working, so I'll build the last 3.x series for all active releases (the last version finally has a LICENSE file) and then build the last 4.x tarball I can find on PyPI for Rawhide. If it works for rebuilding Django then I will also build that for EPEL 9. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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: Proposal: Make -r (include runtime deps) the default for %pyproject_buildrequires
On Mon, Jan 10, 2022 at 01:55:39PM +0100, Miro Hrončok wrote: > 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. > Yes please. I find myself having to add it several times, for packages that don't use Tox. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: python-flit for EPEL9?
On Thu, Dec 23, 2021 at 04:51:36PM -0500, Neal Gompa wrote: > Top posting because replying from my phone, but I think it'd be great to > have in EPEL 9 because it's essential for some packages to build. The same > goes for Poetry, which is now used for software made by Fedora > Infrastructure these days. > Do we (as in Fedora) have any preference which way, between setuptools, poetry, and flit? Asking because I'm writing a new tool and I wonder which build system to use. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: python-flit for EPEL9?
On Thu, Dec 23, 2021 at 11:18:47PM +0100, Miro Hrončok wrote: > On 23. 12. 21 21:10, Michel Alexandre Salim wrote: > > I'm starting to try and grok pyproject.toml and its assorted PEPs in > > more details, and it looks like flit is one of the more straightforward > > way to build compliant wheels out there. > > So is setuptools BTW. > True. > > Should we get it into EPEL9? I filed a tracking bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=2035376 > > Sure. > > > It currently does not build because of some missing dependencies - I > > listed them in the bug above - if we do want this in EPEL9 I'll file > > those bug requests and make them block this. > > I've noted some info about a bootstrap loop in a comment, reposting here for > clarity: > > Note that tomli/flit needs to be bootstrapped. If you want to void extra > commits, you can build flit 3.3.0 first, then tomli, then update flit. > Thanks for the tip! > > Also, to note, the EPEL maintainer is currently set to orphan. While I'm > > in python-sig so I can branch and build just fine as is, Miro, as the > > owner could you add me to the ACL and/or set me as the EPEL assignee? > > Done both. It was set to orphan because when I took the package I had no > intention to maintain the ancient version in EPEL 7 and 8. > Yeah, that makes sense. > > We could probably add epel-packagers-sig as collaborator on epel* > > branches too. > > Done. > And thanks Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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
python-flit for EPEL9?
I'm starting to try and grok pyproject.toml and its assorted PEPs in more details, and it looks like flit is one of the more straightforward way to build compliant wheels out there. Should we get it into EPEL9? I filed a tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=2035376 looks like it's retired in CS9 so it should be fine for us to have. https://gitlab.com/redhat/centos-stream/rpms/python-flit/-/blob/main/dead.package It currently does not build because of some missing dependencies - I listed them in the bug above - if we do want this in EPEL9 I'll file those bug requests and make them block this. Also, to note, the EPEL maintainer is currently set to orphan. While I'm in python-sig so I can branch and build just fine as is, Miro, as the owner could you add me to the ACL and/or set me as the EPEL assignee? We could probably add epel-packagers-sig as collaborator on epel* branches too. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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-rpm-macros: adding support for Pipfile?
*From: *Miro Hrončok *To: *Fedora Python SIG ; Michel Alexandre Salim *Date: *Dec 19, 2021 03:58:57 *Subject: *Re: pyproject-rpm-macros: adding support for Pipfile? On 17. 12. 21 23:26, Michel Alexandre Salim wrote: Hi, Is there interest in supporting parsing Pipfile for build requirements? Hi. Let me borrow an answer from a similar request somewhere else [1]: """Whatever comes out of this, we will probably strive for supporting existing standards, rather than specific tools that do their own thing.""" Supporting Pipfile is *not* planned. We should encourage upstreams to use a standardized way of specifying dependencies. Agreed, I'll see if I can nudge them, or bring up the issue with our internal Python team. If you need to parse out dev-packages from Pipfile, you could use a tool like micorpipenv (as already suggested by Lumír) to create a txt file with list of dependencies, and pass that file to %pyproject_buildrequires. However note that MonkeyType includes stuff like flake8 in there, so you would need to filter it anyway Thanks Lumir! I'll definitely check micropipenv, some of the other tools I've found don't exactly work. I was recently thinking that there are many common but not standardized ways upstream specify their test dependencies, e.g.: - setup.py: tests_require - Pipfile: dev-packages - pyproject.toml: tool.poetry.dev-dependencies And I don't really want to keep snowballing such use-cases to %pyproject_buildrequires. However, we might be able to provide a Python *interface* for anybody to hook in their own way. Something like: %pyproject_buildrequires -p my.module:function And it would use this function to generate a list of additional deps. Packagers could then either include custom implementations as sources if they really wanted to, or even package their own "%pyproject_buildrequires plugins". But maybe that's just too complex for a very narrow use case? [1] https://github.com/readthedocs/readthedocs.org/issues/3181#issuecomment-975378486 e.g. MonkeyType uses it to list its dependencies: https://github.com/instagram/MonkeyType For now I can just add requirements by hand, `%pyproject_buildrequires -r` does not error out but also does not generate anything. Amongst the defaults (pip, toml), it should also generate setuptools, wheel: https://github.com/Instagram/MonkeyType/blob/v21.5.0/pyproject.toml#L2 and mypy_extensions, libcst: https://github.com/Instagram/MonkeyType/blob/v21.5.0/setup.py#L48 Could you please share the specfile, so I can debug this? Sure. As it turns out, most of the requirements are indeed superfluous, the test suite passed just fine with just this: https://bugzilla.redhat.com/show_bug.cgi?id=2033816 It seems to work as expected with the demo provided in the example, but I haven't tried installing it in mock to make sure the runtime deps are complete. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name ___ 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
pyproject-rpm-macros: adding support for Pipfile?
Hi, Is there interest in supporting parsing Pipfile for build requirements? e.g. MonkeyType uses it to list its dependencies: https://github.com/instagram/MonkeyType For now I can just add requirements by hand, `%pyproject_buildrequires -r` does not error out but also does not generate anything. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: Adjusting python-django to latest Python Packaging Guidelines
On Wed, Dec 15, 2021 at 12:49:51PM -0800, Michel Alexandre Salim wrote: > On Tue, Dec 14, 2021 at 02:29:58PM -0800, Michel Alexandre Salim wrote: > > Hi all, > > > > Neal Gompa and I have been reviving the effort to get our mailing list > > server infrastructure (currently running on RHEL 7 with missing packages > > provided in an unofficial repo) hostable on RHEL 9 + EPEL. > > > > Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 > > Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 > > Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) > > > > Any objection if I modernize python-django's spec file so we get > automatic BRs? I accidentally branched python-mock for EPEL9 because > Django BR-ed it, before realizing that it's an out of date BR and the > unit tests all use `from unittest import mock` already > > ref: https://fedoraproject.org/wiki/Changes/DeprecatePythonMock > > python-django without python-mock built for Rawhide: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1867385 > PR: https://src.fedoraproject.org/rpms/python-django/pull-request/20 This now adheres closely to the Python Packaging Guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ - automatic BRs - Consistently use pyproject macros As a bonus, it's so much cleaner and we track the directories for localization files better. Provides and Requires are sane (I provided details in the PR comments) I'll leave this open for a couple of days and then merge it if there's no objection. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 10:20:27PM +0100, Charalampos Stratakis wrote: > On Wed, Dec 15, 2021 at 10:03 PM Miro Hrončok wrote: > > > On 15. 12. 21 21:49, Michel Alexandre Salim wrote: > > > (I haven't built python-mock in EPEL9 yet, and am not going to unless we > > > really need it for something - but I'll hold off on retiring the branch) > > > > Please, retire it for EPEL9. It should never be needed. > > > > > Unfortunately it's quite possible something might need it as there are > still a lot of packages relying on the external mock. > True, but we probably should patch these going forward? I'm happy to help. I wonder how many of those will turn out to be obsolete BRs too. > I would keep the branch but defer building it for now. > Argh, too late, but unretiring is easy anyway. Regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 10:03:29PM +0100, Miro Hrončok wrote: > On 15. 12. 21 21:49, Michel Alexandre Salim wrote: > > (I haven't built python-mock in EPEL9 yet, and am not going to unless we > > really need it for something - but I'll hold off on retiring the branch) > > Please, retire it for EPEL9. It should never be needed. > Done, sorry for the noise https://src.fedoraproject.org/rpms/python-mock/blob/9cca66d7e2b5ac0784e160e02383807991890f5c/f/dead.package Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Tue, Dec 14, 2021 at 02:29:58PM -0800, Michel Alexandre Salim wrote: > Hi all, > > Neal Gompa and I have been reviving the effort to get our mailing list > server infrastructure (currently running on RHEL 7 with missing packages > provided in an unofficial repo) hostable on RHEL 9 + EPEL. > > Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 > Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 > Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) > Any objection if I modernize python-django's spec file so we get automatic BRs? I accidentally branched python-mock for EPEL9 because Django BR-ed it, before realizing that it's an out of date BR and the unit tests all use `from unittest import mock` already ref: https://fedoraproject.org/wiki/Changes/DeprecatePythonMock python-django without python-mock built for Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1867385 (I haven't built python-mock in EPEL9 yet, and am not going to unless we really need it for something - but I'll hold off on retiring the branch) Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Wed, Dec 15, 2021 at 11:53:02AM +0100, Miro Hrončok wrote: > On 15. 12. 21 11:51, Miro Hrončok wrote: > > On 14. 12. 21 23:29, Michel Alexandre Salim wrote: > > > In particular, python-nbconvert specifically requires mistune < 2, and > > > upstream doesn't seem to have a newer release yet. > > > > This is the biggest blocker. If nbconvert figures it out in git, we can > > backport it. Until then, I would not merge the update. If we really need > > this ASAP, we can introduce python-mistune0.8 compat pacakge. > > Upstream issue https://github.com/jupyter/nbconvert/issues/1685 > > I am quite confident they would accept a PR, but I don't have the capacity > to contribute one at this moment. I can try looking at this to unblock then. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
On Tue, Dec 14, 2021 at 05:50:46PM -0500, Elliott Sales de Andrade wrote: > On Tue, 14 Dec 2021 at 17:32, Michel Alexandre Salim > wrote: > > > > Hi all, > > > > Neal Gompa and I have been reviving the effort to get our mailing list > > server infrastructure (currently running on RHEL 7 with missing packages > > provided in an unofficial repo) hostable on RHEL 9 + EPEL. > > > > Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 > > Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 > > Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) > > > > We're currently stuck on the following: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2032607 > > > > Your package (python-hyperkitty) Fails To Install in Fedora 36: > > > > can't install hyperkitty: > > - nothing provides python3.10dist(flufl-lock) >= 4 needed by > > hyperkitty-1.3.5-1.fc36.noarch > > - nothing provides python3.10dist(mistune) >= 2~rc1 needed by > > hyperkitty-1.3.5-1.fc36.noarch > > > > I have PRs attached to the upgrade requests for mistune: > > https://bugzilla.redhat.com/show_bug.cgi?id=1782288 > > and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 > > > > but both have breaking changes I detailed in the above Bz entries; if > > you're a maintainer cc:ed on this email please check the relevant bz: > > > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > > --whatrequires python3-flufl-lock > > mailman3-0:3.3.4-5.fc35.noarch > > mailman3-0:3.3.4-5.fc35.src > > mailman3-0:3.3.4-5.fc36.noarch > > mailman3-0:3.3.4-5.fc36.src > > odcs-0:0.3.4-6.fc35.noarch > > odcs-0:0.3.4-6.fc35.src > > odcs-0:0.3.4-6.fc36.noarch > > odcs-0:0.3.4-6.fc36.src > > python-cartopy-0:0.20.0-1.fc35.src > > python-cartopy-0:0.20.1-2.fc36.src > > > > ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source > > --whatrequires python3-mistune > > python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src > > python-nbconvert-0:6.1.0-2.fc35.src > > python-nbconvert-0:6.1.0-3.fc36.src > > python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch > > python3-nbconvert-0:6.1.0-2.fc35.noarch > > python3-nbconvert-0:6.1.0-3.fc36.noarch > > > > In particular, python-nbconvert specifically requires mistune < 2, and > > upstream doesn't seem to have a newer release yet. python-cartopy oddly > > only requires flufl-lock in its SRPM, not the built RPM. > > > > Cartopy only needs flufl-lock to run tests. I suppose since those are > installed, it could also have a runtime dependency, but it'd be > largely unused, and anyway Cartopy won't need it at all after the next > minor release. Thanks, I just checked and all cartopy tests still pass with flufl-lock 6.0. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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
The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?
Hi all, Neal Gompa and I have been reviving the effort to get our mailing list server infrastructure (currently running on RHEL 7 with missing packages provided in an unofficial repo) hostable on RHEL 9 + EPEL. Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455 Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061 Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet) We're currently stuck on the following: https://bugzilla.redhat.com/show_bug.cgi?id=2032607 Your package (python-hyperkitty) Fails To Install in Fedora 36: can't install hyperkitty: - nothing provides python3.10dist(flufl-lock) >= 4 needed by hyperkitty-1.3.5-1.fc36.noarch - nothing provides python3.10dist(mistune) >= 2~rc1 needed by hyperkitty-1.3.5-1.fc36.noarch I have PRs attached to the upgrade requests for mistune: https://bugzilla.redhat.com/show_bug.cgi?id=1782288 and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603 but both have breaking changes I detailed in the above Bz entries; if you're a maintainer cc:ed on this email please check the relevant bz: ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source --whatrequires python3-flufl-lock mailman3-0:3.3.4-5.fc35.noarch mailman3-0:3.3.4-5.fc35.src mailman3-0:3.3.4-5.fc36.noarch mailman3-0:3.3.4-5.fc36.src odcs-0:0.3.4-6.fc35.noarch odcs-0:0.3.4-6.fc35.src odcs-0:0.3.4-6.fc36.noarch odcs-0:0.3.4-6.fc36.src python-cartopy-0:0.20.0-1.fc35.src python-cartopy-0:0.20.1-2.fc36.src ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source --whatrequires python3-mistune python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src python-nbconvert-0:6.1.0-2.fc35.src python-nbconvert-0:6.1.0-3.fc36.src python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch python3-nbconvert-0:6.1.0-2.fc35.noarch python3-nbconvert-0:6.1.0-3.fc36.noarch In particular, python-nbconvert specifically requires mistune < 2, and upstream doesn't seem to have a newer release yet. python-cartopy oddly only requires flufl-lock in its SRPM, not the built RPM. PRs: https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1 https://src.fedoraproject.org/rpms/python-mistune/pull-request/5 (the packages are not in side tags yet because the PRs are not merged yet, but if it helps I can build them in a COPR for F35) We should probably bump the packages in Rawhide anyway, but also to note: - both of these packages are not co-maintained by the Python SIG - most of the recent updates have been done by non-maintainers Would it make sense to get the following groups officially added to the package ACLs? - infra-sig (admin), to ease maintaining the dependencies for Mailman and Hyperkitty - python-sig (commit or admin), for fixing issues e.g. with newer Python versions - epel-packagers-sig (collaborator, epel* branches) for helping to bootstrap on new EL releases Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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
pyproject_buildrequires choked on mistune
I'm packaging python-mistune as a dependency for hyperkitty (so we can
finally pull off a Mailman3/Hyperkitty migration from the current
RHEL7+custom repo setup - tracked in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2030061)
python-mistune review:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2031262
One weird thing is, pyproject_buildrequires fails:
```
Executing(%generate_buildrequires): /bin/sh -e /var/tmp/rpm-tmp.KZ4hKk
+ umask 022
+ cd /builddir/build/BUILD
+ cd mistune-2.0.0
+ echo python3-devel
+ echo 'python3dist(pip) >= 19'
+ echo 'python3dist(packaging)'
+ '[' -f pyproject.toml ']'
+ echo 'python3dist(toml)'
+ rm -rfv '*.dist-info/'
+ '[' -f /usr/bin/python3 ']'
+ RPM_TOXENV=py310
+ HOSTNAME=rpmbuild
+ /usr/bin/python3 -s /usr/lib/rpm/redhat/pyproject_buildrequires.py
--generate-extras --python3_pkgver
sion 3
Handling setuptools from build-system.requires
Requirement satisfied: setuptools
(installed: setuptools 58.5.3)
Handling wheel from build-system.requires
Requirement not satisfied: wheel
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 421, in main
generate_requires(
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 354, in
generate_requires
backend = get_backend(requirements)
File "/usr/lib/rpm/redhat/pyproject_buildrequires.py", line 219, in
get_backend
raise FileNotFoundError('File "setup.py" not found for legacy project.')
FileNotFoundError: File "setup.py" not found for legacy project.
```
so I had to manually add the BRs in
https://salimma.fedorapeople.org/specs/python/python-mistune.spec
the `pyproject.toml` is super simple:
```
$ cat python/mistune-2.0.0/pyproject.toml
[build-system]
requires = [ "setuptools", "wheel" ]
```
because the project really didn't have any dependency (beyond pytest for
running tests).
Is this a problem with our tooling or with upstream's pyproject.toml?
Happy to follow up with them if they need a more fleshed-out project
definition.
Thanks,
--
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
signature.asc
Description: PGP signature
___
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: Python RPM dependency generator does not support PEP 508?
On Fri, 2021-11-12 at 10:24 -0500, Ben Beasley wrote: > I know this pattern works in general, because I maintain several Python > packages in which it is used. > > I tried modifying python-fixit to patch requirements.txt as you > described. I confirmed the line appeared in the “prepped” source as you > have written. Then I built it with mock and installed it into a Rawhide > chroot without difficulty. > > My best guess is that there was a mix-up in which RPM version you were > trying to install—something that’s probably happened to all of us. > Perhaps you built it in Rawhide and didn’t use --enablerepo=local when > testing the installation? > Ah, that's likely what happened. And indeed, < '3.7' is better. Thanks! Now we have something we can upstream, while just yanking out that line likely won't fly: https://github.com/Instagram/Fixit/pull/206 Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: This is a digitally signed message part ___ 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
On Wed, Jul 14, 2021 at 07:27:52PM +0200, Miro Hrončok wrote: > On 08. 07. 21 16:48, Miro Hrončok wrote: > > On 29. 06. 21 8:28, Felix Schwarz wrote: > > > > > > 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. :-) > > > > Feel free to test it out in rawhide. > > > > If there is no more feedback, I'll initiate the backports next week. > > > EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/31 > > EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/32 > Tested the EPEL updates: EPEL 8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dfd462a782 EPEL 7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e3b1cc2b6e with this `python-dialog` PR: https://src.fedoraproject.org/rpms/python-dialog/pull-request/1 Works fine. If someone wants to help test, the needed `epel-rpm-macros` is in buildroot override, and here's a good way to find EPEL specs that do not have checks yet: wget -cN https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz tar xf rpm-specs-latest.tar.xz cd rpm-specs grep -l epel $(grep -L '%check' python*.spec) currently resulting in: python-bitarray.spec python-dialog.spec python-docker.spec python-epel-rpm-macros.spec python-fedora.spec python-flask-login.spec python-graphitesend.spec python-pretend.spec python-progress.spec python-pvc.spec python-pysb.spec python-pyvirtualize.spec python-qt5.spec python-requests-oauthlib.spec python-sphinx-bootstrap-theme.spec python-sphinx_lv2_theme.spec python-stuf.spec python-unidecode.spec python-urlobject.spec python-vevents.spec python-vpoller.spec python-wrapt.spec python-wtforms.spec python-xcffib.spec Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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
python-testtools 2.5.0 built for Rawhide
I've upgraded python-testtools in Rawhide to 2.5.0 The upstream changelog contains some breaking changes, so I'm not planning to upgrade F34 (let alone F33) unless there's a need for it. It's mostly removing deprecated functionality though: https://github.com/testing-cabal/testtools/releases/tag/2.5.0 As a bonus, all patches have been dropped, this release builds cleanly on Python 3.10 (despite the release notes only saying it's tested on 3.9) and all tests pass. -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ 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: Is it worthwhile to get fedora-review into EPEL8?
On Thu, 2020-12-03 at 12:32 -0800, Michel Alexandre Salim wrote: > I split my time between the latest Fedora and the latest CentOS these > days, and it would make dogfooding packaging changes for CentOS/EPEL > much easier if all the packager utilities are available. Right now, > fedpkg is, but fedora-review is not. > > Tracking my effort here: https://pagure.io/epel/issue/108 > > Apart from the usual package-not-available story (which I want to fix > as part of my work bringing up the EPEL Packagers SIG), my current > snag > is that python-tox-current-env uses %generate_buildrequires which > does > not work on CentOS 8: > > ERROR: Source RPM is not installable: > error: Missing rpmlib features for python-tox-current-env-0.0.5- > 1.el8.noarch: > error: rpmlib(DynamicBuildRequires) <= 4.15.0-1 > > CentOS 8 is still on RPM 4.14: > sh-4.4# rpm -q rpm > rpm-4.14.2-37.el8.x86_64 > > I'll put up a patch to hardcode dependencies for non-Fedora releases, > though that sorts of defeat the purpose of dynamic build > requirements. > Then again, this is only needed for EPEL8, since EPEL9 will have a > new > enough RPM. > Given that %generate_buildrequires is the selling point of pyproject- rpm-macros, I'm guessing a better way forward for EPEL8 would be to not require it on EPEL8 since there's no way it would work, since RH won't update RPM? https://src.fedoraproject.org/rpms/pyproject-rpm-macros Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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 it worthwhile to get fedora-review into EPEL8?
I split my time between the latest Fedora and the latest CentOS these days, and it would make dogfooding packaging changes for CentOS/EPEL much easier if all the packager utilities are available. Right now, fedpkg is, but fedora-review is not. Tracking my effort here: https://pagure.io/epel/issue/108 Apart from the usual package-not-available story (which I want to fix as part of my work bringing up the EPEL Packagers SIG), my current snag is that python-tox-current-env uses %generate_buildrequires which does not work on CentOS 8: ERROR: Source RPM is not installable: error: Missing rpmlib features for python-tox-current-env-0.0.5- 1.el8.noarch: error: rpmlib(DynamicBuildRequires) <= 4.15.0-1 CentOS 8 is still on RPM 4.14: sh-4.4# rpm -q rpm rpm-4.14.2-37.el8.x86_64 I'll put up a patch to hardcode dependencies for non-Fedora releases, though that sorts of defeat the purpose of dynamic build requirements. Then again, this is only needed for EPEL8, since EPEL9 will have a new enough RPM. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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: PythonMacroError change tripping up fedora-review on Python packages?
On Tue, 2020-10-27 at 16:41 -0700, Michel Alexandre Salim wrote: > When reviewing python-TestSlide > (https://bugzilla.redhat.com/show_bug.cgi?id=1891963#), > fedora-review failed with: > > error: attempt to use unversioned python, define %__python to > /usr/bin/python2 or /usr/bin/python3 explicitly > > This seems related to the change introduced in F33: > https://fedoraproject.org/wiki/Changes/PythonMacroError > > but we're a bit puzzled as to how it happens since we can't find any > macro usage that expands to %__python. > OK, it's a fedora-review bug that got fixed 2 months ago, but there's not been a release since: https://pagure.io/FedoraReview/c/e357d1970aad94621a627c5f2d41513438bf45cb?branch=master Could someone cut a release? Meanwhile, running try-fedora-review from a Git checkout works. Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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
PythonMacroError change tripping up fedora-review on Python packages?
When reviewing python-TestSlide (https://bugzilla.redhat.com/show_bug.cgi?id=1891963#), fedora-review failed with: error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly This seems related to the change introduced in F33: https://fedoraproject.org/wiki/Changes/PythonMacroError but we're a bit puzzled as to how it happens since we can't find any macro usage that expands to %__python. Out of curiosity I checked out python-six (fedpkg clone python-six && cd python-six && fedpkg srpm) and ran fedora-review on it, and it failed with the same error; likewise the spec seems valid to me. Any idea what could be the problem here? Thanks in advance! ❯ fedora-review --rpm-spec --name ./python-six-1.15.0-2.fc34.src.rpm INFO: Processing local files: ./python-six-1.15.0-2.fc34.src.rpm INFO: Getting .spec and .srpm Urls from : Local files in /home/michel/src/fedora/other-pkgs/python-six INFO: --> SRPM url: file:///home/michel/src/fedora/other-pkgs/python- six/python-six-1.15.0-2.fc34.src.rpm INFO: Using review directory: /home/michel/src/fedora/other- pkgs/python-six/python-six INFO: Downloading (Source0): https://files.pythonhosted.org/packages/source/s/six/six-1.15.0.tar.gz INFO: Running checks and generating report INFO: Results and/or logs in: /home/michel/src/fedora/other- pkgs/python-six/python-six/results INFO: Reading configuration from /etc/mock/site-defaults.cfg INFO: Reading configuration from /etc/mock/fedora-rawhide-x86_64.cfg INFO: Build completed INFO: Installing built package(s) INFO: Active plugins: Shell-api, Python, Generic error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly ERROR: Exception down the road... (logs in /home/michel/.cache/fedora- review.log) -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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 spec template violates guidelines?
On Wed, 2020-08-26 at 18:46 -0400, Neal Gompa wrote: > On Wed, Aug 26, 2020 at 6:25 PM Michel Alexandre Salim > wrote: > > > > So: > > F32 has rpmdevtools 8.10, which was first released... over three > > years > > ago > > > > * Sat Jan 14 2017 Ville Skyttä - 8.10-1 > > > > The spec in pagure is updated (including a patch Miro committed > > last > > year), but looks like it's only built for F33 and F34 right now. > > > > Neal, we should be able to release this for F32, right? Most > > packagers > > are likely to still be on it rather than on the recently branched > > F33 > > so it probably would save some review time. > > > > I am not releasing rpmdevtools 9.x to F32 or older because I've > changed default behaviors for 9.0 and replaced the spectool > implementation. > Ack. That probably means I'll run F33 sooner rather than later, at least in a toolbox container. Thanks, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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 spec template violates guidelines?
On Wed, 2020-08-26 at 15:16 -0700, Michel Alexandre Salim wrote: > On Wed, 2020-08-26 at 20:23 +0200, Miro Hrončok wrote: > > > > I don't really know who maintains `rpmdev-newspec python-foo` but > > the > > output > > (when I run this on Fedora 32) is really severely outdated beyond > > being any > > useful. I remember trying to update the template many years ago but > > got stuck at > > EPEL-compatibility issues. > > > Neal maintains rpmdevtools, both on src.fp.o and on Pagure > > I'll get a PR in to make the Python spec a bit more up to date. This > brings to mind that I've been intendeing to have a spec template and > a > packaging guideline for Lua for a while; that can go next. > So: F32 has rpmdevtools 8.10, which was first released... over three years ago * Sat Jan 14 2017 Ville Skyttä - 8.10-1 The spec in pagure is updated (including a patch Miro committed last year), but looks like it's only built for F33 and F34 right now. Neal, we should be able to release this for F32, right? Most packagers are likely to still be on it rather than on the recently branched F33 so it probably would save some review time. Best, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ 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 spec template violates guidelines?
On Wed, 2020-08-26 at 20:23 +0200, Miro Hrončok wrote:
> On 26. 08. 20 19:59, Michel Alexandre Salim wrote:
> > Per https://pagure.io/packaging-committee/issue/782, "Forbid
> > %{pythonX_site(lib|arch)}/* in %files" Python packages should not
> > blindly glob contents of the sitelib/sitearch directories.
> >
> > This makes sense, in fact, I just got bit by this packaging python-
> > sphinx-hoverxref (
> > https://bugzilla.redhat.com/show_bug.cgi?id=1872508)
> > -- for some reason a `tests` directory also get copied to buildroot
> > and
> > thus get packaged.
> >
> > `rpmdev-newspec python-foo` still produces a spec with globbing
> > though.
> > This is just a matter of omission, I presume? I can put up a PR
> > fixing
> > this.
>
> I don't really know who maintains `rpmdev-newspec python-foo` but the
> output
> (when I run this on Fedora 32) is really severely outdated beyond
> being any
> useful. I remember trying to update the template many years ago but
> got stuck at
> EPEL-compatibility issues.
>
Neal maintains rpmdevtools, both on src.fp.o and on Pagure
I'll get a PR in to make the Python spec a bit more up to date. This
brings to mind that I've been intendeing to have a spec template and a
packaging guideline for Lua for a while; that can go next.
Thanks,
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
signature.asc
Description: This is a digitally signed message part
___
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
On 6/23/20 9:26 AM, Tomas Hrnciar wrote:
Hello everyone,
there are plenty of Python packages in Fedora currently using setuptools at
buildtime but not all of them are BuildRequiring it explicitly. This only
works because python3-devel (transitively) depends on python3-setuptools.
We would like to kindly ask you to add explicit
BuildRequires for python3-setuptools to packages where setuptools is used. It
will help us with testing new versions of setuptools in the future or
with decoupling Python and setuptools. Today, if we want to know if a
package is using setuptools,we have to do `fedpkgprep` and use grep to
search for setuptools. Using a repoquery is much more convenient.
...
salimma python-django python-psutil
Done (for Rawhide). For python-psutil I'm following the other pattern in
the spec and using python%{python3_pkgversion}-setuptools, but this
should resolve to python3-setuptools when you use repoquery.
Cheers,
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: Intent to retire python-blist, but it's "apparently" being used by python-ujson
Howdy, On 5/11/20 9:21 PM, Igor Raits wrote: The blist requirement is gone in 2.0.0; we should probably upgrade from the pre-release snapshot we've been using since 2017 (eek): https://github.com/ultrajson/ultrajson/releases/tag/2.0.0 Thanks for noticing that! https://src.fedoraproject.org/rpms/python-ujson/c/f906bbad0017e41acebb67528277c828fc428a65?branch=master Awesome, thanks! I'll retire python-blist in Rawhide then. Was working on a PR for python-ujson and noticed your commit just as I was finishing mine up. The spec is so much cleaner now, thanks! Best, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ 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: Draft of New Python Packaging Guidelines
Hi, On 4/30/20 6:41 AM, Petr Viktorin wrote: The draft lives on hackmd.io, which we found easy to collaborate with. If you have an account there, we can add you. If you'd like to collaborate some other way, let us know. Please add mic...@michel-slm.name, thanks! (I'm assuming hackmd.io allows commenting on the document without overwriting it willy-nilly) Best, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ 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
[Python 3 migration] Heads up: Retiring the Obnam stack and gnumed-server
Hi all, With Python 2 slated to be removed, I'm going to retire these packages where upstream has either stopped development (Obnam's dependencies) or is moving too slow to get a stable Python 3-based release out (gnumed-server). Also, I've been helping out with gnumed (the client) but never officially maintained it, and that package is already retired in Rawhide due to being orphaned - so there's no reason to keep the server around. List of packages as follows, I'll hold off until Friday before retiring them if someone wants to take over these packages and get them built. If you take over gnumed-server you should take over gnumed and unretire it too. gnumed: gnumed-server Obnam stack: - cmdtest - genbackupdata - python-cliapp - python-coverage-test-runner - python-larch - python-tracing - python-ttystatus - summain Thanks, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ 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
Two more Python packages for review swaps: python-qrcode and gnuhealth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Two more Python packages, if anyone is interested in swapping: https://bugzilla.redhat.com/show_bug.cgi?id=827722 - for python-qrcode, a dependency for GNU Health https://bugzilla.redhat.com/show_bug.cgi?id=827723 - GNU Health Feel free to take them up -- and I'll do my best to help out with package reviews, just let me know what needs reviewing. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPyxaJAAoJEEr1VKujapN6Rn4H/0Jgdj2jAMGImhgeb0cofRMD BCMszsMeG2JGTIZNocj1UMhq/HGHNfzqgepPrBzfyXoC7NRf0aUZFYocoIEgLXPZ BmtDLo3udZ5iBuZ1+epkMZ2oDRtBH1ZqdZ6NbZXbg9PraQRh6s1ctOKT32fIEeYb 2GEmlB2VL4Rgtb01PbP6p4Cmu7K9mYKPTB4d0Kl02xcYQzr7tdifW3loh9Kcg5wk UcZc/Mdms+6ZImQK8EBtwd/iZqc3O92mwDUhtf2coiDKzUWJludI+lLO8PyLGLgf skiwyIXLoCR/QeUb49wX52OC02qWtVT0MK5rcba67KNbllG2ZE4bwq+NIvWlHiY= =+gcR -END PGP SIGNATURE- ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Review swap requests for Lars Wirzenius' new Obnam backup tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2012 01:45 PM, Michel Alexandre Salim wrote: > Hi all, > > I've just packaged Obnam, Lars Wirzenius' new B-tree-based backup > tool (think btrfs for backup), whose 1.0 release was recently > announced on Linux Weekly News on Friday, June 1st: > > http://lwn.net/Articles/499845/ > > It consists of 8 packages, and there are two more (seivot, for > benchmarking, and summain, for generating diff-able file > manifests) that I have not packaged yet, all eight are in Bugzilla, > in descending order (packages at the bottom are depended on by the > ones on top) > I've now also packaged the remaining two auxiliary packages: seivot - Benchmarking tool for backup programs https://bugzilla.redhat.com/show_bug.cgi?id=827818 summain - File manifest generator https://bugzilla.redhat.com/show_bug.cgi?id=827819 PS please reply to this rather than the original message; I accidentally used the old fedora-devel email address. > As usual, please reply to the list with which package you want to > review and if you want to swap with any of your own review > requests. > Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPyxSbAAoJEEr1VKujapN6YZAH/izJNSfHS6SnJgAsMr5w9kMY iBJiyh9PGxJgljaPOE4/3fPPzAHduD8crk3hhYJkHEKki0nzyza+yb7/jorFohKe mpyTYaSrJ6E2zntBfa7zgm69nHT6TNTsEh1KlkRG4HhGoNSJZ3eUoOdqrc5szO3x /a1uEIdzxQ+QC0jIQzAWZ4Uh9nC8UJVMBybZgPUa2YRJXkTtGW3+NUzGThX8K04M 9MQk9nnBKGq6spniBPs8w9idp1UNJEa430tB7NySuHPxsgkQY1hP4tMh1bT4/+EL /4QCO5KAKaPrj9lsUYot7ui+YVQQyl6vn17+Ku9u6WizlcjBX70nX1bE5ClBfxM= =lX3d -END PGP SIGNATURE- ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Review swap requests for Lars Wirzenius' new Obnam backup tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've just packaged Obnam, Lars Wirzenius' new B-tree-based backup tool (think btrfs for backup), whose 1.0 release was recently announced on Linux Weekly News on Friday, June 1st: http://lwn.net/Articles/499845/ It consists of 8 packages, and there are two more (seivot, for benchmarking, and summain, for generating diff-able file manifests) that I have not packaged yet, all eight are in Bugzilla, in descending order (packages at the bottom are depended on by the ones on top) obnam - An easy, secure backup program https://bugzilla.redhat.com/show_bug.cgi?id=827810 genbackupdata - A program to generate test data for testing backup software https://bugzilla.redhat.com/show_bug.cgi?id=827809 python-larch - Python B-tree library https://bugzilla.redhat.com/show_bug.cgi?id=827808 python-tracing - Python debug logging helper https://bugzilla.redhat.com/show_bug.cgi?id=827807 cmdtest - Black-box testing for Unix command line tools https://bugzilla.redhat.com/show_bug.cgi?id=827806 python-ttystatus - Progress and status updates on terminals for Python https://bugzilla.redhat.com/show_bug.cgi?id=827805 python-cliapp - Python framework for Unix command line programs https://bugzilla.redhat.com/show_bug.cgi?id=827804 python-coverage-test-runner - Python module for enforcing code coverage completeness https://bugzilla.redhat.com/show_bug.cgi?id=827803 I've so far tested it for local unencrypted backups -- there's a problem with Obnam's locking mechanism I've emailed Lars about, so some related test cases are disabled, and it seems that it also affects going GPG-encrypted backups. There's a Yum repository for F-17 x86_64 for your testing convenience: http://hircus.multics.org/yum-repos/obnam.repo http://hircus.multics.org/yum-repos/obnam/ As usual, please reply to the list with which package you want to review and if you want to swap with any of your own review requests. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPywf4AAoJEEr1VKujapN61HcH/Rnxed1S0n+ZOh6nTusp2Iyl 3WSZEnCUxRGEInrHRxjnnHZKz1fgGQG96lxKPAosVrO8Ll+oHldEWvuxchgg5QYt sy7yFaFImQ78Z858bdS2AyywKp3KFcingATFNHukXlwhMSYTxN74u4bgAG5uYJL0 DStqtVzExsQckJW3fAd7PvE7TWVy3ytL/O+6oRijlHGH+bpiQjrb3N6Ht007klT+ IfMz9yMcSyXtEEpUAH1jWyiZ3ZYdHTyp3GsvJr4O4hv1yMuD+Mt1uHtDMyxdiPyt BzzksfLPb6+SLYQhcXVJPgXL2nkDOxiUxc6CsF61Q7n6qTa7yRMv03qLpD6svpo= =Btyg -END PGP SIGNATURE- ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Django packages - proposed name changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2012 08:28 AM, Bohuslav Kabrda wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 18/01/12 14:01, Bohuslav Kabrda wrote: >>> It seems actually, that there are pretty straightforward >>> guidelines for renaming packages: >>> >>> http://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required >>> >>> >> >>> >>> http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages >>> >>> So if renaming, we will _have to_ re-review. Also, the >>> guidelines are pretty clear with the Provides and Obsoletes, >>> so it shouldn't really be a problem. >>> >>> Bohuslav. >>> >> OK, >> >> if renaming is consence, we should implement it right after >> branching F17 in devel-tree. >> >> Probably one should write an example .spec, especially taking >> care on sane requires, provides. >> >> Maybe we should make a wiki page to coordinate this step >> (overview, which package is required to change, which is >> changed, etc. >> >> Bohuslav, would you start such a page? We could divide up >> reviews. I would volunteer to do some reviews. >> >> Matthias > > Hi guys, so it seems that we should get this started now, when we > have plenty of time for Fedora. I was thinking about this a lot > and here is what I came up with: 1) We should create a fpc ticket, > that would summarize what we want to do, and more importantly, it > would ask fpc to add a section about Django and its plugins to > Python packaging guidelines. 2) Then, after approved by fpc, I will > create a wiki page that will hold the list of Django > plugins/extensions, that were/were not renamed. 3) Then, we should > first review python-django, which is already in work [1], but I > believe it might be a good idea to wait for the fpc approval, > before we actually approve and push it. 4) Finally, we should do > all the other packages. In case some of the packagers are not > responsive, we should have a proven packager standing by (I know > two personally, so that shouldn't be a problem). > Sounds like a good plan. I'll be travelling from Wednesday to the end of the week, and I need to bring the python-django spec that's being reviewed in sync with our latest Django package (and make some changes already mentioned in the review ticket and in Bohuslav's email), but I'll have time to do that later this week. It'd be great to have this land (mea culpa: I'm the one who originally picked 'Django' as the package name). - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPS1fiAAoJEEr1VKujapN6Fp4H/j2a76cI+qq6EzkxQRj1nHkw YCwwcLFpobAOI1cNgODZjvBwtKP9AVeRwqtonwP9KqSM3DsYY2uFzaO+kpY+iW69 hEec8Sq01xmomFrBR8RDWMohYfzii6yFjl/UCa1tM3AYDOGWXHdzc6omsnqFL7kR aex8kxnMkQuuBrwbwX7yZaLwGSP5XJPov4tH+lTp/qtr0hshs1gBNVSK0Tdx+J93 85Q3GygPhe1DsfEfW7mfe0hugzTCSd0Oc6IPYStouM5ofAuRXxTa5qWEVBeH7mpW BBfDXo2OAgDa8y4jdoGYmvjpeoDSCdj4KdxJzYavZykQndW83AhxnJb/uIVNSlw= =pD9X -END PGP SIGNATURE- ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
