[UPDATE] textproc/mdp

[Remi Pointel]

ping


 Forwarded Message 
Subject: [UPDATE] textproc/mdp
Date: Mon, 05 Mar 2018 13:27:26 +0100
From: Remi Pointel 
To: ports@openbsd.org

Hi,

this is the diff to update ldp to latest release.

Ok?

Cheers,

Remi.

Index: Makefile
===
RCS file: /cvs/ports/textproc/mdp/Makefile,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 Makefile
--- Makefile	12 Nov 2017 16:17:16 -	1.2
+++ Makefile	5 Mar 2018 12:26:03 -
@@ -4,14 +4,14 @@ COMMENT =	command-line based markdown pr
 
 GH_ACCOUNT =	visit1985
 GH_PROJECT =	mdp
-GH_TAGNAME =	1.0.10
+GH_TAGNAME =	1.0.12
 
 CATEGORIES =	textproc
 
 # GPLv3+
 PERMIT_PACKAGE_CDROM =	Yes
 
-WANTLIB += c ncursesw
+WANTLIB += c curses
 
 MAKE_FLAGS =		PREFIX=${PREFIX}
 
Index: distinfo
===
RCS file: /cvs/ports/textproc/mdp/distinfo,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 distinfo
--- distinfo	12 Nov 2017 16:17:16 -	1.2
+++ distinfo	5 Mar 2018 12:26:03 -
@@ -1,2 +1,2 @@
-SHA256 (mdp-1.0.10.tar.gz) = c4TBujK9jksRNCVw0hRBZaYGgkmbTLVOUMjrMWTPq8U=
-SIZE (mdp-1.0.10.tar.gz) = 37502
+SHA256 (mdp-1.0.12.tar.gz) = n6ygJFur1UqkfLu3LBQkTKmpqE9jAhpnkHgEHaT26Ys=
+SIZE (mdp-1.0.12.tar.gz) = 37513

[NEW] security/py-ropper

[Remi Pointel]

ping


 Forwarded Message 
Subject: [NEW] security/py-ropper
Date: Mon, 9 Apr 2018 21:12:06 +0200
From: Remi Pointel 
To: The OpenBSD ports mailing-list 

Hi,

attached is ropper, a rop gadget finder and binary information tool.

-
$ pkg_info py-ropper
Information for inst:py-ropper-1.11.6

Comment:
rop gadget finder and binary information tool

Description:
Ropper can be used to look at information about files in different file 
formats
and can find ROP and JOP gadgets to build chains for different 
architectures.
Ropper supports ELF, MachO and the PE file format. Other files can be 
opened in

RAW format.

Maintainer: Remi Pointel 

WWW: https://scoding.de/ropper/
-

Ok?

Cheers,

Remi.



py-ropper-1.11.6.tar.gz
Description: application/gzip

Re: NEW: x11/kde-applications/libkdcraw

[Landry Breuil]

On Sun, Apr 29, 2018 at 10:20:42PM +0200, Rafael Sadowski wrote:
> On Sun Apr 29, 2018 at 12:01:21PM +0200, Landry Breuil wrote:
> > On Sun, Apr 29, 2018 at 11:58:02AM +0200, Rafael Sadowski wrote:
> > > On Sun Apr 29, 2018 at 11:01:11AM +0200, Landry Breuil wrote:
> > > > On Sun, Apr 29, 2018 at 10:04:25AM +0200, Rafael Sadowski wrote:
> > > > > $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> > > > > Libkdcraw is a C++ interface around LibRaw library used to decode RAW 
> > > > > picture
> > > > > files.
> > > > > 
> > > > > Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> > > > > conflicts with libkdcraw from KDE4 but we can't just commit because 
> > > > > all
> > > > > KDE4 applications will grep/find libkdcraw-17.12.3 instead
> > > > > libkdcraw-4.*, which is wrong.
> > > > 
> > > > Do you mean at install time ?  just because the pkgname is the same ?
> > > > use @option is-branch maybe ?
> > > > 
> > > 
> > > Exactly, pkgname is the same but somehow everything looks okay:
> > > 
> > > $ TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all pkg_add gwenview
> > > gwenview-4.14.3p3:libkdcraw-4.14.3p2: ok
> > > gwenview-4.14.3p3:libkipi-4.14.3p2: ok
> > > gwenview-4.14.3p3: ok
> > > 
> > > The 17.12.3 packages will not fetch. kde4 is smart enough, anyway ok?
> > 
> > I'm not 100% sure but i think you *have* to at least set @option
> > no-default-config (maybe is-branch?), otherwise the packages will
> > conflict by default since they have the same name, even if they don't
> > have actual files conflicting.
> > 
> 
> Yes, both options make sense to me. Btw I didn't know them, so far:
> 
> @option is-branch
> @option no-default-conflict
> 
> Ok (I think a second updated tarball is nor necessary, isn't)?

I think testing that it does what it's supposed to do with various
combinations of the options is necessary :)

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2018/04/29 23:06:09

Added files:
games/mars/patches: patch-include_Specials_NoSpecial_hpp 

Log message:
Fix runtime crash

Re: NEW: Spyder + UPDATE: py-rope

[Elias M. Mariani]

Hi, it's me again.
Still looking for someone to review/approve/commit the spyder port
available on openbsd-wip.
Thanks.
Elias.

2018-04-28 13:05 GMT-03:00 Elias M. Mariani :
> NEW devel/spyder added on openbsd-wip on github.
> https://github.com/jasperla/openbsd-wip
> Looking for OKs and someone to do the commit.
> Thanks to Daniel Jakots for commiting the py-rope update.
> Elias,
>
> 2018-04-26 21:29 GMT-03:00 Elias M. Mariani :
>> Great!
>> About NEW: devel/spyder could you assist me ? Or should I send the
>> port to openbsd-wip on github to see if someone else can give the OK
>> and send it to de CVS?
>> Best Regards.
>>
>> 2018-04-26 17:34 GMT-03:00 Daniel Jakots :
>>> On Thu, 26 Apr 2018 19:09:39 +, "Elias M. Mariani"
>>>  wrote:
>>>
 Sure, no problem, thanks to you for the help!
>>>
>>> Thanks! I committed a tweak version of your py-rope diff and added the
>>> missing bits for the ports infrastructure. The overall quality of your
>>> diff was pretty good ;)
>>>
>>> Cheers,
>>> Daniel

patch which upgrades tcltls to 1.7.16

[currellberry]

The current version of tcltls in ports is 1.6 which only supports up to TLS 
1.0.  Supposedly TLS 1.0 is not considered that secure anymore.  TCLTLS 
development has since moved to core.tcl.tk and tcltls 1.7.16 adds support up to 
TLS 1.2 .  Some files have been moved around moved around/renamed upstream so 
this patch is a little more than just a version bump.

Last time I submitted a patch I made some errors, so please let me know if 
there are things I need to change.

-- Currell

Index: Makefile
===
RCS file: /cvs/ports/security/tcltls/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile12 May 2017 21:41:46 -  1.15
+++ Makefile29 Apr 2018 22:38:35 -
@@ -2,15 +2,14 @@
 
 COMMENT=   OpenSSL Tcl extension
 
-VERSION=   1.6
+VERSION=   1.7.16
 
-DISTNAME=  tls${VERSION}-src
+DISTNAME=  tcltls-${VERSION}
 PKGNAME=   tcltls-${VERSION}
-REVISION=  3
 
 CATEGORIES=security
 
-HOMEPAGE=  http://tls.sourceforge.net/
+HOMEPAGE=  http://core.tcl.tk/tcltls
 
 MAINTAINER=Sebastian Reitenbach 
 
@@ -19,29 +18,29 @@ PERMIT_PACKAGE_CDROM=   Yes
 
 WANTLIB=   ssl crypto
 
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=tls/}
+MASTER_SITES=  https://core.tcl.tk/tcltls/uv/ \
+   https://tcltls.rkeene.org/uv/
 
 MODULES=   lang/tcl
 
 RUN_DEPENDS=   ${MODTCL_RUN_DEPENDS}
 BUILD_DEPENDS= ${RUN_DEPENDS}
 
-WRKDIST=   ${WRKDIR}/tls${VERSION}
+WRKDIST=   ${WRKDIR}/tcltls-${VERSION}
 SEPARATE_BUILD =Yes
 CONFIGURE_STYLE=gnu
 CONFIGURE_ARGS=--libdir=${MODTCL_TCLDIR} \
--with-tcl=${MODTCL_LIBDIR} \
--with-tclinclude=${MODTCL_INCDIR} \
--with-ssl-dir=/usr \
-   --includedir=${PREFIX}/include/tcltls
+   --includedir=${PREFIX}/include/tcltls \
+   --disable-sslv2 \
+   --disable-sslv3 
 
 FAKE_FLAGS =   PKG_DIR='$$(PACKAGE_NAME)' INSTALL_PROGRAM='$$(INSTALL_DATA)'
-INSTALL_TARGET=install-binaries
+INSTALL_TARGET=install
 TEST_TARGET=   test
-CFLAGS +=  -DNO_SSL2 -DNO_SSL3
-SUBST_VARS=VER
-
-VER=   ${VERSION:S/.//g}
+SUBST_VARS=VERSION
 
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/tcltls/
Index: distinfo
===
RCS file: /cvs/ports/security/tcltls/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo18 Jan 2015 03:15:08 -  1.4
+++ distinfo29 Apr 2018 22:38:35 -
@@ -1,2 +1,2 @@
-SHA256 (tls1.6-src.tar.gz) = rexQFDqa1jSmcdJPfHu/JFVIfrXxLSkPQXl8MqmLk/M=
-SIZE (tls1.6-src.tar.gz) = 168043
+SHA256 (tcltls-1.7.16.tar.gz) = aEUABzK+33ZOeMI0zuZG+Vu2jfNOWQw5Q0q47db1ua8=
+SIZE (tcltls-1.7.16.tar.gz) = 166439
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 12 May 2017 21:41:47 -  1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-configure,v 1.2 2017/05/12 21:41:47 stu Exp $
-Index: configure
 configure.orig
-+++ configure
-@@ -8155,7 +8155,7 @@ echo "${ECHO_T}$tcl_cv_ld_elf" >&6
-   DL_LIBS=""
-   CC_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
-   LD_SEARCH_FLAGS=${CC_SEARCH_FLAGS}
--  SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}.so.1.0'
-+  SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}.so'
-   echo "$as_me:$LINENO: checking for ELF" >&5
- echo $ECHO_N "checking for ELF... $ECHO_C" >&6
- if test "${tcl_cv_ld_elf+set}" = set; then
Index: patches/patch-tests_ciphers_test
===
RCS file: /cvs/ports/security/tcltls/patches/patch-tests_ciphers_test,v
retrieving revision 1.2
diff -u -p -r1.2 patch-tests_ciphers_test
--- patches/patch-tests_ciphers_test5 Jan 2011 18:04:58 -   1.2
+++ patches/patch-tests_ciphers_test29 Apr 2018 22:38:35 -
@@ -1,41 +1,33 @@
-$OpenBSD: patch-tests_ciphers_test,v 1.2 2011/01/05 18:04:58 sebastia Exp $
+$OpenBSD$
 
-Those tests will fail.
-
 tests/ciphers.test.origFri Jun 22 23:03:34 2007
-+++ tests/ciphers.test Sun Dec  5 12:57:05 2010
-@@ -105,22 +105,22 @@ test ciphers-1.2 {Tls::ciphers for tls1} {rsabsafe} {
- listcompare $::EXPECTEDCIPHERS(rsabsafe) [tls::ciphers tls1]
- } {}
+Index: tests/ciphers.test
+--- tests/ciphers.test.orig
 tests/ciphers.test
+@@ -122,17 +122,17 @@ proc listcompare {wants haves} {
+ }
+ }
  
--test ciphers-1.3 {Tls::ciphers for ssl3} {openssl} {
--# This will fail if you compiled against RSA bsafe or with a
--# different set of defines than the default.
+-test ciphers-1.1 {Tls::ciphers for ssl3} {rsabsafe} {
+-# This will fail if you compiled against OpenSSL.
 -# Change the constraint setting above.
--

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 16:24:56

Modified files:
textproc/zathura/core: Makefile 

Log message:
missing BDEP on sphinx

Re: update lang/sbcl

[Josh Elsasser]

On Sun, Apr 29, 2018 at 09:47:09AM +0200, Solene Rapenne wrote:
> 
> Josh Elsasser writes:
> 
> > On Fri, Apr 27, 2018 at 08:56:04PM -0700, Josh Elsasser wrote:
> >> Patching the i386 and ppc *-arch.c files isn't necessary. However i386
> >> didn't build for me (in a VM). I think we need to do this in
> >> patches/patch-src_runtime_bsd-os_c:
> 
> Christian Weisgerber reported me that sbcl build was failing on i386
> with 1.4.6, build log attached to the mail. Maybe sbcl is allocating too
> much memory, I don't know... I don't have an i386 system at the moment
> to debug this. Otherwise, next week I will be able to try sbcl on
> powerpc arch as I am using it daily.
> 

The failure I was seeing is now fixed upstream, I'm not sure if
naddy's has the same cause. I'm running a build in a loop under a VM
to try and reproduce it.

NEW: net/frrouting

[Aaron A. Glenn]

Hello,

Long time listener; first time caller.

Attached is a port of FreeRangeRouting, with a snmp flavor. I have
confirmed it builds, and the resulting package installs, successfully on
6.3-RELEASE/amd64. Despite my best efforts, and endless questions to
phessler@, there is substantial chance I overlooked something.

Please let me know what, if so.

Best,
Aaron A. Glenn


net_frrouting-4.0.tgz
Description: application/gtar-compressed

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 16:05:53

Removed files:
productivity/vym/patches: patch-exports_cpp 

Log message:
remove unneeded patch

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 14:38:44

Modified files:
infrastructure/bin: update-plist 

Log message:
also annotate fragments so that they don't wander from plist to plist in
complex situations

Re: NEW: x11/kde-applications/libkdcraw

[Rafael Sadowski]

On Sun Apr 29, 2018 at 12:01:21PM +0200, Landry Breuil wrote:
> On Sun, Apr 29, 2018 at 11:58:02AM +0200, Rafael Sadowski wrote:
> > On Sun Apr 29, 2018 at 11:01:11AM +0200, Landry Breuil wrote:
> > > On Sun, Apr 29, 2018 at 10:04:25AM +0200, Rafael Sadowski wrote:
> > > > $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> > > > Libkdcraw is a C++ interface around LibRaw library used to decode RAW 
> > > > picture
> > > > files.
> > > > 
> > > > Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> > > > conflicts with libkdcraw from KDE4 but we can't just commit because all
> > > > KDE4 applications will grep/find libkdcraw-17.12.3 instead
> > > > libkdcraw-4.*, which is wrong.
> > > 
> > > Do you mean at install time ?  just because the pkgname is the same ?
> > > use @option is-branch maybe ?
> > > 
> > 
> > Exactly, pkgname is the same but somehow everything looks okay:
> > 
> > $ TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all pkg_add gwenview
> > gwenview-4.14.3p3:libkdcraw-4.14.3p2: ok
> > gwenview-4.14.3p3:libkipi-4.14.3p2: ok
> > gwenview-4.14.3p3: ok
> > 
> > The 17.12.3 packages will not fetch. kde4 is smart enough, anyway ok?
> 
> I'm not 100% sure but i think you *have* to at least set @option
> no-default-config (maybe is-branch?), otherwise the packages will
> conflict by default since they have the same name, even if they don't
> have actual files conflicting.
> 

Yes, both options make sense to me. Btw I didn't know them, so far:

@option is-branch
@option no-default-conflict

Ok (I think a second updated tarball is nor necessary, isn't)?

Re: [New] [WIP] Toxcore, Toxic and uTox

[Landry Breuil]

On Sun, Apr 29, 2018 at 12:57:29PM +0100, Stuart Henderson wrote:
> On 2018/04/29 12:43, Landry Breuil wrote:
> > The rationale is to not explicitely adding libtool from ports (the gnu
> > one) unless its really needed, ie delete ports libtool, figure out if
> > the port is fine with the base libtool, and then set USE_LIBTOOL=yes
> > which will set LIBTOOL in the env during build. If you set it to 'gnu'
> > it will also add devel/libtool to the build depends.
> 
> I know Landry already knows, but getting it into the thread:

Well i tend to forget the gory details so that's a nice reminder; thanks :)

> libtool's m4 files are often needed for autoconf/automake regeneration,
> in that case (where gnu libtool itself isn't needed) then devel/libtool
> must be listed as a BUILD_DEPENDS.
> 
> USE_LIBTOOL=gnu should not be used unless base libtool doesn't work
> with the port (and in that case it should come with agood explanation).
> 

 USE_LIBTOOL
 Defaults to ‘Yes’.  Set to ‘gnu’ if the base libtool(1) is
 insufficient and GNU libtool is required.  Set to ‘No’ to disable
 the use of libtool(1) entirely; this should not be set under
 normal circumstances.  Adds dependencies if necessary, and passes
 LIBTOOL environment variable to scripts invocations.

Could be improved to mention the only reason to manually add libtool to
BDEP ?

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 13:26:33

Modified files:
infrastructure/bin: update-plist 

Log message:
missing space

CVS: cvs.openbsd.org: ports

[Anthony J . Bentley]

CVSROOT:/cvs
Module name:ports
Changes by: bent...@cvs.openbsd.org 2018/04/29 12:19:33

Modified files:
textproc/html-xml-utils: Makefile distinfo 
Added files:
textproc/html-xml-utils/patches: patch-Makefile_in 
Removed files:
textproc/html-xml-utils/patches: patch-Makefile_am 
 patch-configure_ac 

Log message:
Update to html-xml-utils-7.7.

Latest autoconf patches have now been committed upstream.

Request: lang/julia

[Elias M. Mariani]

Hi,
For people looking for something nice to add to OpenBSD I think that
lang/julia is a good addition.

Julia:
Julia is a high-level, high-performance dynamic programming language
for numerical computing. It provides a sophisticated compiler,
distributed parallel execution, numerical accuracy, and an extensive
mathematical function library. Julia’s Base library, largely written
in Julia itself, also integrates mature, best-of-breed open source C
and Fortran libraries for linear algebra, random number generation,
signal processing, and string processing. In addition, the Julia
developer community is contributing a number of external packages
through Julia’s built-in package manager at a rapid pace.

https://julialang.org/
https://github.com/JuliaLang/julia

Most of the dependencies are already ported to OpenBSD.
It can be built with clang and is already ported in FreeBSD.

This is just a request for a language that I would like to see in
OpenBSD, don't make this a hate-thread...
Elias.

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 07:08:32

Modified files:
infrastructure/bin: update-plist 

Log message:
special rule: for FULLPKGNAME, consider a new substitution on
shared/doc/pkg-readmes/

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 07:03:45

Modified files:
infrastructure/bin: update-plist 

Log message:
strip directories later
so that we don't need to bother if there are NO DIRECTORIES WHATSOEVER
Lots of packages are going to love this :)

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/04/29 07:03:52

Modified files:
devel/p5-File-ChangeNotify: Makefile distinfo 

Log message:
Update to p5-File-ChangeNotify-0.28.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/04/29 07:02:12

Modified files:
print/system-config-printer: Makefile 
print/system-config-printer/pkg: DESCR 

Log message:
Missing BDEP: www/py-requests${MODPY_FLAVOR}, reported by andi at jaak dot de
While here, add a small note aout py3-smbc in DESCR (SMB browser support).

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2018/04/29 06:56:15

Modified files:
www/newsboat   : Makefile 
Added files:
www/newsboat/patches: patch-Makefile 

Log message:
Programs that use curses need to explicitly link with libcurses.
Fixes linking with lld.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/04/29 06:55:26

Modified files:
sysutils/terraform/provider-cloudstack: Makefile distinfo 
sysutils/terraform/provider-triton: Makefile distinfo 

Log message:
Update providers to their latest release.

update misc/most

[Solene Rapenne]

update 5.0.0a => 5.0.0

I removed termcap from WANTLIB because =>
$ make port-lib-depends-check
most-5.0.0(misc/most):
Extra:  termcap.14

MAKE_FLAGS added to set the right directory for the doc, I think it's
better than patching the project Makefile who choosed to use
${PREFIX}/doc in their last version.


Index: Makefile
===
RCS file: /cvs/ports/misc/most/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile25 Apr 2015 21:56:38 -  1.20
+++ Makefile29 Apr 2018 12:52:29 -
@@ -4,8 +4,8 @@ PORTROACH=  limit:.*[^a]$$

 COMMENT=   browse or page through a text file

-DISTNAME=  most-5.0.0a
-REVISION=  0
+DISTNAME=  most-5.0.0
+
 CATEGORIES=misc

 MASTER_SITES=  ftp://space.mit.edu/pub/davis/most/
@@ -15,7 +15,9 @@ LIB_DEPENDS=  devel/libslang
 # GPLv2+
 PERMIT_PACKAGE_CDROM=  Yes

-WANTLIB=   c m slang termcap
+WANTLIB=   c m slang
+
+MAKE_FLAGS=DOC_DIR=${PREFIX}/share/doc/most

 CONFIGURE_STYLE= gnu
 CONFIGURE_ARGS=--with-slang=${LOCALBASE}
Index: distinfo
===
RCS file: /cvs/ports/misc/most/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo18 Jan 2015 03:14:32 -  1.7
+++ distinfo29 Apr 2018 12:52:29 -
@@ -1,2 +1,2 @@
-SHA256 (most-5.0.0a.tar.gz) = F6Flk9oGTd1IT1MVfVS4O82Y6kWrHtNh7qZMT64WOhA=
-SIZE (most-5.0.0a.tar.gz) = 155233
+SHA256 (most-5.0.0.tar.gz) = f40aGLGcbfcvYbsGwzdHfR8TuouU4csfyV5iquWvV1s=
+SIZE (most-5.0.0.tar.gz) = 155177
Index: patches/patch-src_Makefile_in
===
RCS file: patches/patch-src_Makefile_in
diff -N patches/patch-src_Makefile_in
--- patches/patch-src_Makefile_in   13 Oct 2009 21:47:59 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_Makefile_in,v 1.1 2009/10/13 21:47:59 sthen Exp $
 src/Makefile.in.orig   Sat Oct 10 17:56:33 2009
-+++ src/Makefile.inSat Oct 10 17:56:45 2009
-@@ -22,7 +22,7 @@ prefix   = @prefix@
- exec_prefix   = @exec_prefix@
- datarootdir   = @datarootdir@
- BIN_DIR   = $(prefix)/bin
--MAN_DIR   = $(datarootdir)/man
-+MAN_DIR   = $(prefix)/man
- DOC_DIR   = $(datarootdir)/doc/most
- SYS_INITFILE  = @sysconfdir@/most.conf
- MKINSDIR  = ../autoconf/mkinsdir.sh
Index: pkg/PLIST
===
RCS file: /cvs/ports/misc/most/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST   13 Oct 2009 21:47:59 -  1.4
+++ pkg/PLIST   29 Apr 2018 12:52:29 -
@@ -1,4 +1,4 @@
-@comment $OpenBSD: PLIST,v 1.4 2009/10/13 21:47:59 sthen Exp $
+@comment $OpenBSD$
 @bin bin/most
 @man man/man1/most.1
 share/doc/most/

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2018/04/29 06:34:20

Modified files:
mail/mailest   : Makefile 
Added files:
mail/mailest/patches: patch-mailestd_Makefile 

Log message:
Explicitly link with -liconv since the iconv() functions are called
directly from the program.  Fixes linking with lld.  ok yasuoka@

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2018/04/29 06:33:13

ports/mail/mailest/patches

Update of /cvs/ports/mail/mailest/patches
In directory cvs.openbsd.org:/tmp/cvs-serv95381/patches

Log Message:
Directory /cvs/ports/mail/mailest/patches added to the repository

update misc/zzuf

[Solene Rapenne]

bump 0.14 => 0.15

- two patches are removed because merged upstream
- one patch added to remove 

Index: Makefile
===
RCS file: /cvs/ports/misc/zzuf/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile5 Feb 2018 06:30:21 -   1.18
+++ Makefile29 Apr 2018 12:18:16 -
@@ -4,9 +4,9 @@ BROKEN-hppa=__sync_lock_test_and_set_4
 
 COMMENT=   transparent application input fuzzer
 
-VERSION=   0.14
+VERSION=   0.15
 DISTNAME=  zzuf-${VERSION}
-REVISION=  1
+
 CATEGORIES=misc security
 
 MASTER_SITES=  
https://github.com/samhocevar/zzuf/releases/download/v${VERSION}/
Index: distinfo
===
RCS file: /cvs/ports/misc/zzuf/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo19 Nov 2015 00:55:23 -  1.7
+++ distinfo29 Apr 2018 12:18:16 -
@@ -1,2 +1,2 @@
-SHA256 (zzuf-0.14.tar.gz) = KRtB1Trm33XQ0rSg+qMzrfxKArnKhwa+5H73vmV5Zs4=
-SIZE (zzuf-0.14.tar.gz) = 469885
+SHA256 (zzuf-0.15.tar.gz) = o09iRQPgms0mnHDYJqrCo1wD6E3DUYc/FA8LpqeS/9Y=
+SIZE (zzuf-0.15.tar.gz) = 493559
Index: patches/patch-configure
===
RCS file: /cvs/ports/misc/zzuf/patches/patch-configure,v
retrieving revision 1.1
diff -u -p -r1.1 patch-configure
--- patches/patch-configure 14 Mar 2017 02:43:18 -  1.1
+++ patches/patch-configure 29 Apr 2018 12:18:16 -
@@ -1,7 +1,8 @@
 $OpenBSD: patch-configure,v 1.1 2017/03/14 02:43:18 jca Exp $
 configure.orig Tue Mar 14 03:39:28 2017
-+++ configure  Tue Mar 14 03:41:16 2017
-@@ -11915,7 +11915,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$
+Index: configure
+--- configure.orig
 configure
+@@ -12423,7 +12423,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$
  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_try_cflags_ok" >&5
  $as_echo "$ac_cv_try_cflags_ok" >&6; }
  if test x"$ac_cv_try_cflags_ok" = x"yes"; then
Index: patches/patch-src_libzzuf_lib-stream_c
===
RCS file: patches/patch-src_libzzuf_lib-stream_c
diff -N patches/patch-src_libzzuf_lib-stream_c
--- patches/patch-src_libzzuf_lib-stream_c  19 Nov 2015 00:55:23 -  
1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-A simple missing semicolon. Fixed upstream by commit 9eb78c6:
-
-   
https://github.com/samhocevar/zzuf/commit/9eb78c602c1ef292cb5d94e6dad5d3d2c4215786
-
-$OpenBSD: patch-src_libzzuf_lib-stream_c,v 1.1 2015/11/19 00:55:23 mmcc Exp $
 src/libzzuf/lib-stream.c.orig  Tue Nov 17 23:58:02 2015
-+++ src/libzzuf/lib-stream.c   Tue Nov 17 23:58:29 2015
-@@ -1052,7 +1052,7 @@ char *NEW(fgetln)(FILE *stream, size_t *len)
- 
- fuzz->tmp[i] = (char)(unsigned char)chr;
- }
--while (fuzz->tmp[i++] != '\n')
-+while (fuzz->tmp[i++] != '\n');
- 
- *len = i;
- char *ret = fuzz->tmp;
Index: patches/patch-src_zzuf_c
===
RCS file: patches/patch-src_zzuf_c
diff -N patches/patch-src_zzuf_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_zzuf_c29 Apr 2018 12:18:16 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Index: src/zzuf.c
+--- src/zzuf.c.orig
 src/zzuf.c
+@@ -48,7 +48,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #if defined HAVE_SYS_TIME_H
+ #   include 
+ #endif
Index: patches/patch-test_bug-mmap_c
===
RCS file: /cvs/ports/misc/zzuf/patches/patch-test_bug-mmap_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-test_bug-mmap_c
--- patches/patch-test_bug-mmap_c   19 Nov 2015 00:55:23 -  1.1
+++ patches/patch-test_bug-mmap_c   29 Apr 2018 12:18:16 -
@@ -10,12 +10,3 @@ $OpenBSD: patch-test_bug-mmap_c,v 1.1 20
  #if HAVE_SYS_MMAN_H
  #   include 
  #endif
-@@ -32,7 +30,7 @@
- 
- int main(void)
- {
--#if defined _SC_PAGE_SIZE
-+#if defined _SC_PAGE_SIZE && defined MAP_POPULATE
- int fd = open("/etc/hosts", O_RDONLY);
- mmap(0, sysconf(_SC_PAGE_SIZE) * 2, PROT_READ,
-  MAP_PRIVATE | MAP_POPULATE, fd, 0);

Re: [New] [WIP] Toxcore, Toxic and uTox

[Stuart Henderson]

On 2018/04/29 12:43, Landry Breuil wrote:
> The rationale is to not explicitely adding libtool from ports (the gnu
> one) unless its really needed, ie delete ports libtool, figure out if
> the port is fine with the base libtool, and then set USE_LIBTOOL=yes
> which will set LIBTOOL in the env during build. If you set it to 'gnu'
> it will also add devel/libtool to the build depends.

I know Landry already knows, but getting it into the thread:

libtool's m4 files are often needed for autoconf/automake regeneration,
in that case (where gnu libtool itself isn't needed) then devel/libtool
must be listed as a BUILD_DEPENDS.

USE_LIBTOOL=gnu should not be used unless base libtool doesn't work
with the port (and in that case it should come with agood explanation).

CVS: cvs.openbsd.org: ports

[Nigel Taylor]

CVSROOT:/cvs
Module name:ports
Changes by: ni...@cvs.openbsd.org   2018/04/29 05:52:55

Modified files:
devel/p5-Module-Install: Makefile 

Log message:
Add missing BDEP for v1.18 v1.19 to follow
Ok aja

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2018/04/29 05:20:53

Modified files:
net: Makefile 

Log message:
+toxcore, toxic, utox

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2018/04/29 05:19:43

Modified files:
net/toxcore/pkg: DESCR 
net/utox/pkg   : DESCR 
net/toxic/pkg  : DESCR 

Log message:
Tweak DESCRs

CVS: cvs.openbsd.org: ports

[Nigel Taylor]

CVSROOT:/cvs
Module name:ports
Changes by: ni...@cvs.openbsd.org   2018/04/29 05:18:13

Modified files:
devel/p5-Module-ScanDeps: Makefile 
devel/p5-Module-ScanDeps/pkg: DESCR 

Log message:
Update DESCR for OpenBSD path
Ok aja

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2018/04/29 05:16:30

Log message:
Import toxic 0.8.2.

Toxic is a ncurses-base Tox-based instant messenging client which
formerly resided in the Tox core repository, and is now available as a
standalone application.

From Leonid Bobrov who takes maintainership, ok bcallah@

Status:

Vendor Tag: lbobrov
Release Tags:   landry_20180429

N ports/net/toxic/Makefile
N ports/net/toxic/distinfo
N ports/net/toxic/patches/patch-Makefile
N ports/net/toxic/patches/patch-cfg_targets_install_mk
N ports/net/toxic/pkg/DESCR
N ports/net/toxic/pkg/PLIST

No conflicts created by this import

Re: [New] [WIP] Toxcore, Toxic and uTox

[mazocomp]

On Sun, Apr 29, 2018 at 01:06:21PM +0200, Landry Breuil wrote:
> On Sun, Apr 29, 2018 at 12:43:15PM +0200, Landry Breuil wrote:
> > On Sun, Apr 29, 2018 at 01:33:57PM +0300, mazocomp wrote:
> > > On Sun, Apr 29, 2018 at 01:27:14PM +0300, mazocomp wrote:
> > > > On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> > > > > On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > > > > > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > > > > > 
> > > > > > > On 04/28/18 19:43, mazocomp wrote:
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > Is there any hope this port will be accepted
> > > > > > > > or should I keep maintaining it in WIP tree?
> > > > > > > > 
> > > > > > > > I know toxcore is unstable, but I don't know alternatives.
> > > > > > > > (except bloated ricochet and retroshare)
> > > > > > > > 
> > > > > > > 
> > > > > > > toxcore's license marker should be tweaked to GPLv3+, otherwise 
> > > > > > > ok.
> > > > > > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise 
> > > > > > > ok.
> > > > > > > utox sets -std=gnu11 so should have COMPILER=base-clang 
> > > > > > > ports-gcc, also
> > > > > > > needs NO_TEST=Yes, otherwise ok.
> > > > > > > 
> > > > > > Ok, done.
> > > > > > 
> > > > > > > I don't know anyone who uses tox so I can't test beyond making 
> > > > > > > sure they
> > > > > > > start up and close without crashing, with both do.
> > > > > > > 
> > > > > > > You are not listed as MAINTAINER of any of these. Do you want to 
> > > > > > > be
> > > > > > > MAINTAINER?
> > > > > > > 
> > > > > > Oh, can I? Ok, I'll try.
> > > > > 
> > > > > I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> > > > > uses it) in toxcore so that proper setup of libtool is done. Besides
> > > > > that those ports look okay to me.
> > > > > 
> > > > > Landry
> > > > > 
> > > > After testing both of that I can't find file shared_libs.log
> > > > (I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?
> > > > 
> > > I'm not sure this is right, but ok:
> > 
> > The rationale is to not explicitely adding libtool from ports (the gnu
> > one) unless its really needed, ie delete ports libtool, figure out if
> > the port is fine with the base libtool, and then set USE_LIBTOOL=yes
> > which will set LIBTOOL in the env during build. If you set it to 'gnu'
> > it will also add devel/libtool to the build depends.
> 
> Damn, USE_LIBTOOL=yes is default anyway now. I dont see anything in the port
> that requires libtool, and it seems to build fine if gnu libtool is not
> installed, so why did you add it to BUILD_DEPENDS ?
> 
I didn't add it to build depends, Dmitriy Czarkoff created this port
and added that stuff to build depends, all I did is updating
net/toxcore and net/toxic to recent versions and adding recent
version of net/utox

https://github.com/jasperla/openbsd-wip/commits/master/net/toxcore/Makefile

> Landry
> > 
> 

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2018/04/29 05:15:17

Log message:
Import utox 0.17.0.

uTox is the lightweight client with minimal dependencies,
It not only looks pretty, it runs fast!
uTox is available with full support for:
* chat;
* file transfers;
* audio/video calling;
* desktop sharing (both as video and inline screenshots);
* group chats.

From Leonid Bobrov who takes maintainership, ok bcallah@

Status:

Vendor Tag: lbobrov
Release Tags:   landry_20180429

N ports/net/utox/Makefile
N ports/net/utox/distinfo
N ports/net/utox/pkg/DESCR
N ports/net/utox/pkg/PLIST
N ports/net/utox/patches/patch-CMakeLists_txt

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Landry Breuil]

CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2018/04/29 05:14:09

Log message:
Import toxcore 0.2.2.

Tox is a secure distributed messaging protocol with audio and video chat
capabilities.

This package contains the client library for the Tox protocol.

From Leonid Bobrov who takes maintainership, ok bcallah@

Status:

Vendor Tag: lbobrov
Release Tags:   landry_20180429

N ports/net/toxcore/Makefile
N ports/net/toxcore/distinfo
N ports/net/toxcore/patches/patch-CMakeLists_txt
N ports/net/toxcore/patches/patch-toxcore_ccompat_h
N ports/net/toxcore/pkg/DESCR
N ports/net/toxcore/pkg/PLIST

No conflicts created by this import

Re: [New] [WIP] Toxcore, Toxic and uTox

[Landry Breuil]

On Sun, Apr 29, 2018 at 02:03:02PM +0300, mazocomp wrote:
> On Sun, Apr 29, 2018 at 12:43:15PM +0200, Landry Breuil wrote:
> > On Sun, Apr 29, 2018 at 01:33:57PM +0300, mazocomp wrote:
> > > On Sun, Apr 29, 2018 at 01:27:14PM +0300, mazocomp wrote:
> > > > On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> > > > > On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > > > > > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > > > > > 
> > > > > > > On 04/28/18 19:43, mazocomp wrote:
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > Is there any hope this port will be accepted
> > > > > > > > or should I keep maintaining it in WIP tree?
> > > > > > > > 
> > > > > > > > I know toxcore is unstable, but I don't know alternatives.
> > > > > > > > (except bloated ricochet and retroshare)
> > > > > > > > 
> > > > > > > 
> > > > > > > toxcore's license marker should be tweaked to GPLv3+, otherwise 
> > > > > > > ok.
> > > > > > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise 
> > > > > > > ok.
> > > > > > > utox sets -std=gnu11 so should have COMPILER=base-clang 
> > > > > > > ports-gcc, also
> > > > > > > needs NO_TEST=Yes, otherwise ok.
> > > > > > > 
> > > > > > Ok, done.
> > > > > > 
> > > > > > > I don't know anyone who uses tox so I can't test beyond making 
> > > > > > > sure they
> > > > > > > start up and close without crashing, with both do.
> > > > > > > 
> > > > > > > You are not listed as MAINTAINER of any of these. Do you want to 
> > > > > > > be
> > > > > > > MAINTAINER?
> > > > > > > 
> > > > > > Oh, can I? Ok, I'll try.
> > > > > 
> > > > > I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> > > > > uses it) in toxcore so that proper setup of libtool is done. Besides
> > > > > that those ports look okay to me.
> > > > > 
> > > > > Landry
> > > > > 
> > > > After testing both of that I can't find file shared_libs.log
> > > > (I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?
> > > > 
> > > I'm not sure this is right, but ok:
> > 
> > The rationale is to not explicitely adding libtool from ports (the gnu
> > one) unless its really needed, ie delete ports libtool, figure out if
> > the port is fine with the base libtool, and then set USE_LIBTOOL=yes
> > which will set LIBTOOL in the env during build. If you set it to 'gnu'
> > it will also add devel/libtool to the build depends.
> Oh, I am so blind. Toxcore doesn't use both devel/libtool and
> devel/check anymore.

Better, thanks :) will import it.

Re: [New] [WIP] Toxcore, Toxic and uTox

[Landry Breuil]

On Sun, Apr 29, 2018 at 12:43:15PM +0200, Landry Breuil wrote:
> On Sun, Apr 29, 2018 at 01:33:57PM +0300, mazocomp wrote:
> > On Sun, Apr 29, 2018 at 01:27:14PM +0300, mazocomp wrote:
> > > On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> > > > On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > > > > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > > > > 
> > > > > > On 04/28/18 19:43, mazocomp wrote:
> > > > > > > Hi!
> > > > > > > 
> > > > > > > Is there any hope this port will be accepted
> > > > > > > or should I keep maintaining it in WIP tree?
> > > > > > > 
> > > > > > > I know toxcore is unstable, but I don't know alternatives.
> > > > > > > (except bloated ricochet and retroshare)
> > > > > > > 
> > > > > > 
> > > > > > toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> > > > > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> > > > > > utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, 
> > > > > > also
> > > > > > needs NO_TEST=Yes, otherwise ok.
> > > > > > 
> > > > > Ok, done.
> > > > > 
> > > > > > I don't know anyone who uses tox so I can't test beyond making sure 
> > > > > > they
> > > > > > start up and close without crashing, with both do.
> > > > > > 
> > > > > > You are not listed as MAINTAINER of any of these. Do you want to be
> > > > > > MAINTAINER?
> > > > > > 
> > > > > Oh, can I? Ok, I'll try.
> > > > 
> > > > I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> > > > uses it) in toxcore so that proper setup of libtool is done. Besides
> > > > that those ports look okay to me.
> > > > 
> > > > Landry
> > > > 
> > > After testing both of that I can't find file shared_libs.log
> > > (I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?
> > > 
> > I'm not sure this is right, but ok:
> 
> The rationale is to not explicitely adding libtool from ports (the gnu
> one) unless its really needed, ie delete ports libtool, figure out if
> the port is fine with the base libtool, and then set USE_LIBTOOL=yes
> which will set LIBTOOL in the env during build. If you set it to 'gnu'
> it will also add devel/libtool to the build depends.

Damn, USE_LIBTOOL=yes is default anyway now. I dont see anything in the port
that requires libtool, and it seems to build fine if gnu libtool is not
installed, so why did you add it to BUILD_DEPENDS ?

Landry
> 

Re: [New] [WIP] Toxcore, Toxic and uTox

[mazocomp]

On Sun, Apr 29, 2018 at 12:43:15PM +0200, Landry Breuil wrote:
> On Sun, Apr 29, 2018 at 01:33:57PM +0300, mazocomp wrote:
> > On Sun, Apr 29, 2018 at 01:27:14PM +0300, mazocomp wrote:
> > > On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> > > > On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > > > > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > > > > 
> > > > > > On 04/28/18 19:43, mazocomp wrote:
> > > > > > > Hi!
> > > > > > > 
> > > > > > > Is there any hope this port will be accepted
> > > > > > > or should I keep maintaining it in WIP tree?
> > > > > > > 
> > > > > > > I know toxcore is unstable, but I don't know alternatives.
> > > > > > > (except bloated ricochet and retroshare)
> > > > > > > 
> > > > > > 
> > > > > > toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> > > > > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> > > > > > utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, 
> > > > > > also
> > > > > > needs NO_TEST=Yes, otherwise ok.
> > > > > > 
> > > > > Ok, done.
> > > > > 
> > > > > > I don't know anyone who uses tox so I can't test beyond making sure 
> > > > > > they
> > > > > > start up and close without crashing, with both do.
> > > > > > 
> > > > > > You are not listed as MAINTAINER of any of these. Do you want to be
> > > > > > MAINTAINER?
> > > > > > 
> > > > > Oh, can I? Ok, I'll try.
> > > > 
> > > > I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> > > > uses it) in toxcore so that proper setup of libtool is done. Besides
> > > > that those ports look okay to me.
> > > > 
> > > > Landry
> > > > 
> > > After testing both of that I can't find file shared_libs.log
> > > (I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?
> > > 
> > I'm not sure this is right, but ok:
> 
> The rationale is to not explicitely adding libtool from ports (the gnu
> one) unless its really needed, ie delete ports libtool, figure out if
> the port is fine with the base libtool, and then set USE_LIBTOOL=yes
> which will set LIBTOOL in the env during build. If you set it to 'gnu'
> it will also add devel/libtool to the build depends.
Oh, I am so blind. Toxcore doesn't use both devel/libtool and
devel/check anymore.


tox,4.tar.gz
Description: application/tar-gz

Re: [New] [WIP] Toxcore, Toxic and uTox

[Landry Breuil]

On Sun, Apr 29, 2018 at 01:33:57PM +0300, mazocomp wrote:
> On Sun, Apr 29, 2018 at 01:27:14PM +0300, mazocomp wrote:
> > On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> > > On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > > > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > > > 
> > > > > On 04/28/18 19:43, mazocomp wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > Is there any hope this port will be accepted
> > > > > > or should I keep maintaining it in WIP tree?
> > > > > > 
> > > > > > I know toxcore is unstable, but I don't know alternatives.
> > > > > > (except bloated ricochet and retroshare)
> > > > > > 
> > > > > 
> > > > > toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> > > > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> > > > > utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, 
> > > > > also
> > > > > needs NO_TEST=Yes, otherwise ok.
> > > > > 
> > > > Ok, done.
> > > > 
> > > > > I don't know anyone who uses tox so I can't test beyond making sure 
> > > > > they
> > > > > start up and close without crashing, with both do.
> > > > > 
> > > > > You are not listed as MAINTAINER of any of these. Do you want to be
> > > > > MAINTAINER?
> > > > > 
> > > > Oh, can I? Ok, I'll try.
> > > 
> > > I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> > > uses it) in toxcore so that proper setup of libtool is done. Besides
> > > that those ports look okay to me.
> > > 
> > > Landry
> > > 
> > After testing both of that I can't find file shared_libs.log
> > (I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?
> > 
> I'm not sure this is right, but ok:

The rationale is to not explicitely adding libtool from ports (the gnu
one) unless its really needed, ie delete ports libtool, figure out if
the port is fine with the base libtool, and then set USE_LIBTOOL=yes
which will set LIBTOOL in the env during build. If you set it to 'gnu'
it will also add devel/libtool to the build depends.

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 04:43:33

Modified files:
x11/gnome/shell: Makefile 
Added files:
x11/gnome/shell/patches: patch-js_ui_dnd_js 
 patch-js_ui_tweener_js 
 patch-js_ui_workspaceThumbnail_js 
 patch-js_ui_workspace_js 

Log message:
apply patch from upstream bugreport to fix interaction with gjs
prevents a huge number of stacktraces when doing just about anything

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 04:42:28

Modified files:
infrastructure/bin: update-plist 

Log message:
tweak display

Re: [New] [WIP] Toxcore, Toxic and uTox

[mazocomp]

On Sun, Apr 29, 2018 at 01:27:14PM +0300, mazocomp wrote:
> On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> > On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > > 
> > > > On 04/28/18 19:43, mazocomp wrote:
> > > > > Hi!
> > > > > 
> > > > > Is there any hope this port will be accepted
> > > > > or should I keep maintaining it in WIP tree?
> > > > > 
> > > > > I know toxcore is unstable, but I don't know alternatives.
> > > > > (except bloated ricochet and retroshare)
> > > > > 
> > > > 
> > > > toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> > > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> > > > utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, also
> > > > needs NO_TEST=Yes, otherwise ok.
> > > > 
> > > Ok, done.
> > > 
> > > > I don't know anyone who uses tox so I can't test beyond making sure they
> > > > start up and close without crashing, with both do.
> > > > 
> > > > You are not listed as MAINTAINER of any of these. Do you want to be
> > > > MAINTAINER?
> > > > 
> > > Oh, can I? Ok, I'll try.
> > 
> > I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> > uses it) in toxcore so that proper setup of libtool is done. Besides
> > that those ports look okay to me.
> > 
> > Landry
> > 
> After testing both of that I can't find file shared_libs.log
> (I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?
> 
I'm not sure this is right, but ok:

--- net/toxcore/Makefile.orig   Sun Apr 29 13:18:00 2018
+++ net/toxcore/MakefileSun Apr 29 13:31:51 2018
@@ -31,6 +31,8 @@ LIB_DEPENDS = audio/opus \
multimedia/libvpx \
security/libsodium

+USE_LIBTOOL =  Yes
+
 NO_TEST =  Yes

 .include 

Re: [New] [WIP] Toxcore, Toxic and uTox

[mazocomp]

On Sun, Apr 29, 2018 at 12:13:16PM +0200, Landry Breuil wrote:
> On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> > On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > > 
> > > On 04/28/18 19:43, mazocomp wrote:
> > > > Hi!
> > > > 
> > > > Is there any hope this port will be accepted
> > > > or should I keep maintaining it in WIP tree?
> > > > 
> > > > I know toxcore is unstable, but I don't know alternatives.
> > > > (except bloated ricochet and retroshare)
> > > > 
> > > 
> > > toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> > > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> > > utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, also
> > > needs NO_TEST=Yes, otherwise ok.
> > > 
> > Ok, done.
> > 
> > > I don't know anyone who uses tox so I can't test beyond making sure they
> > > start up and close without crashing, with both do.
> > > 
> > > You are not listed as MAINTAINER of any of these. Do you want to be
> > > MAINTAINER?
> > > 
> > Oh, can I? Ok, I'll try.
> 
> I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
> uses it) in toxcore so that proper setup of libtool is done. Besides
> that those ports look okay to me.
> 
> Landry
> 
After testing both of that I can't find file shared_libs.log
(I used find(1)), should I still set USE_LIBTOOL to Yes or gnu?

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 04:24:18

Modified files:
x11/kde4/artikulate: Makefile 

Log message:
Mark as broken, depends on x11/kde4/kqtquickcharts which is gone

Update is coming soon.

CVS: cvs.openbsd.org: ports

[Solene Rapenne]

CVSROOT:/cvs
Module name:ports
Changes by: sol...@cvs.openbsd.org  2018/04/29 04:21:35

Modified files:
games/tome4: Makefile distinfo 
games/tome4/patches: patch-build_te4core_lua patch-premake4_lua 

Log message:
Update tome4-1.5.8

Contribution from jca@

ok bcallah@ jca@

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 04:21:32

Modified files:
infrastructure/bin: update-plist 

Log message:
don't substitute those either

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 04:19:32

Modified files:
infrastructure/bin: update-plist 

Log message:
tidy

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 04:15:11

Modified files:
infrastructure/bin: update-plist 

Log message:
basic tag-along code for fragments, comments, @exec-like actions

(samples will follow later, they warrant more love)

Re: [New] [WIP] Toxcore, Toxic and uTox

[mazocomp]

The only question left is: who will commit this?
I don't have write access.

Re: CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

On Sun Apr 29, 2018 at 11:48:17AM +0200, Jasper Lievisse Adriaanse wrote:
> On Sun, Apr 29, 2018 at 01:55:02AM -0600, Rafael Sadowski wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: rsadow...@cvs.openbsd.org   2018/04/29 01:55:02
> > 
> > Modified files:
> > x11/kde4   : Makefile 
> > Removed files:
> > x11/kde4/kqtquickcharts: Makefile distinfo 
> > x11/kde4/kqtquickcharts/pkg: DESCR PLIST 
> > 
> > Log message:
> > Remove KDE4 kqtquickcharts (replaced by x11/kde-applications/kqtquickcharts 
> > --
> > KDE5)
> 
> x11/kde4/artikulate still has a dependency on this.
> devel/kdevelop still has a dependency on x11/kde4/kate, which you also just
> removed.
> 

Thanks for pointing that out. kdevelop is fixed and runs fine with KDE5
kate. artikulate is currently broken at run-time but I will send a
replacement as soon as possible,

> Also, no quirks have been committed, was that intentional?
> 

Yeah, because there's a replacement in every single port (@pkgpath)

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 04:13:57

Modified files:
devel/spe  : Makefile 
Added files:
devel/spe/patches: patch-_spe_SPE_py 
   patch-_spe_plugins_winpdb_rpdb2_py 

Log message:
py-crypto -> py-cryptodome

Re: [New] [WIP] Toxcore, Toxic and uTox

[Landry Breuil]

On Sun, Apr 29, 2018 at 12:41:01PM +0300, mazocomp wrote:
> On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> > 
> > On 04/28/18 19:43, mazocomp wrote:
> > > Hi!
> > > 
> > > Is there any hope this port will be accepted
> > > or should I keep maintaining it in WIP tree?
> > > 
> > > I know toxcore is unstable, but I don't know alternatives.
> > > (except bloated ricochet and retroshare)
> > > 
> > 
> > toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> > toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> > utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, also
> > needs NO_TEST=Yes, otherwise ok.
> > 
> Ok, done.
> 
> > I don't know anyone who uses tox so I can't test beyond making sure they
> > start up and close without crashing, with both do.
> > 
> > You are not listed as MAINTAINER of any of these. Do you want to be
> > MAINTAINER?
> > 
> Oh, can I? Ok, I'll try.

I think you need to set USE_LIBTOOL = Yes (or gnu, depending on how it
uses it) in toxcore so that proper setup of libtool is done. Besides
that those ports look okay to me.

Landry

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 04:07:52

Modified files:
devel/kdevelop : Makefile 

Log message:
fix run depends on kate

Spotted by jasper@; Thanks

Re: NEW: x11/kde-applications/libkdcraw

[Landry Breuil]

On Sun, Apr 29, 2018 at 11:58:02AM +0200, Rafael Sadowski wrote:
> On Sun Apr 29, 2018 at 11:01:11AM +0200, Landry Breuil wrote:
> > On Sun, Apr 29, 2018 at 10:04:25AM +0200, Rafael Sadowski wrote:
> > > $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> > > Libkdcraw is a C++ interface around LibRaw library used to decode RAW 
> > > picture
> > > files.
> > > 
> > > Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> > > conflicts with libkdcraw from KDE4 but we can't just commit because all
> > > KDE4 applications will grep/find libkdcraw-17.12.3 instead
> > > libkdcraw-4.*, which is wrong.
> > 
> > Do you mean at install time ?  just because the pkgname is the same ?
> > use @option is-branch maybe ?
> > 
> 
> Exactly, pkgname is the same but somehow everything looks okay:
> 
> $ TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all pkg_add gwenview
> gwenview-4.14.3p3:libkdcraw-4.14.3p2: ok
> gwenview-4.14.3p3:libkipi-4.14.3p2: ok
> gwenview-4.14.3p3: ok
> 
> The 17.12.3 packages will not fetch. kde4 is smart enough, anyway ok?

I'm not 100% sure but i think you *have* to at least set @option
no-default-config (maybe is-branch?), otherwise the packages will
conflict by default since they have the same name, even if they don't
have actual files conflicting.

Re: NEW: x11/kde-applications/libkdcraw

[Rafael Sadowski]

On Sun Apr 29, 2018 at 11:01:11AM +0200, Landry Breuil wrote:
> On Sun, Apr 29, 2018 at 10:04:25AM +0200, Rafael Sadowski wrote:
> > $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> > Libkdcraw is a C++ interface around LibRaw library used to decode RAW 
> > picture
> > files.
> > 
> > Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> > conflicts with libkdcraw from KDE4 but we can't just commit because all
> > KDE4 applications will grep/find libkdcraw-17.12.3 instead
> > libkdcraw-4.*, which is wrong.
> 
> Do you mean at install time ?  just because the pkgname is the same ?
> use @option is-branch maybe ?
> 

Exactly, pkgname is the same but somehow everything looks okay:

$ TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all pkg_add gwenview
gwenview-4.14.3p3:libkdcraw-4.14.3p2: ok
gwenview-4.14.3p3:libkipi-4.14.3p2: ok
gwenview-4.14.3p3: ok

The 17.12.3 packages will not fetch. kde4 is smart enough, anyway ok?

Re: CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

On Sun, Apr 29, 2018 at 01:55:02AM -0600, Rafael Sadowski wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   rsadow...@cvs.openbsd.org   2018/04/29 01:55:02
> 
> Modified files:
>   x11/kde4   : Makefile 
> Removed files:
>   x11/kde4/kqtquickcharts: Makefile distinfo 
>   x11/kde4/kqtquickcharts/pkg: DESCR PLIST 
> 
> Log message:
> Remove KDE4 kqtquickcharts (replaced by x11/kde-applications/kqtquickcharts --
> KDE5)

x11/kde4/artikulate still has a dependency on this.
devel/kdevelop still has a dependency on x11/kde4/kate, which you also just
removed.

Also, no quirks have been committed, was that intentional?

-- 
jasper

Re: [New] [WIP] Toxcore, Toxic and uTox

[mazocomp]

On Sat, Apr 28, 2018 at 08:17:56PM -0400, Brian Callahan wrote:
> 
> On 04/28/18 19:43, mazocomp wrote:
> > Hi!
> > 
> > Is there any hope this port will be accepted
> > or should I keep maintaining it in WIP tree?
> > 
> > I know toxcore is unstable, but I don't know alternatives.
> > (except bloated ricochet and retroshare)
> > 
> 
> toxcore's license marker should be tweaked to GPLv3+, otherwise ok.
> toxic doesn't need HOMEPAGE set if you're using GH_*, otherwise ok.
> utox sets -std=gnu11 so should have COMPILER=base-clang ports-gcc, also
> needs NO_TEST=Yes, otherwise ok.
> 
Ok, done.

> I don't know anyone who uses tox so I can't test beyond making sure they
> start up and close without crashing, with both do.
> 
> You are not listed as MAINTAINER of any of these. Do you want to be
> MAINTAINER?
> 
Oh, can I? Ok, I'll try.

> ~Brian
> 


tox,3.tar.gz
Description: application/tar-gz

CVS: cvs.openbsd.org: ports

[Robert Peichaer]

CVSROOT:/cvs
Module name:ports
Changes by: r...@cvs.openbsd.org2018/04/29 03:37:07

Modified files:
www/selfoss: Makefile distinfo 
www/selfoss/pkg: PLIST 

Log message:
Update www/selfoss to 2.18

OK aja

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 03:33:00

Added files:
games/easyrpg/patches: patch-src_audio_sdl_mixer_cpp 

Log message:
fix build after sdl_mixer update; from upstream

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2018/04/29 03:28:53

Modified files:
textproc/html-xml-utils: Makefile 
Added files:
textproc/html-xml-utils/patches: patch-Makefile_am 
 patch-configure_ac 
Removed files:
textproc/html-xml-utils/patches: patch-Makefile_in 

Log message:
Fetch and insert the proper iconv.m4 glue to detect iconv() when it
is provided by libiconv, and explicitly link with libiconv since the
iconv() functions are called from the program.  Fixes linking with lld.
ok bentley@

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 03:27:32

Added files:
games/dunelegacy/patches: 
  
patch-src_FileClasses_music_DirectoryPlayer_cpp 
  patch-src_FileClasses_music_XMIPlayer_cpp 

Log message:
Fix build with sdl_mixer 2.0.2; from slackbuilds

CVS: cvs.openbsd.org: ports

[Solene Rapenne]

CVSROOT:/cvs
Module name:ports
Changes by: sol...@cvs.openbsd.org  2018/04/29 03:23:56

Modified files:
mail/mu: Makefile distinfo 
mail/mu/pkg: PLIST 

Log message:
Update to mu-1.0

ok jca@

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 03:15:05

Modified files:
x11/gnome/system-monitor: Makefile 

Log message:
add missing build dependency to address "cannot locate ITS rules for 
org.gnome.gnome-system-monitor.policy.in "

CVS: cvs.openbsd.org: ports

[Christian Weisgerber]

CVSROOT:/cvs
Module name:ports
Changes by: na...@cvs.openbsd.org   2018/04/29 03:07:39

Modified files:
databases/gq   : Makefile 

Log message:
GNU libiconv doesn't actually provide iconv() etc., but libiconv()
and maps the functions with  to the standard names.  This
causes naive link checks to fail.  The recommended upstream iconv.m4
autoconf check that handles all this is rather large, pulls in more
macros, and may be difficult to retrofit into old configure.in
scripts written for obsolete autotools versions.  Instead, it is
simpler to just override the check and assert that we indeed have
iconv().

The failing test causes the final link command line to omit -liconv.
The iconv() function is still referenced from the code, so overriding
the test fixes linking with lld.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/04/29 03:05:44

Modified files:
sysutils/polkit: Makefile 
Added files:
sysutils/polkit/patches: 
 
patch-src_polkitbackend_polkitbackendjsauthority_cpp 

Log message:
jsauthority: pass "%s" format string to remaining report function; upstream

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 03:04:53

Modified files:
sysutils/py-ghmi: Makefile 
Added files:
sysutils/py-ghmi/patches: patch-pyghmi_ipmi_private_session_py 

Log message:
switch to py-cryptodome

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 03:03:50

ports/sysutils/py-ghmi/patches

Update of /cvs/ports/sysutils/py-ghmi/patches
In directory cvs.openbsd.org:/tmp/cvs-serv19405/patches

Log Message:
Directory /cvs/ports/sysutils/py-ghmi/patches added to the repository

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/04/29 03:03:43

Modified files:
devel/dconf: Makefile 

Log message:
Extend comment.

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2018/04/29 03:01:56

Modified files:
infrastructure/bin: update-plist 

Log message:
tweak display
find out first what will be copied so that we can attach tags to them

Re: NEW: x11/kde-applications/libkdcraw

[Landry Breuil]

On Sun, Apr 29, 2018 at 10:04:25AM +0200, Rafael Sadowski wrote:
> $ cat x11/kde-applications/libkdcraw/pkg/DESCR
> Libkdcraw is a C++ interface around LibRaw library used to decode RAW picture
> files.
> 
> Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
> conflicts with libkdcraw from KDE4 but we can't just commit because all
> KDE4 applications will grep/find libkdcraw-17.12.3 instead
> libkdcraw-4.*, which is wrong.

You're not clear at all, i dont understand what you mean here. this
version installs libKF5KDcraw, the kde4 version installs libkdcraw, so
how kde4 apps might use the wrong one ? Do you mean at install time ?
just because the pkgname is the same ? use @option is-branch maybe ?

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2018/04/29 03:00:07

Modified files:
textproc/meld  : Makefile distinfo 
textproc/meld/pkg: PLIST 

Log message:
Update to meld-3.18.1.

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 02:56:56

Modified files:
security   : Makefile 

Log message:
+py-cryptodome
+py-cryptodome,python3

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 02:55:50

Log message:
import py-cryptodomex-3.6.1

PyCryptodome is a self-contained Python package of low-level cryptographic
primitives. It is an cleaned and simplified fork of PyCrypto, exposing
almost the same API. Most applications run unmodified, apart from a very
few compatibility breaks for those parts of the API that represented a
security hazard or that were too hard to maintain.

NB: currently we're packaging cryptodomex which doesn't conflict with 
py-crypto.
once all callers are migrated we can switch to the regular cryptodome 
package.

with and ok sthen@

Status:

Vendor Tag: jasper
Release Tags:   jasper_20182904

N ports/security/py-cryptodome/Makefile
N ports/security/py-cryptodome/distinfo
N ports/security/py-cryptodome/pkg/PLIST
N ports/security/py-cryptodome/pkg/DESCR

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 02:13:07

Modified files:
productivity/vym: Makefile distinfo 
productivity/vym/pkg: PLIST 

Log message:
update to vym-2.6.0

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 02:08:46

Modified files:
lang/ecl   : Makefile 

Log message:
when bumping revision, make sure to bump it and not add another REVISION=0

NEW: x11/kde-applications/libkdcraw

[Rafael Sadowski]

$ cat x11/kde-applications/libkdcraw/pkg/DESCR
Libkdcraw is a C++ interface around LibRaw library used to decode RAW picture
files.

Looks simple but it feels like a trap. libkdcraw-17.12.3 has no
conflicts with libkdcraw from KDE4 but we can't just commit because all
KDE4 applications will grep/find libkdcraw-17.12.3 instead
libkdcraw-4.*, which is wrong.

Any (simple) clue?

Ok to import?

Rafael Sadowski


libkdcraw-17.12.3.tar.gz
Description: Binary data

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 01:55:02

Modified files:
x11/kde4   : Makefile 
Removed files:
x11/kde4/kqtquickcharts: Makefile distinfo 
x11/kde4/kqtquickcharts/pkg: DESCR PLIST 

Log message:
Remove KDE4 kqtquickcharts (replaced by x11/kde-applications/kqtquickcharts --
KDE5)

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2018/04/29 01:49:20

Added files:
sysutils/socket/patches: patch-utils_c 

Log message:
thank you cvs(1)

Re: update lang/sbcl

[Solene Rapenne]

Josh Elsasser writes:

> On Fri, Apr 27, 2018 at 08:56:04PM -0700, Josh Elsasser wrote:
>> Patching the i386 and ppc *-arch.c files isn't necessary. However i386
>> didn't build for me (in a VM). I think we need to do this in
>> patches/patch-src_runtime_bsd-os_c:
>
> This is obviously wrong now that I look closer. I'll investigate further.
>
>> $OpenBSD$
>>
>> MAP_TRYFIXED is needed to allow SBCL to relocate its heap if the
>> hardcoded virtual address is unavailable.
>>
>> Index: src/runtime/bsd-os.c
>> --- src/runtime/bsd-os.c.orig
>> +++ src/runtime/bsd-os.c
>> @@ -157,7 +157,11 @@ os_validate(int movable, os_vm_address_t addr, os_vm_s
>>   * the hint address, and moreover that it "is the default 
>> behavior") */
>>  // FALLTHROUGH_INTENDED
>>  case NOT_MOVABLE:
>> +#ifdef MAP_TRYFIXED
>> +flags = MAP_TRYFIXED;
>> +#else
>>  flags = MAP_FIXED;
>> +#endif
>>  }
>>  #ifdef MAP_EXCL // not defined in OpenBSD, NetBSD, DragonFlyBSD
>>  if (flags & MAP_FIXED) flags |= MAP_EXCL;
>>

Christian Weisgerber reported me that sbcl build was failing on i386
with 1.4.6, build log attached to the mail. Maybe sbcl is allocating too
much memory, I don't know... I don't have an i386 system at the moment
to debug this. Otherwise, next week I will be able to try sbcl on
powerpc arch as I am using it daily.



sbcl.log.gz
Description: sbcl build log

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 01:47:21

Modified files:
meta/kde4  : Makefile 
x11/kde4   : Makefile 
Removed files:
x11/kde4/ktouch: Makefile distinfo 
x11/kde4/ktouch/pkg: DESCR PLIST 

Log message:
Remove KDE4 ktouch (replaced by x11/kde-applications/ktouch -- KDE5)

- unhook
- zap from meta
- drop all all KDE4 parts

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 01:41:41

Modified files:
meta/kde4  : Makefile 
x11/kde4   : Makefile 
Removed files:
x11/kde4/kate  : Makefile distinfo 
x11/kde4/kate/patches: 
   
patch-addons_kate_backtracebrowser_CMakeLists_txt 
   
patch-addons_kate_close-except-like_CMakeLists_txt 
   patch-addons_kate_filebrowser_CMakeLists_txt 
   patch-addons_kate_gdbplugin_CMakeLists_txt 
   patch-addons_kate_helloworld_CMakeLists_txt 
   patch-addons_kate_kate-ctags_CMakeLists_txt 
   
patch-addons_kate_katebuild-plugin_CMakeLists_txt 
   patch-addons_kate_katesql_CMakeLists_txt 
   patch-addons_kate_konsole_CMakeLists_txt 
   patch-addons_kate_kttsd_CMakeLists_txt 
   patch-addons_kate_mailfiles_CMakeLists_txt 
   patch-addons_kate_pate_src_CMakeLists_txt 
   patch-addons_kate_pate_src_version_checker_h 
   patch-addons_kate_project_CMakeLists_txt 
   patch-addons_kate_search_CMakeLists_txt 
   patch-addons_kate_snippets_CMakeLists_txt 
   patch-addons_kate_symbolviewer_CMakeLists_txt 
   patch-addons_kate_tabbarextension_CMakeLists_txt 
   patch-addons_kate_tabify_CMakeLists_txt 
   patch-addons_kate_textfilter_CMakeLists_txt 
   patch-addons_kate_xmlcheck_CMakeLists_txt 
   patch-addons_kate_xmltools_CMakeLists_txt 
   patch-addons_ktexteditor_exporter_CMakeLists_txt 
   
patch-addons_ktexteditor_hlselection_CMakeLists_txt 
   
patch-addons_ktexteditor_insertfile_CMakeLists_txt 
   patch-kate_app_CMakeLists_txt 
   patch-part_CMakeLists_txt 
   patch-part_view_kateviewhelpers_cpp 
   patch-tests_CMakeLists_txt 
x11/kde4/kate/pkg: DESCR PLIST 

Log message:
Remove KDE4 kate (replaced by x11/kde-applications/kate -- KDE5)

- unhook
- zap from meta
- drop all all KDE4 parts

NEW: x11/kde-applications/okteta (replacement for x11/kde4/okteta)

[Rafael Sadowski]

$ cat x11/kde-applications/okteta/pkg/DESCR
Okteta is a simple editor for the raw data of files.

Features

- Values and characters shown either in two columns (the traditional display in
  hex editors) or in rows with the value on top of the character
- Editing and navigating similar to a text editor
- Customizable data views
- Data view profiles
- Tools dockable on all sides or floating
- Numerical encodings: Hexadecimal, Decimal, Octal, Binary
- Character encodings: All 8-bit encodings as supplied by Qt, EBCDIC
- Fast data rendering on screen
- Multiple open files
- Support for remote files, by http, ftp, fish & other protocols supported by
  KDE Platform
- Export of data to text, both file and clipboard.
- Checksum/Hashsum calculator: Modular sum (8/16/32/64 bit), Adler-32, CRC-32
  and Hashsums by the QCA2 library, can be SHA-0/1/224/256/384/512, MD2/4/5,
  RIPEMD-160, Whirlpool
- Structures tool for analyzing and editing based on user-creatable structure
  definitions
- Statistic tool
- String extraction tool
- 8-bit charset conversion tool
- Decoding table listing common simple data types.
- Bookmarks
- Printing
- Table with complete list of all byte values

I see no conflict with other application(s) so only set "@pkgpath
x11/kde4/okteta".

Ok? Comments?

Rafael Sadowski


okteta-17.12.3.tar.gz
Description: Binary data

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 00:51:04

Modified files:
x11/kde-applications: Makefile 

Log message:
hook ktouch

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2018/04/29 00:49:56

Log message:
Import ktouch-17.12.3

KTouch is a typing learning tool for KDE.

It is a part of KDE Edu project.

ok landry@

Status:

Vendor Tag: rsadowski
Release Tags:   rsadowski_20180429

N ports/x11/kde-applications/ktouch/Makefile
N ports/x11/kde-applications/ktouch/distinfo
N ports/x11/kde-applications/ktouch/pkg/DESCR
N ports/x11/kde-applications/ktouch/pkg/PLIST

No conflicts created by this import

Re: CVS: cvs.openbsd.org: src

[Kirill Bychkov]

On Sun, April 29, 2018 00:25, Stuart Henderson wrote:
> It needs more of a change than that, the syntax is different.
>

Hi!
It uses /usr/bin/mail so it is safe to drop embedded smtp (see
/etc/apcupsd/apccontrol) and I doubt someone tweaked it to use
other mailers instead of its default.So no tweaks for MESSAGE
are needed, IMO.
Thanks for noticing it!
OK kirby@

> --
> Sent from a phone, apologies for poor formatting.
> On 28 April 2018 18:30:32 Vadim Zhukov  wrote:
>
>> 2018-04-28 19:54 GMT+03:00 Eric Faurot :
>> > CVSROOT:/cvs
>> > Module name:src
>> > Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11
>> >
>> > Modified files:
>> > usr.sbin/smtpd : Makefile
>> >
>> > Log message:
>> > link smtp(1) to the build
>> >
>> > ok deraadt@
>>
>> Some care would be needed for apcupsd port, which installs
>> /usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp
>> and port could just stop installing it. The existing smtp users could
>> be affected, though, so I propose the following patch. Any better
>> ideas/objections/okays?
>>
>> --
>>  WBR,
>>  Vadim Zhukov
>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v
>> retrieving revision 1.38
>> diff -u -p -r1.38 Makefile
>> --- Makefile12 Jan 2018 14:05:10 -  1.38
>> +++ Makefile28 Apr 2018 17:27:33 -
>> @@ -9,7 +9,7 @@ PKGNAME-main =  ${DISTNAME}
>> PKGNAME-cgi =  ${DISTNAME:S/-/-cgi-/}
>> PKGNAME-x11 =  ${DISTNAME:S/-/-x11-/}
>> REVISION = 1
>> -REVISION-main =2
>> +REVISION-main =3
>>
>> CATEGORIES =   sysutils
>>
>> @@ -108,5 +108,6 @@ post-install:
>>${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/
>>cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd
>>chmod 755 ${PREFIX}/sbin/apcupsctl
>> +   rm -f ${PREFIX}/sbin/smtp
>>
>> .include 
>> Index: pkg/MESSAGE-main
>> ===
>> RCS file: pkg/MESSAGE-main
>> diff -N pkg/MESSAGE-main
>> --- /dev/null   1 Jan 1970 00:00:00 -
>> +++ pkg/MESSAGE-main28 Apr 2018 17:27:33 -
>> @@ -0,0 +1,2 @@
>> +The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4.
>> +Any scripts using it should now use the /usr/bin/smtp instead.
>> Index: pkg/PLIST-main
>> ===
>> RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v
>> retrieving revision 1.9
>> diff -u -p -r1.9 PLIST-main
>> --- pkg/PLIST-main  22 Jan 2015 21:23:30 -  1.9
>> +++ pkg/PLIST-main  28 Apr 2018 17:27:33 -
>> @@ -14,7 +14,6 @@
>> @mode
>> @owner
>> sbin/apcupsctl
>> -@bin sbin/smtp
>> @comment share/applications/
>> @group
>> share/doc/apcupsd/
>
>
>
>

Re: NEW: x11/kde-applications/ktouch

[Landry Breuil]

On Sat, Apr 28, 2018 at 11:16:15PM +0200, Rafael Sadowski wrote:
> On Sat Apr 28, 2018 at 11:05:46PM +0300, Vadim Zhukov wrote:
> > 2018-04-28 22:44 GMT+03:00 Rafael Sadowski :
> > >
> > > On Thu Apr 26, 2018 at 10:43:14PM +0300, Vadim Zhukov wrote:
> > >> 2018-04-26 21:58 GMT+03:00 Rafael Sadowski :
> > >> > Please find attached next new KDE4 replacement.
> > >> >
> > >> > Conflict bits are set:
> > >> >
> > >> > @conflict ktouch-<17.12.3
> > >> > @conflict kdebase-*
> > >> > @pkgpath x11/kde4/ktouch
> > >> >
> > >> > $ cat x11/kde-applications/ktouch/pkg/DESCR
> > >> > KTouch is a typing learning tool for KDE.
> > >> >
> > >> > It is a part of KDE Edu project.
> > >> >
> > >> > Ok? Commenst?
> > >>
> > >> Well, ktouch conflicts with ktouch by definition, so the first
> > >> @conflict shouldn't be needed. :)
> > >
> > > That was exactly the idea of not allowing either.
> > >
> > > The question is: do we want to replace everything step by step but how
> > > if we set conflict with kdebase-*. That doesn't make much sense to me.
> > > Or do we want KDE4 || KDE5 Application?
> > >
> > > I think teh following is wrong:
> > >
> > >> > @conflict ktouch-<17.12.3
> > >> > @conflict kdebase-*
> > >> > @pkgpath x11/kde4/ktouch
> > >
> > > Because "@pkgpath x11/kde4/*" is in conflict with "@conflict kdebase-*"
> > >
> > > I prefer it like now. x11/kde4 OR x11/kde-applications/*:
> > >
> > >> > @conflict ktouch-<17.12.3
> > >> > @conflict kdebase-*
> > >
> > > without pkgpath.
> > >
> > > I would be happy to hear the opinion of our pro porters!?
> > 
> > I think you've got @conflict and @pkgpath wrong.
> > 
> > The @conflict marks that you can't have both packages installed at the
> > same time. The package by default conflicts with any other with same
> > name, version and flavors are out of this check.
> > 
> > The @pkgpath instead tells that given package should be "compatible"
> > with another one, even with different name, in case of updating
> > packages.
> > 
> > So we have to have "@conflict kdebase-*" since both kdebase and ktouch
> > packages contain same file(-s). And there is no point in having
> > "@conflict ktouch-<17.12.3" since it's superseded by implicit default
> > "@conflict ktouch-*".
> > 
> > But "@pkgpath x11/kde4/ktouch" solves a totally different problem,
> > allowing pkg_add not to complain when replacing KDE4's KTouch with
> > KDE5 one. Note that @pkgpath kicks only when there's @conflict, either
> > implicit or explicit.
> > 
> > The appropriate @conflict+@pkgpat pair would mean not "you can't
> > install this" but "you can upgrade to this".
> 
> ACK;
> 
> > 
> > Now to main question: do we want to have KDE Applications both from
> > KDE4 and KDE5 worlds? They are almost equal at resources being used,
> > but KDE4 isn't maintained upstream at all. And KF5-based apps
> > perfectly work under KDE4 desktop and talk with KDE4 apps via, e.g.,
> > D-Bus. Yes, you'll have both Qt4 and Qt5 installed, as well quiet a
> > few other libraries, until migration ends. Does such situation hurt
> > anyone running modern desktop?
> > 
> > My plan a long ago was getting rid of KDE4 as soon as KF5-based stuff
> > comes in. Thus, x11/kde4/ktouch gets unlinked at the same time
> > x11/kde-applications/ktouch is linked to build. But since I'm not
> > doing the real work right now, it's not my right to take decisions
> > here.
> 
> I think you're right, and it's the best decision. Are there any
> objections?

I support the replacement, no need for both versions, and it makes
things simpler.

> Btw I need an ok to import ktouch.

ok