Re: CVS: cvs.openbsd.org: ports
On Sat, Jan 09, 2021 at 11:08:24PM -0700, Kurt Mosiejczuk wrote: > CVSROOT: /cvs > Module name: ports > Changes by: k...@cvs.openbsd.org2021/01/09 23:08:24 > > Modified files: > www/purritobin : Makefile > > Log message: > purritobin has never built on base-gcc arches and isn't likely to soon. > > Change COMPILER to just base-clang This was with suggestions by and ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/09 23:08:24 Modified files: www/purritobin : Makefile Log message: purritobin has never built on base-gcc arches and isn't likely to soon. Change COMPILER to just base-clang
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/09 22:44:34 Modified files: devel/universal-ctags: Makefile Log message: universal-ctags uses C99 constructs so base-gcc needs to be informed Fix build no sparc64 ok rsadowski@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2021/01/09 22:20:37 Modified files: devel/xtensa-esp32-elf/gcc-bootstrap: Makefile Log message: repair
[sparc64/base-gcc] Fix build of net/toxic
toxic uses C99 constructs so base-gcc needs to be told that.
This fixes the build on sparc64
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/net/toxic/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile3 Jan 2021 19:36:09 - 1.9
+++ Makefile10 Jan 2021 01:29:19 -
@@ -44,6 +44,11 @@ LIB_DEPENDS += devel/libnotify
RUN_DEPENDS = devel/desktop-file-utils
.endif
+.include
+.if !${PROPERTIES:Mclang}
+CFLAGS += -std=gnu99
+.endif
+
NO_TEST = Yes
pre-configure:
Re: dev and deve and devel
On 2021-01-09, Jan Stary wrote: > The current ports.tar.gz contains a dev/ and deve/ directory > beside the expected devel/ category. Is that intended? The creation of those directories wasn't intended as such, they're the result of cvs import accidents, but once a directory has been created in CVS, it can never be deleted from the repository. However, the -P option will tell cvs checkout or update to remove now empty directories from a checked-out tree. Which ports.tar.gz are you referring to? They're not in here: https://ftp.openbsd.org/pub/OpenBSD/snapshots/ports.tar.gz -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [NEW] graphics/openvdb
Ping On Sun, Jan 03, 2021 at 10:34:50AM +0100, Rafael Sadowski wrote: > On Sun Jan 03, 2021 at 07:47:29AM +, Dimitri Karamazov wrote: > > Ping > > > > On Thu, Dec 10, 2020 at 02:16:37PM +, Dimitri Karamazov wrote: > > > Information for inst:openvdb-7.1.0 > > > > > > Comment: > > > tools for storage and manipulation of volumetric data > > > > > > OpenVDB is an Academy Award-winning open-source C++ library comprising a > > > novel > > > hierarchical data structure and a suite of tools for the efficient > > > storage and > > > manipulation of sparse volumetric data discretized on three-dimensional > > > grids. > > > It was developed by DreamWorks Animation for use in volumetric > > > applications > > > typically encountered in feature film production and is now maintained by > > > the > > > Academy Software Foundation (ASWF). > > > > > > Maintainer: Dimitri Karamazov > > > > > > WWW: https://www.openvdb.org/ > > > > > > Build, run tested with blender. > > > No regression tests available. > > > > > > Any comments,OK's? > > > > Port-wise it looks good to me. If someone wants to import, ok rsadowski@ openvdb.tar.gz Description: Binary data
Re: [NEW] graphics/alembic
Ping On Sun, Jan 03, 2021 at 04:48:16PM +, Dimitri Karamazov wrote: > On Sun, Jan 03, 2021 at 11:02:56AM +0100, Rafael Sadowski wrote: > > On Sun Jan 03, 2021 at 07:48:24AM +, Dimitri Karamazov wrote: > > > Ping > > > > > > On Sun, Dec 13, 2020 at 03:51:14AM +, Dimitri Karamazov wrote: > > > > Information for inst:alembic-1.7.16 > > > > > > > > Comment: > > > > open framework for storing and sharing scene data > > > > > > > > Description: > > > > Alembic is an open computer graphics interchange framework. It distills > > > > complex, animated scenes into a non-procedural, application-independent > > > > set of baked geometric results. This "distillation" of scenes into baked > > > > geometry is exactly analogous to the distillation of lighting and > > > > rendering scenes into rendered image data. > > > > > > > > Alembic is focused on efficiently storing the computed results of > > > > complex > > > > procedural geometric constructions. It is very specifically NOT > > > > concerned > > > > with storing the complex dependency graph of procedural tools used to > > > > create the computed results. > > > > > > > > Maintainer: Dimitri Karamazov > > > > > > > > WWW: https://www.alembic.io/ > > > > > > > > Build, run tested with blender. > > > > All regression tests pass. > > > > > > > > Any comments,OK's? > > > > > > > > > > Broken tarball? > > Sad, must be the recent kernel panic. > Reattached, tried and tested. alembic.tar.gz Description: Binary data
Re: [NEW] graphics/opensubdiv
Ping
On Sun, Jan 03, 2021 at 05:00:16PM +, Dimitri Karamazov wrote:
> On Sun, Jan 03, 2021 at 11:02:38AM +0100, Rafael Sadowski wrote:
> > On Sun Jan 03, 2021 at 07:50:58AM +, Dimitri Karamazov wrote:
> > > Ping
> > >
> > > On Mon, Dec 28, 2020 at 06:50:24AM +, Dimitri Karamazov wrote:
> > > > On Mon, Dec 21, 2020 at 12:07:28PM +, Dimitri Karamazov wrote:
> > > > Ping
> > > >
> > > > > Ping
> > > > >
> > > > > On Sun, Dec 13, 2020 at 07:01:14PM +, Dimitri Karamazov wrote:
> > > > > > On Sun, Dec 13, 2020 at 11:23:10AM -0500, Andrea Fleckenstein wrote:
> > > > > > > Dimitri Karamazov writes:
> > > > > > >
> > > > > > > > Information for inst:opensubdiv-3.4.3
> > > > > > > >
> > > > > > > > Comment:
> > > > > > > > open-source subdivision surface library
> > > > > > > >
> > > > > > > > Description:
> > > > > > > > OpenSubdiv is a set of open source libraries that implement
> > > > > > > > high performance
> > > > > > > > subdivision surface (subdiv) evaluation on massively parallel
> > > > > > > > CPU and GPU
> > > > > > > > architectures. This codepath is optimized for drawing deforming
> > > > > > > > subdivs with
> > > > > > > > static topology at interactive framerates. The resulting limit
> > > > > > > > surface
> > > > > > > > matches Pixar's Renderman to numerical precision.
> > > > > > > >
> > > > > > > > Maintainer: Dimitri Karamazov
> > > > > > > >
> > > > > > > > WWW: https://graphics.pixar.com/opensubdiv/
> > > > > > > >
> > > > > > > > This port is pretty provides a vital functionality for blender.
> > > > > > > > Build, run tested with blender
> > > > > > > > All regression tests pass.
> > > > > > > >
> > > > > > > > Any comments,OK's?
> > > > > > >
> > > > > > > It doesn't build on my machine (amd64). ld is unable to find -lrt
> > > > > > > and -ldl,
> > > > > > Ah, must've cleared the sed command to remove that single instance
> > > > > > while
> > > > > > cleaning the Makefile. Now I've included it in a patch.
> > > > > >
> > > > > > > WANTLIB += ${COMPILER_LIBCXX} GL ICE SM X11 Xcursor Xext Xi
> > > > > > > Xinerama
> > > > > > > WANTLIB += Xrandr Xxf86vm c m tbb
> > > > > > >
> > > > > > > So not sure if these extra ones are needed if just for regression
> > > > > > > test.
> > > > > > > Also seems like most of the wantlib anyway is just for the GPU
> > > > > > > lib,
> > > > > > > wondering if we should even install this? Not sure if we could
> > > > > > > use it
> > > > > > > even if we wanted to.
> > > > > >
> > > > > > While building all option must be turned on since it allows for a
> > > > > > more
> > > > > > thorough testing. Just delete those files post-install. They won't
> > > > > > be
> > > > > > cluttering the WANTLIB then. Also 2 regression tests fail out of 16.
> > > > > > Let me know if it is same for you.
> > > > > >
> > > > > > regards,
> > > > > > Dimitri
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> > I ran into:
> >
> > -- Set runtime path of
> > "/usr/ports/pobj/opensubdiv-3.4.3/fake-amd64/usr/local/bin/tutorials/osd_tutorial_0"
> > to "/usr/local/lib"
> > rm -rf /usr/ports/pobj/opensubdiv-3.4.3/fake-amd64/usr/local/bin/tutorials
> > rm
> > /usr/ports/pobj/opensubdiv-3.4.3/fake-amd64/usr/local/bin/{far,gl,hbr,osd}*
> > rm: /usr/ports/pobj/opensubdiv-3.4.3/fake-amd64/usr/local/bin/gl*: No such
> > file or directory
> > rm: /usr/ports/pobj/opensubdiv-3.4.3/fake-amd64/usr/local/bin/osd*: No such
> > file or directory
> >
>
> Sad, must've made some changes before this ping.
> Added the graphics/glfw build dep which is required
> for building those and corresponding tests.
> I've built and run tested right now.
opensubdiv.tar.gz
Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2021/01/09 16:00:29 Added files: www/ruby-passenger/patches: patch-src_agent_Core_ApplicationPool_Group_ProcessListManagement_cpp patch-src_agent_Core_ApplicationPool_Pool_GarbageCollection_cpp patch-src_cxx_supportlib_oxt_system_calls_cpp Log message: fix www/ruby-passenger build with libc++ 10.0, from upstream make passenger compile on FreeBSD 13 https://github.com/phusion/passenger/commit/d0d660bbdbb51079ad6012596810273b1616
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 15:27:29 Removed files: x11/xsettingsd/patches: patch-SConstruct Log message: rm unnecessary patch
Re: bsd.port.mk: add .rpm to EXTRACT_CASES
On Sat, Jan 09, 2021 at 10:45:23PM +0100, Marc Espie wrote:
> No objection from me, but you need a small snippet for bsd.port.mk(5) as
> well.
Right, thanks.
Index: share/man//man5/bsd.port.mk.5
===
RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v
retrieving revision 1.535
diff -u -p -r1.535 bsd.port.mk.5
--- share/man//man5/bsd.port.mk.5 27 Aug 2020 09:29:16 - 1.535
+++ share/man//man5/bsd.port.mk.5 9 Jan 2021 21:53:58 -
@@ -1704,6 +1704,8 @@ do
unzip -q ${FULLDISTDIR}/$$archive -d ${WRKDIR} ${EXTRACT_FILES};;
*.tar.bz2|*.tbz2|*.tbz)
bzip2 -dc ${FULLDISTDIR}/$$archive| tar -xf - -- ${EXTRACT_FILES};;
+ *.rpm)
+ cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/$$archive | cpio -id --
${EXTRACT_FILES};;
*.shar.gz|*.shar.Z|*.sh.Z|*.sh.gz)
gzcat ${FULLDISTDIR}/$$archive | /bin/sh;;
*.shar|*.sh)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 14:51:09 Modified files: net/quagga : Makefile net/quagga/pkg : PLIST Removed files: net/quagga/patches: patch-configure_ac patch-lib_sockopt_c Log message: Remove the hack from net/quagga now that we have ip_mreqn. If you're using ospf/rip with quagga please test and report back if this introduces a problem.
Re: bsd.port.mk: add .rpm to EXTRACT_CASES
On Sat, Jan 09, 2021 at 10:38:36PM +0100, Klemens Nanni wrote:
> Coming from sysutils/mdprint I want ordinary distfiles handling.
> Since we have more than one port using RPM files, here is a straight
> forward diff to unify each of their quirky handling.
>
> Less code, no plist change and we can use EXTRACT_FILES if need be.
Pardon, here's there correct diff that actually simplifies kopano/webapp
as intended.
Cc'ed robert as its maintianer.
Index: infrastructure/mk/bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1542
diff -u -p -r1.1542 bsd.port.mk
--- infrastructure/mk/bsd.port.mk 26 Jun 2020 11:51:16 - 1.1542
+++ infrastructure/mk/bsd.port.mk 9 Jan 2021 21:04:00 -
@@ -1385,6 +1385,11 @@ PATCH_CASES += *.bz2) \
${BZIP2} -d <$$patchfile | ${PATCH} ${PATCH_DIST_ARGS};;
.endif
+.if !empty(_LIST_EXTRACTED:M*.rpm)
+BUILD_DEPENDS += converters/rpm2cpio
+EXTRACT_CASES += *.rpm) \
+ cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/$$archive | cpio -id --
${EXTRACT_FILES};;
+.endif
_PERL_FIX_SHAR ?= perl -ne 'print if $$s || ($$s = m:^\#(\!\s*/bin/sh\s*| This
is a shell archive):)'
Index: sysutils/mdprint/Makefile
===
RCS file: /cvs/ports/sysutils/mdprint/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- sysutils/mdprint/Makefile 28 Dec 2020 04:01:48 - 1.5
+++ sysutils/mdprint/Makefile 9 Jan 2021 21:11:03 -
@@ -17,9 +17,6 @@ PERMIT_PACKAGE = Yes
MASTER_SITES =
https://yum.oracle.com/repo/OracleLinux/OL6/latest/source/getPackageSource/
EXTRACT_SUFX = .el6.src.rpm
-EXTRACT_ONLY = # empty
-
-BUILD_DEPENDS =converters/rpm2cpio
MODULES = lang/python
MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
@@ -31,9 +28,7 @@ NO_TEST = Yes
# the SRC RPM contains a SPEC file and the actual uncompressed source tarball
post-extract:
- cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/${DISTFILES} | \
- cpio -i ${DISTNAME}.tar
- ${TAR} -C${WRKDIR} -xf${WRKDIR}/${DISTNAME}.tar ${DISTNAME}/${MDPRINT}
+ cd ${WRKDIR} && ${TAR} -xf./${DISTNAME}.tar
do-build:
2to3-${MODPY_VERSION} --no-diffs -W ${WRKSRC}/${MDPRINT}
Index: mail/kopano/webapp/Makefile
===
RCS file: /cvs/ports/mail/kopano/webapp/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- mail/kopano/webapp/Makefile 30 May 2020 08:50:13 - 1.21
+++ mail/kopano/webapp/Makefile 9 Jan 2021 21:49:03 -
@@ -24,21 +24,18 @@ MINOR= 2765
RPMVER=1630.1
PKGNAME= kopano-webapp-${WAPP_VERSION}.${MINOR}
-EXTRACT_SUFX= # empty
+EXTRACT_SUFX= .noarch.rpm
#
https://download.kopano.io/community/webapp%3A/webapp-4.1.2765%2B1630.1.dbabb97-RHEL_7-noarch.tar.gz
.for _dfile in ${PLUGINS}
-EDISTFILES+=kopano-webapp-plugin-${_dfile}.noarch.rpm
+DISTFILES+=kopano-webapp-plugin-${_dfile}${EXTRACT_SUFX}
.endfor
-EDISTFILES+=
kopano-webapp-lang-${WAPP_VERSION}.${MINOR}-${RPMVER}.noarch.rpm
-EXTRACT_ONLY= ${EDISTFILES:C/:[0-9]$//}
+DISTFILES+=
kopano-webapp-lang-${WAPP_VERSION}.${MINOR}-${RPMVER}${EXTRACT_SUFX}
-DISTFILES+=kopano-webapp-${WAPP_VERSION}.${MINOR}-${RPMVER}.noarch.rpm
-DISTFILES+=kopano-webapp-plugin-files-3.0.0.42-362.1.noarch.rpm \
-
kopano-webapp-plugin-filesbackend-owncloud-3.0.0.15-115.1.noarch.rpm \
- kopano-webapp-plugin-filesbackend-smb-3.0.0.14-82.1.noarch.rpm
-
-DISTFILES+=${EDISTFILES}
+DISTFILES+=kopano-webapp-${WAPP_VERSION}.${MINOR}-${RPMVER}${EXTRACT_SUFX}
+DISTFILES+=kopano-webapp-plugin-files-3.0.0.42-362.1${EXTRACT_SUFX} \
+
kopano-webapp-plugin-filesbackend-owncloud-3.0.0.15-115.1${EXTRACT_SUFX} \
+
kopano-webapp-plugin-filesbackend-smb-3.0.0.14-82.1${EXTRACT_SUFX}
MASTER_SITES= http://nerd.hu/distfiles/kopano-webapp/
@@ -49,7 +46,6 @@ MODULES= lang/php
MODPHP_BUILDDEP=No
MODPHP_RUNDEP= No
-BUILD_DEPENDS= converters/rpm2cpio
RUN_DEPENDS= mail/kopano/core,-mapi # php-mapi
NO_BUILD= Yes
@@ -62,12 +58,6 @@ INSTDIR= ${PREFIX}/kopano-webapp
TINSTDIR= ${TRUEPREFIX}/kopano-webapp
SUBST_VARS=INSTDIR TINSTDIR
-
-do-extract:
-.for _dfile in ${DISTFILES}
- cd ${WRKDIR} && \
- ${LOCALBASE}/bin/rpm2cpio ${FULLDISTDIR}/${_dfile} | cpio -id
-.endfor
pre-configure:
${SUBST_CMD} ${WRKSRC}/etc/kopano/webapp/config.php
Re: bsd.port.mk: add .rpm to EXTRACT_CASES
On Sat, Jan 09, 2021 at 10:38:36PM +0100, Klemens Nanni wrote:
> Coming from sysutils/mdprint I want ordinary distfiles handling.
> Since we have more than one port using RPM files, here is a straight
> forward diff to unify each of their quirky handling.
>
> Less code, no plist change and we can use EXTRACT_FILES if need be.
>
> OK?
>
> Index: infrastructure/mk/bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1542
> diff -u -p -r1.1542 bsd.port.mk
> --- infrastructure/mk/bsd.port.mk 26 Jun 2020 11:51:16 - 1.1542
> +++ infrastructure/mk/bsd.port.mk 9 Jan 2021 21:04:00 -
> @@ -1385,6 +1385,11 @@ PATCH_CASES += *.bz2) \
> ${BZIP2} -d <$$patchfile | ${PATCH} ${PATCH_DIST_ARGS};;
> .endif
>
> +.if !empty(_LIST_EXTRACTED:M*.rpm)
> +BUILD_DEPENDS += converters/rpm2cpio
> +EXTRACT_CASES += *.rpm) \
> + cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/$$archive | cpio -id --
> ${EXTRACT_FILES};;
> +.endif
>
> _PERL_FIX_SHAR ?= perl -ne 'print if $$s || ($$s = m:^\#(\!\s*/bin/sh\s*|
> This is a shell archive):)'
>
> Index: sysutils/mdprint/Makefile
> ===
> RCS file: /cvs/ports/sysutils/mdprint/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- sysutils/mdprint/Makefile 28 Dec 2020 04:01:48 - 1.5
> +++ sysutils/mdprint/Makefile 9 Jan 2021 21:11:03 -
> @@ -17,9 +17,6 @@ PERMIT_PACKAGE =Yes
>
> MASTER_SITES =
> https://yum.oracle.com/repo/OracleLinux/OL6/latest/source/getPackageSource/
> EXTRACT_SUFX = .el6.src.rpm
> -EXTRACT_ONLY = # empty
> -
> -BUILD_DEPENDS = converters/rpm2cpio
>
> MODULES =lang/python
> MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> @@ -31,9 +28,7 @@ NO_TEST = Yes
>
> # the SRC RPM contains a SPEC file and the actual uncompressed source tarball
> post-extract:
> - cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/${DISTFILES} | \
> - cpio -i ${DISTNAME}.tar
> - ${TAR} -C${WRKDIR} -xf${WRKDIR}/${DISTNAME}.tar ${DISTNAME}/${MDPRINT}
> + cd ${WRKDIR} && ${TAR} -xf./${DISTNAME}.tar
>
> do-build:
> 2to3-${MODPY_VERSION} --no-diffs -W ${WRKSRC}/${MDPRINT}
> Index: mail/kopano/webapp/Makefile
> ===
> RCS file: /cvs/ports/mail/kopano/webapp/Makefile,v
> retrieving revision 1.21
> diff -u -p -r1.21 Makefile
> --- mail/kopano/webapp/Makefile 30 May 2020 08:50:13 - 1.21
> +++ mail/kopano/webapp/Makefile 9 Jan 2021 21:18:51 -
> @@ -24,19 +24,19 @@ MINOR=2765
> RPMVER= 1630.1
> PKGNAME= kopano-webapp-${WAPP_VERSION}.${MINOR}
>
> -EXTRACT_SUFX=# empty
> +EXTRACT_SUFX=.noarch.rpm
>
> #
> https://download.kopano.io/community/webapp%3A/webapp-4.1.2765%2B1630.1.dbabb97-RHEL_7-noarch.tar.gz
> .for _dfile in ${PLUGINS}
> -EDISTFILES+=kopano-webapp-plugin-${_dfile}.noarch.rpm
> +EDISTFILES+=kopano-webapp-plugin-${_dfile}${EXTRACT_SUFX}
> .endfor
> -EDISTFILES+=
> kopano-webapp-lang-${WAPP_VERSION}.${MINOR}-${RPMVER}.noarch.rpm
> +EDISTFILES+=
> kopano-webapp-lang-${WAPP_VERSION}.${MINOR}-${RPMVER}${EXTRACT_SUFX}
> EXTRACT_ONLY= ${EDISTFILES:C/:[0-9]$//}
>
> -DISTFILES+= kopano-webapp-${WAPP_VERSION}.${MINOR}-${RPMVER}.noarch.rpm
> -DISTFILES+= kopano-webapp-plugin-files-3.0.0.42-362.1.noarch.rpm \
> -
> kopano-webapp-plugin-filesbackend-owncloud-3.0.0.15-115.1.noarch.rpm \
> - kopano-webapp-plugin-filesbackend-smb-3.0.0.14-82.1.noarch.rpm
> +DISTFILES+= kopano-webapp-${WAPP_VERSION}.${MINOR}-${RPMVER}${EXTRACT_SUFX}
> +DISTFILES+= kopano-webapp-plugin-files-3.0.0.42-362.1${EXTRACT_SUFX} \
> +
> kopano-webapp-plugin-filesbackend-owncloud-3.0.0.15-115.1${EXTRACT_SUFX} \
> +
> kopano-webapp-plugin-filesbackend-smb-3.0.0.14-82.1${EXTRACT_SUFX}
>
> DISTFILES+= ${EDISTFILES}
>
> @@ -49,7 +49,6 @@ MODULES=lang/php
> MODPHP_BUILDDEP=No
> MODPHP_RUNDEP= No
>
> -BUILD_DEPENDS= converters/rpm2cpio
> RUN_DEPENDS= mail/kopano/core,-mapi # php-mapi
>
> NO_BUILD=Yes
No objection from me, but you need a small snippet for bsd.port.mk(5) as
well.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 14:43:09 Modified files: net/nepim : Makefile net/nepim/patches: patch-Makefile Log message: unbreak net/nepim now we have struct ip_mreqn
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/09 14:41:16 Modified files: devel/arm-none-eabi/gcc-linaro: Makefile devel/msp430/gcc: Makefile devel/avr/gcc : Makefile devel/ti-msp430gcc: Makefile devel/avr32/gcc-bootstrap: Makefile devel/riscv-elf/gcc: Makefile devel/xtensa-lx106-elf/gcc-bootstrap: Makefile devel/xtensa-elf/gcc: Makefile devel/xtensa-esp32-elf/gcc-bootstrap: Makefile Added files: devel/arm-none-eabi/gcc-linaro/patches: vecstep-gcc_tree-vect-loop_c devel/msp430/gcc/patches: vecstep-gcc_tree-vect-loop_c devel/avr/gcc/patches: vecstep-gcc_tree-vect-loop_c devel/ti-msp430gcc/patches: vecstep-sources_tools_gcc_tree-vect-loop_c devel/avr32/gcc-bootstrap/patches: vecstep-gcc_tree-vect-transform_c devel/riscv-elf/gcc/patches: vecstep-gcc_tree-vect-loop_c devel/xtensa-lx106-elf/gcc-bootstrap/patches: vecstep-gcc_tree-vect-loop_c devel/xtensa-elf/gcc/patches: vecstep-gcc_tree-vect-loop_c devel/xtensa-esp32-elf/gcc-bootstrap/patches: vecstep-gcc_tree-vect-loop_c Log message: fix building the various gcc crosscompilers on powerpc64 by redefining vec_step as clang already defines this symbol itself. this approach was discussed with upstream gcc by, and patch copied from, freeBSD
bsd.port.mk: add .rpm to EXTRACT_CASES
Coming from sysutils/mdprint I want ordinary distfiles handling.
Since we have more than one port using RPM files, here is a straight
forward diff to unify each of their quirky handling.
Less code, no plist change and we can use EXTRACT_FILES if need be.
OK?
Index: infrastructure/mk/bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1542
diff -u -p -r1.1542 bsd.port.mk
--- infrastructure/mk/bsd.port.mk 26 Jun 2020 11:51:16 - 1.1542
+++ infrastructure/mk/bsd.port.mk 9 Jan 2021 21:04:00 -
@@ -1385,6 +1385,11 @@ PATCH_CASES += *.bz2) \
${BZIP2} -d <$$patchfile | ${PATCH} ${PATCH_DIST_ARGS};;
.endif
+.if !empty(_LIST_EXTRACTED:M*.rpm)
+BUILD_DEPENDS += converters/rpm2cpio
+EXTRACT_CASES += *.rpm) \
+ cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/$$archive | cpio -id --
${EXTRACT_FILES};;
+.endif
_PERL_FIX_SHAR ?= perl -ne 'print if $$s || ($$s = m:^\#(\!\s*/bin/sh\s*| This
is a shell archive):)'
Index: sysutils/mdprint/Makefile
===
RCS file: /cvs/ports/sysutils/mdprint/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- sysutils/mdprint/Makefile 28 Dec 2020 04:01:48 - 1.5
+++ sysutils/mdprint/Makefile 9 Jan 2021 21:11:03 -
@@ -17,9 +17,6 @@ PERMIT_PACKAGE = Yes
MASTER_SITES =
https://yum.oracle.com/repo/OracleLinux/OL6/latest/source/getPackageSource/
EXTRACT_SUFX = .el6.src.rpm
-EXTRACT_ONLY = # empty
-
-BUILD_DEPENDS =converters/rpm2cpio
MODULES = lang/python
MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
@@ -31,9 +28,7 @@ NO_TEST = Yes
# the SRC RPM contains a SPEC file and the actual uncompressed source tarball
post-extract:
- cd ${WRKDIR} && rpm2cpio ${FULLDISTDIR}/${DISTFILES} | \
- cpio -i ${DISTNAME}.tar
- ${TAR} -C${WRKDIR} -xf${WRKDIR}/${DISTNAME}.tar ${DISTNAME}/${MDPRINT}
+ cd ${WRKDIR} && ${TAR} -xf./${DISTNAME}.tar
do-build:
2to3-${MODPY_VERSION} --no-diffs -W ${WRKSRC}/${MDPRINT}
Index: mail/kopano/webapp/Makefile
===
RCS file: /cvs/ports/mail/kopano/webapp/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- mail/kopano/webapp/Makefile 30 May 2020 08:50:13 - 1.21
+++ mail/kopano/webapp/Makefile 9 Jan 2021 21:18:51 -
@@ -24,19 +24,19 @@ MINOR= 2765
RPMVER=1630.1
PKGNAME= kopano-webapp-${WAPP_VERSION}.${MINOR}
-EXTRACT_SUFX= # empty
+EXTRACT_SUFX= .noarch.rpm
#
https://download.kopano.io/community/webapp%3A/webapp-4.1.2765%2B1630.1.dbabb97-RHEL_7-noarch.tar.gz
.for _dfile in ${PLUGINS}
-EDISTFILES+=kopano-webapp-plugin-${_dfile}.noarch.rpm
+EDISTFILES+=kopano-webapp-plugin-${_dfile}${EXTRACT_SUFX}
.endfor
-EDISTFILES+=
kopano-webapp-lang-${WAPP_VERSION}.${MINOR}-${RPMVER}.noarch.rpm
+EDISTFILES+=
kopano-webapp-lang-${WAPP_VERSION}.${MINOR}-${RPMVER}${EXTRACT_SUFX}
EXTRACT_ONLY= ${EDISTFILES:C/:[0-9]$//}
-DISTFILES+=kopano-webapp-${WAPP_VERSION}.${MINOR}-${RPMVER}.noarch.rpm
-DISTFILES+=kopano-webapp-plugin-files-3.0.0.42-362.1.noarch.rpm \
-
kopano-webapp-plugin-filesbackend-owncloud-3.0.0.15-115.1.noarch.rpm \
- kopano-webapp-plugin-filesbackend-smb-3.0.0.14-82.1.noarch.rpm
+DISTFILES+=kopano-webapp-${WAPP_VERSION}.${MINOR}-${RPMVER}${EXTRACT_SUFX}
+DISTFILES+=kopano-webapp-plugin-files-3.0.0.42-362.1${EXTRACT_SUFX} \
+
kopano-webapp-plugin-filesbackend-owncloud-3.0.0.15-115.1${EXTRACT_SUFX} \
+
kopano-webapp-plugin-filesbackend-smb-3.0.0.14-82.1${EXTRACT_SUFX}
DISTFILES+=${EDISTFILES}
@@ -49,7 +49,6 @@ MODULES= lang/php
MODPHP_BUILDDEP=No
MODPHP_RUNDEP= No
-BUILD_DEPENDS= converters/rpm2cpio
RUN_DEPENDS= mail/kopano/core,-mapi # php-mapi
NO_BUILD= Yes
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/09 14:32:47 Modified files: databases/recoll: Makefile Log message: recoll uses C++11 so needs to use ports-gcc on base-gcc arches Fix the build on sparc64 ok cwen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/09 14:10:33 Modified files: x11/gnome/terminal: Makefile distinfo x11/gnome/terminal/pkg: PLIST Log message: update to gnome-terminal-3.38.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/09 14:03:10 Added files: databases/mariadb/patches: patch-mysys_CMakeLists_txt patch-mysys_crc32_crc32c_cc Log message: add two patches to fix building mariadb on powerpc64 "sure" brad (MAINTAINER)
[sparc64/base-gcc] Fix build of databases/recoll
recoll uses C++11 so needs to use ports-gcc on base-gcc arches
This fixes the build on sparc64
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/databases/recoll/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile4 Jan 2021 14:06:28 - 1.4
+++ Makefile9 Jan 2021 17:41:40 -
@@ -18,6 +18,9 @@ PERMIT_PACKAGE= Yes
MASTER_SITES= https://www.lesbonscomptes.com/recoll/
+# C++11
+COMPILER= base-clang ports-gcc
+
WANTLIB += ${COMPILER_LIBCXX} c iconv lzma m xapian xml2
WANTLIB += xslt z
Re: [update] archivers/gtar 1.32 -> 1.33
Stefan Hagen: > portcheck, make port-lib-depends-check: ok > make test: > amd64 - up to test 165 all good, then I ran out of disk space > sparc64 - passed Well, I get: 89: extracting even when . and .. are unreadableFAILED (extrac09.at:37) Looking at tests/testsuite.dir/089/testsuite.log in the work directory shows chmod a-r . .. tar -xvf archive.tar -C extract f [...] +tar: .: Cannot getcwd: Permission denied +tar: Error is not recoverable: exiting now I don't think our getcwd(3) fails this way. Which makes me think a gnulib wrapper has been enabled. Ah, yes, from the configure output: checking whether getcwd succeeds when 4k < cwd_length < 16k... no Hmmm. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: freerdp (master) & guacamole 1.3.0 - [Was: Using Packages to add a ports dependencies]
On 2021/01/09 12:41, Steve Williams wrote: > I have a "work in progress" port for freerdp. There has been a problem with > the most recent release version connecting to older systems (Server 2012, > XP, etc) with the glyph cache. I noticed in the freerdp main tree, they > have disabled the glyph caching, marked it as broken and "won't fix". So I > modified my port to check the main branch (not a release) of freerdp. > [1], [2], [3] That's nothing new in freerdp, the glyph cache has been disabled by default for ages - the commit you showed is from 2016. That's just guacamole using an inadvisable setting in their default config. > The patches I have (pertaining to a very strange timer implementation) still > applied and I now have a (hacked) port of freerdp. xfreerdp even works (at > a basic level) to Windows XP and Windows 7. > > Along with this, I have a guacamole port running leveraging the freerdp > build and guacamole connects to the Windows XP and Windows 7 system as well > (by default, not having to disable the glyph cache in guacamole). > > The freerdp port is all hacked, returning non-error values instead of error > values in the freerdp timer code (and diagnostic messages)... It's partly to > see exactly where the timer code is used. 2.0rc2 added dynamic resizing, https://github.com/FreeRDP/FreeRDP/commit/80dab90f1a13551009821440710e90676759952d A subsequent commit was added which introduces use of WaitableTimer to avoid sending resize during negotiation or too frequently, to avoid a 2012r2 problem. https://github.com/FreeRDP/FreeRDP/commit/ce89a9096e4450b79e835f24d0d0d73d7e3206cf If the timer is broken the resize is never sent, you can see this by changing the window size. It's also checked in the regression tests. I'm not sure if there's anything else in the main loop hanging off that timer, I haven't noticed anything (I have not looked beyond 2.2.0 though), and quite possibly not because the broken diff several people have sent out (to init the timer fd and do nothing else with it) does _mostly_ work. > Now I need to dive into the freerdp timer code and decide the best approach. > > It's interesting working on this stuff :) > > Thanks again, > Steve Williams > > [1] https://issues.apache.org/jira/browse/GUACAMOLE-1191 > [2] https://github.com/FreeRDP/FreeRDP/issues/6505#issuecomment-705732350 > [3] > https://github.com/FreeRDP/FreeRDP/commit/5a2c24974953f044ac35ddf47bf8637bc41df02d >
freerdp (master) & guacamole 1.3.0 - [Was: Using Packages to add a ports dependencies]
On 09/01/2021 3:03 a.m., Stefan Hagen wrote: Stuart Henderson wrote: On 2021/01/08 14:49, Steve Williams wrote: I want to work on a port that is a pet project (guacamole/xfreerdp). There are a bunch of dependencies on the port and I was wondering if there is an easy way to either 1) Tell the ports system to use packages to fulfill any dependencies See Stuard's response. If you want to make it permanent, you can echo "FETCH_PACKAGES=" >> /etc/mk.conf 2) generate a list of dependencies that can be fed to pkg_add Read ports(7) $ make print-build-depends $ make print-run-depends I have been manually adding the packages based on the dependencies in the ports Makefile, but after doing this manual process a bunch of times (yes, I finally made a shell script), I was wondering if there was an easier way. If you install a package, dependencies are installed as well. If you deinstall the package, you can deinstall unused dependencies with "pkg_delete -a". Be aware that manually installing dependencies marks them as manually installed and pkg_delete -a won't automatically delete them. Best Regards, Stefan Hi Thanks for the pointers and for all the work on the ports infrastructure. It's pretty amazing. I was able to get my development system upgraded and all the packages installed. I have a "work in progress" port for freerdp. There has been a problem with the most recent release version connecting to older systems (Server 2012, XP, etc) with the glyph cache. I noticed in the freerdp main tree, they have disabled the glyph caching, marked it as broken and "won't fix". So I modified my port to check the main branch (not a release) of freerdp. [1], [2], [3] The patches I have (pertaining to a very strange timer implementation) still applied and I now have a (hacked) port of freerdp. xfreerdp even works (at a basic level) to Windows XP and Windows 7. Along with this, I have a guacamole port running leveraging the freerdp build and guacamole connects to the Windows XP and Windows 7 system as well (by default, not having to disable the glyph cache in guacamole). The freerdp port is all hacked, returning non-error values instead of error values in the freerdp timer code (and diagnostic messages)... It's partly to see exactly where the timer code is used. Now I need to dive into the freerdp timer code and decide the best approach. It's interesting working on this stuff :) Thanks again, Steve Williams [1] https://issues.apache.org/jira/browse/GUACAMOLE-1191 [2] https://github.com/FreeRDP/FreeRDP/issues/6505#issuecomment-705732350 [3] https://github.com/FreeRDP/FreeRDP/commit/5a2c24974953f044ac35ddf47bf8637bc41df02d
Re: Mark www/purritobin BROKEN-sparc64
Probably better to set COMPILER= base-clang
On 2021/01/09 13:50, Kurt Mosiejczuk wrote:
> www/purritobin has never compiled on sparc64.
>
> ok to mark it BROKEN?
>
> (cc maintainer)
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/purritobin/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile 12 Dec 2020 15:02:35 - 1.3
> +++ Makefile 9 Jan 2021 18:49:50 -
> @@ -1,5 +1,7 @@
> # $OpenBSD $
>
> +BROKEN-sparc64 = undefined reference to
> std::filesystem::__cxx11::path::_M_split_cmpts()
> +
> COMMENT =minimalistic command line pastebin
> PKGNAME =${DISTNAME:L}
> CATEGORIES = www net
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2021/01/09 12:20:54 Modified files: devel/py-prompt_toolkit: Makefile distinfo Log message: Update to py-prompt_toolkit-3.0.10 Changelog: https://github.com/prompt-toolkit/python-prompt-toolkit/blob/3.0.10/CHANGELOG
Mark www/purritobin BROKEN-sparc64
www/purritobin has never compiled on sparc64.
ok to mark it BROKEN?
(cc maintainer)
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/purritobin/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile12 Dec 2020 15:02:35 - 1.3
+++ Makefile9 Jan 2021 18:49:50 -
@@ -1,5 +1,7 @@
# $OpenBSD $
+BROKEN-sparc64 = undefined reference to
std::filesystem::__cxx11::path::_M_split_cmpts()
+
COMMENT = minimalistic command line pastebin
PKGNAME = ${DISTNAME:L}
CATEGORIES = www net
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/09 11:25:38 Modified files: emulators/mednafen: Makefile Log message: only disable altivec on powerpc as it is actually required to build this on powerpc64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2021/01/09 11:22:12 Modified files: www/newsboat : Makefile Log message: Drop maintainership.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2021/01/09 11:14:11 Modified files: graphics/libsixel: Makefile graphics/termtosvg: Makefile Log message: Drop maintainership for some ports I no longer use.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/09 10:59:04 Modified files: graphics/mojoshader: Makefile Log message: Fix build on sparc64 by informing base-gcc that mojoshader uses C99 constructs ok thfr@ (maintainer)
[sparc64/base-gcc] Fix build of devel/universal-ctags
universal-ctags uses C99 constructs so base-gcc needs to be informed
Fixes build on sparc64
ok?
(cc maintainer)
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/universal-ctags/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile11 Dec 2020 15:47:10 - 1.12
+++ Makefile9 Jan 2021 17:26:27 -
@@ -68,6 +68,11 @@ WANTLIB+=aspell
CONFIGURE_ARGS+= --disable-aspell
.endif
+.include
+.if !${PROPERTIES:Mclang}
+CFLAGS += -std=gnu99
+.endif
+
pre-test:
ln -sf ${LOCALBASE}/bin/gdiff ${WRKDIR}/bin/diff
ln -sf ${LOCALBASE}/bin/gseq ${WRKDIR}/bin/seq
Re: [sparc64/base-gcc] Fix build of graphics/mojoshader
On Sat, Jan 09, 2021 at 12:53:15PM -0500, Kurt Mosiejczuk wrote:
> mojoshader uses C99 constructs so base-gcc needs to be informed of that.
> This diff fixes the build on sparc64
>
> ok?
ok thfr@
>
> (cc maintainer)
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/mojoshader/Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile
> --- Makefile 17 Dec 2020 07:45:16 - 1.8
> +++ Makefile 9 Jan 2021 17:21:56 -
> @@ -40,6 +40,11 @@ WRKDIST = ${WRKDIR}/mojoshader-${HG_COMM
>
> SUBST_VARS +=HG_CHANGESET HG_COMMIT
>
> +.include
> +.if !${PROPERTIES:Mclang}
> +CFLAGS +=-std=gnu99
> +.endif
> +
> do-gen:
> ${SUBST_CMD} ${WRKSRC}/CMakeLists.txt
>
[sparc64/base-gcc] Fix build of www/privoxy
privoxy uses C99 constructs so base-gcc needs to be told that.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/privoxy/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile29 Nov 2020 19:08:14 - 1.38
+++ Makefile9 Jan 2021 17:30:44 -
@@ -33,6 +33,11 @@ CONFIGURE_ARGS= --with-docbook=no \
CONFIGURE_ENV= CPPFLAGS="-Dunix -I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
+.include
+.if !${PROPERTIES:Mclang}
+CFLAGS += -std=gnu99
+.endif
+
pre-configure:
@cd ${WRKDIST} && AUTOCONF_VERSION=${AUTOCONF_VERSION} autoheader
[sparc64/base-gcc] Fix build of graphics/mojoshader
mojoshader uses C99 constructs so base-gcc needs to be informed of that.
This diff fixes the build on sparc64
ok?
(cc maintainer)
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/graphics/mojoshader/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile17 Dec 2020 07:45:16 - 1.8
+++ Makefile9 Jan 2021 17:21:56 -
@@ -40,6 +40,11 @@ WRKDIST =${WRKDIR}/mojoshader-${HG_COMM
SUBST_VARS += HG_CHANGESET HG_COMMIT
+.include
+.if !${PROPERTIES:Mclang}
+CFLAGS += -std=gnu99
+.endif
+
do-gen:
${SUBST_CMD} ${WRKSRC}/CMakeLists.txt
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 10:50:07 Modified files: math/visidata : Makefile distinfo Log message: update to visidata-2.1.1
devel/sdl2: enable real GUID-based controller mapping
Hi,
The next stepping stone in my project to improve out-of-the-box
gamecontroller support.
Background: On other platforms (Linux, MacOSX), SDL2 uses a GUID for
gamecontrollers combined with a database [1] to provide the default
button/axis mappings. This hasn't worked on OpenBSD (or apparently any
*BSD) and the SDL2 code resorts to simply converting the first 16 chars
of the device name to the GUID, which doesn't help with making use of
the gamecontrollerdb [2]. Therefore, the way we have been handling this
so far is that the env var SDL_GAMECONTROLLERCONFIG was available to
hold a mapping string [3]. This poses a significant barrier, as users
have to learn the syntax of the mapping strings and find one fitting
their controller by trial and error mostly.
This diff fixes the issue. To accomplish that, a couple of tasks are
added:
- Calculate and store the GUID (Credit goes to brynet@ for finding the
GUID calculation and writing the initial proof-of-concept code).
- Remove the workaround code in SDL_gamecontroller.c that would either
read the mapping from SDL_GAMECONTROLLERCONFIG if present, or
otherwise default to the (commonly used) XBox 360 controller layout.
- Enable the mappings in SDL_gamecontrollerdb.h for OpenBSD.
- Assign buttons correctly - not in the order that they appear in the
HID report, but based on their numbering in the HID report descriptor.
- Invert Y/Ry axes for the newer XInput-type gamecontrollers. This has
been a particularly annoying problem, as USB standards recommend the
positive directions to be left to right and far to near, but these
controllers just use near-to-far as the positive direction. [4]
The problem with the last bullet point is that the Y/Ry axis inversion
needs to be applied *only* to the XInput devices, and *not* to the
older DInput devices. I can't check for XBox360 and other interface
subclasses (as used by the kernel in uhidev.c), as
USB_GET_INTERFACE_DESC is not exposed in the uhid(4) driver (see
uhid_do_ioctl() in uhid.c).
The solution I came up with is admittedly a (minor) hack. It turns out
that the old DInput devices report their axis values as an unsigned
8bit integer, while the newer ones use a signed 16bit integer. With my
collection of gamecontrollers, checking if hitem.logical_maximum is
greater than 255 allows to reliably pick the correct handling of the
Y/Ry axes.
Other caveats:
- With the newly enabled GUID detection, SDL2 checks for a matching
controller in gamecontrollerdb.txt in the application directory.
I found that with one game (Cryptark), this contained bogus mappings
for the XBox One controller (see the post on tech@), so some buttons
and the Dpad didn't work until I removed that file.
- For some reason, the GUID for DInput devices matches the MACOSX
entries in SDL_gamecontrollerdb.h, but the XInput devices match the
LINUX entries. It's gonna take me a bit of time to get to the bottom
of this; in the meantime just allowing both sets of GUID mappings
works for the devices here on my testing
- The BSD_JoystickGetDeviceGUID() is not ideal at this point, as it
takes the GUID stored as a string in char **joyguids and converts it
into the raw numerical. I haven't figured out how to do the GUID
calculation to avoid this additional transformation step yet. In the
meantime, I don't notice performance issues and I don't think it's
worth holding up the GUID mapping support over this.
Testing:
I tested this with sdl2-jstest (from sdl-jstest package) and few
games (Owlboy, Cryptark) with these controllers that I have:
XBox 360 controller (XInput), XBox One controller (XInput) (see separate
mail on tech@), Logitech F310 (both DInput and XInput), Logitech Dual
Action (DInput)). This maps everything correctly without additional
configuration (as long as faulty gamecontrollerdb.txt in the game
directory is removed).
Testing with a variety of controllers would be useful to see if this
really works across most of them as intended. If you do that, please
let me know the mapping/functioning before and after the diff is
applied.
[1]
https://hg.libsdl.org/SDL/file/2370522dac4c/src/joystick/SDL_gamecontrollerdb.h
[2]
https://hg.libsdl.org/SDL/file/2370522dac4c/src/joystick/bsd/SDL_bsdjoystick.c#l700
[3] https://marc.info/?l=openbsd-ports-cvs=152080802204959=2
[4] https://www.usb.org/sites/default/files/documents/hid1_11.pdf (page 20)
Index: Makefile
===
RCS file: /cvs/ports/devel/sdl2/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile6 Jan 2021 22:32:08 - 1.32
+++ Makefile9 Jan 2021 16:09:20 -
@@ -5,6 +5,7 @@ COMMENT=cross-platform multimedia libra
V= 2.0.14
DISTNAME= SDL2-${V}
PKGNAME= sdl2-${V}
+REVISION= 0
CATEGORIES=devel
MASTER_SITES= https://www.libsdl.org/release/
Index: patches/patch-src_joystick_SDL_gamecontroller_c
NEW: mail/dcc
This port is for DCC (https://www.dcc-servers.net/dcc/), 'The Distributed Checksum Clearinghouses or DCC is an anti-spam content filter that runs on a variety of operating systems. The counts can be used by SMTP servers and mail user agents to detect and reject or filter spam or unsolicited bulk mail. DCC servers exchange or "flood" common checksums. The checksums include values that are constant across common variations in bulk messages, including "personalizations."' It can be used in conjunction with various spam filtering software including rspamd, but note the license restrictions which I've summarised in DESCR and are detailed in https://www.dcc-servers.net/dcc/INSTALL.html. PERMIT_PACKAGE is disabled. ok to import? Index: infrastructure/db/user.list === RCS file: /cvs/ports/infrastructure/db/user.list,v retrieving revision 1.382 diff -u -p -r1.382 user.list --- infrastructure/db/user.list 12 Dec 2020 07:30:48 - 1.382 +++ infrastructure/db/user.list 9 Jan 2021 16:44:07 - @@ -371,3 +371,4 @@ id usergroup port 860 _dendrite _dendrite net/dendrite 861 _i2p _i2pnet/i2p 862 _blackboxexporter _blackboxexporter sysutils/blackbox_exporter +863 _dcc _dccmail/dcc dcc.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/09 08:45:37 Modified files: mail/hashcash : Makefile Log message: mark broken powerpc64: non-portable altivec / gcc-isms
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 08:42:57 Modified files: x11/gnome/maps : Makefile distinfo Log message: Update to gnome-maps-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 08:29:48 Modified files: x11/xsettingsd : Makefile distinfo x11/xsettingsd/pkg: PLIST Added files: x11/xsettingsd/patches: patch-CMakeLists_txt Log message: update to xsettingsd-1.0.2, moves from scons->cmake
Re: UPDATE: net/bitlbee-facebook 1.2.0 -> 1.2.1
Ping? Tested longer on amd64 now. No problems. tor. 22. okt. 2020 kl. 03:36 skrev Eivind Eide : > > bitlbee-facebook-1.2.1 (2020-10-20): > - Fix "Parse error: unexpected identifier 'taNewMessage'" > - Fix "Failed to read thrift: facebook-api.c:1929 fb_api_cb_publish_pt: > assertion 'fb_thrift_read_stop(thft)' failed" > > Tested lightly on amd64. > > Simple diff. Attaching as textfile, as gmail mangles all input. > > -- > > > > Eivind Eide > > "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" > - Oceania Association of Autonomous Astronauts -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2021/01/09 07:34:26 Modified files: devel/p5-Devel-OverloadInfo: Makefile Log message: Tests of p5-Devel-OverloadInfo failed due to inconsistencies between Pod spelling and our /usr/share/dict. Disable this author test as spelling should not be a porter's concern. Now make test passes. OK cwen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2021/01/09 07:26:35 Modified files: net/p5-Net-HTTP: Makefile distinfo Log message: update p5-Net-HTTP to 6.19 from wen heping; maintainer timeout
Dependency problem with stable update of dovecot-2.3.13
Hello, There seems to be a dependency problem if you use dovecot-fts-xapian Dependency of dovecot-fts-xapian-1.3.1 on dovecot-=2.3.11.3v0 doesn't match. And a pkg_add -u will try to upgrade dovecot-pigeonhole Which will create an ABI issue given that main dovecot is not upgraded: Error: Couldn't load plugin /usr/local/lib/dovecot/doveadm/lib10_doveadm_sieve_plugin.so: Module is for different ABI version 2.3.ABIv13(2.3.13) (we have 2.3.ABIv11(2.3.11.3)) Regards smime.p7s Description: S/MIME Cryptographic Signature
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 07:05:40 Modified files: games/tuxpaint : Makefile distinfo games/tuxpaint/patches: patch-Makefile patch-src_manpage_tuxpaint_1 games/tuxpaint/pkg: PLIST Log message: Update to tuxpaint-0.9.25.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 07:05:17 Modified files: graphics : Makefile Log message: +libimagequant
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 07:05:02 Log message: Import libimagequant-2.13.1 libimagequant is a small, portable C library for high-quality conversion of RGBA images to 8-bit indexed-color (palette) images. ok robert@ Status: Vendor Tag: ajacoutot Release Tags: ajacoutot_20200901 N ports/graphics/libimagequant/Makefile N ports/graphics/libimagequant/distinfo N ports/graphics/libimagequant/patches/patch-configure N ports/graphics/libimagequant/pkg/DESCR N ports/graphics/libimagequant/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2021/01/09 06:58:33 Modified files: www/trac : Makefile Log message: bump www/trac after devel/subversion,-python dependency changed package name
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 05:50:09 Modified files: mail/rspamd: Makefile distinfo mail/rspamd/patches: patch-CMakeLists_txt patch-cmake_Toolset_cmake mail/rspamd/pkg: PLIST Log message: update to rspamd-2.7
Re: dev and deve and devel
On 2021/01/09 13:23, Jan Stary wrote: > The current ports.tar.gz contains a dev/ and deve/ directory > beside the expected devel/ category. Is that intended? > Looking at cvsweb, these have been in the Attic for some time. Yes. Directories cannot be removed in CVS.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2021/01/09 05:42:57 Modified files: net/p5-Net-Patricia: Makefile net/p5-Net-Patricia/pkg: PLIST Added files: net/p5-Net-Patricia/patches: patch-libpatricia_Makefile_PL Log message: Add a patch that fixes "make test" for net/p5-Net-Patricia. Mention the BSD license from libpatricia/copyright in the comment. Depend on p5-Net-CIDR-Lite >= 0.20 as specified in Makefile.PL. OK benoit@
conflicts in ports.tar.gz
The current ports.tar.gz contains files that 'cvs up' considers to be in conflict. For example, untaring snapshots/ports.tar.gz and running cvs -q -d anon...@mirror.osn.de:/cvs up -PdA on to of that gives C x11/paper-icon-theme/distinfo cvs update: move away x11/paper-icon-theme/pkg/DESCR; it is in the way and many others (full list below). I am not sure _where_ the problem is: the tarball, my cvs workdir (freshly untarred), the command, the particular mirror? Thanks for any clue. Jan C devel/p5-Devel-CheckOS/Makefile C devel/p5-Devel-CheckOS/distinfo C devel/p5-Devel-CheckOS/pkg/DESCR C devel/p5-Devel-CheckOS/pkg/PLIST C devel/p5-Log-Any-Adapter-Callback/Makefile C devel/p5-Log-Any-Adapter-Callback/distinfo C devel/p5-Log-Any-Adapter-Callback/pkg/DESCR C devel/p5-Log-Any-Adapter-Callback/pkg/PLIST C devel/p5-Test-Needs/Makefile C devel/p5-Test-Needs/distinfo C devel/p5-Test-Needs/pkg/DESCR C devel/p5-Test-Needs/pkg/PLIST C devel/premake4/Makefile C devel/premake4/distinfo C devel/premake4/files/scripts.c C devel/premake4/patches/patch-build_gmake_unix_Premake4_make C devel/premake4/patches/patch-src_base_os_lua C devel/premake4/patches/patch-src_host_os_getversion_c C devel/premake4/pkg/DESCR C devel/premake4/pkg/PLIST C devel/py-backports-functools-lru-cache/Makefile C devel/py-backports-functools-lru-cache/distinfo C devel/py-backports-functools-lru-cache/pkg/DESCR C devel/py-backports-functools-lru-cache/pkg/PLIST C devel/py-codestyle/Makefile C devel/py-codestyle/distinfo C devel/py-codestyle/pkg/DESCR C devel/py-codestyle/pkg/PLIST C devel/py-construct/Makefile C devel/py-construct/distinfo C devel/py-construct/pkg/DESCR C devel/py-construct/pkg/PLIST C devel/py-efilter/Makefile C devel/py-efilter/distinfo C devel/py-efilter/pkg/DESCR C devel/py-efilter/pkg/PLIST C devel/py-entrypoints/Makefile C devel/py-entrypoints/distinfo C devel/py-entrypoints/pkg/DESCR C devel/py-entrypoints/pkg/PLIST C devel/py-execnet/Makefile C devel/py-execnet/distinfo C devel/py-execnet/pkg/DESCR C devel/py-execnet/pkg/PLIST C devel/py-hypothesis/Makefile C devel/py-hypothesis/distinfo C devel/py-hypothesis/pkg/DESCR C devel/py-hypothesis/pkg/PLIST C devel/py-isort/Makefile C devel/py-isort/distinfo C devel/py-isort/pkg/DESCR C devel/py-isort/pkg/PLIST C devel/py-ply/Makefile C devel/py-ply/distinfo C devel/py-ply/pkg/DESCR C devel/py-ply/pkg/PLIST C devel/py-robotframework/Makefile C devel/py-robotframework/distinfo C devel/py-robotframework/pkg/DESCR C devel/py-robotframework/pkg/PLIST C devel/py-spark-parser/Makefile C devel/py-spark-parser/distinfo C devel/py-spark-parser/pkg/DESCR C devel/py-spark-parser/pkg/PLIST C devel/py-test-xdist/Makefile C devel/py-test-xdist/distinfo C devel/py-test-xdist/patches/patch-testing_acceptance_test_py C devel/py-test-xdist/pkg/DESCR C devel/py-test-xdist/pkg/PLIST C devel/py-uncompyle6/Makefile C devel/py-uncompyle6/distinfo C devel/py-uncompyle6/pkg/DESCR C devel/py-uncompyle6/pkg/PLIST C devel/py-voluptuous/Makefile C devel/py-voluptuous/distinfo C devel/py-voluptuous/pkg/DESCR C devel/py-voluptuous/pkg/PLIST C devel/py-xdis/Makefile C devel/py-xdis/distinfo C devel/py-xdis/pkg/DESCR C devel/py-xdis/pkg/PLIST C devel/ruby-fast_gettext/Makefile C devel/ruby-fast_gettext/distinfo C devel/ruby-fast_gettext/pkg/DESCR C devel/ruby-fast_gettext/pkg/PLIST C devel/ruby-gettext-setup/Makefile C devel/ruby-gettext-setup/distinfo C devel/ruby-gettext-setup/pkg/DESCR C devel/ruby-gettext-setup/pkg/PLIST C textproc/py-demjson/Makefile C textproc/py-demjson/distinfo C textproc/py-demjson/patches/patch-setup_py C textproc/py-demjson/pkg/DESCR C textproc/py-demjson/pkg/PLIST C www/py-waitress/Makefile C www/py-waitress/distinfo C www/py-waitress/patches/patch-setup_cfg C www/py-waitress/pkg/DESCR C www/py-waitress/pkg/PLIST C www/sass/Makefile C www/sass/distinfo C www/sass/pkg/DESCR C www/sass/pkg/PLIST C www/tor-browser/Makefile C www/tor-browser/Makefile.inc C www/tor-browser/browser/Makefile C www/tor-browser/browser/distinfo C www/tor-browser/browser/files/all-openbsd.js C www/tor-browser/browser/files/bookmarks.html C www/tor-browser/browser/files/configure C www/tor-browser/browser/files/pledge.content C www/tor-browser/browser/files/pledge.gpu C www/tor-browser/browser/files/pledge.main C www/tor-browser/browser/files/tor-browser C www/tor-browser/browser/files/tor-browser.cfg C www/tor-browser/browser/files/tor-browser.desktop C www/tor-browser/browser/files/torrc-defaults C www/tor-browser/browser/files/unveil.content C www/tor-browser/browser/files/unveil.gpu C www/tor-browser/browser/files/unveil.main C www/tor-browser/browser/patches/patch-_mozconfig C www/tor-browser/browser/patches/patch-browser_extensions_tor-launcher_src_components_tl-process_js C www/tor-browser/browser/patches/patch-browser_extensions_tor-launcher_src_defaults_preferences_torlauncher-prefs_js C
dev and deve and devel
The current ports.tar.gz contains a dev/ and deve/ directory beside the expected devel/ category. Is that intended? Looking at cvsweb, these have been in the Attic for some time. Jan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 05:16:01 Modified files: games/tuxpaint-config: Makefile distinfo games/tuxpaint-config/patches: patch-Makefile Log message: Update to tuxpaint-config-0.0.16.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 05:08:32 Modified files: games/tuxpaint-stamps: Makefile distinfo Log message: Update to tuxpaint-stamps-20201227.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 05:02:43 Modified files: productivity/gnucash: Makefile distinfo productivity/gnucash/patches: patch-gnucash_gnome-utils_gnc-main-window_c productivity/gnucash/pkg: PLIST Log message: Update to gnucash-4.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:41:27 Modified files: sysutils/terragrunt: Makefile distinfo Log message: Update to terragrunt-0.27.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 04:32:40 Modified files: databases/py-pymysql: Makefile distinfo databases/py-pymysql/pkg: PLIST Log message: update to PyMySQL 1.0.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:30:47 Modified files: x11/gtk+4 : Makefile distinfo x11/gtk+4/patches: patch-modules_printbackends_meson_build Log message: Update to gtk+4-4.0.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:27:36 Modified files: sysutils/terraform: Makefile distinfo Log message: Update to terraform-0.14.4.
Re: Dependency problem with stable update of dovecot-2.3.13
This should have been rebuilt as well, this was working in 6.7-stable.. could you take a look please Solene? On 2021/01/09 11:17, Renaud Allard wrote: > Hello, > > There seems to be a dependency problem if you use dovecot-fts-xapian > > Dependency of dovecot-fts-xapian-1.3.1 on dovecot-=2.3.11.3v0 doesn't match. > > And a pkg_add -u will try to upgrade dovecot-pigeonhole > Which will create an ABI issue given that main dovecot is not upgraded: > Error: Couldn't load plugin > /usr/local/lib/dovecot/doveadm/lib10_doveadm_sieve_plugin.so: Module is for > different ABI version 2.3.ABIv13(2.3.13) (we have 2.3.ABIv11(2.3.11.3)) > > Regards >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:14:38 Modified files: misc/shared-mime-info: Makefile distinfo misc/shared-mime-info/pkg: PLIST Removed files: misc/shared-mime-info/patches: patch-data_freedesktop_generate_sh Log message: Update to shared-mime-info-2.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:08:13 Modified files: x11/gnome/gvfs : Makefile distinfo Log message: Update to gvfs-1.46.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:04:25 Modified files: meta/gnome : Makefile Log message: Welcome to GNOME 3.38.3!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 04:03:54 Modified files: x11/gnome/desktop: Makefile distinfo Log message: Update to gnome-desktop-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 03:36:33 Modified files: security/py-cryptodome: Makefile security/py-cryptodome/pkg: PLIST Added files: security/py-cryptodome/pkg: PFRAG.aesni Log message: switch from @commen5 substitution to a separate PFRAG file for aes-ni related files, it's more robust to interference by update-plist
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 03:33:44 Modified files: sysutils/google-cloud-sdk: Makefile distinfo sysutils/google-cloud-sdk/pkg: PLIST Log message: Update to google-cloud-sdk-322.0.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/09 03:29:44 Modified files: security/libnettle: Makefile distinfo security/libnettle/patches: patch-Makefile_in security/libnettle/pkg: PLIST Added files: security/libnettle/patches: patch-blowfish-bcrypt_c Log message: Update to libnettle-3.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2021/01/09 03:18:10 Modified files: sysutils/borgbackup: Makefile distinfo sysutils/borgbackup/pkg: PLIST Log message: Update to borgbackup-1.1.15 Changes: https://github.com/borgbackup/borg/blob/1.1.15/docs/changes.rst Tested by Martin Ziemer . Thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2021/01/09 03:10:35 Modified files: net/filezilla : Makefile distinfo Log message: Update to filezilla-3.52.0.5 Fixes crash when downloading ASCII files with stray carriage returns. Changes: https://filezilla-project.org/versions.php
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/09 03:10:14 Modified files: security/py-cryptodome/pkg: PLIST Log message: reinstate AESNI_COMMENT, from gkoehler. Fixes !x86 broken in last plist sync.
Re: Using Packages to add a ports dependencies
Stuart Henderson wrote: > On 2021/01/08 14:49, Steve Williams wrote: >> I want to work on a port that is a pet project (guacamole/xfreerdp). >> There are a bunch of dependencies on the port and I was wondering if >> there is an easy way to either >> >>1) Tell the ports system to use packages to fulfill any dependencies See Stuard's response. If you want to make it permanent, you can echo "FETCH_PACKAGES=" >> /etc/mk.conf >>2) generate a list of dependencies that can be fed to pkg_add Read ports(7) $ make print-build-depends $ make print-run-depends >> I have been manually adding the packages based on the dependencies in >> the ports Makefile, but after doing this manual process a bunch of >> times (yes, I finally made a shell script), I was wondering if there >> was an easier way. If you install a package, dependencies are installed as well. If you deinstall the package, you can deinstall unused dependencies with "pkg_delete -a". Be aware that manually installing dependencies marks them as manually installed and pkg_delete -a won't automatically delete them. Best Regards, Stefan
