Re: net/nextcloudclient build failure
On Fri Apr 09, 2021 at 09:35:53PM +0200, Christian Weisgerber wrote: > net/nextcloudclient failed to build in my latest amd64 bulk build. > > ===> Faking installation for nextcloudclient-3.1.3 > [0/1] /usr/local/bin/cmake --regenerate-during-build > -S/usr/obj/ports/nextcloudclient-3.1.3/desktop-3.1.3 > -B/usr/obj/ports/nextcloudclient-3.1.3/build-amd64 > > ... and then it goes off the rails. Full log attached. > > This looks like it shares the same root cause as the audio/hydrogen > failure I just sent to ports@. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de To me it looks like the build directory was corrupted after the build task and cmake re-run/try the configure task. Also not reproducible here.
Re: net/nextcloudclient build failure
Hi Christian, Thank you for reporting the build failure. The build and fake process run normally here (OpenBSD 6.9 (GENERIC.MP) #459: Fri Apr 9 11:31:33 MDT 2021 and updated ports tree) and I could not reproduce the problem. The versions of cmake and all other dependencies that you use are the same as the ones on my machine. I can't figure out why you are getting this error and I confess that I don't understand exactly how CMake works and porting Nextcloud client to OpenBSD is a learning subject for me. I appreciate any help you can provide on how to solve this problem. Best. Em sex., 9 de abr. de 2021 às 15:40, Christian Weisgerber escreveu: > > net/nextcloudclient failed to build in my latest amd64 bulk build. > > ===> Faking installation for nextcloudclient-3.1.3 > [0/1] /usr/local/bin/cmake --regenerate-during-build > -S/usr/obj/ports/nextcloudclient-3.1.3/desktop-3.1.3 > -B/usr/obj/ports/nextcloudclient-3.1.3/build-amd64 > > ... and then it goes off the rails. Full log attached. > > This looks like it shares the same root cause as the audio/hydrogen > failure I just sent to ports@. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de -- Adriano Barbosa
Re: lang/mono for arm64
On 4/9/2021 11:15 AM, Patrick Wildt wrote: Hi, to do some release tests with iked we wanted to play^Wtest games/openra over IPsec. Turns out that arm64 does not support lang/mono, but I have gotten it to run. With the following diff, games/openra builds and I can even play it. This doesn't need to make release, so no worries. Would be nice for others, but I myself run -current anyway. The arch-defines.mk enables all mono-related packages. In gcconfig.h OPENBSD needs to be checked so make sure in case it's AArch64, it doesn't define NOSYS. Additionally apparently one has to check for OPENBSD and __aarch64__ to define the mach type. Then there's another AARCH64 block where OS-related stuff has to be defined. I simply used the AMD64 block, but skipping ELFCLASS. In boringssl we need to have the 'find aarch64 crypto accel' code as well. We don't have a nice API yet to extract info, so let's for now only use NEON, which we require on AArch64. As far as I can see, ucontext is sigcontext, so I provide the same defines as FreeBSD but with sigcontext context. I can try to get the diffs upstreamed. Patrick diff --git a/infrastructure/mk/arch-defines.mk b/infrastructure/mk/arch-defines.mk index 228c3991f50..965949a964b 100644 --- a/infrastructure/mk/arch-defines.mk +++ b/infrastructure/mk/arch-defines.mk @@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el powerpc64 sparc64 GCC4_ARCHS = alpha hppa sh sparc64 GCC3_ARCHS = m88k # XXX easier for ports that depend on mono -MONO_ARCHS = amd64 i386 +MONO_ARCHS = amd64 i386 aarch64 Move aarch64 to the front of the list.
Re: [NEW] x11/notion 4.0.2 (successor to x11/ion) (fixed)
Stefan Hagen wrote: > Stefan Hagen wrote: >> Stefan Hagen wrote: >>> attached is a new port for x11/notion (successor of x11/ion). >> >> I have a better version coming up, which fixes the test suite and also >> compiles on sparc64. > > Here we go. Attached is a better port. > > I've tested it on amd64 and sparc64. > > portcheck -N: ok > make-lib-depends-check: ok > make test: ok > > Patches are cleaner now and I moved the DESTDIR removal into the > Makefile. One more fix. The example configuration moved from $PREFIX/etc to $PREFIX/share/doc/notion/config. Port attached. Best Regards, Stefan notion-4_0_2.tar.gz Description: application/tar-gz
Re: [NEW] x11/notion 4.0.2 (successor to x11/ion) (fixed)
Stefan Hagen wrote: > Stefan Hagen wrote: >> attached is a new port for x11/notion (successor of x11/ion). > > I have a better version coming up, which fixes the test suite and also > compiles on sparc64. Here we go. Attached is a better port. I've tested it on amd64 and sparc64. portcheck -N: ok make-lib-depends-check: ok make test: ok Patches are cleaner now and I moved the DESTDIR removal into the Makefile. OK now? Best Regards, Stefan notion-4_0_2.tar.gz Description: application/tar-gz
Re: lang/mono for arm64
Cool, thanks, Robert. > sthen | makes sense to have that mono diff, need to be sure it doesn't break > existing working archs (looked good from a quick read but i haven't tested) The changes are all encapsulated in proper arch ifdefs. To verify that is the case I'll compile it on our two mono arches; amd64 works, and I will test i386 tomorrow morning. Patrick Am Fri, Apr 09, 2021 at 09:00:39PM +0200 schrieb Robert Nagy: > Hi > > I am okay with this and i do not see why it cannot make release. > > On 09/04/21 17:15 +0200, Patrick Wildt wrote: > > Hi, > > > > to do some release tests with iked we wanted to play^Wtest games/openra > > over IPsec. Turns out that arm64 does not support lang/mono, but I have > > gotten it to run. With the following diff, games/openra builds and I > > can even play it. > > > > This doesn't need to make release, so no worries. Would be nice for > > others, but I myself run -current anyway. > > > > The arch-defines.mk enables all mono-related packages. In gcconfig.h > > OPENBSD needs to be checked so make sure in case it's AArch64, it > > doesn't define NOSYS. Additionally apparently one has to check for > > OPENBSD and __aarch64__ to define the mach type. Then there's another > > AARCH64 block where OS-related stuff has to be defined. I simply used > > the AMD64 block, but skipping ELFCLASS. In boringssl we need to have > > the 'find aarch64 crypto accel' code as well. We don't have a nice API > > yet to extract info, so let's for now only use NEON, which we require > > on AArch64. As far as I can see, ucontext is sigcontext, so I provide > > the same defines as FreeBSD but with sigcontext context. > > > > I can try to get the diffs upstreamed. > > > > Patrick > > > > diff --git a/infrastructure/mk/arch-defines.mk > > b/infrastructure/mk/arch-defines.mk > > index 228c3991f50..965949a964b 100644 > > --- a/infrastructure/mk/arch-defines.mk > > +++ b/infrastructure/mk/arch-defines.mk > > @@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el > > powerpc64 sparc64 > > GCC4_ARCHS = alpha hppa sh sparc64 > > GCC3_ARCHS = m88k > > # XXX easier for ports that depend on mono > > -MONO_ARCHS = amd64 i386 > > +MONO_ARCHS = amd64 i386 aarch64 > > OCAML_NATIVE_ARCHS = i386 amd64 > > OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64 > > GO_ARCHS = aarch64 amd64 arm arm64 armv7 i386 > > diff --git > > a/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h > > b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h > > new file mode 100644 > > index 000..e2d766861a7 > > --- /dev/null > > +++ b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h > > @@ -0,0 +1,51 @@ > > +$OpenBSD$ > > + > > +Index: external/bdwgc/include/private/gcconfig.h > > +--- external/bdwgc/include/private/gcconfig.h.orig > > external/bdwgc/include/private/gcconfig.h > > +@@ -155,7 +155,7 @@ EXTERN_C_BEGIN > > + # if defined(__aarch64__) > > + #define AARCH64 > > + #if !defined(LINUX) && !defined(DARWIN) && !defined(FREEBSD) \ > > +-&& !defined(NN_BUILD_TARGET_PLATFORM_NX) > > ++&& !defined(OPENBSD) && !defined(NN_BUILD_TARGET_PLATFORM_NX) > > + # define NOSYS > > + # define mach_type_known > > + #endif > > +@@ -348,6 +348,10 @@ EXTERN_C_BEGIN > > + #define X86_64 > > + #define mach_type_known > > + # endif > > ++# if defined(OPENBSD) && defined(__aarch64__) > > ++# define AARCH64 > > ++# define mach_type_known > > ++# endif > > + # if defined(LINUX) && (defined(i386) || defined(__i386__)) > > + #define I386 > > + #define mach_type_known > > +@@ -2298,6 +2302,25 @@ EXTERN_C_BEGIN > > + extern char etext[]; > > + # define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext) > > + # define DATASTART_USES_BSDGETDATASTART > > ++# endif > > ++# ifdef OPENBSD > > ++# define OS_TYPE "OPENBSD" > > ++# ifndef GC_OPENBSD_THREADS > > ++EXTERN_C_END > > ++# include > > ++# include > > ++EXTERN_C_BEGIN > > ++# ifdef USRSTACK > > ++# define STACKBOTTOM ((ptr_t)USRSTACK) > > ++# else > > ++# define HEURISTIC2 > > ++# endif > > ++# endif > > ++ extern int __data_start[]; > > ++ extern int _end[]; > > ++# define DATASTART ((ptr_t)__data_start) > > ++# define DATAEND ((ptr_t)(&_end)) > > ++# define DYNAMIC_LOADING > > + # endif > > + # ifdef NINTENDO_SWITCH > > + static int zero_fd = -1; > > diff --git > > a/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c > > b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c > > new file mode 100644 > > index 000..472cc8637e0 > > --- /dev/null > > +++ b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c > > @@ -0,0 +1,31 @@ > > +$OpenBSD$ > > + > > +Index: external/boringssl/crypto/cpu-aarch64-linux.c > > +--- external/boringssl/crypto/cpu-aarch64-linux.c.orig > > +++
Re: icinga-web2 & httpd(8)
Sorry, I meant my version of the ports diff containing your httpd.conf snippet.
I did not mean to imply that I had come up with the actual config.
It has been a long day...
On 9 April 2021 19:44:34 CEST, Florian Obser wrote:
>On Fri, Apr 09, 2021 at 07:32:14PM +0200, Michael Wilson wrote:
>>
>> > Am 09.04.2021 um 18:55 schrieb Florian Obser :
>> >
>> > This is awkward, it basically takes over the (virtual) server, so
>it's
>> > not a snipped that you can just add to your existing config.
>>
>> I agree. I didn’t really had this in mind while testing the config. I
>just modified it slightly so there’s no top level root declaration:
>
>Interesting, I thought I had tried this variation and it did not work
>for me.
>
>For now I have commited my version because ports lock is upon us.
>
>I'll try to find some time next week to give this a spin, maybe we can
>sneak that in for 6.9 still.
>
>Thank you for all your work on this, much appreciated.
>
>>
>>location "/icingaweb2/*.php*" {
>>root "/icinga-web2/public/"
>>request strip 1
>>fastcgi socket "/run/php-fpm-icingaweb2.sock"
>>fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
>>}
>>
>>location found "/icingaweb2/*" {
>>root "/icinga-web2/public/"
>>request strip 1
>>}
>>
>>location not found "/icingaweb2/*" {
>>root "/icinga-web2/public/"
>>request rewrite "/icingaweb2/index.php?$QUERY_STRING"
>>}
>>
>> The trick just seems to be to first match for existing files and then
>handle the 'not found‘ ones. Seems to work so far, at least I didn’t
>notice any 404s or empty responses.
--
Sent from a mobile device. Please excuse poor formating.
Re: Vger on sparc64
On Fri, Apr 09, 2021 at 10:01:54PM +0200, Florian Viehweger wrote: > Am Fri, 09 Apr 2021 14:37:35 +0200 > schrieb Omar Polo : > > k...@openbsd.org writes: > > > http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/vger.log > > This should fix the build with gcc > Thank you for looking at this. > This compiles for me on amd64 and I've done (light) testing. > Can anybody with working sparc64 hardware please test this? > Attached is a modified diff with added REVISION. > Thank you! Adding -std=c99 (or -std=gnu99) does fix it on sparc64. I was doing a test of something (adding -std=gnu99 by default for base-gcc) and vger compiled fine there. --Kurt
Re: Vger on sparc64
Florian Viehweger writes:
> Am Fri, 09 Apr 2021 14:37:35 +0200
> schrieb Omar Polo :
>
>>
>> k...@openbsd.org writes:
>>
>> > http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/vger.log
>>
>> This should fix the build with gcc
>
> Thank you for looking at this.
>
> This compiles for me on amd64 and I've done (light) testing.
>
> Can anybody with working sparc64 hardware please test this?
I don't have a spark, but you can replicate with `CC=gcc make'. On
amd64 the default c compiler is clang, but it's not the case for every
arch. Moreover, the gcc version in base is quite old and doesn't
support C99 OOTB (hence the need for the -std=gcc99 flag) - I may
remember wrong tho.
I added the CFLAGS without wrapping it with some .if because a quick
grep showed other ports doing the same (I remember graphics/feh in
particular), don't know if there are better ways.
Cheers :)
> Attached is a modified diff with added REVISION.
>
> Thank you!
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/vger/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 Makefile
> --- Makefile 4 Apr 2021 08:57:15 - 1.1.1.1
> +++ Makefile 9 Apr 2021 19:46:07 -
> @@ -5,6 +5,7 @@ V = 1.06
> DISTNAME = vger-${V}
>
> CATEGORIES = net
> +REVISION = 0
>
> HOMEPAGE = https://tildegit.org/solene/vger/
>
> @@ -20,5 +21,7 @@ WANTLIB += c
> MASTER_SITES = https://tildegit.org/solene/vger/archive/
> DISTFILES = vger-{}${V}${EXTRACT_SUFX}
> WRKSRC = ${WRKDIR}/vger
> +
> +CFLAGS +=-std=gnu99
>
> .include
Vger on sparc64
Am Fri, 09 Apr 2021 14:37:35 +0200
schrieb Omar Polo :
>
> k...@openbsd.org writes:
>
> > http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/vger.log
>
> This should fix the build with gcc
Thank you for looking at this.
This compiles for me on amd64 and I've done (light) testing.
Can anybody with working sparc64 hardware please test this?
Attached is a modified diff with added REVISION.
Thank you!
Index: Makefile
===
RCS file: /cvs/ports/net/vger/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile4 Apr 2021 08:57:15 - 1.1.1.1
+++ Makefile9 Apr 2021 19:46:07 -
@@ -5,6 +5,7 @@ V = 1.06
DISTNAME = vger-${V}
CATEGORIES = net
+REVISION = 0
HOMEPAGE = https://tildegit.org/solene/vger/
@@ -20,5 +21,7 @@ WANTLIB +=c
MASTER_SITES = https://tildegit.org/solene/vger/archive/
DISTFILES =vger-{}${V}${EXTRACT_SUFX}
WRKSRC = ${WRKDIR}/vger
+
+CFLAGS += -std=gnu99
.include
--
greetings,
Florian Viehweger
net/nextcloudclient build failure
net/nextcloudclient failed to build in my latest amd64 bulk build. ===> Faking installation for nextcloudclient-3.1.3 [0/1] /usr/local/bin/cmake --regenerate-during-build -S/usr/obj/ports/nextcloudclient-3.1.3/desktop-3.1.3 -B/usr/obj/ports/nextcloudclient-3.1.3/build-amd64 ... and then it goes off the rails. Full log attached. This looks like it shares the same root cause as the audio/hydrogen failure I just sent to ports@. -- Christian "naddy" Weisgerber na...@mips.inka.de nextcloudclient.log.xz Description: application/xz
audio/hydrogen build failure
audio/hydrogen failed to build in my latest amd64 bulk build. ===> Faking installation for hydrogen-1.0.1 [0/1] /usr/local/bin/cmake --regenerate-during-build -S/usr/obj/ports/hydrogen-1.0.1/hydrogen-1.0.1 -B/usr/obj/ports/hydrogen-1.0.1/build-amd64 ... and then it goes off the rails. Full log attached. -- Christian "naddy" Weisgerber na...@mips.inka.de hydrogen.log.xz Description: application/xz
Re: lang/mono for arm64
Hi
I am okay with this and i do not see why it cannot make release.
On 09/04/21 17:15 +0200, Patrick Wildt wrote:
> Hi,
>
> to do some release tests with iked we wanted to play^Wtest games/openra
> over IPsec. Turns out that arm64 does not support lang/mono, but I have
> gotten it to run. With the following diff, games/openra builds and I
> can even play it.
>
> This doesn't need to make release, so no worries. Would be nice for
> others, but I myself run -current anyway.
>
> The arch-defines.mk enables all mono-related packages. In gcconfig.h
> OPENBSD needs to be checked so make sure in case it's AArch64, it
> doesn't define NOSYS. Additionally apparently one has to check for
> OPENBSD and __aarch64__ to define the mach type. Then there's another
> AARCH64 block where OS-related stuff has to be defined. I simply used
> the AMD64 block, but skipping ELFCLASS. In boringssl we need to have
> the 'find aarch64 crypto accel' code as well. We don't have a nice API
> yet to extract info, so let's for now only use NEON, which we require
> on AArch64. As far as I can see, ucontext is sigcontext, so I provide
> the same defines as FreeBSD but with sigcontext context.
>
> I can try to get the diffs upstreamed.
>
> Patrick
>
> diff --git a/infrastructure/mk/arch-defines.mk
> b/infrastructure/mk/arch-defines.mk
> index 228c3991f50..965949a964b 100644
> --- a/infrastructure/mk/arch-defines.mk
> +++ b/infrastructure/mk/arch-defines.mk
> @@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el powerpc64
> sparc64
> GCC4_ARCHS = alpha hppa sh sparc64
> GCC3_ARCHS = m88k
> # XXX easier for ports that depend on mono
> -MONO_ARCHS = amd64 i386
> +MONO_ARCHS = amd64 i386 aarch64
> OCAML_NATIVE_ARCHS = i386 amd64
> OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64
> GO_ARCHS = aarch64 amd64 arm arm64 armv7 i386
> diff --git
> a/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> new file mode 100644
> index 000..e2d766861a7
> --- /dev/null
> +++ b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> @@ -0,0 +1,51 @@
> +$OpenBSD$
> +
> +Index: external/bdwgc/include/private/gcconfig.h
> +--- external/bdwgc/include/private/gcconfig.h.orig
> external/bdwgc/include/private/gcconfig.h
> +@@ -155,7 +155,7 @@ EXTERN_C_BEGIN
> + # if defined(__aarch64__)
> + #define AARCH64
> + #if !defined(LINUX) && !defined(DARWIN) && !defined(FREEBSD) \
> +-&& !defined(NN_BUILD_TARGET_PLATFORM_NX)
> ++&& !defined(OPENBSD) && !defined(NN_BUILD_TARGET_PLATFORM_NX)
> + # define NOSYS
> + # define mach_type_known
> + #endif
> +@@ -348,6 +348,10 @@ EXTERN_C_BEGIN
> + #define X86_64
> + #define mach_type_known
> + # endif
> ++# if defined(OPENBSD) && defined(__aarch64__)
> ++# define AARCH64
> ++# define mach_type_known
> ++# endif
> + # if defined(LINUX) && (defined(i386) || defined(__i386__))
> + #define I386
> + #define mach_type_known
> +@@ -2298,6 +2302,25 @@ EXTERN_C_BEGIN
> + extern char etext[];
> + # define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
> + # define DATASTART_USES_BSDGETDATASTART
> ++# endif
> ++# ifdef OPENBSD
> ++# define OS_TYPE "OPENBSD"
> ++# ifndef GC_OPENBSD_THREADS
> ++EXTERN_C_END
> ++# include
> ++# include
> ++EXTERN_C_BEGIN
> ++# ifdef USRSTACK
> ++# define STACKBOTTOM ((ptr_t)USRSTACK)
> ++# else
> ++# define HEURISTIC2
> ++# endif
> ++# endif
> ++ extern int __data_start[];
> ++ extern int _end[];
> ++# define DATASTART ((ptr_t)__data_start)
> ++# define DATAEND ((ptr_t)(&_end))
> ++# define DYNAMIC_LOADING
> + # endif
> + # ifdef NINTENDO_SWITCH
> + static int zero_fd = -1;
> diff --git
> a/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
> b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
> new file mode 100644
> index 000..472cc8637e0
> --- /dev/null
> +++ b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
> @@ -0,0 +1,31 @@
> +$OpenBSD$
> +
> +Index: external/boringssl/crypto/cpu-aarch64-linux.c
> +--- external/boringssl/crypto/cpu-aarch64-linux.c.orig
> external/boringssl/crypto/cpu-aarch64-linux.c
> +@@ -16,7 +16,9 @@
> +
> + #if defined(OPENSSL_AARCH64) && !defined(OPENSSL_STATIC_ARMCAP)
> +
> ++#if !defined(__OpenBSD__)
> + #include
> ++#endif
> +
> + #include
> +
> +@@ -63,6 +65,15 @@ void OPENSSL_cpuid_setup(void) {
> + if (ID_AA64ISAR0_SHA2_VAL(isar0_val) >= ID_AA64ISAR0_SHA2_BASE) {
> + OPENSSL_armcap_P |= ARMV8_SHA256;
> + }
> ++}
> ++
> ++#elif defined(__OpenBSD__)
> ++
> ++#include
> ++#include
> ++
> ++void OPENSSL_cpuid_setup(void) {
> ++ OPENSSL_armcap_P |= ARMV7_NEON;
> + }
> +
> + #else // linux
> diff --git a/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
> b/lang
Re: icinga-web2 & httpd(8)
On Fri, Apr 09, 2021 at 07:32:14PM +0200, Michael Wilson wrote:
>
> > Am 09.04.2021 um 18:55 schrieb Florian Obser :
> >
> > This is awkward, it basically takes over the (virtual) server, so it's
> > not a snipped that you can just add to your existing config.
>
> I agree. I didn’t really had this in mind while testing the config. I just
> modified it slightly so there’s no top level root declaration:
Interesting, I thought I had tried this variation and it did not work
for me.
For now I have commited my version because ports lock is upon us.
I'll try to find some time next week to give this a spin, maybe we can
sneak that in for 6.9 still.
Thank you for all your work on this, much appreciated.
>
>location "/icingaweb2/*.php*" {
>root "/icinga-web2/public/"
>request strip 1
>fastcgi socket "/run/php-fpm-icingaweb2.sock"
>fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
>}
>
>location found "/icingaweb2/*" {
>root "/icinga-web2/public/"
>request strip 1
>}
>
>location not found "/icingaweb2/*" {
>root "/icinga-web2/public/"
>request rewrite "/icingaweb2/index.php?$QUERY_STRING"
>}
>
> The trick just seems to be to first match for existing files and then handle
> the 'not found‘ ones. Seems to work so far, at least I didn’t notice any 404s
> or empty responses.
--
I'm not entirely sure you are real.
Re: icinga-web2 & httpd(8)
> Am 09.04.2021 um 18:55 schrieb Florian Obser :
>
> This is awkward, it basically takes over the (virtual) server, so it's
> not a snipped that you can just add to your existing config.
I agree. I didn’t really had this in mind while testing the config. I just
modified it slightly so there’s no top level root declaration:
location "/icingaweb2/*.php*" {
root "/icinga-web2/public/"
request strip 1
fastcgi socket "/run/php-fpm-icingaweb2.sock"
fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
}
location found "/icingaweb2/*" {
root "/icinga-web2/public/"
request strip 1
}
location not found "/icingaweb2/*" {
root "/icinga-web2/public/"
request rewrite "/icingaweb2/index.php?$QUERY_STRING"
}
The trick just seems to be to first match for existing files and then handle
the 'not found‘ ones. Seems to work so far, at least I didn’t notice any 404s
or empty responses.
Re: icinga-web2 & httpd(8)
Sorry for slacking off on this, I'm swamped with a lot of things...
On Sun, Apr 04, 2021 at 11:33:22PM +0200, Michael Wilson wrote:
> I just tried to configure httpd with /icingaweb2 as path. This config seems
> to be working so far:
>
> root "/icinga-web2/public/"
This is awkward, it basically takes over the (virtual) server, so it's
not a snipped that you can just add to your existing config.
I think it's best to bite the bulled and say that you need a new
virtual server for this. With let's encrypt and sni that's not too
terrible I guess.
I think it's worthwhile to have this for 6.9 since we no longer ship
icinga 1, so people might want to switch to icinga 2.
OK?
diff --git Makefile Makefile
index d1ed050fb51..414fa1a1f11 100644
--- Makefile
+++ Makefile
@@ -5,7 +5,7 @@ COMMENT = next-generation web UI for icinga
GH_ACCOUNT = Icinga
GH_PROJECT = icingaweb2
GH_TAGNAME = v2.8.2
-REVISION = 7
+REVISION = 8
PKGNAME = icinga-web2-${GH_TAGNAME:S/v//}
MAINTAINER = Stuart Henderson
diff --git pkg/README pkg/README
index d6d99758ec0..995c7826f0a 100644
--- pkg/README
+++ pkg/README
@@ -73,6 +73,28 @@ Or if you use for php-fpm, use this:
And reload:
# rcctl reload apache2
+An example for base httpd(8), serving directly from the root using the
+above php-fpm section:
+
+ server "icinga.example.com" {
+ listen on * tls port 443
+ tls {
+ certificate "/etc/ssl/icinga.example.com.crt"
+ key "/etc/ssl/private/icinga.example.com.key"
+ }
+
+ root "/icinga-web2/public"
+ directory index "index.php"
+ location "*.php*" {
+ fastcgi socket "/run/php-fpm-icingaweb2.sock"
+ fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
+ }
+
+ location not found "*" {
+ request rewrite "/index.php?$QUERY_STRING"
+ }
+ }
+
- Using icingacli, create the config directory and a token to allow setup:
# ${PREFIX}/icinga-web2/bin/icingacli setup config directory --group
_icingaweb2
>
> location "/icingaweb2/*.php*" {
> request strip 1
> fastcgi socket "/run/php-fpm-icingaweb2.sock"
> fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
> }
>
> location found "/icingaweb2/*" {
> root "/icinga-web2/public/"
> request strip 1
> }
>
> location not found "/icingaweb2/*" {
> request rewrite "/icingaweb2/index.php?$QUERY_STRING"
> }
>
--
I'm not entirely sure you are real.
lang/mono for arm64
Hi,
to do some release tests with iked we wanted to play^Wtest games/openra
over IPsec. Turns out that arm64 does not support lang/mono, but I have
gotten it to run. With the following diff, games/openra builds and I
can even play it.
This doesn't need to make release, so no worries. Would be nice for
others, but I myself run -current anyway.
The arch-defines.mk enables all mono-related packages. In gcconfig.h
OPENBSD needs to be checked so make sure in case it's AArch64, it
doesn't define NOSYS. Additionally apparently one has to check for
OPENBSD and __aarch64__ to define the mach type. Then there's another
AARCH64 block where OS-related stuff has to be defined. I simply used
the AMD64 block, but skipping ELFCLASS. In boringssl we need to have
the 'find aarch64 crypto accel' code as well. We don't have a nice API
yet to extract info, so let's for now only use NEON, which we require
on AArch64. As far as I can see, ucontext is sigcontext, so I provide
the same defines as FreeBSD but with sigcontext context.
I can try to get the diffs upstreamed.
Patrick
diff --git a/infrastructure/mk/arch-defines.mk
b/infrastructure/mk/arch-defines.mk
index 228c3991f50..965949a964b 100644
--- a/infrastructure/mk/arch-defines.mk
+++ b/infrastructure/mk/arch-defines.mk
@@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el powerpc64
sparc64
GCC4_ARCHS = alpha hppa sh sparc64
GCC3_ARCHS = m88k
# XXX easier for ports that depend on mono
-MONO_ARCHS = amd64 i386
+MONO_ARCHS = amd64 i386 aarch64
OCAML_NATIVE_ARCHS = i386 amd64
OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64
GO_ARCHS = aarch64 amd64 arm arm64 armv7 i386
diff --git a/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
new file mode 100644
index 000..e2d766861a7
--- /dev/null
+++ b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
@@ -0,0 +1,51 @@
+$OpenBSD$
+
+Index: external/bdwgc/include/private/gcconfig.h
+--- external/bdwgc/include/private/gcconfig.h.orig
external/bdwgc/include/private/gcconfig.h
+@@ -155,7 +155,7 @@ EXTERN_C_BEGIN
+ # if defined(__aarch64__)
+ #define AARCH64
+ #if !defined(LINUX) && !defined(DARWIN) && !defined(FREEBSD) \
+-&& !defined(NN_BUILD_TARGET_PLATFORM_NX)
++&& !defined(OPENBSD) && !defined(NN_BUILD_TARGET_PLATFORM_NX)
+ # define NOSYS
+ # define mach_type_known
+ #endif
+@@ -348,6 +348,10 @@ EXTERN_C_BEGIN
+ #define X86_64
+ #define mach_type_known
+ # endif
++# if defined(OPENBSD) && defined(__aarch64__)
++# define AARCH64
++# define mach_type_known
++# endif
+ # if defined(LINUX) && (defined(i386) || defined(__i386__))
+ #define I386
+ #define mach_type_known
+@@ -2298,6 +2302,25 @@ EXTERN_C_BEGIN
+ extern char etext[];
+ # define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
+ # define DATASTART_USES_BSDGETDATASTART
++# endif
++# ifdef OPENBSD
++# define OS_TYPE "OPENBSD"
++# ifndef GC_OPENBSD_THREADS
++EXTERN_C_END
++# include
++# include
++EXTERN_C_BEGIN
++# ifdef USRSTACK
++# define STACKBOTTOM ((ptr_t)USRSTACK)
++# else
++# define HEURISTIC2
++# endif
++# endif
++ extern int __data_start[];
++ extern int _end[];
++# define DATASTART ((ptr_t)__data_start)
++# define DATAEND ((ptr_t)(&_end))
++# define DYNAMIC_LOADING
+ # endif
+ # ifdef NINTENDO_SWITCH
+ static int zero_fd = -1;
diff --git
a/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
new file mode 100644
index 000..472cc8637e0
--- /dev/null
+++ b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
@@ -0,0 +1,31 @@
+$OpenBSD$
+
+Index: external/boringssl/crypto/cpu-aarch64-linux.c
+--- external/boringssl/crypto/cpu-aarch64-linux.c.orig
external/boringssl/crypto/cpu-aarch64-linux.c
+@@ -16,7 +16,9 @@
+
+ #if defined(OPENSSL_AARCH64) && !defined(OPENSSL_STATIC_ARMCAP)
+
++#if !defined(__OpenBSD__)
+ #include
++#endif
+
+ #include
+
+@@ -63,6 +65,15 @@ void OPENSSL_cpuid_setup(void) {
+ if (ID_AA64ISAR0_SHA2_VAL(isar0_val) >= ID_AA64ISAR0_SHA2_BASE) {
+ OPENSSL_armcap_P |= ARMV8_SHA256;
+ }
++}
++
++#elif defined(__OpenBSD__)
++
++#include
++#include
++
++void OPENSSL_cpuid_setup(void) {
++ OPENSSL_armcap_P |= ARMV7_NEON;
+ }
+
+ #else // linux
diff --git a/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
b/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
new file mode 100644
index 000..0d036cac533
--- /dev/null
+++ b/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Index: mono/utils/mono-sigcontext.h
+--- mono/utils/mono-sigcontext.h.orig
mono/utils/mono-sigcontext.h
+@@ -472,6 +472,12 @@ typedef struct ucontext {
+ #define UCONTEXT_REG_SP(ctx
Re: [doc] using qemu guest agent on OpenBSD kvm/qemu guests
On Thu, Apr 08, 2021 at 06:19:58PM +0200, Jeroen Derks wrote: > On 08/04/2021 14:35, Landry Breuil wrote:> > > well that's very nice, definitely interested in those freebsd patches ! > > not 100% sure those will get in 6.9 though as we're slowly moving towards > > lock, but send them anyway, and we'll figure out what we can do from > > there. I suppose those come from > > https://github.com/aborche/qemu-guest-agent ? > > Indeed, here they are (if there's interest I can also send a diff of the > patches > compared to the FreeBSD patches to see what I've done): oh, well that looks nice. A bit rought around the edges imo, and im not sure we want to maintain a rather large patch like this in the portstree. according to https://wiki.qemu.org/Contribute/SubmitAPatch i think it should be pushed upstream, do you have any idea if the original freebsd patches were proposed there or qemu-devel list ? i'll let brad decide, but as is this doesnt apply as-is against 6.0 rcs which we're testing for post-6.9 Landry
NSH updating command options to reflect changes in base
Hello all,
what is the policy for command line argument modifications, for NSH
with florian@ change to base
the interface config command
autoconfprivacy
should probably change to
autoconfv6temp
or should old "autoconfprivacy" be still supported for existing configs
and autoconfv6temp encouraged by making it only available when an
engineer enters ? in the interface config menu ?
any advice / directions welcome
Thanks
Tom Smyth
On Thu, 1 Apr 2021 at 01:41, Tom Smyth wrote:
>
> Hello
> below is a diff for commands.c
> to clear some of the compiler warnings,
>
> --- commands.c Tue Oct 6 01:59:33 2020
> +++ /home/tom/commands.c Thu Apr 1 01:00:16 2021
> @@ -451,7 +451,7 @@ flushcmd(int argc, char **argv)
> static int
> flush_line(char *line)
> {
> - char *argv[] = { PKILL, "-9", "-t", line, '\0' };
> + char *argv[] = { PKILL, "-9", "-t", line, NULL };
> cmdargs(PKILL, argv);
> return (1);
> }
> @@ -1673,7 +1673,7 @@ flush_pf(char *arg)
> }
>
> {
> - char *argv[] = { x->cmd, x->arg, '\0' };
> + char *argv[] = { x->cmd, x->arg, NULL };
> cmdargs(x->cmd, argv);
> }
>
> @@ -1720,7 +1720,7 @@ cmdrc(char rcname[FILENAME_MAX])
> if (line[0] == ' ' && line[1] == '!' && savec && savec->modh == 2)
> continue;
> if (line[0] == ' ')
> - strlcpy(saveline, line, sizeof(line));
> + strlcpy(saveline, line, sizeof(saveline));
> makeargv();
> if (margv[0] == 0)
> continue;
> @@ -1876,7 +1876,7 @@ iprompt(void)
> int
> wr_startup(void)
> {
> - char *argv[] = { SAVESCRIPT, NSHRC_TEMP, '\0' };
> + char *argv[] = { SAVESCRIPT, NSHRC_TEMP, NULL };
>
> if (wr_conf(NSHRC_TEMP))
> printf("%% Saving configuration\n");
> @@ -2072,7 +2072,7 @@ pr_kernel(int argc, char **argv)
> void
> pf_stats(void)
> {
> - char *argv[] = { PFCTL, "-sinfo", '\0' };
> + char *argv[] = { PFCTL, "-sinfo", NULL };
>
> printf("%% pf statistics:\n");
>
> @@ -2085,7 +2085,7 @@ pr_prot1(int argc, char **argv)
> {
> struct prot1 *x;
> struct prot *prot;
> - char *args[NOPTFILL] = { NULL, NULL, NULL, NULL, NULL, NULL, '\0' };
> + char *args[NOPTFILL] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL };
> char **fillargs;
> char prefix[64];
>
> @@ -2150,7 +2150,7 @@ step_optreq(char **xargs, char **args, int argc, char
> /* copy xargs to args, replace OPT/REQ args with argv past skip */
> for (i = 0; i < NOPTFILL - 2; i++) {
> if (xargs[i] == NULL) {
> - args[i] = '\0';
> + args[i] = NULL;
> if (i > 1)
> /*
> * all **args passed must have at least two arguments
> @@ -2169,7 +2169,7 @@ step_optreq(char **xargs, char **args, int argc, char
> printf("%% Missing required argument\n");
> return NULL;
> } else {
> - args[i] = '\0';
> + args[i] = NULL;
> break;
> }
> } else {
--
Kindest regards,
Tom Smyth.
Re: [UPDATE] lang/erlang
On 2021/04/09 07:19, niamkik wrote: > Hi, > > > > Since I pruned the old erlang versions in ports, I've got to ask. Would > > we get sufficient benefits from keeping more than one erlang version? Do > > we have important erlang software people rely on that we can't build > > with a single chosen version? > > > > We routinely make decisions choosing single library versions. It makes > > sense to lean this way for the compilers... Libraries are often difficult to handle with multiple versions, they often conflict and cause problems if several are installed together. Though in some cases it's fine, e.g. we often have multiple versions of gtk+, gegl, gstreamer in parallel, but it does require some thought. For interpreters there's often good reason to have multiple versions (see php, python, lua, ruby) and *if* there's a good reason and somebody is willing to maintain then I wouldn't object to that. (That latter point is key though, if it's not going to be actively maintained then it really wants keeping simple). > On my side, maintaining 4 versions will not be easy but I can understand to > have backward compatibility with older version, it could be nice. Anyway, > maintaining only one release could be easier, like R22 or R23. It will > probably lead to break dependencies though. Most of the dependencies are either already broken (riak, rabbitmq), or can handle at least up to 23 (rebar3, elixir). The others are rebar (no longer maintained and only used in ports as a dependency of riak) and tsung (no indication whether it will work or not and doesn't exactly seem active upstream). (riak is a bit special anyway, seems they really want it to be built with a patched Erlang..)
Re: sparc64 bulk build report
k...@openbsd.org writes:
> http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/vger.log
This should fix the build with gcc
Index: Makefile
===
RCS file: /home/cvs/ports/net/vger/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile4 Apr 2021 08:57:15 - 1.1.1.1
+++ Makefile9 Apr 2021 12:34:49 -
@@ -21,4 +21,6 @@ MASTER_SITES =https://tildegit.org/sol
DISTFILES =vger-{}${V}${EXTRACT_SUFX}
WRKSRC = ${WRKDIR}/vger
+CFLAGS += -std=gnu99
+
.include
Re: [UPDATE] lang/erlang
Hi, > Since I pruned the old erlang versions in ports, I've got to ask. Would > we get sufficient benefits from keeping more than one erlang version? Do > we have important erlang software people rely on that we can't build > with a single chosen version? > > We routinely make decisions choosing single library versions. It makes > sense to lean this way for the compilers... On my side, maintaining 4 versions will not be easy but I can understand to have backward compatibility with older version, it could be nice. Anyway, maintaining only one release could be easier, like R22 or R23. It will probably lead to break dependencies though.
sparc64 bulk build report
Bulk build on sparc64-0a.ports.openbsd.org Started : Tue Apr 6 10:25:11 MDT 2021 Finished: Fri Apr 9 04:43:39 MDT 2021 Duration: 2 Days 18 hours 18 minutes Built using OpenBSD 6.9 (GENERIC.MP) #777: Mon Apr 5 22:49:20 MDT 2021 Built 9717 packages Number of packages built each day: Apr 6: 7250 Apr 7: 1659 Apr 8: 806 Apr 9: 2 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2021-04-06/summary.log Build failures: 34 http://build-failures.rhaalovely.net/sparc64/2021-04-06/audio/ncmpcpp.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/cad/dxf2gcode.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/comms/syncterm.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/devel/keystone/python,python3.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/emulators/emulationstation.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/emulators/libretro-genesis-plus-gx.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/games/egoboo.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/games/frotz.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/games/odamex.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/games/openxcom.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/games/stepmania.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/geo/spatialite/gui.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/graphics/asymptote.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/graphics/makehuman.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/graphics/mypaint.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/math/gnumeric.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/math/mlpack,-main.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/math/veusz.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/multimedia/mkvtoolnix,no_x11.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/barrier.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/pmacct,postgresql.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/sniproxy.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/net/vger.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/print/cups-bjnp.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/print/gutenprint.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/productivity/gnucash.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/security/opendnssec.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/sysutils/libvirt.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/www/py-genshi,python3.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/x11/gnome/mutter.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/x11/kde-applications/kmix.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/x11/qt5/docs,-html.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/x11/roxterm.log http://build-failures.rhaalovely.net/sparc64/2021-04-06/x11/xmenu.log Recurrent failures: failures/audio/ncmpcpp.log failures/cad/dxf2gcode.log failures/comms/syncterm.log failures/devel/keystone/python,python3.log failures/emulators/emulationstation.log failures/net/barrier.log failures/net/pmacct,postgresql.log failures/net/sniproxy.log failures/print/cups-bjnp.log failures/print/gutenprint.log failures/productivity/gnucash.log failures/sysutils/libvirt.log failures/www/py-genshi,python3.log failures/x11/kde-applications/kmix.log failures/x11/roxterm.log failures/x11/xmenu.log New failures: +failures/net/vger.log +failures/x11/gnome/mutter.log +failures/x11/qt5/docs,-html.log Resolved failures: -failures/comms/sigrok/libsigrok.log -failures/x11/gnome/sushi.log -failures/x11/gtk+4.log Packages newly built: +comms/sigrok/libsigrok +comms/sigrok/pulseview +comms/sigrok/sigrok-cli +databases/timescaledb +inputmethods/ibus +inputmethods/ibus,-gtk2 +inputmethods/ibus,-gtk4 +inputmethods/ibus,-main +inputmethods/ibus-anthy +inputmethods/ibus-skk +x11/gnome/control-center +x11/gnome/initial-setup +x11/gnome/settings-daemon +x11/gnome/sushi +x11/gtk+4 +x11/gtk+4,-cloudprint +x11/gtk+4,-cups +x11/gtk+4,-demos +x11/gtk+4,-guic +x11/gtk+4,-main +x11/gtk+4,-media +x11/gtkmm40 +x11/gtksourceview5 Packages not built this time: -x11/qt5/docs -x11/qt5/docs,-html -x11/qt5/docs,-qch
Re: gimp language bug
Christian Weisgerber:
> Marc Espie:
>
> > g_setenv ("LANGUAGE", language, TRUE);
> > setlocale (LC_ALL, "");
>
> From the gettext manual:
> Note: The variable LANGUAGE is ignored if the locale is set to 'C'. In
> other words, you have to first enable localization, by setting LANG (or
> LC_ALL) to a value other than 'C', before you can use a language
> priority list through the LANGUAGE variable.
And that is exactly what I observe with gimp after setting the
language to French in the Preferences dialog.
If I set any of the locale-related environment variables LC_ALL,
LC_MESSAGES, or LANG to _any_ value, gimp will start up in French.
Otherwise it will come up in English.
The "bug" here is that gimp's authors assume that the program will
run with locale settings in the environment. I think typical Linux
distributions have had such a default for a long time.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: speedtest-cli - ValueError: invalid literal for int() with base 10
On Fri, Apr 09, 2021 at 08:57:42AM +0200, Theo Buehler wrote:
>
> On Fri, Apr 09, 2021 at 06:45:40AM +, Mikolaj Kucharski wrote:
> > Hi,
> >
> > This should go upsteam, but I just noticed this on multiple -current
> > machines. I see that v2.1.3 was released yesterday and at first glance
> > last commit in repo looks like could fix below issue. Sorry, didn't dive
> > deeper and I'm not sure will I be able until next weekend :/
>
> Indeed, this seems to work for me:
Works for me, thanks.
ok kevlo@
> Index: Makefile
> ===
> RCS file: /cvs/ports/benchmarks/speedtest-cli/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- Makefile 23 Feb 2021 19:39:10 - 1.23
> +++ Makefile 9 Apr 2021 06:54:59 -
> @@ -2,10 +2,9 @@
>
> COMMENT =command-line client for speedtest.net bandwidth tester
>
> -MODPY_EGG_VERSION = 2.1.2
> +MODPY_EGG_VERSION = 2.1.3
> DISTNAME = speedtest-cli-${MODPY_EGG_VERSION}
> CATEGORIES = benchmarks net
> -REVISION = 0
>
> HOMEPAGE = https://github.com/sivel/speedtest-cli
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/benchmarks/speedtest-cli/distinfo,v
> retrieving revision 1.16
> diff -u -p -r1.16 distinfo
> --- distinfo 23 Aug 2019 15:49:58 - 1.16
> +++ distinfo 9 Apr 2021 06:55:05 -
> @@ -1,2 +1,2 @@
> -SHA256 (speedtest-cli-2.1.2.tar.gz) =
> zx04YiL5TDJOMSW6mg0YfkbUoT3KCMAjvbmiMJa+LlQ=
> -SIZE (speedtest-cli-2.1.2.tar.gz) = 24365
> +SHA256 (speedtest-cli-2.1.3.tar.gz) =
> XidzIzzttfo9gSDrf5e8xJdLUiGyVNM/8W4vHUE9kPA=
> +SIZE (speedtest-cli-2.1.3.tar.gz) = 24721
>
