CVS: cvs.openbsd.org: ports

2016-03-10 Thread Sebastien Marie
CVSROOT:/cvs
Module name:ports
Changes by: sema...@cvs.openbsd.org 2016/03/10 22:30:45

Modified files:
lang/rust  : Makefile 
lang/rust/patches: patch-configure 
Added files:
lang/rust/patches: patch-src_compiletest_runtest_rs 

Log message:
lang/rust: use devel/llvm for building

switch from embedded version of LLVM to system version.

OK juanfra@



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/03/10 19:27:01

Modified files:
textproc/calibre/patches: patch-setup_extensions_py 

Log message:
regen



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/03/10 19:27:26

Added files:
textproc/calibre/patches: patch-src_duktape_duktape_duk_config_h 

Log message:
attempt at fixing calibre build on sparc64



Re: [patch] productivity/slideml

2016-03-10 Thread Michael McConville
David Hill wrote:
> Hello -
> 
> This moves productivity/slideml to github.

It's strange that the old HOMEPAGE is still up and doesn't mention
GitHub at all. Do you know if upstream has a preference about which is
used?

> Index: Makefile
> ===
> RCS file: /cvs/ports/productivity/slideml/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile  25 Mar 2014 21:20:39 -  1.7
> +++ Makefile  11 Mar 2016 00:02:09 -
> @@ -2,20 +2,20 @@
>  
>  COMMENT =HTML slide generator based on SlideML
>  
> -DISTNAME =   slideml-1.1.0
> -REVISION =   0
> -
> +V =  1.1.0
> +REVISION =   1
> +GH_TAGNAME = SLIDEML_${V:S/./_/g}
> +GH_ACCOUNT = conformal
> +GH_PROJECT = slideml
> +DISTNAME =   ${GH_PROJECT}-${V}
>  CATEGORIES = productivity
>  
> -HOMEPAGE =   http://opensource.conformal.com/wiki/Slide_ML
> +HOMEPAGE =   https://github.com/conformal/slideml/wiki
>  
>  MAINTAINER = Laurent Fanis 
>  
>  #W3C Software Notice and License & BSD
>  PERMIT_PACKAGE_CDROM =   Yes
> -
> -MASTER_SITES =   
> http://opensource.conformal.com/snapshots/slideml/
> -EXTRACT_SUFX =   .tgz
>  
>  RUN_DEPENDS =graphics/p5-Image-Size 
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/productivity/slideml/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo  18 Jan 2015 03:14:59 -  1.3
> +++ distinfo  11 Mar 2016 00:02:09 -
> @@ -1,2 +1,2 @@
> -SHA256 (slideml-1.1.0.tgz) = RPCos9m9/bXNPhX+29p+k5yJiEBrtkm7HxGbiNN33ck=
> -SIZE (slideml-1.1.0.tgz) = 28245
> +SHA256 (slideml-1.1.0.tar.gz) = mT9/V83DDpcp1dlayIwORs7gdi32Mp1MEQpfkW7zgwc=
> +SIZE (slideml-1.1.0.tar.gz) = 28172
> 



Re: [patch] sysutils/diskrescue

2016-03-10 Thread Michael McConville
David Hill wrote:
> Hello -
> 
> This updates sysutils/diskrescue to 0.4 and moves it to github.
> The change between 0.3 and 0.4 is the patch has been applied. :).

Makes sense, and builds for me. ok mmcc@

> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/diskrescue/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- Makefile  16 Feb 2015 22:57:12 -  1.9
> +++ Makefile  11 Mar 2016 00:32:46 -
> @@ -2,12 +2,14 @@
>  
>  COMMENT =fancy dd
>  
> -DISTNAME =   diskrescue-0.3
> -REVISION =   1
> -
> +V =  0.4
> +GH_TAGNAME = DISKRESCUE_${V:S/./_/g}
> +GH_ACCOUNT = conformal
> +GH_PROJECT = diskrescue
> +DISTNAME =   ${GH_PROJECT}-${V}
>  CATEGORIES = sysutils
>  
> -HOMEPAGE =   http://opensource.conformal.com/wiki/Disk_Rescue
> +HOMEPAGE =   https://github.com/conformal/diskrescue/wiki
>  
>  MAINTAINER = Laurent Fanis 
>  
> @@ -15,10 +17,6 @@ MAINTAINER =   Laurent Fanis   PERMIT_PACKAGE_CDROM =   Yes
>  
>  WANTLIB =c
> -
> -MASTER_SITES =   
> http://opensource.conformal.com/snapshots/diskrescue/
> -
> -EXTRACT_SUFX =   .tgz
>  
>  NO_TEST= Yes
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/diskrescue/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo  18 Jan 2015 03:15:09 -  1.3
> +++ distinfo  11 Mar 2016 00:32:46 -
> @@ -1,2 +1,2 @@
> -SHA256 (diskrescue-0.3.tgz) = GHO70eRi8to/eGHl7Gbg7SvoAoIeZrucUjXd/5snfqo=
> -SIZE (diskrescue-0.3.tgz) = 6825
> +SHA256 (diskrescue-0.4.tar.gz) = loVdK0MDTegiHg8eTVzDaTpjod5airDGxS/GQek/gS0=
> +SIZE (diskrescue-0.4.tar.gz) = 6816
> Index: patches/patch-diskrescue_c
> ===
> RCS file: patches/patch-diskrescue_c
> diff -N patches/patch-diskrescue_c
> --- patches/patch-diskrescue_c15 Jun 2013 08:19:33 -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,121 +0,0 @@
> -$OpenBSD: patch-diskrescue_c,v 1.1 2013/06/15 08:19:33 sthen Exp $
>  diskrescue.c.origMon Sep 28 16:13:33 2009
> -+++ diskrescue.c Sat Jun 15 09:19:05 2013
> -@@ -44,15 +44,15 @@ static const char*cvstag = "$diskrescue: 
> diskrescue.c
> -  */
> - 
> - struct dr_hdr {
> --daddr64_t   disk_sz;
> --daddr64_t   block_sz;
> --charoutput[PATH_MAX];
> -+daddr_t disk_sz;
> -+daddr_t block_sz;
> -+charoutput[PATH_MAX];
> - };
> - 
> - struct dr_entry {
> --daddr64_t   offset;
> --daddr64_t   size;
> --chardigest[SHA1_DIGEST_LENGTH * 2 + 1];
> -+daddr_t offset;
> -+daddr_t size;
> -+chardigest[SHA1_DIGEST_LENGTH * 2 + 1];
> - };
> - 
> - /*
> -@@ -80,7 +80,7 @@ FILE   *resfd = stderr;
> - int quiet = 0;
> - int abort_on_error = 0;
> - volatile sig_atomic_t   running = 1;
> --daddr64_t   bs = DEV_BSIZE;
> -+daddr_t bs = DEV_BSIZE;
> - char*rawdev = NULL;
> - char*outfile = NULL;
> - char*infile = NULL;
> -@@ -143,7 +143,7 @@ hdr_read(FILE *f, struct dr_hdr *h)
> - }
> - 
> - int
> --ent_write(FILE *f, daddr64_t offset, daddr64_t sz, char *inbuf)
> -+ent_write(FILE *f, daddr_t offset, daddr_t sz, char *inbuf)
> - {
> - u_int8_tdigest[SHA1_DIGEST_LENGTH];
> - chardigest_text[SHA1_DIGEST_LENGTH * 2 + 1];
> -@@ -208,7 +208,7 @@ ent_read(FILE *f, FILE *outf, struct dr_entry *e)
> - }
> - 
> - int
> --rawsize(int fd, daddr64_t *size)
> -+rawsize(int fd, daddr_t *size)
> - {
> - #if defined(__OpenBSD__)
> - struct disklabeldl;
> -@@ -223,11 +223,11 @@ rawsize(int fd, daddr64_t *size)
> - #endif
> - }
> - 
> --daddr64_t
> -+daddr_t
> - getbs(char *val)
> - {
> --daddr64_t   num, t;
> --char*expr;
> -+daddr_t num, t;
> -+char*expr;
> - 
> - num = strtoul(val, , 0);
> - if (num == SIZE_T_MAX) /* Overflow. */
> -@@ -283,7 +283,7 @@ erange:  errx(1, "illegal block size: 
> %s", strerror(E
> - }
> - 
> - int
> --readoffset(daddr64_t offs, int fd, char *buf, daddr64_t bs)
> -+readoffset(daddr_t offs, int fd, char *buf, daddr_t bs)
> - {
> - int rv;
> - 
> -@@ -295,10 +295,10 @@ readoffset(daddr64_t offs, int fd, char *buf, daddr64_
> - }
> - 
> - int
> --recover(daddr64_t offs, int fd, char *buf, daddr64_t bs)
> -+recover(daddr_t offs, int fd, char *buf, daddr_t bs)
> - {
> --int rv = 

[patch] sysutils/diskrescue

2016-03-10 Thread David Hill
Hello -

This updates sysutils/diskrescue to 0.4 and moves it to github.
The change between 0.3 and 0.4 is the patch has been applied. :).

Index: Makefile
===
RCS file: /cvs/ports/sysutils/diskrescue/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile16 Feb 2015 22:57:12 -  1.9
+++ Makefile11 Mar 2016 00:32:46 -
@@ -2,12 +2,14 @@
 
 COMMENT =  fancy dd
 
-DISTNAME = diskrescue-0.3
-REVISION = 1
-
+V =0.4
+GH_TAGNAME =   DISKRESCUE_${V:S/./_/g}
+GH_ACCOUNT =   conformal
+GH_PROJECT =   diskrescue
+DISTNAME = ${GH_PROJECT}-${V}
 CATEGORIES =   sysutils
 
-HOMEPAGE = http://opensource.conformal.com/wiki/Disk_Rescue
+HOMEPAGE = https://github.com/conformal/diskrescue/wiki
 
 MAINTAINER =   Laurent Fanis 
 
@@ -15,10 +17,6 @@ MAINTAINER = Laurent Fanis http://opensource.conformal.com/snapshots/diskrescue/
-
-EXTRACT_SUFX = .tgz
 
 NO_TEST=   Yes
 
Index: distinfo
===
RCS file: /cvs/ports/sysutils/diskrescue/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:15:09 -  1.3
+++ distinfo11 Mar 2016 00:32:46 -
@@ -1,2 +1,2 @@
-SHA256 (diskrescue-0.3.tgz) = GHO70eRi8to/eGHl7Gbg7SvoAoIeZrucUjXd/5snfqo=
-SIZE (diskrescue-0.3.tgz) = 6825
+SHA256 (diskrescue-0.4.tar.gz) = loVdK0MDTegiHg8eTVzDaTpjod5airDGxS/GQek/gS0=
+SIZE (diskrescue-0.4.tar.gz) = 6816
Index: patches/patch-diskrescue_c
===
RCS file: patches/patch-diskrescue_c
diff -N patches/patch-diskrescue_c
--- patches/patch-diskrescue_c  15 Jun 2013 08:19:33 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,121 +0,0 @@
-$OpenBSD: patch-diskrescue_c,v 1.1 2013/06/15 08:19:33 sthen Exp $
 diskrescue.c.orig  Mon Sep 28 16:13:33 2009
-+++ diskrescue.c   Sat Jun 15 09:19:05 2013
-@@ -44,15 +44,15 @@ static const char  *cvstag = "$diskrescue: diskrescue.c
-  */
- 
- struct dr_hdr {
--  daddr64_t   disk_sz;
--  daddr64_t   block_sz;
--  charoutput[PATH_MAX];
-+  daddr_t disk_sz;
-+  daddr_t block_sz;
-+  charoutput[PATH_MAX];
- };
- 
- struct dr_entry {
--  daddr64_t   offset;
--  daddr64_t   size;
--  chardigest[SHA1_DIGEST_LENGTH * 2 + 1];
-+  daddr_t offset;
-+  daddr_t size;
-+  chardigest[SHA1_DIGEST_LENGTH * 2 + 1];
- };
- 
- /*
-@@ -80,7 +80,7 @@ FILE *resfd = stderr;
- int   quiet = 0;
- int   abort_on_error = 0;
- volatile sig_atomic_t   running = 1;
--daddr64_t bs = DEV_BSIZE;
-+daddr_t   bs = DEV_BSIZE;
- char  *rawdev = NULL;
- char  *outfile = NULL;
- char  *infile = NULL;
-@@ -143,7 +143,7 @@ hdr_read(FILE *f, struct dr_hdr *h)
- }
- 
- int
--ent_write(FILE *f, daddr64_t offset, daddr64_t sz, char *inbuf)
-+ent_write(FILE *f, daddr_t offset, daddr_t sz, char *inbuf)
- {
-   u_int8_tdigest[SHA1_DIGEST_LENGTH];
-   chardigest_text[SHA1_DIGEST_LENGTH * 2 + 1];
-@@ -208,7 +208,7 @@ ent_read(FILE *f, FILE *outf, struct dr_entry *e)
- }
- 
- int
--rawsize(int fd, daddr64_t *size)
-+rawsize(int fd, daddr_t *size)
- {
- #if defined(__OpenBSD__)
-   struct disklabeldl;
-@@ -223,11 +223,11 @@ rawsize(int fd, daddr64_t *size)
- #endif
- }
- 
--daddr64_t
-+daddr_t
- getbs(char *val)
- {
--  daddr64_t   num, t;
--  char*expr;
-+  daddr_t num, t;
-+  char*expr;
- 
-   num = strtoul(val, , 0);
-   if (num == SIZE_T_MAX) /* Overflow. */
-@@ -283,7 +283,7 @@ erange:errx(1, "illegal block size: 
%s", strerror(E
- }
- 
- int
--readoffset(daddr64_t offs, int fd, char *buf, daddr64_t bs)
-+readoffset(daddr_t offs, int fd, char *buf, daddr_t bs)
- {
-   int rv;
- 
-@@ -295,10 +295,10 @@ readoffset(daddr64_t offs, int fd, char *buf, daddr64_
- }
- 
- int
--recover(daddr64_t offs, int fd, char *buf, daddr64_t bs)
-+recover(daddr_t offs, int fd, char *buf, daddr_t bs)
- {
--  int rv = -1, sz;
--  daddr64_t   blocks, b;
-+  int rv = -1, sz;
-+  daddr_t blocks, b;
- 
-   blocks = bs / DEV_BSIZE;
-   if (bs % DEV_BSIZE)
-@@ -334,7 +334,7 @@ usage(void)
- }
- 
- void
--print_perc(daddr64_t size, daddr64_t offs, char *s, char *cr)
-+print_perc(daddr_t size, daddr_t offs, char *s, char *cr)
- {
-   double  p;
- 
-@@ 

[UPDATE] plan9/drawterm (switch to new source repository)

2016-03-10 Thread sl
One more time.

Supercedes most recent update. The original drawterm is effectively
abandoned by its author. This update switches to a new fork that is
currenlty being maintained against the 9front fork of Plan 9. Latest
revision from 20160310.

This update:

- fixes a glitch in graphics rendering, primarily noticed
when viewing images in the web browser mothra(1).

- defaults to new dp9ik authentication and rcpu(1) connection
method, devolving to the old p9sk1 and cpu(1).

- adds new cryptographic support from 9front libmp and libsec
libraries.

- adds support for 9front 

- enables audio support.

Also, updates my e-mail address from stanley.lie...@gmail.com
to s...@stanleylieber.com, because I am transitioning away from
Google services.

Tested only on 386 and amd64. Would appreciate testing on other platforms.

http://openbsd.stanleylieber.com/drawterm/drawterm-port-20160310.tgz

ok?

sl



[patch] productivity/slideml

2016-03-10 Thread David Hill
Hello -

This moves productivity/slideml to github.

Index: Makefile
===
RCS file: /cvs/ports/productivity/slideml/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile25 Mar 2014 21:20:39 -  1.7
+++ Makefile11 Mar 2016 00:02:09 -
@@ -2,20 +2,20 @@
 
 COMMENT =  HTML slide generator based on SlideML
 
-DISTNAME = slideml-1.1.0
-REVISION = 0
-
+V =1.1.0
+REVISION = 1
+GH_TAGNAME =   SLIDEML_${V:S/./_/g}
+GH_ACCOUNT =   conformal
+GH_PROJECT =   slideml
+DISTNAME = ${GH_PROJECT}-${V}
 CATEGORIES =   productivity
 
-HOMEPAGE = http://opensource.conformal.com/wiki/Slide_ML
+HOMEPAGE = https://github.com/conformal/slideml/wiki
 
 MAINTAINER =   Laurent Fanis 
 
 #W3C Software Notice and License & BSD
 PERMIT_PACKAGE_CDROM = Yes
-
-MASTER_SITES = http://opensource.conformal.com/snapshots/slideml/
-EXTRACT_SUFX = .tgz
 
 RUN_DEPENDS =  graphics/p5-Image-Size 
 
Index: distinfo
===
RCS file: /cvs/ports/productivity/slideml/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo18 Jan 2015 03:14:59 -  1.3
+++ distinfo11 Mar 2016 00:02:09 -
@@ -1,2 +1,2 @@
-SHA256 (slideml-1.1.0.tgz) = RPCos9m9/bXNPhX+29p+k5yJiEBrtkm7HxGbiNN33ck=
-SIZE (slideml-1.1.0.tgz) = 28245
+SHA256 (slideml-1.1.0.tar.gz) = mT9/V83DDpcp1dlayIwORs7gdi32Mp1MEQpfkW7zgwc=
+SIZE (slideml-1.1.0.tar.gz) = 28172



[patch] net/adsuck

2016-03-10 Thread David Hill
Hello -

This moves net/adsuck to github.

Index: Makefile
===
RCS file: /cvs/ports/net/adsuck/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile15 Jul 2015 14:59:15 -  1.29
+++ Makefile10 Mar 2016 23:55:18 -
@@ -2,18 +2,19 @@
 
 COMMENT=   DNS relay for ad blocking
 
-DISTNAME=  adsuck-2.5.0
+V= 2.5.0
+REVISION=  4
+GH_TAGNAME=ADSUCK_${V:S/./_/g}
+GH_ACCOUNT=conformal
+GH_PROJECT=adsuck
+DISTNAME=  ${GH_PROJECT}-${V}
 CATEGORIES=net
-REVISION=  3
 
-HOMEPAGE=  http://opensource.conformal.com/wiki/Adsuck
+HOMEPAGE=  https://github.com/conformal/adsuck/wiki
 MAINTAINER=Gonzalo L. R. 
-EXTRACT_SUFX=  .tgz
 
 # BSD
 PERMIT_PACKAGE_CDROM=  Yes
-
-MASTER_SITES=  http://opensource.conformal.com/snapshots/adsuck/
 
 WANTLIB += c event_core event_extra ldns pthread
 
Index: distinfo
===
RCS file: /cvs/ports/net/adsuck/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo17 Dec 2012 11:34:44 -  1.14
+++ distinfo10 Mar 2016 23:55:18 -
@@ -1,2 +1,2 @@
-SHA256 (adsuck-2.5.0.tgz) = EmAuySScbHMD+QF7yQdHKK9jxFq+wVuYPkemZNcCQmM=
-SIZE (adsuck-2.5.0.tgz) = 10443584
+SHA256 (adsuck-2.5.0.tar.gz) = fWV34g0wnU+qb4hSDa+MXZUSLPXlKzUNyX3vyqx9x+Y=
+SIZE (adsuck-2.5.0.tar.gz) = 10448193



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 16:05:53

Modified files:
audio/gsm  : Makefile 
audio/gsm/patches: patch-Makefile 

Log message:
remove NO_SHARED_LIBS; ok sthen@



Re: [mail/sendmail] SMTP session reuse bugfix

2016-03-10 Thread Stuart Henderson
On 2016/03/10 12:45, Claus Assmann wrote:
> On Wed, Mar 09, 2016, Jeremie Courreges-Anglas wrote:
> 
> > Claus, in the future would it be possible to prefix the patch file names
> > with "sendmail-"?  It would be a bit safer for us, as we would not have
> 
> Do you mean the patch on the sendmail.org FTP server?  That naming
> scheme is used for about 10 years so it's unlikely to be changed now.
> 
> > to check for possible collisions with other ports.
> 
> Sorry, but I don't understand what "possible collisions with other
> ports" could happen: are the patches "global"?
> 

They would normally be fetched to /usr/ports/distfiles which is
"global", it's easy enough to override with DIST_SUBDIR, it's better
not to use it too much (if everything did, we'd end up with a bunch
more inode use, plus the lazy person's cd /usr/ports/*/pkgname
would then fail ;) but I think it would be reasonable to use in
this case.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 15:51:45

Modified files:
multimedia/libvpx: Makefile 
multimedia/x264: Makefile 
multimedia/xvidcore: Makefile 

Log message:
remove simple instances of NO_SHARED_LIBS



NO_SHARED cleanup status

2016-03-10 Thread Christian Weisgerber
For any committers who want to pitch in or just wonder how their ports
are affected, here's what's up:

PFRAG.shared can be folded into PLIST without restrictions.  Remember
the REVISION bump.

NO_SHARED_ARCHS isn't set any longer and PROPERTIES:Mno_shared will
never match.  Instances of these can be removed.  However, there
are usually .if branches to consider.

NO_SHARED_LIBS is always set to "No".  It can be removed.

CONFIGURE_SHARED always expands to "--enable-shared".  I expect
that this is the upstream default for the vast majority of affected
ports.  I currently have a bulk build running that will identify
all ports that actually require CONFIGURE_ARGS = --enable-shared.
Once that is done, all remaining instances of CONFIGURE_SHARED can
be removed.

SHARED_ONLY: DO NOT REMOVE from Perl ports.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: [NEW] www/pnp4nagios

2016-03-10 Thread Kirill Bychkov
On Thu, March 10, 2016 23:22, Vadim Zhukov wrote:
> 2016-03-09 17:08 GMT+03:00 Kirill Bychkov :
>> On Thu, March 3, 2016 16:57, Kirill Bychkov wrote:
>>> Him guys!
>>> This is a port of PNP4Nagios, an addon for Nafios and Oconga for analyzing
>>> performance data and storing it in RRD.
>>> Current port is partially based on an old one from henning@ [1] and tested
>>> for more than a month with Icinga 1.x processing data from about 400 hosts.
>>> It could be splitted to Nagios and Icinga 2.x flavors if there are some
>>> interest in them and one can test it with.
>>>
>>> [1] http://marc.info/?l=openbsd-ports=140803165912579=2
>>>
>>> Comments? OKs?
>> Objections? :)
>>
>> Updated tarball with fixed typos.
>
> Here are some more nits:
>
> ... in Makefile:
>
>> INSTALL_OPTS="-o roog -g bin" \

Damn, as usual... :)
>
> One more tyop. ;)
>
>> SYSCONFDIR =${BASESYSCONFDIR}/pnp4nagios/
>> LOCALSTATEDIR = ${BASELOCALSTATEDIR}/pnp4nagios
>
> Why slash is added in one case but not in the other?

Just a paste effect. Should not change anything, byt a style matters, yes.
>
>
>> # fix broken symlink in tarball
>
> If this symlink gets packaged, then it should be relative one, like:
>
> ln -sf ../en_US/dwnld.html \
> ${WRKSRC}/share/pnp/documents/de_DE/dwnld.html

At a fake stage a file is installed, not symlink. Whithout this trick fake is
broken because upstream foret to symlink it while creating tarball.
>
> ... in patches:
>
> At least patch-sample-config_httpd_conf_in needs justification, why it's
> needed.
>
> ... in pkg/README-cgi:
>
>> Apache2 configuration for PNP4Nagios is stored under:
>> /var/conf/modules.sample/pnp4nagios.conf

Yes, mi bad. This should be /var/www
>
> /var/conf? I suppose this should be ${LOCALSTATEDIR}/apache2/conf, or
> something like that.

Bit not LOCALSTATEDIR which is set to /var/pnp4nagios.
>
> ... in pkg/PLIST-main:
>
> Is it intended that not all share/example/* stuff has its @sample
> counterpart under ${SYSCONFDIR}?

I've aded only mandatory configs. Others are not in my setup but probably
would be useful for others.
>
>> share/doc/pkg-readmes/${FULLPKGNAME}
>> @owner _icinga
>> @sample ${LOCALSTATEDIR}/
>> @sample ${LOCALSTATEDIR}/stats/
>> @sample /var/log/pnp4nagios.log
>
> I'm not sure the latter is supposed to work, or won't fail at some
> point in the future. @sample, when applied to a file, mean "take the
> file from the line above and copy it here". And you have a non-files
> line above up to README one. If you want to create an empty file owned
> by someone, you may either use something like:

Great catch. It is a file. It's a readme (it is above in the list, before all
this directories you've mentionrd). I should create a "dumb" one first and
then @sample it.

>
> @exec-add test -e /var/log/pnp4nagios.log || install -o _nagios -g
> _nagios -m 0640 /dev/null /var/log/pnp4nagios.log
> @extraunexec test -s /var/log/pnp4nagios || rm -f /var/log/pnp4nagios.log
>
> or use /var/log/pnp4nagios/ directory instead, owned by _nagios, where
> application could create/rename/remove files without problem. I'd
> recommend go the 2nd way, as we usually do.

Well, I'm not sure that a subdirectory is really needed for the one log file,
but it is a real alternative. Or just sampling an empty file...

I'll make new tarball tomorrow.

>
> --
>   WBR,
>   Vadim Zhukov
>




CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 14:58:52

Modified files:
archivers/bzip2: Makefile 
archivers/bzip2/patches: patch-Makefile 
devel/libslang : Makefile 
devel/libslang/pkg: PLIST 
graphics/jbigkit: Makefile 
graphics/jbigkit/patches: patch-libjbig_Makefile 
graphics/mpeg-lib: Makefile 
graphics/mpeg-lib/patches: patch-Makefile_in 
net/libbgpdump : Makefile 
lang/STk   : Makefile 
lang/STk/pkg   : PLIST 
mail/alpine: Makefile 
mail/alpine/patches: patch-imap_src_osdep_unix_Makefile 
math/cfitsio   : Makefile 
www/cgiparse   : Makefile 
www/cgiparse/patches: patch-Makefile_in 
x11/golem  : Makefile 
x11/golem/pkg  : PLIST 
Removed files:
devel/libslang/pkg: PFRAG.shared 
lang/STk/pkg   : PFRAG.shared 
x11/golem/pkg  : PFRAG.shared 

Log message:
remove various instances of NO_SHARED_LIBS and PROPERTIES:Mno_shared,
fold PFRAG.shared into PLIST



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Theo de Raadt
> On Thu, Mar 10, 2016 at 05:58:05PM +0100, Karel Gardas wrote:
> > On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie  wrote:
> > > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> > >> This is a sign of not so correct network configuration. MICO is really
> > >> picky about it so it should be able to resolve your host name/IP
> > >> address. What's failing precisely in the assert above is that it's not
> > >> able to get IP for your hostname. Can you confirm that this is the
> > >> case?
> > >
> > > Nope. This is the only port in the tree that doesn't like it when you cut
> > > network access during build (which proper build machines have started 
> > > doing
> > > for a while now).
> > 
> > This would be strange since I commonly build MICO w/o any internet 
> > connection.
> 
> This is not what I'm talking about. I'm talking about explicitly blocking
> the build user from any kind of network activity thru pf.
> 
> > Indeed, it is, but I guess this was done for a good reason in the past
> > and I would rather keep it this way. What I can certainly do for
> > 2.3.14 release is to add some clear error message pointing to the
> > incorrect network configuration.
> 
> It's not an incorrect network configuration, actually.   It's just no 
> resolving
> some things on localhost.
> 
> mico is the only port that wants this. Everything else works peachy.
> 
> I've got a very paranoid setup on my build machines.
> I just have:
> block out quick proto {tcp,udp} from self user pbuild0
> 
> oh, and the build is chroot'd to a place that only knows about localhost.
> 
> No other port in the trees ever tries to resolve `hostname` during build.

but then how does it download the egg...



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Marc Espie
On Thu, Mar 10, 2016 at 05:58:05PM +0100, Karel Gardas wrote:
> On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie  wrote:
> > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> >> This is a sign of not so correct network configuration. MICO is really
> >> picky about it so it should be able to resolve your host name/IP
> >> address. What's failing precisely in the assert above is that it's not
> >> able to get IP for your hostname. Can you confirm that this is the
> >> case?
> >
> > Nope. This is the only port in the tree that doesn't like it when you cut
> > network access during build (which proper build machines have started doing
> > for a while now).
> 
> This would be strange since I commonly build MICO w/o any internet connection.

This is not what I'm talking about. I'm talking about explicitly blocking
the build user from any kind of network activity thru pf.

> Indeed, it is, but I guess this was done for a good reason in the past
> and I would rather keep it this way. What I can certainly do for
> 2.3.14 release is to add some clear error message pointing to the
> incorrect network configuration.

It's not an incorrect network configuration, actually.   It's just no resolving
some things on localhost.

mico is the only port that wants this. Everything else works peachy.

I've got a very paranoid setup on my build machines.
I just have:
block out quick proto {tcp,udp} from self user pbuild0

oh, and the build is chroot'd to a place that only knows about localhost.

No other port in the trees ever tries to resolve `hostname` during build.



Re: [mail/sendmail] SMTP session reuse bugfix

2016-03-10 Thread Claus Assmann
On Wed, Mar 09, 2016, Jeremie Courreges-Anglas wrote:

> Claus, in the future would it be possible to prefix the patch file names
> with "sendmail-"?  It would be a bit safer for us, as we would not have

Do you mean the patch on the sendmail.org FTP server?  That naming
scheme is used for about 10 years so it's unlikely to be changed now.

> to check for possible collisions with other ports.

Sorry, but I don't understand what "possible collisions with other
ports" could happen: are the patches "global"?



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 13:41:22

Modified files:
graphics/ffmpeg: Makefile 

Log message:
requires --enable-shared



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 13:26:03

Modified files:
print/ghostscript/gnu: Makefile 
print/ghostscript/gnu/pkg: PLIST 
Removed files:
print/ghostscript/gnu/pkg: PFRAG.shared 

Log message:
remove NO_SHARED_ARCHS, NO_SHARED_LIBS, and fold PFRAG.shared into PLIST
ok kili@



Re: [NEW] www/pnp4nagios

2016-03-10 Thread Vadim Zhukov
2016-03-09 17:08 GMT+03:00 Kirill Bychkov :
> On Thu, March 3, 2016 16:57, Kirill Bychkov wrote:
>> Him guys!
>> This is a port of PNP4Nagios, an addon for Nafios and Oconga for analyzing
>> performance data and storing it in RRD.
>> Current port is partially based on an old one from henning@ [1] and tested
>> for more than a month with Icinga 1.x processing data from about 400 hosts.
>> It could be splitted to Nagios and Icinga 2.x flavors if there are some
>> interest in them and one can test it with.
>>
>> [1] http://marc.info/?l=openbsd-ports=140803165912579=2
>>
>> Comments? OKs?
> Objections? :)
>
> Updated tarball with fixed typos.

Here are some more nits:

... in Makefile:

> INSTALL_OPTS="-o roog -g bin" \

One more tyop. ;)

> SYSCONFDIR =${BASESYSCONFDIR}/pnp4nagios/
> LOCALSTATEDIR = ${BASELOCALSTATEDIR}/pnp4nagios

Why slash is added in one case but not in the other?


> # fix broken symlink in tarball

If this symlink gets packaged, then it should be relative one, like:

ln -sf ../en_US/dwnld.html \
${WRKSRC}/share/pnp/documents/de_DE/dwnld.html

... in patches:

At least patch-sample-config_httpd_conf_in needs justification, why it's needed.

... in pkg/README-cgi:

> Apache2 configuration for PNP4Nagios is stored under:
> /var/conf/modules.sample/pnp4nagios.conf

/var/conf? I suppose this should be ${LOCALSTATEDIR}/apache2/conf, or
something like that.

... in pkg/PLIST-main:

Is it intended that not all share/example/* stuff has its @sample
counterpart under ${SYSCONFDIR}?

> share/doc/pkg-readmes/${FULLPKGNAME}
> @owner _icinga
> @sample ${LOCALSTATEDIR}/
> @sample ${LOCALSTATEDIR}/stats/
> @sample /var/log/pnp4nagios.log

I'm not sure the latter is supposed to work, or won't fail at some
point in the future. @sample, when applied to a file, mean "take the
file from the line above and copy it here". And you have a non-files
line above up to README one. If you want to create an empty file owned
by someone, you may either use something like:

@exec-add test -e /var/log/pnp4nagios.log || install -o _nagios -g
_nagios -m 0640 /dev/null /var/log/pnp4nagios.log
@extraunexec test -s /var/log/pnp4nagios || rm -f /var/log/pnp4nagios.log

or use /var/log/pnp4nagios/ directory instead, owned by _nagios, where
application could create/rename/remove files without problem. I'd
recommend go the 2nd way, as we usually do.

--
  WBR,
  Vadim Zhukov



Re: patch: perl.port.mk to support Module::Build::Tiny

2016-03-10 Thread Nigel Taylor
On 03/10/16 01:39, Stuart Henderson wrote:
> On 2016/03/09 15:26, Nigel Taylor wrote:
>> Attached revised perl.port.mk diff
> 
> Looks sane, testing this (and cpan.port.mk diff) in a full build now.
> 
>> perl.port.mk.diff_p522 - extras diffs I am using.
> 
> Let's clear Module::Build (which already triggers warnings and breaks
> with 5.22) before we look at Module::Install (which iirc does still
> run with 5.22?)

Looked at Module::Build, distinfo, pkg/PLIST are the same. 
pkg/DESCR I used only the first two lines either way is ok.


Makefile is where we differ, mines a little messy I thought, 
what I had was this see later try.

# $OpenBSD:$

COMMENT =   Module build

DISTNAME =  Module-Build-0.4208
PKGNAME =   p5-Module-Build-0.42.08
CATEGORIES =devel

# Perl
PERMIT_PACKAGE_CDROM =  Yes

MODULES =   cpan

TEST_DEPENDS += devel/p5-PAR-Dist>=0.17

# TODO this works but messy...
do-install:
cd ${WRKSRC} && \
./Build \
--install_path lib="${TRUEPREFIX}/${P5SITE}" \
--install_path arch="${TRUEPREFIX}/${P5ARCH}" \
--install_path libdoc="${TRUEPREFIX}/man/man3p" \
--install_path bindoc="${TRUEPREFIX}/man/man1" \
--install_path bin="${TRUEPREFIX}/bin" \
--install_path script="${TRUEPREFIX}/bin" \
--destdir=${WRKINST} \
install

.include 

Difference is Makefile.PL is used, which uses Module::Build::Compatable,
converts args and runs Build.PL, results in same Build/Makefile, the convert 
args converts to --config rather than --install_path, so install stage
is messed up.



Best effort I've come up with this slightly neater one

# $OpenBSD:$

COMMENT =   Module build

DISTNAME =  Module-Build-0.4208
PKGNAME =   p5-Module-Build-0.42.08
CATEGORIES =devel

# Perl
PERMIT_PACKAGE_CDROM =  Yes

MODULES =   cpan

TEST_DEPENDS += devel/p5-PAR-Dist>=0.17
CONFIGURE_STYLE =   modbuild none

.include 



Needs this in perl.port.mk - "none" doesn't add a build depends

 .if ${CONFIGURE_STYLE:L:Mmodbuild}
+.  if ${CONFIGURE_STYLE:L:Mtiny}
+BUILD_DEPENDS +=   devel/p5-Module-Build-Tiny
+.  elif ${CONFIGURE_STYLE:L:Mnone}
+   # for building Module Build...
+.  else
+BUILD_DEPENDS +=   devel/p5-Module-Build
+.  endif

Currently this shouldn't be needed, as it's for when Module::Build is 
removed from core perl with 5.22 and want modbuild to add the dependency. 
Tried current perl.port.mk and the one above, both work. Will need to work 
out ordering, the changed perl.port.mk can go in before perl 5.22.



Followed the version numbering upstream used major.minor.sub, 
either way is ok, but no to using epochs later, keep 4digits or 2's.





$ doas -u _pbuild make   
===>  Enabling ccache for p5-Module-Build-0.42.08
===> p5-Module-Build-0.42.08 depends on: ccache-* -> ccache-3.2.4
===>  Checking files for p5-Module-Build-0.42.08
`/usr/ports/distfiles/Module-Build-0.4208.tar.gz' is up to date.
>> (SHA256) Module-Build-0.4208.tar.gz: OK
===>  Extracting for p5-Module-Build-0.42.08
===>  Patching for p5-Module-Build-0.42.08
===>  Configuring for p5-Module-Build-0.42.08
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'Module-Build' version '0.4208'
===>  Building for p5-Module-Build-0.42.08
Building Module-Build
$ doas -u _pbuild make fake
===>  Faking installation for p5-Module-Build-0.42.08
install -d -m 755 /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64
Building Module-Build
Installing 
/usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/man/man1/config_data.1
Installing 
/usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/inc/latest.pm
Installing 
/usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/inc/latest/private.pm
Installing 
/usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/Module/Build.pm
Installing 
/usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/Module/Build/PodParser.pm



$ doas -u _pbuild make test  
===> p5-Module-Build-0.42.08 depends on: p5-PAR-Dist->=0.17 -> p5-PAR-Dist-0.49
===>  Regression tests for p5-Module-Build-0.42.08
/usr/bin/perl Build --makefile_env_macros 1 test
t/00-compile.t . ok
t/PL_files.t ... ok
t/actions/installdeps.t  ok
...
t/unit_run_test_harness.t .. ok
t/use_tap_harness.t  ok
t/versions.t ... ok
t/write_default_maniskip.t . ok
t/xs.t . ok
All tests successful.
Files=53, Tests=1134, 182 wallclock secs ( 0.41 usr  0.56 sys + 48.54 cusr 
43.36 csys = 92.87 CPU)
Result: PASS


Extra in TEST_DEPENDS, PAR::Dist is optional if pardist is used in Build.PL 
then required,
we aren't creating a distribution just building, optional if included at 
runtime.

$ grep 

CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 13:15:07

Modified files:
telephony/baresip/re: Makefile 
telephony/baresip/rem: Makefile 

Log message:
remove NO_SHARED_LIBS



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Pascal Stumpf
CVSROOT:/cvs
Module name:ports
Changes by: pas...@cvs.openbsd.org  2016/03/10 12:45:59

Modified files:
security/libotr: Makefile distinfo 
security/libotr/pkg: PLIST 

Log message:
SECURITY update to 4.1.1.  Fixes CVE 2016-2851; to the best of our knowledge,
this one is not exploitable on OpenBSD because memory returned by malloc(0) is
inaccessible.  Bug found by stsp@ 11 months ago.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 12:29:25

Modified files:
security/nss   : Makefile 

Log message:
replace after-bsd.port.mk hack with PROPERTIES check



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 12:03:35

Modified files:
x11/fleditor   : Makefile 

Log message:
requires --enable-shared
remove NO_SHARED_LIBS



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Michael McConville
Karel Gardas wrote:
> This is a sign of not so correct network configuration. MICO is really
> picky about it so it should be able to resolve your host name/IP
> address. What's failing precisely in the assert above is that it's not
> able to get IP for your hostname. Can you confirm that this is the
> case?

Confirmed. I hadn't considered that my hostname could affect a package
build.  :-)

I don't know anything about Mico, so I'll stay out of the patching
process.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Vadim Zhukov
CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/03/10 10:45:11

Modified files:
x11/qt4: qt4.port.mk 
x11/qt5: qt5.port.mk 
Added files:
devel/qmake: qmake.port.mk 

Log message:
Switch to a separate qmake.port.mk. Simplifies logic a lot.

This removes support of separate qmake versions in one port: as we
discovered, there are no ports actually needing this; strangers like
print/poppler don't use qmake in build.

This should be transparent to current ports. But expect more tweaks there:
for now, qt?.port.mk forces qmake.port.mk inclusion, but that will be
reworked to a more common scheme.

Same idea from (at least) espie@ and me; also, espie@ agrees on the plan.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Vadim Zhukov
CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/03/10 10:38:52

ports/devel/qmake

Update of /cvs/ports/devel/qmake
In directory cvs.openbsd.org:/tmp/cvs-serv3286/devel/qmake

Log Message:
Directory /cvs/ports/devel/qmake added to the repository



CVS: cvs.openbsd.org: ports

2016-03-10 Thread James Turner
CVSROOT:/cvs
Module name:ports
Changes by: jtur...@cvs.openbsd.org 2016/03/10 10:37:31

Modified files:
sysutils/tarsnap: Makefile distinfo 

Log message:
Update tarsnap to 1.0.37.

This version adds several new options, including --passphrase-time option for 
increased security of passphrase-protected key files, along with minor bug 
fixes and some additional warnings about common user errors.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Vadim Zhukov
CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/03/10 10:24:38

Modified files:
x11/cool-retro-term: Makefile 

Log message:
Use qmake instead of qmake5 in CONFIGURE_STYLE.

Needed for upcoming qmake.port.mk.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Vadim Zhukov
CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/03/10 10:27:11

Modified files:
audio/musique  : Makefile 

Log message:
Make this fit 80 columns.



Re: update devel/py-pip

2016-03-10 Thread Daniel Jakots
On Sun, 6 Mar 2016 20:34:25 +0100, Daniel Jakots 
wrote:

> Here's an update to latest py-pip.

Ping?



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Karel Gardas
On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie  wrote:
> On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
>> This is a sign of not so correct network configuration. MICO is really
>> picky about it so it should be able to resolve your host name/IP
>> address. What's failing precisely in the assert above is that it's not
>> able to get IP for your hostname. Can you confirm that this is the
>> case?
>
> Nope. This is the only port in the tree that doesn't like it when you cut
> network access during build (which proper build machines have started doing
> for a while now).

This would be strange since I commonly build MICO w/o any internet connection.

> I've looked a bit further, and that stupid test is so deep embedded within
> the mico code itself that it will be a pain to fix.

Indeed, it is, but I guess this was done for a good reason in the past
and I would rather keep it this way. What I can certainly do for
2.3.14 release is to add some clear error message pointing to the
incorrect network configuration.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Vadim Zhukov
CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/03/10 09:07:27

Modified files:
geo/gpsbabel   : Makefile 

Log message:
Switch to MODQMAKE, no Makefile lines count change.



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Stuart Henderson
On 2016/03/10 15:13, Marc Espie wrote:
> On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> > This is a sign of not so correct network configuration. MICO is really
> > picky about it so it should be able to resolve your host name/IP
> > address. What's failing precisely in the assert above is that it's not
> > able to get IP for your hostname. Can you confirm that this is the
> > case?
> 
> Nope. This is the only port in the tree that doesn't like it when you cut
> network access during build (which proper build machines have started doing
> for a while now).
> 
> I've looked a bit further, and that stupid test is so deep embedded within
> the mico code itself that it will be a pain to fix.
> 

It's not even network access, it just needs the name in /etc/hosts.
mico builds fine for me and I do not permit _pbuild to make network
connections, but I do have an entry in /etc/hosts for the hostname
(i.e. getent `hostname` works).



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Vadim Zhukov
CVSROOT:/cvs
Module name:ports
Changes by: z...@cvs.openbsd.org2016/03/10 07:19:53

Modified files:
x11/qwt: Makefile 

Log message:
Use MODQMAKE, not MODQMAKE4. No actual changes in build process.

Will be used in further transition to a separate qmake.port.mk.



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Marc Espie
On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
> This is a sign of not so correct network configuration. MICO is really
> picky about it so it should be able to resolve your host name/IP
> address. What's failing precisely in the assert above is that it's not
> able to get IP for your hostname. Can you confirm that this is the
> case?

Nope. This is the only port in the tree that doesn't like it when you cut
network access during build (which proper build machines have started doing
for a while now).

I've looked a bit further, and that stupid test is so deep embedded within
the mico code itself that it will be a pain to fix.



Re: ports gdb thread handling... (fwd)

2016-03-10 Thread Pascal Stumpf
On Thu, 10 Mar 2016 01:08:36 +0100, Jeremie Courreges-Anglas wrote:
> Philip Guenther  writes:
> 
> > Broadening to ports@
> >
> > With respect to this question in my original note:
> >> Or maybe new gdb has some way to have ptid_get_pid() return the 
> >> per-thread value?
> >
> > the answer appears to be "nope, no new magic in gdb for that".
> 
> Makes sense, I only tested with an old gdb (7.9.1) so far but will take
> a look at -current soon.
> 
> Pascal, any objection?

Nope.  But kettenis@ knows this code best, so I had hoped for his
comment.

> >
> > Philip
> >
> > -- Forwarded message --
> > Date: Sun, 19 Apr 2015 16:18:07 -0700
> > From: Philip Guenther 
> > To: Pascal Stumpf 
> > Cc: Mark Kettenis 
> > Subject: ports gdb thread handling...
> >
> >
> > Looks like the gdb in ports needs patching to try ptid_get_lwp() before 
> > ptid_get_pid() when fetching/setting registers.  For example, diff below 
> > fixes this for amd64.  Without this it always reports the original 
> > thread's registers (and thus the same backtrace), but with it I can get 
> > distinct backtraces like:
> >
> > (gdb) bt
> > #0  tmain (arg=0x13b8b2200fcf) at f.c:7
> > #1  0x13bad626ba3e in _rthread_start (v=0x13bb143b9000)
> > at /usr/src/lib/librthread-clean/rthread.c:145
> > #2  0x13bafd3035db in __tfork_thread ()
> > at /usr/src/lib/libc-clean/arch/amd64/sys/tfork_thread.S:79
> > (gdb) info thr
> >   Id   Target Id Frame
> > * 2thread 1006996tmain (arg=0x13b8b2200fcf) at f.c:7
> >   1thread 1021961_dl_sigprocmask ()
> > at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:121
> > (gdb) thread 1
> > [Switching to thread 1 (thread 1021961)]
> > #0  _dl_sigprocmask () at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:121
> > 121 jc  1b   /* error: result = -errno */
> > (gdb) bt
> > #0  _dl_sigprocmask () at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:121
> > #1  0x13bba8505352 in _dl_thread_bind_lock (what=0, 
> > omask=0x7f7e7474)
> > at /usr/src/libexec/ld.so-realclean/dlfcn.c:526
> > #2  0x13bba8506a4c in _dl_bind (object=0x13bacf01f800,
> > index=)
> > at /usr/src/libexec/ld.so-realclean/amd64/rtld_machine.c:393
> > #3  0x13bba85028b9 in _dl_bind_start ()
> > at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:167
> > #4  0x13bad626b6fe in pthread_join (thread=0x13bb143b9000, retval=0x0)
> > at /usr/src/lib/librthread-clean/rthread.c:360
> > #5  0x13b8b2100f8a in main () at f.c:18
> > (gdb)
> >
> >
> > The other arch files will need the same sort of diff.  Or maybe new gdb 
> > has some way to have ptid_get_pid() return the per-thread value?
> >
> > Philip
> >
> >
> > --- gdb/amd64bsd-nat.c  Thu Feb 19 03:58:07 2015
> > +++ /tmp/amd64bsd-nat.c Sun Apr 19 16:09:45 2015
> > @@ -43,13 +43,19 @@
> >struct regcache *regcache, int regnum)
> >  {
> >struct gdbarch *gdbarch = get_regcache_arch (regcache);
> > +  int pid;
> >  
> > +  /* Cater for systems like OpenBSD, that implement threads as
> > + separate processes.  */
> > +  pid = ptid_get_lwp (inferior_ptid);
> > +  if (pid == 0)
> > +pid = ptid_get_pid (inferior_ptid);
> > +
> >if (regnum == -1 || amd64_native_gregset_supplies_p (gdbarch, regnum))
> >  {
> >struct reg regs;
> >  
> > -  if (ptrace (PT_GETREGS, ptid_get_pid (inferior_ptid),
> > - (PTRACE_TYPE_ARG3) , 0) == -1)
> > +  if (ptrace (PT_GETREGS, pid, (PTRACE_TYPE_ARG3) , 0) == -1)
> > perror_with_name (_("Couldn't get registers"));
> >  
> >amd64_supply_native_gregset (regcache, , -1);
> > @@ -61,8 +67,7 @@
> >  {
> >struct fpreg fpregs;
> >  
> > -  if (ptrace (PT_GETFPREGS, ptid_get_pid (inferior_ptid),
> > - (PTRACE_TYPE_ARG3) , 0) == -1)
> > +  if (ptrace (PT_GETFPREGS, pid, (PTRACE_TYPE_ARG3) , 0) == -1)
> > perror_with_name (_("Couldn't get floating point status"));
> >  
> >amd64_supply_fxsave (regcache, -1, );
> > @@ -77,19 +82,24 @@
> >struct regcache *regcache, int regnum)
> >  {
> >struct gdbarch *gdbarch = get_regcache_arch (regcache);
> > +  int pid;
> >  
> > +  /* Cater for systems like OpenBSD, that implement threads as
> > + separate processes.  */
> > +  pid = ptid_get_lwp (inferior_ptid);
> > +  if (pid == 0)
> > +pid = ptid_get_pid (inferior_ptid);
> > +
> >if (regnum == -1 || amd64_native_gregset_supplies_p (gdbarch, regnum))
> >  {
> >struct reg regs;
> >  
> > -  if (ptrace (PT_GETREGS, ptid_get_pid (inferior_ptid),
> > -  (PTRACE_TYPE_ARG3) , 0) == -1)
> > +  if (ptrace (PT_GETREGS, pid, (PTRACE_TYPE_ARG3) , 0) == -1)
> >  perror_with_name (_("Couldn't get registers"));
> >  
> >amd64_collect_native_gregset (regcache, , 

Re: libotr security fix

2016-03-10 Thread Pascal Stumpf
On Thu, 10 Mar 2016 10:10:07 +0100, Stefan Sperling wrote:
> On Wed, Mar 09, 2016 at 05:32:47PM -0800, Michael McConville wrote:
> > Is anyone working on updates for security/libotr and
> > security/pidgin-otr? There were releases addressing a scary
> > vulnerability this morning:
> > 
> > https://marc.info/?l=otr-announce=145754687614832=2
> > 
> > If not, I probably have time to work on it tonight.
> 
> These should be updated, but there's no reason to hurry up very very much.
> 
> The libotr problem depends on malloc(0) returning a pointer that doesn't
> segfault when it is used. On OpenBSD the program will crash at the point
> where the attacker tries to overwrite the heap.
> Unless there's another avenue for this exploit which doesn't use malloc(0),
> but the advisory only mentions malloc(0).
> See http://seclists.org/oss-sec/2016/q1/568
> 
> security/pidgin-otr has been already patched in our ports tree by me in
> 2015 (before 5.8). I reported this bug and they left it sit for 9 months
> until Hanno Boeck reported the same problem again:
> https://bugs.otr.im/issues/88
> pidgin-otr crashed on OpenBSD immediately, which is why I noticed.
> 
> 

Works for me with all OTR-capable messengers (Kopete untested).

No API change apparently, so no bump.

"make update-plist" re-added share/aclocal; is that due to some change
in dependencies?


Index: Makefile
===
RCS file: /cvs/ports/security/libotr/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- Makefile19 Jul 2015 08:18:52 -  1.27
+++ Makefile10 Mar 2016 10:08:27 -
@@ -2,7 +2,7 @@
 
 COMMENT=   portable OTR messaging library and toolkit
 
-DISTNAME=  libotr-4.1.0
+DISTNAME=  libotr-4.1.1
 CATEGORIES=security
 
 SHARED_LIBS +=  otr  4.1  # 6.0
Index: distinfo
===
RCS file: /cvs/ports/security/libotr/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo3 Apr 2015 16:15:40 -   1.9
+++ distinfo10 Mar 2016 10:08:27 -
@@ -1,2 +1,2 @@
-SHA256 (libotr-4.1.0.tar.gz) = T9uJGUDsidMAGQqY9pqROCSNy4yNM3Yz+5gbjQqc2TA=
-SIZE (libotr-4.1.0.tar.gz) = 576771
+SHA256 (libotr-4.1.1.tar.gz) = izsYJCQlEGepUvtObHuVoh5kT7sn+9X4rysu2HykGfU=
+SIZE (libotr-4.1.1.tar.gz) = 655791
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/libotr/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST   16 Mar 2015 18:07:54 -  1.7
+++ pkg/PLIST   10 Mar 2016 10:08:27 -
@@ -33,4 +33,5 @@ lib/pkgconfig/libotr.pc
 @man man/man1/otr_remac.1
 @man man/man1/otr_sesskeys.1
 @man man/man1/otr_toolkit.1
+share/aclocal/
 share/aclocal/libotr.m4



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Kirill Bychkov
CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2016/03/10 06:35:23

Modified files:
sysutils/logstalgia: Makefile 

Log message:
update HOMEPAGE. OK gonzalo@ (maintainer)



Re: [update] net/transmission

2016-03-10 Thread Josh Grosse

On 2016-03-08 13:11, Marc Espie wrote:

On Tue, Mar 08, 2016 at 04:18:16PM +, Christian Weisgerber wrote:

On 2016-03-08, Josh Grosse  wrote:

> Thank you, naddy, for your kind patience with my port update.  This one in
> particular has been a learning experience, and I appreciate the guidance.

That port is awfully complex.  I keep wavering between wanting to
split off the Qt client into a separate port to simplify things,
and keeping the port as is just because it makes a good example.


Can you build the qt client separately in a simple enough way to not
have lots of patches duplication ?


If the -qt subpackage is split into its own port, it needs to build 
-main

in order to link needed objects.  If I'm right, then this doesn't seem
a worthwhile separation.  But, due to the large set of corrections
that Vadim, Naddy, and Antoine needed to make to my port update OK for
commit, it is safest to assume I'm wrong.  :)


I've had a look, it's not that awful, but then I'm biased, considering
what "complex" was in the past...




CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 05:20:06

Modified files:
infrastructure/bin: portcheck 
infrastructure/mk: arch-defines.mk bsd.port.arch.mk 

Log message:
no more non-shared archs:
NO_SHARED_ARCHS and "no_shared" in PROPERTIES are no longer set



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Peter Hessler
On 2016 Mar 10 (Thu) at 10:53:26 + (+), Stuart Henderson wrote:
:On 2016/03/10 02:05, Michael McConville wrote:
:> It's been failing reliably on my machine since I started bulk building a
:> couple months ago.
:
:If your local hostname doesn't resolve this triggers an assertion in
:mico.
:

would setting a fake hostname fix the assert?  can that be patched out?


-- 
In Boston, it is illegal to hold frog-jumping contests in nightclubs.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Christian Weisgerber
CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2016/03/10 04:50:13

Modified files:
audio/flite: Makefile 
databases/db   : Makefile.inc 
lang/python: Makefile.inc 
lang/ruby  : Makefile.inc 
lang/swi-prolog: Makefile 
math/netcdf: Makefile 
net/libircclient: Makefile 
telephony/pjsua: Makefile 
x11/fltk   : Makefile 

Log message:
requires --enable-shared



Re: missing lib dep for devel/iso-codes

2016-03-10 Thread Andreas Kusalananda Kähäri
On Thu, Mar 10, 2016 at 11:01:58AM +, Stuart Henderson wrote:
> On 2016/03/10 02:37, Michael McConville wrote:
> > It looks like devel/iso-codes needs libintl, although make
> > lib-depends-check doesn't pick it up. See the build failure below.
> 
> This doesn't make sense:
> 
> > /usr/local/bin/msgfmt --verbose --check -o da.mo da.po
> > 488 translated messages.
> > /usr/local/bin/msgfmt --verbose --check -o vi.mo vi.po
> > /usr/local/bin/msgfmt: can't load library 'libintl.so.6.0'
> > Makefile:462: recipe for target 'vi.mo' failed
> 
> The message is generated by msgfmt which is part of gettext-tools,
> but gettext-tools *does* depend on devel/gettext (which contains
> libintl).
> 
> If this is something other than a local problem, it's definitely
> not in iso-codes.
> 

I've seen these sorts of things with dpb too, build tools/libs suddenly
disappearing.  Sometimes the build will succeed if it's run again.  I'm
wondering if turning off junking ("-J 0") would help?

Cheers,

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF




Re: productivity/davical failing when fetching

2016-03-10 Thread Stuart Henderson
On 2016/03/10 02:26, Michael McConville wrote:
> Apparently none of the sources are valid anymore. IIRC, this has been
> happening since I started bulk building a couple months ago.

This is a bug (or missing feature) in ports infrastructure, the
MASTER_SITE_BACKUP mechanism doesn't know about the filename{url}sufx
handling in DISTFILES.

> ===> Trying http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//
> /usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v 
> http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
> Trying 145.238.209.46...
> Requesting 
> http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
> ftp: Error retrieving file: 404 Not Found

$ curl -s http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/ | grep davical
davical-1.1.3.1.tar.gz 
24-Nov-2014 03:24 3031220

When using MASTER_SITE_BACKUP it needs to fetch these files from
"$(filename)$(sufx)" rather than "$(url)$(sufx)".



Re: missing lib dep for devel/iso-codes

2016-03-10 Thread Stuart Henderson
On 2016/03/10 02:37, Michael McConville wrote:
> It looks like devel/iso-codes needs libintl, although make
> lib-depends-check doesn't pick it up. See the build failure below.

This doesn't make sense:

> /usr/local/bin/msgfmt --verbose --check -o da.mo da.po
> 488 translated messages.
> /usr/local/bin/msgfmt --verbose --check -o vi.mo vi.po
> /usr/local/bin/msgfmt: can't load library 'libintl.so.6.0'
> Makefile:462: recipe for target 'vi.mo' failed

The message is generated by msgfmt which is part of gettext-tools,
but gettext-tools *does* depend on devel/gettext (which contains
libintl).

If this is something other than a local problem, it's definitely
not in iso-codes.



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Stuart Henderson
On 2016/03/10 02:05, Michael McConville wrote:
> It's been failing reliably on my machine since I started bulk building a
> couple months ago.

If your local hostname doesn't resolve this triggers an assertion in
mico.



Re: devel/mico failing due to failed assertion

2016-03-10 Thread Karel Gardas
This is a sign of not so correct network configuration. MICO is really
picky about it so it should be able to resolve your host name/IP
address. What's failing precisely in the assert above is that it's not
able to get IP for your hostname. Can you confirm that this is the
case?

On Thu, Mar 10, 2016 at 11:05 AM, Michael McConville  wrote:
> It's been failing reliably on my machine since I started bulk building a
> couple months ago.
>
>
 Building on localhost under devel/mico
>  BDEPENDS = [devel/gmake]
>  DIST = [devel/mico:mico-2.3.13.tar.gz]
>  FULLPKGNAME = mico-2.3.13p0
> (Junk lock failure for localhost at 1455583281)
> Received IO
> (Junk lock obtained for localhost at 1455583287)
> Woken up devel/mico
> Woken up devel/mico
> Woken up devel/mico
> Short-cut: depends already handled by devel/avr/gcc
 Running show-prepare-results in devel/mico at 1455583287
> ===> devel/mico
> ===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0
> ===>  Verifying specs:  c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt 
> pthread
> ===>  found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 
> ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1
> gmake-4.1p0
> (Junk lock released for localhost at 1455583288)
> distfiles size=3269814
 Running patch in devel/mico at 1455583288
> ===> devel/mico
> ===>  Checking files for mico-2.3.13p0
> `/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date.
> ===>  Extracting for mico-2.3.13p0
> ===>  Patching for mico-2.3.13p0
 Running configure in devel/mico at 1455583290
> ===> devel/mico
> ===>  Configuring for mico-2.3.13p0
> Using /home/dpb-wrk/mico-2.3.13/config.site (generated)
> loading site script /home/dpb-wrk/mico-2.3.13/config.site
> creating cache ./config.cache
> checking for extra include and lib directories...
> checking host system type... x86_64-unknown-openbsd5.9
> checking target system type... x86_64-unknown-openbsd5.9
> checking build system type... x86_64-unknown-openbsd5.9
> checking for gcc... cc
> checking whether the C compiler (cc -O2 -pipe ) works... yes
> checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether cc accepts -g... (cached) yes
> checking how to run the C preprocessor... cc -E
> checking for c++... c++
> checking whether the C++ compiler (c++ -O2 -pipe ) works... yes
> checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no
> checking whether we are using GNU C++... yes
> checking whether c++ accepts -g... (cached) yes
> checking how to run the C++ preprocessor... c++ -E
> checking for POSIXized ISC... no
> checking OS Type... unix
> checking for open in -lpthread... yes
> checking for pthread.h... (cached) yes
> checking for sched.h... yes
> checking for semaphore.h... (cached) yes
> checking for bison... yacc
> checking for flex... (cached) flex
> checking for yywrap in -lfl... (cached) yes
> checking for ar... ar rc
> checking for ranlib... ranlib
> checking whether gmake sets ${MAKE}... yes
> checking for tclsh... tclsh
> checking for javac... no
> checking for JavaCUP... no
> configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts 
> disabled.
> checking for esnacc/c++/asn-incl.h... no
> checking for open in -lc++asn1... no
> checking for esnacc... no
> checking for smp/AttributeCertificateDefinitions.h... no
> checking for open in -lcmlasn... no
> checking for open in -lm... (cached) yes
> checking for open in -lnsl... no
> checking for X... (cached) libraries /usr/X11R6/lib, headers 
> /usr/X11R6/include
> checking for dnet_ntoa in -ldnet... no
> checking for dnet_ntoa in -ldnet_stub... no
> checking for gethostbyname... (cached) yes
> checking for connect... (cached) yes
> checking for remove... (cached) yes
> checking for shmat... (cached) yes
> checking for IceConnectionNumber in -lICE... (cached) yes
> checking for open in -lsocket... no
> checking for open in -lbsd... no
> checking for open in -lelf... no
> checking for open in -ldl... no
> checking for open in -ldld... no
> checking for open in -lld... no
> checking for open in -lcrypto... yes
> checking for open in -lssl... yes
> checking for open in -lncurses... yes
> checking for readline in -lreadline... yes
> checking for ANSI C header files... (cached) yes
> checking for fcntl.h... (cached) yes
> checking for unistd.h... (cached) yes
> checking for sys/select.h... (cached) yes
> checking for strings.h... (cached) yes
> checking for float.h... (cached) yes
> checking for ieeefp.h... yes
> checking for sys/un.h... (cached) yes
> checking for netinet/in.h... (cached) yes
> checking for arpa/inet.h... (cached) yes
> checking for netdb.h... (cached) yes
> checking for dlfcn.h... (cached) yes
> checking for dl.h... no
> checking for netinet/tcp.h... (cached) yes
> checking for stdlib.h... (cached) yes
> checking for sys/time.h... (cached) yes
> checking for 

missing lib dep for devel/iso-codes

2016-03-10 Thread Michael McConville
It looks like devel/iso-codes needs libintl, although make
lib-depends-check doesn't pick it up. See the build failure below.


===>  Building for iso-codes-3.66
Making all in iso_639
gmake[1]: Entering directory 
'/home/dpb-wrk/iso-codes-3.66/iso-codes-3.66/iso_639'
/usr/local/bin/msgfmt --verbose --check -o wa.mo wa.po
486 translated messages, 2 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o mn.mo mn.po
137 translated messages, 173 fuzzy translations, 178 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ko.mo ko.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o id.mo id.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o ml.mo ml.po
483 translated messages, 2 fuzzy translations, 3 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ve.mo ve.po
37 translated messages, 257 fuzzy translations, 194 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o zh_TW.mo zh_TW.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o gez.mo gez.po
gez.po:9: warning: header field 'Language' still has the initial default value
121 translated messages, 49 fuzzy translations, 318 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ms.mo ms.po
ms.po:11: warning: header field 'Language' still has the initial default value
43 translated messages, 139 fuzzy translations, 306 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ps.mo ps.po
ps.po:9: warning: header field 'Language' still has the initial default value
29 translated messages, 34 fuzzy translations, 425 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ro.mo ro.po
486 translated messages, 2 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o sk.mo sk.po
486 translated messages, 2 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o nl.mo nl.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o oc.mo oc.po
oc.po:12: warning: header field 'Language' still has the initial default value
85 translated messages, 26 fuzzy translations, 377 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o pl.mo pl.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o af.mo af.po
158 translated messages, 147 fuzzy translations, 183 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ta.mo ta.po
483 translated messages, 2 fuzzy translations, 3 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o am.mo am.po
am.po:9: warning: header field 'Language' still has the initial default value
121 translated messages, 49 fuzzy translations, 318 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o pt.mo pt.po
274 translated messages, 139 fuzzy translations, 75 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o he.mo he.po
45 translated messages, 135 fuzzy translations, 308 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o gl.mo gl.po
486 translated messages, 2 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o ar.mo ar.po
60 translated messages, 133 fuzzy translations, 295 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o uk.mo uk.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o as.mo as.po
485 translated messages, 1 fuzzy translation, 2 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o mk.mo mk.po
mk.po:12: warning: header field 'Language' still has the initial default value
36 translated messages, 144 fuzzy translations, 308 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o kn.mo kn.po
483 translated messages, 2 fuzzy translations, 3 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o crh.mo crh.po
431 translated messages, 37 fuzzy translations, 20 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o cs.mo cs.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o el.mo el.po
81 translated messages, 74 fuzzy translations, 333 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o it.mo it.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o is.mo is.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o xh.mo xh.po
50 translated messages, 138 fuzzy translations, 300 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o bg.mo bg.po
259 translated messages, 229 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o be.mo be.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o fr.mo fr.po
488 translated messages.
/usr/local/bin/msgfmt --verbose --check -o eu.mo eu.po
eu.po:13: warning: header field 'Language' still has the initial default value
270 translated messages, 39 fuzzy translations, 179 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o lt.mo lt.po
479 translated messages, 2 fuzzy translations, 7 untranslated messages.
/usr/local/bin/msgfmt --verbose --check -o hr.mo 

productivity/davical failing when fetching

2016-03-10 Thread Michael McConville
Apparently none of the sources are valid anymore. IIRC, this has been
happening since I started bulk building a couple months ago.


>>> From productivity/davical
===> Trying https://gitlab.com/davical-project/davical/repository/
/usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v 
https://gitlab.com/davical-project/davical/repository/archive.tar.gz?ref=r1.1.3.1
Trying 104.210.2.228...
Requesting 
https://gitlab.com/davical-project/davical/repository/archive.tar.gz?ref=r1.1.3.1
3032719 bytes received in 3.31 seconds (894.80 KB/s)
size does not match
===> Trying http://ftp.openbsd.org/pub/OpenBSD/distfiles//
/usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v 
http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
Trying 129.128.5.191...
Requesting 
http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
ftp: Error retrieving file: 404 Not Found
===> Trying ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles//
/usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v 
ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
Connected to plier.ucar.edu.
220 plier.ucar.edu FTP server ready.
331 Guest login ok, send your email address as password.
230-   Welcome to ftp.usa.OpenBSD.org in Boulder, Colorado, USA.
230-   For other mirror sites visit http://www.openbsd.org/ftp.html
230-_    _ _
230-   / ___ \   |  _ \ / |  __ \
230-  / /  / /___  ___   | |_) | (___ | |  | |
230- / /  / / __ \/ _ \/ __ \|  _ < \___ \| |  | |
230-/ /__/ / /_/ /  __/ / / /| |_) |) | |__| |
230-\_/ .___/\___/_/ /_/ |/|_/|_/
230- /_/
230-|.The proactively secure Unix-like
230-.   |L  /|   .Operating System.
230-_ . |\ _| \--+._/| .  Please visit the OpenBSD web site
230-   / ||\| Y J  )   / |/| ./  at http://www.openbsd.org/
230-  J  |)'( |` F`.'/
230--<|  F __ .-< All transfers are logged, if you don't
230-  | /   .-'. `.  /-. L___ like this policy, disconnect now!
230-  J \  <\  | | O\|.-'
230-_J \  .-\/ O | | \  |F
230-   '-F  -<_. \   .-'  `-' L__ OpenBSD 5.8 has now been released!
230-  __J  _   _. >-'  )._.   |-' You can order a CD of OpenBSD 5.8
230-  `-|.'   /_.   \_|   F   from http://www.openbsd.org/orders.html.
230-/.-   ._. Trying http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//
/usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v 
http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
Trying 145.238.209.46...
Requesting 
http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1
ftp: Error retrieving file: 404 Not Found



devel/mico failing due to failed assertion

2016-03-10 Thread Michael McConville
It's been failing reliably on my machine since I started bulk building a
couple months ago.


>>> Building on localhost under devel/mico
 BDEPENDS = [devel/gmake]
 DIST = [devel/mico:mico-2.3.13.tar.gz]
 FULLPKGNAME = mico-2.3.13p0
(Junk lock failure for localhost at 1455583281)
Received IO
(Junk lock obtained for localhost at 1455583287)
Woken up devel/mico
Woken up devel/mico
Woken up devel/mico
Short-cut: depends already handled by devel/avr/gcc
>>> Running show-prepare-results in devel/mico at 1455583287
===> devel/mico
===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0
===>  Verifying specs:  c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt 
pthread
===>  found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 
ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1
gmake-4.1p0
(Junk lock released for localhost at 1455583288)
distfiles size=3269814
>>> Running patch in devel/mico at 1455583288
===> devel/mico
===>  Checking files for mico-2.3.13p0
`/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date.
===>  Extracting for mico-2.3.13p0
===>  Patching for mico-2.3.13p0
>>> Running configure in devel/mico at 1455583290
===> devel/mico
===>  Configuring for mico-2.3.13p0
Using /home/dpb-wrk/mico-2.3.13/config.site (generated)
loading site script /home/dpb-wrk/mico-2.3.13/config.site
creating cache ./config.cache
checking for extra include and lib directories...
checking host system type... x86_64-unknown-openbsd5.9
checking target system type... x86_64-unknown-openbsd5.9
checking build system type... x86_64-unknown-openbsd5.9
checking for gcc... cc
checking whether the C compiler (cc -O2 -pipe ) works... yes
checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether cc accepts -g... (cached) yes
checking how to run the C preprocessor... cc -E
checking for c++... c++
checking whether the C++ compiler (c++ -O2 -pipe ) works... yes
checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... (cached) yes
checking how to run the C++ preprocessor... c++ -E
checking for POSIXized ISC... no
checking OS Type... unix
checking for open in -lpthread... yes
checking for pthread.h... (cached) yes
checking for sched.h... yes
checking for semaphore.h... (cached) yes
checking for bison... yacc
checking for flex... (cached) flex
checking for yywrap in -lfl... (cached) yes
checking for ar... ar rc
checking for ranlib... ranlib
checking whether gmake sets ${MAKE}... yes
checking for tclsh... tclsh
checking for javac... no
checking for JavaCUP... no
configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts 
disabled.
checking for esnacc/c++/asn-incl.h... no
checking for open in -lc++asn1... no
checking for esnacc... no
checking for smp/AttributeCertificateDefinitions.h... no
checking for open in -lcmlasn... no
checking for open in -lm... (cached) yes
checking for open in -lnsl... no
checking for X... (cached) libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... (cached) yes
checking for connect... (cached) yes
checking for remove... (cached) yes
checking for shmat... (cached) yes
checking for IceConnectionNumber in -lICE... (cached) yes
checking for open in -lsocket... no
checking for open in -lbsd... no
checking for open in -lelf... no
checking for open in -ldl... no
checking for open in -ldld... no
checking for open in -lld... no
checking for open in -lcrypto... yes
checking for open in -lssl... yes
checking for open in -lncurses... yes
checking for readline in -lreadline... yes
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/select.h... (cached) yes
checking for strings.h... (cached) yes
checking for float.h... (cached) yes
checking for ieeefp.h... yes
checking for sys/un.h... (cached) yes
checking for netinet/in.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking for netdb.h... (cached) yes
checking for dlfcn.h... (cached) yes
checking for dl.h... no
checking for netinet/tcp.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for sunmath.h... no
checking for sys/stat.h... (cached) yes
checking for poll.h... (cached) yes
checking for exception... yes
checking for exception.h... no
checking for terminate.h... no
checking for openssl/ssl.h... (cached) yes
checking for pgsql/libpq-fe.h... no
checking for qapplication.h... no
checking for qsocketnotifier.h... no
checking for qlineedit.h... no
checking for byteorder.h... no
checking for iostream... yes
checking for map... yes
checking for string... yes
checking for sstream... yes
checking for Ansi C++ headers... yes
checking for cxxabi.h... yes
checking for 

CVS: cvs.openbsd.org: ports

2016-03-10 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/03/10 02:57:19

Modified files:
net/isc-bind   : Tag: OPENBSD_5_8 Makefile distinfo 

Log message:
update to BIND 9.10.3-P4
https://kb.isc.org/article/AA-01363/81/BIND-9.10.3-P4-Release-Notes.html



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/03/10 02:38:08

Modified files:
www/py-django/lts: Tag: OPENBSD_5_8 Makefile distinfo 
www/py-django/lts/pkg: Tag: OPENBSD_5_8 PLIST 

Log message:
security fixes for 
https://www.djangoproject.com/weblog/2016/mar/01/security-releases/



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/03/10 02:31:07

Modified files:
www/py-django/lts: Makefile distinfo 
www/py-django/lts/pkg: PLIST 
www/py-django/stable: Makefile distinfo 
www/py-django/stable/pkg: PLIST 

Log message:
security updates to latest releases, addressing 
https://www.djangoproject.com/weblog/2016/mar/01/security-releases/

ok rpointel@ (MAINTAINER)



UPDATE: net/py-ripe.atlas.tools to 1.2.3 (including cousteau and sagan lib update)

2016-03-10 Thread Florian Obser
these need to go in together, older tools fails with newer libs.
works for me[tm]
OK?

diff --git py-ripe.atlas.cousteau/Makefile py-ripe.atlas.cousteau/Makefile
index acc68d4..80344b5 100644
--- py-ripe.atlas.cousteau/Makefile
+++ py-ripe.atlas.cousteau/Makefile
@@ -2,7 +2,7 @@
 
 COMMENT =  python bindings for the RIPE Atlas API
 
-MODPY_EGG_VERSION =1.0.7
+MODPY_EGG_VERSION =1.2
 DISTNAME = ripe.atlas.cousteau-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 
diff --git py-ripe.atlas.cousteau/distinfo py-ripe.atlas.cousteau/distinfo
index 8e61e15..22169dd 100644
--- py-ripe.atlas.cousteau/distinfo
+++ py-ripe.atlas.cousteau/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ripe.atlas.cousteau-1.0.7.tar.gz) = 
T5mr+emFEJF0vF2uOOlY38hdxBqHK7+RZ2Oh9TqeS2s=
-SIZE (ripe.atlas.cousteau-1.0.7.tar.gz) = 45757
+SHA256 (ripe.atlas.cousteau-1.2.tar.gz) = 
C07VFkePtqniJo3GjsqGcilh7EIJ+eVP43VkdlxWAl4=
+SIZE (ripe.atlas.cousteau-1.2.tar.gz) = 47015
diff --git py-ripe.atlas.cousteau/pkg/PLIST py-ripe.atlas.cousteau/pkg/PLIST
index dfdbe83..491c6a7 100644
--- py-ripe.atlas.cousteau/pkg/PLIST
+++ py-ripe.atlas.cousteau/pkg/PLIST
@@ -13,6 +13,10 @@ lib/python${MODPY_VERSION}/site-packages/ripe/atlas/
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/__init__.py
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/__init__.pyc
+lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_listing.py
+lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_listing.pyc
+lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_meta_data.py
+lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_meta_data.pyc
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/exceptions.py
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/exceptions.pyc
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/measurement.py
diff --git py-ripe.atlas.sagan/Makefile py-ripe.atlas.sagan/Makefile
index ad483c9..e37327f 100644
--- py-ripe.atlas.sagan/Makefile
+++ py-ripe.atlas.sagan/Makefile
@@ -2,7 +2,7 @@
 
 COMMENT =  parsing library for RIPE Atlas measurement results
 
-MODPY_EGG_VERSION =1.1.8
+MODPY_EGG_VERSION =1.1.10
 DISTNAME = ripe.atlas.sagan-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 
diff --git py-ripe.atlas.sagan/distinfo py-ripe.atlas.sagan/distinfo
index c9d3147..7bc6427 100644
--- py-ripe.atlas.sagan/distinfo
+++ py-ripe.atlas.sagan/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ripe.atlas.sagan-1.1.8.tar.gz) = 
uzlPc4VwsLDBgleFa2HHMDddkZlsjHJvnc02f9YYs9g=
-SIZE (ripe.atlas.sagan-1.1.8.tar.gz) = 100037
+SHA256 (ripe.atlas.sagan-1.1.10.tar.gz) = 
ODG/K8ZhiMV2Sz0LPA5Th7PWcNCog57UZKJExv/lKIs=
+SIZE (ripe.atlas.sagan-1.1.10.tar.gz) = 128425
diff --git py-ripe.atlas.sagan/pkg/PLIST py-ripe.atlas.sagan/pkg/PLIST
index ad74ae6..100e1f1 100644
--- py-ripe.atlas.sagan/pkg/PLIST
+++ py-ripe.atlas.sagan/pkg/PLIST
@@ -1,5 +1,4 @@
 @comment $OpenBSD: PLIST,v 1.2 2016/01/20 09:25:03 florian Exp $
-bin/parse_abuf
 lib/python${MODPY_VERSION}/site-packages/ripe/
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}-nspkg.pth
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
@@ -7,7 +6,6 @@ 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-p
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/namespace_packages.txt
-lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/pbr.json
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
 
lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/ripe/atlas/
diff --git py-ripe.atlas.tools/Makefile py-ripe.atlas.tools/Makefile
index be6c4cd..26e455c 100644
--- py-ripe.atlas.tools/Makefile
+++ py-ripe.atlas.tools/Makefile
@@ -2,7 +2,7 @@
 
 COMMENT =  official command-line client for RIPE Atlas
 
-MODPY_EGG_VERSION =1.2.2
+MODPY_EGG_VERSION =1.2.3
 DISTNAME = ripe.atlas.tools-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 
diff --git py-ripe.atlas.tools/distinfo py-ripe.atlas.tools/distinfo
index 59c6106..c624af7 100644
--- py-ripe.atlas.tools/distinfo
+++ py-ripe.atlas.tools/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ripe.atlas.tools-1.2.2.tar.gz) = 
k/htEXez3E3ZrInwi3fYCPCTFQpbCvsDUbMKYoJRoqA=
-SIZE 

UPDATE: net/py-websocket-client to 0.35.0

2016-03-10 Thread Florian Obser
tested with upcomming py-ripe.atlas.tools
OK?

diff --git py-websocket-client/Makefile py-websocket-client/Makefile
index 9f9019e..2fed175 100644
--- py-websocket-client/Makefile
+++ py-websocket-client/Makefile
@@ -2,7 +2,7 @@
 
 COMMENT =  WebSocket client for Python
 
-MODPY_EGG_VERSION =0.34.0
+MODPY_EGG_VERSION =0.35.0
 REVISION = 0
 DISTNAME = websocket_client-${MODPY_EGG_VERSION}
 PKGNAME =  py-websocket-client-${MODPY_EGG_VERSION}
diff --git py-websocket-client/distinfo py-websocket-client/distinfo
index c46c5aa..a1b2f68 100644
--- py-websocket-client/distinfo
+++ py-websocket-client/distinfo
@@ -1,2 +1,2 @@
-SHA256 (websocket_client-0.34.0.tar.gz) = 
aCpiQcqVNJnwbKUG9pqj6ibw7SpB/nmCcyy4RJrpLd8=
-SIZE (websocket_client-0.34.0.tar.gz) = 193141
+SHA256 (websocket_client-0.35.0.tar.gz) = 
WsPq0JG+F7aAoN2pJq7xppeits8emsD75L/7FJFMIRY=
+SIZE (websocket_client-0.35.0.tar.gz) = 193509


-- 
I'm not entirely sure you are real.



Re: libotr security fix

2016-03-10 Thread Stefan Sperling
On Wed, Mar 09, 2016 at 05:32:47PM -0800, Michael McConville wrote:
> Is anyone working on updates for security/libotr and
> security/pidgin-otr? There were releases addressing a scary
> vulnerability this morning:
> 
> https://marc.info/?l=otr-announce=145754687614832=2
> 
> If not, I probably have time to work on it tonight.

These should be updated, but there's no reason to hurry up very very much.

The libotr problem depends on malloc(0) returning a pointer that doesn't
segfault when it is used. On OpenBSD the program will crash at the point
where the attacker tries to overwrite the heap.
Unless there's another avenue for this exploit which doesn't use malloc(0),
but the advisory only mentions malloc(0).
See http://seclists.org/oss-sec/2016/q1/568

security/pidgin-otr has been already patched in our ports tree by me in
2015 (before 5.8). I reported this bug and they left it sit for 9 months
until Hanno Boeck reported the same problem again:
https://bugs.otr.im/issues/88
pidgin-otr crashed on OpenBSD immediately, which is why I noticed.



CVS: cvs.openbsd.org: ports

2016-03-10 Thread Kirill Bychkov
CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2016/03/10 01:40:05

Modified files:
www/goaccess   : Makefile distinfo 
www/goaccess/patches: patch-configure_ac 

Log message:
update to goaccess-0.9.8



dpb: Problem building ports whose RUN_DEPENDS have unmet BUILD_DEPENDS dependencies

2016-03-10 Thread Andreas Kusalananda Kähäri
Hi,

Quite often, dpb fails to build ports because one or several
BUILD_DEPENDS for some of the port's RUN_DEPENDS are not installed.
Sometimes, this happens after I run "pkg_delete -a", and sometimes I
think it's due to the "junking" of unneeded ports during the build (but
I'm not sure).

This happened just now, for example.  The llvm port is definitely up to
date, so py-sphinx shouldn't need to be installed, but chromium fails to
build anyway:

$ less /usr/ports/logs/amd64/packages/chromium-49.0.2623.75p0.log
>>> Building on localhost under www/chromium
 BDEPENDS = 
[devel/yasm;archivers/xz;shells/bash;lang/python/2.7;devel/gconf2;devel/gperf;lang/gcc/4.9,-c++;devel/llvm;security/nss;sysutils/flock;x11/gtk+2;x11/gnome/libgnome-keyring;devel/ninja;devel/libexecinfo;print/cups,-libs;sysutils/pciutils;textproc/libxslt;lang/gcc/4.9,-libs;devel/bison;archivers/bzip2]
 DIST = [www/chromium:chromium-49.0.2623.75.tar.xz]
 FULLPKGNAME = chromium-49.0.2623.75p0
 RDEPENDS = 
[x11/gtk+2;lang/gcc/4.9,-libs;textproc/libxslt;x11/gtk+3,-guic;security/nss;print/cups,-libs;devel/gconf2;graphics/libexif;devel/desktop-file-utils;devel/libexecinfo;devel/xdg-utils;fonts/noto/fonts;x11/gnome/libgnome-keyring]
>>> Running clean in www/chromium at 1457594571
===> www/chromium
===>  Cleaning for chromium-49.0.2623.75p0
[...]
===> Returning to build of chromium-49.0.2623.75p0
===> chromium-49.0.2623.75p0 depends on: g++->=4.9,<4.10 -> g++-4.9.3p3
===>  Verifying update for llvm->=3.7.1 in devel/llvm
===> Updating for llvm-3.7.1p0
===> llvm-3.7.1p0 depends on: py-sphinx-* - not found
Dependency check failed
*** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:2114 
'/srv/ports/pobj/llvm-3.7.1/.dep-textproc-py-sphinx')
*** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:1987 
'/srv/ports/update/amd64/llvm-3.7.1p0')
*** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:2482 
'subupdate')
*** Error 1 in www/chromium (/srv/ports/infrastructure/mk/bsd.port.mk:2114 
'/srv/ports/pobj/chromium-49.0.2623.75/.dep-STEM-ge-3.7.1-devel-llvm')
*** Error 1 in www/chromium (/srv/ports/infrastructure/mk/bsd.port.mk:2482 
'prepare')
===> Exiting www/chromium with an error
*** Error 1 in /srv/ports (infrastructure/mk/bsd.port.subdir.mk:147 
'show-prepare-results')
(Junk lock released for localhost at 1457594593)
Error: job failed 256


The ffmpeg port build failed in a similar way for exactly the same reason.


Cheers,

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF