CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2020/06/28 23:48:00 Modified files: graphics/zint : Makefile distinfo Log message: update zint to 2.8.0
Re: new: www/ephemetoot
On Sun, 28 Jun 2020 at 20:50:56 +0100, Stuart Henderson wrote:
> On 2020/06/28 20:48, Paco Esteban wrote:
> > Hi ports@,
> >
> > This is a new port for ephemetoot: https://github.com/hughrun/ephemetoot
> >
> > Ephemetoot is a command line tool for selectively deleting old Mastodon
> > toots from one or more Mastodon accounts.
> >
> > I had to play a bit with the GH_* variables and DISTNAME as the only
> > availabe distfile source is the github automatically generated tarballs.
> > I also set up DIST_SUBDIR to avoid file collisions.
> >
> > It all works correctly but not sure is the correct way to do it.
> >
> > Cheers,
>
> It's easier if you stick closer to the defaults for GH_*, diff below.
> I regenerated plist too, I'm not sure why yours didn't have __init__.py?
>
> diff b4f9cb237fc8e39009a2e71cd79ff3562c19cebd /usr/ports/mystuff
> blob - e0e37d2c675a817fb19b3f908165b4dcfed97f2b
> file + www/ephemetoot/Makefile
> --- www/ephemetoot/Makefile
> +++ www/ephemetoot/Makefile
> @@ -3,22 +3,18 @@
> COMMENT =tool for deleting old Mastodon toots
>
> MODPY_EGG_VERSION = 2.3.1
> -GH_TAGNAME = v${MODPY_EGG_VERSION}
> GH_ACCOUNT = hughrun
> GH_PROJECT = ephemetoot
> +GH_TAGNAME = v${MODPY_EGG_VERSION}
>
> -DISTNAME = ${GH_TAGNAME}
> PKGNAME =py-ephemetoot-${MODPY_EGG_VERSION}
>
> CATEGORIES = www
>
> -HOMEPAGE = https://github.com/hughrun/ephemetoot/
> MAINTAINER = Paco Esteban
>
> # GPLv3+
> PERMIT_PACKAGE = Yes
> -
> -DIST_SUBDIR =ephemetoot
>
> MODULES =lang/python
> MODPY_SETUPTOOLS = Yes
> blob - 07bdb60e88cfa636615afd532b1b8ec29de8bf2c
> file + www/ephemetoot/distinfo
> --- www/ephemetoot/distinfo
> +++ www/ephemetoot/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (ephemetoot/v2.3.1.tar.gz) =
> XbI6iSEvMKDin65oypwk14WRKq6Rf88VBk35a8j2SC8=
> -SIZE (ephemetoot/v2.3.1.tar.gz) = 21461
> +SHA256 (ephemetoot-2.3.1.tar.gz) =
> XbI6iSEvMKDin65oypwk14WRKq6Rf88VBk35a8j2SC8=
> +SIZE (ephemetoot-2.3.1.tar.gz) = 21461
> blob - 58a960c96092e9ff5522476e9b93eb3909053e7b
> file + www/ephemetoot/pkg/PLIST
> --- www/ephemetoot/pkg/PLIST
> +++ www/ephemetoot/pkg/PLIST
> @@ -1,5 +1,7 @@
> @comment $OpenBSD: PLIST,v$
> bin/ephemetoot
> +lib/python${MODPY_VERSION}/site-packages/__init__.py
> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}ephemetoot.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/ephemetoot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
>
> lib/python${MODPY_VERSION}/site-packages/ephemetoot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
> @@ -10,10 +12,14 @@ lib/python${MODPY_VERSION}/site-packages/ephemetoot-${
>
> lib/python${MODPY_VERSION}/site-packages/ephemetoot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> lib/python${MODPY_VERSION}/site-packages/ephemetoot.py
> lib/python${MODPY_VERSION}/site-packages/lib/
> +lib/python${MODPY_VERSION}/site-packages/lib/__init__.py
>
> ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/lib/${MODPY_PYCACHE}/
> +lib/python${MODPY_VERSION}/site-packages/lib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/lib/${MODPY_PYCACHE}ephemetoot.${MODPY_PYC_MAGIC_TAG}pyc
> lib/python${MODPY_VERSION}/site-packages/lib/ephemetoot.py
> lib/python${MODPY_VERSION}/site-packages/lib/lib/
> +lib/python${MODPY_VERSION}/site-packages/lib/lib/__init__.py
>
> ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/lib/lib/${MODPY_PYCACHE}/
> +lib/python${MODPY_VERSION}/site-packages/lib/lib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/lib/lib/${MODPY_PYCACHE}ephemetoot.${MODPY_PYC_MAGIC_TAG}pyc
> lib/python${MODPY_VERSION}/site-packages/lib/lib/ephemetoot.py
>
This looks fines for me and it works!
Thanks!
--
- gonzalo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/06/28 23:38:20 Modified files: devel/protobuf : Makefile distinfo Log message: Update to protobuf 3.12.3 ok landry
dav1d ASM testing on i386
Hi,
Just looking for someone with i386 hw that could test enabling ASM on
i386. It should be fairly noticeable between the straight C path and
SSSE3.
Sample AV1 encoded content to try..
https://comstyle.com/av1/Snowfall%20-%2029314.mkv
Index: Makefile
===
RCS file: /home/cvs/ports/multimedia/dav1d/Makefile,v
retrieving revision 1.22
diff -u -p -u -p -r1.22 Makefile
--- Makefile24 Jun 2020 16:43:34 - 1.22
+++ Makefile28 Jun 2020 04:40:27 -
@@ -4,6 +4,7 @@ COMMENT=small and fast AV1 decoder
VER= 0.7.1
DISTNAME= dav1d-${VER}
+REVISION= 0
CATEGORIES=multimedia
MASTER_SITES= https://downloads.videolan.org/pub/videolan/dav1d/${VER}/
EXTRACT_SUFX= .tar.xz
@@ -25,12 +26,8 @@ MODULES= devel/meson
COMPILER= base-clang ports-gcc
COMPILER_LANGS=c
-.if ${MACHINE_ARCH} == "amd64"
+.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
BUILD_DEPENDS+=devel/nasm
-.endif
-
-.if ${MACHINE_ARCH} == "i386"
-CONFIGURE_ARGS+=-Denable_asm=false
.endif
.include
Index: patches/patch-src_x86_mc_sse_asm
===
RCS file: patches/patch-src_x86_mc_sse_asm
diff -N patches/patch-src_x86_mc_sse_asm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_x86_mc_sse_asm27 Jun 2020 04:39:39 -
@@ -0,0 +1,371 @@
+$OpenBSD$
+
+x86: Fix 32-bit build with PIC enabled.
+
+Index: src/x86/mc_sse.asm
+--- src/x86/mc_sse.asm.orig
src/x86/mc_sse.asm
+@@ -1263,7 +1263,7 @@ cglobal prep_bilin, 3, 7, 0, tmp, src, stride, w, h, m
+ %if ARCH_X86_64
+ mova m8, [pw_8]
+ %else
+- %define m8 [pw_8]
++ %define m8 [t1-prep_sse2+pw_8]
+ %endif
+ pxor m7, m7
+ %endif
+@@ -1272,13 +1272,11 @@ cglobal prep_bilin, 3, 7, 0, tmp, src, stride, w, h, m
+ pshuflw m6, m6, q
+ %if cpuflag(ssse3)
+ punpcklqdq m6, m6
+-%else
+- %if ARCH_X86_64
++%elif ARCH_X86_64
+ psrlwm0, m8, 3
+ punpcklwdm6, m0
+- %else
++%else
+ punpcklwdm6, [base+pw_1]
+- %endif
+ %endif
+ %if ARCH_X86_32
+ mov t1, t2 ; save base reg for w4
+@@ -1396,8 +1394,8 @@ cglobal prep_bilin, 3, 7, 0, tmp, src, stride, w, h, m
+ PUSH r7
+ %endif
+ mov r7, tmpq
++mov r5, srcq
+ %endif
+-mov t1, srcq
+ .hv_w16_hloop:
+ movu m0, [srcq+strideq*0+8*0]
+ movu m1, [srcq+strideq*0+8*1]
+@@ -1440,14 +1438,17 @@ cglobal prep_bilin, 3, 7, 0, tmp, src, stride, w, h, m
+ sub hd, 2
+ jg .hv_w16_vloop
+ movzxhd, t2w
+-add t1, 16
+-movsrcq, t1
+ %if ARCH_X86_64
++add r5, 16
+ add r7, 2*16
++movsrcq, r5
+ movtmpq, r7
+ %else
++movsrcq, srcmp
+ movtmpq, tmpmp
++addsrcq, 16
+ addtmpq, 2*16
++mov srcmp, srcq
+ mov tmpmp, tmpq
+ %endif
+ sub t2d, 1<<16
+@@ -2624,22 +2625,20 @@ cglobal put_8tap, 1, 9, 0, dst, ds, src, ss, w, h, mx,
+ %macro PHADDW 4 ; dst, src, pw_1/tmp, load_pw_1
+ %if cpuflag(ssse3)
+ phaddw %1, %2
+- %else
+- %ifnidn %1, %2
++ %elifnidn %1, %2
+%if %4 == 1
+-mova %3, [pw_1]
++mova %3, [base+pw_1]
+%endif
+ pmaddwd %1, %3
+ pmaddwd %2, %3
+ packssdw %1, %2
+- %else
++ %else
+%if %4 == 1
+-pmaddwd %1, [pw_1]
++pmaddwd %1, [base+pw_1]
+%else
+ pmaddwd %1, %3
+%endif
+ packssdw %1, %1
+- %endif
+ %endif
+ %endmacro
+
+@@ -2795,11 +2794,9 @@ PREP_8TAP_FN sharp_smooth, SHARP, SMOOTH
+ %if ARCH_X86_32
+ %define base_reg r2
+ %define base base_reg-prep%+SUFFIX
+- %define W32_RESTORE_SSQ mov strideq, stridem
+ %else
+ %define base_reg r7
+ %define base 0
+- %define W32_RESTORE_SSQ
+ %endif
+ cglobal prep_8tap, 1, 9, 0, tmp, src, stride, w, h, mx, my, stride3
+ %assign org_stack_offset stack_offset
+@@ -2835,6 +2832,10 @@ cglobal prep_8tap, 1, 9, 0, tmp, src, stride, w, h, mx
+ %else
+ WIN64_SPILL_XMM 16
+ %endif
++%if ARCH_X86_32
++ %define strideq r6
++mov strideq, stridem
++%endif
+ cmp wd, 4
+ je .h_w4
+ tzcntwd, wd
+@@ -2894,7 +2895,6 @@ cglobal prep_8tap, 1, 9, 0, tmp, src, stride, w, h, mx
+ punpcklbwm4, m4
+ psrawm4, 8
+ %endif
+-W32_RESTORE_SSQ
+ %if ARCH_X86_64
+ leastride3q, [strideq*3]
+ %endif
+@@ -2916,8 +2916,7 @@ cglobal prep_8tap, 1, 9, 0, tmp, src, stride, w, h,
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2020/06/28 23:20:14 Modified files: devel/mygui: Makefile distinfo devel/mygui/patches: patch-Common_Base_Ogre_BaseManager_cpp devel/mygui/pkg: PLIST Removed files: devel/mygui/patches: patch-MyGUIEngine_include_MyGUI_Prerequest_h Log message: update to mygui-3.4.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/06/28 23:12:45 Modified files: sysutils : Makefile Log message: +ugrep While here, sort the list alphabetically; ok naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/06/28 23:11:49 Log message: Import sysutils/ugrep, an ultra fast universal grep. ok bket@ ugrep is an ultra fast universal grep with interactive query UI: search file systems, source code, text, binary files, archives (cpio/tar/pax/zip), compressed files (gz/Z/bz2/lzma/xz), documents, fuzzy search, and more. Status: Vendor Tag: bcallah Release Tags: bcallah_20200629 N ports/sysutils/ugrep/Makefile N ports/sysutils/ugrep/distinfo N ports/sysutils/ugrep/patches/patch-configure N ports/sysutils/ugrep/pkg/PLIST N ports/sysutils/ugrep/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/28 23:07:56 Modified files: security/qca-qt5: Makefile distinfo security/qca-qt5/patches: patch-plugins_qca-ossl_qca-ossl_cpp security/qca-qt5/pkg: PLIST Added files: security/qca-qt5/patches: patch-unittest_CMakeLists_txt Removed files: security/qca-qt5/patches: patch-plugins_qca-botan_CMakeLists_txt patch-plugins_qca-ossl_ossl110-compat_h Log message: Update qca to 2.3.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/28 22:54:59 Modified files: net/profanity : Makefile distinfo net/profanity/patches: patch-configure_ac Log message: Update profanity to 0.9.4 Diff from new maintainer lucas at sexy dot is
Re: NEW: security/mat2 0.11.0 - metadata anonymisation toolkit
On Sun, Jun 28, 2020 at 08:45:45PM +0100, Stuart Henderson wrote: > On 2020/06/28 20:34, clematis wrote: > If the tests don't work anyway, you might as well just use pypi and > avoid the on-the-fly generated 10MB tarballs (which might change hash > if they update git, gitlab, gzip, tar, etc) and just use the 30K ones. That's a very fair point - makes sense - thank you. > diff for the above below. Sorry for the space and uppercase mess. And thank you for clarifying the _DEPENDS py3 flavoring. > upstream has a fairly prominent warning about it being in beta on the > readme and not using it for anything critical, should that be copied > to pkg/DESCR? Make sense - I've added it to DESCR. New tarball attached including those changes. Thanks, -- clematis (0xA2C87EDB507B4C53) security_mat2.tar.gz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/28 15:35:41 Modified files: databases/mariadb: Makefile databases/mariadb/pkg: PLIST-server Added files: databases/mariadb/patches: patch-storage_maria_libmarias3_src_marias3_c patch-storage_perfschema_CMakeLists_txt patch-storage_perfschema_my_thread_h patch-storage_perfschema_pfs_config_h_cmake Log message: MariaDB port update, from Brad: - Make use of getthrid(), also fixes the build on sparc64 - Fix building the S3 storage engine Builds Ok on amd64, i386, powerpc and sparc64.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2020/06/28 15:29:20
Modified files:
math/py-ecos : Makefile
Log message:
py-ecos: BUILD_DEPENDS=${RUN_DEPENDS} to unbreak build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/28 15:25:18 Modified files: editors: Makefile Log message: +neovim-qt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/28 15:24:26 Log message: Import neovim-qt-0.2.16.1 OK sthen@, port from Laurence Tratt Comment: Qt5 GUI front-end for neovim Description: neovim-qt is a simple QT5 GUI front-end for neovim. WWW: https://github.com/equalsraf/neovim-qt/wiki Status: Vendor Tag: rsadowski Release Tags: rsadowski_20200628 N ports/editors/neovim-qt/Makefile N ports/editors/neovim-qt/distinfo N ports/editors/neovim-qt/pkg/DESCR N ports/editors/neovim-qt/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2020/06/28 14:08:42 Modified files: www/chromium : Makefile www/chromium/pkg: README Log message: Fix README --disable-unveil flag ok robert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/06/28 14:05:27 Modified files: audio/libvorbis: Tag: OPENBSD_6_7 Makefile audio/libvorbis/pkg: Tag: OPENBSD_6_7 PLIST Added files: audio/libvorbis/patches: Tag: OPENBSD_6_7 patch-lib_psy_c patch-lib_vorbisenc_c Log message: add upstream patches for CVE-2017-14160 and CVE-2018-10392 ok naddy
Re: [update] mail/mu-1.4.10
On 2020/06/28 18:57, Stefan Hagen wrote:
> Hello,
>
> maintainer here, this updates mu from 1.2 to 1.4.10. It includes the
> changes discussed in an earlier thread and the guile flavor contributed
> by Miguel .
>
> Version 1.2 to 1.4 introduces some incompatibilities. Those are mentioned
> in the README. I plan to remove the README file after 6.8.
>
> Please commit if ok.
The ports tree uses a standard format for pkg/README, see
ports/infrastructure/template and every other pkg/README file in
the ports tree. Don't use utf8 chars. README is really a place for
OpenBSD-specific docs rather than a place to replicate upstream release
notes.
> +.if ${FLAVOR} == "guile"
> +WANTLIB += guile-2.2 gc ltdl gmp
> +LIB_DEPENDS += lang/guile2
> +SHARED_LIBS= guile-mu0.0
please just set SHARED_LIBS unconditionally near the top of the file,
it will be ignored for the flavour that doesn't use this.
> +.else
> +CONFIGURE_ARGS +=--disable-guile
> +.endif
>
> USE_GMAKE= Yes
> +
> +SEPARATE_BUILD= Yes
>
> .include
> Index: mail/mu/distinfo
> ===
> RCS file: /cvs/ports/mail/mu/distinfo,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 distinfo
> --- mail/mu/distinfo 21 Jul 2019 00:10:04 - 1.7
> +++ mail/mu/distinfo 28 Jun 2020 16:44:29 -
> @@ -1,2 +1,2 @@
> -SHA256 (mu-1.2.0.tar.xz) = 9jTH8kTcaET/cdw8PhiT5I4ZPKqeDnR+umFjCXdfBTo=
> -SIZE (mu-1.2.0.tar.xz) = 844192
> +SHA256 (mu-1.4.10.tar.xz) = RnXxSkO0hT4Uo+CJIFF4fRuC30jqG9Q3UXKJNnbNfm0=
> +SIZE (mu-1.4.10.tar.xz) = 873328
> Index: mail/mu/patches/patch-configure_ac
> ===
> RCS file: mail/mu/patches/patch-configure_ac
> diff -N mail/mu/patches/patch-configure_ac
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ mail/mu/patches/patch-configure_ac28 Jun 2020 16:44:29 -
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +Look for guile-snarf as guile-snarf2.2
> +(lang/guile2 installs it that way)
> +Index: configure.ac
> +--- configure.ac.orig
> configure.ac
> +@@ -230,7 +230,7 @@ AS_IF([test "x$enable_guile" != "xno"],[
> + GUILE_FLAGS
> + AC_DEFINE_UNQUOTED([GUILE_BINARY],"$GUILE",[guile binary])
> + AC_DEFINE(BUILD_GUILE,[1], [Do we support Guile?])
> +-AC_SUBST(GUILE_SNARF, [guile-snarf])
> ++AC_SUBST(GUILE_SNARF, [guile-snarf2.2])
> + guile_version=$($PKG_CONFIG guile-2.2 --modversion)
> + ])
> + ])
> Index: mail/mu/patches/patch-guile_scripts_find-dups_scm
> ===
> RCS file: mail/mu/patches/patch-guile_scripts_find-dups_scm
> diff -N mail/mu/patches/patch-guile_scripts_find-dups_scm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ mail/mu/patches/patch-guile_scripts_find-dups_scm 28 Jun 2020 16:44:29
> -
> @@ -0,0 +1,12 @@
> +$OpenBSD$
> +look for guile interpreter as guile2.2
these patches are going to be a complete pain when guile is updated..
can you at least use a variable e.g. set GUILE_V=2.2 and SUBST_VARS+=GUILE_V
in the port Makefile and use ${SUBST_CMD} in a makefile target (e.g.
pre-configure) to substitute the actual version into place?
> +Index: guile/scripts/find-dups.scm
> +--- guile/scripts/find-dups.scm.orig
> guile/scripts/find-dups.scm
> +@@ -1,5 +1,5 @@
> + #!/bin/sh
> +-exec guile -e main -s $0 $@
> ++exec guile2.2 -e main -s $0 $@
> + !#
> + ;;
> + ;; Copyright (C) 2013-2015 Dirk-Jan C. Binnema
> Index: mail/mu/patches/patch-guile_scripts_msgs-count_scm
> ===
> RCS file: mail/mu/patches/patch-guile_scripts_msgs-count_scm
> diff -N mail/mu/patches/patch-guile_scripts_msgs-count_scm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ mail/mu/patches/patch-guile_scripts_msgs-count_scm28 Jun 2020
> 16:44:29 -
> @@ -0,0 +1,12 @@
> +$OpenBSD$
> +look for guile interpreter as guile2.2
> +Index: guile/scripts/msgs-count.scm
> +--- guile/scripts/msgs-count.scm.orig
> guile/scripts/msgs-count.scm
> +@@ -1,5 +1,5 @@
> + #!/bin/sh
> +-exec guile -e main -s $0 $@
> ++exec guile2.2 -e main -s $0 $@
> + !#
> + ;;
> + ;; Copyright (C) 2013 Dirk-Jan C. Binnema
> Index: mail/mu/patches/patch-guile_scripts_msgs-per-day_scm
> ===
> RCS file: mail/mu/patches/patch-guile_scripts_msgs-per-day_scm
> diff -N mail/mu/patches/patch-guile_scripts_msgs-per-day_scm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ mail/mu/patches/patch-guile_scripts_msgs-per-day_scm 28 Jun 2020
> 16:44:29 -
> @@ -0,0 +1,12 @@
> +$OpenBSD$
> +look for guile interpreter as guile2.2
> +Index: guile/scripts/msgs-per-day.scm
> +--- guile/scripts/msgs-per-day.scm.orig
> guile/scripts/msgs-per-day.scm
> +@@ -1,5 +1,5 @@
> + #!/bin/sh
> +-exec guile -e main -s $0 $@
> ++exec guile2.2 -e main -s $0 $@
> + !#
> + ;;
> + ;; Copyright (C) 2012-2013 Dirk-Jan C. Binnema
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/06/28 14:03:51 Modified files: audio/libvorbis: Makefile audio/libvorbis/pkg: PLIST Added files: audio/libvorbis/patches: patch-lib_psy_c patch-lib_vorbisenc_c Log message: add upstream patches for CVE-2017-14160 and CVE-2018-10392 ok naddy
Re: new: www/ephemetoot
On 2020/06/28 20:48, Paco Esteban wrote:
> Hi ports@,
>
> This is a new port for ephemetoot: https://github.com/hughrun/ephemetoot
>
> Ephemetoot is a command line tool for selectively deleting old Mastodon
> toots from one or more Mastodon accounts.
>
> I had to play a bit with the GH_* variables and DISTNAME as the only
> availabe distfile source is the github automatically generated tarballs.
> I also set up DIST_SUBDIR to avoid file collisions.
>
> It all works correctly but not sure is the correct way to do it.
>
> Cheers,
It's easier if you stick closer to the defaults for GH_*, diff below.
I regenerated plist too, I'm not sure why yours didn't have __init__.py?
diff b4f9cb237fc8e39009a2e71cd79ff3562c19cebd /usr/ports/mystuff
blob - e0e37d2c675a817fb19b3f908165b4dcfed97f2b
file + www/ephemetoot/Makefile
--- www/ephemetoot/Makefile
+++ www/ephemetoot/Makefile
@@ -3,22 +3,18 @@
COMMENT = tool for deleting old Mastodon toots
MODPY_EGG_VERSION =2.3.1
-GH_TAGNAME = v${MODPY_EGG_VERSION}
GH_ACCOUNT = hughrun
GH_PROJECT = ephemetoot
+GH_TAGNAME = v${MODPY_EGG_VERSION}
-DISTNAME = ${GH_TAGNAME}
PKGNAME = py-ephemetoot-${MODPY_EGG_VERSION}
CATEGORIES = www
-HOMEPAGE = https://github.com/hughrun/ephemetoot/
MAINTAINER = Paco Esteban
# GPLv3+
PERMIT_PACKAGE = Yes
-
-DIST_SUBDIR = ephemetoot
MODULES = lang/python
MODPY_SETUPTOOLS = Yes
blob - 07bdb60e88cfa636615afd532b1b8ec29de8bf2c
file + www/ephemetoot/distinfo
--- www/ephemetoot/distinfo
+++ www/ephemetoot/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ephemetoot/v2.3.1.tar.gz) =
XbI6iSEvMKDin65oypwk14WRKq6Rf88VBk35a8j2SC8=
-SIZE (ephemetoot/v2.3.1.tar.gz) = 21461
+SHA256 (ephemetoot-2.3.1.tar.gz) = XbI6iSEvMKDin65oypwk14WRKq6Rf88VBk35a8j2SC8=
+SIZE (ephemetoot-2.3.1.tar.gz) = 21461
blob - 58a960c96092e9ff5522476e9b93eb3909053e7b
file + www/ephemetoot/pkg/PLIST
--- www/ephemetoot/pkg/PLIST
+++ www/ephemetoot/pkg/PLIST
@@ -1,5 +1,7 @@
@comment $OpenBSD: PLIST,v$
bin/ephemetoot
+lib/python${MODPY_VERSION}/site-packages/__init__.py
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}ephemetoot.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ephemetoot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/ephemetoot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -10,10 +12,14 @@ lib/python${MODPY_VERSION}/site-packages/ephemetoot-${
lib/python${MODPY_VERSION}/site-packages/ephemetoot-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/ephemetoot.py
lib/python${MODPY_VERSION}/site-packages/lib/
+lib/python${MODPY_VERSION}/site-packages/lib/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/lib/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/lib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/lib/${MODPY_PYCACHE}ephemetoot.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/lib/ephemetoot.py
lib/python${MODPY_VERSION}/site-packages/lib/lib/
+lib/python${MODPY_VERSION}/site-packages/lib/lib/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/lib/lib/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/lib/lib/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/lib/lib/${MODPY_PYCACHE}ephemetoot.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/lib/lib/ephemetoot.py
Re: NEW: security/mat2 0.11.0 - metadata anonymisation toolkit
On 2020/06/28 20:34, clematis wrote:
> > It build/install/run OK on amd64. I would appreciate feedback to confirm
> > the python FLAVORING is done properly. Thanks ajacoutot@ for pointing me
> > to the use of devel/py-gobject3${MODPY_FLAVOR} (and not just ${FLAVOR}).
> >
> > I've opened an issue upstream (Ref; #142) to add tests/
> > If they do I will make sure to add this to the next update.
>
> Upstream has no interest in maintaining their pypi nor add test there. So I've
> switched to their gitlab as MASTER_SITES.
> I have some errors trying to run make test. Plus it says it's deprecated
> and this method will be removed inviting to use tox. So I kept the
> NO_TEST = yes There's a few example to run manual test and coverage
> available on the project page. I don't know if that's ok to keep it this
> way.
If the tests don't work anyway, you might as well just use pypi and
avoid the on-the-fly generated 10MB tarballs (which might change hash
if they update git, gitlab, gzip, tar, etc) and just use the 30K ones.
> > I've used it successfully on pictures and pdfs.
>
> I've also re-arranged the Makefile to follow the template order more
> strictly. It still builds and runs OK on amd64. portcheck OK.
> Worked as expected via the command line on pictures and pdfs (which is my only
> use case).
Other problems:
- line things up with tabs (8 col width) not spaces
- Yes/No not YES/NO
- LIB_DEPENDS *must* have an associated WANTLIB, if there is not a
WANTLIB then it's BUILD and/or RUN_DEPENDS
- if a variable is at the default value (at least DISTFILES, EXTRACT_SUFX
in this) don't set it in the Makefile
- use *either* FLAVOR=python3 FLAVORS=python3 (for something which is
a module, package named py-*) *or* MODPY_VERSION, not both
- no , before ${MODPY_FLAVOR}
- there is no python3 version of py-poppler so it's not going to be
doing anything useful for this port
- setuptools is auto added as a dependency when MODPY_SETUPTOOLS is set
- standard for python ports is to set the version number in the
egg-info files/dirs in MODPY_EGG_VERSION so that it's subst'ed with a
variable in the PLIST
- mind the \ at the end of blocks setting variables
diff for the above below.
upstream has a fairly prominent warning about it being in beta on the
readme and not using it for anything critical, should that be copied
to pkg/DESCR?
> > More tests, comments, feedback will be appreciated.
>
> That would still be appreciated. It's meant to have a service menu for
> Dolphin and an extension for Nautilus so if anyone wants to give this a
> try it would be a plus.
>
>
> New tarball including the changes mentioned above attached.
> Cheers,
> --
> clematis (0xA2C87EDB507B4C53)
diff b59de2620f6c14ee88ecdea20ece040a6a11adf2 /usr/ports/mystuff
blob - 319a98de2009039b309a961b0795810e0430d253
file + security/mat2/Makefile
--- security/mat2/Makefile
+++ security/mat2/Makefile
@@ -1,42 +1,35 @@
# $OpenBSD$
-COMMENT = metadata anonymisation toolkit
+COMMENT = metadata anonymisation toolkit
-V = 0.11.0
-DISTNAME = mat2-${V}
-DISTFILES = mat2-${V}${EXTRACT_SUFX}
+MODPY_EGG_VERSION =0.11.0
+DISTNAME = mat2-${MODPY_EGG_VERSION}
-CATEGORIES = security
+CATEGORIES = security
-HOMEPAGE =https://0xacab.org/jvoisin/mat2
-MAINTAINER = Clem Atis
+HOMEPAGE = https://0xacab.org/jvoisin/mat2
+MAINTAINER = Clem Atis
# LGPLv3
-PERMIT_PACKAGE =YES
+PERMIT_PACKAGE = Yes
-MASTER_SITES = https://0xacab.org/jvoisin/mat2/\-/archive/${V}/
-EXTRACT_SUFX = .tar.gz
+MODULES = lang/python
+MODPY_PI = Yes
+MODPY_SETUPTOOLS = Yes
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
-MODULES = lang/python
-MODPY_PI =NO
-MODPY_SETUPTOOLS =YES
-MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
-FLAVOR ?=
-FLAVORS = python3
+RUN_DEPENDS = audio/py-mutagen${MODPY_FLAVOR} \
+ devel/py-gobject3${MODPY_FLAVOR} \
+ graphics/py-cairo${MODPY_FLAVOR}
-RUN_DEPENDS = audio/py-mutagen,${MODPY_FLAVOR} \
-graphics/py-cairo,${MODPY_FLAVOR} \
-devel/py-gobject3${MODPY_FLAVOR}
+RUN_DEPENDS += graphics/ffmpeg \
+ graphics/gdk-pixbuf2 \
+ graphics/p5-Image-ExifTool \
+ print/poppler,-main \
+ x11/gtk+3 \
+ x11/gnome/librsvg
-LIB_DEPENDS = print/py-poppler \
-devel/py-setuptools \
-graphics/gdk-pixbuf2 \
-x11/gtk+3 \
-x11/gnome/librsvg \
-graphics/ffmpeg \
-graphics/p5-Image-ExifTool \
-
# test deprecated - upstream encourage to use tox
-NO_TEST = Yes
+NO_TEST = Yes
.include
blob - d94932f82b60c88ebbb6cea690da2ff39e6614c7
file + security/mat2/distinfo
--- security/mat2/distinfo
+++ security/mat2/distinfo
@@ -1,2 +1,2 @@
-SHA256 (mat2-0.11.0.tar.gz) =
Re: Haskell ports: cabal v2-build?
Hello, I'm looking for strong negative reactions (if any) to this proposal so I don't waste any time. On Sat, Jun 8, 2019 at 9:27 PM Greg Steuck wrote: > While looking at Haskell binary ports, a couple of approaches seem > possible. > > 1) Embed Haskell libraries into ports, build binaries from them. > 2) Build binaries with `cabal new-build` I'm reviving this thread to see if this is a plausible path forward for ghc-8.10 upgrade. The new information that I learned since I wrote the original[1] was that FreeBSD already implemented the cabal new-build route (before I even wrote the original email): https://github.com/freebsd/freebsd-ports/commit/0f5d99f9175dc8876140c7b098358d51223c7f5d The main takeaway here is that the approach is workable and we can learn from their experience. In particular, custom xmonad configurations require local rebuilding which isn't hard, but does mean a beefier machine is needed. I'm keeping a running log of my learnings: https://github.com/blackgnezdo/ports/issues/3 Thanks Greg [1] https://openbsdmailbox.blogspot.com/2019/06/haskell-ports-cabal-v2-build.html -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/28 12:59:15 Modified files: x11/kde-applications/akregator: Makefile Log message: Add a lot of new dependencies to fix a bulk build. Spotted by naddy
Re: UPDATE: audio/ncspot to 0.1.4
On Sun, Jun 28, 2020 at 03:31:47PM +0200, Henrik Friedrichsen wrote: > Maintenance update to 0.1.4 > > Changelog: > > Add command/binding ( to jump to currently playing track (fixes #181) > Add OpenUri D-BUS MPRIS support (#185) > Implement volume normalization setting (fixes #195) > Implement audio_cache setting (fixes #196) > Support configuration of audio backend and backend device (fixes #194) > Handle lost/disconnected sessions gracefully (fixes #34, #125, #176, #192) > Add configuration value to drop default keybindings (fixes #204) > Only clear credentials when they're invalid (fixes #77) > Add noop command to override single default bindings (#207) > Add help command (#208) Hi Henrik, Build/Install OK for me on amd64. Runs OK too. Been using 0.1.4 for a couple of hours. Just once as I exit I had a : thread '' panicked at 'could not send no-op event to cursive: "SendError(..)"', src/events.rs:42:9 I couldn't reproduce it going through various cycle of browsing/searching/playing and coming back as well as switching from Queue/Search/Library. -- clematis (0xA2C87EDB507B4C53)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/28 12:49:08 Modified files: graphics/digikam: Makefile Log message: Add new dependencies like akonadi. Spotted by naddy
new: www/ephemetoot
Hi ports@, This is a new port for ephemetoot: https://github.com/hughrun/ephemetoot Ephemetoot is a command line tool for selectively deleting old Mastodon toots from one or more Mastodon accounts. I had to play a bit with the GH_* variables and DISTNAME as the only availabe distfile source is the github automatically generated tarballs. I also set up DIST_SUBDIR to avoid file collisions. It all works correctly but not sure is the correct way to do it. Cheers, -- Paco Esteban. 0x5818130B8A6DBC03 ephemetoot.tar.gz Description: Binary data
Re: NEW: security/mat2 0.11.0 - metadata anonymisation toolkit
On Sat, May 30, 2020 at 11:12:41PM +0200, clematis wrote:
> Hi Team,
>
> Here's a new package for mat2, a metadata removal tool supporting a wide
> range of commonly used file formats.
>
> https://0xacab.org/jvoisin/mat2
>
> [+] Supported formats:
> - application/epub+zip (.epub)
> - application/pdf (.pdf)
> - application/x-dtbncx+xml (.ncx)
> - application/x-tar (.tar)
> - application/zip (.zip)
> - audio/mpeg (.mp3, .mp2)
> - audio/x-wav (.wav)
> - image/gif (.gif)
> - image/jpeg (.jpeg, .jpe, .jpg)
> - image/png (.png)
> - image/svg+xml (.svg)
> - image/tiff (.tif, .tiff)
> - image/x-ms-bmp (.bmp)
> - image/x-portable-pixmap (.ppm)
> - text/css (.css)
> - text/html (.html, .htm)
> - text/plain (.txt)
> - video/mp4 (.mp4)
> - video/x-msvideo (.avi)
>
>
> It build/install/run OK on amd64. I would appreciate feedback to confirm
> the python FLAVORING is done properly. Thanks ajacoutot@ for pointing me
> to the use of devel/py-gobject3${MODPY_FLAVOR} (and not just ${FLAVOR}).
>
> I've opened an issue upstream (Ref; #142) to add tests/
> If they do I will make sure to add this to the next update.
Upstream has no interest in maintaining their pypi nor add test there. So I've
switched to their gitlab as MASTER_SITES.
I have some errors trying to run make test. Plus it says it's deprecated
and this method will be removed inviting to use tox. So I kept the
NO_TEST = yes There's a few example to run manual test and coverage
available on the project page. I don't know if that's ok to keep it this
way.
> I've used it successfully on pictures and pdfs.
I've also re-arranged the Makefile to follow the template order more
strictly. It still builds and runs OK on amd64. portcheck OK.
Worked as expected via the command line on pictures and pdfs (which is my only
use case).
> More tests, comments, feedback will be appreciated.
That would still be appreciated. It's meant to have a service menu for
Dolphin and an extension for Nautilus so if anyone wants to give this a
try it would be a plus.
New tarball including the changes mentioned above attached.
Cheers,
--
clematis (0xA2C87EDB507B4C53)
security_mat2.tar.gz
Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2020/06/28 11:33:38 Modified files: audio/ncspot : Makefile distinfo Log message: Update to ncspot-0.1.4 Changes: https://github.com/hrkfdn/ncspot/releases/tag/0.1.4. From Henrik Friedrichsen (maintainer).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/06/28 11:06:09 Modified files: sysutils/diffoscope: Makefile distinfo Log message: Update to diffoscope-149
[update] mail/mu-1.4.10
Hello,
maintainer here, this updates mu from 1.2 to 1.4.10. It includes the
changes discussed in an earlier thread and the guile flavor contributed
by Miguel .
Version 1.2 to 1.4 introduces some incompatibilities. Those are mentioned
in the README. I plan to remove the README file after 6.8.
Please commit if ok.
Cheers,
Stefan
Index: mail/mu/Makefile
===
RCS file: /cvs/ports/mail/mu/Makefile,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 Makefile
--- mail/mu/Makefile24 Jan 2020 10:36:41 - 1.19
+++ mail/mu/Makefile28 Jun 2020 16:44:29 -
@@ -2,8 +2,12 @@
COMMENT= maildir indexer and searcher with emacs frontend
-DISTNAME= mu-1.2.0
-REVISION= 0
+V= 1.4.10
+
+DISTNAME= mu-$V
+
+FLAVORS= guile
+FLAVOR ?=
CATEGORIES=mail
HOMEPAGE= http://www.djcbsoftware.nl/code/mu/
@@ -16,9 +20,10 @@ PERMIT_PACKAGE= Yes
WANTLIB += ${COMPILER_LIBCXX} assuan c ffi gio-2.0 glib-2.0 gmime-3.0
WANTLIB += gmodule-2.0 gobject-2.0 gpg-error gpgme gthread-2.0
WANTLIB += iconv idn2 intl json-glib-1.0 m pcre unistring uuid
-WANTLIB += xapian z
+WANTLIB += xapian z curses readline
+
-MASTER_SITES= https://github.com/djcb/mu/releases/download/1.2/
+MASTER_SITES= https://github.com/djcb/mu/releases/download/${V}/
EXTRACT_SUFX= .tar.xz
BUILD_DEPENDS= emacs->=24:editors/emacs
@@ -37,9 +42,18 @@ AUTOMAKE_VERSION=1.15
CONFIGURE_STYLE= autoreconf
CONFIGURE_ARGS=--disable-gtk \
- --disable-webkit \
- --disable-guile
+ --disable-webkit
+
+.if ${FLAVOR} == "guile"
+WANTLIB += guile-2.2 gc ltdl gmp
+LIB_DEPENDS += lang/guile2
+SHARED_LIBS= guile-mu 0.0
+.else
+CONFIGURE_ARGS += --disable-guile
+.endif
USE_GMAKE= Yes
+
+SEPARATE_BUILD=Yes
.include
Index: mail/mu/distinfo
===
RCS file: /cvs/ports/mail/mu/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- mail/mu/distinfo21 Jul 2019 00:10:04 - 1.7
+++ mail/mu/distinfo28 Jun 2020 16:44:29 -
@@ -1,2 +1,2 @@
-SHA256 (mu-1.2.0.tar.xz) = 9jTH8kTcaET/cdw8PhiT5I4ZPKqeDnR+umFjCXdfBTo=
-SIZE (mu-1.2.0.tar.xz) = 844192
+SHA256 (mu-1.4.10.tar.xz) = RnXxSkO0hT4Uo+CJIFF4fRuC30jqG9Q3UXKJNnbNfm0=
+SIZE (mu-1.4.10.tar.xz) = 873328
Index: mail/mu/patches/patch-configure_ac
===
RCS file: mail/mu/patches/patch-configure_ac
diff -N mail/mu/patches/patch-configure_ac
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/mu/patches/patch-configure_ac 28 Jun 2020 16:44:29 -
@@ -0,0 +1,15 @@
+$OpenBSD$
+Look for guile-snarf as guile-snarf2.2
+(lang/guile2 installs it that way)
+Index: configure.ac
+--- configure.ac.orig
configure.ac
+@@ -230,7 +230,7 @@ AS_IF([test "x$enable_guile" != "xno"],[
+ GUILE_FLAGS
+ AC_DEFINE_UNQUOTED([GUILE_BINARY],"$GUILE",[guile binary])
+ AC_DEFINE(BUILD_GUILE,[1], [Do we support Guile?])
+-AC_SUBST(GUILE_SNARF, [guile-snarf])
++AC_SUBST(GUILE_SNARF, [guile-snarf2.2])
+ guile_version=$($PKG_CONFIG guile-2.2 --modversion)
+ ])
+ ])
Index: mail/mu/patches/patch-guile_scripts_find-dups_scm
===
RCS file: mail/mu/patches/patch-guile_scripts_find-dups_scm
diff -N mail/mu/patches/patch-guile_scripts_find-dups_scm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/mu/patches/patch-guile_scripts_find-dups_scm 28 Jun 2020 16:44:29
-
@@ -0,0 +1,12 @@
+$OpenBSD$
+look for guile interpreter as guile2.2
+Index: guile/scripts/find-dups.scm
+--- guile/scripts/find-dups.scm.orig
guile/scripts/find-dups.scm
+@@ -1,5 +1,5 @@
+ #!/bin/sh
+-exec guile -e main -s $0 $@
++exec guile2.2 -e main -s $0 $@
+ !#
+ ;;
+ ;; Copyright (C) 2013-2015 Dirk-Jan C. Binnema
Index: mail/mu/patches/patch-guile_scripts_msgs-count_scm
===
RCS file: mail/mu/patches/patch-guile_scripts_msgs-count_scm
diff -N mail/mu/patches/patch-guile_scripts_msgs-count_scm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ mail/mu/patches/patch-guile_scripts_msgs-count_scm 28 Jun 2020 16:44:29
-
@@ -0,0 +1,12 @@
+$OpenBSD$
+look for guile interpreter as guile2.2
+Index: guile/scripts/msgs-count.scm
+--- guile/scripts/msgs-count.scm.orig
guile/scripts/msgs-count.scm
+@@ -1,5 +1,5 @@
+ #!/bin/sh
+-exec guile -e main -s $0 $@
++exec guile2.2 -e main -s $0 $@
+ !#
+ ;;
+ ;; Copyright (C) 2013 Dirk-Jan C. Binnema
Index: mail/mu/patches/patch-guile_scripts_msgs-per-day_scm
===
RCS file: mail/mu/patches/patch-guile_scripts_msgs-per-day_scm
diff -N mail/mu/patches/patch-guile_scripts_msgs-per-day_scm
--- /dev/null 1 Jan 1970 00:00:00 -
+++
[update] protobuf 3.12.3
On Thu, May 28, 2020 at 09:15:21PM +0200, Theo Buehler wrote:
> Protocol buffers have seen a few releases over the past weeks, so it's
> time for an update. I have built this diff on amd64, macppc and sparc64
> and tested interoperability between these platforms with mosh linked
> against protobuf 3.11 and 3.12.
>
> The google/protobuf home now redirects to a new location, so I changed
> that.
>
> Major bumps required for all three libs. The diff between 3.11.4 and
> 3.12.2 is huge as usual, the one well-known test hang is still present.
>
> I will do some more build testing in the coming days, but wanted to send
> this out already.
Here's an updated diff for Protobuf 3.12.3.
I have done the usual runtime checking of mosh between different
architectures and versions, also mumble and profanity on amd64. I've
build a few of the dependent ports with no fallout.
I'd really like to get this in soon.
Index: Makefile
===
RCS file: /var/cvs/ports/devel/protobuf/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile6 Mar 2020 14:06:10 - 1.33
+++ Makefile28 Jun 2020 15:01:55 -
@@ -2,26 +2,26 @@
COMMENT = c++ protocol buffers
-V =3.11.4
+V =3.12.3
DISTNAME = protobuf-cpp-$V
PKGNAME = protobuf-$V
WRKDIST = ${WRKDIR}/protobuf-${V}
-SHARED_LIBS += protobuf6.0 # 22.4
-SHARED_LIBS += protoc 7.0 # 22.4
-SHARED_LIBS += protobuf-lite 6.0 # 22.4
+SHARED_LIBS += protobuf7.0 # 23.3
+SHARED_LIBS += protobuf-lite 7.0 # 23.3
+SHARED_LIBS += protoc 8.0 # 23.3
CATEGORIES = devel
-HOMEPAGE = https://github.com/google/protobuf/
+HOMEPAGE = https://github.com/protocolbuffers/protobuf/
# New BSD
PERMIT_PACKAGE = Yes
WANTLIB += c m pthread ${COMPILER_LIBCXX} z
-MASTER_SITES =
https://github.com/google/protobuf/releases/download/v$V/
+MASTER_SITES =
https://github.com/protocolbuffers/protobuf/releases/download/v$V/
COMPILER = base-clang ports-gcc
@@ -34,7 +34,7 @@ CONFIGURE_ARGS += --with-zlib
# avoid undefined reference to __atomic_fetch_add_8
.if ${CHOSEN_COMPILER} == "ports-gcc"
-. if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "hppa"
+. if ${MACHINE_ARCH} == "hppa"
CONFIGURE_ENV += LIBS="-latomic"
WANTLIB += atomic
. endif
Index: distinfo
===
RCS file: /var/cvs/ports/devel/protobuf/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo6 Mar 2020 14:06:10 - 1.12
+++ distinfo11 Jun 2020 09:55:28 -
@@ -1,2 +1,2 @@
-SHA256 (protobuf-cpp-3.11.4.tar.gz) =
uku8PmtY0sz+QG5hZXbvSHEKKq4gX0Y2GAJfxpFUnP4=
-SIZE (protobuf-cpp-3.11.4.tar.gz) = 4605834
+SHA256 (protobuf-cpp-3.12.3.tar.gz) =
Tvl+xqjgVw0irYxXyZ0gVaYeomQ7jhoJmNLIRJFsSWg=
+SIZE (protobuf-cpp-3.12.3.tar.gz) = 4631996
Re: UPDATE net/profanity 0.9.4 and take MAINTAINER
This is a simple update to 0.9.4, with some bug fixes since 0.9.0.
* Make legacy auth optional (0.9.1)
* Dont manipulate pointer from getenv (0.9.2)
* Fix reading/writing linked files (0.9.2)
* Use gnu99 C standard (0.9.2)
* Fix expansion in eval_password (0.9.3)
* Fix NULL terminated list (0.9.4)
* Add missing string.h (0.9.4)
* Fix gcc warnings for cygwin (0.9.4)
I also addressed the patch update as gsoares@ pointed out.
-Lucas
Index: Makefile
===
RCS file: /home/cvs/ports/net/profanity/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile18 Jun 2020 20:44:16 - 1.14
+++ Makefile27 Jun 2020 22:03:17 -
@@ -1,10 +1,12 @@
# $OpenBSD: Makefile,v 1.14 2020/06/18 20:44:16 rsadowski Exp $
COMMENT = console based XMPP client
-DISTNAME = profanity-0.9.0
+DISTNAME = profanity-0.9.4
CATEGORIES = net
HOMEPAGE = https://profanity-im.github.io/
+
+MAINTAINER = Lucas
SHARED_LIBS += profanity 0.0 # 0.0
Index: distinfo
===
RCS file: /home/cvs/ports/net/profanity/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo18 Jun 2020 20:44:16 - 1.8
+++ distinfo28 Jun 2020 13:30:48 -
@@ -1,2 +1,2 @@
-SHA256 (profanity-0.9.0.tar.gz) = sq93MqdTXUbfccMjGc0Elds9HyutlnGbSN0/MieT6LA=
-SIZE (profanity-0.9.0.tar.gz) = 830056
+SHA256 (profanity-0.9.4.tar.gz) = ZVcKAV5EE3+H2Q2q3R4+vHyNpQ8lMlsGqksT9YuThfo=
+SIZE (profanity-0.9.4.tar.gz) = 830413
Index: patches/patch-configure_ac
===
RCS file: /home/cvs/ports/net/profanity/patches/patch-configure_ac,v
retrieving revision 1.5
diff -u -p -r1.5 patch-configure_ac
--- patches/patch-configure_ac 18 Jun 2020 20:44:16 - 1.5
+++ patches/patch-configure_ac 28 Jun 2020 14:49:36 -
@@ -1,5 +1,8 @@
$OpenBSD: patch-configure_ac,v 1.5 2020/06/18 20:44:16 rsadowski Exp $
+Use ${LOCALBASE} instead of hard-coded /usr/local
+Use ${MODPY_VERSION} to pick up our python-config
+
Index: configure.ac
--- configure.ac.orig
+++ configure.ac
@@ -12,7 +15,7 @@ Index: configure.ac
if test "$PYTHON_CONFIG_EXISTS" == "yes"; then
AX_PYTHON_DEVEL
AM_CONDITIONAL([BUILD_PYTHON_API], [true])
-@@ -214,10 +214,10 @@ AS_IF([test "x$PLATFORM" = xosx],
+@@ -223,10 +223,10 @@ AS_IF([test "x$PLATFORM" = xosx],
[AC_MSG_ERROR([libreadline is required for profanity])])],
[test "x$PLATFORM" = xopenbsd],
Re: [update] audio/lmms enable ZynAddSubFX
On Sun, Jun 28, 2020 at 01:03:48PM +0100, Stuart Henderson wrote: > On 2020/06/28 11:01, Kinichiro Inoguchi wrote: > > On Sat, Jun 27, 2020 at 04:55:47PM +0100, Stuart Henderson wrote: > > > On 2020/06/27 15:37, Kinichiro Inoguchi wrote: > > > > Currently, lmms is disabling the ZynAddSubFX plugin. > > > > This diff enables it. > > > > > > > > - remove patches/patch-plugins_CMakeLists_txt to build zynaddsubfx > > > > - add required libraries to WANTLIB and LIB_DEPENDS > > > > - bump up REVISION to 1 > > > > > > > > In this diff, I just delete all lines in patch-plugins_CMakeLists_txt. > > > > I would like to 'cvs remove' it if this diff is ok. > > > > > > > > I had confirmed that build and install on my OpenBSD 6.7 (amd64) > > > > succeeded. > > > > And I could play ZynAddSubFX within lmms. > > > > > > > > ok? > > > > > > Doesn't seem to work here (I couldn't get it to work when I tried > > > before when I updated the port to 1.2.0). > > > > > > I don't see ZynAddSubFX show up in the plugins list in lmms. > > > And I see this on the console when starting lmms, > > > > > > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > > > symbol(_ZTI6Effect) size mismatch, relink your program > > > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > > > symbol(_ZTV6Effect) size mismatch, relink your program > > > "LMMS plugin /usr/local/lib/lmms/libZynAddSubFxCore.so does not have a > > > plugin descriptor named ZynAddSubFxCore_plugin_descriptor!" > > > > Thanks for checking this. > > > > I'm getting the same console messages. > > > > $ lmms > > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to > > '/tmp/runtime-inoguchi' > > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > > symbol(_ZTI6Effect) size mismatch, relink your program > > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > > symbol(_ZTV6Effect) size mismatch, relink your program > > "LMMS plugin /usr/local/lib/lmms/libZynAddSubFxCore.so does not have a > > plugin descriptor named ZynAddSubFxCore_plugin_descriptor!" > > > > But I can see ZynAddSubFX in "Instrument Plugins" and "My Preset". > > > > I will attach my "make port-lib-depends-check" and "make config" below. > > difference seems: > > - I'm using lo.1 (recently I re-added liblo-0.31 to ports) > > - Mine showed up patch apply section (intentionally omitted ?) > > - I have no cmake warning (I installed 3.16.2) > > - fluidsynth 1.1.6 vs 2.1.2 (I'm using pkg_add on my OpenBSD 6.7, > > and the latest was fluidsynth-1.1.6p5) > > > > Can I try fluidsynth 2.1.2 to check if this is the problem ? > > In that case, could you tell me where I can obtain 2.1.2, please. > > Apologies, I had forgotten about the local update to fluidsynth (I didn't > successfully get sndio working so I had abandoned it, but still had it > installed).. > > My liblo version is from testing your submission before it was committed, > I think there was no change other than the version number. > > Replacing liblo and fluidsynth with the versions from current packages > doesn't help. I only see Sine Oscillator (x4) and White Noise Source in > instrument plugins. > > The missing linkages in port-lib-depends-check are still there: > > lmms-1.2.0p1(audio/lmms): > Extra: fftw3.7 lo.1 mxml.0 > > "Extra" means that the libraries are listed in WANTLIB but are not used > by any of the programs/libraries in the package, this might mean that > static libraries are used instead, but it's a bit suspicious. Sorry, I misunderstood "Extra:". And nothing seems to link those libraries. I should remove them from WANTLIB next time. > > Can you try updating your system? cmake 3.17 has been in the ports tree > for a month, maybe it's related to that. > Yes, sure. And I had updated cmake to 3.17.2 from latest ports, and rebuild lmms. Before rebuild, I had cleaned up my lmms installation and package, with make uninstall, make clean, and make clean=[package plist dist]. After rebuild with cmake 3.17.2, zynaddsubfx is still working with lmms. Latest cmake gives warning like "CMake Deprecation Warning at CMakeLists.txt:11 (CMAKE_POLICY):", but works fine and build was succeeded. I can't tell why zynaddsubfx is not working on your environment... Here is my build log. https://github.com/kinichiro/zynaddsubfx/files/4842454/lmms-make.zip Some screen shots for lmms with zynaddsubfx on my OpenBSD 6.7 (amd64). Instrument Plugins: https://user-images.githubusercontent.com/4927823/85950622-e5cff480-b998-11ea-8689-b41ea1195475.PNG My Presets: https://user-images.githubusercontent.com/4927823/85950692-42cbaa80-b999-11ea-8704-1be8d0044744.PNG Loading demos: https://user-images.githubusercontent.com/4927823/85950716-76a6d000-b999-11ea-8b02-9ff2f0418f56.PNG Kinichiro Inoguchi
UPDATE: audio/ncspot to 0.1.4
Maintenance update to 0.1.4
Changelog:
Add command/binding ( to jump to currently playing track (fixes #181)
Add OpenUri D-BUS MPRIS support (#185)
Implement volume normalization setting (fixes #195)
Implement audio_cache setting (fixes #196)
Support configuration of audio backend and backend device (fixes #194)
Handle lost/disconnected sessions gracefully (fixes #34, #125, #176, #192)
Add configuration value to drop default keybindings (fixes #204)
Only clear credentials when they're invalid (fixes #77)
Add noop command to override single default bindings (#207)
Add help command (#208)
Index: Makefile
===
RCS file: /cvs/ports/audio/ncspot/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile12 Apr 2020 14:44:52 - 1.5
+++ Makefile28 Jun 2020 13:29:42 -
@@ -6,7 +6,7 @@ COMMENT = ncurses Spotify client
GH_ACCOUNT = hrkfdn
GH_PROJECT = ncspot
-GH_TAGNAME = v0.1.3
+GH_TAGNAME = 0.1.4
CATEGORIES = audio
@@ -27,34 +27,34 @@ NO_TEST = Yes
CONFIGURE_STYLE = cargo
DISTFILES += ${DISTNAME}${EXTRACT_SUFX}
+MODCARGO_CRATES += addr2line 0.12.1 # Apache-2.0/MIT
MODCARGO_CRATES += adler32 1.0.4 # Zlib
MODCARGO_CRATES += aes 0.3.2 # MIT OR Apache-2.0
MODCARGO_CRATES += aes-ctr 0.3.0 # MIT OR Apache-2.0
MODCARGO_CRATES += aes-soft0.3.3 # MIT OR Apache-2.0
MODCARGO_CRATES += aesni 0.6.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += ahash 0.2.18 # MIT OR Apache-2.0
+MODCARGO_CRATES += ahash 0.3.5 # MIT OR Apache-2.0
MODCARGO_CRATES += aho-corasick0.7.10 # Unlicense/MIT
MODCARGO_CRATES += alga0.9.3 # Apache-2.0
MODCARGO_CRATES += alsa0.2.2 # Apache-2.0/MIT
MODCARGO_CRATES += alsa-sys0.1.2 # MIT
MODCARGO_CRATES += ansi_term 0.11.0 # MIT
MODCARGO_CRATES += approx 0.3.2 # Apache-2.0
-MODCARGO_CRATES += arc-swap0.4.5 # Apache-2.0/MIT
-MODCARGO_CRATES += array-macro 1.0.4 # MIT/Apache-2.0
+MODCARGO_CRATES += arc-swap0.4.6 # Apache-2.0/MIT
+MODCARGO_CRATES += array-macro 1.0.5 # MIT/Apache-2.0
MODCARGO_CRATES += arrayref0.3.6 # BSD-2-Clause
MODCARGO_CRATES += arrayvec0.5.1 # MIT/Apache-2.0
MODCARGO_CRATES += atty0.2.14 # MIT
MODCARGO_CRATES += autocfg 0.1.7 # Apache-2.0/MIT
MODCARGO_CRATES += autocfg 1.0.0 # Apache-2.0 OR MIT
-MODCARGO_CRATES += backtrace 0.3.46 # MIT/Apache-2.0
-MODCARGO_CRATES += backtrace-sys 0.1.35 # MIT/Apache-2.0
+MODCARGO_CRATES += backtrace 0.3.48 # MIT/Apache-2.0
MODCARGO_CRATES += base64 0.9.3 # MIT/Apache-2.0
MODCARGO_CRATES += base64 0.10.1 # MIT/Apache-2.0
MODCARGO_CRATES += base64 0.11.0 # MIT/Apache-2.0
-MODCARGO_CRATES += bindgen 0.53.2 # BSD-3-Clause
-MODCARGO_CRATES += bit-set 0.5.1 # MIT/Apache-2.0
-MODCARGO_CRATES += bit-vec 0.5.1 # MIT/Apache-2.0
-MODCARGO_CRATES += bitflags0.3.3 # MIT/Apache-2.0
+MODCARGO_CRATES += base64 0.12.1 # MIT/Apache-2.0
+MODCARGO_CRATES += bindgen 0.53.3 # BSD-3-Clause
+MODCARGO_CRATES += bit-set 0.5.2 # MIT/Apache-2.0
+MODCARGO_CRATES += bit-vec 0.6.2 # MIT/Apache-2.0
MODCARGO_CRATES += bitflags0.9.1 # MIT/Apache-2.0
MODCARGO_CRATES += bitflags1.2.1 # MIT/Apache-2.0
MODCARGO_CRATES += blake2b_simd0.5.10 # MIT
@@ -62,17 +62,17 @@ MODCARGO_CRATES += block 0.1.6 # MIT
MODCARGO_CRATES += block-buffer0.7.3 # MIT OR Apache-2.0
MODCARGO_CRATES += block-cipher-trait 0.6.2 # MIT OR Apache-2.0
MODCARGO_CRATES += block-padding 0.1.5 # MIT OR Apache-2.0
-MODCARGO_CRATES += bumpalo 3.2.1 # MIT/Apache-2.0
+MODCARGO_CRATES += bumpalo 3.4.0 # MIT/Apache-2.0
MODCARGO_CRATES += byte-tools 0.3.1 # MIT OR Apache-2.0
MODCARGO_CRATES += byteorder 1.3.4 # Unlicense OR MIT
MODCARGO_CRATES += bytes 0.4.12 # MIT
MODCARGO_CRATES += bytes 0.5.4 # MIT
-MODCARGO_CRATES += cc 1.0.50 # MIT/Apache-2.0
+MODCARGO_CRATES += cc 1.0.54 # MIT/Apache-2.0
MODCARGO_CRATES += cexpr 0.4.0 # Apache-2.0/MIT
MODCARGO_CRATES += cfg-if 0.1.10 # MIT/Apache-2.0
MODCARGO_CRATES += chrono 0.4.11 # MIT/Apache-2.0
-MODCARGO_CRATES += clang-sys 0.29.2 # Apache-2.0
-MODCARGO_CRATES += clap2.33.0 # MIT
+MODCARGO_CRATES += clang-sys 0.29.3 # Apache-2.0
+MODCARGO_CRATES += clap2.33.1 # MIT
MODCARGO_CRATES += clipboard 0.5.0 # MIT / Apache-2.0
MODCARGO_CRATES += clipboard-win 2.2.0 # MIT
MODCARGO_CRATES += cloudabi0.0.3 # BSD-2-Clause
@@ -85,17 +85,18 @@ MODCARGO_CRATES += core-foundation 0.7.0
MODCARGO_CRATES += core-foundation-sys
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/28 07:55:50 Modified files: sysutils/google-cloud-sdk: Makefile sysutils/google-cloud-sdk/pkg: PLIST Log message: Move to python3 to unbreak. breakage reported by Evan Tann, thanks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/28 06:19:35 Modified files: math/z3: Makefile distinfo math/z3/patches: patch-scripts_mk_util_py Log message: update to z3-4.8.8
Re: update pango to 1.45.3 with backported patch
On Sun, Jun 28, 2020 at 12:44:09PM +0100, Stuart Henderson wrote:
> On 2020/06/28 12:53, Antoine Jacoutot wrote:
> > On Sat, Jun 27, 2020 at 04:14:35PM +0200, Christopher Zimmermann wrote:
> > > Hi,
> > >
> > > I'm trying to fix monospace bitmap font support for gvim (gtk-2 flavor),
> > > which has been broken since pango 1.44.
> > > It requires several changes:
> > >
> > > 1. fix metrics rounding in vim https://github.com/vim/vim/pull/6168,
> > > already included in our vim port.
> > > 2. fix fonttosfnt in our xenocara or rely on something like fontforge
> > > for
> > > the same job.
> > > (https://gitlab.freedesktop.org/xorg/app/fonttosfnt/-/merge_requests/7)
>
> FWIW the current fonttosfnt in xenocara might have some problems with
> spacing but is still good enough to create terminus font .otbs
> demonstrating the problem. Makefile fragment for terminus-font to
> convert:
>
> cd ${WRKSRC}; for i in ter-u*[nb].pcf; do fonttosfnt -c -g 2 -m 2 -o
> $${i%.pcf}.otb $$i; done
>
> Then run gvim, edit/select font, Terminus
>
> > > 3. fix pango, so it does not accidentally use unsupported pcf fonts when
> > > supported OpenType fonts are present:
> > >https://gitlab.gnome.org/GNOME/pango/-/issues/484
> > > 4. ship bitmap fonts in an OpenType container, too.
> > >
> > > Attached is a diff to update pango to the latest release and backport
> > > above
> > > mentioned fix.
> >
> > This is the latest *development* release, not stable.
> > I don't think we want this in our tree, do we?
>
> I agree. Here is a backport to the 1.44 branch which fixes the reported
> problem with gvim (which I don't normally ever use ;)
>
> I'll run with it on my workstation for now but I have not tested it
> extensively with other software.
>
> Current situation in ports is that .pcf fonts don't work with Pango (so
> generally what happens is it will fallback to a not-wanted font). *but*
> if we ship .otb versions alongside the .pcf then software using Pango
> will now see the .otb font and permit the font to be chosen, but will
> actually try to use the unsupported pcf not the otb, resulting in
> broken characters (the usual unicode "missing char" boxes).
>
> The alternative workaround is to change all ports installing pcf fonts
> and convert them to otb (removing the pcf) - but that doesn't help for
> user-installed fonts and maybe there are some programs that still
> require pcf. So fixing in pango seems the right thing to do (especially
> as it's a bug which they've acknowledged/fixed in master).
Thanks.
If this works out for you folks, OK with me.
>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/pango/Makefile,v
> retrieving revision 1.129
> diff -u -p -r1.129 Makefile
> --- Makefile 21 Dec 2019 14:38:47 - 1.129
> +++ Makefile 28 Jun 2020 11:33:05 -
> @@ -3,7 +3,7 @@
> COMMENT= library for layout and rendering of text
>
> GNOME_VERSION= 1.44.7
> -REVISION=0
> +REVISION=1
> GNOME_PROJECT= pango
>
> SHARED_LIBS += pango-1.0 3801.0 # 0.4400.7
> Index: patches/patch-pango_pangofc-fontmap_c
> ===
> RCS file: patches/patch-pango_pangofc-fontmap_c
> diff -N patches/patch-pango_pangofc-fontmap_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-pango_pangofc-fontmap_c 28 Jun 2020 11:33:05 -
> @@ -0,0 +1,110 @@
> +$OpenBSD$
> +
> +Backported from below commit (slightly different due to code reorganisation)
> +
> +From fe1ee773310bac83d8e5d3c062b13a51fb5fb4ad Mon Sep 17 00:00:00 2001
> +From: Khaled Hosny
> +Date: Thu, 25 Jun 2020 10:02:21 +0200
> +Subject: [PATCH] fcfontmap: Always reject unsupported font formats
> +
> +Fixes https://gitlab.gnome.org/GNOME/pango/-/issues/484 and
> +https://gitlab.gnome.org/GNOME/pango/-/issues/457
> +---
> + pango/pangofc-fontmap.c | 52 -
> + 1 file changed, 26 insertions(+), 26 deletions(-)
> +
> +Index: pango/pangofc-fontmap.c
> +--- pango/pangofc-fontmap.c.orig
> pango/pangofc-fontmap.c
> +@@ -808,8 +808,15 @@ pango_fc_patterns_get_pattern (PangoFcPatterns *pats)
> + }
> +
> + static gboolean
> +-pango_fc_is_supported_font_format (const char *fontformat)
> ++pango_fc_is_supported_font_format (FcPattern* pattern)
> + {
> ++ FcResult res;
> ++ const char *fontformat;
> ++
> ++ res = FcPatternGetString (pattern, FC_FONTFORMAT, 0, (FcChar8
> **)(void*));
> ++ if (res != FcResultMatch)
> ++return FALSE;
> ++
> + /* harfbuzz supports only SFNT fonts. */
> + /* FIXME: "CFF" is used for both CFF in OpenType and bare CFF files, but
> +* HarfBuzz does not support the later and FontConfig does not seem
> +@@ -831,11 +838,7 @@ filter_fontset_by_format (FcFontSet *fontset)
> +
> + for (i = 0; i < fontset->nfont; i++)
> + {
> +- FcResult res;
> +- const
Re: [update] audio/lmms enable ZynAddSubFX
On 2020/06/28 11:01, Kinichiro Inoguchi wrote: > On Sat, Jun 27, 2020 at 04:55:47PM +0100, Stuart Henderson wrote: > > On 2020/06/27 15:37, Kinichiro Inoguchi wrote: > > > Currently, lmms is disabling the ZynAddSubFX plugin. > > > This diff enables it. > > > > > > - remove patches/patch-plugins_CMakeLists_txt to build zynaddsubfx > > > - add required libraries to WANTLIB and LIB_DEPENDS > > > - bump up REVISION to 1 > > > > > > In this diff, I just delete all lines in patch-plugins_CMakeLists_txt. > > > I would like to 'cvs remove' it if this diff is ok. > > > > > > I had confirmed that build and install on my OpenBSD 6.7 (amd64) > > > succeeded. > > > And I could play ZynAddSubFX within lmms. > > > > > > ok? > > > > Doesn't seem to work here (I couldn't get it to work when I tried > > before when I updated the port to 1.2.0). > > > > I don't see ZynAddSubFX show up in the plugins list in lmms. > > And I see this on the console when starting lmms, > > > > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > > symbol(_ZTI6Effect) size mismatch, relink your program > > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > > symbol(_ZTV6Effect) size mismatch, relink your program > > "LMMS plugin /usr/local/lib/lmms/libZynAddSubFxCore.so does not have a > > plugin descriptor named ZynAddSubFxCore_plugin_descriptor!" > > Thanks for checking this. > > I'm getting the same console messages. > > $ lmms > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-inoguchi' > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > symbol(_ZTI6Effect) size mismatch, relink your program > lmms:/usr/local/lib/lmms/libZynAddSubFxCore.so: lmms : WARNING: > symbol(_ZTV6Effect) size mismatch, relink your program > "LMMS plugin /usr/local/lib/lmms/libZynAddSubFxCore.so does not have a plugin > descriptor named ZynAddSubFxCore_plugin_descriptor!" > > But I can see ZynAddSubFX in "Instrument Plugins" and "My Preset". > > I will attach my "make port-lib-depends-check" and "make config" below. > difference seems: > - I'm using lo.1 (recently I re-added liblo-0.31 to ports) > - Mine showed up patch apply section (intentionally omitted ?) > - I have no cmake warning (I installed 3.16.2) > - fluidsynth 1.1.6 vs 2.1.2 (I'm using pkg_add on my OpenBSD 6.7, > and the latest was fluidsynth-1.1.6p5) > > Can I try fluidsynth 2.1.2 to check if this is the problem ? > In that case, could you tell me where I can obtain 2.1.2, please. Apologies, I had forgotten about the local update to fluidsynth (I didn't successfully get sndio working so I had abandoned it, but still had it installed).. My liblo version is from testing your submission before it was committed, I think there was no change other than the version number. Replacing liblo and fluidsynth with the versions from current packages doesn't help. I only see Sine Oscillator (x4) and White Noise Source in instrument plugins. The missing linkages in port-lib-depends-check are still there: lmms-1.2.0p1(audio/lmms): Extra: fftw3.7 lo.1 mxml.0 "Extra" means that the libraries are listed in WANTLIB but are not used by any of the programs/libraries in the package, this might mean that static libraries are used instead, but it's a bit suspicious. Can you try updating your system? cmake 3.17 has been in the ports tree for a month, maybe it's related to that.
Re: update pango to 1.45.3 with backported patch
On 2020/06/28 12:53, Antoine Jacoutot wrote:
> On Sat, Jun 27, 2020 at 04:14:35PM +0200, Christopher Zimmermann wrote:
> > Hi,
> >
> > I'm trying to fix monospace bitmap font support for gvim (gtk-2 flavor),
> > which has been broken since pango 1.44.
> > It requires several changes:
> >
> > 1. fix metrics rounding in vim https://github.com/vim/vim/pull/6168,
> > already included in our vim port.
> > 2. fix fonttosfnt in our xenocara or rely on something like fontforgefor
> > the same job.
> > (https://gitlab.freedesktop.org/xorg/app/fonttosfnt/-/merge_requests/7)
FWIW the current fonttosfnt in xenocara might have some problems with
spacing but is still good enough to create terminus font .otbs
demonstrating the problem. Makefile fragment for terminus-font to
convert:
cd ${WRKSRC}; for i in ter-u*[nb].pcf; do fonttosfnt -c -g 2 -m 2 -o
$${i%.pcf}.otb $$i; done
Then run gvim, edit/select font, Terminus
> > 3. fix pango, so it does not accidentally use unsupported pcf fonts when
> > supported OpenType fonts are present:
> >https://gitlab.gnome.org/GNOME/pango/-/issues/484
> > 4. ship bitmap fonts in an OpenType container, too.
> >
> > Attached is a diff to update pango to the latest release and backport above
> > mentioned fix.
>
> This is the latest *development* release, not stable.
> I don't think we want this in our tree, do we?
I agree. Here is a backport to the 1.44 branch which fixes the reported
problem with gvim (which I don't normally ever use ;)
I'll run with it on my workstation for now but I have not tested it
extensively with other software.
Current situation in ports is that .pcf fonts don't work with Pango (so
generally what happens is it will fallback to a not-wanted font). *but*
if we ship .otb versions alongside the .pcf then software using Pango
will now see the .otb font and permit the font to be chosen, but will
actually try to use the unsupported pcf not the otb, resulting in
broken characters (the usual unicode "missing char" boxes).
The alternative workaround is to change all ports installing pcf fonts
and convert them to otb (removing the pcf) - but that doesn't help for
user-installed fonts and maybe there are some programs that still
require pcf. So fixing in pango seems the right thing to do (especially
as it's a bug which they've acknowledged/fixed in master).
Index: Makefile
===
RCS file: /cvs/ports/devel/pango/Makefile,v
retrieving revision 1.129
diff -u -p -r1.129 Makefile
--- Makefile21 Dec 2019 14:38:47 - 1.129
+++ Makefile28 Jun 2020 11:33:05 -
@@ -3,7 +3,7 @@
COMMENT= library for layout and rendering of text
GNOME_VERSION= 1.44.7
-REVISION= 0
+REVISION= 1
GNOME_PROJECT= pango
SHARED_LIBS += pango-1.0 3801.0 # 0.4400.7
Index: patches/patch-pango_pangofc-fontmap_c
===
RCS file: patches/patch-pango_pangofc-fontmap_c
diff -N patches/patch-pango_pangofc-fontmap_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-pango_pangofc-fontmap_c 28 Jun 2020 11:33:05 -
@@ -0,0 +1,110 @@
+$OpenBSD$
+
+Backported from below commit (slightly different due to code reorganisation)
+
+From fe1ee773310bac83d8e5d3c062b13a51fb5fb4ad Mon Sep 17 00:00:00 2001
+From: Khaled Hosny
+Date: Thu, 25 Jun 2020 10:02:21 +0200
+Subject: [PATCH] fcfontmap: Always reject unsupported font formats
+
+Fixes https://gitlab.gnome.org/GNOME/pango/-/issues/484 and
+https://gitlab.gnome.org/GNOME/pango/-/issues/457
+---
+ pango/pangofc-fontmap.c | 52 -
+ 1 file changed, 26 insertions(+), 26 deletions(-)
+
+Index: pango/pangofc-fontmap.c
+--- pango/pangofc-fontmap.c.orig
pango/pangofc-fontmap.c
+@@ -808,8 +808,15 @@ pango_fc_patterns_get_pattern (PangoFcPatterns *pats)
+ }
+
+ static gboolean
+-pango_fc_is_supported_font_format (const char *fontformat)
++pango_fc_is_supported_font_format (FcPattern* pattern)
+ {
++ FcResult res;
++ const char *fontformat;
++
++ res = FcPatternGetString (pattern, FC_FONTFORMAT, 0, (FcChar8
**)(void*));
++ if (res != FcResultMatch)
++return FALSE;
++
+ /* harfbuzz supports only SFNT fonts. */
+ /* FIXME: "CFF" is used for both CFF in OpenType and bare CFF files, but
+* HarfBuzz does not support the later and FontConfig does not seem
+@@ -831,11 +838,7 @@ filter_fontset_by_format (FcFontSet *fontset)
+
+ for (i = 0; i < fontset->nfont; i++)
+ {
+- FcResult res;
+- const char *s;
+-
+- res = FcPatternGetString (fontset->fonts[i], FC_FONTFORMAT, 0, (FcChar8
**)(void*));
+- if (res == FcResultMatch && pango_fc_is_supported_font_format (s))
++ if (pango_fc_is_supported_font_format (fontset->fonts[i]))
+ FcFontSetAdd (result, FcPatternDuplicate (fontset->fonts[i]));
+ }
+
+@@ -851,34 +854,32 @@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/06/28 04:58:25 Modified files: infrastructure/bin: register-plist Log message: register-plist is a logical place to be able to save stuff elsewhere, set up to be able to save manpages
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/28 04:55:41 Modified files: graphics/jpeg : Tag: OPENBSD_6_7 Makefile distinfo graphics/jpeg/patches: Tag: OPENBSD_6_7 patch-CMakeLists_txt Log message: update to libjpeg-turbo-2.0.5, including a fix for CVE-2020-13790 in the PPM reader that caused a buffer overrun in cjpeg, TJBench, or the tjLoadImage() function if one of the values in a binary PPM/PGM input file exceeded the maximum value defined in the file's header and that maximum value was less than 255. >From Brad.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/28 04:55:33 Modified files: graphics/jpeg : Makefile distinfo graphics/jpeg/patches: patch-CMakeLists_txt Log message: update to libjpeg-turbo-2.0.5, including a fix for CVE-2020-13790 in the PPM reader that caused a buffer overrun in cjpeg, TJBench, or the tjLoadImage() function if one of the values in a binary PPM/PGM input file exceeded the maximum value defined in the file's header and that maximum value was less than 255. >From Brad.
Re: update pango to 1.45.3 with backported patch
On Sat, Jun 27, 2020 at 04:14:35PM +0200, Christopher Zimmermann wrote: > Hi, > > I'm trying to fix monospace bitmap font support for gvim (gtk-2 flavor), > which has been broken since pango 1.44. > It requires several changes: > > 1. fix metrics rounding in vim https://github.com/vim/vim/pull/6168, > already included in our vim port. > 2. fix fonttosfnt in our xenocara or rely on something like fontforgefor > the same job. > (https://gitlab.freedesktop.org/xorg/app/fonttosfnt/-/merge_requests/7) > 3. fix pango, so it does not accidentally use unsupported pcf fonts when > supported OpenType fonts are present: >https://gitlab.gnome.org/GNOME/pango/-/issues/484 > 4. ship bitmap fonts in an OpenType container, too. > > Attached is a diff to update pango to the latest release and backport above > mentioned fix. This is the latest *development* release, not stable. I don't think we want this in our tree, do we? -- Antoine
Re: redis-sentinel segfault workaround
On Sun, Jun 28, 2020 at 12:52:35PM +0200, Theo Buehler wrote: > On Fri, Jun 26, 2020 at 10:01:00PM -0700, Nam Nguyen wrote: > > Theo Buehler writes: > > > > > I was given a reliable reproducer for the sentinel segfault that seems > > > to be present since at least Redis 4. I can only reproduce on amd64 and > > > only when compiling with -O1 or -O2, but not with -O0. > > > > > >>From what I can tell, it is an out-of-bounds access trying to read from > > > a page without read permissions, hence the process is killed. It's > > > always the same line 2216 in sentinel.c: > > > > Here is a diff resolving the out-of-bounds memory access. > > Thank you very much for figuring this out. It never occurred to me to > look *after* the point where Redis crashed according to gdb, but once > you point it out the problem is clear... > > It would be great if you could make a PR https://github.com/antirez/redis > so you get proper credit, but if you don't want to, I can also take care > of this. I forgot to say that I committed this.
Re: redis-sentinel segfault workaround
On Fri, Jun 26, 2020 at 10:01:00PM -0700, Nam Nguyen wrote: > Theo Buehler writes: > > > I was given a reliable reproducer for the sentinel segfault that seems > > to be present since at least Redis 4. I can only reproduce on amd64 and > > only when compiling with -O1 or -O2, but not with -O0. > > > >>From what I can tell, it is an out-of-bounds access trying to read from > > a page without read permissions, hence the process is killed. It's > > always the same line 2216 in sentinel.c: > > Here is a diff resolving the out-of-bounds memory access. Thank you very much for figuring this out. It never occurred to me to look *after* the point where Redis crashed according to gdb, but once you point it out the problem is clear... It would be great if you could make a PR https://github.com/antirez/redis so you get proper credit, but if you don't want to, I can also take care of this.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/06/28 04:47:15 Modified files: databases/redis: Makefile Added files: databases/redis/patches: patch-src_sentinel_c Log message: Avoid an out-of-bounds read in the redis-sentinel The Redis sentinel would crash with a segfault after a few minutes because it tried to read from a page without read permissions. Check up front whether the sds is long enough to contain redis:slave or redis:master before memcmp() as is done everywhere else in sentinelRefreshInstanceInfo(). >From Nam Nguyen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/06/28 04:33:01 Modified files: databases/redis/patches: patch-src_Makefile Log message: add a few comments to summarize the many changes in src/Makefile
