Re: django-pytest vs pytest-django

> "DM" == David Moreau-Simard writes: DM> I don't have the bandwidth to take care of pytest-django right now. DM> Would it be acceptable to propose a new package without %check until DM> it gets packaged ? It's OK to disable tests you can't run because they have additional dependencies

Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

> "MH" == Miro Hrončok writes: MH> Are my assumptions correct? Yes, unless some major changes happened of which I was not aware, you cannot have any package name in EPEL7 (including a source package) which duplicates a package name in RHEL7 _on a particular architecture_. (There are

Re: Removal of Python 2 from the Xfce spin

> "MH" == Miro Hrončok writes: MH> Aaaand... it's reverted :D He reverts any of the commits I have made to the packages he maintains as well. Just mass cleanup things like the removal of defattr. Reverted with a completely empty commit message. I really don't want to get into a revert war

Re: [EPEL-devel] Moving EPEL7 to python3.6

> "NG" == Neal Gompa writes: NG> Wait, we can do that? I thought we couldn't use the exception NG> process for this? Well, the idea is that you don't need a separate review just to import a different version of the same package. So foo and foo1.2 (the 1.2 version) or python-abc and

Re: [EPEL-devel] Moving EPEL7 to python3.6

> "OP" == Orion Poplawski writes: OP> - Can we make epel7-py36 branches, and somehow have OP> %python3_version, et. al. be 3.6 for those builds? I can't think of any way to do that without extra magic. And if you require something in the spec, you might as well just hardcode it. OP> - Can

Re: Python 2 Package Removal and when to use fedora-obsolete-packages

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> Heh, I don't think the FPC policy is very robust. It's as robust as is reasonable to implement. When fedora-obsolete-packages was introduced, there was considerable controversy over whether it is remotely acceptable to remove installed

Re: What is the criterion for Python 3.7 side tag merge?

> "MH" == Miro Hrončok writes: MH> What is the criterion to merge the side tag? I think ultimately that's up to you, but certainly the idea is to balance disruption (breaking builds or rawhide usability) against holding back progress (the approved python 3.7 feature). It would certainly be

Re: Draft: Macros to tell what Python versions to package for

> "MH" == Miro Hrončok writes: MH> I expect it to be called for both 2 and 3 unconditionally. Hiding MH> the condition in the maro makes things too magical for me. I don't think that stance holds up well as we increasingly hide things in macros and will continue to hide

Re: Draft: Macros to tell what Python versions to package for

> "PV" == Petr Viktorin writes: PV> %install PV> %install PV> %if %{with python2} PV> %py2_install PV> %endif PV> %if %{with python3} PV> %py3_install PV> %endif So... why not just make %py2_install and %py3_install just do the %{with python*} internally, so the

Python2 stub packages now in EPEL stable

[For those who don't read epel-devel, this is a duplicate of a message also posted there.] The initial set of stub python2-* packages I created have now made their way to EPEL6 and EPEL7 stable, so packages can now depend on python2-setuptools, python2-six, python2-pytest and python2-sphinx in

Re: flit

> "TK" == Toshio Kuratomi writes: TK> However, you should check with tibbs/FPC about TK> whether the definitions/list of macros are an altogether dated TK> concept. I think it's reasonable to document macros which are going to need to use. Python packaging just isn't

Re: Finalizing Fedora's Switch to Python 3

> "MH" == Miro Hrončok writes: MH> I just had a discussion with Tomáš Orsava and Petr Viktorin on MH> #fedora-python. Rather than asking FESCo now to allow mass MH> fully-automated spec changing, we'll open bugs as planned, but we'll MH> attach patches generated by your

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

> "IS" == Iryna Shcherbina writes: IS> Thanks a lot, that is helpful. There is also a pkgdb2client [0] IS> package that I've been looking into for this. You could run that tool in a loop, parse the result and generate the report, I guess, but it's also rather trivial to

Re: python34 for EPEL6

> "AL" == Avram Lubkin writes: AL> I'm curious if anyone else has any insight. Maybe it is worth AL> bringing up at a FPC meeting. That would more appropriately be a topic of an EPEL meeting, since this is purely an EPEL policy issue. - J<

Re: python34 for EPEL6

> "AL" == Avram Lubkin writes: AL> Definitely, but it runs into the same problem as 3.4 on EL7, the AL> fact that there are few packages available and adding them when the AL> package already exists in RHEL requires creating a separate parent AL> package in Fedora

Re: Automatic Provides: Discussion summary and plan

> "PV" == Petr Viktorin writes: PV> - Make it standard practice in Fedora to use this data and treat the PV> spec file as an immutable generated artifact. If you're saying that any changes which are made to the spec file (say, by release engineering doing a rebuild or

Re: Automatic Provides: Discussion summary and plan

> "TO" == Tomas Orsava writes: TO> That looks incredible! Why didn't it see the light of day? Time TO> constraints or some technical issues? Well, it sort of fell by the wayside as I got involved with other things. I've learned a lot about RPM internals since then and I

Re: Automatic Provides: Discussion summary and plan

> "PV" == Petr Viktorin writes: PV> No, getting. Example expansion: PV> %{python_dist_name ndg_HTTPSclient} => ndg-httpsclient Ah, OK, that makes much more sense. PV> Would "python3_requires" and "python3_buildrequires" be better? I think so. PV> Please do and share

Re: Automatic Provides: Discussion summary and plan

> "PV" == Petr Viktorin writes: PV> * One macro for getting the canonical (normalized) dist-name: PV> %{python_dist_name NAME} Do you mean "setting" here? PV> * Four macros for adding Requires and BuildRequires lines (which use PV> the python_dist_name macro

Re: Problems with script installation in RPM's

> "PV" == Petr Viktorin writes: PV> Unfortunately, changing the Guidelines isn't trivial – we have a PV> ticket that's been sitting in FPC's queue for half a year [1]... Thanks for the snark. Nobody has submitted a draft and that ticket isn't particularly urgent

Re: [EPEL-devel] Re: Which python3 versions to package for EPEL7?

> "TK" == Toshio Kuratomi writes: TK> We would have been in a lot better place today if we had separate TK> packaging of python2 and python3 packages in Fedora so that they TK> were never in sync there but that's not something we can probably TK> change now Nothing

Re: Mention dist-info files in the packaging policy?

> "NC" == Nick Coghlan writes: NC> I just noticed that the packaging policy doesn't currently mention NC> dist-info directories, only the older egg-info: NC> https://fedoraproject.org/wiki/Packaging:Python#Files_to_include dist-info is completely new to me. I never

Re: macros.python2 requires update in F21+

> "H" == Haïkel writes: H> Hi, Nobody answered, should I assume that everyone is ok with me H> pushing Orion's patches in F21 and F22? I'm for whatever works, but I should ask if there's any possibility of getting these macros out of the main python package and

Re: Python guidelines cleanup

ZJ == Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: ZJ There's a dead link in Example common spec file. Oops, missed a colon. Fixed, thanks. ZJ I wrote that. I turns out, which I didn't know at the time, that ZJ this is only true for binary modules (for example python-systemd has ZJ

Re: Python guidelines cleanup

Also, When using the python_provide macro as detailed in the guidelines, I can't seem to get fedpkg to generate an srpm: fedpkg srpm error: line 36: Unknown tag: ERROR: not recognized. error: query of specfile /home/tibbs/work/fpkg/python-requests/python-requests.spec failed, can't parse That

Re: Python guidelines cleanup

JLT == Jason L Tibbitts ti...@math.uh.edu writes: JLT Also, When using the python_provide macro as detailed in the JLT guidelines, I can't seem to get fedpkg to generate an srpm: OK, I think a question mark somehow got converted to a % in the draft. %{?python_provide:%python_provide

Re: Python guidelines cleanup

MH == Miro Hrončok mhron...@redhat.com writes: MH * in example spec, you mix srcname and pypi_name macros Yeah, fixed that up. MH * For example, the python 3 version of coverage must ship MHexecutables MH /usr/bin/coverage, /usr/bin/coverage-2 and /usr/bin/coverage-2.7, MH while the

Re: Python guidelines cleanup

After some additional discussion and cleanup, I've gone ahead and moved my drafts into place in the main guidelines. Please let me know if I've made any mistakes or typos or left out anything important. However, there is one thing I'm trying to understand about the new guidelines (which came

Re: fedora wikipage Packaging:Python

MB == Martin Bukatovič martin.bukato...@gmail.com writes: MB The page doesn't discuss much any differences in guidelines for MB packages of python modules, python applications and when python MB project provides both. It shouldn't really need to; the question isn't specific to python at all.

Proposal to require python3-supporting modules to be packaged for python3

I've not posted here before, but I've been becoming more familiar with python and have been doing some work on the various guidelines in my capacity as an FPC member. I was kind of surprised that with the push for python 3 as default we don't actually have a guideline that modules supporting