Re: New: rigg - program to run independent games with unveil

[Bryan Steele]

On Sat, Apr 27, 2024 at 10:57:28PM -0400, Thomas Frohwein wrote:
> updated tarball; I had some left over, commented out lines in the
> Makefile and unnecessary SUBST_*.

Looks good, having this in the ports tree would be nice.

ok brynet@ for what its worth :-)

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

Re: security/openssl/3.1 endbr64 sprinkling

[Bryan Steele]

Hey Mark, does the order of .cfi_startproc and endbranch matter at all,
I noticed a difference between your openssl/3.1 and 3.2 patches and was
just wondering, it's reversed in gcm_init_avx.

-Bryan.

diff -u -p -r1.1.1.1 patch-crypto_modes_asm_ghash-x86_64_pl
--- security/openssl/3.1/patches/patch-crypto_modes_asm_ghash-x86_64_pl
14 Mar 2023 18:54:42 -  1.1.1.1
+++ security/openssl/3.1/patches/patch-crypto_modes_asm_ghash-x86_64_pl
18 Feb 2024 22:25:50 -
@@ -1,7 +1,23 @@
 Index: crypto/modes/asm/ghash-x86_64.pl
 --- crypto/modes/asm/ghash-x86_64.pl.orig
 +++ crypto/modes/asm/ghash-x86_64.pl
-@@ -1609,6 +1609,7 @@ ___
+@@ -534,6 +534,7 @@ $code.=<<___;
+ .align16
+ gcm_init_clmul:
+ .cfi_startproc
++  endbranch
+ .L_init_clmul:
+ ___
+ $code.=<<___ if ($win64);
+@@ -1026,6 +1027,7 @@ $code.=<<___;
+ .type gcm_init_avx,\@abi-omnipotent
+ .align32
+ gcm_init_avx:
++  endbranch
+ .cfi_startproc
+ ___
+ if ($avx) {
+@@ -1609,6 +1611,7 @@ ___
  }
  
  $code.=<<___;
@@ -9,7 +25,7 @@ Index: crypto/modes/asm/ghash-x86_64.pl
  .align64
  .Lbswap_mask:
.byte   15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0
-@@ -1662,6 +1663,7 @@ $code.=<<___;
+@@ -1662,6 +1665,7 @@ $code.=<<___;
  
  .asciz"GHASH for x86_64, CRYPTOGAMS by "
  .align64

Re: lang/mono: stop using syscall(2)

[Bryan Steele]

On Fri, Oct 27, 2023 at 09:45:52PM -0400, Thomas Frohwein wrote:
> This diff patches out mono's use of syscall(SYS_fork), which is the
> only instance of syscall(2) in use. Upstream has this behind:
> 
> #elif !defined(HOST_DARWIN) && defined(SYS_fork)
> 
> This diff changes that to #elif defined(__linux__)... and as a
> consequence, fork(2) is simply used.
> 
> With this patched, none of the mono binaries I looked at (mono,
> mono-sgen, monodis) or shared objects have any reference to syscall(2)
> anymore.
> 
> ok?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/mono/Makefile,v
> retrieving revision 1.156
> diff -u -p -r1.156 Makefile
> --- Makefile  26 Sep 2023 12:02:02 -  1.156
> +++ Makefile  28 Oct 2023 01:45:11 -
> @@ -6,7 +6,7 @@ COMMENT=  cross platform, open source .NE
>  V=   6.12.0.199
>  
>  DISTNAME=mono-${V}
> -REVISION=1
> +REVISION=2
>  
>  CATEGORIES=  lang devel
>  
> Index: patches/patch-mono_mini_mini-posix_c
> ===
> RCS file: patches/patch-mono_mini_mini-posix_c
> diff -N patches/patch-mono_mini_mini-posix_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-mono_mini_mini-posix_c  28 Oct 2023 01:45:12 -
> @@ -0,0 +1,14 @@
> +It is *ONLY* Linux that does special shit in fork(2)
> +
> +Index: mono/mini/mini-posix.c
> +--- mono/mini/mini-posix.c.orig
>  mono/mini/mini-posix.c
> +@@ -940,7 +940,7 @@ fork_crash_safe (void)
> + #if defined(HOST_ANDROID)
> + /* SYS_fork is defined to be __NR_fork which is not defined in some ndk 
> versions */
> + g_assert_not_reached ();
> +-#elif !defined(HOST_DARWIN) && defined(SYS_fork)
> ++#elif defined(__linux__) && defined(SYS_fork)
> + pid = (pid_t) syscall (SYS_fork);
> + #elif HAVE_FORK
> + pid = (pid_t) fork ();

I think this is obviously correct, if there are any missed, they can
be added later.

ok brynet@

Re: chromium 96.0.4664.110 stopped working with Dec 19th snapshot

[Bryan Steele]

On Sun, Dec 19, 2021 at 06:24:21PM -0600, Amit Kulkarni wrote:
> On Sun, Dec 19, 2021 at 2:23 PM Bryan Steele  wrote:
> >
> > I'm thinking this could be llvm/clang13 fallout, but with the new Dec 19
> > snapshot chromium stopped working for me. It opens up a blank white
> > page, and trying to visit any website is stuck "loading..."
> >
> > In ps(1), one chrome subprocess is pegging a CPU at 99% utilization..
> >
> >  brynet   10507 96.6  0.8 14 64620 p5  R+pU/3  3:00PM1:01.60
> >  chrome: --type=utility --utility-sub-type=network.mojom.NetworkService
> >  --field-trial-handle=9547151940239398474,4827432241527663666,131072
> >  --disable-features=AsmJsToWebAssembly,WebAssembly,WebAssemblyStreaming
> >  --lang=en-GB --service-sandbox-type=network
> >  --change-stack-guard-on-fork=enable
> >  --shared-files=v8_context_snapshot_data:100 (chrome)
> >
> > I don't see any pledge violations in dmesg, but when starting chrome in
> > an xterm, I'm getting this shortly afterward:
> >
> >   
> > [61545:-1478398720:1219/150010.299942:ERROR:network_service_instance_impl.cc(916)]
> >   Network service crashed, restarting service.
> >
> >  -Bryan.
> >
> 
> Iridium has the same fallout!

Installing chromium-96.0.4664.110 from a previous snapshot linked
with libc++.so.8.0/libc++abi.so.5.1 works.

The package linked with libc++.so.9.0/libc++abi.so.6.0 does not, so
this is looking indeed llvm13 fallout.

-Bryan.

chromium 96.0.4664.110 stopped working with Dec 19th snapshot

[Bryan Steele]

I'm thinking this could be llvm/clang13 fallout, but with the new Dec 19
snapshot chromium stopped working for me. It opens up a blank white
page, and trying to visit any website is stuck "loading..."

In ps(1), one chrome subprocess is pegging a CPU at 99% utilization..

 brynet   10507 96.6  0.8 14 64620 p5  R+pU/3  3:00PM1:01.60
 chrome: --type=utility --utility-sub-type=network.mojom.NetworkService
 --field-trial-handle=9547151940239398474,4827432241527663666,131072
 --disable-features=AsmJsToWebAssembly,WebAssembly,WebAssemblyStreaming
 --lang=en-GB --service-sandbox-type=network
 --change-stack-guard-on-fork=enable
 --shared-files=v8_context_snapshot_data:100 (chrome)
 
I don't see any pledge violations in dmesg, but when starting chrome in
an xterm, I'm getting this shortly afterward:
 
  
[61545:-1478398720:1219/150010.299942:ERROR:network_service_instance_impl.cc(916)]
  Network service crashed, restarting service.
 
 -Bryan.

Re: new games/amnesia-tdd

[Bryan Steele]

On Sat, Oct 23, 2021 at 07:16:20PM -0700, Nam Nguyen wrote:
> Please find attached a port for Amnesia: The Dark Descent. It is a port
> from brynet@ with tweaks by me.
> 
> Thanks to brynet@ for making and upstreaming patches to compile on
> OpenBSD with clang. Thanks to shamazmazum for providing an upstream for
> this port and getting it to run on FreeBSD. Thanks to thfr@ for intial
> feedback on this port, including the suggestion to name it amnesia-tdd
> to leave room for a future port of Amnesia: A Machine for Pigs.
> 
> The game was initially open-sourced on September 23, 2020. It required
> some new ports: AngelScript and Newton Dynamics. After shamazmazum got
> it running on FreeBSD, it now bundles both so no need for new ports.
> 
> Feedback and tests are welcome. OK?
> 
> pkg/DESCR:
> Amnesia: The Dark Descent, a first person survival horror. A game about
> immersion, discovery and living through a nightmare. An experience that
> will chill you to the core.
> 

Note that you'll also need the game data from e.g: Steam to play this. I
also tested it works with the Epic Games store version.

thfr@ sent a port recent for steamctl which might be helpful for
obtaining this as well.

https://marc.info/?l=openbsd-ports=163413529509808=2

-Bryan.

Re: new games/amnesia-tdd

[Bryan Steele]

On Sat, Oct 23, 2021 at 07:16:20PM -0700, Nam Nguyen wrote:
> Please find attached a port for Amnesia: The Dark Descent. It is a port
> from brynet@ with tweaks by me.
> 
> Thanks to brynet@ for making and upstreaming patches to compile on
> OpenBSD with clang. Thanks to shamazmazum for providing an upstream for
> this port and getting it to run on FreeBSD. Thanks to thfr@ for intial
> feedback on this port, including the suggestion to name it amnesia-tdd
> to leave room for a future port of Amnesia: A Machine for Pigs.
> 
> The game was initially open-sourced on September 23, 2020. It required
> some new ports: AngelScript and Newton Dynamics. After shamazmazum got
> it running on FreeBSD, it now bundles both so no need for new ports.
> 
> Feedback and tests are welcome. OK?
> 
> pkg/DESCR:
> Amnesia: The Dark Descent, a first person survival horror. A game about
> immersion, discovery and living through a nightmare. An experience that
> will chill you to the core.

ok brynet@ :-)

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2021/08/20 15:54:22

Modified files:
audio/openal   : Makefile 
audio/openal/patches: patch-alc_backends_sndio_cpp 

Log message:
Backport the following two commits from upstream, which fixes the sndio
backend changes that were introduced in the 1.21.1 update.

Simplify channel handling in the sndio backend
620836f173ae6fc4505d0634984e0f2c46166367

Use non-block mode for sndio capture
1fd4c865fc084f134363db5155361d5483679235

>From Brad, tested by me

ok maintainer (David CARLIER)

Re: audio/openal no longer works since 1.21.1 update

[Bryan Steele]

On Sat, Jul 31, 2021 at 12:31:42AM -0400, Brad Smith wrote:
> On Thu, Jul 29, 2021 at 03:01:33PM -0400, Kurt Mosiejczuk wrote:
> > On Thu, Jul 29, 2021 at 02:46:57PM -0400, Bryan Steele wrote:
> > 
> > > > > It would be nice to commit his diff below, or perhaps backout the 
> > > > > 1.21.1
> > > > > update in ports until the bug can be fixed upstream..
> > 
> > > > It fixes audio for me. ok kmos on using this diff.
> > 
> > > ok brynet@ too.
> > 
> > To be clear, I _prefer_ keeping the update with the diff since it has cured
> > the clipping I experienced all the time with minecraft (and sometimes with
> > other things). I just played for a few minutes during work time because I so
> > enjoyed the clipping being gone. :D
> > 
> > --Kurt
> 
> Can you guys try out the following diff?
> 
> After bringing up the breakage upstream it looks like the author
> fixed whatever the root issue was.

Sorry I missed this, I have tested that sound still works with this
fix as well.

-Bryan.

> Index: Makefile
> ===
> RCS file: /home/cvs/ports/audio/openal/Makefile,v
> retrieving revision 1.56
> diff -u -p -u -p -r1.56 Makefile
> --- Makefile  30 Jul 2021 12:47:53 -  1.56
> +++ Makefile  31 Jul 2021 03:50:08 -
> @@ -6,7 +6,7 @@ V =   1.21.1
>  EPOCH =  0
>  DISTNAME =   openal-soft-$V
>  PKGNAME =openal-$V
> -REVISION =   0
> +REVISION =   1
>  CATEGORIES = audio
>  
>  SHARED_LIBS =openal  4.1
> Index: patches/patch-alc_backends_sndio_cpp
> ===
> RCS file: /home/cvs/ports/audio/openal/patches/patch-alc_backends_sndio_cpp,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 patch-alc_backends_sndio_cpp
> --- patches/patch-alc_backends_sndio_cpp  31 Jul 2021 00:27:59 -  
> 1.2
> +++ patches/patch-alc_backends_sndio_cpp  31 Jul 2021 04:02:08 -
> @@ -1,30 +1,45 @@
>  $OpenBSD: patch-alc_backends_sndio_cpp,v 1.2 2021/07/31 00:27:59 brynet Exp $
>  
> -Revert..
> +Simplify channel handling in the sndio backend
> +620836f173ae6fc4505d0634984e0f2c46166367
>  
> -sndio: Support more than 2 channels
> -5cffe7e50a2885d9b392c15f2cd3941cac49692c
> +Use non-block mode for sndio capture
> +1fd4c865fc084f134363db5155361d5483679235
>  
> -and
> -
> -Use a safer layout if sndio changes the channel count
> -b4a52321c4ad8e8bc0eb29d2cdae2c043fc405e1
> -
> -which break the backend.
>  
>  Index: alc/backends/sndio.cpp
>  --- alc/backends/sndio.cpp.orig
>  +++ alc/backends/sndio.cpp
> -@@ -57,7 +57,7 @@ struct SndioPlayback final : public BackendBase {
> +@@ -22,6 +22,7 @@
> + 
> + #include "backends/sndio.h"
> + 
> ++#include 
> + #include 
> + #include 
> + #include 
> +@@ -43,7 +44,12 @@ namespace {
> + 
> + static const char sndio_device[] = "SndIO Default";
> + 
> ++struct SioPar : public sio_par {
> ++SioPar() { sio_initpar(this); }
> + 
> ++void clear() { sio_initpar(this); }
> ++};
> ++
> + struct SndioPlayback final : public BackendBase {
> + SndioPlayback(ALCdevice *device) noexcept : BackendBase{device} { }
> + ~SndioPlayback() override;
> +@@ -56,6 +62,7 @@ struct SndioPlayback final : public BackendBase {
> + void stop() override;
>   
>   sio_hdl *mSndHandle{nullptr};
> ++uint mFrameStep{};
>   
> --al::vector mBuffer;
> -+al::vector mBuffer;
> + al::vector mBuffer;
>   
> - std::atomic mKillNow{true};
> - std::thread mThread;
> -@@ -74,24 +74,16 @@ SndioPlayback::~SndioPlayback()
> +@@ -74,39 +81,29 @@ SndioPlayback::~SndioPlayback()
>   
>   int SndioPlayback::mixerProc()
>   {
> @@ -35,106 +50,133 @@ Index: alc/backends/sndio.cpp
>  -mDevice->handleDisconnect("Failed to get device parameters");
>  -return 1;
>  -}
> --
> ++const size_t frameStep{mFrameStep};
> ++const size_t frameSize{frameStep * mDevice->bytesFromFmt()};
> + 
>  -const size_t frameStep{par.pchan};
>  -const size_t frameSize{frameStep * par.bps};
>  -
>   SetRTPriority();
>   althrd_setname(MIXER_THREAD_NAME);
>   
> --while(!mKillNow.load(std::memory_order_acquire)
> --&& mDevice->Connected.load(std::memory_order_acquire))
> -+const size_t frameStep{mDevice->channelsFromFmt()};
> -+const uint frameSize{mDevice->frameSizeFromFmt()};
> -+
> -+while(!mKillNow.load(std::memory_order_acquire) &&
> -+  mDevice->

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2021/07/30 18:27:59

Modified files:
audio/openal/patches: patch-alc_backends_sndio_cpp 

Log message:
Improve comments on patch.

>From brad (no code change)

-Bryan.

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2021/07/30 06:47:54

Modified files:
audio/openal   : Makefile 
Added files:
audio/openal/patches: patch-alc_backends_sndio_cpp 

Log message:
The recent update to 1.21.1 broke sound output.

This was tracked down to two commits upstream which broke the sndio
backend due to >2 channel support being added.

Until this can be sorted out, this diff reverts two upstream commits:
5cffe7e50a2885d9b392c15f2cd3941cac49692c
b4a52321c4ad8e8bc0eb29d2cdae2c043fc405e1

>From Brad, tested by me and kmos@

ok kmos@ sthen@

audio/openal no longer works since 1.21.1 update

[Bryan Steele]

After upgrading to the latest amd64 snapshot, OpenAL is broken now
and no longer produces any sound. It was working for me using
1.20.1 previously.

I tested with ioquake and several games playable using fnaify and
libgdx/lwjgl{2,3}.

No issues with others ports using e.g: SDL2 sndio backend for example,
or audio playback in chromium.

-Bryan.

Re: fix games/barony textures in sdl2-2.0.14

[Bryan Steele]

On Sat, Apr 10, 2021 at 08:39:07PM -0400, Bryan Steele wrote:
> On Sat, Apr 10, 2021 at 04:56:55PM -0700, Nam Nguyen wrote:
> > solene@ reported that games/barony has missing textures.[1] Here is a
> > diff fixing this sourced from a PR by Sylvain Becker.
> > 
> > I used hg bisect to track down the revision in sdl2's repository that
> > introduced this bug.[2] I contacted Sylvain Becker, the author of the sdl2
> > commit. Sylvain fixed barony's usage of sdl2.
> > 
> > The bug is with barony's modification of refcount, which is
> > read-only. The fix uses userdata to stash imgref.
> > 
> > I tried to understand the fix, but more eyes are welcome.
> > 
> > Details
> > ===
> > 
> > >From /usr/local/include/SDL2/SDL_surface.h, refcount is read-only.
> > 
> > /** Application data associated with the surface */
> > void *userdata; /**< Read-write */
> > /** Reference count -- used when freeing surface */
> > int refcount;   /**< Read-mostly */
> > 
> > Important variables:
> > userdata: used to store imgref (the id) of a surface
> > imgref: global Uint32 used to index into allsurfaces, an array of
> >   GL_Surface pointers[3][4]
> > refcount: read-only field in SDL_Surface used to count how many
> >   references are made to a GL_Surface. See deleted comments in 1107-1113
> >   in SDL_pixels.c.[2] It is probably used for some other purpose in the
> >   implementation now that is deleted.
> > 
> > Testing
> > ===
> > 
> > Textures work now with epic game assets downloaded on September 5,
> > 2020. Feedback and tests are welcome. OK?
> > 
> > Footnotes:
> > [1] https://github.com/TurningWheel/Barony/issues/580
> > [2] 
> > https://github.com/libsdl-org/SDL/commit/ebc12a2fd2bb692908884e7db6cc935941a591f2#diff-98a8d948613c29516e252e8134aee43ba14fb7bcd6457d29be3ba99861fd80bcL1107
> > [3] Barony-3.3.7/src/main.cpp:344:Uint32 imgref = 1
> > [4] src/init.cpp:354: allsurfaces = (SDL_Surface**) malloc
> 
> I tested this and can confirm this fixes the texture loading problem
> and makes Barony 3.3.7 playable again, thanks for working with the
> upstream SDL2 developers to find and fix this Nam!
> 
> ok brynet@ at least, but will also need approval by solene@ (maintainer)
> and also naddy@ because of the upcoming ports tree lock.
> 
> -Bryan.

Whoops, sorry solene@.

MAINTAINER =David Carlier 

Re: fix games/barony textures in sdl2-2.0.14

[Bryan Steele]

On Sat, Apr 10, 2021 at 04:56:55PM -0700, Nam Nguyen wrote:
> solene@ reported that games/barony has missing textures.[1] Here is a
> diff fixing this sourced from a PR by Sylvain Becker.
> 
> I used hg bisect to track down the revision in sdl2's repository that
> introduced this bug.[2] I contacted Sylvain Becker, the author of the sdl2
> commit. Sylvain fixed barony's usage of sdl2.
> 
> The bug is with barony's modification of refcount, which is
> read-only. The fix uses userdata to stash imgref.
> 
> I tried to understand the fix, but more eyes are welcome.
> 
> Details
> ===
> 
> >From /usr/local/include/SDL2/SDL_surface.h, refcount is read-only.
> 
> /** Application data associated with the surface */
> void *userdata; /**< Read-write */
> /** Reference count -- used when freeing surface */
> int refcount;   /**< Read-mostly */
> 
> Important variables:
> userdata: used to store imgref (the id) of a surface
> imgref: global Uint32 used to index into allsurfaces, an array of
>   GL_Surface pointers[3][4]
> refcount: read-only field in SDL_Surface used to count how many
>   references are made to a GL_Surface. See deleted comments in 1107-1113
>   in SDL_pixels.c.[2] It is probably used for some other purpose in the
>   implementation now that is deleted.
> 
> Testing
> ===
> 
> Textures work now with epic game assets downloaded on September 5,
> 2020. Feedback and tests are welcome. OK?
> 
> Footnotes:
> [1] https://github.com/TurningWheel/Barony/issues/580
> [2] 
> https://github.com/libsdl-org/SDL/commit/ebc12a2fd2bb692908884e7db6cc935941a591f2#diff-98a8d948613c29516e252e8134aee43ba14fb7bcd6457d29be3ba99861fd80bcL1107
> [3] Barony-3.3.7/src/main.cpp:344:Uint32 imgref = 1
> [4] src/init.cpp:354: allsurfaces = (SDL_Surface**) malloc

I tested this and can confirm this fixes the texture loading problem
and makes Barony 3.3.7 playable again, thanks for working with the
upstream SDL2 developers to find and fix this Nam!

ok brynet@ at least, but will also need approval by solene@ (maintainer)
and also naddy@ because of the upcoming ports tree lock.

-Bryan.

Re: NEW: libgdx, a Java-based framework for games

[Bryan Steele]

On Sat, Feb 20, 2021 at 05:49:28PM -0700, Thomas Frohwein wrote:
> Hi,
> 
> This is a port of libgdx, a framework for games in Java. It has been
> used for a variety of high-profile indie games in recent years. Notable
> titles include Slay the Spire, Pathway, and others [1].
> 
> This port has been made with the main purpose to allow some of those
> games to run, rather than development (although game development might
> also be possible with it). It builds a number of different backend
> libraries (JNI), as well as Java classes that are able to recognize
> OpenBSD as a valid operating system, rather than erroring out.
> 
> This has mainly been tested with Slay the Spire, and the port comes
> with 2 helper scripts (libgdx-setup and libgdx-run) that allow for ease
> of use with Slay the Spire. I am hoping to expand the usability of the
> port and the included scripts to include other games in the near
> future.
> 
> The version of libgdx is 1.9.11 because that is the apparently last one
> that doesn't break backwards compability for Slay the Spire. It can
> also run the game Mewnbase (although the setup is currently much more
> complicated). I anticipate that multiple separate versions of the port
> may be worth having in the future to support at least some of the
> better games with incompatible libgdx backend versions. I haven't found
> one yet that requires a different version than 1.9.11 and runs well, so
> I'm deferring multi-version setup for now.
> 
> A few technical notes on the port:
> 
> - maven pulls in a bunch of dependencies from online [2]. The way I
>   work around this is with the m2repo-libgdx-${VERSION} package that
>   contains all of them, and the '-o' switch for offline mode. I have
>   reviewed the build logs for any hints of it still trying to download
>   and have done a build with the internet connection turned off and all
>   is good for offline building.
> - There are many dependencies, with licenses summarized in the Makefile
>   (Apache 2.0, BSD, LGPL, Eclipse Public License)
> 
> If you own Slay the Spire, you can test the port by going into the
> game's directory where 'desktop-1.0.jar' is located, then run:
> 
> $ libgdx-setup
> $ libgdx-run
> 
> The game works very well overall, but online features and gamepad are
> not supported at the moment. There is also a high-frequency flickering
> of transparent/fading objects that I haven't been able to debug yet.
> Occasionally, it fails to load libopenal on startup.
> 
> On another technical note: a few of the patch-* filenames are too long
> for tar(1), so I made the tarball with gtar. I was able to unpack it
> with tar(1) without issues.
> 
> [1] https://libgdx.com/
> [2] https://mvnrepository.com/

I tested this builds for me on amd64, and the wrapper scripts work for
me with Slay the Spire (after some self-inflicted foot injuries).

There are some improvements that can be made but that can always happen
in-tree.

-Bryan.

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

[Bryan Steele]

On Tue, Feb 09, 2021 at 01:47:37PM +, Laurence Tratt wrote:
> On Tue, Feb 09, 2021 at 10:57:32PM +1100, Jonathan Gray wrote:
> 
> Hello Jonathan,
> 
> > See previous libva discussions.  If it is to support more than just Intel
> > it needs to be in xenocara and new Mesa Makefiles will need to be written.
> >
> > That would also be the case to use gallium-va with the iris Mesa driver for
> > Intel >= gen8.
> 
> I'm not aware of the previous discussions, but I'm not sure if you're saying
> "don't put it in ports" or not?

Yes. On AMD graphics (and I guess Intel >= gen8) Mesa needs to be linked
with libva, and Mesa is a part of xenocara. Building the base system does
not depend on ports.

> Even if it means that *only* Intel hardware benefits for the time being, this
> port is really very useful and I've been working with Eugene to test his
> work. Now that I've got it up and running, it's pretty impressive: for
> example, on my OpenBSD machine, ffmpeg video encoding on a test file went
> from 6m30 down to 2m20 (also, not coincidentally, moving from fully consuming
> all 4 cores at to consuming only a small portion of 1 core).

It's certainly something that would be nice to have, and has been
attempted a few times. Someone just needs to pick up the work that has
been started by others.

The original ports discussions:

https://marc.info/?t=15762647571=1=2
https://marc.info/?t=15758739041=1=2

..when it moved to tech@ to attempt xenocara integration:

https://marc.info/?t=15767653863=1=2

> If nothing else, support in ports might be a useful stepping stone on the way
> to having libva in xenocara which, I imagine, is a rather harder job?
> 
> Laurie

Putting something into ports knowing that it's the wrong place feels
wrong, and will undoubtedly cause friction later when moved to base.

-Bryan.

Re: devel/sdl2: enable real GUID-based controller mapping

[Bryan Steele]

On Thu, Jan 21, 2021 at 12:05:59PM -0700, Thomas Frohwein wrote:
> On Sat, Jan 09, 2021 at 10:46:17AM -0700, Thomas Frohwein wrote:
> > Hi,
> > 
> > The next stepping stone in my project to improve out-of-the-box
> > gamecontroller support.
> 
> Haven't gotten much feedback since I sent this out. Below is a slightly
> adjusted diff that generates the GUID in BSD_JoystickOpen rather than
> BSD_JoystickInit, avoiding a duplicate open(2) - close(2) dance.
> 
> Some testing would be appreciated - I tested it on 4 controllers, but
> it would be good to see that this works with some more controllers.
> 
> Here the Cliff notes of the diff:
> - Enables using GUID to get joystick mapping from the included (or
>   game-specific) controller mapping.
> - This replaces the prior workaround that was much more primitive, with
>   a fallback to standard XBox360 mapping and customization with a hand-
>   crafter SDL_GAMECONTROLLERCONFIG environment variable.
> - The entire patch for SDL_gamecontroller.c can now be dropped.
> - This gets us much closer to what's done on other platforms (Linux,
>   MacOS) to appropriately map a large number of gamecontrollers.
> - The solution is functional, though not yet 100% ideal in regards to
>   the creation and storage of the GUID, as it's stored as the string
>   which results in conversion to the numerical and then back to the
>   string. We will figure out the solution to this eventually, but I
>   don't think this should hold up the transition as the current
>   solution does not adversely affect performance.
> 
> More details in the original email.
> 
> Any of {testing,feedback,oks} would be appreciated.
> 
> > 
> > Background: On other platforms (Linux, MacOSX), SDL2 uses a GUID for
> > gamecontrollers combined with a database [1] to provide the default
> > button/axis mappings. This hasn't worked on OpenBSD (or apparently any
> > *BSD) and the SDL2 code resorts to simply converting the first 16 chars
> > of the device name to the GUID, which doesn't help with making use of
> > the gamecontrollerdb [2]. Therefore, the way we have been handling this
> > so far is that the env var SDL_GAMECONTROLLERCONFIG was available to
> > hold a mapping string [3]. This poses a significant barrier, as users
> > have to learn the syntax of the mapping strings and find one fitting
> > their controller by trial and error mostly.
> > 
> > This diff fixes the issue. To accomplish that, a couple of tasks are
> > added:
> > 
> > - Calculate and store the GUID (Credit goes to brynet@ for finding the
> >   GUID calculation and writing the initial proof-of-concept code).
> > - Remove the workaround code in SDL_gamecontroller.c that would either
> >   read the mapping from SDL_GAMECONTROLLERCONFIG if present, or
> >   otherwise default to the (commonly used) XBox 360 controller layout.
> > - Enable the mappings in SDL_gamecontrollerdb.h for OpenBSD.
> > - Assign buttons correctly - not in the order that they appear in the
> >   HID report, but based on their numbering in the HID report descriptor.
> > - Invert Y/Ry axes for the newer XInput-type gamecontrollers. This has
> >   been a particularly annoying problem, as USB standards recommend the
> >   positive directions to be left to right and far to near, but these
> >   controllers just use near-to-far as the positive direction. [4]
> > 
> > The problem with the last bullet point is that the Y/Ry axis inversion
> > needs to be applied *only* to the XInput devices, and *not* to the
> > older DInput devices. I can't check for XBox360 and other interface
> > subclasses (as used by the kernel in uhidev.c), as
> > USB_GET_INTERFACE_DESC is not exposed in the uhid(4) driver (see
> > uhid_do_ioctl() in uhid.c).
> > The solution I came up with is admittedly a (minor) hack. It turns out
> > that the old DInput devices report their axis values as an unsigned
> > 8bit integer, while the newer ones use a signed 16bit integer. With my
> > collection of gamecontrollers, checking if hitem.logical_maximum is
> > greater than 255 allows to reliably pick the correct handling of the
> > Y/Ry axes.
> > 
> > Other caveats:
> > 
> > - With the newly enabled GUID detection, SDL2 checks for a matching
> >   controller in gamecontrollerdb.txt in the application directory.
> >   I found that with one game (Cryptark), this contained bogus mappings
> >   for the XBox One controller (see the post on tech@), so some buttons
> >   and the Dpad didn't work until I removed that file.
> > - For some reason, the GUID for DInput devices matches the MACOSX
> >   entries in SDL_gamecontrollerdb.h, but the XInput devices match the
> >   LINUX entries. It's gonna take me a bit of time to get to the bottom
> >   of this; in the meantime just allowing both sets of GUID mappings
> >   works for the devices here on my testing
> > - The BSD_JoystickGetDeviceGUID() is not ideal at this point, as it
> >   takes the GUID stored as a string in char **joyguids and converts it
> >   into the raw 

Re: [NEW] graphics/libva and graphics/intel-vaapi-driver

[Bryan Steele]

On Thu, Dec 17, 2020 at 04:45:01PM +0100, Robert Nagy wrote:
> The upcoming chromium update also requires libva, so I've fixed up
> and updated the submitted libva port. Attached is the new version.

If it is blocking chromium updates now, perhaps libva should go in ports.
But if AMD graphics are ever to be supported it needs to go into xenocara
so that Mesa can be linked with it. I believe there are also some
additional patches required that need to be backported.

-Bryan.

Re: gnupg: avoid printf %n in build process

[Bryan Steele]

On Fri, Oct 16, 2020 at 09:54:25PM -0700, Greg Steuck wrote:
> I tried to get this upstreamed in https://dev.gnupg.org/T5104 to no
> avail. If people find it useful to not see %n related complaints during
> the build, the patch below would do it. If desirable, OK?
> 
> Thanks
> Greg

> >From 8afc030e5e22cdcde94437a8b2056ab4c6f16061 Mon Sep 17 00:00:00 2001
> From: Greg Steuck 
> Date: Wed, 14 Oct 2020 23:49:01 -0700
> Subject: [PATCH GnuPG] Avoid printf-%n in mkdefs.c
> 
> Replace with an easy computation.
> ---
>  doc/mkdefsinc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/mkdefsinc.c b/doc/mkdefsinc.c
> index b8fbed6e9..c8ff90fda 100644
> --- a/doc/mkdefsinc.c
> +++ b/doc/mkdefsinc.c
> @@ -268,6 +268,7 @@ main (int argc, char **argv)
>else
>  {
>const char *month = "?";
> +  const day_of_month = atoi (opt_date+8);
  ^

No comments about the diff, but shouldn't there be some type here?

clang complains.

warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

> ...

-Bryan.

Re: update games/barony - looking for help with cmake

[Bryan Steele]

On Sat, Oct 03, 2020 at 11:09:51PM +0200, Rafael Sadowski wrote:
> On Sat Oct 03, 2020 at 10:19:12PM +0200, Solene Rapenne wrote:
> > This diff updates barony to version 3.3.7 which
> > matches the version available on GOG for download
> > and should bring support for latest DLC that I don't
> > own so I didn't test.
> > 
> > I had to patch the thread library detection and rework the patch
> > on the CMake because the original file changed too much.
> > 
> > Rapidjson is now required, I added a new DISTFILE and an environment
> > variable to cmake to gives the path to the files.
> > 
> > I have one issue though that I made a really ugly fix to be able
> > to continue and check if the engine was working with the assets.
> > 
> > It seems cmake doesn't copy the "lang" directory at the build time
> > and fails during fake-target
> > 
> > ===>  Faking installation for barony-3.3.7
> > [0/1] cd /home/build/usr/ports/pobj/barony-3.3.7/build-amd64 && 
> > /usr/local/bin/cmake -P cmake_install.cmake
> > -- Install configuration: "Release"
> > -- Installing: 
> > /home/build/usr/ports/pobj/barony-3.3.7/fake-amd64/usr/local/bin/barony-bin
> > -- Installing: 
> > /home/build/usr/ports/pobj/barony-3.3.7/fake-amd64/usr/local/bin/barony-editor
> > CMake Error at cmake_install.cmake:89 (file):
> >   file INSTALL cannot find
> >   "/home/build/usr/ports/pobj/barony-3.3.7/build-amd64/lang": No such file 
> > or
> >   directory.
> > 
> > FAILED: CMakeFiles/install.util 
> > cd /home/build/usr/ports/pobj/barony-3.3.7/build-amd64 && 
> > /usr/local/bin/cmake -P cmake_install.cmake
> > ninja: build stopped: subcommand failed.
> > *** Error 1 in . (/home/build/usr/ports/devel/cmake/cmake.port.mk:39 
> > 'do-install': @cd /home/build/usr/ports/pobj/barony-3.3.7/build-amd64 &...)
> > *** Error 2 in . (/home/build/usr/ports/infrastructure/mk/bsd.port.mk:3005 
> > '/home/build/usr/ports/pobj/barony-3.3.7/fake-amd64/.fake_done')
> > *** Error 2 in . (/home/build/usr/ports/infrastructure/mk/bsd.port.mk:2116 
> > '/home/build/usr/ports/packages/amd64/all/barony-3.3.7.tgz': @cd ...)
> > *** Error 2 in . (/home/build/usr/ports/infrastructure/mk/bsd.port.mk:2605 
> > '_internal-package': @case X${_DEPENDS_CACHE} in  X) _DEPENDS_CAC...)
> > *** Error 2 in . (/home/build/usr/ports/infrastructure/mk/bsd.port.mk:2584 
> > 'package': @:; cd /usr/ports/games/barony && PKGPATH=games/barony...)
> > *** Error 2 in . (/home/build/usr/ports/infrastructure/mk/bsd.port.mk:2137 
> > '/var/db/pkg/barony-3.3.7/+CONTENTS': @cd /usr/ports/games/barony...)
> > *** Error 2 in /usr/ports/games/barony 
> > (/home/build/usr/ports/infrastructure/mk/bsd.port.mk:2584 'install': 
> > @lock=barony-3.3.7;  export _LOC...)
> > 
> > 
> > My fix is the following, I don't know how to fix this in Cmake or
> > if it's okay enough to commit with this:
> 
> You can change "${CMAKE_CURRENT_BINARY_DIR}/lang" to
> ${CMAKE_CURRENT_SOURCE_DIR}/lang or simply lang (without
> ${CMAKE_CURRENT_BINARY_DIR}/"). Full diff below.

Tested this builds and works with the latest game data
from the Epic store version, thanks!

-Bryan.

> Index: Makefile
> ===
> RCS file: /cvs/ports/games/barony/Makefile,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 Makefile
> --- Makefile  18 Jun 2020 21:37:44 -  1.6
> +++ Makefile  3 Oct 2020 21:08:18 -
> @@ -1,6 +1,6 @@
>  # $OpenBSD: Makefile,v 1.6 2020/06/18 21:37:44 solene Exp $
>  
> -V =  3.2.3
> +V =  3.3.7
>  COMMENT =3D, first person roguelike
>  PKGNAME =${DISTNAME:L}
>  CATEGORIES = games x11
> @@ -15,6 +15,11 @@ MAINTAINER =   David Carlier   # GPLv3 only
>  PERMIT_PACKAGE = Yes
>  
> +RAPIDJSON_V =1.1.0
> +MASTER_SITES0 =  https://github.com/Tencent/rapidjson/archive/
> +DISTFILES += Barony-${V}.tar.gz \
> + rapidjson-{}v${RAPIDJSON_V}.tar.gz:0
> +
>  WANTLIB += ${COMPILER_LIBCXX} GL GLU SDL2 SDL2_image SDL2_net
>  WANTLIB += SDL2_ttf c execinfo m ogg openal png vorbisfile physfs
>  
> @@ -33,6 +38,7 @@ LIB_DEPENDS =   audio/libvorbis \
>   devel/sdl2-ttf \
>   graphics/png
>  
> +CONFIGURE_ENV =  
> RAPID_JSONROOT="${WRKDIR}/rapidjson-${RAPIDJSON_V}/"
>  CONFIGURE_ARGS = -DCMAKE_C_FLAGS="${CFLAGS}" \
>   -DCMAKE_CXX_FLAGS="${CXXFLAGS}" \
>   -DOPENAL_ENABLED=ON \
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/barony/distinfo,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 distinfo
> --- distinfo  18 Jun 2020 21:37:44 -  1.3
> +++ distinfo  3 Oct 2020 21:08:18 -
> @@ -1,2 +1,4 @@
> -SHA256 (Barony-3.2.3.tar.gz) = M0tAqqGtVXFQaBWqYBpw1B5L1EqnBqp52MIeChIlwm8=
> -SIZE (Barony-3.2.3.tar.gz) = 53508615
> +SHA256 (Barony-3.3.7.tar.gz) = oLiULiaeja/MQhcykryxvUrNHC3TXVtIOgpgWe8ne7M=
> +SHA256 

Re: VAAPI ports

[Bryan Steele]

On Sat, Aug 22, 2020 at 07:35:47PM +0200, Luca De Pandis wrote:
> Hi everyone,
> I'm Luca De Pandis and I'm an OpenBSD user since March.
> 
> I'd like to contribute to the project since I'm using it everyday, so I
> decided to work on porting the VAAPI stack on OpenBSD.
> 
> Before submitting I checked with portcheck and make
> ports-lib-depends-check for errors or things I could improve to make the
> ports as compliant as possible. Still, as they are my first attempt to
> port something I'd like to receive your feedbacks about them.
> 
> Since I need for VAAPI to get hw acceleration on mpv I wouldn't mind to
> step up as a maintainer for these ports.
> 
> Also, I wrote some patches, but I'm not as proficient in C as I would. So
> I'm counting on your feedbacks if there are some things I could do
> better in that regard as well.
> 
> 
> Best regards,
> Luca De Pandis

Hi Luca,

This has come up before last year [0], and the conclusion was that this
needed to be a part of xenocara [1] as Mesa needs to be compiled with
'--enable-va' to have working r600/radeonsi gallium drivers [2].

The original work was done by Brad DeMorrow and Jonathan Gray had
picked it up after that, not sure what the status is now. I had it
working on my Radeon HD 7450 along with a modified ffmpeg port with
Brad's original ports and recompiled Mesa.

Having support for video encode/decode offloading would be nice,
especially on lower power CPUs.

-Bryan.

[0] https://marc.info/?l=openbsd-ports=157626463822587=2
[1] https://marc.info/?l=openbsd-tech=157676527322944=2
[2] https://marc.info/?l=openbsd-ports=157638698722892=2

Re: games/godot: add libao to make audio functional

[Bryan Steele]

On Tue, Aug 04, 2020 at 07:39:30PM +0200, Omar Polo wrote:
> 
> Christian Weisgerber  writes:
> 
> > Omar Polo:
> >
> >> The following patch is to make audio working on games/godot via libao.
> >>
> >> Six years ago, Anton Yabchinskiy added a libao driver[0] to have audio
> >> working on OpenBSD, but a year later[1] that code was removed. (n.b.:
> >> all of this was pre godot 2.0)
> >
> > Frankly, if you are adding an audio module that upstream doesn't
> > have, it would make more sense to support sndio directly rather
> > than going through libao.  That's just an extra layer.
> 
> That was my first thought too, but after I while I gave up and gone the
> libao route.  I mean, adapting that old driver to work with new version
> was, like, 10-15 minutes of work?  Then I got the audio working and I
> was happy, and I've simply ignored the bloat.
> 
> However, I've reconsider that.  Using the libao driver as example I
> managed to build an sndio driver that works.  (that's the reason of the
> delay in this reply.)  Kudos to who worked on sndio, the documentation
> is fantastic and was a pleasure to read.  The new driver should also be
> more reliable than this libao hack.
> 
> So, yeah, thanks for your comment, it convinced me to give it another
> try and consider this patch retired.  I'll need another week or so to
> find the time to complete the driver and I'll send another patch,
> probably with or slightly after the incoming 3.2.3 update.

This is great news, Omar!

For those curious, *.pck files can be loaded with the '--main-pack'
argument for godot which avoids starting the editor/project manager.
This seems to be how some, but not all, released games are packaged
Godot. A few of us tested some freely available games, like Hive Time
and Oddventure.

Proper sound support was a huge missing peice, glad to see someone
working on a sndio backend for this one!

-Bryan.

Re: Clang 10 FIX: games/devilutionx

[Bryan Steele]

On Fri, Jul 31, 2020 at 02:09:53PM +, Brian Callahan wrote:
> Hi ports --
> 
> As reported by naddy@, games/devilutionx doesn't build with clang-10.
> The problem is that our ar doesn't understand archives with LLVM thin
> LTO objects in it (devilutionx turns -flto=thin on by default if you
> have a newer toolchain).
> 
> The solution is to disable LTO, which makes things build and run fine.
> 
> While here, add a patch to silence a bunch of warnings about
> redefining __va_list.
> 
> OK?

It probably shouldn't have been enabling LTO automatically in the
first place, so it seems like a good thing to fix regardless of
mysterious clang10 rumblings.

Comments inline.

> ~Brian

> Index: Makefile
> ===
> RCS file: /cvs/ports/games/devilutionx/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- Makefile  16 Mar 2020 23:50:28 -  1.6
> +++ Makefile  31 Jul 2020 14:05:16 -
> @@ -2,6 +2,7 @@
>  
>  COMMENT =open source engine recreation for Diablo 1 game
>  PKGNAME =${DISTNAME:L}
> +REVISION =   0
>  CATEGORIES = games x11
>  
>  GH_ACCOUNT = diasurgical
> @@ -37,7 +38,8 @@ NO_TEST =   Yes
>  
>  # Remove DOS line endings from patched files
>  post-extract:
> - @cd ${WRKSRC} && perl -i -pe 's/\r$$//' CMakeLists.txt
> + @cd ${WRKSRC} && perl -i -pe 's/\r$$//' CMakeLists.txt \
> + SourceS/macos_stdarg.h
>  
>  # No install target
>  do-install:
> Index: patches/patch-CMakeLists_txt
> ===
> RCS file: /cvs/ports/games/devilutionx/patches/patch-CMakeLists_txt,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-CMakeLists_txt
> --- patches/patch-CMakeLists_txt  16 Mar 2020 23:50:28 -  1.5
> +++ patches/patch-CMakeLists_txt  31 Jul 2020 14:05:16 -
> @@ -1,10 +1,20 @@
>  $OpenBSD: patch-CMakeLists_txt,v 1.5 2020/03/16 23:50:28 bcallah Exp $
>  
> +-DLTO=OFF on the command line doesn't catch.
>  Don't do git here.
>  
>  Index: CMakeLists.txt
>  --- CMakeLists.txt.orig
>  +++ CMakeLists.txt
> +@@ -25,7 +25,7 @@ if(BINARY_RELEASE)
> +   set(ASAN OFF)
> +   set(UBSAN OFF)
> +   set(DEBUG OFF)
> +-  set(LTO ON)
> ++  set(LTO Off)

Should this be "OFF" capitalized to match the rest? Also there's already
a section for OpenBSD overrides cmake options like ASAN/UBSAN. I suppose
it doesn't matter much.

> +   set(DIST ON)
> +   set(FASTER OFF)
> + endif()
>  @@ -40,14 +40,8 @@ if(NIGHTLY_BUILD)
> set(FASTER OFF)
>   endif()
> Index: patches/patch-SourceS_macos_stdarg_h
> ===
> RCS file: patches/patch-SourceS_macos_stdarg_h
> diff -N patches/patch-SourceS_macos_stdarg_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-SourceS_macos_stdarg_h  31 Jul 2020 14:05:16 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +
> +We don't need this.
> +
> +Index: SourceS/macos_stdarg.h
> +--- SourceS/macos_stdarg.h.orig
>  SourceS/macos_stdarg.h
> +@@ -1,9 +1,11 @@
> + #ifndef __STDARG_H
> + #define __STDARG_H
> + 
> ++#if 0
> + typedef __builtin_va_list va_list;
> + #define _VA_LIST_T
> + #define va_start(ap, param) __builtin_va_start(ap, param)
> + #define va_end(ap) __builtin_va_end(ap)
> ++#endif
> + 
> + #endif /* __STDARG_H */

If we don't need this anymore, then we should remove the check in
SourceS/miniwin.h instead, seems it was working around a bug.

// work around https://reviews.llvm.org/D51265^M
#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__)
#include "macos_stdarg.h"
#else
#include 
#endif

It doesn't appear to be needed with clang-8.0.1 either, *shrug*.

ok brynet@ with those changes.

-Bryan.

Re: NEW: x11/picom

[Bryan Steele]

On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
> 
> Hi,
> 
> This is a port for picom, a compositor for X11.  It's an actively
> developed fork of compton.
> 
> I've been running for a month now, and it has been rock stable (instead
> of compton which would occasionally crash.)
> 
> Build and tested on amd64, passes port-lib-depends-check and portcheck.
> 
> A couple of notes about the patches:
> 
> - (AFAIK) the project was recently renamed from "compton" to "picom",
>   that's the reason they install some files that can conflict   with
>   x11/compton (like the bin/compton{,-trans} links to
>   bin/picom{,-trans}).  I've removed (and/or renamed) them to   avoid the
>   conflict, since I wanted to have them both installed   side-by-side
> 
> - moved the manpage from the (port) default share/man/man1 to
>   man/man1
> 
> - the patch-src_meson_build is an hack to avoid a meson error I cannot
>   understand
> 
> Cheers!
> 

I can't comment on the port itself, but picom looks like it needs
a similar fix for vsync as compton in ports does to use the correct
drm(4) device node.

-Bryan.

diff --git src/vsync.c src/vsync.c
index 5980155..8273d28 100644
--- src/vsync.c
+++ src/vsync.c
@@ -54,7 +54,7 @@ static int vsync_drm_wait(session_t *ps) {
  */
 static bool vsync_drm_init(session_t *ps) {
// Should we always open card0?
-   if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0", O_RDWR)) < 
0) {
+   if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0", O_RDWR)) < 0) {
log_error("Failed to open device.");
return false;
}

Re: should we port ssh-copy-id ?

[Bryan Steele]

On Sat, Jan 18, 2020 at 10:14:57AM +0100, Jan-Piet Mens wrote:
> > I assume a better distfile would be OpenSSH portable tarballs.
> 
> It occurred to me, but I assumed the original source repository of the
> script would be the cleaner method.
> 
> > ./openssh-8.0p1/contrib/ssh-copy-id
> 
> Would there be a reason for using 8.0p1 instead of 8.1p1 ?

No, I just downloaded the wrong tarball. :-)

>   -JP
> 
> 

Re: should we port ssh-copy-id ?

[Bryan Steele]

On Fri, Jan 17, 2020 at 02:33:09PM +, Stuart Henderson wrote:
> On 2020/01/17 14:55, Jan-Piet Mens wrote:
> > > Seems reasonable - is there a stable distfile somewhere or does it
> > > need mirroring?
> > 
> > I'm aware only of the git repository at [1], in other words, I assume if we
> > need a .tar.gz it needs mirroring. Is there provision at ports@ to do that
> > or do I try to create the port to pull a specific git tag from [1]?
> > 
> > -JP
> > 
> > [1] http://git.hands.com/ssh-copy-id
> > 
> 
> tar.gz files generated by gitweb are subject to change so we try to avoid 
> using
> them directly.
> 
> I've just mirrored it at https://spacehopper.org/ssh-copy-id-20161215.tar.gz,
> the port Makefile will need WRKDIST=${WRKDIR}/ssh-copy-id-b32a55c

>From the discussion on Twitter, djm@ said [0] the ssh-copy-id script has
been distributed with OpenSSH portable, in the contribs directory. It
is not installed by the Makefile, this is done by Linux distributions.

I assume a better distfile would be OpenSSH portable tarballs. At least
that will be what is on other systems (Except FreeBSD). We're already
widely mirroring it.

https://www.openssh.com/portable.html

./openssh-8.0p1/contrib/ssh-copy-id
./openssh-8.0p1/contrib/ssh-copy-id.1


[0] https://twitter.com/damienmiller/status/1216835366604328960

Re: [NEW] VA-API for OpenBSD

[Bryan Steele]

On Sun, Dec 15, 2019 at 12:14:33AM -0500, Bryan Steele wrote:
> I did a dirty, awful thing. For r600/radeonsi gallium drivers it seems
> neccessary to compile Mesa with --enable-va for this to work. That said,
> it seems that installing the shared libraries from this build is
> enough to make the vainfo utility happy. I haven't seen if this
> actualy works with ffmpeg at all.

It works!

The original ffmpeg diff Brad DeMorrow sent earlier was incomplete,
with this patch to his updated port. Diff attached.

ffmpeg version 4.2.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on 
LLVM 8.0.1)
  configuration: --enable-shared --arch=amd64 --cc=cc --disable-altivec 
--disable-debug --disable-indev=jack --disable-indev=oss --disable-mipsdsp 
--disable-mipsdspr2 --disable-mipsfpu --disable-mmi --disable-msa 
--disable-outdev=oss --disable-outdev=sdl2 --enable-avresample 
--enable-fontconfig --enable-frei0r --enable-gpl --enable-libaom 
--enable-libass --enable-libdav1d --enable-libfreetype --enable-libfribidi 
--enable-libgsm --enable-libmp3lame --enable-libopus --enable-libspeex 
--enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx 
--enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid 
--enable-nonfree --enable-openssl --enable-vaapi 
--extra-cflags='-I/usr/local/include -I/usr/X11R6/include' 
--extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' --extra-ldsoflags= 
--mandir=/usr/local/man --optflags='-O2 -pipe -Wno-redundant-decls'
  libavutil  56. 31.100 / 56. 31.100
  libavcodec 58. 54.100 / 58. 54.100
  libavformat58. 29.100 / 58. 29.100
  libavdevice58.  8.100 / 58.  8.100
  libavfilter 7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale  5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc55.  5.100 / 55.  5.100
[AVHWDeviceContext @ 0x1a72a575f940] libva: VA-API version 1.6.0
[AVHWDeviceContext @ 0x1a72a575f940] libva: va_getDriverName() returns 0
[AVHWDeviceContext @ 0x1a72a575f940] libva: Trying to open 
/usr/local/lib/dri/r600_drv_video.so
[AVHWDeviceContext @ 0x1a72a575f940] libva: Found init function 
__vaDriverInit_1_0
[AVHWDeviceContext @ 0x1a72a575f940] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x1a72a575f940] Initialised VAAPI connection: version 1.6
[AVHWDeviceContext @ 0x1a72a575f940] VAAPI driver: Mesa Gallium driver 19.0.8 
for AMD CAICOS (DRM 2.50.0 / 6.6, LLVM 8.0.1).
[AVHWDeviceContext @ 0x1a72a575f940] Driver not found in known nonstandard 
list, using standard behaviour.
[h264 @ 0x1a72c8da9000] Reinit context to 768x1088, pix_fmt: yuv420p
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'openbsd-sixdotsix.mp4':
  Metadata:
major_brand : mp42
minor_version   : 1
compatible_brands: mp41mp42isom
creation_time   : 2019-10-12T10:33:50.00Z
  Duration: 00:00:29.87, start: 0.00, bitrate: 1666 kb/s
Stream #0:0(und): Video: h264 (High), 1 reference frame (avc1 / 
0x31637661), yuv420p(tv, bt709, left), 754x1080 (768x1088), 1660 kb/s, 30 fps, 
30 tbr, 600 tbn, 1200 tbc (default)
Metadata:
  creation_time   : 2019-10-12T10:33:50.00Z
  handler_name: Core Media Video
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
[h264 @ 0x1a731863f800] Reinit context to 768x1088, pix_fmt: vaapi_vld
[graph 0 input from stream 0:0 @ 0x1a73156e7100] w:754 h:1080 pixfmt:vaapi_vld 
tb:1/600 fr:30/1 sar:0/1 sws_param:flags=2
Output #0, null, to 'pipe:':
  Metadata:
major_brand : mp42
minor_version   : 1
compatible_brands: mp41mp42isom
encoder : Lavf58.29.100
Stream #0:0(und): Video: wrapped_avframe, 1 reference frame, 
vaapi_vld(left), 754x1080, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default)
Metadata:
  creation_time   : 2019-10-12T10:33:50.00Z
  handler_name: Core Media Video
  encoder : Lavc58.54.100 wrapped_avframe
No more output streams to write to, finishing.:28.90 bitrate=N/A speed=5.74x
frame=  896 fps=173 q=-0.0 Lsize=N/A time=00:00:29.86 bitrate=N/A speed=5.78x   
 
video:469kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
Input file #0 (openbsd-sixdotsix.mp4):
  Input stream #0:0 (video): 897 packets read (6207755 bytes); 896 frames 
decoded; 
  Total: 897 packets (6207755 bytes) demuxed
Output file #0 (pipe:):
s); 
  Total: 896 packets (480256 bytes) muxed
[AVIOContext @ 0x1a731ff5b000] Statistics: 6254355 bytes read, 2 seeks

--- graphics/ffmpeg/MakefileSun Dec 15 01:53:55 2019
+++ graphics/ffmpeg/MakefileSun Dec 15 01:25:13 2019
@@ -63,12 +63,12 @@
textproc/libxml
 
 # inter-library dependencies for the current configuration
-LIBavcodec_EXTRALIBS=-L${LOCALBASE}/lib -laom -ldav1d -lgsm -liconv -llzma 
-lmp3lame -lopus -lspeex -ltheoradec -ltheoraenc -lvorbis -lvo

Re: [NEW] VA-API for OpenBSD

[Bryan Steele]

I did a dirty, awful thing. For r600/radeonsi gallium drivers it seems
neccessary to compile Mesa with --enable-va for this to work. That said,
it seems that installing the shared libraries from this build is
enough to make the vainfo utility happy. I haven't seen if this
actualy works with ffmpeg at all.

$ vainfo  
libva info: VA-API version 1.6.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.6 (libva 2.6.0.1)
vainfo: Driver version: Mesa Gallium driver 19.0.8 for AMD CAICOS (DRM
2.50.0 / 6.6, LLVM 8.0.1)
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc

On Linux, {r600,radeonsi,}_drv_video.so are symlinks to
gallium_drv_video.so.

Here's the awful patch that edits the pre-generated configure file,
because the xenocara build system purposefully prevents pkg-config
from searching /usr/local. There's some weirdness as well related
to VA_MAJOR/VA_MINOR, as vainfo complains if they match the installed
library so 0.0. It wants __vaDriverInit_1_0 and not __vaDriverInit_0_0.

$ cvs -qd $CVSROOT checkout -P xenocara/lib/mesa
$ cd xenocara/lib/mesa
$ patch -p0 < patch
$ make -f Makefile.bsd-wrapper -j $(sysctl -n hw.ncpuonline)
$ doas cp ./src/gallium/targets/va/.libs/gallium_drv_video.so
/usr/local/lib/dri/r600_drv_video.so
$ doas cp ./src/gallium/targets/va/.libs/gallium_drv_video.so
/usr/local/lib/dri/radeonsi_drv_video.so

Index: Makefile.bsd-wrapper
===
RCS file: /cvs/xenocara/lib/mesa/Makefile.bsd-wrapper,v
retrieving revision 1.28
diff -u -r1.28 Makefile.bsd-wrapper
--- xenocara/lib/mesa/Makefile.bsd-wrapper  28 Aug 2019 08:01:48 -  
1.28
+++ xenocara/lib/mesa/Makefile.bsd-wrapper  15 Dec 2019 04:45:56 -
@@ -41,6 +41,7 @@
--enable-gles1 --enable-gles2 \
--enable-shared-glapi \
--enable-osmesa \
+   --enable-va \
--enable-gbm \
--enable-texture-float \
--enable-autotools \
Index: configure
===
RCS file: /cvs/xenocara/lib/mesa/configure,v
retrieving revision 1.25
diff -u -r1.25 configure
--- xenocara/lib/mesa/configure 7 Dec 2019 03:10:09 -   1.25
+++ xenocara/lib/mesa/configure 15 Dec 2019 04:45:58 -
@@ -14,6 +14,9 @@
 ## M4sh Initialization. ##
 ##  ##
 
+export VA_CFLAGS="-I/usr/local/include"
+export VA_LIBS="-L/usr/local/lib -lva"
+
 # Be more Bourne compatible
 DUALCASE=1; export DUALCASE # for MKS sh
 if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :
@@ -29815,8 +29818,10 @@
 
 
 if test "x$enable_va" = xyes; then
-VA_MAJOR=`$PKG_CONFIG --modversion libva | $SED -n 
's/\([^\.]*\)\..*$/\1/p'`
-VA_MINOR=`$PKG_CONFIG --modversion libva | $SED -n 
's/.*\.\(.*\)\..*$/\1/p'`
+#VA_MAJOR=`$PKG_CONFIG --modversion libva | $SED -n 
's/\([^\.]*\)\..*$/\1/p'`
+VA_MAJOR=1
+#VA_MINOR=`$PKG_CONFIG --modversion libva | $SED -n 
's/.*\.\(.*\)\..*$/\1/p'`
+VA_MINOR=0
 fi
 VA_MAJOR=$VA_MAJOR
 

On Sat, Dec 14, 2019 at 08:27:41AM -0600, Brad DeMorrow wrote:
> Thank you both again for the explanation.  That makes sense now.
> I've updated the libva Makefile to simply use 0.0 as the SHARED_LIBS
> versions
> and I've removed the post-install hook that adds additional symlinks for no
> good reason.
> 
> I added patches to remove the explicit shared library versions from the
> dlopen calls in the
> intel-vaapi-driver port and it now works as expected without the symlinks.
> I looked through
> the other ports for hard-coded dlopen calls as well, but found no more.
> 
> libva-utils had an extra binary being installed called test_va_api as a
> result of building the test suite.
> I added a post-install hook to remove this binary before it's packaged.  I
> hope that's the correct approach.
> 
> Please find the updated tarballs attached with all of the changes we've
> discussed thus far.
> 
> Thank you again for helping me test this and get it all straightened out.
> 
> 
> On Sat, Dec 14, 2019 at 1:55 AM Vadim Zhukov  wrote:
> 
> > сб, 14 дек. 2019 г. в 10:27, Brad DeMorrow :
> > >
> > > On Sat, Dec 14, 2019 at 1:16 AM Vadim Zhukov  wrote:
> > >>
> > >> сб, 14 дек. 2019 г. в 08:25, 

Re: [NEW] graphics/libva and graphics/intel-vaapi-driver

[Bryan Steele]

On Mon, Dec 09, 2019 at 11:28:57AM -0600, Brad DeMorrow wrote:
> Bryan,
> I've attached the full output of *moonlight > moonlight.log 2>&1*
> 
> There are no errors that I see, however, I do see a behavior that's probably
> not intended.
> The original code used the RTLD_NODELETE flag with dlopen to basically
> cause the library to stay in memory when dlcose is called.  It doesn't
> appear
> to affect the application, but you can see it open the intel-vaapi-driver on
> 6 different occasions before it is finally settled down.
> 
> We don't seem to support RTLD_NODELETE, so I opted to remove this flag
> since their code also supported operation without it on the ANDROID
> platform.
> 
> Like I said, operationally speaking - it appears to work without errors,
> but if
> anyone has any ideas about what to do with the RTLD_NODELETE flag, let
> me know please.

Sorry I can't comment on the dlopen or moonlight aspects of this port,
or comments on the port itself, but that is interesting to hear!

I assume CPU utilization drops with ffmpeg? That might be interesting to
compare, before and after. But indeed, from this log it appears to be
working as intended.

Having this working in ffmpeg would benefit many applications.

> On Mon, Dec 9, 2019 at 10:51 AM Brad DeMorrow  wrote:
> 
> >
> >> I was under the impression that in order to have working VAAPI/VDPAU
> >> accelleration we had to compile Mesa with it (which been a problem, as
> >> our Mesa is in maintained in base).
> >>
> > I wasn't aware of that (potential?) problem.
> >
> >
> >>
> >> IIRC libvaapi does compile, but fails at runtime without the Mesa
> >> components. Is this not accurate?
> >>
> >> I can scour the output from a quick gaming session and report back with
> > more details, but here is what my experience has been:
> >
> > 1. I built libva and intel-vaapi-driver because I knew that moonlight-qt
> > needed it.
> > 2. Once I built moonlight-qt and ran it, I realized that it was using
> > ffmpeg to
> > do the actual decoding, which wasn't built with vaapi support.  Upon
> > starting it, you get a warning message that it couldn't enable hardware
> > accelerated h264 decoding.
> > 3. I rebuilt ffmpeg with --enable-vaapi.
> > 4. moonlight-qt seemed perfectly content afterwards, and if there were any
> > errors/exceptions, they are hidden away in logs.  The gaming experience
> > was perfectly acceptable.  I spent a good 10-15 minutes playing
> > Borderlands 3 to test it out.
> >
> > So, again, I will collect the full output and attach to a follow-up email.
> >
> > --
> > --Brad DeMorrow
> >
> 
> 
> -- 
> --Brad DeMorrow

> 00:00:00 - SDL Info (0): Compiled with SDL 2.0.10
> 00:00:00 - SDL Info (0): Running with SDL 2.0.10
> 00:00:00 - Qt Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/tmp/runtime-brad'
> 00:00:00 - Qt Warning: JIT is disabled for QML. Property bindings and 
> animations will be very slow. Visit https://wiki.qt.io/V4 to learn about 
> possible solutions for your platform.
> 00:00:00 - Qt Info: Found "gamecontrollerdb.txt" at 
> ":/data/gamecontrollerdb.txt"
> 00:00:00 - SDL Info (0): Loaded 279 new gamepad mappings
> 00:00:01 - SDL Info (0): V-sync enabled
> libva info: VA-API version 1.6.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
> libva info: Found init function __vaDriverInit_1_6
> libva info: va_openDriver() returns 0
> 00:00:01 - SDL Info (0): Initialized VAAPI 1.6
> 00:00:01 - SDL Info (0): Driver: Intel i965 driver for Intel(R) Kaby Lake - 
> 2.4.0
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x32315659 -> 
> yuv420p.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x30323449 -> 
> yuv420p.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x3231564e -> 
> nv12.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x32595559 -> 
> yuyv422.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x59565955 -> 
> uyvy422.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x48323234 -> 
> yuv422p.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x58424752 -> 
> rgb0.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x58524742 -> 
> bgr0.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Format 0x30313050 -> 
> p010le.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] VAAPI driver: Intel 
> i965 driver for Intel(R) Kaby Lake - 2.4.0.
> 00:00:01 - FFmpeg: [AVHWDeviceContext @ 0xc003488740] Driver not found in 
> known nonstandard list, using standard behaviour.
> 00:00:01 - SDL Info (0): Using VAAPI accelerated renderer on x11
> 00:00:01 - FFmpeg: [h264 @ 0xbf8e0f4800] nal_unit_type: 7(SPS), nal_ref_idc: 3
> 00:00:01 - FFmpeg: [h264 @ 0xbf8e0f4800] nal_unit_type: 8(PPS), nal_ref_idc: 3
> 00:00:01 - FFmpeg: [h264 @ 0xbf8e0f4800] nal_unit_type: 5(IDR), nal_ref_idc: 3
> 00:00:01 - FFmpeg: [h264 @ 0xbf8e0f4800] 

Re: [NEW] graphics/libva and graphics/intel-vaapi-driver

[Bryan Steele]

On Mon, Dec 09, 2019 at 12:42:45AM -0600, Brad DeMorrow wrote:
> I managed to get moonlight-qt (to stream games) to work today.
> I'm trying to bundle up my work, but I need some help/feedback on a few
> things.
> 
> First, here is libva and the intel-vaapi-driver.
> I've ran portcheck and done several clean/build cycles and it works on my
> box,
> but I'm still pretty new to porting - so it's probably not perfect.
> 
> Both required very minimal patching to get them to compile.  I will try
> to upstream these patches in a better way, but they are in the tree for the
> moment.
> 
> Beyond these two, I have attached a small update to the graphics/ffmpeg
> Makefile
> that simply enables VAAPI and allows hardware-accelerated H264 decoding from
> moonlight-qt. I was able to stream games on my local network at 60FPS@1080p
> without a problem.
> 
> Now for the big question/problem:
> moonlight-qt requires a `git submodule update --init --recursive` before
> the build, but
> I'm pretty sure that's not how we do things here.  How is this normally
> handled?
> Do I need to repack everything and host it on my own github account?
> 
> Feedback appreciated.

I was under the impression that in order to have working VAAPI/VDPAU
accelleration we had to compile Mesa with it (which been a problem, as
our Mesa is in maintained in base).

IIRC libvaapi does compile, but fails at runtime without the Mesa
components. Is this not accurate?

-Bryan.

gimp 2.10.12 SIGSEGV on image export (gdk-pixbuf?)

[Bryan Steele]

It's only semi-reproducible, if you create a screenshot from within gimp
and then click "Export As..."

Thanks to sthen@ for explaining how to use the new debug- packages.

-Bryan.

(gdb backtrace)

Thread 1 received signal SIGSEGV, Segmentation fault.
0x1d28c1e569f1 in compute_hint (pixbuf=, 
x0=, x1=24, y0=31, y1=32) at pixbuf-render.c:606
606 pixbuf-render.c: No such file or directory.
(gdb) bt
#0  0x1d28c1e569f1 in compute_hint (pixbuf=, 
x0=, x1=24, y0=31, y1=32) at pixbuf-render.c:606
#1  theme_pixbuf_compute_hints (theme_pb=)
at pixbuf-render.c:696
#2  0x1d28c1e56d76 in theme_pixbuf_get_pixbuf (theme_pb=0x1d285c7dcb80)
at pixbuf-render.c:759
#3  theme_pixbuf_render (theme_pb=0x1d285c7dcb80, window=0x1d286fa727e0, 
mask=0x0, clip_rect=0x1d283bc37924, component_mask=512, center=0, x=10, 
y=577, width=148, height=26) at pixbuf-render.c:777
#4  0x1d28c1e55fcd in draw_simple_image (style=, 
window=0x1d286fa727e0, area=0x1d283bc37924, widget=, 
match_data=, draw_center=1, allow_setbg=, 
x=10, y=577, width=882012157, height=23) at pixbuf-draw.c:145
#5  0x1d28c1e54e88 in draw_box (style=0x1d28c310a830,
window=0x1d286fa727e0, state=GTK_STATE_NORMAL, shadow=GTK_SHADOW_NONE, 
area=0x1d283bc37924, widget=0x1d286fa72730, 
detail=0x1d28a7a9744c "toolbar", x=10, y=577, width=148, height=26)
at pixbuf-draw.c:668
#6  0x1d28a7d2979c in IA__gtk_paint_box (style=0x1d28c310a830, 
window=0x1d286fa727e0, state_type=GTK_STATE_NORMAL, 
shadow_type=GTK_SHADOW_NONE, area=0x1d283bc37924, widget=0x1d286fa72730, 
detail=0x1d28a7a9744c "toolbar", x=10, y=577, width=148, height=26)
at gtkstyle.c:6207
#7  0x1d28a7d8547b in gtk_toolbar_expose (widget=0x1d286fa72730, 
event=0x1d283bc37910) at gtktoolbar.c:874
#8  0x1d28a7c92fbe in _gtk_marshal_BOOLEAN__BOXED (closure=0x1d28550ca4a0, 
return_value=0x7f7d7740, n_param_values=, 
param_values=0x7f7d7810, invocation_hint=, 
marshal_data=) at gtkmarshalers.c:84
#9  0x1d28a381ed57 in g_closure_invoke ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#10 0x1d28a3837f60 in ?? () from /usr/local/lib/libgobject-2.0.so.4200.10
#11 0x1d28a3838c30 in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#12 0x1d28a38392c1 in g_signal_emit ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#13 0x1d28a7deb5c7 in gtk_widget_event_internal (widget=0x1d286fa72730, 
event=0x1d283bc37910) at gtkwidget.c:5010
#14 0x1d28a7bf630c in IA__gtk_container_propagate_expose (
container=, child=0x1d286fa72730, event=0x1d283bc37cf0)
at gtkcontainer.c:2757
#15 0x1d28a7bbacfc in gtk_box_forall (container=0x1d28c918a8a0, 
include_internals=, 
callback=0x1d28a7bf7110 , 
callback_data=0x7f7d7b10) at gtkbox.c:1251
#16 0x1d28a7bf689d in IA__gtk_container_forall (container=,
callback=0x1f, callback_data=) at gtkcontainer.c:1507
#17 gtk_container_expose (widget=0x1d28c918a8a0, event=)
at gtkcontainer.c:2661
#18 0x1d28a7c92fbe in _gtk_marshal_BOOLEAN__BOXED (closure=0x1d28550ca4a0, 
return_value=0x7f7d7c20, n_param_values=, 
param_values=0x7f7d7cf0, invocation_hint=, 
marshal_data=) at gtkmarshalers.c:84
#19 0x1d28a381ed57 in g_closure_invoke ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#20 0x1d28a3837f60 in ?? () from /usr/local/lib/libgobject-2.0.so.4200.10
#21 0x1d28a3838c30 in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#22 0x1d28a38392c1 in g_signal_emit ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#23 0x1d28a7deb5c7 in gtk_widget_event_internal (widget=0x1d28c918a8a0, 
event=0x1d283bc37cf0) at gtkwidget.c:5010
#24 0x1d28a7bf630c in IA__gtk_container_propagate_expose (
container=, child=0x1d28c918a8a0, event=0x1d283bc37ad0)
at gtkcontainer.c:2757
#25 0x1d28a7cc7db9 in gtk_paned_forall (container=0x1d28b90cd480, 
include_internals=, 
callback=0x1d28a7bf7110 , 
callback_data=0x7f7d7fe0) at gtkpaned.c:1462
#26 0x1d28a7bf689d in IA__gtk_container_forall (container=, 
callback=0x1f, callback_data=) at gtkcontainer.c:1507
#27 gtk_container_expose (widget=0x1d28b90cd480, event=)
at gtkcontainer.c:2661
#28 0x1d28a7cc7796 in gtk_paned_expose (widget=0x1d28b90cd480, 
event=0x1d283bc37ad0) at gtkpaned.c:1095
#29 0x1d28a7c92fbe in _gtk_marshal_BOOLEAN__BOXED (closure=0x1d28550ca4a0, 
return_value=0x7f7d8130, n_param_values=, 
param_values=0x7f7d8200, invocation_hint=, 
marshal_data=) at gtkmarshalers.c:84
#30 0x1d28a381ed57 in g_closure_invoke ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#31 0x1d28a3837f60 in ?? () from /usr/local/lib/libgobject-2.0.so.4200.10
#32 0x1d28a3838c30 in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.4200.10
#33 0x1d28a38392c1 in g_signal_emit ()
   from 

Re: UPDATE: games/devilutionx to 0.5.0+

[Bryan Steele]

On Sat, Nov 09, 2019 at 04:16:22PM -0500, Bryan Steele wrote:
> On Sat, Nov 09, 2019 at 12:16:24PM -0500, Brian Callahan wrote:
> > 
> > 
> > On 2019-11-09 12:12 PM, Brian Callahan wrote:
> > > Hi ports --
> > > 
> > > Attached is an update to games/devilutionx. The latest release is 0.5.0
> > > but this update is a good bit past that point. Primarily because brynet@
> > > did a lot of work upstreaming all patches but that came after the 0.5.0
> > > release and I think it makes more sense to remove all our local patches
> > > than cherry pick his improvements (creating more patches...).
> > > 
> > > Really, all this work is brynet@'s; I just get to be the one who swoops
> > > in with the port update.
> > > 
> > > Works well here.
> > > 
> > > OK?
> > > 
> > > ~Brian
> > > 
> > 
> > I should add too that upstream's CMake stuff generates compiler lines that
> > neither ninja, samurai, nor our make understand so I fell back to gmake to
> > build.
> 
> Yeah, I was using gmake directly too, but per upstream wanting to use
> cmake --build, I had to find the magical invocation:
> 
>   cmake -DCMAKE_MAKE_PROGRAM=gmake ..
> 
> For the port, I think this can be added to CONFIGURE_ARGS?
> 
> Either way, it's OK brynet@ :-)
> 
> -Bryan.

Heads up though, as this is an active RE project, you may lose savegames
going forward.. you could try reporting it upstream and they might be
able to help you salvage them, but be prepared to have to start over.

But it's Diablo, so, torture is part of the game.

Re: UPDATE: games/devilutionx to 0.5.0+

[Bryan Steele]

On Sat, Nov 09, 2019 at 12:16:24PM -0500, Brian Callahan wrote:
> 
> 
> On 2019-11-09 12:12 PM, Brian Callahan wrote:
> > Hi ports --
> > 
> > Attached is an update to games/devilutionx. The latest release is 0.5.0
> > but this update is a good bit past that point. Primarily because brynet@
> > did a lot of work upstreaming all patches but that came after the 0.5.0
> > release and I think it makes more sense to remove all our local patches
> > than cherry pick his improvements (creating more patches...).
> > 
> > Really, all this work is brynet@'s; I just get to be the one who swoops
> > in with the port update.
> > 
> > Works well here.
> > 
> > OK?
> > 
> > ~Brian
> > 
> 
> I should add too that upstream's CMake stuff generates compiler lines that
> neither ninja, samurai, nor our make understand so I fell back to gmake to
> build.

Yeah, I was using gmake directly too, but per upstream wanting to use
cmake --build, I had to find the magical invocation:

  cmake -DCMAKE_MAKE_PROGRAM=gmake ..

For the port, I think this can be added to CONFIGURE_ARGS?

Either way, it's OK brynet@ :-)

-Bryan.

Re: UPDATE: games/devilutionx to 0.5.0+

[Bryan Steele]

On Sat, Nov 09, 2019 at 12:12:58PM -0500, Brian Callahan wrote:
> Hi ports --
> 
> Attached is an update to games/devilutionx. The latest release is 0.5.0 but
> this update is a good bit past that point. Primarily because brynet@ did a
> lot of work upstreaming all patches but that came after the 0.5.0 release
> and I think it makes more sense to remove all our local patches than cherry
> pick his improvements (creating more patches...).

Awesome! :-)

> Really, all this work is brynet@'s; I just get to be the one who swoops in
> with the port update.

I just upstreamed the CMakeList.txt and a single patch, many of the
clang compatibility issues were fixed independently by upstream, which
significantly reduced the ports diffs required! Also, namtsui did a lot
of work on portability as well, and did a ton of work previously on
making TCP multiplayer on 64-bit platforms.

> Works well here.
> 
> OK?
> 
> ~Brian
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/devilutionx/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile  22 Sep 2019 14:35:18 -  1.3
> +++ Makefile  9 Nov 2019 17:08:04 -
> @@ -1,12 +1,12 @@
>  # $OpenBSD: Makefile,v 1.3 2019/09/22 14:35:18 bcallah Exp $
>  
>  COMMENT =open source engine recreation for Diablo 1 game
> -DISTNAME =   devilutionx-0.4.0pl20190914
> +DISTNAME =   devilutionx-0.5.0
>  CATEGORIES = games x11
>  
>  GH_ACCOUNT = diasurgical
>  GH_PROJECT = devilutionX
> -GH_COMMIT =  c52464d2278660cbfe6c23ea48d31d82882d205b
> +GH_COMMIT =  2afc5862a0762bdf1a2005249d5e34245815c595
>  
>  MAINTAINER = Brian Callahan 
>  
> @@ -27,6 +27,9 @@ LIB_DEPENDS =   devel/sdl2-mixer \
>  
>  CONFIGURE_ARGS = -DBINARY_RELEASE=ON \
>   -DDEBUG=OFF
> +
> +USE_GMAKE =  Yes
> +USE_NINJA =  No
>  
>  NO_TEST =Yes
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/devilutionx/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo  18 Sep 2019 13:32:16 -  1.2
> +++ distinfo  9 Nov 2019 17:08:04 -
> @@ -1,2 +1,2 @@
> -SHA256 (devilutionx-0.4.0pl20190914-c52464d2.tar.gz) = 
> M46b84l+ZUAcj44i7c4fnYpVAHPv4isUV6qUwNuAG2g=
> -SIZE (devilutionx-0.4.0pl20190914-c52464d2.tar.gz) = 1163991
> +SHA256 (devilutionx-0.5.0-2afc5862.tar.gz) = 
> W+N9S07qWHqFLPuv9Km18EIY+x0dIHGHvgukmL5By7o=
> +SIZE (devilutionx-0.5.0-2afc5862.tar.gz) = 1781028
> Index: patches/patch-CMakeLists_txt
> ===
> RCS file: /cvs/ports/games/devilutionx/patches/patch-CMakeLists_txt,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-CMakeLists_txt
> --- patches/patch-CMakeLists_txt  18 Sep 2019 13:32:16 -  1.2
> +++ patches/patch-CMakeLists_txt  9 Nov 2019 17:08:04 -
> @@ -1,25 +1,23 @@
>  $OpenBSD: patch-CMakeLists_txt,v 1.2 2019/09/18 13:32:16 bcallah Exp $
>  
> -clang
> +Don't do git here.
>  
>  Index: CMakeLists.txt
>  --- CMakeLists.txt.orig
>  +++ CMakeLists.txt
> -@@ -35,7 +35,7 @@ if(NIGHTLY_BUILD)
> -   set(FASTER ON)
> - endif()
> +@@ -18,14 +18,8 @@ option(NIGHTLY_BUILD "Enable options for nightly build
> + option(USE_SDL1 "Use SDL1.2 instead of SDL2" OFF)
> + option(NONET "Disable network" OFF)
>   
> --if(${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD)
> -+if(${CMAKE_SYSTEM_NAME} STREQUAL FreeBSD OR ${CMAKE_SYSTEM_NAME} STREQUAL 
> OpenBSD)
> -   set(ASAN OFF)
> -   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DO_LARGEFILE=0 -Dstat64=stat 
> -Dlstat64=lstat -Dlseek64=lseek -Doff64_t=off_t -Dfstat64=fstat 
> -Dftruncate64=ftruncate")
> - endif()
> -@@ -280,7 +280,7 @@ if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
> -   # Silence warnings about __int64 alignment hack not always being 
> applicable
> -   target_compile_options(devilutionx PRIVATE -Wno-ignored-attributes)
> -   # Fix: error: cast from pointer to smaller type 'unsigned char' loses 
> information
> --  target_compile_options(devilution PRIVATE -fms-extensions 
> -fms-compatibility -fms-compatibility-version=19.00)
> -+  #target_compile_options(devilution PRIVATE -fms-extensions 
> -fms-compatibility -fms-compatibility-version=19.00)
> - # Silence appfat.cpp warnings
> -   set(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -Wno-narrowing")
> - endif()
> +-include(CMake/git.cmake)
> +-get_git_tag(GIT_TAG)
> +-if(NOT CMAKE_BUILD_TYPE MATCHES "Release")
> +-  get_git_commit_hash(GIT_COMMIT_HASH)
> +-endif()
> +-
> + project(DevilutionX
> +-  VERSION ${GIT_TAG}
> ++  VERSION 0.5.0
> +   LANGUAGES C CXX)
> + 
> + if(BINARY_RELEASE)
> Index: patches/patch-SourceS_miniwin_h
> ===
> RCS file: patches/patch-SourceS_miniwin_h
> diff -N patches/patch-SourceS_miniwin_h
> --- patches/patch-SourceS_miniwin_h   18 Sep 2019 13:32:16 -  1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,31 +0,0 @@
> 

Re: chromium-77.0.3865.90 and Aw, Snap! everywhere

[Bryan Steele]

On Thu, Sep 26, 2019 at 11:47:39PM -0400, Bryan Steele wrote:
> On Thu, Sep 26, 2019 at 11:22:23PM +, Mikolaj Kucharski wrote:
> > Hi,
> > 
> > Does anyone else sees chrome not usable with latest snapshot? After
> > starting the browser it crashes any tab with "Aw, Snap!". At the same
> > time when I start the browser dmesg is full of pledge entries from
> > chrome (see below output) and chrome.core is left in $HOME.
> 
> I'm seeing this too with chromium-77.0.3865.90. It works fine with
> chromium-76.0.3809.132.
> 
> From what I can tell it seems the chromium renderer process is missing
> a pledge.
> 
> 39948 chrome   STRU  promise="stdio rpath flock prot_exec recvfd sendfd
> ps"
> 39948 chrome   CALL  getpriority(PRIO_PROCESS,0)
> 39948 chrome   PLDG  getpriority, "id", errno 1 Operation not permitted
> ..
> 
> https://github.com/openbsd/ports/blob/961e5936cdffea36f0041c7153c960ae65ad2ff3/www/chromium/patches/patch-services_service_manager_sandbox_openbsd_sandbox_openbsd_cc#L301
> 
> You'll need to use chrome --no-sandbox at least until this can be
> looked at by the maintainer, or if possible reinstall the older
> chromium package.

Note that robert@ has committed a proper fix for this (and a safer
workaround before that), so don't forget to remove --no-sandbox if
you added it somewhere.

chromium-77.0.3865.90p0 and later work again.

https://marc.info/?l=openbsd-ports-cvs=156968818914586=2

> > I upgraded to:
> > 
> > $ sysctl -n kern.version
> > OpenBSD 6.6-beta (GENERIC.MP) #327: Thu Sep 26 11:36:51 MDT 2019
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > and packages snapshot to:
> > 
> > $ awk '/digital-signature/ {print $NF}' /var/db/pkg/quirks-3.181/+CONTENTS
> > signify2:2019-09-26T17:01:40Z:external
> > 
> > $ awk '/digital-signature/ {print $NF}' 
> > /var/db/pkg/chromium-77.0.3865.90/+CONTENTS
> > signify2:2019-09-26T16:55:04Z:external
> > 
> > $ dmesg
> > ...
> > chrome[49746]: pledge "id", syscall 100
> > chrome[92387]: pledge "id", syscall 100
> > chrome[85549]: pledge "id", syscall 100
> > chrome[68279]: pledge "id", syscall 100
> > chrome[94240]: pledge "id", syscall 100
> > chrome[90180]: pledge "id", syscall 100
> > chrome[66584]: pledge "id", syscall 100
> > chrome[63381]: pledge "id", syscall 100
> > chrome[73033]: pledge "id", syscall 100
> > chrome[90867]: pledge "id", syscall 100
> > chrome[85108]: pledge "id", syscall 100
> > chrome[48198]: pledge "id", syscall 100
> > chrome[7576]: pledge "id", syscall 100
> > chrome[7576]: pledge "stdio", syscall 197
> > chrome[92089]: pledge "id", syscall 100
> > chrome[56583]: pledge "id", syscall 100
> > chrome[2955]: pledge "id", syscall 100
> > chrome[2955]: pledge "stdio", syscall 197
> > chrome[35028]: pledge "id", syscall 100
> > chrome[12759]: pledge "id", syscall 100
> > chrome[22687]: pledge "id", syscall 100
> > chrome[21924]: pledge "id", syscall 100
> > chrome[99193]: pledge "id", syscall 100
> > chrome[32604]: pledge "id", syscall 100
> > chrome[84867]: pledge "id", syscall 100
> > chrome[6284]: pledge "id", syscall 100
> > chrome[6284]: pledge "stdio", syscall 197
> > chrome[4125]: pledge "id", syscall 100
> > chrome[33735]: pledge "id", syscall 100
> > chrome[77972]: pledge "id", syscall 100
> > chrome[25419]: pledge "id", syscall 100
> > chrome[72435]: pledge "id", syscall 100
> > chrome[904]: pledge "id", syscall 100
> > 
> > -- 
> > Regards,
> >  Mikolaj
> > 
> > 

Re: chromium-77.0.3865.90 and Aw, Snap! everywhere

[Bryan Steele]

On Thu, Sep 26, 2019 at 11:22:23PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> Does anyone else sees chrome not usable with latest snapshot? After
> starting the browser it crashes any tab with "Aw, Snap!". At the same
> time when I start the browser dmesg is full of pledge entries from
> chrome (see below output) and chrome.core is left in $HOME.

I'm seeing this too with chromium-77.0.3865.90. It works fine with
chromium-76.0.3809.132.

>From what I can tell it seems the chromium renderer process is missing
a pledge.

39948 chrome   STRU  promise="stdio rpath flock prot_exec recvfd sendfd
ps"
39948 chrome   CALL  getpriority(PRIO_PROCESS,0)
39948 chrome   PLDG  getpriority, "id", errno 1 Operation not permitted
..

https://github.com/openbsd/ports/blob/961e5936cdffea36f0041c7153c960ae65ad2ff3/www/chromium/patches/patch-services_service_manager_sandbox_openbsd_sandbox_openbsd_cc#L301

You'll need to use chrome --no-sandbox at least until this can be
looked at by the maintainer, or if possible reinstall the older
chromium package.

> I upgraded to:
> 
> $ sysctl -n kern.version
> OpenBSD 6.6-beta (GENERIC.MP) #327: Thu Sep 26 11:36:51 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> and packages snapshot to:
> 
> $ awk '/digital-signature/ {print $NF}' /var/db/pkg/quirks-3.181/+CONTENTS
> signify2:2019-09-26T17:01:40Z:external
> 
> $ awk '/digital-signature/ {print $NF}' 
> /var/db/pkg/chromium-77.0.3865.90/+CONTENTS
> signify2:2019-09-26T16:55:04Z:external
> 
> $ dmesg
> ...
> chrome[49746]: pledge "id", syscall 100
> chrome[92387]: pledge "id", syscall 100
> chrome[85549]: pledge "id", syscall 100
> chrome[68279]: pledge "id", syscall 100
> chrome[94240]: pledge "id", syscall 100
> chrome[90180]: pledge "id", syscall 100
> chrome[66584]: pledge "id", syscall 100
> chrome[63381]: pledge "id", syscall 100
> chrome[73033]: pledge "id", syscall 100
> chrome[90867]: pledge "id", syscall 100
> chrome[85108]: pledge "id", syscall 100
> chrome[48198]: pledge "id", syscall 100
> chrome[7576]: pledge "id", syscall 100
> chrome[7576]: pledge "stdio", syscall 197
> chrome[92089]: pledge "id", syscall 100
> chrome[56583]: pledge "id", syscall 100
> chrome[2955]: pledge "id", syscall 100
> chrome[2955]: pledge "stdio", syscall 197
> chrome[35028]: pledge "id", syscall 100
> chrome[12759]: pledge "id", syscall 100
> chrome[22687]: pledge "id", syscall 100
> chrome[21924]: pledge "id", syscall 100
> chrome[99193]: pledge "id", syscall 100
> chrome[32604]: pledge "id", syscall 100
> chrome[84867]: pledge "id", syscall 100
> chrome[6284]: pledge "id", syscall 100
> chrome[6284]: pledge "stdio", syscall 197
> chrome[4125]: pledge "id", syscall 100
> chrome[33735]: pledge "id", syscall 100
> chrome[77972]: pledge "id", syscall 100
> chrome[25419]: pledge "id", syscall 100
> chrome[72435]: pledge "id", syscall 100
> chrome[904]: pledge "id", syscall 100
> 
> -- 
> Regards,
>  Mikolaj
> 
> 

Re: update games/devilutionx 0.4.0pl20190914

[Bryan Steele]

On Sat, Sep 14, 2019 at 06:47:56PM -0700, Nam Nguyen wrote:
> I attached an update for games/devilutionx as of September 14,
> 2019. Upstream added my fix for 64-bit TCP multiplayer. UDP is still
> broken.
> 
> Update: 
> https://github.com/diasurgical/devilutionX/commit/c52464d2278660cbfe6c23ea48d31d82882d205b
> TCP fix: https://github.com/diasurgical/devilutionX/pull/243
> UDP: https://github.com/diasurgical/devilutionX/issues/250
> 
> I tested multiplayer on i386 and amd64 and both were able to host and
> join the same game.
> 
> Tests are welcome, especially on arm64, as I saw that it did not cause
> an error on the aarch64 bulk build report. (A future version will
> support Spawn shareware to make it easier to test.)

Cool!

I've been using these changes locally for a few months now, glad to
see these fixes have been upstreamed.

I tested the diff applies and port update builds, Cmake is doing some
werid stuff because the compiler isn't named "clang" but c++, but it
only causes harmless warnings, devilutionx is still compiling with
clang and linking to libc++/libc++abi.

Thanks Nam!

(I'm obviously ok with this :-))

Re: egcc-ar in ports-gcc fails with Cannot find plugin 'liblto_plugin.so'

[Bryan Steele]

Please use ports@ for ports related discussions.

On Mon, Aug 26, 2019 at 04:03:23PM -0600, j...@bitminer.ca wrote:
> For ports package gcc-8.3.0p3, on abd64, using -current.
> 
> The shared lib liblto_plugin.so.5.0 is installed
> but no link is created. Thus egcc-ar (and egcc-ranlib and egcc-nm) fail:
> 

This is consistent with how OpenBSD handles shared libraries,
we don't usually create .so links for shared libraries.

https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs

Looking more closely this, it appears to be a GCC plugin, and not a
library intended to linked with, but dynamically loaded.

ktrace(1) shows that GCC is first trying to stat/access(2) the plugin
path instead of just calling dlopen(3) and checking for failure.

The port will need to be patched..

> snaptest66# cd /usr/local/libexec/gcc/x86_64-unknown-openbsd6.6/8.3.0/
> snaptest66# ls -l
> total 208420
> -rwxr-xr-x  1 root  bin25847384 Aug 22 14:13 cc1
> -rwxr-xr-x  1 root  bin27367192 Aug 22 14:13 cc1plus
> -rwxr-xr-x  1 root  bin  639696 Aug 22 14:13 collect2
> -rwxr-xr-x  1 root  bin26805056 Aug 22 14:13 f951
> drwxr-xr-x  2 root  wheel   512 Aug 23 10:29 install-tools
> -rwxr-xr-x  1 root  bin 989 Aug 22 14:13 liblto_plugin.la
> -rw-r--r--  1 root  bin  108688 Aug 22 14:13 liblto_plugin.so.5.0
> -rwxr-xr-x  1 root  bin 1077840 Aug 22 14:13 lto-wrapper
> -rwxr-xr-x  1 root  bin24795680 Aug 22 14:13 lto1
> drwxr-xr-x  2 root  wheel   512 Aug 23 10:29 plugin
> snaptest66# exit
> snaptest66$ egcc-nm -V
> egcc-nm: Cannot find plugin 'liblto_plugin.so'
> snaptest66$ egcc-ar -V
> egcc-ar: Cannot find plugin 'liblto_plugin.so'
> snaptest66$ egcc-ranlib -V
> egcc-ranlib: Cannot find plugin 'liblto_plugin.so'
> snaptest66$ \su -
> Password:
> snaptest66# cd /usr/local/libexec/gcc/x86_64-unknown-openbsd6.6/8.3.0/
> snaptest66# ln -s liblto_plugin.so.5.0 liblto_plugin.so
> snaptest66# ls -l
> total 208420
> -rwxr-xr-x  1 root  bin25847384 Aug 22 14:13 cc1
> -rwxr-xr-x  1 root  bin27367192 Aug 22 14:13 cc1plus
> -rwxr-xr-x  1 root  bin  639696 Aug 22 14:13 collect2
> -rwxr-xr-x  1 root  bin26805056 Aug 22 14:13 f951
> drwxr-xr-x  2 root  wheel   512 Aug 23 10:29 install-tools
> -rwxr-xr-x  1 root  bin 989 Aug 22 14:13 liblto_plugin.la
> lrwxr-xr-x  1 root  wheel20 Aug 26 14:57 liblto_plugin.so ->
> liblto_plugin.so.5.0
> -rw-r--r--  1 root  bin  108688 Aug 22 14:13 liblto_plugin.so.5.0
> -rwxr-xr-x  1 root  bin 1077840 Aug 22 14:13 lto-wrapper
> -rwxr-xr-x  1 root  bin24795680 Aug 22 14:13 lto1
> drwxr-xr-x  2 root  wheel   512 Aug 23 10:29 plugin
> snaptest66# exit
> snaptest66$ egcc-ar -V
> /usr/bin/ar: illegal option -- -
> Usage: /usr/bin/ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV]
> [member-name] [count] archive-file file...
>/usr/bin/ar -M [  commands:
>   d- delete file(s) from the archive
>   m[ab]- move file(s) in the archive
>   p- print file(s) found in the archive
> etc...works!
> 
> 
> snaptest66$ pkg_info
> boost-1.66.0p6  free peer-reviewed portable C++ source libraries
> bzip2-1.0.8 block-sorting file compressor, unencumbered
> flang-8.0.0.20190801 LLVM Fortran compiler passes and runtime library
> flang-driver-8.0.0.20190621p0 LLVM Fortran compiler driver
> g++-8.3.0p3 GNU compiler collection: C++ compiler
> g95-8.3.0p3 GNU compiler collection: f95 compiler
> gcc-8.3.0p3 GNU compiler collection: core C compiler
> gcc-libs-8.3.0p3GNU compiler collection: support libs
> gettext-runtime-0.20.1p0 GNU gettext runtime libraries and programs
> gmp-6.1.2p3 library for arbitrary precision arithmetic
> icu4c-64.2p0International Components for Unicode
> intel-firmware-20190618p0v0 microcode update binaries for Intel CPUs
> libaio_compat-5.2.2 port of POSIX asynchronous I/O routines from DragonFly
> BSD
> libexecinfo-0.3p2v0 clone of backtrace facility found in the GNU libc
> libffi-3.2.1p5  Foreign Function Interface
> libiconv-1.16p0 character set conversion library
> libmpc-0.9p2complex numbers math library
> libomp-8.0.0p1  LLVM OpenMP runtime
> libpgmath-8.0.0.20190801 LLVM Fortran math library
> mpfr-3.1.5.2p1  library for multiple-precision floating-point
> computations
> python-2.7.16p1 interpreted object-oriented programming language
> python-3.7.4interpreted object-oriented programming language
> quirks-3.173exceptions to pkg_add rules
> sqlite3-3.29.0  embedded SQL implementation
> xz-5.2.4LZMA compression and decompression tools
> 
> 
> 
> snaptest66$ sysctl |grep OpenBSD
> kern.ostype=OpenBSD
> kern.version=OpenBSD 6.6-beta (GENERIC.MP) #242: Fri Aug 23 09:06:40 MDT
> 2019
> 
> 
> 

Re: NEW: games/devilutionx

[Bryan Steele]

I had a lot of fun testing this, indeed, this fixes multiplayer. I'm
ok with getting this in to make it easier for others to get in. :-)

On Tue, Jul 23, 2019 at 11:46:10PM -0700, Nam Nguyen wrote:
> 
> I promise that this third attachment preserves ^M properly. I had to use
> application/octet-stream and not text/x-patch in my e-mail client.
> 
> Nam Nguyen writes:
> 
> > I just realized that pasting it mangled the ^M. I have attached it
> > here. Also, the commit is dated July 23, 2019.
> 

Re: NEW: games/devilutionx

[Bryan Steele]

On Fri, Jul 19, 2019 at 10:37:59AM -0400, Bryan Steele wrote:
> On Thu, Jul 18, 2019 at 07:49:51PM -0400, Brian Callahan wrote:
> > Hi ports --
> > 
> > Attached is a new port, games/devilutionx. DevilutionX is an open source
> > engine recreation for the original Diablo I game.
> > 
> > ---
> > pkg/DESCR:
> > DevilutionX is an open source recreation of the game engine used in
> > Diablo I, an action role-playing game by Blizzard Entertainment.
> > 
> > While this package and the game engine are open source, one still needs
> > to provide the original game assets from Diablo I, which is not open
> > source. You will need to purchase the original game to use this package.
> > ---
> > 
> > This port is a multi-person effort between myself, thfr@, and brynet@. The
> > game works very well on amd64--the underlying engine is claimed to be nearly
> > 100% binary identical to the original game. Sadly, multiplayer doesn't work
> > on 64-bit platforms, but this is known and hopefully will be fixed at some
> > point.
> > 
> > OK?
> > 
> > ~Brian
> 
> I'm obviously ok with this going in, w/ the pkg/README fix from Nam. :-)
> 
> It's unfortunate that we will initially miss out on multiplayer support,
> but good that someone is working on the problem, and upstream is aware.
> 
> Hopefully some of these changes can be sent upstream.
> 
> -Bryan.

To those of you following along, this is the port that thfr@ used when
streaming Diablo last month on OpenBSD.

https://www.youtube.com/watch?v=5sBKaqkFev8

Re: NEW: games/devilutionx

[Bryan Steele]

On Thu, Jul 18, 2019 at 07:49:51PM -0400, Brian Callahan wrote:
> Hi ports --
> 
> Attached is a new port, games/devilutionx. DevilutionX is an open source
> engine recreation for the original Diablo I game.
> 
> ---
> pkg/DESCR:
> DevilutionX is an open source recreation of the game engine used in
> Diablo I, an action role-playing game by Blizzard Entertainment.
> 
> While this package and the game engine are open source, one still needs
> to provide the original game assets from Diablo I, which is not open
> source. You will need to purchase the original game to use this package.
> ---
> 
> This port is a multi-person effort between myself, thfr@, and brynet@. The
> game works very well on amd64--the underlying engine is claimed to be nearly
> 100% binary identical to the original game. Sadly, multiplayer doesn't work
> on 64-bit platforms, but this is known and hopefully will be fixed at some
> point.
> 
> OK?
> 
> ~Brian

I'm obviously ok with this going in, w/ the pkg/README fix from Nam. :-)

It's unfortunate that we will initially miss out on multiplayer support,
but good that someone is working on the problem, and upstream is aware.

Hopefully some of these changes can be sent upstream.

-Bryan.

Re: add pledge and unveil to net/irssi

[Bryan Steele]

On Tue, Jun 11, 2019 at 08:59:55AM +0200, Solene Rapenne wrote:
> On Fri, Jun 07, 2019 at 11:41:14PM +0200, Solene Rapenne wrote:
> > On Fri, Jun 07, 2019 at 07:25:45PM +0100, Stuart Henderson wrote:
> > > On 2019/06/07 19:05, Solene Rapenne wrote:
> > > > Hi,
> > > > 
> > > > This is a first draft to add pledge and unveil to net/irssi.
> > > > 
> > > > About the Makefile, I added PORTHOME=${WRKDIST} so "make test" run with
> > > > 100% of success.
> > > > 
> > > > The current implementation of pledge/unveil is under a #ifdef
> > > > HAVE_PLEDGE so I defined it there.
> > > 
> > > Nothing is calling pledge_init (I noticed because there's no "p" flag
> > > showing in ps, and to be honest also because it didn't crash like I was
> > > expecting it to with my configuration ;-)
> > 
> > one patch was missing :(
> > 
> > full patch below, I reapplied it on a fresh net/irssi folder and I can
> > see the "p" state in ps
> > 
> > The security features can be disabled (a bit of work is required to
> > disable the pledge in net-nonblock.c (you should already have it enabled
> > when you were connected)) so people requiring plugins not working can
> > still use irssi in the current state. /bin/ , /usr/bin/ and
> > /usr/local/bin could be added to unveil I think. My main goal was to
> > prevent irssi to write scripts and exec them, with the current unveil
> > from this patch, irssi can't write under ~/.irssi/scripts but can exec
> > them.
> > 
> 
> I reworked the patch a bit. I removed HAVE_PLEDGE and made a function to
> get if user want to disable that feature or not, so I can use it in
> other files, like in net-nonblock.c, when you use -u then all
> pledge/unveil calls are skipped correctly.
> 
> When not disabled, it will show a message in irssi log (easy to view it
> with irssi -! to disable autoconnect).
> 
> irssi doesn't exec plugins but load them, so the x flag is useless for
> the scripts directory. unveil is still useful there because it sets the
> filesystem scope of plugins, you cant' do `cat /something` from a perl
> script nor you can do open(IN,' 
> I'm not sure keeping the unveil call for ~/irclogs is a good idea, it
> won't work at first run because unveil assume a non existent path is a
> file, so you need to run irssi twice the first time you activate logs.
> People having logs in ~/irclogs can still redefine logs inside ~/.irssi/
> and make a symlink to it in ~/irclogs

Hi Solene,

As I mentioned on irc, I don't think this is good for a number of
reasons. The logs directory can be changed in ~/.irssi/config, via
command line, _AND_ at runtime (/SET autolog_path  ++if (pledge("dns inet stdio",NULL) == -1)

Instead of
> ++if (pledge("stdio dns inet", NULL) == -1)

Always makes me suspect that this wasn't done..

-Bryan.

> I had lot of feedback about this change not being plugin friendly, but I
> had no real feedback either. I would say that if it kills your plugins,
> just use flag -u or maybe I should make this feature non default and
> activate it with -u?
> 
> I don't use much plugins in irssi and none interacts with the FS at all.
> If some requires dbus for notification, I think it's safe to unveil the
> dbus socket path as chromium does.
> 
> 
> Index: Makefile
> ===
> RCS file: /data/cvs/ports/net/irssi/Makefile,v
> retrieving revision 1.79
> diff -u -p -r1.79 Makefile
> --- Makefile  18 Feb 2019 18:35:57 -  1.79
> +++ Makefile  11 Jun 2019 06:38:27 -
> @@ -5,6 +5,7 @@ COMMENT = modular IRC client with many f
>  V =  1.2.0
>  DISTNAME =   irssi-$V
>  PKGSPEC =irssi-=$V
> +REVISION =   0
>  
>  CATEGORIES = net
>  
> @@ -15,6 +16,7 @@ MAINTAINER =Klemens Nanni   # GPLv2+
>  PERMIT_PACKAGE_CDROM =   Yes
>  
> +# use pledge()
>  WANTLIB +=   c crypto curses gcrypt glib-2.0 gmodule-2.0 gpg-error \
>   iconv intl m otr pcre perl pthread ssl
>  
> @@ -44,6 +46,9 @@ CONFIGURE_ARGS +=   --with-socks
>  LIB_DEPENDS +=   security/dante
>  WANTLIB +=   socks
>  .endif
> +
> +# required for 100% tests to pass
> +PORTHOME=${WRKDIST}
>  
>  MAKE_FLAGS = scriptdir="${SYSCONFDIR}/irssi/scripts" \
>   themedir="${SYSCONFDIR}/irssi/themes"
> Index: patches/patch-src_core_net-nonblock_c
> ===
> RCS file: patches/patch-src_core_net-nonblock_c
> diff -N patches/patch-src_core_net-nonblock_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_core_net-nonblock_c 11 Jun 2019 06:37:38 -
> @@ -0,0 +1,17 @@
> +$OpenBSD$
> +
> +Index: src/core/net-nonblock.c
> +--- src/core/net-nonblock.c.orig
>  src/core/net-nonblock.c
> +@@ -60,6 +60,11 @@ int net_gethostbyname_nonblock(const char *addr, GIOCh
> +   "Using blocking resolving");
> + }
> + 
> ++if(pledge_enabled()) {
> ++if (pledge("dns inet stdio",NULL) == -1)
> ++  

WASM/WebAssembly is busted

[Bryan Steele]

In -current (and 6.4), chrome repeatedly attempts to mmap a large linear
area of memory for WASM/WebAssembly and it always fails. WASM JIT avoids
using the system malloc/free, opting instead for their own "Heartbleed
accelerating custom allocator".

Despite the horribleness, this feature is being increasingly used by
default if the browser advertises this misfeature as supported, many
sites will fallback if it is unavailable. Unfortunately, they *DO NOT*
fallback if WASM fails to allocate memory. You simply get broken, half-
working websites. :-(

For example, the popular video streaming platform (twitch.tv) will show
a black box where the stream should be. The error is not obvious unless
you check the browsers Javascript console:

Uncaught RangeError: WebAssembly.Memory(): could not allocate memory
at wasmworker.min.js:51
at blob:https://www.twitch.tv/2af8520d-25ad-4f42-bc94-497265c25c62:6
(index):1 Script error

After hours of searching, I found the magic knob to disable WASM in
chrome: '--js-flags=--noexpose_wasm'

There's no UI way that I can find to disable it, so you'll need to
add a shell alias or put it in your window managers config.

Note: Firefox is also not saved from this insanity, WASM will often
fail there as well.. unless datasize is cranked to infinity and beyond.

-Bryan.

Here's the ktrace(1)/kdump(1) for chrome:

 60738 chrome   CALL  
mmap(0x1f46f5fa,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x1f46f5fa,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x208a1b2f,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x208a1b2f,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x2f854681,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x2f854681,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x29b16e69,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x29b16e69,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x2cfe5ed4,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x2cfe5ed4,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x2b67a9e9,0x28000,0,0x1002,-1,0)
 60738 chrome   CALL  
mmap(0x2b67a9e9,0x28000,0,0x1002,-1,0)
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory
 60738 chrome   RET   mmap -1 errno 12 Cannot allocate memory

Re: CVS: cvs.openbsd.org: ports

[Bryan Steele]

On Sun, Sep 23, 2018 at 12:39:34PM -0600, Thomas Frohwein wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   t...@cvs.openbsd.org2018/09/23 12:39:34
> 
> Log message:
> import games/fnaify
> 
> fnaify is a script to facilitate running games based on the open-source 
> FNA
> framework on OpenBSD. It takes care of adjusting the configuration files 
> to
> OpenBSD's library names and creates a custom launch script with everything
> needed to start the game.
> 
> For more information on FNA, see official website: 
> https://fna-xna.github.io
> 
> Some examples of games FNA games that can be configured with fnaify 
> include
> Stardew Valley, Rogue Legacy, and Owlboy.
> 
> tested by Thuban, ok bcallah@
> 
> Status:
> 
> Vendor Tag:   thfr
> Release Tags: thfr_20180923
> 
> N ports/games/fnaify/Makefile
> N ports/games/fnaify/distinfo
> N ports/games/fnaify/pkg/README
> N ports/games/fnaify/pkg/DESCR
> N ports/games/fnaify/pkg/PLIST
> 
> No conflicts created by this import

Congrats! :-)

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2017/07/31 15:26:12

Modified files:
emulators/mednafen: Makefile 

Log message:
Fix mednafen link with clang builds,  not thoroughly tested yet.

ok jeremy@

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Mon, Jun 19, 2017 at 10:33:26AM -0400, Bryan Steele wrote:
> On Sat, Jun 17, 2017 at 12:58:03PM +0100, Stuart Henderson wrote:
> > On 2017/06/04 04:40, Bryan Steele wrote:
> > > "As Shmuel reported in
> > > <https://gcc.gnu.org/ml/gcc-help/2017-03/msg9.html>,
> > > on x86-64 small structures in automatic storage are aligned to 16 bytes.
> > > This seems to be because of a mix-up between bits and bytes in the i386
> > > target code.
> > > 
> > > * config/i386/i386.c (ix86_local_alignment): Align most aggregates
> > > of 16 bytes and more to 16 bytes, not those of 16 bits and more."
> > > 
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6
> > > 
> > > It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
> > > and committed by martynas@ to base gcc4 shortly later.
> > > 
> > > http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
> > > http://marc.info/?l=openbsd-cvs=139895377300712=2
> > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3=1.4=h
> > 
> > Does this actually work?
> > 
> > I might be missing something from this, but I haven't been able to
> > elicit a SIGABRT from Ted's simple test program with any of the
> > compilers.
> > 
> > Any idea what's going on?
> > 
> > $ for i in gcc egcc /usr/bin/clang /usr/local/bin/clang; do printf "$i\t"; 
> > $i -o scanf scanf.c; echo 12345678901234567890123456789012 | ./scanf; done
> > gcc 12345678901234567890123456789012 0xabad1dea
> > egcc12345678901234567890123456789012 0xabad1dea
> > /usr/bin/clang  12345678901234567890123456789012 0xabad1dea
> > /usr/local/bin/clang12345678901234567890123456789012 0xabad1dea
> 
> It works with the example I gave previously, at least, I can't find
> tedu@'s example, but there is always the possibility for alignment
> or padding differences preventing it from reproducibly triggering
> on every overflow.
> 
> http://marc.info/?l=openbsd-ports=149667837410983=2
> 
> $ pkg_info | grep gcc
> gcc-4.9.4p5 GNU compiler collection: core C compiler
> $ egcc ssp-test.c -o ssp-test-egcc  
> $ ./ssp-test-egcc
> Abort trap
> 
> Of course, there could *always* be more compiler bugs.. ;-)
> 
> -Bryan.

Found it
http://undeadly.org/cgi?action=article=20131202075805

A good explanation from otto@ in the comments, as others reported
this before..

"Stack protection only protects the return address and frame pointer.
There's no way it will catch any stack based overflow. Due to alignment
rules on amd64, the buffer will live further in the stack frame, hence
the one byte overflow just falls into the alignment gap.

i386 allows it's stack frame to be packed tight."

http://undeadly.org/cgi?action=article=20131202075805=6

-Bryan.

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Sat, Jun 17, 2017 at 12:58:03PM +0100, Stuart Henderson wrote:
> On 2017/06/04 04:40, Bryan Steele wrote:
> > "As Shmuel reported in
> > <https://gcc.gnu.org/ml/gcc-help/2017-03/msg9.html>,
> > on x86-64 small structures in automatic storage are aligned to 16 bytes.
> > This seems to be because of a mix-up between bits and bytes in the i386
> > target code.
> > 
> > * config/i386/i386.c (ix86_local_alignment): Align most aggregates
> > of 16 bytes and more to 16 bytes, not those of 16 bits and more."
> > 
> > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6
> > 
> > It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
> > and committed by martynas@ to base gcc4 shortly later.
> > 
> > http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
> > http://marc.info/?l=openbsd-cvs=139895377300712=2
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3=1.4=h
> 
> Does this actually work?
> 
> I might be missing something from this, but I haven't been able to
> elicit a SIGABRT from Ted's simple test program with any of the
> compilers.
> 
> Any idea what's going on?
> 
> $ for i in gcc egcc /usr/bin/clang /usr/local/bin/clang; do printf "$i\t"; $i 
> -o scanf scanf.c; echo 12345678901234567890123456789012 | ./scanf; done
> gcc   12345678901234567890123456789012 0xabad1dea
> egcc  12345678901234567890123456789012 0xabad1dea
> /usr/bin/clang12345678901234567890123456789012 0xabad1dea
> /usr/local/bin/clang  12345678901234567890123456789012 0xabad1dea

It works with the example I gave previously, at least, I can't find
tedu@'s example, but there is always the possibility for alignment
or padding differences preventing it from reproducibly triggering
on every overflow.

http://marc.info/?l=openbsd-ports=149667837410983=2

$ pkg_info | grep gcc
gcc-4.9.4p5 GNU compiler collection: core C compiler
$ egcc ssp-test.c -o ssp-test-egcc  
$ ./ssp-test-egcc
Abort trap

Of course, there could *always* be more compiler bugs.. ;-)

-Bryan.

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2017/06/07 17:34:03

Modified files:
lang/gcc/4.6   : Makefile 
lang/gcc/4.6/pkg: PLIST-main 
lang/gcc/4.9   : Makefile 
lang/gcc/4.9/patches: patch-gcc_config_i386_i386_c 
lang/gcc/4.9/pkg: PLIST-main 
lang/gcc/6 : Makefile 
lang/gcc/6/patches: patch-gcc_config_i386_i386_c 
lang/gcc/6/pkg : PLIST-main 

Log message:
Backport, or rather forward port, a fix for the broken stack-protector on amd64.

This mirrors a change made to base gcc4.2 by martynas@ in 2014.

https://marc.info/?l=openbsd-ports=149656580518245=2

Includes an independent fix from upstream for gcc6, currently unlinked
from builds

Also, stop installing libssp as it broken on OpenBSD as it tries to use gets()

pirofti@ ok'd an earlier version, suggestions from sthen@
"doesn't look dangerous" espie@
"pretty astounding" deraadt@

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Tue, Jun 06, 2017 at 12:05:57PM -0400, Bryan Steele wrote:
> On Tue, Jun 06, 2017 at 04:53:27PM +0100, Stuart Henderson wrote:
> > On 2017/06/06 11:12, Bryan Steele wrote:
> > > On Mon, Jun 05, 2017 at 11:58:43AM -0400, Bryan Steele wrote:
> > > > This will probably require library and ports bumps
> > > 
> > > I'm not sure where to go from here, bumping estdc++ should take
> > > care of any ports using eg++, but there are still a few ports
> > > using egcc for emulated TLS support.
> > 
> > Or for C11, or because of miscompiles with gcc 4.2, or various other
> > reasons.
> 
> Right.
> 
> > > What about the other shared libraries, gfortran, objc.. or other
> > > bootstraps? The installed libssp is unused, and uses gets()..
> > > 
> > > This is something I wish someone else could help me with as I
> > > don't normally do ports builds myself..
> > > 
> > > Not sure if this SQL query is correct.. at least some of these
> > > may actually be missing an explict stdc++ wantlib? Qt5?
> > 
> > Qt5 is built with ports gcc so it uses estdc++ not stdc++.
> > 
> > Programs are not _supposed_ to link with both stdc++ and estdc++ because
> > they conflict, though many things in ports do, it's unavoidable when we
> > have X libraries built with gcc 4.2.
> 
> Yes, I meant estdc++ here.
> 
> > > Halp?
> > > 
> > > -Bryan.
> > > 
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/lang/gcc/4.9/Makefile,v
> > > retrieving revision 1.47
> > > diff -u -p -u -r1.47 Makefile
> > > --- Makefile  4 Mar 2017 21:59:55 -   1.47
> > > +++ Makefile  6 Jun 2017 15:10:51 -
> > > @@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 arm hppa i386 mip
> > >  DPB_PROPERTIES = parallel
> > >  
> > >  V = 4.9.4
> > > -REVISION = 4
> > > +REVISION = 5
> > >  FULL_VERSION = $V
> > >  FULL_PKGVERSION = $V
> > >  
> > > @@ -39,7 +39,7 @@ PKGNAME-objc =  gobjc-${FULL_PKGVERSION}
> > >  PKGNAME-ada =   gnat-${FULL_PKGVERSION}
> > >  PKGSPEC-main = gcc->=4.9,<4.10
> > >  
> > > -SHARED_LIBS =estdc++ 17.0 \
> > > +SHARED_LIBS =estdc++ 18.0 \
> > 
> > This conflicts with the major in lang/gcc/6. If you want to bump major
> > here, you'll also have to bump it in lang/gcc/6 as well (including
> > MODGCC4_CPPWANTLIB in 6/gcc4.port.mk). I don't see why you would bump
> > major though, you're just trying to trigger an update aren't you? Minor
> > is enough for that.
> 
> Yeah, we just need to recompile dependant ports, no symbol changes.
> 
> From what I can tell, gcc6 is not linked to the build yet, but it
> would also require a similar patch, probably closer to what was
> committed upstream.

I'd like to commit at least this part, and then deal with ports
that needs REVISION or library bumps later if we have to..

libssp is not used by our stack-protector implementation and
should be removed, linking with it doesn't work.. anything
using the installed headers should be fixed.

I've bumped all other gcc shared libraries which I verified
are compiled with stack protection enabled, which is all of
them except libgcj-tools and libgo (unpackaged?)

Didn't bother with the bumps for gcc6 because nothing is
using it yet.

No idea about the bootstraps, I can't test those..

-Bryan.

Index: 4.9/Makefile
===
RCS file: /cvs/ports/lang/gcc/4.9/Makefile,v
retrieving revision 1.47
diff -u -p -u -r1.47 Makefile
--- 4.9/Makefile4 Mar 2017 21:59:55 -   1.47
+++ 4.9/Makefile7 Jun 2017 20:13:25 -
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 arm hppa i386 mip
 DPB_PROPERTIES = parallel
 
 V = 4.9.4
-REVISION = 4
+REVISION = 5
 FULL_VERSION = $V
 FULL_PKGVERSION = $V
 
@@ -39,19 +39,18 @@ PKGNAME-objc =  gobjc-${FULL_PKGVERSION}
 PKGNAME-ada =   gnat-${FULL_PKGVERSION}
 PKGSPEC-main = gcc->=4.9,<4.10
 
-SHARED_LIBS =  estdc++ 17.0 \
-   gfortran6.0 \
-   gcj 4.0 \
+SHARED_LIBS =  estdc++ 17.1 \
+   gfortran6.1 \
+   gcj 4.1 \
gcj-tools   4.0 \
-   gij 4.0 \
-   objc6.0 \
-   ssp 4.0 \
-   lto_plugin  3.0 \
+   gij 4.1 \
+   objc6.1 \
+   lto_plugin  3.1 \
go  3.0 \
-

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Tue, Jun 06, 2017 at 12:23:31PM -0400, Bryan Steele wrote:
> On Tue, Jun 06, 2017 at 12:05:57PM -0400, Bryan Steele wrote:
> > > > SELECT FULLPKGPATH,MODULES,WANTLIB FROM Ports WHERE MODULES LIKE 
> > > > '%gcc4%' AND WA
> > > > NTLIB NOT LIKE '%CXX%' AND WANTLIB NOT LIKE '%stdc++%';
> > > 
> > > I think you're actually wanting
> > > 
> > > ... wantlib not like '%LIBECXX%' and wantlib not like '%estdc++%'
> > 
> > I believe the point here was to generate a list of ports using ports gcc4,
> > but not depending on C++, so this should exclude both.
> > 
> > -Bryan.
> 
> Hmm, Actually I guess we also want ports using gcc4, but using base
> stdc++ as well.

archivers/zstd|gcc4|c pthread z
astro/wcslib|gcc4 gnu|c cfitsio m gfortran>=3 quadmath
audio/audacious|devel/gettext gcc4 gnu|atk-1.0 c cairo cairo-gobject fontconfig 
freetype gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gtk-3 
guess m pango-1.0 pangocairo-1.0 pangoft2-1.0 pthread z intl>=5 iconv>=6
audio/jack|gcc4 gnu|c celt0>=1 db m pthread readline samplerate sndfile sndio 
termcap FLAC ogg vorbis vorbisenc
audio/sox|gcc4 gnu|c m z sndio FLAC gsm mad id3tag mp3lame ogg sndfile vorbis 
vorbisenc vorbisfile opencore-amrnb opencore-amrwb opus opusfile twolame 
wavpack iconv png
databases/kyotocabinet|gcc4 gnu|c m pthread ${LIBCXX} z
databases/mdbtools,-main|gcc4 devel/gettext x11/gnome gnu|c glib-2.0 iconv 
iodbcinst pthread readline
databases/mdbtools,-gmdb|gcc4 devel/gettext x11/gnome gnu|intl>=5 iconv>=6 c 
gdk-x11-2.0 gdk_pixbuf-2.0 glade-2.0 glib-2.0 gnome-2 gnomeui-2 gobject-2.0 
gtk-x11-2.0 mdb mdbsql pango-1.0 pthread
databases/postgresql,-pg_upgrade|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 pq>=4
databases/postgresql,-plpython|lang/python gcc4 gnu|c m pthread util  python2.7
databases/postgresql,-contrib|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 pq>=4
databases/postgresql,-server|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 perl pq>=4
databases/postgresql,-main|lang/python gcc4 gnu|c crypto m readline ssl termcap 
z xml2
databases/postgresql-previous|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 perl util
devel/libgit2/libgit2|devel/cmake  lang/python  gcc4|crypto curl pthread ssh2 
ssl z
devel/liburcu|gcc4 gnu|pthread
devel/libuv|gcc4 gnu|pthread
devel/llvm,-python|devel/cmake  lang/python  gcc4|clang
devel/py-gobject3,-main|lang/python  x11/gnome gcc4 gnu textproc/intltool|X11 
Xext Xrender cairo cairo-gobject expat ffi fontconfig freetype gio-2.0 
girepository-1.0 glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 iconv intl m pcre 
pixman-1 png pthread pthread-stubs xcb xcb-render xcb-shm z
devel/py-gobject3,python3,-main|lang/python  x11/gnome gcc4 gnu 
textproc/intltool|X11 Xext Xrender cairo cairo-gobject expat ffi fontconfig 
freetype gio-2.0 girepository-1.0 glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 
iconv intl m pcre pixman-1 png pthread pthread-stubs xcb xcb-render xcb-shm z
emulators/mgba,-libretro|devel/cmake x11/qt5 gcc4|m pthread
emulators/mgba,-main|devel/cmake x11/qt5 gcc4|GL GLU MagickCore-6.Q16 
MagickWand-6.Q16 SDL2  avcodec avformat avresample avutil c edit m png  pthread 
swscale termcap z zip epoxy
emulators/mupen64plus/core|gcc4|GL GLU c m ${LIBCXX} z freetype png pthread SDL2
emulators/xroar|gnu gcc4|GL GLU ICE SDL2 SM X11 Xcomposite Xcursor Xdamage Xext 
Xfixes Xi Xinerama Xmu Xt Xrandr Xrender atk-1.0 c cairo fontconfig freetype 
gdk-x11-2.0 gdkglext-x11-1.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0 
gobject-2.0 gtk-x11-2.0 gtkglext-x11-1.0 intl m pango-1.0 pangocairo-1.0 
pangoft2-1.0 pangox-1.0 pthread sndfile z
games/tome4,-main|gcc4|GL GLU SDL2 SDL2_image SDL2_ttf openal c m  png pthread 
vorbisfile
graphics/libgxps|x11/gnome gnu gcc4 textproc/intltool|X11 Xext Xrender archive 
bz2 c cairo crypto expat ffi fontconfig freetype gio-2.0 glib-2.0 gmodule-2.0 
gobject-2.0 iconv intl jpeg lcms2 lz4 lzma lzo2 m pcre pixman-1 png pthread 
pthread-stubs tiff xcb xcb-render xcb-shm z
graphics/libraw|gcc4 gnu|c jasper jpeg lcms2 m pthread ${LIBCXX}
japanese/mecab,-main|gcc4 gnu|c iconv m pthread ${LIBCXX}
lang/classpath|devel/gettext gcc4 gnu|GL ICE SM X11 Xau Xcomposite Xcursor 
Xdamage Xdmcp Xext Xfixes Xi Xinerama Xrandr Xrender Xtst Xxf86vm atk-1.0 c 
cairo dbus-1 dbus-glib-1 drm expat ffi fontconfig freetype gconf-2 gdk-x11-2.0 
gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0 gmp gobject-2.0 graphite2 
gthread-2.0 gtk-x11-2.0 harfbuzz m magic pango-1.0 pangocairo-1.0 pangoft2-1.0 
pcre pixman-1 png pthread pthread-stubs ${LIBCXX} xcb xcb-render xcb-shm z 
intl>=5 iconv>=6
lang/guile2|gnu gcc4|c ffi gc gmp iconv intl ltdl m ncurses pthread readline 
unistring
lang/luajit|lang/lua gcc4|c m
lang/php/5.5,-bz2|gcc4 gnu|bz2>=10 pthread
lang/php/5.5,-odbc|gcc4 gnu|iodbc>=2 pthread iodbcinst
lang/

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Tue, Jun 06, 2017 at 12:05:57PM -0400, Bryan Steele wrote:
> > > SELECT FULLPKGPATH,MODULES,WANTLIB FROM Ports WHERE MODULES LIKE '%gcc4%' 
> > > AND WA
> > > NTLIB NOT LIKE '%CXX%' AND WANTLIB NOT LIKE '%stdc++%';
> > 
> > I think you're actually wanting
> > 
> > ... wantlib not like '%LIBECXX%' and wantlib not like '%estdc++%'
> 
> I believe the point here was to generate a list of ports using ports gcc4,
> but not depending on C++, so this should exclude both.
> 
> -Bryan.

Hmm, Actually I guess we also want ports using gcc4, but using base
stdc++ as well.

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Tue, Jun 06, 2017 at 04:53:27PM +0100, Stuart Henderson wrote:
> On 2017/06/06 11:12, Bryan Steele wrote:
> > On Mon, Jun 05, 2017 at 11:58:43AM -0400, Bryan Steele wrote:
> > > This will probably require library and ports bumps
> > 
> > I'm not sure where to go from here, bumping estdc++ should take
> > care of any ports using eg++, but there are still a few ports
> > using egcc for emulated TLS support.
> 
> Or for C11, or because of miscompiles with gcc 4.2, or various other
> reasons.

Right.

> > What about the other shared libraries, gfortran, objc.. or other
> > bootstraps? The installed libssp is unused, and uses gets()..
> > 
> > This is something I wish someone else could help me with as I
> > don't normally do ports builds myself..
> > 
> > Not sure if this SQL query is correct.. at least some of these
> > may actually be missing an explict stdc++ wantlib? Qt5?
> 
> Qt5 is built with ports gcc so it uses estdc++ not stdc++.
> 
> Programs are not _supposed_ to link with both stdc++ and estdc++ because
> they conflict, though many things in ports do, it's unavoidable when we
> have X libraries built with gcc 4.2.

Yes, I meant estdc++ here.

> > Halp?
> > 
> > -Bryan.
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/lang/gcc/4.9/Makefile,v
> > retrieving revision 1.47
> > diff -u -p -u -r1.47 Makefile
> > --- Makefile4 Mar 2017 21:59:55 -   1.47
> > +++ Makefile6 Jun 2017 15:10:51 -
> > @@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 arm hppa i386 mip
> >  DPB_PROPERTIES = parallel
> >  
> >  V = 4.9.4
> > -REVISION = 4
> > +REVISION = 5
> >  FULL_VERSION = $V
> >  FULL_PKGVERSION = $V
> >  
> > @@ -39,7 +39,7 @@ PKGNAME-objc =  gobjc-${FULL_PKGVERSION}
> >  PKGNAME-ada =   gnat-${FULL_PKGVERSION}
> >  PKGSPEC-main = gcc->=4.9,<4.10
> >  
> > -SHARED_LIBS =  estdc++ 17.0 \
> > +SHARED_LIBS =  estdc++ 18.0 \
> 
> This conflicts with the major in lang/gcc/6. If you want to bump major
> here, you'll also have to bump it in lang/gcc/6 as well (including
> MODGCC4_CPPWANTLIB in 6/gcc4.port.mk). I don't see why you would bump
> major though, you're just trying to trigger an update aren't you? Minor
> is enough for that.

Yeah, we just need to recompile dependant ports, no symbol changes.

>From what I can tell, gcc6 is not linked to the build yet, but it
would also require a similar patch, probably closer to what was
committed upstream.

> 
> > gfortran6.0 \
> > gcj 4.0 \
> > gcj-tools   4.0 \
> > Index: patches/patch-gcc_config_i386_i386_c
> > ===
> > RCS file: /cvs/ports/lang/gcc/4.9/patches/patch-gcc_config_i386_i386_c,v
> > retrieving revision 1.4
> > diff -u -p -u -r1.4 patch-gcc_config_i386_i386_c
> > --- patches/patch-gcc_config_i386_i386_c1 Sep 2016 17:30:33 -   
> > 1.4
> > +++ patches/patch-gcc_config_i386_i386_c6 Jun 2017 15:10:51 -
> > @@ -1,6 +1,6 @@
> >  $OpenBSD: patch-gcc_config_i386_i386_c,v 1.4 2016/09/01 17:30:33 pascal 
> > Exp $
> >  gcc/config/i386/i386.c.origMon Aug  1 18:03:41 2016
> > -+++ gcc/config/i386/i386.c Sat Aug  6 19:19:04 2016
> > +--- gcc/config/i386/i386.c.origMon Aug  1 12:03:41 2016
> >  gcc/config/i386/i386.c Sun Jun  4 04:30:01 2017
> >  @@ -2307,6 +2307,8 @@ struct ix86_frame
> > HOST_WIDE_INT reg_save_offset;
> > HOST_WIDE_INT sse_reg_save_offset;
> > @@ -18,13 +18,22 @@ $OpenBSD: patch-gcc_config_i386_i386_c,v
> > frame->nregs = ix86_nsaved_regs ();
> > frame->nsseregs = ix86_nsaved_sseregs ();
> >   
> > -@@ -10903,6 +10906,9 @@ ix86_expand_prologue (void)
> > -   m->fs.sp_offset = INCOMING_FRAME_SP_OFFSET;
> > +@@ -10904,6 +10907,9 @@ ix86_expand_prologue (void)
> > m->fs.realigned = true;
> >   }
> > -+
> > + 
> >  +  if (warn_stack_larger_than && frame.local_size > stack_larger_than_size)
> >  +warning (OPT_Wstack_larger_than_, "stack usage is %ld bytes", 
> > frame.local_size);
> > - 
> > ++
> > int_registers_saved = (frame.nregs == 0);
> > sse_registers_saved = (frame.nsseregs == 0);
> > + 
> > +@@ -26860,7 +26866,7 @@ ix86_local_alignment (tree exp, enum machine_mode 
> > mode
> > +  != TYPE_MAIN_VARIANT (va_list_type_node)))
> &g

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Mon, Jun 05, 2017 at 11:58:43AM -0400, Bryan Steele wrote:
> This will probably require library and ports bumps

I'm not sure where to go from here, bumping estdc++ should take
care of any ports using eg++, but there are still a few ports
using egcc for emulated TLS support.

What about the other shared libraries, gfortran, objc.. or other
bootstraps? The installed libssp is unused, and uses gets()..

This is something I wish someone else could help me with as I
don't normally do ports builds myself..

Not sure if this SQL query is correct.. at least some of these
may actually be missing an explict stdc++ wantlib? Qt5?

Halp?

-Bryan.

Index: Makefile
===
RCS file: /cvs/ports/lang/gcc/4.9/Makefile,v
retrieving revision 1.47
diff -u -p -u -r1.47 Makefile
--- Makefile4 Mar 2017 21:59:55 -   1.47
+++ Makefile6 Jun 2017 15:10:51 -
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 arm hppa i386 mip
 DPB_PROPERTIES = parallel
 
 V = 4.9.4
-REVISION = 4
+REVISION = 5
 FULL_VERSION = $V
 FULL_PKGVERSION = $V
 
@@ -39,7 +39,7 @@ PKGNAME-objc =  gobjc-${FULL_PKGVERSION}
 PKGNAME-ada =   gnat-${FULL_PKGVERSION}
 PKGSPEC-main = gcc->=4.9,<4.10
 
-SHARED_LIBS =  estdc++ 17.0 \
+SHARED_LIBS =  estdc++ 18.0 \
gfortran6.0 \
gcj 4.0 \
gcj-tools   4.0 \
Index: patches/patch-gcc_config_i386_i386_c
===
RCS file: /cvs/ports/lang/gcc/4.9/patches/patch-gcc_config_i386_i386_c,v
retrieving revision 1.4
diff -u -p -u -r1.4 patch-gcc_config_i386_i386_c
--- patches/patch-gcc_config_i386_i386_c1 Sep 2016 17:30:33 -   
1.4
+++ patches/patch-gcc_config_i386_i386_c6 Jun 2017 15:10:51 -
@@ -1,6 +1,6 @@
 $OpenBSD: patch-gcc_config_i386_i386_c,v 1.4 2016/09/01 17:30:33 pascal Exp $
 gcc/config/i386/i386.c.origMon Aug  1 18:03:41 2016
-+++ gcc/config/i386/i386.c Sat Aug  6 19:19:04 2016
+--- gcc/config/i386/i386.c.origMon Aug  1 12:03:41 2016
 gcc/config/i386/i386.c Sun Jun  4 04:30:01 2017
 @@ -2307,6 +2307,8 @@ struct ix86_frame
HOST_WIDE_INT reg_save_offset;
HOST_WIDE_INT sse_reg_save_offset;
@@ -18,13 +18,22 @@ $OpenBSD: patch-gcc_config_i386_i386_c,v
frame->nregs = ix86_nsaved_regs ();
frame->nsseregs = ix86_nsaved_sseregs ();
  
-@@ -10903,6 +10906,9 @@ ix86_expand_prologue (void)
-   m->fs.sp_offset = INCOMING_FRAME_SP_OFFSET;
+@@ -10904,6 +10907,9 @@ ix86_expand_prologue (void)
m->fs.realigned = true;
  }
-+
+ 
 +  if (warn_stack_larger_than && frame.local_size > stack_larger_than_size)
 +warning (OPT_Wstack_larger_than_, "stack usage is %ld bytes", 
frame.local_size);
- 
++
int_registers_saved = (frame.nregs == 0);
sse_registers_saved = (frame.nsseregs == 0);
+ 
+@@ -26860,7 +26866,7 @@ ix86_local_alignment (tree exp, enum machine_mode mode
+  != TYPE_MAIN_VARIANT (va_list_type_node)))
+  && TYPE_SIZE (type)
+  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
+- && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 16
++ && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 128
+  || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 128)
+   return 128;
+ }


SELECT FULLPKGPATH,MODULES,WANTLIB FROM Ports WHERE MODULES LIKE '%gcc4%' AND WA
NTLIB NOT LIKE '%CXX%' AND WANTLIB NOT LIKE '%stdc++%';

archivers/zstd|gcc4|c pthread z
astro/wcslib|gcc4 gnu|c cfitsio m gfortran>=3 quadmath
audio/audacious|devel/gettext gcc4 gnu|atk-1.0 c cairo cairo-gobject fontconfig 
freetype gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gtk-3 
guess m pango-1.0 pangocairo-1.0 pangoft2-1.0 pthread z intl>=5 iconv>=6
audio/jack|gcc4 gnu|c celt0>=1 db m pthread readline samplerate sndfile sndio 
termcap FLAC ogg vorbis vorbisenc
audio/sox|gcc4 gnu|c m z sndio FLAC gsm mad id3tag mp3lame ogg sndfile vorbis 
vorbisenc vorbisfile opencore-amrnb opencore-amrwb opus opusfile twolame 
wavpack iconv png
databases/mdbtools,-main|gcc4 devel/gettext x11/gnome gnu|c glib-2.0 iconv 
iodbcinst pthread readline
databases/mdbtools,-gmdb|gcc4 devel/gettext x11/gnome gnu|intl>=5 iconv>=6 c 
gdk-x11-2.0 gdk_pixbuf-2.0 glade-2.0 glib-2.0 gnome-2 gnomeui-2 gobject-2.0 
gtk-x11-2.0 mdb mdbsql pango-1.0 pthread
databases/postgresql,-pg_upgrade|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 pq>=4
databases/postgresql,-plpython|lang/python gcc4 gnu|c m pthread util  python2.7
databases/postgresql,-contrib|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 pq>=4
databases/postgresql,-server|lang/python gcc4 gnu|c crypto m readline ssl 
termcap z xml2 perl pq>=4
databases/postgresql,-main|lang/python gcc4 gnu|c crypto m readline ssl termcap 
z xml2
databases/

Re: PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

On Sun, Jun 04, 2017 at 04:40:17AM -0400, Bryan Steele wrote:
> "As Shmuel reported in
> <https://gcc.gnu.org/ml/gcc-help/2017-03/msg9.html>,
> on x86-64 small structures in automatic storage are aligned to 16 bytes.
> This seems to be because of a mix-up between bits and bytes in the i386
> target code.
> 
> * config/i386/i386.c (ix86_local_alignment): Align most aggregates
> of 16 bytes and more to 16 bytes, not those of 16 bits and more."
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6
> 
> It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
> and committed by martynas@ to base gcc4 shortly later.
> 
> http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
> http://marc.info/?l=openbsd-cvs=139895377300712=2
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3=1.4=h
> 
> -Bryan.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/gcc/4.9/Makefile,v
> retrieving revision 1.47
> diff -u -p -u -r1.47 Makefile
> --- Makefile  4 Mar 2017 21:59:55 -   1.47
> +++ Makefile  4 Jun 2017 08:36:12 -
> @@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 arm hppa i386 mip
>  DPB_PROPERTIES = parallel
>  
>  V = 4.9.4
> -REVISION = 4
> +REVISION = 5
>  FULL_VERSION = $V
>  FULL_PKGVERSION = $V
>  
> Index: patches/patch-gcc_config_i386_i386_c
> ===
> RCS file: /cvs/ports/lang/gcc/4.9/patches/patch-gcc_config_i386_i386_c,v
> retrieving revision 1.4
> diff -u -p -u -r1.4 patch-gcc_config_i386_i386_c
> --- patches/patch-gcc_config_i386_i386_c  1 Sep 2016 17:30:33 -   
> 1.4
> +++ patches/patch-gcc_config_i386_i386_c  4 Jun 2017 08:36:12 -
> @@ -1,6 +1,6 @@
>  $OpenBSD: patch-gcc_config_i386_i386_c,v 1.4 2016/09/01 17:30:33 pascal Exp $
>  gcc/config/i386/i386.c.orig  Mon Aug  1 18:03:41 2016
> -+++ gcc/config/i386/i386.c   Sat Aug  6 19:19:04 2016
> +--- gcc/config/i386/i386.c.orig  Mon Aug  1 12:03:41 2016
>  gcc/config/i386/i386.c   Sun Jun  4 04:30:01 2017
>  @@ -2307,6 +2307,8 @@ struct ix86_frame
> HOST_WIDE_INT reg_save_offset;
> HOST_WIDE_INT sse_reg_save_offset;
> @@ -18,13 +18,22 @@ $OpenBSD: patch-gcc_config_i386_i386_c,v
> frame->nregs = ix86_nsaved_regs ();
> frame->nsseregs = ix86_nsaved_sseregs ();
>   
> -@@ -10903,6 +10906,9 @@ ix86_expand_prologue (void)
> -   m->fs.sp_offset = INCOMING_FRAME_SP_OFFSET;
> +@@ -10904,6 +10907,9 @@ ix86_expand_prologue (void)
> m->fs.realigned = true;
>   }
> -+
> + 
>  +  if (warn_stack_larger_than && frame.local_size > stack_larger_than_size)
>  +warning (OPT_Wstack_larger_than_, "stack usage is %ld bytes", 
> frame.local_size);
> - 
> ++
> int_registers_saved = (frame.nregs == 0);
> sse_registers_saved = (frame.nsseregs == 0);
> + 
> +@@ -26860,7 +26866,7 @@ ix86_local_alignment (tree exp, enum machine_mode 
> mode
> +!= TYPE_MAIN_VARIANT (va_list_type_node)))
> +&& TYPE_SIZE (type)
> +&& TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
> +-   && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 16
> ++   && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 128
> +|| TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 128)
> + return 128;
> + }

This will probably require library and ports bumps, but here is
an example to better demonstrate the issue:

#include 
#include 

int main()
{
char buf[15];
strcpy(buf, "1234567890abcdef");
printf("%s", buf);
}

# base gcc 4.2.1

$ gcc ssp-test.c -o ssp-test
/tmp//cc6vEhU3.o: In function `main':
ssp-test.c:(.text+0x21): warning: warning: strcpy() is almost always misused, 
please use strlcpy()
$ ./ssp-test
Abort trap

# base clang 4.0.0

$ /usr/bin/clang ssp-test.c -o ssp-test-clang1
/tmp/ssp-test-3faff4.o: In function `main':
ssp-test.c:(.text+0x31): warning: warning: strcpy() is almost always misused, pl
ease use strlcpy()
$ ./ssp-test-clang1
Abort trap

# ports clang 4.0.0

$ /usr/local/bin/clang ssp-test.c -o ssp-test-clang2
/tmp/ssp-test-f372af.o: In function `main':
ssp-test.c:(.text+0x31): warning: warning: strcpy() is almost always misused, pl
ease use strlcpy()
$ ./ssp-test-clang2
Abort trap

# ports egcc 4.9.4

$ egcc ssp-test.c -o ssp-test-egcc # ???
$ ./ssp-test-egcc
1234567890abcdef $
$ egcc -fno-builtin-strcpy ssp-test.c -o ssp-test-egcc
/tmp//ccU4UBvd.o: In function `main':
ssp-test.c:(.text+0x24): warning: warning: strcpy() is almost always misused, 
please use strlcpy()
$ ./ssp-test-egcc
1234567890abcdef $
$ readelf -a ssp-test-egcc | grep smash
00200fc8  000f0007 R_X86_64_JUMP_SLO  
__stack_smash_handler + 0
15:    281 FUNCGLOBAL DEFAULT  UND __stack_smash_handler
30:    281 FUNCGLOBAL DEFAULT  UND 
__stack_smash_handler$

PATCH: Fix SSP on amd64 for ports gcc 4.9

[Bryan Steele]

"As Shmuel reported in
,
on x86-64 small structures in automatic storage are aligned to 16 bytes.
This seems to be because of a mix-up between bits and bytes in the i386
target code.

* config/i386/i386.c (ix86_local_alignment): Align most aggregates
of 16 bytes and more to 16 bytes, not those of 16 bits and more."

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b44e9be23d38be8997ae64d7509ac22cb4c556d6

It might be worth fixing this in ports gcc 4.9, found by tedu@ in 2014
and committed by martynas@ to base gcc4 shortly later.

http://www.tedunangst.com/flak/post/my-stack-protector-wasnt-working
http://marc.info/?l=openbsd-cvs=139895377300712=2
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/gcc/gcc/config/i386/i386.c.diff?r1=1.3=1.4=h

-Bryan.

Index: Makefile
===
RCS file: /cvs/ports/lang/gcc/4.9/Makefile,v
retrieving revision 1.47
diff -u -p -u -r1.47 Makefile
--- Makefile4 Mar 2017 21:59:55 -   1.47
+++ Makefile4 Jun 2017 08:36:12 -
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64 arm hppa i386 mip
 DPB_PROPERTIES = parallel
 
 V = 4.9.4
-REVISION = 4
+REVISION = 5
 FULL_VERSION = $V
 FULL_PKGVERSION = $V
 
Index: patches/patch-gcc_config_i386_i386_c
===
RCS file: /cvs/ports/lang/gcc/4.9/patches/patch-gcc_config_i386_i386_c,v
retrieving revision 1.4
diff -u -p -u -r1.4 patch-gcc_config_i386_i386_c
--- patches/patch-gcc_config_i386_i386_c1 Sep 2016 17:30:33 -   
1.4
+++ patches/patch-gcc_config_i386_i386_c4 Jun 2017 08:36:12 -
@@ -1,6 +1,6 @@
 $OpenBSD: patch-gcc_config_i386_i386_c,v 1.4 2016/09/01 17:30:33 pascal Exp $
 gcc/config/i386/i386.c.origMon Aug  1 18:03:41 2016
-+++ gcc/config/i386/i386.c Sat Aug  6 19:19:04 2016
+--- gcc/config/i386/i386.c.origMon Aug  1 12:03:41 2016
 gcc/config/i386/i386.c Sun Jun  4 04:30:01 2017
 @@ -2307,6 +2307,8 @@ struct ix86_frame
HOST_WIDE_INT reg_save_offset;
HOST_WIDE_INT sse_reg_save_offset;
@@ -18,13 +18,22 @@ $OpenBSD: patch-gcc_config_i386_i386_c,v
frame->nregs = ix86_nsaved_regs ();
frame->nsseregs = ix86_nsaved_sseregs ();
  
-@@ -10903,6 +10906,9 @@ ix86_expand_prologue (void)
-   m->fs.sp_offset = INCOMING_FRAME_SP_OFFSET;
+@@ -10904,6 +10907,9 @@ ix86_expand_prologue (void)
m->fs.realigned = true;
  }
-+
+ 
 +  if (warn_stack_larger_than && frame.local_size > stack_larger_than_size)
 +warning (OPT_Wstack_larger_than_, "stack usage is %ld bytes", 
frame.local_size);
- 
++
int_registers_saved = (frame.nregs == 0);
sse_registers_saved = (frame.nsseregs == 0);
+ 
+@@ -26860,7 +26866,7 @@ ix86_local_alignment (tree exp, enum machine_mode mode
+  != TYPE_MAIN_VARIANT (va_list_type_node)))
+  && TYPE_SIZE (type)
+  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
+- && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 16
++ && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 128
+  || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 128)
+   return 128;
+ }

Re: possible chromium regression on -current

[Bryan Steele]

On Wed, Feb 22, 2017 at 11:35:24AM +, Dimitris Papastamos wrote:
> Hi everyone,
> 
> I think at some point in the last week a possible chromium regression
> was introduced.
> 
> Youtube videos give a playback error.  This is what I get in the log:
> 
> [11087:-105893312:0221/190453.466753:ERROR:sync_control_vsync_provider.cc(144)]
> glXGetSyncValuesOML should not return TRUE with a media stream counter
> of 0.
> [70895:441591864:0221/190454.467559:ERROR:network_interfaces_posix.cc(63)]
> Not implemented reached in bool
> net::GetNetworkList(NetworkInterfaceList *, int)
> [97863:574132800:0221/190457.039780:ERROR:render_media_log.cc(25)]
> MediaEvent: PIPELINE_ERROR pipeline: initialization failed
> [11087:-105893312:0221/190457.133204:ERROR:sync_control_vsync_provider.cc(144)]
> glXGetSyncValuesOML should not return TRUE with a media stream counter
> of 0.
> [97863:574132800:0221/190457.459204:ERROR:render_media_log.cc(25)]
> MediaEvent: PIPELINE_ERROR pipeline: initialization failed
> [70895:441591864:0221/190500.474199:ERROR:network_interfaces_posix.cc(63)]
> Not implemented reached in bool
> net::GetNetworkList(NetworkInterfaceList *, int)
> 
> Any ideas?

I noticed this too and mentioned it on a ports dev chat, I remember
it working a few weeks ago. But I'm not sure if it stopped working
before or after the 56.0.2924.87 update..

It appears to affect only some HTML5 video streaming sites, like
Youtube and Twitch, but embedded  still works. It doesn't
appear to be drm(4) obviously related either as WebGL demos work
fine.

At least a few people said it still works for them, so perhaps
it's a certain hardware combination that's causing this?

-Bryan.

radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3000" rev 0x00
drm0 at radeondrm0

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD RS780 (DRM 2.29.0 / 6.0) (0x9616)
Version: 13.0.3
Accelerated: yes
Video memory: 512MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.1
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RS780 (DRM 2.29.0 / 6.0)
OpenGL core profile version string: 3.1 (Core Profile) Mesa 13.0.3
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, 
GL_AMD_performance_monitor, 

Re: Update emulators/mednafen 0.9.38.7 -> 0.9.39.2

[Bryan Steele]

On Wed, Oct 19, 2016 at 10:41:27PM -0700, Jeremy Evans wrote:
> Update to the latest medafen release.  The major change in this update
> is the addition of Saturn support, which I tested and does appear to
> work (at least with Shanghai Triple Threat).
> 
> Changelog:
> 
> Added experimental Sega Saturn emulation.
> 
> Low-accuracy "snes_faust" SNES emulation module is now compiled in and
> available by default(but not used by default, except for SPC playback).
> 
> The version is now displayed in the upper right corner of the F1 help
> screen.
> 
> Scrolling in the netplay and cheat consoles is now done in visible line
> units, instead of internal line units as before, and when a console is
> not scrolled all the way down, a green indicator arrow will now be drawn
> in the lower right corner.
> 
> Revamped the layout of the debugger's memory editor.
> 
> MD: Replaced old 68K emulator with new 68K emulator developed for Saturn
> emulation. Fixes major issues in "Double Clutch", "James Pond 3", and
> "Sub-Terrania". However, timing is currently a bit off with the new 68K
> emulation code, so there may be some regressions.
> 
> MD: Implemented kludge to fix a startup lockup in "Turrican".
> 
> NES: Implemented kludge to fix a minor Zelda 2 title screen glitch, a
> status bar glitch in Burai Fighter, and scrolling in the second stage of
> The Young Indiana Jones Chronicles.
> 
> NES: Enabled SSE2 support in the audio resampler(though not used on all
> CPUs with SSE2 support, mostly just newer ones).
> 
> NES, PCE, PC-FX: Added ARM NEON support to the audio resamplers(when
> compiled with -mfpu=neon or similar).
> 
> PCE, PC-FX: Added AVX support to the audio resampler.
> 
> PS1: Enabled emulation of a rarely-used CDC feature; fixes lockup bug in
> "Fantastic Pinball Kyutenkai".
> 
> PS1: Reordered CPU class data layout for a small performance boost on
> ARM CPUs.
> 
> SNES: Updated libco, for ARM support.
> 
> 
> Only significant ports changes are the setting of USE_WXNEEDED, as
> apparently mednafen uses W|X mappings, pointed out by brynet@.  I also
> had to remove the __inline code from the embedded quicklz to get this
> new version to compile.
> 
> Tested briefly on amd64, compiles on i386.  I'll try to do the hard work
> of additional testing this weekend, but assuming no problems I'll commit
> unless I hear objections.
> 
> Thanks,
> Jeremy
>
> ...

Great! :-)

It works well enough again for me to play SNES SMW. It takes
forever to compile though, heh.

ok brynet@, if it helps (tested on amd64)

Re: Cruft: imake

[Bryan Steele]

On Fri, Sep 02, 2016 at 12:56:50PM +0200, Christian Weisgerber wrote:
> Now that gtk1 has been removed, we need to give jasper@ a new goal
> in life.  I think a good candidate is imake.  Anything that still
> uses imake for configuration is likely old cruft that has been
> barely maintained, if at all, since the late 1990s.
> 
> Here's a list of ports that use CONFIGURE_STYLE=imake:
>
> ... 
> sysutils/xbatt
> sysutils/xbattbar

At least these two are still useful.

Re: [patch] archivers/libarchive ioctl woes

[Bryan Steele]

On Tue, Mar 22, 2016 at 10:30:51PM +0100, Matthias Kilian wrote:
> Hi,
> 
> On Tue, Mar 22, 2016 at 04:20:34PM -0400, Bryan Steele wrote:
> > It seems libarchive/bsdtar is picking up headers from e2fsprogs if
> > installed, specifically, headers related to Linux file ioctls.
> > 
> > ./ext2_fs.h:#define EXT2_IOC_GETFLAGS   _IOR('f', 1, long)
> > 
> > Here's a patch so that it stops trying random ioctls that
> > fortunately all fail with our kernel.
> > 
> > .. might be worth checking other ports.
> 
> Well, no objections against your libarchive diff, but wouldn't it
> be better to patch the offending header in e2fsprogs and shield
> those #define's with #ifndef __OpenBSD__?
> 
> If noone beats me, I'll give it a try in a day or two.
> 
> Ciao,
>   Kili
> 
> ps: i mean something like this (completely untested for now):
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/e2fsprogs/Makefile,v
> retrieving revision 1.36
> diff -u -p -r1.36 Makefile
> --- Makefile  15 Dec 2015 10:52:02 -  1.36
> +++ Makefile  22 Mar 2016 21:29:19 -
> @@ -3,7 +3,7 @@
>  COMMENT= utilities to manipulate ext2 filesystems
>  
>  DISTNAME=e2fsprogs-1.42.12
> -REVISION=1
> +REVISION=2
>  CATEGORIES=  sysutils devel
>  SHARED_LIBS= blkid   0.0 \
>   com_err 21.0 \
> Index: patches/patch-lib_ext2fs_ext2_fs_h
> ===
> RCS file: patches/patch-lib_ext2fs_ext2_fs_h
> diff -N patches/patch-lib_ext2fs_ext2_fs_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-lib_ext2fs_ext2_fs_h22 Mar 2016 21:29:19 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +--- lib/ext2fs/ext2_fs.h.origSat Aug  2 22:26:22 2014
>  lib/ext2fs/ext2_fs.h Tue Mar 22 22:26:56 2016
> +@@ -344,6 +344,7 @@ struct ext4_new_group_input {
> + #define _IOT_ext2_new_group_input _IOT (_IOTS(__u32), 5, _IOTS(__u16), 2, 
> 0, 0)
> + #endif
> + 
> ++#ifndef __OpenBSD__
> + #define EXT2_IOC_GETFLAGS   _IOR('f', 1, long)
> + #define EXT2_IOC_SETFLAGS   _IOW('f', 2, long)
> + #define EXT2_IOC_GETVERSION _IOR('v', 1, long)
> +@@ -354,6 +355,7 @@ struct ext4_new_group_input {
> + #define EXT2_IOC_GROUP_ADD  _IOW('f', 8,struct ext2_new_group_input)
> + #define EXT4_IOC_GROUP_ADD  _IOW('f', 8,struct ext4_new_group_input)
> + #define EXT4_IOC_RESIZE_FS  _IOW('f', 16, __u64)
> ++#endif
> + 
> + /*
> +  * Structure of an inode on the disk

This works too, whichever is preferred. Or both. :-)

ok brynet@ if it helps.

[patch] archivers/libarchive ioctl woes

[Bryan Steele]

It seems libarchive/bsdtar is picking up headers from e2fsprogs if
installed, specifically, headers related to Linux file ioctls.

./ext2_fs.h:#define EXT2_IOC_GETFLAGS   _IOR('f', 1, long)

Here's a patch so that it stops trying random ioctls that
fortunately all fail with our kernel.

.. might be worth checking other ports.

Index: Makefile
===
RCS file: /cvs/ports/archivers/libarchive/Makefile,v
retrieving revision 1.28
diff -u -p -u -r1.28 Makefile
--- archivers/libarchive/Makefile   11 Mar 2016 19:59:11 -  1.28
+++ archivers/libarchive/Makefile   22 Mar 2016 20:12:23 -
@@ -3,7 +3,7 @@
 COMMENT=   multi-format archive and compression library
 
 DISTNAME=  libarchive-3.1.2
-REVISION=  0
+REVISION=  1
 SHARED_LIBS=   archive 8.2 # 14.2
 CATEGORIES=archivers
 HOMEPAGE=  http://www.libarchive.org/
@@ -27,7 +27,9 @@ CONFIGURE_ARGS+=--without-lzmadec # old 
 CONFIGURE_ARGS+=--without-nettle   # prefer OpenSSL
 CONFIGURE_ARGS+=--without-xml2 # expat suffices
 CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
-   LDFLAGS="-L${LOCALBASE}/lib"
+   LDFLAGS="-L${LOCALBASE}/lib" \
+   ac_cv_header_ext2fs_ext2_fs_h=no \
+   ac_cv_have_decl_EXT2_IOC_GETFLAGS=no
 MODGNU_CONFIG_GUESS_DIRS=${WRKSRC}/build/autoconf
 
 # Regression tests known to fail due to locale issues

Re: nginx woes

[Bryan Steele]

On Sat, Mar 28, 2015 at 01:02:25PM +0100, frantisek holop wrote:
 
 so i have just been bitten by the implicitly
 included openbsd chroot patch for nginx.
 
 the issue is, that i _remembered_ there is a
 parameter to turn it off, but upon doing
 man nginx, i could not find it. then i proceeded
 to read the pkg-readme as well, and not a
 word about it.  yes, it is in nginx -h at least.
 
 i think this makes the nginx port very confusing.
 
 so first of all, would it be possible to add
 the needed bits to the man page?  i would also
 welcome it very much if pkg-readme's by default
 listed ANY intrusive local openbsd changes
 like this.  and make this a hard rule.
 
 and second, i was wondering if it was possible
 to create an nginx flavor without the chroot patch.
 
 sometimes i just want a vanilla nginx, just like
 upstream, so i am not going to be bitten by this
 when i deploy stuff to linux servers...
 actually, i think it should be the other way
 around, nginx-chroot being a flavor, and not
 vice versa
 
 -f
 -- 
 i'm not religious.  god willing, i never will be.

The chroot functionality is a sane default for a webserver, and people
upgrading from the former base nginx to ports nginx might be suprised
that it is no longer doing so. I only agree that documentation could be
improved here.

Your FastCGI applications can happily be configured somewhere outside
of nginx's chroot..

-Bryan.

Re: remove print/epdfview?

[Bryan Steele]

On Mon, Dec 15, 2014 at 01:09:11PM +0100, Matthias Kilian wrote:
 Hi,
 
 the HOMEPAGE for print/epdfview is dead, there was no update since
 2011, and, most important, it doesn't display anything, at least
 for me.
 
 So is it be ok to remove it?
 
 Ciao,
   Kili

I think epdfview has been broken for awhile now, there are patches
floating around for various Linux distros, but as you said it is
dead upstream.

It should probaby be removed, unless someone is actually using it? I've
switched to mupdf, mozilla's pdf.js (..also works in chrome).

So.. ok brynet@ :-)

-Bryan.

Re: please remove the procmail port

[Bryan Steele]

On Tue, Nov 18, 2014 at 10:32:58PM +0100, Landry Breuil wrote:
 On Tue, Nov 18, 2014 at 10:01:33PM +0100, frantisek holop wrote:
  Philip Guenther, 18 Nov 2014 12:42:
   Executive summary: delete the procmail port; the code is not safe and 
   should not be used as a basis for any further work.
  
  just for the record, what is the alternative
  you would recommend?
 
 fdm, what else ?
 
 Landry

fdm is quite nice, but nicm@ hasn't rolled a release in a bit. There
are a few patches that should probably be added to the port.

http://sourceforge.net/p/fdm/mailman/message/30918981/

http://sourceforge.net/p/fdm/mailman/fdm-cvs/

CC'd nicm@,
-Bryan.

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2012/04/03 20:19:16

Modified files:
sysutils/xbattbar: Makefile 
sysutils/xbattbar/patches: patch-xbattbar_c 

Log message:
Add an option for displaying timedate to xbattbar (-T), from Alexander Polakov.

ok sthen@

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2012/04/03 20:35:15

Modified files:
sysutils/xbattbar: Makefile 
Added files:
sysutils/xbattbar/patches: patch-xbattbar_man 

Log message:
Whoops, add the man page patch for xbattbar.

CVS: cvs.openbsd.org: ports

[Bryan Steele]

CVSROOT:/cvs
Module name:ports
Changes by: bry...@cvs.openbsd.org  2012/01/31 16:24:00

Modified files:
geo/openbsd-developers: Makefile 
geo/openbsd-developers/files: OpenBSD 

Log message:
Add my coordinates, icbm's away!

ok sthen@