Re: [update] dunst-1.3.0

[Timo Myyrä]

timo.my...@bittivirhe.fi (Timo Myyrä) writes:

> Hi,
>
> As mentioned, here's update to dunst to bring it to latest version.
> Also includes pledge tweak to fix the port when using icons in notifications.
>
> Quickly tested on amd64 where icons work. More tests would be welcome.
>
> Timo
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/dunst/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile  31 Aug 2017 20:57:00 -  1.3
> +++ Makefile  13 Jan 2018 15:18:53 -
> @@ -4,13 +4,13 @@ COMMENT=customizable and lightweight no
>  
>  GH_ACCOUNT = dunst-project
>  GH_PROJECT = dunst
> -GH_TAGNAME = v1.2.0
> +GH_TAGNAME = v1.3.0
>  
>  CATEGORIES = x11
>  
>  HOMEPAGE=https://dunst-project.org/
>  
> -MAINTAINER = Timo Myyra 
> +MAINTAINER = Timo Myyra 
>  
>  # BSD
>  PERMIT_PACKAGE_CDROM=Yes
> Index: distinfo
> ===
> RCS file: /cvs/ports/x11/dunst/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo  31 Aug 2017 20:57:00 -  1.2
> +++ distinfo  13 Jan 2018 15:18:53 -
> @@ -1,2 +1,2 @@
> -SHA256 (dunst-1.2.0.tar.gz) = o8BbXvh+iHBKYgcjbkJ3PfvPUMsjx89R5JSnI2t1xa0=
> -SIZE (dunst-1.2.0.tar.gz) = 110628
> +SHA256 (dunst-1.3.0.tar.gz) = dMCxFlz3qccfVivZdpeXBSjq5iXTTIcU+LmVG9XKW+Y=
> +SIZE (dunst-1.3.0.tar.gz) = 121499
> Index: patches/patch-config_mk
> ===
> RCS file: /cvs/ports/x11/dunst/patches/patch-config_mk,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-config_mk
> --- patches/patch-config_mk   31 Aug 2017 20:57:00 -  1.2
> +++ patches/patch-config_mk   13 Jan 2018 15:18:53 -
> @@ -2,12 +2,12 @@ $OpenBSD: patch-config_mk,v 1.2 2017/08/
>  Index: config.mk
>  --- config.mk.orig
>  +++ config.mk
> -@@ -28,7 +28,7 @@ endif
> +@@ -12,7 +12,7 @@ MANPREFIX = ${PREFIX}/share/man
>   
>   # flags
>   CPPFLAGS += -D_DEFAULT_SOURCE -DVERSION=\"${VERSION}\"
>  -CFLAGS   += -g --std=gnu99 -pedantic -Wall -Wno-overlength-strings -Os 
> ${STATIC} ${CPPFLAGS}
>  +CFLAGS   += -g --std=gnu99 -pedantic -Wall -Wno-overlength-strings 
> ${STATIC} ${CPPFLAGS}
> + LDFLAGS  += -lm -L${X11LIB}
>   
> - pkg_config_packs := dbus-1 x11 xscrnsaver \
> - "glib-2.0 >= 2.36" gio-2.0 \
> + CPPFLAGS_DEBUG := -DDEBUG_BUILD
> Index: patches/patch-src_dunst_c
> ===
> RCS file: /cvs/ports/x11/dunst/patches/patch-src_dunst_c,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_dunst_c
> --- patches/patch-src_dunst_c 31 Aug 2017 20:57:00 -  1.1
> +++ patches/patch-src_dunst_c 13 Jan 2018 15:18:53 -
> @@ -3,23 +3,34 @@ $OpenBSD: patch-src_dunst_c,v 1.1 2017/0
>  Index: src/dunst.c
>  --- src/dunst.c.orig
>  +++ src/dunst.c
> -@@ -14,6 +14,9 @@
> - #include 
> - #include 
> +@@ -5,12 +5,14 @@
> + #include "dunst.h"
>   
> + #include 
>  +#include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
>  +#include 
> -+
> + 
>   #include "dbus.h"
>   #include "menu.h"
> - #include "notification.h"
> -@@ -325,6 +328,9 @@ int dunst_main(int argc, char *argv[])
> - int owner_id = initdbus();
> - 
> - x_setup();
> -+
> -+if (pledge("stdio rpath proc exec", NULL) == -1)
> -+err(1, "pledge");
> +@@ -193,6 +195,15 @@ int dunst_main(int argc, char *argv[])
> +  * graceful termination */
> + guint term_src = g_unix_signal_add(SIGTERM, quit_signal, NULL);
> + guint int_src = g_unix_signal_add(SIGINT, quit_signal, NULL);
> ++
> ++/* allow prot_exec if icons are used */
> ++if (settings.icon_position != icons_off) {
> ++if (pledge("stdio rpath proc exec prot_exec", NULL) == -1)
> ++err(1, "pledge");
> ++} else {
> ++if (pledge("stdio rpath proc exec", NULL) == -1)
> ++err(1, "pledge");
> ++}
>   
> - if (settings.startup_notification) {
> - notification *n = notification_create();
> + run(NULL);
> + g_main_loop_run(mainloop);
> Index: patches/patch-src_menu_c
> ===
> RCS file: /cvs/ports/x11/dunst/patches/patch-src_menu_c,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_menu_c
> --- patches/patch-src_menu_c  31 Aug 2017 20:57:00 -  1.1
> +++ patches/patch-src_menu_c  13 Jan 2018 15:18:53 -
> @@ -11,7 +11,7 @@ Index: src/menu.c
>  -"\\b(https?://|ftps?://|news://|mailto:|file://|www\\.)"
>  -"[-[:alnum:]_\\@;/?:&=%$.+!*\x27,~#]*"
>  -
> "(\\([-[:alnum:]_\\@;/?:&=%$.+!*\x27,~#]*\\)|[-[:alnum:]_\\@;/?:&=%$+*~])+";
> -+char *regex = 
> 

Re: [update] kawa-3.0

[Timo Myyrä]

timo.my...@bittivirhe.fi (Timo Myyrä) writes:

> Hi,
>
> Re-sending earlier diff to bring kawa to latest release.
>
> Timo
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/kawa/Makefile,v
> retrieving revision 1.15
> diff -u -p -r1.15 Makefile
> --- Makefile  19 Sep 2017 19:23:04 -  1.15
> +++ Makefile  12 Jan 2018 22:09:18 -
> @@ -2,7 +2,7 @@
>  
>  COMMENT= Scheme and language framework for the Java platform
>  
> -DISTNAME=kawa-2.4
> +DISTNAME=kawa-3.0
>  CATEGORIES=  lang java
>  
>  HOMEPAGE=https://www.gnu.org/software/kawa/
> @@ -27,7 +27,7 @@ BUILD_DEPENDS=  print/texinfo \
>   ${MODGNU_AUTOCONF_DEPENDS} \
>   ${MODGNU_AUTOMAKE_DEPENDS}
>  
> -CONFIGURE_STYLE= gnu
> +CONFIGURE_STYLE= autoconf no-autoheader
>  CONFIGURE_ARGS+= --enable-kawa-frontend
>  CONFIGURE_ENV+=  AUTOMAKE=${LOCALBASE}/bin/automake-1.15 \
>   AUTOCONF=${LOCALBASE}/bin/autoconf-2.69
> @@ -56,6 +56,8 @@ TEST_FLAGS =DIFF=diff \
>  
>  pre-patch:
>   find ${WRKSRC} -type f | \
> - xargs sed -i 's,^JAR =.*,JAR = ${JAVA_HOME}/bin/jar,g'
> + xargs fgrep -l "JAR =" | \
> + xargs sed -i 's,^JAR =.*,JAR = ${JAVA_HOME}/bin/jar,g'; \
> + touch ${WRKSRC}/configure.ac
>  
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/kawa/distinfo,v
> retrieving revision 1.4
> diff -u -p -r1.4 distinfo
> --- distinfo  31 Aug 2017 06:33:05 -  1.4
> +++ distinfo  12 Jan 2018 22:09:18 -
> @@ -1,2 +1,2 @@
> -SHA256 (kawa-2.4.tar.gz) = FMCL6BYxoeuLiSbKI1GYyhZRVsDBeey+boONP0tHY10=
> -SIZE (kawa-2.4.tar.gz) = 3285436
> +SHA256 (kawa-3.0.tar.gz) = Hm6FIXvW2MKgw0eIgqRXAxTfa5UHj+exIlkRw5q/OM0=
> +SIZE (kawa-3.0.tar.gz) = 3393879
> Index: patches/patch-bin_kawa_sh_in
> ===
> RCS file: patches/patch-bin_kawa_sh_in
> diff -N patches/patch-bin_kawa_sh_in
> --- patches/patch-bin_kawa_sh_in  31 Aug 2017 06:33:05 -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,10 +0,0 @@
> -$OpenBSD: patch-bin_kawa_sh_in,v 1.1 2017/08/31 06:33:05 jasper Exp $
>  bin/kawa.sh.in.orig  Sun Apr  9 08:44:21 2017
> -+++ bin/kawa.sh.in   Sun Apr  9 08:44:30 2017
> -@@ -1,5 +1,5 @@
> - #!@KAWA_SHELL@
> --thisfile=`type -p $0`
> -+thisfile=`command -v $0`
> - case "$thisfile" in
> -   "") echo "installation error - can't find path to $0"; exit -1 ;;
> -   /*) ;;
> Index: patches/patch-doc_Makefile_am
> ===
> RCS file: patches/patch-doc_Makefile_am
> diff -N patches/patch-doc_Makefile_am
> --- patches/patch-doc_Makefile_am 31 Aug 2017 06:33:05 -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,19 +0,0 @@
> -$OpenBSD: patch-doc_Makefile_am,v 1.1 2017/08/31 06:33:05 jasper Exp $
>  doc/Makefile.am.orig Sat Mar 25 12:33:43 2017
> -+++ doc/Makefile.am  Sat Mar 25 12:34:24 2017
> -@@ -29,12 +29,11 @@ TEXI2PDF = texi2pdf
> - 
> - man_MANS = kawa.1 qexo.1
> - kawa.1: $(srcdir)/kawa.man
> --nroff -man $(srcdir)/kawa.man > tpm-kawa.1
> --mv tpm-kawa.1 kawa.1
> -+cp $(srcdir)/kawa.man kawa.1
> - 
> -+
> - qexo.1: $(srcdir)/qexo.man
> --nroff -man $(srcdir)/qexo.man > tpm-qexo1
> --mv tpm-qexo1 qexo.1
> -+cp $(srcdir)/qexo.man qexo.1
> - 
> - ../kawa-doc-$(VERSION).tar.gz: kawa.info $(KAWA_HTMLDIR)/index.html kawa.pdf
> - tar cf - $(KAWA_HTMLDIR)/*.html kawa.pdf|gzip -c --best >$@
> Index: patches/patch-gnu_xquery_testsuite_Makefile_am
> ===
> RCS file: patches/patch-gnu_xquery_testsuite_Makefile_am
> diff -N patches/patch-gnu_xquery_testsuite_Makefile_am
> --- patches/patch-gnu_xquery_testsuite_Makefile_am31 Aug 2017 06:33:05 
> -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,85 +0,0 @@
> -$OpenBSD: patch-gnu_xquery_testsuite_Makefile_am,v 1.1 2017/08/31 06:33:05 
> jasper Exp $
> -
> -Index: gnu/xquery/testsuite/Makefile.am
>  gnu/xquery/testsuite/Makefile.am.orig
> -+++ gnu/xquery/testsuite/Makefile.am
> -@@ -2,6 +2,7 @@ include $(top_srcdir)/Make-rules
> - 
> - KAWALIB = $(top_builddir)
> - KAWA = ../../../bin/kawa.sh
> -+DIFF = diff -b
> - EXTRA_CLEAN = tmp* *.log testing.zip */*.class
> - mostlyclean-am: mostlyclean-generic
> - rm -rf Mod1 Mod2
> -@@ -34,7 +35,7 @@ XQTS_JAVA_FLAGS = -Xmx120m
> - check-XQTS: RunXQTS.class
> - CLASSPATH=$(KAWALIB) \
> -   $(JAVA) $(XQTS_JAVA_FLAGS) gnu.xquery.testsuite.RunXQTS $(XQTS_DIR)
> --@if diff -b $(srcdir)/XQTS-trace.exp XQuery-trace.log; \
> -+@if $(DIFF) $(srcdir)/XQTS-trace.exp XQuery-trace.log; \
> -   then echo '# XQTS trace output matches'; \
> -   else echo 

FIX: devel/libffi on armv7/clang

[Brian Callahan]

Hi ports --

devel/libffi failed to build for me on my Orange Pi Zero (armv7) using 
the latest snapshot.
It's a clang thing, FreeBSD dealt with it like such: 
https://github.com/libffi/libffi/issues/162

So let's do the same thing.

The change in patches/patch_src_arm_ffi_c is also necessary. Without it, 
trying to build

py-setuptools Abort Traps immediately. With the patch, everything seems OK.

However, a ton of tests fail:
# of expected passes    10
# of unexpected failures    685
# of unresolved testcases   675
But I don't know the previous state of things. So I don't know if this 
is a change or as

expected.

Finally, it looks like libffi needs libc++abi on arm for at least some 
functions, as
experienced with lang/snobol4, its configure script didn't pick up 
libffi and instead

complained about this:
/usr/local/lib/libffi.so.1.2: undefined reference to 
`__aeabi_unwind_cpp_pr0'
/usr/local/lib/libffi.so.1.2: undefined reference to 
`__aeabi_unwind_cpp_pr1'

Those functions are in libc++abi.

Also taking suggestions for #ifdef __arm__ defines in the event they 
would also catch

arm64.

Comments/OK?

~Brian

Index: Makefile
===
RCS file: /cvs/ports/devel/libffi/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- Makefile	26 May 2016 20:48:50 -	1.35
+++ Makefile	21 Jan 2018 05:11:17 -
@@ -3,7 +3,7 @@
 COMMENT=		Foreign Function Interface
 
 DISTNAME=		libffi-3.2.1
-REVISION=		2
+REVISION=		3
 SHARED_LIBS +=  ffi  1.2  # .6.4
 CATEGORIES=		devel
 
Index: patches/patch-src_arm_ffi_c
===
RCS file: /cvs/ports/devel/libffi/patches/patch-src_arm_ffi_c,v
retrieving revision 1.7
diff -u -p -r1.7 patch-src_arm_ffi_c
--- patches/patch-src_arm_ffi_c	15 Jul 2015 17:06:48 -	1.7
+++ patches/patch-src_arm_ffi_c	21 Jan 2018 05:11:17 -
@@ -1,15 +1,36 @@
 $OpenBSD: patch-src_arm_ffi_c,v 1.7 2015/07/15 17:06:48 jasper Exp $
 
-Fix warning: implicit declaration of function '__clear_cache'
+https://svnweb.freebsd.org/ports/head/devel/libffi/files/patch-src__arm__ffi.c?revision=337118=markup
 
 src/arm/ffi.c.orig	Fri Apr 25 19:45:13 2014
-+++ src/arm/ffi.c	Mon Sep 15 22:00:37 2014
-@@ -37,6 +37,8 @@
+Index: src/arm/ffi.c
+--- src/arm/ffi.c.orig
 src/arm/ffi.c
+@@ -33,6 +33,11 @@
+ 
+ #include 
+ 
++#ifdef __arm__
++#include 
++#include 
++#endif
++
+ /* Forward declares. */
  static int vfp_type_p (ffi_type *);
  static void layout_vfp_args (ffi_cif *);
+@@ -750,6 +755,16 @@ ffi_closure_free (void *ptr)
+ }
  
-+extern void __clear_cache(char *beg, char *end);
+ #else
 +
- int ffi_prep_args_SYSV(char *stack, extended_cif *ecif, float *vfp_space);
- int ffi_prep_args_VFP(char *stack, extended_cif *ecif, float *vfp_space);
++#ifdef __arm__
++#define __clear_cache(start, end) do {	\
++		struct arm_sync_icache_args ua;\
++	\
++		ua.addr = (uintptr_t)(start);\
++		ua.len = (char *)(end) - (char *)start;			\
++		sysarch(ARM_SYNC_ICACHE, );\
++	} while (0);
++#endif
  
+ #define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX)\
+ ({ unsigned char *__tramp = (unsigned char*)(TRAMP);			\
Index: patches/patch-src_arm_sysv_S
===
RCS file: patches/patch-src_arm_sysv_S
diff -N patches/patch-src_arm_sysv_S
--- /dev/null	1 Jan 1970 00:00:00 -
+++ patches/patch-src_arm_sysv_S	21 Jan 2018 05:11:17 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+https://github.com/libffi/libffi/issues/162
+
+Index: src/arm/sysv.S
+--- src/arm/sysv.S.orig
 src/arm/sysv.S
+@@ -396,7 +396,7 @@ LSYM(Lbase_args):
+ 	beq	LSYM(Lepilogue_vfp)
+ 
+ 	cmp	r3, #FFI_TYPE_SINT64
+-	stmeqia	r2, {r0, r1}
++	stmiaeq	r2, {r0, r1}
+ 	beq	LSYM(Lepilogue_vfp)
+ 
+ 	cmp	r3, #FFI_TYPE_FLOAT

Re: adjustments for arm clang switch

[Juan Francisco Cantero Hurtado]

On Sat, Jan 20, 2018 at 11:07:46PM +, Stuart Henderson wrote:
> On 2018/01/20 12:53, Juan Francisco Cantero Hurtado wrote:
> > On Sat, Jan 20, 2018 at 09:05:28AM +, Stuart Henderson wrote:
> > > On 2018/01/20 16:28, Jonathan Gray wrote:
> > > > With armv7 switching to clang as the base compiler atomic builtins and
> > > > -mfpu=neon are now available on arm.
> > > 
> > > Comments on a couple below, others are OK with me:
> > > 
> > > > Index: lang/racket-minimal/Makefile
> > > > ===
> > > > RCS file: /cvs/ports/lang/racket-minimal/Makefile,v
> > > > retrieving revision 1.43
> > > > diff -u -p -r1.43 Makefile
> > > > --- lang/racket-minimal/Makefile2 Dec 2017 21:39:49 -   
> > > > 1.43
> > > > +++ lang/racket-minimal/Makefile20 Jan 2018 00:52:42 -
> > > > @@ -38,7 +38,6 @@ EXTRACT_SUFX =.tgz
> > > >  # "places" and "futures" require TLS.
> > > >  COMPILER = base-clang ports-gcc
> > > >  COMPILER_LANGS =   c
> > > > -MODGCC4_ARCHS =arm
> > > >  
> > > >  LIB_DEPENDS =  converters/libiconv \
> > > > databases/sqlite3 \
> > > 
> > > Here ports-gcc is only used for arm (restricting from the defaults).
> > > By removing MODGCC4_ARCHS all !base-clang arches switch to ports-gcc,
> > > so the effect you are looking for would come from removing the
> > > COMPILER* lines as well.
> > > 
> > > This doesn't really square up with the above comment about TLS though
> > > because ONLY_FOR_ARCHS lists !base-clang arches. juanfra, do you know
> > > what's going on here?
> > 
> > I remember vaguely someone changing a bunch of ports to lang/gcc because
> > the base gcc didn't have support for something on arm. Sorry, I don't
> > remember the details.
> 
> The comment talks about TLS, but base gcc didn't have that anyway.
> But also it talks about needing TLS for "places" and "futures" but
> those are disabled with CONFIGURE_ARGS on all !x86 anyway.
> 
> Bit confusing..

In fact, it's quite simple :)

Racket has a JIT and a C interpreter. The JIT is only available on
amd64, i386, arm and powerpc. powerpc has an old version and doesn't
support places and futures. The assembly is broken on arm when places
and futures are enabled. The C interpreter doesn't support places and
futures. places and futures requires TLS.

So, you have amd64/i386 with JIT+places+futures. arm and powerpc with
JIT-places+futures. Everything else has only the C interpreter.

Upstream is working on a new different interpreter which probably will
provide a better support for less popular platforms.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: adjustments for arm clang switch

[Juan Francisco Cantero Hurtado]

On Sun, Jan 21, 2018 at 12:13:57AM +, Stuart Henderson wrote:
> With the move to clang, arm has a more modern assembler, so it probably
> makes sense to try places+futures there. And the comment about TLS doesn't
> make much sense because it will only be tried on arch that have some kind of
> TLS support anyway.

It's not that kind of problem. Racket doesn't build with JIT+places on
arm. The JIT doesn't have the assembly code to support places there. I
tested the build this afternoon also with places and futures enabled
(just in case).

My comments here are mostly small notes to avoid fuck up the package. If
something is enabled in the makefile, I tested it on that platform. In
the past, the configure magic built an apparently good interpreter which
failed with some tests.

The makefile will be more clean when upstream releases the new
interpreter.

> 
> 
> 
> On 20 January 2018 23:58:08 Juan Francisco Cantero Hurtado
>  wrote:
> 
> > On Sat, Jan 20, 2018 at 11:07:46PM +, Stuart Henderson wrote:
> > > On 2018/01/20 12:53, Juan Francisco Cantero Hurtado wrote:
> > > > On Sat, Jan 20, 2018 at 09:05:28AM +, Stuart Henderson wrote:
> > > > > On 2018/01/20 16:28, Jonathan Gray wrote:
> > > > > > With armv7 switching to clang as the base compiler atomic builtins 
> > > > > > and
> > > > > > -mfpu=neon are now available on arm.
> > > > >
> > > > > Comments on a couple below, others are OK with me:
> > > > >
> > > > > > Index: lang/racket-minimal/Makefile
> > > > > > ===
> > > > > > RCS file: /cvs/ports/lang/racket-minimal/Makefile,v
> > > > > > retrieving revision 1.43
> > > > > > diff -u -p -r1.43 Makefile
> > > > > > --- lang/racket-minimal/Makefile2 Dec 2017 21:39:49 -   
> > > > > > 1.43
> > > > > > +++ lang/racket-minimal/Makefile20 Jan 2018 00:52:42 -
> > > > > > @@ -38,7 +38,6 @@ EXTRACT_SUFX =.tgz
> > > > > >  # "places" and "futures" require TLS.
> > > > > >  COMPILER = base-clang ports-gcc
> > > > > >  COMPILER_LANGS =   c
> > > > > > -MODGCC4_ARCHS =arm
> > > > > >
> > > > > >  LIB_DEPENDS =  converters/libiconv \
> > > > > > databases/sqlite3 \
> > > > >
> > > > > Here ports-gcc is only used for arm (restricting from the defaults).
> > > > > By removing MODGCC4_ARCHS all !base-clang arches switch to ports-gcc,
> > > > > so the effect you are looking for would come from removing the
> > > > > COMPILER* lines as well.
> > > > >
> > > > > This doesn't really square up with the above comment about TLS though
> > > > > because ONLY_FOR_ARCHS lists !base-clang arches. juanfra, do you know
> > > > > what's going on here?
> > > >
> > > > I remember vaguely someone changing a bunch of ports to lang/gcc because
> > > > the base gcc didn't have support for something on arm. Sorry, I don't
> > > > remember the details.
> > > 
> > > The comment talks about TLS, but base gcc didn't have that anyway.
> > > But also it talks about needing TLS for "places" and "futures" but
> > > those are disabled with CONFIGURE_ARGS on all !x86 anyway.
> > > 
> > > Bit confusing..
> > 
> > In fact, it's quite simple :)
> > 
> > Racket has a JIT and a C interpreter. The JIT is only available on
> > amd64, i386, arm and powerpc. powerpc has an old version and doesn't
> > support places and futures. The assembly is broken on arm when places
> > and futures are enabled. The C interpreter doesn't support places and
> > futures. places and futures requires TLS.
> > 
> > So, you have amd64/i386 with JIT+places+futures. arm and powerpc with
> > JIT-places+futures. Everything else has only the C interpreter.
> > 
> > Upstream is working on a new different interpreter which probably will
> > provide a better support for less popular platforms.
> > 
> > 
> > --
> > Juan Francisco Cantero Hurtado http://juanfra.info
> 
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: adjustments for arm clang switch

[Stuart Henderson]

With the move to clang, arm has a more modern assembler, so it probably 
makes sense to try places+futures there. And the comment about TLS doesn't 
make much sense because it will only be tried on arch that have some kind 
of TLS support anyway.




On 20 January 2018 23:58:08 Juan Francisco Cantero Hurtado 
 wrote:



On Sat, Jan 20, 2018 at 11:07:46PM +, Stuart Henderson wrote:

On 2018/01/20 12:53, Juan Francisco Cantero Hurtado wrote:
> On Sat, Jan 20, 2018 at 09:05:28AM +, Stuart Henderson wrote:
> > On 2018/01/20 16:28, Jonathan Gray wrote:
> > > With armv7 switching to clang as the base compiler atomic builtins and
> > > -mfpu=neon are now available on arm.
> >
> > Comments on a couple below, others are OK with me:
> >
> > > Index: lang/racket-minimal/Makefile
> > > ===
> > > RCS file: /cvs/ports/lang/racket-minimal/Makefile,v
> > > retrieving revision 1.43
> > > diff -u -p -r1.43 Makefile
> > > --- lang/racket-minimal/Makefile 2 Dec 2017 21:39:49 -   1.43
> > > +++ lang/racket-minimal/Makefile 20 Jan 2018 00:52:42 -
> > > @@ -38,7 +38,6 @@ EXTRACT_SUFX = .tgz
> > >  # "places" and "futures" require TLS.
> > >  COMPILER =  base-clang ports-gcc
> > >  COMPILER_LANGS =c
> > > -MODGCC4_ARCHS = arm
> > >
> > >  LIB_DEPENDS =   converters/libiconv \
> > >  databases/sqlite3 \
> >
> > Here ports-gcc is only used for arm (restricting from the defaults).
> > By removing MODGCC4_ARCHS all !base-clang arches switch to ports-gcc,
> > so the effect you are looking for would come from removing the
> > COMPILER* lines as well.
> >
> > This doesn't really square up with the above comment about TLS though
> > because ONLY_FOR_ARCHS lists !base-clang arches. juanfra, do you know
> > what's going on here?
>
> I remember vaguely someone changing a bunch of ports to lang/gcc because
> the base gcc didn't have support for something on arm. Sorry, I don't
> remember the details.

The comment talks about TLS, but base gcc didn't have that anyway.
But also it talks about needing TLS for "places" and "futures" but
those are disabled with CONFIGURE_ARGS on all !x86 anyway.

Bit confusing..


In fact, it's quite simple :)

Racket has a JIT and a C interpreter. The JIT is only available on
amd64, i386, arm and powerpc. powerpc has an old version and doesn't
support places and futures. The assembly is broken on arm when places
and futures are enabled. The C interpreter doesn't support places and
futures. places and futures requires TLS.

So, you have amd64/i386 with JIT+places+futures. arm and powerpc with
JIT-places+futures. Everything else has only the C interpreter.

Upstream is working on a new different interpreter which probably will
provide a better support for less popular platforms.


--
Juan Francisco Cantero Hurtado http://juanfra.info

Re: adjustments for arm clang switch

[Stuart Henderson]

On 2018/01/20 12:53, Juan Francisco Cantero Hurtado wrote:
> On Sat, Jan 20, 2018 at 09:05:28AM +, Stuart Henderson wrote:
> > On 2018/01/20 16:28, Jonathan Gray wrote:
> > > With armv7 switching to clang as the base compiler atomic builtins and
> > > -mfpu=neon are now available on arm.
> > 
> > Comments on a couple below, others are OK with me:
> > 
> > > Index: lang/racket-minimal/Makefile
> > > ===
> > > RCS file: /cvs/ports/lang/racket-minimal/Makefile,v
> > > retrieving revision 1.43
> > > diff -u -p -r1.43 Makefile
> > > --- lang/racket-minimal/Makefile  2 Dec 2017 21:39:49 -   1.43
> > > +++ lang/racket-minimal/Makefile  20 Jan 2018 00:52:42 -
> > > @@ -38,7 +38,6 @@ EXTRACT_SUFX =  .tgz
> > >  # "places" and "futures" require TLS.
> > >  COMPILER =   base-clang ports-gcc
> > >  COMPILER_LANGS = c
> > > -MODGCC4_ARCHS =  arm
> > >  
> > >  LIB_DEPENDS =converters/libiconv \
> > >   databases/sqlite3 \
> > 
> > Here ports-gcc is only used for arm (restricting from the defaults).
> > By removing MODGCC4_ARCHS all !base-clang arches switch to ports-gcc,
> > so the effect you are looking for would come from removing the
> > COMPILER* lines as well.
> > 
> > This doesn't really square up with the above comment about TLS though
> > because ONLY_FOR_ARCHS lists !base-clang arches. juanfra, do you know
> > what's going on here?
> 
> I remember vaguely someone changing a bunch of ports to lang/gcc because
> the base gcc didn't have support for something on arm. Sorry, I don't
> remember the details.

The comment talks about TLS, but base gcc didn't have that anyway.
But also it talks about needing TLS for "places" and "futures" but
those are disabled with CONFIGURE_ARGS on all !x86 anyway.

Bit confusing..

Re: cmake.port.mk and DEBUG

[Stuart Henderson]

On 2018/01/20 13:08, Jeremie Courreges-Anglas wrote:
> On Sat, Jan 20 2018, Landry Breuil  wrote:
> > On Fri, Jan 19, 2018 at 03:18:53PM +0100, Jeremie Courreges-Anglas wrote:
> >> 
> >> Once again I've been bitten by the special handling of DEBUG done in
> >> cmake.port.mk.
> >> 
> >> First, cmake might use different CFLAGS in debug and release mode (this
> >> is usually specified by upstream in CMakeLists.txt).  Those CFLAGS might
> >> be undesirable or even unusable on OpenBSD (iirc some stuff might try to
> >> link against valgrind or ubsan / whatever).  Those might be useful but
> >> IMO you shouldn't get to use them when all you want is to rebuild a port
> >> with DEBUG=-g, ie debug symbols.
> >> 
> >> Also the release/debug difference means that some ports just won't
> >> package because of file names changes:
> >> 
> >> --8<--
> >> ===>  Building package for libical-3.0.1
> >> Create /usr/ports/packages/amd64/all/libical-3.0.1.tgz
> >> Creating package libical-3.0.1
> >> Error: change in plist
> >> | If the old and new builds were done correctly
> >> | (fully up-to-date ports tree including relevant MODULES)
> >> | then someone probably forgot to bump a REVISION.
> >> | (see bsd.port.mk(5), PACKAGE_REPOSITORY)
> >> --- /usr/ports/plist/amd64/libical-3.0.1
> >> +++ /usr/ports/plist/amd64/libical-3.0.1-new
> >> @@ -74,7 +74,7 @@
> >>  lib/cmake/LibIcal/
> >>  lib/cmake/LibIcal/LibIcalConfig.cmake
> >>  lib/cmake/LibIcal/LibIcalConfigVersion.cmake
> >> -lib/cmake/LibIcal/LibIcalTargets-release.cmake
> >> +lib/cmake/LibIcal/LibIcalTargets-debug.cmake
> >>  lib/cmake/LibIcal/LibIcalTargets.cmake
> >>  lib/girepository-1.0/
> >>  lib/girepository-1.0/ICalGLib-3.0.typelib
> >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1943 
> >> '/usr/ports/packages/amd64/all/libical-3.0.1.tgz')
> >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2440 
> >> '_internal-package')
> >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package')
> >> *** Error 1 in /usr/ports/textproc/libical 
> >> (/usr/ports/infrastructure/mk/bsd.port.mk:3421 'repackage')
> >> -->8--
> >> 
> >>   $ pkglocate  release.cmake | wc -l
> >>150
> >> 
> >> I think it's fair to say that the ports tree is not ready to use
> >> cmake with DEBUG=-g.  This could be fixed in theory, but someone has to
> >> do the work*, and is does not invalidate my first point.
> >
> > What do you mean by 'not ready' ?
> 
> As a dumb porter, I'd like to be able to use DEBUG=-g and expect it to
> add debug symbols to the resulting package.  Not to fail at compile time
> because of alien CFLAGS suddenly appearing, not to fail at make package
> time because of PLIST changes.  DEBUG=-g is a super useful tool that
> allowed me to fix quite a bunch of problems in the past and present
> days.
> 
> (Of course for this DEBUG=-g should be respected by each ports' build
> system, but that's a separate issue.)
> 
> >> So here's the simple diff that does less and makes DEBUG=-g actually
> >> usable.
> >
> > As the one with came up with what you're proposing to revert, i had to
> > sit and look again. I thought i had done this recently, but it turns out
> > it was already 3+ years ago in r1.34.
> >
> > My usecase was at the time, i want to be able to just set DEBUG, and
> > have cmake build with upstream-provided debug configuration (setting
> > various flags, not only CFLAGS) because that's much more different and
> > useful (*in my opinion*) that just setting -g: sometimes it enables
> > verbose logging on the output, sometimes different codepaths are used
> > for debugging corner cases - this is *convenient*, but i agree it
> > totally depends on the case and what upstream made special in the debug
> > build type.
> >
> > For example, i don't want to use gdb on qgis, unless in an extremely
> > desperate case.
> >
> > When you set CMAKE_BUILD_TYPE, cmake installs the -debug.cmake file
> > instead of the -release.cmake file, so MODCMAKE_BUILD_SUFFIX was added
> > so that ports packaged. Minus the eventual PLIST_DB warning, but you
> > know make clean=plist right ? :)
> 
> Nope.  PLIST_DB is super useful and having to ditch it as a work-around
> is less than optimal in my book.  IMHO, the ports tree should be ready
> to build and package with DEBUG=-g set.  (No, I'm not suggesting that
> people should use this in their /etc/mk.conf.)
> 
> > If you don't like the fact that it's 'automagic' with DEBUG, change the
> > variable to have it in a distinct way (dunno, MODCMAKE_DEBUG?) that sets
> > CMAKE_BUILD_TYPE and MODCMAKE_BUILD_SUFFIX (and DEBUG while here?) like
> > it's done now with DEBUG ?
> 
> I would support any solution that doesn't overload the semantics of
> DEBUG.
> 
> > With DEBUG set it was convenient because it also (iirc) disabled
> > stripping, but i dont know if it has any effect with cmake-builds.
> >
> >> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?
> >
> > Well, some do 

CVS: cvs.openbsd.org: ports

[Juan Francisco Cantero Hurtado]

CVSROOT:/cvs
Module name:ports
Changes by: juan...@cvs.openbsd.org 2018/01/20 15:23:17

Modified files:
lang/racket-minimal: Makefile 

Log message:
Racket doesn't need lang/gcc on arm anymore. Noticed by jsg@, jca@, sthen@.

Re: [NEW] textproc/p5-Text-CSV-Hashify

[Nigel Taylor]

I just imported before the new tarball, I had removed PLIST.orig.

On 01/20/18 15:20, James E Keenan wrote:
> On 01/20/2018 04:24 AM, Landry Breuil wrote:
>> On Fri, Jan 19, 2018 at 06:43:21PM -0500, James E Keenan wrote:
>>> On 01/07/2018 10:50 PM, James E Keenan wrote:
 Hello ports@,

 Here is a new port, for Perl extension Text-CSV-Hashify (version 0.08).

   From DESCR:

 The Comma-Separated-Value ('CSV') format is the most common way to
 store
 spreadsheets or the output of relational database queries in plain-text
 format.  However, since commas (or other designated field-separator
 characters) may be embedded within data entries, the parsing of
 delimited records is non-trivial.  Fortunately, in Perl this parsing is
 well handled by CPAN distribution Text::CSV.  This permits us to
 address
 more specific data manipulation problems by building modules on top of
 Text::CSV.

 Text::CSV::Hashify is designed for the case where you simply want to
 turn a CSV file into a Perl hash.  In particular, it is designed for
 the
 case where (a) the CSV file's first record is a list of fields in the
 ancestral database table and (b) one field (column) functions as a
 primary key, i.e., each record's entry in that field is non-null and is
 distinct from every other record's entry therein.  Text::CSV::Hashify
 turns that kind of CSV file into one big hash of hashes.

 Text::CSV::Hashify can handle less typical cases; please consult the
 documentation for its other functionalities.

 Please review.

 Thank you very much.
 Jim Keenan


>>>
>>> ping on this new port; please review.  Thank you very much.
>>
>> Port itself looks okay to me to import if anyone with commit access
>> wants to do so, just beware of the PLIST.orig file in the tarball (cvs
>> import will Ignore it anyway)
>>
>> Landry
>>
> 
> Corrected tarball attached.
> 
> Thank you very much.
> Jim Keenan

[Patch] update games/tome4

[Solene Rapenne]

Hello,

please find a patch to bump the version.
I tested it and it works fine.


Index: Makefile
===
RCS file: /cvs/ports/games/tome4/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile2 Dec 2017 15:26:12 -   1.12
+++ Makefile20 Jan 2018 19:36:05 -
@@ -10,7 +10,7 @@ ONLY_FOR_ARCHS = i386 amd64
 COMMENT-main = graphical sdl rogue-like game
 COMMENT-data = data for Tales of Maj'Eyal
 
-V =1.5.1
+V =1.5.5
 PKGNAME-main = tome4-${V}
 PKGNAME-data = tome4-data-${V}
 CATEGORIES =   games x11
Index: distinfo
===
RCS file: /cvs/ports/games/tome4/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo27 Mar 2017 18:28:29 -  1.2
+++ distinfo20 Jan 2018 19:36:05 -
@@ -1,2 +1,2 @@
-SHA256 (t-engine4-src-1.5.1.tar.bz2) = 
er5VbR72iQ0WrlO4KSwQWSVDopR6QCS7mjtnARp00Lg=
-SIZE (t-engine4-src-1.5.1.tar.bz2) = 421336208
+SHA256 (t-engine4-src-1.5.5.tar.bz2) = 
A3zO5JMhPF4gdJ00gfVnbwUJlbtop7vYCu23fV17WGw=
+SIZE (t-engine4-src-1.5.5.tar.bz2) = 421330688

Re: NEW: news/nzbget

[Klemens Nanni]

On Sat, Jan 20, 2018 at 08:05:04PM +0100, Björn Ketelaars wrote:
> New port for NZBGet
> 
> pkg/DESCR:
> NZBGet is a binary newsgrabber, which downloads files from usenet based on
> information given in nzb-files. NZBGet is written in C++ and is known for its
> extraordinary performance and efficiency.
> 
> 
> This port does the same thing as news/sabnzbd but is faster, lighter on
> resources, and has less dependencies.
> 
> I used the first free id from infrastructure/db/user.list.
> 
> Comments?
Looks good to me portwise except for:

DISTNAME is not needed as it's generated by GH_* already. But since
upstream provides proper release tarballs, please use DISTNAME and
MASTER_SITES without GH_* here.

HOMEPAGE has HTTPS.

The example nzbget.conf should probably be installed under
share/examples/nzget/ instead of share/nzget/ as per our porting guide.

CVS: cvs.openbsd.org: ports

[Matthias Kilian]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2018/01/20 13:00:58

Modified files:
astro/py-astral: Makefile 

Log message:
py-tz is *both*, run *and* build dependency.

ok danj@

UPDATE sysutils/logtail

[Björn Ketelaars]

A newer version of sysutils/logcheck is available, which fixes some things
[0]. Testing is limited to building and a bit of playing, nothing serious.

Comments?

[0] https://anonscm.debian.org/git/logcheck/logcheck.git/log/

-- 
Björn Ketelaars
GPG key: 0x4F0E5F21


diff --git sysutils/logtail/Makefile sysutils/logtail/Makefile
index 22e222b01a9..ecba102babb 100644
--- sysutils/logtail/Makefile
+++ sysutils/logtail/Makefile
@@ -2,8 +2,7 @@
 
 COMMENT=   mail anomalies in the system logfiles to the administrator
 
-V= 1.3.17
-REVISION=  0
+V= 1.3.18
 DISTNAME=  logcheck_${V}
 PKGNAME=   logtail-${V}
 EXTRACT_SUFX=  .tar.xz
diff --git sysutils/logtail/distinfo sysutils/logtail/distinfo
index cfccefe578e..7ec172f1931 100644
--- sysutils/logtail/distinfo
+++ sysutils/logtail/distinfo
@@ -1,2 +1,2 @@
-SHA256 (logcheck_1.3.17.tar.xz) = wtP8Mj6MZVXpHZVjhdv9D2e1WHLtD2p62K0lJqn68Do=
-SIZE (logcheck_1.3.17.tar.xz) = 130956
+SHA256 (logcheck_1.3.18.tar.xz) = B3uRSczSt0e1J4WvqJ2oRPPQcsAXyecZkl3sasuamvQ=
+SIZE (logcheck_1.3.18.tar.xz) = 131252

NEW: news/nzbget

[Björn Ketelaars]

New port for NZBGet

pkg/DESCR:
NZBGet is a binary newsgrabber, which downloads files from usenet based on
information given in nzb-files. NZBGet is written in C++ and is known for its
extraordinary performance and efficiency.


This port does the same thing as news/sabnzbd but is faster, lighter on
resources, and has less dependencies.

I used the first free id from infrastructure/db/user.list.

Comments?

-- 
Björn Ketelaars
GPG key: 0x4F0E5F21


nzbget.tgz
Description: application/tar-gz

UPDATE: www/youtube-dl 2017.12.23 -> 2018.01.18

[Klemens Nanni]

Here's a simple bump. working fine for me on the usual sites.

Ran 2248 tests in 11832.601s

FAILED (errors=572, failures=341)

Feedback? Anyone willing to commit?

diff --git a/www/youtube-dl/Makefile b/www/youtube-dl/Makefile
index 71e79164626..8a716ef3731 100644
--- a/www/youtube-dl/Makefile
+++ b/www/youtube-dl/Makefile
@@ -2,7 +2,7 @@
 
 COMMENT =  CLI program to download videos from YouTube and other sites
 
-VERSION =  2017.12.23
+VERSION =  2018.01.18
 MODPY_EGG_VERSION =${VERSION:S/.0/./g}
 
 DISTNAME = youtube-dl-${VERSION}
diff --git a/www/youtube-dl/distinfo b/www/youtube-dl/distinfo
index d6050fd7d97..5ec65326204 100644
--- a/www/youtube-dl/distinfo
+++ b/www/youtube-dl/distinfo
@@ -1,2 +1,2 @@
-SHA256 (youtube-dl-2017.12.23.tar.gz) = 
hSBsRqkKiZOxM7ndDg7I/G81gGDf6ltcYHqliptcoYo=
-SIZE (youtube-dl-2017.12.23.tar.gz) = 2859430
+SHA256 (youtube-dl-2018.01.18.tar.gz) = 
Ti/OPegi31G67E4I1QJ3/af3slVms9Vw4DBApAfyrZo=
+SIZE (youtube-dl-2018.01.18.tar.gz) = 2885167
diff --git a/www/youtube-dl/pkg/PLIST b/www/youtube-dl/pkg/PLIST
index 02b709bdab8..a0699f8688b 100644
--- a/www/youtube-dl/pkg/PLIST
+++ b/www/youtube-dl/pkg/PLIST
@@ -161,7 +161,6 @@ 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}cl
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}cmt.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}cnbc.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}cnn.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}collegerama.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}comcarcoff.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}comedycentral.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}common.${MODPY_PYC_MAGIC_TAG}pyc
@@ -192,6 +191,7 @@ 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}de
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}democracynow.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}dfb.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}dhm.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}digg.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}digiteka.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}discovery.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}discoverygo.${MODPY_PYC_MAGIC_TAG}pyc
@@ -240,6 +240,7 @@ 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}fa
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}fc2.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}fczenit.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}filmon.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}filmweb.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}firsttv.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}fivemin.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}fivetv.${MODPY_PYC_MAGIC_TAG}pyc
@@ -318,6 +319,7 @@ 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}in
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}indavideo.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}infoq.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}instagram.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}internazionale.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}internetvideoarchive.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}iprima.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}iqiyi.${MODPY_PYC_MAGIC_TAG}pyc
@@ -335,7 +337,6 @@ 
lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/${MODPY_PYCACHE}jp
 

Re: [NEW] textproc/p5-Text-CSV-Hashify

[James E Keenan]

On 01/20/2018 10:34 AM, Nigel Taylor wrote:

I just imported before the new tarball, I had removed PLIST.orig.



Thank you very much!

CVS: cvs.openbsd.org: ports

[Nigel Taylor]

CVSROOT:/cvs
Module name:ports
Changes by: ni...@cvs.openbsd.org   2018/01/20 08:30:58

Modified files:
textproc   : Makefile 

Log message:
add in new port p5-Text-CSV-Hashify

CVS: cvs.openbsd.org: ports

[Nigel Taylor]

CVSROOT:/cvs
Module name:ports
Changes by: ni...@cvs.openbsd.org   2018/01/20 08:23:18

Log message:
CSV file to perl Hashes
Ok landry

Status:

Vendor Tag: nigel
Release Tags:   nigel_20180120

N ports/textproc/p5-Text-CSV-Hashify/Makefile
N ports/textproc/p5-Text-CSV-Hashify/distinfo
N ports/textproc/p5-Text-CSV-Hashify/pkg/DESCR
N ports/textproc/p5-Text-CSV-Hashify/pkg/PLIST

No conflicts created by this import

Re: [NEW] textproc/p5-Text-CSV-Hashify

[James E Keenan]

On 01/20/2018 04:24 AM, Landry Breuil wrote:

On Fri, Jan 19, 2018 at 06:43:21PM -0500, James E Keenan wrote:

On 01/07/2018 10:50 PM, James E Keenan wrote:

Hello ports@,

Here is a new port, for Perl extension Text-CSV-Hashify (version 0.08).

  From DESCR:

The Comma-Separated-Value ('CSV') format is the most common way to store
spreadsheets or the output of relational database queries in plain-text
format.  However, since commas (or other designated field-separator
characters) may be embedded within data entries, the parsing of
delimited records is non-trivial.  Fortunately, in Perl this parsing is
well handled by CPAN distribution Text::CSV.  This permits us to address
more specific data manipulation problems by building modules on top of
Text::CSV.

Text::CSV::Hashify is designed for the case where you simply want to
turn a CSV file into a Perl hash.  In particular, it is designed for the
case where (a) the CSV file's first record is a list of fields in the
ancestral database table and (b) one field (column) functions as a
primary key, i.e., each record's entry in that field is non-null and is
distinct from every other record's entry therein.  Text::CSV::Hashify
turns that kind of CSV file into one big hash of hashes.

Text::CSV::Hashify can handle less typical cases; please consult the
documentation for its other functionalities.

Please review.

Thank you very much.
Jim Keenan




ping on this new port; please review.  Thank you very much.


Port itself looks okay to me to import if anyone with commit access
wants to do so, just beware of the PLIST.orig file in the tarball (cvs
import will Ignore it anyway)

Landry



Corrected tarball attached.

Thank you very much.
Jim Keenan


p5-Text-CSV-Hashify.tar.gz
Description: application/gzip

CVS: cvs.openbsd.org: ports

[Jonathan Gray]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2018/01/20 08:05:34

Modified files:
devel/codeblocks: Makefile 
devel/reposurgeon: Makefile 
games/crimson  : Makefile 
games/stone-soup: Makefile 
games/fifengine: Makefile 
lang/seed7 : Makefile 
security/john-jumbo: Makefile 

Log message:
Remove most of the remaining BROKEN-arm markers to give ports a chance
of building with clang.

ok sthen@ phessler@

Re: new www/py-yarl [hass: #11]

[Klemens Nanni]

On Wed, Jan 17, 2018 at 09:57:03PM +0100, Joerg Jung wrote:
> On Wed, Jan 17, 2018 at 09:14:57PM +0100, Klemens Nanni wrote:
> > On Wed, Jan 17, 2018 at 08:34:28PM +0100, Joerg Jung wrote:
> > > On Wed, Jan 17, 2018 at 12:12:06AM +0100, Joerg Jung wrote:
> > > > Hi,
> > > > 
> > > > please find attached a new port for www/py-yarl.
> > > > 
> > > >$ cat pkg/DESCR
> > > >Yet another URL library.
> > > > 
> > > > This port is a dependency for the upcoming homeassistant port.
> > >  
> > > Meanwhile yarl-1.0.0 was release. Newer version is attached.
> > > 
> > > > Please test and comment. OK to import?
> > 
> > In addition I'd like to add minimal version requirements to its RDEPS,
> > see diff below ontop of your tarball.
> 
> Thanks, added. New tarball attached.
Looks good to me.

CVS: cvs.openbsd.org: ports

[Jonathan Gray]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2018/01/20 07:03:39

Modified files:
audio/audiality2: Makefile 
audio/jack : Makefile 
databases/kyotocabinet: Makefile 
databases/postgresql-previous: Makefile 
databases/postgresql: Makefile 
devel/libgit2/libgit2: Makefile 
devel/liburcu  : Makefile 
devel/msgpack  : Makefile 
devel/openmpi  : Makefile 
graphics/libraw: Makefile 
japanese/mecab : Makefile 
lang/moarvm: Makefile 
misc/zzuf  : Makefile 
net/haproxy: Makefile 
net/icinga/core2: Makefile 
net/libtorrent : Makefile 
net/rtorrent   : Makefile 
www/kore   : Makefile 
www/nginx  : Makefile 
www/ruby-passenger: Makefile 
x11/freerdp: Makefile 
x11/qt4: Makefile 

Log message:
Now that arm has switched to clang the base compiler has atomic builtins
and accepts -mfpu=neon.

ok jca@ sthen@

Re: adjustments for arm clang switch

[Juan Francisco Cantero Hurtado]

On Sat, Jan 20, 2018 at 09:05:28AM +, Stuart Henderson wrote:
> On 2018/01/20 16:28, Jonathan Gray wrote:
> > With armv7 switching to clang as the base compiler atomic builtins and
> > -mfpu=neon are now available on arm.
> 
> Comments on a couple below, others are OK with me:
> 
> > Index: lang/racket-minimal/Makefile
> > ===
> > RCS file: /cvs/ports/lang/racket-minimal/Makefile,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 Makefile
> > --- lang/racket-minimal/Makefile2 Dec 2017 21:39:49 -   1.43
> > +++ lang/racket-minimal/Makefile20 Jan 2018 00:52:42 -
> > @@ -38,7 +38,6 @@ EXTRACT_SUFX =.tgz
> >  # "places" and "futures" require TLS.
> >  COMPILER = base-clang ports-gcc
> >  COMPILER_LANGS =   c
> > -MODGCC4_ARCHS =arm
> >  
> >  LIB_DEPENDS =  converters/libiconv \
> > databases/sqlite3 \
> 
> Here ports-gcc is only used for arm (restricting from the defaults).
> By removing MODGCC4_ARCHS all !base-clang arches switch to ports-gcc,
> so the effect you are looking for would come from removing the
> COMPILER* lines as well.
> 
> This doesn't really square up with the above comment about TLS though
> because ONLY_FOR_ARCHS lists !base-clang arches. juanfra, do you know
> what's going on here?

I remember vaguely someone changing a bunch of ports to lang/gcc because
the base gcc didn't have support for something on arm. Sorry, I don't
remember the details.

I will update the makefile later today.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 05:36:58

Modified files:
graphics/babl  : Makefile distinfo 

Log message:
Update to babl-0.1.40.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 05:33:31

Modified files:
x11/gnome/libgepub: Makefile distinfo 

Log message:
Update to libgepub-0.5.3.

Re: cmake.port.mk and DEBUG

[Jeremie Courreges-Anglas]

On Sat, Jan 20 2018, Antoine Jacoutot  wrote:
> On Fri, Jan 19, 2018 at 02:18:53PM +, Jeremie Courreges-Anglas wrote:

[...]

>> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?
>
> I think that's the main issue isn't it?
> We can probably fix the framework to do so.

Nope.  This blurb about MODCMAKE_BUILD_SUFFIX not being substituted is
just me being stupid.

But given that I'm perfectly fine with being stupid, I'm not happy with
a module overloading DEBUG, inserting random CFLAGS at upstream's will
and triggering PLIST_DB changes.

And I'm not the only one that has been bitten by this, I recall at least
three other developers and one user losing time on this.  So I'm
advocating for less magic. :)

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

Re: cmake.port.mk and DEBUG

[Jeremie Courreges-Anglas]

On Sat, Jan 20 2018, Landry Breuil  wrote:
> On Fri, Jan 19, 2018 at 03:18:53PM +0100, Jeremie Courreges-Anglas wrote:
>> 
>> Once again I've been bitten by the special handling of DEBUG done in
>> cmake.port.mk.
>> 
>> First, cmake might use different CFLAGS in debug and release mode (this
>> is usually specified by upstream in CMakeLists.txt).  Those CFLAGS might
>> be undesirable or even unusable on OpenBSD (iirc some stuff might try to
>> link against valgrind or ubsan / whatever).  Those might be useful but
>> IMO you shouldn't get to use them when all you want is to rebuild a port
>> with DEBUG=-g, ie debug symbols.
>> 
>> Also the release/debug difference means that some ports just won't
>> package because of file names changes:
>> 
>> --8<--
>> ===>  Building package for libical-3.0.1
>> Create /usr/ports/packages/amd64/all/libical-3.0.1.tgz
>> Creating package libical-3.0.1
>> Error: change in plist
>> | If the old and new builds were done correctly
>> | (fully up-to-date ports tree including relevant MODULES)
>> | then someone probably forgot to bump a REVISION.
>> | (see bsd.port.mk(5), PACKAGE_REPOSITORY)
>> --- /usr/ports/plist/amd64/libical-3.0.1
>> +++ /usr/ports/plist/amd64/libical-3.0.1-new
>> @@ -74,7 +74,7 @@
>>  lib/cmake/LibIcal/
>>  lib/cmake/LibIcal/LibIcalConfig.cmake
>>  lib/cmake/LibIcal/LibIcalConfigVersion.cmake
>> -lib/cmake/LibIcal/LibIcalTargets-release.cmake
>> +lib/cmake/LibIcal/LibIcalTargets-debug.cmake
>>  lib/cmake/LibIcal/LibIcalTargets.cmake
>>  lib/girepository-1.0/
>>  lib/girepository-1.0/ICalGLib-3.0.typelib
>> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1943 
>> '/usr/ports/packages/amd64/all/libical-3.0.1.tgz')
>> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2440 
>> '_internal-package')
>> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package')
>> *** Error 1 in /usr/ports/textproc/libical 
>> (/usr/ports/infrastructure/mk/bsd.port.mk:3421 'repackage')
>> -->8--
>> 
>>   $ pkglocate  release.cmake | wc -l
>>150
>> 
>> I think it's fair to say that the ports tree is not ready to use
>> cmake with DEBUG=-g.  This could be fixed in theory, but someone has to
>> do the work*, and is does not invalidate my first point.
>
> What do you mean by 'not ready' ?

As a dumb porter, I'd like to be able to use DEBUG=-g and expect it to
add debug symbols to the resulting package.  Not to fail at compile time
because of alien CFLAGS suddenly appearing, not to fail at make package
time because of PLIST changes.  DEBUG=-g is a super useful tool that
allowed me to fix quite a bunch of problems in the past and present
days.

(Of course for this DEBUG=-g should be respected by each ports' build
system, but that's a separate issue.)

>> So here's the simple diff that does less and makes DEBUG=-g actually
>> usable.
>
> As the one with came up with what you're proposing to revert, i had to
> sit and look again. I thought i had done this recently, but it turns out
> it was already 3+ years ago in r1.34.
>
> My usecase was at the time, i want to be able to just set DEBUG, and
> have cmake build with upstream-provided debug configuration (setting
> various flags, not only CFLAGS) because that's much more different and
> useful (*in my opinion*) that just setting -g: sometimes it enables
> verbose logging on the output, sometimes different codepaths are used
> for debugging corner cases - this is *convenient*, but i agree it
> totally depends on the case and what upstream made special in the debug
> build type.
>
> For example, i don't want to use gdb on qgis, unless in an extremely
> desperate case.
>
> When you set CMAKE_BUILD_TYPE, cmake installs the -debug.cmake file
> instead of the -release.cmake file, so MODCMAKE_BUILD_SUFFIX was added
> so that ports packaged. Minus the eventual PLIST_DB warning, but you
> know make clean=plist right ? :)

Nope.  PLIST_DB is super useful and having to ditch it as a work-around
is less than optimal in my book.  IMHO, the ports tree should be ready
to build and package with DEBUG=-g set.  (No, I'm not suggesting that
people should use this in their /etc/mk.conf.)

> If you don't like the fact that it's 'automagic' with DEBUG, change the
> variable to have it in a distinct way (dunno, MODCMAKE_DEBUG?) that sets
> CMAKE_BUILD_TYPE and MODCMAKE_BUILD_SUFFIX (and DEBUG while here?) like
> it's done now with DEBUG ?

I would support any solution that doesn't overload the semantics of
DEBUG.

> With DEBUG set it was convenient because it also (iirc) disabled
> stripping, but i dont know if it has any effect with cmake-builds.
>
>> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?
>
> Well, some do it right, some don't and they need to be fixed ? I've just
> fixed the 3 occurences that were wrong, over 150... no so bad, right ?
> If we want to keep it that way, could be one more check to add to
> portcheck for the ones that use it...

I'll trust you about the 

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:53:44

Modified files:
sysutils/terraform/provider-fastly: Makefile distinfo 
sysutils/terraform/provider-pagerduty: Makefile distinfo 
sysutils/terraform/provider-postgresql: Makefile distinfo 

Log message:
Update providers to their latest release.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:42:59

Modified files:
databases/mariadb: Makefile 
multimedia/x264: Makefile 
multimedia/x264/patches: patch-common_osdep_h 
multimedia/x265: Makefile 
multimedia/mpv : Makefile 

Log message:
Enable some ports and adjust for atomic ops on arm.

from Brad

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:39:01

Modified files:
devel/llvm : Makefile 
devel/llvm/patches: 
patch-tools_clang_lib_Driver_ToolChains_OpenBSD_cpp 

Log message:
Update for arm switching to Clang as default in base.

from Brad (maintainer)

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:35:50

Modified files:
sysutils/terraform/provider-alicloud: Makefile distinfo 

Log message:
Update to terraform-provider-alicloud-1.6.1.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:34:16

Modified files:
sysutils/salt-testing: Makefile distinfo 

Log message:
Update to salt-testing-2018.1.16.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:30:32

Modified files:
sysutils/awless: Makefile distinfo 

Log message:
Update to awless-0.1.9.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:27:34

Modified files:
sysutils/amazon-ssm-agent: Makefile distinfo 
sysutils/amazon-ssm-agent/patches: 
   
patch-agent_appconfig_constants_unix_go 

Log message:
Update to amazon-ssm-agent-2.2.160.0.

Re: cmake.port.mk and DEBUG

[Antoine Jacoutot]

On Fri, Jan 19, 2018 at 02:18:53PM +, Jeremie Courreges-Anglas wrote:
> 
> Once again I've been bitten by the special handling of DEBUG done in
> cmake.port.mk.
> 
> First, cmake might use different CFLAGS in debug and release mode (this
> is usually specified by upstream in CMakeLists.txt).  Those CFLAGS might
> be undesirable or even unusable on OpenBSD (iirc some stuff might try to
> link against valgrind or ubsan / whatever).  Those might be useful but
> IMO you shouldn't get to use them when all you want is to rebuild a port
> with DEBUG=-g, ie debug symbols.
> 
> Also the release/debug difference means that some ports just won't
> package because of file names changes:
> 
> --8<--
> ===>  Building package for libical-3.0.1
> Create /usr/ports/packages/amd64/all/libical-3.0.1.tgz
> Creating package libical-3.0.1
> Error: change in plist
> | If the old and new builds were done correctly
> | (fully up-to-date ports tree including relevant MODULES)
> | then someone probably forgot to bump a REVISION.
> | (see bsd.port.mk(5), PACKAGE_REPOSITORY)
> --- /usr/ports/plist/amd64/libical-3.0.1
> +++ /usr/ports/plist/amd64/libical-3.0.1-new
> @@ -74,7 +74,7 @@
>  lib/cmake/LibIcal/
>  lib/cmake/LibIcal/LibIcalConfig.cmake
>  lib/cmake/LibIcal/LibIcalConfigVersion.cmake
> -lib/cmake/LibIcal/LibIcalTargets-release.cmake
> +lib/cmake/LibIcal/LibIcalTargets-debug.cmake
>  lib/cmake/LibIcal/LibIcalTargets.cmake
>  lib/girepository-1.0/
>  lib/girepository-1.0/ICalGLib-3.0.typelib
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1943 
> '/usr/ports/packages/amd64/all/libical-3.0.1.tgz')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2440 
> '_internal-package')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package')
> *** Error 1 in /usr/ports/textproc/libical 
> (/usr/ports/infrastructure/mk/bsd.port.mk:3421 'repackage')
> -->8--
> 
>   $ pkglocate  release.cmake | wc -l
>150
> 
> I think it's fair to say that the ports tree is not ready to use
> cmake with DEBUG=-g.  This could be fixed in theory, but someone has to
> do the work*, and is does not invalidate my first point.
> 
> So here's the simple diff that does less and makes DEBUG=-g actually
> usable.
> 
> ok?
> 
> 
> 
> Index: cmake.port.mk
> ===
> RCS file: /d/cvs/ports/devel/cmake/cmake.port.mk,v
> retrieving revision 1.62
> diff -u -p -p -u -r1.62 cmake.port.mk
> --- cmake.port.mk 28 Nov 2017 10:26:00 -  1.62
> +++ cmake.port.mk 8 Jan 2018 09:37:03 -
> @@ -76,13 +76,8 @@ MODCMAKE_configure=cd ${WRKBUILD} && ${
>   -G ${_MODCMAKE_GEN} ${CONFIGURE_ARGS} ${WRKSRC}
>  
>  .if !defined(CONFIGURE_ARGS) || ! ${CONFIGURE_ARGS:M*CMAKE_BUILD_TYPE*}
> -.  if defined(DEBUG)
> -CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Debug
> -MODCMAKE_BUILD_SUFFIX =  -debug.cmake
> -.  else
>  CONFIGURE_ARGS += -DCMAKE_BUILD_TYPE:String=Release
>  MODCMAKE_BUILD_SUFFIX =  -release.cmake
> -.  endif
>  .endif
>  SUBST_VARS +=MODCMAKE_BUILD_SUFFIX
>  
> 
> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?

I think that's the main issue isn't it?
We can probably fix the framework to do so.

-- 
Antoine

Re: [update] pgbouncer 1.8.1

[Landry Breuil]

On Sat, Jan 20, 2018 at 12:14:00PM +0100, Landry Breuil wrote:


> that explains why the 'compat' backend doesnt work. And that one is
> pretty hilarious :) The configure script has:
> 
> #include pthread.h
> 
> ... lol. 1.7.2 has it too :) And i have no idea where this interesting
> html comes from.. web 2.0 autoconf ?

Aaand after digging more, this gem comes from
https://github.com/libusual/libusual/blob/51d444927e55fed0523e03dd17b392fc70556023/m4/acx_pthread.m4#L117

> patching configure to fix that one yields:
> checking whether pthreads work with -pthread... yes
> 
> Aaaand this finally produces a working pgbouncer with hostnames, since i
> think it ends up falling back to our plain libc getaddrinfo. Maybe. I
> don't really know, 
> https://github.com/pgbouncer/pgbouncer/blob/master/src/dnslookup.c
> is a maze :)

In the end we use the getaddrinfo_a compat function from here:
https://github.com/libusual/libusual/blob/51d444927e55fed0523e03dd17b392fc70556023/usual/netdb.c#L179

Landry

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:20:20

Modified files:
sysutils/amazon-ecs-cli: Makefile distinfo 

Log message:
Update to ecs-cli-1.3.0.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:16:16

Modified files:
security/gnutls: Makefile distinfo 

Log message:
Update to gnutls-3.5.17.

Re: [update] pgbouncer 1.8.1

[Landry Breuil]

On Fri, Jan 19, 2018 at 03:48:52PM +0100, Landry Breuil wrote:
> Hi,
> 
> had to backport pgbouncer 1.7 to 6.2 ( i need auth_type = hba) and then
> i realized upstream released 1.8 and 1.8.1 (which i'm already running on
> debian), see https://pgbouncer.github.io/changelog.html#pgbouncer-18x
> 
> easy diff, only build-tested :)

While trying to do some actual realworld testing, found something
'strange'.

with a simple remote database definition such as:

gis = host=localhost db=gis

pgbouncer as is fails to resolve localhost (and it uses dns a lot, cf
https://github.com/pgbouncer/pgbouncer#dns-lookup-support) and
connecting to it timeouts when it tries to reach the remote db.

and in the log i get:
WARNING dns: getaddrinfo_a(localhost)=-11, errno=78 (Function not implemented)
LOG S-0x14c2e5dd9010: gis/gis@(bad-af):0 closing because: server dns lookup 
failed (age=0)

seems it tries to use the glibc-only getaddrinfo_a function. It uses the
'compat' adns backend:

process up: pgbouncer 1.8.1, libevent 1.4.15-stable (kqueue), adns: compat, 
tls: LibreSSL 2.7.0

of course i get no issue connecting directly:

$psql -h localhost -d gis -U gis
Password for user gis:
psql (10.1)

$psql -h localhost -p 6432 -d gis -U gis
Password for user gis:


This is not a regression, i get the same thing with 1.7.2. It of course
works fine if i use an ip in the database definition.

I've briefly tested --enable-evdns to keep changes to a minimal since we
already link with libevent1, but then linking fails:

src/dnslookup.c:(.text+0x7f): undefined reference to `evdns_init'
src/dnslookup.c:(.text+0x8a): undefined reference to `evdns_shutdown'
src/dnslookup.c:(.text+0x252): undefined reference to `evdns_shutdown'
src/dnslookup.c:(.text+0x3ad): undefined reference to `evdns_resolve_ipv4'

It 'builds' if i add LDFLAGS='-L${LOCALBASE}/lib -leventextra -levent'
to CONFIGURE_ENV (and libeventextra should move to a LDEP) but that
doesnt *work* at runtime:

LOG process up: pgbouncer 1.8.1, libevent 1.4.15-stable (kqueue), adns:evdns1, 
tls: LibreSSL 2.7.0
...
WARNING lookup failed: localhost: result=1
LOG S-0x33370334010: gis2/gis@(bad-af):0 closing because: server dns lookup 
failed (age=0)

And anyway, upstream seem to say that evdns/libevent1 dns backend is
buggy. Havent digged more in this direction, since our libevent
situation is.. particular.

Looking at the configure output, i then noticed this:
checking for pthread-config... no
Threads not available and fallback getaddrinfo_a() non-functional.

that explains why the 'compat' backend doesnt work. And that one is
pretty hilarious :) The configure script has:

#include pthread.h

... lol. 1.7.2 has it too :) And i have no idea where this interesting
html comes from.. web 2.0 autoconf ?

patching configure to fix that one yields:
checking whether pthreads work with -pthread... yes

Aaaand this finally produces a working pgbouncer with hostnames, since i
think it ends up falling back to our plain libc getaddrinfo. Maybe. I
don't really know, 
https://github.com/pgbouncer/pgbouncer/blob/master/src/dnslookup.c
is a maze :)

so, time to move to libevent2 ? use c-ares ? just patch configure to fix
pthread detection, like the attached patch does ?

Of course i can commit the upgrade as-is now (got an okay from
maintainer, thanks :) since that's not a regression, and can fix the dns
thing separately..

So, thoughts ? That was a quite puzzling one...

Landry
Index: Makefile
===
RCS file: /cvs/ports/databases/pgbouncer/Makefile,v
retrieving revision 1.25
diff -u -r1.25 Makefile
--- Makefile11 Jan 2018 19:27:01 -  1.25
+++ Makefile20 Jan 2018 11:10:18 -
@@ -2,9 +2,8 @@
 
 COMMENT =  lightweight connection pooler for PostgreSQL
 
-V =1.7.2
+V =1.8.1
 DISTNAME = pgbouncer-${V}
-REVISION =  0
 
 CATEGORIES =   databases
 
Index: distinfo
===
RCS file: /cvs/ports/databases/pgbouncer/distinfo,v
retrieving revision 1.10
diff -u -r1.10 distinfo
--- distinfo19 Dec 2017 08:58:15 -  1.10
+++ distinfo20 Jan 2018 11:10:18 -
@@ -1,2 +1,2 @@
-SHA256 (pgbouncer-1.7.2.tar.gz) = 3jazGP5KLyCl9g0cXqYsHKMx9oE9LEhIZuy1kmWhYLo=
-SIZE (pgbouncer-1.7.2.tar.gz) = 462374
+SHA256 (pgbouncer-1.8.1.tar.gz) = +oveKi0sjIDVOoWfjki8ZxPPEn4xx32PeHu8HWc+jcg=
+SIZE (pgbouncer-1.8.1.tar.gz) = 465930
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-configure 20 Jan 2018 11:10:18 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: configure
+--- configure.orig
 configure
+@@ -7190,7 +7190,7 @@ $as_echo_n "checking for the pthreads library -l$flag.
+ # We try pthread_create on general principles.
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:06:16

Modified files:
security/libtasn1: Makefile distinfo 

Log message:
Update to libtasn1-4.13.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:03:45

Modified files:
net/py-boto3   : Makefile distinfo 

Log message:
Update to py-boto3-1.5.19.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:03:31

Modified files:
sysutils/awscli: Makefile distinfo 
sysutils/awscli/pkg: PLIST 

Log message:
Update to awscli-1.14.29.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:03:12

Modified files:
net/py-botocore: Makefile distinfo 
net/py-botocore/pkg: PLIST 

Log message:
Update to py-botocore-1.8.33.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/01/20 04:02:53

Modified files:
print/cups-filters: Makefile distinfo 

Log message:
Update to cups-filters-1.19.0.

Re: gnome-games: part 1

[Antoine Jacoutot]

On Sat, Jan 20, 2018 at 04:25:23AM +, Brian Callahan wrote:
> 
> On 01/16/18 16:54, Victor Kukshiev wrote:
> > ping.
> > 
> > 2018-01-12 20:11 GMT+03:00 Victor Kukshiev :
> > 
> > > hello!
> > > I was partial ported GNOME games.
> > > 
> > > in this archive:
> > > gnome-mahjongg https://wiki.gnome.org/Apps/Mahjongg
> > > gnome-chess https://wiki.gnome.org/Apps/Chess
> > > gnome-sudoku https://wiki.gnome.org/Apps/Sudoku
> > > hitori https://wiki.gnome.org/Apps/Hitori
> > > swell-foop https://wiki.gnome.org/Apps/Swell%20Foop
> > > 
> > > okay?
> > > 
> 
> It is a must that you run portcheck before submitting any ports. portcheck
> identified a number of issues in every single one of these ports. You must
> at a minimum address all the issues in portcheck, though these ports have
> further issues beyond just what portcheck has identified.
> 
> As a courtesy, I went ahead and fixed up gnome-chess. Fix the others like I
> did this one, then resubmit.
> 
> Additionally, if these ports are going to live in x11/gnome (Antoine?) then
> dropping the gnome- prefix from the port directory will have to be done as
> well.

Correct.

-- 
Antoine

CVS: cvs.openbsd.org: ports

[Benoit Lecocq]

CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2018/01/20 02:24:57

Modified files:
devel/git  : Makefile distinfo 
devel/git/patches: patch-Makefile patch-gitweb_gitweb_perl 
   patch-t_t-basic_sh patch-t_test-lib_sh 
devel/git/pkg  : PLIST-main 

Log message:
Update to git-2.16.0.

Re: [NEW] textproc/p5-Text-CSV-Hashify

[Landry Breuil]

On Fri, Jan 19, 2018 at 06:43:21PM -0500, James E Keenan wrote:
> On 01/07/2018 10:50 PM, James E Keenan wrote:
> > Hello ports@,
> > 
> > Here is a new port, for Perl extension Text-CSV-Hashify (version 0.08).
> > 
> >  From DESCR:
> > 
> > The Comma-Separated-Value ('CSV') format is the most common way to store
> > spreadsheets or the output of relational database queries in plain-text
> > format.  However, since commas (or other designated field-separator
> > characters) may be embedded within data entries, the parsing of
> > delimited records is non-trivial.  Fortunately, in Perl this parsing is
> > well handled by CPAN distribution Text::CSV.  This permits us to address
> > more specific data manipulation problems by building modules on top of
> > Text::CSV.
> > 
> > Text::CSV::Hashify is designed for the case where you simply want to
> > turn a CSV file into a Perl hash.  In particular, it is designed for the
> > case where (a) the CSV file's first record is a list of fields in the
> > ancestral database table and (b) one field (column) functions as a
> > primary key, i.e., each record's entry in that field is non-null and is
> > distinct from every other record's entry therein.  Text::CSV::Hashify
> > turns that kind of CSV file into one big hash of hashes.
> > 
> > Text::CSV::Hashify can handle less typical cases; please consult the
> > documentation for its other functionalities.
> > 
> > Please review.
> > 
> > Thank you very much.
> > Jim Keenan
> > 
> > 
> 
> ping on this new port; please review.  Thank you very much.

Port itself looks okay to me to import if anyone with commit access
wants to do so, just beware of the PLIST.orig file in the tarball (cvs
import will Ignore it anyway)

Landry

Re: adjustments for arm clang switch

[Peter Hessler]

On 2018 Jan 20 (Sat) at 09:05:28 + (+), Stuart Henderson wrote:
:On 2018/01/20 16:28, Jonathan Gray wrote:
:> Index: multimedia/mpv/Makefile
:> ===
:> RCS file: /cvs/ports/multimedia/mpv/Makefile,v
:> retrieving revision 1.38
:> diff -u -p -r1.38 Makefile
:> --- multimedia/mpv/Makefile  23 Oct 2017 17:10:52 -  1.38
:> +++ multimedia/mpv/Makefile  20 Jan 2018 00:42:26 -
:> @@ -1,7 +1,7 @@
:>  # $OpenBSD: Makefile,v 1.38 2017/10/23 17:10:52 sthen Exp $
:>  
:>  # archs with atomic ops
:> -ONLY_FOR_ARCHS =aarch64 alpha amd64 i386 mips64 mips64el powerpc sparc64
:> +ONLY_FOR_ARCHS =aarch64 alpha amd64 arm i386 mips64 mips64el powerpc 
sparc64
:>  BROKEN-powerpc =atomics detection fails
:>  
:>  COMMENT =   movie player based on MPlayer/mplayer2
:
:This is probably better written as
:
:NOT_FOR_ARCHS =hppa landisk luna88k m88k
:
:(The current line is missing aarch64).
:

I'm happy with changing it to NOT_FOR_ARCHS, but aarch64 is the first
entry :).

:> Other BROKEN markers are suspect as well
:> 
:> devel/codeblocks/Makefile:BROKEN-arm=wxwidgets va_list c++ mangling 
requires gcc < 4.4
:> devel/arm-none-eabi/gcc-linaro/Makefile:BROKEN-armv7=error during 
libgcc autoconf "checking for suffix of object files", probably similar to i386
:> devel/reposurgeon/Makefile:BROKEN-arm=   out of memory compiling 
cyreposurgeon.c
:> games/crimson/Makefile:BROKEN-arm=   mktileset buggy, loops at high CPU use
:> games/stone-soup/Makefile:BROKEN-arm=tilegen.elf loops burning cpu
:> games/fifengine/Makefile:BROKEN-arm =out of memory when compiling 
fifePYTHON_wrap.cxx
:> lang/seed7/Makefile:BROKEN-arm = gmake: *** [makefile:279: ../bin/make7] 
Bus error (core dumped)
:> security/john-jumbo/Makefile:BROKEN-arm =uaf_encode_plug.c:61: error: 
stray '$' in program
:
:Unless phessler objects I think it would probably make sense to try
:removing these as well.

Yes, please remove those BROKEN-arm markers.  We can add them back if
necessary.


-- 
Concept, n.:
Any "idea" for which an outside consultant billed you more than
$25,000.

Re: cmake.port.mk and DEBUG

[Landry Breuil]

On Fri, Jan 19, 2018 at 03:18:53PM +0100, Jeremie Courreges-Anglas wrote:
> 
> Once again I've been bitten by the special handling of DEBUG done in
> cmake.port.mk.
> 
> First, cmake might use different CFLAGS in debug and release mode (this
> is usually specified by upstream in CMakeLists.txt).  Those CFLAGS might
> be undesirable or even unusable on OpenBSD (iirc some stuff might try to
> link against valgrind or ubsan / whatever).  Those might be useful but
> IMO you shouldn't get to use them when all you want is to rebuild a port
> with DEBUG=-g, ie debug symbols.
> 
> Also the release/debug difference means that some ports just won't
> package because of file names changes:
> 
> --8<--
> ===>  Building package for libical-3.0.1
> Create /usr/ports/packages/amd64/all/libical-3.0.1.tgz
> Creating package libical-3.0.1
> Error: change in plist
> | If the old and new builds were done correctly
> | (fully up-to-date ports tree including relevant MODULES)
> | then someone probably forgot to bump a REVISION.
> | (see bsd.port.mk(5), PACKAGE_REPOSITORY)
> --- /usr/ports/plist/amd64/libical-3.0.1
> +++ /usr/ports/plist/amd64/libical-3.0.1-new
> @@ -74,7 +74,7 @@
>  lib/cmake/LibIcal/
>  lib/cmake/LibIcal/LibIcalConfig.cmake
>  lib/cmake/LibIcal/LibIcalConfigVersion.cmake
> -lib/cmake/LibIcal/LibIcalTargets-release.cmake
> +lib/cmake/LibIcal/LibIcalTargets-debug.cmake
>  lib/cmake/LibIcal/LibIcalTargets.cmake
>  lib/girepository-1.0/
>  lib/girepository-1.0/ICalGLib-3.0.typelib
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1943 
> '/usr/ports/packages/amd64/all/libical-3.0.1.tgz')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2440 
> '_internal-package')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2419 'package')
> *** Error 1 in /usr/ports/textproc/libical 
> (/usr/ports/infrastructure/mk/bsd.port.mk:3421 'repackage')
> -->8--
> 
>   $ pkglocate  release.cmake | wc -l
>150
> 
> I think it's fair to say that the ports tree is not ready to use
> cmake with DEBUG=-g.  This could be fixed in theory, but someone has to
> do the work*, and is does not invalidate my first point.

What do you mean by 'not ready' ?

> So here's the simple diff that does less and makes DEBUG=-g actually
> usable.

As the one with came up with what you're proposing to revert, i had to
sit and look again. I thought i had done this recently, but it turns out
it was already 3+ years ago in r1.34.

My usecase was at the time, i want to be able to just set DEBUG, and
have cmake build with upstream-provided debug configuration (setting
various flags, not only CFLAGS) because that's much more different and
useful (*in my opinion*) that just setting -g: sometimes it enables
verbose logging on the output, sometimes different codepaths are used
for debugging corner cases - this is *convenient*, but i agree it
totally depends on the case and what upstream made special in the debug
build type.

For example, i don't want to use gdb on qgis, unless in an extremely
desperate case.

When you set CMAKE_BUILD_TYPE, cmake installs the -debug.cmake file
instead of the -release.cmake file, so MODCMAKE_BUILD_SUFFIX was added
so that ports packaged. Minus the eventual PLIST_DB warning, but you
know make clean=plist right ? :)

If you don't like the fact that it's 'automagic' with DEBUG, change the
variable to have it in a distinct way (dunno, MODCMAKE_DEBUG?) that sets
CMAKE_BUILD_TYPE and MODCMAKE_BUILD_SUFFIX (and DEBUG while here?) like
it's done now with DEBUG ?

With DEBUG set it was convenient because it also (iirc) disabled
stripping, but i dont know if it has any effect with cmake-builds.

> * why isn't MODCMAKE_BUILD_SUFFIX properly substituted in all PLISTs?

Well, some do it right, some don't and they need to be fixed ? I've just
fixed the 3 occurences that were wrong, over 150... no so bad, right ?
If we want to keep it that way, could be one more check to add to
portcheck for the ones that use it...

Landry

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2018/01/20 02:13:35

Modified files:
devel/libfirm/pkg: PLIST 
geo/mapserver/pkg: PLIST-utils 
graphics/simgear/pkg: PLIST 

Log message:
Use MODCMAKE_BUILD_SUFFIX where appropriate.

Re: adjustments for arm clang switch

[Stuart Henderson]

On 2018/01/20 16:28, Jonathan Gray wrote:
> With armv7 switching to clang as the base compiler atomic builtins and
> -mfpu=neon are now available on arm.

Comments on a couple below, others are OK with me:

> Index: lang/racket-minimal/Makefile
> ===
> RCS file: /cvs/ports/lang/racket-minimal/Makefile,v
> retrieving revision 1.43
> diff -u -p -r1.43 Makefile
> --- lang/racket-minimal/Makefile  2 Dec 2017 21:39:49 -   1.43
> +++ lang/racket-minimal/Makefile  20 Jan 2018 00:52:42 -
> @@ -38,7 +38,6 @@ EXTRACT_SUFX =  .tgz
>  # "places" and "futures" require TLS.
>  COMPILER =   base-clang ports-gcc
>  COMPILER_LANGS = c
> -MODGCC4_ARCHS =  arm
>  
>  LIB_DEPENDS =converters/libiconv \
>   databases/sqlite3 \

Here ports-gcc is only used for arm (restricting from the defaults).
By removing MODGCC4_ARCHS all !base-clang arches switch to ports-gcc,
so the effect you are looking for would come from removing the
COMPILER* lines as well.

This doesn't really square up with the above comment about TLS though
because ONLY_FOR_ARCHS lists !base-clang arches. juanfra, do you know
what's going on here?

> Index: multimedia/mpv/Makefile
> ===
> RCS file: /cvs/ports/multimedia/mpv/Makefile,v
> retrieving revision 1.38
> diff -u -p -r1.38 Makefile
> --- multimedia/mpv/Makefile   23 Oct 2017 17:10:52 -  1.38
> +++ multimedia/mpv/Makefile   20 Jan 2018 00:42:26 -
> @@ -1,7 +1,7 @@
>  # $OpenBSD: Makefile,v 1.38 2017/10/23 17:10:52 sthen Exp $
>  
>  # archs with atomic ops
> -ONLY_FOR_ARCHS = aarch64 alpha amd64 i386 mips64 mips64el powerpc sparc64
> +ONLY_FOR_ARCHS = aarch64 alpha amd64 arm i386 mips64 mips64el powerpc 
> sparc64
>  BROKEN-powerpc = atomics detection fails
>  
>  COMMENT =movie player based on MPlayer/mplayer2

This is probably better written as

NOT_FOR_ARCHS = hppa landisk luna88k m88k

(The current line is missing aarch64).

> Index: x11/qt4/Makefile
> ===
> RCS file: /cvs/ports/x11/qt4/Makefile,v
> retrieving revision 1.150
> diff -u -p -r1.150 Makefile
> --- x11/qt4/Makefile  4 Jan 2018 09:34:24 -   1.150
> +++ x11/qt4/Makefile  20 Jan 2018 00:56:07 -
> @@ -150,12 +150,6 @@ CONFIGURE_ARGS +=-release
>  
>  .include 
>  
> -MODULES =gcc4
> -
> -# for __sync_add_and_fetch_4, __sync_sub_and_fetch_4
> -MODGCC4_ARCHS =  arm
> -MODGCC4_LANGS =  c++
> -
>  LIB_DEPENDS =
>  WANTLIB =
>  RUN_DEPENDS =

I wondered about the ".include " here. Turns out it's
to support "no_examples" builds which were removed with Makefile r1.122
so that could be removed as well, but that's unrelated to the
MODULES=gcc4 things.

> Other BROKEN markers are suspect as well
> 
> devel/codeblocks/Makefile:BROKEN-arm= wxwidgets va_list c++ mangling requires 
> gcc < 4.4
> devel/arm-none-eabi/gcc-linaro/Makefile:BROKEN-armv7= error during libgcc 
> autoconf "checking for suffix of object files", probably similar to i386
> devel/reposurgeon/Makefile:BROKEN-arm=out of memory compiling 
> cyreposurgeon.c
> games/crimson/Makefile:BROKEN-arm=mktileset buggy, loops at high CPU use
> games/stone-soup/Makefile:BROKEN-arm= tilegen.elf loops burning cpu
> games/fifengine/Makefile:BROKEN-arm = out of memory when compiling 
> fifePYTHON_wrap.cxx
> lang/seed7/Makefile:BROKEN-arm =  gmake: *** [makefile:279: ../bin/make7] 
> Bus error (core dumped)
> security/john-jumbo/Makefile:BROKEN-arm = uaf_encode_plug.c:61: error: 
> stray '$' in program

Unless phessler objects I think it would probably make sense to try
removing these as well.

CVS: cvs.openbsd.org: ports

[Benoit Lecocq]

CVSROOT:/cvs
Module name:ports
Changes by: ben...@cvs.openbsd.org  2018/01/20 01:30:55

Modified files:
graphics/gifsicle: Makefile distinfo 

Log message:
Update to gifsicle-1.91.