Re: Java Development Kit and Icedtea

[Stuart Henderson]

On 2013/08/21 22:15, Pascal Stumpf wrote:
> On Wed, 21 Aug 2013 13:47:03 -0500, eagir...@cox.net wrote:
> > Having installed the 64 bit time snapshots (amd64), I have reinstalled 
> > packages. Except that the jdks used to have packages, and don't. Will they 
> > be coming back? Can't build a new icedtea plugin without them
> 
> Yes, they will be back as soon as they have been re-bootstrapped for
> 64bit time_t.

It's likely to be more than just a bootstrap problem - at least there are
no "bad system call" messages with T32 but the internal self-tests in the
build fail (and if you patch away the tests, other things fail later)...

Anyone who has ideas about how to fix it, feel free to send a mail ;)

Re: cmake diff to disable elf parser and ninja (Was: arm port build failures)

[Stuart Henderson]

On 2013/08/21 15:03, Stuart Henderson wrote:
> On 2013/08/21 15:30, David Coppa wrote:
> > On Tue, 20 Aug 2013, Stuart Henderson wrote:
> > 
> > > On 2013/08/20 08:25, Stuart Henderson wrote:
> > > > On 2013/08/20 08:50, David Coppa wrote:
> > > > > On Mon, Aug 19, 2013 at 11:50 PM, Stuart Henderson 
> > > > >  wrote:
> > > > > 
> > > > > > these ones all use cmake which has a common segfault on arm since
> > > > > > the move to enabling the elf parser.
> > 
> > Comments on the following diff?
> 
> In the absence of any better ideas, this makes sense to me, I'll give it a 
> try.

yep, that works.

> > #0  cmELF (this=0xbfff4674, fname=0x4337438c "/usr/lib/libz.so.4.1")
> > at basic_ios.h:124
> > 124   { return _M_streambuf_state; }
> 
> I get the impression this is something which shouldn't be segfaulting though..

as a workaround: OK.

Re: Java Development Kit and Icedtea

[Stuart Henderson]

On 2013/08/21 15:21, patrick keshishian wrote:
> On 8/21/13, Stuart Henderson  wrote:
> > On 2013/08/21 22:15, Pascal Stumpf wrote:
> >> On Wed, 21 Aug 2013 13:47:03 -0500, eagir...@cox.net wrote:
> >> > Having installed the 64 bit time snapshots (amd64), I have reinstalled
> >> > packages. Except that the jdks used to have packages, and don't. Will
> >> > they be coming back? Can't build a new icedtea plugin without them
> >>
> >> Yes, they will be back as soon as they have been re-bootstrapped for
> >> 64bit time_t.
> >
> > It's likely to be more than just a bootstrap problem - at least there are
> > no "bad system call" messages with T32 but the internal self-tests in the
> > build fail (and if you patch away the tests, other things fail later)...
> >
> > Anyone who has ideas about how to fix it, feel free to send a mail ;)
> 
> rm comes to mind ...
> 

can't, I need railo. the alternative is worse ;)

Re: UPDATE: sysutils/ranger-1.6.1

[Stuart Henderson]

On 2013/08/10 00:07, Kyle Merchant wrote:
> Hi ports,
> 
> Below is a patch to bring ranger to the latest version.  Update includes
> a BSD-friendly setsid implementation, overhauled config files, and
> numerous other fixes and feature additions. Please note config files
> need to be updated or use the --clean switch.
> 
> Tested on amd64. OKs and/or comments?

> -# libarchive (bsdtar) used as an alternative to atool; see scope.sh patch
> +# libarchive (bsdtar) used as an alternative to atool

please restore this comment; it directs people to the patch file where this is 
done.

> +share/doc/ranger/config/
> +share/doc/ranger/config/colorschemes/
> +share/doc/ranger/config/colorschemes/default.py
> +share/doc/ranger/config/colorschemes/jungle.py
> +share/doc/ranger/config/colorschemes/snow.py
> +share/doc/ranger/config/commands.py
> +share/doc/ranger/config/rc.conf
> +share/doc/ranger/config/rifle.conf
> +share/doc/ranger/config/scope.sh
> +share/doc/ranger/examples/
> +share/doc/ranger/examples/README
> +share/doc/ranger/examples/bash_automatic_cd.sh
> +share/doc/ranger/examples/bash_subshell_notice.sh
> +share/doc/ranger/examples/plugin_chmod_keybindings.py
> +share/doc/ranger/examples/plugin_file_filter.py
> +share/doc/ranger/examples/plugin_hello_world.py
> +share/doc/ranger/examples/plugin_new_macro.py
> +share/doc/ranger/examples/plugin_new_sorting_method.py
> +share/doc/ranger/examples/rifle_different_file_opener.conf
> +share/doc/ranger/examples/rifle_sxiv.sh
> +share/doc/ranger/examples/vim_file_chooser.vim
> +share/doc/ranger/tools/
> +share/doc/ranger/tools/print_colors.py
> +share/doc/ranger/tools/print_keys.py

the standard location for sample files etc. is share/examples.

Re: Exim problem after OpenBSD time_t 64bit change

[Stuart Henderson]

On 2013/08/22 10:39, Renaud Allard wrote:
> Hello,
> 
> I upgraded one of my machines to OpenBSD 5.4-current containing the
> 64bits time_t change. And I noticed that exim was giving a 4XX error
> to every mail because it was too busy. So I commented
> smtp_load_reserve in the configuration file and it now works just
> fine. So it seems this parameter is not interpreted correctly after
> the time_t change.

I don't use Exim but I gave this a quick go, I can't repeat it here.
I'm on amd64 using the default /etc/exim/configure file with just the
line "smtp_load_reserve = 50" added.

Which arch?

Anything in exim's logs?

Any more info if you do debug logging in exim? (-d option to run in foreground).

Was your load actually above the value you had configured anyway?

update: mail/exim

[Stuart Henderson]

I've had this sitting in my tree for a while.. OK?

Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.93
diff -u -p -r1.93 Makefile
--- Makefile12 Jun 2013 20:36:33 -  1.93
+++ Makefile22 Aug 2013 17:09:25 -
@@ -3,8 +3,7 @@
 CATEGORIES =   mail
 COMMENT-main = flexible mail transfer agent
 COMMENT-eximon =   X11 monitor tool for Exim MTA
-VERSION =  4.77
-REVISION = 4
+VERSION =  4.80.1
 DISTNAME = exim-${VERSION}
 PKGNAME-main = exim-${VERSION}
 FULLPKGNAME-eximon =   exim-eximon-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/mail/exim/distinfo,v
retrieving revision 1.21
diff -u -p -r1.21 distinfo
--- distinfo19 Oct 2011 23:06:57 -  1.21
+++ distinfo22 Aug 2013 17:09:25 -
@@ -1,5 +1,2 @@
-MD5 (exim-4.77.tar.gz) = 3B8p9odVbw8OmPveGfmO9A==
-RMD160 (exim-4.77.tar.gz) = 6/kbDf+blCKW24umVAhj5qFROtY=
-SHA1 (exim-4.77.tar.gz) = LBumuPYntxs7WPwMxW45RZDc0dw=
-SHA256 (exim-4.77.tar.gz) = FkmActgsdNKf6eCctG+QYN4b0MtXIczAcZkK9hLumjw=
-SIZE (exim-4.77.tar.gz) = 2035914
+SHA256 (exim-4.80.1.tar.gz) = LKwFziel1bQJzlZXlXBHIz02+TltAgPSQKW3rtKpad4=
+SIZE (exim-4.80.1.tar.gz) = 2107974
Index: files/Makefile
===
RCS file: /cvs/ports/mail/exim/files/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- files/Makefile  19 Oct 2011 23:06:57 -  1.15
+++ files/Makefile  22 Aug 2013 17:09:25 -
@@ -248,11 +248,19 @@ SUPPORT_MBX=yes
 
 #--
 # See below for dynamic lookup modules.
-# LOOKUP_MODULE_DIR=/usr/lib/exim/lookups/
+#
 # If not using package management but using this anyway, then think about how
 # you perform upgrades and revert them. You should consider the benefit of
 # embedding the Exim version number into LOOKUP_MODULE_DIR, so that you can
 # maintain two concurrent sets of modules.
+# 
+# *BEWARE*: ability to modify the files in LOOKUP_MODULE_DIR is equivalent to
+# the ability to modify the Exim binary, which is often setuid root!  The Exim
+# developers only intend this functionality be used by OS software packagers
+# and we suggest that such packagings' integrity checks should be paranoid
+# about the permissions of the directory and the files within.
+
+# LOOKUP_MODULE_DIR=/usr/lib/exim/lookups/
 
 # To build a module dynamically, you'll need to define CFLAGS_DYNAMIC for
 # your platform.  Eg:
@@ -279,6 +287,10 @@ SUPPORT_MBX=yes
 # the dynamic library and not the exim binary will be linked against the
 # library.
 # NOTE: LDAP cannot be built as a module!
+#
+# If your system has pkg-config then the _INCLUDE/_LIBS setting can be
+# handled for you automatically by also defining the _PC variable to reference
+# the name of the pkg-config package, if such is available.
 
 LOOKUP_DBM=yes
 LOOKUP_LSEARCH=yes
@@ -295,6 +307,7 @@ LOOKUP_NIS=yes
 LOOKUP_PASSWD=yes
 # LOOKUP_PGSQL=yes
 # LOOKUP_SQLITE=yes
+# LOOKUP_SQLITE_PC=sqlite3
 # LOOKUP_WHOSON=yes
 
 # These two settings are obsolete; all three lookups are compiled when
@@ -329,9 +342,12 @@ LOOKUP_PASSWD=yes
 # In either case you must specify the library link info here.  If the
 # PCRE header files are not in the standard search path you must also
 # modify the INCLUDE path (above)
-# The default setting of PCRE_LIBS should work on the vast majority of
-# systems
+#
+# Use PCRE_CONFIG to query the pcre-config command (first found in $PATH)
+# to find the include files and libraries, else use PCRE_LIBS and set INCLUDE
+# too if needed.
 
+PCRE_CONFIG=yes
 PCRE_LIBS=-lpcre
 
 
@@ -342,6 +358,8 @@ PCRE_LIBS=-lpcre
 # don't need to set LOOKUP_INCLUDE if the relevant directories are already
 # specified in INCLUDE. The settings below are just examples; -lpq is for
 # PostgreSQL, -lgds is for Interbase, -lsqlite3 is for SQLite.
+#
+# You do not need to use this for any lookup information added via pkg-config.
 
 # LOOKUP_INCLUDE=-I /usr/local/ldap/include -I /usr/local/mysql/include -I 
/usr/local/pgsql/include
 # LOOKUP_LIBS=-L/usr/local/lib -lldap -llber -lmysqlclient -lpq -lgds -lsqlite3
@@ -398,6 +416,11 @@ WITH_OLD_DEMIME=yes
 # experimental-spec.txt. "Experimental" means that the way these features are
 # implemented may still change. Backward compatibility is not guaranteed.
 
+# Uncomment the following line to add support for talking to dccifd.  This
+# defaults the socket path to /usr/local/dcc/var/dccifd.
+
+# EXPERIMENTAL_DCC=yes
+
 # Uncomment the following lines to add SPF support. You need to have libspf2
 # installed on your system (www.libspf2.org). Depending on where it is 
installed
 # you may have to edit the CFLAGS and LDFLAGS lines.
@@ -424,6 +447,11 @@ WITH_OLD_DEMIME=yes
 # CFLAGS  += -I/opt/brightma

Re: Exim problem after OpenBSD time_t 64bit change

[Stuart Henderson]

On 2013/08/22 12:01, Landry Breuil wrote:
> On Thu, Aug 22, 2013 at 10:39:54AM +0200, Renaud Allard wrote:
> > Hello,
> > 
> > I upgraded one of my machines to OpenBSD 5.4-current containing the
> > 64bits time_t change. And I noticed that exim was giving a 4XX error
> > to every mail because it was too busy. So I commented
> > smtp_load_reserve in the configuration file and it now works just
> > fine. So it seems this parameter is not interpreted correctly after
> > the time_t change.
> 
> LOTS of ports will have runtime issues after the time_t bump, and will
> require manual fiddling to remove/purge caches, reset indexes, reindex
> databases, etc...
> 
> - mutt header caches
> - dovecot indexes
> - etc

Mutt is OK as of the current port (mutt-1.5.21p4v0).

I have not had any problems with Dovecot using mdbox on amd64 over the
64-bit time_t bump - do not zap your indexes/caches blindly especially for
the dbox formats. If anyone does run into problems with Dovecot please give
full information, I think it highly likely that upstream would treat it
as a bug if this did happen.

Also not had problems with MySQL. I would be interested to hear if anyone
takes an openldap box over the bump to find whether or not that works OK :)

Re: UPDATE: textproc/py-feedparser 5.0.1 => 5.1.3

[Stuart Henderson]

On 2013/08/24 10:31, Brian Callahan wrote:
> Is no one using this?

Ah, I forgot that rss2email uses this, that still works. (hint: for libraries,
people are more likely to notice that they use it if you mention the ports which
depend on it ;)

OK as far as I'm concerned.

Re: time_t and nmap

[Stuart Henderson]

On 2013/08/25 09:46, Florian Stinglmayr wrote:
> Hi,
> 
> I just compiled nmap from ports and it always gives the following
> error:
> 
> Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-25 09:45 CEST
> assertion "diff <= interval" failed: file "timing.cc", line 408, function 
> "update"
> Abort trap
> 
> I supppose it has something to do with the time_t change?
> 
> Regards,
> Florian
> 

nmap was already partly broken on OpenBSD due to bad conversions
between timeval and bpf_timeval, the time_t switch has made it worse.

http://marc.info/?l=openbsd-ports&m=136930349508697&w=2

Re: NEW: mail/spamd-setup-downloader

[Stuart Henderson]

On 2013/08/27 11:42, Craig R. Skinner wrote:
> ping

- don't distribute source files in ports
- don't use NO_CHECKSUM
- too many PERMIT_* lines
- don't have a MESSAGE just pointing people at the readme, pkg_add
already points people at the readme
- this is, err, not normal:

@echo '@mode ${SHAREMODE}\n@group ${SHAREGRP}' >> ${PLIST}
@echo 'share/doc/pkg-readmes/${FULLPKGNAME}' | tee -a ${PLIST}
@${SUBST_CMD} -c -g ${BINGRP} -o ${BINOWN} \
${FILESDIR}/${INST_DIR}/${DISTNAME} \
${PREFIX}/${INST_DIR}/${DISTNAME}
@echo '@mode ${BINMODE}\n@owner ${BINOWN}\n@group ${BINGRP}' | tee -a 
${PLIST}
@echo "${INST_DIR}/${DISTNAME}" | tee -a ${PLIST}

- your local rcs history is pointless to include in the port
- script itself has security issues

Re: NEW: mail/spamd-setup-downloader

[Stuart Henderson]

On 2013/08/28 11:32, Craig R. Skinner wrote:
> On 2013-08-28 Wed 08:44 AM |, Stuart Henderson wrote:
> > 
> > - don't distribute source files in ports
> > - your local rcs history is pointless to include in the port
> 
> I done this because I thought it was OK to include small files:

Not really, ports-internal things like sqlports are OK to put there
but that's pretty much it. There were one or two others in the past but
I think they've been moved to proper distfiles now.

> I also want to give the code away and make it easy for others to improve.

github etc.?

> > - this is, err, not normal:
> > 
> > @echo '@mode ${SHAREMODE}\n@group ${SHAREGRP}' >> ${PLIST}
> > @echo 'share/doc/pkg-readmes/${FULLPKGNAME}' | tee -a ${PLIST}
> > @${SUBST_CMD} -c -g ${BINGRP} -o ${BINOWN} \
> > ${FILESDIR}/${INST_DIR}/${DISTNAME} \
> > ${PREFIX}/${INST_DIR}/${DISTNAME}
> > @echo '@mode ${BINMODE}\n@owner ${BINOWN}\n@group ${BINGRP}' | tee 
> > -a ${PLIST}
> > @echo "${INST_DIR}/${DISTNAME}" | tee -a ${PLIST}
> > 
> 
> PLIST generation.

"make plist" and tweak the results as needed like other ports do.
a port shouldn't be touching files in the ports tree itself during
build, and in this case it won't even work (you keep appending to
the file each time it's run).

> > - script itself has security issues
> > 
> 
> Thanks for the feedback Stuart.
> 
> Pointers about security appreciated.
> 

>From a quick look at the script (I'm only using spamd as a classic
tarpit on a low priority MX rather than anything else so I'm not
interesting in using it myself..) there are various uses of
fixed/predictable names for tempfiles in shared directories,
which is unsafe. It's a well known problem so there's plenty of
advice e.g.

https://www.securecoding.cert.org/confluence/display/seccode/FIO43-C.+Do+not+create+temporary+files+in+shared+directories

(note, predictable names includes using $$, use mktemp with a decent
number of X's, say 10+, instead)

... retrieved=$(print ${url} | sed 's/[`¬¦!"$%^&*()+=:;@~#\|?/<>,]/_/g')

Keep known-good characters, rather than try and strip out bad
characters. A hash of the URL might be more appropriate.

Re: NEW: mail/spamd-setup-downloader

[Stuart Henderson]

On 2013/08/28 14:50, Craig R. Skinner wrote:
> It's part of the deliberate design concept to use predictable names as
> the tool caches blacklists. If during the next run there are temporary
> networking errors, the currently running instance can reuse previously
> cached data.

If that's the case, they should go in a private directory which
is not world-writable, something under /var/db would be appropriate.

> As the blacklists are (mostly) publicly available, I thought /var/tmp
> was sufficient.

Then I think you miss the point of the problem with predictable filenames.
Consider the scenario where an attacker creates a link pointing at
some file he would like to be overwritten..

> The locks also need to have predictable names as each time spamd-setup
> is run by cron, it exec's a new instance for each blacklist. There is no
> persistent process to use any IPC.
> 
> After reading the CERT URL, I realise an attacker might be able to alter
> the blacklists OK. I could default to using /var/[spool/]${DISTNAME}
> for everything, and also check for stale files internally, rather than
> rely on daily(8).

For locks, ports/sysutils/flock is very useful.

> Quick question;- should tools log in /var/log, or their own sub dir
> (e.g. apache, squid)? I chose to append failed $(mktemp) logs to
> /var/tmp/${DISTNAME}.log as any transient networking errors are
> inconsequential after a couple of days, by which time daily(8) will have
> deleted the log. A newsyslog(8) entry seemed OTT for a seldom used log.

syslog (via logger(1)) is good for 1-line status information, as it's run
from cron then maybe output errors/more information to stdout or stderr,
people can decide whether or not to redirect it (in which case, it's
probably best if a successful run is silent).

> > ... retrieved=$(print ${url} | sed 's/[`??!"$%^&*()+=:;@~#\|?/<>,]/_/g')
> > 
> > Keep known-good characters, rather than try and strip out bad
> > characters. A hash of the URL might be more appropriate.
> > 
> 
> OK. I done it that way to make the cache human readable for any manual
> administration:
> 
> $ ls /var/tmp/spamd-setup-downloader
> psbl-mirror.surriel.com__psbl_psbl.txt
> rsync-mirrors.uceprotect.net__RBLDNSD-ALL_dnsbl-1.uceprotect.net
> www.bsdly.net__peter_bsdly.net.traplist
> www.bsdly.net__peter_bsdly.net.traplist~
> www.openbsd.org_spamd_nixspam
> www.openbsd.org_spamd_nixspam.gz
> www.openbsd.org_spamd_nixspam.gz~
> www.openbsd.org_spamd_traplist
> www.openbsd.org_spamd_traplist.gz
> www.openbsd.org_spamd_traplist.gz~

If you're not too concerned about multiple URLs getting squashed to the
same string, you could do something like "tr -c '[a-zA-Z0-9,.]' _"

Re: devel/json-c on gcc3

[Stuart Henderson]

On 2013/08/29 16:12, Martin Reindl wrote:
> Below is a diff which let's devel/json-c build on gcc3 archs.
> On gcc4, -Wextra and -W is the same.
> OK?

OK. (The REVISION bump is probably not needed as this shouldn't change
compilation results, but doesn't hurt).



> martin
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/json-c/Makefile,v
> retrieving revision 1.8
> diff -u -p -u -p -r1.8 Makefile
> --- Makefile  7 Aug 2013 15:37:09 -   1.8
> +++ Makefile  29 Aug 2013 14:03:01 -
> @@ -3,6 +3,7 @@
>  COMMENT= JSON implementation in C
>  
>  DISTNAME =   json-c-0.11
> +REVISION=0
>  CATEGORIES=  devel
>  SHARED_LIBS +=  json  2.0 # 1.0
>  SHARED_LIBS +=  json-c0.0 # 2.1
> --- /dev/null Thu Aug 29 16:03:51 2013
> +++ patches/patch-Makefile_in Thu Aug 29 15:24:13 2013
> @@ -0,0 +1,11 @@
> +--- Makefile.in.orig Sun Aug  4 10:11:43 2013
>  Makefile.in  Sun Aug  4 10:12:03 2013
> +@@ -274,7 +274,7 @@ target_alias = @target_alias@
> + top_build_prefix = @top_build_prefix@
> + top_builddir = @top_builddir@
> + top_srcdir = @top_srcdir@
> +-AM_CFLAGS = -Wall -Werror -Wextra -Wwrite-strings -Wno-unused-parameter 
> -std=gnu99 -D_GNU_SOURCE -D_REENTRANT
> ++AM_CFLAGS = -Wall -Werror -W -Wwrite-strings -Wno-unused-parameter 
> -std=gnu99 -D_GNU_SOURCE -D_REENTRANT
> + EXTRA_DIST = README.html README-WIN32.html config.h.win32 doc json-c.vcproj
> + SUBDIRS = . tests
> + lib_LTLIBRARIES = libjson-c.la $(am__append_1)
> 

Re: rss2email improvements

[Stuart Henderson]

On 2013/08/29 15:42, J. Lewis Muir wrote:
> Hello.
> 
> I was looking at the rss2email port at
> 
>   http://www.openbsd.org/cgi-bin/cvsweb/ports/mail/rss2email
> 
> and noticed a few things:
> 
> 1. The Makefile refers to version 2.70, but the latest version of
>rss2email is 2.71.  (I know, a port can't always be on the latest
>version, but since this was just added two months ago, it seems nice
>if it could start out on the latest version.)

Actually the latest version is 3.5, https://pypi.python.org/pypi/rss2email/
but it needs a bit more work, including tweaks to the libraries it uses
so they are built for python3.

> 2. The Makefile has:
> 
>  SUBST_VARS+=  MODPY_SITEPKG
> 
>but files/r2e contains two variables: MODPY_BIN and MODPY_SITEPKG.  I
>don't know a lot about OpenBSD ports, but wouldn't you need to list
>MODPY_BIN in SUBST_VARS in the Makefile for it to get substituted
>correctly when installing files/r2e?

Adding this is handled by the python module, see port-modules(5)

$ make show=SUBST_VARS
MODPY_PYCACHE MODPY_COMMENT MODPY_PYC_MAGIC_TAG MODPY_BIN MODPY_EGG_VERSION 
MODPY_VERSION MODPY_BIN_SUFFIX MODPY_PY_PREFIX MODPY_SITEPKG MACHINE_ARCH ARCH 
HOMEPAGE ^PREFIX ^SYSCONFDIR FLAVOR_EXT  FULLPKGNAME MAINTAINER ^BASE_PKGPATH 
^LOCALBASE ^X11BASE ^TRUEPREFIX  ^RCDIR

> 3. In files/r2e, the last argument of the exec is
> 
>  $*
> 
>but normally the correct thing to use is
> 
>  "$@"
> 
>which will preserve spaces in an argument and not split such an
>argument into multiple arguments.

I don't think it makes a lot of difference in this case (afaict it
would only cause a problem if you use opmlimport with a filename
containing spaces) though it does make sense to fix this next time
the port is updated.

> Thanks,
> 
> Lewis
> 

Re: fvwm2 on current

[Stuart Henderson]

On 2013/08/30 11:08, James Griffin wrote:
> I was just wondering if the Window Manager fvwm2 has been or is able to
> be used on the current snapshots post August 12, i.e. after the time_t
> changes. I tried it on a snapshot back on August 12/14 (something like
> that) and it crashed the X server. I haven't attempted it since. 
> 
> Would anyone happen to know if there is a problem with this particular
> Window Manager on the current snapshots?

There hasn't been anything mentioned here yet, so it's probably not
known. Logs would be useful. Backtraces might be even better (if you
have X source installed, see /usr/xenocara/README's "How to get a
core file..." section).

Re: Incoherent default rcscript and user for pure-ftpd?

[Stuart Henderson]

On 2013/08/30 14:22, Brad Smith wrote:
> On 26/08/13 10:17 AM, Donovan Watteau wrote:
> >Hello,
> >
> >net/pure-ftpd creates the following user and group:
> >@newgroup _pure-ftpd:642
> >@newuser _pure-ftpd:642:_pure-ftpd:daemon:pure-ftpd 
> >user:/nonexistent:/sbin/nologin
> >
> >but then, /etc/rc.d/pure_ftpd has:
> >daemon_flags="-A -B -H -u1000"
> >
> >so, with this default configuration, users below 1000 can't log in.
> >
> >Hence, if I create a user this way:
> ># pure-pw useradd myuser -u _pure-ftpd -d /whatever
> ># pure-pw mkdb
> >
> >I can't log in with it ("account disabled"), unless I use something
> >like "-u600".
> >
> >Am I missing something about the purpose of the _pure-ftpd user here,
> >or should the -u parameter in daemon_flags be lowered by default in the
> >provided package?
> 
> I'm looking back at this and to be honest I don't even know why the
> port creates the user/group. I understand why the rc script is the
> way it is.
> 
> Stuart, do you remember why the user / group was added?

This user/group is used for privilege separation, see the section from the
README I've pasted below.

$ ps wwaxu|grep pure
root 13008  0.0  0.0   608  1340 ??  Ss 8:01PM0:00.01 pure-ftpd: 
-pure-ftpd (SERVER) (pure-ftpd)
_pure-ftpd 20890  0.0  0.0   624  1204 ??  S  8:02PM0:00.00 pure-ftpd: 
-pure-ftpd (PRIV) (pure-ftpd)
ftp  24033  0.0  0.0   620  1432 ??  S  8:02PM0:00.07 pure-ftpd: 
-pure-ftpd (IDLE) (pure-ftpd)

I use a separate account with uid >=1000 as a file owner for anonymous
ftp or as account owner for virtual users.



...snip...

 PRIVILEGE SEPARATION 


When privilege separation is enabled, each session will spawn two processes :
a "privileged" process running as root, but that can only do very basic
and trusted actions (binding a port and remove the ftpwho scoreboard) and
the "client" process. The "client" process definitely revokes all privileges
after authentication and chroot() and punctually communicates with the
parent over a private channel.

Privilege separation decreases performance of loaded servers, but it
increases security and reliability. Enabling it is recommended.

Re: NEW net/ipv6-toolkit

[Stuart Henderson]

On 2013/08/30 22:56, Stefan Sperling wrote:
> On Fri, Aug 30, 2013 at 10:32:45PM +0200, Alexander Bluhm wrote:
> > Hi,
> > 
> > I would like to add Fernado Gont's IPv6 toolkit to our ports tree.
> > 
> > The SI6 Networks' IPv6 toolkit is a set of IPv6 security/trouble-shooting
> > tools, that can send arbitrary IPv6-based packets.
> > 
> > ok?
> > 
> > bluhm
> 
> OK by me. These tools look quite useful.

OK for me too.

> There are plenty of random() warnings in the build.
> Do you think it's worth fixing them and pushing patches upstream,
> making these tools use arc4random() if available?

if we're talking about pushing arc4random patches upstream (which might
be on the cards for various ports with the APIWARN for random() and
friends) I wonder if it might be a good time to consider alternative
(non-cipher-specific) function names, otherwise I suspect we are going
to get pointed at the libottery faq quite often..

i386 ports build failures

[Stuart Henderson]

graphics/pecl-imagick,
multimedia/ffmpeg-php,
www/pecl-phar,
www/pecl-swish: broken by php update

lang/sbcl: build hangs, see
http://rhaalovely.net/build-failures/i386/20130828/lang/sbcl.log

lang/smlnj: segfault during build
http://rhaalovely.net/build-failures/i386/20130828/lang/smlnj.log

productivity/taskjuggler: broken by 64-bit time_t, not a bootstrap issue
http://rhaalovely.net/build-failures/i386/20130828/productivity/taskjuggler.log

math/yorick: built this time, but there is a very common intermittent failure
where there are lots of undefined references, compare
http://junkpile.org/yorick-built.log with
http://rhaalovely.net/build-failures/i386/20130817/math/yorick.log

Re: UPDATE: misc/dvtm

[Stuart Henderson]

On 2013/08/28 11:33, Dennis Herrmann wrote:
> Ahoi,
> 
> For a long time i send a update for misc/dvtm. This is a new patch[1]
> without ugly
> snprintf patches or etc.
> 
> # $Id: UPDATE,v 1.3 2013/08/28 11:10:04 dhn Exp $
> 
> 2013-08-28 Dennis Herrmann 
> 
>  * Update to 0.9
>  * Update/Remove some patches
>- Update: patches/patch-vt_c
>- Remove: patches/patch-dvtm_c

I also had to remove patch-madtty_c, but I hit this:

vt.c: In function 'vt_draw':
vt.c:1528: warning: implicit declaration of function 'waddnwstr'

this looks like it might be a problem for LP64 arch as a couple of
the parameters are pointers, but the header appears to be correctly
included, so I'm not quite sure what's going on there..

Re: PATCH: fix security/libnettle on arm

[Stuart Henderson]

On 2013/09/03 02:09, Juan Francisco Cantero Hurtado wrote:
> Patch tested on amd64 and arm. All tests passed.

> +# A lot of errors in the compilation of memxor.s
> +.if ${MACHINE_ARCH} == "arm"
> +CONFIGURE_ARGS += --disable-assembler
> +.endif

Maybe "binutils 2.15 can't handle memxor.s" in the comment?

> The ggdb3 patch is unrelated to arm errors.

Bump needed for this one.

Re: devel/mercurial: make hgk work out of the box

[Stuart Henderson]

On 2013/09/03 17:05, Edd Barrett wrote:
> On Sat, Aug 31, 2013 at 06:00:42PM +0100, Edd Barrett wrote:
> > Hi,
> > 
> > The following diff makes hgk work out of the box without having to add a
> > custom path in the hgrc. Also, while we are here, adjust python script
> > shebangs.
> 
> This is a revised diff which adds a multipackage containing hgk. This
> works in much the same way as the git-x11 package. This avoids the
> ambiguous/questionable README that I proposed previously.
> 
> Aja, this is the diff you have already seen, but generated from cvs this
> time.
> 
> OK?

You need an @pkgpath marker in PLIST-main as well, otherwise it will
not be considered as a suitable update for devel/mercurial.
Rest looks good.

Re: UPDATE: OpenCV 2.4.6.1

[Stuart Henderson]

On 2013/09/03 03:54, Vadim Zhukov wrote:
> (Disclaimer: I thought that I sent similar mail a while ago, but it
> stuck in smtpd queue due to configuration problems; I'm sorry)
> 
> So the consensus is:
> 
>   * No "nonfree" FLAVOR;
>   * PERMIT_PACKAGES_CDROM=patents, PERMIT_PACKAGES_FTP=Yes.
> 
> Right? Here is an update with those changes. It also pre-compiles
> the Python module OpenCV installs.
> 
> sthen@, Rafael - okay?

Reading through this diff I don't see any problems, but I haven't
built it and have no idea how to test it.

Re: fix scons soname behaviour

[Stuart Henderson]

On 2013/09/05 14:43, Stefan Sperling wrote:
> On Wed, Sep 04, 2013 at 02:50:44PM -0400, Brad Smith wrote:
> > The soname command line parameter should just be removed on the line
> > below what is being modified.
> 
> That would likely make it work. But I don't think we could push
> such a patch upstream.

Hmm, why not? Obviously it would need to be conditional on OS but that
is just the way things are usually done on OpenBSD. Other tools doing
a similar(ish) job like libtool and cmake are setup that way.

Re: [NEW] Terminology-0.3.0

[Stuart Henderson]

On 2013/09/09 13:04, Brian Callahan wrote:
> On 9/9/2013 12:51 PM, Azwaw OUSADOU wrote:
> >Hi !
> >
> >I ported terminology, the terminal emulator supported by e17.
> >
> >Tested with an amd64
> >
> >Please test it !
> >Thanks
> >
> 
> Really quick untested eyeball:
> * You only need PERMIT_PACKAGE_CDROM=Yes
> * Missing PLIST goo

To be more specific this needs the update-desktop-database markers that
you'll see in many other ports. Add them in the same place in PLIST as
is normally done.

> * That DESCR is huge. You definitely don't need "Extract from
> website" and probably a lot of that other stuff too.

Suggested alternative:

Terminology is an X11 terminal, emulating a slightly extended vt100
supporting most xterm/rxvt additions. It was written for Enlightenment,
but can be used with other desktop environments. Features include
address detection, transparency, backgrounds, themes, multiple tabs,
and support for inline display of various media by using helper apps.

Other things:

- inconsistent spacing styles in Makefile, some lines are 'FOO+='
others are 'FOO += ...'

- trailing whitespace in CONFIGURE_ENV

- typo in directory name, s/terminolgy/terminology/

- does it actually need separate copies of the fonts or can it
use the ones from X / other packages? if it needs separate ones for
some reason, then you are missing license markers for fonts e.g.
terminus should be OFL.

Re: Building GCC-4.8.1 without ports

[Stuart Henderson]

On 2013/09/11 10:07, niXman wrote:
> Hi,
> 
> I try to build GCC-4.8.1 on pre 5.4 without ports and faced with the
> following error when libgomp is configured:
> configure:3664: checking for C compiler default output file name
> configure:3686: /home/nixman/build/./gcc/xgcc
> -B/home/nixman/build/./gcc/
> -B/home/nixman/prefix/x86_64-unknown-openbsd5.4/bin/
> -B/home/nixman/prefix/x86_64-unknown-openbsd5.4/lib/ -isystem
> /home/nixman/prefix/x86_64-unknown-openbsd5.4/include -isystem
> /home/nixman/prefix/x86_64-unknown-openbsd5.4/sys-include-g -O2
> conftest.c  >&5
> /usr/bin/ld: /tmp//ccgLXgHL.o: relocation R_X86_64_32 can not be used
> when making a shared object; recompile with -fPIC
> /tmp//ccgLXgHL.o: could not read symbols: Bad value
> collect2: error: ld returned 1 exit status
> configure:3690: $? = 1
> configure:3727: result:
> configure: failed program was:
> ...
> ...
> configure:3733: error: in
> `/home/nixman/build/x86_64-unknown-openbsd5.4/libgomp':
> configure:3736: error: C compiler cannot create executables
> 
> 
> GCC configured with:
> --prefix=/home/nixman/prefix \
> --disable-shared \
> --with-{gmp,mpfr,mpc}=/home/nixman/prefix \
> --disable-nls \
> --disable-miltilib \
> --with-gnu-as \
> --with-gnu-ld \
> --enable-languages=c,c++,fortran,go \
> --host=x86_64-unknown-openbsd5.4 \
> --build=x86_64-unknown-openbsd5.4 \
> --target=x86_64-unknown-openbsd5.4
> 
> gmp,mpfr,mpc configured witg --disable-shared
> 
> Ideas?
> 
> Thanks!
> 
> -- 
> Regards,
> niXman
> 

The error message gives quite a good clue:

relocation R_X86_64_32 can not be used when making a shared object; recompile 
with -fPIC

Re: llvm and libc++

[Stuart Henderson]

On 2013/09/11 09:05, niXman wrote:
> Hi,
> 
> Tell me please, why LLVM is built without clang-libc++[1] support?
> 
> 
> [1] http://libcxx.llvm.org/
> 
> -- 
> Regards,
> niXman
> 

Not yet ported.

Re: UPDATE: databases/py-sqlite

[Stuart Henderson]

On 2013/09/11 10:47, Giovanni Bechis wrote:
> On 09/11/13 00:45, Giovanni Bechis wrote:
> > Major update to latest version, now it links with sqlite3 instead of 
> > sqlite2.
> >  Comments ? Ok ?
> >   Cheers
> >Giovanni
> > 
> As spotted by ajacoutot@, security/yubiserve needs this patch to work, I do 
> not have a yubikey to test it with, any testers ?
>  Cheers
>   Giovanni
>   
> 

My yubiserve box is running 5.4, I'll try and get something else setup to test 
this with..

Re: Building GCC-4.8.1 without ports

[Stuart Henderson]

On 2013/09/11 12:06, niXman wrote:
> 2013/9/11 Stuart Henderson
> > The error message gives quite a good clue:
> >
> > relocation R_X86_64_32 can not be used when making a shared object; 
> > recompile with -fPIC
> 
> Maybe, but it doesn't speak to me about anything. Can you help me?

"recompile with -fPIC" seems clear to me. If this doesn't mean anything
to you, I don't think you should be trying to port GCC by yourself.

Re: small www/apache-httpd fixes: rc script and readme

[Stuart Henderson]

On 2013/09/11 22:26, Antoine Jacoutot wrote:
> On Wed, Sep 11, 2013 at 09:50:14PM +0200, Stefan Sperling wrote:
> > This fixes two small issues with www/apache-httpd:
> > 
> >  - The rc script doesn't work out of the box because it doesn't pass
> >the -k option needed for 'start|stop|...' arguments. I hope my
> >way of fixing it is appropriate, and welcome other suggestions.
> 
> Hmm... it works fine for me. What error are you running into exactly?

It works for me as-is too, though I think -k is more correct (the usage
text implies that you have to use it)

> >  - The readme implies that chroot is not available, while it has
> >been available since 2.2.10 and does indeed work as advertised.
> >http://httpd.apache.org/docs/2.2/mod/mpm_common.html#chrootdir

How about removing MESSAGE? We're trying to get rid of base httpd..

Re: nsca-ng 64 bit time_t segfault on i386

[Stuart Henderson]

cc'ing Holger; OpenBSD recently switched to long long time_t which has
caused nsca-ng to break on 32-bit arch.

On 2013/09/12 10:42, Florian Obser wrote (on ports@openbsd.org):
> send_nsca segfaults on i386 (presumably on all 32bit archs):
> 
> #0  strlen (str=0xd )
> at /usr/src/lib/libc/string/strlen.c:43
> 43  for (s = str; *s; ++s)
> (gdb) bt 
> #0  strlen (str=0xd )
> at /usr/src/lib/libc/string/strlen.c:43
> #1  0x01d1a302 in __vfprintf (fp=0xcfbd753c, 
> fmt0=0x3c000668 "[%lu] PROCESS_SERVICE_CHECK_RESULT;%.*s;%.*s;%.*s;%s", 
> ap=0xcfbd772c "\026!O\211\002") at /usr/src/lib/libc/stdio/vfprintf.c:879
> #2  0x01cca8c7 in vasprintf (str=0xcfbd7778, 
> fmt=0x3c000668 "[%lu] PROCESS_SERVICE_CHECK_RESULT;%.*s;%.*s;%.*s;%s", 
> ap=0xcfbd7718 "\035\2241R") at /usr/src/lib/libc/stdio/vasprintf.c:40
> #3  0x1c00693f in xvasprintf (result=0xcfbd7778, 
> format=0x3c000668 "[%lu] PROCESS_SERVICE_CHECK_RESULT;%.*s;%.*s;%.*s;%s", 
> ap=0xcfbd7718 "\035\2241R")
> at /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/lib/wrappers.c:87
> #4  0x1c006982 in xasprintf (result=0xcfbd7778, 
> format=0x3c000668 "[%lu] PROCESS_SERVICE_CHECK_RESULT;%.*s;%.*s;%.*s;%s")
> at /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/lib/wrappers.c:80
> #5  0x1c00375f in parse_check_result (
> input=0x894f2100 "-eopenbsd.adns.de_em0\tcvsync update\tOK\tsync ok  - 
> openbsd.adns.de", delimiter=9 '\t')
> at /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/src/client/parse.c:107
> #6  0x1c002608 in handle_input_chunk (input=0x870a9000, 
> chunk=0x894f2100 "-eopenbsd.adns.de_em0\tcvsync update\tOK\tsync ok  - 
> openbsd.adns.de") at 
> /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/src/client/client.c:137
> #7  0x01e8433d in ev_invoke () from /usr/local/lib/libev.so.3.1
> ---Type  to continue, or q  to quit--- 
> #8  0x1c00345a in input_read_chunk (input=0x870a9000, 
> handle_read=0x1c002520 )
> at /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/src/client/input.c:85
> #9  0x1c0024fa in handle_tls_moin_response (tls=0x870a8400, 
> line=0x870a9900 "MOIN")
> at /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/src/client/client.c:202
> #10 0x01e843ae in ev_invoke_pending () from /usr/local/lib/libev.so.3.1
> #11 0x01e890a2 in ev_run () from /usr/local/lib/libev.so.3.1
> #12 0x1c003df2 in main (argc=0, argv=Cannot access memory at address 0x3
> )
> at /usr/ports/pobj/nsca-ng-1.1/nsca-ng-1.1/src/client/send_nsca.c:123
> 
> 
> patch-src_client_parse_c fixes the problem for me, only the "case 4"
> tested. I gave the source a quick once over and found another issue in
> fifo.c, untested though.

Nearly, but time_t should be printed using %lld, and the value cast (long
long) so that it's also OK for other OS where time_t is not long long.

> 
> Index: net/nagios/nsca-ng//patches/patch-src_client_parse_c
> ===
> RCS file: net/nagios/nsca-ng//patches/patch-src_client_parse_c
> diff -N net/nagios/nsca-ng//patches/patch-src_client_parse_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ net/nagios/nsca-ng//patches/patch-src_client_parse_c  12 Sep 2013 
> 10:36:12 -
> @@ -0,0 +1,30 @@
> +$OpenBSD$
> +--- src/client/parse.c.orig  Fri Feb  8 16:35:32 2013
>  src/client/parse.c   Thu Sep 12 12:22:16 2013
> +@@ -56,7 +56,7 @@ parse_command(const char *line)
> + if (line[0] == '[')
> + command = xstrdup(line);
> + else
> +-xasprintf(&command, "[%lu] %s", time(NULL), line);
> ++xasprintf(&command, "[%llu] %s", time(NULL), line);
> + 
> + return command;
> + }
> +@@ -96,7 +96,7 @@ parse_check_result(const char *input, char delimiter)
> + case 3:
> + debug("Got host check result");
> + xasprintf(&command,
> +-"[%lu] PROCESS_HOST_CHECK_RESULT;%.*s;%.*s;%s",
> ++"[%llu] PROCESS_HOST_CHECK_RESULT;%.*s;%.*s;%s",
> + time(NULL),
> + lengths[0], fields[0],
> + lengths[1], fields[1],
> +@@ -105,7 +105,7 @@ parse_check_result(const char *input, char delimiter)
> + case 4:
> + debug("Got service check result");
> + xasprintf(&command,
> +-"[%lu] PROCESS_SERVICE_CHECK_RESULT;%.*s;%.*s;%.*s;%s",
> ++"[%llu] PROCESS_SERVICE_CHECK_RESULT;%.*s;%.*s;%.*s;%s",
> + time(NULL),
> + lengths[0], fields[0],
> + lengths[1], fields[1],
> Index: net/nagios/nsca-ng//patches/patch-src_server_fifo_c
> ===
> RCS file: net/nagios/nsca-ng//patches/patch-src_server_fifo_c
> diff -N net/nagios/nsca-ng//patches/patch-src_server_fifo_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ net/nagios/nsca-ng//patches/patch-src_server_fifo_c   12 Sep 2013 
> 10:36:12 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +--- src/server/fifo.c.orig   Thu Sep 12 12:31:03 2013
> ++

[th...@debian.org: [oss-security] CVE request: MediaWiki Security Release: 1.21.2, 1.20.7 and 1.19.8]

[Stuart Henderson]

Could somebody who uses www/wikimedia take a look at updating it please?
Last week's security fixes include a fix for an authentication bypass bug.


- Forwarded message from Thijs Kinkhorst  -

From: Thijs Kinkhorst 
Date: Wed, 4 Sep 2013 12:18:36 +0200
To: oss-secur...@lists.openwall.com
Cc: Chris Steipp 
Reply-To: oss-secur...@lists.openwall.com
Importance: Normal
User-Agent: SquirrelMail/1.4.23 [SVN]
Subject: [oss-security] CVE request: MediaWiki Security Release: 1.21.2, 1.20.7 
and 1.19.8

Hi,

Mediawiki has announced the following security releases. The message
contains a link to the patches for various release branches.

Can CVE names be assigned please?


thanks,
Thijs

 Original Message 
Subject: [MediaWiki-announce] MediaWiki Security Release: 1.21.2, 1.20.7
and 1.19.8
From:"Chris Steipp" 
Date:Tue, September 3, 2013 22:50
To:  mediawiki-annou...@lists.wikimedia.org
 "MediaWiki-l" 
 "Wikimedia developers" 
--

I would like to announce the release of MediaWiki 1.21.2, 1.20.7 and
1.19.8. These releases fix 3 security related bugs that could affect users
of MediaWiki. Download links are given at the end of this email.

* Mozilla, and other developers, reported a full path disclosure in
MediaWiki, when an invalid language is specified in ResourceLoader


* An internal review found several API modules allowed anti-CSRF tokens to
be accessed via JSONP.


* Andreas Peetz reported an issue with the MediaWiki API where an invalid
property name could be used for XSS with older versions of Internet
Explorer.



Additionally, the following extensions have been updated to fix security
issues:

* CentralAuth: An internal review found an authentication regression that
allowed an attacker to bypass authentication


* SyntaxHighlight_GeSHi: Mateusz Goik reported an XSS in the included
example.php script


* CheckUser: Alex Monk reported and fixed that CheckUser didn't require
anti-CSRF tokens for checking users


* Wikibase: Liangent reported and fixed an XSS


* LiquidThreads: Alex Monk reported and fixed an XSS




Full release notes for 1.21.2:


Full release notes for 1.20.7:


Full release notes for 1.19.8:


For information about how to upgrade, see



**
   1.21.2
**
Download:
http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.2.tar.gz

Patch to previous version (1.21.1):
http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.2.patch.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.21/mediawiki-core-1.21.2.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.2.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.2.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   1.20.7
**
Download:
http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.7.tar.gz

Patch to previous version (1.20.6):
http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.7.patch.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.20/mediawiki-core-1.20.7.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.7.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.7.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   1.19.8
**
Download:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.8.tar.gz

Patch to previous version (1.19.7):
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.8.patch.gz

GPG signatures:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.8.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.8.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.8.patch.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

**
   Extension:CentralAuth

Re: [th...@debian.org: [oss-security] CVE request: MediaWiki Security Release: 1.21.2, 1.20.7 and 1.19.8]

[Stuart Henderson]

On 2013/09/13 19:01, wen heping wrote:
> Please go ahead and feel free to take the maintainership of it.

I don't use it, but if security fixes aren't handled reasonably quickly, there
isn't much point in having webapps in ports.

(Wordpress also needs some update love if anyone interested is reading - remote
code execution in some cases).

Re: [update] mutagen 1.22

[Stuart Henderson]

On 2013/09/17 13:26, David Coppa wrote:
> On Tue, Sep 17, 2013 at 1:23 PM, Giovanni Bechis  
> wrote:
> > On 09/16/13 13:08, Giovanni Bechis wrote:
> >> On 09/16/13 09:44, David Coppa wrote:
> >>>
> >>> Hi!
> >>>
> >>> The diff below updated audio/py-mutagen to its latest version.
> >>>
> >>> MAKE_ENV here is needed to fix a reproducible error in regression
> >>> tests:
> >>>
> >> regression tests are hanging for me (OpenBSD 5.4-current (GENERIC.MP) #1: 
> >> Mon Aug 12 20:16:33 PDT 2013) with python stuck in getblk or biowait.
> >> mutagen-1.20 regression tests has the same problem.

Any clues from ktrace about what's happening?

> >> As for the MAKE_ENV trick maybe C.UTF-8 could be more correct ?
> >> I will try to update to more recent snapshot soon and retest.
> > Even with an upgraded snapshots mutagen tests hangs; I tried to run them 
> > "by hand" and they starts, I also run ./setup.py test --quick and all 
> > "quick" tests finished without any failures, maybe it's a local problem.
> > Portwise is ok and Exaile still works.
> 
> Strange, cause I do not have this problem.
> 
> So, should I change MAKE_ENV to "LC_CTYPE=C.UTF-8", instead of
> "LC_CTYPE=en_US.UTF-8"?
> 
> Stuart, what do you think about this?
> 
> ciao,
> David
> 

Coming from a mostly-7bit-country I'm no expert on NLS but in the
faq we're telling people to use en_US.UTF-8..

http://www.openbsd.org/faq/faq10.html#charset

Re: NEW: multimedia/MediaInfo

[Stuart Henderson]

On 2013/09/18 15:35, Dmitrij D. Czarkoff wrote:
> Hello!
> 
> I prepared a port of MediaInfo - media files analysis utility. Comments? OKs?

It would be a bit more standard with the changes from the diff below.
I don't like the "do-build" much though, this *is* running normal
autoconf scripts internally so it would really be better to find
a way to use CONFIGURE_STYLE=gnu which passes in the normal
flags/variables and, importantly, copies in correct versions of
config.status/config.guess/config.cache...

Other things, doesn't honour CFLAGS/CXXFLAGS, CC/CXX, and I haven't
tried but it looks like it may pick up textproc/tinyxml if installed at
build time.

> begin-base64 644 MediaInfo.tgz

MIME attachments are preferred.


diff --git a/Makefile b/Makefile
index 528abea..c28b3b0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,8 @@
 # $OpenBSD$
 
 V =0.7.64
-DISTNAME = MediaInfo-${V}
+DISTNAME = MediaInfo_CLI_${V}_GNU_FromSource
+PKGNAME =  mediainfo-${V}
 COMMENT =  multimedia files analysis tool
 CATEGORIES =   multimedia
 HOMEPAGE = http://mediaarea.net/
@@ -12,13 +13,13 @@ PERMIT_PACKAGE_CDROM =  Yes
 
 WANTLIB = c crypto curl glib-2.0 iconv idn intl m mms pcre pthread ssl stdc++ z
 
-MASTER_SITES = 
${MASTER_SITE_SOURCEFORGE:=mediainfo/binary/mediainfo/${V}/}
-MASTER_SITES0 =${HOMEPAGE:=download/binary/mediainfo/${V}/}
+MASTER_SITES = 
${MASTER_SITE_SOURCEFORGE:=mediainfo/binary/mediainfo/${V}/} \
+   http://mediaarea.net/download/binary/mediainfo/${V}/
 
-DISTFILES =MediaInfo_CLI_0.7.64_GNU_FromSource${EXTRACT_SUFX}
 EXTRACT_SUFX = .tar.bz2
 
-LIB_DEPENDS =  multimedia/libmms net/curl
+LIB_DEPENDS =  multimedia/libmms \
+   net/curl
 
 WRKDIST =  ${WRKDIR}/MediaInfo_CLI_GNU_FromSource
 

Re: squid crashes in 5.3

[Stuart Henderson]

On 2013/09/18 13:18, patric conant wrote:
> I've had a squid/dansguardian machine running for years, religiously
> upgrade with set cds every 6 months. Most recently I upgraded over an ssh
> session. Thinking that was the cause I fiddled with it for a week or so,
> getting intermittent to increased "connection reset" errors in client
> machine browsers. I employed replacement hardware, an out of service p4,
> with 1.25 GB ram with a clean installation of 5.3. and the following
> packages.

What does squid's cache.log say?


Have you got a "squid" class in login.conf? If so, what resource limits apply 
to it,
if not, what limits apply to the "daemon" class? - If you don't know what this 
means,
see the "system resource limits" section from the newer version of the
package readme for squid in -current:

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/www/squid/pkg/README-main


If the above doesn't help, can you isolate squid from dansguardian to try and
identify which side is causing the problem?

Re: UPDATE: www/cclive

[Stuart Henderson]

On 2013/09/18 23:47, Anthony J. Bentley wrote:
> Hi,
> 
> Below is a trivial update to cclive-0.7.16.
> 
> My previous update posted was 0.7.12, and had multiple bogus warnings at
> runtime. These are all fixed.

they still have the warnings for the pointless renaming of command line
flags, oh well I guess they won't back down on that!..

> Works fine on i386/amd64.
> 
> ok?

Please add USE_GROFF=Yes, then it's OK. The bullet-point lists in the
(docbook-xsl generated) manual are slightly broken with mandoc:

-   oa regular expression pattern
+   o   a regular expression pattern
 
-   oformat (media stream) to download
+   o   format (media stream) to download

(manpage source at http://junkpile.org/cclive.1)

remove www/moodle port

[Stuart Henderson]

The current moodle port isn't maintained, is very outdated and
there have been a number of security fixes since then (upstream are
quite good about reporting these).

The update procedure involves upgrading to an intermediate version
before moving on to a current version, the port isn't doing anything
clever, and the readme has almost no information about configuration
on OpenBSD, so I think removing it makes most sense.

OK?

Re: the_silver_searcher: Patch upstream with 0.16

[Stuart Henderson]

On 2013/09/19 18:09, Florian Stinglmayr wrote:
> Hi list,
> 
> even though the the_silver_searcher never made it into the ports,
> something good did came out of it: The patch I had made that fixes a
> segmentation fault that occoured on OpenBSD is now upstream. The port
> in openbsd-wip[1] has been bumped to the new version.
> 
> Regards,
> Florian
> 
> [1] https://github.com/jasperla/openbsd-wip
> 

The bash completion script should go in
${PREFIX}/share/bash-completion/completions/ then it will be OK sthen@
for anyone who would like to import.

Annoyingly the MASTER_SITES has broken ipv6 :(

Re: NEW: x11/radeontop

[Stuart Henderson]

On 2013/09/20 13:20, Dmitrij D. Czarkoff wrote:
> On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote:
> > 1) Getting tarball off of github and the name of the distfile itself
> > (v0.6)
> 
> You might want to use DIST_SUBDIR (see bsd.port.mk(5)). BTW, is it really
> necessary to hide file suffix?
>  
> > 2) Patching of the Makefile to link to libintl properly
> > 
> > 3) Patching of the Makefile to install files properly
> 
> While you are at patching Makefile anyway, why not patch away all the CFLAGS
> stuff that is not needed (eg. it forces "-Wall", which may go against local
> settings). FWIW I would probably replace the original Makefile with a custom
> one.
> 
> -- 
> Dmitrij D. Czarkoff
> 

- no problem with the -W's in CFLAGS, but the hardcoded /usr/local 
should pick up LOCALBASE instead (will need to be patched using SUBST_CMD etc).
I see no reason to replace with a custom Makefile, that is more likely
to cause problems at update time

- lowercase start of COMMENT

- stray \ at end of MODULES

- follow Makefile.template ordering of variables e.g. WANTLIB is in
the wrong place (goes below PERMIT_..), makes it easier when we do bulk
work on the tree

Re: [UPDATE] mail/sylpheed

[Stuart Henderson]

On 2013/09/20 09:33, Remi Pointel wrote:
> Hi,
> 
> this is the diff to update sylpheed to 3.3.0.

This diff is against an out-of-date tree, you have Makefile 1.98, current is 
1.102

>  SHARED_LIBS +=   sylph-0   2.1 # 2.1
>  SHARED_LIBS +=   sylpheed-plugin-0 2.1 # 2.1

have you checked if these need a bump? (also some space/tab/space/tab in
the lines ;)

Re: [UPDATE] mail/sylpheed

[Stuart Henderson]

On 2013/09/20 07:12, Amit Kulkarni wrote:
> On Fri, 20 Sep 2013 09:33:02 +0200
> Remi Pointel  wrote:
> 
> > Hi,
> > 
> > this is the diff to update sylpheed to 3.3.0.
> > 
> > Are you ok?
> > 
> > Cheers,
> > 
> > Remi.
> 
> 
> 3.4.0 is going to come out soon. I am running 3.4 beta5...
> 
> Please remove the extra PERMIT_* lines. Just keeping the 
> PERMIT_PACKAGE_CDROM=Yes line... following other ports.

Careful with these btw, sylpheed is not quite like other ports, see the
compface flavour. I'm not saying that this isn't right, but just check
things work how you expect (make dump-vars).

Re: Recent version of gcc for amd64?

[Stuart Henderson]

On 2013/09/20 12:40, John Carr wrote:
> 
> Is it possible to build gcc 4.8 / 4.9 (development) for OpenBSD 5.3 amd64?
> 
> I tried and failed.  The first stage compiler fails building libgomp
> because of a relocation problem in a DWARF frame descriptor.
> 
> "relocation R_X86_64_32 can not be used when making a shared object"
> 
> I am not explicitly making a shared object but who knows what's going on
> internally.
> 
> Thinking that the old GNU assembler might be at fault I fetched a recent
> binutils.  Compiling that fails because the compiler gives errors about
> use of the "struct hack" (which is now blessed by standards, but still
> dangerous).  I beat on the code to avoid the warning.  The next obstacle
> is x86-64 openbsd is not a supported target for the linker.  I changed
> the target script to treat it like netbsd.  And I don't know what error
> will come next, but I expect to find one.  And I don't know if old binutils
> is really the problem?
> 
> Any advice?
> 

gcc 4.8 is in packages in -current and the upcoming release OpenBSD 5.4,
if you want to try and build it on 5.3 then fetching the port from the
OPENBSD_5_4 branch is probably your best starting point, you may need
to disable ada by removing amd64 from the ONLY_FOR_ARCHS-ada line to
avoid the binary bootstrap which is required).

For 4.9 your best starting point is probably to get 4.8.1 building and
then copy/modify the port to point at 4.9 instead.

NEW: giflib

[Stuart Henderson]

Quick history: giflib was changed to libungif when the patent became a
problem, but more recently this has expired and so development has moved
back to giflib.

Here's a port for giflib. OK to import it (unlinked for now)?

I have a diff for the rest of the tree to switch across (Makefile changes
obviously, but also various patches are needed as the API has changed for
thread safety) that I'll send separately.





giflib.tgz
Description: application/tar-gz

Re: NEW: x11/radeontop (v2)

[Stuart Henderson]

On 2013/09/20 16:29, Kyle R W Milz wrote:
> My knowledge of Make is terrible at best. I think `all' is the default
> rule and so it gets invoked during build time, and then at when faking
> the install rule is invoked, which depends on `all' again. But I thought
> Make was supposed to be smart and not rebuild if none of the
> dependencies have changed.

It's probably because of the $(verh) stuff. Please patch things so
it doesn't use getver.sh to run git, nicest way would probably be to
create version.h manually with the right version number in it.

Re: NEW: x11/radeontop (v2)

[Stuart Henderson]

On 2013/09/20 16:45, Kyle R W Milz wrote:
> On Sat, Sep 21, 2013 at 12:15:07AM +0200, J??r??mie Courr??ges-Anglas wrote:
> 
> < big snip >
> 
> > Is that port supposed to be compiled twice, at build and fake time?
> 
> OK I think I got something here. Untarring reveals that there is no
> include/version.h but there is a getver.sh shell script that is
> called while building to generate it. However getver.sh depends on
> the git repository to define the version number (through git describe)
> but the git repo is not included in the tarball. This thing is broken
> as hell.

Looks to me like it is meant to be generated when a release is rolled
with 'make dist' and then there is a fallback for git checkouts which
don't have that file.

update: vim 7.4.31

[Stuart Henderson]

Here's an update to vim (there was a recent release 7.4, and I've pulled
in the post-release patches as of now). Also to slightly reduce size of
the main package I've moved the non-English tutor files to the -lang
subpackage, along with the menus and manpages which were already there.
(There's not a huge difference, but seeing as this is something which
plenty of users install on every system, it's probably worthwhile).

ckuethe, do you still want to stay listed as maintainer?

Any test reports, comments, OKs?

Index: Makefile
===
RCS file: /cvs/ports/editors/vim/Makefile,v
retrieving revision 1.129
diff -u -p -r1.129 Makefile
--- Makefile26 Mar 2013 08:12:35 -  1.129
+++ Makefile21 Sep 2013 23:07:00 -
@@ -3,11 +3,10 @@
 COMMENT-main=  vi clone, many additional features
 COMMENT-lang=  vi clone, NLS subpackage
 
-VERSION=   7.3.850
+VERSION=   7.4.31
 DISTNAME=  vim-${VERSION}
 PKGNAME-main=  vim-${VERSION}
 PKGNAME-lang=  vim-lang-${VERSION}
-REVISION-lang= 2
 P= vim${VERSION:R:S/.//}
 CATEGORIES=editors
 # Upstream's normal distribution (http://ftp.vim.org/pub/vim/unix/) consists
@@ -106,7 +105,7 @@ CONFIGURE_ARGS+= --enable-gui="gtk2" \
--enable-xim \
--with-x
 WANTLIB += ICE SM X11 Xcomposite Xcursor Xdamage Xdmcp Xext Xfixes
-WANTLIB += Xi Xinerama Xpm Xrandr Xrender Xt atk-1.0 cairo expat
+WANTLIB += Xi Xinerama Xpm Xrandr Xrender Xt atk-1.0 cairo
 WANTLIB += fontconfig freetype gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0
 WANTLIB += glib-2.0 gobject-2.0 gtk-x11-2.0 m pango-1.0 pangocairo-1.0
 WANTLIB += pangoft2-1.0 pthread z
Index: distinfo
===
RCS file: /cvs/ports/editors/vim/distinfo,v
retrieving revision 1.39
diff -u -p -r1.39 distinfo
--- distinfo16 Mar 2013 22:56:44 -  1.39
+++ distinfo21 Sep 2013 23:07:00 -
@@ -1,2 +1,2 @@
-SHA256 (vim-7.3.850.tar.bz2) = lClIxcjvlj8G0heSJiGsnU3MOO3WJT/9zGOTarN5JTs=
-SIZE (vim-7.3.850.tar.bz2) = 9200471
+SHA256 (vim-7.4.31.tar.bz2) = LMILtJ8Zay7t0cFxj3rgCkljGaz5V/wkueLKx53OYVs=
+SIZE (vim-7.4.31.tar.bz2) = 9518320
Index: patches/patch-runtime_autoload_tar_vim
===
RCS file: /cvs/ports/editors/vim/patches/patch-runtime_autoload_tar_vim,v
retrieving revision 1.1
diff -u -p -r1.1 patch-runtime_autoload_tar_vim
--- patches/patch-runtime_autoload_tar_vim  15 Jun 2011 19:43:10 -  
1.1
+++ patches/patch-runtime_autoload_tar_vim  21 Sep 2013 23:07:00 -
@@ -1,7 +1,7 @@
 $OpenBSD: patch-runtime_autoload_tar_vim,v 1.1 2011/06/15 19:43:10 sthen Exp $
 runtime/autoload/tar.vim.orig  Wed Jun 15 13:27:21 2011
-+++ runtime/autoload/tar.vim   Wed Jun 15 13:30:00 2011
-@@ -42,7 +42,7 @@ if !exists("g:tar_readoptions")
+--- runtime/autoload/tar.vim.orig  Fri Sep 20 19:13:53 2013
 runtime/autoload/tar.vim   Sat Sep 21 23:43:47 2013
+@@ -43,7 +43,7 @@ if !exists("g:tar_readoptions")
   let g:tar_readoptions= "OPxf"
  endif
  if !exists("g:tar_cmd")
Index: patches/patch-runtime_filetype_vim
===
RCS file: /cvs/ports/editors/vim/patches/patch-runtime_filetype_vim,v
retrieving revision 1.4
diff -u -p -r1.4 patch-runtime_filetype_vim
--- patches/patch-runtime_filetype_vim  16 Mar 2013 22:56:44 -  1.4
+++ patches/patch-runtime_filetype_vim  21 Sep 2013 23:07:00 -
@@ -1,6 +1,6 @@
 $OpenBSD: patch-runtime_filetype_vim,v 1.4 2013/03/16 22:56:44 sthen Exp $
 runtime/filetype.vim.orig  Thu Mar  7 15:08:35 2013
-+++ runtime/filetype.vim   Thu Mar  7 15:25:57 2013
+--- runtime/filetype.vim.orig  Fri Sep 20 19:13:53 2013
 runtime/filetype.vim   Sat Sep 21 23:43:48 2013
 @@ -71,6 +71,14 @@ func! s:Check_inp()
endif
  endfunc
@@ -16,7 +16,7 @@ $OpenBSD: patch-runtime_filetype_vim,v 1
  " A-A-P recipe
  au BufNewFile,BufRead *.aap   setf aap
  
-@@ -601,7 +609,7 @@ au BufNewFile,BufRead dict.conf,.dictrcsetf 
dictconf
+@@ -604,7 +612,7 @@ au BufNewFile,BufRead dict.conf,.dictrcsetf 
dictconf
  au BufNewFile,BufRead dictd.conf  setf dictdconf
  
  " Diff files
@@ -25,7 +25,7 @@ $OpenBSD: patch-runtime_filetype_vim,v 1
  
  " Dircolors
  au BufNewFile,BufRead .dir_colors,.dircolors,*/etc/DIR_COLORS setf dircolors
-@@ -1077,7 +1085,7 @@ au BufNewFile,BufRead */etc/mail/aliases,*/etc/aliases
+@@ -1091,7 +1099,7 @@ au BufNewFile,BufRead */etc/mail/aliases,*/etc/aliases
  au BufNewFile,BufRead .mailcap,mailcapsetf mailcap
  
  " Makefile
@@ -34,7 +34,7 @@ $OpenBSD: patch-runtime_filetype_vim,v 1
  
  " MakeIndex
  au BufNewFile,BufRead *.ist,*.mst setf ist
-@@ -2224,12 +2232,14 @@ au BufNewFile,BufRead *.vim,*.vba,.exrc,_exrc  setf vim
+@@ -2244,12 +2252,14 @@ au BufNewFile,BufRead *.vim,*.vba,.exrc,_exrc  setf vim
  a

Re: update: vim 7.4.31

[Stuart Henderson]

On 2013/09/22 00:10, Stuart Henderson wrote:
> ckuethe, do you still want to stay listed as maintainer?

.. email bounces, so please let me have an alternative if you're
reading and want to stay listed :)

segfaults at exit [Re: gphoto segfaults]

[Stuart Henderson]

On 2013/09/22 12:51, Jan Stary wrote:
> I am using gphoto-2.5.2 to download photos
> form a Canon Powershot A630, with `gphoto -P'.
> 
> The pictures and videos download fine,
> but after the download is complete,
> gphoto segfaults, dumping a core.
> 
> Is anyone else seeing this?
> 
>   Jan
> 

Yes, I've seen the same in some other programs too (e.g. the dd2 port
posted yesterday). Not much in a backtrace, even with -g.

(gdb) bt full
#0  0x178ab701c570 in ?? ()
No symbol table info available.
#1  0x178ac057f177 in __cxa_finalize (dso=0x0) at 
/usr/src/lib/libc/stdlib/atexit.c:147
p = 0x178abe5b2000
fn = {fn_ptr = {std_func = 0x178ab701c570, cxa_func = 0x178ab701c570}, 
fn_arg = 0x0, 
  fn_dso = 0x0}
n = 
pgsize = 4096
call_depth = 1
#2  0x178ac056827a in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:57
No locals.
#3  0x1788b6506558 in ___start ()
No symbol table info available.
#4  0x in ?? ()
No symbol table info available.

Re: NEW: games/dd2

[Stuart Henderson]

On 2013/09/22 18:13, Juan Francisco Cantero Hurtado wrote:
> Makefile without ${V}, as requested by bcallah@, sthen@ and kirby@.
> 
> I think the port is ready. I've various good reports from different
> users with different graphics cards on i386/amd64 and only one crash.
> 
> Tests from bcallah@, sthen@, bentley@ and kirby@.


OK sthen.

btw, any idea why the mime-type for your attachment is "applica/gzip" instead of
"application/gzip"? (I can add it to my .mailcap to open in vim, but it seems
strange that it's set that way).

Re: update: vim 7.4.31

[Stuart Henderson]

On 2013/09/22 00:10, Stuart Henderson wrote:
> Here's an update to vim (there was a recent release 7.4, and I've pulled
> in the post-release patches as of now). Also to slightly reduce size of
> the main package I've moved the non-English tutor files to the -lang
> subpackage, along with the menus and manpages which were already there.
> (There's not a huge difference, but seeing as this is something which
> plenty of users install on every system, it's probably worthwhile).
> 
> ckuethe, do you still want to stay listed as maintainer?
> 
> Any test reports, comments, OKs?

hmm, let's skip this for now, syntax highlighting is significantly
slower than with 7.3.850. I'll send another diff, possibly for an earlier
version, when I've worked out what's going on.

NEW: security/sslScanner

[Stuart Henderson]

sslScanner is a perl script which connects to one or more hostnames,
IP addresses or network ranges (cidr), scanning all hosts for SSL
and displaying common name and certificate expiry information.
It depends on 2 new Perl ports, also included in the tar.gz.
OK to import?



sslScanner.tgz
Description: application/tar-gz

Re: NEW: giflib

[Stuart Henderson]

On 2013/09/20 23:09, Stuart Henderson wrote:
> Quick history: giflib was changed to libungif when the patent became a
> problem, but more recently this has expired and so development has moved
> back to giflib.
> 
> Here's a port for giflib. OK to import it (unlinked for now)?
> 
> I have a diff for the rest of the tree to switch across (Makefile changes
> obviously, but also various patches are needed as the API has changed for
> thread safety) that I'll send separately.
> 
> 
> 

Did any ports devs have chance to check over this one yet?

ftp -ogiflib.tgz 'http://marc.info/?l=openbsd-ports&m=137971503231849&q=p3'

Re: NEW: giflib

[Stuart Henderson]

On 2013/09/23 16:35, Stuart Henderson wrote:
> On 2013/09/20 23:09, Stuart Henderson wrote:
> > Quick history: giflib was changed to libungif when the patent became a
> > problem, but more recently this has expired and so development has moved
> > back to giflib.
> > 
> > Here's a port for giflib. OK to import it (unlinked for now)?
> > 
> > I have a diff for the rest of the tree to switch across (Makefile changes
> > obviously, but also various patches are needed as the API has changed for
> > thread safety) that I'll send separately.
> > 
> > 
> > 
> 
> Did any ports devs have chance to check over this one yet?

Updated after feedback; regression tests repaired.  No change to the
main port itself, so no need to update if you're testing runtime.

http://junkpile.org/giflib.tgz

Re: UPDATE: net/snort 2.9.5.5

[Stuart Henderson]

On 2013/09/24 11:59, Community - Dognaedis wrote:
> Hi,
> I've been testing this on 5.2 and 5.3 amd64 without issues.
> but I've noticed that if I do a 'make update-plist' on net/daq
> I get a warning of SHARED_LIBS daq 2.0 vs 2.1 and sfbpf 1.0 vs 0.1.
> I've changed the Makefile so I don't get it. Is that the correct
> thing to do ?

You have updated individual ports to versions which depend on changes in
infrastructure; the whole tree should be in-sync. Specifically USE_LIBTOOL=Yes
is now the default and has been removed from ports.

(btw, with the time_t changes in -current, tests on earlier versions are
much less useful than usual right now).

Re: NEW: databases/mydumper

[Stuart Henderson]

On 2013/09/24 15:45, Giovanni Bechis wrote:
> On 09/16/13 17:55, Giovanni Bechis wrote:
> > pkg/DESCR:
> > mydumper is complement to mysqldump, for MySQL data dumping, providing
> > parallelism, performance and easier to manage output.
> > 
> > new version of databases/mysql-zrm can use this tool to speed up backups, 
> > separate diff soon.
> >  ok to import ? Comments ?
> >   Cheers
> >Giovanni
> > 
> Updated diff, textproc/py-sphinx is needed to build the documentation, atm it 
> fails building man pages (probably a bug in py-sphinx itself) so I disabled 
> man and pdf docs creation.
>  Cheers
>Giovanni

Rather than listing V and R separately, here's an alternative you might like to 
try:

V=0.5.2
DISTNAME=mydumper-$V
MASTER_SITES=https://launchpad.net/mydumper/${V:R}/${V}/+download/

otherwise, please zap PLIST.orig and move WANTLIB up below PERMIT_*
(it makes bulk wantlib syncs slightly less hassle to have things in a
standard place), and the license marker should be GPLv3+, then it's
ok with me.

Re: NEW-ish: sqlite3-tcl

[Stuart Henderson]

On 2013/09/24 21:12, Landry Breuil wrote:
> Right. As long as you've tested the pkg_add -r upgrade path...

and pkg_add -u

Re: webapps in OpenBSD

[Stuart Henderson]

On 2013/09/24 23:49, Matthias Kilian wrote:
> Well, we currently don't provide packages for -stable.

OpenBSD doesn't, but other people do (stable.mtier.org), and of course people 
can build their own..

Re: UPDATE: net/py-ftpdlib

[Stuart Henderson]

On 2013/09/25 00:56, Juan Francisco Cantero Hurtado wrote:
> On 09/24/13 22:27, Juan Francisco Cantero Hurtado wrote:
> >Update to the last release of pyftpdlib. Tested on amd64 using my
> >android as client. Also, I would like to take the maintainership.
> >
> >Please test and commit.
> >
> 
> You can test the package with this command and a ftp client:
> $ python2.7 -m pyftpdlib -p 12345
> 

hmm, on my recently-updated laptop (sep 20 amd64 snap) I get this:

$ python2.7 -m pyftpdlib -p 12345
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/local/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/usr/local/lib/python2.7/site-packages/pyftpdlib/__main__.py", line 45, 
in 
from pyftpdlib.servers import FTPServer
  File "/usr/local/lib/python2.7/site-packages/pyftpdlib/servers.py", line 521, 
in 
class MultiprocessFTPServer(_SpawnerBase):
  File "/usr/local/lib/python2.7/site-packages/pyftpdlib/servers.py", line 525, 
in MultiprocessFTPServer
_lock = multiprocessing.Lock()
  File "/usr/local/lib/python2.7/multiprocessing/__init__.py", line 175, in Lock
from multiprocessing.synchronize import Lock
  File "/usr/local/lib/python2.7/multiprocessing/synchronize.py", line 59, in 

" function, see issue 3770.")
ImportError: This platform lacks a functioning sem_open implementation, 
therefore, the required synchronization primitives needed will not function, 
see issue 3770.

Re: NEW: graphics/optipng

[Stuart Henderson]

- "@owner root" / "@group wheel" don't belong in plist for this

- check the linker command line;

 cc -s -o optipng optipng.o  optim.o  cbitset.o  osys.o  wildargs.o 
../opngreduc/libopngreduc.a  ../pngxtern/libpngxtern.a  ../libpng/libpng.a  
../zlib/libz.a  ../gifread/libgifread.a  ../pnmio/libpnmio.a  
../minitiff/libminitiff.a   -lm 

"-s" strips the installed binary; for ports, this can be done for a
normal build but shouldn't be done if it's a debug build (e.g.
make DEBUG="-g")

to fix these two above, I would write a custom do-install target using
${INSTALL_PROGRAM} for the binary and ${INSTALL_DATA} for the manpage
which uses correct permissions, ownership, and automatically uses -s
unless it's a DEBUG build.

- it should use the system libpng rather than a bundled copy; as well
as the configure flag, you'll need

CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"

- stray space at end of COMMENT

Re: NEW: graphics/optipng

[Stuart Henderson]

Because I forgot about when I wrote the mail :) Yes that's better.

"Dmitrij D. Czarkoff"  wrote:
>Stuart Henderson said:
>> to fix these two above, I would write a custom do-install target
>using
>> ${INSTALL_PROGRAM} for the binary and ${INSTALL_DATA} for the manpage
>> which uses correct permissions, ownership, and automatically uses -s
>> unless it's a DEBUG build.
>
>Why not ${INSTALL_MAN} for manpage?

Re: UPDATE: net/py-ftpdlib

[Stuart Henderson]

On 2013/09/25 01:12, Juan Francisco Cantero Hurtado wrote:
> Can you look if the patch is applied correctly in pyftpdlib/servers.py?

Yes that was it, new directory so it needed patch -p0.

Re: NEW: archivers/lzip

[Stuart Henderson]

On 2013/09/25 03:48, Juan Francisco Cantero Hurtado wrote:
> On Wed, Sep 25, 2013 at 03:25:25AM +0200, Juan Francisco Cantero Hurtado 
> wrote:
> > On 09/25/13 03:22, Juan Francisco Cantero Hurtado wrote:
> > >The tarball contains 7 small ports. All are part of the lzip project.
> > >
> > >Please test and commit.
> > >
> > >PS: If you like xz then you should try lzip :) (harder, better, faster,
> > >stronger)
> > >
> > >
> > >Lzip is a lossless data compressor with a user interface similar to the
> > >one of gzip or bzip2. Lzip decompresses almost as fast as gzip and
> > >compresses more than bzip2, which makes it well suited for software
> > >distribution and data archiving.
> > >
> > >Lzip is a clean implementation of the LZMA algorithm. The lzip file
> > >format is designed for long-term data archiving. It is clean, provides
> > >very safe 4 factor integrity checking. Lzip uses the same well-defined
> > >exit status values used by bzip2, which makes it safer when used in
> > >pipes or scripts than compressors returning ambiguous warning values,
> > >like gzip.
> > >
> > 
> > I forgot to attach the tarball.
> 
> New tarball. The previous one has a broken patch.
> 
> -- 
> Juan Francisco Cantero Hurtado http://juanfra.info

Nearly there, just a couple of things:

- In lzlib, you patched away the run_ldconfig=no line; this should stay.
Also please patch away the line which creates a symlink to liblzip.so and
regenerate the PLIST (and remove PFRAG.shared and the %%shared%% line).

- Looks like CONFIGURE_STYLE should be simple, these aren't autoconf.

Re: NEW: archivers/lzip

[Stuart Henderson]

On 2013/09/25 08:22, Stuart Henderson wrote:
> - Looks like CONFIGURE_STYLE should be simple, these aren't autoconf.

Oh, it has it already; I saw the "WARNING: unrecognized option:
'--enable-shared'" on almost all of the ports and assumed it was set
to gnu - maybe only use --enable-shared for lzlib?

Re: New port: Worker

[Stuart Henderson]

On 2013/09/25 11:50, Brian Callahan wrote:
> On 9/25/2013 9:09 AM, Eivind Evensen wrote:
> >This is an X11 filemanager.
> >
> 
> Makefile:
> * You need an RCS ID at the top (# $OpenBSD$ will do).
> * You forgot to put your name for MAINTAINER :) You only wrote your
> email address.
> * The license is GPLv2+
> * You only need the PERMIT_PACKAGE_CDROM=Yes line.
> * You should run 'make port-lib-depends-check' and add the
> appropriate libraries to WANTLIB and LIB_DEPENDS (as an exception,
> intl takes MODULES=devel/gettext and no intl in WANTLIB).
> * You need RUN_DEPENDS=devel/desktop-file-utils (I see a .desktop
> file in pkg/PLIST).
> * Don't use DISTFILES; it's smart enough to know what you want.
> * I'm not in love with the COMMENT; maybe someone else can chime in
> here. (for example, look at the COMMENT for x11/xfe)
> 
> pkg/DESCR:
> * You need to run pkg/DESCR through 'fmt -72' - one of your lines is
> too long. However, the one offending line is talking about the
> software being licensed GPLv2+, which is already noted in the
> Makefile, so you should delete it instead.
> 
> pkg/PLIST:
> * Because you need RUN_DEPENDS=devel/desktop-file-utils, you need the
> corresponding PLIST goo. Take a look at any of the many ports that
> have a .desktop file to see how to do that.
> 
> The port itself:
> * Any reason not to use libmagic? We have a port for it in devel/libmagic.
> * I don't believe we have a port of AVFS but it might be worth looking into.
> 

Some of these are also picked up by /usr/ports/infrastructure/bin/portcheck :)

Re: [UPDATE] devel/py-test

[Stuart Henderson]

On 2013/09/26 11:39, David Coppa wrote:
> On Thu, Sep 26, 2013 at 11:15 AM, Remi Pointel  wrote:
> > Hi,
> >
> > this is the diff to update to latest release of py-test: 2.3.5.
> >
> > Ok?
> 
> Have you looked at PLIST (make update-plist) ?
> 

python3 ports are special ;)

Re: UPDATE: claws-mail 3.9.2

[Stuart Henderson]

The plugin packages for claws-mail don't seem to be FLAVOR-dependent,
but currently they're packaged twice. is there any point having separate
packages for them?

$ make show=PKGNAMES
claws-mail-3.9.2 claws-mail-bogofilter-3.9.2 claws-mail-spamassassin-3.9.2 
claws-mail-htmlviewer-3.9.2 claws-mail-pdfviewer-3.9.2

$ FLAVOR=ldap make show=PKGNAMES
claws-mail-3.9.2-ldap claws-mail-bogofilter-3.9.2-ldap 
claws-mail-spamassassin-3.9.2-ldap claws-mail-htmlviewer-3.9.2-ldap 
claws-mail-pdfviewer-3.9.2-ldap

php and asterisk have examples of overwriting the FULLPKGNAME and
FULLPKGPATH for the subpackages to avoid the second set of packages
(and annoying "which package do you want?" messages from pkg_add).

Previously this only affected spamassassin/bogofilter but now that
various other ports have been rolled into claws-mail itself,
more users are going to run into it.

Re: UPDATE: games/freeciv 2.3.4 => 2.4.0

[Stuart Henderson]

On 2013/09/28 00:54, Brian Callahan wrote:
> * Rearrange the different PLISTs to make more sense.

>From a quick skim - moving files between subpackages means you need
an @conflict tag (e.g. freeciv-server.desktop going to -main needs
@conflict freeciv-client-<2.4.0 in PLIST-main).

Check with pkg_add -u that updating from old installed packages
works (point PKG_PATH to a dir containing new packages).

Re: UPDATE: devel/libmagic 5.11 => 5.15

[Stuart Henderson]

On 2013/09/29 15:22, Brian Callahan wrote:
> Library number for libmagic doesn't seem to have incremented (major
> or minor)

They should have bumped major, many functions are no longer exported,
and there's one new one. Otherwise ok.

> so I didn't bump any of the dependent ports.

Unlike some OS the ports infrastructure on OpenBSD keeps track of library
version numbers provided by a port and records them in the package signature,
so there's no need to bump dependent ports.

Re: ERROR: devel/gobject-introspection

[Stuart Henderson]

Your base OS is too old.

On 2013/09/30 14:45, Rafael Sadowski wrote:
> On Sat Sep 28, 2013 at 10:00:31AM +0200, Antoine Jacoutot wrote:
> > Wait a couple of days or use packages
> > Or recompile all your ports from scratch on an *empty* system.
> > It looks like you have old stuffs installed.
> > 
> 
> Thanks Antoine,
> 
> I deleted all my packages with "pkg_delte -X" and removed my /usr/ports.
> With new ports tree it build painless and works fine but my
> consolekit-0.4.6p0 build is in trouble. New advice? I had no time to
> check it until now. Maybe it's a know issue.
> 
> Cheers Rafael
> 
> ===>  Checking files for consolekit-0.4.6p0
> >> Fetch 
> >> http://www.freedesktop.org/software/ConsoleKit/dist/ConsoleKit-0.4.6.tar.xz
> >> (SHA256) ConsoleKit-0.4.6.tar.xz: OK
> ===> consolekit-0.4.6p0 depends on: gettext->=0.10.38 -> gettext-0.18.2p3
> ===> consolekit-0.4.6p0 depends on: metaauto-* -> metaauto-1.0p1
> ===> consolekit-0.4.6p0 depends on: autoconf-2.69 -> autoconf-2.69p0
> ===> consolekit-0.4.6p0 depends on: gmake-* -> gmake-3.82p2
> ===> consolekit-0.4.6p0 depends on: xz-* -> xz-5.0.5p0
> ===> consolekit-0.4.6p0 depends on: polkit-* -> polkit-0.112
> ===> consolekit-0.4.6p0 depends on: dbus-glib-* -> dbus-glib-0.100.2v0
> ===> consolekit-0.4.6p0 depends on: libiconv-* -> libiconv-1.14p0
> ===>  Verifying specs: X11 c dbus-1 dbus-glib-1 ffi gio-2.0 glib-2.0 
> gmodule-2.0 gobject-2.0 gthread-2.0 kvm pcre polkit-gobject-1 pthread xcb z 
> intl>=5 iconv>=6 X11 c dbus-1 dbus-glib-1 ffi gio-2.0 glib-2.0 gmodule-2.0 
> gobject-2.0 gthread-2.0 kvm pcre polkit-gobject-1 pthread xcb z intl>=5 
> iconv>=6
> ===>  found X11.16.0 c.70.0 dbus-1.10.2 dbus-glib-1.4.3 ffi.0.0 
> gio-2.0.3800.0 glib-2.0.3800.0 gmodule-2.0.3800.0 gobject-2.0.3800.0 
> gthread-2.0.3800.0 kvm.14.0 pcre.3.0 polkit-gobject-1.2.0 pthread.18.0 
> xcb.3.0 z.5.0 intl.6.0 iconv.6.0
> ===>  Extracting for consolekit-0.4.6p0
> ===>  Patching for consolekit-0.4.6p0
> `/usr/ports/pobj/consolekit-0.4.6/.prepatch_done' is up to date.
> Running autoconf-2.69 in /usr/ports/pobj/consolekit-0.4.6/ConsoleKit-0.4.6
> Running autoheader-2.69 in /usr/ports/pobj/consolekit-0.4.6/ConsoleKit-0.4.6
> ===>  Configuring for consolekit-0.4.6p0
> Using /usr/ports/pobj/consolekit-0.4.6/config.site (generated)
> configure: loading site script /usr/ports/pobj/consolekit-0.4.6/config.site
> checking for a BSD-compatible install... /usr/bin/install -c -o root -g bin
> 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
> checking whether UID '1000' is supported by ustar format... yes
> checking whether GID '1000' is supported by ustar format... yes
> checking how to create a ustar tar archive... (cached) /usr/bin/tar
> checking whether gmake supports nested variables... (cached) yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for style of include used by gmake... GNU
> checking for gcc... cc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... (cached) o
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether cc accepts -g... (cached) yes
> checking for cc option to accept ISO C89... none needed
> checking dependency style of cc... gcc3
> checking how to run the C preprocessor... cc -E
> checking for grep that handles long lines and -e... (cached) /usr/bin/grep
> checking for egrep... (cached) /usr/bin/egrep
> checking for ANSI C header files... (cached) yes
> checking for sys/types.h... (cached) yes
> checking for sys/stat.h... (cached) yes
> checking for stdlib.h... (cached) yes
> checking for string.h... (cached) yes
> checking for memory.h... (cached) yes
> checking for strings.h... (cached) yes
> checking for inttypes.h... (cached) yes
> checking for stdint.h... (cached) yes
> checking for unistd.h... (cached) yes
> checking minix/config.h usability... no
> checking minix/config.h presence... no
> checking for minix/config.h... no
> checking whether it is safe to define __EXTENSIONS__... yes
> checking for library containing strerror... none required
> checking for gcc... (cached) cc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether cc accepts -g... (cached) yes
> checking for cc option to accept ISO C89... (cached) none needed
> checking dependency style of cc... (cached) gcc3
> checking whether cc understands -c and -o together... yes
> checking for ANSI C header files... (cached) yes
> checking build system type... x86_64-unknown-openbsd5.4
> checking host system type... x86_64-unknown-openbsd5.4
> checking how to print strings... print -r
> checking for a sed that does not truncate ou

Re: ERROR: devel/gobject-introspection

[Stuart Henderson]

On 2013/09/30 17:21, Rafael Sadowski wrote:
> On Mon Sep 30, 2013 at 01:49:31PM +0100, Stuart Henderson wrote:
> > Your base OS is too old.
> 
> OpenBSD 5.4-current (GENERIC.MP) #59: Tue Sep 17 08:43:41 MDT 2013
> 
> ... is too old. Damn! Okay, thanks Stuart.

yes, recently there were changes to struct proc, a couple of ports
were modified to cope with this.

Re: p5-EV "for module EV: Cannot load specified object" on 5.3 amd64

[Stuart Henderson]

On 2013/09/30 09:40, Dustin Lundquist wrote:
> Test
> ># perl -e 'use EV;'
> >Can't load '/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/EV/EV.so' 
> >for module EV: Cannot load specified object at 
> >/usr/libdata/perl5/XSLoader.pm line 70.
> > at /usr/local/libdata/perl5/site_perl/amd64-openbsd/EV.pm line 86
> >BEGIN failed--compilation aborted at 
> >/usr/local/libdata/perl5/site_perl/amd64-openbsd/EV.pm line 87.
> >Compilation failed in require at -e line 1.
> >BEGIN failed--compilation aborted at -e line 1.
> 

IIRC it needs LD_PRELOAD=libpthread.so to be set in the environment.
Due to changes in perl in OpenBSD, this is no longer necessary with 5.4 / 
-current.

Re: update: vim 7.4.31

[Stuart Henderson]

On 2013/09/23 14:36, Liviu Daia wrote:
> On 23 September 2013, Stuart Henderson  wrote:
> 
> It's the new non-backtracking regexp engine at work (see ":help
> new-regexp-engine").  It's supposed to be faster than the old one for
> complex patterns, but in practice it can be 10+ times slower for things
> like syntax highlighting. :) You can turn it off completely with
> 
> set re = 1

Ah: I've tracked this down further. It's a combination of the new regexp
engine and malloc flag 'J'.

Does anyone have opinions on patching options.c to change the default to
re=1? (easily done; updated port diff at http://junkpile.org/vim.diff does
this and updates to a newer version from Mercurial).

Re: xkb-qwerty-fr

[Stuart Henderson]

On 2013/10/01 12:20, Jérémie Courrèges-Anglas wrote:
> 
> Here's an old mail...
> 
> Tristan Le Guern  writes:
> 
> > Hi,
> 
> Hi Tristan,
> 
> > This is an updated version of my previous submission of xbk-qwerty-fr.
> > The keymap file is now installed under
> > "/usr/local/share/X11/xkb/symbols/us_qwerty-fr" and then @sample'd to
> > "/usr/X11R6/share/X11/xkb/symbols/us_qwerty-fr".
> >
> > Ok?
> 
> Hmm, almost.  I wouldn't use ${PREFIX}/share/doc/${PKGNAME}, but
> ${PREFIX}/share/doc/xkb-qwerty-fr/ in do-install.  This way the path
> doesn't change with updates, and the make update-plist won't try to use
> ${FULLPKGNAME} (which is wrong).  But I can fix this before importing.
> 
> I'd like to hear at least another porter about the /usr/X11R6 handling.
> Does @sample make sense?  That's the only way we found for setxkbmap to
> work.

I'm not totally keen on a port installing files into /usr/X11R6, does
a symlink work? If so, we could ask people to add that themselves (a quick
1-line MESSAGE would probably be enough for this).

Re: subtitles on vlc

[Stuart Henderson]

[re: "main xml reader error: XML reader not found" playing files with subtitles]

On 2013/07/06 08:39, Stuart Henderson wrote:
> On 2013/07/05 19:36, Amit Kulkarni wrote:
> > ktrace doesn't point to anything
> 
> You just included the output where it prints the errors.
> There might be something in the pages before this.
> Using ktrace -B will skip some spam.
> 
> Also try running with LD_DEBUG set in the environment and look for
> failures.
> 

I've just noticed this too. I've got a bit more debug output but not
really much further.

Tested building a new package with vlc's .la files included as a test,
no difference.

Running with LD_DEBUG set causes playback to fail, vlc hangs and
needs a kill -9, though it does attempt to load subtitles before this
and fails in a similar-looking way, output at
http://junkpile.org/vlc-subtitle.txt (search for "not found") -
no errors noticed from ld.so.  (The "attempt to dlopen `...`"
lines are from a local patch to vlc).

NEW: www/urlwatch

[Stuart Henderson]

-- -- --
Comment:
monitor webpages for updates

Description:
This script is intended to help you watch URLs and get notified (via
email or in your terminal) of any changes. The change notification will
include the URL that has changed and a unified diff of what has changed.

The script supports the use of a filtering hook function to strip
trivially-varying elements of a webpage.
-- -- --

tgz includes www/urlwatch and its required dependency, devel/py-futures.
OK to import?

Re: NEW: www/urlwatch

[Stuart Henderson]

On 2013/10/02 00:33, Stuart Henderson wrote:
> -- -- --
> Comment:
> monitor webpages for updates
> 
> Description:
> This script is intended to help you watch URLs and get notified (via
> email or in your terminal) of any changes. The change notification will
> include the URL that has changed and a unified diff of what has changed.
> 
> The script supports the use of a filtering hook function to strip
> trivially-varying elements of a webpage.
> -- -- --
> 
> tgz includes www/urlwatch and its required dependency, devel/py-futures.
> OK to import?
> 

Now with 100% more tgz!


urlwatch.tgz
Description: application/tar-gz

Re: UPDATE: claws-mail 3.9.2

[Stuart Henderson]

On 2013/10/02 11:21, Ido Admon wrote:
> It was a peachy Wednesday, Oct 2 2013, 15:00:03, when Landry Breuil
> wrote:
> 
> > On Tue, Oct 01, 2013 at 02:36:44PM -0400, ido...@gmail.com wrote:
> > > ok here's a version with only one subpackage, the htmlviewer, and
> > > FULLPKGNAME
> > etc. \
> > > i can't really get webkit to build atm, so i can't test much.
> > 
> > I dont think stuart meant this, it was rather an issue with the
> > flavors handling. I think we need to keep those subpackages as they
> > are for dependency reasons, just fix the  pkgnames for flavoured
> > builds.
> > 
> > Landry
> 
> well, since the bogofilter and the spamassasing don't have any
> LIB_DEPENDS, only RUN_DEPENDS, how about putting them in (another...)
> flavor? "spamfilters" maybe?

IIRC quirks isn't enough to handle merging two old subpackages into one new
one. Rolling into the main package should work though spamassassin is a fairly
hefty set of dependencies, more than many users would want I think.

I would suggest keeping the original bogofilter/spamassassin subpackages
and just overwriting FULLPKGNAME/FULLPKGPATH..

Re: UPDATE: claws-mail 3.9.2

[Stuart Henderson]

On 2013/10/02 19:09, Ido Admon wrote:
> 
> 
> It was a peachy Wednesday, Oct  2 2013, 21:46:01 when Stuart Henderson
>  wrote:
> 
> > On 2013/10/02 11:21, Ido Admon wrote:
> > > It was a peachy Wednesday, Oct 2 2013, 15:00:03, when Landry Breuil
> > > wrote:
> > > 
> > > > On Tue, Oct 01, 2013 at 02:36:44PM -0400, ido...@gmail.com wrote:
> > > > > ok here's a version with only one subpackage, the htmlviewer,
> > > > > and FULLPKGNAME
> > > > etc. \
> > > > > i can't really get webkit to build atm, so i can't test much.
> > > > 
> > > > I dont think stuart meant this, it was rather an issue with the
> > > > flavors handling. I think we need to keep those subpackages as
> > > > they are for dependency reasons, just fix the  pkgnames for
> > > > flavoured builds.
> > > > 
> > > > Landry
> > > 
> > > well, since the bogofilter and the spamassasing don't have any
> > > LIB_DEPENDS, only RUN_DEPENDS, how about putting them in
> > > (another...) flavor? "spamfilters" maybe?
> > 
> > IIRC quirks isn't enough to handle merging two old subpackages into
> > one new one. Rolling into the main package should work though
> > spamassassin is a fairly hefty set of dependencies, more than many
> > users would want I think.
> > 
> > I would suggest keeping the original bogofilter/spamassassin
> > subpackages and just overwriting FULLPKGNAME/FULLPKGPATH..
> > 
> 
> 
> wouldn't they be in the main package if they're a FLAVOR?

FLAVOR is where some files which are always built (for example the main
binary) changes depending on build options (for example, the ldap
flavour where the main binary is linked to the openldap libraries).

Subpackages are used where some files are *only* built if you use certain
build options, and the main program can run without them (for example,
plugin modules).

When a build option just chooses whether or not to build a plugin module,
we use subpackages. If we did this using flavours we would need to build
the whole program several times over with different combinations of options,
and most of it would be the same, there would just be some extra parts in
some of the builds..

With subpackages we build once, and the user chooses which parts they want
at install time.

So, these wouldn't be FLAVORs at all.

Re: UPDATE devel/droplet 2.0

[Stuart Henderson]

> +DISTFILES=   v${VERSION}.tar.gz

This filename isn't suitable, you can use something like this to have it 
renamed:

DISTFILES=  droplet-${VERSION}.tar.gz{v${VERSION}.tar.gz}

Re: New Port - facebook phabricator

[Stuart Henderson]

On 2013/10/07 13:26, Gabriel Guzman wrote:
> 
> I'm working on a port of phabricator (phabricator.org), facebook's bug 
> tracking, code review, wiki, etc software.  They don't release any versions 
> at the
> moment, or have any tags so I can't get a version number for my
> Makefile.  I'm looking for other examples of software like this in the
> ports tree to see what the best approach would be, right now my Makefile
> looks like this: 
> 
> # $OpenBSD: Makefile,v 1.45 2013/03/11 11:44:50 espie Exp $
> 
> COMMENT =   code review, repository browser, bug tracker and wiki
> 
> DISTNAME =  master
> CATEGORIES =www
> 
> HOMEPAGE =  http://phabricator.org/
> MAINTAINER =Gabriel Guzman 
> 
> # Apache
> #PERMIT_PACKAGE_CDROM = Yes
> 
> MASTER_SITES =  https://github.com/facebook/phabricator/archive/
> 
> MODULES =   lang/php
> 
> RUN_DEPENDS =   lang/php/${MODPHP_VERSION},-mysql
> 
> NO_BUILD =  Yes
> NO_TEST =   Yes
> PKG_ARCH =  *
> 
> PREFIX =/var/www
> INSTDIR =   ${PREFIX}/phabricator
> WRKDIST =   ${WRKDIR}/phabricator
> 
> SUBST_VARS =INSTDIR
> 
> do-install:
> ${INSTALL_DATA_DIR} ${PREFIX}/phabricator
> cd ${WRKSRC} && pax -rw * ${PREFIX}/phabricator
> 
> .include 
> 
> 
> But, that results in make fetch-all creating a file called
> master.tar.gz, which is less than useful.  
> 
> I'm going to try the filename{url} approach to see if that works better,
> but then I'm not sure what to use as a number scheme for the version of
> phabricator... do I just make something up since upstream does not
> provide a version number? 
> 
> Any pointers (RTFM's etc) appreciated.
> 
> Thanks,
> gabe.
> 

You can't just use master, you need to pick a commit id instead.
I would normally use DISTNAME=phabricator-0.20131007 or something..

Re: Fix for textproc/meldm

[Stuart Henderson]

yes, so please mention sem_open in the patch file so grep can find it.

David Coppa  wrote:
>On Mon, Oct 7, 2013 at 5:49 PM, Alexandr Shadchin
> wrote:
>
>> ImportError: This platform lacks a functioning sem_open
>implementation, therefore, the required synchronization primitives
>needed will not function, see issue 3770.
>
>as a side note, sem_open() will eventually hit openbsd in a
>not-so-distant future...

Re: NEW: archivers/lzip

[Stuart Henderson]

On 2013/10/08 02:12, Juan Francisco Cantero Hurtado wrote:
> > > Nearly there, just a couple of things:
> > > 
> > > - In lzlib, you patched away the run_ldconfig=no line; this should stay.
> > 
> > I trimmed the conditional because the script uses "ldconfig -n" and our
> > ldconfig doesn't support this option. From the man page of ldconfig on
> > Linux:
> > 
> > -n Only  process  directories  specified  on  the  command  line.  Don't
> >process the trusted directories (/lib and /usr/lib) nor those specified
> >in /etc/ld.so.conf. Implies -N.
> > 
> > -N Don't rebuild the cache. Unless -X is also specified, links are
> >still updated.
> > 
> > I don't know which is the correct ldconfig command here.

It is not correct to run any ldconfig command during a port build :)
Looks like this is now working correctly.

> > > Also please patch away the line which creates a symlink to liblzip.so and
> > > regenerate the PLIST (and remove PFRAG.shared and the %%shared%% line).
> > 
> > Done.

The PLIST/PFRAG.shared look better, but it still creates the symlink
during build, so "make plist" re-adds them.

Re: Update: databases/p5-ldap

[Stuart Henderson]

On 2013/10/09 15:08, Tristan Le Guern wrote:
> Hello,
> 
> Here is an update for p5-ldap to version 0.57. I have tested it
> lightly and it works for my use case.

> Index: Makefile
> ===
> RCS file: /cvs/ports/databases/p5-ldap/Makefile,v
> retrieving revision 1.33
> diff -u -p -r1.33 Makefile
> --- Makefile11 Mar 2013 02:52:07 -  1.33
> +++ Makefile9 Oct 2013 13:06:09 -
> @@ -2,19 +2,19 @@
> 
>  COMMENT=   client interface to LDAP servers
> 
> -VERSION=   0.4001
> +VERSION=   0.57

because the version number goes "backwards" this requires an EPOCH bump
i.e. add 'EPOCH=0'.

>  DISTNAME=  perl-ldap-${VERSION}
>  PKGNAME=   p5-ldap-${VERSION}
> -REVISION=  1
>  CATEGORIES=databases
>  MODULES=   cpan
>  USE_GROFF =Yes

USE_GROFF can be removed too.

committed it with these changes..

Re: qt4 apps broken

[Stuart Henderson]

On 2013/10/09 16:03, Sébastien Marie wrote:
> Hi,
> 
> I just upgrade my ports to -current (dmesg below), but I have problems
> with qt4 applications.
> 
> For example, starting qtconfig4 (which is packaged in qt4-4.8.5) result
> of X11 error:

Confirmed (and on amd64 here, so it's not just a problem with a particular
pkg snap).


> $ qtconfig4
> X Error: BadAccess (attempt to access private resource denied) 10
>   Extension:130 (MIT-SHM)
>   Minor opcode: 1 (X_ShmAttach)
>   Resource id:  0x180
> X Error: BadShmSeg (invalid shared segment parameter) 128
>   Extension:130 (MIT-SHM)
>   Minor opcode: 5 (X_ShmCreatePixmap)
>   Resource id:  0x81
> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode: 62 (X_CopyArea)
>   Resource id:  0x1800010
> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode: 62 (X_CopyArea)
>   Resource id:  0x1800010
> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode: 62 (X_CopyArea)
>   Resource id:  0x1800010
> ...
> 
> and the window is just a plain rectangle...
> 
> Same problem occurs for others qt4 applications (as vlc or keepassx).
> 
> Is it a known problem ? or it is just me ?
> 
> I don't think about dependency problem as qtconfig4 is affected too, and
> my system seems clean (pkg_check ok, no .libs-qt4-*).
> 
> Thanks for your help.
> -- 
> Sébastien Marie
> 
> 
> 
> OpenBSD 5.4-current (GENERIC.MP) #70: Tue Oct  1 12:57:28 MDT 2013
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Genuine Intel(R) CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
> real mem  = 2137399296 (2038MB)
> avail mem = 2090733568 (1993MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 06/13/07, BIOS32 rev. 0 @ 0xffa10, 
> SMBIOS rev. 2.4 @ 0xf7980 (44 entries)
> bios0: vendor Dell Inc. version "A17" date 06/13/2007
> bios0: Dell Inc. MM061
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG SLIC BOOT SSDT
> acpi0: wakeup devices LID_(S3) PBTN(S4) MBTN(S5) PCI0(S3) USB0(S0) USB1(S0) 
> USB2(S0) USB3(S0) EHCI(S0) AZAL(S3) PCIE(S4) RP01(S4) RP02(S3) RP03(S3) 
> RP04(S3) RP05(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 166MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Genuine Intel(R) CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz
> cpu1: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 2
> acpimcfg0 at acpi0 addr 0xf000, bus 0-63
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 3 (PCIE)
> acpiprt3 at acpi0: bus 11 (RP01)
> acpiprt4 at acpi0: bus -1 (RP02)
> acpiprt5 at acpi0: bus -1 (RP03)
> acpiprt6 at acpi0: bus 12 (RP04)
> acpiprt7 at acpi0: bus -1 (RP05)
> acpiprt8 at acpi0: bus -1 (RP06)
> acpicpu0 at acpi0: C3, C2, C1, PSS
> acpicpu1 at acpi0: C3, C2, C1, PSS
> acpitz0 at acpi0: critical temperature is 126 degC
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model " DELLUD2649" serial 878 type LION oem "Sanyo"
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: PBTN
> acpibtn2 at acpi0: SBTN
> acpivideo0 at acpi0: VID_
> acpivideo1 at acpi0: VID_
> acpivout0 at acpivideo1: LCD_
> acpivideo2 at acpi0: VID2
> bios0: ROM list: 0xc/0xe800! 0xce800/0x1800
> cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
> vga1 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
> intagp0 at vga1
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0 at vga1
> drm0 at inteldrm0
> inteldrm0: 1280x800
> wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi
> azalia0: codecs: Sigmatel STAC9200, Conexant/0x2bfa, using Sigmatel STAC9200
> audio0 at azalia0
> ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 2 int 16
> pci1 at ppb0 bus 11
> wpi0 at pci1 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: msi, 
> MoW2, address 00:13:02:2e:8b:46
> ppb1 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 2 int 19
> pci2 at ppb1 bus 12
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 20
> uhci1 at pci0 dev 29 functi

Re: qt4 apps broken

[Stuart Henderson]

I'm using xdm, wm is cwm, new mesa, packages built against new mesa, inteldrm

Matthieu Herrb  wrote:
>On Wed, Oct 09, 2013 at 04:47:41PM +0200, Giovanni Bechis wrote:
>> On 10/09/13 16:32, Stuart Henderson wrote:
>> > On 2013/10/09 16:03, Sébastien Marie wrote:
>> >> Hi,
>> >>
>> >> I just upgrade my ports to -current (dmesg below), but I have
>problems
>> >> with qt4 applications.
>> >>
>> >> For example, starting qtconfig4 (which is packaged in qt4-4.8.5)
>result
>> >> of X11 error:
>> > 
>> > Confirmed (and on amd64 here, so it's not just a problem with a
>particular
>> > pkg snap).
>> >
>> With this snapshot and inteldrm is working fine:
>> OpenBSD 5.4-current (GENERIC.MP) #65: Thu Oct  3 18:48:14 MDT 2013
>
>How are you starting X (xdm, gdm, startx, ... ? )

Re: qt4 apps broken

[Stuart Henderson]

Temporary workaround until we can fix this:

Set QT_X11_NO_MITSHM=1 in the environment

Re: qt4 apps broken

[Stuart Henderson]

> > 
> > - Change all shmget calls to user-only memory (security)
> >
> > So yes, the problem is due to qt4, which use more strict permissions
> > for shmget.
> 
> The aforementioned change was done to fix CVE-2013-0254.
> 
> Here's the commit:
> 
> https://qt.gitorious.org/qt/qt/commit/20b26bdb3dd5e46b01b9a7e1ce8342074df3c89c?format=patch
> 
> So what now? Revert a security fix?

Debian ran into this with kfreebsd, they have applied this to xserver

http://people.debian.org/~jcristau/kbsd-peercred.diff

Re: UPDATE: the_silver_searcher to 0.17

[Stuart Henderson]

On 2013/10/09 22:11, Florian Stinglmayr wrote:
> On Mon, Sep 30, 2013 at 05:56:19PM +0200, Florian Stinglmayr wrote:
> > Hi list,
> >
> > attached is a patch to update the_silver_searcher to 0.17. Upstream does
> > now provide proper release tarballs (so no more configure required), yet
> > the bash completion script still goes in the wrong place.
> >
> > OK?
> 
> Ping?
> 

This was commited ~10 days ago.

Re: qt4 apps broken

[Stuart Henderson]

On 2013-10-10, Lars Engblom  wrote:
> This problem is affecting Minitube. Before the workaround, all you get 
> is an empty window. This workaround makes it possible to search for 
> clip, but you are still not able to watch them. You only hear the sound.
>
> On 10/09/13 22:50, Stuart Henderson wrote:
>> Temporary workaround until we can fix this:
>>
>> Set QT_X11_NO_MITSHM=1 in the environment
>>
>
>

How does 'ipcs -a' look when playing from Minitube?
This (including video playback in minitube) does work for me and others.

Re: UPDATE: darkstat 3.0.717

[Stuart Henderson]

On 2013/10/10 23:00, Remi Locherer wrote:
> On Thu, Oct 03, 2013 at 11:32:59PM -0400, Brad Smith wrote:
> > Here is an update to darkstat 3.0.717.
> > 
> > One nice new feature is darkstat can now monitor multiple interfaces.
> > 
> > OK?
> 
> Works for me on amd64. I added an rc.d script for convenience.

If you're adding a script, I think it also needs a readme to explain
that the user must set darkstat_flags="-i "

Brad, update is ok with me, let's deal with the script separately.

Re: UPDATE: darkstat 3.0.717

[Stuart Henderson]

On 2013/10/14 22:58, Remi Locherer wrote:
> On Sun, Oct 13, 2013 at 12:03:41AM +0200, Antoine Jacoutot wrote:
> > On Sat, Oct 12, 2013 at 03:29:01PM +0200, Remi Locherer wrote:
> > > On Fri, Oct 11, 2013 at 10:02:08AM +0100, Stuart Henderson wrote:
> > > > On 2013/10/10 23:00, Remi Locherer wrote:
> > > > > On Thu, Oct 03, 2013 at 11:32:59PM -0400, Brad Smith wrote:
> > > > > > Here is an update to darkstat 3.0.717.
> > > > > > 
> > > > > > One nice new feature is darkstat can now monitor multiple 
> > > > > > interfaces.
> > > > > > 
> > > > > > OK?
> > > > > 
> > > > > Works for me on amd64. I added an rc.d script for convenience.
> > > > 
> > > > If you're adding a script, I think it also needs a readme to explain
> > > > that the user must set darkstat_flags="-i "
> > > > 
> > > > Brad, update is ok with me, let's deal with the script separately.
> > > > 
> > > 
> > > Here a patch that adds an rc script and a readme.
> > 
> > That is a pretty useless readme imho

I disagree as it does show the user how to set the interface..

> Maybe it's better to have an rc script with default flags and no readme. 
> The new diff works as long as there is an egress interface.

It's useful to have this as a default, but I think the instructions are
still needed as this might get the wrong egress interface (e.g. for
people who have default IPv4 and IPv6 routes pointing over different
interfaces and the "wrong" one is first - or, uh, no interface if it
uses dhcpd and the server is down ;-)

> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/darkstat/Makefile,v
> retrieving revision 1.20
> diff -u -p -r1.20 Makefile
> --- Makefile11 Oct 2013 17:23:16 -  1.20
> +++ Makefile14 Oct 2013 20:53:04 -
> @@ -3,6 +3,7 @@
>  COMMENT=   network statistics gatherer with graphs
>  
>  DISTNAME=  darkstat-3.0.717
> +REVISION=  1

not really important, but 0 is normal for the first REVISION after
a version update.

> +#
> +# $OpenBSD$
> +
> +egress_if=$( ifconfig egress 2>/dev/null | head -1 | cut -d : -f 1 )
> +
> +daemon="/usr/local/sbin/darkstat"
> +daemon_flags="-i $egress_if -b 127.0.0.1 --syslog"
> +
> +. /etc/rc.d/rc.subr
> +
> +rc_reload=NO
> +
> +rc_cmd $1
> 

Re: editors/vim: new python3 flavor

[Stuart Henderson]

On 2013/10/13 18:52, Juan Francisco Cantero Hurtado wrote:
> This patch adds a python3 flavor to vim. OK?.

OK. Please also make sure it's linked to the build somehow,
probably best to duplicate the "vim,gtk2,perl,python,ruby" and
"vim,no_x11,perl,python,ruby" lines in editors/Makefile and
s/python/python3.

Re: youtube-dl-2013.10.15 (featuring a bunch of new extractors)

[Stuart Henderson]

On 2013/10/15 13:23, David Coppa wrote:
>  COMMENT =command-line program to download videos from YouTube.com
>  
>  lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canalc2.pyc
>  lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canalplus.py
>  lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/canalplus.pyc
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/cinemassacre.py
> +lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/cinemassacre.pyc
>  lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/cnn.py
>  lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/cnn.pyc
>  lib/python${MODPY_VERSION}/site-packages/youtube_dl/extractor/collegehumor.py
[etc etc]

I didn't notice before, but it seems that this software has a
poorly-chosen name ;-)  How about updating COMMENT and DESCR to indicate
that it actually handles quite a wide range of sites?

Re: ***UNCHECKED*** Re: New Port - facebook phabricator

[Stuart Henderson]

You need an @cwd as done in various other ports in www/ which override PREFIX. 
"make plist" won't help with this.

Please don't send an email to the list with multi-megabyte attachments, they 
aren't even useful, send the tarred *port* instead.

Gabriel Guzman  wrote:
>Here's my latest attempt, make files for the 3 packages below, and .tgz
>packages attached... I can't seem to get pkg_readmes to install
>however.
>I have pkg/README created, and make fake installs it: 
>
>Installing /usr/ports/www/phabricator/pkg/README as
>/usr/ports/pobj/phabricator-0.20131007/fake-amd64/usr/local/share/doc/pkg-readmes/phabricator-0.20131007
>
>But then make plist gives me this: 
>
>make-plist: Bogus element outside of every prefix:
>/usr/local/share/doc/pkg-readmes/phabricator-0.20131007
>pkg/PLIST is new
>007/fake-amd64/usr/local/share/doc/pkg-readmes/phabricator-0.20131007
><
>/usr/ports/pobj/phabricator-0.20131007/fake-amd64/usr/local/share/doc/pkg-readmes/phabricator-0.20131007
>
>And when I do make install, I don't get a fancy message telling me to
>check pkg-readmes for more information, and no readme is installed.  
>
>Any pointers?
>
>Thanks,
>gabe.
>
># $OpenBSD: Makefile,v 1.45 2013/03/11 11:44:50 espie Exp $
>
>COMMENT =   code review, repository browser, bug tracker and wiki
>
>COMMIT_ID = 68c854b9673e0e51296daccfeb41884e79ebf77b
>DUMMY_VER = 0.20131007
>DISTNAME =  phabricator-${DUMMY_VER}
>DISTFILES = phabricator-${DUMMY_VER}{${COMMIT_ID}.tar.gz}
>CATEGORIES =www devel
>
>HOMEPAGE =  http://phabricator.org/
>MAINTAINER =Gabriel Guzman 
>
># Apache
>PERMIT_PACKAGE_CDROM =  Yes
>
>MASTER_SITES =  http://github.com/facebook/phabricator/archive/
>
>MODULES =   lang/php
>
>RUN_DEPENDS =   lang/php/${MODPHP_VERSION},-mysqli \
>lang/php/${MODPHP_VERSION},-curl \
>lang/php/${MODPHP_VERSION},-fastcgi \
>lang/php/${MODPHP_VERSION},-pcntl \
>www/arcanist \
>www/libphutil
>
>NO_BUILD =  Yes
>NO_TEST =   Yes
>PKG_ARCH =  *
>
>PREFIX =/var/www
>INSTDIR =   ${PREFIX}/phabricator
>WRKDIST  =  ${WRKDIR}/phabricator-${COMMIT_ID}/
>
>SUBST_VARS =INSTDIR
>
>do-install:
>${INSTALL_DATA_DIR} ${PREFIX}/phabricator
>cd ${WRKSRC} && pax -rw * ${PREFIX}/phabricator
>
>.include 
>
>
>
># $OpenBSD: Makefile,v 1.45 2013/03/11 11:44:50 espie Exp $
>
>COMMENT =   cli to phabricator
>
>COMMIT_ID = 13e422e123fed10cfa7e4962ae19ccd39f712e1c
>DUMMY_VER = 0.20131007
>DISTNAME =  arcanist-${DUMMY_VER}
>DISTFILES = arcanist-${DUMMY_VER}{${COMMIT_ID}.tar.gz}
>CATEGORIES =www devel
>
>HOMEPAGE =  http://phabricator.org/
>MAINTAINER =Gabriel Guzman 
>
># Apache
>PERMIT_PACKAGE_CDROM =  Yes
>
>MASTER_SITES =  http://github.com/facebook/arcanist/archive/
>
>MODULES =   lang/php
>
>NO_BUILD =  Yes
>NO_TEST =   Yes
>PKG_ARCH =  *
>
>PREFIX =/var/www
>INSTDIR =   ${PREFIX}/arcanist
>WRKDIST  =  ${WRKDIR}/arcanist-${COMMIT_ID}/
>
>SUBST_VARS =INSTDIR
>
>do-install:
>${INSTALL_DATA_DIR} ${PREFIX}/arcanist
>cd ${WRKSRC} && pax -rw * ${PREFIX}/arcanist
>
>.include 
>
>
>
># $OpenBSD: Makefile,v 1.45 2013/03/11 11:44:50 espie Exp $
>
>COMMENT =   collection of PHP utility classes for phabricator
>
>COMMIT_ID = 944738bdf93751d11f20f6aa6dc2e4e62d86a308
>DUMMY_VER = 0.20131007
>DISTNAME =  libphutil-${DUMMY_VER}
>DISTFILES = libphutil-${DUMMY_VER}{${COMMIT_ID}.tar.gz}
>CATEGORIES =www devel
>
>HOMEPAGE =  http://phabricator.org/
>MAINTAINER =Gabriel Guzman 
>
># Apache
>PERMIT_PACKAGE_CDROM =  Yes
>
>MASTER_SITES =  http://github.com/facebook/libphutil/archive/
>
>MODULES =   lang/php
>
>NO_BUILD =  Yes
>NO_TEST =   Yes
>PKG_ARCH =  *
>
>PREFIX =/var/www
>INSTDIR =   ${PREFIX}/libphutil
>WRKDIST  =  ${WRKDIR}/libphutil-${COMMIT_ID}/
>
>SUBST_VARS =INSTDIR
>
>do-install:
>${INSTALL_DATA_DIR} ${PREFIX}/libphutil
>cd ${WRKSRC} && pax -rw * ${PREFIX}/libphutil
>
>.include 

Re: Minidlna docs

[Stuart Henderson]

On 2013/10/16 22:25, Ed Ahlsen-Girard wrote:
> I just installed this package (14 October snapshot) and there's no man
> page, no info page, and the README and INSTALL don't seem to have
> anything about how to use the software.
> 
> Where are the docs?
> 
> -- 
> 
> Edward Ahlsen-Girard
> Ft Walton Beach, FL
> 

There isn't anything worth installing really, but it should be fairly
self-explanatory from the sample config.

Re: let's remove www/mod_dav

[Stuart Henderson]

On 2013/10/18 11:00, Stefan Sperling wrote:
> The www/mod_dav port for base httpd is shipping ancient and
> unsupported code from webdav.org.

OK to remove it, there are some places where running 12 year old code
could make sense but this isn't one of them.

mutt 1.5.22

[Stuart Henderson]

tests wanted, especially from anybody using the £&$^"$&"! sidebar patch.

Index: Makefile
===
RCS file: /cvs/ports/mail/mutt/snapshot/Makefile,v
retrieving revision 1.78
diff -u -p -r1.78 Makefile
--- Makefile23 Aug 2013 16:40:29 -  1.78
+++ Makefile18 Oct 2013 11:33:13 -
@@ -2,9 +2,8 @@
 
 COMMENT=   tty-based e-mail client, development version
 
-DISTNAME=  mutt-1.5.21
+DISTNAME=  mutt-1.5.22
 EPOCH= 0
-REVISION=  5
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=mutt/} \
${MASTER_SITES_MUTT:=devel/}
 
@@ -29,11 +28,11 @@ WANTLIB+=   sasl2
 
 MUTTRCDIR= doc/
 
-DIST_COMPRESSED=compressed-5302767aa6aa.gz:2
-DIST_SIDEBAR=  sidebar-5302767aa6aa.gz:2
+DIST_COMPRESSED=compressed-1.5.22.diff0.gz:2
+DIST_SIDEBAR=  sidebar-1.5.22.diff0.gz:2
 
 # http://cedricduval.free.fr/mutt/patches/
-PATCHFILES+=   trashfolder-5302767aa6aa.gz:2
+PATCHFILES+=   trashfolder-1.5.22.diff0.gz:2
 
 .if ${FLAVOR:Msidebar}
 PATCHFILES+=   ${DIST_SIDEBAR}
@@ -43,7 +42,6 @@ SUPDISTFILES+=${DIST_SIDEBAR}
 
 AUTOMAKE_VERSION= 1.9
 CONFIGURE_STYLE= gnu
-USE_GROFF =Yes
 BUILD_DEPENDS+=${MODGNU_AUTOCONF_DEPENDS} \
${MODGNU_AUTOMAKE_DEPENDS}
 post-patch:
Index: distinfo
===
RCS file: /cvs/ports/mail/mutt/snapshot/distinfo,v
retrieving revision 1.35
diff -u -p -r1.35 distinfo
--- distinfo14 Mar 2013 10:14:10 -  1.35
+++ distinfo18 Oct 2013 11:33:13 -
@@ -1,8 +1,8 @@
-SHA256 (mutt/compressed-5302767aa6aa.gz) = 
wip+TwZMzA3Gu1WF5ZBR96hKvz6qfd5JalqB9bn/uB0=
-SHA256 (mutt/mutt-1.5.21.tar.gz) = IUHzbo0PT3HJymeAAB58xnn+MT5kOVP8B/ABIj5nxKA=
-SHA256 (mutt/sidebar-5302767aa6aa.gz) = 
TJdd4RHwJfmiM5hHKGKNmLEGCvpIVIvNBumPXN1Juh8=
-SHA256 (mutt/trashfolder-5302767aa6aa.gz) = 
Axw0VlOhhfUcvzg66Hj21wCJzwGllJrePo+S5flXtBg=
-SIZE (mutt/compressed-5302767aa6aa.gz) = 6315
-SIZE (mutt/mutt-1.5.21.tar.gz) = 3716886
-SIZE (mutt/sidebar-5302767aa6aa.gz) = 11762
-SIZE (mutt/trashfolder-5302767aa6aa.gz) = 2793
+SHA256 (mutt/compressed-1.5.22.diff0.gz) = 
sbVFGEmgnjazv6nHGqYurtVW6afvayUoHm+JrS3xkDs=
+SHA256 (mutt/mutt-1.5.22.tar.gz) = j+rokO0HWKUQi6+u8nvY/Jw3hnWs8lo8Yg8se3VA86c=
+SHA256 (mutt/sidebar-1.5.22.diff0.gz) = 
YYmttj4rGBQYil/wVRgLh1nkcAagQs5rx/BbRwm+kiE=
+SHA256 (mutt/trashfolder-1.5.22.diff0.gz) = 
zpZBRCZKfU8SHnomkrHqkuvqXwMIm//2lh1IXzM5w7g=
+SIZE (mutt/compressed-1.5.22.diff0.gz) = 6350
+SIZE (mutt/mutt-1.5.22.tar.gz) = 3782237
+SIZE (mutt/sidebar-1.5.22.diff0.gz) = 12234
+SIZE (mutt/trashfolder-1.5.22.diff0.gz) = 2747
Index: patches/patch-configure_ac
===
RCS file: /cvs/ports/mail/mutt/snapshot/patches/patch-configure_ac,v
retrieving revision 1.5
diff -u -p -r1.5 patch-configure_ac
--- patches/patch-configure_ac  8 Sep 2010 09:57:28 -   1.5
+++ patches/patch-configure_ac  18 Oct 2013 11:33:13 -
@@ -1,7 +1,7 @@
 $OpenBSD: patch-configure_ac,v 1.5 2010/09/08 09:57:28 sthen Exp $
 configure.ac.orig  Wed Aug 25 00:30:49 2010
-+++ configure.ac   Sat Sep  4 10:33:30 2010
-@@ -549,7 +549,7 @@ fi
+--- configure.ac.orig  Mon Apr 22 07:14:53 2013
 configure.ac   Fri Oct 18 09:58:16 2013
+@@ -550,7 +550,7 @@ fi
  AC_SUBST(docdir)
  
  if test x$mutt_cv_setgid = xyes; then
Index: patches/patch-doc_Makefile_am
===
RCS file: /cvs/ports/mail/mutt/snapshot/patches/patch-doc_Makefile_am,v
retrieving revision 1.2
diff -u -p -r1.2 patch-doc_Makefile_am
--- patches/patch-doc_Makefile_am   22 Oct 2010 17:00:20 -  1.2
+++ patches/patch-doc_Makefile_am   18 Oct 2013 11:33:13 -
@@ -1,7 +1,7 @@
 $OpenBSD: patch-doc_Makefile_am,v 1.2 2010/10/22 17:00:20 naddy Exp $
 doc/Makefile.am.orig   Tue Aug 25 21:08:52 2009
-+++ doc/Makefile.amFri Oct 22 18:45:59 2010
-@@ -161,8 +161,8 @@ update-doc: stamp-doc-xml stamp-doc-chunked stamp-doc-
+--- doc/Makefile.am.orig   Fri Oct 18 05:48:24 2013
 doc/Makefile.amFri Oct 18 09:58:16 2013
+@@ -165,8 +165,8 @@ update-doc: stamp-doc-xml stamp-doc-chunked stamp-doc-
  
  muttrc.man: makedoc$(EXEEXT) $(top_srcdir)/init.h muttrc.man.head 
muttrc.man.tail
$(MAKEDOC_CPP) $(top_srcdir)/init.h | ./makedoc$(EXEEXT) -m |   \
Index: patches/patch-muttlib_c
===
RCS file: patches/patch-muttlib_c
diff -N patches/patch-muttlib_c
--- patches/patch-muttlib_c 14 Mar 2013 10:14:10 -  1.4
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-muttlib_c,v 1.4 2013/03/14 10:14:10 sthen Exp $
-
-fix segfault when $message_cachedir is set and opening a POP3 mailbox.
-upstream 1a4c43138685, fixes bug#3457
-
 muttlib.c.orig Wed Mar 13 16:22:39 2013
-+++ muttlib.c  Wed Mar 13 16:22:40 2013
-@@ -1962,6 +196

Re: mutt 1.5.22

[Stuart Henderson]

On 2013/10/18 15:58, Landry Breuil wrote:
> On Fri, Oct 18, 2013 at 12:34:16PM +0100, Stuart Henderson wrote:
> > tests wanted, especially from anybody using the £&$^"$&"! sidebar patch.
> 
> Seems to work for me with the kitchensink flavor
> (sasl,sidebar,compressed,slang) - sidebar still works fine. It also reindexed
> all my mailboxes so i suppose it considers the headercache tainted by
> default upon upgrading.

It makes a checksum of the header cache struct, if this changes then
the cache is automatically invalidated.

> there seem to be an issue with the dropping of USE_GROFF, since i now
> have this for muttrc(5):
> Empty file /usr/local/man/man5/muttrc.5
> [15:50] dawn:/usr/ports/mystuff/mail/mutt/snapshot/ $man muttrc
> /usr/local/man/man5/muttrc.5:1:1: FATAL: not a manual

Do you have a log for a build showing this please? It's odd - though
I don't think it's related to dropping USE_GROFF (groff would have the
same problem as it just takes man5/muttrc.5 as input, so if that's
empty, there won't be any output from groff either).

Re: www/fennec & productivy/sunbird to the attic ?

[Stuart Henderson]

On 2013/10/18 20:02, Landry Breuil wrote:
> Hi,
> 
> just a headsup to potential www/fennec & productivity/sunbird users.. if
> there are some. Removing those ports would allow me to remove lots of
> cruft from mozilla.port.mk, and sanitize the mozilla builds. They're
> dead upstream & sortof unmaintained... so if you want to keep them,
> speak now or stay silent forever. lightning is the supported version of
> sunbird (but you need to run fullblown thunderbird) and fennec got
> switched to javacrap upstream for android, and thus doesnt build anymore
> on top of xul.
> 
> Landry
> 

I'm using OpenBSD on a dedicated machine for a wallboard calendar display,
- I knew there was a standalone version of the mozilla calendar but forgot what
it was called, so I just installed Thunderbird for this and it's working
perfectly well. I don't think there's any particular reason to continue with a
semi-maintained standalone port and if it's getting in your way, go ahead and
zap.

Fennec might be interesting on lower-powered machines but only if it's
reasonably up to date - Java is only really working properly on OpenBSD amd64
at the moment, and there's no real need for Fennec there, so probably not
useful to keep.

Re: NEW: games/xgalaga-sdl

[Stuart Henderson]

On 2013/10/18 23:18, Christian Weisgerber wrote:
> Anthony J. Bentley  wrote:
> 
> > XGalaga is a clone of the classic game Galaga for the X Window system.
> > XGalaga is a Space Invaders-like game with additional features to
> > produce a more interesting game.
> > 
> > Plays well on i386/amd64. ok?
> 
> Looks good, except when there is no ~/.xgalaga-sdl yet:
> 
> Trouble opening high scores file '/home/naddy/.xgalaga-sdl'
> Trouble opening high scores file '/home/naddy/.xgalaga-sdl'
> Trouble opening high scores file '/home/naddy/.xgalaga-sdl'
> Segmentation fault (core dumped) 

Is that the atexit segfault common in SDL programs?