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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/03 17:13:20 Modified files: graphics/simple-scan: Makefile distinfo Log message: Update to simple-scan-3.36.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/03 16:55:47 Modified files: x11/gnome/control-center: Makefile distinfo x11/gnome/control-center/pkg: PLIST Log message: Update to gnome-control-center-3.36.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/03 14:54:28 Modified files: net/dhcpcd : Makefile net/dhcpcd/pkg : PLIST Log message: fix @exec-update warning message in previous.
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 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
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/03 08:43:06 Modified files: sysutils/grafana: Tag: OPENBSD_6_7 Makefile distinfo sysutils/grafana/pkg: Tag: OPENBSD_6_7 PLIST Log message: MFC update to grafana-6.7.4 https://grafana.com/blog/2020/06/03/grafana-6.7.4-and-7.0.2-released-with-important-security-fix/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/03 08:42:20 Modified files: sysutils/grafana: Makefile distinfo Log message: update to grafana-6.7.4 https://grafana.com/blog/2020/06/03/grafana-6.7.4-and-7.0.2-released-with-important-security-fix/
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 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".
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/03 07:29:55 Modified files: x11/gnome/librsvg: Makefile distinfo Log message: Update to librsvg-2.48.6.
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: CVS: cvs.openbsd.org: ports
On Wed, Jun 03, 2020 at 11:48:08AM +0200, Antoine Jacoutot wrote:
> On Tue, Jun 02, 2020 at 08:07:40AM -0600, James Turner wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: jtur...@cvs.openbsd.org 2020/06/02 08:07:40
> >
> > Log message:
> > Import ports/lang/microscheme. ok abieber@
> >
> > Microscheme is a Scheme subset designed for Atmel microcontrollers,
> > especially as found on Arduino boards.
> >
> > Status:
> >
> > Vendor Tag: jturner
> > Release Tags: jturner_20200602
> >
> > N ports/lang/microscheme/Makefile
> > N ports/lang/microscheme/distinfo
> > N ports/lang/microscheme/pkg/DESCR
> > N ports/lang/microscheme/pkg/PLIST
> > N ports/lang/microscheme/patches/patch-makefile
> >
> > No conflicts created by this import
>
> Doesn't build.
>
Thanks. Just committed a fix. Didn't realize xxd was part of vim!
> >>> Building on exopi-4 under lang/microscheme
> DIST = [lang/microscheme:microscheme-0.9.4-3bc5611b.tar.gz]
> FULLPKGNAME = microscheme-0.9.4
> distfiles size=29569
> >>> Running patch in lang/microscheme at 1591176277.21
> ===> lang/microscheme
> ===> Verifying specs: c
> ===> found c.96.0
> ===> Checking files for microscheme-0.9.4
> `/exopi-cvs/ports/distfiles/microscheme-0.9.4-3bc5611b.tar.gz' is up to date.
> >> (SHA256) microscheme-0.9.4-3bc5611b.tar.gz: OK
> ===> Extracting for microscheme-0.9.4
> ===> Patching for microscheme-0.9.4
> ===> Applying OpenBSD patch patch-makefile
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --
> |$OpenBSD: patch-makefile,v 1.1.1.1 2020/06/02 14:07:40 jturner Exp $
> |
> |Index: makefile
> |--- makefile.orig
> |+++ makefile
> --
> Patching file makefile using Plan A...
> Hunk #1 succeeded at 9.
> done
> ===> Compiler link: clang -> /usr/bin/clang
> ===> Compiler link: clang++ -> /usr/bin/clang++
> ===> Compiler link: cc -> /usr/bin/cc
> ===> Compiler link: c++ -> /usr/bin/c++
> >>> Running configure in lang/microscheme at 1591176278.81
> ===> lang/microscheme
> ===> Generating configure for microscheme-0.9.4
> ===> Configuring for microscheme-0.9.4
> >>> Running build in lang/microscheme at 1591176279.54
> ===> lang/microscheme
> ===> Building for microscheme-0.9.4
> echo "// Hexified internal microscheme files." > src/assembly_hex.c
> xxd -i src/preamble.s >> src/assembly_hex.c
> /bin/sh: xxd: not found
> *** Error 127 in
> /exopi-obj/pobj/microscheme-0.9.4/microscheme-3bc5611bd4194dae149ee6af58a95a7af3e63f34
> (makefile:11 'hexify')
> *** Error 2 in lang/microscheme
> (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2912
> '/exopi-obj/pobj/microscheme-0.9.4/.build_done': @cd /e...)
> *** Error 2 in lang/microscheme
> (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2578 'build':
> @lock=microscheme-0.9.4; export _LOCKS_HELD="...)
> ===> Exiting lang/microscheme with an error
> *** Error 1 in /exopi-cvs/ports (infrastructure/mk/bsd.port.subdir.mk:137
> 'build': @: ${echo_msg:=echo}; : ${target:=build}; for i in ; do...)
> >>> Ended at 1591176279.93
> Error: job failed with 512 on exopi-4 at 1591176279
>
>
> --
> Antoine
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 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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2020/06/03 06:58:08 Modified files: lang/microscheme: Makefile Log message: Fix build, vim is needed for xxd, found and pointed out by aja@
Re: CVS: cvs.openbsd.org: ports
On 2020/05/18 11:32, Brian Callahan wrote: > CVSROOT: /cvs > Module name: ports > Changes by: bcal...@cvs.openbsd.org 2020/05/18 11:32:17 > > Modified files: > games/julius : Makefile distinfo > > Log message: > Update to julius-1.4.0 > Changelog: https://github.com/bvschaik/julius/releases/tag/v1.4.0 > Packaging fails, looks like it is missing a LIB_DEPENDS with path to png. ===> Building package for julius-1.4.0 Create /mnt/packages/i386/all/julius-1.4.0.tgz Missing library for png>=0.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/03 06:32:33 Modified files: net/dhcpcd : Makefile net/dhcpcd/pkg : PLIST Log message: dhcpcd: warn if the existing _dhcpcd user was created with /var/empty homedir, this was only the case for 11 days so hopefully not too many people ran into it. make sure /var/dhcpcd is created for startup.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/03 06:30:53 Modified files: net/unifi/testing: Makefile Log message: unifi/testing: set BUILD_V now this is a public release candidate
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 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 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 :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/06/03 06:06:05 Modified files: sysutils/random_run: Makefile distinfo Log message: new release, with a new option
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
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: r...@cvs.openbsd.org2020/06/03 05:00:51 Modified files: mail/offlineimap: Makefile distinfo Log message: Update OfflineIMAP to version 7.3.3 Removing myself as maintaier since I'm not using it anymore. OK tb@
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/03 03:49:55 Modified files: x11/spice-gtk : Makefile Log message: textproc/asciidoc is picked up if present, so add it to BDEP. spotted by naddy@
Re: CVS: cvs.openbsd.org: ports
On Tue, Jun 02, 2020 at 08:07:40AM -0600, James Turner wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: jtur...@cvs.openbsd.org 2020/06/02 08:07:40
>
> Log message:
> Import ports/lang/microscheme. ok abieber@
>
> Microscheme is a Scheme subset designed for Atmel microcontrollers,
> especially as found on Arduino boards.
>
> Status:
>
> Vendor Tag: jturner
> Release Tags: jturner_20200602
>
> N ports/lang/microscheme/Makefile
> N ports/lang/microscheme/distinfo
> N ports/lang/microscheme/pkg/DESCR
> N ports/lang/microscheme/pkg/PLIST
> N ports/lang/microscheme/patches/patch-makefile
>
> No conflicts created by this import
Doesn't build.
>>> Building on exopi-4 under lang/microscheme
DIST = [lang/microscheme:microscheme-0.9.4-3bc5611b.tar.gz]
FULLPKGNAME = microscheme-0.9.4
distfiles size=29569
>>> Running patch in lang/microscheme at 1591176277.21
===> lang/microscheme
===> Verifying specs: c
===> found c.96.0
===> Checking files for microscheme-0.9.4
`/exopi-cvs/ports/distfiles/microscheme-0.9.4-3bc5611b.tar.gz' is up to date.
>> (SHA256) microscheme-0.9.4-3bc5611b.tar.gz: OK
===> Extracting for microscheme-0.9.4
===> Patching for microscheme-0.9.4
===> Applying OpenBSD patch patch-makefile
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-makefile,v 1.1.1.1 2020/06/02 14:07:40 jturner Exp $
|
|Index: makefile
|--- makefile.orig
|+++ makefile
--
Patching file makefile using Plan A...
Hunk #1 succeeded at 9.
done
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
>>> Running configure in lang/microscheme at 1591176278.81
===> lang/microscheme
===> Generating configure for microscheme-0.9.4
===> Configuring for microscheme-0.9.4
>>> Running build in lang/microscheme at 1591176279.54
===> lang/microscheme
===> Building for microscheme-0.9.4
echo "// Hexified internal microscheme files." > src/assembly_hex.c
xxd -i src/preamble.s >> src/assembly_hex.c
/bin/sh: xxd: not found
*** Error 127 in
/exopi-obj/pobj/microscheme-0.9.4/microscheme-3bc5611bd4194dae149ee6af58a95a7af3e63f34
(makefile:11 'hexify')
*** Error 2 in lang/microscheme
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2912
'/exopi-obj/pobj/microscheme-0.9.4/.build_done': @cd /e...)
*** Error 2 in lang/microscheme
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2578 'build':
@lock=microscheme-0.9.4; export _LOCKS_HELD="...)
===> Exiting lang/microscheme with an error
*** Error 1 in /exopi-cvs/ports (infrastructure/mk/bsd.port.subdir.mk:137
'build': @: ${echo_msg:=echo}; : ${target:=build}; for i in ; do...)
>>> Ended at 1591176279.93
Error: job failed with 512 on exopi-4 at 1591176279
--
Antoine
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2020/06/03 03:28:54 Modified files: devel/git : Makefile distinfo devel/git/patches: patch-config_mak_uname patch-gitweb_gitweb_perl patch-t_test-lib_sh devel/git/pkg : PLIST-main Log message: Update to git 2.27.0 https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.27.0.txt
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2020/06/03 01:09:45 Modified files: sysutils/ncdu : Makefile distinfo Log message: Update ncdu to 1.15.
Re: update devel/pcre2 10.35
Nam Nguyen writes:
> Here is an update for devel/pcre2 10.35, released May 9, 2020.
ping
>
> Changelog:
> https://vcs.pcre.org/pcre2/code/trunk/ChangeLog?revision=1254=markup
>
> This diff does the following:
> - Resyncs upstream library major/minor numbers with
> ${WRKSRC}/src/pcre2.h.generic instead of shared_libs.log
> - patch-RunGrepTest reapplied with new /g suffix
> - Minor bumps for the pcre2 libraries because of changelog items 5 and 11.
> These add PCRE2_SUBSTITUTE_LITERAL and PCRE2_SUBSTITUTE_REPLACEMENT_ONLY
> as new values for the `options' argument of pcre2_substitute(...uint32_t
> options,...). pcre2.h exports these new values.
> - No versioning bumps due to item 15 because it can be considered a
> bugfix. set_start_bits() now limits depth of recursion to 1000, adds
> depthptr to the argument list and adds a new error return code
> (SSB_TOODEEP). (Sequence is pcre2_compile() --> pcre2_study.c:1672
> study() --> set_start_bits()). study() and set_start_bits() are both
> private helpers while pcre2_compile() is part of the API.
> https://vcs.pcre.org/pcre2/code/tags/pcre2-10.35/ChangeLog?r1=1211=1212
>
> https://vcs.pcre.org/pcre2/code/tags/pcre2-10.35/src/pcre2_study.c?r1=1180=1213
>
> Unit tests pass. wget and fish work in my testing. Feedback and tests
> are welcome.
>
Index: Makefile
===
RCS file: /cvs/ports/devel/pcre2/Makefile,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 Makefile
--- Makefile13 Feb 2020 11:05:11 - 1.12
+++ Makefile26 May 2020 10:55:43 -
@@ -2,11 +2,11 @@
COMMENT = perl-compatible regular expression library, version 2
-DISTNAME = pcre2-10.34
+DISTNAME = pcre2-10.35
-SHARED_LIBS += pcre2-16 0.4 # 9.0
-SHARED_LIBS += pcre2-32 0.4 # 9.0
-SHARED_LIBS += pcre2-8 0.5 # 9.0
+SHARED_LIBS += pcre2-16 0.5 # 10.35
+SHARED_LIBS += pcre2-32 0.5 # 10.35
+SHARED_LIBS += pcre2-8 0.6 # 10.35
SHARED_LIBS += pcre2-posix 0.3 # 2.3
CATEGORIES = devel
Index: distinfo
===
RCS file: /cvs/ports/devel/pcre2/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo13 Feb 2020 11:05:11 - 1.6
+++ distinfo26 May 2020 10:55:43 -
@@ -1,2 +1,2 @@
-SHA256 (pcre2-10.34.tar.gz) = 2mq6e6JQnpGOQfT3RKWfpBokJcWaKYojLn/oVpHgA3k=
-SIZE (pcre2-10.34.tar.gz) = 2271533
+SHA256 (pcre2-10.35.tar.gz) = j9zvjI9M1zUWndAiX9AQSHlwwbyt1J6bkOJsclCjPck=
+SIZE (pcre2-10.35.tar.gz) = 2299082
Index: patches/patch-RunGrepTest
===
RCS file: /cvs/ports/devel/pcre2/patches/patch-RunGrepTest,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-RunGrepTest
--- patches/patch-RunGrepTest 13 Feb 2020 11:05:11 - 1.3
+++ patches/patch-RunGrepTest 26 May 2020 10:55:43 -
@@ -12,8 +12,8 @@ Index: RunGrepTest
- Linux)
+ OpenBSD)
printf 'abc\0def' >testNinputgrep
--$valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep |
sed 's/\x00/ZERO/' >>testtrygrep
-+$valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep |
gsed 's/\x00/ZERO/' >>testtrygrep
+-$valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep |
sed 's/\x00/ZERO/g' >>testtrygrep
++$valgrind $vjs $pcre2grep -na --newline=nul "^(abc|def)" testNinputgrep |
gsed 's/\x00/ZERO/g' >>testtrygrep
echo "" >>testtrygrep
;;
*)
Re: [new] sysutils/web2ldap and co
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
- are *all* those @sample required in ${SYSCONFDIR}/web2ldap ? that looks
a lot.
- 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)
Landry
