CVS: cvs.openbsd.org: ports

2015-08-05 Thread Tobias Ulmer
CVSROOT:/cvs
Module name:ports
Changes by: tobi...@cvs.openbsd.org 2015/08/05 16:49:59

Modified files:
devel/csmith   : Makefile 
devel/csmith/patches: patch-src_platform_cpp 

Log message:
Use arc4random instead of x86/powerpc specific cpu time counters as a
random seed.
Unbreaks all non-x86 architectures.

ok daniel@, post-ports-lock ok from sthen@



CVS: cvs.openbsd.org: ports

2015-08-05 Thread Stefan Sperling
CVSROOT:/cvs
Module name:ports
Changes by: s...@cvs.openbsd.org2015/08/05 16:09:12

Modified files:
devel/subversion: Makefile distinfo 

Log message:
Update to Subversion 1.8.14. Fixes CVE-2015-3184 and CVE-2015-3187.
ok sthen@



Re: CVS: cvs.openbsd.org: ports (fwd) (fwd) (fwd)

2015-08-05 Thread Martin Pieuchot
On 04/08/15(Tue) 17:49, Stuart Henderson wrote:
> On 2015/08/03 14:49, Martin Pieuchot wrote:
> > On 03/08/15(Mon) 14:15, Pascal Stumpf wrote:
> > > I actually follow that practice for most games I maintain that require a
> > > "beefier" machine, although they may build and package just fine on
> > > !(amd64 || i386): vegastrike, speeddreams, flightgear, sumwars.  I
> > > believe enabling those on powerpc would only increase bulk build times
> > > for very little gain.
> > 
> > What you say is true for... let me guess... 95% of the ports we build on
> > such architecture.  Should we stop building packages then?
> 
> While I generally agree, these 5 particular ports account for 3.5GB
> of packages per arch. File distribution from the fanout to some of the
> 2nd-level mirrors has never been particularly fast (plus it takes a
> while to gzip this amount of data on a machine with slower CPU and
> disks, and build times there are already pretty long) so disabling
> these particular ports on arch where they aren't playable makes
> a lot of sense to me.

Indeed, that makes sense to me too.