[Update] lang/node 18.13.0
Here's an update for everyone's favourite port. Nothing particularly
urgent or important about it, according to upstream's changelog.
Tested on amd64, arm64 and i386. Builds and runs fine on all three.
None of the riscv64 patches are affected by the update, but there's been
some renaming of riscv source folders going on, so giving it a spin
there first might be a good idea.
Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.113
diff -u -p -r1.113 Makefile
--- Makefile 4 Jan 2023 17:06:33 - 1.113
+++ Makefile 13 Jan 2023 20:18:15 -
@@ -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.13.0
PLEDGE_VER = 1.1.3
DISTFILES = node-pledge-{}${PLEDGE_VER}.tar.gz:0 \
${DISTNAME}-headers.tar.gz \
${DISTNAME}.tar.xz
-REVISION = 0
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 13 Jan 2023 20:18:15 -
@@ -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.13.0-headers.tar.gz) = ULb4336BfxOxxe/EIj/KK6QGY7uVMj/4azYka+lryc0=
+SHA256 (node-v18.13.0.tar.xz) = /UrFYuAdFyiW46lZvVlVLb9kczHJDXJvjTRxaD3T2mg=
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.13.0-headers.tar.gz) = 8565085
+SIZE (node-v18.13.0.tar.xz) = 40324048
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 13 Jan 2023 20:18:15 -
@@ -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/node/patches/patch-configure,v
retrieving revision 1.1
diff -u -p -r1.1 patch-configure
--- patches/patch-configure 23 Sep 2022 19:28:50 - 1.1
+++ patches/patch-configure 13 Jan 2023 20:18:15 -
@@ -1,10 +1,11 @@
Index: configure
--- configure.orig
+++ configure
-@@ -4,11 +4,6 @@
+@@ -4,12 +4,6 @@
# Note that the mix of single and double quotes is intentional,
# as is the fact that the ] goes on a new line.
_=[ 'exec' '/bin/sh' '-c' '''
+-command -v python3.11 >/dev/null && exec python3.11 "$0" "$@"
-command -v python3.10 >/dev/null && exec python3.10 "$0" "$@"
-command -v python3.9 >/dev/null && exec python3.9 "$0" "$@"
-command -v python3.8 >/dev/null && exec python3.8 "$0" "$@"
Index: patches/patch-lib_internal_modules_cjs_loader_js
===
RCS file: /cvs/ports/lang/node/patches/patch-lib_internal_modules_cjs_loader_js,v
retrieving revision 1.9
diff -u -p -r1.9 patch-lib_internal_modules_cjs_loader_js
--- patches/patch-lib_internal_modules_cjs_loader_js 29 Dec 2022 23:34:13 - 1.9
+++ patches/patch-lib_internal_modules_cjs_loader_js 13 Jan 2023 20:18:15 -
@@ -1,7 +1,7 @@
Index: lib/internal/modules/cjs/loader.js
--- lib/internal/modules/cjs/loader.js.orig
+++ lib/internal/modules/cjs/loader.js
-@@ -1294,7 +1294,10 @@ Module._initPaths = function() {
+@@ -1353,7 +1353,10 @@ Module._initPaths = function() {
path.resolve(process.execPath, '..') :
path.resolve(process.execPath, '..', '..');
Index: patches/patch-lib_net_js
===
RCS file: /cvs/ports/lang/node/patches/patch-lib_net_js,v
retrieving revision 1.6
diff -u -p -r1.6 patch-lib_net_js
--- patches/patch-lib_net_js 29 Dec 2022 23:34:13 - 1.6
+++ patches/patch-lib_net_js 13 Jan 2023 20:18:15 -
@@ -13,7 +13,7 @@ for "any address" but that's not really
Index: lib/net.js
--- lib/net.js.orig
+++ lib/net.js
-@@ -1447,22 +1447,12 @@ function setupListenHandle(address, port, addressType,
+@@ -1695,22 +1695,12 @@ function setupListenHandle(address, port, addressType,
let rval = null;
Index: patches/patch-node_gyp
===
RCS file: /cvs/ports/lang/node/patches/patch-node_gyp,v
retrieving revision 1.16
Re: [UPDATE] net/rabbitmq 3.10.13
bump On 12/30/22 21:04, Volker Schlecht wrote: Updates net/rabbitmq to the most recent 3.10.x release. * Reinstates patch-deps_rabbit_scripts_rabbitmq-defaults that shouldn't have been dropped * Drops patch-deps_rabbitmq_cli_mix_exs that is now upstreamed * Substitutes versions of bundled dependencies to avoid PLIST churn further down the line (adding lots of PLIST churn now...) * Prevents epmd from being started as root, albeit in a very ugly way: While rabbitmq.rc always started the rabbitmq launch script as _rabbitmq, it contained a call to rabbitmqctl in rc_check(). rabbitmqctl always starts an instance of epmd if none is running, and since the first call to rc_check() is run by root, it always launches epmd as root. Besides having a server running with root privileges now, this leads to the problem that the first startup might fail because /var/rabbitmq/.erlang.cookie is now owned by root and not accessible by _rabbitmq anymore. What I'm proposing now is to use a pexp in rabbitmq.rc for rc_check(). Given rabbitmq's giant invocation of erl25, the pattern I'm looking for might be a little flaky, but it's the best working idea I could come up with so far - better solutions are highly welcome, as is of course any other feedback.
Re: [update] devel/rebar3 3.20.0
bump On 1/5/23 16:12, Volker Schlecht wrote: bump On 12/29/22 21:33, Volker Schlecht wrote: Cc: Maintainer Updates rebar3 to version 3.20 https://github.com/erlang/rebar3/releases/tag/3.20.0 * Starting with this version they bundle all of their build dependencies * Drop all DISTFILES for the bundled dependencies * Keep DISTFILE for meck around, since it's needed to run make test * Adapt patches to their new paths * Adapt substitutions to their new paths * Only unpack meck hex module in do-test Rebuilds elixir, rebuilds rabbitmq, works on the command line on amd64
Re: openssl3 arm64 assembly fixes
> Date: Sat, 14 Jan 2023 00:24:19 +0100
> From: Theo Buehler
>
> On Fri, Jan 13, 2023 at 11:36:00PM +0100, Mark Kettenis wrote:
> > This fixes the arm64 perl assembly scripts to no longer emit data into
> > .text segments. I removed the -Wl,--no-execute-only flags and ran
> > "make test" which still reports that all tests passed.
>
> Yes, confirmed, this passes tests. Do you plan on backporting this to
> openssl/1.1 or should I take a shot at that?
If you have time to take a look, I can move on to riscv64.
> Although it's unlikely that the lang/node build will break, I'd like to
> make sure that it does build before you commit. I have started the build
> but I will likely sleep before it finishes.
>
> Please apply the patch below that disables -Wl,--no-execute-only for
> aarch64 and bumps revision for openssl/3.0 and mail/postfix (the latter
> need it due to static linking) on top of yours.
>
> Unless I tell you node broke tomorrow morning, this is ok tb. If you
> don't want to commit to postfix, sthen or I can take care of that.
Thanks, I'll take care of it.
> Index: security/openssl/3.0/Makefile
> ===
> RCS file: /cvs/ports/security/openssl/3.0/Makefile,v
> retrieving revision 1.21
> diff -u -p -r1.21 Makefile
> --- security/openssl/3.0/Makefile 9 Jan 2023 17:27:50 - 1.21
> +++ security/openssl/3.0/Makefile 13 Jan 2023 22:56:18 -
> @@ -5,7 +5,7 @@ V=3.0.7
> PKGNAME= openssl-${V}
> PKGSPEC= openssl->=3v0,<3.1v0
> EPOCH= 0
> -REVISION=2
> +REVISION=3
>
> SHLIBVER=12.2
> SHARED_LIBS= crypto ${SHLIBVER} \
> @@ -38,7 +38,9 @@ MAN_PREFIX= @man lib/eopenssl30/man
> INSTALL_TARGET+= install_man_docs
> .endif
>
> +.if ${MACHINE_ARCH} != aarch64
> USE_NOEXECONLY = Yes
> +.endif
>
> # install to unusual directory name - this port is *not* intended to be
> # picked up by configure scripts without explicitly CPPFLAGS/LDFLAGS.
> Index: mail/postfix/Makefile.inc
> ===
> RCS file: /cvs/ports/mail/postfix/Makefile.inc,v
> retrieving revision 1.104
> diff -u -p -r1.104 Makefile.inc
> --- mail/postfix/Makefile.inc 11 Jan 2023 16:33:57 - 1.104
> +++ mail/postfix/Makefile.inc 13 Jan 2023 23:11:01 -
> @@ -67,7 +67,9 @@ MAKE_AUXLIBS+= -L${LOCALBASE}/lib -lsasl
> .endif
>
> .if ${NEEDS_OPENSSL:L:Myes}
> +. if ${MACHINE_ARCH} != aarch64
> USE_NOEXECONLY= Yes
> +. endif
> BUILD_DEPENDS+= security/openssl/3.0
> MAKE_CCARGS+=-I${LOCALBASE}/include/eopenssl30
> MAKE_AUXLIBS+= ${LOCALBASE}/lib/eopenssl30/libssl.a \
> Index: mail/postfix/snapshot/Makefile
> ===
> RCS file: /cvs/ports/mail/postfix/snapshot/Makefile,v
> retrieving revision 1.346
> diff -u -p -r1.346 Makefile
> --- mail/postfix/snapshot/Makefile11 Jan 2023 16:33:57 - 1.346
> +++ mail/postfix/snapshot/Makefile13 Jan 2023 23:11:52 -
> @@ -1,5 +1,5 @@
> VERSION= 3.8-20221007
> -REVISION=2
> +REVISION=3
>
> PORTROACH=
> site:http://ftp.porcupine.org/mirrors/postfix-release/experimental/
> MASTER_SITES=${MASTER_SITE_POSTFIX:=experimental/}
> Index: mail/postfix/stable/Makefile
> ===
> RCS file: /cvs/ports/mail/postfix/stable/Makefile,v
> retrieving revision 1.239
> diff -u -p -r1.239 Makefile
> --- mail/postfix/stable/Makefile 11 Jan 2023 16:33:57 - 1.239
> +++ mail/postfix/stable/Makefile 13 Jan 2023 23:11:40 -
> @@ -1,5 +1,5 @@
> VERSION= 3.7.3
> -REVISION=2
> +REVISION=3
>
> PORTROACH= site:http://ftp.porcupine.org/mirrors/postfix-release/official/
> MASTER_SITES=${MASTER_SITE_POSTFIX:=official/}
>
Re: UPDATE: emulators/citra
On Wed Dec 14, 2022 at 11:33:23AM +0100, Stefan Sperling wrote:
> On Wed, Dec 14, 2022 at 10:53:09AM +0100, Stefan Sperling wrote:
> > On Tue, Dec 13, 2022 at 11:16:59PM +0100, Stefan Sperling wrote:
> > > On Sun, Dec 04, 2022 at 05:19:01PM +0100, Rafael Sadowski wrote:
> > > > Hi Thomas, Hi ports@,
> > > >
> > > >
> > > > Update citra-nightly to 1816. This update results form the devel/catch2
> > > > update and depends on it. There a some exciting port changes:
> > > >
> > > > - Switch to the github repository.
> > > > - 1816 depends on C++20 so I add COMPILER and point to clang only.
> > > > - CXXFLAGS deleted as it no longer needed
> > > > - Use fmt, boost, sdl and robin-map from system
> > > > - Remove {catch2,fmt,boost} before configure to ensure it is not picked
> > > > up
> > > > - This update needs devel/catch2>=3.2.0 (see ports@)
> > > >
> > > > I am not a user of citra so please test and send feedback.
> > > >
> > > > Rafael
> > > >
> > >
> > > The 'citra' SDL binary seems to work fine.
> > >
> > > But citra-qt is broken by this update. No image is being displayed in
> > > the window during emulation. citra-qt works in citra-0.0.0.729p5.
> >
> > In case a reproducer is useful, download this .3dsx file:
> > https://archive.org/download/thc-3ds-physics-sandbox/3DSPhysicsSandbox_v0.3.7z/3ds%2Fphysicssandbox%2Fphysicssandbox.3dsx
> > This game is BSD-licensed homebrew, see here for source code:
> > https://github.com/pieface-/3dsphysicssandbox
> >
> > With citra-0.0.0.729p5 it runs well in both citra and citra-qt (use the
> > mouse to move the squares on the "touchscreen" and watch them bounce).
> >
> > With updated citra, the graphics only show up in citra (the SDL version),
> > but not in citra-qt.
>
> Another problem:
>
> With a game controller plugged in, this message appears over and over on
> stderr of the SDL citra program, and the controller does not work.
> The only way I found to get the process to quit in this state is kill -9.
>
> [ 62.956917] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
> [ 62.995382] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
> [ 63.032273] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
> [ 63.069881] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
> [ 63.108039] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
> [ 63.145670] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
> [ 63.183113] Input
> input_common/sdl/sdl_impl.cpp:InitGameController:508: opened joystick 0 as
> controller
>
> Controllers do work in citra-qt of citra-0.0.0.729p5. But in the SDL citra
> of 0.0.0.729p5 controllers don't seem to work at all (at least after copying
> over the button config generated by citra-qt from qt-config.ini to the
> sdl2-config.ini file, not sure if that is expected to work).
>
> I'll stop playig around for now.
> Perhaps I will find time to look into fixing some of these issues, but it is
> not very likely :-/
>
It looks like 1827 fixes this issue. Stefan, could you verify this for me?
Before I tested 1827 I removed my config in .config/citra-emu
Cheers, Rafael
Index: Makefile
===
RCS file: /cvs/ports/emulators/citra/Makefile,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 Makefile
--- Makefile14 Jan 2023 08:26:10 - 1.20
+++ Makefile14 Jan 2023 11:10:22 -
@@ -7,10 +7,9 @@ USE_WXNEEDED = Yes
COMMENT = nintendo 3DS emulator
-V =729
-DISTNAME = citra-nightly-${V}
+DISTNAME = citra-unified-source-20230110-ad2cbe2
+V =1827
PKGNAME = citra-0.0.0.${V}
-REVISION = 8
CATEGORIES = emulators
@@ -19,35 +18,49 @@ CATEGORIES =emulators
# BSD-3-clause (nihstro), LGPLv2.1 (soundtouch), BSD-style (xbyak)
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Multimedia Qt5Network Qt5OpenGL
-WANTLIB += Qt5Widgets SDL2 c cryptopp enet iconv m
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Multimedia Qt5Widgets
+WANTLIB += SDL2 avcodec avformat avutil boost_serialization-mt
+WANTLIB += c cryptopp enet fmt m swresample swscale usb-1.0
-MASTER_SITES = https://spacehopper.org/mirrors/
+MASTER_SITES =
https://github.com/citra-emu/citra-nightly/releases/download/nightly-${V}/
EXTRACT_SUFX = .tar.xz
MODULES = devel/cmake \
x11/qt5
-# XXX Enable with the next update
-#BUILD_DEPENDS = devel/catch2
+# C++20
+COMPILER = base-clang ports-clang
+
+BUILD_DEPENDS =devel/catch2 \
+ devel/robin-map
-BUILD_DEPENDS =devel/boost
RUN_DEPENDS = devel/desktop-file-utils \
misc/shared-mime-info \
Re: Opinions - Multiple versions of lang/erlang needed?
On 2023/01/14 11:33, Stuart Henderson wrote: > Looks good to me, we will also need quirks/@pkgpath markers to handle > updates from 21 to 25 but whoever commits can do that. And rebar->rebar3 I think
Re: UPDATE: emulators/citra
On Sat, Jan 14, 2023 at 12:14:41PM +0100, Rafael Sadowski wrote: > It looks like 1827 fixes this issue. Stefan, could you verify this for me? > Before I tested 1827 I removed my config in .config/citra-emu I won't be able to test this until at least a week from now. So please proceed. I will check it again when possible and let you know. No point in staying on our old version if you already got some fixes. Tee new version is overall clearly much better in terms of features and compatibility.
[new] meta/jitsi-1.0 - meta port for jitsi and friends
Hi, I've attached the meta port for jitsi, which contains the README for jitsi as well as sample files for nginx and prosody. I've had it running locally for a while and its been working fine. Tests, comments, OKs would be good to have. Cheers, Aisha jitsi-1.0.tgz Description: GNU Zip compressed data
Re: Opinions - Multiple versions of lang/erlang needed?
On Sat Jan 14, 2023 at 11:33:00AM +, Stuart Henderson wrote: > On 2023/01/14 10:52, Volker Schlecht wrote: > > I never tried to submit a patch for dropping something, but > > here's an honest attempt - of course devel/rebar needs to be > > dropped as well, since it depends on erlang21. > > > > I validated the changed erlang.port.mk by rebuilding elixir, > > rebar3 and rabbitmq, which worked without problem. > > > > On 1/14/23 00:03, Antoine Jacoutot wrote: > > > I would love to remove erlang 21. It’s in the way of the wxWidgets update. > > Looks good to me, we will also need quirks/@pkgpath markers to handle > updates from 21 to 25 but whoever commits can do that. > > Any objections? > +1
[update] www/freshrss to 1.20.2
Hi,
I've attached an update for freshrss to 1.20.2.
I've got it running for a couple of week, no issues.
ok?
aisha
diff --git a/www/freshrss/Makefile b/www/freshrss/Makefile
index 585d794678f..601ea3a2d8d 100644
--- a/www/freshrss/Makefile
+++ b/www/freshrss/Makefile
@@ -5,7 +5,7 @@ PKG_ARCH = *
GH_ACCOUNT = FreshRSS
GH_PROJECT = FreshRSS
-GH_TAGNAME = 1.20.0
+GH_TAGNAME = 1.20.2
PKGNAME = freshrss-${GH_TAGNAME}
diff --git a/www/freshrss/distinfo b/www/freshrss/distinfo
index e6e53f32bdb..ba9c1b32465 100644
--- a/www/freshrss/distinfo
+++ b/www/freshrss/distinfo
@@ -1,2 +1,2 @@
-SHA256 (FreshRSS-1.20.0.tar.gz) = 61GIbYXZ6V8x8iW8dxmIXjtAt1xofh9nDnHwGUnxMVM=
-SIZE (FreshRSS-1.20.0.tar.gz) = 4393683
+SHA256 (FreshRSS-1.20.2.tar.gz) = 2fqE38q4kWyOl302Ap7vWIYPcCkoTChH7HMke8iZiPc=
+SIZE (FreshRSS-1.20.2.tar.gz) = 4430346
diff --git a/www/freshrss/pkg/PLIST b/www/freshrss/pkg/PLIST
index 0e6243a3ff1..a9a763a8eed 100644
--- a/www/freshrss/pkg/PLIST
+++ b/www/freshrss/pkg/PLIST
@@ -149,6 +149,15 @@ www/freshrss/app/i18n/de/index.php
www/freshrss/app/i18n/de/install.php
www/freshrss/app/i18n/de/sub.php
www/freshrss/app/i18n/de/user.php
+www/freshrss/app/i18n/el/
+www/freshrss/app/i18n/el/admin.php
+www/freshrss/app/i18n/el/conf.php
+www/freshrss/app/i18n/el/feedback.php
+www/freshrss/app/i18n/el/gen.php
+www/freshrss/app/i18n/el/index.php
+www/freshrss/app/i18n/el/install.php
+www/freshrss/app/i18n/el/sub.php
+www/freshrss/app/i18n/el/user.php
www/freshrss/app/i18n/en/
www/freshrss/app/i18n/en-us/
www/freshrss/app/i18n/en-us/admin.php
@@ -194,6 +203,15 @@ www/freshrss/app/i18n/he/index.php
www/freshrss/app/i18n/he/install.php
www/freshrss/app/i18n/he/sub.php
www/freshrss/app/i18n/he/user.php
+www/freshrss/app/i18n/id/
+www/freshrss/app/i18n/id/admin.php
+www/freshrss/app/i18n/id/conf.php
+www/freshrss/app/i18n/id/feedback.php
+www/freshrss/app/i18n/id/gen.php
+www/freshrss/app/i18n/id/index.php
+www/freshrss/app/i18n/id/install.php
+www/freshrss/app/i18n/id/sub.php
+www/freshrss/app/i18n/id/user.php
www/freshrss/app/i18n/it/
www/freshrss/app/i18n/it/admin.php
www/freshrss/app/i18n/it/conf.php
@@ -1040,10 +1058,10 @@ www/freshrss/p/themes/base-theme/
www/freshrss/p/themes/base-theme/README.md
www/freshrss/p/themes/base-theme/base.css
www/freshrss/p/themes/base-theme/base.rtl.css
+www/freshrss/p/themes/base-theme/frss.css
+www/freshrss/p/themes/base-theme/frss.rtl.css
www/freshrss/p/themes/base-theme/loader.gif
www/freshrss/p/themes/base-theme/metadata.json
-www/freshrss/p/themes/base-theme/template.css
-www/freshrss/p/themes/base-theme/template.rtl.css
www/freshrss/p/themes/fonts/
www/freshrss/p/themes/fonts/LatoLatin-Bold.woff
www/freshrss/p/themes/fonts/LatoLatin-BoldItalic.woff
@@ -1128,6 +1146,13 @@ www/freshrss/tests/app/Models/UserQueryTest.php
www/freshrss/tests/app/Utils/
www/freshrss/tests/app/Utils/passwordUtilTest.php
www/freshrss/tests/bootstrap.php
+www/freshrss/tests/cli/
+www/freshrss/tests/cli/i18n/
+www/freshrss/tests/cli/i18n/I18nCompletionValidatorTest.php
+www/freshrss/tests/cli/i18n/I18nDataTest.php
+www/freshrss/tests/cli/i18n/I18nFileTest.php
+www/freshrss/tests/cli/i18n/I18nUsageValidatorTest.php
+www/freshrss/tests/cli/i18n/I18nValueTest.php
www/freshrss/tests/fixtures/
www/freshrss/tests/fixtures/migrations/
www/freshrss/tests/fixtures/migrations/2019_12_22_FooBar.php
[update] net/knot net/py-libknot to 3.2.4
Hi,
I've attached updates for both knot and py-libknot to 3.2.4.
No major changes in net/knot, no new symbols in library.
py-libknot has additional functionality added but its a ctypes library, so the
update patch is trivial.
Working fine for me, ok?
Cheers,
Aisha
diff --git a/net/knot/Makefile b/net/knot/Makefile
index 366cc501af8..e3401b7e2cb 100644
--- a/net/knot/Makefile
+++ b/net/knot/Makefile
@@ -1,7 +1,7 @@
COMMENT = authoritative DNS server
# update net/py-libknot when updating this
-DISTNAME = knot-3.2.3
+DISTNAME = knot-3.2.4
SHARED_LIBS += dnssec 3.1 # .9.0
SHARED_LIBS += knot 8.0 # .13.0
diff --git a/net/knot/distinfo b/net/knot/distinfo
index 7c9e374fd46..4c41a226355 100644
--- a/net/knot/distinfo
+++ b/net/knot/distinfo
@@ -1,2 +1,2 @@
-SHA256 (knot-3.2.3.tar.xz) = 9zbvKENYkj4xL44ePGznyXsgllsJ62VwXp9+PV6anXk=
-SIZE (knot-3.2.3.tar.xz) = 1673664
+SHA256 (knot-3.2.4.tar.xz) = KZ6N6Rj5/H7L5iW0HLCF5HzdpUJhLvvVHNXsYN653RM=
+SIZE (knot-3.2.4.tar.xz) = 1674532
diff --git a/net/py-libknot/Makefile b/net/py-libknot/Makefile
index 50d450139fd..e07f5c5fb04 100644
--- a/net/py-libknot/Makefile
+++ b/net/py-libknot/Makefile
@@ -1,10 +1,9 @@
COMMENT = Python bindings for libknot
-MODPY_EGG_VERSION =3.2.3
+MODPY_EGG_VERSION =3.2.4
DISTNAME = libknot-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 1
CATEGORIES = net
diff --git a/net/py-libknot/distinfo b/net/py-libknot/distinfo
index bbea1cbdb9c..c43d903e8d1 100644
--- a/net/py-libknot/distinfo
+++ b/net/py-libknot/distinfo
@@ -1,2 +1,2 @@
-SHA256 (libknot-3.2.3.tar.gz) = Hv4JzG7r+8b7fBUKxZUirLAf0gJEgr2q4OFgbym/Y+g=
-SIZE (libknot-3.2.3.tar.gz) = 9508
+SHA256 (libknot-3.2.4.tar.gz) = QpL/60WIxwyJo1fgYODxnyOFa4vze8OQ7ipl1xs9rSM=
+SIZE (libknot-3.2.4.tar.gz) = 10401
diff --git a/net/py-libknot/pkg/PLIST b/net/py-libknot/pkg/PLIST
index d6b4e923d27..4068adfb2ab 100644
--- a/net/py-libknot/pkg/PLIST
+++ b/net/py-libknot/pkg/PLIST
@@ -10,7 +10,10 @@
lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}__init__.${MODP
lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}control.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}control.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}dname.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}dname.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}probe.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/libknot/${MODPY_PYCACHE}probe.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/libknot/control.py
+lib/python${MODPY_VERSION}/site-packages/libknot/dname.py
lib/python${MODPY_VERSION}/site-packages/libknot/probe.py
[update] www/vaultwarden-web to 2023.1.0
Hi,
I've attached update for www/vaultwarden-web to 2023.1.0.
This needs testers as upstream has mentioned "latest version of vaultwarden-web
might not always be compatible with latest version of vaultwarden".
Moving forward I will try to give these ports some fresh air for a while by
letting them sit in the mailing list for a while.
Testers would be really appreciated.
Cheers,
Aisha
diff --git a/www/vaultwarden-web/Makefile b/www/vaultwarden-web/Makefile
index d2586150c6f..eb8a736728f 100644
--- a/www/vaultwarden-web/Makefile
+++ b/www/vaultwarden-web/Makefile
@@ -2,7 +2,7 @@ COMMENT = Web vault builds for vaultwarden
CATEGORIES = www
-VERSION = 2022.12.0
+VERSION = 2023.1.0
MASTER_SITES =
https://github.com/dani-garcia/bw_web_builds/releases/download/v${VERSION}/
DISTNAME = bw_web_v${VERSION}
PKGNAME = vaultwarden-web-${VERSION}
diff --git a/www/vaultwarden-web/distinfo b/www/vaultwarden-web/distinfo
index dbf9938ab20..63b2c4c9e93 100644
--- a/www/vaultwarden-web/distinfo
+++ b/www/vaultwarden-web/distinfo
@@ -1,2 +1,2 @@
-SHA256 (bw_web_v2022.12.0.tar.gz) =
QC3/aqIF2NdJPHmwUbvJR62wsUGBrgsHJCyqBJ/0gMc=
-SIZE (bw_web_v2022.12.0.tar.gz) = 9299031
+SHA256 (bw_web_v2023.1.0.tar.gz) = 9jXYoowD9ZftgTVM9xqgJk0Fq/P+xBM3ss9IefOz9vw=
+SIZE (bw_web_v2023.1.0.tar.gz) = 9554069
diff --git a/www/vaultwarden-web/pkg/PLIST b/www/vaultwarden-web/pkg/PLIST
index cabba6f09db..93c340cf172 100644
--- a/www/vaultwarden-web/pkg/PLIST
+++ b/www/vaultwarden-web/pkg/PLIST
@@ -1,8 +1,10 @@
vaultwarden/
vaultwarden/web-vault/
vaultwarden/web-vault/.nojekyll
-vaultwarden/web-vault/182.ef118a836aae4f655003.js
-vaultwarden/web-vault/182.ef118a836aae4f655003.js.map
+vaultwarden/web-vault/167.d2977fe173ce2e887e92.js
+vaultwarden/web-vault/167.d2977fe173ce2e887e92.js.map
+vaultwarden/web-vault/182.d2a9a155b344d43557b2.js
+vaultwarden/web-vault/182.d2a9a155b344d43557b2.js.map
vaultwarden/web-vault/404/
vaultwarden/web-vault/404.html
vaultwarden/web-vault/404/bootstrap.min.css
@@ -10,57 +12,55 @@ vaultwarden/web-vault/404/styles.css
vaultwarden/web-vault/584.238f402a694e2a33f299.js
vaultwarden/web-vault/584.238f402a694e2a33f299.js.LICENSE.txt
vaultwarden/web-vault/584.238f402a694e2a33f299.js.map
-vaultwarden/web-vault/650.62b87073d6547a6b7fd4.js
-vaultwarden/web-vault/650.62b87073d6547a6b7fd4.js.map
-vaultwarden/web-vault/754.1655b970c4e9dab5fc90.js
-vaultwarden/web-vault/754.1655b970c4e9dab5fc90.js.map
-vaultwarden/web-vault/812.59ccc0f03ed365576697.js
-vaultwarden/web-vault/812.59ccc0f03ed365576697.js.map
+vaultwarden/web-vault/650.4573bc38bef00a907142.js
+vaultwarden/web-vault/650.4573bc38bef00a907142.js.map
+vaultwarden/web-vault/754.d34b2564ddaf564bb52f.js
+vaultwarden/web-vault/754.d34b2564ddaf564bb52f.js.map
+vaultwarden/web-vault/812.8b07d403d707b395caf6.js
+vaultwarden/web-vault/812.8b07d403d707b395caf6.js.map
vaultwarden/web-vault/933.6ce03ae789e31b21134d.js
vaultwarden/web-vault/933.6ce03ae789e31b21134d.js.LICENSE.txt
vaultwarden/web-vault/933.6ce03ae789e31b21134d.js.map
-vaultwarden/web-vault/977.30cfdbe38986b8ddb470.js
-vaultwarden/web-vault/977.30cfdbe38986b8ddb470.js.map
vaultwarden/web-vault/app/
vaultwarden/web-vault/app-id.json
-vaultwarden/web-vault/app/main.5f8690f5c03a207c390a.js
-vaultwarden/web-vault/app/main.5f8690f5c03a207c390a.js.map
-vaultwarden/web-vault/app/main.82096a4e78d5d3f7b01b.css
-vaultwarden/web-vault/app/main.82096a4e78d5d3f7b01b.css.map
+vaultwarden/web-vault/app/main.6d0593041fc253bc2918.css
+vaultwarden/web-vault/app/main.6d0593041fc253bc2918.css.map
+vaultwarden/web-vault/app/main.a6ab60bdf3d0de64c5a0.js
+vaultwarden/web-vault/app/main.a6ab60bdf3d0de64c5a0.js.map
vaultwarden/web-vault/app/polyfills.428c25638840333a09ee.js
vaultwarden/web-vault/app/polyfills.428c25638840333a09ee.js.LICENSE.txt
vaultwarden/web-vault/app/polyfills.428c25638840333a09ee.js.map
-vaultwarden/web-vault/app/vendor.7c30c6e2b5ba56506ea9.js
-vaultwarden/web-vault/app/vendor.7c30c6e2b5ba56506ea9.js.LICENSE.txt
-vaultwarden/web-vault/app/vendor.7c30c6e2b5ba56506ea9.js.map
+vaultwarden/web-vault/app/vendor.52ec48ef32585b61ed1b.js
+vaultwarden/web-vault/app/vendor.52ec48ef32585b61ed1b.js.LICENSE.txt
+vaultwarden/web-vault/app/vendor.52ec48ef32585b61ed1b.js.map
vaultwarden/web-vault/browserconfig.xml
vaultwarden/web-vault/ca8f66ed7fccfcd0809f.json
vaultwarden/web-vault/captcha-connector.html
vaultwarden/web-vault/captcha-mobile-connector.html
vaultwarden/web-vault/connectors/
-vaultwarden/web-vault/connectors/captcha.921e95e8f847c9aa9ad4.css
-vaultwarden/web-vault/connectors/captcha.921e95e8f847c9aa9ad4.css.map
+vaultwarden/web-vault/connectors/captcha.b15040df3b2fb01e04d6.css
+vaultwarden/web-vault/connectors/captcha.b15040df3b2fb01e04d6.css.map
vaultwarden/web-vault/connectors/captcha.e2f543930127fcb95585.js
vaultwarden/web-vault/connectors/captcha.e2f543930127fcb95585.js.map
vaultwarden/web-vault/connectors/duo.03d3232066d89682b1ee.css
vaultwarden/web-vault/c
Re: [UPDATE] net/rabbitmq 3.10.13
On 2022/12/30 21:04, Volker Schlecht wrote:
> While rabbitmq.rc always started the rabbitmq launch script as _rabbitmq, it
> contained a call to rabbitmqctl in rc_check(). rabbitmqctl always starts an
> instance of epmd if none is running, and since the first call to rc_check()
> is run by root, it always launches epmd as root.
> Besides having a server running with root privileges now, this leads to the
> problem that the first startup might fail because
> /var/rabbitmq/.erlang.cookie is now owned by root and not accessible by
> _rabbitmq anymore.
>
> What I'm proposing now is to use a pexp in rabbitmq.rc for rc_check().
>
> Given rabbitmq's giant invocation of erl25, the pattern I'm looking for
> might be a little flaky, but it's the best working idea I could come up with
> so far - better solutions are highly welcome, as is of course any other
> feedback.
> Index: pkg/rabbitmq.rc
> ===
> RCS file: /cvs/ports/net/rabbitmq/pkg/rabbitmq.rc,v
> retrieving revision 1.11
> diff -u -p -r1.11 rabbitmq.rc
> --- pkg/rabbitmq.rc 31 Jul 2022 16:28:15 - 1.11
> +++ pkg/rabbitmq.rc 30 Dec 2022 19:45:46 -
> @@ -5,19 +5,20 @@ daemon_user="_rabbitmq"
>
> . /etc/rc.d/rc.subr
>
> +pexp="s rabbit boot"
> rc_reload=NO
> rc_usercheck=NO
>
> rc_pre() {
> - install -d -o ${daemon_user} /var/run/rabbitmq
> +install -d -o ${daemon_user} /var/run/rabbitmq
...
> rc_stop() {
> - ${TRUEPREFIX}/bin/rabbitmqctl stop
> +${TRUEPREFIX}/bin/rabbitmqctl stop
> }
please leave the tabs as they were
> }
>
> rc_check() {
> - ${TRUEPREFIX}/bin/rabbitmqctl status
> +pgrep -q -f "${pexp}"
if it needs to use pexp, better to use the default rc_check (which uses
pgrep -q -xf, so the pexp string will need to match the whole process
string).
how about this for rabbitmq.rc?
(btw, this part would have been more obvious sent as a separate diff
rather than stacked with an update)
Index: pkg/rabbitmq.rc
===
RCS file: /cvs/ports/net/rabbitmq/pkg/rabbitmq.rc,v
retrieving revision 1.11
diff -u -p -r1.11 rabbitmq.rc
--- pkg/rabbitmq.rc 31 Jul 2022 16:28:15 - 1.11
+++ pkg/rabbitmq.rc 14 Jan 2023 14:01:09 -
@@ -5,15 +5,12 @@ daemon_user="_rabbitmq"
. /etc/rc.d/rc.subr
+pexp="${TRUEPREFIX}/lib/erlang${MODERL_VERSION}/erts.*bin/beam.*-s rabbit
boot.*"
rc_reload=NO
rc_usercheck=NO
rc_pre() {
install -d -o ${daemon_user} /var/run/rabbitmq
-}
-
-rc_check() {
- ${TRUEPREFIX}/bin/rabbitmqctl status
}
rc_stop() {
Re: [update] devel/rebar3 3.20.0
On 2023/01/14 10:43, Volker Schlecht wrote:
> bump
..
> > On 12/29/22 21:33, Volker Schlecht wrote:
> > > Cc: Maintainer
> > >
> > > Updates rebar3 to version 3.20
> > > https://github.com/erlang/rebar3/releases/tag/3.20.0
> > >
> > > * Starting with this version they bundle all of their build dependencies
> > > * Drop all DISTFILES for the bundled dependencies
> > > * Keep DISTFILE for meck around, since it's needed to run make test
> > > * Adapt patches to their new paths
> > > * Adapt substitutions to their new paths
> > > * Only unpack meck hex module in do-test
> > >
> > > Rebuilds elixir, rebuilds rabbitmq, works on the command line on amd64
looks good to me. jmatthew, any concerns?
- Forwarded message from Volker Schlecht -
From: Volker Schlecht
Date: Thu, 29 Dec 2022 21:33:48 +0100
To: ports , jmatt...@openbsd.org
Subject: [update] devel/rebar3 3.20.0
Index: Makefile
===
RCS file: /cvs/ports/devel/rebar3/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile20 Jul 2022 01:09:58 - 1.7
+++ Makefile29 Dec 2022 20:29:28 -
@@ -2,7 +2,7 @@ COMMENT = Erlang build tool
GH_ACCOUNT = erlang
GH_PROJECT = rebar3
-GH_TAGNAME = 3.19.0
+GH_TAGNAME = 3.20.0
CATEGORIES = devel
HOMEPAGE = https://www.rebar3.org
MAINTAINER = Jonathan Matthew
@@ -26,22 +26,11 @@ ERRORS += "Invalid FLAVOR
EXTRACT_ONLY = rebar3-${GH_TAGNAME}.tar.gz
-HEX_MODULES = \
- bbmustache 1.12.2 \
- certifi 2.9.0 \
- cf 0.3.1 \
- cth_readable1.5.1 \
- erlware_commons 1.5.0 \
- eunit_formatters0.5.0 \
- getopt 1.0.1 \
- providers 1.9.0 \
- relx4.7.0 \
- ssl_verify_fun 1.1.6
# for tests
HEX_MODULES += \
meck0.8.13
-DISTFILES =rebar3-{}${GH_TAGNAME}.tar.gz
+DISTFILES =rebar3-{}${GH_TAGNAME}.tar.gz
.for _m _v in ${HEX_MODULES}
DISTFILES += ${_m}-${_v}.tar:1
.endfor
@@ -50,23 +39,12 @@ BUILD_DEPENDS +=${RUN_DEPENDS}
SUBST_VARS = ERL_VERSION
-post-extract:
- # extract hex modules into _build/default/lib for the bootstrap,
- # and _checkouts for rebar3 itself, otherwise it will fetch from hex
- mkdir -p ${WRKSRC}/_build/default/lib
-.for _m _v in ${HEX_MODULES}
- mkdir -p ${WRKDIR}/${_m}
- tar xf ${FULLDISTDIR}/${_m}-${_v}.tar -C ${WRKDIR}/${_m}
-
- mkdir -p ${WRKSRC}/_checkouts/${_m}
- tar xzf ${WRKDIR}/${_m}/contents.tar.gz -C ${WRKSRC}/_checkouts/${_m}
- cp -r ${WRKSRC}/_checkouts/${_m} ${WRKSRC}/_build/default/lib/
-.endfor
pre-configure:
- ${SUBST_CMD} ${WRKSRC}/bootstrap ${WRKSRC}/src/rebar_prv_escriptize.erl
\
- ${WRKSRC}/_build/default/lib/relx/priv/templates/bin \
- ${WRKSRC}/_build/default/lib/relx/priv/templates/extended_bin
+ ${SUBST_CMD} ${WRKSRC}/bootstrap \
+ ${WRKSRC}/apps/rebar/src/rebar_prv_escriptize.erl \
+ ${WRKSRC}/vendor/relx/priv/templates/bin \
+ ${WRKSRC}/vendor/relx/priv/templates/extended_bin
do-build:
cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} ${WRKSRC}/bootstrap
@@ -76,6 +54,14 @@ do-install:
PORTHOME= ${WRKDIR}
do-test:
+.for _m _v in ${HEX_MODULES}
+ mkdir -p ${WRKDIR}/${_m}
+ tar xf ${FULLDISTDIR}/${_m}-${_v}.tar -C ${WRKDIR}/${_m}
+
+ mkdir -p ${WRKSRC}/_checkouts/${_m}
+ tar xzf ${WRKDIR}/${_m}/contents.tar.gz -C ${WRKSRC}/_checkouts/${_m}
+ cp -r ${WRKSRC}/_checkouts/${_m} ${WRKSRC}/_build/default/lib/
+.endfor
cd ${WRKSRC} && \
${SETENV} ${ALL_TEST_ENV} ./rebar3 escriptize && \
${SETENV} ${ALL_TEST_ENV} ./rebar3 ct
Index: distinfo
===
RCS file: /cvs/ports/devel/rebar3/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo20 Jul 2022 01:09:58 - 1.3
+++ distinfo29 Dec 2022 20:29:28 -
@@ -1,24 +1,4 @@
-SHA256 (bbmustache-1.12.2.tar) = aIszpNXMLVH1da3ws2g/xAo4MUovFQkG7c/Hf1tXezs=
-SHA256 (certifi-2.9.0.tar) = Jm2ka9sG1sbTX955m8so022YXUJK18CLW7SPW1zdRkE=
-SHA256 (cf-0.3.1.tar) = MV6NRH06SwK82/o5etA7u5iKbgqm9E063Q9OPDv5dnI=
-SHA256 (cth_readable-1.5.1.tar) = aGVBoi7+bKWkGgR7OVFsLdKPs8reXySi8ZFFs5Z/nYA=
-SHA256 (erlware_commons-1.5.0.tar) =
PnxvsrpMKbDdXf6dAxtmRJ4giOzsGoFGW9n94F7X0Ns=
-SHA256 (eunit_formatters-0.5.0.tar) =
1si6ITQklE5uBbvAl8MgAc3Qq+OSXQJFTyKbINaHY8k=
-SHA256 (getopt-1.0.1.tar) = U+Grg7nOtlyWctPno1uAkum9ybPugHIUcaFhwQxZlZw=
SHA256 (meck-0.8.13.tar) = 008BPBVttRrVfMVWiRuXIOahwd9f4uFa+ZnITWzr6xo=
-SHA256 (providers-1.9.0.tar) = 0ofodEBqFQVghkKwo9tbaNato/KrABrsh+f018efwBc=
-SHA256 (rebar3-3.19.0
OpenSSL 1.1 arm64 assembly fixes
This is a backport of kettenis's diff. Most of it applied with a few
offsets. I had to hand-apply two or three hunks due to whitespace noise.
The only real changes are the hunks containing __ILP32__ which were
needed to make it link. They are part of the diff to OpenSSL 3, which
came from https://github.com/openssl/openssl/pull/8256 which was never
backported.
If this goes in, I'll also take care of sslscan similar to postfix.
Tests pass apart from one unrelated failure that has been around for a
while:
../test/recipes/90-test_shlibload.t
Dubious, test returned 9 (wstat 2304, 0x900)
Failed 9/10 subtests
Index: Makefile
===
RCS file: /cvs/ports/security/openssl/1.1/Makefile,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile
--- Makefile9 Jan 2023 17:27:50 - 1.46
+++ Makefile14 Jan 2023 15:38:45 -
@@ -3,7 +3,7 @@ PORTROACH= limit:^1\.1\.[0-9][a-z] skipb
V= 1.1.1s
PKGSPEC= openssl->=1.1.0v0,<1.2v0
EPOCH= 0
-REVISION= 1
+REVISION= 2
SHLIBVER= 11.6
SHARED_LIBS= crypto ${SHLIBVER} \
@@ -35,7 +35,9 @@ MAN_PREFIX= @man lib/eopenssl11/man
INSTALL_TARGET+= install_man_docs
.endif
+.if ${MACHINE_ARCH} != arch64
USE_NOEXECONLY=Yes
+.endif
# install to unusual directory name - this port is *not* intended to be
# picked up by configure scripts without explicitly CPPFLAGS/LDFLAGS.
Index: patches/patch-Configurations_10-main_conf
===
RCS file:
/cvs/ports/security/openssl/1.1/patches/patch-Configurations_10-main_conf,v
retrieving revision 1.5
diff -u -p -r1.5 patch-Configurations_10-main_conf
--- patches/patch-Configurations_10-main_conf 11 Mar 2022 19:53:36 -
1.5
+++ patches/patch-Configurations_10-main_conf 14 Jan 2023 15:38:45 -
@@ -1,7 +1,7 @@
Index: Configurations/10-main.conf
--- Configurations/10-main.conf.orig
+++ Configurations/10-main.conf
-@@ -958,6 +958,7 @@ my %targets = (
+@@ -965,6 +965,7 @@ my %targets = (
},
"BSD-x86-elf" => {
inherit_from => [ "BSD-x86" ],
Index: patches/patch-crypto_aes_asm_aesv8-armx_pl
===
RCS file: patches/patch-crypto_aes_asm_aesv8-armx_pl
diff -N patches/patch-crypto_aes_asm_aesv8-armx_pl
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-crypto_aes_asm_aesv8-armx_pl 14 Jan 2023 15:38:45 -
@@ -0,0 +1,27 @@
+Index: crypto/aes/asm/aesv8-armx.pl
+--- crypto/aes/asm/aesv8-armx.pl.orig
crypto/aes/asm/aesv8-armx.pl
+@@ -79,11 +79,13 @@ my ($zero,$rcon,$mask,$in0,$in1,$tmp,$key)=
+
+
+ $code.=<<___;
++.rodata
+ .align5
+ .Lrcon:
+ .long 0x01,0x01,0x01,0x01
+ .long 0x0c0f0e0d,0x0c0f0e0d,0x0c0f0e0d,0x0c0f0e0d // rotate-n-splat
+ .long 0x1b,0x1b,0x1b,0x1b
++.previous
+
+ .globl${prefix}_set_encrypt_key
+ .type ${prefix}_set_encrypt_key,%function
+@@ -109,7 +111,8 @@ $code.=<<___;
+ tst $bits,#0x3f
+ b.ne.Lenc_key_abort
+
+- adr $ptr,.Lrcon
++ adrp$ptr,.Lrcon
++ add $ptr,$ptr,:lo12:.Lrcon
+ cmp $bits,#192
+
+ veor$zero,$zero,$zero
Index: patches/patch-crypto_aes_asm_vpaes-armv8_pl
===
RCS file: patches/patch-crypto_aes_asm_vpaes-armv8_pl
diff -N patches/patch-crypto_aes_asm_vpaes-armv8_pl
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-crypto_aes_asm_vpaes-armv8_pl 14 Jan 2023 15:38:45 -
@@ -0,0 +1,150 @@
+Index: crypto/aes/asm/vpaes-armv8.pl
+--- crypto/aes/asm/vpaes-armv8.pl.orig
crypto/aes/asm/vpaes-armv8.pl
+@@ -49,7 +49,7 @@ open OUT,"| \"$^X\" $xlate $flavour $output";
+ *STDOUT=*OUT;
+
+ $code.=<<___;
+-.text
++.rodata
+
+ .type _vpaes_consts,%object
+ .align7 // totally strategic alignment
+@@ -140,6 +140,9 @@ _vpaes_consts:
+ .asciz "Vector Permutation AES for ARMv8, Mike Hamburg (Stanford University)"
+ .size _vpaes_consts,.-_vpaes_consts
+ .align6
++
++.text
++
+ ___
+
+ {
+@@ -159,7 +162,8 @@ $code.=<<___;
+ .type _vpaes_encrypt_preheat,%function
+ .align4
+ _vpaes_encrypt_preheat:
+- adr x10, .Lk_inv
++ adrpx10, .Lk_inv
++ add x10, x10, :lo12:.Lk_inv
+ moviv17.16b, #0x0f
+ ld1 {v18.2d-v19.2d}, [x10],#32 // .Lk_inv
+ ld1 {v20.2d-v23.2d}, [x10],#64 // .Lk_ipt, .Lk_sbo
+@@ -187,7 +191,9 @@ _vpaes_encrypt_preheat:
+ _vpaes_encrypt_core:
+ mov x9, $key
+ ldr w8, [$key,#240] // pull rounds
+- adr x11, .Lk_mc_forward+16
++ adrpx11, .Lk_mc_forward
++ add x11, x11, :lo12:.Lk_mc_forward
++ add x11, x11, #16
+ // vmovdqa .Lk_ipt(%rip),
%xmm2 # iptlo
+ ld1 {v16.2d}, [x9], #16
Re: [update] www/vaultwarden-web to 2023.1.0
On Sat 14/01/2023 08:33, aisha wrote:
> Hi,
> I've attached update for www/vaultwarden-web to 2023.1.0.
>
> This needs testers as upstream has mentioned "latest version of
> vaultwarden-web might not always be compatible with latest version of
> vaultwarden".
>
> Moving forward I will try to give these ports some fresh air for a while by
> letting them sit in the mailing list for a while.
> Testers would be really appreciated.
I'm not sure that it makes sense to update www/vaultwarden-web
independent from security/vaultwarden. Reason is given above ("...might
not always be compatible..."). Maybe we should follow upstream of
vaultwarden, and wait with updating www/vaultwarden-web. Docker
containers of the next release of vaultwarden will use
vaultwarden-web-2023.1.0 [0].
Do you know what the reason is for having separate ports for
vaultwarden-web and vaultwarden? What do you think of combining the
first with the latter? Something similar as what FreeBSD [1] and NetBSD
[2] seem to do.
[0]
https://github.com/dani-garcia/vaultwarden/commit/9b7e86efc23d6bbb5ee350160085ab8d8421d628
[1]
https://github.com/freebsd/freebsd-ports/blob/main/security/vaultwarden/Makefile
[2] https://github.com/NetBSD/pkgsrc/blob/trunk/security/vaultwarden
Re: OpenSSL 1.1 arm64 assembly fixes
> Date: Sat, 14 Jan 2023 16:56:32 +0100
> From: Theo Buehler
>
> This is a backport of kettenis's diff. Most of it applied with a few
> offsets. I had to hand-apply two or three hunks due to whitespace noise.
>
> The only real changes are the hunks containing __ILP32__ which were
> needed to make it link. They are part of the diff to OpenSSL 3, which
> came from https://github.com/openssl/openssl/pull/8256 which was never
> backported.
>
> If this goes in, I'll also take care of sslscan similar to postfix.
>
> Tests pass apart from one unrelated failure that has been around for a
> while:
>
> ../test/recipes/90-test_shlibload.t
> Dubious, test returned 9 (wstat 2304, 0x900)
> Failed 9/10 subtests
Looks good to me. You didn't remove the .LOPENSSL_armcap_P bits
furter up in the files that are part of that __ILP32__ stuff. But
that doesn't really matter.
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/openssl/1.1/Makefile,v
> retrieving revision 1.46
> diff -u -p -r1.46 Makefile
> --- Makefile 9 Jan 2023 17:27:50 - 1.46
> +++ Makefile 14 Jan 2023 15:38:45 -
> @@ -3,7 +3,7 @@ PORTROACH=limit:^1\.1\.[0-9][a-z] skipb
> V= 1.1.1s
> PKGSPEC= openssl->=1.1.0v0,<1.2v0
> EPOCH= 0
> -REVISION=1
> +REVISION=2
>
> SHLIBVER=11.6
> SHARED_LIBS= crypto ${SHLIBVER} \
> @@ -35,7 +35,9 @@ MAN_PREFIX= @man lib/eopenssl11/man
> INSTALL_TARGET+= install_man_docs
> .endif
>
> +.if ${MACHINE_ARCH} != arch64
> USE_NOEXECONLY= Yes
> +.endif
>
> # install to unusual directory name - this port is *not* intended to be
> # picked up by configure scripts without explicitly CPPFLAGS/LDFLAGS.
> Index: patches/patch-Configurations_10-main_conf
> ===
> RCS file:
> /cvs/ports/security/openssl/1.1/patches/patch-Configurations_10-main_conf,v
> retrieving revision 1.5
> diff -u -p -r1.5 patch-Configurations_10-main_conf
> --- patches/patch-Configurations_10-main_conf 11 Mar 2022 19:53:36 -
> 1.5
> +++ patches/patch-Configurations_10-main_conf 14 Jan 2023 15:38:45 -
> @@ -1,7 +1,7 @@
> Index: Configurations/10-main.conf
> --- Configurations/10-main.conf.orig
> +++ Configurations/10-main.conf
> -@@ -958,6 +958,7 @@ my %targets = (
> +@@ -965,6 +965,7 @@ my %targets = (
> },
> "BSD-x86-elf" => {
> inherit_from => [ "BSD-x86" ],
> Index: patches/patch-crypto_aes_asm_aesv8-armx_pl
> ===
> RCS file: patches/patch-crypto_aes_asm_aesv8-armx_pl
> diff -N patches/patch-crypto_aes_asm_aesv8-armx_pl
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-crypto_aes_asm_aesv8-armx_pl14 Jan 2023 15:38:45
> -
> @@ -0,0 +1,27 @@
> +Index: crypto/aes/asm/aesv8-armx.pl
> +--- crypto/aes/asm/aesv8-armx.pl.orig
> crypto/aes/asm/aesv8-armx.pl
> +@@ -79,11 +79,13 @@ my ($zero,$rcon,$mask,$in0,$in1,$tmp,$key)=
> +
> +
> + $code.=<<___;
> ++.rodata
> + .align 5
> + .Lrcon:
> + .long 0x01,0x01,0x01,0x01
> + .long 0x0c0f0e0d,0x0c0f0e0d,0x0c0f0e0d,0x0c0f0e0d //
> rotate-n-splat
> + .long 0x1b,0x1b,0x1b,0x1b
> ++.previous
> +
> + .globl ${prefix}_set_encrypt_key
> + .type ${prefix}_set_encrypt_key,%function
> +@@ -109,7 +111,8 @@ $code.=<<___;
> + tst $bits,#0x3f
> + b.ne.Lenc_key_abort
> +
> +-adr $ptr,.Lrcon
> ++adrp$ptr,.Lrcon
> ++add $ptr,$ptr,:lo12:.Lrcon
> + cmp $bits,#192
> +
> + veor$zero,$zero,$zero
> Index: patches/patch-crypto_aes_asm_vpaes-armv8_pl
> ===
> RCS file: patches/patch-crypto_aes_asm_vpaes-armv8_pl
> diff -N patches/patch-crypto_aes_asm_vpaes-armv8_pl
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-crypto_aes_asm_vpaes-armv8_pl 14 Jan 2023 15:38:45
> -
> @@ -0,0 +1,150 @@
> +Index: crypto/aes/asm/vpaes-armv8.pl
> +--- crypto/aes/asm/vpaes-armv8.pl.orig
> crypto/aes/asm/vpaes-armv8.pl
> +@@ -49,7 +49,7 @@ open OUT,"| \"$^X\" $xlate $flavour $output";
> + *STDOUT=*OUT;
> +
> + $code.=<<___;
> +-.text
> ++.rodata
> +
> + .type _vpaes_consts,%object
> + .align 7 // totally strategic alignment
> +@@ -140,6 +140,9 @@ _vpaes_consts:
> + .asciz "Vector Permutation AES for ARMv8, Mike Hamburg (Stanford
> University)"
> + .size _vpaes_consts,.-_vpaes_consts
> + .align 6
> ++
> ++.text
> ++
> + ___
> +
> + {
> +@@ -159,7 +162,8 @@ $code.=<<___;
> + .type _vpaes_encrypt_preheat,%function
> + .align 4
> + _vpaes_encrypt_preheat:
> +-adr x10, .Lk_inv
> ++adrpx10, .Lk_inv
> ++add x10, x10, :lo12:.Lk_inv
> + moviv17.16b, #0x0f
> + ld1 {v18.2d-v19.2d}, [x10],#32 // .Lk_inv
> + ld1 {v20.2
Re: OpenSSL 1.1 arm64 assembly fixes
On Sat, Jan 14, 2023 at 05:41:10PM +0100, Mark Kettenis wrote: > > Date: Sat, 14 Jan 2023 16:56:32 +0100 > > From: Theo Buehler > > > > This is a backport of kettenis's diff. Most of it applied with a few > > offsets. I had to hand-apply two or three hunks due to whitespace noise. > > > > The only real changes are the hunks containing __ILP32__ which were > > needed to make it link. They are part of the diff to OpenSSL 3, which > > came from https://github.com/openssl/openssl/pull/8256 which was never > > backported. > > > > If this goes in, I'll also take care of sslscan similar to postfix. > > > > Tests pass apart from one unrelated failure that has been around for a > > while: > > > > ../test/recipes/90-test_shlibload.t > > Dubious, test returned 9 (wstat 2304, 0x900) > > Failed 9/10 subtests > > Looks good to me. You didn't remove the .LOPENSSL_armcap_P bits > furter up in the files that are part of that __ILP32__ stuff. But > that doesn't really matter. Thanks. I should have mentioned that I left those bits out deliberately to keep the diffs small.
[update] Update repository for devel/luafs
Hi, a little diff to fix repository and homepage for devel/luafs : - Main repo is now https://github.com/lunarmodules/luafilesystem - Homepage is now http://lunarmodules.github.io/luafilesystem/ Build and tests OK on amd64 with luafs-1.8.0p0 package Laurent Index: Makefile === RCS file: /cvs/ports/devel/luafs/Makefile,v retrieving revision 1.29 diff -u -p -r1.29 Makefile --- Makefile 25 Oct 2022 23:31:20 - 1.29 +++ Makefile 14 Jan 2023 17:09:31 - @@ -1,13 +1,14 @@ COMMENT = file system library for the lua language -GH_ACCOUNT = keplerproject +GH_ACCOUNT = lunarmodules GH_PROJECT = luafilesystem GH_TAGNAME = v1_8_0 PKGNAME = luafs-1.8.0 +REVISION = 0 CATEGORIES = devel -HOMEPAGE = http://keplerproject.github.io/luafilesystem/ +HOMEPAGE = http://lunarmodules.github.io/luafilesystem/ # MIT PERMIT_PACKAGE = Yes
Re: [update] www/vaultwarden-web to 2023.1.0
On 1/14/23 11:38, Bjorn Ketelaars wrote:
> On Sat 14/01/2023 08:33, aisha wrote:
>> Hi,
>> I've attached update for www/vaultwarden-web to 2023.1.0.
>>
>> This needs testers as upstream has mentioned "latest version of
>> vaultwarden-web might not always be compatible with latest version of
>> vaultwarden".
>>
>> Moving forward I will try to give these ports some fresh air for a while by
>> letting them sit in the mailing list for a while.
>> Testers would be really appreciated.
> I'm not sure that it makes sense to update www/vaultwarden-web
> independent from security/vaultwarden. Reason is given above ("...might
> not always be compatible..."). Maybe we should follow upstream of
> vaultwarden, and wait with updating www/vaultwarden-web. Docker
> containers of the next release of vaultwarden will use
> vaultwarden-web-2023.1.0 [0].
>
> Do you know what the reason is for having separate ports for
> vaultwarden-web and vaultwarden? What do you think of combining the
> first with the latter? Something similar as what FreeBSD [1] and NetBSD
> [2] seem to do.
There can be multiple versions of the web-vault which are compatible
with the current version of vaultwarden, so keeping it independent makes
it easy to update it separately.
Also the web-vault has had more frequent releases, not always breaking,
mostly bug fixes. So it would be good to have them when possible. It's
rare that the breakage happens but not impossible, so I wanted to get
more testers.
One of the reasons why I initially made it separate was that the web
vault is not developed by vaultwarden themselves, more of a patching of
the upstream bitwarden web vault by removing branding. So I thought it
made more sense to keep them in separate places.
Also didn't want to trigger a build of vaultwarden every time the web
vault got a new release, my build machine is slow and rust is chonky.
Not a big difference imo.
>
> [0]
> https://github.com/dani-garcia/vaultwarden/commit/9b7e86efc23d6bbb5ee350160085ab8d8421d628
> [1]
> https://github.com/freebsd/freebsd-ports/blob/main/security/vaultwarden/Makefile
> [2] https://github.com/NetBSD/pkgsrc/blob/trunk/security/vaultwarden
>
Re: [new] meta/jitsi-1.0 - meta port for jitsi and friends
Moin Aisha, piece of cake! :-) This is all on a fresh VM I just upgraded to latest -current snapshot jitsi# env FETCH_PACKAGES= make build Sat Jan 14 17:12:50 CET 2023 ===> Checking files for jitsi-1.0 >> No DISTFILES nor PATCHFILES. ===> Extracting for jitsi-1.0 ===> Patching for jitsi-1.0 ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Generating configure for jitsi-1.0 ===> Configuring for jitsi-1.0 Unsure if this Error 1 is part of the usual game: itsi# env FETCH_PACKAGES= make package ===> Looking for jitsi-1.0.tgz in $PKG_PATH - file:/usr/ports/packages/amd64/cache/: empty file:/usr/ports/packages/amd64/all/: empty file:/usr/ports/packages/amd64/no-arch/: empty quirks-6.94 signed on 2023-01-13T18:41:27Z Can't find jitsi-1.0.tgz Couldn't install jitsi-1.0 not found *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2129 '/usr/ports/packages/amd64/cache/jitsi-1.0.tgz': @if /usr/bin/env -i PKG_TMP...) ===> Faking installation for jitsi-1.0 /usr/ports/pobj/jitsi-1.0/bin/install -d -m 755 /usr/ports/pobj/jitsi-1.0/fake-amd64/usr/local/share/jitsi/ /usr/bin/perl /usr/ports/infrastructure/bin/pkg_subst -DARCH=amd64 -DBASE_PKGPATH=meta/jitsi -DFLAVOR_EXT= -DFULLPKGNAME=jitsi-1.0 -DHOMEPAGE= -DLOCALBASE=/usr/local -DLOCALSTATEDIR=/var -DMACHINE_ARCH=amd64 -DMAINTAINER=Philipp\ Buehler\ \,\ \ Aisha\ Tammy\ \ -DPREFIX=/usr/ports/pobj/jitsi-1.0/fake-amd64/usr/local -DRCDIR=/etc/rc.d -DSYSCONFDIR=/etc -DTRUEPREFIX=/usr/local -DX11BASE=/usr/X11R6 -DPKGSTEM=jitsi -i -B /usr/ports/pobj/jitsi-1.0 -c -m 644 /usr/ports/meta/jitsi/files/prosody.cfg.lua.sample /usr/ports/pobj/jitsi-1.0/fake-amd64/usr/local/share/jitsi/prosody.cfg.lua.sample /usr/ports/meta/jitsi/files/nginx.conf.sample /usr/ports/pobj/jitsi-1.0/fake-amd64/usr/local/share/jitsi/nginx.conf.sample Installing /usr/ports/meta/jitsi/pkg/README as /usr/ports/pobj/jitsi-1.0/fake-amd64/usr/local/share/doc/pkg-readmes/jitsi ===> Building package for jitsi-1.0 Create /usr/ports/packages/amd64/no-arch/jitsi-1.0.tgz Creating package jitsi-1.0 Link to /usr/ports/packages/amd64/all/jitsi-1.0.tgz Link to /usr/ports/packages/amd64/ftp/jitsi-1.0.tgz The resulting pkg installs fine, including all recursive deps jitsi# export TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all jitsi# pkg_add /usr/ports/packages/amd64/all/jitsi-1.0.tgz quirks-6.94 signed on 2023-01-13T18:41:27Z jitsi-1.0:lua-5.3.6: ok jitsi-1.0:lua53struct-0.3: ok jitsi-1.0:sqlite3-3.39.4: ok jitsi-1.0:lua53dbi-0.7.2: ok jitsi-1.0:lua53fs-1.8.0: ok jitsi-1.0:unzip-6.0p16: ok jitsi-1.0:zip-3.0p1: ok jitsi-1.0:luarocks-lua53-3.9.2: ok jitsi-1.0:libunbound-1.17.0: ok jitsi-1.0:lua53unbound-1.0.0p1: ok jitsi-1.0:lua53socket-3.0rc1p1: ok jitsi-1.0:lua53sec-1.2.0: ok jitsi-1.0:icu4c-72.1v0: ok jitsi-1.0:lua53expat-1.3.0p0: ok jitsi-1.0:prosody-0.12.2: ok jitsi-1.0:jitsi-prosody-plugins-2.0.8044: ok jitsi-1.0:png-1.6.38: ok jitsi-1.0:jpeg-2.1.4v0: ok jitsi-1.0:lz4-1.9.4: ok jitsi-1.0:xz-5.2.9: ok jitsi-1.0:zstd-1.5.2: ok jitsi-1.0:tiff-4.5.0: ok jitsi-1.0:lcms2-2.14: ok jitsi-1.0:lzo2-2.10p2: ok jitsi-1.0:libiconv-1.17: ok jitsi-1.0:gettext-runtime-0.21.1: ok jitsi-1.0:bzip2-1.0.8p0: ok jitsi-1.0:pcre2-10.37p1: ok jitsi-1.0:libffi-3.4.4: ok jitsi-1.0:python-3.10.9p0: ok jitsi-1.0:glib2-2.74.4p1: ok jitsi-1.0:cairo-1.17.6: ok jitsi-1.0:graphite2-1.3.14: ok jitsi-1.0:harfbuzz-6.0.0: ok jitsi-1.0:giflib-5.2.1: ok jitsi-1.0:jdk-11.0.17.8.1v0: ok jitsi-1.0:jitsi-srtp-1.1pl20220605: ok jitsi-1.0:javaPathHelper-2.2: ok jitsi-1.0:jitsi-videobridge-2.0.8044: ok jitsi-1.0:jitsi-meet-1.0.6845: ok jitsi-1.0:jicofo-2.0.8044: ok jitsi-1.0: ok Running tags: ok The following new rcscripts were installed: /etc/rc.d/jicofo /etc/rc.d/jvb /etc/rc.d/prosody See rcctl(8) for details. New and changed readme(s): /usr/local/share/doc/pkg-readmes/glib2 /usr/local/share/doc/pkg-readmes/jdk-11 /usr/local/share/doc/pkg-readmes/jitsi /usr/local/share/doc/pkg-readmes/prosody --- +jdk-11.0.17.8.1v0 --- You may wish to add /usr/local/jdk-11/man to /etc/man.conf --- +luarocks-lua53-3.9.2 --- If you want to use this package as your default luarocks, as root create symbolic links like so (overwriting any previous default): ln -sf /usr/local/bin/luarocks-5.3 /usr/local/bin/luarocks ln -sf /usr/local/bin/luarocks-admin-5.3 /usr/local/bin/luarocks-admin Config and runtime testing tomorrow. On 14.01.23 13:59, aisha wrote: Hi, I've attached the meta port for jitsi, which contains the README for jitsi as well as sample files for nginx and prosody. I've had it running locally for a while and its been working fine. Tests, comments, OKs would be good to have. Cheers, Aisha Best regards -- Philipp Buehler Managing Consultant sysfive.com GmbH Sachsenstrasse 20 D-20097 Hamburg OpenPGP_signature
Re: tor-browser can't see ffmpeg
(sorry, I forgot to break lines) ok, I disabled unveil by renaming all unveil* files and creating new files that contain only "# disable". the issue persists though. another hint: libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's the reason. Jan 13, 2023, 23:55 by : > ok, I disabled unveil by renaming all unveil* files and creating new files > that contain only "# disable". the issue persists though. another hint: > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. those > in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's the > reason. > > Jan 13, 2023, 14:26 by s...@spacehopper.org: > >> On 2023/01/13 13:30, onatinadr...@tutanota.com wrote: >> >>> before installing ffmpeg, both tor-browser and firefox-esr play >>> youtube videos with sound. after installing ffmpeg, firefox-esr >>> plays videos on other sites too but tor-browser does not. it >>> shows a warning that I need to install codecs. I wonder if it's >>> an unveil issue. I would try disabling unveil for tor-browser >>> but I couldn't find any documentation on how to disable unveil >>> >> >> Should be same as firefox, but in /etc/tor-browser instead. >>
Re: tor-browser can't see ffmpeg
At some point you have to realize two things - the restrictions we added to browsers inside are *intentional* to reduce access outside of their general usage, in particular restrictions inside your home directory - But some libraries and applications you are trying to use are designed to violate those principles *intentionally*, because they are written by people on other operating systems, and they either believe they should have access to everything, or they are written to inadvertently access such things. So these principles are incompatible. Sometimes a middle ground can be reached, but there are so many of these circumstances that it is likely that all the possible use cases will never be satisfied. So it is a huge amount of developer time being spent _for the atypical user_. So, have you considered using Linux instead? And I'm really not joking. I'm very serious. That is a system, like Windows, bending over backwards to ensure that applications can do anything they want inside your home directory. It's so bizzare. You are disabling one type of security to gain what you believe is another type of security, hammering nails you do not know. Do you not sense the dissonance? onatinadr...@tutanota.com wrote: > > > (sorry, I forgot to break lines) > > ok, I disabled unveil by renaming all unveil* files and creating new files > that contain only "# disable". the issue persists though. another hint: > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. > those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe > that's the reason. > > Jan 13, 2023, 23:55 by : > > > ok, I disabled unveil by renaming all unveil* files and creating new files > > that contain only "# disable". the issue persists though. another hint: > > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. > > those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's > > the reason. > > > > Jan 13, 2023, 14:26 by s...@spacehopper.org: > > > >> On 2023/01/13 13:30, onatinadr...@tutanota.com wrote: > >> > >>> before installing ffmpeg, both tor-browser and firefox-esr play > >>> youtube videos with sound. after installing ffmpeg, firefox-esr > >>> plays videos on other sites too but tor-browser does not. it > >>> shows a warning that I need to install codecs. I wonder if it's > >>> an unveil issue. I would try disabling unveil for tor-browser > >>> but I couldn't find any documentation on how to disable unveil > >>> > >> > >> Should be same as firefox, but in /etc/tor-browser instead. > >> >
Re: tor-browser can't see ffmpeg
I have no intention to disable unveil permanently. I was just trying to solve a bug. When I saw that it didn't work, I enabled it again. Yes, I considered using linux. I give it a go from time to time. It gets worse every time. It moves away from unix philosophy. I don't like it. If I could, I would use plan9 (joking). OpenBSD does not currently support the wifi chip on my laptop and the touchpad freezes after a while. But I plug in a dongle and a USB mouse and continue using OpenBSD. Thank you all for this great operating system. Jan 14, 2023, 18:04 by dera...@openbsd.org: > At some point you have to realize two things > > - the restrictions we added to browsers inside are *intentional* > to reduce access outside of their general usage, in particular > restrictions inside your home directory > > - But some libraries and applications you are trying to use are > designed to violate those principles *intentionally*, because > they are written by people on other operating systems, and they > either believe they should have access to everything, or they are > written to inadvertently access such things. > > So these principles are incompatible. > > Sometimes a middle ground can be reached, but there are so many of these > circumstances that it is likely that all the possible use cases will > never be satisfied. So it is a huge amount of developer time being > spent _for the atypical user_. > > So, have you considered using Linux instead? And I'm really not joking. > I'm very serious. That is a system, like Windows, bending over backwards to > ensure that applications can do anything they want inside your home > directory. > > It's so bizzare. You are disabling one type of security to gain what > you believe is another type of security, hammering nails you do not know. > > Do you not sense the dissonance? > > onatinadr...@tutanota.com wrote: > >> >> >> (sorry, I forgot to break lines) >> >> ok, I disabled unveil by renaming all unveil* files and creating new files >> that contain only "# disable". the issue persists though. another hint: >> libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. >> those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe >> that's the reason. >> >> Jan 13, 2023, 23:55 by : >> >> > ok, I disabled unveil by renaming all unveil* files and creating new files >> > that contain only "# disable". the issue persists though. another hint: >> > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. >> > those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's >> > the reason. >> > >> > Jan 13, 2023, 14:26 by s...@spacehopper.org: >> > >> >> On 2023/01/13 13:30, onatinadr...@tutanota.com wrote: >> >> >> >>> before installing ffmpeg, both tor-browser and firefox-esr play >> >>> youtube videos with sound. after installing ffmpeg, firefox-esr >> >>> plays videos on other sites too but tor-browser does not. it >> >>> shows a warning that I need to install codecs. I wonder if it's >> >>> an unveil issue. I would try disabling unveil for tor-browser >> >>> but I couldn't find any documentation on how to disable unveil >> >>> >> >> >> >> Should be same as firefox, but in /etc/tor-browser instead. >> >> >>
Re: tor-browser can't see ffmpeg
onatinadr...@tutanota.com wrote: > I have no intention to disable unveil permanently. I was just trying > to solve a bug. But it does not solve a bug. It does not even identify the bugs. If you really wanted to try to act like a developer, you would grab a huge piece of disk and ktrace -di the browser. I have also edited source code to add utrace() calls so I can identify the chunks of code I am in, when reading the ktrace output. Disabling unveil and pledge is going to provide you with no insight you can follow. When I saw that it didn't work, I enabled it again. > Yes, I considered using linux. I give it a go from time to time. It gets > worse every time. It moves away from unix philosophy. I don't like > it. If I could, I would use plan9 (joking). OpenBSD does not currently > support the wifi chip on my laptop and the touchpad freezes after > a while. But I plug in a dongle and a USB mouse and continue > using OpenBSD. Thank you all for this great operating system. > > Jan 14, 2023, 18:04 by dera...@openbsd.org: > > At some point you have to realize two things > > - the restrictions we added to browsers inside are *intentional* > to reduce access outside of their general usage, in particular > restrictions inside your home directory > > - But some libraries and applications you are trying to use are > designed to violate those principles *intentionally*, because > they are written by people on other operating systems, and they > either believe they should have access to everything, or they are > written to inadvertently access such things. > > So these principles are incompatible. > > Sometimes a middle ground can be reached, but there are so many of these > circumstances that it is likely that all the possible use cases will > never be satisfied. So it is a huge amount of developer time being > spent _for the atypical user_. > > So, have you considered using Linux instead? And I'm really not joking. > I'm very serious. That is a system, like Windows, bending over backwards to > ensure that applications can do anything they want inside your home > directory. > > It's so bizzare. You are disabling one type of security to gain what > you believe is another type of security, hammering nails you do not know. > > Do you not sense the dissonance? > > onatinadr...@tutanota.com wrote: > > (sorry, I forgot to break lines) > > ok, I disabled unveil by renaming all unveil* files and creating new files > that contain only "# disable". the issue persists though. another hint: > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. > those in /usr/local/lib/firefox-esr, have the extension 9.0. maybe > that's the reason. > > Jan 13, 2023, 23:55 by : > > > ok, I disabled unveil by renaming all unveil* files and creating new files > that contain only "# disable". the issue persists though. another hint: > libmozav* files in /usr/local/lib/tor-browser have the extension .7.0. those > in /usr/local/lib/firefox-esr, have the extension 9.0. maybe that's the > reason. > > > > Jan 13, 2023, 14:26 by s...@spacehopper.org: > > > >> On 2023/01/13 13:30, onatinadr...@tutanota.com wrote: > >> > >>> before installing ffmpeg, both tor-browser and firefox-esr play > >>> youtube videos with sound. after installing ffmpeg, firefox-esr > >>> plays videos on other sites too but tor-browser does not. it > >>> shows a warning that I need to install codecs. I wonder if it's > >>> an unveil issue. I would try disabling unveil for tor-browser > >>> but I couldn't find any documentation on how to disable unveil > >>> > >> > >> Should be same as firefox, but in /etc/tor-browser instead. > >> >
new: fonts/nerd-fonts/nerdfontssymbolsonly
I thought I would share this with anyone who might be interested. I notice that there are a few of the patched "Nerd Fonts" already in ports, but there are some programs (like x11/kitty) which can pick up symbols automagically from this font without requiring patched fonts. I've been using this for the past couple of days and, while not perfect, works well enough. Diff for nerd-fonts/Makefile is below, tarball for nerd-fonts/nerdfontssymbolsonly is attached. -- Ariel Index: Makefile === RCS file: /cvs/ports/fonts/nerd-fonts/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile31 Dec 2022 10:02:54 - 1.1.1.1 +++ Makefile14 Jan 2023 18:40:22 - @@ -2,6 +2,7 @@ SUBDIR += codenewroman SUBDIR += dejavusansmono SUBDIR += fantasquesansmono +SUBDIR += nerdfontssymbolsonly SUBDIR += noto SUBDIR += profont SUBDIR += terminus nerdfontssymbolsonly.tgz Description: application/compressed-tar
libgcrypt: arm64 assembly fixes
This moves constants from .text into .rodata.
All tests pass, gnupg tests work, gpgme and gcr build.
Index: Makefile
===
RCS file: /cvs/ports/security/libgcrypt/Makefile,v
retrieving revision 1.81
diff -u -p -r1.81 Makefile
--- Makefile9 Jan 2023 17:27:49 - 1.81
+++ Makefile14 Jan 2023 19:53:18 -
@@ -1,7 +1,7 @@
COMMENT= crypto library based on code used in GnuPG
DISTNAME= libgcrypt-1.10.1
-REVISION= 1
+REVISION= 2
CATEGORIES=security
SHARED_LIBS += gcrypt 21.0 # 24.1
@@ -23,7 +23,9 @@ CONFIGURE_STYLE= gnu
CONFIGURE_ARGS=--enable-static \
--disable-drng-support
+.if ${MACHINE_ARCH} != aarch64
USE_NOEXECONLY=Yes
+.endif
DEBUG_PACKAGES=${BUILD_PACKAGES}
Index: patches/patch-cipher_camellia-aarch64_S
===
RCS file: patches/patch-cipher_camellia-aarch64_S
diff -N patches/patch-cipher_camellia-aarch64_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_camellia-aarch64_S 14 Jan 2023 19:44:18 -
@@ -0,0 +1,11 @@
+Index: cipher/camellia-aarch64.S
+--- cipher/camellia-aarch64.S.orig
cipher/camellia-aarch64.S
+@@ -313,6 +313,7 @@ _gcry_camellia_arm_decrypt_block:
+ .ltorg
+ ELF(.size
_gcry_camellia_arm_decrypt_block,.-_gcry_camellia_arm_decrypt_block;)
+
++.rodata
+ /* Encryption/Decryption tables */
+ ELF(.type _gcry_camellia_arm_tables,@object;)
+ .balign 32
Index: patches/patch-cipher_chacha20-aarch64_S
===
RCS file: patches/patch-cipher_chacha20-aarch64_S
diff -N patches/patch-cipher_chacha20-aarch64_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_chacha20-aarch64_S 14 Jan 2023 19:44:25 -
@@ -0,0 +1,21 @@
+Index: cipher/chacha20-aarch64.S
+--- cipher/chacha20-aarch64.S.orig
cipher/chacha20-aarch64.S
+@@ -36,7 +36,7 @@
+
+ .cpu generic+simd
+
+-.text
++.rodata
+
+ #include "asm-poly1305-aarch64.h"
+
+@@ -192,6 +192,8 @@ _gcry_chacha20_aarch64_blocks4_data_rot8:
+ .byte 7,4,5,6
+ .byte 11,8,9,10
+ .byte 15,12,13,14
++
++.text
+
+ .align 3
+ .globl _gcry_chacha20_aarch64_blocks4
Index: patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S
===
RCS file: patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S
diff -N patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S 14 Jan 2023 19:27:48
-
@@ -0,0 +1,21 @@
+Index: cipher/cipher-gcm-armv8-aarch64-ce.S
+--- cipher/cipher-gcm-armv8-aarch64-ce.S.orig
cipher/cipher-gcm-armv8-aarch64-ce.S
+@@ -25,7 +25,7 @@
+
+ .cpu generic+simd+crypto
+
+-.text
++.rodata
+
+
+ /* Constants */
+@@ -170,6 +170,8 @@ gcry_gcm_reduction_constant:
+ CFI_ADJUST_CFA_OFFSET(-16); \
+ ldp d8, d9, [sp], #16; \
+ CFI_ADJUST_CFA_OFFSET(-16);
++
++.text
+
+ /*
+ * unsigned int _gcry_ghash_armv8_ce_pmull (void *gcm_key, byte *result,
Index: patches/patch-cipher_crc-armv8-aarch64-ce_S
===
RCS file: patches/patch-cipher_crc-armv8-aarch64-ce_S
diff -N patches/patch-cipher_crc-armv8-aarch64-ce_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_crc-armv8-aarch64-ce_S 14 Jan 2023 19:18:35 -
@@ -0,0 +1,20 @@
+Index: cipher/crc-armv8-aarch64-ce.S
+--- cipher/crc-armv8-aarch64-ce.S.orig
cipher/crc-armv8-aarch64-ce.S
+@@ -25,7 +25,7 @@
+
+ .cpu generic+simd+crypto
+
+-.text
++.rodata
+
+
+ /* Structure of crc32_consts_s */
+@@ -54,6 +54,7 @@
+ .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+ .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+
++.text
+
+ /*
+ * void _gcry_crc32r_armv8_ce_bulk (u32 *pcrc, const byte *inbuf, size_t
inlen,
Index: patches/patch-cipher_sha1-armv8-aarch64-ce_S
===
RCS file: patches/patch-cipher_sha1-armv8-aarch64-ce_S
diff -N patches/patch-cipher_sha1-armv8-aarch64-ce_S
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cipher_sha1-armv8-aarch64-ce_S14 Jan 2023 19:25:39
-
@@ -0,0 +1,20 @@
+Index: cipher/sha1-armv8-aarch64-ce.S
+--- cipher/sha1-armv8-aarch64-ce.S.orig
cipher/sha1-armv8-aarch64-ce.S
+@@ -25,7 +25,7 @@
+
+ .cpu generic+simd+crypto
+
+-.text
++.rodata
+
+
+ /* Constants */
+@@ -90,6 +90,7 @@ gcry_sha1_aarch64_ce_K_VEC:
+
+ #define CLEAR_REG(reg) movi reg.16b, #0;
+
++.text
+
+ /*
+ * unsigned int
Index: patches/patch-cipher_sha256-armv8-aarch64-ce_S
===
RCS file: patches/patch-cipher_sha256-armv8-aarch64-ce_S
diff -N patches/patch-cipher_s
Re: [update] www/vaultwarden-web to 2023.1.0
On Sat 14/01/2023 12:26, A Tammy wrote:
> There can be multiple versions of the web-vault which are compatible
> with the current version of vaultwarden, so keeping it independent makes
> it easy to update it separately.
>
> Also the web-vault has had more frequent releases, not always breaking,
> mostly bug fixes. So it would be good to have them when possible. It's
> rare that the breakage happens but not impossible, so I wanted to get
> more testers.
>
> One of the reasons why I initially made it separate was that the web
> vault is not developed by vaultwarden themselves, more of a patching of
> the upstream bitwarden web vault by removing branding. So I thought it
> made more sense to keep them in separate places.
>
> Also didn't want to trigger a build of vaultwarden every time the web
> vault got a new release, my build machine is slow and rust is chonky.
>
> Not a big difference imo.
Clear, I understand your reasoning.
I forgot to enclose the diff below in my initial mail. I enclosed it
with this mail for reference purposes only. Maybe it helps, should the
world change. For now just ignore it.
diff --git devel/quirks/Makefile devel/quirks/Makefile
index 24ed8fb0eea..39d25bcc0d1 100644
--- devel/quirks/Makefile
+++ devel/quirks/Makefile
@@ -3,7 +3,7 @@ CATEGORIES =devel databases
DISTFILES =
# API.rev
-PKGNAME = quirks-6.94
+PKGNAME = quirks-6.95
PKG_ARCH = *
MAINTAINER = Marc Espie
diff --git devel/quirks/files/Quirks.pm devel/quirks/files/Quirks.pm
index e7b4791a99d..2af777d4b90 100644
--- devel/quirks/files/Quirks.pm
+++ devel/quirks/files/Quirks.pm
@@ -763,6 +763,7 @@ my $stem_extensions = {
'py-nose' => 'py3-nose',
'py-xdg' => 'py3-xdg',
'i3-gaps' => 'i3',
+ 'vaultwarden-web' => 'vaultwarden',
};
my $obsolete_reason = {};
diff --git security/vaultwarden/Makefile security/vaultwarden/Makefile
index 961316f00e7..c5900cf95aa 100644
--- security/vaultwarden/Makefile
+++ security/vaultwarden/Makefile
@@ -8,6 +8,9 @@ COMMENT = unofficial bitwarden compatible server
GH_ACCOUNT = dani-garcia
GH_PROJECT = vaultwarden
GH_TAGNAME = 1.27.0
+REVISION = 0
+
+VERSION-webvault = 2022.12.0
CATEGORIES = security
@@ -21,8 +24,10 @@ FLAVOR ?=
WANTLIB += c c++abi crypto m pthread ssl
+MASTER_SITES0 =
https://github.com/dani-garcia/bw_web_builds/releases/download/v${VERSION-webvault}/
MASTER_SITES7 =https://files.bsd.ac/openbsd-distfiles/
-DISTFILES += vaultwarden-deps-${GH_TAGNAME}.tgz:7
+DISTFILES += bw_web_v${VERSION-webvault}${EXTRACT_SUFX}:0 \
+ vaultwarden-deps-${GH_TAGNAME}.tgz:7
# as devel/cargo MODULES adds DISTFILES, GH_* didn't
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
@@ -33,8 +38,6 @@ CONFIGURE_STYLE = cargo
SEPARATE_BUILD = Yes
-RUN_DEPENDS = www/vaultwarden-web
-
MODCARGO_CRATES_KEEP +=libsqlite3-sys
MODCARGO_FEATURES =sqlite
.if ${FLAVOR:Mmysql}
@@ -56,9 +59,10 @@ post-configure:
cat ${WRKDIR}/config.vendor >> ${WRKDIR}/.cargo/config
do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/vaultwarden
- ${INSTALL_DATA} ${WRKSRC}/.env.template ${PREFIX}/share/doc/vaultwarden
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/vaultwarden
+ ${INSTALL_DATA} ${WRKSRC}/.env.template ${PREFIX}/share/vaultwarden
${INSTALL_PROGRAM} ${MODCARGO_TARGET_DIR}/release/vaultwarden
${PREFIX}/bin/
+ cp -Rp ${WRKDIR}/web-vault ${PREFIX}/share/vaultwarden
.include "crates.inc"
diff --git security/vaultwarden/distinfo security/vaultwarden/distinfo
index 92ce9348d72..3afb7a79e0f 100644
--- security/vaultwarden/distinfo
+++ security/vaultwarden/distinfo
@@ -1,3 +1,4 @@
+SHA256 (bw_web_v2022.12.0.tar.gz) =
QC3/aqIF2NdJPHmwUbvJR62wsUGBrgsHJCyqBJ/0gMc=
SHA256 (cargo/addr2line-0.19.0.tar.gz) =
p2/WCyNnm30ZvQZgMUEPt+RYzMXpWOtcMliIzkuu3Jc=
SHA256 (cargo/adler-1.0.2.tar.gz) =
8mIBYEyHseAb09mPjV2aj8u4FejO20H/zL60v1k6Nf4=
SHA256 (cargo/aead-0.5.1.tar.gz) = XBkuuPEfwIGw/kJZulrwQhfU4Prd0CQXMQqSeRGr18g=
@@ -355,6 +356,7 @@ SHA256 (cargo/yansi-0.5.1.tar.gz) =
CQQc2Qz4X3+LLfYMZG+FO39TXOaPhSROtnMc+J+kmOw=
SHA256 (cargo/yubico-0.11.0.tar.gz) =
Fz910sQBBCmi10rjoRSmmTDFnisaTJexx10lmklg1fs=
SHA256 (vaultwarden-1.27.0.tar.gz) =
13F9OjU7cmJt5tby3B53drQLSH3IE3WfvNgSxwnKvNg=
SHA256 (vaultwarden-deps-1.27.0.tgz) =
s3kuDsDvMDQA2htgwfzzv3xLaZPDu2vPyUpQBK15vjI=
+SIZE (bw_web_v2022.12.0.tar.gz) = 9299031
SIZE (cargo/addr2line-0.19.0.tar.gz) = 33210
SIZE (cargo/adler-1.0.2.tar.gz) = 12778
SIZE (cargo/aead-0.5.1.tar.gz) = 15474
diff --git security/vaultwarden/pkg/PLIST security/vaultwarden/pkg/PLIST
index 8c7e3a33812..949cd8288dc 100644
--- security/vaultwarden/pkg/PLIST
+++ security/vaultwarden/pkg/PLIST
@@ -1,12 +1,305 @@
+@pkgpath www/vaultwarden-web
@newgroup _vaultwarden:879
@newuser _vaultwarden:879:879:
Re: libgcrypt: arm64 assembly fixes
> Date: Sat, 14 Jan 2023 21:08:38 +0100
> From: Theo Buehler
>
> This moves constants from .text into .rodata.
>
> All tests pass, gnupg tests work, gpgme and gcr build.
Right, and then the idiots did this:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=fd02e8e78470deb661269c429f3348f811c054c6
so future versions will need furher patching. At least they used a
macro, so it is relatively easy to revert.
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/libgcrypt/Makefile,v
> retrieving revision 1.81
> diff -u -p -r1.81 Makefile
> --- Makefile 9 Jan 2023 17:27:49 - 1.81
> +++ Makefile 14 Jan 2023 19:53:18 -
> @@ -1,7 +1,7 @@
> COMMENT= crypto library based on code used in GnuPG
>
> DISTNAME=libgcrypt-1.10.1
> -REVISION=1
> +REVISION=2
> CATEGORIES= security
>
> SHARED_LIBS += gcrypt 21.0 # 24.1
> @@ -23,7 +23,9 @@ CONFIGURE_STYLE=gnu
> CONFIGURE_ARGS= --enable-static \
> --disable-drng-support
>
> +.if ${MACHINE_ARCH} != aarch64
> USE_NOEXECONLY= Yes
> +.endif
>
> DEBUG_PACKAGES= ${BUILD_PACKAGES}
>
> Index: patches/patch-cipher_camellia-aarch64_S
> ===
> RCS file: patches/patch-cipher_camellia-aarch64_S
> diff -N patches/patch-cipher_camellia-aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-cipher_camellia-aarch64_S 14 Jan 2023 19:44:18 -
> @@ -0,0 +1,11 @@
> +Index: cipher/camellia-aarch64.S
> +--- cipher/camellia-aarch64.S.orig
> cipher/camellia-aarch64.S
> +@@ -313,6 +313,7 @@ _gcry_camellia_arm_decrypt_block:
> + .ltorg
> + ELF(.size
> _gcry_camellia_arm_decrypt_block,.-_gcry_camellia_arm_decrypt_block;)
> +
> ++.rodata
> + /* Encryption/Decryption tables */
> + ELF(.type _gcry_camellia_arm_tables,@object;)
> + .balign 32
> Index: patches/patch-cipher_chacha20-aarch64_S
> ===
> RCS file: patches/patch-cipher_chacha20-aarch64_S
> diff -N patches/patch-cipher_chacha20-aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-cipher_chacha20-aarch64_S 14 Jan 2023 19:44:25 -
> @@ -0,0 +1,21 @@
> +Index: cipher/chacha20-aarch64.S
> +--- cipher/chacha20-aarch64.S.orig
> cipher/chacha20-aarch64.S
> +@@ -36,7 +36,7 @@
> +
> + .cpu generic+simd
> +
> +-.text
> ++.rodata
> +
> + #include "asm-poly1305-aarch64.h"
> +
> +@@ -192,6 +192,8 @@ _gcry_chacha20_aarch64_blocks4_data_rot8:
> + .byte 7,4,5,6
> + .byte 11,8,9,10
> + .byte 15,12,13,14
> ++
> ++.text
> +
> + .align 3
> + .globl _gcry_chacha20_aarch64_blocks4
> Index: patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S
> ===
> RCS file: patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S
> diff -N patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-cipher_cipher-gcm-armv8-aarch64-ce_S14 Jan 2023
> 19:27:48 -
> @@ -0,0 +1,21 @@
> +Index: cipher/cipher-gcm-armv8-aarch64-ce.S
> +--- cipher/cipher-gcm-armv8-aarch64-ce.S.orig
> cipher/cipher-gcm-armv8-aarch64-ce.S
> +@@ -25,7 +25,7 @@
> +
> + .cpu generic+simd+crypto
> +
> +-.text
> ++.rodata
> +
> +
> + /* Constants */
> +@@ -170,6 +170,8 @@ gcry_gcm_reduction_constant:
> + CFI_ADJUST_CFA_OFFSET(-16); \
> + ldp d8, d9, [sp], #16; \
> + CFI_ADJUST_CFA_OFFSET(-16);
> ++
> ++.text
> +
> + /*
> + * unsigned int _gcry_ghash_armv8_ce_pmull (void *gcm_key, byte *result,
> Index: patches/patch-cipher_crc-armv8-aarch64-ce_S
> ===
> RCS file: patches/patch-cipher_crc-armv8-aarch64-ce_S
> diff -N patches/patch-cipher_crc-armv8-aarch64-ce_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-cipher_crc-armv8-aarch64-ce_S 14 Jan 2023 19:18:35
> -
> @@ -0,0 +1,20 @@
> +Index: cipher/crc-armv8-aarch64-ce.S
> +--- cipher/crc-armv8-aarch64-ce.S.orig
> cipher/crc-armv8-aarch64-ce.S
> +@@ -25,7 +25,7 @@
> +
> + .cpu generic+simd+crypto
> +
> +-.text
> ++.rodata
> +
> +
> + /* Structure of crc32_consts_s */
> +@@ -54,6 +54,7 @@
> + .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
> + .byte 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
> +
> ++.text
> +
> + /*
> + * void _gcry_crc32r_armv8_ce_bulk (u32 *pcrc, const byte *inbuf, size_t
> inlen,
> Index: patches/patch-cipher_sha1-armv8-aarch64-ce_S
> ===
> RCS file: patches/patch-cipher_sha1-armv8-aarch64-ce_S
> diff -N patches/patch-cipher_sha1-armv8-aarch64-ce_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-cipher_sha1-armv8-aarch64-ce_S 14 Jan 2023 19:25:39
Re: UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
On 23/01/07 00:20, Ashlen wrote: > As for the renaming thing, I realized I didn't actually provide any links > showing why I kept this in. I looked at the commits and it appears their > rationale is that anyone that writes a Lua script and imports luasocket as > well > as another module that happens to have an identical buffer_* will have a > headache due to name collisions. Though if that's the case, it makes me wonder > why FreeBSD backed out the patch in the commit op@ mentioned. > > https://cvsweb.openbsd.org/ports/net/luasocket/patches/patch-src_buffer_c?rev=1.2&content-type=text/x-cvsweb-markup > https://marc.info/?l=freebsd-ports-bugs&m=125089202109336&w=2 > https://marc.info/?l=freebsd-ports&m=125097467421558&w=2 Hey Robert, I CC'ed you because I need to ask you something. You were originally the person who made patches renaming 'buffer_*' to 'ls_buffer_*' in net/luasocket due to them creating a namespace clash with other ports. I know this was all the way back in 2009, but can you let me know if changing those is still necessary? I'm guessing the answer is yes, but I wanted to double check to make sure since there was some discussion about it earlier. I meant to test it myself and therefore avoid bothering you, but it's been a week and I'm realizing I'm not going to get to it in a timely manner (I don't know how to write in Lua yet). (Side note for the other people in the thread: testing against those two other ports is on my TODO list. Life has just been crazy lately and it's been a struggle to get organized again... sorry for the delay on that)
Re: [update] Update repository for devel/luafs
On 1/14/23 12:19, Laurent Cheylus wrote: > Hi, > > a little diff to fix repository and homepage for devel/luafs : > > - Main repo is now https://github.com/lunarmodules/luafilesystem > - Homepage is now http://lunarmodules.github.io/luafilesystem/ > > Build and tests OK on amd64 with luafs-1.8.0p0 package > > Laurent > ok aisha
[update] i2pd-2.45.1
Hi, Here's an update for i2pd. This is a bugfix release. Changelog : https://github.com/PurpleI2P/i2pd/releases/tag/2.45.1 Cheers, GanymedeIndex: Makefile === RCS file: /cvs/ports/net/i2pd/Makefile,v retrieving revision 1.14 diff -u -p -r1.14 Makefile --- Makefile 8 Jan 2023 21:29:06 - 1.14 +++ Makefile 13 Jan 2023 14:00:55 - @@ -2,7 +2,7 @@ COMMENT = client for the I2P anonymous n GH_ACCOUNT = PurpleI2P GH_PROJECT = i2pd -GH_TAGNAME = 2.45.0 +GH_TAGNAME = 2.45.1 CATEGORIES = net HOMEPAGE = https://i2pd.website Index: distinfo === RCS file: /cvs/ports/net/i2pd/distinfo,v retrieving revision 1.9 diff -u -p -r1.9 distinfo --- distinfo 8 Jan 2023 21:29:06 - 1.9 +++ distinfo 13 Jan 2023 14:00:55 - @@ -1,2 +1,2 @@ -SHA256 (i2pd-2.45.0.tar.gz) = QFDAo4/aBqdt770nIfRo9bCYie17a1p+IH5GWdMAc48= -SIZE (i2pd-2.45.0.tar.gz) = 630600 +SHA256 (i2pd-2.45.1.tar.gz) = qEsePLWsRfOa+Y5jKR00cl72czfhGsvg4kWs3npbK3I= +SIZE (i2pd-2.45.1.tar.gz) = 631280
[update] www/libreddit to 0.27.1
Hello, Here's an update for libreddit that's been working fine with my instance. changelog: Bugfix: 'all posts are hidden because NSFW' Search - add support for raw reddit links fix a11y and HTML issues on settings page build: enable LTO and strip the binary Link to libreddit/libreddit and open in new tab Landing page for NSFW content, SFW-only mode Add config system to read from file Remove unused dep "async-recursion" Add hide_awards config option Theme browser scrollbar Mark search query as safe in askama template config: fix SFW test Bump tokio from 1.23.0 to 1.23.1 Make CLI args have higher precedence than env vars Create rust-tests.yml https://github.com/libreddit/libreddit/compare/v0.25.1...v0.27.1 Thanks, Lucas diff refs/heads/master refs/heads/libreddit commit - 5eee03e8a0ff1ef5637f6309e0c0ef986fbfaeb3 commit + f1e91e074c631b4c56f061232458088665a41d2e blob - 9f58309114faf7206be3c943f9770a04430f443e blob + c50fd47f67901b6be2636e408414fec0265c592c --- www/libreddit/Makefile +++ www/libreddit/Makefile @@ -5,7 +5,7 @@ GH_TAGNAME =v0.25.1 GH_ACCOUNT = libreddit GH_PROJECT = libreddit -GH_TAGNAME = v0.25.1 +GH_TAGNAME = v0.27.1 CATEGORIES = www blob - df27de2d3bc9af446a01f6b7ed29008ab65b07c1 blob + cccb2eb7b63581eed1c732dcf83deedc51fdb9ec --- www/libreddit/crates.inc +++ www/libreddit/crates.inc @@ -1,13 +1,12 @@ MODCARGO_CRATES += adler32 1.2.0 # Zlib -MODCARGO_CRATES += aho-corasick0.7.19 # Unlicense/MIT +MODCARGO_CRATES += aho-corasick0.7.20 # Unlicense OR MIT MODCARGO_CRATES += alloc-no-stdlib 2.0.4 # BSD-3-Clause MODCARGO_CRATES += alloc-stdlib0.2.2 # BSD-3-Clause MODCARGO_CRATES += askama 0.11.1 # MIT OR Apache-2.0 MODCARGO_CRATES += askama_derive 0.11.2 # MIT/Apache-2.0 MODCARGO_CRATES += askama_escape 0.10.3 # MIT OR Apache-2.0 MODCARGO_CRATES += askama_shared 0.12.2 # MIT/Apache-2.0 -MODCARGO_CRATES += async-recursion 1.0.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += async-trait 0.1.58 # MIT OR Apache-2.0 +MODCARGO_CRATES += async-trait 0.1.59 # MIT OR Apache-2.0 MODCARGO_CRATES += async_once 0.2.6 # MIT OR Apache-2.0 MODCARGO_CRATES += autocfg 1.1.0 # Apache-2.0 OR MIT MODCARGO_CRATES += base64 0.13.1 # MIT/Apache-2.0 @@ -17,13 +16,13 @@ MODCARGO_CRATES += bytes 1.2.1 # MIT MODCARGO_CRATES += brotli-decompressor 2.3.2 # BSD-3-Clause/MIT MODCARGO_CRATES += bstr0.2.17 # MIT OR Apache-2.0 MODCARGO_CRATES += bumpalo 3.11.1 # MIT/Apache-2.0 -MODCARGO_CRATES += bytes 1.2.1 # MIT +MODCARGO_CRATES += bytes 1.3.0 # MIT MODCARGO_CRATES += cached 0.40.0 # MIT MODCARGO_CRATES += cached_proc_macro 0.15.0 # MIT MODCARGO_CRATES += cached_proc_macro_types 0.1.0 # MIT -MODCARGO_CRATES += cc 1.0.76 # MIT OR Apache-2.0 +MODCARGO_CRATES += cc 1.0.77 # MIT OR Apache-2.0 MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0 -MODCARGO_CRATES += clap4.0.24 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap4.0.29 # MIT OR Apache-2.0 MODCARGO_CRATES += clap_lex0.3.0 # MIT OR Apache-2.0 MODCARGO_CRATES += cookie 0.16.1 # MIT OR Apache-2.0 MODCARGO_CRATES += core-foundation 0.9.3 # MIT / Apache-2.0 @@ -34,10 +33,11 @@ MODCARGO_CRATES += digest 0.10.5 # MIT OR Apache-2.0 MODCARGO_CRATES += darling 0.13.4 # MIT MODCARGO_CRATES += darling_core0.13.4 # MIT MODCARGO_CRATES += darling_macro 0.13.4 # MIT -MODCARGO_CRATES += digest 0.10.5 # MIT OR Apache-2.0 +MODCARGO_CRATES += digest 0.10.6 # MIT OR Apache-2.0 MODCARGO_CRATES += fastrand1.8.0 # Apache-2.0 OR MIT MODCARGO_CRATES += fnv 1.0.7 # Apache-2.0 / MIT MODCARGO_CRATES += form_urlencoded 1.1.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += fs_extra1.2.0 # MIT MODCARGO_CRATES += futures 0.3.25 # MIT OR Apache-2.0 MODCARGO_CRATES += futures-channel 0.3.25 # MIT OR Apache-2.0 MODCARGO_CRATES += futures-core0.3.25 # MIT OR Apache-2.0 @@ -57,15 +57,15 @@ MODCARGO_CRATES += hyper-rustls0.23.0 # Apache-2.0/IS MODCARGO_CRATES += httparse1.8.0 # MIT/Apache-2.0 MODCARGO_CRATES += httpdate1.0.2 # MIT/Apache-2.0 MODCARGO_CRATES += hyper 0.14.23 # MIT -MODCARGO_CRATES += hyper-rustls0.23.0 # Apache-2.0/ISC/MIT +MODCARGO_CRATES += hyper-rustls0.23.2 # Apache-2.0/ISC/MIT MODCARGO_CRATES += ident_case 1.0.1 # MIT/Apache-2.0 MODCARGO_CRATES += idna0.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += indexmap1.9.1 # Apache-2.0 OR MIT +MODCARGO_CRATES += indexmap1.9.2 # Apache-2.0 OR MIT MODCARGO_CRATES += instant 0.1.12 # BSD-3-Clause MODCARGO_CRATES += itoa1.0.4 # MIT OR Apache-2.0 MODCARGO_CRATES += js-sys 0.3.60 # MIT/Apache-2.0 MODCARGO_CRATES += lazy_static 1.4.0 # MI
Re: [update] net/knot net/py-libknot to 3.2.4
On Sat, Jan 14 2023, aisha wrote: > Hi, > I've attached updates for both knot and py-libknot to 3.2.4. > No major changes in net/knot, no new symbols in library. > py-libknot has additional functionality added but its a ctypes library, so > the update patch is trivial. > > Working fine for me, ok? LGTM. make configure before/after only show one additional check: +checking for stdatomic.h... yes I would suggest that you take maintainer alone as you're doing all the work and I don't use knot. ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [update] Update repository for devel/luafs
On 1/14/23 16:52, A Tammy wrote: > > On 1/14/23 12:19, Laurent Cheylus wrote: >> Hi, >> >> a little diff to fix repository and homepage for devel/luafs : >> >> - Main repo is now https://github.com/lunarmodules/luafilesystem >> - Homepage is now http://lunarmodules.github.io/luafilesystem/ >> >> Build and tests OK on amd64 with luafs-1.8.0p0 package >> >> Laurent >> > ok aisha > committed, thanks for the patch :)
Re: [update] net/knot net/py-libknot to 3.2.4
On 1/14/23 17:57, Jeremie Courreges-Anglas wrote: > On Sat, Jan 14 2023, aisha wrote: >> Hi, >> I've attached updates for both knot and py-libknot to 3.2.4. >> No major changes in net/knot, no new symbols in library. >> py-libknot has additional functionality added but its a ctypes library, so >> the update patch is trivial. >> >> Working fine for me, ok? > LGTM. make configure before/after only show one additional check: > > +checking for stdatomic.h... yes > > I would suggest that you take maintainer alone as you're doing all the > work and I don't use knot. haha, will do next bump :D > ok jca@ >
Re: [NEW] audio/alsa-lib-1.2.8
Hi,
> Let's keep it simple like:
> /usr/local/lib/alsa-lib/...
> /usr/local/include/alsa-lib/...
Really? I thought:
/usr/local/alsa-lib/include
/usr/local/alsa-lib/lib
(how about /usr/local/linux-alsa/{include,lib}?)
Both are not difficult to write alsa-lib's Makefile
but very hard to porting apps to /usr/local/lib/alsa-lib and
/usr/local/include/alsa-lib.
In alsa-utils, about 50 or more files are needed to be patched
if header files are stored into /usr/local/include/alsa-lib .
I think this is too much, but simply do write a patch that
it is still neccesary...
--
SASANO Takayoshi (JG1UAA)
arm bulk build report
bulk build on armv7.ports.openbsd.org started on Tue Dec 20 16:09:18 MST 2022 finished at Sat Jan 14 22:19:19 MST 2023 lasted 25D06h10m done with kern.version=OpenBSD 7.2-current (GENERIC) #91: Tue Dec 20 00:00:31 MST 2022 built packages:8448 Dec 20:270 Dec 21:440 Dec 22:54 Dec 23:269 Dec 24:263 Dec 25:86 Dec 26:94 Dec 27:266 Dec 28:190 Dec 29:32 Dec 30:108 Dec 31:144 Jan 1:4271 Jan 2:146 Jan 3:168 Jan 4:300 Jan 5:210 Jan 6:297 Jan 7:292 Jan 8:275 Jan 9:272 Jan 10:441 Jan 11:302 Jan 12:317 Jan 13:328 Jan 14:2726 critical path missing pkgs: http://build-failures.rhaalovely.net/arm/2022-12-20/summary.log build failures: 55 http://build-failures.rhaalovely.net/arm/2022-12-20/audio/pulseaudio.log http://build-failures.rhaalovely.net/arm/2022-12-20/databases/pgbackrest.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/abseil-cpp.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/boost.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/dyncall.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/liboil.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/mtxclient.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/ptlib.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/remake.log http://build-failures.rhaalovely.net/arm/2022-12-20/devel/xsd.log http://build-failures.rhaalovely.net/arm/2022-12-20/editors/micro.log http://build-failures.rhaalovely.net/arm/2022-12-20/emulators/dgen-sdl.log http://build-failures.rhaalovely.net/arm/2022-12-20/emulators/higan.log http://build-failures.rhaalovely.net/arm/2022-12-20/emulators/ppsspp.log http://build-failures.rhaalovely.net/arm/2022-12-20/emulators/spike.log http://build-failures.rhaalovely.net/arm/2022-12-20/games/barony.log http://build-failures.rhaalovely.net/arm/2022-12-20/games/godot.log http://build-failures.rhaalovely.net/arm/2022-12-20/games/hyperrogue.log http://build-failures.rhaalovely.net/arm/2022-12-20/games/stockfish.log http://build-failures.rhaalovely.net/arm/2022-12-20/graphics/babl.log http://build-failures.rhaalovely.net/arm/2022-12-20/graphics/tesseract/tesseract.log http://build-failures.rhaalovely.net/arm/2022-12-20/inputmethods/uim.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/STk.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/hashlink.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/janet.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/parrot.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/python/3.11,-gdbm.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/racket-minimal.log http://build-failures.rhaalovely.net/arm/2022-12-20/lang/swi-prolog.log http://build-failures.rhaalovely.net/arm/2022-12-20/mail/bogofilter,db4.log http://build-failures.rhaalovely.net/arm/2022-12-20/mail/courier-unicode.log http://build-failures.rhaalovely.net/arm/2022-12-20/math/igraph.log http://build-failures.rhaalovely.net/arm/2022-12-20/math/lean.log http://build-failures.rhaalovely.net/arm/2022-12-20/math/mathomatic.log http://build-failures.rhaalovely.net/arm/2022-12-20/misc/astrolog.log http://build-failures.rhaalovely.net/arm/2022-12-20/misc/osinfo/libosinfo.log http://build-failures.rhaalovely.net/arm/2022-12-20/misc/osinfo/osinfo-db-tools.log http://build-failures.rhaalovely.net/arm/2022-12-20/net/bro.log http://build-failures.rhaalovely.net/arm/2022-12-20/net/tailscale.log http://build-failures.rhaalovely.net/arm/2022-12-20/net/tdlib.log http://build-failures.rhaalovely.net/arm/2022-12-20/net/ucspi-tools.log http://build-failures.rhaalovely.net/arm/2022-12-20/plan9/drawterm.log http://build-failures.rhaalovely.net/arm/2022-12-20/print/foo2zjs.log http://build-failures.rhaalovely.net/arm/2022-12-20/security/foremost.log http://build-failures.rhaalovely.net/arm/2022-12-20/security/step-cli.log http://build-failures.rhaalovely.net/arm/2022-12-20/sysutils/autossh.log http://build-failures.rhaalovely.net/arm/2022-12-20/sysutils/libvirt.log http://build-failures.rhaalovely.net/arm/2022-12-20/sysutils/login_krb5.log http://build-failures.rhaalovely.net/arm/2022-12-20/sysutils/planor.log http://build-failures.rhaalovely.net/arm/2022-12-20/sysutils/rancid.log http://build-failures.rhaalovely.net/arm/2022-12-20/telephony/kamailio.log http://build-failures.rhaalovely.net/arm/2022-12-20/x11/gnustep/libobjc2.log http://build-failures.rhaalovely.net/arm/2022-12-20/x11/jgmenu.log http://build-failures.rhaalovely.net/arm/2022-12-20/x11/qt5/qtbase.log http://build-failures.rhaalovely.net/arm/2022-12-20/x11/qt6/qtbase.log recurrent failures failures/audio/pulseaudio.log failures/databases/pgbackrest.log failures/devel/abseil-cpp.log failures/devel/boost.log failures/devel/dyncall.log failures/devel/liboil.log failures/devel/mtxclient.log failures/devel/ptlib.log failures/devel/remake.log failures/devel/xsd.log failures/emulators/dgen-sdl.log failures/emulators/higan.log failures/emulators/ppsspp.log failures/
