CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/11/26 00:43:33 Modified files: geo/pgpointcloud: Makefile distinfo geo/pgpointcloud/pkg: PLIST Log message: Update to pgpointcloud 1.2.1, from wen heping, thanks !
[Update] geo/pgpointcloud : Update to 1.2.1
Hi, ports@:
Here is a patch for geo/pgpointcloud to update to 1.2.1.
It build well and pass all tests on amd64-6.8 system. No other
ports depends on it.
Cheers !
wen
Index: Makefile
===
RCS file: /cvs/ports/geo/pgpointcloud/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile6 Feb 2020 00:40:22 - 1.8
+++ Makefile26 Nov 2020 07:20:35 -
@@ -2,17 +2,11 @@
COMMENT = point cloud storage extension for PostgreSQL
-GH_TAGNAME = v1.2.0
+GH_TAGNAME = v1.2.1
GH_PROJECT = pointcloud
GH_ACCOUNT = pgpointcloud
CATEGORIES = geo databases
-
-REVISION = 1
-MASTER_SITES0 =
https://github.com/pgpointcloud/pointcloud/commit/
-PATCHFILES =
pgpointcloud-patch1.patch{3e64c68dd4e0b9b9fdf0a74492ab49023161f6f1.diff}:0 \
-
pgpointcloud-patch2.patch{fa6faa4ec4ba28b61a9f6d160624257420ce7555.diff}:0
-PATCH_DIST_STRIP = -p1
# BSD
PERMIT_PACKAGE=Yes
Index: distinfo
===
RCS file: /cvs/ports/geo/pgpointcloud/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo6 Feb 2020 00:40:22 - 1.4
+++ distinfo26 Nov 2020 07:20:35 -
@@ -1,6 +1,2 @@
-SHA256 (pgpointcloud-patch1.patch) =
crVC7HyK06YRhuX7JOZVXfOZg2HuX0p1A0th21FPFt8=
-SHA256 (pgpointcloud-patch2.patch) =
uNeth90+OnYu8+bPZYPFzEysEDqETxPNBJxAIUNxkhU=
-SHA256 (pointcloud-1.2.0.tar.gz) = hUKkxxS00MZ/ENCSKRpDtWUIcbTsjK+DHkkoEPJbuTw=
-SIZE (pgpointcloud-patch1.patch) = 964
-SIZE (pgpointcloud-patch2.patch) = 3932
-SIZE (pointcloud-1.2.0.tar.gz) = 311231
+SHA256 (pointcloud-1.2.1.tar.gz) = kHQrb1+RZOJzr7s9D5MzX0TSAqjC3z/3F2neZHHR5Cc=
+SIZE (pointcloud-1.2.1.tar.gz) = 317926
Index: pkg/PLIST
===
RCS file: /cvs/ports/geo/pgpointcloud/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 23 Jan 2019 17:37:50 - 1.2
+++ pkg/PLIST 26 Nov 2020 07:20:35 -
@@ -1,13 +1,14 @@
@comment $OpenBSD: PLIST,v 1.2 2019/01/23 17:37:50 landry Exp $
lib/postgresql/
-lib/postgresql/pointcloud-1.2.so
+@so lib/postgresql/pointcloud-1.2.so
share/postgresql/
share/postgresql/extension/
-share/postgresql/extension/pointcloud--1.1.0--1.2.0.sql
-share/postgresql/extension/pointcloud--1.1.1--1.2.0.sql
-share/postgresql/extension/pointcloud--1.2.0--1.2.0next.sql
-share/postgresql/extension/pointcloud--1.2.0.sql
-share/postgresql/extension/pointcloud--1.2.0next--1.2.0.sql
+share/postgresql/extension/pointcloud--1.1.0--1.2.1.sql
+share/postgresql/extension/pointcloud--1.1.1--1.2.1.sql
+share/postgresql/extension/pointcloud--1.2.0--1.2.1.sql
+share/postgresql/extension/pointcloud--1.2.1--1.2.1next.sql
+share/postgresql/extension/pointcloud--1.2.1.sql
+share/postgresql/extension/pointcloud--1.2.1next--1.2.1.sql
share/postgresql/extension/pointcloud.control
-share/postgresql/extension/pointcloud_postgis--1.2.0.sql
+share/postgresql/extension/pointcloud_postgis--1.2.1.sql
share/postgresql/extension/pointcloud_postgis.control
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2020/11/25 22:38:13 Modified files: devel/py-pybind11: Makefile distinfo Log message: update to pybind11 2.6.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2020/11/25 22:30:03 Modified files: math/coq : Makefile distinfo Log message: update coq to 8.12.1; a bug fix release ok Yozo Toda (MAINTAINER)
Re: [ld.bfd] Unbreak x11/gnome/gucharmap
On Wed, Nov 25, 2020 at 10:39:33PM +0100, Charlene Wendling wrote:
> On Wed, 25 Nov 2020 16:20:38 -0500
> Brad Smith wrote:
>
> > On Wed, Nov 25, 2020 at 11:39:49AM +0100, Charlene Wendling wrote:
> > > Hi,
> > >
> > > > http://build-failures.rhaalovely.net/sparc64/2020-11-17/x11/gnome/gucharmap.log
> > > (same thing on macppc)
> > >
> > > This new version of gucharmap "requires" the -Bsymbolic-functions
> > > linker flag. Bypassing the check allows to build gucharmap.
> > >
> > > I didn't bump REVISION; this changes nothing on amd64 and it has
> > > never been built on ld.bfd archs.
> > >
> > > The runtime is fine on macppc.
> > >
> > > Comments/feedback are welcome,
> > >
> > > Charl??ne.
> > >
> > > [0] https://bin.charlenew.xyz/gucharmap.log
> >
> > I was looking at this yesterday. I just had not sent the diff out yet.
>
> I was committing the fix while you sending that mail. I'm pretty
> sure that upstream would prefer your fix to mine.
Just FYI this was part of a bigger diff I had to remove the workaround
for lld. I previously had a similar diff to the autoconf based ports for
gucharmap and then it switched from autoconf to meson. It also included
devel/vte but that was removed.
Index: www/libcroco/Makefile
===
RCS file: /home/cvs/ports/www/libcroco/Makefile,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 Makefile
--- www/libcroco/Makefile 16 May 2020 18:46:55 - 1.35
+++ www/libcroco/Makefile 30 Oct 2020 20:31:05 -
@@ -6,6 +6,7 @@ COMMENT=generic CSS parsing library fo
GNOME_PROJECT= libcroco
GNOME_VERSION= 0.6.13
+REVISION= 0
SHARED_LIBS += croco-0.64.0 # 3.1
@@ -27,7 +28,10 @@ LIB_DEPENDS= devel/glib2 \
CONFIGURE_STYLE= gnu
+.include
+.if !${PROPERTIES:Mlld}
# error: -Bsymbolic-functions requested but not supported by ld
CONFIGURE_ARGS += --disable-Bsymbolic
+.endif
.include
Index: x11/gnome/gucharmap/Makefile
===
RCS file: /home/cvs/ports/x11/gnome/gucharmap/Makefile,v
retrieving revision 1.128
diff -u -p -u -p -r1.128 Makefile
--- x11/gnome/gucharmap/Makefile8 Nov 2020 07:42:26 - 1.128
+++ x11/gnome/gucharmap/Makefile25 Nov 2020 23:35:42 -
@@ -4,6 +4,7 @@ COMMENT=Unicode character map for the
GNOME_PROJECT= gucharmap
GNOME_VERSION= 13.0.4
+REVISION= 0
SHARED_LIBS += gucharmap_2_907.0 # 7.0
@@ -32,5 +33,11 @@ RUN_DEPENDS =devel/gsettings-desktop-s
LIB_DEPENDS= x11/gtk+3,-main
CONFIGURE_ARGS += -Ducd_path=${LOCALBASE}/share/unicode/ucd/
+
+.include
+.if !${PROPERTIES:Mlld}
+# ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not supported
+CONFIGURE_ARGS += -Dsymbolic_functions=false
+.endif
.include
Index: x11/gnome/gucharmap/patches/patch-meson_build
===
RCS file: /home/cvs/ports/x11/gnome/gucharmap/patches/patch-meson_build,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-meson_build
--- x11/gnome/gucharmap/patches/patch-meson_build 25 Nov 2020 21:19:51
- 1.2
+++ x11/gnome/gucharmap/patches/patch-meson_build 25 Nov 2020 23:36:25
-
@@ -1,8 +1,7 @@
$OpenBSD: patch-meson_build,v 1.2 2020/11/25 21:19:51 cwen Exp $
-Hunk #1: ERROR: C shared or static library 'dl' not found
-Hunk #2: fix the build on ld.bfd archs, where the -Bsymbolic-functions
- linker flag is not supported
+- ERROR: C shared or static library 'dl' not found
+- ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not supported
Index: meson.build
--- meson.build.orig
@@ -26,17 +25,27 @@ Index: meson.build
# Compiler flags
compiler_flags_common = [
-@@ -226,8 +214,11 @@ linker_flags = [
- ]
+@@ -221,14 +209,16 @@ add_project_arguments(global_cflags, language: 'c',)
- foreach flag: linker_flags
+ # Linker flags
+
+-linker_flags = [
+- '-Wl,-Bsymbolic-functions'
+-]
++if get_option('symbolic_functions')
++ linker_flags = [
++'-Wl,-Bsymbolic-functions'
++ ]
+
+-foreach flag: linker_flags
- assert(cc.has_link_argument(flag), flag + ' is required but not supported')
- add_project_link_arguments(flag, language: 'c',)
-+ if cc.has_link_argument(flag)
+-endforeach
++ foreach flag: linker_flags
++assert(cc.has_link_argument(flag), flag + ' is required but not
supported')
+add_project_link_arguments(flag, language: 'c',)
-+ else
-+message(flag + ' is not supported')
-+ endif
- endforeach
++ endforeach
++endif
# Dependencies
+
Index: x11/gnome/gucharmap/patches/patch-meson_options_txt
===
RCS file: x11/gnome/gucharmap/patches/patch-meson_options_txt
diff -N
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/11/25 20:41:39 Modified files: devel : Makefile Log message: +rebar3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jmatt...@cvs.openbsd.org2020/11/25 20:31:56 Log message: Import rebar3-3.13.2 - "the official build tool for Erlang" ok jasper@ Status: Vendor Tag: jmatthew Release Tags: jmatthew_20201126 N ports/devel/rebar3/Makefile N ports/devel/rebar3/distinfo N ports/devel/rebar3/patches/patch-bootstrap N ports/devel/rebar3/patches/patch-src_rebar_prv_escriptize_erl N ports/devel/rebar3/patches/patch-_build_default_lib_relx_priv_templates_bin N ports/devel/rebar3/patches/patch-rebar_config N ports/devel/rebar3/patches/patch-_build_default_lib_relx_priv_templates_extended_bin N ports/devel/rebar3/pkg/DESCR N ports/devel/rebar3/pkg/PLIST No conflicts created by this import
$ cd /usr/ports/archivers/unzip $ make show=MAINTAINER
Dikirim dari iPhone saya
[fixes/updates] net/usockets www/uwebsockets to 18.15.0 www/purritobin to 0.3.2
Hi,
Attached updates for net/usockets www/{uwebsockets,purritobin}
I am unsure what the protocol is for submitting multiple port updates but at
least
usockets and uwebsockets are closely tied enough that they would need
to be updated together. I can decouple purritobin, if it makes it easier to
review.
Changes/fixes:
net/usockets:
- revision bump to 0
- fixes a cstdlib include error from upstream
- adds a pkg-config file for easy use by other programs
- removes internal header installation
- fixes header install path to match FreeBSD (deprecates a patch in uWebSockets)
www/uwebsockets:
- update to 18.15.0
- removes unneeded patch
www/purritobin:
- update to 0.3.2
- adds SSL capabilities
- adds support for ipv6
- adds listening on multiple interfaces and ports
- adds a man page (was fun to learn mandoc, damn cool)
- adds logging to syslog
Thanks a lot to tb@ for noticing me being dumb with unveil :P
Cheers,
Aisha
diff --git a/net/usockets/Makefile b/net/usockets/Makefile
index b39937b6fe5..24297b98f34 100644
--- a/net/usockets/Makefile
+++ b/net/usockets/Makefile
@@ -1,14 +1,22 @@
# $OpenBSD: Makefile,v 1.3 2020/09/17 01:38:30 bcallah Exp $
COMMENT= eventing, networking & crypto for async applications
-PKGNAME = ${DISTNAME:L}
CATEGORIES = net
+VERSION = 0.6.0
+REVISION = 0
+
+DISTNAME = usockets-${VERSION}
+PKGNAME = ${DISTNAME:L}
+
SHARED_LIBS = usockets 1.0
GH_ACCOUNT = uNetworking
GH_PROJECT = uSockets
-GH_TAGNAME = v0.6.0
+#GH_TAGNAME = v0.6.0
+# cstdlib include error
+GH_COMMIT =7683672d87067cd75b854f4e36b9820f4809a4be
+
MAINTAINER = Aisha Tammy
@@ -23,12 +31,9 @@ COMPILER = base-clang ports-gcc
LIB_DEPENDS = devel/libuv
USE_GMAKE =Yes
-ALL_TARGET = default
-MAKE_FLAGS = CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
- LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib" \
- CXX="${CXX}" CXXFLAGS="${CXXFLAGS}" \
- LIBusockets_VERSION="${LIBusockets_VERSION}" \
- WITH_OPENSSL=1 WITH_LIBUV=1
+MAKE_FLAGS = CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" \
+ CC="${CC}" CXX="${CXX}" \
+ LIBusockets_VERSION="${LIBusockets_VERSION}"
NO_TEST = Yes
diff --git a/net/usockets/distinfo b/net/usockets/distinfo
index 8058bc795ab..964ba508e9e 100644
--- a/net/usockets/distinfo
+++ b/net/usockets/distinfo
@@ -1,2 +1,2 @@
-SHA256 (uSockets-0.6.0.tar.gz) = mZOH02U7K8Zjw0qn6XM1isTEiX3M1kRVOlyquEOpeKE=
-SIZE (uSockets-0.6.0.tar.gz) = 57590
+SHA256 (usockets-0.6.0-7683672d.tar.gz) =
0OooGCHD8ezNIcaB1zDPK6RQLGGYGZJb24Vemjlat7c=
+SIZE (usockets-0.6.0-7683672d.tar.gz) = 57634
diff --git a/net/usockets/patches/patch-Makefile
b/net/usockets/patches/patch-Makefile
index e68fbee5c06..56473a2f03b 100644
--- a/net/usockets/patches/patch-Makefile
+++ b/net/usockets/patches/patch-Makefile
@@ -1,68 +1,98 @@
$OpenBSD: patch-Makefile,v 1.2 2020/09/17 01:38:30 bcallah Exp $
-add shared + static lib + default targets
+add shared + static lib + pkg-config file
remove -flto -O3
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -1,3 +1,13 @@
+@@ -1,60 +1,40 @@
+-# WITH_OPENSSL=1 enables OpenSSL 1.1+ support or BoringSSL
+-# For now we need to link with C++ for OpenSSL support, but should be removed
with time
+-ifeq ($(WITH_OPENSSL),1)
+- override CFLAGS += -DLIBUS_USE_OPENSSL
+- # With problems on macOS, make sure to pass needed LDFLAGS required to
find these
+- override LDFLAGS += -lssl -lcrypto -lstdc++
+-else
+- # WITH_WOLFSSL=1 enables WolfSSL 4.2.0 support (mutually exclusive with
OpenSSL)
+- ifeq ($(WITH_WOLFSSL),1)
+- # todo: change these
+- override CFLAGS += -DLIBUS_USE_WOLFSSL -I/usr/local/include
+- override LDFLAGS += -L/usr/local/lib -lwolfssl
+- else
+- override CFLAGS += -DLIBUS_NO_SSL
+- endif
+-endif
+DESTDIR ?=
-+
-+prefix ?= "/usr/local"
-+exec_prefix ?= "$(prefix)"
-+libdir ?= "$(exec_prefix)/lib"
-+includedir?="$(exec_prefix)/include/uSockets"
-+
+
+-# WITH_LIBUV=1 builds with libuv as event-loop
+-ifeq ($(WITH_LIBUV),1)
+- override CFLAGS += -DLIBUS_USE_LIBUV
+- override LDFLAGS += -luv
+-endif
++PREFIX ?= "/usr/local"
++LIBDIR ?= "$(PREFIX)/lib"
++INCLUDEDIR ?= "$(PREFIX)/include"
+
+-# WITH_GCD=1 builds with libdispatch as event-loop
+-ifeq ($(WITH_GCD),1)
+- override CFLAGS += -DLIBUS_USE_GCD
+- override LDFLAGS += -framework CoreFoundation
+-endif
+# OpenBSD specific library version
-+LIBTARGET = libusockets.so.$(LIBusockets_VERSION)
-+
- # WITH_OPENSSL=1 enables OpenSSL 1.1+ support or BoringSSL
- # For now we need to link with C++ for OpenSSL support, but should be removed
with time
- ifeq ($(WITH_OPENSSL),1)
-@@ -34,18 +44,32 @@ ifeq ($(WITH_ASAN),1)
- endif
++LIBTARGET ?= libusockets.so.$(LIBusockets_VERSION)
+
+-# WITH_ASAN builds with sanitizers
+-ifeq ($(WITH_ASAN),1)
+- override
回复: [Update] devel/p5-Paranoid : Update to 2.07
ping ... 发件人: wen heping 发送时间: 2020年1月12日 15:11 收件人: ports@openbsd.org 主题: [Update] devel/p5-Paranoid : Update to 2.07 Hi, ports@: Here is a simple patch for devel/p5-Paranoid updae to 2.07, which is required by the update of devel/p5-Parse-PlainConfig. It build well and pass all tests on amd64-current system. Regards, wen
回复: [Update] devel/p5-Parse-PlainConfig : Update to 3.05
ping ... 发件人: wen heping 发送时间: 2020年1月12日 15:14 收件人: ports@openbsd.org 主题: [Update] devel/p5-Parse-PlainConfig : Update to 3.05 Hi, ports@: Here is a patch for devel/p5-Parse-PlainConfig: i) Update to 3.05 ii) Add MAKE_ENV iii) Add devel/p5-Class-EHierarchy as RUN_DEPENDS It build well and pass all tests on amd64-current system. Regards, wen
回复: [NEW] devel/p5-Class-EHierarchy
ping ... 发件人: wen heping 发送时间: 2020年1月12日 15:08 收件人: ports@openbsd.org 主题: [NEW] devel/p5-Class-EHierarchy Hi, ports@: Here is a patch to create new port devel/p5-Class-EHierarchy, which is required by the update of devel/p5-Parse-PlainConfig. It build well and pass all tests on amd64-current system. Regards, wen
Re: [ld.bfd] Unbreak x11/gnome/gucharmap
On Wed, Nov 25, 2020 at 11:39:49AM +0100, Charlene Wendling wrote:
> Hi,
>
> > http://build-failures.rhaalovely.net/sparc64/2020-11-17/x11/gnome/gucharmap.log
> (same thing on macppc)
>
> This new version of gucharmap "requires" the -Bsymbolic-functions
> linker flag. Bypassing the check allows to build gucharmap.
>
> I didn't bump REVISION; this changes nothing on amd64 and it has never
> been built on ld.bfd archs.
>
> The runtime is fine on macppc.
>
> Comments/feedback are welcome,
>
> Charl??ne.
>
> [0] https://bin.charlenew.xyz/gucharmap.log
I was looking at this yesterday. I just had not sent the diff out yet.
Index: Makefile
===
RCS file: /home/cvs/ports/x11/gnome/gucharmap/Makefile,v
retrieving revision 1.128
diff -u -p -u -p -r1.128 Makefile
--- Makefile8 Nov 2020 07:42:26 - 1.128
+++ Makefile24 Nov 2020 05:26:34 -
@@ -33,4 +33,10 @@ LIB_DEPENDS= x11/gtk+3,-main
CONFIGURE_ARGS += -Ducd_path=${LOCALBASE}/share/unicode/ucd/
+.include
+.if !${PROPERTIES:Mlld}
+# ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not supported
+CONFIGURE_ARGS += -Dsymbolic_functions=false
+.endif
+
.include
Index: patches/patch-meson_build
===
RCS file: /home/cvs/ports/x11/gnome/gucharmap/patches/patch-meson_build,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-meson_build
--- patches/patch-meson_build 7 Nov 2020 08:59:35 - 1.1
+++ patches/patch-meson_build 25 Nov 2020 19:27:55 -
@@ -1,6 +1,7 @@
$OpenBSD: patch-meson_build,v 1.1 2020/11/07 08:59:35 jasper Exp $
-ERROR: C shared or static library 'dl' not found
+- ERROR: C shared or static library 'dl' not found
+- ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not supported
Index: meson.build
--- meson.build.orig
@@ -24,3 +25,27 @@ Index: meson.build
# Compiler flags
compiler_flags_common = [
+@@ -221,14 +209,16 @@ add_project_arguments(global_cflags, language: 'c',)
+
+ # Linker flags
+
+-linker_flags = [
+- '-Wl,-Bsymbolic-functions'
+-]
++if get_option('symbolic_functions')
++ linker_flags = [
++'-Wl,-Bsymbolic-functions'
++ ]
+
+-foreach flag: linker_flags
+- assert(cc.has_link_argument(flag), flag + ' is required but not supported')
+- add_project_link_arguments(flag, language: 'c',)
+-endforeach
++ foreach flag: linker_flags
++assert(cc.has_link_argument(flag), flag + ' is required but not
supported')
++add_project_link_arguments(flag, language: 'c',)
++ endforeach
++endif
+
+ # Dependencies
+
Index: patches/patch-meson_options_txt
===
RCS file: patches/patch-meson_options_txt
diff -N patches/patch-meson_options_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-meson_options_txt 25 Nov 2020 19:28:01 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not supported
+
+Index: meson_options.txt
+--- meson_options.txt.orig
meson_options.txt
+@@ -61,3 +61,10 @@ option(
+ value: true,
+ description: 'Enable Vala bindings',
+ )
++
++option(
++ 'symbolic_functions',
++ type: 'boolean',
++ value: true,
++ description: 'Enable bind defined function symbols locally',
++)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/11/25 17:08:36 Modified files: devel/boost: Makefile Removed files: devel/boost/patches: patch-tools_build_src_engine_Jambase Log message: boost-build has been removed, gc pointless patch Suggested by Brad (maintainer)
Re: mosquitto with websockets enabled?
On 11/25/20 3:03 PM, Stuart Henderson wrote:
[moved to ports@ and cc'ing mosquitto maintainer]
In gmane.os.openbsd.misc, Jeff Ross wrote:
Greetings,
I've been trying to build mosquitto with websockets enabled on 6.8
release. The web says that all I should have to do is edit config.mk
and change WITH_WEBSOCKETS:=no to WITH_WEBSOCKETS:=yes.
I also added libwebsockets from ports.
I built a patch to do that and then built the port with that patch.
test68# cd /usr/ports/net/mosquitto/patches/
test68# cat patch-config_mk
--- config.mk.orig Wed Nov 25 09:33:17 2020
+++ config.mk Wed Nov 25 09:33:34 2020
@@ -65,7 +65,7 @@
WITH_SRV:=no
# Build with websockets support on the broker.
-WITH_WEBSOCKETS:=no
+WITH_WEBSOCKETS:=yes
# Use elliptic keys in broker
WITH_EC:=yes
However, I still get the following:
test68# /usr/local/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
1606323544: Error: Websockets support not available.
1606323544: Error found at /etc/mosquitto/mosquitto.conf:241.
ktracing the command above I don't even see a place where it actually
looks to see if websockets are enabled.
I'm hoping someone has gone down this path before and can share the
secret sauce to enable websockets.
Alternatively, a suggestion for a different implementation of MQTT with
websockets would be fine.
Thanks,
Jeff Ross
config.mk is for the autoconf-based build system, the mosquitto port
uses the CMake one instead so you need to set configure flags.
This works for me - Jasper, what do you think about adding to the
port? (either directly like this or as a flavour)?
Index: Makefile
===
RCS file: /cvs/ports/net/mosquitto/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile22 Aug 2020 13:55:07 - 1.33
+++ Makefile25 Nov 2020 21:42:00 -
@@ -3,6 +3,7 @@
COMMENT = opensource MQTT broker
DISTNAME = mosquitto-1.6.12
+REVISION = 0
SHARED_LIBS += mosquitto 1.0 # 1.5
SHARED_LIBS += mosquittopp 1.0 # 1.5
@@ -15,7 +16,7 @@ MAINTAINER = Jasper Lievisse Adriaanse
# EPL/EDL
PERMIT_PACKAGE = Yes
-WANTLIB += c crypto m pthread ssl ${COMPILER_LIBCXX}
+WANTLIB += c crypto m pthread ssl websockets ${COMPILER_LIBCXX}
MASTER_SITES = https://mosquitto.org/files/source/
@@ -29,12 +30,15 @@ MODPY_RUNDEP= No
MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}
BUILD_DEPENDS = devel/uthash
+LIB_DEPENDS = www/libwebsockets
DEBUG_PACKAGES = ${BUILD_PACKAGES}
-CONFIGURE_ARGS= -DWITH_SRV=no
+CONFIGURE_ARGS=-DWITH_SRV=no \
+ -DWITH_WEBSOCKETS=yes
# Pre-shared key support was intentionally removed from libressl
CONFIGURE_ARGS += -DWITH_TLS_PSK=no
+CONFIGURE_ENV += LDFLAGS="-L${LOCALBASE}/lib"
CFLAGS += -I${LOCALBASE}/include
Thanks, Stuart! I never would have hit upon the right combination of
changes.
Jeff
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/11/25 17:06:04 Modified files: devel/boost: Makefile devel/boost/pkg: PLIST-main Log message: Drop boost_python27, boost_numpy27 and boost-build support Drops one consumer of py2-numpy, upstream numpy is now python3 only. Dropping all python27 support makes the port simpler and hopefully future updates easier. boost-build also leaves as collateral damage, its python files aren't ready for python3 and it's not clear how useful they are. ok Brad, rsadowski@ (maintainers) ok sthen@ who also helped clear the way
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 11/25/20 2:48 PM, Theo Buehler wrote:
> On Wed, Nov 25, 2020 at 02:19:38PM -0500, Aisha Tammy wrote:
>> On 11/25/20 2:01 PM, Theo Buehler wrote:
>>> On Wed, Nov 25, 2020 at 01:12:03PM -0500, Aisha Tammy wrote:
On 11/25/20 12:34 PM, Stuart Henderson wrote:
> On 2020/11/25 12:03, Aisha Tammy wrote:
>> Hi,
>> It has come to my attention that upstream does not support
>> libressl and only wants to support openssl
>> https://github.com/uNetworking/uWebSockets/issues/994
>>
>> I am unsure on how to fix this port.
>> There is no problem right now as the only consumer www/purritobin
>> does not use the SSL functionality in 0.2.4 (the current version in
>> tree).
>>
>> The new updated version www/purritobin-0.3.1 (not yet sent the diff)
>> does use SSL functionality optionally during runtime, which will be
>> broken
>> if net/usockets doesn't get fixed.
>>
>> Can anyone help with fixing this linking?
>>
>> The updated version of usockets and purritobin do work correctly when
>> linked with OpenSSL when used on linux (tested on gentoo).
>>
>> Thanks,
>> Aisha
> "LibreSSL seems to be just like most forks are; a joke." lovely.
I know right :(
> what is the actual breakage when trying to use it with libressl?
>
When doing a paste, with curl, using an SSL connection, the error is:
>>>
>>> The first thing getting in the way is unveil. You probably don't want to
>>> have certificate and key in the storage directory. That won't be fixed
>>> by a switch to OpenSSL:
>>>
>>> /* based and lit method to make sure that nothing goes wrong */
>>> #if defined(__OpenBSD__)
>>> /* the only directory we need access to is the storage directory */
>>> int unveil_err = unveil(storage_directory.c_str(), "rwxc");
>>> if (unveil_err != 0) {
>>> err(unveil_err, "Error: could not unveil storage folder: %s",
>>> storage_directory.c_str());
>>> }
>>> /* also we only need small amounts of net and socket access */
>>> (void)pledge("stdio rpath wpath cpath inet unix", NULL);
>>> #endif
>>>
>>> The library still needs to load certificate and key correctly, which it
>>> doesn't (the connection errors out since libssl can't load the cert),
>>> but I haven't looked into why that is.
>>>
>>> https://github.com/openbsd/src/blob/master/lib/libssl/tls13_server.c#L625
>>>
* Trying 73.215.141.174:42069...
* Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure
Thanks a bunch,
Aisha
>>>
>>
>> OMG! YOU ARE A GENIUS!
>> It worked with commenting out the unveil :D :D :D
>> That is amazing!!
>
> Oh, great. So I messed up my testing when it didn't load the cert for
> me...:)
>
>> It seems I am dumb about not knowing what I write myself...
>> Sorry about this :(
>
> No worries. This happens to all of us :)
>
> I ran a test instance under ktrace.
>
> ktrace -di ./purrito -l -d localhost -s /tmp/purritobin/ -k
> /tmp/localhost.key -c /tmp/localhost.crt -n localhost
>
> Then looking at the output of kdump showed that opening
> /tmp/localhost.key gave ENOENT. The reason for this was then rather
> obvious.
>
>> Fixing up the unveil is easy enough now that I know the problem.
>
> Indeed.
>
>> On a side note, am curious about this not being an error during runtime.
>> I thought wrong read access would terminate the program :O
>
> Only pledge aborts. As mentioned above, unveil gives ENOENT on access of
> hidden files. I'm not entirely sure why the server lib doesn't give a
> meaningful error, though. It should...
>
>> On a side side note: While this consumer is correctly working now,
>> the upstreams horrible statement still does exist...
>> Do we want/need to link it to OpenSSL instead?
>
> I don't think so. From a quick glance, usockets doesn't seem to do
> anything particularly fancy libssl-wise. We use OpenSSL in ports only if
> there really is no other way (missing API, or occasionally due to major
> breakage). This should not happen with a relatively simple webserver.
>
Gotcha, that makes sense
. Thanks for glancing over :)
>> There doesn't seem to be an immediate need but yea... I have no clue
>> what internal shenanigans happen in OpenSSL vs LibreSSL.
>
> We strive to be a drop-in replacement as far as possible and reasonable.
> Things
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/11/25 16:56:25 Modified files: games/vegastrike: Makefile.inc Log message: Mark as BROKEN, this uses boost_python27 which is getting in the way Upstream development has taken a new turn, with python3 support planned for 0.8.0. While here update HOMEPAGE and point at github for new releases. Maintainer timeout, ok sthen@
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 11/25/20 2:01 PM, Theo Buehler wrote:
> On Wed, Nov 25, 2020 at 01:12:03PM -0500, Aisha Tammy wrote:
>> On 11/25/20 12:34 PM, Stuart Henderson wrote:
>>> On 2020/11/25 12:03, Aisha Tammy wrote:
Hi,
It has come to my attention that upstream does not support
libressl and only wants to support openssl
https://github.com/uNetworking/uWebSockets/issues/994
I am unsure on how to fix this port.
There is no problem right now as the only consumer www/purritobin
does not use the SSL functionality in 0.2.4 (the current version in tree).
The new updated version www/purritobin-0.3.1 (not yet sent the diff)
does use SSL functionality optionally during runtime, which will be broken
if net/usockets doesn't get fixed.
Can anyone help with fixing this linking?
The updated version of usockets and purritobin do work correctly when
linked with OpenSSL when used on linux (tested on gentoo).
Thanks,
Aisha
>>> "LibreSSL seems to be just like most forks are; a joke." lovely.
>> I know right :(
>>> what is the actual breakage when trying to use it with libressl?
>>>
>>
>> When doing a paste, with curl, using an SSL connection, the error is:
>
> The first thing getting in the way is unveil. You probably don't want to
> have certificate and key in the storage directory. That won't be fixed
> by a switch to OpenSSL:
>
> /* based and lit method to make sure that nothing goes wrong */
> #if defined(__OpenBSD__)
> /* the only directory we need access to is the storage directory */
> int unveil_err = unveil(storage_directory.c_str(), "rwxc");
> if (unveil_err != 0) {
> err(unveil_err, "Error: could not unveil storage folder: %s",
> storage_directory.c_str());
> }
> /* also we only need small amounts of net and socket access */
> (void)pledge("stdio rpath wpath cpath inet unix", NULL);
> #endif
>
> The library still needs to load certificate and key correctly, which it
> doesn't (the connection errors out since libssl can't load the cert),
> but I haven't looked into why that is.
>
> https://github.com/openbsd/src/blob/master/lib/libssl/tls13_server.c#L625
>
>>
>> * Trying 73.215.141.174:42069...
>> * Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0)
>> * ALPN, offering h2
>> * ALPN, offering http/1.1
>> * successfully set certificate verify locations:
>> * CAfile: /etc/ssl/certs/ca-certificates.crt
>> * CApath: /etc/ssl/certs
>> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
>> * TLSv1.3 (IN), TLS handshake, Server hello (2):
>> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
>> * TLSv1.3 (IN), TLS alert, handshake failure (552):
>> * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
>> * Closing connection 0
>> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
>> failure
>>
>> Thanks a bunch,
>> Aisha
>
OMG! YOU ARE A GENIUS!
It worked with commenting out the unveil :D :D :D
That is amazing!!
It seems I am dumb about not knowing what I write myself...
Sorry about this :(
Fixing up the unveil is easy enough now that I know the problem.
On a side note, am curious about this not being an error during runtime.
I thought wrong read access would terminate the program :O
On a side side note: While this consumer is correctly working now,
the upstreams horrible statement still does exist...
Do we want/need to link it to OpenSSL instead?
There doesn't seem to be an immediate need but yea... I have no clue
what internal shenanigans happen in OpenSSL vs LibreSSL.
Thanks so much,
Aisha
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 11/25/20 12:34 PM, Stuart Henderson wrote: > On 2020/11/25 12:03, Aisha Tammy wrote: >> Hi, >> It has come to my attention that upstream does not support >> libressl and only wants to support openssl >> https://github.com/uNetworking/uWebSockets/issues/994 >> >> I am unsure on how to fix this port. >> There is no problem right now as the only consumer www/purritobin >> does not use the SSL functionality in 0.2.4 (the current version in tree). >> >> The new updated version www/purritobin-0.3.1 (not yet sent the diff) >> does use SSL functionality optionally during runtime, which will be broken >> if net/usockets doesn't get fixed. >> >> Can anyone help with fixing this linking? >> >> The updated version of usockets and purritobin do work correctly when >> linked with OpenSSL when used on linux (tested on gentoo). >> >> Thanks, >> Aisha > "LibreSSL seems to be just like most forks are; a joke." lovely. I know right :( > what is the actual breakage when trying to use it with libressl? > When doing a paste, with curl, using an SSL connection, the error is: * Trying 73.215.141.174:42069... * Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS alert, handshake failure (552): * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure * Closing connection 0 curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure Thanks a bunch, Aisha
Re: mosquitto with websockets enabled?
[moved to ports@ and cc'ing mosquitto maintainer]
In gmane.os.openbsd.misc, Jeff Ross wrote:
> Greetings,
>
> I've been trying to build mosquitto with websockets enabled on 6.8
> release. The web says that all I should have to do is edit config.mk
> and change WITH_WEBSOCKETS:=no to WITH_WEBSOCKETS:=yes.
> I also added libwebsockets from ports.
>
> I built a patch to do that and then built the port with that patch.
>
> test68# cd /usr/ports/net/mosquitto/patches/
> test68# cat patch-config_mk
> --- config.mk.orig Wed Nov 25 09:33:17 2020
> +++ config.mk Wed Nov 25 09:33:34 2020
> @@ -65,7 +65,7 @@
> WITH_SRV:=no
>
> # Build with websockets support on the broker.
> -WITH_WEBSOCKETS:=no
> +WITH_WEBSOCKETS:=yes
>
> # Use elliptic keys in broker
> WITH_EC:=yes
>
> However, I still get the following:
>
> test68# /usr/local/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
> 1606323544: Error: Websockets support not available.
> 1606323544: Error found at /etc/mosquitto/mosquitto.conf:241.
>
> ktracing the command above I don't even see a place where it actually
> looks to see if websockets are enabled.
>
> I'm hoping someone has gone down this path before and can share the
> secret sauce to enable websockets.
>
> Alternatively, a suggestion for a different implementation of MQTT with
> websockets would be fine.
>
> Thanks,
>
> Jeff Ross
>
>
config.mk is for the autoconf-based build system, the mosquitto port
uses the CMake one instead so you need to set configure flags.
This works for me - Jasper, what do you think about adding to the
port? (either directly like this or as a flavour)?
Index: Makefile
===
RCS file: /cvs/ports/net/mosquitto/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile22 Aug 2020 13:55:07 - 1.33
+++ Makefile25 Nov 2020 21:42:00 -
@@ -3,6 +3,7 @@
COMMENT = opensource MQTT broker
DISTNAME = mosquitto-1.6.12
+REVISION = 0
SHARED_LIBS += mosquitto 1.0 # 1.5
SHARED_LIBS += mosquittopp 1.0 # 1.5
@@ -15,7 +16,7 @@ MAINTAINER = Jasper Lievisse Adriaanse
# EPL/EDL
PERMIT_PACKAGE = Yes
-WANTLIB += c crypto m pthread ssl ${COMPILER_LIBCXX}
+WANTLIB += c crypto m pthread ssl websockets ${COMPILER_LIBCXX}
MASTER_SITES = https://mosquitto.org/files/source/
@@ -29,12 +30,15 @@ MODPY_RUNDEP= No
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_3}
BUILD_DEPENDS =devel/uthash
+LIB_DEPENDS = www/libwebsockets
DEBUG_PACKAGES = ${BUILD_PACKAGES}
-CONFIGURE_ARGS=-DWITH_SRV=no
+CONFIGURE_ARGS=-DWITH_SRV=no \
+ -DWITH_WEBSOCKETS=yes
# Pre-shared key support was intentionally removed from libressl
CONFIGURE_ARGS += -DWITH_TLS_PSK=no
+CONFIGURE_ENV += LDFLAGS="-L${LOCALBASE}/lib"
CFLAGS += -I${LOCALBASE}/include
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2020/11/25 14:45:06 Modified files: www/py-bokeh : Makefile distinfo Log message: update py-bokeh to 2.2.3
Re: [ld.bfd] Unbreak x11/gnome/gucharmap
On Wed, 25 Nov 2020 16:20:38 -0500
Brad Smith wrote:
> On Wed, Nov 25, 2020 at 11:39:49AM +0100, Charlene Wendling wrote:
> > Hi,
> >
> > > http://build-failures.rhaalovely.net/sparc64/2020-11-17/x11/gnome/gucharmap.log
> > (same thing on macppc)
> >
> > This new version of gucharmap "requires" the -Bsymbolic-functions
> > linker flag. Bypassing the check allows to build gucharmap.
> >
> > I didn't bump REVISION; this changes nothing on amd64 and it has
> > never been built on ld.bfd archs.
> >
> > The runtime is fine on macppc.
> >
> > Comments/feedback are welcome,
> >
> > Charl??ne.
> >
> > [0] https://bin.charlenew.xyz/gucharmap.log
>
> I was looking at this yesterday. I just had not sent the diff out yet.
I was committing the fix while you sending that mail. I'm pretty
sure that upstream would prefer your fix to mine.
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnome/gucharmap/Makefile,v
> retrieving revision 1.128
> diff -u -p -u -p -r1.128 Makefile
> --- Makefile 8 Nov 2020 07:42:26 - 1.128
> +++ Makefile 24 Nov 2020 05:26:34 -
> @@ -33,4 +33,10 @@ LIB_DEPENDS= x11/gtk+3,-main
>
> CONFIGURE_ARGS +=-Ducd_path=${LOCALBASE}/share/unicode/ucd/
>
> +.include
> +.if !${PROPERTIES:Mlld}
> +# ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not
> supported +CONFIGURE_ARGS += -Dsymbolic_functions=false
> +.endif
> +
> .include
> Index: patches/patch-meson_build
> ===
> RCS
> file: /home/cvs/ports/x11/gnome/gucharmap/patches/patch-meson_build,v
> retrieving revision 1.1 diff -u -p -u -p -r1.1 patch-meson_build
> --- patches/patch-meson_build 7 Nov 2020 08:59:35 -
> 1.1 +++ patches/patch-meson_build 25 Nov 2020 19:27:55 -
> @@ -1,6 +1,7 @@
> $OpenBSD: patch-meson_build,v 1.1 2020/11/07 08:59:35 jasper Exp $
>
> -ERROR: C shared or static library 'dl' not found
> +- ERROR: C shared or static library 'dl' not found
> +- ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not
> supported
> Index: meson.build
> --- meson.build.orig
> @@ -24,3 +25,27 @@ Index: meson.build
> # Compiler flags
>
> compiler_flags_common = [
> +@@ -221,14 +209,16 @@ add_project_arguments(global_cflags, language:
> 'c',)
> +
> + # Linker flags
> +
> +-linker_flags = [
> +- '-Wl,-Bsymbolic-functions'
> +-]
> ++if get_option('symbolic_functions')
> ++ linker_flags = [
> ++'-Wl,-Bsymbolic-functions'
> ++ ]
> +
> +-foreach flag: linker_flags
> +- assert(cc.has_link_argument(flag), flag + ' is required but not
> supported') +- add_project_link_arguments(flag, language: 'c',)
> +-endforeach
> ++ foreach flag: linker_flags
> ++assert(cc.has_link_argument(flag), flag + ' is required but not
> supported') ++add_project_link_arguments(flag, language: 'c',)
> ++ endforeach
> ++endif
> +
> + # Dependencies
> +
> Index: patches/patch-meson_options_txt
> ===
> RCS file: patches/patch-meson_options_txt
> diff -N patches/patch-meson_options_txt
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-meson_options_txt 25 Nov 2020 19:28:01 -
> @@ -0,0 +1,18 @@
> +$OpenBSD$
> +
> +ERROR: Assert failed: -Wl,-Bsymbolic-functions is required but not
> supported +
> +Index: meson_options.txt
> +--- meson_options.txt.orig
> meson_options.txt
> +@@ -61,3 +61,10 @@ option(
> + value: true,
> + description: 'Enable Vala bindings',
> + )
> ++
> ++option(
> ++ 'symbolic_functions',
> ++ type: 'boolean',
> ++ value: true,
> ++ description: 'Enable bind defined function symbols locally',
> ++)
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2020/11/25 14:32:40 Modified files: textproc/py-snowballstemmer: Makefile distinfo textproc/py-snowballstemmer/pkg: PLIST Log message: update to py-snowballstemmer 2.0.0 >From Aisha Tammy as part of the big batch of diffs to get py-sphinx updated.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 14:24:32 Modified files: net/isc-bind : Tag: OPENBSD_6_8 Makefile distinfo net/isc-bind/patches: Tag: OPENBSD_6_8 patch-bin_dig_dig_c patch-configure_ac patch-lib_isc_unix_socket_c net/isc-bind/pkg: Tag: OPENBSD_6_8 PLIST Log message: update to isc-bind-9.16.9 includes assert crash fixes and others
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 14:22:23 Modified files: net/isc-bind : Makefile Log message: tweak comment
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2020/11/25 14:19:51 Modified files: x11/gnome/gucharmap/patches: patch-meson_build Log message: gucharmap: unbreak on ld.bfd archs The `-Bsymbolic-functions' linker flag is not supported by ld.bfd and broke a configure test. Emit a simple message instead of an assertion error, and use that flag only if the linker is capable. Built and run tested on powerpc. "sure" jasper@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 14:14:43 Modified files: net/isc-bind : Makefile distinfo net/isc-bind/patches: patch-configure_ac net/isc-bind/pkg: PLIST Log message: update to bind-9.16.9
[help needed] net/usockets - needs to link to openssl instead of libressl
Hi, It has come to my attention that upstream does not support libressl and only wants to support openssl https://github.com/uNetworking/uWebSockets/issues/994 I am unsure on how to fix this port. There is no problem right now as the only consumer www/purritobin does not use the SSL functionality in 0.2.4 (the current version in tree). The new updated version www/purritobin-0.3.1 (not yet sent the diff) does use SSL functionality optionally during runtime, which will be broken if net/usockets doesn't get fixed. Can anyone help with fixing this linking? The updated version of usockets and purritobin do work correctly when linked with OpenSSL when used on linux (tested on gentoo). Thanks, Aisha
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 2020/11/25 14:19, Aisha Tammy wrote: > On a side side note: While this consumer is correctly working now, > the upstreams horrible statement still does exist... > Do we want/need to link it to OpenSSL instead? Not if it works. Since the only thing using usockets/uwebsockets in ports at the moment is purritobin it doesn't much matter anyway, but if it was more common then by switching it to linking against OpenSSL would mean that ports using usockets could not be linked to other libraries that pull in libssl/libcrypto (for example most database client libraries) as they would conflict. Switching a build to OpenSSL is really only for special cases where a port really needs something that LibreSSL doesn't/won't support and usually only desirable for 'leaf' ports. Currently only done for nrpe, nsca-ng and sslscan which have particular reasons. > There doesn't seem to be an immediate need but yea... I have no clue > what internal shenanigans happen in OpenSSL vs LibreSSL. Library users shouldn't rely on internals anyway, just use the published API. OpenSSL has some APIs that LibreSSL doesn't - if usockets starts to use one of these then either look at whether the usockets feature requiring it is necessary, maybe it can be disabled in usockets, whether it might make sense to add to libressl, or to stick with an older version of usockets.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 13:01:34 Modified files: net/nagios/nrpe: Makefile Log message: nrpe: bump to be sure that openssl PKGSPEC change causes no problems
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 12:58:48 Modified files: net/nagios/nsca-ng: Makefile distinfo net/nagios/nsca-ng/pkg: PLIST-client PLIST-main Log message: update to nsca-ng-1.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 12:58:32 Modified files: security/openssl/1.0.2: Makefile security/openssl/1.1: Makefile Log message: openssl ports: add PKGSPEC
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On Wed, Nov 25, 2020 at 02:19:38PM -0500, Aisha Tammy wrote:
> On 11/25/20 2:01 PM, Theo Buehler wrote:
> > On Wed, Nov 25, 2020 at 01:12:03PM -0500, Aisha Tammy wrote:
> >> On 11/25/20 12:34 PM, Stuart Henderson wrote:
> >>> On 2020/11/25 12:03, Aisha Tammy wrote:
> Hi,
> It has come to my attention that upstream does not support
> libressl and only wants to support openssl
> https://github.com/uNetworking/uWebSockets/issues/994
>
> I am unsure on how to fix this port.
> There is no problem right now as the only consumer www/purritobin
> does not use the SSL functionality in 0.2.4 (the current version in
> tree).
>
> The new updated version www/purritobin-0.3.1 (not yet sent the diff)
> does use SSL functionality optionally during runtime, which will be
> broken
> if net/usockets doesn't get fixed.
>
> Can anyone help with fixing this linking?
>
> The updated version of usockets and purritobin do work correctly when
> linked with OpenSSL when used on linux (tested on gentoo).
>
> Thanks,
> Aisha
> >>> "LibreSSL seems to be just like most forks are; a joke." lovely.
> >> I know right :(
> >>> what is the actual breakage when trying to use it with libressl?
> >>>
> >>
> >> When doing a paste, with curl, using an SSL connection, the error is:
> >
> > The first thing getting in the way is unveil. You probably don't want to
> > have certificate and key in the storage directory. That won't be fixed
> > by a switch to OpenSSL:
> >
> > /* based and lit method to make sure that nothing goes wrong */
> > #if defined(__OpenBSD__)
> > /* the only directory we need access to is the storage directory */
> > int unveil_err = unveil(storage_directory.c_str(), "rwxc");
> > if (unveil_err != 0) {
> > err(unveil_err, "Error: could not unveil storage folder: %s",
> > storage_directory.c_str());
> > }
> > /* also we only need small amounts of net and socket access */
> > (void)pledge("stdio rpath wpath cpath inet unix", NULL);
> > #endif
> >
> > The library still needs to load certificate and key correctly, which it
> > doesn't (the connection errors out since libssl can't load the cert),
> > but I haven't looked into why that is.
> >
> > https://github.com/openbsd/src/blob/master/lib/libssl/tls13_server.c#L625
> >
> >>
> >> * Trying 73.215.141.174:42069...
> >> * Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0)
> >> * ALPN, offering h2
> >> * ALPN, offering http/1.1
> >> * successfully set certificate verify locations:
> >> * CAfile: /etc/ssl/certs/ca-certificates.crt
> >> * CApath: /etc/ssl/certs
> >> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> >> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> >> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
> >> * TLSv1.3 (IN), TLS alert, handshake failure (552):
> >> * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
> >> * Closing connection 0
> >> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
> >> handshake failure
> >>
> >> Thanks a bunch,
> >> Aisha
> >
>
> OMG! YOU ARE A GENIUS!
> It worked with commenting out the unveil :D :D :D
> That is amazing!!
Oh, great. So I messed up my testing when it didn't load the cert for
me...:)
> It seems I am dumb about not knowing what I write myself...
> Sorry about this :(
No worries. This happens to all of us :)
I ran a test instance under ktrace.
ktrace -di ./purrito -l -d localhost -s /tmp/purritobin/ -k /tmp/localhost.key
-c /tmp/localhost.crt -n localhost
Then looking at the output of kdump showed that opening
/tmp/localhost.key gave ENOENT. The reason for this was then rather
obvious.
> Fixing up the unveil is easy enough now that I know the problem.
Indeed.
> On a side note, am curious about this not being an error during runtime.
> I thought wrong read access would terminate the program :O
Only pledge aborts. As mentioned above, unveil gives ENOENT on access of
hidden files. I'm not entirely sure why the server lib doesn't give a
meaningful error, though. It should...
> On a side side note: While this consumer is correctly working now,
> the upstreams horrible statement still does exist...
> Do we want/need to link it to OpenSSL instead?
I don't think so. From a quick glance, usockets doesn't seem to do
anything particularly fancy libssl-wise. We use OpenSSL in ports only if
there really is no other way (missing API, or occasionally due to major
breakage). This should not happen with a relatively simple webserver.
> There doesn't seem to be an immediate need but yea... I have no clue
> what internal shenanigans happen in OpenSSL vs LibreSSL.
We strive to be a drop-in replacement as far as possible and reasonable.
Things certainly are a far cry from perfect for everyone needing to deal
with this. However, very commonly used things should work mostly the
same way.
(My work on OpenBSD has been
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On Wed, Nov 25, 2020 at 01:12:03PM -0500, Aisha Tammy wrote:
> On 11/25/20 12:34 PM, Stuart Henderson wrote:
> > On 2020/11/25 12:03, Aisha Tammy wrote:
> >> Hi,
> >> It has come to my attention that upstream does not support
> >> libressl and only wants to support openssl
> >> https://github.com/uNetworking/uWebSockets/issues/994
> >>
> >> I am unsure on how to fix this port.
> >> There is no problem right now as the only consumer www/purritobin
> >> does not use the SSL functionality in 0.2.4 (the current version in tree).
> >>
> >> The new updated version www/purritobin-0.3.1 (not yet sent the diff)
> >> does use SSL functionality optionally during runtime, which will be broken
> >> if net/usockets doesn't get fixed.
> >>
> >> Can anyone help with fixing this linking?
> >>
> >> The updated version of usockets and purritobin do work correctly when
> >> linked with OpenSSL when used on linux (tested on gentoo).
> >>
> >> Thanks,
> >> Aisha
> > "LibreSSL seems to be just like most forks are; a joke." lovely.
> I know right :(
> > what is the actual breakage when trying to use it with libressl?
> >
>
> When doing a paste, with curl, using an SSL connection, the error is:
The first thing getting in the way is unveil. You probably don't want to
have certificate and key in the storage directory. That won't be fixed
by a switch to OpenSSL:
/* based and lit method to make sure that nothing goes wrong */
#if defined(__OpenBSD__)
/* the only directory we need access to is the storage directory */
int unveil_err = unveil(storage_directory.c_str(), "rwxc");
if (unveil_err != 0) {
err(unveil_err, "Error: could not unveil storage folder: %s",
storage_directory.c_str());
}
/* also we only need small amounts of net and socket access */
(void)pledge("stdio rpath wpath cpath inet unix", NULL);
#endif
The library still needs to load certificate and key correctly, which it
doesn't (the connection errors out since libssl can't load the cert),
but I haven't looked into why that is.
https://github.com/openbsd/src/blob/master/lib/libssl/tls13_server.c#L625
>
> * Trying 73.215.141.174:42069...
> * Connected to epsilonknot.xyz (73.215.141.174) port 42069 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> * CAfile: /etc/ssl/certs/ca-certificates.crt
> * CApath: /etc/ssl/certs
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
> * TLSv1.3 (IN), TLS alert, handshake failure (552):
> * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
> * Closing connection 0
> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
> failure
>
> Thanks a bunch,
> Aisha
Re: [help needed] net/usockets - needs to link to openssl instead of libressl
On 2020/11/25 12:03, Aisha Tammy wrote: > Hi, > It has come to my attention that upstream does not support > libressl and only wants to support openssl > https://github.com/uNetworking/uWebSockets/issues/994 > > I am unsure on how to fix this port. > There is no problem right now as the only consumer www/purritobin > does not use the SSL functionality in 0.2.4 (the current version in tree). > > The new updated version www/purritobin-0.3.1 (not yet sent the diff) > does use SSL functionality optionally during runtime, which will be broken > if net/usockets doesn't get fixed. > > Can anyone help with fixing this linking? > > The updated version of usockets and purritobin do work correctly when > linked with OpenSSL when used on linux (tested on gentoo). > > Thanks, > Aisha "LibreSSL seems to be just like most forks are; a joke." lovely. what is the actual breakage when trying to use it with libressl?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2020/11/25 09:02:05 Modified files: net/powerdns_recursor: Makefile distinfo Log message: Update to PowerDNS Recursor 4.4.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 08:23:49 Modified files: lang/go: go.port.mk Log message: For MODGO_MODULES ports, don't point the port to fetch files directly from /usr/ports/distfiles when it wants to unpack modules during the build, instead copy the files into the WRKDIR and point it there. If there was a mistake with setting up MODGO_MODULES/MODGO_MODFILES in a port then this change will cause it to show up in build, otherwise it may succeed or fail randomly depending on what files are present in distfiles (fetched by other ports).
[SOLVED] Re: net/zabbix-5.0.5 : Zabbix wrongly reporting down hosts as up
On retrying the upgrade today, planning to upgrade Zabbix with -D snapshot, I found you brought 5.0.5 into -stable. The upgrade went smooth as silk, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 07:26:26 Modified files: security/opensc: Makefile distinfo security/opensc/patches: patch-configure_ac patch-doc_tools_Makefile_am security/opensc/pkg: PLIST Log message: update to OpenSC 0.21.0, various fixes/improvements including CVE-2020-26570, CVE-2020-26571, CVE-2020-26572
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 07:11:17 Modified files: telephony/asterisk: Makefile telephony/asterisk/pkg: README-main Log message: asterisk: AST.pdf is no more, replace the reference in pkg-readme with a link to the official documentation wiki.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 06:54:12 Modified files: net/fastnetmon : Makefile net/fastnetmon/pkg: PLIST Log message: fastnetmon: tidy away some scripts in examples that aren't useful at runtime, @sample the sample exabgp config file (it needs modification in order to use it). ok jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 06:22:42 Modified files: devel/jdk/1.8 : Makefile devel/jdk/1.8/patches: patch-jdk_src_solaris_native_java_net_ExtendedOptionsImpl_c Log message: jdk/1.8: fix "libnet.so: undefined symbol 'socketOptionSupported'" as found by pamela@ and kmos@. ok kurt@
Re: [Update] devel/p5-Time-TimeDate : Update to 2.33
On 2020/11/25 03:23, wen heping wrote: > Hi, ports@: > > Here is a patch for devel/p5-Time-TimeDate to update to 2.33, > it build well and pass all tests on amd64-6.8 system. > Many ports(17) depends on it, I only test 8 of all, no problem met. committed. >And I suggest rename the port and put it to time category as: > devel/p5-Time-TimeDate --> time/p5-TimeDate OpenBSD ports has no time category, and it's a pain moving ports between directories (apart from losing repo history, all ports depending on them need to be updated). Doesn't seem worth the trouble.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/25 06:04:09 Modified files: devel/p5-Time-TimeDate: Makefile distinfo devel/p5-Time-TimeDate/pkg: PLIST Log message: update to p5-Time-TimeDate-2.33, from wen heping
Nono - OpenBSD luna88k
Hello,
Little diff adding aoyama@'s image and explanation to boot OpenBSD luna88k on
nono.
OK? Comments?
Cheers.-
--
- gonzalo
Index: Makefile
===
RCS file: /cvs/ports/emulators/nono/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile20 Nov 2020 19:31:43 - 1.10
+++ Makefile25 Nov 2020 11:09:49 -
@@ -7,6 +7,7 @@ BROKEN-i386=requires __m128i and simil
COMMENT= LUNA-I emulator
DISTNAME= nono-0.1.4
+REVISION= 0
CATEGORIES=emulators
MAINTAINER=Gonzalo L. R.
Index: pkg/README
===
RCS file: /cvs/ports/emulators/nono/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- pkg/README 6 Jul 2020 17:42:25 - 1.1.1.1
+++ pkg/README 25 Nov 2020 11:09:49 -
@@ -38,24 +38,22 @@ For more options you should read the man
| Running OpenBSD on ${PKGSTEM}
+---
-Currently nono's luna88k emulation is under construction.
-It can start OpenBSD/luna88k bsd.rd and bsd but it will stop after
-"WARNING: clock gained ..." line.
+Currently nono's luna88k emulation is under construction, but aoyama@
+build a custom image for ${PKGSTEM}.
-You can use it downloading the bsd or bsd.rd from one of the mirrors
-and place it on ~/nono
+You can follow the README file in:
+
+http://www.nk-home.net/~aoyama/liveimage/
+
+To boot OpenBSD on ${PKGSTEM}.
The config file nono.cfg inside ~/nono should be like:
vmtype = luna88k
luna-dipsw1 =
ram-size = 64MB
-spc0-id0-image = hd,luna88k.img
-
-The luna88k.img could be created with zeros or with vmctl(8), so far
-you will not use it.
+spc0-id6-image = hd,liveimage-luna88k-raw-20201121.img
To turn it on:
-$ nono -c ~/nono -s 0.5 -A bsd.rd
-
+$ nono -c ~/nono -s 0.5 -f -A boot
[ld.bfd] Unbreak x11/gnome/gucharmap
Hi, > http://build-failures.rhaalovely.net/sparc64/2020-11-17/x11/gnome/gucharmap.log (same thing on macppc) This new version of gucharmap "requires" the -Bsymbolic-functions linker flag. Bypassing the check allows to build gucharmap. I didn't bump REVISION; this changes nothing on amd64 and it has never been built on ld.bfd archs. The runtime is fine on macppc. Comments/feedback are welcome, Charlène. [0] https://bin.charlenew.xyz/gucharmap.log Index: patches/patch-meson_build === RCS file: /cvs/ports/x11/gnome/gucharmap/patches/patch-meson_build,v retrieving revision 1.1 diff -u -p -u -p -r1.1 patch-meson_build --- patches/patch-meson_build 7 Nov 2020 08:59:35 - 1.1 +++ patches/patch-meson_build 25 Nov 2020 09:22:44 - @@ -1,6 +1,8 @@ $OpenBSD: patch-meson_build,v 1.1 2020/11/07 08:59:35 jasper Exp $ -ERROR: C shared or static library 'dl' not found +Hunk #1: ERROR: C shared or static library 'dl' not found +Hunk #2: fix the build on ld.bfd archs, where the -Bsymbolic-functions + linker flag is not supported Index: meson.build --- meson.build.orig @@ -24,3 +26,17 @@ Index: meson.build # Compiler flags compiler_flags_common = [ +@@ -226,8 +214,11 @@ linker_flags = [ + ] + + foreach flag: linker_flags +- assert(cc.has_link_argument(flag), flag + ' is required but not supported') +- add_project_link_arguments(flag, language: 'c',) ++ if cc.has_link_argument(flag) ++add_project_link_arguments(flag, language: 'c',) ++ else ++message(flag + ' is not supported') ++ endif + endforeach + + # Dependencies
Re: graphics/makehuman hangs after a while
On Tue, November 24, 2020 14:03, Dimitri Karamazov wrote: > Hi, > > > Ever since a very recent sysupgrade(after months), makehuman tends to hang. > Even the beta version of makehuman repeats the same behaviour. But it doesn't > really output anything for me to post here. Know that this wasn't the case > before. Also blender-1.79 which I never > tested before gives me a segmentation fault. I think this is a intel i915 > issue, since blender 2.90.1 which I have > running stumbles into the same problem, it's hangs after a while. I'll post > the dmesg for that failure. Can some test > to see if they face the same set of problems? > I tried 'intel' driver which worked a little longer which failed the same way. The time interval to failure after starting up the application reduced on subsequents reboots. [ 1415.106] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details [ 1415.106]linear framebuffer access unavailable [ 1415.125] (--) Using wscons driver on /dev/ttyC4 [ 1415.144] X.Org X Server 1.20.8 X Protocol Version 11, Revision 0 [ 1415.144] Build Operating System: OpenBSD 6.8 amd64 [ 1415.144] Current Operating System: OpenBSD orca.iballbatonwifi.com 6.8 GENERIC.MP#188 amd64 [ 1415.144] Build Date: 20 November 2020 06:33:08PM [ 1415.144] [ 1415.144] Current version of pixman: 0.38.4 [ 1415.144]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1415.144] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1415.144] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Nov 25 08:52:03 2020 [ 1415.144] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 1415.144] (==) No Layout section. Using the first Screen section. [ 1415.144] (==) No screen section available. Using defaults. [ 1415.144] (**) |-->Screen "Default Screen Section" (0) [ 1415.144] (**) | |-->Monitor "" [ 1415.145] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 1415.145] (**) | |-->Device "intel" [ 1415.145] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1415.145] (==) Automatically adding devices [ 1415.145] (==) Automatically enabling devices [ 1415.145] (==) Not automatically adding GPU devices [ 1415.145] (==) Max clients allowed: 256, resource mask: 0x1f [ 1415.145] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [ 1415.145] (==) ModulePath set to "/usr/X11R6/lib/modules" [ 1415.145] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [ 1415.145] (II) Loader magic: 0xda625626940 [ 1415.145] (II) Module ABI versions: [ 1415.145]X.Org ANSI C Emulation: 0.4 [ 1415.145]X.Org Video Driver: 24.1 [ 1415.145]X.Org XInput driver : 24.1 [ 1415.145]X.Org Server Extension : 10.0 [ 1415.145] (--) PCI:*(0@0:2:0) 8086:3e91:1458:d000 rev 0, Mem @ 0xf600/16777216, 0xe000/268435456, I/O @ 0xf000/64 [ 1415.145] (II) LoadModule: "glx" [ 1415.146] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [ 1415.147] (II) Module glx: vendor="X.Org Foundation" [ 1415.147]compiled for 1.20.8, module version = 1.0.0 [ 1415.147]ABI class: X.Org Server Extension, version 10.0 [ 1415.147] (II) LoadModule: "intel" [ 1415.148] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so [ 1415.148] (II) Module intel: vendor="X.Org Foundation" [ 1415.148]compiled for 1.20.8, module version = 2.99.916 [ 1415.148]Module class: X.Org Video Driver [ 1415.148]ABI class: X.Org Video Driver, version 24.1 [ 1415.148] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 [ 1415.148] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000 [ 1415.148] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100 [ 1415.148] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300 [ 1415.159] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20200313 [ 1415.160] (WW) intel(0): Unknown chipset [ 1415.160] (--)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/11/25 03:10:59 Modified files: meta/gnome : Makefile Log message: Welcome to GNOME 3.38.2!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/11/25 03:10:28 Modified files: x11/gnome/desktop: Makefile distinfo Log message: Update to gnome-desktop-3.38.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2020/11/25 01:12:52 Modified files: databases/p5-SQL-Abstract-Limit: Makefile distinfo Log message: Update to p5-SQL-Abstract-Limit-0.142.
