Re: Fw: Re: Ask help to contribute codes to https://github.com/libressl-portable/

[Xiao Ling XL Chen]

Hi Abel,

May I contact you about the contribution of our porting source code? If no,
please tell me the correct person who can mentor me. Thanks.

There is no message
Best regards,
Sunny (Xiao Ling Chen)

z/OS USS DBX Development and L3
IBM China Systems & Technology Lab (CSTL)
Tel:86-010-82452454
E-mail: chenx...@cn.ibm.com



From:   Abel Abraham Camarillo Ojeda 
To: Xiao Ling XL Chen 
Cc: ports 
Date:   2020/11/24 02:43 PM
Subject:[EXTERNAL] Re: Fw: Re: Ask help to contribute codes to
https://github.com/libressl-portable/



On Tue, Nov 24, 2020 at 12:22 AM Xiao Ling XL Chen ...









  This Message Is From an External Sender   
  This message came from outside your organization. 









On Tue, Nov 24, 2020 at 12:22 AM Xiao Ling XL Chen 
wrote:

  I ported libRessl to IBM zOS platform and would like to contribute our
  code
  to libressl github, is there anyone guides me the process? Thanks.

  Best regards,
  Sunny (Xiao Ling Chen)

  z/OS USS DBX Development and L3
  IBM China Systems & Technology Lab (CSTL)
  Tel:    86-010-82452454
  E-mail: chenx...@cn.ibm.com




  - Forwarded by Xiao Ling XL Chen/China/IBM on 2020/11/23 10:41 AM
  -

  From:   Stuart Henderson 
  To:     Xiao Ling XL Chen 
  Cc:     ports@openbsd.org
  Date:   2020/01359/14 07:08 PM
  Subject:        [EXTERNAL] Re: Ask help to contribute codes to
              https://github.com/libressl-portable/



  On 2020/09/14 18:35, Xiao Ling XL Chen wrote:
  > Hi Stuart,
  >
  > Thanks for your quick response, I will go through the guide. May I send
  email to you directly
  > if I have questions during push our codes later?

  I am not particularly involved with LibreSSL myself, it is best if you
  ask your questions on one of the mailing lists, t...@openbsd.org is
  probably
  best for sending diffs, libre...@openbsd.org might be better for more
  general
  discussions
  https://www.libressl.org/mail.html





I've seen lots of messages being ignored because the sender asks for a
reply too soon,
I think the average time for a response is around a week. Perhaps try again
next week...

regards

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/11/24 00:47:21

Modified files:
geo/mdal   : Makefile distinfo 

Log message:
Update to MDAL 0.7.2

Re: Fw: Re: Ask help to contribute codes to https://github.com/libressl-portable/

[Xiao Ling XL Chen]

I ported libRessl to IBM zOS platform in May and want to contribute our
code to libressl github, is there anyone who can mentor me the process?
Thanks.


Best regards,
Sunny (Xiao Ling Chen)

z/OS USS DBX Development and L3
IBM China Systems & Technology Lab (CSTL)
Tel:86-010-82452454
E-mail: chenx...@cn.ibm.com



- Forwarded by Xiao Ling XL Chen/China/IBM on 2020/11/23 10:41 AM -

From:   Stuart Henderson 
To: Xiao Ling XL Chen 
Cc: ports@openbsd.org
Date:   2020/09/14 07:08 PM
Subject:[EXTERNAL] Re: Ask help to contribute codes to
https://github.com/libressl-portable/



On 2020/09/14 18:35, Xiao Ling XL Chen wrote:
> Hi Stuart,
>
> Thanks for your quick response, I will go through the guide. May I send
email to you directly
> if I have questions during push our codes later?

I am not particularly involved with LibreSSL myself, it is best if you
ask your questions on one of the mailing lists, t...@openbsd.org is
probably
best for sending diffs, libre...@openbsd.org might be better for more
general
discussions
https://www.libressl.org/mail.html

Re: Fw: Re: Ask help to contribute codes to https://github.com/libressl-portable/

[Abel Abraham Camarillo Ojeda]

On Tue, Nov 24, 2020 at 12:22 AM Xiao Ling XL Chen 
wrote:

>
> I ported libRessl to IBM zOS platform and would like to contribute our code
> to libressl github, is there anyone guides me the process? Thanks.
>
> Best regards,
> Sunny (Xiao Ling Chen)
>
> z/OS USS DBX Development and L3
> IBM China Systems & Technology Lab (CSTL)
> Tel:86-010-82452454
> E-mail: chenx...@cn.ibm.com
>
>
>
>
> - Forwarded by Xiao Ling XL Chen/China/IBM on 2020/11/23 10:41 AM -
>
> From:   Stuart Henderson 
> To: Xiao Ling XL Chen 
> Cc: ports@openbsd.org
> Date:   2020/01359/14 07:08 PM
> Subject:[EXTERNAL] Re: Ask help to contribute codes to
> https://github.com/libressl-portable/
>
>
>
> On 2020/09/14 18:35, Xiao Ling XL Chen wrote:
> > Hi Stuart,
> >
> > Thanks for your quick response, I will go through the guide. May I send
> email to you directly
> > if I have questions during push our codes later?
>
> I am not particularly involved with LibreSSL myself, it is best if you
> ask your questions on one of the mailing lists, t...@openbsd.org is
> probably
> best for sending diffs, libre...@openbsd.org might be better for more
> general
> discussions
> https://www.libressl.org/mail.html
>
>
>
>

I've seen lots of messages being ignored because the sender asks for a
reply too soon,
I think the average time for a response is around a week. Perhaps try again
next week...

regards

Re: Fw: Re: Ask help to contribute codes to https://github.com/libressl-portable/

[Xiao Ling XL Chen]

I ported libRessl to IBM zOS platform and would like to contribute our code
to libressl github, is there anyone guides me the process? Thanks.

Best regards,
Sunny (Xiao Ling Chen)

z/OS USS DBX Development and L3
IBM China Systems & Technology Lab (CSTL)
Tel:86-010-82452454
E-mail: chenx...@cn.ibm.com




- Forwarded by Xiao Ling XL Chen/China/IBM on 2020/11/23 10:41 AM -

From:   Stuart Henderson 
To: Xiao Ling XL Chen 
Cc: ports@openbsd.org
Date:   2020/09/14 07:08 PM
Subject:[EXTERNAL] Re: Ask help to contribute codes to
https://github.com/libressl-portable/



On 2020/09/14 18:35, Xiao Ling XL Chen wrote:
> Hi Stuart,
>
> Thanks for your quick response, I will go through the guide. May I send
email to you directly
> if I have questions during push our codes later?

I am not particularly involved with LibreSSL myself, it is best if you
ask your questions on one of the mailing lists, t...@openbsd.org is
probably
best for sending diffs, libre...@openbsd.org might be better for more
general
discussions
https://www.libressl.org/mail.html

sparc64 bulk build report

[kmos]

Bulk build on sparc64-0.ports.openbsd.org

Started : Fri Nov 20 23:49:43 MST 2020
Finished: Mon Nov 23 21:38:24 MST 2020
Duration: 2 Days 21 hours 49 minutes

Built using OpenBSD 6.8-current (GENERIC.MP) #570: Fri Nov 20 21:00:30 MST 2020

Built 9439 packages

Number of packages built each day:
Nov 20: 173
Nov 21: 7335
Nov 22: 1467
Nov 23: 464


Critical path missing pkgs:
http://build-failures.rhaalovely.net/sparc64/2020-11-20/summary.log

Build failures: 14
http://build-failures.rhaalovely.net/sparc64/2020-11-20/devel/spidermonkey78.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/emulators/spike.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/games/odamex.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/geo/spatialite/gui.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/graphics/gimp/lensfun.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/graphics/mypaint.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/lang/mruby.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/productivity/gnucash.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/security/hydra,-gui.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/sysutils/libvirt.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/www/purritobin.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/x11/gnome/gucharmap.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/x11/grantlee-qt5.log
http://build-failures.rhaalovely.net/sparc64/2020-11-20/x11/roxterm.log

Recurrent failures:
 failures/devel/spidermonkey78.log
 failures/emulators/spike.log
 failures/games/odamex.log
 failures/geo/spatialite/gui.log
 failures/graphics/gimp/lensfun.log
 failures/graphics/mypaint.log
 failures/lang/mruby.log
 failures/productivity/gnucash.log
 failures/security/hydra,-gui.log
 failures/sysutils/libvirt.log
 failures/www/purritobin.log
 failures/x11/gnome/gucharmap.log
 failures/x11/grantlee-qt5.log
 failures/x11/roxterm.log

New failures:

Resolved failures:
-failures/audio/solfege.log
-failures/graphics/openimageio.log
-failures/security/sslscan.log
-failures/x11/picom.log

Packages newly built:
+audio/solfege
+devel/p5-Data-Section-Simple
+graphics/openimageio
+net/dog
+net/py-rrdtool
+security/sslscan
+sysutils/flashrom
+x11/picom

Packages not built this time:

py-pyx update to 0.15

[Daniel Dickman]

Hi Benoit,

py-pyx is now python3 only. Think nothing in the tree depends on py-pyx.

ok?


Index: Makefile
===
RCS file: /cvs/ports/graphics/py-pyx/Makefile,v
retrieving revision 1.22
diff -u -p -u -r1.22 Makefile
--- Makefile12 Jul 2019 20:47:09 -  1.22
+++ Makefile24 Nov 2020 02:54:31 -
@@ -2,11 +2,10 @@
 
 COMMENT =  package for creating PostScript/PDF graphics
 
-MODPY_EGG_VERSION = 0.12.1
+MODPY_EGG_VERSION = 0.15
 DISTNAME = PyX-${MODPY_EGG_VERSION}
 PKGNAME =  py-pyx-${MODPY_EGG_VERSION}
 CATEGORIES =   graphics devel
-REVISION = 4
 
 HOMEPAGE = http://pyx.sourceforge.net/
 
@@ -19,10 +18,14 @@ WANTLIB +=  ${MODPY_WANTLIB} pthread
 
 MODULES =  lang/python
 
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=pyx/}
+FLAVORS =  python3
+FLAVOR  =  python3
+
+MODPY_PI = Yes
+MODPY_SETUPTOOLS = Yes
 
 RUN_DEPENDS =  print/texlive/base \
-   graphics/py-Pillow
+   graphics/py-Pillow${MODPY_FLAVOR}
 
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/py-pyx
Index: distinfo
===
RCS file: /cvs/ports/graphics/py-pyx/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo21 Jan 2013 06:55:29 -  1.3
+++ distinfo24 Nov 2020 02:54:31 -
@@ -1,2 +1,2 @@
-SHA256 (PyX-0.12.1.tar.gz) = 6DeyaoscJ1JM8/PdbA1WNFEkkVntqi42bYfnFDqGfo4=
-SIZE (PyX-0.12.1.tar.gz) = 561989
+SHA256 (PyX-0.15.tar.gz) = D8OwDF5/tvSu+/Y7lfYkKX3eR3AKgri1rW67NGteSXc=
+SIZE (PyX-0.15.tar.gz) = 2559840
Index: patches/patch-examples_bitmap_pil_py
===
RCS file: patches/patch-examples_bitmap_pil_py
diff -N patches/patch-examples_bitmap_pil_py
--- patches/patch-examples_bitmap_pil_py6 Apr 2014 21:10:30 -   
1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,10 +0,0 @@
-$OpenBSD: patch-examples_bitmap_pil_py,v 1.1 2014/04/06 21:10:30 sthen Exp $
 examples/bitmap/pil.py.origSun Apr  6 19:53:10 2014
-+++ examples/bitmap/pil.py Sun Apr  6 19:53:14 2014
-@@ -1,5 +1,5 @@
- from pyx import *
--import Image
-+from PIL import Image
- 
- im = Image.new("RGB", (3, 1))
- im.putpixel((0, 0), (255, 0, 0))
Index: patches/patch-pyx_epsfile_py
===
RCS file: patches/patch-pyx_epsfile_py
diff -N patches/patch-pyx_epsfile_py
--- patches/patch-pyx_epsfile_py6 Apr 2014 21:10:30 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-pyx_epsfile_py,v 1.1 2014/04/06 21:10:30 sthen Exp $
 pyx/epsfile.py.origSun Apr  6 19:48:19 2014
-+++ pyx/epsfile.py Sun Apr  6 19:48:33 2014
-@@ -345,7 +345,7 @@ class epsfile(canvasitem.canvasitem):
- def processPDF(self, file, writer, context, registry, bbox):
- warnings.warn("EPS file is included as a bitmap created using pipeGS")
- from pyx import bitmap, canvas
--import Image
-+from PIL import Image
- c = canvas.canvas()
- c.insert(self)
- i = Image.open(c.pipeGS(device="pngalpha", resolution=600, 
seekable=True))
Index: patches/patch-pyx_mesh_py
===
RCS file: patches/patch-pyx_mesh_py
diff -N patches/patch-pyx_mesh_py
--- patches/patch-pyx_mesh_py   6 Apr 2014 21:10:30 -   1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-pyx_mesh_py,v 1.1 2014/04/06 21:10:30 sthen Exp $
 pyx/mesh.py.orig   Sun Apr  6 19:48:19 2014
-+++ pyx/mesh.pySun Apr  6 19:48:29 2014
-@@ -110,7 +110,7 @@ class mesh(canvasitem.canvasitem):
- def processPS(self, file, writer, context, registry, bbox):
- if writer.mesh_as_bitmap:
- from pyx import bitmap, canvas
--import Image
-+from PIL import Image
- c = canvas.canvas()
- c.insert(self)
- i = Image.open(c.pipeGS("pngalpha", 
resolution=writer.mesh_as_bitmap_resolution, seekable=True))
-@@ -140,7 +140,7 @@ class mesh(canvasitem.canvasitem):
- def processPDF(self, file, writer, context, registry, bbox):
- if writer.mesh_as_bitmap:
- from pyx import bitmap, canvas
--import Image
-+from PIL import Image
- c = canvas.canvas()
- c.insert(self)
- i = Image.open(c.pipeGS("pngalpha", 
resolution=writer.mesh_as_bitmap_resolution, seekable=True))
Index: patches/patch-setup_py
===
RCS file: patches/patch-setup_py
diff -N patches/patch-setup_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-setup_py  24 Nov 2020 02:54:31 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: setup.py
+--- setup.py.orig
 setup.py
+@@ -20,7 +20,7 @@ old 

rxvt-unicode with fixed font spacing & wide glyphs patch

[su.root]

Would it be possible in the future to have with fixed font spacing & wide 
glyphs patch? 

As a ref: 
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=rxvt-unicode-cvs-patched-wideglyphs

Thxs!

update for py-sphinx_rtd_theme to 0.4.3

[Daniel Dickman]

Here's an update of the "read the docs" aka rtd theme for sphinx. This is 
part of the set of diffs from Aisha Tammy to try to get py-sphinx updated.

While the update of the rtd port does not change the packing list for 
py-sphinx itself, it does change the packing lists for 3 consumers of 
py-sphinx:

devel/luacheck
devel/py-virtualenv
productivity/vdirsyncer

So the below diff makes py-sphinx depend on rtd theme >= 0.4.3 and bumps 
py-sphinx to 1.4.8p5.

The 3 consumers of py-sphinx above, now depend explicitly on 
py-sphinx>=1.4.8p5 and their packing lists are regenerated.

ok on the diff below or is there a better way to do this?


Index: textproc/py-sphinx_rtd_theme/Makefile
===
RCS file: /cvs/ports/textproc/py-sphinx_rtd_theme/Makefile,v
retrieving revision 1.7
diff -u -p -u -r1.7 Makefile
--- textproc/py-sphinx_rtd_theme/Makefile   3 Jul 2020 21:13:16 -   
1.7
+++ textproc/py-sphinx_rtd_theme/Makefile   24 Nov 2020 02:16:38 -
@@ -2,10 +2,9 @@
 
 COMMENT =  readthedocs.org theme for Sphinx
 
-MODPY_EGG_VERSION =0.2.4
+MODPY_EGG_VERSION =0.4.3
 DISTNAME = sphinx_rtd_theme-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
-REVISION = 2
 
 CATEGORIES =   textproc
 
Index: textproc/py-sphinx_rtd_theme/distinfo
===
RCS file: /cvs/ports/textproc/py-sphinx_rtd_theme/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- textproc/py-sphinx_rtd_theme/distinfo   22 Apr 2017 20:06:41 -  
1.2
+++ textproc/py-sphinx_rtd_theme/distinfo   24 Nov 2020 02:16:38 -
@@ -1,2 +1,2 @@
-SHA256 (sphinx_rtd_theme-0.2.4.tar.gz) = 
LfdLj/b65pZcUn6XzKbGyUSIaq5HS0kOF/kq376ENBc=
-SIZE (sphinx_rtd_theme-0.2.4.tar.gz) = 1392456
+SHA256 (sphinx_rtd_theme-0.4.3.tar.gz) = 
coYH401gRW1zbMeZH9I2r7goshuC+VbF6nX5TIQUBAo=
+SIZE (sphinx_rtd_theme-0.4.3.tar.gz) = 5391190
Index: textproc/py-sphinx_rtd_theme/pkg/PLIST
===
RCS file: /cvs/ports/textproc/py-sphinx_rtd_theme/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 PLIST
--- textproc/py-sphinx_rtd_theme/pkg/PLIST  20 Jan 2016 05:03:47 -  
1.1.1.1
+++ textproc/py-sphinx_rtd_theme/pkg/PLIST  24 Nov 2020 02:16:38 -
@@ -4,7 +4,9 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
 
lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
 
lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/entry_points.txt
 
lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
+lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
 
lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/__init__.py
 
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/${MODPY_PYCACHE}/
@@ -12,7 +14,6 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/breadcrumbs.html
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/footer.html
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/layout.html
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/layout_old.html
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/search.html
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/searchbox.html
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/
@@ -20,16 +21,37 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/css/badge_only.css
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/css/theme.css
 lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/Inconsolata-Bold.ttf
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/Inconsolata-Regular.ttf
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.ttf
-lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.ttf
+lib/python${MODPY_VERSION}/site-packages/sphinx_rtd_theme/static/fonts/Lato/

Re: Icinga2 endpoints unable to connect to master after update to current package 2.12.1-1

[Stuart Henderson]

Quick notes from offlist mails to save time for anyone else reading,
Ted was previously running 6.8-beta Fri Sep  4 22:46:14 MDT 2020,
before the new validator was enabled in libressl.

There was an icinga update in the window, but only a fairly minor
update, and a boost update though that is unlikely to interfere with
certs at all. I'm not running icinga clustering myself so wouldn't have
run into problems with it.

Ted please ignore the "switch to openssl" diff I sent you for now, try
this instead:

Index: patches/patch-lib_base_tlsutility_cpp
===
RCS file: patches/patch-lib_base_tlsutility_cpp
diff -N patches/patch-lib_base_tlsutility_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_base_tlsutility_cpp   24 Nov 2020 00:48:51 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Index: lib/base/tlsutility.cpp
+--- lib/base/tlsutility.cpp.orig
 lib/base/tlsutility.cpp
+@@ -812,6 +812,7 @@ bool VerifyCertificate(const std::shared_ptr& ca
+ 
+   X509_STORE_CTX *csc = X509_STORE_CTX_new();
+   X509_STORE_CTX_init(csc, store, certificate.get(), nullptr);
++  X509_STORE_CTX_set_flags(csc, X509_V_FLAG_LEGACY_VERIFY);
+ 
+   int rc = X509_verify_cert(csc);
+ 

I can let you have binary packages built with that tomorrow if
that's easier.


On 2020/11/23 17:13, Theodore Wynnychenko wrote:
> Hello
> 
> The other day I updated to current (6.8 GENERIC.MP#188).
> 
> I then updated packages.
> 
> I have been using Icinga2 since about OpenBSD 5.6, and everything was
> fine.
> 
> A few hours after the update, I got a warning that my /var/log filesystem
> on the icinga2 master was full.
> 
> Then, I noticed warnings in icinga2 for pretty much every check that
> state:
> 
>   "Error: Function call 'pipe2' failed with error code 24, 'Too many
> open files'"
> 
> I only have a couple of dozen endpoints, and have never had this issue
> before.  I tried increasing the file limits, but that only increased the
> time before icinga2 crashed into the limit with too many open files.
> 
> I then noticed that icinga2 was now throwing a warning about self signed
> certificates.
> 
> Specifically, I was getting log messages on the endpoints "New client
> connection for identity 'master.my.tld' to [172.xx.xx.99]:5665
> (certificate validation failed: code 19: self signed certificate in
> certificate chain)".
> 
> On the master, I was getting the same, but inverted, error:  "New client
> connection for identity 'endpoint.my.tld' from [172.xx.xx.1]:3621
> (certificate validation failed: code 19: self signed certificate in
> certificate chain)".
> 
> So, I decided to add the icinga CA certificate to the list of trusted
> certificates in /etc/ssl/cert.pem on both master and endpoint.
> 
> Now, when I connect (either from master to endpoint, or the reverse) using
> s_client, I see:
> 
> openssl s_client -connect endpoint.my.tld:5665
> 
> CONNECTED(0003)
> depth=1 CN = Icinga CA
> verify return:1
> depth=1 CN = Icinga CA
> verify error:num=19:self signed certificate in certificate chain
> verify return:0
> depth=1 CN = Icinga CA
> verify return:1
> depth=0 CN = endpoint.my.tld
> verify return:1
> depth=0 CN = endpoint.my.tld
> verify return:1
> write W BLOCK
> ---
> Certificate chain
>  0 s:/CN=endpoint.my.tld
>i:/CN=Icinga CA
>  1 s:/CN=Icinga CA
>i:/CN=Icinga CA
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIFAjCCAuqgAwIBAgIUZuaLfnjnY6dLkKTQ3J6GGGcCYnowDQYJKoZIhvcNAQEL
> BQAwFDESMBAGA1UEAwwJSWNpbmdhIENBMB4XDTE4MDUxNjE2MzQzN1oXDTMzMDUx
> MjE2MzQzN1owJzElMCMGA1UEAwwccGlwcGluLnNhbWJhLnd5bm55Y2hlbmtvLmNv
> bTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJzPMaQdWkhb/YMy242C
> jmbRVcwOqZrCRPwscYhAfhfSwNJfSN7k5I9UCFszgvAU3QU3RhEElrJYOQY7UKp1
> V7D4MO88S5NMh6rLrjyCuojxVnbwCA4WwIXMA0zNY6EEG8/1LbcfA8utSy1Y1X0c
> xb4FJKv3ar02j9A5XleZf0p9bKQezysxB3TT17L4AhWsoE1w/7GCfU715OEch+Dw
> WI9TusrJXKLFwHvk1j+ZCjiNM49F7gFDpw3m/Asekt5B3M6L7ZkPM9jI1ThX4etj
> kEC1C2371lP9OdFExqScLudHCL8+2IILd3i+/7YxWFTnxhFszyWMDiMll/omcpot
> qDbFhQdVrfnTo4lczK42EfhQuDMdESkmvay8UVGyUe90AEaQ38V3w8B0iDzgGQTX
> UZNxpurotW2zU1XPhzTOawRlp1POFQ1tnFJzH+iyBCxZZZfZsQchJbMJz/JCGIiW
> qkhTN5bAKoAgO6GglTmqktSZmixa38fZ8qIJ8Y0UZsnH5zRQWcbzKr49u3FhH2rH
> pC9Dh+zlRj/LiMM4c/UF2LzwuIQ3fjZMEff+q3vzs6cXgs8FICX7uvpB4yqqt4Vn
> /ZSRrq++dUAav+0JhTYlW2m+sa/ga4HVAB+zNN7+l92PWSJ0b3DDzZt6CHLp/lWX
> zCPDpo7ABbk+xrg+NEoym8ejAgMBAAGjOTA3MAwGA1UdEwEB/wQCMAAwJwYDVR0R
> BCAwHoIccGlwcGluLnNhbWJhLnd5bm55Y2hlbmtvLmNvbTANBgkqhkiG9w0BAQsF
> AAOCAgEAGh1goJVNy4Ltpv0+x1okod55g7ob6/l2hAwrq0jXBca4zIGncQcdl0jg
> +z6TDMiq+2UUoKB80k5D947t2VHtp+d/wuSTNwpzESNplh5GWpqkdpOHcAN1lkku
> ZgCUnQH/ZFa4Q2V01rPHSaf1znMpaqaYTjAKwNwZY9qRxjXUZg62/D/y9pfmy+VC
> yvZype5rETXjLxr0WN6LABRgda41wiLszMWLAonHRHRVkhdyUYC+brmDNhfByqGJ
> L5oHpvCq9Oywk4zKO02y3wrhL1+JHt0TH/5RmaalWQRsB0vJY9699cnLk6DK/+CD
> YyHecKplsnwnfvwau6aMlwg6zilCZ+YMl3Jwj0vQeG/h8DyTw6t9HtknlnRfcfQ/
> eyTHZtdyH1y1O5v4BQJNt5Ewc7y144IP2g/9Y7g3n7GFlvd68TQjJmI6I4nGsJ+u
> 

Icinga2 endpoints unable to connect to master after update to current package 2.12.1-1

[Theodore Wynnychenko]

Hello

The other day I updated to current (6.8 GENERIC.MP#188).

I then updated packages.

I have been using Icinga2 since about OpenBSD 5.6, and everything was
fine.

A few hours after the update, I got a warning that my /var/log filesystem
on the icinga2 master was full.

Then, I noticed warnings in icinga2 for pretty much every check that
state:

"Error: Function call 'pipe2' failed with error code 24, 'Too many
open files'"

I only have a couple of dozen endpoints, and have never had this issue
before.  I tried increasing the file limits, but that only increased the
time before icinga2 crashed into the limit with too many open files.

I then noticed that icinga2 was now throwing a warning about self signed
certificates.

Specifically, I was getting log messages on the endpoints "New client
connection for identity 'master.my.tld' to [172.xx.xx.99]:5665
(certificate validation failed: code 19: self signed certificate in
certificate chain)".

On the master, I was getting the same, but inverted, error:  "New client
connection for identity 'endpoint.my.tld' from [172.xx.xx.1]:3621
(certificate validation failed: code 19: self signed certificate in
certificate chain)".

So, I decided to add the icinga CA certificate to the list of trusted
certificates in /etc/ssl/cert.pem on both master and endpoint.

Now, when I connect (either from master to endpoint, or the reverse) using
s_client, I see:

openssl s_client -connect endpoint.my.tld:5665

CONNECTED(0003)
depth=1 CN = Icinga CA
verify return:1
depth=1 CN = Icinga CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
depth=1 CN = Icinga CA
verify return:1
depth=0 CN = endpoint.my.tld
verify return:1
depth=0 CN = endpoint.my.tld
verify return:1
write W BLOCK
---
Certificate chain
 0 s:/CN=endpoint.my.tld
   i:/CN=Icinga CA
 1 s:/CN=Icinga CA
   i:/CN=Icinga CA
---
Server certificate
-BEGIN CERTIFICATE-
MIIFAjCCAuqgAwIBAgIUZuaLfnjnY6dLkKTQ3J6GGGcCYnowDQYJKoZIhvcNAQEL
BQAwFDESMBAGA1UEAwwJSWNpbmdhIENBMB4XDTE4MDUxNjE2MzQzN1oXDTMzMDUx
MjE2MzQzN1owJzElMCMGA1UEAwwccGlwcGluLnNhbWJhLnd5bm55Y2hlbmtvLmNv
bTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJzPMaQdWkhb/YMy242C
jmbRVcwOqZrCRPwscYhAfhfSwNJfSN7k5I9UCFszgvAU3QU3RhEElrJYOQY7UKp1
V7D4MO88S5NMh6rLrjyCuojxVnbwCA4WwIXMA0zNY6EEG8/1LbcfA8utSy1Y1X0c
xb4FJKv3ar02j9A5XleZf0p9bKQezysxB3TT17L4AhWsoE1w/7GCfU715OEch+Dw
WI9TusrJXKLFwHvk1j+ZCjiNM49F7gFDpw3m/Asekt5B3M6L7ZkPM9jI1ThX4etj
kEC1C2371lP9OdFExqScLudHCL8+2IILd3i+/7YxWFTnxhFszyWMDiMll/omcpot
qDbFhQdVrfnTo4lczK42EfhQuDMdESkmvay8UVGyUe90AEaQ38V3w8B0iDzgGQTX
UZNxpurotW2zU1XPhzTOawRlp1POFQ1tnFJzH+iyBCxZZZfZsQchJbMJz/JCGIiW
qkhTN5bAKoAgO6GglTmqktSZmixa38fZ8qIJ8Y0UZsnH5zRQWcbzKr49u3FhH2rH
pC9Dh+zlRj/LiMM4c/UF2LzwuIQ3fjZMEff+q3vzs6cXgs8FICX7uvpB4yqqt4Vn
/ZSRrq++dUAav+0JhTYlW2m+sa/ga4HVAB+zNN7+l92PWSJ0b3DDzZt6CHLp/lWX
zCPDpo7ABbk+xrg+NEoym8ejAgMBAAGjOTA3MAwGA1UdEwEB/wQCMAAwJwYDVR0R
BCAwHoIccGlwcGluLnNhbWJhLnd5bm55Y2hlbmtvLmNvbTANBgkqhkiG9w0BAQsF
AAOCAgEAGh1goJVNy4Ltpv0+x1okod55g7ob6/l2hAwrq0jXBca4zIGncQcdl0jg
+z6TDMiq+2UUoKB80k5D947t2VHtp+d/wuSTNwpzESNplh5GWpqkdpOHcAN1lkku
ZgCUnQH/ZFa4Q2V01rPHSaf1znMpaqaYTjAKwNwZY9qRxjXUZg62/D/y9pfmy+VC
yvZype5rETXjLxr0WN6LABRgda41wiLszMWLAonHRHRVkhdyUYC+brmDNhfByqGJ
L5oHpvCq9Oywk4zKO02y3wrhL1+JHt0TH/5RmaalWQRsB0vJY9699cnLk6DK/+CD
YyHecKplsnwnfvwau6aMlwg6zilCZ+YMl3Jwj0vQeG/h8DyTw6t9HtknlnRfcfQ/
eyTHZtdyH1y1O5v4BQJNt5Ewc7y144IP2g/9Y7g3n7GFlvd68TQjJmI6I4nGsJ+u
iNu+DGzD6Ih9UhFCWMrR57r9utdarBWYV4NJaXldNnqXrL099Hu3CLzdjikabeHE
J56gkXOHQdQi2xIyIgIuMHMF+niJkqAmxyGaMfnBOOv6Gvt7TAMLrt4dIFSgomKe
Rd6xSyCh66H/AYF8b4NlwVCjDmvQf31OtGrl8xVlXDnOeaUHoZsu/ECO9f7E5yuN
od5dNX4mJoSCkESbwQ67IumOLxSEw5extwTNplG/oEqgl6YalJI=
-END CERTIFICATE-
subject=/CN=endpoint.my.tld
issuer=/CN=Icinga CA
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3436 bytes and written 392 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
AF10B5FA058B109699E87151A6BFCE6E9AD4968C04F6E8C1EFE24C8830AE7D5F
Session-ID-ctx:
Master-Key:
6509DF9A604E5FB4C7F3BD55DC4666FDD93315CA00AA8E373E8C41BD93E3E1D91961AEA356
42A684F45DA530C4FDF260
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - b1 ef 85 f6 29 57 ee 81-8f d7 af 12 de 8e 19 1e
)W..
0010 - c4 3d b8 5d 68 1e d0 87-9a 88 09 b8 e5 b8 fd 7d
.=.]h..}
0020 - 6e 48 ea 63 5f df 83 54-9a d3 b4 3e e6 3a 30 a4
nH.c_..T...>.:0.
0030 - 83 0b df 4d 3e 7b da a2-47 a0 c2 2b 2c 4e 4e f6
...M>{..G..+,NN.
0040 - f3 b5 6c 24 da 6a f1 c8-bf 27 08 23 1e 37 21 9a
..l$.j...'.#.7!.
0050 - 93 dd 87 a5 95 b8 72 3c-14 07 33 a1 e4 23 b7 2d
..r<..3..#.-
0060 - 16 0e b8 ad c4 f9 be 72-a0 44 1f 09 c9 47 47 8a
...r.D...GG.
0070 - a6 97 10 55 77 

Re: [sparc64] Fix build of x11/picom

[Stuart Henderson]

On 2020/11/23 17:04, Kurt Mosiejczuk wrote:
> I was a bit bewildered for a while as to why picom would error out with
> "couldn't find uthash.h" when uthash was a build dependency. I finally
> looked at the log and the test program was specifying "-std=c++11" which
> base-gcc errored out on.
> 
> So specify ports-gcc in COMPILER fixes the build.

it's C11 not C++11 - probably wants COMPILER_LANGS=c too to avoid the
extra dep?

Re: [PATCH 01/11] [update] sphinx_rtd_theme to 0.4.3

[Daniel Dickman]

> On Sep 7, 2020, at 8:44 PM, Aisha Tammy  wrote:
> 
> From: Aisha Tammy 
> 
> Signed-off-by: Aisha Tammy 
> ---
> textproc/py-sphinx_rtd_theme/Makefile  |  5 ++--
> textproc/py-sphinx_rtd_theme/distinfo  |  4 +--
> textproc/py-sphinx_rtd_theme/pkg/PLIST | 36 +-
> 3 files changed, 33 insertions(+), 12 deletions(-)


This one breaks 3 ports because those ports needs PLISTs to be regenerated. I 
will send out a new diff to ports shortly to account for this.

devel/luacheck
devel/py-virtualenv 
productivity/vdirsyncer

Thanks.

Re: [PATCH 03/11] [update] py-snowballstemmer to 2.0.0

[Daniel Dickman]

> On Sep 7, 2020, at 8:44 PM, Aisha Tammy  wrote:
> 
> From: Aisha Tammy 
> 
> Signed-off-by: Aisha Tammy 
> ---
> textproc/py-snowballstemmer/Makefile  |  5 +++--
> textproc/py-snowballstemmer/distinfo  |  4 ++--
> textproc/py-snowballstemmer/pkg/PLIST | 26 +-
> 3 files changed, 30 insertions(+), 5 deletions(-)


I will commit this one soon. It looks good to me. Thanks.

[sparc64] Fix build of x11/picom

[Kurt Mosiejczuk]

I was a bit bewildered for a while as to why picom would error out with
"couldn't find uthash.h" when uthash was a build dependency. I finally
looked at the log and the test program was specifying "-std=c++11" which
base-gcc errored out on.

So specify ports-gcc in COMPILER fixes the build.

ok?

--Kurt

Index: Makefile
===
RCS file: /cvs/ports/x11/picom/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile6 Nov 2020 19:40:34 -   1.3
+++ Makefile23 Nov 2020 21:49:45 -
@@ -18,6 +18,9 @@
 
 MODULES =  devel/meson
 
+# C++11
+COMPILER = base-clang ports-gcc
+
 BUILD_DEPENDS =devel/uthash \
textproc/asciidoc
 

split graphics/py-Pillow

[Stuart Henderson]

Like what was done for py2-cairo, to unblock py-Pillow updates I would
like to re-import a copy of py-Pillow with the following changes to
ports/graphics/py2-Pillow (tgz attached).

OK?

 DISTNAME=  Pillow-${MODPY_EGG_VERSION}
 PKGNAME=   py-${DISTNAME}
 CATEGORIES=graphics
-REVISION=  0
+REVISION=  1
...
-
-FLAVORS=   python3
-FLAVOR?=

 @comment $OpenBSD: PLIST,v 1.12 2020/01/03 14:42:18 sthen Exp $
 @conflict py-Imaging-*
-@pkgpath graphics/py-Pillow,-main${MODPY_FLAVOR}
+@pkgpath graphics/py-Pillow,-main
+@pkgpath graphics/py-Pillow
 @pkgpath 
graphics/py-Imaging,-bin[,python2.4][,python2.5][,python2.6][,python2.7]
 @pkgpath 
graphics/py-Imaging,-docs[,python2.4][,python2.5][,python2.6][,python2.7]
 @pkgpath 
graphics/py-Imaging,-examples[,python2.4][,python2.5][,python2.6][,python2.7]

...

I will then turn graphics/py-Pillow into a py3-only port, diff for that
below, and switch dependent py2 ports over to using it.


Index: graphics/Makefile
===
RCS file: /cvs/ports/graphics/Makefile,v
retrieving revision 1.530
diff -u -p -r1.530 Makefile
--- graphics/Makefile   14 Nov 2020 11:06:54 -  1.530
+++ graphics/Makefile   23 Nov 2020 21:23:39 -
@@ -237,7 +237,7 @@
  SUBDIR += pqiv
  SUBDIR += pstoedit
  SUBDIR += py-blurhash
- SUBDIR += py-Pillow
+ SUBDIR += py2-Pillow
  SUBDIR += py-Pillow,python3
  SUBDIR += py-cairo,python3
  SUBDIR += py-cycler
Index: graphics/py-Pillow/Makefile
===
RCS file: /cvs/ports/graphics/py-Pillow/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- graphics/py-Pillow/Makefile 3 Jul 2020 21:12:55 -   1.32
+++ graphics/py-Pillow/Makefile 23 Nov 2020 21:24:12 -
@@ -6,7 +6,7 @@ MODPY_EGG_VERSION=  6.2.2
 DISTNAME=  Pillow-${MODPY_EGG_VERSION}
 PKGNAME=   py-${DISTNAME}
 CATEGORIES=graphics
-REVISION=  0
+REVISION=  1
 
 HOMEPAGE=  https://python-pillow.org/
 
@@ -15,7 +15,7 @@ HOMEPAGE= https://python-pillow.org/
 PERMIT_PACKAGE=Yes
 
 FLAVORS=   python3
-FLAVOR?=
+FLAVOR=python3
 
 MODPY_PI = Yes
 
Index: graphics/py-Pillow/pkg/PLIST
===
RCS file: /cvs/ports/graphics/py-Pillow/pkg/PLIST,v
retrieving revision 1.12
diff -u -p -r1.12 PLIST
--- graphics/py-Pillow/pkg/PLIST3 Jan 2020 14:42:18 -   1.12
+++ graphics/py-Pillow/pkg/PLIST23 Nov 2020 21:24:12 -
@@ -1,10 +1,5 @@
 @comment $OpenBSD: PLIST,v 1.12 2020/01/03 14:42:18 sthen Exp $
-@conflict py-Imaging-*
 @pkgpath graphics/py-Pillow,-main${MODPY_FLAVOR}
-@pkgpath 
graphics/py-Imaging,-bin[,python2.4][,python2.5][,python2.6][,python2.7]
-@pkgpath 
graphics/py-Imaging,-docs[,python2.4][,python2.5][,python2.6][,python2.7]
-@pkgpath 
graphics/py-Imaging,-examples[,python2.4][,python2.5][,python2.6][,python2.7]
-@pkgpath 
graphics/py-Imaging,-main[,python2.4][,python2.5][,python2.6][,python2.7]
 ${INCL_DIR}/ImPlatform.h
 ${INCL_DIR}/Imaging.h
 lib/python${MODPY_VERSION}/site-packages/PIL/



py2-Pillow.tgz
Description: application/tar-gz

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 13:51:42

Modified files:
www/c-icap/c-icap: Makefile distinfo 

Log message:
update to c-icap-0.5.7

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 11:35:03

Modified files:
devel/cmake: cmake.port.mk 

Log message:
MODCMAKE_PORT_BUILD=yes must be set in CONFIGURE_ENV.
Keeping it in MAKE_ENV as well in case something runs a second copy
of cmake during the build.

Re: aarch64 bulk build report

[Dimitri Karamazov]

On Mon, November 23, 2020 12:43, Stuart Henderson wrote:
> On 2020/11/23 09:13, Dimitri Karamazov wrote:
>
>> Forgot to add REVISION bump.
>> The below changes are necessary, unless JAVA_HOME is manually appended to 
>> PATH
>> while building, not a thing to leave up to chance.
>
> This script is not called in the build.
>
>
>
??

/usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh[12]: jar: not found
Native code built into jbigi.jar

The above error is caused even on amd64, so I fix the jar location
by making changes to ${WRKSRC}/core/c/build.sh which is called here.

post-build:
 cd ${WRKSRC}/core/c && CC=${CC} BITS=${BITS} \
${WRKSRC}/core/c/build.sh

I didn't catch it earlier since JAVA_HOME was appended to PATH.
I set MAKE_ENV employ it above, which is required to pass JAVA_HOME and CFLAGS.

Could you elucidate on why the changes aren't necessary?

I've added a mirror to MASTER_SITES.

Index: Makefile
===
RCS file: /cvs/ports/net/i2p/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile5 Nov 2020 19:54:50 -   1.3
+++ Makefile23 Nov 2020 13:39:56 -
@@ -6,7 +6,7 @@ V=  0.9.47
 DISTNAME=  i2psource_${V}
 EXTRACT_SUFX=  .tar.bz2
 PKGNAME=   i2p-${V}
-REVISION=  0
+REVISION=  1

 CATEGORIES=net

@@ -20,7 +20,8 @@ PERMIT_PACKAGE=   Yes

 WANTLIB += gmp

-MASTER_SITES=  https://download.i2p2.de/releases/$V/
+MASTER_SITES=  https://download.i2p2.de/releases/$V/ \
+   https://launchpad.net/i2p/trunk/$V/+download/

 MODULES=   java
 MODJAVA_VER=   1.8
@@ -43,6 +44,8 @@ DB_DIR=   ${LOCALSTATEDIR}/i2p

 SUBST_VARS=DB_DIR JAVA_HOME

+MAKE_ENV=  CC=${CC} BITS=${BITS}
+
 WRKDIST=   ${WRKDIR}/${PKGNAME}

 # test requires addition dependencies (atleast: junit, hamcrest, jmockfit)
@@ -54,8 +57,7 @@ post-patch:
${SUBST_CMD} ${WRKSRC}/installer/resources/eepget

 post-build:
-   cd ${WRKSRC}/core/c && CC=${CC} BITS=${BITS} \
-   ${WRKSRC}/core/c/build.sh
+   cd ${WRKSRC}/core/c && ${MAKE_ENV} ${WRKSRC}/core/c/build.sh

 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/i2p
Index: patches/patch-core_c_build_sh
===
RCS file: patches/patch-core_c_build_sh
diff -N patches/patch-core_c_build_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-core_c_build_sh   23 Nov 2020 13:39:56 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+fix jar location
+
+--- core/c/build.sh.orig   Mon Nov 23 09:30:07 2020
 core/c/build.shMon Nov 23 09:30:50 2020
+@@ -9,6 +9,6 @@ cp jcpuid/lib/freenet/support/CPUInformation/*jcpuid*
+ mkdir -p t/net/i2p/util/
+ cp jbigi/lib/*jbigi* t/
+
+-(cd t ; jar cf ../jbigi.jar . ; cd ..)
++(cd t ; ${JAVA_HOME}/bin/jar cf ../jbigi.jar . ; cd ..)
+
+ echo "Native code built into jbigi.jar"


regards,
  Dimitri

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 11:05:49

Modified files:
www/py-autobahn: Makefile 

Log message:
bump revision, pointed out by daniel@

CVS: cvs.openbsd.org: ports

[Edd Barrett]

CVSROOT:/cvs
Module name:ports
Changes by: e...@cvs.openbsd.org2020/11/23 08:16:44

Modified files:
textproc/mdbook: Makefile distinfo 

Log message:
Update textproc/mdbook to version 0.4.4.

CVS: cvs.openbsd.org: ports

[Benoit Lecocq]

CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/11/23 07:54:36

Modified files:
mail/p5-MIME-Lite: Makefile distinfo 

Log message:
Update to p5-MIME-Lite-3.031.

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 07:48:21

Modified files:
devel/py-txaio : Makefile 

Log message:
bump REVISION

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 07:40:27

Modified files:
net/i2p: Makefile 
Added files:
net/i2p/patches: patch-core_c_build_sh 

Log message:
i2p: fix post-build, add a download mirror (original has cert problems)

Re: aarch64 bulk build report

[Stuart Henderson]

On 2020/11/23 14:05, Dimitri Karamazov wrote:
> On Mon, November 23, 2020 12:43, Stuart Henderson wrote:
> > On 2020/11/23 09:13, Dimitri Karamazov wrote:
> >
> >> Forgot to add REVISION bump.
> >> The below changes are necessary, unless JAVA_HOME is manually appended to 
> >> PATH
> >> while building, not a thing to leave up to chance.
> >
> > This script is not called in the build.
> >
> >
> >
> ??
> 
> /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh[12]: jar: not found
> Native code built into jbigi.jar

sigh, I was looking on i386 and of course it isn't built there because
tanukiwrapper fails, so I looked in i2pd.log rather than i2p.log by mistake.

> The above error is caused even on amd64, so I fix the jar location
> by making changes to ${WRKSRC}/core/c/build.sh which is called here.
> 
> post-build:
>cd ${WRKSRC}/core/c && CC=${CC} BITS=${BITS} \
>   ${WRKSRC}/core/c/build.sh
> 
> I didn't catch it earlier since JAVA_HOME was appended to PATH.

also because the script is stupid and does no error checking...
Thanks, committed and I changed it to use #!/bin/sh -e.

CVS: cvs.openbsd.org: ports

[Kurt Mosiejczuk]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/11/23 07:32:51

Modified files:
math/matio : Makefile 

Log message:
Fix build for matio on sparc64 by making it use ports-gcc rather
than base-gcc

(Fails with "error: stray '\357' in program")

ok benoit

Re: cyrus-imapd upstreamed patches and improvements

[Anatoli]

Stuart,

Thanks a lot for the explanation! Much appreciated!

cyrus-imapd project is mostly modular (e.g. if it's built with --enable-http,
there would be additional binary httpd), but there are also some elements that
hold the compilation information, like cyr_buildinfo [1] which returns the
details about the components, dependencies, etc. that were activated or not
during the build:

$ cyr_buildinfo
{
  "component": {
"event_notification": false,
"gssapi": false,
"autocreate": true,
"idled": true,
"httpd": true,
"kerberos_v4": false,
"murder": false,
"nntpd": false,
"replication": false,
"sieve": true,
"calalarmd": false,
"objectstore": false,
"backup": false
  },
  "dependency": {
"ldap": false,
"openssl": true,
"pcre": true,
"clamav": false
  },
  "database": {
"mysql": false,
"pgsql": false,
"sqlite": true,
"lmdb": false
  },
  "search": {
"squat": false,
"sphinx": false,
"xapian": false,
"xapian_flavor": "none"
  },
  "hardware": {
"sse42": true
  }
}

I've asked [2] the devs about the extent of the modificaions that the same files
experience with different options. They are all affected by config.h include
holding the configuration options.

There's also a libcyrus library that has all the API definitions for the
requested functionality that builds conditionally. Part of the reply from a dev
from [2]:

> If you've built it with everything included, then there is no particular
> advantage to packaging up subsets of that.  You might think "we can avoid
> bloat by excluding the features we don't need", but in this case all the APIs
> to support those features would still be in libcyrus, you would just be
> missing binaries.  You could have achieved the same effect by just not running
> those services in cyrus.conf

I guess it would be more appropriate to proceed with flavors.

I was thinking about actually defining a number of flavors (basically for most
components and dependencies as returned by cyr_buildinfo), but to build only 4
combinations as part of the build infrastructure (the most clear use-cases), so
the rest of possible combinations could be activated by the users in the ports.

Does that sound good?

And if I understood it correctly, I'd have to use PFRAGs and %%flavor%% in PLIST
to define the build differences for each flavor, right?

Regards,
Anatoli

[1] 
https://www.cyrusimap.org/imap/reference/manpages/systemcommands/cyr_buildinfo.html
[2] 
https://cyrus.topicbox.com/groups/devel/T5acbcb9536dc47c3/cyrus-imapd-packaging-flavors-variations


On 22/11/20 10:53, Stuart Henderson wrote:
> On 2020/11/22 00:27, Anatoli wrote:
>> Then, I'm working now on the flavored version of the port, and my idea is to
>> apply it as soon as the new minor version is published (or maybe even before
>> this so not to deal with the REVISION) but this is my first time working with
>> ports, so I have no experience with the process and I have a couple of 
>> questions
>> about some aspects of flavors definition.
> 
> Is the build "modular"? That is, do the build options just have it build
> additional features in separate files (.so modules etc), or do they change
> the main binaries too?
> 
> For builds which are modular, generally we do a single build and split
> the various files into subpackages. See for example PHP, Asterisk,
> Dovecot. MULTI_PACKAGES is defined with a list of subpackage names,
> the port is built once, packages are created for each subpackage
> using the relevant "PLIST-sub" file.
> 
> (Heading off something you will see in some of these ports - there are
> "no_*" pseudo-flavours in some of these which are an optimization to
> reduce build dependencies for people building themselves rather than
> using packages - ignore these initially, they would be something to add
> later, if at all).
> 
>> 1: vim-8.2.1805p0-gtk2
>> 2: vim-8.2.1805p0-gtk2-lua
>> 3: vim-8.2.1805p0-gtk2-perl-python-ruby
>> 4: vim-8.2.1805p0-gtk2-perl-python3-ruby
>> 5: vim-8.2.1805p0-gtk3
>> 6: vim-8.2.1805p0-gtk3-lua
>> 7: vim-8.2.1805p0-gtk3-perl-python-ruby
>> 8: vim-8.2.1805p0-gtk3-perl-python3-ruby
>> 9: vim-8.2.1805p0-no_x11-lua
>> 10: vim-8.2.1805p0-no_x11
>> 11: vim-8.2.1805p0-no_x11-perl-python-ruby
>> 12: vim-8.2.1805p0-no_x11-perl-python3-ruby
>> 13: vim-8.2.1805p0-no_x11-python
>> 14: vim-8.2.1805p0-no_x11-python3
>> 15: vim-8.2.1805p0-no_x11-ruby
> 
> Solène explained how this list is defined. vim (and some other things
> like mutt) are just "either/or", so there's no alternative to building
> it multiple times. But it's better to avoid building what is essentially
> the same port 15 times if possible :)
> 
>> Then I have some other questions like what does 'M'(option1) and 'L' mean in
>> places like: .if ${FLAVOR:Moption1} or .if ${FLAVOR:L:Mcrypto}? I've seen 
>> other
>> letters (F) being used in a similar way, but haven't seen anything in the 

Re: aarch64 bulk build report

[Dimitri Karamazov]

On Mon, November 23, 2020 08:05, Stuart Henderson wrote:
> On 2020/11/23 05:14, Dimitri Karamazov wrote:
>
 /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh
 Building openbsd .sos
 Please ensure you have a Java SDK installed
 and/or set JAVA_HOME then re-run this script. ERROR: Cannot find jni.h! 
 Looked in "/include/jni.h" Please set
 JAVA_HOME to a java home that has the JNI

>> The error until this part is probably because of jdk11 being set as builddep,
>> even though it requires jdk1.8 as is defined in the Makefile
>
> Yes this is strange because the port shouldn't build on aarch64 at all
> (set by java.port.mk).
>
>
> $ cd /usr/ports/net/i2p; make show=ONLY_FOR_ARCHS
> i386 amd64
>
 http://build-failures.rhaalovely.net/aarch64/2020-11-20/java/tanukiwrapper.log

>
> same here
>
>
Don't know the reason for above, maybe one should check if the rest
of the ports with MODJAVA_VER=1.8 are compatible with version 11.
That could be the reason they didn't give out any errors.

Forgot to add REVISION bump.
The below changes are necessary, unless JAVA_HOME is manually appended to PATH
while building, not a thing to leave up to chance.

Index: Makefile
===
RCS file: /cvs/ports/net/i2p/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile5 Nov 2020 19:54:50 -   1.3
+++ Makefile23 Nov 2020 09:00:04 -
@@ -6,7 +6,7 @@ V=  0.9.47
 DISTNAME=  i2psource_${V}
 EXTRACT_SUFX=  .tar.bz2
 PKGNAME=   i2p-${V}
-REVISION=  0
+REVISION=  1

 CATEGORIES=net

@@ -43,6 +43,8 @@ DB_DIR=   ${LOCALSTATEDIR}/i2p

 SUBST_VARS=DB_DIR JAVA_HOME

+MAKE_ENV=  CC=${CC} BITS=${BITS}
+
 WRKDIST=   ${WRKDIR}/${PKGNAME}

 # test requires addition dependencies (atleast: junit, hamcrest, jmockfit)
@@ -54,8 +56,7 @@ post-patch:
${SUBST_CMD} ${WRKSRC}/installer/resources/eepget

 post-build:
-   cd ${WRKSRC}/core/c && CC=${CC} BITS=${BITS} \
-   ${WRKSRC}/core/c/build.sh
+   cd ${WRKSRC}/core/c && ${MAKE_ENV} ${WRKSRC}/core/c/build.sh

 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/i2p
Index: patches/patch-core_c_build_sh
===
RCS file: patches/patch-core_c_build_sh
diff -N patches/patch-core_c_build_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-core_c_build_sh   23 Nov 2020 09:00:04 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+fix jar location
+
+--- core/c/build.sh.orig   Mon Nov 23 09:30:07 2020
 core/c/build.shMon Nov 23 09:30:50 2020
+@@ -9,6 +9,6 @@ cp jcpuid/lib/freenet/support/CPUInformation/*jcpuid*
+ mkdir -p t/net/i2p/util/
+ cp jbigi/lib/*jbigi* t/
+
+-(cd t ; jar cf ../jbigi.jar . ; cd ..)
++(cd t ; ${JAVA_HOME}/bin/jar cf ../jbigi.jar . ; cd ..)
+
+ echo "Native code built into jbigi.jar"

regards,
  Dimitri

Re: aarch64 bulk build report

[Stuart Henderson]

On 2020/11/23 12:43, Stuart Henderson wrote:
> On 2020/11/23 09:13, Dimitri Karamazov wrote:
> > On Mon, November 23, 2020 08:05, Stuart Henderson wrote:
> > > On 2020/11/23 05:14, Dimitri Karamazov wrote:
> > >
> >  /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh
> >  Building openbsd .sos
> >  Please ensure you have a Java SDK installed
> >  and/or set JAVA_HOME then re-run this script. ERROR: Cannot find 
> >  jni.h! Looked in "/include/jni.h" Please set
> >  JAVA_HOME to a java home that has the JNI
> > 
> > >> The error until this part is probably because of jdk11 being set as 
> > >> builddep,
> > >> even though it requires jdk1.8 as is defined in the Makefile
> > >
> > > Yes this is strange because the port shouldn't build on aarch64 at all
> > > (set by java.port.mk).
> > >
> > >
> > > $ cd /usr/ports/net/i2p; make show=ONLY_FOR_ARCHS
> > > i386 amd64
> > >
> >  http://build-failures.rhaalovely.net/aarch64/2020-11-20/java/tanukiwrapper.log
> > 
> > >
> > > same here
> > >
> > >
> > Don't know the reason for above, maybe one should check if the rest
> > of the ports with MODJAVA_VER=1.8 are compatible with version 11.
> > That could be the reason they didn't give out any errors.
> 
> it's because the port pulls in bsd.port.arch.mk itself, which has side 
> effects.
> 
> I have updated these two ports to manually set ONLY_FOR_ARCHS because
> the setting coming from java.port.mk is ignored.
> 
> > Forgot to add REVISION bump.
> > The below changes are necessary, unless JAVA_HOME is manually appended to 
> > PATH
> > while building, not a thing to leave up to chance.
> 
> This script is not called in the build.
> 

btw:

>> Fetch https://download.i2p2.de/releases/0.9.47/i2psource_0.9.47.tar.bz2
TLS handshake failure: certificate verification failed: certificate has expired

...

Subject:  download.i2p2.de
Altnames: DNS:download.i2p2.de
Issuer:   Let's Encrypt Authority X3

Not valid before: Aug  9 13:02:16 2020 GMT
Not valid after:  Nov  7 13:02:16 2020 GMT

Re: aarch64 bulk build report

[Stuart Henderson]

On 2020/11/23 09:13, Dimitri Karamazov wrote:
> On Mon, November 23, 2020 08:05, Stuart Henderson wrote:
> > On 2020/11/23 05:14, Dimitri Karamazov wrote:
> >
>  /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh
>  Building openbsd .sos
>  Please ensure you have a Java SDK installed
>  and/or set JAVA_HOME then re-run this script. ERROR: Cannot find jni.h! 
>  Looked in "/include/jni.h" Please set
>  JAVA_HOME to a java home that has the JNI
> 
> >> The error until this part is probably because of jdk11 being set as 
> >> builddep,
> >> even though it requires jdk1.8 as is defined in the Makefile
> >
> > Yes this is strange because the port shouldn't build on aarch64 at all
> > (set by java.port.mk).
> >
> >
> > $ cd /usr/ports/net/i2p; make show=ONLY_FOR_ARCHS
> > i386 amd64
> >
>  http://build-failures.rhaalovely.net/aarch64/2020-11-20/java/tanukiwrapper.log
> 
> >
> > same here
> >
> >
> Don't know the reason for above, maybe one should check if the rest
> of the ports with MODJAVA_VER=1.8 are compatible with version 11.
> That could be the reason they didn't give out any errors.

it's because the port pulls in bsd.port.arch.mk itself, which has side effects.

I have updated these two ports to manually set ONLY_FOR_ARCHS because
the setting coming from java.port.mk is ignored.

> Forgot to add REVISION bump.
> The below changes are necessary, unless JAVA_HOME is manually appended to PATH
> while building, not a thing to leave up to chance.

This script is not called in the build.

Re: [MAINTAINER UPDATE] graphics/makehuman -> 1.2.0

[Dimitri Karamazov]

On Mon, November 23, 2020 07:41, Rafael Sadowski wrote:
> On Sun Nov 22, 2020 at 03:51:49PM -, Dimitri Karamazov wrote:
>
>> -
>> +V=  1.2.0
>> GH_ACCOUNT=  makehumancommunity
>> GH_PROJECT=  makehuman
>> -GH_TAGNAME= b0ca7c8837327b6fbcccfcc85f75a9854f95ea05
>> +GH_TAGNAME= v${V}
>>
>>
>
> I see no reason to introduce a new variable $V here otherwise the diff
> looks good.
Mistake by force of habit.

OK?

Index: Makefile
===
RCS file: /cvs/ports/graphics/makehuman/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile16 Aug 2020 08:03:05 -  1.33
+++ Makefile23 Nov 2020 08:36:45 -
@@ -2,11 +2,9 @@

 COMMENT=   parametrical modeling of 3D humanoid characters

-PKGNAME=   makehuman-1.2.0beta2
-
 GH_ACCOUNT=makehumancommunity
 GH_PROJECT=makehuman
-GH_TAGNAME=b0ca7c8837327b6fbcccfcc85f75a9854f95ea05
+GH_TAGNAME=v1.2.0

 CATEGORIES=graphics

Index: distinfo
===
RCS file: /cvs/ports/graphics/makehuman/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo16 Aug 2020 08:03:05 -  1.7
+++ distinfo23 Nov 2020 08:36:45 -
@@ -1,2 +1,2 @@
-SHA256 (makehuman-b0ca7c8837327b6fbcccfcc85f75a9854f95ea05.tar.gz) = 
yiUgSLbT2ermyuL8bGbK0avw6jye4D/30hBZCyJOu1I=
-SIZE (makehuman-b0ca7c8837327b6fbcccfcc85f75a9854f95ea05.tar.gz) = 43407370
+SHA256 (makehuman-1.2.0.tar.gz) = 32kE8bWnis+oNj8rKjuPz5yDwLMhR145QI+AJGG+sWs=
+SIZE (makehuman-1.2.0.tar.gz) = 44646408
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/makehuman/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST   16 Aug 2020 08:03:05 -  1.6
+++ pkg/PLIST   23 Nov 2020 08:36:46 -
@@ -1839,6 +1839,7 @@ share/makehuman/data/themes/default/
 share/makehuman/data/themes/default.mht
 share/makehuman/data/themes/default/images/
 share/makehuman/data/themes/default/images/splash.png
+share/makehuman/data/themes/default/images/splash.xcf
 share/makehuman/data/themes/makehuman/
 share/makehuman/data/themes/makehuman.mht
 share/makehuman/data/themes/makehuman.qss


regards,
  Dimitri

makehuman-diff
Description: Binary data

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 05:39:34

Modified files:
x11/qt5/qtwebkit: Makefile 

Log message:
qtwebkit: disable dwz for aarch64

assertion "off == cu_size" failed: file "dwz.c", line 9607, function 
"recompute_abbrevs"

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 05:37:25

Modified files:
net/i2p: Makefile 
java/tanukiwrapper: Makefile 

Log message:
explicitly set ONLY_FOR_ARCHS; it would normally come from java.port.mk
but MODULES is pulled in too late when bsd.port.arch.mk is included
directly from the port makefile.

Re: [Update from Maintainer] games/freeorion 0.4.10.1

[Nam Nguyen]

Tom Murphy writes:
> Hi,
>
> Attached below is an update for games/freeorion. This updates the game
> to 0.4.10.1.
>
> I removed GLU from WANTLIB (as it was complaining about Extra) and
> patches/patch-cmake_make_versioncpp_py has been removed (fixed upstream)
>
> Full changelog for the game can be found here:
>
> https://github.com/freeorion/freeorion/blob/v0.4.10.1/ChangeLog.md
>
> OK?
>
> Thanks,
> Tom

> Hi,
>
>   Just pinging the list about this diff. I posted it last month.
>   Re-attaching the diff.
>
>   OK?
>
>   Thanks!
>   Tom

Thank you for the update. Here is a fresh diff with two additional
tweaks:
- WANTLIB remove boost_system-mt and 80 column fix
- remove patch-cmake_FindBoost_cmake because boost python bindings are
  now named boost_python38-mt

I am looking for another OK to commit and Tom's approval.

I tested runtime and it works.

Details
---
I went through the types of warnings and they seem harmless. The same
warnings appear in the previous version as this update. Here are the
gory details on why they are harmless:

-Wdelete-abstract-non-virtual-dtor:
---
Fixed upstream
https://github.com/freeorion/freeorion/commit/ff55c8ca0d534c9cb035412067a02d05211dfc11

-Wrange-loop-construct:
---
/usr/obj/pobj/freeorion-0.4.10.1/src-tarball/GG/src/GUI.cpp:1685:21:
warning: loop variable 'drop_wnd' of type 'const std::__1::pair, GG::Pt>' creates a copy from type 'const
std::__1::pair, GG::Pt>'
[-Wrange-loop-construct]

Loop variable can be replaced with reference to make this warning go
away, but it is harmless. Similar to:
https://github.com/opencv/opencv/pull/18559/commits/2dd2d6095584b957b243bb86948b13223ecb39b3

-Wreturn-std-move
-
GUI.cpp:908:16: warning: local variable 'focus_wnd' will be copied
despite being returned by name [-Wreturn-std-move]

Declared r-value but it ends up being copied anyways.

-Wunused-lambda-capture
---
/usr/obj/pobj/freeorion-0.4.10.1/src-tarball/universe/IDAllocator.cpp:346:60:
warning: lambda capture 'this' is not used [-Wunused-lambda-capture]

These lambda captures really aren't used. Class members can be accessed
with 'this' in the capture list, but they actually aren't used.

UI/DesignWnd.cpp:1984:10: warning: lambda capture 'BUTTON_EDGE_PAD' is
not required to be captured for this use [-Wunused-lambda-capture]

However, this unused-lambda-capture is a bit confusing because
BUTTON_EDGE_PAD is actually used in the lambda.

-Woverloaded-shift-op-parentheses
-
ConditionParser7.cpp:157:40: warning: overloaded operator >> has higher
precedence than comparison operator [-Woverloaded-shift-op-parentheses]

This program uses the boost qi library to make a parser, and it relies
on overloading C++ syntax.

https://www.boost.org/doc/libs/1_74_0/libs/spirit/doc/html/spirit/qi/tutorials/warming_up.html

Index: Makefile
===
RCS file: /cvs/ports/games/freeorion/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- Makefile15 Aug 2020 20:30:53 -  1.8
+++ Makefile23 Nov 2020 11:27:18 -
@@ -1,11 +1,10 @@
 # $OpenBSD: Makefile,v 1.8 2020/08/15 20:30:53 rsadowski Exp $
 
-V =0.4.10
+V =0.4.10.1
 COMMENT =  turn-based space empire and galactic conquest computer game
-DISTNAME = FreeOrion_v${V}_2020-07-10.f3d403e_Source
+DISTNAME =  FreeOrion_v${V}_2020-09-25.39cfe10_Source
 PKGNAME =  freeorion-${V}
 CATEGORIES =   games
-REVISION = 0
 
 HOMEPAGE = https://www.freeorion.org/
 MAINTAINER =   Tom Murphy 
@@ -14,11 +13,11 @@ MAINTAINER =Tom Murphy https://github.com/freeorion/freeorion/releases/download/v${V}/
Index: distinfo
===
RCS file: /cvs/ports/games/freeorion/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo9 Aug 2020 09:37:07 -   1.3
+++ distinfo23 Nov 2020 11:27:18 -
@@ -1,2 +1,2 @@
-SHA256 (FreeOrion_v0.4.10_2020-07-10.f3d403e_Source.tar.gz) = 
5yq0LLoe6IQlBzQJMe84nmQBHgQKStx0rdX0mXu8uos=
-SIZE (FreeOrion_v0.4.10_2020-07-10.f3d403e_Source.tar.gz) = 124810803
+SHA256 (FreeOrion_v0.4.10.1_2020-09-25.39cfe10_Source.tar.gz) = 
AAYZGttQRtURFvblpld3PyAVr3wjaE8p4qff99r15Oc=
+SIZE (FreeOrion_v0.4.10.1_2020-09-25.39cfe10_Source.tar.gz) = 124809524
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/games/freeorion/patches/patch-CMakeLists_txt,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt9 Aug 2020 09:37:07 -   1.3
+++ patches/patch-CMakeLists_txt23 Nov 2020 11:27:18 -
@@ -4,7 +4,7 @@ Remove hardcoded optimisation option.
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -436,7 +436,6 @@ 

Re: cyrus-imapd upstreamed patches and improvements

[Stuart Henderson]

On 2020/11/23 07:31, Anatoli wrote:
> Stuart,
>
> Thanks a lot for the explanation! Much appreciated!
>
> cyrus-imapd project is mostly modular (e.g. if it's built with --enable-http,
> there would be additional binary httpd), but there are also some elements that
> hold the compilation information, like cyr_buildinfo [1] which returns the
> details about the components, dependencies, etc. that were activated or not
> during the build:

ok, so subpackages won't work for this - seems it also links libcyrus
against all the various libraries used by the various components. (last
time I ran cyrus imapd it was in 2.2.something days so I'm not familiar
with current development :-)

> > If you've built it with everything included, then there is no particular
> > advantage to packaging up subsets of that.  You might think "we can avoid
> > bloat by excluding the features we don't need", but in this case all the 
> > APIs
> > to support those features would still be in libcyrus, you would just be
> > missing binaries.  You could have achieved the same effect by just not 
> > running
> > those services in cyrus.conf
>
> I guess it would be more appropriate to proceed with flavors.

There is also ellie's reply, which makes a lot of sense at least in
cases where it doesn't pull in a bunch of extra dependencies:

 "I would simply provide one package with all the
stable/non-experimental features enabled, and admins can
just not use the features they don't need."

> I was thinking about actually defining a number of flavors (basically for most
> components and dependencies as returned by cyr_buildinfo), but to build only 4
> combinations as part of the build infrastructure (the most clear use-cases), 
> so
> the rest of possible combinations could be activated by the users in the 
> ports.
>
> Does that sound good?

With flavours, all of the individual choices should be built as part of
a bulk build, to make sure that any breakage in non-default options is
picked up, plus whatever combinations are useful for real-world use
should be built too.

When the port is updated later, the set of different "standard build"
flavours should be tested. When deciding what flavours to support, this
extra work for every update needs factoring in :-)

Additionally consider the case where new users install the software;
pkg_add will present the big list of options which can be a bit
overwhelming if a flavour is provided for every build option.

Generally my approach would be to add flavours for things which are
fairly popular but that also some users will really not want to use.
This could either be "positive" flavours to enable those features,
or "negative" flavours i.e. "no_whatever" to disable them (for example
many ports have a no_x11 flavour). I would tend towards "negative"
for core features that some people may want to avoid (considering
cyrus then http might be a candidate for this) - and "positive" for
things pulling in heavier-weight extra dependencies.

> And if I understood it correctly, I'd have to use PFRAGs and %%flavor%% in 
> PLIST
> to define the build differences for each flavor, right?

Yes. Try www/lighttpd for a simple example of this (vim is a poor
example to crib from as it has a combination of multipackages *and*
flavours).

games/cataclysm-dda is a more complex example (though still just
flavours not multipackages) using PFRAG.no_x11 for files which are only
in the no_x11 flavour, PFRAG.no-no_x11 for files which are _not_ in
the no_x11 flavour, and PLIST has the files common to both flavours.

> Anatoli
>
> [1] 
> https://www.cyrusimap.org/imap/reference/manpages/systemcommands/cyr_buildinfo.html
> [2] 
> https://cyrus.topicbox.com/groups/devel/T5acbcb9536dc47c3/cyrus-imapd-packaging-flavors-variations
>
>
> On 22/11/20 10:53, Stuart Henderson wrote:
> > On 2020/11/22 00:27, Anatoli wrote:
> >> Then, I'm working now on the flavored version of the port, and my idea is 
> >> to
> >> apply it as soon as the new minor version is published (or maybe even 
> >> before
> >> this so not to deal with the REVISION) but this is my first time working 
> >> with
> >> ports, so I have no experience with the process and I have a couple of 
> >> questions
> >> about some aspects of flavors definition.
> >
> > Is the build "modular"? That is, do the build options just have it build
> > additional features in separate files (.so modules etc), or do they change
> > the main binaries too?
> >
> > For builds which are modular, generally we do a single build and split
> > the various files into subpackages. See for example PHP, Asterisk,
> > Dovecot. MULTI_PACKAGES is defined with a list of subpackage names,
> > the port is built once, packages are created for each subpackage
> > using the relevant "PLIST-sub" file.
> >
> > (Heading off something you will see in some of these ports - there are
> > "no_*" pseudo-flavours in some of these which are an optimization to
> > reduce build dependencies for people 

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/11/23 03:49:41

Modified files:
editors/vim: Makefile distinfo 
editors/vim/patches: patch-runtime_filetype_vim 
editors/vim/pkg: PLIST-lang PLIST-main 
Added files:
editors/vim/patches: patch-runtime_syntax_bindzone_vim 

Log message:
update to vim-8.2.2034

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/11/23 03:36:12

Modified files:
x11/gnome/eog  : Makefile distinfo 

Log message:
update to eog-3.38.1

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/11/23 03:36:08

Modified files:
x11/gnome/calculator: Makefile distinfo 

Log message:
update to gnome-calculator-3.38.2

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/11/23 02:58:35

Modified files:
devel/cmake: cmake.port.mk 

Log message:
Cleanup: tabs and spaces

CVS: cvs.openbsd.org: ports

[Gonzalo L . Rodriguez]

CVSROOT:/cvs
Module name:ports
Changes by: gonz...@cvs.openbsd.org 2020/11/23 02:32:27

Modified files:
www/nextcloud  : Makefile distinfo 
www/nextcloud/pkg: PLIST 

Log message:
Update for Nextcloud to 20.0.2:

https://nextcloud.com/changelog/

OK tracey@

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/11/23 02:31:46

Modified files:
graphics/makehuman: Makefile distinfo 
graphics/makehuman/pkg: PLIST 

Log message:
Update makehuman to 1.2.0

>From maintainer Dimitri Karamazov

clang ICE, golang SIGILL, others [Re: aarch64 bulk build report]

[Stuart Henderson]

On 2020/11/22 18:50, phess...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/aarch64/2020-11-20/converters/wv2.log
> http://build-failures.rhaalovely.net/aarch64/2020-11-20/editors/calligra.log
> http://build-failures.rhaalovely.net/aarch64/2020-11-20/editors/xwpe.log
> http://build-failures.rhaalovely.net/aarch64/2020-11-20/emulators/vice.log

these are all clang ICE, Running pass 'AArch64 Instruction Selection'.

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/java/tanukiwrapper.log
> http://build-failures.rhaalovely.net/aarch64/2020-11-20/net/i2p.log

java 1.8 ports; should not even be tried on aarch64. possibly connected with
pulling in bsd.port.arch.mk.

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/sysutils/rclone.log

uses the newly-compiled binary during build which fails with SIGILL:

cd /usr/obj/ports/rclone-1.53.3/go/bin &&  
HOME=/usr/obj/ports/rclone-1.53.3/go/src/github.com/rclone/rclone ./rclone 
genautocomplete bash rclone.bash
SIGILL: illegal instruction
PC=0xca0700 m=0 sigcode=1
instruction bytes: 0x0 0x6 0x38 0xd5 0xe0 0x7 0x0 0xf9 0xc0 0x3 0x5f 0xd6 0x0 
0x0 0x0 0x0
..

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/x11/qt5/qtwebkit.log
builds ok, but dwz fails when compressing debug symbols
assertion "off == cu_size" failed: file "dwz.c", line 9607, function 
"recompute_abbrevs"
could just set DWZ=: in the port

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/games/shockolate.log
compile: invalid operands to binary expression

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/www/chromium.log
mksnapshot: out of memory

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/x11/e17/elementary.log
linker: undefined symbols, mesa-related


All the rest are go arch support, some due to pinned/vendored old versions
of system modules.


> http://build-failures.rhaalovely.net/aarch64/2020-11-20/devel/sqlc.log
# github.com/lfittl/pg_query_go/parser
...
In file included from 
../../../go/pkg/mod/github.com/lfittl/pg_query_go@v1.0.0/parser/include/utils/dsa.h:17:
../../../go/pkg/mod/github.com/lfittl/pg_query_go@v1.0.0/parser/include/port/atomics.h:68:10:
 fatal error: 'port/atomics/arch-arm.h' file not found

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/security/age.log
go module pinned to an old version of sys/unix with no aarch64 support for 
OpenBSD
# golang.org/x/sys/unix
../../go/pkg/mod/golang.org/x/sys@v0.0.0-20190412213103-97732733099d/unix/fcntl.go:26:42:
 undefined: Flock_t
../../go/pkg/mod/golang.org/x/sys@v0.0.0-20190412213103-97732733099d/unix/ioctl.go:14:47:
 undefined: Winsize
../../go/pkg/mod/golang.org
etc

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/sysutils/docker-cli.log
similar, old vendored version of sys/unix
# github.com/docker/cli/vendor/golang.org/x/sys/unix
vendor/golang.org/x/sys/unix/fcntl.go:26:42: undefined: Flock_t
vendor/golang.org/x/sys/unix/ioctl.go:14:47: undefined: Winsize
vendor/golang.org/x/sys/unix/ioctl.go:25:47: undefined: Termios
etc

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/sysutils/nomad.log
# github.com/hashicorp/nomad/vendor/github.com/kr/pty
vendor/github.com/kr/pty/pty_openbsd.go:24:10: undefined: ptmget

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/sysutils/telegraf.log
# github.com/influxdata/telegraf/vendor/github.com/shirou/gopsutil/disk
vendor/github.com/shirou/gopsutil/disk/disk_openbsd.go:24:36: undefined: 
MNT_WAIT
vendor/github.com/shirou/gopsutil/disk/disk_openbsd.go:29:15: undefined: Statfs
vendor/github.com/shirou/gopsutil/disk/disk_openbsd.go:30:28: undefined: 
MNT_WAIT
...
github.com/influxdata/telegraf/vendor/github.com/shirou/gopsutil/mem
# github.com/influxdata/telegraf/vendor/github.com/shirou/gopsutil/mem
vendor/github.com/shirou/gopsutil/mem/mem_openbsd.go:21:17: undefined: CTLVm
vendor/github.com/shirou/gopsutil/mem/mem_openbsd.go:21:24: undefined: VmUvmexp
vendor/github.com/shirou/gopsutil/mem/mem_openbsd.go:26:14: undefined: 
sizeOfUvmexp
...

> http://build-failures.rhaalovely.net/aarch64/2020-11-20/sysutils/terragrunt.log
# github.com/creack/pty
../../../go/pkg/mod/github.com/creack/pty@v1.1.9/pty_openbsd.go:24:10: 
undefined: ptmget

Re: aarch64 bulk build report

[Dimitri Karamazov]

On Mon, November 23, 2020 04:51, Dimitri Karamazov wrote:
> On Mon, November 23, 2020 04:26, phess...@openbsd.org wrote:
>
>> bulk build on arm64.ports.openbsd.org started on  Fri Nov 20 04:33:02 MST 
>> 2020 finished at Sun Nov 22 18:50:13 MST
>> 2020
>> lasted 2D14h17m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) 
>> #905: Thu Nov 19 22:40:17 MST 2020
>>
>> http://build-failures.rhaalovely.net/aarch64/2020-11-20/net/i2p.log
>>
>>
>>
>> cd /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c && CC=cc BITS=64
>> /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh
>> Building openbsd .sos
>> Please ensure you have a Java SDK installed
>> and/or set JAVA_HOME then re-run this script. ERROR: Cannot find jni.h! 
>> Looked in "/include/jni.h" Please set
>> JAVA_HOME to a java home that has the JNI
The error until this part is probably because of jdk11 being set as builddep,
even though it requires jdk1.8 as is defined in the Makefile

>> http://build-failures.rhaalovely.net/aarch64/2020-11-20/java/tanukiwrapper.log
>> compile-java:core:
>>[mkdir] Created dir: 
>> /usr/obj/ports/java-tanukiwrapper-3.5.44/wrapper_3.5.44_src/build/classes
>>[mkdir] Created dir: 
>> /usr/obj/ports/java-tanukiwrapper-3.5.44/wrapper_3.5.44_src/build/testclasses
>>[mkdir] Created dir: 
>> /usr/obj/ports/java-tanukiwrapper-3.5.44/wrapper_3.5.44_src/lib
>>[javac] Compiling 109 source files to 
>> /usr/obj/ports/java-tanukiwrapper-3.5.44/wrapper_3.5.44_src/build/classes
>>[javac] warning: [options] bootstrap class path not set in conjunction 
>> with -source 1.4
>>[javac] error: Source option 1.4 is no longer supported. Use 6 or later.
>>[javac] error: Target option 1.4 is no longer supported. Use 1.6 or later.
Same here

regards,
  Dimitri

Re: NEW: fonts/ttyp0-font

[Manuel Giraud]

Stuart Henderson  writes:

> at least all of the single flavours:
>
>   SUBDIR += ttyp0-font,sq
>   SUBDIR += ttyp0-font,ct
>   SUBDIR += ttyp0-font,nbd
>   SUBDIR += ttyp0-font,sz
>
> others by request I guess?

maybe nbs,sz too (as terminus as already a slashed zero).
-- 
Manuel Giraud

Re: aarch64 bulk build report

[Dimitri Karamazov]

On Mon, November 23, 2020 04:26, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org started on  Fri Nov 20 04:33:02 MST 
> 2020 finished at Sun Nov 22 18:50:13 MST 2020
>  lasted 2D14h17m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) 
> #905: Thu Nov 19 22:40:17 MST 2020
>
> http://build-failures.rhaalovely.net/aarch64/2020-11-20/net/i2p.log
>
>
> cd /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c && CC=cc BITS=64  
> /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh
>  Building openbsd .sos
> Please ensure you have a Java SDK installed
> and/or set JAVA_HOME then re-run this script. ERROR: Cannot find jni.h! 
> Looked in "/include/jni.h"
> Please set JAVA_HOME to a java home that has the JNI
> cp: jcpuid/lib/freenet/support/CPUInformation/*jcpuid*: No such file or 
> directory
> cp: jbigi/lib/*jbigi*: No such file or directory
> /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh[12]: jar: not found
> Native code built into jbigi.jar
>
>
I don't know why exactly the jar program isn't picked up, so I simply fixed
it's path. Probably because it uses a shell script for that specific build.
But part of the fix is required for amd64 too, particularly the patch.
Can't test, don't have aarch64.

Index: Makefile
===
RCS file: /cvs/ports/net/i2p/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile5 Nov 2020 19:54:50 -   1.3
+++ Makefile23 Nov 2020 04:21:42 -
@@ -43,6 +43,8 @@ DB_DIR=   ${LOCALSTATEDIR}/i2p

 SUBST_VARS=DB_DIR JAVA_HOME

+MAKE_ENV=  CC=${CC} BITS=${BITS}
+
 WRKDIST=   ${WRKDIR}/${PKGNAME}

 # test requires addition dependencies (atleast: junit, hamcrest, jmockfit)
@@ -54,8 +56,7 @@ post-patch:
${SUBST_CMD} ${WRKSRC}/installer/resources/eepget

 post-build:
-   cd ${WRKSRC}/core/c && CC=${CC} BITS=${BITS} \
-   ${WRKSRC}/core/c/build.sh
+   cd ${WRKSRC}/core/c && ${MAKE_ENV} ${WRKSRC}/core/c/build.sh

 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/i2p
Index: patches/patch-core_c_build_sh
===
RCS file: patches/patch-core_c_build_sh
diff -N patches/patch-core_c_build_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-core_c_build_sh   23 Nov 2020 04:21:42 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+fix jar location
+
+--- core/c/build.sh.orig   Mon Nov 23 09:30:07 2020
 core/c/build.shMon Nov 23 09:30:50 2020
+@@ -9,6 +9,6 @@ cp jcpuid/lib/freenet/support/CPUInformation/*jcpuid*
+ mkdir -p t/net/i2p/util/
+ cp jbigi/lib/*jbigi* t/
+
+-(cd t ; jar cf ../jbigi.jar . ; cd ..)
++(cd t ; ${JAVA_HOME}/bin/jar cf ../jbigi.jar . ; cd ..)
+
+ echo "Native code built into jbigi.jar"


regards,
  Dimitri

CVS: cvs.openbsd.org: ports

[Benoit Lecocq]

CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/11/23 01:51:21

Modified files:
devel/p5-Graph : Makefile distinfo 

Log message:
Update to p5-Graph-0.9709.

Re: update coq to 8.12.1

[Yozo TODA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Daniel Dickman writes:
> Hi Yozo, a new release of coq has been made. I've already updated compcert 
> to v3.8 which supports this new version of coq and is the only consumer 
> of coq.
>
> ok if we update coq to the latest version?

ok with me.
Reading the changelog I believe this revision affects nothing for packaging.

Actually I'm trying to update to 8.12.1 with the same diff, too :-D
It just compiles and works on amd64.

I'll try compile on ocaml-non-native architectures
(simulating with arch-defines.mk modified), and
post another message when I find anything.

 -- yozo.


-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEP48DGKttLBTWuiCMx2ep6SZGbGQFAl+7SgkVHHlvem9AdjAw
Ny52YWlvLm5lLmpwAAoJEMdnqekmRmxkrysP/0Fy92jLM75R/9aymPAJIkUqOEa8
24Uj5jrjVnaN3PuhAaQLRlZrkAIcDlGoWl3uorVoIvkSrwgadT4jsaXTsl3bdg/N
MMEOWSzi9dWGxRBubqhvenV6EQgLO8UcgSmgwmz4exlgrkCzPRQTJ/mf7rya5x0F
q4d0mBT8USaYglgo+ndhZUhxKAeEdgkgawSl5Ub8Nrotr3oRq2LGJC8xrpCY2bXG
vvbzXejfM2p/qHn79Fwc1yqy05ePLc4otVsEofC0l4O4/0kGBkwKSNyD7JYegPDK
0oOT2SD+EquRt1NR3FDfu4Pr3EMVLtWiLFyD4GAkahvYZLJBtUR7nNTPLgXBhUHF
eqP0w/lHa1gIC8ZAZIHXo8kkGehISnqOxgKwQkWloToERRDoAhNvhSg0uRk2HsRz
Z5ySUVZ/3TPZ2onW4jId1AbA3Fev3bZgPu0adEUbBNimju9EjJ+Vj8ho1fATo8Oy
WFBr9u0YdXlIH2QGbra1MAFsWLiFgA091VadeQy8U061FuoRAg5TyAwuCcTbTpI5
5N3E/Ph25G+4GGf7M4onIuFPjNQ6Je7t6i6Zw7/UAOsgrku4WFbKoiHybQnRiqRg
8JdMHO5QO7KNsIb7XMiC929YbD3imKfy1wDTjEFP8RiKe/9tgDP/peU94SluTwwV
AOh+En3pltiAr+P9
=OuCy
-END PGP SIGNATURE-

Re: aarch64 bulk build report

[Stuart Henderson]

On 2020/11/23 05:14, Dimitri Karamazov wrote:
> >> /usr/obj/ports/i2p-0.9.47/i2p-0.9.47/core/c/build.sh
> >> Building openbsd .sos
> >> Please ensure you have a Java SDK installed
> >> and/or set JAVA_HOME then re-run this script. ERROR: Cannot find jni.h! 
> >> Looked in "/include/jni.h" Please set
> >> JAVA_HOME to a java home that has the JNI
> The error until this part is probably because of jdk11 being set as builddep,
> even though it requires jdk1.8 as is defined in the Makefile

Yes this is strange because the port shouldn't build on aarch64 at all
(set by java.port.mk).

$ cd /usr/ports/net/i2p; make show=ONLY_FOR_ARCHS
i386 amd64

> >> http://build-failures.rhaalovely.net/aarch64/2020-11-20/java/tanukiwrapper.log

same here