from:"Tobias Heider"

Re: Update m1n1 and apple-boot firmware

2024-05-18 Thread Tobias Heider




On May 18, 2024 10:56:14 AM GMT+02:00, Mark Kettenis  
wrote:
>> From: Stuart Henderson 
>> Date: Fri, 17 May 2024 20:49:33 +0100
>> 
>> Better hold off for now, seems there's a display init problem on M1 (at
>> least desktop)
>
>Fixed in m1n1 1.4.14.

also ok

>
>> On 17 May 2024 20:20:47 Mark Kettenis  wrote:
>> 
>>  https://social.treehouse.systems/@AsahiLinux/112454079096607233
>> 
>>  This updates m1n1 to a version that has the mentioned workaround.
>>  Once this is in, we should make the new firmware available, probably
>>  also for the 7.5 release.
>> 
>>  ok?
>> 
>
>
>Index: sysutils/m1n1/Makefile
>===
>RCS file: /cvs/ports/sysutils/m1n1/Makefile,v
>retrieving revision 1.14
>diff -u -p -r1.14 Makefile
>--- sysutils/m1n1/Makefile 8 Jan 2024 19:57:24 -   1.14
>+++ sysutils/m1n1/Makefile 18 May 2024 08:53:49 -
>@@ -4,7 +4,7 @@ COMMENT=   Bootloader for Apple Silicon
> 
> GH_ACCOUNT=   AsahiLinux
> GH_PROJECT=   m1n1
>-GH_TAGNAME=   v1.4.11
>+GH_TAGNAME=   v1.4.14
> 
> CATEGORIES=   sysutils
> HOMEPAGE= https://github.com/AsahiLinux/m1n1
>Index: sysutils/m1n1/distinfo
>===
>RCS file: /cvs/ports/sysutils/m1n1/distinfo,v
>retrieving revision 1.7
>diff -u -p -r1.7 distinfo
>--- sysutils/m1n1/distinfo 8 Jan 2024 19:57:24 -   1.7
>+++ sysutils/m1n1/distinfo 18 May 2024 08:53:49 -
>@@ -1,2 +1,2 @@
>-SHA256 (m1n1-1.4.11.tar.gz) = InZEkH2ElVuUIaU3F7PrtA36HZDHdC4oRjJUeAOETY4=
>-SIZE (m1n1-1.4.11.tar.gz) = 825748
>+SHA256 (m1n1-1.4.14.tar.gz) = YYcd0tJlMbTgf5s9sFFrWA+DbDXhYt5HmbTlVuhpgRk=
>+SIZE (m1n1-1.4.14.tar.gz) = 837044
>Index: sysutils/firmware/apple-boot/Makefile
>===
>RCS file: /cvs/ports/sysutils/firmware/apple-boot/Makefile,v
>retrieving revision 1.17
>diff -u -p -r1.17 Makefile
>--- sysutils/firmware/apple-boot/Makefile  31 Mar 2024 19:14:06 -  
>1.17
>+++ sysutils/firmware/apple-boot/Makefile  18 May 2024 08:53:49 -
>@@ -1,5 +1,5 @@
> FW_DRIVER=apple-boot
>-FW_VER=   1.3
>+FW_VER=   1.4
> 
> WRKDIST=  ${WRKDIR}
> DISTFILES=
>@@ -9,7 +9,7 @@ DISTFILES=
> PERMIT_PACKAGE= firmware
> PERMIT_DISTFILES= Yes
> 
>-BUILD_DEPENDS=m1n1-=1.4.11:sysutils/m1n1:build \
>+BUILD_DEPENDS=m1n1-=1.4.14:sysutils/m1n1:build \
>   u-boot-asahi-=2024.01p0:sysutils/u-boot-asahi:build
> 
> ASAHI_BUILD=  ${WRKSRC}/sysutils/u-boot-asahi/u-boot-*/build
>

Re: Update m1n1 and apple-boot firmware

2024-05-17 Thread Tobias Heider

On May 17, 2024 9:49:33 PM GMT+02:00, Stuart Henderson  
wrote:
>Better hold off for now, seems there's a display init problem on M1 (at least 
>desktop)
>

AFAIU this issue is caused by updating the stage 1, so it only happens when you 
rerun the original installer. Updating the port should not be a problem since 
that is used to update stage 2 only.

ok tobhe@

Re: HOTFIX games/{bugdom,bugdom2,nanosaur,mightymike,ottomatic,billyfrontier} on sparc64

2024-03-13 Thread Tobias Heider via ports




On March 13, 2024 7:24:26 PM GMT+01:00, Stuart Henderson via ports 
 wrote:
>On 2024/03/13 12:31, izder456 via ports wrote:
>> Hey ports@-
>> 
>> Looks like these ports I take MAINTAINER on fail on sparc64 with the
>> same u8string error, which AFAIK is a C++20 thing.
>> 
>> From what it looks like, sparc64 doesn't have a C++20 compiler, so they
>> unfortunately will be broken on that arch.
>> 
>> Attached are diffs that adds BROKEN-sparc64 to those ports.
>
>I think something like this would be preferable
>
># requires C++20
>COMPILER = base-clang
>

but then you could also add ports clang and ports gcc right?
they should also support newer c++ versions

Re: powerpc bulk build report

2024-03-10 Thread Tobias Heider

On Sun, Mar 10, 2024 at 06:26:04PM +0100, Omar Polo wrote:
> On 2024/03/03 20:37:45 -0700, gkoeh...@openbsd.org wrote:
> > http://build-failures.rhaalovely.net/powerpc/2024-02-07/games/nanosaur2.log
> 
> : 
> /usr/obj/ports/nanosaur2-2.1.0/Nanosaur2-2.1.0/Source/Headers/ogl_support.h:122:2:
> : error: unknown type name 'vector'
> : vector float v[4];
> : ^
> : 1 error generated.
> 
> I missed this failure, thanks izzy for prodding me.  I don't have a
> powerpc to test this, but it appears if I'm grepping correctly that this
> field is never used.
> 
> (no bump needed since it only fixes -hopefully- the build on powerpc
> where it wasn't built before.)
> 
> The alternative, if I'm reading this[0] correctly, is to sprinkle some
> #include  and -maltivec, but since it's not used I think it's
> easier to just remove it.  If it works I'll upstream this as well.
> 
> [0]: 
> https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html

I actually built and tested this a few weeks back. I just removed all the
#ifdef __ppc__ blocks. Game loads but runs with ~5 fps and crashes after
a few seconds on my powerbook G4

Do we actually support ppcs without altivec? I guess it might work better
with altivec enabled instead.

> 
> 
> Thanks!
> 
> Omar Polo
> 
> 
> Index: patches/patch-Source_Headers_ogl_support_h
> ===
> RCS file: patches/patch-Source_Headers_ogl_support_h
> diff -N patches/patch-Source_Headers_ogl_support_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-Source_Headers_ogl_support_h10 Mar 2024 17:12:47 
> -
> @@ -0,0 +1,16 @@
> +fixes "error: unknown type name 'vector'" on powerpc; the v field is
> +never used.
> +
> +Index: Source/Headers/ogl_support.h
> +--- Source/Headers/ogl_support.h.orig
>  Source/Headers/ogl_support.h
> +@@ -118,9 +118,6 @@ typedef struct
> + typedef union
> + {
> + GLfloat value[16];
> +-#if defined(__ppc__)
> +-vector float v[4];
> +-#endif
> + }OGLMatrix4x4;
> + 
> + typedef struct
>

Re: powerpc bulk build report

2024-03-10 Thread Tobias Heider

On Sun, Mar 10, 2024 at 06:55:07PM +0100, Omar Polo wrote:
> On 2024/03/10 18:42:06 +0100, Tobias Heider  wrote:
> > On Sun, Mar 10, 2024 at 06:26:04PM +0100, Omar Polo wrote:
> > > On 2024/03/03 20:37:45 -0700, gkoeh...@openbsd.org wrote:
> > > > http://build-failures.rhaalovely.net/powerpc/2024-02-07/games/nanosaur2.log
> > > 
> > > : 
> > > /usr/obj/ports/nanosaur2-2.1.0/Nanosaur2-2.1.0/Source/Headers/ogl_support.h:122:2:
> > > : error: unknown type name 'vector'
> > > : vector float v[4];
> > > : ^
> > > : 1 error generated.
> > > 
> > > I missed this failure, thanks izzy for prodding me.  I don't have a
> > > powerpc to test this, but it appears if I'm grepping correctly that this
> > > field is never used.
> > > 
> > > (no bump needed since it only fixes -hopefully- the build on powerpc
> > > where it wasn't built before.)
> > > 
> > > The alternative, if I'm reading this[0] correctly, is to sprinkle some
> > > #include  and -maltivec, but since it's not used I think it's
> > > easier to just remove it.  If it works I'll upstream this as well.
> > > 
> > > [0]: 
> > > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html
> > 
> > I actually built and tested this a few weeks back. I just removed all the
> > #ifdef __ppc__ blocks. Game loads but runs with ~5 fps and crashes after
> > a few seconds on my powerbook G4
> > 
> > Do we actually support ppcs without altivec? I guess it might work better
> > with altivec enabled instead.
> 
> If there are chances that it is playable with altivec enabled IMHO it
> would make sense to do so since the choice is between a broken game
> everywhere and something that can be played on some machines.
> 
> However, this vector doesn't seem to be used at all in the code, so I
> don't see how enabling altivec here will actually change something at
> runtime, although I might have missed something.
> 

Right, the commit history also doesn't really help. I can test it and see if it
works with just the vec removed. The other __ppc__ parts might actually work.

Re: NEW: games/oneko

2024-03-09 Thread Tobias Heider

On Fri, Mar 08, 2024 at 10:02:33PM -0600, izder456 wrote:
> 
> Hey ports@ o/,
> 
> This is a little & silly X program that has a small pixelated
> cat "neko" or optionally a dog or other characters like Beastie follow
> your cursor around.
> 
> I loosely followed the FreeBSD port as a structural reference and used
> the Arch PKGBUILD for finding `DISTFILES`. Unsure as this is my first
> `CONFIGURE = imake` port.
> 
> I want to import this.
> 
> OK? or nits b4 merge?
> 
> -- 
> -iz (they/them)
> 
> > i like to say mundane things, 
> > there are too many uninteresting things 
> > that go unnoticed.
> 
> izder456 (dot) neocities (dot) org

What's the licensing situation for oneko?
I thought it didn't have one, which could be a problem for distributing it in
ports.

Re: devel/libffi: arm64 BTI fix

2024-03-07 Thread Tobias Heider




On March 7, 2024 11:27:38 PM GMT+01:00, Mark Kettenis  
wrote:
>This one was a bit tricky as I had to adjust the offsets used in the
>instructions.  But with this lang/guile3 no longer generates SIGILL
>when running the tests.
>
>ok?

ok tobhe@

>
>
>Index: devel/libffi/Makefile
>===
>RCS file: /cvs/ports/devel/libffi/Makefile,v
>retrieving revision 1.49
>diff -u -p -r1.49 Makefile
>--- devel/libffi/Makefile  22 Nov 2023 14:18:03 -  1.49
>+++ devel/libffi/Makefile  7 Mar 2024 22:06:25 -
>@@ -1,7 +1,7 @@
> COMMENT=  Foreign Function Interface
> 
> V=3.4.4
>-REVISION= 0
>+REVISION= 1
> DISTNAME= libffi-$V
> SHARED_LIBS +=  ffi  2.0  # 9.2
> CATEGORIES=   devel
>Index: devel/libffi/patches/patch-src_aarch64_ffi_c
>===
>RCS file: /cvs/ports/devel/libffi/patches/patch-src_aarch64_ffi_c,v
>retrieving revision 1.1
>diff -u -p -r1.1 patch-src_aarch64_ffi_c
>--- devel/libffi/patches/patch-src_aarch64_ffi_c   22 Nov 2023 14:18:03 
>-  1.1
>+++ devel/libffi/patches/patch-src_aarch64_ffi_c   7 Mar 2024 22:06:25 
>-
>@@ -74,3 +74,15 @@ Index: src/aarch64/ffi.c
>  : "memory", "v16", "v17", "v18", "v19");
>  }
>  #endif
>+@@ -873,8 +885,9 @@ ffi_prep_closure_loc (ffi_closure *closure,
>+ # endif
>+ #else
>+   static const unsigned char trampoline[16] = {
>+-0x90, 0x00, 0x00, 0x58,  /* ldr  x16, tramp+16   */
>+-0xf1, 0xff, 0xff, 0x10,  /* adr  x17, tramp+0*/
>++0x5f, 0x24, 0x03, 0xd5,  /* bti  c   */
>++0x70, 0x00, 0x00, 0x58,  /* ldr  x16, tramp+16   */
>++0xd1, 0xff, 0xff, 0x10,  /* adr  x17, tramp+0*/
>+ 0x00, 0x02, 0x1f, 0xd6   /* br   x16 */
>+   };
>+   char *tramp = closure->tramp;
>

Re: security/libgcrypt: Sprinkle some ENDBR64 instructions

2024-02-22 Thread Tobias Heider




On February 22, 2024 7:56:45 PM GMT+01:00, Theo Buehler  
wrote:
>On Thu, Feb 22, 2024 at 02:57:39PM +0100, Mark Kettenis wrote:
>> > From: Renato Aguiar 
>> > Date: Wed, 21 Feb 2024 17:31:41 -0800
>> 
>> Apologies to Antoine, I forgot to CC you the first time I sent this
>> out.  Anyway, here is a new version.  Thinking about this a bit more
>> changing CFI_STARTPROC like we did on arm64 will make maintenance a
>> lot easier.  This will over-BTI, but I'm also looking at having the
>> linker remove unnecessary ENDBR64 instructions at the start of a
>> function.
>> 
>> ok?
>
>I think this is preferable, especially if you are planning to amortize
>the cost in lld.
>
>ok tb
>

oh I missed that there was a second version. ok with me too, we arrived at the 
same conclusion for arm64 after all.

Re: security/libgcrypt: Sprinkle some ENDBR64 instructions

2024-02-22 Thread Tobias Heider

On Tue, Feb 20, 2024 at 01:11:35PM +0100, Mark Kettenis wrote:
> I probably could have done this by changing CFI_STARTPROC, like on
> arm64.  But that would "over-BTI" and there is a benefit in trying to
> avoid that on amd64.
> 
> Let me know what you think.

Looks ok to me. Hard to tell if that covers everything but I think that's
fine. If anything is missing people will complain and we fix it.

> 
> 
> Index: security/libgcrypt/Makefile
> ===
> RCS file: /cvs/ports/security/libgcrypt/Makefile,v
> retrieving revision 1.93
> diff -u -p -r1.93 Makefile
> --- security/libgcrypt/Makefile   20 Nov 2023 16:53:17 -  1.93
> +++ security/libgcrypt/Makefile   20 Feb 2024 11:27:18 -
> @@ -6,7 +6,7 @@ USE_NOEXECONLY=   Yes
>  COMMENT= crypto library based on code used in GnuPG
>  
>  DISTNAME=libgcrypt-1.10.3
> -REVISION=0
> +REVISION=1
>  
>  CATEGORIES=  security
>  
> Index: security/libgcrypt/patches/patch-cipher_arcfour-amd64_S
> ===
> RCS file: security/libgcrypt/patches/patch-cipher_arcfour-amd64_S
> diff -N security/libgcrypt/patches/patch-cipher_arcfour-amd64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ security/libgcrypt/patches/patch-cipher_arcfour-amd64_S   20 Feb 2024 
> 11:27:18 -
> @@ -0,0 +1,11 @@
> +Index: cipher/arcfour-amd64.S
> +--- cipher/arcfour-amd64.S.orig
>  cipher/arcfour-amd64.S
> +@@ -26,6 +26,7 @@
> + ELF(.type _gcry_arcfour_amd64,@function)
> + _gcry_arcfour_amd64:
> + CFI_STARTPROC()
> ++endbr64
> + ENTER_SYSV_FUNC_PARAMS_0_4
> + push%rbp
> + CFI_PUSH(%rbp)
> Index: security/libgcrypt/patches/patch-cipher_blake2b-amd64-avx2_S
> ===
> RCS file: 
> /cvs/ports/security/libgcrypt/patches/patch-cipher_blake2b-amd64-avx2_S,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-cipher_blake2b-amd64-avx2_S
> --- security/libgcrypt/patches/patch-cipher_blake2b-amd64-avx2_S  19 Jan 
> 2023 17:11:02 -  1.1
> +++ security/libgcrypt/patches/patch-cipher_blake2b-amd64-avx2_S  20 Feb 
> 2024 11:27:18 -
> @@ -17,3 +17,11 @@ Index: cipher/blake2b-amd64-avx2.S
>   .align 64
>   .globl _gcry_blake2b_transform_amd64_avx2
>   ELF(.type _gcry_blake2b_transform_amd64_avx2,@function;)
> +@@ -208,6 +210,7 @@ _gcry_blake2b_transform_amd64_avx2:
> +  *  %rdx: num_blks
> +  */
> + CFI_STARTPROC();
> ++endbr64;
> + 
> + vzeroupper;
> + 
> Index: security/libgcrypt/patches/patch-cipher_blake2s-amd64-avx_S
> ===
> RCS file: 
> /cvs/ports/security/libgcrypt/patches/patch-cipher_blake2s-amd64-avx_S,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-cipher_blake2s-amd64-avx_S
> --- security/libgcrypt/patches/patch-cipher_blake2s-amd64-avx_S   19 Jan 
> 2023 17:11:02 -  1.1
> +++ security/libgcrypt/patches/patch-cipher_blake2s-amd64-avx_S   20 Feb 
> 2024 11:27:18 -
> @@ -18,3 +18,11 @@ Index: cipher/blake2s-amd64-avx.S
>   .align 64
>   .globl _gcry_blake2s_transform_amd64_avx
>   ELF(.type _gcry_blake2s_transform_amd64_avx,@function;)
> +@@ -192,6 +193,7 @@ _gcry_blake2s_transform_amd64_avx:
> +  *  %rdx: num_blks
> +  */
> + CFI_STARTPROC();
> ++endbr64;
> + 
> + vzeroupper;
> + 
> Index: security/libgcrypt/patches/patch-cipher_blowfish-amd64_S
> ===
> RCS file: security/libgcrypt/patches/patch-cipher_blowfish-amd64_S
> diff -N security/libgcrypt/patches/patch-cipher_blowfish-amd64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ security/libgcrypt/patches/patch-cipher_blowfish-amd64_S  20 Feb 2024 
> 11:27:18 -
> @@ -0,0 +1,51 @@
> +Index: cipher/blowfish-amd64.S
> +--- cipher/blowfish-amd64.S.orig
>  cipher/blowfish-amd64.S
> +@@ -166,6 +166,7 @@ _gcry_blowfish_amd64_do_encrypt:
> +  *  %rdx: u32 *ret_xr
> +  */
> + CFI_STARTPROC();
> ++endbr64;
> + ENTER_SYSV_FUNC_PARAMS_0_4
> + 
> + movl (%rdx), RX0d;
> +@@ -197,6 +198,7 @@ _gcry_blowfish_amd64_encrypt_block:
> +  *  %rdx: src
> +  */
> + CFI_STARTPROC();
> ++endbr64;
> + ENTER_SYSV_FUNC_PARAMS_0_4
> + 
> + movq %rsi, %r10;
> +@@ -225,6 +227,7 @@ _gcry_blowfish_amd64_decrypt_block:
> +  *  %rdx: src
> +  */
> + CFI_STARTPROC();
> ++endbr64;
> + ENTER_SYSV_FUNC_PARAMS_0_4
> + 
> + movq %rbp, %r11;
> +@@ -413,6 +416,7 @@ _gcry_blowfish_amd64_ctr_enc:
> +  *  %rcx: iv (big endian, 64bit)
> +  */
> + CFI_STARTPROC();
> ++endbr64;
> + ENTER_SYSV_FUNC_PARAMS_0_4
> + 
> + pushq %rbp;
> +@@ -483,6 +487,7 @@ _gcry_blowfish_amd64_cbc_dec:
> +  *  %rcx: iv (64bit)
> +  */
> +

CVS: cvs.openbsd.org: ports

2024-02-21 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/21 16:30:40

Modified files:
lang/hare  : Makefile.inc 

Log message:
lang/hare: Lorenz would like to take over maintainership

I will stick around as co-maintainer for a while to review and upload
updates.

CVS: cvs.openbsd.org: ports

2024-02-21 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/21 16:26:42

Modified files:
lang/hare/harec: Makefile 

Log message:
lang/hare/harec: Move DISTFILES to top where it is in hare

CVS: cvs.openbsd.org: ports

2024-02-21 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/21 13:12:59

Modified files:
lang/hare  : Makefile.inc 
lang/hare/hare : Makefile distinfo 
lang/hare/hare/pkg: PLIST 
lang/hare/harec: Makefile distinfo 
Removed files:
lang/hare/hare/patches: patch-Makefile 
patch-makefiles_openbsd_x86_64_mk 
lang/hare/harec/patches: patch-Makefile patch-config_sh 
 patch-rt_+openbsd_start+aarch64_s 
 patch-rt_Makefile 
 patch-testmod_Makefile 
 patch-tests_configure 

Log message:
lang/hare: update to first official release 0.24.0

tested by Lorenz (xha)

CVS: cvs.openbsd.org: ports

2024-02-21 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/21 12:56:01

Modified files:
lang/hare  : Makefile.inc 

Log message:
Take over maintainership from bcallah@ who has ENOTIME

Re: CVS: cvs.openbsd.org: ports

2024-02-16 Thread Tobias Heider

On Fri, Feb 16, 2024 at 03:49:10PM -0700, Tobias Heider wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   to...@cvs.openbsd.org   2024/02/16 15:49:10
> 
> Modified files:
>   lang/qbe   : Makefile distinfo 
> Removed files:
>   lang/qbe/patches: patch-all_h patch-amd64_emit_c 
> patch-arm64_emit_c patch-emit_c patch-ops_h 
> patch-parse_c patch-rv64_emit_c 
> 
> Log message:
> lang/qbe: Update to 1.2
> 

+ ok bcallah@

CVS: cvs.openbsd.org: ports

2024-02-16 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/16 15:49:10

Modified files:
lang/qbe   : Makefile distinfo 
Removed files:
lang/qbe/patches: patch-all_h patch-amd64_emit_c 
  patch-arm64_emit_c patch-emit_c patch-ops_h 
  patch-parse_c patch-rv64_emit_c 

Log message:
lang/qbe: Update to 1.2

lang/qbe: update to 1.2

2024-02-16 Thread Tobias Heider

New qbe version is out and required for the latest hare
update.  Looks like we can drop our patches too.

ok?

Index: Makefile
===
RCS file: /cvs/ports/lang/qbe/Makefile,v
diff -u -p -r1.7 Makefile
--- Makefile5 Feb 2024 21:50:49 -   1.7
+++ Makefile16 Feb 2024 21:21:25 -
@@ -2,9 +2,8 @@
 ONLY_FOR_ARCHS =   amd64 arm64 riscv64
 
 COMMENT =  small, quick compiler backend
-DISTNAME = qbe-1.1pl20230925
+DISTNAME = qbe-1.2
 CATEGORIES =   lang devel
-REVISION = 0
 
 HOMEPAGE = https://c9x.me/compile/
 MAINTAINER =   Brian Callahan 
@@ -14,7 +13,8 @@ PERMIT_PACKAGE =  Yes
 
 WANTLIB += c
 
-SITES =https://github.com/ibara/ports/releases/download/v1.0/
+EXTRACT_SUFX= .tar.xz
+SITES =https://c9x.me/compile/release/
 
 DEBUG_PACKAGES =   ${BUILD_PACKAGES}
 
Index: distinfo
===
RCS file: /cvs/ports/lang/qbe/distinfo,v
diff -u -p -r1.4 distinfo
--- distinfo2 Dec 2023 21:55:09 -   1.4
+++ distinfo16 Feb 2024 21:21:25 -
@@ -1,2 +1,2 @@
-SHA256 (qbe-1.1pl20230925.tar.gz) = 
8HFVyjMmMgzARvknqUKFqICTJIqbtCljaYHloK6F4Qg=
-SIZE (qbe-1.1pl20230925.tar.gz) = 360885
+SHA256 (qbe-1.2.tar.xz) = ptUOuVJSWiNL92uhUYYfc7ejgqyVLZhfK5rx31NoIl0=
+SIZE (qbe-1.2.tar.xz) = 246364

Re: CVS: cvs.openbsd.org: ports

2024-02-09 Thread Tobias Heider

On Wed, Feb 07, 2024 at 01:11:07PM -0700, Antoine Jacoutot wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   ajacou...@cvs.openbsd.org   2024/02/07 13:11:07
> 
> Modified files:
>   www/webkitgtk4 : Tag: OPENBSD_7_4 Makefile distinfo 
>   www/webkitgtk4/patches: Tag: OPENBSD_7_4 
>   
> patch-Source_JavaScriptCore_assembler_ARMv7Assembler_h 
> 
> Log message:
> Update to webkitgtk40-2.42.5.
> 

This is weirdly broken on macppc. It seems like they forgot to include a commit
in the release.

In LowLevelInterpreter.cpp:339 they use a variable t6 which does not exist in 
the
release tarball. It is there in the github repo.
Does the build work on other archs?

CVS: cvs.openbsd.org: ports

2024-02-09 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/09 04:13:02

Modified files:
games/cromagrally: Makefile distinfo 
games/cromagrally/pkg: PLIST 
Added files:
games/cromagrally/patches: patch-Source_Boot_cpp 
Removed files:
games/cromagrally/patches: patch-Source_Main_cpp 

Log message:
games/cromagrally: Update to 3.0.1

This release fixes rendering on macppc.

ok op@

games/cromagrally: update to 3.0.1

2024-02-08 Thread Tobias Heider

cromagrally just published a new version including a bug fix that makes
it work properly on macppc.

Here's a diff to update to 3.0.1

ok?

Index: Makefile
===
RCS file: /cvs/ports/games/cromagrally/Makefile,v
diff -u -p -r1.1.1.1 Makefile
--- Makefile30 Jan 2024 19:51:55 -  1.1.1.1
+++ Makefile8 Feb 2024 15:47:59 -
@@ -1,11 +1,10 @@
 COMMENT =  family-friendly bronze age kart game
 
-V =3.0.0pl0
-GAME_COMMIT =  5983de40c180b50bbbec8b04f5f5f1ceccd1901b
+V =3.0.1
 PKGNAME =  cromagrally-${V}
-DISTNAME = CroMagRally-${GAME_COMMIT}
-DIST_TUPLE +=  github jorio CroMagRally ${GAME_COMMIT} .
-DIST_TUPLE +=  github jorio Pomme d57c28e205462e51063e787f9ebddaadff592f1e \
+DISTNAME = CroMagRally-${V}
+DIST_TUPLE +=  github jorio CroMagRally ${V} .
+DIST_TUPLE +=  github jorio Pomme ef94150e2dcec522e3099f4d03a4e8f2639f7232 \
extern/Pomme
 
 CATEGORIES =   games
@@ -35,7 +34,7 @@ CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE=Rel
-DCMAKE_INSTALL_PREFIX=${LOCALBASE}
 
 pre-configure:
-   ${SUBST_CMD} ${WRKSRC}/Source/Main.cpp
+   ${SUBST_CMD} ${WRKSRC}/Source/Boot.cpp
 
 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/CroMagRally/
@@ -44,9 +43,9 @@ do-install:
cp -R ${WRKBUILD}/Data ${PREFIX}/share/cromagrally
${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/512x512/apps/ \
${PREFIX}/share/applications/
-   ${INSTALL_DATA} ${WRKSRC}/packaging/cromagrally-desktopicon.png \
+   ${INSTALL_DATA} ${WRKSRC}/packaging/io.jor.cromagrally.png \
${PREFIX}/share/icons/hicolor/512x512/apps/
-   ${INSTALL_DATA} ${WRKSRC}/packaging/cromagrally.desktop \
+   ${INSTALL_DATA} ${WRKSRC}/packaging/io.jor.cromagrally.desktop \
${PREFIX}/share/applications/
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/games/cromagrally/distinfo,v
diff -u -p -r1.1.1.1 distinfo
--- distinfo30 Jan 2024 19:51:55 -  1.1.1.1
+++ distinfo8 Feb 2024 15:47:59 -
@@ -1,4 +1,4 @@
-SHA256 (jorio-CroMagRally-5983de40c180b50bbbec8b04f5f5f1ceccd1901b.tar.gz) = 
bah6hMEPSWWHufce0fLLgNZAg1qsMZiN/b5oII4nYKU=
-SHA256 (jorio-Pomme-d57c28e205462e51063e787f9ebddaadff592f1e.tar.gz) = 
P4oAFIYquIpOTCeOay8Y/V/nEzV01zuz1mun2QK8mTQ=
-SIZE (jorio-CroMagRally-5983de40c180b50bbbec8b04f5f5f1ceccd1901b.tar.gz) = 
143649930
-SIZE (jorio-Pomme-d57c28e205462e51063e787f9ebddaadff592f1e.tar.gz) = 148831
+SHA256 (jorio-CroMagRally-3.0.1.tar.gz) = 
lho27SF/FwiYlU2MKOiDS1YXZ150HmEUkOeSsCjqZ3w=
+SHA256 (jorio-Pomme-ef94150e2dcec522e3099f4d03a4e8f2639f7232.tar.gz) = 
afr2FkScBzfiODZ4g+NiMPFdE8Jh4Y1uTUxp4u3QsAI=
+SIZE (jorio-CroMagRally-3.0.1.tar.gz) = 143630062
+SIZE (jorio-Pomme-ef94150e2dcec522e3099f4d03a4e8f2639f7232.tar.gz) = 152738
Index: patches/patch-Source_Boot_cpp
===
RCS file: patches/patch-Source_Boot_cpp
diff -N patches/patch-Source_Boot_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-Source_Boot_cpp   8 Feb 2024 15:47:59 -
@@ -0,0 +1,12 @@
+Index: Source/Boot.cpp
+--- Source/Boot.cpp.orig
 Source/Boot.cpp
+@@ -58,7 +58,7 @@ tryAgain:
+   break;
+ 
+   case 2:
+-  dataPath = "Data";
++  dataPath = "${TRUEPREFIX}/share/cromagrally";
+   break;
+ 
+   default:
Index: patches/patch-Source_Main_cpp
===
RCS file: patches/patch-Source_Main_cpp
diff -N patches/patch-Source_Main_cpp
--- patches/patch-Source_Main_cpp   30 Jan 2024 19:51:55 -  1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-Index: Source/Main.cpp
 Source/Main.cpp.orig
-+++ Source/Main.cpp
-@@ -51,7 +51,7 @@ static fs::path FindGameData()
-   dataPath = pathbuf;
-   dataPath = dataPath.parent_path().parent_path() / "Resources";
- #else
--  dataPath = "Data";
-+  dataPath = "${TRUEPREFIX}/share/cromagrally";
- #endif
- 
-   dataPath = dataPath.lexically_normal();
Index: pkg/PLIST
===
RCS file: /cvs/ports/games/cromagrally/pkg/PLIST,v
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST   30 Jan 2024 19:51:55 -  1.1.1.1
+++ pkg/PLIST   8 Feb 2024 15:47:59 -
@@ -1,5 +1,5 @@
 @bin bin/CroMagRally
-share/applications/cromagrally.desktop
+share/applications/io.jor.cromagrally.desktop
 share/cromagrally/
 share/cromagrally/Audio/
 share/cromagrally/Audio/Announcer/
@@ -51,7 +51,7 @@ share/cromagrally/Audio/EuroSong.aiff
 share/cromagrally/Audio/IceSong.aiff
 share/cromagrally/Audio/JungleSong.aiff
 share/cromagrally/Audio/LevelSpecific/
-share/cromagrally/Audio/LevelSpecific/Blowdart.aiff

Re: qbe: include dbgloc patch for hare

2024-02-07 Thread Tobias Heider

On Wed, Feb 07, 2024 at 10:54:56AM +0100, Lorenz (xha) wrote:
> fyi there might be a QBE release 1.2 before hare 0.24.0
> 
> https://lists.sr.ht/~sircmpwn/hare-dev/%3CCYYOPRMPIF11.2F5WIW9HORKTQ%40taiga%3E

Thx for the info!

I have a first working draft of a hare-0.24.0-rc2 port, I guess I will
wait for it to be released before sending the update to the list.

New qbe should make things easier.

> 
> On Mon, Feb 05, 2024 at 08:54:54PM +0100, Tobias Heider wrote:
> > For the next hare port update we will need this additional
> > qbe patch, otherwise it won't build.
> > 
> > This is upstream commit 85287081c4a25785dec1ec48c488a5879b3c37ac
> > Unfortunately they haven't tagged a new version including that.
> > 
> > ok to ship it as a patch?
> > 
> > diff /home/user/got/co/ports
> > commit - b8046539b93a72d6288d3d3643f7d6c95435a297
> > path + /home/user/got/co/ports
> > blob - 502cd243b7828146f82d943d353e12028979ce03
> > file + lang/qbe/Makefile
> > --- lang/qbe/Makefile
> > +++ lang/qbe/Makefile
> > @@ -4,6 +4,7 @@ ONLY_FOR_ARCHS =amd64 arm64 riscv64
> >  COMMENT =  small, quick compiler backend
> >  DISTNAME = qbe-1.1pl20230925
> >  CATEGORIES =   lang devel
> > +REVISION = 0
> >  
> >  HOMEPAGE = https://c9x.me/compile/
> >  MAINTAINER =   Brian Callahan 
> > blob - /dev/null
> > file + lang/qbe/patches/patch-all_h (mode 644)
> > --- /dev/null
> > +++ lang/qbe/patches/patch-all_h
> > @@ -0,0 +1,16 @@
> > +dbgloc: add column argument
> > +
> > +backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
> > +
> > +Index: all.h
> > +--- all.h.orig
> >  all.h
> > +@@ -569,7 +569,7 @@ void rega(Fn *);
> > + void emitfnlnk(char *, Lnk *, FILE *);
> > + void emitdat(Dat *, FILE *);
> > + void emitdbgfile(char *, FILE *);
> > +-void emitdbgloc(uint, FILE *);
> > ++void emitdbgloc(uint, uint, FILE *);
> > + int stashbits(void *, int);
> > + void elf_emitfnfin(char *, FILE *);
> > + void elf_emitfin(FILE *);
> > blob - /dev/null
> > file + lang/qbe/patches/patch-amd64_emit_c (mode 644)
> > --- /dev/null
> > +++ lang/qbe/patches/patch-amd64_emit_c
> > @@ -0,0 +1,16 @@
> > +dbgloc: add column argument
> > +
> > +backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
> > +
> > +Index: amd64/emit.c
> > +--- amd64/emit.c.orig
> >  amd64/emit.c
> > +@@ -548,7 +548,7 @@ emitins(Ins i, Fn *fn, FILE *f)
> > +   emitcopy(i.arg[1], TMP(XMM0+15), i.cls, fn, f);
> > +   break;
> > +   case Odbgloc:
> > +-  emitdbgloc(i.arg[0].val, f);
> > ++  emitdbgloc(i.arg[0].val, i.arg[1].val, f);
> > +   break;
> > +   }
> > + }
> > blob - /dev/null
> > file + lang/qbe/patches/patch-arm64_emit_c (mode 644)
> > --- /dev/null
> > +++ lang/qbe/patches/patch-arm64_emit_c
> > @@ -0,0 +1,16 @@
> > +dbgloc: add column argument
> > +
> > +backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
> > +
> > +Index: arm64/emit.c
> > +--- arm64/emit.c.orig
> >  arm64/emit.c
> > +@@ -447,7 +447,7 @@ emitins(Ins *i, E *e)
> > +   emitf("mov %=, sp", i, e);
> > +   break;
> > +   case Odbgloc:
> > +-  emitdbgloc(i->arg[0].val, e->f);
> > ++  emitdbgloc(i->arg[0].val, i->arg[1].val, e->f);
> > +   break;
> > +   }
> > + }
> > blob - /dev/null
> > file + lang/qbe/patches/patch-emit_c (mode 644)
> > --- /dev/null
> > +++ lang/qbe/patches/patch-emit_c
> > @@ -0,0 +1,20 @@
> > +dbgloc: add column argument
> > +
> > +backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
> > +
> > +Index: emit.c
> > +--- emit.c.orig
> >  emit.c
> > +@@ -235,7 +235,10 @@ emitdbgfile(char *fn, FILE *f)
> > + }
> > + 
> > + void
> > +-emitdbgloc(uint loc, FILE *f)
> > ++emitdbgloc(uint line, uint col, FILE *f)
> > + {
> > +-  fprintf(f, "\t.loc %u %u\n", curfile, loc);
> > ++  if (col != 0)
> > ++  fprintf(f, "\t.loc %u %u %u\n", curfile, line, col);
> > ++  else
> > ++  fprintf(f, "\t.loc %u %u\n", curfile, line);
> > + }
> > blob - /dev/null
> > file + lang/qbe/patches/patch-ops_h (mode 644)
> > --- /dev/null
> > +++ lang/qbe/patches/patch-ops_h
> > @@ -0,0 +1,16 @@
> > +dbgloc: add column argument
> > +
> > +backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
> > +
> > +Index: ops.

CVS: cvs.openbsd.org: ports

2024-02-06 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/06 05:49:37

Modified files:
games/yquake2  : Makefile 

Log message:
games/yquake2: Enable build for all archs. Upstream has indicated they
are going to officially try to support all possible archs.
Testing has shown it works on macppc, so there is a good chance other
archs work too.

ok kn@

Re: games/yquake2: enable macppc

2024-02-06 Thread Tobias Heider

On Tue, Feb 06, 2024 at 01:54:26AM +, Klemens Nanni wrote:
> On Tue, Feb 06, 2024 at 02:48:32AM +0100, Tobias Heider wrote:
> > I wouldn't mind enabling it for all archs either. Not sure which arch it
> > doesn't work on so NOT_FOR_ARCHS doesn't seem very useful.
> > I guess if it works on 32 bit BE macppc there is a good chance that most
> > others work too.
> 
> Remove ONLY_FOR_ARCHS and find out through bulks?
> Iff that's a bad idea or I'm missing something, your diff is certainly
> OK kn, given your tests.

I think I'll do that then if no one sees a problem with it.
Does updating archs need a REVISION bump? I guess I'd do one
just to be sure.

Re: games/yquake2: enable macppc

2024-02-05 Thread Tobias Heider

On Tue, Feb 06, 2024 at 01:36:58AM +, Klemens Nanni wrote:
> On Tue, Feb 06, 2024 at 02:28:34AM +0100, Tobias Heider wrote:
> > Tested and found out it builds and runs fine on macppc.
> > 
> > ok to enable it there?
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/games/yquake2/Makefile,v
> > retrieving revision 1.28
> > diff -u -p -r1.28 Makefile
> > --- Makefile26 Sep 2023 09:41:45 -  1.28
> > +++ Makefile6 Feb 2024 01:17:26 -
> > @@ -1,4 +1,4 @@
> > -ONLY_FOR_ARCHS=i386 amd64 sparc64
> > +ONLY_FOR_ARCHS=i386 amd64 sparc64 macppc
> >  
> >  COMMENT=   Yamagi Quake II
> >  N= yquake2
> > 
> 
> Do you want to stick to the whitelist or flip to NOT_FOR_ARCHS?
> 
> I'm not interested in this game, just wondered how it came to be that
> architectures support changed.

I wouldn't mind enabling it for all archs either. Not sure which arch it
doesn't work on so NOT_FOR_ARCHS doesn't seem very useful.
I guess if it works on 32 bit BE macppc there is a good chance that most
others work too.

> 
> revision 1.4
> date: 2016/06/28 20:50:22;  author: awolk;  state: Exp;  lines: +6 -4;  
> commitid: OCjzSGt5M9IIpgwf;
> Update games/yquake2 5.32 => 5.34
> 
> OK abieber@
> 
> Changes in the port:
> [...]
> Additional notes:
> [...]
> - upstream said in their changelog that they are changing their
>platform policy 'Switch from an arch whitelist to an "all archs are
>supported" approach.'. I saw in our tree a change by landry@
>specifically limiting the supported platform to the upstream
>supported versions
>
> (http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/games/yquake2/Makefile?rev=1.2=text/x-cvsweb-markup).
>I am not removing this restriction until I get some feedback from
>people able to test other platforms than currently
>listed in ONLY_FOR_ARCHS.
>

games/yquake2: enable macppc

2024-02-05 Thread Tobias Heider

Tested and found out it builds and runs fine on macppc.

ok to enable it there?

Index: Makefile
===
RCS file: /cvs/ports/games/yquake2/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile26 Sep 2023 09:41:45 -  1.28
+++ Makefile6 Feb 2024 01:17:26 -
@@ -1,4 +1,4 @@
-ONLY_FOR_ARCHS=i386 amd64 sparc64
+ONLY_FOR_ARCHS=i386 amd64 sparc64 macppc
 
 COMMENT=   Yamagi Quake II
 N= yquake2

CVS: cvs.openbsd.org: ports

2024-02-05 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/05 14:50:49

Modified files:
lang/qbe   : Makefile 
Added files:
lang/qbe/patches: patch-all_h patch-amd64_emit_c 
  patch-arm64_emit_c patch-emit_c patch-ops_h 
  patch-parse_c patch-rv64_emit_c 

Log message:
lang/qbe: include "dbgloc: add column argument" as patch

Backport upstream commit 85287081c4a25785dec1ec48c488a5879b3c37ac
which is required for building newer versions of hare.

ok bcallah@

CVS: cvs.openbsd.org: ports

2024-02-05 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2024/02/05 14:35:33

ports/lang/qbe/patches

Update of /cvs/ports/lang/qbe/patches
In directory cvs.openbsd.org:/tmp/cvs-serv45479/patches

Log Message:
Directory /cvs/ports/lang/qbe/patches added to the repository

qbe: include dbgloc patch for hare

2024-02-05 Thread Tobias Heider

For the next hare port update we will need this additional
qbe patch, otherwise it won't build.

This is upstream commit 85287081c4a25785dec1ec48c488a5879b3c37ac
Unfortunately they haven't tagged a new version including that.

ok to ship it as a patch?

diff /home/user/got/co/ports
commit - b8046539b93a72d6288d3d3643f7d6c95435a297
path + /home/user/got/co/ports
blob - 502cd243b7828146f82d943d353e12028979ce03
file + lang/qbe/Makefile
--- lang/qbe/Makefile
+++ lang/qbe/Makefile
@@ -4,6 +4,7 @@ ONLY_FOR_ARCHS =amd64 arm64 riscv64
 COMMENT =  small, quick compiler backend
 DISTNAME = qbe-1.1pl20230925
 CATEGORIES =   lang devel
+REVISION = 0
 
 HOMEPAGE = https://c9x.me/compile/
 MAINTAINER =   Brian Callahan 
blob - /dev/null
file + lang/qbe/patches/patch-all_h (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-all_h
@@ -0,0 +1,16 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: all.h
+--- all.h.orig
 all.h
+@@ -569,7 +569,7 @@ void rega(Fn *);
+ void emitfnlnk(char *, Lnk *, FILE *);
+ void emitdat(Dat *, FILE *);
+ void emitdbgfile(char *, FILE *);
+-void emitdbgloc(uint, FILE *);
++void emitdbgloc(uint, uint, FILE *);
+ int stashbits(void *, int);
+ void elf_emitfnfin(char *, FILE *);
+ void elf_emitfin(FILE *);
blob - /dev/null
file + lang/qbe/patches/patch-amd64_emit_c (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-amd64_emit_c
@@ -0,0 +1,16 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: amd64/emit.c
+--- amd64/emit.c.orig
 amd64/emit.c
+@@ -548,7 +548,7 @@ emitins(Ins i, Fn *fn, FILE *f)
+   emitcopy(i.arg[1], TMP(XMM0+15), i.cls, fn, f);
+   break;
+   case Odbgloc:
+-  emitdbgloc(i.arg[0].val, f);
++  emitdbgloc(i.arg[0].val, i.arg[1].val, f);
+   break;
+   }
+ }
blob - /dev/null
file + lang/qbe/patches/patch-arm64_emit_c (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-arm64_emit_c
@@ -0,0 +1,16 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: arm64/emit.c
+--- arm64/emit.c.orig
 arm64/emit.c
+@@ -447,7 +447,7 @@ emitins(Ins *i, E *e)
+   emitf("mov %=, sp", i, e);
+   break;
+   case Odbgloc:
+-  emitdbgloc(i->arg[0].val, e->f);
++  emitdbgloc(i->arg[0].val, i->arg[1].val, e->f);
+   break;
+   }
+ }
blob - /dev/null
file + lang/qbe/patches/patch-emit_c (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-emit_c
@@ -0,0 +1,20 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: emit.c
+--- emit.c.orig
 emit.c
+@@ -235,7 +235,10 @@ emitdbgfile(char *fn, FILE *f)
+ }
+ 
+ void
+-emitdbgloc(uint loc, FILE *f)
++emitdbgloc(uint line, uint col, FILE *f)
+ {
+-  fprintf(f, "\t.loc %u %u\n", curfile, loc);
++  if (col != 0)
++  fprintf(f, "\t.loc %u %u %u\n", curfile, line, col);
++  else
++  fprintf(f, "\t.loc %u %u\n", curfile, line);
+ }
blob - /dev/null
file + lang/qbe/patches/patch-ops_h (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-ops_h
@@ -0,0 +1,16 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: ops.h
+--- ops.h.orig
 ops.h
+@@ -122,7 +122,7 @@ O(vastart, T(m,e,e,e, x,e,e,e), 0) X(0, 0, 0) V(0)
+ O(copy,T(w,l,s,d, x,x,x,x), 0) X(0, 0, 1) V(0)
+ 
+ /* Debug */
+-O(dbgloc,  T(w,l,s,d, x,x,x,x), 0) X(0, 0, 1) V(0)
++O(dbgloc,  T(w,e,e,e, w,e,e,e), 0) X(0, 0, 1) V(0)
+ 
+ //
+ /* INTERNAL OPERATIONS (keep nop first) */
blob - /dev/null
file + lang/qbe/patches/patch-parse_c (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-parse_c
@@ -0,0 +1,22 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: parse.c
+--- parse.c.orig
 parse.c
+@@ -669,6 +669,14 @@ parseline(PState ps)
+   arg[0] = INT(tokval.num);
+   if (arg[0].val != tokval.num)
+   err("line number too big");
++  if (peek() == Tcomma) {
++  next();
++  expect(Tint);
++  arg[1] = INT(tokval.num);
++  if (arg[1].val != tokval.num)
++  err("column number too big");
++  } else
++  arg[1] = INT(0);
+   goto Ins;
+   }
+   if (op == Tcall) {
blob - /dev/null
file + lang/qbe/patches/patch-rv64_emit_c (mode 644)
--- /dev/null
+++ lang/qbe/patches/patch-rv64_emit_c
@@ -0,0 +1,16 @@
+dbgloc: add column argument
+
+backport of 85287081c4a25785dec1ec48c488a5879b3c37ac
+
+Index: rv64/emit.c
+--- rv64/emit.c.orig
 rv64/emit.c
+@@ -406,7 +406,7 @@ emitins(Ins *i, Fn *fn, FILE *f)
+   emitf("mv %=, sp", i, fn, f);
+   break;
+   case

Re: firefox - some pages cause SIGILL

2024-01-24 Thread Tobias Heider




On January 24, 2024 8:49:27 AM GMT+01:00, Jan Stary  wrote:
>This is current/arm64 on a MacBook Air (M1),
>running the latest Firefox 121.0.1
>
>Some webpages, such as reuters.com or theguardian.com,
>result in a tab crash, with firefix saying
>
>[Parent 94040, IPC I/O Parent] WARNING: process 47036 exited on signal 4: file 
>/usr/obj/ports/firefox-121.0.1/firefox-121.0.1/ipc/chromium/src/base/process_util_posix.cc:315
>
>[Parent 94040, IPC I/O Parent] WARNING: process 82372 exited on signal 4: file 
>/usr/obj/ports/firefox-121.0.1/firefox-121.0.1/ipc/chromium/src/base/process_util_posix.cc:315
>
>Other pages work just fine.
>
>Once the crash happens, ktrace -p $FOXPID -di -ts
>starts reporting a flood of these (full log below):
>
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac1630e trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac1630e trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac16fc8 trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac1630c trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac1630c trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
>
>Any idea what this is?
>How do I debug that?

might be a pledge violation. check dmesg to see if there are any pledge errors.

firefox sometimes tries to use shared memory when using software rendering.

>
>   Jan
>
>
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac1630e trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac1630e trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_ACCERR addr=0x206ac16fc8 trapno=-1845493745
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273 firefox  PSIG  SIGSEGV caught handler=0x206f4b242c mask=0<> 
> code=SEGV_MAPERR addr=0x0 trapno=-2113929211
> 65273

Re: firefox missing libmozwayland.so on arm64

2023-12-17 Thread Tobias Heider

On Sun, Dec 17, 2023 at 10:11:26AM +0100, Jan Stary wrote:
> This is current/arm64 on a M1 macbook, with firefox-120.0.1.
> Firefox will not start, complaining that
> 
> XPCOMGlueLoad error for file /usr/local/lib/firefox/libmozwayland.so.132.0:
> File not found
> Couldn't load XPCOM.
> 
> Indeed, the file does not exist.
> 
>   Jan
> 

I'm seeing the same on amd64, so it might not be arm specific.

Re: lang/hare build failure (Re: NEW: lang/hare)

2023-12-12 Thread Tobias Heider

On Tue, Dec 12, 2023 at 03:36:52AM +, Brian Callahan wrote:
> On 12/11/2023 7:42 PM, Brian Callahan wrote:
> > On 12/11/2023 6:34 PM, Stuart Henderson wrote:
> >> On 2023/12/11 16:40, Lorenz (xha) wrote:
> >>> FYI hare only needs gas and not the complete binutils package. and gas
> >>> is just needed because the "as" in the base system is too old.
> >>>
> >>
> >> Will the version from devel/gas (2.31.1) also work? If so, you could do
> >> this to prefer binutils-* but use gas-* if already installed.
> >>
> > 
> > For some reason, I thought devel/gas was too old to have riscv64
> > support, but it seems I misremembered that.
> > 
> > It works fine for amd64, I will check on arm64 and riscv64.
> > 
> > I don't see a reason not to use devel/gas if we can and just forget
> > about devel/binutils. I wouldn't want people to install hare and then
> > try to install gcc only to have it fail for something easily fixed.
> > 
> > OK to replace devel/binutils with devel/gas and bump, assuming arm64 and
> > riscv64 check out?
> > 
> 
> Now after testing arm64 and riscv64:
> amd64 and arm64 work with devel/gas. riscv64 does not work with
> devel/gas and requires devel/binutils.
> 
> Attached is a patch that tweaks things. Also adds a patch from tobhe@
> that got missed during import that has been upstreamed.
> 
> OK?

ok tobhe@

> 
> ~Brian

> Index: hare/Makefile
> ===
> RCS file: /cvs/ports/lang/hare/hare/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- hare/Makefile 3 Dec 2023 19:07:28 -   1.1.1.1
> +++ hare/Makefile 12 Dec 2023 03:16:59 -
> @@ -17,7 +17,7 @@ do-gen:
>   cp ${WRKSRC}/configs/openbsd.mk ${WRKSRC}/config.mk
>   sed -i "s/aarch64-//g" ${WRKSRC}/config.mk
>   sed -i "s/riscv64-//g" ${WRKSRC}/config.mk
> -.if ${MACHINE_ARCH:Marm64}
> +.if ${MACHINE_ARCH:Maarch64} || ${MACHINE_ARCH:Mriscv64}
>   echo "ARCH = $$(arch -s)" >> ${WRKSRC}/config.mk
>  .endif
>  
> Index: harec/Makefile
> ===
> RCS file: /cvs/ports/lang/hare/harec/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- harec/Makefile3 Dec 2023 19:07:28 -   1.1.1.1
> +++ harec/Makefile12 Dec 2023 03:16:59 -
> @@ -1,4 +1,5 @@
>  DISTNAME =   harec-0.0.0pl20231202
> +REVISION =   0
>  
>  WANTLIB += c m
>  
> @@ -7,9 +8,15 @@ COMPILER =   base-clang ports-gcc
>  
>  BUILD_DEPENDS =  ${RUN_DEPENDS}
>  
> -# Needs a newer GNU as
> -RUN_DEPENDS =devel/binutils \
> - lang/qbe
> +RUN_DEPENDS =lang/qbe
> +
> +# All archs need a newer GNU as
> +# gas-2.31.1 is not new enough for riscv64
> +.if ${MACHINE_ARCH:Mriscv64}
> +RUN_DEPENDS +=   devel/binutils
> +.else
> +RUN_DEPENDS +=   devel/gas
> +.endif
>  
>  CONFIGURE_STYLE =simple
>  CONFIGURE_ARGS = --sysconfdir="${SYSCONFDIR}"
> Index: harec/patches/patch-rt_+openbsd_start+aarch64_s
> ===
> RCS file: harec/patches/patch-rt_+openbsd_start+aarch64_s
> diff -N harec/patches/patch-rt_+openbsd_start+aarch64_s
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ harec/patches/patch-rt_+openbsd_start+aarch64_s   12 Dec 2023 03:16:59 
> -
> @@ -0,0 +1,11 @@
> +Already upstreamed, from tobhe@
> +
> +Index: rt/+openbsd/start+aarch64.s
> +--- rt/+openbsd/start+aarch64.s.orig
>  rt/+openbsd/start+aarch64.s
> +@@ -5,5 +5,4 @@ _start:
> + mov x30, #0
> + mov x0, sp
> + add sp, x0, #-16
> +-and sp, sp, #-16
> + b rt.start_ha

Re: apple-boot firmware update

2023-12-12 Thread Tobias Heider




On December 12, 2023 1:29:21 PM GMT+01:00, Mark Kettenis 
 wrote:
>This updates m1n1 to the latest tagged version (1.4.8) and updates
>u-boot to a version that can initailize the "mtp" coprocessor on with
>newer system firmware.  This is necessary to have a working keyboard
>on machines like the M2 MacBook Air when using the latest version of
>the Asahi installer.
>
>ok?

ok tobhe@

>
>Index: sysutils/firmware/apple-boot/Makefile
>===
>RCS file: /cvs/ports/sysutils/firmware/apple-boot/Makefile,v
>retrieving revision 1.14
>diff -u -p -r1.14 Makefile
>--- sysutils/firmware/apple-boot/Makefile  27 Oct 2023 10:20:43 -  
>1.14
>+++ sysutils/firmware/apple-boot/Makefile  12 Dec 2023 12:23:05 -
>@@ -1,6 +1,6 @@
> FW_DRIVER=apple-boot
> FW_VER=   1.1
>-REVISION= 0
>+REVISION= 1
> 
> WRKDIST=  ${WRKDIR}
> DISTFILES=
>@@ -10,8 +10,8 @@ DISTFILES=
> PERMIT_PACKAGE= firmware
> PERMIT_DISTFILES= Yes
> 
>-BUILD_DEPENDS=m1n1-=1.4.3:sysutils/m1n1:build \
>-  u-boot-asahi-=2023.07.02:sysutils/u-boot-asahi:build
>+BUILD_DEPENDS=m1n1-=1.4.8:sysutils/m1n1:build \
>+  u-boot-asahi-=2023.07.02p1:sysutils/u-boot-asahi:build
> 
> ASAHI_BUILD=  ${WRKSRC}/sysutils/u-boot-asahi/u-boot-*/build
> M1N1_BUILD=   ${WRKSRC}/sysutils/m1n1/m1n1-*/build
>Index: sysutils/m1n1/Makefile
>===
>RCS file: /cvs/ports/sysutils/m1n1/Makefile,v
>retrieving revision 1.12
>diff -u -p -r1.12 Makefile
>--- sysutils/m1n1/Makefile 26 Oct 2023 18:45:28 -  1.12
>+++ sysutils/m1n1/Makefile 12 Dec 2023 12:23:06 -
>@@ -4,7 +4,7 @@ COMMENT=   Bootloader for Apple Silicon
> 
> GH_ACCOUNT=   AsahiLinux
> GH_PROJECT=   m1n1
>-GH_TAGNAME=   v1.4.3
>+GH_TAGNAME=   v1.4.8
> 
> CATEGORIES=   sysutils
> HOMEPAGE= https://github.com/AsahiLinux/m1n1
>Index: sysutils/m1n1/distinfo
>===
>RCS file: /cvs/ports/sysutils/m1n1/distinfo,v
>retrieving revision 1.5
>diff -u -p -r1.5 distinfo
>--- sysutils/m1n1/distinfo 26 Oct 2023 18:45:28 -  1.5
>+++ sysutils/m1n1/distinfo 12 Dec 2023 12:23:06 -
>@@ -1,2 +1,2 @@
>-SHA256 (m1n1-1.4.3.tar.gz) = 9x58eF1lQUgb9srl0pUYOOMeb2Q1SMdEDE//B1fV91U=
>-SIZE (m1n1-1.4.3.tar.gz) = 819419
>+SHA256 (m1n1-1.4.8.tar.gz) = ohQaSkEnddnyW3WWEcXQEKHsaSnq34laCUyi9643rCg=
>+SIZE (m1n1-1.4.8.tar.gz) = 822674
>Index: sysutils/u-boot-asahi/Makefile
>===
>RCS file: /cvs/ports/sysutils/u-boot-asahi/Makefile,v
>retrieving revision 1.13
>diff -u -p -r1.13 Makefile
>--- sysutils/u-boot-asahi/Makefile 3 Dec 2023 22:55:16 -   1.13
>+++ sysutils/u-boot-asahi/Makefile 12 Dec 2023 12:23:08 -
>@@ -5,8 +5,8 @@ COMMENT=   U-Boot firmware for Apple Silic
> VERSION=  2023.07.02
> GH_ACCOUNT=   AsahiLinux
> GH_PROJECT=   u-boot
>-GH_TAGNAME=   openbsd-v${VERSION}
>-REVISION= 0
>+GH_TAGNAME=   openbsd-v${VERSION}-1
>+REVISION= 1
> 
> PKGNAME=  u-boot-asahi-${VERSION:S/-/./g}
> 
>Index: sysutils/u-boot-asahi/distinfo
>===
>RCS file: /cvs/ports/sysutils/u-boot-asahi/distinfo,v
>retrieving revision 1.3
>diff -u -p -r1.3 distinfo
>--- sysutils/u-boot-asahi/distinfo 10 Sep 2023 15:18:39 -  1.3
>+++ sysutils/u-boot-asahi/distinfo 12 Dec 2023 12:23:08 -
>@@ -1,2 +1,2 @@
>-SHA256 (u-boot-openbsd-v2023.07.02.tar.gz) = 
>aKuZg4uGmNDt9aaoKTjMrdkYJUKZbKqt3JHZtKWJquE=
>-SIZE (u-boot-openbsd-v2023.07.02.tar.gz) = 25087062
>+SHA256 (u-boot-openbsd-v2023.07.02-1.tar.gz) = 
>sVhMi6ZAIReDCU+Ps0BnYzOgMMftVpw2K8gNl7HR3b0=
>+SIZE (u-boot-openbsd-v2023.07.02-1.tar.gz) = 25088652

Re: Fix u-boot-asahi plist

2023-12-03 Thread Tobias Heider

On Sun, Dec 03, 2023 at 10:08:24PM +0100, Mark Kettenis wrote:
> Add a few files that were missed in a previous update.
> 
> ok?

ok tobhe@

> 
> 
> Index: sysutils/u-boot-asahi/Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot-asahi/Makefile,v
> retrieving revision 1.12
> diff -u -p -r1.12 Makefile
> --- sysutils/u-boot-asahi/Makefile10 Sep 2023 15:18:39 -  1.12
> +++ sysutils/u-boot-asahi/Makefile3 Dec 2023 21:03:44 -
> @@ -6,6 +6,7 @@ VERSION=  2023.07.02
>  GH_ACCOUNT=  AsahiLinux
>  GH_PROJECT=  u-boot
>  GH_TAGNAME=  openbsd-v${VERSION}
> +REVISION=0
>  
>  PKGNAME= u-boot-asahi-${VERSION:S/-/./g}
>  
> Index: sysutils/u-boot-asahi/pkg/PLIST
> ===
> RCS file: /cvs/ports/sysutils/u-boot-asahi/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -r1.3 PLIST
> --- sysutils/u-boot-asahi/pkg/PLIST   11 Nov 2022 19:38:11 -  1.3
> +++ sysutils/u-boot-asahi/pkg/PLIST   3 Dec 2023 21:03:44 -
> @@ -8,12 +8,19 @@ share/u-boot/apple_m1/dts/t6001-j314c.dt
>  share/u-boot/apple_m1/dts/t6001-j316c.dtb
>  share/u-boot/apple_m1/dts/t6001-j375c.dtb
>  share/u-boot/apple_m1/dts/t6002-j375d.dtb
> +share/u-boot/apple_m1/dts/t6020-j414s.dtb
> +share/u-boot/apple_m1/dts/t6020-j474s.dtb
> +share/u-boot/apple_m1/dts/t6021-j414c.dtb
> +share/u-boot/apple_m1/dts/t6021-j416c.dtb
> +share/u-boot/apple_m1/dts/t6022-j180d.dtb
>  share/u-boot/apple_m1/dts/t8103-j274.dtb
>  share/u-boot/apple_m1/dts/t8103-j293.dtb
>  share/u-boot/apple_m1/dts/t8103-j313.dtb
>  share/u-boot/apple_m1/dts/t8103-j456.dtb
>  share/u-boot/apple_m1/dts/t8103-j457.dtb
>  share/u-boot/apple_m1/dts/t8112-j413.dtb
> +share/u-boot/apple_m1/dts/t8112-j415.dtb
> +share/u-boot/apple_m1/dts/t8112-j473.dtb
>  share/u-boot/apple_m1/dts/t8112-j493.dtb
>  share/u-boot/apple_m1/u-boot
>  share/u-boot/apple_m1/u-boot-nodtb.bin
>

Re: NEW: lang/hare

2023-12-03 Thread Tobias Heider




On December 3, 2023 1:22:31 PM GMT+01:00, Omar Polo  wrote:
>On 2023/12/03 12:05:20 +0100, Tobias Heider  wrote:
>> On Sun, Dec 03, 2023 at 08:07:19AM +0100, Lorenz (xha) wrote:
>> > thanks for the port ;-)
>> > 
>> > On Sat, Dec 02, 2023 at 10:54:47PM +0100, Tobias Heider wrote:
>> > > On Sat, Dec 02, 2023 at 08:46:11PM +, Brian Callahan wrote:
>> > > > Hi ports --
>> > > > 
>> > > > Attached is a new port for the Hare programming language. Support for
>> > > > OpenBSD was just announced.
>> > > > 
>> > > > This is good enough to compile the Hello world example on the main
>> > > > harelang.org. The port itself is a snapshot I just made of the mainline
>> > > > code, making sure to include some additional improvements from tobhe@
>> > > > that just hit their tree.
>> > > > 
>> > > > Specifically looking for arm64 and riscv64 testing. I've only been able
>> > > > to test it on amd64. I believe some tweaks will be needed for the other
>> > > > archs.
>> > > > 
>> > > > There are a small number of tests that fail, and one that segfaults, 
>> > > > but
>> > > > as support is brand new, I don't think that's necessarily a 
>> > > > showstopper.
>> > 
>> > can you tell me which test segfaults so i can fix this? all tests should
>> > and are passing for me (amd64)
>> 
>> The harec tests don't seem to work at all for me.
>
>I'm new to hare, just playing with it, so sorry for chiming in, but
>tests are fully passing for me, both hare and harec ones.  (There are
>three skipped tests in hare, but it's just the 'slow tests'.)
>
>I'm on amd64 without ibt.

this could be an arm64 bug then

>
>> > > > 
>> > > > OK?
>> > > > 
>> > > > ~Brian
>
>I'm just starting with it, but the hello word and other example code
>from the website works, and i did the first "challenge" of the advent of
>code in it.  Works enough to be hooked in the tree IMHO :)
>
>so ok op@ if you want to import it.

Agree, ok from me too. we can fix the remaining warts in-tree

>
>(the XXX comment in harec/Makefile can be dropped, from what I see
>there's a typo in the upstream makefile that you're patching anyway.)
>

Re: NEW: lang/hare

2023-12-03 Thread Tobias Heider

On Sun, Dec 03, 2023 at 08:07:19AM +0100, Lorenz (xha) wrote:
> thanks for the port ;-)
> 
> On Sat, Dec 02, 2023 at 10:54:47PM +0100, Tobias Heider wrote:
> > On Sat, Dec 02, 2023 at 08:46:11PM +, Brian Callahan wrote:
> > > Hi ports --
> > > 
> > > Attached is a new port for the Hare programming language. Support for
> > > OpenBSD was just announced.
> > > 
> > > This is good enough to compile the Hello world example on the main
> > > harelang.org. The port itself is a snapshot I just made of the mainline
> > > code, making sure to include some additional improvements from tobhe@
> > > that just hit their tree.
> > > 
> > > Specifically looking for arm64 and riscv64 testing. I've only been able
> > > to test it on amd64. I believe some tweaks will be needed for the other
> > > archs.
> > > 
> > > There are a small number of tests that fail, and one that segfaults, but
> > > as support is brand new, I don't think that's necessarily a showstopper.
> 
> can you tell me which test segfaults so i can fix this? all tests should
> and are passing for me (amd64)

The harec tests don't seem to work at all for me.

> 
> > > 
> > > OK?
> > > 
> > > ~Brian
> > 
> > arm64 needs a little more work
> > 
> > 1. We need to fix the _start hook, I submitted a fix upstream at
> > https://lists.sr.ht/~sircmpwn/hare-dev/patches/47286
> > 
> > 2. config.mk hardcodes amd64 and always treats arm and riscv as if
> > it was cross compiled. we need to change this to work for natively
> > 
> > This works on arm64:
> > 
> > diff -Nru hare/hare/Makefile hare2/hare/Makefile
> > --- hare/hare/Makefile  Sat Dec  2 21:34:50 2023
> > +++ hare2/hare/Makefile Sat Dec  2 22:53:42 2023
> > @@ -13,5 +13,8 @@
> >  
> >  do-gen:
> > cp ${WRKSRC}/configs/openbsd.mk ${WRKSRC}/config.mk
> > +   sed -i "s/aarch64-//g" ${WRKSRC}/config.mk
> > +   sed -i "s/riscv64-//g" ${WRKSRC}/config.mk
> 
> can upstream this if you want. i think it doesn't make sense to always
> assume cross-compilation.

Sure, I can send a diff. I was planning to experiment some more and see if
we can make the default saner (assume host == target).

> 
> > +   echo "ARCH = $$(arch -s)" >> ${WRKSRC}/config.mk
> >  
> >  .include 
> > diff -Nru hare/harec/patches/patch-rt_+openbsd_start+aarch64_s 
> > hare2/harec/patches/patch-rt_+openbsd_start+aarch64_s
> > --- hare/harec/patches/patch-rt_+openbsd_start+aarch64_sThu Jan  1 
> > 01:00:00 1970
> > +++ hare2/harec/patches/patch-rt_+openbsd_start+aarch64_s   Sat Dec  2 
> > 22:25:37 2023
> > @@ -0,0 +1,9 @@
> > +Index: rt/+openbsd/start+aarch64.s
> > +--- rt/+openbsd/start+aarch64.s.orig
> >  rt/+openbsd/start+aarch64.s
> > +@@ -5,5 +5,4 @@ _start:
> > +   mov x30, #0
> > +   mov x0, sp
> > +   add sp, x0, #-16
> > +-  and sp, sp, #-16
> > +   b rt.start_ha
> > 
> 
> this is already upstreamed.

Re: NEW: lang/hare

2023-12-02 Thread Tobias Heider

On Sat, Dec 02, 2023 at 08:46:11PM +, Brian Callahan wrote:
> Hi ports --
> 
> Attached is a new port for the Hare programming language. Support for
> OpenBSD was just announced.
> 
> This is good enough to compile the Hello world example on the main
> harelang.org. The port itself is a snapshot I just made of the mainline
> code, making sure to include some additional improvements from tobhe@
> that just hit their tree.
> 
> Specifically looking for arm64 and riscv64 testing. I've only been able
> to test it on amd64. I believe some tweaks will be needed for the other
> archs.
> 
> There are a small number of tests that fail, and one that segfaults, but
> as support is brand new, I don't think that's necessarily a showstopper.
> 
> OK?
> 
> ~Brian

arm64 needs a little more work

1. We need to fix the _start hook, I submitted a fix upstream at
https://lists.sr.ht/~sircmpwn/hare-dev/patches/47286

2. config.mk hardcodes amd64 and always treats arm and riscv as if
it was cross compiled. we need to change this to work for natively

This works on arm64:

diff -Nru hare/hare/Makefile hare2/hare/Makefile
--- hare/hare/Makefile  Sat Dec  2 21:34:50 2023
+++ hare2/hare/Makefile Sat Dec  2 22:53:42 2023
@@ -13,5 +13,8 @@
 
 do-gen:
cp ${WRKSRC}/configs/openbsd.mk ${WRKSRC}/config.mk
+   sed -i "s/aarch64-//g" ${WRKSRC}/config.mk
+   sed -i "s/riscv64-//g" ${WRKSRC}/config.mk
+   echo "ARCH = $$(arch -s)" >> ${WRKSRC}/config.mk
 
 .include 
diff -Nru hare/harec/patches/patch-rt_+openbsd_start+aarch64_s 
hare2/harec/patches/patch-rt_+openbsd_start+aarch64_s
--- hare/harec/patches/patch-rt_+openbsd_start+aarch64_sThu Jan  1 
01:00:00 1970
+++ hare2/harec/patches/patch-rt_+openbsd_start+aarch64_s   Sat Dec  2 
22:25:37 2023
@@ -0,0 +1,9 @@
+Index: rt/+openbsd/start+aarch64.s
+--- rt/+openbsd/start+aarch64.s.orig
 rt/+openbsd/start+aarch64.s
+@@ -5,5 +5,4 @@ _start:
+   mov x30, #0
+   mov x0, sp
+   add sp, x0, #-16
+-  and sp, sp, #-16
+   b rt.start_ha

Re: textproc/ripgrep: update to 14.0.1

2023-11-27 Thread Tobias Heider

On Mon, Nov 27, 2023 at 11:19:39AM +, Klemens Nanni wrote:
> https://github.com/BurntSushi/ripgrep/releases
> 
> Manpage and shell completions are now generated by rg.
> 
> amd64:
> test result: ok. 297 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 
> finished in 6.38s
> 
> Feedback? OK?

Looks like Laurent was a little bit faster:
https://marc.info/?l=openbsd-ports=170108184208404=2

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/ripgrep/Makefile,v
> diff -u -p -r1.27 Makefile
> --- Makefile  6 Mar 2023 18:45:42 -   1.27
> +++ Makefile  27 Nov 2023 11:09:03 -
> @@ -2,8 +2,7 @@ COMMENT = line oriented search tool usi
>  
>  GH_ACCOUNT = BurntSushi
>  GH_PROJECT = ripgrep
> -GH_TAGNAME = 13.0.0
> -REVISION =   3
> +GH_TAGNAME = 14.0.1
>  
>  CATEGORIES = textproc sysutils
>  
> @@ -13,7 +12,6 @@ PERMIT_PACKAGE =Yes
>  WANTLIB +=   c c++abi pthread
>  
>  MODULES =devel/cargo
> -BUILD_DEPENDS =  textproc/asciidoctor
>  
>  CONFIGURE_STYLE =cargo
>  
> @@ -26,6 +24,11 @@ MODCARGO_RUSTFLAGS =   -C debuginfo=0
>  RELEASE_DIR =${MODCARGO_TARGET_DIR}/release
>  OUT_DIR =${RELEASE_DIR}/build/ripgrep-*/out
>  
> +post-build:
> + cd ${OUT_DIR} && ${RELEASE_DIR}/rg --generate man > ./rg.1
> + cd ${OUT_DIR} && ${RELEASE_DIR}/rg --generate complete-bash > ./rg.bash
> + cd ${OUT_DIR} && ${RELEASE_DIR}/rg --generate complete-zsh > ./_rg
> +
>  # fish completion excluded as it is shipped with shells/fish
>  do-install:
>   ${INSTALL_PROGRAM} ${RELEASE_DIR}/rg ${PREFIX}/bin/
> @@ -34,7 +37,7 @@ do-install:
>   ${PREFIX}/share/zsh/site-functions
>   ${INSTALL_DATA} ${OUT_DIR}/rg.bash \
>   ${PREFIX}/share/bash-completion/completions/rg
> - ${INSTALL_DATA} ${WRKSRC}/complete/_rg \
> + ${INSTALL_DATA} ${OUT_DIR}/_rg \
>   ${PREFIX}/share/zsh/site-functions/_rg
>  
>  .include "crates.inc"
> Index: crates.inc
> ===
> RCS file: /cvs/ports/textproc/ripgrep/crates.inc,v
> diff -u -p -r1.3 crates.inc
> --- crates.inc24 Aug 2022 21:43:09 -  1.3
> +++ crates.inc27 Nov 2023 11:10:10 -
> @@ -1,56 +1,49 @@
> -MODCARGO_CRATES +=   aho-corasick0.7.18  # Unlicense/MIT
> -MODCARGO_CRATES +=   atty0.2.14  # MIT
> -MODCARGO_CRATES +=   base64  0.13.0  # MIT/Apache-2.0
> -MODCARGO_CRATES +=   bitflags1.2.1   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   bstr0.2.16  # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   bytecount   0.6.2   # Apache-2.0/MIT
> -MODCARGO_CRATES +=   cc  1.0.73  # MIT/Apache-2.0
> -MODCARGO_CRATES +=   cfg-if  0.1.10  # MIT/Apache-2.0
> +MODCARGO_CRATES +=   aho-corasick1.1.2   # Unlicense OR MIT
> +MODCARGO_CRATES +=   anyhow  1.0.75  # MIT OR Apache-2.0
> +MODCARGO_CRATES +=   autocfg 1.1.0   # Apache-2.0 OR MIT
> +MODCARGO_CRATES +=   bstr1.8.0   # MIT OR Apache-2.0
> +MODCARGO_CRATES +=   cc  1.0.83  # MIT OR Apache-2.0
>  MODCARGO_CRATES +=   cfg-if  1.0.0   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   clap2.33.3  # MIT
> -MODCARGO_CRATES +=   crossbeam-channel   0.5.1   # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   crossbeam-utils 0.8.5   # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   encoding_rs 0.8.28  # Apache-2.0 OR MIT
> +MODCARGO_CRATES +=   crossbeam-channel   0.5.8   # MIT OR Apache-2.0
> +MODCARGO_CRATES +=   crossbeam-deque 0.8.3   # MIT OR Apache-2.0
> +MODCARGO_CRATES +=   crossbeam-epoch 0.9.15  # MIT OR Apache-2.0
> +MODCARGO_CRATES +=   crossbeam-utils 0.8.16  # MIT OR Apache-2.0
> +MODCARGO_CRATES +=   encoding_rs 0.8.33  # (Apache-2.0 OR MIT) AND 
> BSD-3-Clause
>  MODCARGO_CRATES +=   encoding_rs_io  0.1.7   # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   fnv 1.0.7   # Apache-2.0 / MIT
> -MODCARGO_CRATES +=   fs_extra1.2.0   # MIT
> -MODCARGO_CRATES +=   glob0.3.0   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   hermit-abi  0.1.18  # MIT/Apache-2.0
> -MODCARGO_CRATES +=   itoa0.4.7   # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   jemalloc-sys0.3.2   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   jemallocator0.3.2   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   jobserver   0.1.22  # MIT/Apache-2.0
> -MODCARGO_CRATES +=   lazy_static 1.4.0   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   libc0.2.132 # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   libm0.1.4   # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   log 0.4.14  # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   memchr  2.4.0   # Unlicense/MIT
> -MODCARGO_CRATES +=   memmap2 0.3.0   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   num_cpus1.13.0  # MIT/Apache-2.0
> -MODCARGO_CRATES +=   once_cell   1.7.2   # MIT OR Apache-2.0
> -MODCARGO_CRATES +=   packed_simd_2   0.3.5   # MIT/Apache-2.0
> -MODCARGO_CRATES +=   pcre2

CVS: cvs.openbsd.org: ports

2023-11-27 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/11/27 04:23:04

Modified files:
www/chromium   : Makefile 
www/ungoogled-chromium: Makefile 

Log message:
Prefer base-clang now that we have 16 and rebuild with latest arm64 bti fixes.

ok robert@

CVS: cvs.openbsd.org: ports

2023-11-27 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/11/27 04:13:51

Modified files:
www/iridium: Makefile 

Log message:
Bump REVISION for rebuild with latest llvm fixes

ok robert@

CVS: cvs.openbsd.org: ports

2023-11-27 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/11/27 03:51:37

Modified files:
devel/llvm/16/patches: patch-lld_ELF_Arch_AArch64_cpp 
   patch-lld_ELF_Symbols_cpp 
   patch-lld_ELF_Symbols_h 
Added files:
devel/llvm/16/patches: patch-lld_ELF_Thunks_cpp 
   patch-lld_test_ELF_aarch64-feature-bti-plt_s 

Log message:
llvm/16: sync arm64 bti fix for range extension thunks from base

Large arm64 binaries like chromium use range extension thunks
for accessing plt entries. Add bti landing pads for the
additional indirection.

upstream commit: 60827df765156cee6cca3dc5049388dde9dac1c0

ok robert@ kettenis@

llvm: arm64 bti lld fix

2023-11-26 Thread Tobias Heider

Here's the same lld fix I sent to tech earlier.
This is needed to make chromium work on arm64 machines with bti.

Previous mail:
https://marc.info/?l=openbsd-tech=170099852707132=2

Upstream fix:
https://github.com/llvm/llvm-project/commit/60827df765156cee6cca3dc5049388dde9dac1c0

ok?

Index: Makefile
===
RCS file: /cvs/ports/devel/llvm/16/Makefile,v
diff -u -p -r1.20 Makefile
--- Makefile13 Nov 2023 13:57:37 -  1.20
+++ Makefile26 Nov 2023 14:11:32 -
@@ -2,7 +2,7 @@ LLVM_MAJOR =16
 LLVM_VERSION = ${LLVM_MAJOR}.0.6
 LLVM_PKGSPEC = >=16,<17
 
-REVISION-main =18
+REVISION-main =19
 REVISION-lldb =3
 REVISION-python =  1
 
Index: patches/patch-lld_ELF_Arch_AArch64_cpp
===
RCS file: /cvs/ports/devel/llvm/16/patches/patch-lld_ELF_Arch_AArch64_cpp,v
diff -u -p -r1.1.1.1 patch-lld_ELF_Arch_AArch64_cpp
--- patches/patch-lld_ELF_Arch_AArch64_cpp  3 Sep 2023 16:00:03 -   
1.1.1.1
+++ patches/patch-lld_ELF_Arch_AArch64_cpp  26 Nov 2023 14:11:32 -
@@ -13,7 +13,17 @@ Index: lld/ELF/Arch/AArch64.cpp
// A BTI (Branch Target Indicator) Plt Entry is only required if the
// address of the PLT entry can be taken by the program, which permits an
// indirect jump to the PLT entry. This can happen when the address
-@@ -936,6 +940,10 @@ void AArch64BtiPac::writePlt(uint8_t *buf, const Symbo
+@@ -912,7 +916,8 @@ void AArch64BtiPac::writePlt(uint8_t *buf, const Symbo
+   // escape to shared objects. isInIplt indicates a non-preemptible ifunc. Its
+   // address may escape if referenced by a direct relocation. The condition is
+   // conservative.
+-  bool hasBti = btiHeader && (sym.hasFlag(NEEDS_COPY) || sym.isInIplt);
++  bool hasBti = btiHeader &&
++(sym.hasFlag(NEEDS_COPY) || sym.isInIplt || 
sym.thunkAccessed);
+   if (hasBti) {
+ memcpy(buf, btiData, sizeof(btiData));
+ buf += sizeof(btiData);
+@@ -936,6 +941,10 @@ void AArch64BtiPac::writePlt(uint8_t *buf, const Symbo
  }
  
  static TargetInfo *getTargetInfo() {
@@ -24,7 +34,7 @@ Index: lld/ELF/Arch/AArch64.cpp
if ((config->andFeatures & GNU_PROPERTY_AARCH64_FEATURE_1_BTI) ||
config->zPacPlt) {
  static AArch64BtiPac t;
-@@ -943,6 +951,7 @@ static TargetInfo *getTargetInfo() {
+@@ -943,6 +952,7 @@ static TargetInfo *getTargetInfo() {
}
static AArch64 t;
return 
Index: patches/patch-lld_ELF_Symbols_cpp
===
RCS file: /cvs/ports/devel/llvm/16/patches/patch-lld_ELF_Symbols_cpp,v
diff -u -p -r1.1.1.1 patch-lld_ELF_Symbols_cpp
--- patches/patch-lld_ELF_Symbols_cpp   3 Sep 2023 16:00:03 -   1.1.1.1
+++ patches/patch-lld_ELF_Symbols_cpp   26 Nov 2023 14:11:32 -
@@ -1,6 +1,15 @@
 Index: lld/ELF/Symbols.cpp
 --- lld/ELF/Symbols.cpp.orig
 +++ lld/ELF/Symbols.cpp
+@@ -25,7 +25,7 @@ using namespace llvm::ELF;
+ using namespace lld;
+ using namespace lld::elf;
+ 
+-static_assert(sizeof(SymbolUnion) <= 64, "SymbolUnion too large");
++static_assert(sizeof(SymbolUnion) <= 72, "SymbolUnion too large");
+ 
+ template  struct AssertSymbol {
+   static_assert(std::is_trivially_destructible(),
 @@ -61,6 +61,7 @@ std::string lld::toString(const elf::Symbol ) {
  }
  
Index: patches/patch-lld_ELF_Symbols_h
===
RCS file: /cvs/ports/devel/llvm/16/patches/patch-lld_ELF_Symbols_h,v
diff -u -p -r1.1.1.1 patch-lld_ELF_Symbols_h
--- patches/patch-lld_ELF_Symbols_h 3 Sep 2023 16:00:03 -   1.1.1.1
+++ patches/patch-lld_ELF_Symbols_h 26 Nov 2023 14:11:32 -
@@ -20,7 +20,17 @@ Index: lld/ELF/Symbols.h
  
void overwrite(Symbol , Kind k) const {
  if (sym.traced)
-@@ -490,6 +493,9 @@ struct ElfSym {
+@@ -292,6 +295,9 @@ class Symbol { (public)
+   // True if defined in a DSO as protected visibility.
+   uint8_t dsoProtected : 1;
+ 
++  // True if targeted by a range extension thunk.
++  uint8_t thunkAccessed : 1;
++
+   // Temporary flags used to communicate which symbol entries need PLT and GOT
+   // entries during postScanRelocations();
+   std::atomic flags;
+@@ -490,6 +496,9 @@ struct ElfSym {
// __bss_start
static Defined *bss;
  
@@ -30,7 +40,7 @@ Index: lld/ELF/Symbols.h
// etext and _etext
static Defined *etext1;
static Defined *etext2;
-@@ -546,6 +552,8 @@ void reportDuplicate(const Symbol , const InputFil
+@@ -546,6 +555,8 @@ void reportDuplicate(const Symbol , const InputFil
   InputSectionBase *errSec, uint64_t errOffset);
  void maybeWarnUnorderableSymbol(const Symbol *sym);
  bool computeIsPreemptible(const Symbol );
Index: patches/patch-lld_ELF_Thunks_cpp
===
RCS file: patches/patch-lld_ELF_Thunks_cpp
diff -N patches/patch-lld_ELF_Thunks_cpp
---

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

2023-11-24 Thread Tobias Heider

On Fri, Nov 24, 2023 at 03:23:46PM +0100, Tobias Heider wrote:
> On Fri, Nov 24, 2023 at 08:36:03AM +0100, Sebastien Marie wrote:
> > Tobias Heider  writes:
> >
> > > On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
> > >> gkoeh...@openbsd.org writes:
> > >> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
> > >>
> > >> Could someone test the following patch for lang/sbcl on powerpc ?
> > >> If it works, I will push it upstream.
> > >
> > > This fixes the first problem but after that I ran into an undefined
> > > symbol current_thread error.
> > >
> > > It looks like arm64 already handles this correctly in arm64-assem.S:114
> > > but a simple s/current_thread/__emutls_v.current_thread/ was not enough
> > > since it caused runtime errors later on.
> >
> > oh.
> >
> > direct TLS seems to not be expected for powerpc: Linux code enable it
> > only for some archs (and ppc isn't in the list). So follow the same way.
> >
> > Does it correct the problem ? (and does #include "validate.h" is still
> > need ?)
> >
> > Thanks.
> >
> 
> Sadly this seems to give me the same error that I got with 
> __emutls_v.current_thread:
> 
> //doing warm init - compilation phase
> This is SBCL 2.3.10.openbsd.sbcl-2.3.10, an implementation of ANSI Common 
> Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
> 
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> Initial page table:
> Immobile Object Counts
>  Gen layout fdefn symbol   code  Boxed   ConsRaw   Code  SmMix  Mixed  
> LgRaw LgCode  LgMix Waste%   AllocTrig   Dirty GCs Mem-age
>   6  0  0  0  0  0501  0   3505  0   3591 
>  0  0  00.430986640 2003505   0  0.
> Tot  0  0  0  0  0501  0   3505  0   3591 
>  0  0  00.430986640 [5.8% of 536870912 max]
> fatal error encountered in SBCL pid 94032 pthread 0xc50e1d94:
> maximum interrupt nesting depth (8) exceeded
> 
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> //doing warm init - load and dump phase
> fatal error encountered in SBCL pid 52269 pthread 0xc040cd94:
> maximum interrupt nesting depth (8) exceeded
> 
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> [1] + Stopped (tty input)  ./src/runtime/sbcl --core 
> output/cold-sbcl.core
> [2] - Stopped (tty input)  ./src/runtime/sbcl --noinform --core output/col
> 0m00.51s real 0m00.01s user 0m00.01s system
> //entering make-target-contrib.sh
> 

Just realized that that was a lie.  I was looking at the wrong tmux pane...
Your fix seems to work. Thank you!

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

2023-11-24 Thread Tobias Heider

On Fri, Nov 24, 2023 at 08:36:03AM +0100, Sebastien Marie wrote:
> Tobias Heider  writes:
>
> > On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
> >> gkoeh...@openbsd.org writes:
> >> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
> >>
> >> Could someone test the following patch for lang/sbcl on powerpc ?
> >> If it works, I will push it upstream.
> >
> > This fixes the first problem but after that I ran into an undefined
> > symbol current_thread error.
> >
> > It looks like arm64 already handles this correctly in arm64-assem.S:114
> > but a simple s/current_thread/__emutls_v.current_thread/ was not enough
> > since it caused runtime errors later on.
>
> oh.
>
> direct TLS seems to not be expected for powerpc: Linux code enable it
> only for some archs (and ppc isn't in the list). So follow the same way.
>
> Does it correct the problem ? (and does #include "validate.h" is still
> need ?)
>
> Thanks.
>

Sadly this seems to give me the same error that I got with 
__emutls_v.current_thread:

//doing warm init - compilation phase
This is SBCL 2.3.10.openbsd.sbcl-2.3.10, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
Initial page table:
Immobile Object Counts
 Gen layout fdefn symbol   code  Boxed   ConsRaw   Code  SmMix  Mixed  
LgRaw LgCode  LgMix Waste%   AllocTrig   Dirty GCs Mem-age
  6  0  0  0  0  0501  0   3505  0   3591  
0  0  00.430986640 2003505   0  0.
Tot  0  0  0  0  0501  0   3505  0   3591  
0  0  00.430986640 [5.8% of 536870912 max]
fatal error encountered in SBCL pid 94032 pthread 0xc50e1d94:
maximum interrupt nesting depth (8) exceeded

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> //doing warm init - load and dump phase
fatal error encountered in SBCL pid 52269 pthread 0xc040cd94:
maximum interrupt nesting depth (8) exceeded

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> [1] + Stopped (tty input)  ./src/runtime/sbcl --core output/cold-sbcl.core
[2] - Stopped (tty input)  ./src/runtime/sbcl --noinform --core output/col
0m00.51s real 0m00.01s user 0m00.01s system
//entering make-target-contrib.sh

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

2023-11-23 Thread Tobias Heider

On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
> gkoeh...@openbsd.org writes:
> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
> 
> Could someone test the following patch for lang/sbcl on powerpc ?
> If it works, I will push it upstream.

This fixes the first problem but after that I ran into an undefined
symbol current_thread error.

It looks like arm64 already handles this correctly in arm64-assem.S:114
but a simple s/current_thread/__emutls_v.current_thread/ was not enough
since it caused runtime errors later on.

CVS: cvs.openbsd.org: ports

2023-11-22 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/11/22 07:18:03

Modified files:
devel/libffi   : Makefile 
Added files:
devel/libffi/patches: patch-src_aarch64_ffi_c 
  patch-src_aarch64_sysv_S 

Log message:
Fix BTI in arm64 assembly by adding bti instructions to function
calls and jump tables

feedback from kettenis@
ok jasper@

Re: libffi: fix arm64 bti

2023-11-21 Thread Tobias Heider

On Tue, Nov 21, 2023 at 04:48:29PM +0100, Mark Kettenis wrote:
> > Date: Tue, 21 Nov 2023 16:08:13 +0100
> > From: Tobias Heider 
> > 
> > On Tue, Nov 21, 2023 at 12:23:08PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 21 Nov 2023 12:04:42 +0100
> > > > From: Tobias Heider 
> > > > 
> > > > On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote:
> > > > > > Date: Tue, 21 Nov 2023 00:16:40 +0100
> > > > > > From: Tobias Heider 
> > > > > > 
> > > > > > Diff below fixes make regress for libffi with arm64 BTI enabled.
> > > > > > The tricky part were two jump tables in ffi.c and sysV.S.
> > > > > > 
> > > > > > ok?
> > > > > 
> > > > > I think you missed the "computed goto" in ffi_closure_SYSV.
> > > > > 
> > > > > Maybe we shouldn't add a "bti j" for the unused slots?
> > > > 
> > > > Functionally yes, that should also work and makes more sense.
> > > > But then the brks would be a bit redundant. I wasn't sure if there
> > > > are tests or something that expects those breaks to be reachable.
> > > 
> > > The brks still need to be there for those poor CPUs that don't
> > > implement BTI.
> > > 
> > 
> > Here is an updated diff where all reserved and unused entries
> > don't get bti j.  make regress still passes.
> 
> Looks like you missed my comment about ffi_closure_SYSV.

urgh yes, missed that. fixed in diff below

> Is the closures stuff not tested as part of make regress?

it seems like a lot of tests are skipped in our port. I'll see
if I can force it to run a few more.

# of expected passes5822
# of unsupported tests  209 

Index: Makefile
===
RCS file: /cvs/ports/devel/libffi/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile21 Sep 2023 09:49:57 -  1.48
+++ Makefile21 Nov 2023 16:07:43 -
@@ -1,6 +1,7 @@
 COMMENT=   Foreign Function Interface
 
 V= 3.4.4
+REVISION=  0
 DISTNAME=  libffi-$V
 SHARED_LIBS +=  ffi  2.0  # 9.2
 CATEGORIES=devel
Index: patches/patch-src_aarch64_ffi_c
===
RCS file: patches/patch-src_aarch64_ffi_c
diff -N patches/patch-src_aarch64_ffi_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_aarch64_ffi_c 21 Nov 2023 16:07:43 -
@@ -0,0 +1,76 @@
+Index: src/aarch64/ffi.c
+--- src/aarch64/ffi.c.orig
 src/aarch64/ffi.c
+@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h)
+   "adr%0, 0f\n"
+ " add %0, %0, %1\n"
+ " br  %0\n"
+-"0:   ldp s16, s17, [%3]\n"   /* S4 */
++"0:   bti j\n"/* S4 */
++" ldp s16, s17, [%3]\n"
+ " ldp s18, s19, [%3, #8]\n"
+ " b   4f\n"
+-" ldp s16, s17, [%3]\n"   /* S3 */
++" bti j\n"/* S3 */
++" ldp s16, s17, [%3]\n"
+ " ldr s18, [%3, #8]\n"
+ " b   3f\n"
+-" ldp s16, s17, [%3]\n"   /* S2 */
++" bti j\n"/* S2 */
++" ldp s16, s17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr s16, [%3]\n"/* S1 */
++" bti j\n"/* S1 */
++" ldr s16, [%3]\n"
+ " b   1f\n"
+ " nop\n"
+-" ldp d16, d17, [%3]\n"   /* D4 */
++" bti j\n"/* D4 */
++" ldp d16, d17, [%3]\n"
+ " ldp d18, d19, [%3, #16]\n"
+ " b   4f\n"
+-" ldp d16, d17, [%3]\n"   /* D3 */
++" bti j\n"/* D3 */
++" ldp d16, d17, [%3]\n"
+ " ldr d18, [%3, #16]\n"
+ " b   3f\n"
+-" ldp d16, d17, [%3]\n"   /* D2 */
++" bti j\n"/* D2 */
++" ldp d16, d17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr d16, [%3]\n"/* D1 */
++" bti j\n"/* D1 */
++" ldr d16, [%3]\n"
+ " b   1f\n"
+ " nop\n"
+-" ldp q16, q17, [%3]\n"   /* Q4 */
++" bti j\n"

Re: libffi: fix arm64 bti

2023-11-21 Thread Tobias Heider

On Tue, Nov 21, 2023 at 12:23:08PM +0100, Mark Kettenis wrote:
> > Date: Tue, 21 Nov 2023 12:04:42 +0100
> > From: Tobias Heider 
> > 
> > On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 21 Nov 2023 00:16:40 +0100
> > > > From: Tobias Heider 
> > > > 
> > > > Diff below fixes make regress for libffi with arm64 BTI enabled.
> > > > The tricky part were two jump tables in ffi.c and sysV.S.
> > > > 
> > > > ok?
> > > 
> > > I think you missed the "computed goto" in ffi_closure_SYSV.
> > > 
> > > Maybe we shouldn't add a "bti j" for the unused slots?
> > 
> > Functionally yes, that should also work and makes more sense.
> > But then the brks would be a bit redundant. I wasn't sure if there
> > are tests or something that expects those breaks to be reachable.
> 
> The brks still need to be there for those poor CPUs that don't
> implement BTI.
> 

Here is an updated diff where all reserved and unused entries
don't get bti j.  make regress still passes.

Index: Makefile
===
RCS file: /cvs/ports/devel/libffi/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile21 Sep 2023 09:49:57 -  1.48
+++ Makefile21 Nov 2023 15:05:33 -
@@ -1,6 +1,7 @@
 COMMENT=   Foreign Function Interface
 
 V= 3.4.4
+REVISION=  0
 DISTNAME=  libffi-$V
 SHARED_LIBS +=  ffi  2.0  # 9.2
 CATEGORIES=devel
Index: patches/patch-src_aarch64_ffi_c
===
RCS file: patches/patch-src_aarch64_ffi_c
diff -N patches/patch-src_aarch64_ffi_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_aarch64_ffi_c 21 Nov 2023 15:05:33 -
@@ -0,0 +1,76 @@
+Index: src/aarch64/ffi.c
+--- src/aarch64/ffi.c.orig
 src/aarch64/ffi.c
+@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h)
+   "adr%0, 0f\n"
+ " add %0, %0, %1\n"
+ " br  %0\n"
+-"0:   ldp s16, s17, [%3]\n"   /* S4 */
++"0:   bti j\n"/* S4 */
++" ldp s16, s17, [%3]\n"
+ " ldp s18, s19, [%3, #8]\n"
+ " b   4f\n"
+-" ldp s16, s17, [%3]\n"   /* S3 */
++" bti j\n"/* S3 */
++" ldp s16, s17, [%3]\n"
+ " ldr s18, [%3, #8]\n"
+ " b   3f\n"
+-" ldp s16, s17, [%3]\n"   /* S2 */
++" bti j\n"/* S2 */
++" ldp s16, s17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr s16, [%3]\n"/* S1 */
++" bti j\n"/* S1 */
++" ldr s16, [%3]\n"
+ " b   1f\n"
+ " nop\n"
+-" ldp d16, d17, [%3]\n"   /* D4 */
++" bti j\n"/* D4 */
++" ldp d16, d17, [%3]\n"
+ " ldp d18, d19, [%3, #16]\n"
+ " b   4f\n"
+-" ldp d16, d17, [%3]\n"   /* D3 */
++" bti j\n"/* D3 */
++" ldp d16, d17, [%3]\n"
+ " ldr d18, [%3, #16]\n"
+ " b   3f\n"
+-" ldp d16, d17, [%3]\n"   /* D2 */
++" bti j\n"/* D2 */
++" ldp d16, d17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr d16, [%3]\n"/* D1 */
++" bti j\n"/* D1 */
++" ldr d16, [%3]\n"
+ " b   1f\n"
+ " nop\n"
+-" ldp q16, q17, [%3]\n"   /* Q4 */
++" bti j\n"/* Q4 */
++" ldp q16, q17, [%3]\n"
+ " ldp q18, q19, [%3, #32]\n"
+ " b   4f\n"
+-" ldp q16, q17, [%3]\n"   /* Q3 */
++" bti j\n"/* Q3 */
++" ldp q16, q17, [%3]\n"
+ " ldr q18, [%3, #32]\n"
+ " b   3f\n"
+-" ldp q16, q17, [%3]\n"   /* Q2 */
++" bti j\n"/* Q2 */
++" ldp q16, q17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr q16, [%3]\n"/* Q1 */
++" bti j\n"/* Q1 */
++" ldr q16, [%3]\n"
+ " b

Re: libffi: fix arm64 bti

2023-11-21 Thread Tobias Heider

On Tue, Nov 21, 2023 at 11:56:18AM +0100, Mark Kettenis wrote:
> > Date: Tue, 21 Nov 2023 00:16:40 +0100
> > From: Tobias Heider 
> > 
> > Diff below fixes make regress for libffi with arm64 BTI enabled.
> > The tricky part were two jump tables in ffi.c and sysV.S.
> > 
> > ok?
> 
> I think you missed the "computed goto" in ffi_closure_SYSV.
> 
> Maybe we shouldn't add a "bti j" for the unused slots?

Functionally yes, that should also work and makes more sense.
But then the brks would be a bit redundant. I wasn't sure if there
are tests or something that expects those breaks to be reachable.

> 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/devel/libffi/Makefile,v
> > retrieving revision 1.48
> > diff -u -p -r1.48 Makefile
> > --- Makefile21 Sep 2023 09:49:57 -  1.48
> > +++ Makefile20 Nov 2023 23:14:17 -
> > @@ -1,6 +1,7 @@
> >  COMMENT=   Foreign Function Interface
> >  
> >  V= 3.4.4
> > +REVISION=  0
> >  DISTNAME=  libffi-$V
> >  SHARED_LIBS +=  ffi  2.0  # 9.2
> >  CATEGORIES=devel
> > Index: patches/patch-src_aarch64_ffi_c
> > ===
> > RCS file: patches/patch-src_aarch64_ffi_c
> > diff -N patches/patch-src_aarch64_ffi_c
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-src_aarch64_ffi_c 20 Nov 2023 23:14:17 -
> > @@ -0,0 +1,76 @@
> > +Index: src/aarch64/ffi.c
> > +--- src/aarch64/ffi.c.orig
> >  src/aarch64/ffi.c
> > +@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h)
> > +   "adr%0, 0f\n"
> > + " add %0, %0, %1\n"
> > + " br  %0\n"
> > +-"0:   ldp s16, s17, [%3]\n"   /* S4 */
> > ++"0:   bti j\n"/* S4 */
> > ++" ldp s16, s17, [%3]\n"
> > + " ldp s18, s19, [%3, #8]\n"
> > + " b   4f\n"
> > +-" ldp s16, s17, [%3]\n"   /* S3 */
> > ++" bti j\n"/* S3 */
> > ++" ldp s16, s17, [%3]\n"
> > + " ldr s18, [%3, #8]\n"
> > + " b   3f\n"
> > +-" ldp s16, s17, [%3]\n"   /* S2 */
> > ++" bti j\n"/* S2 */
> > ++" ldp s16, s17, [%3]\n"
> > + " b   2f\n"
> > + " nop\n"
> > +-" ldr s16, [%3]\n"/* S1 */
> > ++" bti j\n"/* S1 */
> > ++" ldr s16, [%3]\n"
> > + " b   1f\n"
> > + " nop\n"
> > +-" ldp d16, d17, [%3]\n"   /* D4 */
> > ++" bti j\n"/* D4 */
> > ++" ldp d16, d17, [%3]\n"
> > + " ldp d18, d19, [%3, #16]\n"
> > + " b   4f\n"
> > +-" ldp d16, d17, [%3]\n"   /* D3 */
> > ++" bti j\n"/* D3 */
> > ++" ldp d16, d17, [%3]\n"
> > + " ldr d18, [%3, #16]\n"
> > + " b   3f\n"
> > +-" ldp d16, d17, [%3]\n"   /* D2 */
> > ++" bti j\n"/* D2 */
> > ++" ldp d16, d17, [%3]\n"
> > + " b   2f\n"
> > + " nop\n"
> > +-" ldr d16, [%3]\n"/* D1 */
> > ++" bti j\n"/* D1 */
> > ++" ldr d16, [%3]\n"
> > + " b   1f\n"
> > + " nop\n"
> > +-" ldp q16, q17, [%3]\n"   /* Q4 */
> > ++" bti j\n"/* Q4 */
> > ++" ldp q16, q17, [%3]\n"
> > + " ldp q18, q19, [%3, #32]\n"
> > + " b   4f\n"
> > +-" ldp q16, q17, [%3]\n"   /* Q3 */
> > ++" bti j\n"/* Q3 */
> > ++" ldp q16, q17, [%3]\n"
> > + " ldr q18, [%3, #32]\n"
> > + " b   3f\n"
> > +-" ldp q16, q17, [%3]\n"   /* Q2 */
> > ++" bti j\n"/* Q2 */
> > ++" ldp q16, q17, [%3]\n"
> > + " b   2f\n"
> > + " nop\n"
> > +-" ldr q16, [%3]\n"/* Q1 */
> &g

libffi: fix arm64 bti

2023-11-20 Thread Tobias Heider

Diff below fixes make regress for libffi with arm64 BTI enabled.
The tricky part were two jump tables in ffi.c and sysV.S.

ok?

Index: Makefile
===
RCS file: /cvs/ports/devel/libffi/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile21 Sep 2023 09:49:57 -  1.48
+++ Makefile20 Nov 2023 23:14:17 -
@@ -1,6 +1,7 @@
 COMMENT=   Foreign Function Interface
 
 V= 3.4.4
+REVISION=  0
 DISTNAME=  libffi-$V
 SHARED_LIBS +=  ffi  2.0  # 9.2
 CATEGORIES=devel
Index: patches/patch-src_aarch64_ffi_c
===
RCS file: patches/patch-src_aarch64_ffi_c
diff -N patches/patch-src_aarch64_ffi_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_aarch64_ffi_c 20 Nov 2023 23:14:17 -
@@ -0,0 +1,76 @@
+Index: src/aarch64/ffi.c
+--- src/aarch64/ffi.c.orig
 src/aarch64/ffi.c
+@@ -390,47 +390,59 @@ extend_hfa_type (void *dest, void *src, int h)
+   "adr%0, 0f\n"
+ " add %0, %0, %1\n"
+ " br  %0\n"
+-"0:   ldp s16, s17, [%3]\n"   /* S4 */
++"0:   bti j\n"/* S4 */
++" ldp s16, s17, [%3]\n"
+ " ldp s18, s19, [%3, #8]\n"
+ " b   4f\n"
+-" ldp s16, s17, [%3]\n"   /* S3 */
++" bti j\n"/* S3 */
++" ldp s16, s17, [%3]\n"
+ " ldr s18, [%3, #8]\n"
+ " b   3f\n"
+-" ldp s16, s17, [%3]\n"   /* S2 */
++" bti j\n"/* S2 */
++" ldp s16, s17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr s16, [%3]\n"/* S1 */
++" bti j\n"/* S1 */
++" ldr s16, [%3]\n"
+ " b   1f\n"
+ " nop\n"
+-" ldp d16, d17, [%3]\n"   /* D4 */
++" bti j\n"/* D4 */
++" ldp d16, d17, [%3]\n"
+ " ldp d18, d19, [%3, #16]\n"
+ " b   4f\n"
+-" ldp d16, d17, [%3]\n"   /* D3 */
++" bti j\n"/* D3 */
++" ldp d16, d17, [%3]\n"
+ " ldr d18, [%3, #16]\n"
+ " b   3f\n"
+-" ldp d16, d17, [%3]\n"   /* D2 */
++" bti j\n"/* D2 */
++" ldp d16, d17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr d16, [%3]\n"/* D1 */
++" bti j\n"/* D1 */
++" ldr d16, [%3]\n"
+ " b   1f\n"
+ " nop\n"
+-" ldp q16, q17, [%3]\n"   /* Q4 */
++" bti j\n"/* Q4 */
++" ldp q16, q17, [%3]\n"
+ " ldp q18, q19, [%3, #32]\n"
+ " b   4f\n"
+-" ldp q16, q17, [%3]\n"   /* Q3 */
++" bti j\n"/* Q3 */
++" ldp q16, q17, [%3]\n"
+ " ldr q18, [%3, #32]\n"
+ " b   3f\n"
+-" ldp q16, q17, [%3]\n"   /* Q2 */
++" bti j\n"/* Q2 */
++" ldp q16, q17, [%3]\n"
+ " b   2f\n"
+ " nop\n"
+-" ldr q16, [%3]\n"/* Q1 */
++" bti j\n"/* Q1 */
++" ldr q16, [%3]\n"
+ " b   1f\n"
+ "4:   str q19, [%2, #48]\n"
+ "3:   str q18, [%2, #32]\n"
+ "2:   str q17, [%2, #16]\n"
+ "1:   str q16, [%2]"
+ : "="(x0)
+-: "r"(f * 12), "r"(dest), "r"(src)
++: "r"(f * 16), "r"(dest), "r"(src)
+ : "memory", "v16", "v17", "v18", "v19");
+ }
+ #endif
Index: patches/patch-src_aarch64_sysv_S
===
RCS file: patches/patch-src_aarch64_sysv_S
diff -N patches/patch-src_aarch64_sysv_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_aarch64_sysv_S20 Nov 2023 23:14:17 -
@@ -0,0 +1,220 @@
+Index: src/aarch64/sysv.S
+--- src/aarch64/sysv.S.orig
 src/aarch64/sysv.S
+@@ -78,6 +78,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ 
+   cfi_startproc
+ CNAME(ffi_call_SYSV):
++  bti c
+   /* Sign the lr with x1 since that is where it will be stored */
+   SIGN_LR_WITH_REG(x1)
+ 
+@@ -138,78 +139,142 @@ CNAME(ffi_call_SYSV):
+   /* Save the return value as directed.  */
+   adr x5, 0f
+   and w4, w4, #AARCH64_RET_MASK
+-  add x5, x5, x4, lsl #3
++  add x5, x5, x4, lsl #4
+   br  x5
+ 
+-  /* Note that each table entry is 2 insns, and thus 8 bytes.
++  /* Note that each table entry is 4 insns, and thus 16 bytes.
+  For integer data, note that we're storing into ffi_arg
+  and therefore we want to extend to 64 bits; these types
+  have two consecutive entries allocated for them.  */
+   .align  4
+-0:b 99f   /* VOID */
++0:bti j
++  b 99f   /* VOID */
++  nop 
+   nop
+-1:

CVS: cvs.openbsd.org: ports

2023-11-20 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/11/20 09:53:17

Modified files:
security/libgcrypt: Makefile 
Added files:
security/libgcrypt/patches: patch-cipher_asm-common-aarch64_h 

Log message:
Fix BTI in arm64 assembly by adding bti instructions to CFI_STARTPROC()

feedback from jca@ and kettenis@
ok ajacoutot@ jca@

Re: arm64 BTI for libgcrypt

2023-11-20 Thread Tobias Heider

On Mon, Nov 20, 2023 at 12:11:42PM +0100, Mark Kettenis wrote:
> > Date: Mon, 20 Nov 2023 11:55:43 +0100
> > From: Tobias Heider 
> > Cc: Jeremie Courreges-Anglas , ports@openbsd.org,
> > kette...@openbsd.org, ajacou...@openbsd.org
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > 
> > On Mon, Nov 20, 2023 at 11:37:17AM +0100, Mark Kettenis wrote:
> > > > From: Jeremie Courreges-Anglas 
> > > > Date: Mon, 20 Nov 2023 08:22:13 +0100
> > > > 
> > > > On Sun, Nov 19 2023, Tobias Heider  wrote:
> > > > > Diff below fixes libgcrypt/gnupg on my m2.
> > > > >
> > > > > CFI_STARTPROC() seemed like a good place to add the bti instructions
> > > > > since it is called in all the right places.
> > > > 
> > > > It's not something that makes sense for upstream IMHO, but for ports
> > > > that use it, it's an obvious place for us to tuck in "endbr64" or
> > > > "bti c".  (eg I've been tempted to use such macros in lang/ocaml)
> > > > 
> > > > Using a macro named CFI_STARTPROC() can be considered either appropriate
> > > > or misleading, since the .cfi_* directives are about "Call Frame
> > > > Information", and endbr64/bti are about "Control-flow Integrity"...
> > > > 
> > > > > If this is too hacky I'm also fine with adding explicit instructions
> > > > > everywhere or even a new macro.
> > > > 
> > > > I'd say it's fine for our port.
> > > > 
> > > > I have one doubt: wouldn't it look more correct to have "bti c" *after*
> > > > .cfi_startproc:
> > > > 
> > > >   # define CFI_STARTPROC().cfi_startproc; bti c;
> > > > 
> > > > since "bti c" is intended to be part of the function?
> > > 
> > > yes!
> > > 
> > 
> > Sure, ok like this?
> > 
> 
> I think you don't need the semicolon at the end.

experimental evaluation says you are right.

Index: Makefile
===
RCS file: /cvs/ports/security/libgcrypt/Makefile,v
retrieving revision 1.92
diff -u -p -r1.92 Makefile
--- Makefile15 Nov 2023 08:00:14 -  1.92
+++ Makefile20 Nov 2023 11:21:52 -
@@ -6,6 +6,7 @@ USE_NOEXECONLY= Yes
 COMMENT=   crypto library based on code used in GnuPG
 
 DISTNAME=  libgcrypt-1.10.3
+REVISION=  0
 
 CATEGORIES=security
 
Index: patches/patch-cipher_asm-common-aarch64_h
===
RCS file: patches/patch-cipher_asm-common-aarch64_h
diff -N patches/patch-cipher_asm-common-aarch64_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_asm-common-aarch64_h   20 Nov 2023 11:21:52 -
@@ -0,0 +1,21 @@
+Index: cipher/asm-common-aarch64.h
+--- cipher/asm-common-aarch64.h.orig
 cipher/asm-common-aarch64.h
+@@ -45,7 +45,7 @@
+ 
+ #ifdef HAVE_GCC_ASM_CFI_DIRECTIVES
+ /* CFI directives to emit DWARF stack unwinding information. */
+-# define CFI_STARTPROC().cfi_startproc
++# define CFI_STARTPROC().cfi_startproc; bti c
+ # define CFI_ENDPROC()  .cfi_endproc
+ # define CFI_REMEMBER_STATE()   .cfi_remember_state
+ # define CFI_RESTORE_STATE().cfi_restore_state
+@@ -87,7 +87,7 @@
+   DW_SLEB128_28BIT(rsp_offs)
+ 
+ #else
+-# define CFI_STARTPROC()
++# define CFI_STARTPROC() bti c
+ # define CFI_ENDPROC()
+ # define CFI_REMEMBER_STATE()
+ # define CFI_RESTORE_STATE()

Re: arm64 BTI for libgcrypt

2023-11-20 Thread Tobias Heider

On Mon, Nov 20, 2023 at 11:37:17AM +0100, Mark Kettenis wrote:
> > From: Jeremie Courreges-Anglas 
> > Date: Mon, 20 Nov 2023 08:22:13 +0100
> > 
> > On Sun, Nov 19 2023, Tobias Heider  wrote:
> > > Diff below fixes libgcrypt/gnupg on my m2.
> > >
> > > CFI_STARTPROC() seemed like a good place to add the bti instructions
> > > since it is called in all the right places.
> > 
> > It's not something that makes sense for upstream IMHO, but for ports
> > that use it, it's an obvious place for us to tuck in "endbr64" or
> > "bti c".  (eg I've been tempted to use such macros in lang/ocaml)
> > 
> > Using a macro named CFI_STARTPROC() can be considered either appropriate
> > or misleading, since the .cfi_* directives are about "Call Frame
> > Information", and endbr64/bti are about "Control-flow Integrity"...
> > 
> > > If this is too hacky I'm also fine with adding explicit instructions
> > > everywhere or even a new macro.
> > 
> > I'd say it's fine for our port.
> > 
> > I have one doubt: wouldn't it look more correct to have "bti c" *after*
> > .cfi_startproc:
> > 
> >   # define CFI_STARTPROC().cfi_startproc; bti c;
> > 
> > since "bti c" is intended to be part of the function?
> 
> yes!
> 

Sure, ok like this?

Index: Makefile
===
RCS file: /cvs/ports/security/libgcrypt/Makefile,v
retrieving revision 1.92
diff -u -p -r1.92 Makefile
--- Makefile15 Nov 2023 08:00:14 -  1.92
+++ Makefile20 Nov 2023 10:54:58 -
@@ -6,6 +6,7 @@ USE_NOEXECONLY= Yes
 COMMENT=   crypto library based on code used in GnuPG
 
 DISTNAME=  libgcrypt-1.10.3
+REVISION=  0
 
 CATEGORIES=security
 
Index: patches/patch-cipher_asm-common-aarch64_h
===
RCS file: patches/patch-cipher_asm-common-aarch64_h
diff -N patches/patch-cipher_asm-common-aarch64_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_asm-common-aarch64_h   20 Nov 2023 10:54:58 -
@@ -0,0 +1,21 @@
+Index: cipher/asm-common-aarch64.h
+--- cipher/asm-common-aarch64.h.orig
 cipher/asm-common-aarch64.h
+@@ -45,7 +45,7 @@
+ 
+ #ifdef HAVE_GCC_ASM_CFI_DIRECTIVES
+ /* CFI directives to emit DWARF stack unwinding information. */
+-# define CFI_STARTPROC().cfi_startproc
++# define CFI_STARTPROC().cfi_startproc; bti c;
+ # define CFI_ENDPROC()  .cfi_endproc
+ # define CFI_REMEMBER_STATE()   .cfi_remember_state
+ # define CFI_RESTORE_STATE().cfi_restore_state
+@@ -87,7 +87,7 @@
+   DW_SLEB128_28BIT(rsp_offs)
+ 
+ #else
+-# define CFI_STARTPROC()
++# define CFI_STARTPROC() bti c;
+ # define CFI_ENDPROC()
+ # define CFI_REMEMBER_STATE()
+ # define CFI_RESTORE_STATE()

arm64 BTI for libgcrypt

2023-11-19 Thread Tobias Heider

Diff below fixes libgcrypt/gnupg on my m2.

CFI_STARTPROC() seemed like a good place to add the bti instructions
since it is called in all the right places.
If this is too hacky I'm also fine with adding explicit instructions
everywhere or even a new macro.

opinions? ok?

Index: patches/patch-cipher_asm-common-aarch64_h
===
RCS file: patches/patch-cipher_asm-common-aarch64_h
diff -N patches/patch-cipher_asm-common-aarch64_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_asm-common-aarch64_h   19 Nov 2023 20:22:40 -
@@ -0,0 +1,21 @@
+Index: cipher/asm-common-aarch64.h
+--- cipher/asm-common-aarch64.h.orig
 cipher/asm-common-aarch64.h
+@@ -45,7 +45,7 @@
+ 
+ #ifdef HAVE_GCC_ASM_CFI_DIRECTIVES
+ /* CFI directives to emit DWARF stack unwinding information. */
+-# define CFI_STARTPROC().cfi_startproc
++# define CFI_STARTPROC()bti c; .cfi_startproc;
+ # define CFI_ENDPROC()  .cfi_endproc
+ # define CFI_REMEMBER_STATE()   .cfi_remember_state
+ # define CFI_RESTORE_STATE().cfi_restore_state
+@@ -87,7 +87,7 @@
+   DW_SLEB128_28BIT(rsp_offs)
+ 
+ #else
+-# define CFI_STARTPROC()
++# define CFI_STARTPROC() bti c;
+ # define CFI_ENDPROC()
+ # define CFI_REMEMBER_STATE()
+ # define CFI_RESTORE_STATE()

CVS: cvs.openbsd.org: ports

2023-10-26 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/10/26 12:46:22

Modified files:
sysutils/firmware/apple-boot: Makefile 

Log message:
Bump m1n1 version to 1.4.3

ok kettenis@

CVS: cvs.openbsd.org: ports

2023-10-26 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/10/26 12:45:28

Modified files:
sysutils/m1n1  : Makefile distinfo 
Added files:
sysutils/m1n1/patches: patch-data_makelogo_sh 

Log message:
Update to m1n1 1.4.3

m1n1: update to 1.4.3

2023-10-23 Thread Tobias Heider

As the title says. We need a small patch to remove an unnecessary
bash dependency, I opened an upstream PR for that.
Once this is in I will also update apple-firmware.

Index: Makefile
===
RCS file: /cvs/ports/sysutils/m1n1/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile10 Sep 2023 15:17:37 -  1.11
+++ Makefile23 Oct 2023 18:36:37 -
@@ -4,7 +4,7 @@ COMMENT=Bootloader for Apple Silicon
 
 GH_ACCOUNT=AsahiLinux
 GH_PROJECT=m1n1
-GH_TAGNAME=v1.3.6
+GH_TAGNAME=v1.4.3
 
 CATEGORIES=sysutils
 HOMEPAGE=  https://github.com/AsahiLinux/m1n1
Index: distinfo
===
RCS file: /cvs/ports/sysutils/m1n1/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo10 Sep 2023 15:17:37 -  1.4
+++ distinfo23 Oct 2023 18:36:37 -
@@ -1,2 +1,2 @@
-SHA256 (m1n1-1.3.6.tar.gz) = qqKH3qPQRBc5nFswvdCdcJFnaTXyWdfLUpYqMKAiy/A=
-SIZE (m1n1-1.3.6.tar.gz) = 785173
+SHA256 (m1n1-1.4.3.tar.gz) = 9x58eF1lQUgb9srl0pUYOOMeb2Q1SMdEDE//B1fV91U=
+SIZE (m1n1-1.4.3.tar.gz) = 819419
Index: patches/patch-data_makelogo_sh
===
RCS file: patches/patch-data_makelogo_sh
diff -N patches/patch-data_makelogo_sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-data_makelogo_sh  23 Oct 2023 18:36:37 -
@@ -0,0 +1,8 @@
+Index: data/makelogo.sh
+--- data/makelogo.sh.orig
 data/makelogo.sh
+@@ -1,3 +1,3 @@
+-#!/bin/bash
++#!/bin/sh
+ convert bootlogo_128.png -background black -flatten -depth 8 
rgba:bootlogo_128.bin
+ convert bootlogo_256.png -background black -flatten -depth 8 
rgba:bootlogo_256.bin

CVS: cvs.openbsd.org: ports

2023-07-24 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/07/24 05:17:21

Modified files:
x11/qt6/qtmultimedia: Makefile 
Added files:
x11/qt6/qtmultimedia/patches: 
  patch-src_resonance-audio_CMakeLists_txt 

Log message:
Fix build on macppc. CMAKE_SYSTEM_PROCESSOR returns powerpc on OpenBSD.

ok kn@ rsadowski@

CVS: cvs.openbsd.org: ports

2023-07-24 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/07/24 05:15:23

ports/x11/qt6/qtmultimedia/patches

Update of /cvs/ports/x11/qt6/qtmultimedia/patches
In directory cvs.openbsd.org:/tmp/cvs-serv50648/patches

Log Message:
Directory /cvs/ports/x11/qt6/qtmultimedia/patches added to the repository

qt6-multimedia: fix macppc

2023-07-21 Thread Tobias Heider

When trying to build qt6-multimedia I noticed the build fails because
of missing Altivec support.  The included CMake file does some ppc
specific CFLAG magic but matches on the wrong value.

The diff below unbreaks it for me.  I am not quite sure how the REV bump
works with those multi package folders like qt.

ok?

diff /home/user/got/co/ports
commit - 909b2aa1081bfe2fe1f22f676e8f2d248c8550d9
path + /home/user/got/co/ports
blob - 3604a2a6918ab0b4e4c509779d466b515d073d6c
file + x11/qt6/qtmultimedia/Makefile
--- x11/qt6/qtmultimedia/Makefile
+++ x11/qt6/qtmultimedia/Makefile
@@ -1,6 +1,7 @@
 QT6NAME =  QtMultimedia
 COMMENT =  Qt6 multimedia components
 PKGSPEC =  qt6-qtmultimedia-${QT6_PKGSPEC}
+REVISION=  0
 
 SHARED_LIBS +=  Qt6Multimedia 3.0 # 6.5
 SHARED_LIBS +=  Qt6MultimediaQuick3.0 # 6.5
blob - /dev/null
file + x11/qt6/qtmultimedia/patches/patch-src_resonance-audio_CMakeLists_txt 
(mode 644)
--- /dev/null
+++ x11/qt6/qtmultimedia/patches/patch-src_resonance-audio_CMakeLists_txt
@@ -0,0 +1,22 @@
+On OpenBSD CMAKE_SYSTEM_PROCESSOR returns powerpc on macppc.
+Fixes missing altivec compilation error on macppc.
+
+Index: src/resonance-audio/CMakeLists.txt
+--- src/resonance-audio/CMakeLists.txt.orig
 src/resonance-audio/CMakeLists.txt
+@@ -215,13 +215,13 @@ qt_internal_add_3rdparty_library(BundledResonanceAudio
+ )
+ 
+ # Required by pffft on certain PowerPC archs
+-qt_internal_extend_target(BundledResonanceAudio CONDITION GCC AND 
(${CMAKE_SYSTEM_PROCESSOR} MATCHES "(ppc|ppc64)$")
++qt_internal_extend_target(BundledResonanceAudio CONDITION GCC AND 
(${CMAKE_SYSTEM_PROCESSOR} MATCHES "(ppc|ppc64|powerpc)$")
+ COMPILE_OPTIONS
+ -maltivec
+ )
+ 
+ # Required by eigen on certain PowerPC archs
+-qt_internal_extend_target(BundledResonanceAudio CONDITION 
(${CMAKE_SYSTEM_PROCESSOR} MATCHES "(ppc|ppc64)$")
++qt_internal_extend_target(BundledResonanceAudio CONDITION 
(${CMAKE_SYSTEM_PROCESSOR} MATCHES "(ppc|ppc64|powerpc)$")
+ COMPILE_OPTIONS
+ -mvsx
+ )

CVS: cvs.openbsd.org: ports

2023-04-14 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/04/14 06:17:32

Modified files:
sysutils/firmware/apple-boot: Makefile 

Log message:
Bump u-boot version to 2023.04

CVS: cvs.openbsd.org: ports

2023-04-14 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2023/04/14 05:29:15

Modified files:
sysutils/u-boot-asahi: Makefile distinfo 
sysutils/u-boot-asahi/patches: 
   patch-arch_arm_dts_t600x-j314-j316_dtsi 
   patch-arch_arm_dts_t8103-j293_dts 
   patch-arch_arm_dts_t8103-j313_dts 
   patch-arch_arm_dts_t8112-j413_dts 
   patch-arch_arm_dts_t8112-j493_dts 
Added files:
sysutils/u-boot-asahi/patches: 
   patch-arch_arm_dts_t600x-j375_dtsi 
Removed files:
sysutils/u-boot-asahi/patches: 
   patch-arch_arm_dts_t6001-j375c_dts 
   patch-arch_arm_dts_t6002-j375d_dts 

Log message:
Update to openbsd-v2023.04

ok sthen@ patrick@

Re: [Update] u-boot-asahi to openbsd-v2023.04

2023-04-13 Thread Tobias Heider

On Tue, Apr 11, 2023 at 11:25:48AM +0100, Stuart Henderson wrote:
> On 2023/04/10 19:45, Tobias Heider wrote:
> > Update to to get the newer device trees with keyboard backlight and usb
> > type-a support. The upstream maintainer was nice to us and added an
> > openbsd release tag with all the good stuff included.
> 
> Untested (I am just running via VMs on my m1) but lgtm. Don't forget to
> update REVISION and BUILD_DEPENDS in sysutils/firmware/apple-boot.
> 

Thanks! I will update apple-boot once this one is committed.

One more update because the first diff was actually missing the removal of
patch-arch_arm_dts_t6002-j375d_dts and patch-arch_arm_dts_t6001-j375c_dts
which are no longer needed.

Index: Makefile
===
RCS file: /cvs/ports/sysutils/u-boot-asahi/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile5 Feb 2023 21:15:39 -   1.9
+++ Makefile13 Apr 2023 23:16:48 -
@@ -2,11 +2,10 @@
 
 COMMENT=   U-Boot firmware for Apple Silicon
 
-VERSION=   2022.07-3
+VERSION=   2023.04
 GH_ACCOUNT=AsahiLinux
 GH_PROJECT=u-boot
-GH_TAGNAME=asahi-v${VERSION}
-REVISION=  5
+GH_TAGNAME=openbsd-v${VERSION}
 
 PKGNAME=   u-boot-asahi-${VERSION:S/-/./g}
 
Index: distinfo
===
RCS file: /cvs/ports/sysutils/u-boot-asahi/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo25 Oct 2022 20:27:00 -  1.1.1.1
+++ distinfo13 Apr 2023 23:16:48 -
@@ -1,2 +1,2 @@
-SHA256 (u-boot-asahi-v2022.07-3.tar.gz) = 
jR5RfM+ArQZsiNF6J8KRJUl9f4iD7WDJree/C9hUgq0=
-SIZE (u-boot-asahi-v2022.07-3.tar.gz) = 23237466
+SHA256 (u-boot-openbsd-v2023.04.tar.gz) = 
qt1ShPpWt7zW3KEIkhjtVfOzFzuozRZcPh8PxvuyniY=
+SIZE (u-boot-openbsd-v2023.04.tar.gz) = 24662447
Index: patches/patch-arch_arm_dts_t6001-j375c_dts
===
RCS file: patches/patch-arch_arm_dts_t6001-j375c_dts
diff -N patches/patch-arch_arm_dts_t6001-j375c_dts
--- patches/patch-arch_arm_dts_t6001-j375c_dts  5 Feb 2023 21:15:39 -   
1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,19 +0,0 @@
-Index: arch/arm/dts/t6001-j375c.dts
 arch/arm/dts/t6001-j375c.dts.orig
-+++ arch/arm/dts/t6001-j375c.dts
-@@ -260,15 +260,6 @@
-   compatible = "apple,j375-macaudio", "apple,macaudio";
-   model = "Mac Studio J375 integrated audio";
- 
--  /*
--   * DANGER ZONE: You can blow your speakers!
--   *
--   * The drivers are not ready, and unless you are careful
--   * to attenuate the audio stream, you run the risk of
--   * blowing your speakers.
--   */
--  status = "disabled";
--
-   dai-link@0 {
-   link-name = "Speaker";
-   mclk-fs = <64>;
Index: patches/patch-arch_arm_dts_t6002-j375d_dts
===
RCS file: patches/patch-arch_arm_dts_t6002-j375d_dts
diff -N patches/patch-arch_arm_dts_t6002-j375d_dts
--- patches/patch-arch_arm_dts_t6002-j375d_dts  5 Feb 2023 21:15:39 -   
1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,19 +0,0 @@
-Index: arch/arm/dts/t6002-j375d.dts
 arch/arm/dts/t6002-j375d.dts.orig
-+++ arch/arm/dts/t6002-j375d.dts
-@@ -352,15 +352,6 @@
-   compatible = "apple,j375-macaudio", "apple,macaudio";
-   model = "Mac Studio J375 integrated audio";
- 
--  /*
--   * DANGER ZONE: You can blow your speakers!
--   *
--   * The drivers are not ready, and unless you are careful
--   * to attenuate the audio stream, you run the risk of
--   * blowing your speakers.
--   */
--  status = "disabled";
--
-   dai-link@0 {
-   link-name = "Speaker";
-   mclk-fs = <64>;
Index: patches/patch-arch_arm_dts_t600x-j314-j316_dtsi
===
RCS file: 
/cvs/ports/sysutils/u-boot-asahi/patches/patch-arch_arm_dts_t600x-j314-j316_dtsi,v
retrieving revision 1.1
diff -u -p -r1.1 patch-arch_arm_dts_t600x-j314-j316_dtsi
--- patches/patch-arch_arm_dts_t600x-j314-j316_dtsi 5 Feb 2023 21:15:39 
-   1.1
+++ patches/patch-arch_arm_dts_t600x-j314-j316_dtsi 13 Apr 2023 23:16:48 
-
@@ -1,19 +1,19 @@
 Index: arch/arm/dts/t600x-j314-j316.dtsi
 --- arch/arm/dts/t600x-j314-j316.dtsi.orig
 +++ arch/arm/dts/t600x-j314-j316.dtsi
-@@ -313,15 +313,6 @@
-   compatible = "apple,j314-macaudio", "apple,macaudio";
-   model = "MacBook Pro J

[Update] u-boot-asahi to openbsd-v2023.04

2023-04-10 Thread Tobias Heider

Update to to get the newer device trees with keyboard backlight and usb
type-a support. The upstream maintainer was nice to us and added an
openbsd release tag with all the good stuff included.

ok?

Index: Makefile
===
RCS file: /cvs/ports/sysutils/u-boot-asahi/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile5 Feb 2023 21:15:39 -   1.9
+++ Makefile10 Apr 2023 17:43:13 -
@@ -2,11 +2,10 @@
 
 COMMENT=   U-Boot firmware for Apple Silicon
 
-VERSION=   2022.07-3
+VERSION=   2023.04
 GH_ACCOUNT=AsahiLinux
 GH_PROJECT=u-boot
-GH_TAGNAME=asahi-v${VERSION}
-REVISION=  5
+GH_TAGNAME=openbsd-v${VERSION}
 
 PKGNAME=   u-boot-asahi-${VERSION:S/-/./g}
 
Index: distinfo
===
RCS file: /cvs/ports/sysutils/u-boot-asahi/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo25 Oct 2022 20:27:00 -  1.1.1.1
+++ distinfo10 Apr 2023 17:43:13 -
@@ -1,2 +1,2 @@
-SHA256 (u-boot-asahi-v2022.07-3.tar.gz) = 
jR5RfM+ArQZsiNF6J8KRJUl9f4iD7WDJree/C9hUgq0=
-SIZE (u-boot-asahi-v2022.07-3.tar.gz) = 23237466
+SHA256 (u-boot-openbsd-v2023.04.tar.gz) = 
qt1ShPpWt7zW3KEIkhjtVfOzFzuozRZcPh8PxvuyniY=
+SIZE (u-boot-openbsd-v2023.04.tar.gz) = 24662447
Index: patches/patch-arch_arm_dts_t600x-j314-j316_dtsi
===
RCS file: 
/cvs/ports/sysutils/u-boot-asahi/patches/patch-arch_arm_dts_t600x-j314-j316_dtsi,v
retrieving revision 1.1
diff -u -p -r1.1 patch-arch_arm_dts_t600x-j314-j316_dtsi
--- patches/patch-arch_arm_dts_t600x-j314-j316_dtsi 5 Feb 2023 21:15:39 
-   1.1
+++ patches/patch-arch_arm_dts_t600x-j314-j316_dtsi 10 Apr 2023 17:43:13 
-
@@ -1,19 +1,19 @@
 Index: arch/arm/dts/t600x-j314-j316.dtsi
 --- arch/arm/dts/t600x-j314-j316.dtsi.orig
 +++ arch/arm/dts/t600x-j314-j316.dtsi
-@@ -313,15 +313,6 @@
-   compatible = "apple,j314-macaudio", "apple,macaudio";
-   model = "MacBook Pro J314/6 integrated audio";
- 
--  /*
--   * DANGER ZONE: You can blow your speakers!
--   *
--   * The drivers are not ready, and unless you are careful
--   * to attenuate the audio stream, you run the risk of
--   * blowing your speakers.
--   */
--  status = "disabled";
--
+@@ -403,15 +403,6 @@
dai-link@0 {
link-name = "Speakers";
-   mclk-fs = <256>;
+ 
+-  /*
+-   * DANGER ZONE: You can blow your speakers!
+-   *
+-   * The drivers are not ready, and unless you are careful
+-   * to attenuate the audio stream, you run the risk of
+-   * blowing your speakers.
+-   */
+-  status = "disabled";
+-
+   cpu {
+   sound-dai = < 0>, < 1>;
+   };
Index: patches/patch-arch_arm_dts_t600x-j375_dtsi
===
RCS file: patches/patch-arch_arm_dts_t600x-j375_dtsi
diff -N patches/patch-arch_arm_dts_t600x-j375_dtsi
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-arch_arm_dts_t600x-j375_dtsi  10 Apr 2023 17:43:13 -
@@ -0,0 +1,18 @@
+Index: arch/arm/dts/t600x-j375.dtsi
+--- arch/arm/dts/t600x-j375.dtsi.orig
 arch/arm/dts/t600x-j375.dtsi
+@@ -292,14 +292,6 @@
+ 
+   dai-link@0 {
+   link-name = "Speaker";
+-  /*
+-  * DANGER ZONE: You can blow your speakers!
+-  *
+-  * The drivers are not ready, and unless you are careful
+-  * to attenuate the audio stream, you run the risk of
+-  * blowing your speakers.
+-  */
+-  status = "disabled";
+   cpu {
+   sound-dai = < 0>;
+   };
Index: patches/patch-arch_arm_dts_t8103-j293_dts
===
RCS file: 
/cvs/ports/sysutils/u-boot-asahi/patches/patch-arch_arm_dts_t8103-j293_dts,v
retrieving revision 1.1
diff -u -p -r1.1 patch-arch_arm_dts_t8103-j293_dts
--- patches/patch-arch_arm_dts_t8103-j293_dts   17 Jan 2023 21:00:22 -  
1.1
+++ patches/patch-arch_arm_dts_t8103-j293_dts   10 Apr 2023 17:43:13 -
@@ -1,10 +1,10 @@
 Index: arch/arm/dts/t8103-j293.dts
 --- arch/arm/dts/t8103-j293.dts.orig
 +++ arch/arm/dts/t8103-j293.dts
-@@ -138,15 +138,6 @@
-   model = "MacBook Pro J293 integrated audio";
- 
+@@ -149,15 +149,6 @@
dai-link@0 {
+   link-name = "Speakers";
+ 
 -

CVS: cvs.openbsd.org: ports

2022-11-11 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/11 13:06:01

Modified files:
sysutils/firmware/apple-boot: Makefile 
sysutils/firmware/apple-boot/pkg: PLIST 

Log message:
Produce a combined m1n1 + uboot license file in 
/etc/firmware/apple-boot-license.
Fix PLIST path while there.

CVS: cvs.openbsd.org: ports

2022-11-11 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/11 12:38:11

Modified files:
sysutils/m1n1  : Makefile 
sysutils/m1n1/pkg: PLIST 
sysutils/u-boot-asahi: Makefile 
sysutils/u-boot-asahi/pkg: PLIST 

Log message:
Generate license files for m1n1 and u-boot-asahi to include in
the apple-boot firmware package.

ok sthen@ kettenis@

CVS: cvs.openbsd.org: ports

2022-11-11 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/11 12:05:10

Removed files:
sysutils/firmware/m1n1-uboot: Makefile 
sysutils/firmware/m1n1-uboot/pkg: DESCR PLIST 

Log message:
Remove m1n1-uboot. It has moved to apple-boot.

CVS: cvs.openbsd.org: ports

2022-11-11 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/11 12:02:53

Modified files:
sysutils/firmware: Makefile 

Log message:
Rename m1n1-uboot -> apple-boot

CVS: cvs.openbsd.org: ports

2022-11-11 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/11 11:59:19

Log message:
Reimport m1n1-uboot as apple-boot for a more generic and
descriptive name.

discussed with many

Status:

Vendor Tag: tobhe
Release Tags:   tobhe_2022

N ports/sysutils/firmware/apple-boot/Makefile
N ports/sysutils/firmware/apple-boot/pkg/DESCR
N ports/sysutils/firmware/apple-boot/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

2022-11-10 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/10 08:44:43

Modified files:
sysutils/firmware: Makefile 

Log message:
Hook up m1n1-uboot

CVS: cvs.openbsd.org: ports

2022-11-10 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/10 08:41:23

Log message:
Import m1n1+uboot bootloader firmware meta port for Apple arm64 machines.

ok sthen@

Status:

Vendor Tag: tobhe
Release Tags:   tobhe_20221110

N ports/sysutils/firmware/m1n1-uboot/Makefile
N ports/sysutils/firmware/m1n1-uboot/pkg/DESCR
N ports/sysutils/firmware/m1n1-uboot/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

2022-11-08 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/08 11:16:18

Modified files:
sysutils/m1n1  : Makefile 
Added files:
sysutils/m1n1/files: logo.svg 

Log message:
Add custom OpenBSD bootsplash instead of Asahi Linux default.

Discussed with kettenis@
ok patrick@

CVS: cvs.openbsd.org: ports

2022-11-08 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/08 11:06:44

ports/sysutils/m1n1/files

Update of /cvs/ports/sysutils/m1n1/files
In directory cvs.openbsd.org:/tmp/cvs-serv76598/files

Log Message:
Directory /cvs/ports/sysutils/m1n1/files added to the repository

CVS: cvs.openbsd.org: ports

2022-11-07 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/11/07 04:53:36

Modified files:
sysutils/u-boot-asahi: Makefile 
sysutils/u-boot-asahi/pkg: PLIST 

Log message:
Install device trees for u-boot-asahi. We are going to need those to update
the booloader binary from the installer.

ok kettenis@

CVS: cvs.openbsd.org: ports

2022-10-25 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/10/25 14:32:14

Modified files:
sysutils   : Makefile 

Log message:
Hook up u-boot-asahi

CVS: cvs.openbsd.org: ports

2022-10-25 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/10/25 14:27:00

Log message:
sysutils/u-boot-asahi: Import u-boot-asahi-2022.07-3

U-Boot firmware for Apple Silicon arm64 machines

ok kettenis@ sthen@

Status:

Vendor Tag: tobhe
Release Tags:   tobhe_20221025

N ports/sysutils/u-boot-asahi/Makefile
N ports/sysutils/u-boot-asahi/distinfo
N ports/sysutils/u-boot-asahi/pkg/DESCR
N ports/sysutils/u-boot-asahi/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

2022-10-25 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/10/25 14:03:22

Modified files:
sysutils   : Makefile 

Log message:
Hook m1n1 up to build

CVS: cvs.openbsd.org: ports

2022-10-25 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/10/25 13:27:04

Log message:
sysutils/m1n1: Import m1n1-1.1.6

m1n1 is a bootloader for Apple Silicon ARM64 machines.

ok kettenis@ sthen@

Status:

Vendor Tag: tobhe
Release Tags:   tobhe_20221025

N ports/sysutils/m1n1/Makefile
N ports/sysutils/m1n1/distinfo
N ports/sysutils/m1n1/pkg/DESCR
N ports/sysutils/m1n1/pkg/PLIST

No conflicts created by this import

[NEW] sysutils/m1n1

2022-10-24 Thread Tobias Heider

m1n1 is a bootloader for Apple silicon machines developed by the Asahi Linux
project.

This is the first of several packages we need to upgrade the bootloader chain
from OpenBSD.  The other missing parts are the asahi fork of u-boot which I
plan to upload as a separate port and a few device trees in sysutils/dtb.

ok?


m1n1.tar.gz
Description: application/gzip

sysutils/u-boot-asahi

2022-10-24 Thread Tobias Heider

u-boot-asahi is the Asahi Linux version of the u-boot bootloader that works
on Apple Silicon Arm hardware.

We need this package to update the bootloader chain on these devices from
OpenBSD and to distribute newer device trees.

There is already a u-boot port, but this fork has so many changes added that
it makes more sense to ship it as a separate port, as discussed with others
at g2k22.

ok?


u-boot-asahi.tar.gz
Description: application/gzip

CVS: cvs.openbsd.org: ports

2022-01-17 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2022/01/17 06:09:21

Modified files:
graphics/cairo : Makefile 
graphics/cairo/patches: patch-meson_build 

Log message:
Add upstream fix for endianness detection in meson.
Fixes empty window frames on big endian archs.

ok aja@ gkoehler@

graphics/cairo: fix on big endian

2022-01-14 Thread Tobias Heider

Hi,

GTK is currently broken on big endian archs.  I traced
the problem down to cairo.  It looks like the switch to
meson as build system has broken the endianness check that
was previously done by autoconf.

An upstream fix was committed with the following pull request:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/214

The diff below fixes the bug on my PowerBook G4.
ok?

Index: Makefile
===
RCS file: /cvs/ports/graphics/cairo/Makefile,v
retrieving revision 1.73
diff -u -p -r1.73 Makefile
--- Makefile7 Nov 2021 19:35:33 -   1.73
+++ Makefile14 Jan 2022 22:41:47 -
@@ -3,7 +3,7 @@
 COMMENT=   vector graphics library
 
 DISTNAME=  cairo-1.17.4
-REVISION=  0
+REVISION=  1
 
 CATEGORIES=graphics
 DPB_PROPERTIES=parallel
Index: patches/patch-meson_build
===
RCS file: /cvs/ports/graphics/cairo/patches/patch-meson_build,v
retrieving revision 1.1
diff -u -p -r1.1 patch-meson_build
--- patches/patch-meson_build   25 Oct 2021 07:21:40 -  1.1
+++ patches/patch-meson_build   14 Jan 2022 22:41:47 -
@@ -12,6 +12,13 @@ Subject: [PATCH] meson: fix library vers
 
 Last chunk: LD_PRELOAD is supported on OpenBSD
 
+commit e2c002c570c42cb883e41f0dfabfdb0651edbe9b
+Author: Adrian Johnson 
+Date:   Sun Jul 25 11:59:40 2021 +0930
+
+meson: add endian check
+Fixes #464
+
 Index: meson.build
 --- meson.build.orig
 +++ meson.build
@@ -52,7 +59,30 @@ Index: meson.build
  if cc.get_id() == 'msvc'
# Basic usage in the cairo type system that causes spammy and useless 
warnings
add_project_arguments('/wd4244', '/wd4146',
-@@ -312,8 +331,7 @@ if xcb_dep.found() and xcb_render_dep.found()
+@@ -116,6 +135,22 @@ extra_link_args = []
+ 
+ conf = configuration_data()
+ 
++if host_machine.endian() == 'big'
++  conf.set('WORDS_BIGENDIAN', 1)
++endif
++
++float_order = cc.get_define('__FLOAT_WORD_ORDER__')
++if float_order != ''
++  if float_order == cc.get_define('__ORDER_BIG_ENDIAN__')
++conf.set('FLOAT_WORDS_BIGENDIAN', 1)
++  endif
++else
++  # Assume same as platform endian
++  if host_machine.endian() == 'big'
++conf.set('FLOAT_WORDS_BIGENDIAN', 1)
++  endif
++endif
++
+ lzo_dep = dependency('lzo2', required: false)
+ if lzo_dep.found()
+   deps += [lzo_dep]
+@@ -312,8 +347,7 @@ if xcb_dep.found() and xcb_render_dep.found()
  endif
  
  if feature_conf.get('CAIRO_HAS_XCB_SURFACE', 0) == 1 and 
feature_conf.get('CAIRO_HAS_XLIB_SURFACE', 0) == 1
@@ -62,7 +92,7 @@ Index: meson.build
if x11xcb_dep.found()
  deps += [x11xcb_dep]
  feature_conf.set('CAIRO_HAS_XLIB_XCB_FUNCTIONS', 1)
-@@ -832,7 +850,7 @@ if not ['x86', 'x86_64'].contains(host_machine.cpu_fam
+@@ -832,7 +866,7 @@ if not ['x86', 'x86_64'].contains(host_machine.cpu_fam
conf.set('ATOMIC_OP_NEEDS_MEMORY_BARRIER', 1)
  endif

Re: unbreak games/openjk singleplayer fullscreen

2021-05-06 Thread Tobias Heider

On Thu, May 06, 2021 at 04:19:24AM -0700, Nam Nguyen wrote:
> Here is a diff that unbreaks crashing when toggling fullscreen in
> singleplayer. I used LD_DEBUG=1 to see the differences between openjk_sp
> and openjk.[1] I eventually found that openjk is linked with -lGL -lGLU
> whereas openjk_sp lacks these flags.
> 
> I opened a pull request.[2]
> 
> Feedback and tests are welcome. OK?
> 

Thanks for the update, this fixes the issue for me.

ok tobhe@

Re: games/openra: update to 20210321

2021-05-04 Thread Tobias Heider

On Mon, May 03, 2021 at 03:58:01PM -0600, Thomas Frohwein wrote:
> Hi,
> 
> Here is a diff that updates OpenRA to the latest version 20210321. The
> heavy lifting was done by patrick@; I added the nuget dependencies and
> the workaround for the dllmap config files.
> 
> bcallah@: would appreciate if both distfiles could be hosted on the
> nycbug mirror again.
> 
> Unfortunately the msbuild ports don't get nicer, so some dark magic is
> required once again to make it work:
> 
> - nuget-openra-20210321.tar.xz is just an archive of the dependencies
>   fetched by nuget run with a working internet connection. I checked
>   that this builds with network interface down.
> - DLLMAP_FILES doesn't work anymore because the the *.config files with
>   dllmap are built "on the fly" during the install goal. Best option I
>   could come up with (that doesn't hardcode the library versions like
>   the included script configure-system-libraries.sh tries to do) was to
>   copy the correct files from $FILESDIR (they are all trivial and
>   small).
> - The build system (MSBuild or mono) erros with LangVersion 7.3; but
>   lowering it to 7.2 allows it to build without problems.
> 
> Tested in a brief single-player mission with Red Alert, and I checked
> that the multiplayer lobby shows available servers/games.
> 
> ok? comments?

We tested the multiplayer with RA and CNC without problems.
Patrick didn't stand a chance.

ok tobhe@

CVS: cvs.openbsd.org: ports

2021-02-05 Thread Tobias Heider

CVSROOT:/cvs
Module name:ports
Changes by: to...@cvs.openbsd.org   2021/02/05 12:57:54

Modified files:
security/wpa_supplicant: Makefile 
Added files:
security/wpa_supplicant/patches: patch-src_p2p_p2p_c 

Log message:
Add security patch 2020-2 from upstream. The vulnerable code is
currently disabled because we don't enable CONFIG_P2P.

ok sthen@ bluhm@

wpa-supplicant security 2020-2

2021-02-05 Thread Tobias Heider

Hi,

the diff below adds a security patch released by wpa_supplicant yesterday.
For more infos, see https://w1.fi/security/2020-2/

ok?

diff --git a/security/wpa_supplicant/Makefile b/security/wpa_supplicant/Makefile
index 1ae7b15dc8e..4bf372e1e06 100644
--- a/security/wpa_supplicant/Makefile
+++ b/security/wpa_supplicant/Makefile
@@ -3,6 +3,7 @@
 COMMENT=   IEEE 802.1X supplicant
 
 DISTNAME=  wpa_supplicant-2.9
+REVISION=  0
 CATEGORIES=security net
 
 HOMEPAGE=  https://w1.fi/wpa_supplicant/
diff --git a/security/wpa_supplicant/patches/patch-src_p2p_p2p_c 
b/security/wpa_supplicant/patches/patch-src_p2p_p2p_c
new file mode 100644
index 000..5f105084f94
--- /dev/null
+++ b/security/wpa_supplicant/patches/patch-src_p2p_p2p_c
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/p2p/p2p.c
+--- src/p2p/p2p.c.orig
 src/p2p/p2p.c
+@@ -453,6 +453,8 @@ static void p2p_copy_client_info(struct p2p_device *de
+   dev->info.config_methods = cli->config_methods;
+   os_memcpy(dev->info.pri_dev_type, cli->pri_dev_type, 8);
+   dev->info.wps_sec_dev_type_list_len = 8 * cli->num_sec_dev_types;
++  if (dev->info.wps_sec_dev_type_list_len > WPS_SEC_DEV_TYPE_MAX_LEN)
++  dev->info.wps_sec_dev_type_list_len = WPS_SEC_DEV_TYPE_MAX_LEN;
+   os_memcpy(dev->info.wps_sec_dev_type_list, cli->sec_dev_types,
+ dev->info.wps_sec_dev_type_list_len);
+ }

Re: [PATCH] Fix valgrind abort

2020-10-03 Thread Tobias Heider

On Thu, Sep 24, 2020 at 05:30:51PM +0900, Masato Asou wrote:
> The Valgrind is aborted in OpenBSD current as follows:
> 
> $ sysctl -n kern.version
> OpenBSD 6.8-beta (GENERIC.MP) #77: Wed Sep 23 15:36:00 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> $ valgrind /bin/ls
> Abort trap
> $ 
> 
> I made fix this abort.
> 
> comment? ok?

This fixes the bug for me.  ok tobhe@

> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/valgrind/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile  22 May 2020 08:51:24 -  1.24
> +++ Makefile  24 Sep 2020 07:21:20 -
> @@ -7,7 +7,7 @@ CATEGORIES =  devel
>  
>  V =  3.10.1
>  PV = 20160331
> -REVISION =   17
> +REVISION =   18
>  DISTNAME =   valgrind-${V}
>  EXTRACT_SUFX =   .tar.bz2
>  
> Index: patches/patch-coregrind_link_tool_exe_openbsd_in
> ===
> RCS file: 
> /cvs/ports/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-coregrind_link_tool_exe_openbsd_in
> --- patches/patch-coregrind_link_tool_exe_openbsd_in  6 Nov 2019 05:25:13 
> -   1.4
> +++ patches/patch-coregrind_link_tool_exe_openbsd_in  24 Sep 2020 07:21:20 
> -
> @@ -1,16 +1,40 @@
>  --- coregrind/link_tool_exe_openbsd.in.orig  Fri Sep 27 10:40:06 2019
> -+++ coregrind/link_tool_exe_openbsd.in   Fri Sep 27 10:45:59 2019
> -@@ -77,7 +77,12 @@
> - my $origbase = 0x40;
> - system(sprintf "sed -e 's|%x|%x|g' < $ldscript > $temp", $origbase, 
> $notebase);
>  coregrind/link_tool_exe_openbsd.in   Fri Sep 25 00:50:44 2020
> +@@ -63,22 +63,13 @@
> + # The cc invokation to do the final link
> + my $cc = $ARGV[1];
>   
> --my $cmd = sprintf "$cc -static -nopie -Wl,-Ttext=0x%x -Wl,-T,$temp", 
> $textbase;
> +-# and the 'restargs' are argv[2 ..]
>  +# XXX The '-s' option was not specified when executing the install command.
>  +# Instead '--strip-all' is now executed at link time.
>  +# strip command rewrite offset and align in ELF file. Therefor, when 
> valgrind
>  +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
>  +# call.
> -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x 
> -Wl,-T,$temp", $textbase;
> ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x", 
> "$ala + 0x1000";
>   
> +-# so, build up the complete command here:
> +-# 'cc' -static -Ttext='ala' 'restargs'
> +-
> +-my $textbase = eval("$ala + 0x1000");
> +-my $notebase = eval("$ala");
> +-
> +-my $ldscript = "/usr/libdata/ldscripts/elf_x86_64_obsd.x";
> +-my $temp = `mktemp /tmp/XX`;
> +-chomp($temp);
> +-my $origbase = 0x40;
> +-system(sprintf "sed -e 's|%x|%x|g' < $ldscript > $temp", $origbase, 
> $notebase);
> +-
> +-my $cmd = sprintf "$cc -static -nopie -Wl,-Ttext=0x%x -Wl,-T,$temp", 
> $textbase;
> +-
>   # Add the rest of the parameters
>   foreach my $n (2 .. $#ARGV) {
> +$cmd = "$cmd $ARGV[$n]";
> +@@ -89,8 +80,6 @@
> + 
> + # Execute the command:
> + my $r = system("$cmd");
> +-
> +-unlink $temp;
> + 
> + if ($r == 0) {
> + exit 0;
> --
> ASOU Masato
>

85 matches

Mail list logo