Re: New: devel/p5-JSON-RPC2 -JSON-RPC 2.0 Perl module
On 13 Jun at 21:54, Andrew Hewus Fresh wrote: > On Sun, Jun 13, 2021 at 09:17:44PM +0200, Mischa wrote: > > On 13 Jun at 20:45, Andrew Hewus Fresh wrote: > > > On Sun, Jun 13, 2021 at 03:40:22PM +0200, Mischa wrote: > > > > This module implement JSON-RPC 2.0 protocol in transport-independent > > > > way. > > > > > > > > Also it support non-blocking client remote procedure call and both > > > > blocking and non-blocking server method execution. This can be very > > > > useful in case server methods will need to do some RPC or other > > > > slow things like network I/O, which can be done in parallel with > > > > executing other server methods in any event-based environment. > > > > > > > > meta::cpan: https://metacpan.org/pod/JSON::RPC2 > > > > > > > > JSON RPC is for example needed to use the eAPI from Arista. > > > > > > > > Any comments / suggestions welcome! > > > > > > Most of the other JSON perl modules are in converters, not devel. This > > > one should probably go there as well. > > > > That was my first instict as well, until I checked some of the other > > JSON RPC packages and they are all in devel, so was a little > > conflicted. Using converters now as it does make more sense considering > > the other JSON Perl modules. > > Well, the perl RPC ports I see are in net/, so not really sure where > the best place is. Perhaps someone else will chime in. Attached are two tgz's converters-p5-JSON-RPC2.tgz and net-p5-JSON-RPC2.tgz Not sure if this makes sense this way, let me know it doesn't. > I might recommend that you add yourself as MAINTAINER, but that's not > necessary. Done! > > > New tgz attached. > > I'm not sure about the DESCR, might be better with the second paragraph > as well, or more specifically exactly what you included above. Good catch. Mischa > If someone else has an opinion, mine aren't strongly held on either of > those points and we can go with theirs. > > OK afresh1@ whichever way those two things go, if someone wants to > decide and commit. > > l8rZ, > -- > andrew - http://afresh1.com > > Speed matters. > Almost as much as some things, and nowhere near as much as others. > -- Nick Holland converters-p5-JSON-RPC2.tgz Description: application/tar-gz net-p5-JSON-RPC2.tgz Description: application/tar-gz
[update] telephony/bcg729 1.1.1
Hi,
this update allows linphone's mediastreamer2 lib to correctly find
bcg729, the version we ship is more than 5 years old now.
switched to cmake and removes the BDEP on net/ortp which i didnt even
notice when porting linphone bits, afaict the latter isnt used by
anything in the portstree. Once bctoolbox is in (a new ortp dep) i can
update net/ortp or move it to telephony/linphone/ortp as in my previous
submission.
the 'fetch additional files if you want to run tests' is somewhat
clever.. and ofc all tests pass. Currently building pjsip and wireshark,
can someone using asterisk-g729 check that it works with this update ?
stuart ? :)
Landry
? bcg729-1.0.2-libbcg729.so.0.1
? bcg729-1.1.1-libbcg729.so.0.1
Index: Makefile
===
RCS file: /cvs/ports/telephony/bcg729/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile14 Jul 2019 00:39:40 - 1.6
+++ Makefile14 Jun 2021 06:40:40 -
@@ -2,33 +2,34 @@
COMMENT= software G729A encoder and decoder library
-DISTNAME= bcg729-1.0.2
+V= 1.1.1
+DISTNAME= bcg729-${V}
SHARED_LIBS += bcg7290.1 # unknown
CATEGORIES=telephony audio
-HOMEPAGE= http://www.linphone.org/technical-corner/bcg729/overview
+HOMEPAGE= http://www.linphone.org/technical-corner/bcg729/
# Dual: GPLv2(only) or commercial
PERMIT_PACKAGE=Yes
-MASTER_SITES=
http://download-mirror.savannah.gnu.org/releases/linphone/plugins/sources/
+MASTER_SITES = https://gitlab.linphone.org/BC/public/bcg729/-/archive/${V}/
-BUILD_DEPENDS= net/ortp
+MODULES = devel/cmake
+CONFIGURE_ARGS +=-DENABLE_TESTS=YES
-CONFIGURE_STYLE= gnu
-CONFIGURE_ARGS=--disable-msplugin
-
-# Use bundled libtool for the tests only; otherwise they fail to link.
-TEST_FLAGS=LIBTOOL="/bin/sh ../../libtool"
TEST_IS_INTERACTIVE= Yes
pre-test:
- @if ! [ -d ${WRKSRC}/test/patterns ]; then echo; echo \
+ @if ! [ -e ${WRKBUILD}/test/patterns ]; then echo; echo \
">>> Tests require an additional download. Please fetch"; echo \
- ">>>
http://www.belledonne-communications.com/downloads/bcg729-patterns.zip";; echo \
- ">>> and unzip it in ${WRKSRC}/test"; \
+ ">>> http://linphone.org/bc-downloads/bcg729-patterns-v1.1.0.zip";;
echo \
+ ">>> and unzip it in ${WRKBUILD}/test"; echo \
+ "#ftp -o ${WRKBUILD}/test/bcg729-patterns-v1.1.0.zip
http://linphone.org/bc-downloads/bcg729-patterns-v1.1.0.zip"; ; echo \
+ "#unzip -d ${WRKBUILD}test/
${WRKBUILD}/test/bcg729-patterns-v1.1.0.zip" \
echo; exit 1; fi
+do-test:
+ cd ${WRKBUILD}/test && sh ./testCampaignAll
.include
Index: distinfo
===
RCS file: /cvs/ports/telephony/bcg729/distinfo,v
retrieving revision 1.3
diff -u -r1.3 distinfo
--- distinfo6 Aug 2017 20:09:40 - 1.3
+++ distinfo14 Jun 2021 06:40:40 -
@@ -1,2 +1,2 @@
-SHA256 (bcg729-1.0.2.tar.gz) = d8kj7cV6UwFNpfMXiLY++6v8cnfAberq2gZXRijksD8=
-SIZE (bcg729-1.0.2.tar.gz) = 474851
+SHA256 (bcg729-1.1.1.tar.gz) = aFmahQU10bGCkys/hlWKyKdtS4maVIGDsGKVbF/ckW0=
+SIZE (bcg729-1.1.1.tar.gz) = 122475
Index: patches/patch-test_testCampaignAll
===
RCS file: patches/patch-test_testCampaignAll
diff -N patches/patch-test_testCampaignAll
--- patches/patch-test_testCampaignAll 10 Oct 2015 13:00:04 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,9 +0,0 @@
-$OpenBSD: patch-test_testCampaignAll,v 1.1 2015/10/10 13:00:04 sthen Exp $
test/testCampaignAll.orig Sat Oct 10 13:44:54 2015
-+++ test/testCampaignAll Sat Oct 10 13:45:03 2015
-@@ -1,4 +1,4 @@
--#! /bin/bash
-+#!/bin/sh
- # This script check if we have the tests patterns and download them if needed
- # then run all available tests
-
Index: patches/patch-test_testCampaignAll_cmake
===
RCS file: patches/patch-test_testCampaignAll_cmake
diff -N patches/patch-test_testCampaignAll_cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-test_testCampaignAll_cmake14 Jun 2021 06:40:40 -
@@ -0,0 +1,11 @@
+$OpenBSD$
+
+Index: test/testCampaignAll.cmake
+--- test/testCampaignAll.cmake.orig
test/testCampaignAll.cmake
+@@ -1,4 +1,4 @@
+-#! /bin/bash
++#!/bin/sh
+ # This script check if we have the tests patterns and download them if needed
+ # then run all available tests
+
Index: pkg/PLIST
===
RCS file: /cvs/ports/telephony/bcg729/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 PLIST
--- pkg/PLIST 10 Oct 2015 12:33:16 - 1.1.1.1
+++ pkg/PLIST 14 Jun 2021 06:40:40 -
@@ -2,7 +2,12 @@
include/bcg729/
include/bcg729/decoder.h
include/bcg729/encoder.h
-
[wip] telephony/linphone 4.2.5
Hi, here's a wip port of the complete linphone SIP client stack from https://www.linphone.org, current things to improve: - it heavily relies on ipv6-to-v4 mapping, so i had to default everything to ipv4 otherwise things blow here and there. There's been many tries for that, so maybe some patches arent relevant anymore, with the current status it connects fine to a SIP server over v4. - there's a circular dependency between bctoolbox and bcunit, so testing of components cant be built by default (but it allowed me to debug previous point so ..) - hence not building bcunit and commenting out the bits enabling testing. - the client itself works but with pulseaudio, for some reason recording doesnt work so when calling a real phone you only hear the remote but the remote cant hear you. Dunno if recording is supposed to work with pulseaudio, but the plan is to write a sndio backend, cf telephony/linphone/mediastreamer2/patches/patch-src_audiofilters_sndio_c for a skeleton. poke ratchov@ :) - i need to figure out why Bcg729 isnt picked up - havent been able to test video, havent poked at the v4l bits - there's an annoying bdep on doxygen that i didnt manage to remove everywhere - there's a bdep for pystache, which i ported but its last release was in 2014.. yay for bringing zombies to the ports tree, at least it works with py3. Comments on the naming welcome (went for py-stache) Feedback welcome ! Landry linphone-4.2.5.tgz Description: application/tar-gz
Re: [fix, macppc] Unbreak devel/sdl{1,2} on Mac G3s
On Sat, 12 Jun 2021 12:03:01 +
Charlene Wendling wrote:
> You were right, SDL 1.x is impacted as well. I've updated the diff
> below to include SDL 1.x. It has been tested successfully against
> frozen-bubble and tutris. xmoto fails with:
ok gkoehler@
and thanks for trying so many packages!
I didn't know which packages used SDL 1.x.
> Program received signal SIGILL, Illegal instruction.
> 0x9830c5f0 in jsimd_idct_ifast_altivec ()
> from /usr/local/lib/libjpeg.so.70.0
>
> So i know what's up next, but given a lot of stuff depend on libjpeg, it
> should be way longer, since i may need to rebuild almost all my
> current packages ;)
This libjpeg crash might be a false positive (from the no-ALTIVEC
kernel bug), so it might go away with Matthieu Herrb's diff on bugs@.
I am running no-ALTIVEC with the diff, but here xmoto crashes in
libLLVM.so.5.0 because I don't have radeondrm. (I know that OpenGL,
on macppc without radeondrm, always crashes in libLLVM.)
I have a PowerBook G4 with radeondrm, but I didn't use it for this
no-ALTIVEC trial. I also have a G3, but it doesn't power on.
By doing $ objdump -dlr /usr/local/lib/libjpeg.so.70.0 |less
and searching for '[, ]v[0-9]', it looks like libjpeg uses altivec
only in its *_altivec() functions. If it knows not to call
*_altivec() on G3, it wouldn't crash.
--George
>
> Charlène.
>
>
> Index: devel/sdl2/Makefile
> ===
> RCS file: /cvs/ports/devel/sdl2/Makefile,v
> retrieving revision 1.34
> diff -u -p -r1.34 Makefile
> --- devel/sdl2/Makefile 23 Jan 2021 17:47:43 - 1.34
> +++ devel/sdl2/Makefile 12 Jun 2021 12:01:33 -
> @@ -5,7 +5,7 @@ COMMENT= cross-platform multimedia libra
> V= 2.0.14
> DISTNAME=SDL2-${V}
> PKGNAME= sdl2-${V}
> -REVISION=1
> +REVISION=2
> CATEGORIES= devel
> MASTER_SITES=https://www.libsdl.org/release/
>
> @@ -50,6 +50,13 @@ CONFIGURE_ENV+=CPPFLAGS="-I${LOCALBASE}
>
> .if ${MACHINE_ARCH} == "hppa"
> CONFIGURE_ARGS+= --disable-atomic
> +.endif
> +
> +# The assembly code contains AltiVec instructions, whose support is not
> +# properly detected at runtime. Fix SIGILLs on macppc G3s, while keeping
> +# it for powerpc64.
> +.if ${MACHINE_ARCH} == "powerpc"
> +CONFIGURE_ARGS+= --enable-altivec=no
> .endif
>
> # tests in test subdir, but interactive and not hooked up to build
> Index: devel/sdl/Makefile
> ===
> RCS file: /cvs/ports/devel/sdl/Makefile,v
> retrieving revision 1.105
> diff -u -p -r1.105 Makefile
> --- devel/sdl/Makefile23 Jan 2021 17:52:00 - 1.105
> +++ devel/sdl/Makefile12 Jun 2021 12:01:33 -
> @@ -5,7 +5,7 @@ COMMENT= cross-platform multimedia libra
> VERSION= 1.2.15
> DISTNAME=SDL-${VERSION}
> PKGNAME= ${DISTNAME:L}
> -REVISION=11
> +REVISION=12
> CATEGORIES= devel
> MAINTAINER= Thomas Frohwein
> MASTER_SITES=${HOMEPAGE}release/
> @@ -64,6 +64,13 @@ WANTLIB+= X11 Xau Xdmcp Xext Xrandr Xren
> .endif
>
> NO_TEST= Yes
> +
> +# The assembly code contains AltiVec instructions, whose support is not
> +# properly detected at runtime. Fix SIGILLs on macppc G3s, while keeping
> +# it for powerpc64.
> +.if ${MACHINE_ARCH} == "powerpc"
> +CONFIGURE_ARGS+= --enable-altivec=no
> +.endif
>
> pre-configure:
> @mkdir -p ${WRKSRC}/src/audio/sndio
>
>
--
George Koehler
[no subject]
Hola SSH hash tags
Re: [update] ansible-4.1.0
> On Jun 13, 2021, at 5:20 PM, Stuart Henderson wrote: > > On 2021/06/13 14:20, Daniel Dickman wrote: >>> On Sun, Jun 13, 2021 at 12:58 PM Pavel Korovin wrote: >>> >>> On 06/13, Johnathan C. Maudlin wrote: Has it become vital to move off of Ansible 2.9.x? Currently in Linux land, specifically when looking at Fedora/CentOS and Ubuntu, they are all still providing Ansible 2.9.x and I would assume Fedora would be the first to move off of 2.9.x if there was a pressing need to do so. In my humble opinion, I think it might be reasonable to continue with the Ansible 2.9.x branch as users who rely on a newer version can do so using virtualenv and other such mechanisms. >>> >>> Johnathan, >>> The main reason for me to switch is the fact that ansible-2.9 will not >>> receive bugfixes except the security ones. Earlier or later ansible >>> community will stop supporting v2.9 and we'll have to switch anyway. >>> https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-release-cycle >>> >> >> ansible 2.9 is a blocker for updating py-sphinx to the 4.x series. >> > > Probably not the only thing blocking updating sphinx, with the "Support > for evaluating Python 2 syntax is deprecated and will be removed in > Sphinx 4.0" warnings seen in the current version.. > To clarify, ansible is the only thing left in my local tree. ghc was recently updated so is no longer an issue and I have trivial diffs for the other 3 affected ports. Note that the idea would be to go to Sphinx 4.0.1 as 4.0.2 will require plist updates in some of the consumers.
Re: [update] ansible-4.1.0
On 2021/06/13 14:20, Daniel Dickman wrote: > On Sun, Jun 13, 2021 at 12:58 PM Pavel Korovin wrote: > > > > On 06/13, Johnathan C. Maudlin wrote: > > > Has it become vital to move off of Ansible 2.9.x? Currently in Linux > > > land, specifically when looking at Fedora/CentOS and Ubuntu, they are > > > all still providing Ansible 2.9.x and I would assume Fedora would be the > > > first to move off of 2.9.x if there was a pressing need to do so. > > > > > > In my humble opinion, I think it might be reasonable to continue with > > > the Ansible 2.9.x branch as users who rely on a newer version can do so > > > using virtualenv and other such mechanisms. > > > > Johnathan, > > The main reason for me to switch is the fact that ansible-2.9 will not > > receive bugfixes except the security ones. Earlier or later ansible > > community will stop supporting v2.9 and we'll have to switch anyway. > > https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-release-cycle > > > > ansible 2.9 is a blocker for updating py-sphinx to the 4.x series. > Probably not the only thing blocking updating sphinx, with the "Support for evaluating Python 2 syntax is deprecated and will be removed in Sphinx 4.0" warnings seen in the current version..
Re: [sparc64/base-gcc] Fix build of audio/mpg123
On Sat, Jun 12, 2021 at 11:20:19PM +0200, Christian Weisgerber wrote: > Kurt Mosiejczuk: > > The most recent version of mpg123 uses C99 for loop initialization. > It already did before. > The issue here is that upstream changed configure.ac to be compatible > with autoconf 2.71, then went back and used 2.69. > * With 2.71, AC_PROG_CC tries to enable C89/C99/C11 and AC_PROG_CC_C99 > is a nop. > * With 2.69, AC_PROG_CC only tries to enable C89 and you need to use > AC_PROG_CC_C99 to get C99. > I prefer to let the configure script handle this as intended. > OK? ok kmos --Kurt > Index: Makefile > === > RCS file: /cvs/ports/audio/mpg123/Makefile,v > retrieving revision 1.107 > diff -u -p -r1.107 Makefile > --- Makefile 11 Jun 2021 20:55:07 - 1.107 > +++ Makefile 12 Jun 2021 21:12:56 - > @@ -20,7 +20,8 @@ EXTRACT_SUFX= .tar.bz2 > > WANTLIB= c m sndio > > -CONFIGURE_STYLE=gnu > +AUTOCONF_VERSION=2.69 > +CONFIGURE_STYLE=autoconf > CONFIGURE_ARGS= --enable-static \ > --disable-lfs-alias \ > --with-audio=sndio \ > Index: patches/patch-configure_ac > === > RCS file: patches/patch-configure_ac > diff -N patches/patch-configure_ac > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-configure_ac12 Jun 2021 21:12:56 - > @@ -0,0 +1,15 @@ > +$OpenBSD$ > + > +With autoconf 2.69, AC_PROG_CC only enables C89. > + > +Index: configure.ac > +--- configure.ac.orig > configure.ac > +@@ -105,6 +105,7 @@ fi > + AM_PROG_AS > + dnl We really mean C99 here. The specific macro for that is gone. > + AC_PROG_CC > ++AC_PROG_CC_C99 > + AM_PROG_CC_C_O > + AC_PROG_CPP > + AC_PROG_INSTALL > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: [update] ansible-4.1.0
Pavel Korovin writes: > Dear all, > > Ansible project was significantly restructured after v2.9. > Starting with ansible-2.10, the project was split into the core engine > (called ansible-base in v2.10, and renamed to ansible-core in v2.11), > which contains essential code needed to run collections and > ansible collections, e.g. community.aws, community.vmware etc. > > Since v2.10 what is called ansible is a python package which contains selected > list of ansible collections and depends on ansible-core package: > https://pypi.org/project/ansible-core/ > https://pypi.org/project/ansible/ > The core enginge and collections have different versioning schemes: > ansible v3 depends on ansible-core v2.10 and ansible v4 depends on > ansible-core v2.11. > > More on ansible project restructurization: > https://www.ansible.com/blog/ansible-3.0.0-qa > > Ansible Collections Overview: > https://github.com/ansible-collections/overview > > [...] Has it become vital to move off of Ansible 2.9.x? Currently in Linux land, specifically when looking at Fedora/CentOS and Ubuntu, they are all still providing Ansible 2.9.x and I would assume Fedora would be the first to move off of 2.9.x if there was a pressing need to do so. In my humble opinion, I think it might be reasonable to continue with the Ansible 2.9.x branch as users who rely on a newer version can do so using virtualenv and other such mechanisms.
Re: New: devel/p5-JSON-RPC2 -JSON-RPC 2.0 Perl module
On Sun, Jun 13, 2021 at 09:17:44PM +0200, Mischa wrote: > On 13 Jun at 20:45, Andrew Hewus Fresh wrote: > > On Sun, Jun 13, 2021 at 03:40:22PM +0200, Mischa wrote: > > > This module implement JSON-RPC 2.0 protocol in transport-independent > > > way. > > > > > > Also it support non-blocking client remote procedure call and both > > > blocking and non-blocking server method execution. This can be very > > > useful in case server methods will need to do some RPC or other > > > slow things like network I/O, which can be done in parallel with > > > executing other server methods in any event-based environment. > > > > > > meta::cpan: https://metacpan.org/pod/JSON::RPC2 > > > > > > JSON RPC is for example needed to use the eAPI from Arista. > > > > > > Any comments / suggestions welcome! > > > > Most of the other JSON perl modules are in converters, not devel. This > > one should probably go there as well. > > That was my first instict as well, until I checked some of the other > JSON RPC packages and they are all in devel, so was a little > conflicted. Using converters now as it does make more sense considering > the other JSON Perl modules. Well, the perl RPC ports I see are in net/, so not really sure where the best place is. Perhaps someone else will chime in. I might recommend that you add yourself as MAINTAINER, but that's not necessary. > New tgz attached. I'm not sure about the DESCR, might be better with the second paragraph as well, or more specifically exactly what you included above. If someone else has an opinion, mine aren't strongly held on either of those points and we can go with theirs. OK afresh1@ whichever way those two things go, if someone wants to decide and commit. l8rZ, -- andrew - http://afresh1.com Speed matters. Almost as much as some things, and nowhere near as much as others. -- Nick Holland
Re: split math/py-numpy
Le Sun, Jun 13, 2021 at 01:24:21PM -0400, Daniel Dickman a écrit : > I'd like to go ahead and split numpy into python2 and python3 ports so we > can unblock updating numpy. > > Attached is the py2-numpy port with the main diff being shown below. After > this goes in I can update the py3 port and the various consumers. > > ok? Definitely !
Re: UPDATE: syncthing-1.17.0
On Fri 11/06/2021 22:14, Edd Barrett wrote: > Hi, > > Simple update to syncthing's latest. > > Note that the cli binary was merged into the main program. Use it with > `synchting cli `. > > Tests passing on amd64. I'll be use testing it over the next few days. > > Commments or OKs? Works here, OK bket@
Re: New: devel/p5-JSON-RPC2 -JSON-RPC 2.0 Perl module
On 13 Jun at 20:45, Andrew Hewus Fresh wrote:
> On Sun, Jun 13, 2021 at 03:40:22PM +0200, Mischa wrote:
> > This module implement JSON-RPC 2.0 protocol in transport-independent
> > way.
> >
> > Also it support non-blocking client remote procedure call and both
> > blocking and non-blocking server method execution. This can be very
> > useful in case server methods will need to do some RPC or other
> > slow things like network I/O, which can be done in parallel with
> > executing other server methods in any event-based environment.
> >
> > meta::cpan: https://metacpan.org/pod/JSON::RPC2
> >
> > JSON RPC is for example needed to use the eAPI from Arista.
> >
> > Any comments / suggestions welcome!
>
> Most of the other JSON perl modules are in converters, not devel. This
> one should probably go there as well.
That was my first instict as well, until I checked some of the other
JSON RPC packages and they are all in devel, so was a little
conflicted. Using converters now as it does make more sense considering
the other JSON Perl modules.
> The COMMENT starts with a capital letter, it shouldn't.
> See item #16: http://www.openbsd.org/faq/ports/guide.html#PortsChecklist
Got it!
> Usually perl ports don't need to set BUILD_DEPENDS=${RUN_DEPENDS},
> and in this case that seems to be true. It doesn't hurt anything, just
> makes bulk builds take slightly longer than than need to.
Argh... Artifact from me working around the errors I got.
Removed.
> Something was telling the truth though, as we do need a RUN_DEPENDS on
> p5-JSON-Maybe-XS instead of p5-JSON-XS because as it is, `make test`
> fails if that isn't installed.
Reverted to what it was orginally.
> Other than those nits, it looks good to me.
Great! :)
> > Mischa
> >
> > PS: Thank you Andrew for your guidance so far!
>
> You're welcome!
>
> I did commit a fix so portgen should properly set the CONFIGURE_STYLE if
> p5-Module-Build-Tiny isn't installed and needs to be. Thanks for
> reporting that!
Nice!
New tgz attached.
Mischa
>
>
> l8rZ,
> --
> andrew - http://afresh1.com
>
> Real programmers don't document.
> If it was hard to write, it should be hard to understand.
>
p5-JSON-RPC2.tgz
Description: application/tar-gz
Firefox crashes
Firefox from snapshot Fri Jun 11 08:31:52 MDT 2021 is crashing spontaneously on the following three tabs: https://www.tarptent.com/product/notch/#tab-id-3 https://www.google.com/search?client=firefox-b-1-d&q=four+season+tents https://seatosummitusa.com/products/ultralight-insulated-mat?variant=7896105484316 This is when not running anything in particular. Message: Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=179.718) [GFX1-]: Receive IPC close with reason=AbnormalShutdown Exiting due to channel error. Segmentation fault (core dumped) -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: New: devel/p5-JSON-RPC2 -JSON-RPC 2.0 Perl module
On Sun, Jun 13, 2021 at 03:40:22PM +0200, Mischa wrote:
> This module implement JSON-RPC 2.0 protocol in transport-independent
> way.
>
> Also it support non-blocking client remote procedure call and both
> blocking and non-blocking server method execution. This can be very
> useful in case server methods will need to do some RPC or other
> slow things like network I/O, which can be done in parallel with
> executing other server methods in any event-based environment.
>
> meta::cpan: https://metacpan.org/pod/JSON::RPC2
>
> JSON RPC is for example needed to use the eAPI from Arista.
>
> Any comments / suggestions welcome!
Most of the other JSON perl modules are in converters, not devel. This
one should probably go there as well.
The COMMENT starts with a capital letter, it shouldn't.
See item #16: http://www.openbsd.org/faq/ports/guide.html#PortsChecklist
Usually perl ports don't need to set BUILD_DEPENDS=${RUN_DEPENDS},
and in this case that seems to be true. It doesn't hurt anything, just
makes bulk builds take slightly longer than than need to.
Something was telling the truth though, as we do need a RUN_DEPENDS on
p5-JSON-Maybe-XS instead of p5-JSON-XS because as it is, `make test`
fails if that isn't installed.
Other than those nits, it looks good to me.
>
> Mischa
>
> PS: Thank you Andrew for your guidance so far!
You're welcome!
I did commit a fix so portgen should properly set the CONFIGURE_STYLE if
p5-Module-Build-Tiny isn't installed and needs to be. Thanks for
reporting that!
l8rZ,
--
andrew - http://afresh1.com
Real programmers don't document.
If it was hard to write, it should be hard to understand.
Re: [update] ansible-4.1.0
On Sun, Jun 13, 2021 at 12:58 PM Pavel Korovin wrote: > > On 06/13, Johnathan C. Maudlin wrote: > > Has it become vital to move off of Ansible 2.9.x? Currently in Linux > > land, specifically when looking at Fedora/CentOS and Ubuntu, they are > > all still providing Ansible 2.9.x and I would assume Fedora would be the > > first to move off of 2.9.x if there was a pressing need to do so. > > > > In my humble opinion, I think it might be reasonable to continue with > > the Ansible 2.9.x branch as users who rely on a newer version can do so > > using virtualenv and other such mechanisms. > > Johnathan, > The main reason for me to switch is the fact that ansible-2.9 will not > receive bugfixes except the security ones. Earlier or later ansible > community will stop supporting v2.9 and we'll have to switch anyway. > https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-release-cycle > ansible 2.9 is a blocker for updating py-sphinx to the 4.x series.
split math/py-numpy
I'd like to go ahead and split numpy into python2 and python3 ports so we
can unblock updating numpy.
Attached is the py2-numpy port with the main diff being shown below. After
this goes in I can update the py3 port and the various consumers.
ok?
diff -x CVS -Nur py-numpy/Makefile py2-numpy/Makefile
--- py-numpy/Makefile Sun Jun 13 13:13:33 2021
+++ py2-numpy/Makefile Sun Jun 13 13:04:40 2021
@@ -1,6 +1,6 @@
# $OpenBSD: Makefile,v 1.61 2021/05/21 19:50:32 kmos Exp $
-COMMENT= fast array and numeric programming library for Python
+COMMENT= fast array and numeric programming library for Python 2
MODPY_EGG_VERSION= 1.16.6
DISTNAME= numpy-${MODPY_EGG_VERSION}
@@ -20,9 +20,7 @@
MODULES= lang/python \
fortran
-FLAVORS= python3
-FLAVOR = python3
-
+MODPY_VERSION =${MODPY_DEFAULT_VERSION_2}
MODPY_PI = Yes
MODPY_SETUPTOOLS= Yes
MODPY_DISTUTILS_BUILDARGS = --fcompiler=gnu95
diff -x CVS -Nur py-numpy/pkg/PLIST py2-numpy/pkg/PLIST
--- py-numpy/pkg/PLIST Mon Jan 4 09:06:34 2021
+++ py2-numpy/pkg/PLIST Sun Jun 13 13:11:59 2021
@@ -1,103 +1,87 @@
+@pkgpath math/py-numpy
py2-numpy.tgz
Description: Binary data
Re: [update] ansible-4.1.0
On 06/13, Johnathan C. Maudlin wrote: > Has it become vital to move off of Ansible 2.9.x? Currently in Linux > land, specifically when looking at Fedora/CentOS and Ubuntu, they are > all still providing Ansible 2.9.x and I would assume Fedora would be the > first to move off of 2.9.x if there was a pressing need to do so. > > In my humble opinion, I think it might be reasonable to continue with > the Ansible 2.9.x branch as users who rely on a newer version can do so > using virtualenv and other such mechanisms. Johnathan, The main reason for me to switch is the fact that ansible-2.9 will not receive bugfixes except the security ones. Earlier or later ansible community will stop supporting v2.9 and we'll have to switch anyway. https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-release-cycle >From my experience, the code is stable enough to make a switch now. -- With best regards, Pavel Korovin
New: devel/p5-JSON-RPC2 -JSON-RPC 2.0 Perl module
This module implement JSON-RPC 2.0 protocol in transport-independent way. Also it support non-blocking client remote procedure call and both blocking and non-blocking server method execution. This can be very useful in case server methods will need to do some RPC or other slow things like network I/O, which can be done in parallel with executing other server methods in any event-based environment. meta::cpan: https://metacpan.org/pod/JSON::RPC2 JSON RPC is for example needed to use the eAPI from Arista. Any comments / suggestions welcome! Mischa PS: Thank you Andrew for your guidance so far! p5-JSON-RPC2.tgz Description: application/tar-gz
Re: UPDATE: syncthing-1.17.0
> Tests passing on amd64. I'll be use testing it over the next few days. > > Commments or OKs? It has been running for 24 hours here without issue (on amd64). -- Alex Holst
