Re: new: devel/stylua
On Thu, 17 Aug 2023 20:21 +0200, Omar Polo wrote: > don't feel strongly about SEPARATE_BUILD but I'd propend to skip it. > It's ok op@ to import either way. > > Thanks! I'm OK with skipping it. :) Bumping this and reattaching the tarball you sent in response to mine. stylua.tar.gz Description: application/tar-gz
NEW: textproc/domain-sift
Hi. :) domain-sift is a tool I wrote in Perl to extract domains from files/STDIN and format + print the domains to STDOUT. I use it along with unwind/unbound on machines running OpenBSD to block malicious/unwanted domains. domain-sift uses OpenBSD::Pledge(3p) and OpenBSD::Unveil(3p). Home page: https://www.anthes.is/domain-sift.html Github: https://github.com/3uryd1ce/domain-sift Builds and installs on amd64 7.3-current. Tests run and succeed. Feedback/OK? Feedback on the code and/or documentation is OK, too. Though if it's minor stuff I'd prefer to get domain-sift into the ports tree first and then release a new version + submit a diff. domain-sift-0.1.2.tgz Description: application/tar-gz
Re: Question about updating devel/pygame
Forgot to attach the diff.
Index: Makefile
===
RCS file: /cvs/ports/devel/pygame/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile26 Nov 2022 23:28:13 - 1.49
+++ Makefile29 Aug 2023 19:54:35 -
@@ -1,7 +1,6 @@
COMMENT= set of Python modules designed for writing games
-MODPY_EGG_VERSION =2.0.1
-REVISION= 4
+MODPY_EGG_VERSION =2.5.1
DISTNAME= pygame-${MODPY_EGG_VERSION}
PKGNAME = py-game-${MODPY_EGG_VERSION}
CATEGORIES=devel games
@@ -11,8 +10,8 @@ HOMEPAGE= https://www.pygame.org/
# LGPLv2.1
PERMIT_PACKAGE=Yes
-WANTLIB += SDL SDL_image SDL_mixer SDL_ttf X11 jpeg png pthread
-WANTLIB += freetype z ${MODPY_WANTLIB}
+WANTLIB += SDL2 SDL2_image SDL2_mixer SDL2_ttf X11 freetype jpeg
+WANTLIB += png ${MODPY_WANTLIB}
MODULES = lang/python
@@ -22,14 +21,14 @@ FLAVOR ?=
MODPY_PI = Yes
MODPY_SETUPTOOLS = Yes
-LIB_DEPENDS= devel/sdl-ttf \
- devel/sdl-image \
- devel/sdl-mixer
+LIB_DEPENDS= devel/sdl2-ttf \
+ devel/sdl2-image \
+ devel/sdl2-mixer
TEST_DEPENDS = ${BUILD_PKGPATH}
MAKE_ENV+= LOCALBASE="${LOCALBASE}" \
- SDL_CONFIG="${LOCALBASE}/bin/sdl-config"
+ SDL_CONFIG="${LOCALBASE}/bin/sdl2-config"
EXAMPLESDIR= ${PREFIX}/share/examples/${MODPY_PY_PREFIX}pygame
DOCDIR=${PREFIX}/share/doc/${MODPY_PY_PREFIX}pygame
@@ -38,8 +37,8 @@ TEST_IS_INTERACTIVE= x11
TEST_ENV = PYTHONPATH=${WRKSRC}
do-configure:
- ${SUBST_CMD} ${WRKSRC}/buildconfig/Setup.SDL1.in
- @cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${MODPY_BIN}
buildconfig/config.py -auto -sdl1
+ ${SUBST_CMD} ${WRKSRC}/buildconfig/Setup.SDL2.in
+ @cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${MODPY_BIN} setup.py -config
-auto
post-install:
${INSTALL_DATA_DIR} ${EXAMPLESDIR}
@@ -49,7 +48,6 @@ post-install:
${INSTALL_SCRIPT} ${WRKSRC}/examples/data/* ${EXAMPLESDIR}/data
${INSTALL_DATA_DIR} ${DOCDIR}
${INSTALL_DATA} ${WRKSRC}/README.rst ${DOCDIR}
- ${INSTALL_DATA} ${WRKSRC}/docs/*.{gif,html} ${DOCDIR}
.for i in ref tut
${INSTALL_DATA_DIR} ${DOCDIR}/$i
${INSTALL_DATA} `find ${WRKSRC}/docs/reST/$i -maxdepth 1 -type f` \
Index: distinfo
===
RCS file: /cvs/ports/devel/pygame/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo14 Jan 2021 06:37:35 - 1.12
+++ distinfo29 Aug 2023 19:54:35 -
@@ -1,2 +1,2 @@
-SHA256 (pygame-2.0.1.tar.gz) = ix57Y/R6r83YhJkzsgZ3h0fvGAK9PVJqykXtdxQeQAE=
-SIZE (pygame-2.0.1.tar.gz) = 5536907
+SHA256 (pygame-2.5.1.tar.gz) = t/iHIL5cdAV2/ZiNwDdTKNwa2wcIaWVKJFUx4D30YmI=
+SIZE (pygame-2.5.1.tar.gz) = 15779748
Index: patches/patch-buildconfig_Setup_SDL2_in
===
RCS file: patches/patch-buildconfig_Setup_SDL2_in
diff -N patches/patch-buildconfig_Setup_SDL2_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-buildconfig_Setup_SDL2_in 29 Aug 2023 19:54:35 -
@@ -0,0 +1,11 @@
+Index: buildconfig/Setup.SDL2.in
+--- buildconfig/Setup.SDL2.in.orig
buildconfig/Setup.SDL2.in
+@@ -56,6 +56,7 @@ base src_c/base.c $(SDL) $(DEBUG)
+ color src_c/color.c $(SDL) $(DEBUG)
+ constants src_c/constants.c $(SDL) $(DEBUG)
+ display src_c/display.c $(SDL) $(DEBUG)
++display src_c/display.c $(SDL) $(DEBUG) -I${X11BASE}/include
+ event src_c/event.c $(SDL) $(DEBUG)
+ key src_c/key.c $(SDL) $(DEBUG)
+ mouse src_c/mouse.c $(SDL) $(DEBUG)
Index: patches/patch-src_c_camera_h
===
RCS file: /cvs/ports/devel/pygame/patches/patch-src_c_camera_h,v
retrieving revision 1.3
diff -u -p -r1.3 patch-src_c_camera_h
--- patches/patch-src_c_camera_h11 Mar 2022 18:53:06 - 1.3
+++ patches/patch-src_c_camera_h29 Aug 2023 19:54:35 -
@@ -1,29 +1,34 @@
Index: src_c/camera.h
--- src_c/camera.h.orig
+++ src_c/camera.h
-@@ -41,9 +41,12 @@
- /* on freebsd there is no asm/types */
- #ifdef linux
- #include /* for videodev2.h */
-+#include
- #endif
+@@ -42,11 +42,15 @@
+ /* on freebsd there is no asm/types */
+ #ifdef linux
+ #include /* for videodev2.h */
++#include
+ #endif
--#include
-+#ifdef __OpenBSD__
-+#include
-+#endif
- #elif defined(__APPLE__)
- #include
- /* We support OSX 10.6 and below. */
-@@ -167,7 +170,11 @@ char** v4l2_list_cameras (int* num_devices);
- int v4l2_get_control (int fd, int id, int *value);
- int v4l2_set_control (int fd, int id, int value);
- PyObject* v4l2_read_raw (pgCameraObject* self);
+-#include
+#ifdef __OpenBSD__
-+int v4l2_xioctl (int fd, unsigned long request, void *arg);
++#include
+ #endif
+
++#endif
++
+ #if
Question about updating devel/pygame
Hi, I have a diff for devel/pygame to bring it up to version 2.5.1, but I noticed that Python 2 and SDL1 support were deprecated in 2.0.3. https://github.com/pygame/pygame/releases/tag/2.0.3 These are the ports that were yielded by `make show-required-by`, and they all contain MODPY_DEFAULT_VERSION_2 in their Makefiles: games/fretsonfire productivity/bruce games/forcedattack games/pathological games/mysticmine games/renpy games/pyganim My question is this: is there a way to update this port without breaking the ports that depend on it, or would a new port need to be created? This is the first time I've run into a situation like this and I'd like to get some feedback before I forge ahead. I've attached my current diff for review and suggestions.
Re: update productivity/timewarrior
On Thu, 3 Aug 2023 22:55 +0100, Stuart Henderson wrote:
> On 2023/08/03 12:24, Ashlen wrote:
> > On Thu, 3 Aug 2023 17:37 +0100, Stuart Henderson wrote:
> > > you can get tests to run with these (and this also needs
> > > SEPARATE_BUILD = No otherwise when it builds the .t binaries, it puts
> > > them in the build dir, and there's nothing setup to replace the MacOS
> > > binaries present in the test dir in the tar).
> > >
> > > TEST_DEPENDS =${MODPY_RUN_DEPENDS}
> > > USE_NINJA = No
> >
> > Thank you. I have zero experience with C++ and so I know very little
> > about its build systems.
> >
> > > > +# Hack to get rid of empty CMakeFiles directories on 1.5.0. Check to
> > > > see
> > > > +# if this is still necessary next release.
> > > > +pre-install:
> > > > + rmdir ${WRKBUILD}/doc/man1/CMakeFiles
> > > > + rmdir ${WRKBUILD}/doc/man7/CMakeFiles
> > >
> > > I'd go for a tweak to simplify a little and put the comment where make
> > > will display it on-screen when run, so it's immediately obvious what's
> > > going on if things change in a future update.
> >
> > I like this solution, I didn't think to do it like that.
> >
> > > so here's a diff with those added, a quick change to the comment
> > > about out-of-source builds (the PR was committed upstream, but it
> > > doesn't cover the files which just contain .so manpage links;
> > > timew-day, timew-week, timew-month).
> > >
> > > builds and all regression tests pass; I don't use this myself so not
> > > tested runtime
> >
> > Runtime works for me so far.
> >
> > The timewarrior line in TEST_DEPENDS causes `make test` to fail for
> > me with this:
> >
> > ===> timewarrior-1.5.0 depends on: timewarrior-=1.5.0 - default
> > timewarrior-1.1.1p0 does not match
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2294
> > '/usr/obj/ports/timewarrior-1.5.0/.dep-timewarrior--1.5.0-productivity-timewarrior,')
> > *** Error 2 in /usr/ports/mystuff/productivity/timewarrior
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2612 'test':
> > @lock=timewarrior-1.5.0; ...)
> >
> > I'm gathering that this will probably work after commit based on
> > the error? I tested without that line and with timewarrior uninstalled,
> > and it fails on help.t as you mentioned in the comment.
> >
> > I didn't quite understand how `timewarrior-=${VERSION}:${BUILD_PKGPATH}`
> > works. I did see the explanation for `:old_string=new_string` in
> > make(1), but I don't get what -= does in this context. Can you help
> > me understand?
>
> This is in packages-specs(7) and sets the version number of the
> dependency.
>
> I guess you're working on this in a dir other than
> /usr/ports/productivity/taskwarrior but don't have PORTSDIR and/or
> PORTSDIR_PATH set to match?
Thank you, this was the problem. Tests run and pass as expected
when I use `PORTSDIR_PATH=/usr/ports/mystuff:/usr/ports make test`
instead of the default.
Are any other adjustments needed?
>
>
> > Thank you for the help + input, Stuart. I appreciate it. :)
> >
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/productivity/timewarrior/Makefile,v
> > > retrieving revision 1.5
> > > diff -u -p -r1.5 Makefile
> > > --- Makefile 11 Mar 2022 19:51:47 - 1.5
> > > +++ Makefile 3 Aug 2023 16:37:27 -
> > > @@ -1,35 +1,46 @@
> > > -COMMENT =command line tracking time tool
> > > +COMMENT =command line tracking time tool
> > >
> > > -VERSION =1.1.1
> > > -DISTNAME = timew-${VERSION}
> > > -PKGNAME =timewarrior-${VERSION}
> > > -CATEGORIES = productivity
> > > -REVISION = 0
> > > +VERSION =1.5.0
> > > +DISTNAME = timew-${VERSION}
> > > +PKGNAME =timewarrior-${VERSION}
> > > +CATEGORIES = productivity
> > >
> > > -HOMEPAGE = https://timewarrior.net/
> > > +HOMEPAGE = https://timewarrior.net/
> > >
> > > # MIT
> > > -PERMIT_PACKAGE = Yes
> > > +PERMIT_PACKAGE = Yes
> > >
> > > WANTLIB += c m ${COMPILER_LIBCXX}
> > >
> > > -MASTER_SITES = https://taskwarrior.org/downlo
Re: new: devel/selene
On Thu, 17 Aug 2023 08:36 +0200, Theo Buehler wrote:
> > Side note: I noticed MODCARGO_INSTALL_TARGET_PATH is undocumented
> > in cargo-module(5), along with MODCARGO_WANTLIB. Should they be
> > included in that man page?
>
> I have added a blurb for MODCARGO_INSTALL_TARGET_PATH after sending my
> previous mail. If you want to take a stab for MODCARGO_WANTLIB, that
> would be nice.
Sure, I've attached a diff that adds it to the list. Should some
of these be documented at some point as well?
grep -E '^MODCARGO(_[[:upper:]]+){1,}.*=' /usr/ports/devel/cargo/cargo.port.mk \
| cut -f 1 -d ' ' \
| sort -u \
| while read -r cargo_var; do
grep -q "${cargo_var}" /usr/src/share/man/man5/cargo-module.5 \
|| echo "${cargo_var}"
done
MODCARGO_BUILD
MODCARGO_BUILDDEP
MODCARGO_BUILD_ARGS
MODCARGO_BUILD_DEPENDS
MODCARGO_BUILD_TARGET
MODCARGO_CARGO_BIN
MODCARGO_CARGO_RUN
MODCARGO_CARGO_UPDATE
MODCARGO_CRATES_BUILDDEP
MODCARGO_CRATES_KEEP
MODCARGO_ENV
MODCARGO_INSTALL_ARGS
MODCARGO_MASTER_SITESN
MODCARGO_NO_DEFAULT_FEATURES
MODCARGO_TARGET_DIR
MODCARGO_TEST
MODCARGO_TEST_ARGS
MODCARGO_TEST_TARGET
> Since this uses ring, the Makefile needs this near the top:
>
> # ring-v0.16.20 does not support those archs
> NOT_FOR_ARCHS = powerpc64 riscv64 sparc64
>
> Could you please resend the tarball with the Makefile patch applied and
> this on top? That will make it easier for the committer who will import.
Yes, I've attached the new tarball as well.
devel-selene.tgz
Description: application/tar-gz
Index: cargo-module.5
===
RCS file: /cvs/src/share/man/man5/cargo-module.5,v
retrieving revision 1.5
diff -u -p -r1.5 cargo-module.5
--- cargo-module.5 17 Aug 2023 05:43:09 - 1.5
+++ cargo-module.5 17 Aug 2023 16:16:03 -
@@ -106,6 +106,8 @@ Needs to be set for some virtual manifes
Name of the local directory for vendoring crates.
Defaults to
.Pa ${WRKSRC}/modcargo-crates .
+.It MODCARGO_WANTLIB
+Needed Rust libraries, for use with WANTLIB.
.El
.Pp
This module adds three
Re: new: devel/stylua
On Thu, 17 Aug 2023 10:23 +0200, Omar Polo wrote:
> Some tweaks for the makefile:
>
> - the indentation of the value is off (you're not using tab multiples
>of 8 columns?)
I guess I forgot to `:set tabstop=8 shiftwidth=8`. Usually I prefer
values of 4 and adjust those manually as needed. I'll fix my neovim
config to set those to 8 when I'm working with ports.
> - homepage is already set by GH_*
>
> - to lower-case the package name you can just do PKGNAME=${DISTNAME:L}
>
> - typo on SEPARATE_BUILD (should be SEPARATED_BUILD)
I checked and SEPARATE_BUILD is right. I just rebuilt StyLua with
SEPARATE_BUILD to make sure that it works, so I think it should be
kept, right?
> - missing WANTLIBs
>
> not sure why CONFIGURE_STYLE is needed but the build fails otherwise
> and rust is out of my comfort zone. It also seem to build stuff
> during fake, don't know if it's usual for rust ports.
I don't write Rust, but there's this in cargo-module(5).
"""
With CONFIGURE_STYLE set to 'cargo', cargo is configured to use
MODCARGO_VENDOR_DIR instead of the standard crates-io network source.
"""
> It's sad that there's not documentation other than the README.md (that
> isn't much legible with less(1)). stylua -h | less seems like a
> manpage however, meh.
I agree, a man page would've been nicer.
Thank you for reviewing this, and apologies for the sloppy work.
Other than wanting to add SEPARATE_BUILD back in, your changes seem
good to me.
> Quickly tested the port, it doesn't like one file I wrote but
> otherwise seems to work fine.
>
> I'm attaching a diff against your makefile and an updated tarball.
> Provided the two points above are fine, ok op@ to import.
>
> --- Makefile.orig Thu Aug 17 09:43:06 2023
> +++ Makefile Thu Aug 17 10:18:31 2023
> @@ -1,22 +1,19 @@
> -COMMENT =opinionated Lua code formatter
> -V = 0.18.1
> -DISTNAME = stylua-${V}
> +COMMENT =opinionated Lua code formatter
>
> GH_ACCOUNT = JohnnyMorganz
> GH_PROJECT = StyLua
> -GH_TAGNAME = v${V}
> +GH_TAGNAME = v0.18.1
> +PKGNAME =${DISTNAME:L}
>
> CATEGORIES = devel
>
> -HOMEPAGE = https://github.com/JohnnyMorganz/StyLua
> -
> # Mozilla Public License 2.0
> PERMIT_PACKAGE = Yes
>
> -MODULES =devel/cargo
> -SEPARATE_BUILD = Yes
> +WANTLIB = ${MODCARGO_WANTLIB}
> +
> +MODULES =devel/cargo
> CONFIGURE_STYLE =cargo
>
> .include "crates.inc"
> -
> .include
Re: new: devel/selene
On Thu, 17 Aug 2023 07:10 +0200, Theo Buehler wrote:
> On Wed, Aug 16, 2023 at 11:01:38PM -0600, Ashlen wrote:
> > Selene is a modern Lua linter written in Rust.
> >
> > GitHub: https://github.com/Kampfkarren/selene
> > Docs: https://kampfkarren.github.io/selene/
> >
> > This was easy enough to port. Tests run and pass. do-install hook
> > seems to be needed due to a `Cargo.toml` issue.
>
> Try setting
>
> MODCARGO_INSTALL_TARGET_PATH = selene
>
> instead.
>
Thanks, I see your commit to devel/cargo/cargo.port.mk on 2023/07/24.
While there, I also changed WANTLIB to use MODCARGO_WANTLIB, and
adjusted tabs for alignment.
Side note: I noticed MODCARGO_INSTALL_TARGET_PATH is undocumented
in cargo-module(5), along with MODCARGO_WANTLIB. Should they be
included in that man page?
--- Makefile.orig Thu Aug 17 00:01:43 2023
+++ MakefileThu Aug 17 00:01:54 2023
@@ -1,31 +1,28 @@
-COMMENT = modern Lua linter written in Rust
+COMMENT = modern Lua linter written in Rust
-V =0.25.0
-DISTNAME = selene-${V}
+V =0.25.0
+DISTNAME = selene-${V}
-GH_ACCOUNT = Kampfkarren
-GH_PROJECT = selene
-GH_TAGNAME = ${V}
+GH_ACCOUNT = Kampfkarren
+GH_PROJECT = selene
+GH_TAGNAME = ${V}
-CATEGORIES = devel
+CATEGORIES = devel
-HOMEPAGE = https://kampfkarren.github.io/selene/
+HOMEPAGE = https://kampfkarren.github.io/selene/
-WANTLIB += c c++abi pthread
+WANTLIB += ${MODCARGO_WANTLIB}
# Mozilla Public License 2.0
-PERMIT_PACKAGE = Yes
+PERMIT_PACKAGE = Yes
-MODULES = devel/cargo
-CONFIGURE_STYLE = cargo
-SEPARATE_BUILD = Yes
+MODULES = devel/cargo
+CONFIGURE_STYLE = cargo
+SEPARATE_BUILD = Yes
-BUILD_DEPENDS =security/rust-ring
+BUILD_DEPENDS =security/rust-ring
-RELEASE_DIR = ${MODCARGO_TARGET_DIR}/release
-
-do-install:
- ${INSTALL_PROGRAM} ${RELEASE_DIR}/selene ${PREFIX}/bin/
+MODCARGO_INSTALL_TARGET_PATH = selene
.include "crates.inc"
new: devel/stylua
Description: """ An opinionated code formatter for Lua 5.1, 5.2, 5.3, 5.4 and Luau, built using full-moon. StyLua is inspired by the likes of prettier, it parses your Lua codebase, and prints it back out from scratch, enforcing a consistent code style. StyLua mainly follows the Roblox Lua Style Guide, with a few deviations. """ GitHub: https://github.com/JohnnyMorganz/StyLua This was easy enough to port, nothing interesting to say really. Tests run and pass. Tested runtime by using the formatter.nvim plugin. https://github.com/mhartington/formatter.nvim Suggestions/OKs? devel-stylua.tgz Description: application/tar-gz
new: devel/selene
Selene is a modern Lua linter written in Rust. GitHub: https://github.com/Kampfkarren/selene Docs: https://kampfkarren.github.io/selene/ This was easy enough to port. Tests run and pass. do-install hook seems to be needed due to a `Cargo.toml` issue. ===> Faking installation for selene-0.25.0 error: found a virtual manifest at `/usr/obj/ports/selene-0.25.0/selene-0.25.0/Cargo.toml` instead of a package manifest *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:376 'do-install': @cd /usr/obj/ports/selene-0.25.0/selene-0.25.0 && /usr/bin/env -i...) *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3079 '/usr/obj/ports/selene-0.25.0/fake-amd64/.fake_done': @cd /usr/ports/mystuff...) *** Error 2 in /usr/ports/mystuff/devel/selene (/usr/ports/infrastructure/mk/bsd.port.mk:2633 'fake': @lock=selene-0.25.0; export _LOCKS_HE...) Suggestions/OKs? devel-selene.tgz Description: application/tar-gz
Re: update productivity/timewarrior
On Thu, 3 Aug 2023 17:37 +0100, Stuart Henderson wrote:
> you can get tests to run with these (and this also needs
> SEPARATE_BUILD = No otherwise when it builds the .t binaries, it puts
> them in the build dir, and there's nothing setup to replace the MacOS
> binaries present in the test dir in the tar).
>
> TEST_DEPENDS =${MODPY_RUN_DEPENDS}
> USE_NINJA = No
Thank you. I have zero experience with C++ and so I know very little
about its build systems.
> > +# Hack to get rid of empty CMakeFiles directories on 1.5.0. Check to see
> > +# if this is still necessary next release.
> > +pre-install:
> > + rmdir ${WRKBUILD}/doc/man1/CMakeFiles
> > + rmdir ${WRKBUILD}/doc/man7/CMakeFiles
>
> I'd go for a tweak to simplify a little and put the comment where make
> will display it on-screen when run, so it's immediately obvious what's
> going on if things change in a future update.
I like this solution, I didn't think to do it like that.
> so here's a diff with those added, a quick change to the comment
> about out-of-source builds (the PR was committed upstream, but it
> doesn't cover the files which just contain .so manpage links;
> timew-day, timew-week, timew-month).
>
> builds and all regression tests pass; I don't use this myself so not
> tested runtime
Runtime works for me so far.
The timewarrior line in TEST_DEPENDS causes `make test` to fail for
me with this:
===> timewarrior-1.5.0 depends on: timewarrior-=1.5.0 - default
timewarrior-1.1.1p0 does not match
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2294
'/usr/obj/ports/timewarrior-1.5.0/.dep-timewarrior--1.5.0-productivity-timewarrior,')
*** Error 2 in /usr/ports/mystuff/productivity/timewarrior
(/usr/ports/infrastructure/mk/bsd.port.mk:2612 'test': @lock=timewarrior-1.5.0;
...)
I'm gathering that this will probably work after commit based on
the error? I tested without that line and with timewarrior uninstalled,
and it fails on help.t as you mentioned in the comment.
I didn't quite understand how `timewarrior-=${VERSION}:${BUILD_PKGPATH}`
works. I did see the explanation for `:old_string=new_string` in
make(1), but I don't get what -= does in this context. Can you help
me understand?
Thank you for the help + input, Stuart. I appreciate it. :)
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/productivity/timewarrior/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- Makefile 11 Mar 2022 19:51:47 - 1.5
> +++ Makefile 3 Aug 2023 16:37:27 -
> @@ -1,35 +1,46 @@
> -COMMENT =command line tracking time tool
> +COMMENT =command line tracking time tool
>
> -VERSION =1.1.1
> -DISTNAME = timew-${VERSION}
> -PKGNAME =timewarrior-${VERSION}
> -CATEGORIES = productivity
> -REVISION = 0
> +VERSION =1.5.0
> +DISTNAME = timew-${VERSION}
> +PKGNAME =timewarrior-${VERSION}
> +CATEGORIES = productivity
>
> -HOMEPAGE = https://timewarrior.net/
> +HOMEPAGE = https://timewarrior.net/
>
> # MIT
> -PERMIT_PACKAGE = Yes
> +PERMIT_PACKAGE = Yes
>
> WANTLIB += c m ${COMPILER_LIBCXX}
>
> -MASTER_SITES = https://taskwarrior.org/download/
> +MASTER_SITES =
> https://github.com/GothenburgBitFactory/timewarrior/releases/download/v${VERSION}/
>
> COMPILER = base-clang ports-gcc
>
> MODULES =devel/cmake \
> lang/python
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
> MODPY_RUNDEP = No
> MODPY_BUILDDEP = No
> MODPY_ADJ_FILES =ext/totals.py
>
> +BUILD_DEPENDS = textproc/asciidoctor
> +
> CONFIGURE_STYLE =cmake
>
> CONFIGURE_ARGS +=-DTIMEW_DOCDIR=share/doc/timewarrior
> -CONFIGURE_ARGS +=-DTIMEW_RCDIR=share/doc/timewarrior/rc
> -CONFIGURE_ARGS +=-DTIMEW_MAN1DIR=man/man1
> +CONFIGURE_ARGS +=-DTIMEW_MANDIR=man
> +
> +# test infrastructure only works with cmake make backend
> +# self-depend added to avoid failure in help.t test which checks
> +# that the (correct version's) manual is displayed
> +USE_NINJA = No
> +TEST_DEPENDS = ${MODPY_RUN_DEPENDS} \
> + timewarrior-=${VERSION}:${BUILD_PKGPATH}
> +
> +# tests and manpage creation fail with out-of-source-tree builds
> +# upstream commit dd330aa0db61 partially fixes manpages but not tests
> +SEPARATE_BUILD = No
>
> -NO_TEST =Yes
> +post-install:
> + rmdir ${PREFIX}/man/man{1,7}/CMakeFiles{/*,} # empty dirs present in
> 1.5.0
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/productivity/timewarrior/distinfo,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 17 May 2018 23:22:21 - 1.1.1.1
> +++ distinfo 3 Aug 2023 16:37:27 -
> @@ -1,2 +1,2 @@
> -SHA256
update productivity/timewarrior
Updates productivity/timewarrior from 1.1.1 to 1.5.0.
https://github.com/GothenburgBitFactory/timewarrior/releases/tag/v1.5.0
https://github.com/GothenburgBitFactory/timewarrior/compare/v1.1.1...v1.5.0
I looked to see if NO_TESTING could be removed, but didn't see an
obvious way to get tests to work.
It works alright so far. I'm not too familiar with timewarrior,
though I've used taskwarrior in the past.
Feedback/OK?
Index: Makefile
===
RCS file: /cvs/ports/productivity/timewarrior/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile11 Mar 2022 19:51:47 - 1.5
+++ Makefile2 Aug 2023 23:46:01 -
@@ -1,35 +1,48 @@
-COMMENT = command line tracking time tool
+COMMENT = command line tracking time tool
-VERSION = 1.1.1
-DISTNAME = timew-${VERSION}
-PKGNAME = timewarrior-${VERSION}
-CATEGORIES = productivity
-REVISION = 0
+VERSION = 1.5.0
+DISTNAME = timew-${VERSION}
+PKGNAME = timewarrior-${VERSION}
+CATEGORIES = productivity
-HOMEPAGE = https://timewarrior.net/
+HOMEPAGE = https://timewarrior.net/
# MIT
-PERMIT_PACKAGE = Yes
+PERMIT_PACKAGE = Yes
-WANTLIB += c m ${COMPILER_LIBCXX}
+WANTLIB += c m ${COMPILER_LIBCXX}
-MASTER_SITES = https://taskwarrior.org/download/
+MASTER_SITES =
https://github.com/GothenburgBitFactory/timewarrior/releases/download/v${VERSION}/
COMPILER = base-clang ports-gcc
MODULES = devel/cmake \
lang/python
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
MODPY_RUNDEP = No
MODPY_BUILDDEP = No
MODPY_ADJ_FILES = ext/totals.py
+BUILD_DEPENDS =textproc/asciidoctor
+
CONFIGURE_STYLE = cmake
+# Out-of-source build is broken on 1.5.0
+# https://github.com/GothenburgBitFactory/timewarrior/issues/461
+# https://github.com/GothenburgBitFactory/timewarrior/pull/538
+#
+# Try commenting/removing this on the next release to see if
+# out-of-source builds are fixed.
+SEPARATE_BUILD = No
+
CONFIGURE_ARGS += -DTIMEW_DOCDIR=share/doc/timewarrior
-CONFIGURE_ARGS += -DTIMEW_RCDIR=share/doc/timewarrior/rc
-CONFIGURE_ARGS += -DTIMEW_MAN1DIR=man/man1
+CONFIGURE_ARGS += -DTIMEW_MANDIR=man
NO_TEST = Yes
+
+# Hack to get rid of empty CMakeFiles directories on 1.5.0. Check to see
+# if this is still necessary next release.
+pre-install:
+ rmdir ${WRKBUILD}/doc/man1/CMakeFiles
+ rmdir ${WRKBUILD}/doc/man7/CMakeFiles
.include
Index: distinfo
===
RCS file: /cvs/ports/productivity/timewarrior/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo17 May 2018 23:22:21 - 1.1.1.1
+++ distinfo2 Aug 2023 23:46:01 -
@@ -1,2 +1,2 @@
-SHA256 (timew-1.1.1.tar.gz) = H32aYuVfxaMSZDNlTMsf19LRNfBvBWl/hxiXydt3zMk=
-SIZE (timew-1.1.1.tar.gz) = 166484
+SHA256 (timew-1.5.0.tar.gz) = UefCx3KDe71tVtqNFlBsS23oZEFm4LUjStNq5qcN1PY=
+SIZE (timew-1.5.0.tar.gz) = 4148590
Index: pkg/PLIST
===
RCS file: /cvs/ports/productivity/timewarrior/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 11 Mar 2022 19:51:47 - 1.2
+++ pkg/PLIST 2 Aug 2023 23:46:01 -
@@ -1,12 +1,49 @@
@bin bin/timew
+@man man/man1/timew-annotate.1
+@man man/man1/timew-cancel.1
+@man man/man1/timew-chart.1
+@man man/man1/timew-config.1
+@man man/man1/timew-continue.1
+@man man/man1/timew-day.1
+@man man/man1/timew-delete.1
+@man man/man1/timew-diagnostics.1
+@man man/man1/timew-export.1
+@man man/man1/timew-extensions.1
+@man man/man1/timew-fill.1
+@man man/man1/timew-gaps.1
+@man man/man1/timew-get.1
+@man man/man1/timew-help.1
+@man man/man1/timew-join.1
+@man man/man1/timew-lengthen.1
+@man man/man1/timew-modify.1
+@man man/man1/timew-month.1
+@man man/man1/timew-move.1
+@man man/man1/timew-report.1
+@man man/man1/timew-resize.1
+@man man/man1/timew-shorten.1
+@man man/man1/timew-show.1
+@man man/man1/timew-split.1
+@man man/man1/timew-start.1
+@man man/man1/timew-stop.1
+@man man/man1/timew-summary.1
+@man man/man1/timew-tag.1
+@man man/man1/timew-tags.1
+@man man/man1/timew-track.1
+@man man/man1/timew-undo.1
+@man man/man1/timew-untag.1
+@man man/man1/timew-week.1
@man man/man1/timew.1
+@man man/man7/timew-config.7
+@man man/man7/timew-dates.7
+@man man/man7/timew-dom.7
+@man man/man7/timew-durations.7
+@man man/man7/timew-hints.7
+@man man/man7/timew-ranges.7
share/doc/timewarrior/
share/doc/timewarrior/AUTHORS
-share/doc/timewarrior/COPYING
share/doc/timewarrior/ChangeLog
share/doc/timewarrior/INSTALL
share/doc/timewarrior/LICENSE
-share/doc/timewarrior/NEWS
share/doc/timewarrior/README.md
share/doc/timewarrior/doc/
new and needs testing/feedback: x11/xst
(CC'ing two people that expressed interest in a previous thread, I hope
that's alright)
```
$ cat /usr/ports/mystuff/x11/xst/pkg/DESCR
xst is a fork of st, which is a simple virtual terminal emulator for X
that sucks less.
Some things specific to xst include:
- Loads settings from Xresources.
- Live-reloads settings from xrdb on USR1 signal (like termite).
- Has cursor blinking options (and can persistently blink while typing).
- A keybind alt+u for launching urls with dmenu + xurls.
```
Homepage: https://github.com/gnotclub/xst
Porting notes:
--
I noticed some warnings in the build that don't exist in x11/st, both
related to `${WRKSRC}/xst.c`. The sprintf warning seemed easy enough to
fix, but please double check that patch because C isn't a language I
write anything in right now.
Anyway, there's a different build warning I don't know how to fix, but
still see as a potential issue because I can trigger a SIGSEGV with it:
```
In file included from x.c:243:
./xst.c:76:34: warning: expression which evaluates to zero treated as a null
pointer constant of type 'char *' [-Wnon-literal-null-conversion]
font2[endchar + count + 1] = '\0';
```
One way to trigger the SIGSEGV is by setting `st.font_fallback` in
.Xresources to a single comma because of the way the relevant code is
structured:
config.def.h line 9:
```
static char *font2[] = {
/* "Inconsolata for Powerline:pixelsize=12:antialias=true:autohint=true",
*/
/* "Hack Nerd Font Mono:pixelsize=11:antialias=true:autohint=true", */
};
```
xst.c line 65:
```
XRESOURCE_LOAD_META("font_fallback") {
int count = 0, endchar = fonts_count = sizeof(font2) /
sizeof(*font2);
for (int i = 0; ret.addr[i]; i++) if (ret.addr[i] ==
',') count++;
if (count > 0)
{
for (int i = 0; i <= count; i++)
{
if (i == 0) font2[endchar + i] =
strtok(ret.addr, ",");
else
font2[endchar + i] = strtok(NULL, ",");
fonts_count++;
}
font2[endchar + count + 1] = '\0';
} else if (ret.addr) {
font2[endchar] = ret.addr;
fonts_count++;
}
}
```
Triggering the segmentation fault:
```
$ grep st.font_fallback ~/.Xresources
st.font_fallback: ,
$ xst
Segmentation fault (core dumped)
$ egdb xst xst.core
Reading symbols from xst...
[New process 195719]
Core was generated by `xst'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0ec5e2d55653 in xloadsparefonts () at x.c:1173
1173if (**fp == '-')
(gdb) bt
#0 0x0ec5e2d55653 in xloadsparefonts () at x.c:1173
#1 0x0ec5e2d5480d in xinit (cols=80, rows=24) at x.c:1333
#2 0x0ec5e2d542d4 in main (argc=, argv=) at
x.c:2759
(gdb) quit
```
As I said, I'm not sure how to fix that problem, but the way it creates
undefined behavior like that seems bad. If anyone has any advice, I'd
really appreciate it.
Also, xst seems to use xurls, which isn't in the ports tree yet. I'm
thinking xurls would need to get ported and then the Makefile of x11/xst
would need to be revised to include xurls + x11/dmenu as RUN_DEPENDS?
Here's a link to xurls:
https://github.com/mvdan/xurls
Any and all feedback and suggestions are welcome. I view this as needing
more testing, and if there's a way to upstream a fix or two, I see that
as a positive thing. I'm not in contact with upstream yet because I
wanted to see what you all thought first.
Thanks.
xst-0.9.0.tgz
Description: application/tar-gz
Re: x11/st xresources flavor?
On Tue, 18 Jul 2023 20:42 +0100, Stuart Henderson wrote:
> On 2023/07/18 10:52, Ashlen wrote:
> > On Tue, 18 Jul 2023 14:23 +0200, Joerg Jung wrote:
> > >
> > >
> > > > On 18. Jul 2023, at 10:31, Sebastien Marie wrote:
> > > >
> > > > On Mon, Jul 17, 2023 at 11:25:37PM -0600, Ashlen wrote:
> > > >> Hello,
> > > >> I am reaching out to discuss the possibility of adding an xresources
> > > >> flavor to x11/st. In my opinion, this addition would greatly enhance
> > > >> the
> > > >> functionality of the program by allowing it to read colors and a font
> > > >> from the .Xresources file.
> > > >>
> > > >> Personally, I find it beneficial to set Solarized colors in my
> > > >> .Xresources file as it helps reduce eye strain. By incorporating this
> > > >> flavor, it would simplify the process of setting up my development
> > > >> environment after a fresh OpenBSD installation.
> > > >>
> > > >> I've attached a diff for your review. I'd greatly appreciate it if you
> > > >> could take a look and let me know if it meets the necessary
> > > >> requirements.
> > > >
> > > > My personal point of vue would be to have only one alternate flavour:
> > > >
> > > > - no flavor : plain st
> > > > - "enhanced" flavor : st + scrollback + xresources
> > >
> > > Yes, I agree with that.
> > >
> > >
> > > > I think that xresources is interesting as it permits to somehow
> > > > configure st
> > > > without having to recompile it (which defeat the fact to have it in
> > > > ports tree).
> > > >
> > > > What are others opinions ?
> > >
> > > Personally, I don’t really like the xresources patch, but if wanted by
> > > others
> > > I would be fine with adding it.
> >
> > Can I ask why you dislike it, Joerg? Maybe it could be a valuable
> > learning experience for me. If it's a technical issue that can be
> > resolved, I'm guessing upstream would greatly appreciate a solution, and
> > I can help coordinate that.
> >
> >
> > Also, I noticed that you are the maintainer of x11/dmenu. If you don't
> > mind, I'd like to work on a flavor of dmenu that includes an xresources
> > patch. This would allow me to easily switch between Solarized light and
> > Solarized dark and have those changes apply to both st and dmenu.
> >
> >
> > In any case, I've attached another patch for review that incorporates
> > everyone's feedback. Please let me know if there's anything else I can
> > do to improve my diff. :)
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/x11/st/Makefile,v
> > retrieving revision 1.26
> > diff -u -p -r1.26 Makefile
> > --- Makefile12 Jan 2023 21:00:13 - 1.26
> > +++ Makefile18 Jul 2023 16:05:32 -
> > @@ -2,7 +2,10 @@ COMMENT= simple X terminal
> >
> > V= 0.9
> > DISTNAME= st-${V}
> > -SUPDISTFILES= st-scrollback-0.8.5.diff:0
> > +
> > +SUPDISTFILES= st-scrollback-0.8.5.diff:0 \
> > + st-xresources-20230320-45a15676.diff:1
> > +
> > REVISION= 0
> >
> > CATEGORIES=x11
> > @@ -19,6 +22,7 @@ WANTLIB= X11 Xft c fontconfig freetype
> >
> > MASTER_SITES= https://dl.suckless.org/st/
> > MASTER_SITES0= https://st.suckless.org/patches/scrollback/
> > +MASTER_SITES1= https://st.suckless.org/patches/xresources/
> >
> > MAKE_ENV= LDFLAGS="${LDFLAGS}" \
> > X11INC=${X11BASE}/include \
> > @@ -26,10 +30,10 @@ MAKE_ENV= LDFLAGS="${LDFLAGS}" \
> >
> > NO_TEST= Yes
> >
> > -FLAVORS= scrollback
> > +FLAVORS= enhanced
> > FLAVOR?=
> >
> > -.if ${FLAVOR:Mscrollback}
> > +.if ${FLAVOR:Menhanced}
> > PATCHFILES=${SUPDISTFILES}
> > .endif
> > PATCH_DIST_STRIP= -p1
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/x11/st/distinfo,v
> > retrieving revision 1.17
> > diff -u -p -r1.17 distinfo
> > --- distinfo12 Jan
Re: x11/st xresources flavor?
On Tue, 18 Jul 2023 14:23 +0200, Joerg Jung wrote:
>
>
> > On 18. Jul 2023, at 10:31, Sebastien Marie wrote:
> >
> > On Mon, Jul 17, 2023 at 11:25:37PM -0600, Ashlen wrote:
> >> Hello,
> >> I am reaching out to discuss the possibility of adding an xresources
> >> flavor to x11/st. In my opinion, this addition would greatly enhance the
> >> functionality of the program by allowing it to read colors and a font
> >> from the .Xresources file.
> >>
> >> Personally, I find it beneficial to set Solarized colors in my
> >> .Xresources file as it helps reduce eye strain. By incorporating this
> >> flavor, it would simplify the process of setting up my development
> >> environment after a fresh OpenBSD installation.
> >>
> >> I've attached a diff for your review. I'd greatly appreciate it if you
> >> could take a look and let me know if it meets the necessary
> >> requirements.
> >
> > My personal point of vue would be to have only one alternate flavour:
> >
> > - no flavor : plain st
> > - "enhanced" flavor : st + scrollback + xresources
>
> Yes, I agree with that.
>
>
> > I think that xresources is interesting as it permits to somehow configure
> > st
> > without having to recompile it (which defeat the fact to have it in ports
> > tree).
> >
> > What are others opinions ?
>
> Personally, I don’t really like the xresources patch, but if wanted by others
> I would be fine with adding it.
Can I ask why you dislike it, Joerg? Maybe it could be a valuable
learning experience for me. If it's a technical issue that can be
resolved, I'm guessing upstream would greatly appreciate a solution, and
I can help coordinate that.
Also, I noticed that you are the maintainer of x11/dmenu. If you don't
mind, I'd like to work on a flavor of dmenu that includes an xresources
patch. This would allow me to easily switch between Solarized light and
Solarized dark and have those changes apply to both st and dmenu.
In any case, I've attached another patch for review that incorporates
everyone's feedback. Please let me know if there's anything else I can
do to improve my diff. :)
Index: Makefile
===
RCS file: /cvs/ports/x11/st/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile12 Jan 2023 21:00:13 - 1.26
+++ Makefile18 Jul 2023 16:05:32 -
@@ -2,7 +2,10 @@ COMMENT= simple X terminal
V= 0.9
DISTNAME= st-${V}
-SUPDISTFILES= st-scrollback-0.8.5.diff:0
+
+SUPDISTFILES= st-scrollback-0.8.5.diff:0 \
+ st-xresources-20230320-45a15676.diff:1
+
REVISION= 0
CATEGORIES=x11
@@ -19,6 +22,7 @@ WANTLIB= X11 Xft c fontconfig freetype
MASTER_SITES= https://dl.suckless.org/st/
MASTER_SITES0= https://st.suckless.org/patches/scrollback/
+MASTER_SITES1= https://st.suckless.org/patches/xresources/
MAKE_ENV= LDFLAGS="${LDFLAGS}" \
X11INC=${X11BASE}/include \
@@ -26,10 +30,10 @@ MAKE_ENV= LDFLAGS="${LDFLAGS}" \
NO_TEST= Yes
-FLAVORS= scrollback
+FLAVORS= enhanced
FLAVOR?=
-.if ${FLAVOR:Mscrollback}
+.if ${FLAVOR:Menhanced}
PATCHFILES=${SUPDISTFILES}
.endif
PATCH_DIST_STRIP= -p1
Index: distinfo
===
RCS file: /cvs/ports/x11/st/distinfo,v
retrieving revision 1.17
diff -u -p -r1.17 distinfo
--- distinfo12 Jan 2023 21:00:13 - 1.17
+++ distinfo18 Jul 2023 16:05:32 -
@@ -1,4 +1,6 @@
SHA256 (st-0.9.tar.gz) = 82NZeZc06ueFvss3QGPwvoM88i+ItPFpzSUbmTJOCOc=
SHA256 (st-scrollback-0.8.5.diff) =
3H9SI7JvyBPZHUrjW9qlTWMCTK6fGK/Zs1lLozmd+lU=
+SHA256 (st-xresources-20230320-45a15676.diff) =
/ETVhdSM8d+wD7MMTixM+RmLd/VakfaO974mpcdXBKg=
SIZE (st-0.9.tar.gz) = 48171
SIZE (st-scrollback-0.8.5.diff) = 8914
+SIZE (st-xresources-20230320-45a15676.diff) = 4853
Index: pkg/DESCR
===
RCS file: /cvs/ports/x11/st/pkg/DESCR,v
retrieving revision 1.2
diff -u -p -r1.2 DESCR
--- pkg/DESCR 12 Jan 2023 21:00:14 - 1.2
+++ pkg/DESCR 18 Jul 2023 16:05:32 -
@@ -1,5 +1,10 @@
st is a simple virtual terminal emulator for X which sucks less.
Flavour:
+ enhanced - built with the patches listed below.
+
+Patches:
scrollback - allows scrolling through terminal output with
- shift+pgup/pgdn
+ shift+pgup/pgdn.
+
+ xresources - configure st through Xresources.
x11/st xresources flavor?
Hello,
I am reaching out to discuss the possibility of adding an xresources
flavor to x11/st. In my opinion, this addition would greatly enhance the
functionality of the program by allowing it to read colors and a font
from the .Xresources file.
Personally, I find it beneficial to set Solarized colors in my
.Xresources file as it helps reduce eye strain. By incorporating this
flavor, it would simplify the process of setting up my development
environment after a fresh OpenBSD installation.
I've attached a diff for your review. I'd greatly appreciate it if you
could take a look and let me know if it meets the necessary
requirements.
Index: Makefile
===
RCS file: /cvs/ports/x11/st/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile12 Jan 2023 21:00:13 - 1.26
+++ Makefile18 Jul 2023 05:17:24 -
@@ -2,7 +2,12 @@ COMMENT= simple X terminal
V= 0.9
DISTNAME= st-${V}
-SUPDISTFILES= st-scrollback-0.8.5.diff:0
+
+PATCH_SCROLLBACK= st-scrollback-0.8.5.diff:0
+PATCH_XRESOURCES= st-xresources-20230320-45a15676.diff:1
+SUPDISTFILES= ${PATCH_SCROLLBACK} \
+ ${PATCH_XRESOURCES}
+
REVISION= 0
CATEGORIES=x11
@@ -19,6 +24,7 @@ WANTLIB= X11 Xft c fontconfig freetype
MASTER_SITES= https://dl.suckless.org/st/
MASTER_SITES0= https://st.suckless.org/patches/scrollback/
+MASTER_SITES1= https://st.suckless.org/patches/xresources/
MAKE_ENV= LDFLAGS="${LDFLAGS}" \
X11INC=${X11BASE}/include \
@@ -26,12 +32,17 @@ MAKE_ENV= LDFLAGS="${LDFLAGS}" \
NO_TEST= Yes
-FLAVORS= scrollback
+FLAVORS= scrollback xresources
FLAVOR?=
.if ${FLAVOR:Mscrollback}
-PATCHFILES=${SUPDISTFILES}
+PATCHFILES+= ${PATCH_SCROLLBACK}
.endif
+
+.if ${FLAVOR:Mxresources}
+PATCHFILES+= ${PATCH_XRESOURCES}
+.endif
+
PATCH_DIST_STRIP= -p1
do-install:
Index: distinfo
===
RCS file: /cvs/ports/x11/st/distinfo,v
retrieving revision 1.17
diff -u -p -r1.17 distinfo
--- distinfo12 Jan 2023 21:00:13 - 1.17
+++ distinfo18 Jul 2023 05:17:24 -
@@ -1,4 +1,6 @@
SHA256 (st-0.9.tar.gz) = 82NZeZc06ueFvss3QGPwvoM88i+ItPFpzSUbmTJOCOc=
SHA256 (st-scrollback-0.8.5.diff) =
3H9SI7JvyBPZHUrjW9qlTWMCTK6fGK/Zs1lLozmd+lU=
+SHA256 (st-xresources-20230320-45a15676.diff) =
/ETVhdSM8d+wD7MMTixM+RmLd/VakfaO974mpcdXBKg=
SIZE (st-0.9.tar.gz) = 48171
SIZE (st-scrollback-0.8.5.diff) = 8914
+SIZE (st-xresources-20230320-45a15676.diff) = 4853
Index: pkg/DESCR
===
RCS file: /cvs/ports/x11/st/pkg/DESCR,v
retrieving revision 1.2
diff -u -p -r1.2 DESCR
--- pkg/DESCR 12 Jan 2023 21:00:14 - 1.2
+++ pkg/DESCR 18 Jul 2023 05:17:24 -
@@ -3,3 +3,4 @@ st is a simple virtual terminal emulator
Flavour:
scrollback - allows scrolling through terminal output with
shift+pgup/pgdn
+ xresources - configure st through Xresources
Re: Update: net/i2pd-2.48.0
On Sun, 25 Jun 2023 14:04 +, open...@systemfailure.net wrote:
> Hi,
>
> Here's an update to i2pd.
>
> Lightly tested on current, extensively on stable (amd64).
>
> These commands are OK:
> make test
> make port-lib-depend-check
> /usr/ports/infrastructure/bin/portcheck
>
> Regards,
>
> SystemFailure
Builds and tests OK for me on -current amd64 at least (I don't have a
-stable to test on). Haven't used 2.48.0 extensively yet, but
openbsd.i2p loads and works just fine.
Release notes:
https://github.com/PurpleI2P/i2pd/releases/tag/2.48.0
Would be happy to see 2.48.0 in the ports tree. I'd adjust one small
thing, which is to move the stray @static-lib in PLIST so that it's with
the rest of them. Here's an updated diff with that change included.
Index: Makefile
===
RCS file: /cvs/ports/net/i2pd/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile16 May 2023 07:23:36 - 1.18
+++ Makefile26 Jun 2023 17:00:08 -
@@ -2,7 +2,7 @@ COMMENT = client for the I2P anonymous n
GH_ACCOUNT = PurpleI2P
GH_PROJECT = i2pd
-GH_TAGNAME = 2.47.0
+GH_TAGNAME = 2.48.0
CATEGORIES = net
HOMEPAGE = https://i2pd.website
Index: distinfo
===
RCS file: /cvs/ports/net/i2pd/distinfo,v
retrieving revision 1.13
diff -u -p -r1.13 distinfo
--- distinfo16 May 2023 07:23:36 - 1.13
+++ distinfo26 Jun 2023 17:00:08 -
@@ -1,2 +1,2 @@
-SHA256 (i2pd-2.47.0.tar.gz) = yYi68jIVw31fVmt7IFmjwWjHjRV+rG3ASjCsJmxjNfA=
-SIZE (i2pd-2.47.0.tar.gz) = 650284
+SHA256 (i2pd-2.48.0.tar.gz) = zPQXqmbON/cuoVt/vP9McegjVm6nS9ppa5weGarghzk=
+SIZE (i2pd-2.48.0.tar.gz) = 654495
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/i2pd/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST
--- pkg/PLIST 16 May 2023 07:23:37 - 1.11
+++ pkg/PLIST 26 Jun 2023 17:00:08 -
@@ -68,6 +68,7 @@ include/i2pd/util.h
include/i2pd/version.h
@static-lib lib/libi2pd.a
@static-lib lib/libi2pdclient.a
+@static-lib lib/libi2pdlang.a
@owner _i2pd
@group _i2pd
@sample ${SYSCONFDIR}/i2pd/
@@ -78,7 +79,6 @@ include/i2pd/version.h
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/router/
@owner
@group
-@static-lib lib/libi2pdlang.a
share/doc/pkg-readmes/${PKGSTEM}
share/examples/i2pd/
share/examples/i2pd/certificates/
Re: keepassxc in Jun 20 snap is sad
Same for me, I can't reproduce the issue either (I just upgraded). Edward, what are the contents of /etc/installurl for you? If you're using a CDN or a mirror with issues, that's probably your problem right there. My advice is the following, in this order: 1) `pkg_add -u` if you haven't already. You should be doing this at least every time you upgrade to a new snapshot. Personally, I do it every single time I log in. 2) Switch mirrors by editing /etc/installurl and repeat step one. 3) `pkg_add -u -D installed` on the new mirror 4) `pkg_info -mz > file`, `pkg_delete -X`, `pkg_add -l file`. Do this one outside of an X session, perhaps even in single user mode so you know for sure that you're not removing a package as a daemon is running or anything along those lines. It looks like you had a thread in the past about a similar enough issue that I'm guessing the root cause is probably also similar. https://marc.info/?l=openbsd-ports=167694546914669=2 $ sysctl -n kern.version OpenBSD 7.3-current (GENERIC.MP) #1258: Thu Jun 22 23:53:27 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ pkg_info -S keepassxc Information for inst:keepassxc-2.7.5 Signature: keepassxc-2.7.5,10,@argon2-20190702,@botan2-2.19.3,@desktop-file-utils-0.26,@gtk4-update-icon-cache-4.10.4,@libqrencode-4.1.1,@minizip-4.0.0,@qtbase-5.15.10,@qtsvg-5.15.10,@qtx11extras-5.15.10,@shared-mime-info-2.2,Qt5Concurrent.4.0,Qt5Core.4.0,Qt5DBus.3.0,Qt5Gui.3.0,Qt5Network.4.0,Qt5Svg.3.0,Qt5Widgets.4.0,Qt5X11Extras.3.0,X11.18.0,Xtst.11.0,argon2.0.0,botan-2.17.0,c++.9.0,c++abi.6.0,c.97.0,m.10.1,minizip.2.0,pthread.27.0,qrencode.2.1,readline.4.0,z.7.0 On Thu, 22 Jun 2023 14:48 +0200, Solene Rapenne wrote: > Le Thu, 22 Jun 2023 05:53:55 -0500, > Edward Ahlsen-Girard a écrit : > > > On Wed, 21 Jun 2023 10:32:52 -0600 > > Ashlen wrote: > > > > > 1) Port-related mails should go to ports@, so I'm CC'ing ports@ and > > > dropping misc@. If it becomes clear it's an issue with the port > > > itself (but I don't think it is), we can CC the maintainer later. > > > > > > 2) Can you please open that core file with gdb and provide the > > > backtrace? Should be as simple as: > > > > > > # pkg_add gdb > > > $ egdb -q keepassxc keepassxc.core > > > (gdb) bt > > > > > > Right now I'm on the snapshot from June 14th with keepassxc 2.7.5 > > > and mine works. If it's an issue related to snapshots, we can at > > > least narrow it down to between those two. > > > > > > On Wed, 21 Jun 2023 06:46 -0500, Edward Ahlsen-Girard wrote: > > > [...] > > > > Installed 21 June snapshot; results below. > > > > works fine for me, are you using a flavor of keepassxc? > > $ sysctl kern.version > kern.version=OpenBSD 7.3-current (GENERIC.MP) #1255: Wed Jun 21 > 20:41:16 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > $ pkg_info -S keepassxc > Information for inst:keepassxc-2.7.5 > > Signature: > keepassxc-2.7.5,10,@argon2-20190702,@botan2-2.19.3,@desktop-file-utils-0.26,@gtk4-update-icon-cache-4.10.4,@libqrencode-4.1.1,@minizip-4.0.0,@qtbase-5.15.10,@qtsvg-5.15.10,@qtx11extras-5.15.10,@shared-mime-info-2.2,Qt5Concurrent.4.0,Qt5Core.4.0,Qt5DBus.3.0,Qt5Gui.3.0,Qt5Network.4.0,Qt5Svg.3.0,Qt5Widgets.4.0,Qt5X11Extras.3.0,X11.18.0,Xtst.11.0,argon2.0.0,botan-2.17.0,c++.9.0,c++abi.6.0,c.97.0,m.10.1,minizip.2.0,pthread.27.0,qrencode.2.1,readline.4.0,z.7.0
Re: keepassxc in Jun 20 snap is sad
1) Port-related mails should go to ports@, so I'm CC'ing ports@ and dropping misc@. If it becomes clear it's an issue with the port itself (but I don't think it is), we can CC the maintainer later. 2) Can you please open that core file with gdb and provide the backtrace? Should be as simple as: # pkg_add gdb $ egdb -q keepassxc keepassxc.core (gdb) bt Right now I'm on the snapshot from June 14th with keepassxc 2.7.5 and mine works. If it's an issue related to snapshots, we can at least narrow it down to between those two. On Wed, 21 Jun 2023 06:46 -0500, Edward Ahlsen-Girard wrote: > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even > though it was found. This application failed to start because no Qt > platform plugin could be initialized. Reinstalling the application may > fix this problem. > > Available platform plugins are: eglfs, minimal, minimalegl, offscreen, > vnc, wayland-egl, wayland, wayland-xcomposite-egl, > wayland-xcomposite-glx, xcb. > > Abort trap (core dumped) > > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > > OpenBSD 7.3-current (GENERIC.MP) #1253: Tue Jun 20 13:52:16 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4174688256 (3981MB) > avail mem = 4028489728 (3841MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec530 (36 entries) > bios0: vendor AMI version "80.06" date 04/01/2015 > bios0: Hewlett-Packard 550-036 > efi0 at bios0: UEFI 2.3.1 > efi0: American Megatrends rev 0x4028e > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MSDM SSDT SSDT MCFG HPET SSDT SSDT DBGP > acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) > PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) > EHC2(S3) XHC_(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.58 MHz, 06-3c-03 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.59 MHz, 06-3c-03 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 1 (application processor) > cpu2: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.76 MHz, 06-3c-03 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache > cpu2: smt 1, core 0, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.78 MHz, 06-3c-03 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache,
[new]: devel/p5-Software-License (need it for RUN_DEPENDS)
Hi, I'm looking to update devel/p5-Module-Starter from 1.54 to 1.77. In order to do this, I need devel/p5-Software-License imported into the ports tree so I can add it as a RUN_DEPENDS. Without it, the new version of `module-starter` fails during runtime. I couldn't find a decent description upstream, so this is what I wrote for pkg/DESCR (I'm open to changing it): "Software::License provides templated software licenses. It also includes Software::LicenseUtils, which contains useful bits of code for guessing licenses and creating Software::License objects." I don't think I want MAINTAINER. OK? p5-Software-License-0.104004.tgz Description: application/tar-gz
[update] devel/shfmt v3.5.1 => v3.6.0
Release notes:
https://github.com/mvdan/sh/releases/tag/v3.6.0
Note that `make test` fails in the last version as well as this one
(error output is attached). I'm unsure how to fix it, though, as I don't
write in Go and I didn't find anything obvious in go-module(5) that I
could adjust.
Any ideas, or feedback in general?
[/usr/ports/mystuff/devel/shfmt]$ make test
===> Regression tests for shfmt-3.6.0
cd /usr/obj/ports/shfmt-3.6.0/mvdan.cc/sh/v3@v3.6.0 && /usr/bin/env -i
GO386=softfloat GOCACHE="/usr/obj/ports/shfmt-3.6.0/go-cache"
TMPDIR="/usr/obj/ports/shfmt-3.6.0/build-amd64"
GOPROXY=file:///usr/obj/ports/shfmt-3.6.0/go_modules GO111MODULE=on
GOPATH="/usr/obj/ports/shfmt-3.6.0/go:/usr/local/go-pkg" PORTSDIR="/usr/ports"
LIBTOOL="/usr/bin/libtool"
PATH='/usr/obj/ports/shfmt-3.6.0/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin'
PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' CFLAGS='-O2
-pipe' TRUEPREFIX='/usr/local' DESTDIR='' HOME='/shfmt-3.6.0_writes_to_HOME'
PICFLAG="-fpic" BINGRP=bin BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755
INSTALL_COPY=-c INSTALL_STRIP= MANGRP=bin MANOWN=root MANMODE=644
BSD_INSTALL_PROGRAM="/usr/obj/ports/shfmt-3.6.0/bin/install -c -m 755"
BSD_INSTALL_SCRIPT="/usr/obj/ports/shfmt-3.6.0/bin/install -c -m 755"
BSD_INSTALL_DATA="/usr/obj/ports/shfmt-3.6.0/bin/install -c -m 644"
BSD_INSTALL_MAN="/usr/obj/ports/shfmt-3.6.0/bin/install -c -m 644"
BSD_INSTALL_PROGRAM_DIR="/usr/obj/ports/shfmt-3.6.0/bin/install -d -m 755"
BSD_INSTALL_SCRIPT_DIR="/usr/obj/ports/shfmt-3.6.0/bin/install -d -m 755"
BSD_INSTALL_DATA_DIR="/usr/obj/ports/shfmt-3.6.0/bin/install -d -m 755"
BSD_INSTALL_MAN_DIR="/usr/obj/ports/shfmt-3.6.0/bin/install -d -m 755" go test
mvdan.cc/sh/v3
no required module provides package mvdan.cc/sh/v3; to add it:
go get mvdan.cc/sh/v3
*** Error 1 in . (/usr/ports/lang/go/go.port.mk:185 'do-test')
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2997
'/usr/obj/ports/shfmt-3.6.0/build-amd64/.test_done': @cd /usr/ports/mystuff/...)
*** Error 2 in /usr/ports/mystuff/devel/shfmt
(/usr/ports/infrastructure/mk/bsd.port.mk:2608 'test': @lock=shfmt-3.6.0;
export _LOCKS_HELD=...)
[/usr/obj/ports/shfmt-3.6.0/mvdan.cc/sh/v3@v3.6.0]$ go get mvdan.cc/sh/v3
go: downloading mvdan.cc/sh v2.6.4+incompatible
go: module mvdan.cc/sh@upgrade found (v2.6.4+incompatible), but does not
contain package mvdan.cc/sh/v3
Index: Makefile
===
RCS file: /cvs/ports/devel/shfmt/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- Makefile5 Oct 2022 14:54:23 - 1.8
+++ Makefile15 Jun 2023 20:58:06 -
@@ -1,8 +1,7 @@
COMMENT = shell parser, formatter, and interpreter
MODGO_MODNAME =mvdan.cc/sh/v3
-MODGO_VERSION =v3.5.1
-REVISION = 0
+MODGO_VERSION =v3.6.0
DISTNAME = shfmt-${MODGO_VERSION}
Index: distinfo
===
RCS file: /cvs/ports/devel/shfmt/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- distinfo10 Jun 2022 16:38:21 - 1.4
+++ distinfo15 Jun 2023 20:58:06 -
@@ -1,78 +1,52 @@
-SHA256 (go_modules/github.com/creack/pty/@v/v1.1.17.mod) =
BBOkGR3M1sdbDMdMtxrxVkBw8uy/zjq0ujzMnXAf2Cw=
-SHA256 (go_modules/github.com/creack/pty/@v/v1.1.17.zip) =
xrCCCzXCX314L4bABUUEWyiZK23olJMGNBkf7sVvxIQ=
+SHA256 (go_modules/github.com/creack/pty/@v/v1.1.18.mod) =
BBOkGR3M1sdbDMdMtxrxVkBw8uy/zjq0ujzMnXAf2Cw=
+SHA256 (go_modules/github.com/creack/pty/@v/v1.1.18.zip) =
fcrad4LgTw1LR9UNTvNfNvLID5CSMQGRSUgEKb2xduU=
SHA256 (go_modules/github.com/creack/pty/@v/v1.1.9.mod) =
6rBwW8ShjdMVwnpOPbqPIKnhIwZfogYzlmMytczPdzE=
-SHA256 (go_modules/github.com/frankban/quicktest/@v/v1.14.0.mod) =
NesGxsU7XJIASF2NNyQwKaLpCs06MxzuY1A/XmE6p3Y=
-SHA256 (go_modules/github.com/frankban/quicktest/@v/v1.14.0.zip) =
8wa0o/yVd00aB96B5gTIGGPblyCc+KK7XiFrnPZst9E=
-SHA256 (go_modules/github.com/google/go-cmp/@v/v0.5.6.mod) =
QDarVjaqQr0xMpbNO/y0yIkSdgxWqeZlWuQi2HZ8gNo=
-SHA256 (go_modules/github.com/google/go-cmp/@v/v0.5.6.zip) =
Msa7U6LyFP7NQ8oKQ2dYSI0IiprCPjke9LUC7aBZEUc=
-SHA256 (go_modules/github.com/google/renameio/@v/v1.0.1.mod) =
jZ5etDAO1Se1ndRA01hQHcvklcQZOW7wsKYfAcfJhI0=
-SHA256 (go_modules/github.com/google/renameio/@v/v1.0.1.zip) =
hGpDertikoVGN3dB/fzQy1g+saL24PH9mDoC/ofSBMk=
-SHA256 (go_modules/github.com/kr/pretty/@v/v0.1.0.mod) =
49XUbS9qyUpmalS16GfsFr8ZnZ9LcAgnzXMWB+/dEJo=
-SHA256 (go_modules/github.com/kr/pretty/@v/v0.3.0.mod) =
Qud4TgS5ZSWGtfne3/b5UYN2t0V2Gp/RoMIXjrhtyXo=
-SHA256 (go_modules/github.com/kr/pretty/@v/v0.3.0.zip) =
OsZeGF+VbYidd0hRc/rcww6Vm2vP2qisr67F9NrFzUg=
-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
Re: UPDATE: pngquant 2.18.0
Built + installed on amd64 and it works great. Looks like updating to
3.x would require reworking the port (upstream switched their build
system from make to cargo). Thanks for looking at this, Brad. :)
I can't give an OK, but I'd be happy to see this updated version in the
ports tree. I use it to reduce bandwidth when serving images over HTTP.
On Sun, 11 Jun 2023 16:38 -0400, Brad Smith wrote:
> Here is an update to pngquant 2.18.0.
>
>
> version 2.17
>
> - fix for Unicode filenames on Windows
> - builds for ARM
> - small quality improvements
>
> version 2.16
>
> - reduced stack usage, prevenitng stack overlfow in pathological cases
>
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/graphics/pngquant/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile 8 May 2022 09:39:33 - 1.5
> +++ Makefile 9 Jun 2023 02:21:37 -
> @@ -2,8 +2,7 @@ COMMENT = PNG compressor
>
> GH_ACCOUNT = kornelski
> GH_PROJECT = pngquant
> -GH_TAGNAME = 2.15.1
> -REVISION = 0
> +GH_TAGNAME = 2.18.0
>
> CATEGORIES = graphics
>
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/graphics/pngquant/distinfo,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 distinfo
> --- distinfo 28 May 2021 16:22:03 - 1.2
> +++ distinfo 9 Jun 2023 02:21:41 -
> @@ -1,2 +1,2 @@
> -SHA256 (pngquant-2.15.1.tar.gz) =
> JIVrKKykfteGM/piXrdLhXgtYtrMS8pjT87fL26VxLc=
> -SIZE (pngquant-2.15.1.tar.gz) = 71163
> +SHA256 (pngquant-2.18.0.tar.gz) =
> Qk/0MuUd/Dz1/4ABrRtkGYhQaGxePCbs1Hfktp70+t4=
> +SIZE (pngquant-2.18.0.tar.gz) = 71187
> Index: patches/patch-configure
> ===
> RCS file: /home/cvs/ports/graphics/pngquant/patches/patch-configure,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 patch-configure
> --- patches/patch-configure 11 Mar 2022 19:23:12 - 1.2
> +++ patches/patch-configure 9 Jun 2023 00:17:59 -
> @@ -3,19 +3,16 @@ Remove optimizations
> Index: configure
> --- configure.orig
> +++ configure
> -@@ -291,15 +291,6 @@ status "Compiler" "$CC"
> - CFLAGS=${CFLAGS:--fno-math-errno -funroll-loops -fomit-frame-pointer -Wall}
> - cflags "-std=c99 -I."
> +@@ -293,10 +293,10 @@ cflags "-std=c99 -I."
>
> --# DEBUG
> --if [ -z "$DEBUG" ]; then
> + # DEBUG
> + if [ -z "$DEBUG" ]; then
> -cflags "-O3 -DNDEBUG"
> --status "Debug" "no"
> --else
> ++cflags "-DNDEBUG"
> + status "Debug" "no"
> + else
> -cflags "-O1 -g -DDEBUG"
> --status "Debug" "yes"
> --fi
> --
> - # SSE
> - if [ "$SSE" = 'auto' ]; then
> - SSE=0
> ++cflags "-g -DDEBUG"
> + status "Debug" "yes"
> + fi
> +
> Index: patches/patch-test_test_sh
> ===
> RCS file: patches/patch-test_test_sh
> diff -N patches/patch-test_test_sh
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-test_test_sh9 Jun 2023 02:20:57 -
> @@ -0,0 +1,9 @@
> +Index: test/test.sh
> +--- test/test.sh.orig
> test/test.sh
> +@@ -1,4 +1,4 @@
> +-#!/bin/bash
> ++#!/usr/bin/env bash
> + set -eu
> + set -o pipefail
> +
>
UPDATE: security/zaproxy 2.11.1 -> 2.12.0 (log4j update, and HTML injection fix)
Release notes:
https://www.zaproxy.org/blog/2022-10-27-zap-2-12-0-the-ten-thousand-star-release/
JVM 11+ is now a requirement. log4j was updated from 2.15.0[!] to
2.19.0. An HTML injection vulnerability is patched in this release.
Builds and runs OK for the most part. zaproxy.sh was a bit broken, so I
changed some things around. Brief summary:
- Tilde expansion doesn't happen inside quotes, so `[ -f ${JVMPROPS} ]`
would always fail. Fixed ${JVMPROPS} to use ${HOME} instead.
- The provided path for ${JVMPROPS} isn't the one used on OpenBSD[1] so I
fixed that as well.
- Quoted variables to avoid unexpected word splitting and globbing.
- Consistency and readability improvements.
- The last line now uses `-dir "${HOME}/OWASP ZAP"`.
I wasn't sure whether to try adding a do-build target with
BUILD_DEPENDS=java/gradle so NO_BUILD can get removed. I don't have much
experience with that stuff, but if upstream makes a change in the future
that warrants downstream patches, it seems like it'd be easier to fix if
that shift has already happened.
Thoughts/feedback? :)
[1]:
https://github.com/zaproxy/zaproxy/blob/v2.12.0/zap/src/main/java/org/parosproxy/paros/Constant.java#L408
Index: Makefile
===
RCS file: /cvs/ports/security/zaproxy/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile11 Mar 2022 19:54:10 - 1.13
+++ Makefile23 May 2023 18:32:54 -
@@ -1,6 +1,6 @@
COMMENT = web application security tool
-VERSION = 2.11.1
+VERSION = 2.12.0
DISTNAME = ZAP_${VERSION}_Linux
PKGNAME = zaproxy-${VERSION}
@@ -14,7 +14,7 @@ PERMIT_PACKAGE = Yes
MASTER_SITES =
https://github.com/zaproxy/zaproxy/releases/download/v${VERSION}/
MODULES = java
-MODJAVA_VER = 1.8+
+MODJAVA_VER = 11+
RUN_DEPENDS = java/javaPathHelper
Index: distinfo
===
RCS file: /cvs/ports/security/zaproxy/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo11 Dec 2021 10:09:54 - 1.6
+++ distinfo23 May 2023 18:32:54 -
@@ -1,2 +1,2 @@
-SHA256 (ZAP_2.11.1_Linux.tar.gz) = X4Nmblhj9PlOrFg5QvHE4V+cx7cwfQW8bOZUUmXGOCw=
-SIZE (ZAP_2.11.1_Linux.tar.gz) = 194801121
+SHA256 (ZAP_2.12.0_Linux.tar.gz) = nESTyZHLk0cGOGTSQ2o3lc87aXYGJeez20Ac00LT/FU=
+SIZE (ZAP_2.12.0_Linux.tar.gz) = 248228711
Index: files/zaproxy.sh
===
RCS file: /cvs/ports/security/zaproxy/files/zaproxy.sh,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 zaproxy.sh
--- files/zaproxy.sh7 Dec 2015 06:32:09 - 1.1.1.1
+++ files/zaproxy.sh23 May 2023 18:32:54 -
@@ -1,41 +1,36 @@
#!/bin/sh
-DIRBASEZAP=${TRUEPREFIX}/share/zaproxy/
-ZAP=${DIRBASEZAP}zap-${VERSION}.jar
+DIRBASEZAP="${TRUEPREFIX}/share/zaproxy/"
+ZAP="${DIRBASEZAP}zap-${VERSION}.jar"
-JAVA_CMD=$(javaPathHelper -c zaproxy)
+JAVA_CMD="$(javaPathHelper -c zaproxy)"
-JVMPROPS="~/.ZAP/.ZAP_JVM.properties"
-if [ -f $JVMPROPS ]; then
+JVMPROPS="${HOME}/OWASP ZAP/.ZAP_JVM.properties"
+if [ -f "${JVMPROPS}" ]; then
# Local jvm properties file present
- JMEM=$(head -1 $JVMPROPS)
+ JMEM="$(head -1 "${JVMPROPS}")"
else
- MEM=$(($(ulimit -m )/1024 ))
+ MEM="$(( $(ulimit -m) / 1024 ))"
fi
-if [ ! -z $JMEM ]; then
- echo "Using jvm memory setting from " ~/.ZAP_JVM.properties
-elif [ -z $MEM ]; then
- echo "Failed to obtain current memory, using jvm default memory settings"
-else
- echo "Available memory: " $MEM "MB"
- if [ $MEM -gt 1500 ]; then
+if [ -n "${JMEM}" ]; then
+ echo "Using jvm memory setting from ${JVMPROPS}"
+elif [ -n "${MEM}" ]; then
+ echo "Available memory: ${MEM} MB"
+ if [ "${MEM}" -gt 1500 ]; then
JMEM="-Xmx512m"
- else
-if [ $MEM -gt 900 ] ; then
- JMEM="-Xmx256m"
-else
- if [ $MEM -gt 512 ] ; then
-JMEM="-Xmx128m"
- fi
-fi
+ elif [ "${MEM}" -gt 900 ]; then
+JMEM="-Xmx256m"
+ elif [ "${MEM}" -gt 512 ]; then
+JMEM="-Xmx128m"
fi
+else
+ echo "Failed to obtain current memory, using jvm default memory settings"
fi
-if [ -n "$JMEM" ]
-then
- echo "Setting jvm heap size: $JMEM"
+if [ -n "${JMEM}" ]; then
+ echo "Setting jvm heap size: ${JMEM}"
fi
-cd ${DIRBASEZAP}
-exec ${JAVA_CMD} ${JMEM} -jar "${ZAP}" -dir ~/.ZAP/ -installdir ${DIRBASEZAP}
"$@"
+cd "${DIRBASEZAP}" || exit
+exec "${JAVA_CMD}" "${JMEM}" -jar "${ZAP}" -dir "${HOME}/OWASP ZAP/"
-installdir "${DIRBASEZAP}" "$@"
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/zaproxy/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST 11 Mar 2022 19:54:10 - 1.7
+++ pkg/PLIST 23 May 2023 18:32:54 -
@@ -53,6 +53,7 @@ share/zaproxy/lang/Messages_ur_PK.proper
Re: NEW: fonts/victor-mono
On Fri, 19 May 2023 01:11 -0600, Omar Polo wrote:
> On 2023/05/19 00:01:09 -0400, A Tammy wrote:
> >
> > On 5/18/23 12:26, Ashlen wrote:
> > > Hi all. :) This is a font I recently discovered and I decided to make a
> > > proper port for it.
> > >
> > > Homepage: https://rubjo.github.io/victor-mono/
> > > GitHub: https://github.com/rubjo/victor-mono
> > >
> > > Victor Mono is a monospaced font with a large x-height. It reminds me a
> > > little of Iosevka, except that I find Victor Mono more readable (I have
> > > astigmatism and it's easier on my eyes for whatever reason).
> > >
> > > Suggestions/feedback are always welcome. I added a comment above
> > > MASTER_SITES and DISTFILES because I had to jump through some hoops to
> > > get a versioned copy. I used the solution that packagers elsewhere use
> > > (FreeBSD, NixOS).
> >
> > Don't think we need the comment over the MASTER_SITES but don't really
> > care either way.
>
> hum. same for me. I'd probably drop it.
>
> > You could also add yourself as maintainer if you wish.
> >
> > If someone likes it and wants to import OK aisha.
>
> I'd tweak slightly the indentation, just so they line up, see diff
> below.
>
> looks fine in emacs, ok op@
Thanks for the feedback. :) I attached a patch that'll apply these
changes to the original Makefile:
- Added myself as maintainer.
- Dropped the comment.
- Added Omar's whitespace changes.
--- Makefile.orig Fri May 19 01:26:34 2023
+++ MakefileFri May 19 01:28:04 2023
@@ -1,19 +1,17 @@
COMMENT= slender monospaced font with a large x-height
HOMEPAGE= https://rubjo.github.io/victor-mono/
+MAINTAINER=Ashlen
TYPEFACE= victor-mono
-V= 1.5.5
+V= 1.5.5
-# Packagers on other operating systems obtain a versioned copy of
-# victor-mono using this URL. Unfortunately, upstream doesn't seem to
-# provide one anywhere else.
MASTER_SITES= https://github.com/rubjo/victor-mono/raw/v${V}/public/
DISTFILES= victor-mono-${V}{VictorMonoAll}${EXTRACT_SUFX}
# SIL OFL 1.1
PERMIT_PACKAGE=Yes
-MODULES= font
+MODULES= font
FONT_DISTSUBDIR= OTF
NO_BUILD= Yes
NEW: fonts/victor-mono
Hi all. :) This is a font I recently discovered and I decided to make a proper port for it. Homepage: https://rubjo.github.io/victor-mono/ GitHub: https://github.com/rubjo/victor-mono Victor Mono is a monospaced font with a large x-height. It reminds me a little of Iosevka, except that I find Victor Mono more readable (I have astigmatism and it's easier on my eyes for whatever reason). Suggestions/feedback are always welcome. I added a comment above MASTER_SITES and DISTFILES because I had to jump through some hoops to get a versioned copy. I used the solution that packagers elsewhere use (FreeBSD, NixOS). victor-mono-1.5.5.tgz Description: application/tar-gz
Re: UPDATE: net/i2pd 2.46.1 -> 2.47.0
On 2023-05-16 09:30, Theo Buehler wrote: > On Mon, May 15, 2023 at 04:47:31PM -0600, Ashlen wrote: > > I tested the update briefly and it works. Noticed some errors in `make > > test` about rand(), strcat(), and sprintf(), but I'm unsure what to do > > about those. Adding boost_atomic-mt to WANTLIB was necessary to pass > > port-lib-depends-check. > > > > Feedback? I hope I didn't miss anything obvious. > > Your patch didn't apply cleanly because of tabs vs spaces in this line: > > > -GH_TAGNAME = 2.46.1 > > +GH_TAGNAME = 2.47.0 > > Not sure how that happened. Avoid copy-pasting diffs. For example tmux > likes to convert tabs into spaces. Shoot, I always forget it does that. That's exactly the mistake I made, too. Sorry about that, it's a bad habit. Next time I'll be sure to avoid copy-pasting and to test the patch itself before sending. Thank you both for all the feedback. :) Am still pretty new to ports stuff, but I'll do my best to learn from all of the suggestions I get.
UPDATE: net/i2pd 2.46.1 -> 2.47.0
I tested the update briefly and it works. Noticed some errors in `make
test` about rand(), strcat(), and sprintf(), but I'm unsure what to do
about those. Adding boost_atomic-mt to WANTLIB was necessary to pass
port-lib-depends-check.
Feedback? I hope I didn't miss anything obvious.
---
Changelog entry from upstream:
## [2.47.0] - 2023-03-11
### Added
- Congestion caps
- SAM UDP port parameter
- Support domain addresses for yggdrasil reseeds
### Changed
- DHT for floodfills instead plain list
- Process router's messages in separate thread
- Don't publish non-reachable router
- Send and check target destination in first streaming SYN packet
- Reseeds list
### Fixed
- Memory leak in windows network state detection
- Reseed attempts from invalid address
Index: Makefile
===
RCS file: /cvs/ports/net/i2pd/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile26 Feb 2023 07:51:45 - 1.17
+++ Makefile15 May 2023 22:28:46 -
@@ -2,7 +2,7 @@ COMMENT = client for the I2P anonymous n
GH_ACCOUNT = PurpleI2P
GH_PROJECT = i2pd
-GH_TAGNAME = 2.46.1
+GH_TAGNAME = 2.47.0
CATEGORIES = net
HOMEPAGE = https://i2pd.website
@@ -12,7 +12,7 @@ PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} boost_date_time-mt boost_filesystem-mt
WANTLIB += boost_program_options-mt boost_system-mt c crypto m
-WANTLIB += ssl z
+WANTLIB += ssl z boost_atomic-mt
COMPILER = base-clang ports-gcc
MODULES = devel/cmake
Index: distinfo
===
RCS file: /cvs/ports/net/i2pd/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo26 Feb 2023 07:51:45 - 1.12
+++ distinfo15 May 2023 22:28:46 -
@@ -1,2 +1,2 @@
-SHA256 (i2pd-2.46.1.tar.gz) = g7teJJTVZtQf86heTJMHjSkNEOPPH754B77J8NAkUT4=
-SIZE (i2pd-2.46.1.tar.gz) = 644777
+SHA256 (i2pd-2.47.0.tar.gz) = yYi68jIVw31fVmt7IFmjwWjHjRV+rG3ASjCsJmxjNfA=
+SIZE (i2pd-2.47.0.tar.gz) = 650284
cvs server: Diffing patches
cvs server: Diffing pkg
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/i2pd/pkg/PLIST,v
retrieving revision 1.10
diff -u -p -r1.10 PLIST
--- pkg/PLIST 26 Feb 2023 07:51:45 - 1.10
+++ pkg/PLIST 15 May 2023 22:28:46 -
@@ -131,6 +131,7 @@ share/examples/i2pd/certificates/reseed/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/reseed/acetone_at_mail.i2p.crt
@owner
@group
+share/examples/i2pd/certificates/reseed/arnavbhatt288_at_mail.i2p.crt
share/examples/i2pd/certificates/reseed/creativecowpat_at_mail.i2p.crt
@owner _i2pd
@group _i2pd
Re: Odd failures related to devel/py-setuptools_git?
On 2023-05-15 09:17, Stuart Henderson wrote: > There must be something unusual with your local setup. Maybe in mk.conf, maybe > you don't have sudo or doas setup to pass the environment through, maybe > something in the checkout, not sure. > > There's no general problem with those ports, or we'd see it in bulk builds. > > -- > Sent from a phone, apologies for poor formatting. Thank you for taking the time to respond, Stuart. It turns out I had lines with `setenv` written in /etc/doas.conf that were preventing relevant environment variables from being passed through. Changing `setenv` to `keepenv` corrected the problem. You saved me the headache of continuing to look in the wrong place, and I really appreciate that. I knew I had to be missing something.
Odd failures related to devel/py-setuptools_git?
Hi, I have two questions:
1) Why does the python3 FLAVOR of devel/py-setuptools_git seem to
require extraction of the python2 version first to work?
2) Why does devel/py-setuptools_git look for python2 when a different
port is requesting the python3 version?
I encountered these issues while attempting to update net/i2pd and
productivity/vym. They end up pulling in devel/py-setuptools_git as a
dependency.
The relevant output that lead me to ask these two questions is contained
in two separate sections below.
Steps I took:
1) Changed directory.
2) `make clean=all` for both versions of devel/py-setuptools_git.
3) Attempted to build python3 flavor. It failed.
4) Attempted to build python2 version. It also failed.
5) Built python3 flavor successfully because the python2 version created
a missing directory needed in step 3.
$ cd /usr/ports/devel/py-setuptools_git
$ make clean=all
===> Cleaning for py-setuptools-git-1.2p6
doas -u _pbuild rm -f /usr/ports/packages/amd64/all/py-setuptools-git-1.2p6.tgz
/usr/ports/packages/amd64/ftp/py-setuptools-git-1.2p6.tgz
/usr/ports/pobj/py-setuptools-git-1.2/fake-amd64/debug-pkg/Makefile
doas -u _pfetch rm -f
/usr/ports/packages/amd64/cache/py-setuptools-git-1.2p6.tgz
doas -u _pbuild rm -f /usr/ports/update/amd64/py-setuptools-git-1.2p6
doas -u _pbuild rm -f /usr/ports/plist/amd64/{debug-,}py-setuptools-git-1.2p6
$ env FLAVOR=python3 make clean=all
===> Cleaning for py3-setuptools-git-1.2p6
doas -u _pbuild rm -f
/usr/ports/packages/amd64/all/py3-setuptools-git-1.2p6.tgz
/usr/ports/packages/amd64/ftp/py3-setuptools-git-1.2p6.tgz
/usr/ports/pobj/py-setuptools-git-1.2-python3/fake-amd64-python3/debug-pkg/Makefile
doas -u _pfetch rm -f
/usr/ports/packages/amd64/cache/py3-setuptools-git-1.2p6.tgz
doas -u _pbuild rm -f /usr/ports/update/amd64/py3-setuptools-git-1.2p6
doas -u _pbuild rm -f /usr/ports/plist/amd64/{debug-,}py3-setuptools-git-1.2p6
$ env FLAVOR=python3 make extract
===> Checking files for py3-setuptools-git-1.2p6
`/usr/ports/distfiles/setuptools-git-1.2.tar.gz' is up to date.
>> (SHA256) setuptools-git-1.2.tar.gz: OK
===> py3-setuptools-git-1.2p6 depends on: python->=3.10,<3.11 ->
python-3.10.11p0
===> py3-setuptools-git-1.2p6 depends on: py3-setuptools-* ->
py3-setuptools-67.6.1v0
===> Extracting for py3-setuptools-git-1.2p6
/bin/sh: cd: /usr/ports/pobj/py-setuptools-git-1.2 - No such file or directory
*** Error 1 in /usr/ports/devel/py-setuptools_git
(/usr/ports/infrastructure/mk/bsd.port.mk:2726 'do-extract':
@PATH=/usr/ports/pobj/py-setu...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2699
'/usr/ports/pobj/py-setuptools-git-1.2-python3/.extract_done': @cd /usr/port...)
*** Error 2 in /usr/ports/devel/py-setuptools_git
(/usr/ports/infrastructure/mk/bsd.port.mk:2600 'extract':
@lock=py3-setuptools-git-1.2p6; ...)
$ make extract
===> Checking files for py-setuptools-git-1.2p6
`/usr/ports/distfiles/setuptools-git-1.2.tar.gz' is up to date.
>> (SHA256) setuptools-git-1.2.tar.gz: OK
===> py-setuptools-git-1.2p6 depends on: python->=2.7,<2.8 - not found
===> Verifying install for python->=2.7,<2.8 in lang/python/2.7
===> Checking files for Python-2.7.18
`/usr/ports/distfiles/Python-2.7.18.tgz' is up to date.
>> (SHA256) Python-2.7.18.tgz: OK
===> python-2.7.18p11 depends on: db->=4,<5|db->=4v0,<5v0 - not found
===> Verifying install for db->=4,<5|db->=4v0,<5v0 in databases/db/v4
===> Patching for db-4.6.21
===> Applying OpenBSD patch patch-dist_Makefile_in
patch: can't cd to
/usr/ports/pobj/db-4.6.21-no_java-bootstrap-no_tcl/db-4.6.21: No such file or
directory
***> patch-dist_Makefile_in did not apply cleanly
===> Applying OpenBSD patch patch-dist_configure
patch: can't cd to
/usr/ports/pobj/db-4.6.21-no_java-bootstrap-no_tcl/db-4.6.21: No such file or
directory
***> patch-dist_configure did not apply cleanly
===> Applying OpenBSD patch
patch-java_src_com_sleepycat_db_internal_db_javaJNI_java
patch: can't cd to
/usr/ports/pobj/db-4.6.21-no_java-bootstrap-no_tcl/db-4.6.21: No such file or
directory
***> patch-java_src_com_sleepycat_db_internal_db_javaJNI_java did not apply
cleanly
===> Applying OpenBSD patch patch-libdb_java_java_util_i
patch: can't cd to
/usr/ports/pobj/db-4.6.21-no_java-bootstrap-no_tcl/db-4.6.21: No such file or
directory
***> patch-libdb_java_java_util_i did not apply cleanly
===> Applying OpenBSD patch patch-tcl_tcl_compat_c
patch: can't cd to
/usr/ports/pobj/db-4.6.21-no_java-bootstrap-no_tcl/db-4.6.21: No such file or
directory
***> patch-tcl_tcl_compat_c did not apply cleanly
===> Applying OpenBSD patch patch-tcl_tcl_db_c
patch: can't cd to
/usr/ports/pobj/db-4.6.21-no_java-bootstrap-no_tcl/db-4.6.21: No such file or
directory
***> patch-tcl_tcl_db_c did not apply cleanly
===> Applying OpenBSD patch patch-tcl_tcl_db_pkg_c
patch: can't cd to
[UPDATE] x11/girara 0.3.8 -> 0.4.0 (fixes a SIGSEGV in textproc/zathura)
Hi. textproc/zathura will consistently SIGSEGV and dump a core file when
I hit to view the table of contents. I examined the core file and
found that this is due to an invalid read in girara_node_free,
referenced in this issue and fixed in the commit following it.
https://git.pwmt.org/pwmt/girara/-/issues/17
https://git.pwmt.org/pwmt/girara/-/commit/6926cc1234853ccf3010a1e2625aafcf462ed60e
Bumping x11/girara to 0.4.0 fixes the issue. I added SEPARATE_BUILD=Yes
while here since that works.
Any feedback? I kept the diff minimal, but am open to suggestions.
Index: Makefile
===
RCS file: /cvs/ports/x11/girara/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- Makefile28 Dec 2022 22:56:14 - 1.27
+++ Makefile25 Apr 2023 22:13:00 -
@@ -1,5 +1,5 @@
COMMENT = user interface library from pwmt
-DISTNAME = girara-0.3.8
+DISTNAME = girara-0.4.0
SHARED_LIBS += girara-gtk3 1.2 # 3.1
@@ -33,5 +33,7 @@ TEST_DEPENDS =devel/check
TEST_FLAGS += VERBOSE=1
TEST_FLAGS += HOME=${WRKDIR}
TEST_IS_INTERACTIVE =X11
+
+SEPARATE_BUILD = Yes
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/girara/distinfo,v
retrieving revision 1.15
diff -u -p -r1.15 distinfo
--- distinfo28 Dec 2022 22:56:14 - 1.15
+++ distinfo25 Apr 2023 22:13:00 -
@@ -1,2 +1,2 @@
-SHA256 (girara-0.3.8.tar.xz) = UXBiKODIIv8tMgkCnhQh6cFT7CAiemo8Z4V3Bipkg/w=
-SIZE (girara-0.3.8.tar.xz) = 60664
+SHA256 (girara-0.4.0.tar.xz) = zq/Qpq7VCtgyunZuxinx6jZmgcFfj6coqPVUGMOdyQE=
+SIZE (girara-0.4.0.tar.xz) = 60804
[UPDATE] textproc/p5-Regexp-Assemble 0.35p1 -> 0.38
Hey, happened to experiment with this module (am working through
Intermediate Perl) and noticed it wasn't the latest version.
Had to make a couple of small changes to the Makefile. I looked over the
list of changes since 0.35 the best I knew how (found the relevant
revisions with git-grep and git-rev-list -- no tags unfortunately).
$ cd ~/src && git clone https://github.com/ronsavage/Regexp-Assemble
$ cd Regexp-Assemble
$ git diff a448b18c1afb5578445947ed75aea1392697e334
76f53cffbb29e58dc228768e99fb134cd9c1027f
`make test` produces good output, and I can use the module without any
problems.
$ make test
[...]
# Testing Regexp::Assemble
t/00_basic.t .. ok
t/01_insert.t . ok
t/02_reduce.t . ok
t/03_str.t ok
t/04_match.t .. ok
t/05_hostmatch.t .. ok
t/06_general.t ok
t/07_warning.t ok
t/08_track.t .. ok
t/09_debug.t .. ok
t/10_perl514.t ok
All tests successful.
Files=11, Tests=2948, 3 wallclock secs ( 0.30 usr 0.02 sys + 2.86 cusr 0.20
csys = 3.38 CPU)
Result: PASS
OK?
Index: Makefile
===
RCS file: /cvs/ports/textproc/p5-Regexp-Assemble/Makefile,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile
--- Makefile11 Mar 2022 20:02:58 - 1.11
+++ Makefile24 Apr 2023 21:59:44 -
@@ -2,9 +2,9 @@ COMMENT = assemble multiple Regular Expr
MODULES = cpan
PKG_ARCH = *
-DISTNAME = Regexp-Assemble-0.35
+DISTNAME = Regexp-Assemble-0.38
CATEGORIES = textproc
-REVISION = 1
+EXTRACT_SUFX = .tgz
# Perl
PERMIT_PACKAGE = Yes
@@ -12,6 +12,6 @@ PERMIT_PACKAGE = Yes
MAKE_ENV +=TEST_POD=1
MODCPAN_EXAMPLES= Yes
-MODCPAN_EXAMPLES_DIST= eg
+MODCPAN_EXAMPLES_DIST= examples
.include
Index: distinfo
===
RCS file: /cvs/ports/textproc/p5-Regexp-Assemble/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:15:25 - 1.3
+++ distinfo24 Apr 2023 21:59:44 -
@@ -1,2 +1,2 @@
-SHA256 (Regexp-Assemble-0.35.tar.gz) =
AwHMaykwCR6+jz5vdc7ZXEpMnuFsQmGZigiTg2POXdc=
-SIZE (Regexp-Assemble-0.35.tar.gz) = 87019
+SHA256 (Regexp-Assemble-0.38.tgz) =
oGvn+a4bc8m/1bZmKxQcDXBGnpwZu0QTpu5W+Cra5EI=
+SIZE (Regexp-Assemble-0.38.tgz) = 106551
Index: pkg/PLIST
===
RCS file: /cvs/ports/textproc/p5-Regexp-Assemble/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST
--- pkg/PLIST 11 Mar 2022 20:02:58 - 1.3
+++ pkg/PLIST 24 Apr 2023 21:59:44 -
@@ -4,6 +4,7 @@ ${P5SITE}/Regexp/Assemble.pm
share/examples/p5-Regexp-Assemble/
share/examples/p5-Regexp-Assemble/assemble
share/examples/p5-Regexp-Assemble/debugging
+share/examples/p5-Regexp-Assemble/failure.01.pl
share/examples/p5-Regexp-Assemble/fee
share/examples/p5-Regexp-Assemble/file.1
share/examples/p5-Regexp-Assemble/file.2
Potential TLS-related DoS threat in some ports
Here's a quick demonstration of what I'm talking about with net/prosody, using
testssl.sh[1]:
$ testssl.sh -t xmpp -R example.com:5222
[ snip... ]
Testing for Renegotiation vulnerabilities
Secure Renegotiation (RFC 5746) supported (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS
threat
I've found this issue in two ports so far (net/prosody, telephony/coturn) and
suspect it may be in others due to the nature of the problem, which I'll get
into more in a moment. Upstream for net/prosody patched it May 12th of 2021[2],
so I was led to believe that it might be a local problem.
net/prosody relies on security/luasec to deal with TLS. In certmanager.lua[3],
it's
clear that it means to disable renegotiation based on these two lines in the
source (in different sections).
no_renegotiation = test_option("no_renegotiation");
no_renegotiation = luasec_has.options.no_renegotiation;
However, the problem is that security/luasec expects the option to be named
SSL_OP_NO_RENEGOTIATION and it's actually named SSL_OP_NO_CLIENT_RENEGOTIATION
in the OpenBSD source tree. This is shown in options.c[4] and in
lib/libssl/ssl.h[5].
#if defined(SSL_OP_NO_RENEGOTIATION)
{"no_renegotiation", SSL_OP_NO_RENEGOTIATION},
#endif
/* Disallow client initiated renegotiation. */
#define SSL_OP_NO_CLIENT_RENEGOTIATION 0x0002L
Though, in the case of security/luasec, there's a promising comment in options.c
that says:
/* If you need to generate these options again, see options.lua */
As I said before, I'm making an educated guess that some other ports may have
this issue as well. In fact, even the OpenBSD source tree has some mentions of
SSL_OP_NO_RENEGOTIATION in unbound and nsd sections (I'm using textproc/ripgrep
from ports to search here).
$ rg 'SSL_OP_NO_RENEGOTIATION'
usr.sbin/unbound/smallapp/unbound-control.c
541:#if defined(SSL_OP_NO_RENEGOTIATION)
543:if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
544:SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION)
545:ssl_err("could not set SSL_OP_NO_RENEGOTIATION");
usr.sbin/unbound/util/net_help.c
992:#if defined(SSL_OP_NO_RENEGOTIATION)
994:if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
995:SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
996:log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
1228:#if defined(SSL_OP_NO_RENEGOTIATION)
1230: if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
1231: SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
1232: log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
usr.sbin/nsd/server.c
2006:#if defined(SSL_OP_NO_RENEGOTIATION)
2008: if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
2009: SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
2010: log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
usr.sbin/nsd/nsd-control.c
187:#if defined(SSL_OP_NO_RENEGOTIATION)
189:if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
190:SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION)
191:ssl_err("could not set SSL_OP_NO_RENEGOTIATION");
sbin/unwind/libunbound/util/net_help.c
992:#if defined(SSL_OP_NO_RENEGOTIATION)
994:if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
995:SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
996:log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
1228:#if defined(SSL_OP_NO_RENEGOTIATION)
1230: if((SSL_CTX_set_options(ctx, SSL_OP_NO_RENEGOTIATION) &
1231: SSL_OP_NO_RENEGOTIATION) != SSL_OP_NO_RENEGOTIATION) {
1232: log_crypto_err("could not set SSL_OP_NO_RENEGOTIATION");
I don't exactly know what the best way to deal with this is, but I felt it was
important to bring to people's attention nonetheless.
[1]: https://github.com/drwetter/testssl.sh
[2]: https://prosody.im/security/advisory_20210512/
[3]: https://hg.prosody.im/0.12/file/tip/core/certmanager.lua
[4]: https://github.com/brunoos/luasec/blob/v1.0.1/src/options.c
[5]:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libssl/ssl.h?rev=1.230=text/plain
Re: UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
Can someone else review and OK this?
On 23/01/15 10:36, Omar Polo wrote:
>
> I haven't noticed before, sorry, but this shouldn't cause issues
> anymore. luasocket doesn't export the buffer_* symbols:
>
> % nm /usr/local/lib/lua/5.1/{mime,socket}/*so | grep buffer
>U luaL_prepbuffer
> F buffer.c
> 77a0 t buffer_init
> 80c0 t buffer_isempty
> 77f0 t buffer_meth_getstats
> 7bc0 t buffer_meth_receive
> 7980 t buffer_meth_send
> 7890 t buffer_meth_setstats
> 7770 t buffer_open
>U luaL_prepbuffer
> F buffer.c
> 47d0 t buffer_init
> 50f0 t buffer_isempty
> 4820 t buffer_meth_getstats
> 4bf0 t buffer_meth_receive
> 49b0 t buffer_meth_send
> 48c0 t buffer_meth_setstats
> 47a0 t buffer_open
>U luaL_prepbuffer
> F buffer.c
> 5650 t buffer_init
> 5f70 t buffer_isempty
> 56a0 t buffer_meth_getstats
> 5a70 t buffer_meth_receive
> 5830 t buffer_meth_send
> 5740 t buffer_meth_setstats
> 5620 t buffer_open
>U luaL_prepbuffer
>
> (this is luasocket built with patch below)
>
> The lowercase 't' should mean those symbols are private, right? if
> so, I think we can go on with the update. I'm reattaching Ashlen'
> patch without the sed to rename the symbols and with my previous
> tweaks included.
>
> ok?
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/luasocket/Makefile,v
> retrieving revision 1.37
> diff -u -p -r1.37 Makefile
> --- Makefile 11 Mar 2022 19:46:18 - 1.37
> +++ Makefile 9 Jan 2023 09:46:07 -
> @@ -1,49 +1,42 @@
> COMMENT= network support for the lua language
> -V= 3.0-rc1
> -GH_ACCOUNT= diegonehab
> +
> +V= 3.1.0
> +GH_ACCOUNT= lunarmodules
> GH_PROJECT= luasocket
> GH_TAGNAME= v$V
> -REVISION=1
> -PKGNAME= ${DISTNAME:S/-rc/rc/}
> +
> CATEGORIES= net
>
> -HOMEPAGE=http://w3.impa.br/~diego/software/luasocket/
> +HOMEPAGE=https://lunarmodules.github.io/luasocket/index.html
>
> # MIT
> PERMIT_PACKAGE= Yes
>
> MODULES= lang/lua
>
> -FLAVORS= lua52 lua53
> +FLAVORS= lua52 lua53 lua54
> FLAVOR?=
>
> -NO_TEST= Yes
> -
> -USE_GMAKE= Yes
> -
> MAKE_FILE= makefile
>
> +CFLAGS+= -fPIC -DPIC -I${MODLUA_INCL_DIR}
> +CFLAGS+= -DUNIX_HAS_SUN_LEN -DLUA_COMPAT_APIINTCASTS
> MAKE_FLAGS= CC_linux=${CC} \
> LD_linux=${CC} \
> - CFLAGS_linux="${CFLAGS} -I${MODLUA_INCL_DIR} -fPIC \
> - -DPIC -DUNIX_HAS_SUN_LEN \
> - -DLUA_COMPAT_APIINTCASTS" \
> - LDFLAGS_linux="${LDFLAGS} -shared -fPIC -o "
> -
> -do-install:
> - ${INSTALL_DATA_DIR} ${MODLUA_DATADIR}/socket ${MODLUA_DATADIR}/mime
> - ${INSTALL_DATA_DIR} ${MODLUA_LIBDIR}/socket ${MODLUA_LIBDIR}/mime
> + CFLAGS_linux="${CFLAGS}" \
> + LDFLAGS_linux="${LDFLAGS} -shared -fPIC -o " \
> + LUAV=${MODLUA_VERSION}
> +
> +INSTALL_TARGET= install-unix
> +
> +TEST_DEPENDS=${PKGPATH},${FLAVOR}=$V
> +
> +post-install:
> ${INSTALL_DATA_DIR} ${MODLUA_DOCDIR} ${MODLUA_EXAMPLEDIR}
> - ${INSTALL_DATA} ${WRKSRC}/src/socket.so ${MODLUA_LIBDIR}/socket/core.so
> - ${INSTALL_DATA} ${WRKSRC}/src/unix.so ${MODLUA_LIBDIR}/socket/unix.so
> - ${INSTALL_DATA} ${WRKSRC}/src/mime.so ${MODLUA_LIBDIR}/mime/core.so
> -.for l in ltn12 socket mime
> - ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}
> -.endfor
> -.for l in http url tp ftp headers smtp
> - ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}/socket
> -.endfor
> - ${INSTALL_DATA} ${WRKSRC}/doc/* ${MODLUA_DOCDIR}
> + ${INSTALL_DATA} ${WRKSRC}/docs/* ${MODLUA_DOCDIR}
> ${INSTALL_DATA} ${WRKSRC}/samples/* ${MODLUA_EXAMPLEDIR}
> +
> +pre-test:
> + ln -sf ${MODLUA_BIN} ${WRKDIR}/bin/lua
>
> .include
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/net/luasocket/distinfo,v
> retrieving revision 1.9
> diff -u -p -r1.9 distinfo
> --- distinfo 25 Nov 2013 15:27:56 - 1.9
> +++ distinfo 5 Jan 2023 10:40:51 -
> @@ -1,2 +1,2 @@
> -SHA256 (luasocket-3.0-rc1.tar.gz) =
> i2fZtbVF4baUdT2re9bNvCTCkPKyG6HhTHezKBfqEkk=
> -SIZE (luasocket-3.0-rc1.tar.
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=text/x-cvsweb-markup > https://marc.info/?l=freebsd-ports-bugs=125089202109336=2 > https://marc.info/?l=freebsd-ports=125097467421558=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 net/luasocket 3.0rc1p1 -> 3.1.0
On 23/01/07 04:33, Lucas wrote: > Ashlen wrote: > > On 23/01/06 12:53, Omar Polo wrote: > > > This needs some further testing. Packages that depends on luasockets > > > are > > > > > > - devel/luacopasno test suite > > > - devel/luaeventtest run OK > > > - net/jitsi/prosody-plugins no test suite > > > - net/prosody no test suite > > > - security/luasec no test suite > > > - www/luakitwith simple runtesting seems fine > > > > > > I can manage to test it with net/prosody on -RELEASE but will take a > > > while. > > > > I'll see if I can test against net/prosody on -RELEASE as well, actually. > > I'll > > do my best to follow your suggestions. Thank you for taking the time to > > respond. > > Prosody port maintainer here. Built and installed it with op@ patch in > my -current and restarted prosody. It didn't blow up and is currently > connected to my usual servers. Running with LD_DEBUG shows it's actually > used (is there a better way to check which dynamic libraries a running > process is using? fstat doesn't provide that info :( ) > > dlopen: loading: /usr/local/lib/lua/5.3/socket/unix.so > flags /usr/local/lib/lua/5.3/socket/unix.so = 0x0 > head /usr/local/lib/lua/5.3/socket/unix.so > obj /usr/local/lib/lua/5.3/socket/unix.so has > /usr/local/lib/lua/5.3/socket/unix.so as head > linking /usr/local/lib/lua/5.3/socket/unix.so as dlopen()ed > head [/usr/local/lib/lua/5.3/socket/unix.so] > examining: '/usr/local/lib/lua/5.3/socket/unix.so' > tail /usr/local/lib/lua/5.3/socket/unix.so > protect RELRO [0x6810b52eba0,0x6810b53) in > /usr/local/lib/lua/5.3/socket/unix.so > doing ctors obj 0x680e98f65f0 @0x6810b52d0b0: > [/usr/local/lib/lua/5.3/socket/unix.so] > dlopen: /usr/local/lib/lua/5.3/socket/unix.so: done (success). > dlsym: luaopen_socket_unix in /usr/local/lib/lua/5.3/socket/unix.so: > 0x6810b52cf60 > > -Lucas > Thanks Lucas, I was actually a little wary of trying to build an updated version of net/luasocket against 7.2. I'm still really new to this stuff. net/prosody depends on security/luasec, so if I understand it correctly, that means devel/luacopas and net/jitsi/prosody-plugins are the ones left untested. 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=text/x-cvsweb-markup https://marc.info/?l=freebsd-ports-bugs=125089202109336=2 https://marc.info/?l=freebsd-ports=125097467421558=2 As for the dynamic library thing, I'm unsure. I know about ldd(1) but that's not for a running program. Maybe some of the tracing software available, like ltrace(1) or similar, could do it.
Re: UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
(Sorry Omar, I accidentally replied directly off-list)
On 23/01/06 12:53, Omar Polo wrote:
> Hello,
>
> On 2023/01/04 21:13:29 -0700, Ashlen wrote:
> > Updated a couple of things.
> >
> > - Use '&&' instead of ';' so that sed only executes after a successful cd.
> >
> > - Needed to patch version string in src/luasocket.h, I guess I left that
> > out for
> > some reason.
> >
> > - Add TEST_DEPENDS so that make test only works if net/luasocket is
> > installed.
> >
> > Is this OK? Any feedback?
>
> thanks for looking at luasocket.
Of course. I was looking into a separate issue and saw it was out of date. I run
net/prosody and want the dependencies to be up to date.
(Off-topic: that separate issue that caused me to end up here is an interaction
between security/luasec and net/prosody that results in Secure Client-Initiated
Renegotiation being enabled by default instead of disabled. I found it with
testssl.sh. Allegedly that's a potential DoS risk, so I'd also like to fix that
at some point, but as I said it's unrelated. Would be content to go into more
detail about that in a separate mail on ports@).
> The diff looks mostly OK to me, a few considerations:
>
> - Fails to package with lua != 5.1; need to set LUAV=5.X for it to
>work (try `FLAVOR=lua52 make package')
Thanks for pointing that out, I didn't think about that. Reproduced that failure
locally.
> - Maybe we can drop the buffer_* -> ls_buffer_* rename? FreeBSD had
>similar patches and they dropped them with the update to 3.0.0[0].
>Unfortunately the commit message doesn't explain why.
>
>A quick compare of `nm /usr/local/lib/lighttpd/mod_magnet.so' with
>the exported symbols from buffer.c show no overlap, but I haven't
>run-tested.
I think "buffer_init" is the thing that was said to cause a problem, although I
haven't run-tested either. mod_magnet at the time of that commit (way back in
2009) appears to call it, but you're right, it doesn't anymore. Though, other
stuff in lighttpd might, so I wanted to check and see if it needs more
investigating.
I installed lighttpd and checked out version 3.1.0 of luasocket. Here I'm
grabbing all of the symbols that start with buffer_.
$ nm /usr/local/lib/lighttpd/mod_*.so \
| perl -nE 'chomp; next unless /\bbuffer_/; @segments = split " "; say
$segments[1]' \
| sort -u
buffer_append_base64_decode
buffer_append_base64_enc
buffer_append_bs_escaped
[a lot more entries like this...]
I did some text filtering on this output to build a command to compare the
symbols against luasocket. Here's an echo to show what would get executed, so
the results of the eval afterward will make sense.
$ cd /path/to/luasocket_src
$ echo grep -nR "$(\
nm /usr/local/lib/lighttpd/mod_*.so \
| perl -nE 'chomp; next unless /\bbuffer_/; @segments = split " "; say
$segments[1]' \
| sort -u \
| sed -e 's/^/-e /' -e 's/buffer_.*/\"&\"/' \
| tr '\n' ' ' \
)".
grep -nR -e "buffer_append_base64_decode" -e "buffer_append_base64_enc"
[snip...] .
Replacing that echo with an eval, I get this.
./src/buffer.c:40:void buffer_init(p_buffer buf, p_io io, p_timeout tm) {
./src/buffer.h:41:void buffer_init(p_buffer buf, p_io io, p_timeout tm);
./src/tcp.c:238:buffer_init(>buf, >io, >tm);
./src/tcp.c:409:buffer_init(>buf, >io, >tm);
./src/tcp.c:448:buffer_init(>buf, >io, >tm);
./src/serial.c:169:buffer_init(>buf, >io, >tm);
./src/unixdgram.c:398:buffer_init(>buf, >io, >tm);
./src/unixstream.c:172:buffer_init(>buf, >io, >tm);
./src/unixstream.c:348:buffer_init(>buf, >io, >tm);
So it appears "buffer_init" is the one that shows up in both. I was curious what
modules in lighttpd have buffer_init in their symbols table. Here they are:
$ for lighttpd_module in /usr/local/lib/lighttpd/mod_*.so; do
if nm "${lighttpd_module}" | grep -qE '[[:<:]]buffer_init[[:>:]]'; then
echo "${lighttpd_module}"
fi
done
/usr/local/lib/lighttpd/mod_cgi.so
/usr/local/lib/lighttpd/mod_openssl.so
$ nm /usr/local/lib/lighttpd/mod_{cgi,openssl}.so | grep -E
'[[:<:]]buffer_init[[:>:]]'
U buffer_init
U buffer_init
(Off-topic: if any of the commands I used or my approach to find this are flawed
in some way, feel free to point it out. Always happy to learn. I only know Perl
and shell, so my knowledge of lower level things is lacking.)
I'm unsure how to test lighttpd for that SIGSEGV at the moment. I'd need to look
(or if someone else familiar with lighttpd would be willing to test it, that'd
be great. I've never used it).
>Anyway, patches are better than sed. You get to s
Re: UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
Updated a couple of things.
- Use '&&' instead of ';' so that sed only executes after a successful cd.
- Needed to patch version string in src/luasocket.h, I guess I left that out for
some reason.
- Add TEST_DEPENDS so that make test only works if net/luasocket is installed.
Is this OK? Any feedback?
Index: Makefile
===
RCS file: /cvs/ports/net/luasocket/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile11 Mar 2022 19:46:18 - 1.37
+++ Makefile5 Jan 2023 03:34:48 -
@@ -1,13 +1,12 @@
COMMENT= network support for the lua language
-V= 3.0-rc1
-GH_ACCOUNT=diegonehab
+V= 3.1.0
+GH_ACCOUNT=lunarmodules
GH_PROJECT=luasocket
GH_TAGNAME=v$V
-REVISION= 1
PKGNAME= ${DISTNAME:S/-rc/rc/}
CATEGORIES=net
-HOMEPAGE= http://w3.impa.br/~diego/software/luasocket/
+HOMEPAGE= https://lunarmodules.github.io/luasocket/index.html
# MIT
PERMIT_PACKAGE=Yes
@@ -17,10 +16,6 @@ MODULES= lang/lua
FLAVORS= lua52 lua53
FLAVOR?=
-NO_TEST= Yes
-
-USE_GMAKE= Yes
-
MAKE_FILE= makefile
MAKE_FLAGS=CC_linux=${CC} \
@@ -30,20 +25,27 @@ MAKE_FLAGS= CC_linux=${CC} \
-DLUA_COMPAT_APIINTCASTS" \
LDFLAGS_linux="${LDFLAGS} -shared -fPIC -o "
-do-install:
- ${INSTALL_DATA_DIR} ${MODLUA_DATADIR}/socket ${MODLUA_DATADIR}/mime
- ${INSTALL_DATA_DIR} ${MODLUA_LIBDIR}/socket ${MODLUA_LIBDIR}/mime
+# Needed so that Unix specific components are installed.
+INSTALL_TARGET=install install-unix
+
+TEST_DEPENDS= ${FULLPKGNAME}:${BUILD_PKGPATH}
+
+# Consult ${WRKSRC}/makefile and ${WRKSRC}/test/README to make sure this test
is
+# up to date.
+do-test:
+ ${MODLUA_BIN} ${WRKSRC}/test/hello.lua
+
+# This replaces all buffer_* functions with ls_buffer_* instead.
+#
+# "luasocket defines buffer_init(); which is common enough to be defined
+# elsewhere and it is defined in mod_magnet, so you end up with a SIGSEGV.
+# So rename buffer_* funcs to ls_buffer_*."
+post-patch:
+ cd ${WRKSRC}/src && sed -i -e 's/[[:<:]]buffer_/ls_buffer_/g' ./*
+
+post-install:
${INSTALL_DATA_DIR} ${MODLUA_DOCDIR} ${MODLUA_EXAMPLEDIR}
- ${INSTALL_DATA} ${WRKSRC}/src/socket.so ${MODLUA_LIBDIR}/socket/core.so
- ${INSTALL_DATA} ${WRKSRC}/src/unix.so ${MODLUA_LIBDIR}/socket/unix.so
- ${INSTALL_DATA} ${WRKSRC}/src/mime.so ${MODLUA_LIBDIR}/mime/core.so
-.for l in ltn12 socket mime
- ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}
-.endfor
-.for l in http url tp ftp headers smtp
- ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}/socket
-.endfor
- ${INSTALL_DATA} ${WRKSRC}/doc/* ${MODLUA_DOCDIR}
+ ${INSTALL_DATA} ${WRKSRC}/docs/* ${MODLUA_DOCDIR}
${INSTALL_DATA} ${WRKSRC}/samples/* ${MODLUA_EXAMPLEDIR}
.include
Index: distinfo
===
RCS file: /cvs/ports/net/luasocket/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo25 Nov 2013 15:27:56 - 1.9
+++ distinfo5 Jan 2023 03:34:48 -
@@ -1,2 +1,2 @@
-SHA256 (luasocket-3.0-rc1.tar.gz) =
i2fZtbVF4baUdT2re9bNvCTCkPKyG6HhTHezKBfqEkk=
-SIZE (luasocket-3.0-rc1.tar.gz) = 328598
+SHA256 (luasocket-3.1.0.tar.gz) = vwM6655ivKqNAH32jBGclmQY6Mnvfk8tfpa93sqcym4=
+SIZE (luasocket-3.1.0.tar.gz) = 336542
Index: patches/patch-docs_installation_html
===
RCS file: patches/patch-docs_installation_html
diff -N patches/patch-docs_installation_html
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-docs_installation_html5 Jan 2023 03:34:48 -
@@ -0,0 +1,12 @@
+Index: docs/installation.html
+--- docs/installation.html.orig
docs/installation.html
+@@ -89,7 +89,7 @@ it should be easy to use LuaSocket. Just fire the inte
+ Lua 5.2.2 Copyright (C) 1994-2013 Lua.org, PUC-Rio
+ socket = require("socket")
+ print(socket._VERSION)
+--- LuaSocket 3.0.0
++-- LuaSocket 3.1.0
+
+
+ Each module loads their dependencies automatically, so you only need to
Index: patches/patch-makefile_dist
===
RCS file: patches/patch-makefile_dist
diff -N patches/patch-makefile_dist
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-makefile_dist 5 Jan 2023 03:34:48 -
@@ -0,0 +1,12 @@
+Index: makefile.dist
+--- makefile.dist.orig
makefile.dist
+@@ -1,7 +1,7 @@
+ #--
+ # Distribution makefile
+ #--
+-DIST = luasocket-3.0.0
++DIST = luasocket-3.1.0
+
+ TEST = \
+ test/README \
Index: patches/patch-src_buffer_c
===
RCS file:
UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
Hey, this is my first diff to the ports tree. How does this look? I don't
program in Lua (yet), but I followed the porting guide and from what I can tell,
this seems alright.
Some quick notes:
- HOMEPAGE and GH_ACCOUNT changed.
- The do-install hook is changed to a post-install hook because it had been said
to be less fragile.
- Regression testing is now supported with a do-test hook, and so NO_TEST was
removed.
- USE_GMAKE was removed because the port appears to build and work without it.
- Some version strings were still 3.0.0 rather than 3.1.0 so they were patched
accordingly. I can see if upstream will fix this.
- Other patches that renamed 'buffer_*' to 'ls_buffer_*' were removed and
replaced with a post-patch hook. Does this seem like an alright way to
approach this problem?
- An INSTALL_TARGET is supplied so that everything is installed properly. In the
future, it may be worth looking into src/makefile and adding an OpenBSD
section (FreeBSD has one).
Index: Makefile
===
RCS file: /cvs/ports/net/luasocket/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile11 Mar 2022 19:46:18 - 1.37
+++ Makefile4 Jan 2023 02:07:06 -
@@ -1,13 +1,12 @@
COMMENT= network support for the lua language
-V= 3.0-rc1
-GH_ACCOUNT=diegonehab
+V= 3.1.0
+GH_ACCOUNT=lunarmodules
GH_PROJECT=luasocket
GH_TAGNAME=v$V
-REVISION= 1
PKGNAME= ${DISTNAME:S/-rc/rc/}
CATEGORIES=net
-HOMEPAGE= http://w3.impa.br/~diego/software/luasocket/
+HOMEPAGE= https://lunarmodules.github.io/luasocket/index.html
# MIT
PERMIT_PACKAGE=Yes
@@ -17,10 +16,6 @@ MODULES= lang/lua
FLAVORS= lua52 lua53
FLAVOR?=
-NO_TEST= Yes
-
-USE_GMAKE= Yes
-
MAKE_FILE= makefile
MAKE_FLAGS=CC_linux=${CC} \
@@ -30,20 +25,25 @@ MAKE_FLAGS= CC_linux=${CC} \
-DLUA_COMPAT_APIINTCASTS" \
LDFLAGS_linux="${LDFLAGS} -shared -fPIC -o "
-do-install:
- ${INSTALL_DATA_DIR} ${MODLUA_DATADIR}/socket ${MODLUA_DATADIR}/mime
- ${INSTALL_DATA_DIR} ${MODLUA_LIBDIR}/socket ${MODLUA_LIBDIR}/mime
+# Needed so that Unix specific components are installed.
+INSTALL_TARGET=install install-unix
+
+# Consult ${WRKSRC}/makefile and ${WRKSRC}/test/README to make sure this test
is
+# up to date.
+do-test:
+ ${MODLUA_BIN} ${WRKSRC}/test/hello.lua
+
+# This replaces all buffer_* functions with ls_buffer_* instead.
+#
+# "luasocket defines buffer_init(); which is common enough to be defined
+# elsewhere and it is defined in mod_magnet, so you end up with a SIGSEGV.
+# So rename buffer_* funcs to ls_buffer_*."
+post-patch:
+ cd ${WRKSRC}/src; sed -i -e 's/[[:<:]]buffer_/ls_buffer_/g' ./*
+
+post-install:
${INSTALL_DATA_DIR} ${MODLUA_DOCDIR} ${MODLUA_EXAMPLEDIR}
- ${INSTALL_DATA} ${WRKSRC}/src/socket.so ${MODLUA_LIBDIR}/socket/core.so
- ${INSTALL_DATA} ${WRKSRC}/src/unix.so ${MODLUA_LIBDIR}/socket/unix.so
- ${INSTALL_DATA} ${WRKSRC}/src/mime.so ${MODLUA_LIBDIR}/mime/core.so
-.for l in ltn12 socket mime
- ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}
-.endfor
-.for l in http url tp ftp headers smtp
- ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}/socket
-.endfor
- ${INSTALL_DATA} ${WRKSRC}/doc/* ${MODLUA_DOCDIR}
+ ${INSTALL_DATA} ${WRKSRC}/docs/* ${MODLUA_DOCDIR}
${INSTALL_DATA} ${WRKSRC}/samples/* ${MODLUA_EXAMPLEDIR}
.include
Index: distinfo
===
RCS file: /cvs/ports/net/luasocket/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo25 Nov 2013 15:27:56 - 1.9
+++ distinfo4 Jan 2023 02:07:06 -
@@ -1,2 +1,2 @@
-SHA256 (luasocket-3.0-rc1.tar.gz) =
i2fZtbVF4baUdT2re9bNvCTCkPKyG6HhTHezKBfqEkk=
-SIZE (luasocket-3.0-rc1.tar.gz) = 328598
+SHA256 (luasocket-3.1.0.tar.gz) = vwM6655ivKqNAH32jBGclmQY6Mnvfk8tfpa93sqcym4=
+SIZE (luasocket-3.1.0.tar.gz) = 336542
Index: patches/patch-docs_installation_html
===
RCS file: patches/patch-docs_installation_html
diff -N patches/patch-docs_installation_html
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-docs_installation_html4 Jan 2023 02:07:06 -
@@ -0,0 +1,12 @@
+Index: docs/installation.html
+--- docs/installation.html.orig
docs/installation.html
+@@ -89,7 +89,7 @@ it should be easy to use LuaSocket. Just fire the inte
+ Lua 5.2.2 Copyright (C) 1994-2013 Lua.org, PUC-Rio
+ socket = require("socket")
+ print(socket._VERSION)
+--- LuaSocket 3.0.0
++-- LuaSocket 3.1.0
+
+
+ Each module loads their dependencies automatically, so you only need to
Index: patches/patch-makefile_dist
===
RCS file:
Re: no output from zathura
On 22/04/24 08:11, Landry Breuil wrote: > Le Sat, Apr 23, 2022 at 05:44:41PM -0600, Ashlen a écrit : > > I'm still getting the same problem with the mupdf plugin on the snapshot > > mentioned below. > > > > > > $ sysctl -n kern.version > > OpenBSD 7.1-current (GENERIC.MP) #483: Sat Apr 23 05:33:19 MDT 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > that's one data point, but do you have zathura-pdf-mupdf-0.3.8 or > zathura-pdf-mupdf-0.3.8p0 installed ? only the latter has stuart's fix > (https://github.com/openbsd/ports/commit/11f36733ca2bddc98932283aac772c7bd9bae1ff) zathura-pdf-mupdf-0.3.8. I should've included pkg_info(1) output there, will remember that for next time. I do see Stuart's email about the newer package not being available yet, so I'll sit tight for now and work around it until the newer package becomes available. Thanks for the help everyone. -- https://amissing.link/
Re: no output from zathura
I'm still getting the same problem with the mupdf plugin on the snapshot mentioned below. $ sysctl -n kern.version OpenBSD 7.1-current (GENERIC.MP) #483: Sat Apr 23 05:33:19 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Here are the dynamic libraries marked as needed from objdump(1). $ objdump -p /usr/local/lib/zathura/libpdf-mupdf.so | grep NEEDED NEEDED libgirara-gtk3.so.1.2 NEEDED libharfbuzz.so.17.3 NEEDED libcairo.so.13.2 NEEDED libglib-2.0.so.4201.8 After shooting in the dark for a bit, I looked at the other dependencies in the build file, and noticed these libraries are missing from that output: libjbig2dec.so.1.0 libopenjp2.so.4.0 libgumbo.so.0.0 nm(1) showed that they contain the needed symbols. Using LD_PRELOAD with them listed causes zathura to work. Without LD_PRELOAD, it breaks like before. Sadly, I don't know much about meson build files, or libraries and linking for that matter, so I wouldn't know how to write a diff to fix this. $ LD_PRELOAD=/usr/local/lib/libgumbo.so.0.0:/usr/local/lib/libopenjp2.so.4.0:/usr/local/lib/libjbig2dec.so.1.0 zathura --version zathura 0.4.9 girara 0.3.7 (runtime: 0.3.7) (plugin) pdf-mupdf (0.3.8) (/usr/local/lib/zathura/libpdf-mupdf.so) $ zathura --version zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_ctx_new_imp' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_data_in' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_make_global_ctx' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_global_ctx_free' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_complete_page' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_page_out' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_release_page' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'jbig2_ctx_free' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_set_default_decoder_parameters' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_create_decompress' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_set_info_handler' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_set_warning_handler' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_set_error_handler' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_setup_decoder' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_default_create' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_set_read_function' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_set_skip_function' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_set_seek_function' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_set_user_data' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_set_user_data_length' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_read_header' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_decode' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_stream_destroy' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_destroy_codec' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'opj_image_destroy' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'gumbo_parse_with_options' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'gumbo_destroy_output' zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol 'gumbo_normalized_tagname' error: Could not load plugin '/usr/local/lib/zathura/libpdf-mupdf.so' (Cannot load specified object). zathura 0.4.9 girara 0.3.7 (runtime: 0.3.7) On 22/04/18 22:36, Stuart Henderson wrote: > I've committed a fix. > > If you report problems with ports, it would help to include at least: > > - OpenBSD version and machine arch (it never hurts to include the full dmesg) > - Package version > - (plus the description of what happens, any console messages etc, like > you included here) > > And preferably on ports@ rather than misc. > > > On 2022-04-18, Shadrock Uhuru wrote: > > Hi everyone > > i have zathura zathura-ps zathura-pdf-mupdf installed, > > i run zathura from the command line with zathura file.pdf which opens > > zathura with nothing > > displayed, > > the shell that i run zathura from displays the following > > > > zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol > > 'jbig2_ctx_new_imp' > > zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol > > 'jbig2_data_in' > > zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol > > 'jbig2_make_global_ctx' > > zathura:/usr/local/lib/zathura/libpdf-mupdf.so: undefined symbol
Re: removing libutil.so.15.1 and libX11.so.17.1 per sysclean(8) breaks xmonad(1)
On 22/04/03 21:04, Stuart Henderson wrote:
> [ dropping misc@ from CC list ]
>
> On 2022/04/03 11:25, Ashlen wrote:
> > With the previous emails in mind, I have a diff for the build script in
> > the ports tree if it would help. My xmonad.hs hardly changes these days.
> > If the build script actually recompiled xmonad every time instead of
> > quitting if xmonad.hs hasn't changed, I don't think this issue would
> > come up in the future.
>
> How about comparing the date of /usr/local/bin/xmonad as well?
> If libraries have changed such that a rebuild is needed, that binary
> ought to have been updated too.
>
> if [ "${output_file}" -nt xmonad.hs -a "${output_file}" -nt
> /usr/local/bin/xmonad ]; then
> ...
>
> Or is it fast enough anyway? I couldn't tell, there seem to be other problems:
I didn't think to do that, but I bet that would probably work (and is a
better solution than recompiling every time). Although I would tend to
prefer this form:
if [ "${output_file}" -nt xmonad.hs ] && [ "${output_file}" -nt
/usr/local/bin/xmonad ]; then
...
I prefer that over the form mentioned as it avoids some potential
ambiguity/maintenance issues in the long run. Here's a relevant entry
from the shellcheck wiki on github.
https://github.com/koalaman/shellcheck/wiki/SC2166
> | Install notice:
> | XMonad is now compiled using `cabal v2-build`. If you rely on a custom
> | xmonad.hs configuration file, you should switch to using
> | ~/.xmonad/build script. An example is included in
> | /usr/local/share/examples/xmonad-0.17.0
>
> Looks like it should be ~/.config/xmonad/build rather than ~/.xmonad/build,
> but also it doesn't seem to actually work:
>
> | $ Xnest :1 &
> | [1] 13846
> | $ DISPLAY=:1 xmonad
> | XMonad is recompiling and replacing itself with another XMonad process
> because the current process is called "xmonad" but the compiled configuration
> should be called "xmonad-x86_64-openbsd"
> | XMonad will use build script at "/home/sthen/.config/xmonad/build" to
> recompile.
> | XMonad recompiling because a custom build script is being used.
> | Errors detected while compiling xmonad config:
> /home/sthen/.config/xmonad/xmonad.hs
> | $ /home/sthen/.config/xmonad/build
> /home/sthen/.cache/xmonad/xmonad-x86_64-openbsd
> | cabal: Unknown package "exe".
> |
> |
> | Please check the file for errors.
> |
> | /home/sthen/.cache/xmonad/xmonad-x86_64-openbsd: executeFile: does not
> exist (No such file or directory)
> ...
>
My apologies for the confusion, it would be ~/.xmonad/build by default.
Everything goes in ~/.xmonad by default. I have configured my setup so
everything isn't in ~/.xmonad, but rather split up into different
directories via XMONAD_CACHE_DIR, XMONAD_CONFIG_DIR, and
XMONAD_DATA_DIR. I prefer to follow the XDG base directory specification
when possible so that config files are in ~/.config, user scripts are in
~/.local/bin, etc.
Here are the relevant bits in ~/.profile (sourced by ~/.xsession) that I
use to make that work:
export \
XDG_BIN_HOME="${HOME}/.local/bin" \
XDG_CACHE_HOME="${HOME}/.cache" \
XDG_CONFIG_HOME="${HOME}/.config" \
XDG_DATA_HOME="${HOME}/.local/share" \
XDG_STATE_HOME="${HOME}/.local/state"
export \
XMONAD_CACHE_DIR="${XDG_CACHE_HOME}/xmonad" \
XMONAD_CONFIG_DIR="${XDG_CONFIG_HOME}/xmonad" \
XMONAD_DATA_DIR="${XDG_DATA_HOME}/xmonad"
Sorry about the mix-up. Either configuring it as above and, to be on the
safe side, making sure that $XMONAD_*_DIR all exist, should work. Or
using ~/.xmonad if you don't want it to be separated like that (this is
also easier to deal with if xmonad or the XDG base directory
specification are unfamiliar territory, since it's all in one location).
Also, you'll need to have an xmonad-config.cabal if you don't have it
already, either in ~/.config/xmonad/xmonad-config.cabal if you used the
exports above or ~/.xmonad/xmonad-config.cabal. An example config can be
found at /usr/local/share/examples/xmonad-0.17.0/xmonad-config.cabal.
I'd guess the absence of that file might be causing 'cabal: Unknown
package "exe".'
Here's an updated diff implementing your suggested change. Thanks for
your time and I hope it helps. :)
Index: files/build
===
RCS file: /cvs/ports/x11/xmonad/files/build,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 build
--- files/build 1 Mar 2021 04:16:34 - 1.1
+++ files/build 4 Apr 2022 02:58:22 -
@@ -2,7 +2,7 @@
output_file="${1}"
-if [ "${output_file}" -nt xmonad.hs ]; then
+if [ "${output_file}" -nt xmonad.hs ] && [ "${output_file}" -nt
/usr/local/bin/xmonad ]; then
echo "${output_file}" is newer than xmonad.hs
exit 0
fi
--
https://amissing.link/
Re: removing libutil.so.15.1 and libX11.so.17.1 per sysclean(8) breaks xmonad(1)
With the previous emails in mind, I have a diff for the build script in
the ports tree if it would help. My xmonad.hs hardly changes these days.
If the build script actually recompiled xmonad every time instead of
quitting if xmonad.hs hasn't changed, I don't think this issue would
come up in the future.
Index: files/build
===
RCS file: /cvs/ports/x11/xmonad/files/build,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 build
--- files/build 1 Mar 2021 04:16:34 - 1.1
+++ files/build 3 Apr 2022 17:02:34 -
@@ -2,11 +2,6 @@
output_file="${1}"
-if [ "${output_file}" -nt xmonad.hs ]; then
-echo "${output_file}" is newer than xmonad.hs
-exit 0
-fi
-
cabal v2-install exe:xmonad-config --overwrite-policy=always
--install-method=copy
[ -e "${output_file}" ] && mv -f "${output_file}" "${output_file}.old"
--
https://amissing.link/
Re: ncmpcpp dumps core when fetching lyrics
On 2020/09/12 12:36, Erling Westenvik wrote: > Thanks for the diff. Ncmpcpp still crashes when trying to fetch lyrics though. > Gdb output with last version and after rebuilding with debug flags: Yep, same here. Needed `-l` to patch(1) the diff, not sure if it's an issue with the diff or PEBCAK. Probably the second one. On 20/09/12 12:42PM, Stuart Henderson wrote: > Since the problem still exists in git head, I think it would be worth > reporting this upstream. Added a comment referencing this thread here[1] with my dummy account (I don't trust M$). I figured it wasn't worth creating a separate issue. [1] https://github.com/ncmpcpp/ncmpcpp/issues/394 -- https://amissing.link
