Re: Build errors in Python packages with compiled extensions

2020-12-22 Thread John Kennedy
On Tue, Dec 22, 2020 at 05:25:41PM -0800, John Kennedy wrote:
> On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote:
> > Hello,
> > 
> > I have started to notice poudriere builds of Python ports with compiled 
> > extensions failing:
> > 
> > [00:00:11] /usr/bin/strip 
> > /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
> > [00:00:11] strip: open 
> > /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
> >  failed: No such file or directory
> > 
> > The reason is that setuptools puts a version tag (aka cache tag) into the 
> > .so's name; in this case it is actually _cffi_backend.cpython-38.so . The 
> > strip command, on the other hand, is in the port Makefile's post-install 
> > target and has the file name as above, without the version.
> > 
> > This tag is to be available in Uses/python.mk as $PYMAGICTAG, e.g. 
> > "cpython-38".
> > 
> > I'm not sure whether I'm not doing something wrong that causes the tag to 
> > end up in the .so file names. The last update to devel/py-setuptools was a 
> > while ago (to 44.0 in January 2020), and someone would probably have 
> > noticed since. On the other hand, this _is_ poudriere, so the build 
> > environments are pretty well isolated.
> > 
> > Anyone know what is going on?
> 
>   Not just you.  As soon as I upgraded python38 from 3.8.6_1 -> 3.8.7, I ran
> into the same kind of problems...  my local poudriere build failed 7 python
> packages and skipped another 96.  I don't have the exact same setup, but it
> happened on both -CURRENT and releng/12.2.
> 
>   So, ports rev 558913 ~Tue Dec 22 14:58:05 2020 +.
> 
>   I opened up bug 252057.

  As a follow-up to myself, it looks like I did a upgrade pass ~11:08 (my TZ,
PST8PDT) which was fine and then a pass ~14:42 where pkg (1.16.0) and python38
got upgraded.

  Now, packages that get upgraded seem to be a subset of what got built, so
it's possible that something else in the same pass might be at fault.  Just
looking at the dates in my poudriere package stash might help someone way
more python-savvy than I:

 8585 -rw-r--r--  1 nobody  wheel8713736 Dec 22 14:33 pkg-1.16.0.txz
17553 -rw-r--r--  1 nobody  wheel   17841384 Dec 22 14:35 
python38-3.8.7.txz
  649 -rw-r--r--  1 nobody  wheel 527536 Dec 22 14:35 
py38-setuptools-44.0.0.txz
  265 -rw-r--r--  1 nobody  wheel 168752 Dec 22 14:35 
py38-pycparser-2.20.txz
   21 -rw-r--r--  1 nobody  wheel  19664 Dec 22 14:35 
py38-six-1.15.0.txz
  101 -rw-r--r--  1 nobody  wheel 100440 Dec 22 14:35 
ninja-1.10.2,2.txz
  265 -rw-r--r--  1 nobody  wheel 141576 Dec 22 14:35 
py38-certifi-2020.12.5.txz
   25 -rw-r--r--  1 nobody  wheel  24492 Dec 22 14:35 
py38-pysocks-1.7.1.txz
   69 -rw-r--r--  1 nobody  wheel  65712 Dec 22 14:36 
py38-idna-2.10.txz
  265 -rw-r--r--  1 nobody  wheel 161056 Dec 22 14:36 
py38-pytz-2020.1,1.txz
 5001 -rw-r--r--  1 nobody  wheel4988776 Dec 22 14:36 git-2.29.2.txz
  113 -rw-r--r--  1 nobody  wheel 111728 Dec 22 14:36 
py38-pyparsing-2.4.7.txz
 1161 -rw-r--r--  1 nobody  wheel1059760 Dec 22 14:36 
meson-0.56.0.txz
  265 -rw-r--r--  1 nobody  wheel 155488 Dec 22 14:36 
py38-chardet-3.0.4_3.txz
9 -rw-r--r--  1 nobody  wheel   6212 Dec 22 14:36 
py38-imagesize-1.1.0.txz
 5129 -rw-r--r--  1 nobody  wheel5224196 Dec 22 14:36 
py38-Babel-2.8.0.txz
   21 -rw-r--r--  1 nobody  wheel  19760 Dec 22 14:36 
py38-sphinxcontrib-qthelp-1.0.3.txz
   57 -rw-r--r--  1 nobody  wheel  54436 Dec 22 14:36 
py38-packaging-20.8.txz
   25 -rw-r--r--  1 nobody  wheel  22616 Dec 22 14:36 
py38-sphinxcontrib-htmlhelp-1.0.3.txz
   17 -rw-r--r--  1 nobody  wheel  15900 Dec 22 14:36 
py38-sphinxcontrib-devhelp-1.0.2.txz
   21 -rw-r--r--  1 nobody  wheel  17508 Dec 22 14:36 
py38-sphinxcontrib-serializinghtml-1.1.4.txz
 1929 -rw-r--r--  1 nobody  wheel1935412 Dec 22 14:37 
py38-cython-0.29.21.txz
 7561 -rw-r--r--  1 nobody  wheel7645180 Dec 22 14:37 
vim-8.2.2072.txz
 1289 -rw-r--r--  1 nobody  wheel1289680 Dec 22 14:37 
py38-pygments-2.7.2.txz
9 -rw-r--r--  1 nobody  wheel   6088 Dec 22 14:37 
py38-sphinxcontrib-jsmath-1.0.1.txz
   25 -rw-r--r--  1 nobody  wheel  21364 Dec 22 14:37 
py38-sphinxcontrib-applehelp-1.0.2.txz
   17 -rw-r--r--  1 nobody  wheel  15764 Dec 22 14:37 
py38-alabaster-0.7.6.txz
  649 -rw-r--r--  1 nobody  wheel 650632 Dec 22 14:37 
py38-future-0.18.2.txz
   85 -rw-r--r--  1 nobody  wheel  82784 Dec 22 14:37 
py38-beaker-1.11.0.txz
   85 -rw-r--r--  1 nobody  wheel  84420 Dec 22 14:37 
py38-CommonMark-0.9.1.txz
   65 -rw-r--r--  1 nobody  wheel  63344 Dec 22 14:37 

Re: Build errors in Python packages with compiled extensions

2020-12-22 Thread John Kennedy
On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote:
> Hello,
> 
> I have started to notice poudriere builds of Python ports with compiled 
> extensions failing:
> 
> [00:00:11] /usr/bin/strip 
> /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
> [00:00:11] strip: open 
> /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
>  failed: No such file or directory
> 
> The reason is that setuptools puts a version tag (aka cache tag) into the 
> .so's name; in this case it is actually _cffi_backend.cpython-38.so . The 
> strip command, on the other hand, is in the port Makefile's post-install 
> target and has the file name as above, without the version.
> 
> This tag is to be available in Uses/python.mk as $PYMAGICTAG, e.g. 
> "cpython-38".
> 
> I'm not sure whether I'm not doing something wrong that causes the tag to end 
> up in the .so file names. The last update to devel/py-setuptools was a while 
> ago (to 44.0 in January 2020), and someone would probably have noticed since. 
> On the other hand, this _is_ poudriere, so the build environments are pretty 
> well isolated.
> 
> Anyone know what is going on?

  Not just you.  As soon as I upgraded python38 from 3.8.6_1 -> 3.8.7, I ran
into the same kind of problems...  my local poudriere build failed 7 python
packages and skipped another 96.  I don't have the exact same setup, but it
happened on both -CURRENT and releng/12.2.

  So, ports rev 558913 ~Tue Dec 22 14:58:05 2020 +.

  I opened up bug 252057.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Build errors in Python packages with compiled extensions

2020-12-22 Thread Christian Ullrich

Hello,

I have started to notice poudriere builds of Python ports with compiled 
extensions failing:

[00:00:11] /usr/bin/strip 
/wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
[00:00:11] strip: open 
/wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
 failed: No such file or directory

The reason is that setuptools puts a version tag (aka cache tag) into the .so's 
name; in this case it is actually _cffi_backend.cpython-38.so . The strip 
command, on the other hand, is in the port Makefile's post-install target and 
has the file name as above, without the version.

This tag is to be available in Uses/python.mk as $PYMAGICTAG, e.g. "cpython-38".

I'm not sure whether I'm not doing something wrong that causes the tag to end 
up in the .so file names. The last update to devel/py-setuptools was a while 
ago (to 44.0 in January 2020), and someone would probably have noticed since. 
On the other hand, this _is_ poudriere, so the build environments are pretty 
well isolated.

Anyone know what is going on?


--
Christian
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"