Re: update: devel/subversion 1.14.0
On Thu, May 28, 2020 at 12:16:31AM +0100, Stuart Henderson wrote: > ...not sure what in the build is causing the problem, but the bindings are > definitely not working > > Also I think I know how to add a python3 flavour so that it can be built > > again with py3 bindings. > > I have a diff for that but it should go on top of an existing commit > rather than be stacked up Thanks a lot for your input. I like your idea of using flavours for this. And yes, we can add a py3 flavour later. Once 1.14 is in and works with py2 this will be easy to do. I will try to figure out how the bindings can be fixed for py2. The py3 ones are definitely working for me locally. I've done my release verification test runs with py3 because I was naively assuming downstreams could already flip over to py3. It felt like SVN was one of the last projects in the universe to make that transition; apparently not :)
Re: UPDATE: www/netsurf
On Mon, 25 May 2020 23:03:13 -0600 "Anthony J. Bentley" wrote: > Here's an update to netsurf-3.10. The main browser has switched from > GTK2 to GTK3, and certificate error handling has been significantly > revamped. For more, see the changelog: > https://download.netsurf-browser.org/netsurf/releases/ChangeLog.txt > > As always, test reports on diverse architectures are greatly appreciated. This update builds and runs on macppc. https://www.openbsd.org/ looks good. Other sites look less than perfect, but I can read some of them. I like having this lightweight browser, which doesn't need to build WebKit nor Gecko nor Chromium. The disadvantage is that some sites need JavaScript, but NetSurf doesn't run JavaScript. --George
NEW: graphics/chafa
Hi ports -- Attached is a new port, graphics/chafa. Chafa is a commandline utility that converts images for terminal output. --- pkg/DESCR: Chafa allows you to view reasonable approximations of pictures and animations in the comfort of your favorite terminal emulator. Features: * Supports most popular image formats, including animated GIFs. * Combines Unicode symbols from multiple selectable ranges for optimal output. * Multiple color modes, including Truecolor, 256-color, 16-color and simple FG/BG. * RGB and DIN99d color spaces for improved color picking. * Alpha transparency support in any color mode, including in animations. * Suitable for terminal graphics, ANSI art composition and even black & white print. * Works with most modern and classic terminals and terminal emulators. * Documented, stable C API. --- Builds and all tests pass on amd64 and sparc64. Testing on a big endian glass console would be appreciated. OK? ~Brian chafa.tgz Description: application/compressed-tar
[update] sysutils/udfclient
Update 0.8.9 -> 0.8.11.
>From $HOMEPAGE:
"Minor release fixing compilation errors on gcc 10.
Also corrected some minor spelling mistakes."
Index: Makefile
===
RCS file: /systems/cvs/ports/sysutils/udfclient/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile12 Jul 2019 20:49:53 - 1.9
+++ Makefile28 May 2020 01:02:18 -
@@ -2,7 +2,7 @@
COMMENT = userland implementation of the UDF filesystem
-V =0.8.9
+V =0.8.11
DISTNAME = UDFclient.${V}
PKGNAME = udfclient-${V}
CATEGORIES = sysutils
Index: distinfo
===
RCS file: /systems/cvs/ports/sysutils/udfclient/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo26 May 2019 15:17:23 - 1.5
+++ distinfo28 May 2020 01:02:47 -
@@ -1,2 +1,2 @@
-SHA256 (UDFclient.0.8.9.tgz) = mLlRDYgIOTLjxypk4eaiIogEanBqyuGMiee5ewRJyIo=
-SIZE (UDFclient.0.8.9.tgz) = 257062
+SHA256 (UDFclient.0.8.11.tgz) = TlsQLPfxND2G+DDLb2n+osGWtBE2u9MN3CbLiWnt350=
+SIZE (UDFclient.0.8.11.tgz) = 252986
UPDATE: archivers/quazip 0.8.1 => 0.9
Hi ports --
Simple update to quazip. All dependent ports built OK.
Some symbols were added, so minor bump.
OK?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/archivers/quazip/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile 25 Jan 2020 22:57:56 - 1.19
+++ Makefile 27 May 2020 20:51:48 -
@@ -5,11 +5,11 @@ CATEGORIES = archivers
GH_ACCOUNT = stachenov
GH_PROJECT = quazip
-V = 0.8.1
+V = 0.9
GH_TAGNAME = v$V
PKGNAME = quazip-qt5-$V
-SHARED_LIBS += quazip5 3.0 # 1.0
+SHARED_LIBS += quazip5 3.1 # 1.0
HOMEPAGE = https://stachenov.github.io/quazip/
MAINTAINER = Brian Callahan
Index: distinfo
===
RCS file: /cvs/ports/archivers/quazip/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo 25 Jan 2020 22:57:56 - 1.7
+++ distinfo 27 May 2020 20:51:48 -
@@ -1,2 +1,2 @@
-SHA256 (quazip-0.8.1.tar.gz) = T9pNQkjggBW1CQ0Dae+eaL3ER1qhJJT3wPbXnkMnDRQ=
-SIZE (quazip-0.8.1.tar.gz) = 150584
+SHA256 (quazip-0.9.tar.gz) = N36/d2MOTP90Ef4UnLNC4Q875VuhI8wLHuCaJfw/qgY=
+SIZE (quazip-0.9.tar.gz) = 155764
Index: pkg/PLIST
===
RCS file: /cvs/ports/archivers/quazip/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 25 Jan 2020 22:57:56 - 1.4
+++ pkg/PLIST 27 May 2020 20:51:48 -
@@ -17,6 +17,8 @@ include/quazip5/quazipfileinfo.h
include/quazip5/quazipnewinfo.h
include/quazip5/unzip.h
include/quazip5/zip.h
+lib/cmake/QuaZip5/
+lib/cmake/QuaZip5/QuaZip5Config.cmake
@static-lib lib/libquazip5.a
@lib lib/libquazip5.so.${LIBquazip5_VERSION}
-share/cmake/Modules/FindQuaZip5.cmake
+lib/pkgconfig/quazip.pc
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Mon May 25 00:55:21 MDT 2020 finished at Wed May 27 18:17:13 MDT 2020 lasted 2D17h21m done with kern.version=OpenBSD 6.7-current (GENERIC.MP) #626: Sun May 24 11:41:50 MDT 2020 built packages:10911 May 25:3993 May 26:1829 May 27:5088 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2020-05-25/summary.log build failures: 14 http://build-failures.rhaalovely.net/aarch64/2020-05-25/devel/tbb.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/graphics/vulkan-loader.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/e17/elementary.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/kde4/amor.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/kde4/parley.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/kde4/pim.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/kde4/runtime,-locale.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/kde4/superkaramba.log http://build-failures.rhaalovely.net/aarch64/2020-05-25/x11/qt5/qtwebengine.log recurrent failures failures/editors/xwpe.log failures/graphics/vulkan-loader.log failures/lang/pfe.log failures/sysutils/nomad.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log failures/x11/e17/elementary.log new failures +++ ls-failures Wed May 27 18:17:25 2020 +failures/x11/kde4/amor.log +failures/x11/kde4/parley.log +failures/x11/kde4/pim.log +failures/x11/kde4/runtime,-locale.log +failures/x11/kde4/superkaramba.log +failures/x11/qt5/qtwebengine.log resolved failures --- ../old/aarch64/last//ls-failuresSun May 24 11:01:44 2020 -failures/security/clamav.log
Re: update: devel/subversion 1.14.0
On 2020/05/27 22:38, Stuart Henderson wrote:
> On 2020/05/27 19:23, Stefan Sperling wrote:
> > lib/python${MODPY_VERSION}/site-packages/libsvn/client.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/client.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/core.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/core.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/delta.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/delta.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/diff.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/diff.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/fs.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/fs.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/ra.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/ra.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/repos.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/repos.pyc
> > lib/python${MODPY_VERSION}/site-packages/libsvn/wc.py
> > -lib/python${MODPY_VERSION}/site-packages/libsvn/wc.pyc
> > lib/python${MODPY_VERSION}/site-packages/svn/
> > lib/python${MODPY_VERSION}/site-packages/svn/__init__.py
> > lib/python${MODPY_VERSION}/site-packages/svn/__init__.pyc
>
> I am looking at this, the missing .pyc files are a red flag - in build log
> you'll see some "SyntaxError: invalid syntax" which I think suggests it may
> be using swig in py3 mode.
...not sure what in the build is causing the problem, but the bindings are
definitely not working, this should return silently:
$ python2
Python 2.7.18 (default, Apr 24 2020, 15:52:16)
[GCC 4.2.1 Compatible OpenBSD Clang 8.0.1 (tags/RELEASE_801/final)] on openbsd6
Type "help", "copyright", "credits" or "license" for more information.
>>> import svn.fs
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/site-packages/svn/fs.py", line 26, in
from libsvn.fs import *
File "/usr/local/lib/python2.7/site-packages/libsvn/fs.py", line 152
def svn_fs_version() -> "svn_version_t const *":
^
SyntaxError: invalid syntax
>>>
Old version looks like this:
$ python2
Python 2.7.18 (default, Apr 24 2020, 15:52:16)
[GCC 4.2.1 Compatible OpenBSD Clang 8.0.1 (tags/RELEASE_801/final)] on openbsd6
Type "help", "copyright", "credits" or "license" for more information.
>>> import svn.fs
>>>
autoconf does seem to be setting up to use the right parameters for swig
but I'm not all that familiar with swig/python so I may have missed
something. Whatever ends up being needed to fix generation of the pyc
files should fix runtime too.
This is probably most easily fixed by someone who knows their way around
svn's swig build infrastructure..
> Also I think I know how to add a python3 flavour so that it can be built
> again with py3 bindings.
I have a diff for that but it should go on top of an existing commit
rather than be stacked up so I'll keep it local for now. I would like
this though because it will allow moving Trac without having to deal
with cvs2svn as well. (The py2 and py3 bindings will need to conflict
due to the libsvn_swig_py-1* libraries - I don't think that's really a
problem, the trac upgrade path will be a little messy but people will
cope, it just needs a current.html entry to tell them to pkg_delete and
reinstall).
Re: NEW: x11/picom
On Wed, May 27, 2020 at 09:33:57PM +0200, Omar Polo wrote:
> This is a port for picom, a compositor for X11. It's an actively
> developed fork of compton.
>
> I've been running for a month now, and it has been rock stable (instead
> of compton which would occasionally crash.)
Rock stable here too after running for about one hour... But that is
WITH glx and box/gaussian background blur, options that would make
compton really mess things up on my (rather old) hardware.
Thank you for this port!
Erling
> Build and tested on amd64, passes port-lib-depends-check and portcheck.
$ sysctl | grep vers
kern.version=OpenBSD 6.7-current (GENERIC.MP) #197: Mon May 18 11:00:29 MDT 2020
$ dmesg | grep drm
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 5770" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
radeondrm0: 1920x1080, 32bpp
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
> A couple of notes about the patches:
>
> - (AFAIK) the project was recently renamed from "compton" to "picom",
> that's the reason they install some files that can conflict with
> x11/compton (like the bin/compton{,-trans} links to
> bin/picom{,-trans}). I've removed (and/or renamed) them to avoid the
> conflict, since I wanted to have them both installed side-by-side
>
> - moved the manpage from the (port) default share/man/man1 to
> man/man1
>
> - the patch-src_meson_build is an hack to avoid a meson error I cannot
> understand
>
> Cheers!
Re: UPDATE mail/s-nail
Stuart Henderson wrote in <20200526181335.gg4...@symphytum.spacehopper.org>: |On 2020/05/26 16:53, Steffen Nurpmeso wrote: |> Steffen Nurpmeso wrote in |> <20200427220948.ddaqe%stef...@sdaoden.eu>: |>|So here is the promised update to v14.9.19. ... |Committed without the incorrect LIB_DEPENDS changes. Thanks a lot! Next time i will read the entire manual once again, maybe i will get it right. Ciao, and keep the virus and such off the remote holes! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: update: devel/subversion 1.14.0
On 2020/05/27 19:23, Stefan Sperling wrote:
> lib/python${MODPY_VERSION}/site-packages/libsvn/client.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/client.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/core.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/core.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/delta.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/delta.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/diff.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/diff.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/fs.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/fs.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/ra.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/ra.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/repos.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/repos.pyc
> lib/python${MODPY_VERSION}/site-packages/libsvn/wc.py
> -lib/python${MODPY_VERSION}/site-packages/libsvn/wc.pyc
> lib/python${MODPY_VERSION}/site-packages/svn/
> lib/python${MODPY_VERSION}/site-packages/svn/__init__.py
> lib/python${MODPY_VERSION}/site-packages/svn/__init__.pyc
I am looking at this, the missing .pyc files are a red flag - in build log
you'll see some "SyntaxError: invalid syntax" which I think suggests it may
be using swig in py3 mode.
Also I think I know how to add a python3 flavour so that it can be built
again with py3 bindings.
NEW: devel/ruby-colored2
Hi, sysutils/ruby-r10k update has colored2 gem as dependency, in favor of the old colored dependency. The port is more or less a copy of the old devel/ruby-colored port. Afterward, the devel/ruby-colored could be sent to attic, it's not used by anything else. OK? Sebastian ruby-colored2.tar.gz Description: application/gzip
Re: update math/coq 8.11.1 supporting OCaml 4.10 - sparc64 testing needed
On Tue, May 26, 2020 at 10:57 PM Christopher Zimmermann
wrote:
>
>
>
> On May 27, 2020 2:20:54 AM GMT+02:00, Jeremie Courreges-Anglas
> wrote:
> >On Mon, May 25 2020, Daniel Dickman wrote:
> >>> On May 25, 2020, at 5:11 AM, Christopher Zimmermann
> > wrote:
> >>>
> >>> testing needed
> >>> Reply-To:
> >>> In-Reply-To: <20a364d1-d8bc-441f-9814-ebe7dfc02...@gmail.com>
> >>>
> On Sun, May 24, 2020 at 05:23:25PM -0400, Daniel Dickman wrote:
> Jeremie reported a problem on sparc64. Is it addressed in the diff
> >below?
>
> https://marc.info/?t=15819679343&r=1&w=2
> >>>
> >>> No. I forgot about this. Chances are it got fixed with Coq 8.11.1,
> >but I don't have access to sparc64 hardware. Who could test on sparc64
> >?
> >>
> >> I have a sparc64 box but it’s slow. I’ll get it started but someone
> >with a faster box will definitely beat me to it.
> >
> >Everything looks fine on sparc64,
>
> That's great. Thanks!
>
>From your big ocaml diff, OK daniel@ to update:
- coq
- ocaml-camlp4
(since Jeremie retested on sparc64)
I did notice PLIST changes for ocaml-ocamlbuild. Is it expected? Why
does it change for a newer version of ocaml?
As for Compcert, I will update it shortly (taking a bit of time for me
as I recently rebuilt my box to pickup the recent FFS2 changes)
I don't think the patch you suggested for compcert is a good idea though:
-ONLY_FOR_ARCHS = amd64 i386
+ONLY_FOR_ARCHS = ${OCAML_NATIVE_ARCHS}
For this port, ONLY_FOR_ARCHS is supposed to be tied to the list of
compcert back-ends. It is independant from the OCAML native archs, no?
Was there a reason you wanted to make this change?
Once all this has gone in, let's do the ocaml update and revision
bumps separately.
p.s. I was looking at updating ocaml-menhir recently (which compcert
needs), but it seems like we need to move to a newer dune to update
ocaml-menhir any further. But dune cannot be updated without first
fixing some of the ports that use dune to support newer dune versions.
Do you have any diffs for this already?
Re: [Bugfix] textproc/meld needs gtksourceview4
Ok aja
—
Antoine
> On 27 May 2020, at 20:34, Stefan Hagen wrote:
>
> Hello,
>
> quick fix for textproc/meld. It refuses to start without gtksourceview4.
> No other changes.
>
> Cheers,
> Stefan
>
> Index: textproc/meld/Makefile
> ===
> RCS file: /cvs/ports/textproc/meld/Makefile,v
> retrieving revision 1.69
> diff -u -p -u -p -r1.69 Makefile
> --- textproc/meld/Makefile 19 Apr 2020 07:26:24 - 1.69
> +++ textproc/meld/Makefile 27 May 2020 18:29:28 -
> @@ -5,6 +5,7 @@ COMMENT=graphical diff and merge tool
> GNOME_VERSION= 3.21.0
> GNOME_PROJECT= meld
> MODPY_EGG_VERSION= ${GNOME_VERSION}
> +REVISION= 0
>
> CATEGORIES=textproc
>
> @@ -25,7 +26,7 @@ MODGNOME_TOOLS= desktop-file-utils gtk-
> MODPY_ADJ_FILES= bin/meld
>
> RUN_DEPENDS= devel/py-gobject3${MODPY_FLAVOR} \
> - x11/gtksourceview3
> + x11/gtksourceview4
>
> # org.gnome.desktop.interface
> RUN_DEPENDS += devel/gsettings-desktop-schemas
>
NEW: x11/picom
Hi,
This is a port for picom, a compositor for X11. It's an actively
developed fork of compton.
I've been running for a month now, and it has been rock stable
(instead
of compton which would occasionally crash.)
Build and tested on amd64, passes port-lib-depends-check and
portcheck.
A couple of notes about the patches:
- (AFAIK) the project was recently renamed from "compton" to
"picom",
that's the reason they install some files that can conflict
with
x11/compton (like the bin/compton{,-trans} links to
bin/picom{,-trans}). I've removed (and/or renamed) them to
avoid the
conflict, since I wanted to have them both installed
side-by-side
- moved the manpage from the (port) default share/man/man1 to
man/man1
- the patch-src_meson_build is an hack to avoid a meson error I
cannot
understand
Cheers!
picom.tar.gz
Description: Binary data
Re: devel/gdb: Fix backtrace across signals on amd64
On Mon, 2020-05-18 at 20:28 -0400, k...@intricatesoftware.com wrote:
> Fix backtrace across signals on amd64
>
> The 'Apply the retpoline transformation to indirect jumps in the
> raw ASM' commit in 6.4 added an instruction to the sigcode.
> This fixes the offset to look for sigreturn and mantains
> backward compat till 5.0.
>
> okay?
ping
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/gdb/Makefile,v
> retrieving revision 1.65
> diff -u -p -u -r1.65 Makefile
> --- Makefile 29 Mar 2020 17:23:30 - 1.65
> +++ Makefile 18 May 2020 21:44:42 -
> @@ -4,7 +4,7 @@ COMMENT= GNU debugger
> CATEGORIES= devel
>
> DISTNAME=gdb-7.12.1
> -REVISION=10
> +REVISION=11
>
> HOMEPAGE=https://www.gnu.org/software/gdb/
>
> Index: patches/patch-gdb_amd64obsd-tdep_c
> ===
> RCS file: patches/patch-gdb_amd64obsd-tdep_c
> diff -N patches/patch-gdb_amd64obsd-tdep_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-gdb_amd64obsd-tdep_c18 May 2020 21:44:42 -
> @@ -0,0 +1,107 @@
> +$OpenBSD$
> +
> +Index: gdb/amd64obsd-tdep.c
> +--- gdb/amd64obsd-tdep.c.orig
> gdb/amd64obsd-tdep.c
> +@@ -76,8 +76,40 @@ amd64obsd_iterate_over_regset_sections (struct gdbarch
> + /* Support for signal handlers. */
> +
> + /* Default page size. */
> +-static const int amd64obsd_page_size = 4096;
> ++static const CORE_ADDR amd64obsd_page_size = 4096;
> +
> ++/* Offset & instructions for sigreturn(2). */
> ++
> ++#define SIGRETURN_INSN_LEN 9
> ++
> ++struct amd64obsd_sigreturn_info_t {
> ++ int offset;
> ++ gdb_byte sigreturn[SIGRETURN_INSN_LEN];
> ++};
> ++
> ++static const amd64obsd_sigreturn_info_t
> ++ amd64obsd_sigreturn_info[] = {
> ++ /* OpenBSD 6.4 */
> ++ { 9, { 0x48, 0xc7, 0xc0,
> ++ 0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> ++ 0x0f, 0x05 } }, /* syscall */
> ++ /* OpenBSD 5.1 */
> ++ { 6, { 0x48, 0xc7, 0xc0,
> ++ 0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> ++ 0x0f, 0x05 } }, /* syscall */
> ++ { 7, { 0x48, 0xc7, 0xc0,
> ++ 0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> ++ 0x0f, 0x05 } }, /* syscall */
> ++ /* OpenBSD 5.0 */
> ++ { 6, { 0x48, 0xc7, 0xc0,
> ++ 0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> ++ 0xcd, 0x80 } }, /* int $0x80 */
> ++ { 7, { 0x48, 0xc7, 0xc0,
> ++ 0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> ++ 0xcd, 0x80 } }, /* int $0x80 */
> ++ { -1, {} }
> ++};
> ++
> + /* Return whether THIS_FRAME corresponds to an OpenBSD sigtramp
> +routine. */
> +
> +@@ -86,20 +118,8 @@ amd64obsd_sigtramp_p (struct frame_info *this_frame)
> + {
> + CORE_ADDR pc = get_frame_pc (this_frame);
> + CORE_ADDR start_pc = (pc & ~(amd64obsd_page_size - 1));
> +- const gdb_byte osigreturn[] =
> +- {
> +-0x48, 0xc7, 0xc0,
> +-0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> +-0xcd, 0x80 /* int $0x80 */
> +- };
> +- const gdb_byte sigreturn[] =
> +- {
> +-0x48, 0xc7, 0xc0,
> +-0x67, 0x00, 0x00, 0x00, /* movq $SYS_sigreturn, %rax */
> +-0x0f, 0x05 /* syscall */
> +- };
> +- size_t buflen = (sizeof sigreturn) + 1;
> +- gdb_byte *buf;
> ++ const amd64obsd_sigreturn_info_t *info;
> ++ gdb_byte buf[SIGRETURN_INSN_LEN];
> + const char *name;
> +
> + /* If the function has a valid symbol name, it isn't a
> +@@ -113,22 +133,22 @@ amd64obsd_sigtramp_p (struct frame_info *this_frame)
> + if (find_pc_section (pc) != NULL)
> + return 0;
> +
> +- /* If we can't read the instructions at START_PC, return zero. */
> +- buf = (gdb_byte *) alloca ((sizeof sigreturn) + 1);
> +- if (!safe_frame_unwind_memory (this_frame, start_pc + 6, buf, buflen))
> +-return 0;
> ++ for (info = amd64obsd_sigreturn_info; info->offset != -1; info++)
> ++{
> +
> +- /* Check for sigreturn(2). Depending on how the assembler encoded
> +- the `movq %rsp, %rdi' instruction, the code starts at offset 6 or
> +- 7. OpenBSD 5.0 and later use the `syscall' instruction. Older
> +- versions use `int $0x80'. Check for both. */
> +- if (memcmp (buf, sigreturn, sizeof sigreturn)
> +- && memcmp (buf + 1, sigreturn, sizeof sigreturn)
> +- && memcmp (buf, osigreturn, sizeof osigreturn)
> +- && memcmp (buf + 1, osigreturn, sizeof osigreturn))
> +-return 0;
> ++ /* If we can't read the instructions at return zero. */
> ++ if (!safe_frame_unwind_memory (this_frame,
> ++start_pc + info->offset, buf, sizeof buf))
> ++continue;
> +
> +- return 1;
> ++ /* Check for sigreturn(2). */
> ++ if (memcmp (buf, info->sigreturn, sizeof buf))
> ++continue;
> ++
> ++ return 1;
> ++}
> ++
> ++ return 0;
> + }
>
[Bugfix] textproc/meld needs gtksourceview4
Hello,
quick fix for textproc/meld. It refuses to start without gtksourceview4.
No other changes.
Cheers,
Stefan
Index: textproc/meld/Makefile
===
RCS file: /cvs/ports/textproc/meld/Makefile,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 Makefile
--- textproc/meld/Makefile 19 Apr 2020 07:26:24 - 1.69
+++ textproc/meld/Makefile 27 May 2020 18:29:28 -
@@ -5,6 +5,7 @@ COMMENT=graphical diff and merge tool
GNOME_VERSION= 3.21.0
GNOME_PROJECT= meld
MODPY_EGG_VERSION= ${GNOME_VERSION}
+REVISION= 0
CATEGORIES=textproc
@@ -25,7 +26,7 @@ MODGNOME_TOOLS= desktop-file-utils gtk-
MODPY_ADJ_FILES= bin/meld
RUN_DEPENDS= devel/py-gobject3${MODPY_FLAVOR} \
- x11/gtksourceview3
+ x11/gtksourceview4
# org.gnome.desktop.interface
RUN_DEPENDS += devel/gsettings-desktop-schemas
update: devel/subversion 1.14.0
This updates devel/subversion to 1.14.0.
Release notes: https://subversion.apache.org/docs/release-notes/1.14.html
For the actual list of changes since 1.13.0, see the CHANGES file:
https://svn.apache.org/repos/asf/subversion/trunk/CHANGES
Not a lot has changed since 1.13.0, so this is really more of a
maintenance update from the point of view of our ports tree.
The big ticket item relative to 1.13.0 is much better Python3 support.
The new devel/py3c port which was imported today is now required.
However, the Python bindings in our port remain on Python 2.7 for now to
avoid problems with consumers in the ports tree which do not yet support
Python3. AFAIK those are cvs2svn and trac. I am now setting MODPY_VERSION
explicitly to make sure we don't flip this port to a newer version by
accident.
I am switching to Ruby 2.7 since Subversion's Ruby bindings can now work
with it.
ok?
diff 24cae81146b73ebd1005423a1e7a1b85981687f0 /usr/ports
blob - 3ca5215b4bf8aed2aaafd4b25271aec3c474a3af
file + devel/subversion/Makefile
--- devel/subversion/Makefile
+++ devel/subversion/Makefile
@@ -7,7 +7,7 @@ COMMENT-ruby= ruby interface to subversion
COMMENT-ap2= apache2 subversion modules
COMMENT-gnome-keyring= GNOME keyring support for subversion
-VERSION= 1.13.0
+VERSION= 1.14.0
DISTNAME= subversion-${VERSION:S/rc/-rc/}
PKGNAME-main= subversion-${VERSION}
FULLPKGNAME-perl= p5-SVN-${VERSION}
@@ -21,17 +21,15 @@ FULLPKGPATH-ap2=devel/subversion,-ap2
FULLPKGNAME-gnome-keyring= gnome-keyring-subversion-${VERSION}
FULLPKGPATH-gnome-keyring= devel/subversion,-gnome-keyring
-REVISION-main= 1
-REVISION-perl= 0
-REVISION-python= 0
-REVISION-ruby= 0
-REVISION-ap2= 0
-
-MODRUBY_REV ?= 2.5
+MODRUBY_REV ?= 2.7
# Work around for SHARED_LIBS not picking up MODRUBY_BINREV from ruby module
MODRUBY_BINREV=${MODRUBY_REV:S/.//}
-SO_VERSION=5.0
+# Subversion supports either python2 or python3 bindings. Consumers in the
+# ports tree are not yet ready for python3. So keep using python 2.7 for now.
+MODPY_VERSION ?= 2.7
+
+SO_VERSION=6.0
SVN_LIBS= svn_client-1 svn_delta-1 svn_diff-1 svn_fs-1 \
svn_fs_base-1 svn_fs_fs-1 svn_fs_util-1 svn_fs_x-1 \
svn_ra-1 svn_ra_serf-1 svn_ra_local-1 \
@@ -69,7 +67,8 @@ MODULES= lang/python
WANTLIB= expat iconv intl lz4 m pthread z
-BUILD_DEPENDS= devel/gettext,-tools
+BUILD_DEPENDS= devel/gettext,-tools \
+ devel/py3c
MULTI_PACKAGES = -main -ap2 -perl -python -ruby -gnome-keyring
@@ -143,7 +142,7 @@ RUN_DEPENDS-gnome-keyring=
MAKE_FLAGS=MAKE=${MAKE_PROGRAM}
CONFIGURE_STYLE=gnu
-CONFIGURE_ENV= PYTHON2=${MODPY_BIN} MKDIR="/bin/mkdir -p"
+CONFIGURE_ENV= PYTHON=${MODPY_BIN} MKDIR="/bin/mkdir -p"
CONFIGURE_ARGS+=--with-sasl=${LOCALBASE} \
--without-jikes \
--without-jdk \
blob - f3e9a934ed16ecc22fe06886f22fcc6fb457fe39
file + devel/subversion/distinfo
--- devel/subversion/distinfo
+++ devel/subversion/distinfo
@@ -1,2 +1,2 @@
-SHA256 (subversion-1.13.0.tar.bz2) =
vFDOLD+qexrpEDxDIBffmN/ZicQjn5+CcLs6MU7Z5b0=
-SIZE (subversion-1.13.0.tar.bz2) = 8508122
+SHA256 (subversion-1.14.0.tar.bz2) =
a6jiGPn5eoOnmeWKPG2hIh0DSxjZ2Mu8tuxSqxFyIQI=
+SIZE (subversion-1.14.0.tar.bz2) = 8497531
blob - facc9081810686bf9f2549d8846e28032e04b64b
file + devel/subversion/patches/patch-Makefile_in
--- devel/subversion/patches/patch-Makefile_in
+++ devel/subversion/patches/patch-Makefile_in
@@ -17,20 +17,14 @@ Index: Makefile.in
# where to install pkg-config files
pkgconfig_dir = $(datadir)/pkgconfig
-@@ -150,13 +150,13 @@ BOOST_TEST_LDFLAGS = @BOOST_LDFLAGS@ @BOOST_UNIT_TEST_
+@@ -150,8 +150,8 @@ BOOST_TEST_LDFLAGS = @BOOST_LDFLAGS@ @BOOST_UNIT_TEST_
SWIG = @SWIG@
- SWIG_PY_INCLUDES = @SWIG_PY_INCLUDES@ -I$(SWIG_SRC_DIR)/python/libsvn_swig_py
+ SWIG_PY_INCLUDES = @SWIG_PY_INCLUDES@ @SVN_PY3C_INCLUDES@
-I$(SWIG_SRC_DIR)/python/libsvn_swig_py
SWIG_PY_COMPILE = @SWIG_PY_COMPILE@
-SWIG_PY_LINK = @SWIG_PY_LINK@
-SWIG_PY_LIBS = @SWIG_PY_LIBS@
+SWIG_PY_LINK = @SWIG_PY_LINK@ -L@libdir@
+SWIG_PY_LIBS = -lpython${MODPY_VERSION}
+ SWIG_PY_ERRMSG = @SWIG_PY_ERRMSG@
SWIG_PL_INCLUDES = @SWIG_PL_INCLUDES@
- SWIG_RB_INCLUDES = @SWIG_RB_INCLUDES@ -I$(SWIG_SRC_DIR)/ruby/libsvn_swig_ruby
- SWIG_RB_COMPILE = @SWIG_RB_COMPILE@
- SWIG_RB_LINK = @SWIG_RB_LINK@
--SWIG_RB_LIBS = @SWIG_RB_LIBS@
-+SWIG_RB_LIBS = -lruby${MODRUBY_BINREV}
- SWIG_RB_SITE_LIB_DIR = @SWIG_RB_SITE_LIB_DIR@
- SWIG_RB_SITE_ARCH_DIR = @SWIG_RB_SITE_ARCH_DIR@
- SWIG_RB_TEST_VERBOSE = @SWIG_RB_TEST_VERBOSE@
+ SWIG_PL_ERRMSG = @SWIG_PL_ERRMSG@
blob - 10f71448f892f604a77d21e8a59dc1e1d0840cc2
file + devel/subversion/pkg/PLIST-python
--- devel/subversion/pkg/PLIST-python
+++ devel/subversion/pkg/PLIST-python
@@ -31,21 +31,13 @@ lib/python${MODPY_VERSION}/site-packages/libsvn/_wc.a
lib/python${MODPY_VERSION}/site-packages/l
Re: [UPDATE] dovecot-fts-xapian to 1.3.1, and RUN_DEPENDS query
Le Wed, 27 May 2020 20:20:16 +1200, Tom Wong-Cornall a écrit : > Hi ports, > > Question re. BUILD_ and RUN_DEPENDS; user has reported (running > -stable) that `pkg_add dovecot dovecot-fts-xapian` fails because > dovecot-fts-xapian-1.2.9p0 depends on dovecot-2.3.10p0v0; > dovecot-2.3.10.1v0 is in -stable. Is there something else I should be > doing to cause a rebuild to happen when dovecot is bumped, or should > I have manually bumped dovecot-fts-xapian? Hello, thank you for reporting this. Fixed packages will be available very soon on mirrors.
Re: remove devel/pysvn?
On Wed, May 27, 2020 at 12:29:05PM +0200, Jeremie Courreges-Anglas wrote: > On Wed, May 27 2020, Stefan Sperling wrote: > > Would anyone be sad to see devel/pysvn go away? > > > > Every time Subversion gets a significant update I need to check whether > > pysvn still works and it will usually require an update. > > > > Current releases of pysvn have split some C++ parts into a separate pycxx > > project. Adding that seems like too much effort for questionable gain. > > I added the pysvn port 10 years ago. In all this time I have never seen > > evidence of anything or anyone depending on it. > > Nothing in the ports tree uses it, as far as I can tell. > > My personal policy is that, if nothing uses a library in ports, then > someone who depends on the lib should step up as a maintainer, and bear > the testing and updating efforts. > > If that someone doesn't exist, ok jca@ to drop pysvn. Agreed. -- Antoine
Re: remove devel/pysvn?
On Wed May 27, 2020 at 12:29:05PM +0200, Jeremie Courreges-Anglas wrote: > On Wed, May 27 2020, Stefan Sperling wrote: > > My personal policy is that, if nothing uses a library in ports, then > someone who depends on the lib should step up as a maintainer, and bear > the testing and updating efforts. +1 > > If that someone doesn't exist, ok jca@ to drop pysvn. > > (I'd wait for a few days, YMMV) > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
Le Wed, 27 May 2020 13:19:47 +0100,
Stuart Henderson a écrit :
> On 2020/05/27 13:58, Solene Rapenne wrote:
> > Le Wed, 27 May 2020 12:33:27 +0100,
> > Stuart Henderson a écrit :
> >
> > > On 2020/05/27 13:21, Solene Rapenne wrote:
> > > > Le Wed, 27 May 2020 11:55:20 +0100,
> > > > Stuart Henderson a écrit :
> > > >
> > > > it only need to read config in /etc/i2pd/ and read/write in
> > > > /var/lib/i2pd/
> > >
> > > Does it need to rewrite existing files in /var/lib/i2pd/?
> > >
> >
> > I'm not sure to understand what you mean. /var/lib/i2pd/ is where
> > i2pd create files, store cache etc.. so i2pd daemon is pretty
> > active there, but that folder is only created by i2pd package and
> > populated at installation, then i2pd will create more files in it.
>
> The version currently in ports has some files created in there by
> @sample which are owned by _i2pd - the updated plist in the diff
> changes those to being owned by root.
>
should be fine now, thank you very much for your help
files under /var/lib/i2pd and /etc/i2pd are owned by _i2pd:_i2pd and
files under /usr/local/ are all owned by root.
Index: Makefile
===
RCS file: /cvs/ports/net/i2pd/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile16 Jun 2019 22:13:55 - 1.1.1.1
+++ Makefile27 May 2020 13:06:42 -
@@ -4,7 +4,7 @@ COMMENT = client for the I2P anonymous n
GH_ACCOUNT = PurpleI2P
GH_PROJECT = i2pd
-GH_TAGNAME = 2.26.0
+GH_TAGNAME = 2.31.0
CATEGORIES = net
HOMEPAGE = https://i2pd.website
Index: distinfo
===
RCS file: /cvs/ports/net/i2pd/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo16 Jun 2019 22:13:55 - 1.1.1.1
+++ distinfo27 May 2020 13:06:42 -
@@ -1,2 +1,2 @@
-SHA256 (i2pd-2.26.0.tar.gz) = KuGJeMh5a7a0W8jP5OHyU3fgz8n8+fRgVLCdwzhO72M=
-SIZE (i2pd-2.26.0.tar.gz) = 1073024
+SHA256 (i2pd-2.31.0.tar.gz) = fjerz0np9Z72k5Bp9NdPxr8psJ3uwRG9NWECH8E0lSg=
+SIZE (i2pd-2.31.0.tar.gz) = 1092238
Index: patches/patch-build_CMakeLists_txt
===
RCS file: /cvs/ports/net/i2pd/patches/patch-build_CMakeLists_txt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-build_CMakeLists_txt
--- patches/patch-build_CMakeLists_txt 16 Jun 2019 22:13:55 - 1.1.1.1
+++ patches/patch-build_CMakeLists_txt 27 May 2020 13:06:42 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-build_CMakeLists_txt,v 1
Index: build/CMakeLists.txt
--- build/CMakeLists.txt.orig
+++ build/CMakeLists.txt
-@@ -473,7 +473,7 @@ if (WITH_BINARY)
+@@ -456,7 +456,7 @@ if (WITH_BINARY)
target_link_libraries(libi2pd ${Boost_LIBRARIES} ${ZLIB_LIBRARY})
target_link_libraries( "${PROJECT_NAME}" libi2pd libi2pdclient ${DL_LIB}
${Boost_LIBRARIES} ${OPENSSL_LIBRARIES} ${ZLIB_LIBRARY}
${CMAKE_THREAD_LIBS_INIT} ${MINGW_EXTRA} ${DL_LIB} ${CMAKE_REQUIRED_LIBRARIES})
@@ -12,7 +12,7 @@ Index: build/CMakeLists.txt
set (APPS
"\${CMAKE_INSTALL_PREFIX}/bin/${PROJECT_NAME}${CMAKE_EXECUTABLE_SUFFIX}")
set (DIRS
"${Boost_LIBRARY_DIR};${OPENSSL_INCLUDE_DIR}/../bin;${ZLIB_INCLUDE_DIR}/../bin;/mingw32/bin")
if (MSVC)
-@@ -487,7 +487,7 @@ if (WITH_BINARY)
+@@ -470,7 +470,7 @@ if (WITH_BINARY)
endif ()
install(FILES ../LICENSE
@@ -21,7 +21,7 @@ Index: build/CMakeLists.txt
COMPONENT Runtime
)
# Take a copy on Appveyor
-@@ -498,8 +498,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
+@@ -481,8 +481,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
OPTIONAL # for local builds only!
)
@@ -32,7 +32,7 @@ Index: build/CMakeLists.txt
# install(DIRECTORY ../ DESTINATION src/
# # OPTIONAL
# COMPONENT Source FILES_MATCHING
-@@ -508,7 +508,7 @@ install(FILES ${I2PD_SOURCES} DESTINATION src/ COMPONE
+@@ -491,7 +491,7 @@ install(FILES ${I2PD_SOURCES} DESTINATION src/ COMPONE
# )
file(GLOB I2PD_HEADERS "../libi2pd/*.h" "../libi2pd_client/*.h"
"../daemon/*.h")
Index: patches/patch-tests_Makefile
===
RCS file: /cvs/ports/net/i2pd/patches/patch-tests_Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-tests_Makefile
--- patches/patch-tests_Makefile16 Jun 2019 22:13:55 - 1.1.1.1
+++ patches/patch-tests_Makefile27 May 2020 13:06:42 -
@@ -14,7 +14,7 @@ Index: tests/Makefile
test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndian.cpp
../libi2pd/Log.cpp ../libi2pd/Crypto.cpp test-x25519.cpp
$(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto
-lssl -lboost_system
-@@ -22,11 +22,11 @@ test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndi
+@@ -22,14 +22,14 @@ test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndi
test-aeadchacha20poly1305: ../libi2pd/Cr
update: sysutils/sec
Routine update to 2.8.3.
ok?
Index: Makefile
===
RCS file: /home/open/cvs/ports/sysutils/sec/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- Makefile19 Jul 2019 20:44:35 - 1.35
+++ Makefile26 May 2020 14:28:05 -
@@ -2,7 +2,7 @@
COMMENT= simple event correlator
-V= 2.8.2
+V= 2.8.3
DISTNAME= sec-${V}
CATEGORIES=sysutils
MASTER_SITES= https://github.com/simple-evcorr/sec/releases/download/${V}/
Index: distinfo
===
RCS file: /home/open/cvs/ports/sysutils/sec/distinfo,v
retrieving revision 1.29
diff -u -p -r1.29 distinfo
--- distinfo19 Jul 2019 20:44:35 - 1.29
+++ distinfo26 May 2020 14:28:11 -
@@ -1,2 +1,2 @@
-SHA256 (sec-2.8.2.tar.gz) = 7Hswt3Ih9Y3kyR3xFbB6n13pGBP5BP0BAHYyOJZyqjw=
-SIZE (sec-2.8.2.tar.gz) = 144131
+SHA256 (sec-2.8.3.tar.gz) = s3a2TtW+GbKBAdl0rE1gwGofUsw9i6Y4KaGKb5A9/Sk=
+SIZE (sec-2.8.3.tar.gz) = 144950
Re: [update] pgbouncer 1.13.0
On Wed, May 27, 2020 at 11:39:24AM +0200, Landry Breuil wrote:
> On Wed, May 20, 2020 at 08:18:59AM +0200, Landry Breuil wrote:
> > Hi,
> >
> > here's an update to pgbouncer 1.13, cf
> > https://github.com/pgbouncer/pgbouncer/releases/tag/pgbouncer_1_12_0 and
> > https://github.com/pgbouncer/pgbouncer/releases/tag/pgbouncer_1_13_0 for
> > the relnotes:
> >
> > - builds fine, not tested at runtime yet
> > - now uses libevent2 instead of requiring libeventextra old apis
> > - some work needed on the tests, but i think they could be enabled
> > somehow. It tries to add pf rules to a dedicated anchor so my guess is
> > that's to test connectivity breaks.. and there's support for 'make
> > check' ootb, but for some reason it doesnt find ./test.sh under test/.
> >
> > Landry
>
> Ping ? pea@, can you test this ?
>
Yes, sorry for the late answer.
I will test it asap.
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/databases/pgbouncer/Makefile,v
> > retrieving revision 1.29
> > diff -u -r1.29 Makefile
> > --- Makefile12 Jul 2019 21:15:34 - 1.29
> > +++ Makefile20 May 2020 06:14:33 -
> > @@ -2,7 +2,7 @@
> >
> > COMMENT = lightweight connection pooler for PostgreSQL
> >
> > -V =1.9.0
> > +V =1.13.0
> > DISTNAME = pgbouncer-${V}
> >
> > CATEGORIES = databases
> > @@ -14,11 +14,11 @@
> > # BSD
> > PERMIT_PACKAGE = Yes
> >
> > -WANTLIB = c event crypto ssl pthread
> > +WANTLIB = c event_core event_extra crypto ssl
> >
> > MASTER_SITES = https://pgbouncer.github.io/downloads/files/${V}/
> >
> > -BUILD_DEPENDS =devel/libeventextra
> > +LIB_DEPENDS = devel/libevent2
> >
> > CONFIGURE_STYLE = gnu
> > #Disable the detection of asciidoc since docs are already included
> > @@ -31,6 +31,6 @@
> > # The actual regress tests are (cd ${WRKSRC}/test; ./test.sh)
> > # They want to create full postgres install and also play with
> > # firewall (iptables)
> > -NO_TEST = Yes
> > +#NO_TEST = Yes
> >
> > .include
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/databases/pgbouncer/distinfo,v
> > retrieving revision 1.12
> > diff -u -r1.12 distinfo
> > --- distinfo10 Sep 2018 12:38:35 - 1.12
> > +++ distinfo20 May 2020 06:14:33 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (pgbouncer-1.9.0.tar.gz) =
> > OeypYTOYY2Mn55y8vVtBEVA1vKnKG9NyVTlkZGiCXwQ=
> > -SIZE (pgbouncer-1.9.0.tar.gz) = 469300
> > +SHA256 (pgbouncer-1.13.0.tar.gz) =
> > TLghyV8FYlWUNVu6icE58qTgYq8iHCE1vwUmuSDInTE=
> > +SIZE (pgbouncer-1.13.0.tar.gz) = 574955
> > Index: patches/patch-configure
> > ===
> > RCS file: /cvs/ports/databases/pgbouncer/patches/patch-configure,v
> > retrieving revision 1.1
> > diff -u -r1.1 patch-configure
> > --- patches/patch-configure 22 Jan 2018 10:57:29 - 1.1
> > +++ patches/patch-configure 20 May 2020 06:14:33 -
> > @@ -3,7 +3,7 @@
> > Index: configure
> > --- configure.orig
> > +++ configure
> > -@@ -7190,7 +7190,7 @@ $as_echo_n "checking for the pthreads library
> > -l$flag.
> > +@@ -7359,7 +7359,7 @@ $as_echo_n "checking for the pthreads library
> > -l$flag.
> > # We try pthread_create on general principles.
> > cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> > /* end confdefs.h. */
> > Index: patches/patch-etc_pgbouncer_ini
> > ===
> > RCS file: /cvs/ports/databases/pgbouncer/patches/patch-etc_pgbouncer_ini,v
> > retrieving revision 1.5
> > diff -u -r1.5 patch-etc_pgbouncer_ini
> > --- patches/patch-etc_pgbouncer_ini 22 Jan 2018 10:57:29 - 1.5
> > +++ patches/patch-etc_pgbouncer_ini 20 May 2020 06:14:33 -
> > @@ -2,21 +2,21 @@
> > Index: etc/pgbouncer.ini
> > --- etc/pgbouncer.ini.orig
> > +++ etc/pgbouncer.ini
> > -@@ -103,7 +103,7 @@ listen_port = 6432
> > +@@ -112,7 +112,7 @@ listen_port = 6432
> > ;;;
> >
> > - ; any, trust, plain, crypt, md5, cert, hba, pam
> > + ;; any, trust, plain, md5, cert, hba, pam
> > -auth_type = trust
> > +auth_type = md5
> > - ;auth_file = /8.0/main/global/pg_auth
> > auth_file = /etc/pgbouncer/userlist.txt
> >
> > -@@ -119,7 +119,7 @@ auth_file = /etc/pgbouncer/userlist.txt
> > + ;; Path to HBA-style auth config
> > +@@ -127,7 +127,7 @@ auth_file = /etc/pgbouncer/userlist.txt
> > ;;;
> >
> > - ; comma-separated list of users, who are allowed to change settings
> > + ;; comma-separated list of users who are allowed to change settings
> > -;admin_users = user2, someadmin, otheradmin
> > +admin_users = admin, pgbouncer
> >
> > - ; comma-separated list of users who are just allowed to use SHOW command
> > + ;; comma-separated list of users who are just allowed to use SHOW command
> > ;stats_users = stat
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
On 2020/05/27 13:58, Solene Rapenne wrote: > Le Wed, 27 May 2020 12:33:27 +0100, > Stuart Henderson a écrit : > > > On 2020/05/27 13:21, Solene Rapenne wrote: > > > Le Wed, 27 May 2020 11:55:20 +0100, > > > Stuart Henderson a écrit : > > > > > > it only need to read config in /etc/i2pd/ and read/write in > > > /var/lib/i2pd/ > > > > Does it need to rewrite existing files in /var/lib/i2pd/? > > > > I'm not sure to understand what you mean. /var/lib/i2pd/ is where i2pd > create files, store cache etc.. so i2pd daemon is pretty active there, > but that folder is only created by i2pd package and populated at > installation, then i2pd will create more files in it. The version currently in ports has some files created in there by @sample which are owned by _i2pd - the updated plist in the diff changes those to being owned by root.
Re: firefox and electronic national identity card
Sebastien Marie wrote: > The diff switchs the function sc_mem_secure_alloc() to uses mmap(2) with > MAP_CONCEAL as we do for secrets (it excludes this chunk of memory from core > dumps), and to not uses mlock(2). And changes sc_mem_secure_free() too. Why. They tried to keep it out of swap, which is meaningless. Why is keeping it out of core files meaningless? corefiles are not world-readable, and the user who can read them can still attach with ptrace and inspect the process, in both these cases. Why do also you feel compelled to solve a problem --- which the ssh client doesn't solve? If a program like that doesn'nt solve it, why does this library, which ges loaded into a behemoth, need to? What makes this code so special that it needs to use rare functionality that almost no other code uses?
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
Le Wed, 27 May 2020 12:33:27 +0100, Stuart Henderson a écrit : > On 2020/05/27 13:21, Solene Rapenne wrote: > > Le Wed, 27 May 2020 11:55:20 +0100, > > Stuart Henderson a écrit : > > > > it only need to read config in /etc/i2pd/ and read/write in > > /var/lib/i2pd/ > > Does it need to rewrite existing files in /var/lib/i2pd/? > I'm not sure to understand what you mean. /var/lib/i2pd/ is where i2pd create files, store cache etc.. so i2pd daemon is pretty active there, but that folder is only created by i2pd package and populated at installation, then i2pd will create more files in it.
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
On 2020/05/27 13:21, Solene Rapenne wrote:
> Le Wed, 27 May 2020 11:55:20 +0100,
> Stuart Henderson a écrit :
>
> > On 2020/05/27 12:47, Solene Rapenne wrote:
> > > share/examples/i2pd/
> > > share/examples/i2pd/certificates/
> > > share/examples/i2pd/certificates/family/
> > > -@sample ${LOCALSTATEDIR}/lib/
> >
> > That @sample should remain where it is (it was moved down in the file,
> > _after_ the subdirectories are created), and there should be
> > additional @sample for
> >
> > @sample ${LOCALSTATEDIR}/lib/i2pd/
> > @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/
> > @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/
> > @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/reseed/
> > @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/router/
>
> those are already in my previous mail
>
> @owner _i2pd
> @group _i2pd
> @sample ${SYSCONFDIR}/i2pd/
> @sample ${LOCALSTATEDIR}/lib/i2pd/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/reseed/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/router/
Oh, I see. So "@sample ${LOCALSTATEDIR}/lib/" needs to be listed before
"@sample ${LOCALSTATEDIR}/lib/i2pd/".
> I'll add this after previous lines
> @sample ${LOCALSTATEDIR}/lib/i2pd/
>
> > > share/examples/i2pd/certificates/family/gostcoin.crt
> > > -@owner _i2pd
> > > -@group _i2pd
> > > @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/gostcoin.crt
> > > -@owner
> > > -@group
>
> > I have no idea (or interest) in i2pd, does it need to write to those
> > files/directories at runtime? If so then at least the directories,
> > maybe also the files, need to keep @owner/group set.
> >
>
> it only need to read config in /etc/i2pd/ and read/write in
> /var/lib/i2pd/
Does it need to rewrite existing files in /var/lib/i2pd/?
Re: firefox and electronic national identity card
On Wed, May 27, 2020 at 07:59:09AM +0200, Landry Breuil wrote:
>
> Maybe opensc upstream have valid reasons for calling mlock() or not, i'm
> not in a position to judge that.
>
> Anyway, the corresponding code is probably there:
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc.c#L895
>
> Which was added 2 years ago in this PR, with subject 'Added memory
> locking for secrets': https://github.com/OpenSC/OpenSC/pull/1491/files
>
> And fwiw, i recently had exchanges with someone else trying to use an
> estonian id card, so it seems this usecase is 'common'. Maybe
> fixing/looking at opensc is the way to go.
>
Here a diff for security/opensc.
>From the PR description, the uses of mlock() is specially to avoid leaking
secrets to swap.
The diff switchs the function sc_mem_secure_alloc() to uses mmap(2) with
MAP_CONCEAL as we do for secrets (it excludes this chunk of memory from core
dumps), and to not uses mlock(2). And changes sc_mem_secure_free() too.
Could you try it (firefox with pledge(2) activated, and unveil still disabled) ?
Thanks.
--
Sebastien Marie
diff 753d46e2c6f99e4a69ce571e41ff1e16e4b9e615 /data/semarie/repos/openbsd/ports
blob - 8f081d8b44e2c20e9bed3b6786cf6069e8147ea3
file + security/opensc/Makefile
--- security/opensc/Makefile
+++ security/opensc/Makefile
@@ -3,7 +3,7 @@
COMMENT= set of libraries and utilities to access smart cards
V= 0.20.0
-REVISION = 0
+REVISION = 1
DISTNAME= opensc-${V}
SUBST_VARS += V
blob - /dev/null
file + security/opensc/patches/patch-src_libopensc_sc_c
--- security/opensc/patches/patch-src_libopensc_sc_c
+++ security/opensc/patches/patch-src_libopensc_sc_c
@@ -0,0 +1,42 @@
+$OpenBSD$
+use MAP_CONCEAL and avoid mlock(2)
+Index: src/libopensc/sc.c
+--- src/libopensc/sc.c.orig
src/libopensc/sc.c
+@@ -892,6 +892,12 @@ void *sc_mem_secure_alloc(size_t len)
+ len = pages * page_size;
+ }
+
++#ifdef _OPENBSD_
++ p = mmap(NULL, len, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON|MAP_CONCEAL, -1, 0);
++ if (p == MAP_FAILED) {
++ return NULL;
++ }
++#else
+ p = malloc(len);
+ if (p == NULL) {
+ return NULL;
+@@ -901,18 +907,23 @@ void *sc_mem_secure_alloc(size_t len)
+ #else
+ mlock(p, len);
+ #endif
++#endif
+
+ return p;
+ }
+
+ void sc_mem_secure_free(void *ptr, size_t len)
+ {
++#ifdef _OPENBSD_
++ munmap(ptr, len);
++#else
+ #ifdef _WIN32
+ VirtualUnlock(ptr, len);
+ #else
+ munlock(ptr, len);
+ #endif
+ free(ptr);
++#endif
+ }
+
+ void sc_mem_clear(void *ptr, size_t len)
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
Le Wed, 27 May 2020 11:55:20 +0100,
Stuart Henderson a écrit :
> On 2020/05/27 12:47, Solene Rapenne wrote:
> > share/examples/i2pd/
> > share/examples/i2pd/certificates/
> > share/examples/i2pd/certificates/family/
> > -@sample ${LOCALSTATEDIR}/lib/
>
> That @sample should remain where it is (it was moved down in the file,
> _after_ the subdirectories are created), and there should be
> additional @sample for
>
> @sample ${LOCALSTATEDIR}/lib/i2pd/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/reseed/
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/router/
those are already in my previous mail
@owner _i2pd
@group _i2pd
@sample ${SYSCONFDIR}/i2pd/
@sample ${LOCALSTATEDIR}/lib/i2pd/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/reseed/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/router/
I'll add this after previous lines
@sample ${LOCALSTATEDIR}/lib/i2pd/
> > share/examples/i2pd/certificates/family/gostcoin.crt
> > -@owner _i2pd
> > -@group _i2pd
> > @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/gostcoin.crt
> > -@owner
> > -@group
> I have no idea (or interest) in i2pd, does it need to write to those
> files/directories at runtime? If so then at least the directories,
> maybe also the files, need to keep @owner/group set.
>
it only need to read config in /etc/i2pd/ and read/write in
/var/lib/i2pd/
Re: [UPDATE] dovecot-fts-xapian to 1.3.1, and RUN_DEPENDS query
On 2020/05/27 11:58, Stuart Henderson wrote: > > Question re. BUILD_ and RUN_DEPENDS; user has reported (running -stable) > > that `pkg_add dovecot dovecot-fts-xapian` fails because > > dovecot-fts-xapian-1.2.9p0 depends on dovecot-2.3.10p0v0; > > dovecot-2.3.10.1v0 is in -stable. Is there something else I should be > > doing to cause a rebuild to happen when dovecot is bumped, or should I > > have manually bumped dovecot-fts-xapian? > > There was a short period where this was broken but the -stable builds > should be picking this up again now. > > It isn't necessary to bump dovecot-fts-xapian because this is setup via > Dovecot's PKGSPEC line. > Hmm. Looks like the -stable packages are indeed still broken, could you take a look please Solene? From the @ts date it looks like it reused the release packages, I think the build script may need something like "SUBDIRLIST=xx make clean=packages". $ PKG_PATH=http://ftp.fr.openbsd.org/pub/OpenBSD/6.7/packages-stable/amd64/ pkg_info -S dovecot-fts-xapian Information for http://ftp.fr.openbsd.org/pub/OpenBSD/6.7/packages-stable/amd64/dovecot-fts-xapian-1.2.9p0.tgz Signature: dovecot-fts-xapian-1.2.9p0,5,@dovecot-2.3.10p0v0,@e2fsprogs-1.42.12p5,@icu4c-67.1,@xapian-core-1.4.15,c++.4.0,c++abi. 2.1,icudata.18.0,icui18n.18.0,icuio.18.0,icuuc.18.0,m.10.1,pthread.26.1,uuid.14.0,xapian.5.1,z.5.0 $ ftp -V -o- http://ftp.fr.openbsd.org/pub/OpenBSD/6.7/packages-stable/amd64/dovecot-fts-xapian-1.2.9p0.tgz | zgrep ^@ts @ts 1589035765 @ts 1589035765 $ date -ur 1589035765 Sat May 9 14:49:25 UTC 2020
Re: [UPDATE] dovecot-fts-xapian to 1.3.1, and RUN_DEPENDS query
On 2020/05/27 20:20, Tom Wong-Cornall wrote: > Hi ports, > > Diff below updates dovecot-fts-xapian from 1.2.9 to 1.3.1. I posted > previous update to 1.3 close to freeze, so repeating the changes from > then (less the patches I included which are now rolled into 1.3.1): > > Changes: > - There is a new dependency on sqlite3; this is used to speed up >expunges > > - Author has clarified some details around the vsz_limit parameter. >Looking at dovecot docs, increasing default_vsz_limit doesn't seem >necessary, so README changed to reflect this. > > - Timeouts on indexing, so if using lots of memory and taking forever >on some big messages it will commit at least something before >resuming > > - New index optimization function Will test/commit soon. > Question re. BUILD_ and RUN_DEPENDS; user has reported (running -stable) > that `pkg_add dovecot dovecot-fts-xapian` fails because > dovecot-fts-xapian-1.2.9p0 depends on dovecot-2.3.10p0v0; > dovecot-2.3.10.1v0 is in -stable. Is there something else I should be > doing to cause a rebuild to happen when dovecot is bumped, or should I > have manually bumped dovecot-fts-xapian? There was a short period where this was broken but the -stable builds should be picking this up again now. It isn't necessary to bump dovecot-fts-xapian because this is setup via Dovecot's PKGSPEC line.
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
On 2020/05/27 12:47, Solene Rapenne wrote:
> share/examples/i2pd/
> share/examples/i2pd/certificates/
> share/examples/i2pd/certificates/family/
> -@sample ${LOCALSTATEDIR}/lib/
That @sample should remain where it is (it was moved down in the file,
_after_ the subdirectories are created), and there should be additional
@sample for
@sample ${LOCALSTATEDIR}/lib/i2pd/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/reseed/
@sample ${LOCALSTATEDIR}/lib/i2pd/certificates/router/
> share/examples/i2pd/certificates/family/gostcoin.crt
> -@owner _i2pd
> -@group _i2pd
> @sample ${LOCALSTATEDIR}/lib/i2pd/certificates/family/gostcoin.crt
> -@owner
> -@group
I have no idea (or interest) in i2pd, does it need to write to those
files/directories at runtime? If so then at least the directories, maybe
also the files, need to keep @owner/group set.
Re: UPDATE: i2pd 2.26.0 -> 2.30.0
Le Thu, 30 Apr 2020 19:23:31 +0200,
Solene Rapenne a écrit :
> Le Thu, 23 Apr 2020 12:22:54 +0200,
> satmeir a écrit :
> >
> > Thank you for bearing with me
> >
>
> package built fine and starts, in floodfill mode it works as expected.
>
> Tunnels with matchtunnels = true stopped working though, maybe because
> the other end is running 2.26?
>
I reworked a bit the diff. I deleted pkg/MESSAGE because there is
already pkg/README. I cleaned README which had extra whitespaces at end
of lines and was missing the first line header.
I used update-plist after manual changes in the pkg/PLIST file, some
examples files are currently installed and owned by _i2pd for some
reasons...
2.32.0 was released 2 days ago but I would prefer to have 2.31.0 in
ports now and then update to 2.32.0, I tried quickly the latest and at
least one patch doesn't apply out of the box.
Index: Makefile
===
RCS file: /cvs/ports/net/i2pd/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile16 Jun 2019 22:13:55 - 1.1.1.1
+++ Makefile27 May 2020 10:32:24 -
@@ -4,7 +4,7 @@ COMMENT = client for the I2P anonymous n
GH_ACCOUNT = PurpleI2P
GH_PROJECT = i2pd
-GH_TAGNAME = 2.26.0
+GH_TAGNAME = 2.31.0
CATEGORIES = net
HOMEPAGE = https://i2pd.website
Index: distinfo
===
RCS file: /cvs/ports/net/i2pd/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo16 Jun 2019 22:13:55 - 1.1.1.1
+++ distinfo27 May 2020 10:32:24 -
@@ -1,2 +1,2 @@
-SHA256 (i2pd-2.26.0.tar.gz) = KuGJeMh5a7a0W8jP5OHyU3fgz8n8+fRgVLCdwzhO72M=
-SIZE (i2pd-2.26.0.tar.gz) = 1073024
+SHA256 (i2pd-2.31.0.tar.gz) = fjerz0np9Z72k5Bp9NdPxr8psJ3uwRG9NWECH8E0lSg=
+SIZE (i2pd-2.31.0.tar.gz) = 1092238
Index: patches/patch-build_CMakeLists_txt
===
RCS file: /cvs/ports/net/i2pd/patches/patch-build_CMakeLists_txt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-build_CMakeLists_txt
--- patches/patch-build_CMakeLists_txt 16 Jun 2019 22:13:55 - 1.1.1.1
+++ patches/patch-build_CMakeLists_txt 27 May 2020 10:32:24 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-build_CMakeLists_txt,v 1
Index: build/CMakeLists.txt
--- build/CMakeLists.txt.orig
+++ build/CMakeLists.txt
-@@ -473,7 +473,7 @@ if (WITH_BINARY)
+@@ -456,7 +456,7 @@ if (WITH_BINARY)
target_link_libraries(libi2pd ${Boost_LIBRARIES} ${ZLIB_LIBRARY})
target_link_libraries( "${PROJECT_NAME}" libi2pd libi2pdclient ${DL_LIB}
${Boost_LIBRARIES} ${OPENSSL_LIBRARIES} ${ZLIB_LIBRARY}
${CMAKE_THREAD_LIBS_INIT} ${MINGW_EXTRA} ${DL_LIB} ${CMAKE_REQUIRED_LIBRARIES})
@@ -12,7 +12,7 @@ Index: build/CMakeLists.txt
set (APPS
"\${CMAKE_INSTALL_PREFIX}/bin/${PROJECT_NAME}${CMAKE_EXECUTABLE_SUFFIX}")
set (DIRS
"${Boost_LIBRARY_DIR};${OPENSSL_INCLUDE_DIR}/../bin;${ZLIB_INCLUDE_DIR}/../bin;/mingw32/bin")
if (MSVC)
-@@ -487,7 +487,7 @@ if (WITH_BINARY)
+@@ -470,7 +470,7 @@ if (WITH_BINARY)
endif ()
install(FILES ../LICENSE
@@ -21,7 +21,7 @@ Index: build/CMakeLists.txt
COMPONENT Runtime
)
# Take a copy on Appveyor
-@@ -498,8 +498,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
+@@ -481,8 +481,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
OPTIONAL # for local builds only!
)
@@ -32,7 +32,7 @@ Index: build/CMakeLists.txt
# install(DIRECTORY ../ DESTINATION src/
# # OPTIONAL
# COMPONENT Source FILES_MATCHING
-@@ -508,7 +508,7 @@ install(FILES ${I2PD_SOURCES} DESTINATION src/ COMPONE
+@@ -491,7 +491,7 @@ install(FILES ${I2PD_SOURCES} DESTINATION src/ COMPONE
# )
file(GLOB I2PD_HEADERS "../libi2pd/*.h" "../libi2pd_client/*.h"
"../daemon/*.h")
Index: patches/patch-tests_Makefile
===
RCS file: /cvs/ports/net/i2pd/patches/patch-tests_Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-tests_Makefile
--- patches/patch-tests_Makefile16 Jun 2019 22:13:55 - 1.1.1.1
+++ patches/patch-tests_Makefile27 May 2020 10:32:24 -
@@ -14,7 +14,7 @@ Index: tests/Makefile
test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndian.cpp
../libi2pd/Log.cpp ../libi2pd/Crypto.cpp test-x25519.cpp
$(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto
-lssl -lboost_system
-@@ -22,11 +22,11 @@ test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndi
+@@ -22,14 +22,14 @@ test-x25519: ../libi2pd/Ed25519.cpp ../libi2pd/I2PEndi
test-aeadchacha20poly1305: ../libi2pd/Crypto.cpp ../libi2pd/ChaCha20.cpp
../libi2pd/Poly1305.cpp test-aeadchacha20poly1305.cpp
$(CXX) $(CXXFLAGS) $(NEEDED_CXXFLAGS) $(INCFLAGS) -o $@ $^ -lcrypto
-lssl -lboost_system
@@ -22,6 +22,9 @@ Index: tests/Makefile
- $(CXX) $(CXXFLAGS) $(NEED
Re: new: devel/py3c
OK with those changes, though I would prefer to skip the empty WANTLIB= line.
It could use PKG_ARCH=* though we don't (can't really) do anything useful with
that in bulk builds anyway so it doesn't make much difference :)
On 2020/05/27 12:09, Jeremie Courreges-Anglas wrote:
> On Wed, May 27 2020, Stefan Sperling wrote:
> > py3c is a header-only C library which provides a python 2/3 compat layer.
> >
> > This is required to compile the Python bindings of Subversion 1.14,
> > regardless of whether python2 or python3 bindings are built.
> >
> > I will need this as a BUILD_DEP of devel/subversion soon.
> >
> > ok?
>
> port Makefile:
> --8<--
> # Upstream's default make target just prints a list of available targets.
> # All we need upstream's Makefile to do is produce a pkg-config .pc file
> # which we can ship in our package. The Makefile's "prefix" variable ends
> # up in the generated .pc file. So use LOCALBASE instead of use PREFIX:
> MAKE_FLAGS = prefix=${LOCALBASE}
> ALL_TARGET = py3c.pc
>
> USE_GMAKE = Yes
>
> # Upstream Makefile 'make install' doesn't respect DESTDIR.
> # We replicate the entire install target here:
> -->8--
>
> ALL_TARGET is fine, the first line of the comment isn't needed IMO.
>
> prefix=${TRUEPREFIX} looks more correct than prefix=${LOCALBASE}.
>
> Maybe you already tried this, we could set
>
> FAKE_FLAGS =prefix=${DESTDIR}${PREFIX}
>
> to inject DESTDIR in the install step, but the Makefile dependencies
> would then trigger a rebuild of py3c.pc with a wrong value for
> $(includedir).
>
> I think the cleanest approach is to patch the Makefile so that it honors
> DESTDIR. This way you only need
>
> MAKE_FLAGS = prefix=${PREFIX}
>
> The patch could easily be pushed upstream since supporting DESTDIR is
> a common feature.
>
> python2 and python3 are needed for the tests so use the python module
> to register those deps. The tests fail, maybe because of a difference
> between OpenBSD and other libcs.
>
> Updated tarball, ok jca@ if you like the changes I introduced.
>
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [NEW] sysutils/fluent-bit
On 2020/05/27 07:47, Landry Breuil wrote:
> On Wed, May 27, 2020 at 01:48:55PM +0900, Masato Asou wrote:
> > Hi,
> >
> > This is a new port sysutils/fluent-bit. Fluent bit is a Log Processor
> > and Forwarder.
>
> Great stuff, i think i had a look at it some years ago and it looked
> very-linuxy/not that much portable.. nice that you made it.
>
> some notes:
> * why USE_NINJA=No ?
Couple of reasons. One is that they don't want the full path in traces and are
using some gmake-specific mess to define __FILENAME__ with the 'base' source
directory stripped off (that's easily avoided by using __FILE__ instead).
Another is that they bundle various dependencies and are building them by
calling $(MAKE). Also some of those dependencies use gmake-specific things.
LuaJIT-2.1.0-beta3
chunkio
flb_libco
jemalloc-5.2.1
jsmn
libbacktrace-ca0de05
mbedtls-2.16.5
miniz
monkey
mpack-amalgamation-1.0
msgpack-3.2.0
onigmo
rbtree
sqlite-amalgamation-331
tutf8e
Several of these are in ports already (normally dependencies should be taken
from ports rather than bundled - so that patches needed for working on OpenBSD,
at least on some arches, are picked up - and so that security fixes don't have
to be made in multiple places - for example onigmo/oniguruma is an old version
missing security fixes).
Builds for some of these do things like force using gcc as the compiler,
setting opt flags like -O3 -funroll-loops which aren't allowed in ports.
Those using autoconf bypass the normal ports infrastructure for this and
pick up tools like gsed/ggrep if present at build time, which in a bulk
build maybe removed part-way through the build.
cmake checks for some things which aren't listed as dependencies too (and
finds them if installed), which need to be disabled properly or at least check
that they don't break things if they're present when configure is run but
removed during the build
-- Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR
GTEST_MAIN_LIBRARY)
-- Found Doxygen: /usr/local/bin/doxygen (found version "1.8.18") found
components: doxygen dot
-- Found PythonInterp: /usr/local/bin/python3.8 (found version "3.8.2")
-- Found PostgreSQL: /usr/local/lib/libpq.so.6.11 (found version "12.2")
I've tidied up some things (diff below) but due to upstream's choices of
how to do things this is going to be complicated to get in proper shape for
commit.
> * why not taking maintainership ?
> * it feels weird to force gmake usage w/ cmake.. in which voodooo
> trickery does cmake end up generating $< -gmake rules ? cant the cmake
> stuff be fixed instead ?
> * 1.4.5 was released 2 days ago
> * many portability patches without comments.. are you planning to push
> those upstream via github ?
>
> other than that it reads good at first sight.
diff b192e6571d88d491076b4fcb9b72bcf952411506 /usr/ports/mystuff
blob - 4b49acd7179e29773d9bc5263bd4d5bf548afd11
file + sysutils/fluent-bit/Makefile
--- sysutils/fluent-bit/Makefile
+++ sysutils/fluent-bit/Makefile
@@ -1,9 +1,7 @@
# $OpenBSD$
-PKG_ARCH = *
+COMMENT = fast log processor and forwarder
-COMMENT = Fast log processor and forwarder
-
GH_ACCOUNT = fluent
GH_PROJECT = fluent-bit
GH_TAGNAME = v1.4.4
@@ -16,24 +14,27 @@ HOMEPAGE = https://fluentbit.io/
# Apache License 2.0
PERMIT_PACKAGE = Yes
-PERMIT_DISTFILES = Yes
+WANTLIB += c c++abi m pthread
+
MODULES= devel/cmake
-USE_NINJA =No
-# some Makefiles use "$<"
-USE_GMAKE =Yes
+# hardcodes c++abi
+COMPILER = base-clang
-# CFLAGS "-frandom-seed=\$@" generated by lib/libbacktrace/configure
-# assumes a GNU libtool's behavior, our libtool doesn't behave like so.
-USE_LIBTOOL = gnu
-
-# Makefiles generated by cmake are using "$<"
+# calls out to $(MAKE) from build files for bundled dependencies,
+# some of which need gmake.
+USE_NINJA =No
+USE_GMAKE =Yes
CONFIGURE_ARGS += -DCMAKE_MAKE_PROGRAM:FILEPATH=${LOCALBASE}/bin/gmake
CONFIGURE_ARGS +=
-DCMAKE_INSTALL_SYSCONFDIR:PATH=${LOCALBASE}/share/examples
CONFIGURE_ARGS += -DWITHOUT_HEADERS=1
CONFIGURE_ARGS += -DFLB_CORO_STACK_SIZE=16384
+
+# CFLAGS "-frandom-seed=\$@" generated by lib/libbacktrace/configure
+# breaks with openbsd libtool
+CONFIGURE_ARGS += -DFLB_BACKTRACE=OFF
BUILD_DEPENDS =devel/bison
blob - /dev/null
file + sysutils/fluent-bit/patches/patch-CMakeLists_txt
--- sysutils/fluent-bit/patches/patch-CMakeLists_txt
+++ sysutils/fluent-bit/patches/patch-CMakeLists_txt
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+avoid gmake-ism, only used to strip off the build path from trace functions
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
CMakeLists.txt
+@@ -24,11 +24,7 @@ else()
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall")
+ endif()
+
+-if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "Windows")
+- set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D__FILENAME__='\"$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")
+-else()
+- set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}
Re: remove devel/pysvn?
On Wed, May 27 2020, Stefan Sperling wrote: > Would anyone be sad to see devel/pysvn go away? > > Every time Subversion gets a significant update I need to check whether > pysvn still works and it will usually require an update. > > Current releases of pysvn have split some C++ parts into a separate pycxx > project. Adding that seems like too much effort for questionable gain. > I added the pysvn port 10 years ago. In all this time I have never seen > evidence of anything or anyone depending on it. > Nothing in the ports tree uses it, as far as I can tell. My personal policy is that, if nothing uses a library in ports, then someone who depends on the lib should step up as a maintainer, and bear the testing and updating efforts. If that someone doesn't exist, ok jca@ to drop pysvn. (I'd wait for a few days, YMMV) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: new: devel/py3c
On Wed, May 27 2020, Stefan Sperling wrote:
> py3c is a header-only C library which provides a python 2/3 compat layer.
>
> This is required to compile the Python bindings of Subversion 1.14,
> regardless of whether python2 or python3 bindings are built.
>
> I will need this as a BUILD_DEP of devel/subversion soon.
>
> ok?
port Makefile:
--8<--
# Upstream's default make target just prints a list of available targets.
# All we need upstream's Makefile to do is produce a pkg-config .pc file
# which we can ship in our package. The Makefile's "prefix" variable ends
# up in the generated .pc file. So use LOCALBASE instead of use PREFIX:
MAKE_FLAGS =prefix=${LOCALBASE}
ALL_TARGET =py3c.pc
USE_GMAKE = Yes
# Upstream Makefile 'make install' doesn't respect DESTDIR.
# We replicate the entire install target here:
-->8--
ALL_TARGET is fine, the first line of the comment isn't needed IMO.
prefix=${TRUEPREFIX} looks more correct than prefix=${LOCALBASE}.
Maybe you already tried this, we could set
FAKE_FLAGS = prefix=${DESTDIR}${PREFIX}
to inject DESTDIR in the install step, but the Makefile dependencies
would then trigger a rebuild of py3c.pc with a wrong value for
$(includedir).
I think the cleanest approach is to patch the Makefile so that it honors
DESTDIR. This way you only need
MAKE_FLAGS = prefix=${PREFIX}
The patch could easily be pushed upstream since supporting DESTDIR is
a common feature.
python2 and python3 are needed for the tests so use the python module
to register those deps. The tests fail, maybe because of a difference
between OpenBSD and other libcs.
Updated tarball, ok jca@ if you like the changes I introduced.
py3c.tgz
Description: Binary data
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
remove devel/pysvn?
Would anyone be sad to see devel/pysvn go away? Every time Subversion gets a significant update I need to check whether pysvn still works and it will usually require an update. Current releases of pysvn have split some C++ parts into a separate pycxx project. Adding that seems like too much effort for questionable gain. I added the pysvn port 10 years ago. In all this time I have never seen evidence of anything or anyone depending on it. Nothing in the ports tree uses it, as far as I can tell.
Re: [update] pgbouncer 1.13.0
On Wed, May 20, 2020 at 08:18:59AM +0200, Landry Breuil wrote:
> Hi,
>
> here's an update to pgbouncer 1.13, cf
> https://github.com/pgbouncer/pgbouncer/releases/tag/pgbouncer_1_12_0 and
> https://github.com/pgbouncer/pgbouncer/releases/tag/pgbouncer_1_13_0 for
> the relnotes:
>
> - builds fine, not tested at runtime yet
> - now uses libevent2 instead of requiring libeventextra old apis
> - some work needed on the tests, but i think they could be enabled
> somehow. It tries to add pf rules to a dedicated anchor so my guess is
> that's to test connectivity breaks.. and there's support for 'make
> check' ootb, but for some reason it doesnt find ./test.sh under test/.
>
> Landry
Ping ? pea@, can you test this ?
> Index: Makefile
> ===
> RCS file: /cvs/ports/databases/pgbouncer/Makefile,v
> retrieving revision 1.29
> diff -u -r1.29 Makefile
> --- Makefile 12 Jul 2019 21:15:34 - 1.29
> +++ Makefile 20 May 2020 06:14:33 -
> @@ -2,7 +2,7 @@
>
> COMMENT =lightweight connection pooler for PostgreSQL
>
> -V = 1.9.0
> +V = 1.13.0
> DISTNAME = pgbouncer-${V}
>
> CATEGORIES = databases
> @@ -14,11 +14,11 @@
> # BSD
> PERMIT_PACKAGE = Yes
>
> -WANTLIB =c event crypto ssl pthread
> +WANTLIB =c event_core event_extra crypto ssl
>
> MASTER_SITES = https://pgbouncer.github.io/downloads/files/${V}/
>
> -BUILD_DEPENDS = devel/libeventextra
> +LIB_DEPENDS =devel/libevent2
>
> CONFIGURE_STYLE =gnu
> #Disable the detection of asciidoc since docs are already included
> @@ -31,6 +31,6 @@
> # The actual regress tests are (cd ${WRKSRC}/test; ./test.sh)
> # They want to create full postgres install and also play with
> # firewall (iptables)
> -NO_TEST =Yes
> +#NO_TEST = Yes
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/databases/pgbouncer/distinfo,v
> retrieving revision 1.12
> diff -u -r1.12 distinfo
> --- distinfo 10 Sep 2018 12:38:35 - 1.12
> +++ distinfo 20 May 2020 06:14:33 -
> @@ -1,2 +1,2 @@
> -SHA256 (pgbouncer-1.9.0.tar.gz) =
> OeypYTOYY2Mn55y8vVtBEVA1vKnKG9NyVTlkZGiCXwQ=
> -SIZE (pgbouncer-1.9.0.tar.gz) = 469300
> +SHA256 (pgbouncer-1.13.0.tar.gz) =
> TLghyV8FYlWUNVu6icE58qTgYq8iHCE1vwUmuSDInTE=
> +SIZE (pgbouncer-1.13.0.tar.gz) = 574955
> Index: patches/patch-configure
> ===
> RCS file: /cvs/ports/databases/pgbouncer/patches/patch-configure,v
> retrieving revision 1.1
> diff -u -r1.1 patch-configure
> --- patches/patch-configure 22 Jan 2018 10:57:29 - 1.1
> +++ patches/patch-configure 20 May 2020 06:14:33 -
> @@ -3,7 +3,7 @@
> Index: configure
> --- configure.orig
> +++ configure
> -@@ -7190,7 +7190,7 @@ $as_echo_n "checking for the pthreads library -l$flag.
> +@@ -7359,7 +7359,7 @@ $as_echo_n "checking for the pthreads library -l$flag.
> # We try pthread_create on general principles.
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h. */
> Index: patches/patch-etc_pgbouncer_ini
> ===
> RCS file: /cvs/ports/databases/pgbouncer/patches/patch-etc_pgbouncer_ini,v
> retrieving revision 1.5
> diff -u -r1.5 patch-etc_pgbouncer_ini
> --- patches/patch-etc_pgbouncer_ini 22 Jan 2018 10:57:29 - 1.5
> +++ patches/patch-etc_pgbouncer_ini 20 May 2020 06:14:33 -
> @@ -2,21 +2,21 @@
> Index: etc/pgbouncer.ini
> --- etc/pgbouncer.ini.orig
> +++ etc/pgbouncer.ini
> -@@ -103,7 +103,7 @@ listen_port = 6432
> +@@ -112,7 +112,7 @@ listen_port = 6432
> ;;;
>
> - ; any, trust, plain, crypt, md5, cert, hba, pam
> + ;; any, trust, plain, md5, cert, hba, pam
> -auth_type = trust
> +auth_type = md5
> - ;auth_file = /8.0/main/global/pg_auth
> auth_file = /etc/pgbouncer/userlist.txt
>
> -@@ -119,7 +119,7 @@ auth_file = /etc/pgbouncer/userlist.txt
> + ;; Path to HBA-style auth config
> +@@ -127,7 +127,7 @@ auth_file = /etc/pgbouncer/userlist.txt
> ;;;
>
> - ; comma-separated list of users, who are allowed to change settings
> + ;; comma-separated list of users who are allowed to change settings
> -;admin_users = user2, someadmin, otheradmin
> +admin_users = admin, pgbouncer
>
> - ; comma-separated list of users who are just allowed to use SHOW command
> + ;; comma-separated list of users who are just allowed to use SHOW command
> ;stats_users = stats, root
> Index: patches/patch-lib_usual_tls_tls_c
> ===
> RCS file: /cvs/ports/databases/pgbouncer/patches/patch-lib_usual_tls_tls_c,v
> retrieving revision 1.2
> diff -u -r1.2 patch-lib_usual_tls_tls_c
> --- patches/patch-lib_usual_tls_tls_c 22 Jan 2018 10:57:29 - 1.2
> +++ patches/patch-lib_usual_tls_tls_c 20 May
Re: update: textproc/ripgrep
On Tue, May 26 2020, Stuart Henderson wrote: > On 2020/05/26 19:04, Paco Esteban wrote: >> # keep libc >=0.2.63 for sparc64 support >> MODCARGO_CRATES_UPDATE += libc >> -MODCARGO_CRATES += libc0.2.63 # MIT OR Apache-2.0 >> +MODCARGO_CRATES += libc0.2.69 # MIT OR Apache-2.0 > > MODCARGO_CRATES_UPDATE can be removed and MODCARGO_CRATES += libc > can be moved back into the main group now. > > Otherwise OK (I have not tested on sparc64 but wouldn't expect any new > problems there). Also ok jca@ (builds and works fine on sparc64) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
new: devel/py3c
py3c is a header-only C library which provides a python 2/3 compat layer. This is required to compile the Python bindings of Subversion 1.14, regardless of whether python2 or python3 bindings are built. I will need this as a BUILD_DEP of devel/subversion soon. ok? py3c.tgz Description: Binary data
[UPDATE] dovecot-fts-xapian to 1.3.1, and RUN_DEPENDS query
Hi ports,
Diff below updates dovecot-fts-xapian from 1.2.9 to 1.3.1. I posted
previous update to 1.3 close to freeze, so repeating the changes from
then (less the patches I included which are now rolled into 1.3.1):
Changes:
- There is a new dependency on sqlite3; this is used to speed up
expunges
- Author has clarified some details around the vsz_limit parameter.
Looking at dovecot docs, increasing default_vsz_limit doesn't seem
necessary, so README changed to reflect this.
- Timeouts on indexing, so if using lots of memory and taking forever
on some big messages it will commit at least something before
resuming
- New index optimization function
Question re. BUILD_ and RUN_DEPENDS; user has reported (running -stable)
that `pkg_add dovecot dovecot-fts-xapian` fails because
dovecot-fts-xapian-1.2.9p0 depends on dovecot-2.3.10p0v0;
dovecot-2.3.10.1v0 is in -stable. Is there something else I should be
doing to cause a rebuild to happen when dovecot is bumped, or should I
have manually bumped dovecot-fts-xapian?
---
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile
--- Makefile15 Feb 2020 15:38:26 - 1.3
+++ Makefile27 May 2020 08:00:58 -
@@ -2,15 +2,13 @@
COMMENT= full text search plugin for Dovecot using Xapian
-V= 1.2.9
+V= 1.3.1
GH_ACCOUNT=grosjo
GH_PROJECT=fts-xapian
GH_TAGNAME=${V}
PKGNAME= dovecot-fts-xapian-${V}
-# remove DISTNAME at next update; upstream rerolled the distfile
-DISTNAME= fts-xapian-${V}-1
REVISION= 0
CATEGORIES=mail
@@ -22,8 +20,8 @@ MAINTAINER= Tom Wong-Cornall
