Re: [Duplicity-talk] librsync failure

[edgar . soldin]

On 01.05.2015 06:02, Ken Bass wrote:
> I am not following your reply, did you read my entire message? 

yes

>I pointed out the exact bug # where this was fixed, so I obviously researched 
>the archives before posting. From that research the fix appears to have been 
>implemented in a backwards compatible way that could be applied to the 0.6 
>tree. (not to mention it appears to be only 3 lines of code).

ok, wasn't on the ml but in the launchpad answer tracker under an unrelated 
subject
 
https://answers.launchpad.net/duplicity/+question/264557#yui_3_10_3_1_1430471616015_400

> 
> As far as rereading the website, it says 0.6.25 release will continue to 
> receive critical bug fixes. 

"to support distributions with long term support" .. is this your case? what's 
your distro that switches out librsync with legacy incompatible API changed 
newer version?
also
"0.6.25 release is the last release of the series that will receive new 
additions or enhancements." .. supporting a new library version sounds like an 
enhancement to me.

>The librsync change was due to a security issue so it would be reasonable for 
>someone to ask if that will be backported/fixed in 0.6.25.

nope, it was because they changed their API
 https://bugs.launchpad.net/duplicity/+bug/1416344
 
> And my other question was asking if 0.7.02 is ready for production use so I 
> know what my options are here.

no guarantee but it should. try it and decide for yourself. it's based in 0.6.x 
anyway but has some major changes that can be found in
 http://duplicity.nongnu.org/CHANGELOG

..ede/duply.net
 
> On 4/30/2015 7:53 PM, address@hidden wrote:
>> reread http://duplicity.nongnu.org/
>>
>> "
>> Please NOTE: The 0.6 series is in the process of being deprecated and the 
>> 0.6.25 release is the last release of the series that will receive new 
>> additions or enhancements. It will continue to receive critical bug fixes to 
>> support distributions with long term support. The major focus of development 
>> will be on the 0.7 series.
>> "
>>
>> also check the mailing list archive.
>>   http://lists.nongnu.org/archive/html/duplicity-talk/
>> the issue came up before and was solved.
>>
>> ..ede/duply.net
>>
>> On April 30, 2015 11:51:25 PM GMT+02:00, Ken Bass <address@hidden> wrote:
>>> I updated my Centos 7 server yesterday which updated the system
>>> librsync
>>> and librsync-devel packages to librsync-1.0.0-1.el7.x86_64 and
>>> librsync-devel-1.0.0-1.el7.x86_64.
>>> I noticed since that time duplicity no longer runs.
>>>
>>> Traceback (most recent call last):
>>>    File "/usr/local/bin/duplicity", line 41, in <module>
>>>      from duplicity import collections
>>> File
>>> "/usr/local/lib64/python2.7/site-packages/duplicity/collections.py",
>>> line 30, in <module>
>>>      from duplicity import path
>>> File "/usr/local/lib64/python2.7/site-packages/duplicity/path.py", line
>>> 36, in <module>
>>>      from duplicity import librsync
>>> File "/usr/local/lib64/python2.7/site-packages/duplicity/librsync.py",
>>> line 29, in <module>
>>>      import _librsync
>>> ImportError: librsync.so.1: cannot open shared object file: No such
>>> file or directory
>>>
>>> I am running 0.6.24, but just to be sure, I downloaded the 0.6.25
>>> tarball. And when I try to compile it:
>>>
>>>
>>> building 'duplicity._librsync' extension
>>> creating build/temp.linux-x86_64-2.7
>>> creating build/temp.linux-x86_64-2.7/duplicity
>>> gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
>>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
>>> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
>>> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
>>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
>>> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
>>> -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python2.7 -c
>>> duplicity/_librsyncmodule.c -o
>>> build/temp.linux-x86_64-2.7/duplicity/_librsyncmodule.o
>>> duplicity/_librsyncmodule.c: In function ‘_librsync_new_sigmaker’:
>>> duplicity/_librsyncmodule.c:71:38: error: ‘RS_DEFAULT_STRONG_LEN’
>>> undeclared (first use in this function)
>>>                                (size_t)RS_DEFAULT_STRONG_LEN);
>>>                                        ^
>>> duplicity/_librsyncmodule.c:71:38: note: each undeclared identifier is
>>> reported only once for each function it appears in
>>> duplicity/_librsyncmodule.c:71:30: error: too few arguments to function
>>>
>>> ‘rs_sig_begin’
>>>                                (size_t)RS_DEFAULT_STRONG_LEN);
>>>                                ^
>>> In file included from duplicity/_librsyncmodule.c:26:0:
>>> /usr/include/librsync.h:370:11: note: declared here
>>>   rs_job_t *rs_sig_begin(size_t new_block_len,
>>>             ^
>>> error: command 'gcc' failed with exit status 1
>>>
>>> I do notice in the Changelog that v0.7.02 (2015/03/10) lists "Fix
>>> _librsyncmodule.c compilation, bug 1416344, thanks to Kari Hautio."
>>> So this means I am forced to upgrade to 0.7.02? The website said 0.6
>>> series was being maintained and I got the impression that 0.7 was a
>>> development version not ready for production. Is 0.7 safe to use? If
>>> not, is the librsync fix going to be applied to the 0.6 series.
>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk