Re: [update] sbcl-2.0.1
Ping
On Tue, Feb 25, 2020, at 04:47, Josh Elsasser wrote:
> Sorry, I lost track of this. It tested fine for me, I think it should
> go in. It looks like 2.0.2 will be broken for us on powerpc, I'll need
> to convert the assembly to use secure-plt before it will run on openbsd.
>
> On Fri, Jan 31, 2020 at 11:01:01AM +0200, Timo Myyrä wrote:
> > Hi,
> >
> > New attempt at updating sbcl. Tested on amd64 with threads on
> > native_bootstrap
> > and clisp bootstrapped.
> >
> > Timo
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/lang/sbcl/Makefile,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 Makefile
> > --- Makefile16 Sep 2019 06:24:18 - 1.43
> > +++ Makefile31 Jan 2020 08:57:58 -
> > @@ -6,7 +6,7 @@ USE_WXNEEDED = Yes
> >
> > COMMENT= compiler and runtime system for ANSI Common Lisp
> >
> > -V =1.5.5
> > +V =2.0.1
> > DISTNAME= sbcl-${V}-source
> > PKGNAME= sbcl-${V}
> > WRKDIST= ${WRKDIR}/sbcl-${V}
> > @@ -82,6 +82,7 @@ do-install:
> >
> > post-install:
> > chown -R 0:0 ${PREFIX}/lib/sbcl
> > + rmdir ${PREFIX}/share/doc/sbcl/html
> >
> > do-test:
> > cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} DONT_CLEAN_SBCL_CONTRIB=1 \
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/lang/sbcl/distinfo,v
> > retrieving revision 1.18
> > diff -u -p -r1.18 distinfo
> > --- distinfo16 Sep 2019 06:24:18 - 1.18
> > +++ distinfo31 Jan 2020 08:57:58 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (sbcl-1.5.5-source.tar.bz2) =
> > y0f65qhvDFxXQxYE+05fEcioI/lM4SjVaLh3D8W8quI=
> > -SIZE (sbcl-1.5.5-source.tar.bz2) = 6351480
> > +SHA256 (sbcl-2.0.1-source.tar.bz2) =
> > hFDWC3Jko0FY+IEdRtxudP+FW70SJ3Ulcod+ZgTOVug=
> > +SIZE (sbcl-2.0.1-source.tar.bz2) = 6466983
> > Index: patches/patch-src_runtime_GNUmakefile
> > ===
> > RCS file: /cvs/ports/lang/sbcl/patches/patch-src_runtime_GNUmakefile,v
> > retrieving revision 1.8
> > diff -u -p -r1.8 patch-src_runtime_GNUmakefile
> > --- patches/patch-src_runtime_GNUmakefile 8 Mar 2018 15:17:39 -
> > 1.8
> > +++ patches/patch-src_runtime_GNUmakefile 31 Jan 2020 08:57:58 -
> > @@ -2,7 +2,7 @@ $OpenBSD: patch-src_runtime_GNUmakefile,
> > Index: src/runtime/GNUmakefile
> > --- src/runtime/GNUmakefile.orig
> > +++ src/runtime/GNUmakefile
> > -@@ -30,7 +30,7 @@ __LDFLAGS__ =
> > +@@ -34,7 +34,7 @@ __LDFLAGS__ =
> >
> > include ../../output/prefix.def
> >
> > Index: patches/patch-src_runtime_gc-common_c
> > ===
> > RCS file: /cvs/ports/lang/sbcl/patches/patch-src_runtime_gc-common_c,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 patch-src_runtime_gc-common_c
> > --- patches/patch-src_runtime_gc-common_c 8 Mar 2018 15:17:39 -
> > 1.2
> > +++ patches/patch-src_runtime_gc-common_c 31 Jan 2020 08:57:58 -
> > @@ -5,7 +5,7 @@ clang only has it as builtin
> > Index: src/runtime/gc-common.c
> > --- src/runtime/gc-common.c.orig
> > +++ src/runtime/gc-common.c
> > -@@ -55,6 +55,8 @@
> > +@@ -57,6 +57,8 @@
> > #define LONG_FLOAT_SIZE 3
> > #endif
> >
>
>
Re: NEW: x11/tigervnc
On 2020/03/11 23:31, Alessandro De Laurenzis wrote: > Hello Stuart, > > Wouldn't it be "tigervncviewer" a more suitable name for binary/manpage? I find it quite convenient this way for finger memory (vncv) ..
Re: NEW: x11/tigervnc
Hello Stuart, Wouldn't it be "tigervncviewer" a more suitable name for binary/manpage? On March 10, 2020 11:38:48 PM GMT+01:00, 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). -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
[PATCH] emulators/snes9x: remove BROKEN-powerpc marker
Hi, The following diff removes the BROKEN-powerpc marker from emulators/snes9x. It builds without ICE, and runs here. (No bump since it only changes something on an arch where it wasn't built.) Donovan Index: Makefile === RCS file: /cvs/ports/emulators/snes9x/Makefile,v retrieving revision 1.50 diff -u -p -r1.50 Makefile --- Makefile14 Jul 2019 00:39:36 - 1.50 +++ Makefile16 Dec 2019 18:33:01 - @@ -3,7 +3,6 @@ COMMENT = emulates the Super Nintendo Entertainment System BROKEN-alpha = ICE/failure on filter/hq2x.cpp BROKEN-hppa = ICE/failure on filter/hq2x.cpp -BROKEN-powerpc =ICE/failure on filter/hq2x.cpp GH_ACCOUNT = snes9xgit GH_PROJECT = snes9x
Re: WIP: Update of math/py-numpy to 1.16.5
On Fri, Jan 10, 2020 at 04:00:10PM +, Stuart Henderson wrote:
[...]
> I also removed part of patch-numpy_core_include_numpy_npy_common_h
> that was dealing with gcc-<4.4 which we don't have to worry about
> (the gfortran module uses gcc for C as well as Fortran, so it will
> always be built with 4.4+ for us). I left the second part in but
> we could do with testing powerpc with that file removed completely
> (I added an XXX).
I believe this second part is still needed. Without it, there are lots
of warnings of this type:
/usr/include/math.h:425:32: note: expected 'long double *' but argument is of
type 'npy_longdouble *' {aka 'double *'}
On Tue, Mar 10, 2020 at 06:41:22PM +0100, Jeremie Courreges-Anglas wrote:
[...]
> 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).
Somebody with a better knowledge of powerpc should probably take a look:
Both flavors build, but the regress tests abort due to a bus error in
the multiarray code between 18% and 19% in (trace below). This is new.
The 14.0.6 tests only had a handful (9?) unexpected failures (also with
jca@'s cblas diff).
It's probably unrelated, but there are new warnings from dragon4.c that
are of the same kind as the ones fixed by the patch sthen mentioned, e.g.:
numpy/core/src/multiarray/dragon4.c:3160:1: note: in expansion of macro
'make_dragon4_typefuncs'
make_dragon4_typefuncs(LongDouble, npy_longdouble, NPY_LONGDOUBLE_BINFMT_NAME)
^~
numpy/core/src/multiarray/dragon4.c:2373:48: note: expected 'npy_float64 *'
{aka 'double *'} but argument is of type 'npy_longdouble *' {aka 'long double
*'}
Dragon4_Scratch *scratch, npy_float64 *value, Dragon4_Options *opt)
~^
And here's the start of the trace of the bus error during tests. The
python3 version is almost the same.
#0 0xd79f731c in _contig_cast_cfloat_to_cdouble ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#1 0xd797be04 in raw_array_assign_array ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#2 0xd797c55c in PyArray_AssignArray ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#3 0xd798b2bc in PyArray_CastToType ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#4 0xd7aa8908 in PyUFunc_GenericFunction ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#5 0xd7aa9648 in ufunc_generic_call ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#6 0xa9513200 in PyObject_Call () from /usr/local/lib/libpython2.7.so.0.0
#7 0xa9513ca4 in PyObject_CallFunctionObjArgs () from
/usr/local/lib/libpython2.7.so.0.0
#8 0xd7a48a00 in PyArray_GenericBinaryFunction ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#9 0xd7a49640 in array_add ()
from
/usr/obj/pobj/py-numpy-1.16.5/fake-powerpc/usr/local/lib/python2.7/site-packages/numpy/core/_multiarray_umath.so
#10 0xa950cfe4 in binary_op1 () from /usr/local/lib/libpython2.7.so.0.0
...
Re: WIP: Update of math/py-numpy to 1.16.5
Am 11.03.20 um 18:53 schrieb Theo Buehler:
> On Wed, Mar 11, 2020 at 04:12:56AM +0100, Jeremie Courreges-Anglas wrote:
>> 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 see. Thank you very much for your explanations.
>
> FWIW your cblas diff is ok tb (also tested on macppc).
>
Also tested on arm64, with numpy-1.16.6:
42 failed, 7268 passed, 93 skipped, 168 deselected, 12 xfailed, 1
xpassed, 1 warnings
I think this is ready to go into the tree with the cblas diff on top?
The update to 1.16.6 is straightforward if you want to stick to 1.16.5 now.
-m
Re: [ports-gcc] Unbreak graphics/pstoedit
On Wed, Mar 11 2020, Charlene Wendling wrote:
> Hi,
>
>> http://build-failures.rhaalovely.net/sparc64/2020-03-08/graphics/pstoedit.log
> (not yet on macppc)
>
> Back in the ports-gcc-4.9 days we had to force C++11, but now it's
> useless with gcc-8.3, and it wants C++14 at least.
>
> Once `-std=c++11' is removed, it builds fine on macppc [0] and is
> still fine on amd64.
>
> Comments/feedback are welcome,
ok jca@
> Charlène.
>
>
> [0] https://bin.charlenew.xyz/pstoedit-3.75p0.log
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/pstoedit/Makefile,v
> retrieving revision 1.31
> diff -u -p -u -p -r1.31 Makefile
> --- Makefile 5 Mar 2020 21:02:17 - 1.31
> +++ Makefile 11 Mar 2020 18:45:03 -
> @@ -3,6 +3,7 @@
> COMMENT= translate PostScript/PDF graphics to other vector formats
>
> DISTNAME=pstoedit-3.75
> +REVISION=0
> SHARED_LIBS= pstoedit 3.0
> CATEGORIES= graphics
>
> @@ -26,11 +27,8 @@ CONFIGURE_ARGS=--without-libplot \
> --without-magick
> WANTLIB= c ${COMPILER_LIBCXX} m
>
> -# c++11
> -COMPILER = base-clang ports-gcc base-gcc
> -
> -# This should be reviewed once moving to ports-gcc>=8
> -CXXFLAGS += -std=c++11
> +# c++14
> +COMPILER = base-clang ports-gcc
>
> post-install:
> ${INSTALL_MAN} ${WRKSRC}/doc/pstoedit.1 ${PREFIX}/man/man1
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[ld.bfd] don't build net/dleyna-*
> http://build-failures.rhaalovely.net/sparc64/2020-03-08/net/dleyna/
> http://build-failures.rhaalovely.net/powerpc/2020-02-14/net/dleyna/
> http://build-failures.rhaalovely.net/mips64/2020-02-23/net/dleyna/
I'm proposing to not build dleyna on ld.bfd archs, the renderer is known
to be broken with modern version of net/gupnp [0].
I think that the implied changes in the renderer are too big to be
patched in our ports tree [1], actually the proposed changes are not
even committed yet upstream.
Note that dleyna-server has some potential fix [2] committed, so
we could be just mark dleyna-renderer broken and patch dleyna-server.
But i don't have the hardware to test, so it makes things difficult.
Comments/feedback are welcome,
Charlène.
[0] https://github.com/intel/dleyna-renderer/issues/166
[1] https://github.com/intel/dleyna-renderer/pull/167/files
[2] https://github.com/intel/dleyna-server/pull/161
Index: Makefile.inc
===
RCS file: /cvs/ports/net/dleyna/Makefile.inc,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 Makefile.inc
--- Makefile.inc12 Jul 2019 20:48:25 - 1.6
+++ Makefile.inc11 Mar 2020 19:04:59 -
@@ -1,5 +1,9 @@
# $OpenBSD: Makefile.inc,v 1.6 2019/07/12 20:48:25 sthen Exp $
+# Requires this to be fixed with ld.bfd:
+# https://github.com/intel/dleyna-renderer/issues/166
+ONLY_FOR_ARCHS=${LLD_ARCHS}
+
CATEGORIES ?= net multimedia
HOMEPAGE ?=https://01.org/dleyna/
[ports-gcc] Unbreak graphics/pstoedit
Hi,
> http://build-failures.rhaalovely.net/sparc64/2020-03-08/graphics/pstoedit.log
(not yet on macppc)
Back in the ports-gcc-4.9 days we had to force C++11, but now it's
useless with gcc-8.3, and it wants C++14 at least.
Once `-std=c++11' is removed, it builds fine on macppc [0] and is
still fine on amd64.
Comments/feedback are welcome,
Charlène.
[0] https://bin.charlenew.xyz/pstoedit-3.75p0.log
Index: Makefile
===
RCS file: /cvs/ports/graphics/pstoedit/Makefile,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 Makefile
--- Makefile5 Mar 2020 21:02:17 - 1.31
+++ Makefile11 Mar 2020 18:45:03 -
@@ -3,6 +3,7 @@
COMMENT= translate PostScript/PDF graphics to other vector formats
DISTNAME= pstoedit-3.75
+REVISION= 0
SHARED_LIBS= pstoedit 3.0
CATEGORIES=graphics
@@ -26,11 +27,8 @@ CONFIGURE_ARGS= --without-libplot \
--without-magick
WANTLIB= c ${COMPILER_LIBCXX} m
-# c++11
-COMPILER = base-clang ports-gcc base-gcc
-
-# This should be reviewed once moving to ports-gcc>=8
-CXXFLAGS +=-std=c++11
+# c++14
+COMPILER = base-clang ports-gcc
post-install:
${INSTALL_MAN} ${WRKSRC}/doc/pstoedit.1 ${PREFIX}/man/man1
Re: new emulators/gsplus
On Wed, Mar 11, 2020 at 05:47:59PM +0100, Jeremie Courreges-Anglas wrote: > On Wed, Mar 11 2020, Solene Rapenne wrote: > > Hi, this is a port to bring gsplus, an Apple IIgs emulator > > > > I had to patch a timeval struct use leading to a compilation error, I'm > > not sure I correctly fixed it though. > > Looking at the rest of the file, this function is duplicated with > various versions used epending on the OS, and all the other versions > have this line commented out. The line doesn't do anything anyway since > the times array is initialized to 0s using memset. > > It seems bogus to set the access time to 0 (Jan 1 01:00:00 1970) but > I guess that's a detail that corrects itself once you open the file > again... To avoid this you can either set times[0] to current access > time of the file or the current time, or use the convenient utimensat(2) > interface and its UTIME_NOW/OMIT special values. I prefer not to touch this, if it's doing nothing then it's fine, if I add code I may introduce bugs :) If someone wants to improve this, that would be nice though > > I'm still trying to figure out to use this emulator, if someone have a > > clue please share :) It asks for a ROM (seems like the "bios" or system > > equivalent?) and it's possible to feed it with floppies images. > > > > The port was super easy to do and pass dpb build in a fresh chroot, I > > hope this will be easy to review. > > LGTM ports-wise, I think you should set NO_TEST=Yes and maybe install > stuff under the doc/ directory, eg doc/README.txt and > doc/gsplusmanual.pdf. If it proves useful, that is. :) > here a new version from your and bcallah@ inputs - added NO_TEST=yes - added some doc which are really helpful (ive been able to start something) - added some files which gsplus was looking for (not sure about the use but in console it complains about them missing) - add myself as maintainer - fixed license, it's GPLv2 PLUS gsplus.tar.gz Description: application/tar-gz
Re: new emulators/gsplus
On Wed, Mar 11, 2020 at 03:40:47PM +0100, Solene Rapenne wrote: > Hi, this is a port to bring gsplus, an Apple IIgs emulator > > I had to patch a timeval struct use leading to a compilation error, I'm > not sure I correctly fixed it though. > > I'm still trying to figure out to use this emulator, if someone have a > clue please share :) It asks for a ROM (seems like the "bios" or system > equivalent?) and it's possible to feed it with floppies images. Here is how I was able to play arkanoid: Download and unzip rom03.zip from here: ftp://ftp.apple.asimov.net/pub/apple_II/emulators/rom_images/ Download and unzip Arkanoid.zip from this page (don't know if this is legal): http://www.whatisthe2gs.apple2.org.za/arkanoid Put the following two lines in ~/.config.gsp: g_cfg_rom_path = APPLE2GS.ROM2 s7d1 = Arkanoid/Arkanoid.2mg Running GSplus should now load the game automatically. It works fine on amd64, but on macppc it runs super super slow.. > > The port was super easy to do and pass dpb build in a fresh chroot, I > hope this will be easy to review. >
Re: WIP: Update of math/py-numpy to 1.16.5
On Wed, Mar 11, 2020 at 04:12:56AM +0100, Jeremie Courreges-Anglas wrote:
> 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 see. Thank you very much for your explanations.
FWIW your cblas diff is ok tb (also tested on macppc).
Re: UPDATE: audio/vamp-plugin-sdk 2.2.1 -> 2.9.0
On Wed, Mar 11 2020, Raphael Graf wrote: > Diff below updates vamp-plugin-sdk to 2.9.0. > > Here is the changelog: > https://github.com/c4dm/vamp-plugin-sdk/blob/vamp-plugin-sdk-v2.9/CHANGELOG > > Consumers of this port are audio/audacity and audio/rubberband. > > I have tested the example plugins and the plugins provided by rubberband. > The plugins can be enabled in audacity via 'Effect' -> 'Add/Remove Plug-ins'. > > Comments/OKs are welcome Please bump libvamp-hostsdk.so to 2.0, some symbols have been removed (you can use /usr/src/lib/check_sym to check for such changes). Otherwise this looks good ports-wise. If you know that audacity still builds fine with the new vamp-plugin-sdk package installed, ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: new emulators/gsplus
On Wed, Mar 11 2020, Solene Rapenne wrote: > Hi, this is a port to bring gsplus, an Apple IIgs emulator > > I had to patch a timeval struct use leading to a compilation error, I'm > not sure I correctly fixed it though. Looking at the rest of the file, this function is duplicated with various versions used epending on the OS, and all the other versions have this line commented out. The line doesn't do anything anyway since the times array is initialized to 0s using memset. It seems bogus to set the access time to 0 (Jan 1 01:00:00 1970) but I guess that's a detail that corrects itself once you open the file again... To avoid this you can either set times[0] to current access time of the file or the current time, or use the convenient utimensat(2) interface and its UTIME_NOW/OMIT special values. > I'm still trying to figure out to use this emulator, if someone have a > clue please share :) It asks for a ROM (seems like the "bios" or system > equivalent?) and it's possible to feed it with floppies images. > > The port was super easy to do and pass dpb build in a fresh chroot, I > hope this will be easy to review. LGTM ports-wise, I think you should set NO_TEST=Yes and maybe install stuff under the doc/ directory, eg doc/README.txt and doc/gsplusmanual.pdf. If it proves useful, that is. :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Slight grafana file permissions improvement
Thankyou for updating the Grafana port. The /etc/grafana/custom.ini contains a default key and can contain passwords. These are public knowledge but may be changed and better to be secure by default. https://github.com/grafana/grafana/pull/2306 https://github.com/grafana/grafana/issues/2126 Could the recent import be edited to do similar or atleast for custom.ini? IOW Set files in /etc/grafana to mode 0640 and group ownership to _grafana They are currently root:wheel 0644 in the previous and most recent 6.2.2 pkg
new emulators/gsplus
Hi, this is a port to bring gsplus, an Apple IIgs emulator I had to patch a timeval struct use leading to a compilation error, I'm not sure I correctly fixed it though. I'm still trying to figure out to use this emulator, if someone have a clue please share :) It asks for a ROM (seems like the "bios" or system equivalent?) and it's possible to feed it with floppies images. The port was super easy to do and pass dpb build in a fresh chroot, I hope this will be easy to review. gsplus.tar.gz Description: application/tar-gz
Re: NEW: wormhole-william
On Thu, 05 Mar 2020 at 23:28:50 +, Edd Barrett wrote:
> Hi,
>
> This is a golang implementation of magic wormhole:
> https://github.com/warner/magic-wormhole
>
> The go implementation is easier to port than the Python one ;)
>
> Had to generate a vendored tarball, hence hosting the distfile.
>
> Comments? OK?
>
> --
> Best Regards
> Edd Barrett
>
> http://www.theunixzoo.co.uk
I'd whack the GH_* stuff in favor of ALL_TARGET (doing so breaks the distfile -
i think it just needs to contain a directory named
"wormhole-william-vendored-${V")
For go apps GH_* sets ALL_TARGET which then becomes:
go install ${ALL_TARGET}
I prefer just setting ALL_TARGET as it's a bit more clear what's happening and
makes the makefile a bit shorter (also I have a mental twinge from the GH
distfile regen stuff when I see GH_* :P)
MODGO_TYPE is default, so it can be removed.
OK abieber@ with MODGO_TYPE removed - whacking GH_* is up to you :D
--
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
UPDATE: audio/vamp-plugin-sdk 2.2.1 -> 2.9.0
Diff below updates vamp-plugin-sdk to 2.9.0.
Here is the changelog:
https://github.com/c4dm/vamp-plugin-sdk/blob/vamp-plugin-sdk-v2.9/CHANGELOG
Consumers of this port are audio/audacity and audio/rubberband.
I have tested the example plugins and the plugins provided by rubberband.
The plugins can be enabled in audacity via 'Effect' -> 'Add/Remove Plug-ins'.
Comments/OKs are welcome
Index: Makefile
===
RCS file: /cvs/ports/audio/vamp-plugin-sdk/Makefile,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 Makefile
--- Makefile18 Nov 2019 12:06:23 - 1.21
+++ Makefile11 Mar 2020 12:34:48 -
@@ -2,13 +2,12 @@
COMMENT = audio plugin API
-VERSION = 2.2.1
+VERSION = 2.9.0
DISTNAME = vamp-plugin-sdk-${VERSION}
-REVISION = 5
CATEGORIES = audio
-SHARED_LIBS += vamp-sdk1.0
-SHARED_LIBS += vamp-hostsdk1.0
+SHARED_LIBS += vamp-sdk1.1
+SHARED_LIBS += vamp-hostsdk1.1
HOMEPAGE = http://www.vamp-plugins.org/
@@ -17,25 +16,18 @@ PERMIT_PACKAGE =Yes
WANTLIB = c m ${COMPILER_LIBCXX}
-COMPILER = base-clang ports-gcc base-gcc
+# C++11
+COMPILER = base-clang ports-gcc
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=vamp/}
+MASTER_SITES =
https://code.soundsoftware.ac.uk/attachments/download/2588/
-MAKE_ENV +=CXX=${CXX} \
- CXXFLAGS="${CXXFLAGS} -I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib" \
- LIBvamp-sdk_VERSION="${LIBvamp-sdk_VERSION}" \
+MAKE_ENV +=LIBvamp-sdk_VERSION="${LIBvamp-sdk_VERSION}" \
LIBvamp-hostsdk_VERSION="${LIBvamp-hostsdk_VERSION}"
-FAKE_FLAGS = PREFIX="${TRUEPREFIX}"
USE_GMAKE =Yes
CONFIGURE_STYLE = gnu
-CONFIGURE_ENV =SNDFILE_CFLAGS="-I${LOCALBASE}/include" \
- SNDFILE_LIBS="-L${LOCALBASE}/lib -lsndfile"
TEST_TARGET = test
TEST_DEPENDS = audio/libsndfile
-
-WRKDIST = ${WRKDIR}/vamp-plugin-sdk-v${VERSION}
.include
Index: distinfo
===
RCS file: /cvs/ports/audio/vamp-plugin-sdk/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- distinfo10 Jan 2016 17:28:55 - 1.4
+++ distinfo11 Mar 2020 12:34:48 -
@@ -1,2 +1,2 @@
-SHA256 (vamp-plugin-sdk-2.2.1.tar.gz) =
VxSBCYJwEz0reMakYbhQ4EqYqzgoQifE2AVjhfYzPCY=
-SIZE (vamp-plugin-sdk-2.2.1.tar.gz) = 162829
+SHA256 (vamp-plugin-sdk-2.9.0.tar.gz) =
typ474/4qSfcLtfmbs9MYtIyaKXXTQLaJb4rjQA0EJk=
+SIZE (vamp-plugin-sdk-2.9.0.tar.gz) = 312726
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/audio/vamp-plugin-sdk/patches/patch-Makefile_in,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-Makefile_in
--- patches/patch-Makefile_in 18 Nov 2019 12:06:23 - 1.4
+++ patches/patch-Makefile_in 11 Mar 2020 12:34:48 -
@@ -1,11 +1,13 @@
$OpenBSD: patch-Makefile_in,v 1.4 2019/11/18 12:06:23 sthen Exp $
Makefile.in.orig Tue Apr 5 14:30:52 2011
-+++ Makefile.inSun Jan 10 17:02:16 2016
-@@ -75,15 +75,15 @@ INSTALL_SDK_LIBS = $(INSTALL_PREFIX)/lib
+
+Index: Makefile.in
+--- Makefile.in.orig
Makefile.in
+@@ -78,15 +78,15 @@ INSTALL_SDK_LIBS = $(INSTALL_PREFIX)/lib
INSTALL_PLUGINS = $(INSTALL_PREFIX)/lib/vamp
INSTALL_BINARIES= $(INSTALL_PREFIX)/bin
--INSTALL_SDK_LIBNAME = libvamp-sdk.so.2.2.0
+-INSTALL_SDK_LIBNAME = libvamp-sdk.so.2.9.0
-INSTALL_SDK_LINK_ABI= libvamp-sdk.so.2
-INSTALL_SDK_LINK_DEV= libvamp-sdk.so
+INSTALL_SDK_LIBNAME = libvamp-sdk.so.${LIBvamp-sdk_VERSION}
@@ -14,7 +16,7 @@ $OpenBSD: patch-Makefile_in,v 1.4 2019/1
INSTALL_SDK_STATIC= libvamp-sdk.a
INSTALL_SDK_LA= libvamp-sdk.la
--INSTALL_HOSTSDK_LIBNAME = libvamp-hostsdk.so.3.2.0
+-INSTALL_HOSTSDK_LIBNAME = libvamp-hostsdk.so.3.9.0
-INSTALL_HOSTSDK_LINK_ABI = libvamp-hostsdk.so.3
-INSTALL_HOSTSDK_LINK_DEV = libvamp-hostsdk.so
+INSTALL_HOSTSDK_LIBNAME = libvamp-hostsdk.so.${LIBvamp-hostsdk_VERSION}
@@ -23,7 +25,7 @@ $OpenBSD: patch-Makefile_in,v 1.4 2019/1
INSTALL_HOSTSDK_STATIC= libvamp-hostsdk.a
INSTALL_HOSTSDK_LA= libvamp-hostsdk.la
-@@ -91,9 +91,9 @@ INSTALL_PKGCONFIG = $(INSTALL_PREFIX)/lib/pkgconfig
+@@ -94,9 +94,9 @@ INSTALL_PKGCONFIG = $(INSTALL_PREFIX)/lib/pkgconfig
# Flags required to tell the compiler to create a dynamically loadable object
#
@@ -36,7 +38,7 @@ $OpenBSD: patch-Makefile_in,v 1.4 2019/1
# Additional flags for making a plugin. This version script tells the
# GNU linker to make all symbols in the library hidden except for the
Re: [New] devel/snare
On 2020/03/11 10:43, Laurence Tratt wrote:
> On Thu, Mar 05, 2020 at 09:06:34PM +, Stuart Henderson wrote:
>
> Hello Stuart,
>
> Thanks for your comments -- I've incorporated all of them. I was waiting for
> Sebastien's cargo patch to go into tree, but I'm not sure when that's
> coming, and db/user.list keeps changing underneath my feet!
>
> > - as a daemon it would be better if this had an rc script and dedicated uid
> > to run it as. probably also @sample the config file into ${SYSCONFDIR}?
>
> Agreed -- an rc script makes sense, at which point a dedicated uid/gid is
> vital (this is a program one definitely doesn't want to run as root!). The
> diff to user.list is inline. I attach an update of the port as a .tgz. I've
> made a new release a) so that snare now searches /etc/snare/snare.conf b)
> because one of its dependencies has been yanked. Those are relatively minor
> changes, fortunately.
>
>
> Laurie
>
> Index: infrastructure/db/user.list
> ===
> RCS file: /cvs/ports/infrastructure/db/user.list,v
> retrieving revision 1.360
> diff -u -r1.360 user.list
> --- infrastructure/db/user.list 9 Mar 2020 08:17:31 - 1.360
> +++ infrastructure/db/user.list 11 Mar 2020 10:01:35 -
> @@ -357,3 +357,4 @@
> 847 _iperf3 _iperf3 net/iperf3
> 848 _loki_loki sysutils/loki
> 849 _synapse _synapsenet/synapse
> +850 _snare _snare devel/snare
Thanks - committed, we can adjust when the cargo patch goes in :)
Re: [New] devel/snare
On Thu, Mar 05, 2020 at 09:06:34PM +, Stuart Henderson wrote:
Hello Stuart,
Thanks for your comments -- I've incorporated all of them. I was waiting for
Sebastien's cargo patch to go into tree, but I'm not sure when that's
coming, and db/user.list keeps changing underneath my feet!
> - as a daemon it would be better if this had an rc script and dedicated uid
> to run it as. probably also @sample the config file into ${SYSCONFDIR}?
Agreed -- an rc script makes sense, at which point a dedicated uid/gid is
vital (this is a program one definitely doesn't want to run as root!). The
diff to user.list is inline. I attach an update of the port as a .tgz. I've
made a new release a) so that snare now searches /etc/snare/snare.conf b)
because one of its dependencies has been yanked. Those are relatively minor
changes, fortunately.
Laurie
Index: infrastructure/db/user.list
===
RCS file: /cvs/ports/infrastructure/db/user.list,v
retrieving revision 1.360
diff -u -r1.360 user.list
--- infrastructure/db/user.list 9 Mar 2020 08:17:31 - 1.360
+++ infrastructure/db/user.list 11 Mar 2020 10:01:35 -
@@ -357,3 +357,4 @@
847 _iperf3_iperf3 net/iperf3
848 _loki _loki sysutils/loki
849 _synapse _synapsenet/synapse
+850 _snare _snare devel/snare
snare_port.tgz
Description: application/tar-gz
Re: py-msgpack 1.0.0 upgrade broke salt
FWIW this one works for me, pkg_add also sees it as an updated.
Thanks,
Florian
On Tue, Mar 10, 2020 at 10:45:08PM +0100, Florian Obser wrote:
> 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-pack
sparc64 bulk build report
Bulk build on sparc64-0.ports.openbsd.org Started : Sun Mar 8 16:32:47 MDT 2020 Finished: Wed Mar 11 03:01:19 MDT 2020 Duration: 2 Days 10 hours 29 minutes Built using OpenBSD 6.6-current (GENERIC.MP) #238: Sat Mar 7 17:48:34 MST 2020 Built 9915 packages Number of packages built each day: Mar 8: 5888 Mar 9: 3019 Mar 10: 1006 Mar 11: 2 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2020-03-08/summary.log Build failures: 21 http://build-failures.rhaalovely.net/sparc64/2020-03-08/cad/qucs.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/emulators/BasiliskII.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/games/pokerth.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/games/xevil.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/graphics/colord-gtk.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/graphics/pstoedit.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/mail/kopano/core.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/math/py-scikit-learn.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/misc/dtcltiny.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/net/dleyna/renderer.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/net/dleyna/server.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/net/synapse.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/net/telegram-purple.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/productivity/gnucash.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/telephony/iaxclient.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/x11/gnome/builder.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/x11/gnome/mutter.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/x11/gtk+4,-cloudprint.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/x11/kde4/libs,,-en_US.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/x11/libdbus-c++.log http://build-failures.rhaalovely.net/sparc64/2020-03-08/x11/libhandy.log Recurrent failures: failures/games/pokerth.log failures/games/xevil.log failures/graphics/colord-gtk.log failures/mail/kopano/core.log failures/math/py-scikit-learn.log failures/misc/dtcltiny.log failures/net/dleyna/renderer.log failures/net/dleyna/server.log failures/net/telegram-purple.log failures/productivity/gnucash.log New failures: +failures/graphics/pstoedit.log +failures/net/synapse.log Resolved failures: -failures/math/py-h5py,python3.log Packages newly built: +devel/py-importlib-metadata,python3 +devel/py-typing-extensions,python3 +fonts/iosevka-fonts +fonts/iosevka-fonts,-main +fonts/iosevka-fonts,-term +math/py-h5py,python3 +net/dbip/city +net/dbip/country +security/py-libnacl,python3 +textproc/py-canonicaljson,python3 +textproc/py-signedjson,python3 +textproc/py-unpaddedbase64,python3 +www/py-macaroons,python3 +www/py-treq,python3 Packages not built this time: -devel/py-wurlitzer -devel/spyder/py-spyder-kernels -devel/spyder/spyder -graphics/pstoedit -math/py-sympy -shells/py-qtconsole
