Re: New: stratagus
Forgot about this one... Can anyone with ninja-skills have a look at this? martijn@ On Mon, 2024-02-12 at 15:01 -0500, Thomas Frohwein wrote: > On Mon, Feb 12, 2024 at 07:12:56PM +0100, Martijn van Duren wrote: > > $ cat stratagus/pkg/DESCR > > Stratagus is a free cross-platform real-time strategy gaming engine. It > > includes support for playing over the internet/LAN, or playing a > > computer opponent. The engine is configurable and can be used to create > > games with a wide-range of features specific to your needs. Stratagus is > > written in C++. > > > > This is a dependency for war1gus and wargus, a warcraft orcs and humans, > > and warcraft 2 open source reimplementation respectively (need original > > assets). > > > > Both the changes to the CMakeLists.txt are probably wrong/not needed, > > but outside the scope of my knowledge, so if someone would at least > > look those over it would be appreciated. > > Thanks for sharing this! I looked at it a little; this is a trickier > project. The main thing I'm bumping into is that you set > "USE_NINJA=No" which doesn't seem to be intended (either "yes" or > "samurai"). The result is that none of the flags from > MODCMAKE_BUILD_TARGET are used and instead it builds with cmake with > no arguments. When I try using our regular MODCMAKE_BUILD_TARGET (by > removing the USE_NINJA line), it then somehow doesn't build the > vendored lua dependencies including the needed .a file before it's > needed. I would have thought that this line in CMakeLists.txt should > ensure that: > > add_dependencies(stratagus Lua51B) > > but that doesn't seem to be the case. Maybe someone with more cmake > knowledge can better spot why this only works with empty > MODCMAKE_BUILD_TARGET. > > Here a few other nits: > > - remove leading article in COMMENT > - drop devel/sdl2 LDEP (is pulled in by sdl2-mixer and sdl2-image) > -> same for audio/libogg > - setting WRKDIST not be needed as DISTNAME already set correctly > - disable doxygen? (low quality docs; don't set ENABLE_DOC) > - add archivers/innoextract to RDEP? (see patches - this is used by runtime) > - variables USE_OPENMP and USE_BACKTRACE are not used by cmake (see > make configure output) > > > PS: > > $ make show=MODCMAKE_BUILD_TARGET > cd /usr/ports/pobj/stratagus-3.3.2/build-amd64 && exec /usr/bin/env -i > MODCMAKE_USE_SHARED_LIBS=yes MODCMAKE_PORT_BUILD=yes PORTSDIR="/usr/ports" > LIBTOOL="/usr/bin/libtool" > PATH='/usr/ports/pobj/stratagus-3.3.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin' > PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' > CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' > HOME='/stratagus-3.3.2_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin > BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c > INSTALL_STRIP=-s MANGRP=bin MANOWN=root MANMODE=644 > BSD_INSTALL_PROGRAM="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -s -m > 755" BSD_INSTALL_SCRIPT="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -m > 755" BSD_INSTALL_DATA="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -m > 644" BSD_INSTALL_MAN="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -m 644" > BSD_INSTALL_PROGRAM_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d -m > 755" BSD_INSTALL_SCRIPT_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d > -m 755" BSD_INSTALL_DATA_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d > -m 755" BSD_INSTALL_MAN_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d > -m 755" cmake --build /usr/ports/pobj/stratagus-3.3.2/build-amd64 --verbose > -j 1 > > > One issue is that sound doesn't play with video cut scenes and is > > something that boils up from SDL2's Mix_LoadMUS or Mix_LoadMUS_RW in > > stratagus' src/sound/sound_server.cpp's LoadMusic(). > > > > martijn@ > >
Re: vbam: enable wxWidgets/visualboyadvance-m
On Mon, 2024-05-06 at 00:51 -0600, Anthony J. Bentley wrote:
> Martijn van Duren writes:
> > Back in 2018 Jasper explicitly disabled wxWidgets on vbam so it wouldn't
> > accidentally get picked up. I reckon it would be worth it to enable it
> > explicitly, since it would build the visualboyadvance-m binary.
> >
> > Not only brings it some menu options which allows you to change things
> > at runtime, it also brings in some features I couldn't find in vbam:
> > most notably the link (network) option. Without it battling your
> > friends, or completing your pokedex will be impossible. :-)
>
> I agree, we should provide the wx frontend since it has extra features.
After some testing I found that the networking feature isn't as stable
as I hoped. From the same source it works a lot better on Linux.
However I still think it's worth it.
>
> > I placed visualboyadvance-m inside the vbam package for quick testing,
> > but considering it pulls in extra dependencies and is its own thing
> > it might be cleaner to put it in its own subpackage.
>
> I agree, we also provide separate packages in similar cases like mgba
> and mgba-qt.
>
> The hard part :) is what to name the wx package. We shouldn't call it
> "visualboyadvance-m" after the executable, because nobody looking at
> the package names will know the difference between the "vbam" and
> "visualboyadvance-m" packages. So maybe vbam-wxwidgets?
I personally would've gone for visualboyadvance-m, but I don't care
enough about the name and went with your suggestion.
>
> > +@tag update-desktop-database
> > +@tag gtk-update-icon-cache %D/share/icons/hicolor
>
> Needs additional RUN_DEPENDS.
>
Fixed
Somehow update-plist added share/applications/, and share/icons...
I've left in the new PLIST-main, but I think it's worth explicit
mentioning.
Index: Makefile
===
RCS file: /cvs/ports/emulators/vbam/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- Makefile7 Feb 2024 20:51:39 - 1.41
+++ Makefile17 May 2024 10:39:57 -
@@ -1,13 +1,16 @@
BROKEN-alpha = ICE or OOM on hq_implementation.cpp
BROKEN-hppa = ICE or OOM on src/filters/hq/c/hq_base.h:421
-COMMENT = emulator for Nintendo Game Boy (Color/Advance)
+COMMENT-main = emulator for Nintendo Game Boy (Color/Advance)
+COMMENT-wxwidgets =emulator for Nintendo Game Boy (Color/Advance) with GUI
GH_ACCOUNT = visualboyadvance-m
GH_PROJECT = ${GH_ACCOUNT}
GH_TAGNAME = v2.1.9
PKGNAME = vbam-${GH_TAGNAME:S/v//}
+MULTI_PACKAGES = -main -wxwidgets
+
CATEGORIES = emulators
HOMEPAGE = https://www.vba-m.com
@@ -15,9 +18,15 @@ HOMEPAGE = https://www.vba-m.com
# GPLv2+ (see doc/License.txt)
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX}
-WANTLIB += GL GLU SDL2 c charset iconv intl m sfml-network sfml-system
-WANTLIB += z
+cWANTLIB += ${COMPILER_LIBCXX}
+cWANTLIB += GL GLU SDL2 c charset iconv intl m sfml-network sfml-system
+cWANTLIB += z
+
+WANTLIB-main = ${cWANTLIB}
+WANTLIB-wxwidgets =${cWANTLIB}
+WANTLIB-wxwidgets += wx_gtk3u_xrc-3.2 wx_baseu_xml-3.2 wx_gtk3u_html-3.2
+WANTLIB-wxwidgets += wx_baseu_net-3.2 wx_gtk3u_core-3.2 wx_baseu-3.2
wx_gtk3u_gl-3.2
+WANTLIB-wxwidgets += wx_gtk3u_gl-3.2
MODULES = devel/cmake
@@ -25,13 +34,20 @@ MODULES = devel/cmake
COMPILER = base-clang ports-gcc
BUILD_DEPENDS =devel/gettext,-tools
+# visualboyadvance-m
+BUILD_DEPENDS += archivers/zip
-LIB_DEPENDS = devel/gettext,-runtime \
+cLIB_DEPENDS = devel/gettext,-runtime \
devel/sdl2 \
multimedia/sfml
+LIB_DEPENDS-main = ${cLIB_DEPENDS}
+LIB_DEPENDS-wxwidgets += ${cLIB_DEPENDS} x11/wxWidgets
+
+RUN_DEPENDS-wxwidgets =devel/desktop-file-utils \
+ x11/gtk+4,-guic
CONFIGURE_ARGS += -DENABLE_FFMPEG=OFF \
- -DENABLE_WX=OFF \
+ -DENABLE_WX=ON \
-DENABLE_SDL=ON
# Creates unlinkable files ('data' according to file(1))
CONFIGURE_ARGS += -DENABLE_LTO=OFF
Index: patches/patch-src_wx_panel_cpp
===
RCS file: patches/patch-src_wx_panel_cpp
diff -N patches/patch-src_wx_panel_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_wx_panel_cpp 17 May 2024 10:39:57 -
@@ -0,0 +1,27 @@
+Index: src/wx/panel.cpp
+--- src/wx/panel.cpp.orig
src/wx/panel.cpp
+@@ -2309,6 +2309,7 @@ void GLDrawingPanel::DrawingPanelInit()
+ else
+ wxLogDebug(_("Disabling GLX VSync."));
+
+
vbam: enable wxWidgets/visualboyadvance-m
Hello ports,
Back in 2018 Jasper explicitly disabled wxWidgets on vbam so it wouldn't
accidentally get picked up. I reckon it would be worth it to enable it
explicitly, since it would build the visualboyadvance-m binary.
Not only brings it some menu options which allows you to change things
at runtime, it also brings in some features I couldn't find in vbam:
most notably the link (network) option. Without it battling your
friends, or completing your pokedex will be impossible. :-)
Some notes about the changes:
I placed visualboyadvance-m inside the vbam package for quick testing,
but considering it pulls in extra dependencies and is its own thing
it might be cleaner to put it in its own subpackage.
The patch is needed because glXGetCurrentDisplay() can return NULL,
which crashes glXSwapIntervalEXT(). I don't have much knowledge of X,
but considering the function itself is already behind an if statement I
simply expanded said statement with the glXGetCurrentDisplay() check.
It runs great for me with this diff, but I'm not making any claims about
its correctness.
I'm not quite sure about the new LIB_DEPENDS, since it's quite a list
from wxWidgets, for which there might be something more convenient that
I'm not aware of. There's also a few libraries explicitly linked to
visualboyadvance-m, which are dependencies of wxWidgets and I thus left
out of LIB_DEPENDS.
martijn@
Index: Makefile
===
RCS file: /cvs/ports/emulators/vbam/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- Makefile7 Feb 2024 20:51:39 - 1.41
+++ Makefile23 Apr 2024 15:33:12 -
@@ -30,8 +30,15 @@ LIB_DEPENDS =devel/gettext,-runtime \
devel/sdl2 \
multimedia/sfml
+# visualboyadvance-m
+WANTLIB += wx_gtk3u_xrc-3.2 wx_baseu_xml-3.2 wx_gtk3u_html-3.2 wx_baseu_net-3.2
+WANTLIB += wx_gtk3u_core-3.2 wx_baseu-3.2 wx_gtk3u_gl-3.2
+
+BUILD_DEPENDS += archivers/zip
+LIB_DEPENDS += x11/wxWidgets
+
CONFIGURE_ARGS += -DENABLE_FFMPEG=OFF \
- -DENABLE_WX=OFF \
+ -DENABLE_WX=ON \
-DENABLE_SDL=ON
# Creates unlinkable files ('data' according to file(1))
CONFIGURE_ARGS += -DENABLE_LTO=OFF
Index: patches/patch-src_wx_panel_cpp
===
RCS file: patches/patch-src_wx_panel_cpp
diff -N patches/patch-src_wx_panel_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_wx_panel_cpp 23 Apr 2024 15:33:12 -
@@ -0,0 +1,27 @@
+Index: src/wx/panel.cpp
+--- src/wx/panel.cpp.orig
src/wx/panel.cpp
+@@ -2309,6 +2309,7 @@ void GLDrawingPanel::DrawingPanelInit()
+ else
+ wxLogDebug(_("Disabling GLX VSync."));
+
++Display *cdisplay;
+ static PFNGLXSWAPINTERVALEXTPROC glXSwapIntervalEXT = NULL;
+ static PFNGLXSWAPINTERVALSGIPROC glXSwapIntervalSGI = NULL;
+ static PFNGLXSWAPINTERVALMESAPROC glXSwapIntervalMESA = NULL;
+@@ -2321,8 +2322,9 @@ void GLDrawingPanel::DrawingPanelInit()
+ if (strstr(glxQuery, "GLX_EXT_swap_control") != NULL)
+ {
+ glXSwapIntervalEXT =
reinterpret_cast(glXGetProcAddress((const
GLubyte*)"glXSwapIntervalEXT"));
+-if (glXSwapIntervalEXT)
+-glXSwapIntervalEXT(glXGetCurrentDisplay(),
++cdisplay = glXGetCurrentDisplay();
++if (glXSwapIntervalEXT && cdisplay)
++glXSwapIntervalEXT(cdisplay,
+glXGetCurrentDrawable(),
OPTION(kPrefVsync));
+ else
+ systemScreenMessage(_("Failed to set glXSwapIntervalEXT"));
+@@ -2700,4 +2702,4 @@ void GameArea::UnsuspendScreenSaver() {
+ xscreensaver_suspended = false;
+ }
+ #endif // HAVE_XSS
Index: pkg/PLIST
===
RCS file: /cvs/ports/emulators/vbam/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 11 Mar 2022 18:59:42 - 1.4
+++ pkg/PLIST 23 Apr 2024 15:33:12 -
@@ -1,6 +1,89 @@
@bin bin/vbam
+@bin bin/visualboyadvance-m
@man man/man6/vbam.6
+@man man/man6/visualboyadvance-m.6
+share/applications/visualboyadvance-m.desktop
share/examples/vbam/
share/examples/vbam/vbam.cfg
+share/icons/hicolor/128x128/apps/visualboyadvance-m.png
+share/icons/hicolor/16x16/apps/visualboyadvance-m.png
+share/icons/hicolor/22x22/apps/visualboyadvance-m.png
+share/icons/hicolor/24x24/apps/visualboyadvance-m.png
+share/icons/hicolor/256x256/apps/visualboyadvance-m.png
+share/icons/hicolor/32x32/apps/visualboyadvance-m.png
+share/icons/hicolor/48x48/apps/visualboyadvance-m.png
+share/icons/hicolor/64x64/apps/visualboyadvance-m.png
+share/icons/hicolor/96x96/apps/visualboyadvance-m.png
+share/icons/hicolor/scalable/apps/visualboyadvance-m.svg
+share/locale/bg/LC_MESSAGES/wxvbam.mo
Re: opensmtpd-filter-dkimsign: high memory usage
Hello Songbo, On Mon, 2024-04-01 at 13:32 +0200, Songbo Wang wrote: > Hi, > > I am running an OpenSMTPD server with opensmtpd-filter-dkimsign-0.5p2 on > OpenBSD 7.4 (amd64). I noticed recently that the dkimsign program was using a > lot of memory: > > $ ps ax -orss,command | grep dkimsign > 110920 /usr/local/libexec/smtpd/filter-dkimsign -d wsb.onl -s viper1 -k > /etc/mai > 304 grep dkimsign > > I am not a C programmer so maybe I am wrong, but it seems to me that over 100 > MB is a lot for the simple program. I'm aware of this, and I've also managed to track the reason down. I haven't spend the time yet to find a good solution yet. The problem is that after every line libopensmtpd does an event_del/ event_add dance, which libevent queues up for the next kqueue call without doing any deduplication. This means that if it receives a lot of lines to send before returning to the event loop (which happens when you flush a complete cached file from /tmp as dkimsign does) it can grow to an unreasonable amount of kqueue events. The second part of the problem is that this array is never freed/shrunk by libevent. So it shouldn't grow further, unless you sign even larger mails, but I agree that it's far from ideal. > > And of course the relevant line in my smtpd.conf is the following: > > filter "dkimsign" proc-exec "filter-dkimsign -d wsb.onl -s viper1 \ > -k /etc/mail/dkim/private.key" user _dkimsign group _dkimsign > > I am not sure if this memory usage is related to how long the program is > being ran (server’s uptime is over 100 days), so I didn’t restart the > dkimsign program to investigate. But I will be happy to provide more > information if needed. > > Thanks, > -- > Songbo Wang > martijn@
Re: New: stratagus
On Mon, 2024-02-12 at 15:01 -0500, Thomas Frohwein wrote:
> On Mon, Feb 12, 2024 at 07:12:56PM +0100, Martijn van Duren wrote:
> > $ cat stratagus/pkg/DESCR
> > Stratagus is a free cross-platform real-time strategy gaming engine. It
> > includes support for playing over the internet/LAN, or playing a
> > computer opponent. The engine is configurable and can be used to create
> > games with a wide-range of features specific to your needs. Stratagus is
> > written in C++.
> >
> > This is a dependency for war1gus and wargus, a warcraft orcs and humans,
> > and warcraft 2 open source reimplementation respectively (need original
> > assets).
> >
> > Both the changes to the CMakeLists.txt are probably wrong/not needed,
> > but outside the scope of my knowledge, so if someone would at least
> > look those over it would be appreciated.
>
> Thanks for sharing this! I looked at it a little; this is a trickier
> project. The main thing I'm bumping into is that you set
> "USE_NINJA=No" which doesn't seem to be intended (either "yes" or
> "samurai"). The result is that none of the flags from
> MODCMAKE_BUILD_TARGET are used and instead it builds with cmake with
> no arguments. When I try using our regular MODCMAKE_BUILD_TARGET (by
> removing the USE_NINJA line), it then somehow doesn't build the
> vendored lua dependencies including the needed .a file before it's
> needed. I would have thought that this line in CMakeLists.txt should
> ensure that:
>
> add_dependencies(stratagus Lua51B)
>
> but that doesn't seem to be the case. Maybe someone with more cmake
> knowledge can better spot why this only works with empty
> MODCMAKE_BUILD_TARGET.
This build issue is the reason why I found that USE_NINJA=no fixed it.
But if someone with more cmake knowledge knows how to fix this I'm
definitely not objecting. :-)
>
> Here a few other nits:
>
> - remove leading article in COMMENT
Sure
> - drop devel/sdl2 LDEP (is pulled in by sdl2-mixer and sdl2-image)
> -> same for audio/libogg
If they're direct dependencies tested for by the configure script,
shouldn't they be explicitly noted?
> - setting WRKDIST not be needed as DISTNAME already set correctly
Right. Minor left-over from when I fudged around with the package name.
> - disable doxygen? (low quality docs; don't set ENABLE_DOC)
I haven't really looked at the output of doxygen. But the doxygen
part is needed to install the manpage. This can of course be done
with a workaround, but didn't thought it'd be the effort compared to
this flag.
> - add archivers/innoextract to RDEP? (see patches - this is used by runtime)
I've added these to war{,1}gus, since it's in the code that's in the
.h files (yes... I know...), so it's war{,1}gus binary that calls this
function and not the stratagus binary. But there's something to say to
let stratagus have the dependency since it's its header... I'll change
it if you still feel it's in the wrong place as is.
> - variables USE_OPENMP and USE_BACKTRACE are not used by cmake (see
> make configure output)
>
You're right. USE_OPENMP was needed for the head of tree, apparently
it detects it correct in the release. Same for USE_BACKTRACE.
>
> PS:
>
> $ make show=MODCMAKE_BUILD_TARGET
> cd /usr/ports/pobj/stratagus-3.3.2/build-amd64 && exec /usr/bin/env -i
> MODCMAKE_USE_SHARED_LIBS=yes MODCMAKE_PORT_BUILD=yes PORTSDIR="/usr/ports"
> LIBTOOL="/usr/bin/libtool"
> PATH='/usr/ports/pobj/stratagus-3.3.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin'
> PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6'
> CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR=''
> HOME='/stratagus-3.3.2_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin
> BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c
> INSTALL_STRIP=-s MANGRP=bin MANOWN=root MANMODE=644
> BSD_INSTALL_PROGRAM="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -s -m
> 755" BSD_INSTALL_SCRIPT="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -m
> 755" BSD_INSTALL_DATA="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -m
> 644" BSD_INSTALL_MAN="/usr/ports/pobj/stratagus-3.3.2/bin/install -c -m 644"
> BSD_INSTALL_PROGRAM_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d -m
> 755" BSD_INSTALL_SCRIPT_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d
> -m 755" BSD_INSTALL_DATA_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d
> -m 755" BSD_INSTALL_MAN_DIR="/usr/ports/pobj/stratagus-3.3.2/bin/install -d
> -m 755" cmake --build /usr/ports/pobj/stratagus-3.3.2/build-amd64 --verbose
> -j 1
>
Not quite sure what you're trying to show here. Sorry.
> > One issue is that sound doesn't play with video cut scenes and is
> > something that boils up from SDL2's Mix_LoadMUS or Mix_LoadMUS_RW in
> > stratagus' src/sound/sound_server.cpp's LoadMusic().
> >
> > martijn@
>
>
stratagus.tar.gz
Description: application/compressed-tar
New: wargus
$ cat wargus/pkg/DESCR Wargus is a Warcraft 2 Mod that allows you to play Warcraft 2 with the Stratagus engine. The game looks and sounds almost exactly like Warcraft 2. The gameplay is very close to Warcraft 2's gameplay, with slight enhancements towards Starcraft and other more modern RTS games. The patch is simply to disable the std::experimental::filesystem test, similar to the stratagus patch. Tested with gog installer and minor campaign testing. Runs without issues for me. martijn@ wargus.tar.gz Description: application/compressed-tar
New: war1gus
$ cat war1gus/pkg/DESCR War1gus is a re-implementation of "Warcraft: Orcs & Humans" that allows you to play Warcraft with the Stratagus engine. The game uses graphics and sounds from the original Warcraft, but improves the gameplay mechanisms with many modern conveniences that the Stratagus engine allows, such as modern mouse controls, named groups, larger group selection, more player factions in multiplayer games, a map editor, and multiple towns. The patch is simply to disable the std::experimental::filesystem test, similar to the stratagus patch. Tested with gog installer and minor campaign testing. Runs without issues for me. martijn@ war1gus.tar.gz Description: application/compressed-tar
New: stratagus
$ cat stratagus/pkg/DESCR Stratagus is a free cross-platform real-time strategy gaming engine. It includes support for playing over the internet/LAN, or playing a computer opponent. The engine is configurable and can be used to create games with a wide-range of features specific to your needs. Stratagus is written in C++. This is a dependency for war1gus and wargus, a warcraft orcs and humans, and warcraft 2 open source reimplementation respectively (need original assets). Both the changes to the CMakeLists.txt are probably wrong/not needed, but outside the scope of my knowledge, so if someone would at least look those over it would be appreciated. One issue is that sound doesn't play with video cut scenes and is something that boils up from SDL2's Mix_LoadMUS or Mix_LoadMUS_RW in stratagus' src/sound/sound_server.cpp's LoadMusic(). martijn@ stratagus.tar.gz Description: application/compressed-tar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2022/08/31 09:06:34 Modified files: net/net-snmp : Makefile Added files: net/net-snmp/patches: patch-EXAMPLE_conf_def Log message: Let the default net-snmpd config use the same permissions as base snmpd(8). OK sthen@
net-snmpd: Change default socket permissions
If we want to move towards easier and safer integration of agentx backends, I think it makes sense to let net-snmpd have the same default permissions as base snmpd(8). I choose for EXAMPLE.conf and not to change it in the code to surprise the least amount of people (if any). OK? martijn@ Index: Makefile === RCS file: /cvs/ports/net/net-snmp/Makefile,v retrieving revision 1.121 diff -u -p -r1.121 Makefile --- Makefile17 Jul 2022 09:03:22 - 1.121 +++ Makefile31 Aug 2022 15:00:12 - @@ -6,6 +6,7 @@ DISTNAME= net-snmp-$V MULTI_PACKAGES=-main -tkmib PKGNAME-main= net-snmp-$V PKGNAME-tkmib= net-snmp-tkmib-$V +REVISION-main= 0 # tkmib isn't flavoured FULLPKGPATH-tkmib= net/net-snmp,-tkmib Index: patches/patch-EXAMPLE_conf_def === RCS file: patches/patch-EXAMPLE_conf_def diff -N patches/patch-EXAMPLE_conf_def --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-EXAMPLE_conf_def 31 Aug 2022 15:00:12 - @@ -0,0 +1,14 @@ +$OpenBSD$ + +Index: EXAMPLE.conf.def +--- EXAMPLE.conf.def.orig EXAMPLE.conf.def +@@ -188,6 +188,8 @@ linkUpDownNotifications yes + # +# Run as an AgentX master agent + master agentx ++ # Make AgentX master socket permissions identical to base snmpd ++ agentXPerms 660 755 root _agentx +# Listen for network connections (from localhost) +#rather than the default named socket /var/agentx/master + #agentXSockettcp:localhost:705
Re: mbedtls fails to verify rsa cert with clang-13
On Tue, 2022-01-04 at 19:01 +0100, Martijn van Duren wrote: > I have an openvpn connection that needs the mbedtls flavor, because > libressl is a bit too strict with its validation (yes, the cert should > be changed, but it's not my server). > > Since the update to clang-13 the connection fails with > "The certificate is not correctly signed by the trusted CA" > I found that compiling with compiling with -O1 or with clang-11/gcc > from ports doesn't have the issue. > > Via printf comparison I managed to track the issue to > mbedtls_rsa_rsassa_pkcs1_v15_verify() in rsa.c, where > mbedtls_rsa_public() returns an incorrect , which is too > crypto black voodoo magic for me to hunt down further. > This seems to be fixed by bket's update to security/polarssl-2.16.12.
mbedtls fails to verify rsa cert with clang-13
I have an openvpn connection that needs the mbedtls flavor, because libressl is a bit too strict with its validation (yes, the cert should be changed, but it's not my server). Since the update to clang-13 the connection fails with "The certificate is not correctly signed by the trusted CA" I found that compiling with compiling with -O1 or with clang-11/gcc from ports doesn't have the issue. Via printf comparison I managed to track the issue to mbedtls_rsa_rsassa_pkcs1_v15_verify() in rsa.c, where mbedtls_rsa_public() returns an incorrect , which is too crypto black voodoo magic for me to hunt down further.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/10/27 07:57:08 Modified files: mail/opensmtpd-filters/dnsbl: Makefile distinfo Log message: Apparently there are paid dnsbl providers out there that put an authentication key in one of the domain labels. While I don't recommend this construct; echoing said key back to anyone listed is an even worse idea. For these known blacklists strip the key label from the domain when printing. Behaviour pointed out by and initial diff from Renaud Allard (renaud allard it) OK jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: mart...@cvs.openbsd.org 2021/08/11 07:09:49
Modified files:
net/p5-Net-SNMP: Makefile
Added files:
net/p5-Net-SNMP/patches: patch-lib_Net_SNMP_Security_USM_pm
Log message:
Add support for SHA2 (RFC7860).
This allows at least the manubulon-snmp package to work with SHA2
algorithms.
This probably breaks support for 3des and aes{192,256}. Both of these
never got out of the draft state and are unlikely to be encountered in
the wild in any meaningful sense.
feedback, help and OK sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/08/11 07:04:41 ports/net/p5-Net-SNMP/patches Update of /cvs/ports/net/p5-Net-SNMP/patches In directory cvs.openbsd.org:/tmp/cvs-serv37041/patches Log Message: Directory /cvs/ports/net/p5-Net-SNMP/patches added to the repository
p5-Net-SNMP sha2 support
Despite claiming I can't do perl earlier, I decided to give sha2 support
for p5-Net-SNMP another shot and found that I can do enough
perl^Wcopy/paste/tweak to make manubulon-snmp work.
I've already send the patch to David Town, so depending on him still
checking his cpan address it may or may not get upstreamed.
Do we want to have this patch locally pending upstream doing a new
release? If so, someone with actual perl understanding should probably
check this diff.
Since p5-Digest-HMAC doesn't appear to support anything other then
MD5/SHA1 I moved to Digest::SHA for hmac_sha* and kept Digest::HMAC_MD5
for hmac_md5 (which isn't in Digest::MD5). This also removes one
dependency.
martijn@
Index: Makefile
===
RCS file: /cvs/ports/net/p5-Net-SNMP/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile31 Jul 2020 09:17:26 - 1.22
+++ Makefile11 Aug 2021 06:49:12 -
@@ -6,7 +6,7 @@ MODULES=cpan
PKG_ARCH= *
DISTNAME= Net-SNMP-v6.0.1
PKGNAME= p5-Net-SNMP-6.0.1
-REVISION= 2
+REVISION= 3
CATEGORIES=net devel
# same as perl
@@ -14,8 +14,7 @@ PERMIT_PACKAGE= Yes
RUN_DEPENDS= security/p5-Crypt-DES>=2.03 \
security/p5-Crypt-Rijndael \
- security/p5-Digest-HMAC>=1 \
- security/p5-Digest-SHA1>=1.02
+ security/p5-Digest-HMAC>=1
BUILD_DEPENDS= ${RUN_DEPENDS}
.include
Index: patches/patch-lib_Net_SNMP_Security_USM_pm
===
RCS file: patches/patch-lib_Net_SNMP_Security_USM_pm
diff -N patches/patch-lib_Net_SNMP_Security_USM_pm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_Net_SNMP_Security_USM_pm 11 Aug 2021 06:49:12 -
@@ -0,0 +1,201 @@
+$OpenBSD$
+
+Index: lib/Net/SNMP/Security/USM.pm
+--- lib/Net/SNMP/Security/USM.pm.orig
lib/Net/SNMP/Security/USM.pm
+@@ -25,9 +25,11 @@ use Net::SNMP::Message qw(
+
+ use Crypt::DES();
+ use Digest::MD5();
+-use Digest::SHA1();
+-use Digest::HMAC();
++use Digest::SHA();
+
++use Digest::SHA qw( hmac_sha1 hmac_sha224 hmac_sha256 hmac_sha384 hmac_sha512
);
++use Digest::HMAC_MD5 qw ( hmac_md5 );
++
+ ## Version of the Net::SNMP::Security::USM module
+
+ our $VERSION = v4.0.1;
+@@ -40,7 +42,9 @@ our @EXPORT_OK;
+
+ our %EXPORT_TAGS = (
+authprotos => [
+- qw( AUTH_PROTOCOL_NONE AUTH_PROTOCOL_HMACMD5 AUTH_PROTOCOL_HMACSHA )
++ qw( AUTH_PROTOCOL_NONE AUTH_PROTOCOL_HMACMD5 AUTH_PROTOCOL_HMACSHA
++ AUTH_PROTOCOL_HMACSHA224 AUTH_PROTOCOL_HMACSHA256
++ AUTH_PROTOCOL_HMACSHA384 AUTH_PROTOCOL_HMACSHA512 )
+],
+levels => [
+ qw( SECURITY_LEVEL_NOAUTHNOPRIV SECURITY_LEVEL_AUTHNOPRIV
+@@ -63,9 +67,13 @@ $EXPORT_TAGS{ALL} = [ @EXPORT_OK ];
+
+ ## RCC 3414 - Authentication protocols
+
+-sub AUTH_PROTOCOL_NONE{ '1.3.6.1.6.3.10.1.1.1' } # usmNoAuthProtocol
+-sub AUTH_PROTOCOL_HMACMD5 { '1.3.6.1.6.3.10.1.1.2' } # usmHMACMD5AuthProtocol
+-sub AUTH_PROTOCOL_HMACSHA { '1.3.6.1.6.3.10.1.1.3' } # usmHMACSHAAuthProtocol
++sub AUTH_PROTOCOL_NONE { '1.3.6.1.6.3.10.1.1.1' } # usmNoAuthProtocol
++sub AUTH_PROTOCOL_HMACMD5{ '1.3.6.1.6.3.10.1.1.2' } #
usmHMACMD5AuthProtocol
++sub AUTH_PROTOCOL_HMACSHA{ '1.3.6.1.6.3.10.1.1.3' } #
usmHMACSHAAuthProtocol
++sub AUTH_PROTOCOL_HMACSHA224 { '1.3.6.1.6.3.10.1.1.4' } #
usmHMAC128SHA224AuthProtocol
++sub AUTH_PROTOCOL_HMACSHA256 { '1.3.6.1.6.3.10.1.1.5' } #
usmHMAC192SHA256AuthProtocol
++sub AUTH_PROTOCOL_HMACSHA384 { '1.3.6.1.6.3.10.1.1.6' } #
usmHMAC256SHA384AuthProtocol
++sub AUTH_PROTOCOL_HMACSHA512 { '1.3.6.1.6.3.10.1.1.7' } #
usmHMAC384SHA512AuthProtocol
+
+ ## RFC 3414 - Privacy protocols
+
+@@ -124,6 +132,7 @@ sub new
+ '_time_epoc' => time(),# snmpEngineBoots epoc
+ '_user_name' => q{}, # securityName
+ '_auth_data' => undef, # Authentication data
++ '_auth_maclen'=> undef, # MAC length
+ '_auth_key' => undef, # authKey
+ '_auth_password' => undef, # Authentication
password
+ '_auth_protocol' => AUTH_PROTOCOL_HMACMD5, # authProtocol
+@@ -280,10 +289,10 @@ sub generate_request_msg
+if ($pdu->security_level() > SECURITY_LEVEL_NOAUTHNOPRIV) {
+
+ # Save the location to fill in msgAuthenticationParameters later
+- $auth_location = $msg->length() + 12 + length $pdu_buffer;
++ $auth_location = $msg->length() + $this->{_auth_maclen} + length
$pdu_buffer;
+
+ # Set the msgAuthenticationParameters to all zeros
+- $auth_params = pack 'x12';
++ $auth_params = pack "x$this->{_auth_maclen}";
+}
+
+if (!defined $msg->prepare(OCTET_STRING, $auth_params)) {
+@@ -418,12 +427,12 @@ sub process_incoming_msg
+# to compute the HMAC properly.
+
+if (my
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/06/10 05:00:15 Modified files: mail/opensmtpd-filters: Makefile Log message: Enable opensmtpd-filter-dkimsign--ed25519 Looks OK to jasper@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/06/10 04:58:51 Modified files: mail/opensmtpd-filters/dkimsign: Makefile distinfo mail/opensmtpd-filters/dkimsign/pkg: README Log message: Update to version 0.5 Changelist: - Add support for ed25519. This currently requires openssl1.1 libcrypto and is thus only enabled in an ed25519 flavor of the package. Lots of help from tb@ and sthen@ - Fix error handling in a couple of places - Fix an initialization issue Spotted by Maarten de Vries de-vri es> - Fix a couple of signedness warnings - Allow filter-dkimsign to be build on Debian (not relevant for OpenBSD) With Ryan Kavanagh debian org> Looks OK to jasper@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/06/10 04:47:00 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Update to 0.7 Fixes: - Registering OSMTPD_PHASE_LINK_CONNECT should be OSMTPD_TYPE_REPORT - Fix manpage: 0 is for outgoing connections, not 2. >From Edgar Pettijohn pettijohn-web com> - Fix a spelling mistake. >From Ryan Kavanagh debian org> - Major overhaul of the Makefile.gnu so that things properly build on Debian (not relevant for OpenBSD) With Ryan Kavanagh debian org> Looks OK to jasper@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/03/30 06:35:37 Modified files: mail/opensmtpd-filters/dkimsign: Tag: OPENBSD_6_8 Makefile distinfo Log message: filter-dkimsign version 0.4 - Some manpage fixes from bentley@ - Plug a memory leak - Fix an infinite loop in the mheader.c Reported by Karsten. OK jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/03/30 06:32:53 Modified files: mail/opensmtpd-filters/dkimsign: Makefile distinfo Log message: filter-dkimsign version 0.4 - Some manpage fixes from bentley@ - Plug a memory leak - Fix an infinite loop in the mheader.c Reported by Karsten. OK jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/03/30 06:23:47 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Make osmtpd_run return on closing STDIN instead of exiting. This doesn't make much difference for current filters, but allows filters to clean up after themselves; which helps with memory leak detection. OK jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/01/04 00:50:56 Modified files: mail/opensmtpd-filters: Makefile Log message: Hook up admdscrub
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/01/04 00:48:58 Log message: Import filter-admdscrub. This filter checks the Authentication-Results header for the configured admd in smtpd.conf. This filter is intended for border mailservers so that the internal mailservers can trust all Authentication-Results headers within its own Administrative Management Domain. Code checked by gilles@ OK jasper@ Status: Vendor Tag: martijn Release Tags: martijn_20210104 N ports/mail/opensmtpd-filters/admdscrub/Makefile N ports/mail/opensmtpd-filters/admdscrub/distinfo N ports/mail/opensmtpd-filters/admdscrub/pkg/DESCR N ports/mail/opensmtpd-filters/admdscrub/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2021/01/04 00:40:05 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo mail/opensmtpd-filters/libopensmtpd/pkg: PLIST Log message: Update to libopensmtpd 0.5. This adds support osmtpd_register_conf, which passes the smtpd config to the application. This is needed for upcoming filter-admdscrub. OK jasper@
icinga2 crashes on mutex different owner
I'm currently trying to set up a couple of icinga2 satalites on OpenBSD,
but they keep crashing after
/var/lib/icinga2/api/zones-stage/pub//_etc/generated_dbconfig_hosts.conf
has been copied to
/var/lib/icinga2/api/zones/pub//_etc/generated_dbconfig_hosts.conf.
I managed to get the following backtrace:
#1 0x0a94dd2ce2ae in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:61
#2 0x0a94dd231e9c in _libc_pthread_mutex_unlock (mutexp=)
at /usr/src/lib/libc/thread/rthread_mutex.c:265
#3 0x0a9272acc510 in boost::posix::pthread_mutex_unlock (m=0xa927306f488
) at
/usr/local/include/boost/thread/pthread/mutex.hpp:71
#4 boost::mutex::unlock (this=0xa927306f488
) at
/usr/local/include/boost/thread/pthread/mutex.hpp:125
#5 boost::unique_lock::~unique_lock (this=) at
/usr/local/include/boost/thread/lock_types.hpp:331
#6 icinga::intrusive_ptr_release >
(object=0xa952e854d60) at
/usr/ports/pobj/icinga2-2.11.5/icinga2-2.11.5/lib/base/shared.hpp:27
#7 boost::intrusive_ptr >
>::~intrusive_ptr (this=) at
/usr/local/include/boost/smart_ptr/intrusive_ptr.hpp:98
#8
icinga::ApiListener::AsyncTryActivateZonesStage(std::__1::vector > const&,
boost::intrusive_ptr
> > const&)::$_34::~$_34() (this=0xa949f7244c8)
at
/usr/ports/pobj/icinga2-2.11.5/icinga2-2.11.5/lib/remote/apilistener-filesync.cpp:648
#9
std::__1::__compressed_pair_elem > const&,
boost::intrusive_ptr > >
const&)::$_34, 0, false>::~__compressed_pair_elem() (this=0xa949f7244c8)
at /usr/include/c++/v1/memory:2134
#10 0x0a9272acc423 in
std::__1::__function::__alloc_func > const&,
boost::intrusive_ptr > >
const&)::$_34,
std::__1::allocator > const&,
boost::intrusive_ptr > >
const&)::$_34>, void (icinga::ProcessResult const&)>::destroy() (this=) at /usr/include/c++/v1/functional:1546
#11
std::__1::__function::__func > const&,
boost::intrusive_ptr > >
const&)::$_34,
std::__1::allocator > const&,
boost::intrusive_ptr > >
const&)::$_34>, void (icinga::ProcessResult const&)>::destroy_deallocate()
(this=0xa949f7244c0) at /usr/include/c++/v1/functional:1643
#12 0x0a92729bad13 in std::__1::__function::__value_func::~__value_func() (this=) at
/usr/include/c++/v1/functional:1758
#13 std::__1::function::~function()
(this=) at /usr/include/c++/v1/functional:2334
#14 std::__1::__bind&,
icinga::ProcessResult&>::~__bind() (this=) at
/usr/include/c++/v1/functional:2648
#15 std::__1::__compressed_pair_elem&, icinga::ProcessResult&>, 0,
false>::~__compressed_pair_elem() (this=) at
/usr/include/c++/v1/memory:2134
#16 std::__1::__function::__alloc_func&, icinga::ProcessResult&>,
std::__1::allocator&, icinga::ProcessResult&> >, void
()>::destroy() (this=)
at /usr/include/c++/v1/functional:1546
#17 std::__1::__function::__func&, icinga::ProcessResult&>,
std::__1::allocator&, icinga::ProcessResult&> >, void
()>::destroy_deallocate() (this=0xa94b97a1000)
at /usr/include/c++/v1/functional:1643
#18 0x0a92729d438d in std::__1::__function::__value_func::~__value_func() (this=) at
/usr/include/c++/v1/functional:1758
#19 std::__1::function::~function() (this=) at
/usr/include/c++/v1/functional:2334
#20 bool icinga::ThreadPool::Post
>(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}::~SchedulerPolicy() (this=) at
/usr/ports/pobj/icinga2-2.11.5/icinga2-2.11.5/lib/base/threadpool.hpp:59
#21 boost::asio::system_executor::dispatch >(std::__1::function, icinga::SchedulerPolicy)::{lambda()#1}, std::__1::allocator
>(bool icinga::ThreadPool::Post
>>(std::__1::function, icinga::SchedulerPolicy)::{lambda()#1}&&,
>std::__1::allocator const&) const (this=,
f=) at /usr/local/include/boost/asio/impl/system_executor.hpp:40
#22 0x0a92729d420c in boost::asio::detail::work_dispatcher >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>::operator()() (this=) at
/usr/local/include/boost/asio/detail/work_dispatcher.hpp:58
#23 boost::asio::asio_handler_invoke >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>
>(boost::asio::detail::work_dispatcher >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>&, ...) (function=...) at
/usr/local/include/boost/asio/handler_invoke_hook.hpp:69
#24
boost_asio_handler_invoke_helpers::invoke >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>, bool
icinga::ThreadPool::Post >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>(boost::asio::detail::work_dispatcher >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>&, bool
icinga::ThreadPool::Post >(std::__1::function, icinga::SchedulerPolicy)::{lambda()#1}&) (function=..., context=...)
at /usr/local/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#25 boost::asio::detail::executor_op >(std::__1::function,
icinga::SchedulerPolicy)::{lambda()#1}>, std::__1::allocator,
boost::asio::detail::scheduler_operation>::do_complete(void*,
std::__1::allocator*, boost::system::error_code const&, unsigned
long) (owner=0xa94be39e300, base=0xa94b97a1e00) at
Re: valgrind + llvm10
On Mon, 2020-09-14 at 18:12 +0900, Masato Asou wrote:
> Hi,
>
> From: Martijn van Duren
> Date: Mon, 14 Sep 2020 10:43:28 +0200
>
> > I did some bisecting and it seems that the update to clang 10 broke
> > valgrind. Specifically /usr/local/lib/valgrind/memcheck-amd64-openbsd:
> >
> > $ ktrace -i /usr/local/lib/valgrind/memcheck-amd64-openbsd
> > Abort trap
> > $ kdump
> > 12913 ktrace RET ktrace 0
> > 12913 ktrace CALL execve(0x7f7c6fca,0x7f7c6e68,0x7f7c6e78)
> > 12913 ktrace NAMI "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
> > 12913 ktrace ARGS
> > [0] = "/usr/local/lib/valgrind/memcheck-amd64-openbsd"
>
> Now, I am debugging this problem.
>
> > Compiling valgrind with CC=gcc gives the same result, so my guess is
> > that the linker does something unexpected.
>
> Your guess is correct.
>
> Anyway, the following changes seems to work correctly.
> I will report the patch to this mailing list in the next few days.
>
> --- a/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
> +++ b/devel/valgrind/patches/patch-coregrind_link_tool_exe_openbsd_in
> @@ -10,7 +10,7 @@
> +# strip command rewrite offset and align in ELF file. Therefor, when
> valgrind
> +# launch memcheck-amd64-openbsd, an Abort trap occurs in the execvp() system
> +# call.
> -+my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x
> -Wl,-T,$temp", $textbase;
> ++my $cmd = sprintf "$cc -static -nopie -Wl,--strip-all -Wl,-Ttext=0x%x",
> $textbase;
>
> # Add the rest of the parameters
> foreach my $n (2 .. $#ARGV) {
> --
> ASOU Masato
>
Thanks, that gets us a bit further, but it still crashes:
$ cat test.c
int
main(int argc, char *argv[])
{
}
$ make test && valgrind ./test
`test' is up to date.
==57402== Memcheck, a memory error detector
==57402== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==57402== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==57402== Command: ./test
==57402==
==57402==
==57402== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==57402== Access not within mapped region at address 0x8016A00
==57402==at 0x4A680CB: __amd64_read_tcb (in /usr/lib/libc.so.96.0)
==57402==by 0x4A6803D: _thread_finalize (in /usr/lib/libc.so.96.0)
==57402==by 0x4A68120: __cxa_finalize (in /usr/lib/libc.so.96.0)
==57402==by 0x4AF2BF3: exit (in /usr/lib/libc.so.96.0)
==57402==by 0x109747: ___start (in ./test)
==57402== If you believe this happened as a result of a stack
==57402== overflow in your program's main thread (unlikely but
==57402== possible), you can try to increase the size of the
==57402== main thread stack using the --main-stacksize= flag.
==57402== The main thread stack size used in this run was 4194304.
valgrind: m_coredump/coredump-elf.c:816 (void make_elf_coredump(ThreadId, const
vki_siginfo_t *, ULong)): Assertion 'VG_(lseek)(core_fd, phdrs[idx].p_offset,
VKI_SEEK_SET) == phdrs[idx].p_offset'
failed.
host stacktrace:
==57402==at 0x3804BA6C: ???
==57402==by 0x802A9AFDF: ???
==57402==by 0x38069590: ???
==57402==by 0x3804BA6B: ???
==57402==by 0x802A99FAF: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==57402==at 0x4A680CB: __amd64_read_tcb (in /usr/lib/libc.so.96.0)
==57402==by 0x4A6803D: _thread_finalize (in /usr/lib/libc.so.96.0)
==57402==by 0x4A68120: __cxa_finalize (in /usr/lib/libc.so.96.0)
==57402==by 0x4AF2BF3: exit (in /usr/lib/libc.so.96.0)
==57402==by 0x109747: ___start (in ./test)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
valgrind + llvm10
I did some bisecting and it seems that the update to clang 10 broke valgrind. Specifically /usr/local/lib/valgrind/memcheck-amd64-openbsd: $ ktrace -i /usr/local/lib/valgrind/memcheck-amd64-openbsd Abort trap $ kdump 12913 ktrace RET ktrace 0 12913 ktrace CALL execve(0x7f7c6fca,0x7f7c6e68,0x7f7c6e78) 12913 ktrace NAMI "/usr/local/lib/valgrind/memcheck-amd64-openbsd" 12913 ktrace ARGS [0] = "/usr/local/lib/valgrind/memcheck-amd64-openbsd" Compiling valgrind with CC=gcc gives the same result, so my guess is that the linker does something unexpected. martijn@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2020/09/12 06:27:56 Modified files: mail/opensmtpd-filters/dkimsign: Makefile distinfo Log message: Add support for multiple domains by looking at the first mailbox from the "from" mailheader. Tested by me and Uwe Werler (uwe werler retiolum eu) "Go for it!" jasper@
Re: Fix random crashes with gettext on alpha
On Thu, 2020-05-14 at 18:48 +0200, Christian Weisgerber wrote: > Martijn van Duren: > > > So msgfmt crashes an insane amount of times on alpha (rough guess is 75% > > of the time) which is a pain when building other packages. > > That is odd. Why does this only happen on alpha? When did it start > happening on alpha? Years ago I had an alpha and this is a "new" > problem. Don't know, since this system is running less then a week. >From gettext-tools/src/Changelog.1 the freea idiom was added in 2007. > > > tl;dr: should we disable alloca in gettext and what's the best way to > > do this if so? > > I'm reluctant to work around a problem that isn't properly understood. I understand, but considering it's a configure time tested feature that enables a function that has a big fat warning label on it I thought I'd save myself the time. :-) So I did some additional testing and the math appears to check out. >From what I can gather it allocates some additional space and moves the pointer to the next sa_alignment_max so the first sa_alignment_max bits are cleared for alloca or the msb can be set for mmalloca, which determines whether or not it needs to be freed. I fully disassembled the gettext-tools/gnulib-lib/xmalloca.h xmalloca function (which allocates the memory that crashes) and put a printf in between steps. This doesn't result in a crash and matches the alignment math done by gettext. Doing a printf after where the memory was allocated by the original macro it turns out that alloca'd memory which was aligned on the bit required for malloc-checking was not shifting. This hinted at an optimization error. After this I started playing with the -O flag and when tuning -O back to -O0 the code also works. In other words this looks like an optimization bug/eagerness in the gcc; gcc-8 also crashes with default -O2. > The best way is to override the configure check by setting the > corresponding variable. Something like ac_cv_func_alloca_works=no > in CONFIGURE_ENV. > This works, so I see two options: - Move away from this dangerous idiom and set ac_cv_func_alloca_works=no either for alpha or in general. - Set CFLAGS to -O0 for alpha. Either one works for me.
Fix random crashes with gettext on alpha
tl;dr: should we disable alloca in gettext and what's the best way to do this if so? So msgfmt crashes an insane amount of times on alpha (rough guess is 75% of the time) which is a pain when building other packages. I managed to trace the issue to gettet-runtime/gnulib-lib/malloca.c: freea(), which (from a best guess) passes a stack-pointer to free. I set HAVE_ALLOCA in all config.h files to 0 after make configure and rebuild the package. After that I've seen zero crashes anymore. So apparently gettext butchers their calculations on if the pointer is in a stack (alloca) region or not. Since alloca(3) has a big fat warning on it for reasons other than what I've seen on my alpha station it might be wise to just butcher HAVE_ALLOCA on the port. martijn@
Compiling ninja on alpha
Hello, Trying to build ninja on alpha fails with the current COMPILER-line. Apparently gcc-8 has a regression for its alpha backend resulting in a compiler crash with the following error (transcribed): ./src/deps_log.cc:306:1: error: unrecognizable insn: } (insn 483 482 484 36 (set (reg:DI 262) (plus:DI (reg/f:DI 65 virtual-stack-vars) (const_int -524292 [0xfff7fffc] "./src/deps_log.cc":228 -1 (nil)) during RTL pass: vregs ./src/deps_log.cc:386:1: internal compiler error: in extract_insn, at recog.c:2304 Is there an easy way to prioritize base-gcc over ports-gcc on alpha, because I don't think we want to change the line to: COMPILER = base-clang base-gcc ports-gcc martijn@
Make python package on alpha
Python won't package on alpha because VPATH isn't removed during
configure. This is because the following code on alpha isn't triggered:
if test "$ac_abs_confdir" = "$ac_pwd"; then
srcdir=.
fi
which (from what I gathered) is generated by autoconf. This in turn
triggers the check-clean-src check in Makefile, which results in
python failing to pass the install phase of the build.
Since autoconf is a mystery to me and the comment in Makefile.inc
references a utility long send to the great bitbucket in the sky
would this be an appropriate fix?
Of course to be committed after unlock.
martijn@
Index: Makefile.inc
===
RCS file: /cvs/ports/lang/python/Makefile.inc,v
retrieving revision 1.134
diff -u -p -r1.134 Makefile.inc
--- Makefile.inc11 Feb 2020 11:45:31 - 1.134
+++ Makefile.inc12 May 2020 17:47:21 -
@@ -113,9 +113,7 @@ WANTLIB-tkinter = X11 pthread python${VE
AUTOCONF_VERSION = 2.69
CONFIGURE_STYLE = autoconf
-CONFIGURE_ARGS += --enable-shared
-# --srcdir is needed for systrace to work correctly
-CONFIGURE_ARGS += --srcdir=${WRKSRC} \
+CONFIGURE_ARGS += --enable-shared \
--with-fpectl \
--with-threads \
--enable-ipv6 \
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2020/04/13 13:14:28 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Add support for smtpd filter protocol v0.6, which is imminent.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/12/06 05:57:40 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Update in anticipation of a coming filter protocol change. This release works both the current and next version of the protocol. OK jasper@
Re: new: opensmtpd clamav filter
Hello Joerg, No objections from me portswise (although I'm no authority). I do however dislike the trend that every single filters in ports not written by me is in go. At first I thought this was to display the flexibility of the smtpd-api (I even recollect it was said, but I can't find the mail which states so). But it's restricting to OpenBSD users not running on amd64, arm, or i386. Just yesterday there was someone who couldn't run a filter on sparc64 because it was written in go[0]. If we as OpenBSD community value portability over architectures these tools should be written in a language that's just as portable. If you want to demonstrate the flexibility of the API write it in something new like ruby, C++, or even PHP or awk for all I care. If you care about portability please use one of these (although PHP is currently not supported on HPPA). Maybe you could give libopensmtpd a go (pun intended). I reckon it's not hard to use. Also the manpage is incorrect. It states [address] [limit], while if you want to limit the address is non-optional (from reading the code). So this should be [address [limit]]. Also I don't like this syntax, because it gets confusing if the amount of arguments grows (not saying it will happen here, just bad practice). I'd rather see this as [-s address] [-l limit]. martijn@ [0] https://marc.info/?l=openbsd-ports=157353099716261=2 On 11/13/19 1:32 AM, Joerg Jung wrote: > Hi, > > please find attached a port for opensmtpd filter-clamav. > > Comments, OKs? > > Thanks, > Regards, > Joerg >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/10/27 23:59:26 Modified files: mail/opensmtpd-filters/dkimsign: Tag: OPENBSD_6_6 Makefile distinfo Log message: Fix off by one in relaxed mode. Issue found and fix tested by Mikolaj Kucharski. OK jasper@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/10/27 23:58:40 Modified files: mail/opensmtpd-filters/dnsbl: Tag: OPENBSD_6_6 Makefile distinfo Log message: When running filter-dnsbl later in a filter chain it can happen that a disconnect command is issued without any prior. This results in an invalid free. Found by and fix tested by Mischa Peters OK jasper@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/10/23 02:01:19 Modified files: mail/opensmtpd-filters/dkimsign: Makefile distinfo Log message: Fix off by one in relaxed mode. Issue found and fix tested by Mikolaj Kucharski. port diff looks good to jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/10/23 01:59:10 Modified files: mail/opensmtpd-filters/dnsbl: Makefile distinfo Log message: When running filter-dnsbl later in a filter chain it can happen that a disconnect command is issued without any prior. This results in an invalid free. Found by and fix tested by Mischa Peters port diff looks good to jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/26 11:21:42 Modified files: mail/opensmtpd-filters/libopensmtpd: Makefile distinfo Log message: Fix libopensmtpd to correctly interpret IPv6 addresses, which caused crashes after smtpd changed the forward. Bug found and fix tested by mikolaj kucharski name OK jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/23 13:24:45 Modified files: infrastructure/db: user.list mail/opensmtpd-filters/dkimsign: Makefile mail/opensmtpd-filters/dkimsign/pkg: PLIST Added files: mail/opensmtpd-filters/dkimsign/pkg: README Log message: Add a dedicated user for the dkimsign filter, including a default directory to put the private key. While here also add a README on how to set up the filter. With help from and OK jasper@
Re: LAMP/LEMP equivalent bundle?
On 9/20/19 8:57 PM, Implausibility wrote: > Hi. > > I'm trying to move a few system off of Linux, and onto OpenBSD... I'm > trying to get it "right" the first time. > > I'm wondering if there's a 'bundle' or 'stack' of a web server > environment for OpenBSD... Something like... > > OpenBSD + > (Apache | NGINX |OpenHHTPD) > (MySQL/MariaDB/??) > (Perl/PHP/Python) > > Thanks. :) > That fully depends on the application you want to run and what that application requires. Note that there's a difference between what an application requires and what they document on how to set things up. If you are going to write it yourself just use what you're comfortable with. Just keep sane coding practises in mind.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/20 07:00:35 Modified files: mail/opensmtpd-filters: Makefile Log message: Hook up libopensmtpd, opensmtpd-filter-dnsbl and opensmtpd-filter-dkim. OK jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/20 06:57:48 Log message: Import opensmtpd-filter-dkimsign filter-dkim is an opensmtpd filter that signs email with a dkim signature. OK jasper@ Status: Vendor Tag: martijn Release Tags: martijn_20190920 N ports/mail/opensmtpd-filters/dkimsign/Makefile N ports/mail/opensmtpd-filters/dkimsign/distinfo N ports/mail/opensmtpd-filters/dkimsign/pkg/DESCR N ports/mail/opensmtpd-filters/dkimsign/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/20 06:42:56 Log message: Import opensmtpd-filter-dnsbl filter-dnsbl is an opensmtpd filter that checks the sender's IP address against one or more dnsbl lists to flag or reject spam messages at session time. OK jasper@ Status: Vendor Tag: martijn Release Tags: martijn_20190920 N ports/mail/opensmtpd-filters/dnsbl/Makefile N ports/mail/opensmtpd-filters/dnsbl/distinfo N ports/mail/opensmtpd-filters/dnsbl/pkg/DESCR N ports/mail/opensmtpd-filters/dnsbl/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/20 06:11:05 Log message: Import libopensmtpd libopensmtpd is an libevent based library which allows for easy writing of opensmtpd filter applications in C. OK jasper@ Status: Vendor Tag: martijn Release Tags: martijn_20190920 N ports/mail/opensmtpd-filters/libopensmtpd/Makefile N ports/mail/opensmtpd-filters/libopensmtpd/distinfo N ports/mail/opensmtpd-filters/libopensmtpd/pkg/DESCR N ports/mail/opensmtpd-filters/libopensmtpd/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/20 05:22:23 Modified files: mail/opensmtpd-filters: Makefile.inc Log message: Make the variable assignment in Makefile.inc "?=" instead of "=". Requested by jasper@
Re: [NEW] mail/opensmtpd-filter-dnsbl
On 9/18/19 10:49 PM, Mikolaj Kucharski wrote: > On Tue, Sep 17, 2019 at 08:04:47AM +0200, Martijn van Duren wrote: >> Thanks. Apparently I had a opensmtpd.h still lingering in /usr/include >> on this machine. > > I got rusty with OpenBSD ports, so I don't have anything to comment > regards the port itself, but dnsbl filter works (started with options > -vm and runs as _smtpd user): > > 2019-09-18T20:34:45.388Z ks28975 smtpd[62206]: info: OpenSMTPD 6.6.0 starting > 2019-09-18T20:36:40.396Z ks28975 smtpd[53386]: 7f750e1df82c8768 smtp > connected address=209.85.222.169 host=mail-qk1-f169.google.com > 2019-09-18T20:36:40.519Z ks28975 smtpd[37832]: spamcop: 7f750e1df82c8768 not > listed > 2019-09-18T20:36:40.538Z ks28975 smtpd[37832]: spamhaus: 7f750e1df82c8768 not > listed > 2019-09-18T20:36:40.692Z ks28975 smtpd[37832]: blocklist: 7f750e1df82c8768 > not listed > 2019-09-18T20:36:40.742Z ks28975 smtpd[37832]: megarbl: 7f750e1df82c8768 not > listed > 2019-09-18T20:36:41.137Z ks28975 smtpd[53386]: 7f750e1df82c8768 smtp tls > ciphers=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 You did saw that you can specify multiple blacklists in a single filter right? Saves quite a lot of time, since queries can be done parallel, instead of sequential with chaining. > > > Note from myself, not related to the port itself. I found that spamd(8) > in front of smtpd(8) and periodic `smtpctl spf walk` on Big Mail Corps > domains to white list their SPF exposed subnets via pf table > gives very good results, so I never felt a need to reach for additional > filtering signal via DNSBLs. In other words, I'm not sure will I stick > to above filters in long run. Nonetheless, thanks Martijn for this > additional tool. >
Re: [NEW] mail/opensmtpd-filter-dkim
Saw this message only after I send my previous one. CC and WANTLIB updated. On 9/17/19 1:03 AM, Stuart Henderson wrote: > On 2019/09/16 20:42, Mikolaj Kucharski wrote: >> Hi, >> >> On Thu, Sep 12, 2019 at 09:08:31AM +0200, Martijn van Duren wrote: >>> Ping >>> >>> Doesn't anyone want to replace dkimproxy with something that integrates >>> a little better? > > that's not a good incentive, i never used dkimproxy :) (amavisd used to do > that for me, but I switched to rspamd's signing a couple of years ago and > haven't had any interest in looking for alternatives yet). s/dkimproxy/amavisd/g, I want something that integrates better with smtpd. :-) Other advantages: it's a minimal implementation that's pledged and can run under a dedicated user for your dkim key. > >> I used this port and it worked for me. Initially I could not get >> DKIM pass with GMail, but with -c relaxed/relaxed Google is now >> happy. > > it's probably worth figuring out what's going on without that setting, but > generally relaxed/relaxed is recommended anyway Absolutely, and should be fixed. > > https://wordtothewise.com/2016/12/dkim-canonicalization-or-why-microsoft-breaks-your-mail/ > https://wordtothewise.com/2018/07/minimal-dmarc/ That entirely depends on your usecase and who you ask. The official RFC recommendation is: simple/simple: RFC6376 section 3.5 "c=". Hence this is the default for filter-dkimsign. If someone messes with my mail the recipient should be aware, even if it's not too intrusive. dkimsign.tar.gz Description: application/gzip
Re: [NEW] mail/opensmtpd-filter-dkim
On 9/17/19 7:33 AM, Mikolaj Kucharski wrote: > On Tue, Sep 17, 2019 at 12:03:34AM +0100, Stuart Henderson wrote: >>> I used this port and it worked for me. Initially I could not get >>> DKIM pass with GMail, but with -c relaxed/relaxed Google is now >>> happy. >> >> it's probably worth figuring out what's going on without that setting, but >> generally relaxed/relaxed is recommended anyway >> >> https://wordtothewise.com/2016/12/dkim-canonicalization-or-why-microsoft-breaks-your-mail/ >> https://wordtothewise.com/2018/07/minimal-dmarc/ > > I'm not sure what was the problem, as when took the same emails as raw > mbox file and tested it with: > > - https://www.appmaildev.com/en/dkim > - dkimverify.pl from p5-Mail-DKIM-0.54 > - dkimverify from dkimpy 0.9.3 > > they all reported as DKIM pass. My emails were plain text, sent via Mutt > with only few random characters in the email body. > tl;dr: Can you give this one a try? So this took me way longer than I'd like considering the reason. First of, I tested the following platforms without issues: - office365 - yahoo - yandex - p5-DKIM - manual (yes, you can do it manually with openssl(1)). The reason google failed is because my header was named DKIM-signature instead of DKIM-Signature (note the capital S). Headers are case insensitive and this is also the case with google, since it does recognize the header (else we wouldn't have the fail-line). The problem is that google changes the header-name back to DKIM-Signature before validating, which is in violation with RFC6376 section 3.4.1: Header fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified. If anyone has a line to the google devs, please let them know. martijn@ dkimsign.tar.gz Description: application/gzip
Re: [NEW] mail/opensmtpd-filter-dnsbl
On 9/17/19 7:42 AM, Mikolaj Kucharski wrote:
> On Tue, Sep 17, 2019 at 07:21:45AM +0200, Martijn van Duren wrote:
>> Updated for CC flag.
>
> Compilartion fails with:
>
> main.c:32:10: fatal error: 'opensmtpd.h' file not found
> #include "opensmtpd.h"
> ^
>
> below change fixes it:
>
>
> --- Makefile Tue Sep 17 05:06:55 2019
> +++ Makefile Tue Sep 17 05:39:50 2019
> @@ -16,13 +16,12 @@
>
> LIB_DEPENDS= mail/opensmtpd-filters/libopensmtpd
>
> -MAKE_FLAGS+= CFLAGS=-I${LOCALBASE}/include LDFLAGS=-L${LOCALBASE}/lib
> +MAKE_FLAGS= CC="${CC}" CFLAGS=-I${LOCALBASE}/include
> LDFLAGS=-L${LOCALBASE}/lib
>
> # ISC
> PERMIT_PACKAGE= Yes
>
> WANTLIB= c pthread event opensmtpd
> NO_TEST= Yes
> -MAKE_FLAGS= CC="${CC}"
>
> .include
>
Thanks. Apparently I had a opensmtpd.h still lingering in /usr/include
on this machine.
dnsbl.tar.gz
Description: application/gzip
Re: [NEW] mail/opensmtpd-filter-dkim
On 9/17/19 7:33 AM, Mikolaj Kucharski wrote: > On Tue, Sep 17, 2019 at 12:03:34AM +0100, Stuart Henderson wrote: >>> I used this port and it worked for me. Initially I could not get >>> DKIM pass with GMail, but with -c relaxed/relaxed Google is now >>> happy. >> >> it's probably worth figuring out what's going on without that setting, but >> generally relaxed/relaxed is recommended anyway >> >> https://wordtothewise.com/2016/12/dkim-canonicalization-or-why-microsoft-breaks-your-mail/ >> https://wordtothewise.com/2018/07/minimal-dmarc/ > > I'm not sure what was the problem, as when took the same emails as raw > mbox file and tested it with: > > - https://www.appmaildev.com/en/dkim > - dkimverify.pl from p5-Mail-DKIM-0.54 > - dkimverify from dkimpy 0.9.3 > > they all reported as DKIM pass. My emails were plain text, sent via Mutt > with only few random characters in the email body. > Thanks for the report. I'm looking into it right now.
Re: [NEW] mail/opensmtpd-filter-dnsbl
Updated for CC flag. On 9/12/19 9:09 AM, Martijn van Duren wrote: > ping > > No one interested in filtering on DNSBL anymore? > > On 9/5/19 3:15 PM, Martijn van Duren wrote: >> On 8/24/19 6:31 AM, Martijn van Duren wrote: >>> $ cat pkg/DESCR >>> filter-dnsbl is an opensmtpd filter that checks the sender's IP address >>> against one or more dnsbl lists to flag or reject spam messages at session >>> time. >>> $ >>> >>> Since I'm not too familiar with ports I would like to pay special >>> attention to the Makefile of both the port as well as the source. >>> >>> Also, I currently host the release tarballs at my personal server, which >>> I also use for generic other stuff and might not always be available. >>> If someone from the ports team has a more stable location to host the >>> release tarballs let me know. >>> >>> martijn@ >>> >> Ping. >> >> Slightly modified version based on move of libopensmtpd to >> mail/opensmtpd-filters. >> >> Same questions still remain. >> > dnsbl.tar.gz Description: application/gzip
Re: [NEW] mail/libopensmtpd
On 9/17/19 1:00 AM, Stuart Henderson wrote:
> On 2019/09/12 09:13, Martijn van Duren wrote:
>> ping
>>
>> On 9/5/19 3:13 PM, Martijn van Duren wrote:
>>> On 8/24/19 6:29 AM, Martijn van Duren wrote:
>>>> $ cat libopensmtpd/pkg/DESCR
>>>> libopensmtpd is an libevent based library which allows for easy writing
>>>> of opensmtpd filter applications in C.
>>>> $
>>>>
>>>> This is required for filter-dnsbl and filter-dkim.
>>>>
>>>> Since I'm not too familiar with ports I would like to pay special
>>>> attention to the Makefile of both the port as well as the source.
>>>>
>>>> Also, I currently host the release tarballs at my personal server, which
>>>> I also use for generic other stuff and might not always be available.
>>>> If someone from the ports team has a more stable location to host the
>>>> release tarballs let me know.
>>>>
>>>> martijn@
>>>>
>>> Updated diff based on recent smtpd changes.
>>> I haven't changed the version number since it isn't imported in ports
>>> yet.
>>>
>>> Questions above still remain.
>>>
>>> Now to be placed in mail/openstmpd-filters. Requires additional diff
>>> to prevent PKGNAME to be overwritten.
>>>
>>> Index: Makefile.inc
>>> ===
>>> RCS file: /cvs/ports/mail/opensmtpd-filters/Makefile.inc,v
>>> retrieving revision 1.1
>>> diff -u -p -r1.1 Makefile.inc
>>> --- Makefile.inc4 Sep 2019 12:27:42 - 1.1
>>> +++ Makefile.inc5 Sep 2019 13:12:09 -
>>> @@ -1,6 +1,6 @@
>>> # $OpenBSD: Makefile.inc,v 1.1 2019/09/04 12:27:42 martijn Exp $
>>>
>>> -PKGNAME = opensmtpd-filter-${FILTER_NAME}-${V}
>>> +PKGNAME ?= opensmtpd-filter-${FILTER_NAME}-${V}
>>>
>>> MODGO_TYPE = bin
>>> MODGO_BINDIR = libexec/smtpd
>>>
>>
>
> port doesn't honour CC - set this: MAKE_FLAGS= CC="${CC}"
>
> trim COMMENT a bit, we don't usually start with a/the or start with
> caps. I'd just go for e.g. "library for writing opensmtpd filters"
>
> gcc objects to this:
>
> opensmtpd.c:1967:13: warning: 'port' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> port[-1] = ':';
> ~^
>
> start with "SHARED_LIBS= opensmtpd 0.0" and the version number needs to
> be under ports control; changing that var in the Makefile must cause the
> built library version to change. the version number is available in
> LIBopensmtpd_VERSION in the ports Makefile which can then be passed into
> the build via MAKE_FLAGS / MAKE_ENV.
>
>
This one should address all the issues.
libopensmtpd.tar.gz
Description: application/gzip
Re: [NEW] mail/libopensmtpd
ping
On 9/5/19 3:13 PM, Martijn van Duren wrote:
> On 8/24/19 6:29 AM, Martijn van Duren wrote:
>> $ cat libopensmtpd/pkg/DESCR
>> libopensmtpd is an libevent based library which allows for easy writing
>> of opensmtpd filter applications in C.
>> $
>>
>> This is required for filter-dnsbl and filter-dkim.
>>
>> Since I'm not too familiar with ports I would like to pay special
>> attention to the Makefile of both the port as well as the source.
>>
>> Also, I currently host the release tarballs at my personal server, which
>> I also use for generic other stuff and might not always be available.
>> If someone from the ports team has a more stable location to host the
>> release tarballs let me know.
>>
>> martijn@
>>
> Updated diff based on recent smtpd changes.
> I haven't changed the version number since it isn't imported in ports
> yet.
>
> Questions above still remain.
>
> Now to be placed in mail/openstmpd-filters. Requires additional diff
> to prevent PKGNAME to be overwritten.
>
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/mail/opensmtpd-filters/Makefile.inc,v
> retrieving revision 1.1
> diff -u -p -r1.1 Makefile.inc
> --- Makefile.inc 4 Sep 2019 12:27:42 - 1.1
> +++ Makefile.inc 5 Sep 2019 13:12:09 -
> @@ -1,6 +1,6 @@
> # $OpenBSD: Makefile.inc,v 1.1 2019/09/04 12:27:42 martijn Exp $
>
> -PKGNAME =opensmtpd-filter-${FILTER_NAME}-${V}
> +PKGNAME ?= opensmtpd-filter-${FILTER_NAME}-${V}
>
> MODGO_TYPE = bin
> MODGO_BINDIR = libexec/smtpd
>
Re: [NEW] mail/opensmtpd-filter-dnsbl
ping No one interested in filtering on DNSBL anymore? On 9/5/19 3:15 PM, Martijn van Duren wrote: > On 8/24/19 6:31 AM, Martijn van Duren wrote: >> $ cat pkg/DESCR >> filter-dnsbl is an opensmtpd filter that checks the sender's IP address >> against one or more dnsbl lists to flag or reject spam messages at session >> time. >> $ >> >> Since I'm not too familiar with ports I would like to pay special >> attention to the Makefile of both the port as well as the source. >> >> Also, I currently host the release tarballs at my personal server, which >> I also use for generic other stuff and might not always be available. >> If someone from the ports team has a more stable location to host the >> release tarballs let me know. >> >> martijn@ >> > Ping. > > Slightly modified version based on move of libopensmtpd to > mail/opensmtpd-filters. > > Same questions still remain. >
Re: [NEW] mail/opensmtpd-filter-dkim
Ping Doesn't anyone want to replace dkimproxy with something that integrates a little better? On 9/5/19 3:22 PM, Martijn van Duren wrote: > On 8/24/19 6:37 AM, Martijn van Duren wrote: >> $ cat pkg/DESCR >> filter-dkim is an opensmtpd filter that signs email with a dkim signature. >> $ >> >> Since I'm not too familiar with ports I would like to pay special >> attention to the Makefile of both the port as well as the source. >> >> Also, I currently host the release tarballs at my personal server, which >> I also use for generic other stuff and might not always be available. >> If someone from the ports team has a more stable location to host the >> release tarballs let me know. >> >> Furthermore smtpd.conf allows for filters to be run as another user >> (currently undocumented). I know we're tight for uids, but can we >> reserve one for this port, so we can protect the dkim signing key from >> the smtpd users? Or could it be possible to share a uid with another >> port with similar purpose? E.g. dkimproxy? >> >> martijn@ >> >> > I renamed the package to opensmtpd-filter-dkimsign. This to allow for a > future dkimverify. Moved port to mail/opensmtpd-filters/dkimsign. > > Apart from reserving a user, same questions as above remain. > > Index: user.list > === > RCS file: /cvs/ports/infrastructure/db/user.list,v > retrieving revision 1.351 > diff -u -p -r1.351 user.list > --- user.list 25 Aug 2019 12:06:28 - 1.351 > +++ user.list 5 Sep 2019 13:21:08 - > @@ -350,3 +350,4 @@ id user group port options > 839 _exabgp _exabgp net/exabgp > 840 _dma _dmamail/dma > 841 _rt _rt www/rt > +842 _dkimsign_dkimsign mail/opensmtpd-filters/dkimsign >
Re: [NEW] mail/opensmtpd-filter-dkim
On 8/24/19 6:37 AM, Martijn van Duren wrote: > $ cat pkg/DESCR > filter-dkim is an opensmtpd filter that signs email with a dkim signature. > $ > > Since I'm not too familiar with ports I would like to pay special > attention to the Makefile of both the port as well as the source. > > Also, I currently host the release tarballs at my personal server, which > I also use for generic other stuff and might not always be available. > If someone from the ports team has a more stable location to host the > release tarballs let me know. > > Furthermore smtpd.conf allows for filters to be run as another user > (currently undocumented). I know we're tight for uids, but can we > reserve one for this port, so we can protect the dkim signing key from > the smtpd users? Or could it be possible to share a uid with another > port with similar purpose? E.g. dkimproxy? > > martijn@ > > I renamed the package to opensmtpd-filter-dkimsign. This to allow for a future dkimverify. Moved port to mail/opensmtpd-filters/dkimsign. Apart from reserving a user, same questions as above remain. Index: user.list === RCS file: /cvs/ports/infrastructure/db/user.list,v retrieving revision 1.351 diff -u -p -r1.351 user.list --- user.list 25 Aug 2019 12:06:28 - 1.351 +++ user.list 5 Sep 2019 13:21:08 - @@ -350,3 +350,4 @@ id usergroup port options 839 _exabgp_exabgp net/exabgp 840 _dma _dmamail/dma 841 _rt_rt www/rt +842 _dkimsign _dkimsign mail/opensmtpd-filters/dkimsign opensmtpd-filter-dkimsign.tar.gz Description: application/gzip
Re: [NEW] mail/opensmtpd-filter-dnsbl
On 8/24/19 6:31 AM, Martijn van Duren wrote: > $ cat pkg/DESCR > filter-dnsbl is an opensmtpd filter that checks the sender's IP address > against one or more dnsbl lists to flag or reject spam messages at session > time. > $ > > Since I'm not too familiar with ports I would like to pay special > attention to the Makefile of both the port as well as the source. > > Also, I currently host the release tarballs at my personal server, which > I also use for generic other stuff and might not always be available. > If someone from the ports team has a more stable location to host the > release tarballs let me know. > > martijn@ > Ping. Slightly modified version based on move of libopensmtpd to mail/opensmtpd-filters. Same questions still remain. opensmtpd-filter-dnsbl.tar.gz Description: application/gzip
Re: [NEW] mail/libopensmtpd
On 8/24/19 6:29 AM, Martijn van Duren wrote:
> $ cat libopensmtpd/pkg/DESCR
> libopensmtpd is an libevent based library which allows for easy writing
> of opensmtpd filter applications in C.
> $
>
> This is required for filter-dnsbl and filter-dkim.
>
> Since I'm not too familiar with ports I would like to pay special
> attention to the Makefile of both the port as well as the source.
>
> Also, I currently host the release tarballs at my personal server, which
> I also use for generic other stuff and might not always be available.
> If someone from the ports team has a more stable location to host the
> release tarballs let me know.
>
> martijn@
>
Updated diff based on recent smtpd changes.
I haven't changed the version number since it isn't imported in ports
yet.
Questions above still remain.
Now to be placed in mail/openstmpd-filters. Requires additional diff
to prevent PKGNAME to be overwritten.
Index: Makefile.inc
===
RCS file: /cvs/ports/mail/opensmtpd-filters/Makefile.inc,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile.inc
--- Makefile.inc4 Sep 2019 12:27:42 - 1.1
+++ Makefile.inc5 Sep 2019 13:12:09 -
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile.inc,v 1.1 2019/09/04 12:27:42 martijn Exp $
-PKGNAME = opensmtpd-filter-${FILTER_NAME}-${V}
+PKGNAME ?= opensmtpd-filter-${FILTER_NAME}-${V}
MODGO_TYPE = bin
MODGO_BINDIR = libexec/smtpd
libopensmtpd.tar.gz
Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:37:44 Removed files: mail/opensmtpd-filter-rspamd: Makefile distinfo mail/opensmtpd-filter-rspamd/pkg: DESCR PLIST README mail/opensmtpd-filter-senderscore: Makefile distinfo mail/opensmtpd-filter-senderscore/pkg: DESCR PLIST README Log message: Remove old mail/opensmtpd-filter-rspamd and mail/opensmtpd-filter-senderscore in favour of the new mail/opensmtpd-filters/rspamd and mail/opensmtpd-filters/senderscore. OK gilles@ and sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:33:52 Modified files: mail : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Hook up mail/opensmtpd-filters Unhook mail/opensmtpd-filter-rspamd and mail/opensmtpd-filter-senderscore register pkg renaming from filter-* to opensmtpd-filter-*. Idea OK gilles@ OK sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:27:42 Added files: mail/opensmtpd-filters: Makefile Makefile.inc mail/opensmtpd-filters/rspamd: Makefile distinfo mail/opensmtpd-filters/rspamd/pkg: DESCR PLIST README mail/opensmtpd-filters/senderscore: Makefile distinfo mail/opensmtpd-filters/senderscore/pkg: DESCR PLIST README Log message: Move opensmtpd-filter-rspamd and opensmtpd-filter-senderscore to mail/opensmtpd-filters and change the install directory to libexec/smtpd. Idea OK by gilles@ OK sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:24:43 ports/mail/opensmtpd-filters/senderscore/pkg Update of /cvs/ports/mail/opensmtpd-filters/senderscore/pkg In directory cvs.openbsd.org:/tmp/cvs-serv49446/opensmtpd-filters/senderscore/pkg Log Message: Directory /cvs/ports/mail/opensmtpd-filters/senderscore/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:24:43 ports/mail/opensmtpd-filters/rspamd/pkg Update of /cvs/ports/mail/opensmtpd-filters/rspamd/pkg In directory cvs.openbsd.org:/tmp/cvs-serv49446/opensmtpd-filters/rspamd/pkg Log Message: Directory /cvs/ports/mail/opensmtpd-filters/rspamd/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:24:42 ports/mail/opensmtpd-filters/senderscore Update of /cvs/ports/mail/opensmtpd-filters/senderscore In directory cvs.openbsd.org:/tmp/cvs-serv49446/opensmtpd-filters/senderscore Log Message: Directory /cvs/ports/mail/opensmtpd-filters/senderscore added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:24:42 ports/mail/opensmtpd-filters Update of /cvs/ports/mail/opensmtpd-filters In directory cvs.openbsd.org:/tmp/cvs-serv49446/opensmtpd-filters Log Message: Directory /cvs/ports/mail/opensmtpd-filters added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:24:42 ports/mail/opensmtpd-filters/rspamd Update of /cvs/ports/mail/opensmtpd-filters/rspamd In directory cvs.openbsd.org:/tmp/cvs-serv49446/opensmtpd-filters/rspamd Log Message: Directory /cvs/ports/mail/opensmtpd-filters/rspamd added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/09/04 06:22:03 Modified files: lang/go: go.port.mk Log message: Add support for MODGO_BINDIR to allow go applications to be installed in an alternative location. Still defaults to bin/. OK sthen@
Re: Move opensmptd filters to libexec/smtpd
On 9/3/19 12:07 PM, Stuart Henderson wrote:
> On 2019/09/02 13:27, Martijn van Duren wrote:
>> So here's my next iteration that also handles the upgrade.
>> I stuck with MODGO_BINDIR, since the alternatives suggested weren't
>> fully in favor and BINDIR is used by bsd.prog.mk
>>
>> OK in this form?
>
> You also need @conflict entries in the PLISTs to cope with the renamed
> packages.
>
> @conflict filter-rspamd-*
> @conflict filter-senderscore-*
>
> Test by building the new packages including quirks and move them to a
> directory
> on their own. pkg_add the old packages. Run TRUSTED_PKG_PATH=/path/to/newpkgs
> pkg_add -u,
> and make sure they get updated.
>
> Rest looks good to me.
Is that really required? This move renames every file in the package.
I already did the testing steps above.
>
>> martijn@
>>
>> Index: lang/go/go.port.mk
>> ===
>> RCS file: /cvs/ports/lang/go/go.port.mk,v
>> retrieving revision 1.22
>> diff -u -p -r1.22 go.port.mk
>> --- lang/go/go.port.mk 4 May 2019 21:46:16 - 1.22
>> +++ lang/go/go.port.mk 2 Sep 2019 11:07:46 -
>> @@ -27,6 +27,7 @@ MAKE_ENV +=GOCACHE="${MODGO_GOCACHE}"
>> MODGO_CMD ?=${SETENV} ${MAKE_ENV} go
>> MODGO_BUILD_CMD = ${MODGO_CMD} install ${MODGO_FLAGS}
>> MODGO_TEST_CMD =${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
>> +MODGO_BINDIR ?= bin
>>
>> .if ! empty(MODGO_LDFLAGS)
>> MODGO_BUILD_CMD += -ldflags="${MODGO_LDFLAGS}"
>> @@ -57,8 +58,9 @@ MODGO_FLAGS += -x
>>
>> INSTALL_STRIP =
>> .if ${MODGO_TYPE:L:Mbin}
>> -MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
>> -${PREFIX}/bin;
>> +MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR}
>> ${PREFIX}/${MODGO_BINDIR} && \
>> +${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
>> +${PREFIX}/${MODGO_BINDIR};
>> .endif
>>
>> # Go source files serve the purpose of libraries, so sources should be
>> included
>> Index: devel/quirks/Makefile
>> ===
>> RCS file: /cvs/ports/devel/quirks/Makefile,v
>> retrieving revision 1.784
>> diff -u -p -r1.784 Makefile
>> --- devel/quirks/Makefile27 Aug 2019 03:21:32 - 1.784
>> +++ devel/quirks/Makefile2 Sep 2019 11:07:46 -
>> @@ -5,7 +5,7 @@ CATEGORIES = devel databases
>> DISTFILES =
>>
>> # API.rev
>> -PKGNAME = quirks-3.175
>> +PKGNAME = quirks-3.176
>> PKG_ARCH = *
>> MAINTAINER =Marc Espie
>>
>> Index: devel/quirks/files/Quirks.pm
>> ===
>> RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
>> retrieving revision 1.801
>> diff -u -p -r1.801 Quirks.pm
>> --- devel/quirks/files/Quirks.pm 27 Aug 2019 03:21:32 - 1.801
>> +++ devel/quirks/files/Quirks.pm 2 Sep 2019 11:07:46 -
>> @@ -334,6 +334,8 @@ my $stem_extensions = {
>> 'kwebapp' => 'openradtool',
>> 'py-xmldiff' => 'py3-xmldiff',
>> 'bro' => 'zeek',
>> +'filter-rspamd' => 'opensmtpd-filter-rspamd',
>> +'filter-senderscore' => 'opensmtpd-filter-senderscore',
>> };
>>
>> my $obsolete_reason = {
>
>
Re: Move opensmptd filters to libexec/smtpd
So here's my next iteration that also handles the upgrade.
I stuck with MODGO_BINDIR, since the alternatives suggested weren't
fully in favor and BINDIR is used by bsd.prog.mk
OK in this form?
martijn@
Index: lang/go/go.port.mk
===
RCS file: /cvs/ports/lang/go/go.port.mk,v
retrieving revision 1.22
diff -u -p -r1.22 go.port.mk
--- lang/go/go.port.mk 4 May 2019 21:46:16 - 1.22
+++ lang/go/go.port.mk 2 Sep 2019 11:07:46 -
@@ -27,6 +27,7 @@ MAKE_ENV += GOCACHE="${MODGO_GOCACHE}"
MODGO_CMD ?= ${SETENV} ${MAKE_ENV} go
MODGO_BUILD_CMD = ${MODGO_CMD} install ${MODGO_FLAGS}
MODGO_TEST_CMD = ${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
+MODGO_BINDIR ?=bin
.if ! empty(MODGO_LDFLAGS)
MODGO_BUILD_CMD += -ldflags="${MODGO_LDFLAGS}"
@@ -57,8 +58,9 @@ MODGO_FLAGS +=-x
INSTALL_STRIP =
.if ${MODGO_TYPE:L:Mbin}
-MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
- ${PREFIX}/bin;
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/${MODGO_BINDIR} && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+ ${PREFIX}/${MODGO_BINDIR};
.endif
# Go source files serve the purpose of libraries, so sources should be included
Index: devel/quirks/Makefile
===
RCS file: /cvs/ports/devel/quirks/Makefile,v
retrieving revision 1.784
diff -u -p -r1.784 Makefile
--- devel/quirks/Makefile 27 Aug 2019 03:21:32 - 1.784
+++ devel/quirks/Makefile 2 Sep 2019 11:07:46 -
@@ -5,7 +5,7 @@ CATEGORIES =devel databases
DISTFILES =
# API.rev
-PKGNAME = quirks-3.175
+PKGNAME = quirks-3.176
PKG_ARCH = *
MAINTAINER = Marc Espie
Index: devel/quirks/files/Quirks.pm
===
RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.801
diff -u -p -r1.801 Quirks.pm
--- devel/quirks/files/Quirks.pm27 Aug 2019 03:21:32 - 1.801
+++ devel/quirks/files/Quirks.pm2 Sep 2019 11:07:46 -
@@ -334,6 +334,8 @@ my $stem_extensions = {
'kwebapp' => 'openradtool',
'py-xmldiff' => 'py3-xmldiff',
'bro' => 'zeek',
+ 'filter-rspamd' => 'opensmtpd-filter-rspamd',
+ 'filter-senderscore' => 'opensmtpd-filter-senderscore',
};
my $obsolete_reason = {
opensmtpd-filters.tar.gz
Description: application/gzip
Re: Move opensmptd filters to libexec/smtpd
On 8/26/19 9:00 AM, Landry Breuil wrote:
> On Mon, Aug 26, 2019 at 08:10:01AM +0200, Martijn van Duren wrote:
>> On 8/24/19 8:56 PM, Martijn van Duren wrote:
>>> On 8/24/19 10:39 AM, Stuart Henderson wrote:
>>>> On 2019/08/24 10:02, Gilles Chehade wrote:
>>>>> On Sat, Aug 24, 2019 at 06:49:59AM +0200, Martijn van Duren wrote:
>>>>>> On 8/24/19 6:07 AM, Martijn van Duren wrote:
>>>>>>> Briefly discussed with gilles@.
>>>>>>>
>>>>>>> I would like to move the filters to libexec/smtpd for two reasons.
>>>>>>> 1) filters are not commandline applications and I don't want them in my
>>>>>>>$PATH.
>>>>>>> 2) opensmtpd-extras already used this location, so it's only consistent
>>>>>>>to install there as well.
>>>>>>>
>>>>>>> Diff below works for me and based on go.port.mk I don't see any other
>>>>>>> way to change the install directory (except for changing go.port.mk)
>>>>>>>
>>>>>>> OK?
>>>>>>>
>>>>>>> martijn@
>>>>>>>
>>>>>> Missed revision bump...
>>>>>>
>>>>>
>>>>> ok with the idea but I'm not comfortable enough with ports to know
>>>>> if the way you did is the proper way, ports newbie here :-)
>>>>
>>>> I think this should use its own do-install target rather than override
>>>> MODGO_INSTALL_TARGET.
>>>>
>>> Not saying we shouldn't go the do-install route, but just throwing out
>>> an idea. If you're opposed I'll write the do-install patch.
>>> Main reason: less code in port Makefile and might be used by other ports
>>> in the future.
>>>
>>> thoughts?
>>>
>> So combining this one with Antoine's request to put everything in
>> mail/opensmtpd-filters, this is what I came up with.
>>
>> Only thing missing is the automatic rename on upgrade, which I can't
>> figure out how to achieve.
>>
>> Index: go.port.mk
>> ===
>> RCS file: /cvs/ports/lang/go/go.port.mk,v
>> retrieving revision 1.22
>> diff -u -p -r1.22 go.port.mk
>> --- go.port.mk 4 May 2019 21:46:16 - 1.22
>> +++ go.port.mk 26 Aug 2019 06:08:06 -
>> @@ -27,6 +27,7 @@ MAKE_ENV +=GOCACHE="${MODGO_GOCACHE}"
>> MODGO_CMD ?=${SETENV} ${MAKE_ENV} go
>> MODGO_BUILD_CMD = ${MODGO_CMD} install ${MODGO_FLAGS}
>> MODGO_TEST_CMD =${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
>> +MODGO_BINDIR ?= bin
>
> nit here - even if it defaults to bin, i wouldnt name the variable
> _BINDIR, rather MODGO_DESTDIR if it doesnt conflict with an existing
> var, or MODGO_BIN_DESTDIR to make it clear the var is "where a binary is
> going to be installed". But that's only my 2c, no hard feelings if we
> dont care.
>
> Landry
>
Fine with me as well. If noone else objects I'll take your suggestion.
Re: Move opensmptd filters to libexec/smtpd
On 8/24/19 8:56 PM, Martijn van Duren wrote:
> On 8/24/19 10:39 AM, Stuart Henderson wrote:
>> On 2019/08/24 10:02, Gilles Chehade wrote:
>>> On Sat, Aug 24, 2019 at 06:49:59AM +0200, Martijn van Duren wrote:
>>>> On 8/24/19 6:07 AM, Martijn van Duren wrote:
>>>>> Briefly discussed with gilles@.
>>>>>
>>>>> I would like to move the filters to libexec/smtpd for two reasons.
>>>>> 1) filters are not commandline applications and I don't want them in my
>>>>>$PATH.
>>>>> 2) opensmtpd-extras already used this location, so it's only consistent
>>>>>to install there as well.
>>>>>
>>>>> Diff below works for me and based on go.port.mk I don't see any other
>>>>> way to change the install directory (except for changing go.port.mk)
>>>>>
>>>>> OK?
>>>>>
>>>>> martijn@
>>>>>
>>>> Missed revision bump...
>>>>
>>>
>>> ok with the idea but I'm not comfortable enough with ports to know
>>> if the way you did is the proper way, ports newbie here :-)
>>
>> I think this should use its own do-install target rather than override
>> MODGO_INSTALL_TARGET.
>>
> Not saying we shouldn't go the do-install route, but just throwing out
> an idea. If you're opposed I'll write the do-install patch.
> Main reason: less code in port Makefile and might be used by other ports
> in the future.
>
> thoughts?
>
So combining this one with Antoine's request to put everything in
mail/opensmtpd-filters, this is what I came up with.
Only thing missing is the automatic rename on upgrade, which I can't
figure out how to achieve.
Index: go.port.mk
===
RCS file: /cvs/ports/lang/go/go.port.mk,v
retrieving revision 1.22
diff -u -p -r1.22 go.port.mk
--- go.port.mk 4 May 2019 21:46:16 - 1.22
+++ go.port.mk 26 Aug 2019 06:08:06 -
@@ -27,6 +27,7 @@ MAKE_ENV += GOCACHE="${MODGO_GOCACHE}"
MODGO_CMD ?= ${SETENV} ${MAKE_ENV} go
MODGO_BUILD_CMD = ${MODGO_CMD} install ${MODGO_FLAGS}
MODGO_TEST_CMD = ${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
+MODGO_BINDIR ?=bin
.if ! empty(MODGO_LDFLAGS)
MODGO_BUILD_CMD += -ldflags="${MODGO_LDFLAGS}"
@@ -57,8 +58,9 @@ MODGO_FLAGS +=-x
INSTALL_STRIP =
.if ${MODGO_TYPE:L:Mbin}
-MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
- ${PREFIX}/bin;
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/${MODGO_BINDIR} && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+ ${PREFIX}/${MODGO_BINDIR};
.endif
# Go source files serve the purpose of libraries, so sources should be included
opensmtpd-filters.tar.gz
Description: application/gzip
Re: [NEW] mail/opensmtpd-filter-dkim
On 8/25/19 11:43 AM, Antoine Jacoutot wrote: > On Sat, Aug 24, 2019 at 09:10:18PM +0200, Martijn van Duren wrote: >> On 8/24/19 12:20 PM, Stuart Henderson wrote: >>> On 2019/08/24 11:52, Antoine Jacoutot wrote: >>>> On Sat, Aug 24, 2019 at 09:42:10AM +0100, Stuart Henderson wrote: >>>>> On 2019/08/24 06:37, Martijn van Duren wrote: >>>>>> $ cat pkg/DESCR >>>>>> filter-dkim is an opensmtpd filter that signs email with a dkim >>>>>> signature. >>>>>> $ >>>>>> >>>>>> Since I'm not too familiar with ports I would like to pay special >>>>>> attention to the Makefile of both the port as well as the source. >>>>>> >>>>>> Also, I currently host the release tarballs at my personal server, which >>>>>> I also use for generic other stuff and might not always be available. >>>>>> If someone from the ports team has a more stable location to host the >>>>>> release tarballs let me know. >>>>>> >>>>>> Furthermore smtpd.conf allows for filters to be run as another user >>>>>> (currently undocumented). I know we're tight for uids, but can we >>>>>> reserve one for this port, so we can protect the dkim signing key from >>>>>> the smtpd users? >>>>> >>>>> Maybe it makes sense to use a shared uid for the other filters, but >>>>> it sounds reasonable to assign a new uid for this one. >> >> Thanks. Diff below reserves one. >> As for Gilles' suggestion to reserve one for all filters in general, I'm >> not convinced that's needed, since user _smtpd in general can't do much >> damage. >>>>> >>>>>> Or could it be possible to share a uid with another >>>>>> port with similar purpose? E.g. dkimproxy? >>>>> >>>>> Definitely prefer not to do that. >>>>> >>>>> Ports UIDs need a more general solution rather than trying to conserve the >>>>> odd 1 or 2 here and there. >> >> It was just an idea to scrape the barrel considering any bit might help. >>>> >>>> Maybe we could also reserve a directory in ports (e.g. >>>> mail/opensmtpd-filter)? >>>> So we can have: >>>> mail/opensmtpd-filter/dkim >>>> mail/opensmtpd-filter/dnsbl >>>> and so on... >>>> >>>> -- >>>> Antoine >>>> >>> >>> Yes please! >>> >> I don't mind doing it that way. > > Make it opensmtpd-filter*s* I guess :-) No objection one way or the other. So if noone objects I'll make it so. While at it, should we also give a clearer DISTNAME? E.g. opensmtpd-filter-? Right now it's filter-..., which might not be clear to everyone that it's an smtpd filter. > >> >> Index: infrastructure/db/user.list >> === >> RCS file: /cvs/ports/infrastructure/db/user.list,v >> retrieving revision 1.350 >> diff -u -p -r1.350 user.list >> --- infrastructure/db/user.list 2 Aug 2019 21:59:35 - 1.350 >> +++ infrastructure/db/user.list 24 Aug 2019 19:08:18 - >> @@ -349,3 +349,4 @@ id user group port options >> 838 _i2pd _i2pd net/i2pd >> 839 _exabgp _exabgp net/exabgp >> 840 _dma_dmamail/dma >> +841 _smtpd_dkim _smtpd_dkim mail/opensmtpd-filter/dkim >
Re: [NEW] mail/opensmtpd-filter-dkim
On 8/24/19 12:20 PM, Stuart Henderson wrote: > On 2019/08/24 11:52, Antoine Jacoutot wrote: >> On Sat, Aug 24, 2019 at 09:42:10AM +0100, Stuart Henderson wrote: >>> On 2019/08/24 06:37, Martijn van Duren wrote: >>>> $ cat pkg/DESCR >>>> filter-dkim is an opensmtpd filter that signs email with a dkim signature. >>>> $ >>>> >>>> Since I'm not too familiar with ports I would like to pay special >>>> attention to the Makefile of both the port as well as the source. >>>> >>>> Also, I currently host the release tarballs at my personal server, which >>>> I also use for generic other stuff and might not always be available. >>>> If someone from the ports team has a more stable location to host the >>>> release tarballs let me know. >>>> >>>> Furthermore smtpd.conf allows for filters to be run as another user >>>> (currently undocumented). I know we're tight for uids, but can we >>>> reserve one for this port, so we can protect the dkim signing key from >>>> the smtpd users? >>> >>> Maybe it makes sense to use a shared uid for the other filters, but >>> it sounds reasonable to assign a new uid for this one. Thanks. Diff below reserves one. As for Gilles' suggestion to reserve one for all filters in general, I'm not convinced that's needed, since user _smtpd in general can't do much damage. >>> >>>> Or could it be possible to share a uid with another >>>> port with similar purpose? E.g. dkimproxy? >>> >>> Definitely prefer not to do that. >>> >>> Ports UIDs need a more general solution rather than trying to conserve the >>> odd 1 or 2 here and there. It was just an idea to scrape the barrel considering any bit might help. >> >> Maybe we could also reserve a directory in ports (e.g. >> mail/opensmtpd-filter)? >> So we can have: >> mail/opensmtpd-filter/dkim >> mail/opensmtpd-filter/dnsbl >> and so on... >> >> -- >> Antoine >> > > Yes please! > I don't mind doing it that way. Index: infrastructure/db/user.list === RCS file: /cvs/ports/infrastructure/db/user.list,v retrieving revision 1.350 diff -u -p -r1.350 user.list --- infrastructure/db/user.list 2 Aug 2019 21:59:35 - 1.350 +++ infrastructure/db/user.list 24 Aug 2019 19:08:18 - @@ -349,3 +349,4 @@ id usergroup port options 838 _i2pd _i2pd net/i2pd 839 _exabgp_exabgp net/exabgp 840 _dma _dmamail/dma +841 _smtpd_dkim_smtpd_dkim mail/opensmtpd-filter/dkim
Re: Move opensmptd filters to libexec/smtpd
On 8/24/19 10:39 AM, Stuart Henderson wrote:
> On 2019/08/24 10:02, Gilles Chehade wrote:
>> On Sat, Aug 24, 2019 at 06:49:59AM +0200, Martijn van Duren wrote:
>>> On 8/24/19 6:07 AM, Martijn van Duren wrote:
>>>> Briefly discussed with gilles@.
>>>>
>>>> I would like to move the filters to libexec/smtpd for two reasons.
>>>> 1) filters are not commandline applications and I don't want them in my
>>>>$PATH.
>>>> 2) opensmtpd-extras already used this location, so it's only consistent
>>>>to install there as well.
>>>>
>>>> Diff below works for me and based on go.port.mk I don't see any other
>>>> way to change the install directory (except for changing go.port.mk)
>>>>
>>>> OK?
>>>>
>>>> martijn@
>>>>
>>> Missed revision bump...
>>>
>>
>> ok with the idea but I'm not comfortable enough with ports to know
>> if the way you did is the proper way, ports newbie here :-)
>
> I think this should use its own do-install target rather than override
> MODGO_INSTALL_TARGET.
>
Not saying we shouldn't go the do-install route, but just throwing out
an idea. If you're opposed I'll write the do-install patch.
Main reason: less code in port Makefile and might be used by other ports
in the future.
thoughts?
Index: lang/go/go.port.mk
===
RCS file: /cvs/ports/lang/go/go.port.mk,v
retrieving revision 1.22
diff -u -p -r1.22 go.port.mk
--- lang/go/go.port.mk 4 May 2019 21:46:16 - 1.22
+++ lang/go/go.port.mk 24 Aug 2019 18:53:52 -
@@ -27,6 +27,7 @@ MAKE_ENV += GOCACHE="${MODGO_GOCACHE}"
MODGO_CMD ?= ${SETENV} ${MAKE_ENV} go
MODGO_BUILD_CMD = ${MODGO_CMD} install ${MODGO_FLAGS}
MODGO_TEST_CMD = ${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
+MODGO_BINDIR ?=bin
.if ! empty(MODGO_LDFLAGS)
MODGO_BUILD_CMD += -ldflags="${MODGO_LDFLAGS}"
@@ -57,8 +58,9 @@ MODGO_FLAGS +=-x
INSTALL_STRIP =
.if ${MODGO_TYPE:L:Mbin}
-MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
- ${PREFIX}/bin;
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/${MODGO_BINDIR} && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+ ${PREFIX}/${MODGO_BINDIR};
.endif
# Go source files serve the purpose of libraries, so sources should be included
Index: mail/opensmtpd-filter-rspamd/Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- mail/opensmtpd-filter-rspamd/Makefile 13 Aug 2019 18:40:10 -
1.1.1.1
+++ mail/opensmtpd-filter-rspamd/Makefile 24 Aug 2019 18:53:52 -
@@ -3,6 +3,7 @@
COMMENT = rspamd integration to the OpenSMTPD daemon
V =0.1.0
+REVISION = 0
DISTNAME = filter-rspamd-${V}
CATEGORIES = mail
@@ -18,6 +19,7 @@ PERMIT_PACKAGE = Yes
WANTLIB = c pthread
MODULES = lang/go
MODGO_TYPE = bin
+MODGO_BINDIR = libexec/smtpd
NO_TEST = Yes
ALL_TARGET = filter-rspamd
Index: mail/opensmtpd-filter-rspamd/pkg/PLIST
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- mail/opensmtpd-filter-rspamd/pkg/PLIST 13 Aug 2019 18:40:10 -
1.1.1.1
+++ mail/opensmtpd-filter-rspamd/pkg/PLIST 24 Aug 2019 18:53:52 -
@@ -1,3 +1,4 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2019/08/13 18:40:10 gilles Exp $
-@bin bin/filter-rspamd
+libexec/smtpd/
+@bin libexec/smtpd/filter-rspamd
share/doc/pkg-readmes/${PKGSTEM}
Index: mail/opensmtpd-filter-rspamd/pkg/README
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- mail/opensmtpd-filter-rspamd/pkg/README 13 Aug 2019 18:40:10 -
1.1.1.1
+++ mail/opensmtpd-filter-rspamd/pkg/README 24 Aug 2019 18:53:52 -
@@ -8,7 +8,7 @@ To use filter-rspamd, you must declare i
Edit the /etc/mail/smtpd.conf file to declare the filter:
- filter "rspamd" proc-exec "${PREFIX}/bin/filter-rspamd"
+ filter "rspamd" proc-exec "${PREFIX}/libexec/smtpd/filter-rspamd"
Then add the filter to each listener that should be filtered:
Index: mail/opensmtpd-filter-senderscore/Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/Makefile,v
retrieving revision 1
Re: Move opensmptd filters to libexec/smtpd
On 8/24/19 6:07 AM, Martijn van Duren wrote:
> Briefly discussed with gilles@.
>
> I would like to move the filters to libexec/smtpd for two reasons.
> 1) filters are not commandline applications and I don't want them in my
>$PATH.
> 2) opensmtpd-extras already used this location, so it's only consistent
>to install there as well.
>
> Diff below works for me and based on go.port.mk I don't see any other
> way to change the install directory (except for changing go.port.mk)
>
> OK?
>
> martijn@
>
Missed revision bump...
Index: opensmtpd-filter-rspamd/Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- opensmtpd-filter-rspamd/Makefile13 Aug 2019 18:40:10 - 1.1.1.1
+++ opensmtpd-filter-rspamd/Makefile24 Aug 2019 04:49:48 -
@@ -3,6 +3,7 @@
COMMENT = rspamd integration to the OpenSMTPD daemon
V =0.1.0
+REVISION = 0
DISTNAME = filter-rspamd-${V}
CATEGORIES = mail
@@ -23,3 +24,7 @@ NO_TEST = Yes
ALL_TARGET = filter-rspamd
.include
+
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/libexec/smtpd && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+${PREFIX}/libexec/smtpd;
Index: opensmtpd-filter-rspamd/pkg/PLIST
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- opensmtpd-filter-rspamd/pkg/PLIST 13 Aug 2019 18:40:10 - 1.1.1.1
+++ opensmtpd-filter-rspamd/pkg/PLIST 24 Aug 2019 04:49:48 -
@@ -1,3 +1,4 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2019/08/13 18:40:10 gilles Exp $
-@bin bin/filter-rspamd
+libexec/smtpd/
+@bin libexec/smtpd/filter-rspamd
share/doc/pkg-readmes/${PKGSTEM}
Index: opensmtpd-filter-rspamd/pkg/README
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- opensmtpd-filter-rspamd/pkg/README 13 Aug 2019 18:40:10 - 1.1.1.1
+++ opensmtpd-filter-rspamd/pkg/README 24 Aug 2019 04:49:48 -
@@ -8,7 +8,7 @@ To use filter-rspamd, you must declare i
Edit the /etc/mail/smtpd.conf file to declare the filter:
- filter "rspamd" proc-exec "${PREFIX}/bin/filter-rspamd"
+ filter "rspamd" proc-exec "${PREFIX}/libexec/smtpd/filter-rspamd"
Then add the filter to each listener that should be filtered:
Index: opensmtpd-filter-senderscore/Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- opensmtpd-filter-senderscore/Makefile 19 Aug 2019 21:21:17 -
1.1.1.1
+++ opensmtpd-filter-senderscore/Makefile 24 Aug 2019 04:49:48 -
@@ -3,6 +3,7 @@
COMMENT = SenderScore integration to the OpenSMTPD daemon
V =0.1.0
+REVISION = 0
DISTNAME = filter-senderscore-${V}
CATEGORIES = mail
@@ -23,3 +24,7 @@ NO_TEST = Yes
ALL_TARGET = filter-senderscore
.include
+
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/libexec/smtpd && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+${PREFIX}/libexec/smtpd;
Index: opensmtpd-filter-senderscore/pkg/PLIST
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- opensmtpd-filter-senderscore/pkg/PLIST 19 Aug 2019 21:21:17 -
1.1.1.1
+++ opensmtpd-filter-senderscore/pkg/PLIST 24 Aug 2019 04:49:48 -
@@ -1,3 +1,4 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2019/08/19 21:21:17 gilles Exp $
-@bin bin/filter-senderscore
+libexec/smtpd/
+@bin libexec/smtpd/filter-senderscore
share/doc/pkg-readmes/${PKGSTEM}
Index: opensmtpd-filter-senderscore/pkg/README
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- opensmtpd-filter-senderscore/pkg/README 19 Aug 2019 21:21:17 -
1.1.1.1
+++ opensmtpd-filter-senderscore/pkg/README 24 Aug 2019 04:49:48 -
@@ -9,7 +9,7 @@ To use filter-senderscore, you must decl
Edit the /etc/mail/smtpd.conf file to declare the filter:
filter "senderscore" \
-proc-exec "${PREFIX}/bin/filter-senderscore [...]"
+proc-exec "${PREFIX}/libexec/smtpd/filter-senderscore [...]"
The following options may be passed to filter-senderscore:
[NEW] mail/opensmtpd-filter-dkim
$ cat pkg/DESCR filter-dkim is an opensmtpd filter that signs email with a dkim signature. $ Since I'm not too familiar with ports I would like to pay special attention to the Makefile of both the port as well as the source. Also, I currently host the release tarballs at my personal server, which I also use for generic other stuff and might not always be available. If someone from the ports team has a more stable location to host the release tarballs let me know. Furthermore smtpd.conf allows for filters to be run as another user (currently undocumented). I know we're tight for uids, but can we reserve one for this port, so we can protect the dkim signing key from the smtpd users? Or could it be possible to share a uid with another port with similar purpose? E.g. dkimproxy? martijn@ opensmtpd-filter-dkim.tar.gz Description: application/gzip
[NEW] mail/opensmtpd-filter-dnsbl
$ cat pkg/DESCR filter-dnsbl is an opensmtpd filter that checks the sender's IP address against one or more dnsbl lists to flag or reject spam messages at session time. $ Since I'm not too familiar with ports I would like to pay special attention to the Makefile of both the port as well as the source. Also, I currently host the release tarballs at my personal server, which I also use for generic other stuff and might not always be available. If someone from the ports team has a more stable location to host the release tarballs let me know. martijn@ opensmtpd-filter-dnsbl.tar.gz Description: application/gzip
[NEW] mail/libopensmtpd
$ cat libopensmtpd/pkg/DESCR libopensmtpd is an libevent based library which allows for easy writing of opensmtpd filter applications in C. $ This is required for filter-dnsbl and filter-dkim. Since I'm not too familiar with ports I would like to pay special attention to the Makefile of both the port as well as the source. Also, I currently host the release tarballs at my personal server, which I also use for generic other stuff and might not always be available. If someone from the ports team has a more stable location to host the release tarballs let me know. martijn@ libopensmtpd.tar.gz Description: application/gzip
Move opensmptd filters to libexec/smtpd
Briefly discussed with gilles@.
I would like to move the filters to libexec/smtpd for two reasons.
1) filters are not commandline applications and I don't want them in my
$PATH.
2) opensmtpd-extras already used this location, so it's only consistent
to install there as well.
Diff below works for me and based on go.port.mk I don't see any other
way to change the install directory (except for changing go.port.mk)
OK?
martijn@
Index: opensmtpd-filter-rspamd/Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- opensmtpd-filter-rspamd/Makefile13 Aug 2019 18:40:10 - 1.1.1.1
+++ opensmtpd-filter-rspamd/Makefile24 Aug 2019 04:01:56 -
@@ -23,3 +23,7 @@ NO_TEST = Yes
ALL_TARGET = filter-rspamd
.include
+
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/libexec/smtpd && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+${PREFIX}/libexec/smtpd;
Index: opensmtpd-filter-rspamd/pkg/PLIST
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- opensmtpd-filter-rspamd/pkg/PLIST 13 Aug 2019 18:40:10 - 1.1.1.1
+++ opensmtpd-filter-rspamd/pkg/PLIST 24 Aug 2019 04:01:56 -
@@ -1,3 +1,4 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2019/08/13 18:40:10 gilles Exp $
-@bin bin/filter-rspamd
+libexec/smtpd/
+@bin libexec/smtpd/filter-rspamd
share/doc/pkg-readmes/${PKGSTEM}
Index: opensmtpd-filter-rspamd/pkg/README
===
RCS file: /cvs/ports/mail/opensmtpd-filter-rspamd/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- opensmtpd-filter-rspamd/pkg/README 13 Aug 2019 18:40:10 - 1.1.1.1
+++ opensmtpd-filter-rspamd/pkg/README 24 Aug 2019 04:01:56 -
@@ -8,7 +8,7 @@ To use filter-rspamd, you must declare i
Edit the /etc/mail/smtpd.conf file to declare the filter:
- filter "rspamd" proc-exec "${PREFIX}/bin/filter-rspamd"
+ filter "rspamd" proc-exec "${PREFIX}/libexec/smtpd/filter-rspamd"
Then add the filter to each listener that should be filtered:
Index: opensmtpd-filter-senderscore/Makefile
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- opensmtpd-filter-senderscore/Makefile 19 Aug 2019 21:21:17 -
1.1.1.1
+++ opensmtpd-filter-senderscore/Makefile 24 Aug 2019 04:01:56 -
@@ -23,3 +23,7 @@ NO_TEST = Yes
ALL_TARGET = filter-senderscore
.include
+
+MODGO_INSTALL_TARGET = ${INSTALL_PROGRAM_DIR} ${PREFIX}/libexec/smtpd && \
+ ${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/* \
+${PREFIX}/libexec/smtpd;
Index: opensmtpd-filter-senderscore/pkg/PLIST
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- opensmtpd-filter-senderscore/pkg/PLIST 19 Aug 2019 21:21:17 -
1.1.1.1
+++ opensmtpd-filter-senderscore/pkg/PLIST 24 Aug 2019 04:01:56 -
@@ -1,3 +1,4 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2019/08/19 21:21:17 gilles Exp $
-@bin bin/filter-senderscore
+libexec/smtpd/
+@bin libexec/smtpd/filter-senderscore
share/doc/pkg-readmes/${PKGSTEM}
Index: opensmtpd-filter-senderscore/pkg/README
===
RCS file: /cvs/ports/mail/opensmtpd-filter-senderscore/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- opensmtpd-filter-senderscore/pkg/README 19 Aug 2019 21:21:17 -
1.1.1.1
+++ opensmtpd-filter-senderscore/pkg/README 24 Aug 2019 04:01:56 -
@@ -9,7 +9,7 @@ To use filter-senderscore, you must decl
Edit the /etc/mail/smtpd.conf file to declare the filter:
filter "senderscore" \
-proc-exec "${PREFIX}/bin/filter-senderscore [...]"
+proc-exec "${PREFIX}/libexec/smtpd/filter-senderscore [...]"
The following options may be passed to filter-senderscore:
Re: new net/icinga/web2-module-graphite
On 2/19/19 3:44 PM, Stuart Henderson wrote: > I think it needs to say somewhere that it requires graphite-web which > is not available in ports. (There's extra risk of confusion because > we do have graphics/graphite2 which is something else). I already submitted a port for py-graphite-web about 3 months ago, along with all the other changes required to make it work. But I have received a disappointing amount of replies. But I added a note to DESCR to inform people. > > As you have it now (bearing in mind that it pulls in ../Makefile.inc) > it has me listed as maintainer, which I don't want, please either set > an explicit ports@ maintainer to override that, or take maintainer > yourself. > Set maintainer to myself. Update port attached. > > > On 2019/02/19 07:51, Martijn van Duren wrote: >> ping >> >> On 11/27/18 2:26 PM, Martijn van Duren wrote: >>> Here's a port of web2-module-graphite. I took web2-module-director as a >>> basis, which worked well enough. >>> >>> The diff is for a quirk when having a service check based on >>> snmp-storage. The check uses regexes and anchoring with a '^' is stored >>> as is by icinga2-graphite, while web2-module-graphite escapes it with a >>> '_'. Upstream is already notified but not yet merged.[0] >>> >>> This requires a running graphite including graphite-web, but since that >>> can run on a separate host I don't think we should add it as a >>> dependency. This way we can also include it right away for people >>> offloading their icinga2 graphite needs to an instance not maintained >>> by ports. >>> >>> OK? >>> >>> martijn@ >>> >>> [0]https://github.com/Icinga/icingaweb2-module-graphite/pull/189 >>> > > web2-module-graphite.tar.gz Description: application/gzip
Re: new py-cachetools
ping
On 1/24/19 1:29 PM, Martijn van Duren wrote:
> ping
>
> On 11/28/18 1:59 PM, Martijn van Duren wrote:
>> Here's the port for py-cachetools, which is required to startup
>> carbon-aggregator{,-cache}.py. Only lightly tested in py3 flavor by
>> starting up carbon-aggregator.
>>
>> martijn@
>>
>
Re: login_ldap with referrals
No one using login_ldap with referrals? On 2/12/19 10:37 PM, Martijn van Duren wrote: > 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: update py-carbon
ping
On 1/24/19 1:29 PM, Martijn van Duren wrote:
> ping
>
> On 11/28/18 1:56 PM, Martijn van Duren wrote:
>> So something like this?
>> I'll send py-cachetools in a separate diff.
>>
>> On 11/28/18 12:07 PM, Stuart Henderson wrote:
>>> On 2018/11/28 08:25, Martijn van Duren wrote:
>>>> On 11/27/18 2:36 PM, Daniel Jakots wrote:
>>>>> On Tue, 27 Nov 2018 12:43:52 +0100, Martijn van Duren
>>>>> wrote:
>>>>>
>>>>>> Here's an update to databases/py-carbon.
>>>>>> There's experimental support for python3, but I haven't included it
>>>>>> here because of other dependencies which don't yet have python3
>>>>>> support in our tree.
>>>>>
>>>>> Which one(s)?
>>>>>
>>>> I must have goofed somewhere. It's not py-carbon directly which has
>>>> "issues", but py-whisper. But let's safe that discussion for that
>>>> threat.
>>>>
>>>> Here's an updated diff. I don't know whether mostly executable
>>>> python packages should be moved to python3, or if they still
>>>> should come in flavors, so I just made it a flavor, so we can
>>>> quite easily dumb it down again if we just want python3.
>>>
>>> If it's actually useful as a library then it might be worth considering
>>> whether to subpackage it - have the executables as a separate package
>>> only built with the python3 flavour.
>>>
>>> But if (as COMMENT implies) it's only really useful as daemon/utilties
>>> then I'd much prefer to just switch to py3 outright. This cuts a lot of
>>> complexity from Makefile, patches and PLIST, and makes it so all users
>>> are on recent python (rather than the "default" being old python).
>>>
>>>> Note: carbon-aggregator{,-cache} doesn't work because it misses
>>>> py-cachetools, but people could get that themselves via pip, or it
>>>> could be added as a package in the future, so I left the plumbing in
>>>> as is.
>>>
>>> Hmm. People shouldn't be installing via pip to make packages work3
>>> I'd prefer to either port the dep, or @comment the files that need it.
>>>
>>>> @@ -108,3 +121,13 @@ share/examples/graphite/whitelist.conf.e
>>>> @sample /var/graphite/storage/whisper/
>>>> @owner
>>>> @group
>>>> +storage/
>>>> +storage/ceres/
>>>> +storage/ceres/dummy.txt/
>>>> +storage/lists/
>>>> +storage/log/
>>>> +storage/log/dummy.txt/
>>>> +storage/rrd/
>>>> +storage/rrd/dummy.txt/
>>>> +storage/whisper/
>>>> +storage/whisper/dummy.txt/
>>>
>>> It feels like these /usr/local/storage directories should not be installed,
>>> they are already @sample'd under /var/graphite/storage so I think should
>>> just
>>> be rm'd. But there are some missing @extra or @extraunexec that would be
>>> needed for pkg_delete -c to correctly remove files generated in this tree.
>>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/devel/quirks/Makefile,v
>> retrieving revision 1.651
>> diff -u -p -r1.651 Makefile
>> --- Makefile 27 Nov 2018 15:24:15 - 1.651
>> +++ Makefile 28 Nov 2018 12:54:48 -
>> @@ -5,7 +5,7 @@ CATEGORIES = devel databases
>> DISTFILES =
>>
>> # API.rev
>> -PKGNAME = quirks-3.44
>> +PKGNAME = quirks-3.45
>> PKG_ARCH = *
>> MAINTAINER =Marc Espie
>>
>> Index: files/Quirks.pm
>> ===
>> RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
>> retrieving revision 1.665
>> diff -u -p -r1.665 Quirks.pm
>> --- files/Quirks.pm 27 Nov 2018 15:24:15 - 1.665
>> +++ files/Quirks.pm 28 Nov 2018 12:54:48 -
>> @@ -288,6 +288,7 @@ my $stem_extensions = {
>> 'py-pafy' => 'py3-pafy',
>> 'py-libmagic' => 'py-magic',
>> 'py3-libmagic' => 'py3-magic',
>> +'py-carbon' => 'py3-carbon',
>> };
>>
>> my $obsolete_reason = {
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/databases/py-carbon/Makefile,v
>> retrieving revision 1.9
>> diff -u -p -r1.9 Makefile
>> --- Makefile 1 Nov 2017 10:44:39 - 1.9
&
Re: update py-whisper
ping
On 1/24/19 1:29 PM, Martijn van Duren wrote:
> ping
>
> On 11/27/18 12:44 PM, Martijn van Duren wrote:
>> Here's an update for databases/py-whisper, which is a requirement for
>> graphite-web, which also requires py-django, which in turn is python3
>> only nowadays. Ergo I added a python3 flavor, for which has experimental
>> support.
>>
>> Same as with py-carbon; major release notes can be found:
>> https://graphite.readthedocs.io/en/latest/releases/1_1_1.html
>>
>> OK?
>>
>> martijn
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/databases/py-whisper/Makefile,v
>> retrieving revision 1.9
>> diff -u -p -r1.9 Makefile
>> --- Makefile 14 Nov 2017 15:59:27 - 1.9
>> +++ Makefile 27 Nov 2018 11:24:27 -
>> @@ -2,7 +2,7 @@
>>
>> COMMENT=fixed size round-robin style database
>>
>> -MODPY_EGG_VERSION= 1.0.2
>> +MODPY_EGG_VERSION= 1.1.4
>>
>> DISTNAME= whisper-${MODPY_EGG_VERSION}
>> PKGNAME=py-${DISTNAME}
>> @@ -18,5 +18,20 @@ MODPY_PI =Yes
>> RUN_DEPENDS=net/rrdtool,-python
>>
>> NO_TEST = Yes
>> +
>> +FLAVORS=python3
>> +FLAVOR ?=
>> +
>> +PYBINS= find-corrupt-whisper-files rrd2whisper update-storage-times \
>> +whisper-auto-resize whisper-auto-update whisper-create whisper-diff \
>> +whisper-dump whisper-fetch whisper-fill whisper-info whisper-merge \
>> +whisper-resize whisper-set-aggregation-method whisper-set-xfilesfactor \
>> +whisper-update
>> +
>> +post-install:
>> +.for b in ${PYBINS}
>> +mv -f ${PREFIX}/bin/$b.py ${PREFIX}/bin/$b${MODPY_BIN_SUFFIX}.py
>> +.endfor
>> +
>>
>> .include
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/databases/py-whisper/distinfo,v
>> retrieving revision 1.6
>> diff -u -p -r1.6 distinfo
>> --- distinfo 14 Nov 2017 15:59:27 - 1.6
>> +++ distinfo 27 Nov 2018 11:24:27 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (whisper-1.0.2.tar.gz) = Q9v7R9wUHBdKANjVYdsByfCZp18imTjJJ9fEQN2IK+w=
>> -SIZE (whisper-1.0.2.tar.gz) = 24064
>> +SHA256 (whisper-1.1.4.tar.gz) = 7pEohztfnJfSWNNdCjLvjmLJ2kc/u9BWmC3x828LN6o=
>> +SIZE (whisper-1.1.4.tar.gz) = 31395
>> Index: pkg/PLIST
>> ===
>> RCS file: /cvs/ports/databases/py-whisper/pkg/PLIST,v
>> retrieving revision 1.4
>> diff -u -p -r1.4 PLIST
>> --- pkg/PLIST8 Jul 2017 16:09:17 - 1.4
>> +++ pkg/PLIST27 Nov 2018 11:24:27 -
>> @@ -1,20 +1,21 @@
>> @comment $OpenBSD: PLIST,v 1.4 2017/07/08 16:09:17 jasper Exp $
>> -bin/find-corrupt-whisper-files.py
>> -bin/rrd2whisper.py
>> -bin/update-storage-times.py
>> -bin/whisper-auto-resize.py
>> -bin/whisper-auto-update.py
>> -bin/whisper-create.py
>> -bin/whisper-diff.py
>> -bin/whisper-dump.py
>> -bin/whisper-fetch.py
>> -bin/whisper-fill.py
>> -bin/whisper-info.py
>> -bin/whisper-merge.py
>> -bin/whisper-resize.py
>> -bin/whisper-set-aggregation-method.py
>> -bin/whisper-set-xfilesfactor.py
>> -bin/whisper-update.py
>> +bin/find-corrupt-whisper-files${MODPY_BIN_SUFFIX}.py
>> +bin/rrd2whisper${MODPY_BIN_SUFFIX}.py
>> +bin/update-storage-times${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-auto-resize${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-auto-update${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-create${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-diff${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-dump${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-fetch${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-fill${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-info${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-merge${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-resize${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-set-aggregation-method${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-set-xfilesfactor${MODPY_BIN_SUFFIX}.py
>> +bin/whisper-update${MODPY_BIN_SUFFIX}.py
>> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}/
>> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}whisper.${MODPY_PYC_MAGIC_TAG}pyc
>>
>> lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
>> lib/python${MODPY_VERSION}/site-packages/whisper.py
>> -lib/python${MODPY_VERSION}/site-packages/whisper.pyc
>>
>
Re: new net/icinga/web2-module-graphite
ping On 11/27/18 2:26 PM, Martijn van Duren wrote: > Here's a port of web2-module-graphite. I took web2-module-director as a > basis, which worked well enough. > > The diff is for a quirk when having a service check based on > snmp-storage. The check uses regexes and anchoring with a '^' is stored > as is by icinga2-graphite, while web2-module-graphite escapes it with a > '_'. Upstream is already notified but not yet merged.[0] > > This requires a running graphite including graphite-web, but since that > can run on a separate host I don't think we should add it as a > dependency. This way we can also include it right away for people > offloading their icinga2 graphite needs to an instance not maintained > by ports. > > OK? > > martijn@ > > [0]https://github.com/Icinga/icingaweb2-module-graphite/pull/189 > web2-module-graphite.tar.gz Description: application/gzip
Re: new py-django-tagging
ping On 1/24/19 1:28 PM, Martijn van Duren wrote: > ping > > On 11/27/18 12:45 PM, Martijn van Duren wrote: >> Here's a port of django-tagging, which is a requirement for >> graphite-web. >> >> OK? >> >> martijn@ >> >
Re: [UPDATE] repmgr
ping
On 1/24/19 1:28 PM, Martijn van Duren wrote:
> ping
>
> On 11/20/18 8:27 AM, Martijn van Duren wrote:
>> ping
>>
>> repmgrd now also tested correctly.
>>
>> On 11/12/18 4:34 PM, Martijn van Duren wrote:
>>> On 11/12/18 4:30 PM, Martijn van Duren wrote:
>>>> When trying a new test-setup I found that our repmgr is quite out of
>>>> date. Here's a simple update to version 4.2.
>>>>
>>>> I haven't tested it with upgrading from our current version, but I have
>>>> tested it very basically on a streaming replication setup with setup,
>>>> failover, and switchover via repmgr. Repmgrd untested.
>>>>
>>>> OK?
>>>>
>>>> martijn@
>>>>
>>> And of course I overlooked the patches-directory.
>>>
>>> Index: Makefile
>>> ===
>>> RCS file: /cvs/ports/databases/repmgr/Makefile,v
>>> retrieving revision 1.8
>>> diff -u -p -r1.8 Makefile
>>> --- Makefile16 Mar 2016 16:46:32 - 1.8
>>> +++ Makefile12 Nov 2018 15:33:40 -
>>> @@ -2,9 +2,10 @@
>>>
>>> COMMENT = HA and replication cluster management for PostgreSQL
>>>
>>> -DISTNAME = repmgr-3.0.3
>>> +DISTNAME = repmgr-4.2
>>> CATEGORIES = databases
>>> HOMEPAGE = http://www.repmgr.org/
>>> +WRKDIST = ${WRKDIR}/${DISTNAME}.0
>>>
>>> # GPLv3
>>> PERMIT_PACKAGE_CDROM = Yes
>>> @@ -13,6 +14,7 @@ WANTLIB += c crypto m pq pthread readlin
>>>
>>> MASTER_SITES = ${HOMEPAGE}download/
>>> USE_GMAKE =Yes
>>> +CONFIGURE_STYLE = gnu
>>> MAKE_FLAGS = USE_PGXS=1
>>>
>>> # for getopt_long.h
>>> @@ -23,7 +25,7 @@ RUN_DEPENDS = net/rsync
>>> NO_TEST = Yes
>>>
>>> pre-configure:
>>> - ${SUBST_CMD} ${WRKSRC}/config.c
>>> + ${SUBST_CMD} ${WRKSRC}/configfile.c
>>>
>>> post-install:
>>> ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/repmgr
>>> Index: distinfo
>>> ===
>>> RCS file: /cvs/ports/databases/repmgr/distinfo,v
>>> retrieving revision 1.4
>>> diff -u -p -r1.4 distinfo
>>> --- distinfo23 Jan 2016 18:01:07 - 1.4
>>> +++ distinfo12 Nov 2018 15:33:40 -
>>> @@ -1,2 +1,2 @@
>>> -SHA256 (repmgr-3.0.3.tar.gz) = My5PpsuVkZOs7f0UEGDxgjQWR2a/7PQ8cfK3YVQoOBQ=
>>> -SIZE (repmgr-3.0.3.tar.gz) = 102211
>>> +SHA256 (repmgr-4.2.tar.gz) = jfYcn0TgUgesWld6a1KYdpfuQv+FCxTznl7hNaFXzv0=
>>> +SIZE (repmgr-4.2.tar.gz) = 341556
>>> Index: patches/patch-config_c
>>> ===
>>> RCS file: patches/patch-config_c
>>> diff -N patches/patch-config_c
>>> --- patches/patch-config_c 23 Jan 2016 18:01:07 - 1.1
>>> +++ /dev/null 1 Jan 1970 00:00:00 -
>>> @@ -1,16 +0,0 @@
>>> -$OpenBSD: patch-config_c,v 1.1 2016/01/23 18:01:07 ajacoutot Exp $
>>> config.c.orig Sat Jan 23 18:59:43 2016
>>> -+++ config.c Sat Jan 23 18:59:34 2016
>>> -@@ -128,10 +128,10 @@ load_config(const char *config_file, bool verbose,
>>> t_c
>>> - /* 2. "/etc/repmgr.conf" */
>>> - if (verbose == true)
>>> - {
>>> -- log_notice(_("looking for configuration file in
>>> /etc\n"));
>>> -+ log_notice(_("looking for configuration file in
>>> ${SYSCONFDIR}\n"));
>>> - }
>>> -
>>> -- snprintf(config_file_path, MAXPGPATH, "/etc/%s",
>>> CONFIG_FILE_NAME);
>>> -+ snprintf(config_file_path, MAXPGPATH, "${SYSCONFDIR}/%s",
>>> CONFIG_FILE_NAME);
>>> - if (stat(config_file_path, _config) == 0)
>>> - {
>>> - config_file_found = true;
>>> Index: patches/patch-configfile_c
>>> ===
>>> RCS file: patches/patch-configfile_c
>>> diff -N patches/patch-configfile_c
>>> --- /dev/null 1 Jan 1970 00:00:00 -
>>> +++ patches/patch-configfile_c 12 Nov 2018 15:33:40 -
>>> @@ -0,0 +1,16 @@
>>> +$OpenBSD: patch-configfile_c,v 1.1 2016/01/23 18:01:07 aj
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: update py-whisper
ping
On 11/27/18 12:44 PM, Martijn van Duren wrote:
> Here's an update for databases/py-whisper, which is a requirement for
> graphite-web, which also requires py-django, which in turn is python3
> only nowadays. Ergo I added a python3 flavor, for which has experimental
> support.
>
> Same as with py-carbon; major release notes can be found:
> https://graphite.readthedocs.io/en/latest/releases/1_1_1.html
>
> OK?
>
> martijn
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/databases/py-whisper/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- Makefile 14 Nov 2017 15:59:27 - 1.9
> +++ Makefile 27 Nov 2018 11:24:27 -
> @@ -2,7 +2,7 @@
>
> COMMENT= fixed size round-robin style database
>
> -MODPY_EGG_VERSION= 1.0.2
> +MODPY_EGG_VERSION= 1.1.4
>
> DISTNAME=whisper-${MODPY_EGG_VERSION}
> PKGNAME= py-${DISTNAME}
> @@ -18,5 +18,20 @@ MODPY_PI = Yes
> RUN_DEPENDS= net/rrdtool,-python
>
> NO_TEST =Yes
> +
> +FLAVORS= python3
> +FLAVOR ?=
> +
> +PYBINS= find-corrupt-whisper-files rrd2whisper update-storage-times \
> + whisper-auto-resize whisper-auto-update whisper-create whisper-diff \
> + whisper-dump whisper-fetch whisper-fill whisper-info whisper-merge \
> + whisper-resize whisper-set-aggregation-method whisper-set-xfilesfactor \
> + whisper-update
> +
> +post-install:
> +.for b in ${PYBINS}
> + mv -f ${PREFIX}/bin/$b.py ${PREFIX}/bin/$b${MODPY_BIN_SUFFIX}.py
> +.endfor
> +
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/databases/py-whisper/distinfo,v
> retrieving revision 1.6
> diff -u -p -r1.6 distinfo
> --- distinfo 14 Nov 2017 15:59:27 - 1.6
> +++ distinfo 27 Nov 2018 11:24:27 -
> @@ -1,2 +1,2 @@
> -SHA256 (whisper-1.0.2.tar.gz) = Q9v7R9wUHBdKANjVYdsByfCZp18imTjJJ9fEQN2IK+w=
> -SIZE (whisper-1.0.2.tar.gz) = 24064
> +SHA256 (whisper-1.1.4.tar.gz) = 7pEohztfnJfSWNNdCjLvjmLJ2kc/u9BWmC3x828LN6o=
> +SIZE (whisper-1.1.4.tar.gz) = 31395
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/databases/py-whisper/pkg/PLIST,v
> retrieving revision 1.4
> diff -u -p -r1.4 PLIST
> --- pkg/PLIST 8 Jul 2017 16:09:17 - 1.4
> +++ pkg/PLIST 27 Nov 2018 11:24:27 -
> @@ -1,20 +1,21 @@
> @comment $OpenBSD: PLIST,v 1.4 2017/07/08 16:09:17 jasper Exp $
> -bin/find-corrupt-whisper-files.py
> -bin/rrd2whisper.py
> -bin/update-storage-times.py
> -bin/whisper-auto-resize.py
> -bin/whisper-auto-update.py
> -bin/whisper-create.py
> -bin/whisper-diff.py
> -bin/whisper-dump.py
> -bin/whisper-fetch.py
> -bin/whisper-fill.py
> -bin/whisper-info.py
> -bin/whisper-merge.py
> -bin/whisper-resize.py
> -bin/whisper-set-aggregation-method.py
> -bin/whisper-set-xfilesfactor.py
> -bin/whisper-update.py
> +bin/find-corrupt-whisper-files${MODPY_BIN_SUFFIX}.py
> +bin/rrd2whisper${MODPY_BIN_SUFFIX}.py
> +bin/update-storage-times${MODPY_BIN_SUFFIX}.py
> +bin/whisper-auto-resize${MODPY_BIN_SUFFIX}.py
> +bin/whisper-auto-update${MODPY_BIN_SUFFIX}.py
> +bin/whisper-create${MODPY_BIN_SUFFIX}.py
> +bin/whisper-diff${MODPY_BIN_SUFFIX}.py
> +bin/whisper-dump${MODPY_BIN_SUFFIX}.py
> +bin/whisper-fetch${MODPY_BIN_SUFFIX}.py
> +bin/whisper-fill${MODPY_BIN_SUFFIX}.py
> +bin/whisper-info${MODPY_BIN_SUFFIX}.py
> +bin/whisper-merge${MODPY_BIN_SUFFIX}.py
> +bin/whisper-resize${MODPY_BIN_SUFFIX}.py
> +bin/whisper-set-aggregation-method${MODPY_BIN_SUFFIX}.py
> +bin/whisper-set-xfilesfactor${MODPY_BIN_SUFFIX}.py
> +bin/whisper-update${MODPY_BIN_SUFFIX}.py
> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}/
> +lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}whisper.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
> lib/python${MODPY_VERSION}/site-packages/whisper.py
> -lib/python${MODPY_VERSION}/site-packages/whisper.pyc
>
Re: new net/icinga/web2-module-graphite
ping On 11/27/18 2:26 PM, Martijn van Duren wrote: > Here's a port of web2-module-graphite. I took web2-module-director as a > basis, which worked well enough. > > The diff is for a quirk when having a service check based on > snmp-storage. The check uses regexes and anchoring with a '^' is stored > as is by icinga2-graphite, while web2-module-graphite escapes it with a > '_'. Upstream is already notified but not yet merged.[0] > > This requires a running graphite including graphite-web, but since that > can run on a separate host I don't think we should add it as a > dependency. This way we can also include it right away for people > offloading their icinga2 graphite needs to an instance not maintained > by ports. > > OK? > > martijn@ > > [0]https://github.com/Icinga/icingaweb2-module-graphite/pull/189 >
Re: update py-carbon
ping
On 11/28/18 1:56 PM, Martijn van Duren wrote:
> So something like this?
> I'll send py-cachetools in a separate diff.
>
> On 11/28/18 12:07 PM, Stuart Henderson wrote:
>> On 2018/11/28 08:25, Martijn van Duren wrote:
>>> On 11/27/18 2:36 PM, Daniel Jakots wrote:
>>>> On Tue, 27 Nov 2018 12:43:52 +0100, Martijn van Duren
>>>> wrote:
>>>>
>>>>> Here's an update to databases/py-carbon.
>>>>> There's experimental support for python3, but I haven't included it
>>>>> here because of other dependencies which don't yet have python3
>>>>> support in our tree.
>>>>
>>>> Which one(s)?
>>>>
>>> I must have goofed somewhere. It's not py-carbon directly which has
>>> "issues", but py-whisper. But let's safe that discussion for that
>>> threat.
>>>
>>> Here's an updated diff. I don't know whether mostly executable
>>> python packages should be moved to python3, or if they still
>>> should come in flavors, so I just made it a flavor, so we can
>>> quite easily dumb it down again if we just want python3.
>>
>> If it's actually useful as a library then it might be worth considering
>> whether to subpackage it - have the executables as a separate package
>> only built with the python3 flavour.
>>
>> But if (as COMMENT implies) it's only really useful as daemon/utilties
>> then I'd much prefer to just switch to py3 outright. This cuts a lot of
>> complexity from Makefile, patches and PLIST, and makes it so all users
>> are on recent python (rather than the "default" being old python).
>>
>>> Note: carbon-aggregator{,-cache} doesn't work because it misses
>>> py-cachetools, but people could get that themselves via pip, or it
>>> could be added as a package in the future, so I left the plumbing in
>>> as is.
>>
>> Hmm. People shouldn't be installing via pip to make packages work3
>> I'd prefer to either port the dep, or @comment the files that need it.
>>
>>> @@ -108,3 +121,13 @@ share/examples/graphite/whitelist.conf.e
>>> @sample /var/graphite/storage/whisper/
>>> @owner
>>> @group
>>> +storage/
>>> +storage/ceres/
>>> +storage/ceres/dummy.txt/
>>> +storage/lists/
>>> +storage/log/
>>> +storage/log/dummy.txt/
>>> +storage/rrd/
>>> +storage/rrd/dummy.txt/
>>> +storage/whisper/
>>> +storage/whisper/dummy.txt/
>>
>> It feels like these /usr/local/storage directories should not be installed,
>> they are already @sample'd under /var/graphite/storage so I think should just
>> be rm'd. But there are some missing @extra or @extraunexec that would be
>> needed for pkg_delete -c to correctly remove files generated in this tree.
>>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/quirks/Makefile,v
> retrieving revision 1.651
> diff -u -p -r1.651 Makefile
> --- Makefile 27 Nov 2018 15:24:15 - 1.651
> +++ Makefile 28 Nov 2018 12:54:48 -
> @@ -5,7 +5,7 @@ CATEGORIES = devel databases
> DISTFILES =
>
> # API.rev
> -PKGNAME =quirks-3.44
> +PKGNAME =quirks-3.45
> PKG_ARCH = *
> MAINTAINER = Marc Espie
>
> Index: files/Quirks.pm
> ===
> RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
> retrieving revision 1.665
> diff -u -p -r1.665 Quirks.pm
> --- files/Quirks.pm 27 Nov 2018 15:24:15 - 1.665
> +++ files/Quirks.pm 28 Nov 2018 12:54:48 -
> @@ -288,6 +288,7 @@ my $stem_extensions = {
> 'py-pafy' => 'py3-pafy',
> 'py-libmagic' => 'py-magic',
> 'py3-libmagic' => 'py3-magic',
> + 'py-carbon' => 'py3-carbon',
> };
>
> my $obsolete_reason = {
> Index: Makefile
> ===
> RCS file: /cvs/ports/databases/py-carbon/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- Makefile 1 Nov 2017 10:44:39 - 1.9
> +++ Makefile 28 Nov 2018 12:54:15 -
> @@ -2,12 +2,11 @@
>
> COMMENT= backend data caching and persistence daemon for Graphite
>
> -MODPY_EGG_VERSION= 1.0.1
> +MODPY_EGG_VERSION= 1.1.4
>
> DISTNAME=carbon-${MODPY_EGG_VERSION}
> PKGNAME= py-${DISTNAME}
> CATEGORIES= databases
> -REVISION=0
>
> # Apache
> PERMIT_PACKAGE_CDROM=Yes
> @@ -16,19 +15,26 @@ MODULES=
Re: new py-cachetools
ping
On 11/28/18 1:59 PM, Martijn van Duren wrote:
> Here's the port for py-cachetools, which is required to startup
> carbon-aggregator{,-cache}.py. Only lightly tested in py3 flavor by
> starting up carbon-aggregator.
>
> martijn@
>
Re: [UPDATE] repmgr
ping
On 11/20/18 8:27 AM, Martijn van Duren wrote:
> ping
>
> repmgrd now also tested correctly.
>
> On 11/12/18 4:34 PM, Martijn van Duren wrote:
>> On 11/12/18 4:30 PM, Martijn van Duren wrote:
>>> When trying a new test-setup I found that our repmgr is quite out of
>>> date. Here's a simple update to version 4.2.
>>>
>>> I haven't tested it with upgrading from our current version, but I have
>>> tested it very basically on a streaming replication setup with setup,
>>> failover, and switchover via repmgr. Repmgrd untested.
>>>
>>> OK?
>>>
>>> martijn@
>>>
>> And of course I overlooked the patches-directory.
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/databases/repmgr/Makefile,v
>> retrieving revision 1.8
>> diff -u -p -r1.8 Makefile
>> --- Makefile 16 Mar 2016 16:46:32 - 1.8
>> +++ Makefile 12 Nov 2018 15:33:40 -
>> @@ -2,9 +2,10 @@
>>
>> COMMENT = HA and replication cluster management for PostgreSQL
>>
>> -DISTNAME = repmgr-3.0.3
>> +DISTNAME = repmgr-4.2
>> CATEGORIES =databases
>> HOMEPAGE = http://www.repmgr.org/
>> +WRKDIST = ${WRKDIR}/${DISTNAME}.0
>>
>> # GPLv3
>> PERMIT_PACKAGE_CDROM = Yes
>> @@ -13,6 +14,7 @@ WANTLIB += c crypto m pq pthread readlin
>>
>> MASTER_SITES = ${HOMEPAGE}download/
>> USE_GMAKE = Yes
>> +CONFIGURE_STYLE = gnu
>> MAKE_FLAGS =USE_PGXS=1
>>
>> # for getopt_long.h
>> @@ -23,7 +25,7 @@ RUN_DEPENDS = net/rsync
>> NO_TEST = Yes
>>
>> pre-configure:
>> -${SUBST_CMD} ${WRKSRC}/config.c
>> +${SUBST_CMD} ${WRKSRC}/configfile.c
>>
>> post-install:
>> ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/repmgr
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/databases/repmgr/distinfo,v
>> retrieving revision 1.4
>> diff -u -p -r1.4 distinfo
>> --- distinfo 23 Jan 2016 18:01:07 - 1.4
>> +++ distinfo 12 Nov 2018 15:33:40 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (repmgr-3.0.3.tar.gz) = My5PpsuVkZOs7f0UEGDxgjQWR2a/7PQ8cfK3YVQoOBQ=
>> -SIZE (repmgr-3.0.3.tar.gz) = 102211
>> +SHA256 (repmgr-4.2.tar.gz) = jfYcn0TgUgesWld6a1KYdpfuQv+FCxTznl7hNaFXzv0=
>> +SIZE (repmgr-4.2.tar.gz) = 341556
>> Index: patches/patch-config_c
>> ===
>> RCS file: patches/patch-config_c
>> diff -N patches/patch-config_c
>> --- patches/patch-config_c 23 Jan 2016 18:01:07 - 1.1
>> +++ /dev/null1 Jan 1970 00:00:00 -
>> @@ -1,16 +0,0 @@
>> -$OpenBSD: patch-config_c,v 1.1 2016/01/23 18:01:07 ajacoutot Exp $
>> config.c.orig Sat Jan 23 18:59:43 2016
>> -+++ config.cSat Jan 23 18:59:34 2016
>> -@@ -128,10 +128,10 @@ load_config(const char *config_file, bool verbose, t_c
>> -/* 2. "/etc/repmgr.conf" */
>> -if (verbose == true)
>> -{
>> -- log_notice(_("looking for configuration file in
>> /etc\n"));
>> -+ log_notice(_("looking for configuration file in
>> ${SYSCONFDIR}\n"));
>> -}
>> -
>> -- snprintf(config_file_path, MAXPGPATH, "/etc/%s",
>> CONFIG_FILE_NAME);
>> -+ snprintf(config_file_path, MAXPGPATH, "${SYSCONFDIR}/%s",
>> CONFIG_FILE_NAME);
>> -if (stat(config_file_path, _config) == 0)
>> -{
>> -config_file_found = true;
>> Index: patches/patch-configfile_c
>> ===
>> RCS file: patches/patch-configfile_c
>> diff -N patches/patch-configfile_c
>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ patches/patch-configfile_c 12 Nov 2018 15:33:40 -
>> @@ -0,0 +1,16 @@
>> +$OpenBSD: patch-configfile_c,v 1.1 2016/01/23 18:01:07 ajacoutot Exp $
>> +Index: configfile.c
>> +--- configfile.c.orig
>> configfile.c
>> +@@ -188,9 +188,9 @@ load_config(const char *config_file, bool verbose, boo
>> +
>> +/* 3. "/etc/repmgr.conf" */
>> +if (verbose == true)
>> +- fprintf(stdout, _("INFO: looking for configuration file
>> in /etc\n"));
>> ++ fprintf(stdout, _("INFO: looki
Re: new py-django-tagging
ping On 11/27/18 12:45 PM, Martijn van Duren wrote: > Here's a port of django-tagging, which is a requirement for > graphite-web. > > OK? > > martijn@ >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mart...@cvs.openbsd.org 2019/01/22 23:00:27 Modified files: net/icinga/web2: Makefile net/icinga/web2/pkg: README Added files: net/icinga/web2/patches: patch-library_Icinga_Application_Modules_Manager_php Log message: When enabling a module in web2, make sure we turn an absolute path to a relative path, so that enabled modules always work from within our php-fpm chroot and from icingacli, no mather if the module is enabled via icingacli or the web interface. OK sthen@
Re: make icingacli available outside chroot
On 1/22/19 11:36 AM, Stuart Henderson wrote:
> On 2019/01/22 08:42, Martijn van Duren wrote:
>> I'm currently trying to get vsphere module to run, which requires the
>> daemon to be started via icingacli. Unfortunately this doesn't work,
>> because the module was enabled inside the chroot, which makes the
>> destination path invalid for icingacli, which runs outside a chroot.
>>
>> The following diff adds some extra logic to turn the absolute chroot
>> paths into relative paths.
>>
>> This also allows us to enable and disable modules via icingacli
>> without breaking it inside the webroot.
>>
>> OK?
>
> Did you follow the instructions in the icinga-web2 pkg-readme about
> creating the symlink? I haven't checked recently but this used to work.
I must admit, I overlooked that part, but that still only works half.
1) It only works for modules enabled with icingacli, but modules enabled
via the web interface still point to /icinga-web2/
icinga1# pwd
/var/www/etc/icingaweb2/enabledModules
icinga1# ls -l
total 0
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 37 Jan 22 07:30 graphite ->
../../../icinga-web2/modules/graphite
lrwxr-xr-x 1 root _icingaweb2 38 Jan 22 09:16 incubator ->
../../../icinga-web2/modules/incubator
lrwxr-xr-x 1 root _icingaweb2 32 Jan 22 09:14 ipl ->
../../../icinga-web2/modules/ipl
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 39 Jan 22 07:30 monitoring ->
../../../icinga-web2/modules/monitoring
lrwxr-xr-x 1 root _icingaweb2 40 Jan 22 08:47 reactbundle ->
../../../icinga-web2/modules/reactbundle
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 38 Jan 22 07:27 vspheredb ->
../../../icinga-web2/modules/vspheredb
icinga1# # Click enable button in web interface
icinga1# ls -l
total 0
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 29 Jan 22 13:57 director ->
/icinga-web2/modules/director
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 37 Jan 22 07:30 graphite ->
../../../icinga-web2/modules/graphite
lrwxr-xr-x 1 root _icingaweb2 38 Jan 22 09:16 incubator ->
../../../icinga-web2/modules/incubator
lrwxr-xr-x 1 root _icingaweb2 32 Jan 22 09:14 ipl ->
../../../icinga-web2/modules/ipl
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 39 Jan 22 07:30 monitoring ->
../../../icinga-web2/modules/monitoring
lrwxr-xr-x 1 root _icingaweb2 40 Jan 22 08:47 reactbundle ->
../../../icinga-web2/modules/reactbundle
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 38 Jan 22 07:27 vspheredb ->
../../../icinga-web2/modules/vspheredb
icinga1# icingacli module disable director
Found invalid module in enabledModule directory
"/var/www/etc/icingaweb2/enabledModules":
"/var/www/etc/icingaweb2/enabledModules/director" points to non existing path
"false"
icinga1# icingacli module enable director
icinga1# ls -l
total 0
lrwxr-xr-x 1 root _icingaweb2 37 Jan 22 13:57 director ->
/var/www/icinga-web2/modules/director
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 37 Jan 22 07:30 graphite ->
../../../icinga-web2/modules/graphite
lrwxr-xr-x 1 root _icingaweb2 38 Jan 22 09:16 incubator ->
../../../icinga-web2/modules/incubator
lrwxr-xr-x 1 root _icingaweb2 32 Jan 22 09:14 ipl ->
../../../icinga-web2/modules/ipl
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 39 Jan 22 07:30 monitoring ->
../../../icinga-web2/modules/monitoring
lrwxr-xr-x 1 root _icingaweb2 40 Jan 22 08:47 reactbundle ->
../../../icinga-web2/modules/reactbundle
lrwxr-xr-x 1 _icingaweb2 _icingaweb2 38 Jan 22 07:27 vspheredb ->
../../../icinga-web2/modules/vspheredb
2) I reckon this is basic functionality that people could reasonably
expect to work without any hacks.
>
> (and please make sure I am at least CC'd on mails about ports which
> I am listed as MAINTAINER for, ports@ is busy enough that I sometimes
> miss things there..)
>
Will do.
>
>
>> martijn@
Index: Makefile
===
RCS file: /cvs/ports/net/icinga/web2/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile22 Nov 2018 22:20:12 - 1.28
+++ Makefile22 Jan 2019 06:42:59 -
@@ -6,6 +6,7 @@ GH_ACCOUNT =Icinga
GH_PROJECT = icingaweb2
GH_TAGNAME = v2.6.2
PKGNAME = icinga-web2-${GH_TAGNAME:S/v//}
+REVISION = 0
MODULES= lang/php
Index: patches/patch-library_Icinga_Application_Modules_Manager_php
===
RCS file: patches/patch-library_Icinga_Application_Modules_Manager_php
diff -N patches/patch-library_Icinga_Application_Modules_Manager_php
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-library_Icinga_Application_Modules_Manager_php22 Jan
2019 07:36:00 -
@@ -0,
make icingacli available outside chroot
I'm currently trying to get vsphere module to run, which requires the
daemon to be started via icingacli. Unfortunately this doesn't work,
because the module was enabled inside the chroot, which makes the
destination path invalid for icingacli, which runs outside a chroot.
The following diff adds some extra logic to turn the absolute chroot
paths into relative paths.
This also allows us to enable and disable modules via icingacli
without breaking it inside the webroot.
OK?
martijn@
Index: Makefile
===
RCS file: /cvs/ports/net/icinga/web2/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile22 Nov 2018 22:20:12 - 1.28
+++ Makefile22 Jan 2019 06:42:59 -
@@ -6,6 +6,7 @@ GH_ACCOUNT =Icinga
GH_PROJECT = icingaweb2
GH_TAGNAME = v2.6.2
PKGNAME = icinga-web2-${GH_TAGNAME:S/v//}
+REVISION = 0
MODULES= lang/php
Index: patches/patch-library_Icinga_Application_Modules_Manager_php
===
RCS file: patches/patch-library_Icinga_Application_Modules_Manager_php
diff -N patches/patch-library_Icinga_Application_Modules_Manager_php
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-library_Icinga_Application_Modules_Manager_php22 Jan
2019 07:36:00 -
@@ -0,0 +1,36 @@
+$OpenBSD$
+
+Make icingacli available outside of chroot
+Index: library/Icinga/Application/Modules/Manager.php
+--- library/Icinga/Application/Modules/Manager.php.orig
library/Icinga/Application/Modules/Manager.php
+@@ -285,7 +285,28 @@ class Manager
+ return $this;
+ }
+
+-if (! @symlink($target, $link)) {
++$relTarget = explode("/", $target);
++$relLink = explode("/", $link);
++while (end($relTarget) === "") {
++array_pop($relTarget);
++}
++while (end($relLink) === "") {
++array_pop($relLink);
++}
++while (reset($relTarget) === reset($relLink)) {
++array_shift($relTarget);
++array_shift($relLink);
++}
++array_pop($relLink);
++if (empty($relLink)) {
++array_unshift($relTarget, ".");
++} else {
++while (array_shift($relLink)) {
++array_unshift($relTarget, "..");
++}
++}
++$relTarget = implode("/", $relTarget);
++if (! @symlink($relTarget, $link)) {
+ $error = error_get_last();
+ if (strstr($error["message"], "File exists") === false) {
+ throw new SystemPermissionException(
