CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2017/07/02 23:43:56

Modified files:
misc/supercat  : Makefile distinfo 
misc/supercat/pkg: PLIST 

Log message:
Update to 0.5.6 -- adds case-insensitive REs. Tweak license marker to be
more specific (GPLv3+).
ok Girish Venkatachalam (MAINTAINER)

Re: UPDATE: www/phantomjs

[Pavel Korovin]

Please find updated/fixed diff/tgz for phantomjs-2.1.1 attached.

-- 
With best regards,
Pavel Korovin


phantomjs-2.1.1.diff.gz
Description: application/gunzip


phantomjs-2.1.1.tar.gz
Description: application/tar-gz

CVS: cvs.openbsd.org: ports

[Pratik Vyas]

CVSROOT:/cvs
Module name:ports
Changes by: p...@cvs.openbsd.org2017/07/02 21:45:18

Modified files:
geo/openbsd-developers: Makefile 
geo/openbsd-developers/files: OpenBSD 

Log message:
add myself

ok mlarkin@

Re: NEW: multimedia/streamlink && REMOVE x2: multimedia/livestreamer and multimedia/livestreamer-curses

[Brian Callahan]

On 06/22/17 19:55, Brian Callahan wrote:

Hi ports --

Attached is a new port, multimedia/streamlink. Streamlink is a Python 
utility that lets you pipe video streams into a video player. It is a 
fork of multimedia/livestreamer. Livestreamer is dead, streamlink is 
the new livestreamer.


---
pkg/DESCR:
Streamlink is a command-line utility that pipes video streams from
various services into a video player, such as VLC. The main purpose of
Streamlink is to allow the user to avoid buggy and CPU heavy flash
plugins but still be able to enjoy various streamed content. There is
also an API available for developers who want access to the video stream
data. This project was forked from Livestreamer, which is no longer
maintained.

Streamlink is built upon a plugin system which allows support for new
services to be easily added. Currently most of the big streaming
services are supported, such as:

* Dailymotion
* Livestream
* Twitch
* UStream
* YouTube Live

and many more.
---

This requires devel/py-iso3166 and devel/py-iso639 that were just 
committed.


I looked to see if it would be a simple diff to make 
multimedia/livestreamer-curses work with streamlink. Someone appears 
to have done the work but it looks like major surgery (and 
livestreamer-curses might also be dead upstream) so I think it's 
better to remove it.


I think it makes sense for anyone who has livestreamer installed on 
their system to get upgraded to streamlink.


I'm watching a Twitch.tv stream on my laptop as I write this email, so 
it definitely works.


OK?

~Brian



Ping. Watching SGDQ on my laptop as I write this, so it's still good.
(In any event, we should remove livestreamer, as it no longer supports 
all streaming services it claims to and will only support fewer and 
fewer as time goes on.)

CVS: cvs.openbsd.org: ports

[Gonzalo L . Rodriguez]

CVSROOT:/cvs
Module name:ports
Changes by: gonz...@cvs.openbsd.org 2017/07/02 19:28:53

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

Log message:
Update for SQLmap to 1.1.7:

https://github.com/sqlmapproject/sqlmap

OK rpointel@

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2017/07/02 16:20:22

Modified files:
textproc/the_silver_searcher: Makefile distinfo 
Removed files:
textproc/the_silver_searcher/patches: patch-src_ignore_c 
  patch-src_options_c 
  patch-src_scandir_h 
  patch-src_search_c 

Log message:
Update to 2.0.0 -- Please note that this breaks backwards compatibility as
.agignore was renamed to .ignore!
ok Florian Stinglmayr (MAINTAINER)

[maintainer update] www/py-jwt

[Johan Huldtgren]

hello,

minor update of www/py-jwt from 1.5.0 to 1.5.2, I've removed
our patch which just disabled pytest_runner, IIRC at the time
we put it in, it was to stop the port from trying to autofetch
it as we didn't have it in tree. I can no longer duplicate this
behavior (i.e. on a system without pytest_runner and with no
internet connection this still builds correctly). However I'd
appreciate a second set of eyes to confirm.

thanks,

.jhIndex: py-jwt/Makefile
===
RCS file: /cvs/ports/www/py-jwt/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- py-jwt/Makefile	24 Apr 2017 09:30:00 -	1.8
+++ py-jwt/Makefile	2 Jul 2017 21:37:03 -
@@ -2,12 +2,11 @@
 
 COMMENT =	JSON Web Token implementation in Python
 
-MODPY_EGG_VERSION = 1.5.0
+MODPY_EGG_VERSION = 1.5.2
 DISTNAME =	PyJWT-${MODPY_EGG_VERSION}
 PKGNAME =	py-jwt-${MODPY_EGG_VERSION}
 CATEGORIES =	www
 MAINTAINER =	Johan Huldtgren 
-REVISION =	0
 
 HOMEPAGE =	http://github.com/jpadilla/pyjwt
 
@@ -27,6 +26,9 @@ RUN_DEPENDS =   security/py-cryptography
 TEST_DEPENDS =	devel/py-test \
 		devel/py-test-cov \
 		devel/py-test-runner
+
+post-extract:
+	@find ${WRKSRC}/tests -name '__pycache__'  | xargs rm -rf
 
 post-install:
 	mv ${PREFIX}/bin/pyjwt ${PREFIX}/bin/pyjwt${MODPY_BIN_SUFFIX}
Index: py-jwt/distinfo
===
RCS file: /cvs/ports/www/py-jwt/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- py-jwt/distinfo	24 Apr 2017 09:30:00 -	1.4
+++ py-jwt/distinfo	2 Jul 2017 21:37:03 -
@@ -1,2 +1,2 @@
-SHA256 (PyJWT-1.5.0.tar.gz) = /Rgrco0T8EwonZsmI9CSVtNWybSmd4AYABRUqVTXxUs=
-SIZE (PyJWT-1.5.0.tar.gz) = 34841
+SHA256 (PyJWT-1.5.2.tar.gz) = EXnwv/hkY7UwjuX3r/HDUOHzgTnWKnI+FvssVX0ceV8=
+SIZE (PyJWT-1.5.2.tar.gz) = 72715

Re: UPDATE: print/texinfo

[Matthias Kilian]

On Sun, Jul 02, 2017 at 12:35:13AM +0200, Matthias Kilian wrote:
> On Thu, Jun 29, 2017 at 01:46:40PM +0200, Ingo Feinerer wrote:
> > Update print/texinfo 6.3 -> 6.4
> > 
> > - No failing tests ('make test') on amd64.
> > - perl WANTLIB seems to be no longer needed (as reported by 'make
> >   port-lib-depends-check').
> > 
> > OK?
> 
> I'm currently running dpb in update mode with it and will have a
> look at the logs of the few ports depending on it tomorrow.

There were sime warning and errors in math/maxima, but those look
like coming from a texi2html script included in the maxima sources.
I'm not even sure wether this is new.

Since everything else seems to look fine: ok.

Ciao,
Kili

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2017/07/02 15:04:48

Modified files:
sysutils/pftop/patches: patch-Makefile 

Log message:
forgot about the multiple targets semantic. Fix it properly for parallel
make

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2017/07/02 14:46:12

Modified files:
sysutils/pftop/patches: patch-Makefile 

Log message:
fix the fix.  yacc rules that generate a .h file that we need to depend on
MUST be explicitly written

CVS: cvs.openbsd.org: ports

[Marc Espie]

CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2017/07/02 14:33:06

Modified files:
net/dsocks : Makefile 

Log message:
overriding the flags on the command line means bsd.dep.mk can't do its job.
fix it.

(not an issue with clang)

CVS: cvs.openbsd.org: ports

[Anton Lindqvist]

CVSROOT:/cvs
Module name:ports
Changes by: an...@cvs.openbsd.org   2017/07/02 13:37:22

Modified files:
sysutils/pick  : Makefile distinfo 

Log message:
Update pick to 1.7.0.

ok jca@

Re: NEW: devel/leiningen

[Jasper Lievisse Adriaanse]

On Sun, Jul 02, 2017 at 05:12:15PM +0100, Edd Barrett wrote:
> Hi Jon,
> 
> On Thu, Jun 29, 2017 at 10:38:32AM -0400, Jon Bernard wrote:
> > Attached is a port of leiningen, for automating clojure projects.
> 
> Comments:
> 
>  * There's a hard-coded path to bash in a patch. You will need to use a
>variable (LOCALBASE) in place of /usr/local and then use
>${SUBST_CMD} in a custom make target, maybe post-install.
> 
>  * Did you try that script with /bin/sh? If it works that would be
>preferable. Otherwise, bash needs to be a RUN_DEPEND.
> 
>  * mandoc linter is unhappy with the man page:
> 
>$ mandoc -Tlint /usr/local/man/man1/lein.1 
>mandoc: /usr/local/man/man1/lein.1:2:17: WARNING: cannot parse date, using 
> it verbatim: 2011 June 30
> 
>Consider pathcing?
> 
>  * I was surprised to see that your port did not RUN_DEPEND on clojure.
>I see that upon first `lein repl` the tool will download a clojure
>using (the horror) maven (which must be bundled?). I *think*, but
>other porters can correct me, we would prefer to use the in-tree
>clojure instead of a moving target. Is this possible?
> 
>  * Even if I let it do its thing, the repl doesn't seem to work:
> 
> ---8<---
> $ lein repl 
> Retrieving org/clojure/clojure/1.8.0/clojure-1.8.0.pom from central
> Retrieving org/sonatype/oss/oss-parent/7/oss-parent-7.pom from central
> Retrieving org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.pom from 
> central
> Retrieving org/clojure/pom.contrib/0.1.2/pom.contrib-0.1.2.pom from 
> central
> Retrieving 
> clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.pom from 
> clojars
> Retrieving org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar from 
> central
> Retrieving org/clojure/clojure/1.8.0/clojure-1.8.0.jar from central
> Retrieving 
> clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar from 
> clojars
> REPL server launch timed out.
> --->8---
> 
> I know nothing about Clojure or lein, so I'm going to CC our clojure
> MAINTAINER, Jasper.
> 
> Cheers
> 
> -- 
> Best Regards
> Edd Barrett
> 
> http://www.theunixzoo.co.uk

We used to have a port of leiningen, but I removed it more than 3 years ago:

8<
Revision 1.6, Sat Nov 9 10:40:20 2013 UTC (3 years, 7 months ago) by jasper 
Branch: MAIN 
CVS Tags: HEAD 
Changes since 1.5: +1 -1 lines
FILE REMOVED

remove leiningen; the upstream script is not really intended to get packaged
anyway. 
8<

Might be worth considering before proceeding to re-add the files if the
situation has improved since 2013.

-- 
jasper

CVS: cvs.openbsd.org: ports

[Jeremie Courreges-Anglas]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/07/02 12:38:24

Modified files:
archivers/p7zip: Makefile 
archivers/p7zip/patches: patch-C_CpuArch_h 

Log message:
Detect endianness thru endian.h

Fixes build on at least mips64el, and might fix a problem on powerpc.
>From Donovan Watteau, ok Josh Grosse (maintainer) bcallah@

CVS: cvs.openbsd.org: ports

[Jeremie Courreges-Anglas]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/07/02 12:26:56

Added files:
sysutils/pftop/patches: patch-Makefile 

Log message:
Use BUILDFIRST for yacc-produced files

Re: UPDATE: php revamp

[Robert Nagy]

Hi

Antoine, can you please push this into a bulk?

On (2017-07-02 19:52), Martijn van Duren wrote:
> Hello ports@,
> 
> Last couple of months I've been busy getting to know the OpenBSD ports 
> system and the php build environment.
> The main reason being my need for functionality at my $DAYJOB which 
> isn't offered by the default php install on OpenBSD. Most notably php 
> 7.1 and chroot (the php function).
> 
> During my quest I ended up touching about every part of the port and 
> I'm currently quite happy with the result, although there's still some 
> things I want to touch later on.
> 
> Some of the highlights I've done:
> - Remove PHP 5.5. It's dead upstream for almost a year, so there's no 
> need to keep it on OpenBSD.
> - Clean up the CONFIGURE_ARGS. There were some arguments there that 
> were simply not in PHP anymore.
> - Move some deprecated modules into the PHP 5.6 Makefile. This keeps 
> the Makefile.inc cleaner of if/else bloat.
> - Replace the -fastcgi port with -cgi. -cgi is the official name and 
> for fastcgi needs -fpm is recommended. This avoids confusion.
> - Move modules to their own subpackage where possible. I don't like my 
> clean php install having ftp or wddx. Let people make up their own mind.
> - Remove unused dependencies (e.g. mariadb isn't needed when building 
> with mysqlnd)
> - Move every SAPI to their own subpackage. People running -fpm don't 
> need mod_php or -cgi.
> - Move the extension headers to their corresponding subpackage.
> - Clean up the build environment. YACC=, USE_LIBTOOL, etc don't seem to 
> be needed (anymore).
> - Clean up patches. Some are unneeded, redundant, superfluous so keep 
> it to a minimum for maintainability.
> - Subpackages requiring another module have those dependencies. (e.g. 
> installing -pdo_mysql also pulls in -pdo and -mysqlnd)
> - Install phar and disable it on sparc64. This should allow us to have 
> php on sparc64, without phar support. Untested for lack of hardware.
> - Enable the chroot function by default. This function normally gets 
> disabled if any SAPI other than -cli, -cgi, or -embed is compiled.
> I reckon that if the chroot function is usable the code is running as 
> root and you have bigger problems than a php server locking itself out 
> of your main filesystem.
> - Allow phpize to work without --with-php-config.
> - Try to rely on other packages where code would be otherwise compiled 
> in. E.g. devel/pcre for the pcre module and textproc/oniguruma for 
> mbstring. These libraries are also packaged inside PHP if not available
> on the main system.
> - Miscellaneous cleanup
> 
> For the packages this means the following:
> Removed:
> - php-fastcgi
> Added:
> - php-apxs2
> - php-bcmath
> - php-calendar
> - php-cgi
> - php-cli
> - php-ctype
> - php-dom
> - php-enchant
> - php-exif
> - php-fileinfo
> - php-fpm
> - php-ftp
> - php-gettext
> - php-iconv
> - php-json
> - php-mbstring
> - php-mysqlnd
> - php-opcache
> - php-pdo
> - php-pdo_sqlite
> - php-phar
> - php-posix
> - php-readline
> - php-simplexml
> - php-sockets
> - php-sqlite3
> - php-sysvmsg
> - php-sysvsem
> - php-sysvshm
> - php-tokenizer
> - php-wddx
> - php-xmlreader
> - php-xmlwriter
> Modules moved to shared components:
> - bcmath
> - calendar
> - ctype
> - dom
> - exif
> - fileinfo
> - ftp
> - gettext
> - iconv
> - json
> - mbstring
> - mysqlnd
> - PDO
> - pdo_sqlite
> - Phar
> - posix
> - readline
> - SimpleXML
> - sockets
> - sqlite3
> - sysvmsg
> - sysvsem
> - sysvshm
> - tokenizer
> - wddx
> - xmlreader
> - xmlwriter
> Modules kept compiled in:
> - Core (for obvious reasons)
> - date (can't be build stand-alone)
> - ereg (removed in php 7.0, not worth the effort, also pcre is in 
> default install)
> - filter (can't be build stand-alone)
> - hash (required to be built-in for phar hash-checking)
> - libxml (can't be build stand-alone)
> - openssl (allow tls as a Stream Socket Transport in a default install)
> - pcre (can't be build stand-alone)
> - Reflection (can't be build stand-alone)
> - session (what's a webserver without sessions?)
> - SPL (can't be build stand-alone)
> - standard (for obvious reasons)
> - xml (required for pear building. Should be turned into a module once 
> something like phpctl is in place)
> - zlib (required for phar)
> 
> When updating to the new packages I didn't encounter any problems, 
> except for the expected behaviour that some modules or SAPIs are now in 
> other packages, which could easily be covered with a current.html entry.
> 
> Some things that I would like to realize once this gets accepted are:
> - Allow easier module manipulation via an external tool. E.g. 
> "phpctl-5.6 enable pdo_mysql", or "phpctl-5.6 list | phpctl-7.1 load".
> I'm not sure of the semantics and haven't started on this yet. But it
> would solve some issues, like migration or automatic module enabling
> during package building (-xml).
> - Allow pecl modules to be built with multiple PHP versions. Right now 
> all pecl modules are 

UPDATE: php revamp

[Martijn van Duren]

Hello ports@,

Last couple of months I've been busy getting to know the OpenBSD ports 
system and the php build environment.
The main reason being my need for functionality at my $DAYJOB which 
isn't offered by the default php install on OpenBSD. Most notably php 
7.1 and chroot (the php function).

During my quest I ended up touching about every part of the port and 
I'm currently quite happy with the result, although there's still some 
things I want to touch later on.

Some of the highlights I've done:
- Remove PHP 5.5. It's dead upstream for almost a year, so there's no 
need to keep it on OpenBSD.
- Clean up the CONFIGURE_ARGS. There were some arguments there that 
were simply not in PHP anymore.
- Move some deprecated modules into the PHP 5.6 Makefile. This keeps 
the Makefile.inc cleaner of if/else bloat.
- Replace the -fastcgi port with -cgi. -cgi is the official name and 
for fastcgi needs -fpm is recommended. This avoids confusion.
- Move modules to their own subpackage where possible. I don't like my 
clean php install having ftp or wddx. Let people make up their own mind.
- Remove unused dependencies (e.g. mariadb isn't needed when building 
with mysqlnd)
- Move every SAPI to their own subpackage. People running -fpm don't 
need mod_php or -cgi.
- Move the extension headers to their corresponding subpackage.
- Clean up the build environment. YACC=, USE_LIBTOOL, etc don't seem to 
be needed (anymore).
- Clean up patches. Some are unneeded, redundant, superfluous so keep 
it to a minimum for maintainability.
- Subpackages requiring another module have those dependencies. (e.g. 
installing -pdo_mysql also pulls in -pdo and -mysqlnd)
- Install phar and disable it on sparc64. This should allow us to have 
php on sparc64, without phar support. Untested for lack of hardware.
- Enable the chroot function by default. This function normally gets 
disabled if any SAPI other than -cli, -cgi, or -embed is compiled.
I reckon that if the chroot function is usable the code is running as 
root and you have bigger problems than a php server locking itself out 
of your main filesystem.
- Allow phpize to work without --with-php-config.
- Try to rely on other packages where code would be otherwise compiled 
in. E.g. devel/pcre for the pcre module and textproc/oniguruma for 
mbstring. These libraries are also packaged inside PHP if not available
on the main system.
- Miscellaneous cleanup

For the packages this means the following:
Removed:
- php-fastcgi
Added:
- php-apxs2
- php-bcmath
- php-calendar
- php-cgi
- php-cli
- php-ctype
- php-dom
- php-enchant
- php-exif
- php-fileinfo
- php-fpm
- php-ftp
- php-gettext
- php-iconv
- php-json
- php-mbstring
- php-mysqlnd
- php-opcache
- php-pdo
- php-pdo_sqlite
- php-phar
- php-posix
- php-readline
- php-simplexml
- php-sockets
- php-sqlite3
- php-sysvmsg
- php-sysvsem
- php-sysvshm
- php-tokenizer
- php-wddx
- php-xmlreader
- php-xmlwriter
Modules moved to shared components:
- bcmath
- calendar
- ctype
- dom
- exif
- fileinfo
- ftp
- gettext
- iconv
- json
- mbstring
- mysqlnd
- PDO
- pdo_sqlite
- Phar
- posix
- readline
- SimpleXML
- sockets
- sqlite3
- sysvmsg
- sysvsem
- sysvshm
- tokenizer
- wddx
- xmlreader
- xmlwriter
Modules kept compiled in:
- Core (for obvious reasons)
- date (can't be build stand-alone)
- ereg (removed in php 7.0, not worth the effort, also pcre is in 
default install)
- filter (can't be build stand-alone)
- hash (required to be built-in for phar hash-checking)
- libxml (can't be build stand-alone)
- openssl (allow tls as a Stream Socket Transport in a default install)
- pcre (can't be build stand-alone)
- Reflection (can't be build stand-alone)
- session (what's a webserver without sessions?)
- SPL (can't be build stand-alone)
- standard (for obvious reasons)
- xml (required for pear building. Should be turned into a module once 
something like phpctl is in place)
- zlib (required for phar)

When updating to the new packages I didn't encounter any problems, 
except for the expected behaviour that some modules or SAPIs are now in 
other packages, which could easily be covered with a current.html entry.

Some things that I would like to realize once this gets accepted are:
- Allow easier module manipulation via an external tool. E.g. 
"phpctl-5.6 enable pdo_mysql", or "phpctl-5.6 list | phpctl-7.1 load".
I'm not sure of the semantics and haven't started on this yet. But it
would solve some issues, like migration or automatic module enabling
during package building (-xml).
- Allow pecl modules to be built with multiple PHP versions. Right now 
all pecl modules are only available for 5.6, but I could use some of 
those on my 7.1 install, which I now have to built custom with my 
revamped phpize, which is not ideal.

The new layout requires a few tweaks in the pecl and pear department, 
but nothing too fancy. See patch down below.

Also, arguments can be made to move some packages back together. E.g. 
-cli into -main. I'm not against it, but it 

Re: [PATCH] Fix archivers/p7zip endianness detection

[Josh Grosse]

On Sun, Jul 02, 2017 at 05:46:07PM +0200, Jeremie Courreges-Anglas wrote:

> I'd like to commit this.

$MAINTAINER OK, for what that is worth.

Re: NEW: x11/xcape

[Ingo Schwarze]

Hi Edd,

Edd Barrett wrote on Sun, Jul 02, 2017 at 05:00:21PM +0100:
> On Sun, Jul 02, 2017 at 04:38:49PM +0100, Edd Barrett wrote:

>> Fix up the above and send a new tarball and I will see if we can put
>> this in for you :)

> Oh, and if I were nitpicking:
> 
> $ mandoc -Tlint /usr/local/man/man1/xcape.1 
> mandoc: /usr/local/man/man1/xcape.1:31:57: WARNING: whitespace at end of 
> input line

That one is actually among the most common WARNINGs you will see
in the ports tree.  Off the top of my head, i'd estimate that the
majority of ports throws that one.  And even in in /usr/src/gnu,
there are almost a thousand of them.

It is not a false positive, though:  In base system pages that we
maintain ourselves, we do fix that.

> But unless it breaks rendering, I wouldn't worry.

I'm not aware of any way how that one could break rendering,
so you certainly don't need to worry.

There is one very exotic case where trailing whitespace is syntactically
significant in the roff(7) language: at the end of .if and .ie request
lines that neither contain controlled content nor \{ nor a trailing
line continuation backslash.  But those are flagged differently:

  WARNING: conditional request controls empty scope: if

There may be a few other case like a after trailing \c, but they are
even more arcane, and if they ever cause trouble in practice, they
should get a different message.

So i should probably downgrade

  WARNING: whitespace at end of input line

to STYLE.

Yours,
  Ingo

Re: NEW: devel/leiningen

[Ingo Schwarze]

Hi Edd,

Edd Barrett wrote on Sun, Jul 02, 2017 at 05:12:15PM +0100:

>  * mandoc linter is unhappy with the man page:
> 
>$ mandoc -Tlint /usr/local/man/man1/lein.1 
>mandoc: /usr/local/man/man1/lein.1:2:17: WARNING: cannot parse date, using 
> it verbatim: 2011 June 30
> 
>Consider pathcing?

No, most definitely not!

Do not patch ports manuals except to prevent very badly broken
formatting or serious information loss, and even in those cases,
only if the problem also occurs with groff.

In the very unusual case that a mere WARNING from mandoc causes
unintelligible rendering or information loss, that's a bug in mandoc,
and then we want to patch mandoc to either format properly or at
least issue an ERROR rather than a WARNING, before even considering
to patch the port.

In this case, the string renders as "2011 June 30" (as the message
says), and that is perfectly understandable for humans.  Now that
we have the STYLE message level, i will probably downgrade this
particular message from WARNING to STYLE soon.

In the base system, we have unusually high standards for code
cleanness (because that helps developers when doing maintenance)
und uniformity of presentation (because that helps users).  So in
the base system, the number of WARNINGs is low and we try to fix
as many of them as is reasonable.  But in non-OpenBSD software, you
will have a hard time to find *anything* that does not trigger at
least a few WARNINGs.

For routine checking of a port, unless you are planning to help
upstream to get their manuals up to OpenBSD base system quality
standards, it is completely sufficient to run

  mandoc -Tlint -Werror

Even if a ports page throws ERRORs, that usually doesn't require
patching the port, but in that case, it is useful to check that
none of the ERRORs cause broken formatting or information loss.
While all ERRORs carry a potential risk of causing such damage, in
practice, only a minority of them actually does cause such damage.
If you find that kind of damage, then helping upstream to get it
fixed is definitely useful.

For more information, see

  https://www.openbsd.org/faq/ports/specialtopics.html#Mandoc

Yours,
  Ingo

CVS: cvs.openbsd.org: ports

[Robert Nagy]

CVSROOT:/cvs
Module name:ports
Changes by: rob...@cvs.openbsd.org  2017/07/02 10:47:46

Modified files:
www/nginx  : Makefile distinfo 

Log message:
update to 1.12.0

Re: www/linkchecker refusing to start

[Jeremie Courreges-Anglas]

mrsatte...@mrsatterly.com writes:

> I am using
> OpenBSD 6.1-current (GENERIC.MP) #64: Wed Jun 28 12:27:46 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> www/linkchecker refuses to start and gives a wrong version error for
> py-requests.
>
> $ linkchecker
> This program requires Python requests 2.2.0 or later.
>
> Using pkg_info on py-requests shows it is above 2.2.0.
>
> $ pkg_info py-requests
> Information for inst:py-requests-2.14.2
> ...
> Required by:
> linkchecker-9.3p1
> ...
>
> All of the bug reports about the problem point to this link.
> https://github.com/wummel/linkchecker/issues/649
>
> It looks like a fix was posted here.
> https://github.com/wummel/linkchecker/commit/c2ce810c3fb00b895a841a7be6b2e78c64e7b042
>
> Comments in the commit and bug threads still show people having
> problems.

Yet upstream's commit fixes the issue here, so I've applied it as
a patch.

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

CVS: cvs.openbsd.org: ports

[Jeremie Courreges-Anglas]

CVSROOT:/cvs
Module name:ports
Changes by: j...@cvs.openbsd.org2017/07/02 10:18:44

Modified files:
www/linkchecker: Makefile 
Added files:
www/linkchecker/patches: patch-linkcheck___init___py 

Log message:
Fix requests version detection

Reported by MrSatterly, fix from upstream.

Re: NEW: devel/leiningen

[Edd Barrett]

Hi Jon,

On Thu, Jun 29, 2017 at 10:38:32AM -0400, Jon Bernard wrote:
> Attached is a port of leiningen, for automating clojure projects.

Comments:

 * There's a hard-coded path to bash in a patch. You will need to use a
   variable (LOCALBASE) in place of /usr/local and then use
   ${SUBST_CMD} in a custom make target, maybe post-install.

 * Did you try that script with /bin/sh? If it works that would be
   preferable. Otherwise, bash needs to be a RUN_DEPEND.

 * mandoc linter is unhappy with the man page:

   $ mandoc -Tlint /usr/local/man/man1/lein.1 
   mandoc: /usr/local/man/man1/lein.1:2:17: WARNING: cannot parse date, using 
it verbatim: 2011 June 30

   Consider pathcing?

 * I was surprised to see that your port did not RUN_DEPEND on clojure.
   I see that upon first `lein repl` the tool will download a clojure
   using (the horror) maven (which must be bundled?). I *think*, but
   other porters can correct me, we would prefer to use the in-tree
   clojure instead of a moving target. Is this possible?

 * Even if I let it do its thing, the repl doesn't seem to work:

---8<---
$ lein repl 
Retrieving org/clojure/clojure/1.8.0/clojure-1.8.0.pom from central
Retrieving org/sonatype/oss/oss-parent/7/oss-parent-7.pom from central
Retrieving org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.pom from 
central
Retrieving org/clojure/pom.contrib/0.1.2/pom.contrib-0.1.2.pom from central
Retrieving 
clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.pom from clojars
Retrieving org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar from 
central
Retrieving org/clojure/clojure/1.8.0/clojure-1.8.0.jar from central
Retrieving 
clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar from clojars
REPL server launch timed out.
--->8---

I know nothing about Clojure or lein, so I'm going to CC our clojure
MAINTAINER, Jasper.

Cheers

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: NEW: x11/xcape

[Edd Barrett]

On Sun, Jul 02, 2017 at 04:38:49PM +0100, Edd Barrett wrote:
> Fix up the above and send a new tarball and I will see if we can put
> this in for you :)

Oh, and if I were nitpicking:

$ mandoc -Tlint /usr/local/man/man1/xcape.1 
mandoc: /usr/local/man/man1/xcape.1:31:57: WARNING: whitespace at end of input 
line

But unless it breaks rendering, I wouldn't worry.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: [PATCH] Fix archivers/p7zip endianness detection

[Jeremie Courreges-Anglas]

Josh Grosse  writes:

> On Sun, Jul 02, 2017 at 12:41:48PM +0200, Donovan Watteau wrote:
>> Hi,
>> 
>> archivers/p7zip currently fails to build on loongson, because of a
>> mistake in patch-C_CpuArch_h: we were implying that __mips64__ always
>> means that we're running big-endian, but that's wrong for loongson
>> (which is mips64el).
>> 
>> __MIPSEL__ and __mips64__ are both detected by CpuArch.h, so p7zip
>> tries to build thinking that it's both big- and little-endian, and
>> the build fails right at the start.
>> 
>> The following diff just patches CpuArch.h to use  instead,
>> which makes things simpler and correct.
>
> Thank you, Donovan.  I've tested on amd64, and the patch seems to be 
> working.  The built-in tests all function.  I am in the process of 
> testing on i386 and armv7 (the latter under qemu), which I should
> be able to complete later today.

make test passes on armv7.

>> I don't think REVISION needs to be bumped, because it shouldn't change
>> anything for the architectures where it didn't build (except if there
>> was an arch where we were successfully building, but with the wrong
>> endianness).
>
> I think a revision bump is needed and have attached a revise patch
> which includes one.

Bumps are cheap, when in doubt, use them.

Here, the architecture list did not include powerpc, where neither
MY_CPU_BE and MY_CPU_LE would end up defined (the build would succeed,
though).  Since p7zip contains code that depends on those macros,
a REVISION bump is due.

I'd like to commit this.

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

Re: NEW: sysutils/myrepos

[Edd Barrett]

On Mon, May 08, 2017 at 10:12:50AM -0400, Jon Bernard wrote:
> Hi ports@,
> 
> Attached is a port of myrepos from Joey Hess.

Comments:

 * COMMENT starts with a lower case letter unless the first word is a
   proper noun.

 * Author moved the project away from github, so the port no longer
   fetches. If you can't find a tarball somewhere, you might have to
   roll your own and host it.

If you can fix the latter, I will complete the review.

Thanks

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: NEW: x11/xcape

[Edd Barrett]

Hi Jon,

On Tue, May 02, 2017 at 09:51:57AM -0400, Jon Bernard wrote:
> This is my first port, I think everything is in order from what I've
> read but do let me know if I've missed or misunderstood something.

Here are a few comments:

 * You need to mark the port as not having tests (see NO_TEST).

 * You are missing a WANTLIB line. There's a make target
   'port-lib-depends-check' that can help you.

 * Funny that they have an install target which installs the manual, but
   not the binary! Doh! Might want to report that, so that in later
   versions you don't need a custom do-install target.

 * You should set a HOMEPAGE, even if it's just the GitHub landing page.

The tool seems to work. With xcape running in the default config, left
control sends escape.

Fix up the above and send a new tarball and I will see if we can put
this in for you :)

Thanks

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: [PATCH] Fix archivers/p7zip endianness detection

[Josh Grosse]

On Sun, Jul 02, 2017 at 09:32:26AM -0400, Josh Grosse wrote:
> ...I am in the process of 
> testing on i386 and armv7 (the latter under qemu), which I should
> be able to complete later today.

Testing complete on amd64, i386, and armv7.  No regressions.

Re: UPDATE: www/phantomjs

[Pavel Korovin]

On 07/02, Stuart Henderson wrote:
> On 2017/07/02 01:10, Pavel Korovin wrote:
> > Dear all,
> > 
> > Please find the update for the latest (v2.1.1) phantomjs attached.
> > Since it uses its own bundled version of qt, I used OpenBSD patches
> > for qt-5.5.1.
> > 
> > To avoid unnecessary dances with sources, I borrowed sources from
> > FreeBSD (not sure if I did it correctly with MASTER_SITE_FREEBSD = Yes),
> > but anyway, the beast compiles, tests, and runs OK. Although phantomjs
> > was abandoned by maintainer, it's still used by many projects.
> > 
> > Since the diff is quite large, I'm also attaching tgz; hopefully somebody
> > will find it useful.
> 
> Please use "COMPILER=gcc" instead of MODULES=gcc4 and the MODGCC4_* variables.
> 
> Is there any way to avoid using openssl from ports?
 
Stuart, I hope so. My first approach was very clunky, the only reason I've
sent the patch so early was the relief that it finally compiles/tests/works,
sorry for the noise.

Now checked all the deps, half of them not needed for bundled qt build, fixed
MASTER_SITES to actually download the sources, removed openssl dep,
fixed build script to keep everything clean and conformable to OpenBSD qt5
port, hopefully I'll send the fixed version today.

-- 
With best regards,
Pavel Korovin

CVS: cvs.openbsd.org: ports

[Frederic Cambus]

CVSROOT:/cvs
Module name:ports
Changes by: fcam...@cvs.openbsd.org 2017/07/02 07:45:36

Modified files:
archivers/snappy: Makefile 

Log message:
Drop maintainership, I no longer use snappy.

Re: [PATCH] Fix archivers/p7zip endianness detection

[Josh Grosse]

On Sun, Jul 02, 2017 at 12:41:48PM +0200, Donovan Watteau wrote:
> Hi,
> 
> archivers/p7zip currently fails to build on loongson, because of a
> mistake in patch-C_CpuArch_h: we were implying that __mips64__ always
> means that we're running big-endian, but that's wrong for loongson
> (which is mips64el).
> 
> __MIPSEL__ and __mips64__ are both detected by CpuArch.h, so p7zip
> tries to build thinking that it's both big- and little-endian, and
> the build fails right at the start.
> 
> The following diff just patches CpuArch.h to use  instead,
> which makes things simpler and correct.

Thank you, Donovan.  I've tested on amd64, and the patch seems to be 
working.  The built-in tests all function.  I am in the process of 
testing on i386 and armv7 (the latter under qemu), which I should
be able to complete later today.
 
> I don't think REVISION needs to be bumped, because it shouldn't change
> anything for the architectures where it didn't build (except if there
> was an arch where we were successfully building, but with the wrong
> endianness).

I think a revision bump is needed and have attached a revise patch
which includes one.

  Josh Grosse, $MAINTAINER
Index: Makefile
===
RCS file: /systems/cvs/ports/archivers/p7zip/Makefile,v
retrieving revision 1.39
diff -u -p -r1.39 Makefile
--- Makefile10 Apr 2017 11:45:22 -  1.39
+++ Makefile2 Jul 2017 12:32:47 -
@@ -4,7 +4,7 @@ COMMENT-main=   file archiver with high co
 COMMENT-rar=   rar modules for p7zip
 
 V= 16.02
-REVISION-main= 1
+REVISION-main= 2
 REVISION-rar=  0
 DISTNAME=  p7zip_${V}_src_all
 PKGNAME=   p7zip-${V}
Index: patches/patch-C_CpuArch_h
===
RCS file: /systems/cvs/ports/archivers/p7zip/patches/patch-C_CpuArch_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-C_CpuArch_h
--- patches/patch-C_CpuArch_h   10 Apr 2016 19:53:09 -  1.2
+++ patches/patch-C_CpuArch_h   2 Jul 2017 12:31:10 -
@@ -1,25 +1,52 @@
 $OpenBSD: patch-C_CpuArch_h,v 1.2 2016/04/10 19:53:09 naddy Exp $
 
-Add support for more OpenBSD architectures.
+Use  to determine endianness, instead of a complex and 
+incorrect list of architectures.
 
 C/CpuArch.h.orig   Wed Feb 17 01:27:16 2016
-+++ C/CpuArch.hSun Apr  3 19:05:55 2016
-@@ -66,6 +66,8 @@ MY_CPU_LE_UNALIGN means that CPU is LITTLE ENDIAN and 
- || defined(__MIPSEL__) \
- || defined(__MIPSEL) \
- || defined(_MIPSEL) \
-+|| defined(__alpha__) \
-+|| defined(__sh__) \
- || (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == 
__ORDER_LITTLE_ENDIAN__))
-   #define MY_CPU_LE
+Index: C/CpuArch.h
+--- C/CpuArch.h.orig
 C/CpuArch.h
+@@ -5,6 +5,7 @@
+ #define __CPU_ARCH_H
+ 
+ #include "7zTypes.h"
++#include 
+ 
+ EXTERN_C_BEGIN
+ 
+@@ -56,33 +57,9 @@ MY_CPU_LE_UNALIGN means that CPU is LITTLE ENDIAN and 
+ #define MY_CPU_IA64_LE
  #endif
-@@ -82,6 +84,9 @@ MY_CPU_LE_UNALIGN means that CPU is LITTLE ENDIAN and 
- || defined(__s390x__) \
- || defined(__zarch__) \
- || defined(__sparc) \
-+|| defined(__sparc__) \
-+|| defined(__hppa__) \
-+|| defined(__mips64__) \
- || (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__))
+ 
+-#if defined(MY_CPU_X86_OR_AMD64) \
+-|| defined(MY_CPU_ARM_LE) \
+-|| defined(MY_CPU_IA64_LE) \
+-|| defined(__LITTLE_ENDIAN__) \
+-|| defined(__ARMEL__) \
+-|| defined(__THUMBEL__) \
+-|| defined(__AARCH64EL__) \
+-|| defined(__MIPSEL__) \
+-|| defined(__MIPSEL) \
+-|| defined(_MIPSEL) \
+-|| (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == 
__ORDER_LITTLE_ENDIAN__))
++#if BYTE_ORDER == LITTLE_ENDIAN
+   #define MY_CPU_LE
+-#endif
+-
+-#if defined(__BIG_ENDIAN__) \
+-|| defined(__ARMEB__) \
+-|| defined(__THUMBEB__) \
+-|| defined(__AARCH64EB__) \
+-|| defined(__MIPSEB__) \
+-|| defined(__MIPSEB) \
+-|| defined(_MIPSEB) \
+-|| defined(__m68k__) \
+-|| defined(__s390__) \
+-|| defined(__s390x__) \
+-|| defined(__zarch__) \
+-|| defined(__sparc) \
+-|| (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__))
++#elif BYTE_ORDER == BIG_ENDIAN
#define MY_CPU_BE
  #endif
+ 

Re: UPDATE: graphics/libraw

[Jeremie Courreges-Anglas]

Rafael Sadowski  writes:

> On Sat Jul 01, 2017 at 07:26:39PM +0200, Jeremie Courreges-Anglas wrote:
>> Rafael Sadowski  writes:
>> 
>> > Update libraw 0.17.2 -> 0.18.2
>> >
>> > Tested with a few KDE applications,
>> >
>> > OK? Comments?
>> 
>> Looks fine ports-wise (including the major bump).  Did you build all
>> consumers?
>
> Of course! All consumers build fine on amd64.
>
>> 
>> Nits below,
>> 
>
> New diff below.

ok jca@

> Cheers, Rafael
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/libraw/Makefile,v
> retrieving revision 1.24
> diff -u -p -u -p -r1.24 Makefile
> --- Makefile  27 Apr 2017 23:15:00 -  1.24
> +++ Makefile  2 Jul 2017 12:39:46 -
> @@ -4,28 +4,25 @@ BROKEN-hppa =   undefined reference to __
>  
>  COMMENT =library for reading RAW files
>  
> -V =  0.17.2
> -DISTNAME =   LibRaw-${V}
> +DISTNAME =   LibRaw-0.18.2
>  PKGNAME =${DISTNAME:L}
> -REVISION =   0
>  CATEGORIES = graphics
>  
> -SHARED_LIBS +=  raw  1.0  # 15.0
> -SHARED_LIBS +=  raw_r1.0  # 15.0
> +SHARED_LIBS +=  raw  2.0  # 15.0
> +SHARED_LIBS +=  raw_r2.0  # 15.0
>  
> -HOMEPAGE =   http://www.libraw.org/
> +HOMEPAGE =   https://www.libraw.org/
>  
>  # LGPL v2.1 OR CDDL v1.0 OR their own
>  PERMIT_PACKAGE_CDROM =   Yes
>  
>  WANTLIB += c jasper jpeg lcms2 m pthread ${LIBCXX}
>  
> -MASTER_SITES =   http://www.libraw.org/data/
> +MASTER_SITES =   https://www.libraw.org/data/
>  
> -MODULES =gcc4
> +COMPILER =   gcc
>  # for atomic builtins (__sync_fetch_and_add_4)
>  MODGCC4_ARCHS =  arm
> -MODGCC4_LANGS =  c++
>  
>  LIB_DEPENDS =graphics/jasper \
>   graphics/lcms2
> Index: distinfo
> ===
> RCS file: /cvs/ports/graphics/libraw/distinfo,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 distinfo
> --- distinfo  27 Aug 2016 15:56:27 -  1.6
> +++ distinfo  2 Jul 2017 12:39:46 -
> @@ -1,2 +1,2 @@
> -SHA256 (LibRaw-0.17.2.tar.gz) = krDELHZm7Kkwfl4fl9b+/Bls8LfuCJ4iiAJZp2+v0Vw=
> -SIZE (LibRaw-0.17.2.tar.gz) = 1472714
> +SHA256 (LibRaw-0.18.2.tar.gz) = zjZrs4wRRBMHN+sW6RkDiTe03BqxZReaIl1ehHryq8Y=
> +SIZE (LibRaw-0.18.2.tar.gz) = 1281674
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/graphics/libraw/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 PLIST
> --- pkg/PLIST 22 May 2015 11:31:15 -  1.5
> +++ pkg/PLIST 2 Jul 2017 12:39:46 -
> @@ -30,4 +30,3 @@ share/doc/libraw/COPYRIGHT
>  share/doc/libraw/Changelog.txt
>  share/doc/libraw/LICENSE.CDDL
>  share/doc/libraw/LICENSE.LGPL
> -share/doc/libraw/LICENSE.LibRaw.pdf
>

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

Re: UPDATE: graphics/libraw

[Rafael Sadowski]

On Sat Jul 01, 2017 at 07:26:39PM +0200, Jeremie Courreges-Anglas wrote:
> Rafael Sadowski  writes:
> 
> > Update libraw 0.17.2 -> 0.18.2
> >
> > Tested with a few KDE applications,
> >
> > OK? Comments?
> 
> Looks fine ports-wise (including the major bump).  Did you build all
> consumers?

Of course! All consumers build fine on amd64.

> 
> Nits below,
> 

New diff below.

Cheers, Rafael

Index: Makefile
===
RCS file: /cvs/ports/graphics/libraw/Makefile,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile
--- Makefile27 Apr 2017 23:15:00 -  1.24
+++ Makefile2 Jul 2017 12:39:46 -
@@ -4,28 +4,25 @@ BROKEN-hppa = undefined reference to __
 
 COMMENT =  library for reading RAW files
 
-V =0.17.2
-DISTNAME = LibRaw-${V}
+DISTNAME = LibRaw-0.18.2
 PKGNAME =  ${DISTNAME:L}
-REVISION = 0
 CATEGORIES =   graphics
 
-SHARED_LIBS +=  raw  1.0  # 15.0
-SHARED_LIBS +=  raw_r1.0  # 15.0
+SHARED_LIBS +=  raw  2.0  # 15.0
+SHARED_LIBS +=  raw_r2.0  # 15.0
 
-HOMEPAGE = http://www.libraw.org/
+HOMEPAGE = https://www.libraw.org/
 
 # LGPL v2.1 OR CDDL v1.0 OR their own
 PERMIT_PACKAGE_CDROM = Yes
 
 WANTLIB += c jasper jpeg lcms2 m pthread ${LIBCXX}
 
-MASTER_SITES = http://www.libraw.org/data/
+MASTER_SITES = https://www.libraw.org/data/
 
-MODULES =  gcc4
+COMPILER = gcc
 # for atomic builtins (__sync_fetch_and_add_4)
 MODGCC4_ARCHS =arm
-MODGCC4_LANGS =c++
 
 LIB_DEPENDS =  graphics/jasper \
graphics/lcms2
Index: distinfo
===
RCS file: /cvs/ports/graphics/libraw/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo27 Aug 2016 15:56:27 -  1.6
+++ distinfo2 Jul 2017 12:39:46 -
@@ -1,2 +1,2 @@
-SHA256 (LibRaw-0.17.2.tar.gz) = krDELHZm7Kkwfl4fl9b+/Bls8LfuCJ4iiAJZp2+v0Vw=
-SIZE (LibRaw-0.17.2.tar.gz) = 1472714
+SHA256 (LibRaw-0.18.2.tar.gz) = zjZrs4wRRBMHN+sW6RkDiTe03BqxZReaIl1ehHryq8Y=
+SIZE (LibRaw-0.18.2.tar.gz) = 1281674
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/libraw/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 PLIST
--- pkg/PLIST   22 May 2015 11:31:15 -  1.5
+++ pkg/PLIST   2 Jul 2017 12:39:46 -
@@ -30,4 +30,3 @@ share/doc/libraw/COPYRIGHT
 share/doc/libraw/Changelog.txt
 share/doc/libraw/LICENSE.CDDL
 share/doc/libraw/LICENSE.LGPL
-share/doc/libraw/LICENSE.LibRaw.pdf

[PATCH] Fix archivers/p7zip endianness detection

[Donovan Watteau]

Hi,

archivers/p7zip currently fails to build on loongson, because of a
mistake in patch-C_CpuArch_h: we were implying that __mips64__ always
means that we're running big-endian, but that's wrong for loongson
(which is mips64el).

__MIPSEL__ and __mips64__ are both detected by CpuArch.h, so p7zip
tries to build thinking that it's both big- and little-endian, and
the build fails right at the start.

The following diff just patches CpuArch.h to use  instead,
which makes things simpler and correct.

I don't think REVISION needs to be bumped, because it shouldn't change
anything for the architectures where it didn't build (except if there
was an arch where we were successfully building, but with the wrong
endianness).

Index: patches/patch-C_CpuArch_h
===
RCS file: /cvs/ports/archivers/p7zip/patches/patch-C_CpuArch_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-C_CpuArch_h
--- patches/patch-C_CpuArch_h   10 Apr 2016 19:53:09 -  1.2
+++ patches/patch-C_CpuArch_h   2 Jul 2017 09:14:29 -
@@ -1,25 +1,52 @@
 $OpenBSD: patch-C_CpuArch_h,v 1.2 2016/04/10 19:53:09 naddy Exp $
 
-Add support for more OpenBSD architectures.
+Use  to determine endianness, instead of a complex and 
+incorrect list of architectures.
 
 C/CpuArch.h.orig   Wed Feb 17 01:27:16 2016
-+++ C/CpuArch.hSun Apr  3 19:05:55 2016
-@@ -66,6 +66,8 @@ MY_CPU_LE_UNALIGN means that CPU is LITTLE ENDIAN and 
- || defined(__MIPSEL__) \
- || defined(__MIPSEL) \
- || defined(_MIPSEL) \
-+|| defined(__alpha__) \
-+|| defined(__sh__) \
- || (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == 
__ORDER_LITTLE_ENDIAN__))
-   #define MY_CPU_LE
+Index: C/CpuArch.h
+--- C/CpuArch.h.orig
 C/CpuArch.h
+@@ -5,6 +5,7 @@
+ #define __CPU_ARCH_H
+ 
+ #include "7zTypes.h"
++#include 
+ 
+ EXTERN_C_BEGIN
+ 
+@@ -56,33 +57,9 @@ MY_CPU_LE_UNALIGN means that CPU is LITTLE ENDIAN and 
+ #define MY_CPU_IA64_LE
  #endif
-@@ -82,6 +84,9 @@ MY_CPU_LE_UNALIGN means that CPU is LITTLE ENDIAN and 
- || defined(__s390x__) \
- || defined(__zarch__) \
- || defined(__sparc) \
-+|| defined(__sparc__) \
-+|| defined(__hppa__) \
-+|| defined(__mips64__) \
- || (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__))
+ 
+-#if defined(MY_CPU_X86_OR_AMD64) \
+-|| defined(MY_CPU_ARM_LE) \
+-|| defined(MY_CPU_IA64_LE) \
+-|| defined(__LITTLE_ENDIAN__) \
+-|| defined(__ARMEL__) \
+-|| defined(__THUMBEL__) \
+-|| defined(__AARCH64EL__) \
+-|| defined(__MIPSEL__) \
+-|| defined(__MIPSEL) \
+-|| defined(_MIPSEL) \
+-|| (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == 
__ORDER_LITTLE_ENDIAN__))
++#if BYTE_ORDER == LITTLE_ENDIAN
+   #define MY_CPU_LE
+-#endif
+-
+-#if defined(__BIG_ENDIAN__) \
+-|| defined(__ARMEB__) \
+-|| defined(__THUMBEB__) \
+-|| defined(__AARCH64EB__) \
+-|| defined(__MIPSEB__) \
+-|| defined(__MIPSEB) \
+-|| defined(_MIPSEB) \
+-|| defined(__m68k__) \
+-|| defined(__s390__) \
+-|| defined(__s390x__) \
+-|| defined(__zarch__) \
+-|| defined(__sparc) \
+-|| (defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__))
++#elif BYTE_ORDER == BIG_ENDIAN
#define MY_CPU_BE
  #endif
+ 

security/opendnssec: 1.4.14

[Patrik Lundin]

Hello,

Below is an update of security/opendnssec to 1.4.14.
>From https://www.opendnssec.org/:
===
Bugs Fixed
* OPENDNSSEC-888: Fix up MySQL<->SQLite3 database conversion script.
* OPENDNSSEC-752: Incorrect calculated number of KSKs needed when KSK and
  ZSK have exactly the same parameters. This would prevent KSK rollovers.
* OPENDNSSEC-890: Bogus signatures on mismatching TTLs within the same 
RRset.
===

-- 
Patrik Lundin

Index: Makefile
===
RCS file: /cvs/ports/security/opendnssec/Makefile,v
retrieving revision 1.10
diff -u -p -u -r1.10 Makefile
--- Makefile10 Apr 2017 11:46:33 -  1.10
+++ Makefile2 Jul 2017 09:54:33 -
@@ -2,7 +2,7 @@
 
 COMMENT=   open-source turn-key solution for DNSSEC
 
-DISTNAME=  opendnssec-1.4.13
+DISTNAME=  opendnssec-1.4.14
 
 CATEGORIES=security
 
Index: distinfo
===
RCS file: /cvs/ports/security/opendnssec/distinfo,v
retrieving revision 1.5
diff -u -p -u -r1.5 distinfo
--- distinfo17 Mar 2017 21:12:11 -  1.5
+++ distinfo2 Jul 2017 09:54:33 -
@@ -1,2 +1,2 @@
-SHA256 (opendnssec-1.4.13.tar.gz) = 
zhRv9e6u/cgdsQ6GeIJbMOzAQQADvacGiCG/jo2PTR8=
-SIZE (opendnssec-1.4.13.tar.gz) = 1067262
+SHA256 (opendnssec-1.4.14.tar.gz) = 
4cQexbxhdiM7LZT09PcD51h7rmdgdkqxvvA88QvR3N8=
+SIZE (opendnssec-1.4.14.tar.gz) = 1037188

SECURITY UPDATE: www/kibana 5.4.2 => 5.4.3

[Pavel Korovin]

Dear all,

Please find the update for the latest www/kibana attached.

Announce: https://www.elastic.co/blog/kibana-5-4-3-released

Release Notes:
https://www.elastic.co/guide/en/kibana/current/release-notes-5.4.3.html

-- 
With best regards,
Pavel Korovin
Index: Makefile
===
RCS file: /cvs/ports/www/kibana/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile24 Jun 2017 11:22:19 -  1.16
+++ Makefile2 Jul 2017 09:07:59 -
@@ -2,7 +2,7 @@
 
 COMMENT=   browser based analytics/search interface to ElasticSearch
 
-V= 5.4.2
+V= 5.4.3
 PKGNAME=   kibana-${V}
 DISTNAME=  ${PKGNAME}-darwin-x86_64
 
Index: distinfo
===
RCS file: /cvs/ports/www/kibana/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo24 Jun 2017 11:22:19 -  1.14
+++ distinfo2 Jul 2017 09:07:59 -
@@ -1,2 +1,2 @@
-SHA256 (kibana-5.4.2-darwin-x86_64.tar.gz) = 
tJ0PTEDdnLfwBugZIJ1hrWmLNTd+vDp0QQbFE3EaPKY=
-SIZE (kibana-5.4.2-darwin-x86_64.tar.gz) = 51531040
+SHA256 (kibana-5.4.3-darwin-x86_64.tar.gz) = 
1Fvmricoq99SMzDobZIbrwBCtyyTxHjgWQy3LKyfmYU=
+SIZE (kibana-5.4.3-darwin-x86_64.tar.gz) = 51595379
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/kibana/pkg/PLIST,v
retrieving revision 1.14
diff -u -p -r1.14 PLIST
--- pkg/PLIST   24 Jun 2017 11:22:19 -  1.14
+++ pkg/PLIST   2 Jul 2017 09:08:02 -
@@ -27746,6 +27746,7 @@ kibana/node_modules/caniuse-db/features-
 kibana/node_modules/caniuse-db/features-json/getrandomvalues.json
 kibana/node_modules/caniuse-db/features-json/hardwareconcurrency.json
 kibana/node_modules/caniuse-db/features-json/hashchange.json
+kibana/node_modules/caniuse-db/features-json/heif.json
 kibana/node_modules/caniuse-db/features-json/hevc.json
 kibana/node_modules/caniuse-db/features-json/hidden.json
 kibana/node_modules/caniuse-db/features-json/high-resolution-time.json
@@ -32500,6 +32501,7 @@ kibana/node_modules/fbjs/node_modules/pr
 kibana/node_modules/fbjs/node_modules/promise/domains/node-extensions.js
 kibana/node_modules/fbjs/node_modules/promise/domains/rejection-tracking.js
 kibana/node_modules/fbjs/node_modules/promise/domains/synchronous.js
+kibana/node_modules/fbjs/node_modules/promise/index.d.ts
 kibana/node_modules/fbjs/node_modules/promise/index.js
 kibana/node_modules/fbjs/node_modules/promise/lib/
 kibana/node_modules/fbjs/node_modules/promise/lib/core.js
@@ -39520,6 +39522,7 @@ kibana/node_modules/prop-types/node_modu
 kibana/node_modules/prop-types/node_modules/promise/domains/node-extensions.js
 
kibana/node_modules/prop-types/node_modules/promise/domains/rejection-tracking.js
 kibana/node_modules/prop-types/node_modules/promise/domains/synchronous.js
+kibana/node_modules/prop-types/node_modules/promise/index.d.ts
 kibana/node_modules/prop-types/node_modules/promise/index.js
 kibana/node_modules/prop-types/node_modules/promise/lib/
 kibana/node_modules/prop-types/node_modules/promise/lib/core.js
@@ -41110,6 +41113,7 @@ kibana/node_modules/react-addons-shallow
 
kibana/node_modules/react-addons-shallow-compare/node_modules/promise/domains/node-extensions.js
 
kibana/node_modules/react-addons-shallow-compare/node_modules/promise/domains/rejection-tracking.js
 
kibana/node_modules/react-addons-shallow-compare/node_modules/promise/domains/synchronous.js
+kibana/node_modules/react-addons-shallow-compare/node_modules/promise/index.d.ts
 kibana/node_modules/react-addons-shallow-compare/node_modules/promise/index.js
 kibana/node_modules/react-addons-shallow-compare/node_modules/promise/lib/
 
kibana/node_modules/react-addons-shallow-compare/node_modules/promise/lib/core.js
@@ -42297,6 +42301,7 @@ kibana/node_modules/react-addons-test-ut
 
kibana/node_modules/react-addons-test-utils/node_modules/promise/domains/node-extensions.js
 
kibana/node_modules/react-addons-test-utils/node_modules/promise/domains/rejection-tracking.js
 
kibana/node_modules/react-addons-test-utils/node_modules/promise/domains/synchronous.js
+kibana/node_modules/react-addons-test-utils/node_modules/promise/index.d.ts
 kibana/node_modules/react-addons-test-utils/node_modules/promise/index.js
 kibana/node_modules/react-addons-test-utils/node_modules/promise/lib/
 kibana/node_modules/react-addons-test-utils/node_modules/promise/lib/core.js
@@ -44938,6 +44943,7 @@ kibana/node_modules/react-dom/node_modul
 kibana/node_modules/react-dom/node_modules/promise/domains/node-extensions.js
 
kibana/node_modules/react-dom/node_modules/promise/domains/rejection-tracking.js
 kibana/node_modules/react-dom/node_modules/promise/domains/synchronous.js
+kibana/node_modules/react-dom/node_modules/promise/index.d.ts
 kibana/node_modules/react-dom/node_modules/promise/index.js
 kibana/node_modules/react-dom/node_modules/promise/lib/
 

www/linkchecker refusing to start

[MrSatterly]

I am using
OpenBSD 6.1-current (GENERIC.MP) #64: Wed Jun 28 12:27:46 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

www/linkchecker refuses to start and gives a wrong version error for
py-requests.

$ linkchecker
This program requires Python requests 2.2.0 or later.

Using pkg_info on py-requests shows it is above 2.2.0.

$ pkg_info py-requests
Information for inst:py-requests-2.14.2
...
Required by:
linkchecker-9.3p1
...

All of the bug reports about the problem point to this link.
https://github.com/wummel/linkchecker/issues/649

It looks like a fix was posted here.
https://github.com/wummel/linkchecker/commit/c2ce810c3fb00b895a841a7be6b2e78c64e7b042

Comments in the commit and bug threads still show people having
problems.

Re: UPDATE: www/phantomjs

[Stuart Henderson]

On 2017/07/02 01:10, Pavel Korovin wrote:
> Dear all,
> 
> Please find the update for the latest (v2.1.1) phantomjs attached.
> Since it uses its own bundled version of qt, I used OpenBSD patches
> for qt-5.5.1.
> 
> To avoid unnecessary dances with sources, I borrowed sources from
> FreeBSD (not sure if I did it correctly with MASTER_SITE_FREEBSD = Yes),
> but anyway, the beast compiles, tests, and runs OK. Although phantomjs
> was abandoned by maintainer, it's still used by many projects.
> 
> Since the diff is quite large, I'm also attaching tgz; hopefully somebody
> will find it useful.

Please use "COMPILER=gcc" instead of MODULES=gcc4 and the MODGCC4_* variables.

Is there any way to avoid using openssl from ports?

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2017/07/02 02:23:59

Modified files:
editors/texworks: Makefile 

Log message:
bump REVISIONs for texworks - it seems that it did package ok in
some cases but not others, reported by naddy@ aja@.

i386 builds were seeing this before the dep changes in my last
commit to this file:

===>  Building package for texworks-0.4.4p0v0
Create /mnt/packages/i386/all/texworks-0.4.4p0v0.tgz
LIB_DEPENDS x11/dbus not needed for editors/texworks,-main ?
Missing library for estdc++>=17.0

UPDATE: SQLmap-1.1.7

[Gonzalo L. Rodriguez]

Hello,


Update for SQLMap to 1.1.7:

https://github.com/sqlmapproject/sqlmap

Ok? Comments?

Cheers.-

-- 
Sending from my toaster.
Index: Makefile
===
RCS file: /cvs/ports/security/sqlmap/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile9 Mar 2017 13:26:37 -   1.5
+++ Makefile2 Jul 2017 06:34:50 -
@@ -4,7 +4,7 @@ COMMENT =   penetration testing tool to d
 
 GH_ACCOUNT =   sqlmapproject
 GH_PROJECT =   sqlmap
-GH_TAGNAME =   1.1.2
+GH_TAGNAME =   1.1.7
 
 CATEGORIES =   security
 
Index: distinfo
===
RCS file: /cvs/ports/security/sqlmap/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo9 Mar 2017 13:26:37 -   1.3
+++ distinfo2 Jul 2017 06:34:50 -
@@ -1,2 +1,2 @@
-SHA256 (sqlmap-1.1.2.tar.gz) = mKccj5rkVxhRYwlkedX/LpOsiDMTa+X3BF1c88MDzlc=
-SIZE (sqlmap-1.1.2.tar.gz) = 6740345
+SHA256 (sqlmap-1.1.7.tar.gz) = D41ZQqlldVYjdboHy8ePt9Z9PQfvk45dq+/IIF5EC7E=
+SIZE (sqlmap-1.1.7.tar.gz) = 7402587
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/sqlmap/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST   9 Mar 2017 13:26:37 -   1.4
+++ pkg/PLIST   2 Jul 2017 06:34:51 -
@@ -39,14 +39,15 @@ share/sqlmap/extra/mssqlsig/update.py
 share/sqlmap/extra/mssqlsig/update.pyc
 share/sqlmap/extra/runcmd/
 share/sqlmap/extra/runcmd/README.txt
-share/sqlmap/extra/runcmd/windows/
-share/sqlmap/extra/runcmd/windows/README.txt
-share/sqlmap/extra/runcmd/windows/runcmd/
-share/sqlmap/extra/runcmd/windows/runcmd.sln
-share/sqlmap/extra/runcmd/windows/runcmd/runcmd.cpp
-share/sqlmap/extra/runcmd/windows/runcmd/runcmd.vcproj
-share/sqlmap/extra/runcmd/windows/runcmd/stdafx.cpp
-share/sqlmap/extra/runcmd/windows/runcmd/stdafx.h
+share/sqlmap/extra/runcmd/runcmd.exe_
+share/sqlmap/extra/runcmd/src/
+share/sqlmap/extra/runcmd/src/README.txt
+share/sqlmap/extra/runcmd/src/runcmd/
+share/sqlmap/extra/runcmd/src/runcmd.sln
+share/sqlmap/extra/runcmd/src/runcmd/runcmd.cpp
+share/sqlmap/extra/runcmd/src/runcmd/runcmd.vcproj
+share/sqlmap/extra/runcmd/src/runcmd/stdafx.cpp
+share/sqlmap/extra/runcmd/src/runcmd/stdafx.h
 share/sqlmap/extra/safe2bin/
 share/sqlmap/extra/safe2bin/README.txt
 share/sqlmap/extra/safe2bin/__init__.py
@@ -67,6 +68,7 @@ share/sqlmap/extra/shutils/duplicates.py
 share/sqlmap/extra/shutils/pep8.sh
 share/sqlmap/extra/shutils/postcommit-hook.sh
 share/sqlmap/extra/shutils/precommit-hook.sh
+share/sqlmap/extra/shutils/pydiatra.sh
 share/sqlmap/extra/shutils/pyflakes.sh
 share/sqlmap/extra/shutils/pylint.py
 share/sqlmap/extra/shutils/pylint.pyc
@@ -227,11 +229,6 @@ share/sqlmap/lib/techniques/blind/__init
 share/sqlmap/lib/techniques/blind/__init__.pyc
 share/sqlmap/lib/techniques/blind/inference.py
 share/sqlmap/lib/techniques/blind/inference.pyc
-share/sqlmap/lib/techniques/brute/
-share/sqlmap/lib/techniques/brute/__init__.py
-share/sqlmap/lib/techniques/brute/__init__.pyc
-share/sqlmap/lib/techniques/brute/use.py
-share/sqlmap/lib/techniques/brute/use.pyc
 share/sqlmap/lib/techniques/dns/
 share/sqlmap/lib/techniques/dns/__init__.py
 share/sqlmap/lib/techniques/dns/__init__.pyc
@@ -256,6 +253,8 @@ share/sqlmap/lib/utils/__init__.py
 share/sqlmap/lib/utils/__init__.pyc
 share/sqlmap/lib/utils/api.py
 share/sqlmap/lib/utils/api.pyc
+share/sqlmap/lib/utils/brute.py
+share/sqlmap/lib/utils/brute.pyc
 share/sqlmap/lib/utils/crawler.py
 share/sqlmap/lib/utils/crawler.pyc
 share/sqlmap/lib/utils/deps.py
@@ -521,7 +520,6 @@ share/sqlmap/shell/backdoor.asp_
 share/sqlmap/shell/backdoor.aspx_
 share/sqlmap/shell/backdoor.jsp_
 share/sqlmap/shell/backdoor.php_
-share/sqlmap/shell/runcmd.exe_
 share/sqlmap/shell/stager.asp_
 share/sqlmap/shell/stager.aspx_
 share/sqlmap/shell/stager.jsp_
@@ -556,6 +554,8 @@ share/sqlmap/tamper/commalesslimit.py
 share/sqlmap/tamper/commalesslimit.pyc
 share/sqlmap/tamper/commalessmid.py
 share/sqlmap/tamper/commalessmid.pyc
+share/sqlmap/tamper/commentbeforeparentheses.py
+share/sqlmap/tamper/commentbeforeparentheses.pyc
 share/sqlmap/tamper/concat2concatws.py
 share/sqlmap/tamper/concat2concatws.pyc
 share/sqlmap/tamper/equaltolike.py
@@ -588,6 +588,8 @@ share/sqlmap/tamper/percentage.py
 share/sqlmap/tamper/percentage.pyc
 share/sqlmap/tamper/plus2concat.py
 share/sqlmap/tamper/plus2concat.pyc
+share/sqlmap/tamper/plus2fnconcat.py
+share/sqlmap/tamper/plus2fnconcat.pyc
 share/sqlmap/tamper/randomcase.py
 share/sqlmap/tamper/randomcase.pyc
 share/sqlmap/tamper/randomcomments.py
@@ -785,11 +787,6 @@ share/sqlmap/thirdparty/oset/_abc.py
 share/sqlmap/thirdparty/oset/_abc.pyc
 share/sqlmap/thirdparty/oset/${MODPY_PYOEXTENSION}set.py
 share/sqlmap/thirdparty/oset/${MODPY_PYOEXTENSION}set.pyc
-share/sqlmap/thirdparty/pagerank/