python-flake8 package not available in F30

I have a slightly different packaging issue with the repository structure
(similar state on both COPR an Koji).

In epel7, f28, and f29 i can use the line:
BuildRequires: python-flake8

However this package is not available on f30 servers:
Koji ref: <a href="" title=""></a>

I realize f30 is in rawhide state right now, so i wasn't sure if this is
the right forum for this question or if i should just wait?



Re: python-flake8 package not available in F30

By Tomasz Torcz at 03/09/2019 - 10:33

On Sat, Mar 09, 2019 at 09:26:49AM -0500, Chris wrote:
This is available both in F30:
<a href="" title=""></a>

and in Rawhide:
<a href="" title=""></a>

Note that the name of a package is python3-flake8 – we are removing
python2 from Fedora.

Rawhide is f31 at the moment. F30 is in beta freeze.

Re: python-flake8 package not available in F30

By =?UTF-8?B?TWlyb... at 03/09/2019 - 10:33

On 09. 03. 19 15:26, Chris wrote:
python-flake8 was provided by python2-flake8, python2-flake8 was removed from
rawhide and f30.

Why do you need to BuildRequire a linting tool? What are you trying to achieve?

Re: python-flake8 package not available in F30

By Chris at 03/09/2019 - 14:33

Thank you both for your fast reply!

I just use python-flake8 as an OCD way of having my build fail if i fail
pep8 :) It's just used in conjunction of my unit tests.

I should have clued in that Python 2 support is dropped; my bad. I updated
my spec to accommodate the fact Python v2 isn't always available and f30
builds great now.

Thank you!

Don't lint in %check (Was: python-flake8 package not available i

By Petr Viktorin at 03/11/2019 - 05:59

On 3/9/19 7:33 PM, Chris wrote:
Running a linter is fine upstream, but I'll argue that you'll be much
better off disabling it for the distro build.

Newer versions of flake8 can cause your tests to suddenly fail. We've
seen that happen relatively often -- style standards themselves evolve,
and the way they're codified in automatic tools evolves.

Upstream, please do check code style or unused imports if that's your
thing. But after you cut a release (on GitHub/PyPI), linting the code
doesn't really bring any benefit. (Unlike running the test suite, of

Even if you're currently maintaining this both upstream and in Fedora,
and have the energy to watch for & fix any failures, after some years
you might want to pass the package on to someone else. Be nice to your
successor. And be nice your potential Debian (et al.) maintainers by
making your specfile show how to package for a distro :)

(Note: AFAIK this is not official Fedora policy; please

Re: Don't lint in %check (Was: python-flake8 package not availab

By Chris at 03/11/2019 - 08:37


I'll take this portion out. :)


On Mon., Mar. 11, 2019, 6:00 a.m. Petr Viktorin, < ... at redhat dot com>

Re: Don't lint in %check (Was: python-flake8 package not availab

By Dridi Boukelmoune at 03/11/2019 - 08:34

On Mon, Mar 11, 2019 at 11:00 AM Petr Viktorin < ... at redhat dot com> wrote:
If upstream takes <insert linter here> seriously, and the package
maintainer does too, then following our First principle I would argue
it's fine to get an FTBFS as a result of an <insert linter here>
update iff the package maintainer is willing to patch their package
and upstream the patch.

But a release should be definitive, a "linter" bug is like any other
bug, it can be patched downstream and fixed in the next release.

As package maintainers we are supposed to stay in touch with upstream
projects, so letting them know about changes in <insert linter here>
should be part of that relationship.

Same for me, just my personal opinion full of ifs :)