Re: Exception during duplicity testing

As to temp files left over, that's going to happen anytime duplicity
fails.  In testing it's forced to fail a lot.

I need a log.  Could you run the tests that cause this to a log, then gzip
and attach it to your reply.  Do NOT edit the log.

$ pytest >& /tmp/pytest.log
$ gzip /tmp/test.log

then attach /tmp/pytest.log.gz

...Ken


On Tue, Sep 10, 2024 at 8:50 AM Kenneth Loafman <[email protected]> wrote:

> Ok, I'll take a look.
>
> ...Ken
>
> On Sun, Sep 8, 2024 at 8:36 PM Scott Hannahs <[email protected]> wrote:
>
>> Ken,
>>
>> The package manager has updated pytest to 7.4.4 at the moment.  I think
>> this makes the errors between duplicity 3.0.0 and 3.0.2 more consistent.
>> However running the tests leaves about 50 files in the temporary
>> /var/folders directory.  Manually removing those files seems to avoid
>> differences.
>>
>> I realize that it works on your system and I am trying to figure out what
>> is different in my setup which is running the tests in a different file
>> structure and locations which shouldn’t matter.
>>
>> After a reboot into recovery mode and cleanup of the /var/folder
>> directory of temporary files.  It now technically passes all the tests.
>> However after the tests, the cleanup function fails with the following
>> message:
>>
>> Exception ignored in: <function TemporaryDirectory.__del__ at 0x10ee8e290>
>> Traceback (most recent call last):
>>   File
>> "/opt/sw/src/fink.build/duplicity-3.0.2-1/duplicity-rel.3.0.2/duplicity/tempdir.py",
>> line 180, in __del__
>>   File
>> "/opt/sw/src/fink.build/duplicity-3.0.2-1/duplicity-rel.3.0.2/duplicity/tempdir.py",
>> line 284, in cleanup
>> NameError: name '_' is not defined
>>
>>
>> I assume this is the problem with cleaning up the recovery files?  There
>> are again about 100 files in my /var/folders hierarchy that have duplicity
>> as part of their name.
>>
>> -Scott
>>
>> On Sep 7, 2024, at 2:41 PM, Kenneth Loafman <[email protected]> wrote:
>>
>> Scott,
>>
>> Are you still having problems?  I just do not see it.  curtimestr is set
>> for all tests that need to be done.  duplicity/dup_time.py is just a
>> collection of time munging functions.
>>
>> ...Ken
>>
>>
>> On Sat, Sep 7, 2024 at 12:47 PM Scott Hannahs <[email protected]> wrote:
>>
>>> Ken,
>>>
>>> Of course, but the point was that the testing module does not seem to
>>> set it and thus fails when it does an assert on “curtimestr”.  This of
>>> course fails.
>>>
>>> Should the test call dup_time.setcurtime() before the assert?  On all
>>> platforms?  That would be the call that I was guessing was missing.  The
>>> test module for
>>> "testing/unit/test_collections.py::CollectionTest::test_collections_status”
>>> should set the current time in the test routine?
>>>
>>> -Scott
>>>
>>> On Sep 6, 2024, at 14:14, Kenneth Loafman via Duplicity-talk <
>>> [email protected]> wrote:
>>>
>>> This is the way it works, like it should, in all versions.
>>>
>>> dup_time.curtimestr is not set until dup_time.setcurtime() is called.
>>> Just importing the module will not set it.
>>>
>>> ...Ken
>>>
>>> On Fri, Sep 6, 2024 at 12:42 PM Scott Hannahs via Duplicity-talk <
>>> [email protected]> wrote:
>>>
>>>> Just to finish up on this (duplicity 3.0.0)
>>>> The test that fails seems to be:
>>>>
>>>> If I run pythion3.10 manually and use the following commands, this is
>>>> the result:
>>>>
>>>> % python3.10
>>>> Python 3.10.4 (main, Jul  1 2023, 16:39:08) [Clang 14.0.3
>>>> (clang-1403.0.22.14.1)] on darwin
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> from duplicity import dup_time
>>>> >>> assert dup_time.curtimestr
>>>> Traceback (most recent call last):
>>>>   File "<stdin>", line 1, in <module>
>>>> AssertionError
>>>> >>> print(dup_time.curtimestr)
>>>> None
>>>>
>>>> Am I reading this wrong or is something missing in the duplicity time
>>>> function?  Does it need an initialization call to initialize the global
>>>> curtimestr?
>>>>
>>>> NB: (I seem to get that same error under duplicity version 3.0.2)
>>>>
>>>> -Scott
>>>>
>>>>
>>>> On Aug 22, 2024, at 7:48 PM, Scott Hannahs <[email protected]> wrote:
>>>>
>>>> Thomas,
>>>>
>>>> Perfect.  I will try that.  Not looking to be a python expert by any
>>>> means.  Not my favorite language.  But thanks for the pointer.
>>>>
>>>> If I need more I will RTFM.
>>>>
>>>> -Scott
>>>>
>>>>
>>>> On Aug 22, 2024, at 5:11 PM, Thomas Laubrock <[email protected]>
>>>> wrote:
>>>>
>>>> Hi Scott,
>>>>
>>>> this is pretty easy. Simply add the folder or path to a test e.g.:
>>>>
>>>> `pytest testing/functional/`
>>>>
>>>> `pytest testing/unit/test_collections.py`
>>>>
>>>> You can even address a specific test:
>>>>
>>>> `pytest
>>>> testing/unit/test_collections.py::CollectionTest::test_collections_status`
>>>>
>>>> Bye
>>>>
>>>>   Thomas
>>>>
>>>> There are good pytest docs out there if you looking for more.
>>>>
>>>>
>>>> On 22.08.24 02:36, Scott Hannahs wrote:
>>>>
>>>> Thomas,
>>>>
>>>> I don’t know how to connect it to a specific test.  I take it this is not something others see when running the complete test suite.  I’ll just put it down to weirdness.  It may be something in how the backends shutdown during a test?  Maybe it is the exact version of the backends that I have?  Since the test does not list as a failure I am going to just move on.
>>>>
>>>> -Scott
>>>>
>>>>
>>>> On Aug 21, 2024, at 6:01 PM, Thomas Laubrock via Duplicity-talk <[email protected]> <[email protected]> wrote:
>>>>
>>>> Hi Scott,
>>>>
>>>> On 21.08.24 18:02, Scott Hannahs via Duplicity-talk wrote:
>>>>
>>>> Ok, I will look for that.  But I still don’t know where the “ignored exception” comes from.   At the moment I am ignoring that ignored exception and will continue to do so.  Just thought it may indicate some other hidden issue.  If it was a big problem I expect that it would have an “f” in the test list and show as a failed test.  I think it is just text that went from python to the std err output.
>>>>
>>>> “ignored exception” comes from the python interpreter if the exception is raised late in the shutdown process that it can't be handled any more.
>>>>
>>>> Are you able to trace this down to a specific test?
>>>>
>>>> At the end this doesn't necessarily mean that this is an issue in duplicity or the test itself, because it could be triggered intentionally while creating an intentional error case.
>>>>
>>>> Bye
>>>>
>>>>   Thomas
>>>>
>>>>
>>>> _______________________________________________
>>>> Duplicity-talk mailing [email protected]://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Duplicity-talk mailing list
>>>> [email protected]
>>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> [email protected]
>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>>
>>>
>>

_______________________________________________
Duplicity-talk mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk