CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2020/03/11 21:04:08 Modified files: databases/sqlbox: Makefile distinfo Log message: Update sqlbox to 0.1.12
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: tra...@cvs.openbsd.org 2020/03/11 18:13:19 Modified files: devel : Makefile Log message: Gently reminded by sthen@ to add xtensa-esp32-elf to devel/Makefile.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/03/11 17:57:04 Modified files: www/chromium : Makefile distinfo Removed files: www/chromium/patches: epatch-electron_BUILD_gn epatch-electron_atom_app_atom_main_cc epatch-electron_atom_app_atom_main_delegate_cc epatch-electron_atom_browser_api_atom_api_app_cc epatch-electron_atom_browser_api_atom_api_power_monitor_cc epatch-electron_atom_browser_api_atom_api_power_monitor_h epatch-electron_atom_browser_api_atom_api_web_contents_cc epatch-electron_atom_browser_atom_browser_main_parts_cc epatch-electron_atom_browser_atom_browser_main_parts_posix_cc epatch-electron_atom_browser_atom_paths_h epatch-electron_atom_browser_browser_h epatch-electron_atom_browser_lib_power_observer_h epatch-electron_atom_browser_lib_power_observer_linux_cc epatch-electron_atom_browser_native_window_views_cc epatch-electron_atom_browser_native_window_views_h epatch-electron_atom_browser_relauncher_linux_cc epatch-electron_atom_browser_ui_views_atom_views_delegate_cc epatch-electron_atom_browser_ui_views_atom_views_delegate_h epatch-electron_atom_browser_ui_views_submenu_button_cc epatch-electron_atom_common_api_atom_api_crash_reporter_cc epatch-electron_atom_common_api_electron_bindings_cc epatch-electron_atom_common_atom_command_line_cc epatch-electron_atom_common_atom_command_line_h epatch-electron_atom_common_crash_reporter_crash_reporter_cc epatch-electron_atom_common_node_bindings_cc epatch-electron_atom_common_node_bindings_linux_cc epatch-electron_atom_common_platform_util_h epatch-electron_build_npm_gni epatch-electron_chromium_src_chrome_browser_process_singleton_posix_cc epatch-electron_default_app_default_app_ts epatch-electron_lib_browser_api_dialog_js epatch-electron_lib_browser_api_menu-item-roles_js epatch-electron_lib_browser_api_power-monitor_js epatch-electron_lib_common_api_clipboard_js epatch-electron_node_modules_arch_index_js epatch-electron_node_modules_dugite_build_lib_git-environment_js epatch-electron_node_modules_fsevents_node_modules_os-homedir_index_js epatch-electron_node_modules_fsevents_node_modules_signal-exit_signals_js epatch-electron_node_modules_os-homedir_index_js epatch-electron_node_modules_signal-exit_signals_js epatch-electron_script_lib_utils_js epatch-electron_script_spec-runner_js epatch-electron_spec-main_api-app-spec_ts epatch-electron_spec_api-auto-updater-spec_js epatch-electron_spec_api-browser-window-spec_js epatch-electron_spec_api-clipboard-spec_js epatch-electron_spec_api-content-tracing-spec_js epatch-electron_spec_api-crash-reporter-spec_js epatch-electron_spec_api-net-log-spec_js epatch-electron_spec_api-process-spec_js epatch-electron_spec_api-screen-spec_js epatch-electron_spec_api-shell-spec_js epatch-electron_spec_chromium-spec_js epatch-electron_spec_version-bump-spec_js epatch-third_party_electron_node_BUILD_gn epatch-third_party_electron_node_deps_cares_config_linux_ares_config_h epatch-third_party_electron_node_deps_uv_BUILD_gn www/chromium/pkg: DESCR-electron PFRAG.swiftshader-electron PLIST-electron Log message: zap electron cruft
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 17:32:13 Modified files: net/scamper: Makefile distinfo net/scamper/pkg: PLIST Log message: update to scamper-20191102b
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à.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2020/03/11 16:27:58 Modified files: devel/cdk : Makefile editors/vile : Makefile lang/mawk : Makefile misc/vttest: Makefile Log message: move home page and master site to https
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2020/03/11 16:04:04 Modified files: archivers/unzip: Tag: OPENBSD_6_6 Makefile archivers/unzip/patches: Tag: OPENBSD_6_6 patch-extract_c patch-fileio_c patch-list_c patch-process_c Added files: archivers/unzip/patches: Tag: OPENBSD_6_6 patch-globals_c patch-globals_h patch-unzip_h Log message: Security fixes for: CVE-2018-135 (heap overflow in processing password-protected archives) CVE-2019-13232 (mishandles the overlapping of files inside a ZIP container) >From Moritz Buhl
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2020/03/11 15:57:32 Modified files: archivers/unzip: Makefile archivers/unzip/patches: patch-extract_c patch-fileio_c patch-list_c patch-process_c Added files: archivers/unzip/patches: patch-globals_c patch-globals_h patch-unzip_h Log message: Security fixes for: CVE-2018-135 (heap overflow in processing password-protected archives) CVE-2019-13232 (mishandles the overlapping of files inside a ZIP container) >From Moritz Buhl
[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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2020/03/11 15:01:05 Modified files: databases/sqlite3: Makefile Added files: databases/sqlite3/patches: patch-sqlite3_c Log message: Apply a patch from sqlite's upstream repository to fix a crash on sparc64. Observed in e.g. 'svn update' which started segfaulting with sqlite 3.31.1. Thanks to Richard Hipp for identifying the fix we need. ok sthen@
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 12:27:15 Modified files: x11/tigervnc : Makefile distinfo x11/tigervnc/pkg: PLIST Added files: x11/tigervnc/patches: patch-unix_vncserver patch-unix_xserver_hw_vnc_Makefile_am Log message: x11/tigervnc: also build Xvnc
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).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/03/11 11:48:37 ports/devel/kf5/khtml/patches Update of /cvs/ports/devel/kf5/khtml/patches In directory cvs.openbsd.org:/tmp/cvs-serv39435/patches Log Message: Directory /cvs/ports/devel/kf5/khtml/patches added to the repository
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/03/11 10:46:34 Modified files: infrastructure/mk: bsd.port.mk Log message: let's use a proper mktemp idiom for makesum
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 09:55:12 Modified files: x11/tigervnc : Makefile Log message: x11/tigervnc: explicitly disable pam as suggested by jca@, even though the current version doesn't pick up libpam, a future update may change this, so explicitly disable it via cmake args.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/03/11 09:35:58 Modified files: geo/geos : Makefile distinfo geo/geos/pkg : PLIST Log message: Update to geos 3.8.1. See https://lists.osgeo.org/pipermail/geos-devel/2020-March/009478.html - bump major to be on the safe side, two prototypes changed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2020/03/11 09:17:12 Modified files: math/ebc : Makefile distinfo Log message: Update to ebc-2.6.0 Changelog: https://github.com/gavinhoward/bc/releases/tag/2.6.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 09:12:53 Modified files: devel/py-enum34: Makefile distinfo devel/py-enum34/pkg: PLIST Log message: update to py-enum34-1.1.10
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: tra...@cvs.openbsd.org 2020/03/11 08:24:58 Log message: import ports/devel/xtensa-esp32-elf, ok sthen@ kmos@ The xtensa-esp32-elf port is an ESP32 GNU cross-compiler Toolchain. ESP32 is a series of low-cost, low-power system on a chip microcontrollers with integrated Wi-Fi and dual-mode Bluetooth. The ESP32 series employs a Tensilica Xtensa LX6 microprocessor in both dual-core and single-core variations and includes built-in antenna switches, RF balun, power amplifier, low-noise receive amplifier, filters, and power-management modules. ESP32 is created and developed by Espressif Systems, a Shanghai-based Chinese company, and is manufactured by TSMC using their 40 nm process.[2] It is a successor to the ESP8266 microcontroller. Status: Vendor Tag: tracey Release Tags: tracey_20200311 N ports/devel/xtensa-esp32-elf/Makefile N ports/devel/xtensa-esp32-elf/Makefile.inc N ports/devel/xtensa-esp32-elf/binutils/Makefile N ports/devel/xtensa-esp32-elf/binutils/distinfo N ports/devel/xtensa-esp32-elf/binutils/patches/patch-bfd_xtensa-modules_c N ports/devel/xtensa-esp32-elf/binutils/patches/patch-include_xtensa-config_h N ports/devel/xtensa-esp32-elf/binutils/pkg/DESCR N ports/devel/xtensa-esp32-elf/binutils/pkg/PLIST N ports/devel/xtensa-esp32-elf/gcc/Makefile N ports/devel/xtensa-esp32-elf/gcc/distinfo N ports/devel/xtensa-esp32-elf/gcc/patches/patch-include_xtensa-config_h N ports/devel/xtensa-esp32-elf/gcc/pkg/DESCR N ports/devel/xtensa-esp32-elf/gcc/pkg/PLIST N ports/devel/xtensa-esp32-elf/gcc-bootstrap/Makefile N ports/devel/xtensa-esp32-elf/gcc-bootstrap/distinfo N ports/devel/xtensa-esp32-elf/gcc-bootstrap/patches/patch-include_xtensa-config_h N ports/devel/xtensa-esp32-elf/gcc-bootstrap/pkg/DESCR N ports/devel/xtensa-esp32-elf/gcc-bootstrap/pkg/PLIST N ports/devel/xtensa-esp32-elf/gdb/Makefile N ports/devel/xtensa-esp32-elf/gdb/distinfo N ports/devel/xtensa-esp32-elf/gdb/patches/patch-bfd_xtensa-modules_c N ports/devel/xtensa-esp32-elf/gdb/patches/patch-gdb_Makefile_in N ports/devel/xtensa-esp32-elf/gdb/patches/patch-gdb_gdbserver_xtensa-regmap_c N ports/devel/xtensa-esp32-elf/gdb/patches/patch-gdb_gdbserver_xtensa-xtregs_c N ports/devel/xtensa-esp32-elf/gdb/patches/patch-gdb_regformats_reg-xtensa_dat N ports/devel/xtensa-esp32-elf/gdb/patches/patch-gdb_xtensa-config_c N ports/devel/xtensa-esp32-elf/gdb/patches/patch-gdb_xtensa-xtregs_c N ports/devel/xtensa-esp32-elf/gdb/patches/patch-include_xtensa-config_h N ports/devel/xtensa-esp32-elf/gdb/pkg/DESCR N ports/devel/xtensa-esp32-elf/gdb/pkg/PLIST N ports/devel/xtensa-esp32-elf/newlib/Makefile N ports/devel/xtensa-esp32-elf/newlib/distinfo N ports/devel/xtensa-esp32-elf/newlib/pkg/DESCR N ports/devel/xtensa-esp32-elf/newlib/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/03/11 07:41:53 Modified files: x11/xfce4/xfce4-whiskermenu: Makefile distinfo Log message: Update to xfce4-whiskermenu 2.4.3
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 :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 06:26:24 Modified files: devel : Makefile Log message: +snare
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 06:25:53 Log message: import ports/devel/snare, from upstream/maintainer Laurie Tratt, earlier version ok edd@ snare is a GitHub webhooks runner daemon. When snare receives a webhook event from a given repository, it authenticates the request, and then executes a user-defined "per-repo program" with information about the webhook event. Status: Vendor Tag: sthen Release Tags: sthen_20200311 N ports/devel/snare/Makefile N ports/devel/snare/distinfo N ports/devel/snare/pkg/DESCR N ports/devel/snare/pkg/PLIST N ports/devel/snare/pkg/snare.rc N ports/devel/snare/patches/patch-modcargo-crates_openssl-sys-0_9_54_build_main_rs No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 06:22:51 Modified files: infrastructure/db: user.list Log message: reserve 850 for snare
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 06:19:53 Modified files: x11: Makefile Log message: +tigervnc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/03/11 06:19:27 Log message: import ports/x11/tigervnc, ok robert@ bcallah@ 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. Status: Vendor Tag: sthen Release Tags: sthen_20200311 N ports/x11/tigervnc/Makefile N ports/x11/tigervnc/distinfo N ports/x11/tigervnc/pkg/DESCR N ports/x11/tigervnc/pkg/PLIST N ports/x11/tigervnc/patches/patch-CMakeLists_txt N ports/x11/tigervnc/patches/patch-vncviewer_vncviewer_desktop_in_in No conflicts created by this import
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2020/03/11 03:41:54 Modified files: devel : Makefile www: Makefile Log message: switch to building electron on its own, it's all grown up now.
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
> >
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2020/03/11 02:20:25 Modified files: textproc/ruby-rouge: Makefile distinfo textproc/ruby-rouge/pkg: PLIST Log message: Update ruby-rouge to 3.17.0.
