Bug 1737848 - quisk depends on Python 2
Summary: quisk depends on Python 2
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: quisk
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F31_PY2REMOVAL 1739460
TreeView+ depends on / blocked
 
Reported: 2019-08-06 09:57 UTC by Lumír Balhar
Modified: 2019-11-08 21:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-08 21:32:57 UTC
Type: Bug


Attachments (Terms of Use)

Description Lumír Balhar 2019-08-06 09:57:50 UTC
Python 2.7 will reach end-of-life in January 2020, over 9 years after it was released. This falls within the Fedora 31 lifetime.
Packages that depend on Python 2 are being switched to Python 3 or removed from Fedora: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages
Python 2 will be retired in Fedora 32: https://fedoraproject.org/wiki/Changes/RetirePython2

To help planning, we'd like to know the plans for quisk's future. Specifically:


- What is the reason for the Python2 dependency? (Is it software written in Python, or does it just provide Python bindings, or use Python in the build system or test runner?)

- What are the upstream/community plans/timelines regarding Python 3?

- What is the guidance for porting to Python 3? (Assuming that there is someone who generally knows how to port to Python 3, but doesn't know anything about the particular package, what are the next steps to take?)


This bug is filed semi-automatically, and might not have all the context specific to quisk.
If you need anything from us, or something is unclear, please mention it here.

Thank you.

Comment 1 Ben Cotton 2019-08-13 16:53:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 2 Ben Cotton 2019-08-13 17:53:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 3 Lumír Balhar 2019-08-15 07:49:06 UTC
Please answer the above questions. If you don't, the package can be orphaned: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages

If you need any information or help, or if you need some more time, please let us know.

Comment 4 Lumír Balhar 2019-08-22 07:03:23 UTC
Please answer the above questions. If you don't, the package can be orphaned: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages

If you need any information or help, or if you need some more time, please let us know.

Comment 5 Lumír Balhar 2019-08-29 05:22:08 UTC
Please answer the above questions. If you don't, the package can be orphaned: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages

If you need any information or help, or if you need some more time, please let us know.

Comment 6 Miro Hrončok 2019-09-05 10:41:21 UTC
According to the procedure described in https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages the package was now orphaned. If you think it was a mistake, you can provide the answers and claim the package back.

Let us know if you need any help or just need more time.

Comment 7 Jaroslav Škarvada 2019-09-05 11:54:06 UTC
Please unorphan.

- What is the reason for the Python2 dependency?
It's SW written in the Python

- What are the upstream/community plans/timelines regarding Python 3?
Upstream is aware of the problem and is working on the Python3 port, it should be ready before Python2 sunsetting.

- What is the guidance for porting to Python 3? 
I offered my help, but upstream is capable enough to do the port themselves.

Comment 8 Miro Hrončok 2019-09-05 12:00:53 UTC
The package is yours.

Comment 9 Jaroslav Škarvada 2019-09-05 12:01:33 UTC
Please could you set needinfo next time? Otherwise this requests can be easily missed.

Comment 10 Jaroslav Škarvada 2019-09-05 12:53:38 UTC
(In reply to Jaroslav Škarvada from comment #9)
> Please could you set needinfo next time? Otherwise this requests can be
> easily missed.

Or better could you set needinfo to all such bugzillas? People with many packages like me could otherwise easily oversee these bugzillas (which also happened to me :)

Comment 11 Lumír Balhar 2019-09-06 05:58:29 UTC
Well, from my point of view (and I also maintain some packages), 4 notification emails per bug in one month are enough.

But yeah, I'll do my best to not waste my time tracking hundreds of bugs without any reaction.

Comment 12 Lumír Balhar 2019-09-06 06:01:19 UTC
Back to the original issue.

The current plan is to remove packages with dependency on Python 2 from Fedora 32 in the middle of November 2019. If you want to keep your package in Fedora after that date and you cannot port it to Python 3 yet, you need to request a FESCo exception for the package and all its Python 2 dependencies (even transitive) [1]. If you don't want to maintain it anymore, and nothing in Fedora uses it, you can retire it or just remove the Python 2 part from it (subpackage, module, bindings, etc.).

If you're considering filing the exception request, let us know. We can help (for example, we can help find all the dependencies).

[1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions

Comment 13 Jaroslav Škarvada 2019-09-06 06:50:26 UTC
(In reply to Lumír Balhar from comment #11)
> Well, from my point of view (and I also maintain some packages), 4
> notification emails per bug in one month are enough.
> 
> But yeah, I'll do my best to not waste my time tracking hundreds of bugs
> without any reaction.

The problem is if you maintain e.g nearly cca. 100 packages, you receive plenty of notifications daily. If there are some auto-generated messages you will soon stop reading them - i.e. I read the comment 0 (there are no dates and nothing about orphaning and also no orphaning dates) took it into account and then I start receiving the same notifications for all of my other packages, so I muted them. Then I noticed my packages got orphaned. I guess other maintainers could encounter the same problem.

I think you *should* add needinfo to such bugs, especially if you choose this more aggressive non-responsive maintainer process (i.e. no direct mails to the maintainer) - the needinfo costs you nearly nothing and by doing so: the maintainer will usually start receiving e-mail notifications about pending unanswered needinfo requests periodically. And she or he will also see it in dashboards, trackers, bugzilla queries etc. The best approach would probably also be to send direct e-mails to package owners aliases before orphaning. Just my two cents.

Comment 14 Jaroslav Škarvada 2019-09-06 06:58:33 UTC
(In reply to Lumír Balhar from comment #12)
> Back to the original issue.
> 
> The current plan is to remove packages with dependency on Python 2 from
> Fedora 32 in the middle of November 2019. If you want to keep your package
> in Fedora after that date and you cannot port it to Python 3 yet, you need
> to request a FESCo exception for the package and all its Python 2
> dependencies (even transitive) [1]. If you don't want to maintain it
> anymore, and nothing in Fedora uses it, you can retire it or just remove the
> Python 2 part from it (subpackage, module, bindings, etc.).
> 
> If you're considering filing the exception request, let us know. We can help
> (for example, we can help find all the dependencies).
> 
> [1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions

Thanks for info. I will decide the next steps after my vacation. This one will probably require exception. The upstream is working on the port, but according to the latest communication they are targeting January 2020 at the worst case (I will try to speed it up) - there is a problem that they have plenty of customers (on multiple OSes) still on Python 2 so they don't want to break Python 2 support, so it will require more effort to make it Python2/3 compatible.

Comment 15 Lumír Balhar 2019-09-06 08:02:00 UTC
> The problem is if you maintain e.g nearly cca. 100 packages, you receive
> plenty of notifications daily. If there are some auto-generated messages you
> will soon stop reading them - i.e. I read the comment 0 (there are no dates
> and nothing about orphaning and also no orphaning dates) took it into
> account and then I start receiving the same notifications for all of my
> other packages, so I muted them. Then I noticed my packages got orphaned. I
> guess other maintainers could encounter the same problem.

I don't want to discuss it here but I think that the only thing needed here is to read the first comment carefully and also take a look at the linked change description. If you do that, you will know what is happening. No matter if you maintain tens or hundreds of packages because when you read it once, you'll know what will happen to all of them and what the notification emails mean to you.

Comment 16 Jaroslav Škarvada 2019-09-06 09:39:14 UTC
(In reply to Lumír Balhar from comment #15)
> > The problem is if you maintain e.g nearly cca. 100 packages, you receive
> > plenty of notifications daily. If there are some auto-generated messages you
> > will soon stop reading them - i.e. I read the comment 0 (there are no dates
> > and nothing about orphaning and also no orphaning dates) took it into
> > account and then I start receiving the same notifications for all of my
> > other packages, so I muted them. Then I noticed my packages got orphaned. I
> > guess other maintainers could encounter the same problem.
> 
> I don't want to discuss it here but I think that the only thing needed here
> is to read the first comment carefully and also take a look at the linked
> change description. If you do that, you will know what is happening. No
> matter if you maintain tens or hundreds of packages because when you read it
> once, you'll know what will happen to all of them and what the notification
> emails mean to you.

Sorry, I can't understand why you insist on not setting the needinfo - this is what this flag is meant for - to get info from the maintainer and it's zero overhead for you.

Email notifications are not reliable and some maintainers could even disable them. Relying on them is silly at least.

Comment 17 Scott Talbert 2019-11-06 22:03:32 UTC
It looks like quisk now has some support for Python 3.  Is it time to switch to it in Fedora?

Comment 18 Jaroslav Škarvada 2019-11-07 12:57:46 UTC
(In reply to Scott Talbert from comment #17)
> It looks like quisk now has some support for Python 3.  Is it time to switch
> to it in Fedora?

I communicated with upstream regarding this few releases earlier (and I also reported one bug related to the Python 3 enabling code). James (Quisk upstream) is adding Python 3 support step-by-step. I am not sure whether it's ready now, but I am going to re-check.

Comment 19 Jaroslav Škarvada 2019-11-07 13:20:44 UTC
It's not yet ready:

Bytecompiling .py files below /builddir/build/BUILDROOT/quisk-4.1.48-1.fc32.x86_64/usr/lib64/python3.8 using /usr/bin/python3.8
*** Error compiling '/builddir/build/BUILDROOT/quisk-4.1.48-1.fc32.x86_64/usr/lib64/python3.8/site-packages/quisk/afedrinet/afedri.py'...
  File "/usr/lib64/python3.8/afedri.py", line 172
    print "found ", __devname, __sn, __ip, __port
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("found ", __devname, __sn, __ip, __port)?

And there are more.

Comment 20 Jaroslav Škarvada 2019-11-08 21:32:57 UTC
(In reply to Jaroslav Škarvada from comment #19)
> It's not yet ready:
> 
> Bytecompiling .py files below
> /builddir/build/BUILDROOT/quisk-4.1.48-1.fc32.x86_64/usr/lib64/python3.8
> using /usr/bin/python3.8
> *** Error compiling
> '/builddir/build/BUILDROOT/quisk-4.1.48-1.fc32.x86_64/usr/lib64/python3.8/
> site-packages/quisk/afedrinet/afedri.py'...
>   File "/usr/lib64/python3.8/afedri.py", line 172
>     print "found ", __devname, __sn, __ip, __port
>           ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean
> print("found ", __devname, __sn, __ip, __port)?
> 
> And there are more.

Fixed this and other minor problems, notified upstream.


Note You need to log in before you can comment on or make changes to this bug.