Re: Chromium tabs immediately SIGSEGV on arm64

[Jonathan Gray]

On Sun, Sep 15, 2024 at 07:57:09PM +1000, Jonathan Gray wrote:
> On Sun, Sep 15, 2024 at 11:37:18AM +0200, Caspar Schutijser wrote:
> > Hi,
> > 
> > On my M1, tabs in Chromium immediately show "Aw, Snap!" with
> > "Error code: SIGSEGV" when a tab is opened (so also immediately on the
> > first tab that's opened when starting the browser, without any
> > interaction beyond starting the browser). This applies to all three
> > Chromium variants that are available in the ports tree. Below is
> > console output of Chromium, a part of the ktrace dump
> > (surrounding the SIGSEGVs), the versions of the Chromium browsers
> > that I currently have on my system, and a dmesg.
> > 
> > A couple of weeks ago (perhaps 2 or 3 weeks ago) they were still working
> > fine. Let me know if I can provide more information.
> > 
> > Caspar
> 
> ..
> 
> > chrome:/usr/X11R6/lib/libvulkan_radeon.so: undefined symbol 
> > 'blake3_hash_many_neon'
> 
> untested diff for that

fixes undefined symbol but still SIGSEGVs on M1

> 
> Index: lib/mesa/mk/libblake3/Makefile
> ===
> RCS file: /cvs/xenocara/lib/mesa/mk/libblake3/Makefile,v
> diff -u -p -r1.1 Makefile
> --- lib/mesa/mk/libblake3/Makefile2 Apr 2024 10:42:12 -   1.1
> +++ lib/mesa/mk/libblake3/Makefile15 Sep 2024 09:50:19 -
> @@ -13,6 +13,8 @@ SRCS+=  blake3_sse2_x86-64_unix.S \
>   blake3_sse41_x86-64_unix.S \
>   blake3_avx2_x86-64_unix.S \
>   blake3_avx512_x86-64_unix.S
> +.elif ${MACHINE_ARCH} == "aarch64"
> +SRCS+=   blake3_neon.c
>  .endif
>  
>  .include "../Makefile.inc"
> 
> 

Re: Chromium tabs immediately SIGSEGV on arm64

[Jonathan Gray]

On Sun, Sep 15, 2024 at 11:37:18AM +0200, Caspar Schutijser wrote:
> Hi,
> 
> On my M1, tabs in Chromium immediately show "Aw, Snap!" with
> "Error code: SIGSEGV" when a tab is opened (so also immediately on the
> first tab that's opened when starting the browser, without any
> interaction beyond starting the browser). This applies to all three
> Chromium variants that are available in the ports tree. Below is
> console output of Chromium, a part of the ktrace dump
> (surrounding the SIGSEGVs), the versions of the Chromium browsers
> that I currently have on my system, and a dmesg.
> 
> A couple of weeks ago (perhaps 2 or 3 weeks ago) they were still working
> fine. Let me know if I can provide more information.
> 
> Caspar

..

> chrome:/usr/X11R6/lib/libvulkan_radeon.so: undefined symbol 
> 'blake3_hash_many_neon'

untested diff for that

Index: lib/mesa/mk/libblake3/Makefile
===
RCS file: /cvs/xenocara/lib/mesa/mk/libblake3/Makefile,v
diff -u -p -r1.1 Makefile
--- lib/mesa/mk/libblake3/Makefile  2 Apr 2024 10:42:12 -   1.1
+++ lib/mesa/mk/libblake3/Makefile  15 Sep 2024 09:50:19 -
@@ -13,6 +13,8 @@ SRCS+=blake3_sse2_x86-64_unix.S \
blake3_sse41_x86-64_unix.S \
blake3_avx2_x86-64_unix.S \
blake3_avx512_x86-64_unix.S
+.elif ${MACHINE_ARCH} == "aarch64"
+SRCS+= blake3_neon.c
 .endif
 
 .include "../Makefile.inc"

Re: firmware update for qwx and qwz

[Jonathan Gray]

On Wed, Sep 11, 2024 at 08:29:41AM +0200, Peter Hessler wrote:
> Update qwx and qwz firmwares to the most recent release, instead of a
> git snapshot.
> 
> OK?

qwx
b1de0237a78a84baf7e1e2a1e9585405b88d82f8..20240909 ath11k/WCN6855
no change

qwz
b1de0237a78a84baf7e1e2a1e9585405b88d82f8..20240909 ath12k/WCN7850
no change

ok jsg@

> 
> 
> 
> Index: sysutils/firmware/qwx/Makefile
> ===
> RCS file: /cvs/openbsd/ports/sysutils/firmware/qwx/Makefile,v
> diff -u -p -u -p -r1.3 Makefile
> --- sysutils/firmware/qwx/Makefile17 Aug 2024 08:39:38 -  1.3
> +++ sysutils/firmware/qwx/Makefile9 Sep 2024 22:42:58 -
> @@ -1,17 +1,13 @@
>  FW_DRIVER=   qwx
>  
> -FW_VER=  20240815
> -DISTNAME=linux-firmware-b1de0237a78a84baf7e1e2a1e9585405b88d82f8
> -PKG_NAME=linux-firmware-${FW_VER}
> +FW_VER=  20240909
>  
> -#DISTNAME=   linux-firmware-${FW_VER}
> -#EXTRACT_SUFX=   .tar.xz
> +DISTNAME=linux-firmware-${FW_VER}
> +EXTRACT_SUFX=.tar.xz
>  # broad enough to reduce WRKSRC size but specific enough to match all 
> DISTFILES
>  EXTRACT_FILES=   \*/{ath11k\*,LICEN\*,WHENCE}
>  
> -#SITES=  https://cdn.kernel.org/pub/linux/kernel/firmware/
> -SITES=   
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/
> -
> +SITES=   https://cdn.kernel.org/pub/linux/kernel/firmware/
>  HOMEPAGE=
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath11k
>  
>  # can be redistributed, but shouldn't be in normal packages directory as
> Index: sysutils/firmware/qwx/distinfo
> ===
> RCS file: /cvs/openbsd/ports/sysutils/firmware/qwx/distinfo,v
> diff -u -p -u -p -r1.3 distinfo
> --- sysutils/firmware/qwx/distinfo17 Aug 2024 08:39:38 -  1.3
> +++ sysutils/firmware/qwx/distinfo9 Sep 2024 22:43:10 -
> @@ -1,2 +1,2 @@
> -SHA256 
> (firmware/linux-firmware-b1de0237a78a84baf7e1e2a1e9585405b88d82f8.tar.gz) = 
> sYa5xbB3dMoHd/5T52IhCs2/RV5p0x/vD1cc6uHOSEU=
> -SIZE 
> (firmware/linux-firmware-b1de0237a78a84baf7e1e2a1e9585405b88d82f8.tar.gz) = 
> 585194788
> +SHA256 (firmware/linux-firmware-20240909.tar.xz) = 
> lD+9GYg8+OrfieCyJCJUnbBWVXsezTClZABhWXE2lnE=
> +SIZE (firmware/linux-firmware-20240909.tar.xz) = 383099276
> Index: sysutils/firmware/qwz/Makefile
> ===
> RCS file: /cvs/openbsd/ports/sysutils/firmware/qwz/Makefile,v
> diff -u -p -u -p -r1.1.1.1 Makefile
> --- sysutils/firmware/qwz/Makefile18 Aug 2024 14:56:44 -  1.1.1.1
> +++ sysutils/firmware/qwz/Makefile9 Sep 2024 22:42:26 -
> @@ -1,16 +1,13 @@
>  FW_DRIVER=   qwz
>  
> -FW_VER=  20240815
> -DISTNAME=linux-firmware-b1de0237a78a84baf7e1e2a1e9585405b88d82f8
> +FW_VER=  20240909
>  
> -#DISTNAME=   linux-firmware-${FW_VER}
> -#EXTRACT_SUFX=   .tar.xz
> +DISTNAME=linux-firmware-${FW_VER}
> +EXTRACT_SUFX=.tar.xz
>  # broad enough to reduce WRKSRC size but specific enough to match all 
> DISTFILES
>  EXTRACT_FILES=   \*/{ath12k\*,LICEN\*,WHENCE}
>  
> -#SITES=  https://cdn.kernel.org/pub/linux/kernel/firmware/
> -SITES=   
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/
> -
> +SITES=   https://cdn.kernel.org/pub/linux/kernel/firmware/
>  HOMEPAGE=
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath12k
>  
>  # can be redistributed, but shouldn't be in normal packages directory as
> Index: sysutils/firmware/qwz/distinfo
> ===
> RCS file: /cvs/openbsd/ports/sysutils/firmware/qwz/distinfo,v
> diff -u -p -u -p -r1.1.1.1 distinfo
> --- sysutils/firmware/qwz/distinfo18 Aug 2024 14:56:44 -  1.1.1.1
> +++ sysutils/firmware/qwz/distinfo9 Sep 2024 22:41:56 -
> @@ -1,2 +1,2 @@
> -SHA256 
> (firmware/linux-firmware-b1de0237a78a84baf7e1e2a1e9585405b88d82f8.tar.gz) = 
> sYa5xbB3dMoHd/5T52IhCs2/RV5p0x/vD1cc6uHOSEU=
> -SIZE 
> (firmware/linux-firmware-b1de0237a78a84baf7e1e2a1e9585405b88d82f8.tar.gz) = 
> 585194788
> +SHA256 (firmware/linux-firmware-20240909.tar.xz) = 
> lD+9GYg8+OrfieCyJCJUnbBWVXsezTClZABhWXE2lnE=
> +SIZE (firmware/linux-firmware-20240909.tar.xz) = 383099276
> 
> -- 
> Every little picofarad has a nanohenry all its own.
>   -- Don Vonada
> 
> 

Re: [new/wip] games/openxray (S.T.A.L.K.E.R.)

[Jonathan Gray]

On Mon, Aug 26, 2024 at 12:36:50AM +0200, Benjamin Stürz wrote:
> Hi ports@,
> 
> here is a WIP port of the OpenXRay game engine,
> used by the S.T.A.L.K.E.R. series of games.
> 
> WWW: https://github.com/OpenXRay/xray-16
> 
> The linking step requires large amounts of RAM,
> so before compiling, make sure you have your limits set:
> 
>   $ ulimit -d $(ulimit -Hd)
> 
> 4GB of RAM are not enough, but 16GB work fine.
> 
> 
> If you want to start the game, you'll have to own a copy of
> S.T.A.L.K.E.R Call of Pripyat or Clear Sky,
> and you'll have to follow these steps, after installing:
> 
> https://github.com/OpenXRay/xray-16/wiki/%5BEN%5D-How-to-build-and-setup-on-Linux#game-resources
> 
> At last, run the game with `xr_3da`.
> On the first start it may crash while compiling shaders.
> Just re-run and it has probably fixed itself.
> 
> 
> Any testing and feedback is very appreciated,
> especially on how to simplify the pre-configure step.

The licensing/legality of this has not changed since
last time:

https://marc.info/?l=openbsd-ports&m=161442903129677&w=2

handle intel rewriting microcode git history

[Jonathan Gray]

Intel rewrote the history of their git repository and retagged
to change 06-a5-03.

distfile checksum failure reported by tb@

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
diff -u -p -r1.41 Makefile
--- Makefile14 Aug 2024 01:58:57 -  1.41
+++ Makefile15 Aug 2024 08:32:45 -
@@ -1,11 +1,12 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20240813
+FW_VER=20240814
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
-GH_TAGNAME=microcode-${FW_VER}
+#GH_TAGNAME=   microcode-${FW_VER}
+GH_TAGNAME=microcode-20240813
 
 MAINTAINER=Jonathan Gray 
 
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
diff -u -p -r1.33 distinfo
--- distinfo14 Aug 2024 01:58:57 -  1.33
+++ distinfo15 Aug 2024 08:32:58 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20240813.tar.gz) = 
geEei6wPAbNcicx3LwaOOyIwWoEOsFIaCOftJFO826Y=
-SIZE (firmware/intel-20240813.tar.gz) = 12879091
+SHA256 (firmware/intel-20240814.tar.gz) = 
9Gz+HYvo08LFoPtj/E1Ix90URPNDRvDkKtkscGy5Dnk=
+SIZE (firmware/intel-20240814.tar.gz) = 12879301

Re: SDL2 libs names

[Jonathan Gray]

On Fri, Aug 02, 2024 at 09:25:41AM +0200, Robert Palm wrote:
> 
> Quoting Thomas Frohwein :
> 
> > On Wed, Jul 31, 2024 at 09:48:31PM +0200, Robert Palm wrote:
> > > 
> > > Hi,
> > > 
> > > I would like to know why, the following libs are named
> > > 
> > > libSDL2_image.so.1.1
> > > libSDL2_ttf.so.0.1
> > > 
> > > and not
> > > 
> > > libSDL2_image-2.0.so.0
> > > libSDL2_ttf-2.0.so.0
> > > 
> > > Ports:
> > > devel/sdl2-image
> > > devel/sdl2_ttf
> > > 
> > > Is it because of CMAKE_SHARED_LIBRARY_SUFFIX ? How does it work?
> > > 
> > > Thank you.
> > > 
> > 
> > As to the why in the sense of the reason for the decision - this
> > decision was made before my time. My understanding is that upstream
> > decision to append '-2.0' didn't serve a useful purpose (SDL2 in the
> > library name really tells you everything and at this point it looks
> > like the next version will be SDL3).
> > 
> > Also note the comment in CMakeLists.txt:
> > 
> > # For historical reasons, the library name redundantly includes the major
> > # version twice: libSDL2-2.0.so.0.
> > 
> > As to the technical why - the port uses configure/Makefile and the patch
> > for Makefile.in removes the use of LT_RELEASE which is responsible for
> > the '-2.0' in other platforms.
> > 
> > This is for devel/sdl2, probably similar for the sdl2-* ports. At this
> > point this is moot as upstream has already acknowledged that this
> > library naming will be stopped with SDL3.
> 
> Hi Thomas,
> 
> understand - thanks a lot for your detailed explanations!
> 
> I'll simply use symlinks so that the sdl2 libs can be found...typically,
> they are refered to by the 2 "standard" designators like
> 
> ("libSDL2_ttf-2.0.so.0" "libSDL2_ttf")
> ("libSDL2_image-2.0.so.0" "libSDL2_image")

don't use links, the major number may change

and dlopen'ing libname.so and libname.so.major work without them

change vaapi .so dirs in ports

[Jonathan Gray]

The ports part of a tech@ diff to change the directories libva looks
for .so files in.

removes the need for @sample

Index: graphics/intel-media-driver/Makefile
===
RCS file: /cvs/ports/graphics/intel-media-driver/Makefile,v
diff -u -p -r1.5 Makefile
--- graphics/intel-media-driver/Makefile22 Jul 2024 13:09:45 -  
1.5
+++ graphics/intel-media-driver/Makefile23 Jul 2024 05:19:23 -
@@ -6,7 +6,7 @@ VERSION =   24.1.5
 GH_ACCOUNT =   intel
 GH_PROJECT =   media-driver
 GH_TAGNAME =   intel-media-${VERSION}
-REVISION = 0
+REVISION = 1
 
 DISTNAME = intel-media-driver-${VERSION}
 
@@ -29,7 +29,7 @@ CONFIGURE_ARGS =  -DMEDIA_RUN_TEST_SUITE=
 CONFIGURE_ARGS +=  -DMEDIA_BUILD_FATAL_WARNINGS=OFF \
-DBUILD_CMRTLIB=OFF
 
-CONFIGURE_ARGS +=  -DLIBVA_DRIVERS_PATH="${LOCALBASE}/lib/xorg/modules"
+CONFIGURE_ARGS +=  -DLIBVA_DRIVERS_PATH="${LOCALBASE}/lib/dri"
 
 # build dependency on libva
 MODCMAKE_LDFLAGS = -L${X11BASE}/lib -L${LOCALBASE}/lib
Index: graphics/intel-media-driver/pkg/PLIST
===
RCS file: /cvs/ports/graphics/intel-media-driver/pkg/PLIST,v
diff -u -p -r1.1.1.1 PLIST
--- graphics/intel-media-driver/pkg/PLIST   15 Jul 2024 19:27:04 -  
1.1.1.1
+++ graphics/intel-media-driver/pkg/PLIST   23 Jul 2024 05:18:54 -
@@ -1,4 +1,2 @@
-lib/xorg/
-lib/xorg/modules/
-@so lib/xorg/modules/iHD_drv_video.so
-@sample ${X11BASE}/lib/modules/drivers/iHD_drv_video.so
+lib/dri/
+@so lib/dri/iHD_drv_video.so
Index: graphics/intel-vaapi-driver/Makefile
===
RCS file: /cvs/ports/graphics/intel-vaapi-driver/Makefile,v
diff -u -p -r1.4 Makefile
--- graphics/intel-vaapi-driver/Makefile20 Jul 2024 07:19:05 -  
1.4
+++ graphics/intel-vaapi-driver/Makefile23 Jul 2024 05:19:51 -
@@ -5,6 +5,7 @@ COMMENT =   VAAPI legacy driver for Intel 
 GH_ACCOUNT =   intel
 GH_PROJECT =   intel-vaapi-driver
 GH_TAGNAME =   2.4.1
+REVISION = 0
 
 CATEGORIES =   graphics multimedia
 
@@ -17,7 +18,7 @@ MODULES = devel/meson
 
 COMPILER = base-clang ports-gcc
 
-MODMESON_CONFIGURE_ARGS += -Ddriverdir="${LOCALBASE}/lib/xorg/modules" \
+MODMESON_CONFIGURE_ARGS += -Ddriverdir="${LOCALBASE}/lib/dri" \
-Dwith_wayland=no
 
 pre-fake:
Index: graphics/intel-vaapi-driver/pkg/PLIST
===
RCS file: /cvs/ports/graphics/intel-vaapi-driver/pkg/PLIST,v
diff -u -p -r1.1.1.1 PLIST
--- graphics/intel-vaapi-driver/pkg/PLIST   15 Jul 2024 19:20:09 -  
1.1.1.1
+++ graphics/intel-vaapi-driver/pkg/PLIST   23 Jul 2024 05:20:08 -
@@ -1,4 +1,2 @@
-lib/xorg/
-lib/xorg/modules/
-@so lib/xorg/modules/i965_drv_video.so
-@sample ${X11BASE}/lib/modules/drivers/i965_drv_video.so
+lib/dri/
+@so lib/dri/i965_drv_video.so

Re: NEW: multimedia/intel-media-driver

[Jonathan Gray]

On Sat, Jul 13, 2024 at 12:51:39PM +0200, Rafael Sadowski wrote:
> OK to import intel-media-driver-24.1.5? Keep in mind, to build this you
> need libv installed from xenocara.
> 
> Comment:
> Intel(R) Media Driver for VAAPI
> 
> Description:
> VA-API (Video Acceleration API) user mode driver for Intel GEN Graphics family
> 
> VA-API is an open-source library and API specification, which provides access 
> to
> graphics hardware acceleration capabilities for video processing. It consists 
> of
> a main library and driver-specific acceleration backends for each supported
> hardware vendor.
> 
> The current video driver backend provides a bridge to the GEN GPUs through the
> packaging of buffers and commands to be sent to the i915 driver for exercising
> both hardware and shader functionality for video decode, encode, and 
> processing.

Why are you putting .so files into X11BASE with @sample?

lib/xorg/
lib/xorg/modules/
@so lib/xorg/modules/iHD_drv_video.so
@sample ${X11BASE}/lib/modules/drivers/iHD_drv_video.so

@sample is for sample configuration files according to pkg_create(1)

Shouldn't the .so built in ports go into LOCALBASE and
libva search both X11BASE and LOCALBASE paths?

Re: infrastructure/db/network.conf: update SITE_XORG

[Jonathan Gray]

On Sun, Apr 28, 2024 at 06:49:54PM +0200, Matthieu Herrb wrote:
> Hi,
> 
> X.Org / Freedesktop moved things around a bit and /pub is not
> available anymore; it's now called /archive ... Also they advertize
> xorg.freedesktop.org instead of ftp.x.org as the hostname in all
> recent packages announcements (both are CNAME for the same host
> currently. 
> 
> ok ? Comments ?

the old path redirects to
https://www.x.org/archive/individual/driver/
which is the same machine

I agree on matching what they use in release announcements.
ok jsg@

> 
> Index: network.conf
> ===
> RCS file: /local/cvs/ports/infrastructure/db/network.conf,v
> diff -u -p -u -r1.25 network.conf
> --- network.conf  3 Feb 2024 11:49:55 -   1.25
> +++ network.conf  28 Apr 2024 16:48:49 -
> @@ -35,7 +35,7 @@ SITE_GCC+=  \
>   http://robotlab.itk.ppke.hu/gcc/
>  
>  SITE_XORG+=  \
> - https://ftp.x.org/pub/individual/ \
> + https://xorg.freedesktop.org/archive/individual/ \
>   https://ftp.gwdg.de/pub/x11/x.org/pub/individual/ \
>   https://ftp.mirrorservice.org/sites/ftp.x.org/pub/individual/
>  
> 
> 
> 
> -- 
> Matthieu Herrb
> 
> 

Re: sysuitls/u-boot: split off 32-bit ARM Allwinner SoCs

[Jonathan Gray]

On Fri, Mar 22, 2024 at 03:56:35PM +0100, Mark Kettenis wrote:
> The diff below splits off the 32-bit ARM Allwinner SoCs and updates
> them to U-Boot 2024.01.  I've tested this on a few of my armv7 boards
> and I'm pretty confident it doesn't break any of them.
> 
> Theo, this has consequences for the armv7 miniroots as the "cubie"
> variant includes firmwares that move from u-boot-arm to u-boot-sunxi.
> There are a few possibilities to handle this:
> 
> * You (and other folks building releases) install the new packages by hand.
> 
> * We add some ports magic such that updating the u-boot-arm package
>   will also install the new u-boot-sunxi package.  Stuart told me how
>   to do that somewhat recently.
> 
> * We drop the "cubie" miniroot.
> 
> I'm somewhat leaning towards the last option myself.  Very few people
> own a cubieboard so it isn't really helping people.  In fact I'm very
> much inclined to move armv7 to a single miniroot image in the long
> run.
> 
> Thoughts?

I agree it can go.  The cubie miniroot is specifically for the
Allwinner A20 based Cubieboard 2 (changed from A10 Cubieboard in 2016).

update games/wrath to 1.0

[Jonathan Gray]

Wrath left early access and the old repo was removed.
Build tested only.

Index: Makefile
===
RCS file: /cvs/ports/games/wrath/Makefile,v
diff -u -p -r1.6 Makefile
--- Makefile15 Nov 2023 12:59:32 -  1.6
+++ Makefile28 Feb 2024 10:44:57 -
@@ -1,10 +1,10 @@
 COMMENT =  client of wrath-darkplaces engine
 
-DISTNAME = wrath-0.0.0.20210608
+DISTNAME = wrath-1.0
 
-GH_ACCOUNT =   KillPixelGames
+GH_ACCOUNT =   Official3DRealms
 GH_PROJECT =   wrath-darkplaces
-GH_COMMIT =e0770286b39bb137f3457b05acbd4c6a46044488
+GH_COMMIT =d7a494fbe76f45a84d1df0c7360c0c4848042e45
 
 CATEGORIES =   games
 
@@ -33,6 +33,6 @@ MAKE_FILE =   makefile
 ALL_TARGET =   sdl2-release
 
 do-install:
-   ${INSTALL_PROGRAM} ${WRKBUILD}/darkplaces-sdl ${PREFIX}/bin/wrath
+   ${INSTALL_PROGRAM} ${WRKBUILD}/wrath-sdl ${PREFIX}/bin/wrath
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/games/wrath/distinfo,v
diff -u -p -r1.4 distinfo
--- distinfo15 Nov 2023 12:59:32 -  1.4
+++ distinfo28 Feb 2024 10:41:46 -
@@ -1,2 +1,2 @@
-SHA256 (wrath-0.0.0.20210608-e0770286.tar.gz) = 
GEGpfWWKoA/fg3AEe2jGQKCfp36KHutfmfdNG6xrpc0=
-SIZE (wrath-0.0.0.20210608-e0770286.tar.gz) = 2688056
+SHA256 (wrath-1.0-d7a494fb.tar.gz) = 
gl5B8+tVp0cZN4MEQ/DOJHgVFKM8x5eCy7E03F4ZnU8=
+SIZE (wrath-1.0-d7a494fb.tar.gz) = 2710199

Re: Updating to newest sway, wlroots, and libdrm

[Jonathan Gray]

On Thu, Jan 04, 2024 at 11:07:56AM +0100, Matthieu Herrb wrote:
> On Wed, Jan 03, 2024 at 07:52:56PM -0700, Chris Waddey wrote:
> > Hello.
> 
> Hi,
> 
> > I was able to get the latest version of sway working on my box after
> > getting the latest version of wlroots to work, which was after applying
> > the following patch to the latest version of libdrm (source obtained
> > from https://gitlab.freedesktop.org/mesa/drm.git). I don't know if we
> > have some patches somewhere else that handle this, but I figured I
> > would send it your way in case it would save some effort.
> 
> Does this include the removal of the wlr_drm protocol which was
> committed to sway/wlroots a few hours ago ?
> 
> I wasn't sure if OpenBSD libdrm / mesa supports linux-dmabuf which is
> supposed to replace it.
> 
> If it works with linux-dmabuf, that's great news. I don't think there
> are any other significant changes since the released versions packaged
> in ports that could impact OpenBSD.
> 
> > I also had to do
> > 
> > doas chmod $USER:$USER /dev/dri/* && env WLR_RENDERER=pixman
> > startsway.sh
> 
> Normally if you log in on the text console where you want to run sway,
> the /dev/dri/* owndership  is taken care of by fbtab(5).
> 
> I think setting WLR_RENDERER to pixman means that you don't use the
> new linux-dmabuf protocol. What happens if you leave that variable
> undefined (defaults to 'auto') ?
> 
> > to get everything just right. And of course I applied the patches I
> > found in ports to sway and wlroots, but nothing else that I can
> > think of.
> 
> This diff is present in the /usr/xenocara/lib/libdrm tree. (not
> exactly the same though: the whole #ifdef __OpenBSD__ part can be
> removed now).

attempts to merge the patches upstream stalled years ago

https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/119

Re: fix games/wrath build with llvm 16

[Jonathan Gray]

On Wed, Nov 15, 2023 at 04:43:16PM +1100, Jonathan Gray wrote:
> http://build-failures.rhaalovely.net/amd64-clang/2023-11-13/games/wrath.log
> 
> games/wrath build is fixed with a commit after the one we have
> 
> https://github.com/KillPixelGames/wrath-darkplaces/commit/e0770286b39bb137f3457b05acbd4c6a46044488.patch

and remove MAINTAINER
rei...@enmadechi.com: Domain does not exist

Index: games/wrath/Makefile
===
RCS file: /cvs/ports/games/wrath/Makefile,v
diff -u -p -r1.5 Makefile
--- games/wrath/Makefile11 Mar 2022 19:05:13 -  1.5
+++ games/wrath/Makefile15 Nov 2023 05:47:42 -
@@ -1,14 +1,12 @@
 COMMENT =  client of wrath-darkplaces engine
 
-DISTNAME = wrath-0.0.0.20210114
+DISTNAME = wrath-0.0.0.20210608
 
 GH_ACCOUNT =   KillPixelGames
 GH_PROJECT =   wrath-darkplaces
-GH_COMMIT =2e4c399f3b6428d313d408d84f9e3ac6355a857e
+GH_COMMIT =e0770286b39bb137f3457b05acbd4c6a46044488
 
 CATEGORIES =   games
-
-MAINTAINER =   Paul Valencia 
 
 # GPLv2
 PERMIT_PACKAGE =   Yes
Index: games/wrath/distinfo
===
RCS file: /cvs/ports/games/wrath/distinfo,v
diff -u -p -r1.3 distinfo
--- games/wrath/distinfo14 Feb 2021 10:54:16 -  1.3
+++ games/wrath/distinfo15 Nov 2023 05:47:42 -
@@ -1,2 +1,2 @@
-SHA256 (wrath-0.0.0.20210114-2e4c399f.tar.gz) = 
SoI3jHCfGwHqVxx6msqL2rSXFc7bYat+XFdemRzGcIU=
-SIZE (wrath-0.0.0.20210114-2e4c399f.tar.gz) = 2687876
+SHA256 (wrath-0.0.0.20210608-e0770286.tar.gz) = 
GEGpfWWKoA/fg3AEe2jGQKCfp36KHutfmfdNG6xrpc0=
+SIZE (wrath-0.0.0.20210608-e0770286.tar.gz) = 2688056

fix games/wrath build with llvm 16

[Jonathan Gray]

http://build-failures.rhaalovely.net/amd64-clang/2023-11-13/games/wrath.log

games/wrath build is fixed with a commit after the one we have

https://github.com/KillPixelGames/wrath-darkplaces/commit/e0770286b39bb137f3457b05acbd4c6a46044488.patch

Index: games/wrath/Makefile
===
RCS file: /cvs/ports/games/wrath/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- games/wrath/Makefile11 Mar 2022 19:05:13 -  1.5
+++ games/wrath/Makefile15 Nov 2023 05:33:01 -
@@ -1,10 +1,10 @@
 COMMENT =  client of wrath-darkplaces engine
 
-DISTNAME = wrath-0.0.0.20210114
+DISTNAME = wrath-0.0.0.20210608
 
 GH_ACCOUNT =   KillPixelGames
 GH_PROJECT =   wrath-darkplaces
-GH_COMMIT =2e4c399f3b6428d313d408d84f9e3ac6355a857e
+GH_COMMIT =e0770286b39bb137f3457b05acbd4c6a46044488
 
 CATEGORIES =   games
 
Index: games/wrath/distinfo
===
RCS file: /cvs/ports/games/wrath/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- games/wrath/distinfo14 Feb 2021 10:54:16 -  1.3
+++ games/wrath/distinfo15 Nov 2023 05:33:01 -
@@ -1,2 +1,2 @@
-SHA256 (wrath-0.0.0.20210114-2e4c399f.tar.gz) = 
SoI3jHCfGwHqVxx6msqL2rSXFc7bYat+XFdemRzGcIU=
-SIZE (wrath-0.0.0.20210114-2e4c399f.tar.gz) = 2687876
+SHA256 (wrath-0.0.0.20210608-e0770286.tar.gz) = 
GEGpfWWKoA/fg3AEe2jGQKCfp36KHutfmfdNG6xrpc0=
+SIZE (wrath-0.0.0.20210608-e0770286.tar.gz) = 2688056

Re: Clean up sysutils/u-boot a bit

[Jonathan Gray]

On Thu, Oct 19, 2023 at 08:17:29PM +0200, Mark Kettenis wrote:
> Back when I split up the port, Stuart suggested to see if some
> simplification of the do-build rule would be possible.  I think the
> most sensible thing to do is to move this from Makefile.inc into the
> per-directory Makefile.  There is a tiny bit of duplication, but I
> think the result is more manageable, especially if we add more per-SoC
> directories.
> 
> Since this doesn't change the output, no REVISION bump is needed is it?
> 
> ok?

looks good
ok jsg@

> 
> 
> Index: sysutils/u-boot/Makefile.inc
> ===
> RCS file: /cvs/ports/sysutils/u-boot/Makefile.inc,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile.inc
> --- sysutils/u-boot/Makefile.inc  17 Oct 2023 19:36:22 -  1.8
> +++ sysutils/u-boot/Makefile.inc  19 Oct 2023 18:00:06 -
> @@ -57,82 +57,6 @@ FILES=\
>   spl/sunxi-spl.bin \
>   spl/u-boot-spl.bin
>  
> -do-build:
> -.for BOARD in ${BOARDS}
> - cd ${WRKSRC} && \
> - mkdir -p build/${BOARD} && \
> - ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
> - O="build/${BOARD}" \
> - -f ${MAKE_FILE} "${BOARD}"_defconfig
> -.if "${BOARD:M*-rk3399*}"
> - cd ${WRKSRC} && \
> - ${SETENV} ${MAKE_ENV} BL31=${RK3399_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.elif "${BOARD:M*-rk3328}"
> - cd ${WRKSRC} && \
> - ${SETENV} ${MAKE_ENV} BL31=${RK3328_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.elif "${BOARD:M*-rk3566*}"
> - cd ${WRKSRC}/build/${BOARD} && \
> - ../../scripts/config --set-val BAUDRATE 115200
> - cd ${WRKSRC} && \
> - ${SETENV} ${MAKE_ENV} ROCKCHIP_TPL=${RK3566_TPL} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.elif "${BOARD:M*-rk3568*}"
> - cd ${WRKSRC}/build/${BOARD} && \
> - ../../scripts/config --set-val BAUDRATE 115200
> - cd ${WRKSRC} && \
> - ${SETENV} ${MAKE_ENV} ROCKCHIP_TPL=${RK3568_TPL} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.elif "${BOARD:M*sifive_*}"
> - cd ${WRKSRC} && \
> - ${SETENV} ${MAKE_ENV} OPENSBI=${FW_DYNAMIC} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.else
> - cd ${WRKSRC} && \
> - ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
> - O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.endif
> -.if "${BOARD:M*-rk3288}"
> - cd ${WRKSRC}/build/${BOARD} && \
> - tools/mkimage -n rk3288 -T rksd -d tpl/u-boot-tpl.bin \
> - idbloader.img && \
> - cat spl/u-boot-spl-dtb.bin >> idbloader.img
> -.endif
> -.endfor
> -.for BOARD in ${SUNXI64}
> -.if "${BOARD:M*_h64*}"
> - cd ${WRKSRC} && \
> - mkdir -p build/${BOARD} && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} "${BOARD}"_defconfig && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.else
> - cd ${WRKSRC} && \
> - mkdir -p build/${BOARD} && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} "${BOARD}"_defconfig && \
> - ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
> - ${MAKE_FLAGS} O="build/${BOARD}" \
> - -f ${MAKE_FILE} ${ALL_TARGET}
> -.endif
> - if [[ -f ${WRKSRC}/build/${BOARD}/spl/sunxi-spl.bin && \
> -   -f ${WRKSRC}/build/${BOARD}/u-boot.itb ]]; then \
> - cd ${WRKSRC}/build/${BOARD} && \
> - cat spl/sunxi-spl.bin u-boot.itb > 
> u-boot-sunxi-with-spl.bin ; \
> - fi
> -.endfor
> -
>  do-install:
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/u-boot
>  .for BOARD in ${BOARDS} ${SUNXI64}
> Index: sysutils/u-boot/aarch64/Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot/aarch64/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- sysutils/u-boot/aarch64/Makefile  2 Sep 2023 14:33:03 -   1.4
> +++ sysutils/u-boot/aarch64/Makefile  19 Oct 2023 18:00:06 -
> @@ -46,4 +46,55 @@ SUNXI_H6_BL31= ${LOCALBASE}/share/arm-tr
>  
>  MODPY_ADJ_FILES= arch/arm/mach-rockchip/make_fit_atf.py
>  
> +do-build:
> +.for BOARD in ${BOARDS}
> + cd ${WRKSRC} && \
> + mkdir -p build/${BOARD} && \
> + ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM

Re: Enable LTO for arm/aarch64 cross-compiler

[Jonathan Gray]

On Sat, Sep 23, 2023 at 09:31:16PM +0200, Mark Kettenis wrote:
> Newer U-Boot versions have started to require LTO in order to save
> some space for certain targets.  I don't see a downside in enabling it
> as the cross compiler won't be used to build OpenBSD binaries.
> 
> ok?

if atf, m1n1, u-boot, newlib still build, sure
ok jsg@

> 
> 
> Index: devel/arm-none-eabi/gcc/Makefile
> ===
> RCS file: /cvs/ports/devel/arm-none-eabi/gcc/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- devel/arm-none-eabi/gcc/Makefile  21 Sep 2023 09:49:48 -  1.3
> +++ devel/arm-none-eabi/gcc/Makefile  23 Sep 2023 19:25:41 -
> @@ -3,7 +3,7 @@ COMMENT=  gcc for ${CONFIG} cross-develop
>  VERSION= 12.2.0
>  DISTNAME=gcc-${VERSION}
>  PKGNAME= ${CONFIG}-gcc-${VERSION}
> -REVISION=0
> +REVISION=1
>  
>  USE_NOEXECONLY=  Yes
>  
> @@ -55,7 +55,6 @@ CONFIGURE_ARGS+=--enable-languages=${LAN
>   --with-gmp=${LOCALBASE} \
>   --with-newlib   \
>   --disable-libcc1\
> - --disable-lto   \
>   --enable-cpp\
>   --without-isl   \
>   --without-zstd
> Index: devel/arm-none-eabi/gcc/pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/arm-none-eabi/gcc/pkg/PLIST,v
> retrieving revision 1.1
> diff -u -p -r1.1 PLIST
> --- devel/arm-none-eabi/gcc/pkg/PLIST 22 Apr 2023 16:23:25 -  1.1
> +++ devel/arm-none-eabi/gcc/pkg/PLIST 23 Sep 2023 19:25:41 -
> @@ -11,6 +11,7 @@
>  @bin bin/${CONFIG}-gcov
>  @bin bin/${CONFIG}-gcov-dump
>  @bin bin/${CONFIG}-gcov-tool
> +@bin bin/${CONFIG}-lto-dump
>  libexec/gcc/
>  libexec/gcc/${CONFIG}/
>  libexec/gcc/${CONFIG}/${VERSION}/
> @@ -23,7 +24,10 @@ libexec/gcc/${CONFIG}/${VERSION}/install
>  @bin libexec/gcc/${CONFIG}/${VERSION}/install-tools/fixincl
>  libexec/gcc/${CONFIG}/${VERSION}/install-tools/mkheaders
>  libexec/gcc/${CONFIG}/${VERSION}/install-tools/mkinstalldirs
> +libexec/gcc/${CONFIG}/${VERSION}/liblto_plugin.la
> +@so libexec/gcc/${CONFIG}/${VERSION}/liblto_plugin.so
>  @bin libexec/gcc/${CONFIG}/${VERSION}/lto-wrapper
> +@bin libexec/gcc/${CONFIG}/${VERSION}/lto1
>  libexec/gcc/${CONFIG}/${VERSION}/plugin/
>  @bin libexec/gcc/${CONFIG}/${VERSION}/plugin/gengtype
>  @man man/man1/${CONFIG}-cpp.1
> @@ -35,3 +39,4 @@ libexec/gcc/${CONFIG}/${VERSION}/plugin/
>  @comment @man man/man7/fsf-funding.7
>  @comment @man man/man7/gfdl.7
>  @comment @man man/man7/gpl.7
> +@man man/man1/${CONFIG}-lto-dump.1
> 
> 

update amd microcode to 20230809

[Jonathan Gray]

Genoa and Bergamo (4th gen epyc) patches for
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html

Family=0x19 Model=0x11 Stepping=0x01: Patch=0x0a10113e Length=5568 bytes
Family=0x19 Model=0x11 Stepping=0x02: Patch=0x0a10123e Length=5568 bytes
Family=0x19 Model=0xa0 Stepping=0x02: Patch=0x0aa00212 Length=5568 bytes
Family=0x19 Model=0xa0 Stepping=0x01: Patch=0x0aa00116 Length=5568 bytes

the previous patches covered Milan (3rd gen epyc)

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/amd/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile7 Aug 2023 03:45:05 -   1.4
+++ Makefile9 Aug 2023 12:14:55 -
@@ -1,14 +1,16 @@
 COMMENT=   microcode update binaries for AMD CPUs
 FW_DRIVER= amd
-FW_VER=20230804
-DISTNAME=  linux-firmware-${FW_VER}
-EXTRACT_SUFX=  .tar.xz
+FW_VER=20230809
+DISTNAME=  linux-firmware-f2eb058afc57348cde66852272d6bf11da1eef8f
+#DISTNAME= linux-firmware-${FW_VER}
+#EXTRACT_SUFX= .tar.xz
 EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,amd-ucode}
 
 MAINTAINER=Jonathan Gray 
 
 HOMEPAGE=  
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode
-MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/firmware/
+MASTER_SITES=  
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/
+#MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/firmware/
 
 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/firmware/amd
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/amd/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo7 Aug 2023 03:45:05 -   1.3
+++ distinfo9 Aug 2023 12:17:00 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/linux-firmware-20230804.tar.xz) = 
iNRsVDhH7jsDQE1JQdkckpdGkO4fb9y+6c7z5fl9tog=
-SIZE (firmware/linux-firmware-20230804.tar.xz) = 295170972
+SHA256 
(firmware/linux-firmware-f2eb058afc57348cde66852272d6bf11da1eef8f.tar.gz) = 
/NVwuLJZBJ3YSgMm8XoxMnGWL4Bsoy29nkDN2QeYV9A=
+SIZE (firmware/linux-firmware-f2eb058afc57348cde66852272d6bf11da1eef8f.tar.gz) 
= 457911356

Re: new intel code for fw_update

[Jonathan Gray]

for those wondering, the _DUPLICATE files are all older versions

06-ba-02 ver: 4119 date: 06062023
06-ba-02_DUPLICATE ver: 4112 date: 0023

06-ba-03 ver: 4119 date: 06062023
06-ba-03_DUPLICATE ver: 4112 date: 0023

06-be-00 ver: 0011 date: 04122023
06-be-00_DUPLICATE ver: 0010 date: 12192022

On Tue, Aug 08, 2023 at 07:52:41PM +0100, Stuart Henderson wrote:
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
> retrieving revision 1.35
> diff -u -p -r1.35 Makefile
> --- Makefile  15 May 2023 14:39:50 -  1.35
> +++ Makefile  8 Aug 2023 18:51:31 -
> @@ -1,7 +1,7 @@
>  COMMENT= microcode update binaries for Intel CPUs
>  FW_DRIVER=   intel
> 
> -FW_VER=  20230512
> +FW_VER=  20230808
>  EPOCH=   0
>  GH_ACCOUNT=  intel
>  GH_PROJECT=  Intel-Linux-Processor-Microcode-Data-Files
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
> retrieving revision 1.27
> diff -u -p -r1.27 distinfo
> --- distinfo  15 May 2023 14:39:50 -  1.27
> +++ distinfo  8 Aug 2023 18:51:31 -
> @@ -1,2 +1,2 @@
> -SHA256 (firmware/intel-20230512.tar.gz) = 
> WPMyHc+QAXXYfVs5RVE4wqJOad9LqZf7ROPg0Z5TGtE=
> -SIZE (firmware/intel-20230512.tar.gz) = 12654272
> +SHA256 (firmware/intel-20230808.tar.gz) = 
> /km7cZRB8gM17WAECQqzjNw3QTTTbU9dML5+2TuCAxM=
> +SIZE (firmware/intel-20230808.tar.gz) = 13011561
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/sysutils/firmware/intel/pkg/PLIST,v
> retrieving revision 1.22
> diff -u -p -r1.22 PLIST
> --- pkg/PLIST 15 May 2023 14:39:50 -  1.22
> +++ pkg/PLIST 8 Aug 2023 18:51:31 -
> @@ -123,8 +123,11 @@ firmware/intel/06-a6-01
>  firmware/intel/06-a7-01
>  firmware/intel/06-b7-01
>  firmware/intel/06-ba-02
> +@comment firmware/intel/06-ba-02_DUPLICATE
>  firmware/intel/06-ba-03
> +@comment firmware/intel/06-ba-03_DUPLICATE
>  firmware/intel/06-be-00
> +@comment firmware/intel/06-be-00_DUPLICATE
>  firmware/intel/06-bf-02
>  firmware/intel/06-bf-05
>  firmware/intel/0f-00-07
> 
> 

update amdgpu firmware to 20230804

[Jonathan Gray]

includes initial firmware for GC 11.0.3

VCN is the video codec acceleration we don't yet have userspace for.
Most of the DMCUB changes are for parts released this year.

$ git log --oneline 20230625..20230804 amdgpu
253cc179 amdgpu: Update DMCUB for DCN314 & Yellow Carp
59fbffa9 amdgpu: update VCN 4.0.0 firmware
22fb12f2 amdgpu: add initial SMU 13.0.10 firmware
b3f512fb amdgpu: add initial SDMA 6.0.3 firmware
b1a7d762 amdgpu: add initial PSP 13.0.10 firmware
d6d655ad amdgpu: add initial GC 11.0.3 firmware
9dfcacec amdgpu: update green sardine VCN firmware
b5198321 amdgpu: update renoir VCN firmware
5f569aa8 amdgpu: update raven VCN firmware
868bb363 amdgpu: update raven2 VCN firmware
6fa9a175 amdgpu: update Picasso VCN firmware
cd524606 amdgpu: update DMCUB to v0.0.175.0 for various AMDGPU ASICs
d3f66064 Partially revert "amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5"

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile29 Jun 2023 12:52:36 -  1.21
+++ Makefile6 Aug 2023 10:46:33 -
@@ -1,16 +1,13 @@
 FW_DRIVER= amdgpu
-FW_VER=20230625
-DISTNAME=  linux-firmware-045b2136a61968e7984caeae857a326150bfe851
-#DISTNAME= linux-firmware-${FW_VER}
-#EXTRACT_SUFX= .tar.xz
+FW_VER=20230804
+DISTNAME=  linux-firmware-${FW_VER}
+EXTRACT_SUFX=  .tar.xz
 EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,\*.bin}
-REVISION=  0
 
 MAINTAINER=Jonathan Gray 
 
 HOMEPAGE=  
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
-#MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/firmware/
-MASTER_SITES=  
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/
+MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/firmware/
 
 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/firmware/amdgpu
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/distinfo,v
retrieving revision 1.19
diff -u -p -r1.19 distinfo
--- distinfo29 Jun 2023 12:52:36 -  1.19
+++ distinfo6 Aug 2023 10:47:24 -
@@ -1,2 +1,2 @@
-SHA256 
(firmware/linux-firmware-045b2136a61968e7984caeae857a326150bfe851.tar.gz) = 
I5VDKGybmVgRYfpCojBZvBcpqbLb+OVuM+VBwRuB81U=
-SIZE (firmware/linux-firmware-045b2136a61968e7984caeae857a326150bfe851.tar.gz) 
= 439517447
+SHA256 (firmware/linux-firmware-20230804.tar.xz) = 
iNRsVDhH7jsDQE1JQdkckpdGkO4fb9y+6c7z5fl9tog=
+SIZE (firmware/linux-firmware-20230804.tar.xz) = 295170972
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/pkg/PLIST,v
retrieving revision 1.16
diff -u -p -r1.16 PLIST
--- pkg/PLIST   27 Jun 2023 10:11:42 -  1.16
+++ pkg/PLIST   6 Aug 2023 10:48:22 -
@@ -128,6 +128,13 @@ firmware/amdgpu/gc_11_0_2_mes1.bin
 firmware/amdgpu/gc_11_0_2_mes_2.bin
 firmware/amdgpu/gc_11_0_2_pfp.bin
 firmware/amdgpu/gc_11_0_2_rlc.bin
+firmware/amdgpu/gc_11_0_3_imu.bin
+firmware/amdgpu/gc_11_0_3_me.bin
+firmware/amdgpu/gc_11_0_3_mec.bin
+firmware/amdgpu/gc_11_0_3_mes1.bin
+firmware/amdgpu/gc_11_0_3_mes_2.bin
+firmware/amdgpu/gc_11_0_3_pfp.bin
+firmware/amdgpu/gc_11_0_3_rlc.bin
 firmware/amdgpu/gc_11_0_4_imu.bin
 firmware/amdgpu/gc_11_0_4_me.bin
 firmware/amdgpu/gc_11_0_4_mec.bin
@@ -346,6 +353,8 @@ firmware/amdgpu/polaris12_uvd.bin
 firmware/amdgpu/polaris12_vce.bin
 firmware/amdgpu/psp_13_0_0_sos.bin
 firmware/amdgpu/psp_13_0_0_ta.bin
+firmware/amdgpu/psp_13_0_10_sos.bin
+firmware/amdgpu/psp_13_0_10_ta.bin
 firmware/amdgpu/psp_13_0_11_ta.bin
 firmware/amdgpu/psp_13_0_11_toc.bin
 firmware/amdgpu/psp_13_0_4_ta.bin
@@ -399,6 +408,7 @@ firmware/amdgpu/sdma_5_2_7.bin
 firmware/amdgpu/sdma_6_0_0.bin
 firmware/amdgpu/sdma_6_0_1.bin
 firmware/amdgpu/sdma_6_0_2.bin
+firmware/amdgpu/sdma_6_0_3.bin
 firmware/amdgpu/si58_mc.bin
 firmware/amdgpu/sienna_cichlid_ce.bin
 firmware/amdgpu/sienna_cichlid_dmcub.bin
@@ -413,6 +423,7 @@ firmware/amdgpu/sienna_cichlid_sos.bin
 firmware/amdgpu/sienna_cichlid_ta.bin
 firmware/amdgpu/sienna_cichlid_vcn.bin
 firmware/amdgpu/smu_13_0_0.bin
+firmware/amdgpu/smu_13_0_10.bin
 firmware/amdgpu/smu_13_0_7.bin
 firmware/amdgpu/stoney_ce.bin
 firmware/amdgpu/stoney_me.bin

update intel microcode to 20230512

[Jonathan Gray]

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20230512

"Security updates for [INTEL-SA-NA]" no details given

the two new _DUPLICATE files (with different checksums) commented in PLIST

MD5 (06-8e-09) = daf3267deea513e55d9b045ff0487f1b
MD5 (06-8e-09_DUPLICATE) = d5db1891b8e3d0a9d5ff5856990cd904
MD5 (06-8e-0b) = 26c8a8e38366a7771bc2b3c72e82eacf
MD5 (06-8e-0b_DUPLICATE) = 3c9f02a2b7fb36ecbdbbce36547c60bc

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- Makefile16 Feb 2023 04:44:44 -  1.34
+++ Makefile15 May 2023 03:43:33 -
@@ -1,7 +1,7 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20230214
+FW_VER=20230512
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
retrieving revision 1.26
diff -u -p -r1.26 distinfo
--- distinfo16 Feb 2023 04:44:44 -  1.26
+++ distinfo15 May 2023 03:43:38 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20230214.tar.gz) = 
Ojz+LHZCM5r59MKtafXzZ9+kzR9/n9QSTe3vt4A1kdQ=
-SIZE (firmware/intel-20230214.tar.gz) = 12088391
+SHA256 (firmware/intel-20230512.tar.gz) = 
WPMyHc+QAXXYfVs5RVE4wqJOad9LqZf7ROPg0Z5TGtE=
+SIZE (firmware/intel-20230512.tar.gz) = 12654272
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/intel/pkg/PLIST,v
retrieving revision 1.21
diff -u -p -r1.21 PLIST
--- pkg/PLIST   16 Feb 2023 04:44:44 -  1.21
+++ pkg/PLIST   15 May 2023 03:49:51 -
@@ -94,8 +94,10 @@ firmware/intel/06-8c-01
 firmware/intel/06-8c-02
 firmware/intel/06-8d-01
 firmware/intel/06-8e-09
+@comment firmware/intel/06-8e-09_DUPLICATE
 firmware/intel/06-8e-0a
 firmware/intel/06-8e-0b
+@comment firmware/intel/06-8e-0b_DUPLICATE
 firmware/intel/06-8e-0c
 firmware/intel/06-8f-04
 firmware/intel/06-8f-05
@@ -122,6 +124,7 @@ firmware/intel/06-a7-01
 firmware/intel/06-b7-01
 firmware/intel/06-ba-02
 firmware/intel/06-ba-03
+firmware/intel/06-be-00
 firmware/intel/06-bf-02
 firmware/intel/06-bf-05
 firmware/intel/0f-00-07

double words in DESCR

[Jonathan Gray]

Index: cad/kicad-share/Makefile.inc
===
RCS file: /cvs/ports/cad/kicad-share/Makefile.inc,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile.inc
--- cad/kicad-share/Makefile.inc18 Feb 2023 07:14:52 -  1.18
+++ cad/kicad-share/Makefile.inc9 Apr 2023 08:33:04 -
@@ -7,6 +7,7 @@ PKG_ARCH ?= *
 
 V ?=   6.0.11
 EXTRACT_SUFX ?=.tar.bz2
+REVISION = 0
 
 DISTNAME=  kicad-${KICAD_PROJECT}-$V
 
Index: cad/kicad-share/packages3D/pkg/DESCR
===
RCS file: /cvs/ports/cad/kicad-share/packages3D/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- cad/kicad-share/packages3D/pkg/DESCR3 Oct 2019 07:58:04 -   
1.1.1.1
+++ cad/kicad-share/packages3D/pkg/DESCR9 Apr 2023 08:33:04 -
@@ -1,4 +1,4 @@
 The KiCad 3D model libraries are the individual .3dshapes directories.
 These 3d models are best used in combination with the official footprint libs.
-Each directory directory contains multiple 3D model files, supporting the
+Each directory contains multiple 3D model files, supporting the
 WRL and STEP file formats.
Index: chinese/libtabe/Makefile
===
RCS file: /cvs/ports/chinese/libtabe/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- chinese/libtabe/Makefile11 Mar 2022 18:25:21 -  1.29
+++ chinese/libtabe/Makefile9 Apr 2023 08:33:04 -
@@ -2,7 +2,7 @@ COMMENT=library for Chinese language pr
 
 DISTNAME=  libtabe-0.2.6
 PKGNAME=   zh-${DISTNAME}
-REVISION=  6
+REVISION=  7
 CATEGORIES=chinese
 SHARED_LIBS += tabe 2.1  # .0.0
 SHARED_LIBS += bims 2.1  # .0.0
Index: chinese/libtabe/pkg/DESCR
===
RCS file: /cvs/ports/chinese/libtabe/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- chinese/libtabe/pkg/DESCR   14 Jan 2004 05:56:23 -  1.1.1.1
+++ chinese/libtabe/pkg/DESCR   9 Apr 2023 08:33:04 -
@@ -1,5 +1,5 @@
 After its pioneering work on Chinese i18n/l10n issues, TaBE Project extends 
-extends its goal to more general Chinese language processing issues 
+its goal to more general Chinese language processing issues 
 on computer systems.
 
 libtabe, the latest work made available by the Project, is a library which
Index: databases/p5-DBIx-DBSchema/Makefile
===
RCS file: /cvs/ports/databases/p5-DBIx-DBSchema/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- databases/p5-DBIx-DBSchema/Makefile 26 Feb 2023 07:57:19 -  1.16
+++ databases/p5-DBIx-DBSchema/Makefile 9 Apr 2023 08:33:04 -
@@ -4,6 +4,7 @@ DISTNAME =  DBIx-DBSchema-0.47
 CATEGORIES=databases
 MODULES=   cpan
 PKG_ARCH=  *
+REVISION=  0
 
 # Perl
 PERMIT_PACKAGE=Yes
Index: databases/p5-DBIx-DBSchema/pkg/DESCR
===
RCS file: /cvs/ports/databases/p5-DBIx-DBSchema/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- databases/p5-DBIx-DBSchema/pkg/DESCR6 May 2006 19:36:12 -   
1.1.1.1
+++ databases/p5-DBIx-DBSchema/pkg/DESCR9 Apr 2023 08:33:04 -
@@ -2,5 +2,5 @@ This module implements an OO-interface t
 module, you can create a database schema with an OO Perl interface. You
 can read the schema from an existing database. You can save the schema
 to disk and restore it a different process. Most importantly,
-DBIx::DBSchema can write SQL CREATE statements statements for different
+DBIx::DBSchema can write SQL CREATE statements for different
 databases from a single source.
Index: devel/npth/Makefile
===
RCS file: /cvs/ports/devel/npth/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- devel/npth/Makefile 11 Mar 2022 18:50:52 -  1.11
+++ devel/npth/Makefile 9 Apr 2023 08:33:04 -
@@ -1,6 +1,7 @@
 COMMENT=   new GNU Portable Threads Library
 
 DISTNAME=  npth-1.6
+REVISION=  0
 
 SHARED_LIBS=   npth 1.0# 1.1
 
Index: devel/npth/pkg/DESCR
===
RCS file: /cvs/ports/devel/npth/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- devel/npth/pkg/DESCR17 Oct 2012 11:56:22 -  1.1.1.1
+++ devel/npth/pkg/DESCR9 Apr 2023 08:33:04 -
@@ -1,5 +1,5 @@
 nPth is a non-preemptive threads implementation using an API very similar to
 the one known from GNU Pth. It has been designed as a replacement of GNU Pth
-for non-ancient operating systems. In contrast to GNU Pth is is based on the
+for non-ancient operating systems. In contrast to GN

Re: update for vulkan to latest sdk 1.3.239.0

[Jonathan Gray]

On Sun, Feb 05, 2023 at 05:55:56PM -0500, Thomas Frohwein wrote:
> This updates all vulkan ports to the latest SDK from January. Tested it
> with and without validation layers on my Intel Tigerlake integrated GPU
> without issues, including vkcube, vkcubepp, vulkaninfo, and vkquake.
> Overall a lot fewer patches needed; I think Brad has been working hard
> to upstream some of our patches.

vulkaninfo, vkcube, and vkquake seem fine with amdgpu on amd64
GPU id : 0 (AMD Radeon Graphics (RADV RENOIR)):

diff looks good, have not looked at the upstream changes

ok jsg@

> 
> Index: glslang/Makefile
> ===
> RCS file: /cvs/ports/graphics/glslang/Makefile,v
> retrieving revision 1.14
> diff -u -p -r1.14 Makefile
> --- glslang/Makefile  13 Nov 2022 15:28:41 -  1.14
> +++ glslang/Makefile  5 Feb 2023 22:23:00 -
> @@ -2,10 +2,9 @@ PORTROACH =  limit:^[0-9]
>  
>  COMMENT =reference front-end for GLSL and ESSL
>  
> -GH_TAGNAME = 11.11.0
> +GH_TAGNAME = 12.0.0
>  GH_ACCOUNT = KhronosGroup
>  GH_PROJECT = glslang
> -REVISION =   0
>  
>  CATEGORIES = devel graphics
>  
> Index: glslang/distinfo
> ===
> RCS file: /cvs/ports/graphics/glslang/distinfo,v
> retrieving revision 1.6
> diff -u -p -r1.6 distinfo
> --- glslang/distinfo  30 Oct 2022 22:51:56 -  1.6
> +++ glslang/distinfo  5 Feb 2023 22:23:00 -
> @@ -1,2 +1,2 @@
> -SHA256 (glslang-11.11.0.tar.gz) = 
> JsIWwwYlEsAYy911IiS42tcDt+W7kL8zi6LbtdTxFDg=
> -SIZE (glslang-11.11.0.tar.gz) = 3542123
> +SHA256 (glslang-12.0.0.tar.gz) = fLRYQuwdS26nddYkw9LYupRQqkFrBIKwzH5P3TmcPXU=
> +SIZE (glslang-12.0.0.tar.gz) = 3682791
> Index: glslang/pkg/PLIST
> ===
> RCS file: /cvs/ports/graphics/glslang/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -p -r1.5 PLIST
> --- glslang/pkg/PLIST 30 Oct 2022 22:51:56 -  1.5
> +++ glslang/pkg/PLIST 5 Feb 2023 22:23:00 -
> @@ -46,9 +46,12 @@ include/glslang/MachineIndependent/prepr
>  include/glslang/MachineIndependent/propagateNoContraction.h
>  include/glslang/MachineIndependent/reflection.h
>  include/glslang/Public/
> +include/glslang/Public/ResourceLimits.h
>  include/glslang/Public/ShaderLang.h
> +include/glslang/Public/resource_limits_c.h
>  include/glslang/SPIRV/
>  include/glslang/SPIRV/GLSL.ext.AMD.h
> +include/glslang/SPIRV/GLSL.ext.ARM.h
>  include/glslang/SPIRV/GLSL.ext.EXT.h
>  include/glslang/SPIRV/GLSL.ext.KHR.h
>  include/glslang/SPIRV/GLSL.ext.NV.h
> @@ -56,6 +59,7 @@ include/glslang/SPIRV/GLSL.std.450.h
>  include/glslang/SPIRV/GlslangToSpv.h
>  include/glslang/SPIRV/Logger.h
>  include/glslang/SPIRV/NonSemanticDebugPrintf.h
> +include/glslang/SPIRV/NonSemanticShaderDebugInfo100.h
>  include/glslang/SPIRV/SPVRemapper.h
>  include/glslang/SPIRV/SpvBuilder.h
>  include/glslang/SPIRV/SpvTools.h
> @@ -72,7 +76,12 @@ lib/cmake/OGLCompilerTargets.cmake
>  lib/cmake/OSDependentTargets.cmake
>  lib/cmake/SPIRVTargets.cmake
>  lib/cmake/SPVRemapperTargets.cmake
> +lib/cmake/glslang/
>  lib/cmake/glslang-default-resource-limitsTargets.cmake
> +lib/cmake/glslang/glslang-config-version.cmake
> +lib/cmake/glslang/glslang-config.cmake
> +lib/cmake/glslang/glslang-targets${MODCMAKE_BUILD_SUFFIX}
> +lib/cmake/glslang/glslang-targets.cmake
>  lib/cmake/glslangTargets.cmake
>  lib/cmake/glslangValidatorTargets.cmake
>  lib/cmake/spirv-remapTargets.cmake
> @@ -85,8 +94,3 @@ lib/cmake/spirv-remapTargets.cmake
>  @static-lib lib/libSPVRemapper.a
>  @static-lib lib/libglslang-default-resource-limits.a
>  @static-lib lib/libglslang.a
> -share/glslang/
> -share/glslang/glslang-config-version.cmake
> -share/glslang/glslang-config.cmake
> -share/glslang/glslang-targets${MODCMAKE_BUILD_SUFFIX}
> -share/glslang/glslang-targets.cmake
> Index: spirv-headers/Makefile
> ===
> RCS file: /cvs/ports/graphics/spirv-headers/Makefile,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile
> --- spirv-headers/Makefile30 Oct 2022 22:51:56 -  1.10
> +++ spirv-headers/Makefile5 Feb 2023 22:23:00 -
> @@ -1,6 +1,6 @@
>  COMMENT =SPIRV-Headers
>  
> -V =  1.3.224.1
> +V =  1.3.239.0
>  DISTNAME =   spirv-headers-${V}
>  GH_ACCOUNT = KhronosGroup
>  GH_PROJECT = SPIRV-Headers
> Index: spirv-headers/distinfo
> ===
> RCS file: /cvs/ports/graphics/spirv-headers/distinfo,v
> retrieving revision 1.8
> diff -u -p -r1.8 distinfo
> --- spirv-headers/distinfo30 Oct 2022 22:51:56 -  1.8
> +++ spirv-headers/distinfo5 Feb 2023 22:23:00 -
> @@ -1,2 +1,2 @@
> -SHA256 (spirv-headers-1.3.224.1.tar.gz) = 
> yFcUv+YvhAByhr07PARxrwp+BqtmvCykYjBDARsoc38=
> -SIZE (spirv-headers-1.3.224.1.tar.gz) = 437010
> +SHA256 (spirv-headers-1.3.239.0.tar.gz) = 
> /a9mcOMRzRwIrpC/gT6J3TFjAgW8Y

Re: gtk+4 slow application startup

[Jonathan Gray]

On Tue, Feb 21, 2023 at 10:07:08AM +0100, Landry Breuil wrote:
> Le Tue, Feb 21, 2023 at 07:47:59PM +1100, Jonathan Gray a écrit :
> > On Tue, Feb 21, 2023 at 09:09:49AM +0100, Landry Breuil wrote:
> > > Le Tue, Feb 21, 2023 at 01:28:45PM +1100, Jonathan Gray a écrit :
> > > > On Mon, Feb 20, 2023 at 08:17:35PM +0100, Robert Nagy wrote:
> > > > > On 20/02/23 14:56 +0100, Landry Breuil wrote:
> > > > > > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit :
> > > > > > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote:
> > > > > > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote:
> > > > > > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot 
> > > > > > > > > wrote:
> > > > > > > > > > Hi.
> > > > > > > > > > 
> > > > > > > > > > There seems to be a regression with mesa that makes gtk+4 
> > > > > > > > > > application very slow
> > > > > > > > > > to start.
> > > > > > > > > > By default the GSK renderer uses OpenGL.
> > > > > > > > > > As a workaround, you can temporarily use this to go back to 
> > > > > > > > > > the cairo renderer
> > > > > > > > > > which makes gtk+4 applications fast again:
> > > > > > > > > > 
> > > > > > > > > > export GSK_RENDERER=cairo
> > > > > > > > > 
> > > > > > > > > What hardware is this on?  Is there a Mesa or gtk bug for it?
> > > > > > > > 
> > > > > > > > See dmesg below.
> > > > > > > > 
> > > > > > > > > When did this behaviour start?  Before the gtk update that 
> > > > > > > > > recently
> > > > > > > > > went in? Does it occur with GSK_RENDERER=vulkan?
> > > > > > > > > GSK_RENDERER described in
> > > > > > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer
> > > > > > > > 
> > > > > > > > It did not happen on my previous amd ryzen.
> > > > > > > > As soon as I switched to the new intel laptop, I was that bug 
> > > > > > > > (exact same
> > > > > > > > installation, I rsync'd everything).
> > > > > > > > 
> > > > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer 
> > > > > > > > is buggy (not
> > > > > > > > built by default) and segfaults on a regular basis.
> > > > > > > > 
> > > > > > > > > There is
> > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113
> > > > > > > > > which briefly touches on shader cache.  We disable the shader
> > > > > > > > > cache to be able to uses pledge(2).
> > > > > > > > 
> > > > > > > > Yes, that is the bug I was looking into.
> > > > > > > 
> > > > > > > Here is a xenocara diff to enable the shader cache.
> > > > > > > It is created in ~/.cache/mesa_shader_cache/
> > > > > > > 
> > > > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo 
> > > > > > > results in
> > > > > > > a 1.6M cache.  The time to a window appearing is noticeably 
> > > > > > > shorter
> > > > > > > running it again after that.
> > > > > > > 
> > > > > > > The various firefox and chromium ports will need to change
> > > > > > > unveil/pledge policies to use it.  Chromium at least still runs 
> > > > > > > but
> > > > > > > there are multiple warnings that directories can't be created.
> > > > > 
> > > > > This just needs an unveil of that directory in the gpu process and
> > > > > an flock pledge for chromium to use it. Seems okay to me. I think
> > > > > this should go in.
> > > > 
> > > > So chromium and firefox commits go in first, then the Mesa part a
> > > > few days later?
> > > 
> > > i&#x

Re: gtk+4 slow application startup

[Jonathan Gray]

On Tue, Feb 21, 2023 at 09:09:49AM +0100, Landry Breuil wrote:
> Le Tue, Feb 21, 2023 at 01:28:45PM +1100, Jonathan Gray a écrit :
> > On Mon, Feb 20, 2023 at 08:17:35PM +0100, Robert Nagy wrote:
> > > On 20/02/23 14:56 +0100, Landry Breuil wrote:
> > > > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit :
> > > > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote:
> > > > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote:
> > > > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote:
> > > > > > > > Hi.
> > > > > > > > 
> > > > > > > > There seems to be a regression with mesa that makes gtk+4 
> > > > > > > > application very slow
> > > > > > > > to start.
> > > > > > > > By default the GSK renderer uses OpenGL.
> > > > > > > > As a workaround, you can temporarily use this to go back to the 
> > > > > > > > cairo renderer
> > > > > > > > which makes gtk+4 applications fast again:
> > > > > > > > 
> > > > > > > > export GSK_RENDERER=cairo
> > > > > > > 
> > > > > > > What hardware is this on?  Is there a Mesa or gtk bug for it?
> > > > > > 
> > > > > > See dmesg below.
> > > > > > 
> > > > > > > When did this behaviour start?  Before the gtk update that 
> > > > > > > recently
> > > > > > > went in? Does it occur with GSK_RENDERER=vulkan?
> > > > > > > GSK_RENDERER described in
> > > > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer
> > > > > > 
> > > > > > It did not happen on my previous amd ryzen.
> > > > > > As soon as I switched to the new intel laptop, I was that bug 
> > > > > > (exact same
> > > > > > installation, I rsync'd everything).
> > > > > > 
> > > > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is 
> > > > > > buggy (not
> > > > > > built by default) and segfaults on a regular basis.
> > > > > > 
> > > > > > > There is
> > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113
> > > > > > > which briefly touches on shader cache.  We disable the shader
> > > > > > > cache to be able to uses pledge(2).
> > > > > > 
> > > > > > Yes, that is the bug I was looking into.
> > > > > 
> > > > > Here is a xenocara diff to enable the shader cache.
> > > > > It is created in ~/.cache/mesa_shader_cache/
> > > > > 
> > > > > On an Intel system (x250 with Broadwell) launching gtk4-demo results 
> > > > > in
> > > > > a 1.6M cache.  The time to a window appearing is noticeably shorter
> > > > > running it again after that.
> > > > > 
> > > > > The various firefox and chromium ports will need to change
> > > > > unveil/pledge policies to use it.  Chromium at least still runs but
> > > > > there are multiple warnings that directories can't be created.
> > > 
> > > This just needs an unveil of that directory in the gpu process and
> > > an flock pledge for chromium to use it. Seems okay to me. I think
> > > this should go in.
> > 
> > So chromium and firefox commits go in first, then the Mesa part a
> > few days later?
> 
> i'll play dumb, but which firefox commit ?
> 
> to my understanding so far, that mesa shader cache only has an impact on
> gtk+4 apps. A i wrong and if enabled it will also have an impact on
> gtk+3 apps, in which case what needs to be done ?

Web browsers use OpenGL/shaders outside of the use in gtk4.

> 
> build mesa with your diff, try to run firefox, see it crash/fail to do
> something, add random things to unveil/pledge ?

for example on firefox startup:

Failed to create /usr/users/jsg/.cache/mesa_shader_cache/cd for shader cache 
(No such file or directory)---disabling.
Failed to create /usr/users/jsg/.cache/mesa_shader_cache/79 for shader cache 
(No such file or directory)---disabling.
Failed to create /usr/users/jsg/.cache/mesa_shader_cache/bb for shader cache 
(No such file or directory)---disabling.
...

For firefox this path is also required in unveil.main ...

Re: gtk+4 slow application startup

[Jonathan Gray]

On Mon, Feb 20, 2023 at 08:17:35PM +0100, Robert Nagy wrote:
> On 20/02/23 14:56 +0100, Landry Breuil wrote:
> > Le Tue, Feb 21, 2023 at 12:00:06AM +1100, Jonathan Gray a écrit :
> > > On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote:
> > > > On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote:
> > > > > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote:
> > > > > > Hi.
> > > > > > 
> > > > > > There seems to be a regression with mesa that makes gtk+4 
> > > > > > application very slow
> > > > > > to start.
> > > > > > By default the GSK renderer uses OpenGL.
> > > > > > As a workaround, you can temporarily use this to go back to the 
> > > > > > cairo renderer
> > > > > > which makes gtk+4 applications fast again:
> > > > > > 
> > > > > > export GSK_RENDERER=cairo
> > > > > 
> > > > > What hardware is this on?  Is there a Mesa or gtk bug for it?
> > > > 
> > > > See dmesg below.
> > > > 
> > > > > When did this behaviour start?  Before the gtk update that recently
> > > > > went in? Does it occur with GSK_RENDERER=vulkan?
> > > > > GSK_RENDERER described in
> > > > > https://docs.gtk.org/gtk4/running.html#gsk_renderer
> > > > 
> > > > It did not happen on my previous amd ryzen.
> > > > As soon as I switched to the new intel laptop, I was that bug (exact 
> > > > same
> > > > installation, I rsync'd everything).
> > > > 
> > > > It does *not* appear with GSK_RENDERER=vulkan but that renderer is 
> > > > buggy (not
> > > > built by default) and segfaults on a regular basis.
> > > > 
> > > > > There is
> > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113
> > > > > which briefly touches on shader cache.  We disable the shader
> > > > > cache to be able to uses pledge(2).
> > > > 
> > > > Yes, that is the bug I was looking into.
> > > 
> > > Here is a xenocara diff to enable the shader cache.
> > > It is created in ~/.cache/mesa_shader_cache/
> > > 
> > > On an Intel system (x250 with Broadwell) launching gtk4-demo results in
> > > a 1.6M cache.  The time to a window appearing is noticeably shorter
> > > running it again after that.
> > > 
> > > The various firefox and chromium ports will need to change
> > > unveil/pledge policies to use it.  Chromium at least still runs but
> > > there are multiple warnings that directories can't be created.
> 
> This just needs an unveil of that directory in the gpu process and
> an flock pledge for chromium to use it. Seems okay to me. I think
> this should go in.

So chromium and firefox commits go in first, then the Mesa part a
few days later?

Re: gtk+4 slow application startup

[Jonathan Gray]

On Mon, Feb 20, 2023 at 11:31:23AM +0100, Antoine Jacoutot wrote:
> On Mon, Feb 20, 2023 at 02:06:34PM +1100, Jonathan Gray wrote:
> > On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote:
> > > Hi.
> > > 
> > > There seems to be a regression with mesa that makes gtk+4 application 
> > > very slow
> > > to start.
> > > By default the GSK renderer uses OpenGL.
> > > As a workaround, you can temporarily use this to go back to the cairo 
> > > renderer
> > > which makes gtk+4 applications fast again:
> > > 
> > > export GSK_RENDERER=cairo
> > 
> > What hardware is this on?  Is there a Mesa or gtk bug for it?
> 
> See dmesg below.
> 
> > When did this behaviour start?  Before the gtk update that recently
> > went in? Does it occur with GSK_RENDERER=vulkan?
> > GSK_RENDERER described in
> > https://docs.gtk.org/gtk4/running.html#gsk_renderer
> 
> It did not happen on my previous amd ryzen.
> As soon as I switched to the new intel laptop, I was that bug (exact same
> installation, I rsync'd everything).
> 
> It does *not* appear with GSK_RENDERER=vulkan but that renderer is buggy (not
> built by default) and segfaults on a regular basis.
> 
> > There is
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113
> > which briefly touches on shader cache.  We disable the shader
> > cache to be able to uses pledge(2).
> 
> Yes, that is the bug I was looking into.

Here is a xenocara diff to enable the shader cache.
It is created in ~/.cache/mesa_shader_cache/

On an Intel system (x250 with Broadwell) launching gtk4-demo results in
a 1.6M cache.  The time to a window appearing is noticeably shorter
running it again after that.

The various firefox and chromium ports will need to change
unveil/pledge policies to use it.  Chromium at least still runs but
there are multiple warnings that directories can't be created.

Index: lib/mesa/src/util/disk_cache.c
===
RCS file: /cvs/xenocara/lib/mesa/src/util/disk_cache.c,v
retrieving revision 1.13
diff -u -p -r1.13 disk_cache.c
--- lib/mesa/src/util/disk_cache.c  28 Jan 2023 08:56:53 -  1.13
+++ lib/mesa/src/util/disk_cache.c  20 Feb 2023 12:42:45 -
@@ -80,11 +80,6 @@ disk_cache_create(const char *gpu_name, 
uint8_t cache_version = CACHE_VERSION;
size_t cv_size = sizeof(cache_version);
 
-#ifdef __OpenBSD__
-   /* default to no disk shader cache to avoid pledge violations in chromium */
-  return NULL;
-#endif
-
if (!disk_cache_enabled())
   return NULL;
 

Re: gtk+4 slow application startup

[Jonathan Gray]

On Sun, Feb 19, 2023 at 01:34:41PM +0100, Antoine Jacoutot wrote:
> Hi.
> 
> There seems to be a regression with mesa that makes gtk+4 application very 
> slow
> to start.
> By default the GSK renderer uses OpenGL.
> As a workaround, you can temporarily use this to go back to the cairo renderer
> which makes gtk+4 applications fast again:
> 
> export GSK_RENDERER=cairo

What hardware is this on?  Is there a Mesa or gtk bug for it?
When did this behaviour start?  Before the gtk update that recently
went in? Does it occur with GSK_RENDERER=vulkan?
GSK_RENDERER described in
https://docs.gtk.org/gtk4/running.html#gsk_renderer

There is
https://gitlab.freedesktop.org/mesa/mesa/-/issues/5113
which briefly touches on shader cache.  We disable the shader
cache to be able to uses pledge(2).

At the moment, -current has Mesa 22.3.4.  Mesa 22.3.5 is already
available and 22.3.6 is scheduled to be released in a few days.
https://docs.mesa3d.org/release-calendar.html

Re: [update] quakespasm => 0.95.0 + SDL fix [was: Re: [update] games/vkquake => 1.20.3 (+ SDL fix)]

[Jonathan Gray]

On Sun, Oct 23, 2022 at 11:00:50AM -0400, Thomas Frohwein wrote:
> On Sun, Oct 23, 2022 at 10:45:20AM -0400, Thomas Frohwein wrote:
> 
> [...]
> 
> > Same (or at least very similar) error occurs with quakespasm... I
> > checked because vkquake is based quakespasm:
> > 
> > $ quakespasm -basedir ~/games/quake   
> > Command line: /usr/local/libexec/quakespasm -basedir /home/thfr/games/quake
> > Found SDL version 2.24.1
> > 
> > ERROR-OUT BEGIN
> > 
> > 
> > QUAKE ERROR: Your version of SDL library is incompatible with me.
> > You need a library version in the line of 2.0.0
> > 
> > CC'ing maintainer jsg@
> 
> Below a diff to update quakespasm to 0.95.0 which fixes the issue. ok?

ok jsg@

> 
> [...]
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/quakespasm/Makefile,v
> retrieving revision 1.16
> diff -u -p -r1.16 Makefile
> --- Makefile  17 May 2022 03:28:43 -  1.16
> +++ Makefile  23 Oct 2022 14:48:20 -
> @@ -1,8 +1,8 @@
>  COMMENT= SDL Quake port
>  CATEGORIES=  games
> -DISTNAME=quakespasm-0.94.4
> +DISTNAME=quakespasm-0.95.0
>  MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=quakespasm/}
> -HOMEPAGE=http://quakespasm.sourceforge.net
> +HOMEPAGE=https://quakespasm.sourceforge.net
>  
>  MAINTAINER=  Jonathan Gray 
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/quakespasm/distinfo,v
> retrieving revision 1.11
> diff -u -p -r1.11 distinfo
> --- distinfo  17 May 2022 03:28:43 -  1.11
> +++ distinfo  23 Oct 2022 14:48:20 -
> @@ -1,2 +1,2 @@
> -SHA256 (quakespasm-0.94.4.tar.gz) = 
> zHt0ZuzeUL229imGUwaIhWu4UwE5i88M3sgQ8QmUO/I=
> -SIZE (quakespasm-0.94.4.tar.gz) = 11174546
> +SHA256 (quakespasm-0.95.0.tar.gz) = 
> pjXqOyL5ILu0Tx5sfehYXbVsL11Abt9cgZJ4xkkBrnA=
> +SIZE (quakespasm-0.95.0.tar.gz) = 10787352
> 

Re: [big-endian] unbreak graphics/webp-pixbuf-loader

[Jonathan Gray]

On Wed, Sep 21, 2022 at 11:18:17PM -0400, George Koehler wrote:
> On Thu, 22 Sep 2022 12:28:56 +1000
> Jonathan Gray  wrote:
> 
> > On Wed, Sep 21, 2022 at 10:13:44PM -0400, George Koehler wrote:
> > This uses the compiler builtin __BYTE_ORDER__ instead of endian.h
> > BYTE_ORDER.
> > 
> > Both could be avoided by using htole32() instead.  Then the two
> > ifdefs could be removed as well.
> 
> My 1st patch used swap32; this 2nd patch uses le32toh and works
> equally well.  ok for either swap32 or le32toh?

change "Use  on BE_ARCHS" to "Use "

I prefer the original name of letoh32().  Though that isn't always
available on other platforms which later did things differently.

so ok jsg@ on this version

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/webp-pixbuf-loader/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile  12 Aug 2022 11:42:55 -  1.1.1.1
> +++ Makefile  22 Sep 2022 03:12:56 -
> @@ -3,6 +3,7 @@ COMMENT=  WebP GDK Pixbuf Loader library
>  GH_ACCOUNT=  aruiz
>  GH_PROJECT=  webp-pixbuf-loader
>  GH_TAGNAME=  0.0.6
> +REVISION=0
>  
>  CATEGORIES=  graphics
>  
> Index: patches/patch-io-webp_c
> ===
> RCS file: patches/patch-io-webp_c
> diff -N patches/patch-io-webp_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-io-webp_c   22 Sep 2022 03:12:56 -
> @@ -0,0 +1,27 @@
> +Use  on BE_ARCHS; OpenBSD doesn't have .
> +
> +Index: io-webp.c
> +--- io-webp.c.orig
>  io-webp.c
> +@@ -12,9 +12,7 @@
> + 
> + #include "io-webp.h"
> + 
> +-#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> +-#include 
> +-#endif
> ++#include 
> + 
> + #define  IMAGE_READ_BUFFER_SIZE 65535
> + 
> +@@ -278,9 +276,7 @@ gdk_pixbuf__webp_anim_load_increment (gpointer  co
> + /* The next 4 bytes give the size of the webp container 
> less the 8 byte header. */
> + uint32_t anim_size = *(uint32_t *) (buf + 4); /* gives file 
> size not counting the first 8 bytes. */
> + 
> +-#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> +-anim_size = bswap_32(anim_size);
> +-#endif
> ++anim_size = le32toh(anim_size);
> + 
> + uint32_t file_size = anim_size + 8;
> + if (file_size < size) {
> 
> 

Re: [big-endian] unbreak graphics/webp-pixbuf-loader

[Jonathan Gray]

On Wed, Sep 21, 2022 at 10:13:44PM -0400, George Koehler wrote:
> graphics/webp-pixbuf-loader failed in the ongoing powerpc bulk, but
> this looks easy to fix.  OpenBSD doesn't have , so use
>  (on big-endian platforms like powerpc and sparc64).  With
> this patch, "make package" works and "make test" passes on powerpc.

This uses the compiler builtin __BYTE_ORDER__ instead of endian.h
BYTE_ORDER.

Both could be avoided by using htole32() instead.  Then the two
ifdefs could be removed as well.

> 
> ok to commit?
> 
> ../webp-pixbuf-loader-0.0.6/io-webp.c:16:10: fatal error: 'byteswap.h'
> file not found
> #include 
>  ^~~~
> 1 error generated.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/webp-pixbuf-loader/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile  12 Aug 2022 11:42:55 -  1.1.1.1
> +++ Makefile  22 Sep 2022 01:57:35 -
> @@ -3,6 +3,7 @@ COMMENT=  WebP GDK Pixbuf Loader library
>  GH_ACCOUNT=  aruiz
>  GH_PROJECT=  webp-pixbuf-loader
>  GH_TAGNAME=  0.0.6
> +REVISION=0
>  
>  CATEGORIES=  graphics
>  
> Index: patches/patch-io-webp_c
> ===
> RCS file: patches/patch-io-webp_c
> diff -N patches/patch-io-webp_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-io-webp_c   22 Sep 2022 01:57:35 -
> @@ -0,0 +1,23 @@
> +Use  on BE_ARCHS; OpenBSD doesn't have .
> +
> +Index: io-webp.c
> +--- io-webp.c.orig
>  io-webp.c
> +@@ -13,7 +13,7 @@
> + #include "io-webp.h"
> + 
> + #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> +-#include 
> ++#include 
> + #endif
> + 
> + #define  IMAGE_READ_BUFFER_SIZE 65535
> +@@ -279,7 +279,7 @@ gdk_pixbuf__webp_anim_load_increment (gpointer  co
> + uint32_t anim_size = *(uint32_t *) (buf + 4); /* gives file 
> size not counting the first 8 bytes. */
> + 
> + #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> +-anim_size = bswap_32(anim_size);
> ++anim_size = swap32(anim_size);
> + #endif
> + 
> + uint32_t file_size = anim_size + 8;
> 
> 

Re: update Vulkan ports to latest sdk 1.3.224.1

[Jonathan Gray]

On Mon, Aug 29, 2022 at 10:00:54PM +1000, Jonathan Gray wrote:
> On Fri, Aug 26, 2022 at 10:03:12PM -0400, Thomas Frohwein wrote:
> > Hi,
> > 
> > Here is an update to the latest Vulkan SDK 1.3.224.1, along with
> > glslang to 11.11.0. Tested here on my Intel Tigerlake setup without
> > regressions in vulkaninfo, vkcube, and vkquake. Also tested with
> > VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation; everything looking as
> > expected.
> > 
> > Sharing this to give an opportunity to test this on other GPUs and
> > architectures, as an increasing number of applications relies on
> > Vulkan.
> > 
> > oks? Concerns?
> 
> Builds on amd64.  I'll try some other archs.

builds on arm64

Re: update Vulkan ports to latest sdk 1.3.224.1

[Jonathan Gray]

On Mon, Aug 29, 2022 at 10:00:54PM +1000, Jonathan Gray wrote:
> On Fri, Aug 26, 2022 at 10:03:12PM -0400, Thomas Frohwein wrote:
> > Hi,
> > 
> > Here is an update to the latest Vulkan SDK 1.3.224.1, along with
> > glslang to 11.11.0. Tested here on my Intel Tigerlake setup without
> > regressions in vulkaninfo, vkcube, and vkquake. Also tested with
> > VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation; everything looking as
> > expected.
> > 
> > Sharing this to give an opportunity to test this on other GPUs and
> > architectures, as an increasing number of applications relies on
> > Vulkan.
> > 
> > oks? Concerns?
> 
> Builds on amd64.  I'll try some other archs.
> 
> Running vulkaninfo on amd64 with amdgpu (renoir) I see new warnings:
> 
> WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver 
> /usr/X11R6/lib/libvulkan_intel.so supports Vulkan 1.2, but only supports 
> loader interface version 4. Interface version 5 or newer required to support 
> this version of Vulkan (Policy #LDP_DRIVER_7)
> WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver 
> /usr/X11R6/lib/libvulkan_radeon.so supports Vulkan 1.2, but only supports 
> loader interface version 4. Interface version 5 or newer required to support 
> this version of Vulkan (Policy #LDP_DRIVER_7)
> 
> Mesa 21.3.8 has
> src/amd/vulkan/radv_device.c:   *pSupportedVersion = MIN2(*pSupportedVersion, 
> 4u);
> src/intel/vulkan/anv_device.c:   *pSupportedVersion = 
> MIN2(*pSupportedVersion, 4u);
> 
> Mesa 22.1.7 has
> src/amd/vulkan/radv_device.c:   *pSupportedVersion = MIN2(*pSupportedVersion, 
> 5u);
> src/intel/vulkan/anv_device.c:   *pSupportedVersion = 
> MIN2(*pSupportedVersion, 5u);
> 
> changed in
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563

as expected, warnings go away with 22.1.7

@@ -67,12 +67,13 @@ GPU id : 0 (AMD RADV RENOIR):
supportedCompositeAlpha: count = 2
COMPOSITE_ALPHA_OPAQUE_BIT_KHR
COMPOSITE_ALPHA_INHERIT_BIT_KHR
-   supportedUsageFlags: count = 5
+   supportedUsageFlags: count = 6
IMAGE_USAGE_TRANSFER_SRC_BIT
IMAGE_USAGE_TRANSFER_DST_BIT
IMAGE_USAGE_SAMPLED_BIT
IMAGE_USAGE_STORAGE_BIT
IMAGE_USAGE_COLOR_ATTACHMENT_BIT
+   IMAGE_USAGE_INPUT_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
--
supportedSurfaceCounters:
@@ -104,13 +105,13 @@ Device Properties and Extensions:
 GPU0:
 VkPhysicalDeviceProperties:
 ---
-   apiVersion= 4202691 (1.2.195)
-   driverVersion = 88092680 (0x5403008)
+   apiVersion= 4206803 (1.3.211)
+   driverVersion = 92278791 (0x5801007)
vendorID  = 0x1002
deviceID  = 0x1636
deviceType= PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName= AMD RADV RENOIR
-   pipelineCacheUUID = 0878b1e2-1438-7210-482d-0503fc596d47
+   pipelineCacheUUID = c49e2a28-f724-e507-a5f0-33bb1d898228
 
 VkPhysicalDeviceLimits:
 ---
@@ -122,7 +123,7 @@ VkPhysicalDeviceLimits:
maxTexelBufferElements  = 4294967295
maxUniformBufferRange   = 4294967295
maxStorageBufferRange   = 4294967295
-   maxPushConstantsSize= 128
+   maxPushConstantsSize= 256
maxMemoryAllocationCount= 4294967295
maxSamplerAllocationCount   = 65536
bufferImageGranularity  = 0x0001
@@ -164,7 +165,7 @@ VkPhysicalDeviceLimits:
maxFragmentInputComponents  = 128
maxFragmentOutputAttachments= 8
maxFragmentDualSrcAttachments   = 1
-   maxFragmentCombinedOutputResources  = 8
+   maxFragmentCombinedOutputResources  = 8388606
maxComputeSharedMemorySize  = 65536
maxComputeWorkGroupCount: count = 3
65535
@@ -343,12 +344,12 @@ VkPhysicalDeviceDriverProperties:
 -
driverID= DRIVER_ID_MESA_RADV
driverName  = radv
-   driverInfo  = Mesa 21.3.8
+   driverInfo  = Mesa 22.1.7
conformanceVersion:
major= 1
minor= 2
-   subminor = 3
-   patch= 0
+   subminor = 7
+   patch= 1
 
 VkPhysicalDeviceDrmPropertiesEXT:
 

Re: update Vulkan ports to latest sdk 1.3.224.1

[Jonathan Gray]

On Fri, Aug 26, 2022 at 10:03:12PM -0400, Thomas Frohwein wrote:
> Hi,
> 
> Here is an update to the latest Vulkan SDK 1.3.224.1, along with
> glslang to 11.11.0. Tested here on my Intel Tigerlake setup without
> regressions in vulkaninfo, vkcube, and vkquake. Also tested with
> VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation; everything looking as
> expected.
> 
> Sharing this to give an opportunity to test this on other GPUs and
> architectures, as an increasing number of applications relies on
> Vulkan.
> 
> oks? Concerns?

Builds on amd64.  I'll try some other archs.

Running vulkaninfo on amd64 with amdgpu (renoir) I see new warnings:

WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver 
/usr/X11R6/lib/libvulkan_intel.so supports Vulkan 1.2, but only supports loader 
interface version 4. Interface version 5 or newer required to support this 
version of Vulkan (Policy #LDP_DRIVER_7)
WARNING: [Loader Message] Code 0 : loader_scanned_icd_add: Driver 
/usr/X11R6/lib/libvulkan_radeon.so supports Vulkan 1.2, but only supports 
loader interface version 4. Interface version 5 or newer required to support 
this version of Vulkan (Policy #LDP_DRIVER_7)

Mesa 21.3.8 has
src/amd/vulkan/radv_device.c:   *pSupportedVersion = MIN2(*pSupportedVersion, 
4u);
src/intel/vulkan/anv_device.c:   *pSupportedVersion = MIN2(*pSupportedVersion, 
4u);

Mesa 22.1.7 has
src/amd/vulkan/radv_device.c:   *pSupportedVersion = MIN2(*pSupportedVersion, 
5u);
src/intel/vulkan/anv_device.c:   *pSupportedVersion = MIN2(*pSupportedVersion, 
5u);

changed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14563

@@ -2,10 +2,10 @@
 VULKANINFO
 ==
 
-Vulkan Instance Version: 1.3.204
+Vulkan Instance Version: 1.3.224
 
 
-Instance Extensions: count = 18
+Instance Extensions: count = 19
 ===
VK_EXT_acquire_drm_display : extension revision 1
VK_EXT_acquire_xlib_display: extension revision 1
@@ -21,6 +21,7 @@ Instance Extensions: count = 18
VK_KHR_get_display_properties2 : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2   : extension revision 1
+   VK_KHR_portability_enumeration : extension revision 1
VK_KHR_surface : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_xcb_surface : extension revision 6
@@ -343,7 +344,11 @@ VkPhysicalDeviceDriverProperties:
driverID   = DRIVER_ID_MESA_RADV
driverName = radv
driverInfo = Mesa 21.3.8
-   conformanceVersion = 1.2.3.0
+   conformanceVersion:
+   major= 1
+   minor= 2
+   subminor = 3
+   patch= 0
 
 VkPhysicalDeviceDrmPropertiesEXT:
 -
@@ -594,7 +599,11 @@ VkPhysicalDeviceVulkan12Properties:
driverID = 
DRIVER_ID_MESA_RADV
driverName   = radv
driverInfo   = Mesa 21.3.8
-   conformanceVersion   = 1.2.3.0
+   conformanceVersion:
+   major= 1
+   minor= 2
+   subminor = 3
+   patch= 0
denormBehaviorIndependence   = 
SHADER_FLOAT_CONTROLS_INDEPENDENCE_32_BIT_ONLY
roundingModeIndependence = 
SHADER_FLOAT_CONTROLS_INDEPENDENCE_32_BIT_ONLY
shaderSignedZeroInfNanPreserveFloat16= true
@@ -798,23 +807,11 @@ VkQueueFamilyProperties:
VkQueueFamilyGlobalPriorityPropertiesKHR:
-
priorityCount  = 4
-   priorities: count = 16
-   128
-   256
-   512
-   1024
-   0
-   0
-   0
-   0
-   0
-   0
-   0
-   0
-   0
-   0
-   0
-   0
+   priorities: count = 4
+   QUEUE_GLOBAL_PRIORITY_LOW_KHR
+   QUEUE_GLOBAL_PRIORITY_MEDIUM_KHR
+   QUEUE_GLOBAL_PRIORITY_HIGH_KHR
+   QUEUE_GLOBAL_PRIORITY_REALTIME_KHR
 
 
queueProperties[1]:
@@ -827,23 +824,11 @@ VkQueueFamilyProperties:
VkQueueFamilyGlobalPriorityPropertiesKHR:

update intel microcode to 20220809

[Jonathan Gray]

release notes
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20220809

 Processor  | Stepping | F-M-S/PI| Products
:---|:-|:|:-
 SKX-SP | B1   | 06-55-03/97 | Xeon Scalable
 SKX-SP | H0/M0/U0 | 06-55-04/b7 | Xeon Scalable
 SKX-D  | M1   | 06-55-04/b7 | Xeon D-21xx
 ICX-SP | D0   | 06-6a-06/87 | Xeon Scalable Gen3
 GLK| B0   | 06-7a-01/01 | Pentium Silver N/J5xxx, Celeron 
N/J4xxx
 GLK-R  | R0   | 06-7a-08/01 | Pentium J5040/N5030, Celeron 
J4125/J4025/N4020/N4120
 ICL-U/Y| D1   | 06-7e-05/80 | Core Gen10 Mobile
 TGL-R  | C0   | 06-8c-02/c2 | Core Gen11 Mobile
 TGL-H  | R0   | 06-8d-01/c2 | Core Gen11 Mobile
 RKL-S  | B0   | 06-a7-01/02 | Core Gen11
 ADL| C0   | 06-97-02/03 | Core Gen12
 ADL| C0   | 06-97-05/03 | Core Gen12
 ADL| L0   | 06-9a-03/80 | Core Gen12
 ADL| L0   | 06-9a-04/80 | Core Gen12
 ADL| C0   | 06-bf-02/03 | Core Gen12
 ADL| C0   | 06-bf-05/03 | Core Gen12

tested on
cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.56 MHz, 06-9a-03

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- Makefile12 May 2022 05:53:07 -  1.31
+++ Makefile10 Aug 2022 05:37:35 -
@@ -1,7 +1,7 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20220510
+FW_VER=20220809
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
retrieving revision 1.23
diff -u -p -r1.23 distinfo
--- distinfo12 May 2022 05:53:07 -  1.23
+++ distinfo10 Aug 2022 05:37:40 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20220510.tar.gz) = 
JU3ccbWY+7jbsgDOs68prrIva/ULxgno+VPPnI0obSo=
-SIZE (firmware/intel-20220510.tar.gz) = 5912115
+SHA256 (firmware/intel-20220809.tar.gz) = 
CERjyC+8tnnn+iEeZ2/RKorkZP7X1EXpLMxnEBztWpQ=
+SIZE (firmware/intel-20220809.tar.gz) = 5929894

update intel microcode to 20220510

[Jonathan Gray]

release notes
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20220510

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile26 Apr 2022 10:36:49 -  1.30
+++ Makefile11 May 2022 02:34:32 -
@@ -1,7 +1,7 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20220419
+FW_VER=20220510
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
retrieving revision 1.22
diff -u -p -r1.22 distinfo
--- distinfo26 Apr 2022 10:36:49 -  1.22
+++ distinfo11 May 2022 02:34:38 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20220419.tar.gz) = 
uIONMA50nB3VXYhlvdSd7lFTvrXinUsOYTruR14MCIE=
-SIZE (firmware/intel-20220419.tar.gz) = 4590171
+SHA256 (firmware/intel-20220510.tar.gz) = 
JU3ccbWY+7jbsgDOs68prrIva/ULxgno+VPPnI0obSo=
+SIZE (firmware/intel-20220510.tar.gz) = 5912115
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/intel/pkg/PLIST,v
retrieving revision 1.18
diff -u -p -r1.18 PLIST
--- pkg/PLIST   7 Mar 2022 22:03:29 -   1.18
+++ pkg/PLIST   11 May 2022 02:34:45 -
@@ -97,6 +97,10 @@ firmware/intel/06-8e-0a
 firmware/intel/06-8e-0b
 firmware/intel/06-8e-0c
 firmware/intel/06-96-01
+firmware/intel/06-97-02
+firmware/intel/06-97-05
+firmware/intel/06-9a-03
+firmware/intel/06-9a-04
 firmware/intel/06-9c-00
 firmware/intel/06-9e-09
 firmware/intel/06-9e-0a
@@ -109,6 +113,8 @@ firmware/intel/06-a5-05
 firmware/intel/06-a6-00
 firmware/intel/06-a6-01
 firmware/intel/06-a7-01
+firmware/intel/06-bf-02
+firmware/intel/06-bf-05
 firmware/intel/0f-00-07
 firmware/intel/0f-00-0a
 firmware/intel/0f-01-02

update intel microcode to 20220419

[Jonathan Gray]

only change in this release is for 06-5c-0a Apollo Lake Atom x5-E39xx

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20220419
"Update for functional issues. Refer to errata APLI-11 in
 https://cdrdv2.intel.com/v1/dl/getContent/612204 for details."

that document was last updated in June 2021 and does not mention APLI-11

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile7 Mar 2022 22:03:29 -   1.29
+++ Makefile22 Apr 2022 03:10:11 -
@@ -1,7 +1,7 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20220207
+FW_VER=20220419
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
retrieving revision 1.21
diff -u -p -r1.21 distinfo
--- distinfo10 Feb 2022 22:27:32 -  1.21
+++ distinfo22 Apr 2022 03:10:30 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20220207.tar.gz) = 
UyUnvRfz6mZkRStTZpmBijv4luSs5omkOnNiRxG3ySE=
-SIZE (firmware/intel-20220207.tar.gz) = 4590237
+SHA256 (firmware/intel-20220419.tar.gz) = 
uIONMA50nB3VXYhlvdSd7lFTvrXinUsOYTruR14MCIE=
+SIZE (firmware/intel-20220419.tar.gz) = 4590171

Re: [update] afl 2.57b

[Jonathan Gray]

On Wed, Apr 13, 2022 at 07:57:29AM +0200, Theo Buehler wrote:
> Seems lcamtuf no longer maintains this and most distros now ship the
> version from Google opensource where there is still the occasional
> commit once in a while. The Makefile installs an empty README file, so I
> added a patch to install README.md instead and a sed to make sources
> point to it.
> 
> The release notes don't show anything earth-shattering. Works for me.
> https://github.com/google/AFL/releases

daniel@ proposed this without the README change a while back
not sure why that didn't go in

afl-clang/afl-fuzz still work here in a quick (incomplete) test

ok jsg@

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/afl/Makefile,v
> retrieving revision 1.50
> diff -u -p -r1.50 Makefile
> --- Makefile  11 Mar 2022 18:49:31 -  1.50
> +++ Makefile  12 Apr 2022 21:24:03 -
> @@ -1,13 +1,14 @@
>  ONLY_FOR_ARCHS= i386 amd64
>  
> +V=   2.57b
>  COMMENT= instrumented fuzzer
> -DISTNAME=afl-2.52b
> -EXTRACT_SUFX=.tgz
> +PKGNAME= afl-$V
>  CATEGORIES=  devel
> -REVISION =   0
>  
> -HOMEPAGE=http://lcamtuf.coredump.cx/afl
> -MASTER_SITES=${HOMEPAGE}/releases/
> +HOMEPAGE=https://lcamtuf.coredump.cx/afl
> +GH_ACCOUNT=  google
> +GH_PROJECT=  AFL
> +GH_TAGNAME=  v$V
>  MAINTAINER=  Jonathan Gray 
>  
>  # Apache 2.0
> @@ -17,5 +18,8 @@ USE_GMAKE=  Yes
>  FAKE_FLAGS=  PREFIX="${TRUEPREFIX}"
>  TEST_TARGET= test_build
>  WANTLIB= c
> +
> +pre-configure:
> + sed -i 's,%s/README,&.md,' ${WRKSRC}/afl-{tmin,showmap,fuzz,analyze}.c
>  
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/afl/distinfo,v
> retrieving revision 1.47
> diff -u -p -r1.47 distinfo
> --- distinfo  8 Nov 2017 00:15:21 -   1.47
> +++ distinfo  3 Apr 2022 22:38:23 -
> @@ -1,2 +1,2 @@
> -SHA256 (afl-2.52b.tgz) = Q2FLS5HAFNOe8IbFzIT/XwaAEMJkwsBb8ZnfYImM4EU=
> -SIZE (afl-2.52b.tgz) = 835907
> +SHA256 (AFL-2.57b.tar.gz) = bwWmUVwHq+Sfbykr0TyWAEzB4Ba9oMPMnCdp3UPxY+4=
> +SIZE (AFL-2.57b.tar.gz) = 839871
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/devel/afl/patches/patch-Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 patch-Makefile
> --- patches/patch-Makefile11 Mar 2022 18:49:31 -  1.24
> +++ patches/patch-Makefile3 Apr 2022 22:44:44 -
> @@ -1,5 +1,6 @@
>  Makefile.origSat Aug  6 09:12:53 2016
> -+++ Makefile Sat Aug  6 14:07:48 2016
> +Index: Makefile
> +--- Makefile.orig
>  Makefile
>  @@ -18,7 +18,7 @@ VERSION = $(shell grep '^\#define VERSION ' config
>   
>   PREFIX ?= /usr/local
> @@ -17,4 +18,13 @@
>  +all: test_x86 $(PROGS) afl-as
>   
>   ifndef AFL_NO_X86
> + 
> +@@ -133,7 +133,7 @@ endif
> + set -e; for i in afl-g++ afl-clang afl-clang++; do ln -sf afl-gcc 
> $${DESTDIR}$(BIN_PATH)/$$i; done
> + install -m 755 afl-as $${DESTDIR}$(HELPER_PATH)
> + ln -sf afl-as $${DESTDIR}$(HELPER_PATH)/as
> +-install -m 644 docs/README docs/ChangeLog docs/*.txt 
> $${DESTDIR}$(DOC_PATH)
> ++install -m 644 README.md docs/ChangeLog docs/*.txt 
> $${DESTDIR}$(DOC_PATH)
> + cp -r testcases/ $${DESTDIR}$(MISC_PATH)
> + cp -r dictionaries/ $${DESTDIR}$(MISC_PATH)
>   
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/afl/pkg/PLIST,v
> retrieving revision 1.17
> diff -u -p -r1.17 PLIST
> --- pkg/PLIST 11 Mar 2022 18:49:31 -  1.17
> +++ pkg/PLIST 12 Apr 2022 21:04:06 -
> @@ -24,6 +24,7 @@ share/afl/dictionaries/js.dict
>  share/afl/dictionaries/json.dict
>  share/afl/dictionaries/pdf.dict
>  share/afl/dictionaries/png.dict
> +share/afl/dictionaries/regexp.dict
>  share/afl/dictionaries/sql.dict
>  share/afl/dictionaries/tiff.dict
>  share/afl/dictionaries/webp.dict
> @@ -103,6 +104,11 @@ share/afl/testcases/others/pcap/
>  share/afl/testcases/others/pcap/small_capture.pcap
>  share/afl/testcases/others/pdf/
>  share/afl/testcases/others/pdf/small.pdf
> +share/afl/testcases/others/regexp/
> +share/afl/testcases/others/regexp/reg1
> +share/afl/testcases/others/regexp/reg2
> +share/afl/testcases/others/regexp/reg3
> +share/afl/testcases/others/regexp/reg4
>  share/afl/testcases/others/rtf/
>  share/afl/testcases/others/rtf/small_document.rtf
>  share/afl/testcases/others/sql/
> @@ -114,7 +120,7 @@ share/afl/testcases/others/xml/small_doc
>  share/doc/afl/
>  share/doc/afl/ChangeLog
>  share/doc/afl/QuickStartGuide.txt
> -share/doc/afl/README
> +share/doc/afl/README.md
>  share/doc/afl/env_variables.txt
>  share/doc/afl/historical_notes.txt
>  share/doc/afl/life_pro_tips.txt
> 

update amdgpu-firmware to 20220411

[Jonathan Gray]

update amdgpu firmware to 20220411
for after ports unlock

$ git log --oneline 20211027..20220411 amdgpu
688dd3f amdgpu: update green sardine VCN firmware
e0efcbc amdgpu: update renoir VCN firmware
07a7c48 amdgpu: update navi14 VCN firmware
9f949b1 amdgpu: update navi12 VCN firmware
571ff33 amdgpu: update navi10 VCN firmware
681281e amdgpu: update PSP 13.0.8 firmware
c025e59 amdgpu: update GC 10.3.7 firmware
e4fb562 amdgpu: add firmware for SDMA 5.2.7 IP block
f70c610 amdgpu: add firmware for PSP 13.0.8 IP block
eb14a98 amdgpu: add firmware for DCN 3.1.6 IP block
fd29e7b amdgpu: add firmware for GC 10.3.7 IP block
ee0667a amdgpu: update raven2 VCN firmware
efcfe18 amdgpu: update raven VCN firmware
777b8b5 amdgpu: update picasso VCN firmware
c40a2b3 amdgpu: Update yellow carp firmware from 21.50
5dadc0e amdgpu: Update vega20 firmware from 21.50
2b96e62 amdgpu: Update vega12 firmware from 21.50
3e49b41 amdgpu: Update vega10 firmware from 21.50
88b4ba0 amdgpu: Update vangogh firmware from 21.50
b2a9dc2 amdgpu: Update renoir firmware from 21.50
ba491f6 amdgpu: Update raven2 firmware from 21.50
87ee374 amdgpu: Update raven firmware from 21.50
5b2742c amdgpu: Update picasso firmware from 21.50
4c10cbe amdgpu: Update beige goby firmware from 21.50
ca1f7a4 amdgpu: Update dimgrey cavefish firmware from 21.50
400fc47 amdgpu: Update navy flounder firmware from 21.50
7b3a5b9 amdgpu: Update sienna cichlid firmware from 21.50
edeed02 amdgpu: Update navi14 firmware from 21.50
a00061d amdgpu: Update navi12 firmware from 21.50
4a597a3 amdgpu: Update navi10 firmware from 21.50
9f84af7 amdgpu: Update cyan skillfish2 firmware from 21.50
964e73f amdgpu: Update green sardine firmware from 21.50
51c41e0 amdgpu: Update arcturus firmware from 21.50
97d0c7f amdgpu: Add aldebaran firmware from 21.50
4aa2c65 amdgpu: update yellow carp dmcub firmware
26c7427 amdgpu: update green sardine PSP firmware
581f8a3 amdgpu: update yellow carp dmcub firmware
0581ebf amdgpu: update vangogh DMCUB firmware
150c19f amdgpu: update raven2 firmware from 21.40
db3f08b amdgpu: update navi14 firmware from 21.40
ea6b937 amdgpu: update raven firmware from 21.40
83125bf amdgpu: update navi12 firmware from 21.40
7c2a112 amdgpu: update navi10 firmware from 21.40
97e2e04 amdgpu: update vega20 firmware from 21.40
af4366a amdgpu: update vega12 firmware from 21.40
893e78f amdgpu: update vega10 firmware from 21.40
78ff523 amdgpu: update picasso firmware from 21.40
379f0a5 amdgpu: update vangogh firmware from 21.40
c911835 amdgpu: update beige goby firmware from 21.40
f704766 amdgpu: add cyan skillfish firmware from 21.40
1bbae78 amdgpu: update dimgrey cavefish firmware from 21.40
fbdf20e amdgpu: update green sardine firmware from 21.40
a3e107d amdgpu: update navy flounder firmware from 21.40
afb685b amdgpu: update renoir firmware from 21.40
b0d7ebd amdgpu: update arcturus firmware from 21.40
2eac483 amdgpu: update sienna cichlid firmware from 21.40
b21eb26 amdgpu: update VCN firmware for green sardine

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile7 Mar 2022 22:03:28 -   1.12
+++ Makefile12 Apr 2022 01:14:57 -
@@ -1,5 +1,5 @@
 FW_DRIVER= amdgpu
-FW_VER=20211027
+FW_VER=20220411
 DISTNAME=  linux-firmware-${FW_VER}
 EXTRACT_SUFX=  .tar.xz
 EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,\*.bin}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo28 Oct 2021 01:18:08 -  1.10
+++ distinfo12 Apr 2022 01:16:37 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/linux-firmware-20211027.tar.xz) = 
vCZX3Y64I4app+xt+czzHDLH6Qc8BdN3hsHtwnP5RAo=
-SIZE (firmware/linux-firmware-20211027.tar.xz) = 183341500
+SHA256 (firmware/linux-firmware-20220411.tar.xz) = 
AgsR9kEvSVb1pvmN59QYZ9KzDqDOgbHi0gbsmEA2OEk=
+SIZE (firmware/linux-firmware-20220411.tar.xz) = 237957584
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST
--- pkg/PLIST   7 Mar 2022 22:03:28 -   1.11
+++ pkg/PLIST   26 Mar 2022 08:53:42 -
@@ -1,4 +1,12 @@
 firmware/amdgpu/
+firmware/amdgpu/aldebaran_mec.bin
+firmware/amdgpu/aldebaran_mec2.bin
+firmware/amdgpu/aldebaran_rlc.bin
+firmware/amdgpu/aldebaran_sdma.bin
+firmware/amdgpu/aldebaran_smc.bin
+firmware/amdgpu/aldebaran_sos.bin
+firmware/amdgpu/aldebaran_ta.bin
+firmware/amdgpu/aldebaran_vcn.bin
 firmware/amdgpu/amdgpu-license
 firmware/amdgpu/arcturus_asd.bin
 firmware/amdgpu/arcturus_gpu_info.bin
@@ -45,6 +53,15 @@ firmware/amdgpu/carrizo_sdma.bin
 firmware/amdgpu/carrizo_sdma1.bin
 firmware/amdgpu/carrizo_uvd.bin
 firmware/amdgpu/carrizo_vce.bin
+firmware/

Re: sdl2-ttf build issue after Mesa update

[Jonathan Gray]

On Thu, Feb 24, 2022 at 11:45:27PM +, Stuart Henderson wrote:
> Looks like there is some issue linking sdl2-ttf with new Mesa (new ports
> bulk on i386); not sure if it will affect other ports too or if it's
> just this.
> 
> (for once ld.lld actually managed to complain about an undefined
> reference, we don't usually find these until it results in a runtime
> failure)
> 
> Anyone have ideas?
> 
> /usr/bin/libtool  --tag=CC--mode=link cc  -O2 -pipe 
> -I/usr/X11R6/include/freetype2 -I/usr/local/include/SDL2 -I/usr/X11R6/include 
> -D_REENTRANT  -I/usr/X11R6/include -DHAVE_OPENGL   -L/usr/local/lib -o glfont 
> glfont.o libSDL2_ttf.la  -L/usr/X11R6/lib -lGL -lm -L/usr/X11R6/lib 
> -lfreetype -lz -L/usr/local/lib -L/usr/X11R6/lib -lSDL2
> libtool: link: cc -o .libs/glfont -pthread -O2 -pipe 
> -I/usr/X11R6/include/freetype2 -I/usr/local/include/SDL2 -I/usr/X11R6/include 
> -D_REENTRANT -I/usr/X11R6/include -DHAVE_OPENGL glfont.o -L.libs -lSDL2_ttf 
> -lm -lfreetype -lz -lSDL2 -lsndio -lsamplerate -lX11 -lxcb -lXext -lXcursor 
> -lXrender -lXfixes -lXinerama -lXi -lXrandr -lXss -lXxf86vm -lusbhid -lGL 
> -lexpat -lX11-xcb -lxcb-glx -lXau -lXdmcp -lxcb-dri2 -lxcb-shm -ldrm 
> -lpthread -lxcb-dri3 -lxcb-xfixes -lxcb-present -lxcb-sync -lxshmfence 
> -lglapi -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib
> ld: error: .libs/libGL.so.17.1: undefined reference to 
> std::__1::basic_string, 
> std::__1::allocator >::find(char, unsigned long) const 
> [--no-allow-shlib-undefined]
> ld: error: .libs/libGL.so.17.1: undefined reference to operator new(unsigned 
> long) [--no-allow-shlib-undefined]
> ld: error: .libs/libGL.so.17.1: undefined reference to operator delete(void*) 
> [--no-allow-shlib-undefined]
> ld: error: .libs/libGL.so.17.1: undefined reference to 
> std::__1::__basic_string_common::__throw_length_error() const 
> [--no-allow-shlib-undefined] ld: error: .libs/libGL.so.17.1: undefined 
> reference to __gxx_personality_v0 [--no-allow-shlib-undefined]
> cc: error: linker command failed with exit code 1 (use -v to see 
> invocation)Error while executing cc -o .libs/glfont -pthread -O2 -pipe 
> -I/usr/X11R6/include/freetype2 -I/usr/local/include/SDL2 -I/usr/X11R6/include 
> -D_REENTRANT -I/usr/X11R6/include -DHAVE_OPENGL glfont.o -L.libs -lSDL2_ttf 
> -lm -lfreetype -lz -lSDL2 -lsndio -lsamplerate -lX11 -lxcb -lXext -lXcursor 
> -lXrender -lXfixes -lXinerama -lXi -lXrandr -lXss -lXxf86vm -lusbhid -lGL 
> -lexpat -lX11-xcb -lxcb-glx -lXau -lXdmcp -lxcb-dri2 -lxcb-shm -ldrm 
> -lpthread -lxcb-dri3 -lxcb-xfixes -lxcb-present -lxcb-sync -lxshmfence 
> -lglapi -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib
> *** Error 2 in /pobj/sdl2-ttf-2.0.15/build-i386 (Makefile:519 'glfont')

These references come from u_printf.cpp in libmesa_util.a

Follow what the meson build does and use section removal
to avoid them.

Index: lib/mesa/mk/libEGL/Makefile
===
RCS file: /cvs/xenocara/lib/mesa/mk/libEGL/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- lib/mesa/mk/libEGL/Makefile 1 Aug 2021 01:52:49 -   1.4
+++ lib/mesa/mk/libEGL/Makefile 25 Feb 2022 05:29:37 -
@@ -41,6 +41,7 @@ CPPFLAGS+=-I${MESA_SRC}/src/egl/main \
 LDADD+= -Wl,--as-needed -Wl,--allow-shlib-undefined -Wl,--start-group \
${.CURDIR}/../libmesa_util/${__objdir}/libmesa_util.a \
${.CURDIR}/../libmesa_format/${__objdir}/libmesa_format.a \
+   -Wl,--gc-sections \
-lz -lm \
-L${X11BASE}/lib -lX11-xcb -lX11 -lxcb -lxcb-xfixes
 
Index: lib/mesa/mk/libGL/Makefile
===
RCS file: /cvs/xenocara/lib/mesa/mk/libGL/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- lib/mesa/mk/libGL/Makefile  22 Jul 2021 11:10:09 -  1.3
+++ lib/mesa/mk/libGL/Makefile  25 Feb 2022 05:29:37 -
@@ -72,7 +72,8 @@ LDADD+=   -L${.CURDIR}/../libglapi/${__obj
${.CURDIR}/../libglapi_static/${__objdir}/libglapi_static.a \
${.CURDIR}/../libloader/${__objdir}/libloader.a \
${.CURDIR}/../libxmlconfig/${__objdir}/libxmlconfig.a \
-   ${.CURDIR}/../libmesa_util/${__objdir}/libmesa_util.a
+   ${.CURDIR}/../libmesa_util/${__objdir}/libmesa_util.a \
+   -Wl,--gc-sections
 
 .if ${XENOCARA_BUILD_DRI3:L} == "yes"
 LDADD+=
${.CURDIR}/../libloader_dri3_helper/${__objdir}/libloader_dri3_helper.a
Index: lib/mesa/mk/libgbm/Makefile
===
RCS file: /cvs/xenocara/lib/mesa/mk/libgbm/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- lib/mesa/mk/libgbm/Makefile 24 Feb 2022 02:29:48 -  1.4
+++ lib/mesa/mk/libgbm/Makefile 25 Feb 2022 05:29:37 -
@@ -24,6 +24,7 @@ LDADD+=   -Wl,--as-needed -Wl,--start-grou
${.CURDIR}/../libmesa_util/${__objdir}/libmesa_util.a \
${.CURDIR}/../libmesa_format/${__objdir}/libmesa_format.a \
 

Re: update intel microcode to 20220207

[Jonathan Gray]

On Thu, Feb 10, 2022 at 12:40:43PM +0100, Alexander Bluhm wrote:
> On Thu, Feb 10, 2022 at 01:31:11AM +1100, Jonathan Gray wrote:
> > release notes and list of updated platforms
> > https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20220207
> >
> > tests welcome
> 
> Running on the following machines:
> 
> with i386
> cpu0: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz ("GenuineIntel" 686-class) 
> 2.81 GHz, 06-3f-02

HSX-E/EP changed with this release, 0046 -> 0049

> cpu0: Intel(R) Xeon(R) CPU E31230 @ 3.20GHz ("GenuineIntel" 686-class) 3.21 
> GHz, 06-2a-07

SNB, no change

> cpu0: Intel(R) Xeon(TM) CPU 3.06GHz ("GenuineIntel" 686-class) 3.07 GHz, 
> 0f-02-05

32-bit only xeon, no change

> cpu0: Intel(R) Xeon(R) CPU X5690 @ 3.47GHz ("GenuineIntel" 686-class) 3.54 
> GHz, 06-2c-02

westmere, no change

> 
> with amd64
> cpu0: Intel(R) Xeon(R) E-2236 CPU @ 3.40GHz, 3392.10 MHz, 06-9e-0a

CFL-H/S/E3 changed with this release, 00ea -> 00ec

> 
> OK bluhm@

thanks

> 
> Running the nightly regress tests with it did not happen, as the
> old firmware got reinstalled during automatic upgrade.  Does the
> new fw_update not check the version number of the file?  Does it
> always overwrite with the tgz from firmware.openbsd.org?
> 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
> > retrieving revision 1.27
> > diff -u -p -r1.27 Makefile
> > --- Makefile9 Jun 2021 13:58:59 -   1.27
> > +++ Makefile9 Feb 2022 14:21:22 -
> > @@ -3,7 +3,7 @@
> >  COMMENT=   microcode update binaries for Intel CPUs
> >  FW_DRIVER= intel
> >
> > -FW_VER=20210608
> > +FW_VER=20220207
> >  EPOCH= 0
> >  GH_ACCOUNT=intel
> >  GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
> > retrieving revision 1.20
> > diff -u -p -r1.20 distinfo
> > --- distinfo9 Jun 2021 13:58:59 -   1.20
> > +++ distinfo9 Feb 2022 14:21:28 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (firmware/intel-20210608.tar.gz) = 
> > /YW2t2nv0CnexqLAcQb9GPtNy1SLe8TN4JKVqDRO9tc=
> > -SIZE (firmware/intel-20210608.tar.gz) = 4782451
> > +SHA256 (firmware/intel-20220207.tar.gz) = 
> > UyUnvRfz6mZkRStTZpmBijv4luSs5omkOnNiRxG3ySE=
> > +SIZE (firmware/intel-20220207.tar.gz) = 4590237
> > Index: pkg/PLIST
> > ===
> > RCS file: /cvs/ports/sysutils/firmware/intel/pkg/PLIST,v
> > retrieving revision 1.16
> > diff -u -p -r1.16 PLIST
> > --- pkg/PLIST   9 Jun 2021 13:58:59 -   1.16
> > +++ pkg/PLIST   9 Feb 2022 14:21:40 -
> > @@ -89,8 +89,6 @@ firmware/intel/06-6a-06
> >  firmware/intel/06-7a-01
> >  firmware/intel/06-7a-08
> >  firmware/intel/06-7e-05
> > -firmware/intel/06-86-04
> > -firmware/intel/06-86-05
> >  firmware/intel/06-8a-01
> >  firmware/intel/06-8c-01
> >  firmware/intel/06-8c-02
> 

update intel microcode to 20220207

[Jonathan Gray]

release notes and list of updated platforms
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20220207

tests welcome

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- Makefile9 Jun 2021 13:58:59 -   1.27
+++ Makefile9 Feb 2022 14:21:22 -
@@ -3,7 +3,7 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20210608
+FW_VER=20220207
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo9 Jun 2021 13:58:59 -   1.20
+++ distinfo9 Feb 2022 14:21:28 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20210608.tar.gz) = 
/YW2t2nv0CnexqLAcQb9GPtNy1SLe8TN4JKVqDRO9tc=
-SIZE (firmware/intel-20210608.tar.gz) = 4782451
+SHA256 (firmware/intel-20220207.tar.gz) = 
UyUnvRfz6mZkRStTZpmBijv4luSs5omkOnNiRxG3ySE=
+SIZE (firmware/intel-20220207.tar.gz) = 4590237
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/intel/pkg/PLIST,v
retrieving revision 1.16
diff -u -p -r1.16 PLIST
--- pkg/PLIST   9 Jun 2021 13:58:59 -   1.16
+++ pkg/PLIST   9 Feb 2022 14:21:40 -
@@ -89,8 +89,6 @@ firmware/intel/06-6a-06
 firmware/intel/06-7a-01
 firmware/intel/06-7a-08
 firmware/intel/06-7e-05
-firmware/intel/06-86-04
-firmware/intel/06-86-05
 firmware/intel/06-8a-01
 firmware/intel/06-8c-01
 firmware/intel/06-8c-02

Re: Add support for PINE H64 model B

[Jonathan Gray]

On Thu, Jan 13, 2022 at 05:02:05PM +0800, Kevin Lo wrote:
> The PINE H64 ver. B is a minor revision of the original H64.
> I copied the device tree from the Linux kernel.
> 
> dmesg: http://ix.io/3M3r
> 
> ok?

ok on the atf change

To make u-boot less of a mess the model b device tree selection
should be done with the existing h64 target not a new one.

A related patch series to yours
https://lists.denx.de/pipermail/u-boot/2021-December/469475.html
though this was not merged upstream

In case you missed it I am no longer maintainer on the u-boot port.

> 
> Index: sysutils/arm-trusted-firmware/Makefile
> ===
> RCS file: /cvs/ports/sysutils/arm-trusted-firmware/Makefile,v
> retrieving revision 1.16
> diff -u -p -u -p -r1.16 Makefile
> --- sysutils/arm-trusted-firmware/Makefile18 Jun 2021 09:17:28 -  
> 1.16
> +++ sysutils/arm-trusted-firmware/Makefile13 Jan 2022 08:54:30 -
> @@ -9,6 +9,7 @@ GH_PROJECT=   arm-trusted-firmware
>  GH_TAGNAME=  v2.5
>  
>  EPOCH=   0
> +REVISION=0
>  
>  CATEGORIES=  sysutils
>  
> @@ -32,7 +33,8 @@ CFLAGS=
>  PLATFORMS=\
>   rk3328 \
>   rk3399 \
> - sun50i_a64
> + sun50i_a64 \
> + sun50i_h6
>  
>  do-build:
>  .for P in ${PLATFORMS}
> @@ -49,5 +51,7 @@ do-install:
>   ${PREFIX}/share/arm-trusted-firmware/rk3399-bl31.elf
>   ${INSTALL_DATA} ${WRKBUILD}/build/sun50i_a64/debug/bl31.bin \
>   ${PREFIX}/share/arm-trusted-firmware/sun50i_a64-bl31.bin
> + ${INSTALL_DATA} ${WRKBUILD}/build/sun50i_h6/debug/bl31.bin \
> + ${PREFIX}/share/arm-trusted-firmware/sun50i_h6-bl31.bin
>  
>  .include 
> Index: sysutils/arm-trusted-firmware/pkg/PLIST
> ===
> RCS file: /cvs/ports/sysutils/arm-trusted-firmware/pkg/PLIST,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 PLIST
> --- sysutils/arm-trusted-firmware/pkg/PLIST   27 Sep 2019 15:43:29 -  
> 1.4
> +++ sysutils/arm-trusted-firmware/pkg/PLIST   13 Jan 2022 08:54:30 -
> @@ -4,3 +4,4 @@ share/arm-trusted-firmware/
>  share/arm-trusted-firmware/rk3328-bl31.elf
>  share/arm-trusted-firmware/rk3399-bl31.elf
>  share/arm-trusted-firmware/sun50i_a64-bl31.bin
> +share/arm-trusted-firmware/sun50i_h6-bl31.bin
> Index: sysutils/u-boot/Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
> retrieving revision 1.89
> diff -u -p -u -p -r1.89 Makefile
> --- sysutils/u-boot/Makefile  17 Dec 2021 23:00:41 -  1.89
> +++ sysutils/u-boot/Makefile  13 Jan 2022 08:54:31 -
> @@ -8,7 +8,7 @@ FLAVOR?=  arm
>  
>  COMMENT= U-Boot firmware
>  VERSION= 2021.10
> -REVISION=2
> +REVISION=3
>  DISTNAME=u-boot-${VERSION}
>  PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
>  FULLPKGNAME= ${PKGNAME}
> @@ -44,6 +44,7 @@ MAKE_ENV+=  CROSS_COMPILE="aarch64-none-e
>  RK3328_BL31= "${LOCALBASE}/share/arm-trusted-firmware/rk3328-bl31.elf"
>  RK3399_BL31= "${LOCALBASE}/share/arm-trusted-firmware/rk3399-bl31.elf"
>  SUNXI_BL31=  "${LOCALBASE}/share/arm-trusted-firmware/sun50i_a64-bl31.bin"
> +SUNXI_H6_BL31=   
> "${LOCALBASE}/share/arm-trusted-firmware/sun50i_h6-bl31.bin"
>  .elif "${FLAVOR}" == "arm"
>  BUILD_DEPENDS+=  devel/arm-none-eabi/gcc-linaro>=7.4.2019.02
>  MAKE_ENV+=   CROSS_COMPILE="arm-none-eabi-"
> @@ -69,6 +70,7 @@ SUNXI64=\
>   orangepi_zero_plus \
>   pine64-lts \
>   pine64_plus \
> + pine_h64-model-b \
>   pinebook \
>   sopine_baseboard
>  BOARDS=\
> @@ -203,6 +205,16 @@ do-build:
>  .endif
>  .endfor
>  .for BOARD in ${SUNXI64}
> +.if "${BOARD:M*_h64*}"
> + cd ${WRKSRC} && \
> + mkdir -p build/${BOARD} && \
> + ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
> + ${MAKE_FLAGS} O="build/${BOARD}" \
> + -f ${MAKE_FILE} "${BOARD}"_defconfig && \
> + ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
> + ${MAKE_FLAGS} O="build/${BOARD}" \
> + -f ${MAKE_FILE} ${ALL_TARGET}
> +.else
>   cd ${WRKSRC} && \
>   mkdir -p build/${BOARD} && \
>   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
> @@ -211,6 +223,7 @@ do-build:
>   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
>   ${MAKE_FLAGS} O="build/${BOARD}" \
>   -f ${MAKE_FILE} ${ALL_TARGET}
> +.endif
>   if [[ -f ${WRKSRC}/build/${BOARD}/spl/sunxi-spl.bin && \
> -f ${WRKSRC}/build/${BOARD}/u-boot.itb ]]; then \
>   cd ${WRKSRC}/build/${BOARD} && \
> Index: sysutils/u-boot/patches/patch-arch_arm_dts_Makefile
> ===
> RCS file: sysutils/u-boot/patches/patch-arch_arm_dts_Makefile
> diff -N sysutils/u-boot/patches/patch-arch_arm_dts_Makefile
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ sysu

Re: graphics/vulkan-loader doesn't build on aarch64

[Jonathan Gray]

On Sat, Jan 01, 2022 at 08:11:34PM +0100, Matthieu Herrb wrote:
> Hi,
> 
> graphics/vulkan-loader fails to build here on Pine Book Pro. Below is
> the log from dpb.
> 
> It's now a depency for poppler (via qt apparently) so it taks down
> XFCE packages.

builds with a backported patch
https://github.com/KhronosGroup/Vulkan-Loader/commit/a11162fcaca808eb91c0fa4fbcce99bbcd5d3be2
https://github.com/KhronosGroup/Vulkan-Loader/pull/774

--- /dev/null   Sun Jan  2 10:07:56 2022
+++ patches/patch-loader_unknown_ext_chain_gas_aarch64_SSun Jan  2 
10:06:32 2022
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+loader/aarch64: attempt to avoid text relocations in the unknown code
+a11162fcaca808eb91c0fa4fbcce99bbcd5d3be2
+
+Index: loader/unknown_ext_chain_gas_aarch64.S
+--- loader/unknown_ext_chain_gas_aarch64.S.orig
 loader/unknown_ext_chain_gas_aarch64.S
+@@ -50,7 +50,8 @@ terminError\num:
+ mov x0, x11 // Vulkan instance pointer 
(first arg)
+ mov x1, VK_DEBUG_REPORT_ERROR_BIT_EXT   // The error logging bit 
(second arg)
+ mov x2, #0  // Zero (third arg)
+-ldr x3, =termin_error_string// The error string (fourth 
arg)
++adrpx9, termin_error_string
++add x3, x9, #:lo12:termin_error_string  // The error string (fourth 
arg)
+ ldr x4, [x11, x10]  // The function name (fifth 
arg)
+ bl  loader_log  // Log the error message 
before we crash
+ mov x0, #0

Re: Adding BASE_C99 for ports needing -std=gnu99 for base-gcc

[Jonathan Gray]

On Mon, Dec 27, 2021 at 09:50:04PM -0500, Kurt Mosiejczuk wrote:
> I find myself adding the following to many ports files nowadays
> 
> .include 
> .if !${PROPERTIES:Mclang}
> CFLAGS += -std=gnu99
> .endif
> 
> Rather than continue this, I'd like to propose adding BASE_C99 to bsd.port.mk
> 
> When BASE_C99= Yes, if on a non-base-clang arch, it will add the same to
> CFLAGS, but without including bsd.port.arch.mk by hand.
> 
> Included are patches to add this to bsd.port.mk and a diff for bsd.port.mk(5)
> to include it in the man page.
> 
> Once this is in, I'll sweep the tree for the boilerplate and replace it all
> with this.
> 
> ok?

Is it time to consider changing the gcc default to gnu99?
built and installed on sparc64 but otherwise untested.

--- /tmp/defs.old   Sun Dec 19 15:25:52 2021
+++ /tmp/defs.new   Sun Dec 19 16:34:59 2021
@@ -70,6 +70,7 @@
 #define __FLT_HAS_INFINITY__ 1
 #define __DEC64_MAX__ 9.999E384DD
 #define __DEC64_MANT_DIG__ 16
+#define __STDC_VERSION__ 199901L
 #define __DEC32_MAX_EXP__ 96
 #define __DEC128_DEN__ 0.1E-6143DL
 #define __LDBL_MANT_DIG__ 113

Index: gnu/gcc/gcc/c-opts.c
===
RCS file: /cvs/src/gnu/gcc/gcc/c-opts.c,v
retrieving revision 1.3
diff -u -p -r1.3 c-opts.c
--- gnu/gcc/gcc/c-opts.c15 Sep 2011 12:19:12 -  1.3
+++ gnu/gcc/gcc/c-opts.c28 Dec 2021 03:44:20 -
@@ -236,6 +236,8 @@ c_common_init_options (unsigned int argc
 
   if (c_language == clk_c)
 {
+  set_std_c99 (false /* ISO */);
+
   /* If preprocessing assembly language, accept any of the C-family
 front end options since the driver may pass them through.  */
   for (i = 1; i < argc; i++)

Re: dnsdist segfaults since clang-13

[Jonathan Gray]

On Tue, Dec 21, 2021 at 08:25:14AM +0100, Otto Moerbeek wrote:
> Hi,
> 
> I noticed dnsdist on amd64 segfaults runtime when compiled with
> clang-13.  The most recent package snapshot has a broken dnsdist.
> 
> This does not seem to happen on arm64.
> 
> I'm investigating.
> 
>   -Otto

There was a backported fix for a runtime segfault with bind9
on FreeBSD that might be related?

https://github.com/llvm/llvm-project/commit/c446ac46746edcffab57d22c42c249a3954698c9

update to include-what-you-use 0.17

[Jonathan Gray]

requires not yet committed ports llvm 13 update

Index: Makefile
===
RCS file: /cvs/ports/devel/include-what-you-use/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile2 Nov 2021 00:00:24 -   1.24
+++ Makefile21 Dec 2021 01:32:44 -
@@ -2,9 +2,8 @@
 
 COMMENT=   tool to analyse \#includes in C and C++ source files
 CATEGORIES=devel
-DISTNAME=  include-what-you-use-0.15.src
+DISTNAME=  include-what-you-use-0.17.src
 PKGNAME=   ${DISTNAME:.src=}
-REVISION=  0
 
 HOMEPAGE=  https://include-what-you-use.org
 MASTER_SITES=  ${HOMEPAGE}/downloads/
@@ -16,7 +15,7 @@ MAINTAINER=   Jonathan Gray =${LLVM_V}
 RUN_DEPENDS=   devel/llvm>=${LLVM_V}
 
@@ -27,7 +26,6 @@ MODPY_ADJ_FILES=  *.py
 COMPILER=  base-clang ports-gcc
 COMPILER_LANGS=c++
 
-WRKDIST=   ${WRKDIR}
 DOCDIR=${PREFIX}/share/doc/include-what-you-use
 
 do-test:
Index: distinfo
===
RCS file: /cvs/ports/devel/include-what-you-use/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo13 May 2021 23:55:12 -  1.10
+++ distinfo21 Dec 2021 01:32:44 -
@@ -1,2 +1,2 @@
-SHA256 (include-what-you-use-0.15.src.tar.gz) = 
K9byrg125KlBL0aKX6Gvk9XyC7Zrnnv3NHnDHXiawuI=
-SIZE (include-what-you-use-0.15.src.tar.gz) = 603123
+SHA256 (include-what-you-use-0.17.src.tar.gz) = 
7KfAT4tBa2OF7QDjNmmn+kaTzSbLcrUizeVYgo6wxmU=
+SIZE (include-what-you-use-0.17.src.tar.gz) = 747285
Index: patches/patch-iwyu_include_picker_cc
===
RCS file: 
/cvs/ports/devel/include-what-you-use/patches/patch-iwyu_include_picker_cc,v
retrieving revision 1.7
diff -u -p -r1.7 patch-iwyu_include_picker_cc
--- patches/patch-iwyu_include_picker_cc13 May 2021 23:55:12 -  
1.7
+++ patches/patch-iwyu_include_picker_cc21 Dec 2021 01:32:44 -
@@ -3,46 +3,47 @@ $OpenBSD: patch-iwyu_include_picker_cc,v
 Index: iwyu_include_picker.cc
 --- iwyu_include_picker.cc.orig
 +++ iwyu_include_picker.cc
-@@ -115,8 +115,6 @@ const IncludeMapEntry libc_symbol_map[] = {
-   { "gid_t", kPrivate, "", kPublic },
-   { "id_t", kPrivate, "", kPublic },
-   { "id_t", kPrivate, "", kPublic },
+@@ -133,8 +133,6 @@ const IncludeMapEntry libc_symbol_map[] = {
+   { "imaxdiv_t", kPrivate, "", kPublic },
+   { "intmax_t", kPrivate, "", kPublic },
+   { "uintmax_t", kPrivate, "", kPublic },
 -  { "ino64_t", kPrivate, "", kPublic },
 -  { "ino64_t", kPrivate, "", kPublic },
{ "ino_t", kPrivate, "", kPublic },
{ "ino_t", kPrivate, "", kPublic },
{ "ino_t", kPrivate, "", kPublic },
-@@ -141,8 +139,6 @@ const IncludeMapEntry libc_symbol_map[] = {
-   { "mode_t", kPrivate, "", kPublic },
+@@ -163,8 +161,6 @@ const IncludeMapEntry libc_symbol_map[] = {
+   { "mode_t", kPrivate, "", kPublic },
{ "nlink_t", kPrivate, "", kPublic },
{ "nlink_t", kPrivate, "", kPublic },
 -  { "off64_t", kPrivate, "", kPublic },
 -  { "off64_t", kPrivate, "", kPublic },
{ "off_t", kPrivate, "", kPublic },
-   { "off_t", kPrivate, "", kPublic },
-   { "off_t", kPrivate, "", kPublic },
-@@ -157,11 +153,8 @@ const IncludeMapEntry libc_symbol_map[] = {
-   { "pid_t", kPrivate, "", kPublic },
-   { "ptrdiff_t", kPrivate, "", kPublic },
-   { "sigset_t", kPrivate, "", kPublic },
--  { "sigset_t", kPrivate, "", kPublic },
+   { "off_t", kPrivate, "", kPublic },
+   { "off_t", kPrivate, "", kPublic },
+@@ -195,13 +191,10 @@ const IncludeMapEntry libc_symbol_map[] = {
+   { "sigevent", kPrivate, "", kPublic },
+   { "siginfo_t", kPrivate, "", kPublic },
+   { "siginfo_t", kPrivate, "", kPublic },
+-  { "sigset_t", kPrivate, "", kPublic },
+-  { "sigset_t", kPrivate, "", kPublic },
{ "sigset_t", kPrivate, "", kPublic },
--  { "socklen_t", kPrivate, "", kPrivate },
--  { "socklen_t", kPrivate, "", kPublic },
--  { "socklen_t", kPrivate, "", kPublic },
-+  { "socklen_t", kPrivate, "", kPublic },
+   { "sigval", kPrivate, "", kPublic },
+   { "sockaddr", kPrivate, "", kPublic },
+   { "socklen_t", kPriva

Re: amd64 build failures 2021-12-18

[Jonathan Gray]

On Sun, Dec 19, 2021 at 03:19:15PM +0100, Christian Weisgerber wrote:
> Now that we have switched to LLVM 13, the remaining build failures
> triggered by the compiler update will show up during regular amd64
> package builds:
> 
> devel/qbs   ./qbs segfault
> lang/libv8  ./mksnapshot segfault
> misc/posixtestsuite various *.test files do not exist

Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/fork/7-1.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/mmap/27-1.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/pthread_create/1-6.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/pthread_mutex_lock/1-1.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/pthread_mutex_unlock/2-1.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/sem_timedwait/9-1.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/sem_wait/7-1.test
 does not exist
Error: 
/usr/ports/pobj/posixtestsuite-1.5.2/fake-amd64/usr/local/libexec/posixtestsuite/conformance/interfaces/sigprocmask/17-core-buildonly.test
 does not exist

build: FAILED
conformance/interfaces/fork/7-1: build: FAILED: Compiler output:
conformance/interfaces/fork/7-1.c:90:9: error: variable 'msg' set but not used 
[-Werror,-Wunused-but-set-variable]
char * msg = NULL;
^
1 error generated.
build: FAILED
conformance/interfaces/mmap/27-1: build: FAILED: Compiler output:
conformance/interfaces/mmap/27-1.c:34:9: error: variable 'data' set but not 
used [-Werror,-Wunused-but-set-variable]
char* data;
^
1 error generated.
build: FAILED
conformance/interfaces/pthread_create/1-6: build: FAILED: Compiler output:
conformance/interfaces/pthread_create/1-6.c:115:6: error: variable 'dummy' set 
but not used [-Werror,-Wunused-but-set-variable]
int dummy=0, i;
^
1 error generated.
build: FAILED
conformance/interfaces/pthread_mutex_lock/1-1: build: FAILED: Compiler output:
conformance/interfaces/pthread_mutex_lock/1-1.c:40:29: error: variable 'rc' set 
but not used [-Werror,-Wunused-but-set-variable]
int   i, rc;
^
1 error generated.
build: FAILED
conformance/interfaces/pthread_mutex_unlock/2-1: build: FAILED: Compiler output:
conformance/interfaces/pthread_mutex_unlock/2-1.c:43:29: error: variable 'rc' 
set but not used [-Werror,-Wunused-but-set-variable]
int   i, rc;
^
1 error generated.
build: FAILED
conformance/interfaces/sem_timedwait/9-1: build: FAILED: Compiler output:
conformance/interfaces/sem_timedwait/9-1.c:43:18: error: variable 'status' set 
but not used [-Werror,-Wunused-but-set-variable]
int pid, status;
^
1 error generated.
build: FAILED
conformance/interfaces/sem_wait/7-1: build: FAILED: Compiler output:
conformance/interfaces/sem_wait/7-1.c:40:18: error: variable 'status' set but 
not used [-Werror,-Wunused-but-set-variable]
int pid, status;
^
1 error generated.
build: FAILED
conformance/interfaces/sigprocmask/17-core-buildonly: build: FAILED: Compiler 
output:
conformance/interfaces/sigprocmask/17-core-buildonly.c:27:6: error: variable 
'signo' set but not used [-Werror,-Wunused-but-set-variable]
int signo;
^
1 error generated.

Re: graphics/vulkan-validation-layers (was: Re: LLVM 13 ports build failures (2021-11-27))

[Jonathan Gray]

On Thu, Dec 02, 2021 at 12:12:52AM +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Nov 28 2021, Christian Weisgerber  wrote:
> > I ran another amd64 bulk build with base clang updated to LLVM 13.
> > I also put in a tentative fix for security/nss.
> >
> > Failure logs:
> > http://build-failures.rhaalovely.net/amd64-clang/2021-11-27/
> 
> [...]
> 
> > graphics/vulkan-validation-layers   -Werror,-Wdeprecated-copy
> 
> 
> Here's a simple diff that lets this build with llvm13.  ok?

I'm ok with this or the recent upstream change

https://github.com/KhronosGroup/Vulkan-ValidationLayers/commit/b38a667579ef66b823bfe33d295ca89384d8fa0d.patch

> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/vulkan-validation-layers/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- Makefile  16 Oct 2021 14:50:41 -  1.9
> +++ Makefile  1 Dec 2021 23:11:01 -
> @@ -33,7 +33,8 @@ BUILD_DEPENDS = graphics/glslang \
>  CONFIGURE_ARGS +=-DGLSLANG_INSTALL_DIR="${LOCALBASE}" \
>   -DBUILD_WSI_WAYLAND_SUPPORT=False \
>   -DSPIRV_HEADERS_INSTALL_DIR=${LOCALBASE}/include/spirv \
> - -DUSE_ROBIN_HOOD_HASHING=False
> + -DUSE_ROBIN_HOOD_HASHING=False \
> + -DBUILD_WERROR=False
>  
>  # Tests only build if Google Test framework is in directory external/
>  NO_TEST =Yes
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 
> 

Re: [UPDATE] games/redeclipse to 2.0.0

[Jonathan Gray]

On Tue, Nov 30, 2021 at 08:24:14PM +0100, Stefan Hagen wrote:
> Tom Murphy wrote:
> > On Sat, Nov 27, 2021 at 02:33:40PM +1100, Jonathan Gray wrote:
> > > On Fri, Nov 26, 2021 at 04:17:35PM +, Tom Murphy wrote:
> > > >   I've updated games/redeclipse to 2.0.0. Compiles and runs fine here
> > > >   but it's kind of hard to figure out the "parkour" like movement in
> > > >   the game. (Looks like fun once you can coordinate your movements!)
> > > 
> > > My concern is that this will run on less hardware.
> > > https://www.redeclipse.net/docs/System-Requirements
> > > 
> > > "The next release of Red Eclipse, 2.0, is based on the Tesseract engine,
> > > which is much more GPU heavy than the outgoing Cube 2 engine."
> > > 
> > > From memory they dropped some maps as well.
> > 
> > What would you recommend? Split out the port into redeclipse1 and 
> > redeclipse2? Or use FLAVOR?
> 
> In my opinion: yes. In redeclipse and redeclipse2.
> 
> They changed the engine, the UI, the movement system. They changed all 
> maps and reduced them from 46 to 7 and wrote that they want to focus
> on the gameplay of those maps instead of providing more of them.
> 
> The distance from redeclipse to redeclipse2 is about as far as to
> xonotic.
> 
> redeclipse2 runs stable here. I rand into one segfault after an hour
> of gameplay. It runs good enough on my integrated Vega7 (RENOIR 27)
> 
> I'm for splitting. We can still have the discussion to drop the legacy 
> redeclipse in future. My feeling is that it will live on by the 
> community and by people that want to play custom maps.
> 
> just my 2 cents,
> Stefan

Each of these ports are around 1GB of files mirrors have to carry.
I'm not sure how much of a concern that is.

Re: aarch64 bulk build report

[Jonathan Gray]

On Sun, Nov 28, 2021 at 08:40:52PM -0700, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Fri Nov 26 11:53:41 MST 2021
> finished at Sun Nov 28 20:40:41 MST 2021
> lasted 2D08h47m
> done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1414: Thu Nov 25 
> 20:48:57 MST 2021
> 
> built packages:10826
> Nov 26:3718
> Nov 27:948
> Nov 28:6159
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/summary.log
> 
> build failures: 6
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/devel/mono-addins.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/graphics/babl.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/graphics/openbsd-backgrounds.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/sysutils/arm-trusted-firmware.log

ld.so: cc1: can't load library 'libisl.so.0.0'
aarch64-none-elf-gcc: internal compiler error: Killed (program cc1)

I've changed devel/arm-none-eabi/gcc-linaro to build with --without-isl

other gcc ports that do not yet have --without-isl/--with-isl

devel/avr32/gcc
devel/avr32/gcc-bootstrap
devel/msp430/gcc
devel/ti-msp430gcc
devel/xtensa-elf/gcc

Re: [UPDATE] games/quakespasm to 0.94.1 -> 0.94.2

[Jonathan Gray]

On Mon, Nov 29, 2021 at 11:59:56AM +1100, Jonathan Gray wrote:
> On Sun, Nov 28, 2021 at 03:02:01PM +1100, Jonathan Gray wrote:
> > On Sat, Nov 27, 2021 at 11:31:44AM -0700, Thomas Frohwein wrote:
> > > On Sat, Nov 27, 2021 at 01:01:13PM +, Tom Murphy wrote:
> > > > Hi,
> > > > 
> > > >   Minor version update of games/quakespasm. Compiles and runs great on
> > > >   my amd64 system. I took 'pthread' out of WANTLIB because it shows up
> > > >   as an 'Extra'.
> > > > 
> > > >   OK?
> > > > 
> > > >   Thanks,
> > > >   Tom
> > > 
> > > I've tested this; no issues. I agree that it looks like pthread isn't
> > > used (anymore?). I did a grep through the code and can only find
> > > pthread in windows and macos code.
> > > 
> > > ok thfr@ for the update
> > 
> > Thanks, I've committed this.
> > 
> > Part of the reason for the 0.94.2 release was to be compatible with
> > the latest update of the 2021 quake rerelease, vkquake has newer
> > releases available as well with the same changes.

previous diff missed Makefile

Index: Makefile
===
RCS file: /cvs/ports/games/vkquake/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile5 Sep 2021 02:35:03 -   1.7
+++ Makefile29 Nov 2021 01:07:53 -
@@ -2,7 +2,7 @@
 
 COMMENT =  port of Quake 1 using Vulkan instead of OpenGL
 
-V =1.11.0
+V =1.12.1
 PKGNAME =  vkquake-${V}
 GH_ACCOUNT =   Novum
 GH_PROJECT =   vkQuake
Index: distinfo
===
RCS file: /cvs/ports/games/vkquake/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo5 Sep 2021 02:35:03 -   1.6
+++ distinfo29 Nov 2021 01:07:53 -
@@ -1,2 +1,2 @@
-SHA256 (vkQuake-1.11.0.tar.gz) = UC6SGKxMJDwyobyvMjMO2PD/O1IGBWILJx2lISC+Yiw=
-SIZE (vkQuake-1.11.0.tar.gz) = 13369976
+SHA256 (vkQuake-1.12.1.tar.gz) = itvCfdRpYs1pFl6EVZt72oUVreOB8iundcMzRA8qLzI=
+SIZE (vkQuake-1.12.1.tar.gz) = 13430306
Index: patches/patch-Quake_Makefile
===
RCS file: /cvs/ports/games/vkquake/patches/patch-Quake_Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 patch-Quake_Makefile
--- patches/patch-Quake_Makefile5 Sep 2021 02:35:03 -   1.2
+++ patches/patch-Quake_Makefile29 Nov 2021 01:07:53 -
@@ -1,15 +1,15 @@
 $OpenBSD: patch-Quake_Makefile,v 1.2 2021/09/05 02:35:03 thfr Exp $
 
-remove hardcoded -O2
+remove hardcoded -O3
 
 Index: Quake/Makefile
 --- Quake/Makefile.orig
 +++ Quake/Makefile
-@@ -55,7 +55,6 @@ CFLAGS += -g
+@@ -56,7 +56,6 @@ CFLAGS += -g
  do_strip=
  else
  DFLAGS += -DNDEBUG
--CFLAGS += -O2
+-CFLAGS += -O3
  CFLAGS += $(call check_gcc,-fweb,)
  CFLAGS += $(call check_gcc,-frename-registers,)
  cmd_strip=$(STRIP) $(1)

Re: [UPDATE] games/quakespasm to 0.94.1 -> 0.94.2

[Jonathan Gray]

On Sun, Nov 28, 2021 at 03:02:01PM +1100, Jonathan Gray wrote:
> On Sat, Nov 27, 2021 at 11:31:44AM -0700, Thomas Frohwein wrote:
> > On Sat, Nov 27, 2021 at 01:01:13PM +, Tom Murphy wrote:
> > > Hi,
> > > 
> > >   Minor version update of games/quakespasm. Compiles and runs great on
> > >   my amd64 system. I took 'pthread' out of WANTLIB because it shows up
> > >   as an 'Extra'.
> > > 
> > >   OK?
> > > 
> > >   Thanks,
> > >   Tom
> > 
> > I've tested this; no issues. I agree that it looks like pthread isn't
> > used (anymore?). I did a grep through the code and can only find
> > pthread in windows and macos code.
> > 
> > ok thfr@ for the update
> 
> Thanks, I've committed this.
> 
> Part of the reason for the 0.94.2 release was to be compatible with
> the latest update of the 2021 quake rerelease, vkquake has newer
> releases available as well with the same changes.

Index: distinfo
===
RCS file: /cvs/ports/games/vkquake/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo5 Sep 2021 02:35:03 -   1.6
+++ distinfo29 Nov 2021 00:53:52 -
@@ -1,2 +1,2 @@
-SHA256 (vkQuake-1.11.0.tar.gz) = UC6SGKxMJDwyobyvMjMO2PD/O1IGBWILJx2lISC+Yiw=
-SIZE (vkQuake-1.11.0.tar.gz) = 13369976
+SHA256 (vkQuake-1.12.1.tar.gz) = itvCfdRpYs1pFl6EVZt72oUVreOB8iundcMzRA8qLzI=
+SIZE (vkQuake-1.12.1.tar.gz) = 13430306
Index: patches/patch-Quake_Makefile
===
RCS file: /cvs/ports/games/vkquake/patches/patch-Quake_Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 patch-Quake_Makefile
--- patches/patch-Quake_Makefile5 Sep 2021 02:35:03 -   1.2
+++ patches/patch-Quake_Makefile29 Nov 2021 00:53:52 -
@@ -1,15 +1,15 @@
 $OpenBSD: patch-Quake_Makefile,v 1.2 2021/09/05 02:35:03 thfr Exp $
 
-remove hardcoded -O2
+remove hardcoded -O3
 
 Index: Quake/Makefile
 --- Quake/Makefile.orig
 +++ Quake/Makefile
-@@ -55,7 +55,6 @@ CFLAGS += -g
+@@ -56,7 +56,6 @@ CFLAGS += -g
  do_strip=
  else
  DFLAGS += -DNDEBUG
--CFLAGS += -O2
+-CFLAGS += -O3
  CFLAGS += $(call check_gcc,-fweb,)
  CFLAGS += $(call check_gcc,-frename-registers,)
  cmd_strip=$(STRIP) $(1)

Re: devel/coccinelle build failure (ocaml, ar?)

[Jonathan Gray]

On Fri, Nov 26, 2021 at 10:09:19PM +0100, Christian Weisgerber wrote:
> devel/coccinelle failed to build in my latest amd64 bulk build:
> 
> /usr/local/bin/ocamlmklib -linkall  -o pyml-current/pyml_stubs 
> pyml-current/pyml_stubs.o pyml-current/libpyml_stubs.a
> ar: error: pyml-current/libpyml_stubs.a: No such file or directory
> 
> This suspiciously looks like a problem between ocaml and the new
> llvm-ar.

ar rcs pyml-current/libpyml_stubs.a pyml-current/pyml_stubs.o
/usr/local/bin/ocamlmklib -linkall  -o pyml-current/pyml_stubs 
pyml-current/pyml_stubs.o pyml-current/libpyml_stubs.a

fails, but this works
ar rcs pyml-current/libpyml_stubs.a pyml-current/pyml_stubs.o
mv pyml-current/libpyml_stubs.a /tmp/
/usr/local/bin/ocamlmklib -linkall  -o pyml-current/pyml_stubs 
pyml-current/pyml_stubs.o /tmp/libpyml_stubs.a

backporting part of 'Fix Makefile dependencies'
https://github.com/coccinelle/coccinelle/commit/3f93bfbb207b8e73f5f39afdf1c6f4a96038d2e4
works with llvm-ar here

--- /dev/null   Sun Nov 28 23:55:08 2021
+++ patches/patch-bundles_Makefile_bundles  Sun Nov 28 23:53:52 2021
@@ -0,0 +1,22 @@
+$OpenBSD$
+
+partial backport of 3f93bfbb207b8e73f5f39afdf1c6f4a96038d2e4
+Fix Makefile dependencies
+
+Index: bundles/Makefile.bundles
+--- bundles/Makefile.bundles.orig
 bundles/Makefile.bundles
+@@ -75,13 +75,10 @@ $(SRC_DIR)/$(ARCHIVE).cma: $(patsubst %,$(SRC_DIR)/%.c
+ $(SRC_DIR)/$(ARCHIVE).cmxa: $(patsubst %,$(SRC_DIR)/%.cmx,$(OBJS))
+   $(OCAMLOPT_CMD) -a $^ -o $@
+ 
+-$(SRC_DIR)/$(LIBRARY).a \
+-$(SRC_DIR)/dll$(LIBRARY)_stubs.so \
+ $(SRC_DIR)/lib$(LIBRARY)_stubs.a: \
+   $(patsubst %,$(SRC_DIR)/%_stubs.o,$(C_OBJS))
+   $(OCAMLMKLIB_CMD) -o $(SRC_DIR)/$(LIBRARY)_stubs $^
+ 
+-$(SRC_DIR)/$(LIBRARY).a \
+ $(SRC_DIR)/dll$(LIBRARY)_stubs.so: $(SRC_DIR)/lib$(LIBRARY)_stubs.a
+ 
+ %.ml: %.mll .prepare

Re: [UPDATE] games/quakespasm to 0.94.1 -> 0.94.2

[Jonathan Gray]

On Sat, Nov 27, 2021 at 11:31:44AM -0700, Thomas Frohwein wrote:
> On Sat, Nov 27, 2021 at 01:01:13PM +, Tom Murphy wrote:
> > Hi,
> > 
> >   Minor version update of games/quakespasm. Compiles and runs great on
> >   my amd64 system. I took 'pthread' out of WANTLIB because it shows up
> >   as an 'Extra'.
> > 
> >   OK?
> > 
> >   Thanks,
> >   Tom
> 
> I've tested this; no issues. I agree that it looks like pthread isn't
> used (anymore?). I did a grep through the code and can only find
> pthread in windows and macos code.
> 
> ok thfr@ for the update

Thanks, I've committed this.

Part of the reason for the 0.94.2 release was to be compatible with
the latest update of the 2021 quake rerelease, vkquake has newer
releases available as well with the same changes.

> > 
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/games/quakespasm/Makefile,v
> > retrieving revision 1.12
> > diff -u -p -r1.12 Makefile
> > --- Makefile6 Sep 2021 01:08:31 -   1.12
> > +++ Makefile27 Nov 2021 12:57:40 -
> > @@ -2,7 +2,7 @@
> >  
> >  COMMENT=   SDL Quake port
> >  CATEGORIES=games
> > -DISTNAME=  quakespasm-0.94.1
> > +DISTNAME=  quakespasm-0.94.2
> >  MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=quakespasm/}
> >  HOMEPAGE=  http://quakespasm.sourceforge.net
> >  
> > @@ -11,7 +11,7 @@ MAINTAINER=   Jonathan Gray  >  # GPLv2
> >  PERMIT_PACKAGE=Yes
> >  
> > -WANTLIB += GL SDL2 c m mad ogg pthread vorbis vorbisfile
> > +WANTLIB += GL SDL2 c m mad ogg vorbis vorbisfile
> >  
> >  LIB_DEPENDS=   audio/libmad \
> > audio/libvorbis \
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/games/quakespasm/distinfo,v
> > retrieving revision 1.8
> > diff -u -p -r1.8 distinfo
> > --- distinfo6 Sep 2021 01:08:31 -   1.8
> > +++ distinfo27 Nov 2021 12:57:40 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (quakespasm-0.94.1.tar.gz) = 
> > VzJZOUesLGVgorwh92bH2Speunb3AZn69XLGMfW++aU=
> > -SIZE (quakespasm-0.94.1.tar.gz) = 9900452
> > +SHA256 (quakespasm-0.94.2.tar.gz) = 
> > wIgtoJVZH14EKcVNqZdwV3a5jORptYkVMTW1UmvaHyo=
> > +SIZE (quakespasm-0.94.2.tar.gz) = 9896037
> > 
> 
> 

Re: [UPDATE] games/redeclipse to 2.0.0

[Jonathan Gray]

On Fri, Nov 26, 2021 at 04:17:35PM +, Tom Murphy wrote:
> Hi,
> 
>   I've updated games/redeclipse to 2.0.0. Compiles and runs fine here
>   but it's kind of hard to figure out the "parkour" like movement in
>   the game. (Looks like fun once you can coordinate your movements!)

My concern is that this will run on less hardware.

https://www.redeclipse.net/docs/System-Requirements

"The next release of Red Eclipse, 2.0, is based on the Tesseract engine,
which is much more GPU heavy than the outgoing Cube 2 engine."

>From memory they dropped some maps as well.

> 
>   I removed a duplicate MASTER_SITES line and switched the source to
>   github.com/redeclipse since the original red-eclipse source seems
>   to be discontinued.
> 
>   Diff gzipped to save space.
> 
>   OK?
> 
>   Thanks,
>   Tom

Re: LLVM 13 ports build failures (2021-10-27)

[Jonathan Gray]

On Thu, Oct 28, 2021 at 10:30:36AM +0200, Christian Weisgerber wrote:
> Jonathan Gray:
> 
> > > fvwm2 may be an exception here. I looked through the log and can't find
> > > any error before the linker error:
> > > 
> > > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to 
> > > pthread_mutexattr_init [--no-allow-shlib-undefined]
> > > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to 
> > > pthread_mutexattr_settype [--no-allow-shlib-undefined]
> > > ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to 
> > > pthread_mutexattr_destroy [--no-allow-shlib-undefined]
> > > 
> > > Leads me to conclude that we need to add -lpthread now to satisfy
> > > clang13. Diff for that below; CC maintainer. ok?
> > 
> > There are multiple ports which fail to build like this.
> > 
> > Shouldn't libintl instead link libpthread?
> 
> Shouldn't we try to understand why this is failing now?

I suspect changes to undefined symbol handling in lld mentioned
in the lld 13 release notes:

https://releases.llvm.org/13.0.0/tools/lld/docs/ReleaseNotes.html

Re: LLVM 13 ports build failures (2021-10-27)

[Jonathan Gray]

On Wed, Oct 27, 2021 at 07:48:52PM -0600, Thomas Frohwein wrote:
> On Thu, Oct 28, 2021 at 12:16:58AM +0200, Christian Weisgerber wrote:
> [...]
> > Failure logs:
> > http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/
> > 
> > The final error may be misleading.  For instance, devel/libdsm fails
> > with a linker error "undefined reference to pthread_create", but
> > the root cause is -Werror breaking a configure check.
> 
> fvwm2 may be an exception here. I looked through the log and can't find
> any error before the linker error:
> 
> ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to 
> pthread_mutexattr_init [--no-allow-shlib-undefined]
> ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to 
> pthread_mutexattr_settype [--no-allow-shlib-undefined]
> ld: error: /usr/local/lib/libintl.so.7.0: undefined reference to 
> pthread_mutexattr_destroy [--no-allow-shlib-undefined]
> 
> Leads me to conclude that we need to add -lpthread now to satisfy
> clang13. Diff for that below; CC maintainer. ok?

There are multiple ports which fail to build like this.

Shouldn't libintl instead link libpthread?

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/fvwm2/Makefile,v
> retrieving revision 1.71
> diff -u -p -r1.71 Makefile
> --- Makefile  19 Sep 2021 21:11:55 -  1.71
> +++ Makefile  28 Oct 2021 01:47:33 -
> @@ -3,7 +3,7 @@
>  COMMENT= multiple virtual desktop window manager
>  
>  VERSION= 2.6.9
> -REVISION=1
> +REVISION=2
>  DISTNAME=fvwm-${VERSION}
>  PKGNAME= fvwm2-${VERSION}
>  
> @@ -19,7 +19,7 @@ PERMIT_PACKAGE= Yes
>  
>  WANTLIB += ICE SM X11 Xcursor Xext Xft Xinerama Xpm Xrender
>  WANTLIB += c cairo curses fontconfig freetype gdk_pixbuf-2.0
> -WANTLIB += gio-2.0 glib-2.0 gobject-2.0 iconv intl m png
> +WANTLIB += gio-2.0 glib-2.0 gobject-2.0 iconv intl m png pthread
>  WANTLIB += readline rsvg-2 z
>  
>  MASTER_SITES=
> https://github.com/fvwmorg/fvwm/releases/download/${VERSION}/
> @@ -47,6 +47,6 @@ CONFIGURE_ARGS+=--enable-mandoc \
>   --without-rplay-library \
>   --without-stroke-library
>  CONFIGURE_ENV+=  CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include" \
> - LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
> + LDFLAGS="${LDFLAGS} -lpthread -L${LOCALBASE}/lib"
>  
>  .include 
> 
> 

deregister chinese/c2t to fix llvm 13 build

[Jonathan Gray]

deregister to fix llvm 13 build and fix a warning/ansi while here

cc -DCHINDICT=\"/usr/local/share/chinese/gb/TONEPY.tit\" -O2 -pipe -c c2t.c
c2t.c:21:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main(argc, argv)
^
c2t.c:99:3: error: address of register variable requested
  hz[2] = '\0';
  ^~
c2t.c:107:7: error: address of register variable requested
  hz[0] = (char)eka;
  ^~
c2t.c:108:7: error: address of register variable requested
  hz[1] = (char)toka;
  ^~
c2t.c:113:8: error: address of register variable requested
  if (hz[0] != (*pipo)[i] || hz[1] != (*pipo)[i+1]) continue;
  ^~
c2t.c:113:31: error: address of register variable requested
  if (hz[0] != (*pipo)[i] || hz[1] != (*pipo)[i+1]) continue;
 ^~
c2t.c:133:36: error: address of register variable requested
fprintf(miss_chars, "%c", hz[0]);
  ^~
c2t.c:134:30: error: address of register variable requested
fprintf(miss_chars, "%c ", hz[1]);
   ^~
c2t.c:143:17: error: address of register variable requested
printf("%c", hz[0]);
 ^~
c2t.c:144:18: error: address of register variable requested
printf("%c ", hz[1]);
  ^~

Index: patches/patch-02
===
RCS file: /cvs/ports/chinese/c2t/patches/patch-02,v
retrieving revision 1.2
diff -u -p -r1.2 patch-02
--- patches/patch-023 Mar 1998 05:12:49 -   1.2
+++ patches/patch-0228 Oct 2021 03:52:49 -
@@ -1,22 +1,33 @@
 c2t.c.orig Tue Feb 23 22:29:23 1993
-+++ c2t.c  Mon Mar  2 21:12:22 1998
-@@ -22,10 +22,14 @@
- int argc;
- char **argv;
+Index: c2t.c
+--- c2t.c.orig
 c2t.c
+@@ -18,15 +18,18 @@
+ 
+ #define MEMAREA 4096 /* max number of lines in DICT file, wc -l DICT */
+ 
+-main(argc, argv)
+-int argc;
+-char **argv;
++int
++main(int argc, char **argv)
  {
 +#ifndef CHINDICT
char *DICT="/home/ftp/software/unix/X-Window/cxterm-dictionary/TONEPY.tit";
+-  register int eka=0, toka=0, i=0;
+-  register char hz[4], **pipo=0;
+-  register char **taulu=0, rivi[82];
+-  register int rpit=0, tila=0, rraja=0, mulpin=0;
 +#else
 +  char *DICT=CHINDICT;
 +#endif
-   register int eka=0, toka=0, i=0;
-   register char hz[4], **pipo=0;
--  register char **taulu=0, rivi[82];
++  int eka=0, toka=0, i=0;
++  char hz[4], **pipo=0;
 +  char **taulu=0, rivi[82];
-   register int rpit=0, tila=0, rraja=0, mulpin=0;
++  int rpit=0, tila=0, rraja=0, mulpin=0;
int monitila=0;
FILE *piffi=0;
-@@ -57,12 +61,12 @@
+   FILE *miss_chars=0; 
+@@ -57,12 +60,12 @@ char **argv;
   i =0;
} /*if argc > 1 */  
if ((piffi = fopen (DICT, "r")) == 0) {
@@ -31,7 +42,7 @@
  exit (-2);
}
pipo = taulu;
-@@ -81,13 +85,13 @@
+@@ -81,13 +84,13 @@ char **argv;
  } else {
if (rivi[0] == '#') continue;
if ((*pipo = (char *)malloc (rpit+8)) == 0) {

Re: llvm13: lang/python/3.8 build failure

[Jonathan Gray]

On Wed, Oct 27, 2021 at 09:22:41PM -0400, Kurt Mosiejczuk wrote:
> On Thu, Oct 28, 2021 at 11:30:34AM +1100, Jonathan Gray wrote:
> > On Tue, Oct 26, 2021 at 06:20:47PM -0400, Kurt Mosiejczuk wrote:
> > > On Tue, Oct 26, 2021 at 10:04:42PM +0200, Christian Weisgerber wrote:
> > > > lang/python/3.8 fails to build with llvm13.  The reason appears to be
> > > > some silly confusion between "openbsd7" and "openbsd7.0" in the build
> > > > system:
> 
> > > > The trigger appears to be the new support for "cc --print-multiarch":
> 
> > > > llvm 12 says on stderr:
> > > >   cc: error: unsupported option '--print-multiarch'
> > > >   cc: error: no input files
> 
> > > > llvm 13 says on stdout:
> > > >   amd64-unknown-openbsd7.0
> 
> > > > I haven't managed to trace this any further.
> 
> > > This patch to configure.ac should neutralize the MULTIARCH stuff which
> > > isn't applicable to OpenBSD anyway. It builds properly on my laptop which 
> > > is
> > > still using LLVM 11.1. I'll try building LLVM 13 tonight and see if it
> > > works with that, but someone else is welcome to try this patch before I
> > > get to it.
> 
> > also needed for lang/python/3.9
> 
> Did the readline module compile ok for you? I did this same diff, but the
> readline module built but then I got an error because it wouldn't import
> properly.
> 
> --Kurt

the packages built but the log indeed suggests some readline problems

cc -pthread -shared -fPIC -L/usr/local/lib/ 
-L/usr/ports/pobj/Python-3.9.7/Python-3.9.7 -L/usr/local/lib/ 
-L/usr/ports/pobj/Python-3.9.7/Python-3.9.7 -L/usr/local/lib/ -O2 -pipe -g 
build/temp.openbsd-7.0-amd64-3.9/usr/ports/pobj/Python-3.9.7/Python-3.9.7/Modules/_ctypes/_ctypes.o
 
build/temp.openbsd-7.0-amd64-3.9/usr/ports/pobj/Python-3.9.7/Python-3.9.7/Modules/_ctypes/callbacks.o
 
build/temp.openbsd-7.0-amd64-3.9/usr/ports/pobj/Python-3.9.7/Python-3.9.7/Modules/_ctypes/callproc.o
 
build/temp.openbsd-7.0-amd64-3.9/usr/ports/pobj/Python-3.9.7/Python-3.9.7/Modules/_ctypes/cfield.o
 
build/temp.openbsd-7.0-amd64-3.9/usr/ports/pobj/Python-3.9.7/Python-3.9.7/Modules/_ctypes/stgdict.o
 -L. -L/usr/ports/pobj/Python-3.9.7/Python-3.9.7 -L/usr/local/lib/ 
-L/usr/local/lib -lffi -o build/lib.openbsd-7.0-amd64-3.9/_ctypes.cpython-39.so
*** WARNING: renaming "readline" since importing it failed: dynamic module does 
not define module export function (PyInit_readline)

Re: llvm13: lang/python/3.8 build failure

[Jonathan Gray]

On Tue, Oct 26, 2021 at 06:20:47PM -0400, Kurt Mosiejczuk wrote:
> On Tue, Oct 26, 2021 at 10:04:42PM +0200, Christian Weisgerber wrote:
> > lang/python/3.8 fails to build with llvm13.  The reason appears to be
> > some silly confusion between "openbsd7" and "openbsd7.0" in the build
> > system:
> 
> > The trigger appears to be the new support for "cc --print-multiarch":
> 
> > llvm 12 says on stderr:
> >   cc: error: unsupported option '--print-multiarch'
> >   cc: error: no input files
> 
> > llvm 13 says on stdout:
> >   amd64-unknown-openbsd7.0
> 
> > I haven't managed to trace this any further.
> 
> This patch to configure.ac should neutralize the MULTIARCH stuff which
> isn't applicable to OpenBSD anyway. It builds properly on my laptop which is
> still using LLVM 11.1. I'll try building LLVM 13 tonight and see if it
> works with that, but someone else is welcome to try this patch before I
> get to it.
> 
> --Kurt

also needed for lang/python/3.9

Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.9/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile1 Sep 2021 17:41:48 -   1.9
+++ Makefile28 Oct 2021 00:23:53 -
@@ -11,6 +11,7 @@ SHARED_LIBS = python3.9 0.0
 VERSION_SPEC = >=3.9,<3.10
 #PSUBDIR = python/3.9.0
 
+REVISION-main =0
 
 CONFIGURE_ARGS +=  --with-ensurepip=no
 CONFIGURE_ARGS +=  --enable-loadable-sqlite-extensions
Index: files/CHANGES.OpenBSD
===
RCS file: /cvs/ports/lang/python/3.9/files/CHANGES.OpenBSD,v
retrieving revision 1.4
diff -u -p -r1.4 CHANGES.OpenBSD
--- files/CHANGES.OpenBSD   12 Jun 2021 04:00:22 -  1.4
+++ files/CHANGES.OpenBSD   28 Oct 2021 00:23:53 -
@@ -11,5 +11,8 @@ ports infrastructure, configure.ac was p
 3.  Disable libuuid, otherwise Python prefers it over the libc uuid
 functions.
 
+4.  Disable MULTIARCH check in configure.ac since OpenBSD is not a
+multi-arch platform and it causes build problems.
+
 These changes are available in the OpenBSD CVS repository
  in ports/lang/python/3.9.
Index: patches/patch-configure_ac
===
RCS file: /cvs/ports/lang/python/3.9/patches/patch-configure_ac,v
retrieving revision 1.4
diff -u -p -r1.4 patch-configure_ac
--- patches/patch-configure_ac  1 Sep 2021 17:41:48 -   1.4
+++ patches/patch-configure_ac  28 Oct 2021 00:23:53 -
@@ -2,6 +2,7 @@ $OpenBSD: patch-configure_ac,v 1.4 2021/
 
 #1: Set ports library version
 #2: Don't pick up an installed linux/e2fsprogs libuuid.so
+#3: OpenBSD isn't multi-arch
 
 Index: configure.ac
 --- configure.ac.orig
@@ -15,6 +16,26 @@ Index: configure.ac
  
  # The later defininition of _XOPEN_SOURCE disables certain features
  # on Linux, so we need _GNU_SOURCE to re-enable them (makedev, tm_zone).
+@@ -727,7 +727,7 @@ then
+ fi
+ 
+ 
+-MULTIARCH=$($CC --print-multiarch 2>/dev/null)
++MULTIARCH=$(false)
+ AC_SUBST(MULTIARCH)
+ 
+ AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
+@@ -743,8 +743,8 @@ cat >> conftest.c <

Re: sysutils/u-boot fix warm reset on Pinebook Pro

[Jonathan Gray]

On Fri, Sep 03, 2021 at 10:09:02AM -0700, Tomasz Bielecki wrote:
> Please consider including this patch, it seems common across other
> OSes supporting Pinebook Pro and fixes the display issues on warm
> reset.
> 
> $OpenBSD$
> 
> Fix Pinebook Pro display on warm reset.
> 
> By Arnaud Patard
> http://people.hupstream.com/~rtp/pbp/20200706/patches/hack-reset.patch

I don't think we should have a patch labelled "HACK NOTFORMERGE".

Talk to the people working on rk3399 video support upstream.  Perhaps
they have something better already merged or sent to the U-Boot list.

> 
> Index: board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> --- board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c.orig
> +++ board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> @@ -7,9 +7,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -59,6 +62,7 @@ int misc_init_r(void)
>   const u32 cpuid_length = 0x10;
>   u8 cpuid[cpuid_length];
>   int ret;
> + unsigned int gpio;
> 
>   setup_iodomain();
> 
> @@ -69,6 +73,11 @@ int misc_init_r(void)
>   ret = rockchip_cpuid_set(cpuid, cpuid_length);
>   if (ret)
>   return ret;
> +
> + gpio_lookup_name("B22", NULL, NULL, &gpio);
> + gpio_direction_output(gpio, 0);
> + udelay(50);
> + gpio_direction_output(gpio, 1);
> 
>   return ret;
>  }
> 
> 

Re: UPDATE: dtc 1.6.1

[Jonathan Gray]

On Sat, Aug 28, 2021 at 01:05:38AM -0400, Brad Smith wrote:
> Here is an update to dtc 1.6.1.

$ show-reverse-deps devel/dtc
emulators/qemu
emulators/qemu,-main
emulators/spike
sysutils/dtb
sysutils/u-boot
sysutils/u-boot,aarch64
sysutils/u-boot,arm
sysutils/u-boot,riscv64

these still package on amd64 with dtc 1.6.1 other flavors not tried
emulators/qemu
emulators/spike
sysutils/dtb
sysutils/u-boot,aarch64

> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/devel/dtc/Makefile,v
> retrieving revision 1.18
> diff -u -p -u -p -r1.18 Makefile
> --- Makefile  30 Jan 2021 13:07:20 -  1.18
> +++ Makefile  28 Aug 2021 04:41:18 -
> @@ -2,7 +2,7 @@
>  
>  COMMENT= Device Tree Compiler
>  
> -DISTNAME=dtc-1.6.0
> +DISTNAME=dtc-1.6.1
>  CATEGORIES=  sysutils devel
>  MASTER_SITES=https://www.kernel.org/pub/software/utils/dtc/
>  EXTRACT_SUFX=.tar.xz
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/devel/dtc/distinfo,v
> retrieving revision 1.8
> diff -u -p -u -p -r1.8 distinfo
> --- distinfo  30 Jan 2021 13:07:20 -  1.8
> +++ distinfo  28 Aug 2021 04:41:22 -
> @@ -1,2 +1,2 @@
> -SHA256 (dtc-1.6.0.tar.xz) = EFA7AhfhsHkz4p6NNHoAAVskMb6l9Zr+C+068wNAyC0=
> -SIZE (dtc-1.6.0.tar.xz) = 158584
> +SHA256 (dtc-1.6.1.tar.xz) = Zc7FKYk2WaSaiXQLs2L1B6O5T8jNeR52qNaitvMgNHM=
> +SIZE (dtc-1.6.1.tar.xz) = 162276
> Index: patches/patch-Makefile
> ===
> RCS file: /home/cvs/ports/devel/dtc/patches/patch-Makefile,v
> retrieving revision 1.9
> diff -u -p -u -p -r1.9 patch-Makefile
> --- patches/patch-Makefile30 Jan 2021 13:07:21 -  1.9
> +++ patches/patch-Makefile28 Aug 2021 04:43:31 -
> @@ -16,7 +16,7 @@ Index: Makefile
>   
>   BISON = bison
>   LEX = flex
> -@@ -72,7 +72,7 @@ SHAREDLIB_LDFLAGS = -shared -Wl,--version-script=$(LIB
> +@@ -73,7 +73,7 @@ SHAREDLIB_LDFLAGS = -shared -Wl,--version-script=$(LIB
>   else
>   SHAREDLIB_EXT = so
>   SHAREDLIB_CFLAGS  = -fPIC
> @@ -25,7 +25,7 @@ Index: Makefile
>   endif
>   
>   #
> -@@ -157,7 +157,7 @@ all: $(BIN) libfdt
> +@@ -158,7 +158,7 @@ all: $(BIN) libfdt
>   check_python_deps = \
>   if $(PKG_CONFIG) --cflags $(PYTHON) >/dev/null 2>&1; then \
>   if which swig >/dev/null 2>&1; then \
> @@ -34,7 +34,7 @@ Index: Makefile
>   fi; \
>   fi; \
>   if [ "$${can_build}" = "yes" ]; then \
> -@@ -204,9 +204,8 @@ $(LIBFDT_archive): $(addprefix $(LIBFDT_dir)/,$(LIBFDT
> +@@ -207,9 +207,8 @@ $(LIBFDT_archive): $(addprefix $(LIBFDT_dir)/,$(LIBFDT
>   
>   $(LIBFDT_lib): $(addprefix $(LIBFDT_dir)/,$(LIBFDT_OBJS)) $(LIBFDT_version)
>   @$(VECHO) LD $@
> @@ -45,7 +45,7 @@ Index: Makefile
>   
>   ifneq ($(DEPTARGETS),)
>   -include $(LIBFDT_OBJS:%.o=$(LIBFDT_dir)/%.d)
> -@@ -227,8 +226,6 @@ install-lib: all
> +@@ -230,8 +229,6 @@ install-lib: all
>   @$(VECHO) INSTALL-LIB
>   $(INSTALL) -d $(DESTDIR)$(LIBDIR)
>   $(INSTALL_LIB) $(LIBFDT_lib) $(DESTDIR)$(LIBDIR)
> Index: patches/patch-util_h
> ===
> RCS file: patches/patch-util_h
> diff -N patches/patch-util_h
> --- patches/patch-util_h  6 Feb 2021 10:04:28 -   1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,21 +0,0 @@
> -$OpenBSD: patch-util_h,v 1.1 2021/02/06 10:04:28 jsg Exp $
> -
> -gnu_printf requires gcc >= 4.4.0
> -
> -Index: util.h
>  util.h.orig
> -+++ util.h
> -@@ -12,10 +12,10 @@
> -  */
> - 
> - #ifdef __GNUC__
> --#ifdef __clang__
> --#define PRINTF(i, j)__attribute__((format (printf, i, j)))
> --#else
> -+#if __GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4)
> - #define PRINTF(i, j)__attribute__((format (gnu_printf, i, j)))
> -+#else
> -+#define PRINTF(i, j)__attribute__((format (printf, i, j)))
> - #endif
> - #define NORETURN__attribute__((noreturn))
> - #else
> 
> 

update amdgpu-firmware to 20210818

[Jonathan Gray]

update amdgpu-firmware to linux-firmware 20210818

"Newer firmware seems to cause random stability issues that
are hard to reproduce reliably to root cause.  Revert
back to the older SDMA firmware until the issue is fixed."

$ git log --oneline 20210716..20210818 amdgpu
d843e52 amdgpu: revert back to older raven2 sdma firmware
99d7250 amdgpu: revert back to older raven sdma firmware
d7b50e6 amdgpu: revert back to older picasso sdma firmware
243bc09 amdgpu: add initial vangogh support
1a14ded amdgpu: update vega20 firmware from 21.30
61f0e52 amdgpu: update vega12 firmware from 21.30
7a2b4d8 amdgpu: update vega10 firmware from 21.30
a187709 amdgpu: update renoir firmware from 21.30
b5f611f amdgpu: update raven2 firmware from 21.30
bbdfd34 amdgpu: update raven firmware from 21.30
8b09c77 amdgpu: update polaris12 firmware from 21.30
fbb372e amdgpu: update picasso firmware from 21.30
39f2a1e amdgpu: update dimgrey cavefish firmware from 21.30
bfbdd73 amdgpu: update navy flounder firmware from 21.30
6b8436a amdgpu: update sienna cichlid firmware from 21.30
922b548 amdgpu: update navi14 firmware from 21.30
f654bd7 amdgpu: update navi12 firmware from 21.30
3252b10 amdgpu: update navi10 firmware from 21.30
8f14593 amdgpu: update green sardine firmware from 21.30
e087519 amdgpu: update arcturus firmware from 21.30

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile28 Jul 2021 02:54:39 -  1.9
+++ Makefile18 Aug 2021 12:21:28 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.9 2021/07/28 02:54:39 jsg Exp $
 
 FW_DRIVER= amdgpu
-FW_VER=20210716
+FW_VER=20210818
 DISTNAME=  linux-firmware-${FW_VER}
 EXTRACT_SUFX=  .tar.xz
 EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,\*.bin}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo28 Jul 2021 02:54:39 -  1.8
+++ distinfo18 Aug 2021 12:22:04 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/linux-firmware-20210716.tar.xz) = 
JYCrrY/PL8kwN8ozjWHWc3qJlwYHaW1+3x4X4Rsg51M=
-SIZE (firmware/linux-firmware-20210716.tar.xz) = 171482168
+SHA256 (firmware/linux-firmware-20210818.tar.xz) = 
vvPTF8NI2WKzoblctOGepPKC4YESssZpz/dPkmfOOJM=
+SIZE (firmware/linux-firmware-20210818.tar.xz) = 172748332
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -r1.8 PLIST
--- pkg/PLIST   28 Jul 2021 02:54:39 -  1.8
+++ pkg/PLIST   18 Aug 2021 12:22:33 -
@@ -355,6 +355,17 @@ firmware/amdgpu/topaz_rlc.bin
 firmware/amdgpu/topaz_sdma.bin
 firmware/amdgpu/topaz_sdma1.bin
 firmware/amdgpu/topaz_smc.bin
+firmware/amdgpu/vangogh_asd.bin
+firmware/amdgpu/vangogh_ce.bin
+firmware/amdgpu/vangogh_dmcub.bin
+firmware/amdgpu/vangogh_me.bin
+firmware/amdgpu/vangogh_mec.bin
+firmware/amdgpu/vangogh_mec2.bin
+firmware/amdgpu/vangogh_pfp.bin
+firmware/amdgpu/vangogh_rlc.bin
+firmware/amdgpu/vangogh_sdma.bin
+firmware/amdgpu/vangogh_toc.bin
+firmware/amdgpu/vangogh_vcn.bin
 firmware/amdgpu/vega10_acg_smc.bin
 firmware/amdgpu/vega10_asd.bin
 firmware/amdgpu/vega10_ce.bin

Re: simple patch to u-boot port

[Jonathan Gray]

On Tue, Aug 03, 2021 at 10:00:35AM +1000, Colin Tree wrote:
> Hi,
> 
> I have a minor change to the u-boot port
> 
> to enable support for FriendlyElec NanoPC - T4
> 
> to reflect Supported Devices in arm64/INSTALL.arm64.

A mention in INSTALL does not mean firmware is also provided in ports.

> 
> it only changes Makefile and pkg/PFRAG.aarch64.
> 
> 
> Go well,
> 
> Colin

As this is the same patch you sent me off list a few months ago the same
comments apply.

Have you tried this via serial? I would expect a patch to
configs/nanopc-t4-rk3399_defconfig for

-CONFIG_BAUDRATE=150
+CONFIG_BAUDRATE=115200

for U-Boot to show at the same rate as ATF/OpenBSD.

The dts change appears to be covered by the existing
patch-arch_arm_dts_rk3399-nanopi4_dtsi
rk3399-nanopc-t4.dts includes rk3399-nanopi4.dtsi

> --- Makefile.orig 2021-07-08 03:18:39.0 +1000
> +++ Makefile  2021-08-03 09:38:32.075115125 +1000
> @@ -4,7 +4,7 @@
>  BROKEN-arm=  lib/time.c:187:1: internal compiler error: Bus error
>  
>  FLAVORS= aarch64 arm riscv64
> -FLAVOR?= arm
> +FLAVOR?= aarch64

The default flavor should not be changed here. Set FLAVOR
in your environment to build the aarch64 flavor.

>  
>  COMMENT= U-Boot firmware
>  VERSION= 2021.07

REVISION=   0

is needed as this changes the package

> @@ -75,6 +75,7 @@
>   firefly-rk3399 \
>   mvebu_espressobin-88f3720 \
>   mvebu_mcbin-88f8040 \
> +nanopc-t4-rk3399 \

whitespace is wrong here

>   nanopi-neo4-rk3399 \
>   pinebook-pro-rk3399 \
>   qemu_arm64 \

Re: sparc64 bulk build report

[Jonathan Gray]

On Sat, Jul 31, 2021 at 01:03:08AM +, Charlene Wendling wrote:
> On Fri, 30 Jul 2021 23:43:07 +0200
> Matthias Kilian  wrote:
> 
> > On Fri, Jul 30, 2021 at 11:36:47PM +0200, Matthias Kilian wrote:
> > > FWIW, I've poppler-21.07.0 in my tree, an update to 21.08.0 will
> > > probably available in two days. I can disable poppler-qt{5,6} for
> > > sparc64.
> > > 
> > > > Note that the NOT_FOR_ARCHS-arm for qt5 looks suspect.
> > > 
> > > Well, this entry is more than 5 years old. Should I remove it (there
> > > seems to be a qt5 package available for arm)?
> > > 
> > > > This builds on qt6, really ?
> > > 
> > > I don't see a qt6 package for arm on the mirrors.
> > 
> > Maybe something like this?
> 
> Not yet, in my humble opinion.
> 
> In fact, mips64 has the same issue, and probably other ld.bfd archs.
> powerpc is not impacted but since bulks are so slow i have not hit
> that yet (the bulk snapshot is from July 16).
> 
> One major change occurred , Mesa has been updated by July 22:
> 
> http://marc.info/?l=openbsd-cvs&m=162694920304776
> 
> Qt5 and Qt6 have started to be broken after the July 23 bulk on
> sparc64, July 27 for mips64.
> 
> Taken from the mips64 bulk:
> 
> > clang++ -Wl,-rpath,/usr/X11R6/lib -o egl main.o   -L/usr/X11R6/lib -lEGL 
> > -L/usr/local/lib  
> > -L/pobj/qtbase-5.15.2/qtbase-everywhere-src-5.15.2/build-octeon/config.tests/egl
> >  
> > /usr/X11R6/lib/libX11.so.17.1: warning: sprintf() is often misused, please 
> > use snprintf()
> > /usr/X11R6/lib/libX11.so.17.1: warning: strcat() is almost always misused, 
> > please use strlcat()
> > /usr/X11R6/lib/libX11.so.17.1: warning: strcpy() is almost always misused, 
> > please use strlcpy()
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to `_mesa_sha1_compute'
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to `_mesa_sha1_format'
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to `util_get_process_name'
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to 
> > `ralloc_asprintf_append'
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to `ralloc_free'
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to `ralloc_strdup'
> > /usr/X11R6/lib/libEGL.so.1.1: undefined reference to 
> > `util_get_process_exec_path'
> > clang++: error: linker command failed with exit code 1 (use -v to see 
> > invocation)
> 
> Since that test fails, all the EGL stuff is not built.

Does a libEGL built with the following help?
Follows how the meson build is linked.

Index: lib/mesa/mk/libEGL/Makefile
===
RCS file: /cvs/xenocara/lib/mesa/mk/libEGL/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- lib/mesa/mk/libEGL/Makefile 22 Jul 2021 11:10:08 -  1.3
+++ lib/mesa/mk/libEGL/Makefile 31 Jul 2021 02:04:01 -
@@ -38,7 +38,8 @@ CPPFLAGS+=-I${MESA_SRC}/src/egl/main \
-I${MESA_SRC}/src/gbm/backends/dri \
-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_X11
 
-LDADD+= ${.CURDIR}/../libmesa_util/${__objdir}/libmesa_util.a \
+LDADD+= -Wl,--as-needed -Wl,--allow-shlib-undefined -Wl,--start-group \
+   ${.CURDIR}/../libmesa_util/${__objdir}/libmesa_util.a \
${.CURDIR}/../libmesa_format/${__objdir}/libmesa_format.a \
-lz -lm \
-L${X11BASE}/lib -lX11-xcb -lX11 -lxcb -lxcb-xfixes
@@ -55,7 +56,8 @@ LDADD+= ${.CURDIR}/../libloader_dri3_hel
 .endif
 
 LDADD+= -L${.CURDIR}/../libgbm/${__objdir} -lgbm \
-   -L${.CURDIR}/../libglapi/${__objdir} -lglapi
+   -L${.CURDIR}/../libglapi/${__objdir} -lglapi \
+   -Wl,--end-group
 
 obj: _xenocara_obj
 

Re: Why do the gtk+ ports use emacs keybindings?

[Jonathan Gray]

On Fri, Jul 16, 2021 at 03:18:31PM +, James Cook wrote:
> Sorry if this has been discussed before; I couldn't find it.
> 
> x11/gtk+2 and x11/gtk+3 include a patch to change the default
> keybindings to "emacs". The decision can be traced back to 2005:
> 
> Revision 1.1, Wed Sep 7 20:51:14 2005 UTC (15 years, 10 months ago) by 
> kurt
> Branch: MAIN
> 
> make emacs the default key theme. this will make the standard ^U, ^A, ^E
> etc emacs commands work by default for gtk+2 apps. orig from pvalchev@.
> 
> okay marcm@
> 
> 16 years later, I wonder if it's worth revisiting this decision.
> 
> For my part, I'm strongly opposed to it, but I'm just some user who
> occasionally contributes. Still, if you'll hear them, here are my
> arguments:
> 
> 1. This seems to create some confusion, at least for firefox users, e.g:
> 
>
> https://www.reddit.com/r/openbsd/comments/4aj3rb/how_do_i_turn_off_emacs_line_editing_in/
> 
>https://mas.to/@adnan360/106589261557989696
> 
>It certainly confused me, until I found the solution through some
>persistent Google searching.
> 
> 2. Even if I were clever enough to trace the Firefox issue to gtk+3,
>the gtk+3 package README does not describe the problem.
> 
>I'm happy to submit a patch to the gtk+3 README, but in my opinion
>this will not solve the confusion, because it's far from obvious
>that one should check the gtk+3 REDAME if one's Firefox keybindings
>are behaving strangely.
> 
> 3. I generally don't expect ports to adjust behaviour without a good
>reason. Users have strong expectations about the behaviour of gtk+
>applications (well, Firefox) based on what they've seen on other
>platforms. If you want emacs keybindings, you can edit your own
>config file.

ksh defaults to an emacs editing mode as well as bootloaders and other
things besides.  Not being able to edit a url in the same way is
annoying.

Re: vulkan ports: maintainer update to sdk 1.2.176.1

[Jonathan Gray]

On Sat, Jun 26, 2021 at 03:42:19PM -0600, Thomas Frohwein wrote:
> Hi,
> 
> This is a diff to update the ports for vulkan to the latest SDK release
> 1.2.176.1 from April. I've updated them and tested without issues with
> vkcube and vulkaninfo (both from the vulkan-tools port), as well as
> vkquake and the FNA game Cryptark with "fnaify /gldevice:Vulkan".
> 
> I tested vkquake with validation layers:
> 
> $ VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation vkquake
> 
> This seems to work and lists one error on start [1].

https://github.com/Novum/vkQuake/commit/db6d2a005a84cad0584a6b7c02af4d7ba56b1b0d

not yet in a non-beta release

> 
> A few notes on this update:
> 
> - For some reason, upstream named this "1.2.176.1-TAG". As versioning
>   has since progressed to 1.2.182 for non-SDK releases, I'm not
>   including the "-TAG".
> - All glslang tests succeed (this is the only one with working tests).
> - spirv-headers: use recent commit as no release tag since November
>   2020; version it as "1.5.4pl2" because there have been 2 patch tags
>   for 1.5.4 ("1.5.4.raytracing" and "1.5.4.raytracing.fixed").
> - spirv-tools: v2021.2 fails to build because of missing
>   SPV_OPERAND_TYPE_OPTIONAL_PACKED_VECTOR_FORMAT; therefore using
>   recent commit (2021.2pl20210623 from June 23rd).

Instead of 2021.2pl20210623 perhaps just 2021.2pl0?

> - vulkan-loader: remove BROKEN-i386 per the comment (was for clang
>   < 9.0.0)
> - vulkan-validation-layers: upstream defaults now to using "Robin Hood
>   Hashing." I haven't heard of this before; but per BUILD.md, this
>   would require a port of
>   https://github.com/martinus/robin-hood-hashing. Disable this for now;
>   we can figure out this out later and then enable.
> 
> Tested on Intel i7-10700 with the integrated UHD 630 GPU. Testing with
> amdgpu would be appreciated.

OpenBSD 6.9-current (GENERIC.MP) #93: Sat Jun 26 10:13:58 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
..
amdgpu0: VEGA10 56 CU rev 0x01

vulkaninfo vkcube and vkquake are fine

> 
> ok? Comments?

Just the patch level comment above.  Everything else looks fine.
ok jsg@ either way

update to sysutils/arm-trusted-firmware 2.5

[Jonathan Gray]

Build tested only for lack of hardware.

release notes
https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-2-5

Index: Makefile
===
RCS file: /cvs/ports/sysutils/arm-trusted-firmware/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile8 Jan 2021 00:11:17 -   1.15
+++ Makefile10 Jun 2021 05:27:08 -
@@ -6,7 +6,7 @@ COMMENT=ARM Trusted Firmware
 
 GH_ACCOUNT=ARM-software
 GH_PROJECT=arm-trusted-firmware
-GH_TAGNAME=v2.4
+GH_TAGNAME=v2.5
 
 EPOCH= 0
 
Index: distinfo
===
RCS file: /cvs/ports/sysutils/arm-trusted-firmware/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo8 Jan 2021 00:11:17 -   1.9
+++ distinfo10 Jun 2021 05:27:19 -
@@ -1,2 +1,2 @@
-SHA256 (arm-trusted-firmware-2.4.tar.gz) = 
S/2p/b5QIvLoitM0QWX304qK5KDi2R1E2aFgNCXMZC0=
-SIZE (arm-trusted-firmware-2.4.tar.gz) = 4593582
+SHA256 (arm-trusted-firmware-2.5.tar.gz) = 
/Ezax8CPw5i21LcFKF3BOsLSswp0ScbwfpzNgSByQd8=
+SIZE (arm-trusted-firmware-2.5.tar.gz) = 5506282

update intel microcode to 20210608

[Jonathan Gray]

update intel microcode to 20210608

release notes

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/microcode-20210608/releasenote.md

among other things covers

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00442.html
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00464.html
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00465.html

### New Platforms

| Processor  | Stepping | F-M-S/PI| Old Ver  | New Ver  | Products
|:---|:-|:|:-|:-|:-
| CLX-SP | A0   | 06-55-05/b7 |  | 0310 | Xeon Scalable 
Gen2
| ICX-SP | C0   | 06-6a-05/87 |  | 0c0002f0 | Xeon Scalable 
Gen3
| ICX-SP | D0   | 06-6a-06/87 |  | 0d0002a0 | Xeon Scalable 
Gen3
| SNR| B0   | 06-86-04/01 |  | 0b0f | Atom P59xxB
| SNR| B1   | 06-86-05/01 |  | 0b0f | Atom P59xxB
| TGL| B1   | 06-8c-01/80 |  | 0088 | Core Gen11 
Mobile
| TGL-R  | C0   | 06-8c-02/c2 |  | 0016 | Core Gen11 
Mobile
| TGL-H  | R0   | 06-8d-01/c2 |  | 002c | Core Gen11 
Mobile
| EHL| B1   | 06-96-01/01 |  | 0011 | Pentium 
J6426/N6415, Celeron J6412/J6413/N6210/N6211, Atom x6000E
| JSL| A0/A1| 06-9c-00/01 |  | 001d | Pentium 
N6000/N6005, Celeron N4500/N4505/N5100/N5105
| RKL-S  | B0   | 06-a7-01/02 |  | 0040 | Core Gen11

### Updated Platforms

| Processor  | Stepping | F-M-S/PI| Old Ver  | New Ver  | Products
|:---|:-|:|:-|:-|:-
| HSX-E/EP   | Cx/M1| 06-3f-02/6f | 0044 | 0046 | Core Gen4 X 
series; Xeon E5 v3
| HSX-EX | E0   | 06-3f-04/80 | 0016 | 0019 | Xeon E7 v3
| SKL-U/Y| D0   | 06-4e-03/c0 | 00e2 | 00ea | Core Gen6 
Mobile
| SKL-U23e   | K1   | 06-4e-03/c0 | 00e2 | 00ea | Core Gen6 
Mobile
| BDX-ML | B0/M0/R0 | 06-4f-01/ef | 0b38 | 0b3e | Xeon E5/E7 
v4; Core i7-69xx/68xx
| SKX-SP | B1   | 06-55-03/97 | 01000159 | 0100015b | Xeon Scalable
| SKX-SP | H0/M0/U0 | 06-55-04/b7 | 02006a0a | 02006b06 | Xeon Scalable
| SKX-D  | M1   | 06-55-04/b7 | 02006a0a | 02006b06 | Xeon D-21xx
| CLX-SP | B0   | 06-55-06/bf | 04003006 | 04003102 | Xeon Scalable 
Gen2
| CLX-SP | B1   | 06-55-07/bf | 05003006 | 05003102 | Xeon Scalable 
Gen2
| CPX-SP | A1   | 06-55-0b/bf | 071e | 07002302 | Xeon Scalable 
Gen3
| BDX-DE | V2/V3| 06-56-03/10 | 0719 | 071b | Xeon 
D-1518/19/21/27/28/31/33/37/41/48, Pentium D1507/08/09/17/19
| BDX-DE | Y0   | 06-56-04/10 | 0f17 | 0f19 | Xeon 
D-1557/59/67/71/77/81/87
| BDX-NS | A1   | 06-56-05/10 | 0e0f | 0e12 | Xeon 
D-1513N/23/33/43/53
| APL| D0   | 06-5c-09/03 | 0040 | 0044 | Pentium 
N/J4xxx, Celeron N/J3xxx, Atom x5/7-E39xx
| APL| E0   | 06-5c-0a/03 | 001e | 0020 | Atom x5-E39xx
| SKL-H/S| R0/N0| 06-5e-03/36 | 00e2 | 00ea | Core Gen6; 
Xeon E3 v5
| DNV| B0   | 06-5f-01/01 | 002e | 0034 | Atom C Series
| GLK| B0   | 06-7a-01/01 | 0034 | 0036 | Pentium 
Silver N/J5xxx, Celeron N/J4xxx
| GKL-R  | R0   | 06-7a-08/01 | 0018 | 001a | Pentium 
J5040/N5030, Celeron J4125/J4025/N4020/N4120
| ICL-U/Y| D1   | 06-7e-05/80 | 00a0 | 00a6 | Core Gen10 
Mobile
| LKF| B2/B3| 06-8a-01/10 | 0028 | 002a | Core w/Hybrid 
Technology
| AML-Y22| H0   | 06-8e-09/10 | 00de | 00ea | Core Gen8 
Mobile
| KBL-U/Y| H0   | 06-8e-09/c0 | 00de | 00ea | Core Gen7 
Mobile
| CFL-U43e   | D0   | 06-8e-0a/c0 | 00e0 | 00ea | Core Gen8 
Mobile
| WHL-U  | W0   | 06-8e-0b/d0 | 00de | 00ea | Core Gen8 
Mobile
| AML-Y42| V0   | 06-8e-0c/94 | 00de | 00ea | Core Gen10 
Mobile
| CML-Y42| V0   | 06-8e-0c/94 | 00de | 00ea | Core Gen10 
Mobile
| WHL-U  | V0   | 06-8e-0c/94 | 00de | 00ea | Core Gen8 
Mobile
| KBL-G/H/S/E3   | B0   | 06-9e-09/2a | 00de | 00ea | Core Gen7; 
Xeon E3 v6
| CFL-H/S/E3 | U0   | 06-9e-0a/22 | 00de | 00ea | Core Gen8 
Desktop, Mobile, Xeon E
| CFL-S  | B0   | 06-9e-0b/02 | 00de | 00ea | Core Gen8
| CFL-H/S| P0   | 06-9e-0c/22 | 00de | 00ea | Core Gen9
| CFL-H  | R0   | 06-9e-0d/22 | 00de | 00ea | Core Gen9 
Mobile
| CML-H  | R1   | 06-a5-02/20 | 00e0 | 00ea | Core Gen10 
Mobile
| CML-S62| G1   | 06-a5-03/22 | 00e0 | 00ea | Core Gen10
| CM

update amdgpu firmware to 20210511

[Jonathan Gray]

git log --oneline 20201218..20210511 amdgpu

3f23f51 amdgpu: add new polaris 12 MC firmware
cfa004c amdgpu: update arcturus firmware from 21.10
d5567c5 amdgpu: update navy flounder firmware from 21.10
ef5ea5d amdgpu: update sienna cichlid firmware from 21.10
f35700f amdgpu: update vega20 firmware from 21.10
1be98f1 amdgpu: update picasso firmware from 21.10
fee0497 amdgpu: update navi14 firmware from 21.10
15003b0 amdgpu: update green sardine firmware from 21.10
64555fb amdgpu: update vega12 firmware from 21.10
eb07276 amdgpu: update navi12 firmware from 21.10
e36c82a amdgpu: update vega10 firmware from 21.10
4a5eaa2 amdgpu: update renoir firmware from 21.10
65eb326 amdgpu: update navi10 firmware from 21.10
8bdca03 amdgpu: update raven2 firmware from 21.10
c9e44ca amdgpu: update raven firmware from 21.10
8ab7aba amdgpu: update navi14 smc firmware
4fe6e53 amdgpu: update navi10 SMC firmware
af1ca28 amdgpu: add arcturus firmware
c82cb46 amdgpu: update sienna cichlid firmware for 20.50
24fe696 amdgpu: update vega20 firmware for 20.50
e05d197 amdgpu: update picasso firmware for 20.50
76d07cd amdgpu: update navi14 firmware for 20.50
b2fc037 amdgpu: update vega12 firmware for 20.50
25451a4 amdgpu: update navi12 firmware for 20.50
b938597 amdgpu: update vega10 firmware for 20.50
2542ba7 amdgpu: update renoir firmware for 20.50
b55d063 amdgpu: update navi10 firmware for 20.50
1a62f28 amdgpu: update raven2 firmware for 20.50
4df488f amdgpu: update raven firmware for 20.50
a29bdb2 amdgpu: add initial support for navy flounder
f7915a0 amdgpu: add initial firmware for green sardine

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile20 Jan 2021 10:06:32 -  1.7
+++ Makefile22 May 2021 07:18:10 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.7 2021/01/20 10:06:32 jsg Exp $
 
 FW_DRIVER= amdgpu
-FW_VER=20201218
+FW_VER=20210511
 DISTNAME=  linux-firmware-${FW_VER}
 EXTRACT_SUFX=  .tar.xz
 EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,\*.bin}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo20 Jan 2021 10:06:32 -  1.6
+++ distinfo22 May 2021 07:18:35 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/linux-firmware-20201218.tar.xz) = 
ocwf9yxznzErCV31ien9Y5/IHD+PeWY3fqNSItyUwEs=
-SIZE (firmware/linux-firmware-20201218.tar.xz) = 137880408
+SHA256 (firmware/linux-firmware-20210511.tar.xz) = 
Kqaui5gIQI+YEaw48AwYjlPphKKzmQJU9snALBqxNBc=
+SIZE (firmware/linux-firmware-20210511.tar.xz) = 166689864
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST   20 Jan 2021 10:06:33 -  1.6
+++ pkg/PLIST   22 May 2021 07:19:05 -
@@ -1,6 +1,16 @@
 @comment $OpenBSD: PLIST,v 1.6 2021/01/20 10:06:33 jsg Exp $
 firmware/amdgpu/
 firmware/amdgpu/amdgpu-license
+firmware/amdgpu/arcturus_asd.bin
+firmware/amdgpu/arcturus_gpu_info.bin
+firmware/amdgpu/arcturus_mec.bin
+firmware/amdgpu/arcturus_mec2.bin
+firmware/amdgpu/arcturus_rlc.bin
+firmware/amdgpu/arcturus_sdma.bin
+firmware/amdgpu/arcturus_smc.bin
+firmware/amdgpu/arcturus_sos.bin
+firmware/amdgpu/arcturus_ta.bin
+firmware/amdgpu/arcturus_vcn.bin
 firmware/amdgpu/banks_k_2_smc.bin
 firmware/amdgpu/bonaire_ce.bin
 firmware/amdgpu/bonaire_k_smc.bin
@@ -36,6 +46,17 @@ firmware/amdgpu/fiji_sdma1.bin
 firmware/amdgpu/fiji_smc.bin
 firmware/amdgpu/fiji_uvd.bin
 firmware/amdgpu/fiji_vce.bin
+firmware/amdgpu/green_sardine_asd.bin
+firmware/amdgpu/green_sardine_ce.bin
+firmware/amdgpu/green_sardine_dmcub.bin
+firmware/amdgpu/green_sardine_me.bin
+firmware/amdgpu/green_sardine_mec.bin
+firmware/amdgpu/green_sardine_mec2.bin
+firmware/amdgpu/green_sardine_pfp.bin
+firmware/amdgpu/green_sardine_rlc.bin
+firmware/amdgpu/green_sardine_sdma.bin
+firmware/amdgpu/green_sardine_ta.bin
+firmware/amdgpu/green_sardine_vcn.bin
 firmware/amdgpu/hainan_ce.bin
 firmware/amdgpu/hainan_k_smc.bin
 firmware/amdgpu/hainan_mc.bin
@@ -131,6 +152,18 @@ firmware/amdgpu/navi14_smc.bin
 firmware/amdgpu/navi14_sos.bin
 firmware/amdgpu/navi14_ta.bin
 firmware/amdgpu/navi14_vcn.bin
+firmware/amdgpu/navy_flounder_ce.bin
+firmware/amdgpu/navy_flounder_dmcub.bin
+firmware/amdgpu/navy_flounder_me.bin
+firmware/amdgpu/navy_flounder_mec.bin
+firmware/amdgpu/navy_flounder_mec2.bin
+firmware/amdgpu/navy_flounder_pfp.bin
+firmware/amdgpu/navy_flounder_rlc.bin
+firmware/amdgpu/navy_flounder_sdma.bin
+firmware/amdgpu/navy_flounder_smc.bin
+firmware/amdgpu/navy_flounder_sos.bin
+firmware/amdgpu/navy_flounder_ta.bin
+firmware/amdgpu/navy_flounder_vcn.bin
 firmware/amdgpu/oland_ce.bin
 firmware/amdgpu/oland_k_smc.bin
 firmware/amd

add riscv64 U-Boot flavor

[Jonathan Gray]

This requires the riscv-elf/binutils diff for -shared.

Tested with
qemu-system-riscv64 -M virt 
-bios opensbi/generic/fw_jump.bin
-kernel u-boot/qemu-riscv64_smode/u-boot.bin

Index: Makefile
===
RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.82
diff -u -p -r1.82 Makefile
--- Makefile23 Apr 2021 23:56:11 -  1.82
+++ Makefile27 Apr 2021 10:16:51 -
@@ -3,7 +3,7 @@
 BROKEN-sparc64=Error: the specified option is not accepted in ISB at 
operand 1 -- isb sy
 BROKEN-arm=lib/time.c:187:1: internal compiler error: Bus error
 
-FLAVORS=   aarch64 arm
+FLAVORS=   aarch64 arm riscv64
 FLAVOR?=   arm
 
 COMMENT=   U-Boot firmware
@@ -47,6 +47,9 @@ SUNXI_BL31=   "${LOCALBASE}/share/arm-trus
 .elif "${FLAVOR}" == "arm"
 BUILD_DEPENDS+=devel/arm-none-eabi/gcc-linaro>=7.4.2019.02
 MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-"
+.elif "${FLAVOR}" == "riscv64"
+BUILD_DEPENDS+= devel/riscv-elf/gcc
+MAKE_ENV+= CROSS_COMPILE="riscv64-unknown-elf-"
 .endif
 
 USE_GMAKE= Yes
@@ -139,6 +142,9 @@ BOARDS=\
tinker-rk3288 \
turris_omnia \
vexpress_ca15_tc2
+.elif "${FLAVOR}" == "riscv64"
+BOARDS=\
+   qemu-riscv64_smode
 .endif
 
 FILES=\
Index: pkg/PFRAG.riscv64
===
RCS file: pkg/PFRAG.riscv64
diff -N pkg/PFRAG.riscv64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/PFRAG.riscv64   27 Apr 2021 10:16:51 -
@@ -0,0 +1,5 @@
+@comment $OpenBSD$
+share/u-boot/
+share/u-boot/qemu-riscv64_smode/
+share/u-boot/qemu-riscv64_smode/u-boot
+share/u-boot/qemu-riscv64_smode/u-boot.bin
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/u-boot/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST   11 Dec 2016 14:08:39 -  1.5
+++ pkg/PLIST   27 Apr 2021 10:16:51 -
@@ -1,3 +1,4 @@
 @comment $OpenBSD: PLIST,v 1.5 2016/12/11 14:08:39 patrick Exp $
 %%aarch64%%
 %%arm%%
+%%riscv64%%

NEW: sysutils/opensbi

[Jonathan Gray]

Here is a port of the RISC-V Open Source Supervisor Binary Interface
(https://github.com/riscv/opensbi) which builds the 'generic' platform
and packages fw_jump.bin.

Tested with qemu-system-riscv64 -M virt.


opensbi.tgz
Description: application/tar-gz

enable -shared for riscv-elf-binutils

[Jonathan Gray]

Add a patch from FreeBSD to allow -shared, needed for U-Boot build.

update to 2.31.1 to match arm-none-eabi/binutils

Index: Makefile
===
RCS file: /cvs/ports/devel/riscv-elf/binutils/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile8 Jun 2018 14:24:32 -   1.1.1.1
+++ Makefile27 Apr 2021 09:56:14 -
@@ -2,7 +2,7 @@
 
 COMMENT=   binutils for riscv-elf cross-development
 
-V= 2.30
+V= 2.31.1
 DISTNAME=  binutils-${V}
 
 HOMEPAGE=  https://www.gnu.org/software/binutils/
Index: distinfo
===
RCS file: /cvs/ports/devel/riscv-elf/binutils/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo8 Jun 2018 14:24:32 -   1.1.1.1
+++ distinfo27 Apr 2021 09:56:14 -
@@ -1,2 +1,2 @@
-SHA256 (binutils/binutils-2.30.tar.xz) = 
bka4rq4vcno28L2VBeQFdopyIY8XlvDQl1fUUgmHGuY=
-SIZE (binutils/binutils-2.30.tar.xz) = 20286700
+SHA256 (binutils/binutils-2.31.1.tar.xz) = 
XSAIbs9XUsx9kTQkbpWI+iAXQNVA9+uE15Wx96k7yoY=
+SIZE (binutils/binutils-2.31.1.tar.xz) = 20467996
Index: patches/patch-bfd_doc_Makefile_in
===
RCS file: 
/cvs/ports/devel/riscv-elf/binutils/patches/patch-bfd_doc_Makefile_in,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-bfd_doc_Makefile_in
--- patches/patch-bfd_doc_Makefile_in   8 Jun 2018 14:24:32 -   1.1.1.1
+++ patches/patch-bfd_doc_Makefile_in   27 Apr 2021 09:56:14 -
@@ -3,12 +3,12 @@ $OpenBSD: patch-bfd_doc_Makefile_in,v 1.
 Index: bfd/doc/Makefile.in
 --- bfd/doc/Makefile.in.orig
 +++ bfd/doc/Makefile.in
-@@ -104,7 +104,7 @@ CONFIG_CLEAN_VPATH_FILES =
- depcomp =
- am__depfiles_maybe =
- SOURCES =
+@@ -174,7 +174,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
 -INFO_DEPS = bfd.info
 +INFO_DEPS =
- TEXINFO_TEX = $(top_srcdir)/../texinfo/texinfo.tex
- am__TEXINFO_TEX_DIR = $(top_srcdir)/../texinfo
+ am__TEXINFO_TEX_DIR = $(srcdir)
  DVIS = bfd.dvi
+ PDFS = bfd.pdf
Index: patches/patch-binutils_doc_Makefile_in
===
RCS file: 
/cvs/ports/devel/riscv-elf/binutils/patches/patch-binutils_doc_Makefile_in,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-binutils_doc_Makefile_in
--- patches/patch-binutils_doc_Makefile_in  8 Jun 2018 14:24:32 -   
1.1.1.1
+++ patches/patch-binutils_doc_Makefile_in  27 Apr 2021 09:56:14 -
@@ -3,12 +3,12 @@ $OpenBSD: patch-binutils_doc_Makefile_in
 Index: binutils/doc/Makefile.in
 --- binutils/doc/Makefile.in.orig
 +++ binutils/doc/Makefile.in
-@@ -101,7 +101,7 @@ CONFIG_CLEAN_VPATH_FILES =
- depcomp =
- am__depfiles_maybe =
- SOURCES =
+@@ -177,7 +177,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
 -INFO_DEPS = binutils.info
-+INFO_DEPS = 
- TEXINFO_TEX = $(top_srcdir)/../texinfo/texinfo.tex
- am__TEXINFO_TEX_DIR = $(top_srcdir)/../texinfo
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
  DVIS = binutils.dvi
+ PDFS = binutils.pdf
Index: patches/patch-gas_doc_Makefile_in
===
RCS file: 
/cvs/ports/devel/riscv-elf/binutils/patches/patch-gas_doc_Makefile_in,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-gas_doc_Makefile_in
--- patches/patch-gas_doc_Makefile_in   8 Jun 2018 14:24:32 -   1.1.1.1
+++ patches/patch-gas_doc_Makefile_in   27 Apr 2021 09:56:14 -
@@ -3,12 +3,12 @@ $OpenBSD: patch-gas_doc_Makefile_in,v 1.
 Index: gas/doc/Makefile.in
 --- gas/doc/Makefile.in.orig
 +++ gas/doc/Makefile.in
-@@ -99,7 +99,7 @@ CONFIG_CLEAN_VPATH_FILES =
- depcomp =
- am__depfiles_maybe =
- SOURCES =
+@@ -174,7 +174,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
 -INFO_DEPS = as.info
 +INFO_DEPS =
- TEXINFO_TEX = $(top_srcdir)/../texinfo/texinfo.tex
- am__TEXINFO_TEX_DIR = $(top_srcdir)/../texinfo
+ TEXINFO_TEX = $(top_srcdir)/../texinfo.tex
+ am__TEXINFO_TEX_DIR = $(top_srcdir)/..
  DVIS = as.dvi
Index: patches/patch-gprof_Makefile_in
===
RCS file: /cvs/ports/devel/riscv-elf/binutils/patches/patch-gprof_Makefile_in,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-gprof_Makefile_in
--- patches/patch-gprof_Makefile_in 8 Jun 2018 14:24:32 -   1.1.1.1
+++ patches/patch-gprof_Makefile_in 27 Apr 2021 09:56:14 -
@@ -3,10 +3,10 @@ $OpenBSD: patch-gprof_Makefile_in,v 1.1.
 Index: gprof/Makefile.in
 --- gprof/Makefile.in.orig
 +++ gprof/Makef

Re: NEW: lang/lua/5.4

[Jonathan Gray]

On Sat, Feb 20, 2021 at 12:49:13PM +1100, Jonathan Gray wrote:
> add lua 5.4.2
> 
> https://www.lua.org/manual/5.4/readme.html#changes

update for 5.4.3

Index: lang/lua/Makefile
===
RCS file: /cvs/ports/lang/lua/Makefile,v
retrieving revision 1.47
diff -u -p -r1.47 Makefile
--- lang/lua/Makefile   14 Jan 2015 20:07:45 -  1.47
+++ lang/lua/Makefile   19 Feb 2021 13:26:20 -
@@ -4,6 +4,7 @@
 SUBDIR += 5.1
 SUBDIR += 5.2
 SUBDIR += 5.3
+SUBDIR += 5.4
 
 .include 
 
Index: lang/lua/lua.port.mk
===
RCS file: /cvs/ports/lang/lua/lua.port.mk,v
retrieving revision 1.35
diff -u -p -r1.35 lua.port.mk
--- lang/lua/lua.port.mk31 Oct 2016 18:46:09 -  1.35
+++ lang/lua/lua.port.mk19 Feb 2021 13:25:59 -
@@ -17,6 +17,8 @@ FLAVOR ?= # empty
 MODLUA_VERSION =   5.2
 .elif ${FLAVOR:Mlua53}
 MODLUA_VERSION =   5.3
+.elif ${FLAVOR:Mlua54}
+MODLUA_VERSION =   5.4
 .else
 MODLUA_VERSION ?=  ${MODLUA_DEFAULT_VERSION}
 .endif
@@ -30,6 +32,9 @@ MODLUA_FLAVOR =   lua52
 .elif "${MODLUA_VERSION}" == "5.3"
 _MODLUA_PKG_PREFIX =   lua53
 MODLUA_FLAVOR =lua53
+.elif "${MODLUA_VERSION}" == "5.4"
+_MODLUA_PKG_PREFIX =   lua54
+MODLUA_FLAVOR =lua54
 .else
 ERRORS +=  "Invalid MODLUA_VERSION set: ${MODLUA_VERSION}."
 .endif


lua54.tgz
Description: application/tar-gz

Re: graphics/piglit: missing BDEP on glslang

[Jonathan Gray]

On Tue, Mar 30, 2021 at 07:58:10AM +0200, Theo Buehler wrote:
> piglit failed to build in a bulk due to a missing dependency. Patch
> below fixed the build for me.
> 
> [3320/4182] cd 
> /tmp/pobj/piglit-20210128/build-amd64/target_api/gl/tests/spec/ext_external_objects
>  && /usr/local/bin/glslangValidator -V 
> /tmp/pobj/piglit-20210128/piglit-83173d9536c9f5e1571efe5933d210466ec255b8/tests/spec/ext_external_objects/vk_blue.vert
>  -o 
> /tmp/pobj/piglit-20210128/piglit-83173d9536c9f5e1571efe5933d210466ec255b8/tests/spec/ext_external_objects/vk_blue.vert.spv
> FAILED: 
> /tmp/pobj/piglit-20210128/piglit-83173d9536c9f5e1571efe5933d210466ec255b8/tests/spec/ext_external_objects/vk_blue.vert.spv
> cd 
> /tmp/pobj/piglit-20210128/build-amd64/target_api/gl/tests/spec/ext_external_objects
>  && /usr/local/bin/glslangValidator -V 
> /tmp/pobj/piglit-20210128/piglit-83173d9536c9f5e1571efe5933d210466ec255b8/tests/spec/ext_external_objects/vk_blue.vert
>  -o 
> /tmp/pobj/piglit-20210128/piglit-83173d9536c9f5e1571efe5933d210466ec255b8/tests/spec/ext_external_objects/vk_blue.vert.spv
> /bin/sh: /usr/local/bin/glslangValidator: not found
> ninja: build stopped: subcommand failed.
> *** Error 1 in graphics/piglit (/usr/ports/devel/cmake/cmake.port.mk:36 
> 'do-build': @cd /tmp/pobj/piglit-20210128/build-amd64 && exec /usr/b...)
> *** Error 2 in graphics/piglit (/usr/ports/infrastructure/mk/bsd.port.mk:2943 
> '/tmp/pobj/piglit-20210128/build-amd64/.build_done': @cd /usr/...)
> *** Error 2 in graphics/piglit (/usr/ports/infrastructure/mk/bsd.port.mk:2602 
> 'build': @lock=piglit-20210128;  export _LOCKS_HELD=" piglit-2...)
> ===> Exiting graphics/piglit with an error
> *** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:137 'build': 
> @: ${echo_msg:=echo};  : ${target:=build};  for i in ; do  eval...

ok jsg@ though there is something odd here as there is a build time
check for it before it is used:

https://github.com/mesa3d/piglit/blob/83173d9536c9f5e1571efe5933d210466ec255b8/tests/spec/ext_external_objects/CMakeLists.gl.txt#L36

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/piglit/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile  23 Feb 2021 19:39:26 -  1.15
> +++ Makefile  30 Mar 2021 05:18:57 -
> @@ -8,6 +8,7 @@ DISTNAME =piglit-20210128
>  GH_ACCOUNT = mesa3d
>  GH_PROJECT = piglit
>  GH_COMMIT =  83173d9536c9f5e1571efe5933d210466ec255b8
> +REVISION =   0
>  
>  CATEGORIES = graphics
>  
> @@ -37,6 +38,7 @@ RUN_DEPENDS =   devel/py-six${MODPY_FLAVO
>   math/py-numpy${MODPY_FLAVOR} \
>   www/py-mako${MODPY_FLAVOR}
>  BUILD_DEPENDS =  ${RUN_DEPENDS} \
> + graphics/glslang \
>   graphics/vulkan-headers
>  
>  LIB_DEPENDS =graphics/waffle \
> 
> 

Re: sysutils/dtb: use EXTRACT_FILES, no need for sed

[Jonathan Gray]

On Wed, Mar 24, 2021 at 10:41:53PM +0100, Klemens Nanni wrote:
> On Wed, Mar 24, 2021 at 10:29:36PM +0100, Klemens Nanni wrote:
> > No need to extract the entire linux source when we only want device
> > trees.
> > 
> > While here, use a simple shell idiom to replace file suffix.
> > 
> > Builds all fine on amd64, no PLIST change.
> > OK?
> 
> Oops, now without PLIST changes from intermediate testing.
> 

ok jsg@ if you drop the comment.  Those values will change and it is
clear without it that using EXTRACT_FILES is to reduce size.

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/dtb/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile  28 Feb 2021 09:33:30 -  1.26
> +++ Makefile  24 Mar 2021 21:22:08 -
> @@ -25,6 +25,10 @@ NO_TEST=   Yes
>  
>  ARCHS= arm arm64 mips powerpc
>  
> +# cuts down WRKSRC from ~1G to ~62M
> +EXTRACT_FILES=   ${ARCHS:=${DISTNAME}/arch/%/boot/dts} \
> + ${DISTNAME}/{include,scripts/dtc/include-prefixes}
> +
>  do-build:
>  .for ARCH in ${ARCHS}
>   cd ${WRKSRC}/arch/${ARCH}/boot/dts ; \
> @@ -34,8 +38,7 @@ do-build:
>   clang-cpp -nostdinc -I . -I include -I${WRKSRC}/include \
>   -I ${WRKSRC}/scripts/dtc/include-prefixes \
>   -undef -D__DTS__ -x assembler-with-cpp $$dts \
> - | dtc -I dts -O dtb -o `echo "$$dts" \
> - | sed -e 's/\.dts$$/\.dtb/'` - ; \
> + | dtc -I dts -O dtb -o $${dts%.dts}.dtb - ; \
>   done ; \
>   done
>  .endfor
> 
> 

Re: sysutils/u-boot: Ship assorted README files

[Jonathan Gray]

On Tue, Mar 23, 2021 at 11:19:32PM +0100, Klemens Nanni wrote:
> On Tue, Mar 23, 2021 at 09:10:22PM +0100, Klemens Nanni wrote:
> > One thing I'd like to have around is documentation on how certain
> > u-boot commands/subsystems work and/or what needs to be done on
> > certain specific boards.
> > 
> > I'm on a Pinebook Pro here and ${WRKSRC}/doc/README.rockchip
> > (thanks abieber!) for example has the relevant dd(1) commands to flash
> > the various blobs -- with that I don't need to try my luck or search
> > online get a firmware update going and/or prep an SD card.
> > 
> > I know that those README.* files generally also explain how to configure
> > and build stuff from source and we are not interested in those bits, but
> > shipping them unmodified is still of value, especially because I can
> > now work on those boxes while mostly offline.
> > 
> > Besides board specific docs there is general information available
> > regarding serial console and video output, GPT partitioning from within
> > u-boot, etc. so I added a few assorted READMEs as well.
> > 
> > Since those ought be shipped regardless of the flavour but and we must
> > not install the same files via multiple packages I've used PKGSTEM
> > (contains FLAVOR) as part of the file path such that each FLAVOR may
> > ship the same docs but under their own unique path.
> > 
> > I have other improvemens in mind but want to take care of them one by
> > one.
> New diff using PKGSTEM in PFRAG.* and BOARD_READMES not ARCH_READMES.
> 
> Feedback? OK?

I don't see a need to have different vars when the files are all
pulled from the same dir.

I don't see a reason for many of these.  We don't use GPT partitioning
on arm, pxe is really for non-uefi booting and the offsets are
covered in INSTALL.armv7/INSTALL.arm64.

> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
> retrieving revision 1.80
> diff -u -p -r1.80 Makefile
> --- Makefile  23 Feb 2021 22:04:35 -  1.80
> +++ Makefile  23 Mar 2021 19:58:27 -
> @@ -8,7 +8,7 @@ FLAVOR?=  arm
>  
>  COMMENT= U-Boot firmware
>  VERSION= 2021.01
> -REVISION=0
> +REVISION=1
>  DISTNAME=u-boot-${VERSION}
>  PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
>  FULLPKGNAME= ${PKGNAME}
> @@ -82,6 +82,8 @@ BOARDS=\
>   rockpro64-rk3399 \
>   rpi_3 \
>   rpi_4
> +BOARD_READMES=\
> + rockchip
>  .elif "${FLAVOR}" == "arm"
>  OMAP=\
>   omap4_panda \
> @@ -140,6 +142,7 @@ BOARDS=\
>   tinker-rk3288 \
>   turris_omnia \
>   vexpress_ca15_tc2
> +BOARD_READMES=
>  .endif
>  
>  FILES=\
> @@ -156,7 +159,15 @@ FILES=\
>   u-boot.itb \
>   u-boot-rockchip.bin \
>   idbloader.img \
> - spl/sunxi-spl.bin \
> + spl/sunxi-spl.bin
> +
> +CMD_READMES+=\
> + console \
> + gpt \
> + nvme \
> + pxe \
> + usb \
> + video
>  
>  do-build:
>  .for BOARD in ${BOARDS}
> @@ -210,6 +221,11 @@ do-install:
>   ${INSTALL_DATA_DIR} ${PREFIX}/share/u-boot/${BOARD}
>   -cd ${WRKSRC}/build/${BOARD} && \
>   cp ${FILES} ${PREFIX}/share/u-boot/${BOARD}/
> +.endfor
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/${PKGSTEM}
> +.for README in ${BOARD_READMES} ${CMD_READMES}
> + ${INSTALL_DATA} ${WRKSRC}/doc/README.${README} \
> + ${PREFIX}/share/doc/${PKGSTEM}/
>  .endfor
>  
>  .include 
> Index: pkg/PFRAG.aarch64
> ===
> RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.aarch64,v
> retrieving revision 1.22
> diff -u -p -r1.22 PFRAG.aarch64
> --- pkg/PFRAG.aarch64 15 Jan 2021 00:01:16 -  1.22
> +++ pkg/PFRAG.aarch64 23 Mar 2021 19:59:37 -
> @@ -1,5 +1,13 @@
>  @comment $OpenBSD: PFRAG.aarch64,v 1.22 2021/01/15 00:01:16 kurt Exp $
>  @pkgpath sysutils/u-boot-pinebook
> +share/doc/${PKGSTEM}/
> +share/doc/${PKGSTEM}/README.console
> +share/doc/${PKGSTEM}/README.gpt
> +share/doc/${PKGSTEM}/README.nvme
> +share/doc/${PKGSTEM}/README.pxe
> +share/doc/${PKGSTEM}/README.rockchip
> +share/doc/${PKGSTEM}/README.usb
> +share/doc/${PKGSTEM}/README.video
>  share/u-boot/
>  share/u-boot/a64-olinuxino/
>  share/u-boot/a64-olinuxino/sunxi-spl.bin
> Index: pkg/PFRAG.arm
> ===
> RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.arm,v
> retrieving revision 1.24
> diff -u -p -r1.24 PFRAG.arm
> --- pkg/PFRAG.arm 14 Jan 2021 00:56:54 -  1.24
> +++ pkg/PFRAG.arm 23 Mar 2021 19:48:37 -
> @@ -1,5 +1,12 @@
>  @comment $OpenBSD: PFRAG.arm,v 1.24 2021/01/14 00:56:54 jsg Exp $
>  @pkgpath sysutils/u-boot,
> +share/doc/${PKGSTEM}/
> +share/doc/${PKGSTEM}/README.console
> +share/doc/${PKGSTEM}/README.gpt
> +share/doc/${PKGSTEM}/README.nvme
> +share/doc/${PKGSTEM}/README.pxe
> +share/doc/${PKGSTEM}/README.usb
> +share/doc/${PKGSTEM}/README.video
>  share/u-boot/
>  share/u-boot/A10-OLinuXino-Lime/
>  share/u-b

Re: sysutils/arm-trusted-firmware: Set HOMEPAGE, use primary repo

[Jonathan Gray]

On Wed, Mar 24, 2021 at 04:26:51PM +0100, Klemens Nanni wrote:
> GitHub is just a mirror and links to where users want to end up,
> so update the port accordingly.
> 
> Builds and packages fine as before.
> 
> OK?

github was the original repository before they moved to
trustedfirmware.org and made github a mirror.

It isn't clear to me how stable the cgit? snapshots on
trustedfirmware.org are compared to github.

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/arm-trusted-firmware/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile  8 Jan 2021 00:11:17 -   1.15
> +++ Makefile  24 Mar 2021 15:25:10 -
> @@ -4,12 +4,16 @@ PKG_ARCH=   *
>  
>  COMMENT= ARM Trusted Firmware
>  
> -GH_ACCOUNT=  ARM-software
> -GH_PROJECT=  arm-trusted-firmware
> -GH_TAGNAME=  v2.4
> +V=   2.4
> +DISTNAME=trusted-firmware-a-${V}
> +PKGNAME= arm-trusted-firmware-${V}
> +REVISION=0
>  
>  EPOCH=   0
>  
> +HOMEPAGE=https://www.trustedfirmware.org/projects/tf-a/
> +MASTER_SITES=
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot/
> +
>  CATEGORIES=  sysutils
>  
>  # BSD
> @@ -19,7 +23,7 @@ BUILD_DEPENDS+= devel/arm-none-eabi/gcc-
>  BUILD_DEPENDS+= devel/arm-none-eabi/gcc-linaro,arm
>  
>  MAKE_ENV+= CROSS_COMPILE="aarch64-none-elf-"
> -MAKE_ENV+= BUILD_STRING="${GH_TAGNAME:S/v//}"
> +MAKE_ENV+= BUILD_STRING="${V}"
>  
>  NO_TEST= Yes
>  USE_GMAKE=   Yes
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/arm-trusted-firmware/distinfo,v
> retrieving revision 1.9
> diff -u -p -r1.9 distinfo
> --- distinfo  8 Jan 2021 00:11:17 -   1.9
> +++ distinfo  24 Mar 2021 15:21:35 -
> @@ -1,2 +1,2 @@
> -SHA256 (arm-trusted-firmware-2.4.tar.gz) = 
> S/2p/b5QIvLoitM0QWX304qK5KDi2R1E2aFgNCXMZC0=
> -SIZE (arm-trusted-firmware-2.4.tar.gz) = 4593582
> +SHA256 (trusted-firmware-a-2.4.tar.gz) = 
> vz6zYXp0zd1/sODqy/44wyWO4H1Mjtcw3u96F1zD1Vs=
> +SIZE (trusted-firmware-a-2.4.tar.gz) = 4593556
> 
> 

Re: Remove devel/mk

[Jonathan Gray]

On Wed, Mar 03, 2021 at 01:21:31PM +0100, Klemens Nanni wrote:
> On Wed, Feb 24, 2021 at 12:21:43PM +1100, Jonathan Gray wrote:
> > On Tue, Feb 23, 2021 at 04:36:49PM +0100, Klemens Nanni wrote:
> > > On Tue, Feb 23, 2021 at 11:59:12PM +1100, Jonathan Gray wrote:
> > > > devel/mk was also the only use of
> > > > 
> > > > devel/libfmt
> > > > devel/libbio
> > > > devel/libregexp9
> > > > devel/libutf
> > > Correct, those we can tackle now;  I had not yet checked their relation
> > > to plan9/plan9port.
> > > 
> > > Only libbio and libregexp9 seem to be part of plan9port, i.e.
> > > 
> > >   $ pkg_info -L plan9port | egrep 'lib/lib(fmt|bio|regexp9|utf)'
> > >   /usr/local/plan9/lib/libbio.a
> > >   /usr/local/plan9/lib/libregexp9.a
> > 
> > libfmt and libutf are part of lib9 in plan9port and libc in plan 9.
> > 
> > > 
> > > Due to the dependencies between those ports we can only only delete all
> > > of them as far as I can tell.
> > > 
> > > They all build but it is doubtworthy whether anyone uses them.
> > > 
> > > None of them have seen any updates since import in 2003 and it's the
> > > story with upstream not providing any versions.
> > > 
> > > OK to remove those?
> > 
> > I think so, perhaps markus can confirm?
> 
> markus? gsoares?
> 
> Without objection, I'll remove those unversioned ports in favour of
> plan9port soon.

markus mailed gsoares and myself but not the list
'they are replaced by plan9port and can be removed'.

Re: [NEW][WIP] games/openxray game engine port for S.T.A.L.K.E.R.

[Jonathan Gray]

On Sat, Feb 27, 2021 at 01:53:22PM +0300, Eugene Moz. wrote:
> Hello,
> This is based on: https://github.com/OpenXRay/xray-16

Isn't this based on leaked code they don't have permission to distribute?

"All source code included with this distribution, unless declared
otherwise, is commercial GSC Game World proprietary code."

"Be advised that this is a community project not sanctioned by GSC Game
World in any way – and they remain the copyright holders of all the
original source code and S.T.A.L.K.E.R. franchise."

> This is work in progress, at the time of writing, I'm stuck at
> "undefined reference to `__cxa_atexit'", I've tried building
> with both ports-gcc and base-clang, same error. For now I've
> chosen gcc, clang is not officialy supported by ^1.
> If anyone is willing to help get this working, please do so =)
> I'll include my last build.log, for examination purposes:
> https://clbin.com/WjJoU
> --
> Eugene Moz.

Re: Remove devel/mk

[Jonathan Gray]

On Tue, Feb 23, 2021 at 04:36:49PM +0100, Klemens Nanni wrote:
> On Tue, Feb 23, 2021 at 11:59:12PM +1100, Jonathan Gray wrote:
> > devel/mk was also the only use of
> > 
> > devel/libfmt
> > devel/libbio
> > devel/libregexp9
> > devel/libutf
> Correct, those we can tackle now;  I had not yet checked their relation
> to plan9/plan9port.
> 
> Only libbio and libregexp9 seem to be part of plan9port, i.e.
> 
>   $ pkg_info -L plan9port | egrep 'lib/lib(fmt|bio|regexp9|utf)'
>   /usr/local/plan9/lib/libbio.a
>   /usr/local/plan9/lib/libregexp9.a

libfmt and libutf are part of lib9 in plan9port and libc in plan 9.

> 
> Due to the dependencies between those ports we can only only delete all
> of them as far as I can tell.
> 
> They all build but it is doubtworthy whether anyone uses them.
> 
> None of them have seen any updates since import in 2003 and it's the
> story with upstream not providing any versions.
> 
> OK to remove those?

I think so, perhaps markus can confirm?

Re: Remove devel/mk

[Jonathan Gray]

On Tue, Feb 23, 2021 at 12:50:55PM +0100, Klemens Nanni wrote:
> Fails with "-fno-common" and Upstream HOMEPAGE (equals MASTER_SITES) now
> points to https://9fans.github.io/plan9port/unix/ which provides
> unversioned tarballs with links to checksums that yield 404;  same story
> for their manual page links on that page.  The GitHub repository does
> not contain releases either.
> 
> So devel/mk is now unportable due to upstream, but we have an
> up-to-date plan9/plan9port which packages from the very same upstream
> repo (using GH_COMMIT and dates as DISTNAME versions, it seems) which
> ships
>   /usr/local/plan9/bin/mk
>   /usr/local/plan9/man/man1/mk.1
>   /usr/local/plan9/unix/man/mk.1
> 
> OK to remove?
> I'd just point at plan9/plan9port in the `obsolete_reason' and not do
> any merging as that port contains much more and mk(1) lives somewhere
> else entirely anyway.

devel/mk was also the only use of

devel/libfmt
devel/libbio
devel/libregexp9
devel/libutf

NEW: lang/lua/5.4

[Jonathan Gray]

add lua 5.4.2

https://www.lua.org/manual/5.4/readme.html#changes

Index: lang/lua/Makefile
===
RCS file: /cvs/ports/lang/lua/Makefile,v
retrieving revision 1.47
diff -u -p -r1.47 Makefile
--- lang/lua/Makefile   14 Jan 2015 20:07:45 -  1.47
+++ lang/lua/Makefile   19 Feb 2021 13:26:20 -
@@ -4,6 +4,7 @@
 SUBDIR += 5.1
 SUBDIR += 5.2
 SUBDIR += 5.3
+SUBDIR += 5.4
 
 .include 
 
Index: lang/lua/lua.port.mk
===
RCS file: /cvs/ports/lang/lua/lua.port.mk,v
retrieving revision 1.35
diff -u -p -r1.35 lua.port.mk
--- lang/lua/lua.port.mk31 Oct 2016 18:46:09 -  1.35
+++ lang/lua/lua.port.mk19 Feb 2021 13:25:59 -
@@ -17,6 +17,8 @@ FLAVOR ?= # empty
 MODLUA_VERSION =   5.2
 .elif ${FLAVOR:Mlua53}
 MODLUA_VERSION =   5.3
+.elif ${FLAVOR:Mlua54}
+MODLUA_VERSION =   5.4
 .else
 MODLUA_VERSION ?=  ${MODLUA_DEFAULT_VERSION}
 .endif
@@ -30,6 +32,9 @@ MODLUA_FLAVOR =   lua52
 .elif "${MODLUA_VERSION}" == "5.3"
 _MODLUA_PKG_PREFIX =   lua53
 MODLUA_FLAVOR =lua53
+.elif "${MODLUA_VERSION}" == "5.4"
+_MODLUA_PKG_PREFIX =   lua54
+MODLUA_FLAVOR =lua54
 .else
 ERRORS +=  "Invalid MODLUA_VERSION set: ${MODLUA_VERSION}."
 .endif


lua54.tgz
Description: application/tar-gz

update intel microcode to 20210216

[Jonathan Gray]

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/microcode-20210216/releasenote.md

### Purpose

Security updates for
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00381.html

### Updated Platforms

| Processor  | Stepping | F-M-S/PI| Old Ver  | New Ver  | Products
||--|-|--|--|--
| SKX-SP | H0/M0/U0 | 06-55-04/b7 | 02006a08 | 02006a0a | Xeon Scalable
| SKX-D  | M1   | 06-55-04/b7 | 02006a08 | 02006a0a | Xeon D-21xx
| CLX-SP | B0   | 06-55-06/bf | 04003003 | 04003006 | Xeon Scalable 
Gen2
| CLX-SP | B1   | 06-55-07/bf | 05003003 | 05003006 | Xeon Scalable 
Gen2

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/intel/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- Makefile14 Nov 2020 23:17:14 -  1.25
+++ Makefile17 Feb 2021 13:14:37 -
@@ -3,7 +3,7 @@
 COMMENT=   microcode update binaries for Intel CPUs
 FW_DRIVER= intel
 
-FW_VER=20201112
+FW_VER=20210216
 EPOCH= 0
 GH_ACCOUNT=intel
 GH_PROJECT=Intel-Linux-Processor-Microcode-Data-Files
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/intel/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo14 Nov 2020 23:17:14 -  1.18
+++ distinfo17 Feb 2021 13:14:43 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/intel-20201112.tar.gz) = 
qifGoTjEQLyLnBkUXwL750JceE/q9h5c+hM0b53pqSc=
-SIZE (firmware/intel-20201112.tar.gz) = 3610834
+SHA256 (firmware/intel-20210216.tar.gz) = 
uFXIH3hwXzU0EkigYDqhpuGZyn9ZzUJeBhtXkymqnqo=
+SIZE (firmware/intel-20210216.tar.gz) = 3506111

allow /dev/dri/card0 in firefox

[Jonathan Gray]

drm /dev nodes with the linux names are going to be added with the old
names going away sometime later.  When libdrm is changed to use the new
names firefox will need this.  chromium does sandboxing better so
doesn't need a change like this.

I didn't find any use of /dev/drm inside the firefox source itself.

Index: mozilla-firefox/Makefile
===
RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
retrieving revision 1.449
diff -u -p -r1.449 Makefile
--- mozilla-firefox/Makefile26 Jan 2021 15:52:58 -  1.449
+++ mozilla-firefox/Makefile11 Feb 2021 23:23:18 -
@@ -9,6 +9,7 @@ MOZILLA_VERSION =   85.0
 MOZILLA_BRANCH =   release
 MOZILLA_PROJECT =  firefox
 MOZILLA_CODENAME = browser
+REVISION = 0
 
 WRKDIST =  ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
 HOMEPAGE = https://www.mozilla.org/firefox/
Index: mozilla-firefox/files/unveil.content
===
RCS file: /cvs/ports/www/mozilla-firefox/files/unveil.content,v
retrieving revision 1.3
diff -u -p -r1.3 unveil.content
--- mozilla-firefox/files/unveil.content13 Sep 2020 06:34:08 -  
1.3
+++ mozilla-firefox/files/unveil.content11 Feb 2021 23:21:04 -
@@ -1,5 +1,6 @@
 # $OpenBSD: unveil.content,v 1.3 2020/09/13 06:34:08 landry Exp $
 /dev/drm0 rw
+/dev/dri/card0 rw
 
 /etc/fonts r
 /etc/machine-id r
Index: mozilla-firefox/files/unveil.gpu
===
RCS file: /cvs/ports/www/mozilla-firefox/files/unveil.gpu,v
retrieving revision 1.4
diff -u -p -r1.4 unveil.gpu
--- mozilla-firefox/files/unveil.gpu15 Jan 2021 11:00:50 -  1.4
+++ mozilla-firefox/files/unveil.gpu11 Feb 2021 23:21:22 -
@@ -1,5 +1,6 @@
 # $OpenBSD: unveil.gpu,v 1.4 2021/01/15 11:00:50 sthen Exp $
 /dev/drm0 rw
+/dev/dri/card0 rw
 
 /usr/local/lib/firefox r
 /usr/local/lib/gdk-pixbuf-2.0 r
Index: mozilla-firefox/files/unveil.main
===
RCS file: /cvs/ports/www/mozilla-firefox/files/unveil.main,v
retrieving revision 1.7
diff -u -p -r1.7 unveil.main
--- mozilla-firefox/files/unveil.main   15 Jan 2021 11:00:50 -  1.7
+++ mozilla-firefox/files/unveil.main   11 Feb 2021 23:21:48 -
@@ -6,6 +6,7 @@
 /dev/fido rw
 # for webgl info in about:support
 /dev/drm0 rw
+/dev/dri/card0 rw
 /usr/lib r
 
 /etc/fonts r
Index: firefox-esr/Makefile
===
RCS file: /cvs/ports/www/firefox-esr/Makefile,v
retrieving revision 1.141
diff -u -p -r1.141 Makefile
--- firefox-esr/Makefile26 Jan 2021 15:54:32 -  1.141
+++ firefox-esr/Makefile11 Feb 2021 23:24:51 -
@@ -8,6 +8,7 @@ MOZILLA_BRANCH =release
 MOZILLA_PROJECT =  firefox-esr
 MOZILLA_CODENAME = browser
 MOZILLA_DIST = firefox
+REVISION = 0
 
 WRKDIST =  ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/esr//}
 HOMEPAGE = https://www.mozilla.org/firefox/organizations/
Index: firefox-esr/files/unveil.content
===
RCS file: /cvs/ports/www/firefox-esr/files/unveil.content,v
retrieving revision 1.2
diff -u -p -r1.2 unveil.content
--- firefox-esr/files/unveil.content25 Aug 2020 13:19:08 -  1.2
+++ firefox-esr/files/unveil.content11 Feb 2021 23:24:20 -
@@ -1,5 +1,6 @@
 # $OpenBSD: unveil.content,v 1.2 2020/08/25 13:19:08 landry Exp $
 /dev/drm0 rw
+/dev/dri/card0 rw
 
 /etc/fonts r
 /etc/machine-id r
Index: firefox-esr/files/unveil.gpu
===
RCS file: /cvs/ports/www/firefox-esr/files/unveil.gpu,v
retrieving revision 1.2
diff -u -p -r1.2 unveil.gpu
--- firefox-esr/files/unveil.gpu15 Jan 2021 11:00:50 -  1.2
+++ firefox-esr/files/unveil.gpu11 Feb 2021 23:24:28 -
@@ -1,5 +1,6 @@
 # $OpenBSD: unveil.gpu,v 1.2 2021/01/15 11:00:50 sthen Exp $
 /dev/drm0 rw
+/dev/dri/card0 rw
 
 /usr/local/lib/firefox-esr r
 /usr/local/lib/gdk-pixbuf-2.0 r
Index: tor-browser/browser/Makefile
===
RCS file: /cvs/ports/www/tor-browser/browser/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
--- tor-browser/browser/Makefile31 Jan 2021 11:54:21 -  1.57
+++ tor-browser/browser/Makefile11 Feb 2021 23:26:04 -
@@ -11,7 +11,7 @@ MOZILLA_PROJECT = ${BROWSER_NAME}
 MOZILLA_CODENAME = browser
 TL_VERSION =   0.2.26
 HE_VERSION =   2020.11.17
-REVISION = 0
+REVISION = 1
 
 EXTRACT_SUFX = .tar.xz
 PATCHORIG =.pat.orig
Index: tor-browser/browser/files/unveil.content
===
RCS file: /cvs/ports/www/tor-browser/browser/files/

Re: NEW: games/crispy-doom

[Jonathan Gray]

On Wed, Feb 10, 2021 at 11:12:17PM -0800, Ryan Freeman wrote:
> Here is a shot at a port for crispy-doom, I adapted off the
> chocolate-doom port.  builds and runs fine here on amd64.
> 
> provides a 'medium-ground' Doom experience:
> - can double the resolution for a 640x400 'crisp' experience
> - has support for non-4:3 screens, even in low resolution mode
> - new fullscreen hud options
> - static limit removal, play larger maps without crashing
> - various other 'crisp' features
> 
> Also supports Heretic.
> 
> Comments? OK?
> 
> -ryan

The python usage does not require python2 so we should use python3.
It seems some parts are missing from the PLIST?

--- Makefile.orig   Thu Feb 11 18:20:06 2021
+++ MakefileThu Feb 11 18:56:50 2021
@@ -11,8 +11,6 @@ MAINTAINER =  Ryan Freeman 
 # GPLv2+
 PERMIT_PACKAGE =   Yes
 
-#MODULES = devel/cmake
-
 WANTLIB += SDL2 SDL2_mixer SDL2_net c m png samplerate z
 
 LIB_DEPENDS =  devel/sdl2-mixer \
@@ -31,21 +29,16 @@ AUTOCONF_VERSION =  2.69
 CONFIGURE_ARGS +=  --mandir="${LOCALBASE}/man"
 
 # python just used for generating manpages
-BUILD_DEPENDS =lang/python/2.7
+MODULES =  lang/python
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
+MODPY_RUNDEP = No
 
 WRKDIST =  ${WRKDIR}/crispy-doom-${DISTNAME}
 
 post-extract:
# set correct data directory
@sed -i 's,"/games/doom","/doom",g' ${WRKSRC}/src/d_iwad.c
-   # set correct python binary name
-   @sed -i 's/HAVE_PYTHON, python/HAVE_PYTHON, python2/' \
-   ${WRKSRC}/configure.ac
-   @sed -i 's,/usr/bin/env python,/usr/bin/env python2,' \
-   ${WRKSRC}/man/docgen
-   @sed -i 's,/usr/bin/env python,/usr/bin/env python2,' \
-   ${WRKSRC}/man/simplecpp
- 
+
 post-install:
# Data files get installed to this directory.
${INSTALL_DATA_DIR} ${PREFIX}/share/doom/
--- pkg/PLIST.orig  Thu Feb 11 17:16:21 2021
+++ pkg/PLIST   Thu Feb 11 18:47:17 2021
@@ -4,19 +4,34 @@
 @bin bin/crispy-heretic
 @bin bin/crispy-heretic-setup
 @bin bin/crispy-server
+@man man/man5/crispy-doom.cfg.5
+@man man/man5/crispy-heretic.cfg.5
+@man man/man5/default.cfg.5
+@man man/man5/heretic.cfg.5
+@man man/man6/crispy-doom-setup.6
+@man man/man6/crispy-doom.6
+@man man/man6/crispy-heretic-setup.6
+@man man/man6/crispy-heretic.6
 share/applications/io.github.fabiangreffrath.Doom.desktop
 share/applications/io.github.fabiangreffrath.Heretic.desktop
 share/applications/io.github.fabiangreffrath.Setup.desktop
 share/applications/screensavers/
 
share/applications/screensavers/io.github.fabiangreffrath.Doom_Screensaver.desktop
+share/bash-completion/completions/crispy-doom
+share/bash-completion/completions/crispy-heretic
 share/doc/crispy-doom/
+share/doc/crispy-doom/CMDLINE.doom
 share/doc/crispy-doom/COPYING.md
 share/doc/crispy-doom/ChangeLog
+share/doc/crispy-doom/INSTALL.doom
 share/doc/crispy-doom/NEWS.md
 share/doc/crispy-doom/NOT-BUGS.md
 share/doc/crispy-doom/PHILOSOPHY.md
 share/doc/crispy-doom/README.Music.md
 share/doc/crispy-doom/README.md
+share/doc/crispy-heretic/
+share/doc/crispy-heretic/CMDLINE.heretic
+share/doc/crispy-heretic/INSTALL.heretic
 share/doc/pkg-readmes/${PKGSTEM}
 share/doom/
 share/icons/hicolor/128x128/apps/crispy-doom.png

Re: [PATCH] Fix security/p0f -fno-common

[Jonathan Gray]

On Tue, Feb 09, 2021 at 11:05:15PM -0800, Greg Steuck wrote:
> I can be talked into removing it as we already have p0f3...

The earlier one is for the format used by pf.os(5) and tcpdump(8)

> 
> OK?

ok jsg@

> 
> From: Greg Steuck 
> Subject: [PATCH] Fix security/p0f -fno-common
> 
> Bonus fix for memset size mismatch noted by clang
> ---
>  security/p0f/Makefile  |  2 +-
>  security/p0f/patches/patch-p0f-query_c | 29 ++
>  2 files changed, 30 insertions(+), 1 deletion(-)
>  create mode 100644 security/p0f/patches/patch-p0f-query_c
> 
> diff --git security/p0f/Makefile security/p0f/Makefile
> index 36391604eb6..d10523527e4 100644
> --- security/p0f/Makefile
> +++ security/p0f/Makefile
> @@ -3,7 +3,7 @@
>  COMMENT= passive OS fingerprinting tool
>  
>  DISTNAME=p0f-2.0.8
> -REVISION =   2
> +REVISION =   3
>  EXTRACT_SUFX=.tgz
>  CATEGORIES=  security net
>  
> diff --git security/p0f/patches/patch-p0f-query_c 
> security/p0f/patches/patch-p0f-query_c
> new file mode 100644
> index 000..ae6b8afa717
> --- /dev/null
> +++ security/p0f/patches/patch-p0f-query_c
> @@ -0,0 +1,29 @@
> +$OpenBSD$
> +
> +-fno-common
> +
> +Fix memset size mismatch
> +
> +Index: p0f-query.c
> +--- p0f-query.c.orig
>  p0f-query.c
> +@@ -46,8 +46,8 @@ static _u16 flags;
> + static _s16 score = NO_SCORE;
> + 
> + /* Imports for statistics */
> +-_u32 packet_count, matched_packets, st_time, file_cksum;
> +-_u8  operating_mode;
> ++extern _u32 packet_count, matched_packets, st_time, file_cksum;
> ++extern _u8  operating_mode;
> + 
> + #define SAD_HASH(a) a) << 16) ^ ((a) << 8) ^ (a)))
> + 
> +@@ -74,7 +74,7 @@ void p0f_addcache(_u32 saddr,_u32 daddr,_u16 sport,_u1
> +   cur->dad   = daddr;
> +   cur->ports = (sport << 16) + dport;
> + 
> +-  memset(sc,0,sizeof(sc));
> ++  memset(sc,0,sizeof(*sc));
> +   if (genre) {
> + strncpy(sc->genre,genre,19);
> + strncpy(sc->detail,detail,39);
> -- 
> 2.30.0
> 
> 

Re: -fno-common update: broken ports

[Jonathan Gray]

On Tue, Feb 09, 2021 at 07:20:25PM -0800, Jeremy Evans wrote:
> On Tue, Feb 9, 2021 at 7:08 PM Ryan Freeman  wrote:
> 
> > On Fri, Feb 05, 2021 at 10:42:49AM +, Stuart Henderson wrote:
> > > Updated list, with the dependent ports listed (which may or may not
> > > be broken, but can't be built until the parent is fixed) It's gradually.
> > > shrinking, and the majority of these are edge ports now.
> >
> > ...snip...
> >
> > > games/prboom
> >
> > I will propose a diff to remove games/prboom, discontinued, last update
> > 2008
> >
> > > games/prboom-plus
> >
> > This one seems to have moved to a git repo:
> > https://github.com/coelckers/prboom-plus
> >
> > Actively updating prboom-plus port to use this, then I'll work through what
> > FreeBSD did for -fno-common
> >
> >
> By coincidence, I just updated both prboom and prboom-plus using FreeBSD's
> patches.
> 
> No opposition to removing prboom, though it did work when I used it last
> year.
> 
> Thanks,
> Jeremy

I'm also fine with removing it.  For a limit removing port that doesn't
go to the extremes of gzdoom I'd rather see crispy doom.

Re: [New] libva-intel-media-driver port

[Jonathan Gray]

On Tue, Feb 09, 2021 at 11:08:15AM +, Stuart Henderson wrote:
> Quick comments from a read-through, I have not tried building:
> 
> 
> ports fetching from github /archive/ URLs should use GH_* variables
> not MASTER_DISTES - see ports/infrastructure/Makefile.template
> 
> the patches directory should be generated with "make update-patches",
> don't split patches between patches/ and files/
> 
> DESCR should describe what it does and should not just be a copy
> of COMMENT
> 
> leave out MAINTAINER completely if you aren't going to set it to
> yourself
> 
> the library should be generated directly with ports versioning,
> no symlinks
> 
> instead of setting PORT_LIB_MAJOR/PORT_LIB_MINOR, take it from
> the SHARED_LIBS setting by using ${LIBigdgmm_VERSION:R} for major
> and ${LIBigdgmm_VERSION:E} for minor
> 
> see other ports or Makefile.template for the expected style
> for CONFIGURE_ARGS / LIB_DEPENDS (one per line) and WANTLIB
> (not one per line), don't use "c++" in WANTLIB that is covered
> by COMPILER_LIBCXX, there is no such thing as COMPILER_LIBC

See previous libva discussions.  If it is to support more than just
Intel it needs to be in xenocara and new Mesa Makefiles will need to be
written.

That would also be the case to use gallium-va with the iris
Mesa driver for Intel >= gen8.

Re: sparc64 bulk build report

[Jonathan Gray]

On Fri, Feb 05, 2021 at 09:05:00PM -0700, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
> 
> Started : Wed Feb  3 10:37:14 MST 2021
> Finished: Fri Feb  5 21:04:45 MST 2021
> Duration: 2 Days 10 hours 28 minutes
> 
> Built using OpenBSD 6.8-current (GENERIC.MP) #668: Tue Feb  2 12:51:08 MST 
> 2021
> 
> Built 9389 packages
> 
> Number of packages built each day:
> Feb 3: 7244
> Feb 4: 1244
> Feb 5: 901
> 
> 
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/summary.log
> 
> Build failures: 23
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/comms/syncterm.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/devel/dtc.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/devel/glog.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/devel/keystone/python,python3.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/devel/spidermonkey78.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/emulators/emulationstation.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/games/frotz.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/games/odamex.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/games/openxcom.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/geo/spatialite/gui.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/graphics/exiv2.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/graphics/inkscape.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/math/mlpack,-main.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/math/py-scipy,python3.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/multimedia/gstreamer-0.10/plugins-bad,-main.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/net/barrier.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/net/libsignal-protocol-c.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/print/gutenprint.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/productivity/gnucash.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/sysutils/libvirt.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/x11/grantlee-qt5.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/x11/i3-mousedrag.log
> http://build-failures.rhaalovely.net/sparc64/2021-02-03/x11/roxterm.log
> 
> Recurrent failures:
>  failures/comms/syncterm.log
>  failures/devel/glog.log
>  failures/devel/keystone/python,python3.log
>  failures/devel/spidermonkey78.log
>  failures/games/frotz.log
>  failures/games/odamex.log
>  failures/games/openxcom.log
>  failures/graphics/exiv2.log
>  failures/graphics/inkscape.log
>  failures/math/mlpack,-main.log
>  failures/multimedia/gstreamer-0.10/plugins-bad,-main.log
>  failures/net/barrier.log
>  failures/print/gutenprint.log
>  failures/productivity/gnucash.log
>  failures/sysutils/libvirt.log
>  failures/x11/grantlee-qt5.log
>  failures/x11/roxterm.log
> 
> New failures:
> +failures/devel/dtc.log

gnu_printf requires gcc >= 4.4.0
https://gcc.gnu.org/legacy-ml/gcc-help/2012-02/msg00225.html

Index: patches/patch-util_h
===
RCS file: patches/patch-util_h
diff -N patches/patch-util_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-util_h6 Feb 2021 04:32:40 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+gnu_printf requires gcc >= 4.4.0
+
+Index: util.h
+--- util.h.orig
 util.h
+@@ -12,10 +12,10 @@
+  */
+ 
+ #ifdef __GNUC__
+-#ifdef __clang__
+-#define PRINTF(i, j)  __attribute__((format (printf, i, j)))
+-#else
++#if __GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4)
+ #define PRINTF(i, j)  __attribute__((format (gnu_printf, i, j)))
++#else
++#define PRINTF(i, j)  __attribute__((format (printf, i, j)))
+ #endif
+ #define NORETURN  __attribute__((noreturn))
+ #else

Re: Comms/minicom -fno-common

[Jonathan Gray]

On Fri, Feb 05, 2021 at 08:45:59PM +0100, Thaison Nguyen wrote:
> This should fix -fno-common with minicom.
> Taken the diff from the FreeBSD people.
> 
> Tested on amd64 with a ftdi usb to serial thingy.
> 
> OK?
> 

While not in the same place as the 2.7.1 distfile there is a 2.8 release
which includes some -fno-common changes

does it still work with this?

Index: Makefile
===
RCS file: /cvs/ports/comms/minicom/Makefile,v
retrieving revision 1.67
diff -u -p -r1.67 Makefile
--- Makefile20 Mar 2020 16:44:21 -  1.67
+++ Makefile6 Feb 2021 00:04:20 -
@@ -2,10 +2,9 @@
 
 COMMENT=   MS-DOS Telix-like serial communication program
 
-DISTNAME=  minicom-2.7.1
-REVISION=  3
+DISTNAME=  minicom-2.8
 CATEGORIES=comms
-MASTER_SITES=  https://alioth-archive.debian.org/releases/minicom/Source/2.7.1/
+MASTER_SITES=  https://salsa.debian.org/minicom-team/minicom/-/archive/2.8/
 
 HOMEPAGE=  https://salsa.debian.org/minicom-team/minicom
 
Index: distinfo
===
RCS file: /cvs/ports/comms/minicom/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo18 Apr 2017 21:05:09 -  1.10
+++ distinfo6 Feb 2021 00:04:20 -
@@ -1,2 +1,2 @@
-SHA256 (minicom-2.7.1.tar.gz) = Uy+Da3pnfrDLHcqNcDArc3KcPTDfJtWDaNcS5cygQfE=
-SIZE (minicom-2.7.1.tar.gz) = 875939
+SHA256 (minicom-2.8.tar.gz) = no3ujn4fbWEV0OGVXaW4AeRLkSifaz4yCEKUlIjUsi8=
+SIZE (minicom-2.8.tar.gz) = 948015
Index: patches/patch-man_minicom_1
===
RCS file: /cvs/ports/comms/minicom/patches/patch-man_minicom_1,v
retrieving revision 1.6
diff -u -p -r1.6 patch-man_minicom_1
--- patches/patch-man_minicom_1 6 May 2017 21:57:27 -   1.6
+++ patches/patch-man_minicom_1 6 Feb 2021 00:04:20 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-man_minicom_1,v 1.6 2017
 Index: man/minicom.1
 --- man/minicom.1.orig
 +++ man/minicom.1
-@@ -842,7 +842,8 @@ $HOME/minicom.log
+@@ -862,7 +862,8 @@ $HOME/minicom.log
  /usr/share/locale/*/LC_MESSAGES/minicom.mo
  .fi
  .SH SEE ALSO
Index: patches/patch-src_main_c
===
RCS file: /cvs/ports/comms/minicom/patches/patch-src_main_c,v
retrieving revision 1.7
diff -u -p -r1.7 patch-src_main_c
--- patches/patch-src_main_c6 May 2017 22:00:53 -   1.7
+++ patches/patch-src_main_c6 Feb 2021 00:04:20 -
@@ -13,7 +13,7 @@ Index: src/main.c
  #include "port.h"
  #include "minicom.h"
  #include "intl.h"
-@@ -333,6 +336,17 @@ nolock:
+@@ -416,6 +419,17 @@ nolock:
/* Set CLOCAL mode */
m_nohang(portfd);
  
@@ -31,7 +31,7 @@ Index: src/main.c
/* Set Hangup on Close if program crashes. (Hehe) */
m_hupcl(portfd, 1);
if (doinit > 0)
-@@ -553,9 +567,10 @@ static void show_status_fmt(const char *fmt)
+@@ -641,9 +655,10 @@ static void show_status_fmt(const char *fmt)
  bufi += snprintf(buf + bufi, COLS - bufi, "%s",
   P_HASDCD[0] == 'Y' ? _("Offline") : 
_("OFFLINE"));
else
Index: patches/patch-src_minicom_c
===
RCS file: patches/patch-src_minicom_c
diff -N patches/patch-src_minicom_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_minicom_c 6 Feb 2021 00:04:20 -
@@ -0,0 +1,24 @@
+$OpenBSD$
+
+Index: src/minicom.c
+--- src/minicom.c.orig
 src/minicom.c
+@@ -1107,6 +1107,7 @@ int main(int argc, char **argv)
+   char *remote_charset = NULL;  /* Remote charset given on the command line 
via -R */
+   char pseudo[64];
+   /* char* console_encoding = getenv ("LC_CTYPE"); */
++  sigset_t set;
+ 
+   enum {
+ OPT_CAP_BUF_MODE = 256,
+@@ -1544,7 +1545,9 @@ int main(int argc, char **argv)
+ #endif
+ 
+   /* On some Linux systems SIGALRM is masked by default. Unmask it */  
+-  sigrelse(SIGALRM);
++  if (sigemptyset(&set) != -1 &&
++  sigaddset(&set, SIGALRM) != -1)
++sigprocmask(SIG_UNBLOCK, &set, NULL);
+ 
+   keyboard(KINSTALL, 0);
+ 
Index: patches/patch-src_script_c
===
RCS file: /cvs/ports/comms/minicom/patches/patch-src_script_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_script_c
--- patches/patch-src_script_c  6 May 2017 21:57:27 -   1.2
+++ patches/patch-src_script_c  6 Feb 2021 00:04:20 -
@@ -1,16 +1,21 @@
-$OpenBSD: patch-src_script_c,v 1.2 2017/05/06 21:57:27 sthen Exp $
+$OpenBSD$
 
 Index: src/script.c
 --- src/script.c.orig
 +++ src/script.c
-@@ -32,6 +32,10 @@
- #include 
+@@ -1089,11 +1089,14 @@ void do_args(int argc, char **argv)
+ int main(int argc, char **argv)
+ {
+   char *s;
++  sigset_t set;
+ #if 0 /* Shouldn't need this.. */
+   signal(SIGHUP, SIG_IGN);
  #endif
+   /* On some Linux systems SIGALRM is masked by default. Unmask it */  
+-  sigrelse(SIG

graphics/tumble -fno-common

[Jonathan Gray]

no newer release or upstream fix

Index: Makefile
===
RCS file: /cvs/ports/graphics/tumble/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile25 Apr 2020 14:02:14 -  1.1.1.1
+++ Makefile1 Feb 2021 06:03:42 -
@@ -8,6 +8,7 @@ COMMENT =   convert pictures into pdf book
 GH_PROJECT =   tumble
 GH_ACCOUNT =   brouhaha
 GH_TAGNAME =   v0.36
+REVISION = 0
 
 CATEGORIES =   graphics textproc
 
Index: patches/patch-semantics_c
===
RCS file: patches/patch-semantics_c
diff -N patches/patch-semantics_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-semantics_c   1 Feb 2021 06:03:42 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+fix -fno-common build
+
+Index: semantics.c
+--- semantics.c.orig
 semantics.c
+@@ -119,7 +119,7 @@ typedef struct output_page_t
+ #endif
+ 
+ 
+-FILE *yyin;
++extern FILE *yyin;
+ int line;  /* line number in spec file */
+ 
+ int bookmark_level;
Index: patches/patch-tumble_input_h
===
RCS file: patches/patch-tumble_input_h
diff -N patches/patch-tumble_input_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-tumble_input_h1 Feb 2021 06:03:42 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+fix -fno-common build
+
+Index: tumble_input.h
+--- tumble_input.h.orig
 tumble_input.h
+@@ -71,4 +71,4 @@ void init_jpeg_handler (void);
+ void init_pbm_handler  (void);
+ void init_png_handler  (void);
+ 
+-input_handler_t blank_handler;
++extern input_handler_t blank_handler;

Re: Remove net/lxnb

[Jonathan Gray]

On Mon, Feb 01, 2021 at 01:29:46AM +0100, Klemens Nanni wrote:
> That's a NetBus 1.6 client... upstream's dead as in NXDOMAIN, we seem to
> be the only folks still packaging it.
> 
> Can we remove this port that hasn't changed in twenty years and
> basically only exists to screw around with old old Windows boxes which
> actually have the server running?
> 
> Fails with `-fno-common'.
> OK?
> 

it is security/lxnb not net/lxnb

ok jsg@ to remove

Re: games/ace: -fno-common fix

[Jonathan Gray]

On Sun, Jan 31, 2021 at 01:30:19PM +0100, Charlene Wendling wrote:
> Hi,
> 
> This fix has been taken from FreeBSD [0]. check_sym reports no dynamic
> change. This has been built and tested successfully on macppc and amd64.
> 
> OK? 

Is a revision bump strictly needed for this?

ok jsg@

> 
> Charlène. 
> 
> 
> [0]  https://github.com/freebsd/freebsd-ports/commit/53cdc659
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/ace/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile  2 Oct 2019 21:11:08 -   1.5
> +++ Makefile  31 Jan 2021 12:18:00 -
> @@ -3,7 +3,7 @@
>  COMMENT =solitaire games
>  
>  DISTNAME =   ace-1.4
> -REVISION =   1
> +REVISION =   2
>  
>  SHARED_LIBS +=  cards 0.0 # 1.0
>  
> Index: patches/patch-lib_table_c
> ===
> RCS file: patches/patch-lib_table_c
> diff -N patches/patch-lib_table_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_table_c 31 Jan 2021 12:18:00 -
> @@ -0,0 +1,16 @@
> +$OpenBSD$
> +
> +Fix the build with -fno-common
> +
> +Index: lib/table.c
> +--- lib/table.c.orig
>  lib/table.c
> +@@ -57,7 +57,7 @@ static int ex=0, ey=0, ew=0, eh=0;
> + static int graphics_disabled = 1;
> + 
> + OptionDesc *app_options;
> +-OptionDesc *xwin_options;
> ++extern OptionDesc *xwin_options;
> + static OptionDesc *options[5];
> + 
> + static OptionDesc ace_options[] = {
> 
> 

audio/speech-dispatcher -fno-common

[Jonathan Gray]

update speech-dispatcher to fix -fno-common build

this is used by x11/gnome/orca and x11/qt5/qtspeech
which are in turn used by quite a few other ports

$ show-reverse-deps audio/speech-dispatcher | wc -l 
 264

/tmp/libspeechd.so.2.1 --> /usr/local/lib/libspeechd.so.2.2
Dynamic export changes:
added:
spd_get_client_id

Index: Makefile
===
RCS file: /cvs/ports/audio/speech-dispatcher/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- Makefile3 Jul 2020 21:12:35 -   1.31
+++ Makefile31 Jan 2021 06:42:40 -
@@ -2,11 +2,10 @@
 
 COMMENT=   common interface to speech synthesis
 
-V= 0.9.1
+V= 0.10.2
 DISTNAME=  speech-dispatcher-${V}
-REVISION=  0
 
-SHARED_LIBS +=  speechd  2.1  # .8.0
+SHARED_LIBS +=  speechd  2.2  # .10.2
 
 CATEGORIES=audio
 
Index: distinfo
===
RCS file: /cvs/ports/audio/speech-dispatcher/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo16 May 2020 12:00:07 -  1.10
+++ distinfo31 Jan 2021 06:42:40 -
@@ -1,2 +1,2 @@
-SHA256 (speech-dispatcher-0.9.1.tar.gz) = 
N8BA45w6yNp1XUkByTt2Zv20yFhW/fXm0VnnaaEob5k=
-SIZE (speech-dispatcher-0.9.1.tar.gz) = 166
+SHA256 (speech-dispatcher-0.10.2.tar.gz) = 
sGMZ8gHhXlbGKWZTr1vPwwDLNI6XLVF9+LBurHfq4tw=
+SIZE (speech-dispatcher-0.10.2.tar.gz) = 4431520
Index: patches/patch-src_modules_module_utils_h
===
RCS file: patches/patch-src_modules_module_utils_h
diff -N patches/patch-src_modules_module_utils_h
--- patches/patch-src_modules_module_utils_h16 May 2020 12:00:07 -  
1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-src_modules_module_utils_h,v 1.1 2020/05/16 12:00:07 ajacoutot 
Exp $
-
-error: invalid suffix on literal;
-C++11 requires a space between literal and identifier 
[-Wreserved-user-defined-literal]
-
-Index: src/modules/module_utils.h
 src/modules/module_utils.h.orig
-+++ src/modules/module_utils.h
-@@ -122,10 +122,10 @@ const char *module_name;
- } while(0)
- 
- #define FATAL(msg) do { \
--  fprintf(stderr, "FATAL ERROR in output module [%s:%d]:\n   
"msg, \
-+  fprintf(stderr, "FATAL ERROR in output module [%s:%d]:\n   " 
msg, \
-   __FILE__, __LINE__); \
-   if (Debug > 1) \
--  fprintf(CustomDebugFile, "FATAL ERROR in output module 
[%s:%d]:\n   "msg,   \
-+  fprintf(CustomDebugFile, "FATAL ERROR in output module 
[%s:%d]:\n   " msg,  \
-   __FILE__, __LINE__); \
-   exit(EXIT_FAILURE); \
- } while (0)
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/speech-dispatcher/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST   16 May 2020 12:00:08 -  1.9
+++ pkg/PLIST   31 Jan 2021 06:42:42 -
@@ -52,6 +52,7 @@ lib/speech-dispatcher-modules/
 @bin lib/speech-dispatcher-modules/sd_generic
 @bin lib/speech-dispatcher-modules/sd_ibmtts
 @bin lib/speech-dispatcher-modules/sd_kali
+@bin lib/speech-dispatcher-modules/sd_voxin
 @so lib/speech-dispatcher/spd_libao.so
 share/examples/speech-dispatcher/
 share/examples/speech-dispatcher/speech-dispatcher/
@@ -69,8 +70,6 @@ share/examples/speech-dispatcher/speech-
 @sample ${SYSCONFDIR}/speech-dispatcher/modules/dtk-generic.conf
 share/examples/speech-dispatcher/speech-dispatcher/modules/epos-generic.conf
 @sample ${SYSCONFDIR}/speech-dispatcher/modules/epos-generic.conf
-share/examples/speech-dispatcher/speech-dispatcher/modules/espeak-generic.conf
-@sample ${SYSCONFDIR}/speech-dispatcher/modules/espeak-generic.conf
 
share/examples/speech-dispatcher/speech-dispatcher/modules/espeak-mbrola-generic.conf
 @sample ${SYSCONFDIR}/speech-dispatcher/modules/espeak-mbrola-generic.conf
 
share/examples/speech-dispatcher/speech-dispatcher/modules/espeak-ng-mbrola-generic.conf
@@ -88,15 +87,22 @@ share/examples/speech-dispatcher/speech-
 share/examples/speech-dispatcher/speech-dispatcher/modules/kali.conf
 
share/examples/speech-dispatcher/speech-dispatcher/modules/llia_phon-generic.conf
 @sample ${SYSCONFDIR}/speech-dispatcher/modules/llia_phon-generic.conf
-share/examples/speech-dispatcher/speech-dispatcher/modules/mary-generic.conf
-share/examples/speech-dispatcher/speech-dispatcher/modules/pico-generic.conf
+share/examples/speech-dispatcher/speech-dispatcher/modules/mary-generic-disabled.conf
 share/examples/speech-dispatcher/speech-dispatcher/modules/swift-generic.conf
 @sample ${SYSCONFDIR}/speech-dispatcher/modules/swift-generic.conf
+share/examples/speech-dispatcher/speech-dispatcher/modules/voxin.conf
 share/examples/speech-dispatcher/speech-dispatcher/speechd.conf
 @sample

security/libsrtp -fno-common

[Jonathan Gray]

https://github.com/cisco/libsrtp/commit/716a73862b387a2107f37398c0fb7d9a754c0ccd.patch

/tmp/libsrtp2.so.1.0 --> /usr/local/lib/libsrtp2.so.2.0
Dynamic export changes:
removed:
bit_string

Index: Makefile
===
RCS file: /cvs/ports/security/libsrtp/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile3 Feb 2020 20:40:40 -   1.12
+++ Makefile31 Jan 2021 05:31:09 -
@@ -1,13 +1,13 @@
 # $OpenBSD: Makefile,v 1.12 2020/02/03 20:40:40 sthen Exp $
 
-SHARED_LIBS +=  srtp2 1.0 # 0.0
+SHARED_LIBS +=  srtp2 2.0 # 0.0
 
 COMMENT=   secure RTP library
 
 GH_ACCOUNT=cisco
 GH_PROJECT=libsrtp
 GH_TAGNAME=v2.3.0
-REVISION=  0
+REVISION=  1
 
 CATEGORIES=security telephony
 
Index: patches/patch-crypto_math_datatypes_c
===
RCS file: patches/patch-crypto_math_datatypes_c
diff -N patches/patch-crypto_math_datatypes_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-crypto_math_datatypes_c   31 Jan 2021 05:31:09 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix building with gcc-10
+716a73862b387a2107f37398c0fb7d9a754c0ccd
+
+Index: crypto/math/datatypes.c
+--- crypto/math/datatypes.c.orig
 crypto/math/datatypes.c
+@@ -79,7 +79,7 @@ int octet_get_weight(uint8_t octet)
+ 
+ /* the value MAX_PRINT_STRING_LEN is defined in datatypes.h */
+ 
+-char bit_string[MAX_PRINT_STRING_LEN];
++static char bit_string[MAX_PRINT_STRING_LEN];
+ 
+ uint8_t srtp_nibble_to_hex_char(uint8_t nibble)
+ {
Index: patches/patch-test_util_c
===
RCS file: patches/patch-test_util_c
diff -N patches/patch-test_util_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-test_util_c   31 Jan 2021 05:31:09 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix building with gcc-10
+716a73862b387a2107f37398c0fb7d9a754c0ccd
+
+Index: test/util.c
+--- test/util.c.orig
 test/util.c
+@@ -49,7 +49,7 @@
+ #include 
+ 
+ /* include space for null terminator */
+-char bit_string[MAX_PRINT_STRING_LEN + 1];
++static char bit_string[MAX_PRINT_STRING_LEN + 1];
+ 
+ static inline int hex_char_to_nibble(uint8_t c)
+ {

devel/boehm-gc -fno-common

[Jonathan Gray]

https://github.com/ivmai/bdwgc/commit/808af929bf55cd2b31e354f1903e182b151e8668.patch

Index: patches/patch-include_private_gc_priv_h
===
RCS file: patches/patch-include_private_gc_priv_h
diff -N patches/patch-include_private_gc_priv_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-include_private_gc_priv_h 31 Jan 2021 05:00:46 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix GC_jmp_buf multiple definition
+808af929bf55cd2b31e354f1903e182b151e8668
+
+Index: include/private/gc_priv.h
+--- include/private/gc_priv.h.orig
 include/private/gc_priv.h
+@@ -2515,7 +2515,7 @@ GC_INNER ptr_t GC_store_debug_info(ptr_t p, word sz, c
+ 
+ #if defined(NEED_FIND_LIMIT) \
+  || (defined(USE_PROC_FOR_LIBRARIES) && defined(THREADS))
+-  JMP_BUF GC_jmp_buf;
++  GC_EXTERN JMP_BUF GC_jmp_buf;
+ 
+   /* Set up a handler for address faults which will longjmp to  */
+   /* GC_jmp_buf;*/
Index: patches/patch-os_dep_c
===
RCS file: patches/patch-os_dep_c
diff -N patches/patch-os_dep_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-os_dep_c  31 Jan 2021 05:00:46 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix GC_jmp_buf multiple definition
+808af929bf55cd2b31e354f1903e182b151e8668
+
+Index: os_dep.c
+--- os_dep.c.orig
 os_dep.c
+@@ -897,6 +897,8 @@ GC_INNER word GC_page_size = 0;
+   /* Some tools to implement HEURISTIC2 */
+ #   define MIN_PAGE_SIZE 256/* Smallest conceivable page size, bytes */
+ 
++GC_INNER JMP_BUF GC_jmp_buf;
++
+ STATIC void GC_fault_handler(int sig GC_ATTR_UNUSED)
+ {
+ LONGJMP(GC_jmp_buf, 1);

Re: update piglit to a newer snapshot

[Jonathan Gray]

On Sun, Jan 31, 2021 at 03:40:33AM +0100, Klemens Nanni wrote:
> On Sat, Jan 30, 2021 at 03:19:04PM +1100, Jonathan Gray wrote:
> > Update piglit to a newer snapshot and switch to python3.
> > Fixes -fno-common build.
> > 
> > Tested with the "quick" tests on a broadwell machine with Mesa 20.0.8.
> You could also commit the update only and leave the python3 conversion
> to another commit, that should make review/testing easier and we don't
> have the non-trivial python3 bits out of the way fixing `-fno-common'.
> 

upstream support for python2 no longer exists
https://gitlab.freedesktop.org/mesa/piglit/-/commit/19eb8323c8c96b786520d2e57741ae9e96be740c

Re: Update arm-none-eabi binutils to 2.31.1

[Jonathan Gray]

On Sat, Jan 30, 2021 at 04:45:01PM +0100, Mark Kettenis wrote:
> U-Boot targets that use the CONFIG_POSITION_INDEPENDENT and
> CONFIG_LINUX_KERNEL_IMAGE_HEADER options don't build because they
> generate a relocation that binutils 2.30 doesn't like.  This is fixed
> in binutils 2.31.  Given that there is a 2.31.1 I updated to that one.
> 
> ok?

The existing targets which default to both are arm64 xen and tegra.

building the xenguest_arm64 target with binutils 2.30

  LD  u-boot
aarch64-none-elf-ld.bfd: arch/arm/cpu/armv8/start.o: relocation R_AARCH64_ABS32 
against `_kernel_offset_le_lo32' can not be used when making a shared object

builds with 2.31.1.

ok jsg@

Re: devel/dtc: Update to 1.6.0

[Jonathan Gray]

On Sat, Jan 30, 2021 at 12:25:59PM +0100, Klemens Nanni wrote:
> On Sat, Jan 30, 2021 at 04:59:33PM +1100, Jonathan Gray wrote:
> > On Fri, Jan 29, 2021 at 10:15:21PM +0100, Klemens Nanni wrote:
> > > The new version from 04.04.2020 fixes `-fno-common' builds.
> > > I sysutils/dtb already built on amd64 with this diff, the following
> > > consumers have yet to build-tested:
> > > 
> > >   $ show-reverse-deps devel/dtc
> > >   emulators/qemu
> > >   emulators/spike
> > >   sysutils/u-boot
> > >   sysutils/u-boot,aarch64
> > >   sysutils/u-boot,arm
> > > 
> > > Feedback? OK?
> > 
> > looks like at least a minor crank is needed
> > 
> > Dynamic export changes:
> > added:
> > fdt_header_size@@LIBFDT_1.2
> Thanks, I simply forgot checking that.
> 
> Here's with a minor crank.

No problems seen building

sysutils/dtb
emulators/spike
emulators/qemu
sysutils/u-boot,aarch64

ok jsg@

> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/dtc/Makefile,v
> retrieving revision 1.17
> diff -u -p -r1.17 Makefile
> --- Makefile  8 Dec 2019 09:55:37 -   1.17
> +++ Makefile  30 Jan 2021 11:23:22 -
> @@ -2,12 +2,12 @@
>  
>  COMMENT= Device Tree Compiler
>  
> -DISTNAME=dtc-1.5.1
> +DISTNAME=dtc-1.6.0
>  CATEGORIES=  sysutils devel
>  MASTER_SITES=https://www.kernel.org/pub/software/utils/dtc/
>  EXTRACT_SUFX=.tar.xz
>  
> -SHARED_LIBS= fdt 5.0
> +SHARED_LIBS= fdt 5.1
>  
>  # GPLv2
>  PERMIT_PACKAGE=  Yes
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/dtc/distinfo,v
> retrieving revision 1.7
> diff -u -p -r1.7 distinfo
> --- distinfo  8 Dec 2019 09:55:37 -   1.7
> +++ distinfo  29 Jan 2021 21:06:45 -
> @@ -1,2 +1,2 @@
> -SHA256 (dtc-1.5.1.tar.xz) = Zgt0A5aQ/DcBNmBUTQkZGDTvtYUDxzxVXFUTunWrAx8=
> -SIZE (dtc-1.5.1.tar.xz) = 155780
> +SHA256 (dtc-1.6.0.tar.xz) = EFA7AhfhsHkz4p6NNHoAAVskMb6l9Zr+C+068wNAyC0=
> +SIZE (dtc-1.6.0.tar.xz) = 158584
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/devel/dtc/patches/patch-Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 patch-Makefile
> --- patches/patch-Makefile8 Dec 2019 09:55:37 -   1.8
> +++ patches/patch-Makefile29 Jan 2021 21:07:59 -
> @@ -1,11 +1,13 @@
>  $OpenBSD: patch-Makefile,v 1.8 2019/12/08 09:55:37 ajacoutot Exp $
>  
> +Fix shared library versions.
> +
>  Index: Makefile
>  --- Makefile.orig
>  +++ Makefile
> -@@ -18,8 +18,8 @@ CONFIG_LOCALVERSION =
> +@@ -22,8 +22,8 @@ ASSUME_MASK ?= 0
>   
> - CPPFLAGS = -I libfdt -I .
> + CPPFLAGS = -I libfdt -I . -DFDT_ASSUME_MASK=$(ASSUME_MASK)
>   WARNINGS = -Wall -Wpointer-arith -Wcast-qual -Wnested-externs \
>  --Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wshadow
>  -CFLAGS = -g -Os $(SHAREDLIB_CFLAGS) -Werror $(WARNINGS) $(EXTRA_CFLAGS)
> @@ -14,7 +16,7 @@ Index: Makefile
>   
>   BISON = bison
>   LEX = flex
> -@@ -66,7 +66,7 @@ SHAREDLIB_LDFLAGS = -shared -Wl,--version-script=$(LIB
> +@@ -72,7 +72,7 @@ SHAREDLIB_LDFLAGS = -shared -Wl,--version-script=$(LIB
>   else
>   SHAREDLIB_EXT = so
>   SHAREDLIB_CFLAGS  = -fPIC
> @@ -23,7 +25,7 @@ Index: Makefile
>   endif
>   
>   #
> -@@ -151,7 +151,7 @@ all: $(BIN) libfdt
> +@@ -157,7 +157,7 @@ all: $(BIN) libfdt
>   check_python_deps = \
>   if $(PKG_CONFIG) --cflags $(PYTHON) >/dev/null 2>&1; then \
>   if which swig >/dev/null 2>&1; then \
> @@ -32,7 +34,7 @@ Index: Makefile
>   fi; \
>   fi; \
>   if [ "$${can_build}" = "yes" ]; then \
> -@@ -198,9 +198,8 @@ $(LIBFDT_archive): $(addprefix $(LIBFDT_dir)/,$(LIBFDT
> +@@ -204,9 +204,8 @@ $(LIBFDT_archive): $(addprefix $(LIBFDT_dir)/,$(LIBFDT
>   
>   $(LIBFDT_lib): $(addprefix $(LIBFDT_dir)/,$(LIBFDT_OBJS)) $(LIBFDT_version)
>   @$(VECHO) LD $@
> @@ -43,7 +45,7 @@ Index: Makefile
>   
>   ifneq ($(DEPTARGETS),)
>   -include $(LIBFDT_OBJS:%.o=$(LIBFDT_dir)/%.d)
> -@@ -221,8 +220,6 @@ install-lib: all
> +@@ -227,8 +226,6 @@ install-lib: all
>   @$(VECHO) INSTALL-LIB
>   $(INSTALL) -d $(DESTDIR)$(LIBDIR)
>   $(INSTALL_LIB) $(LIBFDT_lib) $(DESTDIR)$(LIBDIR)
> Index: patches/patch-libfdt_Makefile_libfdt
> ===
> RCS file: /cvs