From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Dropping Python 2 (python-m2crypto) Date: Tue, 25 May 2021 11:03:09 +0100 Message-ID: In-Reply-To: <8536194f-d8e7-b90a-dbaa-860691ce726d@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2123444014432447978==" List-Id: --===============2123444014432447978== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 22 May 2021, at 13:25, Adolf Belka wrote: >=20 > Hi Michael and All, >=20 > On 20/05/2021 12:15, Michael Tremer wrote: >> Hello, >> Since Core Update 158 is now open, I would like to finish migrating the re= maining Python 2 modules. >> Fedora has dropped crda a little while ago and added some scripts to wirel= ess-regdb: >> https://src.fedoraproject.org/rpms/wireless-regdb >> I think we should follow that path and add the udev rules to lfs/wireless-= regdb and adapt this script for our needs: >> https://src.fedoraproject.org/rpms/wireless-regdb/blob/rawhide/f/setregd= omain > I have been working on this script but I have reached an impasse. > The script as it is, presumes that /etc/localtime is a symlink to one of th= e timezones in /usr/share/zoneinfo/ > If localtime is a file and not a symlink then the scripts man page says tha= t the system admin must create a file called regdomain containing the country= code in /etc/sysconfig/ I believe we are using a hardlink here. I would therefore drop that part of t= he code, or change /etc/localtime to a symlink. > IPFire does not use symlinks to the zoneinfo files so the country code can'= t be created by the script. >=20 > localtime can't just be read as it is a binary file. zdump could read it bu= t that is not available in IPFire as it is commented out in the glibc rootfil= e and anyway it would say that the TZ=3D"/etc/localtime" so that wouldn't hel= p either. I tried it on another system that did have zdump. >=20 > I thought I could use the location routine with the local-ipaddress from re= d but that won't work if IPFire is behind another router as red would then be= a private ip address. >=20 > Then I thought about doing a similar thing as with DDNS to "Guess the real = public IP with help of an external server" but I am not sure if that could be= just done without letting people know we are accessing an external server. >=20 > So I have reached the point where the script will not work as it is and I h= ave not been able to figure out a way to find the country code that has been = selected for the IPFire installation. >=20 > Hopefully there is an easy option that someone can point me to that I have = missed to recognise. How about to make it so simply that we simply read the value from /var/ipfire= /wlanap/settings? Where did we get this data from before? Best, -Michael > Looking forward to any suggestions. >=20 > Regards, >=20 > Adolf. >> We could then drop crda and all dependencies. >> Would you be up for having a look at this? >> -Michael >>> On 14 May 2021, at 20:28, Adolf Belka wrote: >>>=20 >>> Hi Michael, >>>=20 >>> The blockage of nmap to removing python2 was resolved but I have a new on= e now that may be more difficult to resolve. >>>=20 >>> python-m2crypt was able to be successfully built with python3. However cr= da uses python-m2crypt and from what I have read it only works with python2. >>>=20 >>> When I do the build then M2Crypto is in python3.8/site-packages/ and crda= gives the following error >>>=20 >>>=20 >>> make[1]: Entering directory '/usr/src/crda-4.14' >>> GEN keys-gcrypt.c >>> Trusted pubkeys: pubkeys/linville.key.pub.pem pubkeys/sforshee.key.pu= b.pem >>> ERROR: Failed to import the "M2Crypto" module: No module named _m2cry= pto >>> Please install the "M2Crypto" Python module. >>> On Debian GNU/Linux the package is called "python-m2crypto". >>>=20 >>>=20 >>> No matter what I do crda doesn't find python-m2crypto. If I change the py= thon-m2crypto lfs from using >>>=20 >>> cd $(DIR_APP) && python3 setup.py build >>> cd $(DIR_APP) && python3 setup.py install --root=3D/ >>>=20 >>> to >>>=20 >>> cd $(DIR_APP) && python setup.py build >>> cd $(DIR_APP) && python setup.py install --root=3D/ >>>=20 >>> then crda builds successfully. >>>=20 >>> Arch Linux and Gentoo have a python3 patch for crda (the same patch for b= oth) but it makes no difference for my build. >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf >>>=20 >>>=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= conference call this week: Dropping Python 2 >>>>=20 >>>> This version of Python has reached its end of life and will no longer re= ceive 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= be 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= bit more difficult to migrate. We would also have to be very careful to not = change 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 becaus= e we can either force it to build with Python 3 or we just disable the bindin= gs. >>>>=20 >>>> Ultimately we might need to keep Python around in the build system if th= ere 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 d= oes not seem to be too difficult. >>>>=20 >>>> Would anyone be up to help and remove Python from any of those packages = above? I would like to aim for Core Update 158 and remove as much stuff as po= ssible - if we can everything - and then remove Python 2 in the update after = that. If anyone has any custom scripts or applications, people will have some= time to migrate away. >>>>=20 >>>> Best, >>>> -Michael >=20 > --=20 > Sent from my laptop --===============2123444014432447978==--