Version Woes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Version Woes

Brian Bouterse
I use rdiff-backup and love it, but I'm challenged by what I think is a
version mismatch issue.

My central rdiff-backup server has version 1.9.1b0. Now I need to backup a
Debian system and this system and even the latest (
https://packages.debian.org/buster/rdiff-backup ) uses 1.2.8-7.

When I attempt to run the test command:   `rdiff-backup --test-server
example.com::/ignore` I get the error:

Couldn't start up the remote connection by executing

    ssh -C example.com rdiff-backup --server

Remember that, under the default settings, rdiff-backup must be
installed in the PATH on the remote system.  See the man page for more
information on this.  This message may also be displayed if the remote
version of rdiff-backup is quite different from the local version (1.9.1b0).

When I do manually run `ssh -C example.com
<[hidden email]> rdiff-backup --server` it does launch
the server and manual ssh and run rdiff-backup does show it's on the path.
So I've concluded I have a version mismatch.

Do you agree that is my issue?

So I went to manually install it, but the downloads page takes me to
https://github.com/rdiff-backup/rdiff-backup/releases which shows a 10 year
gap and there isn't a version < 2.0 that I can see there.

How do I install a version like 1.9.1b0 on Debian?

Thank you!
Brian


--
Brian Bouterse
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Patrik Dufresne
Hello Brian,

We are aware of the incompatibles between the legacy version and the new
version. It's was not possible in a reasonable amount of time to keep it
backwards compatible.

I'm currently working on a migration guide. It's a work in progress...

Check this out and let me know what you think

https://github.com/rdiff-backup/rdiff-backup/blob/ikus-migration-docs/docs/migration.md


On Tue., Apr. 14, 2020, 5:26 p.m. Brian Bouterse, <[hidden email]>
wrote:

> I use rdiff-backup and love it, but I'm challenged by what I think is a
> version mismatch issue.
>
> My central rdiff-backup server has version 1.9.1b0. Now I need to backup a
> Debian system and this system and even the latest (
> https://packages.debian.org/buster/rdiff-backup ) uses 1.2.8-7.
>
> When I attempt to run the test command:   `rdiff-backup --test-server
> example.com::/ignore` I get the error:
>
> Couldn't start up the remote connection by executing
>
>     ssh -C example.com rdiff-backup --server
>
> Remember that, under the default settings, rdiff-backup must be
> installed in the PATH on the remote system.  See the man page for more
> information on this.  This message may also be displayed if the remote
> version of rdiff-backup is quite different from the local version
> (1.9.1b0).
>
> When I do manually run `ssh -C example.com
> <[hidden email]> rdiff-backup --server` it does launch
> the server and manual ssh and run rdiff-backup does show it's on the path.
> So I've concluded I have a version mismatch.
>
> Do you agree that is my issue?
>
> So I went to manually install it, but the downloads page takes me to
> https://github.com/rdiff-backup/rdiff-backup/releases which shows a 10
> year
> gap and there isn't a version < 2.0 that I can see there.
>
> How do I install a version like 1.9.1b0 on Debian?
>
> Thank you!
> Brian
>
>
> --
> Brian Bouterse
>
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Brian Bouterse
I understand how maintaining the protocol compatibility wasn't an option.
It's actually pretty great the on-disk layout is backwards compatible. Your
guide looks pretty good. I have a few questions.

In my case it's the section at the bottom "Use Case: Remote to Local
(push)". My local is the 1.9.0b1 (Fedora) machine as my remote is the 1.2.8
(Debian) machine. What do you think the right process would be for me to
try? If it works for me I could send some docs back to your PR.

Is my first step to upgrade the remote Debian machine from 1.2.8 -> 2.0.0?
Can I use the "On Debian" portion of guide to upgrade that 2.0.0?

What version was the backwards compatible protocol version made? Is the
1.9.0 client the new or the old protocol?

Any other advice on the process I should try in my case?

Thanks for any info you can provide.

-Brian



On Tue, Apr 14, 2020 at 9:04 PM Patrik Dufresne <[hidden email]> wrote:

> Hello Brian,
>
> We are aware of the incompatibles between the legacy version and the new
> version. It's was not possible in a reasonable amount of time to keep it
> backwards compatible.
>
> I'm currently working on a migration guide. It's a work in progress...
>
> Check this out and let me know what you think
>
>
> https://github.com/rdiff-backup/rdiff-backup/blob/ikus-migration-docs/docs/migration.md
>
>
> On Tue., Apr. 14, 2020, 5:26 p.m. Brian Bouterse, <[hidden email]>
> wrote:
>
>> I use rdiff-backup and love it, but I'm challenged by what I think is a
>> version mismatch issue.
>>
>> My central rdiff-backup server has version 1.9.1b0. Now I need to backup a
>> Debian system and this system and even the latest (
>> https://packages.debian.org/buster/rdiff-backup ) uses 1.2.8-7.
>>
>> When I attempt to run the test command:   `rdiff-backup --test-server
>> example.com::/ignore` I get the error:
>>
>> Couldn't start up the remote connection by executing
>>
>>     ssh -C example.com rdiff-backup --server
>>
>> Remember that, under the default settings, rdiff-backup must be
>> installed in the PATH on the remote system.  See the man page for more
>> information on this.  This message may also be displayed if the remote
>> version of rdiff-backup is quite different from the local version
>> (1.9.1b0).
>>
>> When I do manually run `ssh -C example.com
>> <[hidden email]> rdiff-backup --server` it does launch
>> the server and manual ssh and run rdiff-backup does show it's on the path.
>> So I've concluded I have a version mismatch.
>>
>> Do you agree that is my issue?
>>
>> So I went to manually install it, but the downloads page takes me to
>> https://github.com/rdiff-backup/rdiff-backup/releases which shows a 10
>> year
>> gap and there isn't a version < 2.0 that I can see there.
>>
>> How do I install a version like 1.9.1b0 on Debian?
>>
>> Thank you!
>> Brian
>>
>>
>> --
>> Brian Bouterse
>>
>

--
Brian Bouterse
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Frank Crawford
Brian,
FYI, the incompatibility is really between python2 and python3
versions, so, 1.9.X and 2.0.0 are interoperable.
RegardsFrank
On Wed, 2020-04-15 at 18:52 -0400, Brian Bouterse wrote:

> I understand how maintaining the protocol compatibility wasn't an
> option.It's actually pretty great the on-disk layout is backwards
> compatible. Yourguide looks pretty good. I have a few questions.
> In my case it's the section at the bottom "Use Case: Remote to
> Local(push)". My local is the 1.9.0b1 (Fedora) machine as my remote
> is the 1.2.8(Debian) machine. What do you think the right process
> would be for me totry? If it works for me I could send some docs back
> to your PR.
> Is my first step to upgrade the remote Debian machine from 1.2.8 ->
> 2.0.0?Can I use the "On Debian" portion of guide to upgrade that
> 2.0.0?
> What version was the backwards compatible protocol version made? Is
> the1.9.0 client the new or the old protocol?
> Any other advice on the process I should try in my case?
> Thanks for any info you can provide.
> -Brian
>
>
> On Tue, Apr 14, 2020 at 9:04 PM Patrik Dufresne <[hidden email]>
> wrote:
> > Hello Brian,
> > We are aware of the incompatibles between the legacy version and
> > the newversion. It's was not possible in a reasonable amount of
> > time to keep itbackwards compatible.
> > I'm currently working on a migration guide. It's a work in
> > progress...
> > Check this out and let me know what you think
> >
> > https://github.com/rdiff-backup/rdiff-backup/blob/ikus-migration-docs/docs/migration.md
> >
> >
> > On Tue., Apr. 14, 2020, 5:26 p.m. Brian Bouterse, <
> > [hidden email]>wrote:
> > > I use rdiff-backup and love it, but I'm challenged by what I
> > > think is aversion mismatch issue.
> > > My central rdiff-backup server has version 1.9.1b0. Now I need to
> > > backup aDebian system and this system and even the latest (
> > > https://packages.debian.org/buster/rdiff-backup ) uses 1.2.8-7.
> > > When I attempt to run the test command:   `rdiff-backup --test-
> > > serverexample.com::/ignore` I get the error:
> > > Couldn't start up the remote connection by executing
> > >     ssh -C example.com rdiff-backup --server
> > > Remember that, under the default settings, rdiff-backup must
> > > beinstalled in the PATH on the remote system.  See the man page
> > > for moreinformation on this.  This message may also be displayed
> > > if the remoteversion of rdiff-backup is quite different from the
> > > local version(1.9.1b0).
> > > When I do manually run `ssh -C example.com<
> > > [hidden email]> rdiff-backup --server` it does
> > > launchthe server and manual ssh and run rdiff-backup does show
> > > it's on the path.So I've concluded I have a version mismatch.
> > > Do you agree that is my issue?
> > > So I went to manually install it, but the downloads page takes me
> > > tohttps://github.com/rdiff-backup/rdiff-backup/releases which
> > > shows a 10yeargap and there isn't a version < 2.0 that I can see
> > > there.
> > > How do I install a version like 1.9.1b0 on Debian?
> > > Thank you!Brian
> > >
> > > --Brian Bouterse
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Brian Bouterse
Thanks Frank and Patrik. I did get my Debian system upgraded using the pypi
installation method and my backup worked!

@Patrik your notes helped me, but I did things slightly differently. This
was on Debian stretch. I really should upgrade to Buster but it's a remote
machine and ... COVID.

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

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
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:

```
sudo /opt/rdiff-backup2/bin/pip3 install rdiff-backup
Collecting rdiff-backup
  Using cached
https://files.pythonhosted.org/packages/af/61/4edbe10fbee6e2490207314ac9c036e7135784a328629079860bfecc29ea/rdiff-backup-2.0.0.tar.gz
Building wheels for collected packages: rdiff-backup
  Running setup.py bdist_wheel for rdiff-backup ... error
  Complete output from command /opt/rdiff-backup2/bin/python3 -u -c "import
setuptools,
tokenize;__file__='/tmp/pip-build-gex_7lx1/rdiff-backup/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d
/tmp/tmpz1_uun1spip-wheel- --python-tag cp35:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

  ----------------------------------------
  Failed building wheel for rdiff-backup
  Running setup.py clean for rdiff-backup
Failed to build rdiff-backup
Installing collected packages: rdiff-backup
  Running setup.py install for rdiff-backup ... done
Successfully installed rdiff-backup-2.0.0
```

That was resolved with `/opt/rdiff-backup2/bin/pip3 install wheel`. After
that the following command completed with no errors:

```
sudo /opt/rdiff-backup2/bin/pip3 install rdiff-backup pyxattr pylibacl
Collecting rdiff-backup
  Using cached
https://files.pythonhosted.org/packages/af/61/4edbe10fbee6e2490207314ac9c036e7135784a328629079860bfecc29ea/rdiff-backup-2.0.0.tar.gz
Collecting pyxattr
  Using cached
https://www.piwheels.org/simple/pyxattr/pyxattr-0.7.1-cp35-cp35m-linux_armv7l.whl
Collecting pylibacl
  Using cached
https://files.pythonhosted.org/packages/b5/46/9438665705fbd76015ee2cdda2c136364504272de08124b73ffb3f5cf1a5/pylibacl-0.5.4.tar.gz
Building wheels for collected packages: rdiff-backup, pylibacl
  Running setup.py bdist_wheel for rdiff-backup ... done
  Stored in directory:
/root/.cache/pip/wheels/4d/71/ee/13c25188b5639e34ad22a811fabe1cfcfeac56ba334d120729
  Running setup.py bdist_wheel for pylibacl ... done
  Stored in directory:
/root/.cache/pip/wheels/66/4e/0d/804daa57f0f46ce432e9d050ed0ec8521ce2113c00174104c8
Successfully built rdiff-backup pylibacl
Installing collected packages: rdiff-backup, pyxattr, pylibacl
Successfully installed pylibacl-0.5.4 pyxattr-0.7.1 rdiff-backup-2.0.0
```

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).

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?

Thanks again!
Brian



On Thu, Apr 16, 2020 at 7:08 AM Frank Crawford <[hidden email]>
wrote:

> Brian,
>
> FYI, the incompatibility is really between python2 and python3 versions,
> so, 1.9.X and 2.0.0 are interoperable.
>
> Regards
> Frank
>
> On Wed, 2020-04-15 at 18:52 -0400, Brian Bouterse wrote:
>
> I understand how maintaining the protocol compatibility wasn't an option.
>
> It's actually pretty great the on-disk layout is backwards compatible. Your
>
> guide looks pretty good. I have a few questions.
>
>
> In my case it's the section at the bottom "Use Case: Remote to Local
>
> (push)". My local is the 1.9.0b1 (Fedora) machine as my remote is the 1.2.8
>
> (Debian) machine. What do you think the right process would be for me to
>
> try? If it works for me I could send some docs back to your PR.
>
>
> Is my first step to upgrade the remote Debian machine from 1.2.8 -> 2.0.0?
>
> Can I use the "On Debian" portion of guide to upgrade that 2.0.0?
>
>
> What version was the backwards compatible protocol version made? Is the
>
> 1.9.0 client the new or the old protocol?
>
>
> Any other advice on the process I should try in my case?
>
>
> Thanks for any info you can provide.
>
>
> -Brian
>
>
>
>
> On Tue, Apr 14, 2020 at 9:04 PM Patrik Dufresne <
>
> [hidden email]
>
> > wrote:
>
>
> Hello Brian,
>
>
> We are aware of the incompatibles between the legacy version and the new
>
> version. It's was not possible in a reasonable amount of time to keep it
>
> backwards compatible.
>
>
> I'm currently working on a migration guide. It's a work in progress...
>
>
> Check this out and let me know what you think
>
>
>
> https://github.com/rdiff-backup/rdiff-backup/blob/ikus-migration-docs/docs/migration.md
>
>
>
>
> On Tue., Apr. 14, 2020, 5:26 p.m. Brian Bouterse, <
>
> [hidden email]
>
> >
>
> wrote:
>
>
> I use rdiff-backup and love it, but I'm challenged by what I think is a
>
> version mismatch issue.
>
>
> My central rdiff-backup server has version 1.9.1b0. Now I need to backup a
>
> Debian system and this system and even the latest (
>
> https://packages.debian.org/buster/rdiff-backup
>
>  ) uses 1.2.8-7.
>
>
> When I attempt to run the test command:   `rdiff-backup --test-server
>
> example.com::/ignore` I get the error:
>
>
> Couldn't start up the remote connection by executing
>
>
>     ssh -C example.com rdiff-backup --server
>
>
> Remember that, under the default settings, rdiff-backup must be
>
> installed in the PATH on the remote system.  See the man page for more
>
> information on this.  This message may also be displayed if the remote
>
> version of rdiff-backup is quite different from the local version
>
> (1.9.1b0).
>
>
> When I do manually run `ssh -C example.com
>
> <
>
> [hidden email]
>
> > rdiff-backup --server` it does launch
>
> the server and manual ssh and run rdiff-backup does show it's on the path.
>
> So I've concluded I have a version mismatch.
>
>
> Do you agree that is my issue?
>
>
> So I went to manually install it, but the downloads page takes me to
>
> https://github.com/rdiff-backup/rdiff-backup/releases
>
>  which shows a 10
>
> year
>
> gap and there isn't a version < 2.0 that I can see there.
>
>
> How do I install a version like 1.9.1b0 on Debian?
>
>
> Thank you!
>
> Brian
>
>
>
> --
>
> Brian Bouterse
>
>
>
>
>

--
Brian Bouterse
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

EricZolf
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 | Threaded
Open this post in threaded view
|

Re: Version Woes

EricZolf
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, [hidden email] 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 | Threaded
Open this post in threaded view
|

Re: Version Woes

Robert Nichols-2
On 4/17/20 12:52 AM, [hidden email] wrote:
> 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

That's if you _can_ upgrade on both sides. I have CentOS 6 clients, and
their Python 3 version is 3.4.10, which is too old for rdiff-backup
2.0. The CentOS 8 server has to support both 1.2 and 2.0 clients,
regardless of what needs to be done to accomplish that.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.


Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Frank Crawford
On Fri, 2020-04-17 at 08:27 -0500, Robert Nichols wrote:
> On 4/17/20 12:52 AM,
> [hidden email]
>  wrote:
>
> That's if you _can_ upgrade on both sides. I have CentOS 6 clients,
> and
> their Python 3 version is 3.4.10, which is too old for rdiff-backup
> 2.0. The CentOS 8 server has to support both 1.2 and 2.0 clients,
> regardless of what needs to be done to accomplish that.

Do you actually have a version of 1.2 that runs on CentOS 8?

Regards
Frank


Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Robert Nichols-2
On 4/17/20 8:46 PM, Frank Crawford wrote:

> On Fri, 2020-04-17 at 08:27 -0500, Robert Nichols wrote:
>> On 4/17/20 12:52 AM,
>> [hidden email]
>>   wrote:
>>
>> That's if you _can_ upgrade on both sides. I have CentOS 6 clients,
>> and
>> their Python 3 version is 3.4.10, which is too old for rdiff-backup
>> 2.0. The CentOS 8 server has to support both 1.2 and 2.0 clients,
>> regardless of what needs to be done to accomplish that.
>
> Do you actually have a version of 1.2 that runs on CentOS 8?

It just takes a couple of symlinks to make rdiff-backup-1.2.8-6 work
with the python2-2.7.16.12 that is available for CentOS 8.
    ln -s python2.7 /usr/lib64/python-2.6
    ln -s libpython2.7.so.1.0 /usr/lib64/libpython2.6.so.1.0
The /usr/bin/rdiff-backup script needs to invoke /usr/bin/python2
explicitly.

I haven't tested it fully, but the basic operations seem to work.
I could probably rebuild rdiff-backup-1.2.8-6 to use python2.7
directly.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.


Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Frank Crawford
On Fri, 2020-04-17 at 21:48 -0500, Robert Nichols wrote:

> On 4/17/20 8:46 PM, Frank Crawford wrote:
> > On Fri, 2020-04-17 at 08:27 -0500, Robert Nichols wrote:
> > > On 4/17/20 12:52 AM,
> > > [hidden email]
> > >
> > >   wrote:
> > >
> > > That's if you _can_ upgrade on both sides. I have CentOS 6
> > > clients,
> > > and
> > > their Python 3 version is 3.4.10, which is too old for rdiff-
> > > backup
> > > 2.0. The CentOS 8 server has to support both 1.2 and 2.0 clients,
> > > regardless of what needs to be done to accomplish that.
> >
> > Do you actually have a version of 1.2 that runs on CentOS 8?
>
> It just takes a couple of symlinks to make rdiff-backup-1.2.8-6 work
> with the python2-2.7.16.12 that is available for CentOS 8.
>     ln -s python2.7 /usr/lib64/python-2.6
>     ln -s libpython2.7.so.1.0 /usr/lib64/libpython2.6.so.1.0
> The /usr/bin/rdiff-backup script needs to invoke /usr/bin/python2
> explicitly.
>
> I haven't tested it fully, but the basic operations seem to work.
> I could probably rebuild rdiff-backup-1.2.8-6 to use python2.7
> directly.

Okay, when I get the rdiff-backup 2.0 out in the various Fedora/EPEL
repos, including the optional packages for pylibacl and pyxattr for EPEL8, I'll see if I can knock up a version of rdiff-backup 1.2.8 on my COPR repo.

If there is a big enough demand I will look at how I can get a rdiff-
backup 1.2.8 build into EPEL8, but the real intention is to move
forward with version 2 and onwards.

Regards
Frank


Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Otto Kekäläinen
In reply to this post by Brian Bouterse
Hello!

> My central rdiff-backup server has version 1.9.1b0. Now I need to backup a
> Debian system and this system and even the latest (
> https://packages.debian.org/buster/rdiff-backup ) uses 1.2.8-7.

Versions 1.4.x and 1.9.x are pre-releases of version 2.0.0. This was
not that well communicated. In future the development releases will be
more clear about what they are development versions for, e.g.
2.0.1~pre1 or 2.1.0~beta2 etc. Exact suffix I don't think has been
decided yet (it is not at least documented in
https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/DEVELOP.md#versioning
yet) but the prefix will be marking what it is a dev version for.

So, if anybody is running 1.4.x or 1.9.x somewhere, please uninstall
it. Don't run development releases in production, that is just asking
for trouble. Please use the official 2.0.0 release instead.

I also noticed that our README has an error, it recommended people to
install development versions without proper warnings. This is now
addressed in the PR at
https://github.com/rdiff-backup/rdiff-backup/pull/325/files

- Otto

Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Brian Bouterse
In reply to this post by EricZolf
On Fri, Apr 17, 2020 at 1:34 AM <[hidden email]> 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).
>
Thank you for correcting me on this. You're right pyenv is deprecated, and
virtualenv is not.


> > 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.
>
I upgraded to 2.0.0 so I'm off 1.9.0. I'm also happy to see Fedora 32 will
have a packaged version of 2.0.0 too
https://fedoraproject.org/wiki/Changes/Python3-rdiff-backup

>
> > 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
>
>

--
Brian Bouterse
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Patrik Dufresne
Hello Brian,

Following up with you. Did you get all the information you need to fix your
initial problem ? Does the migration document contain all the information
you need in order to fix your issue ? If not please let us know so we can
update the documentation.

On Sat, Apr 18, 2020 at 2:19 PM Brian Bouterse <[hidden email]> wrote:

> On Fri, Apr 17, 2020 at 1:34 AM <[hidden email]> 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).
> >
> Thank you for correcting me on this. You're right pyenv is deprecated, and
> virtualenv is not.
>
>
> > > 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.
> >
> I upgraded to 2.0.0 so I'm off 1.9.0. I'm also happy to see Fedora 32 will
> have a packaged version of 2.0.0 too
> https://fedoraproject.org/wiki/Changes/Python3-rdiff-backup
>
> >
> > > 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
> >
> >
>
> --
> Brian Bouterse
>


--
Patrik Dufresne <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Derek Atkins-2
In reply to this post by Frank Crawford
Frank Crawford <[hidden email]> writes:

> Okay, when I get the rdiff-backup 2.0 out in the various Fedora/EPEL
> repos, including the optional packages for pylibacl and pyxattr for
> EPEL8, I'll see if I can knock up a version of rdiff-backup 1.2.8 on
> my COPR repo.
>
> If there is a big enough demand I will look at how I can get a rdiff-
> backup 1.2.8 build into EPEL8, but the real intention is to move
> forward with version 2 and onwards.

Unless and until we have a way for "current" version to talk to
"ancient" version, we will necessarily need to maintain 1.2.8 for the
foreseeable future.

Sometimes you just can't upgrade a system but you still need to be able
to back it up.  I've got one server still running Fedora 20!

Lack of cross-version support is going to be a MAJOR issue for a while!
The client-server incompatibility will require maintaining both
versions, at least in one place in a deployed backup solution.

To that end, I recommend we try VERY HARD to have both 1.2.8 AND
2.current available as packages in distros (the same way you can have
both python2 and python3 simultaneously).

> Regards
> Frank

-derek

--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant

Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Frank Crawford
On Thu, 2020-04-23 at 14:16 -0400, Derek Atkins wrote:

> Frank Crawford <
> [hidden email]
> > writes:
>
> > Okay, when I get the rdiff-backup 2.0 out in the various
> > Fedora/EPEL
> > repos, including the optional packages for pylibacl and pyxattr for
> > EPEL8, I'll see if I can knock up a version of rdiff-backup 1.2.8
> > on
> > my COPR repo.
> >
> > If there is a big enough demand I will look at how I can get a
> > rdiff-
> > backup 1.2.8 build into EPEL8, but the real intention is to move
> > forward with version 2 and onwards.
>
> Unless and until we have a way for "current" version to talk to
> "ancient" version, we will necessarily need to maintain 1.2.8 for the
> foreseeable future.

Understand that, which is why we are looking at some options.

> Sometimes you just can't upgrade a system but you still need to be
> able
> to back it up.  I've got one server still running Fedora 20!

However, a different way to address it would be to export the backup
repository via something like NFS and then just running the 1.2.8
locally on the Fedora 20 server.

It is only the communication that is the problem, not the actual backup
repository.

> Lack of cross-version support is going to be a MAJOR issue for a
> while!
> The client-server incompatibility will require maintaining both
> versions, at least in one place in a deployed backup solution.

However, they need to have different names, hence, as it stands you
cannot install both packages at once.

> To that end, I recommend we try VERY HARD to have both 1.2.8 AND
> 2.current available as packages in distros (the same way you can have
> both python2 and python3 simultaneously).

You talk about Fedora 20, but if you stay on the Fedora builds, python2
no longer supported, and shortly won't even be available.

As well, if we try and put a python2 version into a distribution we
would also expect to provide at least patches for security issues, if
they occur.  Especially for long-lived distributions like RHEL7 &
RHEL8.

The easiest way out of that is to ensure that there is no implied
support, i.e. by making something available, but outside the normal
distribution.

This is why I am looking at supplying something out of COPR, but even
that brings in issue with dependencies, such as pylibacl and pyxattr,
which I also need to look at how to make available.

Regards
Frank


Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Derek Atkins-2
Frank Crawford <[hidden email]> writes:

>> Sometimes you just can't upgrade a system but you still need to be
>> able
>> to back it up.  I've got one server still running Fedora 20!
>
> However, a different way to address it would be to export the backup
> repository via something like NFS and then just running the 1.2.8
> locally on the Fedora 20 server.
>
> It is only the communication that is the problem, not the actual backup
> repository.

That presumes that the old server is talking to the repo, but that's not
necessarily how it works.  In my case it is:

     [NFS] --- [Backup Server] -- [Servers being Backed up]

I can generally control the version on the Backup Server.  I cannot
always control the version on the Servers being Backed up.  However, it
would be nice if there were some way to auto-detect the other end and
then fork/exec/switch to a compatible wire protocol.

>> Lack of cross-version support is going to be a MAJOR issue for a
>> while!
>> The client-server incompatibility will require maintaining both
>> versions, at least in one place in a deployed backup solution.
>
> However, they need to have different names, hence, as it stands you
> cannot install both packages at once.

I don't understand.  Why can't they be called rdiff-backup and rdiff-backup1?

>> To that end, I recommend we try VERY HARD to have both 1.2.8 AND
>> 2.current available as packages in distros (the same way you can have
>> both python2 and python3 simultaneously).
>
> You talk about Fedora 20, but if you stay on the Fedora builds, python2
> no longer supported, and shortly won't even be available.

Are you sure?  Fedora-32, just released today, still has Python 2.

> As well, if we try and put a python2 version into a distribution we
> would also expect to provide at least patches for security issues, if
> they occur.  Especially for long-lived distributions like RHEL7 &
> RHEL8.

Sure, but 1.2.8 has been in that sitation for half a decade now.  What's
changed today vs a year ago (beyond having rdiff-backup-2 now)?

> The easiest way out of that is to ensure that there is no implied
> support, i.e. by making something available, but outside the normal
> distribution.
>
> This is why I am looking at supplying something out of COPR, but even
> that brings in issue with dependencies, such as pylibacl and pyxattr,
> which I also need to look at how to make available.

There is a question of support, and there is a question of backwards
compatibility.  In my mind the latter is more important.  I don't expect
(and frankly don't want to make) changes to "old" systems.  But I'd like
"new" systems to continue to be able to talk to them.

> Regards
> Frank

-derek

--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant

Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Derek Atkins-2

On Tue, April 28, 2020 12:36 pm, Derek Atkins wrote:
[snip]
>> You talk about Fedora 20, but if you stay on the Fedora builds, python2
>> no longer supported, and shortly won't even be available.
>
> Are you sure?  Fedora-32, just released today, still has Python 2.

And to follow up to this, not only does F32 have Python 2.7, it also has
Python 2.6!  So I don't think Python 2 is going away any time soon.

-derek
--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant


Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Tomas Pospisek ML
On 28.04.20 19:44, Derek Atkins wrote:

>
> On Tue, April 28, 2020 12:36 pm, Derek Atkins wrote:
> [snip]
>>> You talk about Fedora 20, but if you stay on the Fedora builds, python2
>>> no longer supported, and shortly won't even be available.
>>
>> Are you sure?  Fedora-32, just released today, still has Python 2.
>
> And to follow up to this, not only does F32 have Python 2.7, it also has
> Python 2.6!  So I don't think Python 2 is going away any time soon.

Python 2 has been officially declared "end of life":

https://www.python.org/doc/sunset-python-2/

Python is only "not going away" in the sense that you can not erase the
past and that still existing remainders of it are not being aggressively
deleted. But in most other meanings of that phrase, in particular those
related to software, I think one *can* robustly say that "Python 2 *is*
going away".
*t

Reply | Threaded
Open this post in threaded view
|

Re: Version Woes

Brian Bouterse
In reply to this post by Patrik Dufresne
I did get all the info I needed to fix my problem. It's easier for me
because I was able to upgrade rdiff backup on both the client and server to
2.0.0.

One thing about the docs that is confusing is the github readme and your
guide have the newer info, but the official docs page here
https://rdiff-backup.net/docs/docs.html doesn't have anything on it or link
to it as the "new docs" or something like that.


On Tue, Apr 21, 2020 at 8:35 AM Patrik Dufresne <[hidden email]> wrote:

> Hello Brian,
>
> Following up with you. Did you get all the information you need to fix
> your initial problem ? Does the migration document contain all the
> information you need in order to fix your issue ? If not please let us know
> so we can update the documentation.
>
> On Sat, Apr 18, 2020 at 2:19 PM Brian Bouterse <[hidden email]> wrote:
>
>> On Fri, Apr 17, 2020 at 1:34 AM <[hidden email]> 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).
>> >
>> Thank you for correcting me on this. You're right pyenv is deprecated, and
>> virtualenv is not.
>>
>>
>> > > 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.
>> >
>> I upgraded to 2.0.0 so I'm off 1.9.0. I'm also happy to see Fedora 32 will
>> have a packaged version of 2.0.0 too
>> https://fedoraproject.org/wiki/Changes/Python3-rdiff-backup
>>
>> >
>> > > 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
>> >
>> >
>>
>> --
>> Brian Bouterse
>>
>
>
> --
> Patrik Dufresne <[hidden email]>
> [image: vcs]



--
Brian Bouterse
12