Re: svn commit: r558913 - in head/lang: python-doc-html python38

2020-12-22 Thread Dima Panov
Holy cow!

This is a future of all python branches. We need to rework our py build system

* bpo-42604: Now all platforms use a value for the “EXT_SUFFIX” build variable 
derived from SOABI (for instance in freeBSD, “EXT_SUFFIX” is now 
“.cpython-310d.so” instead of “.so”). Previosuly only Linux, Mac and VxWorks 
were using a value for “EXT_SUFFIX” that included “SOABI”.

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)

> On Wednesday, Dec 23, 2020 at 12:55 PM, Kubilay Kocak  (mailto:ko...@freebsd.org)> wrote:
> On 23/12/2020 1:41 pm, Dima Panov wrote:
> > Better will be resolve errors of packages building. It works for py39 which 
> > used same cpython build internals as this py38 update do now.
>
> Agree, move forward better than a revert.
>
> This is being tracked (reported by users) at:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252057
>
> > --
> > Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
> > (flu...@freebsd.org, https://t.me/dima_panov)
> >
> > > On Wednesday, Dec 23, 2020 at 11:51 AM, wen heping 
> > > mailto:wenheping2...@hotmail.com)> wrote:
> > > python-3.8 is not the default python version, so we do not require a 
> > > exprun for
> > > its update before.
> > >
> > > But I shall revert it if this update break other ports.
> > >
> > > wen
> > >
> > >
> > > 发件人: Dima Panov
> > > 已发送: 2020 12 月 23 日 星期三 9:19
> > > 收件人: Wen Heping; svn-ports-...@freebsd.org; svn-ports-h...@freebsd.org; 
> > > ports-committ...@freebsd.org
> > > 主题: Re: svn commit: r558913 - in head/lang: python-doc-html python38
> > >
> > > Moin!
> > >
> > >
> > > Did you ecen start exp-run for this update? Too many python ports fails 
> > > to package after this update.
> > >
> > > devel/gobject-introspection
> > > devel/py-cffi
> > > devel/py-coverage
> > > devel/py-greenlet
> > > textproc/py-libxml2
> > > textproc/py-markupsafe
> > >
> > > and many other claims about generated py-library.so is missing (gir, for 
> > > example: lib/gobject-introspection/giscanner_giscanner.so: No such file 
> > > or directory)
> > >
> > > --
> > > Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
> > > (flu...@freebsd.org, https://t.me/dima_panov)
> > >
> > >
> > > > On Wednesday, Dec 23, 2020 at 12:58 AM, Wen Heping  > > > (mailto:w...@freebsd.org)> wrote:
> > > > Author: wen
> > > > Date: Tue Dec 22 14:58:05 2020
> > > > New Revision: 558913
> > > > URL: https://svnweb.freebsd.org/changeset/ports/558913
> > > >
> > > > Log:
> > > > - Update to 3.8.7
> > > >
> > > > Modified:
> > > > head/lang/python-doc-html/distinfo
> > > > head/lang/python38/Makefile
> > > > head/lang/python38/Makefile.version
> > > > head/lang/python38/distinfo
> > > > head/lang/python38/pkg-plist
> > > >
> > > > Modified: head/lang/python-doc-html/distinfo
> > > > ==
> > > > --- head/lang/python-doc-html/distinfo Tue Dec 22 14:33:07 2020 
> > > > (r558912)
> > > > +++ head/lang/python-doc-html/distinfo Tue Dec 22 14:58:05 2020 
> > > > (r558913)
> > > > @@ -1,4 +1,4 @@
> > > > -TIMESTAMP = 1607436675
> > > > +TIMESTAMP = 1608648364
> > > > SHA256 (python/python-2.7.18-docs-html.tar.bz2) = 
> > > > 3d05142817615e77cec99f686dca58289bbfe008af22f94a93262e8663db81c7
> > > > SIZE (python/python-2.7.18-docs-html.tar.bz2) = 4732851
> > > > SHA256 (python/python-2.7.18-docs-pdf-a4.tar.bz2) = 
> > > > ead357695e43c824ae1a83dd6cd3b4a47215658f3fa20111726ff7ef16a16dd2
> > > > @@ -23,14 +23,14 @@ SHA256 
> > > > (python/python-3.7.9-docs-pdf-letter.tar.bz2) =
> > > > SIZE (python/python-3.7.9-docs-pdf-letter.tar.bz2) = 14332368
> > > > SHA256 (python/python-3.7.9-docs-text.tar.bz2) = 
> > > > b1a78d8303f9f334353ed3c3ad619190d4a8907eb137d894c1ffb457e523b518
> > > > SIZE (python/python-3.7.9-docs-text.tar.bz2) = 2291659
> > > > -SHA256 (python/python-3.8.6-docs-html.tar.bz2) = 
> > > > 60b8e4c913e51367dcc661c3e3427a9a05a7dd69b3f032b93503acebb195e03f
> > > > -SIZE (python/python-3.8.6-docs-html.tar.bz2) = 6578280
> > > > -SHA256 (python/python-3.8.6-docs-pdf-a4.tar.bz2) = 
> > > > 8c8258d7781888ee48cb790f2e60bf2feb540f0c621a46684dc53e71fe74bc39
> > > > -SIZE (python/python-3.8.6-docs-pdf-a4.tar.bz2) = 14711150
> > > > -SHA256 (python/python-3.8.6-docs-pdf-letter.tar.bz2) = 
> > > > b8f29a407911e63161b3669d304180c44fc8cd65f9fba44473eab7714274f966
> > > > -SIZE (python/python-3.8.6-docs-pdf-letter.tar.bz2) = 14825147
> > > > -SHA256 (python/python-3.8.6-docs-text.tar.bz2) = 
> > > > 1def93d60e46c2925b4618ee02628cef9e8570c3aeb016ac5385576d953fa642
> > > > -SIZE (python/python-3.8.6-docs-text.tar.bz2) = 2409251
> > > > +SHA256 (python/python-3.8.7-docs-html.tar.bz2) = 
> > > > b6cd1c6eab3725711998e37655cbe2a87486d940cd98b558439a857e80df
> > > > +SIZE (python/python-3.8.7-docs-html.tar.bz2) = 6583700
> > > > +SHA256 (python/python-3.8.7-docs-pdf-a4.tar.bz2) = 
> > > > e6d2e8c3d4c413f4fbeb83f5686336364921dd13b31e880

FreeBSD ports you maintain which are out of date

2020-12-22 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
databases/postgresql-orafce | 3_13_4  | 3.14.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!
___
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"


Re: svn commit: r558913 - in head/lang: python-doc-html python38

2020-12-22 Thread Kubilay Kocak

On 23/12/2020 1:41 pm, Dima Panov wrote:

Better will be resolve errors of packages building. It works for py39 which 
used same cpython build internals as this py38 update do now.


Agree, move forward better than a revert.

This is being tracked (reported by users) at:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252057


--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)


On Wednesday, Dec 23, 2020 at 11:51 AM, wen heping mailto:wenheping2...@hotmail.com)> wrote:
python-3.8 is not the default python version, so we do not require a exprun for
its update before.

But I shall revert it if this update break other ports.

wen


发件人: Dima Panov
已发送: 2020 12 月 23 日 星期三 9:19
收件人: Wen Heping; svn-ports-...@freebsd.org; svn-ports-h...@freebsd.org; 
ports-committ...@freebsd.org
主题: Re: svn commit: r558913 - in head/lang: python-doc-html python38

Moin!


Did you ecen start exp-run for this update? Too many python ports fails to 
package after this update.

devel/gobject-introspection
devel/py-cffi
devel/py-coverage
devel/py-greenlet
textproc/py-libxml2
textproc/py-markupsafe

and many other claims about generated py-library.so is missing (gir, for 
example: lib/gobject-introspection/giscanner_giscanner.so: No such file or 
directory)

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)



On Wednesday, Dec 23, 2020 at 12:58 AM, Wen Heping mailto:w...@freebsd.org)> wrote:
Author: wen
Date: Tue Dec 22 14:58:05 2020
New Revision: 558913
URL: https://svnweb.freebsd.org/changeset/ports/558913

Log:
- Update to 3.8.7

Modified:
head/lang/python-doc-html/distinfo
head/lang/python38/Makefile
head/lang/python38/Makefile.version
head/lang/python38/distinfo
head/lang/python38/pkg-plist

Modified: head/lang/python-doc-html/distinfo
==
--- head/lang/python-doc-html/distinfo Tue Dec 22 14:33:07 2020 (r558912)
+++ head/lang/python-doc-html/distinfo Tue Dec 22 14:58:05 2020 (r558913)
@@ -1,4 +1,4 @@
-TIMESTAMP = 1607436675
+TIMESTAMP = 1608648364
SHA256 (python/python-2.7.18-docs-html.tar.bz2) = 
3d05142817615e77cec99f686dca58289bbfe008af22f94a93262e8663db81c7
SIZE (python/python-2.7.18-docs-html.tar.bz2) = 4732851
SHA256 (python/python-2.7.18-docs-pdf-a4.tar.bz2) = 
ead357695e43c824ae1a83dd6cd3b4a47215658f3fa20111726ff7ef16a16dd2
@@ -23,14 +23,14 @@ SHA256 (python/python-3.7.9-docs-pdf-letter.tar.bz2) =
SIZE (python/python-3.7.9-docs-pdf-letter.tar.bz2) = 14332368
SHA256 (python/python-3.7.9-docs-text.tar.bz2) = 
b1a78d8303f9f334353ed3c3ad619190d4a8907eb137d894c1ffb457e523b518
SIZE (python/python-3.7.9-docs-text.tar.bz2) = 2291659
-SHA256 (python/python-3.8.6-docs-html.tar.bz2) = 
60b8e4c913e51367dcc661c3e3427a9a05a7dd69b3f032b93503acebb195e03f
-SIZE (python/python-3.8.6-docs-html.tar.bz2) = 6578280
-SHA256 (python/python-3.8.6-docs-pdf-a4.tar.bz2) = 
8c8258d7781888ee48cb790f2e60bf2feb540f0c621a46684dc53e71fe74bc39
-SIZE (python/python-3.8.6-docs-pdf-a4.tar.bz2) = 14711150
-SHA256 (python/python-3.8.6-docs-pdf-letter.tar.bz2) = 
b8f29a407911e63161b3669d304180c44fc8cd65f9fba44473eab7714274f966
-SIZE (python/python-3.8.6-docs-pdf-letter.tar.bz2) = 14825147
-SHA256 (python/python-3.8.6-docs-text.tar.bz2) = 
1def93d60e46c2925b4618ee02628cef9e8570c3aeb016ac5385576d953fa642
-SIZE (python/python-3.8.6-docs-text.tar.bz2) = 2409251
+SHA256 (python/python-3.8.7-docs-html.tar.bz2) = 
b6cd1c6eab3725711998e37655cbe2a87486d940cd98b558439a857e80df
+SIZE (python/python-3.8.7-docs-html.tar.bz2) = 6583700
+SHA256 (python/python-3.8.7-docs-pdf-a4.tar.bz2) = 
e6d2e8c3d4c413f4fbeb83f5686336364921dd13b31e880daa7161ac9739b70b
+SIZE (python/python-3.8.7-docs-pdf-a4.tar.bz2) = 14727427
+SHA256 (python/python-3.8.7-docs-pdf-letter.tar.bz2) = 
bc99b4ff989518fdde5dd9720cc74713c36b31cb9204bef12ea6957d3a2c8c9e
+SIZE (python/python-3.8.7-docs-pdf-letter.tar.bz2) = 14846046
+SHA256 (python/python-3.8.7-docs-text.tar.bz2) = 
f406249802f8c860dbd64ee7141c1394ed5fbb6908a72f29fd12580de62b5f6a
+SIZE (python/python-3.8.7-docs-text.tar.bz2) = 2413290
SHA256 (python/python-3.9.1-docs-html.tar.bz2) = 
c56e35cd0ee8f7b7fa115b1b58572c9319c2b3e65b823c1a9155734c0a9a751a
SIZE (python/python-3.9.1-docs-html.tar.bz2) = 6806786
SHA256 (python/python-3.9.1-docs-pdf-a4.tar.bz2) = 
3ab5ce54b1165c6575ae577e1fae7d7336d34e9c62ad4df790c02d9d354e2f19

Modified: head/lang/python38/Makefile
==
--- head/lang/python38/Makefile Tue Dec 22 14:33:07 2020 (r558912)
+++ head/lang/python38/Makefile Tue Dec 22 14:58:05 2020 (r558913)
@@ -3,7 +3,6 @@

PORTNAME= python
PORTVERSION= ${PYTHON_PORTVERSION}
-PORTREVISION= 1
CATEGORIES= lang python
MASTER_SITES= PYTHON/ftp/python/${PORTVERSION}
PKGNAMESUFFIX= ${PYTHON_SUFFIX}

Modified: head/lang/python38/Makefile.version
===

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 
py

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"


Re: devel/rust-cbindgen fails to build

2020-12-22 Thread Torfinn Ingolfsen
building rust-cbindgen-0.16.0 also fails on this machine, in the same
way. But - I installed rust-cbindgen from ports on another  FreeBSD
11.4-release machine, starting from "clean" (nothing installed except
for pkg, which then was upgraded from ports), madea package from that
and used 'pkg add' to install said package on this machine. That
worked for now.
It is likely that the build environment for (some) ports is broken
somehow on this machine.

On Sun, Dec 20, 2020 at 11:05 PM Torfinn Ingolfsen  wrote:
>
> rust-cbindgen-0.15.0_2 also fails:
>
> root@kg-core1# make clean
> ===>  Cleaning for rust-cbindgen-0.15.0_2
> root@kg-core1# make
> ===>  License MPL20 accepted by the user
> ===>   rust-cbindgen-0.15.0_2 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by rust-cbindgen-0.15.0_2 for building
> ===>  Extracting for rust-cbindgen-0.15.0_2
> => SHA256 Checksum OK for rust/crates/cbindgen-0.15.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/ansi_term-0.11.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/atty-0.2.14.tar.gz.
> => SHA256 Checksum OK for rust/crates/autocfg-1.0.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/bitflags-1.2.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/cfg-if-0.1.10.tar.gz.
> => SHA256 Checksum OK for rust/crates/clap-2.33.3.tar.gz.
> => SHA256 Checksum OK for rust/crates/getrandom-0.1.15.tar.gz.
> => SHA256 Checksum OK for rust/crates/hashbrown-0.9.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/heck-0.3.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/hermit-abi-0.1.16.tar.gz.
> => SHA256 Checksum OK for rust/crates/indexmap-1.6.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/itoa-0.4.6.tar.gz.
> => SHA256 Checksum OK for rust/crates/libc-0.2.77.tar.gz.
> => SHA256 Checksum OK for rust/crates/log-0.4.11.tar.gz.
> => SHA256 Checksum OK for rust/crates/ppv-lite86-0.2.9.tar.gz.
> => SHA256 Checksum OK for rust/crates/proc-macro2-1.0.21.tar.gz.
> => SHA256 Checksum OK for rust/crates/quote-1.0.7.tar.gz.
> => SHA256 Checksum OK for rust/crates/rand-0.7.3.tar.gz.
> => SHA256 Checksum OK for rust/crates/rand_chacha-0.2.2.tar.gz.
> => SHA256 Checksum OK for rust/crates/rand_core-0.5.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/rand_hc-0.2.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/redox_syscall-0.1.57.tar.gz.
> => SHA256 Checksum OK for rust/crates/remove_dir_all-0.5.3.tar.gz.
> => SHA256 Checksum OK for rust/crates/ryu-1.0.5.tar.gz.
> => SHA256 Checksum OK for rust/crates/serde-1.0.116.tar.gz.
> => SHA256 Checksum OK for rust/crates/serde_derive-1.0.116.tar.gz.
> => SHA256 Checksum OK for rust/crates/serde_json-1.0.57.tar.gz.
> => SHA256 Checksum OK for rust/crates/strsim-0.8.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/syn-1.0.41.tar.gz.
> => SHA256 Checksum OK for rust/crates/tempfile-3.1.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/textwrap-0.11.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/toml-0.5.6.tar.gz.
> => SHA256 Checksum OK for rust/crates/unicode-segmentation-1.6.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/unicode-width-0.1.8.tar.gz.
> => SHA256 Checksum OK for rust/crates/unicode-xid-0.2.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/vec_map-0.8.2.tar.gz.
> => SHA256 Checksum OK for 
> rust/crates/wasi-0.9.0+wasi-snapshot-preview1.tar.gz.
> => SHA256 Checksum OK for rust/crates/winapi-0.3.9.tar.gz.
> => SHA256 Checksum OK for rust/crates/winapi-i686-pc-windows-gnu-0.4.0.tar.gz.
> => SHA256 Checksum OK for 
> rust/crates/winapi-x86_64-pc-windows-gnu-0.4.0.tar.gz.
> ===>  Moving crates to
> /usr/ports/devel/rust-cbindgen/work/cbindgen-0.15.0/cargo-crates
> ===>  Patching for rust-cbindgen-0.15.0_2
> ===>   rust-cbindgen-0.15.0_2 depends on package: rust>=1.48.0 - found
> ===>  Configuring for rust-cbindgen-0.15.0_2
> thread 'main' panicked at 'couldn't initialize the libgit2 library:
> -1, error: could not initialize openssl: error:1410D0B9:SSL
> routines:SSL_CTX_set_cipher_list:no cipher match',
> /usr/ports/lang/rust/work/rustc-1.48.0-src/vendor/libgit2-sys/lib.rs:3807:9
> stack backtrace:
> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
> verbose backtrace.
> *** Error code 101
>
> Stop.
> make: stopped in /usr/ports/devel/rust-cbindgen
> RUST_BACKTRACE=full doesn't give much
> root@kg-core1# RUST_BACKTRACE=full make clean
> ===>  Cleaning for rust-cbindgen-0.15.0_2
> root@kg-core1# RUST_BACKTRACE=full make
> ===>  License MPL20 accepted by the user
> ===>   rust-cbindgen-0.15.0_2 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by rust-cbindgen-0.15.0_2 for building
> ===>  Extracting for rust-cbindgen-0.15.0_2
> => SHA256 Checksum OK for rust/crates/cbindgen-0.15.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/ansi_term-0.11.0.tar.gz.
> => SHA256 Checksum OK for rust/crates/atty-0.2.14.tar.gz.
> => SHA256 Checksum OK for rust/crates/autocfg-1.0.1.tar.gz.
> => SHA256 Checksum OK for rust/crates/bitflags-1.2.1.tar.gz.
> => SHA2

Re: Committer needed: x11-wm/ctwm, PR 251520

2020-12-22 Thread Matthew D. Fuller
On Sun, Dec 20, 2020 at 10:18:23AM +0100 I heard the voice of
Kurt Jaeger, and lo! it spake thus:
> > 
> > Can somebody land the patch in the approved attachment to
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251520
> > ?
> 
> Done.

Thanks!


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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"


Re: textproc/goldendict does not compile on CURRENT

2020-12-22 Thread Matthias Apitz
El día sábado, diciembre 19, 2020 a las 10:49:42p. m. +0100, Matthias Apitz 
escribió:

> 
> Hello,
> 
> I was building textproc/goldendict on amd64 CURRENT and it failes to
> compile with:

I see in SVN that the port was updated (r556759) one day after my 'svn co' 
Thanks and sorry for the noice. Next time I will look for a PR and into
SVN before sending such mail.

matthias



-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich 
Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
___
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"