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
Re: new: devel/selene
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.
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: rsync and xxhash are broken on strict alignment architectures
On Thu 17/08/2023 01:07, Stuart Henderson wrote: > On 2023/08/16 23:55, Christian Weisgerber wrote: > > Stuart Henderson: > > > > > +-# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 && > > > defined(__ARM_FEATURE_UNALIGNED)) > > > ++# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 && > > > defined(__ARM_FEATURE_UNALIGNED)) && !defined(__sparc64__) > > > > This should include and check __STRICT_ALIGNMENT rather than > > hardcoding architectures. > > ...which would look something like the diff below (trying to keep the > added #include so that it's only used in as few cases as possible). > > No idea if this is actually needed on other strict alignment archs > though, it does sound like upstream weren't expecting this to be broken... > from > https://fastcompression.blogspot.com/2015/08/accessing-unaligned-memory.html > it seems like setting to 1 may be mostly intended as a speed optimisation > for armv7, and this ifdef intended to prevent it making things worse for > armv6. But it's been a while, perhaps armv7 compilers are better by now, > so maybe we're better off just disabling the #define XXH_FORCE_MEMORY_ACCESS > 1. > > I don't have any affected hw to test with. No objections here, OK bket@
sysutils/xxhash: pledge xxhsum(1)
Compared to md5(1) with [-h hashfile], xxhsum(1) has no option to write
to anything but standard output.
Dropping "rpath" later can be done, but needs more patching and testing.
Works for me, tests pass.
Feedback? Objcetion? OK?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/xxhash/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile23 Jul 2023 04:29:44 - 1.13
+++ Makefile17 Aug 2023 01:19:55 -
@@ -4,18 +4,20 @@ GH_ACCOUNT = Cyan4973
GH_PROJECT = xxHash
GH_TAGNAME = v0.8.2
PKGNAME = ${DISTNAME:L}
+REVISION = 0
SHARED_LIBS = xxhash 0.3 # 0.8.1
CATEGORIES = sysutils
-HOMEPAGE = https://cyan4973.github.io/xxHash/
+HOMEPAGE = https://xxhash.com
MAINTAINER = Bjorn Ketelaars
# BSD 2-Clause
PERMIT_PACKAGE = Yes
+# uses pledge()
WANTLIB = c
MAKE_FLAGS = CC="${CC}" \
Index: patches/patch-cli_xsum_os_specific_c
===
RCS file: patches/patch-cli_xsum_os_specific_c
diff -N patches/patch-cli_xsum_os_specific_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cli_xsum_os_specific_c17 Aug 2023 01:41:40 -
@@ -0,0 +1,27 @@
+Use pledge(2), xxhsum(1) only ever reads files or stdin.
+
+Index: cli/xsum_os_specific.c
+--- cli/xsum_os_specific.c.orig
cli/xsum_os_specific.c
+@@ -69,6 +69,9 @@ static int XSUM_IS_CONSOLE(FILE* stdStream)
+ || defined(__DJGPP__) \
+ || defined(__MSYS__) \
+ || defined(__HAIKU__)
++# ifdef __OpenBSD__
++#include
++# endif
+ # include/* isatty */
+ # define XSUM_IS_CONSOLE(stdStream) isatty(fileno(stdStream))
+ #elif defined(MSDOS) || defined(OS2)
+@@ -135,6 +138,11 @@ static int XSUM_stat(const char* infilename, XSUM_stat
+ #ifndef XSUM_NO_MAIN
+ int main(int argc, const char* argv[])
+ {
++#ifdef __OpenBSD__
++if (pledge("stdio rpath", NULL) == -1)
++err(1, "pledge");
++#endif
++
+ return XSUM_main(argc, argv);
+ }
+ #endif
Index: patches/patch-tests_sanity_test_c
===
RCS file: patches/patch-tests_sanity_test_c
diff -N patches/patch-tests_sanity_test_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-tests_sanity_test_c 17 Aug 2023 01:41:40 -
@@ -0,0 +1,17 @@
+Use pledge(2), the sanity test does even not read files.
+
+Index: tests/sanity_test.c
+--- tests/sanity_test.c.orig
tests/sanity_test.c
+@@ -639,6 +639,11 @@ int main(int argc, const char* argv[])
+ (void) argc;
+ (void) argv;
+
++#ifdef __OpenBSD__
++if (pledge("stdio", NULL) == -1)
++err(1, "pledge");
++#endif
++
+ {
+ /* XXH32 */
+ size_t const n = sizeof(XSUM_XXH32_testdata) /
sizeof(XSUM_XXH32_testdata[0]);
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 18:28:39 Modified files: security/clamav: Tag: OPENBSD_7_3 Makefile distinfo Log message: update to clamav-1.0.2 CVE-2023-20197 Fixed a possible denial of service vulnerability in the HFS+ file parser. CVE-2023-20212 Fixed a possible denial of service vulnerability in the AutoIt file parser.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 18:22:07 Modified files: security/clamav: Makefile distinfo Log message: update to clamav-1.1.1 CVE-2023-20197 Fixed a possible denial of service vulnerability in the HFS+ file parser.
Re: rsync and xxhash are broken on strict alignment architectures
On 2023/08/16 23:55, Christian Weisgerber wrote:
> Stuart Henderson:
>
> > +-# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 &&
> > defined(__ARM_FEATURE_UNALIGNED))
> > ++# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 &&
> > defined(__ARM_FEATURE_UNALIGNED)) && !defined(__sparc64__)
>
> This should include and check __STRICT_ALIGNMENT rather than
> hardcoding architectures.
...which would look something like the diff below (trying to keep the
added #include so that it's only used in as few cases as possible).
No idea if this is actually needed on other strict alignment archs
though, it does sound like upstream weren't expecting this to be broken...
from
https://fastcompression.blogspot.com/2015/08/accessing-unaligned-memory.html
it seems like setting to 1 may be mostly intended as a speed optimisation
for armv7, and this ifdef intended to prevent it making things worse for
armv6. But it's been a while, perhaps armv7 compilers are better by now,
so maybe we're better off just disabling the #define XXH_FORCE_MEMORY_ACCESS 1.
I don't have any affected hw to test with.
Index: Makefile
===
RCS file: /cvs/ports/sysutils/xxhash/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile23 Jul 2023 04:29:44 - 1.13
+++ Makefile16 Aug 2023 23:56:04 -
@@ -3,6 +3,7 @@ COMMENT = extremely fast non-cryptograph
GH_ACCOUNT = Cyan4973
GH_PROJECT = xxHash
GH_TAGNAME = v0.8.2
+REVISION = 0
PKGNAME = ${DISTNAME:L}
SHARED_LIBS = xxhash 0.3 # 0.8.1
Index: patches/patch-xxhash_h
===
RCS file: patches/patch-xxhash_h
diff -N patches/patch-xxhash_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xxhash_h 16 Aug 2023 23:56:04 -
@@ -0,0 +1,17 @@
+Index: xxhash.h
+--- xxhash.h.orig
xxhash.h
+@@ -1983,8 +1983,11 @@ XXH3_128bits_reset_withSecretandSeed(XXH_NOESCAPE XXH3
+/* prefer __packed__ structures (method 1) for GCC
+ * < ARMv7 with unaligned access (e.g. Raspbian armhf) still uses byte
shifting, so we use memcpy
+ * which for some reason does unaligned loads. */
+-# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 &&
defined(__ARM_FEATURE_UNALIGNED))
+-#define XXH_FORCE_MEMORY_ACCESS 1
++# if defined(__GNUC__)
++#include/* __STRICT_ALIGNMENT */
++#if !defined(__STRICT_ALIGNMENT)
++# define XXH_FORCE_MEMORY_ACCESS 1
++#endif
+ # endif
+ #endif
+
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 16:12:20 Modified files: textproc/py-sphinx: Makefile distinfo textproc/py-sphinx/pkg: PLIST Log message: update to py3-sphinx-7.1.2
New port: novelWriter, a text writer for creating novels
This is a pretty straight-forward, python-based port. It is a bit similar to focuswriter and ghostwriter in its application. I like the chapter/scene tree that allows for rearranging the elements of the work. It has a focus mode (F8) that removes most of the interface to help focus on writing text segment. It supports exporting to a variety of formats, including HTML, Markdown, OpenOffice Text, PDF. ok for import? novelwriter-2.0.7.tgz Description: application/tar-gz
Re: rsync and xxhash are broken on strict alignment architectures
Stuart Henderson: > +-# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 && > defined(__ARM_FEATURE_UNALIGNED)) > ++# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 && > defined(__ARM_FEATURE_UNALIGNED)) && !defined(__sparc64__) This should include and check __STRICT_ALIGNMENT rather than hardcoding architectures. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: update sysutils/cfengine to 3.21.2
On 2023/08/16 18:34, Joseph Benden wrote:
> The included patch brings Cfengine 3 up-to-date with the latest LTS
> release, 3.21.2.
>
> Best regards,
> -Joe
>
Thanks for un-sticking this port :)
I'll include an updated patch below, comments in-line here saying what
changed. note it uses something added by an infrastructure change a
couple of days ago, you need up-to-date base OS (specifically a recent
make binary) and ports/infrastructure files.
> From 44fb146da83e2d1268c6462153a7dd22c9e07b0b Mon Sep 17 00:00:00 2001
> From: Joseph Benden
> Date: Wed, 16 Aug 2023 09:42:10 -0700
> Subject: [PATCH] update to cfengine-3.21.2
>
> Signed-off-by: Joseph Benden
> ---
> sysutils/cfengine/Makefile| 37 +-
> sysutils/cfengine/distinfo| 6 +-
> .../patches/patch-cf-agent_verify_files_c | 17 -
> .../patch-cf-agent_verify_files_utils_c | 11 -
> .../patches/patch-cf-execd_cf-execd_c | 11 -
> .../cfengine/patches/patch-cf-upgrade_log_c | 11 -
> .../patches/patch-libcompat_strchrnul_c | 11 -
> .../cfengine/patches/patch-libpromises-crypto | 40 ++
> .../patches/patch-libpromises_evalfunction_c | 11 -
> .../patch-libpromises_processes_select_c | 11 -
> .../patches/patch-libutils_string_lib_c | 13 -
> sysutils/cfengine/pkg/DESCR-masterfiles | 5 +
> sysutils/cfengine/pkg/PLIST | 28 +-
> sysutils/cfengine/pkg/PLIST-masterfiles | 569 ++
> 14 files changed, 638 insertions(+), 143 deletions(-)
> delete mode 100644 sysutils/cfengine/patches/patch-cf-agent_verify_files_c
> delete mode 100644
> sysutils/cfengine/patches/patch-cf-agent_verify_files_utils_c
> delete mode 100644 sysutils/cfengine/patches/patch-cf-execd_cf-execd_c
> delete mode 100644 sysutils/cfengine/patches/patch-cf-upgrade_log_c
> delete mode 100644 sysutils/cfengine/patches/patch-libcompat_strchrnul_c
> create mode 100644 sysutils/cfengine/patches/patch-libpromises-crypto
> delete mode 100644 sysutils/cfengine/patches/patch-libpromises_evalfunction_c
> delete mode 100644
> sysutils/cfengine/patches/patch-libpromises_processes_select_c
> delete mode 100644 sysutils/cfengine/patches/patch-libutils_string_lib_c
> create mode 100644 sysutils/cfengine/pkg/DESCR-masterfiles
> create mode 100644 sysutils/cfengine/pkg/PLIST-masterfiles
>
> diff --git a/sysutils/cfengine/Makefile b/sysutils/cfengine/Makefile
> index d12d74cdf85..a86977ffb31 100644
> --- a/sysutils/cfengine/Makefile
> +++ b/sysutils/cfengine/Makefile
> @@ -1,16 +1,18 @@
> -BROKEN = pkg_add fails: problem with symlinks
> +COMMENT-main = GNU system administration tool for networks
> +COMMENT-masterfiles =Masterfiles sources for Cfengine
>
> -COMMENT =GNU system administration tool for networks
> -
> -DISTNAME = cfengine-3.7.2
> -REVISION = 5
> -
> -PORTROACH = site:https://github.com/cfengine/core/archive/
> +V = 3.21.2
> +PKGNAME =cfengine-${V}
> +DISTNAME = cfengine-community-${V}
> +REVISION = 0
remove REVISION rather than setting to 0
> +SUPDISTFILES += cfengine-masterfiles-${V}.tar.gz
list cfengine-masterfiles in DISTFILES not SUPDISTFILES so it
gets extracted as part of "make extract". excepting very special
cases (where most of the distfile is totally irrelevant to a port
and it's huge, for example some firmware-packages) we want "make
extract" to unpack the things used to actually build the port.
you can't add to the default DISTFILES with +=, either you need
to list the default filename for the main distfile explicitly,
or we can use a newly added thing in ports to make it simpler,
which is what I went for.
this masterfiles distfile includes autoconf input+output files,
makefiles, etc. it seems the port should be using
cfengine-masterfiles-${V}-1.pkg.tar.gz instead.
>
> SHARED_LIBS += promises 0.0 # 1.0
> CATEGORIES = sysutils
> HOMEPAGE = https://cfengine.com/
>
> +MULTI_PACKAGES = -main -masterfiles
space not tab between -main -masterfiles
> +
> # GPLv3 only
> PERMIT_PACKAGE = Yes
>
> @@ -25,6 +27,7 @@ SUBST_VARS += CFENGINE_BASE CFENGINE_EXAMPLES
> FLAVORS =pgsql mysql
> FLAVOR ?=
>
> +WRKDIST =${WRKDIR}/${PKGNAME}
(not needed with the DISTFILES change I used)
> SEPARATE_BUILD = Yes
> CONFIGURE_STYLE =gnu
> USE_GMAKE = Yes
> @@ -69,20 +72,18 @@ CONFIGURE_ARGS += --without-mysql
>
> # tests not yet working
> NO_TEST =Yes
> -# also note some formatting errors with manpages (e.g. "You can think
> -# of.B cfengine as..." and poor formatting in INFORMATION sections;
> -# these are present with either mandoc or groff.
>
> post-extract:
> - perl -i -pe \
> - 's|^sbin_PROGRAMS.*rpmvercmp||;' \
> - ${WRKDIST}/ext/Makefile.in
> +.for i in configure libpromises/dbm_quick.c ext/Makefile.in
> + perl -i -pe 's|qdbm/depot.h|depot.h|;' \
> + -e
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2023/08/16 14:54:06 Modified files: sysutils/login_duo: Makefile distinfo sysutils/login_duo/pkg: PLIST Log message: Update login_duo to 2.0.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2023/08/16 14:51:35 Modified files: lang/janet : Makefile distinfo Removed files: lang/janet/patches: patch-test_suite-corelib_janet Log message: Update janet to 1.30.0.
Re: rsync and xxhash are broken on strict alignment architectures
> I'm ok with your diff, or perhaps we could do this (then rsync just > needs a bump rather than another change) This works and seems better since it will also help other consumers. ok tb Thanks.
Re: rsync and xxhash are broken on strict alignment architectures
On 2023/08/16 20:15, Theo Buehler wrote:
> I found on one sparc64 box that reposync stopped working and it turned
> out that rsync on sparc64 is busted due to xxhash not dealing correctly
> with unaligned access.
>
> Program terminated with signal SIGBUS, Bus error.
> #0 XXH_read64 (ptr=0xfe7ed9467bbe) at /usr/local/include/xxhash.h:2996
>
> xxhash.h claims XXH_FORCE_MEMORY_ACCESS=0 to be the default, but that
> doesn't seem to be true (anymore?). I haven't tried to find out why.
default eh, what a lie.
#ifndef XXH_FORCE_MEMORY_ACCESS /* can be defined externally, on command line
for example */
/* prefer __packed__ structures (method 1) for GCC
* < ARMv7 with unaligned access (e.g. Raspbian armhf) still uses byte
shifting, so we use memcpy
* which for some reason does unaligned loads. */
# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 &&
defined(__ARM_FEATURE_UNALIGNED))
#define XXH_FORCE_MEMORY_ACCESS 1
# endif
#endif
> rsync built with the diff below that forces the use of memcpy() to
> avoid unaligned access seems to work fine and xxhash passes regress on
> sparc64 (after removing -Wvla from ${WRKSRC}/Makefile).
>
> Maybe we only want to set this conditionally on the architectures that
> need this for performance reasons. I also haven't looked into what
> consumes xxhash.h.
>
> I'd appreciate if you could take it from here.
I'm ok with your diff, or perhaps we could do this (then rsync just
needs a bump rather than another change)
Index: Makefile
===
RCS file: /cvs/ports/sysutils/xxhash/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile23 Jul 2023 04:29:44 - 1.13
+++ Makefile16 Aug 2023 18:37:00 -
@@ -3,6 +3,7 @@ COMMENT = extremely fast non-cryptograph
GH_ACCOUNT = Cyan4973
GH_PROJECT = xxHash
GH_TAGNAME = v0.8.2
+REVISION = 0
PKGNAME = ${DISTNAME:L}
SHARED_LIBS = xxhash 0.3 # 0.8.1
Index: patches/patch-xxhash_h
===
RCS file: patches/patch-xxhash_h
diff -N patches/patch-xxhash_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-xxhash_h 16 Aug 2023 18:37:00 -
@@ -0,0 +1,14 @@
+XXH_FORCE_MEMORY_ACCESS=1 results in unaligned access on sparc64
+
+Index: xxhash.h
+--- xxhash.h.orig
xxhash.h
+@@ -1983,7 +1983,7 @@ XXH3_128bits_reset_withSecretandSeed(XXH_NOESCAPE XXH3
+/* prefer __packed__ structures (method 1) for GCC
+ * < ARMv7 with unaligned access (e.g. Raspbian armhf) still uses byte
shifting, so we use memcpy
+ * which for some reason does unaligned loads. */
+-# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 &&
defined(__ARM_FEATURE_UNALIGNED))
++# if defined(__GNUC__) && !(defined(__ARM_ARCH) && __ARM_ARCH < 7 &&
defined(__ARM_FEATURE_UNALIGNED)) && !defined(__sparc64__)
+ #define XXH_FORCE_MEMORY_ACCESS 1
+ # endif
+ #endif
WIP: Tor Browser 12.5.2
Hi,
Below is a WIP diff for Tor Browser 12.5.2. Upstream removed some code
that we rely on for setting the data directory for the browser
(~/TorBrowser-Data/Browser) and the new default doesn't work very well
for us. This is why I haven't been able to update Tor Browser to the
12.5 series in a timely manner.
It took me a long time to figure out how to make Tor Browser look in
the desired location for the Firefox profile; with two new patches I
finally was able to do so. The result (which I still need to clean up a
bit) can be found below.
Unfortunately, after fixing that, a new problem appeared. Clicking
"Connect" to connect to the Tor network doesn't do much. So probably
there's some problem related to the Tor Launcher.
I'm about to be offline for 1.5 weeks so I'm sending this to the
mailing list on the off chance someone wants to have a look at this
before I can continue to work on it again.
Help or feedback is welcome.
Caspar
Index: Makefile.inc
===
RCS file: /cvs/ports/www/tor-browser/Makefile.inc,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.inc
--- Makefile.inc9 Jun 2023 08:57:20 - 1.69
+++ Makefile.inc16 Aug 2023 18:32:25 -
@@ -3,7 +3,7 @@ HOMEPAGE ?= https://www.torproject.org
PERMIT_PACKAGE ?= Yes
CATEGORIES = www
BROWSER_NAME = tor-browser
-TB_VERSION = 12.0.7
+TB_VERSION = 12.5.2
TB_PREFIX =tb
# keep meta/tor-browser in sync
Index: browser/Makefile
===
RCS file: /cvs/ports/www/tor-browser/browser/Makefile,v
retrieving revision 1.114
diff -u -p -r1.114 Makefile
--- browser/Makefile1 Aug 2023 14:00:33 - 1.114
+++ browser/Makefile16 Aug 2023 18:32:25 -
@@ -5,14 +5,13 @@
COMMENT = modified version of Firefox ESR for browsing over Tor
MOZILLA_VERSION = ${TB_VERSION}
-REVISION = 1
MOZILLA_PROJECT = ${BROWSER_NAME}
MOZILLA_CODENAME = browser
EXTRACT_SUFX = .tar.xz
PKGNAME = ${TB_PREFIX}-browser-${TB_VERSION:S/a/alpha/}
-DISTNAME = src-firefox-tor-browser-102.12.0esr-12.0-1-build2
+DISTNAME = src-firefox-tor-browser-102.14.0esr-12.5-1-build2
FIX_EXTRACT_PERMISSIONS= Yes
DISTFILES += ${DISTNAME}.tar.xz \
@@ -67,8 +66,7 @@ CONFIGURE_ENV += LDFLAGS=-Wl,--threads=$
# app-name etc. for tor-browser
CONFIGURE_ARGS += --with-app-name=${BROWSER_NAME} \
- --with-tor-browser-version=${TB_VERSION}\
- --enable-tor-browser-data-outside-app-dir
+ --with-base-browser-version=${TB_VERSION}
# for nss build system
MAKE_ENV +=BUILD_OPT=1 \
@@ -149,10 +147,15 @@ post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/applications/
${SUBST_DATA} ${FILESDIR}/${BROWSER_NAME}.desktop \
${PREFIX}/share/applications/${BROWSER_NAME}.desktop
- # install icon for desktop file
- ${INSTALL_DATA_DIR} ${PREFIX}/share/pixmaps/
- ${INSTALL_DATA}
${BROWSER_DIR}/browser/chrome/icons/default/default128.png \
- ${PREFIX}/share/pixmaps/${BROWSER_NAME}.png
+ # install icons for desktop file
+.for s in 16 22 24 32 48 64 128 256
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/${s}x${s}/apps
+ ${INSTALL_DATA} ${WRKSRC}/browser/branding/tb-release/default${s}.png \
+ ${PREFIX}/share/icons/hicolor/${s}x${s}/apps/${BROWSER_NAME}.png
+.endfor
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/scalable/apps
+ ${INSTALL_DATA} ${WRKSRC}/browser/branding/tb-release/firefox.svg
${PREFIX}/share/icons/hicolor/scalable/apps/${BROWSER_NAME}.svg
+
# link default48.png to default.png to be used by default
# by non-icccm compliant wm
ln -f ${BROWSER_DIR}/browser/chrome/icons/default/default{48,}.png
@@ -165,7 +168,7 @@ post-install:
# install fonts.conf and fonts
${INSTALL_DATA_DIR} ${BROWSER_DIR}/browser/fontconfig
${SUBST_DATA} \
-
${WRKSRC}/tor-browser-linux64/Browser/TorBrowser/Data/fontconfig/fonts.conf \
+ ${WRKSRC}/tor-browser-linux64/Browser/fontconfig/fonts.conf \
${BROWSER_DIR}/browser/fontconfig/fonts.conf
${INSTALL_DATA_DIR} ${BROWSER_DIR}/browser/fonts
cp ${WRKSRC}/tor-browser-linux64/Browser/fonts/* \
Index: browser/distinfo
===
RCS file: /cvs/ports/www/tor-browser/browser/distinfo,v
retrieving revision 1.67
diff -u -p -r1.67 distinfo
--- browser/distinfo9 Jun 2023 08:57:20 - 1.67
+++ browser/distinfo16 Aug 2023 18:32:25 -
@@ -1,6 +1,6 @@
-SHA256 (mozilla/src-firefox-tor-browser-102.12.0esr-12.0-1-build2.tar.xz) =
iZz/n1VwQTSz+2GSofhMXh+C6OHASInY8aPdiP8gYL4=
update sysutils/cfengine to 3.21.2
The included patch brings Cfengine 3 up-to-date with the latest LTS
release, 3.21.2.
Best regards,
-Joe
From 44fb146da83e2d1268c6462153a7dd22c9e07b0b Mon Sep 17 00:00:00 2001
From: Joseph Benden
Date: Wed, 16 Aug 2023 09:42:10 -0700
Subject: [PATCH] update to cfengine-3.21.2
Signed-off-by: Joseph Benden
---
sysutils/cfengine/Makefile| 37 +-
sysutils/cfengine/distinfo| 6 +-
.../patches/patch-cf-agent_verify_files_c | 17 -
.../patch-cf-agent_verify_files_utils_c | 11 -
.../patches/patch-cf-execd_cf-execd_c | 11 -
.../cfengine/patches/patch-cf-upgrade_log_c | 11 -
.../patches/patch-libcompat_strchrnul_c | 11 -
.../cfengine/patches/patch-libpromises-crypto | 40 ++
.../patches/patch-libpromises_evalfunction_c | 11 -
.../patch-libpromises_processes_select_c | 11 -
.../patches/patch-libutils_string_lib_c | 13 -
sysutils/cfengine/pkg/DESCR-masterfiles | 5 +
sysutils/cfengine/pkg/PLIST | 28 +-
sysutils/cfengine/pkg/PLIST-masterfiles | 569 ++
14 files changed, 638 insertions(+), 143 deletions(-)
delete mode 100644 sysutils/cfengine/patches/patch-cf-agent_verify_files_c
delete mode 100644 sysutils/cfengine/patches/patch-cf-agent_verify_files_utils_c
delete mode 100644 sysutils/cfengine/patches/patch-cf-execd_cf-execd_c
delete mode 100644 sysutils/cfengine/patches/patch-cf-upgrade_log_c
delete mode 100644 sysutils/cfengine/patches/patch-libcompat_strchrnul_c
create mode 100644 sysutils/cfengine/patches/patch-libpromises-crypto
delete mode 100644 sysutils/cfengine/patches/patch-libpromises_evalfunction_c
delete mode 100644 sysutils/cfengine/patches/patch-libpromises_processes_select_c
delete mode 100644 sysutils/cfengine/patches/patch-libutils_string_lib_c
create mode 100644 sysutils/cfengine/pkg/DESCR-masterfiles
create mode 100644 sysutils/cfengine/pkg/PLIST-masterfiles
diff --git a/sysutils/cfengine/Makefile b/sysutils/cfengine/Makefile
index d12d74cdf85..a86977ffb31 100644
--- a/sysutils/cfengine/Makefile
+++ b/sysutils/cfengine/Makefile
@@ -1,16 +1,18 @@
-BROKEN = pkg_add fails: problem with symlinks
+COMMENT-main = GNU system administration tool for networks
+COMMENT-masterfiles = Masterfiles sources for Cfengine
-COMMENT = GNU system administration tool for networks
-
-DISTNAME = cfengine-3.7.2
-REVISION = 5
-
-PORTROACH = site:https://github.com/cfengine/core/archive/
+V = 3.21.2
+PKGNAME = cfengine-${V}
+DISTNAME = cfengine-community-${V}
+REVISION = 0
+SUPDISTFILES += cfengine-masterfiles-${V}.tar.gz
SHARED_LIBS += promises 0.0 # 1.0
CATEGORIES = sysutils
HOMEPAGE = https://cfengine.com/
+MULTI_PACKAGES = -main -masterfiles
+
# GPLv3 only
PERMIT_PACKAGE = Yes
@@ -25,6 +27,7 @@ SUBST_VARS += CFENGINE_BASE CFENGINE_EXAMPLES
FLAVORS = pgsql mysql
FLAVOR ?=
+WRKDIST = ${WRKDIR}/${PKGNAME}
SEPARATE_BUILD = Yes
CONFIGURE_STYLE = gnu
USE_GMAKE = Yes
@@ -69,20 +72,18 @@ CONFIGURE_ARGS += --without-mysql
# tests not yet working
NO_TEST = Yes
-# also note some formatting errors with manpages (e.g. "You can think
-# of.B cfengine as..." and poor formatting in INFORMATION sections;
-# these are present with either mandoc or groff.
post-extract:
- perl -i -pe \
- 's|^sbin_PROGRAMS.*rpmvercmp||;' \
- ${WRKDIST}/ext/Makefile.in
+.for i in configure libpromises/dbm_quick.c ext/Makefile.in
+ perl -i -pe 's|qdbm/depot.h|depot.h|;' \
+ -e 's|^sbin_PROGRAMS.*rpmvercmp||;' \
+ ${WRKDIST}/$i
+.endfor
post-install:
- ${INSTALL_PROGRAM_DIR} ${WRKINST}${CFENGINE_BASE}/bin
-.for i in cf-agent cf-execd cf-key cf-monitord cf-promises cf-upgrade \
- cf-runagent cf-serverd
- ln -s ${TRUEPREFIX}/bin/$i ${WRKINST}${CFENGINE_BASE}/bin/
-.endfor
+ ${INSTALL_PROGRAM_DIR} "${WRKINST}${CFENGINE_BASE}/masterfiles"
+ tar -x -z -f "${FULLDISTDIR}/cfengine-masterfiles-${V}.tar.gz" \
+ -C "${WRKINST}${CFENGINE_BASE}/masterfiles" \
+ -s "#cfengine-masterfiles-${V}#.#"
.include
diff --git a/sysutils/cfengine/distinfo b/sysutils/cfengine/distinfo
index 147ffb8be00..f035fa0522c 100644
--- a/sysutils/cfengine/distinfo
+++ b/sysutils/cfengine/distinfo
@@ -1,2 +1,4 @@
-SHA256 (cfengine-3.7.2.tar.gz) = qtmuJghkrL3yqkQcIINlRg+ajsqlNhi720ZeN670reU=
-SIZE (cfengine-3.7.2.tar.gz) = 2114764
+SHA256 (cfengine-community-3.21.2.tar.gz) = 4/czQz/5rYagFRO3efZG2iI6/thWjo3m6JxOWqjGslY=
+SHA256 (cfengine-masterfiles-3.21.2.tar.gz) = b7qhLWAtuKlMiaak/sUvHim/JwU62KNQNsbxHmGCexw=
+SIZE (cfengine-community-3.21.2.tar.gz) = 3344237
+SIZE (cfengine-masterfiles-3.21.2.tar.gz) = 523289
diff --git a/sysutils/cfengine/patches/patch-cf-agent_verify_files_c b/sysutils/cfengine/patches/patch-cf-agent_verify_files_c
deleted file mode 100644
index f136d132140..000
--- a/sysutils/cfengine/patches/patch-cf-agent_verify_files_c
+++ /dev/null
@@ -1,17 +0,0 @@
cf-agent/verify_files.c.orig Wed Jan 20 00:29:13 2016
-+++ cf-agent/verify_files.c Wed
rsync and xxhash are broken on strict alignment architectures
I found on one sparc64 box that reposync stopped working and it turned
out that rsync on sparc64 is busted due to xxhash not dealing correctly
with unaligned access.
Program terminated with signal SIGBUS, Bus error.
#0 XXH_read64 (ptr=0xfe7ed9467bbe) at /usr/local/include/xxhash.h:2996
xxhash.h claims XXH_FORCE_MEMORY_ACCESS=0 to be the default, but that
doesn't seem to be true (anymore?). I haven't tried to find out why.
rsync built with the diff below that forces the use of memcpy() to
avoid unaligned access seems to work fine and xxhash passes regress on
sparc64 (after removing -Wvla from ${WRKSRC}/Makefile).
Maybe we only want to set this conditionally on the architectures that
need this for performance reasons. I also haven't looked into what
consumes xxhash.h.
I'd appreciate if you could take it from here.
Index: net/rsync/Makefile
===
RCS file: /cvs/ports/net/rsync/Makefile,v
retrieving revision 1.98
diff -u -p -r1.98 Makefile
--- net/rsync/Makefile 6 Jun 2023 14:12:07 - 1.98
+++ net/rsync/Makefile 16 Aug 2023 18:09:59 -
@@ -1,7 +1,7 @@
COMMENT = mirroring/synchronization over low bandwidth links
DISTNAME = rsync-3.2.7
-REVISION = 0
+REVISION = 1
CATEGORIES = net
HOMEPAGE = https://rsync.samba.org/
@@ -34,7 +34,7 @@ CONFIGURE_ARGS =--disable-lz4 \
--with-rsh=/usr/bin/ssh \
--with-nobody-user=_rsync \
--with-nobody-group=_rsync
-CONFIGURE_ENV +=CPPFLAGS="-I${LOCALBASE}/include -DXXH_INLINE_ALL=1" \
+CONFIGURE_ENV +=CPPFLAGS="-I${LOCALBASE}/include -DXXH_INLINE_ALL=1
-DXXH_FORCE_MEMORY_ACCESS=0" \
ac_cv_search_XXH64_createState=""
.include
Index: sysutils/xxhash/Makefile
===
RCS file: /cvs/ports/sysutils/xxhash/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- sysutils/xxhash/Makefile23 Jul 2023 04:29:44 - 1.13
+++ sysutils/xxhash/Makefile16 Aug 2023 17:54:36 -
@@ -4,6 +4,7 @@ GH_ACCOUNT =Cyan4973
GH_PROJECT = xxHash
GH_TAGNAME = v0.8.2
PKGNAME = ${DISTNAME:L}
+REVISION = 0
SHARED_LIBS = xxhash 0.3 # 0.8.1
@@ -23,6 +24,7 @@ MAKE_FLAGS = CC="${CC}" \
SHARED_EXT_VER="so.${LIBxxhash_VERSION}" \
V=1
FAKE_FLAGS = PREFIX=${PREFIX}
+CFLAGS += -DXXH_FORCE_MEMORY_ACCESS=0
USE_GMAKE =Yes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: vol...@cvs.openbsd.org 2023/08/16 10:58:05 Modified files: mail/aerc : Makefile Added files: mail/aerc/patches: patch-filters_colorize_c Log message: mail/aerc: Disable the insertion of osc8 control codes in the colorize filter. It's unsupported on OpenBSD's implementation of less(1) and leads to broken results with the default configuration. ok op@, Thim Cederlund (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2023/08/16 10:57:12 Modified files: sysutils/chezmoi: Makefile distinfo modules.inc Log message: update sysutils/chezmoi to 2.37.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2023/08/16 09:44:03 Modified files: lang/algol68g : Makefile distinfo Log message: Update to algol68g-3.3.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 09:43:32 Modified files: x11/gnome/mutter: Makefile distinfo Removed files: x11/gnome/mutter/patches: patch-src_core_window_c Log message: Merge fix for proper focus management, from upstream.
Re: pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 8/16/2023 10:55 AM, Stuart Henderson wrote:
> On 2023/08/16 14:06, Brian Callahan wrote:
>> On 8/16/2023 9:43 AM, Stuart Henderson wrote:
>>>
>>> also, the comment about why it's using a wrong version of autoconf
>>> should have the version bumped to 2.71 (though if there's a problem
>>> with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..)
>>
>> You may want to try using autoconf-2.71. The scripts were last reconf'd
>> with 2.71, and I was the one who last reconf'd them, on an OpenBSD
>> machine. Worked fine here.
>
> It fails in a ports build with 2.71, and it fails with the bundled
> configure script.
>
> Seems that the problem is that ac_cv_prog_lex_root ("checking for
> lex output file root... lex.yy" is set by ports infrastructure in
> config.cache but that the subsequent "checking for lex library"
> depends on the file created in the ac_cv_prog_lex_root check.
>
Ah, I see the issue. Admittedly, I don't build pcc within the ports
tree, so with lex.yy not cached, things work fine.
~Brian
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 09:04:38 Modified files: net/dino : Makefile Added files: net/dino/patches: patch-main_src_ui_util_helper_vala Log message: Unbreak build with vala >=0.56.11.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 09:04:19 Modified files: lang/vala : Makefile Added files: lang/vala/patches: patch-vala_valamethodcall_vala Log message: Only transform default initializers of parameters; from upstream First step in fixing net/dino.
Re: pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 2023/08/16 14:06, Brian Callahan wrote:
> On 8/16/2023 9:43 AM, Stuart Henderson wrote:
> >
> > also, the comment about why it's using a wrong version of autoconf
> > should have the version bumped to 2.71 (though if there's a problem
> > with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..)
>
> You may want to try using autoconf-2.71. The scripts were last reconf'd
> with 2.71, and I was the one who last reconf'd them, on an OpenBSD
> machine. Worked fine here.
It fails in a ports build with 2.71, and it fails with the bundled
configure script.
Seems that the problem is that ac_cv_prog_lex_root ("checking for
lex output file root... lex.yy" is set by ports infrastructure in
config.cache but that the subsequent "checking for lex library"
depends on the file created in the ac_cv_prog_lex_root check.
[...]
checking for bison... /usr/bin/yacc
checking for flex... (cached) flex
checking for lex output file root... (cached) lex.yy
checking for lex library... cat: lex.yy.c: No such file or directory
cat: lex.yy.c: No such file or directory
cat: lex.yy.c: No such file or directory
not found
configure: WARNING: required lex library not found; giving up on flex
checking for library containing yywrap... -lfl
[...]
This issue is fixed by one or other of the two infrastructure diffs
below. I prefer the first; the 'none needed' setting feels a bit magic.
If anyone is able to add it to a bulk I'd appreciate it (I don't expect
a problem, but since the file is used for every CONFIGURE_STYLE=gnu or
autoconf in the tree, it feels safer to test first).
Index: config.site
===
RCS file: /cvs/ports/infrastructure/db/config.site,v
retrieving revision 1.31
diff -u -p -r1.31 config.site
--- config.site 31 Oct 2022 21:32:43 - 1.31
+++ config.site 16 Aug 2023 14:44:12 -
@@ -886,7 +886,6 @@ ac_cv_prog_egrep=${ac_cv_prog_egrep='gre
ac_cv_prog_f77_g=${ac_cv_prog_f77_g=yes}
ac_cv_prog_gcc=${ac_cv_prog_gcc=yes}
ac_cv_prog_have_hp2ps=${ac_cv_prog_have_hp2ps=1}
-ac_cv_prog_lex_root=${ac_cv_prog_lex_root=lex.yy}
ac_cv_prog_lex_yytext_pointer=${ac_cv_prog_lex_yytext_pointer=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
ac_cv_sizeof_char=${ac_cv_sizeof_char=1}
Index: config.site
===
RCS file: /cvs/ports/infrastructure/db/config.site,v
retrieving revision 1.31
diff -u -p -r1.31 config.site
--- config.site 31 Oct 2022 21:32:43 - 1.31
+++ config.site 16 Aug 2023 14:51:15 -
@@ -887,6 +887,7 @@ ac_cv_prog_f77_g=${ac_cv_prog_f77_g=yes}
ac_cv_prog_gcc=${ac_cv_prog_gcc=yes}
ac_cv_prog_have_hp2ps=${ac_cv_prog_have_hp2ps=1}
ac_cv_prog_lex_root=${ac_cv_prog_lex_root=lex.yy}
+ac_cv_lib_lex='none needed'
ac_cv_prog_lex_yytext_pointer=${ac_cv_prog_lex_yytext_pointer=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
ac_cv_sizeof_char=${ac_cv_sizeof_char=1}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 08:49:03 Modified files: net/net-snmp : Makefile distinfo net/net-snmp/patches: patch-Makefile_rules patch-Makefile_top net/net-snmp/pkg: PLIST-main Removed files: net/net-snmp/patches: patch-agent_mibgroup_mibII_tcp_c patch-include_net-snmp_system_openbsd7_h Log message: update to net-snmp-5.9.4
Re: pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 8/16/2023 9:43 AM, Stuart Henderson wrote: > On 2023/08/12 20:43, Daniel Dickman wrote: >> CVSROOT: /cvs >> Module name: ports >> Changes by: dan...@cvs.openbsd.org 2023/08/12 20:43:15 >> >> Modified files: >> lang/pcc : Makefile.inc >> lang/pcc/pcc : distinfo >> lang/pcc/pcc/patches: patch-arch_powerpc_local_c >>patch-cc_cc_cc_c >> lang/pcc/pcc-libs: Makefile distinfo >> >> Log message: >> update to pcc 20230813 > > i386 fails: > > cc -O2 -pipe -Wall -Wmissing-prototypes -Wstrict-prototypes -Wshadow > -Wsign-compare -DGCC_COMPAT -DPCC_DEBUG -D_ISOC > 99_SOURCE -Dos_openbsd -Dmach_i386 -I. -I. -I../.. -I../../mip > -I../../arch/i386 -I../../os/openbsd -I../../common > -c -o code.o ../../arch/i386/code.c > ../../arch/i386/code.c:452:22: error: no member named 'ss' in 'struct attr' > if (stcall && (ap = strattr(p->n_left->n_ap)) && > ^~~~ > ./pass1.h:623:26: note: expanded from macro 'strattr' > #define strattr(x) ((x)->ss) > ~~~ ^ > 1 error generated. > > > also, the comment about why it's using a wrong version of autoconf > should have the version bumped to 2.71 (though if there's a problem > with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..) > You may want to try using autoconf-2.71. The scripts were last reconf'd with 2.71, and I was the one who last reconf'd them, on an OpenBSD machine. Worked fine here. ~Brian
pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 2023/08/12 20:43, Daniel Dickman wrote: > CVSROOT: /cvs > Module name: ports > Changes by: dan...@cvs.openbsd.org 2023/08/12 20:43:15 > > Modified files: > lang/pcc : Makefile.inc > lang/pcc/pcc : distinfo > lang/pcc/pcc/patches: patch-arch_powerpc_local_c > patch-cc_cc_cc_c > lang/pcc/pcc-libs: Makefile distinfo > > Log message: > update to pcc 20230813 i386 fails: cc -O2 -pipe -Wall -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wsign-compare -DGCC_COMPAT -DPCC_DEBUG -D_ISOC 99_SOURCE -Dos_openbsd -Dmach_i386 -I. -I. -I../.. -I../../mip -I../../arch/i386 -I../../os/openbsd -I../../common -c -o code.o ../../arch/i386/code.c ../../arch/i386/code.c:452:22: error: no member named 'ss' in 'struct attr' if (stcall && (ap = strattr(p->n_left->n_ap)) && ^~~~ ./pass1.h:623:26: note: expanded from macro 'strattr' #define strattr(x) ((x)->ss) ~~~ ^ 1 error generated. also, the comment about why it's using a wrong version of autoconf should have the version bumped to 2.71 (though if there's a problem with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 07:24:37 Modified files: net/isc-bind : Makefile distinfo Log message: update to isc-bind-9.18.18
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 07:24:39 Modified files: databases/mongodb/44: Makefile distinfo Log message: update to mongodb-4.4.24
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 06:43:54 Modified files: devel/py-typeguard: Makefile distinfo devel/py-typeguard/pkg: PLIST Log message: update to py3-typeguard-4.1.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2023/08/16 06:07:02 Modified files: devel/py-cfgv : Makefile distinfo Log message: Update py-cfgv 3.3.1 -> 3.4.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 06:04:31 Modified files: sysutils/sshpass: Makefile distinfo Log message: update to sshpass-1.10
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 05:39:11 Modified files: math/calc : Makefile distinfo Log message: update to calc-2.14.3.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: i...@cvs.openbsd.org2023/08/16 05:34:11 Modified files: textproc/asciidoctor: Makefile Log message: Reset REVISION
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: i...@cvs.openbsd.org2023/08/16 05:33:04 Modified files: textproc/asciidoctor: Makefile distinfo Log message: Minor bump of AsciiDoctor 2.0.17->2.0.20
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 05:24:36 Modified files: lang/lucee : Makefile distinfo Log message: update to lucee-5.4.3.2 https://dev.lucee.org/t/lucee-critical-security-alert-august-15th-2023-cve-2023-38693/12893
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/08/16 05:23:40 Modified files: lang/lucee : Tag: OPENBSD_7_3 Makefile distinfo Log message: update to lucee-5.3.12.1 https://dev.lucee.org/t/lucee-critical-security-alert-august-15th-2023-cve-2023-38693/12893
fix for smtp-vilter link stage on clang archs
Clang does not have -export-dynamic. Instead dlopen(3) teaches us to use
the -rdynamic option to cc(1).
The attached patch is needed for smtp-vilter to be able to dlopen(3) the
clamd and spamd backends on clang archs too.
/Niklas
diff --git a/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
b/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
index 7d6d6147b7c..30dab7adb89 100644
--- a/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
+++ b/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
@@ -1,7 +1,13 @@
Index: bin/smtp-vilter/Makefile
--- bin/smtp-vilter/Makefile.orig
+++ bin/smtp-vilter/Makefile
-@@ -12,7 +12,7 @@ YFLAGS= -d -p vilter
+@@ -7,12 +7,12 @@ SRCS=smtp-vilter.c engine.c imsg.c buffer.c
pftable.
+ CFLAGS+= -pthread -Wall -I{.CURDIR} -I${.CURDIR}/../../include \
+ -I/usr/src/gnu/usr.sbin/sendmail/include
+
+-LDADD+= -export-dynamic -lmilter -lpthread -L/usr/local/lib -lm
++LDADD+= -rdynamic -lmilter -lpthread -L/usr/local/lib -lm
+ YFLAGS= -d -p vilter
LFLAGS= -Pvilter -olex.yy.c
LINTFLAGS+= -u
Re: rdiff-backup dependency issue
On 2023/08/16 09:39, Klemens Nanni wrote: > On Mon, Aug 14, 2023 at 07:36:06AM +, Klemens Nanni wrote: > > No response from maintainer so far. > > Joshua reported success for the update, I don't use it, but am inclined > > to keep such a port up-to-date. > > > > Feedback? OK? > > None, I've just committed the update. It would certainly be helpful for other developers if people would drop maintainer if they're not going to be able to put much time into maintaining a port. At least then versions will show in the ports@ list on portroach and be easier for others to notice when they're outdated.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/08/16 04:44:56 Modified files: security/keepassxc: Makefile distinfo Log message: Update keepassxc to 2.7.6
Re: rdiff-backup dependency issue
On Mon, Aug 14, 2023 at 07:36:06AM +, Klemens Nanni wrote: > No response from maintainer so far. > Joshua reported success for the update, I don't use it, but am inclined > to keep such a port up-to-date. > > Feedback? OK? None, I've just committed the update.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/08/16 03:37:50 Modified files: sysutils/rdiff-backup: Makefile distinfo sysutils/rdiff-backup/patches: patch-setup_py sysutils/rdiff-backup/pkg: DESCR PLIST Log message: update to rdiff-backup 2.2.5 (maintainer timeout); tested by Joshua Megerman also sync COMMENT and DESCR with text from HOMEPAGE.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2023/08/16 03:13:48 Modified files: sysutils/ansible: Makefile distinfo sysutils/ansible/pkg: PLIST Log message: Update ansible 8.2.0 -> 8.3.0 Changelog: https://github.com/ansible-community/ansible-build-data/blob/main/8/CHANGELOG-v8.rst#v8-3-0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2023/08/16 03:10:49 Modified files: sysutils/ansible-core: Makefile distinfo sysutils/ansible-core/pkg: PLIST Log message: Update ansible-core 2.15.2 -> 2.15.3 Changelog: https://github.com/ansible/ansible/blob/stable-2.15/changelogs/CHANGELOG-v2.15.rst#v2-15-3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:29:02 Modified files: sysutils/terragrunt: Makefile distinfo Log message: Update to terragrunt-0.50.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:26:57 Modified files: net/coredns: Makefile distinfo modules.inc Log message: Update to coredns-1.11.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:17:08 Modified files: sysutils/google-cloud-sdk: Makefile distinfo sysutils/google-cloud-sdk/pkg: PLIST Log message: Update to google-cloud-sdk-443.0.0.
Re: [Update] fonts/juliamono
On Tue, Aug 15, 2023 at 08:17:31PM +0100, Laurence Tratt wrote: > A simple update to fonts/juliamono: tested working fine (though, as with > any font update, it will tend to mess up running applications, which > then need to be restarted). > > > Laurie commited. thanks. > > > diff --git fonts/juliamono/Makefile fonts/juliamono/Makefile > index 500dcc97953..ae484ee76db 100644 > --- fonts/juliamono/Makefile > +++ fonts/juliamono/Makefile > @@ -1,6 +1,6 @@ > COMMENT =typeface carefully crafted & designed for computer screens > > -V = 0.048 > +V = 0.050 > DISTNAME = JuliaMono > PKGNAME =juliamono-$V > > diff --git fonts/juliamono/distinfo fonts/juliamono/distinfo > index 43f857f43fc..4f6167524e4 100644 > --- fonts/juliamono/distinfo > +++ fonts/juliamono/distinfo > @@ -1,2 +1,2 @@ > -SHA256 (JuliaMono-0.048.tar.gz) = > J804RqJjpvSx00G0PRjN9wYIvQnsAXWUsZaJGWXdJ1M= > -SIZE (JuliaMono-0.048.tar.gz) = 31773698 > +SHA256 (JuliaMono-0.050.tar.gz) = > 5EZQVkVBAeSjWFgWtOGG1wmXAUAf2qX71Wf6/SUk6qM= > +SIZE (JuliaMono-0.050.tar.gz) = 32756039 > -- Sebastien Marie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2023/08/16 01:13:20 Modified files: fonts/juliamono: Makefile distinfo Log message: update fonts/juliamono to 0.050 from maintainer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:05:07 Modified files: sysutils/awscli: Makefile distinfo sysutils/awscli/pkg: PLIST Log message: Update to awscli-1.29.27.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:04:47 Modified files: net/py-s3transfer: Makefile distinfo Log message: Update to py3-s3transfer-0.6.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:04:15 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.28.27.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 01:03:17 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.31.27.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/08/16 00:59:57 Modified files: net/dino : Makefile Log message: Temporarily mark BROKEN until the regression is newer vala is fixed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2023/08/16 00:30:12 Modified files: mail/gmime30 : Makefile mail/gmime30/patches: patch-tests_test-mime_c Added files: mail/gmime30/patches: patch-gmime_gmime-utils_c Log message: Fix rfc2047 token decoding logic for base64 encodings https://github.com/djcb/mu/issues/2429 OK aja
Re: [fix] mail/gmime: Fix rfc2047 token decoding logic for base64 encodings
Ok
—
Antoine
> On 16 Aug 2023, at 07:57, Stefan Hagen wrote:
>
> Stuart Henderson wrote (2023-08-14 18:04 CEST):
>>> On 2023/08/14 10:40, Antoine Jacoutot wrote:
>>> On Mon, Aug 14, 2023 at 08:44:25AM +0200, Stefan Hagen wrote:
Hi,
there's a bug in gmime, which is affecting mail/mu. It doesn't look like
there will be a new gmime release anytime soon. Can we cherry-pick this
fix?
Maintainer on CC.
>>>
>>> I am OK with this but could you use a regular patch instead of fetching from
>>> github?
>>
>> +1 million
>>
>
> Sure, here's the same as a regular patch.
>
>
> Index: mail/gmime30/Makefile
> ===
> RCS file: /cvs/ports/mail/gmime30/Makefile,v
> retrieving revision 1.23
> diff -u -p -u -p -r1.23 Makefile
> --- mail/gmime30/Makefile5 Nov 2022 17:06:28 -1.23
> +++ mail/gmime30/Makefile16 Aug 2023 05:53:40 -
> @@ -4,7 +4,7 @@ GH_ACCOUNT=jstedfast
> GH_PROJECT=gmime
> GH_TAGNAME=3.2.13
> PKGNAME=gmime30-${GH_TAGNAME}
> -REVISION=0
> +REVISION=1
>
> SHARED_LIBS += gmime-3.02.2 # 213.0
>
> Index: mail/gmime30/patches/patch-gmime_gmime-utils_c
> ===
> RCS file: mail/gmime30/patches/patch-gmime_gmime-utils_c
> diff -N mail/gmime30/patches/patch-gmime_gmime-utils_c
> --- /dev/null1 Jan 1970 00:00:00 -
> +++ mail/gmime30/patches/patch-gmime_gmime-utils_c16 Aug 2023 05:53:40
> -
> @@ -0,0 +1,26 @@
> +Fix rfc2047 token decoding logic for base64 encodings
> +Bug report: https://github.com/djcb/mu/issues/2429
> +
> +Index: gmime/gmime-utils.c
> +--- gmime/gmime-utils.c.orig
> gmime/gmime-utils.c
> +@@ -1789,10 +1789,16 @@ rfc2047_token_decode (rfc2047_token *token, unsigned
> c
> +const unsigned char *inbuf = (const unsigned char *) token->text;
> +size_t len = token->length;
> +
> +-if (token->encoding == 'B')
> ++if (token->encoding == 'B') {
> ++/* Note: A state of -1 means that a previous rfc2047 encoded-word
> token ended with an '=' (aka 'eof'),
> ++ * so we need to reset the state. */
> ++if (*state == -1)
> ++*state = 0;
> ++
> +return g_mime_encoding_base64_decode_step (inbuf, len, outbuf,
> state, save);
> +-else
> +-return quoted_decode (inbuf, len, outbuf, state, save);
> ++}
> ++
> ++return quoted_decode (inbuf, len, outbuf, state, save);
> + }
> +
> + static char *
> Index: mail/gmime30/patches/patch-tests_test-mime_c
> ===
> RCS file: /cvs/ports/mail/gmime30/patches/patch-tests_test-mime_c,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 patch-tests_test-mime_c
> --- mail/gmime30/patches/patch-tests_test-mime_c16 Apr 2022 07:34:04
> -1.3
> +++ mail/gmime30/patches/patch-tests_test-mime_c16 Aug 2023 05:53:40 -
> @@ -1,4 +1,4 @@
> -64bit time_t
> +64bit time_t + Test for rfc2047 token decoding logic for base64 encodings
>
> Index: tests/test-mime.c
> --- tests/test-mime.c.orig
> @@ -12,3 +12,13 @@ Index: tests/test-mime.c
>
> if (tz_offset != dates[i].tzone)
> throw (exception_new ("timezones do not match"));
> +@@ -408,6 +408,9 @@ static struct {
> + "blah:\tI am broken",
> + "blah:\tI am broken" },
> + #endif
> ++{ "=?UTF-8?B?SGVsbG8=?= =?UTF-8?B?IHdvcmxk?=",
> ++ "Hello world",
> ++ "Hello world" },
> +{ "=?iso-8859-1?Q?Copy_of_Rapport_fra_Norges_R=E5fisklag=2Edoc?=",
> + "Copy of Rapport fra Norges R\xc3\xa5" "fisklag.doc",
> + "Copy of Rapport fra Norges =?iso-8859-1?q?R=E5fisklag=2Edoc?=" },
