python27-2.7.18_2 fails to compile on 14.0-BETA2 At the end I see in the poudriere log: =======================<phase: package >============================ ===> Building package for python27-2.7.18_2 pkg-static: Unable to access file /wrkdirs/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_hashlib.so:No such file or directory *** Error code 1 Stop. make: stopped in /usr/ports/lang/python27
I cannot reproduce this. I just rechecked again as I was the one who patched this for OpenSSL fixing on 14. https://pkg.bofh.network/data/140-default/2023-09-26_09h20m46s/logs/python27-2.7.18_2.log
And on BETA3. https://pkg.bofh.network/data/140-default/2023-09-26_09h24m32s/logs/python27-2.7.18_2.log Make sure you have most recent updates on the ports tree.
Created attachment 245247 [details] Poudriere log Here's my log file. I hope it gives some hints to what goes wrong.
This is nasty.Closed already before I got a change to add more information. In the future I won't bother and just wait until 14.0 is officially released.
(In reply to Philip Homburg from comment #4) This is not nasty. This is perfect. I have mentioned what might be the problem. And you have to understand the difference between a bug reporting system and a help desk system. This is not a help desk. If you need help with your case send mail to the proper mailing list or join the forums or join the IRC.
Obviously I have the most recent updates of the ports tree. I have the same python27 version as you. And poudriere just does a git checkout. I seems we cannot have a constructive discussion. I leave it as is. Other people with same issue will find this bug report.
Although you are demanding that you have the most recent updates of the tree but I am more than sure that your failure is due to either of the following: 1. You are using portsnap to update the tree which often corrupts the tree in post svn era. 2. You are running quarterly tree which is not supported by ALPHA/BETA/RC releases.
Created attachment 245249 [details] Diff between two 14.0-BETA2 log files Here is a diff between your log and mine. I have no clue about building python27, but the obvious thing that stands out is that my build has: DEFAULT_VERSIONS+=ssl=openssl
(In reply to Philip Homburg from comment #3) You are using openssl from ports (openssl-1.1.1w). The openssl shown in comment 1 (and comment 2) is from base. So these two builds are not the same. In the log in comment 3, there is this: warning: openssl 0x00000000 is too old for _hashlib That is why the _hashlib module is not being built. See if you can track down why the openssl version reported is 0. setup.py has: # find out which version of OpenSSL we have openssl_ver = 0 openssl_ver_re = re.compile( '^\s*#\s*define\s+OPENSSL_VERSION_NUMBER\s+(0x[0-9a-fA-F]+)' ) It's looking in openssl/opensslv.h for OPENSSL_VERSION_NUMBER. Assuming that file (from your /packages/All/openssl-1.1.1w,1.pkg) does not have a bad version definition or is corrupt in some other way, consider that setup.py is not using the opensslv.h from the port and needs to be convinced to do so. This [using the wrong openssl header file(s)] may have always been a [hidden] problem with lang/python27 and the opensslv.h (and perhaps the rest of openssl) in base and ports were usually close enough to work.
At the end of the line: https://cgit.freebsd.org/ports/tree/lang/python27/Makefile#n127 There is openssl3*. Replace it with openssl* and let me know the result. I have never used ssl from the ports and do not know how that works.
Replacing openssl3* with openssl* makes it build. Thanks.
In truth there is no configure knobs for defining openssl path in python27. So even if someone has DEFAULT_VERSIONS+=ssl=openssl* it will always bind with the base version of openssl so be careful when other ports are using python27. I cannot or do not want to fix that unfortunately. But I will just fix this corner case of determining ssl detection. And for non-default cases please always use forums and mailing lists.
For future reference, which forums and mailing lists do you recommend if I use DEFAULT_VERSIONS+=ssl=openssl. Does that apply to all FreeBSD ports or just to the python-related ones?
We have a forum at https://forums.freebsd.org which I have never tried but there are topics. For ports related issues try ports@ and when you are using most bleeding edge like HEAD/BETA/RC/ALPHA use current@. Normally the committers do not ever try or test with non-default options like this except for cases when we change default version of a port like changing default version of python/php/ruby etc. Because it's CPU intensive and normally we ask the pkgmgr@ to run an exp-run. For OpenSSL we have changed the base version to 3 from 14 and onwards and I was the one to check which ports fail with OpenSSL3 and I have fixed all the ports. But it was not needed for me to test whether if it builds with openssl port or not. On another note we will most probably remove openssl port at the end of the year as it has reached EOl. So I would advise to move out of it.
This is yet another fallout with the latest devel/pkgconf, which pushes base .pc files to the top unconditionally. Currently in the process of filing a bug upstream, after which a PR to track it will be filed here.
Created attachment 245256 [details] [patch] convince py27 setup.py to look in the desired openssl include dir The attached patch seems better than hacking the version number. It gets setup.py to look in the desired openssl include directory (as determined by USES=ssl and DEFAULT_VERSIONS).
(In reply to Charlie Li from comment #15) pkg-config/pkgconf is not involved at all for openssl in lang/python27
(In reply to John Hein from comment #17) You're right, I overreacted to trying to keep those reports from spiralling more than they already have. Looking at the log that did not produce hashlib and the trajectory of the security/openssl port, I (with python@ hat) am not inclined to take any action here. This port has long been EOL, and security/openssl will be updated to 3 in the next commit, which would then appear to obviate the security/openssl3* ports.
(In reply to Charlie Li from comment #18) Ok. Your (python team) call, of course. The patch is fairly trivial and worthwhile, so it could help people. I know there are a lot of python2 users still out there (despite the upstream status). I'm not saying that's good or bad, just that "it is". I confess, I still use it for scripts that haven't been ported or have not been gotten much testing under py3 yet. I appreciate that the ports team allowed py27 to still exist (thankfully, it hasn't been a huge burden, I think). That friendly treatment been very useful to end users in my circle. It can be frustrating to get hit with aggressive deprecation action when there are old (and reliable) systems in production. I did test that openssl32 works fine with the python27 port. Specifically I hard coded the proper ssl version in setup.py, built python27 based on that and did some basic hashlib testing successfully - so that's good news. Anyway... hopefully the patch will help some people who can apply it locally.
The code in the Makefile: > .if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400092 && (${SSL_DEFAULT} == base || ${SSL_DEFAULT:Mopenssl3*} ) does not properly deal with the openssl variation. For ssl's DEFAULT VERSION, there are base, openssl111, openssl, openssl31 and openssl32. The above code treats 'openssl' as 'openssl111', but security/openssl is actually openssl3.0. It should be like: > +.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400092 && \ > (${SSL_DEFAULT} == base || ${SSL_DEFAULT} == openssl || \ > ${SSL_DEFAULT:Mopenssl3*} )
Created attachment 248352 [details] properly deal with the SSL_DEFAULT variations.
I discovered this issue today on my first poudriere package build on 14 since I use security/openssl for my ports. Attachment 248352 [details] fixed it for me, thanks.
(In reply to Adam McDougall from comment #22) Noops. Actually this is not correct. If you look deeply on the python27 binary you will still see it being linked with the system openssl rather than ports openssl. The patch you mentioned just makes it build but behind the scene it is linked with system openssl. The actual patch that is correct is actually from comment #16.