Re: [mpv] --vo=gpu not working, permission denied
This is because the fbtab subsystem is quite broken. No good alternative designs have come forward. Stefan Hagen wrote: > beecdadd...@danwin1210.de wrote (2024-02-26 22:54 CET): > > libEGL warning: failed to open /dev/dri/card0: Permission denied > > You can fix it with: chown /dev/dri/card0 /dev/dri/renderD128 > > Xenodm does this automatically when you log in. > See /etc/X11/xenodm/GiveConsole > > The permission are also set when you log in on ttyC0. > See /etc/fbtab and fbtab(5) > > Therefore the permissions are changing when you jump out of X > with ctrl+alt+f1 and log in as root. When you hop back into X, > the permissions are wrong. > > This only happens on the first console. Use another one instead > (ctrl+alt+f2,3,4) while using X. > > Best Regards, > Stefan >
Re: [mpv] --vo=gpu not working, permission denied
beecdadd...@danwin1210.de wrote (2024-02-26 22:54 CET): > libEGL warning: failed to open /dev/dri/card0: Permission denied You can fix it with: chown /dev/dri/card0 /dev/dri/renderD128 Xenodm does this automatically when you log in. See /etc/X11/xenodm/GiveConsole The permission are also set when you log in on ttyC0. See /etc/fbtab and fbtab(5) Therefore the permissions are changing when you jump out of X with ctrl+alt+f1 and log in as root. When you hop back into X, the permissions are wrong. This only happens on the first console. Use another one instead (ctrl+alt+f2,3,4) while using X. Best Regards, Stefan
Re: NEW. sysutils/croc
Paco Esteban writes:
> After reading other comments, I added the README to ${PREFIX}/share/doc/croc/
> This is markdown, so not so pleasant to read from the terminal. But
> it's something.
fine with it.
>> > The software has a "relay" mode in which it acts as a daemon. I did not
>> > include startup scripts or reserve a system user, should we do that ?
>>
>> I don't have strong opinion about it. I am fine without it, but if you
>> expect users to want to setup a local relay, it might be preferable (as
>> it will be properly configured at first).
>
> I added the startup script and user in the end. I think it's better to
> have it even if the user base is small.
the @newuser is a bit odd: you have a home defined to
${LOCALSTATEDIR}/croc , but the directory isn't created by the port.
if the relay mode doesn't need an owned directory as home, just use /var/empty
for the rc script, prefer:
daemon="${TRUEPREFIX}/bin/croc relay"
daemon_flags=""
so the relay command will not be overrided by user setting.
please note that the default configuration (if the user enable the
script) makes the relay to listen to *:90{09,10,11,12,13}. It might be
preferable to listen to localhost by default (even if not really an
useful relay).
daemon_flags="--host localhost"
Thanks.
--
Sebastien Marie
Re: [mpv] --vo=gpu not working, permission denied
El Mon, 26 Feb 2024 21:54:43 - beecdadd...@danwin1210.de escribió: > hi list > > mpv does not work > OpenBSD -current updated 2 days ago, pkg_add -u was done now > Thinkpad T400 laptop with Intep GPU > say if you need more info than this and down > > mpv gives this error > (+) Video --vid=1 (*) (vp8 240x424 30.000fps) > (+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz) > libEGL warning: MESA-LOADER: failed to retrieve device information > > libEGL warning: failed to open /dev/dri/card0: Permission denied > > libEGL warning: DRI2: could not open /dev/dri/card0 (Permission > denied) [vo/gpu/opengl] Suspected software renderer or indirect > context. [vo/gpu/libplacebo] EnumeratePhysicalDevices(inst, &num, > NULL): VK_ERROR_INITIALIZATION_FAILED > (../libplacebo-6.338.2/src/vulkan/context.c:984) > [vo/gpu/libplacebo] Found no suitable device, giving up. > [vo/gpu/libplacebo] Failed initializing vulkan device > [vo/gpu/libplacebo] EnumeratePhysicalDevices(inst, &num, NULL): > VK_ERROR_INITIALIZATION_FAILED > (../libplacebo-6.338.2/src/vulkan/context.c:984) > [vo/gpu] Failed initializing any suitable GPU context! > Error opening/initializing the selected video_out (--vo) device. > Video: no video > Exiting... (Errors when loading file) > > > > dmesg gave this error, not fresh > drm:pid8053:drm_atomic_helper_wait_for_flip_done *ERROR* [drm] *ERROR* > [CRTC:45:pipe A] flip_done timed out > drm:pid51733:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential > atomic update failure on pipe A > Hi! Can you provide your mpv.conf and the exact output for theses commands? 1) mpv -v --vo=gpu --gpu-api=opengl your_video 2) mpv -v --vo=gpu --gpu-api=vulkan your_video 3) glxinfo 4) vulkaninfo Please provide the info in separate files -- * Dios en su cielo, todo bien en la Tierra
Re: [update] www/mycorrhiza: add cert symlink instructions
On 26 February 2024 22:45:18 UTC, Jag Talon wrote: > Bumping REVISION as well. > Hello, thank you for suggesting this change, I haven't noticed this before, because in testing environment i wasn't using ssl and in 'production' I already had this symlink. The patch is fine by me, but i'm thinking that maybe it would be better to unify the two patches. What do you think?
Re: [NEW]: misc/openhab - open Home Automation Bus (openHAB)
On Mon, Feb 26, 2024 at 06:10:57PM +, Stuart Henderson wrote:
> Here are some tweaks on top (sent as a diff for commentary and a new
> tar).
>
> I'd like the opinion of someone with a hand in the rc.d system to
> comment on that part. Maybe they'll be ok with it, but it's a bit
> complicated and not something that I think we do in any other ports.
> On the other hand I'm not sure I can think of a nice alternative..
>
> : diff --git a/misc/openhab/Makefile b/misc/openhab/Makefile
> : index 3ff4984..dc582de 100644
> : --- a/misc/openhab/Makefile
> : +++ b/misc/openhab/Makefile
> : @@ -28,16 +28,12 @@ pre-extract:
> : @mkdir ${WRKDIST}
> :
> : do-install:
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/
> : + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openhab/
>
> the ${PKGSTEM} indirection isn't really useful imho and makes it harder
> to read, I've replaced with openhab throughout
Makes sense, thank you.
>
> : - ${INSTALL_DATA} ${FILESDIR}/${PKGSTEM}.conf \
> : - ${PREFIX}/share/examples/${PKGSTEM}/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/libexec/${PKGSTEM}/
> : - @cd ${WRKDIST} && openrsync --rsync-path=openrsync -a \
> : - --exclude={'./conf','./userdata'} .
> ${PREFIX}/libexec/${PKGSTEM}/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/etc/
> : - @cd ${WRKDIST}/conf && pax -rw .
> ${PREFIX}/share/examples/${PKGSTEM}/etc/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/var/
> : - @cd ${WRKDIST}/userdata && pax -rw . \
> : - ${PREFIX}/share/examples/${PKGSTEM}/var/
> : + ${INSTALL_DATA} ${FILESDIR}/openhab.conf \
> : + ${PREFIX}/share/examples/openhab/
> : + ${INSTALL_DATA_DIR} ${PREFIX}/libexec/openhab/
> : + cd ${WRKDIST} && pax -rw . ${PREFIX}/libexec/openhab/
> : + mv ${PREFIX}/libexec/openhab/conf ${PREFIX}/share/examples/openhab/
> : + mv ${PREFIX}/libexec/openhab/userdata ${PREFIX}/share/examples/openhab/
>
> not really a fan of using openrsync to copy files around, so I've
> replaced it by copying all files with pax to libexec, then moving the
> couple of dirs which should end up in examples. I kept the original
> dir names and adjusted PLIST to match.
Perfect.
>
> : diff --git a/misc/openhab/pkg/PLIST b/misc/openhab/pkg/PLIST
> : index 1e76d42..8144a30 100644
> : --- a/misc/openhab/pkg/PLIST
> : +++ b/misc/openhab/pkg/PLIST
> : @@ -1,6 +1,5 @@
> : -@newgroup _openhab:896
> : -@newuser _openhab:896:_openhab::openHAB user:/nonexistent:/sbin/nologin
> : +@newgroup _openhab:897
> : +@newuser _openhab:897:_openhab::openHAB user:/nonexistent:/sbin/nologin
>
> 896 is taken now, switch to 897
>
> : -@exec-add usermod -G dialer _openhab
>
> I don't think the package should auto-add itself to what in some
> circumstances could be a sensitive group. Could maybe be suggested
> in the readme (I haven't done so myself because I don't know which
> circumstances need it and I think that should be explained).
I updated the README for access to serial ports. The use-case is when
a USB dongle for Zigbee or Z-Wave is used and the _openhab user needs
access. Unfortuantely, the rxtx wrapper for native serial port access
does not currently support OpenBSD.
https://github.com/rxtx/rxtx
I'm currently looking for an alternative or will port that to OpenBSD.
>
> : @rcscript ${RCDIR}/openhab
> : libexec/openhab/
> : libexec/openhab/LICENSE.TXT
> : @@ -1225,203 +1224,203 @@ libexec/openhab/start_debug.sh
> : share/doc/pkg-readmes/${PKGSTEM}
> : share/examples/openhab/
> : @sample ${SYSCONFDIR}/openhab/
> : -share/examples/openhab/etc/
> : +share/examples/openhab/conf/
> ...
>
>
> : diff --git a/misc/openhab/pkg/openhab.rc b/misc/openhab/pkg/openhab.rc
> : index ea7a859..4284a62 100644
> : --- a/misc/openhab/pkg/openhab.rc
> : +++ b/misc/openhab/pkg/openhab.rc
> : @@ -1,7 +1,7 @@
> : #!/bin/ksh
> :
> : -JAVA="$(${LOCALBASE}/bin/javaPathHelper -c ${PKGSTEM})"
> : -JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h ${PKGSTEM})"
> : +JAVA="$(${LOCALBASE}/bin/javaPathHelper -c openhab)"
> : +JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h openhab)"
>
> avoid indirection again
>
> : # Read configuration variable file if it is present
> : if [ -r /etc/openhab.conf ]; then
> : @@ -13,12 +13,12 @@ if [ -z "${EXTRA_JAVA_OPTS}" ]; then
> EXTRA_JAVA_OPTS="-Dsun.nio.fs.watchservice
> : if [ -z "${OPENHAB_HTTP_ADDRESS}" ]; then
> OPENHAB_HTTP_ADDRESS="127.0.0.1"; fi
> : if [ -z "${OPENHAB_HTTP_PORT}" ]; then OPENHAB_HTTP_PORT=8080; fi
> : if [ -z "${OPENHAB_HTTPS_PORT}" ]; then OPENHAB_HTTPS_PORT=8443; fi
> : -if [ -z "${OPENHAB_HOME}" ]; then
> OPENHAB_HOME="${PREFIX}/libexec/${PKGSTEM}"; fi
> : -if [ -z "${OPENHAB_CONF}" ]; then
> OPENHAB_CONF="${SYSCONFDIR}/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_HOME}" ]; then
> OPENHAB_HOME="${PREFIX}/libexec/openhab"; fi
> : +if [ -z "${OPENHAB_CONF}" ]; then
> OPENHAB_CONF
Re: [update] www/mycorrhiza: add cert symlink instructions
Bumping REVISION as well.
--
Jag Talon (he/him)
https://jagtalon.net/
https://weirder.earth/@jag
Index: Makefile
===
RCS file: /cvs/ports/www/mycorrhiza/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile 12 Apr 2023 09:32:11 - 1.4
+++ Makefile 26 Feb 2024 22:43:34 -
@@ -2,6 +2,7 @@ COMMENT = plain-text driven engine for p
MODGO_MODNAME = github.com/bouncepaw/mycorrhiza
MODGO_VERSION = v1.14.0
+REVISION = 0
DISTNAME = mycorrhiza-${MODGO_VERSION}
[update] www/mycorrhiza: add cert symlink instructions
The httpd.conf and relayd.conf instructions in the README work, but leads to SEC_ERROR_UNKNOWN_ISSUER errors on some browsers. The solution can be found in the project's documentation [1] which is to symlink the example.com.fullchain.pem file to example.com.crt. Here is a patch to the README that adds that instruction. What do you think la ninpre? [1]: https://mycorrhiza.wiki/hypha/openbsd -- Jag Talon (he/him) https://jagtalon.net/ https://weirder.earth/@jag Index: pkg/README === RCS file: /cvs/ports/www/mycorrhiza/pkg/README,v retrieving revision 1.1.1.1 diff -u -p -u -r1.1.1.1 README --- pkg/README 8 Sep 2022 13:35:47 - 1.1.1.1 +++ pkg/README 26 Feb 2024 22:22:35 - @@ -58,6 +58,11 @@ acme-client(1)) and start httpd(8) and r # rcctl enable httpd relayd # rcctl start httpd relayd +If you already have a certificate following the acme-client.conf +default template, make sure to create the following symlink to prevent +SEC_ERROR_UNKNOWN_ISSUER issues on some browsers: + +# ln -s /etc/ssl/example.com.fullchain.pem /etc/ssl/example.com.crt Setup =
Re: acme-client: add challenge hook to support dns-01
On Tue, Feb 20, 2024 at 10:32:11PM +0100, Christopher Zimmermann wrote:
> Hi,
>
> this diff adds a challenge hook to acme-client. This hook can be used to
> fulfill challenges. For example by putting the requested files onto a remote
> http server (http-01 challenge) or by modifying dns records (dns-01
> challenge). The latter are needed to obtain wildcard certificates.
> Is this diff ok? Is the design of the hook interface sane? Any feedback is
> welcome.
>
>
> Christopher
> Index: etc/examples/acme-client.conf
> ===
> RCS file: /cvs/src/etc/examples/acme-client.conf,v
> retrieving revision 1.5
> diff -u -p -r1.5 acme-client.conf
> --- etc/examples/acme-client.conf 10 May 2023 07:34:57 - 1.5
> +++ etc/examples/acme-client.conf 20 Feb 2024 21:20:26 -
> @@ -25,6 +25,12 @@ authority buypass-test {
>
> domain example.com {
> alternative names { secure.example.com }
> + # For wildcard certificates dns-01 challenges need
> + # to be handled by a hook script.
> + # An example script can be found in /etc/examples/acme-hook.sh
> + #alternative names { *.example.com }
> + #challengehook "/etc/acme/acme-hook.sh"
> + #delay 310
> domain key "/etc/ssl/private/example.com.key"
> domain full chain certificate "/etc/ssl/example.com.fullchain.pem"
> # Test with the staging server to avoid aggressive rate-limiting.
> Index: etc/examples/acme-hook.sh
> ===
> RCS file: etc/examples/acme-hook.sh
> diff -N etc/examples/acme-hook.sh
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ etc/examples/acme-hook.sh 20 Feb 2024 21:20:26 -
> @@ -0,0 +1,40 @@
> +#!/bin/ksh
> +#
> +# $OpenBSD: $
> +#
> +
> +password=
> +
> +update() {
> + doas -u nobody curl -K - <<- END
> + no-progress-meter
> + retry = 7
> + retry-connrefused
> + retry-delay = 20
> + max-time= 5
> + url = dyn.dns.he.net
> + user= $1:$password
> + data= txt=$2
> + END
> +}
> +
> +while read type domain token thumb _reserved
> +do
> + if [ "$type" = "dns-01" ]
> + then
> +txt=`echo -n "$token.$thumb" |sha256 -b |tr '+/' '-_' |tr -d '='`
> +domain="_acme-challenge.$domain"
> +result=`update "$domain" "$txt"`
> +echo "$0: Setting $domain to $txt: $result" >&2
> +reset[${#reset[@]}]="$domain"
> +echo "HANDLED"
> + else
> +echo "UNHANDLED"
> + fi
> +done
> +
> +for domain in "${reset[@]}"
> +do
> + result=`update "$domain" "X"`
> + echo "$0: Resetting $domain: $result" >&2
> +done
> Index: usr.sbin/acme-client/acme-client.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
> retrieving revision 1.29
> diff -u -p -r1.29 acme-client.conf.5
> --- usr.sbin/acme-client/acme-client.conf.5 11 Jan 2021 07:23:42 -
> 1.29
> +++ usr.sbin/acme-client/acme-client.conf.5 20 Feb 2024 21:20:26 -
> @@ -193,10 +193,63 @@ The certificate authority (as declared a
> section) to use.
> If this setting is absent, the first authority specified is used.
> .It Ic challengedir Ar path
> -The directory in which the challenge file will be stored.
> +The directory in which the challenge file for
> +.Dv http-01
> +challenges will be stored if
> +.Ar challengehook
> +did not handle them.
> If it is not specified, a default of
> .Pa /var/www/acme
> will be used.
> +.It Ic challengehook Ar command
> +.Ar command
> +receives challenges, one per line, on its
> +.Va stdin
> +and responds on
> +.Va stdout
> +with
> +.Dv HANDLED
> +when the challenge was handled or
> +.Dv UNHANDLED
> +when the challenge was not accepted.
> +.Ic challengehook
> +is meant primarily for
> +.Dv dns-01
> +challeges, but can be used handle other types of challenges, too.
> +.Pp
> +The challenges are presented on stdin in this format:
> +
> +.Ar type
> +.Ar identifier
> +.Ar token
> +.Ar thumb
> +.Ar reserved
> +
> +The most interesting
> +.Ar type
> +is
> +.Dv dns-01.
> +.Ar identifier
> +is the domain name to which a _acme-challenge. TXT subdomain record
> +needs to be installed.
> +.Ar token
> +and
> +.Ar thumb
> +are the token and thumb which are needed to construct the TXT record.
> +.Ar reserved
> +is reserved for future use.
> +
> +An example hook script can be found in
> +.Pa /etc/examples/acme-hook.sh
> +
> +.It Ic delay Ar seconds
> +After challenges are handled, delay for
> +.Ar seconds
> +before asking the
> +.Ar authority
> +to check challenges. A generous delay may be needed to wait for changes
> +to DNS to propagate to all servers checked by the
> +.Ar authority.
> .El
> .Sh FILES
> .Bl -tag -width /etc/examples/acme-client.conf -compact
> Index: usr.sbin/acme-client/chngproc.c
> ===
> RCS file: /cvs/src/usr.sbi
[mpv] --vo=gpu not working, permission denied
hi list mpv does not work OpenBSD -current updated 2 days ago, pkg_add -u was done now Thinkpad T400 laptop with Intep GPU say if you need more info than this and down mpv gives this error (+) Video --vid=1 (*) (vp8 240x424 30.000fps) (+) Audio --aid=1 --alang=eng (*) (vorbis 2ch 48000Hz) libEGL warning: MESA-LOADER: failed to retrieve device information libEGL warning: failed to open /dev/dri/card0: Permission denied libEGL warning: DRI2: could not open /dev/dri/card0 (Permission denied) [vo/gpu/opengl] Suspected software renderer or indirect context. [vo/gpu/libplacebo] EnumeratePhysicalDevices(inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED (../libplacebo-6.338.2/src/vulkan/context.c:984) [vo/gpu/libplacebo] Found no suitable device, giving up. [vo/gpu/libplacebo] Failed initializing vulkan device [vo/gpu/libplacebo] EnumeratePhysicalDevices(inst, &num, NULL): VK_ERROR_INITIALIZATION_FAILED (../libplacebo-6.338.2/src/vulkan/context.c:984) [vo/gpu] Failed initializing any suitable GPU context! Error opening/initializing the selected video_out (--vo) device. Video: no video Exiting... (Errors when loading file) dmesg gave this error, not fresh drm:pid8053:drm_atomic_helper_wait_for_flip_done *ERROR* [drm] *ERROR* [CRTC:45:pipe A] flip_done timed out drm:pid51733:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A
lang/compcert: patch for ocaml-non-native-arch
I found that packaging lang/compcert fails on ocaml-non-native architectures.
we need a patch to Makefile.menhir.
(and I'm not sure if we need revision up here...)
-- yozo.
diff -urN -x CVS /usr/ports/lang/compcert/Makefile
/usr/ports/mystuff/lang/compcert/3.13.1p1/Makefile
--- /usr/ports/lang/compcert/Makefile Sat Jan 6 10:38:27 2024
+++ /usr/ports/mystuff/lang/compcert/3.13.1p1/Makefile Thu Feb 1 01:36:12 2024
@@ -8,7 +8,7 @@
GH_TAGNAME = v${V}
DISTNAME = ${GH_PROJECT}-${V}
PKGNAME = ${DISTNAME:L}
-REVISION = 0
+REVISION = 1
HOMEPAGE = https://compcert.org/
diff -urN -x CVS /usr/ports/lang/compcert/patches/patch-Makefile_menhir
/usr/ports/mystuff/lang/compcert/3.13.1p1/patches/patch-Makefile_menhir
--- /usr/ports/lang/compcert/patches/patch-Makefile_menhir Thu Jan 1
09:00:00 1970
+++ /usr/ports/mystuff/lang/compcert/3.13.1p1/patches/patch-Makefile_menhir
Mon Aug 21 18:18:14 2023
@@ -0,0 +1,27 @@
+for ocaml-non-native architectures
+
+Index: Makefile.menhir
+--- Makefile.menhir.orig
Makefile.menhir
+@@ -42,10 +42,18 @@ MENHIR_FLAGS = -v --no-stdlib -la 1
+ # Using Menhir in --table mode requires MenhirLib.
+
+ ifeq ($(MENHIR_TABLE),true)
+- ifeq ($(wildcard $(MENHIR_DIR)/menhirLib.cmxa),)
+-MENHIR_LIBS = menhirLib.cmx
++ ifeq ($(OCAML_NATIVE_COMP), true)
++ifeq ($(wildcard $(MENHIR_DIR)/menhirLib.cmxa),)
++ MENHIR_LIBS = menhirLib.cmx
++else
++ MENHIR_LIBS = menhirLib.cmxa
++endif
+ else
+-MENHIR_LIBS = menhirLib.cmxa
++ifeq ($(wildcard $(MENHIR_DIR)/menhirLib.cma),)
++ MENHIR_LIBS = menhirLib.cmo
++else
++ MENHIR_LIBS = menhirLib.cma
++endif
+ endif
+ else
+ MENHIR_LIBS =
Re: maintainer update sysutils/chezmoi --> 2.46.1
2.47.0 is out now: https://github.com/twpayne/chezmoi/releases/tag/v2.47.0
Patch updated:
diff /usr/ports
commit - 26872df732fc01fa20b4946684e0cbe5fe3971ff
path + /usr/ports
blob - 550536261c828a5e23134001d82231623934c9dc
file + sysutils/chezmoi/Makefile
--- sysutils/chezmoi/Makefile
+++ sysutils/chezmoi/Makefile
@@ -1,7 +1,7 @@
COMMENT = dotfiles manager across multiple diverse machines
MODGO_MODNAME =github.com/twpayne/chezmoi/v2
-MODGO_VERSION =v2.45.0
+MODGO_VERSION =v2.47.0
DISTNAME = chezmoi-${MODGO_VERSION}
blob - 77fcc1afdc171f6e236280a667ecfab897fb2a1c
file + sysutils/chezmoi/distinfo
--- sysutils/chezmoi/distinfo
+++ sysutils/chezmoi/distinfo
@@ -1,4 +1,4 @@
-SHA256 (chezmoi-v2.45.0.zip) = GHfijF1nwZ/2roKNXuuv3w3J7hoIkzPwZsCAT8SWdaA=
+SHA256 (chezmoi-v2.47.0.zip) = U2/JPUguBHLX1GQU08zPkmpf02KIm/d5JYNdGIFZQ24=
SHA256 (go_modules/cloud.google.com/go/@v/v0.110.10.mod) =
NYagpvj1XJrKsc5QbeBFAKXdHh9xg/Q1yHBvDEDfIWY=
SHA256 (go_modules/cloud.google.com/go/@v/v0.110.10.zip) =
ZeajKzFvIA1rPPWPKhYNxvaKhfBz3KJMBRP3TzDHhHE=
SHA256 (go_modules/cloud.google.com/go/compute/@v/v1.20.1.mod) =
SI2TVknKeuBzDnUj1v2BwiWJhPotYoT9IlqTVMmt43I=
@@ -20,22 +20,21 @@ SHA256 (go_modules/filippo.io/age/@v/v1.1.1.mod) = zcZ
SHA256 (go_modules/filippo.io/age/@v/v1.1.1.zip) =
IWBSEkGBQQhy0T4ND4bAT5RfSt82+6RR7fMejQnBuGk=
SHA256 (go_modules/filippo.io/edwards25519/@v/v1.0.0.mod) =
18MvTgz5F65FgigZwzhreQaHZbYlu+JJdGHuwPjoYpw=
SHA256 (go_modules/filippo.io/edwards25519/@v/v1.0.0.zip) =
+1voKavKxjkxp6DEEKcYH6T5CffrcPc07b2nhoWSFno=
-SHA256
(go_modules/github.com/!azure!a!d/microsoft-authentication-library-for-go/@v/v1.1.1.mod)
= 7Qhg33P5gdaF3uCyx4T31hPZ8gfqcTsNLxcoiYmJuG0=
SHA256
(go_modules/github.com/!azure!a!d/microsoft-authentication-library-for-go/@v/v1.2.1.mod)
= 7Qhg33P5gdaF3uCyx4T31hPZ8gfqcTsNLxcoiYmJuG0=
-SHA256
(go_modules/github.com/!azure!a!d/microsoft-authentication-library-for-go/@v/v1.2.1.zip)
= brKEb3y82QkayVSu1mhXUTjMsGS2xw7/HGSjUkvuvGo=
+SHA256
(go_modules/github.com/!azure!a!d/microsoft-authentication-library-for-go/@v/v1.2.2.mod)
= 7Qhg33P5gdaF3uCyx4T31hPZ8gfqcTsNLxcoiYmJuG0=
+SHA256
(go_modules/github.com/!azure!a!d/microsoft-authentication-library-for-go/@v/v1.2.2.zip)
= iVrDlISSGA7SHqvmUb6+RcnZm5LCc4IGdZ1vr09DDSY=
SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.7.0.mod) =
OpfCagdkJsYpdFdLc6MxeD5hyoH1qYX+9dxp49ZN42U=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.7.1.mod) =
OpfCagdkJsYpdFdLc6MxeD5hyoH1qYX+9dxp49ZN42U=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.8.0.mod) =
pfXLjM8Gc3XZe/zb3zCHxyeP9/eMHuN4JbIkY3HEoVc=
SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.9.1.mod) =
ii0MbFcNX2koP2hdAgAm/CDFqSZj7ALq2knh6SPySL8=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.9.1.zip) =
vZtCQmItHYglzcIHE5GhX7KdSohEs4vAgUEL/sK8p6M=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azidentity/@v/v1.3.1.mod) =
26BfvbYKOINVSNTOGyHSyQBYuzowgNlUYC2dinmHkLI=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azidentity/@v/v1.4.0.mod) =
VGyPgaDR5BmgkcQYtgzt7pwXaz3rIsbnx8KZS90rpb0=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azidentity/@v/v1.4.0.zip) =
OVZiSSVPBeWNiooTJM1EwFRcpAkbNNXYbfuDIGK4MCw=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.9.2.mod) =
TM5Pvhgdoi3fORwj1PoPL5VX2JrmcmmBnqFc6HhBZt4=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azcore/@v/v1.9.2.zip) =
ladSvubqkmWipdgNn+IilmEzXHL9kXWhkOEwhs3DFPc=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azidentity/@v/v1.5.1.mod) =
c7hxFm9gA4du9VAgIiI7yPjTcKuTcTyh+SKREWRyBD4=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/azidentity/@v/v1.5.1.zip) =
KVxcuusNdZm2Q5tcZc8b9tS+zAf59yL3JCY4h7feHwA=
SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/internal/@v/v1.3.0.mod) =
taAvZV66xQR1vv3CMMy7KXov1v5oAwBmXZU5Sib3O2U=
SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/internal/@v/v1.5.1.mod) =
FM4QAVEXlxElQ0RgN4j/NPh5UUI7ayZobn9CpxoBB6Y=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/internal/@v/v1.5.1.zip) =
Z5KDdLufGNcgqxUXFWXJJAXEiNHPv42/8l+LDw/v4Gc=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets/@v/v1.0.1.mod)
= 3FJ/HVva9P1Dta+n9JcOUrixRLSJ1bdzfW57QYHgUkE=
-SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets/@v/v1.0.1.zip)
= iFMBrQsfkK5itAsFl5YZmihkKPePpu9lowUqggZcOeY=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/internal/@v/v1.5.2.mod) =
Zw17axNdy7UgI+97ZxXc2iq9jjxutH5AFfnb/60D9cg=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/internal/@v/v1.5.2.zip) =
9/0GQPw/1cqOe5aPvL0ijy+hpNwfLHEN2U7qN1OhFd0=
+SHA256
(go_modules/github.com/!azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets/@v/v1.1.0.mod
Re: NEW. sysutils/croc
On Mon, 26 Feb 2024, Sebastien Marie wrote:
> Paco Esteban writes:
>
> > Hi ports@,
> >
> > cat DESCR
> >
> > croc is a tool that allows any two computers to simply and securely
> > transfer
> > files and folders.
> > croc's features include:
> >
> > * allow any two computers to transfer data (using a relay)
> > * end-to-end encryption (using PAKE)
> > * easy cross-platform transfers (Windows, Linux, Mac)
> > * multiple file transfers
> > * resume transfers that are interrupted
> > * local server or port-forwarding not needed
> > * ipv6-first with ipv4 fallback
> > * can use proxy, like tor
> >
> > You'll notice than PLIST only contains the binary. The only
> > documentation they include in the sources is the project README file,
> > which I'm not sure if we should include in the package.
>
> Eventually, it could be possible add just few lines as example in DESC:
>
> $ croc send foobar
> Sending 'foobar' (6.6 MB)
> Code is: 1767-cubic-ringo-source
> On the other computer run
>
> croc 1767-cubic-ringo-source
After reading other comments, I added the README to ${PREFIX}/share/doc/croc/
This is markdown, so not so pleasant to read from the terminal. But
it's something.
> > The software has a "relay" mode in which it acts as a daemon. I did not
> > include startup scripts or reserve a system user, should we do that ?
>
> I don't have strong opinion about it. I am fine without it, but if you
> expect users to want to setup a local relay, it might be preferable (as
> it will be properly configured at first).
I added the startup script and user in the end. I think it's better to
have it even if the user base is small.
> > Comments and suggestions welcome.
> >
> > Ok to import ?
>
> There is still a commented "FIX_CLEANUP_PERMISSIONS" in the Makefile.
Removed.
> Outside of that, I am fine with it. ok semarie@
Still ok ?
Here's the diff for the new user and attached the modified port:
diff /usr/ports
commit - 26872df732fc01fa20b4946684e0cbe5fe3971ff
path + /usr/ports
blob - b42938f202aa5f3563a1fbbd9b4e89d5e7a3d49a
file + infrastructure/db/user.list
--- infrastructure/db/user.list
+++ infrastructure/db/user.list
@@ -405,3 +405,4 @@ id usergroup port
894 _gonic _gonic audio/gonic
895 _soju _soju net/soju
896 _certspotter _certspottersecurity/certspotter
+897 _croc _croc sysutils/croc
--
Paco Esteban.
0x5818130B8A6DBC03
croc.tgz
Description: application/tar-gz
Re: [NEW]: misc/openhab - open Home Automation Bus (openHAB)
Here are some tweaks on top (sent as a diff for commentary and a new
tar).
I'd like the opinion of someone with a hand in the rc.d system to
comment on that part. Maybe they'll be ok with it, but it's a bit
complicated and not something that I think we do in any other ports.
On the other hand I'm not sure I can think of a nice alternative..
: diff --git a/misc/openhab/Makefile b/misc/openhab/Makefile
: index 3ff4984..dc582de 100644
: --- a/misc/openhab/Makefile
: +++ b/misc/openhab/Makefile
: @@ -28,16 +28,12 @@ pre-extract:
: @mkdir ${WRKDIST}
:
: do-install:
: - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/
: + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openhab/
the ${PKGSTEM} indirection isn't really useful imho and makes it harder
to read, I've replaced with openhab throughout
: - ${INSTALL_DATA} ${FILESDIR}/${PKGSTEM}.conf \
: - ${PREFIX}/share/examples/${PKGSTEM}/
: - ${INSTALL_DATA_DIR} ${PREFIX}/libexec/${PKGSTEM}/
: - @cd ${WRKDIST} && openrsync --rsync-path=openrsync -a \
: - --exclude={'./conf','./userdata'} .
${PREFIX}/libexec/${PKGSTEM}/
: - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/etc/
: - @cd ${WRKDIST}/conf && pax -rw .
${PREFIX}/share/examples/${PKGSTEM}/etc/
: - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/var/
: - @cd ${WRKDIST}/userdata && pax -rw . \
: - ${PREFIX}/share/examples/${PKGSTEM}/var/
: + ${INSTALL_DATA} ${FILESDIR}/openhab.conf \
: + ${PREFIX}/share/examples/openhab/
: + ${INSTALL_DATA_DIR} ${PREFIX}/libexec/openhab/
: + cd ${WRKDIST} && pax -rw . ${PREFIX}/libexec/openhab/
: + mv ${PREFIX}/libexec/openhab/conf ${PREFIX}/share/examples/openhab/
: + mv ${PREFIX}/libexec/openhab/userdata ${PREFIX}/share/examples/openhab/
not really a fan of using openrsync to copy files around, so I've
replaced it by copying all files with pax to libexec, then moving the
couple of dirs which should end up in examples. I kept the original
dir names and adjusted PLIST to match.
: diff --git a/misc/openhab/pkg/PLIST b/misc/openhab/pkg/PLIST
: index 1e76d42..8144a30 100644
: --- a/misc/openhab/pkg/PLIST
: +++ b/misc/openhab/pkg/PLIST
: @@ -1,6 +1,5 @@
: -@newgroup _openhab:896
: -@newuser _openhab:896:_openhab::openHAB user:/nonexistent:/sbin/nologin
: +@newgroup _openhab:897
: +@newuser _openhab:897:_openhab::openHAB user:/nonexistent:/sbin/nologin
896 is taken now, switch to 897
: -@exec-add usermod -G dialer _openhab
I don't think the package should auto-add itself to what in some
circumstances could be a sensitive group. Could maybe be suggested
in the readme (I haven't done so myself because I don't know which
circumstances need it and I think that should be explained).
: @rcscript ${RCDIR}/openhab
: libexec/openhab/
: libexec/openhab/LICENSE.TXT
: @@ -1225,203 +1224,203 @@ libexec/openhab/start_debug.sh
: share/doc/pkg-readmes/${PKGSTEM}
: share/examples/openhab/
: @sample ${SYSCONFDIR}/openhab/
: -share/examples/openhab/etc/
: +share/examples/openhab/conf/
...
: diff --git a/misc/openhab/pkg/openhab.rc b/misc/openhab/pkg/openhab.rc
: index ea7a859..4284a62 100644
: --- a/misc/openhab/pkg/openhab.rc
: +++ b/misc/openhab/pkg/openhab.rc
: @@ -1,7 +1,7 @@
: #!/bin/ksh
:
: -JAVA="$(${LOCALBASE}/bin/javaPathHelper -c ${PKGSTEM})"
: -JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h ${PKGSTEM})"
: +JAVA="$(${LOCALBASE}/bin/javaPathHelper -c openhab)"
: +JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h openhab)"
avoid indirection again
: # Read configuration variable file if it is present
: if [ -r /etc/openhab.conf ]; then
: @@ -13,12 +13,12 @@ if [ -z "${EXTRA_JAVA_OPTS}" ]; then
EXTRA_JAVA_OPTS="-Dsun.nio.fs.watchservice
: if [ -z "${OPENHAB_HTTP_ADDRESS}" ]; then OPENHAB_HTTP_ADDRESS="127.0.0.1";
fi
: if [ -z "${OPENHAB_HTTP_PORT}" ];then OPENHAB_HTTP_PORT=8080; fi
: if [ -z "${OPENHAB_HTTPS_PORT}" ]; then OPENHAB_HTTPS_PORT=8443; fi
: -if [ -z "${OPENHAB_HOME}" ]; then
OPENHAB_HOME="${PREFIX}/libexec/${PKGSTEM}"; fi
: -if [ -z "${OPENHAB_CONF}" ]; then
OPENHAB_CONF="${SYSCONFDIR}/${PKGSTEM}"; fi
: +if [ -z "${OPENHAB_HOME}" ]; then
OPENHAB_HOME="${PREFIX}/libexec/openhab"; fi
: +if [ -z "${OPENHAB_CONF}" ]; then
OPENHAB_CONF="${SYSCONFDIR}/openhab"; fi
: if [ -z "${OPENHAB_RUNTIME}" ]; then
OPENHAB_RUNTIME="${OPENHAB_HOME}/runtime"; fi
: -if [ -z "${OPENHAB_USERDATA}" ]; then
OPENHAB_USERDATA="/var/db/${PKGSTEM}"; fi
: +if [ -z "${OPENHAB_USERDATA}" ]; then
OPENHAB_USERDATA="/var/db/openhab"; fi
: if [ -z "${OPENHAB_BACKUPS}" ]; then
OPENHAB_BACKUPS="${OPENHAB_USERDATA}/backups"; fi
: -if [ -z "${OPENHAB_LOGDIR}" ]; then
OPENHAB_LOGDIR="/var/log/${PKGSTEM}"; fi
: +if [ -z "${OPENHAB_LOGDIR}" ]; then
OPENHAB_LOGDIR="/var/log/openhab"; fi
:
: ENV="JAVA_HOME=${JAVA_HOME} \
: EXTRA_JAVA_OPTS
Re: NEW. sysutils/croc
On Sun Feb 25, 2024 at 2:19 PM EST, Paco Esteban wrote: > You'll notice than PLIST only contains the binary. The only > documentation they include in the sources is the project README file, > which I'm not sure if we should include in the package. > The software has a "relay" mode in which it acts as a daemon. I did not > include startup scripts or reserve a system user, should we do that ? I used to use croc a lot--I'm excited about this port! I think personally I'd like to have access to the usage section of the README file from the repo easily accessible (but perhaps without the relay part) so that I don't have to go to Github to remember the commands.
Re: NEW. sysutils/croc
Paco Esteban writes: > Hi ports@, > > cat DESCR > > croc is a tool that allows any two computers to simply and securely > transfer > files and folders. > croc's features include: > > * allow any two computers to transfer data (using a relay) > * end-to-end encryption (using PAKE) > * easy cross-platform transfers (Windows, Linux, Mac) > * multiple file transfers > * resume transfers that are interrupted > * local server or port-forwarding not needed > * ipv6-first with ipv4 fallback > * can use proxy, like tor > > You'll notice than PLIST only contains the binary. The only > documentation they include in the sources is the project README file, > which I'm not sure if we should include in the package. Eventually, it could be possible add just few lines as example in DESC: $ croc send foobar Sending 'foobar' (6.6 MB) Code is: 1767-cubic-ringo-source On the other computer run croc 1767-cubic-ringo-source > The software has a "relay" mode in which it acts as a daemon. I did not > include startup scripts or reserve a system user, should we do that ? I don't have strong opinion about it. I am fine without it, but if you expect users to want to setup a local relay, it might be preferable (as it will be properly configured at first). > Comments and suggestions welcome. > > Ok to import ? There is still a commented "FIX_CLEANUP_PERMISSIONS" in the Makefile. Outside of that, I am fine with it. ok semarie@ Thanks. -- Sebastien Marie
Re: [UPDATE] x11/picom - new version 11.2
El Sun, 25 Feb 2024 10:33:30 +0100 Omar Polo escribió: > Hello, > > On 2024/02/25 01:35:08 -0400, Jose Maldonado > wrote: > > El Wed, 14 Feb 2024 15:42:23 -0400 > > Jose Maldonado escribió: > > > Hi! I send diff for new version of picom, in this case the fixes > > > for use libepoxy are merged in upstream, the port compile/build > > > directly. > > > > > > CC @omar because he has maintained the port for a long time. > > > > > > > > > > PING > > > > This is the last update for x11/picom > > > > Bug fixes: > > > > * Workaround a NVIDIA problem that causes high CPU usage after > > * Fix building on OpenBSD (#1189, #1188) > > * Fix occasional freezes (#1040, #1145, #1166) > > * Fix corner-radius-rules not applying sometimes (#1177) > > * Fix window shader not having an effect (#1174) > > * Fix binding root pixmap in case of depth mismatch (#984) > > > > Reattach for convenience > > thanks for updating and taking care of fixing the issues with > upstream. Sorry for the delay in replying, I was hoping to see some > tests reports here before committing. It works fine for me (amdgpu), > so ok op@ if someone wants to go ahead and commit it, otherwise i'll > wait a couple of days still and then commit. > > > Thanks, > > Omar Polo I am also using amdgpu and so far nothing new. Thanks for the feedback! -- * Dios en su cielo, todo bien en la Tierra
Re: [new] net/dnsq
On Mon, Feb 26, 2024 at 11:30:20AM +0100, Renaud Allard wrote: > > > On 2/20/24 11:04, Stuart Henderson wrote: > > On 2024/02/20 10:37, Renaud Allard wrote: > > > > > > > > > On 2/20/24 10:19, Stuart Henderson wrote: > > > > On 2024/02/20 09:30, Renaud Allard wrote: > > > > > Yes, the name doesn't tell anything by itself. > > > > > Is this one better? The binary is still called q, but the package is > > > > > dnsq. > > > > > > > > If naming the package dnsq, I'd suggest also adding a symlink, dnsq -> > > > > q. > > > > > > I have added the symlink > > > > No need for ONLY_FOR_ARCHS, it builds ok on i386. > > > > OK sthen@ to import. > > > > ping OK otto@, -Otto
Re: [NEW]: misc/openhab - open Home Automation Bus (openHAB)
On Wed, Feb 21, 2024 at 09:39:10AM -0500, Chaz Kettleson wrote:
> On Sat, Feb 10, 2024 at 05:57:40PM -0500, Chaz Kettleson wrote:
> > On Wed, Jan 10, 2024 at 12:53:18AM -0500, Chaz Kettleson wrote:
> > >
> > > On Wed, Jan 10, 2024 at 12:15:39AM -0500, Chaz Kettleson wrote:
> > > >
> > > > On Tue, Jan 09, 2024 at 10:24:43PM -0500, A Tammy wrote:
> > > > >
> > > > > On 1/9/24 18:29, Chaz Kettleson wrote:
> > > > > > On Wed, Jan 10, 2024 at 12:01:59AM +0300, Kirill Bychkov wrote:
> > > > > >> On Tue, January 9, 2024 23:22, Chaz Kettleson wrote:
> > > > > >> Hi,
> > > > > >>> On Sun, Jan 07, 2024 at 05:04:57PM +, Stuart Henderson wrote:
> > > > > On 2024/01/07 01:15, Chaz Kettleson wrote:
> > > > > > Hello,
> > > > > >
> > > > > > This is my first port. I'm looking for mentorship, testing, and
> > > > > > feedback
> > > > > > to eventually get this committed. I've read the porting guide,
> > > > > > bsd.port.mk(5), rc.subr(8), and login.conf(5) when making this
> > > > > > port.
> > > > > >
> > > > > > This is a port for open Home Automation Bus
> > > > > > https://www.openhab.org/.
> > > > > > From the project github and DESCR:
> > > > > >
> > > > > > The open Home Automation Bus (openHAB) project aims at
> > > > > > providing a
> > > > > > universal integration platform for all things around home
> > > > > > automation.
> > > > > > It is a pure Java solution, fully based on OSGi.
> > > > > >
> > > > > > It is designed to be vendor-neutral as well as
> > > > > > hardware/protocol-agnostic.
> > > > > > openHAB brings together different bus systems, hardware devices,
> > > > > > and interface protocols by dedicated bindings. These bindings
> > > > > > send
> > > > > > and receive commands and status updates on the openHAB event
> > > > > > bus.
> > > > > > This concept allows designing user interfaces with a unique
> > > > > > look&feel,
> > > > > > but with the possibility to operate devices based on a big
> > > > > > number
> > > > > > of different technologies. Besides the user interfaces, it also
> > > > > > brings the power of automation logic across different system
> > > > > >
> > > > > > I had a few challenges when making this port.
> > > > > >
> > > > > > Firstly, there is no archive root when extracting the distfile.
> > > > > > Initially
> > > > > > I had set ${WRKDIST}=${WRKDIR} and had do-install copy
> > > > > > everything from
> > > > > > ${WRKDIST}. This turned out to be a problem with 'make fake'
> > > > > > since it was
> > > > > > recursively trying to copy fake-amd64. I eventually opted to
> > > > > > override
> > > > > > EXTRACT_CASES for tar.gz to create a subdir and extract there.
> > > > > > I was
> > > > > hoping
> > > > > > for a variable that might let me set a directory instead, but I
> > > > > > imagine
> > > > > most
> > > > > > distfiles extract with an archive root.
> > > > > >
> > > > > > Secondly, I considered using the javaPathHelper within the rc
> > > > > > file, but
> > > > > > ultimately opted to use the scripts that come with Apache
> > > > > > Karaf. The
> > > > > > start.sh packaged with openHAB just calls these under the hood.
> > > > > > They do
> > > > > > a lot of bootstrapping for the environment, so calling java
> > > > > > directly
> > > > > > would cause a number of issues. Unfortunately, these scripts
> > > > > > rely on
> > > > > > the JAVA_HOME environment variable to be set. I packaged a
> > > > > > openhab.login
> > > > > > so I could set this variable via setenv. I was hoping the
> > > > > > packaging
> > > > > process
> > > > > > would allow me to substitute build variables similar to the rc
> > > > > > file. This
> > > > > > way
> > > > > > I could do something like:
> > > > > >
> > > > > > :setenv=JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h openhab"
> > > > > >
> > > > > > I quickly realized it wasn't doing it when $ was substituted
> > > > > > for the user
> > > > > > per login.conf(5) and copied verbatim. This left me no choice
> > > > > > but to
> > > > > > hard-code the path (perhaps logic could be added for this case?)
> > > > > Here it is with a few tweaks;
> > > > >
> > > > > - handling extraction and JAVA_HOME in a bit more of a simple
> > > > > way,
> > > > > no need for login.conf
> > > > > - no need for a separate OPENHAB_HOME, we can just point PREFIX
> > > > > there
> > > > > - don't repeat the name in COMMENT (where it's shown, PKGNAME is
> > > > > shown
> > > > > too, so that's redundant information), instead try to provide
> > > > > more
> > > > > of a brief description
> > > > > >>> Thank you! This is _much_ cleaner. I've
Re: [new] net/dnsq
On 2/20/24 11:04, Stuart Henderson wrote: On 2024/02/20 10:37, Renaud Allard wrote: On 2/20/24 10:19, Stuart Henderson wrote: On 2024/02/20 09:30, Renaud Allard wrote: Yes, the name doesn't tell anything by itself. Is this one better? The binary is still called q, but the package is dnsq. If naming the package dnsq, I'd suggest also adding a symlink, dnsq -> q. I have added the symlink No need for ONLY_FOR_ARCHS, it builds ok on i386. OK sthen@ to import. ping smime.p7s Description: S/MIME Cryptographic Signature
where is serious sam package?
hi list I don't know how long it takes for ports to be added, I just want to know it's not forgotten https://www.mail-archive.com/ports@openbsd.org/msg122960.html there is also non-alpha version of the game here and apparently supports OpenBSD https://github.com/tx00100xt/SeriousSamClassic-VK thanks have nice day
