Tiny fix to security/sshguard to allow use of daemon_flags
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
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
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
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
d -D snap 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
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
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
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
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
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
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
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
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
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&m=153115666203853&w=2 -- Kusalananda Sweden
Issues running dpb(1) (with patch)
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
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
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
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/
Re: CVS: cvs.openbsd.org: ports
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
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)
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, &seed)) { - 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
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) + # Ex
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?)
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
[FIX] devel/openmpi: Make main API symbols non-local (Re: devel/openmpi Can't link example program, symbols local in libmpi.so.0.1?)
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&m=152929789302360&w=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
Re: devel/openmpi Can't link example program, symbols local in libmpi.so.0.1?
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&m=152929789302360&w=2 Regards, -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
Re: UPDATE: security/sshguard 1.5 --> 2.3.0
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
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
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&fileviewer=file-view-default > > [2] https://marc.info/?l=openbsd-ports&m=154410607613935&w=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}/
UPDATE: security/sshguard 1.5 --> 2.3.0
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&fileviewer=file-view-default [2] https://marc.info/?l=openbsd-ports&m=154410607613935&w=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) + # Examp
Re: sshguard-2.2.0 (start/stop issues resolved)
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 > >
Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)
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)
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 w
sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)
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&fileviewer=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&m=154291717732337&w=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= sshgu
Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)
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&fileviewer=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
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
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
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
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
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)
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)
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(&argc, &argv); > > 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)
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(&argc, &argv); > 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)
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(&argc, &argv); 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)
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)
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)
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)
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)
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
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
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
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
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
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
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?
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?
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
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
On Mon, Apr 17, 2017 at 08:04:51PM +, Christian Weisgerber wrote: > On 2017-04-13, Andreas Kusalananda Kähäri 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
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
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
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
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
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 > > 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
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
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
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
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'
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"
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"
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"
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
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 > > > 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
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 > > 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)
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 + +# 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
Adding PARALLEL_BUILD=No to a few ports
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
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: Adding PARALLEL_BUILD=No to a few ports
On Thu, Mar 17, 2016 at 01:07:19PM +0100, Marc Espie wrote: > I should have been more clear in my comment. > > Seeing ports failing to build is not really enough. > > There is still a fairly nasty limitation in our make wrt matching paths > between targets that don't have the same filename, but are the same in > the filesystem. > > This limitation prevents some ports to build in parallel, where make is > the culprit that must be fixed (autoconf, for instance). > > There are also various race conditions in some ports proper, which actually > prevent parallel building. > > Those are very different issues. Just asserting a port doesn't build in > parallel is not enough to take proper action. > > If you can figure out what's going on, and make sure the port itself is > broken (say, by checking that gmake exhibits the same broken behavior), > then fixing the port/talking with upstream/marking as NO_PARALLEL is okay. > > It involves rather specific skills. > > As for that limitation, strategically, we would want to get rid of it > eventually (it "just" involves me totally rewriting a large part of the > core of make) rather than give in and use gpl code for building. > > But marking code as NO_PARALLEL in an indiscriminate way does not help me > doing that. > > Also, in the large scheme of things, there are just a few ports that > realistically benefit from parallel building. And those are often already > tagged with DPB_PROPERTIES because they help the actual official > package building. > I understand. I might look at these ports at a later date, as well as a couple of other ones I discovered today (devel/autoconf/2.61, as you mentioned, and lang/python/3.4), to see if they show the same behaviour with gmake outside of ports. In the meanwhile I'll rely on DPB_PROPERTIES instead, maybe in the way that Stuart suggested. Thanks, Andreas -- Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF signature.asc Description: PGP signature
Re: missing lib dep for devel/iso-codes
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
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)
a958258cd0d) 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
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
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
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
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?
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
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
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 +MAINTAINER=Andreas Kusalananda Kahari # 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 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/stow/manua
Dropping maintainer of mail/signify
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 ::--