Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)
> Date: Wed, 06 Mar 2024 23:32:51 +0100
> From: Mark Kettenis
>
> > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > From: Jeremie Courreges-Anglas
> >
> > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > should make release.
> >
> > Since I now have a laptop with BTI I figured I was going to give this
> > a try. -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > For the amd64 diff I'm deliberately not caring about the assembly for
> > Windows. I can't test the arm64 part but it looks simple.
> >
> > ok?
> >
> > Sebastian, feel free to commit this if it matches your previous diff.
>
> Looks right to me.
Actually, the arm64 bit is probably incomplete. And tb@ has a point
that endbr64 should be after the .cfi_startproc.
> > Index: Makefile
> > ===
> > RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> > diff -u -p -r1.37 Makefile
> > --- Makefile5 Mar 2024 16:11:15 - 1.37
> > +++ Makefile6 Mar 2024 17:26:11 -
> > @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
> >
> > # note: this port does not use the gnustep module
> > VERSION = 2.2
> > -REVISION = 3
> > +REVISION = 4
> > GH_ACCOUNT = gnustep
> > GH_PROJECT = libobjc2
> > GH_TAGNAME = v${VERSION}
> > Index: patches/patch-objc_msgSend_aarch64_S
> > ===
> > RCS file: patches/patch-objc_msgSend_aarch64_S
> > diff -N patches/patch-objc_msgSend_aarch64_S
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
> > @@ -0,0 +1,11 @@
> > +Index: objc_msgSend.aarch64.S
> > +--- objc_msgSend.aarch64.S.orig
> > objc_msgSend.aarch64.S
> > +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> > + CDECL(objc_msgSend_fpret):
> > + CDECL(objc_msgSend_stret):
> > + EH_START
> > ++ btic
> > +
> > + cbzx0, 4f // Skip everything if the receiver is
> > nil
> > + // Jump to 6: if this is a small
> > object
> > Index: patches/patch-objc_msgSend_x86-64_S
> > ===
> > RCS file: patches/patch-objc_msgSend_x86-64_S
> > diff -N patches/patch-objc_msgSend_x86-64_S
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
> > @@ -0,0 +1,15 @@
> > +Index: objc_msgSend.x86-64.S
> > +--- objc_msgSend.x86-64.S.orig
> > objc_msgSend.x86-64.S
> > +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> > + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> > + CDECL(objc_msgSend_fpret):
> > + CDECL(objc_msgSend):
> > ++ endbr64
> > + MSGSEND objc_msgSend, %rdi, %rsi
> > + .globl CDECL(objc_msgSend_stret)
> > + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> > + CDECL(objc_msgSend_stret):
> > ++ endbr64
> > + MSGSEND objc_msgSend_stret, %rsi, %rdx
> > + #endif
> >
> >
> > --
> > jca
> >
>
Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)
> Date: Wed, 6 Mar 2024 19:02:35 +0100
> From: Jeremie Courreges-Anglas
>
> Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > Could you please resend the endbr64 patches with Cc kettenis? They
> > should make release.
>
> Since I now have a laptop with BTI I figured I was going to give this
> a try. -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> For the amd64 diff I'm deliberately not caring about the assembly for
> Windows. I can't test the arm64 part but it looks simple.
>
> ok?
>
> Sebastian, feel free to commit this if it matches your previous diff.
Looks right to me.
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile 5 Mar 2024 16:11:15 - 1.37
> +++ Makefile 6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>
> # note: this port does not use the gnustep module
> VERSION =2.2
> -REVISION = 3
> +REVISION = 4
> GH_ACCOUNT = gnustep
> GH_PROJECT = libobjc2
> GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S 6 Mar 2024 17:19:04 -
> @@ -0,0 +1,11 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
> objc_msgSend.aarch64.S
> +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend_stret):
> + EH_START
> ++btic
> +
> + cbzx0, 4f // Skip everything if the receiver is
> nil
> +// Jump to 6: if this is a small
> object
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
> @@ -0,0 +1,15 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
> objc_msgSend.x86-64.S
> +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend):
> ++endbr64
> + MSGSEND objc_msgSend, %rdi, %rsi
> + .globl CDECL(objc_msgSend_stret)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> + CDECL(objc_msgSend_stret):
> ++endbr64
> + MSGSEND objc_msgSend_stret, %rsi, %rdx
> + #endif
>
>
> --
> jca
>
Re: UPDATE security/vaultwarden-1.30.5 and www/vaultwarden-web-2024.1.2b
Le Sun, Mar 03, 2024 at 09:10:40PM +0100, Bjorn Ketelaars a écrit : > Simple diff for updating vaultwarden to 1.30.5 and vaultwarden-web to > 2024.1.2b. > > Changelog: > https://github.com/dani-garcia/vaultwarden/releases/tag/1.30.4 > https://github.com/dani-garcia/vaultwarden/releases/tag/1.30.5 > > https://github.com/dani-garcia/bw_web_builds/releases/tag/v2024.1.2b > > Run tested on amd64. > > OK? > OK denis@
Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)
On Wed, Mar 06, 2024 at 07:02:35PM +0100, Jeremie Courreges-Anglas wrote:
> Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > Could you please resend the endbr64 patches with Cc kettenis? They
> > should make release.
>
> Since I now have a laptop with BTI I figured I was going to give this
> a try. -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> For the amd64 diff I'm deliberately not caring about the assembly for
> Windows. I can't test the arm64 part but it looks simple.
>
> ok?
I had a somewhat different approach:
https://marc.info/?l=openbsd-ports&m=170915116023144&w=2
Since you add the endbr64 before the MSGSEND macro, they now come before
.cfi_startproc. In all other patches I'm aware of, we put them after.
Not sure if that will matter in the future.
I also added landing pads to the trampolines; I'm sure the old libobjc2
warned about these with kettenis's ld.lld diff. Maybe it's no longer
needed.
>
> Sebastian, feel free to commit this if it matches your previous diff.
>
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile 5 Mar 2024 16:11:15 - 1.37
> +++ Makefile 6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>
> # note: this port does not use the gnustep module
> VERSION =2.2
> -REVISION = 3
> +REVISION = 4
> GH_ACCOUNT = gnustep
> GH_PROJECT = libobjc2
> GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S 6 Mar 2024 17:19:04 -
> @@ -0,0 +1,11 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
> objc_msgSend.aarch64.S
> +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend_stret):
> + EH_START
> ++btic
> +
> + cbzx0, 4f // Skip everything if the receiver is
> nil
> +// Jump to 6: if this is a small
> object
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
> @@ -0,0 +1,15 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
> objc_msgSend.x86-64.S
> +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend):
> ++endbr64
> + MSGSEND objc_msgSend, %rdi, %rsi
> + .globl CDECL(objc_msgSend_stret)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> + CDECL(objc_msgSend_stret):
> ++endbr64
> + MSGSEND objc_msgSend_stret, %rsi, %rdx
> + #endif
>
>
> --
> jca
>
gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)
Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> Could you please resend the endbr64 patches with Cc kettenis? They
> should make release.
Since I now have a laptop with BTI I figured I was going to give this
a try. -current x11/gnustep/zipper was crashing with SIGILL on amd64.
For the amd64 diff I'm deliberately not caring about the assembly for
Windows. I can't test the arm64 part but it looks simple.
ok?
Sebastian, feel free to commit this if it matches your previous diff.
Index: Makefile
===
RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -p -r1.37 Makefile
--- Makefile5 Mar 2024 16:11:15 - 1.37
+++ Makefile6 Mar 2024 17:26:11 -
@@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
# note: this port does not use the gnustep module
VERSION = 2.2
-REVISION = 3
+REVISION = 4
GH_ACCOUNT = gnustep
GH_PROJECT = libobjc2
GH_TAGNAME = v${VERSION}
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
@@ -0,0 +1,11 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
objc_msgSend.aarch64.S
+@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend_stret):
+ EH_START
++ btic
+
+ cbzx0, 4f // Skip everything if the receiver is
nil
+ // Jump to 6: if this is a small
object
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
@@ -0,0 +1,15 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
objc_msgSend.x86-64.S
+@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
+ TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend):
++ endbr64
+ MSGSEND objc_msgSend, %rdi, %rsi
+ .globl CDECL(objc_msgSend_stret)
+ TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
+ CDECL(objc_msgSend_stret):
++ endbr64
+ MSGSEND objc_msgSend_stret, %rsi, %rdx
+ #endif
--
jca
Re: [maintainer update] Bump graphics/decker 1.39 -> 1.40
On Wed Mar 6, 2024 at 11:17 AM EST, Omar Polo wrote: > I've committed the update with devel/xdg-utils moved as RUN_DEPENDS. > > As sthen explained, LIB_DEPENDS is only for ports that provides shared > libraries that this port links to. Instead, devel/xdg-utils only > provides a command that decker needs at runtime, so it has to be a > RUN_DEPENDS. > > /usr/ports/infrastructure/bin/portcheck will caught these mistakes, it's > handy to run it after building the port to catch small issues like this > one. (tip: it's handy to add /usr/ports/infrastructe/bin to $PATH) > > Also, while with CVS you can't (easily) add a directory unless you have > write access, you can still `cvs add' new files. This is better than > attaching new files because it's easier to apply them. > > `cvs -q -n up -d' will tell you the state of the directory, with ? > entries being files unknown to CVS, R files marked as removed with > `cvs rm', A files added, M files modified, etc. > > I'm attaching the diff that I've actually committed. > > Thanks! Thank you so much for the help, Omar! I'll do my best to remember these for my next patches. -- Jag Talon (he/him) https://jagtalon.net/ https://weirder.earth/@jag 2F17E7825E755F08.asc Description: application/pgp-keys
Re: [maintainer update] Bump graphics/decker 1.39 -> 1.40
Hello,
On 2024/03/06 10:19:39 -0500, "Jag Talon" wrote:
> Notes:
> ==
>
> * Aside from bumping the version number, I also added a dependency to
> xdg-utils
> to the Makefile. Apparently it's used within the app to open external links. I
> misunderstood it as only applicable to the web version of Decker which we
> don't
> build. Now Decker is able to open external links.
>
> * I also added a new patch called patch-c_dom_h which includes sys/wait.h in
> the
> c/dom.h file. This allows the build to continue.
I've committed the update with devel/xdg-utils moved as RUN_DEPENDS.
As sthen explained, LIB_DEPENDS is only for ports that provides shared
libraries that this port links to. Instead, devel/xdg-utils only
provides a command that decker needs at runtime, so it has to be a
RUN_DEPENDS.
/usr/ports/infrastructure/bin/portcheck will caught these mistakes, it's
handy to run it after building the port to catch small issues like this
one. (tip: it's handy to add /usr/ports/infrastructe/bin to $PATH)
Also, while with CVS you can't (easily) add a directory unless you have
write access, you can still `cvs add' new files. This is better than
attaching new files because it's easier to apply them.
`cvs -q -n up -d' will tell you the state of the directory, with ?
entries being files unknown to CVS, R files marked as removed with
`cvs rm', A files added, M files modified, etc.
I'm attaching the diff that I've actually committed.
Thanks!
Index: Makefile
===
RCS file: /home/cvs/ports/graphics/decker/Makefile,v
diff -u -p -r1.2 Makefile
--- Makefile18 Feb 2024 21:55:41 - 1.2
+++ Makefile6 Mar 2024 16:02:43 -
@@ -1,6 +1,6 @@
COMMENT = multimedia platform inspired by HyperCard
-DIST_TUPLE = github JohnEarnest Decker v1.39 .
+DIST_TUPLE = github JohnEarnest Decker v1.40 .
PKGNAME = ${DISTNAME:L}
CATEGORIES = graphics
@@ -21,6 +21,8 @@ BUILD_DEPENDS = editors/vim \
LIB_DEPENDS = devel/sdl2 \
devel/sdl2-image
+
+RUN_DEPENDS = devel/xdg-utils
ALL_TARGET = decker lilt docs
Index: distinfo
===
RCS file: /home/cvs/ports/graphics/decker/distinfo,v
diff -u -p -r1.2 distinfo
--- distinfo18 Feb 2024 21:55:41 - 1.2
+++ distinfo6 Mar 2024 15:58:27 -
@@ -1,2 +1,2 @@
-SHA256 (JohnEarnest-Decker-v1.39.tar.gz) =
PTLwp775tqWUAw5/DhAtTcKtOwOvRvcAEmXSDuk4384=
-SIZE (JohnEarnest-Decker-v1.39.tar.gz) = 1343234
+SHA256 (JohnEarnest-Decker-v1.40.tar.gz) =
VnVUKMFYJ6fK+7faWc+DII+p9bpiH4itHCs4aD1kzug=
+SIZE (JohnEarnest-Decker-v1.40.tar.gz) = 1348788
Index: patches/patch-Makefile
===
RCS file: /home/cvs/ports/graphics/decker/patches/patch-Makefile,v
diff -u -p -r1.1.1.1 patch-Makefile
--- patches/patch-Makefile 18 Feb 2024 11:03:40 - 1.1.1.1
+++ patches/patch-Makefile 6 Mar 2024 15:58:27 -
@@ -13,8 +13,8 @@ Index: Makefile
# -Wno-misleading-indentation silences warnings which are entirely
spurious.
FLAGS:=$(FLAGS) -Wno-misleading-indentation -Wno-unknown-warning-option
FLAGS:=$(FLAGS) -lm
-@@ -43,16 +43,16 @@ ifneq ("$(EXTRA_FLAGS)","")
- endif
+@@ -46,16 +46,16 @@ endif
+ # FLAGS:=$(FLAGS) -DDANGER_ZONE
resources:
- @chmod +x ./scripts/resources.sh
@@ -36,7 +36,7 @@ Index: Makefile
clean:
@rm -rf ./c/build/
-@@ -60,19 +60,19 @@ clean:
+@@ -63,19 +63,19 @@ clean:
@rm -f docs/*.html
install:
Index: patches/patch-c_dom_h
===
RCS file: patches/patch-c_dom_h
diff -N patches/patch-c_dom_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-c_dom_h 6 Mar 2024 15:59:16 -
@@ -0,0 +1,9 @@
+Index: c/dom.h
+--- c/dom.h.orig
c/dom.h
+@@ -1,4 +1,4 @@
+-
++#include
+ #include "resources.h"
+
+ // Decker document object model
Re: [new] www/pipe-viewer
On 2024/03/06 16:42, Omar Polo wrote: > while here i've changed to port to use DIST_TUPLE rather than GH_* and note that this breaks portroach
Re: [maintainer update] Bump graphics/decker 1.39 -> 1.40
Thank you for the pointer! Attaching a new diff and also I added a comment to
the dom.h patch.
--
Jag Talon (he/him)
https://jagtalon.net/
https://weirder.earth/@jag
2F17E7825E755F08.asc
Description: application/pgp-keys
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/graphics/decker/patches/patch-Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 patch-Makefile
--- patches/patch-Makefile 18 Feb 2024 11:03:40 - 1.1.1.1
+++ patches/patch-Makefile 6 Mar 2024 16:02:10 -
@@ -13,8 +13,8 @@ Index: Makefile
# -Wno-misleading-indentation silences warnings which are entirely spurious.
FLAGS:=$(FLAGS) -Wno-misleading-indentation -Wno-unknown-warning-option
FLAGS:=$(FLAGS) -lm
-@@ -43,16 +43,16 @@ ifneq ("$(EXTRA_FLAGS)","")
- endif
+@@ -46,16 +46,16 @@ endif
+ # FLAGS:=$(FLAGS) -DDANGER_ZONE
resources:
- @chmod +x ./scripts/resources.sh
@@ -36,7 +36,7 @@ Index: Makefile
clean:
@rm -rf ./c/build/
-@@ -60,19 +60,19 @@ clean:
+@@ -63,19 +63,19 @@ clean:
@rm -f docs/*.html
install:
Index: Makefile
===
RCS file: /cvs/ports/graphics/decker/Makefile,v
retrieving revision 1.2
diff -u -p -u -r1.2 Makefile
--- Makefile 18 Feb 2024 21:55:41 - 1.2
+++ Makefile 6 Mar 2024 16:02:10 -
@@ -1,6 +1,6 @@
COMMENT = multimedia platform inspired by HyperCard
-DIST_TUPLE = github JohnEarnest Decker v1.39 .
+DIST_TUPLE = github JohnEarnest Decker v1.40 .
PKGNAME = ${DISTNAME:L}
CATEGORIES = graphics
@@ -21,6 +21,8 @@ BUILD_DEPENDS = editors/vim \
LIB_DEPENDS = devel/sdl2 \
devel/sdl2-image
+
+RUN_DEPENDS = devel/xdg-utils
ALL_TARGET = decker lilt docs
Index: distinfo
===
RCS file: /cvs/ports/graphics/decker/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo 18 Feb 2024 21:55:41 - 1.2
+++ distinfo 6 Mar 2024 16:02:10 -
@@ -1,2 +1,2 @@
-SHA256 (JohnEarnest-Decker-v1.39.tar.gz) = PTLwp775tqWUAw5/DhAtTcKtOwOvRvcAEmXSDuk4384=
-SIZE (JohnEarnest-Decker-v1.39.tar.gz) = 1343234
+SHA256 (JohnEarnest-Decker-v1.40.tar.gz) = VnVUKMFYJ6fK+7faWc+DII+p9bpiH4itHCs4aD1kzug=
+SIZE (JohnEarnest-Decker-v1.40.tar.gz) = 1348788
- add sys/wait.h for WIFEXITED and WEXITSTATUS
Index: c/dom.h
--- c/dom.h.orig
+++ c/dom.h
@@ -1,4 +1,4 @@
-
+#include
#include "resources.h"
// Decker document object model
Re: [new] www/pipe-viewer
Hello,
On 2024/03/04 22:38:23 +, Klemens Nanni wrote:
> On Mon, Mar 04, 2024 at 05:21:52PM -0500, Stefan Moran wrote:
> > Attached is a port for www/pipe-viewer 0.5.0, a lightweight perl youtube
> > client, designed to be used without a Google API key. The port is a
> > multipackage with -gtk, a GTK3 frontend using x11/p5-Gtk3, and -main,
> > the standard cli interface. The port depends on either youtube-dl or
> > yt-dlp to fetch videos, and I chose to include www/yt-dlp as a rundep as
> > that seems to be the more heavily-maintained and functional ( and also
> > less legally-targeted ;) ) project at this point in time. I also chose
> > to include most of the optional dependencies, excluding
> > LWP::UserAgent::Cached (not currently ported).
> >
> > https://github.com/trizen/pipe-viewer
>
> Port-wise looks fine, although I'd capitalise youtube in COMMENT
> accordingly and distinguish DESCR-gtk from DESCR-main.
> Perhaps add multimedia, net and/or x11 to CATEGORIES?
+1
I'd also try to have a slightly different COMMENT for the -gtk
subpackage and change its name to gkt-pipe-viewer to mirror the name of
the binary it installs.
When it makes sense, I think it's easier for discovery purposes to have
the name of the package to be the same of the program it installs.
> Starts, searches and plays fine in brief testing, seems like a handy
> alternative to the (heavy) Qt alternatives minitube and plasmatube.
some here, briefly tried but I'm liking it, it could become my preferred
way to navigate youtube :)
I'm attaching a diff against your makefile and an updated tarball that's
ok op@ to import.
while here i've changed to port to use DIST_TUPLE rather than GH_* and
re-run make makesum due to it. I've also tried to change the two DESCR
a bit, to reiterate which one has a GTK interface and which don't.
--- Makefile.orig Wed Mar 6 15:02:57 2024
+++ MakefileWed Mar 6 16:33:07 2024
@@ -1,17 +1,14 @@
-COMMENT-main = lightweight perl youtube client
-COMMENT-gtk = lightweight perl youtube client
+COMMENT-main = lightweight YouTube client
+COMMENT-gtk = lightweight YouTube client with a GTK interface
VERSION = 0.5.0
+DIST_TUPLE = github trizen pipe-viewer ${VERSION} .
PKGNAME-main = pipe-viewer-${VERSION}
-PKGNAME-gtk = pipe-viewer-gtk-${VERSION}
+PKGNAME-gtk = gtk-pipe-viewer-${VERSION}
MULTI_PACKAGES = -main -gtk
-GH_ACCOUNT = trizen
-GH_PROJECT = pipe-viewer
-GH_TAGNAME = ${VERSION}
-
-CATEGORIES = www
+CATEGORIES = www multimedia
MAINTAINER = Stefan Moran
pipe-viewer.tar.gz
Description: GNU Zip compressed data
Re: [maintainer update] Bump graphics/decker 1.39 -> 1.40
On 2024/03/06 10:19, Jag Talon wrote:
> Notes:
> ==
>
> * Aside from bumping the version number, I also added a dependency to
> xdg-utils
> to the Makefile. Apparently it's used within the app to open external links. I
> misunderstood it as only applicable to the web version of Decker which we
> don't
> build. Now Decker is able to open external links.
>
> * I also added a new patch called patch-c_dom_h which includes sys/wait.h in
> the
> c/dom.h file. This allows the build to continue.
>
> Bug fixes and one new feature:
> ==
>
> * Decker will no longer crash if a prototype is removed from the deck while
> it is being edited.
>
> * Keyboard shortcuts can be used in drawing mode while
> the menu is hidden.
>
> * Lil now includes a "like" operator for performing "glob
> pattern-matching" against strings, much like conventional dialects of SQL.
>
> More details here:
> https://internet-janitor.itch.io/decker/devlog/690682/decker-140
>
> ok?
>
> --
> Jag Talon (he/him)
>
> https://jagtalon.net/
> https://weirder.earth/@jag
>
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/graphics/decker/patches/patch-Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -u -r1.1.1.1 patch-Makefile
> --- patches/patch-Makefile18 Feb 2024 11:03:40 - 1.1.1.1
> +++ patches/patch-Makefile6 Mar 2024 15:03:48 -
> @@ -13,8 +13,8 @@ Index: Makefile
> # -Wno-misleading-indentation silences warnings which are entirely
> spurious.
> FLAGS:=$(FLAGS) -Wno-misleading-indentation -Wno-unknown-warning-option
> FLAGS:=$(FLAGS) -lm
> -@@ -43,16 +43,16 @@ ifneq ("$(EXTRA_FLAGS)","")
> - endif
> +@@ -46,16 +46,16 @@ endif
> + # FLAGS:=$(FLAGS) -DDANGER_ZONE
>
> resources:
> -@chmod +x ./scripts/resources.sh
> @@ -36,7 +36,7 @@ Index: Makefile
>
> clean:
> @rm -rf ./c/build/
> -@@ -60,19 +60,19 @@ clean:
> +@@ -63,19 +63,19 @@ clean:
> @rm -f docs/*.html
>
> install:
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/decker/Makefile,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 Makefile
> --- Makefile 18 Feb 2024 21:55:41 - 1.2
> +++ Makefile 6 Mar 2024 15:03:48 -
> @@ -1,6 +1,6 @@
> COMMENT =multimedia platform inspired by HyperCard
>
> -DIST_TUPLE = github JohnEarnest Decker v1.39 .
> +DIST_TUPLE = github JohnEarnest Decker v1.40 .
> PKGNAME =${DISTNAME:L}
>
> CATEGORIES = graphics
> @@ -20,7 +20,8 @@ BUILD_DEPENDS = editors/vim \
> shells/bash
>
> LIB_DEPENDS =devel/sdl2 \
> - devel/sdl2-image
> + devel/sdl2-image \
> + devel/xdg-utils
LIB_DEPENDS is only valid if the package contains a shared library and
there's an associated entry in WANTLIB.
In this case you want a RUN_DEPENDS.
>
> ALL_TARGET = decker lilt docs
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/graphics/decker/distinfo,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 distinfo
> --- distinfo 18 Feb 2024 21:55:41 - 1.2
> +++ distinfo 6 Mar 2024 15:03:48 -
> @@ -1,2 +1,2 @@
> -SHA256 (JohnEarnest-Decker-v1.39.tar.gz) =
> PTLwp775tqWUAw5/DhAtTcKtOwOvRvcAEmXSDuk4384=
> -SIZE (JohnEarnest-Decker-v1.39.tar.gz) = 1343234
> +SHA256 (JohnEarnest-Decker-v1.40.tar.gz) =
> VnVUKMFYJ6fK+7faWc+DII+p9bpiH4itHCs4aD1kzug=
> +SIZE (JohnEarnest-Decker-v1.40.tar.gz) = 1348788
> Index: c/dom.h
> --- c/dom.h.orig
> +++ c/dom.h
> @@ -1,4 +1,4 @@
> -
> +#include
> #include "resources.h"
>
> // Decker document object model
[maintainer update] Bump graphics/decker 1.39 -> 1.40
Notes:
==
* Aside from bumping the version number, I also added a dependency to xdg-utils
to the Makefile. Apparently it's used within the app to open external links. I
misunderstood it as only applicable to the web version of Decker which we don't
build. Now Decker is able to open external links.
* I also added a new patch called patch-c_dom_h which includes sys/wait.h in the
c/dom.h file. This allows the build to continue.
Bug fixes and one new feature:
==
* Decker will no longer crash if a prototype is removed from the deck while
it is being edited.
* Keyboard shortcuts can be used in drawing mode while
the menu is hidden.
* Lil now includes a "like" operator for performing "glob
pattern-matching" against strings, much like conventional dialects of SQL.
More details here:
https://internet-janitor.itch.io/decker/devlog/690682/decker-140
ok?
--
Jag Talon (he/him)
https://jagtalon.net/
https://weirder.earth/@jag
2F17E7825E755F08.asc
Description: application/pgp-keys
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/graphics/decker/patches/patch-Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 patch-Makefile
--- patches/patch-Makefile 18 Feb 2024 11:03:40 - 1.1.1.1
+++ patches/patch-Makefile 6 Mar 2024 15:03:48 -
@@ -13,8 +13,8 @@ Index: Makefile
# -Wno-misleading-indentation silences warnings which are entirely spurious.
FLAGS:=$(FLAGS) -Wno-misleading-indentation -Wno-unknown-warning-option
FLAGS:=$(FLAGS) -lm
-@@ -43,16 +43,16 @@ ifneq ("$(EXTRA_FLAGS)","")
- endif
+@@ -46,16 +46,16 @@ endif
+ # FLAGS:=$(FLAGS) -DDANGER_ZONE
resources:
- @chmod +x ./scripts/resources.sh
@@ -36,7 +36,7 @@ Index: Makefile
clean:
@rm -rf ./c/build/
-@@ -60,19 +60,19 @@ clean:
+@@ -63,19 +63,19 @@ clean:
@rm -f docs/*.html
install:
Index: Makefile
===
RCS file: /cvs/ports/graphics/decker/Makefile,v
retrieving revision 1.2
diff -u -p -u -r1.2 Makefile
--- Makefile 18 Feb 2024 21:55:41 - 1.2
+++ Makefile 6 Mar 2024 15:03:48 -
@@ -1,6 +1,6 @@
COMMENT = multimedia platform inspired by HyperCard
-DIST_TUPLE = github JohnEarnest Decker v1.39 .
+DIST_TUPLE = github JohnEarnest Decker v1.40 .
PKGNAME = ${DISTNAME:L}
CATEGORIES = graphics
@@ -20,7 +20,8 @@ BUILD_DEPENDS = editors/vim \
shells/bash
LIB_DEPENDS = devel/sdl2 \
- devel/sdl2-image
+ devel/sdl2-image \
+ devel/xdg-utils
ALL_TARGET = decker lilt docs
Index: distinfo
===
RCS file: /cvs/ports/graphics/decker/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo 18 Feb 2024 21:55:41 - 1.2
+++ distinfo 6 Mar 2024 15:03:48 -
@@ -1,2 +1,2 @@
-SHA256 (JohnEarnest-Decker-v1.39.tar.gz) = PTLwp775tqWUAw5/DhAtTcKtOwOvRvcAEmXSDuk4384=
-SIZE (JohnEarnest-Decker-v1.39.tar.gz) = 1343234
+SHA256 (JohnEarnest-Decker-v1.40.tar.gz) = VnVUKMFYJ6fK+7faWc+DII+p9bpiH4itHCs4aD1kzug=
+SIZE (JohnEarnest-Decker-v1.40.tar.gz) = 1348788
Index: c/dom.h
--- c/dom.h.orig
+++ c/dom.h
@@ -1,4 +1,4 @@
-
+#include
#include "resources.h"
// Decker document object model
Re: Salt master on -stable and communication with minions on -current 3006.7 version
add: I have now connected minions (Alpine/Linux and OpenBSD 7.4 and current)
with version 3006.3, 3006.6 and 3006.7
to master with 3006.7.
On 06 Mar 15:11, Uwe Werler wrote:
> Hi Robert,
>
> I reinstalled salt_master with Your patch and it solves the issue.
> Reinstalled salt 3006.3 from 7.4 on some hosts and reconnected to the
> master without any issues.
>
> Thanks!
>
> Best regards
>
> Uwe
>
> On 06 Mar 08:56, Robert Nagy wrote:
> > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > I think we can backport this until there is a new release out.
> >
> > Please try the following diff:
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > diff -u -p -u -r1.183 Makefile
> > --- Makefile1 Mar 2024 12:02:55 - 1.183
> > +++ Makefile6 Mar 2024 07:56:07 -
> > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > MODPY_EGG_VERSION =3006.7
> > DISTNAME = salt-${MODPY_EGG_VERSION}
> >
> > +REVISION = 0
> > +
> > CATEGORIES = sysutils net devel
> >
> > HOMEPAGE = https://saltproject.io/
> > Index: patches/patch-salt_channel_server_py
> > ===
> > RCS file: patches/patch-salt_channel_server_py
> > diff -N patches/patch-salt_channel_server_py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
> > @@ -0,0 +1,52 @@
> > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > newline, this breaks minion auth.
> > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> > from disk.
> > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > +
> > +Index: salt/channel/server.py
> > +--- salt/channel/server.py.orig
> > salt/channel/server.py
> > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > + transport = salt.transport.request_server(opts, **kwargs)
> > + return cls(opts, transport)
> > +
> > ++@classmethod
> > ++def compare_keys(cls, key1, key2):
> > ++"""
> > ++Normalize and compare two keys
> > ++
> > ++Returns:
> > ++bool: ``True`` if the keys match, otherwise ``False``
> > ++"""
> > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > ++
> > + def __init__(self, opts, transport):
> > + self.opts = opts
> > + self.transport = transport
> > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > + elif os.path.isfile(pubfn):
> > + # The key has been accepted, check it
> > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys did not match. This may be an attempt to
> > compromise "
> > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > + # case. Otherwise log the fact that the minion is still
> > + # pending.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "key in pending did not match. This may be an
> > "
> > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > + # so, pass on doing anything here, and let it get
> > automatically
> > + # accepted below.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys in pending did not match. This may be
> > an "
> > Index: patches/patch-salt_grains_core_py
> > ===
> > RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> > diff -u -p -u -r1.12 patch-salt_grains_core_py
> > --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 -
> > 1.12
> > +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> > @@ -24,7 +24
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Hi Robert,
I reinstalled salt_master with Your patch and it solves the issue.
Reinstalled salt 3006.3 from 7.4 on some hosts and reconnected to the
master without any issues.
Thanks!
Best regards
Uwe
On 06 Mar 08:56, Robert Nagy wrote:
> On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > I think we can backport this until there is a new release out.
>
> Please try the following diff:
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/salt/Makefile,v
> diff -u -p -u -r1.183 Makefile
> --- Makefile 1 Mar 2024 12:02:55 - 1.183
> +++ Makefile 6 Mar 2024 07:56:07 -
> @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> MODPY_EGG_VERSION = 3006.7
> DISTNAME = salt-${MODPY_EGG_VERSION}
>
> +REVISION = 0
> +
> CATEGORIES = sysutils net devel
>
> HOMEPAGE = https://saltproject.io/
> Index: patches/patch-salt_channel_server_py
> ===
> RCS file: patches/patch-salt_channel_server_py
> diff -N patches/patch-salt_channel_server_py
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-salt_channel_server_py 6 Mar 2024 07:56:07 -
> @@ -0,0 +1,52 @@
> +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
> this breaks minion auth.
> +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> from disk.
> +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> +
> +Index: salt/channel/server.py
> +--- salt/channel/server.py.orig
> salt/channel/server.py
> +@@ -52,6 +52,16 @@ class ReqServerChannel:
> + transport = salt.transport.request_server(opts, **kwargs)
> + return cls(opts, transport)
> +
> ++@classmethod
> ++def compare_keys(cls, key1, key2):
> ++"""
> ++Normalize and compare two keys
> ++
> ++Returns:
> ++bool: ``True`` if the keys match, otherwise ``False``
> ++"""
> ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> ++
> + def __init__(self, opts, transport):
> + self.opts = opts
> + self.transport = transport
> +@@ -371,7 +381,7 @@ class ReqServerChannel:
> + elif os.path.isfile(pubfn):
> + # The key has been accepted, check it
> + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(), load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the public "
> + "keys did not match. This may be an attempt to
> compromise "
> +@@ -480,7 +490,7 @@ class ReqServerChannel:
> + # case. Otherwise log the fact that the minion is still
> + # pending.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "key in pending did not match. This may be an "
> +@@ -536,7 +546,7 @@ class ReqServerChannel:
> + # so, pass on doing anything here, and let it get
> automatically
> + # accepted below.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "keys in pending did not match. This may be an "
> Index: patches/patch-salt_grains_core_py
> ===
> RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> diff -u -p -u -r1.12 patch-salt_grains_core_py
> --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 - 1.12
> +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> @@ -24,7 +24,7 @@ Index: salt/grains/core.py
> return grains
>
>
> -@@ -2652,10 +2654,12 @@ def os_data():
> +@@ -2744,10 +2746,12 @@ def os_data():
> # derive osrelease from kernelversion prior to that
> grains["osrelease"] = grains["kernelrelease"].split("-")[0]
> grains.update(_bsd_cpudata(grains))
--
wq: ~uw
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Sorry for the confusion.
I mixed the patch with an old one which tried to patch this file... My
fault.
On 06 Mar 10:26, Robert Nagy wrote:
> On 06/03/24 10:44 +0100, Uwe Werler wrote:
> > Salü Robert,
> >
> > it seems that patches/patch-salt_utils_network_py is already in the attic...
> >
> > Best regards
> >
> > Uwe
>
> Why whould we need that patch? I am confused.
>
> > On 06 Mar 08:56, Robert Nagy wrote:
> > > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > > I think we can backport this until there is a new release out.
> > >
> > > Please try the following diff:
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > > diff -u -p -u -r1.183 Makefile
> > > --- Makefile 1 Mar 2024 12:02:55 - 1.183
> > > +++ Makefile 6 Mar 2024 07:56:07 -
> > > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > > MODPY_EGG_VERSION = 3006.7
> > > DISTNAME = salt-${MODPY_EGG_VERSION}
> > >
> > > +REVISION = 0
> > > +
> > > CATEGORIES = sysutils net devel
> > >
> > > HOMEPAGE = https://saltproject.io/
> > > Index: patches/patch-salt_channel_server_py
> > > ===
> > > RCS file: patches/patch-salt_channel_server_py
> > > diff -N patches/patch-salt_channel_server_py
> > > --- /dev/null 1 Jan 1970 00:00:00 -
> > > +++ patches/patch-salt_channel_server_py 6 Mar 2024 07:56:07 -
> > > @@ -0,0 +1,52 @@
> > > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > > newline, this breaks minion auth.
> > > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned
> > > key from disk.
> > > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > > +
> > > +Index: salt/channel/server.py
> > > +--- salt/channel/server.py.orig
> > > salt/channel/server.py
> > > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > > + transport = salt.transport.request_server(opts, **kwargs)
> > > + return cls(opts, transport)
> > > +
> > > ++@classmethod
> > > ++def compare_keys(cls, key1, key2):
> > > ++"""
> > > ++Normalize and compare two keys
> > > ++
> > > ++Returns:
> > > ++bool: ``True`` if the keys match, otherwise ``False``
> > > ++"""
> > > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > > ++
> > > + def __init__(self, opts, transport):
> > > + self.opts = opts
> > > + self.transport = transport
> > > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > > + elif os.path.isfile(pubfn):
> > > + # The key has been accepted, check it
> > > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > > load["pub"]:
> > > ++if not self.compare_keys(pubfn_handle.read(),
> > > load["pub"]):
> > > + log.error(
> > > + "Authentication attempt from %s failed, the
> > > public "
> > > + "keys did not match. This may be an attempt to
> > > compromise "
> > > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > > + # case. Otherwise log the fact that the minion is still
> > > + # pending.
> > > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > > pubfn_handle:
> > > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > > load["pub"]:
> > > ++if not self.compare_keys(pubfn_handle.read(),
> > > load["pub"]):
> > > + log.error(
> > > + "Authentication attempt from %s failed, the
> > > public "
> > > + "key in pending did not match. This may be
> > > an "
> > > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > > + # so, pass on doing anything here, and let it get
> > > automatically
> > > + # accepted below.
> > > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > > pubfn_handle:
> > > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > > load["pub"]:
> > > ++if not self.compare_keys(pubfn_handle.read(),
> > > load["pub"]):
> > > + log.error(
> > > + "Authentication attempt from %s failed, the
> > > public "
> > > + "keys in pending did not match. This may be
> > > an "
> > > Index: patches/patch-salt_grains_core_py
> > > ===
> > > RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> > > diff -u -p -u -r1.12 patch-salt_grains_
UPDATE: Stripe-cli-1.19.2
Hello,
Update for Stripe-cli to 1.19.2:
https://github.com/stripe/stripe-cli/releases/tag/v1.19.2
OK? Comments?
Cheers.-
Index: Makefile
===
RCS file: /cvs/ports/sysutils/stripe-cli/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile3 Sep 2023 15:07:45 - 1.3
+++ Makefile6 Mar 2024 10:11:33 -
@@ -1,7 +1,7 @@
COMMENT = build, test, and manage your Stripe integration
-V =1.17.2
+V =1.19.2
MODGO_MODNAME =github.com/stripe/stripe-cli
MODGO_VERSION =v${V}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/stripe-cli/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo3 Sep 2023 15:07:45 - 1.3
+++ distinfo6 Mar 2024 10:11:34 -
@@ -872,7 +872,7 @@ SHA256 (go_modules/rsc.io/quote/v3/@v/v3
SHA256 (go_modules/rsc.io/quote/v3/@v/v3.1.0.zip) =
tDTLv8MsF7UijQsO3erqib707JvZC1yPxVtk+M4T7rk=
SHA256 (go_modules/rsc.io/sampler/@v/v1.3.0.mod) =
oq5uhUCkC4XldwPMYYuZxbEHU4bZWOiZmg4tTALzpwU=
SHA256 (go_modules/rsc.io/sampler/@v/v1.3.0.zip) =
2iArDagDqyZhq5imgLuk9kEjoyblQMJVgrbNu53BFKo=
-SHA256 (stripe-cli-v1.17.2.zip) = /Apj0keragSCDSz9cwhqu0h2Mu2f0iApDXJGUjrC1C4=
+SHA256 (stripe-cli-v1.19.2.zip) = NlCrv3UnY9dQvOQG+ECE5721EWajL3qh3UAPfgdiYE4=
SIZE (go_modules/cloud.google.com/go/@v/v0.100.2.mod) = 531
SIZE (go_modules/cloud.google.com/go/@v/v0.100.2.zip) = 567152
SIZE (go_modules/cloud.google.com/go/@v/v0.26.0.mod) = 27
@@ -1747,4 +1747,4 @@ SIZE (go_modules/rsc.io/quote/v3/@v/v3.1
SIZE (go_modules/rsc.io/quote/v3/@v/v3.1.0.zip) = 2223
SIZE (go_modules/rsc.io/sampler/@v/v1.3.0.mod) = 88
SIZE (go_modules/rsc.io/sampler/@v/v1.3.0.zip) = 14308
-SIZE (stripe-cli-v1.17.2.zip) = 1693112
+SIZE (stripe-cli-v1.19.2.zip) = 1782566
--
%gonzalo
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 06/03/24 10:44 +0100, Uwe Werler wrote:
> Salü Robert,
>
> it seems that patches/patch-salt_utils_network_py is already in the attic...
>
> Best regards
>
> Uwe
Why whould we need that patch? I am confused.
> On 06 Mar 08:56, Robert Nagy wrote:
> > On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > > I think we can backport this until there is a new release out.
> >
> > Please try the following diff:
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/sysutils/salt/Makefile,v
> > diff -u -p -u -r1.183 Makefile
> > --- Makefile1 Mar 2024 12:02:55 - 1.183
> > +++ Makefile6 Mar 2024 07:56:07 -
> > @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> > MODPY_EGG_VERSION =3006.7
> > DISTNAME = salt-${MODPY_EGG_VERSION}
> >
> > +REVISION = 0
> > +
> > CATEGORIES = sysutils net devel
> >
> > HOMEPAGE = https://saltproject.io/
> > Index: patches/patch-salt_channel_server_py
> > ===
> > RCS file: patches/patch-salt_channel_server_py
> > diff -N patches/patch-salt_channel_server_py
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-salt_channel_server_py6 Mar 2024 07:56:07 -
> > @@ -0,0 +1,52 @@
> > +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a
> > newline, this breaks minion auth.
> > +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> > +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> > from disk.
> > +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> > +
> > +Index: salt/channel/server.py
> > +--- salt/channel/server.py.orig
> > salt/channel/server.py
> > +@@ -52,6 +52,16 @@ class ReqServerChannel:
> > + transport = salt.transport.request_server(opts, **kwargs)
> > + return cls(opts, transport)
> > +
> > ++@classmethod
> > ++def compare_keys(cls, key1, key2):
> > ++"""
> > ++Normalize and compare two keys
> > ++
> > ++Returns:
> > ++bool: ``True`` if the keys match, otherwise ``False``
> > ++"""
> > ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> > ++
> > + def __init__(self, opts, transport):
> > + self.opts = opts
> > + self.transport = transport
> > +@@ -371,7 +381,7 @@ class ReqServerChannel:
> > + elif os.path.isfile(pubfn):
> > + # The key has been accepted, check it
> > + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys did not match. This may be an attempt to
> > compromise "
> > +@@ -480,7 +490,7 @@ class ReqServerChannel:
> > + # case. Otherwise log the fact that the minion is still
> > + # pending.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "key in pending did not match. This may be an
> > "
> > +@@ -536,7 +546,7 @@ class ReqServerChannel:
> > + # so, pass on doing anything here, and let it get
> > automatically
> > + # accepted below.
> > + with salt.utils.files.fopen(pubfn_pend, "r") as
> > pubfn_handle:
> > +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> > load["pub"]:
> > ++if not self.compare_keys(pubfn_handle.read(),
> > load["pub"]):
> > + log.error(
> > + "Authentication attempt from %s failed, the
> > public "
> > + "keys in pending did not match. This may be
> > an "
> > Index: patches/patch-salt_grains_core_py
> > ===
> > RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> > diff -u -p -u -r1.12 patch-salt_grains_core_py
> > --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 -
> > 1.12
> > +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> > @@ -24,7 +24,7 @@ Index: salt/grains/core.py
> > return grains
> >
> >
> > -@@ -2652,10 +2654,12 @@ def os_data():
> > +@@ -2744,10 +2746,12 @@ def os_data():
> > # derive osr
Re: Salt master on -stable and communication with minions on -current 3006.7 version
On 2024/03/06 10:44, Uwe Werler wrote: > Salü Robert, > > it seems that patches/patch-salt_utils_network_py is already in the attic... Fortunately CVS allows readding files from the attic.
Re: x11/gnustep/libobjc2 failed to build
> thank you, followed your suggestion to move to /usr/local/include/gnustep. > as well as removed the conflict from devel/libdispatch Could you please resend the endbr64 patches with Cc kettenis? They should make release.
Re: Salt master on -stable and communication with minions on -current 3006.7 version
Salü Robert,
it seems that patches/patch-salt_utils_network_py is already in the attic...
Best regards
Uwe
On 06 Mar 08:56, Robert Nagy wrote:
> On 06/03/24 08:43 +0100, Robert Nagy wrote:
> > I think we can backport this until there is a new release out.
>
> Please try the following diff:
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/salt/Makefile,v
> diff -u -p -u -r1.183 Makefile
> --- Makefile 1 Mar 2024 12:02:55 - 1.183
> +++ Makefile 6 Mar 2024 07:56:07 -
> @@ -18,6 +18,8 @@ COMMENT = remote execution and configur
> MODPY_EGG_VERSION = 3006.7
> DISTNAME = salt-${MODPY_EGG_VERSION}
>
> +REVISION = 0
> +
> CATEGORIES = sysutils net devel
>
> HOMEPAGE = https://saltproject.io/
> Index: patches/patch-salt_channel_server_py
> ===
> RCS file: patches/patch-salt_channel_server_py
> diff -N patches/patch-salt_channel_server_py
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-salt_channel_server_py 6 Mar 2024 07:56:07 -
> @@ -0,0 +1,52 @@
> +52d98866200384dbaf3dbdecf66de00ff6d2195c fix: Older keys end with a newline,
> this breaks minion auth.
> +4e72e2f0a57b594c3f7e14cc385a066097a268b2 fix: typo's
> +0f4c022fdaabb41962e7fde1baca7bf73122f534 Simply check against cleaned key
> from disk.
> +ecc39aa994c55b22c10320380abf6bd24529496d Refactor and add some tests
> +
> +Index: salt/channel/server.py
> +--- salt/channel/server.py.orig
> salt/channel/server.py
> +@@ -52,6 +52,16 @@ class ReqServerChannel:
> + transport = salt.transport.request_server(opts, **kwargs)
> + return cls(opts, transport)
> +
> ++@classmethod
> ++def compare_keys(cls, key1, key2):
> ++"""
> ++Normalize and compare two keys
> ++
> ++Returns:
> ++bool: ``True`` if the keys match, otherwise ``False``
> ++"""
> ++return salt.crypt.clean_key(key1) == salt.crypt.clean_key(key2)
> ++
> + def __init__(self, opts, transport):
> + self.opts = opts
> + self.transport = transport
> +@@ -371,7 +381,7 @@ class ReqServerChannel:
> + elif os.path.isfile(pubfn):
> + # The key has been accepted, check it
> + with salt.utils.files.fopen(pubfn, "r") as pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) != load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(), load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the public "
> + "keys did not match. This may be an attempt to
> compromise "
> +@@ -480,7 +490,7 @@ class ReqServerChannel:
> + # case. Otherwise log the fact that the minion is still
> + # pending.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "key in pending did not match. This may be an "
> +@@ -536,7 +546,7 @@ class ReqServerChannel:
> + # so, pass on doing anything here, and let it get
> automatically
> + # accepted below.
> + with salt.utils.files.fopen(pubfn_pend, "r") as
> pubfn_handle:
> +-if salt.crypt.clean_key(pubfn_handle.read()) !=
> load["pub"]:
> ++if not self.compare_keys(pubfn_handle.read(),
> load["pub"]):
> + log.error(
> + "Authentication attempt from %s failed, the
> public "
> + "keys in pending did not match. This may be an "
> Index: patches/patch-salt_grains_core_py
> ===
> RCS file: /cvs/ports/sysutils/salt/patches/patch-salt_grains_core_py,v
> diff -u -p -u -r1.12 patch-salt_grains_core_py
> --- patches/patch-salt_grains_core_py 28 Apr 2023 18:30:40 - 1.12
> +++ patches/patch-salt_grains_core_py 6 Mar 2024 07:56:07 -
> @@ -24,7 +24,7 @@ Index: salt/grains/core.py
> return grains
>
>
> -@@ -2652,10 +2654,12 @@ def os_data():
> +@@ -2744,10 +2746,12 @@ def os_data():
> # derive osrelease from kernelversion prior to that
> grains["osrelease"] = grains["kernelrelease"].split("-")[0]
> grains.update(_bsd_cpudata(grains))
--
wq: ~uw
Re: databases/victoriametrics: update to v1.99.0
On 2024/03/06 00:10, Lucas Gabriel Vuotto wrote: > > 1. Make VictoriaLogs a different package. A bit wasteful, but the reality >is that the tags differ. Agreed. (If not doing this and instead using subpackages, PLIST-main needs "@pkgpath databases/victoriametrics"). > 2. Stick with LTS. No opinion on this, I don't know victoriametrics well enough. For some programs LTS makes sense, for others it doesn't.
Re: databases/victoriametrics: update to v1.99.0
Le Wed, Mar 06, 2024 at 12:10:37AM +, Lucas Gabriel Vuotto a écrit : > On Mon, Mar 04, 2024 at 01:13:46PM +0100, Denis Fondras wrote: > > Here is a diff to update VictoriaMetrics to v1.99.0. > > > > I also added VictoriaLogs in a separate package. > > > > Denis > > Haven't tested the patch yet, but I have a couple of questions / > discussions about the approach. > > 1. What VictoriaMetrics did with Git tags is ugly in my opinion: >there are v0.5.0-victorialogs and v1.99.0. In this particular case, >the diff is only documentation [0]. But there was a >v0.4.0-victorialogs and v0.4.1-victorialogs with an important bugfix >(make it run non-readonly), and in such cases I don't how a sensible >strategy for picking a newer tag, with the added complexity that it >doesn't match the order of ports' versions. This also raises the >question: do we want to keep the both versions tied together? > > 2. For VictoriaMetrics, I wanted to stick to LTS releases, as they are >supported for 1y which gives enough coverage for OpenBSD release >cycle of roughly 6 months. I'm chceking now, latest LTS release is >1.97.3, but 1.97.1 is the last one to include non-enterprise tarballs >(doesn't really matter as we build from the GitHub-generated tarball >for the tag--their release are the built artifacts) which makes me >doubt seriously about how much I understand of their releases. >, I believe that it would be nice sticking with LTS, what do >you think? > > My positions here would be: > > 1. Make VictoriaLogs a different package. A bit wasteful, but the reality >is that the tags differ. > > 2. Stick with LTS. > Thank you for your input. I'll go back to the workbench :) Denis
