Hi All,
On 04/08/2021 16:45, Michael Tremer wrote:
Hello,
On 4 Aug 2021, at 13:40, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
I have resolved the frr program build. The version currently in IPFire (6.0) only works with python2. Python3 support came in with version 7.4. I have now built frr with version 8.0 including libyang as a new dependency but only for the build, so nothing installed into IPFire itself, and that has successfully built without python2 being present.
Great. This could also resolve Matthias’ problem with building frr.
Will now go back and have another go with spice-protocol.
Maybe it has a —-disable-python switch?
I just removed the line in the spice-protocol lfs that ran automake/py-compile on the python modules from spice. Spice and spice-protocol are present for qemu and with the py-compile line removed all three successfully built without python2 being present. I have submitted a patch for this combined with updating spice and spice-protocol, both from 2017.
This now only leaves the ca-certificates script that needs to be updated to work with python3.
Regards, Adolf.
-Michael
Regards,
Adolf.
On 03/08/2021 23:38, Adolf Belka wrote:
Hi Michael & all,
On 03/08/2021 17:11, Michael Tremer wrote:
Hello,
Thank you for looking into this.
This is a third-party script that came from either Mozilla or RedHat. Maybe they have ported it. If not, it should not be rocket science to do it ourselves. If we do it, we should of course upstream it.
I found an updated script from fedora and gave that a try. This time the script went all the way through but then the build.sh script failed at the point where it should find all the .crt files in the certs directory and it came back and said there weren't any.
However, can you comment out this package and continue the build? This should be required until you reach the cdrom stage.
I then commented ca-certificates out in make.sh and ran the build. This time it stopped at spice-protocol which is an addon and uses the py-compile script that is in automake to compile some python modules. py-compile is python2 based and the build stopped because it could not find python
There is a py_compile.py script that is python3 based but when I ran that in place of the py-compile script I got a Permission denied error when it tried to carry out the compile.
I then commented out spice-protocol and ran the build.
It then failed on frr which did look for python3-config but then failed due to not finding python-config or pkg-config python It looks like I should be able to tell it to use python3 in the ./configure
I commented out frr and nothing else failed before cdrom was reached.
So the packages that need to be made to work with python3 are ca-certificates spice-protocol frr
I also converted client175 with 2to3 converter and built it and installed the .ipfire package into a vm and successfully got the WUI page for Media Player IPFire to render. What I haven't tested yet is if the audio works. I will need to get audio set up in my vm to try that.
Regards, Adolf.
If this is the only thing that flags up, we should port the script. If we find another, stronger reason to keep Python 2 around, we do not need to bother and can keep the script this way.
-Michael
On 3 Aug 2021, at 13:31, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
So with crda and the remaining python2 modules removed the question was if removing python2 from the build ran without any problem or if something was flagged up.
ca-certificates was flagged up.
There is a python2 script, certdata2pem.py, which fails if python2 is not present. Running that script with python3 flags up some invalid syntax, unsurprisingly.
I found some patches in Debian from 2015 for certdata2pem.py to provide python3 compatibility. Unfortunately looking at the patch approx half could not be applied because the lines don't exist in the IPFire version of certdata2pem.py (sections to do with blacklisted certs)
I then ran the 2to3 converter on certdata2pem.py and tried that in the build but it came up with the following error.
TypeError: a bytes-like object is required, not 'str'
I don't know how to further move forward with this as I am totally unfamiliar with the python language.
Regards,
Adolf.