CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/06/01 07:14:49 Modified files: games/fheroes2 : Makefile distinfo Log message: update to 1.1.0; major change is addition of a map editor which can be found in bottom right corner of the main menu
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/06/01 07:06:17 Modified files: geo/openbsd-developers: Makefile geo/openbsd-developers/files: OpenBSD Log message: reloc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/29 06:12:22 Modified files: games/keeperrl : Makefile distinfo games/keeperrl/patches: patch-miniunz_cpp patch-steam_base_cpp Log message: update to keeperrl 1.0pl19. While upstream is still not tagging new hotfix releases, this closely matches the date of itch.io game version 1_0_hotfix19 and runs without apparent issues
Re: [Update from Maintainer] games/mvdsv v1.00
On Mon, Apr 01, 2024 at 11:13:45AM +0100, Tom Murphy wrote:
> Hi,
>
> Below is a diff to update games/mvdsv from 0.36 to 1.00.
>
> Changelog:
>
> Improvements
>
> Reduce memory during loadmap (dsvensson)
> Enable pm_bunnyspeedcap cvar (ceeeKay)
> DOWNLOAD: bump download speed (qqshka)
> DEMO: add epoch time to fullserverinfo (ciscon)
>
> Bugfixes
>
> laststats connectionless command responds with invalid json (vikpe)
>
> Patch line numbers slightly updated but aside from that no changes to
> the port.
>
> Thanks,
> Tom
Took me a bit to get around to this one, but it builds fine. Runtime
not tested, but update is ok thfr@.
2 months have passed, I wanted to give opportunity to bring up if
anything changed to consider before committing this... Looks like
1.00 is still the most recent release.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/mvdsv/Makefile,v
> diff -u -p -u -p -r1.10 Makefile
> --- Makefile 12 Nov 2023 17:58:31 - 1.10
> +++ Makefile 1 Apr 2024 10:11:10 -
> @@ -3,7 +3,7 @@ COMMENT = QuakeWorld server
> CATEGORIES = games
>
> QUAKE_COMMIT = bf4ac424ce754894ac8f1dae6a3981954bc9852d
> -DIST_TUPLE +=github QW-Group mvdsv 0.36 .
> +DIST_TUPLE +=github QW-Group mvdsv v1.00 .
> DIST_TUPLE +=github QW-Group qwprot
> 53af547d0608a1507895fc1629cdc3f4820fc0af src/qwprot
> DIST_TUPLE +=github id-software Quake ${QUAKE_COMMIT} .
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/mvdsv/distinfo,v
> diff -u -p -u -p -r1.5 distinfo
> --- distinfo 12 Nov 2023 17:58:31 - 1.5
> +++ distinfo 1 Apr 2024 10:11:10 -
> @@ -1,6 +1,6 @@
> -SHA256 (QW-Group-mvdsv-0.36.tar.gz) =
> jyoHILfjcMyqejVQTA59165akFGzbpS3jWUlbzTpuOk=
> +SHA256 (QW-Group-mvdsv-v1.00.tar.gz) =
> Lon/SIERCWIpompgImcB5yQfQ6vI6/6YWmwmaqs39MM=
> SHA256 (QW-Group-qwprot-53af547d0608a1507895fc1629cdc3f4820fc0af.tar.gz) =
> +nkEALY4D495qX9h2LdciMAwR3CWcT6ewRLjBUsuxFA=
> SHA256 (id-software-Quake-bf4ac424ce754894ac8f1dae6a3981954bc9852d.tar.gz) =
> +5joyZdAEj8/rIMME4dYTsH2hNuJCMv0K3GH0G05kBM=
> -SIZE (QW-Group-mvdsv-0.36.tar.gz) = 551595
> +SIZE (QW-Group-mvdsv-v1.00.tar.gz) = 552652
> SIZE (QW-Group-qwprot-53af547d0608a1507895fc1629cdc3f4820fc0af.tar.gz) = 8815
> SIZE (id-software-Quake-bf4ac424ce754894ac8f1dae6a3981954bc9852d.tar.gz) =
> 2958901
> Index: patches/patch-src_sv_ccmds_c
> ===
> RCS file: /cvs/ports/games/mvdsv/patches/patch-src_sv_ccmds_c,v
> diff -u -p -u -p -r1.3 patch-src_sv_ccmds_c
> --- patches/patch-src_sv_ccmds_c 24 Aug 2022 03:24:32 - 1.3
> +++ patches/patch-src_sv_ccmds_c 1 Apr 2024 10:11:10 -
> @@ -5,7 +5,7 @@ at: https://github.com/deurk/mvdsv/pull/
> Index: src/sv_ccmds.c
> --- src/sv_ccmds.c.orig
> +++ src/sv_ccmds.c
> -@@ -741,54 +741,6 @@ void SV_ChmodFile_f (void)
> +@@ -744,54 +744,6 @@ void SV_ChmodFile_f (void)
> }
> #endif //_WIN32
>
> @@ -60,7 +60,7 @@ Index: src/sv_ccmds.c
> /*
> ==
> SV_Kick_f
> -@@ -1847,8 +1799,6 @@ void SV_InitOperatorCommands (void)
> +@@ -1853,8 +1805,6 @@ void SV_InitOperatorCommands (void)
> Cmd_AddCommand ("chmod", SV_ChmodFile_f);
> #endif //_WIN32
> //<-
>
Re: Sudden reboot every 5-10 minutes on latest snapshot
On Sat, May 25, 2024 at 12:06:39PM +, Ali Farzanrad wrote: > Ali Farzanrad wrote: > > Alexandre Ratchov wrote: > > > On Fri, May 24, 2024 at 09:04:29PM +, Ali Farzanrad wrote: > > > > Alexandre Ratchov wrote: > > > > > On Fri, May 24, 2024 at 04:30:52PM +, Ali Farzanrad wrote: [...] > > I have another problem here. My USB keyboard works great in BOOTX64.EFI > > but will not work on kernel config. > > > > I created /etc/bsd.re-config file and rebooted my system twice to > > disable azalia and then checked if it is disabled using config(8) and > > dmesg(8). > > > > Even when azalia is disabled my system gets sudden reboots. > > First sudden reboot was just after playing a music; but next 2 reboots > > was happened without playing anything. > > > > > Then, just do your regular stuff and see if the system reboots. > > I tested again with my patch. When azalia is disabled, it suddenly > reboots after few minutes, without playing anything. When azalia is > enabled, it lives. > This looks to me like you are chasing down a new rabbit hole every time I open one of your emails. I'd suggest you take a step back from all the stuff you seem to be trying without having a firm grasp on how to observe or report reproducibility. Have you tried out sthen@'s advice to check old kernels + snapshots[1]? I may have missed your response to this. You wrote that you rarely got the issue prior 17-May-2024? If that *is correct*, then you should be able to bisect using the snapshot archive around what date things change. I am highlighting *is correct* above because your issue seems to be unpredictable enough that a few minutes of testing don't mean anything. I suggest you try to find a *clear difference*, meaning between a snapshot where no reboot happens for ideally a whole day of use, and the next one where it clearly happens very quickly (and reproducible at least a second or third time). Your reports also make me wonder how much customization you are running. You've mentioned at least compiling custom kernels and setting bsd.re-config. It's easy to find yourself in virtually unsolvable scenarios by configuring too much. It might be best to try a clean install, ideally without activating xenodm/X11. [1] https://marc.info/?l=openbsd-misc=171646884302309=2
Re: [sparc64] unbreak spirv-tools build
ok with +=
On Tue, May 21, 2024, at 4:25 AM, Theo Buehler wrote:
> On Tue, May 21, 2024 at 10:00:23AM +0200, Theo Buehler wrote:
>> As can be seen on
>>
>> http://build-failures.rhaalovely.net/sparc64/2024-05-18/summary.log
>>
>> spirv-tools is the immediate blocker for many missing ports on sparc64.
>> It needs to link against stdc++fs with ports-gcc:
>>
>> http://build-failures.rhaalovely.net/sparc64/2024-05-18/graphics/spirv-tools.log
>>
>> The diff below uses the same approach as the one used by jca for glslang
>>
>> https://github.com/openbsd/ports/commit/eb51153047ff2fdba5334b386c814557b77857ba
>>
>> Packages on sparc64 and arm64.
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/graphics/spirv-tools/Makefile,v
>> diff -u -p -r1.20 Makefile
>> --- Makefile 20 May 2024 15:46:33 - 1.20
>> +++ Makefile 21 May 2024 07:57:39 -
>> @@ -31,7 +31,16 @@ BUILD_DEPENDS = graphics/spirv-headers
>>
>> CONFIGURE_ARGS =-DSPIRV-Headers_SOURCE_DIR="${LOCALBASE}"
>>
>> +SUBST_VARS =ADDITIONAL_LIBRARIES
>
> changed to +=
>
>> +
>> +pre-configure:
>> +${SUBST_CMD} ${WRKSRC}/tools/CMakeLists.txt
>> +
>> # effcee is missing to build tests
>> NO_TEST = Yes
>>
>> .include
>> +
>> +.if ${CHOSEN_COMPILER} == ports-gcc
>> +ADDITIONAL_LIBRARIES = stdc++fs
>> +.endif
>> Index: patches/patch-tools_CMakeLists_txt
>> ===
>> RCS file: patches/patch-tools_CMakeLists_txt
>> diff -N patches/patch-tools_CMakeLists_txt
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ patches/patch-tools_CMakeLists_txt 21 May 2024 07:58:40 -
>> @@ -0,0 +1,14 @@
>> +Add -lstdc++fs for ports-gcc
>> +
>> +Index: tools/CMakeLists.txt
>> +--- tools/CMakeLists.txt.orig
>> tools/CMakeLists.txt
>> +@@ -74,7 +74,7 @@ if (NOT ${SPIRV_SKIP_EXECUTABLES})
>> +objdump/extract_source.cpp
>> +util/cli_consumer.cpp
>> +${COMMON_TOOLS_SRCS}
>> +- LIBS ${SPIRV_TOOLS_FULL_VISIBILITY})
>> ++ LIBS ${SPIRV_TOOLS_FULL_VISIBILITY}
>> ${ADDITIONAL_LIBRARIES})
>> + target_include_directories(spirv-objdump PRIVATE
>> ${spirv-tools_SOURCE_DIR}
>> +
>> ${SPIRV_HEADER_INCLUDE_DIR})
>> + set(SPIRV_INSTALL_TARGETS ${SPIRV_INSTALL_TARGETS} spirv-objdump)
>>
Re: 0ad: double datasize to avoid crashes
On Mon, May 20, 2024 at 09:33:25PM +, Klemens Nanni wrote:
> 20.05.2024 00:13, Thomas Frohwein пишет:
> > Can we do the same check for -lt like with chromium? The reason is that
> > I don't think the datasize should be reduced if the user has set it
> > higher than the 2G.
>
> Ah yes, of course.
> OK kn if you want to commit that with op's '0.A.D.' -> '0 A.D.' fix,
> otherwise I can do that in a few days (given OKs).
>
> Thanks.
I went ahead and committed it.
> > As in this counter diff:
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/games/0ad/base/Makefile,v
> > retrieving revision 1.51
> > diff -u -p -r1.51 Makefile
> > --- Makefile6 May 2024 12:23:33 - 1.51
> > +++ Makefile19 May 2024 21:12:33 -
> > @@ -2,7 +2,7 @@ COMMENT = historical real-time strategy
> >
> > DISTNAME = 0ad-${V}-alpha-unix-build
> > PKGNAME = 0ad-${V}
> > -REVISION = 6
> > +REVISION = 7
> >
> > USE_WXNEEDED = Yes
> > USE_NOBTCFI = Yes
> > @@ -105,7 +105,7 @@ do-install:
> > cp -R ${WRKDIST}/binaries/data/* ${PREFIX}/share/0ad
> > ${INSTALL_DATA} ${WRKDIST}/binaries/system/lib* ${PREFIX}/lib
> > ${INSTALL_PROGRAM} ${WRKDIST}/binaries/system/pyrogenesis ${PREFIX}/bin
> > - ${INSTALL_SCRIPT} ${WRKDIST}/build/resources/0ad.sh ${PREFIX}/bin/0ad
> > + ${SUBST_PROGRAM} ${WRKDIST}/build/resources/0ad.sh ${PREFIX}/bin/0ad
> > ${INSTALL_DATA_DIR} ${PREFIX}/share/applications
> > ${INSTALL_DATA} ${WRKDIST}/build/resources/0ad.desktop \
> > ${PREFIX}/share/applications/
> > Index: patches/patch-build_resources_0ad_sh
> > ===
> > RCS file: patches/patch-build_resources_0ad_sh
> > diff -N patches/patch-build_resources_0ad_sh
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-build_resources_0ad_sh19 May 2024 21:12:33 -
> > @@ -0,0 +1,22 @@
> > +Try to crank datasize to 2G to avoid ENOMEM crashes during big games
> > +
> > +Index: build/resources/0ad.sh
> > +--- build/resources/0ad.sh.orig
> > build/resources/0ad.sh
> > +@@ -2,6 +2,16 @@
> > +
> > + pyrogenesis=$(which pyrogenesis 2> /dev/null)
> > + if [ -x "$pyrogenesis" ] ; then
> > ++ DATASIZE=$((2 * 1024 * 1024))
> > ++ if [ $(ulimit -Sd) -lt ${DATASIZE} ]; then
> > ++ulimit -Sd ${DATASIZE} || \
> > ++ ${X11BASE}/bin/xmessage -file - -center -buttons yes:0,no:1
> > -default no <<- _EOF
> > ++ Cannot increase datasize-cur to at least ${DATASIZE}
> > ++ Do you want to run 0.A.D. anyway?
> > ++ (If so, it may run out of memory and crash.)
> > ++ _EOF
> > ++[ $? -eq 0 ] || exit
> > ++ fi
> > + "$pyrogenesis" "$@"
> > + else
> > + echo "Error: pyrogenesis not found in ($PATH)"
> >
>
Re: devel/sdl2-image: fix sdl2_image-config.cmake
On Mon, May 20, 2024 at 11:38:12PM +0300, Viacheslav Chimishuk wrote:
> On 20.05.2024 09:20, Thomas Frohwein wrote:
> > Did this work for you? I built it with your patch, but the file
> > /usr/local/lib/cmake/SDL2_image/sdl2_image-config.cmake appears to be
> > unchanged and still doesn't contain the library version. Don't have
> > time right now to look more closely myself...
>
> Yes, it works just fine for me. Maybe package from the cache has been
> installed
> instead of built version or something?
>
> $ cat /usr/local/lib/cmake/SDL2_image/sdl2_image-config.cmake | grep 1.1
> IMPORTED_LOCATION
> "${_sdl2image_libdir}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2_image${CMAKE_SHARED_LIBRARY_SUFFIX}.1.1"
> $
I found the cause. This section:
+Index: sdl2_image-config.cmake.in
+--- sdl2_image-config.cmake.in.orig
sdl2_image-config.cmake.in
created the patch in the main directory of the port and not in patches/
and I didn't look closely so the patch was never applied. Fixed it and
committed it, thanks!
Patches with cvs and git usually preserve the relative directory...
>
> --
> Best regards, Viacheslav Chimishuk
> vchimis...@yandex.ru
> Ukraine, Khmelnitsky
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/20 19:29:18 Modified files: games/0ad/base : Makefile Added files: games/0ad/base/patches: patch-build_resources_0ad_sh Log message: set a minimum datasize limit of 2G for 0ad to avoid crashes from out of memory. By kn@ and ok kn@ with adjustment to the ulimit logic. Also contribution and ok op@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/20 19:25:03 Modified files: devel/sdl2-image: Makefile Added files: devel/sdl2-image/patches: patch-sdl2_image-config_cmake_in Log message: fix cmake config file to carry the version suffix for the .so by Viacheslav Chimishuk ( vchimishuk () yandex ! ru ) ok rsadowski@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/20 09:49:00 Modified files: emulators/snes9x: Makefile Added files: emulators/snes9x/patches: patch-external_VulkanMemoryAllocator-Hpp_include_vk_mem_alloc_funcs_hpp Log message: fix namespace issue with vulkan 1.3.283.0 update
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/20 09:46:34 Modified files: graphics/glslang: Makefile distinfo graphics/glslang/pkg: PLIST graphics/spirv-headers: Makefile distinfo graphics/spirv-headers/pkg: PLIST graphics/spirv-tools: Makefile distinfo graphics/vulkan-headers: Makefile distinfo graphics/vulkan-headers/pkg: PLIST graphics/vulkan-loader: Makefile distinfo graphics/vulkan-tools: Makefile distinfo graphics/vulkan-utility-libraries: Makefile distinfo graphics/vulkan-utility-libraries/pkg: PLIST graphics/vulkan-validation-layers: Makefile distinfo Added files: graphics/vulkan-tools/patches: patch-cube_cube_c Log message: update Vulkan to latest SDK 1.3.283.0, and glslang 14.2.0 Includes fixes for unsafe functions (sprintf, strcat) in vulkan-tools (cube.c). Tested runtime with vkcube and vkquake. Survived a bulk build, with snes9x needing a patch for namespace issue to be committed separately.
Re: devel/sdl2-image: fix sdl2_image-config.cmake
On Mon, May 20, 2024 at 02:45:15AM +0300, Viacheslav Chimishuk wrote:
> When I try to build cmake-based application which uses sdl2-image it fails
> because of missing /usr/local/lib/libSDL2_image.so file.
>
> Cmake files provided by sdl2-image are looking for
> /usr/local/lib/libSDL2_image.so, which is obviously not found. I can see that
> sdl2-image port misses some files which we have for other sdl2-* ports. For
> example for devel/sdl2-ttf.
>
> So, proposed patch fixes cmake files to look for
> /usr/local/lib/libSDL2_image.so.1.1 instead of /usr/local/lib/libSDL2_image.so
Did this work for you? I built it with your patch, but the file
/usr/local/lib/cmake/SDL2_image/sdl2_image-config.cmake appears to be
unchanged and still doesn't contain the library version. Don't have
time right now to look more closely myself...
>
> diff --git a/devel/sdl2-image/Makefile b/devel/sdl2-image/Makefile
> index 3ab8314ca..27ee3c0d3 100644
> --- a/devel/sdl2-image/Makefile
> +++ b/devel/sdl2-image/Makefile
> @@ -39,4 +39,7 @@ CONFIGURE_ARGS += --disable-avif-shared \
> --disable-webp-shared
> CONFIGURE_ENV += OBJC="${CC}"
>
> +pre-configure:
> + ${SUBST_CMD} ${WRKSRC}/sdl2_image-config.cmake.in
> +
> .include
> diff --git a/devel/sdl2-image/patches/patch-sdl2_image-config_cmake_in
> b/devel/sdl2-image/patches/patch-sdl2_image-config_cmake_in
> new file mode 100644
> index 0..c4bf5c9ac
> --- /dev/null
> +++ b/devel/sdl2-image/patches/patch-sdl2_image-config_cmake_in
> @@ -0,0 +1,12 @@
> +Index: sdl2_image-config.cmake.in
> +--- sdl2_image-config.cmake.in.orig
> sdl2_image-config.cmake.in
> +@@ -78,7 +78,7 @@ if(NOT TARGET SDL2_image::SDL2_image)
> + else()
> + set_target_properties(SDL2_image::SDL2_image
> + PROPERTIES
> +-IMPORTED_LOCATION
> "${_sdl2image_libdir}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2_image${CMAKE_SHARED_LIBRARY_SUFFIX}"
> ++IMPORTED_LOCATION
> "${_sdl2image_libdir}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2_image${CMAKE_SHARED_LIBRARY_SUFFIX}.${LIBSDL2_image_VERSION}"
> + )
> + endif()
> + endif()
>
> --
> Best regards, Viacheslav Chimishuk
> vchimis...@yandex.ru
> Ukraine, Khmelnitsky
Re: 0ad: double datasize to avoid crashes
On Sun, May 19, 2024 at 07:45:29PM +, Klemens Nanni wrote:
> 19.05.2024 18:04, Thomas Frohwein пишет:
> > I think the better approach is to pick an absolute datasize and set
> > that (or recommend it in README or MESSAGE). See chromium's
> > files/chrome:
> >
> > DATASIZE="716800"
> > [...]
> > if [ $(ulimit -Sd) -lt ${DATASIZE} ]; then
> > ulimit -Sd ${DATASIZE} || \
> > xm_log "Cannot increase datasize-cur to at least ${DATASIZE}"
> > [ $? -eq 0 ] || exit
> > fi
> >
> > Otherwise you're doubling an unknown ulimit -d that might already be
> > sufficient.
>
> Fair point, so 1.5G crashed and 3G worked; I did a big game with 2G and
> it worked, so I'll pick that and we can still crank if needed.
>
> >
> >> + "$pyrogenesis" "$@"
> >> + else
> >> + echo "Error: pyrogenesis not found in ($PATH)"
> >>
> >
>
> I tested the pop-up with an extra *5 to make it fail.
> Feedback? OK?
Can we do the same check for -lt like with chromium? The reason is that
I don't think the datasize should be reduced if the user has set it
higher than the 2G.
As in this counter diff:
Index: Makefile
===
RCS file: /cvs/ports/games/0ad/base/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile6 May 2024 12:23:33 - 1.51
+++ Makefile19 May 2024 21:12:33 -
@@ -2,7 +2,7 @@ COMMENT = historical real-time strategy
DISTNAME = 0ad-${V}-alpha-unix-build
PKGNAME = 0ad-${V}
-REVISION = 6
+REVISION = 7
USE_WXNEEDED = Yes
USE_NOBTCFI = Yes
@@ -105,7 +105,7 @@ do-install:
cp -R ${WRKDIST}/binaries/data/* ${PREFIX}/share/0ad
${INSTALL_DATA} ${WRKDIST}/binaries/system/lib* ${PREFIX}/lib
${INSTALL_PROGRAM} ${WRKDIST}/binaries/system/pyrogenesis ${PREFIX}/bin
- ${INSTALL_SCRIPT} ${WRKDIST}/build/resources/0ad.sh ${PREFIX}/bin/0ad
+ ${SUBST_PROGRAM} ${WRKDIST}/build/resources/0ad.sh ${PREFIX}/bin/0ad
${INSTALL_DATA_DIR} ${PREFIX}/share/applications
${INSTALL_DATA} ${WRKDIST}/build/resources/0ad.desktop \
${PREFIX}/share/applications/
Index: patches/patch-build_resources_0ad_sh
===
RCS file: patches/patch-build_resources_0ad_sh
diff -N patches/patch-build_resources_0ad_sh
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-build_resources_0ad_sh19 May 2024 21:12:33 -
@@ -0,0 +1,22 @@
+Try to crank datasize to 2G to avoid ENOMEM crashes during big games
+
+Index: build/resources/0ad.sh
+--- build/resources/0ad.sh.orig
build/resources/0ad.sh
+@@ -2,6 +2,16 @@
+
+ pyrogenesis=$(which pyrogenesis 2> /dev/null)
+ if [ -x "$pyrogenesis" ] ; then
++ DATASIZE=$((2 * 1024 * 1024))
++ if [ $(ulimit -Sd) -lt ${DATASIZE} ]; then
++ulimit -Sd ${DATASIZE} || \
++ ${X11BASE}/bin/xmessage -file - -center -buttons yes:0,no:1 -default no
<<- _EOF
++ Cannot increase datasize-cur to at least ${DATASIZE}
++ Do you want to run 0.A.D. anyway?
++ (If so, it may run out of memory and crash.)
++ _EOF
++[ $? -eq 0 ] || exit
++ fi
+ "$pyrogenesis" "$@"
+ else
+ echo "Error: pyrogenesis not found in ($PATH)"
Re: HELP WANTED: NEW net/abaddon
On Sun, May 19, 2024 at 09:15:44AM -0500, izder456 wrote:
> Hello ports@,
>
> I am working on a port for net/abaddon which is a lightweight GTK3
> discord client written in C++.
>
> I got so far until a `make package` where I get this error:
>
> ===> Building package for abaddon-0.2.1
> Create /usr/packages/amd64/all/abaddon-0.2.1.tgz
> Error: Libraries in packing-lists in the ports tree
>and libraries from installed packages don't match
> --- /tmp/dep_cache.u16eUfuw6/portstree-abaddon-0.2.1Sun May 19
> 09:10:39 2024 +++ /tmp/dep_cache.u16eUfuw6/inst-abaddon-0.2.1 Sun May
> 19 09:10:39 2024 @@ -22,7 +22,7 @@
I think your terminal messed up newlines here when you copy-pasted to
your email; this makes this slightly harder to read.
Note the '---' line has portstree-abaddon. And the '+++' line has
inst-abaddon. This means it's showing you the difference between the
version in your ports tree (typically under /usr/ports) and the
installed version.
> -W gtk-3.2201.0
> -W gtkmm-3.0.4.5
> -W handy-1.0.3
> --W harfbuzz.18.9
> +-W harfbuzz.18.8
Now comparing + and - to above: your portstree has library version 18.9
and you have library version 18.8 installed! That's what pkg_create is
complaining about: your installed packages are behind.
This will resolve once you update your snapshot with the new harfbuzz
packages. Or you build and install harfbuzz from you ports tree.
> -W intl.8.0
> -W m.10.1
> -W opus.1.5
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3567
> 'wantlib-args': @case X${_DEPENDS_CACHE} in X) _DEPENDS_CACHE=$(
> mktemp -d ...) *** Error 2 in .
> (/usr/ports/infrastructure/mk/bsd.port.mk:2243
> '/usr/packages/amd64/all/abaddon-0.2.1.tgz': @trap "cd
> /usr/packages/amd64/t...) *** Error 2 in .
> (/usr/ports/infrastructure/mk/bsd.port.mk:2725 '_internal-package':
> @case X${_DEPENDS_CACHE} in X) _DEPENDS_CACHE=$( mktem...) *** Error 2
> in /home/izder456/Projects/OpenBSD/ports/mystuff/net/abaddon
> (/usr/ports/infrastructure/mk/bsd.port.mk:2704 'package': @lock=aba...)
>
> I have tried to update my plist with `make update-plist`, but to no
> avail.
make update-plist only affects that contents, the library versions are
handled by SHARED_LIBS - see bsd.port.mk(5) and pkg_create(1).
Re: 0ad: double datasize to avoid crashes
On Sun, May 19, 2024 at 01:42:45PM +, Klemens Nanni wrote:
> My user is not in the 'staff' group and its default 1572864 is enough to
> start playing a serious game, which eventually crashes when, I presume,
> the world gets big enough.
>
> Losing your game/progress like that sucks, so I just doubled the limit
> and have been playing without crashes ever since.
>
> Is this fair enough to include in ports or should we aim for a specific
> limit? I see the chromium ports have more logic to a) ensure a limit
> and b) present a choice when raising it fails, but none of that was
> needed for me so far, hence the simple diff.
>
> Feedback? OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/0ad/base/Makefile,v
> diff -u -p -r1.51 Makefile
> --- Makefile 6 May 2024 12:23:33 - 1.51
> +++ Makefile 19 May 2024 10:05:32 -
> @@ -2,7 +2,7 @@ COMMENT = historical real-time strategy
>
> DISTNAME = 0ad-${V}-alpha-unix-build
> PKGNAME =0ad-${V}
> -REVISION = 6
> +REVISION = 7
>
> USE_WXNEEDED = Yes
> USE_NOBTCFI =Yes
> Index: patches/patch-build_resources_0ad_sh
> ===
> RCS file: patches/patch-build_resources_0ad_sh
> diff -N patches/patch-build_resources_0ad_sh
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-build_resources_0ad_sh 19 May 2024 11:26:28 -
> @@ -0,0 +1,13 @@
> +(Try to) Double datasize to avoid ENOMEM crashes during (big) games
> +
> +Index: build/resources/0ad.sh
> +--- build/resources/0ad.sh.orig
> build/resources/0ad.sh
> +@@ -2,6 +2,7 @@
> +
> + pyrogenesis=$(which pyrogenesis 2> /dev/null)
> + if [ -x "$pyrogenesis" ] ; then
> ++ ulimit -d $((2 * `ulimit -d`))
I think the better approach is to pick an absolute datasize and set
that (or recommend it in README or MESSAGE). See chromium's
files/chrome:
DATASIZE="716800"
[...]
if [ $(ulimit -Sd) -lt ${DATASIZE} ]; then
ulimit -Sd ${DATASIZE} || \
xm_log "Cannot increase datasize-cur to at least ${DATASIZE}"
[ $? -eq 0 ] || exit
fi
Otherwise you're doubling an unknown ulimit -d that might already be
sufficient.
> + "$pyrogenesis" "$@"
> + else
> + echo "Error: pyrogenesis not found in ($PATH)"
>
Re: Perl ports in arm64 vs -current
On Sat, May 18, 2024 at 06:37:09PM +, Lucas Gabriel Vuotto wrote: > Hello ports@, > > Since today's snapshot, it seems that something is off in arm64 and > Perl: > > $ perl -MNet::SSLeay -e 'print "works\n"' > SSLeay.c: loadable library and perl binaries are mismatched (got first > handshake key 0x1060, needed 0x10d0) > > On the contrary, on amd64 updated today too, > > $ perl -MNet::SSLeay -e 'print "works\n"' > works > > The issue is present with other modules, Net::SSLeay was chosen as it > was the one giving me an error message. But I tried p5-EV with a similar > error except for the filename. > > Rebuilding the package locally makes the error go away, so I guess it's > related to builders not being up-to-date with latest Perl, leading to > errors for packages with native extensions? Yes, that seems to be it and should resolve soon as new packages show up. > dmesgs for systems follow. > > Lucas > > > ==> arm64 > > OpenBSD 7.5-current (GENERIC.MP) #40: Fri May 17 14:59:13 MDT 2024 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 4185792512 (3991MB) > avail mem = 3971817472 (3787MB) > random: good seed from bootblocks > mainbus0 at root: ACPI > psci0 at mainbus0: PSCI 1.0, SMCCC 1.1 > efi0 at mainbus0: UEFI 2.7 > efi0: EDK II rev 0x1 > smbios0 at efi0: SMBIOS 3.0.0 > smbios0: vendor Hetzner version "2017" date 11/11/2017 > smbios0: Hetzner vServer > cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r3p1 > cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache > cpu0: 1024KB 64b/line 8-way L2 cache > cpu0: > DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SSBS+MSR > cpu1 at mainbus0 mpidr 1: ARM Neoverse N1 r3p1 > cpu1: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache > cpu1: 1024KB 64b/line 8-way L2 cache > apm0 at mainbus0 > agintc0 at mainbus0 shift 4:4 nirq 288 nredist 2 ipi: 0, 1, 2: > "interrupt-controller" > agintcmsi0 at agintc0 > agtimer0 at mainbus0: 25000 kHz > acpi0 at mainbus0: ACPI 5.1 > acpi0: sleep states > acpi0: tables DSDT FACP APIC GTDT MCFG SPCR DBG2 IORT BGRT > acpi0: wakeup devices > acpimcfg0 at acpi0 > acpimcfg0: addr 0x401000, bus 0-255 > acpiiort0 at acpi0 > "ACPI0007" at acpi0 not configured > "ACPI0007" at acpi0 not configured > pluart0 at acpi0 COM0 addr 0x900/0x1000 irq 33 > pluart0: console > "LNRO0015" at acpi0 not configured > "LNRO0015" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > "LNRO0005" at acpi0 not configured > acpipci0 at acpi0 PCI0 > pci0 at acpipci0 > "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured > virtio0 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 > viogpu0 at virtio0: 1024x768, 32bpp > wsdisplay0 at viogpu0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > virtio0: msix per-VQ > ppb0 at pci0 dev 2 function 0 "Red Hat PCIE" rev 0x00: irq 37 > pci1 at ppb0 bus 1 > virtio1 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 > vio0 at virtio1: address 96:00:02:40:c5:c9 > virtio1: msix shared > ppb1 at pci0 dev 2 function 1 "Red Hat PCIE" rev 0x00: irq 37 > pci2 at ppb1 bus 2 > xhci0 at pci2 dev 0 function 0 "Red Hat xHCI" rev 0x01: msix, xHCI 0.0 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev > 3.00/1.00 addr 1 > ppb2 at pci0 dev 2 function 2 "Red Hat PCIE" rev 0x00: irq 37 > pci3 at ppb2 bus 3 > virtio2 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Console" rev 0x01 > virtio2: no matching child driver; not configured > ppb3 at pci0 dev 2 function 3 "Red Hat PCIE" rev 0x00: irq 37 > pci4 at ppb3 bus 4 > virtio3 at pci4 dev 0 function 0 "Qumranet Virtio 1.x Memory Balloon" rev 0x01 > viomb0 at virtio3 >
Re: openarena mouse not working on multiple openbsd systems
On Thu, May 16, 2024 at 04:31:22PM +0200, Divan Santana wrote: > Greetings :) > > So I've tried openarena on 7.5 on multiple systems [1,2], both systems > the mouse refuses to work, the left / right movement is not working. > > The one system, it briefly works but stops after less then 15s. > > I've tried launching the game with: > > SDL_VIDEO_X11_DGAMOUSE=0 > > I've also tried this setting > > root@cephas:~# cat /etc/X11/xorg.conf > Section "Module" > SubSection "extmod" > # Don't initialize the DGA extension > Option "omit xfree86-dga" > EndSubSection > EndSection > > After restarting xenodm, I can see in the Xorg log, it's read the config > file, but the issue persists in the game. > > Any ideas? I tried it and what I'm seeing is that the mouse works in the menu, and after I launch the game itself, it stops working after less than a second. However, if I go back into the menu, the mouse works there again. No change with SDL_VIDEO_X11_DGAMOUSE=0. I've looked through the port build and the patches. I don't see anything that looks like it could be an OpenBSD-specific cause for this behavior. You would need to run this by someone who has more familiarity with the openarena codebase. It seems that upstream manages support/issues via http://www.openarena.ws/board/ ... > > [1]: > OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 67784667136 (64644MB) > avail mem = 65708625920 (62664MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.6 @ 0xb9ad6000 (43 entries) > bios0: vendor American Megatrends International, LLC. version "1.93" date > 01/26/2024 > bios0: Micro-Star International Co., Ltd. MS-7E26 > efi0 at bios0: UEFI 2.9 > efi0: American Megatrends rev 0x50020 > acpi0 at bios0: ACPI 6.5 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT FIDT MCFG HPET WDRT UEFI FPDT VFCT SSDT > SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT SSDT SSDT SSDT SSDT BGRT > acpi0: wakeup devices GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) > XHC1(S4) XHC2(S4) GPP0(S4) GPP1(S4) GPP2(S4) GPP7(S4) UP00(S4) DP48(S4) > EP00(S4) DP50(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch > 0a601206 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,STIBP_ALL,IBRS_PREF,IBRS_SM,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line > 8-way L2 cache, 32MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 25MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch > 0a601206 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,HWPSTATE,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,STIBP_ALL,IBRS_PREF,IBRS_SM,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line > 8-way L2 cache, 32MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: AMD Ryzen 9 7900 12-Core Processor, 3700.00 MHz, 19-61-02, patch > 0a601206 > cpu2: >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/16 09:44:33 Modified files: devel/dnspy: Makefile distinfo devel/dnspy/pkg: PLIST Log message: update to dnspy 6.5.0 and switch to the dnSpyEx fork, as the original has become inactive. Found by jca@!
Re: CVS: cvs.openbsd.org: ports
On Mon, May 13, 2024 at 08:47:04PM -0600, Thomas Frohwein wrote: > CVSROOT: /cvs > Module name: ports > Changes by: t...@cvs.openbsd.org2024/05/13 20:47:04 > > Modified files: > lang/rsm : Makefile distinfo > Added files: > lang/rsm/patches: patch-Makefile > Removed files: > lang/rsm/patches: patch-BSDmakefile > > Log message: > update to RSM 1.80.4 > > Release notes at: > https://gitlab.com/Reference-Standard-M/rsm/-/release > Wrong link for the release notes, pointed out to me by upstream. They are at: https://gitlab.com/Reference-Standard-M/rsm/-/releases
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/15 08:30:03 Modified files: audio : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm Removed files: audio/py-fsb5 : Makefile distinfo audio/py-fsb5/pkg: DESCR PLIST Log message: Send py3-fsb5 to the attic, no longer maintained and no longer useful. ok rsadowski@, jca@, sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/15 08:17:05 Modified files: games/keeperrl : Makefile distinfo games/keeperrl/patches: patch-steam_base_cpp Added files: games/keeperrl/patches: patch-miniunz_cpp Log message: update to keeperrl 1.0pl16, matching the commit around the time of the release of the commercial version 1_0_hotfix16. This fixes running hotfix16. While here, fix unsafe string functions sprintf and strcpy. (working on upstreaming this) ok solene@ for an earlier version that didn't include the sprintf and strcpy patch
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/15 08:03:50 Modified files: archivers/py-brotli: Makefile distinfo Log message: update to latest version 1.1.0, also drop myself from MAINTAINER. ok sthen@
Re: update editors/kakoune
On Sun, May 12, 2024 at 12:02:50PM +0200, Solene Rapenne wrote:
> New version of kakoune available:
>
> - gzip_man=no in MAKE_ENV didn't work anymore, I patched Makefile
> - tests were not working, I reported it upstream who made a fix
> - compilation didn't work due to quotes being lost, upstream made fix
>
> I plan to commit it soon, but I'd like some feedback if possible
Built it and running it, looks good. The solutions are reasonable.
There is a file from openrct2 included, apparently by accident. Just
make sure that's removed from the diff that gets committed.
>
> diff --git a/editors/kakoune/Makefile b/editors/kakoune/Makefile
> index 218164067da..17480e4ccb7 100644
> --- a/editors/kakoune/Makefile
> +++ b/editors/kakoune/Makefile
> @@ -1,6 +1,6 @@
> COMMENT =modal code editor with a focus on interactivity
>
> -V = 2023.08.05
> +V = 2024.05.09
> DISTNAME = kakoune-${V}
>
> CATEGORIES = editors
> @@ -18,7 +18,7 @@ PERMIT_PACKAGE =Yes
>
> # -std=c++2a
> COMPILER = base-clang
> -MAKE_ENV = CXX="${CXX}" CXXFLAGS="${CXXFLAGS}" gzip_man=no
> +MAKE_ENV = CXX="${CXX}" CXXFLAGS="${CXXFLAGS}"
> FAKE_FLAGS = PREFIX="${TRUEPREFIX}"
> # some tests fail without en_US.UTF-8
> TEST_ENV = LC_CTYPE="en_US.UTF-8"
> diff --git a/editors/kakoune/distinfo b/editors/kakoune/distinfo
> index 42f8dafa9a2..079e7825106 100644
> --- a/editors/kakoune/distinfo
> +++ b/editors/kakoune/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (kakoune-2023.08.05.tar.bz2) =
> PkUVHgrd01AN4taim1qs8iZ8QrslbUSnguc977Kc2lw=
> -SIZE (kakoune-2023.08.05.tar.bz2) = 568612
> +SHA256 (kakoune-2024.05.09.tar.bz2) =
> IZC939OvWQwFk8OFNwiJdlR1BvR71utsDiI1Db0Woik=
> +SIZE (kakoune-2024.05.09.tar.bz2) = 588121
> diff --git a/editors/kakoune/patches/patch-Makefile
> b/editors/kakoune/patches/patch-Makefile
> new file mode 100644
> index 000..013516f9446
> --- /dev/null
> +++ b/editors/kakoune/patches/patch-Makefile
> @@ -0,0 +1,56 @@
> +Partial changes from 7be22f1ec28677ca0bb30316c6893ab4436734b1
> +
> +- escape KAK_BIN_PATH
> +- test target
> +
> +Index: Makefile
> +--- Makefile.orig
> Makefile
> +@@ -5,7 +5,7 @@ CXX = c++
> +
> + debug = no
> + static = no
> +-gzip_man = yes
> ++gzip_man = no
> + # to get format compatible with GitHub archive use "gzip -S .gz" here
> + compress_bin = bzip2
> +
> +@@ -13,10 +13,8 @@ compress-suffix-bzip2 = bz2
> + compress-suffix-zstd = zst
> +
> + CPPFLAGS-debug-yes = -DKAK_DEBUG
> +-CXXFLAGS-debug-yes = -O0 -g3
> + tag-debug-yes = .debug
> +
> +-CXXFLAGS-debug-no = -O3 -g3
> + tag-debug-no = .opt
> +
> + CXXFLAGS-sanitize-address = -fsanitize=address
> +@@ -40,7 +38,7 @@ bindir = $(DESTDIR)$(PREFIX)/bin
> + libexecdir = $(DESTDIR)$(PREFIX)/libexec/kak
> + sharedir = $(DESTDIR)$(PREFIX)/share/kak
> + docdir = $(DESTDIR)$(PREFIX)/share/doc/kak
> +-mandir = $(DESTDIR)$(PREFIX)/share/man/man1
> ++mandir = $(DESTDIR)$(PREFIX)/man/man1
> +
> + # Both Cygwin and MSYS2 have "_NT" in their uname.
> + os = $(shell uname | sed 's/.*_NT.*/Windows/')
> +@@ -54,7 +52,7 @@ LDFLAGS-os-FreeBSD = -L/usr/local/lib
> +
> + LIBS-os-Haiku = -lnetwork -lbe
> +
> +-CPPFLAGS-os-OpenBSD = -DKAK_BIN_PATH="$(bindir)/kak" -I/usr/local/include
> ++CPPFLAGS-os-OpenBSD = -DKAK_BIN_PATH=\"$(bindir)/kak\" -I/usr/local/include
> + LDFLAGS-os-OpenBSD = -L/usr/local/lib
> + mandir-os-OpenBSD = $(DESTDIR)$(PREFIX)/man/man1
> +
> +@@ -136,6 +134,9 @@ doc/kak.1.gz: doc/kak.1
> +
> + check: test
> + test: src/kak
> ++if [ $(os) = OpenBSD ]; then \
> ++export KAKOUNE_RUNTIME=$$PWD/share/kak; \
> ++fi && \
> + cd test && ./run
> +
> + TAGS: tags
> diff --git a/editors/kakoune/patches/patch-src_Makefile
> b/editors/kakoune/patches/patch-src_Makefile
> deleted file mode 100644
> index 84c865e9398..000
> --- a/editors/kakoune/patches/patch-src_Makefile
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -Remove optimization flags for debug or release builds
> -
> -Index: src/Makefile
> src/Makefile.orig
> -+++ src/Makefile
> -@@ -12,11 +12,9 @@ endif
> -
> - ifeq ($(debug),yes)
> - CPPFLAGS += -DKAK_DEBUG
> --CXXFLAGS += -O0
> - suffix := .debug
> - else
> - ifeq ($(debug),no)
> --CXXFLAGS += -O3
> - suffix := .opt
> - else
> - $(error debug should be either yes or no)
> diff --git a/editors/kakoune/patches/patch-src_ranges_hh
> b/editors/kakoune/patches/patch-src_ranges_hh
> deleted file mode 100644
> index 5145755cd7e..000
> --- a/editors/kakoune/patches/patch-src_ranges_hh
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -From 344d31f42b8ced12626d4f87a22ffa5a671668fd Mon Sep 17 00:00:00 2001
> -From: Johannes Altmanninger
> -Date: Tue, 9 May 2023 10:44:08 +0200
> -Subject: [PATCH] Work around clang not inferring default args of template
> - template args
> -
> -Index: src/ranges.hh
> src/ranges.hh.orig
> -+++ src/ranges.hh
> -@@ -8,6 +8,11
Re: update games/gzdoom
On Sun, May 12, 2024 at 08:26:57PM +0200, Solene Rapenne wrote:
> changelog https://github.com/ZDoom/gzdoom/compare/g4.11.3...g4.12.2
>
> tested with doom2 and brutal doom, sound + music worked fine
>
> one patch was merged upstream
I have the same diff and it works as expected with FreeDoom. ok thfr@
for update; see if Timo can weigh in, too.
> diff --git a/games/gzdoom/Makefile b/games/gzdoom/Makefile
> index 50b4a92f320..e4ca89b89c3 100644
> --- a/games/gzdoom/Makefile
> +++ b/games/gzdoom/Makefile
> @@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = i386 amd64
>
> COMMENT =OpenGL engine for idTech 1 games like
> doom,hexen,heretic...
>
> -V = 4.11.3
> +V = 4.12.2
>
> DIST_TUPLE = github ZDoom gzdoom g${V} .
> PKGNAME =gzdoom-${V}
> diff --git a/games/gzdoom/distinfo b/games/gzdoom/distinfo
> index 34c0a704339..926b22dec20 100644
> --- a/games/gzdoom/distinfo
> +++ b/games/gzdoom/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (ZDoom-gzdoom-g4.11.3.tar.gz) =
> WUPbpQ2iD/lPH8xBUTJnLUKhWRfFcbHCt87v4Uk19dU=
> -SIZE (ZDoom-gzdoom-g4.11.3.tar.gz) = 24354699
> +SHA256 (ZDoom-gzdoom-g4.12.2.tar.gz) =
> hkxaHsl23WBo+c2T+SxUBMZigkmWEB8UEd2yWlSvxzI=
> +SIZE (ZDoom-gzdoom-g4.12.2.tar.gz) = 25910359
> diff --git a/games/gzdoom/patches/patch-CMakeLists_txt
> b/games/gzdoom/patches/patch-CMakeLists_txt
> deleted file mode 100644
> index 6d2aba4be6d..000
> --- a/games/gzdoom/patches/patch-CMakeLists_txt
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -Index: CMakeLists.txt
> CMakeLists.txt.orig
> -+++ CMakeLists.txt
> -@@ -301,7 +301,7 @@ else()
> -
> - if ( UNIX )
> - include(CheckSymbolExists)
> --check_symbol_exists( "fts_set" "fts.h" HAVE_FTS )
> -+check_symbol_exists( "fts_set" "sys/types.h;sys/stat.h;fts.h"
> HAVE_FTS )
> - if ( NOT HAVE_FTS )
> - include ( FindPkgConfig )
> - pkg_check_modules( MUSL_FTS musl-fts )
> diff --git a/games/gzdoom/patches/patch-libraries_ZWidget_CMakeLists_txt
> b/games/gzdoom/patches/patch-libraries_ZWidget_CMakeLists_txt
> new file mode 100644
> index 000..f9dd257c5a3
> --- /dev/null
> +++ b/games/gzdoom/patches/patch-libraries_ZWidget_CMakeLists_txt
> @@ -0,0 +1,12 @@
> +Index: libraries/ZWidget/CMakeLists.txt
> +--- libraries/ZWidget/CMakeLists.txt.orig
> libraries/ZWidget/CMakeLists.txt
> +@@ -127,7 +127,7 @@ elseif(APPLE)
> + add_link_options(-pthread)
> + else()
> + set(ZWIDGET_SOURCES ${ZWIDGET_SOURCES} ${ZWIDGET_SDL2_SOURCES})
> +-set(ZWIDGET_LIBS ${CMAKE_DL_LIBS} -ldl)
> ++set(ZWIDGET_LIBS ${CMAKE_DL_LIBS})
> + add_definitions(-DUNIX -D_UNIX)
> + add_link_options(-pthread)
> + endif()
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/14 02:09:25 Modified files: lang/hashlink : Makefile distinfo lang/hashlink/patches: patch-src_module_c patch-src_std_thread_c Added files: lang/hashlink/patches: patch-src_jit_c Log message: update hashlink to commit from 2024-05-10; tagged as 'latest' While here, patch unsafe sprintf and strcpy to use snprintf/strlcpy. Tested with Dead Cells, Northgard, and Into the Necrovale
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/14 02:05:41 Modified files: games/fna : Makefile.inc games/fna/faudio: distinfo games/fna/fna : distinfo games/fna/fna3d: distinfo games/fna/fna3d/patches: patch-CMakeLists_txt Log message: update FNA ports to latest release 24.05 Release Notes: https://github.com/FNA-XNA/FNA/releases https://github.com/FNA-XNA/FNA3D/releases https://github.com/FNA-XNA/FAudio/releases
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/13 20:50:23 Modified files: games/recoil-rts: Makefile distinfo games/recoil-rts/patches: patch-rts_System_Main_cpp patch-rts_System_Platform_CpuID_cpp Log message: update to latest engine release used by Beyond All Reason, #2472 Release Notes: https://www.beyondallreason.info/microblogs/100
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/13 20:47:04 Modified files: lang/rsm : Makefile distinfo Added files: lang/rsm/patches: patch-Makefile Removed files: lang/rsm/patches: patch-BSDmakefile Log message: update to RSM 1.80.4 Release notes at: https://gitlab.com/Reference-Standard-M/rsm/-/release
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/13 20:43:49 Modified files: editors/novelwriter: Makefile distinfo Log message: Update to 2.4.1 (bugfix release) Release Notes at: https://novelwriter.io/releases/release_2_4.html#main-release-2-4-1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/13 20:39:05 Modified files: games/ezquake : Makefile Log message: update HOMEPAGE, by Tom Murphy (maintainer)
update archivers/py-brotli and drop MAINTAINER
Hi,
Here is an update to archivers/py-brotli to the latest version 1.1.0
from August 2023. I installed it and successfully tested the build of
the direct consumers py-fonttools, py-aiohttp, py-httpbin, and
py-requests.
ok?
As I don't use it anymore I will drop myself from MAINTAINER with/after
this update.
Index: Makefile
===
RCS file: /cvs/ports/archivers/py-brotli/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile6 May 2024 12:22:30 - 1.8
+++ Makefile14 May 2024 00:23:58 -
@@ -1,9 +1,8 @@
COMMENT = Python bindings for the Brotli compression library
-MODPY_EGG_VERSION =1.0.9
+MODPY_EGG_VERSION =1.1.0
DISTNAME = Brotli-${MODPY_EGG_VERSION}
PKGNAME = py-brotli-${MODPY_EGG_VERSION}
-REVISION = 4
CATEGORIES = archivers
@@ -13,8 +12,6 @@ HOMEPAGE =https://github.com/google/br
# MIT
PERMIT_PACKAGE = Yes
-
-EXTRACT_SUFX = .zip
# C++
COMPILER = base-clang ports-gcc base-gcc
Index: distinfo
===
RCS file: /cvs/ports/archivers/py-brotli/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo12 Sep 2020 20:38:14 - 1.1.1.1
+++ distinfo14 May 2024 00:23:58 -
@@ -1,2 +1,2 @@
-SHA256 (Brotli-1.0.9.zip) = TRuBCqDtdz+B3O2izHtAPQEFdFhzDjCYVjVtTvQYhDg=
-SIZE (Brotli-1.0.9.zip) = 510202
+SHA256 (Brotli-1.1.0.tar.gz) = gd4IrBG8uFhB5EDBNhHAC2fTv4JpgxSSjQtnY2JUZyQ=
+SIZE (Brotli-1.1.0.tar.gz) = 7372270
retire devel/dnspy?
Hi, I have no use for this port anymore and upstream has archived the repo and hasn't made any changes since 2020. I haven't used it recently and dnSpy is probably not up-to-date with the recent developments and releases in .NET. ok to retire it?
retire audio/py-fsb5
Hi, When I imported it, I had plans to include this in a project, but this never materialized. Upstream is also dead with the last commit in 2017. ok to send it to the attic?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/11 12:01:17 Modified files: games/recoil-rts: Makefile Log message: Don't build on !x86 arches. Recoil makes heavy use of SSE.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/10 14:12:48 Modified files: games/love/0.10: Makefile Log message: disable LuaJIT for love/0.10 This removes a barrier to updating luajit to 2.1 per sthen@ diff by sthen@ ok op@ (maintainer) Note with this, a few commercial games that depend on LuaJIT don't launch anymore (Blue Revolver, Cityglitch, Spellrazor). Others still work and so does games/orthorobot
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/10 08:25:40 Modified files: games/openarena: Makefile Log message: USE_NOBTCFI for openarena diff from sthen@, issue raised by Divan Santana ( divan AT santanas ! co ! za )
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/10 08:19:49 Modified files: devel/sdl2 : Makefile distinfo devel/sdl2/patches: patch-configure patch-src_joystick_SDL_gamecontrollerdb_h Log message: update to SDL 2.30.3, catching up with several bug fix releases
Re: luajit, arm64, games/love/0.10
On Fri, May 10, 2024 at 09:44:42AM -0400, Thomas Frohwein wrote:
> On Fri, May 10, 2024 at 11:31:54AM +0100, Stuart Henderson wrote:
> > +cc op@, sorry I missed the maintainer line in ../Makefile.inc
> > [ original mail: https://marc.info/?l=openbsd-ports=171528886832093=2 ]
> >
> > On 2024/05/09 20:06, Thomas Frohwein wrote:
> > > On Thu, May 09, 2024 at 10:09:39PM +0100, Stuart Henderson wrote:
> > >
> > > [...]
> > >
> > > > How useful is love/0.10, does it still make sense to keep it?
> > >
> > > There are a couple of nice (commercial) games that run with love-0.10:
> > >
> > > $ ls -1 0.10
> > > blue-revolver
> > > britebot
> > > cityglitch
> > > marvellous-inc
> > > pocket-rumble
> > > soulstice
> > > spellrazor
> > >
> > > From my side not a reason to keep aging version of luajit alive and I
> > > would be ok with marking love/0.10 BROKEN to give a little time to see
> > > if it can be patched up to work with the luajit update...
> > >
> >
> > For the error I'm running into, it looks like it would be fixed by an
> > update to newer luasocket, though the commit which updates it in the
> > love2d tree is huge -
> > https://github.com/love2d/love/commit/8885fc621dd01c3b8dfd1abf063785103d9daf15.patch
> > - and doesn't directly apply to the version in 0.10.2 (and there's no
> > 0.10 branch in their git repo so tracking down other needed commits is
> > a bit awkward).
> >
> > How much would it suck to disable the jit for this version as is
> > already done for 0.8?
>
> I've built it with your diff and ran a few that I could: orthorobot
> from packages, as well as Britebot, Marvellous Inc., and Soulstice.
> All run fine. This is on a high-end CPU (Intel Xeon W-11955M), so the
> effect of not using the JIT may be more noticeable on lower end
> hardware. But this is still all very niche, so I think disabling the
> JIT is the right move. ok thfr@
Just realized the games that I couldn't run (Blue Revolver, Britebot,
Spellrazor) still run with LuaJIT, so the diff breaks them. I still
think it's the right move for now to disable the JIT for love-0.10 at
this point.
Here the errors when running without JIT in case this means more to
someone else:
Spellrazor:
Error: Syntax error: main.lua:1: unexpected symbol near '#'
stack traceback:
(tail call): ?
[C]: ?
[C]: in function 'require'
[string "boot.lua"]:429: in function <[string "boot.lua"]:275>
[C]: in function 'xpcall'
Blue Revolver (and similar with Cityglitch):
Error: lib/bitser.lua:24: module 'ffi' not found:
no field package.preload['ffi']
no 'ffi' in LOVE game directories.
no file 'ffi.so' in LOVE paths.
no file './ffi.lua'
no file '/usr/local/share/lua/5.1/ffi.lua'
no file '/usr/local/share/lua/5.1/ffi/init.lua'
no file '/usr/local/lib/lua/5.1/ffi.lua'
no file '/usr/local/lib/lua/5.1/ffi/init.lua'
no file './ffi.so'
no file '/usr/local/lib/lua/5.1/ffi.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
(tail call): ?
[C]: in function 'require'
lib/bitser.lua:24: in main chunk
[C]: in function 'require'
game/replayplaylist.lua:2: in main chunk
[C]: in function 'require'
game/states/loading.lua:7: in main chunk
[C]: in function 'require'
main.lua:53: in main chunk
[C]: in function 'require'
[string "boot.lua"]:429: in function <[string "boot.lua"]:275>
[C]: in function 'xpcall'
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/games/love/0.10/Makefile,v
> > diff -u -p -r1.2 Makefile
> > --- Makefile23 Jun 2023 17:35:54 - 1.2
> > +++ Makefile10 May 2024 10:22:57 -
> > @@ -1,5 +1,6 @@
> > VERSION = 0.10.2
> > -REVISION = 0
> > +USE_LUAJIT = No
> > +REVISION = 1
> >
> > SHARED_LIBS= love-${VERSION} 0.0
> >
>
Re: luajit, arm64, games/love/0.10
On Fri, May 10, 2024 at 11:31:54AM +0100, Stuart Henderson wrote:
> +cc op@, sorry I missed the maintainer line in ../Makefile.inc
> [ original mail: https://marc.info/?l=openbsd-ports=171528886832093=2 ]
>
> On 2024/05/09 20:06, Thomas Frohwein wrote:
> > On Thu, May 09, 2024 at 10:09:39PM +0100, Stuart Henderson wrote:
> >
> > [...]
> >
> > > How useful is love/0.10, does it still make sense to keep it?
> >
> > There are a couple of nice (commercial) games that run with love-0.10:
> >
> > $ ls -1 0.10
> > blue-revolver
> > britebot
> > cityglitch
> > marvellous-inc
> > pocket-rumble
> > soulstice
> > spellrazor
> >
> > From my side not a reason to keep aging version of luajit alive and I
> > would be ok with marking love/0.10 BROKEN to give a little time to see
> > if it can be patched up to work with the luajit update...
> >
>
> For the error I'm running into, it looks like it would be fixed by an
> update to newer luasocket, though the commit which updates it in the
> love2d tree is huge -
> https://github.com/love2d/love/commit/8885fc621dd01c3b8dfd1abf063785103d9daf15.patch
> - and doesn't directly apply to the version in 0.10.2 (and there's no
> 0.10 branch in their git repo so tracking down other needed commits is
> a bit awkward).
>
> How much would it suck to disable the jit for this version as is
> already done for 0.8?
I've built it with your diff and ran a few that I could: orthorobot
from packages, as well as Britebot, Marvellous Inc., and Soulstice.
All run fine. This is on a high-end CPU (Intel Xeon W-11955M), so the
effect of not using the JIT may be more noticeable on lower end
hardware. But this is still all very niche, so I think disabling the
JIT is the right move. ok thfr@
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/love/0.10/Makefile,v
> diff -u -p -r1.2 Makefile
> --- Makefile 23 Jun 2023 17:35:54 - 1.2
> +++ Makefile 10 May 2024 10:22:57 -
> @@ -1,5 +1,6 @@
> VERSION =0.10.2
> -REVISION = 0
> +USE_LUAJIT = No
> +REVISION = 1
>
> SHARED_LIBS= love-${VERSION} 0.0
>
Re: openarena crash 7.5
On Thu, May 09, 2024 at 07:22:50PM +0200, Divan Santana wrote: > Greetings :) > > Is openarena suppose to work from ports? Or perhaps it's my laptop > that's not compatible with it? This issue is fine to raise on ports@. It's a BTCFI issue, see from ktrace(1)/kdump(1) output: 67964 openarena-client PSIG SIGILL SIG_DFL code=ILL_BTCFI addr=0xf9ba34f3000 trapno=21 > > ds@swift ~ $ /usr/local/bin/openarena-client > ioq3+oa 1.36 openbsd-amd64 Mar 15 2024 > - FS_Startup - > Current search path: > /home/ds//.openarena/baseoa > /usr/local/share/openarena/baseoa/pak6-patch088.pk3 (711 files) > /usr/local/share/openarena/baseoa/pak6-patch085.pk3 (559 files) > /usr/local/share/openarena/baseoa/pak6-misc.pk3 (229 files) > /usr/local/share/openarena/baseoa/pak5-TA.pk3 (139 files) > /usr/local/share/openarena/baseoa/pak4-textures.pk3 (1753 files) > /usr/local/share/openarena/baseoa/pak2-players.pk3 (669 files) > /usr/local/share/openarena/baseoa/pak2-players-mature.pk3 (231 files) > /usr/local/share/openarena/baseoa/pak1-maps.pk3 (100 files) > /usr/local/share/openarena/baseoa/pak0.pk3 (1042 files) > /usr/local/share/openarena/baseoa > > -- > 5433 files in pk3 files > execing default.cfg > couldn't exec q3config.cfg > couldn't exec autoexec.cfg > Hunk_Clear: reset the hunk ok > > (zenity:54194): Gtk-WARNING **: 19:07:49.508: Failed to parse > /home/ds/.config/gtk-4.0/settings.ini: Key file does not start with a group > - Client Initialization - > Couldn't read q3history. > - Initializing Renderer > --- > QKEY building random string > QKEY generated > - Client Initialization Complete - > - R_Init - > SDL using driver "x11" > Initializing OpenGL display > Estimated display aspect: 1.778 > ...setting mode 3: 640 480 > Using 8/8/8 Color bits, 24 depth, 8 stencil display. > Available modes: '320x180 432x243 480x270 512x288 640x360 720x405 800x450 > 864x486 960x540 1024x576 1280x720 1440x810 1600x900 1920x1080 2560x1440 > 360x202 684x384 1368x768 640x400 840x525 960x600 1280x800 1680x1050 700x450 > 1400x900 320x240 400x300 512x384 640x480 700x525 800x600 896x672 928x696 > 960x720 1024x768 1280x960 1400x1050 640x512 1280x1024' > GL_RENDERER: Mesa Intel(R) Graphics (ADL GT2) > Initializing OpenGL extensions > ...ignoring GL_EXT_texture_compression_s3tc > ...ignoring GL_S3_s3tc > ...using GL_EXT_texture_env_add > ...using GL_ARB_multitexture > ...using GL_EXT_compiled_vertex_array > ...ignoring GL_EXT_texture_filter_anisotropic > ...ignoring GL_ARB_vertex_shader > > GL_VENDOR: Intel > GL_RENDERER: Mesa Intel(R) Graphics (ADL GT2) > GL_VERSION: 4.6 (Compatibility Profile) Mesa 23.1.9 > GL_EXTENSIONS: GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color > GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture > GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array > GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D > GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements > GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal > GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp > GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp > GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB > GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays > GL_IBM_texture_mirrored_repeat GL_3DFX_texture_compression_FXT1 > GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix > GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays > GL_EXT_secondary_color GL_EXT_texture_env_add > GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias > GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent > GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc > GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp > GL_ARB_texture_compression GL_EXT_framebuffer_object > GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine > GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil > GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query > GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar > GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos > GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map > GL_NV_depth_clamp GL_NV_fog_distance GL_NV_half_float GL_APPLE_packed_pixels > GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader > GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader > GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float > GL_EXT_depth_bounds_test GL_EXT_shadow_funcs GL_EXT_stencil_wrap > GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp > GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel > GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 > GL_ARB_sync
Re: luajit, arm64, games/love/0.10
On Thu, May 09, 2024 at 10:09:39PM +0100, Stuart Henderson wrote: [...] > How useful is love/0.10, does it still make sense to keep it? There are a couple of nice (commercial) games that run with love-0.10: $ ls -1 0.10 blue-revolver britebot cityglitch marvellous-inc pocket-rumble soulstice spellrazor >From my side not a reason to keep aging version of luajit alive and I would be ok with marking love/0.10 BROKEN to give a little time to see if it can be patched up to work with the luajit update...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/05 18:29:29 Modified files: games/recoil-rts: Makefile distinfo games/recoil-rts/patches: patch-AI_Skirmish_BARb_src_circuit_module_EconomyManager_cpp patch-rts_System_MemPoolTypes_h patch-rts_System_Platform_Linux_CrashHandler_cpp patch-rts_System_Platform_Misc_cpp patch-rts_System_Platform_Threading_h patch-rts_System_Platform_byteorder_h patch-test_CMakeLists_txt Removed files: games/recoil-rts/patches: patch-doc_CMakeLists_txt patch-rts_CMakeLists_txt patch-rts_Rendering_Env_Decals_GroundDecalHandler_cpp patch-rts_Rendering_Units_UnitDrawerData_cpp patch-rts_Sim_Features_FeatureMemPool_h patch-rts_Sim_Path_HAPFS_PathMemPool_h patch-rts_Sim_Projectiles_ExplosionGenerator_cpp patch-rts_Sim_Projectiles_ProjectileMemPool_h patch-rts_Sim_Units_UnitMemPool_h patch-rts_Sim_Weapons_WeaponMemPool_h patch-rts_System_EventClient_h patch-rts_System_FileSystem_Archives_VirtualArchive_cpp patch-rts_System_Platform_Threading_cpp patch-rts_System_Sound_OpenAL_SoundSource_cpp patch-rts_System_SpringApp_cpp patch-rts_builds_dedicated_CMakeLists_txt patch-test_other_testMemPoolTypes_cpp Log message: catch up to more recent release used by BAR; a lot of patches upstreamed
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/05 11:19:38 Modified files: games : Makefile Log message: +recoil-rts
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/05 11:18:13 Log message: import games/recoil-rts, ok solene@ DESCR: Recoil is a battle tested open-source RTS engine, successor of Spring. It is designed, in its basis, to be able to run the content of the game Total Annihilation and deliver a similar, but improved, gaming experience. Games can be intense and very large scaled, with fight of, literally, hundreds of units and the mods allow very wide arrays of different strategies and tactics. Some of the games powered by Recoil: Beyond All Reason, ZeroK, TA Prime and Metal Factions. Status: Vendor Tag: thfr Release Tags: thfr_20240505 N ports/games/recoil-rts/Makefile N ports/games/recoil-rts/distinfo N ports/games/recoil-rts/patches/patch-AI_Skirmish_BARb_src_circuit_module_EconomyManager_cpp N ports/games/recoil-rts/patches/patch-AI_Skirmish_BARb_src_lib_angelscript_add_on_scriptbuilder_scriptbuilder_cpp N ports/games/recoil-rts/patches/patch-rts_CMakeLists_txt N ports/games/recoil-rts/patches/patch-AI_Skirmish_CircuitAI_src_lib_angelscript_add_on_scriptbuilder_scriptbuilder_cpp N ports/games/recoil-rts/patches/patch-rts_Lua_LuaUtils_cpp N ports/games/recoil-rts/patches/patch-doc_CMakeLists_txt N ports/games/recoil-rts/patches/patch-rts_Rendering_Env_Decals_GroundDecalHandler_cpp N ports/games/recoil-rts/patches/patch-rts_System_EventClient_h N ports/games/recoil-rts/patches/patch-rts_build_cmake_ConfigureVersion_cmake N ports/games/recoil-rts/patches/patch-rts_Sim_Misc_SmoothHeightMesh_h N ports/games/recoil-rts/patches/patch-rts_Sim_Projectiles_ExplosionGenerator_cpp N ports/games/recoil-rts/patches/patch-rts_System_GlobalRNG_h N ports/games/recoil-rts/patches/patch-rts_System_FileSystem_Archives_VirtualArchive_cpp N ports/games/recoil-rts/patches/patch-rts_System_FileSystem_DataDirLocater_cpp N ports/games/recoil-rts/patches/patch-rts_System_MemPoolTypes_h N ports/games/recoil-rts/patches/patch-rts_System_Platform_CpuID_cpp N ports/games/recoil-rts/patches/patch-rts_System_Platform_Linux_CrashHandler_cpp N ports/games/recoil-rts/patches/patch-rts_System_Platform_Misc_cpp N ports/games/recoil-rts/patches/patch-rts_System_Platform_Linux_ThreadSupport_cpp N ports/games/recoil-rts/patches/patch-rts_System_Platform_Linux_ThreadSupport_h N ports/games/recoil-rts/patches/patch-rts_System_Platform_Threading_cpp N ports/games/recoil-rts/patches/patch-rts_System_Platform_Threading_h N ports/games/recoil-rts/patches/patch-rts_System_Platform_byteorder_h N ports/games/recoil-rts/patches/patch-rts_System_Sound_OpenAL_SoundSource_cpp N ports/games/recoil-rts/patches/patch-rts_System_SpringApp_cpp N ports/games/recoil-rts/patches/patch-rts_System_SpringHashMap_hpp N ports/games/recoil-rts/patches/patch-rts_System_SpringHashSet_hpp N ports/games/recoil-rts/patches/patch-rts_lib_fmt_os_h N ports/games/recoil-rts/patches/patch-test_CMakeLists_txt N ports/games/recoil-rts/patches/patch-rts_builds_dedicated_CMakeLists_txt N ports/games/recoil-rts/patches/patch-rts_lib_asio_include_asio_detail_impl_posix_event_ipp N ports/games/recoil-rts/patches/patch-rts_lib_assimp_CMakeLists_txt N ports/games/recoil-rts/patches/patch-rts_lib_assimp_code_CMakeLists_txt N ports/games/recoil-rts/patches/patch-rts_lib_assimp_code_DefaultIOStream_cpp N ports/games/recoil-rts/patches/patch-rts_lib_libcpuid_libcpuid_cpuid_main_c N ports/games/recoil-rts/patches/patch-rts_lib_libcpuid_libcpuid_rdtsc_c N ports/games/recoil-rts/patches/patch-rts_lib_lua_src_ldo_cpp N ports/games/recoil-rts/patches/patch-rts_lib_lua_src_lmathlib_cpp N ports/games/recoil-rts/patches/patch-rts_lib_lua_src_loadlib_cpp N ports/games/recoil-rts/patches/patch-rts_lib_streflop_CMakeLists_txt N ports/games/recoil-rts/patches/patch-rts_lib_xsimd_config_xsimd_align_hpp N ports/games/recoil-rts/patches/patch-rts_lib_xsimd_memory_xsimd_aligned_allocator_hpp N ports/games/recoil-rts/patches/patch-tools_pr-downloader_src_CMakeLists_txt N ports/games/recoil-rts/patches/patch-tools_pr-downloader_src_Version_h N ports/games/recoil-rts/patches/patch-tools_pr-downloader_src_lib_minizip_ioapi_h N ports/games/recoil-rts/patches/patch-rts_lib_lua_include_luaconf_h N ports/games/recoil-rts/patches/patch-tools_pr-downloader_src_lib_readerwriterqueue_benchmarks_systemtime_h N ports/games/recoil-rts/patches/patch-rts_Rendering_Units_UnitDrawerData_cpp N ports/games/recoil-rts/patches/patch-rts_Sim_Features_FeatureMemPool_h N ports/games/recoil-rts/patches/patch-rts_Sim_Path_HAPFS_PathMemPool_h N ports/games/recoil-rts/patches/patch-rts_Sim_Projectiles_ProjectileMemPool_h N ports/games/recoil-rts/patches/patch-rts_Sim_Units_UnitMemPool_h
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/04 14:41:53 Modified files: games/py-steam : Makefile distinfo games/py-steam/patches: patch-setup_py games/py-steam/pkg: PLIST Added files: games/py-steam/patches: patch-requirements_txt patch-steam_client_builtins_apps_py Removed files: games/py-steam/patches: patch-steam_egg-info_requires_txt Log message: unbreak py3-steam and steamctl by switching to source with protobuf files regenerated with our more up-to-date version
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/04 14:24:52 Modified files: games : Makefile Log message: +keeperrl
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/04 14:23:36 Log message: import games/keeperrl, ok solene@ DESCR: KeeperRL is an ambitious dungeon simulator with roguelike and RPG elements. Take the role of an evil wizard and study the methods of black magic. Equip your minions and explore the world, murder innocent villagers and burn their homes. Build your dungeon, lay traps and prepare for an assault of angry heroes. When you control your minions the game changes into a classic roguelike, with turn-based and very tactical combat. You can also play as an adventurer and assault dungeons made by you or other players. Status: Vendor Tag: thfr Release Tags: thfr_20240504 N ports/games/keeperrl/Makefile N ports/games/keeperrl/distinfo N ports/games/keeperrl/patches/patch-Makefile N ports/games/keeperrl/patches/patch-steam_internal_h N ports/games/keeperrl/patches/patch-steam_achievements_cpp N ports/games/keeperrl/patches/patch-steam_input_cpp N ports/games/keeperrl/patches/patch-steam_base_cpp N ports/games/keeperrl/patches/patch-steam_call_result_h N ports/games/keeperrl/patches/patch-steam_client_cpp N ports/games/keeperrl/patches/patch-steam_ugc_cpp N ports/games/keeperrl/patches/patch-steam_friends_cpp N ports/games/keeperrl/patches/patch-steam_user_cpp N ports/games/keeperrl/patches/patch-steam_utils_cpp N ports/games/keeperrl/pkg/DESCR N ports/games/keeperrl/pkg/PLIST N ports/games/keeperrl/pkg/README No conflicts created by this import
Re: update games/openttd
On Sat, May 04, 2024 at 01:29:18PM +0200, Solene Rapenne wrote: > a simple bugfix release > https://cdn.openttd.org/openttd-releases/14.1/changelog.txt > > the removed patch is now present upstream > > tested on amd64, worked fine > > ok? Thanks for the update, builds and runs here, too. I noticed the output shows multiple lines of: fluidsynth: error: fluid_is_soundfont(): fopen() failed: 'File does not exist.' Digging through the code, I see that this loops[1] over a list of file paths for soundfont files[2], none of which are OpenBSD paths. I don't know if it would useful/interesting to add for example /usr/local/share/generaluser-gs/GeneralUser_GS.sf2 from the package generaluser-gs-soundfont... This is something to maybe consider exploring at some point? Either way, it still runs (including audio), so update is ok thfr@ [1] https://github.com/OpenTTD/OpenTTD/blob/14.1/src/music/fluidsynth.cpp#L99 [2] https://github.com/OpenTTD/OpenTTD/blob/14.1/src/music/fluidsynth.cpp#L31 > > diff --git a/games/openttd/Makefile b/games/openttd/Makefile > index 93bc2f773e3..196d46e20b1 100644 > --- a/games/openttd/Makefile > +++ b/games/openttd/Makefile > @@ -1,6 +1,6 @@ > COMMENT= open source clone of the game Transport Tycoon Deluxe > > -V = 14.0 > +V = 14.1 > DISTNAME = openttd-$V-source > PKGNAME =openttd-$V > > diff --git a/games/openttd/distinfo b/games/openttd/distinfo > index 6280a398312..5b5c852a3ae 100644 > --- a/games/openttd/distinfo > +++ b/games/openttd/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (openttd/openttd-14.0-source.tar.xz) = > lvdquFiBal4wA4reBpLm6/NQufcL8Zx7SN2oRciEGLE= > -SIZE (openttd/openttd-14.0-source.tar.xz) = 7997536 > +SHA256 (openttd/openttd-14.1-source.tar.xz) = > LBTI8B9EFIxPLIjBaaMKvNsALrEoqSua23a6p2sBNJQ= > +SIZE (openttd/openttd-14.1-source.tar.xz) = 8015032 > diff --git a/games/openttd/patches/patch-src_core_random_func_cpp > b/games/openttd/patches/patch-src_core_random_func_cpp > deleted file mode 100644 > index 5b1654c5db0..000 > --- a/games/openttd/patches/patch-src_core_random_func_cpp > +++ /dev/null > @@ -1,12 +0,0 @@ > -Index: src/core/random_func.cpp > src/core/random_func.cpp.orig > -+++ src/core/random_func.cpp > -@@ -113,7 +113,7 @@ void RandomBytesWithFallback(std::span buf) > - #if defined(_WIN32) > - auto res = BCryptGenRandom(nullptr, static_cast(buf.data()), > static_cast(buf.size()), BCRYPT_USE_SYSTEM_PREFERRED_RNG); > - if (res >= 0) return; > --#elif defined(__APPLE__) || defined(__NetBSD__) || defined(__FreeBSD__) > -+#elif defined(__APPLE__) || defined(__NetBSD__) || defined(__FreeBSD__) || > defined(__OpenBSD__) > - arc4random_buf(buf.data(), buf.size()); > - return; > - #elif defined(__GLIBC__) && ((__GLIBC__ > 2) || ((__GLIBC__ == 2) && > (__GLIBC_MINOR__ >= 25))) >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/03 21:04:40 Modified files: games/rigg : Makefile distinfo Log message: update to rigg 1.1 which includes mainly fixes to test and install targets
Re: update games/hyperrogue
On Fri, May 03, 2024 at 06:44:56PM +0200, Solene Rapenne wrote:
> On Thu, May 02, 2024 at 01:07:08PM GMT, Thomas Frohwein wrote:
> > On Fri, Apr 19, 2024 at 10:27:49PM +0200, Solene Rapenne wrote:
> > > our hyperrogue version is quite old of a dozen releases
> > >
> > > latest release adds a lot of changes
> > > https://github.com/zenorogue/hyperrogue/releases
> > >
> > > the Makefile patch had to be reworked a bit because the original
> > > Makefile differed from the patch, but it applies the same changes
> > > as before.
> > >
> > > update-plist removed some honeycomb files, I don't know if it's
> > > expected... the game plays fine
> >
> > Built it and it works as expected.
> >
> > Noticed that it save hyperrogue.log in $PWD which I find annoying, not
> > sure if that's how upstream designed it. It would make more sense to
> > have a location in the home directory for that. Might be worth checking
> > on, but either way this update is ok thfr@, provided Brian is okay with
> > it or timeout...
>
>
> it also saves settings in $PWD...This can be solved by compiling
> with -DFHS to have the files saved in $HOME/
>
> Not sure if the place I've put it into CXXFLAGS variable is ok?
>
> you can try quickly in game: open settings menu and choose "save"
Making this part of CXXFLAGS looks correct to me. With this, I can now
hear music (I don't think that was there before). The save/log file is
now at ~/.hyperrogue.log. I don't know where the settings
(hyperrogue.ini) are supposed to be; I can't find the file. And after
closing the game, it seems that my settings are set back to the
default.
I've looked if there is more documentation for -DFHS, but it's quite
obscure. It seems to be set by many of the linux build pathways. It's
also in sound.cpp and util.cpp, where it seems to make it look for
files in /usr/share/hyperrogue which of course doesn't exist in our
port and should be /usr/local/share/hyperrogue/...
>
> diff --git a/games/hyperrogue/Makefile b/games/hyperrogue/Makefile
> index 4c1a7417f10..3b211a563a9 100644
> --- a/games/hyperrogue/Makefile
> +++ b/games/hyperrogue/Makefile
> @@ -1,4 +1,4 @@
> -V = 12.0f
> +V = 13.0d
> COMMENT =roguelike game in a non-Euclidean world
> CATEGORIES = games x11
>
> @@ -24,7 +24,7 @@ LIB_DEPENDS = devel/sdl-gfx \
> graphics/glew \
> graphics/png
>
> -CXXFLAGS += -I${LOCALBASE}/include -I${X11BASE}/include \
> +CXXFLAGS += -I${LOCALBASE}/include -I${X11BASE}/include -DFHS\
> -DHYPERPATH="\\\"${LOCALBASE}/share/hyperrogue/\\\""
> LDFLAGS += -L${LOCALBASE}/lib -L${X11BASE}/lib
>
> diff --git a/games/hyperrogue/distinfo b/games/hyperrogue/distinfo
> index 835425d2f49..fe08e61d88c 100644
> --- a/games/hyperrogue/distinfo
> +++ b/games/hyperrogue/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (hyperrogue-12.0f.tar.gz) =
> ROeOk+0dMZg9680EeR1//Pz73EBpfnCaD2yi04wwID4=
> -SIZE (hyperrogue-12.0f.tar.gz) = 79946099
> +SHA256 (hyperrogue-13.0d.tar.gz) =
> 4ApHLRReh9u3dzH+FXCHyB2N5b0rBfogkbyQGFMIDoo=
> +SIZE (hyperrogue-13.0d.tar.gz) = 87765129
> diff --git a/games/hyperrogue/patches/patch-Makefile
> b/games/hyperrogue/patches/patch-Makefile
> index 1567a49854b..6d4afc867d8 100644
> --- a/games/hyperrogue/patches/patch-Makefile
> +++ b/games/hyperrogue/patches/patch-Makefile
> @@ -26,9 +26,9 @@ Index: Makefile
>
> -ifeq (${TOOLCHAIN},clang)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native -fPIC
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -Werror -pedantic
> -- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized -Wno-unknown-warning-option
> +- CXXFLAGS_EARLY += -fPIC
> +- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -pedantic
> +- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized -Wno-char-subscripts -Wno-unknown-warning-option
> - CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> +CXXFLAGS_STD = -std=c++11
> @@ -39,23 +39,23 @@ Index: Makefile
>
> -ifeq (${TOOLCHAIN},gcc)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native -fPIC
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror -pedantic
> +- CXXFLAGS_EARLY += -fPIC
> +- CXXFLAGS_EARLY += -W -Wall -Wextra -pedantic
> - CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized
> +- CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> -
> -ifeq (${TOOLCHAIN},mingw)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=na
Update: devel/sdl2 to latest release 2.30.3
Hi,
This diff catches up to the latest release of SDL, 2.30.3. No dynamic
export changes from our current version in ports (2.30.0). The release
notes (see [1]) show 2.30.1-2.30.3 are stable bugfix releases that also
add support for a few more game controllers.
I built and ran a handful of consumers without any breakage. Planning
to commit this in the next days if no concerns/issues, but feel free to
test!
[1] https://github.com/libsdl-org/SDL/releases
Index: Makefile
===
RCS file: /cvs/ports/devel/sdl2/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
--- Makefile24 Feb 2024 17:34:36 - 1.57
+++ Makefile3 May 2024 18:04:32 -
@@ -1,9 +1,8 @@
COMMENT= cross-platform multimedia library
-V= 2.30.0
+V= 2.30.3
DISTNAME= SDL2-${V}
PKGNAME= sdl2-${V}
-REVISION= 1
CATEGORIES=devel
SITES= https://www.libsdl.org/release/
Index: distinfo
===
RCS file: /cvs/ports/devel/sdl2/distinfo,v
retrieving revision 1.23
diff -u -p -r1.23 distinfo
--- distinfo23 Feb 2024 20:33:55 - 1.23
+++ distinfo3 May 2024 18:04:32 -
@@ -1,2 +1,2 @@
-SHA256 (SDL2-2.30.0.tar.gz) = NuLkFVfg+koVGTFcD1lYqHzLJ+JcUXdr628SOVJkR7A=
-SIZE (SDL2-2.30.0.tar.gz) = 7428037
+SHA256 (SDL2-2.30.3.tar.gz) = ggRABy+PW1AYjB2uEE8q0lmE3iaHhb5AxBoJmlEPCuw=
+SIZE (SDL2-2.30.3.tar.gz) = 7425677
Index: patches/patch-configure
===
RCS file: /cvs/ports/devel/sdl2/patches/patch-configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-configure
--- patches/patch-configure 23 Feb 2024 20:33:55 - 1.2
+++ patches/patch-configure 3 May 2024 18:04:32 -
@@ -2,7 +2,7 @@ prevent from using linux/input.h if pres
Index: configure
--- configure.orig
+++ configure
-@@ -26476,7 +26476,7 @@ main (void)
+@@ -26412,7 +26412,7 @@ main (void)
_ACEOF
if ac_fn_c_try_compile "$LINENO"
then :
Index: patches/patch-src_joystick_SDL_gamecontrollerdb_h
===
RCS file:
/cvs/ports/devel/sdl2/patches/patch-src_joystick_SDL_gamecontrollerdb_h,v
retrieving revision 1.11
diff -u -p -r1.11 patch-src_joystick_SDL_gamecontrollerdb_h
--- patches/patch-src_joystick_SDL_gamecontrollerdb_h 24 Feb 2024 17:34:36
- 1.11
+++ patches/patch-src_joystick_SDL_gamecontrollerdb_h 3 May 2024 18:04:32
-
@@ -1,7 +1,7 @@
Index: src/joystick/SDL_gamecontrollerdb.h
--- src/joystick/SDL_gamecontrollerdb.h.orig
+++ src/joystick/SDL_gamecontrollerdb.h
-@@ -870,6 +870,7 @@ static const char *s_ControllerMappings[] = {
+@@ -871,6 +871,7 @@ static const char *s_ControllerMappings[] = {
"03004c05c4050001,PS4
Controller,a:b1,b:b2,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b12,leftshoulder:b4,leftstick:b10,lefttrigger:a3,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:a4,rightx:a2,righty:a5,start:b9,x:b0,y:b3,",
"03004c05e60c0001,PS5
Controller,a:b1,b:b2,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b12,leftshoulder:b4,leftstick:b10,lefttrigger:a3,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,righttrigger:a4,rightx:a2,righty:a5,start:b9,x:b0,y:b3,",
"03005e048e021001,Xbox 360
Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b8,lefttrigger:a2,leftx:a0,lefty:a1~,rightshoulder:b5,rightstick:b9,righttrigger:a5,rightx:a3,righty:a4~,start:b7,x:b2,y:b3,",
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/05/02 12:44:57 Modified files: games/yquake2 : Makefile distinfo Log message: update to yquake2 8.30. From Tom Murphy who also takes MAINTAINER. ok with former maintainer awolk@
Re: update games/brogue
On Fri, Apr 19, 2024 at 10:07:28PM +0200, Solene Rapenne wrote:
> this updates brogue to latest version, it introduces a quick game
> mode
>
> the Recordings.c patch isn't needed, upstream is now casting the
> variable to unsigned long long instead of our long long, I guess
> it's good enough to drop the patch?
>
> the -Wformat-overflow=0 part in the Makefile was also dropped
> upstream.
The update looks good to me, I've built it and launched the game
successfully. Any word from maintainer? ok thfr@ for the update in this
form.
>
> diff --git a/games/brogue/Makefile b/games/brogue/Makefile
> index 7135bf18124..a73c8e05c4f 100644
> --- a/games/brogue/Makefile
> +++ b/games/brogue/Makefile
> @@ -3,7 +3,7 @@ COMMENT-no_x11 = roguelike game by Brian Walker
>
> GH_ACCOUNT = tmewett
> GH_PROJECT = BrogueCE
> -GH_TAGNAME = v1.12
> +GH_TAGNAME = v1.13
>
> PKGNAME =brogue-${GH_TAGNAME:S/v//}
>
> diff --git a/games/brogue/distinfo b/games/brogue/distinfo
> index 6bed27b849e..71416d88ad5 100644
> --- a/games/brogue/distinfo
> +++ b/games/brogue/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (BrogueCE-1.12.tar.gz) = ru0/bKD041ITewGW6d3b3OVCqemd2p7/2RXgGJI81Cg=
> -SIZE (BrogueCE-1.12.tar.gz) = 1168482
> +SHA256 (BrogueCE-1.13.tar.gz) = TGPpFjmQLVhWWrPChS2JpCBs3WAgC1hfqdk9aliBkGw=
> +SIZE (BrogueCE-1.13.tar.gz) = 1294988
> diff --git a/games/brogue/patches/patch-Makefile
> b/games/brogue/patches/patch-Makefile
> index baef5747b1f..c7a2949a183 100644
> --- a/games/brogue/patches/patch-Makefile
> +++ b/games/brogue/patches/patch-Makefile
> @@ -4,21 +4,12 @@
> Index: Makefile
> --- Makefile.orig
> +++ Makefile
> -@@ -2,7 +2,7 @@ include config.mk
> -
> - cflags := -Isrc/brogue -Isrc/platform -std=c99 \
> - -Wall -Wpedantic -Werror=implicit -Wno-parentheses -Wno-unused-result \
> ---Wformat -Werror=format-security -Wformat-overflow=0
> -+-Wformat -Werror=format-security
> - libs := -lm
> - cppflags := -DDATADIR=$(DATADIR)
> -
> -@@ -41,7 +41,7 @@ ifeq ($(DEBUG),YES)
> - cflags += -g -Og
> - cppflags += -DENABLE_PLAYBACK_SWITCH
> +@@ -62,7 +62,7 @@ ifeq ($(DEBUG),YES)
> + cflags += -g -Og
> + cppflags += -DENABLE_PLAYBACK_SWITCH
> else
> --cflags += -O2
> -+cflags +=
> +-cflags += -O2
> ++cflags +=
> endif
>
> - objects := $(sources:.c=.o)
> + # Add user-provided flags.
> diff --git a/games/brogue/patches/patch-src_brogue_Recordings_c
> b/games/brogue/patches/patch-src_brogue_Recordings_c
> deleted file mode 100644
> index f173d23598b..000
> --- a/games/brogue/patches/patch-src_brogue_Recordings_c
> +++ /dev/null
> @@ -1,18 +0,0 @@
> -cast int64_t to long long for printing
> -
> -Index: src/brogue/Recordings.c
> src/brogue/Recordings.c.orig
> -+++ src/brogue/Recordings.c
> -@@ -1454,10 +1454,10 @@ void parseFile() {
> - numDepths = recallNumber(4);
> - fileLength = recallNumber(4);
> -
> --fprintf(descriptionFile, "Parsed file \"%s\":\n\tVersion:
> %s\n\tSeed: %li\n\tNumber of turns: %li\n\tNumber of depth changes:
> %li\n\tFile length: %li\n",
> -+fprintf(descriptionFile, "Parsed file \"%s\":\n\tVersion:
> %s\n\tSeed: %lli\n\tNumber of turns: %li\n\tNumber of depth changes:
> %li\n\tFile length: %li\n",
> - currentFilePath,
> - versionString,
> --seed,
> -+(long long)seed,
> - numTurns,
> - numDepths,
> - fileLength);
>
Re: update games/hyperrogue
On Fri, Apr 19, 2024 at 10:27:49PM +0200, Solene Rapenne wrote:
> our hyperrogue version is quite old of a dozen releases
>
> latest release adds a lot of changes
> https://github.com/zenorogue/hyperrogue/releases
>
> the Makefile patch had to be reworked a bit because the original
> Makefile differed from the patch, but it applies the same changes
> as before.
>
> update-plist removed some honeycomb files, I don't know if it's
> expected... the game plays fine
Built it and it works as expected.
Noticed that it save hyperrogue.log in $PWD which I find annoying, not
sure if that's how upstream designed it. It would make more sense to
have a location in the home directory for that. Might be worth checking
on, but either way this update is ok thfr@, provided Brian is okay with
it or timeout...
>
> diff --git a/games/hyperrogue/Makefile b/games/hyperrogue/Makefile
> index 4c1a7417f10..b5173d052ca 100644
> --- a/games/hyperrogue/Makefile
> +++ b/games/hyperrogue/Makefile
> @@ -1,4 +1,4 @@
> -V = 12.0f
> +V = 13.0d
> COMMENT =roguelike game in a non-Euclidean world
> CATEGORIES = games x11
>
> diff --git a/games/hyperrogue/distinfo b/games/hyperrogue/distinfo
> index 835425d2f49..fe08e61d88c 100644
> --- a/games/hyperrogue/distinfo
> +++ b/games/hyperrogue/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (hyperrogue-12.0f.tar.gz) =
> ROeOk+0dMZg9680EeR1//Pz73EBpfnCaD2yi04wwID4=
> -SIZE (hyperrogue-12.0f.tar.gz) = 79946099
> +SHA256 (hyperrogue-13.0d.tar.gz) =
> 4ApHLRReh9u3dzH+FXCHyB2N5b0rBfogkbyQGFMIDoo=
> +SIZE (hyperrogue-13.0d.tar.gz) = 87765129
> diff --git a/games/hyperrogue/patches/patch-Makefile
> b/games/hyperrogue/patches/patch-Makefile
> index 1567a49854b..6d4afc867d8 100644
> --- a/games/hyperrogue/patches/patch-Makefile
> +++ b/games/hyperrogue/patches/patch-Makefile
> @@ -26,9 +26,9 @@ Index: Makefile
>
> -ifeq (${TOOLCHAIN},clang)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native -fPIC
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -Werror -pedantic
> -- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized -Wno-unknown-warning-option
> +- CXXFLAGS_EARLY += -fPIC
> +- CXXFLAGS_EARLY += -W -Wall -Wextra -Wsuggest-override -pedantic
> +- CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized -Wno-char-subscripts -Wno-unknown-warning-option
> - CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> +CXXFLAGS_STD = -std=c++11
> @@ -39,23 +39,23 @@ Index: Makefile
>
> -ifeq (${TOOLCHAIN},gcc)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native -fPIC
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror -pedantic
> +- CXXFLAGS_EARLY += -fPIC
> +- CXXFLAGS_EARLY += -W -Wall -Wextra -pedantic
> - CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized
> +- CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> -
> -ifeq (${TOOLCHAIN},mingw)
> - CXXFLAGS_STD = -std=c++11
> -- CXXFLAGS_EARLY += -march=native
> -- CXXFLAGS_EARLY += -W -Wall -Wextra -Werror
> +- CXXFLAGS_EARLY += -W -Wall -Wextra
> - CXXFLAGS_EARLY += -Wno-unused-parameter -Wno-implicit-fallthrough
> -Wno-maybe-uninitialized
> +- CXXFLAGS_EARLY += -Wno-invalid-offsetof
> -endif
> -
> --
> - ## We have now finished OS-specific and TOOLCHAIN-specific computations.
> - ## Begin customization points for user-specifiable HYPERROGUE_USE_XXX
> macros.
> -
> -@@ -139,19 +120,19 @@ override CXXFLAGS := $(CXXFLAGS_STD) $(CXXFLAGS_EARLY)
> + ifeq (${FONTCONFIG},1)
> + CXXFLAGS_EARLY += -DFONTCONFIG `pkg-config --cflags fontconfig`
> + LDFLAGS_EARLY += `pkg-config --libs fontconfig`
> +@@ -144,19 +125,19 @@ override CXXFLAGS := $(CXXFLAGS_STD) $(CXXFLAGS_EARLY)
> override LDFLAGS := $(LDFLAGS_EARLY) $(LDFLAGS) ${EXTRA_LDFLAGS}
>
> hyperrogue$(EXE_EXTENSION): $(hyper_OBJS) $(hyper_RES)
> @@ -78,8 +78,8 @@ Index: Makefile
> +$(CXX) $(CXXFLAGS) makeh.cpp $(LDFLAGS) -o $@
>
> autohdr.h: makeh$(EXE_EXTENSION) language-data.cpp *.cpp
> - ./makeh classes.cpp locations.cpp colors.cpp hyperpoint.cpp
> geometry.cpp goldberg.cpp init.cpp floorshapes.cpp cell.cpp multi.cpp
> shmup.cpp pattern2.cpp mapeditor.cpp graph.cpp textures.cpp hprint.cpp
> language.cpp util.cpp complex.cpp *.cpp > autohdr.h
> -@@ -160,10 +141,10 @@ language-data.cpp: langen$(EXE_EXTENSION)
> + ./makeh classes.cpp locations.cpp colors.cpp hyperpoint.cpp
> geometry.cpp embeddings.cpp goldberg.cpp init.cpp floorshapes.cpp cell.cpp
> multi.cpp shmup.cpp pattern2.cpp mapeditor.cpp graph.cpp textures.cpp
> hprint.cpp language.cpp util.cpp complex.cpp multigame.cpp arbitrile.cpp
> rulegen.cpp *.cpp > autohdr.h
> +@@ -165,10 +146,10 @@ language-data.cpp: langen$(EXE_EXTENSION)
> ./langen > language-data.cpp
>
> savepng$(OBJ_EXTENSION): savepng.cpp
> diff --git a/games/hyperrogue/pkg/PLIST b/games/hyperrogue/pkg/PLIST
> index
Re: NEW: games/classicube
On Tue, Apr 30, 2024 at 11:13:40AM +0200, Sebastian Reitenbach wrote: > On Tuesday, April 30, 2024 07:47 CEST, izder456 wrote: > > > Awh jeez. It is too late for this. > > > > Fixed trailing whitespace in pkg/README, as well as removed leftover > > PLIST.orig. > > > > this should be the last of my mails in this thread unless something > > comes up. > > > > OK to merge? > > lgtm, OK sebastia@ So what was the reason for your earlier Error 2 when starting game? > > > > > -- > > -iz (they/them) > > > > > i like to say mundane things, > > > there are too many uninteresting things > > > that go unnoticed. > > > > izder456 (dot) neocities (dot) org >
update for py3-steam to fix protobuf errors
Hi,
The diff below fixes py3-steam and by extension steamctl. Those stopped
working recently because of an incompatibility of the include python
protobuf files with our protobuf version. This was on life support for
a while anyway... upstream had it marked for protobuf~=3.0 which the
port had to bypass since the beginning. The resulting error is attached
in steamctl-error.txt.
Unfortunately, upstream seems to have become inactive (no commits since
last year). While I'm not sure about the future of the project and the
port, I managed to regenerate the protobufs in my fork so that we can
still use it. Given that there is no alternative in ports (the previous
depot downloader requires .NET core and doesn't work with mono), I
think it's still justified to keep py-steam and steamctl alive this
way... There are 1 or 2 active forks that might be candidates for the
future, for example [1].
I'm planning to commit the update if no protest; this is also meant as
an update on the state of py-steam/steamctl.
[1] https://github.com/FailSpy/steam-py-lib/tree/master
Index: Makefile
===
RCS file: /cvs/ports/games/py-steam/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile2 Aug 2023 02:42:55 - 1.6
+++ Makefile1 May 2024 20:23:19 -
@@ -1,9 +1,8 @@
COMMENT = module for interacting with various Steam features
-MODPY_EGG_VERSION =1.4.4
-DISTNAME = steam-${MODPY_EGG_VERSION}
-PKGNAME = py-${DISTNAME}
-REVISION = 0
+PKGNAME = py-steam-1.4.4pl0
+DIST_TUPLE += github rfht py-steam \
+ e26d2eb52c90dc2c07cc88ea910d59bf873d330d .
CATEGORIES = games
HOMEPAGE = https://github.com/ValvePython/steam
@@ -11,7 +10,6 @@ HOMEPAGE =https://github.com/ValvePyth
PERMIT_PACKAGE = Yes
MODULES = lang/python
-MODPY_PI = Yes
MODPY_PYBUILD =setuptools
RUN_DEPENDS = converters/py-vdf${MODPY_FLAVOR} \
Index: distinfo
===
RCS file: /cvs/ports/games/py-steam/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo20 Apr 2023 03:21:59 - 1.3
+++ distinfo1 May 2024 20:23:19 -
@@ -1,2 +1,2 @@
-SHA256 (steam-1.4.4.tar.gz) = K1vWkRwNSnMS9EG40WK52NR8i+u478bIhnOTsDI/pS4=
-SIZE (steam-1.4.4.tar.gz) = 644071
+SHA256 (rfht-py-steam-e26d2eb52c90dc2c07cc88ea910d59bf873d330d.tar.gz) =
pxX2a3DBS2g9f5m6BiAN6qayea8yoMEdNy+dh2vAxXg=
+SIZE (rfht-py-steam-e26d2eb52c90dc2c07cc88ea910d59bf873d330d.tar.gz) = 713366
Index: patches/patch-requirements_txt
===
RCS file: patches/patch-requirements_txt
diff -N patches/patch-requirements_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-requirements_txt 1 May 2024 20:23:19 -
@@ -0,0 +1,17 @@
+Index: requirements.txt
+--- requirements.txt.orig
requirements.txt
+@@ -1,11 +1,10 @@
+ six>=1.10.0
+-pycryptodomex>=3.7.0
++pycryptodome>=3.7.0
+ requests>=2.9.1
+ urllib3<2
+ vdf>=3.3
+ gevent>=1.3.0
+-protobuf~=3.0; python_version >= '3'
+-protobuf<3.18.0; python_version < '3'
++protobuf
+ gevent-eventemitter~=2.1
+ cachetools>=3.0.0
+ enum34==1.1.2; python_version < '3.4'
Index: patches/patch-setup_py
===
RCS file: /cvs/ports/games/py-steam/patches/patch-setup_py,v
retrieving revision 1.2
diff -u -p -r1.2 patch-setup_py
--- patches/patch-setup_py 11 Jun 2022 13:16:12 - 1.2
+++ patches/patch-setup_py 1 May 2024 20:23:19 -
@@ -11,9 +11,9 @@ Index: setup.py
-'pycryptodomex>=3.7.0',
+'pycryptodome>=3.7.0',
'requests>=2.9.1',
+ 'urllib3<2',
'vdf>=3.3',
- 'cachetools>=3.0.0',
-@@ -26,7 +26,7 @@ install_requires = [
+@@ -27,7 +27,7 @@ install_requires = [
install_extras = {
'client': [
'gevent>=1.3.0',
Index: patches/patch-steam_client_builtins_apps_py
===
RCS file: patches/patch-steam_client_builtins_apps_py
diff -N patches/patch-steam_client_builtins_apps_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-steam_client_builtins_apps_py 1 May 2024 20:23:19 -
@@ -0,0 +1,16 @@
+fix:
+AttributeError: Protocol message CMsgClientPICSProductInfoRequest has no
+"supports_package_tokens" field.
+
+Index: steam/client/builtins/apps.py
+--- steam/client/builtins/apps.py.orig
steam/client/builtins/apps.py
+@@ -129,7 +129,7 @@ class Apps(object):
+
+ message.body.meta_data_only = meta_data_only
+ message.body.num_prev_failed = 0
+-message.body.supports_package_tokens = 1
++#message.body.supports_package_tokens = 1
+
+ job_id = self.send_job(message)
+
Index: patches/patch-steam_egg-info_requires_txt
Re: games/yquake2 8.00 -> 8.30
On Tue, Apr 02, 2024 at 01:36:11PM +0100, Tom Murphy wrote:
> Hi,
>
> Here's a diff to update games/yquake2 from 8.00 to 8.30.
> Have only tested the server binary but not the client (as I don't
> have an OpenBSD gaming machine at the moment) and it loads and runs.
>
> Thanks,
> Tom
Including MAINTAINER in the reply. Looks good as long as REVISION line
is also removed.
Adam, if you're not using the port actively, would you be okay with
passing on maintainership?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/yquake2/Makefile,v
> diff -u -p -u -p -r1.29 Makefile
> --- Makefile 6 Feb 2024 12:49:36 - 1.29
> +++ Makefile 2 Apr 2024 12:33:49 -
> @@ -1,6 +1,6 @@
> COMMENT= Yamagi Quake II
> N= yquake2
> -V= 8.00
> +V= 8.30
> PKGNAME= ${N}-${V}
> DISTNAME=quake2-${V}
> CATEGORIES= games
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/yquake2/distinfo,v
> diff -u -p -u -p -r1.11 distinfo
> --- distinfo 15 Dec 2021 13:44:12 - 1.11
> +++ distinfo 2 Apr 2024 12:33:49 -
> @@ -1,2 +1,2 @@
> -SHA256 (quake2-8.00.tar.xz) = YNjRD8K011uWElGZDk2QM1cZSnMhC8HkKSTt74h9DrI=
> -SIZE (quake2-8.00.tar.xz) = 2086776
> +SHA256 (quake2-8.30.tar.xz) = 4tlWOtgm/TflgHjxXbrpi71IOUnymwl9BKgxVrwQm4Y=
> +SIZE (quake2-8.30.tar.xz) = 2165532
>
Re: NEW: games/classicube
On Sat, Apr 27, 2024 at 08:53:31PM -0500, izder456 wrote: > Ohp, minor typo in files/classicube.desktop > > fixed tarball is attached. > > Best- > > -- > -iz (they/them) > > > i like to say mundane things, > > there are too many uninteresting things > > that go unnoticed. > > izder456 (dot) neocities (dot) org Tested it in singleplayer only, builds and runs fine. I don't really know how to play, but looks good. ok thfr@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/04/28 13:56:18 Modified files: games : Makefile Log message: +rigg
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/04/28 13:54:38 Log message: import games/rigg ok brynet@ DESCR: rigg serves as a thin, OpenBSD-adapted runtime wrapper for independent games based on certain engines. rigg handles visibility of files by using unveil(2) to hide those that conflict with execution on OpenBSD. This solves a common problem with commercial games based on open-source frameworks like FNA, LibGDX, or HashLink. In addition, rigg also enforces a minimum-necessary filesystem view by default via unveil(2). Some basic engine configuration for OpenBSD like dllmap for mono(1) is included. Status: Vendor Tag: thfr Release Tags: thfr_20240428 N ports/games/rigg/Makefile N ports/games/rigg/distinfo N ports/games/rigg/pkg/DESCR N ports/games/rigg/pkg/PLIST No conflicts created by this import
Re: New: rigg - program to run independent games with unveil
updated tarball; I had some left over, commented out lines in the Makefile and unnecessary SUBST_*. On Sat, Apr 27, 2024 at 10:20:31PM -0400, Thomas Frohwein wrote: > Hi, > > This is a port of rigg, a tool for running games based on intermediate/ > interpreted language engines on OpenBSD that I created. It improves > over what we have currently with fnaify: > > - By default, it uses unveil to only allow access to a subset of the > filesystem (notably no read or write access to $HOME or $HOME/.ssh). > - It also unveil with zero permissions to hide conflicting bundled > libraries, so that they don't interfere with execution. (fnaify on > the other hand has to rename/move those files) > - It's more focused, not trying to manage custom environment variables > or flags for the execution. > > The principle is that it's a binary that can invoke mono and hashlink > via their libraries (see [1] for mono example). It can replace many of > the use cases for fnaify in ports. Ultimately, there is a plan for a > project (IndieRunner) to supersede fnaify completely with use of rigg > where appropriate. rigg can run the following games and more: Crystal > Project, Dead Cells, Hacknet, Northgard, Nuclear Blaze, Opus Magnum, > Owlboy, Salt and Sanctuary, SpaceChem, Terraria. > > I'm attaching RogueLegacy.log that shows the rigg -v output, including > all the unveil's that the game runs with. > > I had to create a do-install target, will figure out for next release > why the included install target inherited from bsd.prog.mk fails in the > port. > > `make test` fails currently in the port system. This has simple mono > assemblies to demonstrate visibility and invisibility of directories. > I'll work on fixing this for the next release. `make test` works > outside the ports tree (after installation), for those who want to > check this. > > ok to import? > > [1] https://www.mono-project.com/docs/advanced/embedding/ > parsing Dllmap > initializing mono jit for RogueLegacy.exe > opening executable: RogueLegacy.exe > > unveil: /usr/local/share/FNA "r" > unveil: /usr/lib "r" > unveil: /usr/local/lib "r" > unveil: /usr/X11R6 "r" > unveil: /usr/share "r" > unveil: /etc "r" > unveil: /dev "rw" > unveil: /tmp "rwc" > unveil: ."rwc" > unveil: /home/thfr/.config "rwc" > unveil: /home/thfr/.local/share "rwc" > unveil: /home/thfr/.cache/mesa_shader_ca "rwc" > unveil: /home/thfr/.mono "rwc" > unveil: /home/thfr/.sndio"rwc" > unveil: /home/thfr/.Xauthority "rw" > unveil: /home/thfr/.XCompose "rwc" > unveil: /home/thfr/.Xdefaults"rwc" > unveil: FNA.dll "" > unveil: FNA.dll.config "" > unveil: Mono.Posix.dll "" > unveil: Mono.Security.dll"" > unveil: System.Configuration.dll "" > unveil: System.Core.dll "" > unveil: System.Data.dll "" > unveil: System.Drawing.dll "" > unveil: System.Numerics.dll "" > unveil: System.Runtime.Serialization.dll "" > unveil: System.Security.dll "" > unveil: System.Xml.Linq.dll "" > unveil: System.Xml.dll "" > unveil: System.dll "" > unveil: mscorlib.dll "" > unveil: (null) "(null)" > > executing mono jit with the following arguments: "RogueLegacy.exe" > > cleaning up... rigg-1.0.tgz Description: application/tar-gz
New: rigg - program to run independent games with unveil
Hi, This is a port of rigg, a tool for running games based on intermediate/ interpreted language engines on OpenBSD that I created. It improves over what we have currently with fnaify: - By default, it uses unveil to only allow access to a subset of the filesystem (notably no read or write access to $HOME or $HOME/.ssh). - It also unveil with zero permissions to hide conflicting bundled libraries, so that they don't interfere with execution. (fnaify on the other hand has to rename/move those files) - It's more focused, not trying to manage custom environment variables or flags for the execution. The principle is that it's a binary that can invoke mono and hashlink via their libraries (see [1] for mono example). It can replace many of the use cases for fnaify in ports. Ultimately, there is a plan for a project (IndieRunner) to supersede fnaify completely with use of rigg where appropriate. rigg can run the following games and more: Crystal Project, Dead Cells, Hacknet, Northgard, Nuclear Blaze, Opus Magnum, Owlboy, Salt and Sanctuary, SpaceChem, Terraria. I'm attaching RogueLegacy.log that shows the rigg -v output, including all the unveil's that the game runs with. I had to create a do-install target, will figure out for next release why the included install target inherited from bsd.prog.mk fails in the port. `make test` fails currently in the port system. This has simple mono assemblies to demonstrate visibility and invisibility of directories. I'll work on fixing this for the next release. `make test` works outside the ports tree (after installation), for those who want to check this. ok to import? [1] https://www.mono-project.com/docs/advanced/embedding/ rigg-1.0.tgz Description: application/tar-gz parsing Dllmap initializing mono jit for RogueLegacy.exe opening executable: RogueLegacy.exe unveil: /usr/local/share/FNA "r" unveil: /usr/lib "r" unveil: /usr/local/lib "r" unveil: /usr/X11R6 "r" unveil: /usr/share "r" unveil: /etc "r" unveil: /dev "rw" unveil: /tmp "rwc" unveil: ."rwc" unveil: /home/thfr/.config "rwc" unveil: /home/thfr/.local/share "rwc" unveil: /home/thfr/.cache/mesa_shader_ca "rwc" unveil: /home/thfr/.mono "rwc" unveil: /home/thfr/.sndio"rwc" unveil: /home/thfr/.Xauthority "rw" unveil: /home/thfr/.XCompose "rwc" unveil: /home/thfr/.Xdefaults"rwc" unveil: FNA.dll "" unveil: FNA.dll.config "" unveil: Mono.Posix.dll "" unveil: Mono.Security.dll"" unveil: System.Configuration.dll "" unveil: System.Core.dll "" unveil: System.Data.dll "" unveil: System.Drawing.dll "" unveil: System.Numerics.dll "" unveil: System.Runtime.Serialization.dll "" unveil: System.Security.dll "" unveil: System.Xml.Linq.dll "" unveil: System.Xml.dll "" unveil: System.dll "" unveil: mscorlib.dll "" unveil: (null) "(null)" executing mono jit with the following arguments: "RogueLegacy.exe" cleaning up...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/04/25 09:09:07 Modified files: editors/novelwriter: Makefile distinfo editors/novelwriter/pkg: PLIST Log message: update to novelwriter 2.4, release announcements at: https://github.com/vkbo/novelWriter/releases
Re: update games/fheroes2
On Thu, Apr 18, 2024 at 11:53:29PM +0200, Solene Rapenne wrote: > new update for fheroes2, works fine with GOG assets If it works, go ahead with my ok. It'll be another week or so before I'll have time again for updating ports. > > diff --git a/games/fheroes2/Makefile b/games/fheroes2/Makefile > index 142b36cf104..3b790750107 100644 > --- a/games/fheroes2/Makefile > +++ b/games/fheroes2/Makefile > @@ -1,6 +1,6 @@ > COMMENT =engine recreation for Heroes of Might and Magic 2 > > -DIST_TUPLE = github ihhub fheroes2 1.0.12 . > +DIST_TUPLE = github ihhub fheroes2 1.0.13 . > CATEGORIES = games > HOMEPAGE = https://ihhub.github.io/fheroes2/ > MAINTAINER = Thomas Frohwein > diff --git a/games/fheroes2/distinfo b/games/fheroes2/distinfo > index 93372c2df96..e1001b64745 100644 > --- a/games/fheroes2/distinfo > +++ b/games/fheroes2/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (ihhub-fheroes2-1.0.12.tar.gz) = > pbCI/0wcbC4F5y11W7q96MDL6hnevqO1qCtdCLFswr4= > -SIZE (ihhub-fheroes2-1.0.12.tar.gz) = 11949016 > +SHA256 (ihhub-fheroes2-1.0.13.tar.gz) = > 63+WDnfugBLlu6s4W69JWXl+V4RUrOgldKPG/uJPlMg= > +SIZE (ihhub-fheroes2-1.0.13.tar.gz) = 11988273 >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2024/03/09 08:39:37
Modified files:
lang/hashlink : Makefile
lang/hashlink/patches: patch-Makefile patch-libs_mysql_socket_c
patch-src_std_thread_c
Log message:
previous update overwrote the ${CFLAGS} in ${WRKSRC}/Makefile, so honor
those again if changed from default. Also some minor restructuring of
patches coming out of work to upstream them.
Re: No packages found for 7.5 snapshot on arm64
On Sat, Mar 09, 2024 at 02:27:36PM +0500, ofthecentury wrote: > I had a similar problem this week, for amd64. > The 'packages/amd64' folder on the OpenBSD > mirrors for 7.5 snapshot is also empty. So I > just manually set PKG_PATH to 7.4 packages > folder for the time being. This will likely break things. You would be effectively mixing an almost-7.5 base with 7.4 packages. The solution is to point at the snapshots packages directory, which is what -Dsnap does for you. > On Sat, Mar 9, 2024 at 2:15 PM Dmitry Matveyev wrote: > > > > Hi, > > > > I was running an OpenBSD with this description of the iso: OpenBSD > > 7.4-current 2023-11-03 (arm64). A week ago I started getting an error > > trying to install any package: > > > > # pkg_add -Uvi colorls > > Update candidates: quirks-7.12 -> quirks-7.12 > > Update candidates: updatedb-0p0 -> updatedb-0p0 > > quirks-7.12 signed on 2024-03-05T14:52:30Z > > Can't install colorls-7.4 because of libraries > > |library c.99.0 not found > > | /usr/lib/libc.so.98.0 (system): bad major > > Couldn't install colorls-7.4 > > > > Here I have an older version whereas the package requires a newer > > version. > > > > I've read that it might be due to using -current and that I need to > > upgrade my system to the latest snapshot. I have run sysupgrade and now > > uname says that I'm on OpenBSD 7.5 GENERIC.MP#128 arm64. And now I can't > > install anything at all because pkg_add complains that it can't find a > > directory https://ftp.hostserver.de/pub/OpenBSD/7.5/packages/aarch64/. I > > have checked several mirrors at https://www.openbsd.org/ftp.html and > > they indeed don't have any packages under 7.5. > > > > How do I fix this? > > >
Re: [UPDATE] emulators/dosbox-x-2024.03.01
On Fri, Mar 08, 2024 at 09:58:47PM +0900, SASANO Takayoshi wrote:
> Hi,
>
> here is the diff for dosbox-x 2023.10.06 -> 2024.03.01.
>
> ok?
I would recommend running `make update-patches` to update the patch for
Makefile.am, otherwise looks good and runs. ok thfr@
> Index: Makefile
> ===
> RCS file: /cvs/ports/emulators/dosbox-x/Makefile,v
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 21 Feb 2024 12:29:10 - 1.1.1.1
> +++ Makefile 8 Mar 2024 12:57:53 -
> @@ -1,6 +1,6 @@
> COMMENT= x86 with DOS emulator targeted at playing games
>
> -VERSION= 2023.10.06
> +VERSION= 2024.03.01
> DISTNAME=dosbox-x-v${VERSION}
> PKGNAME= dosbox-x-${VERSION}
> CATEGORIES= games x11 emulators
> Index: distinfo
> ===
> RCS file: /cvs/ports/emulators/dosbox-x/distinfo,v
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 21 Feb 2024 12:29:10 - 1.1.1.1
> +++ distinfo 8 Mar 2024 12:57:53 -
> @@ -1,2 +1,2 @@
> -SHA256 (dosbox-x-v2023.10.06.tar.gz) =
> ZfdW4p+cm4mP29IrDLmzskxuO+y13NpYiqIKP96VOaU=
> -SIZE (dosbox-x-v2023.10.06.tar.gz) = 119420489
> +SHA256 (dosbox-x-v2024.03.01.tar.gz) =
> KonTGW3cFTYfbcfmqxQr/pWUXZPVJ8/Wusyh96QBpRM=
> +SIZE (dosbox-x-v2024.03.01.tar.gz) = 119593920
> Index: patches/patch-include_dos_inc_h
> ===
> RCS file: patches/patch-include_dos_inc_h
> diff -N patches/patch-include_dos_inc_h
> --- patches/patch-include_dos_inc_h 21 Feb 2024 12:29:10 - 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,11 +0,0 @@
> include/dos_inc.h.orig.port Mon Nov 27 22:44:22 2023
> -+++ include/dos_inc.hMon Nov 27 22:44:22 2023
> -@@ -390,7 +390,7 @@ static INLINE uint16_t DOS_PackDate(uint16_t year,uint
> -
> -
> - /* Remains some classes used to access certain things */
> --#define sOffset(s,m) ((char*)&(((s*)NULL)->m)-(char*)NULL)
> -+#define sOffset(s,m) offsetof(s,m)
> - #define sGet(s,m) GetIt(sizeof(((s *))->m),(PhysPt)sOffset(s,m))
> - #define sSave(s,m,val) SaveIt(sizeof(((s
> *))->m),(PhysPt)sOffset(s,m),val)
> -
> Index: patches/patch-src_dos_dos_programs_cpp
> ===
> RCS file: patches/patch-src_dos_dos_programs_cpp
> diff -N patches/patch-src_dos_dos_programs_cpp
> --- patches/patch-src_dos_dos_programs_cpp21 Feb 2024 12:29:10 -
> 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,20 +0,0 @@
> src/dos/dos_programs.cpp.origSat Oct 7 14:52:23 2023
> -+++ src/dos/dos_programs.cpp Fri Nov 3 05:51:29 2023
> -@@ -5926,7 +5926,7 @@ class IMGMOUNT : public Program {
> - FILE* newDisk =
> fopen_lock(fname, ro ? "rb" : "rb+", ro);
> - if(!newDisk) {
> -
> if(!qmount) WriteOut("Unable to open '%s'\n", fname);
> --return
> NULL;
> -+return
> false;
> - }
> -
> QCow2Image::QCow2Header qcow2_header = QCow2Image::read_header(newDisk);
> - // uint64_t
> sectors; /* unused */
> -@@ -5936,7 +5936,7 @@ class IMGMOUNT : public Program {
> -
> uint32_t cluster_size = 1u << qcow2_header.cluster_bits;
> -
> if((sizes[0] < 512) || ((cluster_size % sizes[0]) != 0)) {
> -
> WriteOut("Sector size must be larger than 512 bytes and evenly divide the
> image cluster size of %lu bytes.\n", cluster_size);
> --
> return 0;
> -+
> return false;
> - }
> - //
> sectors = (uint64_t)qcow2_header.size / (uint64_t)sizes[0]; /* unused */
> -
> imagesize = (uint32_t)(qcow2_header.size / 1024L);
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/emulators/dosbox-x/pkg/PLIST,v
> diff -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 21 Feb 2024 12:29:10 - 1.1.1.1
> +++ pkg/PLIST 8 Mar 2024 12:57:53 -
> @@ -65,11 +65,13 @@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/03/08 18:52:31 Modified files: lang/hashlink : Makefile distinfo lang/hashlink/patches: patch-Makefile Log message: update hashlink to most recent "latest" tag, tested with Into the Necrovale, Dead Cells, and Northgard
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/03/06 07:17:27 Modified files: games/fna : Makefile.inc games/fna/faudio: Makefile distinfo games/fna/fna : distinfo games/fna/fna3d: distinfo Log message: update FNA ports to 24.03
Re: [update] games/stone-soup to 0.31.0
committed, thanks!
On Mon, Mar 04, 2024 at 02:54:54PM -0500, Stefan Moran wrote:
> On Sun, 3 Mar 2024 22:41:56 -0500
> Thomas Frohwein wrote:
>
> > Two issues mentioned inline.
> >
> > On Sat, Mar 02, 2024 at 05:43:38PM -0500, Stefan Moran wrote:
> > > Update games/stone-soup from 0.30.1 to 0.31.0 "The Alchemy of
> > > Forms". I tried to simplify the Makefile patch a bit, and also
> > > installed the included .desktop file, which was not being installed
> > > for some reason.
> > >
> > > OK?
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/games/stone-soup/Makefile,v
> > > retrieving revision 1.47
> > > diff -u -p -r1.47 Makefile
> > > --- Makefile 12 Nov 2023 14:03:31 - 1.47
> > > +++ Makefile 2 Mar 2024 22:30:23 -
> > > @@ -2,7 +2,8 @@ BROKEN-hppa = ICE on dgn-shoals.cc:638
> > >
> > > COMMENT =dungeon crawl stone soup
> > >
> > > -VERSION =0.30.1
> > > +VERSION =0.31.0
> > > +TAGNAME =The Alchemy of Forms
> > >
> > > DISTNAME=stone_soup-${VERSION}-nodeps
> > > PKGNAME= stone-soup-${VERSION}
> > > @@ -18,6 +19,7 @@ PERMIT_PACKAGE= Yes
> > >
> > > WANTLIB += ${COMPILER_LIBCXX} ${MODLUA_WANTLIB} c m sqlite3
> > >
> > > +# Failover to github, devs are on and off about providing source
> > > on develz.org. SITES =
> > > https://crawl.develz.org/release/${VERSION:R}/ \
> > > https://github.com/crawl/crawl/releases/download/${VERSION}/
> >
> > The DISTNAME would be different at crawl.develz.org, meaning it can't
> > download anything from there. I don't know if we have a mechnism for
> > multiple SITES with different distfiles, but cleanest solution I see
> > is using just github distfiles for now.
>
> Removed, just have SITES pointing at github now.
>
> > > >patches/patch-source_debian_crawl-tiles_desktop
> > > >===
> > > >RCS file: patches/patch-source_debian_crawl-tiles_desktop diff -N
> > > >patches/patch-source_debian_crawl-tiles_desktop
> > > --- patches/patch-source_debian_crawl-tiles_desktop 12 Nov
> > > 2023 14:03:31 - 1.3 +++ /dev/null 1 Jan 1970
> > > 00:00:00 - @@ -1,11 +0,0 @@
> > > source/debian/crawl-tiles.desktop.orig Thu Sep 29
> > > 01:29:00 2016 -+++ source/debian/crawl-tiles.desktop Thu Sep
> > > 29 01:38:51 2016 -@@ -2,6 +2,6 @@
> > > - Type=Application
> > > -
> > > - Name=Dungeon Crawl (tiles)
> > > --Exec=/usr/games/crawl-tiles
> > > --Icon=crawl
> > > -+Exec=/usr/local/bin/crawl-ss
> > > -+Icon=stone-soup
> > > - Categories=Game;AdventureGame;
> >
> > Is this reversed? Here your diff tries to remove the
> > patches/patch-source_debian_crawl-tiles_desktop, but it looks to me
> > like you are trying to add a file here for the .desktop file
>
> I did something weird with my cvs diff (ran diff -rHEAD from the wrong
> tag I think), I regenerated and tested a new diff on HEAD without
> issues. Removing the patch in favor of a locally installed file was
> intended, but I ended up patching out the wrong file it seems.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/stone-soup/Makefile,v
> retrieving revision 1.47
> diff -u -p -r1.47 Makefile
> --- Makefile 12 Nov 2023 14:03:31 - 1.47
> +++ Makefile 4 Mar 2024 19:45:12 -
> @@ -2,7 +2,8 @@ BROKEN-hppa = ICE on dgn-shoals.cc:638
>
> COMMENT =dungeon crawl stone soup
>
> -VERSION =0.30.1
> +VERSION =0.31.0
> +TAGNAME =The Alchemy of Forms
>
> DISTNAME=stone_soup-${VERSION}-nodeps
> PKGNAME= stone-soup-${VERSION}
> @@ -18,8 +19,7 @@ PERMIT_PACKAGE= Yes
>
> WANTLIB += ${COMPILER_LIBCXX} ${MODLUA_WANTLIB} c m sqlite3
>
> -SITES = https://crawl.develz.org/release/${VERSION:R}/ \
> - https://github.com/crawl/crawl/releases/download/${VERSION}/
> +SITES =
> https://github.com/crawl/crawl/releases/download/${VERSION}/
> EXTRACT_SUFX=.tar.xz
>
> COMPILER = base-clang ports-gcc
> @@ -41,13 +41,15 @@ MAKE_FLAGS = CC="${CC}" GCC="${GCC}" GX
> INSTALL_UGRP=root:wheel \
> prefix=${PREFIX} \
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/03/04 20:10:19 Modified files: games/stone-soup: Makefile distinfo games/stone-soup/patches: patch-source_Makefile games/stone-soup/pkg: PFRAG.no-no_x11 PLIST Removed files: games/stone-soup/patches: patch-source_xdg-data_org_develz_Crawl_tiles_desktop Log message: update to stone-soup 0.31.0, from maintainer Stefan Moran - thanks!
Re: [update] games/stone-soup to 0.31.0
Two issues mentioned inline.
On Sat, Mar 02, 2024 at 05:43:38PM -0500, Stefan Moran wrote:
> Update games/stone-soup from 0.30.1 to 0.31.0 "The Alchemy of Forms". I
> tried to simplify the Makefile patch a bit, and also installed the
> included .desktop file, which was not being installed for some reason.
>
> OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/stone-soup/Makefile,v
> retrieving revision 1.47
> diff -u -p -r1.47 Makefile
> --- Makefile 12 Nov 2023 14:03:31 - 1.47
> +++ Makefile 2 Mar 2024 22:30:23 -
> @@ -2,7 +2,8 @@ BROKEN-hppa = ICE on dgn-shoals.cc:638
>
> COMMENT =dungeon crawl stone soup
>
> -VERSION =0.30.1
> +VERSION =0.31.0
> +TAGNAME =The Alchemy of Forms
>
> DISTNAME=stone_soup-${VERSION}-nodeps
> PKGNAME= stone-soup-${VERSION}
> @@ -18,6 +19,7 @@ PERMIT_PACKAGE= Yes
>
> WANTLIB += ${COMPILER_LIBCXX} ${MODLUA_WANTLIB} c m sqlite3
>
> +# Failover to github, devs are on and off about providing source on
> develz.org.
> SITES = https://crawl.develz.org/release/${VERSION:R}/ \
> https://github.com/crawl/crawl/releases/download/${VERSION}/
The DISTNAME would be different at crawl.develz.org, meaning it can't
download anything from there. I don't know if we have a mechnism for
multiple SITES with different distfiles, but cleanest solution I see is
using just github distfiles for now.
> EXTRACT_SUFX=.tar.xz
> @@ -41,13 +43,15 @@ MAKE_FLAGS = CC="${CC}" GCC="${GCC}" GX
> INSTALL_UGRP=root:wheel \
> prefix=${PREFIX} \
> SAVEDIR="~/.crawl" \
> - NO_YACC=1 V=1
> + NO_YACC=1 V=1 \
> + SRC_VERSION=${VERSION} RECENT_TAG="${TAGNAME}"
>
> USE_GMAKE = Yes
> CONFIGURE_STYLE = none
>
> MODPY_RUN_DEPENDS = No
> -MODPY_ADJ_FILES = util/species-gen.py
> +MODPY_ADJ_FILES =util/species-gen.py \
> + util/tag-35-upgrade.py
>
> FLAVORS =no_x11
> FLAVOR ?=
> @@ -62,7 +66,7 @@ CXXFLAGS += -DUSE_TILE
>
> MAKE_FLAGS +=TILES=y \
> LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib \
> - -lSDL2 -lSDL2_image -lpng -pthread"
> + -lSDL2 -lSDL2_image -lpng -pthread"
> WANTLIB += GL GLU SDL2 SDL2_image freetype png pthread z
> RUN_DEPENDS =devel/desktop-file-utils
> LIB_DEPENDS += devel/sdl2 \
> @@ -85,12 +89,11 @@ post-install:
> ${INSTALL_MAN} ${WRKDIST}/docs/crawl.6 ${PREFIX}/man/man6/crawl-ss.6
> .if ! ${FLAVOR:Mno_x11}
> ${INSTALL_DATA_DIR} ${PREFIX}/share/pixmaps ${PREFIX}/share/applications
> + ${INSTALL_DATA} ${FILESDIR}/stone-soup.desktop \
> + ${PREFIX}/share/applications
> ${INSTALL_DATA} \
> ${PREFIX}/share/crawl/dat/tiles/stone_soup_icon-32x32.png \
> ${PREFIX}/share/pixmaps/stone-soup.png
> - ${INSTALL_DATA} \
> - ${WRKDIST}/source/xdg-data/org.develz.Crawl_tiles.desktop \
> - ${PREFIX}/share/applications
> .endif
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/stone-soup/distinfo,v
> retrieving revision 1.9
> diff -u -p -r1.9 distinfo
> --- distinfo 12 Nov 2023 14:03:31 - 1.9
> +++ distinfo 2 Mar 2024 22:30:23 -
> @@ -1,2 +1,2 @@
> -SHA256 (stone_soup-0.30.1-nodeps.tar.xz) =
> kG03bvgAH7+fegUkUDD2T5MAxs44VdL43IHNjUjvCkY=
> -SIZE (stone_soup-0.30.1-nodeps.tar.xz) = 18901720
> +SHA256 (stone_soup-0.31.0-nodeps.tar.xz) =
> FPIEAmlYt6U8CJizwsxp33Qx+qtbrDG3xVfOSSEJvgs=
> +SIZE (stone_soup-0.31.0-nodeps.tar.xz) = 19577424
> Index: patches/patch-source_Makefile
> ===
> RCS file: /cvs/ports/games/stone-soup/patches/patch-source_Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 patch-source_Makefile
> --- patches/patch-source_Makefile 12 Nov 2023 14:03:31 - 1.9
> +++ patches/patch-source_Makefile 2 Mar 2024 22:30:23 -
> @@ -1,29 +1,7 @@
> Index: source/Makefile
> --- source/Makefile.orig
> +++ source/Makefile
> -@@ -262,9 +262,6 @@ ifdef msys
> - BUILD_LIBPNG = YesPlease
> - COPY_FONTS = yes
> - endif
> --ifeq ($(shell gcc -v -static -static-libstdc++ 2>&1 | grep
> 'unrecognized option'),)
> --EXTRA_LIBS += -static -static-libgcc -static-libstdc++
> --endif
> - endif
> - ifeq ($(uname_S),Darwin)
> - ifdef MAC_TARGET
> -@@ -374,11 +371,8 @@ endif
> - #
> - ifndef NO_APPLE_PLATFORM
> - ifeq ($(uname_S),Darwin)
> --ifneq ($(shell gcc -v 2>&1 | grep Apple),)
> --APPLE_PLATFORM = YesPlease
> - endif
> - endif
> --endif
> -
> -
> - ifdef WIN32
> -@@ -509,15 +503,7 @@ ifneq ($(GCC_VER),)
> +@@ -509,15 +509,7 @@ ifneq ($(GCC_VER),)
> GCC_VER_SUFFIX:=-$(GCC_VER)
> endif
>
> @@ -39,7 +17,7 @@ Index: source/Makefile
>
> ifneq
Re: New: KeeperRL - evil wizard simulator/dungeon colony builder game
On Sat, Mar 02, 2024 at 10:58:12AM +0100, Solène Rapenne wrote: > Le vendredi 01 mars 2024 à 22:12 -0500, Thomas Frohwein a écrit : > > Hi, > > > > Please find attached the port of KeeperRL, an open source game in the > > spirit of Dungeon Keeper or Overlord. This means that this game is > > about reversing the role of tropy RPG heroes and villains, and tasking > > the player with building a dungeon, raiding nearby villages, > > collecting resources, building traps for heroes that try to attack the > > dungeon, etc. This has been in development for many years and now has > > seen the 1.0 release. > > > > The port is built with C++, using the usual suspects of openal and > > sdl2 libraries. It comes with free (and primitive) assets that can be > > used, though the better supported way is to run the commercially > > available game which includes music, sound effects, nicer graphics, and > > a tutorial. The website links to all places where those can be obtained > > [1], including itch.io, GOG.com. > > > > I've launched both versions and played through the tutorial with the > > commercial version. The README explains how to launch each one. A few > > more technical notes about the port: > > > > - It currently builds with Steam features that link to the goldberg > > emulator library. There is a flag to skip Steam integration > > (NO_STEAMWORKS), but that currently runs into build problems with > > missing Steam-related symbols. Hopefully with future updates, the > > Steam/goldberg dependency can be dropped. > > - While the 1.0 release has been announced officially and the engine > > itself advertises version 1.0, there is no 1.0 GitHub release or tag. > > > > ok for import? > > > > [1] https://keeperrl.com/ > > sounds cool! > > can you play the free ascii version with this port? you said it comes > with free assets, while on the official website there is either the paid > or free ascii version, does this mean open source users have an > advantage here? :-) The free ascii version is included in /usr/local/share/keeperrl/. The README describes how to run the free or the commercial version. It seems to me the entry barrier is lower with the commercial version as it comes with a tutorial.
New: KeeperRL - evil wizard simulator/dungeon colony builder game
Hi, Please find attached the port of KeeperRL, an open source game in the spirit of Dungeon Keeper or Overlord. This means that this game is about reversing the role of tropy RPG heroes and villains, and tasking the player with building a dungeon, raiding nearby villages, collecting resources, building traps for heroes that try to attack the dungeon, etc. This has been in development for many years and now has seen the 1.0 release. The port is built with C++, using the usual suspects of openal and sdl2 libraries. It comes with free (and primitive) assets that can be used, though the better supported way is to run the commercially available game which includes music, sound effects, nicer graphics, and a tutorial. The website links to all places where those can be obtained [1], including itch.io, GOG.com. I've launched both versions and played through the tutorial with the commercial version. The README explains how to launch each one. A few more technical notes about the port: - It currently builds with Steam features that link to the goldberg emulator library. There is a flag to skip Steam integration (NO_STEAMWORKS), but that currently runs into build problems with missing Steam-related symbols. Hopefully with future updates, the Steam/goldberg dependency can be dropped. - While the 1.0 release has been announced officially and the engine itself advertises version 1.0, there is no 1.0 GitHub release or tag. ok for import? [1] https://keeperrl.com/ keeperrl-1.0.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/03/01 11:49:50 Modified files: games/godot4 : Makefile Log message: Some cleanup in godot4 - remove the LINKFLAGS line as it isn't doing anything (last update revealed that). This should help avert porters trying to tweak it to no effect. To change linker flags, it seems at this point that detect.py needs to be patched... While here remove WRKDIST line as this is no longer needed with the recent DIST_TUPLE-related commit. This is ok op@ (maintainer)
Re: update games/wrath to 1.0
On Fri, Mar 01, 2024 at 12:14:34PM +0100, Solène Rapenne wrote: > On 28/02/2024 14:48, Solène Rapenne wrote: > > On 28/02/2024 12:11, Jonathan Gray wrote: > > > Wrath left early access and the old repo was removed. > > > Build tested only. > > > > > > > game runs, but crash at the end of the tutorial when loading next area > > "Mourningvale", i was able to repeat the issue twice, I didn't try > > another time. (fortunately the game makes a save ~30s before the loading > > area if someone wants to debug) > > > > Memory pool 0x591a2a38b60 has sprung a leak totalling 44905033 bytes > > (42.825MB)! Listing contents... > > 44905033 bytes allocated at ../../../fs.c:3194 > > Quake Error: Mem_Alloc: out of memory (alloc at > > ../../../model_shared.c:1046) > > Client "player" dropped > > pthread_mutex_destroy on mutex with waiters! > > > > problem solved by increasing ulimit -d value > > ok solene@ > Runs fine here, I played through the tutorial and got to Mourningvale without hitting the out of memory error (my ulimit -d is bumped from the default). This is ok thfr@, too.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/03/01 09:49:04 Modified files: emulators/flycast: Makefile Log message: disable vulkan backend to restore build after vulkan updates, ok namn@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/29 21:47:01 Modified files: games/godot4 : Makefile Log message: missed to remove BROKEN marker when fixing glslang, but this is ready to build again
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2024/02/29 14:20:51
Modified files:
infrastructure/mk: bsd.port.mk dist-tuple.port.mk
Log message:
Enable automatic setting of WRKDIST if DIST_TUPLE is used. After the
previous attempt last fall led to breakage, this is now fixed and has
survived a bulk kindly tested by tb@. It is based on how GitHub
packages its tarballs. If needed, heuristics for other sources like
gitlab, srht can be added later through the same mechanism.
This makes lines in DIST_TUPLE (github) ports like the following
superfluous:
WRKDIST = ${WRKDIR}/project-${COMMIT_HASH}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/29 05:59:20 Modified files: games/godot4 : Makefile distinfo games/godot4/patches: patch-SConstruct patch-drivers_unix_os_unix_cpp patch-methods_py patch-misc_dist_linux_godot_6 patch-platform_linuxbsd_detect_py patch-platform_linuxbsd_os_linuxbsd_cpp patch-platform_linuxbsd_x11_display_server_x11_cpp patch-thirdparty_openxr_src_common_platform_utils_hpp Added files: games/godot4/patches: patch-drivers_unix_file_access_unix_cpp patch-modules_glslang_register_types_cpp Removed files: games/godot4/patches: patch-platform_linuxbsd_tts_linux_cpp patch-platform_linuxbsd_tts_linux_h patch-thirdparty_oidn_mkl-dnn_src_cpu_jit_utils_jitprofiling_jitprofiling_c patch-thirdparty_oidn_mkl-dnn_src_cpu_simple_reorder_hpp Log message: update Godot4 to most recent commit, including unbreaking of build after the vulkan updates. This is now internal version 4.3.dev. Note the release notes for 4.2 (was skipped in ports) which mention some breaking changes and ways to migrate: https://godotengine.org/article/godot-4-2-arrives-in-style/ Discussed with, tested by, and ok op@ (maintainer)
flycast: disable vulkan for now to restore build
flycast build broke with vulkan updates. I suggest we disable vulkan
for now until we can give this a closer look or find an update that
fixes this...
ok?
Index: Makefile
===
RCS file: /cvs/ports/emulators/flycast/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile8 Feb 2024 00:57:55 - 1.6
+++ Makefile28 Feb 2024 03:41:47 -
@@ -8,7 +8,7 @@ COMMENT = emulator for Sega Dreamcast an
V =2.1pl20230303
DISTNAME = flycast-${V}
COMMIT = 27b6bafd0f003c8f8bcd1fb3bfd48a3523b298f5
-REVISION = 2
+REVISION = 3
CATEGORIES = emulators games
@@ -25,8 +25,8 @@ MAINTAINER = Nam Nguyen https://messagemode2.com/source/
@@ -53,12 +53,11 @@ LIB_DEPENDS = archivers/libzip \
audio/pulseaudio \
devel/sdl2 \
emulators/libchdr \
- graphics/glslang \
- graphics/vulkan-loader \
net/curl \
net/miniupnp/miniupnpc \
sysutils/xxhash
+CONFIGURE_ARGS += -DUSE_VULKAN=OFF
do-gen:
${SUBST_CMD} ${WRKSRC}/CMakeLists.txt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/28 20:07:21 Modified files: emulators/snes9x: Makefile emulators/snes9x/patches: patch-gtk_CMakeLists_txt Log message: glslang 14 doesn't need linking libHLSL anymore, nor does it provide it. Therefore remove HLSL from the build which fixes this fallout from glslang 14 update
Re: New: Recoil - 3D engine for Real-Time Strategy games
*ping* I'm still interested in getting this in. Upstream has merged the first set of OpenBSD-specific patches, so this has a decent outlook to be a longer-lived engine port. On Sun, Feb 18, 2024 at 10:37:54AM -0500, Thomas Frohwein wrote: > *ping* > > Attached new tarball with a few changes: > > - update to latest BAR release engine 2314-g9e0bf7d > - disable unmaintained manpages (PR #1291) > - with help from bentley@, remove some unneeded and use >instead of > - fix thinko with xdgConfHome > - limit executable detection to /usr/local/bin/ path to avoid TOCTOU > with prior approach that used access(2) > > ok? > > On Sun, Feb 11, 2024 at 07:04:24PM -0500, Thomas Frohwein wrote: > > Hi, > > > > Please find attached the port of Recoil, the successor of the Spring > > engine. It goes back in lineage to Total Annihilation from the 1990's > > and allows for visually stunning, large-scale RTS battles. > > > > From DESCR: > > > > Recoil is a battle tested open-source RTS engine, successor of Spring. It is > > designed, in its basis, to be able to run the content of the game Total > > Annihilation and deliver a similar, but improved, gaming experience. Games > > can > > be intense and very large scaled, with fight of, literally, hundreds of > > units > > and the mods allow very wide arrays of different strategies and tactics. > > Some > > of the games powered by Recoil: Beyond All Reason, ZeroK, TA Prime and Metal > > Factions. > > > > The README has details on how to install maps and the game-specific > > engines, as well as a lobby application. Not all parts of the Beyond > > ALl Reason experiences can be run (yet?), as their launcher that > > integrates with the lobby and engine is an Electron app, sadly. > > > > A few notes on the port: > > > > - The games that I tested (Zero-K and Beyond All Reason) require a > > data size of at least 4-6G. > > > > - Online multiplayer is untested, but if someone wants to try it out > > please message me. > > > > - Versioning is currently 0.major.minor.etc... as upstream told me of > > their intention to switch to year-month versioning similar to what > > Mesa does. This way, that change wouldn't require EPOCH. > > > > - I'm hoping to keep the port mostly in sync with the versions used by > > Beyond All Reason, as those are getting significant use and attention. > > > > - A few OpenBSD-specific codepaths had to be implemented in patches/, > > for example: getting data dir locations without wordexp, using > > argv[0] for the executable location, enumeration of CPU cores (this > > isn't accounting for SMT at this point), futex(2) instead of syscall > > (SYS_futex...), some pthread non-portable API. > > > > - The bundled Lua 5.1 is too customized and integrated to easily remove > > it in favor of the lua lib from the port. > > > > - Alignment aware memory pools patches from the GH PR have fixed a > > couple of gnarly crashes. > > > > - As far as I know we don't have libunwind available in a way that > > could be used by this port, so those parts of integrated backtraces/ > > crash handling are stubbed. > > > > Make sure to look at the README for using pr-downloader to get maps and > > engines in order to test. > > > > ok? > > recoil-rts-rev0.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/25 15:42:10 Modified files: games/luasteam : Makefile Log message: luasteam depends on luajit, therefore needing USE_NOBTCFI=Yes at this point, raised by sthen@
Re: sdl2-mixer, explicitely disable wavepack and xmp
On Sun, Feb 25, 2024 at 01:17:44PM +0100, Antoine Jacoutot wrote: > Hi. > > This diff to prevent libxmp and libwavepack from being picked up. > Or we do the opposite and add support, I have no opinion. Thanks for spotting this. These are new dlopen(3)'d dependencies via SDL_LoadObject. I prefer that we keep them enabled and add the dependencies properly, as sdl2 stuff is used in so many contexts. I committed the pertinent revision that adds the dependencies. > > Index: Makefile > === > RCS file: /cvs/ports/devel/sdl2-mixer/Makefile,v > retrieving revision 1.17 > diff -u -p -r1.17 Makefile > --- Makefile 23 Feb 2024 20:35:32 - 1.17 > +++ Makefile 25 Feb 2024 12:17:30 - > @@ -24,6 +24,8 @@ LIB_DEPENDS = audio/opusfile \ > > CONFIGURE_STYLE =gnu > CONFIGURE_ARGS +=--disable-music-midi-fluidsynth \ > + --disable-music-wavpack \ > + --disable-music-mod-xmp \ > --disable-music-mod-modplug-shared \ > --disable-music-opus-shared > > > -- > Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/25 06:47:52 Modified files: devel/sdl2-mixer: Makefile Log message: I missed new dlopen(3) library dependencies on wavpack and libxmp. Add those. Found by aja@ - thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 19:57:01 Modified files: lang/hashlink : Makefile Log message: Fix build by adding WRKDIST not set automatically by DIST_TUPLE at this point. Spotted by tb@ in bulk build. Not bumping REVISION because the updated package couldn't be built.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 19:43:36 Modified files: graphics/glslang: Makefile distinfo graphics/glslang/patches: patch-StandAlone_CMakeLists_txt graphics/glslang/pkg: PLIST graphics/spirv-headers: Makefile distinfo graphics/spirv-tools: Makefile distinfo graphics/vulkan-headers: Makefile distinfo graphics/vulkan-headers/patches: patch-registry_apiconventions_py patch-registry_cgenerator_py patch-registry_generator_py patch-registry_reg_py patch-registry_spec_tools_conventions_py patch-registry_vkconventions_py graphics/vulkan-headers/pkg: PLIST graphics/vulkan-loader: Makefile distinfo graphics/vulkan-loader/pkg: PLIST graphics/vulkan-tools: Makefile distinfo graphics/vulkan-validation-layers: Makefile distinfo Removed files: graphics/vulkan-headers/patches: patch-registry_genvk_py graphics/vulkan-validation-layers/patches: patch-layers_vulkan_generated_vk_extension_helper_h Log message: update vulkan ports to latest SDK release 1.3.275.0 testing and ok op@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 19:33:38 Modified files: graphics : Makefile Log message: +vulkan-utility-libraries
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 19:32:52 Log message: Import vulkan-utility-libraries, as part of the update to vulkan sdk 1.3.275.0. Testing and ok op@ - thanks! DESCR: Utilities to facilitate official source deliverables that can be reliably used by developers. Status: Vendor Tag: thfr Release Tags: thfr_20240224 N ports/graphics/vulkan-utility-libraries/Makefile N ports/graphics/vulkan-utility-libraries/distinfo N ports/graphics/vulkan-utility-libraries/pkg/DESCR N ports/graphics/vulkan-utility-libraries/pkg/PLIST No conflicts created by this import
Re: gen-dist-tuple - script to generate submodule information for DIST_TUPLE from github
On Sat, Feb 24, 2024 at 07:12:56PM +0100, Omar Polo wrote: > Thomas Frohwein wrote: > > *ping* > > > > This can save enough work with ports that have multiple submodules that > > I think it might help porters' work. Of course this can be obtained > > from the GitHub source, too, but having it in the ports tree would help > > visibility and accountability, especially to decrease the barrier for > > working with complex ports. Re-attaching for convenience. > > I've quickly tested it and it seems to work as advertised. In my > experience there are not that many ports needing to use submodules (or > maybe i was just lucky ;-) but nevertheless it's nice to have something > in the port infrastructure to automatize that bit. Seems also quite > simple too, which is promising. > > With a few more lines of code to grok the .gitmodules ini file, we could > also be able to avoid using the github api, which would make make even > easier to extend it for other forges. >From my experience with this, .gitmodules doesn't contain all the information to identify the submodule target. But this is definitely intended to be extendable to other forges, see the possible branching options with VALID_TEMPLATES. > I don't have lots of experience with perl but it reads fine to me. Oh, > Readonly.pm is not in base though :P Thanks for catching that. That's an easy fix and I'm attaching the updated script. (version controlled at: https://github.com/rfht/gen-dist-tuple) > So, fwiw I'd welcome something like this in the port infrastructure. > > crazy idea: what about hooking something like this into portgen and then > allow to do `portgen github johnfactotum/foliate'? :-) I don't have much experience with portgen, but DIST_TUPLE really only gets you the dist files and is language agnostic. It would seem to me that a lot more is needed to generate a port draft. gen-dist-tuple.pl Description: Perl program
update of vulkan ports to SDK 1.3.275.0 (and glslang to 14)
ities and Tools
-V =1.3.261.1
+V =1.3.275.0
PKGNAME = vulkan-tools-${V}
-GH_TAGNAME = sdk-${V}
+GH_TAGNAME = vulkan-sdk-${V}
GH_ACCOUNT = KhronosGroup
GH_PROJECT = Vulkan-Tools
@@ -14,6 +14,7 @@ MAINTAINER = Thomas Frohwein glslang until this port can cope with glslang-12.3.1+
-pre-configure:
- find ${WRKSRC} -type f -exec sed -i 's,glslangValidator,glslang,g' {} \;
.include
Index: vulkan-tools/distinfo
===
RCS file: /cvs/ports/graphics/vulkan-tools/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- vulkan-tools/distinfo 5 Sep 2023 19:07:50 - 1.12
+++ vulkan-tools/distinfo 24 Feb 2024 19:58:33 -
@@ -1,2 +1,2 @@
-SHA256 (Vulkan-Tools-sdk-1.3.261.1.tar.gz) =
B1Q9dhta5T44D996P0K9cG8s8a0EoxA4H884b++4FMY=
-SIZE (Vulkan-Tools-sdk-1.3.261.1.tar.gz) = 801322
+SHA256 (Vulkan-Tools-vulkan-sdk-1.3.275.0.tar.gz) =
och2psKILjZRQZQmQaOOCnv6ZoSn3O27AGaiDAZiW9A=
+SIZE (Vulkan-Tools-vulkan-sdk-1.3.275.0.tar.gz) = 755289
Index: vulkan-validation-layers/Makefile
===
RCS file: /cvs/ports/graphics/vulkan-validation-layers/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- vulkan-validation-layers/Makefile 5 Sep 2023 19:07:50 - 1.20
+++ vulkan-validation-layers/Makefile 24 Feb 2024 19:58:33 -
@@ -1,8 +1,8 @@
COMMENT = Vulkan Validation Layers
-V =1.3.261.1
+V =1.3.275.0
PKGNAME = vulkan-validation-layers-${V}
-GH_TAGNAME = sdk-${V}
+GH_TAGNAME = vulkan-sdk-${V}
GH_ACCOUNT = KhronosGroup
GH_PROJECT = Vulkan-ValidationLayers
@@ -23,14 +23,16 @@ MODULES = devel/cmake \
lang/python
MODPY_RUNDEP = No
-BUILD_DEPENDS =devel/robin-hood-hashing \
+BUILD_DEPENDS =graphics/spirv-headers \
+ graphics/spirv-tools \
graphics/vulkan-headers \
- graphics/spirv-headers \
- graphics/spirv-tools
+ graphics/vulkan-utility-libraries
-CONFIGURE_ARGS += -DBUILD_WSI_WAYLAND_SUPPORT=False \
+# needs robin_hood cmake package to build with robing hood hashing
+CONFIGURE_ARGS += -DBUILD_WERROR=False \
+ -DBUILD_WSI_WAYLAND_SUPPORT=False \
-DSPIRV_HEADERS_INSTALL_DIR=${LOCALBASE}/include/spirv \
- -DBUILD_WERROR=False
+ -DUSE_ROBIN_HOOD_HASHING=False
# Tests only build if Google Test framework is in directory external/
NO_TEST = Yes
Index: vulkan-validation-layers/distinfo
===
RCS file: /cvs/ports/graphics/vulkan-validation-layers/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- vulkan-validation-layers/distinfo 5 Sep 2023 19:07:50 - 1.12
+++ vulkan-validation-layers/distinfo 24 Feb 2024 19:58:33 -
@@ -1,2 +1,2 @@
-SHA256 (Vulkan-ValidationLayers-sdk-1.3.261.1.tar.gz) =
E3LVIvKXuz+zhoArGqS3+IWp4elppqPG6bKdOBNX8h0=
-SIZE (Vulkan-ValidationLayers-sdk-1.3.261.1.tar.gz) = 5005018
+SHA256 (Vulkan-ValidationLayers-vulkan-sdk-1.3.275.0.tar.gz) =
rP2EA5EJIgEpYksOy2mYC7w6hYl4xitVbb4W79DyZ1U=
+SIZE (Vulkan-ValidationLayers-vulkan-sdk-1.3.275.0.tar.gz) = 5280585
Index:
vulkan-validation-layers/patches/patch-layers_vulkan_generated_vk_extension_helper_h
===
RCS file:
vulkan-validation-layers/patches/patch-layers_vulkan_generated_vk_extension_helper_h
diff -N
vulkan-validation-layers/patches/patch-layers_vulkan_generated_vk_extension_helper_h
---
vulkan-validation-layers/patches/patch-layers_vulkan_generated_vk_extension_helper_h
5 Sep 2023 19:07:50 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,18 +0,0 @@
-avoid collision with major/minor in types.h
-
-Index: layers/vulkan/generated/vk_extension_helper.h
layers/vulkan/generated/vk_extension_helper.h.orig
-+++ layers/vulkan/generated/vk_extension_helper.h
-@@ -74,6 +74,12 @@ Times to NOT use it
-
- #define VVL_UNRECOGNIZED_API_VERSION 0x
-
-+#ifdef __OpenBSD__
-+// collision with types.h
-+#undef major
-+#undef minor
-+#endif
-+
- class APIVersion {
- public:
- APIVersion() : api_version_(VVL_UNRECOGNIZED_API_VERSION) {}
New: vulkan-utility-libraries - new dependency for vulkan-validation-layers
Hi, This is a new dependency needed to provide vulkan-validation-layers with the Vulkan::LayerSettings library that is needed to update it to the most recent SDK 1.3.275.0. I don't have much to say about this, as the LayerSettings seems to be the only thing that we will rely on in the near term. ok to import? vulkan-utility-libraries.tgz Description: application/tar-gz
Re: gen-dist-tuple - script to generate submodule information for DIST_TUPLE from github
*ping*
This can save enough work with ports that have multiple submodules that
I think it might help porters' work. Of course this can be obtained
from the GitHub source, too, but having it in the ports tree would help
visibility and accountability, especially to decrease the barrier for
working with complex ports. Re-attaching for convenience.
On Thu, Feb 15, 2024 at 02:54:28PM -0500, Thomas Frohwein wrote:
> Hi,
>
> In an attempt to make working with git submodules easier, I would like
> to offer this perl script. It is limited to just github for now. It can
> work with any github repos that have submodules listed in their
> .gitmodules file (not visible in github web interface).
>
> Here are 2 examples:
>
> $ gen-dist-tuple.pl github johnfactotum foliate 3.1.0 <
> DIST_TUPLE += github johnfactotum foliate 3.1.0 .
> DIST_TUPLE += github johnfactotum foliate-js
> 35f749dd7cf8a2e9ee6d34b06d83c92ccd999ba9 src/
> foliate-js
>
> $ gen-dist-tuple.pl github beyond-all-reason spring \
> da52e1c8dccbd33fea11f7bc49429a188751c8d4
> DIST_TUPLE += github beyond-all-reason spring
> da52e1c8dccbd33fea11f7bc49429a188751c8d4 .
> DIST_TUPLE += github spring Python b69a4ea06bb780d68b5934d5d6ce1b93a684514b
> AI/Interfaces/Python
> DIST_TUPLE += github spring pyunitsync
> 8dfe0bcb867150c4d83e6f691e44dc7a55fda21c tools/unitsync/python
> DIST_TUPLE += github beyond-all-reason pr-downloader
> bdac30330eccb5ec73da299922491f3f4ee8debe tools/pr-downloader
> DIST_TUPLE += github spring SpringMapConvNG
> 0ddd86eaa8871dc0833c69f931f55cd856c5009d tools/mapcompile
> DIST_TUPLE += github rlcevg CircuitAI
> 0561a37458f3eb45157c9709febbfe5843e6570e AI/Skirmish/BARb
> DIST_TUPLE += github rlcevg CircuitAI
> afeae5bf1f607744aa984a8ef2094d560d95b564 AI/Skirmish/CircuitAI
> DIST_TUPLE += github wolfpld tracy 5a1f5371b792c12aea324213e1dc738b2923ae21
> rts/lib/tracy
> DIST_TUPLE += github gflags gflags f8a0efe03aa69b3336d8e228b37d4ccb17324b88
> rts/lib/gflags
> DIST_TUPLE += github skypjack entt e4ccb878f47245a319704912435d3c89f34ad6be
> rts/lib/entt
> DIST_TUPLE += github USCiLab cereal d1fcec807b372f04e4c1041b3058e11c12853e6e
> rts/lib/cereal
>
> MODGO's modgo-gen-modules-helper seems to be a comparable script for a
> that ecosystem (I don't have experience or deeper knowledge of the go
> module), and devel/cargo's modcargo-gen-crates target achieves
> something similar.
>
> The repo is at: https://github.com/rfht/gen-dist-tuple
>
> If this seems useful enough to possible integrate in
> ${PORTSDIR}/infrastructure/bin, let me know.
>
> Comments and feedback welcome!
gen-dist-tuple.pl
Description: Perl program
Re: CVS: cvs.openbsd.org: ports
On Sat, Feb 24, 2024 at 07:48:00AM -0700, Thomas Frohwein wrote: > CVSROOT: /cvs > Module name: ports > Changes by: t...@cvs.openbsd.org2024/02/24 07:48:00 > > Log message: > import graphics/volk, a dynamic loader for the vulkan library and now a > dependency for vulkan-tools. ok op@ Was also built and tested by Jose Maldonado - thanks! > DESCR: > volk is a meta-loader for Vulkan. It allows you to dynamically load > entrypoints > required to use Vulkan without linking to vulkan-1.dll or statically > linking > Vulkan loader. Additionally, volk simplifies the use of Vulkan extensions > by > automatically loading all associated entrypoints. Finally, volk enables > loading > Vulkan entrypoints directly from the driver which can increase > performance by > skipping loader dispatch overhead. > > Status: > > Vendor Tag: thfr > Release Tags: thfr_20240224 > > N ports/graphics/volk/Makefile > N ports/graphics/volk/distinfo > N ports/graphics/volk/patches/patch-CMakeLists_txt > N ports/graphics/volk/pkg/DESCR > N ports/graphics/volk/pkg/PLIST > > No conflicts created by this import >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 10:34:36 Modified files: devel/sdl2 : Makefile Added files: devel/sdl2/patches: patch-src_joystick_SDL_gamecontrollerdb_h Log message: Add PS4 controller mapping for GUID 0300d0424c05cc090001 that makes the touchpad button usable. There are more unaccounted PS4 controller GUIDs, will need to ultimately defer to upstream for keeping the SDL_gamecontrollerdb.h update. In the meantime, this helps stsp@ use chiaki better...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 07:49:22 Modified files: graphics : Makefile Log message: +volk
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/02/24 07:48:00 Log message: import graphics/volk, a dynamic loader for the vulkan library and now a dependency for vulkan-tools. ok op@ DESCR: volk is a meta-loader for Vulkan. It allows you to dynamically load entrypoints required to use Vulkan without linking to vulkan-1.dll or statically linking Vulkan loader. Additionally, volk simplifies the use of Vulkan extensions by automatically loading all associated entrypoints. Finally, volk enables loading Vulkan entrypoints directly from the driver which can increase performance by skipping loader dispatch overhead. Status: Vendor Tag: thfr Release Tags: thfr_20240224 N ports/graphics/volk/Makefile N ports/graphics/volk/distinfo N ports/graphics/volk/patches/patch-CMakeLists_txt N ports/graphics/volk/pkg/DESCR N ports/graphics/volk/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2024/02/24 07:20:49
Modified files:
devel/sdl2 : Makefile
devel/sdl2/patches: patch-src_joystick_bsd_SDL_bsdjoystick_c
Log message:
fix Hat/Dpad detection where HUG_HAT_SWITCH is used for it. Problem
found by stsp@, ok stsp@
There are 2 different ways that HID devices communicate gamepad D-pads.
The traditional way with HUG_HAT_SWITCH is less common, so the issue
remained undetected as many current gamepads use
HUG_DPAD_{UP,DOWN,LEFT,RIGHT} instead. The result was a bug where the
HUG_HAT_SWITCH values were later overridden by zeroes from
(non-existent) HUG_DPAD_*
