Re: [new] gurk-rs - a cli signal client
On 2023/02/17 08:13, Stefan Hagen wrote:
> Marcus MERIGHI wrote (2023-02-11 17:14 CET):
> > sh+openbsd-po...@codevoid.de (Stefan Hagen), 2023.02.10 (Fri) 19:28 (CET):
> > > here is a command line signal client. It's lacking a lot of features,
> > > but basic text send/receive functionality is there.
> >
> > for me the client quits upon receiving messages, reliably.
> >
> > 2023-02-11T15:50:33.433155Z ERROR panic: thread 'main' panicked at
> > 'called `Result::unwrap()` on an `Err` value: Error { kind:
> > Uncategorized, message: "no current exe available (short)" }':
> > /usr/ports/pobj/gurk-rs-0.3.0/gurk-rs-0.3.0/modcargo-crates/ \
> > notify-rust-4.5.10/src/notification.rs:23
>
> Oh, that's unfortunate and it's keeping me from going forward. I know it
> works for me and kn@ had some success. But I also don't want to import
> something that only works for half of the people. Missing features are
> fine, but it shouldn't break like that.
Does it work if you use the full path when running the binary?
> > Regarding
> > Signal Messenger client for the terminal written in Rust.
> >
> > While beeing completely right it does not tell that it is a Text User
> > Interface (TUI). Maybe steeli^Wtaking a bit from tut(1)'s description?
> >
> > So
> > TUI for Mastodon with vim inspired keys
> > becomes
> > Signal Messenger client TUI with strange key bindings
>
> Ironically, I find "for the terminal" clearer than TUI.
me too.
Re: games/love: bring in multiple versions
On 2023/02/13 12:59:50 -0500, Thomas Frohwein wrote: > On Mon, Feb 13, 2023 at 11:17:05AM +0100, Omar Polo wrote: > > On 2023/02/12 15:26:01 -0500, Thomas Frohwein > > wrote> > > A few WANTLIB seem to be missing for love 0.8: > > > > > > $ make port-lib-depends-check > > > > > > love-0.8.0p14(games/love/0.8): > > > Missing: Xau.10 (/usr/local/bin/love-0.8.0) (system lib) > > > Missing: Xdmcp.11 (/usr/local/bin/love-0.8.0) (system lib) > > > Missing: xcb-shm.1 (/usr/local/bin/love-0.8.0) (system lib) > > > Extra: Xdamage.4 > > > WANTLIB += Xau Xdmcp xcb-shm > > > *** Error 1 in target 'port-lib-depends-check' (ignored) fixed thanks to sysclean; it was due to some outdated crap I still had left around in this machine. retested everything, still works. attaching a fixed tarball. love.tar.gz Description: GNU Zip compressed data
Re: new: multimedia/karlyriceditor: synchronize music lyrics editor
On 2023/02/11 10:48:00 +, Yifei Zhan wrote:
>
> (manual bump of [1], used it today on -current, works fine as usual)
>
> Attached is a port for multimedia/karlyriceditor:
>
> Karaoke Lyrics Editor is a program lets you edit and synchronize lyrics with
> karaoke songs in various formats. Currently supported formats include LRC,
> LRCv2 (supported by XBMC) and Ultrastar (without pitch).
>
> Tested on OpenBSD-current/{amd64,arm64}, I've used it to edit lyrics for a
> few
> months now, no problem so far.
>
> port-lib-depends-check and portcheck are happy.
>
> any comments?
plist needs to be re-generated, share/applications is owned by
desktop-file-utils:
% diff -u pkg/PLIST{.orig,}
--- pkg/PLIST.orig Mon Jan 9 06:18:15 2023
+++ pkg/PLIST Fri Feb 17 10:58:04 2023
@@ -1,5 +1,4 @@
@bin bin/karlyriceditor
-share/applications/
share/applications/karlyriceditor.desktop
share/pixmaps/
share/pixmaps/karlyriceditor.png
I'd avoid the comments in do-install, it's juite clear what you're
doing, but it's just a matter of personal style.
not really runtested, I just opened the GUI and clicked around, but
seems to work and ports looks fine to me. With plist fixed, ok op@
for import if someone wants to :)
[update] graphics/pinta
Update pinta to the last release with GTK+2, futher updates depend on
GTK+3/.NET 6.
Release notes are at https://www.pinta-project.com/releases/1-7-1
briefly tested on arm64
OK?
Index: graphics/pinta/Makefile
===
RCS file: /cvs/openbsd/ports/graphics/pinta/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- graphics/pinta/Makefile 11 Mar 2022 19:23:10 - 1.16
+++ graphics/pinta/Makefile 17 Feb 2023 12:52:28 -
@@ -1,4 +1,5 @@
-V =1.7
+# V > 2.0 changes deps to gtk3 and .NET 6
+V =1.7.1
COMMENT = open source drawing/editing program modeled after Paint.NET
DISTNAME = pinta-${V}
CATEGORIES = graphics x11
Index: graphics/pinta/distinfo
===
RCS file: /cvs/openbsd/ports/graphics/pinta/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- graphics/pinta/distinfo 31 Oct 2021 20:30:03 - 1.2
+++ graphics/pinta/distinfo 17 Feb 2023 12:47:49 -
@@ -1,2 +1,2 @@
-SHA256 (pinta-1.7.tar.gz) = Z4wNXG5B2ndpYYDvxxR2zP2jI4o9aNczEZjIpDHb+Ww=
-SIZE (pinta-1.7.tar.gz) = 1677736
+SHA256 (pinta-1.7.1.tar.gz) = zbu/4kG4/l86HQsW5zEVEl4mSpyU0l/Oni/PQ0Ke+rk=
+SIZE (pinta-1.7.1.tar.gz) = 1703467
Index: graphics/pinta/pkg/PLIST
===
RCS file: /cvs/openbsd/ports/graphics/pinta/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 PLIST
--- graphics/pinta/pkg/PLIST11 Mar 2022 19:23:10 - 1.5
+++ graphics/pinta/pkg/PLIST17 Feb 2023 12:59:45 -
@@ -9,8 +9,6 @@ lib/pinta/Pinta.Tools.dll
lib/pinta/Pinta.exe
lib/pkgconfig/pinta.pc
@man man/man1/pinta.1
-share/appdata/
-share/appdata/pinta.appdata.xml
share/applications/pinta.desktop
share/icons/hicolor/16x16/apps/pinta.png
share/icons/hicolor/22x22/apps/pinta.png
--
Fourth Law of Revision:
It is usually impractical to worry beforehand about
interferences -- if you have none, someone will make
one for you.
[arm64 fix] emulators/citra
Here's a fix so citra works on arm64. Briefly tested on my arm64
thinkpad x13s, runs and passes tests.
OK?
Index: emulators/citra/Makefile
===
RCS file: /cvs/openbsd/ports/emulators/citra/Makefile,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 Makefile
--- emulators/citra/Makefile22 Jan 2023 15:23:57 - 1.21
+++ emulators/citra/Makefile17 Feb 2023 13:34:12 -
@@ -10,6 +10,7 @@ COMMENT = nintendo 3DS emulator
DISTNAME = citra-unified-source-20230110-ad2cbe2
V =1827
PKGNAME = citra-0.0.0.${V}
+REVISION = 0
CATEGORIES = emulators
@@ -62,6 +63,12 @@ CXXFLAGS += -I${LOCALBASE}/include -I${L
post-extract:
rm -rf ${WRKSRC}/externals/{sdl2,catch2,fmt,boost,cryptopp}
+
+.if ${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == i386
+PKG_ARGS +=-Dx86=1
+.else
+PKG_ARGS +=-Dx86=0
+.endif
.include
Index: emulators/citra/patches/patch-src_common_aarch64_cpu_detect_cpp
===
RCS file: emulators/citra/patches/patch-src_common_aarch64_cpu_detect_cpp
diff -N emulators/citra/patches/patch-src_common_aarch64_cpu_detect_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ emulators/citra/patches/patch-src_common_aarch64_cpu_detect_cpp 17 Feb
2023 12:10:39 -
@@ -0,0 +1,62 @@
+Index: src/common/aarch64/cpu_detect.cpp
+--- src/common/aarch64/cpu_detect.cpp.orig
src/common/aarch64/cpu_detect.cpp
+@@ -14,13 +14,17 @@
+ #include
+ #include
+ // clang-format on
+-#elif !defined(_WIN32)
++#elif !defined(_WIN32) && !defined(__OpenBSD__)
+ #ifndef __FreeBSD__
+ #include
+ #endif // __FreeBSD__
+ #include
+ #include
+ #endif // __APPLE__
++#ifdef __OpenBSD__
++#include
++#include /* CPU_ID_AA64ISAR0 */
++#endif // __OpenBSD__
+
+ #include "common/aarch64/cpu_detect.h"
+ #include "common/file_util.h"
+@@ -36,6 +40,10 @@ static std::string GetCPUString() {
+ }
+ return buf;
+ }
++#elif defined(__OpenBSD__)
++static std::string GetCPUString() {
++return "Unknown";
++}
+ #elif !defined(WIN32)
+ static std::string GetCPUString() {
+ constexpr char procfile[] = "/proc/cpuinfo";
+@@ -76,6 +84,28 @@ static CPUCaps Detect() {
+ caps.sha1 = true;
+ caps.sha2 = true;
+ caps.cpu_string = GetCPUString();
++#elif defined(__OpenBSD__)
++int isar0_mib[] = { CTL_MACHDEP, CPU_ID_AA64ISAR0 };
++size_t len = sizeof(uint64_t);
++uint64_t cpu_id = 0;
++
++caps.fp = true;
++caps.cpu_string = GetCPUString();
++
++if (sysctl(isar0_mib, 2, &cpu_id, &len, NULL, 0) != 1) {
++#define AA64ISA_AES (0x3 << 4)
++#define AA64ISA_SHA1 (0x1 << 8)
++#define AA64ISA_SHA2 (0x3 << 12)
++#define AA64ISA_CRC32 (0x1 << 16)
++
++caps.fp = true;
++caps.asimd = false; // XXX
++caps.aes = cpu_id & AA64ISA_AES;
++caps.crc32 = cpu_id & AA64ISA_CRC32;
++caps.sha1 = cpu_id & AA64ISA_SHA1;
++caps.sha2 = cpu_id & AA64ISA_SHA2;
++
++}
+ #elif defined(_WIN32)
+ // Windows does not provide any mechanism for querying the system
registers on ARMv8, unlike
+ // Linux which traps the register reads and emulates them in the kernel.
There are environment
Index: emulators/citra/pkg/PFRAG.x86
===
RCS file: emulators/citra/pkg/PFRAG.x86
diff -N emulators/citra/pkg/PFRAG.x86
--- /dev/null 1 Jan 1970 00:00:00 -
+++ emulators/citra/pkg/PFRAG.x86 17 Feb 2023 13:30:52 -
@@ -0,0 +1,9 @@
+include/xbyak/
+include/xbyak/xbyak.h
+include/xbyak/xbyak_bin2hex.h
+include/xbyak/xbyak_mnemonic.h
+include/xbyak/xbyak_util.h
+lib/cmake/xbyak/
+lib/cmake/xbyak/xbyak-config-version.cmake
+lib/cmake/xbyak/xbyak-config.cmake
+lib/cmake/xbyak/xbyak-targets.cmake
Index: emulators/citra/pkg/PLIST
===
RCS file: /cvs/openbsd/ports/emulators/citra/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- emulators/citra/pkg/PLIST 22 Jan 2023 15:23:58 - 1.6
+++ emulators/citra/pkg/PLIST 17 Feb 2023 13:29:53 -
@@ -1,3 +1,4 @@
+%%x86%%
@bin bin/citra
@bin bin/citra-qt
@bin bin/citra-room
@@ -152,20 +153,11 @@ include/dynarmic/ir/opt/passes.h
include/dynarmic/ir/terminal.h
include/dynarmic/ir/type.h
include/dynarmic/ir/value.h
-include/xbyak/
-include/xbyak/xbyak.h
-include/xbyak/xbyak_bin2hex.h
-include/xbyak/xbyak_mnemonic.h
-include/xbyak/xbyak_util.h
lib/cmake/dynarmic/
lib/cmake/dynarmic/dynarmicConfig.cmake
lib/cmake/dynarmic/dynarmicConfigVersion.cmake
lib/cmake/dynarmic/dynarmicTargets${MODCMAKE_BUILD_SUFFIX}
lib/cmake/dynarmic/dynarmicTargets.cmake
-lib/cmake/xbyak/
-lib/cmake/xbyak/xbyak-config-version.cmake
-lib/cmake/xbyak/xbyak-config.cmake
-lib/cmake/xbyak/xbyak-targets.cmake
@static-lib lib/libdynarmic.a
@man man/man6/citra-qt.6
@man man/man6/citra.6
--
Murphy's Law is recursive. Wa
Re: [new] gurk-rs - a cli signal client
Hello,
s...@spacehopper.org (Stuart Henderson), 2023.02.17 (Fri) 10:50 (CET):
> On 2023/02/17 08:13, Stefan Hagen wrote:
> > Marcus MERIGHI wrote (2023-02-11 17:14 CET):
> > > sh+openbsd-po...@codevoid.de (Stefan Hagen), 2023.02.10 (Fri) 19:28 (CET):
> > > > here is a command line signal client. It's lacking a lot of features,
> > > > but basic text send/receive functionality is there.
> > >
> > > for me the client quits upon receiving messages, reliably.
> > >
> > > 2023-02-11T15:50:33.433155Z ERROR panic: thread 'main' panicked at
> > > 'called `Result::unwrap()` on an `Err` value: Error { kind:
> > > Uncategorized, message: "no current exe available (short)" }':
> > > /usr/ports/pobj/gurk-rs-0.3.0/gurk-rs-0.3.0/modcargo-crates/ \
> > > notify-rust-4.5.10/src/notification.rs:23
> >
> > Oh, that's unfortunate and it's keeping me from going forward. I know it
> > works for me and kn@ had some success. But I also don't want to import
> > something that only works for half of the people. Missing features are
> > fine, but it shouldn't break like that.
>
> Does it work if you use the full path when running the binary?
Yes, it does! Tried multiple times.
I receive messages and the chats that I've been part of since linking to
the phone have popped up, nice.
> > > Regarding
> > > Signal Messenger client for the terminal written in Rust.
> > >
> > > While beeing completely right it does not tell that it is a Text User
> > > Interface (TUI). Maybe steeli^Wtaking a bit from tut(1)'s description?
> > >
> > > So
> > > TUI for Mastodon with vim inspired keys
> > > becomes
> > > Signal Messenger client TUI with strange key bindings
> >
> > Ironically, I find "for the terminal" clearer than TUI.
>
> me too.
To me there's two types of user interfaces "for the terminal".
Command line, based on stdin/stdout/stderr, like wc(1).
Or an program that is started from the command line but its user
interface is not based on stdin/stdout/stderr, like mutt.
"for the terminal" does not tell which one of these it is.
Am I getting it wrong? In what way?
Marcus
[update] i2pd-2.46.0
Hi, Here are patches updating net/i2pd to the latest version (2.46.0), one for -current and one for -stable. The I2P network suffers from ongoing Denial of Service attacks [1]. i2pd was severely affected - more than the java i2p implementation - to the point of becoming almost unusable. This update contains mitigations against these attacks. With the attached patches, i2pd builds on amd64, 'make test' is passing, albeit with warnings, and 'make port-lib-depends-check' is OK. I'm running the port on -stable for more than 24 hours now, and it's doing great (with a Tunnel creation success rate of more than 40%, which is very good). I'm submitting a patch for -stable because at this point the version on -stable (2.41.0) has become basically useless. I've taken the liberty to remove the MAINTAINER line in these patches, since the maintainer seems to have totally disappeared for several months, and their email account has been deactivated. Best regards, Ganymede [1] See https://geti2p.net/en/blog/post/2023/02/09/about_the_recent_denial_of_service_attacks and https://www.reddit.com/r/i2p/comments/10v9uxp/network_weather_report_stormyIndex: Makefile === RCS file: /cvs/ports/net/i2pd/Makefile,v retrieving revision 1.15 diff -u -p -r1.15 Makefile --- Makefile 14 Jan 2023 22:07:59 - 1.15 +++ Makefile 16 Feb 2023 01:50:25 - @@ -2,12 +2,10 @@ COMMENT = client for the I2P anonymous n GH_ACCOUNT = PurpleI2P GH_PROJECT = i2pd -GH_TAGNAME = 2.45.1 +GH_TAGNAME = 2.46.0 CATEGORIES = net HOMEPAGE = https://i2pd.website - -MAINTAINER = Dimitri Karamazov # BSD PERMIT_PACKAGE = Yes Index: distinfo === RCS file: /cvs/ports/net/i2pd/distinfo,v retrieving revision 1.10 diff -u -p -r1.10 distinfo --- distinfo 14 Jan 2023 22:07:59 - 1.10 +++ distinfo 16 Feb 2023 01:50:25 - @@ -1,2 +1,2 @@ -SHA256 (i2pd-2.45.1.tar.gz) = qEsePLWsRfOa+Y5jKR00cl72czfhGsvg4kWs3npbK3I= -SIZE (i2pd-2.45.1.tar.gz) = 631280 +SHA256 (i2pd-2.46.0.tar.gz) = 2qXke7K4D72qODayCehpAXiTQh9SJd/gGeXUPT+KhtQ= +SIZE (i2pd-2.46.0.tar.gz) = 643087 Index: patches/patch-tests_Makefile === RCS file: /cvs/ports/net/i2pd/patches/patch-tests_Makefile,v retrieving revision 1.7 diff -u -p -r1.7 patch-tests_Makefile --- patches/patch-tests_Makefile 8 Jan 2023 21:29:06 - 1.7 +++ patches/patch-tests_Makefile 16 Feb 2023 01:50:25 - @@ -1,39 +1,12 @@ Index: tests/Makefile --- tests/Makefile.orig +++ tests/Makefile -@@ -1,5 +1,5 @@ - CXXFLAGS += -Wall -Wno-unused-parameter -Wextra -pedantic -O0 -g -std=c++11 -D_GLIBCXX_USE_NANOSLEEP=1 -pthread -Wl,--unresolved-symbols=ignore-in-object-files +@@ -1,7 +1,7 @@ + SYS := $(shell $(CXX) -dumpmachine) + + CXXFLAGS += -Wall -Wno-unused-parameter -Wextra -pedantic -O0 -g -std=c++11 -D_GLIBCXX_USE_NANOSLEEP=1 -DOPENSSL_SUPPRESS_DEPRECATED -pthread -Wl,--unresolved-symbols=ignore-in-object-files -INCFLAGS += -I../libi2pd +CXXFLAGS += -Wall -Wextra -pedantic -g -std=c++11 -D_GLIBCXX_USE_NANOSLEEP=1 -I../libi2pd/ -pthread -Wl,--unresolved-symbols=ignore-in-object-files - TESTS = test-gost test-gost-sig test-base-64 test-x25519 test-aeadchacha20poly1305 test-blinding test-elligator - -@@ -14,8 +14,8 @@ test-base-%: ../libi2pd/Base.cpp test-base-%.cpp - test-gost: ../libi2pd/Gost.cpp ../libi2pd/I2PEndian.cpp test-gost.cpp - $(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto - --test-gost-sig: ../libi2pd/Gost.cpp ../libi2pd/I2PEndian.cpp ../libi2pd/Crypto.cpp ../libi2pd/Log.cpp test-gost-sig.cpp -- $(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto -lssl -lboost_system -+test-gost-sig: ../libi2pd/Gost.cpp ../libi2pd/Config.cpp ../libi2pd/I2PEndian.cpp ../libi2pd/Crypto.cpp ../libi2pd/Log.cpp test-gost-sig.cpp -+ $(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto -lssl -lboost_system -lboost_program_options-mt - - test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndian.cpp ../libi2pd/Log.cpp ../libi2pd/Crypto.cpp test-x25519.cpp - $(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto -lssl -lboost_system -@@ -23,14 +23,14 @@ test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndi - test-aeadchacha20poly1305: ../libi2pd/Crypto.cpp ../libi2pd/ChaCha20.cpp ../libi2pd/Poly1305.cpp test-aeadchacha20poly1305.cpp - $(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto -lssl -lboost_system - --test-blinding: ../libi2pd/Crypto.cpp ../libi2pd/Blinding.cpp ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndian.cpp ../libi2pd/Log.cpp ../libi2pd/util.cpp ../libi2pd/Identity.cpp ../libi2pd/Signature.cpp ../libi2pd/Timestamp.cpp test-blinding.cpp -- $(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto -lssl -lboost_system -+test-blinding: ../libi2pd/Crypto.cpp ../libi2pd/Config.cpp ../libi2pd/Blinding.cpp ../libi2pd/
[UPDATE/SECURITY] lang/node 18.14.1
nodejs published a security release yesterday.
The fixes relevant for the OpenBSD port are:
* Node.js Permissions policies can be bypassed via process.mainModule
(High) (CVE-2023-23918)
* Node.js OpenSSL error handling issues in nodejs crypto library
(Medium) (CVE-2023-23919)
* Fetch API in Node.js did not protect against CRLF injection in host
headers (Medium) (CVE-2023-23936)
* Regular Expression Denial of Service in Headers in Node.js fetch
API(Low) (CVE-2023-24807)
Note: It might be a good idea to have a look at whether it makes sense
to apply the equivalent of
https://github.com/nodejs/node/commit/8393ebc72d to textproc/icu4c (Cc:
Maintainer aja@)
The effective changes vs. v18.14.0 are mostly in javascript code (except
for https://github.com/nodejs/node/commit/004e34d046) and as far as I
can see, have no potential to break on other platforms - Therefore only
built and tested on amd64; v18.14.0 has been tested on i386 and arm64 as
well.
On 2/16/23 21:47, A Tammy wrote:
On 2/12/23 09:02, Volker Schlecht wrote:
ping
On 2/5/23 14:17, Volker Schlecht wrote:
Update lang/node to 18.14.0
* reinstate old patch to disable building the bundled googletest,
because that could lead to build-time conflicts when devel/gtest is
installed, now that the version of devel/gtest has diverged from the
bundled version again
* This fixes a build issue on riscv64 that slipped into v18.13.0
https://github.com/nodejs/node/commit/1e11247b91
* PLIST churn due to updated npm
Built and tested on amd64, i386 and arm64; riscv64 is very likely to
work now as well ...
builds and works for me on amd64, ok aisha@
don't have any other arch around so can't test. Anyone wants to weigh in?
Aisha
Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.116
diff -u -p -r1.116 Makefile
--- Makefile 28 Jan 2023 12:46:46 - 1.116
+++ Makefile 17 Feb 2023 11:46:09 -
@@ -5,12 +5,11 @@ USE_WXNEEDED = Yes
COMMENT = JavaScript runtime built on Chrome's V8 JavaScript engine
-NODE_VERSION = v18.12.1
+NODE_VERSION = v18.14.1
PLEDGE_VER = 1.1.3
DISTFILES = node-pledge-{}${PLEDGE_VER}.tar.gz:0 \
${DISTNAME}-headers.tar.gz \
${DISTNAME}.tar.xz
-REVISION = 2
DISTNAME = node-${NODE_VERSION}
PKGNAME = ${DISTNAME:S/v//g}
Index: distinfo
===
RCS file: /cvs/ports/lang/node/distinfo,v
retrieving revision 1.66
diff -u -p -r1.66 distinfo
--- distinfo 29 Dec 2022 23:34:13 - 1.66
+++ distinfo 17 Feb 2023 11:46:09 -
@@ -1,6 +1,6 @@
SHA256 (node-pledge-1.1.3.tar.gz) = fEaXvLg6hYEJ69K+mgQFizf8DiJY2/DtyFJB/pEanVU=
-SHA256 (node-v18.12.1-headers.tar.gz) = nVXuByum1aFB2wks7xoPcV99P8k4KFptknodCgx0Qvc=
-SHA256 (node-v18.12.1.tar.xz) = T6QGRRvFJlmikOUs/bIWKnYL1UnaS4u+vmop8pbZON8=
+SHA256 (node-v18.14.1-headers.tar.gz) = kYs1rpQ/zRuzrVkM638EQYgezfWUCiA55PtXYsQEgNI=
+SHA256 (node-v18.14.1.tar.xz) = 7sNTQ4Jm/QrvU6lEa+ELMu5udNCOMt1UVLOC/2eT2gQ=
SIZE (node-pledge-1.1.3.tar.gz) = 3167
-SIZE (node-v18.12.1-headers.tar.gz) = 8563785
-SIZE (node-v18.12.1.tar.xz) = 38454588
+SIZE (node-v18.14.1-headers.tar.gz) = 8568128
+SIZE (node-v18.14.1.tar.xz) = 41439328
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/lang/node/patches/patch-Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 patch-Makefile
--- patches/patch-Makefile 29 Dec 2022 23:34:13 - 1.16
+++ patches/patch-Makefile 17 Feb 2023 11:46:09 -
@@ -1,7 +1,7 @@
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -185,7 +185,7 @@ config.gypi: configure configure.py src/node_version.h
+@@ -186,7 +186,7 @@ config.gypi: configure configure.py src/node_version.h
fi
.PHONY: install
@@ -10,7 +10,7 @@ Index: Makefile
$(PYTHON) tools/install.py $@ '$(DESTDIR)' '$(PREFIX)'
.PHONY: uninstall
-@@ -416,6 +416,12 @@ test/addons/.buildstamp: $(ADDONS_PREREQS) \
+@@ -417,6 +417,12 @@ test/addons/.buildstamp: $(ADDONS_PREREQS) \
# Just goes to show that recursive make really is harmful...
# TODO(bnoordhuis) Force rebuild after gyp update.
build-addons: | $(NODE_EXE) test/addons/.buildstamp
Index: patches/patch-common_gypi
===
RCS file: /cvs/ports/lang/node/patches/patch-common_gypi,v
retrieving revision 1.24
diff -u -p -r1.24 patch-common_gypi
--- patches/patch-common_gypi 29 Dec 2022 23:34:13 - 1.24
+++ patches/patch-common_gypi 17 Feb 2023 11:46:09 -
@@ -9,7 +9,7 @@ Index: common.gypi
'conditions': [
['enable_lto=="true"', {
'cflags': ['<(lto)'],
-@@ -413,7 +412,9 @@
+@@ -409,7 +408,9 @@
}],
['OS=="openbsd"', {
'cflags': [ '-I/usr/local/include' ],
Index: patches/patch-configure
===
RCS file: /cvs/ports/lang/nod
Re: [UPDATE/SECURITY] lang/node 18.14.1
On Fri, Feb 17, 2023 at 04:07:36PM +0100, Volker Schlecht wrote: > nodejs published a security release yesterday. Thanks. I'm currently running 18.14.0 through an amd64 bulk. I will commit 18.4.1 once that's completed, i.e. on Sunday.
Re: [UPDATE/SECURITY] lang/node 18.14.1
On Fri, Feb 17, 2023 at 04:07:36PM +0100, Volker Schlecht wrote: > nodejs published a security release yesterday. > > The fixes relevant for the OpenBSD port are: > > * Node.js Permissions policies can be bypassed via process.mainModule (High) > (CVE-2023-23918) > * Node.js OpenSSL error handling issues in nodejs crypto library (Medium) > (CVE-2023-23919) > * Fetch API in Node.js did not protect against CRLF injection in host > headers (Medium) (CVE-2023-23936) > * Regular Expression Denial of Service in Headers in Node.js fetch API(Low) > (CVE-2023-24807) > > Note: It might be a good idea to have a look at whether it makes sense to > apply the equivalent of https://github.com/nodejs/node/commit/8393ebc72d to > textproc/icu4c (Cc: Maintainer aja@) Look at the port, it's already the case.
Re: [UPDATE/SECURITY] lang/node 18.14.1
On 2/17/23 16:17, Antoine Jacoutot wrote: Note: It might be a good idea to have a look at whether it makes sense to apply the equivalent of https://github.com/nodejs/node/commit/8393ebc72d to textproc/icu4c (Cc: Maintainer aja@) Look at the port, it's already the case. Ack ... I did look, but missed it. Sorry.
Re: [new] gurk-rs - a cli signal client
On Fri, Feb 17, 2023 at 8:52 AM Marcus MERIGHI wrote:
>
> Hello,
>
> s...@spacehopper.org (Stuart Henderson), 2023.02.17 (Fri) 10:50 (CET):
> > On 2023/02/17 08:13, Stefan Hagen wrote:
> > > Marcus MERIGHI wrote (2023-02-11 17:14 CET):
> > > > sh+openbsd-po...@codevoid.de (Stefan Hagen), 2023.02.10 (Fri) 19:28
> > > > (CET):
> > > > > here is a command line signal client. It's lacking a lot of features,
> > > > > but basic text send/receive functionality is there.
> > > >
> > > > for me the client quits upon receiving messages, reliably.
> > > >
> > > > 2023-02-11T15:50:33.433155Z ERROR panic: thread 'main' panicked at
> > > > 'called `Result::unwrap()` on an `Err` value: Error { kind:
> > > > Uncategorized, message: "no current exe available (short)" }':
> > > > /usr/ports/pobj/gurk-rs-0.3.0/gurk-rs-0.3.0/modcargo-crates/ \
> > > > notify-rust-4.5.10/src/notification.rs:23
> > >
> > > Oh, that's unfortunate and it's keeping me from going forward. I know it
> > > works for me and kn@ had some success. But I also don't want to import
> > > something that only works for half of the people. Missing features are
> > > fine, but it shouldn't break like that.
> >
> > Does it work if you use the full path when running the binary?
>
> Yes, it does! Tried multiple times.
>
> I receive messages and the chats that I've been part of since linking to
> the phone have popped up, nice.
>
> > > > Regarding
> > > > Signal Messenger client for the terminal written in Rust.
> > > >
> > > > While beeing completely right it does not tell that it is a Text User
> > > > Interface (TUI). Maybe steeli^Wtaking a bit from tut(1)'s description?
> > > >
> > > > So
> > > > TUI for Mastodon with vim inspired keys
> > > > becomes
> > > > Signal Messenger client TUI with strange key bindings
> > >
> > > Ironically, I find "for the terminal" clearer than TUI.
> >
> > me too.
>
> To me there's two types of user interfaces "for the terminal".
>
> Command line, based on stdin/stdout/stderr, like wc(1).
>
> Or an program that is started from the command line but its user
> interface is not based on stdin/stdout/stderr, like mutt.
>
> "for the terminal" does not tell which one of these it is.
>
> Am I getting it wrong? In what way?
I don't think you're wrong, it just seems like "for the terminal" is a
more likely search term. For example, a quick search of -current
package descriptions finds 492 for "command line", 197 for "terminal",
and 3 for "TUI".
Morgan Aldridge
[proposal] set curl as default download method
Cc: Maintainer
Currently math/rstudio always reports
"Unable to set a secure (HTTPS) download.file.method (no compatible
method available in this installation of R)."
at startup, which based on a sample size of one (me), may be confusing
to users and take quite a while to track down.
The attached patch
* adds a RUN_DEPENDS on net/curl
* adds a patch for RStudio to default to curl as default download method
for OpenBSD, just as for Darwin and Linux.
With that in place, installing packages from a https CRAN mirror works
nicely for me.Index: Makefile
===
RCS file: /cvs/ports/math/rstudio/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 3 Aug 2022 15:13:25 - 1.11
+++ Makefile 17 Feb 2023 21:46:55 -
@@ -10,7 +10,7 @@ ONLY_FOR_ARCHS = ${LP64_ARCHS}
V = 1.3.959
COMMENT = Integrated Development Environment (IDE) for R
PKGNAME = rstudio-${V}
-REVISION = 7
+REVISION = 8
CATEGORIES = math x11
HOMEPAGE = https://www.rstudio.com/
@@ -62,8 +62,9 @@ LIB_DEPENDS = devel/boost \
RUN_DEPENDS = devel/desktop-file-utils \
misc/shared-mime-info \
- x11/gtk+3,-guic
-
+ x11/gtk+3,-guic \
+ net/curl
+
CONFIGURE_ARGS = -DBoost_INCLUDE_DIR="${LOCALBASE}/include" \
-DQT_QMAKE_EXECUTABLE="${LOCALBASE}/bin/qmake-qt5" \
-DQt5WebEngine_DIR="${LOCALBASE}/lib/qt5/cmake/Qt5WebEngine" \
Index: patches/patch-src_cpp_session_modules_SessionPackages_R
===
RCS file: patches/patch-src_cpp_session_modules_SessionPackages_R
diff -N patches/patch-src_cpp_session_modules_SessionPackages_R
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_cpp_session_modules_SessionPackages_R 17 Feb 2023 21:46:55 -
@@ -0,0 +1,16 @@
+Index: src/cpp/session/modules/SessionPackages.R
+--- src/cpp/session/modules/SessionPackages.R.orig
src/cpp/session/modules/SessionPackages.R
+@@ -1252,7 +1252,11 @@ if (identical(as.character(Sys.info()["sysname"]), "Da
+else if (identical(sysName, "Darwin")) {
+ posixMethod("curl")
+}
+-
++
++ else if (identical(sysName, "OpenBSD")) {
++ posixMethod("curl")
++ }
++
+else if (identical(sysName, "Linux")) {
+ method <- posixMethod("wget")
+ if (!nzchar(method))
Re: [new] gurk-rs - a cli signal client
On 2023/02/17 14:51, Marcus MERIGHI wrote:
> Hello,
>
> s...@spacehopper.org (Stuart Henderson), 2023.02.17 (Fri) 10:50 (CET):
> > On 2023/02/17 08:13, Stefan Hagen wrote:
> > > Marcus MERIGHI wrote (2023-02-11 17:14 CET):
> > > > sh+openbsd-po...@codevoid.de (Stefan Hagen), 2023.02.10 (Fri) 19:28
> > > > (CET):
> > > > > here is a command line signal client. It's lacking a lot of features,
> > > > > but basic text send/receive functionality is there.
> > > >
> > > > for me the client quits upon receiving messages, reliably.
> > > >
> > > > 2023-02-11T15:50:33.433155Z ERROR panic: thread 'main' panicked at
> > > > 'called `Result::unwrap()` on an `Err` value: Error { kind:
> > > > Uncategorized, message: "no current exe available (short)" }':
> > > > /usr/ports/pobj/gurk-rs-0.3.0/gurk-rs-0.3.0/modcargo-crates/ \
> > > > notify-rust-4.5.10/src/notification.rs:23
> > >
> > > Oh, that's unfortunate and it's keeping me from going forward. I know it
> > > works for me and kn@ had some success. But I also don't want to import
> > > something that only works for half of the people. Missing features are
> > > fine, but it shouldn't break like that.
> >
> > Does it work if you use the full path when running the binary?
>
> Yes, it does! Tried multiple times.
>
> I receive messages and the chats that I've been part of since linking to
> the phone have popped up, nice.
So this is one of those programs which wants to know which path you used
to run it, which is a standard library feature provided in some of the
newer languages and is available in some OS (it's not possible to
guarantee that the file reachable at that path is still the same, or
even exists at all, but for the purppses of what the software wants
that's good enough).
Here it wants to yse it to set the application name and icon in desktop
notifications.
OpenBSD doesn't have a way to do this at all unless it can retrieve
the full path from argv (sshd needs similar for reloading).
As far as software in ports goes, it probably makes sense to patch to
use the location where the package installs the binary - in this case
it's in "notify-rust", so it would probably make sense to patch
that (look for "current_exe" to use a hardcoded path string instead.
> > > > Regarding
> > > > Signal Messenger client for the terminal written in Rust.
> > > >
> > > > While beeing completely right it does not tell that it is a Text User
> > > > Interface (TUI). Maybe steeli^Wtaking a bit from tut(1)'s description?
> > > >
> > > > So
> > > > TUI for Mastodon with vim inspired keys
> > > > becomes
> > > > Signal Messenger client TUI with strange key bindings
> > >
> > > Ironically, I find "for the terminal" clearer than TUI.
> >
> > me too.
>
> To me there's two types of user interfaces "for the terminal".
>
> Command line, based on stdin/stdout/stderr, like wc(1).
>
> Or an program that is started from the command line but its user
> interface is not based on stdin/stdout/stderr, like mutt.
>
> "for the terminal" does not tell which one of these it is.
>
> Am I getting it wrong? In what way?
We used to just say things like "curses UI" and everyone knew what it
meant, but since it doesn't actually use curses that seems wrong...
Personally I'd expect to see "command-line" if it's a command line
application and for most other wording that is obviously related to the
console rather than X or a daemon I'd expect some kind of (probably
full-screen) terminal ui.
Not that it matters all that much.
Re: amd64-clang bulk build report
Theo Buehler: > editors/axe imake [-Wint-conversion] > games/spider imake/X headers [-Wint-conversion] > games/xjewel imake [-Wint-conversion] > misc/xgas imake/X headers [-Wint-conversion] Fixed. -- Christian "naddy" Weisgerber na...@mips.inka.de
UPDATE: productivity/sl
I didn't even know this existed!
Use Tcl/Tk 8.6.
HOMEPAGE and MASTER_SITES no longer exist.
Take maintainership.
Ok?
Stu
Index: Makefile
===
RCS file: /cvs/ports/productivity/sl/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile11 Mar 2022 19:51:46 - 1.7
+++ Makefile18 Feb 2023 05:35:23 -
@@ -1,17 +1,15 @@
COMMENT = substantially more useful ls
+
DISTNAME = sl-ls-1.1.2
-REVISION = 1
+REVISION = 2
CATEGORIES = productivity sysutils
-
-HOMEPAGE = http://practicalthought.com/sl/
+MAINTAINER = Stuart Cassoff
# GPLv3
-PERMIT_PACKAGE = Yes
-
-MASTER_SITES = http://mirrors.nycbug.org/pub/distfiles/
-
-MODULES += lang/tcl
+PERMIT_PACKAGE =Yes
+MODULES = lang/tcl
+MODTCL_VERSION =8.6
RUN_DEPENDS = ${MODTCL_RUN_DEPENDS}
NO_BUILD = Yes
rm devel/p5-Alien-wxWidgets x11/p5-Wx textproc/chordpro
Hi. I would like to remove the following ports: * devel/p5-Alien-wxWidgets -> only needed by x11/p5-Wx * x11/p5-Wx -> BROKEN since 4+ years, unmaintained upstream * textproc/chordpro -> depends on x11/p5-Wx for its -wx subpackage We could always remove the -wx subpackage if prefered but the port could use a serious update. OK ? -- Antoine
Re: rm devel/p5-Alien-wxWidgets x11/p5-Wx textproc/chordpro
On Sat Feb 18, 2023 at 08:37:03AM +0100, Antoine Jacoutot wrote: > Hi. > > I would like to remove the following ports: > > * devel/p5-Alien-wxWidgets-> only needed by x11/p5-Wx > > * x11/p5-Wx -> BROKEN since 4+ years, unmaintained upstream > > * textproc/chordpro -> depends on x11/p5-Wx for its -wx subpackage > We could always remove the -wx subpackage if prefered but the port could use > a serious update. > > > OK ? > > > -- > Antoine > OK rsadowski if millert@ is ok with the chordpro-wx removal option.
