From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Dropping Python 2 (Problem with ipaddr)
Date: Sat, 15 May 2021 13:51:39 +0200
Message-ID: <8cc5e9ac-518d-5282-6832-92b907a43519@ipfire.org>
In-Reply-To: <736E15A7-874F-42E5-B0C9-0E4C875977A1@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0698724369650343465=="
List-Id: <development.lists.ipfire.org>

--===============0698724369650343465==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael, All

On 11/05/2021 12:40, Michael Tremer wrote:
> Hello,
>=20
> Python3 comes with an own module to handle IP addresses. Therefore I am not=
 sure if there is any need to bundle any of the alternative ones.
>=20
> What is depending on this? Can we not simply drop this?
There has not been any further response on this. Should I raise a patch to re=
move this module from IPFire?

Regards,
Adolf.
>=20
> -Michael
>=20
>> On 11 May 2021, at 11:37, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi All,
>>
>> I have run into a problem with ipaddr that I have not been able to solve m=
yself.
>>
>> ipaddr.py has a lot of python2 specific code in it so I ran the 2to3 conve=
rtor on it. That fixed those issues.
>>
>> 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 pytho=
n3 doesn't.
>>
>> So I converted all initial line tabs to spaces in the file and reran the b=
uild and that problem was solved.
>>
>> Now I am getting the following error message.
>>
>>      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 "<string>", line 1, in <module>
>>      File "/usr/lib/python3.8/ipaddr.py", line 1287, in <module>
>>      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
>>
>> python2 had long variables as well as int. python3 only has the int variab=
les which are also longs.
>>
>> However python2 long appeared to accept the string '255.255.255.255' as an=
 input 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=
 found 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 IPFir=
e, 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 =
conference call this week: Dropping Python 2
>>>
>>> This version of Python has reached its end of life and will no longer rec=
eive 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 =
bit more difficult to migrate. We would also have to be very careful to not c=
hange any behaviour of the current implementation.
>>>
>>> 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 binding=
s.
>>>
>>> Ultimately we might need to keep Python around in the build system if the=
re are other packages that rely on it. However, it would be great if we were =
able to remove it from the distribution very soon. Looking at his list, it do=
es not seem to be too difficult.
>>>
>>> Would anyone be up to help and remove Python from any of those packages a=
bove? I would like to aim for Core Update 158 and remove as much stuff as pos=
sible - if we can everything - and then remove Python 2 in the update after t=
hat. If anyone has any custom scripts or applications, people will have some =
time to migrate away.
>>>
>>> Best,
>>> -Michael
>=20

--===============0698724369650343465==--