Re: UPDATE: aom 3.8.1

[Jan Beich]

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

[Jan Beich]

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

[Jan Beich]

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?

[Jan Beich]

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

[Jan Beich]

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

[Jan Beich]

"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

[Jan Beich]

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

[Jan Beich]

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: CVS: cvs.openbsd.org: ports

[Jan Beich]

Antoine Jacoutot  writes:

> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   ajacou...@cvs.openbsd.org   2019/12/25 08:48:26
>
> Modified files:
>   multimedia/mpv : Makefile 
>   x11/vlc: Makefile 
> Added files:
>   x11/vlc/patches: 
>patch-modules_video_output_opengl_fragment_shaders_c 
>patch-modules_video_output_opengl_vout_helper_c 
>patch-modules_video_output_opengl_vout_helper_h 
>
> Log message:
> Enable libplacebo support.
>
> from Brad

mpv doesn't use libplacebo outside of --gpu-api=vulkan but OpenBSD Ports
for both mpv and libplacebo disable Vulkan.

vlc is different. Vulkan output is slated for 4.0 while 3.0 uses
libplacebo for HDR tone mapping on OpenGL output.

Re: aarch64 bulk build report

[Jan Beich]

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

[Jan Beich]

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())
>> > >  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 _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

[Jan Beich]

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())
>>  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 _memory iff FreeBSD kernel tried to return
larger value or padded it with junk/zeros.

Re: devel/git: cpu and memory tracking, LIB_DEPENDS

[Jan Beich]

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())
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, _memory, , 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)

[Jan Beich]

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: CVS: cvs.openbsd.org: ports

[Jan Beich]

Thomas Frohwein  writes:

> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   t...@cvs.openbsd.org2019/03/30 23:09:06
>
> Log message:
> import OpenRA, an engine for real-time strategy games
> 
> ok bentley@ (for slightly older version that didn't include additional 
> launch
> scripts), additional testing by solene@ and Matthias Schmidt (openbsd () 
> xosc DOT org)
[...]
> $OpenBSD: patch-thirdparty_download_SDL2-CS_dll_config,v 1.1.1.1 2019/03/31 
> 05:09:06 thfr Exp $
>
> add openbsd to dllmap
>
> Index: thirdparty/download/SDL2-CS.dll.config
> --- thirdparty/download/SDL2-CS.dll.config.orig
> +++ thirdparty/download/SDL2-CS.dll.config
> @@ -2,4 +2,5 @@
>  
>   
>   
> + 
>  

Does Mono on OpenBSD match os="linux" as well?

Re: UPDATE: emulators/ppsspp

[Jan Beich]

"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

[Jan Beich]

> 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

[Jan Beich]

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

[Jan Beich]

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]

[Jan Beich]

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

[Jan Beich]

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

[Jan Beich]

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=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.