OpenBSD Mail Box: October 2020

Saturday, October 31, 2020

Re: assembler error on trying to port OpenBLAS

On 10/31/20 9:48 PM, Brad Smith wrote:
> On 10/31/2020 12:57 PM, Aisha Tammy wrote:
>> On 10/29/20 8:25 PM, Aisha Tammy wrote:
>>> Hi,
>>> I'm trying to port OpenBLAS to the tree and am currently getting
>>> some weird assembler errors (port makefile is attached at end math/openblas)
>>>
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages:
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)'
>>> ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper '
>>>
>>>
>>> Presumably this is happening due to the assembler being used is
>>> the one from base as we don't build the ports egcc with gas for
>>> anything except aarch64 and arm.
>>> I'm kind of stumped here as it seems like using gfortran sets the
>>> compiler to egcc (compiling the above file with cc works).
>>> Is it possible to mix gfortran with base-clang C compiler?
>>> Another (possible) solution would be to build egcc all archs with
>>> the new gas assembler, but that sounds a lot more dangerous and I
>>> don't know enough to know if that is possible/or even a good idea/
>>> or if it will even work :-/
>>>
>>> Any pointers would be cool to have.
>>> (I've cc'ed pascal@ as they are the maintainer for gcc port and
>>> can be better suited to answer the second point of gas)
>>>
>>> Thanks,
>>> Aisha
>>>
>>>
>>> # $OpenBSD $
>>>
>>> COMMENT    =    optimized BLAS/LAPACK library based on GotoBLAS
>>> PKGNAME =    ${DISTNAME:L}
>>> CATEGORIES =    math
>>>
>>> GH_ACCOUNT =    xianyi
>>> GH_PROJECT =    OpenBLAS
>>> GH_TAGNAME =    v0.3.12
>>>
>>> SHARED_LIBS =    openblas 0.0 \
>>>          blas 7.2 \
>>>          cblas 7.2 \
>>>          lapack 7.2 \
>>>          lapacke 7.2
>>>
>>> MAINTAINER =    Aisha Tammy <openbsd@aisha.cc>
>>>
>>> # BSD
>>> PERMIT_PACKAGE =    Yes
>>>
>>> WANT_LIB +=    c m pthread
>>>
>>> MODULES =    fortran
>>> MODFORTRAN_COMPILER =    gfortran
>>>
>>> USE_GMAKE =    Yes
>>>
>>> MAKE_ENV =    CFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}" \
>>>          LIBopenblas_VERSION="${LIBopenblas_VERSION}" \
>>>          LIBblas_VERSION="${LIBblas_VERSION}" \
>>>          LIBcblas_VERSION="${LIBcblas_VERSION}" \
>>>          LIBlapack_VERSION="${LIBlapack_VERSION}" \
>>>          LIBlapacke_VERSION="${LIBlapacke_VERSION}" \
>>>          USE_THREAD=1 USE_OPENMP=0 \
>>>          NUM_PARALLEL=8 \
>>>          NUM_THREADS=64 \
>>>          MAKE_NB_JOBS=-1 \
>>>          DYNAMIC_ARCH=1 \
>>>          TARGET=GENERIC \
>>>          NO_AFFINITY=1 \
>>>          NO_STATIC=0 \
>>>          BUILD_RELAPACK=1
>>>
>>> .include <bsd.port.mk>
>>>
>>
>> Thanks for the people who commented.
>> I've managed to fix the error by forcing the
>> COMPILER_LINKS = cc /usr/bin/cc gcc /usr/bin/gcc
>
> But that's not an option for something that is to be commited to the tree.
>

Well damn...
Is there any other method to fix the compiler to cc instead of
this?
I tried adding the lang/clang module before the fortran module
MODULES = lang/clang fortran
but that fixes the compiler to /usr/local/bin/clang instead of the
/usr/bin/clang.
I am not sure what else to try right now :(

Thanks,
Aisha

aarch64 bulk build report

Re: assembler error on trying to port OpenBLAS

On 10/31/2020 12:57 PM, Aisha Tammy wrote:
> On 10/29/20 8:25 PM, Aisha Tammy wrote:
>> Hi,
>> I'm trying to port OpenBLAS to the tree and am currently getting
>> some weird assembler errors (port makefile is attached at end
>> math/openblas)
>>
>> ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages:
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such
>> instruction: `vbroadcastss (%rcx),%ymm0'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such
>> instruction: `vmovups (%rdx,%rax,4),%ymm8'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such
>> instruction: `vmovups 32(%rdx,%rax,4),%ymm9'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such
>> instruction: `vmovups 64(%rdx,%rax,4),%ymm10'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such
>> instruction: `vmovups 96(%rdx,%rax,4),%ymm11'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such
>> instruction: `vmovups (%rsi,%rax,4),%ymm4'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such
>> instruction: `vmovups 32(%rsi,%rax,4),%ymm5'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such
>> instruction: `vmovups 64(%rsi,%rax,4),%ymm6'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such
>> instruction: `vmovups 96(%rsi,%rax,4),%ymm7'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such
>> instruction: `vmulps %ymm4,%ymm0,%ymm4'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such
>> instruction: `vaddps %ymm8,%ymm4,%ymm12'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such
>> instruction: `vmulps %ymm5,%ymm0,%ymm5'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such
>> instruction: `vaddps %ymm9,%ymm5,%ymm13'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such
>> instruction: `vmulps %ymm6,%ymm0,%ymm6'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such
>> instruction: `vaddps %ymm10,%ymm6,%ymm14'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such
>> instruction: `vmulps %ymm7,%ymm0,%ymm7'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such
>> instruction: `vaddps %ymm11,%ymm7,%ymm15'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such
>> instruction: `vmovups (%rdx,%rax,4),%ymm8'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such
>> instruction: `vmovups 32(%rdx,%rax,4),%ymm9'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such
>> instruction: `vmovups 64(%rdx,%rax,4),%ymm10'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such
>> instruction: `vmovups 96(%rdx,%rax,4),%ymm11'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such
>> instruction: `vmovups (%rsi,%rax,4),%ymm4'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such
>> instruction: `vmovups 32(%rsi,%rax,4),%ymm5'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such
>> instruction: `vmovups 64(%rsi,%rax,4),%ymm6'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such
>> instruction: `vmovups 96(%rsi,%rax,4),%ymm7'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such
>> instruction: `vmovups %ymm12,-128(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such
>> instruction: `vmovups %ymm13,-96(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such
>> instruction: `vmovups %ymm14,-64(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such
>> instruction: `vmovups %ymm15,-32(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such
>> instruction: `vmulps %ymm4,%ymm0,%ymm4'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such
>> instruction: `vmulps %ymm5,%ymm0,%ymm5'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such
>> instruction: `vmulps %ymm6,%ymm0,%ymm6'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such
>> instruction: `vmulps %ymm7,%ymm0,%ymm7'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such
>> instruction: `vaddps %ymm8,%ymm4,%ymm12'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such
>> instruction: `vaddps %ymm9,%ymm5,%ymm13'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such
>> instruction: `vaddps %ymm10,%ymm6,%ymm14'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such
>> instruction: `vaddps %ymm11,%ymm7,%ymm15'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such
>> instruction: `vmovups %ymm12,-128(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such
>> instruction: `vmovups %ymm13,-96(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such
>> instruction: `vmovups %ymm14,-64(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such
>> instruction: `vmovups %ymm15,-32(%rdx,%rax,4)'
>> ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such
>> instruction: `vzeroupper '
>>
>>
>> Presumably this is happening due to the assembler being used is
>> the one from base as we don't build the ports egcc with gas for
>> anything except aarch64 and arm.
>> I'm kind of stumped here as it seems like using gfortran sets the
>> compiler to egcc (compiling the above file with cc works).
>> Is it possible to mix gfortran with base-clang C compiler?
>> Another (possible) solution would be to build egcc all archs with
>> the new gas assembler, but that sounds a lot more dangerous and I
>> don't know enough to know if that is possible/or even a good idea/
>> or if it will even work :-/
>>
>> Any pointers would be cool to have.
>> (I've cc'ed pascal@ as they are the maintainer for gcc port and
>> can be better suited to answer the second point of gas)
>>
>> Thanks,
>> Aisha
>>
>>
>> # $OpenBSD $
>>
>> COMMENT    =    optimized BLAS/LAPACK library based on GotoBLAS
>> PKGNAME =    ${DISTNAME:L}
>> CATEGORIES =    math
>>
>> GH_ACCOUNT =    xianyi
>> GH_PROJECT =    OpenBLAS
>> GH_TAGNAME =    v0.3.12
>>
>> SHARED_LIBS =    openblas 0.0 \
>>          blas 7.2 \
>>          cblas 7.2 \
>>          lapack 7.2 \
>>          lapacke 7.2
>>
>> MAINTAINER =    Aisha Tammy <openbsd@aisha.cc>
>>
>> # BSD
>> PERMIT_PACKAGE =    Yes
>>
>> WANT_LIB +=    c m pthread
>>
>> MODULES =    fortran
>> MODFORTRAN_COMPILER =    gfortran
>>
>> USE_GMAKE =    Yes
>>
>> MAKE_ENV =    CFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}" \
>>          LIBopenblas_VERSION="${LIBopenblas_VERSION}" \
>>          LIBblas_VERSION="${LIBblas_VERSION}" \
>>          LIBcblas_VERSION="${LIBcblas_VERSION}" \
>>          LIBlapack_VERSION="${LIBlapack_VERSION}" \
>>          LIBlapacke_VERSION="${LIBlapacke_VERSION}" \
>>          USE_THREAD=1 USE_OPENMP=0 \
>>          NUM_PARALLEL=8 \
>>          NUM_THREADS=64 \
>>          MAKE_NB_JOBS=-1 \
>>          DYNAMIC_ARCH=1 \
>>          TARGET=GENERIC \
>>          NO_AFFINITY=1 \
>>          NO_STATIC=0 \
>>          BUILD_RELAPACK=1
>>
>> .include <bsd.port.mk>
>>
>
> Thanks for the people who commented.
> I've managed to fix the error by forcing the
> COMPILER_LINKS = cc /usr/bin/cc gcc /usr/bin/gcc

But that's not an option for something that is to be commited to the tree.

Re: UPDATE: Boost 1.70

On Sat, Oct 31, 2020 at 09:19:41PM -0400, Daniel Dickman wrote:
>
>
> On Fri, 30 Oct 2020, Stuart Henderson wrote:
>
> > comms/sigrok/pulseview
> >
> > In file included from pulseview_autogen/mocs_compilation.cpp:6:
> > In file included from pulseview_autogen/4KQHGSF5UX/moc_analogsegment.cpp:10:
> > In file included from pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/analogsegment.hpp:23:
> > In file included from pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/segment.hpp:24:
> > In file included from /pobj/pulseview-0.4.1/pulseview-0.4.1/pv/util.hpp:28:
> > /usr/local/include/boost/multiprecision/cpp_dec_float.hpp:613:12: error: implicit instantiation of undefined template 'boost::serialization::nvp<bool>'
> >
> >
>
> How about this? Does someone want to check it works with the in-tree
> version of boost as well?
>
> diff -Nur pulseview/Makefile pulseview.new/Makefile
> --- pulseview/Makefile Fri Mar 8 15:00:40 2019
> +++ pulseview.new/Makefile Sat Oct 31 20:58:58 2020
> @@ -1,8 +1,7 @@
> # $OpenBSD: Makefile,v 1.4 2019/03/08 20:00:40 cwen Exp $
>
> COMMENT = command-line frontend for sigrok logic analyzer
> -REVISION = 1
> -
> +REVISION = 2
> SIGROK_PROJECT = pulseview
> SIGROK_VERSION = 0.4.1
>
> diff -Nur pulseview/patches/patch-pv_util_hpp pulseview.new/patches/patch-pv_util_hpp
> --- pulseview/patches/patch-pv_util_hpp Wed Dec 31 19:00:00 1969
> +++ pulseview.new/patches/patch-pv_util_hpp Sat Oct 31 21:11:35 2020
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +backport commit 136b891 to work around boost + clang10 issue
> +
> +Index: pv/util.hpp
> +--- pv/util.hpp.orig
> ++++ pv/util.hpp
> +@@ -25,6 +25,7 @@
> + #include <vector>
> +
> + #ifndef Q_MOC_RUN
> ++#include <boost/serialization/nvp.hpp>
> + #include <boost/multiprecision/cpp_dec_float.hpp>
> +

Re: UPDATE: Boost 1.70

On Fri, 30 Oct 2020, Stuart Henderson wrote:

> comms/sigrok/pulseview
>
> In file included from pulseview_autogen/mocs_compilation.cpp:6:
> In file included from pulseview_autogen/4KQHGSF5UX/moc_analogsegment.cpp:10:
> In file included from pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/analogsegment.hpp:23:
> In file included from pulseview_autogen/4KQHGSF5UX/../../../pulseview-0.4.1/pv/data/segment.hpp:24:
> In file included from /pobj/pulseview-0.4.1/pulseview-0.4.1/pv/util.hpp:28:
> /usr/local/include/boost/multiprecision/cpp_dec_float.hpp:613:12: error: implicit instantiation of undefined template 'boost::serialization::nvp<bool>'
>
>

How about this? Does someone want to check it works with the in-tree
version of boost as well?

diff -Nur pulseview/Makefile pulseview.new/Makefile
--- pulseview/Makefile Fri Mar 8 15:00:40 2019
+++ pulseview.new/Makefile Sat Oct 31 20:58:58 2020
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.4 2019/03/08 20:00:40 cwen Exp $

COMMENT = command-line frontend for sigrok logic analyzer
-REVISION = 1
-
+REVISION = 2
SIGROK_PROJECT = pulseview
SIGROK_VERSION = 0.4.1

diff -Nur pulseview/patches/patch-pv_util_hpp pulseview.new/patches/patch-pv_util_hpp
--- pulseview/patches/patch-pv_util_hpp Wed Dec 31 19:00:00 1969
+++ pulseview.new/patches/patch-pv_util_hpp Sat Oct 31 21:11:35 2020
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+backport commit 136b891 to work around boost + clang10 issue
+
+Index: pv/util.hpp
+--- pv/util.hpp.orig
++++ pv/util.hpp
+@@ -25,6 +25,7 @@
+ #include <vector>
+
+ #ifndef Q_MOC_RUN
++#include <boost/serialization/nvp.hpp>
+ #include <boost/multiprecision/cpp_dec_float.hpp>
+

Re: Update to py-requests-2.24.0

On Wed, Oct 28, 2020 at 09:36:16PM -0400, Daniel Jakots wrote:
> On Wed, 14 Oct 2020 22:32:56 -0400, Daniel Jakots <danj@chown.me> wrote:

> > On Wed, 14 Oct 2020 13:06:33 +0200, Antoine Jacoutot
> > <ajacoutot@bsdfrog.org> wrote:

> > > > Here's a diff for py-requests. I had trouble with 2.23's test
> > > > suite. I found a solution for 2.24 from
> > > > https://github.com/pytest-dev/pytest/issues/2042#issuecomment-429289164

> > > > There are still some failures.

> > > Looks fine to me.
> > > Do these failures appear in the previous version?

> > No, tests in the current version are better. There are some
> > failures because
> > SSLError: HTTPSConnectionPool(host='127.0.0.1', port=37564): Max
> > retries exceeded with url:
> > /redirect-to?url=http%3A%2F%2F127.0.0.1%3A12892%2Fget (Caused by
> > SSLError(CertificateError("hostname '127.0.0.1' doesn't match either
> > of 'localhost', '127.0.0.1'",),))
> > which is weird. I don't remember them
> > from last time I updated the port, so maybe a TDEP changed in the
> > meantime?

> > Anyway, I've been using the update and it works fine for me (that
> > said, my requests use is quite small).

> ping

py-requests has a lot of consumers. Did you run through regression tests
on a number of these to make sure this doesn't break them?

--Kurt

6.8 - Difficulties getting Wireguard ipv6 working

Hi,

I currently have a fully functional dual-stack Wireguard instance running on Debian. However given the recent release of OpenBSD 6.8 with Wireguard in base, I thought it would be a good opportunity to switch over from the dark side. ;-)

Anyway, so on Debian I have a no-NAT setup, with the host announcing the VPN subnets to upstream router. All works great.

I'm no stranger to OpenBSD and OpenBGPD, but I've only managed to get 2/3 of the way :
- The OpenBSD host is config fully functional dual-stack, IPv4 and IPv6 work perfectly
- wg(4) IPv4 config works perfectly, clients can connect and browse the internet
- wg(4) IPv6 config does not work, clients can connect but no routing, not even able to ping loopback IPs or the wg interface IP.
- I have verified upstream routers can ping test loopback IPv6 IPs, so dual-stack BGP is functional
- I have tried a IPv6 only wireguard client config (as shown below) and that has no effect ( i thought maybe a dual-stack client config was the problem with OpenBSD)

Config follows:

OPENBSD SERVER
$ cat /etc/sysctl.conf
ddb.panic=0
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
$ cat /etc/hostname.wg1
inet 192.0.2.1 0xffffffc0
inet6 2001:db8:ffff:ffff::ffff 64
wgkey secretsquirrel
wgport 12345
wgpeer secretsquirrel wgpsk secretsquirrel wgaip 192.0.2.2/32 wgaip 2001:db8:ffff:ffff:aaaa:aaaa:aaaa:aaaa/128
up
$ doas cat /etc/pf.conf
set skip on {lo,wg}
pass

CLIENT CONFIG

[Interface]
PrivateKey = secretsquirrel
Address = 2001:db8:ffff:ffff:aaaa:aaaa:aaaa:aaaa/128
DNS = 2620:fe::fe
[Peer]
PublicKey = secretsquirrel
PresharedKey = secretsquirrel
AllowedIPs = ::/0
Endpoint = [2001:db8:ffff:ffff::ffff]:12345

Re: ghc 8.10.2 won't build haddock on i386

On Thu, Oct 29, 2020 at 10:23 PM Greg Steuck <greg@nest.cx> wrote:

> I believe I implemented this in
> https://github.com/blackgnezdo/ports/commit/3707bd2f19dd4479f4a215aadf33afed36a55f23
> Not entirely sure if it is correct as I only ran it through some
> incremetal experiments and complete builds
> are still underway.
>

This stuff is nearly impossible to get right the first time. Now I tested
it completely on both amd64 and i386.
https://github.com/blackgnezdo/ports/commit/797790009486f9201558d14540bf678d60a52117

The evolving tree is here:
https://github.com/blackgnezdo/ports/commits/pfrag-ghc
It is up to date with the most recent cabal 3.4-rc5. A minor nit in xmobar
port has also been resolved by the upstream release.

Still yearning for feedback :)

Thanks
Greg
--
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0

sparc64 bulk build report

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

Started : Thu Oct 29 22:35:16 MDT 2020
Finished: Sat Oct 31 15:18:25 MDT 2020
Duration: 1 Days 16 hours 43 minutes

Built using OpenBSD 6.8-current (GENERIC.MP) #539: Thu Oct 29 06:21:39 MDT 2020

Built 8089 packages

Number of packages built each day:
Oct 29: 1588
Oct 30: 6004
Oct 31: 497

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

Build failures: 9
http://build-failures.rhaalovely.net/sparc64/2020-10-29/devel/libvmime.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/devel/spidermonkey78.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/math/py-scikit-learn,python3.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/sysutils/dwdiff.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/sysutils/libvirt.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/textproc/libical.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/textproc/py-ICU.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/www/purritobin.log
http://build-failures.rhaalovely.net/sparc64/2020-10-29/x11/picom.log

Recurrent failures:
failures/devel/spidermonkey78.log
failures/sysutils/libvirt.log
failures/www/purritobin.log
failures/x11/picom.log

New failures:
+failures/devel/libvmime.log
+failures/math/py-scikit-learn,python3.log
+failures/sysutils/dwdiff.log
+failures/textproc/libical.log
+failures/textproc/py-ICU.log

Resolved failures:
-failures/security/suricata.log

Packages newly built:
+databases/py-whisper,python3
+devel/arduino-esp32
+devel/p5-IO-Interactive
+devel/xtensa-esp32-elf/binutils
+devel/xtensa-esp32-elf/gcc
+devel/xtensa-esp32-elf/gcc-bootstrap
+devel/xtensa-esp32-elf/gdb
+devel/xtensa-esp32-elf/newlib
+lang/janet
+net/py-rrdtool,python3
+security/suricata
+sysutils/py-threadpoolctl,python3

Packages not built this time:
-devel/libvmime
-games/spacehulk
-graphics/k3dsurf
-math/py-scikit-learn,python3
-net/rrdtool,-python
-sysutils/dwdiff
-sysutils/py-croniter
-sysutils/py-croniter,python3
-textproc/libical
-textproc/libical,-glib
-textproc/libical,-main
-textproc/py-ICU
-textproc/py-ICU,python3
-textproc/py-natsort

games/dMagnetic 0.25 -> 0.26 (Now it can load Amstrad CPC binaries)

--- Makefile.orig 2020-10-31 20:17:32.019290208 +0100
+++ Makefile 2020-10-31 20:17:32.023237365 +0100
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile,v 1.13 2020/07/26 16:47:51 sthen Exp $

-V = 0.25
+V = 0.26
COMMENT = interpreter for Magnetic Scrolls games
DISTNAME = dMagnetic_${V}
PKGNAME = dmagnetic-${V}
--- distinfo.orig 2020-10-31 20:17:32.023237365 +0100
+++ distinfo 2020-10-31 20:17:32.027184522 +0100
@@ -1,2 +1,2 @@
-SHA256 (dMagnetic_0.25.tar.bz2) = XL4q7n6IcGKOrq8v4/xVDzFzb+YXiXZIp3KDvmo4Hm0=
-SIZE (dMagnetic_0.25.tar.bz2) = 68283
+SHA256 (dMagnetic_0.26.tar.bz2) = gemINv/jzJScMMs46O8vyK5+gOQ/8DPBfW8Goh9EtfA=
+SIZE (dMagnetic_0.26.tar.bz2) = 72758
Hello.

My project dMagnetic saw release 0.26. With this one, it is possible to
play the original Amstrad CPC releases of "The Pawn", "The Guild of
Thieves",
"Jinxter" and "Corruption".

I took the liberty of updating the port for OpenBSD. Please find the patch
attached to this Email. Hopefully, it meets your standards.

Thomas Dettbarn

Re: Unmaze Qt4 from x11/qwt

On Sat, Oct 31, 2020 at 06:39:49PM +0100, Rafael Sadowski wrote:
> On Fri Mar 13, 2020 at 09:58:29PM +0100, Rafael Sadowski wrote:
> > Is anyone willing to make x11/qwt qt5 only without -common etc.? The
> > difficult part is to set the right @pkgpath/@conflict.. foo and thus
> > enable a pkg_add update.
> >
> > No more customers available for the Qt4 (main) parts, only Qt5.
> >
> > I'm looking forward to test diff.
> >
> > Rafael Sadowski
> >
>
> Here is my final version. I've adjusted gnuradio and qgis.
> The pkg_add upgrade process looks ok, right?

reads good to me, thanks for this cleanup !

Re: Unmaze Qt4 from x11/qwt

On Fri Mar 13, 2020 at 09:58:29PM +0100, Rafael Sadowski wrote:
> Is anyone willing to make x11/qwt qt5 only without -common etc.? The
> difficult part is to set the right @pkgpath/@conflict.. foo and thus
> enable a pkg_add update.
>
> No more customers available for the Qt4 (main) parts, only Qt5.
>
> I'm looking forward to test diff.
>
> Rafael Sadowski
>

Here is my final version. I've adjusted gnuradio and qgis.
The pkg_add upgrade process looks ok, right?

$ TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all pkg_add -u
boost-1.67.0p1->1.67.0p1: ok
gnuradio-3.8.2.0p0:python-3.8.6p0->3.8.6p0: ok
qwt-6.1.3p2-qt5+qwt-common-6.1.3p2->qwt-6.1.5 forward dependencies:
| Dependency of gnuradio-3.8.2.0 on qwt-*-qt5 doesn't match
| Dependency of qgis-3.16.0 on qwt-*-qt5 doesn't match
Merging gnuradio-3.8.2.0->3.8.2.0p0 (ok)
Merging qgis-3.16.0->3.16.0p0 (ok)
gnuradio-3.8.2.0p0+qgis-3.1...:qtconnectivity-5.13.2->5.13.2: ok
gnuradio-3.8.2.0p0+qgis-3.1...:py3-qt5-5.13.2p0->5.13.2p0: ok
gnuradio-3.8.2.0p0+qgis-3.1...:qscintilla-2.11.4p2->2.11.4p2: ok
gnuradio-3.8.2.0p0+qgis-3.1...:py3-qscintilla-2.11.4p3->2.11.4p3: ok
gnuradio-3.8.2.0+qgis-3.16.0+qwt-6.1.3p2-qt5+qwt-common-6.1.3p2->gnuradio-3.8.2.0p0+qgis-3.16.0p0+qwt-6.1.5: ok
Running tags: ok

Feedback, concerns?

Rafael

diff --git a/comms/gnuradio/Makefile b/comms/gnuradio/Makefile
index 12bb35dc35a..7a2c371847c 100644
--- a/comms/gnuradio/Makefile
+++ b/comms/gnuradio/Makefile
@@ -4,6 +4,7 @@ COMMENT = signal-processing toolkit for SDR (software-defined radio)

V = 3.8.2.0
DISTNAME = gnuradio-$V
+REVISION = 0

SHARED_LIBS += gnuradio-analog 0.0 # 3.7
SHARED_LIBS += gnuradio-atsc 0.0 # 3.7
@@ -41,7 +42,7 @@ WANTLIB += Qt5Core Qt5Gui Qt5Widgets SDL boost_atomic-mt boost_chrono-mt
WANTLIB += boost_date_time-mt boost_filesystem-mt boost_program_options-mt
WANTLIB += boost_regex-mt boost_system-mt boost_thread-mt c fftw3f
WANTLIB += fftw3f_threads gmp gmpxx gsl gslcblas gsm iconv jack
-WANTLIB += log4cpp m orc-0.4 portaudio qwt-qt5 zmq
+WANTLIB += log4cpp m orc-0.4 portaudio qwt zmq

MASTER_SITES = https://github.com/gnuradio/gnuradio/releases/download/v$V/

@@ -92,7 +93,7 @@ LIB_DEPENDS = audio/jack \
devel/sdl \
math/fftw3,float \
net/zeromq \
- x11/qwt,qt5
+ x11/qwt

CONFIGURE_ARGS =-DENABLE_DOXYGEN=OFF \
-DENABLE_GR_UHD=OFF \
diff --git a/geo/qgis/Makefile b/geo/qgis/Makefile
index a419dad45e3..9ac6e6c4d43 100644
--- a/geo/qgis/Makefile
+++ b/geo/qgis/Makefile
@@ -11,6 +11,7 @@ DISTNAME = qgis-3.16.0
EXTRACT_SUFX = .tar.bz2
CATEGORIES = geo x11
DEBUG_PACKAGES =${BUILD_PACKAGES}
+REVISION = 0

SHARED_LIBS = qgis_core 45.0 \
qgis_app 31.0 \
@@ -70,7 +71,7 @@ LIB_DEPENDS = ${MODPY_LIB_DEPENDS} \
www/fcgi \
x11/qt5/qtwebkit \
x11/qt5/qt3d \
- qwt-*-qt5:x11/qwt,qt5 \
+ x11/qwt \
geo/gdal \
geo/mdal>=0.5 \
geo/geos \
@@ -84,7 +85,7 @@ WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5Gui Qt5Network
WANTLIB += Qt5Positioning Qt5PrintSupport Qt5Sql Qt5Svg
WANTLIB += Qt5Test Qt5WebKit Qt5WebKitWidgets Qt5Widgets Qt5Xml
WANTLIB += c exiv2 expat fcgi gdal geos_c gsl gslcblas m mdal pq proj ${MODPY_WANTLIB}
-WANTLIB += qca-qt5 qscintilla2_qt5 qt5keychain qwt-qt5 spatialindex
+WANTLIB += qca-qt5 qscintilla2_qt5 qt5keychain qwt spatialindex
WANTLIB += spatialite sqlite3 util zip hdf5 xml2 z GL
WANTLIB += Qt53DCore Qt53DExtras Qt53DInput Qt53DLogic
WANTLIB += Qt53DRender Qt5Gamepad protobuf-lite
diff --git a/x11/qwt/Makefile b/x11/qwt/Makefile
index 0c9f1c089c2..a9a5d5b971a 100644
--- a/x11/qwt/Makefile
+++ b/x11/qwt/Makefile
@@ -1,64 +1,37 @@
# $OpenBSD: Makefile,v 1.29 2019/07/12 20:51:20 sthen Exp $

-COMMENT-main = Qt Widgets for Technical Applications
-COMMENT-common = common files for the qwt packages
+COMMENT= Qt widgets for technical applications

-VERSION = 6.1.3
-DISTNAME = qwt-${VERSION}
-SHARED_LIBS = qwt${QTLIBSUFFIX} 7.0
-PKGNAME-main = qwt-${VERSION}
-FULLPKGNAME-common = qwt-common-${VERSION}
-FULLPKGPATH-common = x11/qwt,-common
-REVISION = 2
+VERSION = 6.1.5
+DISTNAME = qwt-${VERSION}

-CATEGORIES = x11
-EXTRACT_SUFX = .tar.bz2
+SHARED_LIBS = qwt${QTLIBSUFFIX} 7.0

-HOMEPAGE = http://qwt.sourceforge.net/
+CATEGORIES = x11

-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=qwt/}
+HOMEPAGE = http://qwt.sourceforge.net/
+
+MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=qwt/}
+EXTRACT_SUFX = .tar.bz2

# Qwt License, Version 1.0
# http://qwt.sourceforge.net/qwtlicense.html
PERMIT_PACKAGE = Yes

-MODULES = devel/qmake
+WANTLIB += Qt5Gui Qt5OpenGL Qt5PrintSupport Qt5Svg Qt5Widgets
+WANTLIB += Qt5Xml m
+
+MODULES = x11/qt5 \
+ devel/qmake
+
MODQMAKE_INSTALL_ROOT =
-NO_TEST = Yes
-USE_GMAKE = Yes
-MULTI_PACKAGES= -main -common
-FLAVORS = qt5
-FLAVOR ?=
-
-COMPILER = base-clang ports-gcc base-gcc
-
-.if ${FLAVOR:Mqt5}
-PKGSPEC-main = qwt-*-qt5
-MODULES += x11/qt5
-QTVER = qt5
-QTLIBSUFFIX = -${QTVER}
-LIB_DEPENDS += x11/qt5/qtsvg \
- x11/qt5/qttools
-WANTLIB-main += GL Qt5Concurrent Qt5Core Qt5Designer Qt5Gui Qt5OpenGL
-WANTLIB-main += Qt5PrintSupport Qt5Svg Qt5Widgets Qt5Xml
-.else
-PKGSPEC-main = qwt-*-!qt5
-MODULES += x11/qt4
-QTVER = qt4
-QTLIBSUFFIX = # empty
-WANTLIB-main += GL ICE QtDesigner QtGui QtOpenGL QtScript QtSvg QtXml SM X11 Xext Xi
-WANTLIB-main += Xinerama Xrender fontconfig freetype pthread QtCore
-.endif
-
-WANTLIB-main += ${COMPILER_LIBCXX} m
-
-WANTLIB-common = # empty
-RUN_DEPENDS-common = # empty
-LIB_DEPENDS-common = # empty
-PKG_ARCH-common= *
-
-RUN_DEPENDS = ${FULLPKGPATH-common}

+NO_TEST = Yes
+USE_GMAKE = Yes
+
+LIB_DEPENDS = x11/qt5/qtsvg
+
+QTVER = qt5
SUBST_VARS = WRKINST QTVER QTLIBSUFFIX

pre-configure:
@@ -66,12 +39,11 @@ pre-configure:
${WRKSRC}/designer/designer.pro \
${WRKSRC}/textengines/textengines.pri \
${WRKSRC}/src/src.pro
-
post-configure:
-# ensure CXXFLAGS/-std=c++11 is passed to all clang++ invocations,including the ones generating dependencies
-.if ${FLAVOR:Mqt5}
- sed -i -e 's/@$$(CXX) -M/@$$(CXX) $$(CXXFLAGS) -M/' ${WRKBUILD}/{src,designer}/Makefile
-.endif
+ # ensure CXXFLAGS/-std=c++11 is passed to all clang++
+ # invocations,including the ones generating dependencies
+ sed -i -e 's/@$$(CXX) -M/@$$(CXX) $$(CXXFLAGS) -M/' \
+ ${WRKBUILD}/{src,designer}/Makefile

post-install:
rm -rf ${PREFIX}/share/doc/qwt/html/*.md5
diff --git a/x11/qwt/distinfo b/x11/qwt/distinfo
index 8b1831883d5..f28e6d54bb4 100644
--- a/x11/qwt/distinfo
+++ b/x11/qwt/distinfo
@@ -1,2 +1,2 @@
-SHA256 (qwt-6.1.3.tar.bz2) = 8+zTTnKporCEIvtsjpCcp29M5fp3rK16KIO3AfQwlzM=
-SIZE (qwt-6.1.3.tar.bz2) = 4245614
+SHA256 (qwt-6.1.5.tar.bz2) = QHbeY+wrXoQ3nd/r8nx7KbjckHTz234sph0RoditwEE=
+SIZE (qwt-6.1.5.tar.bz2) = 4408268
diff --git a/x11/qwt/patches/patch-designer_designer_pro b/x11/qwt/patches/patch-designer_designer_pro
deleted file mode 100644
index 62557ee05e0..00000000000
--- a/x11/qwt/patches/patch-designer_designer_pro
+++ /dev/null
@@ -1,14 +0,0 @@
-$OpenBSD: patch-designer_designer_pro,v 1.4 2018/05/28 18:47:00 landry Exp $
-
-Index: designer/designer.pro
---- designer/designer.pro.orig
-+++ designer/designer.pro
-@@ -84,7 +84,7 @@ contains(QWT_CONFIG, QwtDesigner) {
- # into the plugin. Not supported on Windows !
-
- QMAKE_RPATHDIR *= $${QWT_INSTALL_LIBS}
-- qwtAddLibrary($${QWT_OUT_ROOT}/lib, qwt)
-+ qwtAddLibrary($${QWT_OUT_ROOT}/lib, qwt${QTLIBSUFFIX})
-
- contains(QWT_CONFIG, QwtDll) {
-
diff --git a/x11/qwt/patches/patch-qwt_prf b/x11/qwt/patches/patch-qwt_prf
deleted file mode 100644
index ca162855bc5..00000000000
--- a/x11/qwt/patches/patch-qwt_prf
+++ /dev/null
@@ -1,11 +0,0 @@
-$OpenBSD: patch-qwt_prf,v 1.1 2018/05/28 18:47:00 landry Exp $
-
-Index: qwt.prf
---- qwt.prf.orig
-+++ qwt.prf
-@@ -34,4 +34,4 @@ else {
- }
-
- # QMAKE_RPATHDIR *= $${QWT_INSTALL_LIBS}
--qwtAddLibrary($${QWT_INSTALL_LIBS}, qwt)
-+qwtAddLibrary($${QWT_INSTALL_LIBS}, qwt${QTLIBSUFFIX})
diff --git a/x11/qwt/patches/patch-qwtconfig_pri b/x11/qwt/patches/patch-qwtconfig_pri
index 1e37c9f3386..03362b706c9 100644
--- a/x11/qwt/patches/patch-qwtconfig_pri
+++ b/x11/qwt/patches/patch-qwtconfig_pri
@@ -31,7 +31,7 @@ Index: qwtconfig.pri
# linux distributors often organize the Qt installation
# their way and QT_INSTALL_PREFIX doesn't offer a good
@@ -63,7 +63,7 @@ QWT_INSTALL_PLUGINS = $${QWT_INSTALL_PREFIX}/plugins
- # with every Qt upgrade.
+ # with every Qt upgrade.
######################################################################

-QWT_INSTALL_FEATURES = $${QWT_INSTALL_PREFIX}/features
diff --git a/x11/qwt/patches/patch-src_src_pro b/x11/qwt/patches/patch-src_src_pro
deleted file mode 100644
index 983d6c5021e..00000000000
--- a/x11/qwt/patches/patch-src_src_pro
+++ /dev/null
@@ -1,14 +0,0 @@
-$OpenBSD: patch-src_src_pro,v 1.4 2018/05/28 18:47:00 landry Exp $
-
-Index: src/src.pro
---- src/src.pro.orig
-+++ src/src.pro
-@@ -17,7 +17,7 @@ include( $${QWT_ROOT}/qwtfunctions.pri )
- QWT_OUT_ROOT = $${OUT_PWD}/..
-
- TEMPLATE = lib
--TARGET = $$qwtLibraryTarget(qwt)
-+TARGET = $$qwtLibraryTarget(qwt${QTLIBSUFFIX})
-
- DESTDIR = $${QWT_OUT_ROOT}/lib
-
diff --git a/x11/qwt/patches/patch-textengines_textengines_pri b/x11/qwt/patches/patch-textengines_textengines_pri
deleted file mode 100644
index fad51545b21..00000000000
--- a/x11/qwt/patches/patch-textengines_textengines_pri
+++ /dev/null
@@ -1,14 +0,0 @@
-$OpenBSD: patch-textengines_textengines_pri,v 1.1 2018/05/28 18:47:00 landry Exp $
-
-Index: textengines/textengines.pri
---- textengines/textengines.pri.orig
-+++ textengines/textengines.pri
-@@ -34,7 +34,7 @@ contains(QWT_CONFIG, QwtFramework) {
- CONFIG += lib_bundle
- }
-
--qwtAddLibrary($${QWT_OUT_ROOT}/lib, qwt)
-+qwtAddLibrary($${QWT_OUT_ROOT}/lib, qwt${QTLIBSUFFIX})
-
- # Install directives
-
diff --git a/x11/qwt/pkg/DESCR-main b/x11/qwt/pkg/DESCR
similarity index 100%
rename from x11/qwt/pkg/DESCR-main
rename to x11/qwt/pkg/DESCR
diff --git a/x11/qwt/pkg/DESCR-common b/x11/qwt/pkg/DESCR-common
deleted file mode 100644
index 2417f828a17..00000000000
--- a/x11/qwt/pkg/DESCR-common
+++ /dev/null
@@ -1 +0,0 @@
-Common files for the qwt packages.
diff --git a/x11/qwt/pkg/PFRAG.no-qt5-main b/x11/qwt/pkg/PFRAG.no-qt5-main
deleted file mode 100644
index 78c6592a198..00000000000
--- a/x11/qwt/pkg/PFRAG.no-qt5-main
+++ /dev/null
@@ -1,4 +0,0 @@
-@comment $OpenBSD: PFRAG.no-qt5-main,v 1.1 2018/05/28 18:47:00 landry Exp $
-@conflict qwt-*-!qt5
-@pkgpath x11/qwt
-@lib lib/libqwt${QTLIBSUFFIX}.so.${LIBqwt_VERSION}
diff --git a/x11/qwt/pkg/PFRAG.qt5-main b/x11/qwt/pkg/PFRAG.qt5-main
deleted file mode 100644
index 67bcb7ba91b..00000000000
--- a/x11/qwt/pkg/PFRAG.qt5-main
+++ /dev/null
@@ -1,4 +0,0 @@
-@comment $OpenBSD: PFRAG.qt5-main,v 1.1 2018/05/28 18:47:00 landry Exp $
-@conflict qwt-*-qt5
-@pkgpath x11/qwt,qt5
-@lib lib/libqwt${QTLIBSUFFIX}.so.${LIBqwt-qt5_VERSION}
diff --git a/x11/qwt/pkg/PLIST-common b/x11/qwt/pkg/PLIST
similarity index 98%
rename from x11/qwt/pkg/PLIST-common
rename to x11/qwt/pkg/PLIST
index 9a5cf013607..b370f47e2b5 100644
--- a/x11/qwt/pkg/PLIST-common
+++ b/x11/qwt/pkg/PLIST
@@ -1,5 +1,10 @@
-@comment $OpenBSD: PLIST-common,v 1.1 2018/05/28 18:47:00 landry Exp $
-@conflict qwt-<6.1.3p0
+@comment $OpenBSD: PLIST,v$
+@conflict qwt-<6.1.5
+@conflict qwt-common-<6.1.5
+@conflict qwt-*-qt5
+@pkgpath x11/qwt,-main
+@pkgpath x11/qwt,-common
+@pkgpath x11/qwt,-main,qt5
include/qwt.h
include/qwt_abstract_legend.h
include/qwt_abstract_scale.h
@@ -98,6 +103,16 @@ include/qwt_thermo.h
include/qwt_transform.h
include/qwt_wheel.h
include/qwt_widget_overlay.h
+@lib lib/libqwt.so.${LIBqwt_VERSION}
+lib/${QTVER}/
+lib/${QTVER}/mkspecs/
+lib/${QTVER}/mkspecs/features/
+lib/${QTVER}/mkspecs/features/qwt.prf
+lib/${QTVER}/mkspecs/features/qwtconfig.pri
+lib/${QTVER}/mkspecs/features/qwtfunctions.pri
+lib/${QTVER}/plugins/
+lib/${QTVER}/plugins/designer/
+@so lib/${QTVER}/plugins/designer/libqwt_designer_plugin.so
@man man/man3/QwtAbstractLegend.3
@man man/man3/QwtAbstractScale.3
@man man/man3/QwtAbstractScaleDraw.3
@@ -231,9 +246,6 @@ include/qwt_widget_overlay.h
@man man/man3/QwtWeedingCurveFitter.3
@man man/man3/QwtWheel.3
@man man/man3/QwtWidgetOverlay.3
-@man man/man3/_tmp_qwt-6.1.3-tmp_src_.3
-@man man/man3/_tmp_qwt-6.1.3-tmp_textengines_.3
-@man man/man3/_tmp_qwt-6.1.3-tmp_textengines_mathml_.3
@man man/man3/barchartscreenshots.3
@man man/man3/controlscreenshots.3
@man man/man3/curvescreenshots.3
@@ -244,11 +256,15 @@ include/qwt_widget_overlay.h
@man man/man3/spectrogramscreenshots.3
share/doc/qwt/
share/doc/qwt/html/
+share/doc/qwt/html/_form0.eps
+share/doc/qwt/html/_form0.ps
+share/doc/qwt/html/_formulas.aux
+share/doc/qwt/html/_formulas.dvi
+share/doc/qwt/html/_formulas.log
+share/doc/qwt/html/_formulas.tex
share/doc/qwt/html/analogclock.png
share/doc/qwt/html/annotated.html
share/doc/qwt/html/annotated_dup.js
-share/doc/qwt/html/arrowdown.png
-share/doc/qwt/html/arrowright.png
share/doc/qwt/html/barchart-grouped-600x400.png
share/doc/qwt/html/barchart-stacked-600x400.png
share/doc/qwt/html/barchartscreenshots.html
@@ -887,17 +903,9 @@ share/doc/qwt/html/doxygen.png
share/doc/qwt/html/dynsections.js
share/doc/qwt/html/folderclosed.png
share/doc/qwt/html/folderopen.png
-share/doc/qwt/html/form_0.png
-share/doc/qwt/html/form_1.png
-share/doc/qwt/html/form_2.png
-share/doc/qwt/html/form_3.png
-share/doc/qwt/html/form_4.png
-share/doc/qwt/html/form_5.png
-share/doc/qwt/html/formula.repository
share/doc/qwt/html/friedberg-bars-600x400.png
share/doc/qwt/html/friedberg-tube-600x400.png
share/doc/qwt/html/functions.html
-share/doc/qwt/html/functions_0x7e.html
share/doc/qwt/html/functions_b.html
share/doc/qwt/html/functions_c.html
share/doc/qwt/html/functions_d.html
@@ -932,7 +940,6 @@ share/doc/qwt/html/functions_eval_y.html
share/doc/qwt/html/functions_f.html
share/doc/qwt/html/functions_func.html
share/doc/qwt/html/functions_func.js
-share/doc/qwt/html/functions_func_0x7e.html
share/doc/qwt/html/functions_func_b.html
share/doc/qwt/html/functions_func_c.html
share/doc/qwt/html/functions_func_d.html
@@ -956,6 +963,7 @@ share/doc/qwt/html/functions_func_w.html
share/doc/qwt/html/functions_func_x.html
share/doc/qwt/html/functions_func_y.html
share/doc/qwt/html/functions_func_z.html
+share/doc/qwt/html/functions_func_~.html
share/doc/qwt/html/functions_g.html
share/doc/qwt/html/functions_h.html
share/doc/qwt/html/functions_i.html
@@ -977,6 +985,7 @@ share/doc/qwt/html/functions_w.html
share/doc/qwt/html/functions_x.html
share/doc/qwt/html/functions_y.html
share/doc/qwt/html/functions_z.html
+share/doc/qwt/html/functions_~.html
share/doc/qwt/html/graph_legend.html
share/doc/qwt/html/graph_legend.png
share/doc/qwt/html/hierarchy.html
@@ -1089,6 +1098,8 @@ share/doc/qwt/html/inherits.html
share/doc/qwt/html/itemeditor-600x400.png
share/doc/qwt/html/jquery.js
share/doc/qwt/html/knob.png
+share/doc/qwt/html/menu.js
+share/doc/qwt/html/menudata.js
share/doc/qwt/html/nav_f.png
share/doc/qwt/html/nav_g.png
share/doc/qwt/html/nav_h.png
diff --git a/x11/qwt/pkg/PLIST-main b/x11/qwt/pkg/PLIST-main
deleted file mode 100644
index 00de4f5bff2..00000000000
--- a/x11/qwt/pkg/PLIST-main
+++ /dev/null
@@ -1,10 +0,0 @@
-@comment $OpenBSD: PLIST-main,v 1.1 2018/05/28 18:47:00 landry Exp $
-@option no-default-conflict
-@conflict qwt-<6.1.3p0
-!%%qt5%%
-%%qt5%%
-lib/${QTVER}/mkspecs/features/qwt.prf
-lib/${QTVER}/mkspecs/features/qwtconfig.pri
-lib/${QTVER}/mkspecs/features/qwtfunctions.pri
-lib/${QTVER}/plugins/designer/
-lib/${QTVER}/plugins/designer/libqwt_designer_plugin.so

Re: Are relayd and httpd my future buddy?

https://www.amazon.com/Relayd-Httpd-Mastery-Book-11-ebook/dp/B07171352M
Good book.
Edgar

On Oct 31, 2020 11:45 AM, Brian Brombacher <brian@planetunix.net> wrote:

> On Oct 30, 2020, at 6:32 PM, Lars Bonnesen
<lars.bonnesen@gmail.com> wrote:
>
> I have been using a combination of Apache, mod_proxy and
letsencrypt to set
> up different loadbalancing/https offload solution like this:
>
> https://URL1 [Apache
http_1]
> ---|
> https://URL2 [Apache https, mod_proxy, and letsencrypt] --- [Apache
http_2}
> ---|-- SQL
> https://URL3 [Apache
http_3]
> ---|
>
> Of coarse running on OpenBSD
>
> The URLS are typically sharing one IP and in theory the https
offload could
> also be load balanced.
>
> Even though the above setup works, I would like to use as much of
obsd base
> as possible and less packages. Thinking of httpd, letsencrypt and
relayd -
> but can it accomplish my goals about sharing IPs, loadbalancing
while also
> doing SSL offload? Or do I need to stick with Apache or maybe look
at
> another solution like haproxy?
>
> If I can use relayd for this, could someone please share a
relayd.conf
> example for me?
>
> Regards, Lars.

If you're only using mod_proxy for load balancing, yes you can do
this with httpd and relayd.

I don't have a relayd.conf sample for you but there are plenty from
the mailing list.

Re: assembler error on trying to port OpenBLAS

On 10/29/20 8:25 PM, Aisha Tammy wrote:
> Hi,
> I'm trying to port OpenBLAS to the tree and am currently getting
> some weird assembler errors (port makefile is attached at end math/openblas)
>
> ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages:
> ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)'
> ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper '
>
>
> Presumably this is happening due to the assembler being used is
> the one from base as we don't build the ports egcc with gas for
> anything except aarch64 and arm.
> I'm kind of stumped here as it seems like using gfortran sets the
> compiler to egcc (compiling the above file with cc works).
> Is it possible to mix gfortran with base-clang C compiler?
> Another (possible) solution would be to build egcc all archs with
> the new gas assembler, but that sounds a lot more dangerous and I
> don't know enough to know if that is possible/or even a good idea/
> or if it will even work :-/
>
> Any pointers would be cool to have.
> (I've cc'ed pascal@ as they are the maintainer for gcc port and
> can be better suited to answer the second point of gas)
>
> Thanks,
> Aisha
>
>
> # $OpenBSD $
>
> COMMENT    =    optimized BLAS/LAPACK library based on GotoBLAS
> PKGNAME =    ${DISTNAME:L}
> CATEGORIES =    math
>
> GH_ACCOUNT =    xianyi
> GH_PROJECT =    OpenBLAS
> GH_TAGNAME =    v0.3.12
>
> SHARED_LIBS =    openblas 0.0 \
>         blas 7.2 \
>         cblas 7.2 \
>         lapack 7.2 \
>         lapacke 7.2
>
> MAINTAINER =    Aisha Tammy <openbsd@aisha.cc>
>
> # BSD
> PERMIT_PACKAGE =    Yes
>
> WANT_LIB +=    c m pthread
>
> MODULES =    fortran
> MODFORTRAN_COMPILER =    gfortran
>
> USE_GMAKE =    Yes
>
> MAKE_ENV =    CFLAGS="${CFLAGS}" FFLAGS="${CFLAGS}" \
>         LIBopenblas_VERSION="${LIBopenblas_VERSION}" \
>         LIBblas_VERSION="${LIBblas_VERSION}" \
>         LIBcblas_VERSION="${LIBcblas_VERSION}" \
>         LIBlapack_VERSION="${LIBlapack_VERSION}" \
>         LIBlapacke_VERSION="${LIBlapacke_VERSION}" \
>         USE_THREAD=1 USE_OPENMP=0 \
>         NUM_PARALLEL=8 \
>         NUM_THREADS=64 \
>         MAKE_NB_JOBS=-1 \
>         DYNAMIC_ARCH=1 \
>         TARGET=GENERIC \
>         NO_AFFINITY=1 \
>         NO_STATIC=0 \
>         BUILD_RELAPACK=1
>
> .include <bsd.port.mk>
>

Thanks for the people who commented.
I've managed to fix the error by forcing the
COMPILER_LINKS = cc /usr/bin/cc gcc /usr/bin/gcc

This managed to build OpenBLAS. I'm currently working
on getting the tests to run.

Best,
Aisha

Re: Are relayd and httpd my future buddy?

> On Oct 30, 2020, at 6:32 PM, Lars Bonnesen <lars.bonnesen@gmail.com> wrote:
>
> I have been using a combination of Apache, mod_proxy and letsencrypt to set
> up different loadbalancing/https offload solution like this:
>
> https://URL1 [Apache http_1]
> ---|
> https://URL2 [Apache https, mod_proxy, and letsencrypt] --- [Apache http_2}
> ---|-- SQL
> https://URL3 [Apache http_3]
> ---|
>
> Of coarse running on OpenBSD
>
> The URLS are typically sharing one IP and in theory the https offload could
> also be load balanced.
>
> Even though the above setup works, I would like to use as much of obsd base
> as possible and less packages. Thinking of httpd, letsencrypt and relayd -
> but can it accomplish my goals about sharing IPs, loadbalancing while also
> doing SSL offload? Or do I need to stick with Apache or maybe look at
> another solution like haproxy?
>
> If I can use relayd for this, could someone please share a relayd.conf
> example for me?
>
> Regards, Lars.

If you're only using mod_proxy for load balancing, yes you can do this with httpd and relayd.

I don't have a relayd.conf sample for you but there are plenty from the mailing list.

Re: New: fna - FNA framework for fnaify games

re-ping

On Tue, Oct 20, 2020 at 04:46:32AM -0600, Thomas Frohwein wrote:
> ping
>
> On Thu, Oct 08, 2020 at 03:46:01AM -0600, Thomas Frohwein wrote:
> > Hi,
> >
> > This is a port of the .NET FNA libraries - the core FNA.dll, as well as
> > the XNA bridge files. Until recently, games/fnaify was mostly able to
> > use whatever version of FNA.dll came bundled with the games. However,
> > the recent update to graphics/mojoshader with API change, has made that
> > largely impossible.
> >
> > At this point, most of the games in the fnaify catalogue run with FNA
> > 20.09 and mojoshader in the ports. Therefore, I would like to switch
> > the strategy for handling the FNA.dll file from the bundled one to one
> > in ${LOCALBASE}/share/FNA/.
> >
> > fnaify is already looking for an existing FNA.dll in this directory
> > since the 3.0 update.
> >
> > This port can be tested with latest fnaify, for example with the free
> > XNA game Chaos Heart that can be downloaded at [1].
> >
> > The port includes FNA.NetStub and Vorbisfile-CS from their GitHub
> > repos, following the example of emulators/ppsspp for including the
> > additional sources. In addition, a customization of the build in
> > FNA.Settings.props is included that provides SDL2-image and Vorbisfile
> > bindings for broader compatibility.
> >
> > ok?
> >
> > [1] http://www.mattmakesgames.com/
>
>

Re: 回复: 回复: pysol doesn't run

Thank you, I shall look into it and create the new port for py-sol-card.

wen
________________________________
发件人: Daniel Dickman <didickman@gmail.com>
发送时间: 2020年10月30日 12:03
收件人: wen heping <wenheping2000@hotmail.com>
抄送: Daniel Dickman <didickman@gmail.com>; Carsten Boysen Jensen <mail@carstenboysenjensen.dk>; ports@openbsd.org <ports@openbsd.org>
主题: Re: 回复: 回复: pysol doesn't run

On Thu, 29 Oct 2020, wen heping wrote:

> Here is the patch to update games/pysol to 2.10.1.
>
> wen
>

Hi Wen, please try running "pysol". What happens? :-)

(See my previous notes on needing a new port for pysol_cards)

Re: NEW: net/i2p

On Fri Oct 30, 2020 at 07:11:26PM +0100, Solene Rapenne wrote:
> On Sat, 24 Oct 2020 17:06:41 -0000
> "Dimitri Karamazov" <deserter666@danwin1210.me>:
>
> > Ping
>
> Both ports looks fine to me.
>
> Now someone else need to review the ports and give their OK so we
> can import the ports into the tree.
>

OK rsadowski@

mips64 bulk build report

Re: UPDATE: Boost 1.70

On Fri Oct 30, 2020 at 09:04:53PM -0400, Daniel Dickman wrote:
>
>
> >
> > games/pokerth
> >
> > In file included from ../src/net/common/chatcleanermanager.cpp:32:
> > In file included from ../src/net/chatcleanermanager.h:36:
> > In file included from /usr/local/include/boost/asio.hpp:24:
> > In file included from /usr/local/include/boost/asio/basic_datagram_socket.hpp:20:
> > In file included from /usr/local/include/boost/asio/basic_socket.hpp:27:
> > In file included from /usr/local/include/boost/asio/executor.hpp:338:
> > /usr/local/include/boost/asio/impl/executor.hpp:179:22: error: no member named 'context' in 'std::__1::reference_wrapper<boost::asio::io_context>'
> >
> >
>
> Think diff below might fix this one. Sourced from archlinux.
>
> With this I was able to check that the game starts up.
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/games/pokerth/Makefile,v
> retrieving revision 1.47
> diff -u -p -u -r1.47 Makefile
> --- Makefile 20 Mar 2020 16:44:23 -0000 1.47
> +++ Makefile 31 Oct 2020 00:48:37 -0000
> @@ -5,7 +5,7 @@ COMMENT= texas hold'em poker game with o
> BROKEN-hppa = needs atomic ops
>
> DISTNAME = pokerth-1.1.2
> -REVISION = 5
> +REVISION = 6
>
> CATEGORIES= games x11
>
> Index: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp
> ===================================================================
> RCS file: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp
> diff -N patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp 31 Oct 2020 00:48:37 -0000
> @@ -0,0 +1,29 @@
> +$OpenBSD$
> +

If you commit this diff, please add a quick comment here. Thanks!

> +Index: src/third_party/websocketpp/websocketpp/transport/asio/connection.hpp
> +--- src/third_party/websocketpp/websocketpp/transport/asio/connection.hpp.orig
> ++++ src/third_party/websocketpp/websocketpp/transport/asio/connection.hpp
> +@@ -311,9 +311,10 @@ class connection : public config::socket_type::socket_
> + * needed.
> + */
> + timer_ptr set_timer(long duration, timer_handler callback) {
> +- timer_ptr new_timer = lib::make_shared<lib::asio::steady_timer>(
> +- lib::ref(*m_io_service),
> +- lib::asio::milliseconds(duration)
> ++ timer_ptr new_timer(
> ++ new lib::asio::steady_timer(
> ++ *m_io_service,
> ++ lib::asio::milliseconds(duration))
> + );
> +
> + if (config::enable_multithreading) {
> +@@ -461,8 +462,7 @@ class connection : public config::socket_type::socket_
> + m_io_service = io_service;
> +
> + if (config::enable_multithreading) {
> +- m_strand = lib::make_shared<lib::asio::io_service::strand>(
> +- lib::ref(*io_service));
> ++ m_strand.reset(new lib::asio::io_service::strand(*io_service));
> + }
> +
> + lib::error_code ec = socket_con_type::init_asio(io_service, m_strand,
> Index: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp
> ===================================================================
> RCS file: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp
> diff -N patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp 31 Oct 2020 00:48:37 -0000
> @@ -0,0 +1,36 @@
> +$OpenBSD$
> +
> +Index: src/third_party/websocketpp/websocketpp/transport/asio/endpoint.hpp
> +--- src/third_party/websocketpp/websocketpp/transport/asio/endpoint.hpp.orig
> ++++ src/third_party/websocketpp/websocketpp/transport/asio/endpoint.hpp
> +@@ -191,8 +191,7 @@ class endpoint : public config::socket_type { (public)
> +
> + m_io_service = ptr;
> + m_external_io_service = true;
> +- m_acceptor = lib::make_shared<lib::asio::ip::tcp::acceptor>(
> +- lib::ref(*m_io_service));
> ++ m_acceptor.reset(new lib::asio::ip::tcp::acceptor(*m_io_service));
> +
> + m_state = READY;
> + ec = lib::error_code();
> +@@ -660,9 +659,7 @@ class endpoint : public config::socket_type { (public)
> + * @since 0.3.0
> + */
> + void start_perpetual() {
> +- m_work = lib::make_shared<lib::asio::io_service::work>(
> +- lib::ref(*m_io_service)
> +- );
> ++ m_work.reset(new lib::asio::io_service::work(*m_io_service));
> + }
> +
> + /// Clears the endpoint's perpetual flag, allowing it to exit when empty
> +@@ -826,8 +823,7 @@ class endpoint : public config::socket_type { (public)
> +
> + // Create a resolver
> + if (!m_resolver) {
> +- m_resolver = lib::make_shared<lib::asio::ip::tcp::resolver>(
> +- lib::ref(*m_io_service));
> ++ m_resolver.reset(new lib::asio::ip::tcp::resolver(*m_io_service));
> + }
> +
> + tcon->set_uri(u);
> Index: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_none_hpp
> ===================================================================
> RCS file: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_none_hpp
> diff -N patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_none_hpp
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_none_hpp 31 Oct 2020 00:48:37 -0000
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +Index: src/third_party/websocketpp/websocketpp/transport/asio/security/none.hpp
> +--- src/third_party/websocketpp/websocketpp/transport/asio/security/none.hpp.orig
> ++++ src/third_party/websocketpp/websocketpp/transport/asio/security/none.hpp
> +@@ -168,8 +168,7 @@ class connection : public lib::enable_shared_from_this
> + return socket::make_error_code(socket::error::invalid_state);
> + }
> +
> +- m_socket = lib::make_shared<lib::asio::ip::tcp::socket>(
> +- lib::ref(*service));
> ++ m_socket.reset(new lib::asio::ip::tcp::socket(*service));
> +
> + m_state = READY;
> +
> Index: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_tls_hpp
> ===================================================================
> RCS file: patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_tls_hpp
> diff -N patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_tls_hpp
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_security_tls_hpp 31 Oct 2020 00:48:37 -0000
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +Index: src/third_party/websocketpp/websocketpp/transport/asio/security/tls.hpp
> +--- src/third_party/websocketpp/websocketpp/transport/asio/security/tls.hpp.orig
> ++++ src/third_party/websocketpp/websocketpp/transport/asio/security/tls.hpp
> +@@ -193,8 +193,7 @@ class connection : public lib::enable_shared_from_this
> + if (!m_context) {
> + return socket::make_error_code(socket::error::invalid_tls_context);
> + }
> +- m_socket = lib::make_shared<socket_type>(
> +- _WEBSOCKETPP_REF(*service),lib::ref(*m_context));
> ++ m_socket.reset(new socket_type(*service, *m_context));
> +
> + m_io_service = service;
> + m_strand = strand;
>

Friday, October 30, 2020

UPDATE: libsndfile 1.0.30 - CVE

Here is an update to libsndfile 1.0.30.

CVE-2017-12562, CVE-2017-17456, CVE-2017-17457, CVE-2018-19661, CVE-2018-19662,
CVE-2018-19758 and CVE-2019-3832.

Index: Makefile
===================================================================
RCS file: /cvs/ports/audio/libsndfile/Makefile,v
retrieving revision 1.33
diff -u -p -u -p -r1.33 Makefile
--- Makefile 12 Jul 2019 20:43:35 -0000 1.33
+++ Makefile 31 Oct 2020 05:07:55 -0000
@@ -2,31 +2,33 @@

COMMENT= library to handle various audio file formats

-DISTNAME= libsndfile-1.0.28
+DISTNAME= libsndfile-1.0.30
CATEGORIES= audio
+GH_ACCOUNT= libsndfile
+GH_PROJECT= libsndfile
+GH_TAGNAME= v1.0.30
+
HOMEPAGE= http://www.mega-nerd.com/libsndfile/
+
MAINTAINER= Jan Stary <hans@stare.cz>
-SHARED_LIBS += sndfile 6.0 # .1.28
+
+SHARED_LIBS += sndfile 7.0 # .1.28

# LGPLv2.1
PERMIT_PACKAGE= Yes

-MASTER_SITES= ${HOMEPAGE}files/
+WANTLIB= c m sndio FLAC ogg opus vorbis vorbisenc

-WANTLIB= c m sndio FLAC ogg vorbis vorbisenc
+MODULES= devel/cmake

-CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS= --disable-alsa \
- --disable-octave \
- --disable-sqlite
-
-CONFIGURE_ENV= CPPFLAGS="-I${PREFIX}/include"
-MODGNU_CONFIG_GUESS_DIRS=${WRKSRC}/Cfg
+CONFIGURE_ARGS= -DBUILD_SHARED_LIBS:BOOL=ON \
+ -DCMAKE_DISABLE_FIND_PACKAGE_ALSA:BOOL=True \
+ -DCMAKE_DISABLE_FIND_PACKAGE_Speex:BOOL=True \
+ -DCMAKE_DISABLE_FIND_PACKAGE_SQLite3:BOOL=True

LIB_DEPENDS= audio/flac \
audio/libogg \
- audio/libvorbis
-
-FAKE_FLAGS= htmldocdir=${PREFIX}/share/doc/libsndfile
+ audio/libvorbis \
+ audio/opus

.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/audio/libsndfile/distinfo,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 distinfo
--- distinfo 23 Apr 2018 08:48:54 -0000 1.17
+++ distinfo 31 Oct 2020 05:07:55 -0000
@@ -1,2 +1,2 @@
-SHA256 (libsndfile-1.0.28.tar.gz) = H/M5KfBC+jM67R6JI6pijD7p4euFUSaGxVCS0eWp36k=
-SIZE (libsndfile-1.0.28.tar.gz) = 1202833
+SHA256 (libsndfile-1.0.30.tar.gz) = WUK5Y9HbPtirH/uFcIMiqpY333bZ/oTh3+Sal6kOj0c=
+SIZE (libsndfile-1.0.30.tar.gz) = 650659
Index: patches/patch-CMakeLists_txt
===================================================================
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-CMakeLists_txt 31 Oct 2020 05:07:55 -0000
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
++++ CMakeLists.txt
+@@ -56,6 +56,7 @@ if (MSVC AND (CMAKE_VERSION VERSION_LESS 3.15))
+ endif ()
+ option (ENABLE_PACKAGE_CONFIG "Generate and install package config file" ON)
+ option (INSTALL_PKGCONFIG_MODULE "Generate and install pkg-config module" ON)
++option (INSTALL_MANPAGES "Install man pages for programs" ON)
+
+ list (APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
+
+@@ -74,7 +75,6 @@ if (NOT ENABLE_CPU_CLIP)
+ set (CPU_CLIPS_NEGATIVE FALSE)
+ endif ()
+ cmake_dependent_option (ENABLE_COMPATIBLE_LIBSNDFILE_NAME "Set DLL name to libsndfile-1.dll (canonical name), sndfile.dll otherwise" OFF "WIN32;BUILD_SHARED_LIBS" OFF)
+-cmake_dependent_option (INSTALL_MANPAGES "Install man pages for programs" ON "BUILD_PROGRAMS AND (UNIX OR MINGW OR CYGWIN)" OFF)
+
+ set (HAVE_EXTERNAL_XIPH_LIBS ${ENABLE_EXTERNAL_LIBS})
+ set (HAVE_SQLITE3 ${BUILD_REGTEST})
Index: patches/patch-configure
===================================================================
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 23 Apr 2018 08:48:54 -0000 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,16 +0,0 @@
-$OpenBSD: patch-configure,v 1.3 2018/04/23 08:48:54 jca Exp $
-
-Some compilers don't have -Wvla
-
-Index: configure
---- configure.orig
-+++ configure
-@@ -20828,7 +20828,7 @@ rm -f core conftest.err conftest.$ac_objext \
- common_flags="-Wcast-align -Wcast-qual -Wshadow -Wwrite-strings -Wundef -Wuninitialized -Winit-self"
-
- # -Winline -Wconversion "
-- CFLAGS="$CFLAGS $common_flags -Wbad-function-cast -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Waggregate-return -Wvla"
-+ CFLAGS="$CFLAGS $common_flags -Wbad-function-cast -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Waggregate-return"
- CXXFLAGS="$CXXFLAGS $common_flags -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wreorder -Wsign-promo"
-
- if test "x$enable_gcc_opt" = "xno" ; then
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/audio/libsndfile/pkg/PLIST,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 PLIST
--- pkg/PLIST 23 Apr 2018 08:48:54 -0000 1.13
+++ pkg/PLIST 31 Oct 2020 05:07:55 -0000
@@ -12,8 +12,12 @@
@bin bin/sndfile-salvage
include/sndfile.h
include/sndfile.hh
-lib/libsndfile.a
-lib/libsndfile.la
+lib/cmake/
+lib/cmake/SndFile/
+lib/cmake/SndFile/SndFileConfig.cmake
+lib/cmake/SndFile/SndFileConfigVersion.cmake
+lib/cmake/SndFile/SndFileTargets${MODCMAKE_BUILD_SUFFIX}
+lib/cmake/SndFile/SndFileTargets.cmake
@lib lib/libsndfile.so.${LIBsndfile_VERSION}
lib/pkgconfig/sndfile.pc
@man man/man1/sndfile-cmp.1
@@ -32,12 +36,14 @@ share/doc/libsndfile/api.html
share/doc/libsndfile/bugs.html
share/doc/libsndfile/command.html
share/doc/libsndfile/embedded_files.html
+share/doc/libsndfile/formats.html
share/doc/libsndfile/index.html
share/doc/libsndfile/libsndfile.css
share/doc/libsndfile/libsndfile.jpg
share/doc/libsndfile/lists.html
share/doc/libsndfile/new_file_type.HOWTO
share/doc/libsndfile/octave.html
+share/doc/libsndfile/print.css
share/doc/libsndfile/sndfile_info.html
share/doc/libsndfile/tutorial.html
share/doc/libsndfile/win32.html

Re: assembler error on trying to port OpenBLAS

On Fri, Oct 30, 2020 at 04:55:53PM +0000, Stuart Henderson wrote:
> On 2020/10/29 20:25, Aisha Tammy wrote:
> > I'm trying to port OpenBLAS to the tree and am currently getting
> > some weird assembler errors (port makefile is attached at end math/openblas)
>
> not that weird, the source code has inline asm, it is passed to
> /usr/bin/as which is pretty old and pre-dates support for this
> being added
>
> > Presumably this is happening due to the assembler being used is
> > the one from base as we don't build the ports egcc with gas for
> > anything except aarch64 and arm.
> > I'm kind of stumped here as it seems like using gfortran sets the
> > compiler to egcc (compiling the above file with cc works).
> > Is it possible to mix gfortran with base-clang C compiler?
> > Another (possible) solution would be to build egcc all archs with
> > the new gas assembler, but that sounds a lot more dangerous and I
> > don't know enough to know if that is possible/or even a good idea/
> > or if it will even work :-/
>
> I think ports/lang/gcc should start using the newer version of gas
> from ports on i386 and amd64.
>
> On these archs it doesn't affect many ports (fortran things,
> asterisk, seabios [vmm-firmware], maybe one or two others).
>
> For other archs there is higher risk as large parts of the ports
> tree use ports-gcc on most of these. But there's probably less need
> for the newer assembler on those too.

I had sent a diff like the following to Pascal last year. Since in the
past we had run into issues with inline asm and our GNU as being too old.

Index: Makefile
===================================================================
RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 Makefile
--- Makefile 4 Sep 2020 09:55:34 -0000 1.34
+++ Makefile 31 Oct 2020 03:08:05 -0000
@@ -18,6 +18,7 @@ DPB_PROPERTIES = parallel
V = 8.4.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
+REVISION = 0

ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
@@ -65,7 +66,8 @@ EXTRACT_ONLY = ${DISTNAME}.tar.xz
BUILD_DEPENDS += devel/bison \
devel/libexecinfo

-.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "arm"
+.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "amd64" || \
+ ${MACHINE_ARCH} == "arm" || ${MACHINE_ARCH} == "i386"
BUILD_DEPENDS += devel/gas
RUN_DEPENDS += devel/gas
RUN_DEPENDS-main += devel/gas

Re: handbrake-1.3.3 high CPU load while idle on amd64

Hello Morgan --

On Thursday, October 29, 2020 1:29 PM, Morgan Aldridge <morgant@makkintosshu.com> wrote:

> Hi Brian and @ports,
>
> Thanks for the HandBrake port. I'm seeing high CPU load with
> handbrake-1.3.3 on 6.8-stable amd64 while ghb is open and idle,
> starting at first launch. This is without opening any sources.
>
> Top shows high CPU load for gbh:
>
> 25307 1000 2 0 42M 69M onproc/1 poll 19:23 179.64% ghb
>
> And I ran a ktrace, which shows tight looping of the following:
>
> 25307 ghb 0.000011 CALL open(0x6c1edf35b40,0<O_RDONLY>)
>

Thanks for the report. I will try to find some time this weekend to
look at it.

~Brian

Re: UPDATE: Boost 1.70

On 10/30/2020 9:04 PM, Daniel Dickman wrote:
>
>> games/pokerth
>>
>> In file included from ../src/net/common/chatcleanermanager.cpp:32:
>> In file included from ../src/net/chatcleanermanager.h:36:
>> In file included from /usr/local/include/boost/asio.hpp:24:
>> In file included from /usr/local/include/boost/asio/basic_datagram_socket.hpp:20:
>> In file included from /usr/local/include/boost/asio/basic_socket.hpp:27:
>> In file included from /usr/local/include/boost/asio/executor.hpp:338:
>> /usr/local/include/boost/asio/impl/executor.hpp:179:22: error: no member named 'context' in 'std::__1::reference_wrapper<boost::asio::io_context>'
>>
>>
> Think diff below might fix this one. Sourced from archlinux.
>
> With this I was able to check that the game starts up.

I had just started looking into this port. This saves me time. Thanks!

Re: [maintainer update] py-setuptools 41.6.0 -> 44.1.1

On Fri, 30 Oct 2020, Kurt Mosiejczuk wrote:

> Ping. I've added py-packaging to TEST_DEPENDS to fix the issue daniel@ saw.
> (I don't see it because the tests using py-packaging don't run when using
> PORTS_PRIVSEP).
>
> So this went throught a sparc64 bulk without issues.
>
> ok?
>

seems like a good time in the release cycle to do this.

ok.