From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Dropping Python 2 (python-m2crypto) Date: Sat, 29 May 2021 18:19:59 +0200 Message-ID: <02c41825-5dc3-b869-75df-18bd717dc985@ipfire.org> In-Reply-To: <8d91af708bcf98a533d8cce498fcf58db59caea8.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6000328281052083074==" List-Id: --===============6000328281052083074== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Jonatan and Michael, On 29/05/2021 16:31, Jonatan Schlag wrote: > Hi, >=20 > Am Dienstag, den 25.05.2021, 11:03 +0100 schrieb Michael Tremer: >> Hello, >> >>> On 22 May 2021, at 13:25, Adolf Belka wrote: >>> >>> Hi Michael and All, >>> >>> On 20/05/2021 12:15, Michael Tremer wrote: >>>> Hello, >>>> Since Core Update 158 is now open, I would like to finish migrating the = remaining Python 2 modules. >>>> Fedora has dropped crda a little while ago and added some scripts to wir= eless-regdb: >>>> https://src.fedoraproject.org/rpms/wireless-regdb >>>> I think we should follow that path and add the udev rules to lfs/wireles= s-regdb and adapt this script for our needs: >>>> https://src.fedoraproject.org/rpms/wireless-regdb/blob/rawhide/f/setr= egdomain >=20 > read the word "crda" today and was reminded of this thread. As crda seems t= o be deprecated, we could wait for a new kernel, which should make solving th= is problem easier. Thanks Jonatan for finding this status. This might be a better option. >=20 >=20 > Source is: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/= commit/?id=3Df4ef2531698fb9ba006e8b31a223b3269be8bc7c > and https://wiki.gentoo.org/wiki/Hostapd#Proper_use_of_the_5GHz_band >=20 > Jonatan >=20 >>> 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 = the timezones in /usr/share/zoneinfo/ >>> If localtime is a file and not a symlink then the scripts man page says t= hat the system admin must create a file called regdomain containing the count= ry code in /etc/sysconfig/ >> >> I believe we are using a hardlink here. I would therefore drop that part o= f the code, or change /etc/localtime to a symlink. Changing etc/localtime to a softlink would work for new installations but the= problem would be in upgrading existing installations. The localtime hardlink= has no info on the country that was selected only on the timezone which cove= rs multiple countries. So I don't think that changing the hardlink to a softl= ink for localtime is a viable option here. >> >>> IPFire does not use symlinks to the zoneinfo files so the country code ca= n't be created by the script. >>> >>> localtime can't just be read as it is a binary file. zdump could read it = but that is not available in IPFire as it is commented out in the glibc rootf= ile and anyway it would >>> say that the TZ=3D"/etc/localtime" so that wouldn't help either. I tried = it on another system that did have zdump. >>> >>> I thought I could use the location routine with the local-ipaddress from = red but that won't work if IPFire is behind another router as red would then = be a private ip address. >>> >>> Then I thought about doing a similar thing as with DDNS to "Guess the rea= l 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. >>> >>> So I have reached the point where the script will not work as it is and I= have not been able to figure out a way to find the country code that has bee= n selected for the IPFire >>> installation. >>> >>> Hopefully there is an easy option that someone can point me to that I hav= e missed to recognise. >> >> How about to make it so simply that we simply read the value from /var/ipf= ire/wlanap/settings? Where did we get this data from before? Checking the source code files of crda it looks like it just checks the conte= nts of the environment variable COUNTRY. If it is blank or set to 00 then crd= a just provides the global settings to the kernel, ie those that are in line = with every country, and therefore at the lowest applicable level. So using wlanap/settings would be a workable approach as the COUNTRY value co= uld then be used from those settings. So looks like two options:- 1) wait for kernel 4.15 or later to be implemented in IPFire. 2) use the wlanap/settings value for COUNTRY and then add the udev entry as p= er the Fedora approach. Either way I will not be able to test out any change myself as my IPFire syst= em has no built in wireless card. I am using separate Wireless Access Points = in my network. Regards, Adolf >> >> Best, >> -Michael >> >>> Looking forward to any suggestions. >>> >>> Regards, >>> >>> 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: >>>>> >>>>> Hi Michael, >>>>> >>>>> The blockage of nmap to removing python2 was resolved but I have a new = one now that may be more difficult to resolve. >>>>> >>>>> python-m2crypt was able to be successfully built with python3. However = crda uses python-m2crypt and from what I have read it only works with python2. >>>>> >>>>> When I do the build then M2Crypto is in python3.8/site-packages/ and cr= da gives the following error >>>>> >>>>> >>>>> make[1]: Entering directory '/usr/src/crda-4.14' >>>>> GEN keys-gcrypt.c >>>>> Trusted pubkeys: pubkeys/linville.key.pub.pem pubkeys/sforshee.key= .pub.pem >>>>> ERROR: Failed to import the "M2Crypto" module: No module named _m2= crypto >>>>> Please install the "M2Crypto" Python module. >>>>> On Debian GNU/Linux the package is called "python-m2crypto". >>>>> >>>>> >>>>> No matter what I do crda doesn't find python-m2crypto. If I change the = python-m2crypto lfs from using >>>>> >>>>> cd $(DIR_APP) && python3 setup.py build >>>>> cd $(DIR_APP) && python3 setup.py install --root=3D/ >>>>> >>>>> to >>>>> >>>>> cd $(DIR_APP) && python setup.py build >>>>> cd $(DIR_APP) && python setup.py install --root=3D/ >>>>> >>>>> then crda builds successfully. >>>>> >>>>> Arch Linux and Gentoo have a python3 patch for crda (the same patch for= both) but it makes no difference for my build. >>>>> >>>>> >>>>> 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 develop= er conference call this week: Dropping Python 2 >>>>>> >>>>>> This version of Python has reached its end of life and will no longer = receive any security fixes. Hence we need to get rid of it as soon as possibl= e. >>>>>> >>>>>> 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 litt= le bit more difficult to migrate. We would also have to be very careful to no= t change any behaviour >>>>>> of the current implementation. >>>>>> >>>>>> The rest is probably either software that is entirely written in Pytho= n 2 or software that brings bindings for Python. The latter case is easy beca= use we 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 we= re able 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 package= s above? I would like to aim for Core Update 158 and remove as much stuff as = possible - if we can >>>>>> everything - and then remove Python 2 in the update after that. If any= one has any custom scripts or applications, people will have some time to mig= rate away. >>>>>> >>>>>> Best, >>>>>> -Michael >>> >>> --=20 >>> Sent from my laptop >=20 --===============6000328281052083074==--