Bug 1737848

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

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.

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.

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.

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.

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.

The package is yours.

Please could you set needinfo next time? Otherwise this requests can be easily missed.

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

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.

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

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

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

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

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

It looks like quisk now has some support for Python 3.  Is it time to switch to it in Fedora?

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

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.

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