CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: feine...@cvs.openbsd.org2019/03/22 23:40:03 Modified files: multimedia/libv4l: Makefile distinfo multimedia/libv4l/patches: patch-lib_libv4lconvert_Makefile_in Log message: Update to libv4l 1.16.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/03/22 23:27:33 Modified files: devel/sdl2 : Makefile Added files: devel/sdl2/patches: patch-src_video_wayland_SDL_waylandvulkan_c patch-src_video_x11_SDL_x11vulkan_c Log message: Don't specify major version when dlopen()ing the vulkan loader, always use the latest. Similiar to the situation with libGL. ok thfr@
xl2tpd README improvements
I had the misfortune today of having to setup an IKEv1/L2TP VPN. FAQ 17 was very helpful, as was the xl2tpd README, but there are a couple of issues I ran into that I think should be addressed by the README. First, xl2tpd won't run pppd unless the _xl2tpd user is in the network group (see SECURITY section of pppd(8)). If you don't add _xl2tpd to the network group, you get this error when running xl2tpd: xl2tpd[83064]: start_pppd: Exec of /usr/sbin/pppd failed Second /etc/ppp/options contains "auth", and since the /etc/ppp/options.l2tp file recommended by the README has "noauth", the configuration doesn't work, with pppd erroring with: pppd[42191]: cannot override default auth option The diff should fix these issues. OKs? Thanks, Jeremy Index: pkg/README === RCS file: /cvs/ports/net/xl2tpd/pkg/README,v retrieving revision 1.8 diff -u -p -r1.8 README --- pkg/README 4 Sep 2018 12:46:19 - 1.8 +++ pkg/README 23 Mar 2019 03:58:20 - @@ -109,6 +109,8 @@ esp transport from $server to $me spi 0x If that is successful, you can try to make the L2TP connection: +# sed -i 's/^auth/#auth/' /etc/ppp/options +# usermod -G network _xl2tpd # ifconfig ppp0 up # rcctl start xl2tpd # tail -f /var/log/daemon &
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/03/22 16:09:48 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: rename digikam (KDE4) to digikam-kde4 Pointer by espie; Thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2019/03/22 16:09:55 Modified files: x11/kde-applications: Makefile Log message: Unhook libkface,libkgeomap say goodbye to the last KDE4 ports in x11/kde-applications
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org 2019/03/22 16:09:37
Modified files:
graphics/digikam-kde4: Makefile
graphics/digikam-kde4/patches:
patch-extra_kipi-plugins_CMakeLists_txt
patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt
patch-extra_kipi-plugins_gpssync_CMakeLists_txt
graphics/digikam-kde4/pkg: PLIST-kipi PLIST-main
Added files:
graphics/digikam-kde4/patches:
patch-core_cmake_modules_MacroOpenCV_cmake
patch-extra_kipi-plugins_cmake_modules_MacroOpenCV_cmake
patch-extra_libkface_cmake_modules_MacroOpenCV_cmake
graphics/digikam-kde4/pkg: DESCR-face DESCR-geomap PLIST-face
PLIST-geomap
Log message:
Teach digikam4 to build with graphics/opencv2
Highlights:
- Rename digikam to digikam-kde4 (see Quirks bits)
- New mutli-packages: face and geomap which make
x11/kde-applications/{libkface, libkgeomap} unnecessary
Notable changes:
- fix MASTER_SITE
- s/https/https/
- dependencies WANTLIB cleanup
- regen PLIST
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/03/22 15:04:10 Modified files: shells/bash: Makefile distinfo Log message: update to 5.0 patchlevel 3
devel/frama-c: Add findlib as run dependency
Here is what I see if I launch frama-c after installing the standard package:
$ frama-c
[kernel] Current source was: :0
The full backtrace is:
Raised at file "stdlib.ml", line 33, characters 17-33
Called from file "findlib.ml", line 166, characters 10-151
Called from file "src/kernel_services/plugin_entry_points/dynamic.ml", line
287, characters 2-45
Called from file "src/kernel_services/plugin_entry_points/kernel.ml", line
760, characters 4-49
Called from file "src/kernel_services/cmdline_parameters/cmdline.ml", line
836, characters 2-22
Called from file "src/kernel_services/cmdline_parameters/cmdline.ml", line
229, characters 4-8
Unexpected error (Failure("Config file not found - neither /etc/findlib.conf
nor the directory /etc/findlib.conf.d")).
Please report as 'crash' at http://bts.frama-c.com/.
Your Frama-C version is 18.0 (Argon).
Note that a version and a backtrace alone often do not contain enough
information to understand the bug. Guidelines for reporting bugs are at:
http://bts.frama-c.com/dokuwiki/doku.php?id=mantis:frama-c:bug_reporting_guidelines
$
If I install the findlib package, frama-c runs without incident.
Below is a patch that adds findlib as a run dependency for frama-c.
Index: devel/frama-c/Makefile
===
RCS file: /cvs/ports/devel/frama-c/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- devel/frama-c/Makefile 13 Mar 2019 09:34:42 - 1.12
+++ devel/frama-c/Makefile 22 Mar 2019 20:35:43 -
@@ -24,8 +24,8 @@ MODULES = lang/ocaml
BUILD_DEPENDS =x11/lablgtk2 devel/ocaml-graph \
math/graphviz math/ocaml-zarith sysutils/findlib
-RUN_DEPENDS = x11/lablgtk2 math/graphviz math/ocaml-zarith
-
+RUN_DEPENDS = x11/lablgtk2 math/graphviz math/ocaml-zarith \
+ sysutils/findlib
LIB_DEPENDS = x11/gnome/libgnomecanvas \
x11/gtksourceview
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org 2019/03/22 14:39:07
Log message:
Import opencv2-2.4.13.4; Tweaks and OK kn@. Big Thanks!
The Open Computer Vision Library is a collection of algorithms and sample
code for various computer vision problems.
This package contains main OpenCV components.
It's completely based on graphics/opencv with following changes:
- PKGNAME to opencv2 to enable coexistence between opencv2 and
opencv3/4.
- Dropped -java, -docs (Is not required for the last consumers)
- Drop examples and tests
- Changed install paths to avoid conflicts with (main) opencv.
- bin to ${LOCALBASE}\bin\opencv2
- libs to ${LOCALBASE}\libs\opencv2
- include/opencv to ${LOCALBASE}\include\opencv2
- and so on.
Status:
Vendor Tag: rsadowski
Release Tags: rsadowski_20190322
N ports/graphics/opencv2/Makefile
N ports/graphics/opencv2/distinfo
N ports/graphics/opencv2/patches/patch-CMakeLists_txt
N ports/graphics/opencv2/patches/patch-cmake_OpenCVFindLibsVideo_cmake
N ports/graphics/opencv2/patches/patch-cmake_OpenCVPCHSupport_cmake
N ports/graphics/opencv2/patches/patch-cmake_OpenCVUtils_cmake
N
ports/graphics/opencv2/patches/patch-modules_core_include_opencv2_core_operations_hpp
N ports/graphics/opencv2/patches/patch-modules_core_src_system_cpp
N ports/graphics/opencv2/patches/patch-modules_java_CMakeLists_txt
N ports/graphics/opencv2/patches/patch-modules_python_src2_cv2_cv_hpp
N ports/graphics/opencv2/patches/patch-modules_ts_CMakeLists_txt
N ports/graphics/opencv2/patches/patch-data_CMakeLists_txt
N
ports/graphics/opencv2/patches/patch-modules_highgui_src_cap_ffmpeg_impl_hpp
N ports/graphics/opencv2/pkg/DESCR
N ports/graphics/opencv2/pkg/PLIST
No conflicts created by this import
devel/glib2: fix use-after-free
For some time now I have noticed that logging into gnome from gdm
sometimes failed on my systems, even with my user account in the
'staff' group to avoid the known problems with default resource limits.
Gnome failed to start, and often gdm would not restart properly when
this happened, leaving me with just a console screen.
Today I found a core file from gnome-session-binary and with this
I could track the above problem down to a use-after-free in glib2.
Without the patch below I quickly get a gnome-session-bi.core file in
my home directory if I keep logging in and out of gnome. A nice way
of repeating this is to add the lines below to /etc/gdm/custom.conf,
then logging in via SSH and running '/etc/rc.d/gdm restart' repeatedly.
TimedLoginEnable=True
TimedLogin=youruser
TimedLoginDelay=1
With this patch I can restart gnome like this over and over and the
desktop comes back much more reliably. I don't get a core file anymore.
It is still not entirely free of problems, e.g. gnome-shell sometimes
won't come back after restarting gdm, and then the screen stays black:
# pgrep -fl gdm
24802 /usr/local/sbin/gdm
# pgrep -fl gnome-shell
#
But that looks like a separate issue.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/glib2/Makefile,v
retrieving revision 1.296
diff -u -p -r1.296 Makefile
--- Makefile19 Feb 2019 14:53:17 - 1.296
+++ Makefile22 Mar 2019 17:39:57 -
@@ -9,7 +9,7 @@ COMMENT=general-purpose utility librar
GNOME_PROJECT= glib
GNOME_VERSION= 2.58.3
PKGNAME= ${DISTNAME:S/glib/glib2/}
-REVISION= 5
+REVISION= 6
CATEGORIES=devel
Index: patches/patch-gio_gdbusprivate_c
===
RCS file: patches/patch-gio_gdbusprivate_c
diff -N patches/patch-gio_gdbusprivate_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-gio_gdbusprivate_c22 Mar 2019 19:11:48 -
@@ -0,0 +1,43 @@
+$OpenBSD$
+Fix use-after-free triggered by gnome-session-binary when Gnome restarts.
+
+ostream_flush_cb() was calling flush_data_list_complete() with a single
+element list with an item that had already been freed:
+
+#2 0x0e3c0104577a in flush_data_list_complete (flushers=0xe3bd8300340,
+error=0x0) at ../glib-2.58.3/gio/gdbusprivate.c:1156
+1156 g_mutex_lock (>mutex);
+(gdb) p /x *f
+$74 = {mutex = {p = 0xdfdfdfdfdfdfdfdf, i = {0xdfdfdfdf, 0xdfdfdfdf}}, cond = {
+p = 0xdfdfdfdfdfdfdfdf, i = {0xdfdfdfdf, 0xdfdfdfdf}},
+ number_to_wait_for = 0xdfdfdfdfdfdfdfdf, error = 0x0}
+
+This happened because the thread freeing the element didn't properly wait
+for the asynchronous flush operation to finish.
+Gnome's developer docs say: "g_cond_wait() must always be used in a loop"
+https://developer.gnome.org/glib/stable/glib-Threads.html#g-cond-wait
+
+Index: gio/gdbusprivate.c
+--- gio/gdbusprivate.c.orig
gio/gdbusprivate.c
+@@ -1788,10 +1788,17 @@ _g_dbus_worker_flush_sync (GDBusWorker*worker,
+
+ if (data != NULL)
+ {
+- g_cond_wait (>cond, >mutex);
+- g_mutex_unlock (>mutex);
++ /* Wait for flush operations to finish. */
++ g_mutex_lock (>write_lock);
++ while (worker->write_num_messages_flushed < data->number_to_wait_for)
++{
++ g_mutex_unlock (>write_lock);
++ g_cond_wait (>cond, >mutex);
++ g_mutex_lock (>write_lock);
++}
++ g_mutex_unlock (>write_lock);
+
+- /* note:the element is removed from worker->write_pending_flushes in
flush_cb() above */
++ g_mutex_unlock (>mutex);
+ g_cond_clear (>cond);
+ g_mutex_clear (>mutex);
+ if (data->error != NULL)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2019/03/22 13:13:34 Modified files: net/powerdns : Makefile Log message: Update to 4.1.8; ok sthen@
Re: WIP: net/libsignal-protocol-c
Quoting Anthony J. Bentley (anth...@anjbe.name): > > > Is there a reason not to build the shared lib? > > > > Makes sense to me. > > > > Attached tarball builds shared lib, sets BUILD_DEPENDS properly, > > removes executable bit from files in the port directory. > > Is this version ready for import? Any oks? Works for me. Import would be great.
Re: [NEW/WIP] Qflow porting // [7/7] opensta-20190320
On 2019/03/22 16:29, Alessandro DE LAURENZIS wrote: > My main concern with the port is related to the license; although it is > clear that the software is released under the GPLv3, as confirmed by all > source code file headers, I'm puzzled; the README.md ends as follows: > > > ## License > > > > Copyright (c) 2019, Parallax Software, Inc. > > All rights reserved. > > > > No part of this document may be copied, transmitted or > > disclosed in any form or fashion without the express > > written consent of Parallax Software, Inc. > > What do you think? odd. can you ask upstream about that please?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/03/22 12:22:10 Modified files: www/mozilla-firefox: Makefile distinfo www/firefox-i18n: Makefile.inc distinfo Log message: Update to firefox 66.0.1. See https://www.mozilla.org/en-US/firefox/66.0.1/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2019-09/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/03/22 12:06:58 Modified files: textproc/uncrustify: Makefile Log message: Needs lang/python to build.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/03/22 11:57:24 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py-botocore-1.12.119.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/03/22 11:57:39 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.16.129.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/03/22 11:57:13 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py-boto3-1.9.119.
[wip] devel/proj update to 6.0
Hi,
there's been a long-running project in the gis community to rework the
way proj & other projects handle projection definitions (cf
https://gdalbarn.com/), which culminated in the release of proj 6.0
which removes the plaintext projection files for an sqlite database.
Most of the bits are released now, the 'recommended combination' will be
gdal 2.5 + proj 6 + libgeotiff 1.5 per
https://lists.osgeo.org/pipermail/gdal-dev/2019-March/049911.html. gdal
2.5 should be released in the coming months, and libgeotiff is at rc1.
proj 6 also breaks compatibility with previous versions by deprecating a
header (proj_api.h) used by almost all consumers (it will be removed in
7), so requires fixes here and there, per
https://github.com/OSGeo/proj.4/wiki/proj.h-adoption-status
so here are 4 diffs:
- one for the proj update itself
- one for the geotiff 1.5.0rc1 update
- one for the fixes, sprinkling -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H=1
- and an update to py-proj 2.1.1 compatible with proj 6
i dont intend to commit those until geotiff hits final and gdal 2.5 is
released, and i dunno if it'll be for 6.5. But those diffs have been
through a bulk, and all other consumers of proj build fine locally.
Runtime issues (like code looking for hardcoded
/usr/local/share/proj/epsg) might ofc happen...
On a sidenote, geo/qlandkartegt should be removed as dead upstream, and
eventually superseded by qmapshack
(https://bitbucket.org/maproom/qmapshack/wiki/Home). sebastia@ ?
Comments on the rationale welcome.
Landry
Index: Makefile
===
RCS file: /cvs/ports/devel/proj/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- Makefile16 Oct 2018 13:10:43 - 1.21
+++ Makefile19 Mar 2019 21:26:18 -
@@ -2,9 +2,9 @@
COMMENT= cartographic projection utilities
-DISTNAME= proj-5.2.0
+DISTNAME= proj-6.0.0
CATEGORIES=devel geo
-SHARED_LIBS= proj 9.1 # 14.0
+SHARED_LIBS= proj 10.0 # 15.0
DISTFILES =${DISTNAME}${EXTRACT_SUFX} \
proj-datumgrid-1.8${EXTRACT_SUFX}
@@ -21,18 +21,23 @@
# c++11
COMPILER= base-clang ports-gcc
CONFIGURE_STYLE= gnu
-WANTLIB= c m pthread
-CONFIGURE_ENV= LDFLAGS='-pthread'
+LIB_DEPENDS = databases/sqlite3
+BUILD_DEPENDS =devel/gtest
+WANTLIB= c m pthread ${COMPILER_LIBCXX} sqlite3 z
+CONFIGURE_ENV= LDFLAGS='-pthread' \
+ GTEST_CFLAGS=-I${LOCALBASE}/include \
+ GTEST_LIBS="-L${LOCALBASE}/lib -lgtest"
+CONFIGURE_ARGS = --with-external-gtest
-# needed for tests only..
+# needed for proj.db
USE_GMAKE =Yes
GRIDS = BETA2007.gsb nzgd2kgrid0005.gsb ntv1_can.dat ntf_r93.gsb egm96_15.gtx \
stpaul stlrnc stgeorge prvi null hawaii conus alaska WO WI TN MD FL
-post-extract:
+post-install:
.for f in ${GRIDS}
- @mv ${WRKDIR}/${f} ${WRKSRC}/nad
+ mv ${WRKDIR}/${f} ${PREFIX}/share/proj
.endfor
.include
Index: distinfo
===
RCS file: /cvs/ports/devel/proj/distinfo,v
retrieving revision 1.11
diff -u -r1.11 distinfo
--- distinfo20 Sep 2018 06:08:40 - 1.11
+++ distinfo19 Mar 2019 21:26:18 -
@@ -1,4 +1,4 @@
-SHA256 (proj-5.2.0.tar.gz) = 75GUmf+8YqSq4mWaVeKyX/CczLviMGVrpxxiJAVsfmA=
+SHA256 (proj-6.0.0.tar.gz) = RRCiwcj5BWN0cIqGfFGxGS6Nb5pRmN0yC/ahaORKNlc=
SHA256 (proj-datumgrid-1.8.tar.gz) =
P/ZhigrMnwubT2pi5/8Pe/U4+0903ketBNoTF0CPzBU=
-SIZE (proj-5.2.0.tar.gz) = 1398188
+SIZE (proj-6.0.0.tar.gz) = 2405217
SIZE (proj-datumgrid-1.8.tar.gz) = 6604329
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/proj/pkg/PLIST,v
retrieving revision 1.7
diff -u -r1.7 PLIST
--- pkg/PLIST 7 Jun 2018 08:41:32 - 1.7
+++ pkg/PLIST 19 Mar 2019 21:26:18 -
@@ -5,13 +5,25 @@
@bin bin/gie
bin/invgeod
bin/invproj
-@bin bin/nad2bin
@bin bin/proj
+@bin bin/projinfo
include/geodesic.h
include/org_proj4_PJ.h
+include/proj/
include/proj.h
+include/proj/common.hpp
+include/proj/coordinateoperation.hpp
+include/proj/coordinatesystem.hpp
+include/proj/crs.hpp
+include/proj/datum.hpp
+include/proj/io.hpp
+include/proj/metadata.hpp
+include/proj/nn.hpp
+include/proj/util.hpp
include/proj_api.h
-include/projects.h
+include/proj_constants.h
+include/proj_experimental.h
+include/proj_symbol_rename.h
lib/libproj.a
lib/libproj.la
@lib lib/libproj.so.${LIBproj_VERSION}
@@ -21,6 +33,7 @@
@man man/man1/geod.1
@man man/man1/gie.1
@man man/man1/proj.1
+@man man/man1/projinfo.1
@man man/man3/geodesic.3
@man man/man3/pj_init.3
share/proj/
@@ -28,7 +41,6 @@
share/proj/CH
share/proj/FL
share/proj/GL27
-share/proj/IGNF
share/proj/ITRF2000
share/proj/ITRF2008
share/proj/ITRF2014
@@ -39,9 +51,6 @@
share/proj/alaska
share/proj/conus
share/proj/egm96_15.gtx
-share/proj/epsg
Re: x11/gnome seems to fail to start with new user
On Fri, Mar 22, 2019 at 05:02:17PM +0100, Stefan Sperling wrote: > On Sun, Mar 17, 2019 at 04:44:28PM -0700, Ryan Freeman wrote: > > On Tue, Mar 05, 2019 at 10:40:48AM -0800, Ryan Freeman wrote: > > > Hello! > > > > > > In testing my way around a www/chromium-related crash, I created > > > a brand new test user. I was surprised to see that this fresh > > > user, logging in from gdm, never makes it to gnome desktop. > > > > I've been checking this after every snapshot update, clean new user, > > try and log in with this user from GDM, gnome-shell never makes it > > to life. As of snapshot 2019/03/15 and matching packages, and > > today (2019/03/17) snap. > > I can reproduce this on a fresh install with a user account > in the default login class. > > The problem disappears if I move that user into login class 'staff'. Ah, that's why I never saw this issue :-) I will amend the README accordingly. Thanks. -- Antoine
Re: [NEW] cudd-3.0.0
On 2019/03/22 16:05, Alessandro DE LAURENZIS wrote: > Hello Stuart, > > On 22/03/2019 15:16, Stuart Henderson wrote: > > [...] > > Diff on top of yours. > > > > - fix fetches > > > > - it's c++ so use COMPILER > > Just for my comprehension, could you please elaborate a bit (or point me to > the relevant manpage)? On arches which still use GCC as the system compiler, a huge number of ports need to use the newer version of the compiler in ports, rather than the pre-c++11 one in base. Rather than playing whack-a-mole to fix breakage on those arches, and to avoid conflicts between the different C++ standard libraries for base and ports compilers, we're building everything using C++ with ports-gcc unless they're on the path to building ports-gcc itself. It's not ideal (especially because it's easily forgotten) but I don't have a better idea how to improve it yet.. > > > > - it builds with or without doxygen, but if present during the configure > > run then it's needed during build, so add a build dep > > > > - get rid of "-release @PACKAGE_VERSION@" to remove the lib symlink; > > if other things were looking for 'cudd-3.0.0' then you'd probably want > > to keep it but it doesn't sound like that's the case > > > > - symlink is simpler than patching for gdiff > > > > with this added, OK sthen@ to import. > [...] > > Works for me, no objections. Thanks a lot. > > -- > Alessandro DE LAURENZIS > [mailto:jus...@atlantide.t28.net] > Web: http://www.atlantide.t28.net > LinkedIn: https://www.linkedin.com/in/delaurenzis/ >
UPDATE: mail/postfwd
Hi,
update to latest version of postfwd2 (and new postfwd3).
I enabled both rcscripts because postfwd3 is still beta software.
Comments ? Ok ?
Cheers
Giovanni
Index: Makefile
===
RCS file: /var/cvs/ports/mail/postfwd/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile 8 Feb 2019 13:15:13 - 1.9
+++ Makefile 20 Mar 2019 08:08:10 -
@@ -2,7 +2,7 @@
COMMENT = Postfix policy server
-DISTNAME = postfwd-1.39
+DISTNAME = postfwd-2.00
WRKDIST = ${WRKDIR}/postfwd
CATEGORIES = mail
@@ -18,6 +18,7 @@ MASTER_SITES = ${HOMEPAGE}
RUN_DEPENDS = devel/p5-Net-Server \
devel/p5-IO-Multiplex \
+ net/p5-Net-CIDR-Lite \
net/p5-Net-DNS
PKG_ARCH = *
@@ -26,6 +27,7 @@ NO_TEST = Yes
do-install:
${INSTALL_SCRIPT} ${WRKSRC}/sbin/postfwd2 ${PREFIX}/sbin/postfwd2
+ ${INSTALL_SCRIPT} ${WRKSRC}/sbin/postfwd3 ${PREFIX}/sbin/postfwd3
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/postfwd/
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/postfwd/plugins/
${INSTALL_DATA} ${WRKSRC}/etc/postfwd.cf.sample ${PREFIX}/share/examples/postfwd/postfwd.cf.sample
@@ -34,9 +36,10 @@ do-install:
${INSTALL_SCRIPT} ${WRKSRC}/tools/postfwd-client.pl ${PREFIX}/bin/postfwd-client.pl
${INSTALL_SCRIPT} ${WRKSRC}/tools/rblcheck.pl ${PREFIX}/bin/rblcheck.pl
${INSTALL_SCRIPT} ${WRKSRC}/tools/hapolicy/hapolicy ${PREFIX}/sbin/hapolicy
- ${INSTALL_DATA} ${WRKSRC}/doc/postfwd2* ${PREFIX}/share/doc/postfwd/
+ ${INSTALL_DATA} ${WRKSRC}/doc/postfwd3* ${PREFIX}/share/doc/postfwd/
${INSTALL_DATA} ${WRKSRC}/tools/hapolicy/hapolicy.* ${PREFIX}/share/doc/postfwd/
${INSTALL_DATA} ${WRKSRC}/tools/request.sample ${PREFIX}/share/doc/postfwd/request.sample
${INSTALL_MAN} ${WRKSRC}/man/man8/postfwd2.8 ${PREFIX}/man/man8/postfwd2.8
+ ${INSTALL_MAN} ${WRKSRC}/man/man8/postfwd3.8 ${PREFIX}/man/man8/postfwd3.8
.include
Index: distinfo
===
RCS file: /var/cvs/ports/mail/postfwd/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo 8 Feb 2019 13:15:13 - 1.3
+++ distinfo 20 Mar 2019 07:57:53 -
@@ -1,2 +1,2 @@
-SHA256 (postfwd-1.39.tar.gz) = Vv0pJwHRlOC0CFdTnBi/Cu+pE+dpVzOOzeaR77aRuyU=
-SIZE (postfwd-1.39.tar.gz) = 408145
+SHA256 (postfwd-2.00.tar.gz) = RsRimDR7ZJ6LOHtxs1fBTei7DMcxHFVSvRRbqXUCn5A=
+SIZE (postfwd-2.00.tar.gz) = 265346
Index: patches/patch-sbin_postfwd3
===
RCS file: patches/patch-sbin_postfwd3
diff -N patches/patch-sbin_postfwd3
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-sbin_postfwd3 20 Mar 2019 08:01:39 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: sbin/postfwd3
+--- sbin/postfwd3.orig
sbin/postfwd3
+@@ -71,7 +71,7 @@ our %postfwd_settings = (
+ no_client_stdout => 1,
+ },
+ master => {
+- pid_file => "/var/tmp/$NAME-master.pid",
++ pid_file => "/var/run/$NAME-master.pid",
+ watchdog => 60,
+ failures => 7,
+ respawn => 4,
Index: pkg/PLIST
===
RCS file: /var/cvs/ports/mail/postfwd/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 8 Feb 2019 13:15:13 - 1.4
+++ pkg/PLIST 20 Mar 2019 08:08:17 -
@@ -2,19 +2,20 @@
@newgroup _postfwd:715
@newuser _postfwd:715:715:daemon:Postfwd Daemon:/var/empty:/sbin/nologin
@rcscript ${RCDIR}/postfwd2
+@rcscript ${RCDIR}/postfwd3
bin/postfwd-client.pl
bin/rblcheck.pl
@man man/man8/postfwd2.8
+@man man/man8/postfwd3.8
sbin/hapolicy
sbin/postfwd2
+sbin/postfwd3
share/doc/postfwd/
share/doc/postfwd/hapolicy.html
share/doc/postfwd/hapolicy.txt
-share/doc/postfwd/postfwd2-chroot.html
-share/doc/postfwd/postfwd2-chroot.txt
-share/doc/postfwd/postfwd2.CHANGELOG
-share/doc/postfwd/postfwd2.html
-share/doc/postfwd/postfwd2.txt
+share/doc/postfwd/postfwd3.CHANGELOG
+share/doc/postfwd/postfwd3.html
+share/doc/postfwd/postfwd3.txt
share/doc/postfwd/request.sample
share/examples/postfwd/
@sample ${SYSCONFDIR}/postfix/
Index: pkg/postfwd3.rc
===
RCS file: pkg/postfwd3.rc
diff -N pkg/postfwd3.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/postfwd3.rc 20 Mar 2019 08:03:22 -
@@ -0,0 +1,20 @@
+#!/bin/ksh
+#
+# $OpenBSD: postfwd3.rc,v 1.6 2018/01/11 19:27:03 rpe Exp $
+
+daemon="${TRUEPREFIX}/sbin/postfwd3"
+daemon_flags="-u _postfwd -g _postfwd -f ${SYSCONFDIR}/postfix/postfwd3.cf"
+
+. /etc/rc.d/rc.subr
+
+pexp="perl: ${daemon}${daemon_flags:+ ${daemon_flags}}"
+
+rc_stop() {
+ ${daemon} --stop
+}
+
+rc_reload() {
+ ${daemon} --hup
+}
+
+rc_cmd $1
Re: x11/gnome seems to fail to start with new user
On Sun, Mar 17, 2019 at 04:44:28PM -0700, Ryan Freeman wrote: > On Tue, Mar 05, 2019 at 10:40:48AM -0800, Ryan Freeman wrote: > > Hello! > > > > In testing my way around a www/chromium-related crash, I created > > a brand new test user. I was surprised to see that this fresh > > user, logging in from gdm, never makes it to gnome desktop. > > I've been checking this after every snapshot update, clean new user, > try and log in with this user from GDM, gnome-shell never makes it > to life. As of snapshot 2019/03/15 and matching packages, and > today (2019/03/17) snap. I can reproduce this on a fresh install with a user account in the default login class. The problem disappears if I move that user into login class 'staff'. I suppose the problem is that gjs's javescript engine wants to allocate more memory than the default limits allow for.
[NEW/WIP] Qflow porting // [7/7] opensta-20190320
Dear ports@ readers, this is a proposal for a new port: OpenSTA, the Parallax Static Timing Analyzer. DESCR = OpenSTA is a gate level static timing verifier. As a stand-alone executable it can be used to verify the timing of a design using standard file formats: - Verilog netlist - Liberty library - SDC timing constraints - SDF delay annotation - SPEF parasitics OpenSTA uses a TCL command interpreter to read the design, specify timing constraints and print timing reports. I knew this project since a couple of years and its porting was in my TODO list; but recently I noticed that the internal Qflow tool for static timing analysis is partially broken (already reported upstream, see [1]), so I decided to treat it as a Qflow dependency. Please note that it needs cudd (see [2], port is already ok sthen). To compile it, I only patched a file in order to change reinterpret_cast to static_cast. I also added some documentation with the post-install target (those files are in the upstream tarball, but it seems there is no way to install them through their Makefile). My main concern with the port is related to the license; although it is clear that the software is released under the GPLv3, as confirmed by all source code file headers, I'm puzzled; the README.md ends as follows: ## License Copyright (c) 2019, Parallax Software, Inc. All rights reserved. No part of this document may be copied, transmitted or disclosed in any form or fashion without the express written consent of Parallax Software, Inc. What do you think? Taking MAINTAINER, port's tarball attached. [1] http://opencircuitdesign.com/pipermail/eda-dev/2019-March/000127.html [2] https://marc.info/?l=openbsd-ports=155319441906710=2 -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: https://www.linkedin.com/in/delaurenzis/ opensta.tar.gz Description: application/gzip
scapy sniff IEEE802_11_RADIO
Hi, is it possible to set the data link layer in scapy for the interface to sniff on? I.e. what I do for tcpdump to sniff radiotap using -y IEEE802_11_RADIO I don't seem to find an option to tell it to change the mode, it seems it stays in EN10MB link layer mode? Maybe I'm just blind? cheers, Sebastian
Re: [NEW] cudd-3.0.0
Hello Stuart, On 22/03/2019 15:16, Stuart Henderson wrote: [...] Diff on top of yours. - fix fetches - it's c++ so use COMPILER Just for my comprehension, could you please elaborate a bit (or point me to the relevant manpage)? - it builds with or without doxygen, but if present during the configure run then it's needed during build, so add a build dep - get rid of "-release @PACKAGE_VERSION@" to remove the lib symlink; if other things were looking for 'cudd-3.0.0' then you'd probably want to keep it but it doesn't sound like that's the case - symlink is simpler than patching for gdiff with this added, OK sthen@ to import. [...] Works for me, no objections. Thanks a lot. -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: https://www.linkedin.com/in/delaurenzis/
Re: [NEW] cudd-3.0.0
On 2019/03/22 10:27, Alessandro DE LAURENZIS wrote:
> Hello Anthony,
>
> thanks a lot for your feedback.
>
> On 22/03/2019 06:16, Anthony J. Bentley wrote:
> > Hi Alessandro,
> >
> > Alessandro DE LAURENZIS writes:
> > > All tests are PASS, provided that we use gdiff(1) instead of diff(1) for
> > > the dddmp set.
> >
> > Careful...
> >
> > -# Store corresponding CNF in different format:
> > +# Store corresponding CNF in gdifferent format:
> > # NodeByNode method -> file 4.node1.tmp
> > # MaxtermByMaxterm -> file 4.max1.tmp
> > -# Best with different options:
> > +# Best with gdifferent options:
>
> Ooops. Fixed.
>
> >
> > > HOMEPAGE = https://sourceforge.net/projects/cudd-mirror/
> >
> > I think https://www.davidkebo.com/cudd is a better homepage. I would use
> > both SourceForge and https://www.davidkebo.com/source/cudd_versions/ in
> > MASTER_SITES.
>
> Actually David doesn't seem to be affiliated to the project in any way, and
> his page is just a tutorial (there are a few on the net).
>
> The most complete source I can find is a Github mirror:
>
> https://github.com/ivmai/cudd
>
> which contains a collection of the most recent releases and upstream's
> README as front page.
>
> I would suggest to switch to this as master site, but I'm facing issues in
> fetching the tarball: we're trying to download:
>
> https://github.com/ivmai/cudd/archive/3.0.0/cudd-3.0.0.tar.gz
>
> instead of:
>
> https://github.com/ivmai/cudd/archive/cudd-3.0.0.tar.gz
>
> I vaguely remember a similar problem some months ago... do we have to change
> something in ports' infrastructure?
>
> >
> > > One thing I'm not able to do is to force the name of the .so file to be
> > > libcudd.so.0.0, instead of libcudd-3.0.0.so.0.0. Could someone point me
> > > in the right direction?
> >
> > Well, it seems to create both. I suppose you could @comment out the
> > redundant library in PLIST, but personally I wouldn't bother; in ports
> > like textproc/apertium I just leave it be. Which one does OpenSTA pick up?
> >
>
> OpenSTA searches for libcudd-3.0.0.so.0.0 (so we would need
>
> WANTLIB += cudd-3.0.0
>
> which doesn't seem ideal to me, but maybe I'm wrong...).
>
> Also, I would prefer to add some documentation, given that it's available in
> the release (although not updated to the latest version), but I didn't find
> a way to do it using a target from the upstream's Makefile; I just added a
> post-install part in the port's one (this requires pdflatex, so I added
> print/texlive/base to BUILD_DEPENDS).
>
> Updated tarball (using GH_ACCOUNT/PROJECT/TAGNAME, so breaking 'make fetch')
> attached.
>
> --
> Alessandro DE LAURENZIS
> [mailto:jus...@atlantide.t28.net]
> Web: http://www.atlantide.t28.net
> LinkedIn: https://www.linkedin.com/in/delaurenzis/
Diff on top of yours.
- fix fetches
- it's c++ so use COMPILER
- it builds with or without doxygen, but if present during the configure
run then it's needed during build, so add a build dep
- get rid of "-release @PACKAGE_VERSION@" to remove the lib symlink;
if other things were looking for 'cudd-3.0.0' then you'd probably want
to keep it but it doesn't sound like that's the case
- symlink is simpler than patching for gdiff
with this added, OK sthen@ to import.
diff --git Makefile Makefile
index cb1d15c..c3314f0 100644
--- Makefile
+++ Makefile
@@ -2,13 +2,14 @@
COMMENT = Colorado University Decision Diagram
+V =3.0.0
GH_ACCOUNT = ivmai
GH_PROJECT = cudd
-GH_TAGNAME = 3.0.0
+GH_TAGNAME = cudd-$V
+DISTNAME = cudd-$V
CATEGORIES = devel
-SHARED_LIBS += cudd-${GH_TAGNAME} 0.0 # 0.0
SHARED_LIBS += cudd 0.0 # 0.0
MAINTAINER = Alessandro De Laurenzis
@@ -18,7 +19,10 @@ PERMIT_PACKAGE_CDROM = Yes
WANTLIB = ${COMPILER_LIBCXX} m
-BUILD_DEPENDS =print/texlive/base
+COMPILER = base-clang ports-gcc base-gcc
+
+BUILD_DEPENDS =devel/doxygen \
+ print/texlive/base
CONFIGURE_STYLE = gnu
@@ -32,4 +36,7 @@ post-install:
${INSTALL_DATA} ${WRKSRC}/doc/cudd.pdf ${PREFIX}/share/doc/cudd
${INSTALL_DATA} ${WRKSRC}/doc/phase.pdf ${PREFIX}/share/doc/cudd
+pre-test:
+ ln -s ${LOCALBASE}/bin/gdiff ${WRKDIR}/bin/diff
+
.include
diff --git distinfo distinfo
index 28e2db0..cfe8ddd 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (cudd-3.0.0.tar.gz) = uOlmtFYslqA+f76iOXKVh9ezldU8rcw5pyA7Sc9+62k=
-SIZE (cudd-3.0.0.tar.gz) = 1175302
+SHA256 (cudd-3.0.0.tar.gz) = X+FFBBxZRonm589M1iPV8rfDYmFwi+jJpyrtcs9nrM4=
+SIZE (cudd-3.0.0.tar.gz) = 1170745
diff --git pkg/PLIST pkg/PLIST
index aae6309..02d57dd 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -1,6 +1,5 @@
@comment $OpenBSD: PLIST,v$
include/cudd.h
-@lib lib/libcudd-3.0.0.so.${LIBcudd-3.0.0_VERSION}
lib/libcudd.a
lib/libcudd.la
@lib lib/libcudd.so.${LIBcudd_VERSION}
diff --git patches/patch-Makefile_in patches/patch-Makefile_in
new file mode
Re: NEW: audio/portmidi (unbreak audacity)
On Fri, Mar 22 2019, Theo Buehler wrote: >> Thanks, I can't test the actual functionality but I think that portmidi >> is ready to be imported. Could I please get reviews/oks to import? > > You could also give rapha@ an ok to import :) Woops, right, thank you. 8) Raphael: ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: NEW: audio/portmidi (unbreak audacity)
On Fri, Mar 22, 2019 at 02:47:22PM +0100, Theo Buehler wrote: > > Thanks, I can't test the actual functionality but I think that portmidi > > is ready to be imported. Could I please get reviews/oks to import? > > You could also give rapha@ an ok to import :) I'm OK with the portmidi diff. The midi bits could be improved later in tree. I tested audacity, and it works fine, so I'm OK as well for it.
Re: NEW: audio/portmidi (unbreak audacity)
> Thanks, I can't test the actual functionality but I think that portmidi > is ready to be imported. Could I please get reviews/oks to import? You could also give rapha@ an ok to import :)
Re: NEW: audio/portmidi (unbreak audacity)
Back to this, On Tue, Mar 12 2019, Raphael Graf wrote: > On Sun, Mar 10, 2019 at 08:06:59PM +0100, Jeremie Courreges-Anglas wrote: >> On Sun, Mar 10 2019, Raphael Graf wrote: >> > The attached portmidi.tar.gz contains a port of the newest release from >> > 2010. >> > I've added very rudimentary and incomplete support for sndio, it's just >> > enough >> > for playing a midi track via audacity. The sndio stuff is in >> > files/pm_sndio/. >> > It is extremely simple compared to the alsa version (pm_linux). :) >> >> Please comments below, >> >> > Audacity can then use the shared portmidi library instead of the bundled >> > version. The attached audacity.diff does that. >> > It seems to work ok, I've tested midi playback in audacity using >> > fluidsynth. >> >> I'm not sure I understand the rationale for all the changes contained in >> the audacity diff, but it definitely looks like an improvement! Sadly >> it doesn't apply any more, now that audacity has been updated to 2.3.1 >> by Antoine. > > Attached is an new diff for audacity 2.3.1. > It works for me on amd64/i386, I couldn't test on other archs yet. > I didn't manage to make it work without the do-gen step, mainly because > some of the libs (e.g. FileDialog) where wrongly built as shared libs > instead of static libs. > Any help on improving the patches is welcome. ack. I may have some tweaks but the changes look sane overall. audacity seemed to run fine in my (limited) tests. >> > Any thoughts or comments? >> >> Regarding portmidi: >> - SHARED_LIBS should start at 0.0 (if only because it tends to prove >> that SHARED_LIBS is honored) >> - java is still needed even if you don't include the pm_java subdir >> and the jni lib is built unconditionally, this is bad for !(x86). >> I think the easiest way to handle it is just to force-disable all >> java-related stuff for now. >> - what is the rationale for the .pc file? Do other distros provide it >> and does audacity depend on it? Is "Version: 1.0" what the ecosystem >> expect? > > The .pc file is not provided by other distros, but audacity depends on it. > Building audacity with '-with-portmidi=system' probably never worked. > (see this thread: > https://sourceforge.net/p/audacity/mailman/message/36095045/) > Of course, the .pc file should be upstreamed if possible.. > You are right that "Version: 1.0" doesn't make any sense. In the attached > tarball, i've changed it to "Version: 217". Thanks, I can't test the actual functionality but I think that portmidi is ready to be imported. Could I please get reviews/oks to import? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [NEW] cudd-3.0.0
Hello, On 22/03/2019 10:27, Alessandro DE LAURENZIS wrote: Hello Anthony, thanks a lot for your feedback. On 22/03/2019 06:16, Anthony J. Bentley wrote: Hi Alessandro, Alessandro DE LAURENZIS writes: All tests are PASS, provided that we use gdiff(1) instead of diff(1) for the dddmp set. Careful... -# Store corresponding CNF in different format: +# Store corresponding CNF in gdifferent format: # NodeByNode method -> file 4.node1.tmp # MaxtermByMaxterm -> file 4.max1.tmp -# Best with different options: +# Best with gdifferent options: Ooops. Fixed. HOMEPAGE = https://sourceforge.net/projects/cudd-mirror/ I think https://www.davidkebo.com/cudd is a better homepage. I would use both SourceForge and https://www.davidkebo.com/source/cudd_versions/ in MASTER_SITES. Actually David doesn't seem to be affiliated to the project in any way, and his page is just a tutorial (there are a few on the net). The most complete source I can find is a Github mirror: https://github.com/ivmai/cudd which contains a collection of the most recent releases and upstream's README as front page. I would suggest to switch to this as master site, but I'm facing issues in fetching the tarball: we're trying to download: https://github.com/ivmai/cudd/archive/3.0.0/cudd-3.0.0.tar.gz instead of: https://github.com/ivmai/cudd/archive/cudd-3.0.0.tar.gz I vaguely remember a similar problem some months ago... do we have to change something in ports' infrastructure? One thing I'm not able to do is to force the name of the .so file to be libcudd.so.0.0, instead of libcudd-3.0.0.so.0.0. Could someone point me in the right direction? Well, it seems to create both. I suppose you could @comment out the redundant library in PLIST, but personally I wouldn't bother; in ports like textproc/apertium I just leave it be. Which one does OpenSTA pick up? OpenSTA searches for libcudd-3.0.0.so.0.0 (so we would need WANTLIB += cudd-3.0.0 which doesn't seem ideal to me, but maybe I'm wrong...). I was wrong; OpenSTA picks libcudd.so.0.0 up (but still needs WANTLIB+=cudd-3.0.0 for a clean port-lib-depends-check) Also, I would prefer to add some documentation, given that it's available in the release (although not updated to the latest version), but I didn't find a way to do it using a target from the upstream's Makefile; I just added a post-install part in the port's one (this requires pdflatex, so I added print/texlive/base to BUILD_DEPENDS). Updated tarball (using GH_ACCOUNT/PROJECT/TAGNAME, so breaking 'make fetch') attached. -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: https://www.linkedin.com/in/delaurenzis/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2019/03/22 05:23:50 Modified files: www/goaccess : Makefile Log message: Add TLS support. Patch and request from Josh Grosse.
Re: Update: sysutils/py-scandir 1.9.0 -> 1.10.0
OK mariani@
On Wed, Mar 20, 2019 at 7:44 PM Kurt Mosiejczuk wrote:
>
> On Wed, Mar 20, 2019 at 11:25:59PM +0100, Klemens Nanni wrote:
>
> > OK kn
>
> > > @@ -32,7 +32,6 @@ TEST_DEPENDS += devel/py-unittest2
> > > .endif
>
> > > do-test:
> > > - cd ${WRKSRC}/test &&\
> > > - env LC_ALL=C.UTF-8 LANG=C.UTF-8 ${MODPY_BIN} run_tests.py
> > > + cd ${WRKSRC}/test && ${SETENV} ${ALL_TEST_ENV} ${MODPY_BIN}
> > > run_tests.py
> > How about omitting this hunk from the update and commit it separately,
> > possibly in a bulk with other test conversions now that remi has landed
> > your final MODPY_PYTEST bits?
>
> We could. I only submitted this one because it isn't actually using
> MODPY_PYTEST. It is running its own tests. I was just taking advantage of
> the fact that we set TEST_ENV to include en_US.UTF-8. I have others I
> have been updating that I haven't submitted yet because MODPY_PYTEST
> hadn't gone in yet. :)
>
> --Kurt
>
Re: UPDATE: security/john-jumbo
Hi,
Am Dienstag, März 05, 2019 14:44 CET, "Sebastian Reitenbach"
schrieb:
> Hi,
>
> I was in need to crack some hashes that our john-jumbo doesn't have yet.
> Since there is no new release since it was imported, I updated it to a more
> recent git checkout. It's from beginning of February, since then, it works
> for me. Of the >400 tests, ran on amd64 and i386, one fails sometimes, other
> than that, it works quite well for me. While here, take MAINTAINER.
>
> any comments, rants, suggestions, or tests, or even OKs welcome.
>
anyone? Updated patch now with a newer checkout.
cheers,
Sebastian
Index: Makefile
===
RCS file: /cvs/ports/security/john-jumbo/Makefile,v
retrieving revision 1.20
diff -u -p -u -r1.20 Makefile
--- Makefile18 Nov 2018 21:09:47 - 1.20
+++ Makefile22 Mar 2019 09:22:44 -
@@ -5,27 +5,27 @@ BROKEN-alpha =DES_bs.c:173: internal co
FIX_EXTRACT_PERMISSIONS=Yes
V =1.8.0
-JV = 1
-REVISION = 3
-EXTRACT_SUFX = .tar.xz
+JV = 1.20190321
DISTNAME = john-$V-jumbo-${JV}
PKGNAME = john-jumbo-$V.${JV}
+GH_ACCOUNT = magnumripper
+GH_PROJECT = JohnTheRipper
+GH_COMMIT =6e8096ccdb4d2dbf00aa85da370f9e8524f306a2
CATEGORIES = security
-HOMEPAGE = http://www.openwall.com/john/
+HOMEPAGE = https://www.openwall.com/john/
+MAINTAINER = Sebastian Reitenbach
# files from various authors; see license review txt file
PERMIT_PACKAGE_CDROM = see doc/john-1.7.9-jumbo-7-licensing.txt
PERMIT_PACKAGE_FTP = Yes
-WANTLIB += c crypto m nspr4 nss3 pcap plc4 plds4 pthread smime3
-WANTLIB += nssutil3 sqlite3 ssl ssl3 z
+WANTLIB += c crypto m nspr4 nss3 pcap plc4 plds4 smime3
+WANTLIB += nssutil3 ssl ssl3 z
-MASTER_SITES = http://www.openwall.com/john/j/
-LIB_DEPENDS = databases/sqlite3 \
- security/nss
+LIB_DEPENDS = security/nss
USE_GMAKE =Yes
MAKE_FILE =Makefile.legacy
@@ -69,17 +69,18 @@ ALL_TARGET= openbsd-sparc64
ALL_TARGET=generic
.endif
-BINS += SIPdump calc_stat cprepair genmkvpwd luks2john makechr
-BINS += mkvcalcproba raw2dyna tgtsnarf uaf2john vncpcap2john wpapcap2john
+BINS += SIPdump calc_stat cprepair genmkvpwd hccap2john makechr mkvcalcproba
+BINS += racf2john raw2dyna relbench stats tgtsnarf uaf2john vncpcap2john
wpapcap2john
do-configure:
perl -pi -e 's,\$$JOHN/john.conf,${SYSCONFDIR}/john.conf,'
${WRKSRC}/params.h
rm ${WRKSRC}/KRB4_*_plug.c # no old DES API support in LibreSSL
- rm ${WRKSRC}/rawSHA0_fmt_plug.c # no SHA-0 support in LibreSSL
do-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/john
+ ${INSTALL_DATA_DIR} ${PREFIX}/libdata/perl5/site_perl
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/john
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/john/rules
${INSTALL_PROGRAM} ${WRKDIST}/run/john ${PREFIX}/bin
cd ${WRKDIST}/run; ${INSTALL_PROGRAM} ${BINS} ${PREFIX}/bin
${INSTALL_SCRIPT} ${WRKDIST}/run/mailer \
@@ -88,6 +89,10 @@ do-install:
ln -sf john ${PREFIX}/bin/`basename $$i`; done
${INSTALL_DATA} ${WRKDIST}/run/*.{chr,conf,lst} \
${PREFIX}/share/examples/john
+ ${INSTALL_DATA} ${WRKDIST}/run/rules/*.rule \
+ ${PREFIX}/share/examples/john/rules/
+ ${INSTALL_DATA} ${WRKDIST}/run/lib/*.pm \
+ ${PREFIX}/libdata/perl5/site_perl/
${INSTALL_DATA} ${WRKDIST}/doc/* ${PREFIX}/share/doc/john
# not using TEST_TARGET as it gets confused by the quotes in CFLAGS
Index: distinfo
===
RCS file: /cvs/ports/security/john-jumbo/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo16 Jan 2015 15:40:01 - 1.3
+++ distinfo22 Mar 2019 09:22:44 -
@@ -1,2 +1,2 @@
-SHA256 (john-1.8.0-jumbo-1.tar.xz) =
usk9AlmVoFHwVa29fOLxl1Z2ysbHSmx6PuTP3ZwWCSM=
-SIZE (john-1.8.0-jumbo-1.tar.xz) = 23232492
+SHA256 (john-1.8.0-jumbo-1.20190321-6e8096cc.tar.gz) =
jiZPuEunkAui6+Yyk3VrtZY1LsmrGi4YfLQTvoTcoOY=
+SIZE (john-1.8.0-jumbo-1.20190321-6e8096cc.tar.gz) = 47181582
Index: patches/patch-src_Makefile_legacy
===
RCS file: /cvs/ports/security/john-jumbo/patches/patch-src_Makefile_legacy,v
retrieving revision 1.2
diff -u -p -u -r1.2 patch-src_Makefile_legacy
--- patches/patch-src_Makefile_legacy 24 Apr 2018 18:10:55 - 1.2
+++ patches/patch-src_Makefile_legacy 22 Mar 2019 09:22:44 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-src_Makefile_legacy,v 1.
Index: src/Makefile.legacy
--- src/Makefile.legacy.orig
+++ src/Makefile.legacy
-@@ -1073,11 +1073,9 @@ openbsd-alpha:
+@@ -916,11 +916,9 @@ openbsd-alpha:
openbsd-sparc64:
$(LN) sparc64.h arch.h
@echo "#define JOHN_BLD" '"'$@'"' > john_build_rule.h
@@ -16,7 +16,7 @@ Index:
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/03/22 04:44:18 Modified files: textproc/pugixml: Makefile distinfo Log message: Update to pugixml-1.9 While here, move HOMEPAGE to https (suggested by cwen@). ok sthen@ (maintainer)
Re: NEW: security/reaver
On 2019/03/20 23:07, Sebastian Reitenbach wrote:
> HI Stuart,
> Am Mittwoch, März 20, 2019 12:33 CET, Stuart Henderson
> schrieb:
>
> > On 2019/03/20 00:05, Sebastian Reitenbach wrote:
> > > Hi,
> > >
> > > attached a port of reaver, online WPS PIN cracker.
> > >
> > > Reaver implements a brute force attack against Wifi Protected Setup (WPS)
> > > registrar PINs in order to recover WPA/WPA2 passphrases, as described in
> > > Brute forcing Wi-Fi Protected Setup When poor design meets poor
> > > implementation. by Stefan Viehböck.
> > > Reaver has been designed to be a robust and practical attack against
> > > Wi-Fi Protected Setup (WPS) registrar PINs in order to recover WPA/WPA2
> > > passphrases and has been tested against a wide variety of access points
> > > and WPS implementations.
> > > Depending on the target's Access Point (AP), to recover the plain text
> > > WPA/WPA2 passphrase the average amount of time for the transitional
> > > online brute force method is between 4-10 hours. In practice, it will
> > > generally take half this time to guess the correct WPS pin and recover
> > > the passphrase. When using the offline attack, if the AP is vulnerable,
> > > it may take only a matter of seconds to minutes.
> > >
> > > tested and works for me on i386, with athn(4) interface.
> > >
> > > any comments, concerns, test or even OKs welcome.
> >
> > @sample /var/reaver/
> >
> > probably missing some @extra or @extraunexec?
> >
> updated version attached, replaced the @sample with @extra and @extraunexec
> as you pointed out.
>
> OK?
> cheers,
> Sebastian
ok with the diff below added.
diff --git Makefile Makefile
index 4b0cba1..26e842b 100644
--- Makefile
+++ Makefile
@@ -24,4 +24,7 @@ CONFIGURE_STYLE = gnu
WRKSRC=${WRKDIST}/src
+post-install:
+ ${INSTALL_MAN} ${WRKDIST}/docs/reaver.1 ${PREFIX}/man/man1/
+
.include
diff --git pkg/PLIST pkg/PLIST
index 0830397..1896024 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -1,5 +1,6 @@
@comment $OpenBSD: PLIST,v$
@bin bin/reaver
@bin bin/wash
-@extra /var/reaver/
-@extraunexec rm -rf /var/reaver/
+@extraunexec rm -f ${LOCALSTATEDIR}/reaver/*
+@man man/man1/reaver.1
+@sample ${LOCALSTATEDIR}/reaver/
Re: NEW: security/reaver
On Wed, 20 Mar 2019 at 23:07:23 +0100, Sebastian Reitenbach wrote: > HI Stuart, > Am Mittwoch, März 20, 2019 12:33 CET, Stuart Henderson > schrieb: > > > On 2019/03/20 00:05, Sebastian Reitenbach wrote: > > > Hi, > > > > > > attached a port of reaver, online WPS PIN cracker. > > > > > > Reaver implements a brute force attack against Wifi Protected Setup (WPS) > > > registrar PINs in order to recover WPA/WPA2 passphrases, as described in > > > Brute forcing Wi-Fi Protected Setup When poor design meets poor > > > implementation. by Stefan Viehböck. > > > Reaver has been designed to be a robust and practical attack against > > > Wi-Fi Protected Setup (WPS) registrar PINs in order to recover WPA/WPA2 > > > passphrases and has been tested against a wide variety of access points > > > and WPS implementations. > > > Depending on the target's Access Point (AP), to recover the plain text > > > WPA/WPA2 passphrase the average amount of time for the transitional > > > online brute force method is between 4-10 hours. In practice, it will > > > generally take half this time to guess the correct WPS pin and recover > > > the passphrase. When using the offline attack, if the AP is vulnerable, > > > it may take only a matter of seconds to minutes. > > > > > > tested and works for me on i386, with athn(4) interface. > > > > > > any comments, concerns, test or even OKs welcome. > > > > @sample /var/reaver/ > > > > probably missing some @extra or @extraunexec? > > > updated version attached, replaced the @sample with @extra and @extraunexec > as you pointed out. > > OK? > cheers, > Sebastian OK gonzalo@ -- Sending from my toaster.
Re: [NEW] cudd-3.0.0
Hello Anthony, thanks a lot for your feedback. On 22/03/2019 06:16, Anthony J. Bentley wrote: Hi Alessandro, Alessandro DE LAURENZIS writes: All tests are PASS, provided that we use gdiff(1) instead of diff(1) for the dddmp set. Careful... -# Store corresponding CNF in different format: +# Store corresponding CNF in gdifferent format: # NodeByNode method -> file 4.node1.tmp # MaxtermByMaxterm -> file 4.max1.tmp -# Best with different options: +# Best with gdifferent options: Ooops. Fixed. HOMEPAGE = https://sourceforge.net/projects/cudd-mirror/ I think https://www.davidkebo.com/cudd is a better homepage. I would use both SourceForge and https://www.davidkebo.com/source/cudd_versions/ in MASTER_SITES. Actually David doesn't seem to be affiliated to the project in any way, and his page is just a tutorial (there are a few on the net). The most complete source I can find is a Github mirror: https://github.com/ivmai/cudd which contains a collection of the most recent releases and upstream's README as front page. I would suggest to switch to this as master site, but I'm facing issues in fetching the tarball: we're trying to download: https://github.com/ivmai/cudd/archive/3.0.0/cudd-3.0.0.tar.gz instead of: https://github.com/ivmai/cudd/archive/cudd-3.0.0.tar.gz I vaguely remember a similar problem some months ago... do we have to change something in ports' infrastructure? One thing I'm not able to do is to force the name of the .so file to be libcudd.so.0.0, instead of libcudd-3.0.0.so.0.0. Could someone point me in the right direction? Well, it seems to create both. I suppose you could @comment out the redundant library in PLIST, but personally I wouldn't bother; in ports like textproc/apertium I just leave it be. Which one does OpenSTA pick up? OpenSTA searches for libcudd-3.0.0.so.0.0 (so we would need WANTLIB += cudd-3.0.0 which doesn't seem ideal to me, but maybe I'm wrong...). Also, I would prefer to add some documentation, given that it's available in the release (although not updated to the latest version), but I didn't find a way to do it using a target from the upstream's Makefile; I just added a post-install part in the port's one (this requires pdflatex, so I added print/texlive/base to BUILD_DEPENDS). Updated tarball (using GH_ACCOUNT/PROJECT/TAGNAME, so breaking 'make fetch') attached. -- Alessandro DE LAURENZIS [mailto:jus...@atlantide.t28.net] Web: http://www.atlantide.t28.net LinkedIn: https://www.linkedin.com/in/delaurenzis/ cudd.tar.gz Description: application/gzip
Re: opencv2: graphics/digikam-kde4
On Mon Mar 11, 2019 at 09:32:29PM +0100, Rafael Sadowski wrote:
> Diff to use opencv2 and some tweaks:
>
> - fix MASTER_SITE
> - s/https/https/
> - dependencies
> - regen PLIST
>
> RS
>
Unfortunately, we can't get rid of opencv2. That's okay, so digikam4
doesn't lose any of its functionality.
I found a way to get rid of x11/kde-applications/{libkgeomap,libkface}.
digikam comes with libkface and libkgeomap so let's build them as multi
packages and update with a simple REVISION bump.
Whats new:
- New multi packages: face an geomap which will update/replace
x11/kde-applications/{libkgeomap,libkface}. Tested with pkg_add(1) -u
I tested it out so I want to go. Any objections?
I have one more question. Can we rename the port in the update process?
My imagination:
1) Someone who has digikam (graphics/digikam-kde4) installed gets
digikam-kde4 (renamed) through the update.
2) Someone who want to install digikam "pkg_add digikam" gets the
upcoming digikam 5 port?
Is that possible?
RS
Index: Makefile
===
RCS file: /cvs/ports/graphics/digikam-kde4/Makefile,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 Makefile
--- Makefile29 Jun 2018 22:16:16 - 1.30
+++ Makefile22 Mar 2019 06:53:24 -
@@ -1,26 +1,30 @@
# $OpenBSD: Makefile,v 1.30 2018/06/29 22:16:16 espie Exp $
-COMMENT-kipi = KDE image plugins collection
-COMMENT-main = KDE photo management utility
-COMMENT-mediawiki =KIPI interface for MediaWiki
+COMMENT-face = face detection library for KDE4
+COMMENT-geomap = library for mapping photos on maps for KDE4
+COMMENT-kipi = KDE4 image plugins collection
+COMMENT-main = KDE4 photo management utility
+COMMENT-mediawiki =KIPI4 interface for MediaWiki
CATEGORIES = graphics
-HOMEPAGE = http://www.digikam.org/
+HOMEPAGE = https://www.digikam.org/
VERSION = 4.13.0
DISTNAME = digikam-${VERSION}
PKGSPEC-main = digikam->=1
PKGSPEC-kipi = kipi-plugins->=1
+PKGNAME-face = libkface-15.08.3
+PKGNAME-geomap = libkgeomap-15.08.3
PKGNAME-kipi = kipi-plugins-${VERSION}
PKGNAME-main = ${PKGNAME}
PKGNAME-mediawiki =libmediawiki-1.0.0
-REVISION-main =5
-REVISION-kipi =6
-REVISION-mediawiki = 6
-
-EXTRACT_SUFX = .tar.bz2
+REVISION-main =6
+REVISION-kipi =7
+REVISION-mediawiki = 7
+REVISION-face= 3
+REVISION-geomap= 4
# LGPL, GPL and many others
PERMIT_PACKAGE_CDROM = Yes
@@ -29,11 +33,13 @@ SHARED_LIBS = kipiplugins 0.1
SHARED_LIBS += digikamcore0.1
SHARED_LIBS += digikamdatabase0.1
SHARED_LIBS += mediawiki 0.1
+SHARED_LIBS += kface 0.1 # 3.0
+SHARED_LIBS += kgeomap 0.1 # 2.1
-MASTER_SITES = ${MASTER_SITE_KDE:=stable/digikam/} \
- ${MASTER_SITE_KDE:=Attic/digikam/}
+MULTI_PACKAGES = -main -face -geomap -kipi -mediawiki
-MULTI_PACKAGES = -main -kipi -mediawiki
+MASTER_SITES = ${MASTER_SITE_KDE:=Attic/digikam/}
+EXTRACT_SUFX = .tar.bz2
MODULES = x11/kde4 multimedia/phonon
@@ -55,10 +61,11 @@ WANTLIB-kipi += ${KDE4LIB}/kio ${KDE4LIB
WANTLIB-kipi += ${KDE4LIB}/ksane
WANTLIB-kipi += ${KDE4LIB}/nepomuk ${KDE4LIB}/nepomukutils ${KDE4LIB}/solid
WANTLIB-kipi += ${KDE4LIB}/threadweaver
-WANTLIB-kipi += opencv_core opencv_highgui opencv_imgproc opencv_objdetect
+WANTLIB-kipi += lib/opencv2/opencv_core lib/opencv2/opencv_highgui
+WANTLIB-kipi += lib/opencv2/opencv_imgproc lib/opencv2/opencv_objdetect
WANTLIB-kipi += exslt gdk_pixbuf-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gpod
WANTLIB-kipi += gthread-2.0 intl jpeg
-WANTLIB-kipi += qjson kgeomap kqoauth kvkontakte mediawiki png qca soprano
+WANTLIB-kipi += qjson kqoauth kvkontakte png16 qca soprano
WANTLIB-kipi += tiff xml2 xslt MagickCore-6.Q16
WANTLIB-kipi += QtGLib-2.0 QtGStreamer-1.0 QtGStreamerUtils-1.0
@@ -76,14 +83,35 @@ WANTLIB-main += ${KDE4LIB}/kpimutils ${K
WANTLIB-main += ${KDE4LIB}/kresources ${KDE4LIB}/kutils
WANTLIB-main += ${KDE4LIB}/nepomuk ${KDE4LIB}/nepomukutils
WANTLIB-main += ${KDE4LIB}/solid ${KDE4LIB}/threadweaver
-WANTLIB-main += opencv_calib3d opencv_contrib opencv_core opencv_features2d
-WANTLIB-main += opencv_flann opencv_gpu opencv_highgui opencv_imgproc
-WANTLIB-main += opencv_legacy opencv_ml opencv_nonfree opencv_objdetect
-WANTLIB-main += opencv_ocl opencv_photo opencv_video
WANTLIB-main += akonadi-contact akonadi-kde baloocore baloofiles baloopim
-WANTLIB-main += balooqueryparser exif gphoto2 gphoto2_port jasper jpeg
-WANTLIB-main += kface kgeomap lcms2 lensfun lqr-1 pgf png qca soprano
+WANTLIB-main += balooqueryparser gphoto2 gphoto2_port jasper jpeg
+WANTLIB-main += lcms2 lensfun lqr-1 pgf png16 soprano
WANTLIB-main
