From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Dropping Python 2 (Problem with ipaddr) Date: Tue, 11 May 2021 12:37:34 +0200 Message-ID: In-Reply-To: <74B08C60-EBDB-4C2E-83E0-A5EB5A0C3C5E@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4091469173265606429==" List-Id: --===============4091469173265606429== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, I have run into a problem with ipaddr that I have not been able to solve myse= lf. ipaddr.py has a lot of python2 specific code in it so I ran the 2to3 converto= r on it. That fixed those issues. Then I had the problem that the original ipaddr.py had a mixture of spaces an= d tabs at the line starts. Python2 appears to have accepted this but python3 = doesn't. So I converted all initial line tabs to spaces in the file and reran the buil= d and that problem was solved. Now I am getting the following error message. =C2=A0=C2=A0=C2=A0 cd /usr/src/ipaddr-1.2 && install -m 0644 ipaddr.py /usr/= lib/python3* =C2=A0=C2=A0=C2=A0 /usr/bin/python3 -c "import ipaddr" =C2=A0=C2=A0=C2=A0 Traceback (most recent call last): =C2=A0=C2=A0=C2=A0 File "", line 1, in =C2=A0=C2=A0=C2=A0 File "/usr/lib/python3.8/ipaddr.py", line 1287, in =C2=A0=C2=A0=C2=A0 broadcast_network =3D network('255.255.255.255', 32, DEMA= ND_FILTER) =C2=A0=C2=A0=C2=A0 File "/usr/lib/python3.8/ipaddr.py", line 612, in __init__ =C2=A0=C2=A0=C2=A0 self.ip =3D ipaddr(ip) =C2=A0=C2=A0=C2=A0 File "/usr/lib/python3.8/ipaddr.py", line 351, in __init__ =C2=A0=C2=A0=C2=A0 self.intrep =3D int(ip) =C2=A0=C2=A0=C2=A0 ValueError: invalid literal for int() with base 10: '255.= 255.255.255' =C2=A0=C2=A0=C2=A0 make: *** [ipaddr:75: /usr/src/log/ipaddr-1.2] Error 1 python2 had long variables as well as int. python3 only has the int variables= which are also longs. However python2 long appeared to accept the string '255.255.255.255' as an in= put and python3 does not. I don't know how to deal with this problem. If this issue is a fundamental stop to using ipaddr.py with python3 I have fo= und that python3 has, as standard, ipaddress.py available which I believe is = supposed to cover the same things as ipaddr.py does. I just don't know if it = does it with the same usage format or not. I could not find where in IPFire, = ipaddr.py is being used. Any help, advice, direction is gladly welcomed. Regards, Adolf. On 05/05/2021 16:27, Michael Tremer wrote: > Hello, > > I would like to talk about what has been discussed at the last developer co= nference call this week: Dropping Python 2 > > This version of Python has reached its end of life and will no longer recei= ve any security fixes. Hence we need to get rid of it as soon as possible. > > However, there is lots of software that still depends on it which has to be= migrated away first. > > There are at least the following packages: > > boost > fetchmail > fireinfo > iotop > ipaddr > libxml2 > libxslt > newt > nmap > python > python-clientform > python-daemon > python-distutils > python-distutils-extra > python-docutils > python-feedparser > python-inotify > python-ipaddress > python-m2crypto > python-mechanize > python-optional-src > python-pyparsing > python-rssdler > python-setuptools > python-six > python-typing > > We also have the following scripts: > > config/ca-certificates/certdata2pem.py > config/unbound/unbound-dhcp-leases-bridge > > Fireinfo is written by us and has a lot of C which will make it a little bi= t more difficult to migrate. We would also have to be very careful to not cha= nge any behaviour of the current implementation. > > The rest is probably either software that is entirely written in Python 2 o= r software that brings bindings for Python. The latter case is easy because w= e can either force it to build with Python 3 or we just disable the bindings. > > Ultimately we might need to keep Python around in the build system if there= are other packages that rely on it. However, it would be great if we were ab= le to remove it from the distribution very soon. Looking at his list, it does= not seem to be too difficult. > > Would anyone be up to help and remove Python from any of those packages abo= ve? I would like to aim for Core Update 158 and remove as much stuff as possi= ble - if we can everything - and then remove Python 2 in the update after tha= t. If anyone has any custom scripts or applications, people will have some ti= me to migrate away. > > Best, > -Michael --===============4091469173265606429==--