Re: update games/taisei 1.0 -> 1.3.1

2020-02-06 Thread Benoit Lecocq




On 06/02/2020 19:14, Charlene Wendling wrote:

Ping :)


Works fine on amd64, ok benoit@



On Sun, 26 Jan 2020 19:20:17 +0100
Charlene Wendling wrote:



On Wed, 15 Jan 2020 18:10:10 +0100
Charlene Wendling wrote:


Hi,

On Wed, 15 Jan 2020 14:36:48 +0100
Omar Polo wrote:


Hi,

First time here, hoping I didn't mess up too much.


It works for you at least, so it's already nice :)

By the way, it was already in -wip --
https://github.com/jasperla/openbsd-wip/tree/master/games/taisei


The patch below
updates games/taisei from 1.0 to the latest 1.3.1 with the
followings changes:

  - use https for HOMEPAGE
  - upstream repo changed
  - dropped all the patches, they're not needed anymore
  - dependecies updated

Also [0]:
  - it breaks the runtime with amdgpu and radeondrm, and that's why i
did not propose it. But if there is popular demand, i think we
should go for it :)


I brought back my old video card on my amd64 box:

radeondrm0 at pci9 dev 0 function 0 "ATI Radeon HD 7450" rev 0x00

I wanted to correct myself, taisei works fine with radeondrm(4) and
inteldrm(4). As such, i think this update would benefit to most of
us.

I'm providing again the diff for convenience.


  - Requires OpenGL>=3.3, so works only on modern archs


Built and played on amd64, everything seems to work fine (audio
too.)


[...]

I'm proposing here the diff from -wip if someone want to test/review
it.

Charlène.


[0] https://marc.info/?l=openbsd-ports=155611903608886=2






Index: Makefile
===
RCS file: /cvs/ports/games/taisei/Makefile,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 Makefile
--- Makefile12 Jul 2019 20:46:25 -  1.6
+++ Makefile15 Jan 2020 17:01:17 -
@@ -1,33 +1,50 @@
  # $OpenBSD: Makefile,v 1.6 2019/07/12 20:46:25 sthen Exp $
  
+# Requires OpenGL>=3.3, only usable on archs that support

+# modern video cards
+ONLY_FOR_ARCHS =   amd64 aarch64 i386
+
  COMMENT = clone of the touhou games
  
-V =			1.0a

-DISTNAME = taisei-$V
-REVISION = 3
+VERSION =  v1.3.1
+DISTNAME = taisei-${VERSION}
+PKGNAME =  taisei-${VERSION:S/^v//}
  
  CATEGORIES =		games
  
-HOMEPAGE =		http://taisei-project.org/

+HOMEPAGE = https://taisei-project.org/
  
  # MIT

+# Soundtrack: CC-BY 4.0 / Photos: PD and CC-0
  PERMIT_PACKAGE =  Yes
  
-WANTLIB += GL GLU SDL SDL_ttf alut c freetype m openal png pthread

+WANTLIB += SDL2 SDL2_mixer c crypto freetype m opusfile png webpdecoder
  WANTLIB += z
  
-GH_ACCOUNT =		laochailan

-GH_PROJECT =   taisei
-GH_TAGNAME =   v$V
+MASTER_SITES=  
https://github.com/taisei-project/taisei/releases/download/${VERSION}/
+
+EXTRACT_SUFX=  .tar.xz
+
+MODULES =  devel/meson \
+   lang/python
+
+MODPY_RUNDEP = No
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
  
-CFLAGS +=	-fgnu89-inline

-MODULES =  devel/cmake
  RUN_DEPENDS = devel/desktop-file-utils \
+   misc/shared-mime-info \
x11/gtk+3,-guic
-LIB_DEPENDS =  audio/freealut \
-   audio/openal \
-   devel/sdl-ttf \
-   graphics/png
+
+LIB_DEPENDS =  audio/opusfile \
+   devel/sdl2>=2.0.5 \
+   devel/sdl2-mixer>=2.0.4 \
+   graphics/libwebp>=0.5 \
+   graphics/png>=1.5.0
+
+# Don't include docs
+# Don't zip the ressources, it avoids using archivers/libzip
+CONFIGURE_ARGS +=  -Ddocs=false \
+   -Denable_zip=false
  
  NO_TEST =		Yes
  
Index: distinfo

===
RCS file: /cvs/ports/games/taisei/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo22 Aug 2015 09:38:07 -  1.1.1.1
+++ distinfo15 Jan 2020 17:01:17 -
@@ -1,2 +1,2 @@
-SHA256 (taisei-1.0a.tar.gz) = FWHITJ/YucepG4ZL38B/uBG7baXFTPMqK2vWPeX48/8=
-SIZE (taisei-1.0a.tar.gz) = 91854864
+SHA256 (taisei-v1.3.1.tar.xz) = hlg6OnEAk+YwFKWua2glGgacslraBsb41zT4XzGtyYU=
+SIZE (taisei-v1.3.1.tar.xz) = 70763196
Index: patches/patch-src_boss_h
===
RCS file: patches/patch-src_boss_h
diff -N patches/patch-src_boss_h
--- patches/patch-src_boss_h17 May 2017 22:54:28 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-src_boss_h,v 1.1 2017/05/17 22:54:28 espie Exp $
-
-Index: src/boss.h
 src/boss.h.orig
-+++ src/boss.h
-@@ -9,6 +9,8 @@
- #define BOSS_H
-
- #include 
-+#undef complex
-+#define complex double _Complex
-
- #include 
- struct Boss;
Index: patches/patch-src_enemy_h
===
RCS file: patches/patch-src_enemy_h
diff -N 

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/02/07 00:13:40

Modified files:
security/qtkeychain: Makefile 
security/qtkeychain/pkg: PLIST 

Log message:
Set -qt5 flavor as default. All qt4 consumers are gone.

Tweak and OK kirby@



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/02/07 00:13:54

Modified files:
astro/kstars   : Makefile 
geo/qgis   : Makefile 
mail/trojita   : Makefile 
net/nextcloudclient: Makefile 
net/owncloudclient: Makefile 

Log message:
Remove -qt5 flavor from security/qtkeychain; its now the default

Tested by many, thanks!



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Remi Pointel
CVSROOT:/cvs
Module name:ports
Changes by: rpoin...@cvs.openbsd.org2020/02/06 22:50:21

Modified files:
graphics/p5-Image-ExifTool: Makefile distinfo 
graphics/p5-Image-ExifTool/pkg: PLIST 

Log message:
update exiftool to 1.85.
change the HOMEPAGE, from landry@.



UPDATE: net/profanity

2020-02-06 Thread Rafael Sadowski
Simple update to the latest stable version 0.8.0. Changelog:

https://profanity-im.github.io/blog/post/release-080/

Quick test on amd64.

Feedback, OK?

RS

Index: Makefile
===
RCS file: /cvs/ports/net/profanity/Makefile,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 Makefile
--- Makefile2 Oct 2019 17:34:33 -   1.12
+++ Makefile7 Feb 2020 05:39:17 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.12 2019/10/02 17:34:33 rsadowski Exp $
 
 COMMENT =  console based XMPP client
-DISTNAME = profanity-0.7.1
+DISTNAME = profanity-0.8.0
 CATEGORIES =   net
 
 HOMEPAGE = https://profanity-im.github.io/
@@ -12,10 +12,12 @@ PERMIT_PACKAGE =Yes
 
 MASTER_SITES = https://profanity-im.github.io/
 
-WANTLIB += assuan c crypto curl curses ereadline expat ffi gcrypt
-WANTLIB += gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gpg-error
-WANTLIB += gpgme iconv intl m mesode nghttp2 otr pcre pthread
-WANTLIB += signal-protocol-c ssl util z ${MODPY_WANTLIB}
+WANTLIB += X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi Xinerama
+WANTLIB += Xrandr Xrender assuan c crypto curl curses ereadline
+WANTLIB += expat ffi fontconfig freetype gcrypt gio-2.0 glib-2.0
+WANTLIB += gmodule-2.0 gobject-2.0 gpg-error gpgme iconv intl
+WANTLIB += m mesode nghttp2 otr pcre pixman-1 pthread ${MODPY_WANTLIB}
+WANTLIB += signal-protocol-c ssl util xcb xcb-render xcb-shm z
 
 MODULES += lang/python
 
@@ -27,7 +29,8 @@ LIB_DEPENDS +=devel/glib2 \
net/libmesode \
net/libsignal-protocol-c \
security/gpgme \
-   security/libotr
+   security/libotr \
+   www/nghttp2
 
 # Only needed for tests, but cannot be a TEST_DEPENDS.
 # Check must be present at build time for tests to work.
Index: distinfo
===
RCS file: /cvs/ports/net/profanity/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo2 Oct 2019 17:34:33 -   1.6
+++ distinfo7 Feb 2020 05:39:17 -
@@ -1,2 +1,2 @@
-SHA256 (profanity-0.7.1.tar.gz) = P+RClI/y7iWGgcOBLoeNORedz5LhxnvI/g74iWRAsFs=
-SIZE (profanity-0.7.1.tar.gz) = 788754
+SHA256 (profanity-0.8.0.tar.gz) = Gq10Ft7jS3SRzMuk/W96dEwORobZx+rgYeSHaooNt8c=
+SIZE (profanity-0.8.0.tar.gz) = 809438
Index: patches/patch-configure_ac
===
RCS file: /cvs/ports/net/profanity/patches/patch-configure_ac,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-configure_ac
--- patches/patch-configure_ac  13 Sep 2019 09:04:05 -  1.4
+++ patches/patch-configure_ac  7 Feb 2020 05:39:17 -
@@ -12,7 +12,7 @@ Index: configure.ac
  if test "$PYTHON_CONFIG_EXISTS" == "yes"; then
  AX_PYTHON_DEVEL
  AM_CONDITIONAL([BUILD_PYTHON_API], [true])
-@@ -188,10 +188,10 @@ AS_IF([test "x$PLATFORM" = xosx],
+@@ -191,10 +191,10 @@ AS_IF([test "x$PLATFORM" = xosx],
  [AC_MSG_ERROR([libreadline is required for profanity])])],
  
[test "x$PLATFORM" = xopenbsd],
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/profanity/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST
--- pkg/PLIST   3 Mar 2019 19:40:04 -   1.3
+++ pkg/PLIST   7 Feb 2020 05:39:17 -
@@ -16,6 +16,7 @@ share/profanity/themes/boothj5_laptop
 share/profanity/themes/boothj5_slack
 share/profanity/themes/complex
 share/profanity/themes/forest
+share/profanity/themes/gruvbox
 share/profanity/themes/hacker
 share/profanity/themes/headache
 share/profanity/themes/joker
@@ -25,5 +26,7 @@ share/profanity/themes/original
 share/profanity/themes/original_bright
 share/profanity/themes/shade
 share/profanity/themes/simple
+share/profanity/themes/solarized-dark
+share/profanity/themes/solarized-light
 share/profanity/themes/spawn
 share/profanity/themes/whiteness



UPDATE security/go-siphash-1.2.1

2020-02-06 Thread George Rosamond
Attached is a diff for security/go-siphash to version 1.2.1.

The only port that depends on it is net/obfs4proxy, which will also be
updated in the near future.

g
Index: go-siphash//Makefile
===
RCS file: /cvs/ports/security/go-siphash/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- go-siphash//Makefile	12 Jul 2019 20:49:02 -	1.2
+++ go-siphash//Makefile	7 Feb 2020 03:31:49 -
@@ -4,13 +4,13 @@ COMMENT =		SipHash-2-4 in go
 
 GH_ACCOUNT =		dchest
 GH_PROJECT =		siphash
-GH_TAGNAME =		v1.0.0
+GH_TAGNAME =		v1.2.1
 DISTNAME =		go-siphash
 PKGNAME =		${DISTNAME}-${GH_TAGNAME:S/^v//}
 
 CATEGORIES =		security
 
-HOMEPAGE =		https://github.com/dchest/siphash
+HOMEPAGE =		https://github.com/dchest/siphash/
 
 MAINTAINER =		Sean Levy 
 
Index: go-siphash//distinfo
===
RCS file: /cvs/ports/security/go-siphash/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- go-siphash//distinfo	29 Aug 2017 16:59:02 -	1.1.1.1
+++ go-siphash//distinfo	7 Feb 2020 03:31:49 -
@@ -1,2 +1,2 @@
-SHA256 (go-siphash.tar.gz) = CgUm4aCZCOGFeLbzRkgz4DIY8vKnQt5YEy8ptmIuM5s=
-SIZE (go-siphash.tar.gz) = 4462
+SHA256 (go-siphash.tar.gz) = kMXoumK2Sy927VjIfdUEVhcWEASb71H9cbxZPBdE+tI=
+SIZE (go-siphash.tar.gz) = 10729


UPDATE fonts/go-fonts-20191214

2020-02-06 Thread George Rosamond
Update for fonts/go-fonts to 20191214.

g
Index: go-fonts//Makefile
===
RCS file: /cvs/ports/fonts/go-fonts/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- go-fonts//Makefile	12 Jul 2019 20:46:11 -	1.3
+++ go-fonts//Makefile	7 Feb 2020 03:12:47 -
@@ -3,8 +3,8 @@
 COMMENT=	Go TrueType fonts
 GH_ACCOUNT=	golang
 GH_PROJECT=	image
-GH_COMMIT=	ce0faa1867f5944a366e0174e7197b82089e9fa8
-DISTNAME=	go-image-20170401
+GH_COMMIT=	58c23975cae11f062d4b3b0c143fe248faac195d
+DISTNAME=	go-image-20191214
 PKGNAME=	${DISTNAME:S/image/fonts/}
 HOMEPAGE=	https://blog.golang.org/go-fonts
 
Index: go-fonts//distinfo
===
RCS file: /cvs/ports/fonts/go-fonts/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- go-fonts//distinfo	6 May 2017 15:10:17 -	1.3
+++ go-fonts//distinfo	7 Feb 2020 03:12:47 -
@@ -1,2 +1,2 @@
-SHA256 (go-image-20170401-ce0faa18.tar.gz) = 6TBY6YyCEY9LcJeGB4xszoP9M1fNYOK+Cwo7XpXC2t0=
-SIZE (go-image-20170401-ce0faa18.tar.gz) = 4810406
+SHA256 (go-image-20191214-58c23975.tar.gz) = JFiC8M2Gd8mj2EXcYBzUYSSC0tlad8x3GSq2EWFpKTM=
+SIZE (go-image-20191214-58c23975.tar.gz) = 4897822


Re: [update] databases/redis-5.0.7

2020-02-06 Thread Theo Buehler
On Thu, Feb 06, 2020 at 03:21:23PM +0100, Theo Buehler wrote:
[...]
> I have successfully built this version on amd64, i386 and macppc and ran
> the test suite successfully multiple times on each of these platforms.

My BeagleBoneBlack finally managed to update the ports tree and build
Redis.  It turns out that on that machine (or perhaps on armv7 in
general) redis-server is completely broken with both 4.0.14 in tree 
and with the update 5.0.7.

$ redis-server
Bus error (core dumped)

 17192 redis-server CALL  
mmap(0,0x1000,0x3,0x1002,-1,0)
 17192 redis-server RET   mmap -1698103296/0x9ac9
 17192 redis-server CALL  
mmap(0,0x1000,0x3,0x1002,-1,0)
 17192 redis-server RET   mmap -1692004352/0x9b261000
 17192 redis-server CALL  
mmap(0,0x1000,0x3,0x1002,-1,0)
 17192 redis-server RET   mmap -1527689216/0xa4f15000
 17192 redis-server CALL  
mmap(0,0x1000,0x3,0x1002,-1,0)
 17192 redis-server RET   mmap -1848020992/0x91d97000
 17192 redis-server CALL  
mmap(0,0x1000,0x3,0x1002,-1,0)
 17192 redis-server RET   mmap -1513738240/0xa5c63000
 17192 redis-server PSIG  SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0x9a63d024 
trapno=2049
 17192 redis-server NAMI  "redis-server.core"



Re: Update devel/scons

2020-02-06 Thread Chris Cappuccio
Stuart Henderson [s...@spacehopper.org] wrote:
> 
> Wouldn't they just do the same they've done with Java when their license
> changed (i.e. make people install it themselves)? Or keep on providing the
> old binaries themselves but not force the no-longer-supported command line
> flags so it works for distribution packagers..
> 
> (Of course I would very much support them switching to something that
> isn't mongodb...)

They package the full UniFi controller software in their own products
(Cloud Key, UDM) so it needs to be replaced



Re: [update] converters/p5-JSON 2.94 -> 4.02

2020-02-06 Thread Alexander Bluhm
OK bluhm@

On Tue, Feb 04, 2020 at 11:17:54PM +0100, Charlene Wendling wrote:
>
> This is a follow-up for the p5-JSON* update; you should try this diff
> with the XS version i submitted earlier.
>
> You can find the full changelog here [0], there are backward
> incompatible changes due to JSON::XS enabling allow_nonref. That update
> prevents to see that module being fatal-ed while doing a Perl 5.32
> update. See my JSON::XS mail for details.
>
> Port-wise it's a quick update, i replaced variables according to
> Makefile.template, but other than that it's a simple version bump.
>
> I've tested the direct consumers and found no issues [1] due to that
> update, some network-related errors are appearing because i use
> PORTS_PRIVSEP.
>
>
> Comments/feedback are welcome,
>
> Charl??ne.
>
>
> [0] https://metacpan.org/changes/distribution/JSON
> [1] https://bin.charlenew.xyz/p5-JSON-XS.tgz
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/converters/p5-JSON/Makefile,v
> retrieving revision 1.19
> diff -u -p -u -p -r1.19 Makefile
> --- Makefile  17 Jul 2019 14:49:20 -  1.19
> +++ Makefile  4 Feb 2020 21:25:59 -
> @@ -2,18 +2,19 @@
>
>  COMMENT= parse and convert to JSON (JavaScript Object Notation)
>
> -DISTNAME=JSON-2.94
> +DISTNAME=JSON-4.02
>  CATEGORIES=  converters
> -MODULES= cpan
> -PKG_ARCH=*
> -REVISION=0
>
>  # Perl
>  PERMIT_PACKAGE=  Yes
>
> +MODULES= cpan
> +
>  RUN_DEPENDS= www/p5-libwww
>  TEST_DEPENDS=converters/p5-JSON-XS
>
>  MAKE_ENV=TEST_POD=Yes
> +
> +PKG_ARCH=*
>
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/converters/p5-JSON/distinfo,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 distinfo
> --- distinfo  21 Aug 2018 17:57:34 -  1.11
> +++ distinfo  4 Feb 2020 21:25:59 -
> @@ -1,2 +1,2 @@
> -SHA256 (JSON-2.94.tar.gz) = EicbXO5JlDu93kMO71jx/mS6ZWGYCyLGlYXgj8l33G0=
> -SIZE (JSON-2.94.tar.gz) = 82629
> +SHA256 (JSON-4.02.tar.gz) = REqIdVqJ/6KlQkq07R0R3KYYCOvvV+gSQ0JGGanoYnw=
> +SIZE (JSON-4.02.tar.gz) = 90374



Re: [update] converters/p5-JSON-XS 3.04 -> 4.02

2020-02-06 Thread Alexander Bluhm
OK bluhm@

On Tue, Feb 04, 2020 at 11:16:43PM +0100, Charlene Wendling wrote:
> Hi,
>
> --
> $ cd /usr/ports/converters/p5-JSON; make test
> [...]
> Use of strings with code points over 0xFF as arguments to bitwise and
> (&) operator is deprecated. This will be a fatal error in Perl 5.32
> at /shm/pobj/p5-JSON-2.94/JSON-2.94/blib/lib/JSON/backportPP.pm line
> 424.
>
> I think we're better off updating JSON and JSON::XS (versions are
> supposed to be in sync) before we need to do an emergency fix. Note
> that there are a bit less than 400 ports depending on these two.
>
> I'll send the p5-JSON update that goes with it after that one.
> --
>
> Upstream's changelog is here [0], the main change is that it enables
> allow_nonref [1] by default for compatibility with RFC 7159 and newer,
> this has security implications [2].
>
> Port-wise it's a quick update, i reordered things according to
> Makefile.template, and fixed some spacing inconsistencies.
>
> Testing:
>
> - builds and passes tests fine on amd64 and powerpc
> - i tested the direct consumers on amd64, and there are no failures
>   due to that update [3] (there are network errors due to
>   PORTS_PRIVSEP)
>
>
> Comments/feedback are welcome,
>
> Charl??ne.
>
>
> [0] https://metacpan.org/changes/release/MLEHMANN/JSON-XS-4.02
> [1] 
> https://metacpan.org/pod/release/MLEHMANN/JSON-XS-4.02/XS.pm#$enabled-=-$json-%3Eget_allow_nonref
> [2]
> https://metacpan.org/pod/release/MLEHMANN/JSON-XS-4.02/XS.pm#SECURITY-CONSIDERATIONS
> [3] https://bin.charlenew.xyz/p5-JSON-XS.tgz
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/converters/p5-JSON-XS/Makefile,v
> retrieving revision 1.27
> diff -u -p -u -p -r1.27 Makefile
> --- Makefile  12 Jul 2019 20:43:50 -  1.27
> +++ Makefile  4 Feb 2020 18:32:24 -
> @@ -2,18 +2,19 @@
>
>  COMMENT =JSON serialising/deserialising, done correctly and fast
>
> -MODULES =cpan
> -DISTNAME =   JSON-XS-3.04
> +DISTNAME =   JSON-XS-4.02
>  EPOCH =  1
>  CATEGORIES = converters
>
>  # Perl
>  PERMIT_PACKAGE = Yes
>
> -WANTLIB += c perl
> +WANTLIB +=   c perl
> +
> +MODULES =cpan
>
> -BUILD_DEPENDS=   devel/p5-Canary-Stability
> -RUN_DEPENDS= converters/p5-Types-Serialiser \
> +BUILD_DEPENDS =  devel/p5-Canary-Stability
> +RUN_DEPENDS =converters/p5-Types-Serialiser \
>   devel/p5-common-sense
>
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/converters/p5-JSON-XS/distinfo,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 distinfo
> --- distinfo  27 Apr 2018 14:51:24 -  1.13
> +++ distinfo  4 Feb 2020 18:32:24 -
> @@ -1,2 +1,2 @@
> -SHA256 (JSON-XS-3.04.tar.gz) = ZdiDa9jqbwt7/8cLIhIVatw+L/pYfiflSNV2iT8JfCw=
> -SIZE (JSON-XS-3.04.tar.gz) = 83424
> +SHA256 (JSON-XS-4.02.tar.gz) = pa0XITgHGhRynaigGSHKIz2k/ivtKQ/9+45WDditzxY=
> +SIZE (JSON-XS-4.02.tar.gz) = 85904
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/converters/p5-JSON-XS/pkg/PLIST,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 PLIST
> --- pkg/PLIST 8 Mar 2016 14:20:18 -   1.6
> +++ pkg/PLIST 4 Feb 2020 18:32:24 -
> @@ -7,7 +7,7 @@ ${P5ARCH}/JSON/XS/Boolean.pm
>  ${P5ARCH}/auto/
>  ${P5ARCH}/auto/JSON/
>  ${P5ARCH}/auto/JSON/XS/
> -${P5ARCH}/auto/JSON/XS/XS.so
> +@so ${P5ARCH}/auto/JSON/XS/XS.so
>  @man man/man1/json_xs.1
>  @man man/man3p/JSON::XS.3p
>  @man man/man3p/JSON::XS::Boolean.3p



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 15:42:29

Modified files:
net/librenms   : Makefile distinfo 
net/librenms/patches: patch-LibreNMS_Config_php 
  patch-_env_example patch-daily_sh 
net/librenms/pkg: PLIST README 
Added files:
net/librenms/patches: patch-misc_config_definitions_json 
Removed files:
net/librenms/patches: patch-LibreNMS_Util_FileLock_php 
  patch-LibreNMS_Util_Git_php 
  patch-LibreNMS_Validations_Php_php 
  patch-discovery-wrapper_py 
  patch-html_install_php 
  patch-includes_common_php 
  patch-includes_defaults_inc_php 
  patch-includes_functions_php 
  patch-includes_html_output_capture_inc_php 
  patch-includes_html_pages_about_inc_php 
  patch-poller-service_py 
  patch-poller-wrapper_py 
  patch-scripts_composer_wrapper_php 
  patch-validate_php 

Log message:
update to librenms-1.60
- rework the README a bit, install notes may still need some fixes

- note: run daily.sh as _librenms after installing the new version to
update schemas, you will see errors when you try to login if you don't
do this.

- note: some things moved from symbolic links to real files which
pkg_add -u doesn't cope with (this is the same case as "exotest" in
regress/usr.sbin/pkg_add). pkg_delete then pkg_add when updating.
@ask-update is used in the plist to try to warn you and ask you to
cancel during the update in this case.



Re: pkgpaths in python3.7 to upgrade old python3s

2020-02-06 Thread Stuart Henderson
On 2020/02/06 21:26, Mikolaj Kucharski wrote:
> Hi,
> 
> Forgot to add that I've tested Stuart's diff with `pkg_add -u -n`
> and it worked. I didn't do real update (without -n), but I think
> it should work.

It does, I tested that before sending it out.

> On Mon, Feb 03, 2020 at 10:13:25PM +, Stuart Henderson wrote:
> > My attempt at a diff is below, it works for me in tests updating from
> > a system with 3.6+subpackages.
> > 
> > I use ${VERSION_SPEC} in the PLIST for the "same-version" conflicts
> > needed to override "@option no-default-conflict", those should be in all
> > PLISTs, and use a separate conflict entry for the ones there to handle
> > the update from old MODPY_DEFAULT_VERSION_3. I've also added some
> > commentary to the place in python.port.mk where people will look
> > if switching the version to save people having to figure it out again
> > when we move to 3.8-as-default.
> 
> ...
> 
> > > I'll work up an alternative diff and send out after tests.
> > > 
> > 
> > 
> > Index: Makefile.inc
> > ===
> > RCS file: /cvs/ports/lang/python/Makefile.inc,v
> > retrieving revision 1.133
> > diff -u -p -r1.133 Makefile.inc
> > --- Makefile.inc11 Nov 2019 17:47:41 -  1.133
> > +++ Makefile.inc3 Feb 2020 21:56:47 -
> > @@ -130,6 +130,8 @@ MAKE_FLAGS +=   LD_LIBRARY_PATH=${WRKSRC} 
> >  MAKE_FLAGS +=  LDFLAGS='-L${WRKSRC} -L${LOCALBASE}/lib/'
> >  FAKE_FLAGS +=  RANLIB=:
> >  
> > +SUBST_VARS +=  VERSION_SPEC
> > +
> >  # Python itself is clean, but some extensions e.g. py-cryptography
> >  # and QtWebKit require W|X mappings.
> >  USE_WXNEEDED = Yes
> > Index: python.port.mk
> > ===
> > RCS file: /cvs/ports/lang/python/python.port.mk,v
> > retrieving revision 1.119
> > diff -u -p -r1.119 python.port.mk
> > --- python.port.mk  19 Dec 2019 02:42:46 -  1.119
> > +++ python.port.mk  3 Feb 2020 21:56:47 -
> > @@ -9,6 +9,22 @@ CATEGORIES +=  lang/python
> >  MODPY_DEFAULT_VERSION_2 = 2.7
> >  MODPY_DEFAULT_VERSION_3 = 3.7
> >  
> > +# If switching the default version:
> > +# - In the old default version, @comment the non-suffixed bin/XXX files 
> > (python3,
> > +#   pydoc3, etc) and bump REVISION
> > +# - In the new version, uncomment these same files
> > +# - In the new version, add @conflict on the old REVISION of the old 
> > version
> > +
> > +# If later *removing* an old version:
> > +# - *move* the numbered @conflict python-*->=3.2,<3.7 to the new version
> > +#   and update e.g. to  @conflict python-*->=3.2,<3.8
> > +# - *move* the @pkgpath markers to the new version and add a new one for
> > +#   the old version you have just retired.
> > +
> > +# In all cases:
> > +# - keep the @conflict python-*-${VERSION_SPEC} PLIST lines as-is, they are
> > +#   there to override the "@option no-default-conflict".
> > +
> >  .if !defined(MODPY_VERSION)
> >  
> >  FLAVOR ?=
> > Index: 3.7/Makefile
> > ===
> > RCS file: /cvs/ports/lang/python/3.7/Makefile,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 Makefile
> > --- 3.7/Makefile28 Dec 2019 18:35:39 -  1.13
> > +++ 3.7/Makefile3 Feb 2020 21:56:47 -
> > @@ -10,10 +10,12 @@ PATCHLEVEL =.6
> >  SHARED_LIBS =  python3.7m 0.0
> >  VERSION_SPEC = >=3.7,<3.8
> >  
> > +REVISION = 0
> > +
> >  CONFIGURE_ARGS +=  --with-ensurepip=no
> >  CONFIGURE_ARGS +=  --enable-loadable-sqlite-extensions
> >  
> > -CONFIGURE_STYLE = autoconf
> > +CONFIGURE_STYLE =  autoconf
> >  
> >  PORTROACH = limit:^3\.7
> >  
> > Index: 3.7/pkg/PLIST-gdbm
> > ===
> > RCS file: /cvs/ports/lang/python/3.7/pkg/PLIST-gdbm,v
> > retrieving revision 1.4
> > diff -u -p -r1.4 PLIST-gdbm
> > --- 3.7/pkg/PLIST-gdbm  11 Dec 2019 19:55:40 -  1.4
> > +++ 3.7/pkg/PLIST-gdbm  3 Feb 2020 21:56:47 -
> > @@ -1,7 +1,11 @@
> >  @comment $OpenBSD: PLIST-gdbm,v 1.4 2019/12/11 19:55:40 sthen Exp $
> >  @option no-default-conflict
> >  @option is-branch
> > -@conflict python-gdbm->=3.7,<3.8
> > -@pkgpath lang/python3.5,-gdbm
> > -@pkgpath lang/python3.6,-gdbm
> > +@conflict python-gdbm-${VERSION_SPEC}
> > +@conflict python-gdbm->=3.2,<3.7
> > +@pkgpath lang/python/3.2,-gdbm
> > +@pkgpath lang/python/3.3,-gdbm
> > +@pkgpath lang/python/3.4,-gdbm
> > +@pkgpath lang/python/3.5,-gdbm
> > +@pkgpath lang/python/3.6,-gdbm
> >  @so lib/python3.7/lib-dynload/_gdbm.so
> > Index: 3.7/pkg/PLIST-idle
> > ===
> > RCS file: /cvs/ports/lang/python/3.7/pkg/PLIST-idle,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 PLIST-idle
> > --- 3.7/pkg/PLIST-idle  11 Dec 2019 19:55:40 -  1.5
> > +++ 3.7/pkg/PLIST-idle  3 Feb 2020 21:56:47 -
> > @@ 

Re: Update devel/scons

2020-02-06 Thread Stuart Henderson
On 2020/02/06 14:05, Chris Cappuccio wrote:
> Stuart Henderson [s...@spacehopper.org] wrote:
> > On 2020/02/06 21:01, Denis Fondras wrote:
> > > Update to 3.1.2. Will be useful to upgrade MongoDB.
> > 
> > btw, replacing mongodb with a newer version is blocked until ubiquiti
> > get round to fixing unifi, though a newer version could be added 
> > separately..
> 
> I'm not sure that ubiquiti will ever switch to a newer mongo, more likey
> to something else considering mongodb's new license.
> 

Wouldn't they just do the same they've done with Java when their license
changed (i.e. make people install it themselves)? Or keep on providing the
old binaries themselves but not force the no-longer-supported command line
flags so it works for distribution packagers..

(Of course I would very much support them switching to something that
isn't mongodb...)



Re: Update devel/scons

2020-02-06 Thread Chris Cappuccio
Stuart Henderson [s...@spacehopper.org] wrote:
> On 2020/02/06 21:01, Denis Fondras wrote:
> > Update to 3.1.2. Will be useful to upgrade MongoDB.
> 
> btw, replacing mongodb with a newer version is blocked until ubiquiti
> get round to fixing unifi, though a newer version could be added separately..

I'm not sure that ubiquiti will ever switch to a newer mongo, more likey
to something else considering mongodb's new license.



Re: UPDATE: mail/msmtp 1.6.6p1 -> 1.8.6

2020-02-06 Thread Xiyue Deng
Stuart Henderson  writes:

> Thanks - committed with small tweaks.
>

Thanks Stuart!

> On 2020/02/02 18:58, Xiyue Deng wrote:
>> Thanks Stuart for the reply.
>> 
>> Stuart Henderson  writes:
>> 
>> > On 2020/02/02 04:05, Xiyue Deng wrote:
>> >> Seems no one cares about this port.  Is it OK that I apply for maintainer?
>> >
>> > Certainly. It is a bit easier to take patches from someone that feels
>> > responsible enough for a port to be listed as maintainer :)
>> >
>> 
>> Added myself as maintainer now :)
>> 
>> >>  >>> * Many of the patches just replace "#!/usr/bin/env bash" to
>> >>  >>>   "#!/bin/sh".  Now most of scripts are changed to use 
>> >>  >>> "#!/usr/bin/env
>> >>  >>>   sh" which should now be the same thing.  Should we just drop 
>> >>  >>> those
>> >>  >>>   patches?
>> >
>> > It's not quite the same thing because env searches your path.
>> > Explicit /bin/sh seems a much better idea to me so I'm happier to keep 
>> > those.
>> >
>> 
>> Sounds good.  Patches kept.
>> 
>> >>  >>> * One of the patches changes the system /etc/msmtprc to provide 
>> >>  >>> an
>> >>  >>>   "account default" that listens on localhost:25, which will 
>> >>  >>> then use
>> >>  >>>   smtpd as server by default.  I think the intention is to 
>> >>  >>> provide a
>> >>  >>>   working configure that works out of the box.  However this may 
>> >>  >>> not do
>> >>  >>>   what you want because if one try to configure an account in a 
>> >>  >>> user
>> >>  >>>   configuration and somehow it contains errors (e.g. not properly
>> >>  >>>   provide a "from" address), msmtp will just send the mail 
>> >>  >>> through smtpd
>> >>  >>>   and returns OK which will result in the mail stuck in the 
>> >>  >>> system mail
>> >>  >>>   queue forever.  So my suggestion is to leave this file 
>> >>  >>> untouched so
>> >>  >>>   that the system /etc/msmtprc will just provide a fake "account
>> >>  >>>   default" and any mail not handled with a user provided account 
>> >>  >>> will
>> >>  >>>   fail immediately.
>> >
>> > i.e. remove patch-doc_msmtprc-system_example? I'd be ok with that.
>> 
>> Done.
>> 
>> A new release is also available so I've updated the patches accordingly
>> and attached (not inlining to avoid PGP signature messing it up).
>> Please take another look.
>> 
>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/mail/msmtp/Makefile,v
>> retrieving revision 1.47
>> diff -u -p -r1.47 Makefile
>> --- Makefile 12 Jul 2019 20:47:30 -  1.47
>> +++ Makefile 3 Feb 2020 02:55:18 -
>> @@ -2,27 +2,29 @@
>>  
>>  COMMENT =   SMTP plugin for MUAs
>>  
>> -DISTNAME =  msmtp-1.6.6
>> +DISTNAME =  msmtp-1.8.7
>>  CATEGORIES =mail
>> -REVISION =  1
>>  
>>  HOMEPAGE =  https://marlam.de/msmtp/
>>  
>> +MAINTAINER =Xiyue Deng 
>> +
>>  # GPLv3
>>  PERMIT_PACKAGE =Yes
>>  
>> -WANTLIB =  c crypto iconv idn intl ssl
>> +WANTLIB =  c crypto iconv idn2 intl gnutls
>>  
>>  MASTER_SITES =  https://marlam.de/msmtp/releases/
>>  EXTRACT_SUFX =  .tar.xz
>>  
>> -LIB_DEPENDS =   devel/libidn
>> +LIB_DEPENDS =   devel/libidn2 \
>> +security/gnutls
>>  
>>  SEPARATE_BUILD =Yes
>>  CONFIGURE_STYLE =   gnu
>>  CONFIGURE_ARGS =--with-libgsasl=no \
>>  --with-libidn=yes \
>> ---with-tls=openssl \
>> +--with-tls=gnutls \
>>  --without-libsecret
>>  
>>  post-install:
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/mail/msmtp/distinfo,v
>> retrieving revision 1.30
>> diff -u -p -r1.30 distinfo
>> --- distinfo 26 Mar 2017 13:34:06 -  1.30
>> +++ distinfo 3 Feb 2020 02:55:18 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (msmtp-1.6.6.tar.xz) = 2hXbH2K9AgH85TEK24nIYYi+kc10W3yztiuBpQHn+14=
>> -SIZE (msmtp-1.6.6.tar.xz) = 283744
>> +SHA256 (msmtp-1.8.7.tar.xz) = mlO83CROxbGoBpNOzHdG2dCdtYH1h77fWX6dovSMUfE=
>> +SIZE (msmtp-1.8.7.tar.xz) = 340908
>> Index: patches/patch-doc_msmtprc-system_example
>> ===
>> RCS file: patches/patch-doc_msmtprc-system_example
>> diff -N patches/patch-doc_msmtprc-system_example
>> --- patches/patch-doc_msmtprc-system_example 13 Feb 2009 14:59:01 -  
>> 1.1
>> +++ /dev/null1 Jan 1970 00:00:00 -
>> @@ -1,16 +0,0 @@
>> -$OpenBSD: patch-doc_msmtprc-system_example,v 1.1 2009/02/13 14:59:01 
>> pirofti Exp $
>>  doc/msmtprc-system.example.orig Sat Apr  7 18:20:34 2007
>> -+++ doc/msmtprc-system.example  Fri Feb 13 16:53:09 2009
>> -@@ -6,10 +6,10 @@
>> - account default
>> - 
>> - # The SMTP smarthost.
>> --host mailhub.oursite.example
>> -+host localhost
>> - 

Re: NEW: www/p5-Plack-App-URLMux

2020-02-06 Thread Mikolaj Kucharski
On Mon, Jan 27, 2020 at 05:56:52AM +, Mikolaj Kucharski wrote:
> On Sun, Jan 26, 2020 at 02:31:24PM -0800, Andrew Hewus Fresh wrote:
> > On Thu, Jan 16, 2020 at 11:01:40PM +, Mikolaj Kucharski wrote:
> > > Hi,
> > > 
> > > Kind reminder. Port reattached for convenience.
> > 
> > Remove "cpan" from CATEGORIES and then OK afresh1@
> 
> New port attached with cpan removed from CATEGORIES.

Ping. Port re-attached for convenience.

-- 
Regards,
 Mikolaj


p5-Plack-App-URLMux.port,2.tgz
Description: application/tar-gz


Re: Update devel/scons

2020-02-06 Thread Brian Callahan




On 2020-02-06 3:29 PM, Stuart Henderson wrote:

On 2020/02/06 21:01, Denis Fondras wrote:

Update to 3.1.2. Will be useful to upgrade MongoDB.

btw, replacing mongodb with a newer version is blocked until ubiquiti
get round to fixing unifi, though a newer version could be added separately..



Whenever this goes in, can you please drop me as maintainer?
Last time I looked into this (years ago now, admittedly), some of its 
dependents did not build. Hopefully that is no longer the case.


~Brian



Re: pkgpaths in python3.7 to upgrade old python3s

2020-02-06 Thread Mikolaj Kucharski
Hi,

Forgot to add that I've tested Stuart's diff with `pkg_add -u -n`
and it worked. I didn't do real update (without -n), but I think
it should work.

On Mon, Feb 03, 2020 at 10:13:25PM +, Stuart Henderson wrote:
> My attempt at a diff is below, it works for me in tests updating from
> a system with 3.6+subpackages.
> 
> I use ${VERSION_SPEC} in the PLIST for the "same-version" conflicts
> needed to override "@option no-default-conflict", those should be in all
> PLISTs, and use a separate conflict entry for the ones there to handle
> the update from old MODPY_DEFAULT_VERSION_3. I've also added some
> commentary to the place in python.port.mk where people will look
> if switching the version to save people having to figure it out again
> when we move to 3.8-as-default.

...

> > I'll work up an alternative diff and send out after tests.
> > 
> 
> 
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/lang/python/Makefile.inc,v
> retrieving revision 1.133
> diff -u -p -r1.133 Makefile.inc
> --- Makefile.inc  11 Nov 2019 17:47:41 -  1.133
> +++ Makefile.inc  3 Feb 2020 21:56:47 -
> @@ -130,6 +130,8 @@ MAKE_FLAGS += LD_LIBRARY_PATH=${WRKSRC} 
>  MAKE_FLAGS +=LDFLAGS='-L${WRKSRC} -L${LOCALBASE}/lib/'
>  FAKE_FLAGS +=RANLIB=:
>  
> +SUBST_VARS +=VERSION_SPEC
> +
>  # Python itself is clean, but some extensions e.g. py-cryptography
>  # and QtWebKit require W|X mappings.
>  USE_WXNEEDED = Yes
> Index: python.port.mk
> ===
> RCS file: /cvs/ports/lang/python/python.port.mk,v
> retrieving revision 1.119
> diff -u -p -r1.119 python.port.mk
> --- python.port.mk19 Dec 2019 02:42:46 -  1.119
> +++ python.port.mk3 Feb 2020 21:56:47 -
> @@ -9,6 +9,22 @@ CATEGORIES +=lang/python
>  MODPY_DEFAULT_VERSION_2 = 2.7
>  MODPY_DEFAULT_VERSION_3 = 3.7
>  
> +# If switching the default version:
> +# - In the old default version, @comment the non-suffixed bin/XXX files 
> (python3,
> +#   pydoc3, etc) and bump REVISION
> +# - In the new version, uncomment these same files
> +# - In the new version, add @conflict on the old REVISION of the old version
> +
> +# If later *removing* an old version:
> +# - *move* the numbered @conflict python-*->=3.2,<3.7 to the new version
> +#   and update e.g. to  @conflict python-*->=3.2,<3.8
> +# - *move* the @pkgpath markers to the new version and add a new one for
> +#   the old version you have just retired.
> +
> +# In all cases:
> +# - keep the @conflict python-*-${VERSION_SPEC} PLIST lines as-is, they are
> +#   there to override the "@option no-default-conflict".
> +
>  .if !defined(MODPY_VERSION)
>  
>  FLAVOR ?=
> Index: 3.7/Makefile
> ===
> RCS file: /cvs/ports/lang/python/3.7/Makefile,v
> retrieving revision 1.13
> diff -u -p -r1.13 Makefile
> --- 3.7/Makefile  28 Dec 2019 18:35:39 -  1.13
> +++ 3.7/Makefile  3 Feb 2020 21:56:47 -
> @@ -10,10 +10,12 @@ PATCHLEVEL =  .6
>  SHARED_LIBS =python3.7m 0.0
>  VERSION_SPEC =   >=3.7,<3.8
>  
> +REVISION =   0
> +
>  CONFIGURE_ARGS +=--with-ensurepip=no
>  CONFIGURE_ARGS +=--enable-loadable-sqlite-extensions
>  
> -CONFIGURE_STYLE = autoconf
> +CONFIGURE_STYLE =autoconf
>  
>  PORTROACH = limit:^3\.7
>  
> Index: 3.7/pkg/PLIST-gdbm
> ===
> RCS file: /cvs/ports/lang/python/3.7/pkg/PLIST-gdbm,v
> retrieving revision 1.4
> diff -u -p -r1.4 PLIST-gdbm
> --- 3.7/pkg/PLIST-gdbm11 Dec 2019 19:55:40 -  1.4
> +++ 3.7/pkg/PLIST-gdbm3 Feb 2020 21:56:47 -
> @@ -1,7 +1,11 @@
>  @comment $OpenBSD: PLIST-gdbm,v 1.4 2019/12/11 19:55:40 sthen Exp $
>  @option no-default-conflict
>  @option is-branch
> -@conflict python-gdbm->=3.7,<3.8
> -@pkgpath lang/python3.5,-gdbm
> -@pkgpath lang/python3.6,-gdbm
> +@conflict python-gdbm-${VERSION_SPEC}
> +@conflict python-gdbm->=3.2,<3.7
> +@pkgpath lang/python/3.2,-gdbm
> +@pkgpath lang/python/3.3,-gdbm
> +@pkgpath lang/python/3.4,-gdbm
> +@pkgpath lang/python/3.5,-gdbm
> +@pkgpath lang/python/3.6,-gdbm
>  @so lib/python3.7/lib-dynload/_gdbm.so
> Index: 3.7/pkg/PLIST-idle
> ===
> RCS file: /cvs/ports/lang/python/3.7/pkg/PLIST-idle,v
> retrieving revision 1.5
> diff -u -p -r1.5 PLIST-idle
> --- 3.7/pkg/PLIST-idle11 Dec 2019 19:55:40 -  1.5
> +++ 3.7/pkg/PLIST-idle3 Feb 2020 21:56:47 -
> @@ -1,11 +1,14 @@
>  @comment $OpenBSD: PLIST-idle,v 1.5 2019/12/11 19:55:40 sthen Exp $
>  @option no-default-conflict
>  @option is-branch
> -@conflict python-idle->=3.7,<3.8
> +@conflict python-idle-${VERSION_SPEC}
> +@conflict python-idle->=3.2,<3.7
> +@pkgpath lang/python/3.2,-idle
> +@pkgpath 

UPDATE: devel/ninja

2020-02-06 Thread Rafael Sadowski
Hi ports@,

Ninja 0.10.0 was released a while ago. Here is a link to the notes:

https://groups.google.com/forum/#!msg/ninja-build/piOltAhywFA/zPfkrTtRCwAJ

The new version comes with Fortran support. Maybe we can finally get rid
of all the "USE_NINJA=No". This is a job for someone who's interested.
Volunteers come forward :)

This diff needs a hand full of OKs from persons in charge of the bulks.

Index: Makefile
===
RCS file: /cvs/ports/devel/ninja/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile20 Dec 2019 15:51:26 -  1.29
+++ Makefile6 Feb 2020 20:33:20 -
@@ -9,10 +9,10 @@ COMMENT = small build system with a foc
 
 GH_ACCOUNT =   ninja-build
 GH_PROJECT =   ninja
-GH_TAGNAME =   v1.9.0
-REVISION = 0
+GH_TAGNAME =   v1.10.0
 
 CATEGORIES =   devel
+
 HOMEPAGE = https://ninja-build.org/
 
 # Apache License v2.0
Index: distinfo
===
RCS file: /cvs/ports/devel/ninja/distinfo,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 distinfo
--- distinfo22 Jun 2019 20:23:04 -  1.11
+++ distinfo6 Feb 2020 20:33:20 -
@@ -1,2 +1,2 @@
-SHA256 (ninja-1.9.0.tar.gz) = XX7HWCj40/0aDC8xtbDOp4DN/hAxNZIoxCjBpIv81bk=
-SIZE (ninja-1.9.0.tar.gz) = 190860
+SHA256 (ninja-1.10.0.tar.gz) = OBAxiwhIlDX478GcBVJegKmTr1pVuqDf6uBGWp1F+Z8=
+SIZE (ninja-1.10.0.tar.gz) = 210313
Index: patches/patch-src_build_cc
===
RCS file: /cvs/ports/devel/ninja/patches/patch-src_build_cc,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-src_build_cc
--- patches/patch-src_build_cc  20 Dec 2019 15:51:26 -  1.1
+++ patches/patch-src_build_cc  6 Feb 2020 20:33:20 -
@@ -6,7 +6,7 @@ by using a set of pointers.
 Index: src/build.cc
 --- src/build.cc.orig
 +++ src/build.cc
-@@ -348,9 +348,8 @@ bool Plan::AddSubTarget(Node* node, Node* dependent, s
+@@ -382,9 +382,8 @@ void Plan::EdgeWanted(const Edge* edge) {
  Edge* Plan::FindWork() {
if (ready_.empty())
  return NULL;
@@ -18,7 +18,7 @@ Index: src/build.cc
return edge;
  }
  
-@@ -372,7 +371,7 @@ void Plan::ScheduleWork(map::iterator wan
+@@ -406,7 +405,7 @@ void Plan::ScheduleWork(map::iterator wan
  pool->RetrieveReadyEdges(_);
} else {
  pool->EdgeScheduled(*edge);
Index: patches/patch-src_build_h
===
RCS file: /cvs/ports/devel/ninja/patches/patch-src_build_h,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-src_build_h
--- patches/patch-src_build_h   20 Dec 2019 15:51:26 -  1.1
+++ patches/patch-src_build_h   6 Feb 2020 20:33:20 -
@@ -6,12 +6,12 @@ by using a set of pointers.
 Index: src/build.h
 --- src/build.h.orig
 +++ src/build.h
-@@ -103,7 +103,7 @@ struct Plan { (private)
+@@ -122,7 +122,7 @@ struct Plan { (private)
/// we want for the edge.
map want_;
  
 -  set ready_;
 +  deque ready_;
  
-   /// Total number of edges that have commands (not phony).
-   int command_edges_;
+   Builder* builder_;
+ 



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Daniel Jakots
CVSROOT:/cvs
Module name:ports
Changes by: d...@cvs.openbsd.org2020/02/06 13:36:03

Modified files:
textproc/py-black: Makefile 

Log message:
Drop maintainer

To update to 19.10b0, it needs the new ports typed-ast and regex,
and an update for devel/py-pathspec.



Update to libetpan-1.9.4

2020-02-06 Thread Daniel Jakots
Hello,

I thought I would update it before dropping maintainer. I can't test it
so test/ok are welcome (if you use claws-mail && imap, you can test it).

diff'ing the result of the nm output on the two (before/after) .so
gives no difference therefore no bumping the version.

Cheers,
Daniel


Index: Makefile
===
RCS file: /cvs/ports/mail/libetpan/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile12 Jul 2019 20:47:28 -  1.37
+++ Makefile6 Feb 2020 20:27:35 -
@@ -4,14 +4,12 @@ COMMENT=  mail purpose library
 
 GH_ACCOUNT=dinhviethoa
 GH_PROJECT=libetpan
-GH_TAGNAME=1.9.3
+GH_TAGNAME=1.9.4
 CATEGORIES=mail devel
 
 SHARED_LIBS +=  etpan18.2 # 24.0
 
 HOMEPAGE=  http://www.etpan.org/libetpan.html
-
-MAINTAINER=Daniel Jakots 
 
 # BSD
 PERMIT_PACKAGE=Yes
Index: distinfo
===
RCS file: /cvs/ports/mail/libetpan/distinfo,v
retrieving revision 1.13
diff -u -p -r1.13 distinfo
--- distinfo26 Jan 2019 10:25:09 -  1.13
+++ distinfo6 Feb 2020 20:27:35 -
@@ -1,2 +1,2 @@
-SHA256 (libetpan-1.9.3.tar.gz) = WR+X1RAvYA5mhQL+HdWjQekQqEDY6mLmiaOnnYv7rIc=
-SIZE (libetpan-1.9.3.tar.gz) = 549
+SHA256 (libetpan-1.9.4.tar.gz) = guyOoR0jnJln29FxfKwJyDMKVY4CWz5NxqdZToDRO7E=
+SIZE (libetpan-1.9.4.tar.gz) = 525
Index: pkg/PLIST
===
RCS file: /cvs/ports/mail/libetpan/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST   17 Sep 2015 20:28:33 -  1.5
+++ pkg/PLIST   6 Feb 2020 20:27:35 -
@@ -1,5 +1,4 @@
 @comment $OpenBSD: PLIST,v 1.5 2015/09/17 20:28:33 jca Exp $
-bin/libetpan-config
 include/libetpan/
 include/libetpan.h
 include/libetpan/acl.h
@@ -9,6 +8,7 @@ include/libetpan/annotatemore_types.h
 include/libetpan/carray.h
 include/libetpan/charconv.h
 include/libetpan/chash.h
+include/libetpan/clientid.h
 include/libetpan/clist.h
 include/libetpan/condstore.h
 include/libetpan/condstore_types.h
@@ -165,6 +165,7 @@ include/libetpan/xgmlabels.h
 include/libetpan/xgmmsgid.h
 include/libetpan/xgmthrid.h
 include/libetpan/xlist.h
-lib/libetpan.a
+@static-lib lib/libetpan.a
 lib/libetpan.la
 @lib lib/libetpan.so.${LIBetpan_VERSION}
+lib/pkgconfig/libetpan.pc



Re: Update devel/scons

2020-02-06 Thread Stuart Henderson
On 2020/02/06 21:01, Denis Fondras wrote:
> Update to 3.1.2. Will be useful to upgrade MongoDB.

btw, replacing mongodb with a newer version is blocked until ubiquiti
get round to fixing unifi, though a newer version could be added separately..



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Daniel Jakots
CVSROOT:/cvs
Module name:ports
Changes by: d...@cvs.openbsd.org2020/02/06 13:26:58

Modified files:
textproc/py-markdown: Makefile 

Log message:
Drop maintainer



Re: Update devel/scons

2020-02-06 Thread Solène Rapenne

Le 2020-02-06 21:01, Denis Fondras a écrit :

Update to 3.1.2. Will be useful to upgrade MongoDB.



-@comment $OpenBSD: PLIST,v 1.11 2017/06/28 16:26:55 bcallah Exp $
+@comment $OpenBSD: PLIST,v$



+bin/scons-${VERSION}.bat
+bin/scons.bat


I'm not sure we need those bat files



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Daniel Jakots
CVSROOT:/cvs
Module name:ports
Changes by: d...@cvs.openbsd.org2020/02/06 13:16:26

Modified files:
net/haproxy: Makefile distinfo 

Log message:
Update to haproxy-2.0.12



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2020/02/06 13:10:14

Modified files:
net/libmaxminddb: Makefile 

Log message:
bump revision for all subpackages after homepage change



Update devel/scons

2020-02-06 Thread Denis Fondras
Update to 3.1.2. Will be useful to upgrade MongoDB.


Index: Makefile
===
RCS file: /cvs/ports/devel/scons/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile12 Jul 2019 20:46:00 -  1.28
+++ Makefile6 Feb 2020 19:59:44 -
@@ -2,7 +2,7 @@
 
 COMMENT=   Python-based build system
 
-VERSION =  2.5.1
+VERSION =  3.1.2
 REVISION = 0
 DISTNAME=  scons-${VERSION}
 CATEGORIES=devel
@@ -16,6 +16,7 @@ PERMIT_PACKAGE=   Yes
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=scons/}
 
 MODULES=   lang/python
+MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
 
 NO_TEST=   Yes
 
Index: distinfo
===
RCS file: /cvs/ports/devel/scons/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- distinfo28 Jun 2017 16:26:55 -  1.16
+++ distinfo6 Feb 2020 19:59:44 -
@@ -1,2 +1,2 @@
-SHA256 (scons-2.5.1.tar.gz) = CyUhiue0apZ9tC8qU3IWRbPUKHSmX5VSrRbOJtMPUfI=
-SIZE (scons-2.5.1.tar.gz) = 620909
+SHA256 (scons-3.1.2.tar.gz) = eAHz9i9lRSjict94C+EMDpM36JdlC2Ldzunzn94T+Ps=
+SIZE (scons-3.1.2.tar.gz) = 668298
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/scons/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST
--- pkg/PLIST   28 Jun 2017 16:26:55 -  1.11
+++ pkg/PLIST   6 Feb 2020 19:59:44 -
@@ -1,410 +1,428 @@
-@comment $OpenBSD: PLIST,v 1.11 2017/06/28 16:26:55 bcallah Exp $
+@comment $OpenBSD: PLIST,v$
 bin/scons
 bin/scons-${VERSION}
+bin/scons-${VERSION}.bat
 bin/scons-configure-cache
 bin/scons-configure-cache-${VERSION}
 bin/scons-time
 bin/scons-time-${VERSION}
+bin/scons.bat
 bin/sconsign
 bin/sconsign-${VERSION}
-lib/scons-${VERSION}/
-lib/scons-${VERSION}/SCons/
-lib/scons-${VERSION}/SCons/Action.py
-lib/scons-${VERSION}/SCons/Action.pyc
-lib/scons-${VERSION}/SCons/Builder.py
-lib/scons-${VERSION}/SCons/Builder.pyc
-lib/scons-${VERSION}/SCons/CacheDir.py
-lib/scons-${VERSION}/SCons/CacheDir.pyc
-lib/scons-${VERSION}/SCons/Conftest.py
-lib/scons-${VERSION}/SCons/Conftest.pyc
-lib/scons-${VERSION}/SCons/Debug.py
-lib/scons-${VERSION}/SCons/Debug.pyc
-lib/scons-${VERSION}/SCons/Defaults.py
-lib/scons-${VERSION}/SCons/Defaults.pyc
-lib/scons-${VERSION}/SCons/Environment.py
-lib/scons-${VERSION}/SCons/Environment.pyc
-lib/scons-${VERSION}/SCons/Errors.py
-lib/scons-${VERSION}/SCons/Errors.pyc
-lib/scons-${VERSION}/SCons/Executor.py
-lib/scons-${VERSION}/SCons/Executor.pyc
-lib/scons-${VERSION}/SCons/Job.py
-lib/scons-${VERSION}/SCons/Job.pyc
-lib/scons-${VERSION}/SCons/Memoize.py
-lib/scons-${VERSION}/SCons/Memoize.pyc
-lib/scons-${VERSION}/SCons/Node/
-lib/scons-${VERSION}/SCons/Node/Alias.py
-lib/scons-${VERSION}/SCons/Node/Alias.pyc
-lib/scons-${VERSION}/SCons/Node/FS.py
-lib/scons-${VERSION}/SCons/Node/FS.pyc
-lib/scons-${VERSION}/SCons/Node/Python.py
-lib/scons-${VERSION}/SCons/Node/Python.pyc
-lib/scons-${VERSION}/SCons/Node/__init__.py
-lib/scons-${VERSION}/SCons/Node/__init__.pyc
-lib/scons-${VERSION}/SCons/Options/
-lib/scons-${VERSION}/SCons/Options/BoolOption.py
-lib/scons-${VERSION}/SCons/Options/BoolOption.pyc
-lib/scons-${VERSION}/SCons/Options/EnumOption.py
-lib/scons-${VERSION}/SCons/Options/EnumOption.pyc
-lib/scons-${VERSION}/SCons/Options/ListOption.py
-lib/scons-${VERSION}/SCons/Options/ListOption.pyc
-lib/scons-${VERSION}/SCons/Options/PackageOption.py
-lib/scons-${VERSION}/SCons/Options/PackageOption.pyc
-lib/scons-${VERSION}/SCons/Options/PathOption.py
-lib/scons-${VERSION}/SCons/Options/PathOption.pyc
-lib/scons-${VERSION}/SCons/Options/__init__.py
-lib/scons-${VERSION}/SCons/Options/__init__.pyc
-lib/scons-${VERSION}/SCons/PathList.py
-lib/scons-${VERSION}/SCons/PathList.pyc
-lib/scons-${VERSION}/SCons/Platform/
-lib/scons-${VERSION}/SCons/Platform/__init__.py
-lib/scons-${VERSION}/SCons/Platform/__init__.pyc
-lib/scons-${VERSION}/SCons/Platform/aix.py
-lib/scons-${VERSION}/SCons/Platform/aix.pyc
-lib/scons-${VERSION}/SCons/Platform/cygwin.py
-lib/scons-${VERSION}/SCons/Platform/cygwin.pyc
-lib/scons-${VERSION}/SCons/Platform/darwin.py
-lib/scons-${VERSION}/SCons/Platform/darwin.pyc
-lib/scons-${VERSION}/SCons/Platform/hpux.py
-lib/scons-${VERSION}/SCons/Platform/hpux.pyc
-lib/scons-${VERSION}/SCons/Platform/irix.py
-lib/scons-${VERSION}/SCons/Platform/irix.pyc
-lib/scons-${VERSION}/SCons/Platform/os2.py
-lib/scons-${VERSION}/SCons/Platform/os2.pyc
-lib/scons-${VERSION}/SCons/Platform/posix.py
-lib/scons-${VERSION}/SCons/Platform/posix.pyc
-lib/scons-${VERSION}/SCons/Platform/sunos.py
-lib/scons-${VERSION}/SCons/Platform/sunos.pyc
-lib/scons-${VERSION}/SCons/Platform/win32.py
-lib/scons-${VERSION}/SCons/Platform/win32.pyc
-lib/scons-${VERSION}/SCons/SConf.py
-lib/scons-${VERSION}/SCons/SConf.pyc
-lib/scons-${VERSION}/SCons/SConsign.py
-lib/scons-${VERSION}/SCons/SConsign.pyc

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/02/06 13:00:18

Modified files:
net/qbittorrent: Makefile.inc 
net/qbittorrent/qbittorrent: Makefile distinfo 
net/qbittorrent/qbittorrent/patches: patch-configure 
net/qbittorrent/qbittorrent/pkg: PLIST 
net/qbittorrent/qbittorrent-nox: Makefile distinfo 
net/qbittorrent/qbittorrent-nox/patches: patch-configure 

Log message:
Update qbittorrent 4.2.1

* 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

Diff and notes above from Nam Nguyen, OK kn@



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/02/06 13:00:22

Modified files:
net/deluge : Makefile distinfo 
net/deluge/patches: patch-setup_py 
net/deluge/pkg : PLIST 
Removed files:
net/deluge/patches: patch-deluge_ui_gtkui_preferences_py 

Log message:
Update deluge to 2.0.3

"... moves deluge to python 3, using the proposed fixes for devel/boost and
proposed update for net/libtorrent-rasterbar."

Changelogs: https://deluge.readthedocs.io/en/latest/changelog.html
https://deluge.readthedocs.io/en/latest/releases/2.0.html

Diff and notes above from Nam Nguyen, OK kn@



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/02/06 13:00:16

Modified files:
net/libtorrent-rasterbar: Makefile distinfo 
net/libtorrent-rasterbar/patches: 
  patch-include_libtorrent_config_hpp 
net/libtorrent-rasterbar/pkg: PLIST 
Added files:
net/libtorrent-rasterbar/patches: 
  patch-include_libtorrent_buffer_hpp 

Log message:
Update libtorrent-rasterbar to 1.2.3

Diff from Nam Nguyen, tweaks from kn@



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Jeremy Evans
CVSROOT:/cvs
Module name:ports
Changes by: jer...@cvs.openbsd.org  2020/02/06 12:53:02

Removed files:
databases/pg_statsinfo: 

patch-src_drivers_postgresql_PostgresqlTypes_cpp 
patch-src_sql_drivers_psql_qsql_psql_cpp 

Log message:
Remove wrong patches committed by mistake to wrong directory

Pointed out by naddy@



Re: CVS: cvs.openbsd.org: ports

2020-02-06 Thread Jeremy Evans
On 02/06 02:18, Kurt Mosiejczuk wrote:
> On Thu, Feb 06, 2020 at 07:26:35AM -0700, Jeremy Evans wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: jer...@cvs.openbsd.org  2020/02/06 07:26:35
> > 
> > Added files:
> > databases/pg_statsinfo: 
> > 
> > patch-src_drivers_postgresql_PostgresqlTypes_cpp 
> > patch-src_sql_drivers_psql_qsql_psql_cpp 
> 
> > Log message:
> > Add patches missed earlier to allow building with PostgreSQL 12
> 
> It is actually patch-agent_lib_libstatsinfo_c that is failing to apply
> properly on my sparc64 build.

Sorry about that.  Looks like the changes in that patch were also not
committed.  Fixed now.

Thanks,
Jeremy



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Jeremy Evans
CVSROOT:/cvs
Module name:ports
Changes by: jer...@cvs.openbsd.org  2020/02/06 12:26:34

Modified files:
databases/pg_statsinfo/patches: patch-agent_lib_libstatsinfo_c 

Log message:
Add other missed patch needed for PostgreSQL 12 support

Pointed out by kmos@



Re: CVS: cvs.openbsd.org: ports

2020-02-06 Thread Kurt Mosiejczuk
On Thu, Feb 06, 2020 at 07:26:35AM -0700, Jeremy Evans wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   jer...@cvs.openbsd.org  2020/02/06 07:26:35
> 
> Added files:
>   databases/pg_statsinfo: 
>   
> patch-src_drivers_postgresql_PostgresqlTypes_cpp 
>   patch-src_sql_drivers_psql_qsql_psql_cpp 

> Log message:
> Add patches missed earlier to allow building with PostgreSQL 12

It is actually patch-agent_lib_libstatsinfo_c that is failing to apply
properly on my sparc64 build.

--Kurt



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Theo Buehler
On Thu, Feb 06, 2020 at 07:44:28PM +0100, Klemens Nanni wrote:
> On Thu, Feb 06, 2020 at 07:36:42PM +0100, Theo Buehler wrote:
> > I don't understand. How does this work with the 4.0.14 port? The things
> > you ifdef out are already there.
> Sorry, that was a patch against 5.0.3, not 4.0.14 in-tree.
> 

What I'm saying is that the 4.0.14 scripting.c contains the things you
ifdef out for 5.0.3. How does this work with the port we have in tree?



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Klemens Nanni
On Thu, Feb 06, 2020 at 07:36:42PM +0100, Theo Buehler wrote:
> I don't understand. How does this work with the 4.0.14 port? The things
> you ifdef out are already there.
Sorry, that was a patch against 5.0.3, not 4.0.14 in-tree.



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Theo Buehler
On Thu, Feb 06, 2020 at 07:24:18PM +0100, Klemens Nanni wrote:
> On Thu, Feb 06, 2020 at 07:18:48PM +0100, Klemens Nanni wrote:
> > sparc64 does not have luajit suppport which blocked my update to 5.0.3;
> > I #ifdef'd the bits in src/scripting.c but afaik there were issues with
> > dependent ports on such recent redis versions -- rspamd was probably one
> > of them.
> Found the diffs, but I have currently no way and/or time to test this.
> 
> One disables luajit on sparc64, the other removes tests for it, but that
> (test) approach is obviously not suitable for all other arches that have
> luajit.

> $OpenBSD$
> 
> luajit is not available on sparc64.

I don't understand. How does this work with the 4.0.14 port? The things
you ifdef out are already there.

> 
> Index: src/scripting.c
> --- src/scripting.c.orig
> +++ src/scripting.c
> @@ -830,10 +830,12 @@ void luaLoadLib(lua_State *lua, const char *libname, l
>lua_call(lua, 1, 0);
>  }
>  
> +#ifdef LUAJIT_H
>  LUALIB_API int (luaopen_cjson) (lua_State *L);
>  LUALIB_API int (luaopen_struct) (lua_State *L);
>  LUALIB_API int (luaopen_cmsgpack) (lua_State *L);
>  LUALIB_API int (luaopen_bit) (lua_State *L);
> +#endif /* LUAJIT_H */
>  
>  void luaLoadLibraries(lua_State *lua) {
>  luaLoadLib(lua, "", luaopen_base);
> @@ -841,10 +843,12 @@ void luaLoadLibraries(lua_State *lua) {
>  luaLoadLib(lua, LUA_STRLIBNAME, luaopen_string);
>  luaLoadLib(lua, LUA_MATHLIBNAME, luaopen_math);
>  luaLoadLib(lua, LUA_DBLIBNAME, luaopen_debug);
> +#ifdef LUAJIT_H
>  luaLoadLib(lua, "cjson", luaopen_cjson);
>  luaLoadLib(lua, "struct", luaopen_struct);
>  luaLoadLib(lua, "cmsgpack", luaopen_cmsgpack);
>  luaLoadLib(lua, "bit", luaopen_bit);
> +#endif /* LUAJIT_H */
>  
>  #if 0 /* Stuff that we don't load currently, for sandboxing concerns. */
>  luaLoadLib(lua, LUA_LOADLIBNAME, luaopen_package);

> $OpenBSD$
> 
> Remove tests for luajit functions.
> 
> Index: tests/unit/scripting.tcl
> --- tests/unit/scripting.tcl.orig
> +++ tests/unit/scripting.tcl
> @@ -187,75 +187,6 @@ start_server {tags {"scripting"}} {
>  set e
>  } {*against a key*}
>  
> -test {EVAL - JSON numeric decoding} {
> -# We must return the table as a string because otherwise
> -# Redis converts floats to ints and we get 0 and 1023 instead
> -# of 0.0003 and 1023.2 as the parsed output.
> -r eval {return
> - table.concat(
> -   cjson.decode(
> -"[0.0, -5e3, -1, 0.3e-3, 1023.2, 0e10]"), " ")
> -} 0
> -} {0 -5000 -1 0.0003 1023.2 0}
> -
> -test {EVAL - JSON string decoding} {
> -r eval {local decoded = cjson.decode('{"keya": "a", "keyb": "b"}')
> -return {decoded.keya, decoded.keyb}
> -} 0
> -} {a b}
> -
> -test {EVAL - cmsgpack can pack double?} {
> -r eval {local encoded = cmsgpack.pack(0.1)
> -local h = ""
> -for i = 1, #encoded do
> -h = h .. string.format("%02x",string.byte(encoded,i))
> -end
> -return h
> -} 0
> -} {cb3fba}
> -
> -test {EVAL - cmsgpack can pack negative int64?} {
> -r eval {local encoded = cmsgpack.pack(-1099511627776)
> -local h = ""
> -for i = 1, #encoded do
> -h = h .. string.format("%02x",string.byte(encoded,i))
> -end
> -return h
> -} 0
> -} {d3ff00}
> -
> -test {EVAL - cmsgpack can pack and unpack circular references?} {
> -r eval {local a = {x=nil,y=5}
> -local b = {x=a}
> -a['x'] = b
> -local encoded = cmsgpack.pack(a)
> -local h = ""
> --- cmsgpack encodes to a depth of 16, but can't encode
> --- references, so the encoded object has a deep copy recusive
> --- depth of 16.
> -for i = 1, #encoded do
> -h = h .. string.format("%02x",string.byte(encoded,i))
> -end
> --- when unpacked, re.x.x != re because the unpack creates
> --- individual tables down to a depth of 16.
> --- (that's why the encoded output is so large)
> -local re = cmsgpack.unpack(encoded)
> -assert(re)
> -assert(re.x)
> -assert(re.x.x.y == re.y)
> -assert(re.x.x.x.x.y == re.y)
> -assert(re.x.x.x.x.x.x.y == re.y)
> -assert(re.x.x.x.x.x.x.x.x.x.x.y == re.y)
> --- maximum working depth:
> -assert(re.x.x.x.x.x.x.x.x.x.x.x.x.x.x.y == re.y)
> --- now the last x would be b above and has no y
> -assert(re.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x)
> --- so, the final x.x is at the depth limit and was 

Re: [update] databases/redis-5.0.7

2020-02-06 Thread Klemens Nanni
On Thu, Feb 06, 2020 at 07:18:48PM +0100, Klemens Nanni wrote:
> sparc64 does not have luajit suppport which blocked my update to 5.0.3;
> I #ifdef'd the bits in src/scripting.c but afaik there were issues with
> dependent ports on such recent redis versions -- rspamd was probably one
> of them.
Found the diffs, but I have currently no way and/or time to test this.

One disables luajit on sparc64, the other removes tests for it, but that
(test) approach is obviously not suitable for all other arches that have
luajit.
$OpenBSD$

luajit is not available on sparc64.

Index: src/scripting.c
--- src/scripting.c.orig
+++ src/scripting.c
@@ -830,10 +830,12 @@ void luaLoadLib(lua_State *lua, const char *libname, l
   lua_call(lua, 1, 0);
 }
 
+#ifdef LUAJIT_H
 LUALIB_API int (luaopen_cjson) (lua_State *L);
 LUALIB_API int (luaopen_struct) (lua_State *L);
 LUALIB_API int (luaopen_cmsgpack) (lua_State *L);
 LUALIB_API int (luaopen_bit) (lua_State *L);
+#endif /* LUAJIT_H */
 
 void luaLoadLibraries(lua_State *lua) {
 luaLoadLib(lua, "", luaopen_base);
@@ -841,10 +843,12 @@ void luaLoadLibraries(lua_State *lua) {
 luaLoadLib(lua, LUA_STRLIBNAME, luaopen_string);
 luaLoadLib(lua, LUA_MATHLIBNAME, luaopen_math);
 luaLoadLib(lua, LUA_DBLIBNAME, luaopen_debug);
+#ifdef LUAJIT_H
 luaLoadLib(lua, "cjson", luaopen_cjson);
 luaLoadLib(lua, "struct", luaopen_struct);
 luaLoadLib(lua, "cmsgpack", luaopen_cmsgpack);
 luaLoadLib(lua, "bit", luaopen_bit);
+#endif /* LUAJIT_H */
 
 #if 0 /* Stuff that we don't load currently, for sandboxing concerns. */
 luaLoadLib(lua, LUA_LOADLIBNAME, luaopen_package);
$OpenBSD$

Remove tests for luajit functions.

Index: tests/unit/scripting.tcl
--- tests/unit/scripting.tcl.orig
+++ tests/unit/scripting.tcl
@@ -187,75 +187,6 @@ start_server {tags {"scripting"}} {
 set e
 } {*against a key*}
 
-test {EVAL - JSON numeric decoding} {
-# We must return the table as a string because otherwise
-# Redis converts floats to ints and we get 0 and 1023 instead
-# of 0.0003 and 1023.2 as the parsed output.
-r eval {return
- table.concat(
-   cjson.decode(
-"[0.0, -5e3, -1, 0.3e-3, 1023.2, 0e10]"), " ")
-} 0
-} {0 -5000 -1 0.0003 1023.2 0}
-
-test {EVAL - JSON string decoding} {
-r eval {local decoded = cjson.decode('{"keya": "a", "keyb": "b"}')
-return {decoded.keya, decoded.keyb}
-} 0
-} {a b}
-
-test {EVAL - cmsgpack can pack double?} {
-r eval {local encoded = cmsgpack.pack(0.1)
-local h = ""
-for i = 1, #encoded do
-h = h .. string.format("%02x",string.byte(encoded,i))
-end
-return h
-} 0
-} {cb3fba}
-
-test {EVAL - cmsgpack can pack negative int64?} {
-r eval {local encoded = cmsgpack.pack(-1099511627776)
-local h = ""
-for i = 1, #encoded do
-h = h .. string.format("%02x",string.byte(encoded,i))
-end
-return h
-} 0
-} {d3ff00}
-
-test {EVAL - cmsgpack can pack and unpack circular references?} {
-r eval {local a = {x=nil,y=5}
-local b = {x=a}
-a['x'] = b
-local encoded = cmsgpack.pack(a)
-local h = ""
--- cmsgpack encodes to a depth of 16, but can't encode
--- references, so the encoded object has a deep copy recusive
--- depth of 16.
-for i = 1, #encoded do
-h = h .. string.format("%02x",string.byte(encoded,i))
-end
--- when unpacked, re.x.x != re because the unpack creates
--- individual tables down to a depth of 16.
--- (that's why the encoded output is so large)
-local re = cmsgpack.unpack(encoded)
-assert(re)
-assert(re.x)
-assert(re.x.x.y == re.y)
-assert(re.x.x.x.x.y == re.y)
-assert(re.x.x.x.x.x.x.y == re.y)
-assert(re.x.x.x.x.x.x.x.x.x.x.y == re.y)
--- maximum working depth:
-assert(re.x.x.x.x.x.x.x.x.x.x.x.x.x.x.y == re.y)
--- now the last x would be b above and has no y
-assert(re.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x)
--- so, the final x.x is at the depth limit and was assigned nil
-assert(re.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x == nil)
-return {h, re.x.x.x.x.x.x.x.x.y == re.y, re.y == 5}
-} 0
-} 
{82a17905a17881a17882a17905a17881a17882a17905a17881a17882a17905a17881a17882a17905a17881a17882a17905a17881a17882a17905a17881a17882a17905a17881a178c0
 1 1}
-
 test {EVAL - Numerical sanity check from bitop} {
 r eval 

Re: [update] databases/redis-5.0.7

2020-02-06 Thread Klemens Nanni
On Thu, Feb 06, 2020 at 04:12:29PM +, Stuart Henderson wrote:
> When the topic came up before, there was some mention of 5.x not working
> on some arches, I would like to see this tested on at least i386, sparc64,
> aarch64 before it goes in. I can do some tests on i386 and probably
> also aarch64 but not sparc64.
sparc64 does not have luajit suppport which blocked my update to 5.0.3;
I #ifdef'd the bits in src/scripting.c but afaik there were issues with
dependent ports on such recent redis versions -- rspamd was probably one
of them.

> > AFAIK, redis is (or should be) used as a cache i.e. losing its data is
> > a small inconvenience but shouldn't be a problem.
> 
> noo, this would be a big problem
+1



Re: update games/taisei 1.0 -> 1.3.1

2020-02-06 Thread Charlene Wendling
Ping :)

On Sun, 26 Jan 2020 19:20:17 +0100
Charlene Wendling wrote:

> 
> On Wed, 15 Jan 2020 18:10:10 +0100
> Charlene Wendling wrote:
> 
> > Hi,
> > 
> > On Wed, 15 Jan 2020 14:36:48 +0100
> > Omar Polo wrote:
> > 
> > > Hi,
> > > 
> > > First time here, hoping I didn't mess up too much.
> > 
> > It works for you at least, so it's already nice :)
> > 
> > By the way, it was already in -wip --
> > https://github.com/jasperla/openbsd-wip/tree/master/games/taisei
> > 
> > > The patch below
> > > updates games/taisei from 1.0 to the latest 1.3.1 with the
> > > followings changes:
> > > 
> > >  - use https for HOMEPAGE
> > >  - upstream repo changed
> > >  - dropped all the patches, they're not needed anymore
> > >  - dependecies updated
> > Also [0]:
> >  - it breaks the runtime with amdgpu and radeondrm, and that's why i
> >did not propose it. But if there is popular demand, i think we
> > should go for it :)
> 
> I brought back my old video card on my amd64 box:
> 
> radeondrm0 at pci9 dev 0 function 0 "ATI Radeon HD 7450" rev 0x00  
> 
> I wanted to correct myself, taisei works fine with radeondrm(4) and
> inteldrm(4). As such, i think this update would benefit to most of
> us. 
> 
> I'm providing again the diff for convenience.
> 
> >  - Requires OpenGL>=3.3, so works only on modern archs
> > > 
> > > Built and played on amd64, everything seems to work fine (audio
> > > too.)
> > 
> > [...]
> > 
> > I'm proposing here the diff from -wip if someone want to test/review
> > it.
> > 
> > Charlène.
> > 
> > 
> > [0] https://marc.info/?l=openbsd-ports=155611903608886=2
> > 
> 


Index: Makefile
===
RCS file: /cvs/ports/games/taisei/Makefile,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 Makefile
--- Makefile12 Jul 2019 20:46:25 -  1.6
+++ Makefile15 Jan 2020 17:01:17 -
@@ -1,33 +1,50 @@
 # $OpenBSD: Makefile,v 1.6 2019/07/12 20:46:25 sthen Exp $
 
+# Requires OpenGL>=3.3, only usable on archs that support
+# modern video cards
+ONLY_FOR_ARCHS =   amd64 aarch64 i386
+
 COMMENT =  clone of the touhou games
 
-V =1.0a
-DISTNAME = taisei-$V
-REVISION = 3
+VERSION =  v1.3.1
+DISTNAME = taisei-${VERSION}
+PKGNAME =  taisei-${VERSION:S/^v//}
 
 CATEGORIES =   games
 
-HOMEPAGE = http://taisei-project.org/
+HOMEPAGE = https://taisei-project.org/
 
 # MIT
+# Soundtrack: CC-BY 4.0 / Photos: PD and CC-0
 PERMIT_PACKAGE =   Yes
 
-WANTLIB += GL GLU SDL SDL_ttf alut c freetype m openal png pthread
+WANTLIB += SDL2 SDL2_mixer c crypto freetype m opusfile png webpdecoder
 WANTLIB += z
 
-GH_ACCOUNT =   laochailan
-GH_PROJECT =   taisei
-GH_TAGNAME =   v$V
+MASTER_SITES=  
https://github.com/taisei-project/taisei/releases/download/${VERSION}/
+
+EXTRACT_SUFX=  .tar.xz
+
+MODULES =  devel/meson \
+   lang/python
+
+MODPY_RUNDEP = No
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
 
-CFLAGS +=  -fgnu89-inline
-MODULES =  devel/cmake
 RUN_DEPENDS =  devel/desktop-file-utils \
+   misc/shared-mime-info \
x11/gtk+3,-guic
-LIB_DEPENDS =  audio/freealut \
-   audio/openal \
-   devel/sdl-ttf \
-   graphics/png
+
+LIB_DEPENDS =  audio/opusfile \
+   devel/sdl2>=2.0.5 \
+   devel/sdl2-mixer>=2.0.4 \
+   graphics/libwebp>=0.5 \
+   graphics/png>=1.5.0
+
+# Don't include docs
+# Don't zip the ressources, it avoids using archivers/libzip
+CONFIGURE_ARGS +=  -Ddocs=false \
+   -Denable_zip=false
 
 NO_TEST =  Yes
 
Index: distinfo
===
RCS file: /cvs/ports/games/taisei/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo22 Aug 2015 09:38:07 -  1.1.1.1
+++ distinfo15 Jan 2020 17:01:17 -
@@ -1,2 +1,2 @@
-SHA256 (taisei-1.0a.tar.gz) = FWHITJ/YucepG4ZL38B/uBG7baXFTPMqK2vWPeX48/8=
-SIZE (taisei-1.0a.tar.gz) = 91854864
+SHA256 (taisei-v1.3.1.tar.xz) = hlg6OnEAk+YwFKWua2glGgacslraBsb41zT4XzGtyYU=
+SIZE (taisei-v1.3.1.tar.xz) = 70763196
Index: patches/patch-src_boss_h
===
RCS file: patches/patch-src_boss_h
diff -N patches/patch-src_boss_h
--- patches/patch-src_boss_h17 May 2017 22:54:28 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-src_boss_h,v 1.1 2017/05/17 22:54:28 espie Exp $
-
-Index: src/boss.h
 src/boss.h.orig
-+++ src/boss.h
-@@ -9,6 +9,8 @@
- #define BOSS_H
- 
- #include 
-+#undef complex
-+#define complex double _Complex
- 
- #include 
- 

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Edd Barrett
CVSROOT:/cvs
Module name:ports
Changes by: e...@cvs.openbsd.org2020/02/06 11:06:10

Modified files:
net/gophernicus: Makefile distinfo 
net/gophernicus/pkg: PLIST 

Log message:
Update net/gophernicus to version 3.0.1.

Input from, and OK, bket@.

solene@ was OK with a slightly earlier version, pre-simplification.

Thanks!



Mix Release cannot work on OpenBSD 6.6 Elixir Package

2020-02-06 Thread Zhi-Qiang Lei
Hi,

The release tool of Elixir package cannot work on OpenBSD 6.6. José and I had 
done the troubleshooting but we are not sure how to fix this on OpenBSD. Would 
you mind to take a look at this issue? Thanks! 
https://github.com/elixir-lang/elixir/issues/9716 

Sincerely yours,
Siegfried
zhiqiang@gmail.com





Re: [update] databases/redis-5.0.7

2020-02-06 Thread Charlene Wendling
On Thu, 6 Feb 2020 16:12:29 +
Stuart Henderson wrote:

> On 2020/02/06 10:15, Daniel Jakots wrote:
> > Hi Theo,
> > 
> > Thanks for working on that!
> > 
> > On Thu, 6 Feb 2020 15:21:23 +0100, Theo Buehler 
> > wrote:
> > 
> > > First of all, despite the length of this mail, most of the update
> > > is straightforward. The diff is an in-place upgrade from 4.0.14
> > > to 5.0.7.
> 
> When the topic came up before, there was some mention of 5.x not
> working on some arches, I would like to see this tested on at least
> i386, sparc64, aarch64 before it goes in. I can do some tests on i386
> and probably also aarch64 but not sparc64.

I've spotted an occurrence of char being considered as signed on all
arch, which is not the case on arm* and powerpc. Theo found the
issue is there on our current version in CVS, so it won't break builds,
but it should be corrected.

Below is the original diff with an additional patch to fix that. I did
run the tests and it's still fine.

> > > The release notes (which contain migration instructions at the
> > > very end)
> > > 
> > > https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES
> > 
> > Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a
> > user there is nothing to do. I guess you don't plan to add anything
> > to current.html do you?
> > 
> > > look as if there is no risk of losing data due to the migration
> > > and looking around on the net I couldn't find any reports of
> > > breakage. However, I don't know and can't know for sure.
> > > 
> > > Since we're playing with user data here, it might be more prudent
> > > to provide a redis5 port, and to leave it to the users to decide
> > > if and when they want to migrate instead of forcing it upon them
> > > right when the update goes in (or when they upgrade to 6.7).
> > 
> > AFAIK, redis is (or should be) used as a cache i.e. losing its data
> > is a small inconvenience but shouldn't be a problem.
> 
> noo, this would be a big problem
> 
> >   I don't think
> > duplicating the port is worth it.
> 
> I do agree with that.
> 
> > > A detail: redis-sentinel is installed as a symlink to
> > > redis-server. Ports seem to do this frequently, but I wonder if
> > > that should be turned into a hard link as is usually done in base?
> > 
> > What are the pro/cons of using a hard link instead?
> 
> Not sure about pros, but here's a con: you need to check inode numbers
> to see for sure where they point (I hate this with the hardlinked
> files in base...)
> 


Index: Makefile
===
RCS file: /cvs/ports/databases/redis/Makefile,v
retrieving revision 1.108
diff -u -p -u -p -r1.108 Makefile
--- Makefile12 Jul 2019 20:44:01 -  1.108
+++ Makefile6 Feb 2020 17:21:51 -
@@ -1,10 +1,9 @@
 # $OpenBSD: Makefile,v 1.108 2019/07/12 20:44:01 sthen Exp $
 
 COMMENT =  persistent key-value database
-DISTNAME = redis-4.0.14
+DISTNAME = redis-5.0.7
 CATEGORIES =   databases
 HOMEPAGE = https://redis.io/
-REVISION = 0
 
 # BSD
 PERMIT_PACKAGE =   Yes
Index: distinfo
===
RCS file: /cvs/ports/databases/redis/distinfo,v
retrieving revision 1.83
diff -u -p -u -p -r1.83 distinfo
--- distinfo2 Apr 2019 22:13:11 -   1.83
+++ distinfo6 Feb 2020 17:21:51 -
@@ -1,2 +1,2 @@
-SHA256 (redis-4.0.14.tar.gz) = Hh4YQgqGz7KFkzEjsEqC4evaIL+woolHJ0Wgh1h+k6c=
-SIZE (redis-4.0.14.tar.gz) = 1740967
+SHA256 (redis-5.0.7.tar.gz) = Ydt06r9oAfBX/SS1kCMvLzN9QiKA/RlIbsoDvofTqCs=
+SIZE (redis-5.0.7.tar.gz) = 1984203
Index: patches/patch-deps_Makefile
===
RCS file: /cvs/ports/databases/redis/patches/patch-deps_Makefile,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 patch-deps_Makefile
--- patches/patch-deps_Makefile 9 Aug 2017 09:16:09 -   1.10
+++ patches/patch-deps_Makefile 6 Feb 2020 17:21:51 -
@@ -48,7 +48,7 @@ Index: deps/Makefile
 -
 -jemalloc: .make-prerequisites
 -  @printf '%b %b\n' $(MAKECOLOR)MAKE$(ENDCOLOR) $(BINCOLOR)$@$(ENDCOLOR)
--  cd jemalloc && ./configure --with-lg-quantum=3 
--with-jemalloc-prefix=je_ --enable-cc-silence CFLAGS="$(JEMALLOC_CFLAGS)" 
LDFLAGS="$(JEMALLOC_LDFLAGS)"
+-  cd jemalloc && ./configure --with-version=5.1.0-0-g0 
--with-lg-quantum=3 --with-jemalloc-prefix=je_ --enable-cc-silence 
CFLAGS="$(JEMALLOC_CFLAGS)" LDFLAGS="$(JEMALLOC_LDFLAGS)"
 -  cd jemalloc && $(MAKE) CFLAGS="$(JEMALLOC_CFLAGS)" 
LDFLAGS="$(JEMALLOC_LDFLAGS)" lib/libjemalloc.a
 -
 -.PHONY: jemalloc
Index: patches/patch-deps_linenoise_linenoise_c
===
RCS file: patches/patch-deps_linenoise_linenoise_c
diff -N patches/patch-deps_linenoise_linenoise_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ 

Re: [update] databases/redis-5.0.7

2020-02-06 Thread Charlene Wendling
On Thu, 6 Feb 2020 16:12:29 +
Stuart Henderson wrote:

> On 2020/02/06 10:15, Daniel Jakots wrote:
> > Hi Theo,
> > 
> > Thanks for working on that!
> > 
> > On Thu, 6 Feb 2020 15:21:23 +0100, Theo Buehler 
> > wrote:
> > 
> > > First of all, despite the length of this mail, most of the update
> > > is straightforward. The diff is an in-place upgrade from 4.0.14
> > > to 5.0.7.
> 
> When the topic came up before, there was some mention of 5.x not
> working on some arches, I would like to see this tested on at least
> i386, sparc64, aarch64 before it goes in. I can do some tests on i386
> and probably also aarch64 but not sparc64.

It works fine on powerpc, probably one of the less relevant arch to run
redis ;)

- build log: https://bin.charlenew.xyz/redis.log
- test log: https://bin.charlenew.xyz/redis.test.log

> > > The release notes (which contain migration instructions at the
> > > very end)
> > > 
> > > https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES
> > 
> > Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a
> > user there is nothing to do. I guess you don't plan to add anything
> > to current.html do you?
> > 
> > > look as if there is no risk of losing data due to the migration
> > > and looking around on the net I couldn't find any reports of
> > > breakage. However, I don't know and can't know for sure.
> > > 
> > > Since we're playing with user data here, it might be more prudent
> > > to provide a redis5 port, and to leave it to the users to decide
> > > if and when they want to migrate instead of forcing it upon them
> > > right when the update goes in (or when they upgrade to 6.7).
> > 
> > AFAIK, redis is (or should be) used as a cache i.e. losing its data
> > is a small inconvenience but shouldn't be a problem.
> 
> noo, this would be a big problem
> 
> >   I don't think
> > duplicating the port is worth it.
> 
> I do agree with that.
> 
> > > A detail: redis-sentinel is installed as a symlink to
> > > redis-server. Ports seem to do this frequently, but I wonder if
> > > that should be turned into a hard link as is usually done in base?
> > 
> > What are the pro/cons of using a hard link instead?
> 
> Not sure about pros, but here's a con: you need to check inode numbers
> to see for sure where they point (I hate this with the hardlinked
> files in base...)
> 



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Giovanni Bechis
On 2/6/20 4:15 PM, Daniel Jakots wrote:
> Hi Theo,
> 
> Thanks for working on that!
> 
> On Thu, 6 Feb 2020 15:21:23 +0100, Theo Buehler 
> wrote:
> 
>> First of all, despite the length of this mail, most of the update is
>> straightforward. The diff is an in-place upgrade from 4.0.14 to 5.0.7.
>>
>> The release notes (which contain migration instructions at the very
>> end)
>>
>> https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES
> 
> Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a
> user there is nothing to do. I guess you don't plan to add anything to
> current.html do you?
> 
>> look as if there is no risk of losing data due to the migration and
>> looking around on the net I couldn't find any reports of breakage.
>> However, I don't know and can't know for sure.
>>
>> Since we're playing with user data here, it might be more prudent to
>> provide a redis5 port, and to leave it to the users to decide if and
>> when they want to migrate instead of forcing it upon them right when
>> the update goes in (or when they upgrade to 6.7).
> 
> AFAIK, redis is (or should be) used as a cache i.e. losing its data is
> a small inconvenience but shouldn't be a problem. I don't think
> duplicating the port is worth it.
> 
SpamAssassin can store bayes data into Redis, I have some 500k keys I do not 
want to lose but I can test database migration.

 Cheers
  Giovanni

>> A detail: redis-sentinel is installed as a symlink to redis-server.
>> Ports seem to do this frequently, but I wonder if that should be
>> turned into a hard link as is usually done in base?
> 
> What are the pro/cons of using a hard link instead?
> 
> Cheers,
> Daniel
> 



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 09:21:42

Modified files:
telephony/asterisk: Makefile distinfo 
telephony/asterisk/patches: patch-res_res_pjsip_pubsub_c 

Log message:
update to asterisk-16.8.0



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Bjorn Ketelaars
CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2020/02/06 09:20:10

Modified files:
devel/py-sip   : Makefile distinfo 
devel/py-sip/patches: patch-configure_py 

Log message:
Update to py-sip-4.19.21

This update fixes devel/git-cola segfaulting on exit. landry@ was so
kind to check if this update doesn't break qgis.

While here switch HOMEPAGE to https.

OK landry@



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Theo Buehler
On Thu, Feb 06, 2020 at 10:15:20AM -0500, Daniel Jakots wrote:
> > https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES
> 
> Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a
> user there is nothing to do. I guess you don't plan to add anything to
> current.html do you?

While I read it the same way as you and it should be a no-brainer for
most, I was going to add a note with this link to current.html to be on
the safe side.

> > look as if there is no risk of losing data due to the migration and
> > looking around on the net I couldn't find any reports of breakage.
> > However, I don't know and can't know for sure.
> > 
> > Since we're playing with user data here, it might be more prudent to
> > provide a redis5 port, and to leave it to the users to decide if and
> > when they want to migrate instead of forcing it upon them right when
> > the update goes in (or when they upgrade to 6.7).
> 
> AFAIK, redis is (or should be) used as a cache i.e. losing its data is
> a small inconvenience but shouldn't be a problem. I don't think
> duplicating the port is worth it.

It is a persistent key value store, which is not necessarily used for
purely transient data. A common use case is to use it as a state machine
and to update counters. I don't think we should jeopardize this data
lightly.

> > A detail: redis-sentinel is installed as a symlink to redis-server.
> > Ports seem to do this frequently, but I wonder if that should be
> > turned into a hard link as is usually done in base?
> 
> What are the pro/cons of using a hard link instead?

I don't know. It just stands out in the PLIST because of the missing
@bin marker.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 09:18:54

Modified files:
mail/rspamd: Makefile distinfo 
mail/rspamd/patches: patch-cmake_Toolset_cmake 
 patch-src_CMakeLists_txt 
 patch-src_libutil_util_c 
mail/rspamd/pkg: PLIST 
Removed files:
mail/rspamd/patches: patch-contrib_aho-corasick_CMakeLists_txt 
 patch-contrib_hiredis_CMakeLists_txt 
 patch-contrib_http-parser_CMakeLists_txt 
 patch-contrib_lc-btrie_CMakeLists_txt 
 patch-contrib_libottery_CMakeLists_txt 
 patch-contrib_lua-lpeg_CMakeLists_txt 
 patch-contrib_zstd_CMakeLists_txt 

Log message:
update to rspamd-2.3



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Bjorn Ketelaars
CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2020/02/06 09:18:10

Modified files:
devel/git-cola : Makefile 
devel/git-cola/pkg: PLIST 

Log message:
Switch git-cola to python3/py-qt5

Includes feedback on the initial diff from kn@ and rsadowski@.

OK landry@



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 09:18:19

Modified files:
misc/screen: Tag: OPENBSD_6_6 Makefile distinfo 
misc/screen/patches: Tag: OPENBSD_6_6 patch-doc_screen_1 
Removed files:
misc/screen/patches: Tag: OPENBSD_6_6 patch-configure_ac 
 patch-tty_sh 

Log message:
update to screen-4.8.0, including:

"- Fix potential memory corruption when using OSC 49

As last fix, fixes potential memory overwrite of quite big size (~768
bytes), and even though I'm not sure about potential exploitability of
that issue, I highly recommend everyone to upgrade as soon as possible.
This issue is present at least since v.4.2.0 (haven't checked earlier)."



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 09:17:20

Modified files:
misc/screen: Makefile distinfo 
misc/screen/patches: patch-doc_screen_1 
Removed files:
misc/screen/patches: patch-configure_ac patch-tty_sh 

Log message:
update to screen-4.8.0, including:

"- Fix potential memory corruption when using OSC 49

As last fix, fixes potential memory overwrite of quite big size (~768
bytes), and even though I'm not sure about potential exploitability of
that issue, I highly recommend everyone to upgrade as soon as possible.
This issue is present at least since v.4.2.0 (haven't checked earlier)."



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Bjorn Ketelaars
CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2020/02/06 09:16:10

Modified files:
sysutils/ddrescue: Makefile distinfo 

Log message:
Update to ddrescue-1.24.

Release notes:
http://lists.gnu.org/archive/html/info-gnu/2019-02/msg00012.html

OK benoit@



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Stuart Henderson
On 2020/02/06 10:15, Daniel Jakots wrote:
> Hi Theo,
> 
> Thanks for working on that!
> 
> On Thu, 6 Feb 2020 15:21:23 +0100, Theo Buehler 
> wrote:
> 
> > First of all, despite the length of this mail, most of the update is
> > straightforward. The diff is an in-place upgrade from 4.0.14 to 5.0.7.

When the topic came up before, there was some mention of 5.x not working
on some arches, I would like to see this tested on at least i386, sparc64,
aarch64 before it goes in. I can do some tests on i386 and probably
also aarch64 but not sparc64.

> > The release notes (which contain migration instructions at the very
> > end)
> > 
> > https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES
> 
> Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a
> user there is nothing to do. I guess you don't plan to add anything to
> current.html do you?
> 
> > look as if there is no risk of losing data due to the migration and
> > looking around on the net I couldn't find any reports of breakage.
> > However, I don't know and can't know for sure.
> > 
> > Since we're playing with user data here, it might be more prudent to
> > provide a redis5 port, and to leave it to the users to decide if and
> > when they want to migrate instead of forcing it upon them right when
> > the update goes in (or when they upgrade to 6.7).
> 
> AFAIK, redis is (or should be) used as a cache i.e. losing its data is
> a small inconvenience but shouldn't be a problem.

noo, this would be a big problem

>   I don't think
> duplicating the port is worth it.

I do agree with that.

> > A detail: redis-sentinel is installed as a symlink to redis-server.
> > Ports seem to do this frequently, but I wonder if that should be
> > turned into a hard link as is usually done in base?
> 
> What are the pro/cons of using a hard link instead?

Not sure about pros, but here's a con: you need to check inode numbers
to see for sure where they point (I hate this with the hardlinked files
in base...)



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 09:13:07

Modified files:
net/exabgp : Makefile distinfo 

Log message:
update to exabgp-4.2.6



Re: Update devel/py-urwid to 2.1.0

2020-02-06 Thread clematis
On Mon, Jan 13, 2020 at 04:18:07PM +0100, clematis wrote:
> On Mon, Jan 06, 2020 at 12:55:47PM +, Stuart Henderson wrote:
> > On 2020/01/06 09:42, clematis wrote:
> > > On Thu, Nov 28, 2019 at 08:13:04AM +0100, clematis wrote:
> > > > On Wed, Nov 27, 2019 at 09:18:45PM +, Stuart Henderson wrote:
> > > > > diff -u, please.
> > > > > 
> > > > 
> > > > Please find diff -u attached.
> > > > Cheers,
> > > 
> > > ping?
> > > Diff: https://marc.info/?l=openbsd-ports=157492525529846=p3
> > > 
> > Committed with tweaks:
> > 
> > - remove REVISION line
> > - remove bogus dep on python--tests
> > - use MODPY_PYTEST
> 
> Previous submission was breaking py2 flavor.(sorry about that). 
> py2 doesn't support async stuff, so _async_kw_event_loop.py would throw
> an error when byte-compiling.
> I had a quick chat with one of the urwid maintainer but I didn't feel like
> they had much interest in fixing this. I've opened a github issue for
> the record and to track this. [1]
> 
> In the meantime, I don't know if there's a prefered way to fix this in
> between removing _async_kw_event_loop.py post-extract or using
> MODPY_COMMENT. I found both method being used (devel/py-freezegun and
> devel/py-pexpect). I felt more confortable not touching PLIST so I went
> for the first approach.
>  
> both flavors build, package, install, deinstall ok on amd64. tests
> haven't changed. RUN_DEPENDS OK. 
>  
> New diff attached.
> Feedback, comments are welcome.
>  
> Thanks,
> 
> [1] https://github.com/urwid/urwid/issues/393

Hi team,
That won't be fixed upstream as they have no more interest in py2.

Are we keeping the FLAVOR and moving forward with this diff using
post-extract to remove the _async* breaking py2? 

Or should I make it a py3 only port and also ${MODPY_DEFAULT_VERSION_3}
the run_depends:
/usr/ports/devel/bpython
/usr/ports/devel/bpython,python3
/usr/ports/devel/pudb
/usr/ports/devel/pudb,python3

Two other run_depends are already default to py3:
/usr/ports/net/toot
/usr/ports/productivity/khal

And this last one, well, it was declared dead [1] in 2017 so we might
just remove it if no-one has any objection.
/usr/ports/productivity/py-carddav
[1] http://lostpackets.de/pycarddav/pycarddav-is-dead.html
 
Any prefered way to proceed?

Thanks.
-- 
clematis (0x7e96fd2400fe7b59)
Index: Makefile
===
RCS file: /cvs/ports/devel/py-urwid/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile7 Jan 2020 12:09:00 -   1.29
+++ Makefile13 Jan 2020 14:46:51 -
@@ -2,11 +2,10 @@
 
 COMMENT =  console user interface library for python
 
-MODPY_EGG_VERSION = 2.0.1
+MODPY_EGG_VERSION = 2.1.0
 DISTNAME = urwid-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 CATEGORIES =   devel
-EPOCH =0
 
 HOMEPAGE = http://urwid.org/
 
@@ -15,18 +14,27 @@ MAINTAINER =Clem Atis https://github.com/urwid/urwid/issues/393)
+
+.if !${FLAVOR:Mpython3}
+post-extract:
+   rm ${WRKSRC}/urwid/_async_kw_event_loop.py
+.endif
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/devel/py-urwid/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo7 Jan 2020 12:09:00 -   1.10
+++ distinfo13 Jan 2020 14:46:51 -
@@ -1,2 +1,2 @@
-SHA256 (urwid-2.0.1.tar.gz) = ZE0+OQCGcWGi/JKHqXYnU9Zr0ZR1Rnmtsmrt5Vm8zLw=
-SIZE (urwid-2.0.1.tar.gz) = 604167
+SHA256 (urwid-2.1.0.tar.gz) = CJbzYGC+tr84ActVQwP+8zanlmFAF5dVG6EG0jq0zYY=
+SIZE (urwid-2.1.0.tar.gz) = 630226
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-urwid/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST   7 Jan 2020 12:09:00 -   1.7
+++ pkg/PLIST   13 Jan 2020 14:46:51 -
@@ -1,4 +1,4 @@
-@comment $OpenBSD: PLIST,v 1.7 2020/01/07 12:09:00 sthen Exp $
+@comment $OpenBSD: PLIST,v$
 lib/python${MODPY_VERSION}/site-packages/urwid/
 
lib/python${MODPY_VERSION}/site-packages/urwid-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
 
lib/python${MODPY_VERSION}/site-packages/urwid-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -9,6 +9,7 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/urwid/__init__.py
 
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/urwid/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/urwid/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/urwid/${MODPY_PYCACHE}_async_kw_event_loop.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/urwid/${MODPY_PYCACHE}canvas.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/urwid/${MODPY_PYCACHE}command_map.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/urwid/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}pyc
@@ -24,6 +25,7 @@ 

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 08:24:21

Modified files:
net/p5-Net-Whois-RIPE: Makefile distinfo 

Log message:
Update to p5-Net-Whois-RIPE-2.007004.



Re: [update] databases/redis-5.0.7

2020-02-06 Thread Daniel Jakots
Hi Theo,

Thanks for working on that!

On Thu, 6 Feb 2020 15:21:23 +0100, Theo Buehler 
wrote:

> First of all, despite the length of this mail, most of the update is
> straightforward. The diff is an in-place upgrade from 4.0.14 to 5.0.7.
> 
> The release notes (which contain migration instructions at the very
> end)
> 
> https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES

Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a
user there is nothing to do. I guess you don't plan to add anything to
current.html do you?

> look as if there is no risk of losing data due to the migration and
> looking around on the net I couldn't find any reports of breakage.
> However, I don't know and can't know for sure.
> 
> Since we're playing with user data here, it might be more prudent to
> provide a redis5 port, and to leave it to the users to decide if and
> when they want to migrate instead of forcing it upon them right when
> the update goes in (or when they upgrade to 6.7).

AFAIK, redis is (or should be) used as a cache i.e. losing its data is
a small inconvenience but shouldn't be a problem. I don't think
duplicating the port is worth it.

> A detail: redis-sentinel is installed as a symlink to redis-server.
> Ports seem to do this frequently, but I wonder if that should be
> turned into a hard link as is usually done in base?

What are the pro/cons of using a hard link instead?

Cheers,
Daniel



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Theo Buehler
CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/02/06 07:46:16

Modified files:
devel/protobuf : Makefile distinfo 

Log message:
Update to protobuf-3.11.3. Ignoring version number bumps, no actual code
changes.

ok sthen, looks good to Greg Steuck



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 07:37:55

Modified files:
www/p5-pQuery  : Makefile distinfo 
www/p5-pQuery/pkg: PLIST 

Log message:
Update to p5-pQuery-0.24.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Jeremy Evans
CVSROOT:/cvs
Module name:ports
Changes by: jer...@cvs.openbsd.org  2020/02/06 07:26:35

Added files:
databases/pg_statsinfo: 

patch-src_drivers_postgresql_PostgresqlTypes_cpp 
patch-src_sql_drivers_psql_qsql_psql_cpp 

Log message:
Add patches missed earlier to allow building with PostgreSQL 12



[update] databases/redis-5.0.7

2020-02-06 Thread Theo Buehler
Here is an update for Redis to the latest stable version 5.0.7.
I'd like to ask for tests, feedback and some advice.

First of all, despite the length of this mail, most of the update is
straightforward. The diff is an in-place upgrade from 4.0.14 to 5.0.7.

The release notes (which contain migration instructions at the very end)

https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES

look as if there is no risk of losing data due to the migration and
looking around on the net I couldn't find any reports of breakage.
However, I don't know and can't know for sure.

Since we're playing with user data here, it might be more prudent to
provide a redis5 port, and to leave it to the users to decide if and
when they want to migrate instead of forcing it upon them right when
the update goes in (or when they upgrade to 6.7).


There's one new patch for src/zmalloc.c that deserves some discussion,
since it would also be needed for the Redis version we have in the tree:

Redis uses its own wrappers for the malloc(3) family of functions and
keeps track of the allocated sizes in a prefix for each allocation.
Among other things like stats and optimization, it uses this information
to implement zmalloc_size(), its own version of malloc_usable_size(3) if
that isn't already available by the system's memory allocator.

Unfortunately, zmalloc_size() doesn't report the actually allocated
size. Rather, it rounds it up to sizeof(long) granularity, and there is
code assuming that it is safe to just use the rounded up number of
bytes. When running with vm.malloc_conf=C this is obviously deadly upon
free. This can be observed by exceptions that are thrown during regress
because the redis-server died (more or less) unexpectedly.

I see two approaches to fix this: The simpler but riskier way is to
remove the rounding up from zmalloc_size(). Since the code may make the
assumption of having more than the actually allocated number bytes
available without actually asking zmalloc_size(), it seems safer to just
allocate the rounded up number of bytes, so zmalloc_size() returns the
same number as before, but the bytes are actually available for the
program.


A detail: redis-sentinel is installed as a symlink to redis-server.
Ports seem to do this frequently, but I wonder if that should be turned
into a hard link as is usually done in base?


I have successfully built this version on amd64, i386 and macppc and ran
the test suite successfully multiple times on each of these platforms.
Unfortunately, the few consumers we have in tree have more or less
broken test suites (ruby-redis seems to be the only one that's happy
whereas I couldn't get the tests for rspamd, py-redis, and p5-Redis to
work meaningfully).

Finally, many thanks to mikeb@ for his feedback on earlier iterations of
this patch.

Index: Makefile
===
RCS file: /var/cvs/ports/databases/redis/Makefile,v
retrieving revision 1.108
diff -u -p -r1.108 Makefile
--- Makefile12 Jul 2019 20:44:01 -  1.108
+++ Makefile5 Feb 2020 11:34:07 -
@@ -1,10 +1,9 @@
 # $OpenBSD: Makefile,v 1.108 2019/07/12 20:44:01 sthen Exp $
 
 COMMENT =  persistent key-value database
-DISTNAME = redis-4.0.14
+DISTNAME = redis-5.0.7
 CATEGORIES =   databases
 HOMEPAGE = https://redis.io/
-REVISION = 0
 
 # BSD
 PERMIT_PACKAGE =   Yes
Index: distinfo
===
RCS file: /var/cvs/ports/databases/redis/distinfo,v
retrieving revision 1.83
diff -u -p -r1.83 distinfo
--- distinfo2 Apr 2019 22:13:11 -   1.83
+++ distinfo5 Feb 2020 11:34:07 -
@@ -1,2 +1,2 @@
-SHA256 (redis-4.0.14.tar.gz) = Hh4YQgqGz7KFkzEjsEqC4evaIL+woolHJ0Wgh1h+k6c=
-SIZE (redis-4.0.14.tar.gz) = 1740967
+SHA256 (redis-5.0.7.tar.gz) = Ydt06r9oAfBX/SS1kCMvLzN9QiKA/RlIbsoDvofTqCs=
+SIZE (redis-5.0.7.tar.gz) = 1984203
Index: patches/patch-deps_Makefile
===
RCS file: /var/cvs/ports/databases/redis/patches/patch-deps_Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 patch-deps_Makefile
--- patches/patch-deps_Makefile 9 Aug 2017 09:16:09 -   1.10
+++ patches/patch-deps_Makefile 5 Feb 2020 11:34:07 -
@@ -48,7 +48,7 @@ Index: deps/Makefile
 -
 -jemalloc: .make-prerequisites
 -  @printf '%b %b\n' $(MAKECOLOR)MAKE$(ENDCOLOR) $(BINCOLOR)$@$(ENDCOLOR)
--  cd jemalloc && ./configure --with-lg-quantum=3 
--with-jemalloc-prefix=je_ --enable-cc-silence CFLAGS="$(JEMALLOC_CFLAGS)" 
LDFLAGS="$(JEMALLOC_LDFLAGS)"
+-  cd jemalloc && ./configure --with-version=5.1.0-0-g0 
--with-lg-quantum=3 --with-jemalloc-prefix=je_ --enable-cc-silence 
CFLAGS="$(JEMALLOC_CFLAGS)" LDFLAGS="$(JEMALLOC_LDFLAGS)"
 -  cd jemalloc && $(MAKE) CFLAGS="$(JEMALLOC_CFLAGS)" 
LDFLAGS="$(JEMALLOC_LDFLAGS)" lib/libjemalloc.a
 -
 -.PHONY: jemalloc
Index: 

Re: [NEW] sysutils/ssh-copy-id -- 2nd ok?

2020-02-06 Thread Kurt Mosiejczuk
On Thu, Feb 06, 2020 at 01:43:37PM +0100, Jan-Piet Mens wrote:
> > This version is OK sthen@ to import.

> Anybody willing to donate a second ok? :)

ok kmos.

Imported.

Thank you!

--Kurt



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Kurt Mosiejczuk
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/02/06 07:10:53

Modified files:
sysutils   : Makefile 

Log message:
Hook sysutils/ssh-copy-id up to the build



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Kurt Mosiejczuk
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/02/06 07:10:05

Log message:
sysutils/ssh-copy-id(1), a script to copy one's SSH keys to remote
hosts, ensuring that ~/.ssh and authorized_keys are created with
correct permissions

From Jan-Piet Mens

OK sthen@

Status:

Vendor Tag: kmos
Release Tags:   kmos_20200206

N ports/sysutils/ssh-copy-id/Makefile
N ports/sysutils/ssh-copy-id/distinfo
N ports/sysutils/ssh-copy-id/pkg/DESCR
N ports/sysutils/ssh-copy-id/pkg/PLIST

No conflicts created by this import



Re: [UPDATE] math/py-bottleneck-1.2.1 => 1.3.1

2020-02-06 Thread Kurt Mosiejczuk
On Thu, Feb 06, 2020 at 09:08:20AM +0100, Martin Reindl wrote:

> You are right, py-nose is needed for these tests. I will therefore go
> with this diff.

> Thank you for the help Kurt and Charlene!

One quick nit with this latest version


> -# one test fail:
> -# numpy 1.9.2 - median() don't check if array contains any nan's
> +MODPY_PYTEST =   Yes
> +TEST_DEPENDS =   devel/py-pluggy${MODPY_FLAVOR} \
> + devel/py-nose${MODPY_FLAVOR} \
> + devel/py-test${MODPY_FLAVOR}

These should be in alphabetical, so py-nose should be before py-pluggy.

otherwise, looks good to me - ok kmos

--Kurt



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 06:47:59

Modified files:
www/p5-HTML-TableContentParser: Makefile distinfo 

Log message:
Update to p5-HTML-TableContentParser-0.302.



Re: [NEW] sysutils/ssh-copy-id -- 2nd ok?

2020-02-06 Thread su.root
On 06/02   13:43, Jan-Piet Mens wrote:
> > This version is OK sthen@ to import.
> 
> Anybody willing to donate a second ok? :)
> 
>   -JP
> 
tested on two machines with no issues



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 06:29:23

Modified files:
www/p5-Cookie-Baker: Makefile distinfo 

Log message:
Update to p5-Cookie-Baker-0.11.



Re: [new] net/dino 0.1.0

2020-02-06 Thread Uwe Werler
On 06 Feb 11:54, Landry Breuil wrote:
> On Tue, Feb 04, 2020 at 07:20:58PM +0100, Landry Breuil wrote:
> > Hi,
> > 
> > here's a wip port for https://dino.im a modern xmpp/gtk client, quick
> > port that might need polishing (here it fails to start with "Gtk-ERROR
> > **: 19:19:17.373: failed to add UI: .:17:1 Invalid object type
> > 'DinoUiConversationSelector'" but that might just be a local fluke and
> > i'm just sending this one before going out..
> 
> and here's a version that actually starts and connects to an xmpp
> server, thanks to the FreeBSD hint from
> https://github.com/dino/dino/issues/438 to pass --export-dynamic to
> LDFLAGS via some cmake voodoo (set_target_properties(dino PROPERTIES
> ENABLE_EXPORTS TRUE)).
> 
> testers and oks welcome.
> 
> Landry

Hi Landry,

just tested with two accounts and it works like a charm.

Regards Uwe



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 06:18:48

Modified files:
textproc/p5-Text-Autoformat: Makefile distinfo 

Log message:
Update to p5-Text-Autoformat-1.75.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 06:07:36

Modified files:
textproc/p5-Lingua-EN-Sentence: Makefile distinfo 

Log message:
Update to p5-Lingua-EN-Sentence-0.31.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 06:03:20

Modified files:
textproc/p5-Lingua-EN-Fathom: Makefile distinfo 

Log message:
Update to p5-Lingua-EN-Fathom-1.22.



Re: [NEW] sysutils/ssh-copy-id -- 2nd ok?

2020-02-06 Thread Jan-Piet Mens

This version is OK sthen@ to import.


Anybody willing to donate a second ok? :)

-JP



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Martin Reindl
CVSROOT:/cvs
Module name:ports
Changes by: mar...@cvs.openbsd.org  2020/02/06 05:26:54

Modified files:
math/py-bottleneck: Makefile distinfo 
math/py-bottleneck/patches: patch-setup_py 
math/py-bottleneck/pkg: PLIST 

Log message:
update py-bootleneck to 1.3.1 and take maintainer

with help and extra testing from cwen@ and kmos@



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 04:52:09

Modified files:
security/clamav: Makefile distinfo 

Log message:
update to clamav-0.102.2, amongst others including a fix for a
possible DoS (out-of-bounds read -> crash) when using the credit card
data-loss-prevention feature.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 04:52:57

Modified files:
security/clamav: Tag: OPENBSD_6_6 Makefile distinfo 

Log message:
update -stable to clamav-0.102.2, amongst others including a fix for a
possible DoS (out-of-bounds read -> crash) when using the credit card
data-loss-prevention feature.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 04:30:32

Log message:
import mail/dovecot-fts-xapian, from Tom Wong-Cornall, looks good to landry@

fts-xapian is a full-text search plugin for Dovecot. It utilises the Xapian
search engine library to index email automatically, and allow rapid body and
header server-side search over IMAP.

The authors intend this plugin to provide the functionality provided by the
now-deprecated fts_squat plugin, and provide a simpler way to configure FTS 
for
Dovecot without needing heavy external dependencies such as Solr.

Status:

Vendor Tag: sthen
Release Tags:   sthen_20200206

N ports/mail/dovecot-fts-xapian/Makefile
N ports/mail/dovecot-fts-xapian/distinfo
N ports/mail/dovecot-fts-xapian/pkg/DESCR
N ports/mail/dovecot-fts-xapian/pkg/README
N ports/mail/dovecot-fts-xapian/pkg/PLIST

No conflicts created by this import



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 04:30:56

Modified files:
mail   : Makefile 

Log message:
+dovecot-fts-xapian



Re: UPDATE: mail/msmtp 1.6.6p1 -> 1.8.6

2020-02-06 Thread Stuart Henderson
Thanks - committed with small tweaks.

On 2020/02/02 18:58, Xiyue Deng wrote:
> Thanks Stuart for the reply.
> 
> Stuart Henderson  writes:
> 
> > On 2020/02/02 04:05, Xiyue Deng wrote:
> >> Seems no one cares about this port.  Is it OK that I apply for maintainer?
> >
> > Certainly. It is a bit easier to take patches from someone that feels
> > responsible enough for a port to be listed as maintainer :)
> >
> 
> Added myself as maintainer now :)
> 
> >>  >>> * Many of the patches just replace "#!/usr/bin/env bash" to
> >>  >>>   "#!/bin/sh".  Now most of scripts are changed to use 
> >>  >>> "#!/usr/bin/env
> >>  >>>   sh" which should now be the same thing.  Should we just drop 
> >>  >>> those
> >>  >>>   patches?
> >
> > It's not quite the same thing because env searches your path.
> > Explicit /bin/sh seems a much better idea to me so I'm happier to keep 
> > those.
> >
> 
> Sounds good.  Patches kept.
> 
> >>  >>> * One of the patches changes the system /etc/msmtprc to provide an
> >>  >>>   "account default" that listens on localhost:25, which will then 
> >>  >>> use
> >>  >>>   smtpd as server by default.  I think the intention is to 
> >>  >>> provide a
> >>  >>>   working configure that works out of the box.  However this may 
> >>  >>> not do
> >>  >>>   what you want because if one try to configure an account in a 
> >>  >>> user
> >>  >>>   configuration and somehow it contains errors (e.g. not properly
> >>  >>>   provide a "from" address), msmtp will just send the mail 
> >>  >>> through smtpd
> >>  >>>   and returns OK which will result in the mail stuck in the 
> >>  >>> system mail
> >>  >>>   queue forever.  So my suggestion is to leave this file 
> >>  >>> untouched so
> >>  >>>   that the system /etc/msmtprc will just provide a fake "account
> >>  >>>   default" and any mail not handled with a user provided account 
> >>  >>> will
> >>  >>>   fail immediately.
> >
> > i.e. remove patch-doc_msmtprc-system_example? I'd be ok with that.
> 
> Done.
> 
> A new release is also available so I've updated the patches accordingly
> and attached (not inlining to avoid PGP signature messing it up).
> Please take another look.
> 

> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/msmtp/Makefile,v
> retrieving revision 1.47
> diff -u -p -r1.47 Makefile
> --- Makefile  12 Jul 2019 20:47:30 -  1.47
> +++ Makefile  3 Feb 2020 02:55:18 -
> @@ -2,27 +2,29 @@
>  
>  COMMENT =SMTP plugin for MUAs
>  
> -DISTNAME =   msmtp-1.6.6
> +DISTNAME =   msmtp-1.8.7
>  CATEGORIES = mail
> -REVISION =   1
>  
>  HOMEPAGE =   https://marlam.de/msmtp/
>  
> +MAINTAINER = Xiyue Deng 
> +
>  # GPLv3
>  PERMIT_PACKAGE = Yes
>  
> -WANTLIB =  c crypto iconv idn intl ssl
> +WANTLIB =  c crypto iconv idn2 intl gnutls
>  
>  MASTER_SITES =   https://marlam.de/msmtp/releases/
>  EXTRACT_SUFX =   .tar.xz
>  
> -LIB_DEPENDS =devel/libidn
> +LIB_DEPENDS =devel/libidn2 \
> + security/gnutls
>  
>  SEPARATE_BUILD = Yes
>  CONFIGURE_STYLE =gnu
>  CONFIGURE_ARGS = --with-libgsasl=no \
>   --with-libidn=yes \
> - --with-tls=openssl \
> + --with-tls=gnutls \
>   --without-libsecret
>  
>  post-install:
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/msmtp/distinfo,v
> retrieving revision 1.30
> diff -u -p -r1.30 distinfo
> --- distinfo  26 Mar 2017 13:34:06 -  1.30
> +++ distinfo  3 Feb 2020 02:55:18 -
> @@ -1,2 +1,2 @@
> -SHA256 (msmtp-1.6.6.tar.xz) = 2hXbH2K9AgH85TEK24nIYYi+kc10W3yztiuBpQHn+14=
> -SIZE (msmtp-1.6.6.tar.xz) = 283744
> +SHA256 (msmtp-1.8.7.tar.xz) = mlO83CROxbGoBpNOzHdG2dCdtYH1h77fWX6dovSMUfE=
> +SIZE (msmtp-1.8.7.tar.xz) = 340908
> Index: patches/patch-doc_msmtprc-system_example
> ===
> RCS file: patches/patch-doc_msmtprc-system_example
> diff -N patches/patch-doc_msmtprc-system_example
> --- patches/patch-doc_msmtprc-system_example  13 Feb 2009 14:59:01 -  
> 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,16 +0,0 @@
> -$OpenBSD: patch-doc_msmtprc-system_example,v 1.1 2009/02/13 14:59:01 pirofti 
> Exp $
>  doc/msmtprc-system.example.orig  Sat Apr  7 18:20:34 2007
> -+++ doc/msmtprc-system.example   Fri Feb 13 16:53:09 2009
> -@@ -6,10 +6,10 @@
> - account default
> - 
> - # The SMTP smarthost.
> --host mailhub.oursite.example
> -+host localhost
> - 
> - # Construct envelope-from addresses of the form "user@oursite.example".
> --#auto_from on
> -+auto_from on
> - #maildomain oursite.example
> - 
> - # Use TLS.
> Index: 

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 04:26:10

Modified files:
mail/msmtp : Makefile distinfo 
mail/msmtp/patches: patch-scripts_msmtpq_msmtp-queue 
patch-scripts_msmtpq_msmtpq 
patch-scripts_msmtpqueue_msmtp-enqueue_sh 
patch-scripts_msmtpqueue_msmtp-listqueue_sh 
patch-scripts_msmtpqueue_msmtp-runqueue_sh 
patch-scripts_set_sendmail_set_sendmail_sh 
Removed files:
mail/msmtp/patches: patch-doc_msmtprc-system_example 

Log message:
update to msmtp-1.8.7, from Xiyue Deng (taking maintainer), plus I fixed
WANTLIB and regen'd patches (mostly with the same result but I tweaked
one to make it easier to compare the new with the previous line)



Re: [update patch] getmail 5.7 -> 5.14

2020-02-06 Thread Stuart Henderson
On 2020/02/05 11:23, Martin Ziemer wrote:
> This patch updates getmail from 5.7 to 5.14.
> 
> Since i saw there is no maintainer, i also added myself as maintainer.
> 
> I ran this version now for a week on three amd64 systems.
> 
> It would be great, if someone would update the port.

Committed - I removed the REVISION line and changed whitespace on the
MAINTAINER line to match the rest of the file.


> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/getmail/Makefile,v
> retrieving revision 1.97
> diff -u -p -r1.97 Makefile
> --- Makefile  12 Jul 2019 20:47:27 -  1.97
> +++ Makefile  5 Feb 2020 10:16:04 -
> @@ -2,12 +2,14 @@
>  
>  COMMENT= IMAP/POP3/SDPS mail retriever
>  
> -MODPY_EGG_VERSION=   5.7
> +MODPY_EGG_VERSION=   5.14
>  DISTNAME=getmail-${MODPY_EGG_VERSION}
>  CATEGORIES=  mail
>  REVISION=0
>  
>  HOMEPAGE=http://pyropus.ca/software/getmail/
> +
> +MAINTAINER = Martin Ziemer 
>  
>  # GPLv2
>  PERMIT_PACKAGE=  Yes
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/getmail/distinfo,v
> retrieving revision 1.78
> diff -u -p -r1.78 distinfo
> --- distinfo  1 Nov 2018 04:22:15 -   1.78
> +++ distinfo  5 Feb 2020 10:16:04 -
> @@ -1,2 +1,2 @@
> -SHA256 (getmail-5.7.tar.gz) = JJemaed8kpYhgmJANxtXuBV1AruIrlMMMDB7CSM6+/k=
> -SIZE (getmail-5.7.tar.gz) = 197799
> +SHA256 (getmail-5.14.tar.gz) = 86mf50VkI30Syo1FguETwGfJIFtatkD3K06ER2BqmcE=
> +SIZE (getmail-5.14.tar.gz) = 199501
> 



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/02/06 04:17:13

Modified files:
mail/getmail   : Makefile distinfo 

Log message:
Update to getmail-5.14, from Martin Ziemer who takes MAINTAINER
(I removed REVISION and adjusted whitespace from his submission)

Amongst other things this adds SNI support which will be needed to work
with gmail once TLS 1.3 client is reenabled in libressl.



Re: [new] net/dino 0.1.0

2020-02-06 Thread Landry Breuil
On Tue, Feb 04, 2020 at 07:20:58PM +0100, Landry Breuil wrote:
> Hi,
> 
> here's a wip port for https://dino.im a modern xmpp/gtk client, quick
> port that might need polishing (here it fails to start with "Gtk-ERROR
> **: 19:19:17.373: failed to add UI: .:17:1 Invalid object type
> 'DinoUiConversationSelector'" but that might just be a local fluke and
> i'm just sending this one before going out..

and here's a version that actually starts and connects to an xmpp
server, thanks to the FreeBSD hint from
https://github.com/dino/dino/issues/438 to pass --export-dynamic to
LDFLAGS via some cmake voodoo (set_target_properties(dino PROPERTIES
ENABLE_EXPORTS TRUE)).

testers and oks welcome.

Landry


dino-0.1.0_2.tgz
Description: application/tar-gz


CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 03:40:59

Modified files:
net/p5-Net-DNS-DynDNS: Makefile distinfo 

Log message:
Update to p5-Net-DNS-DynDNS-0.9994.



Re: Update salt to 2019.2.3

2020-02-06 Thread Uwe Werler
On 05 Feb 23:39, Uwe Werler wrote:
> Hi,
> 
> this is an update to salt 2019.2.3.
> 
> I'm currently testing this version on our development salt master and haven't
> seen any issues yet wether with the master nor the minion.
> 
> Comments welcome.
> 
> Regards Uwe

Hi,

I included some changes Rafael suggested. But still the port needs further
testing.

Also cc to Jasper now.

Regards Uwe
Index: Makefile
===
RCS file: /cvs/ports/sysutils/salt/Makefile,v
retrieving revision 1.135
diff -u -p -u -r1.135 Makefile
--- Makefile12 Jul 2019 20:49:51 -  1.135
+++ Makefile6 Feb 2020 10:29:07 -
@@ -1,7 +1,7 @@
 # $OpenBSD: Makefile,v 1.135 2019/07/12 20:49:51 sthen Exp $
 
 # optional dependencies
-# https://github.com/saltstack/salt/blob/develop/doc/conf.py#L54
+# https://github.com/saltstack/salt/blob/develop/doc/conf.py
 # libvirt-python
 # py-GitPython
 # py-croniter
@@ -17,13 +17,12 @@
 
 COMMENT =  remote execution and configuration management system
 
-MODPY_EGG_VERSION =2018.3.3
+MODPY_EGG_VERSION =2019.2.3
 DISTNAME = salt-${MODPY_EGG_VERSION}
-REVISION = 0
 
 CATEGORIES =   sysutils net devel
 
-HOMEPAGE = http://saltstack.org/
+HOMEPAGE = https://community.saltstack.com
 
 MAINTAINER =   Jasper Lievisse Adriaanse 
 
@@ -71,10 +70,6 @@ TEST_DEPENDS =   databases/py-mysql \
net/rabbitmq \
sysutils/salt-testing \
www/py-CherryPy
-
-# https://github.com/saltstack/salt/pull/45164
-post-extract:
-   cp ${FILESDIR}/{pf,vmctl}.py ${WRKSRC}/salt/modules/
 
 pre-configure:
${SUBST_CMD} ${WRKSRC}/salt/returners/zabbix_return.py
Index: distinfo
===
RCS file: /cvs/ports/sysutils/salt/distinfo,v
retrieving revision 1.49
diff -u -p -u -r1.49 distinfo
--- distinfo28 Jan 2019 19:25:27 -  1.49
+++ distinfo6 Feb 2020 10:29:07 -
@@ -1,2 +1,2 @@
-SHA256 (salt-2018.3.3.tar.gz) = 3PMNLo6uEFpyl3xRz8JT+8TcKLL3Enf9zp013h62PhU=
-SIZE (salt-2018.3.3.tar.gz) = 13953724
+SHA256 (salt-2019.2.3.tar.gz) = dJfn2/1Nw3mbu8jaY9qYuDAbu2RBUPOQX+V3Wn2BJxo=
+SIZE (salt-2019.2.3.tar.gz) = 14572686
Index: files/pf.py
===
RCS file: files/pf.py
diff -N files/pf.py
--- files/pf.py 24 May 2018 16:59:40 -  1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,349 +0,0 @@
-# -*- coding: utf-8 -*-
-'''
-Control the OpenBSD packet filter (PF).
-
-:codeauthor: Jasper Lievisse Adriaanse 
-
-.. versionadded:: Fluorine
-'''
-
-from __future__ import absolute_import
-
-# Import python libs
-import logging
-import re
-
-# Import salt libs
-import salt.utils.path
-from salt.exceptions import (CommandExecutionError, SaltInvocationError)
-
-log = logging.getLogger(__name__)
-
-
-def __virtual__():
-'''
-Only works on OpenBSD for now; other systems with pf (macOS, FreeBSD, etc)
-need to be tested before enabling them.
-'''
-if __grains__['os'] == 'OpenBSD' and salt.utils.path.which('pfctl'):
-return True
-
-return (False, 'The pf execution module cannot be loaded: either the 
system is not OpenBSD or the pfctl binary was not found')
-
-
-def enable():
-'''
-Enable the Packet Filter.
-
-CLI example:
-
-.. code-block:: bash
-
-salt '*' pf.enable
-'''
-ret = {}
-result = __salt__['cmd.run_all']('pfctl -e',
- output_loglevel='trace',
- python_shell=False)
-
-if result['retcode'] == 0:
-ret = {'comment': 'pf enabled', 'changes': True}
-else:
-# If pf was already enabled the return code is also non-zero.
-# Don't raise an exception in that case.
-if result['stderr'] == 'pfctl: pf already enabled':
-ret = {'comment': 'pf already enabled', 'changes': False}
-else:
-raise CommandExecutionError(
-'Could not enable pf',
-info={'errors': [result['stderr']], 'changes': False}
-)
-
-return ret
-
-
-def disable():
-'''
-Disable the Packet Filter.
-
-CLI example:
-
-.. code-block:: bash
-
-salt '*' pf.disable
-'''
-ret = {}
-result = __salt__['cmd.run_all']('pfctl -d',
- output_loglevel='trace',
- python_shell=False)
-
-if result['retcode'] == 0:
-ret = {'comment': 'pf disabled', 'changes': True}
-else:
-# If pf was already disabled the return code is also non-zero.
-# Don't raise an exception in that case.
-if result['stderr'] == 'pfctl: pf not enabled':
-ret = {'comment': 'pf already disabled', 'changes': False}
-else:
-raise 

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Frederic Cambus
CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2020/02/06 03:37:26

Modified files:
graphics/grafx2: Makefile distinfo 
graphics/grafx2/patches: patch-Makefile 
graphics/grafx2/pkg: PLIST 
Added files:
graphics/grafx2/patches: patch-main_c 
Removed files:
graphics/grafx2/patches: patch-fileformats_c 

Log message:
Update grafx2 to 2.7.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 02:54:41

Modified files:
misc/p5-Finance-QuoteHist: Makefile distinfo 
misc/p5-Finance-QuoteHist/pkg: PLIST 

Log message:
Update to p5-Finance-QuoteHist-1.28.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Frederic Cambus
CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2020/02/06 02:36:31

Modified files:
games/asciiquarium: Makefile 

Log message:
Switch HOMEPAGE and MASTER_SITES to HTTPS.

Note that the distfile does not fetch over HTTPS at the moment, but as
upstream redirects HTTP to HTTPS, keeping MASTER_SITES on HTTP for now
does not help.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 02:36:17

Modified files:
misc/p5-I18N-Charset: Makefile distinfo 

Log message:
Update to p5-I18N-Charset-1.418.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 02:28:37

Modified files:
math/p5-Business-Hours: Makefile distinfo 

Log message:
Update to p5-Business-Hours-0.13.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 02:20:26

Modified files:
graphics/p5-Graphics-ColorNames-WWW: Makefile distinfo 

Log message:
Update to p5-Graphics-ColorNames-WWW-1.14.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Frederic Cambus
CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2020/02/06 02:09:09

Modified files:
net/libmaxminddb: Makefile 

Log message:
Update HOMEPAGE.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Frederic Cambus
CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2020/02/06 02:04:17

Modified files:
graphics/termtosvg: Makefile 

Log message:
Update HOMEPAGE.



CVS: cvs.openbsd.org: ports

2020-02-06 Thread Landry Breuil
CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/02/06 01:54:17

Modified files:
devel/nspr : Makefile distinfo 
devel/nspr/patches: patch-nspr_pr_tests_nameshm1_c 
patch-nspr_pr_tests_runtests_sh 

Log message:
Update to NSPR 4.25



Re: Update security/qtkeychain 0.7.0 => 0.10.0 and update dependent ports

2020-02-06 Thread Kirill Bychkov
On Tue, February 4, 2020 09:17, Rafael Sadowski wrote:
> On Sun Feb 02, 2020 at 02:03:03PM +0300, Kirill Bychkov wrote:
>> On Thu, January 30, 2020 09:03, Rafael Sadowski wrote:
>> > Hi All
>> >
>> > All our consumers only use the qt5 FLAVOR so here is an update diff
>> > which removes the the qt4 pieces and bump to the latest stable version
>> > on github. I did the same like the quazip update from Brian Callahan a
>> > couple days before. Added @pkgpath and bump all consumers.
>> >
>> > Comments, OK?
>>
>> Hi,
>> Makes sense to me but I prefer to split update and flavor removal.
>> Also it needs some tweaks to move 'mkspecs' from /usr/local to
>> /usr/local/lib/qt5/
>> Not tested yet.
>>
>
> You're right, ok for the diff below? It just remove the qt4 bits.
>
> RS

It is missing @conflict qtkeychain-qt5-*
With this change OK kirby@

>
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/qtkeychain/Makefile,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 Makefile
> --- Makefile  12 Jul 2019 20:49:35 -  1.13
> +++ Makefile  4 Feb 2020 06:14:29 -
> @@ -5,9 +5,8 @@ COMMENT = Qt API to store passwords and
>  GH_ACCOUNT = frankosterfeld
>  GH_PROJECT = qtkeychain
>  GH_TAGNAME = v0.7.0
> -REVISION =   3
> +REVISION =   4
>
> -SHARED_LIBS +=   qtkeychain  1.0 # 0.4
>  SHARED_LIBS +=   qt5keychain 1.0 # 0.4
>
>  CATEGORIES = security
> @@ -17,31 +16,16 @@ MAINTAINER =  Kirill Bychkov   # BSD-like
>  PERMIT_PACKAGE = Yes
>
> -WANTLIB =m ${COMPILER_LIBCXX}
> +WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5DBus m
>
> -COMPILER =   base-clang ports-gcc base-gcc
> +MODULES =devel/cmake \
> + x11/qt5
>
> -MODULES =devel/cmake
> -
> -FLAVORS =qt5
> -FLAVOR ?=
> -
> -.if ${FLAVOR:Mqt5}
> -FULLPKGNAME =qtkeychain-qt5-${GH_TAGNAME:S/v//}
> -MODULES +=   x11/qt5
> -WANTLIB +=   Qt5Core Qt5DBus
>  LIBNAME =Qt5Keychain
>  LIBNAME_L =  qt5keychain
>  QT = qt5
> +
>  CONFIGURE_ARGS +=-DBUILD_WITH_QT4=OFF
> -.else
> -MODULES +=   x11/qt4
> -WANTLIB +=   QtDBus
> -CONFIGURE_ARGS +=-DBUILD_WITH_QT4=ON
> -LIBNAME =QtKeychain
> -LIBNAME_L =  qtkeychain
> -QT = qt4
> -.endif
>
>  SUBST_VARS +=LIBNAME LIBNAME_L QT
>
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/security/qtkeychain/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 PLIST
> --- pkg/PLIST 6 May 2016 06:45:43 -   1.3
> +++ pkg/PLIST 4 Feb 2020 06:14:29 -
> @@ -1,4 +1,5 @@
>  @comment $OpenBSD: PLIST,v 1.3 2016/05/06 06:45:43 kirby Exp $
> +@pkgpath security/qtkeychain,qt5
>  include/${LIBNAME_L}/
>  include/${LIBNAME_L}/keychain.h
>  include/${LIBNAME_L}/qkeychain_export.h
>
>




Re: 回复: [Update]math/ntl:Update to 11.4.3

2020-02-06 Thread Benoit Lecocq




On 05/02/2020 14:00, Stuart Henderson wrote:

On 2020/02/05 10:27, Benoit Lecocq wrote:



On 05/02/2020 08:04, wen heping wrote:

Do you mean SHARED_LIBS should be modified ?
But the shared_libs.log say it is :
SHARED_LIBS +=  ntl                  9.2      # 0.0


Yes, we need :

SHARED_LIBS =ntl 10.0



shared_libs.log (if present) shows what it is currently set to in the
port, and what upstream has set.

Some upstreams follow the rules for updating the library version numbers
but many do not so we do our own checks.



Committed, thanks !



wen

*发件人:* Stuart Henderson 
*发送时间:* 2020年2月4日 22:35
*收件人:* wen heping 
*抄送:* ben...@openbsd.org ; ports@openbsd.org

*主题:* Re: [Update]math/ntl:Update to 11.4.3
https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs

On 2020/02/04 13:56, wen heping wrote:

Hi,

     Here is a patch for math/ntl:
  i) Update to 11.4.3
  ii) Switch HOMEPAGE to https

     It build well , run well and pass  tests on amd64-current system.
     No other ports depends on it.

Cheers !
wen



Index: Makefile
===
RCS file: /cvs/ports/math/ntl/Makefile,v
retrieving revision 1.52
diff -u -p -r1.52 Makefile
--- Makefile  12 Jul 2019 20:47:43 -  1.52
+++ Makefile  4 Feb 2020 13:50:29 -
@@ -2,12 +2,11 @@
   COMMENT =    Victor Shoup's Number Theory Library
-DISTNAME =   ntl-9.11.0
-REVISION =   3
+DISTNAME =   ntl-11.4.3
   SHARED_LIBS =    ntl 9.2 # 0.0
   CATEGORIES = math
-HOMEPAGE =   http://www.shoup.net/ntl/
+HOMEPAGE =   https://www.shoup.net/ntl/
   MAINTAINER = Benoit Lecocq 
@@ -39,7 +38,8 @@ do-install:
     @${INSTALL_DATA_DIR} ${PREFIX}/include/NTL
     @cd ${WRKSRC}/include/NTL; ${INSTALL_DATA} *.h ${PREFIX}/include/NTL
     @cd ${WRKBUILD}; ${INSTALL_DATA} .libs/libntl.a  ${PREFIX}/lib/libntl.a
- @cd ${WRKBUILD}; ${INSTALL_DATA} .libs/libntl.so.${LIBntl_VERSION} 
${PREFIX}/lib/libntl.so.${LIBntl_VERSION}
+ @cd ${WRKBUILD}; ${INSTALL_DATA} .libs/libntl.so.${LIBntl_VERSION} \
+ ${PREFIX}/lib/libntl.so.${LIBntl_VERSION}
     @${INSTALL_DATA_DIR} ${PREFIX}/share/doc/NTL
     @cd ${WRKSRC}/doc; ${INSTALL_DATA} * ${PREFIX}/share/doc/NTL
Index: distinfo
===
RCS file: /cvs/ports/math/ntl/distinfo,v
retrieving revision 1.32
diff -u -p -r1.32 distinfo
--- distinfo  30 Aug 2016 06:52:57 -  1.32
+++ distinfo  4 Feb 2020 13:50:29 -
@@ -1,2 +1,2 @@
-SHA256 (ntl-9.11.0.tar.gz) = N5kBcJ5qv+qhykH8NuCnRmBMxggjfGYpBYUFv9jtnPE=
-SIZE (ntl-9.11.0.tar.gz) = 960952
+SHA256 (ntl-11.4.3.tar.gz) = t8HM3GSEDmokNR60oeaIh9KZdPAwc6GUHJBlYsC4OtI=
+SIZE (ntl-11.4.3.tar.gz) = 2274421
Index: patches/patch-src_DoConfig
===
RCS file: /cvs/ports/math/ntl/patches/patch-src_DoConfig,v
retrieving revision 1.9
diff -u -p -r1.9 patch-src_DoConfig
--- patches/patch-src_DoConfig    31 Jan 2016 09:03:50 -  1.9
+++ patches/patch-src_DoConfig    4 Feb 2020 13:50:29 -
@@ -1,22 +1,20 @@
-$OpenBSD: patch-src_DoConfig,v 1.9 2016/01/31 09:03:50 benoit Exp $
 src/DoConfig.orig    Sat Jan 30 22:15:16 2016
-+++ src/DoConfig Sun Jan 31 08:40:55 2016
-@@ -14,24 +14,26 @@
+$OpenBSD$
+
+Index: src/DoConfig
+--- src/DoConfig.orig
 src/DoConfig
+@@ -13,8 +13,8 @@ system("echo '*** CompilerOutput.log ***' > CompilerOu
    %MakeVal = (
   -'CXX' => 'g++',
   -'CXXFLAGS'    => '-g -O2',
   +'CXX' => '${CXX}',
-+'CXXFLAGS'    => '$(CFLAGS)',
++'CXXFLAGS'    => '${CFLAGS}',
    'CXXAUTOFLAGS'=> '',
+ 'NOCONTRACT'  => '',
    'AR'  => 'ar',
- 'ARFLAGS' => 'ruv',
- 'RANLIB'  => 'ranlib',
--'LIBTOOL' => 'libtool',
-+'LIBTOOL' => '${LIBTOOL}',
- - 'LDFLAGS' => '',
+@@ -28,12 +28,14 @@ system("echo '*** CompilerOutput.log ***' > CompilerOu
    'LDLIBS'  => '-lm',
    'CPPFLAGS'    => '',
Index: patches/patch-src_GF2EX_c
===
RCS file: patches/patch-src_GF2EX_c
diff -N patches/patch-src_GF2EX_c
--- patches/patch-src_GF2EX_c 15 Mar 2014 09:13:13 -  1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_GF2EX_c,v 1.3 2014/03/15 09:13:13 benoit Exp $
 src/GF2EX.c.orig Fri Feb 15 15:44:26 2013
-+++ src/GF2EX.c  Tue Feb 19 10:26:58 2013
-@@ -6,6 +6,8 @@
- - #include 
- -+#include 
-+
- NTL_START_IMPL
- - Index: pkg/PLIST
===
RCS file: /cvs/ports/math/ntl/pkg/PLIST,v
retrieving revision 1.16
diff -u -p -r1.16 PLIST
--- pkg/PLIST 7 Jun 2016 13:35:28 -   1.16
+++ pkg/PLIST 4 Feb 2020 13:50:29 -
@@ -1,7 +1,10 @@
   @comment $OpenBSD: PLIST,v 1.16 2016/06/07 13:35:28 benoit Exp $
   include/NTL/

CVS: cvs.openbsd.org: ports

2020-02-06 Thread Benoit Lecocq
CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2020/02/06 01:10:00

Modified files:
math/ntl   : Makefile distinfo 
math/ntl/patches: patch-src_DoConfig 
math/ntl/pkg   : PLIST 
Removed files:
math/ntl/patches: patch-src_GF2EX_c 

Log message:
Update to ntl-11.4.3 from wen heping, thanks !



Re: [UPDATE] math/py-bottleneck-1.2.1 => 1.3.1

2020-02-06 Thread Martin Reindl
On Wed, Feb 05, 2020 at 03:05:40PM -0500, Kurt Mosiejczuk wrote:
> On Wed, Feb 05, 2020 at 09:35:45AM +0100, Martin Reindl wrote:
> 
> > > py-nose is needed. It *shouldn't* be, but a number of the tests require 
> > > it.
> > > (The tests could be rewritten to just use py-test).
> 
> > > Once py-nose is in TEST_DEPENDS, all tests pass on sparc64.
> 
> > Thanks for testing Kurt. Can you please explain where this comes from?
> 
> > RELEASE.rst states it is not needed anymore since 1.3.0 because the test 
> > suite
> > now uses pytest. Also see:
> 
> > https://github.com/pydata/bottleneck/pull/222
> 
> > In addition, I see no other reference in the code to py-nose, or when 
> > building
> > with PORTS_PRIVSEP.
> 
> > But maybe I am overlooking something.
> 
> Did you remove py-nose before running your tests? I tried running and a
> number of them failed because they were using py-nose-only constructs.
> 
> That pull request that got merged changes much to depend on py-test, but does
> not rewrite the tests in question.

You are right, py-nose is needed for these tests. I will therefore go with this
diff.

Thank you for the help Kurt and Charlene!

-m


Index: Makefile
===
RCS file: /cvs/ports/math/py-bottleneck/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- Makefile12 Jul 2019 20:47:46 -  1.8
+++ Makefile6 Feb 2020 07:54:33 -
@@ -1,25 +1,26 @@
 # $OpenBSD: Makefile,v 1.8 2019/07/12 20:47:46 sthen Exp $
 
-BROKEN-powerpc = bottleneck/src/move.c:568: internal compiler error: in 
extract_insn, at recog.c:2077
-
 COMMENT =  fast NumPy array functions written in C
 
-MODPY_EGG_VERSION =1.2.1
+MODPY_EGG_VERSION =1.3.1
 DISTNAME = Bottleneck-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME:L}
 CATEGORIES =   math
-REVISION = 1
+
+MAINTAINER =   Martin Reindl 
 
 # BSD
 PERMIT_PACKAGE =   Yes
 
-WANTLIB += ${MODPY_WANTLIB} pthread
+WANTLIB += ${MODPY_WANTLIB} pthread
+
+# ICE with base-gcc
+COMPILER = base-clang ports-gcc
 
 MODULES =  lang/python
 
 RUN_DEPENDS =  math/py-numpy${MODPY_FLAVOR}
 BUILD_DEPENDS =${RUN_DEPENDS}
-TEST_DEPENDS = devel/py-nose${MODPY_FLAVOR}
 
 MODPY_PI = Yes
 MODPY_SETUPTOOLS = Yes
@@ -27,8 +28,12 @@ MODPY_SETUPTOOLS =   Yes
 FLAVORS =  python3
 FLAVOR ?=
 
-# one test fail:
-# numpy 1.9.2 - median() don't check if array contains any nan's
+MODPY_PYTEST = Yes
+TEST_DEPENDS = devel/py-pluggy${MODPY_FLAVOR} \
+   devel/py-nose${MODPY_FLAVOR} \
+   devel/py-test${MODPY_FLAVOR}
+
+# on python2 with base-clang, test_memory_leak fails
 pre-test:
@${MODPY_CMD} build_ext --inplace
 
Index: distinfo
===
RCS file: /cvs/ports/math/py-bottleneck/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- distinfo16 May 2017 14:57:28 -  1.2
+++ distinfo6 Feb 2020 07:54:33 -
@@ -1,2 +1,2 @@
-SHA256 (Bottleneck-1.2.1.tar.gz) = bvzeX4MK7WT+r8oDWbUdsOGExyr4umZ1tKmfJjki6zY=
-SIZE (Bottleneck-1.2.1.tar.gz) = 105225
+SHA256 (Bottleneck-1.3.1.tar.gz) = RRWGNwRiy2I9atYEpUXR6X+1HSq1JSsaxXNQqD5JSig=
+SIZE (Bottleneck-1.3.1.tar.gz) = 88192
Index: patches/patch-setup_py
===
RCS file: /cvs/ports/math/py-bottleneck/patches/patch-setup_py,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-setup_py
--- patches/patch-setup_py  16 May 2017 14:57:28 -  1.2
+++ patches/patch-setup_py  6 Feb 2020 07:54:33 -
@@ -2,25 +2,39 @@ $OpenBSD: patch-setup_py,v 1.2 2017/05/1
 Index: setup.py
 --- setup.py.orig
 +++ setup.py
-@@ -32,17 +32,17 @@ def prepare_modules():
- make_c_files()
- ext = [Extension("bottleneck.reduce",
-  sources=["bottleneck/src/reduce.c"],
-- extra_compile_args=['-O2'])]
-+ extra_compile_args=[])]
- ext += [Extension("bottleneck.move",
-   sources=["bottleneck/src/move.c",
-"bottleneck/src/move_median/move_median.c"],
--  extra_compile_args=['-O2'])]
-+  extra_compile_args=[])]
- ext += [Extension("bottleneck.nonreduce",
-   sources=["bottleneck/src/nonreduce.c"],
--  extra_compile_args=['-O2'])]
-+  extra_compile_args=[])]
- ext += [Extension("bottleneck.nonreduce_axis",
-   sources=["bottleneck/src/nonreduce_axis.c"],
--  extra_compile_args=['-O2'])]
-+  extra_compile_args=[])]
+@@ -108,7 +108,7 @@ def prepare_modules():
+ "bottleneck.reduce",
+ sources=["bottleneck/src/reduce.c"],
+ 

  1   2   >