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)
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' > > > > > > 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/MakefileFri Mar 8 15:00:40 2019 > +++ pulseview.new/MakefileSat 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 > + > + #ifndef Q_MOC_RUN > ++#include > + #include > + #endif > + I had sent the following diff from upstream to the MAINTAINER. The diff you have, from the git hash, is based on what I have. I built with both versions. Index: Makefile === RCS file: /cvs/ports/comms/sigrok/pulseview/Makefile,v retrieving revision 1.4 diff -u -p -u -p -r1.4 Makefile --- Makefile8 Mar 2019 20:00:40 - 1.4 +++ Makefile30 Oct 2020 19:52:38 - @@ -1,7 +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 Index: patches/patch-pv_util_hpp === RCS file: patches/patch-pv_util_hpp diff -N patches/patch-pv_util_hpp --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-pv_util_hpp 30 Oct 2020 19:52:38 - @@ -0,0 +1,17 @@ +$OpenBSD$ + +pv/util.hpp: Workaround for a Boost::serialization / clang++-10 issue. + +Index: pv/util.hpp +--- pv/util.hpp.orig pv/util.hpp +@@ -25,6 +25,9 @@ + #include + + #ifndef Q_MOC_RUN ++// Workaround for https://github.com/boostorg/serialization/issues/186 ++#include ++ + #include + #endif +
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Thu Oct 29 04:54:03 MDT 2020 finished at Sat Oct 31 20:02:29 MDT 2020 lasted 2D15h08m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #873: Thu Oct 29 01:43:00 MDT 2020 built packages:10867 Oct 29:4196 Oct 30:1292 Oct 31:5378 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2020-10-29/summary.log build failures: 17 http://build-failures.rhaalovely.net/aarch64/2020-10-29/converters/wv2.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/devel/sqlc.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/editors/calligra.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/emulators/vice.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/games/shockolate.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/security/age.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/docker-cli.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/facette.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/rclone.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/www/chromium.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/x11/e17/e.log http://build-failures.rhaalovely.net/aarch64/2020-10-29/x11/qt5/qtwebkit.log recurrent failures failures/emulators/vice.log failures/games/shockolate.log failures/lang/pfe.log failures/security/age.log failures/sysutils/docker-cli.log failures/sysutils/facette.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log failures/www/chromium.log failures/x11/qt5/qtwebkit.log new failures +++ ls-failures Sat Oct 31 20:02:43 2020 +failures/x11/e17/e.log resolved failures --- ../old/aarch64/last//ls-failuresWed Oct 28 05:31:34 2020 -failures/net/kdsoap.log -failures/x11/e17/elementary.log
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' > > 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 + + #ifndef Q_MOC_RUN ++#include + #include + #endif +
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2020/10/31 19:10:36 Modified files: games/pokerth : Makefile Added files: games/pokerth/patches: patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp patch-src_third_party_websocketpp_websocketpp_transport_asio_security_none_hpp patch-src_third_party_websocketpp_websocketpp_transport_asio_security_tls_hpp Log message: fix pokerth with newer boost Fix taken from archlinux. Tested by me with newer boost. Tested by Brad with in-tree boost.
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 wrote:
> > On Wed, 14 Oct 2020 13:06:33 +0200, Antoine Jacoutot
> > 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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/10/31 19:00:58 Modified files: devel/py-setuptools: Makefile distinfo devel/py-setuptools/patches: patch-setup_cfg devel/py-setuptools/pkg: PLIST Log message: Update py-setuptools to 44.1.1 The 44.x series is the last that supports Python 2.7 Ran a bulk build with no issues. tweaks and ok daniel@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/10/31 17:44:34 Modified files: graphics : Makefile Log message: Hook up py-cairo,python3 Missed when graphics/py3-cairo was merged into graphics/py-cairo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/10/31 15:30:39 Modified files: lang/seed7 : Makefile distinfo lang/seed7/patches: patch-src_makefile lang/seed7/pkg : PLIST Log message: Update to seed7-20200929
Re: ghc 8.10.2 won't build haddock on i386
On Thu, Oct 29, 2020 at 10:23 PM Greg Steuck 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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/10/31 15:22:25 Modified files: games/wtf : Makefile distinfo Log message: Update to wtf-20201018
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
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
games/dMagnetic 0.25 -> 0.26 (Now it can load Amstrad CPC binaries)
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
--- 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
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_app31.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
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/
>
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 10:27:55 Modified files: print/qpdf : Makefile Added files: print/qpdf/patches: patch-configure Log message: Don't pick up libatomic from ports gcc if it happens to be installed. reported by naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 10:12:40 Removed files: textproc/libical/patches: patch-src_libical_icalrecur_c Log message: Unbreak: this needs to be applied *after* the new ICU is in tree. Reported by naddy
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 09:50:13 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Register pympd removal.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 09:49:41 Modified files: audio : Makefile Removed files: audio/pympd: Makefile distinfo audio/pympd/pkg: DESCR PLIST Log message: Remove pympd; nothing uses it and it has seen no release in 14y. ok robert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 09:48:07 Modified files: audio : Makefile Added files: audio/py-mpd : Makefile distinfo audio/py-mpd/pkg: DESCR PLIST Log message: Oops, revert previous, I was in the wrong dir.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 09:44:50 Modified files: audio : Makefile Removed files: audio/py-mpd : Makefile distinfo audio/py-mpd/pkg: DESCR PLIST Log message: Remove py-mpd; nothing uses it and it hasn't seen a release in 14y. audio/py-mpd2 is the new kid. ok robert@
Re: 回复: 回复: pysol doesn't run
Thank you, I shall look into it and create the new port for py-sol-card. wen 发件人: Daniel Dickman 发送时间: 2020年10月30日 12:03 收件人: wen heping 抄送: Daniel Dickman ; Carsten Boysen Jensen ; 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)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/10/31 06:09:04 Modified files: mail/geary : Makefile graphics/libgphoto2: Makefile devel/glade: Makefile x11/gnome/seahorse: Makefile x11/libhandy : Makefile Log message: set DEBUG_PACKAGES before including bsd.port.arch.mk, otherwise they're built on all archs not just DEBUGINFO_ARCHS. ok aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/10/31 04:50:16 Modified files: security/opm : Makefile distinfo Log message: update to 1.2
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 - > "Dimitri Karamazov" : > > > 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@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/10/31 04:40:36 Modified files: graphics/gimp : Makefile Log message: +lensfun
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/10/31 04:40:05 Log message: gimp plugin to use lensfen (correct camera aberrations) okay and tweak solene@, thanks for the test! Status: Vendor Tag: espie Release Tags: ports N ports/graphics/gimp/lensfun/Makefile N ports/graphics/gimp/lensfun/distinfo N ports/graphics/gimp/lensfun/pkg/PLIST N ports/graphics/gimp/lensfun/pkg/DESCR N ports/graphics/gimp/lensfun/patches/patch-src_gimplensfun_cpp No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/10/31 04:07:36 Modified files: net/zabbix : Makefile distinfo net/zabbix/patches: patch-src_libs_zbxnix_daemon_c net/zabbix/pkg : PLIST-web Log message: update to 5.0.5; from Mark Patruck
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/10/31 03:42:59 Modified files: www/nextcloud : Tag: OPENBSD_6_8 Makefile distinfo www/nextcloud/pkg: Tag: OPENBSD_6_8 PLIST Log message: Update for Nextcloud to 19.0.4 OK rsadowski@ - tested also by Adriano Barbosa
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 03:28:32 Modified files: audio/pulseaudio: Makefile distinfo Log message: Update to pulseaudio-13.99.3.
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
--- Makefile12 Jul 2019 20:43:35 - 1.33
+++ Makefile31 Oct 2020 05:07:55 -
@@ -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
-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
Index: distinfo
===
RCS file: /cvs/ports/audio/libsndfile/distinfo,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 distinfo
--- distinfo23 Apr 2018 08:48:54 - 1.17
+++ distinfo31 Oct 2020 05:07:55 -
@@ -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 -
+++ patches/patch-CMakeLists_txt31 Oct 2020 05:07:55 -
@@ -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 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/10/31 02:55:41 Modified files: net/vnstat : Makefile distinfo net/vnstat/patches: patch-cfg_vnstat_conf net/vnstat/pkg : PLIST-main README-main Removed files: net/vnstat/patches: patch-Makefile patch-src_Makefile Log message: Update vnstat to 2.6 Feedback and ok solene@, maintainer timeout
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 02:43:53 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.16.9.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 02:44:14 Modified files: sysutils/awscli: Makefile distinfo sysutils/awscli/pkg: PLIST Log message: Update to awscli-1.18.169.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 02:43:40 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.19.9.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 02:41:27 Modified files: x11/sxhkd : Makefile Log message: Unbreak: EVISION -> REVISION
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/10/31 02:40:09 Modified files: sysutils/packer: Makefile distinfo Log message: Update to packer-1.6.5.
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Thu Oct 22 16:11:31 UTC 2020 finished at Tue Oct 27 11:25:51 UTC 2020 lasted 05D19h14m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #13: Thu Oct 22 15:54:26 UTC 2020 built packages:8589 Oct 22:2110 Oct 23:1209 Oct 24:783 Oct 25:604 Oct 26:1022 Oct 27:2860 build failures: 27 http://build-failures.rhaalovely.net/mips64/2020-10-22/cad/netgen.log http://build-failures.rhaalovely.net/mips64/2020-10-22/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2020-10-22/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2020-10-22/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2020-10-22/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2020-10-22/devel/libexecinfo.log http://build-failures.rhaalovely.net/mips64/2020-10-22/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2020-10-22/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2020-10-22/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2020-10-22/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2020-10-22/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2020-10-22/geo/spatialite/gui.log http://build-failures.rhaalovely.net/mips64/2020-10-22/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/STk.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/librep.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2020-10-22/lang/squeak/vm.log http://build-failures.rhaalovely.net/mips64/2020-10-22/math/gbc.log http://build-failures.rhaalovely.net/mips64/2020-10-22/math/ntl.log http://build-failures.rhaalovely.net/mips64/2020-10-22/multimedia/frei0r-plugins.log http://build-failures.rhaalovely.net/mips64/2020-10-22/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2020-10-22/security/botan2.log http://build-failures.rhaalovely.net/mips64/2020-10-22/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2020-10-22/sysutils/libvirt.log http://build-failures.rhaalovely.net/mips64/2020-10-22/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net/mips64/2020-10-22/x11/e17/elementary.log
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'
> >
> >
>
> 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 - 1.47
> +++ Makefile 31 Oct 2020 00:48:37 -
> @@ -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 -
> +++
> patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_connection_hpp
>31 Oct 2020 00:48:37 -
> @@ -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::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::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 -
> +++
> patches/patch-src_third_party_websocketpp_websocketpp_transport_asio_endpoint_hpp
> 31 Oct 2020 00:48:37 -
> @@ -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::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::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(
> +-
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/10/31 01:39:53 Modified files: security/py-tlsfuzzer: Makefile distinfo Log message: Update to tlsfuzzer 20201030
Re: assembler error on trying to port OpenBLAS
On Fri, Oct 30, 2020 at 04:55:53PM +, 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
--- Makefile4 Sep 2020 09:55:34 - 1.34
+++ Makefile31 Oct 2020 03:08:05 -
@@ -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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/10/31 00:42:58 Modified files: net/nextcloudclient: Makefile distinfo Log message: Update nextcloudclient to 3.0.3 Update diff from maintainer with shared-lib and WANTLIB teak by me
Re: handbrake-1.3.3 high CPU load while idle on amd64
Hello Morgan -- On Thursday, October 29, 2020 1:29 PM, Morgan Aldridge 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.11 CALL open(0x6c1edf35b40,0) > Thanks for the report. I will try to find some time this weekend to look at it. ~Brian
