Tiny fix to security/sshguard to allow use of daemon_flags

2021-03-23 Thread Andreas Kusalananda Kähäri
A user contacted me about the security/sshguard port.  They wanted to
use daemon_flags with the port, which means this needs to be added to
the pexp expression in the rc.d file.

The attached patch does this in the similar manner as is done for e.g.
sshd and unbound.


Regards,
Andreas (port maintainer)

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.
Index: Makefile
===
RCS file: /cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile18 Aug 2020 05:06:29 -  1.16
+++ Makefile23 Mar 2021 11:07:18 -
@@ -5,6 +5,8 @@ COMMENT=protect against brute force att
 DISTNAME=  sshguard-2.4.1
 CATEGORIES=security
 
+REVISION=  1
+
 HOMEPAGE=  https://www.sshguard.net/
 
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
Index: pkg/sshguard.rc
===
RCS file: /cvs/ports/security/sshguard/pkg/sshguard.rc,v
retrieving revision 1.6
diff -u -p -r1.6 sshguard.rc
--- pkg/sshguard.rc 18 Aug 2020 05:06:29 -  1.6
+++ pkg/sshguard.rc 23 Mar 2021 11:07:18 -
@@ -6,7 +6,7 @@ daemon="${TRUEPREFIX}/sbin/sshguard"
 
 . /etc/rc.d/rc.subr
 
-pexp="/bin/sh $daemon"
+pexp="/bin/sh $daemon${daemon_flags:+ $daemon_flags}"
 
 rc_bg=YES
 rc_reload=NO


zsh $OSTYPE is openbsd6.7 on -current due to no REVISION bump

2020-12-31 Thread Andreas Kusalananda Kähäri
I don't know if it's a big deal, but I just noticed that my zsh shell's
$OSTYPE variable on my -current system still says openbsd6.7 and not
openbsd6.8.

This is due to the package signature not changing since the release of
OpenBSD 6.8.  My installed zsh package has therefore not been updated to
reflect the change to this built-in variable.

Forcing an update to the package fixes this, but I'm wondering if it
would have been an idea to bump the REVISION of the port for the new
OpenBSD release?

This may possibly also affect other packages that record the OS release
in a user-accessible variable or similar place.

It's a minor issue for me as I can use "uname -r" instead.

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.



[update] security/sshguard: 2.3.1 --> 2.4.1

2020-08-14 Thread Andreas Kusalananda Kähäri
Please find a diff for updating sshguard from 2.3.1 to 2.4.1 attached.

Regards,
Andreas

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.
Index: Makefile
===
RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile12 Jul 2019 20:49:37 -  1.15
+++ Makefile14 Aug 2020 08:22:10 -
@@ -2,7 +2,7 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-2.3.1
+DISTNAME=  sshguard-2.4.1
 CATEGORIES=security
 
 HOMEPAGE=  https://www.sshguard.net/
Index: distinfo
===
RCS file: /extra/cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo29 Mar 2019 15:54:24 -  1.4
+++ distinfo14 Aug 2020 13:02:36 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-2.3.1.tar.gz) = dpBV4m33j0vKNMmnrPJl36IkwFWzPO1H9T1Vv2WdIKI=
-SIZE (sshguard-2.3.1.tar.gz) = 765330
+SHA256 (sshguard-2.4.1.tar.gz) = h10C5uZ9ztYUeQ7V42rvEWDt6pQPNTp5MGy7GFKvPGc=
+SIZE (sshguard-2.4.1.tar.gz) = 723940
Index: patches/patch-src_blocker_blocker_c
===
RCS file: 
/extra/cvs/ports/security/sshguard/patches/patch-src_blocker_blocker_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_blocker_blocker_c
--- patches/patch-src_blocker_blocker_c 29 Mar 2019 15:54:24 -  1.1
+++ patches/patch-src_blocker_blocker_c 14 Aug 2020 13:06:38 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-src_blocker_blocker_c,v 
 Index: src/blocker/blocker.c
 --- src/blocker/blocker.c.orig
 +++ src/blocker/blocker.c
-@@ -139,7 +139,8 @@ int main(int argc, char *argv[]) {
+@@ -117,7 +117,8 @@ int main(int argc, char *argv[]) {
  
  /* termination signals */
  signal(SIGTERM, sigfin_handler);
Index: patches/patch-src_sshguard_in
===
RCS file: /extra/cvs/ports/security/sshguard/patches/patch-src_sshguard_in,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_sshguard_in
--- patches/patch-src_sshguard_in   29 Mar 2019 15:54:24 -  1.1
+++ patches/patch-src_sshguard_in   14 Aug 2020 13:06:48 -
@@ -3,9 +3,9 @@ $OpenBSD: patch-src_sshguard_in,v 1.1 20
 Index: src/sshguard.in
 --- src/sshguard.in.orig
 +++ src/sshguard.in
-@@ -5,6 +5,9 @@
- # entire process group (subshell) on exit/interrupts.
- trap "trap - TERM && kill 0" INT TERM EXIT
+@@ -1,6 +1,9 @@
+ #!/bin/sh
+ # sshguard -- protect hosts from brute-force attacks
  
 +# Ignore HUP
 +trap "" HUP
Index: pkg/sshguard.rc
===
RCS file: /extra/cvs/ports/security/sshguard/pkg/sshguard.rc,v
retrieving revision 1.5
diff -u -p -r1.5 sshguard.rc
--- pkg/sshguard.rc 29 Mar 2019 15:54:24 -  1.5
+++ pkg/sshguard.rc 14 Aug 2020 13:27:01 -
@@ -6,7 +6,7 @@ daemon="${TRUEPREFIX}/sbin/sshguard"
 
 . /etc/rc.d/rc.subr
 
-pexp="${TRUEPREFIX}/libexec/sshg-blocker .*"
+pexp="/bin/sh $daemon"
 
 rc_bg=YES
 rc_reload=NO


Re: Issues with manuals+amd(8) for a handful of ports

2020-01-25 Thread Andreas Kusalananda Kähäri
On Sat, Jan 25, 2020 at 10:16:47AM +0100, Kusalananda Kähäri wrote:
> On Sat, Jan 25, 2020 at 03:07:00AM +0100, Ingo Schwarze wrote:
> > Hi Andreas,
> 
> Good morning Ingo,
> 
> See below.
> 
> > 
> > Andreas Kusalananda wrote on Wed, Jan 22, 2020 at 08:58:26PM +0100:
> > 
> > > I mount my /usr/local directory from a remote server over NFS
> > > using amd(8).  This means that I have the directories directly
[cut] 
> Since running makewhatis on /usr/local/man (and actually also without
> a directory argument at all) corrects the database, I expect that the
> /etc/weekly script will actually correct the issue on my other machines,
> rather than corrupt the database with bogus entries.

Forgot to say that running 

# sh /etc/weekly

fixes the issue on a machine where the manual database has these boges
entries.  I've moved the weekly job to another day, so I'll wait and see
if the automatic run of this fixes the issue on other machines (but I
would expect it to fix it).

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.



Re: Issues with manuals+amd(8) for a handful of ports

2020-01-25 Thread Andreas Kusalananda Kähäri
rsync
doas (k...@pooh.prefix.duckdns.org) password:
quirks-3.216 signed on 2020-01-24T11:25:24Z
Ambiguous: choose package for rsync
a   0: 
1: rsync-3.1.3
2: rsync-3.1.3-iconv
Your choice: 1
rsync-3.1.3: ok
The following new rcscripts were installed: /etc/rc.d/rsyncd
See rcctl(8) for details.
$ man -w rsync
/tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/rsync.1
$ doas makewhatis
$ man -w rsync
/tmp_mnt/eeyore/vol/local/pooh/man/man1/rsync.1

The thing that pkglocate, git and p5-File-Rename have in common, I
realize now, is that they were all installed, reinstalled, or updated
during the last week.

> 
> In general, makewhatis(8) dislikes symbolic links pointing outside
> the respective manpath and uses realpath(3) to normalize them,
> then rejects the files if they aren't in a valid location.
> What's a bit weird is that here it apparently accepted the files
> but then somehow constructed wrong filenames anyway.

I think the issue may possibly be with some path construction within the
bowels of pkg_add.

> 
> I might have to do some experimentation with symlinks to figure
> out what exactly is going on.
> 
> You could also go to
> 
>   $ cd /usr/src/regress/usr.bin/mandoc/db/dbm_dump
>   $ man mandoc.db
>   $ man -l dbm_dump.1
>   $ rm -f obj
>   $ make cleandir
>   $ make obj
>   $ make cleandir
>   $ make
>   $ ./obj/dbm_dump /usr/local/man/mandoc.db | less
> 
> to look at the (probably) broken database in detail.
> 
> > I haven't created or changed any MAN* environment variables nor do I
> > have a /etc/man.conf file.  I haven't been able to figure out what's
> > special about the manuals for these ports.
> 
> I don't expect anything to be special about these ports; i suspect
> that makewhatis(8) was run in a slightly different way or under
> slightly different circumstances.  I'm not surprised that your
> stunt of symnlinking /usr/local/man somewhere else turns out to be
> fragile.

It may be a bit of a stunt, but I don't think it's too far fetched to
have /usr/local mounted remotely via amd(8), just like it ought to
be "normal" to mount /home in the same way (which I do).  What doing
this gives me is the ability to have machines with only a 2 GB chunk
of disk for the base system while everything "extra" is mounted from a
fileserver.  Using amd(8) for this is convenient.  Using persistent NFS
mounts would also be an option, obviously.

Since running makewhatis solves this local issue for me (thanks for
that!), and since I *believe* that /etc/weekly will not corrupt the
manual database further, I'm more or less content with letting this
slide.

> 
> Yours,
>   Ingo

With kind regards,

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.



Issues with manuals+amd(8) for a handful of ports

2020-01-22 Thread Andreas Kusalananda Kähäri
Hi,

I mount my /usr/local directory from a remote server over NFS
using amd(8).  This means that I have the directories directly
beneath /usr/local appear on demand as symbolic links into
/tmp_mnt/eeyore/vol/local/pooh where the /usr/local for the local
machine "pooh" is mounted over NFS from "eeyore" (and mounted/unmounted
on demand).

This works very well, but there is a handful of ports that misbehave
with regards to manuals.  Of the 70 or so pre-built packages that I've
installed on my amd64-current system, the only ones misbehaving are

databases/pkglocatedb   (pkglocatedb-1.5)
devel/git,-main (git-2.25.0)
sysutils/p5-File-Rename-1.10(p5-File-Rename-1.10)

When I do "man pkglocate", for example, I get

man: /tmp_mnt/eeyore/vol/local/pooh/man//usr/local/man/man1/pkg_locate.1: 
SYSERR: open: No such file or directory

... and likewise for any other utility etc. from those ports.  Commands
like "git clone --help" gives similar diagnostics.

The manuals are actually visible where they are supposed to be:

$ ls -l /usr/local/man/man1/{git{,-clone},pkg_locate}.1
-rw-r--r--  1 root  bin  20005 Jan 20 22:20 /usr/local/man/man1/git-clone.1
-rw-r--r--  1 root  bin  50901 Jan 13 19:49 /usr/local/man/man1/git.1
-rw-r--r--  1 root  bin   2845 Jan 19 08:14 /usr/local/man/man1/pkg_locate.1

... so it looks as if man(1) is, for whatever reason, looking in the
wrong location for the file.

Manuals for other utilities, like rsync, pv, pwgen, openvpn, etc., do
work as they should.

I haven't created or changed any MAN* environment variables nor do I
have a /etc/man.conf file.  I haven't been able to figure out what's
special about the manuals for these ports.

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.



Re: [patch] devel/meson: enable detection of libexecinfo

2019-11-23 Thread Andreas Kusalananda Kähäri
On Sat, Nov 23, 2019 at 01:01:50PM +0100, Antoine Jacoutot wrote:
> On Sat, Nov 16, 2019 at 10:22:52AM +0100, Andreas Kusalananda Kähäri wrote:
> > On Wed, May 29, 2019 at 06:49:29PM +0200, Kusalananda Kähäri wrote:
> > > Since Meson updated from 0.50.0 to 0.50.1, the libexecinfo library, if
> > > installed, is not properly detected with Meson's find_library().  The
> > > attached patch (modification of an existing patch file that we already
> > > have) fixes this for OpenBSD.
> > > 
> > > I have also opened an issue about this on the Meson Github pages.
> > > https://github.com/mesonbuild/meson/issues/5432
> > > 
> > > Regards,
> > > 
> > > -- 
> > > Kusalananda
> > > Sweden
> > 
> > I just noticed that the update to Meson 0.52.0 on the 8th of November
> > seems to have brought back the issue with the libexecinfo referred to
> > above.
> > 
> > I haven't written a new patch as I saw that
> > patch-mesonbuild_compilers_compilers_py had been delete from the port
> > some four months ago.
> > 
> > I honestly don't know whether the fact that I've haven't had any issues
> > with Meson and the libexecinfo library for months before the update was
> > due to the patch (or some package patch on the OpenBSD side), something
> > Meson did, or whether it was due to some fix in the project I'm trying
> > to build (the ksh93 shell from its GitHub repo) but that stopped working
> > with the updated Meson.
> > 
> > Regards,
> > Kusalananda
> 
> Does this help?
> https://github.com/mesonbuild/meson/pull/6226


Yes. Rebuilding Meson with the changes suggested in your PR resolves my
issue.

Regards,
Kusalananda

> 
> 
> 
> > > Index: patches/patch-mesonbuild_compilers_compilers_py
> > > ===
> > > RCS file: 
> > > /extra/cvs/ports/devel/meson/patches/patch-mesonbuild_compilers_compilers_py,v
> > > retrieving revision 1.12
> > > diff -u -p -r1.12 patch-mesonbuild_compilers_compilers_py
> > > --- patches/patch-mesonbuild_compilers_compilers_py   18 Apr 2019 
> > > 09:55:15 -  1.12
> > > +++ patches/patch-mesonbuild_compilers_compilers_py   29 May 2019 
> > > 16:36:18 -
> > > @@ -13,6 +13,15 @@ Subject: [PATCH] Fix indent to please co
> > >  Index: mesonbuild/compilers/compilers.py
> > >  --- mesonbuild/compilers/compilers.py.orig
> > >  +++ mesonbuild/compilers/compilers.py
> > > +@@ -82,7 +82,7 @@ cflags_mapping = {'c': 'CFLAGS',
> > > +   'rust': 'RUSTFLAGS'}
> > > + 
> > > + # execinfo is a compiler lib on BSD
> > > +-unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt', 
> > > 'execinfo')
> > > ++unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt')
> > > + 
> > > + # All these are only for C-linkable languages; see `clink_langs` above.
> > > + 
> > >  @@ -1491,7 +1491,9 @@ class GnuLikeCompiler(abc.ABC):
> > >   self.compiler_type = compiler_type
> > >   self.base_options = ['b_pch', 'b_lto', 'b_pgo', 'b_sanitize', 
> > > 'b_coverage',
> > 
> > 
> > -- 
> > Andreas (Kusalananda) Kähäri
> > SciLifeLab, NBIS, ICM
> > Uppsala University, Sweden
> 
> -- 
> Antoine

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden



Re: [patch] devel/meson: enable detection of libexecinfo

2019-11-16 Thread Andreas Kusalananda Kähäri
On Wed, May 29, 2019 at 06:49:29PM +0200, Kusalananda Kähäri wrote:
> Since Meson updated from 0.50.0 to 0.50.1, the libexecinfo library, if
> installed, is not properly detected with Meson's find_library().  The
> attached patch (modification of an existing patch file that we already
> have) fixes this for OpenBSD.
> 
> I have also opened an issue about this on the Meson Github pages.
> https://github.com/mesonbuild/meson/issues/5432
> 
> Regards,
> 
> -- 
> Kusalananda
> Sweden

I just noticed that the update to Meson 0.52.0 on the 8th of November
seems to have brought back the issue with the libexecinfo referred to
above.

I haven't written a new patch as I saw that
patch-mesonbuild_compilers_compilers_py had been delete from the port
some four months ago.

I honestly don't know whether the fact that I've haven't had any issues
with Meson and the libexecinfo library for months before the update was
due to the patch (or some package patch on the OpenBSD side), something
Meson did, or whether it was due to some fix in the project I'm trying
to build (the ksh93 shell from its GitHub repo) but that stopped working
with the updated Meson.

Regards,
Kusalananda

> Index: patches/patch-mesonbuild_compilers_compilers_py
> ===
> RCS file: 
> /extra/cvs/ports/devel/meson/patches/patch-mesonbuild_compilers_compilers_py,v
> retrieving revision 1.12
> diff -u -p -r1.12 patch-mesonbuild_compilers_compilers_py
> --- patches/patch-mesonbuild_compilers_compilers_py   18 Apr 2019 09:55:15 
> -  1.12
> +++ patches/patch-mesonbuild_compilers_compilers_py   29 May 2019 16:36:18 
> -
> @@ -13,6 +13,15 @@ Subject: [PATCH] Fix indent to please co
>  Index: mesonbuild/compilers/compilers.py
>  --- mesonbuild/compilers/compilers.py.orig
>  +++ mesonbuild/compilers/compilers.py
> +@@ -82,7 +82,7 @@ cflags_mapping = {'c': 'CFLAGS',
> +   'rust': 'RUSTFLAGS'}
> + 
> + # execinfo is a compiler lib on BSD
> +-unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt', 'execinfo')
> ++unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt')
> + 
> + # All these are only for C-linkable languages; see `clink_langs` above.
> + 
>  @@ -1491,7 +1491,9 @@ class GnuLikeCompiler(abc.ABC):
>   self.compiler_type = compiler_type
>   self.base_options = ['b_pch', 'b_lto', 'b_pgo', 'b_sanitize', 
> 'b_coverage',


-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden



Updated: sysutils/stow 2.3.0 --> 2.3.1

2019-08-21 Thread Andreas Kusalananda Kähäri
GNU Stow 2.3.1 was recently released.

The main difference is that the run-time dependencies on the Perl
modules Clone::Choose and Hash::Merge (introduced in release 2.3.0) were
dropped.

A diff of the port is attached.

Regards,
Andreas (maintainer)
Index: Makefile
===
RCS file: /extra/cvs/ports/sysutils/stow/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile24 Jul 2019 10:30:33 -  1.15
+++ Makefile21 Aug 2019 10:18:52 -
@@ -2,7 +2,7 @@
 
 COMMENT=   manages software package installations with symlinks
 
-DISTNAME=  stow-2.3.0
+DISTNAME=  stow-2.3.1
 CATEGORIES=sysutils
 
 HOMEPAGE=  https://www.gnu.org/software/stow/stow.html
@@ -16,10 +16,6 @@ MASTER_SITES=${MASTER_SITE_GNU:=stow/}
 
 CONFIGURE_STYLE=gnu
 USE_GMAKE=Yes
-
-RUN_DEPENDS=   devel/p5-Clone \
-   devel/p5-Clone-Choose \
-   devel/p5-Hash-Merge
 
 TEST_DEPENDS=  devel/p5-IO-stringy \
devel/p5-Test-Output
Index: distinfo
===
RCS file: /extra/cvs/ports/sysutils/stow/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo24 Jul 2019 10:30:33 -  1.7
+++ distinfo21 Aug 2019 10:13:17 -
@@ -1,2 +1,2 @@
-SHA256 (stow-2.3.0.tar.gz) = BSTqoNRIXRv/t4tc31tvwT45REZmyi5RM29m3bPIGEE=
-SIZE (stow-2.3.0.tar.gz) = 652135
+SHA256 (stow-2.3.1.tar.gz) = CdXZlnG3hTf9mywLOaXpdhp6Dpefb9t+q/pY7kXwPUs=
+SIZE (stow-2.3.1.tar.gz) = 654191


[Update] sysutils/stow 2.2.2 --> 2.3.0

2019-07-23 Thread Andreas Kusalananda Kähäri
GNU Stow 2.3.0 was released on the 29th of June 2019.

Patch is attached.

Regards,
Andreas (port maintainer)


Release announcement:
https://lists.gnu.org/archive/html/info-stow/2019-06/msg0.html

Summary:

1. New features / changes in behaviour
.. 1. New --dotfiles option
.. 2. Shell-like expansion in .stowrc files
.. 3. chkstow now honours the $STOW_DIR environment variable
.. 4. Stow now has a non-zero exit code if option parsing failed
2. License upgraded from GPL version 2 to version 3
3. Documentation fixes and enhancements
.. 1. Remove dependency on unmaintained texi2html
.. 2. Fixed naming of man page
.. 3. Convert README and INSTALL to Markdown
.. 4. Update documentation to reflect more modern use cases
.. 5. Miscellaneous documentation fixes
4. Fixes for bugs, tests, and other technical debt
.. 1. Add Docker files for convenient testing across multiple Perl versions
.. 2. Set up continuous testing via Travis CI
.. 3. Add Coveralls integration with GitHub
.. 4. Miscellaneous improvements to the test suite
.. 5. Fix for test suite on Cygwin
.. 6. aclocal.m4 was updated using aclocal 1.15.1.
.. 7. Miscellaneous fixes to the build and distribution process
.. 8. Improve handling of directories with unusual names
Index: Makefile
===
RCS file: /cvs/ports/sysutils/stow/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile12 Jul 2019 20:49:52 -  1.14
+++ Makefile23 Jul 2019 19:46:51 -
@@ -2,21 +2,24 @@
 
 COMMENT=   manages software package installations with symlinks
 
-DISTNAME=  stow-2.2.2
-REVISION=  0
+DISTNAME=  stow-2.3.0
 CATEGORIES=sysutils
 
 HOMEPAGE=  https://www.gnu.org/software/stow/stow.html
 
 MAINTAINER=Andreas Kusalananda Kahari 
 
-# GPLv2+
+# GPLv3+
 PERMIT_PACKAGE=Yes
 
 MASTER_SITES=  ${MASTER_SITE_GNU:=stow/}
 
 CONFIGURE_STYLE=gnu
 USE_GMAKE=Yes
+
+RUN_DEPENDS=   devel/p5-Clone \
+   devel/p5-Clone-Choose \
+   devel/p5-Hash-Merge
 
 TEST_DEPENDS=  devel/p5-IO-stringy \
devel/p5-Test-Output
Index: distinfo
===
RCS file: /cvs/ports/sysutils/stow/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo10 Nov 2015 09:13:50 -  1.6
+++ distinfo23 Jul 2019 19:46:51 -
@@ -1,2 +1,2 @@
-SHA256 (stow-2.2.2.tar.gz) = 4vd2STAbIVua28LwdFI77eutNmgSaQudyURXr1zyc98=
-SIZE (stow-2.2.2.tar.gz) = 579324
+SHA256 (stow-2.3.0.tar.gz) = BSTqoNRIXRv/t4tc31tvwT45REZmyi5RM29m3bPIGEE=
+SIZE (stow-2.3.0.tar.gz) = 652135
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/stow/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST   7 May 2015 11:27:59 -   1.4
+++ pkg/PLIST   23 Jul 2019 19:46:51 -
@@ -9,7 +9,8 @@ libdata/perl5/site_perl/Stow/Util.pm
 share/doc/stow/
 share/doc/stow/ChangeLog
 share/doc/stow/ChangeLog.OLD
-share/doc/stow/README
+share/doc/stow/INSTALL.md
+share/doc/stow/README.md
 share/doc/stow/manual-single.html
 share/doc/stow/manual-split/
 share/doc/stow/manual-split/Bootstrapping.html


Re: devel/c2hs and audio/p5-CDDB_Get dangling ports

2019-06-03 Thread Andreas Kusalananda Kähäri
On Mon, Jun 03, 2019 at 12:41:49PM +0200, Matthias Kilian wrote:
> Hi,
> 
> On Mon, Jun 03, 2019 at 11:41:56AM +0200, Andreas Kusalananda Kähäri wrote:
> > The devel/c2hs port was removed in January 2016 ("Broken and not
> > used by anything."), but its directory is still there when checking
> > out the ports repository from CVS.  This is due to a patch file
> > ("patches/patch-doc_man1_c2hs_1") which was never properly deleted.
> 
> Removed now. THanks for noticing.
> 
> > Likewise, the audio/p5-CDDB_Get port (capital "G") is lingering due to
> > non-deleted files (since 2001).
> 
> This one is completely in the attic (i.e. all files properly cvs
> rm'ed). Do you have some additional files in your tree? What doas
> 
>   cvs -q up -dP
> 
> say?
> 
> Ciao,
>   Kili

Hmm... The audio/p5-CDDB_Get port is still there even if I ask cvs to
prune empty directories while updating, but deleting its directory and
doing "cvs up -dP" in the port/audio directory does not make it come
back.

Odd.  A filename case issue in cvs?  There is a valid audio/p5-CDDB_get
port whose name only differs in case.



-- 
Kusalananda
Sweden



devel/c2hs and audio/p5-CDDB_Get dangling ports

2019-06-03 Thread Andreas Kusalananda Kähäri
The devel/c2hs port was removed in January 2016 ("Broken and not
used by anything."), but its directory is still there when checking
out the ports repository from CVS.  This is due to a patch file
("patches/patch-doc_man1_c2hs_1") which was never properly deleted.

Likewise, the audio/p5-CDDB_Get port (capital "G") is lingering due to
non-deleted files (since 2001).


Apologies if this is due to some quirk in my current checkout, but I
*believe* that what I'm seeing is real.


Cheers,

-- 
Kusalananda
Sweden



[patch] devel/meson: enable detection of libexecinfo

2019-05-29 Thread Andreas Kusalananda Kähäri
Since Meson updated from 0.50.0 to 0.50.1, the libexecinfo library, if
installed, is not properly detected with Meson's find_library().  The
attached patch (modification of an existing patch file that we already
have) fixes this for OpenBSD.

I have also opened an issue about this on the Meson Github pages.
https://github.com/mesonbuild/meson/issues/5432

Regards,

-- 
Kusalananda
Sweden
Index: patches/patch-mesonbuild_compilers_compilers_py
===
RCS file: 
/extra/cvs/ports/devel/meson/patches/patch-mesonbuild_compilers_compilers_py,v
retrieving revision 1.12
diff -u -p -r1.12 patch-mesonbuild_compilers_compilers_py
--- patches/patch-mesonbuild_compilers_compilers_py 18 Apr 2019 09:55:15 
-  1.12
+++ patches/patch-mesonbuild_compilers_compilers_py 29 May 2019 16:36:18 
-
@@ -13,6 +13,15 @@ Subject: [PATCH] Fix indent to please co
 Index: mesonbuild/compilers/compilers.py
 --- mesonbuild/compilers/compilers.py.orig
 +++ mesonbuild/compilers/compilers.py
+@@ -82,7 +82,7 @@ cflags_mapping = {'c': 'CFLAGS',
+   'rust': 'RUSTFLAGS'}
+ 
+ # execinfo is a compiler lib on BSD
+-unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt', 'execinfo')
++unixy_compiler_internal_libs = ('m', 'c', 'pthread', 'dl', 'rt')
+ 
+ # All these are only for C-linkable languages; see `clink_langs` above.
+ 
 @@ -1491,7 +1491,9 @@ class GnuLikeCompiler(abc.ABC):
  self.compiler_type = compiler_type
  self.base_options = ['b_pch', 'b_lto', 'b_pgo', 'b_sanitize', 
'b_coverage',


Re: Missing file and Man page for out-of-date

2019-05-25 Thread Andreas Kusalananda Kähäri
On Sat, May 25, 2019 at 05:16:19PM -0400, Michael Alaimo wrote:
> The /usr/ports/infrastructure/bin/out-of-date program is missing.
> 
> I remember it being in OpenBSD 6.3.
> 
> It is still referenced in /usr/ports/infrastructure/README in OpenBSD 6.5.
> 
> It is listed with description:
> bin/out-of-date
> Compare installed registered packages with INDEX, try to find out
> of date ports.
> 
> Is it possible to get the script back into ports for OpenBSD 6.5?
> 
> Does anyone know what happened with it?
> 
> Regards,
> 
> Michael
> 
> http://quantum-foam.org/

On 2018/07/09 11:17:33 it was renamed "pkg_outdated" (same location as
before).

https://marc.info/?l=openbsd-ports-cvs=153115666203853=2

-- 
Kusalananda
Sweden



Issues running dpb(1) (with patch)

2019-05-09 Thread Andreas Kusalananda Kähäri
Hi,

I'm using dpb(1) with proot and a local NFS mount of /usr/ports to
keep my installed ports up to date.  Since yesterday, dpb(1) fails to
properly start with the following error:

Reading size stats...zapping old stuff...Done
Reading build stats...zapping old stuff...Done
Can't locate object method "name" via package "localhost" (perhaps you forgot 
to load "localhost"?) at /usr/ports/infrastructure/lib/DPB/Core.pm line 147.
DPB::Core::Abstract::hostname(DPB::Core=HASH(0xb4e55b5ee38)) called at 
/usr/ports/infrastructure/lib/DPB/Core.pm line 97
DPB::Core::Abstract::new(DPB::Core, localhost) called at 
/usr/ports/infrastructure/lib/DPB/Core.pm line 741
DPB::Core::new_noreg(DPB::Core, localhost) called at 
/usr/ports/infrastructure/lib/DPB/PortBuilder/Rebuild.pm line 33
DPB::PortBuilder::Rebuild::init(DPB::PortBuilder::Rebuild=HASH(0xb4e07d80838)) 
called at /usr/ports/infrastructure/lib/DPB/PortBuilder.pm line 55
DPB::PortBuilder::new(DPB::PortBuilder, DPB::State=HASH(0xb4dce0855c8)) called 
at /usr/ports/infrastructure/bin/dpb line 149


I saw the two "unbreak" CVS commits from Marc against
infrastructure/lib/DPB/Core.pm, but these don't seem to have actually
fixed the above issue.

Looking at the code, it seems that DPB::PortBuilder::Rebuild::init()
needs to modify its call to DPB::Core::new_noreg() slightly:


Index: PortBuilder/Rebuild.pm
===
RCS file: /extra/cvs/ports/infrastructure/lib/DPB/PortBuilder/Rebuild.pm,v
retrieving revision 1.4
diff -u -p -r1.4 Rebuild.pm
--- PortBuilder/Rebuild.pm  27 Jun 2018 07:07:57 -  1.4
+++ PortBuilder/Rebuild.pm  9 May 2019 07:27:34 -
@@ -20,6 +20,8 @@ use warnings;
 package DPB::PortBuilder::Rebuild;
 our @ISA = qw(DPB::PortBuilder);

+use DPB::Host;
+
 sub init
 {
my $self = shift;
@@ -30,7 +32,7 @@ sub init
"file:/$self->{fullrepo}", $self->{state});
$self->{repository}{trusted} = 1;
# this is just a dummy core, for running quick pipes
-   $self->{core} = DPB::Core->new_noreg('localhost');
+   $self->{core} = DPB::Core->new_noreg(DPB::Host->new('localhost'));
 }

 my $uptodate = {};


-- 
Kusalananda
Sweden



Re: UPDATE: security/sshguard 1.5 --> 2.3.0

2019-05-05 Thread Andreas Kusalananda Kähäri
On Sun, May 05, 2019 at 02:25:37AM -0700, Corsaire01 wrote:
> Hello everyone.
> 
> I found out that /etc/sshguard.conf is completely ignored, it is just on my
> system ?
> I got triggered when the machines in my own network got banned although I
> did enable the WHITELIST_FILE option.
> 
> furthermore, default options in the file and default options after starting
> the daemon are different
> 
> /etc/sshguard.conf
>  OPTIONS 
> # Block attackers when their cumulative attack score exceeds THRESHOLD.
> # Most attacks have a score of 10. (optional, default 30)
> THRESHOLD=30
> 
> # Block attackers for initially BLOCK_TIME seconds after exceeding
> THRESHOLD.
> # Subsequent blocks increase by a factor of 1.5. (optional, default 120)
> BLOCK_TIME=120
> 
> # IP addresses listed in the WHITELIST_FILE are considered to be
> # friendlies and will never be blocked.
> WHITELIST_FILE=/etc/friends
> 
> 
> # /etc/rc.d/sshguard start
> # ps auwxx | grep sshguard
> root 40901  0.0  0.2   844   836 C0  Ip 6:01PM0:00.00 /bin/sh
> /usr/local/sbin/sshguard -a 10 -l /var/log/authlog -p 14400 -w
> /var/db/sshguard/whitelist.db
> root 83350  0.0  0.1   844   652 C0  Ip 6:01PM0:00.00 /bin/sh
> /usr/local/sbin/sshguard -a 10 -l /var/log/authlog -p 14400 -w
> /var/db/sshguard/whitelist.db
> root 68041  0.0  0.3  1144  1580 C0  Ip 6:01PM0:00.02
> /usr/local/libexec/sshg-blocker -a 10 -p 14400 -s 1800 -N 128 -n 32 -w
> /var/db/sshguard/whitelist.db
> root 65827  0.0  0.1   844   584 C0  Ip 6:01PM0:00.01 /bin/sh
> /usr/local/sbin/sshguard -a 10 -l /var/log/authlog -p 14400 -w
> /var/db/sshguard/whitelist.db
> 
> 
> At this point I would see to add options in /etc/rc.d/sshguard in the line
> daemon="/usr/local/sbin/sshguard"

Is that what you have done now (above) because I can't really see a
default installation of sshguard pass _any_ command line options to the
/usr/local/sbin/sshguard script.

It could be that you had an old "sshguard_flags" setting in
/etc/rc.conf.local" maybe?  This should no longer be needed and all
configuration can be done in /etc/sshguard.conf.

> but is this recommendable... config files are supposed to be in /etc for a
> reason.
> 
> btw, you can put your whitelist in /var/db/sshguard/whitelist.db as
> advertised by the ps

I've just tested installing sshguard freshly, and it _definitely_ picks
up the WHITELIST_FILE from /etc/sshguard.conf


> 
> OpenBSD 6.5 with 'pkg_add sshguard' here
> 
> 
> 
> --
> Sent from: 
> http://openbsd-archive.7691.n7.nabble.com/openbsd-user-ports-f108501.html

Regards,

-- 
Kusalananda
Sweden



Re: Ports tree locked for 6.5 release

2019-04-05 Thread Andreas Kusalananda Kähäri
On Fri, Apr 05, 2019 at 06:44:36AM -0500, Edward Lopez-Acosta wrote:
> Could you please explain the logic behind this as I am confused. Is this due
> to an inefficient process, technical limitation, or other reason (lack of
> manpower doesn't qualify as that seems self inflicted by the project)? Are
> you somehow tracking submissions to take care of when this unlocked so
> people don't waste their time needing to resubmit them?
> 
> While they may exist I know of no other project, including OS, that halt
> development like this for long, if at all, to do a release. Again, they may
> exist I just don't know of any and find the process awkward and confusing.

NetBSD freezes its pkgsrc tree before each of their quarterly releases.
FreeBSD used to have the same practice for their ports.

Debian Linux enters a period of freeze before a release.  As does
Ubuntu.  Fedora has three stages of "milestone freezing".

This is not an uncommon thing.

See also: https://en.wikipedia.org/wiki/Freeze_(software_engineering)

Cheers,

> 
> > Date: Thu, 4 Apr 2019 15:58:06 +0200
> > From: Christian Weisgerber 
> > To: ports@openbsd.org
> > Subject: Ports tree locked for 6.5 release
> > Message-ID: <20190404135806.gb29...@lorvorc.mips.inka.de>
> > 
> > The t2k19 hackathon has concluded and the ports tree is now locked
> > for the 6.5 release.  Important(!) fixes are still possible for a
> > brief period.  Committers need to ask sthen@ or me for approval.
> > 
> > -- 
> > Christian "naddy" Weisgerber  na...@mips.inka.de
> 
> 
> -- 
> Edward Lopez-Acosta

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: [UPDATE]: security/sshguard -> 2.3.1

2019-03-16 Thread Andreas Kusalananda Kähäri
On Sun, Mar 10, 2019 at 06:50:43PM +0100, Andreas Kusalananda Kähäri wrote:
> On Sun, Mar 10, 2019 at 10:50:19AM +0100, Markus Lude wrote:
> > On Sat, Jan 26, 2019 at 03:43:17PM +0100, Andreas Kusalananda Khri wrote:
> > > Hi,
> > 
> > Hello,
> > 
> > > You will find a patch for security/sshguard attached, bringing sshguard
> > > up to the newly released 2.3.1 (2019-01-01).
> > > 
> > > As with the previous updates I've posted, this is a patch against
> > > sshguard 1.5 which we have in the ports tree, and it also adds me as the
> > > maintainer.
> > > 
> > > The difference between 2.3.1 and the previous 2.3.0 release is minor,
> > > but I updated the patch because there was a commit fixing the handling
> > > of OpenSSH's "Did not receive identification string" message.
> > > 
> > > The differences between 2.3.1 and the 1.5 release are too numerous to
> > > list here, but see [1].
> > > 
> > > [1]
> > > https://bitbucket.org/sshguard/sshguard/src/master/CHANGELOG.rst?fileviewer=file-view-default
> > 
> > Thanks for the update. sshguard is running fine now after reboots.
> > 
> > Running on amd64 with latest snapshot.
> 
> Good.  Yes, I've been running this too since I posted the patch in
> January.  No issues.  I'm attaching the patch again here just in case...
> 
> Regards,
> 
> -- 
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.

Hmm... My message, sent almost a week ago, never reached the list.
Re-posting sshguard patch again.

Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile4 Sep 2018 12:46:21 -   1.13
+++ Makefile26 Jan 2019 12:21:48 -
@@ -2,22 +2,29 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  6
+DISTNAME=  sshguard-2.3.1
 CATEGORIES=security
 
+HOMEPAGE=  https://www.sshguard.net/
+
+MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
+
+MAINTAINER=Andreas Kusalananda Kahari 
+
 # BSD
 PERMIT_PACKAGE_CDROM=  Yes
 
 WANTLIB+=  c pthread
 
-HOMEPAGE=  https://www.sshguard.net/
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
-
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--with-firewall=pf
 
-NO_TEST=   Yes
+post-patch:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8 \
+   ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/*.{example,sample} \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /extra/cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo26 Jan 2019 12:27:45 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.3.1.tar.gz) = dpBV4m33j0vKNMmnrPJl36IkwFWzPO1H9T1Vv2WdIKI=
+SIZE (sshguard-2.3.1.tar.gz) = 765330
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 24 Jun 2018 10:54:19 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-configure,v 1.1 2018/06/24 10:54:19 kn Exp $
-
-Index: configure
 configure.orig
-+++ configure
-@@ -5949,7 +5949,6 @@ then
- STD99_CFLAGS="-xc99"
- else
- # other compiler (assume gcc-compatibile :( )
--OPTIMIZER_CFLAGS="-O2"
- WARNING_CFLAGS="-Wall"
- STD99_CFLAGS="-std=c99"
- fi
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_84 Dec 2018 21:52:04 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,8 +119,8 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
+-See sample configuration file.
++.B ${SYSCONFDIR}/sshguard.conf
++See sample configuration file in 
${PREFIX}/share/examples/sshguard/sshguard.conf.sample

Re: CVS: cvs.openbsd.org: ports

2019-02-20 Thread Andreas Kusalananda Kähäri
On Tue, Feb 19, 2019 at 10:57:05AM -0700, Stuart Henderson wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   st...@cvs.openbsd.org   2019/02/19 10:57:04
> 
> Modified files:
>   graphics/giflib: Makefile distinfo 
>   graphics/giflib/patches: patch-tests_makefile 
>   graphics/giflib/pkg: PLIST 
> Added files:
>   graphics/giflib/patches: patch-Makefile 
> 
> Log message:
> update to giflib-5.1.6


There are two BUILD_DEPENDS= lines in the Makefile.  The second
overwrites the first, which removes the dependency on archivers/gtar,
which in turn breaks the build if gtar is not already installed.


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: sysutils/coreutils problem

2019-02-06 Thread Andreas Kusalananda Kähäri
On Wed, Feb 06, 2019 at 07:57:33PM +0900, 岡本健二 wrote:
> I'm facing another problem at /usr/ports/sysutils/coreutils:
> 
> make install ended eroor, which says:
> 
> ...
> checking whether mknod can create fifo...  without root privileges...
> configure: error: you should not run configure as root
> (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this work)
> 
> Yes, I'm running make as root to install the program.
> Ok, export FORCE_UNSAFE_CONFIGUE=1, and then make distclean, and then
> make install again.
> However, this error comes again.
> 
> What's going on here?
> 
> Kenji

Check your spelling of the word "CONFIGURE".


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



[UPDATE]: shells/yash 2.44 (2017-01-17) -> 2.48 (2018-12-22)

2019-01-28 Thread Andreas Kusalananda Kähäri

Hi,

You'll find a patch for an update to the shells/yash port attached.  It
brings the shell up to version 2.48, which was released last month.
I was trying to debug something in the shell and needed the latest
release, which is why I'm sending this.

I regenerated the single patch (BTW, there's an earlier srand()
call in the same file, but maybe this should not be changed to
srand_deterministic()?) as the lines are slightly offset now.


Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /extra/cvs/ports/shells/yash/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile24 Feb 2017 21:23:38 -  1.5
+++ Makefile28 Jan 2019 16:26:06 -
@@ -2,9 +2,8 @@
 
 COMMENT=   POSIX-compliant command line shell
 
-DISTNAME=  yash-2.44
-RELEASE=   66984
-REVISION=  0
+DISTNAME=  yash-2.48
+RELEASE=   70439
 CATEGORIES=shells
 HOMEPAGE=  https://yash.osdn.jp/index.html.en
 
Index: distinfo
===
RCS file: /extra/cvs/ports/shells/yash/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo18 Jan 2017 23:10:42 -  1.2
+++ distinfo28 Jan 2019 16:26:34 -
@@ -1,2 +1,2 @@
-SHA256 (yash-2.44.tar.xz) = 8TUrSRlaOHkoTjq2CvSzDTqH1pbIOLJG4gaMy9/PLmY=
-SIZE (yash-2.44.tar.xz) = 712272
+SHA256 (yash-2.48.tar.xz) = 9GKU13xaZGQF2yCm3D0WvB7RCbBhsqUICBzkgxU8Ho0=
+SIZE (yash-2.48.tar.xz) = 736280
Index: patches/patch-variable_c
===
RCS file: /extra/cvs/ports/shells/yash/patches/patch-variable_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-variable_c
--- patches/patch-variable_c18 Jan 2017 23:10:42 -  1.2
+++ patches/patch-variable_c28 Jan 2019 16:29:49 -
@@ -1,11 +1,13 @@
 $OpenBSD: patch-variable_c,v 1.2 2017/01/18 23:10:42 naddy Exp $
 variable.c.origMon Jan 16 14:01:12 2017
-+++ variable.c Wed Jan 18 23:59:15 2017
-@@ -1094,7 +1094,7 @@ void variable_set(const wchar_t *name, variable_T *var
+Index: variable.c
+--- variable.c.orig
 variable.c
+@@ -1096,7 +1096,8 @@ void variable_set(const wchar_t *name, variable_T *var
&& var->v_value != NULL) {
unsigned long seed;
if (xwcstoul(var->v_value, 0, )) {
 -  srand((unsigned) seed);
++  /* srand((unsigned) seed); */
 +  srand_deterministic((unsigned) seed);
var->v_getter = random_getter;
random_active = true;
Index: pkg/PLIST
===
RCS file: /extra/cvs/ports/shells/yash/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST   24 Feb 2017 21:23:38 -  1.3
+++ pkg/PLIST   28 Jan 2019 16:33:22 -
@@ -4,8 +4,15 @@ man/ja/
 man/ja/man1/
 @man man/ja/man1/yash.1
 @man man/man1/yash.1
+share/locale/
+share/locale/en@boldquot/
+share/locale/en@boldquot/LC_MESSAGES/
 share/locale/en@boldquot/LC_MESSAGES/yash.mo
+share/locale/en@quot/
+share/locale/en@quot/LC_MESSAGES/
 share/locale/en@quot/LC_MESSAGES/yash.mo
+share/locale/ja/
+share/locale/ja/LC_MESSAGES/
 share/locale/ja/LC_MESSAGES/yash.mo
 share/yash/
 share/yash/completion/
@@ -139,6 +146,7 @@ share/yash/completion/kill
 share/yash/completion/ksh
 share/yash/completion/less
 share/yash/completion/ln
+share/yash/completion/local
 share/yash/completion/locale
 share/yash/completion/ls
 share/yash/completion/make
@@ -160,6 +168,7 @@ share/yash/completion/paste
 share/yash/completion/patch
 share/yash/completion/pathchk
 share/yash/completion/pgawk
+share/yash/completion/ping
 share/yash/completion/popd
 share/yash/completion/pr
 share/yash/completion/printf


[UPDATE]: security/sshguard -> 2.3.1

2019-01-26 Thread Andreas Kusalananda Kähäri
Hi,

You will find a patch for security/sshguard attached, bringing sshguard
up to the newly released 2.3.1 (2019-01-01).

As with the previous updates I've posted, this is a patch against
sshguard 1.5 which we have in the ports tree, and it also adds me as the
maintainer.

The difference between 2.3.1 and the previous 2.3.0 release is minor,
but I updated the patch because there was a commit fixing the handling
of OpenSSH's "Did not receive identification string" message.

The differences between 2.3.1 and the 1.5 release are too numerous to
list here, but see [1].

[1]
https://bitbucket.org/sshguard/sshguard/src/master/CHANGELOG.rst?fileviewer=file-view-default


Regards,
Andreas

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile4 Sep 2018 12:46:21 -   1.13
+++ Makefile26 Jan 2019 12:21:48 -
@@ -2,22 +2,29 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  6
+DISTNAME=  sshguard-2.3.1
 CATEGORIES=security
 
+HOMEPAGE=  https://www.sshguard.net/
+
+MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
+
+MAINTAINER=Andreas Kusalananda Kahari 
+
 # BSD
 PERMIT_PACKAGE_CDROM=  Yes
 
 WANTLIB+=  c pthread
 
-HOMEPAGE=  https://www.sshguard.net/
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
-
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--with-firewall=pf
 
-NO_TEST=   Yes
+post-patch:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8 \
+   ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/*.{example,sample} \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /extra/cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo26 Jan 2019 12:27:45 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.3.1.tar.gz) = dpBV4m33j0vKNMmnrPJl36IkwFWzPO1H9T1Vv2WdIKI=
+SIZE (sshguard-2.3.1.tar.gz) = 765330
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 24 Jun 2018 10:54:19 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-configure,v 1.1 2018/06/24 10:54:19 kn Exp $
-
-Index: configure
 configure.orig
-+++ configure
-@@ -5949,7 +5949,6 @@ then
- STD99_CFLAGS="-xc99"
- else
- # other compiler (assume gcc-compatibile :( )
--OPTIMIZER_CFLAGS="-O2"
- WARNING_CFLAGS="-Wall"
- STD99_CFLAGS="-std=c99"
- fi
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_84 Dec 2018 21:52:04 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,8 +119,8 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
+-See sample configuration file.
++.B ${SYSCONFDIR}/sshguard.conf
++See sample configuration file in 
${PREFIX}/share/examples/sshguard/sshguard.conf.sample
+ .UNINDENT
+ .SH WHITELISTING
+ .sp
Index: patches/patch-examples_sshguard_conf_sample
===
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-examples_sshguard_conf_sample 4 Dec 2018 16:14:34 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
 examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+  REQUIRED CONFIGURATION 
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/sshg-fw-pf"
+ 
+ # Space-separated list of log files to monitor. (optional, no default)
+ #FILES="/var/log/auth.log /var/log/authlog /var/log/maillog"
++FILES=/var/log/authlog
+ 
+ # Shell command that provides logs on standard output. (optional, no default)
+ # Example 1: s

Re: [FIX] devel/openmpi: Make main API symbols non-local (Re: devel/openmpi Can't link example program, symbols local in libmpi.so.0.1?)

2019-01-21 Thread Andreas Kusalananda Kähäri

Ping on this.  It makes the _ancient_ version of OpenMPI that we have
usable.  Currently, the API's symbols are not exported in the library, so
the port is virtually unusable.  This simple patch fixes that.

Cheers,
Andreas

On Mon, Jan 14, 2019 at 10:52:43AM +0100, Andreas Kusalananda Kähäri wrote:
> On Mon, Jan 14, 2019 at 07:38:34AM +0100, Andreas Kusalananda Kähäri wrote:
> > On Sun, Jan 13, 2019 at 04:37:23PM +0100, Thomas L. wrote:
> > > Hi,
> > > 
> > > I tried compiling a MPI example program 
> > > (https://raw.githubusercontent.com/wesleykendall/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c)
> > >  with openmpi on -current and it fails linking:
> > > $ mpicc -v Downloads/mpi_hello_world.c 
> > > OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
> > > Target: amd64-unknown-openbsd6.4
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> > >  "/usr/bin/cc" -cc1 -triple amd64-unknown-openbsd6.4 -emit-obj 
> > > -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names 
> > > -main-file-name mpi_hello_world.c -mrelocation-model pic -pic-level 1 
> > > -pic-is-pie -mthread-model posix -mdisable-fp-elim -relaxed-aliasing 
> > > -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 
> > > -dwarf-column-info -debugger-tuning=gdb -v -resource-dir 
> > > /usr/lib/clang/6.0.0 -I /usr/local/include -fdebug-compilation-dir 
> > > /home/tom -ferror-limit 19 -fmessage-length 224 -femulated-tls -fwrapv 
> > > -pthread -stack-protector 2 -D_RET_PROTECTOR -ret-protector 
> > > -fobjc-runtime=gnustep -fdiagnostics-show-option -fno-builtin-malloc 
> > > -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-valloc 
> > > -fno-builtin-free -fno-builtin-strdup -fno-builtin-strndup -o 
> > > /tmp/mpi_hello_world-a9e376.o -x c Downloads/mpi_hello_world.c
> > > clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target 
> > > amd64-unknown-openbsd6.4
> > > #include "..." search starts here:
> > > #include <...> search starts here:
> > >  /usr/local/include
> > >  /usr/lib/clang/6.0.0/include
> > >  /usr/include
> > > End of search list.
> > >  "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker 
> > > /usr/libexec/ld.so -o a.out /usr/bin/../lib/crt0.o 
> > > /usr/bin/../lib/crtbegin.o -L/usr/local/lib -L/usr/bin/../lib -L/usr/lib 
> > > /tmp/mpi_hello_world-a9e376.o -lmpi -lopen-rte -lopen-pal -E -lutil -lm 
> > > -lcompiler_rt -lpthread -lc -lcompiler_rt /usr/bin/../lib/crtend.o
> > > /usr/bin/ld: error: undefined symbol: MPI_Init
> > > >>> referenced by mpi_hello_world.c
> > > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > > 
> > > /usr/bin/ld: error: undefined symbol: MPI_Comm_size
> > > >>> referenced by mpi_hello_world.c
> > > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > > 
> > > /usr/bin/ld: error: undefined symbol: MPI_Comm_rank
> > > >>> referenced by mpi_hello_world.c
> > > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > > 
> > > /usr/bin/ld: error: undefined symbol: MPI_Get_processor_name
> > > >>> referenced by mpi_hello_world.c
> > > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > > 
> > > /usr/bin/ld: error: undefined symbol: MPI_Finalize
> > > >>> referenced by mpi_hello_world.c
> > > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > > cc: error: linker command failed with exit code 1 (use -v to see 
> > > invocation)
> > > 
> > > The reason seems to be, that the relevant symbols in libmpi.so.0.1 are 
> > > local:
> > > $ nm /usr/local/lib/libmpi.so.0.1  | grep MPI_Init
> > > 00070330 t MPI_Init
> > > 000704f0 t MPI_Init_thread
> > > 000706b0 t MPI_Initialized
> > > 00070330 T PMPI_Init
> > > 000704f0 T PMPI_Init_thread
> > > 000706b0 T PMPI_Initialized
> > > 
> > > Unfortunately, I have no idea why this happens.
> > > 
> > > Kind regards,
> > > 
> > > Thomas
> > 
> > Yes, I also noticed this in June last year [1].  Only the profiling
> > version of each API function is non-local.  Unfortunately, I was in a
> > hurry to get something working so I simply moved my development and
> > testing to another operating system r

[FIX] devel/openmpi: Make main API symbols non-local (Re: devel/openmpi Can't link example program, symbols local in libmpi.so.0.1?)

2019-01-14 Thread Andreas Kusalananda Kähäri
On Mon, Jan 14, 2019 at 07:38:34AM +0100, Andreas Kusalananda Kähäri wrote:
> On Sun, Jan 13, 2019 at 04:37:23PM +0100, Thomas L. wrote:
> > Hi,
> > 
> > I tried compiling a MPI example program 
> > (https://raw.githubusercontent.com/wesleykendall/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c)
> >  with openmpi on -current and it fails linking:
> > $ mpicc -v Downloads/mpi_hello_world.c 
> > OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
> > Target: amd64-unknown-openbsd6.4
> > Thread model: posix
> > InstalledDir: /usr/bin
> >  "/usr/bin/cc" -cc1 -triple amd64-unknown-openbsd6.4 -emit-obj -mrelax-all 
> > -disable-free -disable-llvm-verifier -discard-value-names -main-file-name 
> > mpi_hello_world.c -mrelocation-model pic -pic-level 1 -pic-is-pie 
> > -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -masm-verbose 
> > -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info 
> > -debugger-tuning=gdb -v -resource-dir /usr/lib/clang/6.0.0 -I 
> > /usr/local/include -fdebug-compilation-dir /home/tom -ferror-limit 19 
> > -fmessage-length 224 -femulated-tls -fwrapv -pthread -stack-protector 2 
> > -D_RET_PROTECTOR -ret-protector -fobjc-runtime=gnustep 
> > -fdiagnostics-show-option -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-valloc -fno-builtin-free 
> > -fno-builtin-strdup -fno-builtin-strndup -o /tmp/mpi_hello_world-a9e376.o 
> > -x c Downloads/mpi_hello_world.c
> > clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target 
> > amd64-unknown-openbsd6.4
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/local/include
> >  /usr/lib/clang/6.0.0/include
> >  /usr/include
> > End of search list.
> >  "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker 
> > /usr/libexec/ld.so -o a.out /usr/bin/../lib/crt0.o 
> > /usr/bin/../lib/crtbegin.o -L/usr/local/lib -L/usr/bin/../lib -L/usr/lib 
> > /tmp/mpi_hello_world-a9e376.o -lmpi -lopen-rte -lopen-pal -E -lutil -lm 
> > -lcompiler_rt -lpthread -lc -lcompiler_rt /usr/bin/../lib/crtend.o
> > /usr/bin/ld: error: undefined symbol: MPI_Init
> > >>> referenced by mpi_hello_world.c
> > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > 
> > /usr/bin/ld: error: undefined symbol: MPI_Comm_size
> > >>> referenced by mpi_hello_world.c
> > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > 
> > /usr/bin/ld: error: undefined symbol: MPI_Comm_rank
> > >>> referenced by mpi_hello_world.c
> > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > 
> > /usr/bin/ld: error: undefined symbol: MPI_Get_processor_name
> > >>> referenced by mpi_hello_world.c
> > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > 
> > /usr/bin/ld: error: undefined symbol: MPI_Finalize
> > >>> referenced by mpi_hello_world.c
> > >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> > cc: error: linker command failed with exit code 1 (use -v to see invocation)
> > 
> > The reason seems to be, that the relevant symbols in libmpi.so.0.1 are 
> > local:
> > $ nm /usr/local/lib/libmpi.so.0.1  | grep MPI_Init
> > 00070330 t MPI_Init
> > 000704f0 t MPI_Init_thread
> > 000706b0 t MPI_Initialized
> > 00070330 T PMPI_Init
> > 000704f0 T PMPI_Init_thread
> > 000706b0 T PMPI_Initialized
> > 
> > Unfortunately, I have no idea why this happens.
> > 
> > Kind regards,
> > 
> > Thomas
> 
> Yes, I also noticed this in June last year [1].  Only the profiling
> version of each API function is non-local.  Unfortunately, I was in a
> hurry to get something working so I simply moved my development and
> testing to another operating system rather than digging into why this
> was so.  I might try to look into this later if time permits.
> 
> [1] https://marc.info/?l=openbsd-ports=152929789302360=2
> 
> 
> Regards,
> 
> -- 
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.


Ok, so it seems OpenMPI has to be configured with --disable-visibility.
This would make the symbols show up as "W" ("weak") instead of as local.
A simple test program compiles.

A patch for the devel/openmpi port is attached, although the port we
have is marked as "ancient" on the OpenMPI web pages [1], and the latest
release is 4.0.0.

[1]

Re: devel/openmpi Can't link example program, symbols local in libmpi.so.0.1?

2019-01-13 Thread Andreas Kusalananda Kähäri
On Sun, Jan 13, 2019 at 04:37:23PM +0100, Thomas L. wrote:
> Hi,
> 
> I tried compiling a MPI example program 
> (https://raw.githubusercontent.com/wesleykendall/mpitutorial/gh-pages/tutorials/mpi-hello-world/code/mpi_hello_world.c)
>  with openmpi on -current and it fails linking:
> $ mpicc -v Downloads/mpi_hello_world.c 
> OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
> Target: amd64-unknown-openbsd6.4
> Thread model: posix
> InstalledDir: /usr/bin
>  "/usr/bin/cc" -cc1 -triple amd64-unknown-openbsd6.4 -emit-obj -mrelax-all 
> -disable-free -disable-llvm-verifier -discard-value-names -main-file-name 
> mpi_hello_world.c -mrelocation-model pic -pic-level 1 -pic-is-pie 
> -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -masm-verbose 
> -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info 
> -debugger-tuning=gdb -v -resource-dir /usr/lib/clang/6.0.0 -I 
> /usr/local/include -fdebug-compilation-dir /home/tom -ferror-limit 19 
> -fmessage-length 224 -femulated-tls -fwrapv -pthread -stack-protector 2 
> -D_RET_PROTECTOR -ret-protector -fobjc-runtime=gnustep 
> -fdiagnostics-show-option -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-valloc -fno-builtin-free 
> -fno-builtin-strdup -fno-builtin-strndup -o /tmp/mpi_hello_world-a9e376.o -x 
> c Downloads/mpi_hello_world.c
> clang -cc1 version 6.0.0 based upon LLVM 6.0.0 default target 
> amd64-unknown-openbsd6.4
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/lib/clang/6.0.0/include
>  /usr/include
> End of search list.
>  "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker 
> /usr/libexec/ld.so -o a.out /usr/bin/../lib/crt0.o /usr/bin/../lib/crtbegin.o 
> -L/usr/local/lib -L/usr/bin/../lib -L/usr/lib /tmp/mpi_hello_world-a9e376.o 
> -lmpi -lopen-rte -lopen-pal -E -lutil -lm -lcompiler_rt -lpthread -lc 
> -lcompiler_rt /usr/bin/../lib/crtend.o
> /usr/bin/ld: error: undefined symbol: MPI_Init
> >>> referenced by mpi_hello_world.c
> >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> 
> /usr/bin/ld: error: undefined symbol: MPI_Comm_size
> >>> referenced by mpi_hello_world.c
> >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> 
> /usr/bin/ld: error: undefined symbol: MPI_Comm_rank
> >>> referenced by mpi_hello_world.c
> >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> 
> /usr/bin/ld: error: undefined symbol: MPI_Get_processor_name
> >>> referenced by mpi_hello_world.c
> >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> 
> /usr/bin/ld: error: undefined symbol: MPI_Finalize
> >>> referenced by mpi_hello_world.c
> >>>   /tmp/mpi_hello_world-a9e376.o:(main)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> The reason seems to be, that the relevant symbols in libmpi.so.0.1 are local:
> $ nm /usr/local/lib/libmpi.so.0.1  | grep MPI_Init
> 00070330 t MPI_Init
> 000704f0 t MPI_Init_thread
> 000706b0 t MPI_Initialized
> 00070330 T PMPI_Init
> 000704f0 T PMPI_Init_thread
> 000706b0 T PMPI_Initialized
> 
> Unfortunately, I have no idea why this happens.
> 
> Kind regards,
> 
> Thomas

Yes, I also noticed this in June last year [1].  Only the profiling
version of each API function is non-local.  Unfortunately, I was in a
hurry to get something working so I simply moved my development and
testing to another operating system rather than digging into why this
was so.  I might try to look into this later if time permits.

[1] https://marc.info/?l=openbsd-ports=152929789302360=2


Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: UPDATE: security/sshguard 1.5 --> 2.3.0

2019-01-03 Thread Andreas Kusalananda Kähäri
On Thu, Jan 03, 2019 at 12:24:04PM +0100, Gonzalo L. Rodriguez wrote:
> On Wed, 02 Jan 2019 at 10:56:39 +0100, Andreas Kusalananda Kähäri wrote:
> > On Tue, Jan 01, 2019 at 07:03:36PM +0100, Remi Pointel wrote:
> > > On 12/24/18 8:24 PM, Andreas Kusalananda Kähäri wrote:
> > > > Just resending this.
> > > > 
> > > > I got some comments from Stuart Henderson on a previous iteration of
> > > > this, and the issues that he mentioned (unorthodox HUP for terminating
> > > > the service, and various other fixes to the Makefile) have all been
> > > > resolved.  The weird does-not-start-on-boot issue that the 1.5 release
> > > > apparently also has (according to some that followed up earlier, and
> > > > that I spent some time debugging when I packaged 2.2.0) has been
> > > > resolved by ignoring HUP in a couple of places.
> > > > 
> > > > Regards
> > > 
> > > Hi,
> > > 
> > > sounds good to me, just remove the "NO_TEST = Yes" because there are
> > > regression tests.
> > > 
> > > Cheers,
> > > 
> > > Remi.
> > 
> > I enabled the tests.  The 147 supplied tests runs and passes (no fails).
> > The tests do not require any additional dependencies.
> > 
> > New diff attached.  Thanks!
> > 
> > 
> > -- 
> > Andreas Kusalananda Kähäri,
> > National Bioinformatics Infrastructure Sweden (NBIS),
> > Uppsala University, Sweden.
> 
> > Index: Makefile
[cut]
>  rc_reload=NO
> 
> I am kinda OK with this, after the:
> 
> /etc/rc.d/sshguard -fd stop
> 
> $ ps auwx | grep sshguard
> root 37238  0.0  0.1   840   664 p1  Ip12:19PM0:00.01 /bin/sh
> /usr/local/sbin/sshguard
> 
> Not quite dead, you have the same on your setup?
> 
> 
> 
> -- 
> Sending from my toaster.


This is expected.  All parts of the daemon has died at that stage, and
the only thing left running in the log reader (tail).  It too will stop
as soon as it notices that nothing is reading from the other end of the
pipe that it's writing to.  It will typically terminate as soon as the
next log message is written to /var/log/authlog.

Andreas

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: UPDATE: security/sshguard 1.5 --> 2.3.0

2019-01-02 Thread Andreas Kusalananda Kähäri
On Tue, Jan 01, 2019 at 07:03:36PM +0100, Remi Pointel wrote:
> On 12/24/18 8:24 PM, Andreas Kusalananda Kähäri wrote:
> > Just resending this.
> > 
> > I got some comments from Stuart Henderson on a previous iteration of
> > this, and the issues that he mentioned (unorthodox HUP for terminating
> > the service, and various other fixes to the Makefile) have all been
> > resolved.  The weird does-not-start-on-boot issue that the 1.5 release
> > apparently also has (according to some that followed up earlier, and
> > that I spent some time debugging when I packaged 2.2.0) has been
> > resolved by ignoring HUP in a couple of places.
> > 
> > Regards
> 
> Hi,
> 
> sounds good to me, just remove the "NO_TEST = Yes" because there are
> regression tests.
> 
> Cheers,
> 
> Remi.

I enabled the tests.  The 147 supplied tests runs and passes (no fails).
The tests do not require any additional dependencies.

New diff attached.  Thanks!


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile4 Sep 2018 12:46:21 -   1.13
+++ Makefile2 Jan 2019 09:37:46 -
@@ -2,22 +2,29 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  6
+DISTNAME=  sshguard-2.3.0
 CATEGORIES=security
 
+HOMEPAGE=  https://www.sshguard.net/
+
+MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
+
+MAINTAINER=Andreas Kusalananda Kahari 
+
 # BSD
 PERMIT_PACKAGE_CDROM=  Yes
 
 WANTLIB+=  c pthread
 
-HOMEPAGE=  https://www.sshguard.net/
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
-
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--with-firewall=pf
 
-NO_TEST=   Yes
+post-patch:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8 \
+   ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/*.{example,sample} \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /extra/cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo18 Dec 2018 16:31:02 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.3.0.tar.gz) = 1LU/h6PCZlLloombFlBrgV+lajaq9b3pwnBL+xoMoGg=
+SIZE (sshguard-2.3.0.tar.gz) = 755702
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 24 Jun 2018 10:54:19 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-configure,v 1.1 2018/06/24 10:54:19 kn Exp $
-
-Index: configure
 configure.orig
-+++ configure
-@@ -5949,7 +5949,6 @@ then
- STD99_CFLAGS="-xc99"
- else
- # other compiler (assume gcc-compatibile :( )
--OPTIMIZER_CFLAGS="-O2"
- WARNING_CFLAGS="-Wall"
- STD99_CFLAGS="-std=c99"
- fi
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_84 Dec 2018 21:52:04 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,8 +119,8 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
+-See sample configuration file.
++.B ${SYSCONFDIR}/sshguard.conf
++See sample configuration file in 
${PREFIX}/share/examples/sshguard/sshguard.conf.sample
+ .UNINDENT
+ .SH WHITELISTING
+ .sp
Index: patches/patch-examples_sshguard_conf_sample
===
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-examples_sshguard_conf_sample 4 Dec 2018 16:14:34 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
 examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+  REQUIRED CONFIGURATION 
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/ss

Re: UPDATE: security/sshguard 1.5 --> 2.3.0

2018-12-24 Thread Andreas Kusalananda Kähäri
Just resending this.

I got some comments from Stuart Henderson on a previous iteration of
this, and the issues that he mentioned (unorthodox HUP for terminating
the service, and various other fixes to the Makefile) have all been
resolved.  The weird does-not-start-on-boot issue that the 1.5 release
apparently also has (according to some that followed up earlier, and
that I spent some time debugging when I packaged 2.2.0) has been
resolved by ignoring HUP in a couple of places.

Regards,
Andreas

On Wed, Dec 19, 2018 at 06:34:25PM +0100, Andreas Kusalananda Kähäri wrote:
> 
> sshguard 1.5 in the ports tree is very old (2011), and release 2.3.0 is
> from 2018-12-16.
> 
> The attached diff brings sshguard up to version 2.3.0.  I've also added
> myself as maintainer.
> 
> The changes are too numerous to list (see [1]), but one highlight includes
> 
> * OpenSMTPD monitoring support (in 2.2.0)
> 
> The previous issus with starting/stopping the sshguard service have been
> resolved (see [2]) and it seems to run just fine on my system (only
> using it for SSH blocking).
> 
> [1]
> https://bitbucket.org/sshguard/sshguard/src/c4a90842e7d3c2c25d5417f96d49acc50f740f9c/CHANGELOG.rst?at=v2.3.0=file-view-default
> 
> [2] https://marc.info/?l=openbsd-ports=154410607613935=2
> 
> Regards,
> 
> -- 
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.

> Index: Makefile
> ===
> RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
> retrieving revision 1.13
> diff -u -p -r1.13 Makefile
> --- Makefile  4 Sep 2018 12:46:21 -   1.13
> +++ Makefile  18 Dec 2018 16:30:17 -
> @@ -2,22 +2,31 @@
>  
>  COMMENT= protect against brute force attacks on sshd and others
>  
> -DISTNAME=sshguard-1.5
> -REVISION=6
> +DISTNAME=sshguard-2.3.0
>  CATEGORIES=  security
>  
> +HOMEPAGE=https://www.sshguard.net/
> +
> +MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=sshguard/}
> +
> +MAINTAINER=  Andreas Kusalananda Kahari 
> +
>  # BSD
>  PERMIT_PACKAGE_CDROM=Yes
>  
>  WANTLIB+=c pthread
>  
> -HOMEPAGE=https://www.sshguard.net/
> -MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=sshguard/}
> -EXTRACT_SUFX=.tar.bz2
> -
>  CONFIGURE_STYLE=gnu
> -CONFIGURE_ARGS=  --with-firewall=pf
>  
>  NO_TEST= Yes
> +
> +post-patch:
> + ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8 \
> + ${WRKSRC}/examples/sshguard.conf.sample
> +
> +post-install:
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
> + ${INSTALL_DATA} ${WRKSRC}/examples/*.{example,sample} \
> + ${PREFIX}/share/examples/sshguard
>  
>  .include 
> Index: distinfo
> ===
> RCS file: /extra/cvs/ports/security/sshguard/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo  27 Jan 2014 15:49:15 -  1.3
> +++ distinfo  18 Dec 2018 16:31:02 -
> @@ -1,2 +1,2 @@
> -SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
> -SIZE (sshguard-1.5.tar.bz2) = 303767
> +SHA256 (sshguard-2.3.0.tar.gz) = 1LU/h6PCZlLloombFlBrgV+lajaq9b3pwnBL+xoMoGg=
> +SIZE (sshguard-2.3.0.tar.gz) = 755702
> Index: patches/patch-configure
> ===
> RCS file: patches/patch-configure
> diff -N patches/patch-configure
> --- patches/patch-configure   24 Jun 2018 10:54:19 -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,13 +0,0 @@
> -$OpenBSD: patch-configure,v 1.1 2018/06/24 10:54:19 kn Exp $
> -
> -Index: configure
>  configure.orig
> -+++ configure
> -@@ -5949,7 +5949,6 @@ then
> - STD99_CFLAGS="-xc99"
> - else
> - # other compiler (assume gcc-compatibile :( )
> --OPTIMIZER_CFLAGS="-O2"
> - WARNING_CFLAGS="-Wall"
> - STD99_CFLAGS="-std=c99"
> - fi
> Index: patches/patch-doc_sshguard_8
> ===
> RCS file: patches/patch-doc_sshguard_8
> diff -N patches/patch-doc_sshguard_8
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-doc_sshguard_8  4 Dec 2018 21:52:04 -
> @@ -0,0 +1,16 @@
> +$OpenBSD$
> +
> +Index: doc/sshguard.8
> +--- doc/sshguard.8.orig
>  doc/sshguard.8
> +@@ -119,8 +119,8 @@ Set to enable verbose output from sshg\-blocker.
> + .SH FILES
> + .INDENT 0.0
> + .TP
> +-.B %PREFIX%/etc/sshguard.conf
> +-See sample configuration file.
> ++.B ${SYSCONFDIR}/sshguard.conf
> ++See sample confi

UPDATE: security/sshguard 1.5 --> 2.3.0

2018-12-19 Thread Andreas Kusalananda Kähäri

sshguard 1.5 in the ports tree is very old (2011), and release 2.3.0 is
from 2018-12-16.

The attached diff brings sshguard up to version 2.3.0.  I've also added
myself as maintainer.

The changes are too numerous to list (see [1]), but one highlight includes

* OpenSMTPD monitoring support (in 2.2.0)

The previous issus with starting/stopping the sshguard service have been
resolved (see [2]) and it seems to run just fine on my system (only
using it for SSH blocking).

[1]
https://bitbucket.org/sshguard/sshguard/src/c4a90842e7d3c2c25d5417f96d49acc50f740f9c/CHANGELOG.rst?at=v2.3.0=file-view-default

[2] https://marc.info/?l=openbsd-ports=154410607613935=2

Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile4 Sep 2018 12:46:21 -   1.13
+++ Makefile18 Dec 2018 16:30:17 -
@@ -2,22 +2,31 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  6
+DISTNAME=  sshguard-2.3.0
 CATEGORIES=security
 
+HOMEPAGE=  https://www.sshguard.net/
+
+MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
+
+MAINTAINER=Andreas Kusalananda Kahari 
+
 # BSD
 PERMIT_PACKAGE_CDROM=  Yes
 
 WANTLIB+=  c pthread
 
-HOMEPAGE=  https://www.sshguard.net/
-MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
-
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--with-firewall=pf
 
 NO_TEST=   Yes
+
+post-patch:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8 \
+   ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/*.{example,sample} \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /extra/cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo18 Dec 2018 16:31:02 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.3.0.tar.gz) = 1LU/h6PCZlLloombFlBrgV+lajaq9b3pwnBL+xoMoGg=
+SIZE (sshguard-2.3.0.tar.gz) = 755702
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 24 Jun 2018 10:54:19 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-configure,v 1.1 2018/06/24 10:54:19 kn Exp $
-
-Index: configure
 configure.orig
-+++ configure
-@@ -5949,7 +5949,6 @@ then
- STD99_CFLAGS="-xc99"
- else
- # other compiler (assume gcc-compatibile :( )
--OPTIMIZER_CFLAGS="-O2"
- WARNING_CFLAGS="-Wall"
- STD99_CFLAGS="-std=c99"
- fi
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_84 Dec 2018 21:52:04 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,8 +119,8 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
+-See sample configuration file.
++.B ${SYSCONFDIR}/sshguard.conf
++See sample configuration file in 
${PREFIX}/share/examples/sshguard/sshguard.conf.sample
+ .UNINDENT
+ .SH WHITELISTING
+ .sp
Index: patches/patch-examples_sshguard_conf_sample
===
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-examples_sshguard_conf_sample 4 Dec 2018 16:14:34 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
 examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+  REQUIRED CONFIGURATION 
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/sshg-fw-pf"
+ 
+ # Space-separated list of log files to monitor. (optional, no default)
+ #FILES="/var/log/auth.log /var/log/authlog /var/log/maillog"
++FILES=/var/log/authlog
+ 
+ # Shell command that provides logs on standard output. (optional, no default)
+ # Example 1: ssh and sendmail from systemd journal:
Index: patches/patch-src_blocker_blocker_c
=

Re: sshguard-2.2.0 (start/stop issues resolved)

2018-12-06 Thread Andreas Kusalananda Kähäri

Sigh... Some day, I'll learn how to do patches correctly.  See new diff
(I had forgotten to "cvs add" some of the patches/* files).  The
already submitted tar file is correct though.

Andreas

On Thu, Dec 06, 2018 at 03:20:10PM +0100, Andreas Kusalananda Kähäri wrote:
> On Wed, Dec 05, 2018 at 12:05:07AM +, Stuart Henderson wrote:
> > On 2018/12/05 00:21, Andreas Kusalananda Kähäri wrote:
> > > Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
> > > does not start at boot when started from pkg_scripts.  It *does* start
> > > reliably when started manually with "rcctl start sshguard" and it shuts
> > > down reliably both at system shutdown and manually (and in-between, it
> > > runs well).
> > > 
> > > Any help with possible diagnoses of the startup problem would be
> > > helpful.  I haven't found any other port that starts a shell script as a
> > > daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
> > > 
> > > The "stop" action in the rc script is a bit unorthodox:
> > > 
> > > kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx 
> > > "${pexp}" )" )"
> > > 
> > > ... and that's to send a TERM signal to all the processes in the
> > > relevant process group (sshguard consists of a total of seven separate
> > > processes).  The main script does do something similar to this ("kill 0"
> > > in a trap), but this may require bash to work (and even then it doesn't
> > > seem to work reliably).
> > > 
> > > I have attached a diff for the port as well as a tar archive of it.
> > 
> > It may be worth removing from pkg_scripts and running from rc.local
> > to see if it fails there. If so then run from there under ktrace e.g.
> > "ktrace -f /tmp/ktrace.out -i /usr/sbin/rcctl start sshguard" and
> > see if anything can be gleaned from running kdump on that file.
> 
> Yes, it's getting hupped.  I have now patched out the installing of the
> signal handler for HUP in one of the helper programs, and I'm ignoring
> the same signal in the main script.  The daemon now survives the boot.
> Termination has also been improved (see end).
> 
> > 
> > A couple of porting notes,
> 
> I appreciate these.  Thanks!  They are all incorporated.
> 
> > 
> > > +CONFIGURE_STYLE=simple
> > > +CONFIGURE_ARGS=  --sysconfdir="${SYSCONFDIR}" \
> > > + --mandir="${TRUEPREFIX}/man"
> > 
> > This has crept back in, it should stay at CONFIGURE_STYLE=gnu and
> > remove the manual setting of --sysconfdir= and --mandir.
> > 
> > > +share/examples/sshguard/
> > > +share/examples/sshguard/sshguard.conf.sample
> > > +share/examples/sshguard/whitelistfile.example
> > > Index: pkg/README
> > > ===
> > > RCS file: /extra/cvs/ports/security/sshguard/pkg/README,v
> > > retrieving revision 1.3
> > > diff -u -p -r1.3 README
> > > --- pkg/README4 Sep 2018 12:46:21 -   1.3
> > > +++ pkg/README4 Dec 2018 21:10:55 -
> > > @@ -4,7 +4,13 @@ $OpenBSD: README,v 1.3 2018/09/04 12:46:
> > >  | Running ${PKGSTEM} on OpenBSD
> > >  +---
> > >  
> > > -To use sshguard with pf(4), add the following to /etc/pf.conf:
> > > +Copy the example configuration file:
> > > +
> > > +cp ${PREFIX}/share/examples/sshguard/sshguard.conf.sample \
> > > +   ${SYSCONFDIR}/sshguard.conf
> > 
> > Should use @sample in PLIST instead of telling people to do that by
> > hand, e.g.
> > 
> > share/examples/sshguard/
> > share/examples/sshguard/sshguard.conf.sample
> > @sample ${SYSCONFDIR}/sshguard.conf
> > 
> > Simpler, and helps pkg_delete -c.
> > 
> > > +
> > > +pexp="/bin/sh $pexp"
> > > +
> > > +rc_stop () {
> > > +# Need to send TERM to all processes in the process group not just
> > > +# to the ones matching "$pexp".  The main sshguard shell script does
> > > +# set up a trap for doing this, but it relies on running under bash.
> > > +kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx 
> > > "${pexp}" )" )"
> > > +}
> > >  
> > >  rc_bg=YES
> > >  rc_reload=NO
> &

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-12-06 Thread Andreas Kusalananda Kähäri
On Thu, Dec 06, 2018 at 01:12:52PM +, Stuart Henderson wrote:
> How about just removing the rc script?

No. I resolved it by making sure that every relevant part of sshguard is
ignoring HUP.  See just submitted updated port.


Anderas

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: sshguard-2.2.0 (start/stop issues resolved)

2018-12-06 Thread Andreas Kusalananda Kähäri
On Wed, Dec 05, 2018 at 12:05:07AM +, Stuart Henderson wrote:
> On 2018/12/05 00:21, Andreas Kusalananda Kähäri wrote:
> > Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
> > does not start at boot when started from pkg_scripts.  It *does* start
> > reliably when started manually with "rcctl start sshguard" and it shuts
> > down reliably both at system shutdown and manually (and in-between, it
> > runs well).
> > 
> > Any help with possible diagnoses of the startup problem would be
> > helpful.  I haven't found any other port that starts a shell script as a
> > daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
> > 
> > The "stop" action in the rc script is a bit unorthodox:
> > 
> > kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx 
> > "${pexp}" )" )"
> > 
> > ... and that's to send a TERM signal to all the processes in the
> > relevant process group (sshguard consists of a total of seven separate
> > processes).  The main script does do something similar to this ("kill 0"
> > in a trap), but this may require bash to work (and even then it doesn't
> > seem to work reliably).
> > 
> > I have attached a diff for the port as well as a tar archive of it.
> 
> It may be worth removing from pkg_scripts and running from rc.local
> to see if it fails there. If so then run from there under ktrace e.g.
> "ktrace -f /tmp/ktrace.out -i /usr/sbin/rcctl start sshguard" and
> see if anything can be gleaned from running kdump on that file.

Yes, it's getting hupped.  I have now patched out the installing of the
signal handler for HUP in one of the helper programs, and I'm ignoring
the same signal in the main script.  The daemon now survives the boot.
Termination has also been improved (see end).

> 
> A couple of porting notes,

I appreciate these.  Thanks!  They are all incorporated.

> 
> > +CONFIGURE_STYLE=simple
> > +CONFIGURE_ARGS=--sysconfdir="${SYSCONFDIR}" \
> > +   --mandir="${TRUEPREFIX}/man"
> 
> This has crept back in, it should stay at CONFIGURE_STYLE=gnu and
> remove the manual setting of --sysconfdir= and --mandir.
> 
> > +share/examples/sshguard/
> > +share/examples/sshguard/sshguard.conf.sample
> > +share/examples/sshguard/whitelistfile.example
> > Index: pkg/README
> > ===
> > RCS file: /extra/cvs/ports/security/sshguard/pkg/README,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 README
> > --- pkg/README  4 Sep 2018 12:46:21 -   1.3
> > +++ pkg/README  4 Dec 2018 21:10:55 -
> > @@ -4,7 +4,13 @@ $OpenBSD: README,v 1.3 2018/09/04 12:46:
> >  | Running ${PKGSTEM} on OpenBSD
> >  +---
> >  
> > -To use sshguard with pf(4), add the following to /etc/pf.conf:
> > +Copy the example configuration file:
> > +
> > +cp ${PREFIX}/share/examples/sshguard/sshguard.conf.sample \
> > +   ${SYSCONFDIR}/sshguard.conf
> 
> Should use @sample in PLIST instead of telling people to do that by
> hand, e.g.
> 
> share/examples/sshguard/
> share/examples/sshguard/sshguard.conf.sample
> @sample ${SYSCONFDIR}/sshguard.conf
> 
> Simpler, and helps pkg_delete -c.
> 
> > +
> > +pexp="/bin/sh $pexp"
> > +
> > +rc_stop () {
> > +# Need to send TERM to all processes in the process group not just
> > +# to the ones matching "$pexp".  The main sshguard shell script does
> > +# set up a trap for doing this, but it relies on running under bash.
> > +kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx 
> > "${pexp}" )" )"
> > +}
> >  
> >  rc_bg=YES
> >  rc_reload=NO
> 
>  ;)

It was evil and have now been removed.  I noticed that this way of doing
it would probably have killed the kernel relinking that happens after
boot, had anyone manually stopped the sshguard daemon with "rcctl stop
sshguard" early enough.  This is not the way to do it.

Instead, I do what I believe the sshguard-devs intended people to do,
which is to kill the "sshg-blocker" process instead.  This leads to the
rest of the group of processes terminating, except for a "tail" process
(but this will exit as soon as it discovers that there is nobody
reading from the pipe it's writing to).

This leads me to believe that the diff attached is an actual working
port of sshguard-2.2.0.

sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-12-04 Thread Andreas Kusalananda Kähäri
On Fri, Nov 23, 2018 at 03:36:09PM +, Stuart Henderson wrote:
> On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:
> > On Thu, Nov 22, 2018 at 02:39:54PM +, Stuart Henderson wrote:
> > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > > > > I posted about this update in late March when I had issues getting the
> > > > > sshguard service to properly shut down, but that issue has since been
> > > > > resolved (rc_stop() needs to send it the HUP signal).
> > > 
> > > HUP to shutdown?! is there some analysis on this, that's really weird.

This has now been resolved.
(but startup remains an issue, see end)

> > 
> > Looking at
> > 
> > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master=file-view-default
> > 
> > 
> > The main sshguard utility is a shell script that starts a log "tail"
> > reader, a log parser, a "blocker" (which I presume decides whether a
> > behaviour warrants blocking or not) and a firewall-specific backend that
> > actually does the blocking.  These are started in a shell pipeline:
> > 
> > eval $tailcmd | $libexec/sshg-parser | \
> > $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
> > 
> > (the unquoted variable expansions..., I won't comment more on them)
> > 
> > The bulk of the main shell script is just setting up the values of the
> > variables used in this pipeline.
> > 
> > At the start of the script, there's
> > 
> > trap "trap - TERM && kill 0" INT TERM EXIT
> > 
> > ... which does my head in a bit.  It's *really* easy to start sshguard
> > and have one of the components of this pipeline not work correctly (it's
> > usually one and the same, but I forget which one now).  This usually
> > happens when it's started from pkg_scripts at boot (but not when started
> > manually later for some reason).  Sending the main script a HUP was
> > about the *only* way I could reliably get all components of the pipeline
> > to exit cleanly.
> > 
> > I'm assuming that it expects /bin/sh to be bash, and this could be one
> > of the reasons why it misbehaves under our /bin/sh (I haven't tested
> > with bash).
> > 
> > I have only ever looked at the shell script portion of sshguard 2.1.0
> > and the BitBucket Git thing I linked to and quoted above may well be
> > newer than that.  I gave up when I couldn't get it to start/shut down
> > reliably.
> > 
> > When it *ran*, it worked flawlessly.
> > 
> > I've been meaning to get back to this to sort it out for OpenBSD, but
> > have forgotten and have had other things getting in the way.
> 
> Thanks - no objection to the update then, but would appreciate a link to
> the list archive for this 
> (https://marc.info/?l=openbsd-ports=154291717732337=2)
> in commit log for the benefit of people looking later :)

Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
does not start at boot when started from pkg_scripts.  It *does* start
reliably when started manually with "rcctl start sshguard" and it shuts
down reliably both at system shutdown and manually (and in-between, it
runs well).

Any help with possible diagnoses of the startup problem would be
helpful.  I haven't found any other port that starts a shell script as a
daemon, but I have only looked for "/bin/sh" in the rc scripts for that.

The "stop" action in the rc script is a bit unorthodox:

kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx "${pexp}" )" 
)"

... and that's to send a TERM signal to all the processes in the
relevant process group (sshguard consists of a total of seven separate
processes).  The main script does do something similar to this ("kill 0"
in a trap), but this may require bash to work (and even then it doesn't
seem to work reliably).

I have attached a diff for the port as well as a tar archive of it.


Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /extra/cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile4 Sep 2018 12:46:21 -   1.13
+++ Makefile4 Dec 2018 23:12:47 -
@@ -2,22 +2,31 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  6
+DISTNAME=  sshguard-2.2.0
 CATEGORIES=security
 
+HOMEPAGE=  https://www.sshguard.net/
+
+M

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-11-22 Thread Andreas Kusalananda Kähäri
On Thu, Nov 22, 2018 at 02:39:54PM +, Stuart Henderson wrote:
> > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > > I posted about this update in late March when I had issues getting the
> > > sshguard service to properly shut down, but that issue has since been
> > > resolved (rc_stop() needs to send it the HUP signal).
> 
> HUP to shutdown?! is there some analysis on this, that's really weird.

Looking at

https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master=file-view-default


The main sshguard utility is a shell script that starts a log "tail"
reader, a log parser, a "blocker" (which I presume decides whether a
behaviour warrants blocking or not) and a firewall-specific backend that
actually does the blocking.  These are started in a shell pipeline:

eval $tailcmd | $libexec/sshg-parser | \
$libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)

(the unquoted variable expansions..., I won't comment more on them)

The bulk of the main shell script is just setting up the values of the
variables used in this pipeline.

At the start of the script, there's

trap "trap - TERM && kill 0" INT TERM EXIT

... which does my head in a bit.  It's *really* easy to start sshguard
and have one of the components of this pipeline not work correctly (it's
usually one and the same, but I forget which one now).  This usually
happens when it's started from pkg_scripts at boot (but not when started
manually later for some reason).  Sending the main script a HUP was
about the *only* way I could reliably get all components of the pipeline
to exit cleanly.

I'm assuming that it expects /bin/sh to be bash, and this could be one
of the reasons why it misbehaves under our /bin/sh (I haven't tested
with bash).

I have only ever looked at the shell script portion of sshguard 2.1.0
and the BitBucket Git thing I linked to and quoted above may well be
newer than that.  I gave up when I couldn't get it to start/shut down
reliably.

When it *ran*, it worked flawlessly.

I've been meaning to get back to this to sort it out for OpenBSD, but
have forgotten and have had other things getting in the way.

Andreas

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



sysutils/stow: New address for maintainer

2018-11-22 Thread Andreas Kusalananda Kähäri


Update maintainer email address (this is currently the only port that
I'm the maintainer of):


Index: Makefile
===
RCS file: /extra/cvs/ports/sysutils/stow/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile29 Dec 2016 09:10:36 -  1.12
+++ Makefile22 Nov 2018 16:58:45 -
@@ -7,7 +7,7 @@ CATEGORIES= sysutils

 HOMEPAGE=  https://www.gnu.org/software/stow/stow.html

-MAINTAINER=Andreas Kusalananda Kahari 
+MAINTAINER=Andreas Kusalananda Kahari 

 # GPL
 PERMIT_PACKAGE_CDROM=  Yes

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/en/about-uu/data-protection-policy



Re: fix HOMEPAGE of sysutils/faubackup

2018-10-25 Thread Andreas Kusalananda Kähäri
On Thu, Oct 25, 2018 at 12:05:40PM +0200, Solene Rapenne wrote:
> "Anthony J. Bentley"  wrote:
> > Solene Rapenne writes:
> > > 
> > > faubackup homepage is not working anymore.
> > 
> > Any idea what to use for MASTER_SITES?
> 
> indeed, it doesn't work either.
> Seems that the project homepage doesn't provide sources :(
> 

FWIW, Debian says it's dead upstream and removed it in 2016.
https://launchpad.net/ubuntu/+source/faubackup/+publishinghistory

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



shells/ksh93 no distfiles available, new github repo with Meson build

2018-07-16 Thread Andreas Kusalananda Kähäri


Hi,

I noticed the other day that the shells/ksh93 port stopped building due
to none of the distfiles being available.

I also noticed that the ksh93 shell now has a GitHub repository set
up at https://github.com/att/ast (the license is EPL-1.0) and that
it _finally_ uses a more modern build system (Meson, and it builds
surprisingly quickly).

The shell is still ksh93u+, but there's also a ksh93v- (beta?) release.

Before I start writing a patch for this, are you (Pascal) planning on
updating the port?

Regards,

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/om-uu/dataskydd-personuppgifter/



Re: Getting update signature from package file

2018-07-02 Thread Andreas Kusalananda Kähäri
On Mon, Jul 02, 2018 at 02:15:12PM +0200, Marc Espie wrote:
> On Mon, Jul 02, 2018 at 02:01:53PM +0200, Andreas Kusalananda Kähäri wrote:
> > Is it possible to get the update signature from an uninstalled, locally
> > built, package?
> >
> > I tried with
> >
> > doas pkg_info -q -S
> > /usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz
> >
> > but got
> >
> > file:/usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz: unsigned package
> > (signify(1) doesn't see old-style signatures)
>
> So use -Dunsigned, as documented for pkg_add.

Ah, much thanks!

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/om-uu/dataskydd-personuppgifter/



Getting update signature from package file

2018-07-02 Thread Andreas Kusalananda Kähäri
Is it possible to get the update signature from an uninstalled, locally
built, package?

I tried with

doas pkg_info -q -S
/usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz

but got

file:/usr/ports/packages/amd64/all/libtool-2.4.2p0.tgz: unsigned package
(signify(1) doesn't see old-style signatures)

After installing the package, one can do "pkg_info -q -S", but I'd like
to see the signature without having to install it.

Regards,

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/om-uu/dataskydd-personuppgifter/



Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-06-24 Thread Andreas Kusalananda Kähäri
On Sun, Jun 24, 2018 at 04:49:27PM +0200, Klemens Nanni wrote:
> On Mon, Apr 23, 2018 at 11:12:55AM +0200, Andreas Kusalananda Kähäri wrote:
> > On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:
> > > On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri 
> > > wrote:
> > > >
> > > > Please find the diffs for an updated port of sshguard attached.
> > >
> > > Now actually attached, duh.
> > >
> >
> > Updated patch attached with comments from kn@ taken into account, but
> > with CONFIGURE_STYLE=gnu left in place as suggested by Jeremie and
> > Stuart.
> I forgot about this diff when removing -O2 earlier (portroach also
> wouldn't detect an update due to EXTRACT_SUFX change), thanks Andreas
> for reminding me.
>
> The diff looks good, I made a few additional changes:
>
> - Drop README: sshguard-intro(7) contains all relevant information
> - sshguard.rc: $pexp -> ${pexp}, unfold rc_stop()
> - Makefile: Use SUBST_CMD and INSTALL_DATA just once
>
> On amd64 sshguard continues to work.
>
> 1.5.0 is broken on sparc64 due to an assertion failure when parsing log
> lines, 2.1.0 fixed this.
>
> OK?
>
[cut]

The issue with this is that it won't start properly at reboots.  One
may start it manually through "doas rcctl start sshguard" but if
it's started automatically through pkg_scripts, its sshg-blocker and
sshg-fw-pf (backend) process dies and leaves the tail and sshg-parser
processes, as well as the main sshguard script, hanging.

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/om-uu/dataskydd-personuppgifter/



Re: Issue with linking OpenMPI programs (devel/openmpi)

2018-06-17 Thread Andreas Kusalananda Kähäri
On Sun, Jun 17, 2018 at 11:39:21AM +0200, Andreas Kusalananda Kähäri wrote:
> 
> Issue resolved by setting OMPI_CC=gcc

Sorry, I spoke too soon. It's not resolved.  I still had the profiling
functions rather than the real functions in my test program. Duh.


> 
> 
> On Sun, Jun 17, 2018 at 11:18:31AM +0200, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > I'm trying to build a piece of software that uses MPI.  On a current
> > amd64 OpenBSD system I use the devel/openmpi port for this, but simple
> > test programs fail to link properly, complaining about the MPI
> > functions:
> > 
> > #include 
> > 
> > int
> > main(int argc, char **argv)
> > {
> > MPI_Init(, );
> > MPI_Finalize();
> > return 0;
> > }
> > 
> > 
> > Compiling this:
> > 
> > $ mpicc mpitest.c
> > /usr/local/lib/libopen-pal.so.0.0: warning: strcat() is almost always 
> > misused, please use strlcat()
> > /usr/local/lib/libmpi.so.0.1: warning: strcpy() is almost always misused, 
> > please use strlcpy()
> > /usr/local/lib/libopen-rte.so.0.0: warning: rand() may return deterministic 
> > values, is that what you want?
> > /usr/local/lib/libopen-rte.so.0.0: warning: sprintf() is often misused, 
> > please use snprintf()
> > /usr/local/lib/libopen-pal.so.0.0: warning: vsprintf() is often misused, 
> > please use vsnprintf()
> > /tmp_mfs/mpitest-e45b73.o: In function `main':
> > mpitest.c:(.text+0x3d): undefined reference to `MPI_Init'
> > mpitest.c:(.text+0x45): undefined reference to `MPI_Finalize'
> > cc: error: linker command failed with exit code 1 (use -v to see invocation)
> > 
> > How do I go about working around this?
> > 
> > I notice that the ordinary MPI functions in libmpi.so.0.1 are marked as
> > "local" (they have 't' in the nm output), whereas the profiling version
> > of the functions are not.  The profiling functions have a 'P' prefix
> > (e.g. "PMPI_Init()") and the link properly.  Th issue is that I'm trying
> > to compile a preexisting piece of software and I don't want it to call
> > the profiling routines.
> > 
> > The devel/openmpi port was built from source, but the same error occurs
> > with the package version.
> > 
> > --
> > Andreas Kusalananda Kähäri,
> > National Bioinformatics Infrastructure Sweden (NBIS),
> > Uppsala University, Sweden.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > När du har kontakt med oss på Uppsala universitet med e-post så innebär det 
> > att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det 
> > kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
> > 
> > E-mailing Uppsala University means that we will process your personal data. 
> > For more information on how this is performed, please read here: 
> > http://www.uu.se/om-uu/dataskydd-personuppgifter/
> > 
> 
> -- 
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
> 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: Issue with linking OpenMPI programs (devel/openmpi)

2018-06-17 Thread Andreas Kusalananda Kähäri


Issue resolved by setting OMPI_CC=gcc


On Sun, Jun 17, 2018 at 11:18:31AM +0200, Andreas Kusalananda Kähäri wrote:
> Hi,
> 
> I'm trying to build a piece of software that uses MPI.  On a current
> amd64 OpenBSD system I use the devel/openmpi port for this, but simple
> test programs fail to link properly, complaining about the MPI
> functions:
> 
> #include 
> 
> int
> main(int argc, char **argv)
> {
> MPI_Init(, );
> MPI_Finalize();
> return 0;
> }
> 
> 
> Compiling this:
> 
> $ mpicc mpitest.c
> /usr/local/lib/libopen-pal.so.0.0: warning: strcat() is almost always 
> misused, please use strlcat()
> /usr/local/lib/libmpi.so.0.1: warning: strcpy() is almost always misused, 
> please use strlcpy()
> /usr/local/lib/libopen-rte.so.0.0: warning: rand() may return deterministic 
> values, is that what you want?
> /usr/local/lib/libopen-rte.so.0.0: warning: sprintf() is often misused, 
> please use snprintf()
> /usr/local/lib/libopen-pal.so.0.0: warning: vsprintf() is often misused, 
> please use vsnprintf()
> /tmp_mfs/mpitest-e45b73.o: In function `main':
> mpitest.c:(.text+0x3d): undefined reference to `MPI_Init'
> mpitest.c:(.text+0x45): undefined reference to `MPI_Finalize'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> How do I go about working around this?
> 
> I notice that the ordinary MPI functions in libmpi.so.0.1 are marked as
> "local" (they have 't' in the nm output), whereas the profiling version
> of the functions are not.  The profiling functions have a 'P' prefix
> (e.g. "PMPI_Init()") and the link properly.  Th issue is that I'm trying
> to compile a preexisting piece of software and I don't want it to call
> the profiling routines.
> 
> The devel/openmpi port was built from source, but the same error occurs
> with the package version.
> 
> --
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
> 
> 
> 
> 
> 
> 
> 
> 
> När du har kontakt med oss på Uppsala universitet med e-post så innebär det 
> att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan 
> du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/
> 
> E-mailing Uppsala University means that we will process your personal data. 
> For more information on how this is performed, please read here: 
> http://www.uu.se/om-uu/dataskydd-personuppgifter/
> 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Issue with linking OpenMPI programs (devel/openmpi)

2018-06-17 Thread Andreas Kusalananda Kähäri
Hi,

I'm trying to build a piece of software that uses MPI.  On a current
amd64 OpenBSD system I use the devel/openmpi port for this, but simple
test programs fail to link properly, complaining about the MPI
functions:

#include 

int
main(int argc, char **argv)
{
MPI_Init(, );
MPI_Finalize();
return 0;
}


Compiling this:

$ mpicc mpitest.c
/usr/local/lib/libopen-pal.so.0.0: warning: strcat() is almost always misused, 
please use strlcat()
/usr/local/lib/libmpi.so.0.1: warning: strcpy() is almost always misused, 
please use strlcpy()
/usr/local/lib/libopen-rte.so.0.0: warning: rand() may return deterministic 
values, is that what you want?
/usr/local/lib/libopen-rte.so.0.0: warning: sprintf() is often misused, please 
use snprintf()
/usr/local/lib/libopen-pal.so.0.0: warning: vsprintf() is often misused, please 
use vsnprintf()
/tmp_mfs/mpitest-e45b73.o: In function `main':
mpitest.c:(.text+0x3d): undefined reference to `MPI_Init'
mpitest.c:(.text+0x45): undefined reference to `MPI_Finalize'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

How do I go about working around this?

I notice that the ordinary MPI functions in libmpi.so.0.1 are marked as
"local" (they have 't' in the nm output), whereas the profiling version
of the functions are not.  The profiling functions have a 'P' prefix
(e.g. "PMPI_Init()") and the link properly.  Th issue is that I'm trying
to compile a preexisting piece of software and I don't want it to call
the profiling routines.

The devel/openmpi port was built from source, but the same error occurs
with the package version.

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/om-uu/dataskydd-personuppgifter/



Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-04-23 Thread Andreas Kusalananda Kähäri
On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:
> On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
> > 
> > Please find the diffs for an updated port of sshguard attached.
> 
> Now actually attached, duh.
> 

Updated patch attached with comments from kn@ taken into account, but
with CONFIGURE_STYLE=gnu left in place as suggested by Jeremie and
Stuart.

Regards,

> 
> > 
> > This updates sshguard from version 1.5 to 2.1.0.  One of the main
> > reasons to update to this version is that sshguard now seems to
> > correctly parse the OpenBSD sshd logs.  One can now also block an entire
> > subnet rather than individual IP addresses, if one is so inclined.
> > 
> > I have been running this port for a few weeks, and it seems to work as
> > advertised.
> > 
> > Note that the /etc/sshguard.conf file now is required (I modified the
> > sample file so that it hopefully fits a vanilla OpenBSD system).
> > 
> > I posted about this update in late March when I had issues getting the
> > sshguard service to properly shut down, but that issue has since been
> > resolved (rc_stop() needs to send it the HUP signal).
> > 
> > Release announcements for sshguard are available at
> > https://www.sshguard.net/litenewz/feeds/
> > 
> > Regards,


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
? sshguard.diff
Index: Makefile
===
RCS file: /cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- Makefile11 Jan 2018 19:27:09 -  1.11
+++ Makefile23 Apr 2018 09:08:33 -
@@ -2,8 +2,7 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  4
+DISTNAME=  sshguard-2.1.0
 CATEGORIES=security
 
 # BSD
@@ -11,13 +10,21 @@ PERMIT_PACKAGE_CDROM=   Yes
 
 WANTLIB+=  c pthread
 
-HOMEPAGE=  http://www.sshguard.net/
+HOMEPAGE=  https://www.sshguard.net/
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
 
 CONFIGURE_STYLE=gnu
 NO_TEST=   Yes
 
-CONFIGURE_ARGS = --with-firewall=pf 
+post-patch:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8
+   ${SUBST_CMD} ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/sshguard.conf.sample \
+   ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/whitelistfile.example \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo23 Apr 2018 09:08:33 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.1.0.tar.gz) = ISUqSDSthAjfOE7k3fRoYkqp3pzq1a/eHHc4CkjPAoo=
+SIZE (sshguard-2.1.0.tar.gz) = 1117466
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_823 Apr 2018 09:08:33 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,7 +119,7 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
++.B ${SYSCONFDIR}/sshguard.conf
+ See sample configuration file.
+ .UNINDENT
+ .SH WHITELISTING
Index: patches/patch-examples_sshguard_conf_sample
===
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-examples_sshguard_conf_sample 23 Apr 2018 09:08:33 -
@@ -0,0 +1,31 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
 examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+  REQUIRED CONFIGURATION 
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/sshg-fw-pf"
+ 
+ # Space-separated list of log files to monitor. (optional, no default)
+ #FILES="/var/log/auth.log /var/log/authlog /var/log/maillog"
++FILES="/var/log/authlog"
+ 
+ # Shell command that provides logs on standard output. (optional, no default)
+ # Example 1: ssh and sendmail 

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-04-22 Thread Andreas Kusalananda Kähäri
On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
> 
> Please find the diffs for an updated port of sshguard attached.

Now actually attached, duh.


> 
> This updates sshguard from version 1.5 to 2.1.0.  One of the main
> reasons to update to this version is that sshguard now seems to
> correctly parse the OpenBSD sshd logs.  One can now also block an entire
> subnet rather than individual IP addresses, if one is so inclined.
> 
> I have been running this port for a few weeks, and it seems to work as
> advertised.
> 
> Note that the /etc/sshguard.conf file now is required (I modified the
> sample file so that it hopefully fits a vanilla OpenBSD system).
> 
> I posted about this update in late March when I had issues getting the
> sshguard service to properly shut down, but that issue has since been
> resolved (rc_stop() needs to send it the HUP signal).
> 
> Release announcements for sshguard are available at
> https://www.sshguard.net/litenewz/feeds/
> 
> Regards,
> 
> -- 
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
? sshguard.diff
Index: Makefile
===
RCS file: /cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- Makefile11 Jan 2018 19:27:09 -  1.11
+++ Makefile22 Apr 2018 13:47:55 -
@@ -2,8 +2,7 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  4
+DISTNAME=  sshguard-2.1.0
 CATEGORIES=security
 
 # BSD
@@ -13,11 +12,20 @@ WANTLIB+=   c pthread
 
 HOMEPAGE=  http://www.sshguard.net/
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
+EXTRACT_SUFX=  .tar.gz
 
 CONFIGURE_STYLE=gnu
 NO_TEST=   Yes
 
-CONFIGURE_ARGS = --with-firewall=pf 
+pre-install:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8
+   ${SUBST_CMD} ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/sshguard.conf.sample \
+   ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/whitelistfile.example \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo22 Apr 2018 13:47:55 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.1.0.tar.gz) = ISUqSDSthAjfOE7k3fRoYkqp3pzq1a/eHHc4CkjPAoo=
+SIZE (sshguard-2.1.0.tar.gz) = 1117466
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_822 Apr 2018 13:47:55 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,7 +119,7 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
++.B ${SYSCONFDIR}/sshguard.conf
+ See sample configuration file.
+ .UNINDENT
+ .SH WHITELISTING
Index: patches/patch-examples_sshguard_conf_sample
===
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-examples_sshguard_conf_sample 22 Apr 2018 13:47:55 -
@@ -0,0 +1,31 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
 examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+  REQUIRED CONFIGURATION 
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/sshg-fw-pf"
+ 
+ # Space-separated list of log files to monitor. (optional, no default)
+ #FILES="/var/log/auth.log /var/log/authlog /var/log/maillog"
++FILES="/var/log/authlog"
+ 
+ # Shell command that provides logs on standard output. (optional, no default)
+ # Example 1: ssh and sendmail from systemd journal:
+@@ -40,11 +42,11 @@ DETECTION_TIME=1800
+ # !! Warning: These features may not work correctly with sandboxing. !!
+ 
+ # Full path to PID file (optional, no default)
+-#PID_FILE=/run/sshguard.pid
++#PID_FILE=/var/run/sshguard.pid
+ 
+ # Colon-separated black

UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

2018-04-22 Thread Andreas Kusalananda Kähäri

Please find the diffs for an updated port of sshguard attached.

This updates sshguard from version 1.5 to 2.1.0.  One of the main
reasons to update to this version is that sshguard now seems to
correctly parse the OpenBSD sshd logs.  One can now also block an entire
subnet rather than individual IP addresses, if one is so inclined.

I have been running this port for a few weeks, and it seems to work as
advertised.

Note that the /etc/sshguard.conf file now is required (I modified the
sample file so that it hopefully fits a vanilla OpenBSD system).

I posted about this update in late March when I had issues getting the
sshguard service to properly shut down, but that issue has since been
resolved (rc_stop() needs to send it the HUP signal).

Release announcements for sshguard are available at
https://www.sshguard.net/litenewz/feeds/

Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: dpb: packages not built, in 'H' state (no NFS, local build)

2018-04-22 Thread Andreas Kusalananda Kähäri
On Sun, Apr 22, 2018 at 10:01:28AM +0100, Nigel Taylor wrote:
> On 04/22/18 09:35, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > I'm using dpb in combination with proot to build a subset of packages on
> > my local machine.  I quite often have an issue with packages not getting
> > built and instead being listed as in the 'H' state.  According to the
> > dpb(1) manual, this is due to "package still not found due to nfs on
> > this run", but I'm not mounting anything on NFS.
> > 
> > Examples of packages that ended up in this state in my most recent
> > build:
> > 
> > lang/python/2.7
> > devel/git
> > devel/shellcheck
> > 
> > Python 2.7 (and 3.6) often end up in 'H'.
> > 
> > What are the other reasons this may happen?
> > 
> > Regards,
> > 
> I seen this when I've updated the ports tree while dpb is running, the
> last in the list devel/shellcheck, has only recently been updated, so
> revision has changed from p0 to p1, you might have built p1 revision,
> but dpb is still looking for p0 revision as it doesn't rescan the ports
> tree once building started, so dpb has information that devel/shellcheck
> has been built, but can't see the matching package.
> 
> This is the one I know off.
> 

Thanks.  This does however not apply to my setup.  I make sure the
usr/ports directory in the chroot directory is up to date before
starting dpb, and I don't touch it while it's running.  Also, re-running
the build will quickly cycle through all packages and dependencies and
immediately put the same packages in the 'H' state.

FWIW, I run dpb with

dpb -B "$chroot_dir" -s -uU -R -M 2G \
-P "$HOME/packages.txt"

and I build the proot with the following configuration:

actions=unpopulate
chroot=/extra/proot
preserve=/usr/ports

After building the proot, I rsync over the ports directory from outside
the chroot (while doing this, I make sure that the two copies of
usr/ports are identical).

The ports that end up in the 'H' state builds just fine in or outside
the chroot when I do "make package".




-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



dpb: packages not built, in 'H' state (no NFS, local build)

2018-04-22 Thread Andreas Kusalananda Kähäri
Hi,

I'm using dpb in combination with proot to build a subset of packages on
my local machine.  I quite often have an issue with packages not getting
built and instead being listed as in the 'H' state.  According to the
dpb(1) manual, this is due to "package still not found due to nfs on
this run", but I'm not mounting anything on NFS.

Examples of packages that ended up in this state in my most recent
build:

lang/python/2.7
devel/git
devel/shellcheck

Python 2.7 (and 3.6) often end up in 'H'.

What are the other reasons this may happen?

Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



sshguard 1.5-->2.1.0, daemon issues

2018-03-25 Thread Andreas Kusalananda Kähäri
Hi,

I updated the security/sshguard port from 1.5 to 2.1.0 as that version
now understands the logs that our newer version of OpenSSH outputs.

The port works as it should do, but I have an issue with shutting the
daemon down. "rcctl stop sshguard" simply does nothing.  The "sshguard"
executable is now a shell script, and it does not respond do the TERM
signal properly and does not seem to propagate the signal to the helper
programs that it starts.

I have included the diff in an attachment.

Note that the /etc/sshguard.conf file now is required (I modified the
sample file so that it fits a vanilla OpenBSD system).

If anyone knows how to fix this, then please let me know. Also, I know
the ports tree is locked, but it would be nice to get some kind of
update of sshguard into the tree when it unlocks again, possibly based
on this patch.

Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.
Index: Makefile
===
RCS file: /cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile11 Jan 2018 19:27:09 -  1.11
+++ Makefile25 Mar 2018 11:12:30 -
@@ -2,8 +2,7 @@
 
 COMMENT=   protect against brute force attacks on sshd and others
 
-DISTNAME=  sshguard-1.5
-REVISION=  4
+DISTNAME=  sshguard-2.1.0
 CATEGORIES=security
 
 # BSD
@@ -13,11 +12,20 @@ WANTLIB+=   c pthread
 
 HOMEPAGE=  http://www.sshguard.net/
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX=  .tar.bz2
+EXTRACT_SUFX=  .tar.gz
 
 CONFIGURE_STYLE=gnu
 NO_TEST=   Yes
 
-CONFIGURE_ARGS = --with-firewall=pf 
+pre-install:
+   ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8
+   ${SUBST_CMD} ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+   ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/sshguard.conf.sample \
+   ${PREFIX}/share/examples/sshguard
+   ${INSTALL_DATA} ${WRKSRC}/examples/whitelistfile.example \
+   ${PREFIX}/share/examples/sshguard
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo27 Jan 2014 15:49:15 -  1.3
+++ distinfo25 Mar 2018 11:12:30 -
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.1.0.tar.gz) = ISUqSDSthAjfOE7k3fRoYkqp3pzq1a/eHHc4CkjPAoo=
+SIZE (sshguard-2.1.0.tar.gz) = 1117466
Index: patches/patch-doc_sshguard_8
===
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-doc_sshguard_825 Mar 2018 11:12:30 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
 doc/sshguard.8
+@@ -119,7 +119,7 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
++.B ${SYSCONFDIR}/sshguard.conf
+ See sample configuration file.
+ .UNINDENT
+ .SH WHITELISTING
Index: patches/patch-examples_sshguard_conf_sample
===
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-examples_sshguard_conf_sample 25 Mar 2018 11:12:30 -
@@ -0,0 +1,31 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
 examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+  REQUIRED CONFIGURATION 
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/sshg-fw-pf"
+ 
+ # Space-separated list of log files to monitor. (optional, no default)
+ #FILES="/var/log/auth.log /var/log/authlog /var/log/maillog"
++FILES="/var/log/authlog"
+ 
+ # Shell command that provides logs on standard output. (optional, no default)
+ # Example 1: ssh and sendmail from systemd journal:
+@@ -40,11 +42,11 @@ DETECTION_TIME=1800
+ # !! Warning: These features may not work correctly with sandboxing. !!
+ 
+ # Full path to PID file (optional, no default)
+-#PID_FILE=/run/sshguard.pid
++#PID_FILE=/var/run/sshguard.pid
+ 
+ # Colon-separated blacklist threshold and full path to blacklist file.
+ # (optional, no default)
+-#BLACKLIST_FILE=90:/var/lib/sshguard/enemies
++#BLACKLIST_FILE=90:/var/db/sshguard/enemies
+ 
+ # IP addresses listed in the WHITELIST_FILE are considered to be
+ # friendlies and will never be blocked.
Index: patches/patch-src_fwalls_command_c
===

Re: dpb and ccache

2017-11-04 Thread Andreas Kusalananda Kähäri
The committed fix seems to work as advertised.  Thanks for sorting it
out so quickly!

Andreas


On Sat, Nov 04, 2017 at 07:49:20PM +, Stuart Henderson wrote:
> On 2017/11/04 20:38, Andreas Kusalananda Kähäri wrote:
> > On Sat, Nov 04, 2017 at 08:15:48PM +0100, Andreas Kusalananda Kähäri wrote:
> > > On Sat, Nov 04, 2017 at 07:23:01PM +0100, Marc Espie wrote:
> > > > On Sat, Nov 04, 2017 at 05:46:26PM +0100, Andreas Kusalananda Kähäri 
> > > > wrote:
> > > > > Hi,
> > > > > 
> > > > > I tried using dpb(1) with ccache today by adding USE_CCACHE=Yes and
> > > > > pointing CCACHE_DIR to a sensible location owned by _pbuild:
> > > > > 
> > > > > USE_CCACHE=Yes
> > > > > CCACHE_DIR=/extra/ccache
> > > > > 
> > > > > However, it seems as if this causes dpb to just quickly run though all
> > > > > the ports in my list without buiding anything, or even checking the 
> > > > > port
> > > > > signatures.
> > > > > 
> > > > > I'm running dpb like this:
> > > > > 
> > > > > doas /usr/ports/infrastructure/bin/dpb -p4 -suUR -J0 -P 
> > > > > "$HOME/packages.txt"
> > > > > 
> > > > > Is it possible to enable ccache at all for dpb?  I'm using dpb since 
> > > > > it
> > > > > makes it easy to keep ports up to date on -current, and I'd really 
> > > > > want
> > > > > to have the ability to run with ccache to speed up the rebuilding of 
> > > > > some
> > > > > of the larger ports.
> > > > 
> > > > I'm not going  to go debug that from scratch.
> > > > 
> > > > It's likely dpb produced at least some output, like some logs.
> > > > So there might be an indication of why it doesn't work.
> > > > 
> > > 
> > > Sorry, the summary log, which I don't fully uderstand, seems to say
> > > nothing is being built because of circular dependencies between ccache
> > > and xz(?):
> > > 
> > > x11/dbus not built textproc/xmlto -> misc/gnugetopt -> 
> > > devel/gettext-tools -> archivers/xz -> devel/ccache -> 
> > > devel/autoconf/2.69 -> devel/help2man -> archivers/xz
> > 
> > There's a dependency cycle in the build dependencies for ccache whek
> > USE_CCACHE is set to "Yes":
> > 
> > $ make print-build-depends
> > This port requires package(s) "tsort: cycle in data
> > tsort: devel/autoconf/2.69
> > tsort: devel/ccache
> > tsort: cycle in data
> > tsort: devel/ccache
> > tsort: devel/metaauto
> > autoconf-2.69p2 ccache-3.3.4p0 metaauto-1.0p1 xz-5.2.3p0" to build.
> > 
> > 
> > My guess is that all of those port ought to have NO_CCACHE=Yes.
> 
> This was just a mistake when bulk-fixing autoconf scripts wih nested
> functions shortly before 6.2.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/ccache/Makefile,v
> retrieving revision 1.39
> diff -u -p -r1.39 Makefile
> --- Makefile  25 Sep 2017 19:55:19 -  1.39
> +++ Makefile  4 Nov 2017 19:47:47 -
> @@ -17,9 +17,9 @@ WANTLIB += c m z
>  
>  MASTER_SITES =   http://samba.org/ftp/ccache/
>  
> -CONFIGURE_STYLE =autoconf
> -AUTOCONF_VERSION =   2.69
> +CONFIGURE_STYLE =gnu
>  
> +# This port should not have dependencies.
>  NO_CCACHE =  Yes
>  
>  .include 
> Index: patches/patch-configure
> ===
> RCS file: patches/patch-configure
> diff -N patches/patch-configure
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-configure   4 Nov 2017 19:47:47 -
> @@ -0,0 +1,18 @@
> +$OpenBSD$
> +
> +Index: configure
> +--- configure.orig
>  configure
> +@@ -4544,10 +4544,11 @@ else
> + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> + /* end confdefs.h.  */
> + #include 
> ++void test_fn(void) { qsort(NULL, 0, 0, (__compar_fn_t)NULL); }
> + int
> + main ()
> + {
> +-void test_fn(void) { qsort(NULL, 0, 0, (__compar_fn_t)NULL); }
> ++
> +   ;
> +   return 0;
> + }
> Index: patches/patch-configure_ac
> ===
> RCS file: patches/patch-configure_ac
> diff -N patches/patch-configure_ac
> --- patches/patch-configure_ac25 Sep 2017 19:55:19 -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,17 +0,0 @@
> -$OpenBSD: patch-configure_ac,v 1.1 2017/09/25 19:55:19 sthen Exp $
> -
> -Index: configure.ac
>  configure.ac.orig
> -+++ configure.ac
> -@@ -65,8 +65,9 @@ AC_CHECK_FUNCS(utimes)
> - 
> - AC_CACHE_CHECK([for compar_fn_t in stdlib.h],ccache_cv_COMPAR_FN_T, [
> - AC_TRY_COMPILE(
> --[#include ],
> --[void test_fn(void) { qsort(NULL, 0, 0, (__compar_fn_t)NULL); }],
> -+[#include 
> -+void test_fn(void) { qsort(NULL, 0, 0, (__compar_fn_t)NULL); }],
> -+[],
> - ccache_cv_COMPAR_FN_T=yes,
> - ccache_cv_COMPAR_FN_T=no)])
> - if test x"$ccache_cv_COMPAR_FN_T" = x"yes"; then
> 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: dpb and ccache

2017-11-04 Thread Andreas Kusalananda Kähäri
On Sat, Nov 04, 2017 at 08:15:48PM +0100, Andreas Kusalananda Kähäri wrote:
> On Sat, Nov 04, 2017 at 07:23:01PM +0100, Marc Espie wrote:
> > On Sat, Nov 04, 2017 at 05:46:26PM +0100, Andreas Kusalananda Kähäri wrote:
> > > Hi,
> > > 
> > > I tried using dpb(1) with ccache today by adding USE_CCACHE=Yes and
> > > pointing CCACHE_DIR to a sensible location owned by _pbuild:
> > > 
> > > USE_CCACHE=Yes
> > > CCACHE_DIR=/extra/ccache
> > > 
> > > However, it seems as if this causes dpb to just quickly run though all
> > > the ports in my list without buiding anything, or even checking the port
> > > signatures.
> > > 
> > > I'm running dpb like this:
> > > 
> > > doas /usr/ports/infrastructure/bin/dpb -p4 -suUR -J0 -P 
> > > "$HOME/packages.txt"
> > > 
> > > Is it possible to enable ccache at all for dpb?  I'm using dpb since it
> > > makes it easy to keep ports up to date on -current, and I'd really want
> > > to have the ability to run with ccache to speed up the rebuilding of some
> > > of the larger ports.
> > 
> > I'm not going  to go debug that from scratch.
> > 
> > It's likely dpb produced at least some output, like some logs.
> > So there might be an indication of why it doesn't work.
> > 
> 
> Sorry, the summary log, which I don't fully uderstand, seems to say
> nothing is being built because of circular dependencies between ccache
> and xz(?):
> 
> x11/dbus not built textproc/xmlto -> misc/gnugetopt -> devel/gettext-tools -> 
> archivers/xz -> devel/ccache -> devel/autoconf/2.69 -> devel/help2man -> 
> archivers/xz

There's a dependency cycle in the build dependencies for ccache whek
USE_CCACHE is set to "Yes":

$ make print-build-depends
This port requires package(s) "tsort: cycle in data
tsort: devel/autoconf/2.69
tsort: devel/ccache
tsort: cycle in data
tsort: devel/ccache
tsort: devel/metaauto
autoconf-2.69p2 ccache-3.3.4p0 metaauto-1.0p1 xz-5.2.3p0" to build.


My guess is that all of those port ought to have NO_CCACHE=Yes.


-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: dpb and ccache

2017-11-04 Thread Andreas Kusalananda Kähäri
On Sat, Nov 04, 2017 at 07:23:01PM +0100, Marc Espie wrote:
> On Sat, Nov 04, 2017 at 05:46:26PM +0100, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > I tried using dpb(1) with ccache today by adding USE_CCACHE=Yes and
> > pointing CCACHE_DIR to a sensible location owned by _pbuild:
> > 
> > USE_CCACHE=Yes
> > CCACHE_DIR=/extra/ccache
> > 
> > However, it seems as if this causes dpb to just quickly run though all
> > the ports in my list without buiding anything, or even checking the port
> > signatures.
> > 
> > I'm running dpb like this:
> > 
> > doas /usr/ports/infrastructure/bin/dpb -p4 -suUR -J0 -P 
> > "$HOME/packages.txt"
> > 
> > Is it possible to enable ccache at all for dpb?  I'm using dpb since it
> > makes it easy to keep ports up to date on -current, and I'd really want
> > to have the ability to run with ccache to speed up the rebuilding of some
> > of the larger ports.
> 
> I'm not going  to go debug that from scratch.
> 
> It's likely dpb produced at least some output, like some logs.
> So there might be an indication of why it doesn't work.
> 

Sorry, the summary log, which I don't fully uderstand, seems to say
nothing is being built because of circular dependencies between ccache
and xz(?):

x11/dbus not built textproc/xmlto -> misc/gnugetopt -> devel/gettext-tools -> 
archivers/xz -> devel/ccache -> devel/autoconf/2.69 -> devel/help2man -> 
archivers/xz
x11/dbus,-main same as x11/dbus
x11/dbus,-suid not built textproc/xmlto -> misc/gnugetopt -> 
devel/gettext-tools -> archivers/xz -> devel/ccache -> devel/autoconf/2.69 -> 
devel/help2man -> archivers/xz
x11/dbus-glib not built devel/glib2 -> x11/dbus -> textproc/xmlto -> 
misc/gnugetopt -> devel/gettext-tools -> archivers/xz -> devel/ccache -> 
devel/autoconf/2.69 -> devel/help2man -> archivers/xz
x11/gnome/adwaita-icon-theme not built x11/icontool -> textproc/p5-XML-Simple 
-> devel/ccache -> devel/autoconf/2.69 -> devel/help2man -> archivers/xz -> 
devel/ccache
x11/gnome/at-spi2-atk not built textproc/intltool -> textproc/p5-XML-Parser -> 
devel/ccache -> devel/autoconf/2.69 -> devel/help2man -> archivers/xz -> 
devel/ccache
x11/gnome/at-spi2-core not built textproc/intltool -> textproc/p5-XML-Parser -> 
devel/ccache -> devel/autoconf/2.69 -> devel/help2man -> archivers/xz -> 
devel/ccache
x11/gnome/libgnome-keyring not built devel/ccache -> devel/autoconf/2.69 -> 
devel/help2man -> archivers/xz -> devel/ccache
x11/gnome/librsvg not built textproc/libxml -> devel/ccache -> 
devel/autoconf/2.69 -> devel/help2man -> archivers/xz -> devel/ccache
x11/gnome/libsecret not built textproc/intltool -> textproc/p5-XML-Parser -> 
devel/ccache -> devel/autoconf/2.69 -> devel/help2man -> archivers/xz -> 
devel/ccache
x11/gtk+3 not built devel/json-glib -> archivers/xz -> devel/ccache -> 
devel/autoconf/2.69 -> devel/help2man -> archivers/xz
x11/gtk+3,-guic not built devel/json-glib -> archivers/xz -> devel/ccache -> 
devel/autoconf/2.69 -> devel/help2man -> archivers/xz
x11/gtk+3,-main same as x11/gtk+3
x11/hicolor-icon-theme not built devel/ccache -> devel/autoconf/2.69 -> 
devel/help2man -> archivers/xz -> devel/ccache
x11/icontool not built textproc/p5-XML-Simple -> devel/ccache -> 
devel/autoconf/2.69 -> devel/help2man -> archivers/xz -> devel/ccache
x11/tk/8.5 not built lang/tcl/8.5 -> devel/ccache -> devel/autoconf/2.69 -> 
devel/help2man -> archivers/xz -> devel/ccache



-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



dpb and ccache

2017-11-04 Thread Andreas Kusalananda Kähäri
Hi,

I tried using dpb(1) with ccache today by adding USE_CCACHE=Yes and
pointing CCACHE_DIR to a sensible location owned by _pbuild:

USE_CCACHE=Yes
CCACHE_DIR=/extra/ccache

However, it seems as if this causes dpb to just quickly run though all
the ports in my list without buiding anything, or even checking the port
signatures.

I'm running dpb like this:

doas /usr/ports/infrastructure/bin/dpb -p4 -suUR -J0 -P "$HOME/packages.txt"

Is it possible to enable ccache at all for dpb?  I'm using dpb since it
makes it easy to keep ports up to date on -current, and I'd really want
to have the ability to run with ccache to speed up the rebuilding of some
of the larger ports.

Cheers,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: UPDATE: devel/astyle 1.15.1 => 3.0.1

2017-10-22 Thread Andreas Kusalananda Kähäri
On Sun, Oct 22, 2017 at 08:07:08PM +, Brian Callahan wrote:
> Hi ports --
> 
> While testing out the new games/cataclysm-dda port that was just
> (re-)posted, I noticed that the build was trying to use a program called
> astyle. Never heard of it, checked to see if we have it in ports (we do),
> pkg_add it, re-run cataclysm-dda's build system and... it complains that
> astyle is too old.
> 
> Yup, it's very old. So old that upstream no longer hosts the distfile for it
> any more. The CVS logs suggest our version is 15 years old. Nothing uses it
> and no one maintains it, so it likely just flew under the radar this whole
> time.
> 
> Here's an update to the newest version. The cataclysm-dda build system is
> happy with this version. I'll suggest in my mail about cataclysm-dda that
> this be added as a BDEP to it.
> 
> And, because I touched it, I'll maintain it.
> 
> OK?

astyle is a nice little C code formatter that I'm using from time to
time.  I would be happy to see this updated in ports.



-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: Question about updated stable ports: rebuilt packages?

2017-08-14 Thread Andreas Kusalananda Kähäri
On Mon, Aug 14, 2017 at 01:07:43PM +0200, Andreas Kusalananda Kähäri wrote:
> Hi,
> 
> Sorry, but I can't find this in the FAQ.  If a port is updated and
> committed on the stable OPENBSD_6_1 branch, new packages will not be
> built and uploaded to the package repositories, right?  At least this is
> the way it appears to be.

It was pointed out to me that this is actually explicitly mentioned in
the FAQ.  I was just looking in the wrong parts of it (the bits relating
directly to errata and following -stable, not the packages and ports
FAQ).

When serious bugs or security flaws are discovered in third party
software, they are fixed in the -stable branch of the ports
tree. Note that binary packages for -release and -stable are not
updated. In contrast to the base system, the -stable ports tree only
gets security backports for the latest release.

This means that all you need to do is make sure you check out the
correct branch of the ports tree, and build the desired software
from it. You can keep your tree up to date with CVS and subscribe
to the ports-changes mailing list to receive security announcements
related to software in the ports tree.

Thanks,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Question about updated stable ports: rebuilt packages?

2017-08-14 Thread Andreas Kusalananda Kähäri
Hi,

Sorry, but I can't find this in the FAQ.  If a port is updated and
committed on the stable OPENBSD_6_1 branch, new packages will not be
built and uploaded to the package repositories, right?  At least this is
the way it appears to be.


Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: OpenBSD Package Manager

2017-05-29 Thread Andreas Kusalananda Kähäri
On Mon, May 29, 2017 at 02:16:26PM -0400, H. Ishikawa wrote:
> Hello, I'd like to ask some specific areas of the pkg_add tools.
> 
> 1. Why Perl instead of C?
> Perl is comparatively slow, and I think this limits who can contribute
> to the source code. How many developers in OpenBSD are actively doing
> any review of the pkg_add tools code? Would there be any interest in
> porting pkgsrc or pkgng from another BSD, or rewriting it in C?

Perl is a perfect language for a package manager.  The bottleneck for
a package manager is 1) network and 2) disk, but never CPU.  C may be
faster for CPU-bound operations, but it will be exacly as slow as Perl
when fetching a package over the net or unpacking files on disk.

NetBSD's pkgsrc works on OpenBSD.  You're free to use it.

For the other two questions, as with all similar feature requests I've
seen here: The code is there, just fix it and submit a patch.

Cheers,
Kusalananda

> 2. Why no package database file?
> Other package managers like apt-get can fetch a single file that has
> all the package versions/info in it. When I update my packages on
> OpenBSD Current, it is a very slow process. Each package must be
> individually checked for updates, rather than comparing a list of
> what I have to a single list of the newest versions. This makes
> doing updates very painful and I avoid doing it sometimes.
> 
> 3. Why so many connections?
> When I tried to investigate why the update was so slow, I saw that
> pkg_add was making one HTTPS connection per package! Tools like
> wget from Linux can reuse a single connection for many downloads.
> Could this be added to pkg_add in OpenBSD?
> 
> Thank you.



Re: dpb runs three parallel processes on 2 CPUs

2017-04-18 Thread Andreas Kusalananda Kähäri
On Mon, Apr 17, 2017 at 08:04:51PM +, Christian Weisgerber wrote:
> On 2017-04-13, Andreas Kusalananda Kähäri <andreas.kah...@icm.uu.se> wrote:
> 
> > I have 2 CPUs, and dpb usually builds two ports at a time (or one port
> > in parallel).  However, while rebuilding llvm and ghc I observed that
> > ghc was being built as one job while llvm clearly used a parallel build
> > with two jobs at the same time.
> 
> Yes, that can happen.
> 
> > If dpb is allowed to do a parallel build of a package, does that mean
> > that it'll do that regardless of whether another build is running?
> 
> Yes.  The assumption is that the other build will finish soon, and
> that usually happens when building the full ports tree and on
> machines with four or more cores.

Ah.

> 
> > How should I interpret the '1*'?
> 
> The number of build slots occupied.
> Your machine has 2 build slots, occupied by ghc and 1*llvm.  If ghc
> finished ahead of llvm, you will see 2*llvm: llvm occupies both slots
> and no new jobs are started until it has finished.
> 
> Here's a snapshot from a setup of three machines times four cores:
> 
>   17 Apr 14:02:29 [93925] running for 00:26:31
>   2*lang/gcc/4.9(build) [9292] on amd64-1 17%
>   2*devel/boost(build) [71601] 33%
>   2*devel/cmake(build) [96529] 27%
>   2*graphics/cairo(build) [27962] on amd64-1 66%
>   lang/vala(build) [90156] on amd64-2 41%
>   www/libcroco(build) [26311] on amd64-2 39%
>   misc/gpsd(build) [14547] on amd64-2 21%
>   ~productivity/tryton/timesheet_cost(package) [5212] on amd64-2 27%
>   Hosts: amd64-1 [63886] amd64-2 [16323] localhost
>   I=636 B=194 Q=3986 T=5425 F=0 !=93

I was thinking dpb kept track of number of cores used in the build, but
it uses job slots, and some of the jobs may be parallel. Ok.

> 
> > This might have been the result of unlucky scheduling on dpb's part as
> > both ports take a really long time to build...
> 
> Exactly.
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 
> 

Thanks for the explanation!

Regards,
Kusalananda



Re: books/utp tiny MASTER_SITES correction

2017-04-14 Thread Andreas Kusalananda Kähäri
On Thu, Apr 13, 2017 at 07:23:41PM -0600, Anthony J. Bentley wrote:
> Stuart Henderson writes:
> > -HOMEPAGE = http://home.windstream.net/kollar/utp/
> > -
> 
> It's up for me...

Weird, I get timeouts in Chrome and "Connection reset by peer" from
Curl, both from home and from work.  But I can see that there's a recent
Google cache of the page (more recent than when I first started looking
for where the page had gone), so if it's actually up but difficult to
get to for just me, then I assume it's ok.

> 
> > -MASTER_SITES = http://ftp.ffii.org/pub/groff/contrib/documenta
> > tion/utp/ \
> > -   http://home.windstream.net/kollar/utp/
> > +MASTER_SITES = https://groff.ffii.org/groff/contrib/documentat
> > ion/utp/ \
> > +   ftp://ftp.ffii.org/pub/groff/contrib/documentation/utp/
> 
> ... but fixing the lone 404 in MASTER_SITES is welcome.
> 
> 

Good.


Cheers,
Kusalananda



Re: books/utp tiny MASTER_SITES correction

2017-04-13 Thread Andreas Kusalananda Kähäri
On Thu, Apr 13, 2017 at 05:01:16PM +0100, Stuart Henderson wrote:
> On 2017/04/13 17:53, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > It seems as if the books/utp port points one of its MASTER_SITES to
> > 
> > http://ftp.ffii.org/pub/groff/contrib/documentation/utp/
> > 
> > I believe that this ought to be
> > 
> > ftp://ftp.ffii.org/pub/groff/contrib/documentation/utp/
> > 
> > (s/http/ftp/)
> > 
> > It also looks as if the other (original) site, which is also the
> > HOMEPAGE,
> > 
> > http://home.windstream.net/kollar/utp/
> > 
> > has gone dead (and has been that way for some time).
> 
> That should be removed too then.
> 
> Can you find an http mirror anywhere? Generally better to have that
> rather than ftp as the first site in MASTER_SITES if possible.

I've spent a bit of time looking for a mirror, but everyone, even
O'Reilly, is linking to the off-line home.windstream.net site:

http://www.oreilly.com/openbook/utp/

The UTP revival project was started from the groff mailing list.  I'll
re-subscribe to it and ask...


Cheers,


> 
> 
> > 
> > I have included a patch that points the functioning MASTER_SITES to the
> > right place.
> > 
> > Cheers,
> > Kusalananda
> > 
> > 
> > P.s.  I was part of the team that helped revive the UTP book, doing some
> > of the proof-reading.  So I'm quite happy to see that OpenBSD has a port
> > for the thing.  :-)
> 
> > Index: Makefile
> > ===
> > RCS file: /cvs/OpenBSD-CVS/ports/books/utp/Makefile,v
> > retrieving revision 1.1.1.1
> > diff -u -p -r1.1.1.1 Makefile
> > --- Makefile19 Dec 2015 22:13:58 -  1.1.1.1
> > +++ Makefile13 Apr 2017 15:47:39 -
> > @@ -4,6 +4,7 @@ COMMENT =   comprehensive book on unix te
> >  
> >  V =1.0
> >  DISTNAME = utp-$V
> > +REVISION = 1
> >  
> >  CATEGORIES =   books
> >  
> > @@ -14,7 +15,7 @@ MAINTAINER =  Anthony J. Bentley  >  # CC-BY-1.0
> >  PERMIT_PACKAGE_CDROM = Yes
> >  
> > -MASTER_SITES = 
> > http://ftp.ffii.org/pub/groff/contrib/documentation/utp/ \
> > +MASTER_SITES = 
> > ftp://ftp.ffii.org/pub/groff/contrib/documentation/utp/ \
> > http://home.windstream.net/kollar/utp/
> >  
> >  EXTRACT_ONLY =
> 
> 



books/utp tiny MASTER_SITES correction

2017-04-13 Thread Andreas Kusalananda Kähäri
Hi,

It seems as if the books/utp port points one of its MASTER_SITES to

http://ftp.ffii.org/pub/groff/contrib/documentation/utp/

I believe that this ought to be

ftp://ftp.ffii.org/pub/groff/contrib/documentation/utp/

(s/http/ftp/)

It also looks as if the other (original) site, which is also the
HOMEPAGE,

http://home.windstream.net/kollar/utp/

has gone dead (and has been that way for some time).


I have included a patch that points the functioning MASTER_SITES to the
right place.

Cheers,
Kusalananda


P.s.  I was part of the team that helped revive the UTP book, doing some
of the proof-reading.  So I'm quite happy to see that OpenBSD has a port
for the thing.  :-)
Index: Makefile
===
RCS file: /cvs/OpenBSD-CVS/ports/books/utp/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile19 Dec 2015 22:13:58 -  1.1.1.1
+++ Makefile13 Apr 2017 15:47:39 -
@@ -4,6 +4,7 @@ COMMENT =   comprehensive book on unix te
 
 V =1.0
 DISTNAME = utp-$V
+REVISION = 1
 
 CATEGORIES =   books
 
@@ -14,7 +15,7 @@ MAINTAINER =  Anthony J. Bentley http://ftp.ffii.org/pub/groff/contrib/documentation/utp/ \
+MASTER_SITES = ftp://ftp.ffii.org/pub/groff/contrib/documentation/utp/ 
\
http://home.windstream.net/kollar/utp/
 
 EXTRACT_ONLY =


dpb runs three parallel processes on 2 CPUs

2017-04-13 Thread Andreas Kusalananda Kähäri
Hi,

I'm using dpb to keep the ports that are installed on my system up to
date.  With the recent bump in libc version, it meant that most ports
were rebulit.

I have 2 CPUs, and dpb usually builds two ports at a time (or one port
in parallel).  However, while rebuilding llvm and ghc I observed that
ghc was being built as one job while llvm clearly used a parallel build
with two jobs at the same time.

The output from dpb at the time of building looked like

13 Apr 13:06:04 [44683] running for 04:50:21
lang/ghc(build) [30186] 98%
1*devel/llvm(build) [64378] 84% frozen for 20s
Hosts: localhost
I=287 B=8 Q=18 T=106 F=0 !=1

but top showed two concurrent cc1plus processes belonging to the llvm
build (thoughout the build).

If dpb is allowed to do a parallel build of a package, does that mean
that it'll do that regardless of whether another build is running?  How
should I interpret the '1*'?

This might have been the result of unlucky scheduling on dpb's part as
both ports take a really long time to build...


Cheers,
Kusalananda



Re: Fixes to README of sysutils/anacron

2017-03-29 Thread Andreas Kusalananda Kähäri
On Wed, Mar 29, 2017 at 12:50:31PM +0200, Giovanni Bechis wrote:
> On 02/23/17 17:44, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > I was once the port maintainer of sysutils/anacron. I wrote the
> > pkg/README file and it's been bothering me ever since.
> > 
> > I have attached a patch that fixes it in such a way that
> > 
> > * Environtment variables are the same as in the default crontab for
> >   root.
> >
> ok
>  
> > * Absolute paths for /bin/sh are being used.
> > 
> > * No pipe to tee (why did I even have that?).

I recently found where the pipe-to-tee came from. It's in NetBSD's
port/package of anacron.

> > 
> ok
> 
> > * Suggest adding an @hourly job to run anacron in root's crontab.
> >
> this way some jobs could run more times than expected, I prefer current 
> behaviour 

After consideration, I agree.  I'm using a @reboot and a @daily job on
my machines, and it's sufficient.

>  
> > * Fixes @hourly and @reboot crontab suggestions so that it tests if the
> >   executable is present.  Is this a good idea? Maybe it's better to let
> >   it fail, so that it's spotted?
> > 
> better to let it fail
> 
> Diff attached. 
>  Cheers
>   Giovanni

The diff looks good to me.

Cheers,
Kusalananda


> Index: Makefile
> ===
> RCS file: /var/cvs/ports/sysutils/anacron/Makefile,v
> retrieving revision 1.16
> diff -u -p -r1.16 Makefile
> --- Makefile  11 Jan 2016 06:59:48 -  1.16
> +++ Makefile  29 Mar 2017 10:39:29 -
> @@ -6,7 +6,7 @@ V=2.5.3
>  DISTNAME=anacron.$V
>  PKGNAME= anacron-$V
>  CATEGORIES=  sysutils
> -REVISION=0
> +REVISION=1
>  
>  MAINTAINER=  Giovanni Bechis <giova...@openbsd.org>
>  
> Index: pkg/README
> ===
> RCS file: /var/cvs/ports/sysutils/anacron/pkg/README,v
> retrieving revision 1.3
> diff -u -p -r1.3 README
> --- pkg/README11 Jan 2016 06:59:48 -  1.3
> +++ pkg/README29 Mar 2017 10:47:14 -
> @@ -15,15 +15,15 @@ OpenBSD daily, weekly, and monthly scrip
>  -Cut
>  # ${SYSCONFDIR}/anacrontab example
>  SHELL=/bin/sh
> -PATH=${PREFIX}/sbin:${PREFIX}/bin:/sbin:/bin:/usr/sbin:/usr/bin
> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
> +HOME=/var/log
>  # format: period delay job-identifier command
> -1  5  cron.daily   sh /etc/daily 2>&1   | tee /var/log/daily.out
> -7  10 cron.weekly  sh /etc/weekly 2>&1  | tee /var/log/weekly.out
> -30 15 cron.monthly sh /etc/monthly 2>&1 | tee /var/log/monthly.out
> +1   5   cron.daily  /bin/sh /etc/daily
> +7   10  cron.weekly /bin/sh /etc/weekly
> +30  15  cron.monthly/bin/sh /etc/monthly
>  -Cut
>  
> -Comment out the invocation of these jobs in root's crontab.
> -
> +Comment out the invocation of the corresponding jobs in root's crontab.
>  If your machine is left running for more than 24h at a time, you
>  might also want to invoke anacron from an early morning cron job.
>  



devel/pylint fix for missing RUN_DEPENDS

2017-03-23 Thread Andreas Kusalananda Kähäri
Hi,

I noticed that devel/pylint needs devel/py-mccabe to run:

$ pylint
Traceback (most recent call last):
  File "/usr/local/bin/pylint", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
2994
, in 
@_call_aside
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
2980
, in _call_aside
f(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
3007
, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
658,
 in _build_master
ws.require(__requires__)
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
966,
 in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 
852,
 in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mccabe' distribution was not found and 
is r
equired by pylint

The same is true for the python3 flavor.

You will find a simple patch included that adds devel/py-mccabe to this
port's RUN_DEPENDS and bumps the revision.

Cheers,
Kusalananda

Index: Makefile
===
RCS file: /cvs/OpenBSD-CVS/ports/devel/pylint/Makefile,v
retrieving revision 1.22
diff -u -p -u -r1.22 Makefile
--- Makefile3 Jan 2017 19:19:49 -   1.22
+++ Makefile23 Mar 2017 17:01:49 -
@@ -8,7 +8,7 @@ DISTNAME=   pylint-${MODPY_EGG_VERSION}
 PKGNAME-main=  pylint-${MODPY_EGG_VERSION}
 PKGNAME-gui=   pylint-gui-${MODPY_EGG_VERSION}
 CATEGORIES=devel
-REVISION-main= 2
+REVISION-main= 3
 
 HOMEPAGE=  http://www.pylint.org/
 
@@ -26,6 +26,7 @@ MODPY_SETUPTOOLS =Yes
 
 RUN_DEPENDS=   devel/py-astroid${MODPY_FLAVOR} \
devel/py-isort${MODPY_FLAVOR} \
+   devel/py-mccabe${MODPY_FLAVOR} \
devel/py-six${MODPY_FLAVOR}
 RUN_DEPENDS-gui=   ${MODPY_TKINTER_DEPENDS} \
devel/pylint${MODPY_FLAVOR}=${MODPY_EGG_VERSION}


signature.asc
Description: PGP signature


shells/{scsh,yash} lacks @shell marker in PLIST

2017-02-24 Thread Andreas Kusalananda Kähäri
Hi,

I just noticed that I didn't get a new entry in /etc/shells when I
installed the shells/yash port.

The PLIST lacks the line

@shell bin/yash

Additionally, the shells/scsh port is another shell port that does not
add an entry to /etc/shells

I don't know if this is intentional or not.

Regards,
Kusalananda


signature.asc
Description: PGP signature


Re: Fixes to README of sysutils/anacron

2017-02-24 Thread Andreas Kusalananda Kähäri
On Fri, Feb 24, 2017 at 03:07:36PM +0100, Giovanni Bechis wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 02/23/17 17:44, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > I was once the port maintainer of sysutils/anacron. I wrote the
> > pkg/README file and it's been bothering me ever since.
> > 
> > I have attached a patch that fixes it in such a way that
> > 
> > * Environtment variables are the same as in the default crontab for
> >   root.
> > 
> /usr/local/{s,}bin is not in crontab(5) default path

Exactly, that's why the patch removes these paths.

> 
> > * Absolute paths for /bin/sh are being used.
> > 
> > * No pipe to tee (why did I even have that?).
> > 
> > * Suggest adding an @hourly job to run anacron in root's crontab.
> > 
> why is this needed ?

If the cron jobs are commented out of the crontab of root and instead
handled by anacron, anacron will have to be invoked at least daily.
Invoking it hourly is a good solution for a system that is running
during irregular hours.  This will ensure that anacron is run at least
once every day, even if the machine stays up >24h (in which case a
@reboot job is not enough) or if the machine isn't running at midnight
(in whuch case a @daily job wouldn't be run).  There is no resource
drain in doing this as anacron will just skip all jobs that won't be
needing running.

> 
> > * Fixes @hourly and @reboot crontab suggestions so that it tests if the
> >   executable is present.  Is this a good idea? Maybe it's better to let
> >   it fail, so that it's spotted?
> > 
> I think it is better to let it fail.

Then remove the "test -x ... &&"

> 
> > Also:
> > 
> > * Bump revision in Makefile.
> > 
> > 
> > With kind regards,
> > Kusalananda
> > 
> Cheers
>  Giovanni


signature.asc
Description: PGP signature


Fixes to README of sysutils/anacron

2017-02-23 Thread Andreas Kusalananda Kähäri
Hi,

I was once the port maintainer of sysutils/anacron. I wrote the
pkg/README file and it's been bothering me ever since.

I have attached a patch that fixes it in such a way that

* Environtment variables are the same as in the default crontab for
  root.

* Absolute paths for /bin/sh are being used.

* No pipe to tee (why did I even have that?).

* Suggest adding an @hourly job to run anacron in root's crontab.

* Fixes @hourly and @reboot crontab suggestions so that it tests if the
  executable is present.  Is this a good idea? Maybe it's better to let
  it fail, so that it's spotted?

Also:

* Bump revision in Makefile.


With kind regards,
Kusalananda

Index: Makefile
===
RCS file: /cvs/ports/sysutils/anacron/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- Makefile11 Jan 2016 06:59:48 -  1.16
+++ Makefile23 Feb 2017 16:35:08 -
@@ -6,7 +6,7 @@ V=  2.5.3
 DISTNAME=  anacron.$V
 PKGNAME=   anacron-$V
 CATEGORIES=sysutils
-REVISION=  0
+REVISION=  1
 
 MAINTAINER=Giovanni Bechis 
 
Index: pkg/README
===
RCS file: /cvs/ports/sysutils/anacron/pkg/README,v
retrieving revision 1.3
diff -u -p -u -r1.3 README
--- pkg/README  11 Jan 2016 06:59:48 -  1.3
+++ pkg/README  23 Feb 2017 16:35:08 -
@@ -15,17 +15,19 @@ OpenBSD daily, weekly, and monthly scrip
 -Cut
 # ${SYSCONFDIR}/anacrontab example
 SHELL=/bin/sh
-PATH=${PREFIX}/sbin:${PREFIX}/bin:/sbin:/bin:/usr/sbin:/usr/bin
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+HOME=/var/log
 # format: period delay job-identifier command
-1  5  cron.daily   sh /etc/daily 2>&1   | tee /var/log/daily.out
-7  10 cron.weekly  sh /etc/weekly 2>&1  | tee /var/log/weekly.out
-30 15 cron.monthly sh /etc/monthly 2>&1 | tee /var/log/monthly.out
+1   5   cron.daily  /bin/sh /etc/daily
+7   10  cron.weekly /bin/sh /etc/weekly
+30  15  cron.monthly/bin/sh /etc/monthly
 -Cut
 
-Comment out the invocation of these jobs in root's crontab.
+Comment out the invocation of the corresponding jobs in root's crontab
+and invoke anacron as a hourly job:
 
-If your machine is left running for more than 24h at a time, you
-might also want to invoke anacron from an early morning cron job.
+@hourly test -x ${PREFIX}/sbin/anacron && ${PREFIX}/sbin/anacron -s
 
 To run anacron(8) at boot time, add the following to root's crontab(5):
-@reboot${PREFIX}/sbin/anacron -ds
+
+@reboot test -x ${PREFIX}/sbin/anacron && ${PREFIX}/sbin/anacron -s


signature.asc
Description: PGP signature


sysutils/stow: fix for 'make test'

2016-12-29 Thread Andreas Kusalananda Kähäri
Hi,

I noticed that "make test" fails for the sysutils/stow port that I'm the
maintainer of.  The failure is due to not finding IO::Scalar which is
part of the devel/p5-IO-stringy port.

This tiny patch fixes that by adding devel/p5-IO-stringy to TEST_DEPENDS:

Index: Makefile
===
RCS file: /cvs/ports/sysutils/stow/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- Makefile10 Nov 2015 09:13:50 -  1.11
+++ Makefile29 Dec 2016 08:49:43 -
@@ -17,6 +17,6 @@ MASTER_SITES= ${MASTER_SITE_GNU:=stow/}
 CONFIGURE_STYLE=gnu
 USE_GMAKE=Yes
 
-TEST_DEPENDS=  devel/p5-Test-Output
+TEST_DEPENDS=  devel/p5-Test-Output devel/p5-IO-stringy
 
 .include 


Cheers,
Andreas


signature.asc
Description: PGP signature


Re: "pkg_info -S" can't get update signature, "unsigned package"

2016-10-17 Thread Andreas Kusalananda Kähäri
On Mon, Oct 17, 2016 at 12:05:50PM +0200, Marc Espie wrote:
> On Mon, Oct 17, 2016 at 08:49:43AM +0200, Andreas Kusalananda Kähäri wrote:
> > On Sun, Oct 16, 2016 at 09:37:50AM +0100, Stuart Henderson wrote:
> > > On 2016/10/16 10:27, Andreas Kusalananda Kähäri wrote:
> > > > Hi,
> > > > 
> > > > "pkg_info -S" used to show the "update signature" for a package, i.e.
> > > > the "unique tag showing the package name, and the version number of
> > > > every run time dependency and shared library used to build this
> > > > package".
> > > > 
> > > > Since recently, this gives me an error due to the packages not being
> > > > signed:
> > > > 
> > > > $ pkg_info -S /usr/ports/packages/amd64/all/ccache-3.3.2.tgz
> > > > Error from file:/usr/ports/packages/amd64/all/
> > > > unsigned package
> > > > 
> > > > This is regardless of the whether the package is built recently or a
> > > > long time ago.
> > > > 
> > > > Do I need to sign my own packages to be able to get the update signature
> > > > out of them?!
> > > 
> > > No, you can use "-D unsigned".
> > > 
> > 
> > 
> > Ah! Good! That was documented for pkg_add, but not for pkg_info AFAIK,
> > but it works. Thanks.
> > 
> This is documented in current.html though. Should be your first source of
> information when stuff doesn't work in current.

You mean "2016/09/27 - more secure package and firmware signatures"? I
didn't think it would affect "pkg_info -S package.tgz" as it doesn't
install anything.


> 
> Documentation is somewhat in flux.  There's still duplicated information
> throughout pkg_add(1)/pkg_info(1)/pkg_sign(1)...
> 
> I've tried making /usr/ports/packages/amd64/all a "trusted" 
> source automatically, but it's surprisingly difficult (I have ports a
> symlink elsewhere, and figuring out where we live is somewhat annoying)
> 

I'm aware that things are in flux.  I'm happy that my little script is
working again, and I'm sure all the docs will be updated in due time.

Thanks,
Andreas


-- 
Andreas Kusalananda Kähäri
Bioinformatics Developer
NBIS, Uppsala University
http://www.nbis.se/



Re: "pkg_info -S" can't get update signature, "unsigned package"

2016-10-17 Thread Andreas Kusalananda Kähäri
On Sun, Oct 16, 2016 at 09:37:50AM +0100, Stuart Henderson wrote:
> On 2016/10/16 10:27, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > "pkg_info -S" used to show the "update signature" for a package, i.e.
> > the "unique tag showing the package name, and the version number of
> > every run time dependency and shared library used to build this
> > package".
> > 
> > Since recently, this gives me an error due to the packages not being
> > signed:
> > 
> > $ pkg_info -S /usr/ports/packages/amd64/all/ccache-3.3.2.tgz
> > Error from file:/usr/ports/packages/amd64/all/
> > unsigned package
> > 
> > This is regardless of the whether the package is built recently or a
> > long time ago.
> > 
> > Do I need to sign my own packages to be able to get the update signature
> > out of them?!
> 
> No, you can use "-D unsigned".
> 


Ah! Good! That was documented for pkg_add, but not for pkg_info AFAIK,
but it works. Thanks.


-- 
Andreas Kusalananda Kähäri
Bioinformatics Developer
NBIS, Uppsala University
http://www.nbis.se/


signature.asc
Description: PGP signature


"pkg_info -S" can't get update signature, "unsigned package"

2016-10-16 Thread Andreas Kusalananda Kähäri
Hi,

"pkg_info -S" used to show the "update signature" for a package, i.e.
the "unique tag showing the package name, and the version number of
every run time dependency and shared library used to build this
package".

Since recently, this gives me an error due to the packages not being
signed:

$ pkg_info -S /usr/ports/packages/amd64/all/ccache-3.3.2.tgz
Error from file:/usr/ports/packages/amd64/all/
unsigned package

This is regardless of the whether the package is built recently or a
long time ago.

Do I need to sign my own packages to be able to get the update signature
out of them?!


Cheers,
Andreas

-- 
Andreas Kusalananda Kähäri
Bioinformatics Developer
NBIS, Uppsala University
http://www.nbis.se/


signature.asc
Description: PGP signature


Re: W^X issues running valgrind

2016-10-07 Thread Andreas Kusalananda Kähäri
On Thu, Oct 06, 2016 at 03:42:54PM +0200, Andreas Kusalananda Kähäri wrote:
> On Thu, Oct 06, 2016 at 12:57:43PM +0100, Stuart Henderson wrote:
> > On 2016/10/06 13:23, David Coppa wrote:
> > > On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri
> > > <andreas.kah...@nbis.se> wrote:
> > > > Hi,
> > > >
> > > > Let me know if this should be on ports rather than here.
> > > >
> > > > I'm following OpenBSD current on amd64, updating the system a couple of
> > > > times a week, and I'm using valgrind from ports to check a C program for
> > > > memory leaks.  However, since recently (sorry, can't specify closer,
> > > > within the last couple of months) I get a W^X violation when I try it.
> > > 
> > > devel/valgrind is missing the USE_WXNEEDED=Yes marker.
> > 
> > valgrind works by preloading an .so file and wrapping library functions
> > to override with its own versions.
> > 
> > You will at least need to link the program under test with -Wl,-z,wxneeded
> > but you might need to do more than this.
> > 
> 
> Adding USE_WXNEEDED=Yes to the valgrind port cuts down the error from
> valgrind to just
> 
> valgrind: mmap(0x108000, 4550656) failed in UME with error 12 (Cannot
> allocate memory).
> 
> ... and a notification of a W^X violation from the kernel as before.
> Adding "-Wl,-z,wxneeded" when linking my application makes no
> difference.  I'm still trying to run it under /home with wxneeded added
> to the mount flags as before.
> 
> Is there anything else I could try?

Adding wxallowed to the mount options of every single partition and
adding -Wl,-z,wxneeded to every step of the compilation doesn't help
either.

It feels as if I'm missing something basic here.

Andreas


-- 
Andreas Kusalananda Kähäri
Bioinformatics Developer
NBIS, Uppsala University
http://www.nbis.se/


signature.asc
Description: PGP signature


Re: W^X issues running valgrind

2016-10-06 Thread Andreas Kusalananda Kähäri
On Thu, Oct 06, 2016 at 12:57:43PM +0100, Stuart Henderson wrote:
> On 2016/10/06 13:23, David Coppa wrote:
> > On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri
> > <andreas.kah...@nbis.se> wrote:
> > > Hi,
> > >
> > > Let me know if this should be on ports rather than here.
> > >
> > > I'm following OpenBSD current on amd64, updating the system a couple of
> > > times a week, and I'm using valgrind from ports to check a C program for
> > > memory leaks.  However, since recently (sorry, can't specify closer,
> > > within the last couple of months) I get a W^X violation when I try it.
> > 
> > devel/valgrind is missing the USE_WXNEEDED=Yes marker.
> 
> valgrind works by preloading an .so file and wrapping library functions
> to override with its own versions.
> 
> You will at least need to link the program under test with -Wl,-z,wxneeded
> but you might need to do more than this.
> 

Adding USE_WXNEEDED=Yes to the valgrind port cuts down the error from
valgrind to just

valgrind: mmap(0x108000, 4550656) failed in UME with error 12 (Cannot
allocate memory).

... and a notification of a W^X violation from the kernel as before.
Adding "-Wl,-z,wxneeded" when linking my application makes no
difference.  I'm still trying to run it under /home with wxneeded added
to the mount flags as before.

Is there anything else I could try?

-- 
Andreas Kusalananda Kähäri
Bioinformatics Developer
NBIS, Uppsala University
http://www.nbis.se/


signature.asc
Description: PGP signature


[update] math/mcl 09-308 --> 14-137 (and me as maintainer)

2016-04-19 Thread Andreas Kusalananda Kähäri
Hi,

I believe I created this port in the distant past, and I'm taking over
maintainership (?) of it again.

math/mcl (a clustering algorithm for graphs) has not been updated in a
long while, so here's a diff that brings it up to date with the most
recent release of mcl.

The diff is straight forward. The port installs one scripts that uses
bash, but that's the only new dependency that I can find (that bash
script also need a patch as it picks up perl from /usr/local).

It compiles and runs.

The diff and the patch are attached.

Cheers,
Andreas


-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer (NBIS)
Uppsala University, Uppsala, Sweden
NBIS: http://nbis.se OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF

? patches
Index: Makefile
===
RCS file: /cvs/ports/math/mcl/Makefile,v
retrieving revision 1.12
diff -u -p -u -r1.12 Makefile
--- Makefile11 Mar 2013 11:23:55 -  1.12
+++ Makefile19 Apr 2016 13:39:07 -
@@ -2,17 +2,21 @@
 
 COMMENT=   clustering algorithm for graphs
 
-V= 09-308
+V= 14-137
 DISTNAME=  mcl-${V}
 PKGNAME=   mcl-${V:S,-,_,}
 CATEGORIES=math
 
 HOMEPAGE=  http://micans.org/mcl/
 
-# GPLv2
+MAINTAINER=Andreas Kusalananda Kahari <andreas.kah...@icm.uu.se>
+
+# GPLv3
 PERMIT_PACKAGE_CDROM=  Yes
 
 MASTER_SITES=  ${HOMEPAGE}/src/
+
+RUN_DEPENDS=   shells/bash
 
 WANTLIB=   c m pthread
 
Index: distinfo
===
RCS file: /cvs/ports/math/mcl/distinfo,v
retrieving revision 1.11
diff -u -p -u -r1.11 distinfo
--- distinfo18 Jan 2015 03:14:27 -  1.11
+++ distinfo19 Apr 2016 13:39:07 -
@@ -1,2 +1,2 @@
-SHA256 (mcl-09-308.tar.gz) = gNV73uAtWFWsIf7ql6ko/z1DLRXtKv8CubvohVHUBxI=
-SIZE (mcl-09-308.tar.gz) = 2785872
+SHA256 (mcl-14-137.tar.gz) = tXhol6ioyhGes1WlYwgGpNpy6oQkPbqFsZqG8UdXtJc=
+SIZE (mcl-14-137.tar.gz) = 3035491
Index: pkg/PLIST
===
RCS file: /cvs/ports/math/mcl/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -u -r1.8 PLIST
--- pkg/PLIST   23 Dec 2009 22:08:58 -  1.8
+++ pkg/PLIST   19 Apr 2016 13:39:07 -
@@ -1,6 +1,7 @@
 @comment $OpenBSD: PLIST,v 1.8 2009/12/23 22:08:58 jasper Exp $
 @bin bin/clm
 @bin bin/clmformat
+bin/clxdo
 @bin bin/mcl
 @bin bin/mclcm
 bin/mclpipeline
@@ -19,8 +20,10 @@ bin/mclpipeline
 @man man/man1/clmformat.1
 @man man/man1/clmimac.1
 @man man/man1/clminfo.1
+@man man/man1/clminfo2.1
 @man man/man1/clmmate.1
 @man man/man1/clmmeet.1
+@man man/man1/clmoptics.1
 @man man/man1/clmorder.1
 @man man/man1/clmresidue.1
 @man man/man1/clmvol.1
@@ -36,6 +39,7 @@ bin/mclpipeline
 @man man/man1/mcxctty.1
 @man man/man1/mcxdiameter.1
 @man man/man1/mcxdump.1
+@man man/man1/mcxerdos.1
 @man man/man1/mcxi.1
 @man man/man1/mcxload.1
 @man man/man1/mcxmap.1
@@ -43,6 +47,7 @@ bin/mclpipeline
 @man man/man1/mcxrand.1
 @man man/man1/mcxsubs.1
 @man man/man5/clmprotocols.5
+@man man/man5/clmprotocols2.5
 @man man/man5/mcxio.5
 @man man/man7/mclfamily.7
 @man man/man7/mclfaq.7
@@ -61,14 +66,20 @@ share/doc/mcl/clmimac.html
 share/doc/mcl/clmimac.ps
 share/doc/mcl/clminfo.html
 share/doc/mcl/clminfo.ps
+share/doc/mcl/clminfo2.html
+share/doc/mcl/clminfo2.ps
 share/doc/mcl/clmmate.html
 share/doc/mcl/clmmate.ps
 share/doc/mcl/clmmeet.html
 share/doc/mcl/clmmeet.ps
+share/doc/mcl/clmoptics.html
+share/doc/mcl/clmoptics.ps
 share/doc/mcl/clmorder.html
 share/doc/mcl/clmorder.ps
 share/doc/mcl/clmprotocols.html
 share/doc/mcl/clmprotocols.ps
+share/doc/mcl/clmprotocols2.html
+share/doc/mcl/clmprotocols2.ps
 share/doc/mcl/clmresidue.html
 share/doc/mcl/clmresidue.ps
 share/doc/mcl/clmvol.html
@@ -107,6 +118,8 @@ share/doc/mcl/mcxdiameter.html
 share/doc/mcl/mcxdiameter.ps
 share/doc/mcl/mcxdump.html
 share/doc/mcl/mcxdump.ps
+share/doc/mcl/mcxerdos.html
+share/doc/mcl/mcxerdos.ps
 share/doc/mcl/mcxi.html
 share/doc/mcl/mcxi.ps
 share/doc/mcl/mcxio.html
@@ -149,6 +162,7 @@ share/examples/mcl/friends
 share/examples/mcl/fznyy.mci
 share/examples/mcl/fznyy.tab
 share/examples/mcl/honey.mci
+share/examples/mcl/infinity.mci
 share/examples/mcl/lattice.mci
 share/examples/mcl/make-falkner.pl
 share/examples/mcl/matula.mci
$OpenBSD$
--- scripts/clxdo.orig  Tue Apr 19 15:35:30 2016
+++ scripts/clxdo   Tue Apr 19 15:36:28 2016
@@ -83,7 +83,7 @@ clm vol -nff-fac $fac $@ | mcxsubs 'val(gt(1)), out(-)
 require_num 1 "+"
 mx=$2
 mcxdump -imx $mx --no-values --dump-lines -o - \
-|  /usr/local/bin/perl -ane '$ct{@F-1}++; END { print map { "$_ $ct{$_}\n" } 
sort { $a <=> $b } keys %ct; }'
+|  perl -ane '$ct{@F-1}++; END { print map { "$_ $ct{$_}\n" } sort { $a <=> $b 
} keys %ct; }'
   ;;
 
 
@@ -116,7 +116,7 @@ export CLXDO_VAL1=$2
 shift 2
 for mx in $@; do
   mcxdump -imx $mx --no-

Adding PARALLEL_BUILD=No to a few ports

2016-03-19 Thread Andreas Kusalananda Kähäri
Hi,

I'm building my ports with MAKE_JOBS=4, and I noticed that a few of the
ports were failing.

* devel/boehm-gcfailed sometimes (can't find "libgc.la" towards the
end of the build).

* lang/ruby/1.8 failed consistently (can't find "miniruby" at
beginning of the build).

* editors/vim   failed consistently (can't find "ex.1" and other
manuals when packaging).  I tried the "huge no_x11"
and "no_x11" flavours.

* lang/ocamlfailed consistently ("Unbound module Pervasives"
early in the build, but the build doesn't halt until
much later).

* security/nss  failed inconsistently, at different stages of the
build.

I added PARALLEL_BUILD=No to these ports and now they build fine.

Patches included.

Cheers,

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF

Index: Makefile
===
RCS file: /cvs/ports/devel/boehm-gc/Makefile,v
retrieving revision 1.62
diff -u -p -u -r1.62 Makefile
--- Makefile11 Mar 2016 20:28:23 -  1.62
+++ Makefile16 Mar 2016 13:27:54 -
@@ -41,6 +41,8 @@ MAKE_ENV= CP="cp" \
INSTALL_DATA="${INSTALL_DATA}" \
INSTALL_MAN="${INSTALL_MAN}"
 
+PARALLEL_BUILD=No
+
 CONFIGURE_STYLE= gnu
 
 CONFIGURE_ARGS= --with-libatomic-ops=no \
Index: Makefile
===
RCS file: /cvs/ports/security/nss/Makefile,v
retrieving revision 1.61
diff -u -p -u -r1.61 Makefile
--- Makefile10 Mar 2016 19:29:25 -  1.61
+++ Makefile16 Mar 2016 18:46:25 -
@@ -37,6 +37,8 @@ MAKE_ENV= BUILD_OPT=1 \
 
 USE_GMAKE= Yes
 
+PARALLEL_BUILD=No
+
 WRKSRC=${WRKDIST}/nss
 NSSDIST=   ${WRKDIST}/dist
 NSSOBJ=${NSSDIST}/OpenBSD`uname -r`${OBJ64}_OPT.OBJ
Index: Makefile
===
RCS file: /cvs/ports/lang/ocaml/Makefile,v
retrieving revision 1.70
diff -u -p -u -r1.70 Makefile
--- Makefile29 Feb 2016 23:42:51 -  1.70
+++ Makefile16 Mar 2016 15:19:29 -
@@ -41,6 +41,8 @@ CONFIGURE_ENV+=OPENBSD_LOCALBASE="${LOCA
 
 USE_GMAKE= Yes
 
+PARALLEL_BUILD=No
+
 BUILD_DEPENDS +=   devel/gdb
 RUN_DEPENDS-graphics +=lang/ocaml
 WANTLIB-main = c curses iberty m pthread z
Index: Makefile
===
RCS file: /cvs/ports/lang/ruby/1.8/Makefile,v
retrieving revision 1.38
diff -u -p -u -r1.38 Makefile
--- Makefile29 Feb 2016 20:46:53 -  1.38
+++ Makefile16 Mar 2016 13:20:31 -
@@ -23,6 +23,8 @@ PKGSPEC-main= ruby->=1.8,<1.9
 REVISION-main= 5
 REVISION-ri_docs=  0
 
+PARALLEL_BUILD=No
+
 CONFIGURE_ARGS=--program-suffix=18 \
--enable-ipv6 \
--with-dbm-type=bogus \
Index: Makefile
===
RCS file: /cvs/ports/editors/vim/Makefile,v
retrieving revision 1.146
diff -u -p -u -r1.146 Makefile
--- Makefile9 Mar 2016 18:20:02 -   1.146
+++ Makefile16 Mar 2016 13:50:40 -
@@ -27,6 +27,8 @@ FULLPKGPATH-lang= ${PKGPATH},-lang
 FLAVORS=   huge gtk2 athena motif no_x11 lua perl python python3 ruby
 FLAVOR?=   gtk2
 
+PARALLEL_BUILD=No
+
 .include 
 .if ${FLAVOR:Mno_x11}
 BUILD_PACKAGES := ${BUILD_PACKAGES:N-lang}


signature.asc
Description: PGP signature


Re: Adding PARALLEL_BUILD=No to a few ports

2016-03-19 Thread Andreas Kusalananda Kähäri
On Wed, Mar 16, 2016 at 07:48:53PM +0100, Andreas Kusalananda K�h�ri wrote:
> Hi,
> 
> I'm building my ports with MAKE_JOBS=4, and I noticed that a few of the
> ports were failing.

I should point out the obvious, that these are not "my" ports in any
maintainer sort of way and that these were the ports that failed to
build when I re-built the very small subset of ports that I'm using on
my machine.

It's currently too late in the evening for me to try to figure out
whether it's the ports framework that makes them fail, or their own
makefiles.

Andreas

> 
> * devel/boehm-gcfailed sometimes (can't find "libgc.la" towards the
> end of the build).
> 
> * lang/ruby/1.8 failed consistently (can't find "miniruby" at
> beginning of the build).
> 
> * editors/vim   failed consistently (can't find "ex.1" and other
> manuals when packaging).  I tried the "huge no_x11"
> and "no_x11" flavours.
> 
> * lang/ocamlfailed consistently ("Unbound module Pervasives"
> early in the build, but the build doesn't halt until
> much later).
> 
> * security/nss  failed inconsistently, at different stages of the
>     build.
> 
> I added PARALLEL_BUILD=No to these ports and now they build fine.
> 
> Patches included.
> 
> Cheers,
> 
> -- 
> Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
> OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF
> 

> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/boehm-gc/Makefile,v
> retrieving revision 1.62
> diff -u -p -u -r1.62 Makefile
> --- Makefile  11 Mar 2016 20:28:23 -  1.62
> +++ Makefile  16 Mar 2016 13:27:54 -
> @@ -41,6 +41,8 @@ MAKE_ENV=   CP="cp" \
>   INSTALL_DATA="${INSTALL_DATA}" \
>   INSTALL_MAN="${INSTALL_MAN}"
>  
> +PARALLEL_BUILD=  No
> +
>  CONFIGURE_STYLE= gnu
>  
>  CONFIGURE_ARGS= --with-libatomic-ops=no \

> Index: Makefile
> ===
> RCS file: /cvs/ports/security/nss/Makefile,v
> retrieving revision 1.61
> diff -u -p -u -r1.61 Makefile
> --- Makefile  10 Mar 2016 19:29:25 -  1.61
> +++ Makefile  16 Mar 2016 18:46:25 -
> @@ -37,6 +37,8 @@ MAKE_ENV=   BUILD_OPT=1 \
>  
>  USE_GMAKE=   Yes
>  
> +PARALLEL_BUILD=  No
> +
>  WRKSRC=  ${WRKDIST}/nss
>  NSSDIST= ${WRKDIST}/dist
>  NSSOBJ=  ${NSSDIST}/OpenBSD`uname -r`${OBJ64}_OPT.OBJ

> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ocaml/Makefile,v
> retrieving revision 1.70
> diff -u -p -u -r1.70 Makefile
> --- Makefile  29 Feb 2016 23:42:51 -  1.70
> +++ Makefile  16 Mar 2016 15:19:29 -
> @@ -41,6 +41,8 @@ CONFIGURE_ENV+=OPENBSD_LOCALBASE="${LOCA
>  
>  USE_GMAKE=   Yes
>  
> +PARALLEL_BUILD=  No
> +
>  BUILD_DEPENDS += devel/gdb
>  RUN_DEPENDS-graphics +=  lang/ocaml
>  WANTLIB-main =   c curses iberty m pthread z

> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ruby/1.8/Makefile,v
> retrieving revision 1.38
> diff -u -p -u -r1.38 Makefile
> --- Makefile  29 Feb 2016 20:46:53 -  1.38
> +++ Makefile  16 Mar 2016 13:20:31 -
> @@ -23,6 +23,8 @@ PKGSPEC-main=   ruby->=1.8,<1.9
>  REVISION-main=   5
>  REVISION-ri_docs=0
>  
> +PARALLEL_BUILD=  No
> +
>  CONFIGURE_ARGS=  --program-suffix=18 \
>   --enable-ipv6 \
>   --with-dbm-type=bogus \

> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/vim/Makefile,v
> retrieving revision 1.146
> diff -u -p -u -r1.146 Makefile
> --- Makefile  9 Mar 2016 18:20:02 -   1.146
> +++ Makefile  16 Mar 2016 13:50:40 -
> @@ -27,6 +27,8 @@ FULLPKGPATH-lang= ${PKGPATH},-lang
>  FLAVORS= huge gtk2 athena motif no_x11 lua perl python python3 ruby
>  FLAVOR?= gtk2
>  
> +PARALLEL_BUILD=  No
> +
>  .include 
>  .if ${FLAVOR:Mno_x11}
>  BUILD_PACKAGES := ${BUILD_PACKAGES:N-lang}





signature.asc
Description: PGP signature


Re: missing lib dep for devel/iso-codes

2016-03-10 Thread Andreas Kusalananda Kähäri
On Thu, Mar 10, 2016 at 11:01:58AM +, Stuart Henderson wrote:
> On 2016/03/10 02:37, Michael McConville wrote:
> > It looks like devel/iso-codes needs libintl, although make
> > lib-depends-check doesn't pick it up. See the build failure below.
> 
> This doesn't make sense:
> 
> > /usr/local/bin/msgfmt --verbose --check -o da.mo da.po
> > 488 translated messages.
> > /usr/local/bin/msgfmt --verbose --check -o vi.mo vi.po
> > /usr/local/bin/msgfmt: can't load library 'libintl.so.6.0'
> > Makefile:462: recipe for target 'vi.mo' failed
> 
> The message is generated by msgfmt which is part of gettext-tools,
> but gettext-tools *does* depend on devel/gettext (which contains
> libintl).
> 
> If this is something other than a local problem, it's definitely
> not in iso-codes.
> 

I've seen these sorts of things with dpb too, build tools/libs suddenly
disappearing.  Sometimes the build will succeed if it's run again.  I'm
wondering if turning off junking ("-J 0") would help?

Cheers,

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF




dpb: Problem building ports whose RUN_DEPENDS have unmet BUILD_DEPENDS dependencies

2016-03-10 Thread Andreas Kusalananda Kähäri
Hi,

Quite often, dpb fails to build ports because one or several
BUILD_DEPENDS for some of the port's RUN_DEPENDS are not installed.
Sometimes, this happens after I run "pkg_delete -a", and sometimes I
think it's due to the "junking" of unneeded ports during the build (but
I'm not sure).

This happened just now, for example.  The llvm port is definitely up to
date, so py-sphinx shouldn't need to be installed, but chromium fails to
build anyway:

$ less /usr/ports/logs/amd64/packages/chromium-49.0.2623.75p0.log
>>> Building on localhost under www/chromium
 BDEPENDS = 
[devel/yasm;archivers/xz;shells/bash;lang/python/2.7;devel/gconf2;devel/gperf;lang/gcc/4.9,-c++;devel/llvm;security/nss;sysutils/flock;x11/gtk+2;x11/gnome/libgnome-keyring;devel/ninja;devel/libexecinfo;print/cups,-libs;sysutils/pciutils;textproc/libxslt;lang/gcc/4.9,-libs;devel/bison;archivers/bzip2]
 DIST = [www/chromium:chromium-49.0.2623.75.tar.xz]
 FULLPKGNAME = chromium-49.0.2623.75p0
 RDEPENDS = 
[x11/gtk+2;lang/gcc/4.9,-libs;textproc/libxslt;x11/gtk+3,-guic;security/nss;print/cups,-libs;devel/gconf2;graphics/libexif;devel/desktop-file-utils;devel/libexecinfo;devel/xdg-utils;fonts/noto/fonts;x11/gnome/libgnome-keyring]
>>> Running clean in www/chromium at 1457594571
===> www/chromium
===>  Cleaning for chromium-49.0.2623.75p0
[...]
===> Returning to build of chromium-49.0.2623.75p0
===> chromium-49.0.2623.75p0 depends on: g++->=4.9,<4.10 -> g++-4.9.3p3
===>  Verifying update for llvm->=3.7.1 in devel/llvm
===> Updating for llvm-3.7.1p0
===> llvm-3.7.1p0 depends on: py-sphinx-* - not found
Dependency check failed
*** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:2114 
'/srv/ports/pobj/llvm-3.7.1/.dep-textproc-py-sphinx')
*** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:1987 
'/srv/ports/update/amd64/llvm-3.7.1p0')
*** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:2482 
'subupdate')
*** Error 1 in www/chromium (/srv/ports/infrastructure/mk/bsd.port.mk:2114 
'/srv/ports/pobj/chromium-49.0.2623.75/.dep-STEM-ge-3.7.1-devel-llvm')
*** Error 1 in www/chromium (/srv/ports/infrastructure/mk/bsd.port.mk:2482 
'prepare')
===> Exiting www/chromium with an error
*** Error 1 in /srv/ports (infrastructure/mk/bsd.port.subdir.mk:147 
'show-prepare-results')
(Junk lock released for localhost at 1457594593)
Error: job failed 256


The ffmpeg port build failed in a similar way for exactly the same reason.


Cheers,

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF




Mutt barfs on sendfd when verifying S/MIME (pledge)

2016-01-26 Thread Andreas Kusalananda Kähäri
d)
 18350 mutt RET   kbind 0
 18350 mutt CALL  kbind(0x7f7dbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt RET   kbind 0
 18350 mutt CALL  pipe(0x7f7dbd58)
 18350 mutt RET   pipe 0
 18350 mutt CALL  fcntl(7,F_SETFD,FD_CLOEXEC)
 18350 mutt RET   fcntl 0
 18350 mutt CALL  kbind(0x7f7dbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt RET   kbind 0
 18350 mutt CALL  kbind(0x7f7dbc88,0x18,0x9fbf6a958258cd0d)
 18350 mutt RET   kbind 0
 18350 mutt CALL  kbind(0x7f7dbb88,0x18,0x9fbf6a958258cd0d)
 18350 mutt RET   kbind 0
 18350 mutt CALL  sendmsg(5,0x7f7dbc70,0)
 18350 mutt STRU  struct msghdr { name=0x0, namelen=0, iov=0x7f7dbcc0, 
iovle
n=1, control=0x7f7dbca0, controllen=24, flags=0 }
 18350 mutt STRU  struct iovec { base=0x7f7dbcd0, len=28 }
 18350 mutt STRU  struct cmsghdr { len=20, level=SOL_SOCKET, 
type=SCM_RIGHTS, da
ta=6 }
 18350 mutt PLDG  sendmsg, "sendfd", errno 1 Operation not permitted
 18350 mutt PSIG  SIGABRT SIG_DFL
 18350 mutt NAMI  "mutt.core"

On Sun, Jan 17, 2016 at 07:13:41AM -0700, Stuart Henderson wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   st...@cvs.openbsd.org   2016/01/17 07:13:41
> 
> Modified files:
>   mail/mutt  : Makefile 
> Added files:
>   mail/mutt/patches: patch-main_c patch-mutt_sasl_c 
>  patch-mutt_sasl_h 
> 
> Log message:
> Add an initial pledge to mutt, from tb@. Tested so far with slang/normal,
> gpgme/normal, sasl/normal, headercache on/off, and with imap/mbox/maildir.
> 
> As you'd expect with a program like this that has many configuration
> options, including at runtime, the pledge is rather wide. But even so,
> a wide pledge still prevents many system calls, and restricts use of
> others.
> 
> Committing early to make it easier for people to test. Please do so,
> especially if you have an unusual configuration. If you run into problems,
> please obtain a ktrace and report back to tb@ and myself with a description,
> the last page or so of kdump output, and preferably a backtrace. Thanks!
> 

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF



signature.asc
Description: PGP signature


Re: "rcctl start anacron" fails when no jobs to run

2016-01-09 Thread Andreas Kusalananda Kähäri
On Sat, Jan 09, 2016 at 05:02:04PM +0100, Antoine Jacoutot wrote:
> On Sat, Jan 09, 2016 at 12:45:42PM +0100, Andreas Kusalananda Kähäri wrote:
> > Hi,
> > 
> > When using rcctl to start a service that is not a true daemon, such
> > as anacron (from ports), and that service does its job and exits
> > immediately, then rcctl will wait for the allotted timeout to expire and
> > report failure:
> > 
> > $ rcctl get anacron
> > anacron_class=daemon
> > anacron_flags=-s
> > anacron_timeout=30
> > anacron_user=root
> > 
> > $ doas anacron -s -d
> > Anacron 2.4.3 started on 2016-01-09
> > Normal exit (0 jobs run)
> > 
> > $ doas rcctl start anacron
> > anacron(failed)
> > 
> > I'm not sure how to fix this.  It doesn't break anything, but it delays
> > the boot process.
> 
> rc.d is for daemons only.
> If anacron is just a standard utility that needs to be run at boot time then 
> use rc.local or cron's @reboot facility.
> 

Good suggestion.  I'm already running it @hourly in root's crontab (I've
switched to running /etc/{daily,weekly,monthly} with anacron), and I
might just as well invoke it directly rather than through rcctl.

The port comes with an rcscript.  I'm Cc'ing the port maintainer here
(giovanni@) so that he may decide whether that script should be removed
from the port.  Also switching the mailing list from misc to ports.

Cheers,

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF




Re: Offer to port ObjectRexx

2015-12-31 Thread Andreas Kusalananda Kähäri
On Thu, Dec 31, 2015 at 10:15:55AM -0700, Jack J. Woehr wrote:
> ObjectRexx is a cool language that doesn't build on OpenBSD.
> 
> An ObjectRexx core developer is looking for an OpenBSD login he can access to 
> port OORexx.
> 
> Can anyone provide a login?

OpenBSD is trivial to set up in e.g. VirtualBox...


-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF



signature.asc
Description: PGP signature


Re: [UPDATE] devel/perltidy 20150815

2015-12-04 Thread Andreas Kusalananda Kähäri
Port maintainer jim@ has not replied to this since I sent it about two
weeks ago.  Anyone else care to commit it?

On Sat, Nov 21, 2015 at 09:30:45PM +0100, Andreas Kusalananda K�h�ri wrote:
> Hi,
> 
> I noticed that devel/perltidy was outdated.
> 
> Here is a trivial update to the latest release.
> 
> Cheers,
> 
> -- 
> :: Andreas Kusalananda Kähäri
> :: Bioinformatics Developer
> :: Uppsala, Sweden
> ::--

> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/perltidy/Makefile,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 Makefile
> --- Makefile  8 Jul 2015 16:20:04 -   1.18
> +++ Makefile  21 Nov 2015 20:25:23 -
> @@ -2,7 +2,7 @@
>  
>  COMMENT =tool to indent and reformat perl scripts
>  
> -V =  20140711
> +V =  20150815
>  DISTNAME =   Perl-Tidy-$V
>  PKGNAME =perltidy-$V
>  CATEGORIES = devel
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/perltidy/distinfo,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 distinfo
> --- distinfo  8 Jul 2015 16:20:04 -   1.14
> +++ distinfo  21 Nov 2015 20:25:23 -
> @@ -1,2 +1,2 @@
> -SHA256 (Perl-Tidy-20140711.tar.gz) = 
> FXbOs/2fWS0Cha/75xkmhZY9wdBBGWjMBYfWrA17Otg=
> -SIZE (Perl-Tidy-20140711.tar.gz) = 422397
> +SHA256 (Perl-Tidy-20150815.tar.gz) = 
> CpadnmwEKPqzlKpmtxbKLKBS/kqi7xRPfazDNVwT69c=
> +SIZE (Perl-Tidy-20150815.tar.gz) = 425224




-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF



signature.asc
Description: PGP signature


[UPDATE] devel/perltidy 20150815

2015-11-21 Thread Andreas Kusalananda Kähäri
Hi,

I noticed that devel/perltidy was outdated.

Here is a trivial update to the latest release.

Cheers,

-- 
:: Andreas Kusalananda Kähäri
:: Bioinformatics Developer
:: Uppsala, Sweden
::--
Index: Makefile
===
RCS file: /cvs/ports/devel/perltidy/Makefile,v
retrieving revision 1.18
diff -u -p -u -r1.18 Makefile
--- Makefile8 Jul 2015 16:20:04 -   1.18
+++ Makefile21 Nov 2015 20:25:23 -
@@ -2,7 +2,7 @@
 
 COMMENT =  tool to indent and reformat perl scripts
 
-V =20140711
+V =20150815
 DISTNAME = Perl-Tidy-$V
 PKGNAME =  perltidy-$V
 CATEGORIES =   devel
Index: distinfo
===
RCS file: /cvs/ports/devel/perltidy/distinfo,v
retrieving revision 1.14
diff -u -p -u -r1.14 distinfo
--- distinfo8 Jul 2015 16:20:04 -   1.14
+++ distinfo21 Nov 2015 20:25:23 -
@@ -1,2 +1,2 @@
-SHA256 (Perl-Tidy-20140711.tar.gz) = 
FXbOs/2fWS0Cha/75xkmhZY9wdBBGWjMBYfWrA17Otg=
-SIZE (Perl-Tidy-20140711.tar.gz) = 422397
+SHA256 (Perl-Tidy-20150815.tar.gz) = 
CpadnmwEKPqzlKpmtxbKLKBS/kqi7xRPfazDNVwT69c=
+SIZE (Perl-Tidy-20150815.tar.gz) = 425224


signature.asc
Description: PGP signature


Re: Why flex is no longer in the repository?

2015-11-21 Thread Andreas Kusalananda Kähäri
On Sat, Nov 21, 2015 at 08:55:21AM +0100, Guillermo Bernaldo de Quiros Maraver 
wrote:
> Hi all, good morning.
> 
> This morning, I updated my ports from cvs and I saw that flex is no longer
> in the repository and I wonder why? because is still being needed for ports
> like LibreOffice and other ports...
> Finally I had to install flex from packages. Someone here knows why flex is
> no longer in the repository?
> 
> Thank you very much.
> Guille
> 

I saw the dependency on devel/flex be removed from the LibreOffice port
yesterday.  Is your ports tree in sync?

The ports that depended on devel/flex are now using the base system flex
which was updated to version 2.5.39 on Thursday.  You're running an
up-to-date build, right?

-- 
:: Andreas Kusalananda Kähäri
:: Bioinformatics Developer
:: Uppsala, Sweden
::--



[update] GNU Stow (sysutils/stow) 2.2.0 --> 2.2.2

2015-11-10 Thread Andreas Kusalananda Kähäri
Hi,

GNU Stow had a new public release (2.2.2) on Nov 9 2015, and below is a
trivial patch to bring the OpenBSD port up from version 2.2.0.

There was never a public 2.2.1 release.

Release notes here:
http://lists.gnu.org/archive/html/info-stow/2015-11/msg0.html

Cheers,
Andreas (sysutils/stow maintainer)


Index: Makefile
===
RCS file: /cvs/ports/sysutils/stow/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile7 May 2015 11:27:59 -   1.10
+++ Makefile10 Nov 2015 08:53:57 -
@@ -2,7 +2,7 @@
 
 COMMENT=   manages software package installations with symlinks
 
-DISTNAME=  stow-2.2.0
+DISTNAME=  stow-2.2.2
 CATEGORIES=sysutils
 
 HOMEPAGE=  https://www.gnu.org/software/stow/stow.html
Index: distinfo
===
RCS file: /cvs/ports/sysutils/stow/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo7 May 2015 11:27:59 -   1.5
+++ distinfo10 Nov 2015 08:53:57 -
@@ -1,2 +1,2 @@
-SHA256 (stow-2.2.0.tar.gz) = i4nXmTnPmuh9LyI7s2o7LQxmd1tirrmVPG0z2rQNPCs=
-SIZE (stow-2.2.0.tar.gz) = 479109
+SHA256 (stow-2.2.2.tar.gz) = 4vd2STAbIVua28LwdFI77eutNmgSaQudyURXr1zyc98=
+SIZE (stow-2.2.2.tar.gz) = 579324

-- 
:: Andreas Kusalananda Kähäri
:: Bioinformatics Developer
:: Uppsala, Sweden
::--


signature.asc
Description: PGP signature


UPDATE: sysutils/stow 2.2.0

2015-04-29 Thread Andreas Kusalananda Kähäri
Hi,

Here's an update for GNU Stow that brings it up from version 1.3.3 to
version 2.2.0.  This updated version has been around since early 2012
and I've been using it successfully on other systems.

Works well on amd64, and the port passes make test tests.

I have also updated my email address in the Makefile.


Cheers,

-- 
:: Andreas Kusalananda Kähäri, Bioinformatics Developer, BILS,
:: Uppsala University, Sweden
::--
Index: Makefile
===
RCS file: /cvs/ports/sysutils/stow/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- Makefile1 Jan 2014 20:46:29 -   1.9
+++ Makefile29 Apr 2015 10:23:28 -
@@ -2,13 +2,12 @@
 
 COMMENT=   manages software package installations with symlinks
 
-DISTNAME=  stow-1.3.3
-REVISION = 1
+DISTNAME=  stow-2.2.0
 CATEGORIES=sysutils
 
 HOMEPAGE=  https://www.gnu.org/software/stow/stow.html
 
-MAINTAINER=Andreas Kahari andreas.kah...@gmail.com
+MAINTAINER=Andreas Kusalananda Kahari andreas.kah...@icm.uu.se
 
 # GPL
 PERMIT_PACKAGE_CDROM=  Yes
@@ -16,5 +15,8 @@
 MASTER_SITES=  ${MASTER_SITE_GNU:=stow/}
 
 CONFIGURE_STYLE=gnu
+USE_GMAKE=Yes
+
+TEST_DEPENDS=  devel/p5-Test-Output
 
 .include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/sysutils/stow/distinfo,v
retrieving revision 1.4
diff -u -r1.4 distinfo
--- distinfo18 Jan 2015 03:15:15 -  1.4
+++ distinfo29 Apr 2015 10:23:28 -
@@ -1,2 +1,2 @@
-SHA256 (stow-1.3.3.tar.gz) = DNx/t4Yeg3he3S3hJyaPinLtmuUk3cS+yiNs/WPR+LA=
-SIZE (stow-1.3.3.tar.gz) = 139417
+SHA256 (stow-2.2.0.tar.gz) = i4nXmTnPmuh9LyI7s2o7LQxmd1tirrmVPG0z2rQNPCs=
+SIZE (stow-2.2.0.tar.gz) = 479109
Index: pkg/DESCR
===
RCS file: /cvs/ports/sysutils/stow/pkg/DESCR,v
retrieving revision 1.3
diff -u -r1.3 DESCR
--- pkg/DESCR   30 Jun 2004 23:33:18 -  1.3
+++ pkg/DESCR   29 Apr 2015 10:23:28 -
@@ -1,13 +1,14 @@
-GNU Stow is a Perl program for managing the installation of
-software packages, keeping them separated from each other while
-making them appear to be installed in the same place by using
-symbolic links.
+GNU Stow is a Perl program for managing the installation of software
+packages, keeping them separated from each other while making them
+appear to be installed in the same place by using symbolic links.
 
-Stow is particularly useful when installing software distributed
-with a GNU configure script (use the --prefix=path option).
+Stow is particularly useful when installing software distributed with
+a GNU configure script (use the --prefix=path option) or any other
+software that installs in a standard hierarchy beneath a configurable
+prefix path.
 
-Stow may be used by non-root users to set up a private hierarchy
-under e.g. $HOME/local, or by local administrators who wants
-to install software that is not managed by the native package
-or port system, and make it available under e.g. /opt/local or
-/usr/pkg.
+Stow may be used by non-root users to set up a private software
+hierarchy under e.g. $HOME/local, or by local administrators who wants
+to install software that is not managed by the native package or port
+system, and make it available under /opt/local, /sw, or any other
+similar location.
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/stow/pkg/PLIST,v
retrieving revision 1.3
diff -u -r1.3 PLIST
--- pkg/PLIST   4 Sep 2005 23:35:59 -   1.3
+++ pkg/PLIST   29 Apr 2015 10:23:28 -
@@ -1,4 +1,45 @@
 @comment $OpenBSD: PLIST,v 1.3 2005/09/04 23:35:59 espie Exp $
+bin/chkstow
 bin/stow
 @info info/stow.info
+libdata/perl5/site_perl/Stow/
+libdata/perl5/site_perl/Stow.pm
+libdata/perl5/site_perl/Stow/Util.pm
 @man man/man8/stow.8
+share/doc/stow/
+share/doc/stow/ChangeLog
+share/doc/stow/ChangeLog.OLD
+share/doc/stow/README
+share/doc/stow/manual-single.html
+share/doc/stow/manual-split/
+share/doc/stow/manual-split/Bootstrapping.html
+share/doc/stow/manual-split/Compile_002dtime-vs-Install_002dtime.html
+share/doc/stow/manual-split/Conflicts.html
+share/doc/stow/manual-split/Cygnus-Software.html
+share/doc/stow/manual-split/Deferred-Operation.html
+share/doc/stow/manual-split/Deleting-Packages.html
+share/doc/stow/manual-split/GNU-Emacs.html
+share/doc/stow/manual-split/GNU-General-Public-License.html
+share/doc/stow/manual-split/Ignore-Lists.html
+share/doc/stow/manual-split/Index.html
+share/doc/stow/manual-split/Installing-Packages.html
+share/doc/stow/manual-split/Introduction.html
+share/doc/stow/manual-split/Invoking-Stow.html
+share/doc/stow/manual-split/Justification-For-Yet-Another-Set-Of-Ignore-Files.html
+share/doc/stow/manual-split/Known-Bugs.html
+share/doc/stow/manual-split/Mixing-Operations.html
+share/doc

Dropping maintainer of mail/signify

2015-04-29 Thread Andreas Kusalananda Kähäri
Hi,

After some years away, I noticed that I'm still the maintainer of both
the mail/signify and sysutils/stow ports.

I'd like to drop my maintainership of mail/signify.

I will update stow to the latest version and post a patch for it here
soon-ish. ... and I'll update my email address in the port too.

Cheers,

-- 
:: Andreas Kusalananda Kähäri, Bioinformatics Developer, BILS,
:: Uppsala University, Sweden
::--