Re: [NEW] math/h5py
On Mon, Jan 20, 2020 at 02:46:06PM +0100, Martin Reindl wrote: > h5py is a thin, pythonic wrapper around the HDF5 library. > > Tests on amd64: 526 passed, 20 skipped, 3 xfailed, 2 warnings > Further tests, for example on sparc64 welcome (recent experience shows > hdf5-related ports are always problematic on non base-clang archs)! > Please disregard this for now because it wants to pull in a extra dependency during build which just is not there yet. -m
Re: update: devel/py-country
On Tue, Jan 21, 2020 at 08:50:01PM +, Stuart Henderson wrote:
> py2 still works for now, but perhaps we should add a comment to the port
> Makefile mentioning this though so that people doing future updates
> make sure they test there ..
> > @@ -1,4 +1,6 @@
> > @comment $OpenBSD: PLIST,v 1.8 2019/02/17 20:22:22 sthen Exp $
> > +lib/python${MODPY_VERSION}/
> > +lib/python${MODPY_VERSION}/site-packages/
> I'm not sure how these lines were added, the directories come from a
> dependency though and don't need listing. update-plist removes them here ..
I've commited this update with a comment above the FLAVORS mentioning
the need to check python2 compatibility for future updates and eliminating
these two extraneous lines from the PLIST.
--Kurt
Re: [update] shells/fish with fixes for fish_config and vmctl completion
On Tue, 21 Jan 2020 at 17:32:51 -0700, Aaron Bieber wrote:
> Hi,
>
> This diff does two things:
>
> - Fix vmctl completion. Currently the hostname bits are off.
> - Fix 'fish_config' now that browsers are unveil'd.
>
> Both patches have been sent upstream:
> https://github.com/fish-shell/fish-shell/pull/6523
> https://github.com/fish-shell/fish-shell/pull/6522
>
> OK?
>
Previous diff was incorrect. Here is a fixed version that uses python 3 and has
a re-gen'd PLIST
diff --git a/shells/fish/Makefile b/shells/fish/Makefile
index 41e58668faf..87154ffe195 100644
--- a/shells/fish/Makefile
+++ b/shells/fish/Makefile
@@ -4,7 +4,7 @@ COMMENT = friendly interactive shell
V =3.0.2
DISTNAME = fish-$V
-REVISION = 1
+REVISION = 2
CATEGORIES = shells
@@ -37,6 +37,7 @@ LIB_DEPENDS = devel/pcre2 \
RUN_DEPENDS = misc/gnugetopt
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
MODPY_ADJ_FILES = share/tools/create_manpage_completions.py \
share/tools/deroff.py \
share/tools/web_config/webconfig.py
diff --git a/shells/fish/patches/patch-share_completions_vmctl_fish
b/shells/fish/patches/patch-share_completions_vmctl_fish
new file mode 100644
index 000..023c845466d
--- /dev/null
+++ b/shells/fish/patches/patch-share_completions_vmctl_fish
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+https://github.com/fish-shell/fish-shell/pull/6523
+
+Index: share/completions/vmctl.fish
+--- share/completions/vmctl.fish.orig
share/completions/vmctl.fish
+@@ -1,4 +1,11 @@
+
++function __fish_get_vmctl_vms
++ for line in (vmctl status | string match -e -v "MAXMEM");
++ set a (string split " " $line)
++ and printf "%s " $a[-1]
++ end
++end
++
+ complete -c vmctl -xa 'console create load log reload reset start status stop
pause unpause send receive' -n 'not __fish_seen_subcommand_from list console
create load log reload reset start status stop pause unpause send receive'
+-complete -c vmctl -n '__fish_seen_subcommand_from console reload reset start
status stop pause unpause send receive' -xa '(vmctl status | string match -e -v
"MAXMEM" | string replace -r "^(\s+\S+\s+){7}" "")'
++complete -c vmctl -n '__fish_seen_subcommand_from console reload reset start
status stop pause unpause send receive' -xa (__fish_get_vmctl_vms)
+
diff --git a/shells/fish/patches/patch-share_tools_web_config_webconfig_py
b/shells/fish/patches/patch-share_tools_web_config_webconfig_py
new file mode 100644
index 000..d2dfdb345ea
--- /dev/null
+++ b/shells/fish/patches/patch-share_tools_web_config_webconfig_py
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+https://github.com/fish-shell/fish-shell/pull/6522
+
+Index: share/tools/web_config/webconfig.py
+--- share/tools/web_config/webconfig.py.orig
share/tools/web_config/webconfig.py
+@@ -1172,10 +1172,15 @@ url = 'http://localhost:%d/%s/%s' % (PORT, authkey, in
+ # Create temporary file to hold redirect to real server. This prevents
exposing
+ # the URL containing the authentication key on the command line (see
+ # CVE-2014-2914 or https://github.com/fish-shell/fish-shell/issues/1438).
+-if 'XDG_CACHE_HOME' in os.environ:
+-dirname = os.path.expanduser(os.path.expandvars('$XDG_CACHE_HOME/fish/'))
++if platform.system() == 'OpenBSD':
++# On OpenBSD the main browsers use unveil, which prevents file access
++# to most of the disk. ~/Downloads is unrestricted in both, so use that.
++dirname = os.path.expanduser('~/Downloads/fish/')
+ else:
+-dirname = os.path.expanduser('~/.cache/fish/')
++if 'XDG_CACHE_HOME' in os.environ:
++dirname =
os.path.expanduser(os.path.expandvars('$XDG_CACHE_HOME/fish/'))
++else:
++dirname = os.path.expanduser('~/.cache/fish/')
+
+ os.umask(0o0077)
+ try:
diff --git a/shells/fish/pkg/PLIST b/shells/fish/pkg/PLIST
index bde804df0b2..fc720cee435 100644
--- a/shells/fish/pkg/PLIST
+++ b/shells/fish/pkg/PLIST
@@ -921,11 +921,14 @@ share/fish/man/man1/
@man share/fish/man/man1/wait.1
@man share/fish/man/man1/while.1
share/fish/tools/
+${MODPY_COMMENT}share/fish/tools/${MODPY_PYCACHE}/
+share/fish/tools/${MODPY_PYCACHE}create_manpage_completions.${MODPY_PYC_MAGIC_TAG}pyc
+share/fish/tools/${MODPY_PYCACHE}deroff.${MODPY_PYC_MAGIC_TAG}pyc
share/fish/tools/create_manpage_completions.py
-share/fish/tools/create_manpage_completions.pyc
share/fish/tools/deroff.py
-share/fish/tools/deroff.pyc
share/fish/tools/web_config/
+${MODPY_COMMENT}share/fish/tools/web_config/${MODPY_PYCACHE}/
+share/fish/tools/web_config/${MODPY_PYCACHE}webconfig.${MODPY_PYC_MAGIC_TAG}pyc
share/fish/tools/web_config/delete.png
share/fish/tools/web_config/favicon.png
share/fish/tools/web_config/fishconfig.css
@@ -963,17 +966,35 @@
share/fish/tools/web_config/sample_prompts/screen_savvy.fish
share/fish/tools/web_config/sample_prompts/sorin.fish
share/fish/tools/w
Re: mu: use ports-gcc
Xiyue Deng writes:
> Hi,
>
> Currently mu requires ports-clang which I think is because there was a
> time that GCC 4.9 didn't support C++14. Now that GCC is on 8.3, mu can
> be unblocked for GCC archs as well. I didn't change patch level as I
> think there is no visible change, but correct me if I'm wrong.
>
> Tested on mips64el/loongson.
>
CCing maintainer Stefan.
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/mu/Makefile,v
> retrieving revision 1.18
> diff -u -p -r1.18 Makefile
> --- Makefile 21 Jul 2019 00:10:04 - 1.18
> +++ Makefile 22 Jan 2020 02:16:59 -
> @@ -14,7 +14,7 @@ PERMIT_PACKAGE= Yes
>
> WANTLIB+=assuan c ffi gio-2.0 glib-2.0 gmime-3.0 gmodule-2.0
> WANTLIB+=gobject-2.0 gpg-error gpgme gthread-2.0 iconv
> -WANTLIB+=intl json-glib-1.0 m pcre pthread ${COMPILER_LIBCXX}
> +WANTLIB+=intl json-glib-1.0 m pcre pthread
> WANTLIB+=uuid xapian z
>
> MASTER_SITES=https://github.com/djcb/mu/releases/download/1.2/
> @@ -30,7 +30,7 @@ LIB_DEPENDS=databases/xapian-core \
>
>
> # C++14 required
> -COMPILER=base-clang ports-clang
> +COMPILER=base-clang ports-gcc
>
> AUTOCONF_VERSION=2.69
> AUTOMAKE_VERSION=1.15
signature.asc
Description: PGP signature
mu: use ports-gcc
Hi,
Currently mu requires ports-clang which I think is because there was a
time that GCC 4.9 didn't support C++14. Now that GCC is on 8.3, mu can
be unblocked for GCC archs as well. I didn't change patch level as I
think there is no visible change, but correct me if I'm wrong.
Tested on mips64el/loongson.
Index: Makefile
===
RCS file: /cvs/ports/mail/mu/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile21 Jul 2019 00:10:04 - 1.18
+++ Makefile22 Jan 2020 02:16:59 -
@@ -14,7 +14,7 @@ PERMIT_PACKAGE= Yes
WANTLIB+= assuan c ffi gio-2.0 glib-2.0 gmime-3.0 gmodule-2.0
WANTLIB+= gobject-2.0 gpg-error gpgme gthread-2.0 iconv
-WANTLIB+= intl json-glib-1.0 m pcre pthread ${COMPILER_LIBCXX}
+WANTLIB+= intl json-glib-1.0 m pcre pthread
WANTLIB+= uuid xapian z
MASTER_SITES= https://github.com/djcb/mu/releases/download/1.2/
@@ -30,7 +30,7 @@ LIB_DEPENDS= databases/xapian-core \
# C++14 required
-COMPILER= base-clang ports-clang
+COMPILER= base-clang ports-gcc
AUTOCONF_VERSION= 2.69
AUTOMAKE_VERSION= 1.15
signature.asc
Description: PGP signature
Re: UPDATE: mail/msmtp 1.6.6p1 -> 1.8.6
Friendly ping. Xiyue Deng writes: > Stuart Henderson writes: > >> I'd prefer not to be CC'd on ports that I don't have anything to do with, >> ports@ is enough. >> > > Sorry about this Stuart. It's just that it has been weeks since I sent > out the diff and there is not dedicated maintainer for this port, and > you have been kindly offering your help. I don't know how long I have to > keep bumping it before it is submitted. > > It could be helpful if there was a bug tracker for such kind of ports so > that it doesn't get buried like in the mailing list. > >> >> On 2020/01/12 03:13, Xiyue Deng wrote: >>> Friendly ping. >>> >>> Xiyue Deng writes: >>> >>> > Friendly ping. CCing Stuart in case he's interested. >>> > >>> > Xiyue Deng writes: >>> > >>> >> Friendly ping. >>> >> >>> >> Xiyue Deng writes: >>> >> >>> >>> Dear ports maintainers, >>> >>> >>> >>> I have updated msmtp to the latest version (1.8.6) in ports. It >>> >>> includes the following changes: >>> >>> >>> >>> * GnuTLS is recommended and deprecated OpenSSL. >>> >>> - So now GnuTLS is part of the build dependencies. >>> >>> >>> >>> * Use libidn2 instead of the older libidn. >>> >>> - Configure switch remains as "--with-libidn". >>> >>> >>> >>> * Refreshed patches to apply cleanly. >>> >>> >>> >>> I also have a few questions when working on this ports: >>> >>> >>> >>> * Many of the patches just replace "#!/usr/bin/env bash" to >>> >>> "#!/bin/sh". Now most of scripts are changed to use "#!/usr/bin/env >>> >>> sh" which should now be the same thing. Should we just drop those >>> >>> patches? >>> >>> >>> >>> * One of the patches changes the system /etc/msmtprc to provide an >>> >>> "account default" that listens on localhost:25, which will then use >>> >>> smtpd as server by default. I think the intention is to provide a >>> >>> working configure that works out of the box. However this may not do >>> >>> what you want because if one try to configure an account in a user >>> >>> configuration and somehow it contains errors (e.g. not properly >>> >>> provide a "from" address), msmtp will just send the mail through smtpd >>> >>> and returns OK which will result in the mail stuck in the system mail >>> >>> queue forever. So my suggestion is to leave this file untouched so >>> >>> that the system /etc/msmtprc will just provide a fake "account >>> >>> default" and any mail not handled with a user provided account will >>> >>> fail immediately. >>> >>> >>> >>> Tested on mips64el/loongson on 6.6-stable. Please let me know what you >>> >>> think. The diff is attached. >>> >>> >>> >>> Index: Makefile >>> >>> === >>> >>> RCS file: /cvs/ports/mail/msmtp/Makefile,v >>> >>> retrieving revision 1.47 >>> >>> diff -u -p -r1.47 Makefile >>> >>> --- Makefile12 Jul 2019 20:47:30 - 1.47 >>> >>> +++ Makefile21 Dec 2019 13:54:18 - >>> >>> @@ -2,27 +2,27 @@ >>> >>> >>> >>> COMMENT = SMTP plugin for MUAs >>> >>> >>> >>> -DISTNAME = msmtp-1.6.6 >>> >>> +DISTNAME = msmtp-1.8.6 >>> >>> CATEGORIES = mail >>> >>> -REVISION = 1 >>> >>> >>> >>> HOMEPAGE = https://marlam.de/msmtp/ >>> >>> >>> >>> # GPLv3 >>> >>> PERMIT_PACKAGE = Yes >>> >>> >>> >>> -WANTLIB = c crypto iconv idn intl ssl >>> >>> +WANTLIB = c crypto iconv idn2 intl gnutls >>> >>> >>> >>> MASTER_SITES = https://marlam.de/msmtp/releases/ >>> >>> EXTRACT_SUFX = .tar.xz >>> >>> >>> >>> -LIB_DEPENDS = devel/libidn >>> >>> +LIB_DEPENDS = devel/libidn2 \ >>> >>> + security/gnutls >>> >>> >>> >>> SEPARATE_BUILD = Yes >>> >>> CONFIGURE_STYLE = gnu >>> >>> CONFIGURE_ARGS = --with-libgsasl=no \ >>> >>> --with-libidn=yes \ >>> >>> - --with-tls=openssl \ >>> >>> + --with-tls=gnutls \ >>> >>> --without-libsecret >>> >>> >>> >>> post-install: >>> >>> Index: distinfo >>> >>> === >>> >>> RCS file: /cvs/ports/mail/msmtp/distinfo,v >>> >>> retrieving revision 1.30 >>> >>> diff -u -p -r1.30 distinfo >>> >>> --- distinfo26 Mar 2017 13:34:06 - 1.30 >>> >>> +++ distinfo21 Dec 2019 13:54:18 - >>> >>> @@ -1,2 +1,2 @@ >>> >>> -SHA256 (msmtp-1.6.6.tar.xz) = >>> >>> 2hXbH2K9AgH85TEK24nIYYi+kc10W3yztiuBpQHn+14= >>> >>> -SIZE (msmtp-1.6.6.tar.xz) = 283744 >>> >>> +SHA256 (msmtp-1.8.6.tar.xz) = >>> >>> ZiXxR0MMZbqFJ/UsT+XU0zVS08D7bXk7p9+BmjswQuE= >>> >>> +SIZE (msmtp-1.8.6.tar.xz) = 339732 >>> >>> Index: patches/patch-doc_msmtprc-system_example >>> >>> === >>> >>> RCS file: >>> >>> /cvs/ports/mail/msmtp/patches/patch-doc_msmtprc-system_example,v >>> >>> retrieving revision 1.1 >>> >>> diff -
Re: [NEW] textproc/scdoc
On Sun, 19 Jan 2020 at 23:35:18 -0500, Raymond E. Pasco wrote: > This is a simple man page generation language. > > The only patch is to some tests, which failed because of errors in > the tests themselves rather than program errors. > > I'm not experienced at OpenBSD ports; feedback is appreciated. This is pretty similar to what I have in wip: https://github.com/jasperla/openbsd-wip/blob/master/textproc/scdoc/Makefile I _think_ it needs WANTLIB, bit I am not 100% sure on that. Once that's sorted, OK abieber@ for import! Side-note: If you are looking to import aerc, I have a wip of that as well: https://github.com/jasperla/openbsd-wip/tree/master/mail/aerc (might have some pointers :D) -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: [NEW] textproc/scdoc
On Sun, January 19, 2020 11:35 pm, Raymond E. Pasco wrote:
> This is a simple man page generation language.
>
> The only patch is to some tests, which failed because of errors in
> the tests themselves rather than program errors.
>
> I'm not experienced at OpenBSD ports; feedback is appreciated.
>
I gave it a test. I was thinking about porting this as a dependency of aerc.
I would change the deletion of the test patch backup to just before
running tests. Deleting it right after applying patches doesn't leave it
around for debugging patch issues.
pre-test:
rm ${WRKSRC}/test/*.orig
Otherwise, seems to check out. I'm not a commiter, though. :)
Re: UPDATE: Nextcloud-18.0.0
On Tue, 21 Jan 2020 at 11:44:07 +0100, Gonzalo L. Rodriguez wrote: > Hello, > > Update for Nextcloud to 18.0.0: > > https://nextcloud.com/changelog/ > > OK? Comments? OK abieber@ > > Cheers.- > > -- > > - gonzalo -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
[update] shells/fish with fixes for fish_config and vmctl completion
Hi,
This diff does two things:
- Fix vmctl completion. Currently the hostname bits are off.
- Fix 'fish_config' now that browsers are unveil'd.
Both patches have been sent upstream:
https://github.com/fish-shell/fish-shell/pull/6523
https://github.com/fish-shell/fish-shell/pull/6522
OK?
diff --git a/shells/fish/Makefile b/shells/fish/Makefile
index 41e58668faf..88dd1855ef7 100644
--- a/shells/fish/Makefile
+++ b/shells/fish/Makefile
@@ -4,7 +4,7 @@ COMMENT = friendly interactive shell
V =3.0.2
DISTNAME = fish-$V
-REVISION = 1
+REVISION = 2
CATEGORIES = shells
diff --git a/shells/fish/patches/patch-share_completions_vmctl_fish
b/shells/fish/patches/patch-share_completions_vmctl_fish
new file mode 100644
index 000..023c845466d
--- /dev/null
+++ b/shells/fish/patches/patch-share_completions_vmctl_fish
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+https://github.com/fish-shell/fish-shell/pull/6523
+
+Index: share/completions/vmctl.fish
+--- share/completions/vmctl.fish.orig
share/completions/vmctl.fish
+@@ -1,4 +1,11 @@
+
++function __fish_get_vmctl_vms
++ for line in (vmctl status | string match -e -v "MAXMEM");
++ set a (string split " " $line)
++ and printf "%s " $a[-1]
++ end
++end
++
+ complete -c vmctl -xa 'console create load log reload reset start status stop
pause unpause send receive' -n 'not __fish_seen_subcommand_from list console
create load log reload reset start status stop pause unpause send receive'
+-complete -c vmctl -n '__fish_seen_subcommand_from console reload reset start
status stop pause unpause send receive' -xa '(vmctl status | string match -e -v
"MAXMEM" | string replace -r "^(\s+\S+\s+){7}" "")'
++complete -c vmctl -n '__fish_seen_subcommand_from console reload reset start
status stop pause unpause send receive' -xa (__fish_get_vmctl_vms)
+
diff --git a/shells/fish/patches/patch-share_tools_web_config_webconfig_py
b/shells/fish/patches/patch-share_tools_web_config_webconfig_py
new file mode 100644
index 000..67d91fcc5d6
--- /dev/null
+++ b/shells/fish/patches/patch-share_tools_web_config_webconfig_py
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+https://github.com/fish-shell/fish-shell/pull/6522
+
+Index: share/tools/web_config/webconfig.py
+--- share/tools/web_config/webconfig.py.orig
share/tools/web_config/webconfig.py
+@@ -1172,10 +1172,15 @@ url = 'http://localhost:%d/%s/%s' % (PORT, authkey, in
+ # Create temporary file to hold redirect to real server. This prevents
exposing
+ # the URL containing the authentication key on the command line (see
+ # CVE-2014-2914 or https://github.com/fish-shell/fish-shell/issues/1438).
+-if 'XDG_CACHE_HOME' in os.environ:
+-dirname = os.path.expanduser(os.path.expandvars('$XDG_CACHE_HOME/fish/'))
++if platform.system() == 'OpenBSD':
++# On OpenBSD the main browsers use unveil, which prevents file access
++# to most of the disk. ~/Downloads is unrestricted in both, so use that.
++dirname = os.path.expanduser('~/.Downloads/fish/')
+ else:
+-dirname = os.path.expanduser('~/.cache/fish/')
++if 'XDG_CACHE_HOME' in os.environ:
++dirname =
os.path.expanduser(os.path.expandvars('$XDG_CACHE_HOME/fish/'))
++else:
++dirname = os.path.expanduser('~/.cache/fish/')
+
+ os.umask(0o0077)
+ try:
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: Debug packages policy?
On Tue, Jan 21, 2020 at 02:00:52PM +, cho...@jtan.com wrote:
> Antoine Jacoutot writes:
> > On Tue, Jan 21, 2020 at 11:57:23AM +, cho...@jtan.com wrote:
> > >
> > >
> >
> > I don't quite understand your mail.
>
> This:
>
> > > > > What's the policy for adding debug packages to ports?
>
> but ...
>
> > See this:
> > https://man.openbsd.org/bsd.port.mk.5#THE_DEBUG_PACKAGES_INFRASTRUCTURE
>
> ... I had conflated debug packages with stripping (or rather, not)
> binaries so I was off on a bit of a tangent.
>
> If debug packages are needed the functionality exists to make them,
> in even better form than I had supposed, and if debugging needs to
> be done then having a complete build environment is worlds apart
> more useful than a symbol table (I presume the debug packages have
> a bit more than that but I haven't looked).
>
> So to get to the original point, DEBUG_PACKAGES doesn't look like
> something that's useful in the public version of /usr/ports. If
> anybody needs it then they've already got a complete (& working &
> tested) OpenBSD build environment in which to add it and do their
> debugging. What use the extra load on servers and maintainers?
Sorry but that does not make sense.
The whole point is to have debug packages available for official packages.
Not be forced to rebuild anything.
And we already have many (more than 370 debug-* packages in the snapshots
directory).
For 99% of them it only means adding DEBUG_PACKAGES=${BUILD_PACKAGES} in the
port Makefile.
I run bulk 24/7 and I maintain 300 or 400 ports (I stopped counting years ago),
I think I am entitled to say they're no real extra load here... unless I am
misunderstanding what you mean.
I think you should read the DEBUG_PACKAGES framework to understand.
--
Antoine
Re: ports unable to resolve dependencies in some cases
On Tue, Jan 21, 2020 at 10:10:52AM -0500, Kurt Mosiejczuk wrote: > On Tue, Jan 21, 2020 at 04:02:34PM +0100, Marc Espie wrote: > > > > This happens to me fairly frequently, whether it is on that sparc64 box or > > > my amd64 laptop. Yes, I use FETCH_PACKAGES. No, my /etc/installurl is not > > > wrong, because if I then run "pkg_add -a py-numpy" it will resolve > > > everything just fine. So this is something specific to how the ports > > > infrastructure handles the situation. > > > If things are not perfectly in synch, FETCH_PACKAGES won't help. > > It will look up *exactly* the FULLPKGNAME that's currently in your ports > > tree, so if your ports tree is behind or if the packages haven't made it to > > the mirror, you're out of luck. > > It used to be that in such cases, it would fail over to building the new > version. Here it just gives up completely. Did that change at some point? Oh, that's a new one. I'll check whether I can reproduce/fix. Some things changed. Specifically the old test would do BUILD_DEPENDS along with RUN_DEPENDS in a strange way, but I never intended to make it fail.
Re: update: devel/py-country
On 2020/01/21 19:55, Paco Esteban wrote:
> Hi ports@,
>
> Here's an update for devel/py-country from 18.12.8 to 19.8.18.
> This is part of a dependency rabbit hole I fell into that may or may not
> end up well, but this is done already so here it is.
>
> All tests pass for me on amd64. I checked consumers, these are the
> results:
>
> * multimedia/streamlink: all tests pass
> * www/py-formencode:
> py2 fails 2 tests with a DNS timeout
> py3 fails tests because it cannot find `dnspython3`. I think this is
> a missing dependency and PRIVSEP is making it apparent.
There used to be separate dnspython3 and dnspython, but py3 support has been
rolled into the main dnspython now. formencode is old (last upstream commit
~4 years ago) and I'm not entirely surprised about tests failing. I wouldn't
worry about this though, the changes since 18.12.8 are unlikely to break things.
(I see the version numbers are just based on dates rather than major/minor).
> diff f9926d52c465ed7320e905f705e846cc22b08451
> 81f663d35cd2e7399bb557c4bd32c15049193b14
> blob - 0bfef69066a3a034469c33a214ad6fe536805ac2
> blob + 540b26f5f77c3aedb432d321038461bd5cee2428
> --- devel/py-country/Makefile
> +++ devel/py-country/Makefile
> @@ -2,10 +2,9 @@
>
> COMMENT =country, language, currency and scripts definitions
>
> -MODPY_EGG_VERSION = 18.12.8
> +MODPY_EGG_VERSION = 19.8.18
19.7.15 (2019-07-15)
[...]
- Drop support for Python 2.
py2 still works for now, but perhaps we should add a comment to the port
Makefile mentioning this though so that people doing future updates
make sure they test there ..
> DISTNAME = pycountry-${MODPY_EGG_VERSION}
> PKGNAME =${DISTNAME:S/py/py-/}
> -REVISION = 1
>
> CATEGORIES = devel
>
> blob - b4745cf86b0708b398dfbe582954080e3e84e5f1
> blob + 2a34981920b88e5ae5addba13ff1b0e034576662
> --- devel/py-country/distinfo
> +++ devel/py-country/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (pycountry-18.12.8.tar.gz) =
> jsQCCysVzUEIk9Vzgg1C7hL+UDZTMuWMCXXJU7YKFt4=
> -SIZE (pycountry-18.12.8.tar.gz) = 10026953
> +SHA256 (pycountry-19.8.18.tar.gz) =
> PFeqQK3PKT1Zvrr/vmDYw5l2+6eNhGoBjcDC7Jxss8s=
> +SIZE (pycountry-19.8.18.tar.gz) = 10003160
> blob - 031dc25d0da2814e24f88a0718ed0a0a7194a40d
> blob + c778d79fc708ac37809fb11369e635cc9292160f
> --- devel/py-country/pkg/PLIST
> +++ devel/py-country/pkg/PLIST
> @@ -1,4 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.8 2019/02/17 20:22:22 sthen Exp $
> +lib/python${MODPY_VERSION}/
> +lib/python${MODPY_VERSION}/site-packages/
I'm not sure how these lines were added, the directories come from a
dependency though and don't need listing. update-plist removes them here ..
> lib/python${MODPY_VERSION}/site-packages/pycountry/
>
> lib/python${MODPY_VERSION}/site-packages/pycountry-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
>
> lib/python${MODPY_VERSION}/site-packages/pycountry-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
> @@ -17,6 +19,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/dat
> lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso3166-3.json
> lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso4217.json
> lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso639-3.json
> +lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso639-5.json
> lib/python${MODPY_VERSION}/site-packages/pycountry/db.py
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ab/
> @@ -54,6 +57,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/loc
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso3166-1.mo
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso3166-3.mo
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso3166.mo
> +lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso4217.mo
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso639-3.mo
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso639_3.mo
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/as/
> @@ -94,6 +98,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/loc
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso3166-3.mo
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso3166.mo
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso4217.mo
> +lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso639-5.mo
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/bg/
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/bg/LC_MESSAGES/
>
> lib/python${MODPY_VERSION}/site-packages/pycountry/locales/bg/LC_MESSAGES/iso15924.mo
> @@ -211,6 +216,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/l
Re: NEW: audio/yt-audio
On 21/01 20:17, Stuart Henderson wrote: > On 2020/01/21 09:31, aisha wrote: > > This is awesome, always wanted to just download the songs. > > yt-audio adds some extra things, but that has always been possible > with command-line options..to save typing them each time I have used > this little wrapper unchanged for ~5 years > > $ cat ~/bin/youtube-dl-audio > #!/bin/sh > exec /usr/local/bin/youtube-dl -f bestaudio/best -x "$*" > I was wondering the same. currently have : "youtube-dl -c --geo-bypass --restrict-filenames --extract-audio --audio-quality 0 -o "%(title)s.%(ext)s" $@;}" Ultimately ripping audio from YT is never going to be for audiophiles.
Re: [NEW] devel/p5-PGObject
I have changed the Makefile and edited the DESCR I removed the TEST_DEPENDS of p5-Test-CheckManifest. I kept the RUN_DEPENDS of p5-DBD>=2.0, but removed it from the TEST_DEPENDS because it is already listed in RUN_DEPENDS. This module does what I have done in my own programming. It accepts $dbh from outside. Does not have any use DBI or use DBD::Pg within the modules themselves, but does use the $dbh to query the database. Thus, these modules cannot actually be used without something else sending in a $dbh. The author put all of the various PGObject modules on cpan for usage beyond just LedgerSMB. Should something mention the need to install or code something else to make this usable or not? For example, mozplugger isn't very useful for firefox unless other packages are also installed. Thanks, -- Chris Bennett p5-PGObject.tar.gz Description: GNU Zip compressed data
Re: devel/openmpi mpifort error; compiler
On 2020-01-21 12:45, Martin Reindl wrote:
Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
This fixes the mpifort command which can't find egfortran.
I also propose removing COMPILER = base-clang since this compiles
with gcc anyway. GCC also has some advantages for us fortran
users (coarray fortran).
Hello John,
- OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
- REVISION should start at 0
Ahh, the perils of porting infrequently. Good point.
- egfortran actually is the one from ports-gcc (8.3.0), I don't see the
point replacing base clang 8.0.1 if you need coarray fortran?
On AMD64, OpenMPI compiles with ports-gcc anyway, hence my notion
to avoid confusion by naming the one compiler:
===> Checking files for openmpi-4.0.2p1
`/usr/distfiles/openmpi-4.0.2.tar.gz' is up to date.
(SHA256) openmpi-4.0.2.tar.gz: OK
===> openmpi-4.0.2p1 depends on: libltdl-* -> libltdl-2.4.2p1
===> openmpi-4.0.2p1 depends on: gcc->=8,<9 -> gcc-8.3.0p4
etc etc
Once built (using ports-gcc egcc and egfortran), then OpenMPI is
compatible with clang but not flang because the two Fortrans
have different array implementations (max rank=15 on egfortran
versus merely 8 or 9 on flang, and OpenMPI notices.)
The GCC gfortran compiler supports co-arrays but flang does
not, to my knowledge. The coarrays lib is a very simple
port that I should post.
--John
-m
--John
Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 - 1.29
+++ Makefile20 Jan 2020 19:19:35 -
@@ -4,6 +4,7 @@ COMMENT = open source MPI-3.1 implement
V =4.0.2
DISTNAME = openmpi-$V
+REVISION = 1
SHARED_LIBS += mca_common_dstore 0.0 # 1.0
SHARED_LIBS += mca_common_monitoring 0.0 # 60.0
@@ -30,11 +31,14 @@ WANTLIB += c execinfo m pciaccess pthrea
MASTER_SITES
= ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
MODULES = fortran
MODFORTRAN_COMPILER = gfortran
BUILD_DEPENDS =devel/libtool,-ltdl
LIB_DEPENDS = devel/libexecinfo
+
+CONFIGURE_ARGS += --enable-mpi-fortran=usempif08
+CONFIGURE_ARGS += FC=egfortran
MAKE_FLAGS = V=1
FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
Re: NEW: audio/yt-audio
On 2020/01/21 09:31, aisha wrote: > This is awesome, always wanted to just download the songs. yt-audio adds some extra things, but that has always been possible with command-line options..to save typing them each time I have used this little wrapper unchanged for ~5 years $ cat ~/bin/youtube-dl-audio #!/bin/sh exec /usr/local/bin/youtube-dl -f bestaudio/best -x "$*"
Re: devel/openmpi mpifort error; compiler
On 2020/01/21 20:45, Martin Reindl wrote: > Am 20.01.20 um 22:55 schrieb j...@bitminer.ca: > > This fixes the mpifort command which can't find egfortran. > > > > I also propose removing COMPILER = base-clang since this compiles > > with gcc anyway. GCC also has some advantages for us fortran > > users (coarray fortran). > > Hello John, > > - OK for the CONFIGURE_ARGS fortran bits, thanks for spotting! > - REVISION should start at 0 > - egfortran actually is the one from ports-gcc (8.3.0), I don't see the > point replacing base clang 8.0.1 if you need coarray fortran? COMPILER interacts poorly with the fortran module. $ make show=CHOSEN_COMPILER base-clang Between this and the COMPILER line it suggests it's going to use clang, right? $ make patch [...] ===> Compiler link: gcc -> /usr/local/bin/egcc ===> Compiler link: cc -> /usr/local/bin/egcc ===> Compiler link: gfortran -> /usr/local/bin/egfortran ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: c++ -> /usr/bin/c++ Wrong...that's (ports-)GCC. (This also means that if such a port uses the c++ standard library for some code, and uses or is used by some other library using c++, the binaries will end up broken..not really sure how to deal with this though). > > -COMPILER = base-clang ports-gcc > > +COMPILER = ports-gcc > > MODULES = fortran > > MODFORTRAN_COMPILER = gfortran It could say something like this to make it a bit clearer (and leave out the COMPILER line).. # MODULES=fortran always uses ports-gcc (and overrides COMPILER) MODULES = fortran MODFORTRAN_COMPILER = gfortran [...]
Re: devel/openmpi mpifort error; compiler
Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
> This fixes the mpifort command which can't find egfortran.
>
> I also propose removing COMPILER = base-clang since this compiles
> with gcc anyway. GCC also has some advantages for us fortran
> users (coarray fortran).
Hello John,
- OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
- REVISION should start at 0
- egfortran actually is the one from ports-gcc (8.3.0), I don't see the
point replacing base clang 8.0.1 if you need coarray fortran?
-m
>
> --John
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/openmpi/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile 22 Dec 2019 15:47:35 - 1.29
> +++ Makefile 20 Jan 2020 19:19:35 -
> @@ -4,6 +4,7 @@ COMMENT = open source MPI-3.1 implement
>
> V = 4.0.2
> DISTNAME = openmpi-$V
> +REVISION = 1
>
> SHARED_LIBS += mca_common_dstore 0.0 # 1.0
> SHARED_LIBS += mca_common_monitoring 0.0 # 60.0
> @@ -30,11 +31,14 @@ WANTLIB += c execinfo m pciaccess pthrea
>
> MASTER_SITES =
> ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
>
> -COMPILER = base-clang ports-gcc
> +COMPILER = ports-gcc
> MODULES =fortran
> MODFORTRAN_COMPILER =gfortran
> BUILD_DEPENDS = devel/libtool,-ltdl
> LIB_DEPENDS =devel/libexecinfo
> +
> +CONFIGURE_ARGS +=--enable-mpi-fortran=usempif08
> +CONFIGURE_ARGS +=FC=egfortran
>
> MAKE_FLAGS = V=1
> FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
>
update: devel/py-country
Hi ports@,
Here's an update for devel/py-country from 18.12.8 to 19.8.18.
This is part of a dependency rabbit hole I fell into that may or may not
end up well, but this is done already so here it is.
All tests pass for me on amd64. I checked consumers, these are the
results:
* multimedia/streamlink: all tests pass
* www/py-formencode:
py2 fails 2 tests with a DNS timeout
py3 fails tests because it cannot find `dnspython3`. I think this is
a missing dependency and PRIVSEP is making it apparent.
Both behave the same before and after the update.
Cheers,
Paco.
diff f9926d52c465ed7320e905f705e846cc22b08451
81f663d35cd2e7399bb557c4bd32c15049193b14
blob - 0bfef69066a3a034469c33a214ad6fe536805ac2
blob + 540b26f5f77c3aedb432d321038461bd5cee2428
--- devel/py-country/Makefile
+++ devel/py-country/Makefile
@@ -2,10 +2,9 @@
COMMENT = country, language, currency and scripts definitions
-MODPY_EGG_VERSION =18.12.8
+MODPY_EGG_VERSION =19.8.18
DISTNAME = pycountry-${MODPY_EGG_VERSION}
PKGNAME = ${DISTNAME:S/py/py-/}
-REVISION = 1
CATEGORIES = devel
blob - b4745cf86b0708b398dfbe582954080e3e84e5f1
blob + 2a34981920b88e5ae5addba13ff1b0e034576662
--- devel/py-country/distinfo
+++ devel/py-country/distinfo
@@ -1,2 +1,2 @@
-SHA256 (pycountry-18.12.8.tar.gz) =
jsQCCysVzUEIk9Vzgg1C7hL+UDZTMuWMCXXJU7YKFt4=
-SIZE (pycountry-18.12.8.tar.gz) = 10026953
+SHA256 (pycountry-19.8.18.tar.gz) =
PFeqQK3PKT1Zvrr/vmDYw5l2+6eNhGoBjcDC7Jxss8s=
+SIZE (pycountry-19.8.18.tar.gz) = 10003160
blob - 031dc25d0da2814e24f88a0718ed0a0a7194a40d
blob + c778d79fc708ac37809fb11369e635cc9292160f
--- devel/py-country/pkg/PLIST
+++ devel/py-country/pkg/PLIST
@@ -1,4 +1,6 @@
@comment $OpenBSD: PLIST,v 1.8 2019/02/17 20:22:22 sthen Exp $
+lib/python${MODPY_VERSION}/
+lib/python${MODPY_VERSION}/site-packages/
lib/python${MODPY_VERSION}/site-packages/pycountry/
lib/python${MODPY_VERSION}/site-packages/pycountry-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/pycountry-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -17,6 +19,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/dat
lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso3166-3.json
lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso4217.json
lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso639-3.json
+lib/python${MODPY_VERSION}/site-packages/pycountry/databases/iso639-5.json
lib/python${MODPY_VERSION}/site-packages/pycountry/db.py
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ab/
@@ -54,6 +57,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/loc
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso3166-1.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso3166-3.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso3166.mo
+lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso4217.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso639-3.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/ar/LC_MESSAGES/iso639_3.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/as/
@@ -94,6 +98,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/loc
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso3166-3.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso3166.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso4217.mo
+lib/python${MODPY_VERSION}/site-packages/pycountry/locales/be/LC_MESSAGES/iso639-5.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/bg/
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/bg/LC_MESSAGES/
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/bg/LC_MESSAGES/iso15924.mo
@@ -211,6 +216,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/loc
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/da/LC_MESSAGES/iso3166_2.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/da/LC_MESSAGES/iso4217.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/da/LC_MESSAGES/iso639-3.mo
+lib/python${MODPY_VERSION}/site-packages/pycountry/locales/da/LC_MESSAGES/iso639-5.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/da/LC_MESSAGES/iso639_3.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/de/
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/de/LC_MESSAGES/
@@ -222,6 +228,7 @@ lib/python${MODPY_VERSION}/site-packages/pycountry/loc
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/de/LC_MESSAGES/iso3166_2.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/de/LC_MESSAGES/iso4217.mo
lib/python${MODPY_VERSION}/site-packages/pycountry/locales/de/LC_MESS
Re: NEW: audio/yt-audio
That's why I choose not to prefix it with py. Glad to hear I got it right :) Same rule as for youtube-dl.
Re: [update] nnn 2.8.1 > v2.9
On Tue 21/01/2020 11:55, Dnsgate wrote: > The last sent diff had weird encoding for spaces. > Here is a good one: Diff looks good, however did you see https://github.com/jarun/nnn/pull/441? Maybe this is something you could discuss with MAINTAINER?
Re: NEW: audio/yt-audio
On 2020/01/21 15:28, Landry Breuil wrote: > On Tue, Jan 21, 2020 at 04:16:43PM +0200, Paul Irofti wrote: > > Hi, > > > > Here is a port for fetching audio from youtube streams. It is mainly a > > wrapper around youtube-dl with some extra ffmpeg magic. > > > > youtube-dl fans will also love this port. > > > > %-- > > A simple, configurable, cross-platform youtube-dl wrapper for > > downloading and managing youtube audio (with added features). > > %-- > > > > OK? > > seems fine, but should it be named py3-yt-audio ? sthen@ ? > IMHO no, it is only really interesting as a script rather than a python module.. If it would be libfoo or lua-foo then py-foo makes sense, but for programs that are mostly useful as programs and just happen to be written in that language then just use the program name.
Re: Debug packages policy?
On 2020/01/20 23:31, Christian Weisgerber wrote: > What's the policy for adding debug packages to ports? > > Is the intend to add debug packages... > * eventually to all ports > or > * only to ports where they seem particularly useful? > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > The policy I have been using myself is - common libraries - ports where I suspect there are likely to be crashes that I think debug symbols would reasonably help - ports that take a long time to build (but this is very handwave-y)
devel/openmpi mpifort error; compiler
This fixes the mpifort command which can't find egfortran.
I also propose removing COMPILER = base-clang since this compiles
with gcc anyway. GCC also has some advantages for us fortran
users (coarray fortran).
--John
Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 - 1.29
+++ Makefile20 Jan 2020 19:19:35 -
@@ -4,6 +4,7 @@ COMMENT = open source MPI-3.1 implement
V =4.0.2
DISTNAME = openmpi-$V
+REVISION = 1
SHARED_LIBS += mca_common_dstore 0.0 # 1.0
SHARED_LIBS += mca_common_monitoring 0.0 # 60.0
@@ -30,11 +31,14 @@ WANTLIB += c execinfo m pciaccess pthrea
MASTER_SITES =
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
MODULES = fortran
MODFORTRAN_COMPILER = gfortran
BUILD_DEPENDS =devel/libtool,-ltdl
LIB_DEPENDS = devel/libexecinfo
+
+CONFIGURE_ARGS += --enable-mpi-fortran=usempif08
+CONFIGURE_ARGS += FC=egfortran
MAKE_FLAGS = V=1
FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
Re: [update] nnn 2.8.1 > v2.9
The last sent diff had weird encoding for spaces.
Here is a good one:
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile 13 Jan 2020 17:53:31 - 1.4
+++ Makefile 20 Jan 2020 22:00:32 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V = 2.8.1
+V = 2.9
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
@@ -30,9 +30,7 @@ WRKDIST = ${WRKDIR}/nnn
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
- ${INSTALL_PROGRAM} ${WRKSRC}/misc/nlay/nlay ${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
- ${INSTALL_MAN} ${WRKSRC}/misc/nlay/nlay.1 ${PREFIX}/man/man1/
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
${INSTALL_DATA} ${WRKSRC}/misc/auto-completion/bash/nnn-completion.bash \
Index: distinfo
===
RCS file: /cvs/ports/sysutils/nnn/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo 13 Jan 2020 17:53:32 - 1.2
+++ distinfo 20 Jan 2020 22:00:32 -
@@ -1,2 +1,2 @@
-SHA256 (nnn-v2.8.1.tar.gz) = 4Pr45ifU+GBQ9XyzHu4hvw4hOK3vjtVBKwc12ptdh7w=
-SIZE (nnn-v2.8.1.tar.gz) = 91353
+SHA256 (nnn-v2.9.tar.gz) = ugsHsNh7ptZEIlnal22OM+1pjeQygjr7b8b2gBy92fY=
+SIZE (nnn-v2.9.tar.gz) = 99324
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/nnn/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -u -r1.2 PLIST
--- pkg/PLIST 13 Jan 2020 17:53:32 - 1.2
+++ pkg/PLIST 20 Jan 2020 22:00:32 -
@@ -1,7 +1,5 @@
@comment $OpenBSD: PLIST,v 1.2 2020/01/13 17:53:32 bket Exp $
-bin/nlay
@bin bin/nnn
-@man man/man1/nlay.1
@man man/man1/nnn.1
share/bash-completion/
share/bash-completion/completions/
On 1/20/20 6:17 PM, Dnsgate wrote:
Thank you for the corrections and comments.
On 1/20/20 5:26 PM, Klemens Nanni wrote:
On Mon, Jan 20, 2020 at 03:17:09PM -0400, Dnsgate wrote:
This is a port update for the CLI file manager sysutils/nnn
This patch updates nnn from 2.8.1 to 2.9
Please send diffs inline, not attached.
Changes and version info here:
https://github.com/jarun/nnn/releases/tag/v2.9
Tested on amd64 for a couple of days and I have found it to be more
stable
than the previous versions.
Also the new default key bindings are nicer and work better in
tiling window
managers like dwm.
I think users will appreciate this update.
All of this is subjective? What makes it "more stable"? What bindings
change?
Yes, this is from my own experience using the application since v1.8
on OpenBSD
for example, copying large files (>10GB) produced a core dump or an
application hang randomly.
Also, on reading very large remote directories (NFS) the application
hanged.
This is no longer a problem with 2.9.
Again this is in my experience using -current on bare metal (T450s and
a DELL T1700)
The key bindings where changed for 2.9, more info here:
"Sane keybinds and switches"
https://github.com/jarun/nnn/issues/422
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile 13 Jan 2020 17:53:31 - 1.4
+++ Makefile 20 Jan 2020 21:22:46 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V = 2.8.1
+V = 2.9
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
@@ -21,8 +21,6 @@ MASTER_SITES = https://github.com/jarun
RUN_DEPENDS = shells/bash
-MAKE_FLAGS = CFLAGS_OPTIMIZATION=
-
Why? It now builds with "-O3" again.
Reverted the change.
USE_GMAKE = Yes
NO_TEST = Yes
@@ -30,9 +28,7 @@ WRKDIST = ${WRKDIR}/nnn
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nnn ${PREFIX}/bin/
- ${INSTALL_PROGRAM} ${WRKSRC}/misc/nlay/nlay ${PREFIX}/bin/
${INSTALL_MAN} ${WRKSRC}/nnn.1 ${PREFIX}/man/man1/
- ${INSTALL_MAN} ${WRKSRC}/misc/nlay/nlay.1 ${PREFIX}/man/man1/
Why?
Also, the PLIST update would be missing, so this is wrong in both ways.
nlay is no longer used by nnn.
See:
https://github.com/jarun/nnn/issues/213
I updated the PLIST and re-tested the build.
${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions/
${INSTALL_DATA}
${WRKSRC}/misc/auto-completion/bash/nnn-completion.bash \
Here is the updated diff:
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile 13 Jan 2020 17:53:31 - 1.4
+++ Makefile 20 Jan 2020 22:00:32 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V = 2.8.1
+V = 2.9
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
@@ -30,9 +30,7 @@ WRKDIST =
Re: NEW: audio/yt-audio
This is awesome, always wanted to just download the songs. Sick port. Thanks a lot. --- Aisha www.aisha.cc On 2020-01-21 09:28, Landry Breuil wrote: On Tue, Jan 21, 2020 at 04:16:43PM +0200, Paul Irofti wrote: Hi, Here is a port for fetching audio from youtube streams. It is mainly a wrapper around youtube-dl with some extra ffmpeg magic. youtube-dl fans will also love this port. %-- A simple, configurable, cross-platform youtube-dl wrapper for downloading and managing youtube audio (with added features). %-- OK? seems fine, but should it be named py3-yt-audio ? sthen@ ?
Re: ports unable to resolve dependencies in some cases
On Tue, Jan 21, 2020 at 04:02:34PM +0100, Marc Espie wrote: > > This happens to me fairly frequently, whether it is on that sparc64 box or > > my amd64 laptop. Yes, I use FETCH_PACKAGES. No, my /etc/installurl is not > > wrong, because if I then run "pkg_add -a py-numpy" it will resolve > > everything just fine. So this is something specific to how the ports > > infrastructure handles the situation. > If things are not perfectly in synch, FETCH_PACKAGES won't help. > It will look up *exactly* the FULLPKGNAME that's currently in your ports > tree, so if your ports tree is behind or if the packages haven't made it to > the mirror, you're out of luck. It used to be that in such cases, it would fail over to building the new version. Here it just gives up completely. Did that change at some point? > Not that surprised that things could be lagging on sparc64... But, as I said, it happens on amd64 all the time too. It even happens for things that have not changed. --Kurt
Re: Remove comms/qtserialport
On Tue, Jan 21 2020, Rafael Sadowski wrote: > After cad/fritzing is updated, we can delete comms/qtserialport? Yes!!? > > OK? Concerns? ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Update devel/tmake
On Tue, Jan 21 2020, Rafael Sadowski wrote: > Yearly grep(1)'ing for "x11/qt3" and "x11/qt4", brings me here. > First thought, delete it. But there is an update and it's may useful. > > Tweaks: > > - Switch from qt3 to qt5 to access MODQT_* vars, but set MODQT_DEPS=No. > - Install LICENSE file > > OK? No consumer, released in 2004, long before C++11, clang in base and qt5 in ports. NO_TEST=Yes means we can't even know whether it works. Please just delete it. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ports unable to resolve dependencies in some cases
On Mon, Jan 20, 2020 at 09:51:14PM -0500, Kurt Mosiejczuk wrote: > I think this following case is when there is a package cached (or created) > in the ports tree, but one of its dependencies is not there. > > devlin$ make > ===> py-h5py-2.10.0 depends on: py-numpy-* - not found > ===> Verifying install for py-numpy-* in math/py-numpy > ===> Installing py-numpy-1.14.6p1 from /usr/ports/packages/sparc64/all/ > Can't find blas-3.8.0p0 > Can't install lapack-3.8.0p1: can't resolve blas-3.8.0p0 > Can't install py-numpy-1.14.6p1: can't resolve lapack-3.8.0p1 > Couldn't install blas-3.8.0p0 lapack-3.8.0p1 py-numpy-1.14.6p1 > *** Error 1 in /usr/ports/math/py-numpy > (/usr/ports/infrastructure/mk/bsd.port.mk:2115 > '/var/db/pkg/py-numpy-1.14.6p1/+CONTENTS': @/usr/bin/...) > *** Error 2 in /usr/ports/math/py-numpy > (/usr/ports/infrastructure/mk/bsd.port.mk:2556 'install': > @lock=py-numpy-1.14.6; export _LOCKS_HELD...) > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2239 > '/usr/ports/pobj/py-h5py-2.10.0/.dep-math-py-numpy': @unset _DEPENDS_TARGET > ...) > *** Error 2 in /usr/ports/mystuff/math/h5py > (/usr/ports/infrastructure/mk/bsd.port.mk:2556 'all': @lock=py-h5py-2.10.0; > export _LOCKS_HELD=...) > devlin$ > > This happens to me fairly frequently, whether it is on that sparc64 box or > my amd64 laptop. Yes, I use FETCH_PACKAGES. No, my /etc/installurl is not > wrong, because if I then run "pkg_add -a py-numpy" it will resolve > everything just fine. So this is something specific to how the ports > infrastructure handles the situation. If things are not perfectly in synch, FETCH_PACKAGES won't help. It will look up *exactly* the FULLPKGNAME that's currently in your ports tree, so if your ports tree is behind or if the packages haven't made it to the mirror, you're out of luck. Not that surprised that things could be lagging on sparc64...
Re: Debug packages policy?
On Tue, Jan 21, 2020 at 11:57:23AM +, cho...@jtan.com wrote: > Antoine Jacoutot writes: > > On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote: > > > What's the policy for adding debug packages to ports? > > > > > > Is the intend to add debug packages... > > > * eventually to all ports > > > or > > > * only to ports where they seem particularly useful? > > > > I think the policy is up for debate really. > > Nothing has been decided yet. > > My humble opinion is that "particularly useful" is subjective... > > It would be more useful I think to make the ports and release build > processes more approachable so that debugging symbols can be made > available. If they need it, that is - I haven't had any real trouble > beyond locating the correct documents to read and fumbling my way > through. > > The reason being that including debugging symbols means you're, > well, debugging. In the event that something bug-like is discovered > debugging symbols will certainly make the stack traces sent to > maintainers & developers more useful but a full OpenBSD build > environment *right there* makes it easier to fix the bug where it > was discovered and where that fix can be tested, resulting in not > only a patch, but a *working* patch. > > When making things easier for people, I prefer to make it easier > for people to make my work easier, not make it easier for them to > just give me more work. > > Perhaps the enormous packages could have debug-symbol-filled variants > but these days even that argument holds little water. I don't have > the numbers to hand but the things which have traditionally had the > worst build times - kernels, gcc, java, X, even firefox until they > brought rust in to repair that oversight - now have build times > measured in hours or minutes rather than weeks. You're not making any sense, and I don't think you get what we are talking about. My opinion on DEBUG_PACKAGES is that eventually, most packages that could use some debug will have DEBUG_PACKAGES. In most cases, setting DEBUG_PACKAGES is enough. Doing this package-by-package gives a chance for the mirrors to "grow" the space needed little by little. The exception will be: - ports where it's extra complicated to get debug (obviously not too many) - trivial leaf ports that can get rebuilt in <5mn.
Remove comms/qtserialport
After cad/fritzing is updated, we can delete comms/qtserialport? Yes!!? OK? Concerns?
Re: Remove databases/qt3-sqlite3-plugin
On Tue, Jan 21 2020, Rafael Sadowski wrote: > No consumers present in the tree, looks quite useless. Ok to say > goodbye? yep -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Remove databases/qt3-sqlite3-plugin
On Tue, Jan 21, 2020 at 06:51:59AM +0100, Rafael Sadowski wrote: > No consumers present in the tree, looks quite useless. Ok to say > goodbye? Yes please. OK kmos --Kurt
Re: NEW: audio/yt-audio
On Tue, Jan 21, 2020 at 04:16:43PM +0200, Paul Irofti wrote: > Hi, > > Here is a port for fetching audio from youtube streams. It is mainly a > wrapper around youtube-dl with some extra ffmpeg magic. > > youtube-dl fans will also love this port. > > %-- > A simple, configurable, cross-platform youtube-dl wrapper for > downloading and managing youtube audio (with added features). > %-- > > OK? seems fine, but should it be named py3-yt-audio ? sthen@ ?
NEW: audio/yt-audio
Hi, Here is a port for fetching audio from youtube streams. It is mainly a wrapper around youtube-dl with some extra ffmpeg magic. youtube-dl fans will also love this port. %-- A simple, configurable, cross-platform youtube-dl wrapper for downloading and managing youtube audio (with added features). %-- OK? Paul yt-audio.tgz Description: application/tar-gz
Re: Debug packages policy?
Antoine Jacoutot writes: > On Tue, Jan 21, 2020 at 11:57:23AM +, cho...@jtan.com wrote: > > > > > > I don't quite understand your mail. This: > > > > What's the policy for adding debug packages to ports? but ... > See this: > https://man.openbsd.org/bsd.port.mk.5#THE_DEBUG_PACKAGES_INFRASTRUCTURE ... I had conflated debug packages with stripping (or rather, not) binaries so I was off on a bit of a tangent. If debug packages are needed the functionality exists to make them, in even better form than I had supposed, and if debugging needs to be done then having a complete build environment is worlds apart more useful than a symbol table (I presume the debug packages have a bit more than that but I haven't looked). So to get to the original point, DEBUG_PACKAGES doesn't look like something that's useful in the public version of /usr/ports. If anybody needs it then they've already got a complete (& working & tested) OpenBSD build environment in which to add it and do their debugging. What use the extra load on servers and maintainers? Matthew
Re: Debug packages policy?
On Tue, Jan 21, 2020 at 11:57:23AM +, cho...@jtan.com wrote: > Antoine Jacoutot writes: > > On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote: > > > What's the policy for adding debug packages to ports? > > > > > > Is the intend to add debug packages... > > > * eventually to all ports > > > or > > > * only to ports where they seem particularly useful? > > > > I think the policy is up for debate really. > > Nothing has been decided yet. > > My humble opinion is that "particularly useful" is subjective... > > It would be more useful I think to make the ports and release build > processes more approachable so that debugging symbols can be made > available. If they need it, that is - I haven't had any real trouble > beyond locating the correct documents to read and fumbling my way > through. > > The reason being that including debugging symbols means you're, > well, debugging. In the event that something bug-like is discovered > debugging symbols will certainly make the stack traces sent to > maintainers & developers more useful but a full OpenBSD build > environment *right there* makes it easier to fix the bug where it > was discovered and where that fix can be tested, resulting in not > only a patch, but a *working* patch. > > When making things easier for people, I prefer to make it easier > for people to make my work easier, not make it easier for them to > just give me more work. > > Perhaps the enormous packages could have debug-symbol-filled variants > but these days even that argument holds little water. I don't have > the numbers to hand but the things which have traditionally had the > worst build times - kernels, gcc, java, X, even firefox until they > brought rust in to repair that oversight - now have build times > measured in hours or minutes rather than weeks. > > tl;dr: grep -ri strip /usr/share/mk and, yes, read. No ";dr" for you. > > I don't quite understand your mail. I am not sure you're talking about the same thing naddy@ was... See this: https://man.openbsd.org/bsd.port.mk.5#THE_DEBUG_PACKAGES_INFRASTRUCTURE -- Antoine
Re: Debug packages policy?
Antoine Jacoutot writes: > On Mon, Jan 20, 2020 at 11:31:11PM +0100, Christian Weisgerber wrote: > > What's the policy for adding debug packages to ports? > > > > Is the intend to add debug packages... > > * eventually to all ports > > or > > * only to ports where they seem particularly useful? > > I think the policy is up for debate really. > Nothing has been decided yet. > My humble opinion is that "particularly useful" is subjective... It would be more useful I think to make the ports and release build processes more approachable so that debugging symbols can be made available. If they need it, that is - I haven't had any real trouble beyond locating the correct documents to read and fumbling my way through. The reason being that including debugging symbols means you're, well, debugging. In the event that something bug-like is discovered debugging symbols will certainly make the stack traces sent to maintainers & developers more useful but a full OpenBSD build environment *right there* makes it easier to fix the bug where it was discovered and where that fix can be tested, resulting in not only a patch, but a *working* patch. When making things easier for people, I prefer to make it easier for people to make my work easier, not make it easier for them to just give me more work. Perhaps the enormous packages could have debug-symbol-filled variants but these days even that argument holds little water. I don't have the numbers to hand but the things which have traditionally had the worst build times - kernels, gcc, java, X, even firefox until they brought rust in to repair that oversight - now have build times measured in hours or minutes rather than weeks. tl;dr: grep -ri strip /usr/share/mk and, yes, read. No ";dr" for you. Matthew
Re: update to libvips 8.9.0
On Mon, Jan 20, 2020 at 10:43:49PM +0100, Stephane Guedon wrote: > > In Makefile : > > - SHARED_LIBS should start at 0.0 > > - LIB_DEPENDS should be one dep per line > > > > Also pkg/DESCR is shorter, any reason why ? > > Mistake happened. Apologies. > No worries :) It seems you did not update PLIST. Also it would be better to indent "\" in Makefile. Thank you
