Re: Need an advice about DHCP IPv6 server software

[kasak]

> 6 дек. 2017 г., в 9:14, Denis  написал(а):
> 
> Hi All,
> 
> I have working OpenBSD based IPv4 router, but now need to add IPv6
> functionality to the same router box with keeping all IPv4 services.
> 
> I've set aliases with IPv6 addresses for all the adapters in
> /etc/hostname.if  and added filtering rules for IPv6 to PF.
> 
> Stuck with IPv6 DHCP server piece of software. Which one do I need to
> have IPv6 DHCP server functionality? The best solution is to use
> implemented into OpenBSD, no packaged one.
> 
> Please recommend some. Any examples will be useful too.
> 
> Thank you.
> 
> 
> 
> 
> 
IMO, ipv6 was designed to include router advertisement so there is no need of 
dhcp.
I prefer to use rtadvd implemented in OpenBSD

ups, forgot to include misc in answer

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/06 00:49:55

Modified files:
sysutils/awscli: Makefile distinfo 

Log message:
Update to awscli-1.14.4.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/06 00:49:42

Modified files:
net/py-botocore: Makefile distinfo 
net/py-botocore/pkg: PLIST 

Log message:
Update to py-botocore-1.8.8.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/06 00:46:25

Modified files:
www/py-bokeh   : Makefile distinfo 
www/py-bokeh/pkg: PLIST 

Log message:
Update to py-bokeh-0.12.12.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/05 23:38:12

Modified files:
www/owncloud   : Tag: OPENBSD_6_2 Makefile distinfo 
www/owncloud/patches: Tag: OPENBSD_6_2 patch-version_php 
www/owncloud/pkg: Tag: OPENBSD_6_2 PLIST 

Log message:
Update to the latest stable release (owncloud-10.0.4) to ease updating
when moving from OpenBSD 6.2->6.3

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/05 23:35:49

Modified files:
www/owncloud   : Makefile distinfo 
www/owncloud/patches: patch-version_php 
www/owncloud/pkg: PLIST 

Log message:
Update to owncloud-10.0.4.

Re: CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

On Tue, Dec 05, 2017 at 07:58:55PM +, Pascal Stumpf wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   pas...@cvs.openbsd.org  2017/12/05 12:58:55
> 
> Modified files:
>   devel/bullet   : Makefile distinfo 
>   devel/bullet/pkg: PLIST 
> Removed files:
>   devel/bullet/patches: patch-examples_BasicDemo_CMakeLists_txt 
> patch-examples_ExampleBrowser_CMakeLists_txt 
> patch-examples_OpenGLWindow_CMakeLists_txt 
> patch-examples_SharedMemory_CMakeLists_txt 
> patch-examples_SimpleOpenGL3_CMakeLists_txt 
> patch-examples_ThirdPartyLibs_Gwen_Macros_h 
> 
> Log message:
> Update Bullet to 2.87.

Doesn't build.

>>> Building on exopi-2 under devel/bullet
 BDEPENDS = [devel/ninja;devel/cmake;graphics/freeglut]
 DIST = [devel/bullet:bullet-2.87.tar.gz]
 FULLPKGNAME = bullet-2.87
(Junk lock obtained for exopi-2 at 1512514358)
>>> Running depends in devel/bullet at 1512514358
   last junk was in net/tcl-snmptools
/usr/sbin/pkg_add -aI -Dunsigned -Drepair freeglut-3.0.0
was: /usr/sbin/pkg_add -aI -Dunsigned -Drepair cmake-3.9.3 freeglut-3.0.0 
ninja-1.8.2
/usr/sbin/pkg_add -aI -Dunsigned -Drepair freeglut-3.0.0
>>> Running show-prepare-results in devel/bullet at 1512514360
===> devel/bullet
===> bullet-2.87 depends on: freeglut-* -> freeglut-3.0.0
===> bullet-2.87 depends on: cmake-* -> cmake-3.9.3
===> bullet-2.87 depends on: ninja->=1.5.1 -> ninja-1.8.2
===>  Verifying specs:  c++ c++abi pthread m
===>  found c++.1.0 c++abi.0.0 pthread.25.1 m.10.0
cmake-3.9.3
freeglut-3.0.0
ninja-1.8.2
(Junk lock released for exopi-2 at 1512514361)
distfiles size=56691047
>>> Running patch in devel/bullet at 1512514361
===> devel/bullet
===>  Checking files for bullet-2.87
`/exopi-cvs/ports/distfiles/bullet-2.87.tar.gz' is up to date.
>> (SHA256) bullet-2.87.tar.gz: OK
===>  Extracting for bullet-2.87
===>  Patching for bullet-2.87
===>  Compiler link: clang -> /usr/bin/clang
===>  Compiler link: clang++ -> /usr/bin/clang++
===>  Compiler link: cc -> /usr/bin/cc
===>  Compiler link: c++ -> /usr/bin/c++
>>> Running configure in devel/bullet at 1512514368
===> devel/bullet
===>  Configuring for bullet-2.87
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /exopi-obj/pobj/bullet-2.87/bin/cc
-- Check for working C compiler: /exopi-obj/pobj/bullet-2.87/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /exopi-obj/pobj/bullet-2.87/bin/c++
-- Check for working CXX compiler: /exopi-obj/pobj/bullet-2.87/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
BSD?
-- Found OpenGL: /usr/X11R6/lib/libGL.so.17.1  
OPENGL FOUND
/usr/X11R6/lib/libGLU.so.9.0/usr/X11R6/lib/libGL.so.17.1
-- Found PythonInterp: /usr/local/bin/python3 (found version "3.6.3") 
-- Looking for versions: 3.6.3;3.6
-- Looking for python version '3.6.3' by checking executables: 
/usr/local/bin/python3;python;python3;python3.6.
-- Found executable /usr/local/bin/python3 with suitable version 3.6.3
-- Found PythonLibs: /usr/local/lib/libpython3.6m.so.0.0 (found suitable exact 
version "3.6.3") 
-- Found PythonLibs: /usr/local/lib/libpython3.6m.so.0.0 (found version 
"3.6.3") 
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /exopi-obj/pobj/bullet-2.87/build-amd64
>>> Running build in devel/bullet at 1512514371
===> devel/bullet
===>  Building for bullet-2.87
[1/939] /exopi-obj/pobj/bullet-2.87/bin/c++  -DBT_ENABLE_CLSOCKET 
-DBT_ENABLE_ENET -DBulletRobotics_EXPORTS -DHAS_SOCKLEN_T 
-DPHYSICS_SERVER_DIRECT -DUSE_GRAPHICAL_BENCHMARK -D_BSD 
-I/exopi-obj/pobj/bullet-2.87/bullet3-2.87/src 
-I/exopi-obj/pobj/bullet-2.87/bullet3-2.87/examples 
-I/exopi-obj/pobj/bullet-2.87/bullet3-2.87/examples/ThirdPartyLibs 
-I/exopi-obj/pobj/bullet-2.87/bullet3-2.87/examples/ThirdPartyLibs/enet/include 
-I/exopi-obj/pobj/bullet-2.87/bullet3-2.87/examples/ThirdPartyLibs/clsocket/src 
-O2 -pipe  -I/usr/X11R6/include -DNDEBUG -fPIC -MD -MT 
Extras/BulletRobotics/CMakeFiles/BulletRobotics.dir/__/__/examples/SharedMemory/PosixSharedMemory.o
 -MF 
Extras/BulletRobotics/CMakeFiles/BulletRobotics.dir/__/__/examples/SharedMemory/PosixSharedMemory.o.d
 -o 

[NEW] databases/tdbc-mysql

[Stuart Cassoff]

Provides a database interface that conforms to Tcl DataBase Connectivity (TDBC)
and allows a Tcl script to connect to a MariaDB database.

Tested on i386 and amd64.

OK?

tdbc-mysql-1.0.5-port.tar.gz
Description: application/gzip

Re: [NEW] databases/tdbc-postgres

[Stuart Cassoff]

ping

> -- Original Message --
> From: Stuart Cassoff <3...@bell.net>
> Date: November 24, 2017 at 3:44 PM
> 
> 
> ping
> 
> > -- Original Message --
> > From: Stuart Cassoff <3...@bell.net>
> > Date: November 20, 2017 at 12:32 AM
> > 
> > 
> > ping
> > 
> > > -- Original Message --
> > > From: Stuart Cassoff <3...@bell.net>
> > > Date: November 12, 2017 at 6:45 AM
> > > 
> > > 
> > > ping
> > > 
> > > > -- Original Message --
> > > > From: Stuart Cassoff <3...@bell.net>
> > > > Date: November 4, 2017 at 3:02 PM
> > > > 
> > > > 
> > > > Provides a database interface that conforms to Tcl DataBase 
> > > > Connectivity (TDBC)
> > > > and allows a Tcl script to connect to a PostgreSQL database.
> > > > 
> > > > Tested on i386 and amd64 - in Canada!
> > > > 
> > > > 
> > > > Stu
> > >
> >
>

CVS: cvs.openbsd.org: ports

[Stuart Cassoff]

CVSROOT:/cvs
Module name:ports
Changes by: s...@cvs.openbsd.org2017/12/05 22:48:57

Modified files:
databases/tdbc : Makefile 
Added files:
databases/tdbc/patches: patch-library_tdbc_tcl 

Log message:
Ensure consistent results. From upstream.

CVS: cvs.openbsd.org: ports

[Jeremie Courreges-Anglas]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/12/05 17:29:52

Modified files:
graphics/jasper: Makefile 

Log message:
Fix HOMEPAGE and MASTER_SITES, move to https

(We're using a 10 years old release when upstream has published
JasPer-2.0.14 earlier this year.)

Re: enable build of graphics/libraw on gcc4 arches

[Jeremie Courreges-Anglas]

On Sun, Dec 03 2017, "Kirill Bychkov"  wrote:
> Hi!
> This patch enables build of libraw on other gcc4 arches, not only arm.
> Tested on macppc.
> OK?

This looks heavy-handed to me, why extend this to all non-clang archs,
afaik base-gcc has support for 4-bytes atomics on powerpc.  How does the
build fail exactly?

> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/libraw/Makefile,v
> retrieving revision 1.29
> diff -u -r1.29 Makefile
> --- Makefile16 Nov 2017 23:20:39 -  1.29
> +++ Makefile3 Dec 2017 07:51:00 -
> @@ -23,8 +23,6 @@
>  MASTER_SITES = https://www.libraw.org/data/
>
>  COMPILER = base-clang ports-gcc
> -# for atomic builtins (__sync_fetch_and_add_4)
> -MODGCC4_ARCHS =arm
>
>  LIB_DEPENDS =  graphics/jasper \
> graphics/lcms2
>
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: [UPDATE] archivers/fuse-zip

[Helg]

On Tue, Dec 05, 2017 at 09:41:17PM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Dec 05 2017, Helg  wrote:
> > Hi ports@,
> >
> > Update from 0.4.2 => 0.4.4
> >
> > I've been working with the developer of fuse-zip to add the FUSE mknod
> > operation. This is now mandatory for FUSE ports on OpenbSD after I
> > removed the incorrect implementation of create from the kernel and
> > libfuse.
> >
> > This version also fixes an "off-by-one" bug that caused fuse-zip to fail
> > with either a Segementation fault of Bus error when copying a sparse
> > file.
> >
> > License has changed from LGPL to GPL.
> >
> > ok?
> 
> LGTM, ok jca@
> 
> While here, could you please re-enable the test target, previously named
> "test", now named "check".  You just need to add TEST_TARGET=check to
> the port's Makefile.

Thanks. TEST_TARGET added and all tests passed.

CVS: cvs.openbsd.org: ports

[Helg Bredow]

CVSROOT:/cvs
Module name:ports
Changes by: h...@cvs.openbsd.org2017/12/05 16:58:01

Modified files:
archivers/fuse-zip: Makefile distinfo 
archivers/fuse-zip/pkg: PLIST 

Log message:
Update from 0.4.2 => 0.4.4
Adds FUSE mknod operation, which is now mandatory on OpenBSD.
Re-enabled TEST_TARGET.

ok jca@

CVS: cvs.openbsd.org: ports

[Jeremie Courreges-Anglas]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/12/05 16:28:56

Modified files:
shells/zsh : Makefile distinfo 
shells/zsh/patches: patch-Completion_BSD_Command__bsd_pkg 
shells/zsh/pkg : PLIST 

Log message:
Update to zsh-5.4.2

>From Matthew Martin, ok pea@ (maintainer)

Re: [UPDATE] archivers/fuse-zip

[Klemens Nanni]

On Tue, Dec 05, 2017 at 10:43:51PM +0100, Antoine Jacoutot wrote:
> On Tue, Dec 05, 2017 at 09:39:44PM +, Klemens Nanni wrote:
> > On Tue, Dec 05, 2017 at 07:17:33AM +0800, Helg wrote:
> > > Hi ports@,
> > > 
> > > Update from 0.4.2 => 0.4.4
> > > 
> > > I've been working with the developer of fuse-zip to add the FUSE mknod
> > > operation. This is now mandatory for FUSE ports on OpenbSD after I
> > > removed the incorrect implementation of create from the kernel and
> > > libfuse.
> > > 
> > > This version also fixes an "off-by-one" bug that caused fuse-zip to fail
> > > with either a Segementation fault of Bus error when copying a sparse
> > > file.
> > > 
> > > License has changed from LGPL to GPL.
> > > 
> > > ok?
> > I find it confusing to symlink gmake in do-configure instead of
> > pre-build or so. In fact, this is only required for the test suite as
> > the main Makefile uses $(MAKE).
> > 
> > Attached diff changes that besides adding TEST_TARGET=check (as already
> > mentioned by jca@).
> > 
> > I also removed the CVS tag hunk from your PLIST diff.
> > 
> > diff --git a/archivers/fuse-zip/Makefile b/archivers/fuse-zip/Makefile
> > index 62e32780149..f6f46c37af8 100644
> > --- a/archivers/fuse-zip/Makefile
> > +++ b/archivers/fuse-zip/Makefile
> > @@ -2,13 +2,13 @@
> >  
> >  COMMENT =  navigate zip archives through FUSE
> >  
> > -DISTNAME = fuse-zip-0.4.2
> > +DISTNAME = fuse-zip-0.4.4
> >  
> >  CATEGORIES =   archivers
> >  
> >  HOMEPAGE = https://bitbucket.org/agalanin/fuse-zip
> >  
> > -# LGPLv3+
> > +# GPLv3+
> >  PERMIT_PACKAGE_CDROM = Yes
> >  
> >  WANTLIB += c fuse m ${COMPILER_LIBCXX} z zip
> > @@ -23,8 +23,10 @@ FAKE_FLAGS = 
> > INSTALLPREFIX="${WRKINST}${PREFIX}"
> >  
> >  USE_GMAKE =Yes
> >  
> > -do-configure:
> > -   ln -s ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
> > +TEST_TARGET =  check
> > +
> > +pre-test:
> > +   ln -sf ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
> 
> Ugly.
> Can't you use ${MAKE_PROGRAM} instead?
${LOCALBASE}/bin/${MAKE_PROGRAM} only works for USE_GMAKE=Yes anyway
which is just as ugly.

tests/Makefile should simply use/pick up the make program used for the
main Makefile.

Re: [UPDATE] archivers/fuse-zip

[Jeremie Courreges-Anglas]

On Tue, Dec 05 2017, Antoine Jacoutot  wrote:

[...]

>> @@ -23,8 +23,10 @@ FAKE_FLAGS =  
>> INSTALLPREFIX="${WRKINST}${PREFIX}"
>>  
>>  USE_GMAKE = Yes
>>  
>> -do-configure:
>> -ln -s ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
>> +TEST_TARGET =   check
>> +
>> +pre-test:
>> +ln -sf ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
>
> Ugly.
> Can't you use ${MAKE_PROGRAM} instead?

I'm not sure ${MAKE_PROGRAM} would buy you much here.  What do you have
in mind?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: [UPDATE] archivers/fuse-zip

[Antoine Jacoutot]

On Tue, Dec 05, 2017 at 09:39:44PM +, Klemens Nanni wrote:
> On Tue, Dec 05, 2017 at 07:17:33AM +0800, Helg wrote:
> > Hi ports@,
> > 
> > Update from 0.4.2 => 0.4.4
> > 
> > I've been working with the developer of fuse-zip to add the FUSE mknod
> > operation. This is now mandatory for FUSE ports on OpenbSD after I
> > removed the incorrect implementation of create from the kernel and
> > libfuse.
> > 
> > This version also fixes an "off-by-one" bug that caused fuse-zip to fail
> > with either a Segementation fault of Bus error when copying a sparse
> > file.
> > 
> > License has changed from LGPL to GPL.
> > 
> > ok?
> I find it confusing to symlink gmake in do-configure instead of
> pre-build or so. In fact, this is only required for the test suite as
> the main Makefile uses $(MAKE).
> 
> Attached diff changes that besides adding TEST_TARGET=check (as already
> mentioned by jca@).
> 
> I also removed the CVS tag hunk from your PLIST diff.
> 
> diff --git a/archivers/fuse-zip/Makefile b/archivers/fuse-zip/Makefile
> index 62e32780149..f6f46c37af8 100644
> --- a/archivers/fuse-zip/Makefile
> +++ b/archivers/fuse-zip/Makefile
> @@ -2,13 +2,13 @@
>  
>  COMMENT =navigate zip archives through FUSE
>  
> -DISTNAME =   fuse-zip-0.4.2
> +DISTNAME =   fuse-zip-0.4.4
>  
>  CATEGORIES = archivers
>  
>  HOMEPAGE =   https://bitbucket.org/agalanin/fuse-zip
>  
> -# LGPLv3+
> +# GPLv3+
>  PERMIT_PACKAGE_CDROM =   Yes
>  
>  WANTLIB += c fuse m ${COMPILER_LIBCXX} z zip
> @@ -23,8 +23,10 @@ FAKE_FLAGS =   
> INSTALLPREFIX="${WRKINST}${PREFIX}"
>  
>  USE_GMAKE =  Yes
>  
> -do-configure:
> - ln -s ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
> +TEST_TARGET =check
> +
> +pre-test:
> + ln -sf ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make

Ugly.
Can't you use ${MAKE_PROGRAM} instead?

Re: [UPDATE] archivers/fuse-zip

[Klemens Nanni]

On Tue, Dec 05, 2017 at 07:17:33AM +0800, Helg wrote:
> Hi ports@,
> 
> Update from 0.4.2 => 0.4.4
> 
> I've been working with the developer of fuse-zip to add the FUSE mknod
> operation. This is now mandatory for FUSE ports on OpenbSD after I
> removed the incorrect implementation of create from the kernel and
> libfuse.
> 
> This version also fixes an "off-by-one" bug that caused fuse-zip to fail
> with either a Segementation fault of Bus error when copying a sparse
> file.
> 
> License has changed from LGPL to GPL.
> 
> ok?
I find it confusing to symlink gmake in do-configure instead of
pre-build or so. In fact, this is only required for the test suite as
the main Makefile uses $(MAKE).

Attached diff changes that besides adding TEST_TARGET=check (as already
mentioned by jca@).

I also removed the CVS tag hunk from your PLIST diff.

diff --git a/archivers/fuse-zip/Makefile b/archivers/fuse-zip/Makefile
index 62e32780149..f6f46c37af8 100644
--- a/archivers/fuse-zip/Makefile
+++ b/archivers/fuse-zip/Makefile
@@ -2,13 +2,13 @@
 
 COMMENT =  navigate zip archives through FUSE
 
-DISTNAME = fuse-zip-0.4.2
+DISTNAME = fuse-zip-0.4.4
 
 CATEGORIES =   archivers
 
 HOMEPAGE = https://bitbucket.org/agalanin/fuse-zip
 
-# LGPLv3+
+# GPLv3+
 PERMIT_PACKAGE_CDROM = Yes
 
 WANTLIB += c fuse m ${COMPILER_LIBCXX} z zip
@@ -23,8 +23,10 @@ FAKE_FLAGS = INSTALLPREFIX="${WRKINST}${PREFIX}"
 
 USE_GMAKE =Yes
 
-do-configure:
-   ln -s ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
+TEST_TARGET =  check
+
+pre-test:
+   ln -sf ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
 
 post-install:
${INSTALL_PROGRAM} ${WRKBUILD}/fuse-zip ${PREFIX}/bin
diff --git a/archivers/fuse-zip/distinfo b/archivers/fuse-zip/distinfo
index f22a25f677a..6e52da6b426 100644
--- a/archivers/fuse-zip/distinfo
+++ b/archivers/fuse-zip/distinfo
@@ -1,2 +1,2 @@
-SHA256 (fuse-zip-0.4.2.tar.gz) = PU7hE9THkYrTxmD4CIRz1fq/Z7NHb+8W7H9b2KQYL9w=
-SIZE (fuse-zip-0.4.2.tar.gz) = 672323
+SHA256 (fuse-zip-0.4.4.tar.gz) = xGSmPKfMFu73wUA2/gmCPKnZag71MOJ0hFBEpUQOR9I=
+SIZE (fuse-zip-0.4.4.tar.gz) = 687132
diff --git a/archivers/fuse-zip/pkg/PLIST b/archivers/fuse-zip/pkg/PLIST
index 195d6cafe8c..2e6c01d97f9 100644
--- a/archivers/fuse-zip/pkg/PLIST
+++ b/archivers/fuse-zip/pkg/PLIST
@@ -2,5 +2,5 @@
 @bin bin/fuse-zip
 @man man/man1/fuse-zip.1
 share/doc/fuse-zip/
-share/doc/fuse-zip/README
+share/doc/fuse-zip/README.md
 share/doc/fuse-zip/changelog

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/05 14:27:04

Modified files:
x11/gnome/user-docs: Makefile distinfo 
x11/gnome/user-docs/pkg: PLIST 

Log message:
Update to gnome-user-docs-3.26.2.1.

CVS: cvs.openbsd.org: ports

[Pascal Stumpf]

CVSROOT:/cvs
Module name:ports
Changes by: pas...@cvs.openbsd.org  2017/12/05 14:04:07

Modified files:
archivers/brotli: Makefile distinfo 
archivers/brotli/pkg: PLIST 

Log message:
Update to brotli 1.0.2; install brotli.1 manpage.

Re: [UPDATE] archivers/fuse-zip

[Jeremie Courreges-Anglas]

On Tue, Dec 05 2017, Helg  wrote:
> Hi ports@,
>
> Update from 0.4.2 => 0.4.4
>
> I've been working with the developer of fuse-zip to add the FUSE mknod
> operation. This is now mandatory for FUSE ports on OpenbSD after I
> removed the incorrect implementation of create from the kernel and
> libfuse.
>
> This version also fixes an "off-by-one" bug that caused fuse-zip to fail
> with either a Segementation fault of Bus error when copying a sparse
> file.
>
> License has changed from LGPL to GPL.
>
> ok?

LGTM, ok jca@

While here, could you please re-enable the test target, previously named
"test", now named "check".  You just need to add TEST_TARGET=check to
the port's Makefile.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: NEW FEATURE: PORTS_PRIVSEP (mostly) complete

[Antoine Jacoutot]

On Tue, Dec 05, 2017 at 06:07:04PM +, Marc Espie wrote:
> This is a result from the p2k17 hackathon in Berlin actually...
> 
> Sometimes these things take some time to complete.
> 
> Some time ago, I implemented privilege separation in dpb, and it was good:
> you could run dpb as root, have it drop its privilege to either _pbuild
> or _pfetch before building/fetching anything, and it would work.
> 
> Thus making ports building somewhat less insecure, to the great benefit of
> bulk-builders.
> 
> 
> As usual, security is a trade-off, this gave us two worlds: one where people
> would work on ports, and one where people would bulk-build ports...
> 
> Try to fix an issue on a port that failed with dpb run in privsep mode, 
> and you will understand the pain: you can write nowhere as a normal user.
> 
> So, most of us took the lazy way, and ran a few fixes as root. Ouchie. Not
> a good idea.
> 
> I had a nagging failing this was a bad idea, and talking with pirofti@, we
> decided it might be fixable somehow.
> 
> A few days after p2k17, I committed some undocumented feature, PORTS_PRIVSEP,
> that would make this less painful: it would allow your average user (with doas
> rights, obviously) to switch to _pbuild/_pfetch for common directories such
> as distfiles or packages.
> 
> It's not my habit to commit undocumented features. The main reason for that
> was that the feature was somewhat unfinished, the main part of the ports
> tree, aka the BUILD part, was still run as normal user.
> 
> After a much more extensive patch, and some painful checks (turned out to
> not be that trivial), I've finally committed (and documented) the second
> part of PORTS_PRIVSEP.
> 
> So ports/dpb builds should now be somewhat better integrated.
> 
> Let me explain what's going on.
> 
> - PORTS_PRIVSEP defaults as No, so business as usual.
> 
> - If you turn PORTS_PRIVSEP=Yes, then the ports tree will sprinkle
> doas -u _pbuild and doas -u _pfetch   in many, many places in bsd.port.mk,
> so that a build will be mostly identical to what dpb does when run as root.
> - you can of course override _pbuild and _pfetch as BUILD_USER or FETCH_USER.

As a regular "bulker", I think this is absolutely great.
I do wonder why we need BUILD_USER and FETCH_USER and not just hardcode it to
the default _pbuild and _pfetch.

-- 
Antoine

CVS: cvs.openbsd.org: ports

[Matthias Kilian]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2017/12/05 13:21:19

Modified files:
lang/ghc   : Makefile 
Added files:
lang/ghc/patches: patch-iserv_ghc_mk 

Log message:
Prepare new bootstrapper based on ghc-8.0.1 for use with ghc-8.0.2
or ghc-8.2.x (yet untested).

Also, don't build iserv with -threading if multithreading is disabled
(which is the case for the bootstrappers we build). I could also have
patched out iserv from the bindist targets, but this way it's simpler.

CVS: cvs.openbsd.org: ports

[Pascal Stumpf]

CVSROOT:/cvs
Module name:ports
Changes by: pas...@cvs.openbsd.org  2017/12/05 12:59:13

Modified files:
games/openmw   : Makefile distinfo 
games/openmw/patches: patch-apps_openmw_main_cpp 
games/openmw/pkg: PLIST 

Log message:
Update OpenMW to 0.43.0.

CVS: cvs.openbsd.org: ports

[Pascal Stumpf]

CVSROOT:/cvs
Module name:ports
Changes by: pas...@cvs.openbsd.org  2017/12/05 12:58:55

Modified files:
devel/bullet   : Makefile distinfo 
devel/bullet/pkg: PLIST 
Removed files:
devel/bullet/patches: patch-examples_BasicDemo_CMakeLists_txt 
  patch-examples_ExampleBrowser_CMakeLists_txt 
  patch-examples_OpenGLWindow_CMakeLists_txt 
  patch-examples_SharedMemory_CMakeLists_txt 
  patch-examples_SimpleOpenGL3_CMakeLists_txt 
  patch-examples_ThirdPartyLibs_Gwen_Macros_h 

Log message:
Update Bullet to 2.87.

CVS: cvs.openbsd.org: ports

[Jeremie Courreges-Anglas]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/12/05 12:24:14

Modified files:
x11/netwmpager : Makefile 

Log message:
Print build commands

NEW FEATURE: PORTS_PRIVSEP (mostly) complete

[Marc Espie]

This is a result from the p2k17 hackathon in Berlin actually...

Sometimes these things take some time to complete.

Some time ago, I implemented privilege separation in dpb, and it was good:
you could run dpb as root, have it drop its privilege to either _pbuild
or _pfetch before building/fetching anything, and it would work.

Thus making ports building somewhat less insecure, to the great benefit of
bulk-builders.


As usual, security is a trade-off, this gave us two worlds: one where people
would work on ports, and one where people would bulk-build ports...

Try to fix an issue on a port that failed with dpb run in privsep mode, 
and you will understand the pain: you can write nowhere as a normal user.

So, most of us took the lazy way, and ran a few fixes as root. Ouchie. Not
a good idea.

I had a nagging failing this was a bad idea, and talking with pirofti@, we
decided it might be fixable somehow.

A few days after p2k17, I committed some undocumented feature, PORTS_PRIVSEP,
that would make this less painful: it would allow your average user (with doas
rights, obviously) to switch to _pbuild/_pfetch for common directories such
as distfiles or packages.

It's not my habit to commit undocumented features. The main reason for that
was that the feature was somewhat unfinished, the main part of the ports
tree, aka the BUILD part, was still run as normal user.

After a much more extensive patch, and some painful checks (turned out to
not be that trivial), I've finally committed (and documented) the second
part of PORTS_PRIVSEP.

So ports/dpb builds should now be somewhat better integrated.

Let me explain what's going on.

- PORTS_PRIVSEP defaults as No, so business as usual.

- If you turn PORTS_PRIVSEP=Yes, then the ports tree will sprinkle
doas -u _pbuild and doas -u _pfetch   in many, many places in bsd.port.mk,
so that a build will be mostly identical to what dpb does when run as root.
- you can of course override _pbuild and _pfetch as BUILD_USER or FETCH_USER.

- This gives some amount of security to the ports tree.   bsd.port.mk is still
run as you (obviously), but almost anything in individual makefiles will be
run as _pbuild, or _pfetch.
Those two users should *never* have any doas capabilities. And _pbuild no 
longer has any kind of network access (we fixed this in default pf.conf)

So, yes, it is privilege separation. Not perfect. But better than before.


- The most important part is that *this allows people to run dpb and to
do manual fixes in the ports tree* without compromising on permissions.

Thus making things simple again.


A few "small details (or not so small) remain:

- WRKDIR should be (mostly) readable. I introduced FIX_EXTRACT_PERMISSIONS
to fix that, and I've fixed over half the ports tree by now. This makes things
waaay less painful in general.

- most dpb privsep run are from within a chroot... where often doas is not
configured... and which are mounted nosuid... so this doesn't QUITE work.
I've figured out that doas works when run as root even when notsuid, but it
still needs a configuration.   I have no idea how to make this simpler.
(the clunky security way I have is a single directory within a very small
mountpoint with a doas setuid binary, along with a doas.conf for the chroot)


Now for a bit of gloating. In order to test this, I had to go back to build
ports manually again, to make sure I didn't miss any part. And boy, is it
painful and slooow compared to dpb.  Nothing makes it as obvious that a tool
is cool and useful and fast than having to go without it and realize how
much you miss it. :)

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2017/12/05 10:46:43

Modified files:
infrastructure/mk: bsd.port.mk pkgpath.mk 

Log message:
next stage of PORTS_PRIVSEP: run most steps of the build under
BUILD_USER (aka _pbuild usually)

as far as I know, only _DEPFILE stuff is left out for now.

Tested on roughly 6000 ports without any ill effects

based on an initial remark by pirofti@

Re: WANTLIB is unmaintainable (was: Re: update: shells/zsh 5.4.2)

[Stuart Henderson]

On 2017/12/05 12:16, Marc Espie wrote:
> Apart from the fact that automatic generation won't work and break package
> updates completely, what do you suggest ?...
> 
> Seriously. This is not a simple problem
> 

Another way it /could/ be done is FreeBSD-style bumping dependent ports
when a dependency change forces an update. But (even speaking as one
of the people doing periodic WANTLIB syncs) I'm honestly happier with
WANTLIB than I am with that.

Many of these chagnes would be easier to handle if portbump's WANTLIB
functions worked a bit better.

Re: NEW: textproc/pplatex

[Jeremie Courreges-Anglas]

On Tue, Dec 05 2017, Paul Irofti  wrote:
>> should the LIB_DEPENDS be turned into a BULID_DEPENDS, because portcheck
>> complains that pcre is not a dependency.
>
> Fixed by adding the libraries in WANTLIB, thanks to jca@!

Lightly tested, LGTM.  ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2017/12/05 09:50:10

Modified files:
net/rrdtool: Makefile 
Added files:
net/rrdtool/patches: patch-src_rrd_create_c 

Log message:
avoid non-thread-safe umask use; found by semarie, I used a slightly different
diff than upstream used.

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2017/12/05 09:25:46

Modified files:
devel/p5-B-Hooks-OP-Check: Makefile 
devel/p5-BSD-Resource: Makefile 
devel/p5-Carp-Datum: Makefile 
devel/p5-Class-C3-Adopt-NEXT: Makefile 
devel/p5-Class-C3-XS: Makefile 
devel/p5-Class-Load-XS: Makefile 
devel/p5-Devel-Declare: Makefile 
devel/p5-Devel-NYTProf: Makefile 
devel/p5-Devel-PartialDump: Makefile 
devel/p5-File-Find-Rule-Perl: Makefile 
devel/p5-Hook-LexWrap: Makefile 
devel/p5-Import-Into: Makefile 
devel/p5-MooseX-AttributeHelpers: Makefile 
devel/p5-MooseX-Declare: Makefile 
devel/p5-MooseX-Storage: Makefile 
devel/p5-MooseX-Types-LoadableClass: Makefile 
devel/p5-MooseX-Types-Path-Class: Makefile 
devel/p5-POE-Loop-Event: Makefile 
devel/p5-POE-Loop-Tk: Makefile 
devel/p5-String-Scanf: Makefile 
devel/p5-Term-ReadLine-Perl: Makefile 
devel/p5-Term-ReadLine-TTYtter: Makefile 
devel/p5-Test-Class: Makefile 
devel/p5-Test-Deep-Type: Makefile 
devel/p5-Test-Pod: Makefile 
devel/p5-Test-Regexp: Makefile 
devel/p5-Test-TempDir: Makefile 
devel/p5-Test-XML: Makefile 
devel/p5-Tie-Simple: Makefile 
devel/p5-Time-Clock: Makefile 
devel/p5-namespace-autoclean: Makefile 
sysutils/gkrellm/plugins/moon: Makefile 
sysutils/openpoppassd: Makefile 
sysutils/p5-UPS-Nut: Makefile 
sysutils/xstatbar: Makefile 
textproc/p5-Number-Format: Makefile 
www/p5-Plack-Test-ExternalServer: Makefile 
x11/p5-Gtk2-ImageView: Makefile 
x11/pwm: Makefile 

Log message:
FIX_EXTRACT_PERMISSIONS

Re: DELETE: www/p5-WWW-YouTube-Download

[Nigel Taylor]

On 12/05/17 12:56, Frederic Cambus wrote:
> On Sun, Dec 03, 2017 at 06:51:56PM +, Mikolaj Kucharski wrote:
> 
>>> So I've looked into updating it, but I don't really see a point. Current
>>> version on CPAN doesn't support encrypted signature videos. I don't use
>>> it any more. Anyone has objections to remove it?
>>>
>>> If decision will be to remove it, please review carefully as I'm not
>>> that familiar with ports removal.
>>>
>>> If you really need perl based youtube downloader, I guess you can try:
>>>
>>> https://www.jwz.org/hacks/youtubedown
>>>
>>> otherwise, there are better alternatives.
>>>
>>
>> Ping. Diff at:
>>  https://marc.info/?l=openbsd-ports=151200587924618=2
> 
> Please wait at least one week before pinging, that's the usual delay.
> 
> Nonetheless, I think removing it makes sense and it seems there was no
> objections so far.
> 
> Anyone willing to OK this removal?
> 
> 

it's already been removed

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2017/12/04 06:09:07

Modified files:
www: Makefile
Removed files:
www/p5-WWW-YouTube-Download: Makefile distinfo
www/p5-WWW-YouTube-Download/pkg: DESCR PLIST

Log message:
remove www/p5-WWW-YouTube-Download, req'd by maintainer Mikolaj Kucharski

Re: DELETE: www/p5-WWW-YouTube-Download

[Frederic Cambus]

On Sun, Dec 03, 2017 at 06:51:56PM +, Mikolaj Kucharski wrote:

> > So I've looked into updating it, but I don't really see a point. Current
> > version on CPAN doesn't support encrypted signature videos. I don't use
> > it any more. Anyone has objections to remove it?
> > 
> > If decision will be to remove it, please review carefully as I'm not
> > that familiar with ports removal.
> > 
> > If you really need perl based youtube downloader, I guess you can try:
> > 
> > https://www.jwz.org/hacks/youtubedown
> > 
> > otherwise, there are better alternatives.
> > 
> 
> Ping. Diff at:
>   https://marc.info/?l=openbsd-ports=151200587924618=2

Please wait at least one week before pinging, that's the usual delay.

Nonetheless, I think removing it makes sense and it seems there was no
objections so far.

Anyone willing to OK this removal?

Re: NEW: textproc/pplatex

[Paul Irofti]

> should the LIB_DEPENDS be turned into a BULID_DEPENDS, because portcheck
> complains that pcre is not a dependency.

Fixed by adding the libraries in WANTLIB, thanks to jca@!


pplatex.tgz
Description: application/tar-gz

Re: WANTLIB is unmaintainable (was: Re: update: shells/zsh 5.4.2)

[Marc Espie]

Apart from the fact that automatic generation won't work and break package
updates completely, what do you suggest ?...

Seriously. This is not a simple problem

Re: net/rrdtool: fix for #794 - "rrdtool creates folders/files with arbitrary permissions"

[Sebastien Marie]

On Tue, Dec 05, 2017 at 10:54:05AM +, Stuart Henderson wrote:
> On 2017/12/04 17:36, Sebastien Marie wrote:
> > On Mon, Dec 04, 2017 at 11:41:10AM +0100, Sebastien Marie wrote:
> > > Hi,
> > > 
> > > ISSUE: "Regression: rrdtool creates folders/files with arbitrary 
> > > permissions"
> > >   https://github.com/oetiker/rrdtool-1.x/issues/794
> > > 
> > > FIX: "Remove all occurances of umask ... this is NOT thread safe! Fix for 
> > > #794"
> > >   
> > > https://github.com/oetiker/rrdtool-1.x/commit/f1edd121add94fe69ac22d991748d289b5eb76ae
> > > 
> > > The following diff is the fix applied on 1.7.0.
> > > 
> > 
> > updated diff. It looks like my local repository wasn't up-to-date.
> > 
> > Sorry about that.
> 
> Thanks - there are some slight problems with the upstream commit,

I copied the diff verbatim, but I agree with the problems :)

> I propose just doing this for now. What do you think?

it is good for me. thanks !

> Index: Makefile
> ===
> RCS file: /cvs/ports/net/rrdtool/Makefile,v
> retrieving revision 1.107
> diff -u -p -r1.107 Makefile
> --- Makefile  1 Dec 2017 10:36:51 -   1.107
> +++ Makefile  5 Dec 2017 10:50:58 -
> @@ -12,8 +12,7 @@ PKGNAME-main=   ${DISTNAME}
>  PKGNAME-update=  rrdupdate-${VERSION}
>  PKGNAME-python= py-rrd-${VERSION}
>  PKGNAME-ruby=ruby${MODRUBY_BINREV}-rrd-${VERSION}
> -REVISION-main=   2
> -REVISION-update= 0
> +REVISION=4
>  
>  SHARED_LIBS +=   rrd  5.2  # 9.0
>  
> Index: patches/patch-src_rrd_create_c
> ===
> RCS file: patches/patch-src_rrd_create_c
> diff -N patches/patch-src_rrd_create_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_rrd_create_c5 Dec 2017 10:50:58 -
> @@ -0,0 +1,50 @@
> +$OpenBSD$
> +
> +Based on:
> +
> +From f1edd121add94fe69ac22d991748d289b5eb76ae Mon Sep 17 00:00:00 2001
> +From: Tobias Oetiker 
> +Date: Sun, 11 Jun 2017 17:19:05 +0200
> +Subject: [PATCH] Remove all occurances of umask ... this is NOT thread safe!
> + Fix for #794.
> +
> +Index: src/rrd_create.c
> +--- src/rrd_create.c.orig
>  src/rrd_create.c
> +@@ -1316,7 +1316,6 @@ done:
> + int write_rrd(const char *outfilename, rrd_t *out) {
> + int rc = -1;
> + char *tmpfilename = NULL;
> +-mode_t saved_umask;
> + 
> + /* write out the new file */
> + #ifdef HAVE_LIBRADOS
> +@@ -1341,10 +1340,9 @@ int write_rrd(const char *outfilename, rrd_t *out) {
> + strcpy(tmpfilename, outfilename);
> + strcat(tmpfilename, "XX");
> + 
> +-/* fix CWE-377 */
> +-saved_umask = umask(S_IRUSR|S_IWUSR);
> ++/* this is 0600 according to the manual page */
> + int tmpfd = mkstemp(tmpfilename);
> +-umask(saved_umask);
> ++
> + if (tmpfd < 0) {
> + rrd_set_error("Cannot create temporary file");
> + goto done;
> +@@ -1377,13 +1375,8 @@ int write_rrd(const char *outfilename, rrd_t *out) {
> + stat_buf.st_mode = _S_IREAD | _S_IWRITE;  // have to test 
> it is 
> + #else
> + /* an error occurred (file not found, maybe?). Anyway:
> +-   set the mode to 0666 using current umask */
> +-stat_buf.st_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | 
> S_IROTH | S_IWOTH;
> +-
> +-mode_t mask = umask(0);
> +-umask(mask);
> +-
> +-stat_buf.st_mode &= ~mask;
> ++   set the mode to 0644 */
> ++stat_buf.st_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
> + #endif
> + }
> + if (chmod(tmpfilename, stat_buf.st_mode) != 0) {
> 

-- 
Sebastien Marie

Re: net/rrdtool: fix for #794 - "rrdtool creates folders/files with arbitrary permissions"

[Stuart Henderson]

On 2017/12/04 17:36, Sebastien Marie wrote:
> On Mon, Dec 04, 2017 at 11:41:10AM +0100, Sebastien Marie wrote:
> > Hi,
> > 
> > ISSUE: "Regression: rrdtool creates folders/files with arbitrary 
> > permissions"
> > https://github.com/oetiker/rrdtool-1.x/issues/794
> > 
> > FIX: "Remove all occurances of umask ... this is NOT thread safe! Fix for 
> > #794"
> > 
> > https://github.com/oetiker/rrdtool-1.x/commit/f1edd121add94fe69ac22d991748d289b5eb76ae
> > 
> > The following diff is the fix applied on 1.7.0.
> > 
> 
> updated diff. It looks like my local repository wasn't up-to-date.
> 
> Sorry about that.

Thanks - there are some slight problems with the upstream commit,

> -- 
> Sebastien Marie
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/rrdtool/Makefile,v
> retrieving revision 1.107
> diff -u -p -r1.107 Makefile
> --- Makefile  1 Dec 2017 10:36:51 -   1.107
> +++ Makefile  4 Dec 2017 16:34:45 -
> @@ -12,7 +12,7 @@ PKGNAME-main=   ${DISTNAME}
>  PKGNAME-update=  rrdupdate-${VERSION}
>  PKGNAME-python= py-rrd-${VERSION}
>  PKGNAME-ruby=ruby${MODRUBY_BINREV}-rrd-${VERSION}
> -REVISION-main=   2
> +REVISION-main=   3
>  REVISION-update= 0

-update uses this code too. Not sure if it's built directly into the bindings
as well but I would just bump everything, it's cheap.

>  
>  SHARED_LIBS +=   rrd  5.2  # 9.0
> Index: patches/patch-doc_rrdcreate_pod
> ===
> RCS file: patches/patch-doc_rrdcreate_pod
> diff -N patches/patch-doc_rrdcreate_pod
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-doc_rrdcreate_pod   4 Dec 2017 16:34:45 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +Fix for https://github.com/oetiker/rrdtool-1.x/issues/794
> +https://github.com/oetiker/rrdtool-1.x/commit/f1edd121add94fe69ac22d991748d289b5eb76ae
> +Index: doc/rrdcreate.pod
> +--- doc/rrdcreate.pod.orig
>  doc/rrdcreate.pod
> +@@ -743,6 +743,12 @@ divides each PDP of the AccumDuration by the correspon
> + TotalRequests and stores the average request duration. The remainder of the
> + RPN expression handles the divide by zero case.
> + 
> ++=head1 SECURITY
> ++
> ++Note that new rrd files will have the permission 0622 regarless of your
> ++umask setting. If a file with the same name previously exists, its
> ++permission settings will be copied to the new file.

644 not 622. And if they're touching that, they can fix spelling of
"regardless" as well :)

> ++
> + =head1 AUTHORS
> + 
> + Tobias Oetiker Et...@oetiker.che, Peter Stamfest 
> Epe...@stamfest.ate
> Index: patches/patch-src_rrd_create_c
> ===
> RCS file: patches/patch-src_rrd_create_c
> diff -N patches/patch-src_rrd_create_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_rrd_create_c4 Dec 2017 16:34:45 -
> @@ -0,0 +1,56 @@
> +$OpenBSD$
> +Fix for https://github.com/oetiker/rrdtool-1.x/issues/794
> +https://github.com/oetiker/rrdtool-1.x/commit/f1edd121add94fe69ac22d991748d289b5eb76ae
> +Index: src/rrd_create.c
> +--- src/rrd_create.c.orig
>  src/rrd_create.c
> +@@ -4,6 +4,7 @@
> +  * rrd_create.c  creates new rrds
> +  
> */
> + 
> ++#include "mutex.h"

Remnant of an earlier attempt at fixing?

> + #include 
> + #include 
> + #include 
> +@@ -1313,10 +1314,10 @@ done:
> + return rc;
> + }
> + 
> ++
> + int write_rrd(const char *outfilename, rrd_t *out) {
> + int rc = -1;
> + char *tmpfilename = NULL;
> +-mode_t saved_umask;
> + 
> + /* write out the new file */
> + #ifdef HAVE_LIBRADOS
> +@@ -1341,10 +1342,10 @@ int write_rrd(const char *outfilename, rrd_t *out) {
> + strcpy(tmpfilename, outfilename);
> + strcat(tmpfilename, "XX");
> + 
> +-/* fix CWE-377 */
> +-saved_umask = umask(S_IRUSR|S_IWUSR);
> ++/* this is 0600 according to the manual page */
> + int tmpfd = mkstemp(tmpfilename);
> +-umask(saved_umask);
> ++
> ++
> + if (tmpfd < 0) {
> + rrd_set_error("Cannot create temporary file");
> + goto done;
> +@@ -1377,13 +1378,8 @@ int write_rrd(const char *outfilename, rrd_t *out) {
> + stat_buf.st_mode = _S_IREAD | _S_IWRITE;  // have to test 
> it is 
> + #else
> + /* an error occurred (file not found, maybe?). Anyway:
> +-   set the mode to 0666 using current umask */
> +-stat_buf.st_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | 
> S_IROTH | S_IWOTH;
> +-
> +-mode_t mask = umask(0);
> +-umask(mask);
> +-
> +-stat_buf.st_mode &= ~mask;
> ++   set the mode to 0644 using current umask */
> ++stat_buf.st_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;

The "using current umask" comment here is wrong.

> 

CVS: cvs.openbsd.org: ports

[Pierre-Emmanuel Andre]

CVSROOT:/cvs
Module name:ports
Changes by: p...@cvs.openbsd.org2017/12/05 03:54:15

Modified files:
www/dokuwiki   : Makefile distinfo 

Log message:
Security update to 2017-02-19e (3 cve)

ok rsadowski@

Re: OpenBSD 6.2/Qt 5/GC: crash: W^X violation despite wxallowed

[Claus Assmann]

[wxallowed as mount option solved W^X violation abort in 6.0i,
but not 6.2]

On Mon, Dec 04, 2017, Rafael Sadowski wrote:

> Looks like you built GoldenCheetah from scratch outside the ports env.

Yes; I build SW "just out of the box" (because I build the same
SW on various OSs -- and a port of GoldenCheetah was submitted
by someone but did not get accepted).

> If yes, you have to extend ld(1)'s parameters with `-z wxneeded`.

Thanks.

> Please search for COMPILER_LINKS and USE_WXNEEDED in bsd.port.mk(5).

That doesn't really say what to do when building things
"outside the ports env".

On Mon, Dec 04, 2017, Juan Francisco Cantero Hurtado wrote:

> If that program is outside of the ports tree, add "-Wl,-z,wxneeded" to
> the CFLAGS/CXXFLAGS.

Thanks, but that causes:
warning: -Wl,-z,wxneeded: 'linker' input unused [-Wunused-command-line-argument]

during compilation, so adding it only to the linker
seems to be better.

CVS: cvs.openbsd.org: ports

[Job Snijders]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/12/05 03:42:45

Modified files:
net/aggregate6 : Makefile distinfo 

Log message:
Update to aggregate6 1.0.12

This version brings 'truncate' and 'verbose' mode.

OK sthen@

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/05 03:38:43

Modified files:
devel/harfbuzz : Makefile distinfo 
devel/harfbuzz/pkg: PLIST-main 

Log message:
Update to harfbuzz-1.7.2.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/05 03:32:18

Modified files:
sysutils/awscli: Makefile distinfo 

Log message:
Update to awscli-1.14.3.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2017/12/05 03:32:02

Modified files:
net/py-botocore: Makefile distinfo 

Log message:
Update to py-botocore-1.8.7.

NEW: textproc/pplatex

[Paul Irofti]

Hi,

Here is a new port that makes LaTeX warnings (and errors) more humane.
Works very nice with vimtex, especially for multi-file projects!

%---
LaTeX is able to produce really nice document layouts. But it is also
able to produce a lot of noise on the command line. pplatex is a
command-line tool that parses the logs of latex and pdflatex and prints
warnings and errors in an human readable format.
%---

The binary statically links with the pcre library

%---
$ ldd `which pplatex`
/usr/local/bin/pplatex:
StartEnd  Type Open Ref GrpRef Name
0c2964e0 0c2965012000 exe  20   0  
/usr/local/bin/pplatex
0c2ba39da000 0c2ba3bdd000 rlib 01   0  
/usr/local/lib/libpcreposix.so.1.5
0c2b9f679000 0c2b9f8be000 rlib 02   0  
/usr/local/lib/libpcre.so.3.0
0c2c4f098000 0c2c4f358000 rlib 01   0  
/usr/lib/libc++.so.1.0
0c2c17155000 0c2c173b5000 rlib 01   0  
/usr/lib/libc++abi.so.0.0
0c2bfeef5000 0c2bff0fe000 rlib 01   0  
/usr/lib/libpthread.so.25.1
0c2c5c807000 0c2c5ca2d000 rlib 01   0  
/usr/lib/libm.so.10.0
0c2c16e75000 0c2c17155000 rlib 01   0  
/usr/lib/libc.so.92.0
0c2bd3b0 0c2bd3b0 rtld 01   0  
/usr/libexec/ld.so
%---

should the LIB_DEPENDS be turned into a BULID_DEPENDS, because portcheck
complains that pcre is not a dependency.

As usual, the port can also be found on github.

https://github.com/jasperla/openbsd-wip/tree/master/textproc/pplatex

OK?


pplatex.tgz
Description: application/tar-gz

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2017/12/05 01:33:44

Modified files:
geo/qgis   : Makefile 

Log message:
Ensure qgis depends on the default/non-qt5 flavor of x11/qwt.

Re: PHP rename fastcgi to cgi

[Martijn van Duren]

ping

On 11/24/17 13:13, Martijn van Duren wrote:
> On 11/24/17 12:07, Stuart Henderson wrote:
>> On 2017/11/24 09:27, Martijn van Duren wrote:
 @conflict php-fastcgi->=5.6,<5.7
>>>
>>> Left out, since there's no overlapping names between the two packages,
>>> which is what pkg_create(1) specifies should be the reason of usage.
>>> Of course it's easy enough to add if you think it's still needed.
>>
>> Good point. As long as the upgrade test works that's alright.
>>
> +--- sapi/cgi/php-cgi.1.in.orig
>  sapi/cgi/php-cgi.1.in
> +@@ -1 +1 @@
> +-.so man1/php.1
> ++.so man1/php-5.6.1

 Wrong version.
>>> Autch
>>> It was meant to read .so man1/php-${PV}.1. Probably got overwritten and
>>> overlooked during a final update-patches.

 Did you figure out why it was copied rather than using .so
 before? There might be a reason for that.
>>>
>>> It wasn't installed at all before, so this is the first time php-cgi(1)
>>> is added. If it was copied I would've left it as is.
>>>
>>> On second thought I do now reckon it's better to just copy the original
>>> php.1. If -cli is going to be split of the .so file might not be there
>>> and the content of the file hasn't been changed since it's creation 5
>>> years ago so it's unlikely to get its own manpage any time soon.
>>
>> +1
>>
>>> ${INSTALL_PROGRAM} ${WRKBUILD}/sapi/cli/php ${PREFIX}/bin/php-${PV}
>>> -   ${INSTALL_PROGRAM} ${WRKBUILD}/sapi/cgi/php-cgi 
>>> ${PREFIX}/bin/php-fastcgi-${PV}
>>> +   ${INSTALL_PROGRAM} ${WRKBUILD}/sapi/cgi/php-cgi 
>>> ${PREFIX}/bin/php-cgi-${PV}
>>> +# Make sure that php-cgi.1 still just sources php.1 when importing a new 
>>> major version.
>>> +   ${INSTALL_MAN} ${WRKSRC}/sapi/cli/php.1 
>>> ${PREFIX}/man/man1/php-cgi-${PV}.1
>>
>> It's not /all/ that likely that this comment will be noticed that far
>> down in Makefile.inc when someone adds a new branch. What I sometimes
>> do in cases where I'm worried upstream might change something that
>> might not be noticed and needs further attention is make an explicit
>> check that kills the build (e.g. see the pjproject check in Asterisk's
>> post-extract), might be worth considering. Then again it doesn't seem
>> all that important anyway..
>>
> I tend to sway to the latter. It's not really that important. I added this as
> a general reminder for future maintainers to check it occasionally and as a
> motivation why php.1 is installed instead of php-cgi.1.
> 
> So OK for the current version of the patch?
> 
> Also, any strong opinions about moving out -cli, -fpm, -apxs2 of -main and
> enabling -phpdbg in its own subpackage? I'll probably want to pick that up
> next.
> 

CVS: cvs.openbsd.org: ports

[Kirill Bychkov]

CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2017/12/05 01:19:35

Modified files:
sysutils/ansible: Makefile 

Log message:
switch HOMEPAGE and MASTER_SITES to https
"sure thing!" jasper@ (MAINTAINER)