Dear maintainers, Dominik,
With a recent upload of freezegun the autopkgtest of cached-property
fails in testing when that autopkgtest is run with the binary packages
of freezegun from unstable. It passes when run with only packages from
testing. In tabular form:
pass fail
freezegun from testing 0.3.11-0.1
cached-property from testing 1.5.1-2
all others from testing from testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of freezegun to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package? If needed, please change the
bug's severity.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=freezegun
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cached-property/2001918/log.gz
======================================================================
FAIL: test_threads_ttl_expiry
(tests.test_cached_property.TestCachedPropertyWithTTL)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.kwqe3o55/downtmp/autopkgtest_tmp/tests/test_cached_property.py",
line 207, in test_threads_ttl_expiry
self.assert_cached(check, 2 * num_threads)
File
"/tmp/autopkgtest-lxc.kwqe3o55/downtmp/autopkgtest_tmp/tests/test_cached_property.py",
line 69, in assert_cached
self.assertEqual(check.add_cached, expected)
AssertionError: 6 != 10
Hi Paul, hi all, Since cached_property tested well for weeks with the previous freezegun version (now in testing) and a short look at the sources of freezegun showed substantial changes in the API for the last version I guess this issue is indeed caused by a bug or incompatible API change in freezegun. I don't see how anything could be done from the side of cached_property at this stage of the freeze. Therefore I am bumping the bug to severity serious to be safe this version of freezegun will not migrate to testing and assigning to freezegun. Cheers Mathias
Hi all, On Wed, 27 Feb 2019 00:38:16 +0100 Mathias Behrle <mbehrle@debian.org> wrote:> I don't see how Keeping this version of freezegun out of buster for this is trading one RC bug versus another. Mathias, could you please check if you can make cached_property compatible with the current freezegun in unstable, as that means we could move things forward. Dominik, did you investigate if a different solution for the FTBFS of freezegun in bug 916702 [1] was possible? Federico, I would appreciate it when you would share your opinion on how to solve the freezegun situation for buster. Time is ticking. Paul [1] https://bugs.debian.org/916702
* Paul Gevers: " Fwd: Bug#923282: freezegun breaks cached-property autopkgtest" (Tue, 12 Mar 2019 21:51:28 +0100): Hi all, My research shows that the issue is known for cached_property since 5 Nov 2018 [1], related issues for freezegun date from 21 Oct 2018 [2] resp. 17 Oct 2018 [3]. Indeed freezegun obviously introduced substantial API changes from 0.3.10 to 0.3.11 (btw in no way following semver). What can be done in the current situation: 1) I really don't see what can be done on the side of cached_property. No solution so far was able to workaround the test failures acording to [1]. If there is any input from the freezegun maintainers how the tests could be changed to pass I am all open for it. 2) freezegun 0.3.11 was released on 15 Oct 2018 [4] and there seem to be some more recent commits related to this issue (e.g. [5]). I would propose to cherry-pick some relevant commits or to package current trunk from git to see if it solves the issues. 3) As a last resort the release team should be involved to evtl. mark the issue as ignore for buster. 4) If that should be impossible/not desired I would be willing as a very very last resort to disable temporarily the relevant autopkgtests in cached_property. Basically cached_property *is* and *was* working, it is only that the tests are failing due to API incompatibilities introduced by a test utility (freezegun) during or shortly before the soft freeze. My personal preference obviously goes to 1) or 2). Please advise on how to proceed further. Mathias [1] https://github.com/pydanny/cached-property/issues/131 [2] https://github.com/ktosiek/pytest-freezegun/issues/6 [3] https://github.com/spulec/freezegun/issues/269 [4] https://pypi.org/project/freezegun/#history [5] https://github.com/spulec/freezegun/commit/028dee229f06d200d0f79a130deaad65b14779ef
Hi Mathias, Do I understand you correctly that there is no issue at all for the package cached-property as used by our users? Paul
* Paul Gevers: " Re: Bug#923282: freezegun breaks cached-property autopkgtest" (Thu, 14 Mar 2019 11:55:47 +0100): Dear Paul, I must admit that I find it a little bit strange to have no feedback at all from the freezegun maintainers about this issue. Especially not for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923282#34 for the question, if not some more recent unreleased commits in git of freezegun could sanitize the situation. So I am taking this as an approval from the side of the release team to upload to unstable. Do you expect me to file an unblock bug for this or will you handle it yourself on behalf of the release team? Of course, done. Mathias
Hi Mathias, Full ack. Yes, please upload to unstable, with only the test disabled, and I'll take care of it. Thanks for understanding. Paul
* Paul Gevers: " Re: Bug#923282: freezegun breaks cached-property autopkgtest" (Thu, 14 Mar 2019 12:19:03 +0100): Hi Paul, You are welcome, thanks for the work of the release team. I just uploaded. Mathias
Hi Mathias, I was more thinking of only disabling the broken test_threads_ttl_expiry instead of everything. Unblocked nevertheless as this was on my request, but don't hesitate to "fix" this less invasive. Paul