python27: problem at packaging stage

Updating lang/python27 to the latest version (2.7.9_1, updated in the ports tree on Monday) yields the following error at the "package" step:

Code:
===>  Building package for python27-2.7.9_1
pkg-static: Unable to access file /usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_ssl.so: No such file or directory
*** Error code 1
The latest commit message mentions a change to SSL support:

Code:
Force a rebuild/upgrade to chase head r280306 which removed SSLv2 support.
This fixes head package users so they have working SSL support. There was
already a built-time fix for this.
Anyone else having this problem and/or have any pointers? Is this something that the port maintainer should be contacted about? This is a fairly important port, so if it's a problem with the port itself (rather than my machine) I imagine many people are encountering it.

Thanks in advance for any advice!
 
Compiles on my machine (10.1-RELEASE) fine. Try cd /usr/ports/lang/python27 and rm -rf * and portsnap extract lang/python27. Or fetch a new portstree.
 
Sorry, overlooked
Code:
USE_OPENSSL=  yes
in the Makefile.

(But I think - not sure - this calls OPENSSL_BASE and not OPENSSL_PORTS )
 
Aha, this is in my /etc/make.conf:

Code:
WITH_OPENSSL_PORT=  yes
OPENSSL_PORT=  security/libressl
Perhaps there is a problem with compiling lang/python27 against security/libressl. When I initially installed python27, it was from packages. I don't have time to test this out now but will report back if I can confirm that switching to security/openssl (and/or WITH_OPENSSL_PORT= no) does the trick.

(Update: nope, still getting the same error with WITH_OPENSSL_PORT= no in /etc/make.conf.)
 
Do you have WITH_OPENSSL_PORT= yes in /etc/make.conf? If not, you might be compiling python27 against the openssl in base.

As for me, I did a portmaster -o security/openssl security/libressl, rebuilt everything against openssl, and boom, it works, python27 packages up without a problem. Tried going back to libressl and the same problem recurred. Back again to openssl, and it works. So, at least on my box, it seems that the latest python27 has a problem compiling against libressl.

Thanks all for your thoughts/input.
 
Hi,

I believe there is some rough edges still being ironed out with regards to building ports against security/libressl. There is some information on this here if you haven't seen it already and specifically a PR 192511 that looks related to the issue in this thread that is open yet.
 
I know this is a really old thread, but I'm having the same problem, and somewhat suddenly. When I try to do a # portmaster -Rafd or a

# cd /usr/ports/devel/py-setuptools
# make FLAVOR=py27 install clean


I get

Code:
running install_egg_info
Writing /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/Python-2.7.14-py2.7.egg-info
rm /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_sysconfigdata.py*
install  -m 0644 ./Misc/python.man  /var/ports/usr/ports/lang/python27/work/stage/usr/local/man/man1/python2.7.1
if test "xno" != "xno"  ; then  case no in  upgrade) ensurepip="--altinstall --upgrade --no-default-pip" ;;  install|*) ensurepip="--altinstall --no-default-pip" ;;  esac;  LD_LIBRARY_PATH=/var/ports/usr/ports/lang/python27/work/Python-2.7.14 ./python -E -m ensurepip  $ensurepip --root=/var/ports/usr/ports/lang/python27/work/stage/ ;
 fi
for i in /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/*.so; do  /usr/bin/strip $i; done
# Strip shared extensions
install  -m 0644 /var/ports/usr/ports/lang/python27/work/Python-2.7.14/Tools/gdb/libpython.py  /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/libpython2.7.so.1-gdb.py
====> Compressing man pages (compress-man)
===>>> Starting check for runtime dependencies
===>>> Gathering dependency list for lang/python27 from ports
===>>> Dependency check complete for lang/python27

===>>> All >> mysql56-client-5.6.39_1 >> devel/cmake >> devel/jsoncpp >> scons-3.0.1 >> devel/py-setuptools@py27 >> lang/python27 (49/64)

===>  Installing for python27-2.7.14_1
===>  Checking if python27 already installed
===>   Registering installation for python27-2.7.14_1 as automatic
pkg-static: Unable to access file /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_elementtree.so:No such file or directory
pkg-static: Unable to access file /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/pyexpat.so:No such file or directory
*** Error code 74

Stop.
make: stopped in /usr/ports/lang/python27

I've tried
# portsclean -CDD
# cd /usr/ports && make clean
# portmaster -ty --clean-distfiles
# portmaster -RafFd


And get the same error. I'm at a bit of a loss as there are only two threads I can find with the same error message and the resolutions provided were a bit mysterious. Also, I had lang/python27 installed with security/libressl on this box already. The only major change was upgrading from lang/php56 to lang/php72 as I'm using the jail for www/nextcloud.
 
I know this is a really old thread, but I'm having the same problem, and somewhat suddenly.
I'm quite convinced that this isn't related because why is your system messing around in /var/ports?

That seems a bit off to me.

(edit) You might want to try to see what happens if you keep /etc/make.conf out of the way for now. I can't help wonder if you're using a heavily customized setup, which could be a trigger for issues.
 
I suppose heavily customized is subject to reasonable interpretation.

# ls /var/ports/usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/

yields

Code:
Python-2.7.14-py2.7.egg-info    _curses_panel.so                _socket.so                      datetime.so                     readline.so
_bisect.so                      _elementtree_failed.so          _ssl.so                         dbm.so                          resource.so
_codecs_cn.so                   _functools.so                   _struct.so                      fcntl.so                        select.so
_codecs_hk.so                   _hashlib.so                     _testcapi.so                    future_builtins.so              strop.so
_codecs_iso2022.so              _heapq.so                       array.so                        grp.so                          syslog.so
_codecs_jp.so                   _hotshot.so                     audioop.so                      itertools.so                    termios.so
_codecs_kr.so                   _io.so                          binascii.so                     math.so                         time.so
_codecs_tw.so                   _json.so                        bsddb185.so                     mmap.so                         unicodedata.so
_collections.so                 _locale.so                      bz2.so                          nis.so                          zlib.so
_csv.so                         _lsprof.so                      cPickle.so                      operator.so
_ctypes.so                      _multibytecodec.so              cStringIO.so                    ossaudiodev.so
_ctypes_test.so                 _multiprocessing.so             cmath.so                        parser.so
_curses.so                      _random.so                      crypt.so                        pyexpat_failed.so

The two "missing" files are marked "_failed" which certainly explains why the installer can't find them. The rest seems fine.
 
from the PR:
pkg-static: Unable to access file /usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_elementtree.so:No such file or directory
pkg-static: Unable to access file /usr/ports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/pyexpat.so:No such file or directory

Comment15 in the PR, includes a patch (I have not tested yet, but another user confirmed it works).
 
Talsamon,
Patch applied, build complete. Thank you very much.

I was in error to attach the problem to this thread, it is unrelated to _ssl.so.

Thank you for finding the PR. I'll report build success there as well.
 
I also had failed packaging stage with an error of missing _ssl.so.
I'm using security/libressl-devel for compiling ports.
Configuration of lang/python27 is a default (not changed anything with make config).

During the building progress, there are some compile errors in Modules/_ssl.c.

The patch (fix for libressl 2.7.1)
https://github.com/python/cpython/commit/edd541897b9c28ee0d0f0131746aa5f19665a104
resolved compiling errors even for libressl-2.7.2, and I could install python27 successfully.
 
I just had massive problems with security/libressl 2.7.2 (and same with 2.7.2_1), does not seem to be building libssl.so.44 and libcrypto.so.42. This breaks everything SSL.
Yes, it's a major update to LibreSSL that is not ABI compatible with the old version. You must rebuild everything that links with LibreSSL. There is no way around this. Synth or Poudriere do this automatically. Also see the /usr/ports/UPDATING entry for this:
Code:
20180428:
  AFFECTS: users of security/libressl
  AUTHOR: brnrd@FreeBSD.org

  The port has been updated to the latest stable version 2.7 of LibreSSL.
  The shared library versions of the libraries have been bumped.

  After upgrading, manually update all packages that depend on any of the
  libraries provided by LibreSSL (libssl, libcrypto and libtls) since the
  versions of these libraries have changed. Normally, you can obtain the
  list of dependent software by running the following command:

  # pkg info -r libressl

  Then you should rebuild all ports depending on libressl to avoid dangling
  shared library dependencies. Poudriere and pkg handle this correctly,
  portmaster and portupgrade users can use the following to rebuild all
  dependent ports.

  Portmaster users:
      portmaster -r libressl
  Portupgrade users:
      portupgrade -fr security/libressl
 
Yah, and, just for anyone who comes across this:

It is not optional to portmaster -r libressl, indeed it must be the first thing done after updating ports tree. If it isn't absolutely the first thing done, life gets very unhappy. You cannot undo the damage by running portmaster -r libressl or even rebuildng all ports later.

Ports known to have issues (and the solutions where available) are at this link. I would advise on not updating security/libressl to 2.7.2/2.7.2_1 if ports listed as having issues are installed. Bernard is doing a great job of guiding the patch process, but there are still a lot of important ports (to me, anyway) that aren't patched in ports and at least one (databases/mysql56-server) that's quite alpha.
 
It is not optional to portmaster -r libressl, indeed it must be the first thing done after updating ports tree. If it isn't absolutely the first thing done, life gets very unhappy. You cannot undo the damage by running portmaster -r libressl or even rebuildng all ports later.
No offense but I seriously doubt that.

In the end this is still a mere library which other ports use to build against. And those other ports don't include the actual building tools themselves. So it really doesn't matter when you're performing the rebuild. I can definitely agree that it's a better idea to start with such a commonly used libraries first, no arguments there, but the 'damage' can always be undone.

Might take a while longer, but it's not impossible. Heck, when all else fails you can always uninstall and re-install all ports. That won't affect your configuration and it would definitely fix things as well.
 
I am having an issue with security/py-certbot (FLAVOR=py36)
It depends on security/py-cryptography which fails to build against LibreSSL 2.7.2_1
Code:
root@test:/usr/ports/security/py-certbot # make FLAVOR=py36 install
...
48 warnings and 7 errors generated.
error: command 'cc' failed with exit status 1
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/security/py-cryptography
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/py-acme
*** Error code 1

Stop.
make: stopped in /usr/ports/security/py-certbot
 
Try it, let me know if you find an easy way out. I'm corresponding with Bernard, you can ask him too. Maybe you can ask better questions than I have.

I've rebuilt all ports, as I pretty much do by default, twice now, after working through fails one by one. now I'm manually applying patches. So far the least critical, PR PR226903 for dns/bind-tools, has been successful so I'm optimistic I can get things running. I'm a bit flumoxxed by www/apache24 not starting, the port builds fine on all jails as one would expect given the patch was integrated in 2.4.33 quite some time ago. I still get:

# apachectl restart
Performing sanity check on apache24 configuration:
httpd: Syntax error on line 130 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_ssl.so into server: /usr/local/libexec/apache24/mod_ssl.so: Undefined symbol "OPENSSL_malloc_init"

All ports are up to date on this jail, everything security/py27-cryptography-2.1.4 builds successfully (working on that patch). Once I have everything else and the somewhat alpha PR PR227178 integrated into databases/mysql56-server (on another jail, but definitely part of the Apache melange), I'll see what happens and if I can find any leads in https://github.com/apache/httpd/blob/2.4.33/modules/ssl/mod_ssl.c#L401

Certainly I'll check https://wiki.freebsd.org/LibreSSL/2.7 and make sure all the patches I need are actually in ports before I risk upgrading again.
 
I am having an issue with security/py-certbot (FLAVOR=py36)
It depends on security/py-cryptography which fails to build against LibreSSL 2.7.2_1

I'd be interested in your environment details and if you followed the advice in /usr/ports/UPDATING and did a portmaster -r libressl before anything else, or if, like me, you followed a different protocol and ended up in trouble.

I haven't successfully patched security/py-cryptography and am not on 36 so haven't tried security/py-cryptography@py36, but this PR PR226906 applies and there is further information at https://wiki.freebsd.org/LibreSSL/2.7
 
I tried both:
1. On an existing installation where I have LibreSSL 2.6.4, ran portmaster -r libressl - no luck with security/py-certbot.
2. On a fresh installation, same thing, no luck with it, all other ports that I use build successfully - nginx, dovecot, opensmtpd, openntpd.

In both cases I see this during the build:
Code:
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2345:6: error: conflicting types for 'X509_get0_signature'
void X509_get0_signature(ASN1_BIT_STRING **psig, X509_ALGOR **palg,
     ^
/usr/local/include/openssl/x509.h:919:6: note: previous declaration is here
void X509_get0_signature(const ASN1_BIT_STRING **psig,
     ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2479:7: error: redefinition of 'X509_VERIFY_PARAM_set1_host' as
      different kind of symbol
int (*X509_VERIFY_PARAM_set1_host)(X509_VERIFY_PARAM *, const char *,
      ^
/usr/local/include/openssl/x509_vfy.h:564:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_host(X509_VERIFY_PARAM *param, const char *name,
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2481:7: error: redefinition of 'X509_VERIFY_PARAM_set1_email' as
      different kind of symbol
int (*X509_VERIFY_PARAM_set1_email)(X509_VERIFY_PARAM *, const char *,
      ^
/usr/local/include/openssl/x509_vfy.h:571:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_email(X509_VERIFY_PARAM *param,  const char *email,
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2483:7: error: redefinition of 'X509_VERIFY_PARAM_set1_ip' as
      different kind of symbol
int (*X509_VERIFY_PARAM_set1_ip)(X509_VERIFY_PARAM *, const unsigned char *,
      ^
/usr/local/include/openssl/x509_vfy.h:573:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_ip(X509_VERIFY_PARAM *param, const unsigned char *ip,
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2485:7: error: redefinition of 'X509_VERIFY_PARAM_set1_ip_asc'
      as different kind of symbol
int (*X509_VERIFY_PARAM_set1_ip_asc)(X509_VERIFY_PARAM *, const char *) = NULL;
      ^
/usr/local/include/openssl/x509_vfy.h:575:5: note: previous definition is here
int X509_VERIFY_PARAM_set1_ip_asc(X509_VERIFY_PARAM *param, const char *ipasc);
    ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2486:8: error: redefinition of 'X509_VERIFY_PARAM_set_hostflags'
      as different kind of symbol
void (*X509_VERIFY_PARAM_set_hostflags)(X509_VERIFY_PARAM *,
       ^
/usr/local/include/openssl/x509_vfy.h:568:6: note: previous definition is here
void X509_VERIFY_PARAM_set_hostflags(X509_VERIFY_PARAM *param,
     ^
build/temp.freebsd-11.1-RELEASE-amd64-3.6/_openssl.c:2525:7: error: conflicting types for 'X509_OBJECT_get0_X509'
X509 *X509_OBJECT_get0_X509(X509_OBJECT *x) {
 
I tried both:
1. On an existing installation where I have LibreSSL 2.6.4, ran portmaster -r libressl - no luck with security/py-certbot.

yeah, i did as well, but after a portsnap fetch update I ran a portmaster -Rafd, which failed at security/py-cryptography (I'm a bit chagrined to admit given the instructions in /usr/ports/UPDATING) with

Code:
/usr/local/include/openssl/x509.h:919:50: note: passing argument to parameter 'psig' here
void X509_get0_signature(const ASN1_BIT_STRING **psig,
                                                 ^
build/temp.freebsd-10.3-RELEASE-p28-amd64-2.7/_openssl.c:62265:27: warning: passing 'X509_ALGOR **' (aka 'struct X509_algor_st **') to parameter of type 'const X509_ALGOR **' (aka 'const struct X509_algor_st **')
      discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
  X509_get0_signature(x0, x1, x2);
                          ^~
/usr/local/include/openssl/x509.h:920:24: note: passing argument to parameter 'palg' here
    const X509_ALGOR **palg, const X509 *x);
                       ^
build/temp.freebsd-10.3-RELEASE-p28-amd64-2.7/_openssl.c:62317:25: warning: passing 'ASN1_OCTET_STRING **' (aka 'struct asn1_string_st **') to parameter of type 'const ASN1_BIT_STRING **'
      (aka 'const struct asn1_string_st **') discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
  { X509_get0_signature(x0, x1, x2); }
                        ^~
/usr/local/include/openssl/x509.h:919:50: note: passing argument to parameter 'psig' here
void X509_get0_signature(const ASN1_BIT_STRING **psig,
                                                 ^
build/temp.freebsd-10.3-RELEASE-p28-amd64-2.7/_openssl.c:62317:29: warning: passing 'X509_ALGOR **' (aka 'struct X509_algor_st **') to parameter of type 'const X509_ALGOR **' (aka 'const struct X509_algor_st **')
      discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
      discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
  { X509_get0_signature(x0, x1, x2); }
                            ^~
/usr/local/include/openssl/x509.h:920:24: note: passing argument to parameter 'palg' here
    const X509_ALGOR **palg, const X509 *x);

etc. Same basic error. If you ran anything before running portmaster -r libressl, your problem is the same as mine and PR PR226906 is (hopefully) both our solution. If you updated your ports tree and first thing ran portmaster -r libressl and still had problems with security/py-cryptography@py36 as above, then it would seem to indicate that the instructions in /usr/ports/UPDATING aren't sufficient (maybe I'm a little less chagrined as I would normally share ShelLuser's skepticism). However, in either case I think applying the patches in PR PR226906 is the way through. I'll post if I'm successful.
 
Back
Top