On Thu, Dec 5, 2019 at 7:00 AM Simon Lees wrote:

...

The command is "rpm -q --whatrequires python2" but that will only list the direct dependencies zypper rm python2 will give you the full list of what will change., pretty much everything in the distro's have already been ported to python3, my leap desktop for example doesn't even have python2 installed on my tumbleweed laptop mercurial seems like the only reason I have it installed

The following is on an up-to-date Tumbleweed (dup last night):

It tried the rpm command:

$ rpm -q --whatrequires python2 python2-setuptools-41.0.1-154.2.noarch python2-cryptography-2.8-1.2.x86_64

Or even:

$ rpm -q --whatrequires python python-z3c-rml-3.2.0-4.10.noarch zypper-log-1.14.32-1.2.noarch python3-apparmor-2.13.3-5.2.x86_64 paraview-5.6.2-63.7.x86_64

Yet I have 56 packages that have 'python2' as part of their name.

If I try to remove libpython2_7-1_0-2.7.17-1.1.x86_64, these packages are listed as needing it (I removed the obvious ones with 'python2' in the name). Some that have explicit libpython2 dependencies surprise me.

deinstallation of paraview-5.6.2-63.7.x86_64 deinstallation of python-xml-2.7.17-1.1.x86_64 deinstallation of python-tk-2.7.17-1.1.x86_64 deinstallation of python-curses-2.7.17-1.1.x86_64 deinstallation of python-base-2.7.17-1.1.x86_64 deinstallation of python-2.7.17-1.1.x86_64 deinstallation of mercurial-5.2-1.1.x86_64 deinstallation of bzr-2.7.0-5.4.x86_64 deinstallation of python-ipaddress-1.0.22-17.3.noarch deinstallation of python-functools32-3.2.3.2-6.11.noarch deinstallation of python-enum34-1.1.6-16.14.noarch deinstallation of python-z3c-rml-3.2.0-4.10.noarch deinstallation of python-preppy-2.4.1-2.11.noarch deinstallation of rdesktop-1.9.0-1.1.x86_64 deinstallation of python3-pyside2-5.13.1-1.3.x86_64 deinstallation of python3-astor-0.8-3.1.noarch deinstallation of openconnect-8.05-1.1.x86_64 deinstallation of npm12-12.13.1-1.1.x86_64 deinstallation of clang7-7.0.1-13.3.x86_64 deinstallation of mercurial-lang-5.2-1.1.noarch deinstallation of bzr-lang-2.7.0-5.4.noarch deinstallation of tensorflow-1.13.2-1.1.x86_64 deinstallation of openconnect-lang-8.05-1.1.noarch deinstallation of NetworkManager-openconnect-1.2.6-1.2.x86_64 deinstallation of tensorflow-doc-1.13.2-1.1.x86_64

The packages that have 2.7.17 in the name are probably python2 only. Even if the package names are not consistent.

But I wonder what will happen to ones like clang, brz, npm, rdesktop, and the like. the later versions of clang don't have this requirement, it looks like Canocical has abandoned bzr for git so i'd expect no one plans to spend time porting it to python3 and it will likely be dropped from everywhere, rdesktop has one utility python script that probably should be dropped because its not essential and creates a hard dependency, other packages will either be ported to python3 if there is enough interest (many already have been) or will be dropped when it goes end of

On 12/5/19 5:51 PM, Roger Oberholtzer wrote: life (many no longer maintained applications using python2 have also already been dropped). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Fri, Dec 6, 2019 at 8:32 PM Christian Boltz wrote:

Hello,

Am Donnerstag, 5. Dezember 2019, 08:21:53 CET schrieb Roger Oberholtzer:

...

...

The command is "rpm -q --whatrequires python2" but that will only list the direct dependencies zypper rm python2 will give you the full list of what will change., pretty much everything in the distro's have already been ported to python3 [...] $ rpm -q --whatrequires python [...]

On Thu, Dec 5, 2019 at 7:00 AM Simon Lees wrote: python3-apparmor-2.13.3-5.2.x86_64

I'm afraid (actually happy) that you are testing in a wrong way here ;-)

# rpm -q --requires python3-apparmor | grep python libpython3.7m.so.1.0()(64bit) python = 3.7 python(abi) = 3.7 python(abi) = 3.7

... which are provided by the python3 and python3-base packages ;-)

I will try this. But it is no guarantee that whoever decides to remove packages did/will do the exact same thing as I might try. So our lists might not be the same. A package I did not detect may be removed. Somewhere someone is deciding which packages will get the axe. I think sharing this list might allow people to better prepare. After the packages are removed from someone's system, there is no possibility of recovery (snapper aside). So one must prepare in advance. Which is what I am trying to do. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/5/19 6:48 PM, David C. Rankin wrote:

On 12/03/2019 06:12 AM, Roger Oberholtzer wrote:

...

In a short while, Python 2 will officially no longer be supported. As one would expect, distributions will no longer be making software packages based on Python 2.

I suspect Python 2 will continue to be packaged to support the huge amount of apps that make use of it, even if it is no longer being supported (like with Gtk+2, php5.6, etc...)

As someone who works alongside people in the team responsible for maintaining python inside SLE / openSUSE I can almost certainly say this won't happen. SUSE does not have the main power to maintain python security without an upstream and we are not interested in keeping software that we can't provide security updates for inside openSUSE so its and anything using it is scheduled to be dropped on the day support ends. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Fri, 6 Dec 2019 02:20:01 -0600 "David C. Rankin" wrote:

On 12/05/2019 10:13 PM, Simon Lees wrote:

...

As someone who works alongside people in the team responsible for maintaining python inside SLE / openSUSE I can almost certainly say this won't happen. SUSE does not have the main power to maintain python security without an upstream and we are not interested in keeping software that we can't provide security updates for inside openSUSE so its and anything using it is scheduled to be dropped on the day support ends.

Without an upstream, nothing changes, you just keep packaging the last release. No different than how Gtk+2 is packaged -- which hasn't had an upstream for years -- but there is still a lot of Gtk+2 code in many apps -- as there will be plenty of non-python3 compatible code if python2 was dropped. I don't see any manpower it would require at all. There will be no other changes to the package.

I think the point is that maintenance is done as part of SLE and they guarantee to provide security updates. So unless somebody can guarantee that there are no further security bugs in any python2-related packages, they can't keep them available without committing manpower as and when required. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Dec 6, 2019 at 1:29 PM Carlos E. R. wrote:

David idea is to provide it without security updates nor assurances. I would say in -deprecated-non-secure form.

I get that this will probably not happen. What I would like to see is a list of the packages that will go away when upstream support for Python2 goes away. That would allow one to decide if any of those packages need to be locked for local use. No fun getting a surprise that some package that one did not expect had a python2 dependency and was removed. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [12-06-19 11:00]:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 06/12/2019 15.00, Roger Oberholtzer wrote:

...

On Fri, Dec 6, 2019 at 1:29 PM Carlos E. R. wrote:

...

David idea is to provide it without security updates nor assurances. I would say in -deprecated-non-secure form.

I get that this will probably not happen.

Could be not in oss, but in another repo appropriately labelled, so that it is clear that is not part of the distribution.

...

What I would like to see is a list of the packages that will go away when upstream support for Python2 goes away. That would allow one to decide if any of those packages need to be locked for local use. No fun getting a surprise that some package that one did not expect had a python2 dependency and was removed.

Me too. I have no idea if I use something that needs Python2.

you have "rpm"! -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Roger Oberholtzer [12-06-19 15:10]:

On Fri, Dec 6, 2019 at 5:02 PM Patrick Shanahan wrote:

...

you have "rpm"!

See an earlier comment in this thread where I tried variations on "rpm -q --whatrequires python2"

I was looking for an rpm command to find this information. I must not have the command correct as it did not list as expected.

then rpm --test -e *python2* will show what will be removed, adjust and ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Roger Oberholtzer [12-06-19 15:24]:

On Fri, Dec 6, 2019 at 9:15 PM Patrick Shanahan wrote:

...

* Roger Oberholtzer [12-06-19 15:10]:

...

On Fri, Dec 6, 2019 at 5:02 PM Patrick Shanahan wrote:

...

you have "rpm"!

See an earlier comment in this thread where I tried variations on "rpm -q --whatrequires python2"

I was looking for an rpm command to find this information. I must not have the command correct as it did not list as expected.

then rpm --test -e *python2*

will show what will be removed, adjust and ...

Is that an official and complete description of how the packages will be selected for removal? I guess I sound paranoid. But I really can't chance messing this up.

What date will this happen for openSUSE? Meaning, when is the last 'safe' date to do an update while the python2 packages are still in place?

openSUSE distribution is rpm based. the command "rpm --test -e *python2* will show what will be removed (affected ) by using that command to remove all packages which contain "python2" in their name(s). official? I would guess as "official" as could be. Who designates "official"? it is how I (and quite experienced but not overly blessed with knowledge) would approach removing/replacing python2 packages on my system(s). I would do updates via: zypper -v ref ; zypper -v up -d ; zypper -v up as zypper will advise all changes and wait for permission before proceeding. If "python2" packages will be affected and I did not want to proceed with *them*, answer no to the update, add: zypper al *python2* (or particular packages instead of *python2* if ... ) then: zypper -v ref ; zypper -v up -d ; zypper -v up when satisfied. sometime you will need to determine if >python2 packages will satisfy or replace your current apps sufficiently to adjust and replace. above proceedure(s) should be "safe" for your current *python2* packages. and "date" should not be ?relevant?. again, I am expierienced but no where near an "expert". especially with YOUR install(s). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Bjoern Voigt [12-06-19 17:00]:

...

the command "rpm --test -e *python2* will show what will be removed (affected ) by using that command to remove all packages which contain "python2" in their name(s).

Patrick Shanahan wrote: the command shows nothing:

# rpm --test -e *python2* error: package *python2* is not installed # rpm --test -e "*python2*" error: package *python2* is not installed

I have 162 python 2 packages installed.

# rpm -qa | grep ^python2 | wc -l 162

then rpm --test -e `rpm -qa *python2*` or your incantation rpm --test -e `rpm -qa | grep python2 ` or zypper -vv rm *python2* -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/12/2019 22.35, Bjoern Voigt wrote:

On my desktop I see 3 big programs which require Python 2:

* MythTV * MySQL Workbench * Calibre

MythTV compilation can be configured to use Python 3. I do not know if MySQL Workbench compilation can be configured for Python 2.

The biggest issue seems to be Calibre. The Calibre developer Kovid Goyal commented in a bug report: "I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase." and closed the bug report as WONTFIX. See https://bugs.launchpad.net/calibre/+bug/1714107

He does. Telcontar:~ # tree -d /opt/calibre/ | grep python │   ├── python2.7 Telcontar:~ # He distributes python with /his/ package. /opt/calibre/ ├── bin ├── lib │   ├── python2.7 │ As that is the recommended method of installing calibre, not the rpm way, he is not affected. Just saying... I will not take sides in this. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 12/7/19 12:30 AM, Roger Oberholtzer wrote:

On Fri, Dec 6, 2019 at 1:29 PM Carlos E. R. wrote:

...

David idea is to provide it without security updates nor assurances. I would say in -deprecated-non-secure form.

I get that this will probably not happen. What I would like to see is a list of the packages that will go away when upstream support for Python2 goes away. That would allow one to decide if any of those packages need to be locked for local use. No fun getting a surprise that some package that one did not expect had a python2 dependency and was removed.

Yep its against openSUSE's policy to ship insecure software, there have been a number of packages dropped from tumbleweed because they are old and security bugs weren't being fixed. "zypper rm python2" will give you the full list. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 12/9/19 6:44 PM, Roger Oberholtzer wrote:

On Sat, Dec 7, 2019 at 1:21 AM Simon Lees wrote:

...

On 12/7/19 12:30 AM, Roger Oberholtzer wrote:

...

On Fri, Dec 6, 2019 at 1:29 PM Carlos E. R. wrote:

...

David idea is to provide it without security updates nor assurances. I would say in -deprecated-non-secure form.

I get that this will probably not happen. What I would like to see is a list of the packages that will go away when upstream support for Python2 goes away. That would allow one to decide if any of those packages need to be locked for local use. No fun getting a surprise that some package that one did not expect had a python2 dependency and was removed.

Yep its against openSUSE's policy to ship insecure software, there have been a number of packages dropped from tumbleweed because they are old and security bugs weren't being fixed.

"zypper rm python2" will give you the full list.

I get that this could tell what it claims to tell. But I do not believe that this is how packages to remove from OBS will be managed. After all, packages are not actually installed on OBS. So running a query against installed packages is probably not going to be how it is done.

Or do you mean that this command is what will be run on my system as part of a zypper dup, and that is how my local packages will actually be removed? EXACTLY that command?

I don't see what the problem is with publishing a list of the specific packages that will be removed from OBS.

It probably will be at the time, but it could still change from now, some stuff might get fixed, other stuff has already been removed over the last year so we won't know until then. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 12/7/19 7:09 AM, David C. Rankin wrote:

On 12/06/2019 05:10 AM, Dave Howorth wrote:

...

...

Without an upstream, nothing changes, you just keep packaging the last release. No different than how Gtk+2 is packaged -- which hasn't had an upstream for years -- but there is still a lot of Gtk+2 code in many apps -- as there will be plenty of non-python3 compatible code if python2 was dropped. I don't see any manpower it would require at all. There will be no other changes to the package.

...

I think the point is that maintenance is done as part of SLE and they guarantee to provide security updates. So unless somebody can guarantee that there are no further security bugs in any python2-related packages, they can't keep them available without committing manpower as and when required.

I see that point, but does that mean SLE is doing security checks on Gtk+2, Gtk+3 (now Gtk+4 is current, the same for GtkSourceview-2, 3 & 4), etc.. I can see SLE continuing with php56, but what of all the other successor versions of core tools that are no 100% backwards compatible with the new version.

Given that php56 is no longer in tumbleweed its safe to say it will be dropped in the next SLE / Leap. (It is possibly already in the SLE Legacy module [i'm too lazy to check]). SLE has alot less GTK stuff, desktop stuff also tends to have less significant security issues (when considering how insecure x11 is to start with). If they were getting significant security issues they'd likely be dropped (many of the lesser gtk2 libs have already been dropped).

The python issue makes no difference to me, I don't use it, but it really strikes me as odd why python2 would be singled out for different treatment than all the other packages and libraries where multiple versions are packaged for openSUSE. I would be a good 20-40% of libraries have multiple versions packaged, there are multiple versions of gcc, so why is python2 special?

Its much easier to maintain multiple gcc versions then a whole python stack the same can be said for multi versioned libraries although atleast in Tumbleweed where we have multi versioned libraries both versions are still maintained or we are trying to remove one. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

David C. Rankin wrote:

As for php56, there are still a number of enterprise type apps that remain to be ported.

Yup. I have a customer that is currently on Magento 1.x on php5 - they want to 1.x on php7, maybe even up to 2.x on php7, but they have a whole slew of plug-ins that are php5 only. Migration/updating will cost them thousands. (when you have to pay people). -- Per Jessen, Zürich (10.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org