Re: Update emulators/mednafen 0.9.48 -> 1.21.3
On 2018-08-19 10:34:51, Jeremy Evans wrote: > This upgrades mednafen to the latest released version. Initial diff > from an...@disroot.org, some changes by me. I tested most of the > emulator types, and all appear to work except SNES, which crashes for me > right after the window opens, with no useful debug output. Not sure if > that is a regression or not, or if it is due to my video card. I > generally use snes9x for SNES emulation. > > Ports-wise, the main change is that mednafen now requires SDL2. > > OKs? > I see the same crash with SNES emulation, but the old version crashed too, so that's not a regression. Sound doesn't work though. Initializing sound... Using "OpenBSD(/dev/audio*)" audio driver with SexyAL's default device selection.OpenBSD Audio Error: fd = open(id ? id : "/dev/audio", O_WRONLY) No such file or directory Error opening a sound device. [...] % ls -la /dev/audio ls: /dev/audio: No such file or directory I removed this link according to current.html which says the following: 2018/07/29 - Remove /dev/audio and /dev/audioctl The /dev/audio and /dev/audioctl symbolic links are not used anymore and can be removed: # rm /dev/audio /dev/audioctl So I had to apply the following patch to get sound. Index: src/sexyal/drivers/openbsd.cpp --- src/sexyal/drivers/openbsd.cpp.orig +++ src/sexyal/drivers/openbsd.cpp @@ -165,7 +165,7 @@ SexyAL_device* SexyALI_OpenBSD_Open(const char* id, Se AUDIO_INITPAR(&par); - OBSD_TRY(fd = open(id ? id : "/dev/audio", O_WRONLY)); + OBSD_TRY(fd = open(id ? id : "/dev/audio0", O_WRONLY)); par.bits = SAMPFORMAT_BITS(format->sampformat); par.bps = SAMPFORMAT_BYTES(format->sampformat); This got sound working for me, but I'm not sure how good of a solution it actually is. If anyone has multiple sound cards, then it would hardcode it to only work with /dev/audio0 A proper solution would probably be writing a proper sndio backend for it, but I'm not sure how much work that would actually entail. Failing that, I suppose another option would be to leave things as-is, and adding a MESSAGE telling the user to create the /dev/audio link manually. A final, and somewhat hackish solution (but still probably the best option if it could be made to work) would be to add something like the following patch (NOT WORKING IN ITS CURRENT STATE!). Index: src/sexyal/drivers/openbsd.cpp --- src/sexyal/drivers/openbsd.cpp.orig +++ src/sexyal/drivers/openbsd.cpp @@ -165,7 +165,7 @@ SexyAL_device* SexyALI_OpenBSD_Open(const char* id, Se AUDIO_INITPAR(&par); OBSD_TRY(fd = open(id ? id : "/dev/audio", O_WRONLY)); + OBSD_TRY(fd = open(id ? id : "/dev/audio0", O_WRONLY)); + OBSD_TRY(fd = open(id ? id : "/dev/audio1", O_WRONLY)); + OBSD_TRY(fd = open(id ? id : "/dev/audio2", O_WRONLY)); + OBSD_TRY(fd = open(id ? id : "/dev/audio3", O_WRONLY)); par.bits = SAMPFORMAT_BITS(format->sampformat); par.bps = SAMPFORMAT_BYTES(format->sampformat); So that it would check the /dev/audio link first, and then choose the first audio device that sucessfully opens if there's no /dev/audio link. That way, it would work for most people by choosing audio0, but could be overridden with a /dev/audio link for those who want to point it to a different device. All in all, I've lightly tested the update, and it seems to work fine for me with NES emulation at least. With my patch, audio works, as well as video, a USB gamepad, and everything else. Since you're the maintainer, I'll defer to your judgement on how to best handle the audio patching. Anyway, thanks for the update! -- Bryan
Re: [NEW] www/gumbo
Hi Frederic, Frederic Cambus writes: > Hi ports@, > > Here is a new port: www/gumbo. I get this during configure: ===> Configuring for gumbo-0.10.1 Using /usr/ports/pobj/gumbo-0.10.1/config.site (generated) + libtoolize ./autogen.sh[29]: libtoolize: not found
Re: [NEW] www/gumbo
On Mon, Aug 20, 2018 at 03:30:29AM -0600, Anthony J. Bentley wrote: > > Hi ports@, > > > > Here is a new port: www/gumbo. > > I get this during configure: > > ===> Configuring for gumbo-0.10.1 > Using /usr/ports/pobj/gumbo-0.10.1/config.site (generated) > + libtoolize > ./autogen.sh[29]: libtoolize: not found Indeed, sorry about that. Attaching a new tarball with the missing BUILD_DEPENDS on devel/libtool added. gumbo.tar.gz Description: application/tar-gz
rspamd: SEPARATE_BUILD and other nits
Builds fine in a separate directory:
$ du -sh `make show=WRKDIR`/*
12.0K /tmp/pobj/rspamd-1.7.9/bin
43.8M /tmp/pobj/rspamd-1.7.9/build-amd64
20.3M /tmp/pobj/rspamd-1.7.9/rspamd-1.7.9
Firewall adjustments for tests with PORTS_PRIVSEP so move the comment
into IS_INTERACTIVE.
While here, zap whitespace nits and sort dependencies alphabetically.
OK?
Index: Makefile
===
RCS file: /cvs/ports/mail/rspamd/Makefile,v
retrieving revision 1.55
diff -u -p -r1.55 Makefile
--- Makefile1 Aug 2018 17:11:44 - 1.55
+++ Makefile20 Aug 2018 11:12:00 -
@@ -20,20 +20,21 @@ WANTLIB += intl luajit-5.1 m magic pcre
MODULES= devel/cmake
LIB_DEPENDS= databases/sqlite3 \
- devel/libmagic \
devel/gettext \
devel/glib2 \
+ devel/libmagic \
devel/pcre \
lang/luajit \
textproc/icu4c
BUILD_DEPENDS+=devel/ragel
# /var/rspamd needs to exist for tests to run
-TEST_DEPENDS = ${FULLPKGNAME}:${FULLPKGPATH}
-TEST_DEPENDS +=databases/redis \
+TEST_DEPENDS= ${FULLPKGNAME}:${FULLPKGPATH}
+TEST_DEPENDS+= databases/redis \
+ devel/py-robotframework \
sysutils/py-psutil \
- textproc/py-demjson \
- devel/py-robotframework
+ textproc/py-demjson
+SEPARATE_BUILD=Yes
CONFIGURE_ARGS+=-DOPENBSD_BUILD=1 \
-DCMAKE_C_OPT_FLAGS="${CFLAGS}" \
-DCONFDIR="${SYSCONFDIR}/rspamd" \
@@ -45,10 +46,11 @@ CONFIGURE_ARGS+=-DOPENBSD_BUILD=1 \
-DRSPAMD_GROUP="_rspamd"
# Make sure we pick up the base libevent, never the ports one!
-CONFIGURE_ARGS += -DLIBEVENT_ROOT_DIR=/usr
-# Make sure you have no rspamd or redis instances running and note that the
-# test suite uses the network.
-#
+CONFIGURE_ARGS+= -DLIBEVENT_ROOT_DIR=/usr
+
+TEST_IS_INTERACTIVE= Make sure you have no rspamd or redis instances running
\
+ and note that the test suite uses the network.
+
# In the event of failing tests, look at log.html in ${WRKSRC}
do-test:
cd ${WRKSRC} && \
Re: rspamd: SEPARATE_BUILD and other nits
On Mon Aug 20, 2018 at 01:15:56PM +0200, Klemens Nanni wrote: > Builds fine in a separate directory: > > > +SEPARATE_BUILD= Yes rspamd is a camke port and SEPARATE_BUILD is always set by cmake.port.mk Cheers, Rafael Sadowski
Re: rspamd: SEPARATE_BUILD and other nits
On Mon, Aug 20, 2018 at 01:22:10PM +0200, Rafael Sadowski wrote:
> rspamd is a camke port and SEPARATE_BUILD is always set by cmake.port.mk
Right (not sure now why I set it in the first place).
Rest still stands.
Index: Makefile
===
RCS file: /cvs/ports/mail/rspamd/Makefile,v
retrieving revision 1.55
diff -u -p -r1.55 Makefile
--- Makefile1 Aug 2018 17:11:44 - 1.55
+++ Makefile20 Aug 2018 11:40:03 -
@@ -20,19 +20,19 @@ WANTLIB += intl luajit-5.1 m magic pcre
MODULES= devel/cmake
LIB_DEPENDS= databases/sqlite3 \
- devel/libmagic \
devel/gettext \
devel/glib2 \
+ devel/libmagic \
devel/pcre \
lang/luajit \
textproc/icu4c
BUILD_DEPENDS+=devel/ragel
# /var/rspamd needs to exist for tests to run
-TEST_DEPENDS = ${FULLPKGNAME}:${FULLPKGPATH}
-TEST_DEPENDS +=databases/redis \
+TEST_DEPENDS= ${FULLPKGNAME}:${FULLPKGPATH}
+TEST_DEPENDS+= databases/redis \
+ devel/py-robotframework \
sysutils/py-psutil \
- textproc/py-demjson \
- devel/py-robotframework
+ textproc/py-demjson
CONFIGURE_ARGS+=-DOPENBSD_BUILD=1 \
-DCMAKE_C_OPT_FLAGS="${CFLAGS}" \
@@ -45,10 +45,11 @@ CONFIGURE_ARGS+=-DOPENBSD_BUILD=1 \
-DRSPAMD_GROUP="_rspamd"
# Make sure we pick up the base libevent, never the ports one!
-CONFIGURE_ARGS += -DLIBEVENT_ROOT_DIR=/usr
-# Make sure you have no rspamd or redis instances running and note that the
-# test suite uses the network.
-#
+CONFIGURE_ARGS+= -DLIBEVENT_ROOT_DIR=/usr
+
+TEST_IS_INTERACTIVE= Make sure you have no rspamd or redis instances running
\
+ and note that the test suite uses the network.
+
# In the event of failing tests, look at log.html in ${WRKSRC}
do-test:
cd ${WRKSRC} && \
Re: update: mail/mailman
On Wed, Jul 25, 2018 at 9:29 AM Okan Demirmen wrote:
>
> On Tue 2018.07.24 at 08:42 -0400, Okan Demirmen wrote:
> > A maintenance and security update to 2.1.28, which includes a fix for
> > CVE-2018-13796. Where here, I fixed a few inconsistencies.
> >
> > OK/feedback?
>
> And of course a new release to fix a regression:
Almost forgot about this; been running with the below since.
port-specific feedback welcome as well :)
>
> Index: Makefile
> ===
> RCS file: /home/open/cvs/ports/mail/mailman/Makefile,v
> retrieving revision 1.89
> diff -u -p -r1.89 Makefile
> --- Makefile5 Feb 2018 21:38:44 - 1.89
> +++ Makefile25 Jul 2018 11:43:37 -
> @@ -2,7 +2,7 @@
>
> COMMENT= mailing list manager with web interface
>
> -DISTNAME= mailman-2.1.26
> +DISTNAME= mailman-2.1.29
> CATEGORIES=mail www
>
> HOMEPAGE= https://www.gnu.org/software/mailman/
> Index: distinfo
> ===
> RCS file: /home/open/cvs/ports/mail/mailman/distinfo,v
> retrieving revision 1.28
> diff -u -p -r1.28 distinfo
> --- distinfo5 Feb 2018 21:38:44 - 1.28
> +++ distinfo25 Jul 2018 11:43:50 -
> @@ -1,2 +1,2 @@
> -SHA256 (mailman-2.1.26.tgz) = JAF34e9WHt6I17SCg8ODXzm70LGuGRANNSDL5DBYM58=
> -SIZE (mailman-2.1.26.tgz) = 9264592
> +SHA256 (mailman-2.1.29.tgz) = g4hycTYB6KEkFG5VD1NwlILB7xaPHhbSAUZcZRy/DSw=
> +SIZE (mailman-2.1.29.tgz) = 9376258
> Index: pkg/PLIST
> ===
> RCS file: /home/open/cvs/ports/mail/mailman/pkg/PLIST,v
> retrieving revision 1.29
> diff -u -p -r1.29 PLIST
> --- pkg/PLIST 5 Feb 2018 21:38:44 - 1.29
> +++ pkg/PLIST 23 Jul 2018 19:38:04 -
> @@ -6,6 +6,7 @@
> @newgroup _mailmanq:769
> @newuser _mailman:504:_mailman:daemon:Mailing List
> Manager:${PREFIX}/lib/mailman:/sbin/nologin
> @extraunexec rm -fr /var/spool/mailman/*
> +@rcscript ${RCDIR}/mailman
> @owner _mailman
> @group _mailman
> lib/mailman/
> @@ -334,7 +335,7 @@ lib/mailman/Mailman/i18n.pyc
> @comment lib/mailman/Mailman/mm_cfg.py
> lib/mailman/Mailman/mm_cfg.py.dist
> @mode 664
> -@sample ${PREFIX}/lib/mailman/Mailman/mm_cfg.py
> +@sample lib/mailman/Mailman/mm_cfg.py
> @comment lib/mailman/Mailman/mm_cfg.pyc
> @mode
> lib/mailman/Mailman/versions.py
> @@ -429,8 +430,10 @@ lib/mailman/messages/ar/LC_MESSAGES/
> @mode
> lib/mailman/messages/ar/LC_MESSAGES/mailman.mo
> lib/mailman/messages/ar/LC_MESSAGES/mailman.po
> +@mode 775
> lib/mailman/messages/ast/
> lib/mailman/messages/ast/LC_MESSAGES/
> +@mode
> lib/mailman/messages/ast/LC_MESSAGES/mailman.mo
> lib/mailman/messages/ast/LC_MESSAGES/mailman.po
> @mode 775
> @@ -458,11 +461,19 @@ lib/mailman/messages/de/LC_MESSAGES/
> lib/mailman/messages/de/LC_MESSAGES/mailman.mo
> lib/mailman/messages/de/LC_MESSAGES/mailman.po
> lib/mailman/messages/de/README.de
> +@mode 775
> lib/mailman/messages/el/
> lib/mailman/messages/el/LC_MESSAGES/
> +@mode
> lib/mailman/messages/el/LC_MESSAGES/mailman.mo
> lib/mailman/messages/el/LC_MESSAGES/mailman.po
> @mode 775
> +lib/mailman/messages/eo/
> +lib/mailman/messages/eo/LC_MESSAGES/
> +@mode
> +lib/mailman/messages/eo/LC_MESSAGES/mailman.mo
> +lib/mailman/messages/eo/LC_MESSAGES/mailman.po
> +@mode 775
> lib/mailman/messages/es/
> lib/mailman/messages/es/LC_MESSAGES/
> @mode
> @@ -482,8 +493,10 @@ lib/mailman/messages/eu/LC_MESSAGES/
> lib/mailman/messages/eu/LC_MESSAGES/mailman.mo
> lib/mailman/messages/eu/LC_MESSAGES/mailman.po
> lib/mailman/messages/eu/README.eu
> +@mode 775
> lib/mailman/messages/fa/
> lib/mailman/messages/fa/LC_MESSAGES/
> +@mode
> lib/mailman/messages/fa/LC_MESSAGES/mailman.mo
> lib/mailman/messages/fa/LC_MESSAGES/mailman.po
> @mode 775
> @@ -500,12 +513,16 @@ lib/mailman/messages/fr/LC_MESSAGES/
> lib/mailman/messages/fr/LC_MESSAGES/mailman.mo
> lib/mailman/messages/fr/LC_MESSAGES/mailman.po
> lib/mailman/messages/fr/README.fr
> +@mode 775
> lib/mailman/messages/gl/
> lib/mailman/messages/gl/LC_MESSAGES/
> +@mode
> lib/mailman/messages/gl/LC_MESSAGES/mailman.mo
> lib/mailman/messages/gl/LC_MESSAGES/mailman.po
> +@mode 775
> lib/mailman/messages/he/
> lib/mailman/messages/he/LC_MESSAGES/
> +@mode
> lib/mailman/messages/he/LC_MESSAGES/mailman.mo
> lib/mailman/messages/he/LC_MESSAGES/mailman.po
> @mode 775
> @@ -597,8 +614,10 @@ lib/mailman/messages/ru/LC_MESSAGES/
> lib/mailman/messages/ru/LC_MESSAGES/mailman.mo
> lib/mailman/messages/ru/LC_MESSAGES/mailman.po
> lib/mailman/messages/ru/README.ru
> +@mode 775
> lib/mailman/messages/sk/
> lib/mailman/messages/sk/LC_MESSAGES/
> +@mode
> lib/mailman/messages/sk/LC_MESSAGES/mailman.mo
> lib/mailman/messages/sk/LC_MESSAGES/mailman.po
> lib/mailman/messages/sk/README.sk
> @@ -1045,6 +1064,44 @@ lib/mailman/templates/en/unsubauth.txt
> lib/mailman/templates/en/userpass.txt
> lib/mailman/templa
NEW: graphics/frei0r
Frei0r is a minimalistic plugin API for video effects.
Potential users of this are ffmpeg, mlt, lives, gstreamer and maybe others.
I have sucessfully tested some filter using ffmpeg (built with --enable-frei0r,
see diff below).
For example:
$ ffmpeg -i in.jpg -vf "frei0r=pixeliz0r:0.1:0.1" out.jpg
I didn't manage to get the filters 'facebl0r' and 'facedetect' to work without
crashing (they use opencv), so these are disabled for now.
ffmpeg diff (for testing):
Index: Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.169
diff -u -p -u -p -r1.169 Makefile
--- Makefile23 Jul 2018 10:34:40 - 1.169
+++ Makefile17 Aug 2018 10:29:01 -
@@ -32,7 +32,8 @@ WANTLIB= SDL X11 Xext Xv ass bz2 c crypt
vorbisenc vpx>=5 x264 x265>=2 xcb xcb-shape xcb-shm xcb-xfixes \
xvidcore z
-BUILD_DEPENDS= textproc/texi2html
+BUILD_DEPENDS= textproc/texi2html \
+ graphics/frei0r
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
BUILD_DEPENDS+=devel/yasm
.endif
@@ -90,6 +91,7 @@ CONFIGURE_ARGS+= --enable-shared \
--disable-vfp \
--enable-avresample \
--enable-fontconfig \
+ --enable-frei0r \
--enable-gpl \
--enable-libass \
--enable-libfreetype \
frei0r.tar.gz
Description: application/gzip
[new] cbindgen (firefox build requirement)
Hi, i needed a port for https://github.com/eqrion/cbindgen , 'coz soon it'll be a build requirement for firefox (per https://groups.google.com/forum/#!topic/mozilla.dev.platform/t4Bc-I0lxBY).. comments from rust wizards welcome, oks too. Landry cbindgen-0.6.1.tgz Description: application/tar-gz
Re: rspamd: SEPARATE_BUILD and other nits
On 2018/08/20 13:40, Klemens Nanni wrote:
> On Mon, Aug 20, 2018 at 01:22:10PM +0200, Rafael Sadowski wrote:
> > rspamd is a camke port and SEPARATE_BUILD is always set by cmake.port.mk
> Right (not sure now why I set it in the first place).
>
> Rest still stands.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/rspamd/Makefile,v
> retrieving revision 1.55
> diff -u -p -r1.55 Makefile
> --- Makefile 1 Aug 2018 17:11:44 - 1.55
> +++ Makefile 20 Aug 2018 11:40:03 -
> @@ -20,19 +20,19 @@ WANTLIB += intl luajit-5.1 m magic pcre
>
> MODULES= devel/cmake
> LIB_DEPENDS= databases/sqlite3 \
> - devel/libmagic \
> devel/gettext \
> devel/glib2 \
> + devel/libmagic \
> devel/pcre \
> lang/luajit \
> textproc/icu4c
> BUILD_DEPENDS+= devel/ragel
> # /var/rspamd needs to exist for tests to run
> -TEST_DEPENDS = ${FULLPKGNAME}:${FULLPKGPATH}
> -TEST_DEPENDS += databases/redis \
> +TEST_DEPENDS=${FULLPKGNAME}:${FULLPKGPATH}
> +TEST_DEPENDS+= databases/redis \
> + devel/py-robotframework \
> sysutils/py-psutil \
> - textproc/py-demjson \
> - devel/py-robotframework
> + textproc/py-demjson
>
> CONFIGURE_ARGS+=-DOPENBSD_BUILD=1 \
> -DCMAKE_C_OPT_FLAGS="${CFLAGS}" \
> @@ -45,10 +45,11 @@ CONFIGURE_ARGS+=-DOPENBSD_BUILD=1 \
> -DRSPAMD_GROUP="_rspamd"
>
> # Make sure we pick up the base libevent, never the ports one!
> -CONFIGURE_ARGS +=-DLIBEVENT_ROOT_DIR=/usr
> +CONFIGURE_ARGS+= -DLIBEVENT_ROOT_DIR=/usr
OK for the above
> -# Make sure you have no rspamd or redis instances running and note that the
> -# test suite uses the network.
> -#
> +
> +TEST_IS_INTERACTIVE= Make sure you have no rspamd or redis instances running
> \
> + and note that the test suite uses the network.
> +
> # In the event of failing tests, look at log.html in ${WRKSRC}
> do-test:
> cd ${WRKSRC} && \
>
Please skip this, it's not interactive and runs ok in normal conditions,
no need to block it from a run of non-interactive tests in bulk if
anyone cares to do such a thing.
Re: [new] cbindgen (firefox build requirement)
On 2018/08/20 21:28, Landry Breuil wrote: > Hi, > > i needed a port for https://github.com/eqrion/cbindgen , 'coz soon it'll > be a build requirement for firefox (per > https://groups.google.com/forum/#!topic/mozilla.dev.platform/t4Bc-I0lxBY).. > comments from rust wizards welcome, oks too. No need to list rust in BUILD_DEPENDS, it's added by the module. Otherwise seems ok here (but I am only a rust muggle, of course :-)
Re: UPDATE: www/kibana + NEW: www/kibana-oss
On 2018/08/20 10:53, Pavel Korovin wrote: > Last part of ELK stack. > OK? The ports read OK but have you considered keeping the Apache-licensed one in the same PKGNAME as before (so that pkg_add -u works), and picking a different name for the non-free one? (funny looking license, I don't have the energy to read it all but "do not hack the licensing mechanism" sticks out as strange text to use!)
Re: [UPDATE] sysutils/p5-File-Rename 0.20 -> 1.00
I'd be OK with that, though since this was added after the last OpenBSD
release, I think I would skip MESSAGE and just make sure it's mentioned
in commit log, it will just be noise for most users.
On 2018/08/19 15:28, Charlene Wendling wrote:
> Hi ports,
>
> Here is an update for sysutils/p5-File-Rename, a perl module that
> renames files using regular expressions, including a 'rename'
> script for direct command-line use.
>
> What's new upstream (full changelog[1]):
>
> - File::Rename::Options has been added, it's used for parsing the script
> options
> - Various fixes and improved test suite
>
> What's new in the port:
>
> - Followed Stuart Henderson's suggestion [2] to rename 'rename' to
> 'prename' as it's usually found by this name on other operating
> systems. It shouldn't cause too much disruption doing it now, as the
> port has been imported ~ 3 months ago. A MESSAGE has been added to this
> effect, and DESCR modified accordingly.
> - A DESCR example of prename wasn't working. I fixed it.
>
> Testing:
>
> Tested with proot on amd64 (it's noarch anyway):
> - 'make test' returns PASSED - i've let pod coverage as-is, but checked
> that manpages are properly generated.
> - prename examples given in DESCR are working
> - Tried the module itself with a simple example:
>
> perl -e 'use File::Rename; File::Rename::rename(["/etc/motd"],
> {_code=>sub{s/m/M/}, verbose=>1, no_action=>1})'
>
> Any comment and feedback is welcome!
>
> Charlène.
>
> [1] https://metacpan.org/changes/distribution/File-Rename
> [2] https://marc.info/?l=openbsd-ports&m=152767952308067&w=2
Re: UPDATE: www/kibana + NEW: www/kibana-oss
On 08/20, Stuart Henderson wrote: > The ports read OK but have you considered keeping the Apache-licensed one > in the same PKGNAME as before (so that pkg_add -u works), and picking a > different name for the non-free one? (funny looking license, I don't > have the energy to read it all but "do not hack the licensing mechanism" > sticks out as strange text to use!) Yes, my first approach was exactly like that, but it clashes with official naming, i.e. Elastic uses *-oss naming for Apache-licensed packages and I'd like to avoid ambiguity. Not sure how to deal with updates, e.g. how to manage it via quirks. Any suggestions? -- With best regards, Pavel Korovin
Re: UPDATE: www/kibana + NEW: www/kibana-oss
On 2018/08/21 00:03, Pavel Korovin wrote: > On 08/20, Stuart Henderson wrote: > > The ports read OK but have you considered keeping the Apache-licensed one > > in the same PKGNAME as before (so that pkg_add -u works), and picking a > > different name for the non-free one? (funny looking license, I don't > > have the energy to read it all but "do not hack the licensing mechanism" > > sticks out as strange text to use!) > > Yes, my first approach was exactly like that, but it clashes with > official naming, i.e. Elastic uses *-oss naming for Apache-licensed > packages and I'd like to avoid ambiguity. Not sure how to deal with > updates, e.g. how to manage it via quirks. Any suggestions? > > -- > With best regards, > Pavel Korovin > You could do this via quirks with naming like *-oss and *-nonfree and have a "rename elastic -> elastic-oss" quirk, but I think (even if we aren't providing ftp packages) that it can't be done while keeping the plain "elastic" name around (the quirk would keep on applying, so somebody installing from ports locally and then doing "pkg_add -u" could have it "sidegraded" to the oss version).
Re: [UPDATE] sysutils/p5-File-Rename 0.20 -> 1.00
On Mon, 20 Aug 2018 21:52:20 +0100
Stuart Henderson wrote:
> I'd be OK with that, though since this was added after the last
> OpenBSD release, I think I would skip MESSAGE and just make sure it's
> mentioned in commit log, it will just be noise for most users.
>
Hi,
It totally makes sense, i added it because i saw it from the point of
view of a -current user.
I zapped MESSAGE and retested the port, it works fine.
Charlène.
> On 2018/08/19 15:28, Charlene Wendling wrote:
> > Hi ports,
> >
> > Here is an update for sysutils/p5-File-Rename, a perl module that
> > renames files using regular expressions, including a 'rename'
> > script for direct command-line use.
> >
> > What's new upstream (full changelog[1]):
> >
> > - File::Rename::Options has been added, it's used for parsing the
> > script options
> > - Various fixes and improved test suite
> >
> > What's new in the port:
> >
> > - Followed Stuart Henderson's suggestion [2] to rename 'rename' to
> > 'prename' as it's usually found by this name on other operating
> > systems. It shouldn't cause too much disruption doing it now, as the
> > port has been imported ~ 3 months ago. A MESSAGE has been added to
> > this effect, and DESCR modified accordingly.
> > - A DESCR example of prename wasn't working. I fixed it.
> >
> > Testing:
> >
> > Tested with proot on amd64 (it's noarch anyway):
> > - 'make test' returns PASSED - i've let pod coverage as-is, but
> > checked that manpages are properly generated.
> > - prename examples given in DESCR are working
> > - Tried the module itself with a simple example:
> >
> > perl -e 'use File::Rename; File::Rename::rename(["/etc/motd"],
> > {_code=>sub{s/m/M/}, verbose=>1, no_action=>1})'
> >
> > Any comment and feedback is welcome!
> >
> > Charlène.
> >
> > [1] https://metacpan.org/changes/distribution/File-Rename
> > [2] https://marc.info/?l=openbsd-ports&m=152767952308067&w=2
>
>
p5-File-Rename.diff
Description: Binary data
UPDATE: www/py-requests
Hello all,
Simple version update for www/py-requests to 2.19.1, contacted
maintainer but did not hear back so submitting here. Copied the port to
mystuff/ before making the changes, hopefully that does not affect too much.
Failing tests are for the Pipfile which is not included in the package
as its just for development. I would not mind extra eyes on this though.
Diffs below and pending feedback.
Thank you in advance.
--- /usr/ports/www/py-requests/distinfo Mon Aug 20 19:47:17 2018
+++ /usr/ports/mystuff/www/py-requests/distinfo Mon Aug 20 19:47:55 2018
@@ -1,2 +1,2 @@
-SHA256 (requests-2.18.4_1.tar.gz) =
nEQ+cyS6W4UHDEqBit4ov6vt8W6hAgbaETLtqm3aI34=
-SIZE (requests-2.18.4_1.tar.gz) = 126224
+SHA256 (requests-2.19.1_1.tar.gz) =
7CLYJqNu1ypzWP8/5Wy9S6ad16Zxj/1FD/Dp33pHzmo=
+SIZE (requests-2.19.1_1.tar.gz) = 131068
--- /usr/ports/www/py-requests/Makefile Mon Aug 20 19:47:13 2018
+++ /usr/ports/mystuff/www/py-requests/Makefile Mon Aug 20 19:46:43 2018
@@ -2,7 +2,7 @@
COMMENT= elegant and simple HTTP library for Python
-MODPY_EGG_VERSION= 2.18.4
+MODPY_EGG_VERSION= 2.19.1
DISTNAME= requests-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
REVISION= 0
--- /usr/ports/www/py-requests/pkg/PLISTThu Jul 26 19:02:41 2018
+++ /usr/ports/mystuff/www/py-requests/pkg/PLISTMon Aug 20
19:48:26 2018
@@ -1,4 +1,4 @@
-@comment $OpenBSD: PLIST,v 1.12 2018/01/21 23:20:10 jung Exp $
+@comment $OpenBSD: PLIST,v$
lib/python${MODPY_VERSION}/site-packages/requests/
lib/python${MODPY_VERSION}/site-packages/requests-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/requests-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -8,7 +8,7 @@ lib/python${MODPY_VERSION}/site-packages/requests-${MO
lib/python${MODPY_VERSION}/site-packages/requests-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/requests-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/requests/__init__.py
-${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}
lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}__version__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}_internal_utils.${MODPY_PYC_MAGIC_TAG}pyc
--
Edward Lopez-Acosta
Re: UPDATE: www/py-requests
On Mon, 20 Aug 2018 19:55:04 -0500, Edward Lopez-Acosta
wrote:
> Hello all,
>
> Simple version update for www/py-requests to 2.19.1, contacted
> maintainer but did not hear back so submitting here. Copied the port
> to mystuff/ before making the changes, hopefully that does not affect
> too much.
>
> Failing tests are for the Pipfile which is not included in the
> package as its just for development. I would not mind extra eyes on
> this though.
Did you test anything that depends on this port? There are 68 ports
which have a rdep on requests so it's not 'just another ports'. Any
reason that would motivate the update?
I don't know if it's the way you created your patch, or thunderbird, or
both but your patch won't apply. You can attach it if you want to bypass
thunderbird messing with it. If you don't know how to use git, just use
cvs: a mere `cvs diff > diff.txt` and attaching the result is enough.
No need to diff file by file, from mystuff and the regular port.
Some comments inlined.
> --- /usr/ports/www/py-requests/Makefile Mon Aug 20 19:47:13 2018
> +++ /usr/ports/mystuff/www/py-requests/Makefile Mon Aug 20 19:46:43
> 2018 @@ -2,7 +2,7 @@
>
> COMMENT= elegant and simple HTTP library for Python
>
> -MODPY_EGG_VERSION= 2.18.4
> +MODPY_EGG_VERSION= 2.19.1
> DISTNAME= requests-${MODPY_EGG_VERSION}
> PKGNAME= py-${DISTNAME}
> REVISION= 0
revision line should be removed
> --- /usr/ports/www/py-requests/pkg/PLISTThu Jul 26 19:02:41
> 2018 +++ /usr/ports/mystuff/www/py-requests/pkg/PLISTMon Aug
> 20 19:48:26 2018
> @@ -8,7 +8,7 @@ lib/python${MODPY_VERSION}/site-packages/requests-${MO
>
> lib/python${MODPY_VERSION}/site-packages/requests-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
>
> lib/python${MODPY_VERSION}/site-packages/requests-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> lib/python${MODPY_VERSION}/site-packages/requests/__init__.py
> -${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}/
> +lib/python${MODPY_VERSION}/site-packages/requests/${MODPY_PYCACHE}
That doesn't look good to me did both py2 and py3 version package
correctly?
Cheers,
Daniel
Re: NEW: graphics/frei0r
On 08/20/18 11:23, Raphael Graf wrote:
Frei0r is a minimalistic plugin API for video effects.
Potential users of this are ffmpeg, mlt, lives, gstreamer and maybe others.
I have sucessfully tested some filter using ffmpeg (built with --enable-frei0r,
see diff below).
For example:
$ ffmpeg -i in.jpg -vf "frei0r=pixeliz0r:0.1:0.1" out.jpg
I didn't manage to get the filters 'facebl0r' and 'facedetect' to work without
crashing (they use opencv), so these are disabled for now.
Any reason not to use the tarballs on
https://files.dyne.org/frei0r/releases/ ?
Then you can do something like
DISTNAME = frei0r-plugins-1.6.1
PKGNAME = ${DISTNAME:S/-plugins//}
~Brian
ffmpeg diff (for testing):
Index: Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.169
diff -u -p -u -p -r1.169 Makefile
--- Makefile23 Jul 2018 10:34:40 - 1.169
+++ Makefile17 Aug 2018 10:29:01 -
@@ -32,7 +32,8 @@ WANTLIB= SDL X11 Xext Xv ass bz2 c crypt
vorbisenc vpx>=5 x264 x265>=2 xcb xcb-shape xcb-shm xcb-xfixes \
xvidcore z
-BUILD_DEPENDS= textproc/texi2html
+BUILD_DEPENDS= textproc/texi2html \
+ graphics/frei0r
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
BUILD_DEPENDS+= devel/yasm
.endif
@@ -90,6 +91,7 @@ CONFIGURE_ARGS+= --enable-shared \
--disable-vfp \
--enable-avresample \
--enable-fontconfig \
+ --enable-frei0r \
--enable-gpl \
--enable-libass \
--enable-libfreetype \
Re: [NEW/WIP] Qflow porting // [3/7] graywolf
Alessandro -- On 08/19/18 10:43, Alessandro DE LAURENZIS wrote: Hi Brian, On 08/17/18 17:33, Brian Callahan wrote: I think this one is fine. The other one is probably a little too much. ~Brian [... snip ...] graywolf is a fork of TimberWolf 6.3.5, a placement tool used in VLSI design. TimberWolf is an integrated set of placement (and routing) programs, based on the general combinatorial optimization technique known as simulated annealing. Its last open-source distribution by Yale University is suitable for standard cell, macro/custom cell, and gate-array professional-grade placement. The main improvement in graywolf is that the build process is more streamlined and that it behaves as a normal tool - you can call it from anywhere and no environment variables must be set first. graywolf is mainly used together with Qflow (http://opencircuitdesign.com/qflow/). [... snip ...] I finally had a look at the new graywolf's release. Upstream has been very active in the last weeks and made 3 point releases for 0.1.5 and a brand new 0.1.6. I considered directly the latter, of course. We can save 2 patches (for src/Ylib/okmalloc.c and src/date/getdate.c), but we need to remove a (unintended?) cast to void from src/genrows/draw.c cmake is now able to include and link libs from OPENBSD_X11BASE, but still need a patch because they added devel/gsl as LIB_DEPENDS and OPENBSD_LOCALBASE is not seen. No regression in my (limited) set of test-cases. Updated tarball attached. Ok to import? OK I think this is ready now. I hope you send the patches that add __OpenBSD__ to places upstream if you haven't already. ~Brian
Re: [NEW/WIP] Qflow porting // [4/7] qrouter
Hi Alessandro --
On 08/19/18 11:03, Alessandro DE LAURENZIS wrote:
Dear ports@ readers,
enclosed please find a port for qrouter [1], the tool required by
Qflow [2] for routing:
[... snip ...]
$ pkg_info qrouter
Information for inst:qrouter-1.3.104
Comment:
multi-level, over-the-cell maze router for VLSI design
Description:
Qrouter is a tool to generate metal layers and vias to physically
connect together a netlist in a VLSI fabrication technology. It
is a maze router, otherwise known as an "over-the-cell" router or
"sea-of-gates" router. That is, unlike a channel router, it begins with
a description of placed standard cells, usually packed together at
minimum spacing, and places metal routes over the standard cells.
Qrouter uses the open standard LEF and DEF formats as file input and
output. It takes the cell definitions from a LEF file, and analyzes
the geometry for each cell to determine contact points and route
obstructions. It then reads the cell placement, pin placement, and
netlist from a DEF file, performs the detailed route, and writes an
annotated DEF file as output.
Maintainer: Alessandro De Laurenzis
WWW: http://opencircuitdesign.com/qrouter/
[... snip ...]
This port is very similar to cad/xcircuit (same author, same overall
"style", but older code), so I tried to stay as close as possible to
the correspondent Makefile.
There are two branches, "stable" and "development"; choosing the
former should reduce the maintainer's work :-), so the port is for the
stable latest release, 1.3.104.
configure.in and qrouter.h must be lightly patched in order to behave
correctly when the __OpenBSD__ identifier is present.
I also patched Makefile.in since it seems that ${X_LIBS} is missing
from a target which requires it (I'll report this to upstream in the
coming days).
Compiles and runs correctly on amd64, lightly tested in Qflow.
Of course, I step-up for maintainership.
[1] http://opencircuitdesign.com/qrouter/index.html
[2] https://marc.info/?l=openbsd-ports&m=153270090320035&w=2
I made only a few small changes:
* Changed the license marker to GPLv2 only.
* Wrote out the MASTER_SITES line fully. There was a discussion a few
years ago about discouraging the MASTER_SITES=${HOMEPAGE}/something idiom.
* I added two new patches, adding stdarg.h in two files. There were some
warnings that va_list was being used as an implicit int since it didn't
have a definition. That's definitely worth changing.
I think that's all I did. Tarball with those changes attached.
~Brian
qrouter.tgz
Description: Binary data
