Re: WIP: Update of math/py-numpy to 1.16.5
On Tue, Mar 10 2020, Theo Buehler wrote:
> On Tue, Mar 10, 2020 at 06:35:04PM +0100, Jeremie Courreges-Anglas wrote:
>> On Mon, Mar 09 2020, Stuart Henderson wrote:
>> > 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.
>>
>> I managed to build scipy with no changes on amd64, so I'm not sure what
>> the problem is on this arch (did not try with USE_LLD=No).
>>
>> However I took a look at the issue reported by tb on sparc64.
>>
>> --8<--
>> creating /tmp/tmpKcZ0cd/tmp
>> creating /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd
>> compile options: '-I/usr/local/include -I/usr/include -c'
>> cc: /tmp/tmpKcZ0cd/source.c
>> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lcblas -o
>> /tmp/tmpKcZ0cd/a.out
>> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztbsv_'
>> /usr/local/lib/libcblas.so.1.0: undefined reference to `dasum_'
>>
>> [...]
>>
>> /usr/local/lib/libcblas.so.1.0: undefined reference to `zsymm_'
>> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztrsm_'
>> /usr/local/lib/libcblas.so.1.0: undefined reference to `sswap_'
>> collect2: error: ld returned 1 exit status
>> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lblas -o
>> /tmp/tmpKcZ0cd/a.out
>> /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o: In function `main':
>> source.c:(.text.startup+0xdc): undefined reference to `cblas_ddot'
>> collect2: error: ld returned 1 exit status
>> -->8--
>>
>> libcblas.so doesn't depend on libblas.so so missing symbols are to be
>> expected if one links with -lcblas instead of -lcblas -lblas. The
>> second linking test fails because libblas.so doesn't provide cblas
>> symbols.
>
> Thanks, this makes sense. But why does this work with ld.lld?
ld.lld doesn't bother checking that all symbols in libcblas.so can be
resolved, ld.bfd does. This means that if you link against a library
that references a bogus symbol or lacks some library interdependency
(DT_NEEDED) you only get a crash at run time.
On amd64, using the testcase from numpy:
--8<--
russell /tmp$ cat r.c
#include
int main(int argc, const char *argv[])
{
double a[4] = {1,2,3,4};
double b[4] = {5,6,7,8};
return cblas_ddot(4, a, 1, b, 1) > 10;
}
russell /tmp$ cc -I/usr/local/include r.c -L/usr/local/lib -lcblas
russell /tmp$ ./a.out
a.out:/usr/local/lib/libcblas.so.1.0: undefined symbol 'ddot_'
ld.so: a.out: lazy binding failed!
Killed
-->8--
I suspect Stuart hit a similar problem with this numpy update and scipy.
Using -fuse-ld=bfd in the testcase above would result in the same errors
as in your log.
>>
>> I think the way forward is to make libcblas.so depend on libblas.so
>> (this is what you get eg on Debian). It would probably make sense to do
>> the same with lapack.
>>
>> With the following cblas diff I can build py-numpy-1.16.5 on amd64 and
>> sparc64. cc'ing Steven.
>>
>> ok?
>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/math/cblas/Makefile,v
>> retrieving revision 1.20
>> diff -u -p -r1.20 Makefile
>> --- Makefile 12 Jul 2019 20:47:40 - 1.20
>> +++ Makefile 10 Mar 2020 16:53:46 -
>> @@ -5,8 +5,8 @@ COMMENT= C interface to the BLAS library
>> VERSION=1.0
>> DISTNAME= cblas
>> PKGNAME=${DISTNAME}-${VERSION}
>> -REVISION= 6
>> -SHARED_LIBS=cblas 1.0
>> +REVISION= 7
>> +SHARED_LIBS=cblas 1.1
>>
>> CATEGORIES= math
>>
>> Index: files/Makefile
>> ===
>> RCS file: /cvs/ports/math/cblas/files/Makefile,v
>> retrieving revision 1.1.1.1
>> diff -u -p -r1.1.1.1 Makefile
>> --- files/Makefile 2 Oct 2006 21:58:25 - 1.1.1.1
>> +++ files/Makefile 10 Mar 2020 16:53:46 -
>> @@ -42,5 +42,6 @@ cblas_dgemm.c cblas_sdsdot.c
>> cblas_dgemv.c cblas_sgbmv.c cblas_zhemv.c \
>> cblas_dger.ccblas_sgemm.c cblas_zher.c \
>> cblas_dnrm2.c cblas_sgemv.c cblas_zher2.c
>> +LDADD=-lblas -lgfortran
>>
>> .include
>> Index: pkg/PLIST
>> ===
>> RCS file: /cvs/ports/math/cblas/pkg/PLIST,v
>> retrieving revision 1.4
>> diff -u -p -r1.4 PLIST
>> --- pkg/PLIST16 Mar 2015 18:07:49 - 1.4
>> +++ pkg/PLIST10 Mar 2020 16:53:46 -
>> @@ -1,6 +1,6 @@
>> @comment $OpenBSD: PLIST,v 1.4 2015/03/16 18:07:49 naddy Exp $
>> include/cblas.h
>> include/cblas_f77.h
>> -lib/libcblas.a
>> +@static-lib lib/libcblas.a
>
Re: NEW: x11/tigervnc
On Tue, Mar 10, 2020 at 07:17:54PM -0600, Tracey Emery wrote: > On Tue, Mar 10, 2020 at 10:38:48PM +, Stuart Henderson wrote: > > ok to import this? > > > > --- > > TigerVNC is a high-performance, platform-neutral implementation of VNC > > (Virtual Network Computing), a client/server application that allows > > users to launch and interact with graphical applications on remote > > machines. > > > > TigerVNC provides the levels of performance necessary to run 3D and > > video applications, and it attempts to maintain a common look and feel > > and re-use components, where possible, across the various platforms > > that it supports. TigerVNC also provides extensions for advanced > > authentication methods and TLS encryption. > > > > This package provides TigerVNC's viewer and "x0vncserver", which shares > > an existing X server (typically, one that is connected to a physical > > screen) with viewers on the network. > > --- > > > > (tigervnc also offers Xvnc, a standalone X server, but as this requires > > sources for Xserver it's rather more complicated to build in ports, > > and in many cases x0vncserver is exactly what you want - it's a greatly > > improved alternative to ports/x11/x11vnc). > > > > Builds, reads, and runs fine here, although I don't have a local VNC > server to test against tonight. > > I'll offer an ok for the port :D > > -- > > Tracey Emery Ok, works fine. Connected to the wife's Mac. -- Tracey Emery
Re: NEW: x11/tigervnc
On Tue, Mar 10, 2020 at 10:38:48PM +, Stuart Henderson wrote: > ok to import this? > > --- > TigerVNC is a high-performance, platform-neutral implementation of VNC > (Virtual Network Computing), a client/server application that allows > users to launch and interact with graphical applications on remote > machines. > > TigerVNC provides the levels of performance necessary to run 3D and > video applications, and it attempts to maintain a common look and feel > and re-use components, where possible, across the various platforms > that it supports. TigerVNC also provides extensions for advanced > authentication methods and TLS encryption. > > This package provides TigerVNC's viewer and "x0vncserver", which shares > an existing X server (typically, one that is connected to a physical > screen) with viewers on the network. > --- > > (tigervnc also offers Xvnc, a standalone X server, but as this requires > sources for Xserver it's rather more complicated to build in ports, > and in many cases x0vncserver is exactly what you want - it's a greatly > improved alternative to ports/x11/x11vnc). > Builds, reads, and runs fine here, although I don't have a local VNC server to test against tonight. I'll offer an ok for the port :D -- Tracey Emery
fix print/scribus with poppler-0.86
Hi,
this fixes the build of print/scribus against puppler-0.86. Ugly,
but what can I do (it's what I found in upstreams svn repository)?
Survived a build on amd64, and i also successfully imported a PDF
(as image) and exported the result back to PDF.
If i don't get any complaints, i'll just put this in in a day or two,
together with the poppler update.
Ciao,
Kili
Index: patches/patch-scribus_plugins_import_pdf_importpdf_cpp
===
RCS file:
/cvs/ports/print/scribus/patches/patch-scribus_plugins_import_pdf_importpdf_cpp,v
retrieving revision 1.1
diff -u -p -r1.1 patch-scribus_plugins_import_pdf_importpdf_cpp
--- patches/patch-scribus_plugins_import_pdf_importpdf_cpp 19 Feb 2020
12:15:45 - 1.1
+++ patches/patch-scribus_plugins_import_pdf_importpdf_cpp 10 Mar 2020
22:12:35 -
@@ -2,6 +2,8 @@ $OpenBSD: patch-scribus_plugins_import_p
Fix build with newer poppler, from archlinux
+Fix for poppler-0.86.x from svn r23478.
+
Index: scribus/plugins/import/pdf/importpdf.cpp
--- scribus/plugins/import/pdf/importpdf.cpp.orig
+++ scribus/plugins/import/pdf/importpdf.cpp
@@ -75,7 +77,29 @@ Index: scribus/plugins/import/pdf/import
return false;
}
pageString = optImp->getPagesString();
-@@ -908,8 +926,12 @@ bool PdfPlug::convert(const QString& fn)
+@@ -838,11 +856,20 @@ bool PdfPlug::convert(const QString& fn)
+ names =
catDict.dictLookup("OpenAction");
+ if
(names.isDict())
+ {
++#if POPPLER_ENCODED_VERSION >= POPPLER_VERSION_ENCODE(0, 86, 0)
++
std::unique_ptr linkAction;
++
linkAction = LinkAction::parseAction(&names,
pdfDoc->getCatalog()->getBaseURI());
++#else
+
LinkAction *linkAction = nullptr;
+
linkAction = LinkAction::parseAction(&names,
pdfDoc->getCatalog()->getBaseURI());
++#endif
+ if
(linkAction)
+ {
+-
LinkJavaScript *jsa = (LinkJavaScript*)linkAction;
++#if POPPLER_ENCODED_VERSION >= POPPLER_VERSION_ENCODE(0, 86, 0)
++
LinkJavaScript *jsa = (LinkJavaScript*) linkAction.get();
++#else
++
LinkJavaScript *jsa = (LinkJavaScript*) linkAction;
++#endif
+
if (jsa->isOk())
+
{
+
QString script = UnicodeParsedString(jsa->getScript());
+@@ -908,8 +935,12 @@ bool PdfPlug::convert(const QString& fn)
}
delete pdfDoc;
}
@@ -88,3 +112,50 @@ Index: scribus/plugins/import/pdf/import
//qDebug() << "converting finished";
//qDebug() << "Imported" << Elements.count() << "Elements";
+@@ -1037,6 +1068,46 @@ QString PdfPlug::UnicodeParsedString(POPPLER_CONST Goo
+ else
+ {
+ u = s1->getChar(i) & 0xff;
++ ++i;
++ }
++ // #15616: imagemagick may write unicode strings incorrectly in
PDF
++ if (u == 0)
++ continue;
++ result += QChar( u );
++ }
++ return result;
++}
++
++QString PdfPlug::UnicodeParsedString(const std::string& s1)
++{
++ if (s1.length() == 0)
++ return QString();
++ GBool isUnicode;
++ int i;
++ Unicode u;
++ QString result;
++ if ((s1.at(0) & 0xff) == 0xfe && (s1.length() > 1 && (s1.at(1) & 0xff)
== 0xff))
++ {
++ isUnicode = gTrue;
++ i = 2;
++ result.reserve((s1.length() - 2) / 2);
++ }
++ else
++ {
++ isUnicode = gFalse;
++ i = 0;
++ result.reserve(s1.length());
++ }
++ while (i < s1.length())
++ {
++ if (isUnicode)
++ {
++ u = ((s1.at(i) & 0xff) << 8) | (s1.at(i+1) & 0xff);
++ i += 2;
++ }
++ else
++ {
++ u = s1.at(i) & 0xff;
+
NEW: x11/tigervnc
ok to import this? --- TigerVNC is a high-performance, platform-neutral implementation of VNC (Virtual Network Computing), a client/server application that allows users to launch and interact with graphical applications on remote machines. TigerVNC provides the levels of performance necessary to run 3D and video applications, and it attempts to maintain a common look and feel and re-use components, where possible, across the various platforms that it supports. TigerVNC also provides extensions for advanced authentication methods and TLS encryption. This package provides TigerVNC's viewer and "x0vncserver", which shares an existing X server (typically, one that is connected to a physical screen) with viewers on the network. --- (tigervnc also offers Xvnc, a standalone X server, but as this requires sources for Xserver it's rather more complicated to build in ports, and in many cases x0vncserver is exactly what you want - it's a greatly improved alternative to ports/x11/x11vnc). tigervnc.tgz Description: application/tar-gz
Re: py-msgpack 1.0.0 upgrade broke salt
I don't have an opinion on how best to fix this, so don't wait on me ;)
On 10 March 2020 21:28:42 CET, Bjorn Ketelaars wrote:
>On Tue 10/03/2020 19:49, Florian Obser wrote:
>> The release notes have
>>
>> * Remove encoding option from the Packer and Unpacker.
>>
>> ( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst
>)
>>
>> $ doas salt-minion
>>
>
>I discussed py-msgpack offlist with another user who needed
>py-msgpack-1.0.0 for an update of a vim plugin. Although the update of
>py-msgpack has been tested this issue has not been seen.
>
>It seems that upstream of salt is still working on a solution [0]. Easy
>fix therefore is to revert py-msgpack to 0.6.2, and bump its consumers.
>Downside of course would be that specific vim plugins will start
>complaining.
>
>I had a look at the consumers of py-msgpack, which we have in ports.
>All of them seem happy with py-msgpack-0.6.2. None of them, except
>net/synapse, received an update recently. synapse relies on
>msgpack>=0.5.2 [1]:
>
> RUN_DEPENDS
>/usr/ports/devel/py-test-expect
>/usr/ports/devel/py-test-expect,python3
>/usr/ports/editors/py-neovim
>/usr/ports/editors/py-neovim,python3
>/usr/ports/net/synapse
>/usr/ports/sysutils/salt
> TEST_DEPENDS
>/usr/ports/editors/py-neovim
>/usr/ports/editors/py-neovim,python3
>/usr/ports/net/synapse
>/usr/ports/sysutils/salt
>
>Different route would be to support two versions of py-msgpack. For now
>I propose to make sure that all ports work, thus revert. I will take a
>look at the alternative route in the near future.
>
>Comments/OK?
>
>[0] https://github.com/saltstack/salt/issues/56007
>[1]
>https://github.com/matrix-org/synapse/blob/master/synapse/python_dependencies.py
>
>
>diff --git devel/py-test-expect/Makefile devel/py-test-expect/Makefile
>index f19faf3d50b..0768ce54782 100644
>--- devel/py-test-expect/Makefile
>+++ devel/py-test-expect/Makefile
>@@ -6,7 +6,7 @@ MODPY_EGG_VERSION =1.1.0
> DISTNAME =pytest-expect-${MODPY_EGG_VERSION}
> PKGNAME = ${DISTNAME:S/py/py-/}
> CATEGORIES = devel
>-REVISION =1
>+REVISION =2
>
> HOMEPAGE =https://github.com/gsnedders/pytest-expect
>
>diff --git editors/py-neovim/Makefile editors/py-neovim/Makefile
>index ef30c889738..185624959d5 100644
>--- editors/py-neovim/Makefile
>+++ editors/py-neovim/Makefile
>@@ -3,6 +3,7 @@
> COMMENT = Python plugin support for Neovim
>
> MODPY_EGG_VERSION = 0.4.0
>+REVISION =0
> DISTNAME =pynvim-${MODPY_EGG_VERSION}
> PKGNAME = py-neovim-${MODPY_EGG_VERSION}
>
>diff --git net/py-msgpack/Makefile net/py-msgpack/Makefile
>index ea82fc3e07a..c06d478b9de 100644
>--- net/py-msgpack/Makefile
>+++ net/py-msgpack/Makefile
>@@ -2,7 +2,8 @@
>
> COMMENT = messagepack (de)serializer
>
>-MODPY_EGG_VERSION = 1.0.0
>+MODPY_EGG_VERSION = 0.6.2
>+EPOCH = 0
> DISTNAME =msgpack-${MODPY_EGG_VERSION}
> PKGNAME = py-msgpack-${MODPY_EGG_VERSION}
>
>diff --git net/py-msgpack/distinfo net/py-msgpack/distinfo
>index 5ec380d7403..8d9bdadf9d3 100644
>--- net/py-msgpack/distinfo
>+++ net/py-msgpack/distinfo
>@@ -1,2 +1,2 @@
>-SHA256 (msgpack-1.0.0.tar.gz) =
>lTTVzEgNSv9yAjNBGh92W+kIhXULB993I4CzTBDstcA=
>-SIZE (msgpack-1.0.0.tar.gz) = 232331
>+SHA256 (msgpack-0.6.2.tar.gz) =
>6jwvhZNG/NVfxG6WiFMB2cL3o21FP12PKWeEDvoeGDA=
>+SIZE (msgpack-0.6.2.tar.gz) = 119062
>diff --git net/py-msgpack/pkg/PLIST net/py-msgpack/pkg/PLIST
>index 7d948a0df47..2f24d170108 100644
>--- net/py-msgpack/pkg/PLIST
>+++ net/py-msgpack/pkg/PLIST
>@@ -10,10 +10,8 @@
>${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
>-lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}ext.${MODPY_PYC_MAGIC_TAG}pyc
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}fallback.${MODPY_PYC_MAGIC_TAG}pyc
>-${MODPY_COMMENT}@so
>lib/python${MODPY_VERSION}/site-packages/msgpack/_cmsgpack.so
>+@so lib/python${MODPY_VERSION}/site-packages/msgpack/_cmsgpack.so
> lib/python${MODPY_VERSION}/site-packages/msgpack/_version.py
> lib/python${MODPY_VERSION}/site-packages/msgpack/exceptions.py
>-lib/python${MODPY_VERSION}/site-packages/msgpack/ext.py
> lib/python${MODPY_VERSION}/site-packages/msgpack/fallback.py
>diff --git net/synapse/Makefile net/synapse/Makefile
>index dd2b881637b..b9a8cb8416a 100644
>--- net/synapse/Makefile
>+++ net/synapse/Makefile
>@@ -3,6 +3,7 @@
> COMMENT = open network for secure, decentralized communication
>
> MODPY_EGG_VERSION = 1.11.1
>+REVISION =0
>
> GH_ACCOUNT = matrix-org
> GH_PROJE
Re: py-msgpack 1.0.0 upgrade broke salt
On Tue 10/03/2020 19:49, Florian Obser wrote:
> The release notes have
>
> * Remove encoding option from the Packer and Unpacker.
>
> ( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst )
>
> $ doas salt-minion
>
I discussed py-msgpack offlist with another user who needed
py-msgpack-1.0.0 for an update of a vim plugin. Although the update of
py-msgpack has been tested this issue has not been seen.
It seems that upstream of salt is still working on a solution [0]. Easy
fix therefore is to revert py-msgpack to 0.6.2, and bump its consumers.
Downside of course would be that specific vim plugins will start
complaining.
I had a look at the consumers of py-msgpack, which we have in ports.
All of them seem happy with py-msgpack-0.6.2. None of them, except
net/synapse, received an update recently. synapse relies on
msgpack>=0.5.2 [1]:
RUN_DEPENDS
/usr/ports/devel/py-test-expect
/usr/ports/devel/py-test-expect,python3
/usr/ports/editors/py-neovim
/usr/ports/editors/py-neovim,python3
/usr/ports/net/synapse
/usr/ports/sysutils/salt
TEST_DEPENDS
/usr/ports/editors/py-neovim
/usr/ports/editors/py-neovim,python3
/usr/ports/net/synapse
/usr/ports/sysutils/salt
Different route would be to support two versions of py-msgpack. For now
I propose to make sure that all ports work, thus revert. I will take a
look at the alternative route in the near future.
Comments/OK?
[0] https://github.com/saltstack/salt/issues/56007
[1]
https://github.com/matrix-org/synapse/blob/master/synapse/python_dependencies.py
diff --git devel/py-test-expect/Makefile devel/py-test-expect/Makefile
index f19faf3d50b..0768ce54782 100644
--- devel/py-test-expect/Makefile
+++ devel/py-test-expect/Makefile
@@ -6,7 +6,7 @@ MODPY_EGG_VERSION = 1.1.0
DISTNAME = pytest-expect-${MODPY_EGG_VERSION}
PKGNAME = ${DISTNAME:S/py/py-/}
CATEGORIES = devel
-REVISION = 1
+REVISION = 2
HOMEPAGE = https://github.com/gsnedders/pytest-expect
diff --git editors/py-neovim/Makefile editors/py-neovim/Makefile
index ef30c889738..185624959d5 100644
--- editors/py-neovim/Makefile
+++ editors/py-neovim/Makefile
@@ -3,6 +3,7 @@
COMMENT = Python plugin support for Neovim
MODPY_EGG_VERSION =0.4.0
+REVISION = 0
DISTNAME = pynvim-${MODPY_EGG_VERSION}
PKGNAME = py-neovim-${MODPY_EGG_VERSION}
diff --git net/py-msgpack/Makefile net/py-msgpack/Makefile
index ea82fc3e07a..c06d478b9de 100644
--- net/py-msgpack/Makefile
+++ net/py-msgpack/Makefile
@@ -2,7 +2,8 @@
COMMENT = messagepack (de)serializer
-MODPY_EGG_VERSION =1.0.0
+MODPY_EGG_VERSION =0.6.2
+EPOCH =0
DISTNAME = msgpack-${MODPY_EGG_VERSION}
PKGNAME = py-msgpack-${MODPY_EGG_VERSION}
diff --git net/py-msgpack/distinfo net/py-msgpack/distinfo
index 5ec380d7403..8d9bdadf9d3 100644
--- net/py-msgpack/distinfo
+++ net/py-msgpack/distinfo
@@ -1,2 +1,2 @@
-SHA256 (msgpack-1.0.0.tar.gz) = lTTVzEgNSv9yAjNBGh92W+kIhXULB993I4CzTBDstcA=
-SIZE (msgpack-1.0.0.tar.gz) = 232331
+SHA256 (msgpack-0.6.2.tar.gz) = 6jwvhZNG/NVfxG6WiFMB2cL3o21FP12PKWeEDvoeGDA=
+SIZE (msgpack-0.6.2.tar.gz) = 119062
diff --git net/py-msgpack/pkg/PLIST net/py-msgpack/pkg/PLIST
index 7d948a0df47..2f24d170108 100644
--- net/py-msgpack/pkg/PLIST
+++ net/py-msgpack/pkg/PLIST
@@ -10,10 +10,8 @@
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE
lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}ext.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}fallback.${MODPY_PYC_MAGIC_TAG}pyc
-${MODPY_COMMENT}@so
lib/python${MODPY_VERSION}/site-packages/msgpack/_cmsgpack.so
+@so lib/python${MODPY_VERSION}/site-packages/msgpack/_cmsgpack.so
lib/python${MODPY_VERSION}/site-packages/msgpack/_version.py
lib/python${MODPY_VERSION}/site-packages/msgpack/exceptions.py
-lib/python${MODPY_VERSION}/site-packages/msgpack/ext.py
lib/python${MODPY_VERSION}/site-packages/msgpack/fallback.py
diff --git net/synapse/Makefile net/synapse/Makefile
index dd2b881637b..b9a8cb8416a 100644
--- net/synapse/Makefile
+++ net/synapse/Makefile
@@ -3,6 +3,7 @@
COMMENT = open network for secure, decentralized communication
MODPY_EGG_VERSION =1.11.1
+REVISION = 0
GH_ACCOUNT = matrix-org
GH_PROJECT = synapse
diff --git sysutils/salt/Makefile sysutils/salt/Makefile
index 5129c2a60ad..74117bfa890 100644
--- sysutils/salt/Makefile
+++ sysutils/salt/Makefile
@@ -19,7 +19,7 @@ COMMENT = remote execution and
Re: py-msgpack 1.0.0 upgrade broke salt
...but there might be other problems
https://github.com/saltstack/salt/issues/56007
--
Sent from a phone, apologies for poor formatting.
On 10 March 2020 20:16:39 Stuart Henderson wrote:
Looks like this was fixed in salt 2019.2.1.
--
Sent from a phone, apologies for poor formatting.
On 10 March 2020 18:50:07 Florian Obser wrote:
The release notes have
* Remove encoding option from the Packer and Unpacker.
( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst )
$ doas salt-minion
Process Process-1:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/multiprocessing/process.py", line 267, in
_bootstrap
self.run()
File "/usr/local/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python2.7/site-packages/salt/scripts.py", line 146, in
minion_process
minion.start()
File "/usr/local/lib/python2.7/site-packages/salt/cli/daemons.py", line
348, in start
self.minion.tune_in()
File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 1026, in
tune_in
self._bind()
File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 940, in
_bind
self.event = salt.utils.event.get_event('minion', opts=self.opts,
io_loop=self.io_loop)
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line
143, in get_event
raise_errors=raise_errors)
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line
271, in __init__
self.connect_pub()
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line
383, in connect_pub
io_loop=self.io_loop
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
257, in __new__
client.__singleton_init__(io_loop=io_loop, socket_path=socket_path)
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
620, in __singleton_init__
socket_path, io_loop=io_loop)
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
280, in __singleton_init__
self.unpacker = msgpack.Unpacker(encoding=encoding)
TypeError: __init__() got an unexpected keyword argument 'encoding'
Thanks,
Florian
--
I'm not entirely sure you are real.
Re: py-msgpack 1.0.0 upgrade broke salt
Looks like this was fixed in salt 2019.2.1.
--
Sent from a phone, apologies for poor formatting.
On 10 March 2020 18:50:07 Florian Obser wrote:
The release notes have
* Remove encoding option from the Packer and Unpacker.
( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst )
$ doas salt-minion
Process Process-1:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/multiprocessing/process.py", line 267, in
_bootstrap
self.run()
File "/usr/local/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python2.7/site-packages/salt/scripts.py", line 146, in
minion_process
minion.start()
File "/usr/local/lib/python2.7/site-packages/salt/cli/daemons.py", line
348, in start
self.minion.tune_in()
File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 1026, in
tune_in
self._bind()
File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 940, in
_bind
self.event = salt.utils.event.get_event('minion', opts=self.opts,
io_loop=self.io_loop)
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line
143, in get_event
raise_errors=raise_errors)
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line
271, in __init__
self.connect_pub()
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line
383, in connect_pub
io_loop=self.io_loop
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
257, in __new__
client.__singleton_init__(io_loop=io_loop, socket_path=socket_path)
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
620, in __singleton_init__
socket_path, io_loop=io_loop)
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
280, in __singleton_init__
self.unpacker = msgpack.Unpacker(encoding=encoding)
TypeError: __init__() got an unexpected keyword argument 'encoding'
Thanks,
Florian
--
I'm not entirely sure you are real.
games/supertuxcart add Gamepad/Joystick support
Hi,
attached patch switches the backend from LinuxX11 to SDL, and enables joystick
support.
With the LinuxX11 backend, it's not possible to enable Joystick/Gamepad
support, since it
relies on Linuxism (include linux/joystick.h etc.)
Switching to SDL backend, allows me to play with two GamePads Logitech F310 to
have
a nice race against each other.
comments, tests, yay, nay, or even OK welcome ;)
cheers,
Sebastian
Index: Makefile
===
RCS file: /cvs/ports/games/supertuxkart/Makefile,v
retrieving revision 1.29
diff -u -r1.29 Makefile
--- Makefile12 Jul 2019 20:46:25 - 1.29
+++ Makefile10 Mar 2020 19:46:59 -
@@ -8,7 +8,7 @@
BASENAME = supertuxkart-${V}
DISTNAME = ${BASENAME}-src
PKGNAME = ${BASENAME}
-REVISION = 0
+REVISION = 1
CATEGORIES = games
@@ -20,7 +20,7 @@
PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} GL X11 Xrandr c curl freetype jpeg
-WANTLIB += m ogg openal png vorbis vorbisenc vorbisfile z
+WANTLIB += m ogg openal png vorbis vorbisenc vorbisfile z SDL
MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=supertuxkart/SuperTuxKart/}
EXTRACT_SUFX = .tar.xz
@@ -31,6 +31,7 @@
RUN_DEPENDS = devel/desktop-file-utils
LIB_DEPENDS = audio/openal>=0.0.8p7 \
audio/libvorbis \
+ devel/sdl \
net/curl \
graphics/png \
graphics/jpeg
Index: patches/patch-CMakeLists_txt
===
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-CMakeLists_txt10 Mar 2020 19:46:59 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
CMakeLists.txt
+@@ -416,6 +416,7 @@ target_link_libraries(supertuxkart
+ ${JPEG_LIBRARIES}
+ ${TURBOJPEG_LIBRARY}
+ #${VPX_LIBRARIES}
++SDL
+ )
+
+ if(NOT SERVER_ONLY)
Index: patches/patch-lib_irrlicht_CMakeLists_txt
===
RCS file:
/cvs/ports/games/supertuxkart/patches/patch-lib_irrlicht_CMakeLists_txt,v
retrieving revision 1.4
diff -u -r1.4 patch-lib_irrlicht_CMakeLists_txt
--- patches/patch-lib_irrlicht_CMakeLists_txt 27 Nov 2017 15:45:19 -
1.4
+++ patches/patch-lib_irrlicht_CMakeLists_txt 10 Mar 2020 19:46:59 -
@@ -13,12 +13,3 @@
if(CMAKE_COMPILER_IS_GNUCC)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fexpensive-optimizations")
endif()
-@@ -86,7 +86,7 @@ if(USE_GLES2)
- add_definitions(-D_IRR_COMPILE_WITH_OGLES2_ -DNO_IRR_COMPILE_WITH_OPENGL_)
- endif()
-
--if(CYGWIN)
-+if(NOT LINUX)
- add_definitions(-DNO_IRR_COMPILE_WITH_JOYSTICK_EVENTS_)
- endif()
-
Index: patches/patch-lib_irrlicht_include_IrrCompileConfig_h
===
RCS file: patches/patch-lib_irrlicht_include_IrrCompileConfig_h
diff -N patches/patch-lib_irrlicht_include_IrrCompileConfig_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_irrlicht_include_IrrCompileConfig_h 10 Mar 2020
19:46:59 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+We want Joystick events, so have to use
+SDL instead of X11 backend for Irrlicht
+
+Index: lib/irrlicht/include/IrrCompileConfig.h
+--- lib/irrlicht/include/IrrCompileConfig.h.orig
lib/irrlicht/include/IrrCompileConfig.h
+@@ -44,7 +44,7 @@
+
+
+ //! Uncomment this line to compile with the SDL device
+-//#define _IRR_COMPILE_WITH_SDL_DEVICE_
++#define _IRR_COMPILE_WITH_SDL_DEVICE_
+ #ifdef NO_IRR_COMPILE_WITH_SDL_DEVICE_
+ #undef _IRR_COMPILE_WITH_SDL_DEVICE_
+ #endif
+@@ -111,7 +111,7 @@
+ #define _IRR_LINUX_PLATFORM_
+ #endif
+ #define _IRR_POSIX_API_
+-#define _IRR_COMPILE_WITH_X11_DEVICE_
++//#define _IRR_COMPILE_WITH_X11_DEVICE_
+ //#define _IRR_COMPILE_WITH_WAYLAND_DEVICE_
+ #endif
+
Index: patches/patch-lib_irrlicht_source_Irrlicht_CIrrDeviceSDL_cpp
===
RCS file: patches/patch-lib_irrlicht_source_Irrlicht_CIrrDeviceSDL_cpp
diff -N patches/patch-lib_irrlicht_source_Irrlicht_CIrrDeviceSDL_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_irrlicht_source_Irrlicht_CIrrDeviceSDL_cpp10 Mar
2020 19:46:59 -
@@ -0,0 +1,85 @@
+$OpenBSD$
+
+Index: lib/irrlicht/source/Irrlicht/CIrrDeviceSDL.cpp
+--- lib/irrlicht/source/Irrlicht/CIrrDeviceSDL.cpp.orig
lib/irrlicht/source/Irrlicht/CIrrDeviceSDL.cpp
+@@ -884,43 +884,43 @@ void CIrrDeviceSDL::createKeyMap()
+ KeyMap.push_back(SKeyMap(SDLK_DELETE, IRR_KEY_DELETE));
+ KeyMap.push_back(SKeyMap(SDLK_HELP, IRR_KEY_HELP));
+
+- KeyMap.push_back(SKeyMap(SDLK_0, IRR_KEY_IRR_KEY_0));
+- KeyMap.push_back(SKeyMap(SDLK_1, IRR_KEY_IRR_KEY_1));
+- KeyMap.
py-msgpack 1.0.0 upgrade broke salt
The release notes have
* Remove encoding option from the Packer and Unpacker.
( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst )
$ doas salt-minion
Process Process-1:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/multiprocessing/process.py", line 267, in
_bootstrap
self.run()
File "/usr/local/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python2.7/site-packages/salt/scripts.py", line 146, in
minion_process
minion.start()
File "/usr/local/lib/python2.7/site-packages/salt/cli/daemons.py", line 348,
in start
self.minion.tune_in()
File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 1026, in
tune_in
self._bind()
File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 940, in
_bind
self.event = salt.utils.event.get_event('minion', opts=self.opts,
io_loop=self.io_loop)
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line 143,
in get_event
raise_errors=raise_errors)
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line 271,
in __init__
self.connect_pub()
File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line 383,
in connect_pub
io_loop=self.io_loop
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
257, in __new__
client.__singleton_init__(io_loop=io_loop, socket_path=socket_path)
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
620, in __singleton_init__
socket_path, io_loop=io_loop)
File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line
280, in __singleton_init__
self.unpacker = msgpack.Unpacker(encoding=encoding)
TypeError: __init__() got an unexpected keyword argument 'encoding'
Thanks,
Florian
--
I'm not entirely sure you are real.
Re: WIP: Update of math/py-numpy to 1.16.5
On Tue, Mar 10, 2020 at 06:35:04PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Mar 09 2020, Stuart Henderson wrote:
> > 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.
>
> I managed to build scipy with no changes on amd64, so I'm not sure what
> the problem is on this arch (did not try with USE_LLD=No).
>
> However I took a look at the issue reported by tb on sparc64.
>
> --8<--
> creating /tmp/tmpKcZ0cd/tmp
> creating /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd
> compile options: '-I/usr/local/include -I/usr/include -c'
> cc: /tmp/tmpKcZ0cd/source.c
> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lcblas -o
> /tmp/tmpKcZ0cd/a.out
> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztbsv_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `dasum_'
>
> [...]
>
> /usr/local/lib/libcblas.so.1.0: undefined reference to `zsymm_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztrsm_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `sswap_'
> collect2: error: ld returned 1 exit status
> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lblas -o
> /tmp/tmpKcZ0cd/a.out
> /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o: In function `main':
> source.c:(.text.startup+0xdc): undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
> -->8--
>
> libcblas.so doesn't depend on libblas.so so missing symbols are to be
> expected if one links with -lcblas instead of -lcblas -lblas. The
> second linking test fails because libblas.so doesn't provide cblas
> symbols.
Thanks, this makes sense. But why does this work with ld.lld?
>
> I think the way forward is to make libcblas.so depend on libblas.so
> (this is what you get eg on Debian). It would probably make sense to do
> the same with lapack.
>
> With the following cblas diff I can build py-numpy-1.16.5 on amd64 and
> sparc64. cc'ing Steven.
>
> ok?
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/math/cblas/Makefile,v
> retrieving revision 1.20
> diff -u -p -r1.20 Makefile
> --- Makefile 12 Jul 2019 20:47:40 - 1.20
> +++ Makefile 10 Mar 2020 16:53:46 -
> @@ -5,8 +5,8 @@ COMMENT= C interface to the BLAS library
> VERSION= 1.0
> DISTNAME=cblas
> PKGNAME= ${DISTNAME}-${VERSION}
> -REVISION=6
> -SHARED_LIBS= cblas 1.0
> +REVISION=7
> +SHARED_LIBS= cblas 1.1
>
> CATEGORIES= math
>
> Index: files/Makefile
> ===
> RCS file: /cvs/ports/math/cblas/files/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- files/Makefile2 Oct 2006 21:58:25 - 1.1.1.1
> +++ files/Makefile10 Mar 2020 16:53:46 -
> @@ -42,5 +42,6 @@ cblas_dgemm.c cblas_sdsdot.c
> cblas_dgemv.c cblas_sgbmv.c cblas_zhemv.c \
> cblas_dger.ccblas_sgemm.c cblas_zher.c \
> cblas_dnrm2.c cblas_sgemv.c cblas_zher2.c
> +LDADD=-lblas -lgfortran
>
> .include
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/math/cblas/pkg/PLIST,v
> retrieving revision 1.4
> diff -u -p -r1.4 PLIST
> --- pkg/PLIST 16 Mar 2015 18:07:49 - 1.4
> +++ pkg/PLIST 10 Mar 2020 16:53:46 -
> @@ -1,6 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.4 2015/03/16 18:07:49 naddy Exp $
> include/cblas.h
> include/cblas_f77.h
> -lib/libcblas.a
> +@static-lib lib/libcblas.a
> @lib lib/libcblas.so.${LIBcblas_VERSION}
> -lib/libcblas_p.a
> +@static-lib lib/libcblas_p.a
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
Re: WIP: Update of math/py-numpy to 1.16.5
On Tue, Mar 10 2020, Jeremie Courreges-Anglas wrote:
> On Mon, Mar 09 2020, Stuart Henderson wrote:
>> 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.
>
> I managed to build scipy with no changes on amd64, so I'm not sure what
> the problem is on this arch (did not try with USE_LLD=No).
>
> However I took a look at the issue reported by tb on sparc64.
>
> --8<--
> creating /tmp/tmpKcZ0cd/tmp
> creating /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd
> compile options: '-I/usr/local/include -I/usr/include -c'
> cc: /tmp/tmpKcZ0cd/source.c
> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lcblas -o
> /tmp/tmpKcZ0cd/a.out
> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztbsv_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `dasum_'
>
> [...]
>
> /usr/local/lib/libcblas.so.1.0: undefined reference to `zsymm_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztrsm_'
> /usr/local/lib/libcblas.so.1.0: undefined reference to `sswap_'
> collect2: error: ld returned 1 exit status
> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lblas -o
> /tmp/tmpKcZ0cd/a.out
> /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o: In function `main':
> source.c:(.text.startup+0xdc): undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
> -->8--
>
> libcblas.so doesn't depend on libblas.so so missing symbols are to be
> expected if one links with -lcblas instead of -lcblas -lblas. The
> second linking test fails because libblas.so doesn't provide cblas
> symbols.
>
> I think the way forward is to make libcblas.so depend on libblas.so
> (this is what you get eg on Debian). It would probably make sense to do
> the same with lapack.
>
> With the following cblas diff I can build py-numpy-1.16.5 on amd64 and
> sparc64. cc'ing Steven.
>
> ok?
Here's an updated diff for numpy-1.16.5, for convenience I decided to
drop the hard requirements I had on cblas>=1.1 (WANTLIB) /
math/cblas>=1.0p7 (LIB_DEPENDS).
Index: Makefile
===
RCS file: /cvs/ports/math/py-numpy/Makefile,v
retrieving revision 1.57
diff -u -p -r1.57 Makefile
--- Makefile10 Mar 2020 03:31:45 - 1.57
+++ Makefile10 Mar 2020 17:06:13 -
@@ -2,11 +2,10 @@
COMMENT= fast array and numeric programming library for Python
-MODPY_EGG_VERSION= 1.14.6
+MODPY_EGG_VERSION= 1.16.5
DISTNAME= numpy-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
EXTRACT_SUFX= .zip
-REVISION= 2
CATEGORIES=math devel
@@ -15,7 +14,8 @@ HOMEPAGE= https://www.numpy.org/
# BSD
PERMIT_PACKAGE = Yes
-WANTLIB= blas lapack m pthread ${MODFORTRAN_WANTLIB}
${MODPY_WANTLIB}
+WANTLIB += ${MODFORTRAN_WANTLIB} ${MODPY_WANTLIB}
+WANTLIB += blas cblas lapack m pthread
MODULES= lang/python \
fortran
@@ -27,13 +27,14 @@ MODPY_PI = Yes
MODPY_SETUPTOOLS= Yes
MODPY_DISTUTILS_BUILDARGS = --fcompiler=gnu95
-TEST_DEPENDS= devel/py-nose${MODPY_FLAVOR} \
- devel/py-tz${MODPY_FLAVOR}
-
+TEST_DEPENDS= ${FULLPKGNAME}:${FULLPKGPATH} \
+ devel/py-test${MODPY_FLAVOR} \
+ devel/py-tz${MODPY_FLAVOR}
MODFORTRAN_COMPILER = gfortran
BUILD_DEPENDS = ${MODFORTRAN_BUILD_DEPENDS}
-LIB_DEPENDS=math/lapack \
+LIB_DEPENDS= math/cblas \
+ math/lapack \
${MODFORTRAN_LIB_DEPENDS}
# Cython 0.28.* uses __attribute__((optimize("Os"))) which
Index: distinfo
===
RCS file: /cvs/ports/math/py-numpy/distinfo,v
retrieving revision 1.13
diff -u -p -r1.13 distinfo
--- distinfo26 Oct 2018 21:09:31 - 1.13
+++ distinfo10 Mar 2020 17:06:13 -
@@ -1,2 +1,2 @@
-SHA256 (numpy-1.14.6.zip) = ElDt9vbEPh14I/CWdBa8GCWLsnHcU2KY6w6gCp5FuAo=
-SIZE (numpy-1.14.6.zip) = 4906096
+SHA256 (numpy-1.16.5.zip) = i7RS2U6WSzEiBbDeEjjdcgnaRSNDZTqyFLXWgXgOegw=
+SIZE (numpy-1.16.5.zip) = 5138208
Index: patches/patch-numpy_core_include_numpy_npy_common_h
===
RCS file:
/cvs/ports/math/py-numpy/patches/patch-numpy_core_include_numpy_npy_common_h,v
retrieving revision 1.6
diff -u -p -r1.6 patch-numpy_core_include_numpy_npy_common_h
--- patches/patch-numpy_core_include_numpy_npy_common_h 30 Jun 2018 21:49:33
- 1.6
+++
Re: WIP: Update of math/py-numpy to 1.16.5
On Mon, Mar 09 2020, Stuart Henderson wrote:
> 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.
I managed to build scipy with no changes on amd64, so I'm not sure what
the problem is on this arch (did not try with USE_LLD=No).
However I took a look at the issue reported by tb on sparc64.
--8<--
creating /tmp/tmpKcZ0cd/tmp
creating /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd
compile options: '-I/usr/local/include -I/usr/include -c'
cc: /tmp/tmpKcZ0cd/source.c
cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lcblas -o
/tmp/tmpKcZ0cd/a.out
/usr/local/lib/libcblas.so.1.0: undefined reference to `ztbsv_'
/usr/local/lib/libcblas.so.1.0: undefined reference to `dasum_'
[...]
/usr/local/lib/libcblas.so.1.0: undefined reference to `zsymm_'
/usr/local/lib/libcblas.so.1.0: undefined reference to `ztrsm_'
/usr/local/lib/libcblas.so.1.0: undefined reference to `sswap_'
collect2: error: ld returned 1 exit status
cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lblas -o
/tmp/tmpKcZ0cd/a.out
/tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o: In function `main':
source.c:(.text.startup+0xdc): undefined reference to `cblas_ddot'
collect2: error: ld returned 1 exit status
-->8--
libcblas.so doesn't depend on libblas.so so missing symbols are to be
expected if one links with -lcblas instead of -lcblas -lblas. The
second linking test fails because libblas.so doesn't provide cblas
symbols.
I think the way forward is to make libcblas.so depend on libblas.so
(this is what you get eg on Debian). It would probably make sense to do
the same with lapack.
With the following cblas diff I can build py-numpy-1.16.5 on amd64 and
sparc64. cc'ing Steven.
ok?
Index: Makefile
===
RCS file: /cvs/ports/math/cblas/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile12 Jul 2019 20:47:40 - 1.20
+++ Makefile10 Mar 2020 16:53:46 -
@@ -5,8 +5,8 @@ COMMENT=C interface to the BLAS library
VERSION= 1.0
DISTNAME= cblas
PKGNAME= ${DISTNAME}-${VERSION}
-REVISION= 6
-SHARED_LIBS= cblas 1.0
+REVISION= 7
+SHARED_LIBS= cblas 1.1
CATEGORIES=math
Index: files/Makefile
===
RCS file: /cvs/ports/math/cblas/files/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- files/Makefile 2 Oct 2006 21:58:25 - 1.1.1.1
+++ files/Makefile 10 Mar 2020 16:53:46 -
@@ -42,5 +42,6 @@ cblas_dgemm.c cblas_sdsdot.c
cblas_dgemv.c cblas_sgbmv.c cblas_zhemv.c \
cblas_dger.ccblas_sgemm.c cblas_zher.c \
cblas_dnrm2.c cblas_sgemv.c cblas_zher2.c
+LDADD=-lblas -lgfortran
.include
Index: pkg/PLIST
===
RCS file: /cvs/ports/math/cblas/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 16 Mar 2015 18:07:49 - 1.4
+++ pkg/PLIST 10 Mar 2020 16:53:46 -
@@ -1,6 +1,6 @@
@comment $OpenBSD: PLIST,v 1.4 2015/03/16 18:07:49 naddy Exp $
include/cblas.h
include/cblas_f77.h
-lib/libcblas.a
+@static-lib lib/libcblas.a
@lib lib/libcblas.so.${LIBcblas_VERSION}
-lib/libcblas_p.a
+@static-lib lib/libcblas_p.a
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [new] mautrix-whatsapp 20200225
On 10/03/2020 15:31, Aaron Bieber wrote: On Tue, 10 Mar 2020 at 15:06:38 +0100, Renaud Allard wrote: On 3/10/20 2:01 PM, Renaud Allard wrote: On 3/10/20 1:50 PM, Renaud Allard wrote: Hello, Now that matrix synapse server has been imported into base, we can also import mautrix-whatsapp which is a synapse bridge server for whatsapp. The mirror is on one of my servers since the the original source doesn't provide a vendor folder for this go port. Any comments? Here is is again with some corrections proposed on irc. Sorry for the fast changes, this one should hopefully be the last one. Makefile is more optimized for GO specialities. Here is the makefile with a few more tweaks: - Add "m" to WANTLIB - Remove the TEST_DEPENDS and disable tests I changed the Makefile with what Aaron suggested and made some changes in pkg/README mautrix-whatsapp.tgz Description: GNU Zip compressed data smime.p7s Description: S/MIME Cryptographic Signature
aircrack-ng-1.5.2p2 free(): chunk canary corrupted 0x11a3c50e6c00 0x2ac@0x2ac
It seems malloc problem. aircrack-ng from packages. 6.6-current amd64 setting is: /etc/sysctl.conf vm.malloc_conf=CF Should I set different malloc rule or is it a bug? Martin
Re: [new] mautrix-whatsapp 20200225
On Tue, 10 Mar 2020 at 15:06:38 +0100, Renaud Allard wrote:
>
>
> On 3/10/20 2:01 PM, Renaud Allard wrote:
> >
> >
> > On 3/10/20 1:50 PM, Renaud Allard wrote:
> >> Hello,
> >>
> >> Now that matrix synapse server has been imported into base, we can also
> >> import mautrix-whatsapp which is a synapse bridge server for whatsapp.
> >> The mirror is on one of my servers since the the original source doesn't
> >> provide a vendor folder for this go port.
> >>
> >> Any comments?
> >>
> >
> > Here is is again with some corrections proposed on irc.
> >
> Sorry for the fast changes, this one should hopefully be the last one.
> Makefile is more optimized for GO specialities.
Here is the makefile with a few more tweaks:
- Add "m" to WANTLIB
- Remove the TEST_DEPENDS and disable tests
It might be worth noting the commit that 20200225 corresponds to. Also maybe a
note about the webp.h file and how to roll it into the distfile.
OK abieber@ for the below:
---8<---
# $OpenBSD: Makefile,v 1.6 2017/02/11 22:21:58 danj Exp $
COMMENT = matrix-WhatsApp puppeting bridge
V = 20200225
DISTNAME = mautrix-whatsapp-${V}
CATEGORIES =net
HOMEPAGE = https://github.com/tulir/mautrix-whatsapp
MAINTAINER =Renaud Allard
WANTLIB += c m pthread
MASTER_SITES = https://elendil.arnor.org/OpenBSD/
# GNU Affero General Public License v3.0
PERMIT_PACKAGE =Yes
MODULES = lang/go
ALL_TARGET =maunium.net/go/mautrix-whatsapp
NO_TESTS = Yes
do-install:
${INSTALL_PROGRAM} ${MODGO_WORKSPACE}/bin/mautrix-whatsapp \
${PREFIX}/bin
${INSTALL_DATA_DIR} \
${PREFIX}/share/examples/mautrix-whatsapp
${INSTALL_DATA} ${WRKSRC}/example-config.yaml \
${PREFIX}/share/examples/mautrix-whatsapp
.include
--->8---
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
(No Subject)
subscribe
Re: [new] mautrix-whatsapp 20200225
On 3/10/20 2:01 PM, Renaud Allard wrote: > > > On 3/10/20 1:50 PM, Renaud Allard wrote: >> Hello, >> >> Now that matrix synapse server has been imported into base, we can also >> import mautrix-whatsapp which is a synapse bridge server for whatsapp. >> The mirror is on one of my servers since the the original source doesn't >> provide a vendor folder for this go port. >> >> Any comments? >> > > Here is is again with some corrections proposed on irc. > Sorry for the fast changes, this one should hopefully be the last one. Makefile is more optimized for GO specialities. mautrix-whatsapp.tgz Description: application/compressed-tar smime.p7s Description: S/MIME Cryptographic Signature
subscribe
subscribe
Re: [new] mautrix-whatsapp 20200225
On 3/10/20 1:50 PM, Renaud Allard wrote: > Hello, > > Now that matrix synapse server has been imported into base, we can also > import mautrix-whatsapp which is a synapse bridge server for whatsapp. > The mirror is on one of my servers since the the original source doesn't > provide a vendor folder for this go port. > > Any comments? > Here is is again with some corrections proposed on irc. mautrix-whatsapp.tgz Description: application/compressed-tar smime.p7s Description: S/MIME Cryptographic Signature
[new] mautrix-whatsapp 20200225
Hello, Now that matrix synapse server has been imported into base, we can also import mautrix-whatsapp which is a synapse bridge server for whatsapp. The mirror is on one of my servers since the the original source doesn't provide a vendor folder for this go port. Any comments? Regards mautrix-whatsapp.tgz Description: application/compressed-tar smime.p7s Description: S/MIME Cryptographic Signature
Re: UPDATE x11/i3-4.18
On Fri, Mar 06, 2020 at 02:14:56PM +0100, Bjorn Ketelaars wrote: > On Fri 06/03/2020 13:09, Florian Viehweger wrote: > > > Comments/OK? Thanks for this update. This works fine on my daily driver, no regression spotted. > > I had to uncomment lines 27 and 31 in the auto-generated config file as > > 'xss-lock' and 'nm-applet' were not found. > > These lines are also present in the example config located in > > '/usr/local/share/examples/i3/config'. > > xss-lock, nm-applet, and pactl (volume key) have been added to the > default config [0]. If I'm not mistaken it should be ok if any > combination of these are not installed, i3 merely tries to start them, > it does not rely on them being there. Default behaviour for us has not > changed. I think this set of examples does not make all that much sense for OpenBSD. Only pactl exists in ports and the volume keys should work out of the box. I'd prefer to patch this away as I don't expect it to be a considerable maintenance burden, but I don't insist. Either way: ok tb
Re: update: www/py-multidict
On Mon, Mar 09 2020, Stuart Henderson wrote:
> 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/PLIST26 Apr 2018 13:05:38 - 1.3
>> > > +++ pkg/PLIST6 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).
Same here, ok jca@ with sthen@'s PLIST tweak.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [UPDATE] ropper et filebytes
On Mon, Mar 09 2020, Paco Esteban wrote: > Hi Remi, > > On Sun, 08 Mar 2020, Remi Pointel wrote: > >> Hi, >> >> these are the diff to update filebytes and ropper to latest releases. >> >> Ok? LGTM and appears to work fine in my tests on amd64, ok jca@ > ropper has no consumers and filebytes only has ropper. I gess those are > perfect candidates to go py3 only, don't you think ? It appears so indeed. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: maintainer update: www/hugo
On Tue, Mar 10 2020, Paco Esteban wrote:
> 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 ?
ok jca@
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/www/hugo/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile 5 Mar 2020 06:16:25 - 1.11
> +++ Makefile 10 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
> --- distinfo 5 Mar 2020 06:16:25 - 1.9
> +++ distinfo 10 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
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
