CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/01/05 00:37:04 Modified files: x11/xfce4/libxfce4ui: Makefile distinfo Log message: x11/xfce4/libxfce4ui: update to 4.18.1 see https://mail.xfce.org/pipermail/xfce-announce/2023-January/001218.html
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2023/01/05 00:14:45 Modified files: graphics/lcms2 : Makefile distinfo Log message: graphics/lcms2: update to 2.14. see https://github.com/mm2/Little-CMS/releases/tag/lcms2.14 & https://github.com/mm2/Little-CMS/releases/tag/lcms2.13. requirement for a port of jpegxl i'm working on. tested in a bulk build by ajacoutot@, thanks !
Re: [NEW] audio/alsa-lib-1.2.8
Hi, > Unless installed in a way to make it hard to pick up accidentally (e.g. > a non-standard directory, which has its own problems) I expect the > amount of work needed to cope with this in the rest of the ports tree > is likely to be quite a lot more than that needed to port a couple of > applications from alsa to sndio. That's important. OpenBSD's standard is sndio, not alsa. I expected this alsa port to use temporary, for example; - until the application supports sndio - rescue that cannot support sndio So alsa should not be first choice on OpenBSD. How about to use PERMIT_PACKAGE=No (and PERMIT_DISTFILES=No?) to reduce install accidentaly, and install alsa suites into /usr/local/alsa or somewhere? -- SASANO Takayoshi (JG1UAA)
Re: UPDATE net/luasocket 3.0rc1p1 -> 3.1.0
Updated a couple of things.
- Use '&&' instead of ';' so that sed only executes after a successful cd.
- Needed to patch version string in src/luasocket.h, I guess I left that out for
some reason.
- Add TEST_DEPENDS so that make test only works if net/luasocket is installed.
Is this OK? Any feedback?
Index: Makefile
===
RCS file: /cvs/ports/net/luasocket/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile11 Mar 2022 19:46:18 - 1.37
+++ Makefile5 Jan 2023 03:34:48 -
@@ -1,13 +1,12 @@
COMMENT= network support for the lua language
-V= 3.0-rc1
-GH_ACCOUNT=diegonehab
+V= 3.1.0
+GH_ACCOUNT=lunarmodules
GH_PROJECT=luasocket
GH_TAGNAME=v$V
-REVISION= 1
PKGNAME= ${DISTNAME:S/-rc/rc/}
CATEGORIES=net
-HOMEPAGE= http://w3.impa.br/~diego/software/luasocket/
+HOMEPAGE= https://lunarmodules.github.io/luasocket/index.html
# MIT
PERMIT_PACKAGE=Yes
@@ -17,10 +16,6 @@ MODULES= lang/lua
FLAVORS= lua52 lua53
FLAVOR?=
-NO_TEST= Yes
-
-USE_GMAKE= Yes
-
MAKE_FILE= makefile
MAKE_FLAGS=CC_linux=${CC} \
@@ -30,20 +25,27 @@ MAKE_FLAGS= CC_linux=${CC} \
-DLUA_COMPAT_APIINTCASTS" \
LDFLAGS_linux="${LDFLAGS} -shared -fPIC -o "
-do-install:
- ${INSTALL_DATA_DIR} ${MODLUA_DATADIR}/socket ${MODLUA_DATADIR}/mime
- ${INSTALL_DATA_DIR} ${MODLUA_LIBDIR}/socket ${MODLUA_LIBDIR}/mime
+# Needed so that Unix specific components are installed.
+INSTALL_TARGET=install install-unix
+
+TEST_DEPENDS= ${FULLPKGNAME}:${BUILD_PKGPATH}
+
+# Consult ${WRKSRC}/makefile and ${WRKSRC}/test/README to make sure this test
is
+# up to date.
+do-test:
+ ${MODLUA_BIN} ${WRKSRC}/test/hello.lua
+
+# This replaces all buffer_* functions with ls_buffer_* instead.
+#
+# "luasocket defines buffer_init(); which is common enough to be defined
+# elsewhere and it is defined in mod_magnet, so you end up with a SIGSEGV.
+# So rename buffer_* funcs to ls_buffer_*."
+post-patch:
+ cd ${WRKSRC}/src && sed -i -e 's/[[:<:]]buffer_/ls_buffer_/g' ./*
+
+post-install:
${INSTALL_DATA_DIR} ${MODLUA_DOCDIR} ${MODLUA_EXAMPLEDIR}
- ${INSTALL_DATA} ${WRKSRC}/src/socket.so ${MODLUA_LIBDIR}/socket/core.so
- ${INSTALL_DATA} ${WRKSRC}/src/unix.so ${MODLUA_LIBDIR}/socket/unix.so
- ${INSTALL_DATA} ${WRKSRC}/src/mime.so ${MODLUA_LIBDIR}/mime/core.so
-.for l in ltn12 socket mime
- ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}
-.endfor
-.for l in http url tp ftp headers smtp
- ${INSTALL_DATA} ${WRKSRC}/src/$l.lua ${MODLUA_DATADIR}/socket
-.endfor
- ${INSTALL_DATA} ${WRKSRC}/doc/* ${MODLUA_DOCDIR}
+ ${INSTALL_DATA} ${WRKSRC}/docs/* ${MODLUA_DOCDIR}
${INSTALL_DATA} ${WRKSRC}/samples/* ${MODLUA_EXAMPLEDIR}
.include
Index: distinfo
===
RCS file: /cvs/ports/net/luasocket/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo25 Nov 2013 15:27:56 - 1.9
+++ distinfo5 Jan 2023 03:34:48 -
@@ -1,2 +1,2 @@
-SHA256 (luasocket-3.0-rc1.tar.gz) =
i2fZtbVF4baUdT2re9bNvCTCkPKyG6HhTHezKBfqEkk=
-SIZE (luasocket-3.0-rc1.tar.gz) = 328598
+SHA256 (luasocket-3.1.0.tar.gz) = vwM6655ivKqNAH32jBGclmQY6Mnvfk8tfpa93sqcym4=
+SIZE (luasocket-3.1.0.tar.gz) = 336542
Index: patches/patch-docs_installation_html
===
RCS file: patches/patch-docs_installation_html
diff -N patches/patch-docs_installation_html
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-docs_installation_html5 Jan 2023 03:34:48 -
@@ -0,0 +1,12 @@
+Index: docs/installation.html
+--- docs/installation.html.orig
docs/installation.html
+@@ -89,7 +89,7 @@ it should be easy to use LuaSocket. Just fire the inte
+ Lua 5.2.2 Copyright (C) 1994-2013 Lua.org, PUC-Rio
+ socket = require("socket")
+ print(socket._VERSION)
+--- LuaSocket 3.0.0
++-- LuaSocket 3.1.0
+
+
+ Each module loads their dependencies automatically, so you only need to
Index: patches/patch-makefile_dist
===
RCS file: patches/patch-makefile_dist
diff -N patches/patch-makefile_dist
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-makefile_dist 5 Jan 2023 03:34:48 -
@@ -0,0 +1,12 @@
+Index: makefile.dist
+--- makefile.dist.orig
makefile.dist
+@@ -1,7 +1,7 @@
+ #--
+ # Distribution makefile
+ #--
+-DIST = luasocket-3.0.0
++DIST = luasocket-3.1.0
+
+ TEST = \
+ test/README \
Index: patches/patch-src_buffer_c
===
RCS file:
Re: NEW: video libs libyuv and libwebm (requirements for adding hlvideo to hashlink)
On Wed, Jan 04, 2023 at 04:32:39PM -0500, Thomas Frohwein wrote:
> Hi,
>
> Two ports attached - both are for video processing/playback. I'm bringing
> them up because they are dependencies for hlvideo [1], a library which I
> would like to add to lang/hashlink as it allows running the DLC for
> Northgard, "Cross of Vidar". The libraries may be useful for other
> purposes in the future.
>
> Both ports are from Google code repo and BSD-3 licensed. I'm using the
> Github distfiles because they should remain stable, unlike the the
> tarballs that can be fetched from chromium.googlesource.com.
>
> libyuv is a fairly straightforward port. libwebm doesn't come with much
> of a description and doesn't have a usable install target. Therefore, I
> added a do-build for the libwebm port that installs the library, the
> binaries, and mkvparser head files because those are used by hlvideo.
> There are a lot more .h files, but in an odd directory structure that
> is susceptible to causing conflicts (like ${PREFIX}/include/common).
>
> I also tweaked CMakeLists.txt for libwebm to build a shared library
> because that's what's needed for hlvideo.
>
> ok? comments?
>
> [1] https://github.com/HeapsIO/hlvideo
Updated libyuv.tgz attached - it needs to explicitly link to libjpeg
which it doesn't by default.
hl:/usr/local/lib/libyuv.so.0.0: undefined symbol 'jpeg_resync_to_restart'
The issue is gone with this updated tarball.
libyuv.tgz
Description: application/tar-gz
Avoid rubygems upgrade nag message in Ruby 3.2 rubygems
This disables messages like this when trying to install a gem:
A new release of RubyGems is available: 3.4.1 - 3.4.2!
Run `gem update --system 3.4.2` to update your installation.
I'll be committing this in a couple days unless I hear objections.
Thanks,
Jeremy
Index: Makefile
===
RCS file: /cvs/ports/lang/ruby/3.2/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile26 Dec 2022 03:03:57 - 1.1.1.1
+++ Makefile5 Jan 2023 00:20:54 -
@@ -3,6 +3,7 @@ DISTNAME = ruby-${VERSION}
SHARED_LIBS = ruby32 0.0
NEXTVER = 3.3
PKGSPEC-main ?= ruby->=3.2.0,<${NEXTVER}
+REVISION-main =0
PSEUDO_FLAVORS=no_ri_docs bootstrap
# Do not build the RI docs on slow arches
Index: patches/patch-lib_rubygems_update_suggestion_rb
===
RCS file: patches/patch-lib_rubygems_update_suggestion_rb
diff -N patches/patch-lib_rubygems_update_suggestion_rb
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_rubygems_update_suggestion_rb 5 Jan 2023 00:20:54
-
@@ -0,0 +1,22 @@
+Avoid printing of nagging update message:
+
+ A new release of RubyGems is available: 3.4.1 - 3.4.2!
+ Run `gem update --system 3.4.2` to update your installation.
+
+When using the OpenBSD port, important updates to rubygems will
+be distributed via normal updates to the related ruby ports.
+
+return false while true is used instead of plain return false to
+avoid the statement not reached verbose mode warning.
+
+Index: lib/rubygems/update_suggestion.rb
+--- lib/rubygems/update_suggestion.rb.orig
lib/rubygems/update_suggestion.rb
+@@ -31,6 +31,7 @@ Run `gem update --system #{Gem.latest_rubygems_version
+ # Determines if current environment is eglible for update suggestion.
+
+ def eglible_for_update?
++return false while true
+ # explicit opt-out
+ return false if Gem.configuration[:prevent_update_suggestion]
+ return false if ENV["RUBYGEMS_PREVENT_UPDATE_SUGGESTION"]
net/qbittorrent: drop autoconf patch, use saner cmake
(this needs the python.port.mk diff I just sent.)
cmake gets the PREFIX stuff right and, imho, is easier to work with.
Qt5Svg is always REQUIRED in the global cmake file but only used in
src/app/ for Windows and macOS, so make it a build dep.
With cmake the dbus support bits are under 'if (LINUX)', so enable
explicitly to retain notification and power management support.
Both autoconf and cmake pick up and default-enable
stacktrace printing on crashes so they can be sent upstream, but only
autoconf manages to pass -libexecinfo.
I'll send patches upstream in case future updates don't solve the cmake
bits for dbus and stacktrace.
That one .png is no longer installed but shouldn't matter.
Works as before.
Feedback? Objection? OK?
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile.inc
--- Makefile.inc7 Aug 2022 09:29:21 - 1.22
+++ Makefile.inc4 Jan 2023 22:07:43 -
@@ -17,11 +17,8 @@ PERMIT_PACKAGE = Yes
MASTER_SITES ?=${MASTER_SITE_SOURCEFORGE:=qbittorrent/}
-MODULES += x11/qt5
+MODULES += devel/cmake \
+ x11/qt5
-USE_GMAKE =Yes
-
-CONFIGURE_STYLE = autoreconf
-AUTORECONF =${WRKSRC}/bootstrap.sh
-AUTOCONF_VERSION = 2.69
-AUTOMAKE_VERSION = 1.16
+# for automatic stacktraces on crash: autoconf links it, cmake does not
+CONFIGURE_ARGS += -DCMAKE_EXE_LINKER_FLAGS='${LDFLAGS} -lexecinfo'
Index: qbittorrent/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- qbittorrent/Makefile4 Jan 2023 20:01:50 - 1.20
+++ qbittorrent/Makefile4 Jan 2023 22:07:43 -
@@ -1,8 +1,8 @@
COMMENT = BitTorrent client with Qt interface
-REVISION = 1
+REVISION = 2
-WANTLIB += ${COMPILER_LIBCXX} GL Qt5Core Qt5DBus Qt5Gui Qt5Network
-WANTLIB += Qt5Sql Qt5Svg Qt5Widgets Qt5Xml boost_system-mt c crypto
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5DBus Qt5Gui Qt5Network
+WANTLIB += Qt5Sql Qt5Widgets Qt5Xml boost_system-mt c crypto
WANTLIB += execinfo m ssl torrent-rasterbar z
MODULES = lang/python
@@ -10,19 +10,14 @@ MODULES = lang/python
MODPY_BUILDDEP = No
MODPY_TESTDEP =No
+BUILD_DEPENDS += x11/qt5/qtsvg
+
LIB_DEPENDS += net/libtorrent-rasterbar \
- devel/boost \
- x11/qt5/qtsvg
+ devel/boost
RUN_DEPENDS += x11/gtk+3,-guic \
devel/desktop-file-utils
-# remove include directives which cause incorrect gmake behavior
-pre-build:
- @cd ${WRKBUILD}/src && \
- sed -ie "/^\-include/d" Makefile
-
-pre-install:
- ${SUBST_CMD} ${WRKSRC}/conf.pri
+CONFIGURE_ARGS += -DDBUS=ON
.include
Index: qbittorrent/patches/patch-conf_pri_in
===
RCS file: qbittorrent/patches/patch-conf_pri_in
diff -N qbittorrent/patches/patch-conf_pri_in
--- qbittorrent/patches/patch-conf_pri_in 11 Mar 2022 19:47:15 -
1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-Index: conf.pri.in
conf.pri.in.orig
-+++ conf.pri.in
-@@ -1,9 +1,9 @@
- # @configure_input@
-
--PREFIX = @EXPAND_PREFIX@
--BINDIR = @EXPAND_BINDIR@
--DATADIR = @EXPAND_DATADIR@
--MANPREFIX = @EXPAND_MANDIR@
-+PREFIX = ${PREFIX}
-+BINDIR = ${PREFIX}/bin
-+DATADIR = ${PREFIX}/share
-+MANPREFIX = ${PREFIX}/man
-
- QMAKE_CC = @QBT_CC@
- QMAKE_CXX = @QBT_CXX@
Index: qbittorrent/pkg/PLIST
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- qbittorrent/pkg/PLIST 8 May 2022 14:40:24 - 1.5
+++ qbittorrent/pkg/PLIST 4 Jan 2023 22:07:43 -
@@ -31,5 +31,3 @@ share/icons/hicolor/scalable/status/qbit
share/icons/hicolor/scalable/status/qbittorrent-tray.svg
share/metainfo/
share/metainfo/org.qbittorrent.qBittorrent.appdata.xml
-share/pixmaps/
-share/pixmaps/qbittorrent.png
Index: qbittorrent-nox/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- qbittorrent-nox/Makefile4 Jan 2023 20:01:50 - 1.11
+++ qbittorrent-nox/Makefile4 Jan 2023 22:07:43 -
@@ -1,6 +1,6 @@
COMMENT = BitTorrent client with web interface
PKGNAME = qbittorrent-nox-${VER}
-REVISION = 0
+REVISION = 1
WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Network Qt5Sql Qt5Xml
WANTLIB += boost_system-mt c crypto execinfo m ssl torrent-rasterbar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/01/04 14:38:01 Modified files: security/openssl-ruby-tests: Makefile distinfo security/openssl-ruby-tests/pkg: PLIST Log message: Update to openssl-ruby-tests 20230104
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/01/04 14:33:43 Modified files: emulators/qemu : Makefile distinfo emulators/qemu/patches: patch-configure patch-meson_build patch-meson_mesonbuild_compilers_cpp_py patch-plugins_meson_build patch-qga_commands-posix_c patch-qga_main_c emulators/qemu/pkg: PLIST-main Added files: emulators/qemu/patches: patch-qga_commands-bsd_c Removed files: emulators/qemu/patches: patch-audio_audio_c patch-audio_audio_template_h patch-audio_meson_build patch-audio_sndioaudio_c patch-meson_options_txt patch-qapi_audio_json patch-qemu-options_hx Log message: update to qemu-7.2.0, from Brad (maintainer)
NEW: video libs libyuv and libwebm (requirements for adding hlvideo to hashlink)
Hi,
Two ports attached - both are for video processing/playback. I'm bringing
them up because they are dependencies for hlvideo [1], a library which I
would like to add to lang/hashlink as it allows running the DLC for
Northgard, "Cross of Vidar". The libraries may be useful for other
purposes in the future.
Both ports are from Google code repo and BSD-3 licensed. I'm using the
Github distfiles because they should remain stable, unlike the the
tarballs that can be fetched from chromium.googlesource.com.
libyuv is a fairly straightforward port. libwebm doesn't come with much
of a description and doesn't have a usable install target. Therefore, I
added a do-build for the libwebm port that installs the library, the
binaries, and mkvparser head files because those are used by hlvideo.
There are a lot more .h files, but in an odd directory structure that
is susceptible to causing conflicts (like ${PREFIX}/include/common).
I also tweaked CMakeLists.txt for libwebm to build a shared library
because that's what's needed for hlvideo.
ok? comments?
[1] https://github.com/HeapsIO/hlvideo
libyuv.tgz
Description: application/tar-gz
libwebm.tgz
Description: application/tar-gz
python-module: only set do-* targets if MODPY_*DEP is true
net/qbittorrent uses python with MODPY_BUILDDEP=No MODPY_TESTDEP=No.
I've switched it to cmake and the way its Makefile.inc is now means that
lang/python comes before devel/cmake in MODULES.
I expected this to work without further tweaks since python is just RDEP
but turns out the module still sets do-build and do-install, so cmake
loses unless I manually define it first (and explain with a comment).
Is there a reason those targets are still defined?
If not, the following obvious diff makes any MODULES order work, given
MODPY_*DEP=No.
Feedback? Objection? OK?
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.178
diff -u -p -r1.178 python.port.mk
--- python.port.mk 6 Dec 2022 16:18:16 - 1.178
+++ python.port.mk 4 Jan 2023 21:16:38 -
@@ -356,13 +356,15 @@ MODPY_TEST_TARGET += ${TEST_TARGET}
# dirty way to do it with no modifications in bsd.port.mk
.if empty(CONFIGURE_STYLE)
-. if !target(do-build)
+. if !target(do-build) && \
+ ${MODPY_BUILDDEP:L} == "yes"
do-build:
@${MODPY_BUILD_TARGET}
. endif
# extra documentation or scripts should be installed via post-install
-. if !target(do-install)
+. if !target(do-install) && \
+ ${MODPY_BUILDDEP:L} == "yes"
do-install:
@${MODPY_INSTALL_TARGET}
. endif
@@ -372,6 +374,7 @@ do-install:
# (possibly with MODPY_PYTEST_ARGS pointed at test dirs/files if the automatic
# search picks up files in lib/).
. if !target(do-test) && \
+ ${MODPY_TESTDEP:L} == "yes" && \
(${MODPY_SETUPUTILS:L} == "yes" || ${MODPY_PYTEST:L} == "yes")
do-test:
@${MODPY_TEST_TARGET}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2023/01/04 14:19:29 Modified files: net/tailscale : Makefile distinfo modules.inc Log message: Update tailscale to 1.34.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/01/04 13:40:47 Modified files: lang/hashlink : Makefile distinfo lang/hashlink/patches: patch-Makefile patch-src_hl_h patch-src_std_thread_c Log message: Update to checkout from 2023-01-03. This way version 3 of Northgard can run. Also tested with other major hashlink games without issues: Dead Cells, Nuclear Blaze, Evoland Legendary Edition. Northgard DLC Cross of Vidar needs hlvideo (video.hdll library) before this can be run.
Re: Okular bug
On Fri Sep 16, 2022 at 11:48:38AM -0300, Gabriel Busch de Brito wrote: > Hello, > > I encountered a bug on okular-22.08.0: > Every time I try to save a pdf document after adding some sort of > annotation, the programm exits without saving the file, and reporting > the following error: > > kf.kio.widgets: Failed to check which JobView API is supported "The name > org.kde.kuiserver was not provi ded by any .service files" Segmentation > fault > > Mantainer CCed > > Best, > G > This should be fixed in the next kio package update to kio-5.101.0p0. Checkout the next package update or go with current ports tree.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/01/04 13:35:52 Modified files: devel/kf5/kio : Makefile Added files: devel/kf5/kio/patches: patch-src_core_slave_cpp Log message: Disable threads kio_file support for now. It's totally broken on OpenBSD. Kio has switched to threads implementation for copying (kio_copy) files. This implementation is broken under OpenBSD. Good that we can (still) disable it.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2023/01/04 13:01:51 Modified files: net/qbittorrent/qbittorrent: Makefile net/qbittorrent/qbittorrent-nox: Makefile Removed files: net/qbittorrent/qbittorrent/patches: patch-configure_ac net/qbittorrent/qbittorrent-nox/patches: patch-configure_ac Log message: Drop obsolete OpenSSL version spec fix Quoting tb: LibreSSL's pkgconfig used to announce version 1.0.0. This was bumped to 2.0.0 nearly a year ago in lib/libcrypto/generate_pkgconfig.sh r1.4 to avoid such patches. There are surely a few more diffs left in the ports tree that are no longer needed. I think the idea is to garbage collect them as they are encountered. No WANTLIB or PLIST change. OK tb
Re: net/qbittorrent: drop openssl version patch
04.01.2023 19:52, Theo Buehler пишет: > LibreSSL's pkgconfig used to announce version 1.0.0. This was bumped to > 2.0.0 nearly a year ago in lib/libcrypto/generate_pkgconfig.sh r1.4 to > avoid such patches. There are surely a few more diffs left in the ports > tree that are no longer needed. I think the idea is to garbage collect > them as they are encountered. Good to know, thanks. I'm not heading for a sweep, though, just looking into this port now.
Re: net/qbittorrent: drop openssl version patch
On Wed, Jan 04, 2023 at 07:47:09PM +, Klemens Nanni wrote: > Not sure why this was needed during import, but these days it detects > and builds just fine against LibreSSL. > -- [openssl >= 1.1.1], > -+ [openssl >= 1.0.0], LibreSSL's pkgconfig used to announce version 1.0.0. This was bumped to 2.0.0 nearly a year ago in lib/libcrypto/generate_pkgconfig.sh r1.4 to avoid such patches. There are surely a few more diffs left in the ports tree that are no longer needed. I think the idea is to garbage collect them as they are encountered.
net/qbittorrent: drop openssl version patch
Not sure why this was needed during import, but these days it detects
and builds just fine against LibreSSL.
No WANTLIB or PLIST change, works as before; bump REVISION to be clear.
Feedback? OK?
Index: qbittorrent/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- qbittorrent/Makefile13 Nov 2022 15:28:52 - 1.19
+++ qbittorrent/Makefile4 Jan 2023 19:16:31 -
@@ -1,5 +1,5 @@
COMMENT = BitTorrent client with Qt interface
-REVISION = 0
+REVISION = 1
WANTLIB += ${COMPILER_LIBCXX} GL Qt5Core Qt5DBus Qt5Gui Qt5Network
WANTLIB += Qt5Sql Qt5Svg Qt5Widgets Qt5Xml boost_system-mt c crypto
Index: qbittorrent/patches/patch-configure_ac
===
RCS file: qbittorrent/patches/patch-configure_ac
diff -N qbittorrent/patches/patch-configure_ac
--- qbittorrent/patches/patch-configure_ac 8 May 2022 14:40:24 -
1.5
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-Index: configure.ac
configure.ac.orig
-+++ configure.ac
-@@ -198,7 +198,7 @@ PKG_CHECK_MODULES(libtorrent,
- [CXXFLAGS="$libtorrent_CFLAGS $CXXFLAGS"
LIBS="$libtorrent_LIBS $LIBS"])])
-
- PKG_CHECK_MODULES(openssl,
-- [openssl >= 1.1.1],
-+ [openssl >= 1.0.0],
- [CXXFLAGS="$openssl_CFLAGS $CXXFLAGS"
- LIBS="$openssl_LIBS $LIBS"])
-
Index: qbittorrent-nox/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- qbittorrent-nox/Makefile8 May 2022 14:40:24 - 1.10
+++ qbittorrent-nox/Makefile4 Jan 2023 19:16:36 -
@@ -1,5 +1,6 @@
COMMENT = BitTorrent client with web interface
PKGNAME = qbittorrent-nox-${VER}
+REVISION = 0
WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Network Qt5Sql Qt5Xml
WANTLIB += boost_system-mt c crypto execinfo m ssl torrent-rasterbar
Index: qbittorrent-nox/patches/patch-configure_ac
===
RCS file: qbittorrent-nox/patches/patch-configure_ac
diff -N qbittorrent-nox/patches/patch-configure_ac
--- qbittorrent-nox/patches/patch-configure_ac 8 May 2022 14:40:24 -
1.5
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-Index: configure.ac
configure.ac.orig
-+++ configure.ac
-@@ -198,7 +198,7 @@ PKG_CHECK_MODULES(libtorrent,
- [CXXFLAGS="$libtorrent_CFLAGS $CXXFLAGS"
LIBS="$libtorrent_LIBS $LIBS"])])
-
- PKG_CHECK_MODULES(openssl,
-- [openssl >= 1.1.1],
-+ [openssl >= 1.0.0],
- [CXXFLAGS="$openssl_CFLAGS $CXXFLAGS"
- LIBS="$openssl_LIBS $LIBS"])
-
Re: rpi4 ffmpeg core dumps
On Jan 04 15:52:47, s...@spacehopper.org wrote: > On 2023/01/04 16:22, Jan Stary wrote: > > Hi, > > > > > My old pcengines box died and I had a rpi4 around that I spun up to > > > replace > > > it with as my network router/play machine. > > > > > > The rpi4 is working fantastic except for one thing: > > > > > > I have a webcam that I'm capturing images using fswebcam and those scripts > > > all work perfectly. > > > > > > I try to make a video of the captured images (timelapse) using ffmpeg, but > > > any invocation of ffmpeg I try dumps a core. I have tried on different > > > sets > > > of image files so I don't think it's the data coming in. > > > > > > A super simple invocation: > > > ffmpeg -y -pattern_type glob -i "image*.jpeg" all.mp4 > > > > > > After 40-50 frames results in: > > > Thread 2 received signal SIGSEGV, Segmentation fault. > > > [Switching to thread 203094] > > > 0x001527489808 in mbtree_propagate_list_neon () from > > > /usr/local/lib/libx264.so.24.0 > > > > > > 0x001527489808 in mbtree_propagate_list_neon () from > > > /usr/local/lib/libx264.so.24.0 > > > > > > (gdb) bt > > > #0 0x001527489808 in mbtree_propagate_list_neon () from > > > /usr/local/lib/libx264.so.24.0 > ... > > > Is anyone successfully running ffmpeg on rpi4? > > > > I can confirm that ffmpeg dumps core for me on RPI4 running current/arm64. > > Even with just three jpegs, i.e. three frames, > > > > ffmpeg -y -pattern_type glob -i "*.jpg" all.mp4 > > > > just sits there for ages and eventualy segfaults like this: > > > > Script started on Wed Jan 4 16:12:12 2023 > > ffmpeg version 4.4.3 Copyright (c) 2000-2022 the FFmpeg developers > > built with OpenBSD clang version 13.0.0 > > configuration: --enable-shared --arch=aarch64 --cc=cc --disable-debug > > --disable-indev=jack --disable-outdev=sdl2 --enable-avresample > > --enable-fontconfig --enable-frei0r --enable-gpl --enable-ladspa > > --enable-libaom --enable-libass --enable-libdav1d --enable-libfreetype > > --enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-libopus > > --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis > > --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxml2 > > --enable-libxvid --enable-libzimg --enable-nonfree --enable-openssl > > --enable-libvidstab --extra-cflags='-I/usr/local/include > > -I/usr/X11R6/include' --extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' > > --extra-ldsoflags= --mandir=/usr/local/man --objcc=/usr/bin/false > > --optflags='-O2 -pipe -Wno-redundant-decls' > ... > > Duration: 00:00:00.12, start: 0.00, bitrate: N/A > > Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, > > bt470bg/unknown/unknown), 2560x1920, 25 fps, 25 tbr, 25 tbn, 25 tbc > > Stream mapping: > > Stream #0:0 -> #0:0 (mjpeg (native) -> h264 (libx264)) > > Press [q] to stop, [?] for help > > 1;36m[libx264 @ 0x1491c75800] 0musing cpu capabilities: ARMv8 NEON > > 1;36m[libx264 @ 0x1491c75800] 0mprofile High, level 5.0, 4:2:0, 8-bit > > 1;36m[libx264 @ 0x1491c75800] 0m264 - core 164 - H.264/MPEG-4 AVC codec - > > Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 > > ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 > > mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 > > fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 > > sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 > > constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 > > weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 > > intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 > > qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 > > Output #0, mp4, to 'all.mp4': > > Metadata: > > encoder : Lavf58.76.100 > > Stream #0:0: Video: h264 (avc1 / 0x31637661), yuvj420p(pc, > > bt470bg/unknown/unknown, progressive), 2560x1920, q=2-31, 25 fps, 12800 tbn > > Metadata: > > encoder : Lavc58.134.100 libx264 > > Side data: > > cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A > > frame=1 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A > > speed= > > frame=3 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A > > speed= > > Segmentation fault (core dumped) > > > > > > > > Reading symbols from 32m/usr/local/bin/ffmpegm... > > (No debugging symbols found in 32m/usr/local/bin/ffmpegm) > > [New process 403534] > > [New process 166640] > > [New process 477908] > > [New process 114936] > > [New process 366281] > > [New process 313181] > > [New process 410521] > > [New process 459975] > > [New process 267908] > > [New process 458273] > > [New process 590791] > > [New process 209987] > > Core was generated by `ffmpeg'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > m--Type for more, q to quit, c to continue without paging-- > > #0 34m0x00141f3fa9ccm in
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/01/04 10:29:59 Modified files: x11/kde-plasma : Makefile.inc x11/kde-plasma/breeze: distinfo x11/kde-plasma/breeze-grub: distinfo x11/kde-plasma/breeze-gtk: Makefile distinfo x11/kde-plasma/kdecoration: distinfo x11/kde-plasma/oxygen: distinfo Log message: Update KDE Plamsa to 5.26.5
Re: x11/papirus-icon-theme: update to 20221201
Hello, On 2023/01/04 14:10:09 +0100, David Demelier wrote: > Hi, > > Just an update to 20221201. The patch was mangled and didn't apply. However it was easy, I bumped the version and updated the plist. Committed, thanks!
Re: AM_ICONV
This means that it would actually suffice to install gnulib's iconv module, IIRC. https://lists.gnu.org/archive/html/bug-autoconf/2021-01/msg00036.html HTH, Dima On 4 January 2023 10:56:13 WET, Jan Stary wrote: >On Jan 04 10:17:08, s...@spacehopper.org wrote: >> That comes from iconv.m4 in gettext-tools. IIRC it only needs to be >> installed and you don't need to do anything special to tell automake to find >> it. > >Yes, that was it - thank you. > >While here: > >$ env AUTOCONF_VERSION=2.71 AUTOMAKE_VERSION=1.16 autoreconf -v >autoreconf-2.71: export WARNINGS= >autoreconf-2.71: Entering directory '.' >autoreconf-2.71: configure.ac: not using Gettext >[...] > >Apparently, autoreconf _is_ using gettext (namely, gettext's iconv.m4 >to parse th AM_ICONV macro), so what does 'not using Gettext' mean? > > Thanks again, > > Jan > > >> -- >> Sent from a phone, apologies for poor formatting. >> >> On 4 January 2023 07:52:55 Jan Stary wrote: >> >> > Some third party software, e.g. wavpack, uses AM_ICONV >> > in its configure.ac when building from git. >> > >> > (I know we have a port that already comes with ./configure, >> > so this problem does not occur there.) >> > >> > I do have automake and the rest installed, >> > but autogen.sh complains that >> > >> > autoreconf-2.71: export WARNINGS= >> > autoreconf-2.71: Entering directory '.' >> > autoreconf-2.71: configure.ac: not using Gettext >> > autoreconf-2.71: running: aclocal >> > configure.ac:66: warning: macro 'AM_ICONV' not found in library >> > >> > Please excuse my ignorance: I know next to nothing about the auto* hell. >> > I do have libiconv installed, as well as the following: >> > >> > autoconf-2.69p3 >> > autoconf-2.71 >> > autoconf-archive-2022.09.03 >> > autogen-5.8.7p7 >> > automake-1.16.5 >> > metaauto-1.0p4 >> > >> > Is there something else I need to have >> > so that the AM_ICONV macro is recognized, >> > like the other AM_* stuff in configure.ac? >> > >> > Thank you, >> > >> > Jan >> >> >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2023/01/04 10:06:51 Modified files: x11/papirus-icon-theme: Makefile distinfo x11/papirus-icon-theme/pkg: PLIST Log message: update x11/papirus-icon-theme to 20221201 based on a diff from David Demelier (MAINTAINER), thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/01/04 10:06:33 Modified files: lang/node : Makefile lang/node/patches: patch-deps_v8_src_base_atomicops_h Log message: build fix for node on !LP64; from Volker Schlecht (maintainer) "builds and works for me on my freshly dedicated i386 build machine and on amd64"
Re: [UPDATE] lang/node 18.12.1
With the attached patch, node builds and works for me on my freshly
dedicated i386 build machine and on amd64.
On 1/4/23 07:26, Barry K. Nathan wrote:
On Tue, Jan 3, 2023 at 4:20 PM Volker Schlecht
wrote:
Looping in Barry since he reportedly had the build working on i386, in
the hope that he can remember the missing puzzle piece.
I'll look at this when I get a chance, but that may not be until
the weekend, unfortunately. (In addition to other stuff I need to
get done over the next couple of days, one of my computers just
failed and I need to get that situation under control.)Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.112
diff -u -p -r1.112 Makefile
--- Makefile 29 Dec 2022 23:34:13 - 1.112
+++ Makefile 4 Jan 2023 14:37:52 -
@@ -10,6 +10,7 @@ PLEDGE_VER = 1.1.3
DISTFILES = node-pledge-{}${PLEDGE_VER}.tar.gz:0 \
${DISTNAME}-headers.tar.gz \
${DISTNAME}.tar.xz
+REVISION = 0
DISTNAME = node-${NODE_VERSION}
PKGNAME = ${DISTNAME:S/v//g}
Index: patches/patch-deps_v8_src_base_atomicops_h
===
RCS file: /cvs/ports/lang/node/patches/patch-deps_v8_src_base_atomicops_h,v
retrieving revision 1.5
diff -u -p -r1.5 patch-deps_v8_src_base_atomicops_h
--- patches/patch-deps_v8_src_base_atomicops_h 3 Jan 2023 12:10:40 - 1.5
+++ patches/patch-deps_v8_src_base_atomicops_h 4 Jan 2023 14:37:52 -
@@ -14,3 +14,21 @@ Index: deps/v8/src/base/atomicops.h
using Atomic64 = int64_t;
#else
using Atomic64 = intptr_t;
+@@ -257,7 +257,7 @@ inline Atomic32 SeqCst_Load(volatile const Atomic32* p
+std::memory_order_seq_cst);
+ }
+
+-#if defined(V8_HOST_ARCH_64_BIT)
++#if defined(V8_HOST_ARCH_64_BIT) || defined(V8_OS_OPENBSD)
+
+ inline Atomic64 Relaxed_CompareAndSwap(volatile Atomic64* ptr,
+Atomic64 old_value, Atomic64 new_value) {
+@@ -468,7 +468,7 @@ inline int Relaxed_Memcmp(volatile const Atomic8* s1,
+
+ // On some platforms we need additional declarations to make
+ // AtomicWord compatible with our other Atomic* types.
+-#if defined(V8_OS_DARWIN) || defined(V8_OS_OPENBSD) || defined(V8_OS_AIX)
++#if defined(V8_OS_DARWIN) || defined(V8_OS_AIX)
+ #include "src/base/atomicops_internals_atomicword_compat.h"
+ #endif
+
Re: Error when packaging neovim-0.8.2
On 2023/01/04 17:35, Laurent Cheylus wrote:
> Hi Stuart,
>
> Le 2023-01-04 17:03, Stuart Henderson a écrit :
> > Ports is getting confused between the version in mystuff/ and the main
> > ports tree. You can set the priority order in PORTSDIR_PATH (either in
> > mk.conf or the command line) but it's perhaps easier to edit the port
> > in the main tree (if you want to revert to the ports tree version you
> > can always undo any cvs add/rm commands and cvs up -C to refetch
> > modified files).
>
> Thanks, it was my mistake : priority order for ${PORTDIR}/mystuff in
> PORTSDIR_PATH.
> After redefining it in /etc/mk.conf, my problem is solved : package and
> install OK for my neovim port.
btw the downside of that approach is, if you leave a directory around in
mystuff/, you can have the opposite problem when trying to build something
in the main ports tree (IME that usually shows up when building some
unrelated port that depends on the one from mystuff that you were
working on months ago and forgot about :)
Re: Error when packaging neovim-0.8.2
Hi Stuart,
Le 2023-01-04 17:03, Stuart Henderson a écrit :
Ports is getting confused between the version in mystuff/ and the main
ports tree. You can set the priority order in PORTSDIR_PATH (either in
mk.conf or the command line) but it's perhaps easier to edit the port
in the main tree (if you want to revert to the ports tree version you
can always undo any cvs add/rm commands and cvs up -C to refetch
modified files).
Thanks, it was my mistake : priority order for ${PORTDIR}/mystuff in
PORTSDIR_PATH.
After redefining it in /etc/mk.conf, my problem is solved : package and
install OK for my neovim port.
Edd, my patch for editors/neovim version 0.8.2 is OK : build and tests
work correctly on amd64.
Laurent
Re: Error when packaging neovim-0.8.2
On 2023/01/04 16:58, Laurent Cheylus wrote: > Hi, > > I'm trying to update editors/neovim port with the latest version 0.8.2. > > Build on current/amd64 is OK but I have an error with make package : > > $ make package > `/usr/obj/ports/neovim-0.8.2/fake-amd64/.fake_done' is up to date. > Reading existing plist for neovim-0.8.2 > Writing /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/Makefile.new > Writing /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/PLIST > Renaming /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/Makefile.new to > Makefile > > Extracting debug info from > > /usr/obj/ports/neovim-0.8.2/fake-amd64/usr/local/bin/nvim > Installing /usr/ports/mystuff/editors/neovim/pkg/README as ^^^ > /usr/obj/ports/neovim-0.8.2/fake-amd64/usr/local/share/doc/pkg-readmes/neovim > ===> Building package for neovim-0.8.2 > Create /home/fox/packages/amd64/all/neovim-0.8.2.tgz > Creating package neovim-0.8.2 > Creating package debug-neovim-0.8.2 > checking dependencies|editors/neovim > Error: Dependency = doesn't match FULLPKGNAME: neovim-0.8.1 > checksumming... > pkg_create: can't continue Ports is getting confused between the version in mystuff/ and the main ports tree. You can set the priority order in PORTSDIR_PATH (either in mk.conf or the command line) but it's perhaps easier to edit the port in the main tree (if you want to revert to the ports tree version you can always undo any cvs add/rm commands and cvs up -C to refetch modified files).
Re: Error when packaging neovim-0.8.2
Hi, I'm not at a computer for a few days, but sounds like some part of the port is still referencing the old neovim version. 4 Jan 2023 16:58:14 Laurent Cheylus : > Hi, > > I'm trying to update editors/neovim port with the latest version 0.8.2. > > Build on current/amd64 is OK but I have an error with make package : > > $ make package > `/usr/obj/ports/neovim-0.8.2/fake-amd64/.fake_done' is up to date. > Reading existing plist for neovim-0.8.2 > Writing /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/Makefile.new > Writing /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/PLIST > Renaming /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/Makefile.new to > Makefile >> Extracting debug info from >> /usr/obj/ports/neovim-0.8.2/fake-amd64/usr/local/bin/nvim > Installing /usr/ports/mystuff/editors/neovim/pkg/README as > /usr/obj/ports/neovim-0.8.2/fake-amd64/usr/local/share/doc/pkg-readmes/neovim > ===> Building package for neovim-0.8.2 > Create /home/fox/packages/amd64/all/neovim-0.8.2.tgz > Creating package neovim-0.8.2 > Creating package debug-neovim-0.8.2 > checking dependencies|editors/neovim > Error: Dependency = doesn't match FULLPKGNAME: neovim-0.8.1 > checksumming... > pkg_create: can't continue > > Despite some debug, I am unable to find the root cause of this error. Does > anyone have a clue to solve this issue ? > > Attached my patch for editors/neovim version 0.8.2 > > Laurent
Error when packaging neovim-0.8.2
Hi, I'm trying to update editors/neovim port with the latest version 0.8.2. Build on current/amd64 is OK but I have an error with make package : $ make package `/usr/obj/ports/neovim-0.8.2/fake-amd64/.fake_done' is up to date. Reading existing plist for neovim-0.8.2 Writing /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/Makefile.new Writing /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/PLIST Renaming /usr/obj/ports/neovim-0.8.2/fake-amd64/debug-pkg/Makefile.new to Makefile Extracting debug info from /usr/obj/ports/neovim-0.8.2/fake-amd64/usr/local/bin/nvim Installing /usr/ports/mystuff/editors/neovim/pkg/README as /usr/obj/ports/neovim-0.8.2/fake-amd64/usr/local/share/doc/pkg-readmes/neovim ===> Building package for neovim-0.8.2 Create /home/fox/packages/amd64/all/neovim-0.8.2.tgz Creating package neovim-0.8.2 Creating package debug-neovim-0.8.2 checking dependencies|editors/neovim Error: Dependency = doesn't match FULLPKGNAME: neovim-0.8.1 checksumming... pkg_create: can't continue Despite some debug, I am unable to find the root cause of this error. Does anyone have a clue to solve this issue ? Attached my patch for editors/neovim version 0.8.2 Laurent Index: Makefile === RCS file: /cvs/ports/editors/neovim/Makefile,v retrieving revision 1.31 diff -u -p -r1.31 Makefile --- Makefile 15 Dec 2022 20:05:41 - 1.31 +++ Makefile 4 Jan 2023 15:45:37 - @@ -13,7 +13,7 @@ COMMENT = continuation and extension of GH_ACCOUNT = neovim GH_PROJECT = neovim -GH_TAGNAME = v0.8.1 +GH_TAGNAME = v0.8.2 CATEGORIES = editors devel HOMEPAGE = https://neovim.io Index: distinfo === RCS file: /cvs/ports/editors/neovim/distinfo,v retrieving revision 1.16 diff -u -p -r1.16 distinfo --- distinfo 15 Dec 2022 20:05:41 - 1.16 +++ distinfo 4 Jan 2023 15:45:37 - @@ -1,6 +1,6 @@ SHA256 (luajit-633f265f67f322cbe2c5fd11d3e46d968ac220f7.tar.gz) = JoHwpvYkpkqN+3Clo3fUlNrziWBELFR9nEaGdMGvo8I= SHA256 (luv-1.44.2-1.tar.gz) = PrXHvET2H7xBSOow4yIdQQJj4P+ihWcoUfwZ3r+eXDA= -SHA256 (neovim-0.8.1.tar.gz) = tEhOEwqpYkVxifPe40uEgZQ8HjldLWhMb4uRWYSU2ew= +SHA256 (neovim-0.8.2.tar.gz) = xRbI23PhsSkXprLpkbNE0JFMBXzvgma85hohAKKP/Mk= SIZE (luajit-633f265f67f322cbe2c5fd11d3e46d968ac220f7.tar.gz) = 1074237 SIZE (luv-1.44.2-1.tar.gz) = 1465728 -SIZE (neovim-0.8.1.tar.gz) = 11387691 +SIZE (neovim-0.8.2.tar.gz) = 11401444 Index: pkg/PLIST === RCS file: /cvs/ports/editors/neovim/pkg/PLIST,v retrieving revision 1.16 diff -u -p -r1.16 PLIST --- pkg/PLIST 15 Dec 2022 20:05:41 - 1.16 +++ pkg/PLIST 4 Jan 2023 15:45:37 - @@ -291,6 +291,7 @@ share/nvim/runtime/doc/intro.txt share/nvim/runtime/doc/job_control.txt share/nvim/runtime/doc/lsp-extension.txt share/nvim/runtime/doc/lsp.txt +share/nvim/runtime/doc/lua-guide.txt share/nvim/runtime/doc/lua.txt share/nvim/runtime/doc/luaref.txt share/nvim/runtime/doc/luvref.txt @@ -1041,6 +1042,7 @@ share/nvim/runtime/queries/c/highlights. share/nvim/runtime/queries/c/injections.scm share/nvim/runtime/queries/help/ share/nvim/runtime/queries/help/highlights.scm +share/nvim/runtime/queries/help/injections.scm share/nvim/runtime/queries/lua/ share/nvim/runtime/queries/lua/highlights.scm share/nvim/runtime/queries/lua/injections.scm
Re: rpi4 ffmpeg core dumps
On 2023/01/04 16:22, Jan Stary wrote: > Hi, > > > My old pcengines box died and I had a rpi4 around that I spun up to replace > > it with as my network router/play machine. > > > > The rpi4 is working fantastic except for one thing: > > > > I have a webcam that I'm capturing images using fswebcam and those scripts > > all work perfectly. > > > > I try to make a video of the captured images (timelapse) using ffmpeg, but > > any invocation of ffmpeg I try dumps a core. I have tried on different sets > > of image files so I don't think it's the data coming in. > > > > A super simple invocation: > > ffmpeg -y -pattern_type glob -i "image*.jpeg" all.mp4 > > > > After 40-50 frames results in: > > Thread 2 received signal SIGSEGV, Segmentation fault. > > [Switching to thread 203094] > > 0x001527489808 in mbtree_propagate_list_neon () from > > /usr/local/lib/libx264.so.24.0 > > > > 0x001527489808 in mbtree_propagate_list_neon () from > > /usr/local/lib/libx264.so.24.0 > > > > (gdb) bt > > #0 0x001527489808 in mbtree_propagate_list_neon () from > > /usr/local/lib/libx264.so.24.0 ... > > Is anyone successfully running ffmpeg on rpi4? > > I can confirm that ffmpeg dumps core for me on RPI4 running current/arm64. > Even with just three jpegs, i.e. three frames, > > ffmpeg -y -pattern_type glob -i "*.jpg" all.mp4 > > just sits there for ages and eventualy segfaults like this: > > Script started on Wed Jan 4 16:12:12 2023 > ffmpeg version 4.4.3 Copyright (c) 2000-2022 the FFmpeg developers > built with OpenBSD clang version 13.0.0 > configuration: --enable-shared --arch=aarch64 --cc=cc --disable-debug > --disable-indev=jack --disable-outdev=sdl2 --enable-avresample > --enable-fontconfig --enable-frei0r --enable-gpl --enable-ladspa > --enable-libaom --enable-libass --enable-libdav1d --enable-libfreetype > --enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-libopus > --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis > --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxml2 > --enable-libxvid --enable-libzimg --enable-nonfree --enable-openssl > --enable-libvidstab --extra-cflags='-I/usr/local/include > -I/usr/X11R6/include' --extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' > --extra-ldsoflags= --mandir=/usr/local/man --objcc=/usr/bin/false > --optflags='-O2 -pipe -Wno-redundant-decls' ... > Duration: 00:00:00.12, start: 0.00, bitrate: N/A > Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, > bt470bg/unknown/unknown), 2560x1920, 25 fps, 25 tbr, 25 tbn, 25 tbc > Stream mapping: > Stream #0:0 -> #0:0 (mjpeg (native) -> h264 (libx264)) > Press [q] to stop, [?] for help > 1;36m[libx264 @ 0x1491c75800] 0musing cpu capabilities: ARMv8 NEON > 1;36m[libx264 @ 0x1491c75800] 0mprofile High, level 5.0, 4:2:0, 8-bit > 1;36m[libx264 @ 0x1491c75800] 0m264 - core 164 - H.264/MPEG-4 AVC codec - > Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 > ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 > mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 > fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 > sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 > constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 > weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 > intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 > qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 > Output #0, mp4, to 'all.mp4': > Metadata: > encoder : Lavf58.76.100 > Stream #0:0: Video: h264 (avc1 / 0x31637661), yuvj420p(pc, > bt470bg/unknown/unknown, progressive), 2560x1920, q=2-31, 25 fps, 12800 tbn > Metadata: > encoder : Lavc58.134.100 libx264 > Side data: > cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A > frame=1 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= > frame=3 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= > Segmentation fault (core dumped) > > > > Reading symbols from 32m/usr/local/bin/ffmpegm... > (No debugging symbols found in 32m/usr/local/bin/ffmpegm) > [New process 403534] > [New process 166640] > [New process 477908] > [New process 114936] > [New process 366281] > [New process 313181] > [New process 410521] > [New process 459975] > [New process 267908] > [New process 458273] > [New process 590791] > [New process 209987] > Core was generated by `ffmpeg'. > Program terminated with signal SIGSEGV, Segmentation fault. > m--Type for more, q to quit, c to continue without paging-- > #0 34m0x00141f3fa9ccm in 33mx264_8_cabac_encode_decision_asmm ()m > m from 32m/usr/local/lib/libx264.so.24.0m > [Current thread is 1 (process 403534)] > (gdb) > (gdb) bt > #0 34m0x00141f3fa9ccm in 33mx264_8_cabac_encode_decision_asmm ()m > m from 32m/usr/local/lib/libx264.so.24.0m > #1
Re: rpi4 ffmpeg core dumps
Hi, > My old pcengines box died and I had a rpi4 around that I spun up to replace > it with as my network router/play machine. > > The rpi4 is working fantastic except for one thing: > > I have a webcam that I'm capturing images using fswebcam and those scripts > all work perfectly. > > I try to make a video of the captured images (timelapse) using ffmpeg, but > any invocation of ffmpeg I try dumps a core. I have tried on different sets > of image files so I don't think it's the data coming in. > > A super simple invocation: > ffmpeg -y -pattern_type glob -i "image*.jpeg" all.mp4 > > After 40-50 frames results in: > Thread 2 received signal SIGSEGV, Segmentation fault. > [Switching to thread 203094] > 0x001527489808 in mbtree_propagate_list_neon () from > /usr/local/lib/libx264.so.24.0 > > 0x001527489808 in mbtree_propagate_list_neon () from > /usr/local/lib/libx264.so.24.0 > > (gdb) bt > #0 0x001527489808 in mbtree_propagate_list_neon () from > /usr/local/lib/libx264.so.24.0 > #1 0x00152744fe98 in macroblock_tree_propagate () from > /usr/local/lib/libx264.so.24.0 > #2 0x001527442994 in macroblock_tree () from > /usr/local/lib/libx264.so.24.0 > #3 0x001527441d1c in x264_8_slicetype_analyse () from > /usr/local/lib/libx264.so.24.0 > #4 0x001527488950 in lookahead_slicetype_decide () from > /usr/local/lib/libx264.so.24.0 > #5 0x0015274882dc in lookahead_thread () from > /usr/local/lib/libx264.so.24.0 > #6 0x00158550d3c0 in _rthread_start (v=) at > /usr/src/lib/librthread/rthread.c:96 > #7 0x00153b2cdbf4 in __tfork_thread () at > /usr/src/lib/libc/arch/aarch64/sys/tfork_thread.S:44 > > Is anyone successfully running ffmpeg on rpi4? I can confirm that ffmpeg dumps core for me on RPI4 running current/arm64. Even with just three jpegs, i.e. three frames, ffmpeg -y -pattern_type glob -i "*.jpg" all.mp4 just sits there for ages and eventualy segfaults like this: Script started on Wed Jan 4 16:12:12 2023 ffmpeg version 4.4.3 Copyright (c) 2000-2022 the FFmpeg developers built with OpenBSD clang version 13.0.0 configuration: --enable-shared --arch=aarch64 --cc=cc --disable-debug --disable-indev=jack --disable-outdev=sdl2 --enable-avresample --enable-fontconfig --enable-frei0r --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libdav1d --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-libopus --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nonfree --enable-openssl --enable-libvidstab --extra-cflags='-I/usr/local/include -I/usr/X11R6/include' --extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' --extra-ldsoflags= --mandir=/usr/local/man --objcc=/usr/bin/false --optflags='-O2 -pipe -Wno-redundant-decls' libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat58. 76.100 / 58. 76.100 libavdevice58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc55. 9.100 / 55. 9.100 Input #0, image2, from 'smc*.jpg': Duration: 00:00:00.12, start: 0.00, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 2560x1920, 25 fps, 25 tbr, 25 tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (mjpeg (native) -> h264 (libx264)) Press [q] to stop, [?] for help 1;36m[libx264 @ 0x1491c75800] 0musing cpu capabilities: ARMv8 NEON 1;36m[libx264 @ 0x1491c75800] 0mprofile High, level 5.0, 4:2:0, 8-bit 1;36m[libx264 @ 0x1491c75800] 0m264 - core 164 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to 'all.mp4': Metadata: encoder : Lavf58.76.100 Stream #0:0: Video: h264 (avc1 / 0x31637661), yuvj420p(pc, bt470bg/unknown/unknown, progressive), 2560x1920, q=2-31, 25 fps, 12800 tbn Metadata: encoder : Lavc58.134.100 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A frame=1 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= frame=3 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A speed= Segmentation fault (core dumped) Reading symbols from
Re: [NEW] audio/alsa-lib-1.2.8
I'm worried that a lot of other ports will pick this up if installed. 'grep -wiR alsa' over build logs suggests it's in the order of a hundred ports - apart from the problem of missing deps, we don't want it taking priority over native sndio support in applications. Unless installed in a way to make it hard to pick up accidentally (e.g. a non-standard directory, which has its own problems) I expect the amount of work needed to cope with this in the rest of the ports tree is likely to be quite a lot more than that needed to port a couple of applications from alsa to sndio.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/01/04 07:36:03 Modified files: games/hlsteam : distinfo Log message: missed to update the distinfo filename to pl1, found by aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2023/01/04 07:25:05 Modified files: mail/p5-Mail-SpamAssassin: Makefile distinfo mail/p5-Mail-SpamAssassin/patches: patch-Makefile_PL patch-t_sa_compile_t mail/p5-Mail-SpamAssassin/pkg: PLIST spamassassin.rc Log message: update to 4.0.0 upgrade notes available at http://svn.apache.org/repos/asf/spamassassin/trunk/UPGRADE ok sthen@
Re: [NEW] audio/alsa-lib-1.2.8
Hello, > SHARED_LIBS = asound 0.0 # 2.0 > SHARED_LIBS += atopology 0.0 # 2.0 I will fix them before commit. > with that fixed the port looks fine to me, and builds fine too. What > I don't know is how it's supposed to be used. Is it needed to port > something else? alsa-lib is just the beginning. I want to try MSHV (http://lz2hv.org/mshv) FT8 ham radio software on OpenBSD and this requires ALSA library (it is an idea that rewriting with sndio, but it looks difficult). And, alsa-utils and alsa-plugins are also needed to use alsa-lib. Currently I sent pull-requests for alsa-utils and alsa-plugins, but I think it takes long time to merge (indeed three months has passed for alsa-lib to merge). https://github.com/alsa-project/alsa-utils/pull/186 https://github.com/alsa-project/alsa-plugins/pull/48 Which is better, wait for ALSA team response or work our patch simultaneously? -- SASANO Takayoshi (JG1UAA)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2023/01/04 05:56:12 Modified files: mail/p5-Email-Date-Format: Makefile distinfo Log message: Update to p5-Email-Date-Format-1.007.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2023/01/04 05:05:19 Modified files: devel/spidermonkey102/patches: patch-third_party_rust_cc_src_lib_rs Removed files: devel/spidermonkey102/patches: patch-build_moz_configure_rust_configure Log message: lang/rust now supports a single target on riscv64, drop patch ok ajacoutot@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2023/01/04 05:04:20 Modified files: x11/gnome/librsvg/patches: patch-vendor_cfg-expr_src_targets_builtins_rs Log message: lang/rust riscv64 target name changed, adapt ok ajacoutot@ (maintainer)
Re: AM_ICONV
On Jan 04 10:17:08, s...@spacehopper.org wrote: > That comes from iconv.m4 in gettext-tools. IIRC it only needs to be > installed and you don't need to do anything special to tell automake to find > it. Yes, that was it - thank you. While here: $ env AUTOCONF_VERSION=2.71 AUTOMAKE_VERSION=1.16 autoreconf -v autoreconf-2.71: export WARNINGS= autoreconf-2.71: Entering directory '.' autoreconf-2.71: configure.ac: not using Gettext [...] Apparently, autoreconf _is_ using gettext (namely, gettext's iconv.m4 to parse th AM_ICONV macro), so what does 'not using Gettext' mean? Thanks again, Jan > -- > Sent from a phone, apologies for poor formatting. > > On 4 January 2023 07:52:55 Jan Stary wrote: > > > Some third party software, e.g. wavpack, uses AM_ICONV > > in its configure.ac when building from git. > > > > (I know we have a port that already comes with ./configure, > > so this problem does not occur there.) > > > > I do have automake and the rest installed, > > but autogen.sh complains that > > > > autoreconf-2.71: export WARNINGS= > > autoreconf-2.71: Entering directory '.' > > autoreconf-2.71: configure.ac: not using Gettext > > autoreconf-2.71: running: aclocal > > configure.ac:66: warning: macro 'AM_ICONV' not found in library > > > > Please excuse my ignorance: I know next to nothing about the auto* hell. > > I do have libiconv installed, as well as the following: > > > > autoconf-2.69p3 > > autoconf-2.71 > > autoconf-archive-2022.09.03 > > autogen-5.8.7p7 > > automake-1.16.5 > > metaauto-1.0p4 > > > > Is there something else I need to have > > so that the AM_ICONV macro is recognized, > > like the other AM_* stuff in configure.ac? > > > > Thank you, > > > > Jan > >
Re: AM_ICONV
That comes from iconv.m4 in gettext-tools. IIRC it only needs to be installed and you don't need to do anything special to tell automake to find it. -- Sent from a phone, apologies for poor formatting. On 4 January 2023 07:52:55 Jan Stary wrote: Some third party software, e.g. wavpack, uses AM_ICONV in its configure.ac when building from git. (I know we have a port that already comes with ./configure, so this problem does not occur there.) I do have automake and the rest installed, but autogen.sh complains that autoreconf-2.71: export WARNINGS= autoreconf-2.71: Entering directory '.' autoreconf-2.71: configure.ac: not using Gettext autoreconf-2.71: running: aclocal configure.ac:66: warning: macro 'AM_ICONV' not found in library Please excuse my ignorance: I know next to nothing about the auto* hell. I do have libiconv installed, as well as the following: autoconf-2.69p3 autoconf-2.71 autoconf-archive-2022.09.03 autogen-5.8.7p7 automake-1.16.5 metaauto-1.0p4 Is there something else I need to have so that the AM_ICONV macro is recognized, like the other AM_* stuff in configure.ac? Thank you, Jan
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/04 16:48:05 +0900, SASANO Takayoshi wrote: > Hello, > > - patch for configure.ac is simplified by your idea. > (new diff is also posted to github) thanks! > - warning of pcm.c is fixed, but I use (long)status->x.tv_sec cast > because of other printf() uses same thing. no %ld -> %lld format change. generally speaking I'm not sure this is fine. time_t is 64 bit long here. However, it matches what upstream already do (albeit should change) and seems to be used only for logging, so maybe it's fine. > - add comment before NO_TEST Ooops, sorry, yesterday I failed to notice that SHARED_LIBS should start at zero for new ports: SHARED_LIBS = asound 0.0 # 2.0 SHARED_LIBS += atopology 0.0 # 2.0 > ok? with that fixed the port looks fine to me, and builds fine too. What I don't know is how it's supposed to be used. Is it needed to port something else? Thanks, Omar Polo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/01/04 03:02:31 Modified files: devel/ipython : Makefile distinfo devel/ipython/patches: patch-IPython_core_tests_test_interactiveshell_py devel/ipython/pkg: PLIST Log message: update to ipython3-8.8.0
Re: NEW: math/labplot
27.12.2022 14:58, Rafael Sadowski пишет: > Hi ports, > > this is a port for labplot 2.9.0, a KDE data visualization and analysis > software. > > Comment: > data visualization and analysis software > > Description: > LabPlot is a program for two- and three-dimensional graphical presentation of > data sets and functions. LabPlot allows you to work with multiple plots which > each can have multiple graphs. The graphs can be produced from data or from > functions. > > Maintainer: Rafael Sadowski > > WWW: https://labplot.kde.org/ > > Tested on amd64. OK to import? OK kn > > Rafael >
Re: CVS: cvs.openbsd.org: ports
On Tue, Jan 03, 2023 at 08:05:36PM -0700, Thomas Frohwein wrote: > CVSROOT: /cvs > Module name: ports > Changes by: t...@cvs.openbsd.org2023/01/03 20:05:36 > > Modified files: > games/hlsteam : Makefile distinfo > games/hlsteam/patches: patch-Makefile > patch-native_gameserver_cpp > > Log message: > update to checkout from 2022-03-22, rework Makefile with input from sthen to > avoid SUBST_CMD and use c++ correctly for the build, correctly replace > EnableHeartbeats() with SetAdvertiseServerActive() ===> Checking files for hlsteam-1.0pl1 >> No size recorded for hlsteam-1.0pl1-f774d8ea.tar.gz -- Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2023/01/04 01:01:09 Modified files: x11/gnome/orca : Makefile distinfo Log message: Update to orca-43.1.
