Re: [patch] audio/openal: ugly update to 1.18.2
On Wed, Jun 06, 2018 at 04:11:17PM +0300, Leonid Bobrov wrote: > On Tue, Jun 05, 2018 at 08:01:12AM +0200, Alexandre Ratchov wrote: > > I installed utox, it doesn't crash with the diff below anymore. The > > "Preview" button in the "Audio & Video" settings records my voice. > > > > Ok, I tested your diff using Toxic at virtual machine. Voice recording > works, but when I finish a call, I get segmentation fault (and I got > bus error once). Any update on this? does it work on real machines? If utox keeps crashing, could you provide a stack trace?
[NEW] security/py-miasm
Hi, attached is the port of miasm, a reverse engineering framework in Python. -- $ pkg_info py-miasm Information for inst:py-miasm-2.0 Comment: reverse engineering framework in Python Description: Miasm is a free and open source reverse engineering framework. Miasm aims to analyze / modify / generate binary programs. Here is a non exhaustive list of features: - Opening / modifying / generating PE / ELF 32 / 64 LE / BE using Elfesteem - Assembling / Disassembling X86 / ARM / MIPS / SH4 / MSP430 - Representing assembly semantic using intermediate language - Emulating using JIT (dynamic code analysis, unpacking, ...) - Expression simplification for automatic de-obfuscation Maintainer: Remi Pointel WWW: https://github.com/cea-sec/miasm -- Ok? Cheers, Remi. py-miasm-2.0.tar.gz Description: application/gzip
UPDATE net/py-msgpack
Enclosed a diff for bringing py-msgpack to 0.5.6, which fixes some
issues. This is the last available version of msgpack-python, which has
been deprecated [0]. Updating to the newer msgpack is currently not an
option as some of its consumers do not like the renaming.
While here change HOMEPAGE to https, and update WANTLIB.
Consumers of py-msgpack seem to work ok with this version. I've been
running this version in combination with borgbackup for over a week, and
have not seen any issue.
MAINTAINER responded with "ok shadchin@".
Any other OKs?
[0] https://pypi.org/project/msgpack-python/
Index: Makefile
===
RCS file: /cvs/ports/net/py-msgpack/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile26 Jul 2017 22:45:28 - 1.13
+++ Makefile12 Jun 2018 04:21:56 -
@@ -2,24 +2,25 @@
COMMENT = messagepack (de)serializer
-MODPY_EGG_VERSION =0.4.8
+# XXX: 0.5.6 is the last available version of msgpack-python, which has been
+# deprecated. Updating to the newer msgpack is currently not an option as some
+# of its consumers do not like the renaming.
+MODPY_EGG_VERSION =0.5.6
DISTNAME = msgpack-python-${MODPY_EGG_VERSION}
PKGNAME = py-msgpack-${MODPY_EGG_VERSION}
-REVISION = 1
CATEGORIES = net textproc
-HOMEPAGE = http://msgpack.org/
+HOMEPAGE = https://msgpack.org/
MAINTAINER = Alexandr Shadchin
# Apache 2.0
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += ${MODPY_WANTLIB} m pthread ${COMPILER_LIBCXX}
+WANTLIB = ${COMPILER_LIBCXX} ${MODPY_WANTLIB} m
MODULES = lang/python
-
MODPY_PI = Yes
MODPY_SETUPTOOLS = Yes
Index: distinfo
===
RCS file: /cvs/ports/net/py-msgpack/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo28 Aug 2016 13:17:52 - 1.5
+++ distinfo12 Jun 2018 04:21:56 -
@@ -1,2 +1,2 @@
-SHA256 (msgpack-python-0.4.8.tar.gz) =
GisZ3w8DUZ7H8Z+CavuTWyAtiXmwhWxvs9wolVeZ+IY=
-SIZE (msgpack-python-0.4.8.tar.gz) = 113641
+SHA256 (msgpack-python-0.5.6.tar.gz) =
N4zIptNUW1Mt/RSdpxWrrk/aKjrbbXTlJdDV5R9GkJs=
+SIZE (msgpack-python-0.5.6.tar.gz) = 138996
Re: WireGuard for OpenBSD
Hi Jason, Jason A. Donenfeld writes: > > - ipcErrorProtocol = -int64(unix.EPROTO) > > + ipcErrorProtocol = -int64(95) > > The x/sys/unix Go package now supports EPROTO on OpenBSD. Did you have > an old stale version in your Gopath? Filippo added it there three or > four weeks ago. The version in OpenBSD's package repositories is old, yes. > You cobbled together in your OpenBSD-centric readme a few fragments > from the upstream readme. One of those fragments your cribbed is: > > > To remove the > > interface, use the usual 'ifconfig tun0 destroy', or you may instead remove > the > > control socket via 'rm -f /var/run/wireguard/tun0.sock' > > I know that the `rm -f` version works on OpenBSD, but I'm not sure > `ifconfig tun0 destroy` will have the effect you were hoping for; can > you try this and see if it works there? The BSDs are all very > different about interface destroy handling, and I can't remember which > behavior OpenBSD exhibited. Yes, I did try it (successfully). > > ALL_TARGET = git.zx2c4.com/wireguard-go > > Does that do what you think it does? Shouldn't the target just be > "wireguard-go"? Or is there some special-case openbsd-go handling > happening? This is for some special handling in OpenBSD's Go ports infrastructure. -- Anthony J. Bentley
Re: WireGuard for OpenBSD
Hi Anthony, On Thu, Jun 21, 2018 at 3:05 AM Anthony J. Bentley wrote: > Oops, I accidentally sent out my (unfinished, broken) wireguard-go draft > from last week. Attached is the working version I meant to send out. Thanks. A few notes on what you just sent: > - ipcErrorProtocol = -int64(unix.EPROTO) > + ipcErrorProtocol = -int64(95) The x/sys/unix Go package now supports EPROTO on OpenBSD. Did you have an old stale version in your Gopath? Filippo added it there three or four weeks ago. You cobbled together in your OpenBSD-centric readme a few fragments from the upstream readme. One of those fragments your cribbed is: > To remove the > interface, use the usual 'ifconfig tun0 destroy', or you may instead remove > the > control socket via 'rm -f /var/run/wireguard/tun0.sock' I know that the `rm -f` version works on OpenBSD, but I'm not sure `ifconfig tun0 destroy` will have the effect you were hoping for; can you try this and see if it works there? The BSDs are all very different about interface destroy handling, and I can't remember which behavior OpenBSD exhibited. > ALL_TARGET = git.zx2c4.com/wireguard-go Does that do what you think it does? Shouldn't the target just be "wireguard-go"? Or is there some special-case openbsd-go handling happening? Regards, Jason
Re: WireGuard for OpenBSD
Jason A. Donenfeld writes: > Hi Anthony, > > Thanks for sending this along. Two questions: > > > ALL_TARGET = wg > > Do you need to add wg-quick as a target too? Doesn't look like it. WITH_WGQUICK is enough. > > sed -i s,git.zx2c4.com/wireguard-go,all, > > What is the purpose of this? Why do you need this? The makefile should > successfully fake a gopath. Oops, I accidentally sent out my (unfinished, broken) wireguard-go draft from last week. Attached is the working version I meant to send out. -- Anthony J. Bentley wireguard-go.tar.gz Description: wireguard-go.tar.gz
outside base directory warnings when install package "grace"
Hello: Installing the graphing package "grace" created the following warnings. This occurred in the v6.3 release. The folks on irc suggested I email this to ports@openbsd.org. Sincerely, Norm Finlay Dept of Physics and Astronomy Brandon University Brandon MB Canada # uname -a OpenBSD mirage.Brandonu.ca 6.3 GENERIC.MP#107 amd64 # pkg_add -v -i grace Update candidates: quirks-2.414 -> quirks-2.414 quirks-2.414 signed on 2018-03-28T14:24:37Z grace-5.1.15p7:t1lib-5.1.2p0: ok grace-5.1.15p7:pdflib-4.0.3p5: ok grace-5.1.15p7: ok /usr/local/man/: /usr/local/grace/doc/grace.1: outside base directory /usr/local/man/: /usr/local/grace/doc/grace.1: outside base directory /usr/local/man/: /usr/local/grace/doc/grace.1: outside base directory /usr/local/man/: /usr/local/grace/doc/grconvert.1: outside base directory system(/usr/sbin/makewhatis, -d, /usr/local/man, --, /usr/local/man/man1/xmgrace.1, /usr/local/man/man1/grace.1, /usr/local/man/man1/gracebat.1, /usr/local/man/man1/grconvert.1) failed: exit(5) Extracted 9356432 from 9358312 mirage# ls /usr/local bin grace include infolib libdata libexec man sbin share mirage# ls /usr/local/grace/ auxiliarydoc fontsgracerc.user lib bin examples gracerc include templates
[NEW] security/py-elfesteem
Hi, attached is the port of elfesteem, an elf/pe file manipulation library. it's a dependency for the incoming miasm. Ok? Cheers, Remi. py-elfesteem-0.1.tar.gz Description: application/gzip
Re: REVISION: devel/py-dtopt
On 2018/06/20 16:29, Elias M. Mariani wrote:
> Hi,
> I found a conflict between py-dtopt and py3-dtopt.
> Attached is the diff splitting the docs in separate folders for each package.
> Checking on https://pypi.org/project/dtopt/
> - The project hasn't been updated since Aug 10, 2007.
> - There is no consumers of py-dtopt.
py-webtest has this as a test dependency:
$ sqlite3 /usr/local/share/sqlports "select * from depends where dependspath
like '%dtopt%';"
www/py-webtest|devel/py-dtopt|||devel/py-dtopt|T
www/py-webtest,python3|devel/py-dtopt,python3|||devel/py-dtopt,python3|T
Also for py-webtest from a quick read of the Makefile there's a problem
apparent, TEST_DEPENDS has "devel/py-nose${MODPY_FLAVOR}" but do-test calls
${LOCALBASE}/bin/nosetests without adding MODPY_BIN_SUFFIX.
Actually, if it's always using the py2 version of nose at the moment,
presumably dtopt is being run from there, so it's probably only actually
using the py2 dtopt package anyway..
> - make search key=dtopt only finds the py version (the py3 version is
> not hooked?)
py3 support was added after /usr/ports/INDEX was last generated (12 May).
Maybe we should drop "make search" and INDEX? Or maybe "make search" could
depend on sqlports and do a query that way...
> - I think that the py3 version has errors, there is no comments on the
> compatibility with python 3 on the pypi site.
That's quite possible.
> - The repository seems to be down for a while now...
>
> The patch is made but my recommendation is to drop the port.
>
> Cheers.
> Elias.
REVISION: devel/py-dtopt
Hi, I found a conflict between py-dtopt and py3-dtopt. Attached is the diff splitting the docs in separate folders for each package. Checking on https://pypi.org/project/dtopt/ - The project hasn't been updated since Aug 10, 2007. - There is no consumers of py-dtopt. - make search key=dtopt only finds the py version (the py3 version is not hooked?) - I think that the py3 version has errors, there is no comments on the compatibility with python 3 on the pypi site. - The repository seems to be down for a while now... The patch is made but my recommendation is to drop the port. Cheers. Elias. py-dtopt.diff Description: Binary data
Re: WireGuard for OpenBSD
Hi Anthony, Thanks for sending this along. Two questions: > ALL_TARGET = wg Do you need to add wg-quick as a target too? > sed -i s,git.zx2c4.com/wireguard-go,all, What is the purpose of this? Why do you need this? The makefile should successfully fake a gopath. This install script currently "works": https://xn--4db.cc/IKuBc62Z Jason
[NEW] devel/py-llvmlite
Hi, attached is llvmlite, a dependency of the incoming miasm port. - $ pkg_info py-llvmlite Information for inst:py-llvmlite-0.23.2 Comment: lightweight LLVM-Python binding for writing JIT compilers Description: A lightweight LLVM python binding for writing JIT compilers. Maintainer: Remi Pointel WWW: http://llvmlite.pydata.org/ - Ok? Cheers, Remi. py-llvmlite-0.23.2.tar.gz Description: GNU Zip compressed data
NEW: lang/wabt
WABT is the WebAssembly Binary Toolkit, a suite of tools for WebAssembly. (see https://github.com/WebAssembly/wabt) The port includes one small patch which has already been pushed upstream. It seems to work fine, at least on amd64. wabt.tgz Description: Binary data
Re: devel/avr/gcc bug -> devel/simulavr build error
Christian Weisgerber writes:
Hello,
I may have encountered the same bug when I tried to build programs
generated with devel/arduino. cc1 aborts with a coredump during the
compilation.
I think I have found the culprits: both ISR() and SIGNAL() macros from
avr/interrupt.h use the __attribute__((signal)).
(extract from avr/interrupt.h at the end of my mail)
I don't know how much retguard nor __attribute__((signal)) work, but my
guess is that they are stepping on each others foot.
Once I removed the signal attribute form the ISR and SIGNAL macros, I
was also able to compile the programs generated with devel/arduino
without coredump but it doesn't work on the arduino, I guess the
attribute wasn't there for nothing
When I looked at devel/simulavr source code, the only occurence of the
ISR() macro was in the tests. I was able to build devel/simulavr by
disabling the tests (./configure --disable-tests). However, I wasn't
able to test it because the documentation is for a newer version
(1.0.0), so I end up upgrading devel/simulavr which does work (patch
attached).
Best,
avr/interrupt.h:
/** \def ISR(vector [, attributes])
\ingroup avr_interrupts
Introduces an interrupt handler function (interrupt service
routine) that runs with global interrupts initially disabled
by default with no attributes specified.
The attributes are optional and alter the behaviour and resultant
generated code of the interrupt routine. Multiple attributes may
be used for a single function, with a space seperating each
attribute.
Valid attributes are ISR_BLOCK, ISR_NOBLOCK, ISR_NAKED and
ISR_ALIASOF(vect).
\c vector must be one of the interrupt vector names that are
valid for the particular MCU type.
*/
# define ISR(vector, [attributes])
#else /* real code */
#if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4)
# define __INTR_ATTRS used, externally_visible
#else /* GCC < 4.1 */
# define __INTR_ATTRS used
#endif
#ifdef __cplusplus
# define ISR(vector, ...)\
extern "C" void vector (void) __attribute__ ((signal,__INTR_ATTRS))
__VA_ARGS__; \
void vector (void)
#else
# define ISR(vector, ...)\
void vector (void) __attribute__ ((signal,__INTR_ATTRS)) __VA_ARGS__; \
void vector (void)
#endif
#endif /* DOXYGEN */
#if defined(__DOXYGEN__)
/** \def SIGNAL(vector)
\ingroup avr_interrupts
Introduces an interrupt handler function that runs with global interrupts
initially disabled.
This is the same as the ISR macro without optional attributes.
\deprecated Do not use SIGNAL() in new code. Use ISR() instead.
*/
# define SIGNAL(vector)
#else /* real code */
#ifdef __cplusplus
# define SIGNAL(vector)\
extern "C" void vector(void) __attribute__ ((signal, __INTR_ATTRS));
\
void vector (void)
#else
# define SIGNAL(vector)\
void vector (void) __attribute__ ((signal, __INTR_ATTRS)); \
void vector (void)
#endif
>From ac3304a63bdfbf45f2f6c18e370e81f4292262cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?=
Date: Tue, 19 Jun 2018 19:53:25 +0200
Subject: [PATCH] Update devel/simulavr to 1.0.0
---
devel/simulavr/Makefile| 14 +-
devel/simulavr/distinfo| 4 +-
devel/simulavr/patches/patch-configure | 25
devel/simulavr/patches/patch-src_cmd_gdbserver_cpp | 147 +
devel/simulavr/patches/patch-src_eeprom_c | 16 ---
devel/simulavr/patches/patch-src_flash_c | 16 ---
devel/simulavr/patches/patch-src_memory_c | 16 ---
devel/simulavr/patches/patch-src_systemclock_cpp | 16 +++
devel/simulavr/pkg/PLIST | 119 +
9 files changed, 265 insertions(+), 108 deletions(-)
delete mode 100644 devel/simulavr/patches/patch-configure
create mode 100644 devel/simulavr/patches/patch-src_cmd_gdbserver_cpp
delete mode 100644 devel/simulavr/patches/patch-src_eeprom_c
delete mode 100644 devel/simulavr/patches/patch-src_flash_c
delete mode 100644 devel/simulavr/patches/patch-src_memory_c
create mode 100644 devel/simulavr/patches/patch-src_systemclock_cpp
diff --git a/devel/simulavr/Makefile b/devel/simulavr/Makefile
index ec274bee33e..8c3f7df091e 100644
--- a/devel/simulavr/Makefile
+++ b/devel/simulavr/Makefile
@@ -2,7 +2,7 @@
COMMENT= AVR simulator
-DISTNAME= simulavr-0.1.2.7
+DISTNAME= simulavr-1.0.0
CATEGORIES= devel
HOMEPAGE= http://www.nongnu.org/simulavr/
@@ -13,21 +13,21 @@ PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES= ${MASTER_SITE_SAVANNAH:=simulavr/}
WANTLIB= c ncurses
+SHARED_LIBS += sim 0.0
CONFIGURE_STYLE= gnu
-CONFIGURE_ARGS+= --enable-curses=yes \
- --disable-versioned-doc
+CONFIGURE_ARGS+= --with-bfd=${LOCALBASE}
+MAKE_FLAGS= LANGUAGES="c c++" CFLAGS="-Wnomacro-redefined"
USE_GMAKE= Yes
BUILD_DEPENDS=
Re: NEW: security/tclpledge & security/jimpledge
oing > -- Original Message -- > From: Stuart Cassoff <3...@bell.net> > Date: June 12, 2018 at 2:43 PM > > > Now without the confusing TESTFLAGS bits. > > Stu > > > > -- Original Message -- > > From: Stuart Cassoff <3...@bell.net> > > Date: June 11, 2018 at 1:02 PM > > > > > > Ping on these, they're real simple. > > > > > -- Original Message -- > > > From: Stuart Cassoff <3...@bell.net> > > > Date: June 9, 2018 at 4:59 AM > > > > > > > > > Forgot to mention that they've been tested on amd64 and i386, but only on > > > Earth. > > > > > > > > > Stu > > > > > > > > > > -- Original Message -- > > > > From: Stuart Cassoff <3...@bell.net> > > > > Date: June 7, 2018 at 1:29 AM > > > > > > > > > > > > Tcl and Jim interfaces to pledge(2). > > > > > > > > Stu > > > > >
Re: textproc/go-text usage issues
On 2018/06/20 01:07, Anthony J. Bentley wrote: > On Fri, Jun 15, 2018 at 4:41 AM, Anthony J. Bentley > wrote: > > I don't know anything about Go, but it seems that our textproc/go-text > > package relies on some modules that should be in devel/go-tools, yet > > aren't. > > It looks like the fix for this might be just to set "MODGO_TYPE = bin lib". > > Fake seems to expect a "pkg" directory that isn't there, but this > patch fixes the problem I was seeing. > > Go people, is this correct? I am not a Go person but FWIW this seems correct to me .. So OK from me but I will defer to someone who knows this stuff better :)
sysutils/glide
glide.tgz Description: Binary data
Re: WireGuard for OpenBSD
Stuart Henderson writes: > bentley@ sent a port of wireguard-tools shortly after Jason's first mail Here's my latest revision. I think everything's working now--I've tested communication with the Android app, at least. This requires the go-tools patch I just sent to the list. -- Anthony J. Bentley wireguard-go.tar.gz Description: wireguard-go.tar.gz wireguard-tools.tar.gz Description: wireguard-tools.tar.gz
Re: textproc/go-text usage issues
On Fri, Jun 15, 2018 at 4:41 AM, Anthony J. Bentley wrote: > I don't know anything about Go, but it seems that our textproc/go-text > package relies on some modules that should be in devel/go-tools, yet > aren't. It looks like the fix for this might be just to set "MODGO_TYPE = bin lib". Fake seems to expect a "pkg" directory that isn't there, but this patch fixes the problem I was seeing. Go people, is this correct? -- Anthony J. Bentley go-tools.diff Description: Binary data
