Re: CVS: cvs.openbsd.org: ports

2016-02-17 Thread Tobias Ulmer
On Wed, Feb 17, 2016 at 05:42:22AM -0700, Stuart Henderson wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   st...@cvs.openbsd.org   2016/02/17 05:42:22
> 
> Modified files:
>   devel/libmemcached: Makefile 
>   devel/libmemcached/pkg: PLIST 
> Removed files:
>   devel/libmemcached/pkg: PFRAG.atomic 
> 
> Log message:
> Remove special handling in libmemcached for a strange list of supposedly
> "!atomic" arches, packaging is broken on all but the whitelisted arches due
> to changes upstream since this handling was added. Unbreaks powerpc, may
> unbreak others, won't break any which currently work. If any remain broken
> after this, they can be looked at separately later.
> 
> zhuk@ landry@ agree with this direction.
> 

Remains broken on sparc, should I add a BROKEN-sparc?



CVS: cvs.openbsd.org: ports

2016-02-17 Thread Tobias Ulmer
CVSROOT:/cvs
Module name:ports
Changes by: tobi...@cvs.openbsd.org 2016/02/17 18:25:58

Modified files:
devel/sparsehash: Makefile 

Log message:
mark broken on sparc, g++ requires more than 256MB to compile this



CVS: cvs.openbsd.org: ports

2016-02-17 Thread Robert Nagy
CVSROOT:/cvs
Module name:ports
Changes by: rob...@cvs.openbsd.org  2016/02/17 06:33:29

Modified files:
www/chromium   : Makefile distinfo 

Log message:
security update to 48.0.2564.109; ok sthen@, naddy@



CVS: cvs.openbsd.org: ports

2016-02-17 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2016/02/17 05:42:22

Modified files:
devel/libmemcached: Makefile 
devel/libmemcached/pkg: PLIST 
Removed files:
devel/libmemcached/pkg: PFRAG.atomic 

Log message:
Remove special handling in libmemcached for a strange list of supposedly
"!atomic" arches, packaging is broken on all but the whitelisted arches due
to changes upstream since this handling was added. Unbreaks powerpc, may
unbreak others, won't break any which currently work. If any remain broken
after this, they can be looked at separately later.

zhuk@ landry@ agree with this direction.