From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Dropping Python 2 (Problem with ipaddr) Date: Tue, 11 May 2021 11:40:15 +0100 Message-ID: <736E15A7-874F-42E5-B0C9-0E4C875977A1@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1466755423365511732==" List-Id: --===============1466755423365511732== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Python3 comes with an own module to handle IP addresses. Therefore I am not s= ure if there is any need to bundle any of the alternative ones. What is depending on this? Can we not simply drop this? -Michael > On 11 May 2021, at 11:37, Adolf Belka wrote: >=20 > Hi All, >=20 > I have run into a problem with ipaddr that I have not been able to solve my= self. >=20 > ipaddr.py has a lot of python2 specific code in it so I ran the 2to3 conver= tor on it. That fixed those issues. >=20 > Then I had the problem that the original ipaddr.py had a mixture of spaces = and tabs at the line starts. Python2 appears to have accepted this but python= 3 doesn't. >=20 > So I converted all initial line tabs to spaces in the file and reran the bu= ild and that problem was solved. >=20 > Now I am getting the following error message. >=20 > cd /usr/src/ipaddr-1.2 && install -m 0644 ipaddr.py /usr/lib/python3* > /usr/bin/python3 -c "import ipaddr" > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3.8/ipaddr.py", line 1287, in > broadcast_network =3D network('255.255.255.255', 32, DEMAND_FILTER) > File "/usr/lib/python3.8/ipaddr.py", line 612, in __init__ > self.ip =3D ipaddr(ip) > File "/usr/lib/python3.8/ipaddr.py", line 351, in __init__ > self.intrep =3D int(ip) > ValueError: invalid literal for int() with base 10: '255.255.255.255' > make: *** [ipaddr:75: /usr/src/log/ipaddr-1.2] Error 1 >=20 > python2 had long variables as well as int. python3 only has the int variabl= es which are also longs. >=20 > However python2 long appeared to accept the string '255.255.255.255' as an = input and python3 does not. >=20 > I don't know how to deal with this problem. >=20 >=20 > If this issue is a fundamental stop to using ipaddr.py with python3 I have = found that python3 has, as standard, ipaddress.py available which I believe i= s supposed to cover the same things as ipaddr.py does. I just don't know if i= t does it with the same usage format or not. I could not find where in IPFire= , ipaddr.py is being used. >=20 >=20 > Any help, advice, direction is gladly welcomed. >=20 >=20 > Regards, >=20 > Adolf. >=20 > On 05/05/2021 16:27, Michael Tremer wrote: >> Hello, >>=20 >> I would like to talk about what has been discussed at the last developer c= onference call this week: Dropping Python 2 >>=20 >> This version of Python has reached its end of life and will no longer rece= ive any security fixes. Hence we need to get rid of it as soon as possible. >>=20 >> However, there is lots of software that still depends on it which has to b= e migrated away first. >>=20 >> There are at least the following packages: >>=20 >> 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 >>=20 >> We also have the following scripts: >>=20 >> config/ca-certificates/certdata2pem.py >> config/unbound/unbound-dhcp-leases-bridge >>=20 >> Fireinfo is written by us and has a lot of C which will make it a little b= it more difficult to migrate. We would also have to be very careful to not ch= ange any behaviour of the current implementation. >>=20 >> The rest is probably either software that is entirely written in Python 2 = or software that brings bindings for Python. The latter case is easy because = we can either force it to build with Python 3 or we just disable the bindings. >>=20 >> Ultimately we might need to keep Python around in the build system if ther= e are other packages that rely on it. However, it would be great if we were a= ble to remove it from the distribution very soon. Looking at his list, it doe= s not seem to be too difficult. >>=20 >> Would anyone be up to help and remove Python from any of those packages ab= ove? I would like to aim for Core Update 158 and remove as much stuff as poss= ible - if we can everything - and then remove Python 2 in the update after th= at. If anyone has any custom scripts or applications, people will have some t= ime to migrate away. >>=20 >> Best, >> -Michael --===============1466755423365511732==--