CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2024/03/08 00:48:02

Modified files:
net/nextcloudclient: Makefile distinfo 

Log message:
net/nextcloudclient: update to 3.12.1, from MAINTAINER Adriano Barbosa

see https://github.com/nextcloud/desktop/releases/v3.12.1

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2024/03/08 00:40:15

Modified files:
graphics/openexr: Makefile distinfo 
graphics/openexr/pkg: PLIST-tools 

Log message:
Update to OpenEXR-3.2.3.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2024/03/08 00:39:54

Modified files:
devel/pango: Makefile distinfo 

Log message:
Update to pango-1.52.1.

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2024/03/08 00:39:01

Modified files:
mail/postfix/stable35: Makefile distinfo 

Log message:
update to postfix-3.5.25, ok tb@ Brad
(This is the last release of the 3.5 branch which is still
compatible with libressl, which we need to keep around because
there are issues with the versions using openssl when combined
with libraries that use libressl)

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2024/03/08 00:36:24

Modified files:
mail/postfix/stable: Makefile distinfo 

Log message:
update to postfix-3.8.6, ok tb@ Brad

UPDATE: libde265 1.0.15

[Brad Smith]

Here is an update to libde265 1.0.15.

CVE-2020-21594-CVE-2020-21606, CVE-2022-1253, CVE-2022-43236-CVE-2022-43253,
CVE-2022-47655, CVE-2023-27102l, CVE-2023-27103, CVE-2023-49465, CVE-2023-49467,
CVE-2023-49468


Index: Makefile
===
RCS file: /cvs/ports/multimedia/libde265/Makefile,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile
--- Makefile27 Sep 2023 10:10:20 -  1.11
+++ Makefile8 Mar 2024 07:01:03 -
@@ -1,14 +1,12 @@
 COMMENT-main=  open H.265 video codec implementation
 COMMENT-tools= tools for libde265 open H.265 video codec
 
-V= 1.0.8
+V= 1.0.15
 DISTNAME=  libde265-$V
 PKGNAME-main=  ${DISTNAME}
 PKGNAME-tools= libde265-tools-$V
 
-REVISION-tools=0
-
-SHARED_LIBS +=  de265 1.0 # 0.12
+SHARED_LIBS +=  de265 2.0 # 0.12
 
 CATEGORIES=multimedia
 
@@ -20,13 +18,14 @@ PERMIT_PACKAGE= Yes
 WANTLIB += ${COMPILER_LIBCXX} m
 
 WANTLIB-tools += ${WANTLIB}
-WANTLIB-tools += GL Qt5Core Qt5Gui Qt5Widgets SDL X11 X11-xcb Xau
-WANTLIB-tools += Xdmcp Xext Xfixes Xxf86vm avutil c de265 double-conversion
-WANTLIB-tools += drm execinfo expat freetype glapi glib-2.0 graphite2
-WANTLIB-tools += gthread-2.0 harfbuzz iconv icudata icui18n icuuc
-WANTLIB-tools += intl pcre2-8 pcre2-16 png sndio swscale usbhid xcb xcb-dri2
-WANTLIB-tools += xcb-dri3 xcb-glx xcb-present xcb-sync xcb-xfixes xshmfence
-WANTLIB-tools += z zstd xcb-shm
+WANTLIB-tools += GL Qt5Core Qt5Gui Qt5Widgets SDL2 X11 X11-xcb Xau Xcursor
+WANTLIB-tools += Xdmcp Xext Xfixes Xi Xrandr Xrender Xss Xxf86vm avutil
+WANTLIB-tools += c de265 double-conversion drm execinfo expat freetype
+WANTLIB-tools += glapi glib-2.0 graphite2 gthread-2.0 harfbuzz iconv
+WANTLIB-tools += icudata icui18n icuuc intl pcre2-16 pcre2-8 png samplerate
+WANTLIB-tools += sndio swscale usbhid xcb xcb-dri2 xcb-dri3 xcb-glx
+WANTLIB-tools += xcb-present xcb-randr xcb-shm xcb-sync xcb-xfixes xshmfence
+WANTLIB-tools += z zstd
 
 MULTI_PACKAGES=-main -tools
 
@@ -42,7 +41,7 @@ LIB_DEPENDS-main= ${LIB_DEPENDS}
 
 LIB_DEPENDS-tools= ${LIB_DEPENDS} \
multimedia/libde265,-main \
-   devel/sdl \
+   devel/sdl2 \
graphics/ffmpeg \
x11/qt5/qtbase
 
Index: distinfo
===
RCS file: /cvs/ports/multimedia/libde265/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo6 May 2022 05:38:46 -   1.3
+++ distinfo8 Mar 2024 07:01:03 -
@@ -1,2 +1,2 @@
-SHA256 (libde265-1.0.8.tar.gz) = JMeR3TNPpSF2IyD/VPD+v9PAn8l4iAqMX7xAqI8h2QU=
-SIZE (libde265-1.0.8.tar.gz) = 837878
+SHA256 (libde265-1.0.15.tar.gz) = ACUZhsKdNNOvcRftBYdJUMh13ZKS0Ba+KdOzdiZmUR0=
+SIZE (libde265-1.0.15.tar.gz) = 846016
Index: patches/patch-acceleration-speed_Makefile_in
===
RCS file: 
/cvs/ports/multimedia/libde265/patches/patch-acceleration-speed_Makefile_in,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-acceleration-speed_Makefile_in
--- patches/patch-acceleration-speed_Makefile_in11 Mar 2022 19:39:20 
-  1.2
+++ patches/patch-acceleration-speed_Makefile_in8 Mar 2024 07:01:03 
-
@@ -1,7 +1,7 @@
 Index: acceleration-speed/Makefile.in
 --- acceleration-speed/Makefile.in.orig
 +++ acceleration-speed/Makefile.in
-@@ -358,7 +358,7 @@ AM_CPPFLAGS = -I$(top_srcdir)/libde265 -I$(top_srcdir)
+@@ -363,7 +363,7 @@ AM_CPPFLAGS = -I$(top_srcdir)/libde265 -I$(top_srcdir)
  acceleration_speed_DEPENDENCIES = ../libde265/libde265.la
  acceleration_speed_CXXFLAGS = 
  acceleration_speed_LDFLAGS = 
Index: patches/patch-dec265_Makefile_in
===
RCS file: /cvs/ports/multimedia/libde265/patches/patch-dec265_Makefile_in,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-dec265_Makefile_in
--- patches/patch-dec265_Makefile_in11 Mar 2022 19:39:20 -  1.2
+++ patches/patch-dec265_Makefile_in8 Mar 2024 07:01:03 -
@@ -1,18 +1,12 @@
 Index: dec265/Makefile.in
 --- dec265/Makefile.in.orig
 +++ dec265/Makefile.in
-@@ -361,12 +361,12 @@ AM_CPPFLAGS = -I$(top_srcdir)/libde265 -I$(top_srcdir)
+@@ -364,7 +364,7 @@ AM_CPPFLAGS = -I$(top_srcdir)/libde265 -I$(top_srcdir)
  dec265_DEPENDENCIES = ../libde265/libde265.la
  dec265_CXXFLAGS = $(am__append_1) $(am__append_3)
  dec265_LDFLAGS = $(am__append_2) $(am__append_4) $(am__append_6)
 -dec265_LDADD = ../libde265/libde265.la -lstdc++
 +dec265_LDADD = ../libde265/libde265.la
  dec265_SOURCES = dec265.cc $(am__append_5)
- hdrcopy_DEPENDENCIES = ../libde265/libde265.la
- hdrcopy_CXXFLAGS = 
- hdrcopy_LDFLAGS = 
--hdrcopy_LDADD = ../libde265/libde265.la -lstdc++
-+hdrcopy_LDADD = ../libde265/libde265.la
- hdrcopy_SOURCES = hdrcopy.cc
  EXTRA_DIST = Makefile.vc7 \
CMakeLists.txt \

Re: UPDATE: libheif 1.17.6

[Brad Smith]

On Tue, Feb 27, 2024 at 08:35:07PM -0500, Brad Smith wrote:
> Here is an update to libheif 1.17.6.
> 
> CVE-2023-49462, CVE-2023-49463
 
Enable the minimal tests that are there.


Index: Makefile
===
RCS file: /cvs/ports/multimedia/libheif/Makefile,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 Makefile
--- Makefile23 Oct 2023 06:47:18 -  1.15
+++ Makefile8 Mar 2024 05:26:00 -
@@ -1,10 +1,9 @@
 COMMENT=   HEIF and AVIF file format decoder and encoder
 
-V= 1.16.2
+V= 1.17.6
 DISTNAME=  libheif-$V
-REVISION=  1
 
-SHARED_LIBS +=  heif 1.6
+SHARED_LIBS +=  heif 2.0
 
 CATEGORIES=multimedia graphics
 
@@ -28,14 +27,15 @@ LIB_DEPENDS=graphics/gdk-pixbuf2 \
multimedia/aom \
multimedia/dav1d \
multimedia/libde265 \
+   graphics/jpeg \
multimedia/x265
 # examples
-LIB_DEPENDS+=  graphics/jpeg \
-   graphics/png
+LIB_DEPENDS+=  graphics/png
 
-CONFIGURE_ARGS= -DWITH_RAV1E=Off \
+CONFIGURE_ARGS= -DWITH_DAV1D=On \
+   -DWITH_JPEG_DECODER=On \
+   -DWITH_JPEG_ENCODER=On \
+   -DWITH_RAV1E=Off \
-DWITH_SvtEnc=Off
-
-NO_TEST=   Yes
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/multimedia/libheif/distinfo,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 distinfo
--- distinfo4 Sep 2023 09:52:02 -   1.8
+++ distinfo8 Mar 2024 05:26:00 -
@@ -1,2 +1,2 @@
-SHA256 (libheif-1.16.2.tar.gz) = f5fkIFwL2fm4VgU2yL0uhB0cmm1hBAHrPrh+2c3+eOo=
-SIZE (libheif-1.16.2.tar.gz) = 1339068
+SHA256 (libheif-1.17.6.tar.gz) = g5C69JE+2goYPhMs7GK4dfsu9QfO1d3dyY39Lxd4Cu4=
+SIZE (libheif-1.17.6.tar.gz) = 1433302
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/multimedia/libheif/patches/patch-CMakeLists_txt,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt4 Sep 2023 12:25:08 -   1.1
+++ patches/patch-CMakeLists_txt8 Mar 2024 05:26:00 -
@@ -1,7 +1,7 @@
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -22,7 +22,6 @@ endif()
+@@ -28,7 +28,6 @@ endif()
  
  if(NOT MSVC)
add_definitions(-Wall)
Index: pkg/PLIST
===
RCS file: /cvs/ports/multimedia/libheif/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST   23 Oct 2023 06:47:18 -  1.6
+++ pkg/PLIST   8 Mar 2024 05:26:00 -
@@ -6,6 +6,8 @@ include/libheif/
 include/libheif/heif.h
 include/libheif/heif_cxx.h
 include/libheif/heif_plugin.h
+include/libheif/heif_properties.h
+include/libheif/heif_regions.h
 include/libheif/heif_version.h
 lib/cmake/libheif/
 lib/cmake/libheif/libheif-config${MODCMAKE_BUILD_SUFFIX}
@@ -14,6 +16,7 @@ lib/cmake/libheif/libheif-config.cmake
 @so lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-heif.so
 lib/libheif/
 @lib lib/libheif.so.${LIBheif_VERSION}
+@so lib/libheif/libheif-dav1d.so
 lib/pkgconfig/libheif.pc
 @man man/man1/heif-convert.1
 @man man/man1/heif-enc.1

Re: devel/libffi: arm64 BTI fix

[Theo de Raadt]

Crazy.  Looks good.


Mark Kettenis  wrote:

> This one was a bit tricky as I had to adjust the offsets used in the
> instructions.  But with this lang/guile3 no longer generates SIGILL
> when running the tests.
> 
> ok?
> 
> 
> Index: devel/libffi/Makefile
> ===
> RCS file: /cvs/ports/devel/libffi/Makefile,v
> retrieving revision 1.49
> diff -u -p -r1.49 Makefile
> --- devel/libffi/Makefile 22 Nov 2023 14:18:03 -  1.49
> +++ devel/libffi/Makefile 7 Mar 2024 22:06:25 -
> @@ -1,7 +1,7 @@
>  COMMENT= Foreign Function Interface
>  
>  V=   3.4.4
> -REVISION=0
> +REVISION=1
>  DISTNAME=libffi-$V
>  SHARED_LIBS +=  ffi  2.0  # 9.2
>  CATEGORIES=  devel
> Index: devel/libffi/patches/patch-src_aarch64_ffi_c
> ===
> RCS file: /cvs/ports/devel/libffi/patches/patch-src_aarch64_ffi_c,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_aarch64_ffi_c
> --- devel/libffi/patches/patch-src_aarch64_ffi_c  22 Nov 2023 14:18:03 
> -  1.1
> +++ devel/libffi/patches/patch-src_aarch64_ffi_c  7 Mar 2024 22:06:25 
> -
> @@ -74,3 +74,15 @@ Index: src/aarch64/ffi.c
>   : "memory", "v16", "v17", "v18", "v19");
>   }
>   #endif
> +@@ -873,8 +885,9 @@ ffi_prep_closure_loc (ffi_closure *closure,
> + # endif
> + #else
> +   static const unsigned char trampoline[16] = {
> +-0x90, 0x00, 0x00, 0x58, /* ldr  x16, tramp+16   */
> +-0xf1, 0xff, 0xff, 0x10, /* adr  x17, tramp+0*/
> ++0x5f, 0x24, 0x03, 0xd5, /* bti  c   */
> ++0x70, 0x00, 0x00, 0x58, /* ldr  x16, tramp+16   */
> ++0xd1, 0xff, 0xff, 0x10, /* adr  x17, tramp+0*/
> + 0x00, 0x02, 0x1f, 0xd6  /* br   x16 */
> +   };
> +   char *tramp = closure->tramp;
> 

postfix 3.5.25, 3.8.6

[Stuart Henderson]

Updates to 3.5.25 (last release on the mostly libressl-compatible 3.5
branch) and 3.8.6. OK?


Index: stable/Makefile
===
RCS file: /cvs/ports/mail/postfix/stable/Makefile,v
diff -u -p -r1.259 Makefile
--- stable/Makefile 25 Feb 2024 10:16:25 -  1.259
+++ stable/Makefile 7 Mar 2024 23:19:18 -
@@ -1,5 +1,4 @@
-VERSION=   3.8.5
-REVISION=  0
+VERSION=   3.8.6
 
 EPOCH= 0
 
Index: stable/distinfo
===
RCS file: /cvs/ports/mail/postfix/stable/distinfo,v
diff -u -p -r1.155 distinfo
--- stable/distinfo 22 Feb 2024 13:46:34 -  1.155
+++ stable/distinfo 7 Mar 2024 23:19:18 -
@@ -1,2 +1,2 @@
-SHA256 (postfix/postfix-3.8.5.tar.gz) = 
8+gnorLkEDWa0l0xNBlwQ0qwfjYTn5ou+TmBsOxWTIU=
-SIZE (postfix/postfix-3.8.5.tar.gz) = 4871284
+SHA256 (postfix/postfix-3.8.6.tar.gz) = 
S24XyCbMQ4zDAWqcClXqfnfGy6+6fdVyQdgbaQsOl3Q=
+SIZE (postfix/postfix-3.8.6.tar.gz) = 4873054
Index: stable35/Makefile
===
RCS file: /cvs/ports/mail/postfix/stable35/Makefile,v
diff -u -p -r1.8 Makefile
--- stable35/Makefile   22 Feb 2024 13:45:28 -  1.8
+++ stable35/Makefile   7 Mar 2024 23:19:18 -
@@ -1,4 +1,4 @@
-VERSION=   3.5.24
+VERSION=   3.5.25
 
 PORTROACH= site:https://ftp.fu-berlin.de/unix/mail/postfix/official/
 SITES= ${SITE_POSTFIX:=official/}
Index: stable35/distinfo
===
RCS file: /cvs/ports/mail/postfix/stable35/distinfo,v
diff -u -p -r1.3 distinfo
--- stable35/distinfo   22 Feb 2024 13:45:28 -  1.3
+++ stable35/distinfo   7 Mar 2024 23:19:18 -
@@ -1,2 +1,2 @@
-SHA256 (postfix/postfix-3.5.24.tar.gz) = 
umSo7WcNm9Q8xBmfAeuboDLLqPBAHF9S80GeL3H8Z5c=
-SIZE (postfix/postfix-3.5.24.tar.gz) = 4656922
+SHA256 (postfix/postfix-3.5.25.tar.gz) = 
YYvU3nqrPRR2Pu2T2Teo6/cs+hhqJnUedGN0jXi3edg=
+SIZE (postfix/postfix-3.5.25.tar.gz) = 4660537

Re: rebar3 - add quirk

[Stuart Henderson]

On 2024/03/07 18:42, Volker Schlecht wrote:
> Adds a quirk for the renamed rebar3 package, which I missed in the update.
> 
> ok?
> 

> Index: files/Quirks.pm
> ===
> RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
> retrieving revision 1.1614
> diff -u -p -r1.1614 Quirks.pm
> --- files/Quirks.pm   29 Feb 2024 01:01:12 -  1.1614
> +++ files/Quirks.pm   29 Feb 2024 17:07:12 -
> @@ -812,6 +812,7 @@ my $stem_extensions = {
>   'unison' => 'unison-gui',
>   'sendxmpp' => 'go-sendxmpp',
>   'libreddit' => 'redlib',
> + 'rebar3' => 'erl25-rebar3',
>  };
>  
>  my $obsolete_reason = {};


REVISION bump then it's ok.

Re: erlang.port.mk

[Stuart Henderson]

On 2024/03/07 18:38, Volker Schlecht wrote:
> Fixes a typo in erlang.port.mk.
> Identified, patch proposed by sthen@
> 
> ok?

Reads OK but I have not tried building anything with it.

> Index: erlang.port.mk
> ===
> RCS file: /cvs/ports/lang/erlang/erlang.port.mk,v
> retrieving revision 1.38
> diff -u -p -r1.38 erlang.port.mk
> --- erlang.port.mk12 Feb 2024 17:02:09 -  1.38
> +++ erlang.port.mk29 Feb 2024 17:03:31 -
> @@ -30,7 +30,7 @@ FULLPKGNAME ?=  ${MODERL_PKG_PREFIX}-${PK
>  
>  FLAVOR ?=
>  .if empty(FLAVOR)
> -FLAVOR = ${MODERL_DEFAULT_FLAVOR}
> +FLAVOR = ${_MODERL_DEFAULT_FLAVOR}
>  .endif
>  .  endif
>  .endif

Re: devel/libffi: arm64 BTI fix

[Tobias Heider]

On March 7, 2024 11:27:38 PM GMT+01:00, Mark Kettenis  
wrote:
>This one was a bit tricky as I had to adjust the offsets used in the
>instructions.  But with this lang/guile3 no longer generates SIGILL
>when running the tests.
>
>ok?

ok tobhe@

>
>
>Index: devel/libffi/Makefile
>===
>RCS file: /cvs/ports/devel/libffi/Makefile,v
>retrieving revision 1.49
>diff -u -p -r1.49 Makefile
>--- devel/libffi/Makefile  22 Nov 2023 14:18:03 -  1.49
>+++ devel/libffi/Makefile  7 Mar 2024 22:06:25 -
>@@ -1,7 +1,7 @@
> COMMENT=  Foreign Function Interface
> 
> V=3.4.4
>-REVISION= 0
>+REVISION= 1
> DISTNAME= libffi-$V
> SHARED_LIBS +=  ffi  2.0  # 9.2
> CATEGORIES=   devel
>Index: devel/libffi/patches/patch-src_aarch64_ffi_c
>===
>RCS file: /cvs/ports/devel/libffi/patches/patch-src_aarch64_ffi_c,v
>retrieving revision 1.1
>diff -u -p -r1.1 patch-src_aarch64_ffi_c
>--- devel/libffi/patches/patch-src_aarch64_ffi_c   22 Nov 2023 14:18:03 
>-  1.1
>+++ devel/libffi/patches/patch-src_aarch64_ffi_c   7 Mar 2024 22:06:25 
>-
>@@ -74,3 +74,15 @@ Index: src/aarch64/ffi.c
>  : "memory", "v16", "v17", "v18", "v19");
>  }
>  #endif
>+@@ -873,8 +885,9 @@ ffi_prep_closure_loc (ffi_closure *closure,
>+ # endif
>+ #else
>+   static const unsigned char trampoline[16] = {
>+-0x90, 0x00, 0x00, 0x58,  /* ldr  x16, tramp+16   */
>+-0xf1, 0xff, 0xff, 0x10,  /* adr  x17, tramp+0*/
>++0x5f, 0x24, 0x03, 0xd5,  /* bti  c   */
>++0x70, 0x00, 0x00, 0x58,  /* ldr  x16, tramp+16   */
>++0xd1, 0xff, 0xff, 0x10,  /* adr  x17, tramp+0*/
>+ 0x00, 0x02, 0x1f, 0xd6   /* br   x16 */
>+   };
>+   char *tramp = closure->tramp;
>

devel/libffi: arm64 BTI fix

[Mark Kettenis]

This one was a bit tricky as I had to adjust the offsets used in the
instructions.  But with this lang/guile3 no longer generates SIGILL
when running the tests.

ok?


Index: devel/libffi/Makefile
===
RCS file: /cvs/ports/devel/libffi/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- devel/libffi/Makefile   22 Nov 2023 14:18:03 -  1.49
+++ devel/libffi/Makefile   7 Mar 2024 22:06:25 -
@@ -1,7 +1,7 @@
 COMMENT=   Foreign Function Interface
 
 V= 3.4.4
-REVISION=  0
+REVISION=  1
 DISTNAME=  libffi-$V
 SHARED_LIBS +=  ffi  2.0  # 9.2
 CATEGORIES=devel
Index: devel/libffi/patches/patch-src_aarch64_ffi_c
===
RCS file: /cvs/ports/devel/libffi/patches/patch-src_aarch64_ffi_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_aarch64_ffi_c
--- devel/libffi/patches/patch-src_aarch64_ffi_c22 Nov 2023 14:18:03 
-  1.1
+++ devel/libffi/patches/patch-src_aarch64_ffi_c7 Mar 2024 22:06:25 
-
@@ -74,3 +74,15 @@ Index: src/aarch64/ffi.c
  : "memory", "v16", "v17", "v18", "v19");
  }
  #endif
+@@ -873,8 +885,9 @@ ffi_prep_closure_loc (ffi_closure *closure,
+ # endif
+ #else
+   static const unsigned char trampoline[16] = {
+-0x90, 0x00, 0x00, 0x58,   /* ldr  x16, tramp+16   */
+-0xf1, 0xff, 0xff, 0x10,   /* adr  x17, tramp+0*/
++0x5f, 0x24, 0x03, 0xd5,   /* bti  c   */
++0x70, 0x00, 0x00, 0x58,   /* ldr  x16, tramp+16   */
++0xd1, 0xff, 0xff, 0x10,   /* adr  x17, tramp+0*/
+ 0x00, 0x02, 0x1f, 0xd6/* br   x16 */
+   };
+   char *tramp = closure->tramp;

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2024/03/07 15:07:14

Modified files:
www/sogo   : Makefile distinfo 
www/sogo/pkg   : PLIST 
Added files:
www/sogo/patches: patch-Tools_SOGoToolUpdateSecret_m 

Log message:
update 5.9.1 -> 5.10.0

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2024/03/07 15:05:45

Modified files:
www/sope   : Makefile distinfo 
Removed files:
www/sope/patches: patch-sope-mime_NGMime_NGMimeType_m 

Log message:
update 5.9.1 -> 5.10.0

[NEW] devel/opendht-3.1.7

[SASANO Takayoshi]

Hi,

Here is the port of OpenDHT-3.1.7, without tools and Python support.
To build, it requires devel/msgpack-cxx I sent previously.


SASANO Takayoshi (JG1UAA) 



opendht.tgz
Description: Binary data

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2024/03/07 13:59:30

Modified files:
www/puppetboard: Makefile distinfo 

Log message:
update 5.3.0 -> 5.4.0

Re: [new] www/pipe-viewer

[Stefan Moran]

On Wed, 06 Mar 2024 16:42:51 +0100
Omar Polo  wrote:

> Hello,
> 
> On 2024/03/04 22:38:23 +, Klemens Nanni  wrote:
> > On Mon, Mar 04, 2024 at 05:21:52PM -0500, Stefan Moran wrote:  
> > > Attached is a port for www/pipe-viewer 0.5.0, a lightweight perl
> > > youtube client, designed to be used without a Google API key. The
> > > port is a multipackage with -gtk, a GTK3 frontend using
> > > x11/p5-Gtk3, and -main, the standard cli interface. The port
> > > depends on either youtube-dl or yt-dlp to fetch videos, and I
> > > chose to include www/yt-dlp as a rundep as that seems to be the
> > > more heavily-maintained and functional ( and also less
> > > legally-targeted ;) ) project at this point in time. I also chose
> > > to include most of the optional dependencies, excluding
> > > LWP::UserAgent::Cached (not currently ported).
> > > 
> > > https://github.com/trizen/pipe-viewer  
> > 
> > Port-wise looks fine, although I'd capitalise youtube in COMMENT
> > accordingly and distinguish DESCR-gtk from DESCR-main.
> > Perhaps add multimedia, net and/or x11 to CATEGORIES?  
> 
> +1
> 
> I'd also try to have a slightly different COMMENT for the -gtk
> subpackage and change its name to gkt-pipe-viewer to mirror the name
> of the binary it installs.
> 
> When it makes sense, I think it's easier for discovery purposes to
> have the name of the package to be the same of the program it
> installs.
> 
> > Starts, searches and plays fine in brief testing, seems like a handy
> > alternative to the (heavy) Qt alternatives minitube and plasmatube.
> >  
> 
> some here, briefly tried but I'm liking it, it could become my
> preferred way to navigate youtube :)
> 
> I'm attaching a diff against your makefile and an updated tarball
> that's ok op@ to import.
> 
> while here i've changed to port to use DIST_TUPLE rather than GH_* and
> re-run make makesum due to it.  I've also tried to change the two
> DESCR a bit, to reiterate which one has a GTK interface and which
> don't.
> 
> 
> --- Makefile.orig Wed Mar  6 15:02:57 2024
> +++ Makefile  Wed Mar  6 16:33:07 2024
> @@ -1,17 +1,14 @@
> -COMMENT-main =   lightweight perl youtube client
> -COMMENT-gtk =lightweight perl youtube client
> +COMMENT-main =   lightweight YouTube client
> +COMMENT-gtk =lightweight YouTube client with a GTK interface
>  
>  VERSION =0.5.0
> +DIST_TUPLE = github trizen pipe-viewer ${VERSION} .
>  PKGNAME-main =   pipe-viewer-${VERSION}
> -PKGNAME-gtk =pipe-viewer-gtk-${VERSION}
> +PKGNAME-gtk =gtk-pipe-viewer-${VERSION}
>  
>  MULTI_PACKAGES = -main -gtk
>  
> -GH_ACCOUNT = trizen
> -GH_PROJECT = pipe-viewer
> -GH_TAGNAME = ${VERSION}
> -
> -CATEGORIES = www
> +CATEGORIES = www multimedia

Patch and suggested changes look good to me, only thing I'm a bit
skeptical about is the multimedia tag, since this port just calls on
external rundeps (mpv, youtube-dl/yt-dlp) to fetch and playback
streams, and doesn't really do anything I'd classify as multimedia
itself. www/minitube does something similar to this port, and is also
tagged multimedia though, so maybe this port should be tagged
multimedia too just for consistency.

>  
>  MAINTAINER = Stefan Moran 
>  
> 

Re: [Maintainer Update] print/ghostscript/gnu 10.03.0

[Matthias Kilian]

Hi,

On Thu, Mar 07, 2024 at 07:20:11PM +0100, Volker Schlecht wrote:
> Updates print/ghostscript/gnu to latest release 10.03.0
> 
> This is marked as a security release, but the only documented vulnerability
> affects builds with tesseract enabled. In our port we disable it, so we seem
> to be unaffected.
> 
> https://ghostscript.readthedocs.io/en/gs10.03.0/News.html
> 
> Built and tested on amd64. print/lilypond in particular still builds :-)

Just FYI: the next gs release may need some extra testing with lilypond
;-)

https://lists.gnu.org/archive/html/lilypond-devel/2024-03/msg1.html

> ok?

Yes.

Ciao,
Kili

> Index: Makefile
> ===
> RCS file: /cvs/ports/print/ghostscript/gnu/Makefile,v
> retrieving revision 1.129
> diff -u -p -r1.129 Makefile
> --- Makefile  3 Nov 2023 10:53:15 -   1.129
> +++ Makefile  7 Mar 2024 18:13:52 -
> @@ -1,10 +1,10 @@
>  COMMENT =PostScript and PDF interpreter
>  
> -VERSION =10.02.1
> +VERSION =10.03.0
>  DISTNAME =   ghostscript-${VERSION}
>  EXTRACT_SUFX =   .tar.xz
>  CATEGORIES = lang print
> -SHARED_LIBS =gs 18.1
> +SHARED_LIBS =gs 18.2
>  
>  SITES =  
> https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs${VERSION:S/.//g}/
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/print/ghostscript/gnu/distinfo,v
> retrieving revision 1.24
> diff -u -p -r1.24 distinfo
> --- distinfo  3 Nov 2023 10:53:15 -   1.24
> +++ distinfo  7 Mar 2024 18:13:52 -
> @@ -1,2 +1,2 @@
> -SHA256 (ghostscript-10.02.1.tar.xz) = 
> jFjJSLByG+zvzQApyNuV+bsyaK/8JeoB1MWmsH+hqwg=
> -SIZE (ghostscript-10.02.1.tar.xz) = 68017088
> +SHA256 (ghostscript-10.03.0.tar.xz) = 
> 8l/0kacm2IPwsPnIr5uJXGdM93zd2BSqOCSzIj9DnuU=
> +SIZE (ghostscript-10.03.0.tar.xz) = 68041176
> Index: patches/patch-configure
> ===
> RCS file: /cvs/ports/print/ghostscript/gnu/patches/patch-configure,v
> retrieving revision 1.7
> diff -u -p -r1.7 patch-configure
> --- patches/patch-configure   25 Sep 2023 07:55:12 -  1.7
> +++ patches/patch-configure   7 Mar 2024 18:13:52 -
> @@ -1,7 +1,7 @@
>  Index: configure
>  --- configure.orig
>  +++ configure
> -@@ -13149,8 +13149,8 @@ DLL_EXT=""
> +@@ -13158,8 +13158,8 @@ DLL_EXT=""
>   SO_LIB_VERSION_SEPARATOR="."
>   
>   libname1="_SO_BASE)\$(GS_SOEXT)\$(DLL_EXT)"
> @@ -12,7 +12,7 @@ Index: configure
>   GS_SONAME="lib\$(GS${libname1}"
>   GS_SONAME_MAJOR="lib\$(GS${libname2}"
>   GS_SONAME_MAJOR_MINOR="lib\$(GS${libname3}"
> -@@ -13262,11 +13262,11 @@ case $host in
> +@@ -13271,11 +13271,11 @@ case $host in
>   ;;
>   *bsd*)
> DYNAMIC_CFLAGS="-fPIC $DYNAMIC_CFLAGS"

CVS: cvs.openbsd.org: ports

[Caspar Schutijser]

CVSROOT:/cvs
Module name:ports
Changes by: cas...@cvs.openbsd.org  2024/03/07 12:56:40

Modified files:
net/snowflake_proxy: Makefile distinfo modules.inc 

Log message:
net/snowflake_proxy: update to 2.9.1

CVS: cvs.openbsd.org: ports

[Caspar Schutijser]

CVSROOT:/cvs
Module name:ports
Changes by: cas...@cvs.openbsd.org  2024/03/07 12:44:48

Modified files:
meta/tor-browser: Tag: OPENBSD_7_4 Makefile 
www/tor-browser: Tag: OPENBSD_7_4 Makefile.inc 
www/tor-browser/browser: Tag: OPENBSD_7_4 Makefile distinfo 

Log message:
Tor Browser: update to 13.0.11

CVS: cvs.openbsd.org: ports

[Caspar Schutijser]

CVSROOT:/cvs
Module name:ports
Changes by: cas...@cvs.openbsd.org  2024/03/07 12:43:58

Modified files:
meta/tor-browser: Makefile 
www/tor-browser: Makefile.inc 
www/tor-browser/browser: Makefile distinfo 

Log message:
Tor Browser: update to 13.0.11

[Maintainer Update] lang/gleam 1.0.0

[Volker Schlecht]

Updates lang/gleam to the recently released version 1.0.0

Built and tested on amd64, tests run fine, gleam works.

ok?
Index: Makefile
===
RCS file: /cvs/ports/lang/gleam/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile22 Oct 2023 12:47:41 -  1.6
+++ Makefile7 Mar 2024 17:48:58 -
@@ -2,7 +2,7 @@ COMMENT =   statically typed language for
 
 GH_ACCOUNT =   gleam-lang
 GH_PROJECT =   gleam
-GH_TAGNAME =   v0.31.0
+GH_TAGNAME =   v1.0.0
 
 HOMEPAGE = https://gleam.run
 
Index: crates.inc
===
RCS file: /cvs/ports/lang/gleam/crates.inc,v
retrieving revision 1.4
diff -u -p -r1.4 crates.inc
--- crates.inc  22 Oct 2023 12:47:41 -  1.4
+++ crates.inc  7 Mar 2024 17:48:58 -
@@ -1,292 +1,301 @@
 MODCARGO_CRATES += addr2line   0.21.0  # Apache-2.0 OR MIT
 MODCARGO_CRATES += adler   1.0.2   # 0BSD OR MIT OR Apache-2.0
-MODCARGO_CRATES += aho-corasick1.0.4   # Unlicense OR MIT
-MODCARGO_CRATES += askama  0.12.0  # MIT OR Apache-2.0
-MODCARGO_CRATES += askama_derive   0.12.1  # MIT/Apache-2.0
+MODCARGO_CRATES += aho-corasick1.1.2   # Unlicense OR MIT
+MODCARGO_CRATES += askama  0.12.1  # MIT OR Apache-2.0
+MODCARGO_CRATES += askama_derive   0.12.5  # MIT/Apache-2.0
 MODCARGO_CRATES += askama_escape   0.10.3  # MIT OR Apache-2.0
+MODCARGO_CRATES += askama_parser   0.2.1   # MIT OR Apache-2.0
 MODCARGO_CRATES += asn1-rs 0.5.2   # MIT/Apache-2.0
 MODCARGO_CRATES += asn1-rs-derive  0.4.0   # MIT/Apache-2.0
 MODCARGO_CRATES += asn1-rs-impl0.1.0   # MIT/Apache-2.0
-MODCARGO_CRATES += async-trait 0.1.73  # MIT OR Apache-2.0
+MODCARGO_CRATES += async-trait 0.1.77  # MIT OR Apache-2.0
 MODCARGO_CRATES += atty0.2.14  # MIT
 MODCARGO_CRATES += autocfg 1.1.0   # Apache-2.0 OR MIT
 MODCARGO_CRATES += backtrace   0.3.69  # MIT OR Apache-2.0
 MODCARGO_CRATES += base16  0.2.1   # CC0-1.0
 MODCARGO_CRATES += base64  0.13.1  # MIT/Apache-2.0
-MODCARGO_CRATES += base64  0.21.3  # MIT OR Apache-2.0
-MODCARGO_CRATES += basic-toml  0.1.4   # MIT OR Apache-2.0
+MODCARGO_CRATES += base64  0.21.7  # MIT OR Apache-2.0
+MODCARGO_CRATES += basic-toml  0.1.8   # MIT OR Apache-2.0
 MODCARGO_CRATES += bincode 1.3.3   # MIT
 MODCARGO_CRATES += bitflags1.3.2   # MIT/Apache-2.0
-MODCARGO_CRATES += bitflags2.4.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += bitflags2.4.2   # MIT OR Apache-2.0
 MODCARGO_CRATES += bitmaps 2.1.0   # MPL-2.0+
 MODCARGO_CRATES += block-buffer0.9.0   # MIT OR Apache-2.0
-MODCARGO_CRATES += bstr1.6.0   # MIT OR Apache-2.0
-MODCARGO_CRATES += bumpalo 3.13.0  # MIT/Apache-2.0
-MODCARGO_CRATES += bytes   1.4.0   # MIT
+MODCARGO_CRATES += bstr1.9.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += bumpalo 3.15.2  # MIT OR Apache-2.0
+MODCARGO_CRATES += bytes   1.5.0   # MIT
 MODCARGO_CRATES += camino  1.1.6   # MIT OR Apache-2.0
 MODCARGO_CRATES += capnp   0.14.11 # MIT
 MODCARGO_CRATES += capnpc  0.14.9  # MIT
-MODCARGO_CRATES += cc  1.0.83  # MIT OR Apache-2.0
+MODCARGO_CRATES += cc  1.0.86  # MIT OR Apache-2.0
 MODCARGO_CRATES += cfg-if  1.0.0   # MIT/Apache-2.0
 MODCARGO_CRATES += clap3.2.25  # MIT OR Apache-2.0
 MODCARGO_CRATES += clap_derive 3.2.25  # MIT OR Apache-2.0
 MODCARGO_CRATES += clap_lex0.2.4   # MIT OR Apache-2.0
 MODCARGO_CRATES += codespan-reporting  0.11.1  # Apache-2.0
 MODCARGO_CRATES += combine 4.6.6   # MIT
-MODCARGO_CRATES += console 0.15.7  # MIT
+MODCARGO_CRATES += console 0.15.8  # MIT
 MODCARGO_CRATES += console_error_panic_hook0.1.7   # Apache-2.0/MIT
-MODCARGO_CRATES += core-foundation 0.9.3   # MIT / Apache-2.0
-MODCARGO_CRATES += core-foundation-sys 0.8.4   # MIT / Apache-2.0
-MODCARGO_CRATES += cpufeatures 0.2.9   # MIT OR Apache-2.0
-MODCARGO_CRATES += crc32fast   1.3.2   # MIT OR Apache-2.0
-MODCARGO_CRATES += crossbeam-channel   0.5.8   # MIT OR Apache-2.0
-MODCARGO_CRATES += crossbeam-utils 0.8.16  # MIT OR Apache-2.0
-MODCARGO_CRATES += ctrlc   3.4.0   # MIT/Apache-2.0
-MODCARGO_CRATES += data-encoding   2.4.0   # MIT
+MODCARGO_CRATES += core-foundation 0.9.4   # MIT OR Apache-2.0
+MODCARGO_CRATES += core-foundation-sys 0.8.6   # MIT OR Apache-2.0
+MODCARGO_CRATES += cpufeatures 0.2.12  # MIT OR Apache-2.0
+MODCARGO_CRATES += crc32fast   1.4.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += crossbeam-channel   0.5.11  # MIT OR Apache-2.0
+MODCARGO_CRATES += crossbeam-deque 0.8.5   # MIT OR Apache-2.0
+MODCARGO_CRATES += crossbeam-epoch 0.9.18  # MIT OR Apache-2.0

Re: Unbreak lang/hare/hare on riscv64

[Lorenz (xha)]

On Thu, Mar 07, 2024 at 07:49:06PM +0100, Jeremie Courreges-Anglas wrote:
> Hi,
> 
> I suspect the behavior is different on riscv64 because of the version
> difference between devel/binutils and devel/gas, but I'm not sure
> about it.  Anyway the trivial diff below fixes the build for the next
> release.
> 
> No REVISION bump needed.

was also fixed upstream:
https://git.sr.ht/~sircmpwn/hare/commit/80e45e4d931a6e90d999846b86471cac00d2a6d5

patch is OK by me. i cannot commit it though.

> 
> 
> Index: patches/patch-debug_+riscv64_getfp_s
> ===
> RCS file: patches/patch-debug_+riscv64_getfp_s
> diff -N patches/patch-debug_+riscv64_getfp_s
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-debug_+riscv64_getfp_s  7 Mar 2024 17:56:37 -
> @@ -0,0 +1,13 @@
> +/local/pobj/hare-0.24.0/hare-0.24.0/debug/+riscv64/getfp.s: Assembler 
> messages:
> +/local/pobj/hare-0.24.0/hare-0.24.0/debug/+riscv64/getfp.s:1: Error: junk at 
> end of line, first unrecognized character is `/'
> +/local/pobj/hare-0.24.0/hare-0.24.0/debug/+riscv64/getfp.s:2: Error: junk at 
> end of line, first unrecognized character is `/'
> +
> +Index: debug/+riscv64/getfp.s
> +--- debug/+riscv64/getfp.s.orig
>  debug/+riscv64/getfp.s
> +@@ -1,5 +1,3 @@
> +-// SPDX-License-Identifier: MPL-2.0
> +-// (c) Hare authors 
> + 
> + .section ".text.debug.getfp","ax"
> + .global debug.getfp
> 
> -- 
> jca

Unbreak lang/hare/hare on riscv64

[Jeremie Courreges-Anglas]

Hi,

I suspect the behavior is different on riscv64 because of the version
difference between devel/binutils and devel/gas, but I'm not sure
about it.  Anyway the trivial diff below fixes the build for the next
release.

No REVISION bump needed.


Index: patches/patch-debug_+riscv64_getfp_s
===
RCS file: patches/patch-debug_+riscv64_getfp_s
diff -N patches/patch-debug_+riscv64_getfp_s
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-debug_+riscv64_getfp_s7 Mar 2024 17:56:37 -
@@ -0,0 +1,13 @@
+/local/pobj/hare-0.24.0/hare-0.24.0/debug/+riscv64/getfp.s: Assembler messages:
+/local/pobj/hare-0.24.0/hare-0.24.0/debug/+riscv64/getfp.s:1: Error: junk at 
end of line, first unrecognized character is `/'
+/local/pobj/hare-0.24.0/hare-0.24.0/debug/+riscv64/getfp.s:2: Error: junk at 
end of line, first unrecognized character is `/'
+
+Index: debug/+riscv64/getfp.s
+--- debug/+riscv64/getfp.s.orig
 debug/+riscv64/getfp.s
+@@ -1,5 +1,3 @@
+-// SPDX-License-Identifier: MPL-2.0
+-// (c) Hare authors 
+ 
+ .section ".text.debug.getfp","ax"
+ .global debug.getfp

-- 
jca

[Maintainer Update] devel/difftastic 0.56.1

[Volker Schlecht]

Trivial Update to difftastic 0.56.1, built and tested on amd64.

ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/difftastic/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile18 Oct 2023 16:48:07 -  1.12
+++ Makefile7 Mar 2024 18:36:46 -
@@ -2,7 +2,7 @@ COMMENT =   diff tool that compares files
 
 GH_ACCOUNT =   Wilfred
 GH_PROJECT =   difftastic
-GH_TAGNAME =   0.52.0
+GH_TAGNAME =   0.56.1
 
 HOMEPAGE = https://difftastic.wilfred.me.uk/
 
Index: crates.inc
===
RCS file: /cvs/ports/devel/difftastic/crates.inc,v
retrieving revision 1.9
diff -u -p -r1.9 crates.inc
--- crates.inc  18 Oct 2023 16:48:07 -  1.9
+++ crates.inc  7 Mar 2024 18:36:46 -
@@ -1,84 +1,94 @@
-MODCARGO_CRATES += ahash   0.7.6   # MIT OR Apache-2.0
-MODCARGO_CRATES += aho-corasick0.7.20  # Unlicense OR MIT
+MODCARGO_CRATES += ahash   0.8.9   # MIT OR Apache-2.0
+MODCARGO_CRATES += aho-corasick1.1.2   # Unlicense OR MIT
+MODCARGO_CRATES += allocator-api2  0.2.16  # MIT OR Apache-2.0
 MODCARGO_CRATES += assert_cmd  2.0.5   # MIT OR Apache-2.0
 MODCARGO_CRATES += atty0.2.14  # MIT
 MODCARGO_CRATES += autocfg 1.1.0   # Apache-2.0 OR MIT
 MODCARGO_CRATES += bitflags1.3.2   # MIT/Apache-2.0
+MODCARGO_CRATES += bitflags2.4.2   # MIT OR Apache-2.0
 MODCARGO_CRATES += bstr0.2.17  # MIT OR Apache-2.0
-MODCARGO_CRATES += bumpalo 3.11.1  # MIT/Apache-2.0
+MODCARGO_CRATES += bstr1.6.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += bumpalo 3.14.0  # MIT OR Apache-2.0
 MODCARGO_CRATES += bytecount   0.6.2   # Apache-2.0/MIT
 MODCARGO_CRATES += cc  1.0.83  # MIT OR Apache-2.0
 MODCARGO_CRATES += cfg-if  1.0.0   # MIT/Apache-2.0
-MODCARGO_CRATES += clap3.1.18  # MIT OR Apache-2.0
-MODCARGO_CRATES += clap_lex0.2.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += clap3.2.25  # MIT OR Apache-2.0
+MODCARGO_CRATES += clap_lex0.2.4   # MIT OR Apache-2.0
 MODCARGO_CRATES += const_format0.2.23  # Zlib
 MODCARGO_CRATES += const_format_proc_macros0.2.22  # Zlib
 MODCARGO_CRATES += crossbeam-channel   0.5.8   # MIT OR Apache-2.0
 MODCARGO_CRATES += crossbeam-deque 0.8.1   # MIT OR Apache-2.0
 MODCARGO_CRATES += crossbeam-epoch 0.9.8   # MIT OR Apache-2.0
 MODCARGO_CRATES += crossbeam-utils 0.8.8   # MIT OR Apache-2.0
-MODCARGO_CRATES += crossterm   0.26.1  # MIT
-MODCARGO_CRATES += crossterm_winapi0.9.0   # MIT
+MODCARGO_CRATES += crossterm   0.27.0  # MIT
+MODCARGO_CRATES += crossterm_winapi0.9.1   # MIT
 MODCARGO_CRATES += ctor0.1.22  # Apache-2.0 OR MIT
 MODCARGO_CRATES += diff0.1.12  # MIT OR Apache-2.0
 MODCARGO_CRATES += difflib 0.4.0   # MIT
 MODCARGO_CRATES += doc-comment 0.3.3   # MIT
 MODCARGO_CRATES += either  1.6.1   # MIT/Apache-2.0
-MODCARGO_CRATES += env_logger  0.7.1   # MIT/Apache-2.0
+MODCARGO_CRATES += env_logger  0.10.0  # MIT OR Apache-2.0
+MODCARGO_CRATES += errno   0.3.5   # MIT OR Apache-2.0
 MODCARGO_CRATES += fixedbitset 0.4.1   # MIT/Apache-2.0
 MODCARGO_CRATES += float-cmp   0.9.0   # MIT
 MODCARGO_CRATES += fnv 1.0.7   # Apache-2.0 / MIT
-MODCARGO_CRATES += getrandom   0.2.9   # MIT OR Apache-2.0
 MODCARGO_CRATES += glob0.3.1   # MIT OR Apache-2.0
+MODCARGO_CRATES += globset 0.4.13  # Unlicense OR MIT
 MODCARGO_CRATES += hashbrown   0.11.2  # Apache-2.0/MIT
-MODCARGO_CRATES += hashbrown   0.12.3  # MIT OR Apache-2.0
+MODCARGO_CRATES += hashbrown   0.14.3  # MIT OR Apache-2.0
 MODCARGO_CRATES += heck0.4.1   # MIT OR Apache-2.0
 MODCARGO_CRATES += hermit-abi  0.1.19  # MIT/Apache-2.0
+MODCARGO_CRATES += hermit-abi  0.3.3   # MIT OR Apache-2.0
 MODCARGO_CRATES += humansize   2.1.3   # MIT/Apache-2.0
-MODCARGO_CRATES += humantime   1.3.0   # MIT/Apache-2.0
+MODCARGO_CRATES += humantime   2.1.0   # MIT/Apache-2.0
+MODCARGO_CRATES += ignore  0.4.18  # Unlicense/MIT
 MODCARGO_CRATES += indexmap1.7.0   # Apache-2.0/MIT
+MODCARGO_CRATES += io-lifetimes1.0.11  # Apache-2.0 WITH 
LLVM-exception OR Apache-2.0 OR MIT
+MODCARGO_CRATES += is-terminal 0.4.7   # MIT
 MODCARGO_CRATES += itertools   0.10.3  # MIT/Apache-2.0
 MODCARGO_CRATES += itertools   0.11.0  # MIT OR Apache-2.0
 MODCARGO_CRATES += itoa1.0.9   # MIT OR Apache-2.0
 MODCARGO_CRATES += lazy_static 1.4.0   # MIT/Apache-2.0
-MODCARGO_CRATES += libc0.2.139 # MIT OR Apache-2.0
+MODCARGO_CRATES += libc0.2.149 # MIT OR Apache-2.0
 MODCARGO_CRATES += libm0.2.7   # MIT OR Apache-2.0
 

[Maintainer Update] print/ghostscript/gnu 10.03.0

[Volker Schlecht]

Updates print/ghostscript/gnu to latest release 10.03.0

This is marked as a security release, but the only documented vulnerability
affects builds with tesseract enabled. In our port we disable it, so we seem
to be unaffected.

https://ghostscript.readthedocs.io/en/gs10.03.0/News.html

Built and tested on amd64. print/lilypond in particular still builds :-)

ok?
Index: Makefile
===
RCS file: /cvs/ports/print/ghostscript/gnu/Makefile,v
retrieving revision 1.129
diff -u -p -r1.129 Makefile
--- Makefile3 Nov 2023 10:53:15 -   1.129
+++ Makefile7 Mar 2024 18:13:52 -
@@ -1,10 +1,10 @@
 COMMENT =  PostScript and PDF interpreter
 
-VERSION =  10.02.1
+VERSION =  10.03.0
 DISTNAME = ghostscript-${VERSION}
 EXTRACT_SUFX = .tar.xz
 CATEGORIES =   lang print
-SHARED_LIBS =  gs 18.1
+SHARED_LIBS =  gs 18.2
 
 SITES =
https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs${VERSION:S/.//g}/
 
Index: distinfo
===
RCS file: /cvs/ports/print/ghostscript/gnu/distinfo,v
retrieving revision 1.24
diff -u -p -r1.24 distinfo
--- distinfo3 Nov 2023 10:53:15 -   1.24
+++ distinfo7 Mar 2024 18:13:52 -
@@ -1,2 +1,2 @@
-SHA256 (ghostscript-10.02.1.tar.xz) = 
jFjJSLByG+zvzQApyNuV+bsyaK/8JeoB1MWmsH+hqwg=
-SIZE (ghostscript-10.02.1.tar.xz) = 68017088
+SHA256 (ghostscript-10.03.0.tar.xz) = 
8l/0kacm2IPwsPnIr5uJXGdM93zd2BSqOCSzIj9DnuU=
+SIZE (ghostscript-10.03.0.tar.xz) = 68041176
Index: patches/patch-configure
===
RCS file: /cvs/ports/print/ghostscript/gnu/patches/patch-configure,v
retrieving revision 1.7
diff -u -p -r1.7 patch-configure
--- patches/patch-configure 25 Sep 2023 07:55:12 -  1.7
+++ patches/patch-configure 7 Mar 2024 18:13:52 -
@@ -1,7 +1,7 @@
 Index: configure
 --- configure.orig
 +++ configure
-@@ -13149,8 +13149,8 @@ DLL_EXT=""
+@@ -13158,8 +13158,8 @@ DLL_EXT=""
  SO_LIB_VERSION_SEPARATOR="."
  
  libname1="_SO_BASE)\$(GS_SOEXT)\$(DLL_EXT)"
@@ -12,7 +12,7 @@ Index: configure
  GS_SONAME="lib\$(GS${libname1}"
  GS_SONAME_MAJOR="lib\$(GS${libname2}"
  GS_SONAME_MAJOR_MINOR="lib\$(GS${libname3}"
-@@ -13262,11 +13262,11 @@ case $host in
+@@ -13271,11 +13271,11 @@ case $host in
  ;;
  *bsd*)
DYNAMIC_CFLAGS="-fPIC $DYNAMIC_CFLAGS"

Re: pkg_info: fold Comment newline

[Marc Espie]

On Sat, Mar 02, 2024 at 05:39:10PM +, Klemens Nanni wrote:
> As per Makefile.template and portcheck(1) COMMENT is <=60 chars, so it'd
> fit on the same Comment: line in pkg_info(1) output -- less scrolling!
> 
> It just stands out, imho, compared to Maintainer: and WWW: where there's
> no such seemingly superfluous line break.
> 
> Thoughts?
> 
>  Information for inst:quirks-7.11
> 
> -Comment:
> -exceptions to pkg_add rules
> +Comment: exceptions to pkg_add rules
> 
>  Description:
>  The quirks package allows unpredicted changes to the package system.
>  For instance, package name changes, or stuff incorporated into base.
> 
>  pkg_add(1) always installs and updates it automatically.
> 
>  Maintainer: Marc Espie 
> 
> Index: OpenBSD/PkgInfo.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
> diff -u -p -r1.54 PkgInfo.pm
> --- OpenBSD/PkgInfo.pm25 Nov 2023 11:02:23 -  1.54
> +++ OpenBSD/PkgInfo.pm22 Feb 2024 14:16:18 -
> @@ -384,8 +384,7 @@ sub print_info($self, $state, $pkg, $han
>   } else {
>   if ($state->opt('c')) {
>   $state->header($handle);
> - $state->banner("Comment:");
> - $state->say("#1\n", get_comment($handle->info));
> + $state->say("Comment: #1\n", 
> get_comment($handle->info));
>   }
>   if ($state->opt('R') && -f $handle->info.REQUIRED_BY) {
>   $state->header($handle);
> 
Make sure nobody uses it.

Probably after the release

definitely okay

rebar3 - add quirk

[Volker Schlecht]

Adds a quirk for the renamed rebar3 package, which I missed in the update.

ok?

Index: files/Quirks.pm
===
RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.1614
diff -u -p -r1.1614 Quirks.pm
--- files/Quirks.pm 29 Feb 2024 01:01:12 -  1.1614
+++ files/Quirks.pm 29 Feb 2024 17:07:12 -
@@ -812,6 +812,7 @@ my $stem_extensions = {
'unison' => 'unison-gui',
'sendxmpp' => 'go-sendxmpp',
'libreddit' => 'redlib',
+   'rebar3' => 'erl25-rebar3',
 };
 
 my $obsolete_reason = {};

erlang.port.mk

[Volker Schlecht]

Fixes a typo in erlang.port.mk.
Identified, patch proposed by sthen@

ok?
Index: erlang.port.mk
===
RCS file: /cvs/ports/lang/erlang/erlang.port.mk,v
retrieving revision 1.38
diff -u -p -r1.38 erlang.port.mk
--- erlang.port.mk  12 Feb 2024 17:02:09 -  1.38
+++ erlang.port.mk  29 Feb 2024 17:03:31 -
@@ -30,7 +30,7 @@ FULLPKGNAME ?=${MODERL_PKG_PREFIX}-${PK
 
 FLAVOR ?=
 .if empty(FLAVOR)
-FLAVOR =   ${MODERL_DEFAULT_FLAVOR}
+FLAVOR =   ${_MODERL_DEFAULT_FLAVOR}
 .endif
 .  endif
 .endif

UPDATE: net/nextcloudclient-3.12.1

[Adriano Barbosa]

Hi.
Update for net/nextcloudclient v3.12.1
Changelog:
https://github.com/nextcloud/desktop/releases/v3.12.1

Obrigado!
--
Adriano


Index: Makefile
===
RCS file: /cvs/ports/net/nextcloudclient/Makefile,v
retrieving revision 1.58
diff -u -p -r1.58 Makefile
--- Makefile24 Feb 2024 10:28:33 -  1.58
+++ Makefile7 Mar 2024 17:29:04 -
@@ -2,7 +2,7 @@ USE_WXNEEDED =  Yes
 
 COMMENT =  desktop sync client for Nextcloud
 
-V =3.12.0
+V =3.12.1
 DISTNAME = nextcloudclient-${V}
 
 GH_ACCOUNT =   nextcloud
@@ -13,8 +13,8 @@ CATEGORIES =  net
 
 HOMEPAGE = https://nextcloud.com
 
-SHARED_LIBS +=  nextcloudsync 16.0  # 3.12.0
-SHARED_LIBS +=  nextcloud_csync   8.0   # 3.12.0
+SHARED_LIBS +=  nextcloudsync 17.0  # 3.12.1
+SHARED_LIBS +=  nextcloud_csync   8.1   # 3.12.1
 SHARED_LIBS +=  nextcloudsync_vfs_suffix  2.0   # 3.10.2
 
 MAINTAINER =   Adriano Barbosa 
Index: distinfo
===
RCS file: /cvs/ports/net/nextcloudclient/distinfo,v
retrieving revision 1.47
diff -u -p -r1.47 distinfo
--- distinfo24 Feb 2024 10:28:33 -  1.47
+++ distinfo7 Mar 2024 17:29:04 -
@@ -1,2 +1,2 @@
-SHA256 (nextcloudclient-3.12.0.tar.gz) = 
32xWyPy+59mrCWc823tBZx8usOsdu3nuOTsgepvEbug=
-SIZE (nextcloudclient-3.12.0.tar.gz) = 13636170
+SHA256 (nextcloudclient-3.12.1.tar.gz) = 
oeEXuh6slnxXx7ZsdvHnIAOJZ06eyf/fFhvFJBhISPY=
+SIZE (nextcloudclient-3.12.1.tar.gz) = 13640266

Re: UPDATE: Nextcloud-28.0.3

[Clemens Gößnitzer]

On Tue, 2024-03-05 at 09:30 +0100, Gonzalo L. Rodriguez wrote:
> Hello,
> 
> Update for Nextcloud to 28.0.3:
> 
> https://nextcloud.com/changelog/
> 
> Plus some tweaks from Clemens Gößnitzer for the README and httpd(8)
> conf.

I did not test updating, which does not work in the browser anymore
when using the new examples.  The following addition fixes that for me.
Sorry for not noticing this.


Index: pkg/README
===
RCS file: /cvs/ports/www/nextcloud/pkg/README,v
retrieving revision 1.24
diff -u -p -u -r1.24 README
--- pkg/README  5 Mar 2024 09:57:03 -   1.24
+++ pkg/README  7 Mar 2024 16:09:53 -
@@ -83,6 +83,14 @@ server "domain.tld" {
pass
}
 
+   # required for the updater in the browser
+   location "/nextcloud/core/ajax/update.php*" {
+   root "/nextcloud"
+   request strip 1
+   fastcgi socket "/run/php-fpm.sock"
+   pass
+   }
+
location "/nextcloud/ocs/*.php*" {
root "/nextcloud"
request strip 1


> 
> OK?
> 
> Cheers.-
> 
> 

CVS: cvs.openbsd.org: ports

[Frederic Cambus]

CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2024/03/07 09:07:54

Modified files:
graphics/p5-Image-ExifTool: Makefile distinfo 
graphics/p5-Image-ExifTool/pkg: PLIST 

Log message:
Update p5-Image-ExifTool to 12.78.

Re: net/dnsdist h3 version doesn't seem to start on i386

[Theo Buehler]

On Thu, Mar 07, 2024 at 02:09:58PM +, Stuart Henderson wrote:
> On 2024/03/07 14:58, Renaud Allard wrote:
> > Hello,
> > 
> > I was playing with dnsdist and wanted to install it on an old soekris. I
> > updated to the latest OpenBSD snapshot (i386) of today and installed
> > dnsdist-1.9.0-h3.
> > But it seems it fails to start with "Illegal instruction (core dumped)".
> > I tried the same config with the non h3 version and it started without
> > issue.
> > 
> > Maybe it couldn't run at all on i386, but then the h3 build should probably
> > be removed from the packages build.
> 
> Most likely the machine doesn't have SSE2 and boringssl (which is
> used by dnsdist's h3 flavour) wouldn't build without -msse2.
> I'd expect it to run on newer i386s.

Seems to run fine on an i386 with SSE2, so that's most likely the
explanation.

> 
> > I can provide the core dump if needed.
> 
> A backtrace from the core dump might be useful. The core file itself
> not so useful. Also dmesg.
> 

Re: net/dnsdist h3 version doesn't seem to start on i386

[Renaud Allard]

On 3/7/24 3:09 PM, Stuart Henderson wrote:

On 2024/03/07 14:58, Renaud Allard wrote:

Hello,

I was playing with dnsdist and wanted to install it on an old soekris. I
updated to the latest OpenBSD snapshot (i386) of today and installed
dnsdist-1.9.0-h3.
But it seems it fails to start with "Illegal instruction (core dumped)".
I tried the same config with the non h3 version and it started without
issue.

Maybe it couldn't run at all on i386, but then the h3 build should probably
be removed from the packages build.


Most likely the machine doesn't have SSE2 and boringssl (which is
used by dnsdist's h3 flavour) wouldn't build without -msse2.
I'd expect it to run on newer i386s.


Yes, it clearly has no SSE2

cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 
586-class) 267 MHz, 05-04-00

cpu0: FPU,TSC,MSR,CX8,CMOV,MMX

I think it would be useful to write that somewhere. Although I doubt 
there are that much people still using those old CPUs.





I can provide the core dump if needed.


A backtrace from the core dump might be useful. The core file itself
not so useful. Also dmesg.



There were no debug symbols, so not sure that core will be useful

Core was generated by `dnsdist'.
Program terminated with signal 4, Illegal instruction.
#0  0x1c348167 in ?? ()


smime.p7s
Description: S/MIME Cryptographic Signature

Re: net/dnsdist h3 version doesn't seem to start on i386

[Stuart Henderson]

On 2024/03/07 14:58, Renaud Allard wrote:
> Hello,
> 
> I was playing with dnsdist and wanted to install it on an old soekris. I
> updated to the latest OpenBSD snapshot (i386) of today and installed
> dnsdist-1.9.0-h3.
> But it seems it fails to start with "Illegal instruction (core dumped)".
> I tried the same config with the non h3 version and it started without
> issue.
> 
> Maybe it couldn't run at all on i386, but then the h3 build should probably
> be removed from the packages build.

Most likely the machine doesn't have SSE2 and boringssl (which is
used by dnsdist's h3 flavour) wouldn't build without -msse2.
I'd expect it to run on newer i386s.

> I can provide the core dump if needed.

A backtrace from the core dump might be useful. The core file itself
not so useful. Also dmesg.

net/dnsdist h3 version doesn't seem to start on i386

[Renaud Allard]

Hello,

I was playing with dnsdist and wanted to install it on an old soekris. I 
updated to the latest OpenBSD snapshot (i386) of today and installed 
dnsdist-1.9.0-h3.

But it seems it fails to start with "Illegal instruction (core dumped)".
I tried the same config with the non h3 version and it started without 
issue.


Maybe it couldn't run at all on i386, but then the h3 build should 
probably be removed from the packages build.


I can provide the core dump if needed.

Best Regards


smime.p7s
Description: S/MIME Cryptographic Signature

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Mark Kettenis]

> Date: Thu, 7 Mar 2024 12:55:50 +
> From: Stuart Henderson 
> 
> On 2024/03/07 10:28, Mark Kettenis wrote:
> > This version looks best to me.  But I suspect arm64 needs more work in
> > this version too.
> 
> I tried to give it a spin with gnustep-based software, but no
> gnustep-base package is available for arm64 yet (I suspect because of
> the previous bugs in the libobjc2 port).
> 
> If I try to build gnustep-base myself it fails with BTI SIGILL during
> autoconf when doing a test for libffi, so it looks like we're probably
> missing something in libffi (tobhe fixed some things last November).
> I'm not getting useful backtraces so not sure where in libffi it's
> needed. Test program from libobjc2's autoconf files attached:
> 
> $ cc -I/usr/local/include -L/usr/local/lib config.ffi.c -lffi
> $ ktrace ./a.out
> a
> Illegal instruction (core dumped)
> $ kdump | tail
>   5909 a.outRET   mmap 29349658624/0x6d5604000
>   5909 a.outCALL  fcntl(1,F_ISATTY)
>   5909 a.outRET   fcntl 1
>   5909 a.outCALL  write(1,0x6d5604000,0x2)
>   5909 a.outGIO   fd 1 wrote 2 bytes
>"a
>"
>   5909 a.outRET   write 2
>   5909 a.outPSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x6e74fe010 
> trapno=905969666
>   5909 a.outNAMI  "a.out.core"
> 
> "make test" in libffi runs ok, but picking another consumber of libffi
> I tried "make test" in guile3, and that has SIGILLs too.

I'll take a look.

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Stuart Henderson]

On 2024/03/07 10:28, Mark Kettenis wrote:
> This version looks best to me.  But I suspect arm64 needs more work in
> this version too.

I tried to give it a spin with gnustep-based software, but no
gnustep-base package is available for arm64 yet (I suspect because of
the previous bugs in the libobjc2 port).

If I try to build gnustep-base myself it fails with BTI SIGILL during
autoconf when doing a test for libffi, so it looks like we're probably
missing something in libffi (tobhe fixed some things last November).
I'm not getting useful backtraces so not sure where in libffi it's
needed. Test program from libobjc2's autoconf files attached:

$ cc -I/usr/local/include -L/usr/local/lib config.ffi.c -lffi
$ ktrace ./a.out
a
Illegal instruction (core dumped)
$ kdump | tail
  5909 a.outRET   mmap 29349658624/0x6d5604000
  5909 a.outCALL  fcntl(1,F_ISATTY)
  5909 a.outRET   fcntl 1
  5909 a.outCALL  write(1,0x6d5604000,0x2)
  5909 a.outGIO   fd 1 wrote 2 bytes
   "a
   "
  5909 a.outRET   write 2
  5909 a.outPSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x6e74fe010 
trapno=905969666
  5909 a.outNAMI  "a.out.core"

"make test" in libffi runs ok, but picking another consumber of libffi
I tried "make test" in guile3, and that has SIGILLs too.

#include 
#include 
#include 


typedef struct cls_struct_combined {
  float a;
  float b;
  float c;
  float d;
} cls_struct_combined;

void cls_struct_combined_fn(struct cls_struct_combined arg)
{
/*
  printf("GOT %g %g %g %g,  EXPECTED 4 5 1 8\n",
 arg.a, arg.b,
 arg.c, arg.d);
  fflush(stdout);
*/
  if (arg.a != 4 || arg.b != 5 || arg.c != 1 || arg.d != 8) abort();
}

static void
cls_struct_combined_gn(ffi_cif* cif, void* resp, void** args, void* userdata)
{
  struct cls_struct_combined a0;

  a0 = *(struct cls_struct_combined*)(args[0]);

  cls_struct_combined_fn(a0);
}


int main (void)
{
  ffi_cif cif;
  void *code;
  ffi_closure *pcl = ffi_closure_alloc(sizeof(ffi_closure), );
  ffi_type* cls_struct_fields0[5];
  ffi_type cls_struct_type0;
  ffi_type* dbl_arg_types[5];
  struct cls_struct_combined g_dbl = {4.0, 5.0, 1.0, 8.0};

  cls_struct_type0.size = 0;
  cls_struct_type0.alignment = 0;
  cls_struct_type0.type = FFI_TYPE_STRUCT;
  cls_struct_type0.elements = cls_struct_fields0;

  cls_struct_fields0[0] = _type_float;
  cls_struct_fields0[1] = _type_float;
  cls_struct_fields0[2] = _type_float;
  cls_struct_fields0[3] = _type_float;
  cls_struct_fields0[4] = NULL;

  dbl_arg_types[0] = _struct_type0;
  dbl_arg_types[1] = NULL;

  if (ffi_prep_cif(, FFI_DEFAULT_ABI, 1, _type_void, dbl_arg_types)
!= FFI_OK) abort();

  if (ffi_prep_closure_loc(pcl, , cls_struct_combined_gn, NULL, code)
!= FFI_OK) abort();

  printf("a\n");
  ((void(*)(cls_struct_combined)) (code))(g_dbl);
  printf("b\n");
  exit(0);
}

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

On Thursday, March 07, 2024 12:36 CET, Stuart Henderson  
wrote:

> > > > How do I get a BTI enabled machine?
> > 
> > Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
> > Apple M2.
> 
> Look for "Control-Flow Enforcement Technology" in the Intel cpu details
> page on ark.intel.com. Yes it needs to be gen11 or newer.
> 
> AMD does not have it yet.
> 
> Cheapest way is probably the N100-based mini PCs (not speed demons but
> fairly acceptable and they're really cheap).
> 
> For laptops, Thinkpad T14 are fairly common amongst developers.
> (T14 g2 has gen11 CPUs, all cores the same - T14 g3 has gen12, mix
> of performance + efficiency cores).
> 

I don't own such modern hardware ;)
But such N100 based mini PC looks like a viable option to add to my stack.

Sebastian

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

On Thursday, March 07, 2024 10:28 CET, Mark Kettenis  
wrote:

> > From: "Sebastian Reitenbach" 
> > Date: Thu, 07 Mar 2024 09:01:13 +0100
> > 
> > Hi,
> > 
> > On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > > From: Mark Kettenis 
> > > > 
> > > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > > From: Jeremie Courreges-Anglas 
> > > > > 
> > > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > > should make release.
> > > > > 
> > > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > > 
> > > > > ok?
> > > > > 
> > > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > > 
> > > > Looks right to me.
> > > 
> > > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > > that endbr64 should be after the .cfi_startproc.
> > > 
> > 
> > I already created a lot of mess rushing getting the update in, I'm 
> > a bit confused with this back and fourth. Before messing up even more, 
> > which of these should be the correct version, the one from tb@ or jca@ ?
> > And that one would also be complete in aarch64?
> > If I got all those threats right, the tb@ version would be the correct one?
> > Both attached below.
> > 
> > 
> > How do I get a BTI enabled machine?
> > 
> > Sebastian
> > 
> > tb@ version:
> 
> This version looks best to me.  But I suspect arm64 needs more work in
> this version too.
> 
> ok kettenis@
> 
Thank you all, this version is now in, I'll see to upstream it.

Sebastian

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2024/03/07 05:22:50

Modified files:
x11/gnustep/libobjc2: Makefile 
Added files:
x11/gnustep/libobjc2/patches: patch-block_trampolines_S 
  patch-objc_msgSend_aarch64_S 
  patch-objc_msgSend_x86-64_S 

Log message:
BTI/endbr64 fixes, patches prodded by tb@
aarch64 might still be incomplete
OK jca@, kettenis@

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Stuart Henderson]

> > > How do I get a BTI enabled machine?
> 
> Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
> Apple M2.

Look for "Control-Flow Enforcement Technology" in the Intel cpu details
page on ark.intel.com. Yes it needs to be gen11 or newer.

AMD does not have it yet.

Cheapest way is probably the N100-based mini PCs (not speed demons but
fairly acceptable and they're really cheap).

For laptops, Thinkpad T14 are fairly common amongst developers.
(T14 g2 has gen11 CPUs, all cores the same - T14 g3 has gen12, mix
of performance + efficiency cores).

CVS: cvs.openbsd.org: ports

[Otto Moerbeek]

CVSROOT:/cvs
Module name:ports
Changes by: o...@cvs.openbsd.org2024/03/07 04:34:25

Modified files:
net/powerdns_recursor: Makefile distinfo 

Log message:
Update to PowerDNS Recursor 5.0.3

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Jeremie Courreges-Anglas]

Le Thu, Mar 07, 2024 at 10:28:21AM +0100, Mark Kettenis a écrit :
> > From: "Sebastian Reitenbach" 
> > Date: Thu, 07 Mar 2024 09:01:13 +0100
> > 
> > Hi,
> > 
> > On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > > From: Mark Kettenis 
> > > > 
> > > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > > From: Jeremie Courreges-Anglas 
> > > > > 
> > > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > > should make release.
> > > > > 
> > > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > > 
> > > > > ok?
> > > > > 
> > > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > > 
> > > > Looks right to me.
> > > 
> > > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > > that endbr64 should be after the .cfi_startproc.
> > > 
> > 
> > I already created a lot of mess rushing getting the update in, I'm 
> > a bit confused with this back and fourth. Before messing up even more, 
> > which of these should be the correct version, the one from tb@ or jca@ ?

Well I added to the confusion.  I did not have tb's diff at hand
yesterday, I cooked a subpar diff that fixed the crash and got trigger
happy.  That's a waste of time, sorry folks.

> > And that one would also be complete in aarch64?
> > If I got all those threats right, the tb@ version would be the correct one?
> > Both attached below.
> > 
> > 
> > How do I get a BTI enabled machine?

Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
Apple M2.

> > Sebastian
> > 
> > tb@ version:
> 
> This version looks best to me.

Agreed.

> But I suspect arm64 needs more work in
> this version too.
> 
> ok kettenis@

ok jca@

-- 
jca

CVS: cvs.openbsd.org: ports

[Frederic Cambus]

CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2024/03/07 03:30:40

Modified files:
devel/xa   : Makefile distinfo 

Log message:
Update xa to 2.4.1.

CVS: cvs.openbsd.org: ports

[Sebastian Reitenbach]

CVSROOT:/cvs
Module name:ports
Changes by: sebas...@cvs.openbsd.org2024/03/07 03:04:01

Modified files:
sysutils/ruby-facter: Makefile distinfo 
sysutils/ruby-facter/files/resolvers: virtual.rb 
sysutils/ruby-facter/patches: 
  
patch-lib_facter_framework_core_file_loader_rb 
  
patch-lib_facter_util_facts_posix_virtual_detector_rb 
sysutils/ruby-facter/pkg: PLIST 

Log message:
update 4.5.2 -> 4.6.1
while there, fix the virtual and is_virtual fact on physical hardware

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Mark Kettenis]

> From: "Sebastian Reitenbach" 
> Date: Thu, 07 Mar 2024 09:01:13 +0100
> 
> Hi,
> 
> On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
>  wrote:
> 
> > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > From: Mark Kettenis 
> > > 
> > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > From: Jeremie Courreges-Anglas 
> > > > 
> > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > should make release.
> > > > 
> > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > 
> > > > ok?
> > > > 
> > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > 
> > > Looks right to me.
> > 
> > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > that endbr64 should be after the .cfi_startproc.
> > 
> 
> I already created a lot of mess rushing getting the update in, I'm 
> a bit confused with this back and fourth. Before messing up even more, 
> which of these should be the correct version, the one from tb@ or jca@ ?
> And that one would also be complete in aarch64?
> If I got all those threats right, the tb@ version would be the correct one?
> Both attached below.
> 
> 
> How do I get a BTI enabled machine?
> 
> Sebastian
> 
> tb@ version:

This version looks best to me.  But I suspect arm64 needs more work in
this version too.

ok kettenis@

> Index: patches/patch-block_trampolines_S
> ===
> RCS file: patches/patch-block_trampolines_S
> diff -N patches/patch-block_trampolines_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-block_trampolines_S 28 Feb 2024 20:08:24 -
> @@ -0,0 +1,19 @@
> +Index: block_trampolines.S
> +--- block_trampolines.S.orig
>  block_trampolines.S
> +@@ -22,6 +22,7 @@
> + // x86-64 trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++endbr64
> + mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
> argument
> + xchg  \arg1, \arg0   # Swap the first and second arguments
> + jmp   *-0x1008(%rip) # Call the block function
> +@@ -121,6 +122,7 @@
> + // AArch64 (ARM64) trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++bti c
> + adr x17, #-4096
> + mov \arg1, \arg0
> + ldp \arg0, x17, [x17]
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -47,7 +47,7 @@
> + #   define EH_NOP .seh_nop
> + #else
> + // Marks the real start and end of the function
> +-#   define EH_START .cfi_startproc
> ++#   define EH_START .cfi_startproc; bti c
> + #   define EH_END .cfi_endproc
> + 
> + // The following directives are either not
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -8,7 +8,7 @@
> + #   define SECOND_ARGUMENT %rdx
> + #   define THIRD_ARGUMENT %r8
> + #else
> +-#   define START_PROC(x) .cfi_startproc
> ++#   define START_PROC(x) .cfi_startproc; endbr64
> + #   define END_PROC(x) .cfi_endproc
> + #   define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
> + #   define FIRST_ARGUMENT_STR "%rdi"
> 
> 
> 
> @jca version:
> 
> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N 

Re: Salt master on -stable and communication with minions on -current 3006.7 version

[Uwe Werler]

I simply built the package on 7.4.

Am 7. März 2024 09:10:59 MEZ schrieb Mikolaj Kucharski :
>Hi,
>
>I saw this thread progressed. I didn't had a time to test the diff.
>However, I see positive feedback about the fix. I don't run -current
>on my -stable Salt master. Would it be possible to backport Salt
>version 3006.7 with the fix to OpenBSD -stable?
>
>
>On Tue, Mar 05, 2024 at 03:29:55PM +, Mikolaj Kucharski wrote:
>> Hi Robert.
>> 
>> I've notived this problem on my Debian Bookworm machines, which recently
>> got upgraded to 3006.7 and now I also see this on my OpenBSD -current,
>> which also started to run 3006.7 minions. I have Salt master running
>> on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7
>> lost communication to the master:
>> 
>> openbsd-current-minion# tail -n10 /var/log/salt/minion
>> The master public key can be found at:
>> /etc/salt/pki/minion/minion_master.pub
>> 2024-03-05 15:13:22,252 [salt.minion:1157][ERROR   ][44088] Error while 
>> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
>> responding? The error message was Unable to sign_in to master: Invalid 
>> master key
>> 2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR   ][44088] The master key 
>> has changed, the salt master could have been subverted, verify salt master's 
>> public key
>> 2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master 
>> server's public key did not authenticate!
>> The master may need to be updated if it is a version of Salt lower than 
>> 3006.7, or
>> If you are confident that you are connecting to a valid Salt Master, then 
>> remove the master public key and restart the Salt Minion.
>> The master public key can be found at:
>> /etc/salt/pki/minion/minion_master.pub
>> 2024-03-05 15:13:32,727 [salt.minion:1157][ERROR   ][44088] Error while 
>> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
>> responding? The error message was Unable to sign_in to master: Invalid 
>> master key
>> 
>> I didn't check does upgrade to 3006.7 on master help. I don't want
>> to touch my -stable machines. I could setup Salt master on -current
>> and test, but all this problem started on Debian and OpenBSD after
>> minion upgrade to 3006.7. I do follow -stable packages and syspatch
>> on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD,
>> I suspect compatibility issue on Salt side.
>> 
>> openbsd-salt-master# sysctl -n kern.version
>> OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024
>> 
>> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> 
>> 
>> openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail
>> drwxr-xr-x  2 0  0   512B Jan 17 23:23 brotli-1.0.9p0
>> drwxr-xr-x  2 0  0   512B Jan 17 23:23 taskd-1.1.0p5
>> drwxr-xr-x  2 0  0   512B Feb  7 02:50 ngtcp2-0.19.1
>> drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp3-0.15.0
>> drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp2-1.57.0
>> drwxr-xr-x  2 0  0   512B Feb  7 02:50 git-2.42.0
>> drwxr-xr-x  2 0  0   512B Feb  7 02:50 curl-8.6.0
>> drwxr-xr-x  2 0  0   512B Feb 14 00:47 libunbound-1.19.1
>> drwxr-xr-x  2 0  0   512B Feb 14 00:47 gnutls-3.8.3
>> drwxr-xr-x  2 0  0   512B Feb 24 17:56 quirks-6.160
>> 
>> 
>> openbsd-current-minion# sysctl -n kern.version
>> OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar  3 22:36:54 MST 2024
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> 
>> 
>> Are you aware of this problem? Ports mailing list, did you notice this,
>> by any chance?
>> 
>
>-- 
>Regards,
> Mikolaj
>

-- 
Mit freundlichen Grüssen / Með bestu kveðju / With kind regards

Uwe Werler

Re: Salt master on -stable and communication with minions on -current 3006.7 version

[Mikolaj Kucharski]

Hi,

I saw this thread progressed. I didn't had a time to test the diff.
However, I see positive feedback about the fix. I don't run -current
on my -stable Salt master. Would it be possible to backport Salt
version 3006.7 with the fix to OpenBSD -stable?


On Tue, Mar 05, 2024 at 03:29:55PM +, Mikolaj Kucharski wrote:
> Hi Robert.
> 
> I've notived this problem on my Debian Bookworm machines, which recently
> got upgraded to 3006.7 and now I also see this on my OpenBSD -current,
> which also started to run 3006.7 minions. I have Salt master running
> on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7
> lost communication to the master:
> 
> openbsd-current-minion# tail -n10 /var/log/salt/minion
> The master public key can be found at:
> /etc/salt/pki/minion/minion_master.pub
> 2024-03-05 15:13:22,252 [salt.minion:1157][ERROR   ][44088] Error while 
> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
> responding? The error message was Unable to sign_in to master: Invalid master 
> key
> 2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR   ][44088] The master key has 
> changed, the salt master could have been subverted, verify salt master's 
> public key
> 2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master 
> server's public key did not authenticate!
> The master may need to be updated if it is a version of Salt lower than 
> 3006.7, or
> If you are confident that you are connecting to a valid Salt Master, then 
> remove the master public key and restart the Salt Minion.
> The master public key can be found at:
> /etc/salt/pki/minion/minion_master.pub
> 2024-03-05 15:13:32,727 [salt.minion:1157][ERROR   ][44088] Error while 
> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
> responding? The error message was Unable to sign_in to master: Invalid master 
> key
> 
> I didn't check does upgrade to 3006.7 on master help. I don't want
> to touch my -stable machines. I could setup Salt master on -current
> and test, but all this problem started on Debian and OpenBSD after
> minion upgrade to 3006.7. I do follow -stable packages and syspatch
> on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD,
> I suspect compatibility issue on Salt side.
> 
> openbsd-salt-master# sysctl -n kern.version
> OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024
> 
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> 
> openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail
> drwxr-xr-x  2 0  0   512B Jan 17 23:23 brotli-1.0.9p0
> drwxr-xr-x  2 0  0   512B Jan 17 23:23 taskd-1.1.0p5
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 ngtcp2-0.19.1
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp3-0.15.0
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp2-1.57.0
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 git-2.42.0
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 curl-8.6.0
> drwxr-xr-x  2 0  0   512B Feb 14 00:47 libunbound-1.19.1
> drwxr-xr-x  2 0  0   512B Feb 14 00:47 gnutls-3.8.3
> drwxr-xr-x  2 0  0   512B Feb 24 17:56 quirks-6.160
> 
> 
> openbsd-current-minion# sysctl -n kern.version
> OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar  3 22:36:54 MST 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> 
> Are you aware of this problem? Ports mailing list, did you notice this,
> by any chance?
> 

-- 
Regards,
 Mikolaj

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

Hi,


On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis  
wrote:

> > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > From: Mark Kettenis 
> > 
> > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > From: Jeremie Courreges-Anglas 
> > > 
> > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > should make release.
> > > 
> > > Since I now have a laptop with BTI I figured I was going to give this
> > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > Windows.  I can't test the arm64 part but it looks simple.
> > > 
> > > ok?
> > > 
> > > Sebastian, feel free to commit this if it matches your previous diff.
> > 
> > Looks right to me.
> 
> Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> that endbr64 should be after the .cfi_startproc.
> 

I already created a lot of mess rushing getting the update in, I'm 
a bit confused with this back and fourth. Before messing up even more, 
which of these should be the correct version, the one from tb@ or jca@ ?
And that one would also be complete in aarch64?
If I got all those threats right, the tb@ version would be the correct one?
Both attached below.


How do I get a BTI enabled machine?

Sebastian

tb@ version:

Index: patches/patch-block_trampolines_S
===
RCS file: patches/patch-block_trampolines_S
diff -N patches/patch-block_trampolines_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-block_trampolines_S   28 Feb 2024 20:08:24 -
@@ -0,0 +1,19 @@
+Index: block_trampolines.S
+--- block_trampolines.S.orig
 block_trampolines.S
+@@ -22,6 +22,7 @@
+ // x86-64 trampoline
+ 

+ .macro trampoline arg0, arg1
++  endbr64
+   mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
argument
+   xchg  \arg1, \arg0   # Swap the first and second arguments
+   jmp   *-0x1008(%rip) # Call the block function
+@@ -121,6 +122,7 @@
+ // AArch64 (ARM64) trampoline
+ 

+ .macro trampoline arg0, arg1
++  bti c
+   adr x17, #-4096
+   mov \arg1, \arg0
+   ldp \arg0, x17, [x17]
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -47,7 +47,7 @@
+ #   define EH_NOP .seh_nop
+ #else
+ // Marks the real start and end of the function
+-#   define EH_START .cfi_startproc
++#   define EH_START .cfi_startproc; bti c
+ #   define EH_END .cfi_endproc
+ 
+ // The following directives are either not
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
 objc_msgSend.x86-64.S
+@@ -8,7 +8,7 @@
+ # define SECOND_ARGUMENT %rdx
+ # define THIRD_ARGUMENT %r8
+ #else
+-# define START_PROC(x) .cfi_startproc
++# define START_PROC(x) .cfi_startproc; endbr64
+ # define END_PROC(x) .cfi_endproc
+ # define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
+ # define FIRST_ARGUMENT_STR "%rdi"



@jca version:



Index: Makefile
===
RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -p -r1.37 Makefile
--- Makefile5 Mar 2024 16:11:15 -   1.37
+++ Makefile6 Mar 2024 17:26:11 -
@@ -4,7 +4,7 @@ COMMENT =   GNUstep libobjc2 objective-c r
 
 # note: this port does not use the gnustep module
 VERSION =  2.2
-REVISION = 3
+REVISION = 4
 GH_ACCOUNT =   gnustep
 GH_PROJECT =   libobjc2
 GH_TAGNAME =   v${VERSION}
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
@@ -0,0 +1,11 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend_stret):
+   EH_START
++  btic
+ 
+