Re: [UPDATE] lang/node 18.12.1
> > I don't care deeply if OpenSSL 3 is used for this, I just wanted to make > > sure the switch wasn't made blindly since newer is better (which in this > > case it probably isn't). > > It really wasn't - I just intend to stick as closely to upstream's choices > as possible without having to get the bundled OpenSSL dependency to build > and work. Thanks for the explanations. That's more than good enough for me. The patch doesn't build for me since it tries to fetch zwitch from the net. That's on aarch64 in case it matters: c++ -o /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/node -pthread -rdynamic -Wl,--whole-archive /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/libnode.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a -Wl,--no-whole-archive -Wl,-z,wxneeded -Wl,-rpath,/usr/local/lib/eopenssl30 -Wl,--start-group /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/node/src/node_main.o /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/node/gen/node_snapshot.o /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/histogram/libhistogram.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/uvwasi/libuvwasi.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/libnode.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_libplatform.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/llhttp/libllhttp.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/base64/libbase64.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/deps/base64/libbase64_neon64.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_zlib.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_compiler.a /usr/ports/pobj/node-18.12.1/node-v18.12.1/out/Release/obj.target/tools/v8_gypfiles/libv8_initializers.a -lz -L/usr/local/lib -luv -lbrotlidec -lbrotlienc -lcares -lnghttp2 -L/usr/local/lib/eopenssl30 -lcrypto -lssl -licui18n -licuuc -licudata -L/usr/local/lib -lexecinfo -Wl,--end-group rm 6397dd5483c614f73f92d53c6d8e0280eba86d2f.intermediate 30131a40ede8e27e357859ea148696579dbc6528.intermediate 6e64ad7ded5e02ef3f632200a784bb829ca7e4e9.intermediate 4086690e515943f467370288df0745586e80c35f.intermediate if [ ! -r node ] || [ ! -L node ]; then \ ln -fs out/Release/node node; fi npm ERR! code ENOTFOUND npm ERR! syscall getaddrinfo npm ERR! errno ENOTFOUND npm ERR! network request to https://registry.npmjs.org/zwitch/-/zwitch-2.0.2.tgz failed, reason: getaddrinfo ENOTFOUND registry.npmjs.org npm ERR! network This is a problem related to network connectivity. npm ERR! network In most cases you are behind a proxy or have bad network settings. npm ERR! network npm ERR! network If you are behind a proxy, please make sure that the npm ERR! network 'proxy' config is set properly. See: 'npm help config' npm ERR! A complete log of this run can be found in: npm ERR! /usr/ports/pobj/node-18.12.1/node-v18.12.1/.npm/_logs/2022-12-06T03_58_37_445Z-debug-0.log gmake[1]: *** [Makefile:750: tools/doc/node_modules] Error 1 gmake: *** [Makefile:337: test-only] Error 2 *** Error 2 in . (Makefile:115 'do-test') *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2993 '/usr/ports/pobj/node-18.12.1/.test_done': @cd /usr/ports/lang/node && exec ...) *** Error 2 in /usr/ports/lang/node (/usr/ports/infrastructure/mk/bsd.port.mk:2604 'test': @lock=node-18.12.1v0; export _LOCKS_HELD=" node-...) 0 verbose cli /usr/local/bin/node /usr/ports/pobj/node-18.12.1/node-v18.12.1/deps/npm/bin/npm-cli.js 1 info using npm@8.19.2 2 info using node@v18.12.1 3 timing npm:load:whichnode Completed in 0ms 4 timing config:load:defaults Completed in 2ms 5 timing config:load:file:/usr/ports/pobj/node-18.12.1/node-v18.12.1/deps/npm/npmrc Completed in 1ms 6 timing config:load:builtin Completed in 2ms 7 timing config:load:cli Completed in 2ms 8 timing config:load:env Completed in 1ms 9 timing config:load:file:/usr/ports/pobj/node-18.12.1/node-v18.12.1/tools/doc/.npmrc Completed in 0ms 10 timing config:load:project Completed in 4ms 11 timing config:load:file:/usr/ports/pobj/node-18.12.1/node-v18.12.1/.npmrc Completed in 0ms 12 timing config:load:user Completed in 1ms 13 timing config:load:file:/usr/local/etc/npmrc Completed in 0ms 14 timing config:load:global Completed in 0ms 15 timing config:load:validate Completed in 0ms 16 timing config:load:credentials Completed in 1ms 17
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2022/12/05 22:54:52 Modified files: www/iridium: Makefile distinfo www/iridium/patches: patch-BUILD_gn patch-base_BUILD_gn patch-base_allocator_partition_allocator_page_allocator_h patch-base_allocator_partition_allocator_page_allocator_internals_posix_h patch-base_allocator_partition_allocator_partition_address_space_cc patch-base_allocator_partition_allocator_partition_alloc_constants_h patch-base_cpu_h patch-base_i18n_icu_util_cc patch-base_memory_discardable_memory_cc patch-base_process_process_metrics_h patch-base_rand_util_h patch-base_rand_util_posix_cc patch-base_strings_safe_sprintf_unittest_cc patch-base_system_sys_info_h patch-base_system_sys_info_posix_cc patch-base_system_sys_info_unittest_cc patch-base_threading_platform_thread_linux_cc patch-base_threading_platform_thread_posix_cc patch-build_config_compiler_BUILD_gn patch-cc_BUILD_gn patch-chrome_app_chrome_main_delegate_cc patch-chrome_app_chromium_strings_grd patch-chrome_app_generated_resources_grd patch-chrome_app_google_chrome_strings_grd patch-chrome_app_settings_strings_grdp patch-chrome_app_theme_theme_resources_grd patch-chrome_browser_about_flags_cc patch-chrome_browser_browser_features_cc patch-chrome_browser_browser_process_impl_cc patch-chrome_browser_chrome_browser_interface_binders_cc patch-chrome_browser_chrome_browser_main_cc patch-chrome_browser_chrome_browser_main_posix_cc patch-chrome_browser_chrome_content_browser_client_cc patch-chrome_browser_download_download_file_picker_cc patch-chrome_browser_download_download_item_model_cc patch-chrome_browser_download_download_prefs_cc patch-chrome_browser_download_download_prefs_h patch-chrome_browser_enterprise_connectors_device_trust_device_trust_connector_service_factory_cc patch-chrome_browser_enterprise_connectors_device_trust_device_trust_service_factory_cc patch-chrome_browser_enterprise_connectors_device_trust_signals_signals_service_factory_cc patch-chrome_browser_enterprise_signals_device_info_fetcher_cc patch-chrome_browser_extensions_BUILD_gn patch-chrome_browser_extensions_api_enterprise_reporting_private_conversion_utils_cc patch-chrome_browser_extensions_api_enterprise_reporting_private_enterprise_reporting_private_api_cc patch-chrome_browser_extensions_api_enterprise_reporting_private_enterprise_reporting_private_api_h patch-chrome_browser_extensions_api_passwords_private_passwords_private_delegate_impl_cc patch-chrome_browser_extensions_api_settings_private_prefs_util_cc patch-chrome_browser_first_run_first_run_dialog_h patch-chrome_browser_first_run_first_run_internal_h patch-chrome_browser_flag_descriptions_cc patch-chrome_browser_flag_descriptions_h patch-chrome_browser_headless_headless_mode_util_cc patch-chrome_browser_metrics_chrome_browser_main_extra_parts_metrics_cc patch-chrome_browser_metrics_chrome_metrics_service_client_cc patch-chrome_browser_metrics_perf_cpu_identity_cc patch-chrome_browser_metrics_power_process_monitor_cc patch-chrome_browser_metrics_power_process_monitor_h patch-chrome_browser_policy_configuration_policy_handler_list_factory_cc patch-chrome_browser_prefs_browser_prefs_cc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2022/12/05 17:07:19 Modified files: devel/glib2: Makefile Log message: devel/glib2: fix build on sparc64 The build now involves various C++11 features like trailing commas in enums. And an upstream commit attempts to fix macros by enabling tests depending on C++11 or gcc >= 4.8 everywhere. Switch compiler on sparc64 to ports-gcc while waiting for upstream to clean this mess up. https://gitlab.gnome.org/GNOME/glib/-/commit/c19904d6e8951ea774dc298fa793d8b0e506e32d ok aja
Re: [sparc64] build of glib2
Fine with me.
—
Antoine
> On 5 Dec 2022, at 23:22, Theo Buehler wrote:
>
> Latest devel/glib2 doesn't build on sparc64. Various things now seem to
> require a C++11 capable compiler, e.g.,
>
> ../glib-2.74.3/glib/guri.h:92: error: comma at end of enumerator list
> ../glib-2.74.3/glib/guri.h:213: error: comma at end of enumerator list
> ../glib-2.74.3/glib/guri.h:263: error: comma at end of enumerator list
> ../glib-2.74.3/glib/guri.h:338: error: comma at end of enumerator list
>
> ../glib-2.74.3/glib/tests/cxx.cpp: In function 'void test_typeof()':
> ../glib-2.74.3/glib/tests/cxx.cpp:31: error: invalid conversion from 'void*'
> to 'MyObject*'
> ../glib-2.74.3/glib/tests/cxx.cpp:34: error: invalid conversion from 'void*'
> to 'MyObject*'
> ../glib-2.74.3/glib/tests/cxx.cpp:54: error: invalid conversion from 'void*'
> to 'MyObject*'
>
> Part of this is due to this commit
>
> https://gitlab.gnome.org/GNOME/glib/-/commit/c19904d6e8951ea774dc298fa793d8b0e506e32d
>
> (I'm not sure how this is supposed to work with older compilers as
> mentioned in the commit message: given how glib_typeof() is defined, it
> requires gcc >= 4.8 or clang or a C++11-capable compiler)
>
> Instead of doing a patching whack-a-mole, it seems saner to switch
> compiler at least until upstream fixes this. The below probably isn't
> quite right since port-lib-depends-check on sparc64 complains about
>
> Extra: estdc++.19
>
> I don't know how to fix that.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/glib2/Makefile,v
> retrieving revision 1.369
> diff -u -p -r1.369 Makefile
> --- Makefile2 Dec 2022 07:28:43 -1.369
> +++ Makefile5 Dec 2022 21:21:32 -
> @@ -32,6 +32,9 @@ MODULES=devel/meson \
>
> MODGNOME_TOOLS=docbook
>
> +# Tests in cpp.cxx now require C++11
> +COMPILER=base-clang ports-gcc
> +
> DEBUG_PACKAGES=${BUILD_PACKAGES}
>
> # meson: have_bash, needed to install bash-completion snippets
Re: [UPDATE] lang/node 18.12.1
On 12/5/22 23:27, Theo Buehler wrote: On Mon, Dec 05, 2022 at 11:14:56PM +0100, Volker Schlecht wrote: That's switching as in "They bundle OpenSSL 3.07 + QUIC Patch and that's what they develop against". They also support BoringSSL which does not yet provide any OpenSSL 3 API. Well ... for some value of 'support' they do: https://github.com/nodejs/node/issues/25890 You seem to be critical about having the dependency on 3.0 ... any reasons I should be aware of? OpenSSL 1.1 is well tested and a more or less known beast. OpenSSL 3 on the other hand... not so much. Agreed. I don't care deeply if OpenSSL 3 is used for this, I just wanted to make sure the switch wasn't made blindly since newer is better (which in this case it probably isn't). It really wasn't - I just intend to stick as closely to upstream's choices as possible without having to get the bundled OpenSSL dependency to build and work.
Re: [UPDATE] lang/node 18.12.1
On Mon, Dec 05, 2022 at 11:14:56PM +0100, Volker Schlecht wrote: > That's switching as in "They bundle OpenSSL 3.07 + QUIC Patch and that's > what they develop against". They also support BoringSSL which does not yet provide any OpenSSL 3 API. > Also the project would rather have switched to OpenSSL 3.0 for the previous > LTS release already: > > https://nodejs.org/en/blog/announcements/nodejs16-eol/ > > So while it might build against OpenSSL 1.1.1 (full disclosure: I didn't > even try) I'm reasonably sure that any issues arising from that will be ours > to fix. > > You seem to be critical about having the dependency on 3.0 ... any reasons I > should be aware of? OpenSSL 1.1 is well tested and a more or less known beast. OpenSSL 3 on the other hand... not so much. I don't care deeply if OpenSSL 3 is used for this, I just wanted to make sure the switch wasn't made blindly since newer is better (which in this case it probably isn't).
[sparc64] build of glib2
Latest devel/glib2 doesn't build on sparc64. Various things now seem to
require a C++11 capable compiler, e.g.,
../glib-2.74.3/glib/guri.h:92: error: comma at end of enumerator list
../glib-2.74.3/glib/guri.h:213: error: comma at end of enumerator list
../glib-2.74.3/glib/guri.h:263: error: comma at end of enumerator list
../glib-2.74.3/glib/guri.h:338: error: comma at end of enumerator list
../glib-2.74.3/glib/tests/cxx.cpp: In function 'void test_typeof()':
../glib-2.74.3/glib/tests/cxx.cpp:31: error: invalid conversion from 'void*' to
'MyObject*'
../glib-2.74.3/glib/tests/cxx.cpp:34: error: invalid conversion from 'void*' to
'MyObject*'
../glib-2.74.3/glib/tests/cxx.cpp:54: error: invalid conversion from 'void*' to
'MyObject*'
Part of this is due to this commit
https://gitlab.gnome.org/GNOME/glib/-/commit/c19904d6e8951ea774dc298fa793d8b0e506e32d
(I'm not sure how this is supposed to work with older compilers as
mentioned in the commit message: given how glib_typeof() is defined, it
requires gcc >= 4.8 or clang or a C++11-capable compiler)
Instead of doing a patching whack-a-mole, it seems saner to switch
compiler at least until upstream fixes this. The below probably isn't
quite right since port-lib-depends-check on sparc64 complains about
Extra: estdc++.19
I don't know how to fix that.
Index: Makefile
===
RCS file: /cvs/ports/devel/glib2/Makefile,v
retrieving revision 1.369
diff -u -p -r1.369 Makefile
--- Makefile2 Dec 2022 07:28:43 - 1.369
+++ Makefile5 Dec 2022 21:21:32 -
@@ -32,6 +32,9 @@ MODULES= devel/meson \
MODGNOME_TOOLS=docbook
+# Tests in cpp.cxx now require C++11
+COMPILER= base-clang ports-gcc
+
DEBUG_PACKAGES=${BUILD_PACKAGES}
# meson: have_bash, needed to install bash-completion snippets
Re: [UPDATE] lang/node 18.12.1
That's switching as in "They bundle OpenSSL 3.07 + QUIC Patch and that's what they develop against". Also the project would rather have switched to OpenSSL 3.0 for the previous LTS release already: https://nodejs.org/en/blog/announcements/nodejs16-eol/ So while it might build against OpenSSL 1.1.1 (full disclosure: I didn't even try) I'm reasonably sure that any issues arising from that will be ours to fix. You seem to be critical about having the dependency on 3.0 ... any reasons I should be aware of? On 12/5/22 22:46, Theo Buehler wrote: On Mon, Dec 05, 2022 at 09:24:35PM +0100, Volker Schlecht wrote: Upstream switched to OpenSSL 3 with their 18.x release: https://openjsf.org/blog/2022/04/19/nodejs-18-released/ Is that an actual switch as "switching is required"? The language sounds more like they plan to support their LTS release with OpenSSL 3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2022/12/05 15:07:23 Modified files: devel/mpfr : Makefile distinfo Log message: devel/mpfr: update to 4.1.1-p1 This fixes the CGAL-related build failure in cad/openscad.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2022/12/05 15:06:55 Modified files: audio/schismtracker: Makefile distinfo audio/schismtracker/patches: patch-configure_ac Log message: Update schismtracker to 20221201.
Re: [UPDATE] lang/node 18.12.1
On Mon, Dec 05, 2022 at 09:24:35PM +0100, Volker Schlecht wrote: > Upstream switched to OpenSSL 3 with their 18.x release: > > https://openjsf.org/blog/2022/04/19/nodejs-18-released/ Is that an actual switch as "switching is required"? The language sounds more like they plan to support their LTS release with OpenSSL 3.
Re: [UPDATE] lang/node 18.12.1
Upstream switched to OpenSSL 3 with their 18.x release:
https://openjsf.org/blog/2022/04/19/nodejs-18-released/
On 12/5/22 21:18, Theo Buehler wrote:
@@ -34,7 +33,7 @@ MODULES = lang/python
WANTLIB += c execinfo m pthread ${COMPILER_LIBCXX}
WANTLIB += z brotlienc brotlidec
WANTLIB += icudata icui18n icuuc cares nghttp2 uv
-WANTLIB += lib/eopenssl11/ssl lib/eopenssl11/crypto
+WANTLIB += lib/eopenssl30/ssl lib/eopenssl30/crypto
Is there a particular reason for switching to OpenSSL 3?
Re: [UPDATE] lang/node 18.12.1
> @@ -34,7 +33,7 @@ MODULES = lang/python
> WANTLIB += c execinfo m pthread ${COMPILER_LIBCXX}
> WANTLIB += z brotlienc brotlidec
> WANTLIB += icudata icui18n icuuc cares nghttp2 uv
> -WANTLIB += lib/eopenssl11/ssl lib/eopenssl11/crypto
> +WANTLIB += lib/eopenssl30/ssl lib/eopenssl30/crypto
Is there a particular reason for switching to OpenSSL 3?
Re: [UPDATE] lang/node 18.12.1
Here's the updated patch for lang/node 18.12.1, including
* Feedback from jca@ for riscv64
* Feedback from sthen@ for comment re: OpenSSL usage
* Upstreamed fix for node-pledge
As of now I'm quite happy with it and am now looking for someone to
check and commit ;-DIndex: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.111
diff -u -p -r1.111 Makefile
--- Makefile 13 Nov 2022 15:28:44 - 1.111
+++ Makefile 5 Dec 2022 19:39:52 -
@@ -5,12 +5,11 @@ USE_WXNEEDED = Yes
COMMENT = JavaScript runtime built on Chrome's V8 JavaScript engine
-NODE_VERSION = v16.17.1
-PLEDGE_VER = 1.1.2
+NODE_VERSION = v18.12.1
+PLEDGE_VER = 1.1.3
DISTFILES = node-pledge-{}${PLEDGE_VER}.tar.gz:0 \
${DISTNAME}-headers.tar.gz \
${DISTNAME}.tar.xz
-REVISION = 2
DISTNAME = node-${NODE_VERSION}
PKGNAME = ${DISTNAME:S/v//g}
@@ -34,7 +33,7 @@ MODULES = lang/python
WANTLIB += c execinfo m pthread ${COMPILER_LIBCXX}
WANTLIB += z brotlienc brotlidec
WANTLIB += icudata icui18n icuuc cares nghttp2 uv
-WANTLIB += lib/eopenssl11/ssl lib/eopenssl11/crypto
+WANTLIB += lib/eopenssl30/ssl lib/eopenssl30/crypto
COMPILER = base-clang ports-gcc
@@ -71,16 +70,16 @@ SUBST_VARS += WRKDIST
SUBST_VARS += NODE_VERSION
SUBST_VARS += EOPENSSL_LIB
-# OpenSSL used: {X,Ed}25519 via EVP, SSL_CIPHER_standard_name and 5-10 other missing symbols/defines.
+# uses a wide range of OpenSSL API and only really supports boring/openssl
LIB_DEPENDS += archivers/brotli \
devel/libuv \
net/libcares \
textproc/icu4c \
www/nghttp2 \
- security/openssl/1.1
+ security/openssl/3.0
-EOPENSSL_LIB = ${LOCALBASE}/lib/eopenssl11
-EOPENSSL_INC = ${LOCALBASE}/include/eopenssl11
+EOPENSSL_LIB = ${LOCALBASE}/lib/eopenssl30
+EOPENSSL_INC = ${LOCALBASE}/include/eopenssl30
post-extract:
mv ${WRKDIR}/node-pledge-${PLEDGE_VER} \
Index: distinfo
===
RCS file: /cvs/ports/lang/node/distinfo,v
retrieving revision 1.65
diff -u -p -r1.65 distinfo
--- distinfo 1 Nov 2022 12:01:49 - 1.65
+++ distinfo 5 Dec 2022 19:39:52 -
@@ -1,6 +1,6 @@
-SHA256 (node-pledge-1.1.2.tar.gz) = zY/JcbZ32mmtqWXXNn3/9aTh7Y3F6fAAaADDA8SYwEk=
-SHA256 (node-v16.17.1-headers.tar.gz) = Ncy5XK8CzaO9aA2kNQqK5dZmp6nq46/lwqGz7ymu8Qg=
-SHA256 (node-v16.17.1.tar.xz) = ZyH+tBUtVtLGs1jOOXq9Wn8drwnuLiXFAhubTT+GozA=
-SIZE (node-pledge-1.1.2.tar.gz) = 3155
-SIZE (node-v16.17.1-headers.tar.gz) = 568068
-SIZE (node-v16.17.1.tar.xz) = 35661452
+SHA256 (node-pledge-1.1.3.tar.gz) = fEaXvLg6hYEJ69K+mgQFizf8DiJY2/DtyFJB/pEanVU=
+SHA256 (node-v18.12.1-headers.tar.gz) = nVXuByum1aFB2wks7xoPcV99P8k4KFptknodCgx0Qvc=
+SHA256 (node-v18.12.1.tar.xz) = T6QGRRvFJlmikOUs/bIWKnYL1UnaS4u+vmop8pbZON8=
+SIZE (node-pledge-1.1.3.tar.gz) = 3167
+SIZE (node-v18.12.1-headers.tar.gz) = 8563785
+SIZE (node-v18.12.1.tar.xz) = 38454588
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/lang/node/patches/patch-Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 patch-Makefile
--- patches/patch-Makefile 18 Mar 2022 19:35:16 - 1.15
+++ patches/patch-Makefile 5 Dec 2022 19:39:52 -
@@ -1,7 +1,7 @@
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -163,7 +163,7 @@ config.gypi: configure configure.py src/node_version.h
+@@ -185,7 +185,7 @@ config.gypi: configure configure.py src/node_version.h
fi
.PHONY: install
@@ -10,7 +10,7 @@ Index: Makefile
$(PYTHON) tools/install.py $@ '$(DESTDIR)' '$(PREFIX)'
.PHONY: uninstall
-@@ -394,6 +394,12 @@ test/addons/.buildstamp: $(ADDONS_PREREQS) \
+@@ -416,6 +416,12 @@ test/addons/.buildstamp: $(ADDONS_PREREQS) \
# Just goes to show that recursive make really is harmful...
# TODO(bnoordhuis) Force rebuild after gyp update.
build-addons: | $(NODE_EXE) test/addons/.buildstamp
Index: patches/patch-common_gypi
===
RCS file: /cvs/ports/lang/node/patches/patch-common_gypi,v
retrieving revision 1.23
diff -u -p -r1.23 patch-common_gypi
--- patches/patch-common_gypi 1 Sep 2022 20:42:56 - 1.23
+++ patches/patch-common_gypi 5 Dec 2022 19:39:52 -
@@ -1,7 +1,7 @@
Index: common.gypi
--- common.gypi.orig
+++ common.gypi
-@@ -416,7 +416,9 @@
+@@ -413,7 +413,9 @@
}],
['OS=="openbsd"', {
'cflags': [ '-I/usr/local/include' ],
Index: patches/patch-deps_npm_node_modules_node-gyp_gyp_pylib_gyp_generator_make_py
===
RCS file: /cvs/ports/lang/node/patches/patch-deps_npm_node_modules_node-gyp_gyp_pylib_gyp_generator_make_py,v
retrieving revision 1.10
diff -u -p -r1.10 patch-deps_npm_node_modules_node-gyp_gyp_pylib_gyp_generator_make_py
--- patches/patch-deps_npm_node_modules_node-gyp_gyp_pylib_gyp_generator_make_py 11 Mar 2022 19:29:08 - 1.10
Re: desmume, any special reqs to run it?
On Sun, Dec 04, 2022 at 05:30:47PM -0700, Anthony J. Bentley wrote: > Mikolaj Kucharski writes: > > I just wanted to see how Nintendo 3DS emulators work on OpenBSD. Never > > played with them before. > > > > $ desmume some-game-decrypted.3ds > > mprotect failed: Operation not permitted > > Abort trap (core dumped) > > > > I tried with few 3DS files and one CIA file, always the same output > > like above. Any tips? > > desmume is a DS emulator, not a 3DS emulator. It doesn't support 3DS > files or CIA files. > > (citra is a 3DS emulator and should be able to handle those files.) > > That said, desmume shouldn't crash like that. I'll look into it. > My money's on wxallowed :) -ml
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/12/05 12:18:35 Modified files: net/tdesktop : Makefile Log message: Unbreak build with newest cmake, bump revision just in case Reported by naddy Tested by rsadowski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/12/05 11:55:27 Modified files: sysutils/borgbackup/1.2: Tag: OPENBSD_7_2 Makefile net/py-msgpack : Tag: OPENBSD_7_2 Makefile distinfo Log message: Fix msgpack runtime on sparc64 Same fix as the borg 1.1 one except that borg 1.2 uses ports py-msgpack which has more consumers than borg 1.2, hence the separate commit. $ borg init -e none ./repo ; echo $? Unknown integrity data version 0 in integrity.1 0 msgpack-python messed up __BYTE_ORDER handling, but only on sparc64 using ports GCC 8.4.0; macppc base clang 13 is fine. msgpack-python got fixed, pull the PR and bump borg 1.2. Teste on little endian amd64/base-clang and big endian macppc/base-clang, sparc64/ports-gcc. OK bket
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/12/05 11:49:20 Modified files: sysutils/borgbackup/1.1: Tag: OPENBSD_7_2 Makefile distinfo Log message: Fix msgpack runtime on sparc64 $ borg init -e none ./repo ; echo $? Unknown integrity data version 0 in integrity.1 0 borg 1.1.x bundles msgpack-python, which messed up __BYTE_ORDER handling, but only on sparc64 using ports GCC 8.4.0; macppc base clang 13 is fine. msgpack-python got fixed, borg's 1.1-maint branch merged it, pull the PR. borgbackup/1.2 and py-msgpack will get the same fix but in a different commit as py-msgpack has more consumers than borg 1.2. Tested on little endian amd64/base-clang and big endian macppc/base-clang, sparc64/ports-gcc. OK bket
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/12/05 11:40:42 Modified files: sysutils/borgbackup: Tag: OPENBSD_7_2 Makefile.inc sysutils/borgbackup/1.1: Tag: OPENBSD_7_2 Makefile sysutils/borgbackup/1.2: Tag: OPENBSD_7_2 Makefile Removed files: sysutils/borgbackup/1.1/patches: Tag: OPENBSD_7_2 patch-src_borg__endian_h sysutils/borgbackup/1.2/patches: Tag: OPENBSD_7_2 patch-src_borg__endian_h Log message: Switch 1.2 to ports-gcc like 1.1 does, remove then unneeded patch Found while debugging runtime breakage on sparc64. Feedback bket sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 11:00:32 Modified files: x11: Makefile Log message: +xmem
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 11:00:09 Log message: import ports/x11/xmem, from michi plus openbsd at dataswamp.org, ok op@ (i tweaked the license marker slightly, it's just the standard no advertising clause) Graphical application that displays memory and swap usage. Status: Vendor Tag: sthen Release Tags: sthen_20221205 N ports/x11/xmem/Makefile N ports/x11/xmem/distinfo N ports/x11/xmem/pkg/DESCR N ports/x11/xmem/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/12/05 10:54:53 Modified files: net/py-msgpack : Makefile distinfo sysutils/borgbackup/1.2: Makefile Log message: Fix msgpack runtime on sparc64 Same fix as the borg 1.1 one except that borg 1.2 uses ports py-msgpack which has more consumers than borg 1.2, hence the separate commit. $ borg init -e none ./repo ; echo $? Unknown integrity data version 0 in integrity.1 0 msgpack-python messed up __BYTE_ORDER handling, but only on sparc64 using ports GCC 8.4.0; macppc base clang 13 is fine. msgpack-python got fixed, pull the PR and bump borg 1.2. Teste on little endian amd64/base-clang and big endian macppc/base-clang, sparc64/ports-gcc. OK bket
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2022/12/05 10:37:58 Modified files: devel/p5-XS-Parse-Keyword: Makefile distinfo Log message: update p5-XS-Parse-Keyword to 0.30
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2022/12/05 10:32:33 Modified files: devel/p5-Commandable: Makefile distinfo devel/p5-Commandable/pkg: PLIST Log message: update p5-Commandable to 0.09
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/12/05 10:05:48 Modified files: x11/gnome/tracker3-miners: Makefile distinfo Log message: Update to tracker3-miners-3.4.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/12/05 09:57:52 Modified files: x11/gnome/tracker3: Makefile distinfo Log message: Update to tracker3-3.4.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/12/05 09:53:32 Modified files: x11/gnome/characters: Makefile distinfo Log message: Update to gnome-characters-43.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 09:00:56 Modified files: sysutils/rdiff-backup: Makefile distinfo sysutils/rdiff-backup/patches: patch-setup_py sysutils/rdiff-backup/pkg: PLIST Removed files: sysutils/rdiff-backup/patches: patch-_librsyncmodule_c patch-rdiff_backup_SetConnections_py Log message: update to rdiff-backup-2.0.5, based on a diff from Joshua Megerman, very generous maintainer timeout (i.e. i was waiting for an email and forgot about it in the meantime..). similar diff giovanni@, ok kn@
Re: sysutils/rdiff-backup: update or remove ?
On Mon, Dec 05, 2022 at 11:25:15AM +, Stuart Henderson wrote:
> On 2022/12/05 12:01, Giovanni Bechis wrote:
> > On Sat, Dec 03, 2022 at 07:30:55PM +, Klemens Nanni wrote:
> > > Last port update is from 2010, i consider this port unmaintained despite
> > > the variable being set.
> > >
> > > python 2, but upstream is super active (last beta is a few hours old)
> > > with python 3 support and a stable version of 2.0.5.
> > >
> > > Does anyone use this port and cares to update it?
> > > It shouldn't rot away on py2 life support^W^W...
> > I am using it, update to 2.0.5 follows.
>
> Joshua Megerman sent a diff back in May for this, which I tweaked and
> sent back, no response from maintainer (and I forgot it was in-flight
> and didn't get round to committing it).
>
> It would be really helpful if people would drop maintainer on ports
> which they aren't realistically going to maintain.
>
> > +lib/python${MODPY_VERSION}/site-packages/rdiff_backup-0.0.0.dist-info/
>
> This should use the pypi "sdist" tarball, the version number doesn't end up
> set correctly when it's built from the GH autogenerated tar.
>
> Here's an updated version of the earlier diffs. OK?
>
sure, ok giovanni@, thanks.
Giovanni
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/rdiff-backup/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile 11 Mar 2022 19:57:55 - 1.24
> +++ Makefile 5 Dec 2022 11:20:28 -
> @@ -1,26 +1,27 @@
> -COMMENT =incremental backup
> +COMMENT =incremental backup
>
> -MODPY_EGG_VERSION = 1.2.8
> +MODPY_EGG_VERSION = 2.0.5
> DISTNAME = rdiff-backup-${MODPY_EGG_VERSION}
> -REVISION = 8
> +
> CATEGORIES = sysutils
>
> -HOMEPAGE = http://www.nongnu.org/rdiff-backup/
> +HOMEPAGE = https://rdiff-backup.net/
>
> -MAINTAINER = Pierre-Emmanuel Andre
> +MAINTAINER = Pierre-Emmanuel Andre
>
> # GPLv2+
> PERMIT_PACKAGE = Yes
>
> WANTLIB += rsync pthread ${MODPY_WANTLIB}
>
> -LIB_DEPENDS += net/librsync
> -
> -MASTER_SITES = ${MASTER_SITE_SAVANNAH:=rdiff-backup/}
> +LIB_DEPENDS += net/librsync
>
> -MODULES = lang/python
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
> +MODULES = lang/python
> +MODPY_PI = Yes
> +MODPY_PYBUILD = setuptools_scm
> +CFLAGS +=-I${LOCALBASE}/include
>
> -NO_TEST =Yes
> +# tests are present but are intended to run via Tox in a Docker container
> +NO_TEST =Yes
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/rdiff-backup/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 18 Jan 2015 03:15:14 - 1.3
> +++ distinfo 5 Dec 2022 11:20:28 -
> @@ -1,2 +1,2 @@
> -SHA256 (rdiff-backup-1.2.8.tar.gz) =
> DZGoW0CUkRb6iq8V2hZcNKLRVEmzy+AcgCY5ExCslds=
> -SIZE (rdiff-backup-1.2.8.tar.gz) = 196526
> +SHA256 (rdiff-backup-2.0.5.tar.gz) =
> VNFgOOYgFO2RbHHIMDsH0vphpqaAOMoYn8LTFTSw84s=
> +SIZE (rdiff-backup-2.0.5.tar.gz) = 456089
> Index: patches/patch-_librsyncmodule_c
> ===
> RCS file: patches/patch-_librsyncmodule_c
> diff -N patches/patch-_librsyncmodule_c
> --- patches/patch-_librsyncmodule_c 11 Mar 2022 19:57:55 - 1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,22 +0,0 @@
> -Fix with librsync v1.0.0; similar to
> -https://bugs.launchpad.net/duplicity/+bug/1416344
> -
> -This uses the backwards-compatible format that uses the insecure
> -truncated MD4 hash.
> -
> _librsyncmodule.c.orig Wed Aug 19 20:33:42 2015
> -+++ _librsyncmodule.cWed Aug 19 20:34:42 2015
> -@@ -59,8 +59,13 @@ _librsync_new_sigmaker(PyObject* self, PyObject* args)
> - if (sm == NULL) return NULL;
> - sm->x_attr = NULL;
> -
> -+#ifdef RS_DEFAULT_STRONG_LEN
> - sm->sig_job = rs_sig_begin((size_t)blocklen,
> -
> (size_t)RS_DEFAULT_STRONG_LEN);
> -+#else
> -+ sm->sig_job = rs_sig_begin((size_t)blocklen,
> -+ (size_t)8,
> RS_MD4_SIG_MAGIC);
> -+#endif
> - return (PyObject*)sm;
> - }
> -
> Index: patches/patch-rdiff_backup_SetConnections_py
> ===
> RCS file: patches/patch-rdiff_backup_SetConnections_py
> diff -N patches/patch-rdiff_backup_SetConnections_py
> --- patches/patch-rdiff_backup_SetConnections_py 11 Mar 2022 19:57:55
> - 1.3
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,18 +0,0 @@
> -Bugfix: DeprecationWarning: os.popen2 is deprecated
> -cf http://bugs.gentoo.org/attachment.cgi?id=216585=view
> -
> rdiff_backup/SetConnections.py.orig Mon Mar 16 14:36:21 2009
> -+++
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2022/12/05 06:41:26 Modified files: www/ungoogled-chromium: Makefile distinfo Log message: switch over to official ungoogled-chromium release tarball
Re: NEW: sysutils/xmem
Ping. On Wed, Nov 23, 2022 at 09:13:48PM +0100, Michael wrote: > Ping. > > On Mon, Nov 14, 2022 at 10:41:30AM +0100, Omar Polo wrote: > > Hello, > > > > On 2022/11/13 11:05:51 +0100, Michael wrote: > > > Hi ports, > > > > > > another attempt to get sysutils/xmem in, last one was 2021 [1]. This > > > revision has the RCS IDs removed and HOMEPAGE [2] updated. > > > > > > From pkg/DESCR: > > > Graphical application that displays memory and swap usage. > > > > > > Tested on amd64. > > > > Oh, i remember this one! > > > > The "restrictions" in the license comment is just the following > > clausole added to the MIT license: > > > > : Except as contained in this notice, the name of the X Consortium shall > > : not be used in advertising or otherwise to promote the sale, use or > > : other dealings in this Software without prior written authorization from > > : the X Consortium. > > > > that I guess it's not a blocker for PERMIT_PACKAGE. > > > > ok op@ to import. > > > > > [1] https://marc.info/?l=openbsd-ports=161521843031914=2 > > > [2] https://git.sdf.org/bch/xmem > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2022/12/05 05:17:17 Modified files: geo/pgrouting : Makefile distinfo geo/pgrouting/pkg: PLIST Log message: geo/pgrouting: update to 3.4.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 05:05:55 Modified files: comms/chirp: Makefile distinfo comms/chirp/patches: patch-chirp_ui_mainapp_py comms/chirp/pkg: PLIST Removed files: comms/chirp/patches: patch-chirp_ui_editorset_py patch-chirp_ui_importdialog_py Log message: update to chirp-20221203
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 05:00:36 Modified files: databases : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm Removed files: databases/py-sqlite2: Makefile distinfo databases/py-sqlite2/patches: patch-setup_py databases/py-sqlite2/pkg: DESCR PLIST Log message: remove py-sqlite2; it hasn't actually been used since around python 2.3 when it was integrated into python core as the "sqlite3" module; nmap's zenmap subpackage listed a dependency, but didn't really use this (the module is confusingly named; it is for sqlite3 not sqlite2!)
Re: sysutils/rdiff-backup: update or remove ?
On 2022/12/05 12:01, Giovanni Bechis wrote:
> On Sat, Dec 03, 2022 at 07:30:55PM +, Klemens Nanni wrote:
> > Last port update is from 2010, i consider this port unmaintained despite
> > the variable being set.
> >
> > python 2, but upstream is super active (last beta is a few hours old)
> > with python 3 support and a stable version of 2.0.5.
> >
> > Does anyone use this port and cares to update it?
> > It shouldn't rot away on py2 life support^W^W...
> I am using it, update to 2.0.5 follows.
Joshua Megerman sent a diff back in May for this, which I tweaked and
sent back, no response from maintainer (and I forgot it was in-flight
and didn't get round to committing it).
It would be really helpful if people would drop maintainer on ports
which they aren't realistically going to maintain.
> +lib/python${MODPY_VERSION}/site-packages/rdiff_backup-0.0.0.dist-info/
This should use the pypi "sdist" tarball, the version number doesn't end up
set correctly when it's built from the GH autogenerated tar.
Here's an updated version of the earlier diffs. OK?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/rdiff-backup/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile11 Mar 2022 19:57:55 - 1.24
+++ Makefile5 Dec 2022 11:20:28 -
@@ -1,26 +1,27 @@
-COMMENT = incremental backup
+COMMENT = incremental backup
-MODPY_EGG_VERSION =1.2.8
+MODPY_EGG_VERSION =2.0.5
DISTNAME = rdiff-backup-${MODPY_EGG_VERSION}
-REVISION = 8
+
CATEGORIES = sysutils
-HOMEPAGE = http://www.nongnu.org/rdiff-backup/
+HOMEPAGE = https://rdiff-backup.net/
-MAINTAINER = Pierre-Emmanuel Andre
+MAINTAINER = Pierre-Emmanuel Andre
# GPLv2+
PERMIT_PACKAGE = Yes
WANTLIB += rsync pthread ${MODPY_WANTLIB}
-LIB_DEPENDS += net/librsync
-
-MASTER_SITES = ${MASTER_SITE_SAVANNAH:=rdiff-backup/}
+LIB_DEPENDS += net/librsync
-MODULES= lang/python
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
+MODULES= lang/python
+MODPY_PI = Yes
+MODPY_PYBUILD =setuptools_scm
+CFLAGS += -I${LOCALBASE}/include
-NO_TEST = Yes
+# tests are present but are intended to run via Tox in a Docker container
+NO_TEST = Yes
.include
Index: distinfo
===
RCS file: /cvs/ports/sysutils/rdiff-backup/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:15:14 - 1.3
+++ distinfo5 Dec 2022 11:20:28 -
@@ -1,2 +1,2 @@
-SHA256 (rdiff-backup-1.2.8.tar.gz) =
DZGoW0CUkRb6iq8V2hZcNKLRVEmzy+AcgCY5ExCslds=
-SIZE (rdiff-backup-1.2.8.tar.gz) = 196526
+SHA256 (rdiff-backup-2.0.5.tar.gz) =
VNFgOOYgFO2RbHHIMDsH0vphpqaAOMoYn8LTFTSw84s=
+SIZE (rdiff-backup-2.0.5.tar.gz) = 456089
Index: patches/patch-_librsyncmodule_c
===
RCS file: patches/patch-_librsyncmodule_c
diff -N patches/patch-_librsyncmodule_c
--- patches/patch-_librsyncmodule_c 11 Mar 2022 19:57:55 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,22 +0,0 @@
-Fix with librsync v1.0.0; similar to
-https://bugs.launchpad.net/duplicity/+bug/1416344
-
-This uses the backwards-compatible format that uses the insecure
-truncated MD4 hash.
-
_librsyncmodule.c.orig Wed Aug 19 20:33:42 2015
-+++ _librsyncmodule.c Wed Aug 19 20:34:42 2015
-@@ -59,8 +59,13 @@ _librsync_new_sigmaker(PyObject* self, PyObject* args)
- if (sm == NULL) return NULL;
- sm->x_attr = NULL;
-
-+#ifdef RS_DEFAULT_STRONG_LEN
- sm->sig_job = rs_sig_begin((size_t)blocklen,
-
(size_t)RS_DEFAULT_STRONG_LEN);
-+#else
-+ sm->sig_job = rs_sig_begin((size_t)blocklen,
-+ (size_t)8,
RS_MD4_SIG_MAGIC);
-+#endif
- return (PyObject*)sm;
- }
-
Index: patches/patch-rdiff_backup_SetConnections_py
===
RCS file: patches/patch-rdiff_backup_SetConnections_py
diff -N patches/patch-rdiff_backup_SetConnections_py
--- patches/patch-rdiff_backup_SetConnections_py11 Mar 2022 19:57:55
- 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,18 +0,0 @@
-Bugfix: DeprecationWarning: os.popen2 is deprecated
-cf http://bugs.gentoo.org/attachment.cgi?id=216585=view
-
rdiff_backup/SetConnections.py.origMon Mar 16 14:36:21 2009
-+++ rdiff_backup/SetConnections.py Wed Aug 19 20:31:28 2015
-@@ -135,10 +135,10 @@ def init_connection(remote_cmd):
- if not remote_cmd: return Globals.local_connection
-
- Log("Executing " + remote_cmd, 4)
-- if os.name == "nt":
-+ if map(int, sys.version.split()[0].split('.')[:2]) >= [2, 6]:
-
Re: [update] i2pd-2.44.0
Ping. Le 21/11/2022 à 21:15, Ganymede a écrit : Hi, Here's an update for net/i2pd. The main feature of this release is that SSU2, a novel UDP-based communication protocol developed for the I2P network, is now enabled by default. It also brings other improvements and bug fixes. Changelog : https://github.com/PurpleI2P/i2pd/releases/tag/2.44.0 I could build and run i2pd-2.44.0 on -current and -stable on amd64. It has been working flawlessly for me on -stable for 24 hours. Best regards, Ganymede
Re: sysutils/rdiff-backup: update or remove ?
On Sat, Dec 03, 2022 at 07:30:55PM +, Klemens Nanni wrote:
> Last port update is from 2010, i consider this port unmaintained despite
> the variable being set.
>
> python 2, but upstream is super active (last beta is a few hours old)
> with python 3 support and a stable version of 2.0.5.
>
> Does anyone use this port and cares to update it?
> It shouldn't rot away on py2 life support^W^W...
I am using it, update to 2.0.5 follows.
Cheers
Giovanni
Index: Makefile
===
RCS file: /cvs/ports/sysutils/rdiff-backup/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile11 Mar 2022 19:57:55 - 1.24
+++ Makefile5 Dec 2022 10:54:34 -
@@ -1,12 +1,13 @@
COMMENT = incremental backup
-MODPY_EGG_VERSION =1.2.8
+MODPY_EGG_VERSION =2.0.5
+GH_ACCOUNT = rdiff-backup
+GH_PROJECT = rdiff-backup
+GH_TAGNAME = v2.0.5
+
DISTNAME = rdiff-backup-${MODPY_EGG_VERSION}
-REVISION = 8
CATEGORIES = sysutils
-HOMEPAGE = http://www.nongnu.org/rdiff-backup/
-
MAINTAINER = Pierre-Emmanuel Andre
# GPLv2+
@@ -16,10 +17,8 @@ WANTLIB += rsync pthread ${MODPY_WANTLI
LIB_DEPENDS += net/librsync
-MASTER_SITES = ${MASTER_SITE_SAVANNAH:=rdiff-backup/}
-
MODULES= lang/python
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
+MODPY_PYBUILD =setuptools_scm
NO_TEST = Yes
Index: distinfo
===
RCS file: /cvs/ports/sysutils/rdiff-backup/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:15:14 - 1.3
+++ distinfo5 Dec 2022 10:54:34 -
@@ -1,2 +1,2 @@
-SHA256 (rdiff-backup-1.2.8.tar.gz) =
DZGoW0CUkRb6iq8V2hZcNKLRVEmzy+AcgCY5ExCslds=
-SIZE (rdiff-backup-1.2.8.tar.gz) = 196526
+SHA256 (rdiff-backup-2.0.5.tar.gz) =
/Trz05/pHvKygeapBkRREsW3GGQOSQyLb4OolgMYNSs=
+SIZE (rdiff-backup-2.0.5.tar.gz) = 441475
Index: patches/patch-_librsyncmodule_c
===
RCS file: patches/patch-_librsyncmodule_c
diff -N patches/patch-_librsyncmodule_c
--- patches/patch-_librsyncmodule_c 11 Mar 2022 19:57:55 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,22 +0,0 @@
-Fix with librsync v1.0.0; similar to
-https://bugs.launchpad.net/duplicity/+bug/1416344
-
-This uses the backwards-compatible format that uses the insecure
-truncated MD4 hash.
-
_librsyncmodule.c.orig Wed Aug 19 20:33:42 2015
-+++ _librsyncmodule.c Wed Aug 19 20:34:42 2015
-@@ -59,8 +59,13 @@ _librsync_new_sigmaker(PyObject* self, PyObject* args)
- if (sm == NULL) return NULL;
- sm->x_attr = NULL;
-
-+#ifdef RS_DEFAULT_STRONG_LEN
- sm->sig_job = rs_sig_begin((size_t)blocklen,
-
(size_t)RS_DEFAULT_STRONG_LEN);
-+#else
-+ sm->sig_job = rs_sig_begin((size_t)blocklen,
-+ (size_t)8,
RS_MD4_SIG_MAGIC);
-+#endif
- return (PyObject*)sm;
- }
-
Index: patches/patch-rdiff_backup_SetConnections_py
===
RCS file: patches/patch-rdiff_backup_SetConnections_py
diff -N patches/patch-rdiff_backup_SetConnections_py
--- patches/patch-rdiff_backup_SetConnections_py11 Mar 2022 19:57:55
- 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,18 +0,0 @@
-Bugfix: DeprecationWarning: os.popen2 is deprecated
-cf http://bugs.gentoo.org/attachment.cgi?id=216585=view
-
rdiff_backup/SetConnections.py.origMon Mar 16 14:36:21 2009
-+++ rdiff_backup/SetConnections.py Wed Aug 19 20:31:28 2015
-@@ -135,10 +135,10 @@ def init_connection(remote_cmd):
- if not remote_cmd: return Globals.local_connection
-
- Log("Executing " + remote_cmd, 4)
-- if os.name == "nt":
-+ if map(int, sys.version.split()[0].split('.')[:2]) >= [2, 6]:
- import subprocess
- try:
-- process = subprocess.Popen(remote_cmd, shell=False,
bufsize=0,
-+ process = subprocess.Popen(remote_cmd, shell=True,
bufsize=0,
-
stdin=subprocess.PIPE,
-
stdout=subprocess.PIPE)
- (stdin, stdout) = (process.stdin, process.stdout)
Index: patches/patch-setup_py
===
RCS file: /cvs/ports/sysutils/rdiff-backup/patches/patch-setup_py,v
retrieving revision 1.4
diff -u -p -r1.4 patch-setup_py
--- patches/patch-setup_py 11 Mar 2022 19:57:55 - 1.4
+++ patches/patch-setup_py 5 Dec 2022 10:54:34 -
@@ -1,34 +1,56 @@
setup.py.orig Mon Mar 16 15:36:21 2009
-+++ setup.py Thu Feb 11 14:29:01 2010
-@@ -58,6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 03:03:55 Modified files: graphics/ffmpeg: Makefile graphics/ffmpeg/patches: patch-libavcodec_libsvtav1_c Log message: FFmpeg tweaks, from Brad: - Enable zimg support in libavfilter - Roll in more SVT-AV1 bug fixes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 03:03:23 Modified files: multimedia/mpv : Makefile Added files: multimedia/mpv/patches: patch-common_av_log_c patch-player_main_c patch-video_out_vo_gpu_next_c Log message: mpv tweaks, from brad: - SEPARATE_BUILD is set by the Meson module - Bring in some --version logging patches and two vo_gpu_next bug fixes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 03:02:08 Modified files: net/arp-scan : Makefile distinfo net/arp-scan/files: format-ma net/arp-scan/patches: patch-arp-scan_c patch-link-bpf_c patch-mac-vendor_txt net/arp-scan/pkg: PLIST-mac PLIST-main Log message: update to newer arp-scan checkout
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:56 Modified files: devel/py-pyrsistent: Makefile distinfo Log message: update to py3-pyrsistent-0.19.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:45 Modified files: print/py-pikepdf: Makefile distinfo print/py-pikepdf/patches: patch-tests_test_io_py Log message: update to py3-pikepdf-6.2.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:39 Modified files: devel/py-path : Makefile distinfo Log message: update to py3-path-16.6.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:34 Modified files: devel/py-invoke: Makefile distinfo Log message: update to py3-invoke-1.7.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:29 Modified files: devel/py-pathspec: Makefile distinfo Log message: update to py3-pathspec-0.10.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:26 Modified files: graphics/ImageMagick: Makefile distinfo graphics/ImageMagick/patches: patch-configure_ac Log message: update to ImageMagick-6.9.12.68
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:23 Modified files: devel/py-regex : Makefile distinfo Log message: update to py3-regex-2022.10.31
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:18 Modified files: net/arouteserver: Makefile distinfo Log message: update to arouteserver-1.18.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/12/05 02:10:12 Modified files: graphics/pdf2djvu: Makefile distinfo Log message: update to pdf2djvu-0.9.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/12/05 02:00:20 Modified files: x11/gnome/aisleriot: Makefile distinfo Log message: Update to aisleriot-3.22.27.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/12/05 01:59:32 Modified files: devel/libffi : Makefile distinfo devel/libffi/patches: patch-configure patch-configure_host patch-src_arm_ffi_c patch-src_closures_c patch-testsuite_lib_libffi_exp Log message: Update to libffi-3.4.4. survived a bulk (+ runtime on amd64) ok jasper@ (maintainer) tested on riscv64 and no objection from jca@
Re: mail/opensmtpd-extras: update or remove -python package?
On 12/3/22 20:11, Klemens Nanni wrote: There is 6.8.0 available but the -extras distfile is stuck at 6.7.1. The python code over at https://github.com/OpenSMTPD/OpenSMTPD-extras is at least six years old according to git... according to git latest release is 6.7.1 Is anyone still using old python 2 bindings and/or do they still work with current smtpd? Anyone interested in porting them to python 3 or can we remove them? I am not using python bindings at all. Cheers Giovanni --- Information for https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/opensmtpd-extras-python-6.7.1v0.tgz Comment: extras with python bindings for smtpd Description: Extras with Python bindings for OpenSMTPD. Maintainer: Giovanni Bechis , Joerg Jung WWW: https://www.opensmtpd.org/
