Re: [MAINTAINER UPDATE]: www/mycorrhiza to 1.15.0
On 7/1/24 16:59, la ninpre wrote:
Hello,
mycorrhiza has been updated to 1.15.0.
This version incorporates changes over 15 months.
Notable changes:
- special links for today's date
- ability to change passwords
- css for pdf and printing
- go version required lifted to go1.22
- fix of a longstanding renaming bug
See full changelog: https://mycorrhiza.wiki/hypha/release/1.15
Comments, ok?
best regards,
la ninpre
Hello,
The new version works on my machine, however the provided man page
is still not included in the updated port which is unfurtonate. The
following amendment to your patch should take care of this neglect.
Index: Makefile
===
RCS file: /cvs/ports/www/mycorrhiza/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile12 Apr 2023 09:32:11 - 1.4
+++ Makefile2 Jul 2024 15:55:25 -
@@ -1,7 +1,7 @@
COMMENT = plain-text driven engine for personal wikis
MODGO_MODNAME = github.com/bouncepaw/mycorrhiza
-MODGO_VERSION =v1.14.0
+MODGO_VERSION =v1.15.0
DISTNAME = mycorrhiza-${MODGO_VERSION}
@@ -19,6 +19,9 @@ WANTLIB += c pthread
MODULES = lang/go
RUN_DEPENDS = devel/git
+
+post-install:
+ ${INSTALL_MAN} ${WRKSRC}/help/mycorrhiza.1 ${PREFIX}/man/man1/
.include "modules.inc"
Index: distinfo
===
RCS file: /cvs/ports/www/mycorrhiza/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo12 Apr 2023 09:32:11 - 1.3
+++ distinfo2 Jul 2024 15:55:25 -
@@ -1,5 +1,5 @@
-SHA256 (go_modules/git.sr.ht/~bouncepaw/mycomarkup/v5/@v/v5.4.0.mod) =
L51xy10F0ZU2tmQkoFnYI2AjTv4GmNcDZxDlHpaF3tE=
-SHA256 (go_modules/git.sr.ht/~bouncepaw/mycomarkup/v5/@v/v5.4.0.zip) =
Ud94xXE95bNpcQoBkzMzo8kkKzjcZkl9XAjHCpx0+ec=
+SHA256 (go_modules/git.sr.ht/~bouncepaw/mycomarkup/v5/@v/v5.6.0.mod) =
L51xy10F0ZU2tmQkoFnYI2AjTv4GmNcDZxDlHpaF3tE=
+SHA256 (go_modules/git.sr.ht/~bouncepaw/mycomarkup/v5/@v/v5.6.0.zip) =
I6/F8QuudOUaiUWMeKcIvF/wrW+siVqBLQkko9de3x4=
SHA256 (go_modules/github.com/andybalholm/brotli/@v/v1.0.2.mod) =
hWZkf7zU9nc3KiYxeKry8ncpsFfcIYf9EZS+yYgwx8k=
SHA256 (go_modules/github.com/andybalholm/brotli/@v/v1.0.3.mod) =
gLn5QXXMYZiLSYDdCzyCwBdJQP93fYIOJhrmAA+H1xM=
SHA256 (go_modules/github.com/andybalholm/brotli/@v/v1.0.3.zip) =
HXjtY7wKJvINBW8oDhK7yD769Opg2kz0d9+hLgzNpCE=
@@ -9,21 +9,21 @@ SHA256 (go_modules/github.com/go-ini/ini
SHA256 (go_modules/github.com/go-ini/ini/@v/v1.63.2.zip) =
0xUHX6KjcIGJ+lOuSi1g259fZObSIv+vW4T3k9py4CY=
SHA256 (go_modules/github.com/golang/snappy/@v/v0.0.3.mod) =
9W3ryXZbhJKXn++jEgm2fJYn2Q4kacYVnJQNr20kmQU=
SHA256 (go_modules/github.com/golang/snappy/@v/v0.0.3.zip) =
9rXjW9Hh01taZ8ipG/dtQDQmzjZpeDr4K2bAJU5ODaU=
-SHA256 (go_modules/github.com/gorilla/feeds/@v/v1.1.1.mod) =
5rx1j6V5+hKoKjhl2ds7oP0Wm1ZWjlFhl3yJYqa0bHU=
-SHA256 (go_modules/github.com/gorilla/feeds/@v/v1.1.1.zip) =
UZx+vvJG6E+rfcK3tEecTuGKtPwXij2MN5yw+wa0Td0=
+SHA256 (go_modules/github.com/gorilla/feeds/@v/v1.1.2.mod) =
uWPP2JnxwccGpEKOgfQdZS4s022kLSXbIL1KgDNhp4I=
+SHA256 (go_modules/github.com/gorilla/feeds/@v/v1.1.2.zip) =
w7x8KmoevCDfNVWN3S/xmaA0LiASscxFQs1/Mo9i1lk=
SHA256 (go_modules/github.com/gorilla/mux/@v/v1.8.0.mod) =
R/lPOCkTbcy7qn88QRD3QNs3/5Dd555rM2xzLh/ajZw=
SHA256 (go_modules/github.com/gorilla/mux/@v/v1.8.0.zip) =
dkGRHgCvnJHwiYaDMwZ8nLmlhwLSyeqCHuN0lACRw4U=
SHA256 (go_modules/github.com/klauspost/compress/@v/v1.13.4.mod) =
H9DJliVjOQBLcVctcHaMMJLXSs3bXzZIURU8F5Fjwyg=
SHA256 (go_modules/github.com/klauspost/compress/@v/v1.13.5.mod) =
hzMbvVb5EFUKSEj77nhRzEOqVpvKMdlECSZU8IrPby4=
SHA256 (go_modules/github.com/klauspost/compress/@v/v1.13.5.zip) =
5beJ5Ibx5FTvAjRMgjWhpOKF17jdgB/41mf85jCfM1U=
-SHA256 (go_modules/github.com/kr/pretty/@v/v0.2.1.mod) =
wq4ovVu46PkHaVUSZ2irehR5Ut7qn9vLNzxTzBiHD4I=
-SHA256 (go_modules/github.com/kr/pretty/@v/v0.2.1.zip) =
gK8EUgggUtGzJl18uJhdRk1L4iLCfhRljpVjLCInYeU=
-SHA256 (go_modules/github.com/kr/pty/@v/v1.1.1.mod) =
baTJxzZERolOXvh34Z+YXNUdZxzm6PTKh4YrRJ9t1/Y=
-SHA256 (go_modules/github.com/kr/pty/@v/v1.1.1.zip) =
EEdNeodcvSuddMm7j7mSZLeGPyBMdhBgd5f/GNWAvwA=
-SHA256 (go_modules/github.com/kr/text/@v/v0.1.0.mod) =
L7qVKeXBPd5i83Hvc4O68E1xMlAdrGqgjpEPnsC/hcU=
-SHA256 (go_modules/github.com/kr/text/@v/v0.1.0.zip) =
k2OkyPHzOHo2AU3lG0d7gxoTmB/FmlZl+dIWCb6p53w=
+SHA256 (go_modules/github.com/kr/pretty/@v/v0.3.1.mod) =
hPPkCAOx69SoAuVXlLmZffCxc8SAnoVy/5BC7FWMobw=
+SHA256 (go_modules/github.com/kr/pretty/@v/v0.3.1.zip) =
7PWkrySCbDrXWM4GQQygji1Y5NlQU747nd4uFIUsDNw=
+SHA256 (go_modules/github.com/kr/text/@v/v0.2.0.mod) =
9jh5sgT2zolc6lNZS4FPWsCvCEhrM7HKecZXOE77xyY=
+SHA256 (go_modules/github.com/kr/text/@v/v0.2.0.zip) =
No6zGPkaW2e+kFxHAyq1wxodSal4SLEBGg0KISKzC6Q=
SHA256 (go_modules/github.com/pmezard/go-difflib/@v/v1.0.0.mod) =
dLLnZushU3eGTVh7rfV+lVIfaS0qeGCzx3WQk/nJvsI=
SHA256
Re: [MAINTAINER UPDATE] security/lego v4.16.1 -> 4.17.3
DESC should be updated to inform that it uses ARI-03 now, not ARI-01. On 6/4/24 00:13, Horia Racoviceanu wrote: - Upgrade to v4.17.3 Changelog fix: disable snap release chore: fix snapcraft release pdns: reconstruct zone URLs to enable non-root folder API endpoints dode: update API URL chore: update linter chore: remove remaining deprecated ARI call chore: remove useless file chore: update linter godaddy: documentation new API limitations route53: adds option to not wait for changes azuredns: use TenantID also for cli authentication feat: renewal retry after value exoscale: simplify record creation ovh: add OAuth2 authentication exec: stream command output feat: add LEGO_ISSUER_CERT_PATH to hook feat: fills LEGO_CERT_PFX_PATH and LEGO_CERT_PEM_PATH only when needed chore: update dependencies oracle: update API client Add DNS provider for Selectel v2 chore: fix typos httpnet: add provider to NewDNSChallengeProviderByName docs: fix link to alibaba API documentation chore: update to go1.22 azuredns: servicediscovery for zones scaleway: add alternative env var names chore: add snap to release packages
Go default LDFLAGS behavior
Hello,
How are default LDFLAGS for Go ports applied considering they are set
after they're included into the build command? I don't see those options
in the output when running make and the resulting binary is in its
standard size. However when I relocate the flag settings into the upper
part of the script as in the provided diff, it works as expected and I
get greeted with a shrunk binary. I think the default settings are
skipped on the official build server too, because Go binaries on mirrors
are similarly large.
Could anyone clue me in if this behavior is still correct and I'm just
misunderstanding something?
Index: go.port.mk
===
RCS file: /cvs/ports/lang/go/go.port.mk,v
retrieving revision 1.66
diff -u -p -r1.66 go.port.mk
--- go.port.mk 21 Feb 2024 12:28:57 - 1.66
+++ go.port.mk 27 Feb 2024 15:23:27 -
@@ -58,6 +58,11 @@ MODGO_LIST_CMD = ${MODGO_CMD} list ${MOD
MODGO_TEST_CMD = ${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
MODGO_BINDIR ?=bin
+.if empty(DEBUG)
+# by default omit symbol table, debug information and DWARF symbol table
+MODGO_LDFLAGS += -s -w
+.endif
+
.if ! empty(MODGO_LDFLAGS)
MODGO_BUILD_CMD += -ldflags="${MODGO_LDFLAGS}"
MODGO_LIST_CMD += -ldflags="${MODGO_LDFLAGS}"
@@ -111,10 +116,7 @@ CATEGORIES += lang/go
MODGO_BUILD_TARGET = ${MODGO_BUILD_CMD} ${ALL_TARGET}
MODGO_FLAGS += -v -buildvcs=false -p=${MAKE_JOBS}
-.if empty(DEBUG)
-# by default omit symbol table, debug information and DWARF symbol table
-MODGO_LDFLAGS += -s -w
-.else
+.if ! empty(DEBUG)
MODGO_FLAGS += -x
.endif
Re: dnscrypt-proxy: Unable to set the close on exec flag: [function not implemented]
Hi, Unfortunately many such cases lately in Go software. I think it's due to the syscall removal thing introduced with https://marc.info/?l=openbsd-ports-cvs=170057559813269=2 because it still works if you build it with a previous revision of Go. On 1/3/24 17:14, Florian Obser wrote: Hi there, dnscrypt-proxy fails thusly on -current: Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: dnscrypt-proxy 2.1.5 Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: Network connectivity detected Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: Dropping privileges Jan 3 17:07:29 x395 dnscrypt-proxy[54029]: Unable to set the close on exec flag: [function not implemented]
Re: [new] mail/alps
Ping
On 9/7/23 22:05, Igor Zornik wrote:
On 9/6/23 18:14, Omar Polo wrote:
Hello,
On 2023/08/19 10:04:54 +0200, Igor Zornik wrote:
Greetings ports@,
Long time listener, but first time caller so I hope I didn't get to many
things wrong.
Sorry for the delay. I wanted to review this the day it was sent
but only managed to look at it today.
Attached I have a port of alps, an e-mail web client. It's not as
feature-full as some other web clients, but I like this one because it
has not run-time dependencies which makes it easier to deploy and maintain.
Notes:
- Port initially created with `portgen`. When modified I relied heavily
on gitea port.
- Upstream isn't very responsive to my change proposals so I provided
some fixes and features locally.
- There isn't any special functionality associated with the service
account so I just made it to run as `www`. Should I still run it under a
dedicated service account?
- I had to do some `sed` trick in the `rc` script to get the `rc`
command to pick up the daemon properly. Could anyone confirm if i have
taken the right path here?
- Tested on amd64 using -current and 7.2.
Any comments or suggestions?
a few nits, but otherwise it's a solid submission.
- I'd add some commentary to the patches. Just something brief like
"adding FastCGI support", so that it's clear what it does when
skimming the files.
- I'd drop the patch for go.mod; I'm not sure go.port.mk even looks
at the fetched go.mod file, let alone parsing it once patched.
- there's a small error in the fastcgi patch:
+ addr = strings.TrimPrefix(addr, "fcgi+unix:/")
should be
+ addr = strings.TrimPrefix(addr, "fcgi+unix://")
i.e. remove two slashes. In practice it's not an issue.
- While I really like the fastcgi support (I'm a bit lazy and never
bothered to learn how to use relayd), I don't think we've usually
patched the ports to add features like these. Have you sent the
patch upstream? I can't find it searching for 'fastcgi' on
sourcehut.
To be fair I don't think it's an issue, but still felt like
pointing this out.
- It doesn't work without altering the flags to specify the upstream
server. This has confused me initially, so add that info to the
README.
I've also tweaked the fastcgi example to use `rcctl set alps flags'
and add a dummy example.com at the end to minimize the chance of
getting things wrong.
- (opinable) I've tweaked the http example to listen on port 80.
Otherwise it's not copy-paste-able without further fiddling.
- I'm not sure about ${SYSCONFDIR}/httpd.conf. Even if portcheck
complains, the correct path is /etc/httpd.conf: it is hardcoded in
the httpd(8) binary.
- make update-plist changed @cwd ${LOCALSTATEDIR}/www into /var/www
and I'm not sure how much we care about using the variables instead
of the hardcoded paths. Left as /var for the moment.
- no opinion on the sed machinery to escape '+'s in the pexp. Seems
to work :-)
- changed the version to 0.0.0. so if upstream starts to do
proper releases we don't have to use EPOCH.
I'm reattaching a tarball with these points addressed. It's ok op@ to
import if someone wants to, otherwise i'll be happy to import it
myself (needs an ok to do so).
I don't use web ui for mails if I can, but this is one of the nicer
I've seen.
Ciao!
Thanks for taking your time with the port. I'm just replying to say that
even with the changes it still works on my machine. Also to clarify a
few points.
> I'd add some commentary to the patches.
Nice tip. I didn't know you could include comments like that in a patch.
It does mess up syntax highlighting in some editors though.
> Have you sent the patch upstream?
Patch for FCGI has not been sent to upstream yet because I'm still
waiting for the response on the first patch proposal (the `go.mod` one).
In due time I'll probably just consider it rejected and move on to the
next proposal.
> It doesn't work without altering the flags to specify the upstream
server. This has confused me initially, so add that info to the README.
I've only included things that aren't mentioned in the original
documentation. But if a little coping saves some confusion then it's OK.
I would however like to suggest some changes for the new README for
consistency sake (see attached diff):
Anyhow, looking forward to submitting additional ports.
With regards,
Re: [new] mail/alps
Ciao!
Thanks for taking your time with the port. I'm just replying to say that
even with the changes it still works on my machine. Also to clarify a
few points.
> I'd add some commentary to the patches.
Nice tip. I didn't know you could include comments like that in a patch.
It does mess up syntax highlighting in some editors though.
> Have you sent the patch upstream?
Patch for FCGI has not been sent to upstream yet because I'm still
waiting for the response on the first patch proposal (the `go.mod` one).
In due time I'll probably just consider it rejected and move on to the
next proposal.
> It doesn't work without altering the flags to specify the upstream
server. This has confused me initially, so add that info to the README.
I've only included things that aren't mentioned in the original
documentation. But if a little coping saves some confusion then it's OK.
I would however like to suggest some changes for the new README for
consistency sake (see attached diff):
Anyhow, looking forward to submitting additional ports.
With regards,
--
IZ
https://mocheryl.org/ | moche...@mocheryl.org | 041/517-106
On 9/6/23 18:14, Omar Polo wrote:
Hello,
On 2023/08/19 10:04:54 +0200, Igor Zornik wrote:
Greetings ports@,
Long time listener, but first time caller so I hope I didn't get to many
things wrong.
Sorry for the delay. I wanted to review this the day it was sent
but only managed to look at it today.
Attached I have a port of alps, an e-mail web client. It's not as
feature-full as some other web clients, but I like this one because it
has not run-time dependencies which makes it easier to deploy and maintain.
Notes:
- Port initially created with `portgen`. When modified I relied heavily
on gitea port.
- Upstream isn't very responsive to my change proposals so I provided
some fixes and features locally.
- There isn't any special functionality associated with the service
account so I just made it to run as `www`. Should I still run it under a
dedicated service account?
- I had to do some `sed` trick in the `rc` script to get the `rc`
command to pick up the daemon properly. Could anyone confirm if i have
taken the right path here?
- Tested on amd64 using -current and 7.2.
Any comments or suggestions?
a few nits, but otherwise it's a solid submission.
- I'd add some commentary to the patches. Just something brief like
"adding FastCGI support", so that it's clear what it does when
skimming the files.
- I'd drop the patch for go.mod; I'm not sure go.port.mk even looks
at the fetched go.mod file, let alone parsing it once patched.
- there's a small error in the fastcgi patch:
+ addr = strings.TrimPrefix(addr, "fcgi+unix:/")
should be
+ addr = strings.TrimPrefix(addr, "fcgi+unix://")
i.e. remove two slashes. In practice it's not an issue.
- While I really like the fastcgi support (I'm a bit lazy and never
bothered to learn how to use relayd), I don't think we've usually
patched the ports to add features like these. Have you sent the
patch upstream? I can't find it searching for 'fastcgi' on
sourcehut.
To be fair I don't think it's an issue, but still felt like
pointing this out.
- It doesn't work without altering the flags to specify the upstream
server. This has confused me initially, so add that info to the
README.
I've also tweaked the fastcgi example to use `rcctl set alps flags'
and add a dummy example.com at the end to minimize the chance of
getting things wrong.
- (opinable) I've tweaked the http example to listen on port 80.
Otherwise it's not copy-paste-able without further fiddling.
- I'm not sure about ${SYSCONFDIR}/httpd.conf. Even if portcheck
complains, the correct path is /etc/httpd.conf: it is hardcoded in
the httpd(8) binary.
- make update-plist changed @cwd ${LOCALSTATEDIR}/www into /var/www
and I'm not sure how much we care about using the variables instead
of the hardcoded paths. Left as /var for the moment.
- no opinion on the sed machinery to escape '+'s in the pexp. Seems
to work :-)
- changed the version to 0.0.0. so if upstream starts to do
proper releases we don't have to use EPOCH.
I'm reattaching a tarball with these points addressed. It's ok op@ to
import if someone wants to, otherwise i'll be happy to import it
myself (needs an ok to do so).
I don't use web ui for mails if I can, but this is one of the nicer
I've seen.
--- pkg/README Wed Sep 6 17:40:55 2023
+++ pkg/README Thu Sep 7 21:56:34 2023
@@ -11,8 +11,8 @@ configured to run behind HTTP proxy like relayd(8) or
Another option is to let OpenBSD httpd(8) serve HTTP(S) requests
and pass it to alps via FastCGI protocol.
-In every case, it needs to be told the upstream server. Assuming SRV
-DNS records are properly set up:
+In every case, it needs to be told the upstream server. Assumi
[new] mail/alps
Greetings ports@, Long time listener, but first time caller so I hope I didn't get to many things wrong. Attached I have a port of alps, an e-mail web client. It's not as feature-full as some other web clients, but I like this one because it has not run-time dependencies which makes it easier to deploy and maintain. Notes: - Port initially created with `portgen`. When modified I relied heavily on gitea port. - Upstream isn't very responsive to my change proposals so I provided some fixes and features locally. - There isn't any special functionality associated with the service account so I just made it to run as `www`. Should I still run it under a dedicated service account? - I had to do some `sed` trick in the `rc` script to get the `rc` command to pick up the daemon properly. Could anyone confirm if i have taken the right path here? - Tested on amd64 using -current and 7.2. Any comments or suggestions? With regards, -- IZ alps-20230809211724.tgz Description: application/compressed-tar
