CVS: cvs.openbsd.org: ports
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
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?
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
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
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
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, viqwrote: >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?
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?
> 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
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
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
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
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
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
On Sat, Feb 13, 2016 at 8:17 PM, Stuart Hendersonwrote: > 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...
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...
Plus, I don't see the point to have version in jar filename for selenium port. j.
Re: lang/gcc on macppc
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 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
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
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
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?
> 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
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
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?