hypothesis bug

Got:

+ /usr/bin/python2 -m pytest
============================= test session starts ==============================
platform linux2 -- Python 2.7.16, pytest-4.4.1, py-1.8.0, pluggy-0.11.0
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/builddir/build/BUILD/priority-1.3.0/.hypothesis/examples')
rootdir: /builddir/build/BUILD/priority-1.3.0
plugins: hypothesis-4.23.4
collected 162 items

test/test_priority.py .................................................. [ 30%]
........................................................................ [ 75%]
......................................F.                                 [100%]

=================================== FAILURES ===================================
_______________ TestPriorityTreeOutput.test_period_of_repetition _______________

self = <test_priority.TestPriorityTreeOutput object at 0x7fef65fd8150>

    @given(STREAMS_AND_WEIGHTS)
>   def test_period_of_repetition(self, streams_and_weights):
        """
        The period of repetition of a priority sequence is given by the sum of
        the weights of the streams. Once that many values have been pulled out
        the sequence repeats identically.

test/test_priority.py:492: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python2.7/site-packages/hypothesis/core.py:600: in execute
    % (test.__name__, text_repr[0])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <hypothesis.core.StateForActualGivenExecution object at 0x7fef65fd8510>
message = 'Hypothesis test_period_of_repetition(self=<test_priority.TestPriorityTreeOutput at 0x7fef65fd8150>, streams_and_weigh...70),\n (1, 94),\n (35, 236)]) produces unreliable results: Falsified on the first call but did not on a subsequent one'

    def __flaky(self, message):
        if len(self.falsifying_examples) <= 1:
>           raise Flaky(message)
E           Flaky: Hypothesis test_period_of_repetition(self=<test_priority.TestPriorityTreeOutput at 0x7fef65fd8150>, streams_and_weights=[(2, 228),
E            (9, 251),
E            (58, 45),
E            (107, 67),
E            (4, 204),
E            (257, 105),
E            (46, 170),
E            (1, 94),
E            (35, 236)]) produces unreliable results: Falsified on the first call but did not on a subsequent one

/usr/lib/python2.7/site-packages/hypothesis/core.py:770: Flaky
---------------------------------- Hypothesis ----------------------------------
Falsifying example: test_period_of_repetition(self=<test_priority.TestPriorityTreeOutput at 0x7fef65fd8150>, streams_and_weights=[(2, 228),
 (9, 251),
 (58, 45),
 (107, 67),
 (4, 204),
 (257, 105),
 (46, 170),
 (1, 94),
 (35, 236)])
Unreliable test timings! On an initial run, this test took 270.63ms, which exceeded the deadline of 200.00ms, but on a subsequent run it took 196.96 ms, which did not. If you expect this sort of variability in your test timings, consider turning deadlines off for this test by setting deadline=None.

You can reproduce this example by temporarily adding @reproduce_failure('4.23.4', 'AHQAAALjQQAAEfoBAAByLAEAANVCAQAABssBBBYCAGgBAABbqQEABABdAQAAAAEAD0XrAA==') as a decorator on your test case
==================== 1 failed, 161 passed in 806.56 seconds ====================


I think I can try to build this package until it does, but it would be better to remove this check.

The package built.

*** Bug 1717663 has been marked as a duplicate of this bug. ***

It now gives me almost constant failures in Copr. Shall we report to upstream and skip it?

https://src.fedoraproject.org/rpms/python-priority/pull-request/1

This might not be enough, the build is still quite flaky :(

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

The coordinated rebuild of Python 3.8 has started in the `f32-python` side tag.

If you figure out how to rebuild this package, please don't rebuild it in regular rawhide, but use the side tag instead:

    on branch master:
    $ fedpkg build --target=f32-python

To wait for a build to show up in the side tag, do:

    $ koji wait-repo f32-python --build=<nvr>

Where <nvr> is name-version-release of the source package, e.g. python-foo-1.1-2.fc32.

An updated mock config is posted at:
http://copr.fedorainfracloud.org/coprs/g/python/python3.8/

Note that it will take a while before the essential packages are rebuilt, so don't expect all your dependencies to be available right away.

Thanks. Let us know if you need up to date info, or if you have any questions.



PS this message is mass posted to all the bugs that block the PYTHON38 bug. If this is also a Fedora 31 FTBFS bug and you manage to fix it, you can do a f31 build as usual:

    on branch f31:
    $ fedpkg build

The f32-python side tag has been merged. In order to rebuild the package, do it in regular rawhide, but please wait until python3-3.8 is tagged:

  $ koji wait-repo f32-build --build python3-3.8.0~b3-3.fc32


If your built already started in f32-python, after it is finished, please tag it to rawhide with:

  $ koji tag-build f32-pending <nvr>

For example:

  $ koji tag-build f32-pending libreoffice-6.3.0.4-3.fc32

Thanks!

(This comment is mass posted to all bugzillas blocking the PYTHON38 tracking bug.)

(Python 3.8 has landed in the rawhide buildroot.)

This was rebuild with Python 3.8 and I'm closing it in bulk.

In case you wanted to keep this bugzilla open because the fix is not ideal, please reopen. Thanks.