CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/12/01 00:25:00 Modified files: x11/xfce4/mousepad: Makefile distinfo x11/xfce4/mousepad/pkg: PLIST Log message: x11/xfce4/mousepad: update to 0.5.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/12/01 00:12:56 Modified files: x11/greybird : Makefile distinfo Log message: x11/greybird: update to 3.22.13
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/11/30 23:03:24 Modified files: x11/awesome: Makefile x11/awesome/pkg: PLIST Log message: Disable generation of docs to unbreak sparc64 build OK kmos
make py-sphinx stop depending on py-sphinx_rtd_theme
Turns out py-sphinx stopped depending on py-sphinx_rtd_theme close to 5
years ago. This is mentioned in CHANGES under the notes for release 1.4.
Diff below removes rtd as a BUILD_DEP for py-sphinx and instead makes it a
BUILD_DEP for the 3 ports that actually use the theme (py-virtualenv,
luacheck, vdirsyncer).
Probably should have gone in with the last commit if I'd noticed it
sooner.
ok?
Index: devel/py-virtualenv/Makefile
===
RCS file: /cvs/ports/devel/py-virtualenv/Makefile,v
retrieving revision 1.28
diff -u -p -u -r1.28 Makefile
--- devel/py-virtualenv/Makefile27 Nov 2020 01:59:28 - 1.28
+++ devel/py-virtualenv/Makefile1 Dec 2020 05:26:33 -
@@ -6,7 +6,7 @@ MODPY_EGG_VERSION = 16.0.0
DISTNAME = virtualenv-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
CATEGORIES = devel
-REVISION = 2
+REVISION = 3
HOMEPAGE = http://www.virtualenv.org/
@@ -18,7 +18,8 @@ PERMIT_PACKAGE = Yes
MODPY_PI = Yes
MODULES = lang/python
-BUILD_DEPENDS =textproc/py-sphinx${MODPY_FLAVOR}>=1.4.8p5
+BUILD_DEPENDS =textproc/py-sphinx${MODPY_FLAVOR}>=1.4.8p5 \
+ textproc/py-sphinx_rtd_theme${MODPY_FLAVOR}>=0.4.3
TEST_DEPENDS = devel/py-test${MODPY_FLAVOR} \
devel/py-mock${MODPY_FLAVOR}
Index: devel/luacheck/Makefile
===
RCS file: /cvs/ports/devel/luacheck/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- devel/luacheck/Makefile 27 Nov 2020 01:59:28 - 1.11
+++ devel/luacheck/Makefile 1 Dec 2020 05:26:33 -
@@ -7,11 +7,12 @@ GH_ACCOUNT= mpeterv
GH_PROJECT=luacheck
GH_TAGNAME=0.21.2
-REVISION= 0
+REVISION= 1
MAINTAINER=Jonathan Gray
-BUILD_DEPENDS= textproc/py-sphinx>=1.4.8p5
+BUILD_DEPENDS= textproc/py-sphinx>=1.4.8p5 \
+ textproc/py-sphinx_rtd_theme${MODPY_FLAVOR}>=0.4.3
# MIT
PERMIT_PACKAGE=Yes
Index: textproc/py-sphinx/Makefile
===
RCS file: /cvs/ports/textproc/py-sphinx/Makefile,v
retrieving revision 1.29
diff -u -p -u -r1.29 Makefile
--- textproc/py-sphinx/Makefile 27 Nov 2020 01:59:28 - 1.29
+++ textproc/py-sphinx/Makefile 1 Dec 2020 05:26:33 -
@@ -5,13 +5,12 @@ COMMENT = python documentation generato
MODPY_EGG_VERSION =1.4.8
DISTNAME = Sphinx-${MODPY_EGG_VERSION}
PKGNAME = py-sphinx-${MODPY_EGG_VERSION}
-REVISION = 5
+REVISION = 6
CATEGORIES = textproc
HOMEPAGE = http://sphinx-doc.org/
-
# BSD
PERMIT_PACKAGE = Yes
@@ -24,7 +23,6 @@ RUN_DEPENDS = devel/py-babel${MODPY_FLA
textproc/py-alabaster${MODPY_FLAVOR} \
textproc/py-docutils${MODPY_FLAVOR} \
textproc/py-pygments${MODPY_FLAVOR} \
- textproc/py-sphinx_rtd_theme${MODPY_FLAVOR}>=0.4.3 \
textproc/py-snowballstemmer${MODPY_FLAVOR} \
www/py-jinja2${MODPY_FLAVOR}
BUILD_DEPENDS =${RUN_DEPENDS}
Index: productivity/vdirsyncer/Makefile
===
RCS file: /cvs/ports/productivity/vdirsyncer/Makefile,v
retrieving revision 1.15
diff -u -p -u -r1.15 Makefile
--- productivity/vdirsyncer/Makefile27 Nov 2020 01:59:28 - 1.15
+++ productivity/vdirsyncer/Makefile1 Dec 2020 05:26:33 -
@@ -4,7 +4,7 @@ COMMENT = synchronize calendars and con
MODPY_EGG_VERSION =0.16.8
DISTNAME = vdirsyncer-${MODPY_EGG_VERSION}
-REVISION = 0
+REVISION = 1
CATEGORIES = productivity
@@ -24,6 +24,7 @@ MODPY_PYTEST =Yes
MODPY_PYTEST_ARGS =tests/
BUILD_DEPENDS =textproc/py-sphinx${MODPY_FLAVOR}>=1.4.8p5 \
+ textproc/py-sphinx_rtd_theme${MODPY_FLAVOR}>=0.4.3 \
devel/py-setuptools_scm${MODPY_FLAVOR} \
${RUN_DEPENDS}
Re: [New] devel/re2
Stuart Henderson writes: > Could you add a patch to set that to what's needed on your machine please, > and a comment in the Makefile pointing at it? So just yesterday I finally got around to migrating my dev box to better hardware, and on that machine it now passes with room to spare with the default time limit. I've added a comment to the Makefile noting why there may be a timeout (tarball attached). re2.tgz Description: Binary data
fix castor build
Fix castor build, apps is present twice in the coping of images.
Index: Makefile
===
RCS file: /cvs/ports/www/castor/Makefile,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 Makefile
--- Makefile29 Nov 2020 18:53:50 - 1.2
+++ Makefile1 Dec 2020 02:23:36 -
@@ -4,7 +4,7 @@ COMMENT=graphical browser for plain-te
V= 0.8.16
DISTNAME= castor-${V}
-REVISION= 0
+REVISION= 1
DIST_SUBDIR= castor
DISTFILES= ${V}${EXTRACT_SUFX}
@@ -39,7 +39,7 @@ post-install:
.for i in 16 32 64 128
${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/$ix$i/apps
${INSTALL_DATA} ${WRKSRC}/data/org.typed-hole.castor-$i.png \
- ${PREFIX}/share/icons/hicolor/apps/$ix$i/apps/
+ ${PREFIX}/share/icons/hicolor/$ix$i/apps/
.endfor
${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/scalable/apps
${INSTALL_DATA} ${WRKSRC}/data/org.typed-hole.castor.svg \
Re: [UPDATE] graphics/blender -> 2.90.1
"Dimitri Karamazov" writes: > OpenVDB would be very nice to have, it only supports CPU rendering. > But I will be wary of OpenSubdiv since it seems to supports only modern GPUs. > I'm not sure if it will work on OpenBSD. Did you test them both? yes. OpenSubdiv will actually run single-threaded I think. it has several (optional) parallel backends, including CUDA, OpenCL, OpenMP, and TBB. obviously the only one relevant for OpenBSD is TBB, and I successfully built and tested with that. > https://archive.blender.org/wiki/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv/ > OpenSubdiv requires decent video card and latest video drivers installed. > Recommended video cards are AMD and NVidia, few years old max. Not sure why they say that, as mentioned above OpenSubdiv will actually run with no backend. but OpenSubdiv really is quite necessary in blender 2.81+ as the entire subdivision backend seems to have been moved to opensubdiv, there is no native blender subsurf code anymore. so any sort of subdivision needs opensubdiv, it's not really an "add-on" thing like it was in pre 2.8x, even though you can build blender without it. Cheers, Andrea
[Update] databases/leveldb: 1.21 -> 1.22
The attached diff updates databases/leveldb to the latest version
(1.22).
The changelog can be viewed here:
https://github.com/google/leveldb/releases/tag/1.22
It seems the previous version (1.21) introduced a CMake build. But the
OpenBSD port had not yet adopted it. Here, I've updated the port to the
latest version and converted it to use the CMake build - which
drastically simplifies the port Makefile. More to the point, it seems
that the "old way" of building has been ripped out of this version.
The port contains the following changes:
- Conversion to use the new CMake build
- A convenience patch to the CMakeLists.txt to make sure the
documentation ends up in the right place on install.
- Removal of some old stuff related to the old way of building the library.
- General formatting stuff in the Makefile - there was an over-length
line, detected by portcheck.
- Add myself as maintainer.
The port has been tested on amd64. configure, build, fake, package,
install and uninstall all work. The test suite passes 100%.
A quick grep turns up no dependent ports.
Suggestions and comments welcome.
Cheers,
Ash
diff --git a/databases/leveldb/Makefile b/databases/leveldb/Makefile
index cf6320ce74b..8831f06deb6 100644
--- a/databases/leveldb/Makefile
+++ b/databases/leveldb/Makefile
@@ -1,40 +1,30 @@
# $OpenBSD: Makefile,v 1.20 2019/07/12 20:43:53 sthen Exp $
-#'atomic_pointer.h: error Please implement AtomicPointer for this platform' on other archs
-ONLY_FOR_ARCHS = i386 amd64
+#'atomic_pointer.h: error Please implement AtomicPointer for this
+# platform' on other archs
+ONLY_FOR_ARCHS= i386 amd64
-COMMENT = fast key-value storage library
+COMMENT= fast key-value storage library
+CATEGORIES= databases devel
+GH_ACCOUNT= google
+GH_PROJECT= leveldb
+GH_TAGNAME= 1.22
-GH_ACCOUNT = google
-GH_PROJECT = leveldb
-GH_TAGNAME = v1.20
+SHARED_LIBS= leveldb 3.0 # 0.0
-SHARED_LIBS += leveldb 2.0 # 0.0
-
-CATEGORIES = databases devel
+MAINTAINER= Ashton Fagg
# BSD3
-PERMIT_PACKAGE = Yes
-
-MAKE_ENV = CC="${CC}" CXX="${CXX}" OPT="${CXXFLAGS}" \
- SHARED_VERSION_MAJOR=${LIBleveldb_VERSION:R} \
- SHARED_VERSION_MINOR=${LIBleveldb_VERSION:E}
-
-USE_GMAKE = Yes
+PERMIT_PACKAGE= Yes
-TEST_TARGET = check
+WANTLIB= ${COMPILER_LIBCXX} m pthread
-DOC = ${PREFIX}/share/doc/leveldb/
+# C++11
+COMPILER= base-clang ports-gcc
+MODULES= devel/cmake
-do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/include/leveldb
- ${INSTALL_DATA} ${WRKSRC}/include/leveldb/* ${PREFIX}/include/leveldb
- ${INSTALL_DATA} ${WRKSRC}/out-static/*.a \
- ${PREFIX}/lib
- ${INSTALL_DATA} ${WRKSRC}/out-shared/libleveldb.so.${LIBleveldb_VERSION} \
- ${PREFIX}/lib/libleveldb.so.${LIBleveldb_VERSION}
- ${INSTALL_DATA_DIR} ${DOC}
- ${INSTALL_DATA} ${WRKSRC}/doc/*.md ${DOC}
- ${INSTALL_DATA} ${WRKSRC}/LICENSE ${DOC}
+CONFIGURE_ARGS+= -DBUILD_SHARED_LIBS=on \
+ -DLEVELDB_INSTALL=on \
+ -DLEVELDB_BUILD_BENCHMARKS=off
.include
diff --git a/databases/leveldb/distinfo b/databases/leveldb/distinfo
index abd336a865d..ae4cf1d8f0c 100644
--- a/databases/leveldb/distinfo
+++ b/databases/leveldb/distinfo
@@ -1,2 +1,2 @@
-SHA256 (leveldb-1.20.tar.gz) = 9avotbIJwvNlYLdfMs5hQS85opIvcEWudkosIzNbZmQ=
-SIZE (leveldb-1.20.tar.gz) = 223141
+SHA256 (leveldb-1.22.tar.gz) = VUI8rJ4zBvSpUCxzigAeSjOdGjj/vudXLUoH1dY5SbI=
+SIZE (leveldb-1.22.tar.gz) = 239365
diff --git a/databases/leveldb/patches/patch-CMakeLists_txt b/databases/leveldb/patches/patch-CMakeLists_txt
new file mode 100644
index 000..06c01609581
--- /dev/null
+++ b/databases/leveldb/patches/patch-CMakeLists_txt
@@ -0,0 +1,22 @@
+$OpenBSD$
+
+This adds the install logic for the documentation. Keeps the Makefile nice and tidy.
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
CMakeLists.txt
+@@ -448,4 +448,14 @@ if(LEVELDB_INSTALL)
+ "${PROJECT_BINARY_DIR}/leveldbConfigVersion.cmake"
+ DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake/leveldb"
+ )
++ install(
++FILES
++ "${PROJECT_SOURCE_DIR}/doc/impl.md"
++ "${PROJECT_SOURCE_DIR}/doc/index.md"
++ "${PROJECT_SOURCE_DIR}/doc/log_format.md"
++ "${PROJECT_SOURCE_DIR}/doc/table_format.md"
++ "${PROJECT_SOURCE_DIR}/LICENSE"
++ DESTINATION "${CMAKE_INSTALL_PREFIX}/share/doc/leveldb"
++ )
++
+ endif(LEVELDB_INSTALL)
diff --git a/databases/leveldb/patches/patch-Makefile b/databases/leveldb/patches/patch-Makefile
deleted file mode 100644
index 292fb04cba0..000
--- a/databases/leveldb/patches/patch-Makefile
+++ /dev/null
@@ -1,29 +0,0 @@
-$OpenBSD: patch-Makefile,v 1.5 2018/01/03 20:25:25 rsadowski Exp $
-
-Allow SHARED_MAJOR and SHARED_MINOR to be overridden.
-This doesn't affect kMajorVersion and kMinorVersion in db.h,
-but nothing uses them anyway.
-
-Index: Makefile
Makefile.orig
-+++ Makefile
-@@ -121,8 +121,8 @@ SHARED_LIBS = $(SHARED_LIB1)
- SHARED_MEMENVLIB = $(SHARED_OUTDIR)/libmemenv.a
- else
- # Update db.h if you change these.
Re: emulators/spike: mark BROKEN-powerpc, (possibly) fix on other BE_ARCHS
On Tue, Dec 01, 2020 at 12:28:24AM +0100, Charlene Wendling wrote:
> Hi,
> > http://build-failures.rhaalovely.net/powerpc/2020-11-11/emulators/spike.log
> > http://build-failures.rhaalovely.net/mips64/2020-11-22/emulators/spike.log
> (sparc64 needs a COMPILER line)
> I've just casted the unsigned long argument to uint32_t. Creating a
> new overloaded swap() function seems redundant to me (correct me if
> i'm wrong) and upstream code for fesvr/syscall.cc totally changed.
> While here, i've added a COMPILER line for sparc64, that complains
> about C++11.
> This builds on macppc, but the runtime is wrong. Per upstream's readme:
> (spike allocates 2GB by default, reduces to 100MB)
> $ riscv64-unknown-elf-gcc hello.c -o hello
> $ spike -l -m100 \
> /usr/local/riscv64-unknown-elf/riscv64-unknown-elf/bin/pk hello
> [... lots of assembly ...]
> core 0: exception trap_instruction_page_fault, epc 0x800019c4
> I did not try an update to the latest GitHub sources. It would be better
> for someone who really makes an extensive use of it to do the update.
> This diff has been tested on amd64, where it works as expected.
> Comments/feedback are welcome,
> Charlène.
This _does_ fix the build for sparc64. (I had tried the COMPILER line before
but didn't have the patch. The two in combination are the answer).
ok kmos
--Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/emulators/spike/Makefile,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 Makefile
> --- Makefile 5 Nov 2020 08:35:16 - 1.3
> +++ Makefile 30 Nov 2020 23:07:12 -
> @@ -4,12 +4,14 @@
> # address space is not large enough
> NOT_FOR_ARCHS = i386
>
> +BROKEN-powerpc= internal 'exception trap_instruction_page_fault' at
> runtime
> +
> COMMENT =RISC-V ISA simulator
>
> GH_COMMIT = ec6ded4f2f21cb7aef4a0b31b82b91ef91d22c36
> GH_ACCOUNT = riscv
> GH_PROJECT = riscv-isa-sim
> -REVISION = 0
> +REVISION = 1
>
> DISTNAME = spike-1.0.0
>
> @@ -21,6 +23,9 @@ MAINTAINER =Jasper Lievisse Adriaanse <
> PERMIT_PACKAGE = Yes
>
> WANTLIB += ${COMPILER_LIBCXX} c m
> +
> +# C++11
> +COMPILER = base-clang ports-gcc
>
> BUILD_DEPENDS = devel/dtc
>
> Index: patches/patch-fesvr_syscall_cc
> ===
> RCS file: patches/patch-fesvr_syscall_cc
> diff -N patches/patch-fesvr_syscall_cc
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-fesvr_syscall_cc30 Nov 2020 23:07:12 -
> @@ -0,0 +1,17 @@
> +$OpenBSD$
> +
> +There is no overloaded function for swap(unsigned long). big endian archs
> +fix for: riscv/byteorder.h:22:58: error: call to 'swap' is ambiguous
> +
> +Index: fesvr/syscall.cc
> +--- fesvr/syscall.cc.orig
> fesvr/syscall.cc
> +@@ -300,7 +300,7 @@ reg_t syscall_t::sys_getmainvars(reg_t pbuf, reg_t lim
> + {
> + std::vector args = htif->target_args();
> + std::vector words(args.size() + 3);
> +- words[0] = to_le(args.size());
> ++ words[0] = to_le((uint32_t) args.size());
> + words[args.size()+1] = 0; // argv[argc] = NULL
> + words[args.size()+2] = 0; // envp[0] = NULL
> +
Re: Disable awesome-wm docs
On 2020-11-30 20:48, Rafael Sadowski wrote:
On Mon Nov 30, 2020 at 10:08:29AM -0500, Kurt Mosiejczuk wrote:
On Sat, Nov 28, 2020 at 01:10:44AM -0700, Rafael Sadowski wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by:rsadow...@cvs.openbsd.org 2020/11/28 01:10:44
> Modified files:
>x11/awesome: Makefile distinfo
>x11/awesome/patches: patch-awesomeConfig_cmake
> patch-awesomerc_lua
> patch-docs_06-appearance_md_lua
> patch-lib_awful_completion_lua
> patch-lib_awful_util_lua
> patch-lib_beautiful_init_lua
> patch-lib_gears_filesystem_lua
> patch-lib_menubar_icon_theme_lua
> patch-lib_naughty_core_lua
> patch-themes_default_theme_lua
> patch-themes_xresources_theme_lua
> patch-utils_awesome-client
>x11/awesome/pkg: PLIST
> Added files:
>x11/awesome/patches: patch-docs_05-awesomerc_md_lua
> patch-docs_07-my-first-awesome_md
> patch-docs_90-FAQ_md
> patch-docs_build_rules_index_lua
> patch-lib_menubar_utils_lua
> patch-tests_examples_CMakeLists_txt
> patch-tests_examples_runner_sh
> patch-themes_gtk_theme_lua
> Removed files:
>x11/awesome/patches: patch-CMakeLists_txt
> Log message:
> Update awesome to 4.3
This fails to build on at least sparc64 with
Error:
/usr/obj/ports/awesome-4.3/fake-sparc64/usr/local/share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_encapsulation.svg
does not exist
Thanks for the quick report. I see no reason why this file is missed on
!amd64. We can disable docs again:
Index: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 Makefile
--- Makefile28 Nov 2020 08:10:44 - 1.111
+++ Makefile30 Nov 2020 19:46:15 -
@@ -5,6 +5,7 @@ COMMENT=highly configurable framework
V= 4.3
DISTNAME= awesome-${V}
CATEGORIES=x11
+REVISION= 0
HOMEPAGE= https://awesomewm.org/
@@ -36,8 +37,7 @@ LIB_DEPENDS= ${MODLUA_LIB_DEPENDS} \
MODLUA_BUILD_DEPENDS= devel/lua-lgi
-BUILD_DEPENDS= devel/lualdoc \
- devel/pango \
+BUILD_DEPENDS= devel/pango \
graphics/ImageMagick \
textproc/asciidoctor
@@ -47,6 +47,7 @@ RUN_DEPENDS= misc/rlwrap \
shells/bash
CONFIGURE_ARGS=-DCOMPRESS_MANPAGES=off \
+ -DGENERATE_DOC=OFF \
-DSYSCONFDIR=${SYSCONFDIR}
NO_TEST= Yes
@@ -61,11 +62,6 @@ pre-configure:
${WRKSRC}/lib/beautiful/init.lua \
${WRKSRC}/lib/awful/util.lua \
${WRKSRC}/lib/awful/completion.lua \
- ${WRKSRC}/docs/build_rules_index.lua \
- ${WRKSRC}/docs/90-FAQ.md \
- ${WRKSRC}/docs/07-my-first-awesome.md \
- ${WRKSRC}/docs/06-appearance.md.lua \
- ${WRKSRC}/docs/05-awesomerc.md.lua \
${WRKSRC}/utils/awesome-client \
${WRKSRC}/themes/xresources/theme.lua \
${WRKSRC}/themes/gtk/theme.lua \
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/awesome/pkg/PLIST,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 PLIST
--- pkg/PLIST 28 Nov 2020 08:10:44 - 1.18
+++ pkg/PLIST 30 Nov 2020 19:46:15 -
@@ -305,332 +305,6 @@ share/doc/awesome/00-authors.md
share/doc/awesome/01-readme.md
share/doc/awesome/02-contributing.md
share/doc/awesome/LICENSE
-share/doc/awesome/doc/
-share/doc/awesome/doc/classes/
-share/doc/awesome/doc/classes/awful.button.html
-share/doc/awesome/doc/classes/awful.keygrabber.html
-share/doc/awesome/doc/classes/awful.popup.html
-share/doc/awesome/doc/classes/awful.titlebar.html
-share/doc/awesome/doc/classes/awful.tooltip.html
-share/doc/awesome/doc/classes/awful.wibar.html
-share/doc/awesome/doc/classes/awful.widget.button.html
-share/doc/awesome/doc/classes/awful.widget.calendar_popup.html
-share/doc/awesome/doc/classes/awful.widget.clienticon.html
-share/doc/awesome/doc/classes/awful.widget.common.html
-share/doc/awesome/doc/classes/awful.widget.keyboardlayout.html
-share/doc/awesome/doc/classes/awful.widget.launcher.html
-share/doc/awesome/doc/classes/awful.widget.layoutbox.html
-share/doc/awesome/doc/classes/awful.widget.layoutlist.html
-share/doc/awesome/doc/classes/awful.widget.only_on_screen.html
Re: CVS: cvs.openbsd.org: ports
On Wed, Nov 25, 2020 at 08:31:56PM -0700, Jonathan Matthew wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: jmatt...@cvs.openbsd.org2020/11/25 20:31:56
> Log message:
> Import rebar3-3.13.2 - "the official build tool for Erlang"
> ok jasper@
> Status:
> Vendor Tag: jmatthew
> Release Tags: jmatthew_20201126
> N ports/devel/rebar3/Makefile
> N ports/devel/rebar3/distinfo
> N ports/devel/rebar3/patches/patch-bootstrap
> N ports/devel/rebar3/patches/patch-src_rebar_prv_escriptize_erl
> N
> ports/devel/rebar3/patches/patch-_build_default_lib_relx_priv_templates_bin
> N ports/devel/rebar3/patches/patch-rebar_config
> N
> ports/devel/rebar3/patches/patch-_build_default_lib_relx_priv_templates_extended_bin
> N ports/devel/rebar3/pkg/DESCR
> N ports/devel/rebar3/pkg/PLIST
> No conflicts created by this import
This fails on sparc64 with:
escript: exception throw: {error,
{rebar_file_utils,
{bad_term_file,"/root/.config/rebar3/rebar.config",
eacces}}}
in function rebar_file_utils:try_consult/1 (src/rebar_file_utils.erl, line 67
)
in call from rebar_config:consult_file/1 (src/rebar_config.erl, line 212)
in call from rebar_utils:get_http_vars/1 (src/rebar_utils.erl, line 910)
in call from rebar_utils:set_httpc_options/0 (src/rebar_utils.erl, line 920)
in call from rebar3:init_config/0 (src/rebar3.erl, line 201)
in call from rebar3:run/1 (src/rebar3.erl, line 100)
===> Exiting devel/rebar3 with an error
I don't see the package available for amd64 on any mirrors either. I suspect
this doesn't build on any arch.
--Kurt
Re: Disable awesome-wm docs
On Mon, Nov 30, 2020 at 08:48:33PM +0100, Rafael Sadowski wrote:
> > This fails to build on at least sparc64 with
> > Error:
> > /usr/obj/ports/awesome-4.3/fake-sparc64/usr/local/share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_encapsulation.svg
> > does not exist
> Thanks for the quick report. I see no reason why this file is missed on
> !amd64. We can disable docs again:
This fixes the build on sparc64. ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/awesome/Makefile,v
> retrieving revision 1.111
> diff -u -p -u -p -r1.111 Makefile
> --- Makefile 28 Nov 2020 08:10:44 - 1.111
> +++ Makefile 30 Nov 2020 19:46:15 -
> @@ -5,6 +5,7 @@ COMMENT= highly configurable framework
> V= 4.3
> DISTNAME=awesome-${V}
> CATEGORIES= x11
> +REVISION=0
>
> HOMEPAGE=https://awesomewm.org/
>
> @@ -36,8 +37,7 @@ LIB_DEPENDS=${MODLUA_LIB_DEPENDS} \
>
> MODLUA_BUILD_DEPENDS=devel/lua-lgi
>
> -BUILD_DEPENDS= devel/lualdoc \
> - devel/pango \
> +BUILD_DEPENDS= devel/pango \
> graphics/ImageMagick \
> textproc/asciidoctor
>
> @@ -47,6 +47,7 @@ RUN_DEPENDS=misc/rlwrap \
> shells/bash
>
> CONFIGURE_ARGS= -DCOMPRESS_MANPAGES=off \
> + -DGENERATE_DOC=OFF \
> -DSYSCONFDIR=${SYSCONFDIR}
>
> NO_TEST= Yes
> @@ -61,11 +62,6 @@ pre-configure:
> ${WRKSRC}/lib/beautiful/init.lua \
> ${WRKSRC}/lib/awful/util.lua \
> ${WRKSRC}/lib/awful/completion.lua \
> - ${WRKSRC}/docs/build_rules_index.lua \
> - ${WRKSRC}/docs/90-FAQ.md \
> - ${WRKSRC}/docs/07-my-first-awesome.md \
> - ${WRKSRC}/docs/06-appearance.md.lua \
> - ${WRKSRC}/docs/05-awesomerc.md.lua \
> ${WRKSRC}/utils/awesome-client \
> ${WRKSRC}/themes/xresources/theme.lua \
> ${WRKSRC}/themes/gtk/theme.lua \
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/x11/awesome/pkg/PLIST,v
> retrieving revision 1.18
> diff -u -p -u -p -r1.18 PLIST
> --- pkg/PLIST 28 Nov 2020 08:10:44 - 1.18
> +++ pkg/PLIST 30 Nov 2020 19:46:15 -
> @@ -305,332 +305,6 @@ share/doc/awesome/00-authors.md
> share/doc/awesome/01-readme.md
> share/doc/awesome/02-contributing.md
> share/doc/awesome/LICENSE
> -share/doc/awesome/doc/
> -share/doc/awesome/doc/classes/
> -share/doc/awesome/doc/classes/awful.button.html
> -share/doc/awesome/doc/classes/awful.keygrabber.html
> -share/doc/awesome/doc/classes/awful.popup.html
> -share/doc/awesome/doc/classes/awful.titlebar.html
> -share/doc/awesome/doc/classes/awful.tooltip.html
> -share/doc/awesome/doc/classes/awful.wibar.html
> -share/doc/awesome/doc/classes/awful.widget.button.html
> -share/doc/awesome/doc/classes/awful.widget.calendar_popup.html
> -share/doc/awesome/doc/classes/awful.widget.clienticon.html
> -share/doc/awesome/doc/classes/awful.widget.common.html
> -share/doc/awesome/doc/classes/awful.widget.keyboardlayout.html
> -share/doc/awesome/doc/classes/awful.widget.launcher.html
> -share/doc/awesome/doc/classes/awful.widget.layoutbox.html
> -share/doc/awesome/doc/classes/awful.widget.layoutlist.html
> -share/doc/awesome/doc/classes/awful.widget.only_on_screen.html
> -share/doc/awesome/doc/classes/awful.widget.prompt.html
> -share/doc/awesome/doc/classes/awful.widget.taglist.html
> -share/doc/awesome/doc/classes/awful.widget.tasklist.html
> -share/doc/awesome/doc/classes/awful.widget.textclock.html
> -share/doc/awesome/doc/classes/awful.widget.watch.html
> -share/doc/awesome/doc/classes/button.html
> -share/doc/awesome/doc/classes/client.html
> -share/doc/awesome/doc/classes/drawable.html
> -share/doc/awesome/doc/classes/gears.cache.html
> -share/doc/awesome/doc/classes/gears.matrix.html
> -share/doc/awesome/doc/classes/gears.object.html
> -share/doc/awesome/doc/classes/gears.timer.html
> -share/doc/awesome/doc/classes/key.html
> -share/doc/awesome/doc/classes/menubar.icon_theme.html
> -share/doc/awesome/doc/classes/menubar.index_theme.html
> -share/doc/awesome/doc/classes/screen.html
> -share/doc/awesome/doc/classes/signals.html
> -share/doc/awesome/doc/classes/tag.html
> -share/doc/awesome/doc/classes/wibox.container.arcchart.html
> -share/doc/awesome/doc/classes/wibox.container.background.html
> -share/doc/awesome/doc/classes/wibox.container.constraint.html
> -share/doc/awesome/doc/classes/wibox.container.margin.html
> -share/doc/awesome/doc/classes/wibox.container.mirror.html
> -share/doc/awesome/doc/classes/wibox.container.place.html
> -share/doc/awesome/doc/classes/wibox.container.radialprogressbar.html
>
emulators/spike: mark BROKEN-powerpc, (possibly) fix on other BE_ARCHS
Hi,
> http://build-failures.rhaalovely.net/powerpc/2020-11-11/emulators/spike.log
> http://build-failures.rhaalovely.net/mips64/2020-11-22/emulators/spike.log
(sparc64 needs a COMPILER line)
I've just casted the unsigned long argument to uint32_t. Creating a
new overloaded swap() function seems redundant to me (correct me if
i'm wrong) and upstream code for fesvr/syscall.cc totally changed.
While here, i've added a COMPILER line for sparc64, that complains
about C++11.
This builds on macppc, but the runtime is wrong. Per upstream's readme:
(spike allocates 2GB by default, reduces to 100MB)
$ riscv64-unknown-elf-gcc hello.c -o hello
$ spike -l -m100 \
/usr/local/riscv64-unknown-elf/riscv64-unknown-elf/bin/pk hello
[... lots of assembly ...]
core 0: exception trap_instruction_page_fault, epc 0x800019c4
I did not try an update to the latest GitHub sources. It would be better
for someone who really makes an extensive use of it to do the update.
This diff has been tested on amd64, where it works as expected.
Comments/feedback are welcome,
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/emulators/spike/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- Makefile5 Nov 2020 08:35:16 - 1.3
+++ Makefile30 Nov 2020 23:07:12 -
@@ -4,12 +4,14 @@
# address space is not large enough
NOT_FOR_ARCHS =i386
+BROKEN-powerpc=internal 'exception trap_instruction_page_fault' at
runtime
+
COMMENT = RISC-V ISA simulator
GH_COMMIT =ec6ded4f2f21cb7aef4a0b31b82b91ef91d22c36
GH_ACCOUNT = riscv
GH_PROJECT = riscv-isa-sim
-REVISION = 0
+REVISION = 1
DISTNAME = spike-1.0.0
@@ -21,6 +23,9 @@ MAINTAINER = Jasper Lievisse Adriaanse <
PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} c m
+
+# C++11
+COMPILER = base-clang ports-gcc
BUILD_DEPENDS =devel/dtc
Index: patches/patch-fesvr_syscall_cc
===
RCS file: patches/patch-fesvr_syscall_cc
diff -N patches/patch-fesvr_syscall_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-fesvr_syscall_cc 30 Nov 2020 23:07:12 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+There is no overloaded function for swap(unsigned long). big endian archs
+fix for: riscv/byteorder.h:22:58: error: call to 'swap' is ambiguous
+
+Index: fesvr/syscall.cc
+--- fesvr/syscall.cc.orig
fesvr/syscall.cc
+@@ -300,7 +300,7 @@ reg_t syscall_t::sys_getmainvars(reg_t pbuf, reg_t lim
+ {
+ std::vector args = htif->target_args();
+ std::vector words(args.size() + 3);
+- words[0] = to_le(args.size());
++ words[0] = to_le((uint32_t) args.size());
+ words[args.size()+1] = 0; // argv[argc] = NULL
+ words[args.size()+2] = 0; // envp[0] = NULL
+
Re: [new] net/kristall (gopher/gemini navigator)
On Fri, Nov 27, 2020 at 11:24:57PM +0100, Solene Rapenne wrote: > hi, > > this is a new port for Kristall > https://github.com/MasterQ32/kristall > > A GUI program to navigate into Gemini and Gopher > spaces (or even http). > > I patched a git call which happened at every clang > call which was pretty bad. I've done some light testing on amd64, and it seems to build and run well. At first I thought that gopher and finger-support was disabled at compile time, but there are runtime settings in the application to enable them. Only gemini is enabled by default. Kinda neat, so you can enable only what you will use. /Magnus
Re: [UPDATE] graphics/blender -> 2.90.1
On Mon, November 30, 2020 10:37, Stuart Henderson wrote:
> On 2020/11/30 08:48, Dimitri Karamazov wrote:
>
>> From Stuart Henderson
>>
>>> update to blender-2.91.0, from Dimitri Karamazov (and earlier work on 2.81
>>> from Andrea Fleckenstein). Dimitri takes maintainer, agreed with
>>> pascal@. I added a dep on graphics/potrace because blender picks it up at
>>> build time if present.
>>
>> WANTLIB += ${MODPY_WANTLIB}
>> WANTLIB += ${COMPILER_LIBCXX} GL GLEW Half-2_5 Iex-2_5 IlmImf-2_5
>> WANTLIB += IlmThread-2_5 Imath-2_5 OpenColorIO OpenImageIO SDL2
>> WANTLIB += X11 Xfixes Xi Xrender Xxf86vm avcodec avdevice avformat
>> WANTLIB += avutil boost_atomic-mt boost_chrono-mt boost_date_time-mt
>> WANTLIB += boost_filesystem-mt boost_regex-mt boost_system-mt
>> WANTLIB += boost_thread-mt c fftw3 freetype jpeg m openal openjp2
>> WANTLIB += png potrace sndfile swscale tbb tiff tinyxml util yaml-cpp
>> WANTLIB += z
>>
>>
>> Hmm..., opencolorio, yaml-cpp, tinyxml, sndfile are present in wantlibs as
>> well.
>> I guess those should be added to LIB_DEPENDS. yaml-cpp and tinyxml are
>> recursively pulled by opencolorio, so adding just add will be okay? Also
>> opencolorio is pulled in by openimageio which is listed in LIB_DEPENDS.
>>
>> So the question is are recursively pulled dependencies to be listed in
>> LIB_DEPENDS?
>>
>
> No they are not, unless they are also used directly by the port itself.
>
>
>
Removed -DWITH_RAYOPTIMIZATIONS since it doesn't exist, rest of the options
are auto-detected. gflags is not a dependency anymore. I've added opencolorio,
libsndfile and sdl2 to LIB_DEPENDS since they are direct dependencies.
Arranged LIB_DEPENDS in alpha order hope that is fine. I think it is fine to
expect SSE. Mininum requirements for blender is a 64-bit CPU. What do you think?
https://www.blender.org/download/requirements/
Build,run tested on amd64.
Index: Makefile
===
RCS file: /cvs/ports/graphics/blender/Makefile,v
retrieving revision 1.99
diff -u -p -r1.99 Makefile
--- Makefile29 Nov 2020 19:57:01 - 1.99
+++ Makefile30 Nov 2020 16:24:06 -
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile,v 1.99 2020/11/29 19:57:01 sthen Exp $
-ONLY_FOR_ARCHS = amd64 i386
+ONLY_FOR_ARCHS = amd64
COMMENT = 3D creation software
@@ -39,30 +39,27 @@ MODPY_VERSION = ${MODPY_DEFAULT_VERSION_
CONFIGURE_ARGS = -DPYTHON_INCLUDE_DIR="${MODPY_INCDIR}" \
-DPYTHON_VERSION=${MODPY_VERSION} \
- -DWITH_CODEC_FFMPEG=ON \
-DWITH_INTERNATIONAL=OFF \
- -DWITH_RAYOPTIMIZATION=OFF \
- -DWITH_OPENCOLORIO=ON \
- -DWITH_OPENMP=OFF \
-DWITH_SYSTEM_GLEW=ON \
- -DWITH_CPU_SSE=OFF \
-DWITH_CYCLES_EMBREE=OFF \
-DWITH_JACK=OFF
-BUILD_DEPENDS =devel/gflags \
- math/py-numpy${MODPY_FLAVOR}
-LIB_DEPENDS = graphics/png \
- graphics/jpeg \
- graphics/glew \
- graphics/openexr \
- graphics/tiff \
+BUILD_DEPENDS = math/py-numpy${MODPY_FLAVOR}
+LIB_DEPENDS = audio/libsndfile \
+ audio/openal \
devel/boost \
+ devel/sdl2 \
devel/tbb \
- audio/openal \
- graphics/openjp2 \
graphics/ffmpeg \
+ graphics/glew \
+ graphics/jpeg \
+ graphics/opencolorio \
+ graphics/openexr \
graphics/openimageio \
+ graphics/openjp2 \
+ graphics/png \
graphics/potrace \
+ graphics/tiff \
math/fftw3 \
${MODPY_LIB_DEPENDS}
RUN_DEPENDS = devel/desktop-file-utils \
blender-diff
Description: Binary data
Re: gcc --static produces programs that crash
On Sun, 29 Nov 2020 22:45:27 -0500
George Koehler wrote:
> This diff might fix the problem. This diff was in one of my ports
> trees, but I forgot about it
The diff that I sent yesterday was bad. Please don't build it (and
I'm sorry if you started building it). Adding a REVISION = 0 below
the REVISION = 1 is obviously wrong.
I'm working on making a better diff. --George
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/gcc/8/Makefile,v
> retrieving revision 1.36
> diff -u -p -r1.36 Makefile
> --- Makefile 14 Nov 2020 00:00:39 - 1.36
> +++ Makefile 30 Nov 2020 03:24:18 -
> @@ -36,6 +36,8 @@ PKGNAME-objc = gobjc-${FULL_PKGVERSION}
> PKGNAME-ada = gnat-${FULL_PKGVERSION}
> PKGSPEC-main = gcc->=8,<9
>
> +REVISION = 0
> +
> SHARED_LIBS =estdc++ 19.0 \
> gfortran8.0 \
> objc8.0 \
> Index: patches/patch-gcc_config_aarch64_openbsd_h
> ===
> RCS file: /cvs/ports/lang/gcc/8/patches/patch-gcc_config_aarch64_openbsd_h,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-gcc_config_aarch64_openbsd_h
> --- patches/patch-gcc_config_aarch64_openbsd_h20 May 2019 14:59:05
> - 1.2
> +++ patches/patch-gcc_config_aarch64_openbsd_h30 Nov 2020 03:24:18
> -
> @@ -57,7 +57,7 @@ Index: gcc/config/aarch64/openbsd.h
> + %{!static:-Bdynamic} \
> + %{rdynamic:-export-dynamic} \
> + %{assert*} \
> -+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}} \
> ++ %{!shared:%{!static:%{!-dynamic-linker:-dynamic-linker
> /usr/libexec/ld.so}}} \
> + -L/usr/lib"
> +
> +#define OPENBSD_ENTRY_POINT "__start"
> Index: patches/patch-gcc_config_alpha_openbsd_h
> ===
> RCS file: /cvs/ports/lang/gcc/8/patches/patch-gcc_config_alpha_openbsd_h,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-gcc_config_alpha_openbsd_h
> --- patches/patch-gcc_config_alpha_openbsd_h 20 May 2019 14:59:05 -
> 1.2
> +++ patches/patch-gcc_config_alpha_openbsd_h 30 Nov 2020 03:24:18 -
> @@ -2,7 +2,7 @@ $OpenBSD: patch-gcc_config_alpha_openbsd
> Index: gcc/config/alpha/openbsd.h
> --- gcc/config/alpha/openbsd.h.orig
> +++ gcc/config/alpha/openbsd.h
> -@@ -19,6 +19,28 @@ along with GCC; see the file COPYING3. If not see
> +@@ -19,6 +19,28 @@ along with GCC; see the file COPYING3.
>
> /* Controlling the compilation driver. */
>
> @@ -17,7 +17,7 @@ Index: gcc/config/alpha/openbsd.h
> + %{!static:-Bdynamic} \
> + %{rdynamic:-export-dynamic} \
> + %{assert*} \
> -+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}}"
> ++ %{!shared:%{!static:%{!-dynamic-linker:-dynamic-linker
> /usr/libexec/ld.so}}}"
> +
> +/* As an elf system, we need crtbegin/crtend stuff. */
> +#undef STARTFILE_SPEC
> @@ -31,7 +31,7 @@ Index: gcc/config/alpha/openbsd.h
> /* run-time target specifications */
> #define TARGET_OS_CPP_BUILTINS()\
> do {\
> -@@ -28,18 +50,27 @@ along with GCC; see the file COPYING3. If not see
> +@@ -28,18 +50,27 @@ along with GCC; see the file COPYING3.
>
> /* Layout of source language data types. */
>
> @@ -54,9 +54,9 @@ Index: gcc/config/alpha/openbsd.h
>
> #undef WCHAR_TYPE_SIZE
> #define WCHAR_TYPE_SIZE 32
> -+
> +
> +#undef WINT_TYPE
> +#define WINT_TYPE "int"
> -
> ++
>
> #define LOCAL_LABEL_PREFIX "."
> Index: patches/patch-gcc_config_arm_openbsd_h
> ===
> RCS file: /cvs/ports/lang/gcc/8/patches/patch-gcc_config_arm_openbsd_h,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-gcc_config_arm_openbsd_h
> --- patches/patch-gcc_config_arm_openbsd_h20 May 2019 14:59:05 -
> 1.2
> +++ patches/patch-gcc_config_arm_openbsd_h30 Nov 2020 03:24:18 -
> @@ -82,7 +82,7 @@ Index: gcc/config/arm/openbsd.h
> + %{!static:-Bdynamic} \
> + %{rdynamic:-export-dynamic} \
> + %{assert*} \
> -+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}} \
> ++ %{!shared:%{!static:%{!-dynamic-linker:-dynamic-linker
> /usr/libexec/ld.so}}} \
> + %{!nostdlib:-L/usr/lib}"
> +#endif
> +
> Index: patches/patch-gcc_config_i386_openbsdelf_h
> ===
> RCS file: /cvs/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-gcc_config_i386_openbsdelf_h
> --- patches/patch-gcc_config_i386_openbsdelf_h8 Aug 2020 16:48:48
> - 1.3
> +++ patches/patch-gcc_config_i386_openbsdelf_h30 Nov 2020 03:24:18
> -
> @@ -3,26 +3,29 @@ $OpenBSD: patch-gcc_config_i386_openbsde
> Index: gcc/config/i386/openbsdelf.h
> --- gcc/config/i386/openbsdelf.h.orig
> +++
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/11/30 12:52:14 Modified files: sysutils/toad : Makefile distinfo Log message: Update to toad-1.12.
Disable awesome-wm docs
On Mon Nov 30, 2020 at 10:08:29AM -0500, Kurt Mosiejczuk wrote:
> On Sat, Nov 28, 2020 at 01:10:44AM -0700, Rafael Sadowski wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: rsadow...@cvs.openbsd.org 2020/11/28 01:10:44
>
> > Modified files:
> > x11/awesome: Makefile distinfo
> > x11/awesome/patches: patch-awesomeConfig_cmake
> > patch-awesomerc_lua
> > patch-docs_06-appearance_md_lua
> > patch-lib_awful_completion_lua
> > patch-lib_awful_util_lua
> > patch-lib_beautiful_init_lua
> > patch-lib_gears_filesystem_lua
> > patch-lib_menubar_icon_theme_lua
> > patch-lib_naughty_core_lua
> > patch-themes_default_theme_lua
> > patch-themes_xresources_theme_lua
> > patch-utils_awesome-client
> > x11/awesome/pkg: PLIST
> > Added files:
> > x11/awesome/patches: patch-docs_05-awesomerc_md_lua
> > patch-docs_07-my-first-awesome_md
> > patch-docs_90-FAQ_md
> > patch-docs_build_rules_index_lua
> > patch-lib_menubar_utils_lua
> > patch-tests_examples_CMakeLists_txt
> > patch-tests_examples_runner_sh
> > patch-themes_gtk_theme_lua
> > Removed files:
> > x11/awesome/patches: patch-CMakeLists_txt
>
> > Log message:
> > Update awesome to 4.3
>
> This fails to build on at least sparc64 with
>
> Error:
> /usr/obj/ports/awesome-4.3/fake-sparc64/usr/local/share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_encapsulation.svg
> does not exist
>
Thanks for the quick report. I see no reason why this file is missed on
!amd64. We can disable docs again:
Index: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 Makefile
--- Makefile28 Nov 2020 08:10:44 - 1.111
+++ Makefile30 Nov 2020 19:46:15 -
@@ -5,6 +5,7 @@ COMMENT=highly configurable framework
V= 4.3
DISTNAME= awesome-${V}
CATEGORIES=x11
+REVISION= 0
HOMEPAGE= https://awesomewm.org/
@@ -36,8 +37,7 @@ LIB_DEPENDS= ${MODLUA_LIB_DEPENDS} \
MODLUA_BUILD_DEPENDS= devel/lua-lgi
-BUILD_DEPENDS= devel/lualdoc \
- devel/pango \
+BUILD_DEPENDS= devel/pango \
graphics/ImageMagick \
textproc/asciidoctor
@@ -47,6 +47,7 @@ RUN_DEPENDS= misc/rlwrap \
shells/bash
CONFIGURE_ARGS=-DCOMPRESS_MANPAGES=off \
+ -DGENERATE_DOC=OFF \
-DSYSCONFDIR=${SYSCONFDIR}
NO_TEST= Yes
@@ -61,11 +62,6 @@ pre-configure:
${WRKSRC}/lib/beautiful/init.lua \
${WRKSRC}/lib/awful/util.lua \
${WRKSRC}/lib/awful/completion.lua \
- ${WRKSRC}/docs/build_rules_index.lua \
- ${WRKSRC}/docs/90-FAQ.md \
- ${WRKSRC}/docs/07-my-first-awesome.md \
- ${WRKSRC}/docs/06-appearance.md.lua \
- ${WRKSRC}/docs/05-awesomerc.md.lua \
${WRKSRC}/utils/awesome-client \
${WRKSRC}/themes/xresources/theme.lua \
${WRKSRC}/themes/gtk/theme.lua \
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/awesome/pkg/PLIST,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 PLIST
--- pkg/PLIST 28 Nov 2020 08:10:44 - 1.18
+++ pkg/PLIST 30 Nov 2020 19:46:15 -
@@ -305,332 +305,6 @@ share/doc/awesome/00-authors.md
share/doc/awesome/01-readme.md
share/doc/awesome/02-contributing.md
share/doc/awesome/LICENSE
-share/doc/awesome/doc/
-share/doc/awesome/doc/classes/
-share/doc/awesome/doc/classes/awful.button.html
-share/doc/awesome/doc/classes/awful.keygrabber.html
-share/doc/awesome/doc/classes/awful.popup.html
-share/doc/awesome/doc/classes/awful.titlebar.html
-share/doc/awesome/doc/classes/awful.tooltip.html
-share/doc/awesome/doc/classes/awful.wibar.html
-share/doc/awesome/doc/classes/awful.widget.button.html
-share/doc/awesome/doc/classes/awful.widget.calendar_popup.html
-share/doc/awesome/doc/classes/awful.widget.clienticon.html
-share/doc/awesome/doc/classes/awful.widget.common.html
-share/doc/awesome/doc/classes/awful.widget.keyboardlayout.html
-share/doc/awesome/doc/classes/awful.widget.launcher.html
-share/doc/awesome/doc/classes/awful.widget.layoutbox.html
-share/doc/awesome/doc/classes/awful.widget.layoutlist.html
[macppc] Fix archivers/innoextract
Hi, > http://build-failures.rhaalovely.net/powerpc/2020-11-11/archivers/innoextract.log The problem actually lies here: > -- Checking C++11 feature: std::unique_ptr - unsupported Run Build Command(s):/usr/local/bin/ninja cmTC_057 [...] : && /usr/ports/pobj/innoextract-1.9/bin/c++ -O2 -pipe -fmerge-all-constants -ffast-math -std=c++17 -fuse-linker-plugin -Wl,--no-undefined -Wl,--as-needed CMakeFiles/cmTC_057e6.dir/cxx11-std-unique_ptr.cpp.o -o cmTC_057e6 -Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib && : /usr/bin/../lib/libc++abi.so.3.0: undefined reference to `pthread_rwlock_rdlock' [... more undefined references to pthread symbols ...] c++: error: linker command failed with exit code 1 Innoextract then falls back to using std::auto_ptr, which is disabled by C++17. It shows up now, because -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR has been ... removed by a recent commit. The problem can be fixed by removing '-Wl,--as-needed', as often seen on ld.bfd archs. We can't supply LDFLAGS to fix this, they're removed during the test. I thought it was better to point out the real issue instead of enabling std::auto_ptr. The below diff does that and it builds and runs fine on macppc (tested with the Return to Castle Wolfenstein GOG installer). That REVISION never built there, so i have not bumped it. sparc64 builds it fine ootb, and mips64 has no boost due to libexecinfo not being built, so no other ld.bfd archs are impacted. As such, adding a NO_AS_NEEDED cmake option looks like an overkill to me. Feedback and alternatives are welcome. Charlène. Index: patches/patch-cmake_BuildType_cmake === RCS file: patches/patch-cmake_BuildType_cmake diff -N patches/patch-cmake_BuildType_cmake --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-cmake_BuildType_cmake 30 Nov 2020 16:46:37 - @@ -0,0 +1,21 @@ +$OpenBSD$ + +Index: cmake/BuildType.cmake +--- cmake/BuildType.cmake.orig cmake/BuildType.cmake +@@ -301,6 +301,15 @@ else(MSVC) + if(MACOS) + # TODO For some reason this check succeeds on macOS, but then + # flag causes the actual build to fail :( ++ elseif(CMAKE_SYSTEM_NAME STREQUAL "OpenBSD" ++ AND CMAKE_SYSTEM_PROCESSOR STREQUAL "powerpc") ++ # XXX Need a review once lld is the default linker on powerpc ++ # -Wl,--as-needed causes the std::unique_ptr test to ++ # fail due to undefined reference errors, and user ++ # supplied linker flags are removed during the test. A ++ # fallback exists, using std::auto_ptr, but it has been ++ # disabled by C++17. Use the same code as other archs ++ # instead of reenabling std::auto_ptr. + else() + # Link as few libraries as possible + # This is much easier than trying to decide which libraries are needed for each
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mill...@cvs.openbsd.org 2020/11/30 10:04:34 Modified files: security/sudo : Makefile distinfo Log message: Update to sudo 1.9.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/11/30 09:46:44 Modified files: x11/worker : Makefile distinfo Log message: Update to worker-4.6.0 Changelog: http://www.boomerangsworld.de/cms/worker/changes.html#org929fd48
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/30 09:34:37 Modified files: converters/k2pdfopt: Makefile converters : Makefile Log message: disable k2pdfopt in converters/Makefile, it was already marked BROKEN but it had a dep on graphics/openjpeg which has been removed, causing problems for dpb/sqlports. add some notes from my several failed attempts at updating this port to k2pdfopt/Makefile.
Re: NEW: DASM-2.20.14
On Mon, 30 Nov 2020 at 10:16:50 +0100, Benoit Lecocq wrote: > > > On 27/11/2020 09:55, Gonzalo L. Rodriguez wrote: > > Moin, > > > > Attached a port of DASM a macro assembler with support for several 8-bit > > microprocessors. > > > > https://github.com/dasm-assembler/dasm > > > > Thanks jasper@ for the help! > > > > Cheers.- > > > > ok benoit@ Thanks! > > Some tests failed with "make test" > Yes, I fixed some of them, but they are still working on it. -- - gonzalo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/11/30 08:51:49 Modified files: textproc/py-natsort: Makefile distinfo Log message: update to natsort-7.1.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/11/30 08:49:48 Modified files: x11/xkbcommon : Makefile distinfo Log message: update to libxkbcommon-1.0.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/11/30 08:47:53 Modified files: devel/py-r2pipe: Makefile distinfo Log message: update to r2pipe-1.5.3
Re: [New] devel/re2
Stuart Henderson writes: > Could you add a patch to set that to what's needed on your machine > please, and a comment in the Makefile pointing at it? Certainly. I'll get back to you sometime in the next day or two once I have some more time.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/11/30 08:46:11 Modified files: sysutils/borgmatic: Makefile distinfo Log message: update to borgmatic-1.5.12
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/11/30 08:46:04 Modified files: sysutils/rofi : Makefile distinfo Log message: update to rofi-1.6.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/11/30 08:44:36 Modified files: x11/gnome/eog-plugins: Makefile distinfo Log message: update to eog-plugins-3.26.6
Re: [New] devel/re2
On 2020/11/30 10:20, Ashton Fagg wrote: > Stuart Henderson writes: > > > Generally looks good, I do see a timeout on one of the test though, > > do you get the same? > > Yep, same problem here with the default setting. There is a setting that > can be adjusted in the CMakeLists to make it so that the timeout is > longer, but it's hard to say exactly one should set that to. > > I mentioned that in the original mail I sent that I didn't want to make > assumptions about it because I wasn't sure what the best trade-off was, > so any guidance would be appreciated. > > Ash > Could you add a patch to set that to what's needed on your machine please, and a comment in the Makefile pointing at it?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/11/30 08:41:56 Modified files: mail/greyscanner: Makefile mail/greyscanner/pkg: PLIST Log message: Fix MASTER_SITE and delete HOMEPAGE for now. OK sthen@
Re: [New] devel/re2
Stuart Henderson writes: > Generally looks good, I do see a timeout on one of the test though, > do you get the same? Yep, same problem here with the default setting. There is a setting that can be adjusted in the CMakeLists to make it so that the timeout is longer, but it's hard to say exactly one should set that to. I mentioned that in the original mail I sent that I didn't want to make assumptions about it because I wasn't sure what the best trade-off was, so any guidance would be appreciated. Ash
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2020/11/30 08:15:01 Modified files: audio/libopenmpt: Makefile distinfo Log message: Update libopenmpt to 0.5.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2020/11/30 08:14:05 Modified files: textproc/miller: Makefile distinfo Log message: Update miller to 5.10.0. Notable changes: - Switch to using GH_ directives to fetch the distfile, release tarball does not include the man page anymore - Add a post-install target to install the man page
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: tra...@cvs.openbsd.org 2020/11/30 08:10:46 Modified files: cad: Makefile Log message: add dxf2gcode
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: tra...@cvs.openbsd.org 2020/11/30 08:10:23 Log message: Import cad/dxf2gcode DXF2GCODE is a tool for converting 2D (dxf, pdf, ps) drawings to CNC machine compatible GCode. Tweaks sthen@, additional patch and ok paco@ Status: Vendor Tag: tracey Release Tags: tracey_20201130 N ports/cad/dxf2gcode/Makefile N ports/cad/dxf2gcode/distinfo N ports/cad/dxf2gcode/pkg/DESCR N ports/cad/dxf2gcode/pkg/PLIST N ports/cad/dxf2gcode/patches/patch-make_py_uic_py N ports/cad/dxf2gcode/patches/patch-make_tr_py N ports/cad/dxf2gcode/patches/patch-dxf2gcode_globals_config_py No conflicts created by this import
Re: CVS: cvs.openbsd.org: ports
On Sat, Nov 28, 2020 at 01:10:44AM -0700, Rafael Sadowski wrote: > CVSROOT: /cvs > Module name: ports > Changes by: rsadow...@cvs.openbsd.org 2020/11/28 01:10:44 > Modified files: > x11/awesome: Makefile distinfo > x11/awesome/patches: patch-awesomeConfig_cmake >patch-awesomerc_lua >patch-docs_06-appearance_md_lua >patch-lib_awful_completion_lua >patch-lib_awful_util_lua >patch-lib_beautiful_init_lua >patch-lib_gears_filesystem_lua >patch-lib_menubar_icon_theme_lua >patch-lib_naughty_core_lua >patch-themes_default_theme_lua >patch-themes_xresources_theme_lua >patch-utils_awesome-client > x11/awesome/pkg: PLIST > Added files: > x11/awesome/patches: patch-docs_05-awesomerc_md_lua >patch-docs_07-my-first-awesome_md >patch-docs_90-FAQ_md >patch-docs_build_rules_index_lua >patch-lib_menubar_utils_lua >patch-tests_examples_CMakeLists_txt >patch-tests_examples_runner_sh >patch-themes_gtk_theme_lua > Removed files: > x11/awesome/patches: patch-CMakeLists_txt > Log message: > Update awesome to 4.3 This fails to build on at least sparc64 with Error: /usr/obj/ports/awesome-4.3/fake-sparc64/usr/local/share/doc/awesome/doc/images/AUTOGEN_wibox_widget_progressbar_encapsulation.svg does not exist --Kurt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/11/30 07:59:44 Modified files: sysutils/deja-dup: Makefile distinfo sysutils/deja-dup/patches: patch-meson_build Log message: Update to deja-dup-42.6.
Re: OpenBSD, Rails and core-js/node-sass
Hola! On Mon, Nov 30, 2020, at 2:54 AM, Peter Aarhus wrote: > > On 2020-11-28 13:34:21 Solene wrote: > > > > I already had this error with yarn, the fix is > > > > ln -s /usr/local/bin/node /tmp/node > > > > I can't explain why. It works because node is trying to find the full path to itself when called from /tmp. Since things can’t determine their path on OpenBSD node does it’s best but comes up short. I have a patched yarn in openbsd-wip that works around this - but I have negative interest in moving forward with it :P Here is an attempted fix in node: https://github.com/nodejs/node/pull/18543 Not sure why it stopped working. > > That did it, thank you so much. I'll let the others know. > > Hope you have a wonderful day! > > All the best, > Pete > >
Re: OpenBSD, Rails and core-js/node-sass
> On 2020-11-28 13:34:21 Solene wrote: > > I already had this error with yarn, the fix is > > ln -s /usr/local/bin/node /tmp/node > > I can't explain why. That did it, thank you so much. I'll let the others know. Hope you have a wonderful day! All the best, Pete
Re: [UPDATE] graphics/blender -> 2.90.1
>From Stuart Henderson
> update to blender-2.91.0, from Dimitri Karamazov (and earlier work on
> 2.81 from Andrea Fleckenstein). Dimitri takes maintainer, agreed with
> pascal@. I added a dep on graphics/potrace because blender picks it up
> at build time if present.
WANTLIB += ${MODPY_WANTLIB}
WANTLIB += ${COMPILER_LIBCXX} GL GLEW Half-2_5 Iex-2_5 IlmImf-2_5
WANTLIB += IlmThread-2_5 Imath-2_5 OpenColorIO OpenImageIO SDL2
WANTLIB += X11 Xfixes Xi Xrender Xxf86vm avcodec avdevice avformat
WANTLIB += avutil boost_atomic-mt boost_chrono-mt boost_date_time-mt
WANTLIB += boost_filesystem-mt boost_regex-mt boost_system-mt
WANTLIB += boost_thread-mt c fftw3 freetype jpeg m openal openjp2
WANTLIB += png potrace sndfile swscale tbb tiff tinyxml util yaml-cpp
WANTLIB += z
Hmm..., opencolorio, yaml-cpp, tinyxml, sndfile are present in wantlibs as well.
I guess those should be added to LIB_DEPENDS. yaml-cpp and tinyxml are
recursively pulled by opencolorio, so adding just add will be okay? Also
opencolorio is pulled in by openimageio which is listed in LIB_DEPENDS.
So the question is are recursively pulled dependencies to be listed in
LIB_DEPENDS?
>From Andrea
> This works for me on amd64. I have some local wip ports for OpenSubdiv
> and and OpenVDB and I'm able to build blender against these, which is
> very helpful.
OpenVDB would be very nice to have, it only supports CPU rendering.
But I will be wary of OpenSubdiv since it seems to supports only modern GPUs.
I'm not sure if it will work on OpenBSD. Did you test them both?
https://archive.blender.org/wiki/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv/
OpenSubdiv requires decent video card and latest video drivers installed.
Recommended video cards are AMD and NVidia, few years old max.
https://www.blendernation.com/2015/09/22/using-opensubdiv-in-blender-2-76/
https://www.blendernation.com/2020/03/04/daily-blender-tip-openvdb-quickstart/
If and when you deem fit to release OpenSubdiv and OpenVDB, one at a time
ofcourse,
just cc me.
regards,
Dimitri
Re: sane-backends, libusb and LIBUSB_ERROR_NOT_SUPPORTED in obsd_cancel_transfer()
On Mon, Nov 30, 2020 at 09:32:37AM +, Mikolaj Kucharski wrote:
> Hi,
>
> I have very unreliable results when I use my Canon MG3250 all-in-one
> printer, scanner for scanning.
>
> Most of the scanning attempts with scanimage fail:
>
> scanimage: sane_read: Error during device I/O
>
> I spent some time with it and from what I can see scanning fails when
> libusb_cancel_transfer() from libusb returns code -12. Here is example
> of failed scan:
>
> export LIBUSB_DEBUG=4
> scanimage --device-name pixma:04A91762_860FE4 \
> --format png --mode gray --resolution 300 \
> --output-file scan.png
>
>
> [ 2.024756] [0008d272] libusb: debug [libusb_alloc_transfer] transfer
> 0xbc317170e50
> [ 2.024768] [0008d272] libusb: debug [libusb_submit_transfer] transfer
> 0xbc317170e50
> [ 2.024814] [0008d272] libusb: debug [obsd_submit_transfer]
> [ 2.024887] [0008d272] libusb: debug [_access_endpoint] endpoint 9 mode 0
> [ 3.033570] [0008d272] libusb: debug [libusb_get_next_timeout] first timeout
> already expired
> [ 3.033620] [0008d272] libusb: debug [libusb_cancel_transfer] transfer
> 0xbc317170e50
> [ 3.033634] [0008d272] libusb: debug [obsd_cancel_transfer]
> [ 3.033645] [0008d272] libusb: error [libusb_cancel_transfer] cancel transfer
> failed error -12
> [ 3.033658] [0008d272] libusb: warning [handle_timeout] async cancel failed
> -12 errno=6
> [ 3.033690] [0008d272] libusb: debug [libusb_get_next_timeout] no URB with
> timeout or all handled by OS; no timeout!
> [ 3.033730] [0008d272] libusb: debug [libusb_handle_events_timeout_completed]
> doing our own event handling
> [ 3.033799] [0008d272] libusb: debug [handle_events] poll() 1 fds with
> timeout in 6ms
> [ 3.033822] [0008d272] libusb: debug [handle_events] poll() returned 1
> [ 3.033858] [0008d272] libusb: debug [handle_events] caught a fish on the
> event pipe
> [ 3.033872] [0008d272] libusb: debug [usbi_handle_transfer_completion]
> transfer 0xbc317170e50 has callback 0xbc2c960d550
> [ 3.033899] [0008d272] libusb: debug [sync_transfer_cb] actual_length=0
> [ 3.033947] [0008d272] libusb: debug [libusb_free_transfer] transfer
> 0xbc317170e50
>
>
> Here is the same command like above, but scanning succeeds:
>
> [ 1.974116] [0003cf01] libusb: debug [libusb_alloc_transfer] transfer
> 0x9aeef9a1550
> [ 1.974138] [0003cf01] libusb: debug [libusb_submit_transfer] transfer
> 0x9aeef9a1550
> [ 1.974153] [0003cf01] libusb: debug [obsd_submit_transfer]
> [ 1.974190] [0003cf01] libusb: debug [_access_endpoint] endpoint 9 mode 0
> [ 2.384033] [0003cf01] libusb: debug [libusb_get_next_timeout] next timeout
> in 0.590119s
> [ 2.384079] [0003cf01] libusb: debug [libusb_handle_events_timeout_completed]
> doing our own event handling
> [ 2.384111] [0003cf01] libusb: debug [handle_events] poll() 1 fds with
> timeout in 591ms
> [ 2.384131] [0003cf01] libusb: debug [handle_events] poll() returned 1
> [ 2.384141] [0003cf01] libusb: debug [handle_events] caught a fish on the
> event pipe
> [ 2.384152] [0003cf01] libusb: debug [usbi_handle_transfer_completion]
> transfer 0x9aeef9a1550 has callback 0x9aec4f75550
> [ 2.384190] [0003cf01] libusb: debug [sync_transfer_cb] actual_length=32
> [ 2.384261] [0003cf01] libusb: debug [libusb_free_transfer] transfer
> 0x9aeef9a1550
>
>
> In failed scenario, actual_length=0 which then SANE interpreters
> as SANE_STATUS_EOF (file sanei/sanei_usb.c, function
> sanei_usb_read_int(), condition read_size == 0).
>
> In successful scenario, actual_length=32 and SANE moves along and
> scanning finishes successfully.
>
> I'm kinda stuck here, as I'm not sure how to handle this. In practical
> terms, scanning is extremely unrelaible and code most of the time hits
> cancel transfer failed error -12 (LIBUSB_ERROR_NOT_SUPPORTED) condition.
>
> Any tips how to tackle this?
Looking at the code for the libusb's openbsd backend, it's evident
that the code simply does not support transfer cancellation:
int
obsd_cancel_transfer(struct usbi_transfer *itransfer)
{
usbi_dbg("");
return (LIBUSB_ERROR_NOT_SUPPORTED);
}
(see /usr/ports/pobj/libusb1-1.0.23/libusb-1.0.23/libusb/os/openbsd_usb.c)
So you could either determine what's causing the transfer to be cancelled
and whether this condition could be fixed (wrong transfer timeout values?),
or implement cancellation of transfers in the above function so that libusb
may continue and perhaps retry the transfer.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/11/30 05:00:49 Modified files: textproc/pecl-yaml: Makefile distinfo Log message: update to pecl-yaml-2.2.0
Re: cyrus-imapd upstreamed patches and improvements
Antoine, Stuart,
cyrus-imapd 3.2.5 was just released.
I'm attaching an updated patch that also includes the SHA256 and the version
bump + everything else from my initial mail, which is needed to accommodate the
cross-platform changes and upstreamed port's patches that are included in this
release (and the explanations for each change are in my initial mail).
Regards,
Anatoli
diff --git Makefile Makefile
index bfee0b835b1..d738a1ca91b 100644
--- Makefile
+++ Makefile
@@ -4,7 +4,7 @@ PORTROACH= limitw:1,even
COMMENT= Cyrus IMAP server
-V= 3.2.4
+V= 3.2.5
DISTNAME= cyrus-imapd-${V}
SHARED_LIBS += cyrus 0.0 # 0.0
diff --git distinfo distinfo
index 2c825c1a02a..367870468fe 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (cyrus-imapd-3.2.4.tar.gz) =
UWEmLDgqpaeMKLGk9eolRQne4eet6DH37JsUB4+0LyM=
-SIZE (cyrus-imapd-3.2.4.tar.gz) = 12270070
+SHA256 (cyrus-imapd-3.2.5.tar.gz) =
zDhqdU4kOJtSr4NzdrO7YFW+pwV/U+yHq8oGqOjWlWM=
+SIZE (cyrus-imapd-3.2.5.tar.gz) = 12237158
diff --git Makefile Makefile
index c7fb05ebcee..bfee0b835b1 100644
--- Makefile
+++ Makefile
@@ -39,8 +39,7 @@ LIB_DEPENDS= databases/sqlite3 \
CONFIGURE_STYLE= gnu
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib" \
- cyrus_cv_sse42=no
+ LDFLAGS="-L${LOCALBASE}/lib"
CONFIGURE_ARGS=--bindir=${PREFIX}/cyrus/bin \
--libexec=${PREFIX}/cyrus/libexec \
--sbindir=${PREFIX}/cyrus/sbin \
@@ -48,17 +47,12 @@ CONFIGURE_ARGS= --bindir=${PREFIX}/cyrus/bin \
--with-cyrus-user=_cyrus \
--with-syslogfacility=MAIL \
--without-chardet \
- --without-cld2 \
--without-sphinx-build \
--without-zeroskip \
--disable-gssapi \
--enable-autocreate \
--enable-idled \
- --enable-murder \
- --enable-nntp
-
-# XXX FLAVOR
-CONFIGURE_ARGS += --without-snmp
+ --enable-murder
# XXX notyet; FLAVOR
CONFIGURE_ARGS += --without-clamav \
diff --git patches/patch-imap_conversations_c patches/patch-imap_conversations_c
deleted file mode 100644
index 9eab9396e0d..000
--- patches/patch-imap_conversations_c
+++ /dev/null
@@ -1,16 +0,0 @@
-$OpenBSD: patch-imap_conversations_c,v 1.3 2020/05/14 12:26:39 ajacoutot Exp $
-
-64 bit time_t
-
-Index: imap/conversations.c
imap/conversations.c.orig
-+++ imap/conversations.c
-@@ -567,7 +567,7 @@ static int _conversations_set_key(struct conversations
- if (i) buf_putc(, ',');
- buf_printf(, CONV_FMT, cid);
- }
--buf_printf(, " %lu", stamp);
-+buf_printf(, " %lld", stamp);
-
- r = cyrusdb_store(state->db,
- key, keylen,
diff --git patches/patch-imap_fud_c patches/patch-imap_fud_c
deleted file mode 100644
index cc6a8f8d327..000
--- patches/patch-imap_fud_c
+++ /dev/null
@@ -1,17 +0,0 @@
-$OpenBSD: patch-imap_fud_c,v 1.2 2020/08/28 09:53:04 ajacoutot Exp $
-
-Index: imap/fud.c
imap/fud.c.orig
-+++ imap/fud.c
-@@ -96,8 +96,10 @@ static void send_reply(struct sockaddr *sfrom, socklen
-
- static int soc = 0; /* inetd (master) has handed us the port as stdin */
-
--#ifndef MAXDOMNAME
-+#ifndef MAXLOGNAME
- #define MAXLOGNAME 16 /* should find out for real */
-+#endif
-+#ifndef MAXDOMNAME
- #define MAXDOMNAME 20 /* should find out for real */
- #endif
-
diff --git patches/patch-imap_mailbox_c patches/patch-imap_mailbox_c
deleted file mode 100644
index 0793441fdfa..000
--- patches/patch-imap_mailbox_c
+++ /dev/null
@@ -1,34 +0,0 @@
-$OpenBSD: patch-imap_mailbox_c,v 1.19 2020/05/30 10:09:27 ajacoutot Exp $
-
-64 bit time_t
-
-Index: imap/mailbox.c
imap/mailbox.c.orig
-+++ imap/mailbox.c
-@@ -2899,7 +2899,7 @@ static uint32_t crc_basic(const struct mailbox *mailbo
- flagcrc ^= crc32_cstring(buf);
- }
-
--snprintf(buf, sizeof(buf), "%u " MODSEQ_FMT " %lu (%u) %lu %s",
-+snprintf(buf, sizeof(buf), "%u " MODSEQ_FMT " %lld (%u) %lld %s",
- record->uid, record->modseq, record->last_updated,
- flagcrc,
- record->internaldate,
-@@ -2959,7 +2959,7 @@ static uint32_t crc_virtannot(struct mailbox *mailbox,
- }
-
- if (record->savedate && mailbox->i.minor_version >= 15) {
--buf_printf(, "%lu", record->savedate);
-+buf_printf(, "%lld", record->savedate);
- crc ^= crc_annot(record->uid, IMAP_ANNOT_NS "savedate", "", );
- buf_reset();
- }
-@@ -4520,7 +4520,7 @@ static int mailbox_index_repack(struct mailbox *mailbo
- if (mailbox->i.minor_version >= 15
Re: [New] devel/re2
On 2020/11/29 15:23, Ashton Fagg wrote: > Fixed. > > Update tarball attached. Sorry for the slow response. Generally looks good, I do see a timeout on one of the test though, do you get the same? ===> Regression tests for re2-20201101 [0/1] cd /usr/obj/ports/re2-20201101/build-amd64 && /usr/local/bin/ctest --force-new-ctest-process --exclude-regex "CMake.FileDownload|CTestTestUpload|RunCMake.ctest_submit" Test project /usr/obj/ports/re2-20201101/build-amd64 Start 1: charclass_test 1/20 Test #1: charclass_test ... Passed0.01 sec Start 2: compile_test 2/20 Test #2: compile_test . Passed0.01 sec Start 3: filtered_re2_test 3/20 Test #3: filtered_re2_test Passed0.01 sec Start 4: mimics_pcre_test 4/20 Test #4: mimics_pcre_test . Passed0.01 sec Start 5: parse_test 5/20 Test #5: parse_test ... Passed0.01 sec Start 6: possible_match_test 6/20 Test #6: possible_match_test .. Passed6.54 sec Start 7: re2_test 7/20 Test #7: re2_test . Passed0.20 sec Start 8: re2_arg_test 8/20 Test #8: re2_arg_test . Passed0.01 sec Start 9: regexp_test 9/20 Test #9: regexp_test .. Passed0.04 sec Start 10: required_prefix_test 10/20 Test #10: required_prefix_test . Passed0.01 sec Start 11: search_test 11/20 Test #11: search_test .. Passed0.54 sec Start 12: set_test 12/20 Test #12: set_test . Passed0.01 sec Start 13: simplify_test 13/20 Test #13: simplify_test Passed0.01 sec Start 14: string_generator_test 14/20 Test #14: string_generator_test Passed0.01 sec Start 15: dfa_test 15/20 Test #15: dfa_test . Passed 48.52 sec Start 16: exhaustive1_test 16/20 Test #16: exhaustive1_test . Passed 1411.48 sec Start 17: exhaustive2_test 17/20 Test #17: exhaustive2_test . Passed 513.83 sec Start 18: exhaustive3_test 18/20 Test #18: exhaustive3_test . Passed 209.72 sec Start 19: exhaustive_test 19/20 Test #19: exhaustive_test ..***Timeout 1500.05 sec Start 20: random_test 20/20 Test #20: random_test .. Passed 178.77 sec 95% tests passed, 1 tests failed out of 20 Total Test time (real) = 3869.77 sec The following tests FAILED: 19 - exhaustive_test (Timeout) Errors while running CTest FAILED: CMakeFiles/test.util cd /usr/obj/ports/re2-20201101/build-amd64 && /usr/local/bin/ctest --force-new-ctest-process --exclude-regex "CMake.FileDownload|CTestTestUpload|RunCMake.ctest_submit" ninja: build stopped: subcommand failed. *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:46 'do-test': @cd /usr/obj/ports/re2-20201101/build-amd64 && exec /usr/bin/env -i LIB...) *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2967 '/usr/obj/ports/re2-20201101/build-amd64/.test_done': @cd /usr/ports/mystuff...) *** Error 2 in /usr/ports/mystuff/textproc/re2 (/usr/ports/infrastructure/mk/bsd.port.mk:2597 'test': @lock=re2-20201101; export _LOCKS_HEL...)
Re: [UPDATE] graphics/blender -> 2.90.1
On 2020/11/30 08:48, Dimitri Karamazov wrote:
> From Stuart Henderson
> > update to blender-2.91.0, from Dimitri Karamazov (and earlier work on
> > 2.81 from Andrea Fleckenstein). Dimitri takes maintainer, agreed with
> > pascal@. I added a dep on graphics/potrace because blender picks it up
> > at build time if present.
>
> WANTLIB += ${MODPY_WANTLIB}
> WANTLIB += ${COMPILER_LIBCXX} GL GLEW Half-2_5 Iex-2_5 IlmImf-2_5
> WANTLIB += IlmThread-2_5 Imath-2_5 OpenColorIO OpenImageIO SDL2
> WANTLIB += X11 Xfixes Xi Xrender Xxf86vm avcodec avdevice avformat
> WANTLIB += avutil boost_atomic-mt boost_chrono-mt boost_date_time-mt
> WANTLIB += boost_filesystem-mt boost_regex-mt boost_system-mt
> WANTLIB += boost_thread-mt c fftw3 freetype jpeg m openal openjp2
> WANTLIB += png potrace sndfile swscale tbb tiff tinyxml util yaml-cpp
> WANTLIB += z
>
> Hmm..., opencolorio, yaml-cpp, tinyxml, sndfile are present in wantlibs as
> well.
> I guess those should be added to LIB_DEPENDS. yaml-cpp and tinyxml are
> recursively pulled by opencolorio, so adding just add will be okay? Also
> opencolorio is pulled in by openimageio which is listed in LIB_DEPENDS.
>
> So the question is are recursively pulled dependencies to be listed in
> LIB_DEPENDS?
No they are not, unless they are also used directly by the port itself.
sane-backends, libusb and LIBUSB_ERROR_NOT_SUPPORTED in obsd_cancel_transfer()
Hi, I have very unreliable results when I use my Canon MG3250 all-in-one printer, scanner for scanning. Most of the scanning attempts with scanimage fail: scanimage: sane_read: Error during device I/O I spent some time with it and from what I can see scanning fails when libusb_cancel_transfer() from libusb returns code -12. Here is example of failed scan: export LIBUSB_DEBUG=4 scanimage --device-name pixma:04A91762_860FE4 \ --format png --mode gray --resolution 300 \ --output-file scan.png [ 2.024756] [0008d272] libusb: debug [libusb_alloc_transfer] transfer 0xbc317170e50 [ 2.024768] [0008d272] libusb: debug [libusb_submit_transfer] transfer 0xbc317170e50 [ 2.024814] [0008d272] libusb: debug [obsd_submit_transfer] [ 2.024887] [0008d272] libusb: debug [_access_endpoint] endpoint 9 mode 0 [ 3.033570] [0008d272] libusb: debug [libusb_get_next_timeout] first timeout already expired [ 3.033620] [0008d272] libusb: debug [libusb_cancel_transfer] transfer 0xbc317170e50 [ 3.033634] [0008d272] libusb: debug [obsd_cancel_transfer] [ 3.033645] [0008d272] libusb: error [libusb_cancel_transfer] cancel transfer failed error -12 [ 3.033658] [0008d272] libusb: warning [handle_timeout] async cancel failed -12 errno=6 [ 3.033690] [0008d272] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout! [ 3.033730] [0008d272] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 3.033799] [0008d272] libusb: debug [handle_events] poll() 1 fds with timeout in 6ms [ 3.033822] [0008d272] libusb: debug [handle_events] poll() returned 1 [ 3.033858] [0008d272] libusb: debug [handle_events] caught a fish on the event pipe [ 3.033872] [0008d272] libusb: debug [usbi_handle_transfer_completion] transfer 0xbc317170e50 has callback 0xbc2c960d550 [ 3.033899] [0008d272] libusb: debug [sync_transfer_cb] actual_length=0 [ 3.033947] [0008d272] libusb: debug [libusb_free_transfer] transfer 0xbc317170e50 Here is the same command like above, but scanning succeeds: [ 1.974116] [0003cf01] libusb: debug [libusb_alloc_transfer] transfer 0x9aeef9a1550 [ 1.974138] [0003cf01] libusb: debug [libusb_submit_transfer] transfer 0x9aeef9a1550 [ 1.974153] [0003cf01] libusb: debug [obsd_submit_transfer] [ 1.974190] [0003cf01] libusb: debug [_access_endpoint] endpoint 9 mode 0 [ 2.384033] [0003cf01] libusb: debug [libusb_get_next_timeout] next timeout in 0.590119s [ 2.384079] [0003cf01] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling [ 2.384111] [0003cf01] libusb: debug [handle_events] poll() 1 fds with timeout in 591ms [ 2.384131] [0003cf01] libusb: debug [handle_events] poll() returned 1 [ 2.384141] [0003cf01] libusb: debug [handle_events] caught a fish on the event pipe [ 2.384152] [0003cf01] libusb: debug [usbi_handle_transfer_completion] transfer 0x9aeef9a1550 has callback 0x9aec4f75550 [ 2.384190] [0003cf01] libusb: debug [sync_transfer_cb] actual_length=32 [ 2.384261] [0003cf01] libusb: debug [libusb_free_transfer] transfer 0x9aeef9a1550 In failed scenario, actual_length=0 which then SANE interpreters as SANE_STATUS_EOF (file sanei/sanei_usb.c, function sanei_usb_read_int(), condition read_size == 0). In successful scenario, actual_length=32 and SANE moves along and scanning finishes successfully. I'm kinda stuck here, as I'm not sure how to handle this. In practical terms, scanning is extremely unrelaible and code most of the time hits cancel transfer failed error -12 (LIBUSB_ERROR_NOT_SUPPORTED) condition. Any tips how to tackle this? -- Regards, Mikolaj
Re: [Update] lang/gnucobol : Update to 3.1
On Fri, Nov 13, 2020 at 02:20:32AM +, wen heping wrote: > Index: Makefile > === > RCS file: /cvs/ports/lang/gnucobol/Makefile,v > retrieving revision 1.4 > diff -u -p -r1.4 Makefile > --- Makefile 12 Jul 2019 20:47:18 - 1.4 > +++ Makefile 13 Nov 2020 02:11:38 - > @@ -2,8 +2,7 @@ > > COMMENT= COBOL compiler, formerly known as OpenCOBOL > > -DISTNAME = gnucobol-2.2 > -REVISION = 1 > +DISTNAME = gnucobol-3.1 > > SHARED_LIBS += cob 4.0 # 4.0 At least the library minor number must be bumped. Please read the "Shared Libraries" part of the "Special Porting Topics" section in the Porter's Handbook for more information: https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mar...@cvs.openbsd.org 2020/11/30 02:06:00 Modified files: geo/py-rasterio: Makefile distinfo Log message: Update py-rasterio to 1.1.8.
