[opensuse-factory] Removal of Python2 from openSUSE Tumbleweed
Hello all, We are now in the final stages of python2 saga. :) This means we will have to start removing all the stuff that is based on python2 only from the distribution. We have created lists of items that depend on python2 setuptools and devel respectively in our python trello [1] [2]. Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments. If you wanna help feel free to start based on the lists :) Cheers Ondřej [1] https://trello.com/c/XaVFZE8n/38-packages-depending-on-py2-setuptools-direct... [2] https://trello.com/c/v4XyXC4O/39-packages-depending-on-py2-devel-directly -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 08.01.20 um 15:32 schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution.
We have created lists of items that depend on python2 setuptools and devel respectively in our python trello [1] [2].
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
do we know what will break in Tumbleweed when Python2 is removed? What if things break which we cannot fix short and mid term but which are essential for Tumbleweed? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-01-08 at 15:38 +0100, Wolfgang Rosenauer wrote:
Hi,
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
do we know what will break in Tumbleweed when Python2 is removed? What if things break which we cannot fix short and mid term but which are essential for Tumbleweed?
If we talk about essential stuff in TW, then I'm afraid the 'drop python2 team' will have to step up their game. the final removal of python2 can only happen when Stagings pass. IIRC, Firefox still uses py2 in its own build system too. So that for one will be a fun challenge already. Clearly, I will not accept a python2 delreq before Firefox can build without it. in any case: SLE15 will have to maintain python2 'for quite a bit longer' - with factory first we can still benefit from the corporate maintenance that is nescessary there. It's not as urgent as some folks make it appear (also: a new python 2.x release is scheduled to be released in April - so much about py2 is EOL in January :P ) Cheers, Dominique
Am 08.01.20 um 15:55 schrieb Dominique Leuenberger / DimStar:
On Wed, 2020-01-08 at 15:38 +0100, Wolfgang Rosenauer wrote:
Hi,
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
do we know what will break in Tumbleweed when Python2 is removed? What if things break which we cannot fix short and mid term but which are essential for Tumbleweed?
If we talk about essential stuff in TW, then I'm afraid the 'drop python2 team' will have to step up their game. the final removal of python2 can only happen when Stagings pass.
IIRC, Firefox still uses py2 in its own build system too. So that for one will be a fun challenge already. Clearly, I will not accept a python2 delreq before Firefox can build without it.
that case was what I had in mind when I asked the question. The Firefox buildsystem is highly complex and switching everything to Python3 is not happening short term. The upstream meta bug was opened 2 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1388447 And this is nothing we can accelerate much. Actually probably the 'drop python2 team' can assist upstream so it will be done soon(er)? Anyway feel free to drop python2 stuff as long as other packages do not break or can be fixed from our side. At least I cannot "fix" Firefox on my own. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-01-08, 14:55 GMT, Dominique Leuenberger / DimStar wrote:
(also: a new python 2.x release is scheduled to be released in April - so much about py2 is EOL in January :P )
Yes, but this is meant just as a stopgap measure if anybody forgot anything. This is really it for Python 2 and please do not suggest otherwise. Yes, Mozilla build system is a problem, and I can see that finally the development on that bug seems to make some rounds (finally!), and we will have to wait with removal of the interpreter itself (and only that) from Factory until that is resolved. Otherwise, all other python2-only code should go. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Courage is resistance of fear, mastery of fear, not absence of fear. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 8 Jan 2020 at 15:39, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Hi,
Am 08.01.20 um 15:32 schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution.
We have created lists of items that depend on python2 setuptools and devel respectively in our python trello [1] [2].
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
do we know what will break in Tumbleweed when Python2 is removed?
nothing ... for 99% of user ( i personally removed python2 from my installation in middle of 2019 )
What if things break which we cannot fix short and mid term but which are essential for Tumbleweed?
Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.01.20 um 15:32 schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
will /usr/bin/python then point to python3? Reason: bluez has test scripts that have a #!/usr/bin/python shebang, but work just fine with python3 (AFAICT). Best regards, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jan 8, 2020 at 10:51 AM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 08.01.20 um 15:32 schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
will /usr/bin/python then point to python3?
Reason: bluez has test scripts that have a #!/usr/bin/python shebang, but work just fine with python3 (AFAICT).
We also should probably be imposing a policy similar to Fedora and Mageia to force all Python shebangs to be versioned for installed scripts. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
will /usr/bin/python then point to python3?
Reason: bluez has test scripts that have a #!/usr/bin/python shebang, but work just fine with python3 (AFAICT).
We also should probably be imposing a policy similar to Fedora and Mageia to force all Python shebangs to be versioned for installed scripts.
(1) Note that the version can be imposed without an absolute path: `#!/usr/bin/env python3` and `#!/usr/bin/env python2`. (2) If absolute paths are used can this be done without encouraging upstream to use such shebangs? Absolute paths make it difficult to run up-to-date software on systems where there is no or too old python[23] in /usr/bin. If `env` is used I can at least help myself with a symlink in a folder early in $PATH (or a wrapper script if I also need to activate an environment first). Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-09 at 09:58 +0000, Joachim Wagner wrote:
will /usr/bin/python then point to python3?
Reason: bluez has test scripts that have a #!/usr/bin/python shebang, but work just fine with python3 (AFAICT).
We also should probably be imposing a policy similar to Fedora and Mageia to force all Python shebangs to be versioned for installed scripts.
(1) Note that the version can be imposed without an absolute path: `#!/usr/bin/env python3` and `#!/usr/bin/env python2`.
/usr/bin/env python3 is 'fine' for local stuff done by yourself - but is plain wrong for packages provided by the distro. There, the packages are supposed to be integrating to each others and 'risking' to use any random 'python interpreter other than the one provided by the packaging system' is not what the distro should aim for.
(2) If absolute paths are used can this be done without encouraging upstream to use such shebangs? Absolute paths make it difficult to run up-to-date software on systems where there is no or too old python[23] in /usr/bin. If `env` is used I can at least help myself with a symlink in a folder early in $PATH (or a wrapper script if I also need to activate an environment first).
Preferably upstreams would make their build systems a bit smarter so that packagers can define what they want: 'local addon software' or 'package manager integrated stuff' BTW: '/usr/bin/env python' as shebang has the negative side effect of requriing /usr/bin/env in the rpm metadata of the package, but not actually any python interpreter. Using /usr/bin/python3 makes this correct and requires a python interpreter. Last but not least: we have an rpmlint check complaining about /usr/bin/env as shebang (for all the reasons outlined above). There are currently > 300 reports in Factory for this: https://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=env-scrip... Cheers, Dominique
On 2020-01-08, 15:51 GMT, Stefan Seyfried wrote:
Am 08.01.20 um 15:32 schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
will /usr/bin/python then point to python3?
We will follow https://www.python.org/dev/peps/pep-0394/ but note that its language is very very complicated and very careful reading is necessary to understand it.
Reason: bluez has test scripts that have a #!/usr/bin/python shebang, but work just fine with python3 (AFAICT).
I would still suggest that sed changing /usr/bin/python to /usr/bin/python3 is a good idea, not relying on some silly symlink. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their consciences. -- C. S. Lewis -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 8. Januar 2020, 15:32:58 CET schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution.
We have created lists of items that depend on python2 setuptools and devel respectively in our python trello [1] [2].
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
Calibre needs python2!!! It is not compatible with python3 now. Will python2 only remove in Tumbleweed or in Leap 15.1, too? Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-01-08 20:39, Eric Schirra wrote:
Will python2 only remove in Tumbleweed or in Leap 15.1, too?
Subject: Re: [opensuse-factory] Removal of Python2 from openSUSE Tumbleweed -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Eric Schirra <ecsos@opensuse.org>:
Calibre needs python2!!! It is not compatible with python3 now.
We really shouldn't expect that applications are compatible with python3. After all, it was only released a little more than a decade ago. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/8/20 9:05 PM, Arjen de Korte wrote:
Citeren Eric Schirra <ecsos@opensuse.org>:
Calibre needs python2!!! It is not compatible with python3 now.
We really shouldn't expect that applications are compatible with python3. After all, it was only released a little more than a decade ago.
With the first five or six years of PY3 history being wasted e.g. by not accepting u'' string literals etc. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
Will python2 only remove in Tumbleweed or in Leap 15.1, too?
Leap 15.1 is a stable, released product in a frozen repository. How would that even work to remove a package from there? :) Even Leap 15.2 will still have python2. I'd not expect any python2 in Leap 16 though (whenever that will be) Cheers, Dominique
On Thu, 2020-01-09 at 10:26 +0100, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
According to https://github.com/kovidgoyal/calibre/blob/master/README.python3 https://github.com/kovidgoyal/calibre/pull/870 Calibre should work with Python 3. Third party plugins may not be ready though. Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade?
I guess this depends on how many volunteers will give a helping hand.
Python2 is EOL. Riding a dead horse is no fun.
While this may be true, millions of code lines out in the wild aren't easily rewritten...
I'd not expect any python2 in Leap 16 though (whenever that will be)
Hopefully, it will be at least available as part of an add-on repository. Werner -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-09 at 10:35 +0100, Werner LEMBERG wrote:
I'd not expect any python2 in Leap 16 though (whenever that will be)
Hopefully, it will be at least available as part of an add-on repository.
Sure, you have OBS at your hand and can provide such a repo for Leap 16 when the need arises. Cheers, Dominique
Op donderdag 9 januari 2020 10:35:00 CET schreef Werner LEMBERG:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade?
I guess this depends on how many volunteers will give a helping hand.
Python2 is EOL. Riding a dead horse is no fun.
While this may be true, millions of code lines out in the wild aren't easily rewritten...
I'd not expect any python2 in Leap 16 though (whenever that will be)
Hopefully, it will be at least available as part of an add-on repository.
Werner I hope not. Upstream has (years ago) told us there was an end to python2. If it was just another app, but python is everywhere. I would not take the risk of future zero days that will no longer be fixed by upstream. The Calibre ( and other ) devs have been aware for a long time, or at least they should have when even an average user can be. If they weren't, I'd consider Calibre unmaintained which is sad, but a risk, i.e. a potential security issue.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Upstream has (years ago) told us there was an end to python2. If it was just another app, but python is everywhere. I would not take the risk of future zero days that will no longer be fixed by upstream. The Calibre ( and other ) devs have been aware for a long time, or at least they should have when even an average user can be. If they weren't, I'd consider Calibre unmaintained which is sad, but a risk, i.e. a potential security issue.
I guess it's not that simple. Compare this to LilyPond, which needs an almost ten years old version of guile (1.8.8) and can't really use the 2.x series, because one of the features central to LilyPond (quick string copying without encoding conversion) has been replaced with something "better". The current guile 2.2.x series makes LilyPond work three times slower, which is completely unacceptable given that LilyPond is already tremendously slow due to very heavy layout computations. And no, the maintainers of guile are not listening. Werner -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/9/20 10:44 AM, Knurpht-openSUSE wrote:
I hope not. Upstream has (years ago) told us there was an end to python2. If it was just another app, but python is everywhere. I would not take the risk of future zero days that will no longer be fixed by upstream. The Calibre ( and other ) devs have been aware for a long time, or at least they should have when even an average user can be. If they weren't, I'd consider Calibre unmaintained which is sad, but a risk, i.e. a potential security issue.
I find it somewhat amusing how when someone mentions "EOL" and "unmaintained", then it suddenly becomes a semi-dogmatic emergency to remove anything and everything that is using this so called "EOL" and "unmaintained" code... while at the same time, we have all licenses that state "DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE" If one or two people wrote some piece of software and they are the "upstream" for it and then we have distributions and thousands of people using it .... why are we using Free Open Source?? Because it's Free Beer or because we can fix problems ourselves? If you are worried about "zero days", the current status quo of maintained software doesn't protect you from these "zero days" anyway. A bug needs to be reported and then someone, ideally someone that has access to the source code, can then fix it. And with Python, well, don't we all have access to this source code so we can fix it?? Python2 is maintained for as long as someone cares enough to maintain it. Maybe it's no longer going to be developed by the Python Software Foundation, but that doesn't mean no one cares about it anymore and it becomes radioactive or something. Don't ignore the ONE and ONLY advantage of Free Software over closed binary-blob software. Cheers, Adam PS. Just my thoughts/opinion on this subject. And they are my own opinion, no one else's. -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/9/20 8:57 PM, Adam Majer wrote:
On 1/9/20 10:44 AM, Knurpht-openSUSE wrote:
I hope not. Upstream has (years ago) told us there was an end to python2. If it was just another app, but python is everywhere. I would not take the risk of future zero days that will no longer be fixed by upstream. The Calibre ( and other ) devs have been aware for a long time, or at least they should have when even an average user can be. If they weren't, I'd consider Calibre unmaintained which is sad, but a risk, i.e. a potential security issue.
I find it somewhat amusing how when someone mentions "EOL" and "unmaintained", then it suddenly becomes a semi-dogmatic emergency to remove anything and everything that is using this so called "EOL" and "unmaintained" code... while at the same time, we have all licenses that state "DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE"
If one or two people wrote some piece of software and they are the "upstream" for it and then we have distributions and thousands of people using it .... why are we using Free Open Source?? Because it's Free Beer or because we can fix problems ourselves?
If you are worried about "zero days", the current status quo of maintained software doesn't protect you from these "zero days" anyway. A bug needs to be reported and then someone, ideally someone that has access to the source code, can then fix it. And with Python, well, don't we all have access to this source code so we can fix it??
Python2 is maintained for as long as someone cares enough to maintain it. Maybe it's no longer going to be developed by the Python Software Foundation, but that doesn't mean no one cares about it anymore and it becomes radioactive or something. Don't ignore the ONE and ONLY advantage of Free Software over closed binary-blob software.
I think the point here is that SUSE doesn't care enough to maintain it anymore in its future releases hence it putting in the effort to fix as much as possible before removing it. -- 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 1/9/20 12:32 PM, Simon Lees wrote:
Python2 is maintained for as long as someone cares enough to maintain it. Maybe it's no longer going to be developed by the Python Software Foundation, but that doesn't mean no one cares about it anymore and it becomes radioactive or something. Don't ignore the ONE and ONLY advantage of Free Software over closed binary-blob software.
I think the point here is that SUSE doesn't care enough to maintain it anymore in its future releases hence it putting in the effort to fix as much as possible before removing it.
Is it no longer maintained in SLES-12? Removing it from Factory and keeping it in SLE-12, we just lose on regression testing. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-09 at 13:50 +0100, Adam Majer wrote:
I think the point here is that SUSE doesn't care enough to maintain it
anymore in its future releases hence it putting in the effort to fix as much as possible before removing it.
Is it no longer maintained in SLES-12? Removing it from Factory and keeping it in SLE-12, we just lose on regression testing.
It's even in SLE15 - you have a couple more years. But that does not mean that we have to get Factory to the point where it CAN be without Python 2 - otherwise SLE16 will be in deep waters. This in turn also means: if nothing in TW makes use of py2 anymore, the pure presence of the py2 package does not give you ANY regression testing. That's a very weak argument. Cheers, Dominique
On 1/9/20 1:55 PM, Dominique Leuenberger / DimStar wrote:
This in turn also means: if nothing in TW makes use of py2 anymore, the pure presence of the py2 package does not give you ANY regression testing. That's a very weak argument.
TW is not only its own user. We still have outside users of TW. And they install things like python2 for their legacy applications. I agree with you 100% on your other points. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jan 9, 2020 at 14:24, Adam Majer <amajer@suse.de> wrote:
On 1/9/20 1:55 PM, Dominique Leuenberger / DimStar wrote:
This in turn also means: if nothing in TW makes use of py2 anymore, the pure presence of the py2 package does not give you ANY regression testing. That's a very weak argument.
TW is not only its own user. We still have outside users of TW. And they install things like python2 for their legacy applications.
There would be no reason to keep shipping deps for those python2 applications either then, so they wouldn't work anyway (outside of some very simple scripts), unless you want those to stay too? LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-09 at 14:24 +0100, Adam Majer wrote:
On 1/9/20 1:55 PM, Dominique Leuenberger / DimStar wrote:
This in turn also means: if nothing in TW makes use of py2 anymore, the pure presence of the py2 package does not give you ANY regression testing. That's a very weak argument.
TW is not only its own user. We still have outside users of TW. And they install things like python2 for their legacy applications.
What stops them from also installing python2 from outside for their legacy apps coming from outside? Cheers Dominique
On 09/01/2020 12.32, Simon Lees wrote:
On 1/9/20 8:57 PM, Adam Majer wrote:
[…] Python2 is maintained for as long as someone cares enough to maintain it. Maybe it's no longer going to be developed by the Python Software Foundation, but that doesn't mean no one cares about it anymore and it becomes radioactive or something. Don't ignore the ONE and ONLY advantage of Free Software over closed binary-blob software.
I think the point here is that SUSE doesn't care enough to maintain it anymore in its future releases hence it putting in the effort to fix as much as possible before removing it.
And no one can be stopped easily from using old, EOL'd Linux distributions which still have old, outdated, insecure software but is the only old version that still works for a specific use case. Containers help as well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jan 09, Adam Majer wrote:
I find it somewhat amusing how when someone mentions "EOL" and "unmaintained", then it suddenly becomes a semi-dogmatic emergency to remove anything and everything that is using this so called "EOL" and "unmaintained" code... while at the same time, we have all licenses that state "DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE"
Because legally, there is a big difference if you ship something with a big security problem you are not aware of compared to shipping something with a security problem you are aware of. In the second case, all this disclaimers don't help you at all. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/9/20 12:56 PM, Thorsten Kukuk wrote:
On Thu, Jan 09, Adam Majer wrote:
I find it somewhat amusing how when someone mentions "EOL" and "unmaintained", then it suddenly becomes a semi-dogmatic emergency to remove anything and everything that is using this so called "EOL" and "unmaintained" code... while at the same time, we have all licenses that state "DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE"
Because legally, there is a big difference if you ship something with a big security problem you are not aware of compared to shipping something with a security problem you are aware of. In the second case, all this disclaimers don't help you at all.
Maybe, not sure. But EOL upstream does not imply "big security hole". And even with security issues, we (or almost anyone) doesn't stop shipping of distributions because some component has an issue. This is true in OSS as well as closed software world. Anyway, back to reality, if python2 ends up with future security issues, we can deal with it at the time instead of now. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-09 at 14:47 +0100, Adam Majer wrote:
On 1/9/20 12:56 PM, Thorsten Kukuk wrote:
On Thu, Jan 09, Adam Majer wrote:
I find it somewhat amusing how when someone mentions "EOL" and "unmaintained", then it suddenly becomes a semi-dogmatic emergency to remove anything and everything that is using this so called "EOL" and "unmaintained" code... while at the same time, we have all licenses that state "DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE"
Because legally, there is a big difference if you ship something with a big security problem you are not aware of compared to shipping something with a security problem you are aware of. In the second case, all this disclaimers don't help you at all.
Maybe, not sure. But EOL upstream does not imply "big security hole". And even with security issues, we (or almost anyone) doesn't stop shipping of distributions because some component has an issue. This is true in OSS as well as closed software world.
Anyway, back to reality, if python2 ends up with future security issues, we can deal with it at the time instead of now.
If we have that large usage footprint as we have now (with packages that would support py3 but were never switched) we just run into issues. Let's do the work NOW - before we have to rush it and can't really cope with it. Just a sample: I am just busy switching the fail2ban package to use py3. Upstream had support for it for years - yet our package was never switched. Cheers, Dominique
On Thu, 2020-01-09 at 15:13 +0100, Dominique Leuenberger / DimStar wrote:
Just a sample: I am just busy switching the fail2ban package to use py3. Upstream had support for it for years - yet our package was never switched.
Adding to that: 'years' means many years here (not 2, which would have been the bare minimum to use plural) https://github.com/fail2ban/fail2ban/pull/171 - Python3 support had been merged On April 17 2013 - so just about 7 years ago. Cheers, Dominique
On 1/9/20 3:13 PM, Dominique Leuenberger / DimStar wrote:
Just a sample: I am just busy switching the fail2ban package to use py3. Upstream had support for it for years - yet our package was never switched.
I agree with this. What I don't agree with is removing the *interpreter* that we (SUSE) still have to maintain anyway. Not keeping the *interpreter* in Factory removes the QA feedback from our TW users and is unnecessary. Just don't accept anything new that BR: python. And if in the future there is something wrong found with python2, it could then be easily removed because nothing depends on it anymore. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-09 at 16:10 +0100, Adam Majer wrote:
On 1/9/20 3:13 PM, Dominique Leuenberger / DimStar wrote:
Just a sample: I am just busy switching the fail2ban package to use py3. Upstream had support for it for years - yet our package was never switched.
I agree with this. What I don't agree with is removing the *interpreter* that we (SUSE) still have to maintain anyway. Not keeping the *interpreter* in Factory removes the QA feedback from our TW users and is unnecessary. Just don't accept anything new that BR: python.
And if in the future there is something wrong found with python2, it could then be easily removed because nothing depends on it anymore.
You expect a lot of feedback from an interpreter that is part of the TW repo but nothing depends on? You seem to imply that many users will still install it and offer you (SUSE) feedback about regressions. Will be damn hard to support that with numbers. In any case - the interpreter will obviously be the last thing to be removed from repo. Let's first make sure that we can finally minimize the footprint of stuff depending on python2 - it's not as if the 'removal of py2 in Jan 2020' had only been announced this year. Cheers, Dominique
On 1/9/20 4:10 PM, Adam Majer wrote:
On 1/9/20 3:13 PM, Dominique Leuenberger / DimStar wrote:
Just a sample: I am just busy switching the fail2ban package to use py3. Upstream had support for it for years - yet our package was never switched.
I agree with this. What I don't agree with is removing the *interpreter* that we (SUSE) still have to maintain anyway. Not keeping the *interpreter* in Factory removes the QA feedback from our TW users and is unnecessary. Just don't accept anything new that BR: python.
And if in the future there is something wrong found with python2, it could then be easily removed because nothing depends on it anymore.
I completely agree with Adam here. While I've migrated all my own code to PY3 I see some value to keep the PY2 interpreter for now, at least in such a way that one can create a virtual environment for testing legacy stuff. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/10/20 1:40 AM, Adam Majer wrote:
On 1/9/20 3:13 PM, Dominique Leuenberger / DimStar wrote:
Just a sample: I am just busy switching the fail2ban package to use py3. Upstream had support for it for years - yet our package was never switched.
I agree with this. What I don't agree with is removing the *interpreter* that we (SUSE) still have to maintain anyway. Not keeping the *interpreter* in Factory removes the QA feedback from our TW users and is unnecessary. Just don't accept anything new that BR: python.
Well at the same time SUSE is working to have tumbleweed in a ready state to branch it for the next SLE release and the best way to be sure that tumbleweed is functioning well without python2 for the next SLE release is to no longer have python2 in the distro. We really don't want to be maintaining it for another 10 years after that release. Given that python2 really shouldn't change much from now into the future one would think the QA feedback we would get from TW users about any python updates would be rather limited. -- 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
Am Donnerstag, 9. Januar 2020, 10:26:34 CET schrieb Dominique Leuenberger / DimStar:
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
I have pushed latest calibre version for python3 to Documentation:Tools Request to Factory also done. But attention, python3 support is beta in calibre. For Leap no chance, because the latest running version for Leap is 3.48 Many libraries in Leap are to old. And i can not test calibre in tumbleweed because i use Leap. Perhaps someone other can test calibre for python3 Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, January 9, 2020 4:51:44 PM CET Eric Schirra wrote:
Am Donnerstag, 9. Januar 2020, 10:26:34 CET schrieb Dominique Leuenberger /
DimStar:
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
I have pushed latest calibre version for python3 to Documentation:Tools Request to Factory also done. But attention, python3 support is beta in calibre.
For Leap no chance, because the latest running version for Leap is 3.48 Many libraries in Leap are to old.
And i can not test calibre in tumbleweed because i use Leap. Perhaps someone other can test calibre for python3
Regards Eric
It installs and starts, opens and scrolls through my ebooks on Tumbleweed. Did not have the time to test more of its functionality, yet. So basically it works as it should. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 10. Januar 2020, 17:17:57 CET schrieb Andreas Prittwitz:
I have pushed latest calibre version for python3 to Documentation:Tools Request to Factory also done. But attention, python3 support is beta in calibre.
For Leap no chance, because the latest running version for Leap is 3.48 Many libraries in Leap are to old.
And i can not test calibre in tumbleweed because i use Leap. Perhaps someone other can test calibre for python3
It installs and starts, opens and scrolls through my ebooks on Tumbleweed. Did not have the time to test more of its functionality, yet. So basically it works as it should.
Perfect. Thanks for your replay. :-) Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jan 9, 2020 at 4:28 AM Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
My understanding is that the maintainer really didn't like having to be forced to deal with unicode and for years was counting on a fork of python2 to catch on, but that never happened and so he ended up having to rush at the last minute. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 9. Januar 2020, 18:21:04 CET schrieb Todd Rme:
On Thu, Jan 9, 2020 at 4:28 AM Dominique Leuenberger / DimStar
<dimstar@opensuse.org> wrote:
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
My understanding is that the maintainer really didn't like having to be forced to deal with unicode and for years was counting on a fork of python2 to catch on, but that never happened and so he ended up having to rush at the last minute.
What has this to do with maintainer? You mean updstream? Python3 support is beta in calibre till now. Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/9/20 4:26 AM, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-01-08 at 20:39 +0100, Eric Schirra wrote:
Calibre needs python2!!! It is not compatible with python3 now.
Any plans to bring Calibre to the 21st century and into the current decade? Python2 is EOL. Riding a dead horse is no fun.
Will python2 only remove in Tumbleweed or in Leap 15.1, too?
Leap 15.1 is a stable, released product in a frozen repository. How would that even work to remove a package from there? :) Even Leap 15.2 will still have python2.
I'd not expect any python2 in Leap 16 though (whenever that will be)
Maybe 16 is another "bad" number, don't commit to anything until the "bad number checkers" have done their work ;)
Cheers, Dominique
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-01-09, 09:26 GMT, Dominique Leuenberger / DimStar wrote:
Leap 15.1 is a stable, released product in a frozen repository. How would that even work to remove a package from there? :) Even Leap 15.2 will still have python2.
I'd not expect any python2 in Leap 16 though (whenever that will be)
Just to note that SLE 15 doesn’t have python2 packages already. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 How many Bavarian Illuminati does it take to screw in a light bulb? Three: one to screw it in, and one to confuse the issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 10, Matěj Cepl wrote:
On 2020-01-09, 09:26 GMT, Dominique Leuenberger / DimStar wrote:
Leap 15.1 is a stable, released product in a frozen repository. How would that even work to remove a package from there? :) Even Leap 15.2 will still have python2.
I'd not expect any python2 in Leap 16 though (whenever that will be)
Just to note that SLE 15 doesn’t have python2 packages already.
That's not fully correct, they are only moved to an own Module to make it more difficult for people to use it on the one side, and to allow us to remove python2 completly before EoL of SLE 15. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 8 Jan 2020 at 20:40, Eric Schirra <ecsos@opensuse.org> wrote:
Am Mittwoch, 8. Januar 2020, 15:32:58 CET schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution.
We have created lists of items that depend on python2 setuptools and devel respectively in our python trello [1] [2].
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
Calibre needs python2!!! It is not compatible with python3 now.
interesting, and on github calibre 4.99.3 aka 5.0 beta3 with python3 only is what ?
Will python2 only remove in Tumbleweed or in Leap 15.1, too?
Regards Eric
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 9. Januar 2020, 12:40:01 CET schrieb Ondřej Súkup:
On Wed, 8 Jan 2020 at 20:40, Eric Schirra <ecsos@opensuse.org> wrote:
Calibre needs python2!!! It is not compatible with python3 now.
interesting, and on github calibre 4.99.3 aka 5.0 beta3 with python3 only is what ?
..is more or less working and waits for the plugins to catch up. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 2020-01-09 12:40, schrieb Ondřej Súkup:
On Wed, 8 Jan 2020 at 20:40, Eric Schirra <ecsos@opensuse.org> wrote:
Am Mittwoch, 8. Januar 2020, 15:32:58 CET schrieb Ondřej Súkup:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution.
We have created lists of items that depend on python2 setuptools and devel respectively in our python trello [1] [2].
Now what needs to be done: 1) package can be using just py2 and needs it -> remove it 2) package has optional support of py2 a) remove the part if you don't plan backporting b) add %bcond_without python2 and wrap it in if statements for the opensuse_version to enable it on old codestreams
After the bulk of 'killing' is done we will continue by creating specialized staging project where we will switch off the build of python2-* packages and have another list of stuff that needs adjustments.
Calibre needs python2!!! It is not compatible with python3 now.
interesting, and on github calibre 4.99.3 aka 5.0 beta3 with python3 only is what ?
Yes. For Beta! But not for 4.8. The last release. But the code is included in source from version 4.8 I have now build calibre with python3 and will push it to devel in serveral minutes. -- Regards Eric -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Wed, 8 Jan 2020 15:32:58 +0100 schrieb Ondřej Súkup <mimi.vx@gmail.com>:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution. [...]
will getmail work with python3? Kind regards Will -- openSUSE Tumbleweed 20200105 GNU/Linux 5.3.12-2-default x86_64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09 Jan 14:52, Wilhelm Boltz wrote:
Hello,
Am Wed, 8 Jan 2020 15:32:58 +0100 schrieb Ondřej Súkup <mimi.vx@gmail.com>:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution. [...]
will getmail work with python3?
No. Fedora recently removed it from the repos: https://bugzilla.redhat.com/show_bug.cgi?id=1777628 Regards, ismail -- 1 + 1 = 1 for large values of 1 SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
İsmail Dönmez <idoenmez@suse.de> writes:
On 09 Jan 14:52, Wilhelm Boltz wrote:
Hello,
Am Wed, 8 Jan 2020 15:32:58 +0100 schrieb Ondřej Súkup <mimi.vx@gmail.com>:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution. [...]
will getmail work with python3?
No. Fedora recently removed it from the repos: https://bugzilla.redhat.com/show_bug.cgi?id=1777628
FYI: offlineimap will probably suffer the same fate (although it got some time in Fedora via a FESCO exception). As far as I know python3 support is experimental, has known issues and there has been very little progress upstream. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Am Thu, 9 Jan 2020 14:57:08 +0100 schrieb İsmail Dönmez <idoenmez@suse.de>:
On 09 Jan 14:52, Wilhelm Boltz wrote:
Hello,
Am Wed, 8 Jan 2020 15:32:58 +0100 schrieb Ondřej Súkup <mimi.vx@gmail.com>:
Hello all,
We are now in the final stages of python2 saga. :)
This means we will have to start removing all the stuff that is based on python2 only from the distribution. [...]
will getmail work with python3?
No. Fedora recently removed it from the repos: https://bugzilla.redhat.com/show_bug.cgi?id=1777628
Thank you for this information, though it is bad news. Kind regards Wilhelm -- openSUSE Tumbleweed 20200107 GNU/Linux 5.3.12-2-default x86_64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, what will happen with GIMP? As I learned from the gimp-devel list, 2.10.x won't get Python3 support, they are proting that (only) in the staging for 3.0. While core GIMP can run without Python, quite some powerful tools do use it, and without them (IMO) GIMP is quite crippled :o -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* James Knott <james.knott@jknott.net> [01-15-20 10:41]:
On 2020-01-15 07:49 AM, Peter Suetterlin wrote:
and without them (IMO) GIMP is quite crippled :o
I always though GIMP was LAME. ;-)
and this helps? HOW -- (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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
James Knott wrote:
On 2020-01-15 07:49 AM, Peter Suetterlin wrote:
and without them (IMO) GIMP is quite crippled :o
I always though GIMP was LAME. ;-)
a) not true b) not really funny (IMO) c) there are no alternatives IMO (stuff like resynthesizer etc) And yes, I use it a lot almost daily. A distribution without fully working GIMP is a no-go, just like one w/o firefox (although I don't use that one). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
James Knott schrieb:
On 2020-01-15 07:49 AM, Peter Suetterlin wrote:
and without them (IMO) GIMP is quite crippled :o
I always though GIMP was LAME. ;-)
LAME is actually a completely different software project, which is even included in openSUSE. I don't think that it uses Python at all, neither 2 nor 3, and it also has no direct connection with GIMP, so not sure why you mention it in this thread (others already addressed the not-really-funny potential joke). Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (30)
-
Adam Majer -
Andreas Prittwitz -
Arjen de Korte -
Dan Čermák -
Dominique Leuenberger / DimStar -
Eric Schirra -
Hans-Peter Jansen -
İsmail Dönmez -
James Knott -
Jan Engelhardt -
Joachim Wagner -
Knurpht-openSUSE -
Matěj Cepl -
Michael Ströder -
Neal Gompa -
Oliver Kurz -
Ondřej Súkup -
Patrick Shanahan -
Peter Suetterlin -
Robert Kaiser -
Robert Munteanu -
Robert Schweikert -
Simon Lees -
Stasiek Michalski -
Stefan Seyfried -
Thorsten Kukuk -
Todd Rme -
Werner LEMBERG -
Wilhelm Boltz -
Wolfgang Rosenauer