Bug#939181: cycle: Python2 removal in sid/bullseye

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#939181: cycle: Python2 removal in sid/bullseye

Scott Talbert
Package: src:cycle
Version: 0.3.1-14
Severity: normal
Tags: sid bullseye
User: [hidden email]
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
   case you are providing a Python module foo, please consider dropping
   the python-foo package, and only build a python3-foo package.  Please
   don't drop Python2 modules, which still have reverse dependencies,
   just document them.

   This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
   in Debian, it should be removed from the distribution.  If the
   package still has reverse dependencies, raise the severity to
   "serious" and document the reverse dependencies with the BTS affects
   command.  If the package has no reverse dependencies, confirm that
   the package can be removed, reassign this issue to ftp.debian.org,
   make sure that the bug priority is set to normal and retitle the
   issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
   build another package which cannot be removed, document that by
   adding the "py2keep" user tag (not replacing the py2remove tag),
   using the [hidden email] user.  Also any
   dependencies on an unversioned python package (python, python-dev)
   must not be used, same with the python shebang.  These have to be
   replaced by python2/python2.7 dependencies and shebang.

   This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

   affects <bug number of blocking py2removal bug> + src:cycle

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the [hidden email] mailing list.

Reply | Threaded
Open this post in threaded view
|

Bug#939181: cycle: Python2 removal in sid/bullseye

Antonio Terceiro-3
Package: cycle
Version: 0.3.1-15
Followup-For: Bug #939181
Control: reopen 939181

This update did not fix the issue, as the app now does not work at all.

$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  python-talloc python-wxgtk3.0 python-wxversion
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  libomp-dev
The following packages will be upgraded:
  cycle
1 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/45,4 kB of archives.
After this operation, 15,4 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 507326 files and directories currently installed.)
Preparing to unpack .../cycle_0.3.1-15_all.deb ...
Unpacking cycle (0.3.1-15) over (0.3.1-14) ...
Setting up cycle (0.3.1-15) ...
Sorry: TabError: inconsistent use of tabs and spaces in indentation (cycle.py, line 29)
dpkg: error processing package cycle (--configure):
 installed cycle package post-installation script subprocess returned error exit status 1
Processing triggers for desktop-file-utils (0.24-1) ...
Processing triggers for mime-support (3.63) ...
Processing triggers for gnome-menus (3.32.0-1) ...
Processing triggers for man-db (2.8.7-3) ...
Errors were encountered while processing:
 cycle
======  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ======

-----  Show old opportunities as well as new ones: how-can-i-help --old  -----
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
~[100]$ cycle
  File "/usr/bin/cycle", line 29
    if lang_find:
                ^
TabError: inconsistent use of tabs and spaces in indentation



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cycle depends on:
ii  python3           3.7.3-1
ii  python3-wxgtk4.0  4.0.6+dfsg-2

cycle recommends no packages.

cycle suggests no packages.

-- no debconf information

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andreas Tille-5
Control: tags -1 help

On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote:
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> ~[100]$ cycle
>   File "/usr/bin/cycle", line 29
>     if lang_find:
>                 ^
> TabError: inconsistent use of tabs and spaces in indentation

Argh.  That's fixed via autopep8 in Git[1] now.  However, when calling
cycle I get

$ cycle
Traceback (most recent call last):
  File "/usr/bin/cycle", line 12, in <module>
    from dialogs import *
  File "/usr/share/cycle/dialogs.py", line 8, in <module>
    from cal_year import cycle, Val
  File "/usr/share/cycle/cal_year.py", line 9, in <module>
    from dialogs import Note_Dlg
ImportError: cannot import name 'Note_Dlg' from 'dialogs' (/usr/share/cycle/dialogs.py)


Any idea how to fix this?

Kind regards

     Andreas.


[1]  https://salsa.debian.org/med-team/cycle

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andrey Rahmatullin-3
On Wed, Sep 11, 2019 at 04:12:34PM +0200, Andreas Tille wrote:

> Control: tags -1 help
>
> On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote:
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > ~[100]$ cycle
> >   File "/usr/bin/cycle", line 29
> >     if lang_find:
> >                 ^
> > TabError: inconsistent use of tabs and spaces in indentation
>
> Argh.  That's fixed via autopep8 in Git[1] now.  However, when calling
> cycle I get
>
> $ cycle
> Traceback (most recent call last):
>   File "/usr/bin/cycle", line 12, in <module>
>     from dialogs import *
>   File "/usr/share/cycle/dialogs.py", line 8, in <module>
>     from cal_year import cycle, Val
>   File "/usr/share/cycle/cal_year.py", line 9, in <module>
>     from dialogs import Note_Dlg
> ImportError: cannot import name 'Note_Dlg' from 'dialogs' (/usr/share/cycle/dialogs.py)
There are circular imports in the code so you most likely broke that by
reordering imports in various files.
"from cal_year import *; from dialogs import *" works, the reverse
doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
about other changes.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andreas Tille-2
Hi Andrey,

On Wed, Sep 11, 2019 at 07:32:33PM +0500, Andrey Rahmatullin wrote:

> > $ cycle
> > Traceback (most recent call last):
> >   File "/usr/bin/cycle", line 12, in <module>
> >     from dialogs import *
> >   File "/usr/share/cycle/dialogs.py", line 8, in <module>
> >     from cal_year import cycle, Val
> >   File "/usr/share/cycle/cal_year.py", line 9, in <module>
> >     from dialogs import Note_Dlg
> > ImportError: cannot import name 'Note_Dlg' from 'dialogs' (/usr/share/cycle/dialogs.py)
> There are circular imports in the code so you most likely broke that by
> reordering imports in various files.

s/you most likely broke/2to3 most likely broke/

I admit I did not really checked what 2to3 created but I can assure you
I did not simply fired up an editor and had fun reverting some import
sequences.

> "from cal_year import *; from dialogs import *" works, the reverse
> doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
> about other changes.

I can not confirm that

   from cal_year import *

works at all.  It works in the unpatched Python2 version.

   git clone https://salsa.debian.org/med-team/cycle
   cd cycle
   echo "from cal_year import *" | python
   quilt push -a
   echo "from cal_year import *" | python3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 9, in <module>
    from dialogs import Note_Dlg
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 12, in <module>
    from cal_year import cycle, Val
ImportError: cannot import name 'cycle' from 'cal_year' (/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py)


So may be I misinterpreted your hint but even reverting the reordering
of 2to3 in my latest commit does not help.

Kind regards

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andrey Rahmatullin-3
On Thu, Sep 12, 2019 at 09:17:08AM +0200, Andreas Tille wrote:

> > > $ cycle
> > > Traceback (most recent call last):
> > >   File "/usr/bin/cycle", line 12, in <module>
> > >     from dialogs import *
> > >   File "/usr/share/cycle/dialogs.py", line 8, in <module>
> > >     from cal_year import cycle, Val
> > >   File "/usr/share/cycle/cal_year.py", line 9, in <module>
> > >     from dialogs import Note_Dlg
> > > ImportError: cannot import name 'Note_Dlg' from 'dialogs' (/usr/share/cycle/dialogs.py)
> > There are circular imports in the code so you most likely broke that by
> > reordering imports in various files.
>
> s/you most likely broke/2to3 most likely broke/
2to3 doesn't do that. You mentioned autopep8, it could do that.

> > "from cal_year import *; from dialogs import *" works, the reverse
> > doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
> > about other changes.
>
> I can not confirm that
>
>    from cal_year import *
>
> works at all.  It works in the unpatched Python2 version.
I was just saying that (in the unpatched Python2 version) "from cal_year
import *; from dialogs import *" works, the reverse doesn't, and the
patched version contains the reverse.

>    git clone https://salsa.debian.org/med-team/cycle
>    cd cycle
>    echo "from cal_year import *" | python
>    quilt push -a
>    echo "from cal_year import *" | python3
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 9, in <module>
>     from dialogs import Note_Dlg
>   File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 12, in <module>
>     from cal_year import cycle, Val
> ImportError: cannot import name 'cycle' from 'cal_year' (/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py)
>
>
> So may be I misinterpreted your hint but even reverting the reordering
> of 2to3 in my latest commit does not help.
I also said that other changes may be problematic too. I didn't check
them.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andreas Tille-5
On Thu, Sep 12, 2019 at 01:57:32PM +0500, Andrey Rahmatullin wrote:
> > > There are circular imports in the code so you most likely broke that by
> > > reordering imports in various files.
> >
> > s/you most likely broke/2to3 most likely broke/
> 2to3 doesn't do that. You mentioned autopep8, it could do that.

Ahhh, well, that might be another way to mess up the sequence.  Put a
mental note to warn me about autodep8.
 
> > So may be I misinterpreted your hint but even reverting the reordering
> > of 2to3 in my latest commit does not help.
> I also said that other changes may be problematic too. I didn't check
> them.

OK, I redid the patching in git[1] now.  Some more wxPython 4 porting
was needed as well but I somehow got the user interface working.  May be
some final helping hint could be how to fix leaving the program that
leads to:


Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
    Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 27, in Save_Cycle
    m.update(passwd)
TypeError: Unicode-objects must be encoded before hashing


I tried

  m.update(passwd.encode())

but this leads later to

Traceback (most recent call last):
  File "cycle.py", line 83, in OnCloseWindow
    Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 46, in Save_Cycle
    tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) )
TypeError: can only concatenate str (not "bytes") to str


Since I do not have much experience with hashlib I'd be happy if someone
might be able to proof-read `def Save_Cycle` in save_load.py.

Kind regards

      Andreas.


[1] https://salsa.debian.org/med-team/cycle

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

peter green-2
In reply to this post by Scott Talbert

but this leads later to

Traceback (most recent call last):
  File "cycle.py", line 83, in OnCloseWindow
    Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 46, in Save_Cycle
    tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) )
TypeError: can only concatenate str (not "bytes") to str
String handling changed significantly between python2 and python3. Python 2 is "byte strings by default", type "str" was used for byte strings and type "unicode" was used for unicode strings. Implicit conversions between the two were allowed.

Python 3 is "unicode by default", type "bytes" is used for byte strings and type "str" is used for unicode strings. There is no implict conversion between unicode strings and byte strings.

"pickle.dumps" returned a bytes object, and you tried to concatenate it to a str object. You need to change 'Cycle' to b'Cycle'.

Also python 3 bytes objects behave a bit differently from python 2 str objects. To accommodate this I believe you need the following changes in p_rotor.py

"for c in map(ord, buf):" -> "for c in buf:"
"return ''.join(map(chr, outbuf))" -> "return bytes(outbuf)"
"for c in map(ord, key):" -> "for c in key:"

Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andreas Tille-2
In reply to this post by Scott Talbert
Hi,

On Thu, Sep 12, 2019 at 09:08:04PM +0200, Michael Kesper wrote:

> > Since I do not have much experience with hashlib I'd be happy if
> > someone might be able to proof-read `def Save_Cycle` in
> > save_load.py.
>
> This does not have anything to do with hashlib per se.
> It's just the usual mess of mixing bytestrings with strings.
> You often don't notice in Python2, it just introduces subtle bugs.
> Python3 is more strict here and doesn't allow it.
>
> Try this:
>
> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint and the other hints by Peter Green, I'm now a
bit further.
 
> As an explanation:
>
> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
> ...

Thanks as well.

> P.S.: The code is in a bad state regarding whitespace / indentation.
> This is critical to get right in Python (e.g. after a for there _has to_
> be an indentation added, Python normally uses four spaces, no tabs).

I'm aware that the code is not good - there are other issues than spaces
and tabs for instance I removed an instance of os.tempnam where upstream
simply had overridden the automatic warning.  Its unmaintained upstream
as well.

I've seen other code in Debian which is not good as well.  Its rather a
philosophical question whether it is better to drop it from Debian (and
leave its users alone may be fiddling around with the upstream code
themselves) or whether we try our best to make the code at least
acceptable.  I usually subscribe to the latter and think there is no
right or wrong here.

I'm not really sure whether we might manage in this case.  After
implementing all hints I'm now stumbling upon:


Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
    Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
    tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
    return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
    c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'str' and 'int'


I think an  "int(c) ^ pos[i]"  could do here - but I'd like
to get some confirmation first.

Kind regards

     Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

peter green-2
In reply to this post by Scott Talbert

> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint 
This hint was *wrong*, it will introduce garbage into the string and the "rotor" code is clearly designed to work with byte strings, not unicode strings.

Change it to
"tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"


Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Andreas Tille-5
Hi Peter,

On Sun, Sep 15, 2019 at 02:47:50PM +0100, peter green wrote:
> > > tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
> >
> > Thanks to this hint
> This hint was *wrong*, it will introduce garbage into the string and the "rotor" code is clearly designed to work with byte strings, not unicode strings.
>
> Change it to
>
> "tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"

Thanks a lot for your patience.  Unfortunately this is not
yet the final solution:

...
Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
    Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
    tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
    return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
    c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'int' and 'float'


Kind regards

       Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

peter green-2
On 16/09/2019 10:38, Andreas Tille wrote:
Hi Peter,

On Sun, Sep 15, 2019 at 02:47:50PM +0100, peter green wrote:
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
Thanks to this hint
This hint was *wrong*, it will introduce garbage into the string and the "rotor" code is clearly designed to work with byte strings, not unicode strings.

Change it to

"tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"
Thanks a lot for your patience.  Unfortunately this is not
yet the final solution:

...
Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
    Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
    tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
    return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
    c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'int' and 'float'


Kind regards

       Andreas. 

When you get a floating point number where you were expecting an integer that is probably an issue related to the change in behavior of the division operator in python 3. In python 2 using the regular division operator on two integers produces an integer result, but in python 3 it produces a floating point result.

I see a few cases in the p_rotor code where regular division is used in a way that python2 would interpret it as floored division but python3 would interpret it as floating point division.

"drotor[i] = erotor[i] = 1 + 2*rand(i/2) # increment" -> "drotor[i] = erotor[i] = 1 + 2*rand(i//2) # increment"
"
x = 171 * (x % 177) - 2 * (x/177)" -> "x = 171 * (x % 177) - 2 * (x//177)"
"
y = 172 * (y % 176) - 35 * (y/176)" -> "y = 172 * (y % 176) - 35 * (y//176)"
"z = 170 * (z % 178) - 63 * (z/178)" -> "z = 170 * (z % 178) - 63 * (z//178)"


Reply | Threaded
Open this post in threaded view
|

Bug#939181: cycle: Python2 removal in sid/bullseye - reopen 939181

Sandro Tosi-6
In reply to this post by Scott Talbert
Control: reopen -1

This bug was closed, but the package has still some dependencies towards
Python2 packages, in details:

(source:cycle)Build-Depends-Indep->python
(binary:cycle)Depends->python2:any
(binary:cycle)Depends->python2:any
(binary:cycle)Depends->python-wxgtk3.0

Re-opening, so that they can be taken care of.
Reply | Threaded
Open this post in threaded view
|

Bug#939181: cycle: should it be RM'd ?

Scott Talbert
In reply to this post by Scott Talbert
Hi all,

Is there any hope for a Python 3 port of cycle, or should it just be RM'd?

Scott

Reply | Threaded
Open this post in threaded view
|

Bug#939181: cycle: should it be RM'd ?

Andreas Tille-2
On Tue, Jan 28, 2020 at 10:56:23AM -0500, Scott Talbert wrote:
> Is there any hope for a Python 3 port of cycle, or should it just be RM'd?

Ana, could you please have a last word about this?

Kind regards

       Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#939181: cycle: should it be RM'd ?

Ana Guerrero Lopez
On Tue, Jan 28, 2020 at 06:06:59PM +0100, Andreas Tille wrote:
> On Tue, Jan 28, 2020 at 10:56:23AM -0500, Scott Talbert wrote:
> > Is there any hope for a Python 3 port of cycle, or should it just be RM'd?
>
> Ana, could you please have a last word about this?
>
Thanks Andreas.

I haven't given up yet in a Python 3 port, but if cycle must be removed for the
sake of removing Python 2, just do it. It's always possible to re-introduce
the package later.

Cheers,
Ana

Reply | Threaded
Open this post in threaded view
|

Bug#939181: RM cycle

Scott Talbert
In reply to this post by Scott Talbert
reassign -1 ftp.debian.org
retitle -1 RM: cycle -- RoQA; dead upstream; unmaintained; low popcon; blocking py2 removal