UPDATE: devel/cmake
Simple bugfix update to the latest stable version 3.17.3. Changelog: https://blog.kitware.com/cmake-3-17-3-available-for-download/ Index: Makefile === RCS file: /cvs/ports/devel/cmake/Makefile,v retrieving revision 1.185 diff -u -p -u -p -r1.185 Makefile --- Makefile26 May 2020 15:15:09 - 1.185 +++ Makefile4 Jun 2020 05:45:17 - @@ -4,11 +4,10 @@ DPB_PROPERTIES = parallel COMMENT = portable build system -VER = 3.17.2 +VER = 3.17.3 EPOCH =0 DISTNAME = cmake-${VER} CATEGORIES = devel -REVISION = 0 HOMEPAGE = https://www.cmake.org/ Index: distinfo === RCS file: /cvs/ports/devel/cmake/distinfo,v retrieving revision 1.57 diff -u -p -u -p -r1.57 distinfo --- distinfo25 May 2020 05:12:00 - 1.57 +++ distinfo4 Jun 2020 05:45:17 - @@ -1,2 +1,2 @@ -SHA256 (cmake-3.17.2.tar.gz) = /HcyTE+CCgkFKneFVJuANf+NNGHe1bvYDSUq59HNOqU= -SIZE (cmake-3.17.2.tar.gz) = 9469251 +SHA256 (cmake-3.17.3.tar.gz) = C9YNUSJ13J9u8qKGVCahhGQs6zdheU5rZb/yM7kdjEA= +SIZE (cmake-3.17.3.tar.gz) = 9470753 Index: patches/patch-Source_cmGeneratorTarget_cxx === RCS file: /cvs/ports/devel/cmake/patches/patch-Source_cmGeneratorTarget_cxx,v retrieving revision 1.13 diff -u -p -u -p -r1.13 patch-Source_cmGeneratorTarget_cxx --- patches/patch-Source_cmGeneratorTarget_cxx 25 May 2020 05:12:00 - 1.13 +++ patches/patch-Source_cmGeneratorTarget_cxx 4 Jun 2020 05:45:17 - @@ -3,7 +3,7 @@ $OpenBSD: patch-Source_cmGeneratorTarget Index: Source/cmGeneratorTarget.cxx --- Source/cmGeneratorTarget.cxx.orig +++ Source/cmGeneratorTarget.cxx -@@ -4154,9 +4154,16 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary +@@ -4155,9 +4155,16 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary // Check for library version properties. const char* version = this->GetProperty("VERSION"); const char* soversion = this->GetProperty("SOVERSION"); @@ -20,7 +20,7 @@ Index: Source/cmGeneratorTarget.cxx // Versioning is supported only for shared libraries and modules, // and then only when the platform supports an soname flag. version = nullptr; -@@ -4180,6 +4187,35 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary +@@ -4181,6 +4188,35 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary // The library name. targetNames.Output = prefix + targetNames.Base + suffix; Index: pkg/PLIST === RCS file: /cvs/ports/devel/cmake/pkg/PLIST,v retrieving revision 1.44 diff -u -p -u -p -r1.44 PLIST --- pkg/PLIST 25 May 2020 05:12:00 - 1.44 +++ pkg/PLIST 4 Jun 2020 05:45:17 - @@ -25,7 +25,6 @@ @man man/man7/cmake-toolchains.7 @man man/man7/cmake-variables.7 @man man/man7/cpack-generators.7 -share/aclocal/ share/aclocal/cmake.m4 share/cmake/ share/cmake/Help/ @@ -207,6 +206,8 @@ share/cmake/Help/envvar/FC.rst share/cmake/Help/envvar/FFLAGS.rst share/cmake/Help/envvar/LDFLAGS.rst share/cmake/Help/envvar/MACOSX_DEPLOYMENT_TARGET.rst +share/cmake/Help/envvar/OBJC.rst +share/cmake/Help/envvar/OBJCXX.rst share/cmake/Help/envvar/PackageName_ROOT.rst share/cmake/Help/envvar/RC.rst share/cmake/Help/envvar/RCFLAGS.rst @@ -2992,6 +2993,8 @@ share/doc/cmake/html/_sources/envvar/FC. share/doc/cmake/html/_sources/envvar/FFLAGS.txt share/doc/cmake/html/_sources/envvar/LDFLAGS.txt share/doc/cmake/html/_sources/envvar/MACOSX_DEPLOYMENT_TARGET.txt +share/doc/cmake/html/_sources/envvar/OBJC.txt +share/doc/cmake/html/_sources/envvar/OBJCXX.txt share/doc/cmake/html/_sources/envvar/PackageName_ROOT.txt share/doc/cmake/html/_sources/envvar/RC.txt share/doc/cmake/html/_sources/envvar/RCFLAGS.txt @@ -4715,6 +4718,8 @@ share/doc/cmake/html/envvar/FC.html share/doc/cmake/html/envvar/FFLAGS.html share/doc/cmake/html/envvar/LDFLAGS.html share/doc/cmake/html/envvar/MACOSX_DEPLOYMENT_TARGET.html +share/doc/cmake/html/envvar/OBJC.html +share/doc/cmake/html/envvar/OBJCXX.html share/doc/cmake/html/envvar/PackageName_ROOT.html share/doc/cmake/html/envvar/RC.html share/doc/cmake/html/envvar/RCFLAGS.html
UPDATE: net/bitcoin
Update bitcoin to 0.20.0. Release notes: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.20.0.md Index: Makefile === RCS file: /cvs/ports/net/bitcoin/Makefile,v retrieving revision 1.23 diff -u -p -u -p -r1.23 Makefile --- Makefile20 Mar 2020 18:42:33 - 1.23 +++ Makefile4 Jun 2020 05:44:24 - @@ -6,10 +6,9 @@ COMMENT = P2P payment system GH_ACCOUNT = bitcoin GH_PROJECT = bitcoin -GH_TAGNAME = v0.19.1 -REVISION = 0 +GH_TAGNAME = v0.20.0 -SHARED_LIBS += bitcoinconsensus 2.0 # 0.0 +SHARED_LIBS += bitcoinconsensus 3.0 # 0.0 SHARED_LIBS += secp256k1 0.0 # 0.0 SHARED_LIBS += univalue 0.0 # 100.3 @@ -22,16 +21,16 @@ MAINTAINER =Rafael Sadowski http://www.opensource.org/licenses/mit-license.php. -@@ -196,7 +196,9 @@ bool BerkeleyEnvironment::Open(bool retry) +@@ -195,7 +195,9 @@ bool BerkeleyEnvironment::Open(bool retry) dbenv->set_errfile(fsbridge::fopen(pathErrorFile, "a")); /// debug dbenv->set_flags(DB_AUTO_COMMIT, 1); dbenv->set_flags(DB_TXN_WRITE_NOSYNC, 1); @@ -18,7 +18,7 @@ Index: src/wallet/db.cpp int ret = dbenv->open(strPath.c_str(), DB_CREATE | DB_INIT_LOCK | -@@ -253,7 +255,9 @@ BerkeleyEnvironment::BerkeleyEnvironment() +@@ -250,7 +252,9 @@ BerkeleyEnvironment::BerkeleyEnvironment() dbenv->set_lk_max_locks(1); dbenv->set_lk_max_objects(1); dbenv->set_flags(DB_AUTO_COMMIT, 1);
Re: *new* sysutils/cdirip - need i386/amd64 testers and ok
The original Makefile contained DOS line endings in it, which although my patches could deal with fine they got lost in the original posting and rendered the original patch unusable. So i just decided to fix the problem at the source and modify the actual distfile Makefile and remove the Makefile patch all together. Below (and in the attachment) are the new diffs. Now portcheck also completes with no issues. Index: sysutils/cdirip/Makefile === RCS file: sysutils/cdirip/Makefile diff -N sysutils/cdirip/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/Makefile4 Jun 2020 01:39:31 - @@ -0,0 +1,25 @@ +# $OpenBSD: Makefile,v 1.0 2020/06/02 04:36:48 alexfree Exp $ + +ONLY_FOR_ARCHS = i386 amd64 macppc +COMMENT = maniplulate and extract .cdi files +DISTNAME = cdirip-0.6.2 +COMPILER = base-clang base-gcc ports-gcc +CATEGORIES = sysutils +HOMEPAGE = https://github.com/jozip/cdirip/ + +MAINTAINER = Alex Free + +PERMIT_PACKAGE = No | not stated in copyright +PERMIT_DISTFILES = No | not stated in copyright + +MASTER_SITES = https://home.macintosh.garden/~alexfree/distfiles/ + +USE_GMAKE =Yes + +MAKE_FILE =Makefile.linux + +BUILD_DEPENDS =devel/gmake + +do-install: + ${INSTALL_SCRIPT} ${WRKSRC}/cdirip ${PREFIX}/bin/cdirip +.include Index: sysutils/cdirip/distinfo === RCS file: sysutils/cdirip/distinfo diff -N sysutils/cdirip/distinfo --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/distinfo4 Jun 2020 01:39:31 - @@ -0,0 +1,2 @@ +SHA256 (cdirip-0.6.2.tar.gz) = 1wg7niqZePOR4UqXNPbxdD57/mTLi1oyMjreSGRjFkA= +SIZE (cdirip-0.6.2.tar.gz) = 11424 Index: sysutils/cdirip/pkg/DESCR === RCS file: sysutils/cdirip/pkg/DESCR diff -N sysutils/cdirip/pkg/DESCR --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/pkg/DESCR 4 Jun 2020 01:39:31 - @@ -0,0 +1 @@ +Extract DiscJugglar .cdi files for use with other burning software. Index: sysutils/cdirip/pkg/PLIST === RCS file: sysutils/cdirip/pkg/PLIST diff -N sysutils/cdirip/pkg/PLIST --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/pkg/PLIST 4 Jun 2020 01:39:31 - @@ -0,0 +1,2 @@ +@comment $OpenBSD: PLIST,v$ +@bin bin/cdirip final Description: Binary data
Re: [new] sysutils/web2ldap and co
On Wed, Jun 03, 2020 at 07:06:28AM -0500, Lucas Raab wrote: > On Wed, Jun 03, 2020 at 12:56:00PM +0100, Stuart Henderson wrote: > > On 2020/06/03 06:02, Lucas Raab wrote: > > > On Wed, Jun 03, 2020 at 08:19:40AM +0200, Landry Breuil wrote: > > > > On Tue, Jun 02, 2020 at 05:01:06PM -0500, Lucas Raab wrote: > > > > > Hello, > > > > > > > > > > Here are three new ports, two deps, and the one piece de resistance, > > > > > web2ldap. > > > > > > > > > > sysutils/web2ldap - web-based LDAP client > > > > > devel/py-xlwt - dep for exporting LDAP query results as XLS files > > > > > devel/py-ldap0 - web2ldap's interface to the OpenLDAP libraries > > > > > > > > > > The author of web2ldap and py-ldap0 has been very responsive to some > > > > > questions I had a few months ago and accepted a change to make it > > > > > easier to manage on the BSDs as a whole. > > > > > > > > > > More information here: https://web2ldap.de/ > > > > > Project upstream here: https://gitlab.com/ae-dir/web2ldap > > > > > > > > > > I've been using this in my own tree for several months now with no > > > > > issues. That being said, I hope I didn't get complacent in the > > > > > submission. > > > > > > > > > > Completely understand if this is too niche to warrant being included > > > > > in > > > > > the tree. If not so terribly niche, feedback? > > > > > > > > That looks interesting and a very complete ldap client/admin tool. Will > > > > have to try it on some of my servers, but some porting nits first: > > > > > > > > - WANTLIB = python3.7m -> use ${MODPY_WANTLIB} > > > > - use MODPY_EGG_VERSION in web2ldap, this way it gets substituted in the > > > > PLIST > > > > > > See above about complacency :) I'll get those updated. > > > > > > > - are *all* those @sample required in ${SYSCONFDIR}/web2ldap ? that > > > > looks > > > > a lot. > > > > > > I suppose not. I was going for a `pkg_add web2ldap` and > > > `rcctl start web2ldap` style where moving files around was already > > > sorted out for the user. Being too helpful there? It is rather a lot of > > > files to manage in the PLIST... > > > > Rather than putting files in share/examples/web2ldap/templates and > > @sample'ing them across, another option is to put them in > > share/web2ldap/templates and installing a symlink at pkg_add time, > > something like this should work (untested): > > > > @exec-add [ -e ${SYSCONFDIR}/web2ldap ] || ln -s > > %D/share/web2ldap/templates ${SYSCONFDIR}/web2ldap/ > > > > That allows using the templates directory by default, but still > > allows pointing the link elsewhere if you want to customise them. > > > > tls/ca-bundle.pem should just use the system file instead, > > /etc/ssl/cert.pem (_don't_ use ${SYSCONFDIR} for that one). > > Got it, I'll give that a whirl. Thanks! > > > > > > > - instead of using 'nobody', create a new separate user for the daemon, > > > > look for examples in other ports' PLIST (@newuser/@newgroup, + > > > > db/user.list line) > > > > > > My rationale here was that there aren't any files that an extra user > > > would need to own for web2ldap to run. Using nobody seemed the simplest > > > approach to nulling out any privileges for the service to work. > > > > "nobody" is absolutely not allowed. > > > > $ getent passwd nobody > > nobody:*:32767:32767:Unprivileged user for NFS:/nonexistent:/sbin/nologin > > > Aha, that makes sense now. Consider myself chastised :) > Updated ports attached. Changes: * py-ldap0 WANTLIB to use $(MODPY_WANTLIB} instead * use MODPY_EGG_VERSION in place of $V for web2ldap * new user _web2ldap to run the service * I backed off a bit from the two step install. I included a README to instruct the user to copy the template folder over. The templates can be customized, new ones added, etc so it didn't seem right to do a symlink. Thoughts? * Looking in hosts.py, the ca-bundle.pem file isn't specifically referenced. Instead, I added some words to the README mentioning that if a user needs to connect to TLS enabled servers, then he/she should point to /etc/ssl/cert.pem (unless otherwise needed). I forgot that that's what I ended up doing, looking at my own configuration. web2ldap.tgz Description: Binary data
Re: UPDATE: games/uhexen2 1.5.9
Hi, On Mon, Jun 01, 2020 at 10:20:53PM +0100, Edd Barrett wrote: > On Mon, Jun 01, 2020 at 09:30:34PM +0100, Edd Barrett wrote: > > Just me? > > Right, after many attempts, finally got the distfile. > > Small tweaks: > - Update pkg README about case sensitiveness of pak files. > - patch-hw_utils_hwmaster_Makefile: no need to append nothing to vars. > - patch-engine_hexen2_Makefile: tweak patch comment. > > New patch below. What do you think? I reckon it's good to go. We can mention in the pkg README too about putting the *.pak files into $HOME/.hexen2/data1 as an alternative of /usr/local/share/uhexen2/data1 which is created when you execute hexen2 or glhexen2. Patch with the pkg README update (I built this on amd64 and arm64 but only tested on amd64): Index: Makefile === RCS file: /cvs/ports/games/uhexen2/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- Makefile12 Jul 2019 20:46:26 - 1.9 +++ Makefile3 Jun 2020 23:11:13 - @@ -2,13 +2,12 @@ COMMENT = Hexen II: Hammer of Thyrion -V =1.5.8 +V =1.5.9 DISTNAME = hexen2source-${V} PKGNAME = uhexen2-${V} EXTRACT_SUFX = .tgz DISTFILES =${DISTNAME}${EXTRACT_SUFX} \ hexen2-${V}-linux-i586.tgz -REVISION = 2 CATEGORIES = games HOMEPAGE = http://uhexen2.sourceforge.net/ Index: distinfo === RCS file: /cvs/ports/games/uhexen2/distinfo,v retrieving revision 1.2 diff -u -p -r1.2 distinfo --- distinfo31 Dec 2016 10:48:00 - 1.2 +++ distinfo3 Jun 2020 23:11:13 - @@ -1,4 +1,4 @@ -SHA256 (hexen2-1.5.8-linux-i586.tgz) = D2aTVlfAxPPjmy8IcZ/l+Sa+K5VNxYM0pl7eslDVFgM= -SHA256 (hexen2source-1.5.8.tgz) = ++bQW0oQuC0YF/rszBiZapOybQgU/k5fbnXZSGJmBGM= -SIZE (hexen2-1.5.8-linux-i586.tgz) = 4631311 -SIZE (hexen2source-1.5.8.tgz) = 2473776 +SHA256 (hexen2-1.5.9-linux-i586.tgz) = lmvSP10gvtjKyjNG5R/m8mRf3h66sqy4htQ14504ASs= +SHA256 (hexen2source-1.5.9.tgz) = KqhMFBqCD5CHhQqs82hKX3HENEKLxXVFiZ7aG5oow+A= +SIZE (hexen2-1.5.9-linux-i586.tgz) = 4633437 +SIZE (hexen2source-1.5.9.tgz) = 2529121 Index: patches/patch-engine_hexen2_Makefile === RCS file: /cvs/ports/games/uhexen2/patches/patch-engine_hexen2_Makefile,v retrieving revision 1.3 diff -u -p -r1.3 patch-engine_hexen2_Makefile --- patches/patch-engine_hexen2_Makefile20 Nov 2018 21:41:00 - 1.3 +++ patches/patch-engine_hexen2_Makefile3 Jun 2020 23:11:13 - @@ -1,34 +1,36 @@ $OpenBSD: patch-engine_hexen2_Makefile,v 1.3 2018/11/20 21:41:00 naddy Exp $ -Use standard optimisations. +Disable internal timidity. Use standard optimisations. Index: engine/hexen2/Makefile --- engine/hexen2/Makefile.orig +++ engine/hexen2/Makefile -@@ -133,7 +133,7 @@ USE_CODEC_MODPLUG=no +@@ -136,7 +136,7 @@ USE_CODEC_XMP=no USE_CODEC_UMX=no # either timidity (preferred) or wildmidi (both possible # but not needed nor meaningful) -USE_CODEC_TIMIDITY=yes +USE_CODEC_TIMIDITY=no USE_CODEC_WILDMIDI=no - # compile timidity with DLS instruments support? (no: - # the dls code isn't good enough and isn't used in unix -@@ -194,12 +194,7 @@ endif - # Overrides for the default CPUFLAGS + # which library to use for mp3 decoding: mad or mpg123 + MP3LIB=mad +@@ -198,15 +198,6 @@ endif CPUFLAGS=$(CPU_X86) --CFLAGS += -g -Wall + CFLAGS += -Wall -CFLAGS += $(CPUFLAGS) --ifndef DEBUG +-ifdef DEBUG +-CFLAGS += -g +-else -# optimization flags --CFLAGS += -O2 -DNDEBUG=1 -ffast-math -fomit-frame-pointer +-CFLAGS += -O2 -DNDEBUG=1 -ffast-math +-# NOTE: -fomit-frame-pointer is broken with ancient gcc versions!! +-CFLAGS += -fomit-frame-pointer -endif -+CFLAGS += -Wall CPPFLAGS= LDFLAGS = -@@ -384,6 +379,9 @@ ifeq ($(TARGET_OS),unix) +@@ -405,6 +396,9 @@ ifeq ($(TARGET_OS),unix) # common unix: NASMFLAGS=-f elf -d_NO_PREFIX Index: patches/patch-engine_hexen2_server_Makefile === RCS file: /cvs/ports/games/uhexen2/patches/patch-engine_hexen2_server_Makefile,v retrieving revision 1.2 diff -u -p -r1.2 patch-engine_hexen2_server_Makefile --- patches/patch-engine_hexen2_server_Makefile 31 Dec 2016 10:48:00 - 1.2 +++ patches/patch-engine_hexen2_server_Makefile 3 Jun 2020 23:11:13 - @@ -2,19 +2,22 @@ $OpenBSD: patch-engine_hexen2_server_Mak Use standard optimisations. engine/hexen2/server/Makefile.orig Mon Jul 25 06:35:24 2016 -+++ engine/hexen2/server/Makefile Sat Dec 31 20:44:08 2016 -@@ -66,12 +66,7 @@ endif - # Overrides for the default CPUFLAGS +Index: engine/hexen2/server/Makefile +--- engine/hexen2/server/Makefile.orig engine/hexen2/server/Makefile +@@ -67,15 +67,6 @@ endif CPUFLAGS=$(CPU_X86) --CFLAGS +=
*new* sysutils/cdirip - need i386/amd64 testers and ok
CDIrip allows you to extract the proprietary DoscJugglar format for use in open source burning software. I’m porting 0.6.2 and not the latest 0.6.4 because 0.6.3 and above broke big endian. With this software, I’ve been able to burn a bootable home brew CD-R for an unmodified Sega Dreamcast with a Mac mini G4 running just OpenBSD. This port has been only tested on macppc current, I’d really appreciate if someone could verify that it works fine on i386 and amd64 as I have access to neither at the moment. If I did anything wrong, let me know as this is my first port. Thanks! Index: sysutils/cdirip/pkg/DESCR === RCS file: sysutils/cdirip/pkg/DESCR diff -N sysutils/cdirip/pkg/DESCR --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/pkg/DESCR 3 Jun 2020 22:15:14 - @@ -0,0 +1 @@ +Extract DiscJugglar .cdi files for use with other burning software. Index: sysutils/cdirip/distinfo === RCS file: sysutils/cdirip/distinfo diff -N sysutils/cdirip/distinfo --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/distinfo3 Jun 2020 22:11:58 - @@ -0,0 +1,2 @@ +SHA256 (cdirip-0.6.2) = hzbUgwGzzXkXD8IU+19cMlTR74nMqzSHoDJElmk8c+A= +SIZE (cdirip-0.6.2) = 11425 Index: sysutils/cdirip/Makefile === RCS file: sysutils/cdirip/Makefile diff -N sysutils/cdirip/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/Makefile3 Jun 2020 22:08:54 - @@ -0,0 +1,32 @@ +# $OpenBSD: Makefile,v 1.0 2020/06/02 01:32:48 alexfree Exp $ + +COMMENT= maniplulate and extract .cdi files +ONLY_FOR_ARCHS = i386 amd64 macppc + +PKGNAME = cdirip-0.6.2 + +CATEGORIES = sysutils + +HOMEPAGE = https://github.com/jozip/cdirip/ + +MAINTAINER = Alex Free + +PERMIT_PACKAGE = No | not explicitly permitted +PERMIT_DISTFILES = No | not explicitly permitted + +MASTER_SITES = https://home.macintosh.garden/~alexfree/distfiles/ + +DISTFILES =cdirip-0.6.2 + +COMPILER = base-clang ports-gcc base-gcc + +BUILD_DEPENDS =devel/gmake + +USE_GMAKE =Yes + +MAKE_FILE =Makefile.linux + +do-install: + ${INSTALL_SCRIPT} ${WRKSRC}/cdirip ${PREFIX}/bin/cdirip + +.include Index: sysutils/cdirip/patches/patch-Makefile_linux === RCS file: sysutils/cdirip/patches/patch-Makefile_linux diff -N sysutils/cdirip/patches/patch-Makefile_linux --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/patches/patch-Makefile_linux3 Jun 2020 22:13:47 - @@ -0,0 +1,23 @@ +$OpenBSD$ + +Index: Makefile.linux +--- Makefile.linux.orig Makefile.linux +@@ -7,7 +7,7 @@ + + + # Compiler +-CC=gcc ++CC=cc + # Parameters given to the compiler + CFLAGS=-s -O1 -I/usr/include -I/include + # Output filename (*.exe) +@@ -22,7 +22,7 @@ OBJS=cdirip.o buffer.o cdi.o common.o audio.o + + all: compile_res + $(CC) -c $(SRCS) $(CFLAGS) +- $(CC) -o $(OUTPUT) $(OBJS) $(CFLAGS) ++ $(CC) -o $(OUTPUT) $(OBJS) -lm $(CFLAGS) + + compile_res: + Index: sysutils/cdirip/pkg/PLIST === RCS file: sysutils/cdirip/pkg/PLIST diff -N sysutils/cdirip/pkg/PLIST --- /dev/null 1 Jan 1970 00:00:00 - +++ sysutils/cdirip/pkg/PLIST 3 Jun 2020 22:15:39 - @@ -0,0 +1,2 @@ +@comment $OpenBSD: PLIST,v$ +@bin bin/cdirip
Re: x11/dmenu: drop fonts/terminus-font from RUN_DEPENDS
On Sun, May 31, 2020 at 10:43:20PM +0200, Joerg Jung wrote: > > > Am 31.05.2020 um 15:49 schrieb Klemens Nanni : > > On Sun, May 31, 2020 at 01:39:30PM +, Lucas wrote: > >> FTR, I originally removed the patch for config.def.h completely in > >> dmenu as I didn't see much point in introducing a patch just for > >> changing some colors, which can be changed with parameters and seem > >> quite randomly chosen (they don't match CSS for OpenBSD site, which I > >> think is the only official thing that can be considered as some sort of > >> colorscheme). > > Let's do one thing at a time, if others later decide to change colors > > they can do so, I'd like to fix the fonts due the implied dependencies, > > all else I'd like to leave the any future porter/MAINTAINER. > > This topic comes up every few months for either of the suckless ports, > see archives. Developers (e.g. tedu and myself), who are actively using > dwm have stated that they prefer to keep color patches (across suckless > ports) instead of following the randomly changing upstream colors - > think of it as principal of least surprise after upgrades. > > IMHO this includes keeping Terminus, despite upstream dropped it long > time ago already. So, I’m not in favor of the proposed patch, but would > not object, if you insist on moving on this way. > > Either way, I can take care of maintaining DWM. Not that I get a vote, but I would *prefer* the ports to be left as-is. I like Terminus just fine, and just pkg_add'ing the port is convenient. Joachim
Re: purritobin-0.1.2 - new package + dependencies
On 6/2/20 8:50 AM, Stuart Henderson wrote: > On 2020/06/01 22:13, Brian Callahan wrote: >> Hi Aisha -- >> >> ‐‐‐ Original Message ‐‐‐ >> On Sunday, May 31, 2020 10:03 PM, Aisha Tammy wrote: >> >>> Hi, >>> >>> I've attached the port again, with a few more fixes. >>> >>> Would love to see this added. >>> >>> A few words about this port: >>> >>> It is a minimalistic pastebin client which allows you to also >>> >>> paste encrypted texts and has a simple javascript decryptor frontend. >>> >>> It is asynchronous and allows you to limit the paste size and a >>> >>> location where the pastes are stored. >>> >>> It uses unveil and pledge to make sure that only the necessary >>> >>> folders and permissions are used. >>> >>> Really hope this can be added and would love to get any advice about >>> >>> how to improve this port :) >>> >>> Aisha >> >> Thanks for the ports. I've attached improved versions of the ports >> that address what I'll talk about in this email. I'll take each >> separately. >> >> usockets: >> * I see that it compiles with -std=c11, so we need to have a >> COMPILER=base-clang ports-gcc line. >> * The Makefile has some -O3 lines, so those go. It also has some -flto >> lines. I don't believe all our archs can support -flto at the moment >> so I removed them too. >> * I am not sure why you create and install a shared version of this >> library. It seems like upstream intends for this to be statically >> linked into executables. Indeed, you don't even use the shared >> version of the library in PurritoBin, so I think it can go. >> * Your patch to the Makefile causes everything to be recompiled at >> fake time. >> * Not related to your port, but too bad that we are stuck using libuv >> (it can use kqueue but it uses extensions from FreeBSD that we don't >> have). >> >> uwebsockets: >> * Upstream claims this is a web server so I moved the category to www. >> Devel is quite full. Otherwise this port is quite straightforward. >> >> purritobin: >> * Since you're using the static version of usocket, we can simplify >> your depends lists. >> >> ~Brian >> > > > > > purritobin > - Makefile: > - add "uses pledge()" above wantlib as done in other ports > - pkg/DESCR: > - trailing blank line > - s/writted/written > I've attached with the suggested fixes and those from Brian. again, thank you Brian! > All these static libraries mean that things won't get updated > automatically when a library is updated. Say you install purritobin > and there is a later security fix to usockets; purritobin won't be > updated unless you manually force it (e.g. by bumping REVISION). > The normal way of handling this with almost everything else in ports > is to use shared libraries. > am not sure if there is a good fix for this (?!) Aisha uwebsockets.tgz Description: application/compressed-tar usockets.tgz Description: application/compressed-tar purritobin.tgz Description: application/compressed-tar
Re: NEW: devel/msbuild - build system for .NET
On Tue, Jun 02, 2020 at 09:06:38AM -0600, Thomas Frohwein wrote: > Attaching tarball [...] Now for real (thanks kn for pointing hypocaffeinemia) msbuild.tgz Description: Binary data
Re: does a new port have to be the latest version?
On 6/3/20 2:11 PM, Stuart Henderson wrote: On 2020/06/03 13:54, Alex Free wrote: What is the program? CDIrip, the current GitHub is at https://github.com/jozip/cdirip . yes 0.6.3 looks to be a bit of a step backwards there. looking at the diff it did also remove a duplicate write of &aCommSize though. Note that it doesn't have proper licensing so will need to be marked as PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version developed on sourceforge under gpl" isn't a valid license grant). https://github.com/jozip/cdirip/blob/master/LICENSE Mentions GPLV2 smime.p7s Description: S/MIME Cryptographic Signature
Re: sparc64 bulk build report
On Mon, Jun 01, 2020 at 11:24:47AM +0100, Stuart Henderson wrote: > On 2020/06/01 11:50, Solene Rapenne wrote: > > On Mon, 1 Jun 2020 10:42:03 +0100 > > Stuart Henderson : > > > > > A summary of the failures: > > > > > > On 2020/06/01 02:30, k...@openbsd.org wrote: > > > > http://build-failures.rhaalovely.net/sparc64/2020-05-29/games/wrath.log > > > > > > > > > > cc1: error: unrecognized command line option "-msse2" > > > > Is this because -msse2 doesn't exist on sparc64? > > SSE/SSE2 only exist on i386/amd64. The code has support for building > without these but the makefile doesn't cope. This probably fixes it. > > Index: Makefile > === > RCS file: /cvs/ports/games/wrath/Makefile,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 Makefile > --- Makefile 25 May 2020 16:08:41 - 1.1.1.1 > +++ Makefile 1 Jun 2020 10:21:37 - > @@ -24,6 +24,10 @@ MAKE_FLAGS = CC="${CC}" \ > CFLAGS_LIBJPEG="-I${LOCALBASE}/include > -DLINK_TO_LIBJPEG" \ > CPUOPTIMIZATIONS="${CFLAGS}" > > +.if !(${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == i386) > +MAKE_FLAGS +=CFLAGS_SSE= CFLAGS_SSE2= > +.endif > + > USE_GMAKE = Yes > > NO_TEST =Yes Thanks Stuart, with your diff I built wrath on arm64. I sent a diff to update wrath last Saturday, can I include your diff in the update or is better to bump revision here first? Index: Makefile === RCS file: /cvs/ports/games/wrath/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile25 May 2020 16:08:41 - 1.1.1.1 +++ Makefile3 Jun 2020 15:51:10 - @@ -3,6 +3,7 @@ COMMENT = client of wrath-darkplaces engine DISTNAME = wrath-0.0.0.20200228 +REVISION = 0 GH_ACCOUNT = KillPixelGames GH_PROJECT = wrath-darkplaces @@ -23,6 +24,10 @@ LIB_DEPENDS =devel/sdl2 \ MAKE_FLAGS = CC="${CC}" \ CFLAGS_LIBJPEG="-I${LOCALBASE}/include -DLINK_TO_LIBJPEG" \ CPUOPTIMIZATIONS="${CFLAGS}" + +.if !(${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == i386) +MAKE_FLAGS += CFLAGS_SSE= CFLAGS_SSE2= +.endif USE_GMAKE =Yes
UPDATE: Tor Browser 9.5
Hi, Below is a patch that updates Tor Browser to 9.5. Briefly tested on amd64. Release announcement: https://blog.torproject.org/new-release-tor-browser-95 Includes a change from Stéphane HUC to the pkg-readme of meta/tor-browser. Thanks, Caspar Schutijser Index: meta/tor-browser/Makefile === RCS file: /cvs/ports/meta/tor-browser/Makefile,v retrieving revision 1.25 diff -u -p -r1.25 Makefile --- meta/tor-browser/Makefile 5 May 2020 20:12:20 - 1.25 +++ meta/tor-browser/Makefile 3 Jun 2020 16:04:32 - @@ -4,12 +4,12 @@ COMMENT= Tor Browser meta package MAINTAINER=Caspar Schutijser -PKGNAME= tor-browser-9.0.10 +PKGNAME= tor-browser-9.5 ONLY_FOR_ARCHS = amd64 i386 -RUN_DEPENDS= www/tor-browser/browser>=9.0.10 \ - www/tor-browser/noscript>=11.0.25 \ - www/tor-browser/https-everywhere>=2020.3.16 \ - net/tor>=0.4.2.7 +RUN_DEPENDS= www/tor-browser/browser>=9.5 \ + www/tor-browser/noscript>=11.0.26 \ + www/tor-browser/https-everywhere>=2020.5.20 \ + net/tor>=0.4.3.5 .include Index: meta/tor-browser/pkg/README === RCS file: /cvs/ports/meta/tor-browser/pkg/README,v retrieving revision 1.4 diff -u -p -r1.4 README --- meta/tor-browser/pkg/README 4 Sep 2018 12:46:16 - 1.4 +++ meta/tor-browser/pkg/README 3 Jun 2020 16:04:32 - @@ -41,7 +41,7 @@ Transports (PT). This means that not al such as using obfsproxy to get to Tor. A future update will include ports for PT components. Pluggable Transports have a web page worth reading: - https://www.torproject.org/docs/pluggable-transports.html.en + https://2019.www.torproject.org/docs/pluggable-transports.html.en For more information about Tor Browser and the Tor anonymity network in general please visit http://www.torproject.org Index: www/tor-browser/Makefile.inc === RCS file: /cvs/ports/www/tor-browser/Makefile.inc,v retrieving revision 1.25 diff -u -p -r1.25 Makefile.inc --- www/tor-browser/Makefile.inc5 May 2020 20:12:20 - 1.25 +++ www/tor-browser/Makefile.inc3 Jun 2020 16:04:32 - @@ -5,7 +5,7 @@ HOMEPAGE ?= https://www.torproject.org PERMIT_PACKAGE ?= Yes CATEGORIES = www BROWSER_NAME = tor-browser -TB_VERSION = 9.0.10 +TB_VERSION = 9.5 TB_PREFIX =tb SUBST_VARS += BROWSER_NAME TB_VERSION Index: www/tor-browser/browser/Makefile === RCS file: /cvs/ports/www/tor-browser/browser/Makefile,v retrieving revision 1.45 diff -u -p -r1.45 Makefile --- www/tor-browser/browser/Makefile5 May 2020 20:12:20 - 1.45 +++ www/tor-browser/browser/Makefile3 Jun 2020 16:04:32 - @@ -9,13 +9,13 @@ ONLY_FOR_ARCHS = amd64 i386 MOZILLA_VERSION = ${TB_VERSION} MOZILLA_PROJECT = ${BROWSER_NAME} MOZILLA_CODENAME = browser -TL_VERSION = 0.2.20.5 +TL_VERSION = 0.2.21.8 EXTRACT_SUFX = .tar.xz PATCHORIG =.pat.orig PKGNAME = ${TB_PREFIX}-browser-${TB_VERSION} -DISTNAME = src-firefox-tor-browser-68.8.0esr-9.0-2-build1 +DISTNAME = src-firefox-tor-browser-68.9.0esr-9.5-1-build2 FIX_EXTRACT_PERMISSIONS= Yes DISTFILES += ${DISTNAME}.tar.xz \ @@ -93,7 +93,7 @@ MAKE_ENV += BUILD_OPT=1 \ XCFLAGS="-I${LOCALBASE}/include ${CFLAGS}" BUILD_DEPENDS += devel/py-virtualenv -RUN_DEPENDS += net/tor>=0.4.2.5 +RUN_DEPENDS += net/tor>=0.4.3.5 CONFIGURE_ARGS += --enable-release #1386371 CONFIGURE_ARGS += --enable-sandbox --enable-content-sandbox Index: www/tor-browser/browser/distinfo === RCS file: /cvs/ports/www/tor-browser/browser/distinfo,v retrieving revision 1.24 diff -u -p -r1.24 distinfo --- www/tor-browser/browser/distinfo5 May 2020 20:12:20 - 1.24 +++ www/tor-browser/browser/distinfo3 Jun 2020 16:04:32 - @@ -1,6 +1,6 @@ -SHA256 (mozilla/src-firefox-tor-browser-68.8.0esr-9.0-2-build1.tar.xz) = d37FZv64a1X66+v3GIFQdOdZ5uKV0isduUThNQ0v5as= -SHA256 (mozilla/src-tor-launcher-0.2.20.5.tar.xz) = LVEbHAxcGf49cC8NF4bVYfFD7k2GA8SX+f+VA5p7L4U= -SHA256 (mozilla/tor-browser-linux64-9.0.10_en-US.tar.xz) = cb34CmRIi5WmIasydfot55z35nHfQZgtH0O8HBd0nB0= -SIZE (mozilla/src-firefox-tor-browser-68.8.0esr-9.0-2-build1.tar.xz) = 348566404 -SIZE (mozilla/src-tor-launcher-0.2.20.5.tar.xz) = 210916 -SIZE (mozilla/tor-browser-linux64-9.0.10_en-US.tar.xz) = 80175308 +SHA256 (mozilla/src-firefox-tor-browser-68.9.0esr-9.5-1-build2.tar.xz) = JeNF7a4rgLqpSg53r7b6pmssqkLvsv6xZIrQ7J/9uxw= +SHA256 (mozilla/src-tor
Re: purritobin-0.1.2 - new package + dependencies
On 2020/06/02 15:55, Aisha Tammy wrote: > > All these static libraries mean that things won't get updated > > automatically when a library is updated. Say you install purritobin > > and there is a later security fix to usockets; purritobin won't be > > updated unless you manually force it (e.g. by bumping REVISION). > > The normal way of handling this with almost everything else in ports > > is to use shared libraries. > > > I totally agree but upstream has mandated that this library is to be used > static only and with -flto -O3 (which Brian has removed stating unsupported > archs, thanks brian!). that could just be changed in the port like you did before (but then actually make use of it). I don't think we honestly care about the difference upstream talks about in the ticket (160k req/sec with shared libs, to 215k req/sec with static+lto, on some unspecified OS). https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325 Packagers for at least some other OS will want this too if they're going to include it in their package systems. > Upstream have also rejected my patch to add shared libraries :( and is adamant > on using both the above flags (which was a separate issue that was raised, to > remove the flags and make them optional depending on distribution) > > Does ports not handle such an automated revision bump for static libraries > that get updated? (am just asking, I don't know the intricacies and details > of shared/static library things) If there was a shared library as well you could list it as a "fake" WANTLIB entry (it would show as "extra" so we add a comment to say what's going on) and then it would at least get updated if the shared library version number (.so.X.Y) changes though that doesn't force it for every update either. Really with static libs you need to bump all the downstream users or set a tight dependency on the particular version number. > I am not sure how to resolve this conflict... > > > an aside: why was -O3 removed, upstream has it present and wants it to be > there? Higher opt levels increase risk of hitting compiler bugs (maybe only on certain architectures). If the code implements anything which is undefined behaviour that can cause problems with optimisers too, especially at higher opt levels. Ports policy is to respect what is set by the user / ports infrastructure, usually -O2, but sometimes it's necessary to change that on certain arches.
Re: does a new port have to be the latest version?
> Just saying "released under GPL" without doing other steps isn't enough. > It needs at least a copyright line with a license grant somewhere > preferably on each file, that's why the license goes to some lengths to > explain how to do it. > > Also releasing some version under GPL doesn't mean that previous versions > are also automatically released under GPL. > > > Source for all previous versions were always > > available, and still are on the wayback machine of > > the original homepage. > > > > Essentially pre 0.6.3 is just source available. > > > > Dist file mirroring is okay right? Besides the > > I don't think it is OK for OpenBSD to do this (as in PERMIT_* etc can't > be set to Yes and it would need building from ports not installing from > packages). If you want to mirror the distfile yourself that would be your > responsibility. > > > wayback machine there is exactly one place I can > > find 0.6.2, and it’s on a gnome related mirror > > and in zip format. Right now I have the port’s > > master site set to my own with a .tar.gz of the > > source. > > I found it at > https://nold.in/lib/exe/fetch.php?media=projects:consoles:dreamcast:cdirip-0.6.2-linux.tar.bz2 > (a path like this requires certain fiddling to use as a source in ports, > should be possible but is annoying!). > > ... > > > Is the code actually invalid GPL due to the Apple code? NetBSD is > > hosting dist files containing the Apple code so is it ok? License > > newbie, thanks for your patience. > > IANAL and it may vary between jurisdictions anyway but my understanding > is "if you don't include a Copyright line and grant some specific rights > to allow redistribution then it can't be redistributed". Some OS care > more about this for things in packages than others (Debian in particular > usually get this right) some others seem to rely on "meh nobody's really > going to complain are they". > > I just changed the permit values to no. I just checked your link and that build is indeed broken on big endian. The only version not broken is the one I found on that mirror. Another thing about that Nold guy, he seems to be throwing on his own license to version 0.6.2? https://github.com/Nold360/mksdiso/blob/master/COPYRIGHT Can I proceed with version 0.6.2? Just want to make sure everything is in order and correct. I’ll host it on my own site and have that ftp as a second master since it’s soo slow. Original site is below if you want to take a look. https://web.archive.org/web/20051127193031/http://cdirip.cjb.net:80/
Re: NEW: security/pivy
On 2020/06/03 11:47, Jonathan Matthew wrote: > ping? > > On Mon, May 25, 2020 at 08:01:58PM +1000, Jonathan Matthew wrote: > > Hi, > > > > Here's a new port, security/pivy, a set of tools for using PIV tokens (like > > Yubikeys) as an SSH agent, for encrypting data at rest, and more. > > > > pkg/DESCR: > > Pivy is an implementation of a simple PIV client with minimal dependencies. > > It contains a pivy-tool binary which can conduct basic operations using > > PIV cards, and the pivy-agent, which implements the SSH agent protocol as > > a drop-in replacement for the OpenSSH ssh-agent command (except that the > > keys it contains are always on a PIV card). > > > > "PIV cards" notably includes Yubico Yubikey devices such as the NEO and > > Yubikey4, which can store up to 24 keys by using the "retired key" slots > > (which this agent supports). > > > > > > I've built and used this on amd64 and armv7, and built it on sparc64. > > > > ok to import? > > Tweaked version attached, this one is OK with me. commentary: | V = 0.6.0 | COMMENT =tools for using PIV tokens as an SSH agent, encryption, etc. | -GH_ACCOUNT = arekinath | -GH_PROJECT = pivy | -GH_TAGNAME = v${V} | -MASTER_SITES = https://github.com/arekinath/pivy/releases/download/${GH_TAGNAME}/ GH_* are for use with the automatic setting of MASTER_SITES etc. Files on github /releases/ URLs are just normal distfiles. | +DISTNAME = pivy-$V | | +HOMEPAGE = https://github.com/arekinath/pivy | + | +MASTER_SITES = https://github.com/arekinath/pivy/releases/download/v$V/ | + | CATEGORIES = security | | MAINTAINER = Jonathan Matthew | @@ -14,7 +15,7 @@ MAINTAINER =Jonathan Matthew | # MPLv2 | PERMIT_PACKAGE = Yes | | -WANTLIB =c z crypto pcsclite pthread | +WANTLIB =c edit crypto pcsclite z it links -ledit on OpenBSD, and doesn't link with pthread | -CONFIGURE_STYLE = none CONFIGURE_STYLE=none is a hack for ports using python.port.mk and shouldn't normally be used | NO_TEST =Yes | | -MAKE_ENV = prefix=${PREFIX} | +MAKE_FLAGS = CC="${CC}" \ | + COPTFLAGS="${CFLAGS}" \ | + prefix=${PREFIX} setting CC/CFLAGS through ports should work (including e.g. make CC=gcc, make DEBUG=-g, etc). .. plus add patch-Makefile which does - -O2 -g -D_GNU_SOURCE + $(COPTFLAGS) -D_GNU_SOURCE pivy.tgz Description: application/tar-gz
Re: does a new port have to be the latest version?
On 2020/06/03 14:58, Alex Free wrote: > > Sent: Wednesday, June 03, 2020 at 2:24 PM > > From: "Stuart Henderson" > > To: "Renaud Allard" > > Cc: ports@openbsd.org > > Subject: Re: does a new port have to be the latest version? > > > > On 2020/06/03 14:17, Renaud Allard wrote: > > > > > > > > > On 6/3/20 2:11 PM, Stuart Henderson wrote: > > > > On 2020/06/03 13:54, Alex Free wrote: > > > > > > > > > > > > What is the program? > > > > > > > > > > > > > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > > > > > > > > > > > > > yes 0.6.3 looks to be a bit of a step backwards there. looking at the > > > > diff > > > > it did also remove a duplicate write of &aCommSize though. > > > > > > > > Note that it doesn't have proper licensing so will need to be marked as > > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > > > Mentions GPLV2 > > > > > > > That is just a file in the distribution of the version on github. There's no > > indication that it was added by the original author of the code and the "How > > to Apply These Terms to Your New Programs" section hasn't been followed > > in particular there is no "Copyright XXX you can redistribute it" etc. > > The only valid copyright information I see in the whole distribution is > > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > > * All rights reserved. > > > > and does not grant redistribution. > > > > > > Previous versions were not under the GPL, but the > original author released 0.6.3 under the GPL. Just saying "released under GPL" without doing other steps isn't enough. It needs at least a copyright line with a license grant somewhere preferably on each file, that's why the license goes to some lengths to explain how to do it. Also releasing some version under GPL doesn't mean that previous versions are also automatically released under GPL. > Source for all previous versions were always > available, and still are on the wayback machine of > the original homepage. > > Essentially pre 0.6.3 is just source available. > > Dist file mirroring is okay right? Besides the I don't think it is OK for OpenBSD to do this (as in PERMIT_* etc can't be set to Yes and it would need building from ports not installing from packages). If you want to mirror the distfile yourself that would be your responsibility. > wayback machine there is exactly one place I can > find 0.6.2, and it’s on a gnome related mirror > and in zip format. Right now I have the port’s > master site set to my own with a .tar.gz of the > source. I found it at https://nold.in/lib/exe/fetch.php?media=projects:consoles:dreamcast:cdirip-0.6.2-linux.tar.bz2 (a path like this requires certain fiddling to use as a source in ports, should be possible but is annoying!). ... > Is the code actually invalid GPL due to the Apple code? NetBSD is > hosting dist files containing the Apple code so is it ok? License > newbie, thanks for your patience. IANAL and it may vary between jurisdictions anyway but my understanding is "if you don't include a Copyright line and grant some specific rights to allow redistribution then it can't be redistributed". Some OS care more about this for things in packages than others (Debian in particular usually get this right) some others seem to rely on "meh nobody's really going to complain are they".
Re: does a new port have to be the latest version?
> > > Note that it doesn't have proper licensing so will need to be marked as > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > Mentions GPLV2 > > > > That is just a file in the distribution of the version on github. There's no > indication that it was added by the original author of the code and the "How > to Apply These Terms to Your New Programs" section hasn't been followed > in particular there is no "Copyright XXX you can redistribute it" etc. > The only valid copyright information I see in the whole distribution is > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > * All rights reserved. > > and does not grant redistribution. > > So should I try to patch 0.6.3 to work on big endian? I’d rather not but if we can’t proceed with 0.6.2 I guess I have to try. Is the code actually invalid GPL due to the Apple code? NetBSD is hosting dist files containing the Apple code so is it ok? License newbie, thanks for your patience. Here is where I found cdirip 0.6.2 originally on that gnome related mirror https://ftp.gnome.org/mirror/archive/ftp.sunet.se/pub/mac/fink/?C=M;O=A (warning very slow) . Here’s the original site on archive.org https://web.archive.org/web/20050706012759/http://cdirip.cjb.net:80/ The original SourceForge page https://sourceforge.net/projects/cdimagetools/files/CDIRip/
Re: does a new port have to be the latest version?
> Sent: Wednesday, June 03, 2020 at 2:24 PM > From: "Stuart Henderson" > To: "Renaud Allard" > Cc: ports@openbsd.org > Subject: Re: does a new port have to be the latest version? > > On 2020/06/03 14:17, Renaud Allard wrote: > > > > > > On 6/3/20 2:11 PM, Stuart Henderson wrote: > > > On 2020/06/03 13:54, Alex Free wrote: > > > > > > > > > > What is the program? > > > > > > > > > > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > > > > > > > > > > yes 0.6.3 looks to be a bit of a step backwards there. looking at the diff > > > it did also remove a duplicate write of &aCommSize though. > > > > > > Note that it doesn't have proper licensing so will need to be marked as > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > Mentions GPLV2 > > > > That is just a file in the distribution of the version on github. There's no > indication that it was added by the original author of the code and the "How > to Apply These Terms to Your New Programs" section hasn't been followed > in particular there is no "Copyright XXX you can redistribute it" etc. > The only valid copyright information I see in the whole distribution is > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > * All rights reserved. > > and does not grant redistribution. > > Previous versions were not under the GPL, but the original author released 0.6.3 under the GPL. Source for all previous versions were always available, and still are on the wayback machine of the original homepage. Essentially pre 0.6.3 is just source available. Dist file mirroring is okay right? Besides the wayback machine there is exactly one place I can find 0.6.2, and it’s on a gnome related mirror and in zip format. Right now I have the port’s master site set to my own with a .tar.gz of the source.
Re: does a new port have to be the latest version?
On 2020/06/03 14:17, Renaud Allard wrote: > > > On 6/3/20 2:11 PM, Stuart Henderson wrote: > > On 2020/06/03 13:54, Alex Free wrote: > > > > > > > > What is the program? > > > > > > > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > > > > > > > yes 0.6.3 looks to be a bit of a step backwards there. looking at the diff > > it did also remove a duplicate write of &aCommSize though. > > > > Note that it doesn't have proper licensing so will need to be marked as > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > developed on sourceforge under gpl" isn't a valid license grant). > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > Mentions GPLV2 > That is just a file in the distribution of the version on github. There's no indication that it was added by the original author of the code and the "How to Apply These Terms to Your New Programs" section hasn't been followed in particular there is no "Copyright XXX you can redistribute it" etc. The only valid copyright information I see in the whole distribution is the one in https://github.com/jozip/cdirip/blob/master/audio.c which says /* Copyright (C) 1988-1991 Apple Computer, Inc. * All rights reserved. and does not grant redistribution.
Re: does a new port have to be the latest version?
On 2020/06/03 13:54, Alex Free wrote: > > > > What is the program? > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > yes 0.6.3 looks to be a bit of a step backwards there. looking at the diff it did also remove a duplicate write of &aCommSize though. Note that it doesn't have proper licensing so will need to be marked as PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version developed on sourceforge under gpl" isn't a valid license grant).
Re: [new] sysutils/web2ldap and co
On Wed, Jun 03, 2020 at 12:56:00PM +0100, Stuart Henderson wrote: > On 2020/06/03 06:02, Lucas Raab wrote: > > On Wed, Jun 03, 2020 at 08:19:40AM +0200, Landry Breuil wrote: > > > On Tue, Jun 02, 2020 at 05:01:06PM -0500, Lucas Raab wrote: > > > > Hello, > > > > > > > > Here are three new ports, two deps, and the one piece de resistance, > > > > web2ldap. > > > > > > > > sysutils/web2ldap - web-based LDAP client > > > > devel/py-xlwt - dep for exporting LDAP query results as XLS files > > > > devel/py-ldap0 - web2ldap's interface to the OpenLDAP libraries > > > > > > > > The author of web2ldap and py-ldap0 has been very responsive to some > > > > questions I had a few months ago and accepted a change to make it > > > > easier to manage on the BSDs as a whole. > > > > > > > > More information here: https://web2ldap.de/ > > > > Project upstream here: https://gitlab.com/ae-dir/web2ldap > > > > > > > > I've been using this in my own tree for several months now with no > > > > issues. That being said, I hope I didn't get complacent in the > > > > submission. > > > > > > > > Completely understand if this is too niche to warrant being included in > > > > the tree. If not so terribly niche, feedback? > > > > > > That looks interesting and a very complete ldap client/admin tool. Will > > > have to try it on some of my servers, but some porting nits first: > > > > > > - WANTLIB = python3.7m -> use ${MODPY_WANTLIB} > > > - use MODPY_EGG_VERSION in web2ldap, this way it gets substituted in the > > > PLIST > > > > See above about complacency :) I'll get those updated. > > > > > - are *all* those @sample required in ${SYSCONFDIR}/web2ldap ? that looks > > > a lot. > > > > I suppose not. I was going for a `pkg_add web2ldap` and > > `rcctl start web2ldap` style where moving files around was already > > sorted out for the user. Being too helpful there? It is rather a lot of > > files to manage in the PLIST... > > Rather than putting files in share/examples/web2ldap/templates and > @sample'ing them across, another option is to put them in > share/web2ldap/templates and installing a symlink at pkg_add time, > something like this should work (untested): > > @exec-add [ -e ${SYSCONFDIR}/web2ldap ] || ln -s %D/share/web2ldap/templates > ${SYSCONFDIR}/web2ldap/ > > That allows using the templates directory by default, but still > allows pointing the link elsewhere if you want to customise them. > > tls/ca-bundle.pem should just use the system file instead, > /etc/ssl/cert.pem (_don't_ use ${SYSCONFDIR} for that one). Got it, I'll give that a whirl. Thanks! > > > > - instead of using 'nobody', create a new separate user for the daemon, > > > look for examples in other ports' PLIST (@newuser/@newgroup, + > > > db/user.list line) > > > > My rationale here was that there aren't any files that an extra user > > would need to own for web2ldap to run. Using nobody seemed the simplest > > approach to nulling out any privileges for the service to work. > > "nobody" is absolutely not allowed. > > $ getent passwd nobody > nobody:*:32767:32767:Unprivileged user for NFS:/nonexistent:/sbin/nologin > Aha, that makes sense now. Consider myself chastised :)
Re: [new] sysutils/web2ldap and co
On 2020/06/03 06:02, Lucas Raab wrote: > On Wed, Jun 03, 2020 at 08:19:40AM +0200, Landry Breuil wrote: > > On Tue, Jun 02, 2020 at 05:01:06PM -0500, Lucas Raab wrote: > > > Hello, > > > > > > Here are three new ports, two deps, and the one piece de resistance, > > > web2ldap. > > > > > > sysutils/web2ldap - web-based LDAP client > > > devel/py-xlwt - dep for exporting LDAP query results as XLS files > > > devel/py-ldap0 - web2ldap's interface to the OpenLDAP libraries > > > > > > The author of web2ldap and py-ldap0 has been very responsive to some > > > questions I had a few months ago and accepted a change to make it > > > easier to manage on the BSDs as a whole. > > > > > > More information here: https://web2ldap.de/ > > > Project upstream here: https://gitlab.com/ae-dir/web2ldap > > > > > > I've been using this in my own tree for several months now with no > > > issues. That being said, I hope I didn't get complacent in the > > > submission. > > > > > > Completely understand if this is too niche to warrant being included in > > > the tree. If not so terribly niche, feedback? > > > > That looks interesting and a very complete ldap client/admin tool. Will > > have to try it on some of my servers, but some porting nits first: > > > > - WANTLIB = python3.7m -> use ${MODPY_WANTLIB} > > - use MODPY_EGG_VERSION in web2ldap, this way it gets substituted in the > > PLIST > > See above about complacency :) I'll get those updated. > > > - are *all* those @sample required in ${SYSCONFDIR}/web2ldap ? that looks > > a lot. > > I suppose not. I was going for a `pkg_add web2ldap` and > `rcctl start web2ldap` style where moving files around was already > sorted out for the user. Being too helpful there? It is rather a lot of > files to manage in the PLIST... Rather than putting files in share/examples/web2ldap/templates and @sample'ing them across, another option is to put them in share/web2ldap/templates and installing a symlink at pkg_add time, something like this should work (untested): @exec-add [ -e ${SYSCONFDIR}/web2ldap ] || ln -s %D/share/web2ldap/templates ${SYSCONFDIR}/web2ldap/ That allows using the templates directory by default, but still allows pointing the link elsewhere if you want to customise them. tls/ca-bundle.pem should just use the system file instead, /etc/ssl/cert.pem (_don't_ use ${SYSCONFDIR} for that one). > > - instead of using 'nobody', create a new separate user for the daemon, > > look for examples in other ports' PLIST (@newuser/@newgroup, + > > db/user.list line) > > My rationale here was that there aren't any files that an extra user > would need to own for web2ldap to run. Using nobody seemed the simplest > approach to nulling out any privileges for the service to work. "nobody" is absolutely not allowed. $ getent passwd nobody nobody:*:32767:32767:Unprivileged user for NFS:/nonexistent:/sbin/nologin
Re: does a new port have to be the latest version?
> > What is the program? > CDIrip, the current GitHub is at https://github.com/jozip/cdirip .
Re: does a new port have to be the latest version?
On 2020/06/03 11:33, ale...@mail.com wrote: > I am working on my first port, and version 0.6.3 broke big endian > support. The software’s latest version is still broken on big endian. > The reason for this is stated in the change log as removing endian > specific code. The software compiles fine but does not function > correctly, giving errors. What is the program? > Version 0.6.2 works on big endian, which is what I’ll be using this > software on a lot. > > NetBSD has a port of the newest version of this software. It looks like > it wasn’t properly tested because they use no patches in their port > yet produce PowerPC binaries. This is unconfirmed however because I > don’t use NetBSD. >
Re: [new] sysutils/web2ldap and co
On Wed, Jun 03, 2020 at 08:19:40AM +0200, Landry Breuil wrote: > On Tue, Jun 02, 2020 at 05:01:06PM -0500, Lucas Raab wrote: > > Hello, > > > > Here are three new ports, two deps, and the one piece de resistance, > > web2ldap. > > > > sysutils/web2ldap - web-based LDAP client > > devel/py-xlwt - dep for exporting LDAP query results as XLS files > > devel/py-ldap0 - web2ldap's interface to the OpenLDAP libraries > > > > The author of web2ldap and py-ldap0 has been very responsive to some > > questions I had a few months ago and accepted a change to make it > > easier to manage on the BSDs as a whole. > > > > More information here: https://web2ldap.de/ > > Project upstream here: https://gitlab.com/ae-dir/web2ldap > > > > I've been using this in my own tree for several months now with no > > issues. That being said, I hope I didn't get complacent in the > > submission. > > > > Completely understand if this is too niche to warrant being included in > > the tree. If not so terribly niche, feedback? > > That looks interesting and a very complete ldap client/admin tool. Will > have to try it on some of my servers, but some porting nits first: > > - WANTLIB = python3.7m -> use ${MODPY_WANTLIB} > - use MODPY_EGG_VERSION in web2ldap, this way it gets substituted in the > PLIST See above about complacency :) I'll get those updated. > - are *all* those @sample required in ${SYSCONFDIR}/web2ldap ? that looks > a lot. I suppose not. I was going for a `pkg_add web2ldap` and `rcctl start web2ldap` style where moving files around was already sorted out for the user. Being too helpful there? It is rather a lot of files to manage in the PLIST... > - instead of using 'nobody', create a new separate user for the daemon, > look for examples in other ports' PLIST (@newuser/@newgroup, + > db/user.list line) My rationale here was that there aren't any files that an extra user would need to own for web2ldap to run. Using nobody seemed the simplest approach to nulling out any privileges for the service to work. > > Landry >
Re: does a new port have to be the latest version?
> > Version 0.6.2 works on big endian, which is what I’ll be using this > > software on a lot. > If you worked on a 0.6.2 port and 0.6.3 gets out before your port > submission, this is by no means any blocker. > This isn’t the case. 0.6.2 was released in 2002 and the latest version in 2018. However there was only one release in between the 2, in 2004 and there have not been massive changes to the core program. If there was a currently supported option for what this software does I would use it instead however this is the only option for big endian. > We encourage using the latest versions where possible, but if known > breakage is on the roadmap, there's little point in updating until > upstream fixed it - afterall, I even consider it a good sign that you > spotted the regression and hold back on updating it. > > On the other hand, ports stuck at a specific version without updates in > sight tend to be removed after longer periods of time without updates. > Even if they work 100% fine this is the case? > > NetBSD has a port of the newest version of this software. It looks like > > it wasn’t properly tested because they use no patches in their port > > yet produce PowerPC binaries. This is unconfirmed however because I > > don’t use NetBSD. > Reach out to them and ask. > > I’ve emailed NetBSD on this and am waiting for a response, I almost did so before writing this email to ports.
Re: does a new port have to be the latest version?
> I guess this depend of the port and how old the release you want to > include is. For a network daemon it's better if it's up to date but for > a game or non network tool, I think it's possible to have an older > version. > Well that’s good news. Version 0.6.2 is from 2002. Version 0.6.3 is from 2004, and 0.6.4 is the latest from 2018. This is a non network tool to extract a specific file type. A program like this doesn’t need constant updates.
Re: Firefox and MIME
On Tue, Jun 02, 2020 at 01:18:50PM -0500, joshua stein wrote: > On Tue, 02 Jun 2020 at 17:07:18 +0100, Laurence Tratt wrote: > > At some point recently our mozilla-firefox port stopped automatically > > opening > > downloaded files for me. pkg/README says: > > > > Due to unveil(2) limiting filesystem access, only the default MIME > > handler registered for a given type can be chosen when opening a > > downloaded file. For example, to use the mupdf package to read > > PDFs, it must be registered as the default with XDG: > > > > $ xdg-mime default mupdf.desktop application/pdf > > > > And, indeed, I have had that set for some while and it used to work fine. > > However, when I click on a PDF link in Firefox, it now brings up the > > (not-very-useful because of unveil!) "launch application" window. > > > > I'm sure I'm missing out on something obvious, but I'm not sure what it > > might > > be (and I know someone else who's equally baffled). In case it's relevant, > > I'm using XFCE (so DBUS is running) on -current as of a couple of days ago, > > with the firefox-76.0p0 package on amd64. If anyone has any pointers, I know > > at least two of us who will welcome them! > > Firefox tries to execute xdg-open to parse the MIME stuff and run > the appropriate handler for application/pdf. > > https://github.com/mozilla/gecko-dev/blob/c686b5d5614da653c20c689cea96a80ae598a1a1/toolkit/system/gnome/nsGIOService.cpp#L504-L514 > > Up until Glib 2.64.2, this was done by executing gio-launch-desktop > with xdg-open as an argument. This worked out for us because > xdg-open is a shell script and gio-launch-desktop was a binary, so > we could just unveil /usr/local/bin/gio-launch-desktop in Firefox's > unveil.main. > > This changed as of updating our Glib port to 2.64.2 a few weeks ago, > and now Glib no longer ships with gio-launch-desktop, trying to run > xdg-open via /bin/sh directly: > > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1362/diffs > > I'm not sure how best to handle this going forward, but unveiling > /bin/sh is not a good idea. Definitely. Filed https://gitlab.gnome.org/GNOME/glib/-/issues/2123 to try to get upstream to revert said MR and reinstate gio-launch-desktop, thanks for finding this change. > Perhaps we include a small compiled utility with Firefox that just > hard-codes execve("/usr/local/bin/xdg-open", ...) and then unveil > that binary instead of gio-launch-desktop? Firefox would still need > modifying to exec that utility directly instead of using Glib's > g_app_info_create_from_commandline. That's imo ugly, as it would only 'fix' it for firefox and not all potential unveiled glib apps. Plus, it would have to be upstreamed first at mozilla (you know my own policy..) Landry
Re: does a new port have to be the latest version?
On Wed, Jun 03, 2020 at 11:33:08AM +0200, ale...@mail.com wrote: > I am working on my first port, and version 0.6.3 broke big endian > support. The software’s latest version is still broken on big endian. > The reason for this is stated in the change log as removing endian > specific code. The software compiles fine but does not function > correctly, giving errors. > > Version 0.6.2 works on big endian, which is what I’ll be using this > software on a lot. If you worked on a 0.6.2 port and 0.6.3 gets out before your port submission, this is by no means any blocker. We encourage using the latest versions where possible, but if known breakage is on the roadmap, there's little point in updating until upstream fixed it - afterall, I even consider it a good sign that you spotted the regression and hold back on updating it. On the other hand, ports stuck at a specific version without updates in sight tend to be removed after longer periods of time without updates. > NetBSD has a port of the newest version of this software. It looks like > it wasn’t properly tested because they use no patches in their port > yet produce PowerPC binaries. This is unconfirmed however because I > don’t use NetBSD. Reach out to them and ask.
Re: does a new port have to be the latest version?
On Wed, 3 Jun 2020 11:33:08 +0200 ale...@mail.com: > I am working on my first port, and version 0.6.3 broke big endian > support. The software’s latest version is still broken on big endian. > The reason for this is stated in the change log as removing endian > specific code. The software compiles fine but does not function > correctly, giving errors. > > Version 0.6.2 works on big endian, which is what I’ll be using this > software on a lot. > > NetBSD has a port of the newest version of this software. It looks > like it wasn’t properly tested because they use no patches in their > port yet produce PowerPC binaries. This is unconfirmed however > because I don’t use NetBSD. > I guess this depend of the port and how old the release you want to include is. For a network daemon it's better if it's up to date but for a game or non network tool, I think it's possible to have an older version.
does a new port have to be the latest version?
I am working on my first port, and version 0.6.3 broke big endian support. The software’s latest version is still broken on big endian. The reason for this is stated in the change log as removing endian specific code. The software compiles fine but does not function correctly, giving errors. Version 0.6.2 works on big endian, which is what I’ll be using this software on a lot. NetBSD has a port of the newest version of this software. It looks like it wasn’t properly tested because they use no patches in their port yet produce PowerPC binaries. This is unconfirmed however because I don’t use NetBSD.
Re: Firefox and MIME
On Tue, Jun 02, 2020 at 01:18:50PM -0500, joshua stein wrote: Hello Joshua, > Firefox tries to execute xdg-open to parse the MIME stuff and run the > appropriate handler for application/pdf. [...] > Up until Glib 2.64.2, this was done by executing gio-launch-desktop with > xdg-open as an argument. [...] > This changed as of updating our Glib port to 2.64.2 a few weeks ago, and > now Glib no longer ships with gio-launch-desktop Aha -- I must admit, I would not have thought to look for that! > I'm not sure how best to handle this going forward, but unveiling /bin/sh > is not a good idea. Agreed. > Perhaps we include a small compiled utility with Firefox that just > hard-codes execve("/usr/local/bin/xdg-open", ...) and then unveil that > binary instead of gio-launch-desktop? That's probably the most-effort option, but probably the friendliest to users, in the sense that it restores the old behaviour? I also wondered -- if gio-launch-desktop has disappeared in general (and certainly we no longer have any port which includes it in a PLIST!), then presumably Firefox on other platforms will also have to find another way of executing xdg-open? So perhaps the problem might even go away (or, at least, mutate into another problem) with Firefox 77.0? Laurie