CVS: cvs.openbsd.org: ports

[Kirill Bychkov]

CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2016/02/13 06:43:19

Modified files:
net/owncloudclient: Makefile distinfo 
net/owncloudclient/patches: patch-src_gui_application_cpp 
net/owncloudclient/pkg: PLIST 

Log message:
update to owncloudclient-2.1.1

Re: CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

On Sat, Feb 13, 2016 at 06:43:19AM -0700, Kirill Bychkov wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   ki...@cvs.openbsd.org   2016/02/13 06:43:19
> 
> Modified files:
>   net/owncloudclient: Makefile distinfo 
>   net/owncloudclient/patches: patch-src_gui_application_cpp 
>   net/owncloudclient/pkg: PLIST 
> 
> Log message:
> update to owncloudclient-2.1.1

Can you elaborate as to why this update is worth pushing during a "soft-lock"?
https://marc.info/?l=openbsd-ports=145460329517278=2

-- 
Antoine

Re: is hedgewars broken?

[David Coppa]

On Sat, 13 Feb 2016, Antoine Jacoutot wrote:

> > Maybe the haskell package db is fucked (wouldn't be the first time
> > this happens)?
> > 
> > Does
> > 
> > ghc-pkg check
> > 
> > compain? Does
> > 
> > ghc-pkg list | grep dataenc
> > 
> > show anything?
> 
> Looks sane.
> 
> $ ghc-pkg check
> $ echo $?
> 0
> $ ghc-pkg list | grep dataenc
> dataenc-0.14.0.7

What CMake does is:

/usr/local/bin/ghc -DMODULE=Codec.Binary.Base64 -DFUNCTION=encode 
-DPARAMETERS="" -cpp -c 
/usr/pobj/hedgewars-src-0.9.22/hedgewars-src-0.9.22/cmake_modules/checkModule.hs

And then:

if(${COMMAND_RESULT} EQUAL 0)
  message(STATUS "Looking for ${FUNCTION} in ${MODULE} - found")
... etc ...

Where checkModule.hs is:

---8<---

module Main where

import qualified MODULE as M

main = undefined $ M.FUNCTION PARAMETERS

---8<---

Ciao!
David

Re: xlsx2csv broken

[Nigel Taylor]

On 02/13/16 08:14, Antoine Jacoutot wrote:
> On Sat, Feb 13, 2016 at 01:35:38AM +0100, Dmitrij D. Czarkoff wrote:
>> Antoine Jacoutot said:
>>> unset GOPATH; export 
>>> GOPATH="/exopi-obj/pobj/xlsx2csv-20150225/go:/usr/local/go-pkg"; go install 
>>> -x github.com/tealeg/xlsx2csv
>>> WORK=/tmp/go-build67122
>>> mkdir -p $WORK/github.com/tealeg/xlsx/_obj/
>>> mkdir -p $WORK/github.com/tealeg/
>>> cd /usr/local/go-pkg/src/github.com/tealeg/xlsx
>>> /usr/local/go/pkg/tool/openbsd_amd64/compile -o 
>>> $WORK/github.com/tealeg/xlsx.a -trimpath $WORK -p github.com/tealeg/xlsx 
>>> -complete -buildid 90518c0c038b7176e8b01fb5b752aef4df0eb80d -D 
>>> _/usr/local/go-pkg/src/github.com/tealeg/xlsx -I $WORK -pack ./cell.go 
>>> ./col.go ./date.go ./doc.go ./file.go ./hsl.go ./lib.go ./reftable.go 
>>> ./row.go ./sheet.go ./style.go ./templates.go ./theme.go ./write.go 
>>> ./xmlContentTypes.go ./xmlSharedStrings.go ./xmlStyle.go ./xmlTheme.go 
>>> ./xmlWorkbook.go ./xmlWorksheet.go
>>
>> For some reason go tries to rebuild github.com/tealeg/xlsx package
>> (textproc/go-xlsx).  This should never happen, and it indeed never
>> happens on my machine.  Interestingly, similar thing happened before
>> (http://article.gmane.org/gmane.os.openbsd.ports/77273), and I couldn't
>> reproduce it back then either.  Maybe something uncommon in your
>> environment?
> 
> $ cat /etc/mk.conf
>   
>   
> BSDSRCDIR=/exopi-cvs/src
> XSRCDIR=/exopi-cvs/xenocara
> PORTSDIR=/exopi-cvs/ports
> BSDOBJDIR=/exopi-obj/obj
> XOBJDIR=/exopi-obj/xobj
> WRKOBJDIR=/exopi-obj/pobj
> MASTER_SITE_OPENBSD=http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/
> .include "${PORTSDIR}/infrastructure/templates/mk.conf.template"
> 
> dpb host file:
> COLOR=1
> DEFAULT build_user=_pbuild stuck=10800
> FETCH_USER=_pfetch
> LOG_USER=exopi
> STARTUP=/home/exopi/bin/exo-cleanhost
> localhost
> exopi-1
> exopi-2
> exopi-3
> exopi-4
> exopi-5
> exopi-6
> exopi-7
> 
> "/exopi-cvs" is NFS mounted
> 
> I wouldn't call this particularly uncommon...
> You said that "This should never happen" -- ok but why, because it does; so 
> what would trigger a rebuild like this? I don't know the first thing about 
> the go build system.
> Once we know that, then we can start hunting.
> 

$ doas touch -t 20150101 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a 

That's the one way I found to get the same error.

So does install go-xlsx and touch xlsx.a get rid of the problem. To 
ensure xlsx.a is newer than /usr/local/go-pkg/src/xlsx

maybe look at pkg_info -f go-xlsx and time stamps. My package they 
are all the same. I don't have any nfs.

xlsx.a only needs to be one second earlier to cause the problem.

$ stat /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a
1033 2463041 -r--r--r-- 1 root bin 9827192 1113336 "Feb 13 09:17:02 2016" "Feb 
10 22:19:12 2016" "Feb 13 09:06:14 2016" 32768 2240 0 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a
$ doas touch -t 201602102219.11 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a
$ stat /usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a
1033 2463041 -r--r--r-- 1 root bin 9827192 1113336 "Feb 10 22:19:11 2016" "Feb 
10 22:19:11 2016" "Feb 13 09:57:10 2016" 32768 2240 0 
/usr/local/go-pkg/pkg/openbsd_amd64/github.com/tealeg/xlsx.a

That was enough to cause the problem.


lang/go/go.port.mk has

MODGO_INSTALL_TARGET =  ${INSTALL_DATA_DIR} ${MODGO_PACKAGE_PATH}; \
cp -R ${MODGO_WORKSPACE}/pkg \
${MODGO_WORKSPACE}/src \
${MODGO_PACKAGE_PATH};

could try changing pkg and src order if seeing a very small time difference 
or use two separate cp's

MODGO_INSTALL_TARGET = ${INSTALL_DATA_DIR} ${MODGO_PACKAGE_PATH}; \
cp -R ${MODGO_WORKSPACE}/src \
${MODGO_PACKAGE_PATH}; \
cp -R ${MODGO_WORKSPACE}/pkg \
${MODGO_PACKAGE_PATH};

I can't repeat the problem just building so can't check any of this is or 
solves the problem.

Re: alpha-1.ports.openbsd.org bulk build report

[Matthieu Herrb]

So, here is a patch that should let libGL to build again on
alpha. I've not done a full clean xenocara build with it yet though,
given how slow my alpha is.

In addition to the non-existent sync operation, I had to force 2 files
to build with -O0.

There is a lot of Makefile.in churn since I did some autotools
hackery...

Index: lib/mesa/Makefile.in
===
RCS file: /cvs/OpenBSD/xenocara/lib/mesa/Makefile.in,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile.in
--- lib/mesa/Makefile.in23 Dec 2015 13:43:05 -  1.3
+++ lib/mesa/Makefile.in13 Feb 2016 15:41:54 -
@@ -322,6 +322,7 @@ OBJEXT = @OBJEXT@
 OMX_CFLAGS = @OMX_CFLAGS@
 OMX_LIBS = @OMX_LIBS@
 OMX_LIB_INSTALL_DIR = @OMX_LIB_INSTALL_DIR@
+OPENBSD_ALPHA = @OPENBSD_ALPHA@
 OPENCL_LIBNAME = @OPENCL_LIBNAME@
 OPENCL_VERSION = @OPENCL_VERSION@
 OSMESA_LIB = @OSMESA_LIB@
Index: lib/mesa/configure
===
RCS file: /cvs/OpenBSD/xenocara/lib/mesa/configure,v
retrieving revision 1.4
diff -u -p -u -r1.4 configure
--- lib/mesa/configure  24 Jan 2016 01:21:23 -  1.4
+++ lib/mesa/configure  13 Feb 2016 15:41:54 -
@@ -903,6 +903,9 @@ HAVE_LD_DYNAMIC_LIST_TRUE
 HAVE_LD_VERSION_SCRIPT_FALSE
 HAVE_LD_VERSION_SCRIPT_TRUE
 LD_NO_UNDEFINED
+OPENBSD_ALPHA
+OPENBSD_ALPHA_FALSE
+OPENBSD_ALPHA_TRUE
 GC_SECTIONS
 BSYMBOLIC
 BUILD_SHARED_FALSE
@@ -19300,12 +19303,24 @@ openbsd*)
 case "$host_cpu" in
 powerpc*)
 GC_SECTIONS="" ;;
+alpha*)
+openbsd_alpha=1 ;;
 esac
 ;;
 esac
 
 
 
+ if test x$openbsd_alpha = x1; then
+  OPENBSD_ALPHA_TRUE=
+  OPENBSD_ALPHA_FALSE='#'
+else
+  OPENBSD_ALPHA_TRUE='#'
+  OPENBSD_ALPHA_FALSE=
+fi
+
+
+
 case "$host_os" in
 openbsd* | darwin* )
 LD_NO_UNDEFINED="" ;;
@@ -25658,6 +25673,10 @@ Usually this means the macro was only in
 fi
 if test -z "${BUILD_SHARED_TRUE}" && test -z "${BUILD_SHARED_FALSE}"; then
   as_fn_error $? "conditional \"BUILD_SHARED\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
+if test -z "${OPENBSD_ALPHA_TRUE}" && test -z "${OPENBSD_ALPHA_FALSE}"; then
+  as_fn_error $? "conditional \"OPENBSD_ALPHA\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
 if test -z "${HAVE_LD_VERSION_SCRIPT_TRUE}" && test -z 
"${HAVE_LD_VERSION_SCRIPT_FALSE}"; then
Index: lib/mesa/configure.ac
===
RCS file: /cvs/OpenBSD/xenocara/lib/mesa/configure.ac,v
retrieving revision 1.5
diff -u -p -u -r1.5 configure.ac
--- lib/mesa/configure.ac   23 Dec 2015 13:43:05 -  1.5
+++ lib/mesa/configure.ac   13 Feb 2016 15:41:54 -
@@ -475,11 +475,16 @@ openbsd*)
 case "$host_cpu" in
 powerpc*)
 GC_SECTIONS="" ;;
+alpha*)
+openbsd_alpha=1 ;;
 esac
 ;;
 esac
 
 AC_SUBST([GC_SECTIONS])
+
+AM_CONDITIONAL([OPENBSD_ALPHA], [test x$openbsd_alpha = x1])
+AC_SUBST([OPENBSD_ALPHA])
 
 dnl
 dnl OpenBSD does not have DT_NEEDED entries for libc by design
Index: lib/mesa/src/Makefile.in
===
RCS file: /cvs/OpenBSD/xenocara/lib/mesa/src/Makefile.in,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile.in
--- lib/mesa/src/Makefile.in23 Dec 2015 13:43:05 -  1.3
+++ lib/mesa/src/Makefile.in13 Feb 2016 15:41:55 -
@@ -332,6 +332,7 @@ OBJEXT = @OBJEXT@
 OMX_CFLAGS = @OMX_CFLAGS@
 OMX_LIBS = @OMX_LIBS@
 OMX_LIB_INSTALL_DIR = @OMX_LIB_INSTALL_DIR@
+OPENBSD_ALPHA = @OPENBSD_ALPHA@
 OPENCL_LIBNAME = @OPENCL_LIBNAME@
 OPENCL_VERSION = @OPENCL_VERSION@
 OSMESA_LIB = @OSMESA_LIB@
Index: lib/mesa/src/egl/Makefile.in
===
RCS file: /cvs/OpenBSD/xenocara/lib/mesa/src/egl/Makefile.in,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile.in
--- lib/mesa/src/egl/Makefile.in23 Dec 2015 13:43:05 -  1.3
+++ lib/mesa/src/egl/Makefile.in13 Feb 2016 15:41:55 -
@@ -397,6 +397,7 @@ OBJEXT = @OBJEXT@
 OMX_CFLAGS = @OMX_CFLAGS@
 OMX_LIBS = @OMX_LIBS@
 OMX_LIB_INSTALL_DIR = @OMX_LIB_INSTALL_DIR@
+OPENBSD_ALPHA = @OPENBSD_ALPHA@
 OPENCL_LIBNAME = @OPENCL_LIBNAME@
 OPENCL_VERSION = @OPENCL_VERSION@
 OSMESA_LIB = @OSMESA_LIB@
Index: lib/mesa/src/egl/wayland/wayland-drm/Makefile.in
===
RCS file: 
/cvs/OpenBSD/xenocara/lib/mesa/src/egl/wayland/wayland-drm/Makefile.in,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile.in
--- lib/mesa/src/egl/wayland/wayland-drm/Makefile.in23 Dec 2015 13:43:05 
-  1.3
+++ lib/mesa/src/egl/wayland/wayland-drm/Makefile.in13 Feb 2016 15:41:55 
-
@@ -264,6 +264,7 @@ OBJEXT = @OBJEXT@
 OMX_CFLAGS = @OMX_CFLAGS@
 OMX_LIBS = @OMX_LIBS@
 OMX_LIB_INSTALL_DIR = @OMX_LIB_INSTALL_DIR@
+OPENBSD_ALPHA = @OPENBSD_ALPHA@
 

Re: [FIX] make productivity/taskd install proper vars file

[Stuart Henderson]

I presume this is a file which users need to edit? If so, the @sample is 
correct and its OK with me.

On 11 February 2016 20:35:03 GMT+00:00, viq  wrote:
>On pon, 2016-02-08 at 10:05 -0600, Kent R. Spillner wrote:
>> On Mon, Feb 08, 2016 at 08:11:22AM +0100, viq wrote:
>> > Bump
>> 
>> Hrrmmm, the mail I sent about this last week never made it to the
>> list.
>> I would prefer to commit this fix.
>> 
>> Ok?
>
>This works for me with two linux clients. Can we get this imported so
>release doesn't ship with package with errors?
>Also, I believe you want to drop the @sample line for vars.
>
>> Index: Makefile
>> ===
>> RCS file: /work/cvsroot/ports/productivity/taskd/Makefile,v
>> retrieving revision 1.5
>> diff -p -u -r1.5 Makefile
>> --- Makefile 28 Jan 2016 17:15:00 -  1.5
>> +++ Makefile 8 Feb 2016 15:49:27 -
>> @@ -4,6 +4,7 @@ COMMENT =lightweight server providing a
>>  
>>  DISTNAME =  taskd-1.1.0
>>  CATEGORIES =productivity net
>> +REVISION =  0
>>  
>>  HOMEPAGE =  http://www.taskwarrior.org/
>>  
>> @@ -41,6 +42,8 @@ post-install:
>>  ${PREFIX}/share/examples/taskd/pki/
>>  ${INSTALL_DATA} ${WRKSRC}/pki/README \
>>  ${PREFIX}/share/examples/taskd/pki/
>> +${INSTALL_DATA} ${WRKSRC}/pki/vars \
>> +${PREFIX}/share/examples/taskd/pki/vars.dist
>>  ${SUBST_DATA} ${FILESDIR}/config \
>>  ${PREFIX}/share/examples/taskd/config
>>  
>> Index: pkg/PLIST
>> ===
>> RCS file: /work/cvsroot/ports/productivity/taskd/pkg/PLIST,v
>> retrieving revision 1.3
>> diff -p -u -r1.3 PLIST
>> --- pkg/PLIST28 Jan 2016 17:15:05 -  1.3
>> +++ pkg/PLIST8 Feb 2016 15:49:54 -
>> @@ -35,6 +35,7 @@ share/examples/taskd/pki/generate.ca
>>  share/examples/taskd/pki/generate.client
>>  share/examples/taskd/pki/generate.crl
>>  share/examples/taskd/pki/generate.server
>> +share/examples/taskd/pki/vars.dist
>>  @sample share/examples/taskd/pki/vars
>>  share/taskd/
>>  share/taskd/AUTHORS

-- 
Sent from a phone, please excuse the formatting.

Re: is hedgewars broken?

[Matthias Kilian]

On Sat, Feb 13, 2016 at 10:52:07AM +0100, David Coppa wrote:
> > > Maybe the haskell package db is fucked (wouldn't be the first time
> > > this happens)?
> > > 
> > > Does
> > > 
> > >   ghc-pkg check
> > > 
> > > compain? Does
> > > 
> > >   ghc-pkg list | grep dataenc
> > > 
> > > show anything?
> > 
> > Looks sane.
> > 
> > $ ghc-pkg check
> > $ echo $?
> > 0
> > $ ghc-pkg list | grep dataenc
> > dataenc-0.14.0.7
> 
> What CMake does is:
> 
> /usr/local/bin/ghc -DMODULE=Codec.Binary.Base64 -DFUNCTION=encode 
> -DPARAMETERS="" -cpp -c 
> /usr/pobj/hedgewars-src-0.9.22/hedgewars-src-0.9.22/cmake_modules/checkModule.hs
> 
> And then:
> 
> if(${COMMAND_RESULT} EQUAL 0)
>   message(STATUS "Looking for ${FUNCTION} in ${MODULE} - found")
> ... etc ...
> 
> Where checkModule.hs is:
> 
> ---8<---
> 
> module Main where
> 
> import qualified MODULE as M
> 
> main = undefined $ M.FUNCTION PARAMETERS
> 
> ---8<---

I don't see any way how and why this can fail for antoine, given
that he has dataenc installed and ghc-pkg seems to be happy about
it. Except that it may be the same mysterious bug antoine sees from
time to time with haskell ports (ghc exiting with an exit code !=
0 but without any useful error message).

Ciao,
Kili

Re: is hedgewars broken?

[Antoine Jacoutot]

> Maybe the haskell package db is fucked (wouldn't be the first time
> this happens)?
> 
> Does
> 
>   ghc-pkg check
> 
> compain? Does
> 
>   ghc-pkg list | grep dataenc
> 
> show anything?

Looks sane.

$ ghc-pkg check
$ echo $?
0
$ ghc-pkg list | grep dataenc
dataenc-0.14.0.7


-- 
Antoine

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2016/02/13 01:27:32

Modified files:
mail/mozilla-thunderbird: Makefile 

Log message:
Grr. Remove damn REVISION-main.

Re: xlsx2csv broken

[Antoine Jacoutot]

On Sat, Feb 13, 2016 at 01:35:38AM +0100, Dmitrij D. Czarkoff wrote:
> Antoine Jacoutot said:
> > unset GOPATH; export 
> > GOPATH="/exopi-obj/pobj/xlsx2csv-20150225/go:/usr/local/go-pkg"; go install 
> > -x github.com/tealeg/xlsx2csv
> > WORK=/tmp/go-build67122
> > mkdir -p $WORK/github.com/tealeg/xlsx/_obj/
> > mkdir -p $WORK/github.com/tealeg/
> > cd /usr/local/go-pkg/src/github.com/tealeg/xlsx
> > /usr/local/go/pkg/tool/openbsd_amd64/compile -o 
> > $WORK/github.com/tealeg/xlsx.a -trimpath $WORK -p github.com/tealeg/xlsx 
> > -complete -buildid 90518c0c038b7176e8b01fb5b752aef4df0eb80d -D 
> > _/usr/local/go-pkg/src/github.com/tealeg/xlsx -I $WORK -pack ./cell.go 
> > ./col.go ./date.go ./doc.go ./file.go ./hsl.go ./lib.go ./reftable.go 
> > ./row.go ./sheet.go ./style.go ./templates.go ./theme.go ./write.go 
> > ./xmlContentTypes.go ./xmlSharedStrings.go ./xmlStyle.go ./xmlTheme.go 
> > ./xmlWorkbook.go ./xmlWorksheet.go
> 
> For some reason go tries to rebuild github.com/tealeg/xlsx package
> (textproc/go-xlsx).  This should never happen, and it indeed never
> happens on my machine.  Interestingly, similar thing happened before
> (http://article.gmane.org/gmane.os.openbsd.ports/77273), and I couldn't
> reproduce it back then either.  Maybe something uncommon in your
> environment?

$ cat /etc/mk.conf  

  
BSDSRCDIR=/exopi-cvs/src
XSRCDIR=/exopi-cvs/xenocara
PORTSDIR=/exopi-cvs/ports
BSDOBJDIR=/exopi-obj/obj
XOBJDIR=/exopi-obj/xobj
WRKOBJDIR=/exopi-obj/pobj
MASTER_SITE_OPENBSD=http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/
.include "${PORTSDIR}/infrastructure/templates/mk.conf.template"

dpb host file:
COLOR=1
DEFAULT build_user=_pbuild stuck=10800
FETCH_USER=_pfetch
LOG_USER=exopi
STARTUP=/home/exopi/bin/exo-cleanhost
localhost
exopi-1
exopi-2
exopi-3
exopi-4
exopi-5
exopi-6
exopi-7

"/exopi-cvs" is NFS mounted

I wouldn't call this particularly uncommon...
You said that "This should never happen" -- ok but why, because it does; so 
what would trigger a rebuild like this? I don't know the first thing about the 
go build system.
Once we know that, then we can start hunting.

-- 
Antoine

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2016/02/13 01:26:46

Modified files:
mail/mozilla-thunderbird: Makefile distinfo 
mail/thunderbird-i18n: Makefile.inc distinfo 

Log message:
Security update to thunderbird 38.6.0/lightning 4.0.6.

See https://www.mozilla.org/en-US/thunderbird/38.6.0/releasenotes/
Fixes MFSA2016-14.
ok sthen@ naddy@

Re: prosody with mysql clarification

[Stuart Henderson]

I don't know prosody very well. But can you run it in the foreground
with LD_DEBUG set in the environment? This might give clues. There will
probably be a lot of output, so run it under script(1).


On 2016/02/12 22:57, Stephen Graf wrote:
> Henrik, I would appreciate if you could look into this.  I put prosody and
> the mysql driver on my production system with the same error.  The
> production system is also the release version of openBSD 5.8 and the
> additions came from packages. Do you have a test system on which you can
> test this?  There is really nothing to configure to add mysql other than
> adding the lua mysql package.
> 
> 
> Error message from production system:
> 
> Feb 12 22:42:06 storagemanager  error   Failed to load storage driver plugin
> sql on secure.gccinc.ca: /usr/local/share/lua/5.1/DBI.lua:52: Cannot load
> driver MySQL. Available drivers are: SQLite3
> stack traceback:
> 
> But the mysql package is there:
> 
> # ls -al /usr/local/lib/lua/5.1
> total 392
> drwxr-xr-x  5 root  wheel512 Feb 12 20:25 .
> drwxr-xr-x  3 root  wheel512 Jan 14 22:32 ..
> -r-xr-xr-x  1 root  bin28966 Aug  7  2015 dbdmysql.so
> -r-xr-xr-x  1 root  bin18801 Aug  7  2015 dbdsqlite3.so
> -r--r--r--  1 root  bin18473 Aug  7  2015 lfs.so
> drwxr-xr-x  2 root  wheel512 Feb 12 20:22 luaevent
> -r--r--r--  1 root  bin39219 Aug  7  2015 lxp.so
> drwxr-xr-x  2 root  wheel512 Feb 12 20:22 mime
> drwxr-xr-x  2 root  wheel512 Feb 12 20:22 socket
> -r--r--r--  1 root  bin63197 Aug  7  2015 ssl.so
> -r--r--r--  1 root  bin13229 Aug  7  2015 zlib.so
> 
> 
> -Original Message-
> From: owner-po...@openbsd.org [mailto:owner-po...@openbsd.org] On Behalf Of
> Stephen Graf
> Sent: Friday, February 12, 2016 2:07 PM
> To: ports@openbsd.org
> Subject: FW: prosody with mysql clarification
> 
> Additional information:
> 
> The system is running openBSD 5.8 from the release.  It is a test system.
> It did have wireshark and redis installed which brought in lua ver 5.2.  I
> took all the lua packages pertaining to lua out and resinstalled just
> prosody and the mysql and postgress drivers.
> 
> -Original Message-
> From: Adam Wolk [mailto:adam.w...@tintagel.pl]
> Sent: Friday, February 12, 2016 1:54 PM
> To: Stephen Graf 
> Subject: Re: prosody with mysql clarification
> 
> On Fri, 12 Feb 2016 13:02:56 -0800
> "Stephen Graf"  wrote:
> 
> > Thank you for replying to my post.  I am sending this to you only as I 
> > am not sure of the procedures on the ports mailing list.  I have used 
> > openBSD for many years for bacula, samba and recently ownCloud and 
> > have never resorted to the opwnBSD mailing lists for help.
> > However I am wanting to install a jabber server and I first tried 
> > jabberd until I realized the package is horribly out of date and not 
> > maintained.  Prosody seems much better and cleaner.  The installation 
> > of mysql seems simply enough, but it just does not seem to work and 
> > there is very little on the web for help.
> > 
> 
> Hi Stephen,
> No need to worry about ports@. Your email was OK, people just asked for more
> detail as it was hard to judge what the issue was exactly.
> 
> In short I think you should forward the details you provided here to the
> ports@ mailing list. Additionally outlining if you are using -current or a
> specific release (that's the only information missing here I think). I added
> some more answers inline. Feel free to just forward this email or your
> original reply with more details.
> 
> > If you have a few spare moments, I have listed what I have done.  If 
> > you have a test system can you try mysql?  I added the postgress 
> > driver on my test system and it seems to pick that up.
> > 
> 
> Unfortunately my XMPP system is also my personal mail server additionally
> running -current. I would need to upgrade to a newer snapshot before trying
> any mysql ports and I would rather avoid service disruption at this point. I
> could try in a VM if you indicate which OpenBSD version you are trying to
> accomplish this with.
> 
> > I am trying to set up mysql and getting an error saying the DBI.lua 
> > module cannot load the driver MYSQL.  I looked at the DBI.lua code and 
> > it would seem that it should work.
> > 
> > Error message from log:
> > 
> > Feb 12 11:29:27 modulemanager   error   Error initializing module
> > 'storage_sql' on 'xxx': /usr/local/share/lua/5.1/DBI.lua:52: Cannot 
> > load driver MySQL. Available drivers are: SQLite3,PostgreSQL stack
> > traceback:
> > 
> 
> This really looks like it could be a valid bug, considering that your setup
> properly detects postgresql. Note I asked if you did anything post
> installing as your initial mail didn't indicate it.
> 
> > 
> > From DBI.lua code:
> > 
> > -- Driver to module mapping
> > local name_to_module = {
> > MySQL = 'dbdmysql',
> > PostgreSQL = 'dbdpostgresql',
> > SQLite3 = 'dbdsqlite3',
> > DB2 = 

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/02/13 14:54:28

Modified files:
databases/postgresql: Makefile distinfo 
databases/postgresql/patches: patch-src_backend_libpq_ip_c 
  patch-src_include_storage_s_lock_h 
  
patch-src_interfaces_ecpg_compatlib_Makefile 
  
patch-src_interfaces_ecpg_pgtypeslib_Makefile 
databases/postgresql/pkg: PLIST-docs PLIST-main 

Log message:
SECURITY update to PostgreSQL 9.4.6: various fixes including one for
CVE-2016-0773, an issue with regular expression parsing. Various other fixes.

Note: ..."if you are upgrading an installation that contains any GIN
indexes that use the (non-default) jsonb_path_ops operator class, see
the first changelog entry"...
http://www.postgresql.org/docs/current/static/release-9-4-6.html

OK pea@

Re: [FIX] make productivity/taskd install proper vars file

[viq]

On Sat, Feb 13, 2016 at 8:17 PM, Stuart Henderson 
wrote:

> I presume this is a file which users need to edit? If so, the @sample is
> correct and its OK with me.


Yes, and I retract my statement, I missed the .dist part.


> On 11 February 2016 20:35:03 GMT+00:00, viq  wrote:
> >On pon, 2016-02-08 at 10:05 -0600, Kent R. Spillner wrote:
> >> On Mon, Feb 08, 2016 at 08:11:22AM +0100, viq wrote:
> >> > Bump
> >>
> >> Hrrmmm, the mail I sent about this last week never made it to the
> >> list.
> >> I would prefer to commit this fix.
> >>
> >> Ok?
> >
> >This works for me with two linux clients. Can we get this imported so
> >release doesn't ship with package with errors?
> >Also, I believe you want to drop the @sample line for vars.
> >
> >> Index: Makefile
> >> ===
> >> RCS file: /work/cvsroot/ports/productivity/taskd/Makefile,v
> >> retrieving revision 1.5
> >> diff -p -u -r1.5 Makefile
> >> --- Makefile 28 Jan 2016 17:15:00 -  1.5
> >> +++ Makefile 8 Feb 2016 15:49:27 -
> >> @@ -4,6 +4,7 @@ COMMENT =lightweight server providing a
> >>
> >>  DISTNAME =  taskd-1.1.0
> >>  CATEGORIES =productivity net
> >> +REVISION =  0
> >>
> >>  HOMEPAGE =  http://www.taskwarrior.org/
> >>
> >> @@ -41,6 +42,8 @@ post-install:
> >>  ${PREFIX}/share/examples/taskd/pki/
> >>  ${INSTALL_DATA} ${WRKSRC}/pki/README \
> >>  ${PREFIX}/share/examples/taskd/pki/
> >> +${INSTALL_DATA} ${WRKSRC}/pki/vars \
> >> +${PREFIX}/share/examples/taskd/pki/vars.dist
> >>  ${SUBST_DATA} ${FILESDIR}/config \
> >>  ${PREFIX}/share/examples/taskd/config
> >>
> >> Index: pkg/PLIST
> >> ===
> >> RCS file: /work/cvsroot/ports/productivity/taskd/pkg/PLIST,v
> >> retrieving revision 1.3
> >> diff -p -u -r1.3 PLIST
> >> --- pkg/PLIST28 Jan 2016 17:15:05 -  1.3
> >> +++ pkg/PLIST8 Feb 2016 15:49:54 -
> >> @@ -35,6 +35,7 @@ share/examples/taskd/pki/generate.ca
> >>  share/examples/taskd/pki/generate.client
> >>  share/examples/taskd/pki/generate.crl
> >>  share/examples/taskd/pki/generate.server
> >> +share/examples/taskd/pki/vars.dist
> >>  @sample share/examples/taskd/pki/vars
> >>  share/taskd/
> >>  share/taskd/AUTHORS
>
> --
> Sent from a phone, please excuse the formatting.
>



-- 
viq

(py-)selenium continues...

[Jiri B]

Hi,

some comments about your (py-)selenium ports from June '15 [1]:

$ pkg_info -L py-selenium | grep .so$
/usr/local/lib/python2.7/site-packages/selenium/webdriver/firefox/amd64/x_ignore_nofocus.so
/usr/local/lib/python2.7/site-packages/selenium/webdriver/firefox/x86/x_ignore_nofocus.so

These are Linux libs.

I used to try to build the lib myself, not sure if still relevant and even
not sure if building that lib is correct:

--- /home/jirib/Downloads/py-selenium/Makefile  Mon Jun 22 22:02:43 2015
+++ MakefileSat Feb 13 22:42:13 2016
@ -10,6 +10,15 @@ CATEGORIES = www devel
 HOMEPAGE = http://www.seleniumhq.org/
 MAINTAINER =   frantisek holop 
 
+# XXX: clarify
+MASTER_SITES0 = 
http://selenium.googlecode.com/svn/tags/selenium-2.28.0/cpp/linux-specific/
+
+DIST_SUBDIR =  py-selenium
+EXTRACT_ONLY = ${DISTNAME}${EXTRACT_SUFX}
+DISTFILES =${DISTNAME}${EXTRACT_SUFX} \
+   print_events.h:0 \
+   x_ignore_nofocus.c:0
+
 MODPY_PI = Yes
 
 # Apache
@ -17,5 +26,23 @@ PERMIT_PACKAGE_CDROM =   Yes
 
 MODULES =  lang/python
 MODPY_SETUPTOOLS = Yes
+
+post-extract:
+   cp ${DISTDIR}/${DIST_SUBDIR}/*.[ch] \
+   ${WRKSRC}/
+   perl -i -pe 's,elf.h,libelf/libelf.h,' \
+   ${WRKSRC}/x_ignore_nofocus.c
+
+post-build:
+   cd ${WRKSRC} && \
+   ${CC} ${CFLAGS} -shared -fPIC -I${LOCALBASE}/include -L${LOCALBASE}/lib 
\
+   -I${X11BASE}/include -L${X11BASE}/lib \
+   -o x_ignore_nofocus.so x_ignore_nofocus.c -lelf
+
+post-install:
+   rm -rf ${DESTDIR}${MODPY_SITEPKG}/selenium/webdriver/firefox/{x86,amd64}
+   ${INSTALL_DATA_DIR} 
${DESTDIR}${MODPY_SITEPKG}/selenium/webdriver/firefox/${ARCH}/
+   ${INSTALL_DATA} ${WRKSRC}/x_ignore_nofocus.so \
+   ${DESTDIR}${MODPY_SITEPKG}/selenium/webdriver/firefox/${ARCH}/
 
 .include 

I still have problem to use both local Firefox. Using OpenBSD Firefox via
remote I still can't make it run with Xvfb. Any alternative? A VNC server?

I tried py-selenium with phantomjs and it works, but my test was very primitive
as I'm very beginner.

IMO rc script would be nice. One can put DISPLAY in setenv in login.conf
and have selenium working with a display (just theory). rc script would also
help to maintain multiple hub instances (symlinks)...

Thanks for working on (py-)selenium.

j.

[1] http://marc.info/?l=openbsd-ports=143500635028523=2

Re: (py-)selenium continues...

[Jiri B]

Plus, I don't see the point to have version in jar filename
for selenium port.

j.

Re: lang/gcc on macppc

[Michael McConville]

Have you guys had issues with wd(4) timeouts on macppc? It was happening
intermittently, but I figured it was because the drive was old. However,
I'm now experiencing it again with a brand new hard drive and it's
making the machine unusable.

Re: lang/gcc on macppc

[Michael McConville]

Michael McConville wrote:
> Have you guys had issues with wd(4) timeouts on macppc? It was
> happening intermittently, but I figured it was because the drive was
> old. However, I'm now experiencing it again with a brand new hard
> drive and it's making the machine unusable.

To clarify: this could be because of a worn out motherboard. I think
this machine was heavily used back in the day.

Re: lang/gcc on macppc

[Tobias Ulmer]

On Sat, Feb 13, 2016 at 07:10:06PM -0500, Michael McConville wrote:
> Michael McConville wrote:
> > Have you guys had issues with wd(4) timeouts on macppc? It was
> > happening intermittently, but I figured it was because the drive was
> > old. However, I'm now experiencing it again with a brand new hard
> > drive and it's making the machine unusable.
> 
> To clarify: this could be because of a worn out motherboard. I think
> this machine was heavily used back in the day.

I doubt it, it's much more likely you have a machine for which we miss
some small workaround. Apple hardware is buggy as hell.

Re: xlsx2csv broken

[Dmitrij D. Czarkoff]

Antoine Jacoutot said:
> I wouldn't call this particularly uncommon...
> You said that "This should never happen" -- ok but why, because it does; so 
> what would trigger a rebuild like this? I don't know the first thing about 
> the go build system.

Generally go tries to rebuild dependencies when they are not found.
I don't really understand why this detection produces such unpredictable
results with this port.  Interestingly, I can reliably reproduce the
issue when I install go-xlsx package from mirror.  When I build the
package, the issue is gone.  I'll try to find out during this weekend.

-- 
Dmitrij D. Czarkoff

devel/coccinelle failing

[Michael McConville]

IIUC, we use a bundled version of Menhir in Coccinelle. It exists as the
tarball bundles/menhirLib/menhir-20120123.tar.gz in the Coccinelle
codebase.

Here's the relevant Makefile line:

> CONFIGURE_ARGS +=   --disable-menhirLib # version in ports is too new

However, the build fails for me because it can't find the module
MenhirLib.IncrementalEngine. This seems related, but I'm not sure. It's
been failing for me for weeks; maybe the fact that no one else has
reported it means that it's something anomalous on my machine.

Has anyone else run into this? I have the Menhir package installed -
maybe that's what triggers it.


>>> Building on localhost under devel/coccinelle
 BDEPENDS = 
[lang/ocaml-camlp4;devel/gmake;devel/ocaml-pcre;devel/ocaml-parmap;textproc/latexmk;textproc/gdiff;sysutils/ggrep;lang/ocaml;sysutils/findlib;textproc/hevea;lang/python/2.7;print/texlive/texmf,-full;print/texlive/base]
 DIST = [devel/coccinelle:coccinelle-1.0.4.tgz]
 FULLPKGNAME = coccinelle-1.0.4
 RDEPENDS = 
[devel/ocaml-parmap;devel/ocaml-pcre;lang/python/2.7;lang/ocaml;sysutils/findlib;textproc/gdiff;sysutils/ggrep]
(Junk lock obtained for localhost at 1453032007)
>>> Running depends in devel/coccinelle at 1453032007
   last junk was in devel/sdl-sound
/usr/sbin/pkg_add -aI -Dunsigned -Drepair findlib-1.5.5 gdiff-3.3p0 ggrep-2.22 
hevea-2.23 latexmk-443ap0 ocaml-4.02.3 ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 
ocaml-pcre-7.1.5 texlive_base-2014p1 texlive_texmf-full-2014p0
was: /usr/sbin/pkg_add -aI -Dunsigned -Drepair findlib-1.5.5 gdiff-3.3p0 
ggrep-2.22 gmake-4.1p0 hevea-2.23 latexmk-443ap0 ocaml-4.02.3 
ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 ocaml-pcre-7.1.5 python-2.7.11 
texlive_base-2014p1 texlive_texmf-full-2014p0
/usr/sbin/pkg_add -aI -Dunsigned -Drepair findlib-1.5.5 gdiff-3.3p0 ggrep-2.22 
hevea-2.23 latexmk-443ap0 ocaml-4.02.3 ocaml-camlp4-4.02+6 ocaml-parmap-1.0rc7 
ocaml-pcre-7.1.5 texlive_base-2014p1 texlive_texmf-full-2014p0
--- +hevea-2.23 ---
The imagen script needs LaTeX, dvips, ghostscript and tools from netpbm.

Thus, Hevea does not require texlive, ghostscript, nor netpbm, but its
full functionality can only be achieved if you install those packages.
>>> Running show-prepare-results in devel/coccinelle at 1453032016
===> devel/coccinelle
===> coccinelle-1.0.4 depends on: ocaml-parmap-* -> ocaml-parmap-1.0rc7
===> coccinelle-1.0.4 depends on: ocaml-pcre-* -> ocaml-pcre-7.1.5
===> coccinelle-1.0.4 depends on: findlib-* -> findlib-1.5.5
===> coccinelle-1.0.4 depends on: ggrep-* -> ggrep-2.22
===> coccinelle-1.0.4 depends on: gdiff-* -> gdiff-3.3p0
===> coccinelle-1.0.4 depends on: ocaml-=4.02.3 -> ocaml-4.02.3
===> coccinelle-1.0.4 depends on: python->=2.7,<2.8 -> python-2.7.11
===> coccinelle-1.0.4 depends on: ocaml-camlp4-=4.02+6 -> ocaml-camlp4-4.02+6
===> coccinelle-1.0.4 depends on: texlive_base-* -> texlive_base-2014p1
===> coccinelle-1.0.4 depends on: texlive_texmf-full-* -> 
texlive_texmf-full-2014p0
===> coccinelle-1.0.4 depends on: hevea-* -> hevea-2.23
===> coccinelle-1.0.4 depends on: latexmk-* -> latexmk-443ap0
===> coccinelle-1.0.4 depends on: gmake-* -> gmake-4.1p0
===>  Verifying specs:  c curses m pthread util pcre python2.7
===>  found c.84.2 curses.14.0 m.9.0 pthread.20.1 util.12.1 pcre.3.0 
python2.7.0.0
findlib-1.5.5
gdiff-3.3p0
ggrep-2.22
gmake-4.1p0
hevea-2.23
latexmk-443ap0
ocaml-4.02.3
ocaml-camlp4-4.02+6
ocaml-parmap-1.0rc7
ocaml-pcre-7.1.5
python-2.7.11
texlive_base-2014p1
texlive_texmf-full-2014p0
Still tainted: 1
>>> Running junk in devel/coccinelle at 1453032019
Can't run junk because of lock on x11/qt5
(Junk lock released for localhost at 1453032019)
distfiles size=2484218
>>> Running patch in devel/coccinelle at 1453032019
===> devel/coccinelle
===>  Checking files for coccinelle-1.0.4
`/mnt/big/ports/distfiles/coccinelle-1.0.4.tgz' is up to date.
===>  Extracting for coccinelle-1.0.4
===>  Patching for coccinelle-1.0.4
>>> Running configure in devel/coccinelle at 1453032020
===> devel/coccinelle
===>  Configuring for coccinelle-1.0.4
Using /home/dpb-wrk/coccinelle-1.0.4/config.site (generated)
perl -pi -e s,/usr/local,/usr/local,g 
/home/dpb-wrk/coccinelle-1.0.4/coccinelle-1.0.4/scripts/spatch*
configure: WARNING: unrecognized options: --disable-gtk-doc
configure: loading site script /home/dpb-wrk/coccinelle-1.0.4/config.site
configure: configuring coccinelle 1.0.4 in 
/home/dpb-wrk/coccinelle-1.0.4/coccinelle-1.0.4
checking for a BSD-compatible install... 
/home/dpb-wrk/coccinelle-1.0.4/bin/install -c 
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... mkdir -p
checking for gawk... (cached) awk
checking whether gmake sets $(MAKE)... yes
checking whether gmake supports nested variables... yes
configure: determining version suffix
checking for date... /bin/date
configure: version suffix set to Sun, 17 Jan 2016 07:00:21 -0500
configure: this configure program uses pkg-config m4 macros

Re: is hedgewars broken?

[Antoine Jacoutot]

> I don't see any way how and why this can fail for antoine, given
> that he has dataenc installed and ghc-pkg seems to be happy about
> it. Except that it may be the same mysterious bug antoine sees from
> time to time with haskell ports (ghc exiting with an exit code !=
> 0 but without any useful error message).

Let's just get over it and blame NFS ;-)

-- 
Antoine

Re: xlsx2csv broken

[Antoine Jacoutot]

On Sun, Feb 14, 2016 at 01:22:00AM +0100, Dmitrij D. Czarkoff wrote:
> Antoine Jacoutot said:
> > I wouldn't call this particularly uncommon...
> > You said that "This should never happen" -- ok but why, because it does; so 
> > what would trigger a rebuild like this? I don't know the first thing about 
> > the go build system.
> 
> Generally go tries to rebuild dependencies when they are not found.
> I don't really understand why this detection produces such unpredictable
> results with this port.  Interestingly, I can reliably reproduce the
> issue when I install go-xlsx package from mirror.  When I build the
> package, the issue is gone.  I'll try to find out during this weekend.

Great, thanks.

-- 
Antoine

Re: alpha-1.ports.openbsd.org bulk build report

[Jonathan Gray]

On Sat, Feb 13, 2016 at 07:17:35PM +0100, Matthieu Herrb wrote:
> So, here is a patch that should let libGL to build again on
> alpha. I've not done a full clean xenocara build with it yet though,
> given how slow my alpha is.
> 
> In addition to the non-existent sync operation, I had to force 2 files
> to build with -O0.
> 
> There is a lot of Makefile.in churn since I did some autotools
> hackery...

Any idea which of the -O1 options triggers it?

According to gcc(1):

-O turns on the following optimization flags: -fdefer-pop
-fdelayed-branch -fguess-branch-probability -fcprop-registers
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants

So alpha is in the same situation mips64 was then?

Going by /sys/arch/alpha/include/atomic.h there are atomics,
which sync builtins does gcc not implement on alpha?