Re: Failure testing duplicity 3.0.0

If this were C I would say it's an uninitialized variable. It acted like it.

I could not reproduce it on Linux.  Seems to be only on macOS.

It was just a weird error.  The patch is for 3.0.2, but should work on
3.0.0.  I'd upgrade.  There were fixes made.

...Ken


On Mon, Sep 2, 2024 at 12:32 PM Scott Hannahs <[email protected]> wrote:

> Ken,
>
> Not running under Docker.  Running native on MacOS 14.6.1 (Sonoma)
>
> The timing error was a wild guess based on "assert dup_time.curtimestr”
> line.  It is searching for a file name in the Manifest as far as I can tel
> in this test.  A one second delay should be sufficient to update the
> filename/timestamp.
>
> My test script is:
>
>         #!/bin/sh -ev
>
>         ulimit -n 8192
>
>         %p/bin/pytest-3.10 --capture=fd
>
>
> (The %p expands to /opt/sw which is where my package manager sticks
> everything instead of spewing around the file system like home-brew)
>
> It is odd that it works most of the time and then occasionally can not
> find an incremental file in the manifest.  Might be my specific setup but I
> can’t think of anything odd that I have installed that would interfere with
> duplicity.
>
> I am using pytest version 7.4.4 and have had issues trying to update to
> pytest 8.3.2.  If this is just a weird error, I will go work on updating
> pytest and duplicity to the latest and greatest.
>
> -Scott
>
>
> On Sep 2, 2024, at 12:28, Kenneth Loafman <[email protected]> wrote:
>
> Scott,
>
> Exactly how do you run your tests?  What command line?
>
> I do know that this is not a timing issue.  test_file_naming does not
> actually create files, just filenames.  The tests that do backup, etc..
> have a 1 second delay in between, so no timing issue.
>
> Are you perhaps running this under Docker?  We've had timing issues there,
> but going to the 1 second delay solved that problem years ago.
>
> ...Ken
>
>
>
> On Mon, Sep 2, 2024 at 7:23 AM Scott Hannahs via Duplicity-talk <
> [email protected]> wrote:
>
>> Ede,
>> It might be.  But it is intermittent!  The last 3 tests built without
>> errors.
>>
>> What is that test that does an assertion "assert dup_time.curtimestr”
>> It is trying to do a get of a gzipped incremental file name from the
>> manifest, but with no volume number?
>>
>> Is the machine too fast during testing that it is creating files with
>> duplicate date/time stamps?
>>
>> -Scott
>>
>>
>> > On Sep 2, 2024, at 06:36, edgar.soldin--- via Duplicity-talk <
>> [email protected]> wrote:
>> >
>> > hey Scott,
>> >
>> > looks like the brew build runs fine
>> https://formulae.brew.sh/formula/duplicity . something with your
>> specific setup?
>> >
>> > can you give more details os version etc. to the box you are building
>> on? unfortunately i can't run latest macOS versions virtually so far, so
>> it' difficult to try to reproduce.
>> >
>> > sunny regards ..ede
>> >
>> > On 02.09.2024 03:46, Scott Hannahs via Duplicity-talk wrote:
>> >> First, I get a lot of errors trying to build 3.0.2, so I will get to
>> them next.
>> >>
>> >> However I get this failure with 3.0.0.  It seems that there is an
>> issue with the time of the files?  Are they being built too quickly and the
>> timer does not have time to increment?  This doesn’t happen on every build.
>> >>
>> >>
>> >> -Scott
>> >>
>> >> testing/unit/test_file_naming.py .F.......
>>    [ 92%]
>> >> ….
>> >>
>> >> =================================== FAILURES
>> ===================================
>> >> ____________________________ FileNaming.test_suffix
>> ____________________________
>> >>
>> >> self = <testing.unit.test_file_naming.FileNaming
>> testMethod=test_suffix>
>> >>
>> >>     def test_suffix(self):
>> >>         """Test suffix (encrypt/compressed) encoding and generation"""
>> >>         file_naming.prepare_regex(force=True)
>> >>>       filename = file_naming.get("inc", manifest=1, gzipped=1)
>> >>
>> >> self       = <testing.unit.test_file_naming.FileNaming
>> testMethod=test_suffix>
>> >>
>> >>
>> /opt/sw/src/fink.build/duplicity-3.0.0-1/duplicity-rel.3.0.0/testing/unit/test_file_naming.py:102:
>> >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> _ _ _ _ _
>> >>
>> >> type = 'inc', volume_number = None, manifest = 1, encrypted = False,
>> gzipped = 1
>> >> partial = False
>> >>
>> >>     def get(
>> >>         type,
>> >>         volume_number=None,
>> >>         manifest=False,  # pylint: disable=redefined-builtin
>> >>         encrypted=False,
>> >>         gzipped=False,
>> >>         partial=False,
>> >>     ):
>> >>         """
>> >>         Return duplicity filename of specified type
>> >>
>> >>         type can be "full", "inc", "full-sig", "new-sig", "full-stat",
>> "inc-stat". volume_number
>> >>         can be given with the full and inc types.  If manifest is true
>> the
>> >>         filename is of a full or inc manifest file.
>> >>         """
>> >>>       assert dup_time.curtimestr
>> >> E       AssertionError
>> >>
>> >> encrypted  = False
>> >> gzipped    = 1
>> >> manifest   = 1
>> >> partial    = False
>> >> type       = 'inc'
>> >> volume_number = None
>> >>
>> >>
>> /opt/sw/src/fink.build/duplicity-3.0.0-1/duplicity-rel.3.0.0/duplicity/file_naming.py:253:
>> AssertionError
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>>
>
>

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