Re: [macppc] x11/gnustep/*: fix make, mark base BROKEN

2020-10-28 Thread George Koehler
On Thu, 8 Oct 2020 01:08:05 +0200
Charlene Wendling  wrote:

> Hi,
> 
> Here are the current gnustep/libobjc failures:
> 
> http://build-failures.rhaalovely.net/powerpc/2020-08-23/www/sope.log
> http://build-failures.rhaalovely.net/powerpc/2020-08-23/x11/gnustep/dbuskit.log
> http://build-failures.rhaalovely.net/powerpc/2020-08-23/x11/gnustep/gui.log
> http://build-failures.rhaalovely.net/powerpc/2020-08-23/x11/gnustep/performance.log
> 
> So i'm asking again if i can go ahead so it doesn't waste bulk time.
> 
> Charlène.

I'm sorry for replying 3 weeks after your mail.  Your diff (from
April!), quoted below, would have marked gnustep-base BROKEN-powerpc
and changed gnustep-make on powerpc.

I now have a clang diff (https://reviews.llvm.org/D90329) that
unbreaks gnustep-base and gnustep-make without needing your diff.
Last week, Anthony Richardby had found and reported the bug that
broke clang's va_arg(_, id) in Objective-C code.  With the clang diff,
and using FETCH_PACKAGES=, I built x11/gnustep/{libobjc2,make,base,
gui,gmines} and played gmines.

Later, I will mail the clang diff to tech@, but now, it isn't in
OpenBSD's clang, so ok gkoehler@ to mark base BROKEN-powerpc if you
don't want to wait for the fix.

I didn't ok your gnustep/make diff because I'm not sure.  I don't know
why amd64 and i386 have the different LIBRARY_COMBO.  Also, AS=llvm-as
looks wrong because ports-clang (for llvm-as) might not be installed.

The clang diff affects only 32-bit powerpc.  Something else is wrong
on powerpc64 (where most gnustep packages are missing), but I have
not yet tried a powerpc64 build.  --George

> 
> Index: base/Makefile
> ===
> RCS file: /cvs/ports/x11/gnustep/base/Makefile,v
> retrieving revision 1.75
> diff -u -p -r1.75 Makefile
> --- base/Makefile 20 Oct 2019 08:03:00 -  1.75
> +++ base/Makefile 18 Apr 2020 15:46:55 -
> @@ -1,5 +1,7 @@
>  # $OpenBSD: Makefile,v 1.75 2019/10/20 08:03:00 ajacoutot Exp $
>  
> +BROKEN-powerpc= consumers segfault at runtime
> +
>  COMMENT= GNUstep base library
>  
>  DISTNAME=gnustep-base-1.26.0
> Index: make/Makefile
> ===
> RCS file: /cvs/ports/x11/gnustep/make/Makefile,v
> retrieving revision 1.56
> diff -u -p -r1.56 Makefile
> --- make/Makefile 20 Oct 2019 08:03:03 -  1.56
> +++ make/Makefile 18 Apr 2020 15:46:55 -
> @@ -36,7 +36,8 @@ CONFIGURE_ARGS= --with-layout=openbsd \
>   --with-objc-lib-flag=-lobjc2 \
>   --enable-strict-v2-mode
>  
> -.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
> +.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \
> +${MACHINE_ARCH} == "powerpc"
>  WANTLIB =${COMPILER_LIBCXX}
>  LIBRARY_COMBO =  "ng-gnu-gnu"
>  CONFIGURE_ENV += GS_WITH_ARC=1 AS=llvm-as
> 


-- 
George Koehler 



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Theo Buehler
CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/10/28 23:14:04

Modified files:
databases/redis: Makefile distinfo 
databases/redis/patches: patch-redis_conf patch-src_Makefile 
 patch-src_networking_c 
Added files:
databases/redis/patches: patch-src_debug_c 
Removed files:
databases/redis/patches: patch-src_zmalloc_c 

Log message:
Update to Redis 6.0.9

The incorrect assumption in zmalloc_usable_size() was corrected upstream,
so we can get rid of the local patch. Add a new patch for a long long
time_t format string, with a tweak from jca.

ok danj

Changelog: https://github.com/redis/redis/blob/6.0.9/00-RELEASENOTES



回复: 回复: pysol doesn't run

2020-10-28 Thread wen heping
Here is the patch to update games/pysol to 2.10.1.

wen

发件人: Daniel Dickman 
发送时间: 2020年10月28日 10:12
收件人: wen heping 
抄送: Carsten Boysen Jensen ; ports@openbsd.org 

主题: Re: 回复: pysol doesn't run


>
> Hi,
> Attempt to run pysol from 6.8 on amd64 gives the following error:
>
> --
> Carsten Boysen Jensen
>
>


I committed a minimal fix to change time.clock -> time.time. With that I
was able to play the game.


> On Tue, 27 Oct 2020, wen heping wrote:
>
> It is caused by the default of python changed to 3.8.


Indeed, python 3.8 finally got rid of time.clock which was deprecated
since python 3.3


> I shall submit a patch to update it to 2.10.0 version, help it work with 
> python-3.8.
>
> wen


I think there's a slightly newer version of pysol (2.10.1).

I took a quick look and doing an update may require a new port for
pysol_cards first.
Index: Makefile
===
RCS file: /cvs/ports/games/pysol/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile3 Jul 2020 21:12:54 -   1.11
+++ Makefile29 Oct 2020 03:02:57 -
@@ -1,11 +1,10 @@
 # $OpenBSD: Makefile,v 1.11 2020/07/03 21:12:54 sthen Exp $
 
 COMMENT =  solitaire card games collection
-MODPY_EGG_VERSION =2.6.4
+MODPY_EGG_VERSION =2.10.1
 DISTNAME = PySolFC-${MODPY_EGG_VERSION}
 PKGNAME =  pysol-${MODPY_EGG_VERSION}
 CATEGORIES =   games
-REVISION = 1
 
 HOMEPAGE = http://pysolfc.sourceforge.net/
 
@@ -21,6 +20,7 @@ MODULES = lang/python \
x11/gnome
 MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
 MODGNOME_TOOLS =   desktop-file-utils gtk-update-icon-cache
+MODPY_SETUPTOOLS = Yes
 
 RUN_DEPENDS =  ${MODPY_TKINTER_DEPENDS} \
devel/py-six${MODPY_FLAVOR} \
Index: distinfo
===
RCS file: /cvs/ports/games/pysol/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo7 Sep 2019 07:23:56 -   1.4
+++ distinfo29 Oct 2020 03:02:57 -
@@ -1,4 +1,4 @@
-SHA256 (PySolFC-2.6.4.tar.xz) = Tas1eVMVMBNvtinARdS4OJ9BCWLmz3dJTxjGHJ3m6ng=
+SHA256 (PySolFC-2.10.1.tar.xz) = 8Jck8v3vPxbYulz4NIcuMfVZuzifa1Im/5qi7b8X0xk=
 SHA256 (PySolFC-Cardsets-2.0.tar.bz2) = 
w4jWNgGRs7fkY9hOWmQmDE4+0255GoUifX6JI/P0fKc=
-SIZE (PySolFC-2.6.4.tar.xz) = 3761108
+SIZE (PySolFC-2.10.1.tar.xz) = 6716688
 SIZE (PySolFC-Cardsets-2.0.tar.bz2) = 30687905
Index: patches/patch-data_pysol_desktop
===
RCS file: /cvs/ports/games/pysol/patches/patch-data_pysol_desktop,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-data_pysol_desktop
--- patches/patch-data_pysol_desktop25 May 2015 07:10:45 -  1.1.1.1
+++ patches/patch-data_pysol_desktop29 Oct 2020 03:02:57 -
@@ -1,14 +1,14 @@
-$OpenBSD: patch-data_pysol_desktop,v 1.1.1.1 2015/05/25 07:10:45 czarkoff Exp $
 data/pysol.desktop.origFri Jun  6 08:58:50 2008
-+++ data/pysol.desktop Sun May 24 23:52:58 2015
-@@ -1,8 +1,8 @@
+$OpenBSD$
+
+Index: data/pysol.desktop
+--- data/pysol.desktop.orig
 data/pysol.desktop
+@@ -1,7 +1,7 @@
  [Desktop Entry]
- Encoding=UTF-8
  Name=PySol Fan Club Edition
+ Comment=More than 1000 solitaire card games
 -Exec=pysol.py
 +Exec=pysol
+ StartupWMClass=Pysol
  Terminal=false
  Type=Application
- Categories=Game;CardGame;
--Icon=/usr/share/icons/pysol01.png
-+Icon=pysol01
Index: patches/patch-pysollib_pysolrandom_py
===
RCS file: patches/patch-pysollib_pysolrandom_py
diff -N patches/patch-pysollib_pysolrandom_py
--- patches/patch-pysollib_pysolrandom_py   22 Jan 2019 20:09:42 -  
1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,33 +0,0 @@
-$OpenBSD: patch-pysollib_pysolrandom_py,v 1.2 2019/01/22 20:09:42 landry Exp $
-
-Revert 
https://github.com/shlomif/PySolFC/commit/0515a01a025be3fa3ecfc3e0e72803f5e7370728
-Needs random2 from pip for python3 ?
-
-Index: pysollib/pysolrandom.py
 pysollib/pysolrandom.py.orig
-+++ pysollib/pysolrandom.py
-@@ -28,7 +28,7 @@ import re
- import time
- from pysollib.mfxutil import SubclassResponsibility
- try:
--import random2
-+import random
- except ImportError:
- raise ImportError(
- "You need to install " +
-@@ -101,13 +101,13 @@ class BasicRandom:
- # * uses the standard python module `random'
- # 
- 
--class MTRandom(BasicRandom, random2.Random):
-+class MTRandom(BasicRandom, random.Random):
- 
- def __init__(self, seed=None):
- if seed is None:
- seed = self._getRandomSeed()
- BasicRandom.__init__(self)
--random2.Random.__init__(self, seed)
-+random.Random.__init__(self, seed)
- 

CVS: cvs.openbsd.org: ports

2020-10-28 Thread Lawrence Teo
CVSROOT:/cvs
Module name:ports
Changes by: l...@cvs.openbsd.org2020/10/28 20:22:25

Modified files:
java/gradle: Makefile distinfo 
java/gradle/pkg: PLIST 

Log message:
Update to Gradle 6.7.

https://docs.gradle.org/6.7/release-notes.html



Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

On 10/28/20 5:46 PM, Aisha Tammy wrote:

On 10/28/20 3:31 PM, Ingo Schwarze wrote:

Hi Aisha,

Aisha Tammy wrote on Wed, Oct 28, 2020 at 01:12:15PM -0400:


Here is a preliminary version update of math/lapack to 3.9.0
with some patches from debian and gentoo.


While FORTAN used to be my favourite language until about 1998,
i got out of the habit of using it after that, so i can't really
comment on the port in general, but ...


Current caveats
(1) I've had to remove the man pages installation.


1. Why?

In general, if a major change is needed when updating a port,
it is useful to mention the reason.


2. Isn't that a blocker?

For a programming library, having section 3 documentation seems
crucial to me.  What is the point of an undocumented public API?

Yes, i am aware that lapack is among the last 20 or so ports that
require USE_GROFF, and among the worst handful of these because the
man(7) code is both unusually problematic from a qualitative
standpoint (.ti nested inside .TP head, ...) and also hard to handle
from a perspective of quantity - the library is so large that even
reviewing the manual pages regarding which problems are contained
in them isn't easy.

But none of that should be your problem, nor should it prevent
formatting the manual pages with groff and installing them.

Yours,
   Ingo



That's fair. I removed them as it seemed like none of the other
distributions are installing them in this package.
Some of them have a separate man-pages packages for lapack.
Other reason was that the man pages haven't been updated from 2007.
So I am also not sure if they are the most up to date.
But as you said, having them is better than not having them.

I can try to add them back but it might take some more time.

Aisha



Just as I sent this email, I noticed that it seems they have
a Doxygen man generator that is quite up to date.
- https://github.com/Reference-LAPACK/lapack/blob/master/DOCS/Doxyfile_man
Their prebuilt man files are from 2007 so I'll try to use this
to generate the man pages!

Cheers,
Aisha



Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

On 10/28/20 3:31 PM, Ingo Schwarze wrote:

Hi Aisha,

Aisha Tammy wrote on Wed, Oct 28, 2020 at 01:12:15PM -0400:


Here is a preliminary version update of math/lapack to 3.9.0
with some patches from debian and gentoo.


While FORTAN used to be my favourite language until about 1998,
i got out of the habit of using it after that, so i can't really
comment on the port in general, but ...


Current caveats
(1) I've had to remove the man pages installation.


1. Why?

In general, if a major change is needed when updating a port,
it is useful to mention the reason.


2. Isn't that a blocker?

For a programming library, having section 3 documentation seems
crucial to me.  What is the point of an undocumented public API?

Yes, i am aware that lapack is among the last 20 or so ports that
require USE_GROFF, and among the worst handful of these because the
man(7) code is both unusually problematic from a qualitative
standpoint (.ti nested inside .TP head, ...) and also hard to handle
from a perspective of quantity - the library is so large that even
reviewing the manual pages regarding which problems are contained
in them isn't easy.

But none of that should be your problem, nor should it prevent
formatting the manual pages with groff and installing them.

Yours,
   Ingo



That's fair. I removed them as it seemed like none of the other
distributions are installing them in this package.
Some of them have a separate man-pages packages for lapack.
Other reason was that the man pages haven't been updated from 2007.
So I am also not sure if they are the most up to date.
But as you said, having them is better than not having them.

I can try to add them back but it might take some more time.

Aisha



Re: Update to py-requests-2.24.0

2020-10-28 Thread Daniel Jakots
On Wed, 14 Oct 2020 22:32:56 -0400, Daniel Jakots  wrote:

> On Wed, 14 Oct 2020 13:06:33 +0200, Antoine Jacoutot
>  wrote:
> 
> > > Here's a diff for py-requests. I had trouble with 2.23's test
> > > suite. I found a solution for 2.24 from
> > > https://github.com/pytest-dev/pytest/issues/2042#issuecomment-429289164
> > > 
> > > There are still some failures.
> > 
> > Looks fine to me.
> > Do these failures appear in the previous version?  
> 
> No, tests in the current version are better. There are some
> failures because 
> SSLError: HTTPSConnectionPool(host='127.0.0.1', port=37564): Max
> retries exceeded with url:
> /redirect-to?url=http%3A%2F%2F127.0.0.1%3A12892%2Fget (Caused by
> SSLError(CertificateError("hostname '127.0.0.1' doesn't match either
> of 'localhost', '127.0.0.1'",),))
> which is weird. I don't remember them
> from last time I updated the port, so maybe a TDEP changed in the
> meantime?
> 
> Anyway, I've been using the update and it works fine for me (that
> said, my requests use is quite small).

ping



NEW: devel/rebar3 (again)

2020-10-28 Thread Jonathan Matthew
I picked up an earlier attempt at a port for rebar3, the successor to
devel/rebar.  My main interest in this is that I need it to revive
databases/riak, so for now it's at the version that riak requires.

rebar3 loves downloading things and updating git checkouts when you ask it to
build something.  To convince it to not do that, I've added all its
dependencies as distfiles that are downloaded from http://hex.pm/ and
extracted into two locations, one to stop the rebar3 bootstrap from
downloading them, the second to stop the bootstrapped rebar3 from doing it.

The patches are all in support of using versioned erl and escript binaries.
Since the rebar3 binary is called rebar3, what should its erlang-versioned
binaries be called?  They currently end up called 'rebar3-21' for erlang21,
which isn't great, but I can't think of anything better.

ok to import?



rebar3.tar.gz
Description: application/tar-gz


Re: [update] redis 6.0.9

2020-10-28 Thread Jeremie Courreges-Anglas
On Tue, Oct 27 2020, Theo Buehler  wrote:
> On Tue, Oct 27, 2020 at 07:18:30PM +0100, Jeremie Courreges-Anglas wrote:
>> On Tue, Oct 27 2020, Theo Buehler  wrote:
>> > Raltively simple update to Redis 6.0.9.
>> >
>> > Upgrade urgency is MODERATE due to a local patch for zmalloc. Thanks to
>> > the upstream fix, we can now remove it. We need a new trivial time_t
>> > patch.
>> 
>> [...]
>> 
>> > Index: patches/patch-src_debug_c
>> > ===
>> > RCS file: patches/patch-src_debug_c
>> > diff -N patches/patch-src_debug_c
>> > --- /dev/null  1 Jan 1970 00:00:00 -
>> > +++ patches/patch-src_debug_c  27 Oct 2020 12:59:32 -
>> > @@ -0,0 +1,16 @@
>> > +$OpenBSD$
>> > +
>> > +time_t is long long on OpenBSD
>> > +
>> > +Index: src/debug.c
>> > +--- src/debug.c.orig
>> >  src/debug.c
>> > +@@ -408,7 +408,7 @@ NULL
>> > + } else if (!strcasecmp(c->argv[1]->ptr,"segfault")) {
>> > + *((char*)-1) = 'x';
>> > + } else if (!strcasecmp(c->argv[1]->ptr,"panic")) {
>> > +-serverPanic("DEBUG PANIC called at Unix time %ld", time(NULL));
>> > ++serverPanic("DEBUG PANIC called at Unix time %lld", time(NULL));
>> 
>> The preferred approach would be
>> 
>> ++serverPanic("DEBUG PANIC called at Unix time %lld", (long 
>> long)time(NULL));
>> 
>> which can usually be pushed upstream.  redis seems to use "long long"
>> already so it shouldn't be a problem.
>
> Alright I'll add the cast before commit.
>
> There's another time_t patch in the port already. If you see a nicer
> variant for that (should we just use long long instead of time_t?), feel
> free to fix that.

The existing diff looks fine to me.  IIUC it makes for proper logging of
this warning even on the first call of securityWarningCommand() on a 32
bits machine after y2038.

> $OpenBSD: patch-src_networking_c,v 1.4 2020/09/03 04:29:27 tb Exp $
>
> time_t is long long, so use llabs to avoid truncation
>
> Index: src/networking.c
> --- src/networking.c.orig
> +++ src/networking.c
> @@ -2651,7 +2651,7 @@ void securityWarningCommand(client *c) {
>  static time_t logged_time;
>  time_t now = time(NULL);
>  
> -if (labs(now-logged_time) > 60) {
> +if (llabs(now-logged_time) > 60) {
>  serverLog(LL_WARNING,"Possible SECURITY ATTACK detected. It looks 
> like somebody is sending POST or Host: commands to Redis. This is likely due 
> to an attacker attempting to use Cross Protocol Scripting to compromise your 
> Redis instance. Connection aborted.");
>  logged_time = now;
>  }
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



'make fix-permissions' directory ownership (PORTS_PRIVSEP)

2020-10-28 Thread Ricky Cintron
While setting up the ports tree on my system with PORTS_PRIVSEP enabled,
and after running 'doas make fix-permissions', I noticed that out of the
six affected directories under /usr/ports/ (bulk, distfiles, packages,
plist, pobj, update), both bulk and update were still owned by root.
Looking at infrastructure/mk/bsd.port.mk, I can see that BULK_COOKIES_DIR
and UPDATE_COOKIES_DIR are given to the _pbuild user, but their parent
directories (bulk and update) are not.

Since these two are the only root-owned directories in my ports tree, I
was wondering if giving them to the _pbuild user has been considered, or
perhaps there's a reason for doing it this way that I've overlooked. For
now I've set my user as the owner, but I feel setting them up like the
other four might make more sense.

I'm including a tested diff just in case I'm not completely off target
here.

Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1542
diff -u -p -u -r1.1542 bsd.port.mk
--- bsd.port.mk 26 Jun 2020 11:51:16 -  1.1542
+++ bsd.port.mk 28 Oct 2020 19:58:33 -
@@ -158,8 +158,10 @@ PORTSDIR ?= /usr/ports
 X11BASE ?= /usr/X11R6
 VARBASE ?= /var
 DISTDIR ?= ${PORTSDIR}/distfiles
-BULK_COOKIES_DIR ?= ${PORTSDIR}/bulk/${MACHINE_ARCH}
-UPDATE_COOKIES_DIR ?= ${PORTSDIR}/update/${MACHINE_ARCH}
+BULKDIR ?= ${PORTSDIR}/bulk
+BULK_COOKIES_DIR ?= ${BULKDIR}/${MACHINE_ARCH}
+UPDATEDIR ?= ${PORTSDIR}/update
+UPDATE_COOKIES_DIR ?= ${UPDATEDIR}/${MACHINE_ARCH}

 PLIST_REPOSITORY ?= ${PORTSDIR}/plist
 .if !empty(PLIST_REPOSITORY)
@@ -2075,7 +2077,8 @@ fix-permissions:
fi
 .  for d in ${LOCKDIR} ${PACKAGE_REPOSITORY} \
${PACKAGE_REPOSITORY}/${MACHINE_ARCH} \
-   ${BULK_COOKIES_DIR} ${UPDATE_COOKIES_DIR} \
+   ${BULKDIR} ${BULK_COOKIES_DIR} \
+   ${UPDATEDIR} ${UPDATE_COOKIES_DIR} \
${PLIST_REPOSITORY} ${WRKOBJDIR}
@b=`id -gn ${BUILD_USER}`; \
echo "give $d to ${BUILD_USER}:$$b"; \



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/10/28 17:31:59

Modified files:
sysutils/ugrep : Makefile distinfo 

Log message:
Update to ugrep-3.0.4
Changelog: https://github.com/Genivia/ugrep/releases/tag/v3.0.4



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/10/28 17:17:36

Modified files:
sysutils/diffoscope: Makefile distinfo 
sysutils/diffoscope/pkg: PLIST 

Log message:
Update to diffoscope-161



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/10/28 17:07:32

Modified files:
multimedia/streamlink: Makefile distinfo 
multimedia/streamlink/pkg: PLIST 

Log message:
Update to streamlink-1.7.0
Changelog: https://github.com/streamlink/streamlink/releases/tag/1.7.0



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/10/28 16:47:00

Modified files:
games/julius   : Makefile distinfo 

Log message:
Update to julius-1.5.1
This version is the same as 1.5.0 with a fix for Android, the 1.5.0
changelog is here: https://github.com/bvschaik/julius/releases/tag/v1.5.0



Re: TMPDIR for building go ports ?

2020-10-28 Thread Matthieu Herrb
On Wed, Oct 28, 2020 at 08:59:14PM +, Stuart Henderson wrote:
> On 2020/10/28 21:34, Matthieu Herrb wrote:
> > Hi,
> > 
> > On one of my machines where I'm building ports, I have a /tmp
> > partition that is a  too small (300MB) for building many of the go
> > ports (gitea, facette,...)
> > 
> > Those ports seem to unconditionnaly use /tmp as intermediate storage.
> > 
> > I've plenty of space under /usr/ports. Is there a knob somehere to
> > tell ports build (via dpb) to write to, let's say /usr/ports/tmp
> > instead.
> > 
> > (I've tried seting the TMPDIR environment variable without success...)
> > 
> > Thanks.
> > -- 
> > Matthieu Herrb
> > 
> 
> This might be one way to do it..

That works. Thanks a lot.

> 
> Index: go.port.mk
> ===
> RCS file: /cvs/ports/lang/go/go.port.mk,v
> retrieving revision 1.35
> diff -u -p -r1.35 go.port.mk
> --- go.port.mk9 Oct 2020 13:23:51 -   1.35
> +++ go.port.mk28 Oct 2020 20:58:37 -
> @@ -45,6 +45,7 @@ MODGO_GOPATH ?= ${MODGO_WORKSPACE}:${MO
>  # to explicitly disable SSE on i386 builds.
>  MAKE_ENV +=  GO386=387
>  MAKE_ENV +=  GOCACHE="${MODGO_GOCACHE}"
> +MAKE_ENV +=  GOTMPDIR="${WRKDIR}/go-tmp"
>  
>  MODGO_CMD ?= ${SETENV} ${MAKE_ENV} go
>  MODGO_BUILD_CMD =${MODGO_CMD} install ${MODGO_FLAGS}
> @@ -107,6 +108,8 @@ MODGO_SETUP_WORKSPACE =   mkdir -p ${WRKSR
>  WRKSRC ?=${WRKDIR}/${MODGO_MODNAME}@${MODGO_VERSION}
>  MODGO_SETUP_WORKSPACE =  ln -sf ${WRKSRC} ${WRKDIR}/${MODGO_MODNAME}
>  .endif
> +
> +MODGO_SETUP_WORKSPACE += mkdir -p ${WRKDIR}/go-tmp;
>  
>  INSTALL_STRIP =
>  .if ${MODGO_TYPE:L:Mbin}

-- 
Matthieu Herrb



Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

On 10/28/20 1:12 PM, Aisha Tammy wrote:

On 10/28/20 8:23 AM, Aisha Tammy wrote:

On 10/28/20 7:46 AM, Stuart Henderson wrote:

+cc some people who might be interested to make sure they see this :)

On 2020/10/28 07:32, Aisha Tammy wrote:

Hi,
I was wondering if it is possible to have multiple providers for a library
and then selecting one of them to be used, selecting which provider is
to be installed.
Case in point, we have the math/{lapack,blas} libraries, which are the
reference implementations and not optimized.
I am working on getting OpenBLAS built and ported, which can also
provide the libblas.so and liblapack.so (among other libraries).
It is ABI compatible with the latest BLAS/LAPACK standards so it should
ideally be a drop in replacement for the libraries for math/{lapack,blas}.
This way there is a significant runtime benefit for multiple science
libraries like numpy, scipy, eigen and a bunch of others.
This replacement mechanism is provided in Gentoo and Debian (and its
derivatives).
I don't think we can have the full replacement mechanism at runtime
due to the linking mechanism being different but it should at least
be possible during install time and relinking libraries.
I am not sure how to go about doing this in OpenBSD.

Is there any interest in doing this? I am hoping I can put something
together if people are interested in wanting OpenBLAS based libraries

Cheers,
Aisha

Having alternatives like this is similar to the case where a library has
flavours, which certainly adds complication - we mostly resist doing this
in ports, the exception is apr-util's ldap flavour and I wouldn't really
want to add more.

Is there likely to be a downside to switching outright to OpenBLAS?



Theoretically no, as it is supposed to be ABI compatible.
Reality is often disappointing.
The reference implementations focus on correctness while
OpenBLAS implementation focuses on speed.
So it is *possible* that there may be bugs in the OpenBLAS
based libraries (not saying that reference impl is perfect).

I agree that this will complicate things.
There are like 4 different providers of BLAS/LAPACK that I am
maintaining in Gentoo. I do not want to add all of them in
OpenBSD, OpenBLAS is by far the superior alternative to the
other 3.
The general method for development: write code using BLAS,
test with reference impl, then use in production with OpenBLAS.

One way in which I think this can be simplified:
Combine math/BLAS and math/LAPACK into one package - math/LAPACK
which can supply both libraries. Almost every package which needs
BLAS also needs LAPACK, so there is little configurability that
we lose here.
Then there can be two flavors math/LAPACK-reference and
math/LAPACK-openblas.
More fixes I want to add - add LAPACKE library as well.
For some reason, we don't seem to be building that one.

Best,
Aisha


Hi,
Here is a preliminary version update of math/lapack to 3.9.0
with some patches from debian and gentoo.
Current caveats
(1) I've had to remove the man pages installation.
(2) I am not sure how to enable tests without explicitly putting
the BUILD_TESTING=ON by default, but it adds ~3000 targets
on top of the default ~6700 targets, which is A LOT. But building
the port with BUILD_TESTING=ON and then doing make test works
and all 121 tests pass.
This would be the lapack-reference flavour later, if we do implement the
lapack/openblas thing.
In any case, this should be useful by itself.
Also, this obsoletes the math/blas and math/cblas packages.
This also adds building the lapacke library, which was not being done
before this.

Cheers
Aisha 



git is based and dank af, cuz it does not add new files in git diff...

reattaching diff with new patches as well

Aisha


diff --git a/math/lapack/Makefile b/math/lapack/Makefile
index 85e2b1a3565..ef961bfe003 100644
--- a/math/lapack/Makefile
+++ b/math/lapack/Makefile
@@ -2,14 +2,17 @@
 
 COMMENT=	library of Fortran linear algebra subroutines
 
-VERSION=	3.8.0

-DISTNAME=  lapack-${VERSION}
-REVISION=  1
+CATEGORIES=math devel
 
-SHARED_LIBS=	lapack 7.1

+VERSION=   3.9.0
+GH_ACCOUNT=Reference-LAPACK
+GH_PROJECT=lapack
+GH_TAGNAME=v${VERSION}
 
-CATEGORIES=	math

-DISTFILES= ${DISTNAME}.tar.gz manpages.tgz:0
+SHARED_LIBS=   lapack 7.2 \
+   lapacke 7.2 \
+   blas 7.2 \
+   cblas 7.2
 
 HOMEPAGE=	http://www.netlib.org/lapack/
 
@@ -18,69 +21,15 @@ MAINTAINER=	Steven Mestdagh 

 # BSD
 PERMIT_PACKAGE=Yes
 
-MASTER_SITES=	https://www.netlib.org/lapack/ \

-   https://www.netlib.no/netlib/lapack/
-MASTER_SITES0= https://www.netlib.org/lapack/
-DIST_SUBDIR=   ${DISTNAME}
+WANTLIB+=  m
 
-LIB_DEPENDS =	math/blas

-WANTLIB =  blas>=1 m
-
-MODULES=   fortran
+MODULES=   devel/cmake fortran
 MODFORTRAN_COMPILER = gfortran
 BUILD_DEPENDS= ${MODFORTRAN_BUILD_DEPENDS}
 
-MAKE_ENV=	SHLIB_MAJOR=${LIBlapack_VERSION:R} \

-   SHLIB_MINOR=${LIBlapack_VERSION:E} \
-  

Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

On 10/28/20 8:23 AM, Aisha Tammy wrote:

On 10/28/20 7:46 AM, Stuart Henderson wrote:

+cc some people who might be interested to make sure they see this :)

On 2020/10/28 07:32, Aisha Tammy wrote:

Hi,
I was wondering if it is possible to have multiple providers for a library
and then selecting one of them to be used, selecting which provider is
to be installed.
Case in point, we have the math/{lapack,blas} libraries, which are the
reference implementations and not optimized.
I am working on getting OpenBLAS built and ported, which can also
provide the libblas.so and liblapack.so (among other libraries).
It is ABI compatible with the latest BLAS/LAPACK standards so it should
ideally be a drop in replacement for the libraries for math/{lapack,blas}.
This way there is a significant runtime benefit for multiple science
libraries like numpy, scipy, eigen and a bunch of others.
This replacement mechanism is provided in Gentoo and Debian (and its
derivatives).
I don't think we can have the full replacement mechanism at runtime
due to the linking mechanism being different but it should at least
be possible during install time and relinking libraries.
I am not sure how to go about doing this in OpenBSD.

Is there any interest in doing this? I am hoping I can put something
together if people are interested in wanting OpenBLAS based libraries

Cheers,
Aisha

Having alternatives like this is similar to the case where a library has
flavours, which certainly adds complication - we mostly resist doing this
in ports, the exception is apr-util's ldap flavour and I wouldn't really
want to add more.

Is there likely to be a downside to switching outright to OpenBLAS?



Theoretically no, as it is supposed to be ABI compatible.
Reality is often disappointing.
The reference implementations focus on correctness while
OpenBLAS implementation focuses on speed.
So it is *possible* that there may be bugs in the OpenBLAS
based libraries (not saying that reference impl is perfect).

I agree that this will complicate things.
There are like 4 different providers of BLAS/LAPACK that I am
maintaining in Gentoo. I do not want to add all of them in
OpenBSD, OpenBLAS is by far the superior alternative to the
other 3.
The general method for development: write code using BLAS,
test with reference impl, then use in production with OpenBLAS.

One way in which I think this can be simplified:
Combine math/BLAS and math/LAPACK into one package - math/LAPACK
which can supply both libraries. Almost every package which needs
BLAS also needs LAPACK, so there is little configurability that
we lose here.
Then there can be two flavors math/LAPACK-reference and
math/LAPACK-openblas.
More fixes I want to add - add LAPACKE library as well.
For some reason, we don't seem to be building that one.

Best,
Aisha


Hi,
Here is a preliminary version update of math/lapack to 3.9.0
with some patches from debian and gentoo.
Current caveats
(1) I've had to remove the man pages installation.
(2) I am not sure how to enable tests without explicitly putting
the BUILD_TESTING=ON by default, but it adds ~3000 targets
on top of the default ~6700 targets, which is A LOT. But building
the port with BUILD_TESTING=ON and then doing make test works
and all 121 tests pass.
This would be the lapack-reference flavour later, if we do implement the
lapack/openblas thing.
In any case, this should be useful by itself.
Also, this obsoletes the math/blas and math/cblas packages.
This also adds building the lapacke library, which was not being done
before this.

Cheers
Aisha

diff --git a/math/lapack/Makefile b/math/lapack/Makefile
index 85e2b1a3565..ef961bfe003 100644
--- a/math/lapack/Makefile
+++ b/math/lapack/Makefile
@@ -2,14 +2,17 @@
 
 COMMENT=	library of Fortran linear algebra subroutines
 
-VERSION=	3.8.0

-DISTNAME=  lapack-${VERSION}
-REVISION=  1
+CATEGORIES=math devel
 
-SHARED_LIBS=	lapack 7.1

+VERSION=   3.9.0
+GH_ACCOUNT=Reference-LAPACK
+GH_PROJECT=lapack
+GH_TAGNAME=v${VERSION}
 
-CATEGORIES=	math

-DISTFILES= ${DISTNAME}.tar.gz manpages.tgz:0
+SHARED_LIBS=   lapack 7.2 \
+   lapacke 7.2 \
+   blas 7.2 \
+   cblas 7.2
 
 HOMEPAGE=	http://www.netlib.org/lapack/
 
@@ -18,69 +21,15 @@ MAINTAINER=	Steven Mestdagh 

 # BSD
 PERMIT_PACKAGE=Yes
 
-MASTER_SITES=	https://www.netlib.org/lapack/ \

-   https://www.netlib.no/netlib/lapack/
-MASTER_SITES0= https://www.netlib.org/lapack/
-DIST_SUBDIR=   ${DISTNAME}
+WANTLIB+=  m
 
-LIB_DEPENDS =	math/blas

-WANTLIB =  blas>=1 m
-
-MODULES=   fortran
+MODULES=   devel/cmake fortran
 MODFORTRAN_COMPILER = gfortran
 BUILD_DEPENDS= ${MODFORTRAN_BUILD_DEPENDS}
 
-MAKE_ENV=	SHLIB_MAJOR=${LIBlapack_VERSION:R} \

-   SHLIB_MINOR=${LIBlapack_VERSION:E} \
-   TIMER=EXT_ETIME \
-   FC="${MODFORTRAN_COMPILER} -cpp" \
-   CC=${MODFORTRAN_COMPILER}
-FAKE_FLAGS=LIBDIR=${LOCALBASE}/lib 

Re: TMPDIR for building go ports ?

2020-10-28 Thread Stuart Henderson
On 2020/10/28 21:34, Matthieu Herrb wrote:
> Hi,
> 
> On one of my machines where I'm building ports, I have a /tmp
> partition that is a  too small (300MB) for building many of the go
> ports (gitea, facette,...)
> 
> Those ports seem to unconditionnaly use /tmp as intermediate storage.
> 
> I've plenty of space under /usr/ports. Is there a knob somehere to
> tell ports build (via dpb) to write to, let's say /usr/ports/tmp
> instead.
> 
> (I've tried seting the TMPDIR environment variable without success...)
> 
> Thanks.
> -- 
> Matthieu Herrb
> 

This might be one way to do it..

Index: go.port.mk
===
RCS file: /cvs/ports/lang/go/go.port.mk,v
retrieving revision 1.35
diff -u -p -r1.35 go.port.mk
--- go.port.mk  9 Oct 2020 13:23:51 -   1.35
+++ go.port.mk  28 Oct 2020 20:58:37 -
@@ -45,6 +45,7 @@ MODGO_GOPATH ?=   ${MODGO_WORKSPACE}:${MO
 # to explicitly disable SSE on i386 builds.
 MAKE_ENV +=GO386=387
 MAKE_ENV +=GOCACHE="${MODGO_GOCACHE}"
+MAKE_ENV +=GOTMPDIR="${WRKDIR}/go-tmp"
 
 MODGO_CMD ?=   ${SETENV} ${MAKE_ENV} go
 MODGO_BUILD_CMD =  ${MODGO_CMD} install ${MODGO_FLAGS}
@@ -107,6 +108,8 @@ MODGO_SETUP_WORKSPACE = mkdir -p ${WRKSR
 WRKSRC ?=  ${WRKDIR}/${MODGO_MODNAME}@${MODGO_VERSION}
 MODGO_SETUP_WORKSPACE =ln -sf ${WRKSRC} ${WRKDIR}/${MODGO_MODNAME}
 .endif
+
+MODGO_SETUP_WORKSPACE += mkdir -p ${WRKDIR}/go-tmp;
 
 INSTALL_STRIP =
 .if ${MODGO_TYPE:L:Mbin}



Re: [UPDATE] x11/bspwm 0.9.9 -> 0.9.10

2020-10-28 Thread Jasper Lievisse Adriaanse
On Tue, Oct 27, 2020 at 09:22:54PM +, Ricky Cintron wrote:
> Update x11/bspwm from version 0.9.9 to 0.9.10.
> 
> Like the x11/sxhkd update, this is a simple update. However, I'd like
> to propose the removal of the following patch: patch-examples_bspwmrc.
> It doesn't seem necessary, and the change it applies would need to be
> undone in order to use a properly installed sxhkdrc.
> 
> If it's decided that the patch should remain, then I'll add the diff
> required for this patch.
> 
> Configured and tested on amd64.
Hi Ricky,

Thanks for this update (and for sxhkd). I had originally added the patch
to make it easier to get started with this window manager and sxhkd. However
I can see why this deviation from the default config would be confusing and I'll
drop the patch accordingly.

Cheers,
Jasper

> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/bspwm/Makefile,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 Makefile
> --- Makefile1 Sep 2019 14:01:23 -   1.3
> +++ Makefile27 Oct 2020 20:27:01 -
> @@ -4,7 +4,7 @@ COMMENT =   binary space partitioning win
> 
>  GH_PROJECT =   bspwm
>  GH_ACCOUNT =   baskerville
> -GH_TAGNAME =   0.9.9
> +GH_TAGNAME =   0.9.10
> 
>  CATEGORIES =   x11
> 
> Index: distinfo
> ===
> RCS file: /cvs/ports/x11/bspwm/distinfo,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 distinfo
> --- distinfo1 Sep 2019 14:01:23 -   1.2
> +++ distinfo27 Oct 2020 20:27:20 -
> @@ -1,2 +1,2 @@
> -SHA256 (bspwm-0.9.9.tar.gz) = sUOMPK0TthAe2zHOjQC6TtL5cnVOhbkPdj4E+lFDxvw=
> -SIZE (bspwm-0.9.9.tar.gz) = 19
> +SHA256 (bspwm-0.9.10.tar.gz) = DQ9eRlucJ6XCFDyGGJOS+il/rVUlO57Y9oVEc9OSj48=
> +SIZE (bspwm-0.9.10.tar.gz) = 114099
> 

-- 
jasper



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 14:52:47

Added files:
comms/gnuradio/patches: patch-volk_CMakeLists_txt 

Log message:
gnuradio: add a cmake patch that avoids a build error if doxygen was present
on the system earlier in configure, but was then removed before it reaches this
point. more details in the patch comment.



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/10/28 14:43:40

Modified files:
x11/bspwm  : Makefile distinfo 
Removed files:
x11/bspwm/patches: patch-examples_bspwmrc 

Log message:
- update to bspwm-0.9.10
- remove unneeded patch modifying the example config

from Ricky Cintron



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/10/28 14:43:02

Modified files:
x11/sxhkd  : Makefile distinfo 

Log message:
update to sxhkd-0.6.2

from Ricky Cintron



TMPDIR for building go ports ?

2020-10-28 Thread Matthieu Herrb
Hi,

On one of my machines where I'm building ports, I have a /tmp
partition that is a  too small (300MB) for building many of the go
ports (gitea, facette,...)

Those ports seem to unconditionnaly use /tmp as intermediate storage.

I've plenty of space under /usr/ports. Is there a knob somehere to
tell ports build (via dpb) to write to, let's say /usr/ports/tmp
instead.

(I've tried seting the TMPDIR environment variable without success...)

Thanks.
-- 
Matthieu Herrb



Re: [UPDATE] py-whisper and py-carbon to 1.1.7 + py3

2020-10-28 Thread Martin Reindl
On Wed, Oct 28, 2020 at 12:20:12PM +, Stuart Henderson wrote:
> 
> I've imported it and added a py2 version so I could move across from the
> older code in rrdtool main distfile. I've switched the existing py-whisper
> to use it, here's a refreshed diff for your py-whisper update which is OK
> with me.
> 
> Other than the /usr/local/storage dirs, your py-carbon update and the
> associated quirks/Makefile changes are also OK with me.

I've adapted setup.py to ignore the storage dirs with the dummy.txt's so
update-plist does not pick them up.
Final diff I'm about to commit:


Index: devel/quirks/Makefile
===
RCS file: /cvs/ports/devel/quirks/Makefile,v
retrieving revision 1.1077
diff -u -p -r1.1077 Makefile
--- devel/quirks/Makefile   28 Oct 2020 12:12:46 -  1.1077
+++ devel/quirks/Makefile   28 Oct 2020 19:47:37 -
@@ -5,7 +5,7 @@ CATEGORIES =devel databases
 DISTFILES =
 
 # API.rev
-PKGNAME =  quirks-3.469
+PKGNAME =  quirks-3.470
 PKG_ARCH = *
 MAINTAINER =   Marc Espie 
 
Index: devel/quirks/files/Quirks.pm
===
RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.1095
diff -u -p -r1.1095 Quirks.pm
--- devel/quirks/files/Quirks.pm28 Oct 2020 12:12:46 -  1.1095
+++ devel/quirks/files/Quirks.pm28 Oct 2020 19:47:37 -
@@ -498,6 +498,8 @@ my $stem_extensions = {
'py-croniter' => 'py3-croniter',
'biopython' => 'py3-biopython',
'py-rrd' => 'py-rrdtool',
+   'py-whisper' => 'py3-whisper',
+   'py-carbon' => 'py3-carbon',
 };
 
 my $obsolete_reason = {
Index: databases/py-whisper/Makefile
===
RCS file: /cvs/ports/databases/py-whisper/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- databases/py-whisper/Makefile   28 Oct 2020 12:13:06 -  1.11
+++ databases/py-whisper/Makefile   28 Oct 2020 19:47:37 -
@@ -1,23 +1,27 @@
 # $OpenBSD: Makefile,v 1.11 2020/10/28 12:13:06 sthen Exp $
 
-COMMENT=   fixed size round-robin style database
+COMMENT =  fixed size round-robin style database
 
-MODPY_EGG_VERSION= 1.0.2
-REVISION=  0
+MODPY_EGG_VERSION =1.1.7
 
-DISTNAME=  whisper-${MODPY_EGG_VERSION}
-PKGNAME=   py-${DISTNAME}
-CATEGORIES=databases
+DISTNAME = whisper-${MODPY_EGG_VERSION}
+PKGNAME =  py-${DISTNAME}
+CATEGORIES =   databases
 
 # Apache
-PERMIT_PACKAGE=Yes
+PERMIT_PACKAGE =   Yes
 
-MODULES=   lang/python
+MODULES =  lang/python
 
 MODPY_PI = Yes
+MODPY_SETUPTOOLS = Yes
 
-RUN_DEPENDS=   net/py-rrdtool${MODPY_FLAVOR}
+FLAVORS =  python3
+FLAVOR =   python3
 
-NO_TEST =  Yes
+RUN_DEPENDS =  net/py-rrdtool${MODPY_FLAVOR}
+
+TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR} \
+   devel/py-six${MODPY_FLAVOR}
 
 .include 
Index: databases/py-whisper/distinfo
===
RCS file: /cvs/ports/databases/py-whisper/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- databases/py-whisper/distinfo   14 Nov 2017 15:59:27 -  1.6
+++ databases/py-whisper/distinfo   28 Oct 2020 19:47:37 -
@@ -1,2 +1,2 @@
-SHA256 (whisper-1.0.2.tar.gz) = Q9v7R9wUHBdKANjVYdsByfCZp18imTjJJ9fEQN2IK+w=
-SIZE (whisper-1.0.2.tar.gz) = 24064
+SHA256 (whisper-1.1.7.tar.gz) = huAeZudLW/6gbFNvCKpxuwfN3vrKbWqDUuKabt7gcSE=
+SIZE (whisper-1.1.7.tar.gz) = 37376
Index: databases/py-whisper/pkg/PLIST
===
RCS file: /cvs/ports/databases/py-whisper/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- databases/py-whisper/pkg/PLIST  8 Jul 2017 16:09:17 -   1.4
+++ databases/py-whisper/pkg/PLIST  28 Oct 2020 19:47:37 -
@@ -1,4 +1,6 @@
 @comment $OpenBSD: PLIST,v 1.4 2017/07/08 16:09:17 jasper Exp $
+@conflict py-whisper-*
+@pkgpath databases/py-whisper
 bin/find-corrupt-whisper-files.py
 bin/rrd2whisper.py
 bin/update-storage-times.py
@@ -15,6 +17,12 @@ bin/whisper-resize.py
 bin/whisper-set-aggregation-method.py
 bin/whisper-set-xfilesfactor.py
 bin/whisper-update.py
-lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}whisper.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt

Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Ingo Schwarze
Hi Aisha,

Aisha Tammy wrote on Wed, Oct 28, 2020 at 01:12:15PM -0400:

> Here is a preliminary version update of math/lapack to 3.9.0
> with some patches from debian and gentoo.

While FORTAN used to be my favourite language until about 1998,
i got out of the habit of using it after that, so i can't really
comment on the port in general, but ...

> Current caveats
> (1) I've had to remove the man pages installation.

1. Why?

In general, if a major change is needed when updating a port,
it is useful to mention the reason.


2. Isn't that a blocker?

For a programming library, having section 3 documentation seems
crucial to me.  What is the point of an undocumented public API?

Yes, i am aware that lapack is among the last 20 or so ports that
require USE_GROFF, and among the worst handful of these because the
man(7) code is both unusually problematic from a qualitative
standpoint (.ti nested inside .TP head, ...) and also hard to handle
from a perspective of quantity - the library is so large that even
reviewing the manual pages regarding which problems are contained
in them isn't easy.

But none of that should be your problem, nor should it prevent
formatting the manual pages with groff and installing them.

Yours,
  Ingo



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Theo Buehler
CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2020/10/28 13:19:40

Modified files:
security/py-tlsfuzzer: Makefile distinfo 

Log message:
Update to tlsfuzzer 20201026



Re: CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
On 2020/10/21 19:56, Aaron Bieber wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   abie...@cvs.openbsd.org 2020/10/21 19:56:22
> 
> Modified files:
>   sysutils/facette: Makefile 
> 
> Log message:
> Remove missed BROKEN marker.
> 

===>  Building for facette-0.5.1p0
gmake: git: No such file or directory
gmake: git: No such file or directory
*** Installing pre-commit Git hook...
*** Building assets...

> facette@ build /pobj/facette-0.5.1/facette-0.5.1/ui
> gulp --no-color build

[08:37:43] Using gulpfile ~/facette-0.5.1/ui/gulpfile.js
[08:37:43] Starting 'build'...
[08:37:43] Starting 'buildLocales'...
[08:37:43] Starting 'buildStyles'...
[08:37:43] Starting 'copyHtml'...
[08:37:43] Starting 'copyStyles'...
[08:37:43] Starting 'buildHtml'...
Browserslist: caniuse-lite is outdated. Please run next command `npm update`
[08:37:44] Finished 'copyHtml' after 286 ms
[08:37:44] Finished 'buildLocales' after 298 ms
[08:37:44] Finished 'copyStyles' after 320 ms
[08:37:44] Finished 'buildStyles' after 552 ms
[08:37:44] Finished 'buildHtml' after 661 ms
[08:37:44] Starting 'buildScripts'...
[08:37:44] Finished 'buildScripts' after 88 ms
[08:37:44] Finished 'build' after 752 ms
*** Building binaries for openbsd/386...
go: cloud.google.com/go@v0.26.0: Get 
"https://proxy.golang.org/cloud.google.com/go/@v/v0.26.0.mod": dial tcp: lookup 
proxy.golang.org on XXX:53: write udp XXX:44024->XXX:53: write: permission 
denied
gmake: *** [Makefile:64: build-bin] Error 1
*** Error 2 in sysutils/facette (/usr/ports/infrastructure/mk/bsd.port.mk:2928 
'/pobj/facette-0.5.1/.build_done': @cd /pobj/facette-0.5.1/fa...)
*** Error 2 in sysutils/facette (/usr/ports/infrastructure/mk/bsd.port.mk:2587 
'build': @lock=facette-0.5.1p0;  export _LOCKS_HELD=" facette...)
===> Exiting sysutils/facette with an error
*** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:137 'build': @: 
${echo_msg:=echo};  : ${target:=build};  for i in ; do  eval...)
>>> Ended at 1603895864.79
max_stuck=22.45/depends=28.01/show-prepare-results=0.97/build=12.86
Error: job failed with 512 on i386-3 at 1603895864



[update] picom 8.1 -> 8.2

2020-10-28 Thread Omar Polo
Hello ports,

Please find attached the patch to update picom to its latest release.
8.2 is a bugfix release.  Changelog here[0].

I also took the liberty to fix the formatting string: uint64_t requires
%llu and not %lu (AFAIK this should be the case on all platforms, and I
didn’t want to include inttypes.h as the diff would be a bit more
verbose).

Comments? OK?

[0]: https://github.com/yshui/picom/releases/tag/v8.2

Index: Makefile
===
RCS file: /cvs/ports/x11/picom/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile16 Sep 2020 08:04:43 -  1.2
+++ Makefile28 Oct 2020 12:46:32 -
@@ -4,7 +4,7 @@ COMMENT =   lightweight compositor for X11
 
 GH_ACCOUNT =   yshui
 GH_PROJECT =   picom
-GH_TAGNAME =   v8.1
+GH_TAGNAME =   v8.2
 
 CATEGORIES =   x11
 
Index: distinfo
===
RCS file: /cvs/ports/x11/picom/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo16 Sep 2020 08:04:43 -  1.2
+++ distinfo28 Oct 2020 12:46:32 -
@@ -1,2 +1,2 @@
-SHA256 (picom-8.1.tar.gz) = eTcAqHNoEgaAorKB2wLHCyP+eDLlDNsEkUkTnjJojwI=
-SIZE (picom-8.1.tar.gz) = 242262
+SHA256 (picom-8.2.tar.gz) = nQwlM5helnD/F15xekK1vxoqAMzeXKweEAn11u55Euw=
+SIZE (picom-8.2.tar.gz) = 242653
Index: patches/patch-src_picom_c
===
RCS file: patches/patch-src_picom_c
diff -N patches/patch-src_picom_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_picom_c   28 Oct 2020 12:46:32 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/picom.c
+--- src/picom.c.orig
 src/picom.c
+@@ -99,7 +99,7 @@ const char *const BACKEND_STRS[] = {[BKEND_XRENDER] = 
+ session_t *ps_g = NULL;
+ 
+ void set_root_flags(session_t *ps, uint64_t flags) {
+-  log_debug("Setting root flags: %lu", flags);
++  log_debug("Setting root flags: %llu", flags);
+   ps->root_flags |= flags;
+   ps->pending_updates = true;
+ }
Index: patches/patch-src_win_c
===
RCS file: patches/patch-src_win_c
diff -N patches/patch-src_win_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_win_c 28 Oct 2020 12:46:32 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index: src/win.c
+--- src/win.c.orig
 src/win.c
+@@ -2343,7 +2343,7 @@ win_is_fullscreen_xcb(xcb_connection_t *c, const struc
+ 
+ /// Set flags on a window. Some sanity checks are performed
+ void win_set_flags(struct managed_win *w, uint64_t flags) {
+-  log_debug("Set flags %lu to window %#010x (%s)", flags, w->base.id, 
w->name);
++  log_debug("Set flags %llu to window %#010x (%s)", flags, w->base.id, 
w->name);
+   if (unlikely(w->state == WSTATE_DESTROYING)) {
+   log_error("Flags set on a destroyed window %#010x (%s)", 
w->base.id, w->name);
+   return;
+@@ -2354,7 +2354,7 @@ void win_set_flags(struct managed_win *w, uint64_t fla
+ 
+ /// Clear flags on a window. Some sanity checks are performed
+ void win_clear_flags(struct managed_win *w, uint64_t flags) {
+-  log_debug("Clear flags %lu from window %#010x (%s)", flags, w->base.id, 
w->name);
++  log_debug("Clear flags %llu from window %#010x (%s)", flags, 
w->base.id, w->name);
+   if (unlikely(w->state == WSTATE_DESTROYING)) {
+   log_warn("Flags cleared on a destroyed window %#010x (%s)", 
w->base.id,
+w->name);



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 12:34:34

Modified files:
audio/ncspot   : Makefile distinfo 
audio/ncspot/patches: patch-Cargo_toml 

Log message:
update to ncspot-0.2.4, from maintainer Henrik Friedrichsen



maintainer update: www/hugo 0.76.5

2020-10-28 Thread Paco Esteban
Hi ports@,

This is an update for www/hugo to its latest version 0.76.5.

Builds and runs ok for me on amd64.  As usual, testing from actual hugo
users is really appreciated.

The changelog here and diff at the end.

  * Add Do Not Track (dnt) option to Vimeo shortcode edc5c474 @joshgerdes #7700
  * Regen docshelper b9318e43 @bep
  * Make BuildConfig.Render an enum 63493890 @bep #7783
  * Allow cascade to be a slice with a _target discriminator c63db7f1 @bep #7782
  * Add force flag to server redirects config 5e2a547c @bep #7778
  * bump github.com/evanw/esbuild from 0.7.8 to 0.7.9 ee090c09 @dependabot[bot]
  * bump github.com/tdewolff/minify/v2 from 2.9.5 to 2.9.7 05e358fd 
@dependabot[bot]
  * bump github.com/aws/aws-sdk-go from 1.34.34 to 1.35.0 a2e85d9a 
@dependabot[bot]
  * bump github.com/getkin/kin-openapi from 0.22.0 to 0.22.1 4fba78dd 
@dependabot[bot]
  * bump github.com/aws/aws-sdk-go from 1.34.33 to 1.34.34 c011b466 
@dependabot[bot]
  * bump github.com/evanw/esbuild from 0.7.7 to 0.7.8 35348b4b @dependabot[bot]
  * bump github.com/aws/aws-sdk-go from 1.34.27 to 1.34.33 34915777 
@dependabot[bot]
  * bump github.com/evanw/esbuild from 0.7.4 to 0.7.7 0f4a837e @dependabot[bot]
  * bump github.com/tdewolff/minify/v2 from 2.9.4 to 2.9.5 b395d686 
@dependabot[bot]
  * Upgrade to go-i18n v2 97987e5c @bep #5242
  * bump github.com/evanw/esbuild from 0.7.2 to 0.7.4 4855c186 @dependabot[bot]
  * bump github.com/aws/aws-sdk-go from 1.34.26 to 1.34.27 6f07ec7e 
@dependabot[bot]
  * bump github.com/alecthomas/chroma from 0.8.0 to 0.8.1 4318dc72 
@dependabot[bot]
  * bump github.com/evanw/esbuild from 0.7.1 to 0.7.2 acdc27a3 @dependabot[bot]
  * Make sure CSS is rebuilt when postcss.config.js or tailwind.config.js 
changes 3acde9ae @bep #7715
  * bump github.com/aws/aws-sdk-go from 1.34.22 to 1.34.26 0bce9770 
@dependabot[bot]
  * Update to github.com/tdewolff/minify v2.9.4 b254532b @bep
  * Bump bundled Node.js from v12.18.3 to v12.18.4 05a22892 @anthonyfok
  * Add preserveTOC option 8e553dcd @helfper
  * bump github.com/frankban/quicktest from 1.10.2 to 1.11.0 d4fc70a3 
@dependabot[bot]
  * bump github.com/evanw/esbuild from 0.6.32 to 0.7.1 d905abc0 @dependabot[bot]
  * bump github.com/rogpeppe/go-internal from 1.5.1 to 1.6.2 8f394674 
@dependabot[bot]
  * bump github.com/jdkato/prose from 1.1.1 to 1.2.0 b01b2564 @dependabot[bot]
  * bump github.com/spf13/afero from 1.2.2 to 1.4.0 9fa5ebe2 @dependabot[bot]
  * Preserve the original package.json if it exists 214afe4c @bep #7690
  * Fix grammar in the new 'requires non-zero' error message cd830bb0 @nekr0z
  * Fix writeStats with quote inside quotes 11134411 @bep #7746
  * Fix CLI example for PostCSS 8 0c3d2b67 @ai
  * Fix typo in redirect error message 473b6610 @jmooring
  * Fix nilpointer for images with no Exif cd00f7f9 @bep #7688
  * langs/i18n: Fix i18n .Count regression f9e798e8 @bep #7787
  * Revert "deps: Update to github.com/tdewolff/minify v2.9.4" 6dd60fca @bep 
#7792
  * langs/i18n: Add workaround for known language, but missing plural rule 
error 33e9d79b @bep #7798
  * langs/i18n: Fix for bare TOML keys fc6abc39 @bep
  * snap: Install postcss v8 explicitly as it is now a peer dependency e9a7ebaf 
@anthonyfok
  * lang/i18n: Fix for language code case issue with pt-br etc. 50682043 @bep 
#7804
  * Merge branch 'release-0.76.3' 49972d07 @bep
  * Add merge helper c98132e3 @bep
  * Render aliases even if render=link 79a022a1 @bep #7832

diff 47eddbd4548efcea608008d6abb8609deb1c98f6 /usr/ports
blob - 96fa6653d21e544bbcf5e96da11fdec8dbe85d55
file + www/hugo/Makefile
--- www/hugo/Makefile
+++ www/hugo/Makefile
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS =${GO_ARCHS}
 COMMENT =  fast and flexible static site generator
 
 MODGO_MODNAME =github.com/gohugoio/hugo
-MODGO_VERSION =v0.75.1
+MODGO_VERSION =v0.76.5
 
 DISTNAME = hugo-${MODGO_VERSION}
 
@@ -77,7 +77,7 @@ MODGO_MODULES =   \
github.com/!shopify/toxiproxy
v2.1.4+incompatible \
github.com/akavel/rsrc   v0.8.0 \
github.com/alecthomas/assert 
v0.0.0-20170929043011-405dbfeb8e38 \
-   github.com/alecthomas/chroma v0.8.0 \
+   github.com/alecthomas/chroma v0.8.1 \
github.com/alecthomas/colour 
v0.0.0-20160524082231-60882d9e2721 \
github.com/alecthomas/kong   v0.2.4 \
github.com/alecthomas/kong-hcl   
v0.1.8-0.20190615233001-b21fea9723c8 \
@@ -89,7 +89,7 @@ MODGO_MODULES =   \
github.com/armon/consul-api  
v0.0.0-20180202201655-eb2c6b5be1b6 \
github.com/armon/go-metrics  
v0.0.0-20180917152333-f0300d1749da \
github.com/armon/go-radixv1.0.0 \
-   github.com/aws/aws-sdk-go

Re: [UPDATE] arduino-esp32 1.0.4 -> Revision 1

2020-10-28 Thread Tracey Emery
On Mon, Oct 19, 2020 at 08:35:49AM -0600, Tracey Emery wrote:
> Hello,
> 
> This update goes with my last email for the xtensa-esp32-elf port. It is
> just some patch updates to work with the new version number.
> 
> I've tested this out on sparc64 and amd64 with no issues.
> 
> Ok to commit?

Ping. Anoyone have time to ok this? I can't get the xtensa-esp32-elf
commit in without this guy too. --thanks

> 
> -- 
> 
> Tracey Emery
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/arduino-esp32/Makefile,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 Makefile
> --- Makefile  3 Jul 2020 21:12:38 -   1.2
> +++ Makefile  19 Oct 2020 14:14:35 -
> @@ -4,7 +4,7 @@ COMMENT = esp32 arduino core toolset
>  V =  1.0.4
>  DISTNAME =   esp32-${V}
>  PKGNAME =arduino-${DISTNAME}
> -REVISION =   0
> +REVISION =   1
>  
>  CATEGORIES = devel
>  
> Index: patches/patch-platform_txt
> ===
> RCS file: /cvs/ports/devel/arduino-esp32/patches/patch-platform_txt,v
> retrieving revision 1.1.1.1
> diff -u -p -u -r1.1.1.1 patch-platform_txt
> --- patches/patch-platform_txt23 Apr 2020 14:30:30 -  1.1.1.1
> +++ patches/patch-platform_txt19 Oct 2020 14:14:35 -
> @@ -37,7 +37,7 @@ Index: platform.txt
>  -compiler.path={runtime.tools.xtensa-esp32-elf-gcc.path}/bin/
>   compiler.sdk.path={runtime.platform.path}/tools/sdk
>  -compiler.cpreprocessor.flags=-DESP_PLATFORM 
> -DMBEDTLS_CONFIG_FILE="mbedtls/esp_config.h" -DHAVE_CONFIG_H 
> -DGCC_NOT_5_2_0=0 -DWITH_POSIX "-I{compiler.sdk.path}/include/config" 
> "-I{compiler.sdk.path}/include/app_trace" 
> "-I{compiler.sdk.path}/include/app_update" 
> "-I{compiler.sdk.path}/include/asio" 
> "-I{compiler.sdk.path}/include/bootloader_support" 
> "-I{compiler.sdk.path}/include/bt" "-I{compiler.sdk.path}/include/coap" 
> "-I{compiler.sdk.path}/include/console" 
> "-I{compiler.sdk.path}/include/driver" 
> "-I{compiler.sdk.path}/include/esp-tls" "-I{compiler.sdk.path}/include/esp32" 
> "-I{compiler.sdk.path}/include/esp_adc_cal" 
> "-I{compiler.sdk.path}/include/esp_event" 
> "-I{compiler.sdk.path}/include/esp_http_client" 
> "-I{compiler.sdk.path}/include/esp_http_server" 
> "-I{compiler.sdk.path}/include/esp_https_ota" 
> "-I{compiler.sdk.path}/include/esp_ringbuf" 
> "-I{compiler.sdk.path}/include/ethernet" 
> "-I{compiler.sdk.path}/include/expat" "-I{compiler.sdk.path}/include/fatfs" 
> "-I{compiler.sdk.path}/include/freemodbus" 
> "-I{compiler.sdk.path}/include/freertos" "-I{compiler.sdk.path}/include/heap" 
> "-I{compiler.sdk.path}/include/idf_test" "-I{compiler.sdk.path}/include/jsmn" 
> "-I{compiler.sdk.path}/include/json" 
> "-I{compiler.sdk.path}/include/libsodium" "-I{compiler.sdk.path}/include/log" 
> "-I{compiler.sdk.path}/include/lwip" "-I{compiler.sdk.path}/include/mbedtls" 
> "-I{compiler.sdk.path}/include/mdns" 
> "-I{compiler.sdk.path}/include/micro-ecc" 
> "-I{compiler.sdk.path}/include/mqtt" "-I{compiler.sdk.path}/include/newlib" 
> "-I{compiler.sdk.path}/include/nghttp" 
> "-I{compiler.sdk.path}/include/nvs_flash" 
> "-I{compiler.sdk.path}/include/openssl" 
> "-I{compiler.sdk.path}/include/protobuf-c" 
> "-I{compiler.sdk.path}/include/protocomm" 
> "-I{compiler.sdk.path}/include/pthread" "-I{compiler.sdk.path}/include/sdmmc" 
> "-I{compiler.sdk.path}/include/smartconfig_ack" 
> "-I{compiler.sdk.path}/include/soc" "-I{compiler.sdk.path}/include/spi_flash" 
> "-I{compiler.sdk.path}/include/spiffs" 
> "-I{compiler.sdk.path}/include/tcp_transport" 
> "-I{compiler.sdk.path}/include/tcpip_adapter" 
> "-I{compiler.sdk.path}/include/ulp" "-I{compiler.sdk.path}/include/vfs" 
> "-I{compiler.sdk.path}/include/wear_levelling" 
> "-I{compiler.sdk.path}/include/wifi_provisioning" 
> "-I{compiler.sdk.path}/include/wpa_supplicant" 
> "-I{compiler.sdk.path}/include/xtensa-debug-module" 
> "-I{compiler.sdk.path}/include/esp-face" 
> "-I{compiler.sdk.path}/include/esp32-camera" 
> "-I{compiler.sdk.path}/include/esp-face" 
> "-I{compiler.sdk.path}/include/fb_gfx"
> -+compiler.cpreprocessor.flags=-DESP_PLATFORM 
> -DMBEDTLS_CONFIG_FILE="mbedtls/esp_config.h" -nostdinc -DHAVE_CONFIG_H 
> -DGCC_NOT_5_2_0=0 -DWITH_POSIX 
> "-I/usr/local/xtensa-esp32-elf/include/c++/8.2.0/xtensa-esp32-elf" 
> "-I/usr/local/xtensa-esp32-elf/include/c++/8.2.0/" 
> "-I/usr/local/lib/gcc/xtensa-esp32-elf/8.2.0/include" 
> "-I/usr/local/lib/gcc/xtensa-esp32-elf/8.2.0/include-fixed/" 
> "-I{compiler.sdk.path}/include/config" 
> "-I{compiler.sdk.path}/include/app_trace" 
> "-I{compiler.sdk.path}/include/app_update" 
> "-I{compiler.sdk.path}/include/asio" 
> "-I{compiler.sdk.path}/include/bootloader_support" 
> "-I{compiler.sdk.path}/include/bt" "-I{compiler.sdk.path}/include/coap" 
> "-I{compiler.sdk.path}/include/console" 
> "-I{compiler.sdk.path}/include/driver" 
> "-I{compiler.sdk.path}/include/esp-tls" 

CVS: cvs.openbsd.org: ports

2020-10-28 Thread Kirill Bychkov
CVSROOT:/cvs
Module name:ports
Changes by: ki...@cvs.openbsd.org   2020/10/28 11:52:16

Modified files:
net/seafile/client: Makefile distinfo 
net/seafile/seafile: Makefile distinfo 

Log message:
update seafile to 7.0.10



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 11:47:36

Modified files:
www/mozilla-firefox: Tag: OPENBSD_6_8 distinfo 

Log message:
sync distinfo, noticed by solene@



[UPDATE] audio/ncspot: 0.2.2 -> 0.2.4

2020-10-28 Thread Henrik Friedrichsen
Simple update from 0.2.2 to 0.2.4

Changes:
- https://github.com/hrkfdn/ncspot/releases/tag/v0.2.3
- https://github.com/hrkfdn/ncspot/releases/tag/v0.2.4

OK?? crates
? licenses
Index: Makefile
===
RCS file: /cvs/ports/audio/ncspot/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile2 Sep 2020 10:50:36 -   1.9
+++ Makefile28 Oct 2020 17:31:41 -
@@ -6,8 +6,7 @@ COMMENT =   ncurses Spotify client
 
 GH_ACCOUNT =   hrkfdn
 GH_PROJECT =   ncspot
-GH_TAGNAME =   v0.2.2
-REVISION = 0
+GH_TAGNAME =   v0.2.4
 
 CATEGORIES =   audio
 
@@ -36,7 +35,7 @@ MODCARGO_CRATES +=aes-ctr 0.3.0   # MIT O
 MODCARGO_CRATES += aes-soft0.3.3   # MIT OR Apache-2.0
 MODCARGO_CRATES += aesni   0.6.0   # MIT OR Apache-2.0
 MODCARGO_CRATES += ahash   0.3.8   # MIT OR Apache-2.0
-MODCARGO_CRATES += ahash   0.4.4   # MIT OR Apache-2.0
+MODCARGO_CRATES += ahash   0.4.5   # MIT OR Apache-2.0
 MODCARGO_CRATES += aho-corasick0.7.13  # Unlicense/MIT
 MODCARGO_CRATES += alga0.9.3   # Apache-2.0
 MODCARGO_CRATES += alsa0.2.2   # Apache-2.0/MIT
@@ -49,11 +48,10 @@ MODCARGO_CRATES +=  arrayref0.3.6   # BSD-
 MODCARGO_CRATES += arrayvec0.5.1   # MIT/Apache-2.0
 MODCARGO_CRATES += atty0.2.14  # MIT
 MODCARGO_CRATES += autocfg 0.1.7   # Apache-2.0/MIT
-MODCARGO_CRATES += autocfg 1.0.0   # Apache-2.0 OR MIT
-MODCARGO_CRATES += backtrace   0.3.50  # MIT/Apache-2.0
+MODCARGO_CRATES += autocfg 1.0.1   # Apache-2.0 OR MIT
+MODCARGO_CRATES += backtrace   0.3.52  # MIT/Apache-2.0
 MODCARGO_CRATES += base64  0.9.3   # MIT/Apache-2.0
 MODCARGO_CRATES += base64  0.10.1  # MIT/Apache-2.0
-MODCARGO_CRATES += base64  0.11.0  # MIT/Apache-2.0
 MODCARGO_CRATES += base64  0.12.3  # MIT/Apache-2.0
 MODCARGO_CRATES += bindgen 0.53.3  # BSD-3-Clause
 MODCARGO_CRATES += bit-set 0.5.2   # MIT/Apache-2.0
@@ -70,17 +68,19 @@ MODCARGO_CRATES +=  byte-tools  0.3.1   # MI
 MODCARGO_CRATES += byteorder   1.3.4   # Unlicense OR MIT
 MODCARGO_CRATES += bytes   0.4.12  # MIT
 MODCARGO_CRATES += bytes   0.5.6   # MIT
-MODCARGO_CRATES += cc  1.0.58  # MIT/Apache-2.0
+MODCARGO_CRATES += cc  1.0.61  # MIT/Apache-2.0
 MODCARGO_CRATES += cexpr   0.4.0   # Apache-2.0/MIT
 MODCARGO_CRATES += cfg-if  0.1.10  # MIT/Apache-2.0
-MODCARGO_CRATES += chrono  0.4.15  # MIT/Apache-2.0
+MODCARGO_CRATES += cfg-if  1.0.0   # MIT/Apache-2.0
+MODCARGO_CRATES += chrono  0.4.19  # MIT/Apache-2.0
 MODCARGO_CRATES += clang-sys   0.29.3  # Apache-2.0
 MODCARGO_CRATES += clap2.33.3  # MIT
 MODCARGO_CRATES += clipboard   0.5.0   # MIT / Apache-2.0
 MODCARGO_CRATES += clipboard-win   2.2.0   # MIT
 MODCARGO_CRATES += cloudabi0.0.3   # BSD-2-Clause
-MODCARGO_CRATES += const-random0.1.8   # MIT OR Apache-2.0
-MODCARGO_CRATES += const-random-macro  0.1.8   # MIT OR Apache-2.0
+MODCARGO_CRATES += const-random0.1.11  # MIT OR Apache-2.0
+MODCARGO_CRATES += const-random-macro  0.1.11  # MIT OR Apache-2.0
+MODCARGO_CRATES += const_fn0.4.2   # Apache-2.0 OR MIT
 MODCARGO_CRATES += constant_time_eq0.1.5   # CC0-1.0
 MODCARGO_CRATES += cookie  0.12.0  # MIT/Apache-2.0
 MODCARGO_CRATES += cookie_store0.7.0   # MIT/Apache-2.0
@@ -91,11 +91,13 @@ MODCARGO_CRATES +=  coreaudio-rs0.9.1   # 
 MODCARGO_CRATES += coreaudio-sys   0.2.5   # MIT
 MODCARGO_CRATES += cpal0.8.2   # Apache-2.0
 MODCARGO_CRATES += crc32fast   1.2.0   # MIT OR Apache-2.0
-MODCARGO_CRATES += crossbeam-channel   0.4.3   # MIT OR Apache-2.0
+MODCARGO_CRATES += crossbeam-channel   0.4.4   # MIT OR Apache-2.0
+MODCARGO_CRATES += crossbeam-channel   0.5.0   # MIT OR Apache-2.0
 MODCARGO_CRATES += crossbeam-deque 0.7.3   # MIT/Apache-2.0
 MODCARGO_CRATES += crossbeam-epoch 0.8.2   # MIT/Apache-2.0
 MODCARGO_CRATES += crossbeam-queue 0.2.3   # MIT/Apache-2.0 AND 
BSD-2-Clause
 MODCARGO_CRATES += crossbeam-utils 0.7.2   # MIT/Apache-2.0
+MODCARGO_CRATES += crossbeam-utils 0.8.0   # MIT OR Apache-2.0
 MODCARGO_CRATES += crypto-mac  0.7.0   # MIT OR Apache-2.0
 MODCARGO_CRATES += ctr 0.3.2   # MIT OR Apache-2.0
 MODCARGO_CRATES += cursive 0.15.0  # MIT
@@ -107,17 +109,19 @@ MODCARGO_CRATES +=darling_core0.10.2  #
 MODCARGO_CRATES += darling_macro   0.9.0   # MIT
 MODCARGO_CRATES += darling_macro   0.10.2  # MIT
 MODCARGO_CRATES += dbus0.8.4   # Apache-2.0/MIT
+MODCARGO_CRATES += dbus0.9.0   # Apache-2.0/MIT
+MODCARGO_CRATES += dbus-tree   0.9.0   # Apache-2.0/MIT
 MODCARGO_CRATES += derive_builder  0.7.2   # MIT/Apache-2.0
 MODCARGO_CRATES += derive_builder_core  

RE: RE: new: sysutils/mdf2iso

2020-10-28 Thread zeurkous
theo wrote:
> I thought you said you were leaving.

Again: me's not w/ you folks. Me merely thought me'd give you lot the
opportunity to see the patches that me's nicely going to publish
elsewhere (the mere reason they exist is that it helps me admin things;
yet as always: meshares what mecan).

> You really should do what you said you were going to do. I'm going
> to ask for you to be evicted from the list.

oh noez teh dramaz!1987319318!!1!1

Grow up.

--zeurkous.

-- 
Friggin' Machines!



Re: RE: new: sysutils/mdf2iso

2020-10-28 Thread Theo de Raadt
I thought you said you were leaving.

You really should do what you said you were going to do.  I'm going
to ask for you to be evicted from the list.



 wrote:

> "Tracey Emery"  wrote:
> > On Wed, Oct 28, 2020 at 04:06:43PM +0100, zeurk...@volny.cz wrote:
> >> "Stuart Henderson"  wrote:
> >> > On 2020/10/28 15:22, zeurk...@volny.cz wrote:
> >> > > #?patch
> >> > > #
> >> > > # (There seems to be a bug in diff(1) that causes the mandatory (yet
> >> > > # admittedly empty) pkg/DESCR file to be omitted. Just touch(1) it
> >> > > # yourself...)
> >> >
> >> > a blank pkg/DESCR is not acceptable.
> >>
> >> Then write one :) Me's not good at writing blurbs, and me really feels
> >> the COMMENT says it all.
> >>
> >
> > Then write one? Really?
> >
> >[lecture about what is supposed to be {,un}acceptable]
> 
> So much hate over a friendly suggestion... *shakes head*
> 
> > Go away or try again with a different attitude. There's too much work to
> > be done without filtering this crap.
> 
> Me's not with you. Me's sending what me has. If you don't like it: plonk
> it.
> 
> Welcome to real life.
> 
> --zeurkous.
> 
> -- 
> Friggin' Machines!
> 



Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

On 10/28/20 7:46 AM, Stuart Henderson wrote:

+cc some people who might be interested to make sure they see this :)

On 2020/10/28 07:32, Aisha Tammy wrote:

Hi,
I was wondering if it is possible to have multiple providers for a library
and then selecting one of them to be used, selecting which provider is
to be installed.
Case in point, we have the math/{lapack,blas} libraries, which are the
reference implementations and not optimized.
I am working on getting OpenBLAS built and ported, which can also
provide the libblas.so and liblapack.so (among other libraries).
It is ABI compatible with the latest BLAS/LAPACK standards so it should
ideally be a drop in replacement for the libraries for math/{lapack,blas}.
This way there is a significant runtime benefit for multiple science
libraries like numpy, scipy, eigen and a bunch of others.
This replacement mechanism is provided in Gentoo and Debian (and its
derivatives).
I don't think we can have the full replacement mechanism at runtime
due to the linking mechanism being different but it should at least
be possible during install time and relinking libraries.
I am not sure how to go about doing this in OpenBSD.

Is there any interest in doing this? I am hoping I can put something
together if people are interested in wanting OpenBLAS based libraries

Cheers,
Aisha


Having alternatives like this is similar to the case where a library has
flavours, which certainly adds complication - we mostly resist doing this
in ports, the exception is apr-util's ldap flavour and I wouldn't really
want to add more.

Is there likely to be a downside to switching outright to OpenBLAS?


Theoretically no, as it is supposed to be ABI compatible.
Reality is often disappointing.
The reference implementations focus on correctness while
OpenBLAS implementation focuses on speed.
So it is *possible* that there may be bugs in the OpenBLAS
based libraries (not saying that reference impl is perfect).

I agree that this will complicate things.
There are like 4 different providers of BLAS/LAPACK that I am
maintaining in Gentoo. I do not want to add all of them in
OpenBSD, OpenBLAS is by far the superior alternative to the
other 3.
The general method for development: write code using BLAS,
test with reference impl, then use in production with OpenBLAS.

One way in which I think this can be simplified:
Combine math/BLAS and math/LAPACK into one package - math/LAPACK
which can supply both libraries. Almost every package which needs
BLAS also needs LAPACK, so there is little configurability that
we lose here.
Then there can be two flavors math/LAPACK-reference and
math/LAPACK-openblas.
More fixes I want to add - add LAPACKE library as well.
For some reason, we don't seem to be building that one.

Best,
Aisha



Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

On 10/28/20 7:46 AM, Stuart Henderson wrote:

+cc some people who might be interested to make sure they see this :)

On 2020/10/28 07:32, Aisha Tammy wrote:

Hi,
I was wondering if it is possible to have multiple providers for a library
and then selecting one of them to be used, selecting which provider is
to be installed.
Case in point, we have the math/{lapack,blas} libraries, which are the
reference implementations and not optimized.
I am working on getting OpenBLAS built and ported, which can also
provide the libblas.so and liblapack.so (among other libraries).
It is ABI compatible with the latest BLAS/LAPACK standards so it should
ideally be a drop in replacement for the libraries for math/{lapack,blas}.
This way there is a significant runtime benefit for multiple science
libraries like numpy, scipy, eigen and a bunch of others.
This replacement mechanism is provided in Gentoo and Debian (and its
derivatives).
I don't think we can have the full replacement mechanism at runtime
due to the linking mechanism being different but it should at least
be possible during install time and relinking libraries.
I am not sure how to go about doing this in OpenBSD.

Is there any interest in doing this? I am hoping I can put something
together if people are interested in wanting OpenBLAS based libraries

Cheers,
Aisha

Having alternatives like this is similar to the case where a library has
flavours, which certainly adds complication - we mostly resist doing this
in ports, the exception is apr-util's ldap flavour and I wouldn't really
want to add more.

Is there likely to be a downside to switching outright to OpenBLAS?



Theoretically no, as it is supposed to be ABI compatible.
Reality is often disappointing.
The reference implementations focus on correctness while
OpenBLAS implementation focuses on speed.
So it is *possible* that there may be bugs in the OpenBLAS
based libraries (not saying that reference impl is perfect).

I agree that this will complicate things.
There are like 4 different providers of BLAS/LAPACK that I am
maintaining in Gentoo. I do not want to add all of them in
OpenBSD, OpenBLAS is by far the superior alternative to the
other 3.
The general method for development: write code using BLAS,
test with reference impl, then use in production with OpenBLAS.

One way in which I think this can be simplified:
Combine math/BLAS and math/LAPACK into one package - math/LAPACK
which can supply both libraries. Almost every package which needs
BLAS also needs LAPACK, so there is little configurability that
we lose here.
Then there can be two flavors math/LAPACK-reference and
math/LAPACK-openblas.
More fixes I want to add - add LAPACKE library as well.
For some reason, we don't seem to be building that one.

Best,
Aisha


RE: new: sysutils/mdf2iso

2020-10-28 Thread zeurkous
"Tracey Emery"  wrote:
> On Wed, Oct 28, 2020 at 04:06:43PM +0100, zeurk...@volny.cz wrote:
>> "Stuart Henderson"  wrote:
>> > On 2020/10/28 15:22, zeurk...@volny.cz wrote:
>> > > #?patch
>> > > #
>> > > # (There seems to be a bug in diff(1) that causes the mandatory (yet
>> > > # admittedly empty) pkg/DESCR file to be omitted. Just touch(1) it
>> > > # yourself...)
>> >
>> > a blank pkg/DESCR is not acceptable.
>>
>> Then write one :) Me's not good at writing blurbs, and me really feels
>> the COMMENT says it all.
>>
>
> Then write one? Really?
>
>[lecture about what is supposed to be {,un}acceptable]

So much hate over a friendly suggestion... *shakes head*

> Go away or try again with a different attitude. There's too much work to
> be done without filtering this crap.

Me's not with you. Me's sending what me has. If you don't like it: plonk
it.

Welcome to real life.

--zeurkous.

-- 
Friggin' Machines!



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/10/28 10:16:17

Modified files:
games/devilutionx: Makefile distinfo 
Removed files:
games/devilutionx/patches: patch-CMakeLists_txt 

Log message:
Update to devilutionx-1.1.0
Changelog: https://github.com/diasurgical/devilutionX/releases/tag/1.1.0
ok solene@



RE: new: sysutils/mdf2iso

2020-10-28 Thread zeurkous
> Sounds like you are done here. Again.

W/ever. Take me patches or leave them. Me's stopped caring.

Baai,

 --zeurkous.

-- 
Friggin' Machines!



Re: new: sysutils/mdf2iso

2020-10-28 Thread Tracey Emery
On Wed, Oct 28, 2020 at 04:06:43PM +0100, zeurk...@volny.cz wrote:
> "Stuart Henderson"  wrote:
> > On 2020/10/28 15:22, zeurk...@volny.cz wrote:
> > > #?patch
> > > #
> > > # (There seems to be a bug in diff(1) that causes the mandatory (yet
> > > # admittedly empty) pkg/DESCR file to be omitted. Just touch(1) it
> > > # yourself...)
> > 
> > a blank pkg/DESCR is not acceptable.
> 
> Then write one :) Me's not good at writing blurbs, and me really feels
> the COMMENT says it all.
> 

Then write one? Really?

Acceptable responses:

1. I'm not very good at writing descriptions. Can someone please help?
2. I'm sorry. I didn't realize the DESCR file is required in ports. I'll
take another stab at it.
3. Thanks for the feedback. Let me take another stab at it and I'll get
right back to you.

Unacceptable responses:

1. Being an asshole on this list, let alone directly to sthen.

Go away or try again with a different attitude. There's too much work to
be done without filtering this crap.

> > [...]
> > > diff -Nru /var/empty/Makefile ports/sysutils/mdf2iso/Makefile
> > 
> > send tarballs not diffs for new ports please.
> 
> Because you ask so nicely: attached.
> 
> --zeurkous.
> 
> -- 
> Friggin' Machines!



-- 

Tracey Emery



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/10/28 09:42:15

Modified files:
multimedia/gstreamer1: Makefile Makefile.inc 
multimedia/gstreamer1/core: Makefile distinfo 
multimedia/gstreamer1/core/patches: patch-meson_build 
multimedia/gstreamer1/core/pkg: PLIST 
multimedia/gstreamer1/plugins-bad: Makefile distinfo 
multimedia/gstreamer1/plugins-base: Makefile distinfo 
multimedia/gstreamer1/plugins-good: distinfo 
multimedia/gstreamer1/plugins-libav: distinfo 
multimedia/gstreamer1/plugins-ugly: distinfo 
multimedia/gstreamer1/py-gstreamer: Makefile distinfo 
multimedia/gstreamer1/py-gstreamer/pkg: PLIST 

Log message:
Update Gstreamer stack to 1.18.1.



Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Aisha Tammy

Hi,
I was wondering if it is possible to have multiple providers for a library
and then selecting one of them to be used, selecting which provider is
to be installed.
Case in point, we have the math/{lapack,blas} libraries, which are the
reference implementations and not optimized.
I am working on getting OpenBLAS built and ported, which can also
provide the libblas.so and liblapack.so (among other libraries).
It is ABI compatible with the latest BLAS/LAPACK standards so it should
ideally be a drop in replacement for the libraries for math/{lapack,blas}.
This way there is a significant runtime benefit for multiple science
libraries like numpy, scipy, eigen and a bunch of others.
This replacement mechanism is provided in Gentoo and Debian (and its
derivatives).
I don't think we can have the full replacement mechanism at runtime
due to the linking mechanism being different but it should at least
be possible during install time and relinking libraries.
I am not sure how to go about doing this in OpenBSD.

Is there any interest in doing this? I am hoping I can put something
together if people are interested in wanting OpenBLAS based libraries

Cheers,
Aisha


Re: new: sysutils/mdf2iso

2020-10-28 Thread Florian Obser
Sounds like you are done here. Again.



RE: new: sysutils/mdf2iso

2020-10-28 Thread zeurkous

"Stuart Henderson"  wrote:

On 2020/10/28 15:22, zeurk...@volny.cz wrote:

#?patch
#
# (There seems to be a bug in diff(1) that causes the mandatory (yet
# admittedly empty) pkg/DESCR file to be omitted. Just touch(1) it
# yourself...)


a blank pkg/DESCR is not acceptable.


Then write one :) Me's not good at writing blurbs, and me really feels
the COMMENT says it all.


[...]

diff -Nru /var/empty/Makefile ports/sysutils/mdf2iso/Makefile


send tarballs not diffs for new ports please.


Because you ask so nicely: attached.

--zeurkous.

--
Friggin' Machines!

mdf2iso.tar.gz
Description: mdf2iso.tar.gz


CVS: cvs.openbsd.org: ports

2020-10-28 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/10/28 09:04:05

Modified files:
net/kdsoap : Makefile distinfo 
net/kdsoap/patches: patch-CMakeLists_txt 
net/kdsoap/pkg : PLIST 

Log message:
Update kdsoap to 1.9.1



Re: new: sysutils/mdf2iso

2020-10-28 Thread Stuart Henderson
On 2020/10/28 15:22, zeurk...@volny.cz wrote:
> #?patch
> #
> # (There seems to be a bug in diff(1) that causes the mandatory (yet
> #  admittedly empty) pkg/DESCR file to be omitted. Just touch(1) it
> #  yourself...) 

a blank pkg/DESCR is not acceptable.

> # These patches add mdf2iso to the OpenBSD ports(7) tree.
> #
> #  --zeurkous, Wed Oct 28 14:15:48 UTC 2020.
> #
> diff -Nru /var/empty/Makefile ports/sysutils/mdf2iso/Makefile

send tarballs not diffs for new ports please.

> --- /var/empty/Makefile   Thu Jan  1 00:00:00 1970
> +++ ports/sysutils/mdf2iso/Makefile   Wed Oct 28 14:09:18 2020
> @@ -0,0 +1,24 @@
> +COMMENT= Alcohol 120% to ISO9660 image converter
> +
> +MASTER_SITES=https://gitlab.com/bsdforge/mdf2iso/-/archive/master/
> +DISTNAME=mdf2iso-master
> +EXTRACT_SUFX=.tar.gz
> +VER= 20201028
> +PKGNAME= mdf2iso-${VER}

this points directly at a checkout generated from master which is
a moving target. it needs to point at something that does not change
when a commit is made upstream (I know it has been inactive for some
years but we don't know what might happen later to break the port).
use a tag or a commit id.

> +
> +CATEGORIES=  sysutils
> +
> +# GPLv2
> +PERMIT_PACKAGE=  Yes
> +
> +WANTLIB= c
> +
> +CONFIGURE_STYLE=gnu
> +
> +post-extract:
> + cp ${FILESDIR}/Makefile-doc ${WRKSRC}
> +
> +post-install:
> + cd ${WRKSRC} && ${MAKE} -f Makefile-doc install

you are already in a Makefile there's no need for indirection to a
separate file. just put the targets directly in post-install the same
way every other port in the tree that uses post-install targets does it.

> +
> +.include 
> 
> diff -Nru /var/empty/distinfo ports/sysutils/mdf2iso/distinfo
> --- /var/empty/distinfo   Thu Jan  1 00:00:00 1970
> +++ ports/sysutils/mdf2iso/distinfo   Wed Oct 28 13:50:38 2020
> @@ -0,0 +1,2 @@
> +SHA256 (mdf2iso-master.tar.gz) = Wa6+azbVtgZa031VSP4n/gbs90OCFRy5ef7YH3dxFi8=
> +SIZE (mdf2iso-master.tar.gz) = 193384
> 
> diff -Nru /var/empty/files/Makefile-doc 
> ports/sysutils/mdf2iso/files/Makefile-doc
> --- /var/empty/files/Makefile-doc Thu Jan  1 00:00:00 1970
> +++ ports/sysutils/mdf2iso/files/Makefile-doc Wed Oct 28 13:57:33 2020
> @@ -0,0 +1,8 @@
> +#!/usr/bin/make -f
> +
> +all:
> +
> +install:
> + ${INSTALL} -d -m 755 ${PREFIX}/share/doc/mdf2iso/
> + ${INSTALL} -c -m 644 ChangeLog README.md gpl.txt\
> + ${PREFIX}/share/doc/mdf2iso/
> 
> diff -Nru /var/empty/pkg/PLIST ports/sysutils/mdf2iso/pkg/PLIST
> --- /var/empty/pkg/PLIST  Thu Jan  1 00:00:00 1970
> +++ ports/sysutils/mdf2iso/pkg/PLIST  Wed Oct 28 14:00:58 2020
> @@ -0,0 +1,6 @@
> +@comment $OpenBSD: PLIST,v$
> +@bin bin/mdf2iso
> +share/doc/mdf2iso/
> +share/doc/mdf2iso/ChangeLog
> +share/doc/mdf2iso/README.md
> +share/doc/mdf2iso/gpl.txt
> 



new: sysutils/mdf2iso

2020-10-28 Thread zeurkous
#?patch
#
# (There seems to be a bug in diff(1) that causes the mandatory (yet
#  admittedly empty) pkg/DESCR file to be omitted. Just touch(1) it
#  yourself...) 
# 
# These patches add mdf2iso to the OpenBSD ports(7) tree.
#
#  --zeurkous, Wed Oct 28 14:15:48 UTC 2020.
#
diff -Nru /var/empty/Makefile ports/sysutils/mdf2iso/Makefile
--- /var/empty/Makefile Thu Jan  1 00:00:00 1970
+++ ports/sysutils/mdf2iso/Makefile Wed Oct 28 14:09:18 2020
@@ -0,0 +1,24 @@
+COMMENT=   Alcohol 120% to ISO9660 image converter
+
+MASTER_SITES=  https://gitlab.com/bsdforge/mdf2iso/-/archive/master/
+DISTNAME=  mdf2iso-master
+EXTRACT_SUFX=  .tar.gz
+VER=   20201028
+PKGNAME=   mdf2iso-${VER}
+
+CATEGORIES=sysutils
+
+# GPLv2
+PERMIT_PACKAGE=Yes
+
+WANTLIB=   c
+
+CONFIGURE_STYLE=gnu
+
+post-extract:
+   cp ${FILESDIR}/Makefile-doc ${WRKSRC}
+
+post-install:
+   cd ${WRKSRC} && ${MAKE} -f Makefile-doc install
+
+.include 

diff -Nru /var/empty/distinfo ports/sysutils/mdf2iso/distinfo
--- /var/empty/distinfo Thu Jan  1 00:00:00 1970
+++ ports/sysutils/mdf2iso/distinfo Wed Oct 28 13:50:38 2020
@@ -0,0 +1,2 @@
+SHA256 (mdf2iso-master.tar.gz) = Wa6+azbVtgZa031VSP4n/gbs90OCFRy5ef7YH3dxFi8=
+SIZE (mdf2iso-master.tar.gz) = 193384

diff -Nru /var/empty/files/Makefile-doc 
ports/sysutils/mdf2iso/files/Makefile-doc
--- /var/empty/files/Makefile-doc   Thu Jan  1 00:00:00 1970
+++ ports/sysutils/mdf2iso/files/Makefile-doc   Wed Oct 28 13:57:33 2020
@@ -0,0 +1,8 @@
+#!/usr/bin/make -f
+
+all:
+
+install:
+   ${INSTALL} -d -m 755 ${PREFIX}/share/doc/mdf2iso/
+   ${INSTALL} -c -m 644 ChangeLog README.md gpl.txt\
+ ${PREFIX}/share/doc/mdf2iso/

diff -Nru /var/empty/pkg/PLIST ports/sysutils/mdf2iso/pkg/PLIST
--- /var/empty/pkg/PLISTThu Jan  1 00:00:00 1970
+++ ports/sysutils/mdf2iso/pkg/PLISTWed Oct 28 14:00:58 2020
@@ -0,0 +1,6 @@
+@comment $OpenBSD: PLIST,v$
+@bin bin/mdf2iso
+share/doc/mdf2iso/
+share/doc/mdf2iso/ChangeLog
+share/doc/mdf2iso/README.md
+share/doc/mdf2iso/gpl.txt



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/10/28 08:16:22

Modified files:
games/openrct2 : Makefile distinfo 
games/openrct2/patches: patch-CMakeLists_txt 
games/openrct2/pkg: PLIST 

Log message:
Update to openrct-0.3.1
Changelog: https://github.com/OpenRCT2/OpenRCT2/releases/tag/v0.3.1

ok daniel@, additional testing by Florian Viehweger



chromium window maximize

2020-10-28 Thread Mihai Popescu
New system install from scratch, cwm window manager, added extension uBlock
Origin to chromium and no other settings. IF you click on the tab bar of
the chromium window to maximize, a nice animation will start with the
window going repeatedly between maximum size and original size. It can be
reproduced numerous times.

One I use GTK+ and Use system title bars and borders options, this
behaviour is not present. Even if i go back to disable them, the flickering
cannot be reproduced.


OpenBSD 6.8-current (GENERIC.MP) #142: Tue Oct 27 15:23:47 MDT 2020
chromium-86.0.4240.111p0
cwm as window manager


new: audio/dgguspat

2020-10-28 Thread zeurkous
#?patch
#
# These patches add, to the OpenBSD ports(7) tree, the DooM GUS
# patches, as compiled by fraggle.
#
# (Me uses this as a backing for freepats, which is at the time of
#  writing not yet complete.)
#
# Cover your ears (j/k),
#
# --zeurkous, Wed Oct 28 12:52:11 UTC 2020.
#
diff -Nru /var/empty/Makefile ports/audio/dgguspat/Makefile
--- /var/empty/Makefile Thu Jan  1 00:00:00 1970
+++ ports/audio/dgguspat/Makefile   Wed Oct 28 12:15:02 2020
@@ -0,0 +1,24 @@
+COMMENT=   Gravis Ultrasound patches for TiMidity
+
+MASTER_SITES=  ftp.fu-berlin.de:/pub/pc/games/idgames/music/
+DISTNAME=  dgguspat
+VER=   20130304
+PKGNAME=   ${DISTNAME}-${VER}
+EXTRACT_SUFX=  .zip
+
+CATEGORIES=audio
+
+# unclear
+PERMIT_PACKAGE=No
+
+# zipbomb
+EXTRACT_CASES = *.zip) \
+   cd ${WRKDIST} && unzip -q ${FULLDISTDIR}/$$archive;;
+
+pre-extract:
+   mkdir ${WRKDIST}
+
+post-extract:
+   cp ${FILESDIR}/Makefile ${WRKSRC}
+
+.include 

diff -Nru /var/empty/distinfo ports/audio/dgguspat/distinfo
--- /var/empty/distinfo Thu Jan  1 00:00:00 1970
+++ ports/audio/dgguspat/distinfo   Wed Oct 28 11:45:23 2020
@@ -0,0 +1,2 @@
+SHA256 (dgguspat.zip) = Y+217pLAB1U9GHvO5v7XtciohtJdvAHaWr5czhT7AC8=
+SIZE (dgguspat.zip) = 5308541

diff -Nru /var/empty/files/Makefile ports/audio/dgguspat/files/Makefile
--- /var/empty/files/Makefile   Thu Jan  1 00:00:00 1970
+++ ports/audio/dgguspat/files/Makefile Wed Oct 28 11:57:56 2020
@@ -0,0 +1,11 @@
+#!/usr/bin/make -f
+
+all:
+
+install:
+   ${INSTALL} -d -m 755   ${PREFIX}/share/dgguspat/
+   ${INSTALL} -c -m 644 *.pat ${PREFIX}/share/dgguspat/
+   ${INSTALL} -d -m 755   ${PREFIX}/share/examples/dgguspat/
+   ${INSTALL} -c -m 644 *.cfg ${PREFIX}/share/examples/dgguspat/
+   ${INSTALL} -d -m 755   ${PREFIX}/share/doc/dgguspat/
+   ${INSTALL} -c -m 644 *.txt ${PREFIX}/share/doc/dgguspat/

diff -Nru /var/empty/pkg/PLIST ports/audio/dgguspat/pkg/PLIST
--- /var/empty/pkg/PLISTThu Jan  1 00:00:00 1970
+++ ports/audio/dgguspat/pkg/PLIST  Wed Oct 28 11:58:15 2020
@@ -0,0 +1,213 @@
+@comment $OpenBSD: PLIST,v$
+share/dgguspat/
+share/dgguspat/acbass.pat
+share/dgguspat/accordn.pat
+share/dgguspat/acguitar.pat
+share/dgguspat/acpiano.pat
+share/dgguspat/agogo.pat
+share/dgguspat/agogohi.pat
+share/dgguspat/agogolo.pat
+share/dgguspat/altosax.pat
+share/dgguspat/applause.pat
+share/dgguspat/atmosphr.pat
+share/dgguspat/aurora.pat
+share/dgguspat/bagpipes.pat
+share/dgguspat/banjo.pat
+share/dgguspat/barisax.pat
+share/dgguspat/basslead.pat
+share/dgguspat/bassoon.pat
+share/dgguspat/belltree.pat
+share/dgguspat/blank.pat
+share/dgguspat/bongohi.pat
+share/dgguspat/bongolo.pat
+share/dgguspat/bottle.pat
+share/dgguspat/bowglass.pat
+share/dgguspat/britepno.pat
+share/dgguspat/c550kc_1.pat
+share/dgguspat/c550sn10.pat
+share/dgguspat/c550sn_6.pat
+share/dgguspat/c550vibs.pat
+share/dgguspat/cabasa.pat
+share/dgguspat/calliope.pat
+share/dgguspat/carillon.pat
+share/dgguspat/castinet.pat
+share/dgguspat/celeste.pat
+share/dgguspat/cello.pat
+share/dgguspat/charang.pat
+share/dgguspat/chiflead.pat
+share/dgguspat/choir.pat
+share/dgguspat/church.pat
+share/dgguspat/claps.pat
+share/dgguspat/clarinet.pat
+share/dgguspat/clave.pat
+share/dgguspat/clavinet.pat
+share/dgguspat/cleangtr.pat
+share/dgguspat/concrtna.pat
+share/dgguspat/congahi1.pat
+share/dgguspat/congahi2.pat
+share/dgguspat/congalo.pat
+share/dgguspat/contraba.pat
+share/dgguspat/cowbell.pat
+share/dgguspat/crystal.pat
+share/dgguspat/cuica1.pat
+share/dgguspat/cuica2.pat
+share/dgguspat/cymbell.pat
+share/dgguspat/cymchina.pat
+share/dgguspat/cymcrsh1.pat
+share/dgguspat/cymcrsh2.pat
+share/dgguspat/cymride1.pat
+share/dgguspat/cymride2.pat
+share/dgguspat/cymsplsh.pat
+share/dgguspat/distgtr.pat
+share/dgguspat/doo.pat
+share/dgguspat/echovox.pat
+share/dgguspat/englhorn.pat
+share/dgguspat/epiano1.pat
+share/dgguspat/epiano2.pat
+share/dgguspat/fantasia.pat
+share/dgguspat/fiddle.pat
+share/dgguspat/flute.pat
+share/dgguspat/fngrbass.pat
+share/dgguspat/frenchrn.pat
+share/dgguspat/freshair.pat
+share/dgguspat/fretless.pat
+share/dgguspat/fx-blow.pat
+share/dgguspat/fx-fret.pat
+share/dgguspat/ghostie.pat
+share/dgguspat/glocken.pat
+share/dgguspat/gtrharm.pat
+share/dgguspat/guiro1.pat
+share/dgguspat/guiro2.pat
+share/dgguspat/halopad.pat
+share/dgguspat/harmonca.pat
+share/dgguspat/harp.pat
+share/dgguspat/helicptr.pat
+share/dgguspat/highq.pat
+share/dgguspat/hihatcl.pat
+share/dgguspat/hihatop.pat
+share/dgguspat/hihatpd.pat
+share/dgguspat/hitbrass.pat
+share/dgguspat/homeorg.pat
+share/dgguspat/honky.pat
+share/dgguspat/hrpschrd.pat
+share/dgguspat/jazzgtr.pat
+share/dgguspat/jingles.pat
+share/dgguspat/jungle.pat
+share/dgguspat/kalimba.pat
+share/dgguspat/kick1.pat
+share/dgguspat/kick2.pat
+share/dgguspat/koto.pat
+share/dgguspat/lead5th.pat
+share/dgguspat/maracas.pat
+share/dgguspat/marcato.pat
+share/dgguspat/marimba.pat

CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 06:12:46

Modified files:
net/rrdtool: Makefile 
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 
net/py-rrdtool : Makefile 
net/py-rrdtool/pkg: PLIST 
Removed files:
net/rrdtool/pkg: DESCR-python PLIST-python 

Log message:
enable py2 for py-rrdtool as well, use it to replace net/rrdtool,-python
(which is an older version of the same thing). add an upgrade path via
quirks/@pkgpath.



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 06:13:06

Modified files:
databases/py-whisper: Makefile 

Log message:
switch dep to py-rrdtool



Re: [UPDATE] py-whisper and py-carbon to 1.1.7 + py3

2020-10-28 Thread Stuart Henderson
On 2020/10/28 08:41, Martin Reindl wrote:
> Am 27.10.20 um 22:08 schrieb Stuart Henderson:
> 
> > This can't work, it needs a python 3 version of the rrdtool bindings,
> > this is in the separate pypi project "rrdtool". As things stand
> > rrd2whisper will be broken.
> > 
> > Port for that attached. OK to import? I have tested it by following
> > "usage" on https://github.com/commx/python-rrdtool and checking
> > produced rrd with "rrdtool dump". If that goes in, you can then change
> > this to RUN_DEPENDS=net/py-rrdtool${MODPY_FLAVOR} and rrd2whisper.py
> > should work again.
> > 
> > I would put it in databases/, but rrdtool itself is already in net/
> > (which I consider the wrong subdirectory), so I'll just follow along with
> > that otherwise things get even more confusing :)
> 
> Thanks, I ran the same test on arm64. OK to import.
> 

I've imported it and added a py2 version so I could move across from the
older code in rrdtool main distfile. I've switched the existing py-whisper
to use it, here's a refreshed diff for your py-whisper update which is OK
with me.

Other than the /usr/local/storage dirs, your py-carbon update and the
associated quirks/Makefile changes are also OK with me.

Index: Makefile
===
RCS file: /cvs/ports/databases/py-whisper/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile28 Oct 2020 12:13:06 -  1.11
+++ Makefile28 Oct 2020 12:17:09 -
@@ -1,23 +1,27 @@
 # $OpenBSD: Makefile,v 1.11 2020/10/28 12:13:06 sthen Exp $
 
-COMMENT=   fixed size round-robin style database
+COMMENT =  fixed size round-robin style database
 
-MODPY_EGG_VERSION= 1.0.2
-REVISION=  0
+MODPY_EGG_VERSION= 1.1.7
 
-DISTNAME=  whisper-${MODPY_EGG_VERSION}
-PKGNAME=   py-${DISTNAME}
-CATEGORIES=databases
+DISTNAME = whisper-${MODPY_EGG_VERSION}
+PKGNAME =  py-${DISTNAME}
+CATEGORIES =   databases
 
 # Apache
-PERMIT_PACKAGE=Yes
+PERMIT_PACKAGE =   Yes
 
-MODULES=   lang/python
+MODULES =  lang/python
 
 MODPY_PI = Yes
+MODPY_SETUPTOOLS = Yes
 
-RUN_DEPENDS=   net/py-rrdtool${MODPY_FLAVOR}
+FLAVORS =  python3
+FLAVOR =   python3
 
-NO_TEST =  Yes
+RUN_DEPENDS =  net/py-rrdtool${MODPY_FLAVOR}
+
+TEST_DEPENDS = devel/py-mock${MODPY_FLAVOR} \
+   devel/py-six${MODPY_FLAVOR}
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/databases/py-whisper/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo14 Nov 2017 15:59:27 -  1.6
+++ distinfo28 Oct 2020 12:17:09 -
@@ -1,2 +1,2 @@
-SHA256 (whisper-1.0.2.tar.gz) = Q9v7R9wUHBdKANjVYdsByfCZp18imTjJJ9fEQN2IK+w=
-SIZE (whisper-1.0.2.tar.gz) = 24064
+SHA256 (whisper-1.1.7.tar.gz) = huAeZudLW/6gbFNvCKpxuwfN3vrKbWqDUuKabt7gcSE=
+SIZE (whisper-1.1.7.tar.gz) = 37376
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/py-whisper/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST   8 Jul 2017 16:09:17 -   1.4
+++ pkg/PLIST   28 Oct 2020 12:17:09 -
@@ -1,4 +1,6 @@
 @comment $OpenBSD: PLIST,v 1.4 2017/07/08 16:09:17 jasper Exp $
+@conflict py-whisper-*
+@pkgpath databases/py-whisper
 bin/find-corrupt-whisper-files.py
 bin/rrd2whisper.py
 bin/update-storage-times.py
@@ -15,6 +17,12 @@ bin/whisper-resize.py
 bin/whisper-set-aggregation-method.py
 bin/whisper-set-xfilesfactor.py
 bin/whisper-update.py
-lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}whisper.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
+lib/python${MODPY_VERSION}/site-packages/whisper-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/whisper.py
-lib/python${MODPY_VERSION}/site-packages/whisper.pyc



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 05:59:54

Modified files:
archivers/pecl-lzf: Makefile distinfo 
archivers/pecl-lzf/pkg: PLIST 

Log message:
update to pecl-LZF 1.6.8, from maintainer Johan Huldtgren



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 05:57:12

Modified files:
net: Makefile 

Log message:
+py-rrdtool. sort directory names while there.



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/10/28 05:55:52

Log message:
import ports/net/py-rrdtool, ok martin@

These Python bindings to rrdtool are based on the code of the original
Python 2 bindings module for rrdtool by Hye-Shik Chang which are shipped
with the RRDtool distribution. This project is maintained separately to
provide a more pythonic way to install those bindings via PyPI and
include support for Python 3.

Status:

Vendor Tag: sthen
Release Tags:   sthen_20201028

N ports/net/py-rrdtool/Makefile
N ports/net/py-rrdtool/distinfo
N ports/net/py-rrdtool/pkg/DESCR
N ports/net/py-rrdtool/pkg/PLIST

No conflicts created by this import



Re: Allowing multiple providers of libraries - BLAS/LAPACK

2020-10-28 Thread Stuart Henderson
+cc some people who might be interested to make sure they see this :)

On 2020/10/28 07:32, Aisha Tammy wrote:
> Hi,
> I was wondering if it is possible to have multiple providers for a library
> and then selecting one of them to be used, selecting which provider is
> to be installed.
> Case in point, we have the math/{lapack,blas} libraries, which are the
> reference implementations and not optimized.
> I am working on getting OpenBLAS built and ported, which can also
> provide the libblas.so and liblapack.so (among other libraries).
> It is ABI compatible with the latest BLAS/LAPACK standards so it should
> ideally be a drop in replacement for the libraries for math/{lapack,blas}.
> This way there is a significant runtime benefit for multiple science
> libraries like numpy, scipy, eigen and a bunch of others.
> This replacement mechanism is provided in Gentoo and Debian (and its
> derivatives).
> I don't think we can have the full replacement mechanism at runtime
> due to the linking mechanism being different but it should at least
> be possible during install time and relinking libraries.
> I am not sure how to go about doing this in OpenBSD.
> 
> Is there any interest in doing this? I am hoping I can put something
> together if people are interested in wanting OpenBLAS based libraries
> 
> Cheers,
> Aisha

Having alternatives like this is similar to the case where a library has
flavours, which certainly adds complication - we mostly resist doing this
in ports, the exception is apr-util's ldap flavour and I wouldn't really
want to add more.

Is there likely to be a downside to switching outright to OpenBLAS?



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/10/28 05:45:32

Modified files:
sysutils/krename: Makefile distinfo 
sysutils/krename/pkg: PLIST 
Removed files:
sysutils/krename/patches: patch-CMakeLists_txt 
  patch-config-krename_h_cmake 
  patch-src_CMakeLists_txt 
  patch-src_exiv2plugin_cpp 

Log message:
Update krename to 5.0.1



aarch64 bulk build report

2020-10-28 Thread phessler
bulk build on arm64.ports.openbsd.org
started on  Sat Oct 24 06:58:34 MDT 2020
finished at Wed Oct 28 05:31:08 MDT 2020
lasted 3D22h32m
done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #863: Fri Oct 23 
15:11:47 MDT 2020

built packages:10863
Oct 24:4127
Oct 25:209
Oct 26:509
Oct 27:2757
Oct 28:3260


critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2020-10-24/summary.log

build failures: 18
http://build-failures.rhaalovely.net/aarch64/2020-10-24/converters/wv2.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/devel/sqlc.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/editors/calligra.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/editors/xwpe.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/emulators/vice.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/games/shockolate.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/lang/pfe.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/net/kdsoap.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/security/age.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/sysutils/docker-cli.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/sysutils/facette.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/sysutils/nomad.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/sysutils/rclone.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/sysutils/telegraf.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/sysutils/terragrunt.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/www/chromium.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/x11/e17/elementary.log
http://build-failures.rhaalovely.net/aarch64/2020-10-24/x11/qt5/qtwebkit.log

recurrent failures
 failures/converters/wv2.log
 failures/editors/calligra.log
 failures/editors/xwpe.log
 failures/emulators/vice.log
 failures/games/shockolate.log
 failures/lang/pfe.log
 failures/sysutils/docker-cli.log
 failures/sysutils/nomad.log
 failures/sysutils/rclone.log
 failures/sysutils/telegraf.log
 failures/sysutils/terragrunt.log
 failures/x11/e17/elementary.log
 failures/x11/qt5/qtwebkit.log
new failures
+++ ls-failures Wed Oct 28 05:31:34 2020
+failures/devel/sqlc.log
+failures/net/kdsoap.log
+failures/security/age.log
+failures/sysutils/facette.log
+failures/www/chromium.log
resolved failures
--- ../old/aarch64/last//ls-failuresFri Oct 23 01:59:29 2020
-failures/geo/pdal.log
-failures/security/suricata.log



new: archivers/mscompress

2020-10-28 Thread zeurkous
#?patch
# 
# These patches add ms{compress,expand}(1) to the OpenBSD ports(7) tree.
#
# --zeurkous, Wed Oct 28 10:13:23 UTC 2020.
#
diff -Nru /var/empty/Makefile ports/archivers/mscompress/Makefile
--- /var/empty/Makefile Thu Jan  1 00:00:00 1970
+++ ports/archivers/mscompress/Makefile Wed Oct 28 10:03:38 2020
@@ -0,0 +1,17 @@
+COMMENT=   re-implementation of Microsoft {COMPRESS,EXPAND}.EXE
+
+MASTER_SITES=  ftp.penguin.cz:/pub/users/mhi/mscompress/
+DISTNAME=  mscompress-0.3
+EXTRACT_SUFX=  .tar.bz2
+
+CATEGORIES=archivers
+
+# GPLv2
+PERMIT_PACKAGE=Yes
+
+WANTLIB=   c
+
+CONFIGURE_STYLE=gnu
+TEST_TARGET=   test
+
+.include 

diff -Nru /var/empty/distinfo ports/archivers/mscompress/distinfo
--- /var/empty/distinfo Thu Jan  1 00:00:00 1970
+++ ports/archivers/mscompress/distinfo Wed Oct 28 09:38:14 2020
@@ -0,0 +1,2 @@
+SHA256 (mscompress-0.3.tar.bz2) = zcO/ZoZdqXANX1KgZgLf4/mmUQvFO5c0KVex1x8Ca3c=
+SIZE (mscompress-0.3.tar.bz2) = 40989

diff -Nru /var/empty/patches/patch-Makefile.in 
ports/archivers/mscompress/patches/patch-Makefile.in
--- /var/empty/patches/patch-Makefile.inThu Jan  1 00:00:00 1970
+++ ports/archivers/mscompress/patches/patch-Makefile.inWed Oct 28 
10:00:19 2020
@@ -0,0 +1,27 @@
+--- ..v/0.3/Makefile.inSat Apr 15 12:50:28 2000
 Makefile.inWed Oct 28 10:00:13 2020
+@@ -22,14 +22,16 @@
+   cd test; make test
+ 
+ install:  all
+-  mkdir -p $(BUILDROOT)/usr/bin
+-  mkdir -p $(BUILDROOT)/usr/man/man1
+-  @INSTALL@ -c -s -m 0755 -o root -g root mscompress $(BUILDROOT)/usr/bin
+-  @INSTALL@ -c -s -m 0755 -o root -g root msexpand $(BUILDROOT)/usr/bin
+-  @INSTALL@ -c -m 0644 -o root -g root msexpand.1 
$(BUILDROOT)/usr/man/man1
+-  @INSTALL@ -c -m 0644 -o root -g root mscompress.1 
$(BUILDROOT)/usr/man/man1
+-  @echo installing entry to /usr/lib/magic ...
+-  @/bin/sh ./magic.add $(BUILDROOT)
++  @INSTALL@ -d -m 755 $(PREFIX)/bin
++  @INSTALL@ -d -m 755 $(PREFIX)/man/man1
++  @INSTALL@ -d -m 755 $(PREFIX)/share/doc/mscompress/
++  @INSTALL@ -c -m 0755 mscompress $(PREFIX)/bin
++  @INSTALL@ -c -m 0755 msexpand $(PREFIX)/bin
++  @INSTALL@ -c -m 0644 msexpand.1 $(PREFIX)/man/man1
++  @INSTALL@ -c -m 0644 mscompress.1 $(PREFIX)/man/man1
++  @INSTALL@ -c -m 644 ChangeLog COPYING README TODO format.txt 
$(PREFIX)/share/doc/mscompress/
++# @echo installing entry to /usr/lib/magic ...
++# @/bin/sh ./magic.add $(BUILDROOT)
+ 
+ binary: install
+   @echo Creating binary .tar.bz2 in directory $(OUTDIR)/

diff -Nru /var/empty/pkg/DESCR ports/archivers/mscompress/pkg/DESCR
--- /var/empty/pkg/DESCRThu Jan  1 00:00:00 1970
+++ ports/archivers/mscompress/pkg/DESCRWed Oct 28 09:59:38 2020
@@ -0,0 +1 @@
+re-implementation of Microsoft {COMPRESS,EXPAND}.EXE

diff -Nru /var/empty/pkg/PLIST ports/archivers/mscompress/pkg/PLIST
--- /var/empty/pkg/PLISTThu Jan  1 00:00:00 1970
+++ ports/archivers/mscompress/pkg/PLISTWed Oct 28 10:00:26 2020
@@ -0,0 +1,12 @@
+@comment $OpenBSD: PLIST,v$
+@bin bin/mscompress
+@bin bin/msexpand
+@man man/man1/mscompress.1
+@man man/man1/msexpand.1
+share/doc/mscompress/
+share/doc/mscompress/COPYING
+share/doc/mscompress/ChangeLog
+share/doc/mscompress/README
+share/doc/mscompress/TODO
+share/doc/mscompress/format.txt
+share/doc/pkg-readmes/${PKGSTEM}

diff -Nru /var/empty/pkg/README ports/archivers/mscompress/pkg/README
--- /var/empty/pkg/README   Thu Jan  1 00:00:00 1970
+++ ports/archivers/mscompress/pkg/README   Wed Oct 28 09:35:41 2020
@@ -0,0 +1,2 @@
+magic(5) additions not propagated; instead: patch submitted to
+t...@openbsd.org.



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Landry Breuil
CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/10/28 05:06:42

Modified files:
www/py-flask-cors: Makefile distinfo 

Log message:
Update to py-flask-cors 3.0.9.

Fixes CVE-2020-25032.
>From Wen Heping (thanks!)



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Landry Breuil
CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/10/28 05:02:04

Modified files:
www/mozilla-firefox: Tag: OPENBSD_6_8 Makefile 

Log message:
MFC: Bugfix update to firefox 82.0.2.

See https://www.mozilla.org/en-US/firefox/82.0.2/releasenotes/
Fixes websocket regressions (cf 
https://bugzilla.mozilla.org/show_bug.cgi?id=1673340)



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Landry Breuil
CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/10/28 05:01:40

Modified files:
www/mozilla-firefox: Makefile distinfo 
www/firefox-i18n: Makefile.inc distinfo 

Log message:
Bugfix update to firefox 82.0.2.

See https://www.mozilla.org/en-US/firefox/82.0.2/releasenotes/
Fixes websocket regressions (cf 
https://bugzilla.mozilla.org/show_bug.cgi?id=1673340)



回复: [Security Update] www/py-flask-cors : Update to 3.0.9

2020-10-28 Thread wen heping
ping ...

发件人: owner-po...@openbsd.org  代表 wen heping 

发送时间: 2020年10月22日 8:23
收件人: ports@openbsd.org 
主题: [Security Update] www/py-flask-cors : Update to 3.0.9

Hi, ports@:

   Here is a simple patch for www/py-flask-cors to update to 3.0.9,
it is a security update which fix CVE-2020-25032.
   It build well and pass all tests on amd64-current system.
   Only one port depends on it : geo/pygeoapi ,it build and runwell
with this patch, no test defined.


Cheers !
wen


UPDATE: libass 0.15.0 - CVE-2020-26682

2020-10-28 Thread Brad Smith
Here is an update to libass 0.15.0.

CVE-2020-26682

In libass 0.14.0, the `ass_outline_construct`'s call to `outline_stroke` causes 
a signed integer overflow.


Index: Makefile
===
RCS file: /home/cvs/ports/multimedia/libass/Makefile,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile
--- Makefile21 Aug 2019 07:35:17 -  1.24
+++ Makefile27 Oct 2020 23:07:02 -
@@ -2,14 +2,13 @@
 
 COMMENT=   portable ASS/SSA subtitle renderer
 
-VER=   0.14.0
+VER=   0.15.0
 DISTNAME=  libass-${VER}
-REVISION=  0
 CATEGORIES=multimedia devel
 MASTER_SITES=  https://github.com/libass/libass/releases/download/${VER}/
 EXTRACT_SUFX=  .tar.xz
 
-SHARED_LIBS=   ass 3.0
+SHARED_LIBS=   ass 3.1
 
 HOMEPAGE=  https://github.com/libass/libass
 
@@ -18,7 +17,7 @@ MAINTAINER=   Brad Smith 

CVS: cvs.openbsd.org: ports

2020-10-28 Thread Rafael Sadowski
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2020/10/28 01:47:40

Modified files:
devel/jenkins/devel: Makefile distinfo 

Log message:
Update jenkins-devel to 2.264



Re: [UPDATE] py-whisper and py-carbon to 1.1.7 + py3

2020-10-28 Thread Martin Reindl
Am 27.10.20 um 22:08 schrieb Stuart Henderson:

> This can't work, it needs a python 3 version of the rrdtool bindings,
> this is in the separate pypi project "rrdtool". As things stand
> rrd2whisper will be broken.
> 
> Port for that attached. OK to import? I have tested it by following
> "usage" on https://github.com/commx/python-rrdtool and checking
> produced rrd with "rrdtool dump". If that goes in, you can then change
> this to RUN_DEPENDS=net/py-rrdtool${MODPY_FLAVOR} and rrd2whisper.py
> should work again.
> 
> I would put it in databases/, but rrdtool itself is already in net/
> (which I consider the wrong subdirectory), so I'll just follow along with
> that otherwise things get even more confusing :)

Thanks, I ran the same test on arm64. OK to import.



CVS: cvs.openbsd.org: ports

2020-10-28 Thread Bjorn Ketelaars
CVSROOT:/cvs
Module name:ports
Changes by: b...@cvs.openbsd.org2020/10/28 00:28:37

Modified files:
sysutils/rclone: Makefile distinfo 

Log message:
Update to rclone-1.53.2

Maintenance release. Changes:
https://github.com/rclone/rclone/blob/v1.53.2/docs/content/changelog.md