Re: audio/pulseaudio: Fix zsh completion

[Antoine Jacoutot]

On Fri, Jan 07, 2022 at 11:25:56PM -0600, Matthew Martin wrote:
> Third party zsh completers should be installed to zsh/site-functions[1].
> Since that's what pulseaudio does by default, just remove the flag.
> 
> 1: https://github.com/zsh-users/zsh/blob/master/INSTALL#L257

Hi Matthew.

Thanks, committed.


> diff --git Makefile Makefile
> index a1863c1ee46..2eb0f4eccc5 100644
> --- Makefile
> +++ Makefile
> @@ -5,6 +5,7 @@ COMMENT=  cross-platform networked sound server
>  VERSION= 15.0
>  DISTNAME=pulseaudio-${VERSION}
>  EXTRACT_SUFX=.tar.xz
> +REVISION=0
>  
>  SHARED_LIBS += pulse 7.2 # 0.24.0
>  SHARED_LIBS += pulse-simple  1.2 # 0.1.1
> @@ -67,7 +68,6 @@ CONFIGURE_ARGS= -Ddoxygen=false \
>   -Ddatabase=tdb \
>   -Datomic-arm-linux-helpers=false \
>   
> -Dbashcompletiondir=${PREFIX}/share/bash-completion/completions \
> - 
> -Dzshcompletiondir=${PREFIX}/share/zsh/vendor-completions \
>   -Dalsa=disabled \
>   -Dasyncns=disabled \
>   -Davahi=disabled \
> diff --git pkg/PLIST pkg/PLIST
> index c5b8d9e969c..146c104d87b 100644
> --- pkg/PLIST
> +++ pkg/PLIST
> @@ -238,5 +238,5 @@ share/vala/vapi/libpulse-simple.vapi
>  share/vala/vapi/libpulse.deps
>  share/vala/vapi/libpulse.vapi
>  share/zsh/
> -share/zsh/vendor-completions/
> -share/zsh/vendor-completions/_pulseaudio
> +share/zsh/site-functions/
> +share/zsh/site-functions/_pulseaudio
> 

-- 
Antoine

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/08 00:29:52

Modified files:
audio/pulseaudio: Makefile 
audio/pulseaudio/pkg: PLIST 

Log message:
Fix path to zsh completion.

from Matthew Martin

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2022/01/08 00:18:45

Modified files:
sysutils/openbsdisks2: Makefile distinfo 

Log message:
Update openbsdisks2 to 0.3.1

Re: [maintainer update] ecl-21.2.1

[Timo Myyrä]

Timo Myyrä  [2021-12-21, 13:08 +0200]:

ping ping...

> Ping
>
> On Sat, Dec 11, 2021, at 18:34, Timo Myyrä wrote:
>> Hi,
>>
>> Here's an bump to bring ecl to latest version.
>> Lightly tested on amd64.
>>
>> Timo
>>
>> diff 31bccecebaefd3b23c4e4dac76105b5dd0ae1159 /usr/ports
>> blob - 49c2de291af99891af2eab90692315ae9b00654f
>> file + lang/ecl/Makefile
>> --- lang/ecl/Makefile
>> +++ lang/ecl/Makefile
>> @@ -3,9 +3,9 @@
>>  COMMENT =   embeddable common-lisp
>>  CATEGORIES =lang
>> 
>> -V = 20.4.24
>> +V = 21.2.1
>>  DISTNAME =  ecl-$V
>> -SHARED_LIBS +=  ecl 7.0
>> +SHARED_LIBS +=  ecl 8.0
>> 
>>  HOMEPAGE =  https://common-lisp.net/project/ecl/
>>  MAINTAINER =Timo Myyra 
>> @@ -46,9 +46,7 @@ LIB_DEPENDS += devel/gmp \
>>  devel/libffi
>> 
>>  TEST_DEPENDS =  ${BASE_PKGPATH}
>> +TEST_ENV =  "ECL=${WRKDIST}/build/bin/ecl" \
>> +"TEST_IMAGE=${WRKDIST}/build/bin/ecl"
>> 
>> -# XXX: Workaround for missing Copyright file
>> -post-configure:
>> -@cp ${WRKSRC}/{LICENSE,Copyright}
>> -
>>  .include 
>> blob - 5c3377469374e1eefeb7900f2d30b5660b4c9528
>> file + lang/ecl/distinfo
>> --- lang/ecl/distinfo
>> +++ lang/ecl/distinfo
>> @@ -1,2 +1,2 @@
>> -SHA256 (ecl-20.4.24.tgz) = Zwg47fJYqTa1Iv22INozbefldaoNJ+NIQXJyUnJtDwc=
>> -SIZE (ecl-20.4.24.tgz) = 7815444
>> +SHA256 (ecl-21.2.1.tgz) = sVp13PhLj2LmhyDMqxOT+WEcB4/NOv3WOaEIbK0BCQA=
>> +SIZE (ecl-21.2.1.tgz) = 7875088
>> blob - b44246b9b8d755df5784e6b4dd04570657feb031
>> file + lang/ecl/patches/patch-src_Makefile_in
>> --- lang/ecl/patches/patch-src_Makefile_in
>> +++ lang/ecl/patches/patch-src_Makefile_in
>> @@ -6,7 +6,6 @@ Index: src/Makefile.in
>>  for i in `(cd ecl && find . -name '*.h')`; do echo $$i; \
>>$(INSTALL_DATA) ecl/$$i $(DESTDIR)$(includedir)/ecl/$$i; \
>>  done
>> -+   $(INSTALL_DATA) help.doc $(DESTDIR)$(ecldir)
>>  $(INSTALL_SCRIPT) bin/ecl-config $(DESTDIR)$(bindir)
>>  -   for i in build-stamp help.doc TAGS ; do \
>>  - $(INSTALL_DATA) $$i $(DESTDIR)$(ecldir); \
>> @@ -26,6 +25,7 @@ Index: src/Makefile.in
>>  -   $(LN_S) @SONAME3@ @SONAME1@ && \
>>  -   $(LN_S) @SONAME3@ @SONAME@ ) \
>>  -   fi
>> ++   $(INSTALL_DATA) help.doc $(DESTDIR)$(ecldir)
>>  +   ${INSTALL_LIBRARY} libecl.so $(DESTDIR)$(libdir)/$(LSP_LIBRARIES)
>>  +   cd $(DESTDIR)$(libdir) && ln -sf $(LSP_LIBRARIES) libecl.so
>>  $(INSTALL_PROGRAM) c/$(DPP) $(DESTDIR)$(ecldir)
>> blob - 510d663817b8a3936ee24c14411001f61c030bbf
>> file + /dev/null
>> --- lang/ecl/patches/patch-src_c_package_d
>> +++ /dev/null
>> @@ -1,26 +0,0 @@
>> -$OpenBSD: patch-src_c_package_d,v 1.1 2020/08/24 21:38:06 gkoehler Exp $
>> -
>> -Work around a SIGSEGV on 64-bit big-endian platforms
>> -(mips64, powerpc64, sparc64), from Daniel Kochmaski,
>> -https://gitlab.com/embeddable-common-lisp/ecl/-/issues/604#note_388147381
>> -
>> -Index: src/c/package.d
>>  src/c/package.d.orig
>> -+++ src/c/package.d
>> -@@ -327,10 +327,12 @@ ecl_find_package_nolock(cl_object name)
>> - return name;
>> -   name = cl_string(name);
>> - 
>> --  p = ecl_symbol_value(@'*package*');
>> --  if (ECL_PACKAGEP(p)) {
>> --p = ecl_assoc(name, p->pack.local_nicknames);
>> --if (!Null(p)) return ECL_CONS_CDR(p);
>> -+  if (ecl_option_values[ECL_OPT_BOOTED]) {
>> -+p = ecl_symbol_value(@'*package*');
>> -+if (ECL_PACKAGEP(p)) {
>> -+  p = ecl_assoc(name, p->pack.local_nicknames);
>> -+  if (!Null(p)) return ECL_CONS_CDR(p);
>> -+}
>> -   }
>> - 
>> -   l = cl_core.packages;
>> blob - 1f720b8258ab12e59b9c01b247cf29641de99555
>> file + lang/ecl/patches/patch-src_configure
>> --- lang/ecl/patches/patch-src_configure
>> +++ lang/ecl/patches/patch-src_configure
>> @@ -2,7 +2,7 @@ $OpenBSD: patch-src_configure,v 1.9 2020/08/24 21:38:0
>>  Index: src/configure
>>  --- src/configure.orig
>>  +++ src/configure
>> -@@ -5050,7 +5050,7 @@ LSP_FEATURES="(cons :android ${LSP_FEATURES})"
>> +@@ -5240,7 +5240,7 @@ LSP_FEATURES="(cons :android ${LSP_FEATURES})"
>>   BUNDLE_LDFLAGS="-shared ${LDFLAGS}"
>>   ECL_LDRPATH="-Wl,--rpath,~A"
>>   clibs="-lpthread ${clibs}"
>> @@ -11,7 +11,7 @@ Index: src/configure
>>   SONAME_LDFLAGS="-Wl,-soname,SONAME"
>>   ;;
>>   solaris*)
>> -@@ -9682,7 +9682,7 @@ if test ${enable_shared} = "yes"; then
>> +@@ -9910,7 +9910,7 @@ if test ${enable_shared} = "yes"; then
>>  
>>   $as_echo "#define ENABLE_DLOPEN 1" >>confdefs.h
>>  
>> blob - aaa872a968b99a07f318f3b31e3a8bf0ebbfea40
>> file + lang/ecl/pkg/PLIST
>> --- lang/ecl/pkg/PLIST
>> +++ lang/ecl/pkg/PLIST
>> @@ -29,7 +29,6 @@ include/ecl/object.h
>>  include/ecl/page.h
>>  include/ecl/stack-resize.h
>>  include/ecl/stacks.h
>> -info/ecl.info.gz
>>  lib/ecl/
>>  lib/ecl/COPYING
>>  lib/ecl/LICENSE

aarch64 bulk build report

[phessler]

bulk build on arm64.ports.openbsd.org
started on  Thu Jan 6 01:46:55 MST 2022
finished at Fri Jan 7 22:34:43 MST 2022
lasted 1D20h47m
done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1478: Wed Jan  5 
18:59:05 MST 2022

built packages:10320
Jan 6:4190
Jan 7:6129


critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2022-01-06/summary.log

build failures: 25
http://build-failures.rhaalovely.net/aarch64/2022-01-06/databases/db/v4,no_java,no_tcl.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/devel/jdk/17.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/games/irrlamb.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/games/jbrickshooter.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/games/lwjgl.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/games/mars.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/graphics/opencv.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/java/jBCrypt.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/java/jna.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/java/tanukiwrapper.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/lang/abcl.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/lang/kawa.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/misc/posixtestsuite.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/net/i2p.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/net/openfire.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/net/termshark.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/sysutils/gitlab-runner.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/sysutils/rundeck.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/sysutils/telegraf.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/textproc/p5-SWISH-API.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/textproc/pdftk.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/www/chromium.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/www/icedtea-web.log
http://build-failures.rhaalovely.net/aarch64/2022-01-06/www/seamonkey,-lightning.log

recurrent failures
 failures/databases/db/v4,no_java,no_tcl.log
 failures/devel/jdk/17.log
 failures/games/irrlamb.log
 failures/games/jbrickshooter.log
 failures/games/lwjgl.log
 failures/games/mars.log
 failures/graphics/opencv.log
 failures/java/jBCrypt.log
 failures/java/jna.log
 failures/java/tanukiwrapper.log
 failures/misc/posixtestsuite.log
 failures/net/i2p.log
 failures/net/openfire.log
 failures/net/termshark.log
 failures/sysutils/gitlab-runner.log
 failures/sysutils/rundeck.log
 failures/sysutils/telegraf.log
 failures/textproc/p5-SWISH-API.log
 failures/textproc/pdftk.log
 failures/www/icedtea-web.log
 failures/www/seamonkey,-lightning.log
new failures
+++ ls-failures Fri Jan  7 22:34:56 2022
+failures/www/chromium.log
resolved failures
--- ../old/aarch64/last//ls-failuresMon Jan  3 13:56:15 2022
-failures/devel/jdk/11.log
-failures/devel/qbs.log
-failures/graphics/vulkan-loader.log
-failures/net/profanity.log
-failures/productivity/libalkimia.log
-failures/www/firefox-esr.log

audio/pulseaudio: Fix zsh completion

[Matthew Martin]

Third party zsh completers should be installed to zsh/site-functions[1].
Since that's what pulseaudio does by default, just remove the flag.

1: https://github.com/zsh-users/zsh/blob/master/INSTALL#L257


diff --git Makefile Makefile
index a1863c1ee46..2eb0f4eccc5 100644
--- Makefile
+++ Makefile
@@ -5,6 +5,7 @@ COMMENT=cross-platform networked sound server
 VERSION=   15.0
 DISTNAME=  pulseaudio-${VERSION}
 EXTRACT_SUFX=  .tar.xz
+REVISION=  0
 
 SHARED_LIBS += pulse 7.2 # 0.24.0
 SHARED_LIBS += pulse-simple  1.2 # 0.1.1
@@ -67,7 +68,6 @@ CONFIGURE_ARGS=   -Ddoxygen=false \
-Ddatabase=tdb \
-Datomic-arm-linux-helpers=false \

-Dbashcompletiondir=${PREFIX}/share/bash-completion/completions \
-   
-Dzshcompletiondir=${PREFIX}/share/zsh/vendor-completions \
-Dalsa=disabled \
-Dasyncns=disabled \
-Davahi=disabled \
diff --git pkg/PLIST pkg/PLIST
index c5b8d9e969c..146c104d87b 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -238,5 +238,5 @@ share/vala/vapi/libpulse-simple.vapi
 share/vala/vapi/libpulse.deps
 share/vala/vapi/libpulse.vapi
 share/zsh/
-share/zsh/vendor-completions/
-share/zsh/vendor-completions/_pulseaudio
+share/zsh/site-functions/
+share/zsh/site-functions/_pulseaudio

powerpc bulk build report

[gkoehler]

Bulk build on macppc-0.ports.openbsd.org

Started : Mon Dec 20 21:39:14 MST 2021
Finished: Fri Jan  7 20:48:06 MST 2022
Duration: 17 Days 23 hours 9 minutes

Built using OpenBSD 7.0-current (GENERIC) #974: Mon Dec 20 00:37:28 MST 2021

Built 9210 packages

Number of packages built each day:
Dec 20: 184
Dec 21: 755
Dec 22: 429
Dec 23: 269
Dec 24: 149
Dec 25: 620
Dec 26: 374
Dec 27: 301
Dec 28: 158
Dec 29: 222
Dec 30: 145
Dec 31: 359
Jan 1: 584
Jan 2: 501
Jan 3: 288
Jan 4: 251
Jan 5: 366
Jan 6: 459
Jan 7: 2796


Critical path missing pkgs: 
http://build-failures.rhaalovely.net/powerpc/2021-12-20/summary.log

Build failures: 10
http://build-failures.rhaalovely.net/powerpc/2021-12-20/devel/qbs.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/emulators/higan.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/emulators/mednafen.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/games/hyperrogue.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/games/puzzles.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/lang/pcc/pcc-libs.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/math/coq.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/misc/posixtestsuite.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/www/webkitgtk4.log
http://build-failures.rhaalovely.net/powerpc/2021-12-20/x11/qt6/qttools.log

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 18:36:34

Modified files:
www/qutebrowser: Makefile 

Log message:
i386 qutebrowser can depend on py3-adblock now

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 18:35:55

Modified files:
www/py-adblock : Makefile 

Log message:
py3-adblock builds ok on i386 now (maybe after a rust update, I didn't
retry it since rust 1.57.0), drop NOT_FOR_ARCHS

Re: new: lang/polyml

[Brian Callahan]

On 1/7/2022 8:31 PM, Stuart Henderson wrote:
> On 2022/01/08 00:42, Brian Callahan wrote:
>> * We don't need the COMPILER line if we're just going to use the default
>> compilers for each arch; it can go.
> 
> The COMPILER setting was correct, C++ ports should use base-clang or
> ports-gcc ahead of base-gcc. portcheck warns about this too.
> 

Gotcha. Easy to add back.

>> * The configure script also searches for (and fails to find) -lgmp. The
>> configure script has a --without-gmp option, which I think is what we
>> want here. That is set with CONFIGURE_ARGS.
> 
> I didn't try building but likely that setting include/library
> search paths in CPPFLAGS/LDFLAGS in CONFIGURE_ENV will help it find gmp.
> 

It will. Was not sure if we wanted gmp or not. Seems to work fine
without it.

~Brian

Re: new: lang/polyml

[Stuart Henderson]

On 2022/01/08 00:42, Brian Callahan wrote:
> * We don't need the COMPILER line if we're just going to use the default
> compilers for each arch; it can go.

The COMPILER setting was correct, C++ ports should use base-clang or
ports-gcc ahead of base-gcc. portcheck warns about this too.

> * The configure script also searches for (and fails to find) -lgmp. The
> configure script has a --without-gmp option, which I think is what we
> want here. That is set with CONFIGURE_ARGS.

I didn't try building but likely that setting include/library
search paths in CPPFLAGS/LDFLAGS in CONFIGURE_ENV will help it find gmp.

Re: new: lang/polyml

[Brian Callahan]

Hi Leo --

On 1/7/2022 5:39 PM, Leo Larnack wrote:
> Hi ports@,
> 
> Here is my attempt at porting Poly/ML[1].
> 
> Poly/ML is a Standard ML implementation originally written in an
> experimental language called Poly. It has been fully compatible
> with the ML97 standard since version 4.0.
> 
> Poly/ML takes a conservative approach to the Standard ML language
> and avoids incompatible extensions. It has added various library
> extensions particularly the thread library. Poly/ML's active
> development and unique features make it an exceptional implementation.
> 
> Tests are passing (amd64).
> 
> I'd be happy to read your comments.
> 
> [1] https://polyml.org
> 

Thanks for the port. Attached is your port with some additional tweaks
which should streamline a few things in your original submission:
* A quick glance makes it look like the license is a combination of
LGPLv2.1 and LGPLv2.1+, so I marked the license as LGPLv2.1 only to make
it a little more clear.
* SHARED_LIB should always start with 0.0 -- the ports system will
helpfully output the correct line you need if you omit it and it
discovers a shared library when creating the PLIST.
* We don't need the COMPILER line if we're just going to use the default
compilers for each arch; it can go.
* You're missing a WANTLIB. If you run `make port-lib-depends-check` the
ports system will output what you need.
* I noticed that your patch switches the check for -lstdc++ to -lc++.
I'm not 100% sure that flies at the moment for sparc64 when using the
default compiler. But we can do one better: the define this test sets
goes completely unused in the Poly/ML source code, so let's just rip the
whole test out. This has the benefit of removing your patch to
configure.ac for a patch to configure, which comes with not needing all
the autoconf/automake stuff, so this port has no external depends needed.
* The configure script searches for and runs git if it finds it. That's
a no-no. Fortunately, we can override the test with a simple
CONFIGURE_ENV line.
* The configure script also searches for (and fails to find) -lgmp. The
configure script has a --without-gmp option, which I think is what we
want here. That is set with CONFIGURE_ARGS.
* No need for an ALL_TARGET. Everything works fine without it.

Tarball attached. All test pass on amd64 here as well.

~Brian

polyml.tgz
Description: application/compressed

Re: (update) icewm-2.9.3

[Omar Polo]

Timo Myyrä  writes:

> Hi,
>
> Here's an little bump for icewm, works fine here on amd64.
>
> timo

committed with WANTLIBs synced, thanks!

CVS: cvs.openbsd.org: ports

[Omar Polo]

CVSROOT:/cvs
Module name:ports
Changes by: o...@cvs.openbsd.org2022/01/07 14:54:16

Modified files:
x11/icewm  : Makefile distinfo 
x11/icewm/pkg  : PLIST 

Log message:
update icewm to 2.9.3

diff from Timo Myyrä with tweaks by me (regen WANTLIBs.)  Tested by
John Batteen too, thanks!

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 14:05:27

Modified files:
net/arp-scan   : Makefile 
net/arp-scan/files: unofficial.csv 

Log message:
add text for the ipv6 vrrp mac addresses which use a different prefix

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 13:54:48

Modified files:
net/arp-scan   : Makefile distinfo 

Log message:
update to a newer arp-scan commit, and update the OUI list

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2022/01/07 13:26:38

Modified files:
net/prosody: Makefile distinfo 
net/prosody/patches: patch-makefile 

Log message:
Update prosody to 0.11.11

Update diff from MAINTAINER

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 13:06:27

Modified files:
telephony/asterisk: Makefile.inc 
telephony/asterisk/16: Makefile 
telephony/asterisk/18: Makefile 
telephony/asterisk/19: Makefile 
telephony/asterisk/19/pkg: PLIST-main README-main 
Added files:
telephony/asterisk/16/patches: 
   patch-configs_basic-pbx_asterisk_conf 
telephony/asterisk/18/patches: 
   patch-configs_basic-pbx_asterisk_conf 
telephony/asterisk/19/patches: 
   patch-configs_basic-pbx_asterisk_conf 
Removed files:
telephony/asterisk/19/files: cdr.conf.sample 
 extensions.ael.sample 
 extensions.conf.sample 
 logger.conf.sample 
 modules.conf.sample 
 musiconhold.conf.sample 
 sip.conf.sample 
 voicemail.conf.sample 

Log message:
asterisk port tweaks:

- patch the sample asterisk.conf file in the basic-pbx directory to
include setting ownership/permissions on the control socket as also done
in the simple openbsd-ports config files

- remove the simple openbsd-ports config files from asterisk/19; they pre-date
upstream's "basic-pbx" files and use chan_sip which was removed in 19.x
so don't work

Re: net/libcares: Problem with includes in OpenBSD

[Volker Schlecht]

Just to exclude the possibility of a misunderstanding here:

I proposed to add a patch to the *node* port to define these enums, 
rather than to patch each single line in node's cares_wrap.cc.


I did not intend to do anything with net/libcares...

On 1/7/22 19:56, Stuart Henderson wrote:

On 2022/01/07 17:36, Volker Schlecht wrote:

Got it ... given that I dont't really want to patch all of cares_wrap.cc,


That is exactly how we handle this issue with other ports (ettercap,
pciutils, asterisk, squid).


would it be ok to patch this section verbatim into cares_wrap.h?

It seems indeed that libcares exposes these for NodeJS exclusively, at least
for now ...https://github.com/c-ares/c-ares/issues/415


I'm not maintainer of net/libcares port (CC'd) but I don't think that
is really the best fix. And the fact that we've not seen these issues
with other ports using c-ares suggests that it is node which is doing
something not quite right w.r.t. the usual c-ares api here..




On 1/7/22 17:31, Stuart Henderson wrote:

On 2022/01/07 15:14, Volker Schlecht wrote:

Hi,

while working on a port for NodeJS 16.x, I noticed that net/libcares
provides a /usr/local/include/ares_nameser.h that doesn't work on OpenBSD:

In Lines 68 through 178, the enum ns_rcode, ns_opcode, ns_type are only
defined if CARES_HAVE_ARPA_NAMESER_H is not defined. OpenBSD has
arpa/nameser.h but it doesn't define those enums.

As per the comment, c-ares makes the assumption that arpa/nameser.h should
define them:

/*

* arpa/nameser.h should provide these enumerations always, so if not found,
* provide them
*

*/


I'm not sure if the right approach would be to define those enums in
OpenBSDs arpa/nameser.h (FreeBSD and Linux seem to do that) or to remove the
condition from the include File in the c-ares port, or if there's another
even better solution?


c-ares itself only uses those enums if the other macros (SERVFAIL,
NOTIMP, REFUSED, etc) aren't defined (which they are), so it's not a general
"the c-ares headers don't work" problem.

If you look at the sample code in c-ares and various other software
using c-ares they're all using T_XXX so I think node's cares_wrap.cc is
doing things wrong in this case and should probably change to T_XXX too.

In more general-purpose use i.e. not for software using c-ares, ns_t_xxx
is more common and it would be nice if our nameser.h worked the same way as
pretty much every other OS so we didn't have to keep patching things, but
I think that's an orthogonal problem (and last time I mentioned that
problem deraadt@ looked at it and didn't seem terribly happy about
changing things...)

Re: net/libcares: Problem with includes in OpenBSD

[Stuart Henderson]

On 2022/01/07 17:36, Volker Schlecht wrote:
> Got it ... given that I dont't really want to patch all of cares_wrap.cc,

That is exactly how we handle this issue with other ports (ettercap,
pciutils, asterisk, squid).

> would it be ok to patch this section verbatim into cares_wrap.h?
> 
> It seems indeed that libcares exposes these for NodeJS exclusively, at least
> for now ...https://github.com/c-ares/c-ares/issues/415

I'm not maintainer of net/libcares port (CC'd) but I don't think that
is really the best fix. And the fact that we've not seen these issues
with other ports using c-ares suggests that it is node which is doing
something not quite right w.r.t. the usual c-ares api here..


> 
> On 1/7/22 17:31, Stuart Henderson wrote:
> > On 2022/01/07 15:14, Volker Schlecht wrote:
> > > Hi,
> > > 
> > > while working on a port   for NodeJS 16.x, I noticed that net/libcares
> > > provides a /usr/local/include/ares_nameser.h that doesn't work on OpenBSD:
> > > 
> > > In Lines 68 through 178, the enum ns_rcode, ns_opcode, ns_type are only
> > > defined if CARES_HAVE_ARPA_NAMESER_H is not defined. OpenBSD has
> > > arpa/nameser.h but it doesn't define those enums.
> > > 
> > > As per the comment, c-ares makes the assumption that arpa/nameser.h should
> > > define them:
> > > 
> > > /*
> > > 
> > > * arpa/nameser.h should provide these enumerations always, so if not 
> > > found,
> > > * provide them
> > > *
> > > 
> > > */
> > > 
> > > 
> > > I'm not sure if the right approach would be to define those enums in
> > > OpenBSDs arpa/nameser.h (FreeBSD and Linux seem to do that) or to remove 
> > > the
> > > condition from the include File in the c-ares port, or if there's another
> > > even better solution?
> > 
> > c-ares itself only uses those enums if the other macros (SERVFAIL,
> > NOTIMP, REFUSED, etc) aren't defined (which they are), so it's not a general
> > "the c-ares headers don't work" problem.
> > 
> > If you look at the sample code in c-ares and various other software
> > using c-ares they're all using T_XXX so I think node's cares_wrap.cc is
> > doing things wrong in this case and should probably change to T_XXX too.
> > 
> > In more general-purpose use i.e. not for software using c-ares, ns_t_xxx
> > is more common and it would be nice if our nameser.h worked the same way as
> > pretty much every other OS so we didn't have to keep patching things, but
> > I think that's an orthogonal problem (and last time I mentioned that
> > problem deraadt@ looked at it and didn't seem terribly happy about
> > changing things...)
> > 
> 

Re: [New] sysutils/cmdseq

[Laurence Tratt]

On Fri, Jan 07, 2022 at 06:23:19PM +0100, Omar Polo wrote:

Hello Omar,

> The port looks fine, I'd just switch HOMEPAGE to https, set PKG_ARCH=* and
> drop CONFIGURE_STYLE.  I'm attaching an updated tarball and a diff against
> your Makefile.  I'm sorry but I couldn't help myself to not slightly tweak
> MASTER_SITES: I know I'm bikeshedding, but I think that it's more readable,
> even if it has a couple of extra characters in it.
> Just a suggestion, I'm obviously fine either the way :)

I'm fine with all your changes -- please go ahead!

> I'd like to ask what's the intended usage though.  Honestly, it seems
> powerful to cycle different commands but -without having given it too much
> thoughts- I can't come up with anything.  I think it'd be interesting so
> see some more elaborate examples of its usage.

Personally I mostly use it in cron for backup-type operations where I have
long/short variants: I can run either at any point, but not both together.
Depending on how frequently you want them to run, that can be surprisingly
cumbersome and fragile to express in cron. Instead, I just do something like
"cmdseq 100  1 ".

A couple of other people have used it for non-cron things, although I don't
know much more than that. I think the Unix way is to give people flexible
tools and let them find unexpected uses for them :)


Laurie

CVS: cvs.openbsd.org: ports

[Brian Callahan]

CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2022/01/07 11:14:10

Modified files:
sysutils/ugrep : Makefile distinfo 

Log message:
Update to ugrep-3.5.0
Changelog: https://github.com/Genivia/ugrep/releases/tag/v3.5.0

Re: net/libcares: Problem with includes in OpenBSD

[Volker Schlecht]

Got it ... given that I dont't really want to patch all of 
cares_wrap.cc, would it be ok to patch this section verbatim into 
cares_wrap.h?


It seems indeed that libcares exposes these for NodeJS exclusively, at 
least for now ...https://github.com/c-ares/c-ares/issues/415


On 1/7/22 17:31, Stuart Henderson wrote:

On 2022/01/07 15:14, Volker Schlecht wrote:

Hi,

while working on a port for NodeJS 16.x, I noticed that net/libcares
provides a /usr/local/include/ares_nameser.h that doesn't work on OpenBSD:

In Lines 68 through 178, the enum ns_rcode, ns_opcode, ns_type are only
defined if CARES_HAVE_ARPA_NAMESER_H is not defined. OpenBSD has
arpa/nameser.h but it doesn't define those enums.

As per the comment, c-ares makes the assumption that arpa/nameser.h should
define them:

/*

* arpa/nameser.h should provide these enumerations always, so if not found,
* provide them
*

*/


I'm not sure if the right approach would be to define those enums in
OpenBSDs arpa/nameser.h (FreeBSD and Linux seem to do that) or to remove the
condition from the include File in the c-ares port, or if there's another
even better solution?


c-ares itself only uses those enums if the other macros (SERVFAIL,
NOTIMP, REFUSED, etc) aren't defined (which they are), so it's not a general
"the c-ares headers don't work" problem.

If you look at the sample code in c-ares and various other software
using c-ares they're all using T_XXX so I think node's cares_wrap.cc is
doing things wrong in this case and should probably change to T_XXX too.

In more general-purpose use i.e. not for software using c-ares, ns_t_xxx
is more common and it would be nice if our nameser.h worked the same way as
pretty much every other OS so we didn't have to keep patching things, but
I think that's an orthogonal problem (and last time I mentioned that
problem deraadt@ looked at it and didn't seem terribly happy about
changing things...)

Re: [New] sysutils/cmdseq

[Omar Polo]

Omar Polo  writes:

> Laurence Tratt  writes:
>
>> Please find attached a port for cmdseq-0.2
>> :
>>
>>   cmdseq allows users to execute interleaved sequences of commands. Assuming
>>   the same counts and commands, on each execution cmdseq executes one of the
>>   commands, cycling through the sequence and wrapping back to the beginning
>>   when it is complete. For example, consider the following sequence:
>>
>> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
>> cmd1
>> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
>> cmd1
>> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
>> cmd2
>> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
>> cmd1
>>
>>
>> Laurie
>>
>> [2. application/x-tar-gz; cmdseq.tgz]...
>
> Hello,
>
> The port looks fine, I'd just switch HOMEPAGE to https, set PKG_ARCH=*
> and drop CONFIGURE_STYLE.  I'm attaching an updated tarball and a diff
> against your Makefile.  I'm sorry but I couldn't help myself to not
> slightly tweak MASTER_SITES: I know I'm bikeshedding, but I think that
> it's more readable, even if it has a couple of extra characters in it.
> Just a suggestion, I'm obviously fine either the way :)
>
> The utility also works as advertised.  It's ok for me to import it.
>
> I'd like to ask what's the intended usage though.  Honestly, it seems
> powerful to cycle different commands but -without having given it too
> much thoughts- I can't come up with anything.  I think it'd be
> interesting so see some more elaborate examples of its usage.

Woops, sent too fast.  I just saw the cron example on the homepage, and
that's really interesting!

P.S.: i'd add the cron example in the manpage too :)

> Cheers
>
> Omar Polo
>
>
> --- Makefile.orig Fri Jan  7 18:42:40 2022
> +++ Makefile  Fri Jan  7 18:42:50 2022
> @@ -5,19 +5,18 @@
>  DISTNAME =   cmdseq-0.2
>  CATEGORIES = sysutils
>  
> -HOMEPAGE =   http://tratt.net/laurie/src/cmdseq/
> +HOMEPAGE =   https://tratt.net/laurie/src/cmdseq/
>  
>  MAINTAINER = Laurence Tratt 
>  
>  # Apache-2.0 / MIT
>  PERMIT_PACKAGE = Yes
>  
> -MASTER_SITES =   ${HOMEPAGE}releases/
> +MASTER_SITES =   ${HOMEPAGE:=releases/}
>  
>  EXTRACT_SUFX =   .tgz
>  
> -CONFIGURE_STYLE =none
> -
> +PKG_ARCH =   *
>  NO_BUILD =   Yes
>  NO_TEST =Yes
>  
>
> [2. application/octet-stream; cmdseq.tar.gz]...

Re: [New] sysutils/cmdseq

[Omar Polo]

Laurence Tratt  writes:

> Please find attached a port for cmdseq-0.2
> :
>
>   cmdseq allows users to execute interleaved sequences of commands. Assuming
>   the same counts and commands, on each execution cmdseq executes one of the
>   commands, cycling through the sequence and wrapping back to the beginning
>   when it is complete. For example, consider the following sequence:
>
> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
> cmd1
> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
> cmd1
> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
> cmd2
> $ cmdseq 2 "echo cmd1" 1 "echo cmd2"
> cmd1
>
>
> Laurie
>
> [2. application/x-tar-gz; cmdseq.tgz]...

Hello,

The port looks fine, I'd just switch HOMEPAGE to https, set PKG_ARCH=*
and drop CONFIGURE_STYLE.  I'm attaching an updated tarball and a diff
against your Makefile.  I'm sorry but I couldn't help myself to not
slightly tweak MASTER_SITES: I know I'm bikeshedding, but I think that
it's more readable, even if it has a couple of extra characters in it.
Just a suggestion, I'm obviously fine either the way :)

The utility also works as advertised.  It's ok for me to import it.

I'd like to ask what's the intended usage though.  Honestly, it seems
powerful to cycle different commands but -without having given it too
much thoughts- I can't come up with anything.  I think it'd be
interesting so see some more elaborate examples of its usage.

Cheers

Omar Polo


--- Makefile.orig   Fri Jan  7 18:42:40 2022
+++ MakefileFri Jan  7 18:42:50 2022
@@ -5,19 +5,18 @@
 DISTNAME = cmdseq-0.2
 CATEGORIES =   sysutils
 
-HOMEPAGE = http://tratt.net/laurie/src/cmdseq/
+HOMEPAGE = https://tratt.net/laurie/src/cmdseq/
 
 MAINTAINER =   Laurence Tratt 
 
 # Apache-2.0 / MIT
 PERMIT_PACKAGE =   Yes
 
-MASTER_SITES = ${HOMEPAGE}releases/
+MASTER_SITES = ${HOMEPAGE:=releases/}
 
 EXTRACT_SUFX = .tgz
 
-CONFIGURE_STYLE =  none
-
+PKG_ARCH = *
 NO_BUILD = Yes
 NO_TEST =  Yes
 


cmdseq.tar.gz
Description: Binary data

Re: UPDATE net/prosody 0.11.11 from MAINTAINER

[Lucas]

Lucas  wrote:
> Hi ports,
> 
> Prosody 0.11.11 release on 20-Dec. The release includes:
> 
> ## Fixes and improvements
> 
>   * net.server_epoll: Prioritize network events over timers to improve 
> performance under heavy load
>   * mod_pep: Add some memory usage limits
>   * mod_pep: Prevent creation of services for non-existent users
>   * mod_pep: Free resources on user deletion (needed a restart previously)
> 
> ## Minor changes
> 
>   * mod_pep: Free resources on reload
>   * mod_c2s: Indicate stream secure state in error text when no stream 
> features to offer
>   * MUC: Fix logic for access to affiliation lists
>   * net.server_epoll: Improvements to shutdown procedure 
> [#1670](https://issues.prosody.im/1670)
>   * net.server_epoll: Fix potential issue with rescheduling of timers
>   * prosodyctl: Fix to ensure LuaFileSystem is loaded when needed
>   * util.startup: Fix handling of unknown command line flags (e.g. `-h`)
>   * Fix version number reported as 'unknown' on *BSD

Bump.

diff a76422629a46836e2cb2be727c938e1fa598ae0c /usr/ports
blob - 4a8c38283b42bb5a2312291d879e0114e97b822e
file + net/prosody/Makefile
--- net/prosody/Makefile
+++ net/prosody/Makefile
@@ -1,10 +1,9 @@
 # $OpenBSD: Makefile,v 1.64 2021/08/23 05:38:49 rsadowski Exp $
 
 COMMENT =  communications server for Jabber/XMPP written in Lua
-DISTNAME = prosody-0.11.10
+DISTNAME = prosody-0.11.11
 CATEGORIES =   net
 HOMEPAGE = https://prosody.im/
-REVISION = 0
 
 MAINTAINER =   Lucas 
 
blob - d78f08aadcaecc337ec0cd87c4e6a0ae05df957a
file + net/prosody/distinfo
--- net/prosody/distinfo
+++ net/prosody/distinfo
@@ -1,2 +1,2 @@
-SHA256 (prosody-0.11.10.tar.gz) = xtcU5tSm3dHbEmayBdnYo+2RgY9CdVySaP+xg1nSBOE=
-SIZE (prosody-0.11.10.tar.gz) = 43
+SHA256 (prosody-0.11.11.tar.gz) = oa+Q4tSsL3z4GzhUdRQOzuYL7B64MAPvta64l2WxN3Q=
+SIZE (prosody-0.11.11.tar.gz) = 439395
blob - 5dd352660701fcca0437b469e6bf60291e8d0963
file + net/prosody/patches/patch-makefile
--- net/prosody/patches/patch-makefile
+++ net/prosody/patches/patch-makefile
@@ -1,8 +1,6 @@
 $OpenBSD: patch-makefile,v 1.2 2021/08/23 05:38:49 rsadowski Exp $
 
-- First hunk: fix directories
-- Second hunk: fix `prosody.version` target to stop reporting prosody
-  version as `unknown`
+fix directories
 
 Index: makefile
 --- makefile.orig
@@ -22,25 +20,3 @@ Index: makefile
  
  INSTALLEDSOURCE = $(LIBDIR)/prosody
  INSTALLEDCONFIG = $(SYSCONFDIR)
-@@ -90,12 +90,12 @@ prosody.cfg.lua.install: prosody.cfg.lua.dist
-   sed 's|certs/|$(INSTALLEDCONFIG)/certs/|' prosody.cfg.lua.dist > $@
- 
- prosody.version:
--  test -f prosody.release && \
--  cp prosody.release $@ || \
--  test -f .hg_archival.txt && \
--  sed -n 's/^node: \(\).*/\1/p' .hg_archival.txt > $@ 
|| \
--  test -f .hg/dirstate && \
--  hexdump -n6 -e'6/1 "%02x"' .hg/dirstate > $@ || \
--  echo unknown > $@
--
--
-+  if [ -f prosody.release ]; then \
-+  cp prosody.release $@; \
-+  elif [ -f .hg_archival.txt ]; then \
-+  sed -n 's/^node: \(\).*/\1/p' .hg_archival.txt > 
$@; \
-+  elif [ -f .hg/dirstate ]; then \
-+  hexdump -n6 -e'6/1 "%02x"' .hg/dirstate > $@; \
-+  else \
-+  echo unknown > $@; \
-+  fi

CVS: cvs.openbsd.org: ports

[Kurt Mosiejczuk]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2022/01/07 09:39:55

Modified files:
graphics/mojoshader: Makefile 

Log message:
Switch base-gcc arches to use ports-gcc to fix build on sparc64

ok thfr (maintainer)

Re: net/libcares: Problem with includes in OpenBSD

[Stuart Henderson]

On 2022/01/07 15:14, Volker Schlecht wrote:
> Hi,
> 
> while working on a port   for NodeJS 16.x, I noticed that net/libcares
> provides a /usr/local/include/ares_nameser.h that doesn't work on OpenBSD:
> 
> In Lines 68 through 178, the enum ns_rcode, ns_opcode, ns_type are only
> defined if CARES_HAVE_ARPA_NAMESER_H is not defined. OpenBSD has
> arpa/nameser.h but it doesn't define those enums.
> 
> As per the comment, c-ares makes the assumption that arpa/nameser.h should
> define them:
> 
> /*
> 
> * arpa/nameser.h should provide these enumerations always, so if not found,
> * provide them
> *
> 
> */
> 
> 
> I'm not sure if the right approach would be to define those enums in
> OpenBSDs arpa/nameser.h (FreeBSD and Linux seem to do that) or to remove the
> condition from the include File in the c-ares port, or if there's another
> even better solution?

c-ares itself only uses those enums if the other macros (SERVFAIL,
NOTIMP, REFUSED, etc) aren't defined (which they are), so it's not a general
"the c-ares headers don't work" problem.

If you look at the sample code in c-ares and various other software
using c-ares they're all using T_XXX so I think node's cares_wrap.cc is
doing things wrong in this case and should probably change to T_XXX too.

In more general-purpose use i.e. not for software using c-ares, ns_t_xxx
is more common and it would be nice if our nameser.h worked the same way as
pretty much every other OS so we didn't have to keep patching things, but
I think that's an orthogonal problem (and last time I mentioned that
problem deraadt@ looked at it and didn't seem terribly happy about
changing things...)

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 08:54:07

Modified files:
mail/evolution-ews: Makefile distinfo 

Log message:
Update to evolution-ews-3.42.3.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 08:53:50

Modified files:
mail/evolution : Makefile distinfo 

Log message:
Update to evolution-3.42.3.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 08:53:30

Modified files:
databases/evolution-data-server: Makefile distinfo 

Log message:
Update to evolution-data-server-3.42.3.

net/libcares: Problem with includes in OpenBSD

[Volker Schlecht]

Hi,

while working on a port	for NodeJS 16.x, I noticed that net/libcares 
provides a /usr/local/include/ares_nameser.h that doesn't work on OpenBSD:


In Lines 68 through 178, the enum ns_rcode, ns_opcode, ns_type are only
defined if CARES_HAVE_ARPA_NAMESER_H is not defined. OpenBSD has 
arpa/nameser.h but it doesn't define those enums.


As per the comment, c-ares makes the assumption that arpa/nameser.h 
should define them:


/* 


* arpa/nameser.h should provide these enumerations always, so if not found,
* provide them
* 


*/


I'm not sure if the right approach would be to define those enums in 
OpenBSDs arpa/nameser.h (FreeBSD and Linux seem to do that) or to remove 
the condition from the include File in the c-ares port, or if there's 
another even better solution?


cu,
Volker

Re: WIP: Solo-0.0.31

[Gonzalo Rodriguez]

On 1/7/22 12:31, Stuart Henderson wrote:

On 2022/01/07 12:12, Gonzalo Rodriguez wrote:

Hello,

This is a new port for the Solokeys cli "solo":

https://github.com/solokeys/solo-python
https://solokeys.com/

Attached also 2 diffs for py-click and py-fido2 to make solo work, don't
take them as real upgrades.


It would be nice to get elasticsearch-curator updated so click could
be updated for real, this is coming up with other ports too.
Any reason why you went for 7.1 rather than 7.1.2 of click?


No, I just took the one that I need to make it work, I can change it, 
about elasticsearch-curator I never used it, so really don't know, I can 
give it a try.




Unfortunately py-fido2 is a can of worms. Updating py-fido2 means
yubikey-manager needs an update to 4.x. But yubikey-manager 4.x has some
fairly big changes and doesn't work with OpenBSD as-is.


I really don't need "solo" in, but I think it would be nice to make 
proper updates for all them.






Index: Makefile
===
RCS file: /cvs/ports/security/py-fido2/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile2 Nov 2021 00:02:17 -   1.6
+++ Makefile6 Jan 2022 18:17:01 -
@@ -8,14 +8,13 @@ COMMENT = Python module to communicate
  # which in turn needs an update of py-click.
  GH_ACCOUNT =  Yubico
  GH_PROJECT =  python-fido2
-GH_COMMIT =46a0b649b9aa9af79566e6e3961021e070d98b1c
+GH_COMMIT =58471d4af1c09cc9fe316771d6203b4844cbc668
  
-MODPY_EGG_VERSION =	0.8.2.dev0

+MODPY_EGG_VERSION =0.9.3


this should use GH_TAGNAME=0.9.3 / MODPY_EGG_VERSION=${GH_TAGNAME} or
similar.

  
  #DISTNAME =		fido2-${MODPY_EGG_VERSION}

  #PKGNAME =py-${DISTNAME}
-DISTNAME = py-fido2-0.8.2pre20200313
-REVISION = 1
+DISTNAME = py-fido2-0.9.3
  
  CATEGORIES =		security
  
Index: distinfo

===
RCS file: /cvs/ports/security/py-fido2/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo23 May 2020 21:55:55 -  1.3
+++ distinfo6 Jan 2022 18:17:01 -
@@ -1,2 +1,2 @@
-SHA256 (py-fido2-0.8.2pre20200313-46a0b649.tar.gz) = 
WH4RUQ6IOeruJ8Zp0iBIaI6buEPJmdvU8mPpXXhrPu4=
-SIZE (py-fido2-0.8.2pre20200313-46a0b649.tar.gz) = 210085
+SHA256 (py-fido2-0.9.3-58471d4a.tar.gz) = 
IYt3dGb+Znm6esEtTQhIfU4Fjqd4yW7NU2n8/LjXylU=
+SIZE (py-fido2-0.9.3-58471d4a.tar.gz) = 219249
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/py-fido2/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST   23 May 2020 21:55:55 -  1.3
+++ pkg/PLIST   6 Jan 2022 18:17:01 -
@@ -1,25 +1,20 @@
  @comment $OpenBSD: PLIST,v 1.3 2020/05/23 21:55:55 sthen Exp $
  @pkgpath security/py-fido2
  lib/python${MODPY_VERSION}/site-packages/fido2/
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/PKG-INFO
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/SOURCES.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/requires.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/top_level.txt
  lib/python${MODPY_VERSION}/site-packages/fido2/__init__.py
  
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}/
  
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}_tpm.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}attestation.${MODPY_PYC_MAGIC_TAG}pyc
  
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}cbor.${MODPY_PYC_MAGIC_TAG}pyc
  
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}client.${MODPY_PYC_MAGIC_TAG}pyc
  
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}cose.${MODPY_PYC_MAGIC_TAG}pyc
  

CVS: cvs.openbsd.org: ports

[Klemens Nanni]

CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2022/01/07 07:10:00

Modified files:
net/usrsctp: Makefile distinfo 

Log message:
Switch fixes merged upstream

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 07:04:03

Modified files:
lang/php   : Makefile.inc 

Log message:
revert previous attempt here

NEW: security/evil-winrm

[Sebastian Reitenbach]

Hi,

this is a port of evil-winrm:

WinRM (Windows Remote Management) is the Microsoft implementation of
WS-Management Protocol. A standard SOAP based protocol that allows
hardware and operating systems from different vendors to interoperate.
Microsoft included it in their Operating Systems in order to make life
easier to system administrators.

This program can be used on any Microsoft Windows Servers with this
feature enabled (usually at port 5985), of course only if you have
credentials and permissions to use it. So we can say that it could be
used in a post-exploitation hacking/pentesting phase. The purpose of
this program is to provide nice and easy-to-use features for hacking. It
can be used with legitimate purposes by system administrators as well
but the most of its features are focused on hacking/pentesting stuff.

It requires the other ports of rubygems I just sent as dependencies.

OK?

Sebastian


evil-winrm.tar.gz
Description: application/gzip

NEW: devel/ruby-gssapi

[Sebastian Reitenbach]

Hi,

this is a port of gssapi Ruby gem:

A FFI wrapper around the system GSSAPI library. Please make sure and
read the Yard docs or standard GSSAPI documentation if you have any
questions. There is also a class called GSSAPI::Simple that wraps many
of the common features used for GSSAPI.

it's a dependency of evil-winrm.

OK?

Sebastian


ruby-gssapi.tar.gz
Description: application/gzip

NEW: textproc/ruby-erubi

[Sebastian Reitenbach]

Hi,

this is a port of eruby Ruby gem:

Erubi is a ERB template engine for ruby. It is a simplified fork of
Erubis, using the same basic algorithm, with a few differences.

it's a dependency of evil-winrm.

OK?

Sebastian


ruby-erubi.tar.gz
Description: application/gzip

NEW: devel/ruby-logging

[Sebastian Reitenbach]

Hi,
this is a port of logging Ruby gem:

**Logging** is a flexible logging library for use in Ruby programs based
on the design of Java's log4j library. It features a hierarchical
logging system, custom level names, multiple output destinations per log
event, custom formatting, and more.

it's a dependency of evil-winrm.

OK?

Sebastian


ruby-logging.tar.gz
Description: application/gzip

NEW: textproc/ruby-gyoku

[Sebastian Reitenbach]

Hi,

this is a port of gyoku Ruby gem:

Gyoku translates Ruby Hashes to XML.

it's a dependency of evil-winrm.

OK?

Sebastian


ruby-gyoku.tar.gz
Description: application/gzip

NEW: textproc/ruby-nori

[Sebastian Reitenbach]

Hi

this is a port of nori Ruby gem:

Really simple XML parsing ripped from Crack which ripped it from Merb.
Nori was created to bypass the stale development of Crack, improve its
XML parser and fix certain issues.

it's a dependency of evil-winrm

OK?

Sebastian


ruby-nori.tar.gz
Description: application/gzip

NEW: devel/ruby-little-plugger

[Sebastian Reitenbach]

Hi,

this is a port of little-plugger Ruby gem:

LittlePlugger is a module that provides Gem based plugin management. By
extending your own class or module with LittlePlugger you can easily
manage the loading and initializing of plugins provided by other gems.

it's a dependency of evil-winrm

OK?

Sebastian


ruby-little-plugger.tar.gz
Description: application/gzip

NEW: devel/ruby-winrm

[Sebastian Reitenbach]

Hi,

this is a port of winrm Ruby gem:

File system operations over Windows Remote Management (WinRM) for Ruby.
sebastia@communicator:~/Downloads/EVIL_PORTS> cat ruby-winrm/pkg/DESCR  

This is a SOAP library that uses the functionality in Windows Remote
Management(WinRM) to call native object in Windows. This includes, but
is not limited to, running batch scripts, powershell scripts and
fetching WMI variables. For more information on WinRM, please visit
Microsoft's WinRM site.

As of version 2.0, this gem retains the WinRM name but all powershell
calls use the more modern Powershell Remoting Protocol (PSRP) for
initializing runspace pools as well as creating and processing
powershell pipelines.


it's a dependency of evil-winrm

OK?


ruby-winrm.tar.gz
Description: application/gzip

NEW: devel/ruby-winrm-fs

[Sebastian Reitenbach]

Hi,

this is a port of winrm-fs:

File system operations over Windows Remote Management (WinRM) for Ruby.

it's a dependency for evil-winrm.

OK?

Sebastian


ruby-winrm-fs.tar.gz
Description: application/gzip

Re: CVS: cvs.openbsd.org: ports

[Andrew Krasavin]

On Mon, Jan 03, 2022 at 01:33:00PM +0100, Rafael Sadowski wrote:

On Tue, Dec 21, 2021 at 10:43:37AM +0300, Andrew Krasavin wrote:
Unfortunately, I have not yet been able to figure out exactly what
the problem is with seek + mpv with ao_sndio from #9298.


First of all, I would like to apologise if my first email was too rude.



I didn't find your letter rude, but thank you for your concern.
Anyway, feel free to express your thoughts as you feel comfortable,
I'm not sensitive.



I deleted all entries from my ~/.config/mpv/config, created
~/.config/mpv/input.conf which is an exact copy of yours.

Next, I tried playing different videos (mp4[*] and webm) and then
moving through them in large segments in different directions
randomly.
I didn't notice any weirdness.

Then I built mpv 0.34 with ao_sndio from #8314 (the original version
of the patch from Ivan Rozhuk) and roughly repeated my steps.

Notice the difference could not.

I probably just don't understand what exactly I'm talking about.

If it's not too much trouble:

1) Please describe in more detail exactly how the problem manifests
itself. What exactly should I see? What exactly is the difference
from the previous version?


If you seek fast (hold the seek key pressed all the time) then you shouldn't
see such hard breaks.



2) If you delete all mpv settings except the input.conf you quoted,
does the problem reproduce?


Yes, see below. Instead using "j" I have to use ">" aka. AXIS_LEFT.



3) Does the problem play on any videos or any specific videos? If
the second, please give examples.


Some are a little better and some are worse. But in general, the patch has made
them worse. (Not an show stopper for me)



I don't care where I get feedback from you - by mail or on github
- whichever is more convenient for you. Thank you in advance.


I wasn't at the keyboard over the change of year. So I apologise for my late
reply.



There is nothing to apologize for, I understand everything and just
as you do not always have the opportunity to respond quickly.
It's okay. Thank you.



[*] : When seeking in some mp4 videos with hjkl, there were
messages like "[ffmpeg/video] h264: mmco: unref short failure"
in the mpv log, but it had no effect on smoothness of work, audio
and video synchronization or anything like that.


My test case, to be honest a bit harsh:

$ mpv The\ Future\ of\ Intelligence,\ Artificial\ and\ Natural\ \ \ _\ \ \ Ray\ 
Kurzweil\ \(USA\)\ .\ \[JbKNbMgRbJA\].webm
(+) Video --vid=1 (*) (vp9 1280x720 25.000fps)
(+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
AO: [sndio] 48000Hz stereo 2ch s16
VO: [gpu] 1280x720 yuv420p
AV: 00:22:01 / 01:02:57 (35%) A-V: -0.000

and hold pressed "j" key (j seek  2) and don't release the j key.

Tested with: yt-dlp https://www.youtube.com/watch?v=JbKNbMgRbJA
(multimedia/yle-dl)

All in all, it's not a big issue. I only use it when I want to "slide" through
the entire video.

Thanks for working and caring on the topic.

Rafael


Thanks for the answer and for the clarification, Rafael!

Unfortunately, I still can't reproduce the problem or don't fully
understand what the problem is.

I'll describe what I did:

1) Download https://www.youtube.com/watch?v=JbKNbMgRbJA
(cmd: yt-dlp -f "bestvideo+bestaudio" --no-sponsorblock \
--no-sponskrub --no-part --no-mtime --restrict-filenames -c -o \
"/home/noiseless/video/%(title)s-%(id)s.%(ext)s" \
"https://www.youtube.com/watch?v=JbKNbMgRbJA;)

2) Next, I built mpv 0.34.1 with the original patch from
@rozhuk-im (https://github.com/mpv-player/mpv/pull/8314) and tried
to reproduce the problem in the way you described. I have recorded
the result on video: https://disk.yandex.ru/i/DJyMJGBRwxeKqQ

3) Next I built mpv 0.34.1 with my patch
(https://github.com/mpv-player/mpv/pull/9298) and tried again to
reproduce the problem. I also recorded the result on video:
https://disk.yandex.ru/i/7mPvvNuEn1ZTGA

Unfortunately, I can't see a noticeable difference between the old
and new patch and I hope my videos demonstrate that.
To make it clear what's going on in the video, I first press and
hold down 'j' and move forward in the video. Then I release 'j' and
press 'k' and similarly move backward in the video. Then I press 'j'
again.
Towards the end of both screencasts I release 'j' and press ('j')
again N times, but not by holding, but at some random intervals.

Maybe it's about some settings in mpv.conf? For example, I have the
cache enabled. If I turn it off, though, I still don't see anything
like a freeze on 'seek 2', but it's like a couple of times moving
through the video worked a little worse than the last time.
That said, it's probably because my system isn't idle right now.
Anyway, I think it makes sense to check the included options in
mpv.conf.
My config:

$ cat ~/.config/mpv/config
cache=yes
demuxer-max-bytes=32768KiB
demuxer-readahead-secs=90

ao=sndio
audio-channels=2
vo=gpu

sub-codepage = utf-8

volume-max=200

Can you also record on video what your problem looks 

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 05:42:21

Modified files:
x11/gnome/autoar: Makefile distinfo 

Log message:
Update to gnome-autoar-0.4.2.

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2022/01/07 05:16:21

Modified files:
graphics/krita : Makefile distinfo 

Log message:
Update krita to 5.0.2

Re: wip/help wanted: fcitx5{,-gtk,-qt,-config-qt}

[Stuart Henderson]

On 2022/01/07 11:40, Yifei Zhan wrote:
> On 22/01/06 11:53AM, Stuart Henderson wrote:
> > > > Since fcitx5 is meant to be the successor for fcitx4 which is no 
> > > > longer developed, it may make sense to replace fcitx4 with 5 instead 
> > > > of keeping both in the port tree?  I'm not using either, so I'm 
> > > > probably missing something here.
> > > 
> > > I agree, if Kevin is ok with that we can drop fcitx4 once fcitx5 and its 
> > > plugins are tested and imported.
> > 
> > Wouldn't it make more sense to update the existing fcitx ports rather
> > than add new "fcitx5" ones?
> > 
> 
> I think it's better we keep both of them in our tree for a while so that:

We have found this approach doesn't usually work well in ports.

> 1. users get more time to migrate their config and plugins

Really it just shifts the point at which they have to migrate their config
and plugins from when the new version is added to whenever the old version
is removed. And in the meantime it makes it more complicated for users
as they have to decide which to use.

Unless somebody is actively following ports development they are
unlikely to see/test the new version. (And if they are actively
following ports development, they'll already have had a chance to test
pre-commit!)

> 2. if something is broken they can report the bug & fallback to stay on 
> fcitx4 until the bug is fixed.

Existing users won't find a bug until they upgrade. And with software
that is spread across multiple ports, that's a pain to do, if they even
notice that there are two alternative versions available.

Taking the other approach and replacing the existing ports: -current
users test things sooner, so there's more chance of any bugs being found
before the next OpenBSD release. They can also fallback by checking out
an older version of the relevant ports if needed.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 04:45:12

Modified files:
sysutils/awscli: Makefile distinfo 

Log message:
Update to awscli-1.22.30.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 04:44:56

Modified files:
net/py-boto3   : Makefile distinfo 

Log message:
Update to py3-boto3-1.20.30.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 04:44:43

Modified files:
net/py-botocore: Makefile distinfo 

Log message:
Update to py3-botocore-1.23.30.

Re: WIP: Solo-0.0.31

[Stuart Henderson]

On 2022/01/07 12:12, Gonzalo Rodriguez wrote:
> Hello,
> 
> This is a new port for the Solokeys cli "solo":
> 
> https://github.com/solokeys/solo-python
> https://solokeys.com/
> 
> Attached also 2 diffs for py-click and py-fido2 to make solo work, don't
> take them as real upgrades.

It would be nice to get elasticsearch-curator updated so click could
be updated for real, this is coming up with other ports too.
Any reason why you went for 7.1 rather than 7.1.2 of click?

Unfortunately py-fido2 is a can of worms. Updating py-fido2 means
yubikey-manager needs an update to 4.x. But yubikey-manager 4.x has some
fairly big changes and doesn't work with OpenBSD as-is.


> Index: Makefile
> ===
> RCS file: /cvs/ports/security/py-fido2/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- Makefile  2 Nov 2021 00:02:17 -   1.6
> +++ Makefile  6 Jan 2022 18:17:01 -
> @@ -8,14 +8,13 @@ COMMENT =   Python module to communicate 
>  # which in turn needs an update of py-click.
>  GH_ACCOUNT = Yubico
>  GH_PROJECT = python-fido2
> -GH_COMMIT =  46a0b649b9aa9af79566e6e3961021e070d98b1c
> +GH_COMMIT =  58471d4af1c09cc9fe316771d6203b4844cbc668
>  
> -MODPY_EGG_VERSION =  0.8.2.dev0
> +MODPY_EGG_VERSION =  0.9.3

this should use GH_TAGNAME=0.9.3 / MODPY_EGG_VERSION=${GH_TAGNAME} or
similar.

>  
>  #DISTNAME =  fido2-${MODPY_EGG_VERSION}
>  #PKGNAME =   py-${DISTNAME}
> -DISTNAME =   py-fido2-0.8.2pre20200313
> -REVISION =   1
> +DISTNAME =   py-fido2-0.9.3
>  
>  CATEGORIES = security
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/py-fido2/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo  23 May 2020 21:55:55 -  1.3
> +++ distinfo  6 Jan 2022 18:17:01 -
> @@ -1,2 +1,2 @@
> -SHA256 (py-fido2-0.8.2pre20200313-46a0b649.tar.gz) = 
> WH4RUQ6IOeruJ8Zp0iBIaI6buEPJmdvU8mPpXXhrPu4=
> -SIZE (py-fido2-0.8.2pre20200313-46a0b649.tar.gz) = 210085
> +SHA256 (py-fido2-0.9.3-58471d4a.tar.gz) = 
> IYt3dGb+Znm6esEtTQhIfU4Fjqd4yW7NU2n8/LjXylU=
> +SIZE (py-fido2-0.9.3-58471d4a.tar.gz) = 219249
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/security/py-fido2/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -r1.3 PLIST
> --- pkg/PLIST 23 May 2020 21:55:55 -  1.3
> +++ pkg/PLIST 6 Jan 2022 18:17:01 -
> @@ -1,25 +1,20 @@
>  @comment $OpenBSD: PLIST,v 1.3 2020/05/23 21:55:55 sthen Exp $
>  @pkgpath security/py-fido2
>  lib/python${MODPY_VERSION}/site-packages/fido2/
> -lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
> -lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
> -lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
> -lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
> -lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
> -lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
> +lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/
> +lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/PKG-INFO
> +lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/SOURCES.txt
> +lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/dependency_links.txt
> +lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/requires.txt
> +lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/top_level.txt
>  lib/python${MODPY_VERSION}/site-packages/fido2/__init__.py
>  
> ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}/
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
> -lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}_tpm.${MODPY_PYC_MAGIC_TAG}pyc
> -lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}attestation.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}cbor.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}client.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}cose.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}ctap.${MODPY_PYC_MAGIC_TAG}pyc
>  
> lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}ctap1.${MODPY_PYC_MAGIC_TAG}pyc
> 

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 04:27:27

Modified files:
security/yubico/yubikey-manager: Makefile 

Log message:
yubikey-manager: set max version in RDEP for py-fido2

WIP: Solo-0.0.31

[Gonzalo Rodriguez]

Hello,

This is a new port for the Solokeys cli "solo":

https://github.com/solokeys/solo-python
https://solokeys.com/

Attached also 2 diffs for py-click and py-fido2 to make solo work, don't 
take them as real upgrades.


Cheers.-

solo.tgz
Description: Binary data
Index: Makefile
===
RCS file: /cvs/ports/security/py-fido2/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile2 Nov 2021 00:02:17 -   1.6
+++ Makefile6 Jan 2022 18:17:01 -
@@ -8,14 +8,13 @@ COMMENT = Python module to communicate 
 # which in turn needs an update of py-click.
 GH_ACCOUNT =   Yubico
 GH_PROJECT =   python-fido2
-GH_COMMIT =46a0b649b9aa9af79566e6e3961021e070d98b1c
+GH_COMMIT =58471d4af1c09cc9fe316771d6203b4844cbc668
 
-MODPY_EGG_VERSION =0.8.2.dev0
+MODPY_EGG_VERSION =0.9.3
 
 #DISTNAME =fido2-${MODPY_EGG_VERSION}
 #PKGNAME = py-${DISTNAME}
-DISTNAME = py-fido2-0.8.2pre20200313
-REVISION = 1
+DISTNAME = py-fido2-0.9.3
 
 CATEGORIES =   security
 
Index: distinfo
===
RCS file: /cvs/ports/security/py-fido2/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo23 May 2020 21:55:55 -  1.3
+++ distinfo6 Jan 2022 18:17:01 -
@@ -1,2 +1,2 @@
-SHA256 (py-fido2-0.8.2pre20200313-46a0b649.tar.gz) = 
WH4RUQ6IOeruJ8Zp0iBIaI6buEPJmdvU8mPpXXhrPu4=
-SIZE (py-fido2-0.8.2pre20200313-46a0b649.tar.gz) = 210085
+SHA256 (py-fido2-0.9.3-58471d4a.tar.gz) = 
IYt3dGb+Znm6esEtTQhIfU4Fjqd4yW7NU2n8/LjXylU=
+SIZE (py-fido2-0.9.3-58471d4a.tar.gz) = 219249
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/py-fido2/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST   23 May 2020 21:55:55 -  1.3
+++ pkg/PLIST   6 Jan 2022 18:17:01 -
@@ -1,25 +1,20 @@
 @comment $OpenBSD: PLIST,v 1.3 2020/05/23 21:55:55 sthen Exp $
 @pkgpath security/py-fido2
 lib/python${MODPY_VERSION}/site-packages/fido2/
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
-lib/python${MODPY_VERSION}/site-packages/fido2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/PKG-INFO
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/SOURCES.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/requires.txt
+lib/python${MODPY_VERSION}/site-packages/fido2-0.9.4.dev0-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/fido2/__init__.py
 
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}_tpm.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}attestation.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}cbor.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}client.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}cose.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}ctap.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}ctap1.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}ctap2.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}extensions.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}hid.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}nfc.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}pcsc.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/fido2/${MODPY_PYCACHE}rpid.${MODPY_PYC_MAGIC_TAG}pyc
@@ -27,34 +22,61 @@ 

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 03:48:06

Modified files:
www/unit/unit-php: Makefile 

Log message:
unit-php: include php embed pseudo-flavour in RUN_DEPENDS
another attempt to get dpb to see it

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2022/01/07 03:35:58

Modified files:
devel/doxygen  : Makefile distinfo 
devel/doxygen/patches: patch-doc_CMakeLists_txt 
devel/doxygen-gui: Makefile distinfo 

Log message:
Update doxygen and doxygen-gui to 1.9.3

CVS: cvs.openbsd.org: ports

[Rafael Sadowski]

CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org   2022/01/07 03:36:03

Modified files:
graphics/libgphoto2: Makefile 
graphics/libgphoto2/pkg: PLIST 

Log message:
Regen PLIST after doxygen update to 1.9.3

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 03:03:43

Modified files:
archivers/libzip: Makefile 
archivers/libzip/pkg: PLIST 

Log message:
libzip: stop @comment'ing the cmake files. Dependent ports are now
happy with these, and with the last update a new cmake file was added
while the directories were @comment'ed, so pkg_delete * complained
about the extra dir. ok bcallah@

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 01:51:09

Modified files:
sysutils/amazon-ssm-agent: Makefile distinfo 
sysutils/amazon-ssm-agent/patches: 
   
patch-agent_appconfig_constants_unix_go 

Log message:
Update to amazon-ssm-agent-3.1.804.0.

CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2022/01/07 01:46:10

Modified files:
textproc/meld  : Makefile distinfo 
textproc/meld/pkg: PLIST 

Log message:
Update to meld-3.21.1.

Re: CVS: cvs.openbsd.org: ports

[Antoine Jacoutot]

On Thu, Dec 30, 2021 at 12:12:40PM -0700, Pascal Stumpf wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   pas...@cvs.openbsd.org  2021/12/30 12:12:40
> 
> Modified files:
>   multimedia/sfml: Makefile distinfo 
>   multimedia/sfml/patches: patch-cmake_Config_cmake 
>patch-src_SFML_Window_Unix_WindowImplX11_cpp 
>   multimedia/sfml/pkg: PLIST 
> Removed files:
>   multimedia/sfml/patches: patch-CMakeLists_txt 
>patch-cmake_Modules_FindSFML_cmake 
>patch-include_SFML_Config_hpp 
>patch-include_SFML_OpenGL_hpp 
>patch-include_SFML_Window_WindowHandle_hpp 
>patch-src_SFML_Window_CMakeLists_txt 
>patch-src_SFML_Window_GlContext_cpp 
>patch-src_SFML_Window_InputImpl_hpp 
>patch-src_SFML_Window_JoystickImpl_hpp 
>patch-src_SFML_Window_SensorImpl_hpp 
>patch-src_SFML_Window_Unix_GlxExtensions_hpp 
>patch-src_SFML_Window_WindowImpl_cpp 
> 
> Log message:
> Update to SFML 2.5.1.

This seems to have broken games/mars.

FAILED: /hack/objdirs/pobj/mars-0.7.5/mars-game/mars 
: && /hack/objdirs/pobj/mars-0.7.5/bin/c++ -O2 -pipe -DNDEBUG  
src/CMakeFiles/mars.dir/main.cpp.o 
src/CMakeFiles/mars.dir/Controllers/BotController.cpp.o 
src/CMakeFiles/mars.dir/Controllers/BotControllerBasicActions.cpp.o 
src/CMakeFiles/mars.dir/Controllers/BotControllerChecks.cpp.o 
src/CMakeFiles/mars.dir/Controllers/BotControllerDraw.cpp.o 
src/CMakeFiles/mars.dir/Controllers/BotControllerHelpers.cpp.o 
src/CMakeFiles/mars.dir/Controllers/BotControllerTeamActions.cpp.o 
src/CMakeFiles/mars.dir/Controllers/Controller.cpp.o 
src/CMakeFiles/mars.dir/Controllers/KeyController.cpp.o 
src/CMakeFiles/mars.dir/Controllers/controllers.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/Bolt.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/Cannon.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/Evil.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/PlanetSign.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/ShipHighlight.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/ShipName.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/SunHeat.cpp.o 
src/CMakeFiles/mars.dir/DecoObjects/decoObjects.cpp.o 
src/CMakeFiles/mars.dir/Games/CannonKeep.cpp.o 
src/CMakeFiles/mars.dir/Games/DeathMatch.cpp.o 
src/CMakeFiles/mars.dir/Games/Game.cpp.o 
src/CMakeFiles/mars.dir/Games/GraveItation.cpp.o 
src/CMakeFiles/mars.dir/Games/MenuGame.cpp.o 
src/CMakeFiles/mars.dir/Games/Rally.cpp.o 
src/CMakeFiles/mars.dir/Games/SpaceBall.cpp.o 
src/CMakeFiles/mars.dir/Games/TeamDeathMatch.cpp.o 
src/CMakeFiles/mars.dir/Games/Tutorial.cpp.o 
src/CMakeFiles/mars.dir/Games/games.cpp.o 
src/CMakeFiles/mars.dir/Hud/CountDown.cpp.o 
src/CMakeFiles/mars.dir/Hud/GamePoints.cpp.o 
src/CMakeFiles/mars.dir/Hud/GameStats.cpp.o 
src/CMakeFiles/mars.dir/Hud/LeftLife.cpp.o 
src/CMakeFiles/mars.dir/Hud/Logo.cpp.o 
src/CMakeFiles/mars.dir/Hud/Message.cpp.o 
src/CMakeFiles/mars.dir/Hud/RightLife.cpp.o 
src/CMakeFiles/mars.dir/Hud/TabStats.cpp.o 
src/CMakeFiles/mars.dir/Hud/hud.cpp.o 
src/CMakeFiles/mars.dir/Hud/musicNotify.cpp.o 
src/CMakeFiles/mars.dir/Interface/Button.cpp.o 
src/CMakeFiles/mars.dir/Interface/Checkbox.cpp.o 
src/CMakeFiles/mars.dir/Interface/ColorPicker.cpp.o 
src/CMakeFiles/mars.dir/Interface/ColorPickerWindow.cpp.o 
src/CMakeFiles/mars.dir/Interface/ComboBox.cpp.o 
src/CMakeFiles/mars.dir/Interface/DropDownWindow.cpp.o 
src/CMakeFiles/mars.dir/Interface/KeyEdit.cpp.o 
src/CMakeFiles/mars.dir/Interface/Label.cpp.o 
src/CMakeFiles/mars.dir/Interface/LabeledBox.cpp.o 
src/CMakeFiles/mars.dir/Interface/LanguageButton.cpp.o 
src/CMakeFiles/mars.dir/Interface/Line.cpp.o 
src/CMakeFiles/mars.dir/Interface/RadioButton.cpp.o 
src/CMakeFiles/mars.dir/Interface/RadioGroup.cpp.o 
src/CMakeFiles/mars.dir/Interface/ShipPreview.cpp.o 
src/CMakeFiles/mars.dir/Interface/Slider.cpp.o 
src/CMakeFiles/mars.dir/Interface/Tab.cpp.o 
src/CMakeFiles/mars.dir/Interface/TabList.cpp.o 
src/CMakeFiles/mars.dir/Interface/TextBox.cpp.o 
src/CMakeFiles/mars.dir/Interface/TextEdit.cpp.o 
src/CMakeFiles/mars.dir/Interface/UiElement.cpp.o 
src/CMakeFiles/mars.dir/Interface/UiWindow.cpp.o 
src/CMakeFiles/mars.dir/Interface/VerticalSlider.cpp.o 
src/CMakeFiles/mars.dir/Interface/toolTip.cpp.o 
src/CMakeFiles/mars.dir/Items/CannonControl.cpp.o 
src/CMakeFiles/mars.dir/Items/PUFuel.cpp.o 
src/CMakeFiles/mars.dir/Items/PUHealth.cpp.o 
src/CMakeFiles/mars.dir/Items/PUReverse.cpp.o 
src/CMakeFiles/mars.dir/Items/PUShield.cpp.o 
src/CMakeFiles/mars.dir/Items/PUSleep.cpp.o 
src/CMakeFiles/mars.dir/Items/PowerUp.cpp.o 
src/CMakeFiles/mars.dir/Items/items.cpp.o 
src/CMakeFiles/mars.dir/Locales/locales.cpp.o 
src/CMakeFiles/mars.dir/Media/announcer.cpp.o 

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 01:38:48

Modified files:
www/uriparser  : Tag: OPENBSD_7_0 Makefile distinfo 

Log message:
update to uriparser-0.9.6
CVE-2021-46141, CVE-2021-46142

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 01:34:21

Modified files:
www/uriparser  : Makefile distinfo 

Log message:
update to uriparser-0.9.6
CVE-2021-46141, CVE-2021-46142

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 01:29:15

Modified files:
www/composer   : Makefile distinfo 

Log message:
update to composer-2.2.3

CVS: cvs.openbsd.org: ports

[Stuart Henderson]

CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2022/01/07 01:28:16

Modified files:
textproc/py-pygments: Makefile distinfo 

Log message:
update to py3-pygments-2.11.2