CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/22 23:43:12 Modified files: multimedia/mpv : Makefile Log message: Enable libarchive support. from Brad
Re: colortail crash and fix
Robert Nagy wrote: > Hey, > > Can you guys try this diff? oh, fun, upstream fixed it a different way. i don't have a full ports tree on this laptop, but the new code looks like it could work. // set filename in options class string str = filename.str(); char* cs = new char[str.length()+1]; std::strcpy(cs, str.c_str()); o->cfg_filenames[o->nr_cfg_files] = cs; // set filename in options class string str = filename.str(); char* cs = new char[str.length()+1]; std::strcpy(cs, str.c_str()); o->cfg_filenames[o->nr_cfg_files] = cs;
Re: colortail crash and fix
Hey,
Can you guys try this diff?
http://ix.io/286T
On 22/01/20 20:35 -0500, Ted Unangst wrote:
> Today's selected c++ reading:
> Before any call to str() that uses the result as a C string,
> the buffer must be null-terminated, typically with std::ends.
>
> Found by mlarkin using MALLOC_OPTIONS=SU.
>
> I leave it to the ports wizards to incorporate the patch.
>
>
> --- OptionsParser.cc.orig Wed Aug 4 19:23:39 1999
> +++ OptionsParser.cc Wed Jan 22 20:32:29 2020
> @@ -17,8 +17,8 @@
> Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> -#include
> -#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -27,6 +27,8 @@
> #include "Info.h"
> #include "Usage.h"
>
> +using namespace std;
> +
> // methods for class Options
>
> Options::Options()
> @@ -138,6 +140,7 @@
> {
>// found seperator
>// set filename in options class
> + filename << std::ends;
>o->cfg_filenames[o->nr_cfg_files] = filename.str();
>
>// increase the nr_cfg_files counter
> @@ -154,6 +157,7 @@
> {
>// found end of string
>// set filename in options class
> + filename << std::ends;
>o->cfg_filenames[o->nr_cfg_files] = filename.str();
>
>// increase the nr_cfg_files counter
>
--
Regards,
Robert Nagy
Re: update net/qbittorrent 4.2.1
Rafael Sadowski writes:
> On Sun Jan 19, 2020 at 03:38:29PM -0800, Nam Nguyen wrote:
>> Here is a diff to update net/qbittorrent to 4.2.1, released on December
>> 17, 2019.
>>
>> * Uses the proposed update to net/libtorrent-rasterbar 1.2.3 that moves
>> to python 3 and proposed fix for devel/boost python 3 bindings.
>> * python 2 is an optional dependency used at runtime for this port for
>> some runtime search plugin stuff among other things. I left it as is.
>> * Builds translations
>> * Regen WANTLIB
>>
>> Changelog:
>> https://github.com/qbittorrent/qBittorrent/blob/118af03534e5ded6d3c8323b5dbeeff57b177193/Changelog
>> Feedback and tests are welcome.
>
> Thanks, see comments below.
>> +# compile translations
>> +pre-build:
>> +@cd ${WRKBUILD}/src && make compiler_lrelease_make_all
>> +@cd ${WRKBUILD}/src && make compiler_uic_make_all
>
> Please use: ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f
> Makefile compiler_lrelease_make_all instead pure make.
Investigating this revealed incorrect qmake/gmake behavior. src/Makefile
is generated by qmake. It contains include directives of the form:
-include .deps/app/application.d
-include .deps/app/applicationinstancemanager.d
-include .deps/app/cmdoptions.d
With the -include directives, gmake tries to compile files that depend
on the translations before the translations have been generated. It also
tries to compile files that depend on the generated src/ui_*.h before
they have been generated.
Here is an updated diff that removes all -include directives.
https://www.gnu.org/software/make/manual/html_node/Include.html
Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile.inc
--- Makefile.inc12 Jul 2019 20:48:47 - 1.6
+++ Makefile.inc23 Jan 2020 04:48:58 -
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile.inc,v 1.6 2019/07/12 20:48:47 sthen Exp $
-VER = 4.1.5
+VER = 4.2.1
DISTNAME = qbittorrent-${VER}
DIST_SUBDIR = qbittorrent
Index: qbittorrent/Makefile
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- qbittorrent/Makefile7 Nov 2019 17:40:36 - 1.7
+++ qbittorrent/Makefile23 Jan 2020 04:48:58 -
@@ -1,10 +1,9 @@
# $OpenBSD: Makefile,v 1.7 2019/11/07 17:40:36 fcambus Exp $
COMMENT = BitTorrent client with Qt interface
-REVISION = 2
WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Network Qt5Xml boost_system
-WANTLIB += boost_system-mt c m torrent-rasterbar z
+WANTLIB += boost_system-mt c crypto m ssl torrent-rasterbar z
WANTLIB += GL Qt5DBus Qt5Gui Qt5Svg Qt5Widgets
LIB_DEPENDS += net/libtorrent-rasterbar \
@@ -14,6 +13,11 @@ LIB_DEPENDS += net/libtorrent-rasterbar
RUN_DEPENDS += lang/python/2.7 \
x11/gtk+3,-guic \
devel/desktop-file-utils
+
+# remove include directives which cause incorrect gmake behavior
+pre-build:
+ @cd ${WRKBUILD}/src && \
+ sed -ie "/^\-include/d" Makefile
pre-install:
${SUBST_CMD} ${WRKSRC}/conf.pri
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- qbittorrent/distinfo4 Jan 2019 22:20:49 - 1.4
+++ qbittorrent/distinfo23 Jan 2020 04:48:58 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.1.5.tar.gz) =
SrEkunYL1T3XYP/O8CHjWUKIkjYH6BZAkwPAmNNzD6w=
-SIZE (qbittorrent/qbittorrent-4.1.5.tar.gz) = 7739271
+SHA256 (qbittorrent/qbittorrent-4.2.1.tar.gz) =
/9wg388BBqlBroQiHkXuL5F36xjuxsD8ULJhVvC6MSY=
+SIZE (qbittorrent/qbittorrent-4.2.1.tar.gz) = 7843513
Index: qbittorrent/patches/patch-configure
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/patches/patch-configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-configure
--- qbittorrent/patches/patch-configure 4 Jan 2019 22:20:49 - 1.2
+++ qbittorrent/patches/patch-configure 23 Jan 2020 04:48:58 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-configure,v 1.2 2019/01/
Index: configure
--- configure.orig
+++ configure
-@@ -5405,12 +5405,12 @@ if test -n "$zlib_CFLAGS"; then
+@@ -5478,12 +5478,12 @@ if test -n "$zlib_CFLAGS"; then
pkg_cv_zlib_CFLAGS="$zlib_CFLAGS"
elif test -n "$PKG_CONFIG"; then
if test -n "$PKG_CONFIG" && \
@@ -19,7 +19,7 @@ Index: configure
test "x$?" != "x0" && pkg_failed=yes
else
pkg_failed=yes
-@@ -5422,12 +5422,12 @@ if test -n "$zlib_LIBS"; then
+@@ -5495,12 +5495,12 @@ if test -n "$zlib_LIBS"; then
pkg_cv_zlib_LIBS="$zlib_LIBS"
elif test -n "$PKG_CONFIG"; then
Re: UPDATE mbedtls-2.16.4
On Thu 16/01/2020 07:22, Bjorn Ketelaars wrote: > mbedtls-2.16.4 has been released, which fixes a side channel attack on > ECDSA (CVE-2019-18222). More information can be found at > https://tls.mbed.org/tech-updates/releases/mbedtls-2.16.4-and-2.7.13-released > > Changes to port: > - Minor of mbedcrypto has been bumped as a symbol has been added. > > Testing: > - 'make test' runs successfully > - build tested all consumers > - run tested in combination with openvpn,mbedtls > > I also tested this update on current. > > OK to push this update to both snapshot and current? Ping... For your convenience: diff --git Makefile Makefile index 497dcde0b01..ba301feb7f1 100644 --- Makefile +++ Makefile @@ -4,12 +4,12 @@ PORTROACH=limit:^2\.16 COMMENT= SSL library with an intuitive API and readable source code -DISTNAME= mbedtls-2.16.3 +DISTNAME= mbedtls-2.16.4 EXTRACT_SUFX= -gpl.tgz # check SOVERSION SHARED_LIBS += mbedtls 6.1 # 12 -SHARED_LIBS += mbedcrypto4.3 # 3 +SHARED_LIBS += mbedcrypto4.4 # 3 SHARED_LIBS += mbedx509 3.1 # 0 CATEGORIES=security diff --git distinfo distinfo index d8a902b3eb9..258fc934363 100644 --- distinfo +++ distinfo @@ -1,2 +1,2 @@ -SHA256 (mbedtls-2.16.3-gpl.tgz) = /QH+SyiRFt93gdBeHvcStsmII8UzT0onQE8TqNBm72o= -SIZE (mbedtls-2.16.3-gpl.tgz) = 2560598 +SHA256 (mbedtls-2.16.4-gpl.tgz) = X9ucQ6tD/ZvMNjFQgXCwie3nuG3WVSU6k8sP/rQjCfM= +SIZE (mbedtls-2.16.4-gpl.tgz) = 2699806 diff --git patches/patch-include_mbedtls_config_h patches/patch-include_mbedtls_config_h index 3dc01becdf9..68e6102944f 100644 --- patches/patch-include_mbedtls_config_h +++ patches/patch-include_mbedtls_config_h @@ -6,7 +6,7 @@ www/hiawatha. Index: include/mbedtls/config.h --- include/mbedtls/config.h.orig +++ include/mbedtls/config.h -@@ -1678,7 +1678,7 @@ +@@ -1685,7 +1685,7 @@ * * Uncomment this to enable pthread mutexes. */ @@ -15,7 +15,7 @@ Index: include/mbedtls/config.h /** * \def MBEDTLS_VERSION_FEATURES -@@ -2870,7 +2870,7 @@ +@@ -2881,7 +2881,7 @@ * * Enable this layer to allow use of mutexes within mbed TLS */
Re: [NEW] textproc/scdoc
Having looked at it a bit more, I see other statically linked ports with empty WANTLIB (e.g. shells/tcsh), but that doesn't necessarily mean it's correct. Since I don't know, here's another tgz identical to the last but with WANTLIB=c (which, if you remove -static, is what it would require). scdoc-wantlib.tgz Description: GNU Zip compressed data
NEW security/ssllabs-scan
Attached is the port for SSLLabs.com API written in golang. From pkg/DESCR: This tool is a command-line client for the SSL Labs APIs, designed for automated and/or bulk testing. SSL Labs API expose the complete SSL/TLS server testing functionality in a programmatic fashion, allowing for scheduled and bulk assessment. They are making their API available to encourage site operators to regularly test servers configurations. /quote While the license is Apache2 (https://github.com/ssllabs/ssllabs-scan/blob/master/LICENSE), the terms of use (https://www.ssllabs.com/about/terms.html) contains some restrictions under the API section that I'm not sure if it's legit for inclusion in OpenBSD's ports (https://www.ssllabs.com/about/terms.html). Thanks g ssllabs-scan-1.5.0.tgz Description: Binary data
Re: UPDATE fonts/ibm-plex to 4.0.2
On 1/17/20 3:11 PM, Anthony J. Bentley wrote:
> George Rosamond writes:
>> +GH_ACCOUNT =IBM
>> +GH_PROJECT =plex
>> +GH_TAGNAME =v${V}
>> +
>> # SIL OFL 1.1
>> PERMIT_PACKAGE =Yes
>>
>> -MASTER_SITES = https://github.com/IBM/plex/releases/download/v
>> $V/
>> -
>> -DISTFILES = OpenType.zip \
>> -TrueType.zip
>> -
>> -DIST_SUBDIR = ibm-plex-$V
>> -
>> HOMEPAGE = https://www.ibm.com/plex/
>
> GH_* should not be used for every GitHub project, only those that don't
> upload their own distfiles and thus need to fall back on autogenerated
> ones. Plex is one of the projects that does upload its own .zips, so
> please keep using MASTER_SITES/DISTFILES (and DIST_SUBDIR since they're
> unversioned).
>
diff attached adjusted to use .zip releases.
A number of graphical changes were made to fonts, plus appending "Sans"
to non-Latin script font names.
https://github.com/IBM/plex/releases
I didn't include web fonts in Web.zip yet, since I want to confirm that
all the TTF and OTF fonts are already included in the Web.zip file, as
it appears.
Thanks
g
Index: ibm-plex//Makefile
===
RCS file: /cvs/ports/fonts/ibm-plex/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- ibm-plex//Makefile 12 Jul 2019 20:46:12 - 1.9
+++ ibm-plex//Makefile 23 Jan 2020 03:48:19 -
@@ -3,7 +3,7 @@
COMMENT = IBM's corporate type family
CATEGORIES = fonts
-V = 2.0.0
+V = 4.0.2
PKGNAME = ibm-plex-$V
# SIL OFL 1.1
Index: ibm-plex//distinfo
===
RCS file: /cvs/ports/fonts/ibm-plex/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- ibm-plex//distinfo 11 Jun 2019 07:17:23 - 1.7
+++ ibm-plex//distinfo 23 Jan 2020 03:48:19 -
@@ -1,4 +1,4 @@
-SHA256 (ibm-plex-2.0.0/OpenType.zip) = aCWG4MCHIrUt/TTpJHF4OakKvufFqWYGF/Bhi8cvZtM=
-SHA256 (ibm-plex-2.0.0/TrueType.zip) = zvqebl2gA/UKRnzk9CrzS0J7nBk6v8PjPIAMSrx28cs=
-SIZE (ibm-plex-2.0.0/OpenType.zip) = 6607070
-SIZE (ibm-plex-2.0.0/TrueType.zip) = 7662205
+SHA256 (ibm-plex-4.0.2/OpenType.zip) = ZhXFtez1c2pe0pt/mbeA065QPoGWL+IlmzD9wyJBbZ0=
+SHA256 (ibm-plex-4.0.2/TrueType.zip) = VWT3m/3EpW+fJ6rMaLaxdasgXrpmjklvRKEgUfOjN60=
+SIZE (ibm-plex-4.0.2/OpenType.zip) = 6586340
+SIZE (ibm-plex-4.0.2/TrueType.zip) = 7658406
Index: ibm-plex//pkg/PLIST
===
RCS file: /cvs/ports/fonts/ibm-plex/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- ibm-plex//pkg/PLIST 11 Jun 2019 07:17:23 - 1.7
+++ ibm-plex//pkg/PLIST 23 Jan 2020 03:48:19 -
@@ -3,38 +3,6 @@ share/doc/ibm-plex/
share/doc/ibm-plex/license.txt
share/fonts/
@fontdir share/fonts/ibm-plex/
-share/fonts/ibm-plex/IBMPlexArabic-Bold.otf
-share/fonts/ibm-plex/IBMPlexArabic-Bold.ttf
-share/fonts/ibm-plex/IBMPlexArabic-ExtraLight.otf
-share/fonts/ibm-plex/IBMPlexArabic-ExtraLight.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Light.otf
-share/fonts/ibm-plex/IBMPlexArabic-Light.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Medium.otf
-share/fonts/ibm-plex/IBMPlexArabic-Medium.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Regular.otf
-share/fonts/ibm-plex/IBMPlexArabic-Regular.ttf
-share/fonts/ibm-plex/IBMPlexArabic-SemiBold.otf
-share/fonts/ibm-plex/IBMPlexArabic-SemiBold.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Text.otf
-share/fonts/ibm-plex/IBMPlexArabic-Text.ttf
-share/fonts/ibm-plex/IBMPlexArabic-Thin.otf
-share/fonts/ibm-plex/IBMPlexArabic-Thin.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Bold.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Bold.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-ExtraLight.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-ExtraLight.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Light.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Light.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Medium.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Medium.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Regular.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Regular.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-SemiBold.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-SemiBold.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Text.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Text.ttf
-share/fonts/ibm-plex/IBMPlexDevanagari-Thin.otf
-share/fonts/ibm-plex/IBMPlexDevanagari-Thin.ttf
share/fonts/ibm-plex/IBMPlexMono-Bold.otf
share/fonts/ibm-plex/IBMPlexMono-Bold.ttf
share/fonts/ibm-plex/IBMPlexMono-BoldItalic.otf
@@ -99,6 +67,22 @@ share/fonts/ibm-plex/IBMPlexSans-Thin.ot
share/fonts/ibm-plex/IBMPlexSans-Thin.ttf
share/fonts/ibm-plex/IBMPlexSans-ThinItalic.otf
share/fonts/ibm-plex/IBMPlexSans-ThinItalic.ttf
+share/fonts/ibm-plex/IBMPlexSansArabic-Bold.otf
+share/fonts/ibm-plex/IBMPlexSansArabic-Bold.ttf
+share/fonts/ibm-plex/IBMPlexSansArabic-ExtraLight.otf
+share/fonts/ibm-plex/IBMPlexSansArabic-ExtraLight.ttf
Re: [NEW] textproc/scdoc
> I _think_ it needs WANTLIB, bit I am not 100% sure on that. Once that's > sorted, OK abieber@ for import! I'm not sure when a port would or wouldn't WANTLIB=c, but lib-depends-check thinks it's superfluous here. > Side-note: If you are looking to import aerc, I have a wip of that as > well: aerc would be nice (I'm trying it out at the moment). Wasn't able to figure out how to make ports fetch go dependencies. I changed the target to pre-test as trondd suggested, which I think is correct. (I already submitted it upstream, anyway.) Attached. scdoc.tgz Description: GNU Zip compressed data
colortail crash and fix
Today's selected c++ reading:
Before any call to str() that uses the result as a C string,
the buffer must be null-terminated, typically with std::ends.
Found by mlarkin using MALLOC_OPTIONS=SU.
I leave it to the ports wizards to incorporate the patch.
--- OptionsParser.cc.orig Wed Aug 4 19:23:39 1999
+++ OptionsParser.ccWed Jan 22 20:32:29 2020
@@ -17,8 +17,8 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include
-#include
+#include
+#include
#include
#include
#include
@@ -27,6 +27,8 @@
#include "Info.h"
#include "Usage.h"
+using namespace std;
+
// methods for class Options
Options::Options()
@@ -138,6 +140,7 @@
{
// found seperator
// set filename in options class
+filename << std::ends;
o->cfg_filenames[o->nr_cfg_files] = filename.str();
// increase the nr_cfg_files counter
@@ -154,6 +157,7 @@
{
// found end of string
// set filename in options class
+filename << std::ends;
o->cfg_filenames[o->nr_cfg_files] = filename.str();
// increase the nr_cfg_files counter
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2020/01/22 17:36:56 Modified files: infrastructure/db: user.list net/iperf3 : Makefile net/iperf3/pkg : PLIST Added files: net/iperf3/pkg : iperf3.rc Log message: Implement an rc script for iperf3 that starts the server as a daemon. Add the _iperf3 user for this process. input kn@ ajacoutot@; OK sthen@ jca@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/01/22 17:36:27
Modified files:
textproc/gsed : Makefile distinfo
textproc/gsed/pkg: PLIST
Added files:
textproc/gsed/patches: patch-Makefile_in
Removed files:
textproc/gsed/patches: patch-lib_Makefile_in
patch-lib_regex_internal_h
Log message:
Update to gsed-4.8
Existing patches go away. A new patch is added because our makeinfo is too
old to regen the info file but regeneration is unneccesary, so skip it.
Use PORTHOME=${WRKDIR} to fix a broken test; from both sthen@ and cwen@
independently.
Additional testing by cwen@ and Armin Wolfermann (MAINTAINER).
ok cwen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/01/22 17:32:40 Modified files: net/wget : Makefile Added files: net/wget/patches: patch-src_openssl_c Log message: Fix wget with TLSv1.3. from beck
Re: rc script for net/iperf3 daemon
On Wed, Jan 22, 2020 at 11:33:21PM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Jan 22 2020, Klemens Nanni wrote:
> > On Wed, Jan 22, 2020 at 09:39:16PM +0100, Alexander Bluhm wrote:
> >> For my performance tests it would be convenient to start an iperf3
> >> server as daemon automatically. Can we add an rc script?
> > Seems reasonable.
> >
> >> Index: net/iperf3/pkg/iperf3.rc
> >> ===
> >> RCS file: net/iperf3/pkg/iperf3.rc
> >> diff -N net/iperf3/pkg/iperf3.rc
> >> --- /dev/null 1 Jan 1970 00:00:00 -
> >> +++ net/iperf3/pkg/iperf3.rc 22 Jan 2020 20:18:43 -
> >> @@ -0,0 +1,12 @@
> >> +#!/bin/ksh
> >> +#
> >> +# $OpenBSD$
> >> +
> >> +daemon="${TRUEPREFIX}/bin/iperf3"
> >> +daemon_flags="-s -D"
> > I think at least `-D' should be part of `$daemon', otherwise setting
> > flags only causes trouble.
>
> +1, same for -s
>
> > One might argue that `-s' for server mode belongs there as well, no?
> > Or to put it this way: does it make sense to specify `-c' for client
> > in flags? Would one want to run a client service as well perhaps?
>
> I think that's covered by -R.
>
> ok jca@ with daemon="${TRUEPREFIX}/bin/iperf3 -s -D"
>
> >> +daemon_user="_iperf3"
> >> +rc_reload=NO
Please put rc_reload after sourcing rc.subr.
See ports/infrastructure/templates/rc.template
--
Antoine
Re: devel/openmpi mpifort error; compiler
Hi Martin, On 2020-01-22 03:07, Martin Reindl wrote: On Tue, Jan 21, 2020 at 01:20:29PM -0700, j...@bitminer.ca wrote: [] Hi John, Hi Stuart, I've got around to testing this now a bit more: - Currently, the port does not use flang. It used to before the update to openmpi-4.0.1. So every Fortran feature in the current state depends solely on gcc8 from ports-gcc - Strictly speaking the COMPILER line is there for archs where there is no clang in base and base-gcc is too old. This gives archs like macppc and sparc64 a chance to compile and run openmpi - with MODULES=fortran on a base-clang archs we now have the situation that we build the openmpi binaries and librariers with ports-gcc but at runtime we use base-clang: $ mpicc -v OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1) for Fortran with Johns diff it's ports-gcc as usual: $ mpifort -v [...] gcc version 8.3.0 (GCC) It occurs to me that the same approach for FC would apply to CC. The value of CC=egcc is used to substitute in the mpicc command. With that, mpicc and mpifort would both use ports-gcc. Anyone wanting clang can use "$ OMPI_CC=clang mpicc ." This avoids the confusing use of two distinct compiler origins with OpenMPI build commands. [] I've tested the folling diff and checked the libraries for changes with the help of shared_libs.log. libopen-pal only has adress changes and libopen-rte as a tiny symbol name changed - hence the minor bump. I've also fixed the orig version in the comments for the other libraries and sprinkled some @lib markers in the PLIST while there. I build this as you described and it works for me on amd64. cheers --John
Re: rc script for net/iperf3 daemon
On Wed, Jan 22 2020, Klemens Nanni wrote:
> On Wed, Jan 22, 2020 at 09:39:16PM +0100, Alexander Bluhm wrote:
>> For my performance tests it would be convenient to start an iperf3
>> server as daemon automatically. Can we add an rc script?
> Seems reasonable.
>
>> Index: net/iperf3/pkg/iperf3.rc
>> ===
>> RCS file: net/iperf3/pkg/iperf3.rc
>> diff -N net/iperf3/pkg/iperf3.rc
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ net/iperf3/pkg/iperf3.rc 22 Jan 2020 20:18:43 -
>> @@ -0,0 +1,12 @@
>> +#!/bin/ksh
>> +#
>> +# $OpenBSD$
>> +
>> +daemon="${TRUEPREFIX}/bin/iperf3"
>> +daemon_flags="-s -D"
> I think at least `-D' should be part of `$daemon', otherwise setting
> flags only causes trouble.
+1, same for -s
> One might argue that `-s' for server mode belongs there as well, no?
> Or to put it this way: does it make sense to specify `-c' for client
> in flags? Would one want to run a client service as well perhaps?
I think that's covered by -R.
ok jca@ with daemon="${TRUEPREFIX}/bin/iperf3 -s -D"
>> +daemon_user="_iperf3"
>> +rc_reload=NO
>> +
>> +. /etc/rc.d/rc.subr
>> +
>> +rc_cmd $1
>>
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/22 15:03:30 Modified files: www/webkitgtk4 : Makefile distinfo Removed files: www/webkitgtk4/patches: patch-Source_WTF_wtf_URLHelpers_cpp patch-Source_WebCore_dom_Document_cpp Log message: Update to webkitgtk4-2.26.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/22 15:03:45 Modified files: www/webkitgtk4 : Tag: OPENBSD_6_6 Makefile distinfo Removed files: www/webkitgtk4/patches: Tag: OPENBSD_6_6 patch-Source_WTF_wtf_URLHelpers_cpp patch-Source_WebCore_dom_Document_cpp Log message: Bugfix update to webkitgtk4-2.26.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/22 14:39:07 Modified files: geo/traccar: Makefile distinfo geo/traccar/pkg: PLIST README Log message: Update to traccar-4.7, from Renaud Allard. First run after updating will be a little slower to start as it applies schema updates (adds a missing index that was responsible for slow reports). Point at login.conf fd limits in the pkg-readme, written by Renaud at my request (I discovered them the hard way ;) with a little tweak by me.
Re: mu: use ports-gcc
Stuart Henderson writes:
> On 2020/01/21 18:22, Xiyue Deng wrote:
>> Hi,
>>
>> Currently mu requires ports-clang which I think is because there was a
>> time that GCC 4.9 didn't support C++14. Now that GCC is on 8.3, mu can
>> be unblocked for GCC archs as well. I didn't change patch level as I
>> think there is no visible change, but correct me if I'm wrong.
>>
>> Tested on mips64el/loongson.
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/mail/mu/Makefile,v
>> retrieving revision 1.18
>> diff -u -p -r1.18 Makefile
>> --- Makefile 21 Jul 2019 00:10:04 - 1.18
>> +++ Makefile 22 Jan 2020 02:16:59 -
>> @@ -14,7 +14,7 @@ PERMIT_PACKAGE=Yes
>>
>> WANTLIB+= assuan c ffi gio-2.0 glib-2.0 gmime-3.0 gmodule-2.0
>> WANTLIB+= gobject-2.0 gpg-error gpgme gthread-2.0 iconv
>> -WANTLIB+= intl json-glib-1.0 m pcre pthread ${COMPILER_LIBCXX}
>> +WANTLIB+= intl json-glib-1.0 m pcre pthread
>> WANTLIB+= uuid xapian z
>
> ${COMPILER_LIBCXX} should stay in the list. Seems that idn2 and unistring
> should be added too.
>
> Also needs a REVISION bump.
>
> btw your mail was quoted-printable encoded and the patch couldn't be applied
> directly.
>
Thanks for reviewing the patch! This seems to be caused by PGP
signing. Is there a way to workaround this or I need to attach the
patch instead of inlining it when sending signed emails?
>> # C++14 required
>> -COMPILER= base-clang ports-clang
>> +COMPILER= base-clang ports-gcc
>
> This part is ok with me with the bump added.
>
>> AUTOCONF_VERSION= 2.69
>> AUTOMAKE_VERSION= 1.15
signature.asc
Description: PGP signature
Re: mu: use ports-gcc
Stefan Hagen writes:
> Stuart Henderson wrote:
>> On 2020/01/22 18:25, Stefan Hagen wrote:
>>> Stuart Henderson wrote:
On 2020/01/21 18:22, Xiyue Deng wrote:
> # C++14 required
> -COMPILER=base-clang ports-clang
>+COMPILER= base-clang ports-gcc
This part is ok with me with the bump added.
>>>
>>> Experiement below:
>>>
>>> I don't have a gcc architecture available, so i tried to compile mail/mu
>>> und its dependency database/xapian-core with COMPILER= ports-gcc set on
>>> my amd64 box.
>>>
>>> It looks like xapian-core is not honoring the COMPILER= ports-gcc
>>> flag.
>>
>> That is working here, did you have an old package lying around etc?:
>
> Sort of. I figured it out. I recompiled xapian-core without adding a
> revision. Which then has installed the cached package.
>
> It worked now.
>
>> No maildirs here for full tests with mu, but "make test" has lots of "OK"s..
>
> That, and I did some manual tests on my 200k email-mailbox.
>
> Updated patch below.
>
> Best Regards,
> Stefan
>
Thanks Stefan and Stuart for revising the patch!
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/mu/Makefile,v
> retrieving revision 1.18
> diff -u -p -u -p -r1.18 Makefile
> --- Makefile21 Jul 2019 00:10:04 - 1.18
> +++ Makefile22 Jan 2020 20:13:28 -
> @@ -3,6 +3,7 @@
> COMMENT= maildir indexer and searcher with emacs frontend
>
> DISTNAME= mu-1.2.0
> +REVISION= 1
>
> CATEGORIES=mail
> HOMEPAGE= http://www.djcbsoftware.nl/code/mu/
> @@ -13,9 +14,9 @@ MAINTAINER= Stefan Hagen PERMIT_PACKAGE=Yes
>
> WANTLIB+= assuan c ffi gio-2.0 glib-2.0 gmime-3.0 gmodule-2.0
> -WANTLIB+= gobject-2.0 gpg-error gpgme gthread-2.0 iconv
> +WANTLIB+= gobject-2.0 gpg-error gpgme gthread-2.0 iconv idn2
> WANTLIB+= intl json-glib-1.0 m pcre pthread ${COMPILER_LIBCXX}
> -WANTLIB+= uuid xapian z
> +WANTLIB+= unistring uuid xapian z
>
> MASTER_SITES= https://github.com/djcb/mu/releases/download/1.2/
> EXTRACT_SUFX= .tar.xz
> @@ -30,7 +31,7 @@ LIB_DEPENDS= databases/xapian-core \
>
>
> # C++14 required
> -COMPILER= base-clang ports-clang
> +COMPILER= base-clang ports-gcc
>
> AUTOCONF_VERSION= 2.69
> AUTOMAKE_VERSION= 1.15
signature.asc
Description: PGP signature
Re: rc script for net/iperf3 daemon
On Wed, Jan 22, 2020 at 09:39:16PM +0100, Alexander Bluhm wrote:
> For my performance tests it would be convenient to start an iperf3
> server as daemon automatically. Can we add an rc script?
Seems reasonable.
> Index: net/iperf3/pkg/iperf3.rc
> ===
> RCS file: net/iperf3/pkg/iperf3.rc
> diff -N net/iperf3/pkg/iperf3.rc
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ net/iperf3/pkg/iperf3.rc 22 Jan 2020 20:18:43 -
> @@ -0,0 +1,12 @@
> +#!/bin/ksh
> +#
> +# $OpenBSD$
> +
> +daemon="${TRUEPREFIX}/bin/iperf3"
> +daemon_flags="-s -D"
I think at least `-D' should be part of `$daemon', otherwise setting
flags only causes trouble.
One might argue that `-s' for server mode belongs there as well, no?
Or to put it this way: does it make sense to specify `-c' for client
in flags? Would one want to run a client service as well perhaps?
> +daemon_user="_iperf3"
> +rc_reload=NO
> +
> +. /etc/rc.d/rc.subr
> +
> +rc_cmd $1
>
rc script for net/iperf3 daemon
Hi,
For my performance tests it would be convenient to start an iperf3
server as daemon automatically. Can we add an rc script?
ok?
bluhm
Index: infrastructure/db/user.list
===
RCS file: /data/mirror/openbsd/cvs/ports/infrastructure/db/user.list,v
retrieving revision 1.357
diff -u -p -r1.357 user.list
--- infrastructure/db/user.list 29 Nov 2019 02:42:44 - 1.357
+++ infrastructure/db/user.list 22 Jan 2020 20:31:48 -
@@ -354,3 +354,4 @@ id usergroup port
844 _routinator_routinator net/routinator
845 _snmpexporter _snmpexporter sysutils/snmp_exporter
846 _dhcpcd_dhcpcd net/dhcpcd
+847 _iperf3_iperf3 net/iperf3
Index: net/iperf3/Makefile
===
RCS file: /data/mirror/openbsd/cvs/ports/net/iperf3/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- net/iperf3/Makefile 28 Jun 2019 07:25:37 - 1.4
+++ net/iperf3/Makefile 22 Jan 2020 12:03:57 -
@@ -3,6 +3,7 @@
COMMENT= tool to measure maximum achievable bandwidth on IP networks
V= 3.7
+REVISION= 0
PKGNAME= iperf3-${V}
DISTNAME= iperf-${V}
Index: net/iperf3/pkg/PLIST
===
RCS file: /data/mirror/openbsd/cvs/ports/net/iperf3/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- net/iperf3/pkg/PLIST21 Sep 2016 01:12:57 - 1.1.1.1
+++ net/iperf3/pkg/PLIST22 Jan 2020 20:32:36 -
@@ -1,7 +1,10 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2016/09/21 01:12:57 lteo Exp $
+@newgroup _iperf3:847
+@newuser _iperf3:847:_iperf3:daemon:iperf3 server:/nonexistent:/sbin/nologin
+@rcscript ${RCDIR}/iperf3
@bin bin/iperf3
include/iperf_api.h
-lib/libiperf.a
+@static-lib lib/libiperf.a
lib/libiperf.la
@lib lib/libiperf.so.${LIBiperf_VERSION}
@man man/man1/iperf3.1
Index: net/iperf3/pkg/iperf3.rc
===
RCS file: net/iperf3/pkg/iperf3.rc
diff -N net/iperf3/pkg/iperf3.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/iperf3/pkg/iperf3.rc22 Jan 2020 20:18:43 -
@@ -0,0 +1,12 @@
+#!/bin/ksh
+#
+# $OpenBSD$
+
+daemon="${TRUEPREFIX}/bin/iperf3"
+daemon_flags="-s -D"
+daemon_user="_iperf3"
+rc_reload=NO
+
+. /etc/rc.d/rc.subr
+
+rc_cmd $1
Re: mu: use ports-gcc
Stuart Henderson wrote: > On 2020/01/22 18:25, Stefan Hagen wrote: >> Stuart Henderson wrote: >>> On 2020/01/21 18:22, Xiyue Deng wrote: # C++14 required -COMPILER= base-clang ports-clang +COMPILER= base-clang ports-gcc >>> >>> This part is ok with me with the bump added. >> >> Experiement below: >> >> I don't have a gcc architecture available, so i tried to compile mail/mu >> und its dependency database/xapian-core with COMPILER= ports-gcc set on >> my amd64 box. >> >> It looks like xapian-core is not honoring the COMPILER= ports-gcc >> flag. > > That is working here, did you have an old package lying around etc?: Sort of. I figured it out. I recompiled xapian-core without adding a revision. Which then has installed the cached package. It worked now. > No maildirs here for full tests with mu, but "make test" has lots of "OK"s.. That, and I did some manual tests on my 200k email-mailbox. Updated patch below. Best Regards, Stefan Index: Makefile === RCS file: /cvs/ports/mail/mu/Makefile,v retrieving revision 1.18 diff -u -p -u -p -r1.18 Makefile --- Makefile21 Jul 2019 00:10:04 - 1.18 +++ Makefile22 Jan 2020 20:13:28 - @@ -3,6 +3,7 @@ COMMENT= maildir indexer and searcher with emacs frontend DISTNAME= mu-1.2.0 +REVISION= 1 CATEGORIES=mail HOMEPAGE= http://www.djcbsoftware.nl/code/mu/ @@ -13,9 +14,9 @@ MAINTAINER= Stefan Hagen https://github.com/djcb/mu/releases/download/1.2/ EXTRACT_SUFX= .tar.xz @@ -30,7 +31,7 @@ LIB_DEPENDS= databases/xapian-core \ # C++14 required -COMPILER= base-clang ports-clang +COMPILER= base-clang ports-gcc AUTOCONF_VERSION= 2.69 AUTOMAKE_VERSION= 1.15
Issues with manuals+amd(8) for a handful of ports
Hi,
I mount my /usr/local directory from a remote server over NFS
using amd(8). This means that I have the directories directly
beneath /usr/local appear on demand as symbolic links into
/tmp_mnt/eeyore/vol/local/pooh where the /usr/local for the local
machine "pooh" is mounted over NFS from "eeyore" (and mounted/unmounted
on demand).
This works very well, but there is a handful of ports that misbehave
with regards to manuals. Of the 70 or so pre-built packages that I've
installed on my amd64-current system, the only ones misbehaving are
databases/pkglocatedb (pkglocatedb-1.5)
devel/git,-main (git-2.25.0)
sysutils/p5-File-Rename-1.10(p5-File-Rename-1.10)
When I do "man pkglocate", for example, I get
man: /tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1:
SYSERR: open: No such file or directory
... and likewise for any other utility etc. from those ports. Commands
like "git clone --help" gives similar diagnostics.
The manuals are actually visible where they are supposed to be:
$ ls -l /usr/local/man/man1/{git{,-clone},pkg_locate}.1
-rw-r--r-- 1 root bin 20005 Jan 20 22:20 /usr/local/man/man1/git-clone.1
-rw-r--r-- 1 root bin 50901 Jan 13 19:49 /usr/local/man/man1/git.1
-rw-r--r-- 1 root bin 2845 Jan 19 08:14 /usr/local/man/man1/pkg_locate.1
... so it looks as if man(1) is, for whatever reason, looking in the
wrong location for the file.
Manuals for other utilities, like rsync, pv, pwgen, openvpn, etc., do
work as they should.
I haven't created or changed any MAN* environment variables nor do I
have a /etc/man.conf file. I haven't been able to figure out what's
special about the manuals for these ports.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: [NEW] sysutils/ssh-copy-id
On 2020/01/18 23:20, Jan-Piet Mens wrote: > > p1 can't be used in PKGNAME as it conflicts with REVISION, usual > > practice is to replace p with pl, e.g. > > Fixed, thank you. > > New port attached. > >-JP This version is OK sthen@ to import.
Re: mu: use ports-gcc
On 2020/01/22 18:25, Stefan Hagen wrote: > Stuart Henderson wrote: > > On 2020/01/21 18:22, Xiyue Deng wrote: > > > # C++14 required > > > -COMPILER=base-clang ports-clang > > > +COMPILER=base-clang ports-gcc > > > > This part is ok with me with the bump added. > > Experiement below: > > I don't have a gcc architecture available, so i tried to compile mail/mu > und its dependency database/xapian-core with COMPILER= ports-gcc set on > my amd64 box. > > It looks like xapian-core is not honoring the COMPILER= ports-gcc > flag. That is working here, did you have an old package lying around etc?: $ objdump -p /pobj/xapian-core-1.4.14/fake-amd64/usr/local/lib/libxapian.so.5.1 | grep NEEDED NEEDED libz.so.5.0 NEEDED libuuid.so.14.0 NEEDED libestdc++.so.19.0 NEEDED libm.so.10.1 > Afterwards compiling and installing xapian-core, mail/mu still > complains about an incompatible ABI: > > ld: error: undefined symbol: > Xapian::Document::get_value[abi:cxx11](unsigned int) const No maildirs here for full tests with mu, but "make test" has lots of "OK"s.. > # nm --demangle: > mu-1.2.0/lib/tests/.libs/libxapian.so.5.1 > => _ZNK6Xapian8Document9get_valueEj > mu-1.2.0/lib/tests/.libs/libtestmucommon.a > => _ZNK6Xapian8Document9get_valueB5cxx11Ej > > I'm interested to find out why this is happening... > > Can this behavior break on other archs? > > Best Regards, > Stefan >
Re: UPDATE: textproc/gsed 4.2.2 => 4.8
Hi!
On Wed, 22 Jan 2020 10:41:46 -0500
Brian Callahan wrote:
> Hi ports --
>
> Attached is an update to GNU sed. The version we have is >7 years old.
>
> Some notes:
> * Tarball is now an xz not a bz2
> * The existing patches go away
> * A new patch is added. Our makeinfo is too old to regen the info
> file, but the info file is already there, so avoid needlessly
> regenerating it, which we can't do anyway.
> * Added debug packages because it's an easy addition. But am fine if
> it's not desirable.
>
> Tested on amd64, arm64, and mips64. One test fails,
> test-vc-list-files-cvs.sh, but it's not a sed test, it's a gnulib
> test. Not sure how much it matters. The test fails with:
> cvs [checkout aborted]: can't chdir(/gsed-4.8_writes_to_HOME): No
> such file or directory
> cvs [checkout aborted]: can't chdir(/gsed-4.8_writes_to_HOME): No
> such file or directory
> FAIL test-vc-list-files-cvs.sh (exit status: 1)
It can be circumvented with:
PORTHOME = ${WRKDIR}
> I then built everything that depends on gsed. Everything built OK.
>
> OK?
It builds and works fine on powerpc as well. OK cwen@ with or without
the PORTHOME addition.
> ~Brian
>
Re: devel/openmpi mpifort error; compiler
Hi Stuart, On 2020-01-22 09:31, Stuart Henderson wrote: On 2020/01/22 09:24, j...@bitminer.ca wrote: The mixing of gcc-built code with clang "runtime" is not really such a big deal on AMD64. I know very little about openmpi but it looks like you're intending this as a general statement. For C code it's not a problem. For C++ code it's a big problem because the standard libraries conflict. True -- I should have qualified the sentence "when using C and often when using C++". OpenMPI provides a C library, not C++. So any[*] C++ source code can be built with OpenMPI, with either compiler, provided any other prerequisites are also available. OpenMPI people deprecated their C++ interface long ago. Much of this info exceeds the typical scope of documentation; I have some web pages in progress that I hope to publish soon (once I figure out github pages). Perhaps the OpenMPI port needs an OpenBSD-specific set of guidelines (e.g. useful runtime environment variables, compiling guidance, etc). [*] In principle, although I haven't tried many.
Re: mu: use ports-gcc
Stuart Henderson wrote: > On 2020/01/21 18:22, Xiyue Deng wrote: > > # C++14 required > > -COMPILER= base-clang ports-clang > > +COMPILER= base-clang ports-gcc > > This part is ok with me with the bump added. Experiement below: I don't have a gcc architecture available, so i tried to compile mail/mu und its dependency database/xapian-core with COMPILER= ports-gcc set on my amd64 box. It looks like xapian-core is not honoring the COMPILER= ports-gcc flag. Afterwards compiling and installing xapian-core, mail/mu still complains about an incompatible ABI: ld: error: undefined symbol: Xapian::Document::get_value[abi:cxx11](unsigned int) const # nm --demangle: mu-1.2.0/lib/tests/.libs/libxapian.so.5.1 => _ZNK6Xapian8Document9get_valueEj mu-1.2.0/lib/tests/.libs/libtestmucommon.a => _ZNK6Xapian8Document9get_valueB5cxx11Ej I'm interested to find out why this is happening... Can this behavior break on other archs? Best Regards, Stefan
Re: mu: use ports-gcc
Xiyue Deng wrote:
> Xiyue Deng writes:
> > Currently mu requires ports-clang which I think is because there was a
> > time that GCC 4.9 didn't support C++14. Now that GCC is on 8.3, mu can
> > be unblocked for GCC archs as well. I didn't change patch level as I
> > think there is no visible change, but correct me if I'm wrong.
> >
> > Tested on mips64el/loongson.
Yes, this makes sense. I'm ok with this patch.
Best Regards,
Stefan
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/mail/mu/Makefile,v
> > retrieving revision 1.18
> > diff -u -p -r1.18 Makefile
> > --- Makefile21 Jul 2019 00:10:04 - 1.18
> > +++ Makefile22 Jan 2020 02:16:59 -
> > @@ -14,7 +14,7 @@ PERMIT_PACKAGE= Yes
> >
> > WANTLIB+= assuan c ffi gio-2.0 glib-2.0 gmime-3.0 gmodule-2.0
> > WANTLIB+= gobject-2.0 gpg-error gpgme gthread-2.0 iconv
> > -WANTLIB+= intl json-glib-1.0 m pcre pthread ${COMPILER_LIBCXX}
> > +WANTLIB+= intl json-glib-1.0 m pcre pthread
> > WANTLIB+= uuid xapian z
> >
> > MASTER_SITES= https://github.com/djcb/mu/releases/download/1.2/
> > @@ -30,7 +30,7 @@ LIB_DEPENDS= databases/xapian-core \
> >
> >
> > # C++14 required
> > -COMPILER= base-clang ports-clang
> > +COMPILER= base-clang ports-gcc
> >
> > AUTOCONF_VERSION= 2.69
> > AUTOMAKE_VERSION= 1.15
Re: update: devel/py-country
On Wed, 22 Jan 2020, Kurt Mosiejczuk wrote: > > WRKOBJDIR=/home/paco/ports/obj > > DISTDIR=/home/paco/ports/distfiles > > PACKAGE_REPOSITORY=/home/paco/ports/packages > > All three of those lines should be able to be replaced with > > PORTSDIR=/home/paco/ports > > I suppose its possible since you aren't setting that that there is another > DIR variable derived from PORTSDIR that isn't getting set and confusing > update-plist What I should do is reinstall this machine with a better suited partition schema and start fresh. I've been delaying it for too long. Maybe this weekend. Thank you both for your help. -- Paco Esteban. 5818130B8A6DBC03
Re: devel/openmpi mpifort error; compiler
On 2020/01/22 09:24, j...@bitminer.ca wrote: > The mixing of gcc-built code with clang "runtime" is not really > such a big deal on AMD64. I know very little about openmpi but it looks like you're intending this as a general statement. For C code it's not a problem. For C++ code it's a big problem because the standard libraries conflict.
Re: devel/openmpi mpifort error; compiler
Hi Martin, On 2020-01-22 03:07, Martin Reindl wrote: On Tue, Jan 21, 2020 at 01:20:29PM -0700, j...@bitminer.ca wrote: On 2020-01-21 12:45, Martin Reindl wrote: > Am 20.01.20 um 22:55 schrieb j...@bitminer.ca: > > This fixes the mpifort command which can't find egfortran. > > > > I also propose removing COMPILER = base-clang since this compiles > > with gcc anyway. GCC also has some advantages for us fortran > > users (coarray fortran). > > Hello John, > > - OK for the CONFIGURE_ARGS fortran bits, thanks for spotting! > - REVISION should start at 0 Ahh, the perils of porting infrequently. Good point. > - egfortran actually is the one from ports-gcc (8.3.0), I don't see the > point replacing base clang 8.0.1 if you need coarray fortran? On AMD64, OpenMPI compiles with ports-gcc anyway, hence my notion to avoid confusion by naming the one compiler: ===> Checking files for openmpi-4.0.2p1 `/usr/distfiles/openmpi-4.0.2.tar.gz' is up to date. > > (SHA256) openmpi-4.0.2.tar.gz: OK ===> openmpi-4.0.2p1 depends on: libltdl-* -> libltdl-2.4.2p1 ===> openmpi-4.0.2p1 depends on: gcc->=8,<9 -> gcc-8.3.0p4 etc etc Once built (using ports-gcc egcc and egfortran), then OpenMPI is compatible with clang but not flang because the two Fortrans have different array implementations (max rank=15 on egfortran versus merely 8 or 9 on flang, and OpenMPI notices.) The GCC gfortran compiler supports co-arrays but flang does not, to my knowledge. The coarrays lib is a very simple port that I should post. Hi John, Hi Stuart, I've got around to testing this now a bit more: - Currently, the port does not use flang. It used to before the update to openmpi-4.0.1. So every Fortran feature in the current state depends solely on gcc8 from ports-gcc - Strictly speaking the COMPILER line is there for archs where there is no clang in base and base-gcc is too old. This gives archs like macppc and sparc64 a chance to compile and run openmpi - with MODULES=fortran on a base-clang archs we now have the situation that we build the openmpi binaries and librariers with ports-gcc but at runtime we use base-clang: (I think you mean at compile-time). $ mpicc -v OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1) Actually, compiling with clang is optional: $ mpicc -v OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1) [...] $ OMPI_CC=egcc mpicc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/egcc [...] etc The mixing of gcc-built code with clang "runtime" is not really such a big deal on AMD64. The whole operating system is built with clang. Clang-compiled OpenMPI user code runs fine with the gcc-built OpenMPI. It's just flang-compiled OpenMPI user code that doesn't work and I personally think the gfortran alternative is better, as stated. --John for Fortran with Johns diff it's ports-gcc as usual: $ mpifort -v [...] gcc version 8.3.0 (GCC) We could use ports-gcc only but I am not sure what produces a more coherent system on a base-clang arch where openmpi seems to be most likely to be useful (meaning amd64 and arm64, mostly). A possibility would be to split up the port: a base-clang only version: - Fortran disabled - coherent on all base-clang archs a ports-gcc version: - Fortran enabled - also available where there is no base-clang - possibly less coherent because mixing of libraries (as Stuart pointed) out For a small userbase, this is probably too much work (and too difficult to answer questions about "which should I use?"). For now I would keep base-clang, but given the small userbase it might be worth to really just keep a ports-gcc version. I've tested the folling diff and checked the libraries for changes with the help of shared_libs.log. libopen-pal only has adress changes and libopen-rte as a tiny symbol name changed - hence the minor bump. I've also fixed the orig version in the comments for the other libraries and sprinkled some @lib markers in the PLIST while there. -m cheers --John PS - question: has anyone ever tried to vet the lengthy list of shared libs and tried to prune it? Seems like a few might still be unnecessary on OpenBSD.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/22 09:11:55 Modified files: net/isc-dhcp : Makefile distinfo net/isc-dhcp/patches: patch-bind_Makefile_in patch-client_Makefile_in net/isc-dhcp/pkg: PLIST-main PLIST-omapi Added files: net/isc-dhcp/patches: patch-keama_confparse_c patch-keama_data_c patch-keama_eval_c patch-keama_keama_c patch-keama_keama_h Removed files: net/isc-dhcp/patches: patch-common_socket_c Log message: update to isc-dhcp-4.4.2 and build the new "keama" tool (Kea migration assistant)
Re: update: devel/py-country
On 2020/01/22 14:47, Paco Esteban wrote: > On Wed, 22 Jan 2020, Stuart Henderson wrote: > > > Do you have any local changes in mk.conf or diffs in python ports > > infrastructure (python.port.mk etc)? Running "make plist" here doesn't add > > those lines. > > This is my mk.conf (I have some things in /home because I built > this machine before going into the porting party. I know, I should > reinstall): > > WRKOBJDIR=/home/paco/ports/obj > DISTDIR=/home/paco/ports/distfiles > PACKAGE_REPOSITORY=/home/paco/ports/packages > SUDO=/usr/bin/doas > FETCH_PACKAGES= > PORTS_PRIVSEP=Yes > > I don't have any diff on /usr/ports/infrastructure or > /usr/ports/lang/python > > Cheers, > > -- > Paco Esteban. > 5818130B8A6DBC03 > Hmm, maybe something doas-related, are you allowing it to pass environment variables through (keepenv)? I don't think it's anything to do with WRKOBJDIR, DISTDIR, PACKAGE_REPOSITORY, those are used widely and don't cause it for me.
Re: [macppc, all archs] devel/physfs: fix endianness detection
[...] > The problem actually is that physfs' internal endianness detection is > too basic to work. It was missing `__powerpc__', so i used , > as seen in the already existing lzma patch. > > That diff has been tested successfully in a partial bulk against > consumers on amd64 [2], and macppc. According to check_sym, there is > no dynamic changes. [...] Hi, works on my amd64 with barony and hedgewars (lightly tested); no regression noticed. I don't have a big-endian to test on. ok thfr@ and thanks! looking forward to games/vv! -- tfrohw...@fastmail.com PGP Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22
UPDATE: textproc/gsed 4.2.2 => 4.8
Hi ports --
Attached is an update to GNU sed. The version we have is >7 years old.
Some notes:
* Tarball is now an xz not a bz2
* The existing patches go away
* A new patch is added. Our makeinfo is too old to regen the info file,
but the info file is already there, so avoid needlessly regenerating it,
which we can't do anyway.
* Added debug packages because it's an easy addition. But am fine if
it's not desirable.
Tested on amd64, arm64, and mips64. One test fails,
test-vc-list-files-cvs.sh, but it's not a sed test, it's a gnulib test.
Not sure how much it matters. The test fails with:
cvs [checkout aborted]: can't chdir(/gsed-4.8_writes_to_HOME): No such
file or directory
cvs [checkout aborted]: can't chdir(/gsed-4.8_writes_to_HOME): No such
file or directory
FAIL test-vc-list-files-cvs.sh (exit status: 1)
I then built everything that depends on gsed. Everything built OK.
OK?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/textproc/gsed/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile 16 Jul 2019 21:29:41 - 1.12
+++ Makefile 22 Jan 2020 15:23:01 -
@@ -2,12 +2,11 @@
COMMENT= GNU stream editor
-DISTNAME= sed-4.2.2
+DISTNAME= sed-4.8
PKGNAME= g${DISTNAME}
-REVISION= 3
CATEGORIES= textproc
MASTER_SITES= ${MASTER_SITE_GNU:=sed/}
-EXTRACT_SUFX= .tar.bz2
+EXTRACT_SUFX= .tar.xz
HOMEPAGE= https://www.gnu.org/software/sed/
@@ -17,6 +16,8 @@ MAINTAINER= Armin Wolfermann cur_idx += (idx))
- #define re_string_set_index(pstr,idx) ((pstr)->cur_idx = (idx))
-
--#include
-
- #ifndef _LIBC
- # if HAVE_ALLOCA
Index: pkg/PLIST
===
RCS file: /cvs/ports/textproc/gsed/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 25 Dec 2012 01:29:54 - 1.3
+++ pkg/PLIST 22 Jan 2020 15:23:01 -
@@ -5,9 +5,8 @@
share/locale/af/
share/locale/af/LC_MESSAGES/
share/locale/af/LC_MESSAGES/sed.mo
-share/locale/ast/
-share/locale/ast/LC_MESSAGES/
share/locale/ast/LC_MESSAGES/sed.mo
+share/locale/bg/LC_MESSAGES/sed.mo
share/locale/ca/LC_MESSAGES/sed.mo
share/locale/cs/LC_MESSAGES/sed.mo
share/locale/da/LC_MESSAGES/sed.mo
Re: update: devel/py-country
On Wed, Jan 22, 2020 at 02:47:15PM +0100, Paco Esteban wrote: > On Wed, 22 Jan 2020, Stuart Henderson wrote: > > Do you have any local changes in mk.conf or diffs in python ports > > infrastructure (python.port.mk etc)? Running "make plist" here doesn't add > > those lines. > This is my mk.conf (I have some things in /home because I built > this machine before going into the porting party. I know, I should > reinstall): > WRKOBJDIR=/home/paco/ports/obj > DISTDIR=/home/paco/ports/distfiles > PACKAGE_REPOSITORY=/home/paco/ports/packages All three of those lines should be able to be replaced with PORTSDIR=/home/paco/ports I suppose its possible since you aren't setting that that there is another DIR variable derived from PORTSDIR that isn't getting set and confusing update-plist > SUDO=/usr/bin/doas > FETCH_PACKAGES= > PORTS_PRIVSEP=Yes > I don't have any diff on /usr/ports/infrastructure or > /usr/ports/lang/python Try that change and see if it stops adding those lines. --Kurt
UPDATE audio/audacious
Diff below updates audacious to 3.10.1. Changes between 3.9 and 3.10 are
explained at [0]. 3.10.1 fixes some additional bugs. Note that this
update relies on a newer version of audacious-plugins, which has been
send to ports@.
Changes to the port:
- Switch HOMEPAGE and MASTER_SITES to https
- Sync WANTLIB
- Bump major of libaudcore as symbols have been removed
Lightly tested on amd64.
Comments/OK?
[0] https://audacious-media-player.org/news/43-audacious-3-10-released
diff --git Makefile Makefile
index cc130f2b4fb..42b1adf225a 100644
--- Makefile
+++ Makefile
@@ -5,16 +5,15 @@ BROKEN-alpha =tinylock.c:58: internal compiler error:
in extract_insn, at recog
COMMENT = graphical audio player which supports lots of formats
-DISTNAME = audacious-3.9
-REVISION = 2
+DISTNAME = audacious-3.10.1
-SHARED_LIBS += audcore 4.0 # 5.0
+SHARED_LIBS += audcore 5.0 # 5.1
SHARED_LIBS += audgui 4.0 # 5.0
SHARED_LIBS += audtag 3.0 # 3.0
CATEGORIES = audio multimedia
-HOMEPAGE = http://audacious-media-player.org/
+HOMEPAGE = https://audacious-media-player.org/
# BSD
PERMIT_PACKAGE = Yes
@@ -22,10 +21,10 @@ PERMIT_PACKAGE =Yes
WANTLIB += ${COMPILER_LIBCXX} X11 Xcomposite Xcursor Xdamage Xext
WANTLIB += Xfixes Xi Xinerama Xrandr Xrender atk-1.0 c cairo fontconfig
WANTLIB += freetype gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0
-WANTLIB += gmodule-2.0 gobject-2.0 gtk-x11-2.0 iconv intl m pango-1.0
-WANTLIB += pangocairo-1.0 pangoft2-1.0 z
+WANTLIB += gmodule-2.0 gobject-2.0 gtk-x11-2.0 harfbuzz iconv
+WANTLIB += intl m pango-1.0 pangocairo-1.0 pangoft2-1.0 z
-MASTER_SITES = http://distfiles.audacious-media-player.org/
+MASTER_SITES = https://distfiles.audacious-media-player.org/
EXTRACT_SUFX = .tar.bz2
diff --git distinfo distinfo
index 7dfae153553..65a2003c36a 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (audacious-3.9.tar.bz2) = LYBEZzrHhtcbCABPGQu8o2gli/YOZgL/wNliKDXMsF4=
-SIZE (audacious-3.9.tar.bz2) = 599488
+SHA256 (audacious-3.10.1.tar.bz2) =
g2boQLs8lEjCzwz5oIABVbC9fMISooukSZDD0iica5M=
+SIZE (audacious-3.10.1.tar.bz2) = 564481
diff --git patches/patch-buildsys_mk_in patches/patch-buildsys_mk_in
index a94f8f206f4..2a349cb9230 100644
--- patches/patch-buildsys_mk_in
+++ patches/patch-buildsys_mk_in
@@ -1,12 +1,13 @@
$OpenBSD: patch-buildsys_mk_in,v 1.7 2014/11/03 04:28:11 bcallah Exp $
buildsys.mk.in.origThu Oct 16 20:00:28 2014
-+++ buildsys.mk.in Sat Nov 1 19:11:40 2014
-@@ -107,7 +107,7 @@ PLUGIN_OBJS = ${OBJS:.o=.plugin.o}
+Index: buildsys.mk.in
+--- buildsys.mk.in.orig
buildsys.mk.in
+@@ -113,7 +113,7 @@ PLUGIN_OBJS = ${OBJS:.o=.plugin.o}
MO_FILES = ${LOCALES:.po=.mo}
-.SILENT:
+#.SILENT:
.SUFFIXES:
- .SUFFIXES: .beam .c .c.dep .cc .cc.dep .class .cxx .cxx.dep .d .erl .lib.o
.java .mo .m .m.dep .mm .mm.dep .o .plugin.o .po .py .pyc .rc .S .S.dep .xpm
- .PHONY: all subdirs pre-depend depend install install-extra uninstall
uninstall-extra clean distclean locales ${SUBDIRS}
+ .SUFFIXES: .beam .c .c.dep .cc .cc.dep .class .cxx .cxx.dep .d .erl .lib.o
.java .mo .m .m.dep .mm .mm.dep .moslib.o .o .plugin.o .po .py .pyc .rc .S
.S.dep .xpm
+ .PHONY: all subdirs subdirs-after pre-depend depend install install-includes
install-extra uninstall uninstall-extra clean distclean locales ${SUBDIRS}
${SUBDIRS_AFTER}
diff --git patches/patch-src_libaudcore_Makefile
patches/patch-src_libaudcore_Makefile
index d0c0dbb7e45..ebe69ad1409 100644
--- patches/patch-src_libaudcore_Makefile
+++ patches/patch-src_libaudcore_Makefile
@@ -6,5 +6,5 @@ Index: src/libaudcore/Makefile
-SHARED_LIB = ${LIB_PREFIX}audcore${LIB_SUFFIX}
+SHARED_LIB = ${LIB_PREFIX}audcore.so.${LIBaudcore_VERSION}
LIB_MAJOR = 5
- LIB_MINOR = 0
+ LIB_MINOR = 1
diff --git pkg/PLIST pkg/PLIST
index cba79e04c41..e1ea6e88af0 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -46,20 +46,9 @@ share/applications/audacious.desktop
share/audacious/
share/audacious/AUTHORS
share/audacious/COPYING
-share/audacious/images/
-share/audacious/images/about-logo.png
-share/audacious/images/about-logo.svg
-share/audacious/images/album.png
-share/audacious/images/appearance.png
-share/audacious/images/audio.png
-share/audacious/images/connectivity.png
-share/audacious/images/info.png
-share/audacious/images/playlist.png
-share/audacious/images/plugins.png
share/icons/hicolor/48x48/apps/audacious.png
share/icons/hicolor/scalable/apps/audacious.svg
share/locale/ar/LC_MESSAGES/audacious.mo
-share/locale/ast/LC_MESSAGES/audacious.mo
share/locale/be/LC_MESSAGES/audacious.mo
share/locale/bg/LC_MESSAGES/audacious.mo
share/locale/ca/LC_MESSAGES/audacious.mo
@@ -71,7 +60,6 @@ share/locale/da/LC_MESSAGES/audacious.mo
share/locale/de/LC_MESSAGES/audacious.mo
share/locale/el/LC_MESSAGES/audacious.mo
UPDATE audio/audacious-plugins
Diff below brings audacious-plugins to 3.10.1. This update is needed for
bringing audio/audacious up to date. A diff for the latter has been send
to ports@.
Changes to the port:
- Sync WANTLIB
- Switch MASTER_SITES to https
Lightly run tested on amd64.
Comments/OK?
diff --git Makefile Makefile
index 1501a02b0b0..3d99084988d 100644
--- Makefile
+++ Makefile
@@ -2,9 +2,8 @@
COMMENT = input and output plugins for Audacious
-V =3.9
+V =3.10.1
DISTNAME = audacious-plugins-$V
-REVISION = 3
CATEGORIES = audio multimedia
@@ -18,12 +17,12 @@ WANTLIB += Xext Xfixes Xi Xinerama Xrandr Xrender atk-1.0
audgui
WANTLIB += audtag avcodec avformat avutil c cairo cddb cdio cdio_cdda
WANTLIB += cue curl dbus-1 dbus-glib-1 faad fontconfig freetype
WANTLIB += gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0
-WANTLIB += gobject-2.0 gtk-x11-2.0 iconv intl m mms modplug mp3lame
+WANTLIB += gobject-2.0 gtk-x11-2.0 harfbuzz iconv intl m mms modplug mp3lame
WANTLIB += mpg123 neon notify ogg pango-1.0 pangocairo-1.0 pangoft2-1.0
WANTLIB += samplerate sndfile sndio soxr vorbis vorbisenc vorbisfile
WANTLIB += wavpack xml2 z
-MASTER_SITES = http://distfiles.audacious-media-player.org/
+MASTER_SITES = https://distfiles.audacious-media-player.org/
EXTRACT_SUFX = .tar.bz2
diff --git distinfo distinfo
index f261a81d563..b4a3f1061c9 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (audacious-plugins-3.9.tar.bz2) =
i/fyEInLNAaWjMnHEwd3Su5xAOxGB/KPY89WkNXJJ7g=
-SIZE (audacious-plugins-3.9.tar.bz2) = 1843084
+SHA256 (audacious-plugins-3.10.1.tar.bz2) =
7sMXdjH5lym/DpQiO2J0BsxkjHDmZG41YTx7VQQKJkI=
+SIZE (audacious-plugins-3.10.1.tar.bz2) = 1715477
diff --git patches/patch-buildsys_mk_in patches/patch-buildsys_mk_in
index 0b32ca27e8b..59f544b9292 100644
--- patches/patch-buildsys_mk_in
+++ patches/patch-buildsys_mk_in
@@ -1,12 +1,13 @@
$OpenBSD: patch-buildsys_mk_in,v 1.6 2014/11/03 04:29:05 bcallah Exp $
buildsys.mk.in.origThu Oct 16 20:01:19 2014
-+++ buildsys.mk.in Sat Nov 1 19:44:28 2014
-@@ -107,7 +107,7 @@ PLUGIN_OBJS = ${OBJS:.o=.plugin.o}
+Index: buildsys.mk.in
+--- buildsys.mk.in.orig
buildsys.mk.in
+@@ -113,7 +113,7 @@ PLUGIN_OBJS = ${OBJS:.o=.plugin.o}
MO_FILES = ${LOCALES:.po=.mo}
-.SILENT:
+#.SILENT:
.SUFFIXES:
- .SUFFIXES: .beam .c .c.dep .cc .cc.dep .class .cxx .cxx.dep .d .erl .lib.o
.java .mo .m .m.dep .mm .mm.dep .o .plugin.o .po .py .pyc .rc .S .S.dep .xpm
- .PHONY: all subdirs pre-depend depend install install-extra uninstall
uninstall-extra clean distclean locales ${SUBDIRS}
+ .SUFFIXES: .beam .c .c.dep .cc .cc.dep .class .cxx .cxx.dep .d .erl .lib.o
.java .mo .m .m.dep .mm .mm.dep .moslib.o .o .plugin.o .po .py .pyc .rc .S
.S.dep .xpm
+ .PHONY: all subdirs subdirs-after pre-depend depend install install-includes
install-extra uninstall uninstall-extra clean distclean locales ${SUBDIRS}
${SUBDIRS_AFTER}
diff --git patches/patch-configure patches/patch-configure
index 051879f438f..f66a9125a79 100644
--- patches/patch-configure
+++ patches/patch-configure
@@ -7,7 +7,7 @@ polluted very early on, breaking most of the checks using
AC_CHECK_LIB.
Index: configure
--- configure.orig
+++ configure
-@@ -9675,8 +9675,6 @@ $as_echo "yes" >&6; }
+@@ -9702,8 +9702,6 @@ $as_echo "yes" >&6; }
fi
@@ -16,7 +16,7 @@ Index: configure
if test $HAVE_DARWIN = yes ; then
-@@ -14657,6 +14655,8 @@ as_fn_error ()
+@@ -14701,6 +14699,8 @@ as_fn_error ()
as_fn_exit $as_status
} # as_fn_error
diff --git pkg/PLIST pkg/PLIST
index f25ab5d6cae..021807726dc 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -2,72 +2,70 @@
@pkgpath audio/audacious-plugins,-main
lib/audacious/
lib/audacious/Container/
-lib/audacious/Container/asx.so
-lib/audacious/Container/asx3.so
-lib/audacious/Container/audpl.so
-lib/audacious/Container/cue.so
-lib/audacious/Container/m3u.so
-lib/audacious/Container/pls.so
-lib/audacious/Container/xspf.so
+@so lib/audacious/Container/asx.so
+@so lib/audacious/Container/asx3.so
+@so lib/audacious/Container/audpl.so
+@so lib/audacious/Container/cue.so
+@so lib/audacious/Container/m3u.so
+@so lib/audacious/Container/pls.so
+@so lib/audacious/Container/xspf.so
lib/audacious/Effect/
-lib/audacious/Effect/compressor.so
-lib/audacious/Effect/crossfade.so
-lib/audacious/Effect/crystalizer.so
-lib/audacious/Effect/echo.so
-lib/audacious/Effect/ladspa.so
-lib/audacious/Effect/mixer.so
-lib/audacious/Effect/resample.so
-lib/audacious/Effect/silence-removal.so
-lib/audacious/Effect/sox-resampler.so
-lib/audacious/Effect/speed-pitch.so
-lib/audacious/Effect/stereo.so
-lib/audacious/Effect/voice_removal.so
+@so lib/audacious/Effect/compressor.so
+@so lib/audacious/Effect/crossfade.so
+@so lib/audacious/Effect/crystalizer.so
+@so lib/audacious/Effect/echo.so
+@so lib/audacious/Effect/ladspa.so
+@so lib/audacious/Effect/mixer.so
+@so
Re: [NEW] devel/mongo-c-driver
On 2020/01/22 08:20, mbsd wrote: > ping? That is a very short time for sending a "ping" mail ... - use share/doc/mongo-c-driver instead of share/mongo-c-driver - for the SSL_OP_NO_RENEGOTIATION patch, definitely don't just comment it out. either add a !defined(LIBRESSL_VERSION) check or use #ifdef SSL_OP_NO_RENEGOTIATION ssl_ctx_options |= SSL_OP_NO_RENEGOTIATION; #endif - CATEGORIES=databases would be better - don't use -DCMAKE_BUILD_TYPE=Release this is set automatically
Re: update: devel/py-country
On Wed, 22 Jan 2020, Stuart Henderson wrote: > Do you have any local changes in mk.conf or diffs in python ports > infrastructure (python.port.mk etc)? Running "make plist" here doesn't add > those lines. This is my mk.conf (I have some things in /home because I built this machine before going into the porting party. I know, I should reinstall): WRKOBJDIR=/home/paco/ports/obj DISTDIR=/home/paco/ports/distfiles PACKAGE_REPOSITORY=/home/paco/ports/packages SUDO=/usr/bin/doas FETCH_PACKAGES= PORTS_PRIVSEP=Yes I don't have any diff on /usr/ports/infrastructure or /usr/ports/lang/python Cheers, -- Paco Esteban. 5818130B8A6DBC03
Re: update: devel/py-country
On 2020/01/22 10:24, Paco Esteban wrote:
> On Tue, 21 Jan 2020, Stuart Henderson wrote:
>
> > > blob - 031dc25d0da2814e24f88a0718ed0a0a7194a40d
> > > blob + c778d79fc708ac37809fb11369e635cc9292160f
> > > --- devel/py-country/pkg/PLIST
> > > +++ devel/py-country/pkg/PLIST
> > > @@ -1,4 +1,6 @@
> > > @comment $OpenBSD: PLIST,v 1.8 2019/02/17 20:22:22 sthen Exp $
> > > +lib/python${MODPY_VERSION}/
> > > +lib/python${MODPY_VERSION}/site-packages/
> >
> > I'm not sure how these lines were added, the directories come from a
> > dependency though and don't need listing. update-plist removes them here ..
>
>
> Those lines come from update-plist. I try not to touch PLIST manually,
> only to remove lines like those (this time I did not see them, sorry).
>
> I'll try to see next time when are they introduced, because is not the
> first time I see them on an updated python port.
Do you have any local changes in mk.conf or diffs in python ports
infrastructure (python.port.mk etc)? Running "make plist" here doesn't add
those lines.
> It seems that kmos has commited with your suggestions, so thank you both
> :-)
>
> --
> Paco Esteban.
> 5818130B8A6DBC03
>
Re: UPDATE audia/audacity
On 2020/01/22 14:18, Solene Rapenne wrote: > On Wed, Jan 22, 2020 at 01:27:28PM +0100, Björn Ketelaars wrote: > > Enclosed diff brings audacity to 2.3.3, which focuses on bug fixes and > > code restructuring. Additional information on this release can be found > > in the release announcement [0]. > > > > Run tested on amd64. More precise, I have been using this update for a > > couple of days. So far, no regression. > > > > Comments/OK? > > > > > > [0] https://github.com/audacity/audacity/releases/tag/Audacity-2.3.3 > > > is it normal? if so, ok solene@ update works and I found no regression > > $ make port-lib-depends-check > > audacity-2.3.3(audio/audacity): > Bogus WANTLIB: pango-1.0.3801 (/usr/local/bin/audacity) (NOT REACHABLE) > Bogus WANTLIB: pangocairo-1.0.3801 (/usr/local/bin/audacity) (NOT REACHABLE) > Bogus WANTLIB: pangoft2-1.0.3801 (/usr/local/bin/audacity) (NOT REACHABLE) > *** Error 1 in target 'port-lib-depends-check' (ignored) > It's normal if ports and packages are out of sync on the system running port-lib-depends-check :)
Re: UPDATE audia/audacity
On Wed, Jan 22, 2020 at 01:27:28PM +0100, Björn Ketelaars wrote: > Enclosed diff brings audacity to 2.3.3, which focuses on bug fixes and > code restructuring. Additional information on this release can be found > in the release announcement [0]. > > Run tested on amd64. More precise, I have been using this update for a > couple of days. So far, no regression. > > Comments/OK? > > > [0] https://github.com/audacity/audacity/releases/tag/Audacity-2.3.3 > is it normal? if so, ok solene@ update works and I found no regression $ make port-lib-depends-check audacity-2.3.3(audio/audacity): Bogus WANTLIB: pango-1.0.3801 (/usr/local/bin/audacity) (NOT REACHABLE) Bogus WANTLIB: pangocairo-1.0.3801 (/usr/local/bin/audacity) (NOT REACHABLE) Bogus WANTLIB: pangoft2-1.0.3801 (/usr/local/bin/audacity) (NOT REACHABLE) *** Error 1 in target 'port-lib-depends-check' (ignored)
UPDATE audia/audacity
Enclosed diff brings audacity to 2.3.3, which focuses on bug fixes and
code restructuring. Additional information on this release can be found
in the release announcement [0].
Run tested on amd64. More precise, I have been using this update for a
couple of days. So far, no regression.
Comments/OK?
[0] https://github.com/audacity/audacity/releases/tag/Audacity-2.3.3
diff --git Makefile Makefile
index e396d07d11c..51dad91c94c 100644
--- Makefile
+++ Makefile
@@ -6,9 +6,8 @@ COMMENT=free audio editor
# so can't be fetched automatically
GH_ACCOUNT=audacity
GH_PROJECT=audacity
-GH_TAGNAME=Audacity-2.3.2
+GH_TAGNAME=Audacity-2.3.3
DISTNAME= ${GH_TAGNAME:L}
-REVISION= 1
CATEGORIES=audio
HOMEPAGE= https://www.audacityteam.org/
diff --git distinfo distinfo
index 31e7b242cb0..67bf53ba677 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (audacity-2.3.2.tar.gz) = zEd6cf9Vcccoh6ehVTZbB6GlC86hq/SQpN57iEN2xzE=
-SIZE (audacity-2.3.2.tar.gz) = 61972597
+SHA256 (audacity-2.3.3.tar.gz) = QE5sSWk97clCEvxVJZdAWNhIU2Al4Z2jE1muArq+i9c=
+SIZE (audacity-2.3.3.tar.gz) = 62073352
diff --git patches/patch-configure_ac patches/patch-configure_ac
index d4356305ae5..c466434334a 100644
--- patches/patch-configure_ac
+++ patches/patch-configure_ac
@@ -6,7 +6,7 @@ $OpenBSD: patch-configure_ac,v 1.3 2019/06/12 20:28:36 rapha
Exp $
Index: configure.ac
--- configure.ac.orig
+++ configure.ac
-@@ -204,12 +204,16 @@ if test x$enable_universal_binary = xyes; then
+@@ -200,12 +200,16 @@ if test x$enable_universal_binary = xyes; then
esac
fi
@@ -29,7 +29,7 @@ Index: configure.ac
fi
if test x$enable_sse = xyes; then
-@@ -650,10 +654,6 @@ case "${host_os}" in
+@@ -646,10 +650,6 @@ case "${host_os}" in
AC_CHECK_LIB(asound, snd_pcm_open, have_alsa=yes, have_alsa=no)
if [[ $have_alsa = "yes" ]] ; then
LIBS="$LIBS -lasound"
diff --git patches/patch-lib-src_FileDialog_Makefile_am
patches/patch-lib-src_FileDialog_Makefile_am
index 1df0fbbc809..ec192221959 100644
--- patches/patch-lib-src_FileDialog_Makefile_am
+++ patches/patch-lib-src_FileDialog_Makefile_am
@@ -5,7 +5,8 @@ $OpenBSD: patch-lib-src_FileDialog_Makefile_am,v 1.1 2019/03/26
18:26:45 rapha E
Index: lib-src/FileDialog/Makefile.am
--- lib-src/FileDialog/Makefile.am.orig
+++ lib-src/FileDialog/Makefile.am
-@@ -1,6 +1,6 @@
+@@ -1,7 +1,7 @@
+ AM_LIBTOOLFLAGS = --tag CC
ACLOCAL_AMFLAGS = -I m4
-lib_LTLIBRARIES = libFileDialog.la
diff --git patches/patch-src_AudacityApp_cpp patches/patch-src_AudacityApp_cpp
index 4e61dcf65f6..5f5328b6605 100644
--- patches/patch-src_AudacityApp_cpp
+++ patches/patch-src_AudacityApp_cpp
@@ -5,7 +5,7 @@ Don't hardcode shared libraries version number.
Index: src/AudacityApp.cpp
--- src/AudacityApp.cpp.orig
+++ src/AudacityApp.cpp
-@@ -540,12 +540,12 @@ class GnomeShutdown
+@@ -642,12 +642,12 @@ class GnomeShutdown
{
mArgv[0].reset(strdup("Audacity"));
diff --git patches/patch-src_AudioIO_cpp patches/patch-src_AudioIO_cpp
index 5d078224adc..85a534c1f28 100644
--- patches/patch-src_AudioIO_cpp
+++ patches/patch-src_AudioIO_cpp
@@ -6,7 +6,7 @@ $OpenBSD: patch-src_AudioIO_cpp,v 1.10 2019/09/26 13:54:54
sthen Exp $
Index: src/AudioIO.cpp
--- src/AudioIO.cpp.orig
+++ src/AudioIO.cpp
-@@ -802,18 +802,15 @@ static double streamStartTime = 0; // bias system time
+@@ -797,18 +797,15 @@ static double streamStartTime = 0; // bias system time
static double SystemTime(bool usingAlsa)
{
#ifdef __WXGTK__
@@ -27,12 +27,12 @@ Index: src/AudioIO.cpp
}
#endif
-@@ -4738,7 +4735,7 @@ void AudioIoCallback::ComputeMidiTimings(
+@@ -3606,7 +3603,7 @@ void AudioIoCallback::ComputeMidiTimings(
}
/* GSW: Save timeInfo in case MidiPlayback needs it */
- mAudioCallbackClockTime = PaUtil_GetTime();
-+ mAudioCallbackClockTime = SystemTime(gAudioIO->mUsingAlsa);
++ mAudioCallbackClockTime = SystemTime(mUsingAlsa);
/* for Linux, estimate a smooth audio time as a slowly-changing
offset from system time */
diff --git patches/patch-src_MemoryX_h patches/patch-src_MemoryX_h
deleted file mode 100644
index 7fbd8a0874c..000
--- patches/patch-src_MemoryX_h
+++ /dev/null
@@ -1,13 +0,0 @@
-$OpenBSD: patch-src_MemoryX_h,v 1.4 2019/09/26 13:54:54 sthen Exp $
-
-Index: src/MemoryX.h
src/MemoryX.h.orig
-+++ src/MemoryX.h
-@@ -641,7 +641,6 @@ make_iterator_range( const Container )
- // For using std::unordered_map on wxString
- namespace std
- {
-- template struct hash;
-template<> struct hash< wxString > {
- size_t operator () (const wxString ) const // noexcept
- {
diff --git pkg/PLIST pkg/PLIST
index 6978510d226..82298e79ae8 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -88,7 +88,6 @@ share/audacity/plug-ins/sample-data-export.ny
share/audacity/plug-ins/sample-data-import.ny
share/audacity/plug-ins/tremolo.ny
share/audacity/plug-ins/vocalrediso.ny
-share/audacity/plug-ins/vocalremover.ny
Re: UPDATE: devel/gmake 4.2.1 => 4.3
On 2020-01-20, Christian Weisgerber wrote: > I'll run an amd64 bulk build with it sometime in the next few days. > The "WARNING: Backward-incompatibility!" changes could break some > cruft. These failed to build: devel/jdk/11? devel/libfirm # vs. \# emulators/mame spaces not added by += multimedia/gstreamer-0.10/plugins-base # vs. \# The failures also caused 500 package paths to be skipped. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [new] geo/gpxsee
On Wed, Jan 22, 2020 at 11:55:17AM +0100, Landry Breuil wrote: > Hi, > > here's a port for https://www.gpxsee.org/, a nice alternative to the > (more or less dead) geo/gpx-viewer port or geo/viking port. Works fine > here in basic testing. > > oks to import ? tweaks ? > > Landry awesome tool! Please change HOMEPAGE to use https:// (it works) with that change ok solene@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/01/22 04:55:35 Modified files: x11/gnome/libsecret: Makefile x11/gnome/libsecret/pkg: PLIST Log message: Explicitely do *not* depend on gtk-doc; we don't care about the html documentation. breakage reported by pvk@
Re: [NEW] devel/mongo-c-driver
ping? ~ mbsd[at]m0x.ru > Em 19 de jan de 2020, à(s) 18:10, Murilo Ijanc' escreveu: > > Hi, > > This is a new port for mongodb c driveri [1]. > > The MongoDB C Driveri [2], also known as “libmongoc”, is a library for using > MongoDB from C applications, and for writing MongoDB drivers in higher-level > languages. > > Tested on 6.6-CURRENT > > Comments, feedback OK? > > Thanks > > -- > Murilo Ijanc' > > [1] https://github.com/mongodb/mongo-c-driver > [2] http://mongoc.org/ >
[new] geo/gpxsee
Hi, here's a port for https://www.gpxsee.org/, a nice alternative to the (more or less dead) geo/gpx-viewer port or geo/viking port. Works fine here in basic testing. oks to import ? tweaks ? Landry gpxsee-7.19.tgz Description: application/tar-gz
Re: devel/openmpi mpifort error; compiler
On Wed, Jan 22, 2020 at 10:20:10AM +, Stuart Henderson wrote: > On 2020/01/22 11:07, Martin Reindl wrote: > > I've tested the folling diff and checked the libraries for changes with the > > help of shared_libs.log. libopen-pal only has adress changes and libopen-rte > > as a tiny symbol name changed - hence the minor bump. I've also fixed the > > orig version in the comments for the other libraries and sprinkled some @lib > > markers in the PLIST while there. > > I can't think about the fortran/gcc/clang bits at the moment but a quick > comment > on this, "symbol name changed" sounds like "1 removed 1 added" which is a > major bump. On closer inspection only adress changes - my bad: --- /tmp/old-open-rte.so.1.0Wed Jan 22 08:28:42 2020 +++ /tmp/new-open-rte.so.1.0Wed Jan 22 08:28:42 2020 @@ -1,5 +1,5 @@ -0002c820 r CSWTCH.50 -0002c5c0 r CSWTCH.99 +0002c860 r CSWTCH.50 +0002c600 r CSWTCH.99 000af9d0 T MPIR_Breakpoint 000be700 B MPIR_attach_fifo 000bef28 B MPIR_being_debugged @@ -1332,7 +1332,7 @@ 00049680 T orte_util_print_vpids 000498a0 T orte_util_snprintf_jobid 00057eb0 T orte_util_uncompress_block -0002cd9c R orte_version_string +0002cddc R orte_version_string F orte_wait.c 00045850 T orte_wait_cb 00045b10 T orte_wait_cb_cancel @@ -1628,22 +1628,22 @@ 000a3670 t write_help_msg 0009f670 t xfer_cons 0004b5e0 t xml_format -0002a680 r yy_accept -00029fc0 r yy_base +0002a6c0 r yy_accept +0002a000 r yy_base 000bd620 b yy_buffer_stack 000bd628 b yy_buffer_stack_max 000bd630 b yy_buffer_stack_top 000bd608 b yy_c_buf_p -00029420 r yy_chk -00029da0 r yy_def +00029460 r yy_chk +00029de0 r yy_def 000bd5fc b yy_did_buffer_switch_on_eof -0002a280 r yy_ec +0002a2c0 r yy_ec 0004e0e0 t yy_fatal_error 000bd618 b yy_hold_char 000bd604 b yy_init 000bd5f0 b yy_last_accepting_cpos 000bd5f8 b yy_last_accepting_state -0002a1e0 r yy_meta +0002a220 r yy_meta 000bd610 b yy_n_chars -000298e0 r yy_nxt +00029920 r yy_nxt 000bd600 b yy_start
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/01/22 03:21:47 Modified files: security/suricata: Makefile security/suricata/pkg: PLIST Log message: Remove share/doc/suricata, the files it contains are all just a couple of lines redirecting readers to the website. ok gonzalo@
Re: devel/openmpi mpifort error; compiler
On Tue, Jan 21, 2020 at 01:20:29PM -0700, j...@bitminer.ca wrote:
>
>
> On 2020-01-21 12:45, Martin Reindl wrote:
> > Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
> > > This fixes the mpifort command which can't find egfortran.
> > >
> > > I also propose removing COMPILER = base-clang since this compiles
> > > with gcc anyway. GCC also has some advantages for us fortran
> > > users (coarray fortran).
> >
> > Hello John,
> >
> > - OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
> > - REVISION should start at 0
>
> Ahh, the perils of porting infrequently. Good point.
>
> > - egfortran actually is the one from ports-gcc (8.3.0), I don't see the
> > point replacing base clang 8.0.1 if you need coarray fortran?
>
> On AMD64, OpenMPI compiles with ports-gcc anyway, hence my notion
> to avoid confusion by naming the one compiler:
>
>
>
> ===> Checking files for openmpi-4.0.2p1
> `/usr/distfiles/openmpi-4.0.2.tar.gz' is up to date.
> > > (SHA256) openmpi-4.0.2.tar.gz: OK
> ===> openmpi-4.0.2p1 depends on: libltdl-* -> libltdl-2.4.2p1
> ===> openmpi-4.0.2p1 depends on: gcc->=8,<9 -> gcc-8.3.0p4
> etc etc
>
> Once built (using ports-gcc egcc and egfortran), then OpenMPI is
> compatible with clang but not flang because the two Fortrans
> have different array implementations (max rank=15 on egfortran
> versus merely 8 or 9 on flang, and OpenMPI notices.)
>
> The GCC gfortran compiler supports co-arrays but flang does
> not, to my knowledge. The coarrays lib is a very simple
> port that I should post.
>
Hi John, Hi Stuart,
I've got around to testing this now a bit more:
- Currently, the port does not use flang. It used to before the update to
openmpi-4.0.1. So every Fortran feature in the current state depends solely
on gcc8 from ports-gcc
- Strictly speaking the COMPILER line is there for archs where there is no
clang in base and base-gcc is too old. This gives archs like macppc and
sparc64 a chance to compile and run openmpi
- with MODULES=fortran on a base-clang archs we now have the situation that we
build the openmpi binaries and librariers with ports-gcc but at runtime we
use base-clang:
$ mpicc -v
OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1)
for Fortran with Johns diff it's ports-gcc as usual:
$ mpifort -v
[...]
gcc version 8.3.0 (GCC)
We could use ports-gcc only but I am not sure what produces a more coherent
system on a base-clang arch where openmpi seems to be most likely to be useful
(meaning amd64 and arm64, mostly).
A possibility would be to split up the port:
a base-clang only version:
- Fortran disabled
- coherent on all base-clang archs
a ports-gcc version:
- Fortran enabled
- also available where there is no base-clang
- possibly less coherent because mixing of libraries (as Stuart pointed)
out
For now I would keep base-clang, but given the small userbase it might be worth
to really just keep a ports-gcc version.
I've tested the folling diff and checked the libraries for changes with the
help of shared_libs.log. libopen-pal only has adress changes and libopen-rte
as a tiny symbol name changed - hence the minor bump. I've also fixed the
orig version in the comments for the other libraries and sprinkled some @lib
markers in the PLIST while there.
-m
Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 - 1.29
+++ Makefile22 Jan 2020 09:22:54 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement
V =4.0.2
DISTNAME = openmpi-$V
+REVISION = 0
-SHARED_LIBS += mca_common_dstore 0.0 # 1.0
+SHARED_LIBS += mca_common_dstore 0.0 # 1.1
SHARED_LIBS += mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS += mca_common_ompio 0.0 # 60.1
+SHARED_LIBS += mca_common_ompio 0.0 # 60.2
SHARED_LIBS += mca_common_sm 2.0 # 60.0
-SHARED_LIBS += mpi 1.0 # 60.1
-SHARED_LIBS += mpi_mpifh 0.0 # 60.1
+SHARED_LIBS += mpi 1.0 # 60.2
+SHARED_LIBS += mpi_mpifh 0.0 # 60.2
SHARED_LIBS += mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS += mpi_usempif08 0.0 # 60.0
+SHARED_LIBS += mpi_usempif08 0.0 # 60.1
SHARED_LIBS += ompitrace 0.0 # 60.0
-SHARED_LIBS += open-pal 1.0 # 60.1
-SHARED_LIBS += open-rte 1.0 # 60.1
+SHARED_LIBS += open-pal 1.1 # 60.2
+SHARED_LIBS += open-rte 1.1 # 60.2
CATEGORIES = devel
@@ -31,10 +32,17 @@ WANTLIB += c execinfo m pciaccess pthrea
MASTER_SITES =
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
COMPILER =
Re: update: devel/py-country
On Tue, 21 Jan 2020, Stuart Henderson wrote:
> > blob - 031dc25d0da2814e24f88a0718ed0a0a7194a40d
> > blob + c778d79fc708ac37809fb11369e635cc9292160f
> > --- devel/py-country/pkg/PLIST
> > +++ devel/py-country/pkg/PLIST
> > @@ -1,4 +1,6 @@
> > @comment $OpenBSD: PLIST,v 1.8 2019/02/17 20:22:22 sthen Exp $
> > +lib/python${MODPY_VERSION}/
> > +lib/python${MODPY_VERSION}/site-packages/
>
> I'm not sure how these lines were added, the directories come from a
> dependency though and don't need listing. update-plist removes them here ..
Those lines come from update-plist. I try not to touch PLIST manually,
only to remove lines like those (this time I did not see them, sorry).
I'll try to see next time when are they introduced, because is not the
first time I see them on an updated python port.
It seems that kmos has commited with your suggestions, so thank you both
:-)
--
Paco Esteban.
5818130B8A6DBC03
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/01/22 01:52:34 Modified files: devel/py-buildslave: Makefile distinfo devel/py-buildslave/pkg: PLIST devel/py-buildbot: Makefile.inc devel/py-buildbot/buildbot: distinfo devel/py-buildbot/buildbot/pkg: PLIST devel/py-buildbot/console-view: distinfo devel/py-buildbot/grid-view: distinfo devel/py-buildbot/pkg: distinfo devel/py-buildbot/waterfall-view: distinfo devel/py-buildbot/www: distinfo Log message: Update to buildbot 2.6.0.
Re: update to libvips 8.9.0
Le mardi 21 janvier 2020 11:45:39 CET, vous avez écrit : > On Mon, Jan 20, 2020 at 10:43:49PM +0100, Stephane Guedon wrote: > > > In Makefile : > > > - SHARED_LIBS should start at 0.0 > > > - LIB_DEPENDS should be one dep per line > > > > > > Also pkg/DESCR is shorter, any reason why ? > > > > Mistake happened. Apologies. > > No worries :) > > It seems you did not update PLIST. > Also it would be better to indent "\" in Makefile. > > Thank you I thought I did the plist thing already. Sorry :) libvips.8.9.0.tar.gz Description: application/compressed-tar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/22 01:09:49 Modified files: www/nextcloud : Tag: OPENBSD_6_6 Makefile distinfo www/nextcloud/pkg: Tag: OPENBSD_6_6 PLIST Log message: Update for Nextcloud to 18.0.0 OK abieber@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2020/01/22 01:09:20 Modified files: www/nextcloud : Makefile distinfo www/nextcloud/pkg: PLIST Log message: Update for Nextcloud to 18.0.0 OK abieber@
Re: UPDATE: Jailkit-2.21
ping
On Wed, 15 Jan 2020 at 17:35:47 +0100, Gonzalo L. Rodriguez wrote:
> Hallo,
>
> Update for Jailkit to 2.21:
>
> https://olivier.sessink.nl/jailkit/
>
> OK? Comments?
>
> Cheers.-
>
> --
>
> - gonzalo
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/jailkit/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile 12 Jul 2019 20:49:03 - 1.15
> +++ Makefile 15 Jan 2020 16:33:38 -
> @@ -2,7 +2,7 @@
>
> COMMENT= utilities for jailing a user or process
>
> -DISTNAME=jailkit-2.19
> +DISTNAME=jailkit-2.21
> CATEGORIES= security sysutils
>
> HOMEPAGE=http://olivier.sessink.nl/jailkit/
> @@ -13,6 +13,8 @@ MASTER_SITES= http://olivier.sessink.nl
> PERMIT_PACKAGE= Yes
>
> MODULES= lang/python
> +MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> +
> WANTLIB += c pthread
>
> NO_TEST= Yes
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/jailkit/distinfo,v
> retrieving revision 1.8
> diff -u -p -r1.8 distinfo
> --- distinfo 20 Dec 2015 15:43:46 - 1.8
> +++ distinfo 15 Jan 2020 16:33:38 -
> @@ -1,2 +1,2 @@
> -SHA256 (jailkit-2.19.tar.gz) = /ZYS3Vf0o5q/zeZHxCBhbFyjf1mCuMB6j7XLNSSU/Ig=
> -SIZE (jailkit-2.19.tar.gz) = 142280
> +SHA256 (jailkit-2.21.tar.gz) = egIOB635OGDFOPDZgZauoz1GG6vbqLs+3fcIHleinBQ=
> +SIZE (jailkit-2.21.tar.gz) = 141341
> Index: patches/patch-Makefile_in
> ===
> RCS file: /cvs/ports/security/jailkit/patches/patch-Makefile_in,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 patch-Makefile_in
> --- patches/patch-Makefile_in 20 Sep 2010 07:15:30 - 1.1.1.1
> +++ patches/patch-Makefile_in 15 Jan 2020 16:33:38 -
> @@ -2,24 +2,25 @@ $OpenBSD: patch-Makefile_in,v 1.1.1.1 20
>
> We do not want the packge to manipulate our /etc/shells, use @shell in PLIST
>
> Makefile.in.orig Sat Sep 11 15:45:26 2010
> -+++ Makefile.in Mon Sep 13 08:01:37 2010
> +Index: Makefile.in
> +--- Makefile.in.orig
> Makefile.in
> @@ -69,12 +69,12 @@ install:
> @cd man/ && $(MAKE) install
> # test if the jk_chrootsh is already in /etc/shells
> # this previously had @echo but that fails on FreeBSD
> --if test -w /etc/shells; then \
> --if ! grep ${prefix}/sbin/jk_chrootsh /etc/shells ; then \
> --echo "appending ${prefix}/sbin/jk_chroots to
> /etc/shells";\
> --echo ${prefix}/sbin/jk_chrootsh >> /etc/shells ;\
> --fi \
> --fi
> -+#if test -w /etc/shells; then \
> -+# if ! grep ${prefix}/sbin/jk_chrootsh /etc/shells ; then \
> -+# echo "appending ${prefix}/sbin/jk_chroots to
> /etc/shells";\
> -+# echo ${prefix}/sbin/jk_chrootsh >> /etc/shells ;\
> -+# fi \
> -+#fi
> +-#if test -w /etc/shells; then \
> +-# if ! grep ${prefix}/sbin/jk_chrootsh /etc/shells ; then \
> +-# echo "appending ${prefix}/sbin/jk_chroots to
> /etc/shells";\
> +-# echo ${prefix}/sbin/jk_chrootsh >> /etc/shells ;\
> +-# fi \
> +-#fi
> ++if test -w /etc/shells; then \
> ++if ! grep ${prefix}/sbin/jk_chrootsh /etc/shells ; then \
> ++echo "appending ${prefix}/sbin/jk_chroots to
> /etc/shells";\
> ++echo ${prefix}/sbin/jk_chrootsh >> /etc/shells ;\
> ++fi \
> ++fi
>
>
> uninstall:
> Index: patches/patch-ini_jk_init_ini
> ===
> RCS file: /cvs/ports/security/jailkit/patches/patch-ini_jk_init_ini,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-ini_jk_init_ini
> --- patches/patch-ini_jk_init_ini 26 Mar 2014 17:38:27 - 1.3
> +++ patches/patch-ini_jk_init_ini 15 Jan 2020 16:33:38 -
> @@ -2,13 +2,14 @@ $OpenBSD: patch-ini_jk_init_ini,v 1.3 20
>
> fix some default paths in the jail creation configuration file
>
> ini/jk_init.ini.orig Mon Dec 23 06:02:42 2013
> -+++ ini/jk_init.ini Wed Dec 25 16:04:26 2013
> +Index: ini/jk_init.ini
> +--- ini/jk_init.ini.orig
> ini/jk_init.ini
> @@ -2,18 +2,18 @@
> # this section probably needs adjustment on 64bit systems
> # or non-Linux systems
> comment = common files for all jails that need user/group information
> --paths = /lib/libnsl.so.1, /lib64/libnsl.so.1, /lib/libnss*.so.2,
> /lib64/libnss*.so.2, /lib/i386-linux-gnu/libnsl.so.1,
> /lib/i386-linux-gnu/libnss*.so.2, /lib/x86_64-linux-gnu/libnsl.so.1,
> /lib/x86_64-linux-gnu/libnss*.so.2, /etc/nsswitch.conf, /etc/ld.so.conf
> +-paths = /lib/libnsl.so.1, /lib64/libnsl.so.1, /lib/libnss*.so.2,
> /lib64/libnss*.so.2,
Re: UPDATE: kpcli-3.3
ping On Wed, 15 Jan 2020 at 17:53:58 +0100, Gonzalo L. Rodriguez wrote: > Hello, > > Little update for kpcli to 3.3: > > https://sourceforge.net/projects/kpcli/files/ > > OK? Comments? > > Cheers.- > > -- > > - gonzalo > Index: Makefile > === > RCS file: /cvs/ports/security/kpcli/Makefile,v > retrieving revision 1.10 > diff -u -p -r1.10 Makefile > --- Makefile 12 Jul 2019 20:49:04 - 1.10 > +++ Makefile 15 Jan 2020 16:51:55 - > @@ -2,7 +2,7 @@ > > COMMENT =cli browser for keepassx databases > > -DISTNAME = kpcli-3.2 > +DISTNAME = kpcli-3.3 > CATEGORIES = security > EXTRACT_SUFX = .pl > EXTRACT_ONLY = > Index: distinfo > === > RCS file: /cvs/ports/security/kpcli/distinfo,v > retrieving revision 1.4 > diff -u -p -r1.4 distinfo > --- distinfo 31 Jan 2018 07:56:52 - 1.4 > +++ distinfo 15 Jan 2020 16:51:55 - > @@ -1,2 +1,2 @@ > -SHA256 (kpcli-3.2.pl) = YVobrhntDBMgdqgJsWKmbqDcIsHZkqjG4fLhqu365oc= > -SIZE (kpcli-3.2.pl) = 197369 > +SHA256 (kpcli-3.3.pl) = BN6YTWt5veuEaJv46qDi46qHVrfMqf/fNuGp0cDxzfw= > +SIZE (kpcli-3.3.pl) = 199249 -- - gonzalo
