maintainer update: www/hugo

2020-03-09 Thread Paco Esteban 
Hi ports@,

This is a trivial diff to update www/hugo to the lastest version.  This
new release includes:

Enhancements

Other
* Doument the server config 63393230 @bep
* Support unComparable args of uniq/complement/in 8279d2e2 @satotake
  #6105
* Add HTTP header support for the dev server 10831444 @bep #7031
* Add include and exclude support for remote 51e178a6 @davidejones

Fixes

Templates
* Fix error with unicode in file paths c4fa2f07 @sams96 #6996

Other
* Fix ambigous error on site.GetPage 6cceef65 @bep #7016
* Fix handling of HTML files without front matter ffcb4aeb @bep
  #7030#7028#6789


ok ?


Index: Makefile
===
RCS file: /home/cvs/ports/www/hugo/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile5 Mar 2020 06:16:25 -   1.11
+++ Makefile10 Mar 2020 06:37:06 -
@@ -3,7 +3,7 @@ ONLY_FOR_ARCHS =${GO_ARCHS}
 
 COMMENT =  fast and flexible static site generator
 
-DISTNAME = hugo-0.66.0
+DISTNAME = hugo-0.67.0
 
 CATEGORIES =   www
 
Index: distinfo
===
RCS file: /home/cvs/ports/www/hugo/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- distinfo5 Mar 2020 06:16:25 -   1.9
+++ distinfo10 Mar 2020 06:37:29 -
@@ -1,2 +1,2 @@
-SHA256 (hugo-0.66.0.tar.gz) = vz75fCppiWmo/kqWRk8ANpNK1Bz3Q4pxNyZaaLC9e/8=
-SIZE (hugo-0.66.0.tar.gz) = 37193991
+SHA256 (hugo-0.67.0.tar.gz) = NQg750Jnd/sIGQ/aBMSjs1riolvcFRtdSBSPtQDHxDA=
+SIZE (hugo-0.67.0.tar.gz) = 37845670

-- 
Paco Esteban.
0x5818130B8A6DBC03

Re: editors/sigil : open file dialog make it hang

2020-03-09 Thread Landry Breuil 
On Mon, Mar 09, 2020 at 08:34:45PM +, Stuart Henderson wrote:
> On 2020/03/09 20:21, Solene Rapenne wrote:
> > The software editors/sigil hangs when I use File>Open file dialog, this
> > looks like the exact same issue I reported in calibre
> > https://marc.info/?l=openbsd-ports&m=158201980905357&w=2
> > 
> > Using "Save as" file dialog works as expected though.
> > 
> > I have no crash output because it hangs, only this messages from Gtk
> > 
> > I'm using OpenBSD -current amd64, updated with today's snapshot and 
> > packages up
> > to date.
> > 
> > solene@t480 ~ $ sigil
> > Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> > '/tmp/runtime-solene'
> > Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> > '/tmp/runtime-solene'
> > 
> > (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: Error building template class 
> > 'GtkDialog' for an instance of type 'GtkDialog': .:2:367 Invalid object 
> > type 'GtkHeaderBar'
> > (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
> > _gtk_container_get_border_width_set: assertion 'GTK_IS_CONTAINER 
> > (container)' failed
> > (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
> > gtk_container_set_border_width: assertion 'GTK_IS_CONTAINER (container)' 
> > failed
> > (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
> > _gtk_container_set_border_width_set: assertion 'GTK_IS_CONTAINER 
> > (container)' failed
> 
> hmm, why is this Qt software using Gtk?

Hah, very good, someone else seeing this... i'm seeing the exact same
issue with QGIS (had reported it upstream in
https://issues.qgis.org/issues/17825, thinking it was a qgis issue), and
similar things were reported with Qt5 apps on the list
(https://marc.info/?l=openbsd-ports&m=156398700316410&w=2 ,
https://marc.info/?l=openbsd-ports&m=155105154015694&w=2).

>From that point, the only option is to kill the app, as even if you can
close the dialog, the Qt5 window is unresponsive.

In that case it uses Gtk3 because i *think* it has something to do with desktop
integration wrt themes, where Qt apps try to use a 'Gtk3' platformtheme for
proper integration with gtk-based desktops (i use xfce everywhere)

at the time i ported qt5ct to be able to change the theme used by qt5
apps to prevent it to default to the Gtk3 theme but that's only sliding
the issue under the carpet and not actually fixing anything.

I started digging into qtbase and got a local debug patch (below) but
that didnt help understanding the issue.. more eyes on this would definitely be
welcome as this has been bugging me for 2+ yrs :)

Landry

[07:22] c64:/usr/ports/x11/qt5/ $cat 
qtbase/patches/patch-src_plugins_platformthemes_gtk3_qgtk3dialoghelpers_cpp
$OpenBSD$

Index: src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
--- src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp.orig
+++ src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
@@ -238,6 +238,9 @@ void QGtk3ColorDialogHelper::applyOptions()
 
 QGtk3FileDialogHelper::QGtk3FileDialogHelper()
 {
+qDebug("Registering headerbar type");
+g_type_ensure(GTK_TYPE_HEADER_BAR);
+qDebug("Creating gtk3 file chooser");
 d.reset(new QGtk3Dialog(gtk_file_chooser_dialog_new("", 0,
 
GTK_FILE_CHOOSER_ACTION_OPEN,
 
qUtf8Printable(QGtk3Theme::defaultStandardButtonText(QPlatformDialogHelper::Cancel)),
 GTK_RESPONSE_CANCEL,

回复: [NEW] astro/p5-Astro-satpass

2020-03-09 Thread wen heping 
Thank your reply.
I shall  create ports for Astro::App::Satpass2 and Astro::SpaceTrack and submit
it in one shot.

wen

发件人: Stuart Henderson 
发送时间: 2020年3月10日 0:50
收件人: wen heping ; ports@openbsd.org 

主题: Re: [NEW] astro/p5-Astro-satpass

On 2020/02/15 12:51, Andrew Hewus Fresh wrote:
> On Mon, Jan 27, 2020 at 09:31:41AM +, wen heping wrote:
> > Hi, ports@:
> >
> >   Here is a patch to cretae new port: astro/p5-Astro-satpass.
> >   It build well and pass all tests on amd64-current system.
> >
> > Cheers !
> > wen
>
> It seems useful to add `CONFIGURE_ARGS = -y` in order to install the
> "satpass" utility, which will require a regen of the PLIST.
>
> Unfortunately I couldn't get geocoding to work as we don't have
> Geo::Coder::OSM in the tree, and once I set lat/lon manually it then
> said "Astro::SpaceTrack must be installed if you wish to use command
> st", so maybe it's not that useful.
>
> I'm unsure how common the JSON format files are, but it wouldn't be hard
> to add `RUN_DEPENDS += converters/p5-JSON` so it Just Works.
>
> OK afresh1@ in any case, it seems to work, with our without
> addressing these ideas
>

Since the satpass script is deprecated and upstream has plans to remove it
completely, maybe it's better to skip it and port Astro::App::Satpass2
along with at least Astro::SpaceTrack (it is much less useful without that..)

It is of a lot more interest to present the whole collection of ports that
can be used to do something immediately useful, rather than just the calculation
module which is obviously meant to work with a number of other modules.

update: math/libcerf and math/gnuplot

2020-03-09 Thread Yozo TODA 
(resending this from gmail, because my ISP's mailserver was blocked
via UCEProtect Level1. I hope this will go through now...)

Dear maintainer Paul Irofti, (Cc: ports@openbsd.org)
here attached the patch to update libcerf and gnuplot;
please check and commit this if it's OK?

  - updating libcerf 1.11p0 to 1.13
  - the upstream site looks renewed (apps.jcns... to jugit...)
  - I compiled 1.13 successfully with clang, hence removing COMPILER line.
but I'm not sure it's OK for non-clang architectures...
  - just adding REVISION=0 to gnuplot to get along with libcerf update,
and verify that this libcerf update works well.
all demo work.


In my environment (following -current, amd64)
gcc-8 cannot compile for some weeks.
(some error like "compiler internal error" in the middle of build.)
So, I cannot rebuild math/maxima. Looking at the build log and Makefile,
maxima depends on gnuplot depending on libcerf depending on gcc-8.
That's why I examined libcerf port if it works with clang...

-- yozo.
Index: libcerf/Makefile
===
RCS file: /cvs/ports/math/libcerf/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- libcerf/Makefile12 Jul 2019 20:47:42 -  1.5
+++ libcerf/Makefile8 Mar 2020 07:08:56 -
@@ -2,16 +2,16 @@
 
 COMMENT =  implementation of complex error functions
 
-V =1.11
-DISTNAME = libcerf-${V}
+V =1.13
+DISTNAME = libcerf-v${V}
+PKGNAME =  libcerf-${V}
 EXTRACT_SUFX = .tgz
 CATEGORIES =   math
-MASTER_SITES = http://apps.jcns.fz-juelich.de/src/libcerf/
-REVISION = 0
+MASTER_SITES = https://jugit.fz-juelich.de/mlz/libcerf/-/archive/v${V}/
 
-SHARED_LIBS +=  cerf   2.0 # 1.10
+SHARED_LIBS +=  cerf   3.0 # 1.13
 
-HOMEPAGE = http://apps.jcns.fz-juelich.de/doku/sc/libcerf
+HOMEPAGE = https://jugit.fz-juelich.de/mlz/libcerf/
 
 MAINTAINER =   Paul Irofti 
 
@@ -21,7 +21,5 @@ PERMIT_PACKAGE =  Yes
 WANTLIB += c m ${COMPILER_LIBCXX}
 
 MODULES =  devel/cmake
-
-COMPILER = ports-gcc   # imaginary constants are a GNU extension
 
 .include 
Index: libcerf/distinfo
===
RCS file: /cvs/ports/math/libcerf/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- libcerf/distinfo29 Dec 2018 07:48:36 -  1.3
+++ libcerf/distinfo8 Mar 2020 07:08:56 -
@@ -1,2 +1,2 @@
-SHA256 (libcerf-1.11.tgz) = cBAcrEoNeGMyLU0Gz5XFB6nP1k/JmtGzGoQlIEz9lnI=
-SIZE (libcerf-1.11.tgz) = 60066
+SHA256 (libcerf-v1.13.tgz) = 5Gmfga+Diu9bPncgn+yOmCCk9JLVmPtaBwgAhUl2owU=
+SIZE (libcerf-v1.13.tgz) = 60732
Index: libcerf/patches/patch-man_CMakeLists_txt
===
RCS file: /cvs/ports/math/libcerf/patches/patch-man_CMakeLists_txt,v
retrieving revision 1.1
diff -u -p -r1.1 patch-man_CMakeLists_txt
--- libcerf/patches/patch-man_CMakeLists_txt28 Dec 2018 16:28:44 -  
1.1
+++ libcerf/patches/patch-man_CMakeLists_txt8 Mar 2020 07:08:56 -
@@ -1,4 +1,4 @@
-$OpenBSD: patch-man_CMakeLists_txt,v 1.1 2018/12/28 16:28:44 pirofti Exp $
+$OpenBSD$
 
 Manual pages should go under ${PREFIX}/man/ rather than under
 ${PREFIX}/share/man/.
Index: gnuplot/Makefile
===
RCS file: /cvs/ports/math/gnuplot/Makefile,v
retrieving revision 1.75
diff -u -p -r1.75 Makefile
--- gnuplot/Makefile8 Nov 2019 23:29:56 -   1.75
+++ gnuplot/Makefile8 Mar 2020 07:08:56 -
@@ -4,6 +4,7 @@ COMMENT =   command-driven interactive fun
 
 V =5.2
 PATCHLEVEL =   7
+REVISION = 0
 DISTNAME = gnuplot-${V}.${PATCHLEVEL}
 CATEGORIES =   math graphics
 MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=gnuplot/}

UPDATE: games/devilutionx 1.0.0 => 1.0.1

2020-03-09 Thread Brian Callahan 

Hi ports --

Straightforward update to DevilutionX.
Changelog is here: 
https://github.com/diasurgical/devilutionX/releases/tag/1.0.1


Big endian testing would be very much appreciated.

~Brian
Index: Makefile
===
RCS file: /cvs/ports/games/devilutionx/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile	1 Jan 2020 18:52:50 -	1.5
+++ Makefile	10 Mar 2020 01:06:32 -
@@ -6,7 +6,7 @@ CATEGORIES =	games x11
 
 GH_ACCOUNT =	diasurgical
 GH_PROJECT =	devilutionX
-GH_TAGNAME =	1.0.0
+GH_TAGNAME =	1.0.1
 
 MAINTAINER =	Brian Callahan 
 
Index: distinfo
===
RCS file: /cvs/ports/games/devilutionx/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo	1 Jan 2020 18:52:50 -	1.4
+++ distinfo	10 Mar 2020 01:06:32 -
@@ -1,2 +1,2 @@
-SHA256 (devilutionX-1.0.0.tar.gz) = +vsLrJNbu+6OJh1/vS1Op2m4i7x4uhr/73QGSizHd3k=
-SIZE (devilutionX-1.0.0.tar.gz) = 1798349
+SHA256 (devilutionX-1.0.1.tar.gz) = FlVk/v2/0LT790aI6hvrHYEesdjiALn6rVtwrirHVk4=
+SIZE (devilutionX-1.0.1.tar.gz) = 2005920
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/games/devilutionx/patches/patch-CMakeLists_txt,v
retrieving revision 1.4
diff -u -p -r1.4 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt	1 Jan 2020 18:52:50 -	1.4
+++ patches/patch-CMakeLists_txt	10 Mar 2020 01:06:32 -
@@ -5,9 +5,9 @@ Don't do git here.
 Index: CMakeLists.txt
 --- CMakeLists.txt.orig
 +++ CMakeLists.txt
-@@ -19,14 +19,8 @@ option(NIGHTLY_BUILD "Enable options for nightly build
- option(USE_SDL1 "Use SDL1.2 instead of SDL2" OFF)
- option(NONET "Disable network" OFF)
+@@ -40,14 +40,8 @@ if(NIGHTLY_BUILD)
+   set(FASTER OFF)
+ endif()
  
 -include(CMake/git.cmake)
 -get_git_tag(GIT_TAG)
@@ -17,7 +17,7 @@ Index: CMakeLists.txt
 -
  project(DevilutionX
 -  VERSION ${GIT_TAG}
-+  VERSION 1.0.0
++  VERSION 1.0.1
LANGUAGES C CXX)
  
- if(BINARY_RELEASE)
+ if(LTO)

Add joystick/gamecontroller support to multimedia/sfml

2020-03-09 Thread Sebastian Reitenbach 
Hi,

attached patch adds gamecontroller support for multimedia/sfml.

My first attempt was to just enable the FreeBSD driver, with that, it detected
my gamepads, however, no buttons, axis, hat, etc. worked.

Then I looked at how the SDLs do it, adapted their logic, and finally, all the 
buttons,
axis, hats now seem to do what they're supposed to.

Tested with witchblast (buttons and hat), and extremetuxracer (analog joystick).
Both games tested with Logitec F310 game controllers. Other ports depending on
sfml don't seem to make use of its joystick/gamecontroller support.

However, witchblast needs a patch (find it attached), otherwise in joystick 
configuration
menu, it would take a button release as a valid input. No idea how it's 
supposed to work
with other OSs joystick implementations from sfml without that patch.

test reports, OKs, critics, anything welcome ;)

cheers,
Sebastian
? XXX
? output
? witchblast-joystick.diff
Index: Makefile
===
RCS file: /cvs/ports/games/witchblast/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile	14 Jul 2019 00:39:37 -	1.4
+++ Makefile	9 Mar 2020 22:37:35 -
@@ -5,7 +5,7 @@
 GH_ACCOUNT =	Cirrus-Minor
 GH_PROJECT =	witchblast
 GH_TAGNAME =	v0.7.5
-REVISION =	1
+REVISION =	2
 
 CATEGORIES =	games x11
 
Index: patches/patch-src_WitchBlastGame_cpp
===
RCS file: /cvs/ports/games/witchblast/patches/patch-src_WitchBlastGame_cpp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-src_WitchBlastGame_cpp
--- patches/patch-src_WitchBlastGame_cpp	26 Dec 2017 20:14:34 -	1.1.1.1
+++ patches/patch-src_WitchBlastGame_cpp	9 Mar 2020 22:37:35 -
@@ -14,3 +14,15 @@
time_t t = time(0);   // get time now
struct tm * now = localtime( & t );
  
+@@ -3107,6 +3107,11 @@ void WitchBlastGame::updateMenu()
+ menuState = MenuStateConfig;
+ saveConfigurationToFile();
+ return;
++  }
++
++  // Ignore buttons that get released
++  if (event.type == sf::Event::JoystickButtonReleased) {
++	return;
+   }
+ 
+   // button pressed ?
? diff
? out
? sfml
? sfml-joystick-support.diff
Index: Makefile
===
RCS file: /cvs/ports/multimedia/sfml/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- Makefile	12 Jul 2019 20:47:58 -	1.10
+++ Makefile	9 Mar 2020 22:09:10 -
@@ -6,7 +6,7 @@
 DISTNAME =		SFML-${V}-sources
 PKGNAME =		sfml-${V}
 EXTRACT_SUFX =		.zip
-REVISION =		1
+REVISION =		2
 
 SHARED_LIBS +=  sfml-audio1.0 # 2.1
 SHARED_LIBS +=  sfml-graphics 1.0 # 2.1
@@ -24,7 +24,7 @@
 PERMIT_PACKAGE =	Yes
 
 WANTLIB += FLAC GL X11-xcb freetype jpeg m ogg openal vorbis vorbisenc
-WANTLIB += vorbisfile xcb xcb-image xcb-randr ${COMPILER_LIBCXX}
+WANTLIB += vorbisfile xcb xcb-image xcb-randr usbhid ${COMPILER_LIBCXX}
 
 MASTER_SITES =		https://www.sfml-dev.org/files/
 
@@ -51,6 +51,8 @@
 
 post-extract:
 	find ${WRKSRC} -type f -exec perl -pi -e 's/\015//g' {} \;
+	mkdir ${WRKSRC}/src/SFML/Window/OpenBSD
+	cp ${FILESDIR}/JoystickImpl.* ${WRKSRC}/src/SFML/Window/OpenBSD
 
 post-install:
 	find ${PREFIX}/include -name '*.orig' -exec rm {} \;
Index: files/JoystickImpl.cpp
===
RCS file: files/JoystickImpl.cpp
diff -N files/JoystickImpl.cpp
--- /dev/null	1 Jan 1970 00:00:00 -
+++ files/JoystickImpl.cpp	9 Mar 2020 22:09:10 -
@@ -0,0 +1,443 @@
+
+//
+// SFML - Simple and Fast Multimedia Library
+// Copyright (C) 2007-2016 Laurent Gomila (laur...@sfml-dev.org)
+//   2013-2013 David Demelier (demelier.da...@gmail.com)
+//
+// This software is provided 'as-is', without any express or implied warranty.
+// In no event will the authors be held liable for any damages arising from the use of this software.
+//
+// Permission is granted to anyone to use this software for any purpose,
+// including commercial applications, and to alter it and redistribute it freely,
+// subject to the following restrictions:
+//
+// 1. The origin of this software must not be misrepresented;
+//you must not claim that you wrote the original software.
+//If you use this software in a product, an acknowledgment
+//in the product documentation would be appreciated but is not required.
+//
+// 2. Altered source versions must be plainly marked as such,
+//and must not be misrepresented as being the original software.
+//
+// 3. This notice may not be removed or altered from any source distribution.
+//
+
+
+
+// Headers
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#inc

Re: editors/sigil : open file dialog make it hang

2020-03-09 Thread Stuart Henderson 
On 2020/03/09 20:21, Solene Rapenne wrote:
> The software editors/sigil hangs when I use File>Open file dialog, this
> looks like the exact same issue I reported in calibre
> https://marc.info/?l=openbsd-ports&m=158201980905357&w=2
> 
> Using "Save as" file dialog works as expected though.
> 
> I have no crash output because it hangs, only this messages from Gtk
> 
> I'm using OpenBSD -current amd64, updated with today's snapshot and packages 
> up
> to date.
> 
> solene@t480 ~ $ sigil
> Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/tmp/runtime-solene'
> Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/tmp/runtime-solene'
> 
> (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: Error building template class 
> 'GtkDialog' for an instance of type 'GtkDialog': .:2:367 Invalid object type 
> 'GtkHeaderBar'
> (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
> _gtk_container_get_border_width_set: assertion 'GTK_IS_CONTAINER (container)' 
> failed
> (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: gtk_container_set_border_width: 
> assertion 'GTK_IS_CONTAINER (container)' failed
> (sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
> _gtk_container_set_border_width_set: assertion 'GTK_IS_CONTAINER (container)' 
> failed

hmm, why is this Qt software using Gtk?

Re: textproc/calibre hangs when opening a file dialog

2020-03-09 Thread Stuart Henderson 
On 2020/03/09 20:16, Solene Rapenne wrote:
> On Tue, Feb 18, 2020 at 10:55:30AM +0100, Solene Rapenne wrote:
> > When I started calibre for the first time, I clicked on the button to choose
> > another location for the library files, then it hang.
> > 
> > I started it again, choose default path, then when I click on "add a book",
> > file dialog appear totally grey with correct title, and it hangs, I get the
> > following output in the console.
> > 
> > I'm running -current, I tried before and after updating packages today.
> > 
> > Gimp also has an issue when using file dialog, I wonder if this is related.
> > There is no crash here, it just hang. I have no NFS mountpoints.
> > 
> > 
> 
> It also happens on OpenBSD 6.6, I wonder when it started to not work.
> 
> For what it's worth, wih calibre-2.85.1p12 the issue is still there.
> 

A data point from me: it works here, both with my existing config, and
if I move away .config/calibre and start anew. FWIW I *do* have NFS
mountpoints and no problems from that. It is expected that there will be
some spew in the console (see below).

It's unlikely to be directly related to the gimp crash, it is a whole
different X11 stack (py-qt5 for calibre, Gtk+2 for gimp).



This is normal:

$ calibre
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-sthen'
Failed to load libmtp, MTP device detection disabled
No module named libmtp
Exception in thread Thread-5:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/local/lib/calibre/calibre/gui2/device.py", line 409, in run
self.detect_device()
  File "/usr/local/lib/calibre/calibre/gui2/device.py", line 267, in 
detect_device
self.scanner.scan()
  File "/usr/local/lib/calibre/calibre/devices/scanner.py", line 264, in scan
self.devices = self.scanner()
  File "/usr/local/lib/calibre/calibre/devices/scanner.py", line 69, in __call__
self.libusb_err)
ValueError: DeviceScanner needs libusb to work. Error: No module named libusb

Re: lang/ghc fixups

2020-03-09 Thread Matthias Kilian 
Hi Greg,

On Sun, Mar 08, 2020 at 10:25:15PM -0700, Greg Steuck wrote:
> I made a couple of simplifications that pass lang/ghc build and the
> resulting ghc package works for building a subset of Haskell packages (e.g.
> xmonad, xmobar). I only tested on amd64.
> 
> * Remove unneeded patch-libffi_ghc_mk
> * Use ghc 8.6 for bootstrap, cut gcc dependency

Really cool, thanks!

I'll check this against all hs-ports on amd64 and a build of ghc and
some hs-ports on i386 before committing this. (May take a day or
two, because I'm still waiting for my poppler test builds).

Ciao,
Kili

editors/sigil : open file dialog make it hang

2020-03-09 Thread Solene Rapenne 
The software editors/sigil hangs when I use File>Open file dialog, this
looks like the exact same issue I reported in calibre
https://marc.info/?l=openbsd-ports&m=158201980905357&w=2

Using "Save as" file dialog works as expected though.

I have no crash output because it hangs, only this messages from Gtk

I'm using OpenBSD -current amd64, updated with today's snapshot and packages up
to date.

solene@t480 ~ $ sigil
Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
'/tmp/runtime-solene'
Warning: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
'/tmp/runtime-solene'

(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: Error building template class 
'GtkDialog' for an instance of type 'GtkDialog': .:2:367 Invalid object type 
'GtkHeaderBar'
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
_gtk_container_get_border_width_set: assertion 'GTK_IS_CONTAINER (container)' 
failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: gtk_container_set_border_width: 
assertion 'GTK_IS_CONTAINER (container)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
_gtk_container_set_border_width_set: assertion 'GTK_IS_CONTAINER (container)' 
failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: _gtk_box_get_spacing_set: 
assertion 'GTK_IS_BOX (box)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: gtk_box_set_spacing: assertion 
'GTK_IS_BOX (box)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: _gtk_box_set_spacing_set: 
assertion 'GTK_IS_BOX (box)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: gtk_button_box_get_layout: 
assertion 'GTK_IS_BUTTON_BOX (widget)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: gtk_box_set_spacing: assertion 
'GTK_IS_BOX (box)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
_gtk_container_get_border_width_set: assertion 'GTK_IS_CONTAINER (container)' 
failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: gtk_container_set_border_width: 
assertion 'GTK_IS_CONTAINER (container)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.059: 
_gtk_container_set_border_width_set: assertion 'GTK_IS_CONTAINER (container)' 
failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.060: Error building template class 
'GtkFileChooserDialog' for an instance of type 'GtkFileChooserDialog': Unknown 
internal child: vbox
(sigil:51536): Gtk-CRITICAL **: 20:18:50.060: _gtk_file_chooser_set_delegate: 
assertion 'GTK_IS_FILE_CHOOSER (delegate)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.060: gtk_widget_set_visible: assertion 
'GTK_IS_WIDGET (widget)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.060: gtk_widget_set_no_show_all: 
assertion 'GTK_IS_WIDGET (widget)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.060: g_object_setv: assertion 
'G_IS_OBJECT (object)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.060: g_object_get_property: 
assertion 'G_IS_OBJECT (object)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.072: gtk_container_add: assertion 
'GTK_IS_CONTAINER (container)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.072: gtk_container_add: assertion 
'GTK_IS_CONTAINER (container)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.073: 
gtk_file_chooser_set_current_folder_file: assertion 'GTK_IS_FILE_CHOOSER 
(chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.073: 
gtk_file_chooser_set_current_folder_file: assertion 'GTK_IS_FILE_CHOOSER 
(chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.073: gtk_file_chooser_get_files: 
assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.074: g_object_setv: assertion 
'G_IS_OBJECT (object)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.074: g_object_setv: assertion 
'G_IS_OBJECT (object)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.074: g_object_get_property: 
assertion 'G_IS_OBJECT (object)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.074: g_object_setv: assertion 
'G_IS_OBJECT (object)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.074: g_object_setv: assertion 
'G_IS_OBJECT (object)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.074: g_object_setv: assertion 
'G_IS_OBJECT (object)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.074: gtk_file_chooser_add_filter: 
assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.074: gtk_file_chooser_add_filter: 
assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.075: gtk_file_chooser_add_filter: 
assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.075: gtk_file_chooser_add_filter: 
assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.075: gtk_file_chooser_add_filter: 
assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(sigil:51536): Gtk-CRITICAL **: 20:18:50.075: 
gtk_file_chooser_set_current_folder_file: assertion 'GTK_IS_FILE_CHOOSER 
(chooser)' failed
(sigil:51536): GLib-GObject-CRITICAL **: 20:18:50.075: g_object_se

Re: textproc/calibre hangs when opening a file dialog

2020-03-09 Thread Solene Rapenne 
On Tue, Feb 18, 2020 at 10:55:30AM +0100, Solene Rapenne wrote:
> When I started calibre for the first time, I clicked on the button to choose
> another location for the library files, then it hang.
> 
> I started it again, choose default path, then when I click on "add a book",
> file dialog appear totally grey with correct title, and it hangs, I get the
> following output in the console.
> 
> I'm running -current, I tried before and after updating packages today.
> 
> Gimp also has an issue when using file dialog, I wonder if this is related.
> There is no crash here, it just hang. I have no NFS mountpoints.
> 
> 

It also happens on OpenBSD 6.6, I wonder when it started to not work.

For what it's worth, wih calibre-2.85.1p12 the issue is still there.

Re: [NEW] astro/p5-Astro-satpass

2020-03-09 Thread Stuart Henderson 
On 2020/02/15 12:51, Andrew Hewus Fresh wrote:
> On Mon, Jan 27, 2020 at 09:31:41AM +, wen heping wrote:
> > Hi, ports@:
> > 
> >   Here is a patch to cretae new port: astro/p5-Astro-satpass.
> >   It build well and pass all tests on amd64-current system.
> > 
> > Cheers !
> > wen
> 
> It seems useful to add `CONFIGURE_ARGS = -y` in order to install the
> "satpass" utility, which will require a regen of the PLIST.
> 
> Unfortunately I couldn't get geocoding to work as we don't have
> Geo::Coder::OSM in the tree, and once I set lat/lon manually it then
> said "Astro::SpaceTrack must be installed if you wish to use command
> st", so maybe it's not that useful.
> 
> I'm unsure how common the JSON format files are, but it wouldn't be hard
> to add `RUN_DEPENDS += converters/p5-JSON` so it Just Works.
> 
> OK afresh1@ in any case, it seems to work, with our without
> addressing these ideas
> 

Since the satpass script is deprecated and upstream has plans to remove it
completely, maybe it's better to skip it and port Astro::App::Satpass2
along with at least Astro::SpaceTrack (it is much less useful without that..)

It is of a lot more interest to present the whole collection of ports that
can be used to do something immediately useful, rather than just the calculation
module which is obviously meant to work with a number of other modules.

Re: update: www/py-gnunicorn

2020-03-09 Thread Paco Esteban 
On Mon, 09 Mar 2020, Stuart Henderson wrote:

> >  HOMEPAGE = http://gunicorn.org/
> 
> https
> 
> > -.if ! ${FLAVOR:Mpython3}
> > -TEST_DEPENDS +=devel/py-mock
> > -.endif
> 
> py-mock was only used for py2...
> 
> >  
> > -post-install:
> > -   for i in ${PREFIX}/bin/*; do \
> > -   mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
> > -   done
> > +TEST_DEPENDS +=devel/py-mock
> 
> ...but here you set (the py2 version of) py-mock to be used as test dep
> for py3 -> please remove TEST_DEPENDS.
> 

Thanks Stuart, I totally missed those two.  Here's the corrected diff:


Index: Makefile
===
RCS file: /home/cvs/ports/www/py-gunicorn/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile12 Jul 2019 20:51:01 -  1.23
+++ Makefile9 Mar 2020 15:48:15 -
@@ -2,13 +2,12 @@
 
 COMMENT =  Python WSGI HTTP server
 
-MODPY_EGG_VERSION =19.9.0
+MODPY_EGG_VERSION =20.0.4
 DISTNAME = gunicorn-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 CATEGORIES =   www
-REVISION = 0
 
-HOMEPAGE = http://gunicorn.org/
+HOMEPAGE = https://gunicorn.org/
 
 # MIT
 PERMIT_PACKAGE =   Yes
@@ -16,26 +15,18 @@ PERMIT_PACKAGE =Yes
 MODULES =  lang/python
 MODPY_PI = Yes
 MODPY_SETUPTOOLS = Yes
+MODPY_PYTEST = Yes
 
 FLAVORS =  python3
-FLAVOR ?=
+FLAVOR =   python3
+
+RUN_DEPENDS =  www/py-multidict${MODPY_FLAVOR}
+
+RUN_DEPENDS += www/py-aiohttp
 
-# py-aiohttp and py-multidict are python3 only
-.if ${FLAVOR:Mpython3}
-RUN_DEPENDS += www/py-aiohttp \
-   www/py-multidict
-.endif
 TEST_DEPENDS = devel/py-coverage${MODPY_FLAVOR} \
devel/py-test${MODPY_FLAVOR} \
devel/py-test-cov${MODPY_FLAVOR} \
${BASE_PKGPATH}=${MODPY_EGG_VERSION}
-.if ! ${FLAVOR:Mpython3}
-TEST_DEPENDS +=devel/py-mock
-.endif
-
-post-install:
-   for i in ${PREFIX}/bin/*; do \
-   mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
-   done
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/www/py-gunicorn/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo24 Apr 2019 20:14:08 -  1.14
+++ distinfo9 Mar 2020 14:39:21 -
@@ -1,2 +1,2 @@
-SHA256 (gunicorn-19.9.0.tar.gz) = +iZiCXxm+SD1P3BiHGxYyko8TTQ0IF5gjhIbWztx9PM=
-SIZE (gunicorn-19.9.0.tar.gz) = 415774
+SHA256 (gunicorn-20.0.4.tar.gz) = GQS7K4pDZYgHEI1Zw/PVbCthIacBFh3g3fmtFABzxiY=
+SIZE (gunicorn-20.0.4.tar.gz) = 373841
Index: patches/patch-requirements_test_txt
===
RCS file: patches/patch-requirements_test_txt
diff -N patches/patch-requirements_test_txt
--- patches/patch-requirements_test_txt 24 Apr 2019 20:14:08 -  1.4
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-requirements_test_txt,v 1.4 2019/04/24 20:14:08 sthen Exp $
-
-Relax overly strict requirements
-
-Index: requirements_test.txt
 requirements_test.txt.orig
-+++ requirements_test.txt
-@@ -1,3 +1,3 @@
--coverage>=4.0,<4.4  # TODO: https://github.com/benoitc/gunicorn/issues/1548
--pytest==3.2.5  # TODO: upgrade to latest version requires drop support to 
Python 2.6
--pytest-cov==2.5.1
-+coverage
-+pytest
-+pytest-cov
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/www/py-gunicorn/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST   24 Apr 2019 20:14:08 -  1.9
+++ pkg/PLIST   9 Mar 2020 14:39:21 -
@@ -1,6 +1,7 @@
 @comment $OpenBSD: PLIST,v 1.9 2019/04/24 20:14:08 sthen Exp $
-bin/gunicorn${MODPY_BIN_SUFFIX}
-bin/gunicorn_paster${MODPY_BIN_SUFFIX}
+@conflict py-gunicorn-*
+@pkgpath www/py-gunicorn
+bin/gunicorn
 lib/python${MODPY_VERSION}/site-packages/gunicorn/
 
lib/python${MODPY_VERSION}/site-packages/gunicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
 
lib/python${MODPY_VERSION}/site-packages/gunicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -13,21 +14,16 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/gunicorn/__init__.py
 
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}_compat.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}arbiter.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}argparse_compat.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/gu

Re: update: www/py-gnunicorn

2020-03-09 Thread Stuart Henderson 
On 2020/03/09 15:53, Paco Esteban wrote:
> On Sun, 08 Mar 2020, Paco Esteban wrote:
> 
> > On Sun, 08 Mar 2020, Paco Esteban wrote:
> > 
> > > About the port itself, I made it py3 only, as the consumers are already
> > > py3 only.
> > 
> > Forgot to mention that commits for www/Makefile and quirks will follow
> > if this gets ok, of course.
> 
> Applying sthen's suggestions on www/py-multidict makes this diff
> a little bit different.  I've kept the separation of ${MODPY_FLAVOR}
> ports for style consistency with what was already on the port.
> I personally do not like it and prefer to have a single list.  Let me
> know what's the best approach.

That will be self-correcting when we move the remaining dependency
to new-style FLAVOR=python3 :)


> ok ? comments ?

one nit and one problem otherwise ok:

> Index: Makefile
> ===
> RCS file: /home/cvs/ports/www/py-gunicorn/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- Makefile  12 Jul 2019 20:51:01 -  1.23
> +++ Makefile  9 Mar 2020 14:41:38 -
> @@ -2,11 +2,10 @@
>  
>  COMMENT =Python WSGI HTTP server
>  
> -MODPY_EGG_VERSION =  19.9.0
> +MODPY_EGG_VERSION =  20.0.4
>  DISTNAME =   gunicorn-${MODPY_EGG_VERSION}
>  PKGNAME =py-${DISTNAME}
>  CATEGORIES = www
> -REVISION =   0
>  
>  HOMEPAGE =   http://gunicorn.org/

https

>  
> @@ -16,26 +15,20 @@ PERMIT_PACKAGE =  Yes
>  MODULES =lang/python
>  MODPY_PI =   Yes
>  MODPY_SETUPTOOLS =   Yes
> +MODPY_PYTEST =   Yes
>  
>  FLAVORS =python3
> -FLAVOR ?=
> +FLAVOR = python3
> +
> +RUN_DEPENDS =www/py-multidict${MODPY_FLAVOR}
> +
> +RUN_DEPENDS +=   www/py-aiohttp
>  
> -# py-aiohttp and py-multidict are python3 only
> -.if ${FLAVOR:Mpython3}
> -RUN_DEPENDS +=   www/py-aiohttp \
> - www/py-multidict
> -.endif
>  TEST_DEPENDS =   devel/py-coverage${MODPY_FLAVOR} \
>   devel/py-test${MODPY_FLAVOR} \
>   devel/py-test-cov${MODPY_FLAVOR} \
>   ${BASE_PKGPATH}=${MODPY_EGG_VERSION}
> -.if ! ${FLAVOR:Mpython3}
> -TEST_DEPENDS +=  devel/py-mock
> -.endif

py-mock was only used for py2...

>  
> -post-install:
> - for i in ${PREFIX}/bin/*; do \
> - mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
> - done
> +TEST_DEPENDS +=  devel/py-mock

...but here you set (the py2 version of) py-mock to be used as test dep
for py3 -> please remove TEST_DEPENDS.

>  
>  .include 
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/www/py-gunicorn/distinfo,v
> retrieving revision 1.14
> diff -u -p -r1.14 distinfo
> --- distinfo  24 Apr 2019 20:14:08 -  1.14
> +++ distinfo  9 Mar 2020 14:39:21 -
> @@ -1,2 +1,2 @@
> -SHA256 (gunicorn-19.9.0.tar.gz) = 
> +iZiCXxm+SD1P3BiHGxYyko8TTQ0IF5gjhIbWztx9PM=
> -SIZE (gunicorn-19.9.0.tar.gz) = 415774
> +SHA256 (gunicorn-20.0.4.tar.gz) = 
> GQS7K4pDZYgHEI1Zw/PVbCthIacBFh3g3fmtFABzxiY=
> +SIZE (gunicorn-20.0.4.tar.gz) = 373841
> Index: patches/patch-requirements_test_txt
> ===
> RCS file: patches/patch-requirements_test_txt
> diff -N patches/patch-requirements_test_txt
> --- patches/patch-requirements_test_txt   24 Apr 2019 20:14:08 -  
> 1.4
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,14 +0,0 @@
> -$OpenBSD: patch-requirements_test_txt,v 1.4 2019/04/24 20:14:08 sthen Exp $
> -
> -Relax overly strict requirements
> -
> -Index: requirements_test.txt
>  requirements_test.txt.orig
> -+++ requirements_test.txt
> -@@ -1,3 +1,3 @@
> --coverage>=4.0,<4.4  # TODO: https://github.com/benoitc/gunicorn/issues/1548
> --pytest==3.2.5  # TODO: upgrade to latest version requires drop support to 
> Python 2.6
> --pytest-cov==2.5.1
> -+coverage
> -+pytest
> -+pytest-cov
> Index: pkg/PLIST
> ===
> RCS file: /home/cvs/ports/www/py-gunicorn/pkg/PLIST,v
> retrieving revision 1.9
> diff -u -p -r1.9 PLIST
> --- pkg/PLIST 24 Apr 2019 20:14:08 -  1.9
> +++ pkg/PLIST 9 Mar 2020 14:39:21 -
> @@ -1,6 +1,7 @@
>  @comment $OpenBSD: PLIST,v 1.9 2019/04/24 20:14:08 sthen Exp $
> -bin/gunicorn${MODPY_BIN_SUFFIX}
> -bin/gunicorn_paster${MODPY_BIN_SUFFIX}
> +@conflict py-gunicorn-*
> +@pkgpath www/py-gunicorn
> +bin/gunicorn
>  lib/python${MODPY_VERSION}/site-packages/gunicorn/
>  
> lib/python${MODPY_VERSION}/site-packages/gunicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
>  
> lib/python${MODPY_VERSION}/site-packages/gunicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
> @@ -13,21 +14,16 @@ lib/python${MODPY_VERSION}/site-packages
>  lib/python${MODPY_VERSION}/site-packages/gunicorn/__init__.py
>  
> ${MODPY_

Re: update: www/py-multidict

2020-03-09 Thread Stuart Henderson 
On 2020/03/09 15:49, Paco Esteban wrote:
> On Mon, 09 Mar 2020, Stuart Henderson wrote:
> 
> > On 2020/03/08 18:47, Paco Esteban wrote:
> > > Hi ports@,
> > > 
> > > Here's an update for www/py-multidict to 4.7.5
> > 
> > Could you convert to new-style FLAVOR=python3 / FLAVORS=python3 while there 
> > please?
> > (depends in py-yarl, py-aiohttp, py-gunicorn will need bumps and  
> > ${MODPY_FLAVOR}
> > adding to the multidict line).
> > 
> > > --- pkg/PLIST 26 Apr 2018 13:05:38 -  1.3
> > > +++ pkg/PLIST 6 Mar 2020 18:22:56 -
> > > @@ -1,5 +1,5 @@
> > >  @comment $OpenBSD: PLIST,v 1.3 2018/04/26 13:05:38 danj Exp $
> > > -@pkgpath www/py3-multidict
> > > +@pkgpath www/${MODPY_PY_PREFIX}multidict
> > 
> > Please put this line back how it was.
> 
> Find attached the modified diff for www/py-multidict.  I've also
> included 2 diffs for www/py-yarl and www/py-aiohttp.  For py-gunicorn,
> I'll send as a response to the thread I started for its update.
> 
> I'll also commit mods to www/Makefile and quirks if this is ok.

So with the new-style FLAVOR=python3 in order to get the update to work
seamlessly, it will also need

@pkgpath www/py-multidict

in www/py-multidict/pkg/PLIST.

Otherwise OK (assuming py-gunicorn done at the same time).

Re: UPDATE: Qt 5.13.2

2020-03-09 Thread Stuart Henderson 
On 2020/03/08 16:45, Landry Breuil wrote:
> On Sun, Mar 08, 2020 at 12:59:30PM +, Stuart Henderson wrote:
> > On 2020/03/08 12:40, Stuart Henderson wrote:
> > > py-sip-qt5 attached for completeness, it is the same as the last one from
> > > Landry. OK sthen@ to import that unhooked, then we can hook it to the 
> > > build
> > > when switching over.
> > 
> > py-sip-qt5 needs this added:
> > 
> > MAKE_FLAGS +=   CC="${CC}" CXX="${CXX}"
> > 
> 
> i had it fixed locally by amending the existing patch copied from
> py-sip:

I prefer MAKE_FLAGS because it actually uses what is set through ports,
though IIRC this is all very hit-and-miss with qt ports anyway.

> but i'm fine with MAKE_FLAGS too - fixed version attached.
> 
> still uncertain on the naming ? x11/py-sip-qt5 ? upstream names it 
> PyQt5-sip...
> py-qt5-sip ? who cares ?

I don't :)  I am ok with your current name.


> my bulk is at 3550 so far, the only thing to fix is the version
> dependency in devel/spyder/spyder which has
> x11/py-qt5${MODPY_FLAVOR}<5.12 for some reason:
> 
> Error: @depend x11/py-qt5,python3:py3-qt5-<5.12:py3-qt5-5.13.2
>   pattern py3-qt5-<5.12 doesn't match default py3-qt5-5.13.2

So for spyder.. upstream for the version in ports has <=5.12, which was later
amended to <5.13 (49c6c2aa86 "Setup.py: Fix PyQt5 pinning conditions").
The port Makefile has <5.12 which doesn't quite match either of these.

Upstream's current position: 
https://github.com/spyder-ide/spyder/issues/9829#issuecomment-574749134

Can you try removing the version dependency and see if spyder works anyway?
Looking at the github issues you mentioned it seems the most likely thing to
break is theme icons for the "Spyder 3" theme (tools/prefs/scroll down).

> the only other failures i have are fetching
> devel/libtalloc:talloc-2.1.16.tar.gz databases/tdb:tdb-1.3.18.tar.gz but
> those are totally unrelated, https://download.samba.org/pub/talloc/
> returns a 403 to dpb, but i can fetch it locally so i guess it's just a
> fluke.

old ftp(1) :)

> definitely agree we should go ahead will all this :)

Re: update: www/py-gnunicorn

2020-03-09 Thread Paco Esteban 
On Sun, 08 Mar 2020, Paco Esteban wrote:

> On Sun, 08 Mar 2020, Paco Esteban wrote:
> 
> > About the port itself, I made it py3 only, as the consumers are already
> > py3 only.
> 
> Forgot to mention that commits for www/Makefile and quirks will follow
> if this gets ok, of course.

Applying sthen's suggestions on www/py-multidict makes this diff
a little bit different.  I've kept the separation of ${MODPY_FLAVOR}
ports for style consistency with what was already on the port.
I personally do not like it and prefer to have a single list.  Let me
know what's the best approach.

ok ? comments ?


Index: Makefile
===
RCS file: /home/cvs/ports/www/py-gunicorn/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile12 Jul 2019 20:51:01 -  1.23
+++ Makefile9 Mar 2020 14:41:38 -
@@ -2,11 +2,10 @@
 
 COMMENT =  Python WSGI HTTP server
 
-MODPY_EGG_VERSION =19.9.0
+MODPY_EGG_VERSION =20.0.4
 DISTNAME = gunicorn-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 CATEGORIES =   www
-REVISION = 0
 
 HOMEPAGE = http://gunicorn.org/
 
@@ -16,26 +15,20 @@ PERMIT_PACKAGE =Yes
 MODULES =  lang/python
 MODPY_PI = Yes
 MODPY_SETUPTOOLS = Yes
+MODPY_PYTEST = Yes
 
 FLAVORS =  python3
-FLAVOR ?=
+FLAVOR =   python3
+
+RUN_DEPENDS =  www/py-multidict${MODPY_FLAVOR}
+
+RUN_DEPENDS += www/py-aiohttp
 
-# py-aiohttp and py-multidict are python3 only
-.if ${FLAVOR:Mpython3}
-RUN_DEPENDS += www/py-aiohttp \
-   www/py-multidict
-.endif
 TEST_DEPENDS = devel/py-coverage${MODPY_FLAVOR} \
devel/py-test${MODPY_FLAVOR} \
devel/py-test-cov${MODPY_FLAVOR} \
${BASE_PKGPATH}=${MODPY_EGG_VERSION}
-.if ! ${FLAVOR:Mpython3}
-TEST_DEPENDS +=devel/py-mock
-.endif
 
-post-install:
-   for i in ${PREFIX}/bin/*; do \
-   mv $${i} $${i}${MODPY_BIN_SUFFIX} ;\
-   done
+TEST_DEPENDS +=devel/py-mock
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/www/py-gunicorn/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo24 Apr 2019 20:14:08 -  1.14
+++ distinfo9 Mar 2020 14:39:21 -
@@ -1,2 +1,2 @@
-SHA256 (gunicorn-19.9.0.tar.gz) = +iZiCXxm+SD1P3BiHGxYyko8TTQ0IF5gjhIbWztx9PM=
-SIZE (gunicorn-19.9.0.tar.gz) = 415774
+SHA256 (gunicorn-20.0.4.tar.gz) = GQS7K4pDZYgHEI1Zw/PVbCthIacBFh3g3fmtFABzxiY=
+SIZE (gunicorn-20.0.4.tar.gz) = 373841
Index: patches/patch-requirements_test_txt
===
RCS file: patches/patch-requirements_test_txt
diff -N patches/patch-requirements_test_txt
--- patches/patch-requirements_test_txt 24 Apr 2019 20:14:08 -  1.4
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-requirements_test_txt,v 1.4 2019/04/24 20:14:08 sthen Exp $
-
-Relax overly strict requirements
-
-Index: requirements_test.txt
 requirements_test.txt.orig
-+++ requirements_test.txt
-@@ -1,3 +1,3 @@
--coverage>=4.0,<4.4  # TODO: https://github.com/benoitc/gunicorn/issues/1548
--pytest==3.2.5  # TODO: upgrade to latest version requires drop support to 
Python 2.6
--pytest-cov==2.5.1
-+coverage
-+pytest
-+pytest-cov
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/www/py-gunicorn/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST   24 Apr 2019 20:14:08 -  1.9
+++ pkg/PLIST   9 Mar 2020 14:39:21 -
@@ -1,6 +1,7 @@
 @comment $OpenBSD: PLIST,v 1.9 2019/04/24 20:14:08 sthen Exp $
-bin/gunicorn${MODPY_BIN_SUFFIX}
-bin/gunicorn_paster${MODPY_BIN_SUFFIX}
+@conflict py-gunicorn-*
+@pkgpath www/py-gunicorn
+bin/gunicorn
 lib/python${MODPY_VERSION}/site-packages/gunicorn/
 
lib/python${MODPY_VERSION}/site-packages/gunicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
 
lib/python${MODPY_VERSION}/site-packages/gunicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
@@ -13,21 +14,16 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/gunicorn/__init__.py
 
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}_compat.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}arbiter.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}argparse_compat.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/gunicorn/${MODPY_PYCACHE}config.${MODPY_

Re: update: www/py-multidict

2020-03-09 Thread Paco Esteban 
On Mon, 09 Mar 2020, Stuart Henderson wrote:

> On 2020/03/08 18:47, Paco Esteban wrote:
> > Hi ports@,
> > 
> > Here's an update for www/py-multidict to 4.7.5
> 
> Could you convert to new-style FLAVOR=python3 / FLAVORS=python3 while there 
> please?
> (depends in py-yarl, py-aiohttp, py-gunicorn will need bumps and  
> ${MODPY_FLAVOR}
> adding to the multidict line).
> 
> > --- pkg/PLIST   26 Apr 2018 13:05:38 -  1.3
> > +++ pkg/PLIST   6 Mar 2020 18:22:56 -
> > @@ -1,5 +1,5 @@
> >  @comment $OpenBSD: PLIST,v 1.3 2018/04/26 13:05:38 danj Exp $
> > -@pkgpath www/py3-multidict
> > +@pkgpath www/${MODPY_PY_PREFIX}multidict
> 
> Please put this line back how it was.

Find attached the modified diff for www/py-multidict.  I've also
included 2 diffs for www/py-yarl and www/py-aiohttp.  For py-gunicorn,
I'll send as a response to the thread I started for its update.

I'll also commit mods to www/Makefile and quirks if this is ok.

Cheers,

-- 
Paco Esteban.
0x5818130B8A6DBC03
Index: Makefile
===
RCS file: /home/cvs/ports/www/py-multidict/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:51:02 -  1.7
+++ Makefile9 Mar 2020 14:37:16 -
@@ -2,13 +2,12 @@
 
 COMMENT =  multidict implementation
 
-MODPY_EGG_VERSION =4.2.0
-REVISION = 1
+MODPY_EGG_VERSION =4.7.5
 DISTNAME = multidict-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
 CATEGORIES =   www devel
 
-WANTLIB += pthread ${MODPY_WANTLIB}
+WANTLIB += pthread ${MODPY_WANTLIB}
 
 # Apache2
 PERMIT_PACKAGE =   Yes
@@ -17,8 +16,12 @@ MODULES =lang/python
 
 MODPY_PI = Yes
 MODPY_SETUPTOOLS = Yes
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
+MODPY_PYTEST = Yes
 
-TEST_DEPENDS = devel/py-test${MODPY_FLAVOR}
+FLAVORS =  python3
+FLAVOR =   python3
+
+TEST_DEPENDS = devel/py-test${MODPY_FLAVOR} \
+   devel/py-test-cov${MODPY_FLAVOR}
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/www/py-multidict/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo26 Apr 2018 13:05:38 -  1.3
+++ distinfo9 Mar 2020 14:34:30 -
@@ -1,2 +1,2 @@
-SHA256 (multidict-4.2.0.tar.gz) = JAUnJBleRocnOfqhDGEZV7us6uKO7JLhzkkVCxFexe0=
-SIZE (multidict-4.2.0.tar.gz) = 137359
+SHA256 (multidict-4.7.5.tar.gz) = ruKDxJYB+kwTrcZMCcl4g4p+gS+FN3rhMKJNcZjAMx4=
+SIZE (multidict-4.7.5.tar.gz) = 50845
Index: patches/patch-multidict__multidict_c
===
RCS file: patches/patch-multidict__multidict_c
diff -N patches/patch-multidict__multidict_c
--- patches/patch-multidict__multidict_c1 Aug 2018 22:39:13 -   
1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-multidict__multidict_c,v 1.1 2018/08/01 22:39:13 juanfra Exp $
-
-Os breaks the build on GCC4 platforms.
-
-Index: multidict/_multidict.c
 multidict/_multidict.c.orig
-+++ multidict/_multidict.c
-@@ -20116,8 +20116,6 @@ static int __Pyx_modinit_function_import_code(void) {
- #ifndef CYTHON_SMALL_CODE
- #if defined(__clang__)
- #define CYTHON_SMALL_CODE
--#elif defined(__GNUC__)
--#define CYTHON_SMALL_CODE __attribute__((optimize("Os")))
- #else
- #define CYTHON_SMALL_CODE
- #endif
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/www/py-multidict/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST   26 Apr 2018 13:05:38 -  1.3
+++ pkg/PLIST   9 Mar 2020 14:35:43 -
@@ -8,18 +8,23 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/multidict-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/multidict/__init__.py
 lib/python${MODPY_VERSION}/site-packages/multidict/__init__.pyi
-lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}/
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}_abc.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}_compat.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}_multidict_base.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/multidict/${MODPY_PYCACHE}_multidict_py.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/multidict/_abc.py
 lib/python${MODPY_VERSION}/site-packages/multidict/_compat.py
-lib/python${MODPY_VERSION}/site-packages/multidict/_istr.c

Re: [update] gzdoom-4.3.3

2020-03-09 Thread Solene Rapenne 
On Fri, Feb 28, 2020 at 09:46:17PM +0200, Timo Myyrä wrote:
> Stuart Henderson  writes:
> 
> > On 2020/02/28 08:51, Timo Myyrä wrote:
> >
> >> Hi,
> >> 
> >> Here's an update to latest gzdoom, hopefully I got the patch right.
> >> Slightly playtested on amd64.
> >> 
> >> timo
> >> 
> >> Index: Makefile
> >> ===
> >> RCS file: /cvs/ports/games/gzdoom/Makefile,v
> >> retrieving revision 1.10
> >> diff -u -p -u -p -r1.10 Makefile
> >> --- Makefile   6 Dec 2019 17:40:23 -   1.10
> >> +++ Makefile   28 Feb 2020 06:49:15 -
> >> @@ -8,12 +8,12 @@ ONLY_FOR_ARCHS = i386 amd64
> >>  
> >>  COMMENT = OpenGL engine for idTech 1 games like 
> >> doom,hexen,heretic...
> >>  
> >> -V =   4.2.4
> >> +V =   4.3.3
> >>  PKGNAME = gzdoom-${V}
> >>  
> >>  GH_ACCOUNT =  coelckers
> >>  GH_PROJECT =  gzdoom
> >> -GH_TAGNAME =  g4.2.4
> >> +GH_TAGNAME =  g4.3.3
> >>  DISTNAME =gzdoom-${GH_TAGNAME:S/g//}
> >
> > Why not do this to simplify things?
> >
> > V = 4.3.3
> > GH_ACCOUNT =coelckers
> > GH_PROJECT =gzdoom
> > GH_TAGNAME =g${V}
> > DISTNAME =  gzdoom-${V}
> >
> > (no need for a separate PKGNAME)
> 
> I see no reason not to clean it up, here's revised diff.
> Also tested that saved games from previous version still work.
> 
> timo
> 

I did commit your diff, thank you very much for the work.

I did recompile the port and it was working this time, it stopped
crashing and other people reported the game was working without any
issue. I may had a local setting leading to the crash maybe.

Re: [update] py-importlib-metadata -> 1.5.0

2020-03-09 Thread Stuart Henderson 
On 2020/03/09 10:07, Renaud Allard wrote:
> Here is a quick diff to py-importlib-metadata

committed, there are some test dependencies missing (zipp which was already
missing for the old version, pyfakefs which is new) so I added a comment
to Makefile, and fixed a typo in COMMENT while there.

On 2020/03/09 10:24, Renaud Allard wrote:
> Here is a diff for net/synapse to v 1.11.1

committed.

Re: update: www/py-multidict

2020-03-09 Thread Stuart Henderson 
On 2020/03/08 18:47, Paco Esteban wrote:
> Hi ports@,
> 
> Here's an update for www/py-multidict to 4.7.5

Could you convert to new-style FLAVOR=python3 / FLAVORS=python3 while there 
please?
(depends in py-yarl, py-aiohttp, py-gunicorn will need bumps and  
${MODPY_FLAVOR}
adding to the multidict line).

> --- pkg/PLIST 26 Apr 2018 13:05:38 -  1.3
> +++ pkg/PLIST 6 Mar 2020 18:22:56 -
> @@ -1,5 +1,5 @@
>  @comment $OpenBSD: PLIST,v 1.3 2018/04/26 13:05:38 danj Exp $
> -@pkgpath www/py3-multidict
> +@pkgpath www/${MODPY_PY_PREFIX}multidict

Please put this line back how it was.

Re: [UPDATE] databases/py-ldap3 to 2.7

2020-03-09 Thread Stuart Henderson 
On 2020/03/08 14:22, Lucas Raab wrote:
> Hello,
> 
> Attached a version bump for py-ldap3 from 2.6.1 to 2.7. Builds fine and
> runs fine with the AD/LDAP servers I have. Anyone want to chime in?
> 
> Lucas

Committed, I added NO_TEST because some of the necessary files from
https://github.com/cannatag/ldap3/tree/master/test are missing in the pypi
tarball.

Re: WIP: Update of math/py-numpy to 1.16.5

2020-03-09 Thread Stuart Henderson 
On 2020/03/09 10:42, Theo Buehler wrote:
> On Mon, Jan 13, 2020 at 12:50:32PM +, Stuart Henderson wrote:
> > 2/3 through a bulk build and I see that this breaks scipy (missing symbols,
> > blas/cblas-related) so needs a bit more work, but I think it's generally
> > along the right lines.
> 
> Not sure if this provides any useful clue, but py-numpy doesn't build at
> all on sparc64 with this diff, also due to missing blas/cblas symbols:

You'll probably see the same on amd64 with USE_LLD=no.

Re: [UPDATE] ropper et filebytes

2020-03-09 Thread Paco Esteban 
Hi Remi,

On Sun, 08 Mar 2020, Remi Pointel wrote:

> Hi,
> 
> these are the diff to update filebytes and ropper to latest releases.
> 
> Ok?

ropper has no consumers and filebytes only has ropper.  I gess those are
perfect candidates to go py3 only, don't you think ?

Cheers,

-- 
Paco Esteban.
0x5818130B8A6DBC03

Re: WIP: Update of math/py-numpy to 1.16.5

2020-03-09 Thread Theo Buehler 
On Mon, Jan 13, 2020 at 12:50:32PM +, Stuart Henderson wrote:
> 2/3 through a bulk build and I see that this breaks scipy (missing symbols,
> blas/cblas-related) so needs a bit more work, but I think it's generally
> along the right lines.

Not sure if this provides any useful clue, but py-numpy doesn't build at
all on sparc64 with this diff, also due to missing blas/cblas symbols:

===> py-numpy-1.16.5 depends on: g95->=8,<9 -> g95-8.3.0p4
===> py-numpy-1.16.5 depends on: python->=2.7,<2.8 -> python-2.7.17p1
===> py-numpy-1.16.5 depends on: py-setuptools->=39.0.1v0 -> 
py-setuptools-41.6.0v0
===> py-numpy-1.16.5 depends on: gcc->=8,<9 -> gcc-8.3.0p4
===> py-numpy-1.16.5 depends on: unzip-* -> unzip-6.0p12
===> py-numpy-1.16.5 depends on: cblas-* -> cblas-1.0p6
===> py-numpy-1.16.5 depends on: lapack-* -> lapack-3.8.0p1
===> py-numpy-1.16.5 depends on: gcc-libs->=8,<9 -> gcc-libs-8.3.0p4
===>  Verifying specs:  gfortran>=8 python2.7 blas cblas lapack m pthread 
gfortran>=8
===>  found gfortran.8.0 python2.7.0.0 blas.2.1 cblas.1.0 lapack.7.1 m.10.1 
pthread.26.1
===>  Checking files for py-numpy-1.16.5
`/usr/ports/distfiles/numpy-1.16.5.zip' is up to date.
>> (SHA256) numpy-1.16.5.zip: OK
===>  Extracting for py-numpy-1.16.5
===>  Patching for py-numpy-1.16.5
===>   Applying OpenBSD patch patch-numpy_core_include_numpy_npy_common_h
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-numpy_core_include_numpy_npy_common_h,v 1.6 2018/06/30 
21:49:33 daniel Exp $
|
|XXX recheck powerpc, is this still needed?
|
|py-numpy only checks for expl to determine whether extended-precision
|support is present.  since we don't have it yet;  it implements
|it's own.  however, on alpha, powerpc, it declared functions with
|types that conflict with C99 (double for *l), therefore failed.
|
|Index: numpy/core/include/numpy/npy_common.h
|--- numpy/core/include/numpy/npy_common.h.orig
|+++ numpy/core/include/numpy/npy_common.h
--
Patching file numpy/core/include/numpy/npy_common.h using Plan A...
Hunk #1 succeeded at 320.
done
===>   Ignoring patchfile patch-numpy_core_include_numpy_npy_common_h.orig
===>   Applying OpenBSD patch patch-numpy_distutils_command_build_src_py
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-numpy_distutils_command_build_src_py,v 1.3 2018/06/30 21:49:33 
daniel Exp $
|
|fix build of other packages (e.g. py-scipy) in some cases (e.g. when
|WRKOBJDIR has a trailing slash)
|
|Index: numpy/distutils/command/build_src.py
|--- numpy/distutils/command/build_src.py.orig
|+++ numpy/distutils/command/build_src.py
--
Patching file numpy/distutils/command/build_src.py using Plan A...
Hunk #1 succeeded at 370.
done
===>   Ignoring patchfile patch-numpy_distutils_command_build_src_py.orig
===>   Applying OpenBSD patch patch-numpy_distutils_fcompiler_gnu_py
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-numpy_distutils_fcompiler_gnu_py,v 1.2 2018/06/30 21:49:33 
daniel Exp $
|
|Causes segmentation fault on powerpc when building py-scipy.
|
|See discussion at:
|https://github.com/numpy/numpy/issues/5451
|
|Index: numpy/distutils/fcompiler/gnu.py
|--- numpy/distutils/fcompiler/gnu.py.orig
|+++ numpy/distutils/fcompiler/gnu.py
--
Patching file numpy/distutils/fcompiler/gnu.py using Plan A...
Hunk #1 succeeded at 245.
done
===>   Ignoring patchfile patch-numpy_distutils_fcompiler_gnu_py.orig
===>   Applying OpenBSD patch patch-numpy_distutils_site_cfg
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-numpy_distutils_site_cfg,v 1.2 2009/02/16 10:10:09 eric Exp $
|--- numpy/distutils/site.cfg.orig  Fri Feb 13 15:41:03 2009
|+++ numpy/distutils/site.cfg   Fri Feb 13 15:41:47 2009
--
(Creating file numpy/distutils/site.cfg...)
Patching file numpy/distutils/site.cfg using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
done
===>  Compiler link: gcc -> /usr/local/bin/egcc
===>  Compiler link: cc -> /usr/local/bin/egcc
===>  Compiler link: gfortran -> /usr/local/bin/egfortran
===>  Compiler link: c++ -> /usr/bin/c++
===>  Generating configure for py-numpy-1.16.5
===>  Configuring for py-numpy-1.16.5
===>  Building for py-numpy-1.16.5
cp -f /usr/ports/pobj/py-numpy-1.16.5/numpy-1.16.5/numpy/distutils/site.cfg 
/usr/ports/pobj/py-numpy-1.16.5/numpy-1.16.5/site.cfg
Running from numpy source directory.
running egg_info
creating numpy.egg-info
writing numpy.egg-info/PKG-INFO
writing top-level names to numpy.egg-info/top_level.txt
writing dependency_links to numpy.egg-info/dependency_links.txt
writing entry points to numpy.egg-info/entry_points.txt
writing manifest file 'numpy.egg-info/SOURCES.txt'
reading manifest file 'numpy.egg-info/S

[update] net/synapse -> 1.11.1

2020-03-09 Thread Renaud Allard 
Hello,

Here is a diff for net/synapse to v 1.11.1

This release includes a security fix impacting installations using
Single Sign-On (i.e. SAML2 or CAS) for authentication. Administrators of
such installations are encouraged to upgrade as soon as possible.

The release also includes fixes for a couple of other bugs.

Regards
Index: Makefile
===
RCS file: /cvs/ports/net/synapse/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile	8 Mar 2020 17:03:15 -	1.1.1.1
+++ Makefile	9 Mar 2020 09:22:39 -
@@ -2,7 +2,7 @@
 
 COMMENT =	open network for secure, decentralized communication
 
-MODPY_EGG_VERSION =	1.11.0
+MODPY_EGG_VERSION =	1.11.1
 
 GH_ACCOUNT =	matrix-org
 GH_PROJECT =	synapse
Index: distinfo
===
RCS file: /cvs/ports/net/synapse/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo	8 Mar 2020 17:03:15 -	1.1.1.1
+++ distinfo	9 Mar 2020 09:22:39 -
@@ -1,2 +1,2 @@
-SHA256 (synapse-1.11.0.tar.gz) = SqyqZHy8OY7yqERic7n0SVSLZGrsYVucjmDan5iRZSM=
-SIZE (synapse-1.11.0.tar.gz) = 6363628
+SHA256 (synapse-1.11.1.tar.gz) = oqCE0lq5WPiLF/6wuQ1copk4nD65Q2tioLMKxmYhOSA=
+SIZE (synapse-1.11.1.tar.gz) = 6369073
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/synapse/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST	9 Mar 2020 08:17:59 -	1.2
+++ pkg/PLIST	9 Mar 2020 09:22:39 -
@@ -4,6 +4,8 @@
 @rcscript ${RCDIR}/synapse
 bin/export_signing_key
 bin/generate_log_config
+lib/python${MODPY_VERSION}/
+lib/python${MODPY_VERSION}/site-packages/
 lib/python${MODPY_VERSION}/site-packages/matrix_synapse-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
 lib/python${MODPY_VERSION}/site-packages/matrix_synapse-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
 lib/python${MODPY_VERSION}/site-packages/matrix_synapse-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
@@ -115,6 +117,7 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}server.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}server_notices_config.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}spam_checker.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}sso.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}stats.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}third_party_event_rules.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/synapse/config/${MODPY_PYCACHE}tls.${MODPY_PYC_MAGIC_TAG}pyc
@@ -148,6 +151,7 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/synapse/config/server.py
 lib/python${MODPY_VERSION}/site-packages/synapse/config/server_notices_config.py
 lib/python${MODPY_VERSION}/site-packages/synapse/config/spam_checker.py
+lib/python${MODPY_VERSION}/site-packages/synapse/config/sso.py
 lib/python${MODPY_VERSION}/site-packages/synapse/config/stats.py
 lib/python${MODPY_VERSION}/site-packages/synapse/config/third_party_event_rules.py
 lib/python${MODPY_VERSION}/site-packages/synapse/config/tls.py
@@ -525,6 +529,7 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/synapse/res/templates/registration_success.html
 lib/python${MODPY_VERSION}/site-packages/synapse/res/templates/room.html
 lib/python${MODPY_VERSION}/site-packages/synapse/res/templates/room.txt
+lib/python${MODPY_VERSION}/site-packages/synapse/res/templates/sso_redirect_confirm.html
 lib/python${MODPY_VERSION}/site-packages/synapse/rest/
 lib/python${MODPY_VERSION}/site-packages/synapse/rest/__init__.py
 ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/synapse/rest/${MODPY_PYCACHE}/
@@ -1296,6 +1301,3 @@ share/synapse/synctl
 @owner _synapse
 @group _synapse
 @sample /var/synapse/
-@mode
-@owner
-@group


smime.p7s
Description: S/MIME Cryptographic Signature

[update] py-importlib-metadata -> 1.5.0

2020-03-09 Thread Renaud Allard 
Hi,

Here is a quick diff to py-importlib-metadata

Best Regards
Index: Makefile
===
RCS file: /cvs/ports/devel/py-importlib-metadata/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile	8 Mar 2020 16:28:41 -	1.1.1.1
+++ Makefile	9 Mar 2020 09:06:46 -
@@ -2,7 +2,7 @@
 
 COMMENT =		library providng an API for accessing packages metadata
 
-MODPY_EGG_VERSION =	0.23
+MODPY_EGG_VERSION =	1.5.0
 DISTNAME =		importlib_metadata-${MODPY_EGG_VERSION}
 PKGNAME =		py-${DISTNAME}
 
Index: distinfo
===
RCS file: /cvs/ports/devel/py-importlib-metadata/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo	8 Mar 2020 16:28:41 -	1.1.1.1
+++ distinfo	9 Mar 2020 09:06:46 -
@@ -1,2 +1,2 @@
-SHA256 (importlib_metadata-0.23.tar.gz) = qhjXN4sAtAhHeQ58J+EWc9f+0hk1QQnQ57nlsl3DrSY=
-SIZE (importlib_metadata-0.23.tar.gz) = 25172
+SHA256 (importlib_metadata-1.5.0.tar.gz) = BvWzqZApxxNCB92IJCimaZKp3ivvfCtpm1ZB+YhsMwI=
+SIZE (importlib_metadata-1.5.0.tar.gz) = 26738


smime.p7s
Description: S/MIME Cryptographic Signature

Re: UPDATE: Qt 5.13.2

2020-03-09 Thread Jeremie Courreges-Anglas 
On Sat, Mar 07 2020, Jeremie Courreges-Anglas  wrote:

[...]

> - some -examples subpackages probably need a PLIST refresh.  Note that
>   qttools,-main packaged fine, I'm restarting a build to see whether
>   -examples also packaged properly

Packages fine, no PLIST change except for an additional "@so " in
pkg/PLIST-webview.

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

Re: [py-h5py fix] Re: sparc64 bulk build report

2020-03-09 Thread Theo Buehler 
On Mon, Mar 09, 2020 at 08:25:03AM +0100, Martin Reindl wrote:
> On Mon, Mar 09, 2020 at 08:07:23AM +0100, Theo Buehler wrote:
> > > Is this the complete error output? I get the impression that errors 
> > > related to
> > > numpy are common to hdf5/netcdf ports, it's probably similiar to how 
> > > py-netcdf
> > > fails.
> > 
> > Yes, it's the complete output inlined from test.log.  I'm building
> > math/py-netcdf4 now which looks like it will take a while, will report
> > back once I will have run its tests.
> > 
> > See also ~tb/py-h5py-test.log on cvs.
> 
> If you can spare the CPU cycles, try with the numpy 1.16.5 diff floating
> around.

The py-netcdf4 failure (with the in-tree numpy) is an alignment issue.
Full test.log:

/usr/ports/pobj/py-netcdf4-1.5.3/netCDF4-1.5.3/test/tst_types.py:92:
 UserWarning: WARNING: missing_value not used since it
cannot be safely cast to variable data type
  assert_array_equal(v3[:],-1*np.ones(n2dim,v3.dtype))
..F
==
FAIL: runTest (tst_compoundvar.VariablesTestCase)
testing compound variables
--
Traceback (most recent call last):
  File 
"/usr/ports/pobj/py-netcdf4-1.5.3/netCDF4-1.5.3/test/tst_compoundvar.py", line 
72, in setUp
assert (cmptype4 == dtype4a) # data type should be aligned
AssertionError

--
Ran 91 tests in 412.802s

FAILED (failures=1)
not running tst_unicode.py ...

netcdf4-python version: 1.5.3
HDF5 lib version:   1.10.6
netcdf lib version: 4.7.3
numpy version   1.14.6
cython version  0.29.14
foo_bar
*** Error 1 in . (Makefile:50 'do-test': @cd 
/usr/ports/pobj/py-netcdf4-1.5.3/netCDF4-1.5.3/test && /usr/bin/env -i CC=cc 
PYTHONUSERBASE= PO...)

Re: UPDATE: Qt 5.13.2

2020-03-09 Thread Landry Breuil 
On Sun, Mar 08, 2020 at 12:40:11PM +, Stuart Henderson wrote:
> I'm doing a test build now. (Have disabled a couple of large ports that
> are nothing to do with qt5, but otherwise a standard bulk).
> 
> Here is the complete diff that I'm building with, it includes WANTLIB
> fixes in dependent ports as spotted by cwen@. I have commented-out
> qtlottie from x11/qt5/Makefile because I don't have the files and it
> isn't needed by anything, so it can wait until the main part is done
> (I don't want anything else adding delays :)
> 
> py-sip-qt5 attached for completeness, it is the same as the last one from
> Landry. OK sthen@ to import that unhooked, then we can hook it to the build
> when switching over.
> 
> If my build doesn't find any more problems then I think we should get
> this lot committed ASAP.

my bulk is at 3550 so far, the only thing to fix is the version
dependency in devel/spyder/spyder which has
x11/py-qt5${MODPY_FLAVOR}<5.12 for some reason:

Error: @depend x11/py-qt5,python3:py3-qt5-<5.12:py3-qt5-5.13.2
  pattern py3-qt5-<5.12 doesn't match default py3-qt5-5.13.2

the only other failures i have are fetching
devel/libtalloc:talloc-2.1.16.tar.gz databases/tdb:tdb-1.3.18.tar.gz but
those are totally unrelated, https://download.samba.org/pub/talloc/
returns a 403 to dpb, but i can fetch it locally so i guess it's just a
fluke.

definitely agree we should go ahead will all this :)

Re: [py-h5py fix] Re: sparc64 bulk build report

2020-03-09 Thread Martin Reindl 
On Mon, Mar 09, 2020 at 08:07:23AM +0100, Theo Buehler wrote:
> > Is this the complete error output? I get the impression that errors related 
> > to
> > numpy are common to hdf5/netcdf ports, it's probably similiar to how 
> > py-netcdf
> > fails.
> 
> Yes, it's the complete output inlined from test.log.  I'm building
> math/py-netcdf4 now which looks like it will take a while, will report
> back once I will have run its tests.
> 
> See also ~tb/py-h5py-test.log on cvs.

If you can spare the CPU cycles, try with the numpy 1.16.5 diff floating
around.

-m

Re: [py-h5py fix] Re: sparc64 bulk build report

2020-03-09 Thread Theo Buehler 
> Is this the complete error output? I get the impression that errors related to
> numpy are common to hdf5/netcdf ports, it's probably similiar to how py-netcdf
> fails.

Yes, it's the complete output inlined from test.log.  I'm building
math/py-netcdf4 now which looks like it will take a while, will report
back once I will have run its tests.

See also ~tb/py-h5py-test.log on cvs.