From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: First results from running build without python2 Date: Mon, 23 Aug 2021 11:36:48 +0100 Message-ID: In-Reply-To: <94879785-3bf3-13e5-58d2-97321f1fd39c@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4351674235461650402==" List-Id: --===============4351674235461650402== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 20 Aug 2021, at 21:17, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 20/08/2021 18:38, Michael Tremer wrote: >> Hello, >>> On 20 Aug 2021, at 11:17, Adolf Belka wrote: >>>=20 >>> Hi Michael and everyone, >>>=20 >>> After disabling python on collectd, freeradius and alsa I have been able = to successfully do a complete build with next with python2 removed. >> Very good news! >> I think you can submit those patches already because we can merge them str= aight away. > Patches submitted. Very good. I had a look through them and they look fine. It has made me very = happy that we are now ready to remove Python 2. >>> I will now create patches for the above three programs and also for the f= ix for ca-certificates. With the other patches already submitted we can then = decide in which Core Update to remove python2. >> Agreed. If you like you can submit a patch that removes Python 2 from the = build which we will merge at a later time. > I will submit a patch for this. Cool. No hurry on this one. >> I would suggest Core Update 161. >> This would be a great milestone and make the distribution smaller, and mos= t importantly, remove another large piece of software that is unmaintained up= stream. Thanks for your hard work on this! > I have enjoyed working on this, meeting the challenges and overcoming them = with the support given to me. I have learnt a lot while doing this as well. Judging from the patches this was definitely the most complicated stuff that = you have submitted so far, but you did it absolutely fine. Cannot complain ab= out a thing. I owe you a beer for this :) > Now my fingers are crossed that what worked in my builds will work when mer= ged but if not then I will work to fix any problems that might arise. Hopefully not. Fingers crossed :) -Michael > Regards, > Adolf. >> Best, >> -Michael >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>=20 >>> On 19/08/2021 22:54, Adolf Belka wrote: >>>> Hi Michael, >>>>=20 >>>> On 19/08/2021 18:28, Adolf Belka wrote: >>>>> Hi Michael, >>>>>=20 >>>>> On 19/08/2021 15:54, Michael Tremer wrote: >>>>>> Hello Adolf, >>>>>>=20 >>>>>> This sounds very good. >>>>>>=20 >>>>>>> On 18 Aug 2021, at 22:08, Adolf Belka wrot= e: >>>>>>>=20 >>>>>>> Hi All, >>>>>>>=20 >>>>>>> I have successfully built ca-certificates with the new p11-kit approa= ch. The only difference is that the certificate data such as Version, Serial = Number, Signature Algorithm etc is no longer included in the created bundle f= iles. There is only the actual certificate itself. >>>>>>=20 >>>>>> I do not exactly understand what you mean. Can you post a file system = listing or something that would help me?The first certificate in the new ca-b= undle.crt looks like the following:- >>>>>=20 >>>>> # ACCVRAIZ1 >>>>> -----BEGIN CERTIFICATE----- >>>>> MIIH0zCCBbugAwIBAgIIXsO3pkN/pOAwDQYJKoZIhvcNAQEFBQAwQjESMBAGA1UE >>>>> AwwJQUNDVlJBSVoxMRAwDgYDVQQLDAdQS0lBQ0NWMQ0wCwYDVQQKDARBQ0NWMQsw >>>>> CQYDVQQGEwJFUzAeFw0xMTA1MDUwOTM3MzdaFw0zMDEyMzEwOTM3MzdaMEIxEjAQ >>>>> BgNVBAMMCUFDQ1ZSQUlaMTEQMA4GA1UECwwHUEtJQUNDVjENMAsGA1UECgwEQUND >>>>> VjELMAkGA1UEBhMCRVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCb >>>>> qau/YUqXry+XZpp0X9DZlv3P4uRm7x8fRzPCRKPfmt4ftVTdFXxpNRFvu8gMjmoY >>>>> HtiP2Ra8EEg2XPBjs5BaXCQ316PWywlxufEBcoSwfdtNgM3802/J+Nq2DoLSRYWo >>>>> G2ioPej0RGy9ocLLA76MPhMAhN9KSMDjIgro6TenGEyxCQ0jVn8ETdkXhBilyNpA >>>>> lHPrzg5XPAOBOp0KoVdDaaxXbXmQeOW1tDvYvEyNKKGno6e6Ak4l0Squ7a4DIrhr >>>>> IA8wKFSVf+DuzgpmndFALW4ir50awQUZ0m/A8p/4e7MCQvtQqR0tkw8jq8bBD5L/ >>>>> 0KIV9VMJcRz/RROE5iZe+OCIHAr8Fraocwa48GOEAqDGWuzndN9wrqODJerWx5eH >>>>> k6fGioozl2A3ED6XPm4pFdahD9GILBKfb6qkxkLrQaLjlUPTAYVtjrs78yM2x/47 >>>>> 4KElB0iryYl0/wiPgL/AlmXz7uxLaL2diMMxs0Dx6M/2OLuc5NF/1OVYm3z61PMO >>>>> m3WR5LpSLhl+0fXNWhn8ugb2+1KoS5kE3fj5tItQo05iifCHJPqDQsGH+tUtKSpa >>>>> cXpkatcnYGMN285J9Y0fkIkyF/hzQ7jSWpOGYdbhdQrqeWZ2iE9x6wQl1gpaepPl >>>>> uUsXQA+xtrn13k/c4LOsOxFwYIRKQ26ZIMApcQrAZQIDAQABo4ICyzCCAscwfQYI >>>>> KwYBBQUHAQEEcTBvMEwGCCsGAQUFBzAChkBodHRwOi8vd3d3LmFjY3YuZXMvZmls >>>>> ZWFkbWluL0FyY2hpdm9zL2NlcnRpZmljYWRvcy9yYWl6YWNjdjEuY3J0MB8GCCsG >>>>> AQUFBzABhhNodHRwOi8vb2NzcC5hY2N2LmVzMB0GA1UdDgQWBBTSh7Tj3zcnk1X2 >>>>> VuqB5TbMjB4/vTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNKHtOPfNyeT >>>>> VfZW6oHlNsyMHj+9MIIBcwYDVR0gBIIBajCCAWYwggFiBgRVHSAAMIIBWDCCASIG >>>>> CCsGAQUFBwICMIIBFB6CARAAQQB1AHQAbwByAGkAZABhAGQAIABkAGUAIABDAGUA >>>>> cgB0AGkAZgBpAGMAYQBjAGkA8wBuACAAUgBhAO0AegAgAGQAZQAgAGwAYQAgAEEA >>>>> QwBDAFYAIAAoAEEAZwBlAG4AYwBpAGEAIABkAGUAIABUAGUAYwBuAG8AbABvAGcA >>>>> 7QBhACAAeQAgAEMAZQByAHQAaQBmAGkAYwBhAGMAaQDzAG4AIABFAGwAZQBjAHQA >>>>> cgDzAG4AaQBjAGEALAAgAEMASQBGACAAUQA0ADYAMAAxADEANQA2AEUAKQAuACAA >>>>> QwBQAFMAIABlAG4AIABoAHQAdABwADoALwAvAHcAdwB3AC4AYQBjAGMAdgAuAGUA >>>>> czAwBggrBgEFBQcCARYkaHR0cDovL3d3dy5hY2N2LmVzL2xlZ2lzbGFjaW9uX2Mu >>>>> aHRtMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly93d3cuYWNjdi5lcy9maWxlYWRt >>>>> aW4vQXJjaGl2b3MvY2VydGlmaWNhZG9zL3JhaXphY2N2MV9kZXIuY3JsMA4GA1Ud >>>>> DwEB/wQEAwIBBjAXBgNVHREEEDAOgQxhY2N2QGFjY3YuZXMwDQYJKoZIhvcNAQEF >>>>> BQADggIBAJcxAp/n/UNnSEQU5CmH7UwoZtCPNdpNYbdKl02125DgBS4OxnnQ8pdp >>>>> D70ER9m+27Up2pvZrqmZ1dM8MJP1jaGo/AaNRPTKFpV8M9xii6g3+CfYCS0b78gU >>>>> JyCpZET/LtZ1qmxNYEAZSUNUY9rizLpm5U9EelvZaoErQNV/+QEnWCzI7UiRfD+m >>>>> AM/EKXMRNt6GGT6d7hmKG9Ww7Y49nCrADdg9ZuM8Db3VlFzi4qc1GwQA9j9ajepD >>>>> vV+JHanBsMyZ4k0ACtrJJ1vnE5Bc5PUzolVt3OAJTS+xJlsndQAJxGJ3KQhfnlms >>>>> tn6tn1QwIgPBHnFk/vk4CpYY3QIUrCPLBhwepH2NDd4nQeit2hW3sCPdK6jT2iWH >>>>> 7ehVRE2I9DZ+hJp4rPcOVkkO1jMl1oRQQmwgEh0q1b688nCBpHBgvgW1m54ERL5h >>>>> I6zppSSMEYCUWqKiuUnSwdzRp+0xESyeGabu4VXhwOrPDYTkF7eifKXeVSUG7szA >>>>> h1xA2syVP1XgNce4hL60Xc16gwFy7ofmXx2utYXGJt/mwZrpHgJHnyqobalbz+xF >>>>> d3+YJ5oyXSrjhO7FmGYvliAd3djDJ9ew+f7Zfc3Qn48LFFhRny+Lwzgt3uiP1o2H >>>>> pPVWQxaZLPSkVrQ0uGE3ycJYgBugl6H8WY3pEfbRD0tVNEYqi4Y7 >>>>> -----END CERTIFICATE----- >>>>>=20 >>>>> The version currently in place has the following content for the first = certificate:- >>>>>=20 >>>>> Certificate: >>>>> Data: >>>>> Version: 3 (0x2) >>>>> Serial Number: 6828503384748696800 (0x5ec3b7a6437fa4e0) >>>>> Signature Algorithm: sha1WithRSAEncryption >>>>> Issuer: CN =3D ACCVRAIZ1, OU =3D PKIACCV, O =3D ACCV, C =3D ES >>>>> Validity >>>>> Not Before: May 5 09:37:37 2011 GMT >>>>> Not After : Dec 31 09:37:37 2030 GMT >>>>> Subject: CN =3D ACCVRAIZ1, OU =3D PKIACCV, O =3D ACCV, C =3D ES >>>>> Subject Public Key Info: >>>>> Public Key Algorithm: rsaEncryption >>>>> RSA Public-Key: (4096 bit) >>>>> Modulus: >>>>> 00:9b:a9:ab:bf:61:4a:97:af:2f:97:66:9a:74:5f: >>>>> d0:d9:96:fd:cf:e2:e4:66:ef:1f:1f:47:33:c2:44: >>>>> a3:df:9a:de:1f:b5:54:dd:15:7c:69:35:11:6f:bb: >>>>> c8:0c:8e:6a:18:1e:d8:8f:d9:16:bc:10:48:36:5c: >>>>> f0:63:b3:90:5a:5c:24:37:d7:a3:d6:cb:09:71:b9: >>>>> f1:01:72:84:b0:7d:db:4d:80:cd:fc:d3:6f:c9:f8: >>>>> da:b6:0e:82:d2:45:85:a8:1b:68:a8:3d:e8:f4:44: >>>>> 6c:bd:a1:c2:cb:03:be:8c:3e:13:00:84:df:4a:48: >>>>> c0:e3:22:0a:e8:e9:37:a7:18:4c:b1:09:0d:23:56: >>>>> 7f:04:4d:d9:17:84:18:a5:c8:da:40:94:73:eb:ce: >>>>> 0e:57:3c:03:81:3a:9d:0a:a1:57:43:69:ac:57:6d: >>>>> 79:90:78:e5:b5:b4:3b:d8:bc:4c:8d:28:a1:a7:a3: >>>>> a7:ba:02:4e:25:d1:2a:ae:ed:ae:03:22:b8:6b:20: >>>>> 0f:30:28:54:95:7f:e0:ee:ce:0a:66:9d:d1:40:2d: >>>>> 6e:22:af:9d:1a:c1:05:19:d2:6f:c0:f2:9f:f8:7b: >>>>> b3:02:42:fb:50:a9:1d:2d:93:0f:23:ab:c6:c1:0f: >>>>> 92:ff:d0:a2:15:f5:53:09:71:1c:ff:45:13:84:e6: >>>>> 26:5e:f8:e0:88:1c:0a:fc:16:b6:a8:73:06:b8:f0: >>>>> 63:84:02:a0:c6:5a:ec:e7:74:df:70:ae:a3:83:25: >>>>> ea:d6:c7:97:87:93:a7:c6:8a:8a:33:97:60:37:10: >>>>> 3e:97:3e:6e:29:15:d6:a1:0f:d1:88:2c:12:9f:6f: >>>>> aa:a4:c6:42:eb:41:a2:e3:95:43:d3:01:85:6d:8e: >>>>> bb:3b:f3:23:36:c7:fe:3b:e0:a1:25:07:48:ab:c9: >>>>> 89:74:ff:08:8f:80:bf:c0:96:65:f3:ee:ec:4b:68: >>>>> bd:9d:88:c3:31:b3:40:f1:e8:cf:f6:38:bb:9c:e4: >>>>> d1:7f:d4:e5:58:9b:7c:fa:d4:f3:0e:9b:75:91:e4: >>>>> ba:52:2e:19:7e:d1:f5:cd:5a:19:fc:ba:06:f6:fb: >>>>> 52:a8:4b:99:04:dd:f8:f9:b4:8b:50:a3:4e:62:89: >>>>> f0:87:24:fa:83:42:c1:87:fa:d5:2d:29:2a:5a:71: >>>>> 7a:64:6a:d7:27:60:63:0d:db:ce:49:f5:8d:1f:90: >>>>> 89:32:17:f8:73:43:b8:d2:5a:93:86:61:d6:e1:75: >>>>> 0a:ea:79:66:76:88:4f:71:eb:04:25:d6:0a:5a:7a: >>>>> 93:e5:b9:4b:17:40:0f:b1:b6:b9:f5:de:4f:dc:e0: >>>>> b3:ac:3b:11:70:60:84:4a:43:6e:99:20:c0:29:71: >>>>> 0a:c0:65 >>>>> Exponent: 65537 (0x10001) >>>>> X509v3 extensions: >>>>> Authority Information Access: >>>>> CA Issuers - URI:http://www.accv.es/fileadmin/Archivos/= certificados/raizaccv1.crt >>>>> OCSP - URI:http://ocsp.accv.es >>>>>=20 >>>>> X509v3 Subject Key Identifier: >>>>> D2:87:B4:E3:DF:37:27:93:55:F6:56:EA:81:E5:36:CC:8C:1E:3F:BD >>>>> X509v3 Basic Constraints: critical >>>>> CA:TRUE >>>>> X509v3 Authority Key Identifier: >>>>> keyid:D2:87:B4:E3:DF:37:27:93:55:F6:56:EA:81:E5:36:CC:8C:1E:3F:BD >>>>>=20 >>>>> X509v3 Certificate Policies: >>>>> Policy: X509v3 Any Policy >>>>> User Notice: >>>>> Explicit Text: >>>>> CPS: http://www.accv.es/legislacion_c.htm >>>>>=20 >>>>> X509v3 CRL Distribution Points: >>>>>=20 >>>>> Full Name: >>>>> URI:http://www.accv.es/fileadmin/Archivos/certificados/raizaccv1_der.crl >>>>>=20 >>>>> X509v3 Key Usage: critical >>>>> Certificate Sign, CRL Sign >>>>> X509v3 Subject Alternative Name: >>>>> email:accv(a)accv.es >>>>> Signature Algorithm: sha1WithRSAEncryption >>>>> 97:31:02:9f:e7:fd:43:67:48:44:14:e4:29:87:ed:4c:28:66: >>>>> d0:8f:35:da:4d:61:b7:4a:97:4d:b5:db:90:e0:05:2e:0e:c6: >>>>> 79:d0:f2:97:69:0f:bd:04:47:d9:be:db:b5:29:da:9b:d9:ae: >>>>> a9:99:d5:d3:3c:30:93:f5:8d:a1:a8:fc:06:8d:44:f4:ca:16: >>>>> 95:7c:33:dc:62:8b:a8:37:f8:27:d8:09:2d:1b:ef:c8:14:27: >>>>> 20:a9:64:44:ff:2e:d6:75:aa:6c:4d:60:40:19:49:43:54:63: >>>>> da:e2:cc:ba:66:e5:4f:44:7a:5b:d9:6a:81:2b:40:d5:7f:f9: >>>>> 01:27:58:2c:c8:ed:48:91:7c:3f:a6:00:cf:c4:29:73:11:36: >>>>> de:86:19:3e:9d:ee:19:8a:1b:d5:b0:ed:8e:3d:9c:2a:c0:0d: >>>>> d8:3d:66:e3:3c:0d:bd:d5:94:5c:e2:e2:a7:35:1b:04:00:f6: >>>>> 3f:5a:8d:ea:43:bd:5f:89:1d:a9:c1:b0:cc:99:e2:4d:00:0a: >>>>> da:c9:27:5b:e7:13:90:5c:e4:f5:33:a2:55:6d:dc:e0:09:4d: >>>>> 2f:b1:26:5b:27:75:00:09:c4:62:77:29:08:5f:9e:59:ac:b6: >>>>> 7e:ad:9f:54:30:22:03:c1:1e:71:64:fe:f9:38:0a:96:18:dd: >>>>> 02:14:ac:23:cb:06:1c:1e:a4:7d:8d:0d:de:27:41:e8:ad:da: >>>>> 15:b7:b0:23:dd:2b:a8:d3:da:25:87:ed:e8:55:44:4d:88:f4: >>>>> 36:7e:84:9a:78:ac:f7:0e:56:49:0e:d6:33:25:d6:84:50:42: >>>>> 6c:20:12:1d:2a:d5:be:bc:f2:70:81:a4:70:60:be:05:b5:9b: >>>>> 9e:04:44:be:61:23:ac:e9:a5:24:8c:11:80:94:5a:a2:a2:b9: >>>>> 49:d2:c1:dc:d1:a7:ed:31:11:2c:9e:19:a6:ee:e1:55:e1:c0: >>>>> ea:cf:0d:84:e4:17:b7:a2:7c:a5:de:55:25:06:ee:cc:c0:87: >>>>> 5c:40:da:cc:95:3f:55:e0:35:c7:b8:84:be:b4:5d:cd:7a:83: >>>>> 01:72:ee:87:e6:5f:1d:ae:b5:85:c6:26:df:e6:c1:9a:e9:1e: >>>>> 02:47:9f:2a:a8:6d:a9:5b:cf:ec:45:77:7f:98:27:9a:32:5d: >>>>> 2a:e3:84:ee:c5:98:66:2f:96:20:1d:dd:d8:c3:27:d7:b0:f9: >>>>> fe:d9:7d:cd:d0:9f:8f:0b:14:58:51:9f:2f:8b:c3:38:2d:de: >>>>> e8:8f:d6:8d:87:a4:f5:56:43:16:99:2c:f4:a4:56:b4:34:b8: >>>>> 61:37:c9:c2:58:80:1b:a0:97:a1:fc:59:8d:e9:11:f6:d1:0f: >>>>> 4b:55:34:46:2a:8b:86:3b >>>>> -----BEGIN CERTIFICATE----- >>>>> MIIH0zCCBbugAwIBAgIIXsO3pkN/pOAwDQYJKoZIhvcNAQEFBQAwQjESMBAGA1UE >>>>> AwwJQUNDVlJBSVoxMRAwDgYDVQQLDAdQS0lBQ0NWMQ0wCwYDVQQKDARBQ0NWMQsw >>>>> CQYDVQQGEwJFUzAeFw0xMTA1MDUwOTM3MzdaFw0zMDEyMzEwOTM3MzdaMEIxEjAQ >>>>> BgNVBAMMCUFDQ1ZSQUlaMTEQMA4GA1UECwwHUEtJQUNDVjENMAsGA1UECgwEQUND >>>>> VjELMAkGA1UEBhMCRVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCb >>>>> qau/YUqXry+XZpp0X9DZlv3P4uRm7x8fRzPCRKPfmt4ftVTdFXxpNRFvu8gMjmoY >>>>> HtiP2Ra8EEg2XPBjs5BaXCQ316PWywlxufEBcoSwfdtNgM3802/J+Nq2DoLSRYWo >>>>> G2ioPej0RGy9ocLLA76MPhMAhN9KSMDjIgro6TenGEyxCQ0jVn8ETdkXhBilyNpA >>>>> lHPrzg5XPAOBOp0KoVdDaaxXbXmQeOW1tDvYvEyNKKGno6e6Ak4l0Squ7a4DIrhr >>>>> IA8wKFSVf+DuzgpmndFALW4ir50awQUZ0m/A8p/4e7MCQvtQqR0tkw8jq8bBD5L/ >>>>> 0KIV9VMJcRz/RROE5iZe+OCIHAr8Fraocwa48GOEAqDGWuzndN9wrqODJerWx5eH >>>>> k6fGioozl2A3ED6XPm4pFdahD9GILBKfb6qkxkLrQaLjlUPTAYVtjrs78yM2x/47 >>>>> 4KElB0iryYl0/wiPgL/AlmXz7uxLaL2diMMxs0Dx6M/2OLuc5NF/1OVYm3z61PMO >>>>> m3WR5LpSLhl+0fXNWhn8ugb2+1KoS5kE3fj5tItQo05iifCHJPqDQsGH+tUtKSpa >>>>> cXpkatcnYGMN285J9Y0fkIkyF/hzQ7jSWpOGYdbhdQrqeWZ2iE9x6wQl1gpaepPl >>>>> uUsXQA+xtrn13k/c4LOsOxFwYIRKQ26ZIMApcQrAZQIDAQABo4ICyzCCAscwfQYI >>>>> KwYBBQUHAQEEcTBvMEwGCCsGAQUFBzAChkBodHRwOi8vd3d3LmFjY3YuZXMvZmls >>>>> ZWFkbWluL0FyY2hpdm9zL2NlcnRpZmljYWRvcy9yYWl6YWNjdjEuY3J0MB8GCCsG >>>>> AQUFBzABhhNodHRwOi8vb2NzcC5hY2N2LmVzMB0GA1UdDgQWBBTSh7Tj3zcnk1X2 >>>>> VuqB5TbMjB4/vTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNKHtOPfNyeT >>>>> VfZW6oHlNsyMHj+9MIIBcwYDVR0gBIIBajCCAWYwggFiBgRVHSAAMIIBWDCCASIG >>>>> CCsGAQUFBwICMIIBFB6CARAAQQB1AHQAbwByAGkAZABhAGQAIABkAGUAIABDAGUA >>>>> cgB0AGkAZgBpAGMAYQBjAGkA8wBuACAAUgBhAO0AegAgAGQAZQAgAGwAYQAgAEEA >>>>> QwBDAFYAIAAoAEEAZwBlAG4AYwBpAGEAIABkAGUAIABUAGUAYwBuAG8AbABvAGcA >>>>> 7QBhACAAeQAgAEMAZQByAHQAaQBmAGkAYwBhAGMAaQDzAG4AIABFAGwAZQBjAHQA >>>>> cgDzAG4AaQBjAGEALAAgAEMASQBGACAAUQA0ADYAMAAxADEANQA2AEUAKQAuACAA >>>>> QwBQAFMAIABlAG4AIABoAHQAdABwADoALwAvAHcAdwB3AC4AYQBjAGMAdgAuAGUA >>>>> czAwBggrBgEFBQcCARYkaHR0cDovL3d3dy5hY2N2LmVzL2xlZ2lzbGFjaW9uX2Mu >>>>> aHRtMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly93d3cuYWNjdi5lcy9maWxlYWRt >>>>> aW4vQXJjaGl2b3MvY2VydGlmaWNhZG9zL3JhaXphY2N2MV9kZXIuY3JsMA4GA1Ud >>>>> DwEB/wQEAwIBBjAXBgNVHREEEDAOgQxhY2N2QGFjY3YuZXMwDQYJKoZIhvcNAQEF >>>>> BQADggIBAJcxAp/n/UNnSEQU5CmH7UwoZtCPNdpNYbdKl02125DgBS4OxnnQ8pdp >>>>> D70ER9m+27Up2pvZrqmZ1dM8MJP1jaGo/AaNRPTKFpV8M9xii6g3+CfYCS0b78gU >>>>> JyCpZET/LtZ1qmxNYEAZSUNUY9rizLpm5U9EelvZaoErQNV/+QEnWCzI7UiRfD+m >>>>> AM/EKXMRNt6GGT6d7hmKG9Ww7Y49nCrADdg9ZuM8Db3VlFzi4qc1GwQA9j9ajepD >>>>> vV+JHanBsMyZ4k0ACtrJJ1vnE5Bc5PUzolVt3OAJTS+xJlsndQAJxGJ3KQhfnlms >>>>> tn6tn1QwIgPBHnFk/vk4CpYY3QIUrCPLBhwepH2NDd4nQeit2hW3sCPdK6jT2iWH >>>>> 7ehVRE2I9DZ+hJp4rPcOVkkO1jMl1oRQQmwgEh0q1b688nCBpHBgvgW1m54ERL5h >>>>> I6zppSSMEYCUWqKiuUnSwdzRp+0xESyeGabu4VXhwOrPDYTkF7eifKXeVSUG7szA >>>>> h1xA2syVP1XgNce4hL60Xc16gwFy7ofmXx2utYXGJt/mwZrpHgJHnyqobalbz+xF >>>>> d3+YJ5oyXSrjhO7FmGYvliAd3djDJ9ew+f7Zfc3Qn48LFFhRny+Lwzgt3uiP1o2H >>>>> pPVWQxaZLPSkVrQ0uGE3ycJYgBugl6H8WY3pEfbRD0tVNEYqi4Y7 >>>>> -----END CERTIFICATE----- >>>>>=20 >>>>> The bit between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE---= -- is the same in both cases, it is all the other information that is missing. >>>>>>=20 >>>>>>> This is also the case for the bundles that Arch Linux has created on = my systems, that also uses the p11-kit approach. >>>>>>>=20 >>>>>>> I did a diff on the current ca-bundle.crt/ca-bundle.trust.crt files a= nd the ones created by the new approach as used by Fedora and all the same ce= rtificates are present, it is only the certificate data that is missed. >>>>>>>=20 >>>>>>> There is a --comment option in the trust extract command that looks l= ike it should add the comments that are in the .p11-kit file into the extract= ed bundle files but nothing changes if it is used or not. I will ask into the= p11-kit git repository whether this should work or not. >>>>>>>=20 >>>>>>>=20 >>>>>>> I did a build just with the new ca-certificate files into Core Update= 160 and then installed the created iso into a vm on my testbed system. >>>>>>>=20 >>>>>>> Everything worked that I tested out but I am not 100% sure what needs= to be exercised to test the ca-bundle.crt and ca-bundle.trust.crt files. If = someone can give me some guidance on this then I can do that final test and s= ubmit a patch for this change. >>>>>>=20 >>>>>> If you can download something with wget using HTTPS and the certificat= e can be validated, things should be working fine. >>>>> I will give that a try. >>>>>>=20 >>>> I successfully downloaded clamav with wgat from an https url. I got the = following messages which I think indicate it worked but there is also mention= of http as well as https. Can you confirm if what I did was a good test resu= lt? >>>>=20 >>>>=20 >>>> wget https://www.clamav.net/downloads/production/clamav-0.103.3.tar.gz >>>> --2021-08-19 22:53:03-- https://www.clamav.net/downloads/production/clam= av-0.103.3.tar.gz >>>> Resolving www.clamav.net... 104.16.218.84, 104.16.219.84 >>>> Connecting to www.clamav.net|104.16.218.84|:443... connected. >>>> HTTP request sent, awaiting response... 302 Found >>>> Location: https://clamav-site.s3.amazonaws.com/production/release_files/= files/000/000/612/original/clamav-0.103.3.tar.gz?X-Amz-Algorithm=3DAWS4-HMAC-= SHA256&X-Amz-Credential=3DAKIAIY6OSGQFGUNJQ7GQ%2F20210819%2Fus-east-1%2Fs3%2F= aws4_request&X-Amz-Date=3D20210819T205304Z&X-Amz-Expires=3D3600&X-Amz-SignedH= eaders=3Dhost&X-Amz-Signature=3D22909d2fe084a9cfcc50b41c0e59ed049089d26c42745= 801415c9cf697635051 [following] >>>> --2021-08-19 22:53:04-- https://clamav-site.s3.amazonaws.com/production/= release_files/files/000/000/612/original/clamav-0.103.3.tar.gz?X-Amz-Algorith= m=3DAWS4-HMAC-SHA256&X-Amz-Credential=3DAKIAIY6OSGQFGUNJQ7GQ%2F20210819%2Fus-= east-1%2Fs3%2Faws4_request&X-Amz-Date=3D20210819T205304Z&X-Amz-Expires=3D3600= &X-Amz-SignedHeaders=3Dhost&X-Amz-Signature=3D22909d2fe084a9cfcc50b41c0e59ed0= 49089d26c42745801415c9cf697635051 >>>> Resolving clamav-site.s3.amazonaws.com... 52.216.224.232 >>>> Connecting to clamav-site.s3.amazonaws.com|52.216.224.232|:443... connec= ted. >>>> HTTP request sent, awaiting response... 200 OK >>>> Length: 13389239 (13M) [binary/octet-stream] >>>> Saving to: 'clamav-0.103.3.tar.gz' >>>>=20 >>>> clamav-0.103.3.tar.gz 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>] 12.77M 11.6MB/s in 1.1s >>>>=20 >>>> 2021-08-19 22:53:05 (11.6 MB/s) - 'clamav-0.103.3.tar.gz' saved [1338923= 9/13389239] >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>=20 >>>>>>> I also then did a test build with all python2 programs removed, inclu= ding python2 itself and with the python 3 fixes for spice, frr and ca-certifi= cates installed. The build for every program in the ipfire build section comp= leted successfully but then I had a stop in the cdrom stage for collectd. It = has a python2 plugin module defined which was of course missing. The module c= ould be disabled in the rootfile or in the build config if the python plugin = is not required for IPFire - I could not find any python modules defined. >>>>>>=20 >>>>>> You can just pass =E2=80=9C=E2=80=94-without-python=E2=80=9D or =E2=80= =9C=E2=80=94-disable-python=E2=80=9D and then the module won=E2=80=99t be bui= lt any more. >>>>>>=20 >>>>>>> I have been able to successfully define the path to the python interp= reter in the ./configure statement to point to the python3 program and collec= td successfully built with this so if the python plugin is required then a py= thon3 version can be created. I have not yet tested this in my vm but will do= so. >>>>>>=20 >>>>>> We do not use this module, so I suppose it isn=E2=80=99t worth buildin= g it in the first place. >>>>>>=20 >>>>>>> I also found that freeradius has a python2 module defined. This can b= e disabled. >>>>> I will do that for collectd and freeradius then. >>>>>=20 >>>>> I will also do it for alsa as that is the next one I found with a pytho= n2 library entry. >>>>>>=20 >>>>>> Please do that. If someone needs the Python 3 module, we can still bui= ld it> >>>>>>> There is a python3 module available since 2.0.20. To use it with 3.0.= 21 (current version) you have to have --with-experimental-modules defined. I = am looking at latest version 2.0.23 to see if that also needs the experimenta= l modules enabled or if it has become part of the normal modules now and will= test the build to see if it works successfully or not. >>>>>>=20 >>>>>> Thank you for all the research that you invested into this. Looks like= we are not far away to drop Python 2. >>>>> I also think we are very close now. Hopefully in time for Core Update 1= 60. >>>>>=20 >>>>> Regards, >>>>> Adolf. >>>>>>=20 >>>>>> -Michael >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Adolf. >>>>>>>=20 >>>>>>> On 12/08/2021 21:30, Adolf Belka wrote: >>>>>>>> Hi Michael, >>>>>>>>=20 >>>>>>>> On 12/08/2021 21:23, Adolf Belka wrote: >>>>>>>>> Hi Michael, >>>>>>>>>=20 >>>>>>>>> On 12/08/2021 15:38, Michael Tremer wrote: >>>>>>>>>> Hello, >>>>>>>>>>=20 >>>>>>>>>> Yes, this is the way to go :) >>>>>>>>>>=20 >>>>>>>>>> Reach out here if you need any help. >>>>>>>>> I am trying to build p11-kit and it has flagged up libtasn1. It is = an optional dependency and I can disable it but I would like to check if that= is the correct thing to do or not. >>>>>>>>>=20 >>>>>>>>> libtasn1 is said to be required to allow the trust policy module to= be built as well as other code that interacts with certificates. >>>>>>>>> Is this something that would be needed for IPFire or can I disable = it in the p11-kit build. >>>>>>>>>=20 >>>>>>>> Ignore this question. I just did a quick test of disabling libtasn1 = and p11-kit built ok but then my ca-certificates build failed due to the lack= of the trust tool, so that makes it clear that it is required. I will add it= in to the build. >>>>>>>>=20 >>>>>>>> Slowly getting there. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Adolf. >>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Adolf. >>>>>>>>>>=20 >>>>>>>>>> -Michael >>>>>>>>>>=20 >>>>>>>>>>> On 12 Aug 2021, at 13:10, Adolf Belka = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Michael, >>>>>>>>>>>=20 >>>>>>>>>>> On 12/08/2021 13:36, Adolf Belka wrote: >>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>=20 >>>>>>>>>>>> On 12/08/2021 11:17, Michael Tremer wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 11 Aug 2021, at 15:03, Adolf Belka wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 11/08/2021 12:43, Michael Tremer wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> Is this the one with the broken sed command? >>>>>>>>>>>>>>> https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhi= de/f/certdata2pem.py >>>>>>>>>>>>>> Yes, this is that one. Confirmed with a diff. >>>>>>>>>>>>>>> This should run if you execute it in the right directory: >>>>>>>>>>>>>>> pushd %{name}/certs >>>>>>>>>>>>>>> pwd >>>>>>>>>>>>>>> cp certdata.txt . >>>>>>>>>>>>>>> python3 certdata2pem.py >>>>>>>>>>>>>>> popd >>>>>>>>>>>>>> I have just learnt about the pushd and popd commands. by doing= a quick search. Never heard of them before. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It is just a version of =E2=80=9Ccd=E2=80=9D that remembers whe= re it has been. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So if you call =E2=80=9Cpushd some-directory=E2=80=9D, then =E2= =80=9Cpopd=E2=80=9D will bring you back to where you have been before. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =E2=80=9Ccd -=E2=80=9C does the same as popd now. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The fedora version no longer has the build.sh script. >>>>>>>>>>>>>> That was the bit I didn't realise. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> No problem. >>>>>>>>>>>>=20 >>>>>>>>>>>> Not as simple as I hoped. >>>>>>>>>>>>=20 >>>>>>>>>>>> The new certdata2pem.py script no longer creates .crt files but = .tmp-p11-kit files but that is as far as that script goes. >>>>>>>>>>>>=20 >>>>>>>>>>>> There is an update-ca-trust file in fedora which splits the vari= ous certs to their respective locations, with the openssl ones ending up in c= a-bundle.trust.crt but this uses p11-kit. I suspect that it uses ca-bundle.tr= ust.p11-kit generated later on in the %build section of the ca-certificate.sp= ec file from the tmp-p11-kit files generated by the certdata2pem.py script. S= o it looks like p11-kit needs to be installed to make this work. >>>>>>>>>>>>=20 >>>>>>>>>>>> Alternatively I have found the following in LFS. >>>>>>>>>>>> https://www.linuxfromscratch.org/blfs/view/svn/postlfs/make-ca.h= tml >>>>>>>>>>>> which seems to also create the bundled cert file but also requir= ing p11-kit but then talking about different certdata.txt versions that have = various tunings. The one from LFS comes from the mozilla release branch but i= s modified to something called the Mercurial revision, or the different ones = shipped by RedHat or OpenSUSE which use the version that comes with NSS. >>>>>>>>>>>>=20 >>>>>>>>>>>> All in all I am not sure which approach to use or how to actuall= y build it in IPFire. >>>>>>>>>>>>=20 >>>>>>>>>>>> Definitely help required to know the correct way to go further w= ith this. >>>>>>>>>>>>=20 >>>>>>>>>>> Having said I needed help, I thought I would have another go and = copied the lines from the %build section of the fedora ca-certificate.spec th= at created the ca-bundle.trust.p11.kit >>>>>>>>>>>=20 >>>>>>>>>>> As I have p11-kit installed on my Arch Linux system I then ran th= e command >>>>>>>>>>>=20 >>>>>>>>>>> p11-kit extract --format=3Dopenssl-bundle --filter=3Dcertificates= --overwrite --comment ~/openssl/ca-bundle.trust.crt >>>>>>>>>>>=20 >>>>>>>>>>> and I successfully created the ca-bundle.trust.crt which is neede= d by the IPFire ca-certificates lfs file. >>>>>>>>>>>=20 >>>>>>>>>>> I will now try and create a new build script that will do all the= new type stuff and also install the p11-kit library files and see how things= go. >>>>>>>>>>>=20 >>>>>>>>>>> :crossed_fingers: >>>>>>>>>>>=20 >>>>>>>>>>> Adolf >>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Adolf. >>>>>>>>>>>>=20 >>>>>>>>>>>>> -Michael >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>> On 8 Aug 2021, at 14:47, Adolf Belka wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I had another go at the ca-certificates problem, the last ba= rrier to getting rid of python2. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I found certdata2pem.py files from fedora and 2 from suse. I= created build subdirectories for each version so I could just test running t= he build.sh file with each version of certdata2pem.py, including the IPFire c= urrent version after running through the 2to3 convertor. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> fedora >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The fedora certdata2pem.py file runs successfully with pytho= n3 but has sed commands built into it which fail to find certain files. The s= ed commands are not in the IPFire version. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The error message is >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -> written as 'Certum_Trusted_Root_CA:2.16.30.191.89.80.= 184.201.128.55.76.6.247.235.85.79.181.237.tmp-p11-kit', trust =3D ['CKA_TRUST= _SERVER_AUTH', 'CKA_TRUST_EMAIL_PROTECTION'], openssl-trust =3D ['serverAuth'= , 'emailProtection'], distrust =3D [], openssl-distrust =3D [] >>>>>>>>>>>>>>>> sed: can't read certs/*.crt: No such file or directory >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> suse >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The first suse version runs successfully with python3 but al= so has the sed commands in it with the same error message. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The second suse version runs successfully with python3, does= not have the sed commands and completes the build.sh script with no errors. = However this certdata2pem.py file has a section that is in the IPFire version= completely missing. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> IPfire version after running through the 2to3 convertor >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The following error message occurs >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> producing trust for "GlobalSign Root CA"2.11.4.0.0.0.0.1.21.= 75.90.195.148 >>>>>>>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>>>>>>> File "/mnt/File_Server/Computers/Linux/ipfire/sandbox/p= atch in progress/python/ca-certificates/orig-2to3-build/certs/../certdata2pem= .py", line 224, in >>>>>>>>>>>>>>>> f.write("\n".join(textwrap.wrap(base64.b64encode(obj['CKA_VA= LUE']), 64))) >>>>>>>>>>>>>>>> File "/usr/lib/python3.9/base64.py", line 58, in b64enc= ode >>>>>>>>>>>>>>>> encoded =3D binascii.b2a_base64(s, newline=3DFalse) >>>>>>>>>>>>>>>> TypeError: a bytes-like object is required, not 'str' >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The section that is failing is the section that is missing i= n the 2nd suse version. There is an identical fwrite line at line 206 but tha= t does not seem to flag up the same TypeError message. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> As the certdata2pem.py files from the other distributions va= ry significantly in content, with some having nearly double the number of lin= es of code, I think the best alternative is to fix the IPFire version so we s= tay consistent but I am unable to figure out how to fix the python code that = is causing the " TypeError: a bytes-like object is required, not 'str' " err= or message and need someone's help with that. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Let me know if there is any other information that I need to= provide. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 07/08/2021 15:54, Adolf Belka wrote: >>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 04/08/2021 16:45, Michael Tremer wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 4 Aug 2021, at 13:40, Adolf Belka wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I have resolved the frr program build. The version curren= tly in IPFire (6.0) only works with python2. Python3 support came in with ver= sion 7.4. I have now built frr with version 8.0 including libyang as a new de= pendency but only for the build, so nothing installed into IPFire itself, and= that has successfully built without python2 being present. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Great. This could also resolve Matthias=E2=80=99 problem w= ith building frr. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Will now go back and have another go with spice-protocol. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Maybe it has a =E2=80=94-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 pr= esent. I have submitted a patch for this combined with updating spice and spi= ce-protocol, both from 2017. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> This now only leaves the ca-certificates script that needs = to be updated to work with python3. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 03/08/2021 23:38, Adolf Belka wrote: >>>>>>>>>>>>>>>>>>>> Hi Michael & all, >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 03/08/2021 17:11, Michael Tremer wrote: >>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Thank you for looking into this. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> This is a third-party script that came from either Mozi= lla or RedHat. Maybe they have ported it. If not, it should not be rocket sci= ence 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 tr= y. 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 dir= ectory and it came back and said there weren't any. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> 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 mo= dules. >>>>>>>>>>>>>>>>>>>> py-compile is python2 based and the build stopped becaus= e it could not find python >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> There is a py_compile.py script that is python3 based bu= t 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. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I then commented out spice-protocol and ran the build. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I commented out frr and nothing else failed before cdrom= was reached. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> So the packages that need to be made to work with python= 3 are >>>>>>>>>>>>>>>>>>>> ca-certificates >>>>>>>>>>>>>>>>>>>> spice-protocol >>>>>>>>>>>>>>>>>>>> frr >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> 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 a= udio works. I will need to get audio set up in my vm to try that. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On 3 Aug 2021, at 13:31, Adolf Belka wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> ca-certificates was flagged up. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> There is a python2 script, certdata2pem.py, which fail= s if python2 is not present. Running that script with python3 flags up some i= nvalid syntax, unsurprisingly. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I found some patches in Debian from 2015 for certdata2= pem.py to provide python3 compatibility. Unfortunately looking at the patch a= pprox half could not be applied because the lines don't exist in the IPFire v= ersion of certdata2pem.py (sections to do with blacklisted certs) >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I then ran the 2to3 converter on certdata2pem.py and t= ried that in the build but it came up with the following error. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> TypeError: a bytes-like object is required, not 'str' >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I don't know how to further move forward with this as = I am totally unfamiliar with the python language. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Adolf. >>>>>>>>>>=20 >>>>>>=20 >>> --=20 >>> Sent from my laptop >>>=20 --===============4351674235461650402==--