Re: UPDATE: aom 3.8.1
Stuart Henderson writes: > On 2024/03/03 16:26, Peter Hessler wrote: >> --- aom_configure: Detected CPU: arm64 >> -- The ASM compiler identification is unknown >> -- Found assembler: as >> CMake Error at build/cmake/aom_configure.cmake:212 (enable_language): >> The CMAKE_ASM_COMPILER: >> >> as >> >> is not a full path and was not found in the PATH. [...] > It could possibly depend on devel/gas (there is a newer version in > devel/binutils, but other ports are depending on devel/gas and the two > conflict, so better take the one which is already used) .. Another option is to remove unused dependency from the source e.g., https://github.com/freebsd/freebsd-ports/blob/main/multimedia/aom/files/patch-build_cmake_aom__configure.cmake
Re: UPDATE: aom 3.8.1
Brad Smith writes: > GH_ACCOUNT= jbeich > GH_PROJECT= aom > -GH_TAGNAME= v3.6.1 > +GH_TAGNAME= v3.8.1 If you don't use snapshots or RCs better migrate off my GitHub mirror. According to Repology the download link would be https://storage.googleapis.com/aom-releases/libaom-3.8.1.tar.gz
Re: [NEW] alsa-lib-1.2.11
SASANO Takayoshi writes: > And, alsa-lib/alsa-utils(aplay)/alsa-plugin(Pulse) combination is working > on OpenBSD-7.4/amd64. Did you also test without pulseaudio e.g., via sndio plugin? https://github.com/Duncaen/alsa-sndio https://repology.org/project/alsa-sndio/versions
Re: graphics/libavif hidden dep?
Antoine Jacoutot writes:
> -- Checking for module 'libyuv'
> --
> -- Could NOT find libyuv (missing: LIBYUV_LIBRARY LIBYUV_LIBRARIES
> LIBYUV_INCLUDE_DIR) (found version "")
> -- libavif: libyuv not found; libyuv-based fast paths disabled.
> -- Checking for module 'libsharpyuv'
> -- Found libsharpyuv, version 1.3.0
> -- Found libsharpyuv: /usr/local/lib/libsharpyuv.so.0.0 (found version
> "1.3.0")
> -- libavif: libsharpyuv found; sharp rgb to yuv conversion enabled.
[...]
> FAILED: tests/are_images_equal
> : && /exopi-obj/pobj/libavif-0.11.1/bin/c++ -O2 -pipe -DNDEBUG
> tests/CMakeFiles/aviftest_helpers.dir/gtest/aviftest_helpers.cc.o
> tests/CMakeFiles/are_images_equal.dir/gtest/are_images_equal.cc.o -o
> tests/are_images_equal -Wl,-z,origin,-
> rpath,/exopi-obj/pobj/libavif-0.11.1/build-amd64:/usr/local/lib
> libavif_apps.a libavif.so.6.0 -lm -pthread
> /usr/local/lib/libsharpyuv.so.0.0 /usr/local/lib/libpng.so.18.0
> /usr/lib/libz.so.7.0 /usr/local/lib/libjpeg.so.70.1 -Wl,-r
> path-link,/usr/X11R6/lib:/usr/local/lib && :
> c++: error: no such file or directory: '/usr/local/lib/libsharpyuv.so.0.0'
> ninja: build stopped: subcommand failed.
I don't use OpenBSD but the following may help:
diff --git a/graphics/libavif/Makefile b/graphics/libavif/Makefile
index b35d21698bd..34e579501ba 100644
--- a/graphics/libavif/Makefile
+++ b/graphics/libavif/Makefile
@@ -31,8 +31,8 @@ CONFIGURE_ARGS+=-DAVIF_BUILD_APPS=ON \
-DAVIF_CODEC_AOM_DECODE=OFF \
-DAVIF_CODEC_DAV1D=ON \
-DAVIF_ENABLE_GTEST=OFF \
- -DCMAKE_DISABLE_FIND_PACKAGE_libsharpyuv=OFF \
- -DCMAKE_DISABLE_FIND_PACKAGE_libyuv=OFF
+ -DCMAKE_DISABLE_FIND_PACKAGE_libsharpyuv=ON \
+ -DCMAKE_DISABLE_FIND_PACKAGE_libyuv=ON
do-test:
${WRKBUILD}/tests/aviftest ${WRKSRC}/tests/data
Re: UPDATE: renpy 7.4.9
Omar Polo writes: > Brad Smith wrote: >> On Fri, Feb 25, 2022 at 02:50:01PM -0500, Brad Smith wrote: >> > Here is an attempt at an update to renpy 7.4.9. >> > >> > Looking for any testing and feedback. >> >> I noticed there was a slightly newer version available with 7.4.11. > > builds fine but fails badly at runtime > > % renpy > Traceback (most recent call last): > File "./renpy.py", line 199, in > main() > File "./renpy.py", line 195, in main > renpy.bootstrap.bootstrap(renpy_base) > File "/usr/local/share/renpy/renpy/bootstrap.py", line 306, in bootstrap > renpy.import_all() > File "/usr/local/share/renpy/renpy/__init__.py", line 454, in import_all > import renpy.display.core # object @UnresolvedImport > File "/usr/local/share/renpy/renpy/display/core.py", line 83, in > pygame.KEYMAPCHANGED, > AttributeError: 'module' object has no attribute 'KEYMAPCHANGED' > > do we need a newer pygame? games/pygame_sdl2 should be newer or match games/renpy version. Regular pygame isn't used since 6.99 due to "import pygame_sdl2 as pygame". See also https://github.com/renpy/pygame_sdl2/issues/134#issuecomment-986158575 Disclaimer: I don't use OpenBSD but maintain renpy in FreeBSD ports.
Re: Determinism in generated sourcehut tarballs
"Drew DeVault" writes: > Hiya ports, just writing to let you know that tarballs generated by > git.sr.ht and hg.sr.ht are deterministic. We defer to git to generate > tars, and busybox to gzip them; git has tests enforcing determinism, and > we patched busybox to be deterministic as well. Wouldn't https://todo.sr.ht/~sircmpwn/hg.sr.ht/33 prevent usage in MASTER_SITES?
Re: NEW: x11/picom
Omar Polo writes: > - the patch-src_meson_build is an hack to avoid a meson error I > cannot > understand Upstreaming as https://github.com/yshui/picom/pull/422
Re: [-CURRENT] Microphone does not work in firefox anymore
a...@abiscuola.com writes: > Hi all. > > I installed the latest snapshot and, suddenly, the microphone > stopped working in firefox. Does it happen since nss 3.52 update? If so ask landry@ to apply https://hg.mozilla.org/mozilla-central/rev/463069687b3d See https://bugzilla.mozilla.org/show_bug.cgi?id=1636632
Re: aarch64 bulk build report
phess...@openbsd.org writes: > bulk build on arm64.ports.openbsd.org > started on Wed Nov 13 00:40:30 MST 2019 > finished at Thu Nov 14 21:08:18 MST 2019 > lasted 1D20h27m > done with kern.version=OpenBSD 6.6-current (GENERIC.MP) #323: Tue Nov 12 > 22:50:47 MST 2019 > > built packages:10194 > Nov 13:4720 > Nov 14:5473 > > > critical path missing pkgs: > http://build-failures.rhaalovely.net/aarch64/2019-11-13/summary.log > > build failures: 29 [...] > http://build-failures.rhaalovely.net/aarch64/2019-11-13/graphics/vulkan-loader.log Does OpenBSD aarch64 lack /usr/bin/as? If so try dropping -ATT suffix e.g., https://github.com/freebsd/freebsd-ports/blob/f3ead47ac4be/graphics/vulkan-loader/Makefile#L42-L46
Re: devel/git: cpu and memory tracking, LIB_DEPENDS
Kurt Miller writes:
> On Tue, 2019-11-05 at 14:44 +0100, Jan Beich wrote:
>
>> Kurt Miller writes:
>>
>> >
>> > On Tue, 2019-11-05 at 09:17 +0100, Jan Beich wrote:
>> >
>> > >
>> > > Jeremie Courreges-Anglas writes:
>> > >
>> > > >
>> > > >
>> > > > ++#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
>> > > > defined(HW_PHYSMEM64))
>> > > > + int64_t physical_memory;
>> > > HW_MEMSIZE and HW_PHYSMEM64 return uint64_t, not int64_t.
>> > >
>> > > >
>> > > >
>> > > > ++#elif defined(HAVE_BSD_SYSCTL) && defined(HW_PHYSMEM))
>> > > > ++ int physical_memory;
>> > > HW_PHYSMEM returns u_long (unsigned long) on DragonFly and FreeBSD.
>> > > int or signed long may upset -fsanitize=integer on 32-bit archs.
>> > >
>> > > Note, the code can be simplified via sysconf(3).
>> > >
>> > > --- builtin/gc.c 2019-11-04 05:07:07 UTC
>> > > +++ builtin/gc.c
>> > > @@ -243,20 +243,27 @@ static uint64_t total_ram(void)
>> > >
>> > > if (!sysinfo(&si))
>> > > return si.totalram;
>> > > -#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
>> > > defined(HW_PHYSMEM))
>> > > -int64_t physical_memory;
>> > > -int mib[2];
>> > > -size_t length;
>> > > -
>> > > -mib[0] = CTL_HW;
>> > > +#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
>> > > defined(HW_PHYSMEM64) || defined(HW_PHYSMEM))
>> > > +# if defined(HW_MEMSIZE) || defined(HW_PHYSMEM64)
>> > > +uint64_t physical_memory;
>> > > +# else
>> > > +u_long physical_memory;
>> > > +# endif
>> > > +int mib[2] = {
>> > > +CTL_HW,
>> > > # if defined(HW_MEMSIZE)
>> > > -mib[1] = HW_MEMSIZE;
>> > > +HW_MEMSIZE,
>> > > +# elif defined(HW_PHYSMEM64)
>> > > +HW_PHYSMEM64,
>> > > # else
>> > > -mib[1] = HW_PHYSMEM;
>> > > +HW_PHYSMEM,
>> > > # endif
>> > > -length = sizeof(int64_t);
>> > > +};
>> > > +size_t length = sizeof(mib);
>> > size_t length = sizeof(physical_memory);
>> Sorry. sizeof(int[2]) > sizeof(unsigned long) on i386, so sysctl(3)
>> could overflow &physical_memory iff FreeBSD kernel tried to return
>> larger value or padded it with junk/zeros.
>
> I think you are confused. The fourth argument to sysctl(2) is
> the address of a size_t that contains sizeof the third argument
> before the call. Also HW_PHYSMEM64 is int64_t on OpenBSD.
I didn't disagree. My reply was an attempt to understand what may go
wrong at runtime as the typo didn't trigger -fsanitize=address.
Re: devel/git: cpu and memory tracking, LIB_DEPENDS
Kurt Miller writes:
> On Tue, 2019-11-05 at 09:17 +0100, Jan Beich wrote:
>
>> Jeremie Courreges-Anglas writes:
>>
>> >
>> > ++#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
>> > defined(HW_PHYSMEM64))
>> > + int64_t physical_memory;
>> HW_MEMSIZE and HW_PHYSMEM64 return uint64_t, not int64_t.
>>
>> >
>> > ++#elif defined(HAVE_BSD_SYSCTL) && defined(HW_PHYSMEM))
>> > ++ int physical_memory;
>> HW_PHYSMEM returns u_long (unsigned long) on DragonFly and FreeBSD.
>> int or signed long may upset -fsanitize=integer on 32-bit archs.
>>
>> Note, the code can be simplified via sysconf(3).
>>
>> --- builtin/gc.c 2019-11-04 05:07:07 UTC
>> +++ builtin/gc.c
>> @@ -243,20 +243,27 @@ static uint64_t total_ram(void)
>>
>> if (!sysinfo(&si))
>> return si.totalram;
>> -#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
>> defined(HW_PHYSMEM))
>> -int64_t physical_memory;
>> -int mib[2];
>> -size_t length;
>> -
>> -mib[0] = CTL_HW;
>> +#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
>> defined(HW_PHYSMEM64) || defined(HW_PHYSMEM))
>> +# if defined(HW_MEMSIZE) || defined(HW_PHYSMEM64)
>> +uint64_t physical_memory;
>> +# else
>> +u_long physical_memory;
>> +# endif
>> +int mib[2] = {
>> +CTL_HW,
>> # if defined(HW_MEMSIZE)
>> -mib[1] = HW_MEMSIZE;
>> +HW_MEMSIZE,
>> +# elif defined(HW_PHYSMEM64)
>> +HW_PHYSMEM64,
>> # else
>> -mib[1] = HW_PHYSMEM;
>> +HW_PHYSMEM,
>> # endif
>> -length = sizeof(int64_t);
>> +};
>> +size_t length = sizeof(mib);
>
> size_t length = sizeof(physical_memory);
Sorry. sizeof(int[2]) > sizeof(unsigned long) on i386, so sysctl(3)
could overflow &physical_memory iff FreeBSD kernel tried to return
larger value or padded it with junk/zeros.
Re: devel/git: cpu and memory tracking, LIB_DEPENDS
Jeremie Courreges-Anglas writes:
> ++#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
> defined(HW_PHYSMEM64))
> + int64_t physical_memory;
HW_MEMSIZE and HW_PHYSMEM64 return uint64_t, not int64_t.
> ++#elif defined(HAVE_BSD_SYSCTL) && defined(HW_PHYSMEM))
> ++int physical_memory;
HW_PHYSMEM returns u_long (unsigned long) on DragonFly and FreeBSD.
int or signed long may upset -fsanitize=integer on 32-bit archs.
Note, the code can be simplified via sysconf(3).
--- builtin/gc.c2019-11-04 05:07:07 UTC
+++ builtin/gc.c
@@ -243,20 +243,27 @@ static uint64_t total_ram(void)
if (!sysinfo(&si))
return si.totalram;
-#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) || defined(HW_PHYSMEM))
- int64_t physical_memory;
- int mib[2];
- size_t length;
-
- mib[0] = CTL_HW;
+#elif defined(HAVE_BSD_SYSCTL) && (defined(HW_MEMSIZE) ||
defined(HW_PHYSMEM64) || defined(HW_PHYSMEM))
+# if defined(HW_MEMSIZE) || defined(HW_PHYSMEM64)
+ uint64_t physical_memory;
+# else
+ u_long physical_memory;
+# endif
+ int mib[2] = {
+ CTL_HW,
# if defined(HW_MEMSIZE)
- mib[1] = HW_MEMSIZE;
+ HW_MEMSIZE,
+# elif defined(HW_PHYSMEM64)
+ HW_PHYSMEM64,
# else
- mib[1] = HW_PHYSMEM;
+ HW_PHYSMEM,
# endif
- length = sizeof(int64_t);
+ };
+ size_t length = sizeof(mib);
if (!sysctl(mib, 2, &physical_memory, &length, NULL, 0))
return physical_memory;
+#elif defined(_SC_PHYS_PAGES) && defined(_SC_PAGESIZE)
+ return (uint64_t)sysconf(_SC_PHYS_PAGES) * sysconf(_SC_PAGESIZE);
#elif defined(GIT_WINDOWS_NATIVE)
MEMORYSTATUSEX memInfo;
Re: print/poppler: use boost (also fixes possible build breakage)
Matthias Kilian writes: > -BUILD_DEPENDS+= devel/gobject-introspection > +# devel/boost only as build dependency, because poppler uses > +# header-only classes (from boost/containers/small_vector.hpp). > +BUILD_DEPENDS+= devel/boost \ > + devel/gobject-introspection Don't you need to adjust RUN_DEPENDS for API dependency? $ rg -i boost /usr/local/include/poppler /usr/local/include/poppler/poppler-config.h 114:/* Use header-only classes from Boost in the Splash backend */ 115:#ifndef USE_BOOST_HEADERS 116:#define USE_BOOST_HEADERS 1 /usr/local/include/poppler/splash/SplashXPathScanner.h 30:#ifdef USE_BOOST_HEADERS 31:#include 103:#ifdef USE_BOOST_HEADERS 104: typedef boost::container::small_vector IntersectionLine; 122:#ifdef USE_BOOST_HEADERS 123: typedef boost::container::small_vector IntersectionLine;
Re: UPDATE: emulators/ppsspp
"Anthony J. Bentley" writes: > GH_ACCOUNT = hrydgard > GH_PROJECT = ppsspp > -GH_TAGNAME = v1.5.4 > +GH_TAGNAME = v1.6.2 v1.6.3 was released some time ago, a day after you've started the thread. Is there a reason OpenBSD port cannot update to it? https://github.com/hrydgard/ppsspp/releases.atom https://github.com/hrydgard/ppsspp/compare/v1.6.2...v1.6.3 https://repology.org/metapackage/ppsspp/history FWIW, FreeBSD port also applied fixes that didn't make into 1.6.*: https://github.com/hrydgard/ppsspp/commit/c783e7761c2a https://github.com/hrydgard/ppsspp/commit/f2a75719d843 https://github.com/hrydgard/ppsspp/commit/78a41980dfd7
Re: UPDATE: emulators/ppsspp
> Here's an update to ppsspp-1.6.2. Do you plan to add libretro flavor a la mgba/nestopia? https://github.com/hrydgard/ppsspp/pull/10780 > LIB_DEPENDS =archivers/snappy \ > - archivers/libzip \ Have you tried the following? CONFIGURE_ARGS += -DUSE_SYSTEM_LIBZIP=ON http://github.com/hrydgard/ppsspp/commit/59d6cc12f2c6
Re: on clang-archs: watch out for '-e xport-dynamic' warnings
Jeremie Courreges-Anglas writes: > +--- src/Makefile.am.orig > src/Makefile.am > +@@ -24,5 +24,6 @@ AM_CPPFLAGS = @PACKAGE_CFLAGS@ \ > + -DPACKAGE_DATA_DIR=\""$(datadir)"\" \ > + -DPACKAGE_LOCALE_DIR=\""$(prefix)/$(DATADIRNAME)/locale"\" > + > +-AM_CFLAGS = -export-dynamic -Wall > ++AM_CFLAGS = -Wall > ++AM_LDAGS = -rdynamic ^^ Did you mean AM_LDFLAGS instead?
Re: www/mozilla-firefox: doesn't try to use SSE2 on i386
Sebastien Marie writes:
> Hi,
>
> The following diff makes i386 to be compiled without --enable-rust-simd.
> simd is "Single instruction, multiple data" (aka MMX, SSE, SSE2...).
[...]
> +# bug 1261841
> +.if ${MACHINE_ARCH} == "amd64"
> +CONFIGURE_ARGS += --enable-rust-simd
> .endif
Despite LLVM emitting SSE2 code by default on i386?
https://github.com/rust-lang/rust/blob/1.22.1/src/librustc_back/target/i686_unknown_openbsd.rs#L16
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223415
Re: clang FFmpeg segfaults on i386 [st...@openbsd.org: CVS: cvs.openbsd.org: ports]
Stuart Henderson writes: [...] > So this works around the recently-reported hangs seen on amd64 but we > still have a segfault issue on i386 (I've only seen this so far when > decoding H264, though given the function other things may use it too). Probably same as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205958 Update to FFmpeg 3.2+ or try the following patch. --- configure~ +++ configure @@ -5685,6 +5685,10 @@ elif enabled llvm_gcc; then check_cflags -mllvm -stack-alignment=16 elif enabled clang; then check_cflags -mllvm -stack-alignment=16 +check_cflags -mstack-alignment=16 +if enabled x86_32; then +check_cflags -mstackrealign +fi check_cflags -Qunused-arguments check_cflags -Werror=implicit-function-declaration check_cflags -Werror=missing-prototypes signature.asc Description: PGP signature
Re: NEW: emulation/ppsspp-1.3
Jakub Skrzypnik writes:
> USE_WXNEEDED = Yes
JIT supports W^X, see https://github.com/hrydgard/ppsspp/issues/8943
Maybe try the following instead
--- Common/MemoryUtil.cpp~
+++ Common/MemoryUtil.cpp
@@ -281,7 +281,7 @@ void FreeAlignedMemory(void* ptr) {
bool PlatformIsWXExclusive() {
// Only iOS really needs this mode currently. Even without block
linking, still should be much faster than IR JIT.
// This might also come in useful for UWP (Universal Windows Platform)
if I'm understanding things correctly.
-#if defined(IOS) || PPSSPP_PLATFORM(UWP)
+#if defined(IOS) || PPSSPP_PLATFORM(UWP) || defined(__OpenBSD__)
return true;
#else
// Returning true here lets you test the W^X path on Windows and other
non-W^X platforms.
Re: NEW: emulation/ppsspp-1.3
Jakub Skrzypnik writes:
> Build system is pretty messy, I wasted few hours for non-defining
> BSD_VISIBLE definition (added it to C{,XX}FLAGS finally),
Have you tried to remove -D_XOPEN_SOURCE* lines in CMakeLists.txt?
Each BSD seems to have slightly different way to hide namespace
pollution to be POSIX-ly correct.
>
> From DESCR:
>> PPSSPP is an Sony PlayStation Portable emulator using HLE (high-Level
>> Emulation), so you don't need a operating system's ROM to use it.
>
> PS: I used my own storage for DISTFILES, becuase the Git source tree
> contains about 10 submodules,
PPSSPP v1.3 only needs 3 distfiles while v1.4 - only 6. It should build
fine without downloading submodules for dx9sdk, ffmpeg, pspautotests or
glslang (before v1.4).
> LIB_DEPENDS = graphics/ffmpeg \
Beware of https://github.com/hrydgard/ppsspp/issues/9026
> graphics/png\
PPSSPP v1.3 has bundled libpng v1.7.0beta35 which is affected by
CVE-2016-10087, CVE-2015-8472, CVE-2015-8126, CVE-2014-9495, CVE-2015-0973.
Maybe unbundle e.g.,
https://svnweb.freebsd.org/ports/head/emulators/ppsspp/files/patch-system-libpng16?revision=422387&view=markup
>archivers/snappy\
libzip can also be unbundled.
> CONFIGURE_ARGS =-DUSE_SYSTEM_FFMPEG=True
arm* may also want -DUSING_EGL=off as EGL doesn't seem to work with X11.
aarch64 would have to wait for v1.4 or later.
