update py-sphinx to v4.0.2
Here's an update of py-sphinx to v4.0.2:
- v4.0.1 doesn't work great because it moves some man pages around
- v4.0.2 reverts the man page change, but updates one of the .js files
requiring about 20+ consumer ports to have PLISTs updated
- v4.0.3 just came out just as I finished testing v4.0.2. It may work out
of the box or it may not.
I went with v4.0.2 below.
This update requires:
- a minor fix for lang/ghc
- mechanically updating PLISTs and bumping the 20+ ports below
- the sphinx update itself is mechanical, except that the RDEP on
py-docutils can now go up to 0.18
databases/mydumper
databases/pgadmin3
databases/py-peewee
databases/xapian-bindings
devel/cmake
devel/kf5
devel/luacheck
devel/py-pathlib
devel/py-pexpect
devel/py-testpath
devel/py-virtualenv
devel/udis86
emulators/qemu
productivity/vdirsyncer
shells/fish
www/py-flask-wtf
www/py-frozen-flask
www/py-itsdangerous
www/py-werkzeug
www/py-wtforms
x11/polybar
I successfully packaged and installed all consumer ports on amd64.
ok?
Index: databases/mydumper/Makefile
===
RCS file: /cvs/ports/databases/mydumper/Makefile,v
retrieving revision 1.16
diff -u -p -u -r1.16 Makefile
--- databases/mydumper/Makefile 20 Feb 2021 22:27:27 - 1.16
+++ databases/mydumper/Makefile 6 Jul 2021 02:38:19 -
@@ -3,7 +3,7 @@
COMMENT = utility for quick MySQL dumping
V =0.9.1
-REVISION = 4
+REVISION = 5
DISTNAME = mydumper-${V}
CATEGORIES = databases
Index: databases/mydumper/pkg/PLIST
===
RCS file: /cvs/ports/databases/mydumper/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -u -r1.5 PLIST
--- databases/mydumper/pkg/PLIST20 Feb 2021 22:27:27 - 1.5
+++ databases/mydumper/pkg/PLIST6 Jul 2021 02:38:19 -
@@ -33,7 +33,7 @@ share/doc/mydumper/html/_static/plus.png
share/doc/mydumper/html/_static/pygments.css
share/doc/mydumper/html/_static/searchtools.js
share/doc/mydumper/html/_static/sidebar.js
-share/doc/mydumper/html/_static/underscore-1.12.0.js
+share/doc/mydumper/html/_static/underscore-1.13.1.js
share/doc/mydumper/html/_static/underscore.js
share/doc/mydumper/html/authors.html
share/doc/mydumper/html/compiling.html
Index: databases/pgadmin3/Makefile
===
RCS file: /cvs/ports/databases/pgadmin3/Makefile,v
retrieving revision 1.45
diff -u -p -u -r1.45 Makefile
--- databases/pgadmin3/Makefile 20 Feb 2021 22:27:28 - 1.45
+++ databases/pgadmin3/Makefile 6 Jul 2021 02:38:19 -
@@ -5,7 +5,7 @@ COMMENT=administration and development
V= 1.22.1
DISTNAME= pgadmin3-$V
CATEGORIES=databases devel
-REVISION= 5
+REVISION= 6
HOMEPAGE= https://www.pgadmin.org/
Index: databases/pgadmin3/pkg/PLIST
===
RCS file: /cvs/ports/databases/pgadmin3/pkg/PLIST,v
retrieving revision 1.16
diff -u -p -u -r1.16 PLIST
--- databases/pgadmin3/pkg/PLIST20 Feb 2021 22:27:28 - 1.16
+++ databases/pgadmin3/pkg/PLIST6 Jul 2021 02:38:19 -
@@ -198,7 +198,7 @@ share/pgadmin3/docs/en_US/_static/slony-
share/pgadmin3/docs/en_US/_static/slony-upgrade.png
share/pgadmin3/docs/en_US/_static/status.png
share/pgadmin3/docs/en_US/_static/transaction.png
-share/pgadmin3/docs/en_US/_static/underscore-1.12.0.js
+share/pgadmin3/docs/en_US/_static/underscore-1.13.1.js
share/pgadmin3/docs/en_US/_static/underscore.js
share/pgadmin3/docs/en_US/appendices.html
share/pgadmin3/docs/en_US/backup.html
Index: databases/py-peewee/Makefile
===
RCS file: /cvs/ports/databases/py-peewee/Makefile,v
retrieving revision 1.21
diff -u -p -u -r1.21 Makefile
--- databases/py-peewee/Makefile21 May 2021 19:50:22 - 1.21
+++ databases/py-peewee/Makefile6 Jul 2021 02:38:19 -
@@ -5,7 +5,7 @@ COMMENT=small expressive ORM
MODPY_EGG_VERSION= 2.8.3
DISTNAME= peewee-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
-REVISION= 6
+REVISION= 7
GH_ACCOUNT=coleifer
GH_PROJECT=peewee
Index: databases/py-peewee/pkg/PLIST
===
RCS file: /cvs/ports/databases/py-peewee/pkg/PLIST,v
retrieving revision 1.12
diff -u -p -u -r1.12 PLIST
--- databases/py-peewee/pkg/PLIST 20 Feb 2021 22:27:28 - 1.12
+++ databases/py-peewee/pkg/PLIST 6 Jul 2021 02:38:19 -
@@ -99,7 +99,7 @@ share/doc/${MODPY_PY_PREFIX}peewee/_stat
share/doc/${MODPY_PY_PREFIX}peewee/_static/pygments.css
share/doc/${MODPY_PY_PREFIX}peewee/_static/searchtools.js
share/doc/${MODPY_PY_PREFIX}peewee/_static/sidebar.js
-share/doc/${MODPY_PY_PREFIX}peewee/_static/underscore-1.12.0.js
+share/doc/${
Re: [update] cataclysm-dda 0.E.3 -> 0.F
On Tue, July 6, 2021 00:56, trondd wrote: > Stefmorino wrote: > >> Updates to the next major release of Cataclysm: Dark Days Ahead. >> >> I moved the packaged Terminus font and its license to the no-no_x11 >> package fragment, since they're not needed by the no_x11 flavor. >> >> patch-test_Makefile is needed or catch/catch.hpp isn't included >> properly when building pch tests (clang & gcc inconsistency?) >> >> Port also attached as tgz. >> >> Thoughts/Tests/OK? @trondd >> > > I can't get one of the patches to apply. I've taken patch-Makefile from attached tarball to solve this. > > |Index: patches/patch-Makefile > |=== > |RCS file: /cvs/ports/games/cataclysm-dda/patches/patch-Makefile,v > |retrieving revision 1.10 > |diff -u -p -r1.10 patch-Makefile > |--- patches/patch-Makefile 25 Jun 2021 17:42:59 - 1.10 > |+++ patches/patch-Makefile 5 Jul 2021 18:33:59 - > -- > Patching file patches/patch-Makefile using Plan A... > Hunk #1 succeeded at 3. > Hunk #2 failed at 12. > Hunk #3 succeeded at 29 with fuzz 2. > Hunk #4 failed at 39. > Hunk #5 succeeded at 84. > Hunk #6 failed at 95. > 3 out of 6 hunks failed--saving rejects to patches/patch-Makefile.rej > > Tim. > >
Re: gnupg update
On 2021/07/05 11:53, Stuart Henderson wrote:
> On 2021/07/05 11:25, Edd Barrett wrote:
> > If those are committed, then the only out-of-date gnupg-related
> > component would be gpgme (which I've not had time to look at yet,
> > sorry).
>
> I can take a look at gpgme.
btw I've had a quick look but I ran into an error with the Qt bindings
that I haven't figured out how to get past yet.
qgpgmesignkeyjob.cpp:224:25: error: no viable overloaded '='
d->m_trustSignature = {trust, depth, scope};
~~~ ^ ~
qgpgmesignkeyjob.cpp:59:8: note: candidate function (the implicit copy
assignment operator) not viable: cannot convert initializer list argument to
'const (anonymous namespace)::TrustSignatureProperties'
I'll leave the non-Qt ports that depend on it building to check them.
Re: [update] cataclysm-dda 0.E.3 -> 0.F
Stefmorino wrote: > Updates to the next major release of Cataclysm: Dark Days Ahead. > > I moved the packaged Terminus font and its license to the no-no_x11 > package fragment, since they're not needed by the no_x11 flavor. > > patch-test_Makefile is needed or catch/catch.hpp isn't included > properly when building pch tests (clang & gcc inconsistency?) > > Port also attached as tgz. > > Thoughts/Tests/OK? @trondd > I can't get one of the patches to apply. |Index: patches/patch-Makefile |=== |RCS file: /cvs/ports/games/cataclysm-dda/patches/patch-Makefile,v |retrieving revision 1.10 |diff -u -p -r1.10 patch-Makefile |--- patches/patch-Makefile 25 Jun 2021 17:42:59 - 1.10 |+++ patches/patch-Makefile 5 Jul 2021 18:33:59 - -- Patching file patches/patch-Makefile using Plan A... Hunk #1 succeeded at 3. Hunk #2 failed at 12. Hunk #3 succeeded at 29 with fuzz 2. Hunk #4 failed at 39. Hunk #5 succeeded at 84. Hunk #6 failed at 95. 3 out of 6 hunks failed--saving rejects to patches/patch-Makefile.rej Tim.
Re: [update] www/snownews 1.6.10 -> 1.8
On Mon, July 5, 2021 9:53 am, Charlene Wendling wrote: > Hi, > > The below diff updates snownews to 1.8 with a new repo owner and > finally a lot of modern features [0]! I tend to separate upstream vs > ports changes, but it's unpractical here: > >> Added Atom feed support > Modify COMMENT and DESCR accordingly. While here, update to valid > feeds and a mix of RSS and Atom. HTTPS is used where applicable. >> Use curl for networking > Add proper LIB_DEPENDS, remove README now that HTTPS is supported. > There is a year 2038 printf() warning, but it would require to > sprinkle CURLINFO_FILETIME_T instead of CURLINFO_FILETIME in many > places first. Also, refresh WANTLIB, and remove the netio.c patch > accordingly. >> Use the OPML format to store the feed list, and XDG dirs > Snownews-1.8 will migrate your urls file to the OPML format in > ~/.config/snownews where you can find other settings (key bindings, > colors etc.). The OPML conversion tools (snow2opml, opml2snow) have > been removed, so we don't need p5-XML-LibXML as a RUN_DEPENDS. >> Use UTF-8 everywhere (including manpages) > The upstream configuration system couldn't find our ncurses library > with wide chars support, so i needed to tweak CFLAGS and LDFLAGS. >> Deal with lack of verbosity for the fake stage > The most painful part of that update has been the fake stage, > because upstream hides issued commands, so i preferred to > unsilence them. > > All the rest is mostly updating old patches. > > Testing: > > It builds and works fine on amd64 and macppc. > > Note that feed items' text enclosed in '' is > not displayed (yet?). > > Comments and feedback are welcome, > > Charlène. > > > [0] https://github.com/msharov/snownews/releases > Thanks. I use snownews. It converted my configs and works as epxected. I had to go back in and clean up all the calls to external conversion tools that the previous version needed but that's to be expected. Worked either way. Tim.
Re: gnupg update
On Mon, Jul 05 2021, Stuart Henderson wrote: > On 2021/07/05 11:25, Edd Barrett wrote: >> Hi, >> >> On Mon, Jul 05, 2021 at 12:13:38PM +0200, Jeremie Courreges-Anglas wrote: >> > ok jca@ fwiw but as I said Edd has a wip update to 2.3.1. >> >> In hindsight, I think using Stuart's 2.2.29 diff would be better. >> Upstream describes 2.3.x as "the start of public testing releases". I >> think we should give users the most stable packages we can. >> >> In addition to sthen@'s diff, here's updates to libksba and pinentry. >> >> If those are committed, then the only out-of-date gnupg-related >> component would be gpgme (which I've not had time to look at yet, >> sorry). > > I can take a look at gpgme. > >> With libksba, although upstream did major bumps, I can't see any reason >> to do so based on the changes I see to the public API. Hence I've not >> bumped our SO version, but someone should double check my work. We could >> just bump it to be sure. > > They replaced some parts in the middle of struct ksba_cms_s, this struct > is in src/cms.h which isn't in an installed header but it is used in > prototypes that are in the installed ksba.h. So I'm a bit unsure > whether bumping is needed or not The struct is opaque so this change in particular wouldn't warrant a bump. That being said, > but I think I'd go with "if in doubt, > bump" here to be on the safe side. The ksba_content_type_t enum grew two new possible values. As this enum is used as input parameter and return type for public ksba functions please use at least a minor bump. > Otherwise those are OK sthen@ Seconded. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [update] cataclysm-dda 0.E.3 -> 0.F
On 2021/07/05 19:00, Stefmorino wrote:
> Updates to the next major release of Cataclysm: Dark Days Ahead.
>
> I moved the packaged Terminus font and its license to the no-no_x11
> package fragment, since they're not needed by the no_x11 flavor.
>
> patch-test_Makefile is needed or catch/catch.hpp isn't included
> properly when building pch tests (clang & gcc inconsistency?)
>
> Port also attached as tgz.
>
> Thoughts/Tests/OK? @trondd
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/cataclysm-dda/Makefile,v
> retrieving revision 1.17
> diff -u -p -r1.17 Makefile
> --- Makefile 26 Jun 2021 06:25:41 - 1.17
> +++ Makefile 5 Jul 2021 18:33:59 -
> @@ -5,10 +5,8 @@ CATEGORIES= games
>
> GH_ACCOUNT= CleverRaven
> GH_PROJECT= Cataclysm-DDA
> -GH_TAGNAME= 0.E-3
> -DISTNAME=cataclysm-dda-0.E.3
> -EPOCH= 0
Once EPOCH is set, you cannot remove it or move to a lower version.
> -REVISION=1
> +GH_TAGNAME= 0.F
> +DISTNAME=cataclysm-dda-0.F
>
> HOMEPAGE=https://cataclysmdda.org
> MAINTAINER= Tim Meunier
> @@ -19,14 +17,18 @@ PERMIT_PACKAGE= Yes
> FLAVORS= no_x11
> FLAVOR?=
>
> -WANTLIB= ${COMPILER_LIBCXX} c execinfo iconv intl m pthread
> +WANTLIB= ${COMPILER_LIBCXX} c execinfo iconv intl m
>
> # C++14
> COMPILER=base-clang ports-gcc
>
> MODULES= textproc/intltool
>
> -LIB_DEPENDS= devel/gettext,-runtime
> +RUN_DEPENDS= devel/desktop-file-utils \
> + x11/gtk+3,-guic
> +
> +LIB_DEPENDS= devel/gettext,-runtime \
> + devel/libexecinfo
There is no more devel/libexecinfo port.
Re: [update] www/snownews 1.6.10 -> 1.8
Comments and feedback are welcome, this is pretty cool, i think snownews will replace newsboat for me `make test` and `make install` on amd64 successfull most of my feeds did work without a problem. i will report small improvements and some "broken" feeds upstream thanks for this update
Re: gnupg update
On Mon, Jul 05, 2021 at 04:12:45PM +0100, Stuart Henderson wrote: > That's if there's really a need to run the two in parallel anyway. Agreed. I'd like to avoid packaging the two branches unless we have a good reason. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: [update] www/snownews 1.6.10 -> 1.8
Hi Charlene -- On 07/05/2021 09:53 AM, Charlene Wendling wrote: Hi, The below diff updates snownews to 1.8 with a new repo owner and finally a lot of modern features [0]! I tend to separate upstream vs ports changes, but it's unpractical here: Added Atom feed support Modify COMMENT and DESCR accordingly. While here, update to valid feeds and a mix of RSS and Atom. HTTPS is used where applicable. Use curl for networking Add proper LIB_DEPENDS, remove README now that HTTPS is supported. There is a year 2038 printf() warning, but it would require to sprinkle CURLINFO_FILETIME_T instead of CURLINFO_FILETIME in many places first. Also, refresh WANTLIB, and remove the netio.c patch accordingly. Use the OPML format to store the feed list, and XDG dirs Snownews-1.8 will migrate your urls file to the OPML format in ~/.config/snownews where you can find other settings (key bindings, colors etc.). The OPML conversion tools (snow2opml, opml2snow) have been removed, so we don't need p5-XML-LibXML as a RUN_DEPENDS. Use UTF-8 everywhere (including manpages) The upstream configuration system couldn't find our ncurses library with wide chars support, so i needed to tweak CFLAGS and LDFLAGS. Deal with lack of verbosity for the fake stage The most painful part of that update has been the fake stage, because upstream hides issued commands, so i preferred to unsilence them. All the rest is mostly updating old patches. Testing: It builds and works fine on amd64 and macppc. Note that feed items' text enclosed in '' is not displayed (yet?). Comments and feedback are welcome, Charlène. [0] https://github.com/msharov/snownews/releases Everything checks out and works here too. ok bcallah@ ~Brian
Re: gnupg update
On 2021/07/05 15:43, Jeremie Courreges-Anglas wrote: > On Mon, Jul 05 2021, Stuart Henderson wrote: > > On 2021/07/05 12:13, Jeremie Courreges-Anglas wrote: > >> On Mon, Jul 05 2021, Stuart Henderson wrote: > >> > There have been a few releases since the version in ports so I won't > >> > copy the whole lot here, but release notes are in > >> > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=NEWS;h=e37d5aa5d46276e0e3e462b7619c9678e374ab69;hb=695a879af81e895741109874b9ac0712e1afc994 > >> > >> FWIW I pinged edd@ about this yesterday. He replied with a wip diff > >> which includes an update to 2.3.1. 2.2 is the current stable branch, > >> 2.3 is the new devel branch (since 2021-04-07). > >> > >> I have no opinion whether we should use the stable or devel branch, I'll > >> just note that we have used the 2.1 devel branch in the past. > >> > >> > The doc/Makefile.in patch didn't apply, rather than updating it I just > >> > changed to rm'ing in post-install to save work for future updates. > >> > >> Makes sense to me. > >> > >> > OK? > >> > >> make test passes on amd64 and sparc64. > >> > >> ok jca@ fwiw but as I said Edd has a wip update to 2.3.1. > > > > Thanks. It feels to me a bit early to switch to the 2.3 branch as as the > > only version; the release announcements upstream currently say "may even > > be used for production purposes if either the risk of minor regressions > > is acceptable or the new features are important." > > > > If there's enough interest in running the development version, > > This happened with the 2.1 branch where some people were eager to use > new features. > > > having the > > two in parallel might be a safer approach? > > That's one way to handle it. It makes things a tad more complicated wrt > runtime deps but the gnupg/gnupg2 proved that it works fine in practice. I don't think anything needs to depend on the devel version, and the two packages can conflict with each other (e.g. security/gnupg and security/gnupg23, with gnupg-2.2.XX ang gnupg-2.3.XX PKGNAMEs) and both providing the usual set of files without renaming - bin/gnupg, bin/dirmngr, share/doc/gnupg/* etc - the dependency would be on security/gnupg but the default PKGSPEC of gnupg-* will allow either version to satisfy the dependency. That's if there's really a need to run the two in parallel anyway. > Something to keep in mind: the devel branch appears to have > a discontinuous schedule. > > | | stable | devel | > |--++| > | 2006 | 2.0.0 || > | | x || > | 2007 | x || > | | x || > | 2008 | x || > | | x || > | 2009 | x || > | | x || > | 2010 | x || > | | x || > | 2011 | x || > | | x || > | 2012 | x || > | | x || > | 2013 | x || > | | x || > | 2014 | x | 2.1.0 | > | | x | x | > | 2015 | x | x | > | | x | x | > | 2016 | 2.0.30 | x | > | || x | > | 2017 | 2.2.0 | 2.1.23 | > | | x || > | 2018 | x || > | | x || > | 2019 | x || > | | x || > | 2020 | x || > | | x || > | 2021 | 2.2.29 | 2.3.0 | > | | x | 2.3.1 | > | 2022 | x | ? | > | | x | ? | > | 2023 | x | ? | > | | x | ? | > | 2024 | 2.2.X | ? | > | || ? | > | || ? | > > 2.2 will be discontinued in 2024 (see End-of-life announcements > in https://www.gnupg.org/download/index.html). > While I can't speak for upstream, I expect 2.3 to disappear once 2.4 is > announced. So 2.3 users could be moved automatically to 2.4/stable, but > they'll have to manually upgrade to the new 2.5/devel branch when it > becomes available. > > My two cents, > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
[update] www/snownews 1.6.10 -> 1.8
Hi,
The below diff updates snownews to 1.8 with a new repo owner and
finally a lot of modern features [0]! I tend to separate upstream vs
ports changes, but it's unpractical here:
> Added Atom feed support
Modify COMMENT and DESCR accordingly. While here, update to valid
feeds and a mix of RSS and Atom. HTTPS is used where applicable.
> Use curl for networking
Add proper LIB_DEPENDS, remove README now that HTTPS is supported.
There is a year 2038 printf() warning, but it would require to
sprinkle CURLINFO_FILETIME_T instead of CURLINFO_FILETIME in many
places first. Also, refresh WANTLIB, and remove the netio.c patch
accordingly.
> Use the OPML format to store the feed list, and XDG dirs
Snownews-1.8 will migrate your urls file to the OPML format in
~/.config/snownews where you can find other settings (key bindings,
colors etc.). The OPML conversion tools (snow2opml, opml2snow) have
been removed, so we don't need p5-XML-LibXML as a RUN_DEPENDS.
> Use UTF-8 everywhere (including manpages)
The upstream configuration system couldn't find our ncurses library
with wide chars support, so i needed to tweak CFLAGS and LDFLAGS.
> Deal with lack of verbosity for the fake stage
The most painful part of that update has been the fake stage,
because upstream hides issued commands, so i preferred to
unsilence them.
All the rest is mostly updating old patches.
Testing:
It builds and works fine on amd64 and macppc.
Note that feed items' text enclosed in '' is
not displayed (yet?).
Comments and feedback are welcome,
Charlène.
[0] https://github.com/msharov/snownews/releases
Index: Makefile
===
RCS file: /cvs/ports/www/snownews/Makefile,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 Makefile
--- Makefile21 Nov 2020 22:03:13 - 1.41
+++ Makefile5 Jul 2021 13:01:43 -
@@ -1,13 +1,11 @@
# $OpenBSD: Makefile,v 1.41 2020/11/21 22:03:13 kmos Exp $
-COMMENT= text mode rss newsreader
+COMMENT= text mode rss and atom newsreader
CATEGORIES=www
-GH_ACCOUNT=kouya
+GH_ACCOUNT=msharov
GH_PROJECT=snownews
-GH_TAGNAME=1.6.10
-
-HOMEPAGE= https://github.com/kouya/snownews
+GH_TAGNAME=v1.8
# GPLv3 only
PERMIT_PACKAGE=Yes
@@ -15,21 +13,25 @@ PERMIT_PACKAGE= Yes
# C11
COMPILER= base-clang ports-gcc
-WANTLIB += c curses iconv intl xml2 z
+WANTLIB += c crypto curl curses iconv intl xml2
NO_TEST= Yes
USE_GMAKE= Yes
BUILD_DEPENDS= devel/gettext,-tools
-RUN_DEPENDS= textproc/p5-XML-LibXML
LIB_DEPENDS= devel/gettext,-runtime \
+ net/curl \
textproc/libxml
CONFIGURE_STYLE= simple
-CONFIGURE_ARGS=--prefix="\$${PREFIX}" \
- --mandir="\$${PREFIX}/man" \
- --builddir=${WRKDIR}
-MAKE_ENV= COPTFLAGS="${CFLAGS}"
+CONFIGURE_ARGS+= --builddir=${WRKDIR} --mandir=${PREFIX}/man
+MAKE_ENV= cflags="${CFLAGS}" ldflags="${LDFLAGS}"
+
+# Needed for cchar_t, setcchar() and getcchar()
+CFLAGS+= -D_XOPEN_SOURCE_EXTENDED
+# Fix linking errors due to upstream build system
+# not being able to find proper LDFLAGS for ncurses
+LDFLAGS+= -lncursesw
.include
Index: distinfo
===
RCS file: /cvs/ports/www/snownews/distinfo,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 distinfo
--- distinfo20 Nov 2020 20:48:11 - 1.17
+++ distinfo5 Jul 2021 13:01:43 -
@@ -1,2 +1,2 @@
-SHA256 (snownews-1.6.10.tar.gz) = jHgGeu914oPfSzzKHJZlh7ZlTp6Eo+bl64vdWCl5kkI=
-SIZE (snownews-1.6.10.tar.gz) = 189715
+SHA256 (snownews-1.8.tar.gz) = kNJhGz46ALwUqIaTZdNmrR2rF+oWh4V0QBWfxxN8O+0=
+SIZE (snownews-1.8.tar.gz) = 154813
Index: patches/patch-Config_mk_in
===
RCS file: /cvs/ports/www/snownews/patches/patch-Config_mk_in,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-Config_mk_in
--- patches/patch-Config_mk_in 20 Nov 2020 20:48:11 - 1.1
+++ patches/patch-Config_mk_in 5 Jul 2021 13:01:43 -
@@ -3,25 +3,25 @@ $OpenBSD: patch-Config_mk_in,v 1.1 2020/
Index: Config.mk.in
--- Config.mk.in.orig
+++ Config.mk.in
-@@ -21,7 +21,7 @@ PREFIX := @prefix@
- BINDIR:= @bindir@
- LOCALEPATH:= @localedir@
- MANPATH := @mandir@
--BUILDDIR := @builddir@/${NAME}
-+BUILDDIR := @builddir@/build
- PKGDIR:= @pkgdir@
+@@ -19,20 +19,13 @@ mandir := @mandir@
+ man1dir := @man1dir@
+ localedir := @localedir@
+ TMPDIR:= @TMPDIR@
+-builddir := @builddir@/${name}
++builddir := @builddir@/build
O := .o/
-@@ -29,11 +29,5 @@ O := .o/
+ Compiler options
- CFLAGS:= -Wall -Wextra -Wredundant-decls -Wsha
Re: gnupg update
On Mon, Jul 05 2021, Stuart Henderson wrote: > On 2021/07/05 12:13, Jeremie Courreges-Anglas wrote: >> On Mon, Jul 05 2021, Stuart Henderson wrote: >> > There have been a few releases since the version in ports so I won't >> > copy the whole lot here, but release notes are in >> > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=NEWS;h=e37d5aa5d46276e0e3e462b7619c9678e374ab69;hb=695a879af81e895741109874b9ac0712e1afc994 >> >> FWIW I pinged edd@ about this yesterday. He replied with a wip diff >> which includes an update to 2.3.1. 2.2 is the current stable branch, >> 2.3 is the new devel branch (since 2021-04-07). >> >> I have no opinion whether we should use the stable or devel branch, I'll >> just note that we have used the 2.1 devel branch in the past. >> >> > The doc/Makefile.in patch didn't apply, rather than updating it I just >> > changed to rm'ing in post-install to save work for future updates. >> >> Makes sense to me. >> >> > OK? >> >> make test passes on amd64 and sparc64. >> >> ok jca@ fwiw but as I said Edd has a wip update to 2.3.1. > > Thanks. It feels to me a bit early to switch to the 2.3 branch as as the > only version; the release announcements upstream currently say "may even > be used for production purposes if either the risk of minor regressions > is acceptable or the new features are important." > > If there's enough interest in running the development version, This happened with the 2.1 branch where some people were eager to use new features. > having the > two in parallel might be a safer approach? That's one way to handle it. It makes things a tad more complicated wrt runtime deps but the gnupg/gnupg2 proved that it works fine in practice. Something to keep in mind: the devel branch appears to have a discontinuous schedule. | | stable | devel | |--++| | 2006 | 2.0.0 || | | x || | 2007 | x || | | x || | 2008 | x || | | x || | 2009 | x || | | x || | 2010 | x || | | x || | 2011 | x || | | x || | 2012 | x || | | x || | 2013 | x || | | x || | 2014 | x | 2.1.0 | | | x | x | | 2015 | x | x | | | x | x | | 2016 | 2.0.30 | x | | || x | | 2017 | 2.2.0 | 2.1.23 | | | x || | 2018 | x || | | x || | 2019 | x || | | x || | 2020 | x || | | x || | 2021 | 2.2.29 | 2.3.0 | | | x | 2.3.1 | | 2022 | x | ? | | | x | ? | | 2023 | x | ? | | | x | ? | | 2024 | 2.2.X | ? | | || ? | | || ? | 2.2 will be discontinued in 2024 (see End-of-life announcements in https://www.gnupg.org/download/index.html). While I can't speak for upstream, I expect 2.3 to disappear once 2.4 is announced. So 2.3 users could be moved automatically to 2.4/stable, but they'll have to manually upgrade to the new 2.5/devel branch when it becomes available. My two cents, -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: gnupg update
On 2021/07/05 11:25, Edd Barrett wrote: > Hi, > > On Mon, Jul 05, 2021 at 12:13:38PM +0200, Jeremie Courreges-Anglas wrote: > > ok jca@ fwiw but as I said Edd has a wip update to 2.3.1. > > In hindsight, I think using Stuart's 2.2.29 diff would be better. > Upstream describes 2.3.x as "the start of public testing releases". I > think we should give users the most stable packages we can. > > In addition to sthen@'s diff, here's updates to libksba and pinentry. > > If those are committed, then the only out-of-date gnupg-related > component would be gpgme (which I've not had time to look at yet, > sorry). I can take a look at gpgme. > With libksba, although upstream did major bumps, I can't see any reason > to do so based on the changes I see to the public API. Hence I've not > bumped our SO version, but someone should double check my work. We could > just bump it to be sure. They replaced some parts in the middle of struct ksba_cms_s, this struct is in src/cms.h which isn't in an installed header but it is used in prototypes that are in the installed ksba.h. So I'm a bit unsure whether bumping is needed or not but I think I'd go with "if in doubt, bump" here to be on the safe side. Otherwise those are OK sthen@
Re: update: editors/neovim --> 0.5.0
On Mon, Jul 05, 2021 at 11:32:21AM +0200, Paco Esteban wrote: > That should do for py-neovim (included the quirks patch too). I made it > py3 only while on it. I tested the upgrade from the Python 2 version to Python 3, and that seems to have worked. Nothing is apparently broken in neovim either. I'll run with this for a few days to see if we can shake out any bugs. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: gnupg update
On 2021/07/05 12:13, Jeremie Courreges-Anglas wrote: > On Mon, Jul 05 2021, Stuart Henderson wrote: > > There have been a few releases since the version in ports so I won't > > copy the whole lot here, but release notes are in > > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=NEWS;h=e37d5aa5d46276e0e3e462b7619c9678e374ab69;hb=695a879af81e895741109874b9ac0712e1afc994 > > FWIW I pinged edd@ about this yesterday. He replied with a wip diff > which includes an update to 2.3.1. 2.2 is the current stable branch, > 2.3 is the new devel branch (since 2021-04-07). > > I have no opinion whether we should use the stable or devel branch, I'll > just note that we have used the 2.1 devel branch in the past. > > > The doc/Makefile.in patch didn't apply, rather than updating it I just > > changed to rm'ing in post-install to save work for future updates. > > Makes sense to me. > > > OK? > > make test passes on amd64 and sparc64. > > ok jca@ fwiw but as I said Edd has a wip update to 2.3.1. Thanks. It feels to me a bit early to switch to the 2.3 branch as as the only version; the release announcements upstream currently say "may even be used for production purposes if either the risk of minor regressions is acceptable or the new features are important." If there's enough interest in running the development version, having the two in parallel might be a safer approach?
Re: gnupg update
Hi,
On Mon, Jul 05, 2021 at 12:13:38PM +0200, Jeremie Courreges-Anglas wrote:
> ok jca@ fwiw but as I said Edd has a wip update to 2.3.1.
In hindsight, I think using Stuart's 2.2.29 diff would be better.
Upstream describes 2.3.x as "the start of public testing releases". I
think we should give users the most stable packages we can.
In addition to sthen@'s diff, here's updates to libksba and pinentry.
If those are committed, then the only out-of-date gnupg-related
component would be gpgme (which I've not had time to look at yet,
sorry).
With libksba, although upstream did major bumps, I can't see any reason
to do so based on the changes I see to the public API. Hence I've not
bumped our SO version, but someone should double check my work. We could
just bump it to be sure.
Index: security/libksba/Makefile
===
RCS file: /cvs/ports/security/libksba/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- security/libksba/Makefile 25 Aug 2020 18:19:19 - 1.22
+++ security/libksba/Makefile 4 Jul 2021 20:00:23 -
@@ -2,10 +2,10 @@
COMMENT = X.509 library
-DISTNAME = libksba-1.4.0
+DISTNAME = libksba-1.6.0
CATEGORIES = security
-SHARED_LIBS = ksba 1.0# 20.0
+SHARED_LIBS = ksba 1.0# 22.0
MASTER_SITES = ${MASTER_SITE_GNUPG:=libksba/}
Index: security/libksba/distinfo
===
RCS file: /cvs/ports/security/libksba/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- security/libksba/distinfo 25 Aug 2020 18:19:19 - 1.7
+++ security/libksba/distinfo 4 Jul 2021 19:36:44 -
@@ -1,2 +1,2 @@
-SHA256 (libksba-1.4.0.tar.bz2) = v+ao6R/w9U2KMpUU20BmZwAMsgcjjt7Um1mXYb/KQbY=
-SIZE (libksba-1.4.0.tar.bz2) = 651319
+SHA256 (libksba-1.6.0.tar.bz2) = 2taD5vLZFdiAqkvtXOqaEVaQuJNbeKG74BZpGJMHpIs=
+SIZE (libksba-1.6.0.tar.bz2) = 662120
Index: security/pinentry/Makefile
===
RCS file: /cvs/ports/security/pinentry/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- security/pinentry/Makefile 12 Jul 2019 21:15:36 - 1.26
+++ security/pinentry/Makefile 4 Jul 2021 19:38:15 -
@@ -4,8 +4,7 @@ COMMENT-main = PIN or passphrase entry
COMMENT-gtk2 = PIN or passphrase entry dialog (gtk2 interface)
COMMENT-gnome3 =PIN or passphrase entry dialog (GNOME 3 interface)
-VERSION = 1.1.0
-REVISION = 0
+VERSION = 1.1.1
DISTNAME = pinentry-${VERSION}
CATEGORIES = security
EXTRACT_SUFX = .tar.bz2
Index: security/pinentry/distinfo
===
RCS file: /cvs/ports/security/pinentry/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- security/pinentry/distinfo 7 Dec 2017 22:00:04 - 1.7
+++ security/pinentry/distinfo 4 Jul 2021 19:38:22 -
@@ -1,2 +1,2 @@
-SHA256 (pinentry-1.1.0.tar.bz2) = aAdmhvpySikOpJzfDRwMFQCQfRt1mjvL++wCk+j1ZXA=
-SIZE (pinentry-1.1.0.tar.bz2) = 467702
+SHA256 (pinentry-1.1.1.tar.bz2) = zRKgZAE+0Y4u6EdeZpufWNsbIloBRN69uFpozs3bpX8=
+SIZE (pinentry-1.1.1.tar.bz2) = 515723
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: gnupg update
On Mon, Jul 05 2021, Stuart Henderson wrote:
> There have been a few releases since the version in ports so I won't
> copy the whole lot here, but release notes are in
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=NEWS;h=e37d5aa5d46276e0e3e462b7619c9678e374ab69;hb=695a879af81e895741109874b9ac0712e1afc994
FWIW I pinged edd@ about this yesterday. He replied with a wip diff
which includes an update to 2.3.1. 2.2 is the current stable branch,
2.3 is the new devel branch (since 2021-04-07).
I have no opinion whether we should use the stable or devel branch, I'll
just note that we have used the 2.1 devel branch in the past.
> The doc/Makefile.in patch didn't apply, rather than updating it I just
> changed to rm'ing in post-install to save work for future updates.
Makes sense to me.
> OK?
make test passes on amd64 and sparc64.
ok jca@ fwiw but as I said Edd has a wip update to 2.3.1.
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/gnupg/Makefile,v
> retrieving revision 1.119
> diff -u -p -r1.119 Makefile
> --- Makefile 17 Jan 2021 15:13:34 - 1.119
> +++ Makefile 5 Jul 2021 08:56:45 -
> @@ -2,8 +2,7 @@
>
> COMMENT =GNU privacy guard - a free PGP replacement
>
> -DISTNAME = gnupg-2.2.23
> -REVISION = 2
> +DISTNAME = gnupg-2.2.29
> CATEGORIES = security
>
> MASTER_SITES = ${MASTER_SITE_GNUPG:=gnupg/}
> @@ -45,8 +44,8 @@ DEBUG_PACKAGES =${BUILD_PACKAGES}
>
> RUN_DEPENDS =security/pinentry
>
> -TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH}
> -PORTHOME=${WRKDIR}
> +TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH}
> +PORTHOME = ${WRKDIR}
>
> USE_GMAKE = Yes
>
> @@ -60,5 +59,6 @@ CONFIGURE_ARGS += --enable-gpgtar \
> post-install:
> ln -sf gpg ${PREFIX}/bin/gpg2
> ln -sf gpgv ${PREFIX}/bin/gpgv2
> + rm -rf ${PREFIX}/share/doc/gnupg/examples/systemd-user
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/gnupg/distinfo,v
> retrieving revision 1.33
> diff -u -p -r1.33 distinfo
> --- distinfo 5 Oct 2020 19:46:17 - 1.33
> +++ distinfo 5 Jul 2021 08:56:45 -
> @@ -1,2 +1,2 @@
> -SHA256 (gnupg-2.2.23.tar.bz2) = ELVeSdeLPknx7bWNdUHsva2S3a7riFtvSG7SPRzR2lw=
> -SIZE (gnupg-2.2.23.tar.bz2) = 7099806
> +SHA256 (gnupg-2.2.29.tar.bz2) = OdB820UkgY+evOSSlJMZdK9QRRnmp0dsUunTj8C9DMk=
> +SIZE (gnupg-2.2.29.tar.bz2) = 7215986
> Index: patches/patch-doc_Makefile_in
> ===
> RCS file: patches/patch-doc_Makefile_in
> diff -N patches/patch-doc_Makefile_in
> --- patches/patch-doc_Makefile_in 5 Oct 2020 19:46:17 - 1.11
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,20 +0,0 @@
> -$OpenBSD: patch-doc_Makefile_in,v 1.11 2020/10/05 19:46:17 jca Exp $
> -
> -Index: doc/Makefile.in
> doc/Makefile.in.orig
> -+++ doc/Makefile.in
> -@@ -476,14 +476,6 @@ libcommontls = ../common/libcommontls.a
> - libcommontlsnpth = ../common/libcommontlsnpth.a
> - examples = examples/README examples/scd-event examples/trustlist.txt
> \
> -examples/vsnfd.prf examples/debug.prf\
> -- examples/systemd-user/README \
> -- examples/systemd-user/dirmngr.service\
> -- examples/systemd-user/dirmngr.socket \
> -- examples/systemd-user/gpg-agent.service \
> -- examples/systemd-user/gpg-agent.socket \
> -- examples/systemd-user/gpg-agent-ssh.socket \
> -- examples/systemd-user/gpg-agent-browser.socket \
> -- examples/systemd-user/gpg-agent-extra.socket \
> -examples/gpgconf.conf examples/pwpattern.list
> -
> - helpfiles = help.txt help.be.txt help.ca.txt help.cs.txt\
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/security/gnupg/pkg/PLIST,v
> retrieving revision 1.32
> diff -u -p -r1.32 PLIST
> --- pkg/PLIST 5 Oct 2020 19:46:17 - 1.32
> +++ pkg/PLIST 5 Jul 2021 08:56:45 -
> @@ -38,7 +38,6 @@ bin/gpgv2
> @man man/man1/gpgtar.1
> @man man/man1/gpgv.1
> @man man/man1/scdaemon.1
> -@man man/man1/symcryptrun.1
> @man man/man1/watchgnupg.1
> @man man/man7/gnupg.7
> @man man/man8/addgnupghome.8
> @@ -56,13 +55,14 @@ share/doc/gnupg/OpenPGP
> share/doc/gnupg/README
> share/doc/gnupg/TRANSLATE
> share/doc/gnupg/examples/
> +share/doc/gnupg/examples/Automatic.prf
> share/doc/gnupg/examples/README
> +share/doc/gnupg/examples/VS-NfD.prf
> share/doc/gnupg/examples/debug.prf
> share/doc/gnupg/examples/gpgconf.conf
> share/doc/gnupg/examples/pwpattern.list
> share/doc/gnupg/examples/scd-event
> share/doc/gnupg/exampl
Re: update games/mnemosyne 2.8
On Sun, Jul 04 2021, Grégoire Jadi wrote: > Hi, > > Please find attached an update for Mnemosyne 2.8. > > I tested the application GUI, web server and sync server; ran > update-plist and portcheck. > > Here is the Changelog: > > Mnemosyne 2.8 : 2021-06-28 > > - Added an option to stop showing cards as soon as they reach a certain > number of successful retention reps. This makes sure that your review load > does not keep increasing over the years. > - The card browser now also shows the number of learning and review reps > since the last lapse. > - Making storing of client sync password optional. Warn that the client > stores > the password in plain text. The server now stores a password hash (patch > by J5lx). > - Make sure that Mnemosyne is associated with its icon under Wayland (patch > by J5lx). > - Fix error when using the sync server and the web server at the same time > (patch by Gregoire Jadi). > - Improve Python 3.9 compatibility (patch by Julien Puydt). > > Best, Committed, thanks. Lightly tested, seems to work properly. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: update: editors/neovim --> 0.5.0
On Sun, 04 Jul 2021, Edd Barrett wrote:
> Hi,
>
> Thanks for working on neovim. I'd not had a chance to look yet!
>
> On Sun, Jul 04, 2021 at 07:26:10PM +0200, Paco Esteban wrote:
> > > - I think we want to add -DCMAKE_SUPPRESS_REGENERATION=ON in
> > > pre-configure
>
> If that's what we do now, I'm fine with it.
>
> > > 2.) -- Found LuaJit: /usr/local/lib/libluajit-5.1.so.1.0
> > >
> > > - neovim is looking for luajit at configure step does it needs that at
> > > runtime too?
> >
> > I don't think so, we pass -DPREFER_LUA=ON to CONFIGURE_ARGS.
>
> I've always forced LuaJIT off, as it'd require all of the Lua deps to be
> sub-packaged for LuaJIT, which is no small task.
>
> Portwise this looks good. I'll run with this diff for a few days and see
> how I get on.
>
> (There's also a new pynvim (devel/py-neovim, for historical reasons)).
That should do for py-neovim (included the quirks patch too). I made it
py3 only while on it.
diff eb6ad31e9211e6034806408c424aa25f6fe6ee04 /usr/ports
blob - b9db1cb6e98b5b33c77b633de76d9674128b0182
file + editors/py-neovim/Makefile
--- editors/py-neovim/Makefile
+++ editors/py-neovim/Makefile
@@ -2,13 +2,12 @@
COMMENT = Python plugin support for Neovim
-MODPY_EGG_VERSION =0.4.1
+MODPY_EGG_VERSION =0.4.3
DISTNAME = pynvim-${MODPY_EGG_VERSION}
PKGNAME = py-neovim-${MODPY_EGG_VERSION}
-REVISION = 0
CATEGORIES = editors devel
-HOMEPAGE = https://github.com/neovim/python-client
+HOMEPAGE = https://github.com/neovim/pynvim
MAINTAINER = Edd Barrett
# Apache-2.0
@@ -19,7 +18,7 @@ MODPY_SETUPTOOLS =Yes
MODPY_PI = Yes
FLAVORS = python3
-FLAVOR ?=
+FLAVOR = python3
RUN_DEPENDS = net/py-msgpack${MODPY_FLAVOR} \
devel/py-uv${MODPY_FLAVOR} \
blob - a5d330b646f3d47533eb5102c3f0c5051bb7973c
file + editors/py-neovim/distinfo
--- editors/py-neovim/distinfo
+++ editors/py-neovim/distinfo
@@ -1,2 +1,2 @@
-SHA256 (pynvim-0.4.1.tar.gz) = VekY1mRlTPocmInT2+fGPp8zjfXUlHFmP3jVTIXoTFg=
-SIZE (pynvim-0.4.1.tar.gz) = 41939
+SHA256 (pynvim-0.4.3.tar.gz) = OnlTeL3l6AkvvrOhqZvpxhPSaFVC8dsOXG/UZ+7Vbf8=
+SIZE (pynvim-0.4.3.tar.gz) = 56239
blob - 14894d2a31fadfb0b33d950c254566ba532f0990
file + editors/py-neovim/pkg/PLIST
--- editors/py-neovim/pkg/PLIST
+++ editors/py-neovim/pkg/PLIST
@@ -1,4 +1,6 @@
@comment $OpenBSD: PLIST,v 1.4 2019/03/17 13:15:34 edd Exp $
+@conflict editors/py-neovim-*
+@pkgpath editors/py-neovim
lib/python${MODPY_VERSION}/site-packages/neovim/
lib/python${MODPY_VERSION}/site-packages/neovim/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/neovim/${MODPY_PYCACHE}/
diff eb6ad31e9211e6034806408c424aa25f6fe6ee04 /usr/ports
blob - ba0899f909dcec7cf737ed377beb1d29986edd62
file + devel/quirks/Makefile
--- devel/quirks/Makefile
+++ devel/quirks/Makefile
@@ -5,7 +5,7 @@ CATEGORIES =devel databases
DISTFILES =
# API.rev
-PKGNAME = quirks-4.24
+PKGNAME = quirks-4.25
PKG_ARCH = *
MAINTAINER = Marc Espie
blob - 301ed7bc6d561381c2b7d8fdebc22e80470c3c66
file + devel/quirks/files/Quirks.pm
--- devel/quirks/files/Quirks.pm
+++ devel/quirks/files/Quirks.pm
@@ -469,6 +469,7 @@ my $stem_extensions = {
'py-libarchive-c' => 'py3-libarchive-c',
'py-minimalmodbus' => 'py3-minimalmodbus',
'baresip-gtk2' => 'baresip-gtk',
+ 'py-neovim' => 'py3-neovim'
};
my $obsolete_reason = {};
--
Paco Esteban.
0x5818130B8A6DBC03
Re: broot, a better filesystem navigator
Le Thu, Jan 16, 2020 at 03:31:03PM +0100, Landry Breuil a écrit : > Because we definitely need more rust things to slow down bulks ? > > See https://dystroy.org/broot for features, apparently works better if > integrated with bash or zsh, havent looked at how to integrate it as a > ksh function (cf > https://dystroy.org/broot/documentation/installation/##installation-completion-the-br-shell-function) new version, just fishing for okays :) Landry broot-1.6.1.tgz Description: application/tar-gz
Re: NEW: net/bore (needs help from someone with CVS access)
On Mon, Jul 05, 2021 at 03:38:24PM +0800, Delan Azabani wrote:
> G’day ports@,
>
> I’ve attached my first port: net/bore. Any feedback would be welcome!
>
> Makefile was based on the one for textproc/ripgrep at first, but I’ve
> since cleaned it up against the porting guide and Makefile.template.
>
> Builds and runs well on amd64, but I would especially appreciate any
> testing on one of the other platforms with a Rust compiler.
Some simple runtime testing indicates that it works fine on sparc64.
'make test' succeeds on both amd64 and sparc64.
> One thing I’m unsure of is the portcheck(1) lint “{Makefile,pkg/PLIST}
> does not have $OpenBSD$ RCS tag at the top”. Does this only apply once
> the port is imported by someone with CVS access?
The first line of the Makefile should be '# $OpenBSD$', followed by an
empty line. This tag will be expanded by cvs on commit (see keyword
substitution in rcs(1) for details).
For pkg/PLIST, generate it using 'make update-plist'. It will add
'@comment $OpenBSD: PLIST,v$' as a first line to what you did manually.
With these two tweaks, portcheck will be happy (except for the overlong
line).
Regarding unveil: with pledge dns, a number of files are made available
by the BYPASSUNVEIL mechanism (see /usr/src/sys/kern/kern_pledge.c):
/* DNS needs /etc/{resolv.conf,hosts,services,protocols}. */
so I think it would be sufficient if you removed all filesystem access
via 'expect_unveil("", "");' (I haven't tested this).
I'm unsure if 'MODCARGO_RUSTFLAGS =-C debuginfo=0' is desirable, but
I don't know if/how cargo.port.mk handles debug packages.
>
> Cheers,
> Delan
>
> Homepage:
> https://crates.io/crates/bore
>
> DESCR:
> DNS query tool. Provides highlighting by default and some useful protocol
> debugging features, and uses pledge(2) and unveil(2) on OpenBSD.
gnupg update
There have been a few releases since the version in ports so I won't
copy the whole lot here, but release notes are in
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=NEWS;h=e37d5aa5d46276e0e3e462b7619c9678e374ab69;hb=695a879af81e895741109874b9ac0712e1afc994
The doc/Makefile.in patch didn't apply, rather than updating it I just
changed to rm'ing in post-install to save work for future updates.
OK?
Index: Makefile
===
RCS file: /cvs/ports/security/gnupg/Makefile,v
retrieving revision 1.119
diff -u -p -r1.119 Makefile
--- Makefile17 Jan 2021 15:13:34 - 1.119
+++ Makefile5 Jul 2021 08:56:45 -
@@ -2,8 +2,7 @@
COMMENT = GNU privacy guard - a free PGP replacement
-DISTNAME = gnupg-2.2.23
-REVISION = 2
+DISTNAME = gnupg-2.2.29
CATEGORIES = security
MASTER_SITES = ${MASTER_SITE_GNUPG:=gnupg/}
@@ -45,8 +44,8 @@ DEBUG_PACKAGES = ${BUILD_PACKAGES}
RUN_DEPENDS = security/pinentry
-TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH}
-PORTHOME=${WRKDIR}
+TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH}
+PORTHOME = ${WRKDIR}
USE_GMAKE =Yes
@@ -60,5 +59,6 @@ CONFIGURE_ARGS += --enable-gpgtar \
post-install:
ln -sf gpg ${PREFIX}/bin/gpg2
ln -sf gpgv ${PREFIX}/bin/gpgv2
+ rm -rf ${PREFIX}/share/doc/gnupg/examples/systemd-user
.include
Index: distinfo
===
RCS file: /cvs/ports/security/gnupg/distinfo,v
retrieving revision 1.33
diff -u -p -r1.33 distinfo
--- distinfo5 Oct 2020 19:46:17 - 1.33
+++ distinfo5 Jul 2021 08:56:45 -
@@ -1,2 +1,2 @@
-SHA256 (gnupg-2.2.23.tar.bz2) = ELVeSdeLPknx7bWNdUHsva2S3a7riFtvSG7SPRzR2lw=
-SIZE (gnupg-2.2.23.tar.bz2) = 7099806
+SHA256 (gnupg-2.2.29.tar.bz2) = OdB820UkgY+evOSSlJMZdK9QRRnmp0dsUunTj8C9DMk=
+SIZE (gnupg-2.2.29.tar.bz2) = 7215986
Index: patches/patch-doc_Makefile_in
===
RCS file: patches/patch-doc_Makefile_in
diff -N patches/patch-doc_Makefile_in
--- patches/patch-doc_Makefile_in 5 Oct 2020 19:46:17 - 1.11
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,20 +0,0 @@
-$OpenBSD: patch-doc_Makefile_in,v 1.11 2020/10/05 19:46:17 jca Exp $
-
-Index: doc/Makefile.in
doc/Makefile.in.orig
-+++ doc/Makefile.in
-@@ -476,14 +476,6 @@ libcommontls = ../common/libcommontls.a
- libcommontlsnpth = ../common/libcommontlsnpth.a
- examples = examples/README examples/scd-event examples/trustlist.txt \
- examples/vsnfd.prf examples/debug.prf\
-- examples/systemd-user/README \
-- examples/systemd-user/dirmngr.service\
-- examples/systemd-user/dirmngr.socket \
-- examples/systemd-user/gpg-agent.service \
-- examples/systemd-user/gpg-agent.socket \
-- examples/systemd-user/gpg-agent-ssh.socket \
-- examples/systemd-user/gpg-agent-browser.socket \
-- examples/systemd-user/gpg-agent-extra.socket \
- examples/gpgconf.conf examples/pwpattern.list
-
- helpfiles = help.txt help.be.txt help.ca.txt help.cs.txt \
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/gnupg/pkg/PLIST,v
retrieving revision 1.32
diff -u -p -r1.32 PLIST
--- pkg/PLIST 5 Oct 2020 19:46:17 - 1.32
+++ pkg/PLIST 5 Jul 2021 08:56:45 -
@@ -38,7 +38,6 @@ bin/gpgv2
@man man/man1/gpgtar.1
@man man/man1/gpgv.1
@man man/man1/scdaemon.1
-@man man/man1/symcryptrun.1
@man man/man1/watchgnupg.1
@man man/man7/gnupg.7
@man man/man8/addgnupghome.8
@@ -56,13 +55,14 @@ share/doc/gnupg/OpenPGP
share/doc/gnupg/README
share/doc/gnupg/TRANSLATE
share/doc/gnupg/examples/
+share/doc/gnupg/examples/Automatic.prf
share/doc/gnupg/examples/README
+share/doc/gnupg/examples/VS-NfD.prf
share/doc/gnupg/examples/debug.prf
share/doc/gnupg/examples/gpgconf.conf
share/doc/gnupg/examples/pwpattern.list
share/doc/gnupg/examples/scd-event
share/doc/gnupg/examples/trustlist.txt
-share/doc/gnupg/examples/vsnfd.prf
share/doc/pkg-readmes/${PKGSTEM}
share/gnupg/
share/gnupg/distsigkey.gpg
NEW: net/bore (needs help from someone with CVS access)
G’day ports@,
I’ve attached my first port: net/bore. Any feedback would be welcome!
Makefile was based on the one for textproc/ripgrep at first, but I’ve
since cleaned it up against the porting guide and Makefile.template.
Builds and runs well on amd64, but I would especially appreciate any
testing on one of the other platforms with a Rust compiler.
One thing I’m unsure of is the portcheck(1) lint “{Makefile,pkg/PLIST}
does not have $OpenBSD$ RCS tag at the top”. Does this only apply once
the port is imported by someone with CVS access?
Cheers,
Delan
Homepage:
https://crates.io/crates/bore
DESCR:
DNS query tool. Provides highlighting by default and some useful protocol
debugging features, and uses pledge(2) and unveil(2) on OpenBSD.
bore.tar
Description: Binary data
