[UPDATE] lang/python/3.6

2018-10-21 Thread Remi Pointel

Hi,

attached is the diff to update to python 3.6.7.

Please test this diff in a bulk build.

Cheers,

Remi.
Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.6/Makefile,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 Makefile
--- Makefile18 Sep 2018 16:43:12 -  1.13
+++ Makefile22 Oct 2018 05:03:40 -
@@ -6,10 +6,9 @@
 # Python itself.
 
 VERSION =  3.6
-PATCHLEVEL =   .6
+PATCHLEVEL =   .7
 SHARED_LIBS =  python3.6m 0.0
 VERSION_SPEC = >=3.6,<3.7
-REVISION = 1
 
 CONFIGURE_ARGS +=  --with-ensurepip=no
 CONFIGURE_ARGS +=  --enable-loadable-sqlite-extensions
Index: distinfo
===
RCS file: /cvs/ports/lang/python/3.6/distinfo,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 distinfo
--- distinfo2 Jul 2018 04:56:07 -   1.7
+++ distinfo22 Oct 2018 05:03:40 -
@@ -1,2 +1,2 @@
-SHA256 (Python-3.6.6.tgz) = fVba32x9kqI4cCOJ6Az+Zvv65z5YQYntb4nHW78+2lg=
-SIZE (Python-3.6.6.tgz) = 22930752
+SHA256 (Python-3.6.7.tgz) = t8Nvftj3FDssRhU7czLbIidmn1g+oMznU/rPVJ0aQjk=
+SIZE (Python-3.6.7.tgz) = 22969142
Index: pkg/PLIST-idle
===
RCS file: /cvs/ports/lang/python/3.6/pkg/PLIST-idle,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 PLIST-idle
--- pkg/PLIST-idle  3 Apr 2018 17:53:48 -   1.5
+++ pkg/PLIST-idle  22 Oct 2018 05:03:40 -
@@ -55,9 +55,6 @@ lib/python3.6/idlelib/__pycache__/browse
 lib/python3.6/idlelib/__pycache__/calltip_w.cpython-36.opt-1.pyc
 lib/python3.6/idlelib/__pycache__/calltip_w.cpython-36.opt-2.pyc
 lib/python3.6/idlelib/__pycache__/calltip_w.cpython-36.pyc
-lib/python3.6/idlelib/__pycache__/calltips.cpython-36.opt-1.pyc
-lib/python3.6/idlelib/__pycache__/calltips.cpython-36.opt-2.pyc
-lib/python3.6/idlelib/__pycache__/calltips.cpython-36.pyc
 lib/python3.6/idlelib/__pycache__/codecontext.cpython-36.opt-1.pyc
 lib/python3.6/idlelib/__pycache__/codecontext.cpython-36.opt-2.pyc
 lib/python3.6/idlelib/__pycache__/codecontext.cpython-36.pyc
@@ -199,9 +196,6 @@ lib/python3.6/idlelib/__pycache__/tree.c
 lib/python3.6/idlelib/__pycache__/undo.cpython-36.opt-1.pyc
 lib/python3.6/idlelib/__pycache__/undo.cpython-36.opt-2.pyc
 lib/python3.6/idlelib/__pycache__/undo.cpython-36.pyc
-lib/python3.6/idlelib/__pycache__/windows.cpython-36.opt-1.pyc
-lib/python3.6/idlelib/__pycache__/windows.cpython-36.opt-2.pyc
-lib/python3.6/idlelib/__pycache__/windows.cpython-36.pyc
 lib/python3.6/idlelib/__pycache__/zoomheight.cpython-36.opt-1.pyc
 lib/python3.6/idlelib/__pycache__/zoomheight.cpython-36.opt-2.pyc
 lib/python3.6/idlelib/__pycache__/zoomheight.cpython-36.pyc
@@ -214,7 +208,6 @@ lib/python3.6/idlelib/autocomplete_w.py
 lib/python3.6/idlelib/autoexpand.py
 lib/python3.6/idlelib/browser.py
 lib/python3.6/idlelib/calltip_w.py
-lib/python3.6/idlelib/calltips.py
 lib/python3.6/idlelib/codecontext.py
 lib/python3.6/idlelib/colorizer.py
 lib/python3.6/idlelib/config-extensions.def
@@ -267,9 +260,6 @@ lib/python3.6/idlelib/idle_test/__pycach
 lib/python3.6/idlelib/idle_test/__pycache__/test_browser.cpython-36.opt-1.pyc
 lib/python3.6/idlelib/idle_test/__pycache__/test_browser.cpython-36.opt-2.pyc
 lib/python3.6/idlelib/idle_test/__pycache__/test_browser.cpython-36.pyc
-lib/python3.6/idlelib/idle_test/__pycache__/test_calltips.cpython-36.opt-1.pyc
-lib/python3.6/idlelib/idle_test/__pycache__/test_calltips.cpython-36.opt-2.pyc
-lib/python3.6/idlelib/idle_test/__pycache__/test_calltips.cpython-36.pyc
 lib/python3.6/idlelib/idle_test/__pycache__/test_colorizer.cpython-36.opt-1.pyc
 lib/python3.6/idlelib/idle_test/__pycache__/test_colorizer.cpython-36.opt-2.pyc
 lib/python3.6/idlelib/idle_test/__pycache__/test_colorizer.cpython-36.pyc
@@ -381,7 +371,6 @@ lib/python3.6/idlelib/idle_test/mock_tk.
 lib/python3.6/idlelib/idle_test/test_autocomplete.py
 lib/python3.6/idlelib/idle_test/test_autoexpand.py
 lib/python3.6/idlelib/idle_test/test_browser.py
-lib/python3.6/idlelib/idle_test/test_calltips.py
 lib/python3.6/idlelib/idle_test/test_colorizer.py
 lib/python3.6/idlelib/idle_test/test_config.py
 lib/python3.6/idlelib/idle_test/test_config_key.py
@@ -445,6 +434,5 @@ lib/python3.6/idlelib/textview.py
 lib/python3.6/idlelib/tooltip.py
 lib/python3.6/idlelib/tree.py
 lib/python3.6/idlelib/undo.py
-lib/python3.6/idlelib/windows.py
 lib/python3.6/idlelib/zoomheight.py
 lib/python3.6/idlelib/zzdummy.py
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/lang/python/3.6/pkg/PLIST-main,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 PLIST-main
--- pkg/PLIST-main  2 Jul 2018 04:56:07 -   1.8
+++ pkg/PLIST-main  22 Oct 2018 05:03:41 -
@@ -2219,10 +2219,98 @@ lib/python3.6/http/client.py
 lib/python3.6/http/cookiejar.py
 lib/python3.6/http/cookies.py
 

Re: NEW: math/mlpack (and dependency math/armadillo)

2018-10-21 Thread Steven Mestdagh
Jeremie Courreges-Anglas [2018-10-21, 17:25:19]:
> On Sun, Oct 21 2018, Marc Espie  wrote:
> > Here's a revised version of the armadillo port, adding arpack and hdf5
> > as a dependency.
> >
> > And the missed COMPILER line, oops.
> >
> > Notes:
> > - I definitely prefer to be explicit for CONFIGURE_STYLE
> 
> grep says that most ports rely on the cmake module setting up
> CONFIGURE_STYLE.  Just sayin'...
> 
> > - with arpack added, no need for explicit depends on blas/lapack,
> > as arpack needs them anyway.
> 
> Not sure what's the point of trimming the list of deps, especially as
> armadillo explicitely references code from blas, lapack and arpack.
> I don't think it makes maintenance any easier, rather the opposite.
> That said...
> 
> I like this updated version, ok jca@
> 
> Regarding libgfortran,
> 
> > - the library definitely requires linking with the gfortran library
> > because some of lapack blas want symbols in there
> 
> Yeah I see.  IIUC blas, apack and arpack don't register the dep on
> libgfortran because of a build system quirk (linking is done with with
> cc instead of gfortran).  A simple diff like below would register the
> dep on libgfortran, and remove the need for patch-CMakeLists_txt.
> 
> cc'ing steven@ (maintainer)
> 
> Thoughts, ok?
> 
> 
> Index: blas/Makefile
> ===
> RCS file: /cvs/ports/math/blas/Makefile,v
> retrieving revision 1.27
> diff -u -p -r1.27 Makefile
> --- blas/Makefile 13 Nov 2017 06:56:38 -  1.27
> +++ blas/Makefile 21 Oct 2018 14:31:16 -
> @@ -4,6 +4,7 @@ COMMENT=  Basic Linear Algebra Subprogram
>  
>  VERSION= 3.7.1
>  DISTNAME=blas-${VERSION}
> +REVISION=0
>  
>  SHARED_LIBS= blas2.1
>  
> Index: blas/files/Makefile
> ===
> RCS file: /cvs/ports/math/blas/files/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- blas/files/Makefile   13 Nov 2017 06:56:38 -  1.3
> +++ blas/files/Makefile   21 Oct 2018 14:31:16 -
> @@ -25,6 +25,7 @@ SRCS =  caxpy.f  ccopy.f  cdotc.f  cdotu.
>   zhpmv.f  zhpr.f   zhpr2.f  zrotg.f  zscal.f  zswap.f  zsymm.f   \
>   zsyr2k.f zsyrk.f  ztbmv.f  ztbsv.f  ztpmv.f  ztpsv.f  ztrmm.f   \
>   ztrmv.f  ztrsm.f  ztrsv.f  xerbla_array.f
> +LDADD = -lgfortran
>  
>  printsrc:
>   @echo ${SRCS}

How about just linking with gfortran by passing CC to make?
(blas diff below, but similar for the other ports)
I didn't check if dependent ports are happy with that in terms of
WANTLIB etc.

Index: Makefile
===
RCS file: /cvs/ports/math/blas/Makefile,v
retrieving revision 1.27
diff -u -p -u -r1.27 Makefile
--- Makefile13 Nov 2017 06:56:38 -  1.27
+++ Makefile21 Oct 2018 21:40:59 -
@@ -4,6 +4,7 @@ COMMENT=Basic Linear Algebra Subprogram
 
 VERSION=   3.7.1
 DISTNAME=  blas-${VERSION}
+REVISION=  0
 
 SHARED_LIBS=   blas2.1
 
@@ -30,7 +31,8 @@ BUILD_DEPENDS=${MODFORTRAN_BUILD_DEPEND
 MAKE_FILE= ${FILESDIR}/Makefile
 MAKE_ENV=  SHLIB_MAJOR=${LIBblas_VERSION:R} \
SHLIB_MINOR=${LIBblas_VERSION:E} \
-   FC="${MODFORTRAN_COMPILER} -cpp"
+   FC="${MODFORTRAN_COMPILER} -cpp" \
+   CC=${MODFORTRAN_COMPILER}
 FAKE_FLAGS=LIBDIR=${LOCALBASE}/lib DEBUGLIBS=no
 USE_GROFF= Yes
 



amd64: build failures with lld (2018-10-20)

2018-10-21 Thread Christian Weisgerber
kettenis@'s latest lld fix has allowed building gcc49, which has
unlocked numerous ports.  Here is the current fallout from a test
build with lld; newly revealed failures are marked with '+':

+audio/audacity undefined symbol: g_signal_connect_data
 benchmarks/wrk string table non-null terminated
 databases/pgmodelerundefined symbol: backtrace
 devel/ffcall   can't create dynamic relocation R_X86_64_64
 editors/emacs21segfault
+games/flightgear/base  undefined symbol: XOpenDisplay
+games/pingus   undefined symbol: XFree
+games/pokerth  undefined symbol: SSL_library_init
 games/tome4undefined symbol: _Unwind_GetCFA
+games/valyriatear  undefined symbol: libiconv_open
 games/warzone2100  undefined symbol: ogg_sync_init
 lang/crystal   undefined symbol: OPENSSL_add_all_algorithms_noconf
 lang/fpc   invalid alignment of section headers
+mail/evolution-rss edbus-private not found
 misc/rocrail   undefined symbol: operator new(unsigned long)
+net/bitcoin,no_x11 -shared and -pie may not be used together
 net/telepathy/folksedbus-private not found
 productivity/glabels   edbus-private not found
+productivity/ledgereditline/readline.h not found
 security/xca   undefined symbol: _Unwind_Resume
 sysutils/firmware/vmm  ld "does not properly handle alignments"
 sysutils/memtest86+unknown argument: --warn-constructors
 x11/gnustep/terminal   undefined symbol: libiconv

The error logs are available under
http://build-failures.rhaalovely.net/amd64-clang/2018-10-20/

To try this yourself, do "ln -f /usr/bin/ld.lld /usr/bin/ld" and
tweak ports/infrastructure/mk/arch-defines.mk like this:
-LLD_ARCHS = aarch64 arm
+LLD_ARCHS = aarch64 amd64 arm

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: Update of p5-Test-Base, p5-Test-YAML, p5-YAML, p5-YAML-Tiny and p5-YAML-XS

2018-10-21 Thread Andrew Hewus Fresh
On Sun, Oct 21, 2018 at 04:05:48AM +, wen heping wrote:
> Hi, ports@:
> 
> Here is a patch to update :
>  devel/p5-Test-Base --> 0.89

I think this needs a new TEST_DEPENDS of p5-Algorithm-Diff, see below


>  devel/p5-Test-YAML --> 1.07

OK afresh1@


>  devel/p5-YAML --> 1.26

This needed some TEST_DEPENDS fixes for me, see below


>  devel/p5-YAML-Tiny --> 1.73

Looks like most of the test depends moved to the xt/ directory so we
don't need them, but it did need p5-JSON-MaybeXS, see below.


>  devel/p5-YAML-XS --> 0.74

OK afresh1@
(and I can take MAINTAINER on it, as I'm already p5-YAML)

>All patch build and test well on my amd64 system.
> 
>OK ?

I didn't run reverse dependency tests on these, but may get to trying
that later, however I expect it'll be OK and we can solve any fallout
before the next release.


Index: Makefile
===
RCS file: /cvs/ports/devel/p5-Test-Base/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile20 Mar 2016 19:56:36 -  1.11
+++ Makefile21 Oct 2018 19:49:02 -
@@ -5,15 +5,16 @@ COMMENT=  data driven test framework
 MODULES=   cpan
 PKG_ARCH=  *
 
-DISTNAME=  Test-Base-0.88
+DISTNAME=  Test-Base-0.89
 CATEGORIES=devel
 
 # perl
 PERMIT_PACKAGE_CDROM=  Yes
 
-RUN_DEPENDS=   devel/p5-Spiffy
+RUN_DEPENDS=   devel/p5-Spiffy>=0.40
 
-TEST_DEPENDS=  devel/p5-Test-Deep \
-   devel/p5-YAML
+TEST_DEPENDS=  devel/p5-Algorithm-Diff>=1.15 \
+   devel/p5-Test-Deep \
+   textproc/p5-Text-Diff>=0.35
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-Test-Base/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo19 Apr 2015 12:41:24 -  1.7
+++ distinfo21 Oct 2018 19:49:02 -
@@ -1,2 +1,2 @@
-SHA256 (Test-Base-0.88.tar.gz) = UjaMxanLvE6roz7YIGcvkgAbc9i8ugu5XV/bHTcLkDk=
-SIZE (Test-Base-0.88.tar.gz) = 52032
+SHA256 (Test-Base-0.89.tar.gz) = J5Shqq6x06KH3SxyhiWGY3llYvfbnMxrQkvE8d6K0BQ=
+SIZE (Test-Base-0.89.tar.gz) = 52105

Index: Makefile
===
RCS file: /cvs/ports/devel/p5-YAML/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile23 Nov 2016 00:47:06 -  1.20
+++ Makefile21 Oct 2018 20:11:30 -
@@ -5,7 +5,7 @@ COMMENT =   YAML Ain't Markup Language
 MODULES =  cpan
 PKG_ARCH = *
 
-DISTNAME = YAML-1.19
+DISTNAME = YAML-1.26
 CATEGORIES =   devel
 
 MAINTAINER =   Andrew Fresh 
@@ -13,11 +13,15 @@ MAINTAINER =Andrew Fresh =1.05 \
-   devel/p5-Test-Pod
-MAKE_ENV +=RELEASE_TESTING=1
+TEST_DEPENDS = devel/p5-Test-Deep \
+   devel/p5-Test-YAML>=1.05
+
+# Additional depends to avoid skipping tests
+TEST_ENV +=AUTHOR_TESTING=1
+TEST_DEPENDS +=devel/p5-Test-Pod
 
 .include 
 

Index: distinfo
===
RCS file: /cvs/ports/devel/p5-YAML/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo23 Nov 2016 00:47:06 -  1.12
+++ distinfo21 Oct 2018 20:05:15 -
@@ -1,2 +1,2 @@
-SHA256 (YAML-1.19.tar.gz) = MBD2ULDxehIKNMKj3N/J7iux/hRapSMFk266nAEgAFw=
-SIZE (YAML-1.19.tar.gz) = 81305
+SHA256 (YAML-1.26.tar.gz) = +i+Z1UxK+8WvnaYyJgnStpfQIAtrzm/fZEr/QkKVf7w=
+SIZE (YAML-1.26.tar.gz) = 86698

Index: Makefile
===
RCS file: /cvs/ports/devel/p5-YAML-Tiny/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile4 Dec 2017 17:56:27 -   1.13
+++ Makefile21 Oct 2018 19:43:08 -
@@ -4,17 +4,13 @@ COMMENT = read/write YAML files with as 
 
 MODULES =  cpan
 PKG_ARCH = *
-DISTNAME = YAML-Tiny-1.70
+DISTNAME = YAML-Tiny-1.73
 CATEGORIES =   devel
-FIX_EXTRACT_PERMISSIONS=   Yes
 
 # Perl
 PERMIT_PACKAGE_CDROM = Yes
 
-TEST_DEPENDS = devel/p5-YAML \
-   devel/p5-YAML-Perl \
-   devel/p5-YAML-Syck \
-   devel/p5-YAML-XS
+TEST_DEPENDS = converters/p5-JSON-MaybeXS>=1.001000
 
 MAKE_ENV +=AUTOMATED_TESTING=1
 
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-YAML-Tiny/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo29 Apr 2017 13:26:12 -  1.7
+++ distinfo21 Oct 2018 19:43:08 -
@@ -1,2 +1,2 @@
-SHA256 (YAML-Tiny-1.70.tar.gz) = u85LUrXq/bBOMEOXWgjb85TQC30slYrbnQPZ9+kpElU=
-SIZE (YAML-Tiny-1.70.tar.gz) = 72663
+SHA256 (YAML-Tiny-1.73.tar.gz) = vDFfoS6PHj7l4vQw2Qtwil3H5HyGfbqNzjprj74ld0Q=
+SIZE (YAML-Tiny-1.73.tar.gz) = 73708



[UPDATE] devel/p5-MRO-Compat to 0.13

2018-10-21 Thread Andrew Hewus Fresh
This is a fairly minor update, mostly to deal with the lack of "." in
@INC.  It also moves the Pod tests to an "xt" directory so they don't
even try to run normally.

It does remove the dependency on p5-Class-C3 as that is ignored if the
perl version >= 5.9.5 or greater (which ours is).

There is one difference in the reverse dependency test results,
p5-Catalyst-View-TT went from failing to passing, so yay!
(I'm not quite sure why, but didn't dig too deep)

There are also still some reverse dependency failures:
* p5-Catalyst-Plugin-Authentication which seems to need an of a
  dependency
* p5-Catalyst-Plugin-Unicode which is the same issue with
  Class::MOP::load_class being deprecated
* p5-Catalyst-Controller-HTML-FormFu which is again the same
* p5-Catalyst-Plugin-PageCache same again
* p5-Catalyst-Plugin-Session and again
* p5-Catalyst-Runtime-5.90006 and again, probably should look here
* p5-HTML-FormFu which apparently uses qw() in a for loop without parens
  and so needs an update.

And some similar failures that were dependencies of
p5-Devel-GlobalDestruction:
* p5-Moose
* p5-MooseX-Daemonize
* p5-MooseX-Getopt
* p5-MooseX-POE
https://marc.info/?l=openbsd-ports=154005860118583=2


(Catalyst and Moose are both mine, so will need to get to looking at an
update for those)

OK?

Index: Makefile
===
RCS file: /cvs/ports/devel/p5-MRO-Compat/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile20 Mar 2016 19:56:27 -  1.12
+++ Makefile21 Oct 2018 18:56:27 -
@@ -2,10 +2,10 @@
 
 COMMENT =  mro::* interface compatibility for Perl < 5.9.5
 
-DISTNAME = MRO-Compat-0.12
+DISTNAME = MRO-Compat-0.13
 CATEGORIES =   devel
 
-CPAN_AUTHOR =  BOBTFISH
+CPAN_AUTHOR =  HAARG
 
 MAINTAINER =   Andrew Fresh 
 
@@ -16,11 +16,5 @@ MODULES =cpan
 PKG_ARCH = *
 
 CONFIGURE_STYLE =  modinst
-
-RUN_DEPENDS =  devel/p5-Class-C3>=0.20
-
-# Optional depends to avoid skipping tests
-TEST_DEPENDS = devel/p5-Test-Pod \
-   devel/p5-Test-Pod-Coverage
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-MRO-Compat/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo10 May 2014 17:15:50 -  1.4
+++ distinfo21 Oct 2018 18:56:27 -
@@ -1,2 +1,2 @@
-SHA256 (MRO-Compat-0.12.tar.gz) = u6W5OGmqU3oziZSWadaC8EfTAU1TvDotcgnGgZ5QFdY=
-SIZE (MRO-Compat-0.12.tar.gz) = 24230
+SHA256 (MRO-Compat-0.13.tar.gz) = iiw7bMwZMo1VedAqfZEoXir9hdgB9J1COo6xbzI9pPg=
+SIZE (MRO-Compat-0.13.tar.gz) = 8711



[PATCH] update duplicity to 0.7.18.2

2018-10-21 Thread Henrik Friedrichsen
Hey,

I just upgrade to OpenBSD 6.4 on my server and noticed my duplicity
backup job fails.

The current port installs version 0.7.18.1, which broke remote backups
to at least SFTP locations[1]. The update to 0.7.18.2 was released to
fix this problem.

Attached is a patch to bump the port version.

I don't know the exact protocol for this, but it may be desirable to
backport this change to 6.4 STABLE.

Best regards,
Henrik
Index: Makefile
===
RCS file: /cvs/ports/sysutils/duplicity/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile	3 Sep 2018 01:16:06 -	1.48
+++ Makefile	21 Oct 2018 19:03:29 -
@@ -5,7 +5,7 @@
 
 COMMENT =	encrypted backup using rsync algorithm
 
-MODPY_EGG_VERSION = 0.7.18.1
+MODPY_EGG_VERSION = 0.7.18.2
 DISTNAME =	duplicity-${MODPY_EGG_VERSION}
 
 CATEGORIES =	sysutils
Index: distinfo
===
RCS file: /cvs/ports/sysutils/duplicity/distinfo,v
retrieving revision 1.30
diff -u -p -r1.30 distinfo
--- distinfo	3 Sep 2018 01:16:06 -	1.30
+++ distinfo	21 Oct 2018 19:03:29 -
@@ -1,2 +1,2 @@
-SHA256 (duplicity-0.7.18.1.tar.gz) = yTUBntlT5HZ9+NOXZcTdQRmHCaFGaOgj4unj4gcQgJ0=
-SIZE (duplicity-0.7.18.1.tar.gz) = 1726064
+SHA256 (duplicity-0.7.18.2.tar.gz) = wjaIj0MSjpbNMwF7AaKFXA4kc4GV/tXK2tCMKP1rZ0g=
+SIZE (duplicity-0.7.18.2.tar.gz) = 1726157


devel/sdl2: fix for macppc init crash

2018-10-21 Thread Thomas Frohwein
Hi,

George Koehler ( kernigh () gmail DOT com ) reports that all devel/sdl2 crash
on init on macppc. The reason seems to be an inappropriate bool type. The patch
below for SDL_x11keyboard.c fixes the issue according to George. This has been
merged by upstream along with another change to the types for
XkbSetDetectableAutoRepeat.

The diff below includes both patches, along with formatting of the Makefile to
align it with more commonly used formatting (space before '='). While this may
be harder to review, the Makefile only contains REVISION bump and a change of
MAINTAINER email address.

I tested sdl2 with these changes on amd64 with cataclysm-dda, milkytracker,
citra, dolphin, endless-sky. All of them run on brief testing without issues.

ok to import?

Index: Makefile
===
RCS file: /cvs/ports/devel/sdl2/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile4 Sep 2018 12:46:11 -   1.22
+++ Makefile21 Oct 2018 18:11:03 -
@@ -1,52 +1,52 @@
 # $OpenBSD: Makefile,v 1.22 2018/09/04 12:46:11 espie Exp $
 
-COMMENT=   cross-platform multimedia library
-BROKEN-hppa=   src/atomic/SDL_spinlock.c:101:2: error: \
+COMMENT =  cross-platform multimedia library
+BROKEN-hppa =  src/atomic/SDL_spinlock.c:101:2: error: \
#error Please implement for your platform.
 
-V= 2.0.8
-DISTNAME=  SDL2-${V}
-PKGNAME=   sdl2-${V}
-CATEGORIES=devel
-MASTER_SITES=  https://www.libsdl.org/release/
-REVISION=  0
+V =2.0.8
+DISTNAME = SDL2-${V}
+PKGNAME =  sdl2-${V}
+CATEGORIES =   devel
+MASTER_SITES = https://www.libsdl.org/release/
+REVISION = 1
 
-SHARED_LIBS=   SDL20.5 # 0.8
+SHARED_LIBS =  SDL20.5 # 0.8
 
-HOMEPAGE=  https://www.libsdl.org/
+HOMEPAGE = https://www.libsdl.org/
 
-MAINTAINER=Thomas Frohwein 
+MAINTAINER =   Thomas Frohwein 
 
 # zlib
-PERMIT_PACKAGE_CDROM=  Yes
+PERMIT_PACKAGE_CDROM = Yes
 
-WANTLIB=   m pthread sndio usbhid samplerate
+WANTLIB += m pthread sndio usbhid samplerate
 # GL/X11/Xext/Xrender/Xrandr are dlopen'd by SDL
-WANTLIB+=   GL X11 Xau Xdmcp Xext Xrandr Xrender xcb
+WANTLIB += GL X11 Xau Xdmcp Xext Xrandr Xrender xcb
 
-LIB_DEPENDS=   audio/libsamplerate
+LIB_DEPENDS =  audio/libsamplerate
 
-USE_GMAKE= Yes
-SEPARATE_BUILD=Yes
-CONFIGURE_STYLE=   gnu
-MODGNU_CONFIG_GUESS_DIRS=  ${WRKSRC} ${WRKSRC}/build-scripts
-CONFIGURE_ENV+=CPPFLAGS="-I${LOCALBASE}/include" \
-   LDFLAGS="-L${LOCALBASE}/lib"
-
-CONFIGURE_ARGS+= --disable-alsa \
---disable-arts \
---disable-dbus \
---disable-esd \
---disable-ibus \
---disable-jack \
---disable-libudev \
---disable-nas \
---disable-oss \
---disable-pulseaudio
+USE_GMAKE =Yes
+SEPARATE_BUILD =   Yes
+CONFIGURE_STYLE =  gnu
+MODGNU_CONFIG_GUESS_DIRS = ${WRKSRC} ${WRKSRC}/build-scripts
+CONFIGURE_ENV +=   CPPFLAGS="-I${LOCALBASE}/include" \
+   LDFLAGS="-L${LOCALBASE}/lib"
+
+CONFIGURE_ARGS +=  --disable-alsa \
+   --disable-arts \
+   --disable-dbus \
+   --disable-esd \
+   --disable-ibus \
+   --disable-jack \
+   --disable-libudev \
+   --disable-nas \
+   --disable-oss \
+   --disable-pulseaudio
 # in case devel/usb is installed, don't pick it up.
-CONFIGURE_ENV+= ac_cv_lib_usb_hid_init=no \
-   ac_cv_header_usb_h=no
+CONFIGURE_ENV +=   ac_cv_lib_usb_hid_init=no \
+   ac_cv_header_usb_h=no
 
-NO_TEST=   Yes
+NO_TEST =  Yes
 
 .include 
Index: patches/patch-src_video_x11_SDL_x11keyboard_c
===
RCS file: patches/patch-src_video_x11_SDL_x11keyboard_c
diff -N patches/patch-src_video_x11_SDL_x11keyboard_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_video_x11_SDL_x11keyboard_c   21 Oct 2018 18:11:03 
-
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+fix incorrect function signature that breaks macppc platform (likely any big
+endian platform): "stack overflow in function X11_InitKeyboard"
+included in upstream changeset 9dd351b26dcb (future versions)
+
+Index: src/video/x11/SDL_x11keyboard.c
+--- src/video/x11/SDL_x11keyboard.c.orig
 src/video/x11/SDL_x11keyboard.c
+@@ -266,7 +266,9 @@ X11_InitKeyboard(_THIS)
+ int best_distance;
+ int best_index;
+ int distance;
+-BOOL xkb_repeat = 0;
++Bool xkb_repeat = 0;
+ 
+ X11_XAutoRepeatOn(data->display);
+ 
Index: patches/patch-src_video_x11_SDL_x11sym_h

Re: UPDATE: KDE5

2018-10-21 Thread Landry Breuil
On Sun, Oct 21, 2018 at 06:05:20PM +0200, Rafael Sadowski wrote:
> On Fri Oct 19, 2018 at 07:07:45AM +0200, Landry Breuil wrote:
> > On Wed, Oct 17, 2018 at 11:20:07PM +0200, Landry Breuil wrote:
> > > On Tue, Oct 16, 2018 at 09:42:34PM +0200, Rafael Sadowski wrote:
> > > > Hi All.
> > > > 
> > > > please find below a diff to rule them all.
> > > > 
> > > > - Update KDE Frameworks to 5.51.0
> > > > -- Change examples handling and use @sample for all of them. Idea by
> > > >ajacoutot@. Discussed with ajacoutot@,sthen@,naddy@.
> > > > 
> > > > - Update our KDE Applications to 18.08.2.
> > > > -- Nothing special except okteta. They use there own version pattern
> > > >now. That's why I set EPOCH.
> > > > 
> > > > - Update all devel/kf5 consumers there are effected by the update.
> > > 
> > > Will put it in my next bulk.
> 
> Thanks a lot!
> 
> > - missing REVISION bump on libkface
> 
> Why? libkface is KDE4.

Well, PLISTDB complained that its PLIST changed wrt depends:

-@depend graphics/opencv,-main:opencv-*:opencv-2.4.13
-@depend lang/gcc/4.9,-libs:gcc-libs->=4.9,<4.10:gcc-libs-4.9.4p4
-@depend x11/kde4/libs,-main:kdelibs->=4.14,<5:kdelibs-4.14.10p7
-@depend x11/qt4,-main:qt4-*:qt4-4.8.7p11
+@depend graphics/opencv,-main:opencv-*:opencv-2.4.13.4p0
+@depend x11/kde4/libs,-main:kdelibs->=4.14,<5:kdelibs-4.14.10p15
+@depend x11/qt4,-main:qt4-*:qt4-4.8.7p17

*shrug*

afaict, your diff removes REVISION and HOMEPAGE, and it seems
x11/kde-applications/libkface doesnt follow whatever version is globally
set in this subdir, as its version is libkface-15.08.3.

> > - /bin/sh: python: not found in qtcreator (already fixed in cvs)
> > -Error:
> 
> The changes below have no effect on qtcreator.
> 
> > /usr/obj/ports/krita-4.1.3/fake-amd64/usr/local/share/examples/xdg/kritarc
> > does not exist in krita
> > 
> 
> Thanks for the hint. New diff bewlow (Without phonon-4.10.1 bits --
> sorry for that)

More issues as dpb crashes and goes..:

konsole fails with:
  Could NOT find KF5 (missing: NewStuff NewStuffCore) (found suitable version   
"5.51.0", minimum required is "5.6.0")

calligra failed with the same error as krita:
Error: 
/usr/obj/mfs/calligra-3.1.0/fake-amd64/usr/local/share/examples/xdg/calligra_stencils.knsrc
 does not exist
Error: 
/usr/obj/mfs/calligra-3.1.0/fake-amd64/usr/local/share/examples/xdg/calligrasheetsrc
 does not exist
Error: 
/usr/obj/mfs/calligra-3.1.0/fake-amd64/usr/local/share/examples/xdg/calligrastagerc
 does not exist
Error: 
/usr/obj/mfs/calligra-3.1.0/fake-amd64/usr/local/share/examples/xdg/calligrawordsrc
 does not exist
Error: 
/usr/obj/mfs/calligra-3.1.0/fake-amd64/usr/local/share/examples/xdg/karbonrc 
does not exist

Landry



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Marc Espie
CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/10/21 10:14:47

Modified files:
math   : Makefile 

Log message:
link armadillo to the build



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Marc Espie
CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/10/21 10:13:58

Log message:
Armadillo is a linear algebra library (matrix maths) for the C++ language,
aiming towards a good balance between speed and ease of use.

Provides high-level syntax and functionality deliberately similar to Matlab

(dependency for mlpack)

okay jca@

Status:

Vendor Tag: espie
Release Tags:   espie_20181021

N ports/math/armadillo/distinfo
N ports/math/armadillo/Makefile
N ports/math/armadillo/pkg/PLIST
N ports/math/armadillo/pkg/DESCR
N ports/math/armadillo/patches/patch-CMakeLists_txt

No conflicts created by this import



Re: UPDATE: devel/cmake (i386 build wanted)

2018-10-21 Thread Rafael Sadowski
On Sat Oct 20, 2018 at 10:56:35PM +0200, Rafael Sadowski wrote:
> Hi All.
> 
> Please find below diff to update cmake to the latest stable version. The
> last time it failed on i386 so it would be great if someone could build
> it on i386 and report to me/ports@. Please ignore the wrong CVS tags,
> the diff based on an old diff from sthen@.
> 
> Rafael Sadowski
> 

Successful i386 build by Charlene Wendling and Jan Vlach. Thanks! The
following tests failed on amd64:

28 - FindModulesExecuteAll (Failed)
230 - Java.Javah (Failed)
253 - CMakeOnly.AllFindModules (Failed)
399 - RunCMake.install (Failed)

New in cmake 3.12.2:
231 - Java.NativeHeaders (Failed)

We still have to work on this.

New clean diff below:

Index: Makefile
===
RCS file: /cvs/ports/devel/cmake/Makefile,v
retrieving revision 1.171
diff -u -p -u -p -r1.171 Makefile
--- Makefile13 Jul 2018 03:00:16 -  1.171
+++ Makefile21 Oct 2018 09:57:28 -
@@ -4,9 +4,8 @@ DPB_PROPERTIES =parallel
 
 COMMENT =  portable build system
 
-VER =  3.10.2
+VER =  3.12.2
 EPOCH =0
-REVISION = 0
 DISTNAME = cmake-${VER}
 CATEGORIES =   devel
 
Index: distinfo
===
RCS file: /cvs/ports/devel/cmake/distinfo,v
retrieving revision 1.53
diff -u -p -u -p -r1.53 distinfo
--- distinfo14 Jun 2018 17:04:45 -  1.53
+++ distinfo21 Oct 2018 09:57:28 -
@@ -1,2 +1,2 @@
-SHA256 (cmake-3.10.2.tar.gz) = gND6rUq1beB6ohp/xpLIjEzmFW1CsFecaWIASnCjIYs=
-SIZE (cmake-3.10.2.tar.gz) = 7824452
+SHA256 (cmake-3.12.2.tar.gz) = D5dIV5nlGnBwzBFJTz4CNJsPw6JMwSsILnN79noFgaQ=
+SIZE (cmake-3.12.2.tar.gz) = 8388114
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/devel/cmake/patches/patch-CMakeLists_txt,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt14 Jun 2018 17:04:45 -  1.26
+++ patches/patch-CMakeLists_txt21 Oct 2018 09:57:28 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-CMakeLists_txt,v 1.26 20
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -317,6 +317,15 @@ macro (CMAKE_BUILD_UTILITIES)
+@@ -337,6 +337,15 @@ macro (CMAKE_BUILD_UTILITIES)
  CMAKE_SET_TARGET_FOLDER(${KWSYS_NAMESPACE}TestSharedForward 
"${kwsys_folder}")
endif()
  
@@ -18,7 +18,7 @@ Index: CMakeLists.txt
#-
# Setup third-party libraries.
# Everything in the tree should be able to include files from the
-@@ -350,7 +359,8 @@ macro (CMAKE_BUILD_UTILITIES)
+@@ -370,7 +379,8 @@ macro (CMAKE_BUILD_UTILITIES)
message(FATAL_ERROR
  "CMAKE_USE_SYSTEM_LIBRHASH is ON but LibRHash is not found!")
  endif()
@@ -28,7 +28,7 @@ Index: CMakeLists.txt
else()
  set(CMAKE_LIBRHASH_LIBRARIES cmlibrhash)
  add_subdirectory(Utilities/cmlibrhash)
-@@ -516,7 +526,8 @@ macro (CMAKE_BUILD_UTILITIES)
+@@ -536,7 +546,8 @@ macro (CMAKE_BUILD_UTILITIES)
message(FATAL_ERROR
  "CMAKE_USE_SYSTEM_JSONCPP is ON but a JsonCpp is not found!")
  endif()
@@ -38,7 +38,7 @@ Index: CMakeLists.txt
else()
  set(CMAKE_JSONCPP_LIBRARIES cmjsoncpp)
  add_subdirectory(Utilities/cmjsoncpp)
-@@ -531,7 +542,8 @@ macro (CMAKE_BUILD_UTILITIES)
+@@ -551,7 +562,8 @@ macro (CMAKE_BUILD_UTILITIES)
message(FATAL_ERROR
  "CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!")
  endif()
Index: patches/patch-Modules_CMakeCInformation_cmake
===
RCS file: /cvs/ports/devel/cmake/patches/patch-Modules_CMakeCInformation_cmake,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 patch-Modules_CMakeCInformation_cmake
--- patches/patch-Modules_CMakeCInformation_cmake   14 Jun 2018 17:04:45 
-  1.8
+++ patches/patch-Modules_CMakeCInformation_cmake   21 Oct 2018 09:57:28 
-
@@ -2,7 +2,7 @@ $OpenBSD: patch-Modules_CMakeCInformatio
 Index: Modules/CMakeCInformation.cmake
 --- Modules/CMakeCInformation.cmake.orig
 +++ Modules/CMakeCInformation.cmake
-@@ -165,7 +165,7 @@ include(CMakeCommonLanguageInclude)
+@@ -142,7 +142,7 @@ include(CMakeCommonLanguageInclude)
  # create a C shared library
  if(NOT CMAKE_C_CREATE_SHARED_LIBRARY)
set(CMAKE_C_CREATE_SHARED_LIBRARY
Index: patches/patch-Modules_CMakeCXXInformation_cmake
===
RCS file: 
/cvs/ports/devel/cmake/patches/patch-Modules_CMakeCXXInformation_cmake,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 patch-Modules_CMakeCXXInformation_cmake
--- patches/patch-Modules_CMakeCXXInformation_cmake 14 Jun 2018 17:04:45 
-  1.7
+++ patches/patch-Modules_CMakeCXXInformation_cmake 21 Oct 2018 09:57:28 
-
@@ -1,6 +1,7 @@
 $OpenBSD: 

Re: NEW: math/mlpack (and dependency math/armadillo)

2018-10-21 Thread Jeremie Courreges-Anglas
On Sun, Oct 21 2018, Marc Espie  wrote:
> Here's a revised version of the armadillo port, adding arpack and hdf5
> as a dependency.
>
> And the missed COMPILER line, oops.
>
> Notes:
> - I definitely prefer to be explicit for CONFIGURE_STYLE

grep says that most ports rely on the cmake module setting up
CONFIGURE_STYLE.  Just sayin'...

> - with arpack added, no need for explicit depends on blas/lapack,
> as arpack needs them anyway.

Not sure what's the point of trimming the list of deps, especially as
armadillo explicitely references code from blas, lapack and arpack.
I don't think it makes maintenance any easier, rather the opposite.
That said...

I like this updated version, ok jca@

Regarding libgfortran,

> - the library definitely requires linking with the gfortran library
> because some of lapack blas want symbols in there

Yeah I see.  IIUC blas, apack and arpack don't register the dep on
libgfortran because of a build system quirk (linking is done with with
cc instead of gfortran).  A simple diff like below would register the
dep on libgfortran, and remove the need for patch-CMakeLists_txt.

cc'ing steven@ (maintainer)

Thoughts, ok?


Index: blas/Makefile
===
RCS file: /cvs/ports/math/blas/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- blas/Makefile   13 Nov 2017 06:56:38 -  1.27
+++ blas/Makefile   21 Oct 2018 14:31:16 -
@@ -4,6 +4,7 @@ COMMENT=Basic Linear Algebra Subprogram
 
 VERSION=   3.7.1
 DISTNAME=  blas-${VERSION}
+REVISION=  0
 
 SHARED_LIBS=   blas2.1
 
Index: blas/files/Makefile
===
RCS file: /cvs/ports/math/blas/files/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- blas/files/Makefile 13 Nov 2017 06:56:38 -  1.3
+++ blas/files/Makefile 21 Oct 2018 14:31:16 -
@@ -25,6 +25,7 @@ SRCS =caxpy.f  ccopy.f  cdotc.f  cdotu.
zhpmv.f  zhpr.f   zhpr2.f  zrotg.f  zscal.f  zswap.f  zsymm.f   \
zsyr2k.f zsyrk.f  ztbmv.f  ztbsv.f  ztpmv.f  ztpsv.f  ztrmm.f   \
ztrmv.f  ztrsm.f  ztrsv.f  xerbla_array.f
+LDADD = -lgfortran
 
 printsrc:
@echo ${SRCS}
Index: lapack/Makefile
===
RCS file: /cvs/ports/math/lapack/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- lapack/Makefile 13 Nov 2017 06:57:36 -  1.26
+++ lapack/Makefile 21 Oct 2018 14:31:16 -
@@ -4,6 +4,7 @@ COMMENT=library of Fortran linear algeb
 
 VERSION=   3.7.1
 DISTNAME=  lapack-${VERSION}
+REVISION=  0
 
 SHARED_LIBS=   lapack 6.0
 
Index: lapack/files/Makefile
===
RCS file: /cvs/ports/math/lapack/files/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- lapack/files/Makefile   13 Nov 2017 06:57:36 -  1.7
+++ lapack/files/Makefile   21 Oct 2018 14:31:53 -
@@ -384,6 +384,7 @@ ZLASRC = \
 
 SRCS=${SLASRC} ${DLASRC} ${DSLASRC} ${CLASRC} ${ZLASRC} ${ZCLASRC} \
${SCLAUX} ${DZLAUX} ${ALLAUX}
+LDADD= -lgfortran
 
 printsrc:
@echo ${SRCS}
Index: arpack/Makefile
===
RCS file: /cvs/ports/math/arpack/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- arpack/Makefile 13 Nov 2017 07:09:06 -  1.16
+++ arpack/Makefile 21 Oct 2018 14:31:16 -
@@ -4,7 +4,7 @@ COMMENT=solve large scale eigenvalue pr
 
 DISTNAME=  arpack96
 PKGNAME=   arpack-96
-REVISION=  5
+REVISION=  6
 SHARED_LIBS=   arpack 1.0
 CATEGORIES=math
 
Index: arpack/files/Makefile
===
RCS file: /cvs/ports/math/arpack/files/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- arpack/files/Makefile   19 Oct 2006 16:19:54 -  1.1.1.1
+++ arpack/files/Makefile   21 Oct 2018 14:31:16 -
@@ -18,5 +18,6 @@ SRCS= sgetv0.f slaqrb.f sstqrb.f ssortc.
 zgetv0.f zsortc.f zstatn.f \
zvout.f zmout.f \
icnteq.f icopy.f iset.f iswap.f ivout.f second.f
+LDADD= -lgfortran
 
 .include 


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: chrooting package build process possible?

2018-10-21 Thread Edward Lopez-Acosta
Thanks Marc I will check those out. And I port new and updated 
applications as there are missing or outdated packages for my needs.


On 2018-10-21 10:05, Marc Espie wrote:

On Sun, Oct 21, 2018 at 09:50:24AM -0500, Edward Lopez-Acosta wrote:

I have noticed that when building packages I am required to install
dependencies globally which leads to a messy system if I don't remember to
remove them. This is an issue when building ports that may not be installed
on the same system.


RTFM,
See proot(1) and dpb(1) and bulk(8)

Why do you build packages yourself, btw ?  It takes time and space, and
you can just use the trusted binary packages unless you have very good
reasons to avoid them.


Is it possible to somehow have the make process use a chroot and avoid
installing packages globally? Slight tangent, but why do pkg_add/pkg_delete
not prompt to confirm before taking actions which to me would make much more
sense than just doing the action right away.


This is Unix. Commands do stuff by default.   Observe rm. By default, it
removes files.





Re: chrooting package build process possible?

2018-10-21 Thread Marc Espie
On Sun, Oct 21, 2018 at 09:50:24AM -0500, Edward Lopez-Acosta wrote:
> I have noticed that when building packages I am required to install
> dependencies globally which leads to a messy system if I don't remember to
> remove them. This is an issue when building ports that may not be installed
> on the same system.

RTFM,
See proot(1) and dpb(1) and bulk(8)

Why do you build packages yourself, btw ?  It takes time and space, and
you can just use the trusted binary packages unless you have very good
reasons to avoid them.

> Is it possible to somehow have the make process use a chroot and avoid
> installing packages globally? Slight tangent, but why do pkg_add/pkg_delete
> not prompt to confirm before taking actions which to me would make much more
> sense than just doing the action right away.

This is Unix. Commands do stuff by default.   Observe rm. By default, it
removes files.



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Marc Espie
CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/10/21 08:57:55

Modified files:
databases/sqlports/files: TreeWalker.pm 

Log message:
make sure we don't catch SUBDIRLIST on later calls



chrooting package build process possible?

2018-10-21 Thread Edward Lopez-Acosta
I have noticed that when building packages I am required to install 
dependencies globally which leads to a messy system if I don't remember 
to remove them. This is an issue when building ports that may not be 
installed on the same system.


Is it possible to somehow have the make process use a chroot and avoid 
installing packages globally? Slight tangent, but why do 
pkg_add/pkg_delete not prompt to confirm before taking actions which to 
me would make much more sense than just doing the action right away.


Thank you.



Re: UPDATE: net/onionshare

2018-10-21 Thread fredl


On 10/21/18 1:51 PM, Grégoire Jadi wrote:

fredl  writes:


Hey,

Hello,

Both cli and -gui works on amd64.


Hey,

thanks for your feedback!



Thanks for the update. I think you need to drop the REVISION-gui (but
I'm just a port-newb).

You are right, please find the new diff attached to this mail!

--
fredl

Index: Makefile
===
RCS file: /cvs/ports/net/onionshare/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile27 Jun 2018 21:04:00 -  1.2
+++ Makefile21 Oct 2018 13:25:00 -
@@ -6,11 +6,10 @@ COMMENT-gui = graphical user interface 
 GH_ACCOUNT =   micahflee
 GH_PROJECT =   onionshare
 GH_TAGNAME =   v${MODPY_EGG_VERSION}
-MODPY_EGG_VERSION =1.3
+MODPY_EGG_VERSION =1.3.1
 
 PKGNAME-main = onionshare-${MODPY_EGG_VERSION}
 PKGNAME-gui =  onionshare-gui-${MODPY_EGG_VERSION}
-REVISION-gui = 0
 
 CATEGORIES =   net
 
@@ -37,5 +36,15 @@ RUN_DEPENDS-gui =${RUN_DEPENDS} \
 
 # XXX: not yet working
 NO_TEST =  Yes
+
+DOCDIR=${PREFIX}/share/doc/onionshare
+LICENSEDIR=${WRKSRC}/install/licenses
+
+post-install:
+   ${INSTALL_DATA_DIR} ${DOCDIR}
+   ${INSTALL_DATA} ${LICENSEDIR}/license-obfs4.txt ${DOCDIR}
+   ${INSTALL_DATA} ${LICENSEDIR}/license-onionshare.txt ${DOCDIR}
+   ${INSTALL_DATA} ${LICENSEDIR}/license-tor.txt ${DOCDIR}
+   ${INSTALL_DATA} ${WRKSRC}/README.md ${DOCDIR}
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/net/onionshare/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo9 Mar 2018 23:36:42 -   1.1.1.1
+++ distinfo21 Oct 2018 13:25:00 -
@@ -1,2 +1,2 @@
-SHA256 (onionshare-1.3.tar.gz) = AIkUctiW5AWg9y36jq+D2uyj3DG+Uz1uLIbyxTkUz+0=
-SIZE (onionshare-1.3.tar.gz) = 431352
+SHA256 (onionshare-1.3.1.tar.gz) = h+H6llSCBk6MfIvDIyb1dI/QOPfSr29RBWRE2yLvA1c=
+SIZE (onionshare-1.3.1.tar.gz) = 436741
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/net/onionshare/pkg/PLIST-main,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST-main
--- pkg/PLIST-main  9 Mar 2018 23:36:42 -   1.1.1.1
+++ pkg/PLIST-main  21 Oct 2018 13:25:00 -
@@ -20,6 +20,11 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/onionshare/strings.py
 lib/python${MODPY_VERSION}/site-packages/onionshare/web.py
 share/applications/
+share/doc/onionshare/
+share/doc/onionshare/README.md
+share/doc/onionshare/license-obfs4.txt
+share/doc/onionshare/license-onionshare.txt
+share/doc/onionshare/license-tor.txt
 share/onionshare/
 share/onionshare/html/
 share/onionshare/html/404.html
@@ -42,7 +47,6 @@ share/onionshare/images/server_working.p
 share/onionshare/images/settings.png
 share/onionshare/images/web_file.png
 share/onionshare/images/web_folder.png
-share/onionshare/license.txt
 share/onionshare/locale/
 share/onionshare/locale/cs.json
 share/onionshare/locale/da.json


CVS: cvs.openbsd.org: ports

2018-10-21 Thread Edd Barrett
CVSROOT:/cvs
Module name:ports
Changes by: e...@cvs.openbsd.org2018/10/21 07:29:48

Modified files:
lang/pypy  : Makefile distinfo 
lang/pypy/patches: 
   patch-rpython_jit_backend_x86_detect_feature_py 
   patch-rpython_rlib_rmmap_py 
lang/pypy/pkg  : PLIST 
Removed files:
lang/pypy/patches: patch-ctypes_configure_cbuild_py 

Log message:
Update lang/pypy to 6.0.0.

Thanks to David Carlier for his alloc_noexec patch.

Tested and OK'd by naddy@. Thanks

Naddy also reports that this fixes the build with lld!



Re: update: telephony/baresip

2018-10-21 Thread Sebastien Marie
On Sun, Oct 21, 2018 at 02:55:31PM +0200, Klemens Nanni wrote:
> On Fri, Oct 19, 2018 at 02:13:08PM +0200, Sebastien Marie wrote:
> > - telephony/baresip/baresip 0.5.10->0.5.11
> > 
> >   ChangeLog: https://github.com/alfredh/baresip/blob/master/docs/ChangeLog
> 0.5.11 depends on rem>=5.3 as per the changelog.  OK kn if anyone wants
> to commit this with the minimal version bumped in LIB_DEPENDS-main,
> otherwise I'll do so next week unless I hear objections.

yes, 0.5.11 depens on rem>=5.3, but as 0.5.10.

I think porters has enough work to avoid such extra dependencies
requirements if it serves to nothing. I doubt we want to support
partially updated port tree package build.

just my 2 cents.
-- 
Sebastien Marie



Re: UPDATE: net/onionshare

2018-10-21 Thread Grégoire Jadi
fredl  writes:

> Hey,

Hello,

Both cli and -gui works on amd64.

Thanks for the update. I think you need to drop the REVISION-gui (but
I'm just a port-newb).

Best,

> attached is a update for net/onionshare. It updates onionshare to
> version 1.3.1. (Changes:
> https://github.com/micahflee/onionshare/releases/tag/v1.3.1)
>
> + license and readme.md files added.
>
> --
> fredl



Re: update: telephony/baresip

2018-10-21 Thread Klemens Nanni
On Fri, Oct 19, 2018 at 02:13:08PM +0200, Sebastien Marie wrote:
> - telephony/baresip/baresip 0.5.10->0.5.11
> 
>   ChangeLog: https://github.com/alfredh/baresip/blob/master/docs/ChangeLog
0.5.11 depends on rem>=5.3 as per the changelog.  OK kn if anyone wants
to commit this with the minimal version bumped in LIB_DEPENDS-main,
otherwise I'll do so next week unless I hear objections.



Re: Is sysutils/memtest86+ still useful?

2018-10-21 Thread Klemens Nanni
On Sun, Oct 21, 2018 at 01:22:52PM +0200, Christian Weisgerber wrote:
> Is the sysutils/memtest86+ port still useful?
I doubt it.

> Our version dates from 2011, but even the newest one listed on the
> home page is from 2013.  I tried to run memtest as built by our
> port on my Thinkpad X230 (ca. 2012), but it just crashes.  Does it
> still run on any machines of recent vintage?
You can download bootable images from their website as well.

memtest-4.20p3 does not work through `boot memtest' on a X250 with stock
firmware but just prints "entry point at 0x1000" and leaving the system
in a halted state.

On my machines MemTest86+ 5.01 is either built as coreboot payload or
UEFI executable and works just fine.

> The port does not build with ld.lld.  I have a diff to fix that,
> but I don't know if it produces a working executable.  However,
> that's pointless if even the one built with ld.bfd doesn't work.
I consider our port useless and defunct so OK kn to remove it.



Re: UPDATE: devel/cmake (i386 build wanted)

2018-10-21 Thread Jan Vlach
On Sat, Oct 20, 2018 at 10:56:35PM +0200, Rafael Sadowski wrote:
> Hi All.
> 
> Please find below diff to update cmake to the latest stable version. The
> last time it failed on i386 so it would be great if someone could build
> it on i386 and report to me/ports@. Please ignore the wrong CVS tags,
> the diff based on an old diff from sthen@.
> 
> Rafael Sadowski

Hi Rafael,

Builds fine on 6.4-current i386 running in VMM VM on 6.4-current amd64.
Tomorrow I will have access to real i386 laptop with Pentium 4. I could
test there too.

Have build libmusicbrainz and colobot packages that seem to use/require
cmake.

Jan



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/10/21 06:11:25

Modified files:
sysutils/py-pynetbox: Makefile distinfo 

Log message:
update to py-pynetbox-3.4.7



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/10/21 06:11:32

Modified files:
sysutils/rclone: Makefile distinfo 

Log message:
update to rclone-1.44



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/10/21 06:09:04

Modified files:
textproc/py-pygfm: Makefile distinfo 

Log message:
update to py-gfm-0.1.4



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/10/21 06:07:30

Modified files:
x11/i3lock : Makefile distinfo 
Added files:
x11/i3lock/patches: patch-Makefile_in patch-configure_ac 

Log message:
update to i3lock-2.11.1



Re: Is sysutils/memtest86+ still useful?

2018-10-21 Thread Claudio Jeker
On Sun, Oct 21, 2018 at 01:22:52PM +0200, Christian Weisgerber wrote:
> Is the sysutils/memtest86+ port still useful?
> 
> Our version dates from 2011, but even the newest one listed on the
> home page is from 2013.  I tried to run memtest as built by our
> port on my Thinkpad X230 (ca. 2012), but it just crashes.  Does it
> still run on any machines of recent vintage?
> 
> The port does not build with ld.lld.  I have a diff to fix that,
> but I don't know if it produces a working executable.  However,
> that's pointless if even the one built with ld.bfd doesn't work.
> 

I normaly use a bootable USB stick that comes with a memtest utility and
never used the port.

-- 
:wq Claudio



Re: Is sysutils/memtest86+ still useful?

2018-10-21 Thread Theo Buehler
On Sun, Oct 21, 2018 at 01:22:52PM +0200, Christian Weisgerber wrote:
> I tried to run memtest as built by our port on my Thinkpad X230 (ca.
> 2012), but it just crashes.  Does it still run on any machines of
> recent vintage?

On my x280, the screen goes dark, displays "Entry point 0x1" and
stays there.



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Mark Kettenis
CVSROOT:/cvs
Module name:ports
Changes by: kette...@cvs.openbsd.org2018/10/21 05:31:23

Modified files:
sysutils/arm-trusted-firmware: Makefile distinfo 

Log message:
update to ARM Trusted Firmware 2.0

Includes changes (already in 1.6) for the following advisory:

Trusted Firmware A Security Advisory TFV 7
Trusted Firmware-A exposure to cache speculation vulnerability Variant 4

tested on rk3399
ok jsg@



Is sysutils/memtest86+ still useful?

2018-10-21 Thread Christian Weisgerber
Is the sysutils/memtest86+ port still useful?

Our version dates from 2011, but even the newest one listed on the
home page is from 2013.  I tried to run memtest as built by our
port on my Thinkpad X230 (ca. 2012), but it just crashes.  Does it
still run on any machines of recent vintage?

The port does not build with ld.lld.  I have a diff to fix that,
but I don't know if it produces a working executable.  However,
that's pointless if even the one built with ld.bfd doesn't work.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: update sysutils/arm-trusted-firmware to 1.6

2018-10-21 Thread Jonathan Gray
On Sun, Oct 21, 2018 at 01:08:47PM +0200, Mark Kettenis wrote:
> > Date: Sun, 21 Oct 2018 11:24:01 +1100
> > From: Jonathan Gray 
> > 
> > On Sat, Oct 20, 2018 at 11:42:56PM +0200, Mark Kettenis wrote:
> > > > Date: Sun, 23 Sep 2018 23:15:44 +1000
> > > > From: Jonathan Gray 
> > > > 
> > > > Update to 1.6 and build the newly added a64/h5 platform support that can
> > > > hopefully replace the atf-allwinner port.
> > > > 
> > > > Only compile tested for lack of hardware.
> > > 
> > > FWIW, I've now also tested rk3399.  So I think you should go ahead and
> > > commit this.
> > > 
> > > ok kettenis@
> > 
> > Thanks, committed.
> > 
> > There is now a 2.0 release but that only seems to be concerned with removing
> > deprecated apis.
> > 
> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/change-log.rst#trusted-firmware-a-version-2-0
> > 
> > So we might as well wait till the next one, which should include more
> > allwinner bits
> > 
> > https://github.com/ARM-software/arm-trusted-firmware/pull/1633
> > 
> > 'This updates the Allwinner port to do some cleanups and minor
> > improvements, also adding PMIC and proper SYSTEM_OFF and CPU_OFF support
> > to bring it eventually on par (and beyond) the existing "legacy" ATF
> > port,'
> 
> Well, since they deprecated some interfaces in 2.0 and rk3399 is one
> of the affected platforms I decided to test 2.0 anyway.  The diff is
> trivial, so we might as well go for it.
> 
> ok?
> 

sure, ok jsg@

> 
> 
> Index: sysutils/arm-trusted-firmware/Makefile
> ===
> RCS file: /cvs/ports/sysutils/arm-trusted-firmware/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- sysutils/arm-trusted-firmware/Makefile21 Oct 2018 00:13:54 -  
> 1.6
> +++ sysutils/arm-trusted-firmware/Makefile21 Oct 2018 11:01:49 -
> @@ -6,7 +6,7 @@ COMMENT=  ARM Trusted Firmware
>  
>  GH_ACCOUNT=  ARM-software
>  GH_PROJECT=  arm-trusted-firmware
> -GH_TAGNAME=  v1.6
> +GH_TAGNAME=  v2.0
>  
>  CATEGORIES=  sysutils
>  
> Index: sysutils/arm-trusted-firmware/distinfo
> ===
> RCS file: /cvs/ports/sysutils/arm-trusted-firmware/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- sysutils/arm-trusted-firmware/distinfo21 Oct 2018 00:13:54 -  
> 1.3
> +++ sysutils/arm-trusted-firmware/distinfo21 Oct 2018 11:01:49 -
> @@ -1,2 +1,2 @@
> -SHA256 (arm-trusted-firmware-1.6.tar.gz) = 
> YhIDaPIZbT4SYpbIEW8zmVaOEAlgpRIuUgF9InZrcAk=
> -SIZE (arm-trusted-firmware-1.6.tar.gz) = 3102529
> +SHA256 (arm-trusted-firmware-2.0.tar.gz) = 
> fWmaFoO7elkJ3je265G2442zLNb8WuSKCOsHGNZQSuQ=
> +SIZE (arm-trusted-firmware-2.0.tar.gz) = 3058755
> 



Re: update sysutils/arm-trusted-firmware to 1.6

2018-10-21 Thread Mark Kettenis
> Date: Sun, 21 Oct 2018 11:24:01 +1100
> From: Jonathan Gray 
> 
> On Sat, Oct 20, 2018 at 11:42:56PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 23 Sep 2018 23:15:44 +1000
> > > From: Jonathan Gray 
> > > 
> > > Update to 1.6 and build the newly added a64/h5 platform support that can
> > > hopefully replace the atf-allwinner port.
> > > 
> > > Only compile tested for lack of hardware.
> > 
> > FWIW, I've now also tested rk3399.  So I think you should go ahead and
> > commit this.
> > 
> > ok kettenis@
> 
> Thanks, committed.
> 
> There is now a 2.0 release but that only seems to be concerned with removing
> deprecated apis.
> 
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/change-log.rst#trusted-firmware-a-version-2-0
> 
> So we might as well wait till the next one, which should include more
> allwinner bits
> 
> https://github.com/ARM-software/arm-trusted-firmware/pull/1633
> 
> 'This updates the Allwinner port to do some cleanups and minor
> improvements, also adding PMIC and proper SYSTEM_OFF and CPU_OFF support
> to bring it eventually on par (and beyond) the existing "legacy" ATF
> port,'

Well, since they deprecated some interfaces in 2.0 and rk3399 is one
of the affected platforms I decided to test 2.0 anyway.  The diff is
trivial, so we might as well go for it.

ok?



Index: sysutils/arm-trusted-firmware/Makefile
===
RCS file: /cvs/ports/sysutils/arm-trusted-firmware/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- sysutils/arm-trusted-firmware/Makefile  21 Oct 2018 00:13:54 -  
1.6
+++ sysutils/arm-trusted-firmware/Makefile  21 Oct 2018 11:01:49 -
@@ -6,7 +6,7 @@ COMMENT=ARM Trusted Firmware
 
 GH_ACCOUNT=ARM-software
 GH_PROJECT=arm-trusted-firmware
-GH_TAGNAME=v1.6
+GH_TAGNAME=v2.0
 
 CATEGORIES=sysutils
 
Index: sysutils/arm-trusted-firmware/distinfo
===
RCS file: /cvs/ports/sysutils/arm-trusted-firmware/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- sysutils/arm-trusted-firmware/distinfo  21 Oct 2018 00:13:54 -  
1.3
+++ sysutils/arm-trusted-firmware/distinfo  21 Oct 2018 11:01:49 -
@@ -1,2 +1,2 @@
-SHA256 (arm-trusted-firmware-1.6.tar.gz) = 
YhIDaPIZbT4SYpbIEW8zmVaOEAlgpRIuUgF9InZrcAk=
-SIZE (arm-trusted-firmware-1.6.tar.gz) = 3102529
+SHA256 (arm-trusted-firmware-2.0.tar.gz) = 
fWmaFoO7elkJ3je265G2442zLNb8WuSKCOsHGNZQSuQ=
+SIZE (arm-trusted-firmware-2.0.tar.gz) = 3058755



Re: KDE Kate no longer works with kio-slaves

2018-10-21 Thread Rafael Sadowski
On Sun Oct 21, 2018 at 11:01:47AM +0200, Federico Giannici wrote:
> After I upgraded from OpenBSD amd64 6.3 to 6.4 my KDE Kate program is no
> longer able to open remote files (that is, to use kio-slaves).
> 
> 
> When I try to open a remote (sftp:) file it says:

KIO sftp support is no more part from base KIO. It's a part of
x11/kde-applications/kio-extras which is not portet to OpenBSD yet.

Sorry for the bad news you will have to wait for 6.5 or follow -current.

Btw HTTPS, ftp still works with base KIO.

Rafael Sadowski



KDE Kate no longer works with kio-slaves

2018-10-21 Thread Federico Giannici
After I upgraded from OpenBSD amd64 6.3 to 6.4 my KDE Kate program is no 
longer able to open remote files (that is, to use kio-slaves).



When I try to open a remote (sftp:) file it says:

	kf5.kio.core: couldn't create slave: "klauncher said: Unknown protocol 
'sftp'.\n"



I was able to open an "http:" file supplying it via command line, but 
then it says:


Non-native QFileDialog supports only local files


All other KDE programs (Dolphin, Okular, Gwenview, etc.) are still able 
to correctly open "sftp:" urls, so the kio-slaves are correctly 
installed and working.


I'd like to know if there is something bad in my system (maybe some 
missing package, or a conflict with older versions?) or it is a (very 
very important) limitation of the new Kate version.


Thanks.



CVS: cvs.openbsd.org: ports

2018-10-21 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/10/21 02:17:41

Modified files:
multimedia/mkvtoolnix: Makefile distinfo 
multimedia/mkvtoolnix/pkg: PFRAG.no-no_x11 

Log message:
Update mkvtoolnix-28.0.0



Re: NEW: math/mlpack (and dependency math/armadillo)

2018-10-21 Thread Marc Espie
Here's a revised version of the armadillo port, adding arpack and hdf5
as a dependency.

And the missed COMPILER line, oops.

Notes:
- I definitely prefer to be explicit for CONFIGURE_STYLE
- the library definitely requires linking with the gfortran library
because some of lapack blas want symbols in there
- with arpack added, no need for explicit depends on blas/lapack,
as arpack needs them anyway.


armadillo-9.100.5.tgz
Description: armadillo-9.100.5.tgz