Re: Intent to orphan Python 2

2018-03-23 Thread John Dulaney
On Màrt 23, 2018 aig 03:43:13f +, Toshio Kuratomi sgrìobh: > Depends on what the groups of packagers want... A macro for Django would > definitely have given an easy option for packagers to take advantage of. > Otoh, how far in advance was the Django removal telegraphed and how much > chance wa

Re: Intent to orphan Python 2

2018-03-22 Thread John Dulaney
> If you are a maintainer of anything at [1] we ask you kindly to consider > removing the python2 subpackages. > You can either do it now in Rawhide, or add a conditional for Fedora > 29. > (On the current schedule, Fedora 30 will be the first release still > supported after 2020-01-01.) I notice

Re: openSUSE Python packaging and Fedora

2017-03-13 Thread John Dulaney
Hi. Do you think it would be a good thing to sit down and compare existing macros and create a wiki page or similar listing opensuse's and fedora's macros with the ones that do the same thing side by side? It would be nice to hash out a unified set of macros, for sure. John. ___

Re: Tackling cert bundling with install-time symlink maps?

2016-12-23 Thread John Dulaney
On Fri, Dec 23, 2016 at 05:37:51PM +1000, Nick Coghlan wrote: > I filed that idea on the pip issue tracker at > https://github.com/pypa/pip/issues/4197 but figured I should raise it here > as well, as if something like this was added, then Fedora could be updated > to use a standard symlink map w

Re: Python Patch List

2016-08-08 Thread John Dulaney
On Mon, Aug 08, 2016 at 05:19:44PM +0200, Petr Viktorin wrote: > Hello, > We have a policy that patches for the same issue in the python and > python3 packages should share the same number. This informally > extends to EL and other derived distros, so the number of spec files > to keep in sync grow

Re: RFC: Using the new optional python module dependency generator in Fedora

2016-04-13 Thread John Dulaney
> I'm not sure. Historically, dependency generators of this kind don't > include the architecture information because of the issues related to > determining whether a package is a noarch package or an archful > package (or if it needs to transition from one to the other). It's > somewhat easier to