Python 3.x vs 2.7


Kento Yoshida
 

Hi CIP core group,

 

The security package proposal is suspended now, but I'd like to discuss about the python version which is suitable to maintain.

 

We selected "duplicity" for the requirement of system backup according to the functionality, license, the number of dependencies and so on.

However, the duplicity in the Debian buster [1] dependent on python 2.7, which is not maintained anymore [2].

 

[1] https://packages.debian.org/source/buster/duplicity

[2] https://pythonclock.org/

 

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

 

1. Maintain python 2.7 as well

2. Backport the upper duplicity which migrated python 3.x in bullseye archive

3. Others

 

What do you think is best?

I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

 

FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.

See the following.

 

<Rsync>

Encryption: No

Schedule backup: No

Incremental backup: Yes

License: GPL v3

Dependencies count (aprox): 24

Reference: https://rsync.samba.org/features.html

 

<duplicity>

Encryption: Yes

Schedule backup: No

Incremental backup: Yes

License: GPL v2

Dependencies count (aprox): 80

Reference: http://duplicity.nongnu.org/features.ht

 

<Backuppc>

Encryption: No

Schedule backup: Yes

Incremental backup: Yes

License: GPL-2+, X11

Dependencies count (aprox): 132

Reference: http://backuppc.sourceforge.net/info.html

 

<Amanda>

Encryption: Yes

Schedule backup: Yes

Incremental backup: Yes

License: GPL-2+

Dependencies count (aprox): 289

Reference: https://www.zmanda.com/amanda-community-edition.html

 

<Kbackup>

Encryption: Yes

Schedule backup: Yes

Incremental backup: Yes

License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV

Dependencies count (aprox): 414

Reference: https://kde.org/applications/utilities/org.kde.kbackup

 

Best regards,

Kent


Nobuhiro Iwamatsu
 

Hi,

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive
3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.
In my opinion, it is difficult to support Python2 for a super long term. And I think it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use backposts.debian.org.
However, packages with large dependencies can be difficult to backports. For example Kbuckup is difficult, I think.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive
3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV
Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent


Kento Yoshida
 

Thank you for your feedback, Iwamatsu-san.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
Sent: Friday, April 3, 2020 8:19 AM
To: Kento Yoshida <kento.yoshida.wz@renesas.com>; cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: RE: Python 3.x vs 2.7

Hi,

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye
archive 3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

In my opinion, it is difficult to support Python2 for a super long term. And I think
it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use
backposts.debian.org.
Actually, option-2 is dominant in the security team as well.

However, packages with large dependencies can be difficult to backports. For
example Kbuckup is difficult, I think.
Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the
python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the
functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The
duplicity is the best package for us from the license and num of dependencies
point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent


Pavel Machek
 

Hi!


FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to do
incremental backups...

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


punit1.agrawal@...
 

Hi Kent,

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

Thank you for your feedback, Iwamatsu-san.

-----Original Message-----
From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
[...]

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye
archive 3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

In my opinion, it is difficult to support Python2 for a super long term. And I think
it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use
backposts.debian.org.
Actually, option-2 is dominant in the security team as well.
From a brief look at the pros / cons between the two choices (below), I
am also biased towards backporting a python3 based version of duplicity.

Suggested next steps further down -

* Python2

Pros
----
* No backport (to Buster) needed (least effort, right now)

Cons
----
* Has reached EOL in upstream. Not sure about ELTS support. It maybe
that if we go with Python2, we (CIP) is on our own.


* Python3

Pros
----
* Python3 is available in Debian Buster
* Likely to be supported for longer time - upstream and in Debian

Cons
----
* Needs backporting duplicity (and dependencies) to Buster via
backports to align with upstream first approach of CIP.
- From a quick check of dependencies in bullseye a backport of
librsync2 might also be needed.


Next steps
----------
* Investigate the effort to backport duplicity (and dependencies) to
buster-backports.
* If no major surprises are found during the investigation, work with
Debian upstream to upload the new version.

Hope that makes sense.

Thanks,
Punit


However, packages with large dependencies can be difficult to backports. For
example Kbuckup is difficult, I think.
Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.

Best regards,
Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the
python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the
functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python
3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be
similar problems for the others of python.

FYI, unfortunately we couldn't find the alternative package for system backup. The
duplicity is the best package for us from the license and num of dependencies
point of view.
See the following.

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Jan Kiszka
 

On 03.04.20 23:47, Pavel Machek wrote:
Hi!


FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to do
incremental backups...
I suppose there is that concern about GPLv3 again (as with broadly used rsync) - which is generally overrated. There exists legal views that already GPLv2 requires to keep such licensed components replaceable on the target. What then effectively remains with v3 is its, well, wording complexity.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Pavel Machek <pavel@...>
 

On Mon 2020-04-06 12:15:16, Jan Kiszka wrote:
On 03.04.20 23:47, Pavel Machek wrote:
Hi!


FYI, unfortunately we couldn't find the alternative package for system backup. The duplicity is the best package for us from the license and num of dependencies point of view.
See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to do
incremental backups...
I suppose there is that concern about GPLv3 again (as with broadly used
rsync) - which is generally overrated. There exists legal views that already
GPLv2 requires to keep such licensed components replaceable on the target.
What then effectively remains with v3 is its, well, wording complexity.
Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.

If that's out of question, I'm pretty sure we can get GPLv2 tar
implementation somewhere. busybox has implementation, and I'm pretty
sure there's GPLv2 fork of busybox. Old version of tar should be
GPLv2. Still better than porting duplicity to different python
version...

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Kento Yoshida
 

Hi,

-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: Tuesday, April 7, 2020 6:52 AM
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Pavel Machek <pavel@denx.de>; Kento Yoshida
<kento.yoshida.wz@renesas.com>; cip-security@lists.cip-project.org;
cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Python 3.x vs 2.7

On Mon 2020-04-06 12:15:16, Jan Kiszka wrote:
On 03.04.20 23:47, Pavel Machek wrote:
Hi!


FYI, unfortunately we couldn't find the alternative package for
system backup. The duplicity is the best package for us from the license and num
of dependencies point of view.

See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht
I'm not sure what your exact requirements are, but have you
considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to
do
incremental backups...
I suppose there is that concern about GPLv3 again (as with broadly
used
rsync) - which is generally overrated. There exists legal views that
already
GPLv2 requires to keep such licensed components replaceable on the
target.
What then effectively remains with v3 is its, well, wording
complexity.

Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.
Some of the security members didn't accept GPLv3, so currently we dropped GPLv3 packages from the candidates.

BTW, I'm not sure but is the CIP policy on accepting GPLv3 still to be decided?

If that's out of question, I'm pretty sure we can get GPLv2 tar implementation
somewhere. busybox has implementation, and I'm pretty sure there's GPLv2 fork
of busybox. Old version of tar should be GPLv2. Still better than porting duplicity
to different python version...
Thank you for introduction about "tar".
I will investigate whether it meets the requirements.
And also I'll search GPLv2 implementation if it meets the requirements.
If it's not decided yet about the CIP policy on accepting GPLv3, we cannot adopt GPLv3 packages.

Anyway, I agreed it is difficult to support python 2 for a super long term. And everyone agreed on this point.
So, we cannot support each libraries using python 2, at least.

Best regards, Kent

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany