rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Version Woes


From: ewl+rdiffbackup
Subject: Re: Version Woes
Date: Fri, 17 Apr 2020 07:52:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

Hi,

and one last comment: the migration guide from Patrik is meant for big
environments where you can't upgrade all rdiff-backup installations at
once. If you have only one server and one client, you can just upgrade
rdiff-backup on both sides following the readme and you're done.

KR, Eric

On 17/04/2020 07:33, address@hidden wrote:
> Hi Brian,
> 
> thanks, that's a lot of feedback, so also a lot of feedback from me ;-)
> 
> On 17/04/2020 06:06, Brian Bouterse wrote:
>> Also the curl and run the python script to install pip method is pretty
>> official, but it's kind of scary. Instead I used the pip3 package with:
>> sudo apt install python3-pip
>> After that I could run `pip3 freeze` for example, to confirm it works
> 
> Installing from package is always better than from "random" script. If
> pip3 is packaged, we should use it.
> 
>> Instead of virtualenv I used venv which for python3 I believe is preferred
>> (I think virtualenv is deprecated). To get that installed and the venv
> 
> Don't tell this the virtualenv developers :-) (pyenv is deprecated)
> See https://virtualenv.pypa.io/en/latest/
> As virtualenv is developed by pypa and tox as well, we should continue
> to use virtualenv to get consistent results (even though venv will most
> probably work as fine for this specific use case, but not for tests).
> 
>> created I did this:
>> sudo apt-get install python3-venv
>> sudo python3 -m venv /opt/rdiff-backup2
>>
>> I did need apt install libacl1-dev, but on my system I also needed
>> librsync-dev so I installed those along with Python3 dev using
>> sudo apt install python3-dev libacl1-dev librsync-dev
>> Without librsync-dev rdiff-backup wouldn't compile, and without
>> libacl1-dev, pylibacl wouldn't compile.
>>
>> At that point this command did work:
>> sudo /opt/rdiff-backup2/bin/pip3 install rdiff-backup pyxattr pylibacl but
>> it couldn't build the wheel, it gave this error:
>>
>>   error: invalid command 'bdist_wheel'
>>
>> That was resolved with `/opt/rdiff-backup2/bin/pip3 install wheel`. After
>> that the following command completed with no errors:
> [...]
>> https://www.piwheels.org/simple/pyxattr/pyxattr-0.7.1-cp35-cp35m-linux_armv7l.whl
> 
> Yes, your issues were mainly because you have a non-x86 platform. I'm
> not sure which version of the docs you used, but Patrik has very
> recently added the dependency to librsync-dev in such cases, but only in
> the README file. Perhaps we should also explicitly list ARM and/or Raspi
> to make it clearer.
> 
> Side note: https://docs.travis-ci.com/user/multi-cpu-architectures/ - we
> could also build arm64 images using Travis...
> 
> We definitely missed the wheel dependency and it should be added.
> 
>> Your symlink instructions to put it onto my path worked and my local 1.9.0
>> client (Fedora) successfully backed up my pypi based Debian install (2.0.0).
> 
> Why are you using 1.9.0 on Fedora? The COPR repo from Frank and PyPI
> should provide 2.0.0, and 1.9.0 is the beta of 2.0.0. I'm also on Fedora
> and use 2.0.0 without issue.
> 
>> Do you want any of this sent to you as a PR to your guide? Or maybe the
>> centos instructions too? What repo and branch is the best to open the PR
>> against? Also what version formally because the Python3 version?
> 
> As Patrik is still working on the migration guide [314], you should make
> it out with him, but in general, we develop from master and there is
> only one repo, and a developer's guide [1].
> 
> KR, Eric
> 
> [314] https://github.com/rdiff-backup/rdiff-backup/pull/314
> [1] https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/DEVELOP.md
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]