Re: [NEW] devel/p5-Sub-Exporter-ForMethods 0.100052
On Mon, Feb 11, 2019 at 11:26:14AM +, Stuart Henderson wrote:
> On 2019/02/11 08:57, Solene Rapenne wrote:
> > On Fri, Feb 08, 2019 at 08:55:51PM +0100, Charlene Wendling wrote:
> > >
> > > I'm proposing here a new port, devel/p5-Sub-Exporter-ForMethods, that
> > > will be required to upgrade devel/p5-MooseX-Types.
> > >
> > > It has been created by portgen, i've just modified DESCR. 'make test'
> > > passes. There is not much to say about it, the module is ~20 SLOC ;)
> > >
> > >
> > > Comment:
> > > helper routines for using Sub::Exporter to build methods
> > >
> > > Description:
> > > This module provides helper routines for using Sub::Exporter to
> > > build methods.
> > >
> > >
> > > Comments and feedback are welcome.
> > >
> > > Charlène.
> >
> > Running update-plist adds missing directories
>
> Hmm, it shouldn't - ${P5SITE}/Sub/Exporter/ is provided by
> devel/p5-Sub-Exporter which is in RUN_DEPENDS so update-plist strips
> it from the plist.
>
> $ make plist
> ===> Updating plist for p5-Sub-Exporter-ForMethods-0.100052
> Reading existing plist for p5-Sub-Exporter-ForMethods-0.100052
> Scanning /usr/obj/ports/p5-Sub-Exporter-ForMethods-0.100052/fake-amd64
> Figuring out tie points
> Tieing loose objects
> Copying objects
> Stripping directories from devel/p5-Sub-Exporter
> Stripping directories from devel/p5-Sub-Install
>
I was missing "keepenv" in my doas.conf solene as root
it was somewhat working but did yiel some messages like "DON'T BUILD PORTS
AS ROOT" and did not see it.
Re: lang/gcc/8 can't build x11/qt4
On Wed, 30 Jan 2019 21:15:27 +0100 Landry Breuil wrote: > On that point, debian is planning to remove qt4 from the upcoming > stable: > https://lists.debian.org/debian-devel-announce/2017/08/msg6.html > https://wiki.debian.org/Qt4Removal FreeBSD wants to remove qt4 in about a month, on 15 March: https://reviews.freebsd.org/D17741 OpenBSD has not removed x11/qt3, so I don't predict that OpenBSD would remove qt4. I would suggest to build qt4 without QtWebKit, because that would need fewer patches; but I see 3 ports (geo/gpsbabel geo/merkaartor geo/qlandkartegt) that want QtWebKit from qt4. OpenBSD's math/eigen3 has a build dependency on x11/qt4. Debian, FreeBSD and NetBSD seem to avoid this dependency, so Debian and FreeBSD might keep eigen3 after removing qt4. There are probably more packages that lang/gcc/8 can't build, but the only ones that I know are x11/qt4 and games/stone-soup. Our stone-soup is an old version; an update might fix it. -- George Koehler
Re: UPDATE: lang/flang 7.0.1
On 2/12/19 5:22 PM, Brian Callahan wrote:
On 2/12/19 5:05 PM, Jeremie Courreges-Anglas wrote:
On Tue, Feb 12 2019, Brian Callahan wrote:
On 2/1/19 4:35 PM, Brian Callahan wrote:
Hi ports --
Every time we update LLVM, flang needs to be updated and it takes me
some time to get it done.
Regarding this, do you want some time for the next major upgrades?
I wasn't able to coordinate with the LLVM update this time around and
I don't think flang should hold up LLVM updates so I'm fine with flang
playing catch-up.
It's done now. The patch is attached.
Some notes:
1. Haven't turned arm64 back on. I expect it to work but would like to
compile/run test it first instead of blindly turning it on.
arm64 bulk builds take ~4 days, I don't think phessler and arm64 users
will mind.
I tried it myself and things are still broken on arm64 so I'll have to
talk to the flang people...
2. flang-7 wants to use -lLLVM and build and link to its own separate
libclang.so. I don't want to do either of those things to avoid
potential conflicts, so I've disabled building libclang.so and
ham-fisted a replacement for -lLLVM-7 in a post-configure target,
forcing it to use the LLVM static libs. This creates a very huge
(>80MB) binary. But I think this is fine since the only archs that
flang works on are amd64 and arm64 anyway.
3. Everything is good with the NIST Fortran 77 test suite.
Tests appreciated.
~Brian
No Fortran people? I will just commit it then...
I would not know what to test! If only flang was a possible choice in
fortran.port.mk... :)
I use this: http://www.fortran-2000.com/ArnaudRecipes/fcvs21_f95.html
Specifically, the modified version that conforms to F95.
But yes, thanks for reminding me that we might want to add flang to
fortran.port.mk
~Brian
New patch attached that re-enabled flang on arm64. I'm going to commit
this shortly if I don't hear anything.
~Brian
Index: Makefile.inc
===
RCS file: /cvs/ports/lang/flang/Makefile.inc,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile.inc
--- Makefile.inc 30 Jan 2019 00:30:09 - 1.5
+++ Makefile.inc 13 Feb 2019 02:26:45 -
@@ -2,8 +2,6 @@
# Also ppc64le
ONLY_FOR_ARCHS = amd64 arm64
-BROKEN = needs updating for llvm-7.0.1, being worked on
-#BROKEN-arm64 = see flang issue 557, temporary
CATEGORIES ?= lang
Index: driver/Makefile
===
RCS file: /cvs/ports/lang/flang/driver/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- driver/Makefile 25 Jan 2019 20:06:48 - 1.13
+++ driver/Makefile 13 Feb 2019 02:26:45 -
@@ -1,14 +1,13 @@
# $OpenBSD: Makefile,v 1.13 2019/01/25 20:06:48 bcallah Exp $
# If you are updating to a new version
-# (e.g. 6.0->6.1 or 7.0), you need to sync
+# (e.g. 7.0->7.1 or 8.0), you need to sync
# patches with devel/llvm
COMMENT = LLVM Fortran compiler driver
-DISTNAME = flang-driver-6.0.0.20181012
-REVISION = 0
+DISTNAME = flang-driver-7.0.1.20181218
GH_PROJECT = flang-driver
-GH_COMMIT = f90d905b99ef497cc654b4a8433f1ac35a870f11
+GH_COMMIT = 24bd54da5c41af04838bbe7b68f830840d47fc03
WANTLIB += ${COMPILER_LIBCXX} c m z
@@ -21,8 +20,16 @@ MODULES = devel/cmake \
BUILD_DEPENDS = devel/llvm \
textproc/libxml
+CONFIGURE_ARGS = -DLIBCLANG_BUILD_STATIC=On
+
pre-configure:
@${SUBST_CMD} ${WRKSRC}/lib/Driver/ToolChains/OpenBSD.cpp
+
+# Don't use the LLVM shared library.
+post-configure:
+ sed -i \
+ 's,-lLLVM-7,`llvm-config --libs all --link-static --ignore-libllvm` -lz,g' \
+ ${WRKBUILD}/build.ninja
# We don't want yet another copy of clang and its utilities on the system.
# Doubly true since flang is statically linked to its clang libs.
Index: driver/distinfo
===
RCS file: /cvs/ports/lang/flang/driver/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- driver/distinfo 16 Oct 2018 14:56:38 - 1.10
+++ driver/distinfo 13 Feb 2019 02:26:45 -
@@ -1,2 +1,2 @@
-SHA256 (flang-driver-6.0.0.20181012-f90d905b.tar.gz) = ApdRnjeFdlRb0aiTO0GlcSu6+rB1oYQrQmHmldsuzMY=
-SIZE (flang-driver-6.0.0.20181012-f90d905b.tar.gz) = 16785531
+SHA256 (flang-driver-7.0.1.20181218-24bd54da.tar.gz) = Z54V9PfCA7i6dfxKEvC2NI3fnITSIagEkw/ljha0lu0=
+SIZE (flang-driver-7.0.1.20181218-24bd54da.tar.gz) = 17649879
Index: driver/patches/patch-include_clang_Basic_DiagnosticSemaKinds_td
===
RCS file: /cvs/ports/lang/flang/driver/patches/patch-include_clang_Basic_DiagnosticSemaKinds_td,v
retrieving revision 1.3
diff -u -p -r1.3 patch-include_clang_Basic_DiagnosticSemaKinds_td
--- driver/patches/patch-include_clang_Basic_DiagnosticSemaKinds_td 16 Jun 2018 20:08:28 - 1.3
+++ driver/patches/patch-include_clang_Basic_DiagnosticSemaKinds_td 13 Feb 2019 02:26:45 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-include_clang_Basic_Diag
Index: incl
Re: [UPDATE] audio/openal 1.19.1
On Tue, Feb 12, 2019 at 04:07:53PM +, David CARLIER wrote: > Hi jca and were discussing about his question regarding the > OpenAL32_alBuffer.c patch ... > It might have been fixed with the 1.19.1 release what would be nice is > for you to test couple of consumers without this specific change and > see if it crashes then maybe we will be able to remove this for good > ;-) > Done testing, those consumers simply have no sound when no devices are available, I simple set in /etc/openal/alsoft.conf: drivers = -sndio > Thanks. Now, I report that all openal dependents are successfully built: mazocomp$ cd /usr/ports/ mazocomp$ cat openal.dependents audio/freealut emulators/fs-uae emulators/higan emulators/retroarch games/0ad/base games/arx-libertatis games/astromenace games/barony games/colobot/colobot games/dhewm3 games/dustrac games/endless-sky games/fifengine games/fnaify games/freeorion games/fs2open games/gemrb games/gzdoom games/ioquake3 games/irrlamb games/love games/lugaru games/lwjgl games/megaglest/base games/minetest games/openmw games/openomf games/scorched3d games/solarus/solarus games/spacezero games/speeddreams games/supertux games/supertuxkart games/taisei games/tome4 games/ufoai/base,-editor games/valyriatear games/vegastrike/engine games/warzone2100 games/yquake2 graphics/blender graphics/simgear multimedia/sfml net/utox x11/kde-applications/libkdegames x11/kde4/libkdegames x11/qt5/qtmultimedia mazocomp$ doas infrastructure/bin/dpb openal.dependents Started as: root Port user: root Build user: _pbuild Fetch user: _pfetch Log user: _pbuild Unpriv user: _dpb Reading build stats...zapping old stuff...Done Reading distinfo...zap duplicates...Done Waiting for hosts to finish STARTUP...ready on localhost 13 Feb 03:13:24 [82702] running for 14:30:52 Hosts: localhost(kde4) I=688 B=0 Q=0 T=0 F=0 !=4 Elapsed time=14:30:52 I=688 B=0 Q=0 T=0 F=0 !=4 mazocomp$ Commit time? :)
[UPDATE] games/cataclysm-dda to 20190208
Again, many updates since the last port update. Development is moving towards
the next release so this pulls from the 0.D branch instead of master. 0.D will
be the next release and has reached feature freeze so subsequent port updates
will track the 0.D branch for bug fixes.
Tim.
Index: Makefile
===
RCS file: /cvs/ports/games/cataclysm-dda/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile3 Dec 2018 08:43:56 - 1.7
+++ Makefile9 Feb 2019 21:53:58 -
@@ -1,12 +1,12 @@
# $OpenBSD: Makefile,v 1.7 2018/12/03 08:43:56 kirby Exp $
COMMENT= rogue-like zombie survival game
-DISTNAME= cataclysm-dda-2018.11.01
+DISTNAME= cataclysm-dda-2019.02.08
CATEGORIES=games
GH_ACCOUNT=CleverRaven
GH_PROJECT=Cataclysm-DDA
-GH_COMMIT= 473c84e270095e8095d5e00d8af8ddba012d9286
+GH_COMMIT= 4fd9499fed5caf477fb9abe0eaf0e76ba0323487
HOMEPAGE= http://en.cataclysmdda.com
MAINTAINER=Tim Meunier
@@ -18,7 +18,7 @@ FLAVORS= no_x11
FLAVOR?=
WANTLIB= ${COMPILER_LIBCXX} ${MODLUA_WANTLIB} c \
- iconv intl m pthread
+ execinfo iconv intl m pthread
COMPILER= base-clang ports-gcc
@@ -29,7 +29,7 @@ MODLUA_SA=Yes
BUILD_DEPENDS= devel/libexecinfo
-LIB_DEPENDS= devel/gettext
+LIB_DEPENDS= devel/libexecinfo devel/gettext
MAKE_ENV= CXX="${CXX}" CXXFLAGS="${CXXFLAGS}"
Index: distinfo
===
RCS file: /cvs/ports/games/cataclysm-dda/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo3 Dec 2018 08:43:56 - 1.6
+++ distinfo9 Feb 2019 21:53:58 -
@@ -1,2 +1,2 @@
-SHA256 (cataclysm-dda-2018.11.01-473c84e2.tar.gz) =
g0APey4DAnW6/b9vDYzNFgybfnVUx5NSIzXxWstHNDM=
-SIZE (cataclysm-dda-2018.11.01-473c84e2.tar.gz) = 71795769
+SHA256 (cataclysm-dda-2019.02.08-4fd9499f.tar.gz) =
b+CNCSP2wLKgsUWX9FvNzDl2Jn1J1+96ra9LfthApPo=
+SIZE (cataclysm-dda-2019.02.08-4fd9499f.tar.gz) = 83424764
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/games/cataclysm-dda/patches/patch-Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 patch-Makefile
--- patches/patch-Makefile 3 Dec 2018 08:43:56 - 1.7
+++ patches/patch-Makefile 9 Feb 2019 21:53:58 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-Makefile,v 1.7 2018/12/0
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -84,7 +84,6 @@
+@@ -86,7 +86,6 @@
# RELEASE is flags for release builds, this disables some debugging flags and
# enforces build failure when warnings are encountered.
# We want to error on everything to make sure we don't check in code with new
warnings.
@@ -11,7 +11,7 @@ Index: Makefile
WARNINGS = -Wall -Wextra
# Uncomment below to disable warnings
#WARNINGS = -w
-@@ -254,7 +253,6 @@ ifdef RELEASE
+@@ -276,7 +275,6 @@ ifdef RELEASE
OPTLEVEL = -O3
endif
endif
@@ -19,16 +19,16 @@ Index: Makefile
ifdef LTO
LDFLAGS += -fuse-ld=gold
-@@ -295,7 +293,7 @@ endif
+@@ -317,7 +315,7 @@ endif
ifeq ($(shell sh -c 'uname -o 2>/dev/null || echo not'),Cygwin)
- OTHERS += -std=gnu++11
- else
--OTHERS += -std=c++11
-+OTHERS += -std=c++11 -I${LOCALBASE}/include
+ OTHERS += -std=gnu++11
+ else
+- OTHERS += -std=c++11
++ OTHERS += -std=c++11 -I${LOCALBASE}/include
endif
CXXFLAGS += $(WARNINGS) $(DEBUG) $(DEBUGSYMS) $(PROFILE) $(OTHERS) -MMD -MP
-@@ -440,11 +438,6 @@ ifdef MAPSIZE
+@@ -462,11 +460,6 @@ ifdef MAPSIZE
CXXFLAGS += -DMAPSIZE=$(MAPSIZE)
endif
@@ -40,7 +40,7 @@ Index: Makefile
PKG_CONFIG = $(CROSS)pkg-config
SDL2_CONFIG = $(CROSS)sdl2-config
-@@ -754,7 +747,7 @@ ifdef LTO
+@@ -780,7 +773,7 @@ ifdef LTO
endif
endif
@@ -49,7 +49,7 @@ Index: Makefile
@
$(TARGET): $(OBJS)
-@@ -773,7 +766,6 @@ $(BUILD_PREFIX)$(TARGET_NAME).a: $(OBJS)
+@@ -799,7 +792,6 @@ $(BUILD_PREFIX)$(TARGET_NAME).a: $(OBJS)
.PHONY: version json-verify
version:
@( VERSION_STRING=$(VERSION) ; \
@@ -57,7 +57,7 @@ Index: Makefile
[ -e "$(SRC_DIR)/version.h" ] && OLDVERSION=$$(grep VERSION
$(SRC_DIR)/version.h|cut -d '"' -f2) ; \
if [ "x$$VERSION_STRING" != "x$$OLDVERSION" ]; then echo "#define
VERSION \"$$VERSION_STRING\"" | tee $(SRC_DIR)/version.h ; fi \
)
-@@ -827,36 +819,36 @@ distclean:
+@@ -853,36 +845,36 @@ distclean:
bindist: $(BINDIST)
ifeq ($(TARGETSYSTEM), LINUX)
@@ -114,14 +114,14 @@ Index: Makefile
mkdir -p $(LOCALE_DIR)
ifdef LANGUAGES
LOCALE_DIR=$(LOCALE_DIR) lang/compile_mo.sh $(LANGUAGES)
-@@ -1029,11 +1021,6 @@ astyle: $(ASTYLED_WHITELIST)
+@@ -1055,11 +1047,6 @@ astyle: $(ASTYLED_WHITE
Re: Help updating shells/bash to 5.0
Stephen Gregoratto: > Bash 5.0 has just been released[1], and I thought I'd try and update the > port. I'm having problems getting the `seq` builtin to compile. > I've attached the (truncated) log, but the gist of it is this: I have finally updated the bash port. Sorry, that should not have taken a month. The problem with the seq loadable results from CPPFLAGS not propagating to the compiler flags that are used to build the loadables: https://lists.gnu.org/archive/html/bug-bash/2019-02/msg00045.html -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [new] sysutils/yabitrot
Le 12 févr. 2019 23:06, Daniel Jakots a écrit : > > On Tue, 12 Feb 2019 22:39:24 +0100, Solene Rapenne > wrote: > > > It's just a python script. > > what's the point of packaging it then? > I was pretty sure this question would rise. So, I think it's worth having it in ports, I reviewed it to make sure it's not harmful or not functional and it makes easier for installation, users can trust the package. I will understand if people think packaging a script is not worth.
Re: [new] sysutils/yabitrot
On 2019/02/12 22:39, Solene Rapenne wrote:
> Hi, this is yabitrot, a small utility to check bitrot. It uses Adler-32
> checksum to go faster. It's just a python script.
Please use ${MODPY_BIN} instead of ${LOCALBASE}/bin/python3.6,
otherwise okay with me.
On 2019/02/12 23:06, Daniel Jakots wrote:
> On Tue, 12 Feb 2019 22:39:24 +0100, Solene Rapenne
> wrote:
>
> > It's just a python script.
>
> what's the point of packaging it then?
This way people can find it more easily .. It's faster than
sysutils/bitrot which is pretty much just a python script too :)
Re: UPDATE: lang/flang 7.0.1
On 2/12/19 5:05 PM, Jeremie Courreges-Anglas wrote: On Tue, Feb 12 2019, Brian Callahan wrote: On 2/1/19 4:35 PM, Brian Callahan wrote: Hi ports -- Every time we update LLVM, flang needs to be updated and it takes me some time to get it done. Regarding this, do you want some time for the next major upgrades? I wasn't able to coordinate with the LLVM update this time around and I don't think flang should hold up LLVM updates so I'm fine with flang playing catch-up. It's done now. The patch is attached. Some notes: 1. Haven't turned arm64 back on. I expect it to work but would like to compile/run test it first instead of blindly turning it on. arm64 bulk builds take ~4 days, I don't think phessler and arm64 users will mind. I tried it myself and things are still broken on arm64 so I'll have to talk to the flang people... 2. flang-7 wants to use -lLLVM and build and link to its own separate libclang.so. I don't want to do either of those things to avoid potential conflicts, so I've disabled building libclang.so and ham-fisted a replacement for -lLLVM-7 in a post-configure target, forcing it to use the LLVM static libs. This creates a very huge (>80MB) binary. But I think this is fine since the only archs that flang works on are amd64 and arm64 anyway. 3. Everything is good with the NIST Fortran 77 test suite. Tests appreciated. ~Brian No Fortran people? I will just commit it then... I would not know what to test! If only flang was a possible choice in fortran.port.mk... :) I use this: http://www.fortran-2000.com/ArnaudRecipes/fcvs21_f95.html Specifically, the modified version that conforms to F95. But yes, thanks for reminding me that we might want to add flang to fortran.port.mk ~Brian
Re: UPDATE: lang/flang 7.0.1
On Tue, Feb 12 2019, Brian Callahan wrote: > On 2/1/19 4:35 PM, Brian Callahan wrote: >> Hi ports -- >> >> Every time we update LLVM, flang needs to be updated and it takes me >> some time to get it done. Regarding this, do you want some time for the next major upgrades? >> It's done now. The patch is attached. >> >> Some notes: >> 1. Haven't turned arm64 back on. I expect it to work but would like to >> compile/run test it first instead of blindly turning it on. arm64 bulk builds take ~4 days, I don't think phessler and arm64 users will mind. >> 2. flang-7 wants to use -lLLVM and build and link to its own separate >> libclang.so. I don't want to do either of those things to avoid >> potential conflicts, so I've disabled building libclang.so and >> ham-fisted a replacement for -lLLVM-7 in a post-configure target, >> forcing it to use the LLVM static libs. This creates a very huge >> (>80MB) binary. But I think this is fine since the only archs that >> flang works on are amd64 and arm64 anyway. >> >> 3. Everything is good with the NIST Fortran 77 test suite. >> >> Tests appreciated. >> >> ~Brian >> > > No Fortran people? I will just commit it then... I would not know what to test! If only flang was a possible choice in fortran.port.mk... :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [new] sysutils/yabitrot
On Tue, 12 Feb 2019 22:39:24 +0100, Solene Rapenne wrote: > It's just a python script. what's the point of packaging it then?
Re: x11/qt5/{qtgraphicaleffects,qtquickcontrols*} when not x86
On Tue, 12 Feb 2019 01:32:39 -0500
George Koehler wrote:
> On Thu, 7 Feb 2019 13:09:30 +0100
> Charlene Wendling wrote:
>
> > My change to SUBST_VARS made VERSION not being expanded, actually
> > breaking packaging with the other x11/qt5 ports includig ${VERSION}
> > in PLISTs.
> >
> > I'm joining a new diff that fixes that on my macppc and amd64
> > machines.
>
> Thank you for sharing your diff! It saves much of my time.
You're welcome, given the input i had from so many people on this one
it's more *our* diff!
I'll wait for more OKs and/or rsadowski@ to come back to commit it,
x11/qt5 is a pretty complex subtree (for me), it's still possible i
have missed something... but it just works here.
> I am using your diff to unblock qtquickcontrols and try building
> editors/calligra on macppc. Found that calligra is broken with
> poppler 0.73.0. This is delaying me while I try some patches from
> calligra's git.
I'm a bit out of topic here, but all x11/qt5 binaries seem to segfault
at runtime with ports-gcc-4.9 on macppc - it just worked fine with
ports-gcc-8.2.
Charlène.
Re: fix x11/compton with Mesa 18
On Tue, Feb 12, 2019 at 09:27:40PM +0100, Matthieu Herrb wrote:
> the patch below (from https://github.com/yshui/compton/commit/bf29b2d)
> should fix weird color issues with mesa 18.3 in compton reported by
> Erling Westenvik.
>
> Thanks to Thomas Frohwein for the hint.
Confirmed to fix the problem on my system. Thanks both of you!
Erling Westenvik
> ok?
>
> Index: Makefile
> ===
> RCS file: /cvs/OpenBSD/ports/x11/compton/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 Makefile
> --- Makefile 27 Jun 2018 21:04:07 - 1.5
> +++ Makefile 12 Feb 2019 20:17:27 -
> @@ -5,7 +5,7 @@ COMMENT = lightweight compositor for X,
> V = 0.1_beta2
> PKGNAME =compton-${V}
> DISTNAME = compton-git-v0.1_beta2-2013-10-21
> -REVISION = 2
> +REVISION = 3
>
> CATEGORIES = x11
>
> Index: patches/patch-src_opengl_c
> ===
> RCS file: patches/patch-src_opengl_c
> diff -N patches/patch-src_opengl_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_opengl_c12 Feb 2019 20:17:03 -
> @@ -0,0 +1,25 @@
> +$OpenBSD$
> +
> +https://github.com/yshui/compton/commit/bf29b2d
> +Avoid using 10bit FBConfigs
> +Fix weird color issue with Mesa 18.0
> +
> +--- src/opengl.c.origMon Oct 21 16:17:01 2013
> src/opengl.c Tue Feb 12 21:14:44 2019
> +@@ -497,6 +497,16 @@
> + return -1;
> + if (!pfbc_b)
> + return 1;
> ++ int tmpattr;
> ++
> ++ // Avoid 10-bit colors
> ++ glXGetFBConfigAttrib(ps->dpy, pfbc_a->cfg, GLX_RED_SIZE, &tmpattr);
> ++ if (tmpattr != 8)
> ++return -1;
> ++
> ++ glXGetFBConfigAttrib(ps->dpy, pfbc_b->cfg, GLX_RED_SIZE, &tmpattr);
> ++ if (tmpattr != 8)
> ++return 1;
> +
> + #define P_CMPATTR_LT(attr) { if ((result = glx_cmp_fbconfig_cmpattr(ps,
> pfbc_a, pfbc_b, (attr return -result; }
> + #define P_CMPATTR_GT(attr) { if ((result = glx_cmp_fbconfig_cmpattr(ps,
> pfbc_a, pfbc_b, (attr return result; }
>
> --
> Matthieu Herrb
[new] sysutils/yabitrot
Hi, this is yabitrot, a small utility to check bitrot. It uses Adler-32 checksum to go faster. It's just a python script. yabitrot.tar.gz Description: Binary data
Re: UPDATE: lang/flang 7.0.1
On 2/1/19 4:35 PM, Brian Callahan wrote: Hi ports -- Every time we update LLVM, flang needs to be updated and it takes me some time to get it done. It's done now. The patch is attached. Some notes: 1. Haven't turned arm64 back on. I expect it to work but would like to compile/run test it first instead of blindly turning it on. 2. flang-7 wants to use -lLLVM and build and link to its own separate libclang.so. I don't want to do either of those things to avoid potential conflicts, so I've disabled building libclang.so and ham-fisted a replacement for -lLLVM-7 in a post-configure target, forcing it to use the LLVM static libs. This creates a very huge (>80MB) binary. But I think this is fine since the only archs that flang works on are amd64 and arm64 anyway. 3. Everything is good with the NIST Fortran 77 test suite. Tests appreciated. ~Brian No Fortran people? I will just commit it then... ~Brian
login_ldap with referrals
I'm currently playing around with login_ldap and trying to get it to play nice with our own ldap implementation. Most of this seems to work quite well, but I'm currently trying to wrap my head around the referral code. >From what I can deduce (if the ldap library isn't put into auto-referral) it tries to find the user on the destination server, but still tries to login with the user found on the referred on the original machine, which I personally don't see happening. Is there anyone who uses login_ldap with referrals and manages to get it to work? Any pointers or example setups are welcome. martijn@
Re: sparc64 C++ exception fix for gcc8
> Date: Tue, 12 Feb 2019 18:24:32 +0100
> From: Otto Moerbeek
>
> On Fri, Feb 08, 2019 at 09:07:23PM +0100, Otto Moerbeek wrote:
>
> > Hi,
> >
> > This fixes regresss/misc/exceptions on sparc64
> >
> > OK?
>
> ping...
This looks good to me.
ok kettenis@
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/lang/gcc/8/Makefile,v
> > retrieving revision 1.4
> > diff -u -p -r1.4 Makefile
> > --- Makefile13 Jan 2019 11:59:18 - 1.4
> > +++ Makefile8 Feb 2019 20:06:32 -
> > @@ -11,7 +11,7 @@ DPB_PROPERTIES = parallel
> > V = 8.2.0
> > FULL_VERSION = $V
> > FULL_PKGVERSION = $V
> > -REVISION = 0
> > +REVISION = 1
> >
> > ADASTRAP_LIBC-amd64 = 93.0
> > ADASTRAP_LIBM-amd64 = 10.1
> > Index: patches/patch-libgcc_unwind-dw2_c
> > ===
> > RCS file: patches/patch-libgcc_unwind-dw2_c
> > diff -N patches/patch-libgcc_unwind-dw2_c
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ patches/patch-libgcc_unwind-dw2_c 8 Feb 2019 20:06:32 -
> > @@ -0,0 +1,53 @@
> > +$OpenBSD$
> > +
> > +Index: libgcc/unwind-dw2.c
> > +--- libgcc/unwind-dw2.c.orig
> > libgcc/unwind-dw2.c
> > +@@ -215,6 +215,25 @@ _Unwind_IsExtendedContext (struct _Unwind_Context *con
> > + return (ASSUME_EXTENDED_UNWIND_CONTEXT
> > + || (context->flags & EXTENDED_CONTEXT_BIT));
> > + }
> > ++
> > ++#ifdef __sparc64__
> > ++
> > ++/* Figure out StackGhost cookie. */
> > ++_Unwind_Word uw_get_wcookie(void);
> > ++
> > ++asm(".text\n"
> > ++"uw_get_wcookie:\n"
> > ++" add %o7, %g0, %g4\n"
> > ++" save %sp, -176, %sp\n"
> > ++" save %sp, -176, %sp\n"
> > ++" flushw\n"
> > ++" restore\n"
> > ++" ldx [%sp + 2047 + 120], %g5\n"
> > ++" xor %g4, %g5, %i0\n"
> > ++" ret\n"
> > ++" restore\n");
> > ++#endif
> > ++
> > +
> > + /* Get the value of register REGNO as saved in CONTEXT. */
> > +
> > +@@ -245,6 +264,13 @@ _Unwind_GetGR (struct _Unwind_Context *context, int re
> > + }
> > + #endif
> > +
> > ++#ifdef __sparc64__
> > ++ /* _Unwind_Word and _Unwind_Ptr are the same size on sparc64 */
> > ++ _Unwind_Word reg = * (_Unwind_Word *) val;
> > ++ if (index == 15 || index == 31)
> > ++reg ^= uw_get_wcookie ();
> > ++ return reg;
> > ++#else
> > + /* This will segfault if the register hasn't been saved. */
> > + if (size == sizeof(_Unwind_Ptr))
> > + return * (_Unwind_Ptr *) (_Unwind_Internal_Ptr) val;
> > +@@ -253,6 +279,7 @@ _Unwind_GetGR (struct _Unwind_Context *context, int re
> > + gcc_assert (size == sizeof(_Unwind_Word));
> > + return * (_Unwind_Word *) (_Unwind_Internal_Ptr) val;
> > + }
> > ++#endif
> > + }
> > +
> > + static inline void *
> >
>
Re: UPDATE: net/ngircd to 25
On 2019/02/12 19:48, Giannis Tsaraias wrote:
> Hello,
>
> Here's a diff to update ngircd to 25. Changelog:
> https://raw.githubusercontent.com/ngircd/ngircd/master/ChangeLog
>
> Passes all tests. Manually tested with SSL as well.
>
> Looking for feedback and OKs.
Please use https for ngircd.barton.de and run update-patches.
The newly added MaxPenaltyTime is a time_t (64-bit on all OpenBSD arches)
but is accessed as a long which will break on 32-bit arches; the visible
warning indicating this is here:
conf.c:391:37: warning: format specifies type 'long' but the argument has type
'time_t' (aka 'long long') [-Wforma
t]
printf(" MaxPenaltyTime = %ld\n", Conf_MaxPenaltyTime);
~~~ ^~~
%lld
The attached replacement for patch-src_ngircd_conf_c should fix that.
$OpenBSD: patch-src_ngircd_conf_c,v 1.5 2014/12/03 10:32:18 jasper Exp $
Index: src/ngircd/conf.c
--- src/ngircd/conf.c.orig
+++ src/ngircd/conf.c
@@ -388,7 +388,7 @@ Conf_Test( void )
printf(" MaxConnectionsIP = %d\n", Conf_MaxConnectionsIP);
printf(" MaxJoins = %d\n", Conf_MaxJoins > 0 ? Conf_MaxJoins : -1);
printf(" MaxNickLength = %u\n", Conf_MaxNickLength - 1);
- printf(" MaxPenaltyTime = %ld\n", Conf_MaxPenaltyTime);
+ printf(" MaxPenaltyTime = %lld\n", (long long)Conf_MaxPenaltyTime);
printf(" MaxListSize = %d\n", Conf_MaxListSize);
printf(" PingTimeout = %d\n", Conf_PingTimeout);
printf(" PongTimeout = %d\n", Conf_PongTimeout);
@@ -757,7 +757,7 @@ Set_Defaults(bool InitServers)
strlcat(Conf_HelpFile, HELP_FILE, sizeof(Conf_HelpFile));
strcpy(Conf_ServerPwd, "");
strlcpy(Conf_PidFile, PID_FILE, sizeof(Conf_PidFile));
- Conf_UID = Conf_GID = 0;
+ Conf_UID = Conf_GID = 703; /* _ngircd */
/* Limits */
Conf_ConnectRetry = 60;
@@ -1644,7 +1644,7 @@ Handle_LIMITS(const char *File, int Line, char *Var, c
return;
}
if (strcasecmp(Var, "MaxPenaltyTime") == 0) {
- Conf_MaxPenaltyTime = atol(Arg);
+ Conf_MaxPenaltyTime = atoll(Arg);
if (Conf_MaxPenaltyTime < -1)
Conf_MaxPenaltyTime = -1; /* "unlimited" */
return;
@@ -2291,8 +2291,8 @@ Validate_Config(bool Configtest, bool Rehash)
if (Conf_MaxPenaltyTime != -1)
Config_Error(LOG_WARNING,
-"Maximum penalty increase ('MaxPenaltyTime') is
set to %ld, this is not recommended!",
-Conf_MaxPenaltyTime);
+"Maximum penalty increase ('MaxPenaltyTime') is
set to %lld, this is not recommended!",
+(long long)Conf_MaxPenaltyTime);
#ifdef DEBUG
servers = servers_once = 0;
Re: sysutils/u-boot - thermal readings for Pine A64(+)
> Wiadomość napisana przez Jonathan Gray w dniu 30.01.2019, o
> godz. 12:40:
>
> On Tue, Jan 29, 2019 at 06:37:57PM +0100, Krystian Lewandowski wrote:
>> Hi ports@,
>> OpenBSD supports temperature readings for Pine A64 (sxitemp.c,
>> allwinner,sun50i-a64-ths) but dts file in u-boot port does not contain
>> necessary
>> entry.
>>
>> Its based on FreeBSD overlay[1] with small changes (no sensor calibration in
>> OpenBSD
>> yet). Built with FLAVOR=aarch64.
>
> I'm not sure we want to carry patches for this as doing it properly would
> mean picking up all the other patches for h3, h5, etc and setting it to
> enabled on each board going by the proposed devicetree changes which were
> not applied as far as I can see.
>
> https://lkml.org/lkml/2018/8/4/32
>
If you are interested, below is the patch with all changes from LKML thread
applied.
I tested a64's u-boot-sunxi-with-spl.bin only (I don't have other boards).
I had to add "sid" entries to h5 and h3 and "ths" entries were not added to two
definitions:
sun50i-a64-teres-i.dts
sun8i-h3-beelink-x2.dts
because they are missing in u-boot at the moment.
FLAVOR=aarch64 builld went fine and I wasnt sure what would be the correct
method
to confirm nothing got broken, so I ran "find" on "./build" folder, sorted the
output
for port without this patch and without the patch, checked diff - no changes
reported.
Krystian
Index: Makefile
===
RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile7 Feb 2019 20:50:18 - 1.51
+++ Makefile12 Feb 2019 20:37:57 -
@@ -7,7 +7,7 @@ FLAVOR?=arm
COMMENT= U-Boot firmware
VERSION= 2019.01
-REVISION= 4
+REVISION= 5
DISTNAME= u-boot-${VERSION}
PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
FULLPKGNAME= ${PKGNAME}
Index: patches/patch-arch_arm_dts_sun50i-a64-amarula-relic_dts
===
RCS file: patches/patch-arch_arm_dts_sun50i-a64-amarula-relic_dts
diff -N patches/patch-arch_arm_dts_sun50i-a64-amarula-relic_dts
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-arch_arm_dts_sun50i-a64-amarula-relic_dts 12 Feb 2019
20:37:57 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: arch/arm/dts/sun50i-a64-amarula-relic.dts
+--- arch/arm/dts/sun50i-a64-amarula-relic.dts.orig
arch/arm/dts/sun50i-a64-amarula-relic.dts
+@@ -201,6 +201,10 @@
+ regulator-name = "vcc-rtc";
+ };
+
++&ths {
++ status = "okay";
++};
++
+ &uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
Index: patches/patch-arch_arm_dts_sun50i-a64-bananapi-m64_dts
===
RCS file: patches/patch-arch_arm_dts_sun50i-a64-bananapi-m64_dts
diff -N patches/patch-arch_arm_dts_sun50i-a64-bananapi-m64_dts
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-arch_arm_dts_sun50i-a64-bananapi-m64_dts 12 Feb 2019
20:37:57 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: arch/arm/dts/sun50i-a64-bananapi-m64.dts
+--- arch/arm/dts/sun50i-a64-bananapi-m64.dts.orig
arch/arm/dts/sun50i-a64-bananapi-m64.dts
+@@ -326,6 +326,10 @@
+ vcc-hdmi-supply = <®_dldo1>;
+ };
+
++&ths {
++ status = "okay";
++};
++
+ &uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
Index: patches/patch-arch_arm_dts_sun50i-a64-nanopi-a64_dts
===
RCS file: patches/patch-arch_arm_dts_sun50i-a64-nanopi-a64_dts
diff -N patches/patch-arch_arm_dts_sun50i-a64-nanopi-a64_dts
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-arch_arm_dts_sun50i-a64-nanopi-a64_dts12 Feb 2019
20:37:57 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: arch/arm/dts/sun50i-a64-nanopi-a64.dts
+--- arch/arm/dts/sun50i-a64-nanopi-a64.dts.orig
arch/arm/dts/sun50i-a64-nanopi-a64.dts
+@@ -276,6 +276,10 @@
+ vcc-hdmi-supply = <®_dldo1>;
+ };
+
++&ths {
++ status = "okay";
++};
++
+ &uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
Index: patches/patch-arch_arm_dts_sun50i-a64-olinuxino_dts
===
RCS file: patches/patch-arch_arm_dts_sun50i-a64-olinuxino_dts
diff -N patches/patch-arch_arm_dts_sun50i-a64-olinuxino_dts
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-arch_arm_dts_sun50i-a64-olinuxino_dts 12 Feb 2019 20:37:57
-
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: arch/arm/dts/sun50i-a64-olinuxino.dts
+--- arch/arm/dts/sun50i-a64-olinuxino.dts.orig
arch/arm/dts/sun50i-a64-olinuxino.dts
+@@ -299,6 +299,10 @@
+ vcc-hdmi-supply = <®_dldo1>;
+ };
+
++&ths {
++ status = "okay";
++};
++
+ &uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
Index: patches/patch-arch_arm_dts_sun50i-a64-orangepi-win_dts
Re: devel/llvm powerpc bugs
On Thu, Jan 31 2019, George Koehler wrote: > My OpenBSD/macppc machine has built devel/llvm 7.0.1p0, but a pair of > bugs in clang 6 are still in clang 7. A moment ago, I reported these > bugs to llvm: > > - https://bugs.llvm.org/show_bug.cgi?id=40553 > wrong sizeof(long double) in 32-bit PowerPC NetBSD, OpenBSD > > - https://bugs.llvm.org/show_bug.cgi?id=40554 > misaligned float in PowerPC code causes SIGBUS in OpenBSD/macppc > > Each report includes an example program that reproduces the bug, and > a patch that tries to fix it. The long double bug is breaking > graphics/kdiagram on powerpc. (Most C++ ports use ports-gcc, but > x11/qt5/qt5.port.mk prefers ports-clang before ports-gcc, so ports > using Qt5 may suffer from clang bugs.) > > I am now using the attached diff in devel/llvm. I have packaged > kdiagram with this. My REVISION-main bump (from 0 to 1) conflicts > with recent changes in CVS. My patches might not be correct; someone > who knows llvm might be able to write better patches. > > I am using lang/gcc/8 as my ports-gcc; I have edited > - infrastructure/mk/gcc4.port.mk to use MODGCC4_VERSION?=8 > - devel/llvm/Makefile to use GCC_VER = 8.2.0 > These edits are not in the attached diff. fwiw, you may have noticed that the "long double diff" has already been added both to base and ports-clang. For the other diff I don't know yet what to do. I don't have a powerpc machine at hand at the moment, maybe soon (tm). I see that you've sent a follow-up on https://bugs.llvm.org/show_bug.cgi?id=40554 POWER8 is not relevant for us, but may indeed be relevant for upstream since their PowerPC target seems to handle what look like different ISA to me. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE signature.asc Description: PGP signature
Re: [Update] Ipe 7.2.9
Hello Edd, any comments on this? Thanks Il 4 febbraio 2019 20:33:08 CET, Alessandro DE LAURENZIS ha scritto: >Hello Edd, > >thanks for your time to revisit this port; please find enclosed the >unified diff. > >All the best > >On 2/4/19 12:11 PM, Edd Barrett wrote: >> On Sun, Feb 03, 2019 at 05:10:07PM +0100, Alessandro DE LAURENZIS >wrote: >>> Dear ports@ readers, >>> >>> Here is a proposal for updating Ipe (the extensible drawing editor) >to the >>> latest release. >> >> Thanks, I'm happy to review this, but can you send your update as a >> unified diff from cvs? >> >> `cvs add` and `cvs rm` files as necessary (you should only have M, R >and >> A lines in the output of `cvs -n up -dP`) and then do: >> >> cvs diff -uNp > /tmp/ipe.diff >> >> We only do tarballs for new ports, and diffs are easier to review. >> >> Thanks >> > > >-- >Alessandro DE LAURENZIS >[mailto:jus...@atlantide.t28.net] >Web: http://www.atlantide.t28.net >LinkedIn: https://www.linkedin.com/in/delaurenzis/ -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
fix x11/compton with Mesa 18
Hi,
the patch below (from https://github.com/yshui/compton/commit/bf29b2d)
should fix weird color issues with mesa 18.3 in compton reported by
Erling Westenvik.
Thanks to Thomas Frohwein for the hint.
ok?
Index: Makefile
===
RCS file: /cvs/OpenBSD/ports/x11/compton/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile27 Jun 2018 21:04:07 - 1.5
+++ Makefile12 Feb 2019 20:17:27 -
@@ -5,7 +5,7 @@ COMMENT = lightweight compositor for X,
V =0.1_beta2
PKGNAME = compton-${V}
DISTNAME = compton-git-v0.1_beta2-2013-10-21
-REVISION = 2
+REVISION = 3
CATEGORIES = x11
Index: patches/patch-src_opengl_c
===
RCS file: patches/patch-src_opengl_c
diff -N patches/patch-src_opengl_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_opengl_c 12 Feb 2019 20:17:03 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+https://github.com/yshui/compton/commit/bf29b2d
+Avoid using 10bit FBConfigs
+Fix weird color issue with Mesa 18.0
+
+--- src/opengl.c.orig Mon Oct 21 16:17:01 2013
src/opengl.c Tue Feb 12 21:14:44 2019
+@@ -497,6 +497,16 @@
+ return -1;
+ if (!pfbc_b)
+ return 1;
++ int tmpattr;
++
++ // Avoid 10-bit colors
++ glXGetFBConfigAttrib(ps->dpy, pfbc_a->cfg, GLX_RED_SIZE, &tmpattr);
++ if (tmpattr != 8)
++return -1;
++
++ glXGetFBConfigAttrib(ps->dpy, pfbc_b->cfg, GLX_RED_SIZE, &tmpattr);
++ if (tmpattr != 8)
++return 1;
+
+ #define P_CMPATTR_LT(attr) { if ((result = glx_cmp_fbconfig_cmpattr(ps,
pfbc_a, pfbc_b, (attr return -result; }
+ #define P_CMPATTR_GT(attr) { if ((result = glx_cmp_fbconfig_cmpattr(ps,
pfbc_a, pfbc_b, (attr return result; }
--
Matthieu Herrb
Re: UPDATE: net/snort 2.9.12
Hello,
thanks Stuart for your suggestions.
Updated diff attached.
- straight DISTNAME
- use RULESV instead of V
- fix WANTLIB
Regards
Markus
Index: Makefile
===
RCS file: /cvs/ports/net/snort/Makefile,v
retrieving revision 1.100
diff -u -p -u -p -r1.100 Makefile
--- Makefile4 Sep 2018 12:46:18 - 1.100
+++ Makefile12 Feb 2019 18:57:21 -
@@ -2,8 +2,9 @@
COMMENT = highly flexible sniffer/NIDS
-VERSION = 2.9.11.1
-DISTNAME = snort-${VERSION}
+DISTNAME = snort-2.9.12
+RULESV = 29120
+SUBST_VARS = RULESV
CATEGORIES = net security
@@ -14,7 +15,7 @@ MAINTAINER = Markus Lude https://www.snort.org/downloads/snort/
@@ -25,6 +26,7 @@ CONFIGURE_ARGS += --disable-static-daq \
LIB_DEPENDS = archivers/xz \
devel/pcre \
+ lang/luajit \
net/daq \
net/libdnet \
www/nghttp2
@@ -36,10 +38,6 @@ PREPROC =decoder.rules preprocessor.ru
DOCS = AUTHORS CREDITS README README.* *.pdf TODO USAGE \
WISHLIST
-
-V =${VERSION:S/.//g}
-SUBST_VARS += V
-REVISION = 0
pre-configure:
@${SUBST_CMD} ${WRKSRC}/etc/snort.conf
Index: distinfo
===
RCS file: /cvs/ports/net/snort/distinfo,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 distinfo
--- distinfo28 Jan 2018 03:09:12 - 1.37
+++ distinfo12 Feb 2019 18:57:21 -
@@ -1,2 +1,2 @@
-SHA256 (snort-2.9.11.1.tar.gz) = n2s66sWhCfVVBL03BWSsQxyxdzUHkp3EYWJomPM/Rs0=
-SIZE (snort-2.9.11.1.tar.gz) = 6442755
+SHA256 (snort-2.9.12.tar.gz) = ewLhGYfGy09tedcnmcqa0rS9Wcwdlrt9bJFUn5kNmdA=
+SIZE (snort-2.9.12.tar.gz) = 6456877
Index: patches/patch-src_dynamic-preprocessors_appid_Makefile_in
===
RCS file: patches/patch-src_dynamic-preprocessors_appid_Makefile_in
diff -N patches/patch-src_dynamic-preprocessors_appid_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_dynamic-preprocessors_appid_Makefile_in 12 Feb 2019
18:57:21 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/dynamic-preprocessors/appid/Makefile.in
+--- src/dynamic-preprocessors/appid/Makefile.in.orig
src/dynamic-preprocessors/appid/Makefile.in
+@@ -583,7 +583,7 @@ APPID_SOURCES = $(APPID_SRC_DIR)/commonAppMatcher.c \
+ $(APPID_SRC_DIR)/util/sfutil.c $(APPID_SRC_DIR)/util/sfutil.h
+ dynamicpreprocessordir = ${libdir}/snort_dynamicpreprocessor
+ dynamicpreprocessor_LTLIBRARIES = libsf_appid_preproc.la
+-libsf_appid_preproc_la_LDFLAGS = -export-dynamic -module @XCCFLAGS@
++libsf_appid_preproc_la_LDFLAGS = -export-dynamic -module -avoid-version
@XCCFLAGS@
+ @SO_WITH_STATIC_LIB_FALSE@libsf_appid_preproc_la_LIBADD = $(LUA_LIBS)
+ @SO_WITH_STATIC_LIB_TRUE@libsf_appid_preproc_la_LIBADD =
../libsf_dynamic_preproc.la ../libsf_dynamic_utils.la $(LUA_LIBS)
+ @SO_WITH_STATIC_LIB_FALSE@nodist_libsf_appid_preproc_la_SOURCES = \
Index: patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c
===
RCS file:
/cvs/ports/net/snort/patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 patch-src_preprocessors_Stream6_snort_stream_tcp_c
--- patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c 28 Jan 2018
03:09:12 - 1.5
+++ patches/patch-src_preprocessors_Stream6_snort_stream_tcp_c 12 Feb 2019
18:57:21 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-src_preprocessors_Stream
Index: src/preprocessors/Stream6/snort_stream_tcp.c
--- src/preprocessors/Stream6/snort_stream_tcp.c.orig
+++ src/preprocessors/Stream6/snort_stream_tcp.c
-@@ -8504,7 +8504,7 @@ static int ProcessTcp(SessionControlBlock *scb, Packet
+@@ -8530,7 +8530,7 @@ static int ProcessTcp(SessionControlBlock *scb, Packet
char src_addr[17];
char dst_addr[17];
memset((char *)timestamp, 0, TIMEBUF_SIZE);
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/snort/pkg/PLIST,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 PLIST
--- pkg/PLIST 4 Sep 2018 12:46:18 - 1.31
+++ pkg/PLIST 12 Feb 2019 18:57:21 -
@@ -2,15 +2,21 @@
@pkgpath net/snort[,flexresp][,mysql][,prelude][,postgresql]
@newgroup _snort:557
@newuser _snort:557:_snort:daemon:Snort Account:/nonexistent:/sbin/nologin
+bin/appid_detector_builder.sh
@bin bin/snort
@bin bin/u2boat
+@bin bin/u2openappid
@bin bin/u2spewfoo
+@bin bin/u2streamer
lib/pkgconfig/snort.pc
lib/snort_dynamicengine/
lib/snort_dynamicengine/libsf_engine.a
@comment lib/snort_dynamicengine/
UPDATE: net/ngircd to 25
Hello, Here's a diff to update ngircd to 25. Changelog: https://raw.githubusercontent.com/ngircd/ngircd/master/ChangeLog Passes all tests. Manually tested with SSL as well. Looking for feedback and OKs. -- tsg Index: Makefile === RCS file: /cvs/ports/net/ngircd/Makefile,v retrieving revision 1.16 diff -u -p -u -p -r1.16 Makefile --- Makefile11 Jan 2018 19:27:07 - 1.16 +++ Makefile12 Feb 2019 14:17:52 - @@ -2,8 +2,7 @@ COMMENT = lightweight irc server -DISTNAME = ngircd-24 -REVISION = 0 +DISTNAME = ngircd-25 CATEGORIES = net Index: distinfo === RCS file: /cvs/ports/net/ngircd/distinfo,v retrieving revision 1.10 diff -u -p -u -p -r1.10 distinfo --- distinfo19 Mar 2017 18:20:00 - 1.10 +++ distinfo12 Feb 2019 14:17:52 - @@ -1,2 +1,2 @@ -SHA256 (ngircd-24.tar.gz) = PgCn2lLIH8HgK7mWonv0PakFunA3v4xrs70TMh4Mhas= -SIZE (ngircd-24.tar.gz) = 524968 +SHA256 (ngircd-25.tar.gz) = UZFXgFGbrkPaN5iAfjvtYNiH5OqnKDVKprthzbzaSbo= +SIZE (ngircd-25.tar.gz) = 527886
Re: games/gzdoom disable JIT on amd64
Jeremie Courreges-Anglas writes:
> On Tue, Feb 12 2019, Solene Rapenne wrote:
>
>> brynet@ spotted that gzdoom wasn't W^X compliant due to a JIT engine
>> getting enabled automatically on amd64.
>>
>> This patch makes vm_jit knob at false by default instead of being true.
>> I did not see performance impact on my i7 when it's disabled, but this
>> could be interesting if someone could test it.
>>
>> Without the patch, it's possible to disable JIT with the parameter
>> '+vm_jit false'. While now we can still enable it with '+vm_jit true'
>> (with W^X violation).
>>
>> I don't know if we should let it as this and add WX_NEEDED or patch it
>> out so it doesn't WX by default?
>
> Note that there's a third approach for such ports: try to make the JIT
> W^X compliant. Here, it doesn't seem trivial (look for kVMExecutable).
>
> So your proposal makes sense to me, ok jca@ with a REVISION bump. If
> runtime still works, ofc, but I'll leave tests to actual users. :)
ok by me.
Timo
>
>> Index: patches/patch-src_scripting_vm_vmframe_cpp
>> ===
>> RCS file: patches/patch-src_scripting_vm_vmframe_cpp
>> diff -N patches/patch-src_scripting_vm_vmframe_cpp
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ patches/patch-src_scripting_vm_vmframe_cpp 12 Feb 2019 06:04:57
>> -
>> @@ -0,0 +1,16 @@
>> +$OpenBSD$
>> +
>> +disable JIT so it's W^X compatible
>> +
>> +Index: src/scripting/vm/vmframe.cpp
>> +--- src/scripting/vm/vmframe.cpp.orig
>> src/scripting/vm/vmframe.cpp
>> +@@ -49,7 +49,7 @@
>> + #endif
>> +
>> + #ifdef ARCH_X64
>> +-CUSTOM_CVAR(Bool, vm_jit, true, CVAR_NOINITCALL)
>> ++CUSTOM_CVAR(Bool, vm_jit, false, CVAR_NOINITCALL)
>> + {
>> +Printf("You must restart " GAMENAME " for this change to take
>> effect.\n");
>> +Printf("This cvar is currently not saved. You must specify it on the
>> command line.");
>>
Re: www/iridium README about unveil
On Tue, Feb 12, 2019 at 10:23:53AM +0100, Karel Gardas wrote:
>
> Just iridium user here.
>
> On Tue, 12 Feb 2019 07:02:31 +0100
> Solene Rapenne wrote:
>
> > So, iridium can only display paths allowed in /etc/iridium/, this
>
> This "allowed in /etc/iridium/" is quite confusing. Shouldn't this be
> "allowed in /etc/iridium/unveil.main" unveil definition file for the main
> Iridium process" or something like that?
>
>
> ", but we highly discourage this practise" -- or something like that may be
> added here IMHO.
>
> Thanks!
> Karel
thanks for feedback. I'm unsure about wording, I reworked it a bit from
your suggestions.
Index: pkg/README
===
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/README 12 Feb 2019 18:13:05 -
@@ -0,0 +1,27 @@
+$OpenBSD: README-main,v 1.2 2018/09/04 12:46:25 espie Exp $
+
++---
+| Running ${PKGSTEM} on OpenBSD
++---
+
+Unveil
+=
+Iridium has been patched to use pledge and unveil, so it can only
+display paths allowed in /etc/iridium/unveil.main, this includes
+the following paths:
+
+ ~/Documents ~/Downloads ~/Music
+ ~/Pictures ~/Videos/tmp
+
+If you need to upload a file, you need to make the file available
+in one of those folders.
+
+When iridium file browser is showing up, it may be displaying an
+unauthorized folder which will appear empty, which mean it is not
+possible to browse to some other location. One can use the keyboard
+shortcut Ctrl+L and type a path in the upper address bar to reach a
+whitelisted path.
+
+If you want your browser to be able to walk through your filesystem,
+which is discouraged, unveil can be disabled at runtime by using the
+parameter --disable-unveil
Re: [NEW] devel/p5-Sub-Exporter-ForMethods 0.100052
On Mon, Feb 11, 2019 at 11:26:14AM +, Stuart Henderson wrote:
> On 2019/02/11 08:57, Solene Rapenne wrote:
> > On Fri, Feb 08, 2019 at 08:55:51PM +0100, Charlene Wendling wrote:
> > >
> > > I'm proposing here a new port, devel/p5-Sub-Exporter-ForMethods, that
> > > will be required to upgrade devel/p5-MooseX-Types.
> > >
> > > It has been created by portgen, i've just modified DESCR. 'make test'
> > > passes. There is not much to say about it, the module is ~20 SLOC ;)
> > >
> > >
> > > Comment:
> > > helper routines for using Sub::Exporter to build methods
> > >
> > > Description:
> > > This module provides helper routines for using Sub::Exporter to
> > > build methods.
> > >
> > >
> > > Comments and feedback are welcome.
> > >
> > > Charlène.
> >
> > Running update-plist adds missing directories
>
> Hmm, it shouldn't - ${P5SITE}/Sub/Exporter/ is provided by
> devel/p5-Sub-Exporter which is in RUN_DEPENDS so update-plist strips
> it from the plist.
>
> $ make plist
> ===> Updating plist for p5-Sub-Exporter-ForMethods-0.100052
> Reading existing plist for p5-Sub-Exporter-ForMethods-0.100052
> Scanning /usr/obj/ports/p5-Sub-Exporter-ForMethods-0.100052/fake-amd64
> Figuring out tie points
> Tieing loose objects
> Copying objects
> Stripping directories from devel/p5-Sub-Exporter
> Stripping directories from devel/p5-Sub-Install
>
I did try again on another system (amd64) and I did have different
result. I'll try again once I can access the other system (powerpc)
where update-plist did find some changes, there has to be an
explanation.
> > at configure time, the port yiels this, not sure if it's an error
> > though, this seems to happens in a lot of perl ports, I'm not sure
> > but maybe using LIB_DEPENDS instead of RUN_DEPENDS would solve it.
> >
> > Warning: prerequisite Sub::Exporter 0.978 not found.
> > Warning: prerequisite Sub::Name 0 not found.
>
> That is OK, these are deliberately only listed as RUN_DEPENDS to avoid
> pulling in half the world for builds. They aren't really needed at build
> time.
>
> LIB_DEPENDS can only ever be used where that port provides a library used
> in WANTLIB.
>
thanks for explanations. I thought LIB_DEPENDS could be used to replace
a port path present in both RUN_DEPENDS and BUILD_DEPENDS
Re: games/gzdoom disable JIT on amd64
On Tue, Feb 12 2019, Solene Rapenne wrote:
> brynet@ spotted that gzdoom wasn't W^X compliant due to a JIT engine
> getting enabled automatically on amd64.
>
> This patch makes vm_jit knob at false by default instead of being true.
> I did not see performance impact on my i7 when it's disabled, but this
> could be interesting if someone could test it.
>
> Without the patch, it's possible to disable JIT with the parameter
> '+vm_jit false'. While now we can still enable it with '+vm_jit true'
> (with W^X violation).
>
> I don't know if we should let it as this and add WX_NEEDED or patch it
> out so it doesn't WX by default?
Note that there's a third approach for such ports: try to make the JIT
W^X compliant. Here, it doesn't seem trivial (look for kVMExecutable).
So your proposal makes sense to me, ok jca@ with a REVISION bump. If
runtime still works, ofc, but I'll leave tests to actual users. :)
> Index: patches/patch-src_scripting_vm_vmframe_cpp
> ===
> RCS file: patches/patch-src_scripting_vm_vmframe_cpp
> diff -N patches/patch-src_scripting_vm_vmframe_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_scripting_vm_vmframe_cpp12 Feb 2019 06:04:57
> -
> @@ -0,0 +1,16 @@
> +$OpenBSD$
> +
> +disable JIT so it's W^X compatible
> +
> +Index: src/scripting/vm/vmframe.cpp
> +--- src/scripting/vm/vmframe.cpp.orig
> src/scripting/vm/vmframe.cpp
> +@@ -49,7 +49,7 @@
> + #endif
> +
> + #ifdef ARCH_X64
> +-CUSTOM_CVAR(Bool, vm_jit, true, CVAR_NOINITCALL)
> ++CUSTOM_CVAR(Bool, vm_jit, false, CVAR_NOINITCALL)
> + {
> + Printf("You must restart " GAMENAME " for this change to take
> effect.\n");
> + Printf("This cvar is currently not saved. You must specify it on the
> command line.");
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sparc64 C++ exception fix for gcc8
On Fri, Feb 08, 2019 at 09:07:23PM +0100, Otto Moerbeek wrote:
> Hi,
>
> This fixes regresss/misc/exceptions on sparc64
>
> OK?
ping...
>
> -Otto
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/gcc/8/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 13 Jan 2019 11:59:18 - 1.4
> +++ Makefile 8 Feb 2019 20:06:32 -
> @@ -11,7 +11,7 @@ DPB_PROPERTIES = parallel
> V = 8.2.0
> FULL_VERSION = $V
> FULL_PKGVERSION = $V
> -REVISION = 0
> +REVISION = 1
>
> ADASTRAP_LIBC-amd64 = 93.0
> ADASTRAP_LIBM-amd64 = 10.1
> Index: patches/patch-libgcc_unwind-dw2_c
> ===
> RCS file: patches/patch-libgcc_unwind-dw2_c
> diff -N patches/patch-libgcc_unwind-dw2_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-libgcc_unwind-dw2_c 8 Feb 2019 20:06:32 -
> @@ -0,0 +1,53 @@
> +$OpenBSD$
> +
> +Index: libgcc/unwind-dw2.c
> +--- libgcc/unwind-dw2.c.orig
> libgcc/unwind-dw2.c
> +@@ -215,6 +215,25 @@ _Unwind_IsExtendedContext (struct _Unwind_Context *con
> + return (ASSUME_EXTENDED_UNWIND_CONTEXT
> + || (context->flags & EXTENDED_CONTEXT_BIT));
> + }
> ++
> ++#ifdef __sparc64__
> ++
> ++/* Figure out StackGhost cookie. */
> ++_Unwind_Word uw_get_wcookie(void);
> ++
> ++asm(".text\n"
> ++"uw_get_wcookie:\n"
> ++" add %o7, %g0, %g4\n"
> ++" save %sp, -176, %sp\n"
> ++" save %sp, -176, %sp\n"
> ++" flushw\n"
> ++" restore\n"
> ++" ldx [%sp + 2047 + 120], %g5\n"
> ++" xor %g4, %g5, %i0\n"
> ++" ret\n"
> ++"restore\n");
> ++#endif
> ++
> +
> + /* Get the value of register REGNO as saved in CONTEXT. */
> +
> +@@ -245,6 +264,13 @@ _Unwind_GetGR (struct _Unwind_Context *context, int re
> + }
> + #endif
> +
> ++#ifdef __sparc64__
> ++ /* _Unwind_Word and _Unwind_Ptr are the same size on sparc64 */
> ++ _Unwind_Word reg = * (_Unwind_Word *) val;
> ++ if (index == 15 || index == 31)
> ++reg ^= uw_get_wcookie ();
> ++ return reg;
> ++#else
> + /* This will segfault if the register hasn't been saved. */
> + if (size == sizeof(_Unwind_Ptr))
> + return * (_Unwind_Ptr *) (_Unwind_Internal_Ptr) val;
> +@@ -253,6 +279,7 @@ _Unwind_GetGR (struct _Unwind_Context *context, int re
> + gcc_assert (size == sizeof(_Unwind_Word));
> + return * (_Unwind_Word *) (_Unwind_Internal_Ptr) val;
> + }
> ++#endif
> + }
> +
> + static inline void *
>
Re: Update to exiv2-0.27.0
On Mon, Feb 11 2019, Daniel Jakots wrote:
> Anyone cares to test it?
Tested, looks good overall but I have a bunch of tweaks to propose.
Note that as is, this update won't build if exiv2-0.26 is already
installed. The error points at a function with a fishy name,
getProcessPath(), which wasn't there in previous versions.
This function is now in the public API exported by
include/exiv2/futils.hpp. It can't work on OpenBSD. Shame, its main
use is to find the .mo files now that exiv2 supports i18n.
So here's a revised diff with the following changes:
- remove Exiv2::getProcessPath() from the public API. My take is that
it's easier to spot build failures rather than runtime failures, in
this situation. IMO upstream made a mistake to publish this function,
I'd like to try and convince them to deprecate it.
- stop using getProcessPath() in exiv2 source code, instead use the
PREFIX passed at configure time, just like 99% of software out there.
- drop patches/patch-src_http_cpp, not needed any more
- drop visibility workaround in patches/patch-src_version_cpp, not
needed any more
- don't force-disable XMP. What we want is to remove libxmp.a from
installed files, we don't want to disable XMP support in libexiv2
itself. A "funny" side-effect is that expat is now detected again,
which in turn builds and installs the geotag executable from the
samples directory...
- also drop -DEXV_HAVE_PROCESS_H=OFF, not needed in my tests
I'm a bit sceptical regarding the new programs. Are they really that
useful? Aren't they built/installed just because cmake...?
IIUC Daniel's diff hasn't seen bulk build yet, which is probably
desirable. But first I'd like to hear feedback/objections regarding the
changes proposed above.
Index: Makefile
===
RCS file: /cvs/ports/graphics/exiv2/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile24 Oct 2018 14:28:05 - 1.28
+++ Makefile12 Feb 2019 16:57:09 -
@@ -2,12 +2,11 @@
COMMENT= manipulate image meta-data such as exif and ipct
-DISTNAME= exiv2-0.26-trunk
-PKGNAME= exiv2-0.26
+DISTNAME= exiv2-0.27.0-Source
+PKGNAME= exiv2-0.27.0
CATEGORIES=graphics devel
-REVISION= 0
-SHARED_LIBS += exiv29.0 # 14.0
+SHARED_LIBS += exiv210.0 # 14.0
HOMEPAGE= http://www.exiv2.org/
@@ -20,18 +19,34 @@ COMPILER = base-clang ports-gcc base-gc
MASTER_SITES= http://www.exiv2.org/builds/
-USE_GMAKE= Yes
+MODULES= devel/cmake
-CONFIGURE_STYLE=gnu
+CFLAGS += -I${LOCALBASE}/include
+CXXFLAGS +=-I${LOCALBASE}/include
-BUILD_DEPENDS= devel/gettext-tools
+BUILD_DEPENDS= devel/gettext-tools \
+ devel/gtest
LIB_DEPENDS= devel/gettext
-CONFIGURE_ARGS=--enable-static
+TEST_DEPENDS= converters/dos2unix \
+ shells/bash
-NO_TEST= Yes
+CONFIGURE_ARGS += -DEXIV2_BUILD_UNIT_TESTS=ON
+CONFIGURE_ARGS += -DEXIV2_BUILD_PO=ON
-WRKDIST= ${WRKDIR}/exiv2-trunk
+TEST_TARGET = tests
+
+# dos line-endings in file needing patch
+post-extract:
+ @cd ${WRKSRC} && perl -i -pe 's/\r$$//'
${WRKSRC}/cmake/compilerFlags.cmake
+
+post-install:
+ find ${WRKINST} -name '._*' -delete
+ rm ${PREFIX}/include/exiv2/*.orig
+ rm ${PREFIX}/lib/libxmp.a
+
+pre-test:
+ @sed -Ei 's,!/bin/(ba)?sh,!/usr/bin/env bash,g' ${WRKSRC}/test/*.sh
.include
Index: distinfo
===
RCS file: /cvs/ports/graphics/exiv2/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo5 Apr 2018 21:21:52 - 1.12
+++ distinfo12 Feb 2019 16:57:09 -
@@ -1,2 +1,2 @@
-SHA256 (exiv2-0.26-trunk.tar.gz) = x148SggRv3ANksgjGTc7eoJaIzHBK4s31B61jk8Y6vs=
-SIZE (exiv2-0.26-trunk.tar.gz) = 5677925
+SHA256 (exiv2-0.27.0-Source.tar.gz) =
7oi8gVObc8ZQEGUXhdCU+tCzl2CkJLPBbBfhhWz+8tc=
+SIZE (exiv2-0.27.0-Source.tar.gz) = 27222970
Index: patches/patch-cmake_compilerFlags_cmake
===
RCS file: patches/patch-cmake_compilerFlags_cmake
diff -N patches/patch-cmake_compilerFlags_cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-cmake_compilerFlags_cmake 12 Feb 2019 16:57:09 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+- warnings about c++locale.h clutter the build
+
+Index: cmake/compilerFlags.cmake
+--- cmake/compilerFlags.cmake.orig
cmake/compilerFlags.cmake
+@@ -30,7 +30,7 @@ if ( MINGW OR UNIX OR MSYS ) # MINGW, Linux, APPLE, CY
+ set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --coverage")
+ endif()
+
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wcast-align
-Wpointer-arith -Wformat-security -Wmissing-format-attribute
-Woverloaded-virtual -W")
++set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wcast-align
-Wpointer
new mail/p5-Mail-DMARC-Iterator
Hi ok to import p5-Mail-DMARC-Iterator ? Comment: iterative DMARC validation for mails Description: This module can be used to validate mails against DMARC policies like specified in RFC 7208. The main difference to Mail::DMARC is that it does no blocking operations. Instead it implements a state machine where user input is fed into and instructions what the machine wants is returned. The state machine only wants the data from the mail and the result of specific DNS lookups. With each new data fed into the machine it will provide new information what it needs next, until it finally has enough input and returns the final result. Because of this design the DMARC policy validation can be easily integrated into event-driven programs or coupled with a specific DNS resolver. bluhm p5-Mail-DMARC-Iterator.tgz Description: application/tar-gz
Re: mail/mblaze: update to 0.5
Sunil Nimmagadda wrote:
> Hi,
>
> The changelog...
> * New tool msearch to wrap several mail indexers.
> * New zsh completion _mblaze.
> * mnext/mprev were removed (you can call `mless +`/`mless -`).
> * The GnuPG tools in contrib/ now use gpg2.
> * mshow exits with error if it could not extract all attachments
> * mrep: add -noquote to disable quoting the message replied to
> * mdeliver: keep permissions of messages
> * mcom: aborting the editor is now more like delete than cancel
> * mcom: add -send to send directly without editing
> * mcom: check if mail is formatted sensibly
> * mpick: new flag -v for statistics
> * mscan: new flag -v for statistics
> * magrep: add -h, which is like -p but doesn't print the file name
> * mscan: prioritize displaying trashed mail over other markers
> * mpick: fix off-by-one in expression parsing
> * Many bug fixes
>
> Ok?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/mblaze/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 31 Aug 2018 10:31:41 - 1.4
> +++ Makefile 9 Feb 2019 15:03:59 -
> @@ -2,7 +2,7 @@
>
> COMMENT =set of Maildir utilities
>
> -VERSION =0.4
> +VERSION =0.5
> DISTNAME = mblaze-${VERSION}
> GH_ACCOUNT = chneukirchen
> GH_PROJECT = mblaze
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/mblaze/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 31 Aug 2018 10:31:41 - 1.3
> +++ distinfo 9 Feb 2019 15:04:10 -
> @@ -1,2 +1,2 @@
> -SHA256 (mblaze-0.4.tar.gz) = g9/9f+dPqHFkLpfblOJ8BFBvdG+k1rovlcGogGONbgw=
> -SIZE (mblaze-0.4.tar.gz) = 85934
> +SHA256 (mblaze-0.5.tar.gz) = Myec8PRowD0y6MH44FbPFwBewwISY0FQv+DZDG5Pkm4=
> +SIZE (mblaze-0.5.tar.gz) = 90587
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/mail/mblaze/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -r1.3 PLIST
> --- pkg/PLIST 31 Aug 2018 10:31:41 - 1.3
> +++ pkg/PLIST 9 Feb 2019 15:05:24 -
> @@ -18,9 +18,7 @@ bin/mless
> @bin bin/mlist
> @bin bin/mmime
> bin/mmkdir
> -bin/mnext
> @bin bin/mpick
> -bin/mprev
> bin/mquote
> bin/mrefile
> bin/mrep
works fine here, I was awaiting fixes from this version :)
ok solene@
Re: [maintainer update] www/py-jwt
hello,
On 2019/02/11 12:46, Stuart Henderson wrote:
> On 2019/02/07 16:44, Pamela Mosiejczuk wrote:
>>
>>
>> On 1/30/19 12:10 PM, Johan Huldtgren wrote:
>>> On 2019-01-20 17:41, Johan Huldtgren wrote:
hello,
minor update of py-jwt from 1.6.4 to 1.7.1, built,
packaged, and tested with py-discogs-client on
amd64.
>>>
>>> ping?
>>>
>>> .jh
>>>
>>
>> Hi Johan,
>> With this release's new test dependency version ranges, the tests now
>> download them from pypi, rather than using ours. Perhaps it is better to
>> simply disable tests?
>
> Best fix is to port or update the dependencies (it will only try to fetch from
> pypi if they are not present or too old) .. though even if they're not updated
> I think I'd rather not just knock out the tests completely because they are
> still useful. Maybe leave them enabled but with an XXX comment.
I had never seen the original mail from Pamela (guess I have to take a closer
look at what is being blocked by my mailserver - make sure to cc my gmail for
the time being). I will look into this during the week and see if I can come
up with a better diff. Thanks for seeing this.
.jh
>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/www/py-jwt/Makefile,v
>> retrieving revision 1.12
>> diff -u -p -r1.12 Makefile
>> --- Makefile 1 Jul 2018 06:26:52 - 1.12
>> +++ Makefile 7 Feb 2019 21:03:27 -
>> @@ -2,7 +2,7 @@
>>
>> COMMENT = JSON Web Token implementation in Python
>>
>> -MODPY_EGG_VERSION = 1.6.4
>> +MODPY_EGG_VERSION = 1.7.1
>> DISTNAME = PyJWT-${MODPY_EGG_VERSION}
>> PKGNAME = py-jwt-${MODPY_EGG_VERSION}
>> CATEGORIES =www
>> @@ -23,9 +23,8 @@ MODPY_SETUPTOOLS = Yes
>>
>> RUN_DEPENDS = security/py-cryptography${MODPY_FLAVOR}>=1.4.0
>>
>> -TEST_DEPENDS = devel/py-test${MODPY_FLAVOR} \
>> -devel/py-test-cov${MODPY_FLAVOR} \
>> -devel/py-test-runner${MODPY_FLAVOR}
>> +# Attempts to download dependencies from pypi
>> +NO_TEST = Yes
>>
>> post-install:
>> mv ${PREFIX}/bin/pyjwt ${PREFIX}/bin/pyjwt${MODPY_BIN_SUFFIX}
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/www/py-jwt/distinfo,v
>> retrieving revision 1.8
>> diff -u -p -r1.8 distinfo
>> --- distinfo 1 Jul 2018 06:26:52 - 1.8
>> +++ distinfo 7 Feb 2019 21:03:27 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (PyJWT-1.6.4.tar.gz) = TuQTs1fVP9P7RHBFd6+siOcuh4cWEWJw1yJyPWW0IXY=
>> -SIZE (PyJWT-1.6.4.tar.gz) = 41694
>> +SHA256 (PyJWT-1.7.1.tar.gz) = jVmpdvt3Pz5qOchWNjV8Tw4kJwc5TK2t2YFPXLqiDpY=
>> +SIZE (PyJWT-1.7.1.tar.gz) = 41979
>> Index: pkg/PLIST
>> ===
>> RCS file: /cvs/ports/www/py-jwt/pkg/PLIST,v
>> retrieving revision 1.3
>> diff -u -p -r1.3 PLIST
>> --- pkg/PLIST24 Apr 2017 09:30:00 - 1.3
>> +++ pkg/PLIST7 Feb 2019 21:03:27 -
>> @@ -1,4 +1,4 @@
>> -@comment $OpenBSD: PLIST,v 1.3 2017/04/24 09:30:00 sthen Exp $
>> +@comment $OpenBSD: PLIST,v$
>> bin/pyjwt${MODPY_BIN_SUFFIX}
>>
>> lib/python${MODPY_VERSION}/site-packages/PyJWT-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
>>
>> lib/python${MODPY_VERSION}/site-packages/PyJWT-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
>> @@ -18,6 +18,7 @@ lib/python${MODPY_VERSION}/site-packages
>>
>> lib/python${MODPY_VERSION}/site-packages/jwt/${MODPY_PYCACHE}api_jwt.${MODPY_PYC_MAGIC_TAG}pyc
>>
>> lib/python${MODPY_VERSION}/site-packages/jwt/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}pyc
>>
>> lib/python${MODPY_VERSION}/site-packages/jwt/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
>> +lib/python${MODPY_VERSION}/site-packages/jwt/${MODPY_PYCACHE}help.${MODPY_PYC_MAGIC_TAG}pyc
>>
>> lib/python${MODPY_VERSION}/site-packages/jwt/${MODPY_PYCACHE}utils.${MODPY_PYC_MAGIC_TAG}pyc
>> lib/python${MODPY_VERSION}/site-packages/jwt/algorithms.py
>> lib/python${MODPY_VERSION}/site-packages/jwt/api_jws.py
>> @@ -36,4 +37,5 @@ lib/python${MODPY_VERSION}/site-packages
>> lib/python${MODPY_VERSION}/site-packages/jwt/contrib/algorithms/py_ecdsa.py
>> lib/python${MODPY_VERSION}/site-packages/jwt/contrib/algorithms/pycrypto.py
>> lib/python${MODPY_VERSION}/site-packages/jwt/exceptions.py
>> +lib/python${MODPY_VERSION}/site-packages/jwt/help.py
>> lib/python${MODPY_VERSION}/site-packages/jwt/utils.py
>
Re: PATCH: include-what-you-use needs libLLVM-7.so at runtime
On 2019/02/12 22:39, Jonathan Gray wrote: > On Mon, Feb 11, 2019 at 09:03:52PM +0100, Caspar Schutijser wrote: > > Hi, > > > > $ ldd /usr/local/bin/include-what-you-use | grep libLLVM > > 00885d7d1000 00886139c000 rlib 01 0 > > /usr/local/lib/libLLVM-7.so > > > > Therefore, include-what-you-use won't run unless the llvm package is > > installed. The diff below makes sure llvm is installed when the user > > installs include-what-you-use but I'm not sure it is the right way > > to do it. > > Shouldn't it instead be added to LIB_DEPENDS and have a WANTLIB for > LLVM-7 ? I'd prefer that, but then the library would need a normal .so.X.Y filename.
Re: PATCH: include-what-you-use needs libLLVM-7.so at runtime
On Mon, Feb 11, 2019 at 09:03:52PM +0100, Caspar Schutijser wrote:
> Hi,
>
> $ ldd /usr/local/bin/include-what-you-use | grep libLLVM
> 00885d7d1000 00886139c000 rlib 01 0
> /usr/local/lib/libLLVM-7.so
>
> Therefore, include-what-you-use won't run unless the llvm package is
> installed. The diff below makes sure llvm is installed when the user
> installs include-what-you-use but I'm not sure it is the right way
> to do it.
Shouldn't it instead be added to LIB_DEPENDS and have a WANTLIB for
LLVM-7 ?
Dropping IWYU_LLVM_ROOT_PATH seems fine.
>
> While there; cmake notes the following:
> CMake Warning:
> Manually-specified variables were not used by the project:
>
> IWYU_LLVM_ROOT_PATH
>
> So this diff addresses that as well by removing the CONFIGURE_ARGS.
>
> Thanks,
> Caspar Schutijser
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/include-what-you-use/Makefile,v
> retrieving revision 1.14
> diff -u -p -r1.14 Makefile
> --- Makefile 28 Jan 2019 06:27:28 - 1.14
> +++ Makefile 11 Feb 2019 19:47:08 -
> @@ -4,6 +4,7 @@ COMMENT= tool to analyse \#includes in C
> CATEGORIES= devel
> DISTNAME=include-what-you-use-0.11.src
> PKGNAME= include-what-you-use-0.11
> +REVISION=0
>
> HOMEPAGE=http://include-what-you-use.org
> MASTER_SITES=${HOMEPAGE}/downloads/
> @@ -15,13 +16,14 @@ MAINTAINER= Jonathan Gray PERMIT_PACKAGE_CDROM=Yes
>
> WANTLIB= c curses execinfo form m pthread z
> -BUILD_DEPENDS= devel/llvm>=7.0.1
> +LLVM_V= 7.0.1
> +BUILD_DEPENDS= devel/llvm>=${LLVM_V}
> +RUN_DEPENDS= devel/llvm>=${LLVM_V}
> LIB_DEPENDS= devel/libexecinfo
>
> MODULES= devel/cmake lang/python
> COMPILER=base-clang ports-gcc
> COMPILER_LANGS= c++
> -CONFIGURE_ARGS= -DIWYU_LLVM_ROOT_PATH=${LOCALBASE}
>
> MODPY_ADJ_FILES = fix_includes.py iwyu_tool.py
>
>
Re: [new] www/esniper
On 2/12/19 11:44 AM, Stuart Henderson wrote: On 2019/02/05 12:55, Renaud Allard wrote: Any chances of getting it committed? I don't think we should be encouraging its use by having it in ports. Complex string parsing of a frequently updated website, in C, and the above bug isn't a good indication that they are getting things right (why does it even set CURL_POSTFIELDSIZE at all when it's doing a GET? why reuse a stale pointer?) - this is something I'd be wary of even for a standard website. But for something which has your ebay credentials? My comment about https wasn't so much "ports should change this" but more "the developers are insane if they think this is acceptable, what else are they doing wrong". OK, agreed, on the positive side, this story has led to a patch in libcurl. smime.p7s Description: S/MIME Cryptographic Signature
UPDATE: SMPLayer-19.1.0
Hello, Small update for SMPLayer to 19.1.0 https://www.smplayer.info/en/changes OK? Comments? Cheers.- -- Sending from my toaster. Index: Makefile === RCS file: /cvs/ports/x11/smplayer/Makefile,v retrieving revision 1.55 diff -u -p -r1.55 Makefile --- Makefile24 Oct 2018 07:45:42 - 1.55 +++ Makefile12 Feb 2019 10:41:53 - @@ -2,7 +2,7 @@ COMMENT = complete front-end for MPlayer and MPV -DISTNAME = smplayer-18.10.0 +DISTNAME = smplayer-19.1.0 CATEGORIES = multimedia x11 HOMEPAGE = http://smplayer.sourceforge.net/ Index: distinfo === RCS file: /cvs/ports/x11/smplayer/distinfo,v retrieving revision 1.39 diff -u -p -r1.39 distinfo --- distinfo24 Oct 2018 07:45:42 - 1.39 +++ distinfo12 Feb 2019 10:41:53 - @@ -1,2 +1,2 @@ -SHA256 (smplayer-18.10.0.tar.bz2) = Lf98mtLMbddX+WceSIhTGLf1DTKsOHnVrJocSFoOFOs= -SIZE (smplayer-18.10.0.tar.bz2) = 5167524 +SHA256 (smplayer-19.1.0.tar.bz2) = ekg9JMko+lHo1IMiz9fXR/pb9s9YdQXSmkTCVqu2Q2A= +SIZE (smplayer-19.1.0.tar.bz2) = 5169546
Re: [new] www/esniper
On 2019/02/05 12:55, Renaud Allard wrote: > > > On 2/1/19 3:38 PM, Renaud Allard wrote: > > > > Hi, > > > > I have made a change, in fact setting CURL_POSTFIELDSIZE to 0 when GET > > needs to be used. This resolves the segfault, but the -m option doesn't > > seem to be working yet, but I will report that to the dev. > > > > I also made patches to initialize curl the right way with LONG, limit > > the protocols to HTTP(S) and made it to prefer HTTPS. > > Also, I have changed the useragent to be more modern, and less like the > > default one in esniper. > > > > Best Regards > > Any chances of getting it committed? > I don't think we should be encouraging its use by having it in ports. Complex string parsing of a frequently updated website, in C, and the above bug isn't a good indication that they are getting things right (why does it even set CURL_POSTFIELDSIZE at all when it's doing a GET? why reuse a stale pointer?) - this is something I'd be wary of even for a standard website. But for something which has your ebay credentials? My comment about https wasn't so much "ports should change this" but more "the developers are insane if they think this is acceptable, what else are they doing wrong".
[update] mail/exim 4.62
Hello,
Here is a straightforward diff for exim-4.62
Best Regards
Index: Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.120
diff -u -p -r1.120 Makefile
--- Makefile 19 Apr 2018 20:52:43 - 1.120
+++ Makefile 12 Feb 2019 09:56:39 -
@@ -3,7 +3,7 @@
COMMENT-main = flexible mail transfer agent
COMMENT-eximon = X11 monitor tool for Exim MTA
-VERSION = 4.91
+VERSION = 4.92
DISTNAME = exim-${VERSION}
PKGNAME-main = exim-${VERSION}
FULLPKGNAME-eximon = exim-eximon-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/mail/exim/distinfo,v
retrieving revision 1.33
diff -u -p -r1.33 distinfo
--- distinfo 19 Apr 2018 20:52:43 - 1.33
+++ distinfo 12 Feb 2019 09:56:39 -
@@ -1,2 +1,2 @@
-SHA256 (exim-4.91.tar.gz) = yLTiggoeTjdpokyWb3BDLQLzBqnjpHg81Y93A1AKdJY=
-SIZE (exim-4.91.tar.gz) = 2407413
+SHA256 (exim-4.92.tar.gz) = ic4NEj9ExGbK1ZaoTiNG/bb79i+YPMDa9A69Z55gSYk=
+SIZE (exim-4.92.tar.gz) = 2427409
Re: UPDATE: maven 3.6.0
On 2019/02/12 10:14, Karel Gardas wrote: > On Mon, 11 Feb 2019 22:30:42 + > Stuart Henderson wrote: > > > > RCS file: /cvs/ports/devel/maven/pkg/PLIST,v > > > retrieving revision 1.10 > > > diff -u -p -u -r1.10 PLIST > > > --- pkg/PLIST 23 Apr 2018 10:41:52 - 1.10 > > > +++ pkg/PLIST 3 Feb 2019 20:03:16 - > > > @@ -14,103 +14,69 @@ maven/boot/ > > > > How did you generate this plist? Some directory entries are removed which > > shouldn't have been. > > That was done by hand. OK, will look into how to generate it properly. Thanks! "make plist" updates the file. Often you can just use the results directly, but it does need reviewing as it can't handle everything (especially for ports with flavours or multi-packages).
Re: www/iridium README about unveil
Just iridium user here. On Tue, 12 Feb 2019 07:02:31 +0100 Solene Rapenne wrote: > So, iridium can only display paths allowed in /etc/iridium/, this This "allowed in /etc/iridium/" is quite confusing. Shouldn't this be "allowed in /etc/iridium/unveil.main" unveil definition file for the main Iridium process" or something like that? > includes the following paths: > > ~/Documents ~/Downloads ~/Music > ~/Pictures ~/Videos/tmp > > If you need to upload a file, you need to make the file available in one of > those folders. > > When iridium file browser is showing up, it may be displaying an unauthorized > folder which will appear empty, which mean it is not possible to browse to > some > other location. One can use the keyboard shortcut Ctrl+L and type a path in > the > upper address bar to reach a whitelisted path. > > Unveil can be disabled with the parameter --disable-unveil ", but we highly discourage this practise" -- or something like that may be added here IMHO. Thanks! Karel
Re: UPDATE: lighttpd 1.4.53
Committed thanks. On Fri, Feb 08, 2019 at 04:53:38PM +0100, Solene Rapenne wrote: > On Fri, Feb 08, 2019 at 09:31:59AM -0500, Brad Smith wrote: > > Here is an update to lighttpd 1.4.53. > > > > > > Index: Makefile > > === > > RCS file: /home/cvs/ports/www/lighttpd/Makefile,v > > retrieving revision 1.155 > > diff -u -p -u -p -r1.155 Makefile > > --- Makefile29 Nov 2018 13:27:39 - 1.155 > > +++ Makefile3 Feb 2019 19:18:02 - > > @@ -2,7 +2,7 @@ > > > > COMMENT= secure, fast, compliant, and very flexible web-server > > > > -DISTNAME= lighttpd-1.4.52 > > +DISTNAME= lighttpd-1.4.53 > > CATEGORIES=www net > > MASTER_SITES= https://download.lighttpd.net/lighttpd/releases-1.4.x/ > > EXTRACT_SUFX= .tar.xz > > Index: distinfo > > === > > RCS file: /home/cvs/ports/www/lighttpd/distinfo,v > > retrieving revision 1.58 > > diff -u -p -u -p -r1.58 distinfo > > --- distinfo29 Nov 2018 13:27:39 - 1.58 > > +++ distinfo8 Feb 2019 14:07:50 - > > @@ -1,2 +1,2 @@ > > -SHA256 (lighttpd-1.4.52.tar.xz) = > > J7wJkcUwt8YzXm7/8hgZNNPBocUW90Aepx2DAs79p2Q= > > -SIZE (lighttpd-1.4.52.tar.xz) = 728668 > > +SHA256 (lighttpd-1.4.53.tar.xz) = > > O9/OHPPpZQpVaowm+xU0LFcXxj9TDFRpPbYysDcdy3g= > > +SIZE (lighttpd-1.4.53.tar.xz) = 732160 > > > > make test reports same failures/success as before > > on powerpc, make port-lib-depends-check reports "Extra estdc++.17" on the > vanilla and ldap flavor. I don't know if it's normal but it was already there > with 1.4.52 > > ok solene@ > -- Antoine
Re: UPDATE: maven 3.6.0
On Mon, 11 Feb 2019 22:30:42 + Stuart Henderson wrote: > > RCS file: /cvs/ports/devel/maven/pkg/PLIST,v > > retrieving revision 1.10 > > diff -u -p -u -r1.10 PLIST > > --- pkg/PLIST 23 Apr 2018 10:41:52 - 1.10 > > +++ pkg/PLIST 3 Feb 2019 20:03:16 - > > @@ -14,103 +14,69 @@ maven/boot/ > > How did you generate this plist? Some directory entries are removed which > shouldn't have been. That was done by hand. OK, will look into how to generate it properly. Thanks!
Re: [PATCH] pledge mail/abook
Sorry, forgot to increment the revision number in previous message.
On Tue, Feb 12, 2019 at 03:51:15AM -0500, Mohamed Aslan wrote:
> Hello,
>
> The diff below adds pledge(2) to mail/abook. Generally, abook
> requires the stdio, and {r,w,c}path promises. The tty promise is
> used for the curses user-interface, while proc and exec are needed
> for launching lpr (for printing) and mutt.
>
> Regards,
> Aslan
> Index: patch-abook_c
> ===
> RCS file: patch-abook_c
> diff -N patch-abook_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patch-abook_c 12 Feb 2019 08:32:45 -
> @@ -0,0 +1,20 @@
> +$OpenBSD$
> +
> +Pledge mail/abook.
> +Note: proc and exec promises are only needed for launching lpr and mutt.
> +
> +Index: abook.c
> +--- abook.c.orig
> abook.c
> +@@ -190,6 +190,11 @@ quit_abook_sig(int i)
> + int
> + main(int argc, char **argv)
> + {
> ++if (pledge("stdio rpath wpath cpath tty proc exec", NULL) == -1) {
> ++perror("pledge");
> ++exit(1);
> ++}
> ++
> + #if defined(HAVE_SETLOCALE) && defined(HAVE_LOCALE_H)
> + setlocale(LC_MESSAGES, "");
> + setlocale(LC_TIME, "");
--
Mohamed Aslan, Ph.D.
Postdoctoral Research Associate
Department of Systems and Computer Engineering
Carleton University
Ottawa, ON, Canada
http://www.sce.carleton.ca/~maslan/
Index: Makefile
===
RCS file: /cvs/ports/mail/abook/Makefile,v
retrieving revision 1.37
diff -u -p -u -r1.37 Makefile
--- Makefile8 Feb 2019 09:50:21 - 1.37
+++ Makefile12 Feb 2019 09:04:52 -
@@ -3,7 +3,7 @@
COMMENT= addressbook program with mutt support
DISTNAME= abook-0.6.1
-REVISION= 2
+REVISION= 3
CATEGORIES=mail
HOMEPAGE= http://abook.sourceforge.net/
Index: patches/patch-abook_c
===
RCS file: patches/patch-abook_c
diff -N patches/patch-abook_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-abook_c 12 Feb 2019 09:04:52 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Pledge mail/abook.
+Note: proc and exec promises are only needed for launching lpr and mutt.
+
+Index: abook.c
+--- abook.c.orig
abook.c
+@@ -190,6 +190,11 @@ quit_abook_sig(int i)
+ int
+ main(int argc, char **argv)
+ {
++ if (pledge("stdio rpath wpath cpath tty proc exec", NULL) == -1) {
++ perror("pledge");
++ exit(1);
++ }
++
+ #if defined(HAVE_SETLOCALE) && defined(HAVE_LOCALE_H)
+ setlocale(LC_MESSAGES, "");
+ setlocale(LC_TIME, "");
UPDATE: SQLMap-1.3.2
Update for SQLMap to 1.3.2, small update, some bug fixed. OK? comments? Cheers.- -- Sending from my toaster. Index: Makefile === RCS file: /cvs/ports/security/sqlmap/Makefile,v retrieving revision 1.14 diff -u -p -r1.14 Makefile --- Makefile7 Jan 2019 16:29:26 - 1.14 +++ Makefile12 Feb 2019 09:01:48 - @@ -4,7 +4,7 @@ COMMENT = penetration testing tool to d GH_ACCOUNT = sqlmapproject GH_PROJECT = sqlmap -GH_TAGNAME = 1.3 +GH_TAGNAME = 1.3.2 CATEGORIES = security Index: distinfo === RCS file: /cvs/ports/security/sqlmap/distinfo,v retrieving revision 1.12 diff -u -p -r1.12 distinfo --- distinfo7 Jan 2019 16:29:26 - 1.12 +++ distinfo12 Feb 2019 09:01:48 - @@ -1,2 +1,2 @@ -SHA256 (sqlmap-1.3.tar.gz) = fqRoTgGVbkEZYKX9im1bdLP1lywqPGVT+9HnKYGRkP8= -SIZE (sqlmap-1.3.tar.gz) = 7431942 +SHA256 (sqlmap-1.3.2.tar.gz) = Lcz/B7kY2sFHP4MEHF3kJSFg4w7APPWAMoiRW5HPZak= +SIZE (sqlmap-1.3.2.tar.gz) = 7435538 Index: pkg/PLIST === RCS file: /cvs/ports/security/sqlmap/pkg/PLIST,v retrieving revision 1.12 diff -u -p -r1.12 PLIST --- pkg/PLIST 7 Jan 2019 16:29:26 - 1.12 +++ pkg/PLIST 12 Feb 2019 09:01:48 - @@ -6,6 +6,7 @@ share/sqlmap/.github/CODE_OF_CONDUCT.md share/sqlmap/.github/CONTRIBUTING.md share/sqlmap/.github/ISSUE_TEMPLATE.md share/sqlmap/.travis.yml +share/sqlmap/COMMITMENT share/sqlmap/LICENSE share/sqlmap/extra/ share/sqlmap/extra/__init__.py @@ -943,18 +944,16 @@ share/sqlmap/waf/asm.py share/sqlmap/waf/asm.pyc share/sqlmap/waf/aws.py share/sqlmap/waf/aws.pyc -share/sqlmap/waf/baidu.py -share/sqlmap/waf/baidu.pyc share/sqlmap/waf/barracuda.py share/sqlmap/waf/barracuda.pyc -share/sqlmap/waf/bigip.py -share/sqlmap/waf/bigip.pyc -share/sqlmap/waf/binarysec.py -share/sqlmap/waf/binarysec.pyc -share/sqlmap/waf/blockdos.py -share/sqlmap/waf/blockdos.pyc +share/sqlmap/waf/bekchy.py +share/sqlmap/waf/bekchy.pyc +share/sqlmap/waf/bitninja.py +share/sqlmap/waf/bitninja.pyc share/sqlmap/waf/bluedon.py share/sqlmap/waf/bluedon.pyc +share/sqlmap/waf/cerber.py +share/sqlmap/waf/cerber.pyc share/sqlmap/waf/chinacache.py share/sqlmap/waf/chinacache.pyc share/sqlmap/waf/ciscoacexml.py @@ -969,14 +968,8 @@ share/sqlmap/waf/comodo.py share/sqlmap/waf/comodo.pyc share/sqlmap/waf/crawlprotect.py share/sqlmap/waf/crawlprotect.pyc -share/sqlmap/waf/datapower.py -share/sqlmap/waf/datapower.pyc -share/sqlmap/waf/denyall.py -share/sqlmap/waf/denyall.pyc share/sqlmap/waf/distil.py share/sqlmap/waf/distil.pyc -share/sqlmap/waf/dosarrest.py -share/sqlmap/waf/dosarrest.pyc share/sqlmap/waf/dotdefender.py share/sqlmap/waf/dotdefender.pyc share/sqlmap/waf/edgecast.py @@ -987,32 +980,42 @@ share/sqlmap/waf/fortiweb.py share/sqlmap/waf/fortiweb.pyc share/sqlmap/waf/generic.py share/sqlmap/waf/generic.pyc -share/sqlmap/waf/hyperguard.py -share/sqlmap/waf/hyperguard.pyc +share/sqlmap/waf/godaddy.py +share/sqlmap/waf/godaddy.pyc +share/sqlmap/waf/greywizard.py +share/sqlmap/waf/greywizard.pyc +share/sqlmap/waf/imunify360.py +share/sqlmap/waf/imunify360.pyc share/sqlmap/waf/incapsula.py share/sqlmap/waf/incapsula.pyc share/sqlmap/waf/isaserver.py share/sqlmap/waf/isaserver.pyc +share/sqlmap/waf/janusec.py +share/sqlmap/waf/janusec.pyc share/sqlmap/waf/jiasule.py share/sqlmap/waf/jiasule.pyc share/sqlmap/waf/knownsec.py share/sqlmap/waf/knownsec.pyc share/sqlmap/waf/kona.py share/sqlmap/waf/kona.pyc +share/sqlmap/waf/malcare.py +share/sqlmap/waf/malcare.pyc share/sqlmap/waf/modsecurity.py share/sqlmap/waf/modsecurity.pyc share/sqlmap/waf/naxsi.py share/sqlmap/waf/naxsi.pyc -share/sqlmap/waf/netcontinuum.py -share/sqlmap/waf/netcontinuum.pyc share/sqlmap/waf/netscaler.py share/sqlmap/waf/netscaler.pyc share/sqlmap/waf/newdefend.py share/sqlmap/waf/newdefend.pyc -share/sqlmap/waf/nsfocus.py -share/sqlmap/waf/nsfocus.pyc +share/sqlmap/waf/ninjafirewall.py +share/sqlmap/waf/ninjafirewall.pyc +share/sqlmap/waf/onmessageshield.py +share/sqlmap/waf/onmessageshield.pyc share/sqlmap/waf/paloalto.py share/sqlmap/waf/paloalto.pyc +share/sqlmap/waf/perimeterx.py +share/sqlmap/waf/perimeterx.pyc share/sqlmap/waf/profense.py share/sqlmap/waf/profense.pyc share/sqlmap/waf/proventia.py @@ -1023,42 +1026,54 @@ share/sqlmap/waf/reblaze.py share/sqlmap/waf/reblaze.pyc share/sqlmap/waf/requestvalidationmode.py share/sqlmap/waf/requestvalidationmode.pyc +share/sqlmap/waf/rsfirewall.py +share/sqlmap/waf/rsfirewall.pyc share/sqlmap/waf/safe3.py share/sqlmap/waf/safe3.pyc share/sqlmap/waf/safedog.py share/sqlmap/waf/safedog.pyc +share/sqlmap/waf/secureentry.py +share/sqlmap/waf/secureentry.pyc share/sqlmap/waf/secureiis.py share/sqlmap/waf/secureiis.pyc +share/sqlmap/waf/securesphere.py +share/s
[PATCH] pledge mail/abook
Hello,
The diff below adds pledge(2) to mail/abook. Generally, abook
requires the stdio, and {r,w,c}path promises. The tty promise is
used for the curses user-interface, while proc and exec are needed
for launching lpr (for printing) and mutt.
Regards,
Aslan
Index: patch-abook_c
===
RCS file: patch-abook_c
diff -N patch-abook_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patch-abook_c 12 Feb 2019 08:32:45 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Pledge mail/abook.
+Note: proc and exec promises are only needed for launching lpr and mutt.
+
+Index: abook.c
+--- abook.c.orig
abook.c
+@@ -190,6 +190,11 @@ quit_abook_sig(int i)
+ int
+ main(int argc, char **argv)
+ {
++ if (pledge("stdio rpath wpath cpath tty proc exec", NULL) == -1) {
++ perror("pledge");
++ exit(1);
++ }
++
+ #if defined(HAVE_SETLOCALE) && defined(HAVE_LOCALE_H)
+ setlocale(LC_MESSAGES, "");
+ setlocale(LC_TIME, "");
