Re: security/vpnc: dhclient -> ifconfig inet autoconf

[Florian Obser]

On 2024-07-12 03:05 -06, "Theo de Raadt"  wrote:
> Stuart Henderson  wrote:
>
>> This change won't work directly as the following lines currently need 
>> blocking until dhcp has fetched an address but I don't think it's worth it. 
>
> Right.
>
> We have entered a world where dynamic address negotiation is async.
> But then, it always was.
>

Independent of the port at hand (which indeed should be nuked from
orbit), dhcpcleasctl(8) has this:

 -w maxwait
 Specify the maximum number of seconds to wait for interface to be
 configured.  The default is 10 seconds.

so running "dhcpleasctl $IF" waits max 10 seconds.

-w is parsed thusly:
maxwait = strtonum(optarg, 1, INT_MAX, );

... in case there is something else that absolutely wants to wait until
a lease has been configured.

-- 
In my defence, I have been left unsupervised.

Re: nginx: imrpove compatibiliy with unwind

[Florian Obser]

On 2024-06-23 15:50 +02, Otto Moerbeek  wrote:
> On Sun, Jun 23, 2024 at 03:43:54PM +0200, Otto Moerbeek wrote:
>
>> It is possible to argue that it is correct in doing so, *if* it
>> didn't set the AD flag in the request
>
> or added the DO flag
>

I think the problem is that unwind is a bit too enthusiastic when it
manages to validate an answer. It will always set the AD flag in that
case, no matter if it was asked or not:

$ dig @::1 +qr +noadflag +nocmd ripe.net
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65381
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ripe.net.  IN  A

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65381
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ripe.net.  IN  A

;; ANSWER SECTION:
ripe.net.   193 IN  A   193.0.11.51

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sun Jun 23 16:08:48 CEST 2024
;; MSG SIZE  rcvd: 42

So there are valid reasons to ignore the SHOULD item: It was easier to
implement this way. But it seems like the "full implications" have not
been understood.

-- 
In my defence, I have been left unsupervised.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2024/06/19 10:12:00

Modified files:
sysutils/stow  : Makefile distinfo 
sysutils/stow/pkg: PLIST 

Log message:
update to stow 2.4.0 which should make --dotfiles usable.
OK maintainer
reads OK to sthen

update: stow 2.4.0

[Florian Obser]

I started to use stow to manage my dotfiles between my work laptop
(macOS) and OpenBSD machines. I started to use --dotfiles because
homebrew has 2.4.0 and I was not aware of problems.

stow 2.3.1 on OpenBSD got very confused by this, for example:

UNLINK: .config
MKDIR: .config
stow: ERROR: stow_contents() called with non-directory path: 
../dotfiles/OpenBSD/.config

that should be ../dotfiles/OpenBSD/dot-config.

In the end I decided against --dotfiles but I still have the update
lying around.

OK?

* Changes in version 2.4.0

*** --dotfiles now works with directories

A long-standing bug preventing the --dotfiles option from working
correctly with directories has been fixed.

It should also works in combination with the --compat option.

*** Eliminated a spurious warning on unstowing

2.3.1 introduced a benign but annoying warning when unstowing
in certain circumstances.  It looked like:

  BUG in find_stowed_path? Absolute/relative mismatch between Stow dir X 
and path Y

This was caused by erroneous logic, and has now been fixed.

*** Unstowing logic has been improved in other cases

Several other improvements have been made internally to the
unstowing logic.  These changes should all be either invisible
(except for changes to debug output) or improvements, but if you
encounter any unexpected behaviour, please report it as directed
in the manual.

*** Improved debug output

Extra output resulting from use of the -v / --verbose flag
now appears in a more logical and understandable way.

*** Janitorial tasks

Users are not substantially affected by these changes.

* Added some more information from the web page to the README

* Made some improvements to the documentation

* Improve readability of source code

  Quite a few extra details have been added in comments to clarify
  how the code works.  Many variable names have also been
  improved.  The comments of many Stow class methods have been
  converted into Perl POD format.

* Added a =CONTRIBUTING.md= file

* Add a =watch= target to =Makefile=

  =make watch= provides easy continual pre-processing during
  development, which reduces the risk of debugging the wrong code.

* Removed texinfo.tex from the distribution

  This eliminates existing and future bit-rot.

* Updated aclocal.m4 from 1.15.1 to 1.16.5

  This mostly just updates copyright notices to 2021, and URLs to https.

* Replace broken gmane links with links to lists.gnu.org

  
[[https://lars.ingebrigtsen.no/2020/01/06/whatever-happened-to-news-gmane-org/][gmane
 has been dead for quite a while.]]

* Improve support for navigating / editing source via emacs

*** Support source navigation in emacs via 
[[https://github.com/jacktasia/dumb-jump][dumb-jump]].

*** Configure cperl-mode to match existing coding style.

*** Various maintainer tweaks

Further improved the release process and its documentation in
various minor ways.


diff --git Makefile Makefile
index 0c91ffb91d8..59173083618 100644
--- Makefile
+++ Makefile
@@ -1,6 +1,6 @@
 COMMENT=   manages software package installations with symlinks
 
-DISTNAME=  stow-2.3.1
+DISTNAME=  stow-2.4.0
 CATEGORIES=sysutils
 
 HOMEPAGE=  https://www.gnu.org/software/stow/stow.html
diff --git distinfo distinfo
index 609c46fc574..36e7aa8e0db 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (stow-2.3.1.tar.gz) = CdXZlnG3hTf9mywLOaXpdhp6Dpefb9t+q/pY7kXwPUs=
-SIZE (stow-2.3.1.tar.gz) = 654191
+SHA256 (stow-2.4.0.tar.gz) = b+1nz2Teq209kVGkPiwGyVzfymqI+rfUFvRqZIsddh0=
+SIZE (stow-2.4.0.tar.gz) = 722098
diff --git pkg/PLIST pkg/PLIST
index e5c17b4bcf9..1bfba98f3e8 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -13,7 +13,7 @@ share/doc/stow/README.md
 share/doc/stow/manual-single.html
 share/doc/stow/manual-split/
 share/doc/stow/manual-split/Bootstrapping.html
-share/doc/stow/manual-split/Compile_002dtime-vs-Install_002dtime.html
+share/doc/stow/manual-split/Compile_002dtime-vs_002e-Install_002dtime.html
 share/doc/stow/manual-split/Conflicts.html
 share/doc/stow/manual-split/Cygnus-Software.html
 share/doc/stow/manual-split/Deferred-Operation.html
@@ -39,6 +39,7 @@ share/doc/stow/manual-split/Terminology.html
 share/doc/stow/manual-split/Tree-unfolding.html
 share/doc/stow/manual-split/Types-And-Syntax-Of-Ignore-Lists.html
 share/doc/stow/manual-split/index.html
+share/doc/stow/manual-split/symlink.html
 share/doc/stow/manual-split/tree-folding.html
 share/doc/stow/manual-split/tree-refolding.html
 share/doc/stow/manual.pdf

-- 
In my defence, I have been left unsupervised.

Re: NEW: math/rink

[Florian Obser]

On 2024-05-21 10:09 +01, Stuart Henderson  wrote:
> This seems quite a nice units-aware calculator. OK to import?

Looks neat.

While it knows about stone and seam, it sadly misses important derived
units like the assload (8 stone) and buttload (6 seams).

-- 
In my defence, I have been left unsupervised.

check_openbgpd: "when is deprecated"

[Florian Obser]

with the perl update I get this:

# /usr/local/libexec/nagios/check_openbgpd -c 10:25 -u
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 268.
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 272.
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 273.
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 274.
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 275.
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 276.
when is deprecated at /usr/local/libexec/nagios/check_openbgpd line 282.

I'm currently limping along thusly:

--- check_openbgpd~ Thu Dec  7 14:13:36 2023
+++ check_openbgpd  Wed May 15 13:44:09 2024
@@ -7,6 +7,7 @@
 
 use strict;
 use warnings;
+no warnings 'deprecated';

 use 5.010;
 use if $] >= 5.016, experimental => 'switch';

-- 
In my defence, I have been left unsupervised.

NEW: meta/kinderunix

[Florian Obser]

since this is a ports hackathon and I need to earn my keep...

cf. https://honk.tedunangst.com/u/tedu/h/wsYs143QST1fS2XlBY

Comments, OKs?

Information for inst:kinderunix-0.0.1

Comment:
meta-package for transitioning from linux

Description:
All the world is systemd/Linux.

Maintainer: The OpenBSD ports mailing-list 



kinderunix.tgz
Description: Binary data

-- 
In my defence, I have been left unsupervised.

Re: acme-client: add challenge hook to support dns-01

[Florian Obser]

On 2024-02-21 09:03 +01, Florian Obser  wrote:
> On 2024-02-20 22:32 +01, Christopher Zimmermann  wrote:
>> Hi,
>>
>> this diff adds a challenge hook to acme-client. This hook can be used
>> to fulfill challenges. For example by putting the requested files onto
>> a remote http server (http-01 challenge) or by modifying dns records
>> (dns-01 challenge). The latter are needed to obtain wildcard
>> certificates.
>> Is this diff ok? Is the design of the hook interface sane? Any
>> feedback is welcome.
>>
>
> I'm not convinced passing random crap coming from the internet to a
> shell script running as root is a good idea.
>

btw. a few years back I came up with this:

https://marc.info/?l=openbsd-tech=160883000402270=2

I still have the diff lying around somewhere.

I have no recollection if it's actually better.

But looking at the email some things stick out:

| I implemented the uacme api since I find that less ugly. It should be
| trivial to transmogrify it with a shell one-liner to support
| dehydrated.

that kinda seems sensible.

And than this:

+.It Ic exec Ar script Ic as Ar user
+Run
+.Ar script
+as user
+.Ar user
+for each
+.Cm dns
+challenge.
+This is required when using the
+.Cm dns
+challenge type.


However, one stated requirement at the time was that the dns-01
challenge must work with base tools out of the box, i.e. nsd(8). I have
no idea how one would do that. So I dropped the diff and figured out how
to avoid wildcard certs.

The only annoying bit is that I have some servers that run httpd(8) that
wouldn't strictly need to *shrug*

>>
>> Christopher
>>
>>
>
> -- 
> In my defence, I have been left unsupervised.
>

-- 
In my defence, I have been left unsupervised.

Re: acme-client: add challenge hook to support dns-01

[Florian Obser]

On 2024-02-20 22:32 +01, Christopher Zimmermann  wrote:
> Hi,
>
> this diff adds a challenge hook to acme-client. This hook can be used
> to fulfill challenges. For example by putting the requested files onto
> a remote http server (http-01 challenge) or by modifying dns records
> (dns-01 challenge). The latter are needed to obtain wildcard
> certificates.
> Is this diff ok? Is the design of the hook interface sane? Any
> feedback is welcome.
>

I'm not convinced passing random crap coming from the internet to a
shell script running as root is a good idea.

>
> Christopher
>
>

-- 
In my defence, I have been left unsupervised.

py3-netaddr-1.0.0 breaks ansible.utils.ipaddr('public')

[Florian Obser]

thusly:

An exception occurred during task execution. To see the full traceback, use 
-vvv. The error was: AttributeError: 'IPAddress' object has no attribute 
'is_private'

See also: https://github.com/ansible-collections/ansible.utils/issues/331

This fixes it for me for now, but I didn't have the time to give it both
buttocks, so pretty much half-arsed.

diff --git sysutils/ansible/Makefile sysutils/ansible/Makefile
index 25f922d3ab4..64da78d9e52 100644
--- sysutils/ansible/Makefile
+++ sysutils/ansible/Makefile
@@ -1,6 +1,7 @@
 COMMENT =  radically simple IT automation
 
 MODPY_EGG_VERSION =9.2.0
+REVISION = 0
 DISTNAME = ansible-${MODPY_EGG_VERSION}
 
 CATEGORIES =   sysutils
diff --git 
sysutils/ansible/patches/patch-ansible_collections_ansible_utils_plugins_plugin_utils_base_ipaddr_utils_py
 
sysutils/ansible/patches/patch-ansible_collections_ansible_utils_plugins_plugin_utils_base_ipaddr_utils_py
new file mode 100644
index 000..77756e1aa94
--- /dev/null
+++ 
sysutils/ansible/patches/patch-ansible_collections_ansible_utils_plugins_plugin_utils_base_ipaddr_utils_py
@@ -0,0 +1,22 @@
+'IPAddress' object has no attribute 'is_private' in netaddr >= 1.0.0
+Index: 
ansible_collections/ansible/utils/plugins/plugin_utils/base/ipaddr_utils.py
+--- 
ansible_collections/ansible/utils/plugins/plugin_utils/base/ipaddr_utils.py.orig
 ansible_collections/ansible/utils/plugins/plugin_utils/base/ipaddr_utils.py
+@@ -289,7 +289,7 @@ def _previous_usable_query(v, vtype):
+ 
+ 
+ def _private_query(v, value):
+-if v.is_private():
++if not v.is_global():
+ return value
+ 
+ 
+@@ -298,7 +298,7 @@ def _public_query(v, value):
+ if all(
+ [
+ v_ip.is_unicast(),
+-not v_ip.is_private(),
++v_ip.is_global(),
+ not v_ip.is_loopback(),
+ not v_ip.is_netmask(),
+ not v_ip.is_hostmask(),

-- 
In my defence, I have been left unsupervised.

Re: dnscrypt-proxy: Unable to set the close on exec flag: [function not implemented]

[Florian Obser]

On 2024-01-03 17:14 +01, Florian Obser  wrote:
> Hi there,
>
> dnscrypt-proxy fails thusly on -current:
>
> Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: dnscrypt-proxy 2.1.5
> Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: Network connectivity detected
> Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: Dropping privileges
> Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: Unable to set the close on exec 
> flag: [function not implemented]
>

So I've solved this by installing dnsdist instead.

Since unwind(8) can't natively speak DoH and there are sometimes
networks that try really hard to filter DNS put let through tcp/443 I
need a thing that speaks Do53 as a server and forwards queries to quad9
DoH. dnsdist does this just fine.

-- 
In my defence, I have been left unsupervised.

Re: tweak pkg_* footgun messages

[Florian Obser]

On 2024-01-13 18:16 +01, Peter Hessler  wrote:
> This change doesn't make a difference.  End-Users aren't going to care
> about the difference between "should" and "may".  They're just going to
> run it regardless.

I don't think so. People don't read, we know this.

RFC 6919 seems relevant though:

6.  MAY WISH TO

   The phrase "MAY WISH TO" indicates a behavior that might seem
   appealing to some people, but which is regarded as ridiculous or
   unnecessary by others.

>
> The problem is that they are being printed during upgrades, when the
> messages are only useful when the package is removed.
>
>
>
> On 2024 Jan 13 (Sat) at 17:06:18 + (+), Klemens Nanni wrote:
> : syncthing-1.27.1->1.27.2: ok
> : Read shared items: ok
> : --- -syncthing-1.27.1 ---
> : You should also run rm -rf /var/syncthing/{.,}*
> :
> :I shall certainly not wipe that directory...
> :
> :Apparently fixing this for good is more involved, but rewording is easy,
> :so perhaps this reads better?
> :
> : You may also run rm -rf /var/syncthing/{.,}*
> :
> :It's not great, but relaxing 'must' into 'may' feels more appropiate.
> :
> :Thoughts?
> :
> :Index: OpenBSD/Delete.pm
> :===
> :RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/Delete.pm,v
> :diff -u -p -r1.169 Delete.pm
> :--- OpenBSD/Delete.pm11 Oct 2023 13:54:43 -  1.169
> :+++ OpenBSD/Delete.pm13 Jan 2024 16:57:26 -
> :@@ -527,7 +527,7 @@ sub delete($self, $state)
> : if ($state->{quick} && $state->{quick} >= 2) {
> : unless ($state->{extra}) {
> : $self->mark_dir($state);
> :-$state->log("You should also #1 #2", $action, $realname 
> );
> :+$state->log("You may also #1 #2", $action, $realname );
> : return;
> : }
> : } else {
> :@@ -537,7 +537,7 @@ sub delete($self, $state)
> : } else {
> : unless ($state->{extra}) {
> : $self->mark_dir($state);
> :-$state->log("You should also #1 #2 (which was 
> modified)", $action, $realname);
> :+$state->log("You may also #1 #2 (which was 
> modified)", $action, $realname);
> : return;
> : }
> : }
> :@@ -607,7 +607,7 @@ sub delete($self, $state)
> : unlink($realname) or
> : $state->say("problem deleting extra file #1: #2", 
> $realname, $!);
> : } else {
> :-$state->log("You should also remove #1", $realname);
> :+$state->log("You may also remove #1", $realname);
> : $self->mark_dir($state);
> : }
> : }
> :@@ -622,7 +622,7 @@ sub delete($self, $state)
> : if ($state->{extra}) {
> : $self->SUPER::delete($state);
> : } else {
> :-$state->log("You should also remove the directory #1", 
> $realname);
> :+$state->log("You may also remove the directory #1", $realname);
> : $self->mark_dir($state);
> : }
> : }
> :@@ -634,7 +634,7 @@ sub delete($self, $state)
> : if ($state->{extra}) {
> : $self->run($state);
> : } else {
> :-$state->log("You should also run #1", $self->{expanded});
> :+$state->log("You may also run #1", $self->{expanded});
> : }
> : }
> : 
> :Index: OpenBSD/SharedItems.pm
> :===
> :RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/SharedItems.pm,v
> :diff -u -p -r1.34 SharedItems.pm
> :--- OpenBSD/SharedItems.pm   13 Jun 2023 09:07:17 -  1.34
> :+++ OpenBSD/SharedItems.pm   13 Jan 2024 16:58:03 -
> :@@ -110,7 +110,7 @@ sub cleanup($recorder, $state)
> : $user);
> : } else {
> : $state->log->set_context('-'.$pkgname);
> :-$state->log("You should also run /usr/sbin/userdel #1", 
> $user);
> :+$state->log("You may also run /usr/sbin/userdel #1", 
> $user);
> : }
> : $done++;
> : }
> :@@ -122,7 +122,7 @@ sub cleanup($recorder, $state)
> : $group);
> : } else {
> : $state->log->set_context('-'.$pkgname);
> :-$state->log("You should also run /usr/sbin/groupdel 
> #1", $group);
> :+$state->log("You may also run /usr/sbin/groupdel #1", 
> $group);
> : }
> : $done++;
> : }
> :
>
> -- 
> At no time is freedom of speech more precious than when a man hits his
> thumb with a hammer.
>   -- Marshall Lumsden
>

-- 
In my defence, I have been left unsupervised.

dnscrypt-proxy: Unable to set the close on exec flag: [function not implemented]

[Florian Obser]

Hi there,

dnscrypt-proxy fails thusly on -current:

Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: dnscrypt-proxy 2.1.5
Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: Network connectivity detected
Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: Dropping privileges
Jan  3 17:07:29 x395 dnscrypt-proxy[54029]: Unable to set the close on exec 
flag: [function not implemented]


-- 
In my defence, I have been left unsupervised.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/11/26 23:45:21

Modified files:
net/gelatod: Makefile distinfo 

Log message:
Update to 1.5
OK kn

gelatod 1.5

[Florian Obser]

I've just released 1.5.

Bug Fixes
* struct nd_opt_pref64 only contains the top 96 bits of an IPv6 address, make 
sure to only copy those.
Misc Changes
* guard against re-defining ND_OPT_PREF64 and struct nd_opt_pref64

OK?

diff --git Makefile Makefile
index c432bd2011e..401f3fbc3c4 100644
--- Makefile
+++ Makefile
@@ -1,5 +1,5 @@
 COMMENT =  CLAT configuration daemon for OpenBSD
-V =1.4
+V =1.5
 DISTNAME = gelatod-${V}
 CATEGORIES =   net
 
diff --git distinfo distinfo
index ab8e079bb0e..943c25acf99 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (gelatod-1.4.tar.gz) = rEDK/WDEj5s4OKr8vCEwJPcZy/36nczzm5iBjx9n/Go=
-SIZE (gelatod-1.4.tar.gz) = 17376
+SHA256 (gelatod-1.5.tar.gz) = GfBdte80d0QG79xmfdI3szQ4ljA6GUWF9XWl5faZfvE=
+SIZE (gelatod-1.5.tar.gz) = 17966


-- 
In my defence, I have been left unsupervised.

check_smtp with -D busted in 2.3.5

[Florian Obser]

monitoring-plugins-2.3.3p0:
$ /usr/local/libexec/nagios/check_smtp -D "20 10" -H 
2001:19f0:6c00:8501:5400:ff:fe04:3f -S
OK - Certificate 'mx.xa23.de' will expire on Sun May  5 21:59:00 2024 +.

monitoring-plugins-2.3.5:
$ /usr/local/libexec/nagios/check_smtp -D "20 10" -H 
2001:19f0:6c00:8501:5400:ff:fe04:3f -S
check_smtp: Set either -s/--ssl/--tls or -S/--starttls
Usage:
check_smtp -H host [-p port] [-4|-6] [-e expect] [-C command] [-R response] [-f 
from addr]
[-A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-q]
[-F fqdn] [-S] [-L] [-D warn days cert expire[,crit days cert expire]] [-r] 
[--sni] [-v]

I have not found an incantation that makes it go again. '-s' stops
complaining, but it doesn't check certificate validity. In fact I;m not
even sure it checks TLS at all.

-- 
In my defence, I have been left unsupervised.

Re: fonts/iosevka-fonts: fix packaging of slab variant

[Florian Obser]

I see this already went in. Thanks for fixing this up.
-- 
In my defence, I have been left unsupervised.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/09/04 09:15:47

Modified files:
textproc   : Makefile 

Log message:
Hook up riff.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/09/04 09:13:43

Log message:
Import riff, diff tool highlighting changes.

Handholding solene@; OK sthen@, kn@

Status:

Vendor Tag: florian
Release Tags:   florian_20230904

N ports/textproc/riff/Makefile
N ports/textproc/riff/distinfo
N ports/textproc/riff/crates.inc
N ports/textproc/riff/pkg/DESCR
N ports/textproc/riff/pkg/PLIST

No conflicts created by this import

NEW: riff

[Florian Obser]

Information for inst:riff-2.25.2

Comment:
diff tool highlighting which parts of lines have changed

Description:
Riff is a wrapper around diff that highlights which parts of lines
have changed.

Thanks to solene@ for getting me out of the weeds and explaining how
porting rust stuff actually works. All the good stuff is her doing, all
the mistakes are on me.

OK to import? Further clue-bats? (Remember, I'm just an animal smashing
stones together...)



riff.tgz
Description: Binary data
-- 
In my defence, I have been left unsupervised.

Re: move gelatod to codeberg

[Florian Obser]

Thanks, this is in know.

How long should I leave the github repo in place? Do bulk builders care?
This is also not the most important package in the world...

-- 
In my defence, I have been left unsupervised.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/09/03 06:05:04

Modified files:
net/gelatod: Makefile 

Log message:
Move to codeberg.
OK kn, jca

move gelatod to codeberg

[Florian Obser]

I've moved gelatod to https://codeberg.org/fobser/gelatod

GitHub thinks I'm a supplier and it's one me to fix software supply
chain issues[1]. Uh huh, no.

OK? (as far as I know I don't need to bump revision for this)

diff --git net/gelatod/Makefile net/gelatod/Makefile
index 25b1fa41fbe..2563c62e228 100644
--- net/gelatod/Makefile
+++ net/gelatod/Makefile
@@ -6,7 +6,7 @@ CATEGORIES =net
 # BSD 2-clause
 PERMIT_PACKAGE =   Yes
 
-MASTER_SITES = 
https://github.com/fobser/gelatod/releases/download/v${V}/
+MASTER_SITES = 
https://codeberg.org/fobser/gelatod/releases/download/v${V}/
 
 MAINTAINER =   Klemens Nanni 
 


[1] 
https://github.blog/2022-05-04-software-security-starts-with-the-developer-securing-developer-accounts-with-2fa/
-- 
In my defence, I have been left unsupervised.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/08/08 05:01:13

Modified files:
fonts/iosevka-fonts: Makefile 
Added files:
fonts/iosevka-fonts/fixed-slab: Makefile distinfo 
fonts/iosevka-fonts/fixed-slab/pkg: DESCR PLIST 

Log message:
Add fixed slab variant of iosevka font.

It has some serifs and no ligatures.
Easy on the eyes and compact.
Input & OK edd

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/08/08 04:58:41

ports/fonts/iosevka-fonts/fixed-slab/pkg

Update of /cvs/ports/fonts/iosevka-fonts/fixed-slab/pkg
In directory cvs.openbsd.org:/tmp/cvs-serv50785/fixed-slab/pkg

Log Message:
Directory /cvs/ports/fonts/iosevka-fonts/fixed-slab/pkg added to the repository

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/08/08 04:58:20

ports/fonts/iosevka-fonts/fixed-slab

Update of /cvs/ports/fonts/iosevka-fonts/fixed-slab
In directory cvs.openbsd.org:/tmp/cvs-serv40466/fixed-slab

Log Message:
Directory /cvs/ports/fonts/iosevka-fonts/fixed-slab added to the repository

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/08/08 04:57:32

Modified files:
fonts/iosevka-fonts: Makefile.inc 
fonts/iosevka-fonts/default: distinfo 

Log message:
update to 26.0.1; OK edd

Re: fixed-slab variant for iosevka font

[Florian Obser]

On 2023-08-06 17:23 -04, Morgan Aldridge  wrote:
> On Sun, Aug 6, 2023 at 4:46 PM Edd Barrett  wrote:
>
>> On Sun, Aug 06, 2023 at 09:40:18PM +0100, Edd Barrett wrote:
>> > Hi,
>> >
>> > On Sun, Aug 06, 2023 at 05:02:59PM +0200, Florian Obser wrote:
>> > > I recently discovered the iosevka font and I like the Fixed Slab
>> variant
>> > > best.
>> >
>> > First, can I check that "fixed slab" is correct and not just "slab".
>>
>> Arch has a "slab" package, but not a "fixed slab" package:
>> https://archlinux.org/packages/?q=ttc-iosevka
>>
>> Same for fedora:
>> https://copr.fedorainfracloud.org/coprs/peterwu/iosevka/packages/
>>
>> Same for FreeBSD:
>> https://cgit.freebsd.org/ports/tree/x11-fonts/iosevka/Makefile
>>
>> So is slab and fixed-slab the same thing, or?
>>

No, as Morgan explained:

>
> I haven't tested yet, but according to the Iosevka website <
> https://typeof.net/Iosevka/>:
>
> "Terminal emulators have stricter compatibility requirements for fonts.
> Therefore, Iosevka and Iosevka Slab all contain two specialized families,
> Term and Fixed, targeting terminal users.
>
> In these families, the symbols will be narrower to follow terminals’
> ideology of column count. In the Fixed families, the ligation will be
> disabled to ensure better compatibility in certain environments."
>
> So, it might be preferable for this to install both the "term" & "fixed"
> families of Iosevka Slab. Doing so would probably necessitate renaming the
> package to "iosevka-slab" though.

I have no need for ligatures, that's why I went with fixed.

I'm not sure what FreeBSD packages precisely but I suspect it's the
non-fixed / non-term variant.

https://typeof.net/Iosevka/ has a nice overview table about 10% down on
the page.

Upstream currently has 458 assets listed, it's all over the place.

The way the port is currently setup these would all be different ports:

iosevka-slab
iosevka-fixed
iosevka-fixed-slab
iosevka-term
iosevka-term-fixed

I did one port, because that's the one I need.

>
> Morgan

Fixed comment and description:

commit a2587e7df8a07f2a307c74d83c9dcf2c2623b25e
Author: Florian Obser 
Date:   Sun Aug 6 16:56:36 2023 +0200

update to 26.0.1

diff --git Makefile.inc Makefile.inc
index e02a6f941a9..3358c967f4e 100644
--- Makefile.inc
+++ Makefile.inc
@@ -1,4 +1,4 @@
-V =19.0.1
+V =26.0.1
 CATEGORIES =   fonts x11
 HOMEPAGE = https://github.com/be5invis/Iosevka
 MAINTAINER =   Edd Barrett 
diff --git default/distinfo default/distinfo
index ce9fb8e38ca..48224555407 100644
--- default/distinfo
+++ default/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ttc-iosevka-19.0.1.zip) = dQ2QR33PZ/PBZ7Eu/7YApnCPA+LmJMw4Z00MyeIb5kA=
-SIZE (ttc-iosevka-19.0.1.zip) = 75570917
+SHA256 (ttc-iosevka-26.0.1.zip) = 3h7aeMHkbsTRbbarNkcHT9Ej/o9E9s8XPCb2rdFRImc=
+SIZE (ttc-iosevka-26.0.1.zip) = 97568862

commit ea86fdbae98f91347d0409f377ccf060cd88c597
Author: Florian Obser 
Date:   Sun Aug 6 16:59:14 2023 +0200

fixed slab variant

diff --git Makefile Makefile
index ac190583d83..b4550370196 100644
--- Makefile
+++ Makefile
@@ -14,5 +14,6 @@
 
 SUBDIR =
 SUBDIR += default
+SUBDIR += fixed-slab
 
 .include 
diff --git fixed-slab/Makefile fixed-slab/Makefile
new file mode 100644
index 000..b61982a38b9
--- /dev/null
+++ fixed-slab/Makefile
@@ -0,0 +1,9 @@
+COMMENT =  slender typeface for code (fixed slab variant)
+PKGNAME =  iosevka-fixed-slab-${V}
+DISTFILES =ttc-sgr-iosevka-fixed-slab-${V}${EXTRACT_SUFX}
+
+do-install:
+   ${INSTALL_DATA_DIR} ${FONTDIR}
+   ${INSTALL_DATA} ${WRKDIST}/*.ttc ${FONTDIR}
+
+.include 
diff --git fixed-slab/distinfo fixed-slab/distinfo
new file mode 100644
index 000..405a598b40a
--- /dev/null
+++ fixed-slab/distinfo
@@ -0,0 +1,2 @@
+SHA256 (ttc-sgr-iosevka-fixed-slab-26.0.1.zip) = 
cqEnSt1I3xyacxTjZUCEmo8M7KFw7MudTY7D7D5UnQM=
+SIZE (ttc-sgr-iosevka-fixed-slab-26.0.1.zip) = 93695504
diff --git fixed-slab/pkg/DESCR fixed-slab/pkg/DESCR
new file mode 100644
index 000..38c61002954
--- /dev/null
+++ fixed-slab/pkg/DESCR
@@ -0,0 +1,3 @@
+Coders' typeface, built from code.
+
+This package is for the fixed slab variant.
diff --git fixed-slab/pkg/PLIST fixed-slab/pkg/PLIST
new file mode 100644
index 000..d0073b0c22f
--- /dev/null
+++ fixed-slab/pkg/PLIST
@@ -0,0 +1,11 @@
+share/fonts/
+@fontdir share/fonts/iosevka/
+share/fonts/iosevka/sgr-iosevka-fixed-slab-bold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-extrabold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-extralight.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-heavy.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-light.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-medium.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-regular.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-semibold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-thin.ttc


-- 
In my defence, I have been left unsupervised.

fixed-slab variant for iosevka font

[Florian Obser]

I recently discovered the iosevka font and I like the Fixed Slab variant
best.

This adds a new package and while here updates the font to 26.0.1.

Tests, OKs?

commit a2587e7df8a07f2a307c74d83c9dcf2c2623b25e
Author: Florian Obser 
Date:   Sun Aug 6 16:56:36 2023 +0200

update to 26.0.1

diff --git Makefile.inc Makefile.inc
index e02a6f941a9..3358c967f4e 100644
--- Makefile.inc
+++ Makefile.inc
@@ -1,4 +1,4 @@
-V =19.0.1
+V =26.0.1
 CATEGORIES =   fonts x11
 HOMEPAGE = https://github.com/be5invis/Iosevka
 MAINTAINER =   Edd Barrett 
diff --git default/distinfo default/distinfo
index ce9fb8e38ca..48224555407 100644
--- default/distinfo
+++ default/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ttc-iosevka-19.0.1.zip) = dQ2QR33PZ/PBZ7Eu/7YApnCPA+LmJMw4Z00MyeIb5kA=
-SIZE (ttc-iosevka-19.0.1.zip) = 75570917
+SHA256 (ttc-iosevka-26.0.1.zip) = 3h7aeMHkbsTRbbarNkcHT9Ej/o9E9s8XPCb2rdFRImc=
+SIZE (ttc-iosevka-26.0.1.zip) = 97568862

commit 881de1baf78757642cba9b0365bee0fc8285f13d
Author: Florian Obser 
Date:   Sun Aug 6 16:59:14 2023 +0200

fixed slab variant

diff --git Makefile Makefile
index ac190583d83..b4550370196 100644
--- Makefile
+++ Makefile
@@ -14,5 +14,6 @@
 
 SUBDIR =
 SUBDIR += default
+SUBDIR += fixed-slab
 
 .include 
diff --git fixed-slab/Makefile fixed-slab/Makefile
new file mode 100644
index 000..9ef10a2b549
--- /dev/null
+++ fixed-slab/Makefile
@@ -0,0 +1,9 @@
+COMMENT =  slender typeface for code (default variant)
+PKGNAME =  iosevka-fixed-slab-${V}
+DISTFILES =ttc-sgr-iosevka-fixed-slab-${V}${EXTRACT_SUFX}
+
+do-install:
+   ${INSTALL_DATA_DIR} ${FONTDIR}
+   ${INSTALL_DATA} ${WRKDIST}/*.ttc ${FONTDIR}
+
+.include 
diff --git fixed-slab/distinfo fixed-slab/distinfo
new file mode 100644
index 000..405a598b40a
--- /dev/null
+++ fixed-slab/distinfo
@@ -0,0 +1,2 @@
+SHA256 (ttc-sgr-iosevka-fixed-slab-26.0.1.zip) = 
cqEnSt1I3xyacxTjZUCEmo8M7KFw7MudTY7D7D5UnQM=
+SIZE (ttc-sgr-iosevka-fixed-slab-26.0.1.zip) = 93695504
diff --git fixed-slab/pkg/DESCR fixed-slab/pkg/DESCR
new file mode 100644
index 000..a6ea6f42f32
--- /dev/null
+++ fixed-slab/pkg/DESCR
@@ -0,0 +1,3 @@
+Coders' typeface, built from code.
+
+This package is for the slab variant.
diff --git fixed-slab/pkg/PLIST fixed-slab/pkg/PLIST
new file mode 100644
index 000..d0073b0c22f
--- /dev/null
+++ fixed-slab/pkg/PLIST
@@ -0,0 +1,11 @@
+share/fonts/
+@fontdir share/fonts/iosevka/
+share/fonts/iosevka/sgr-iosevka-fixed-slab-bold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-extrabold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-extralight.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-heavy.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-light.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-medium.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-regular.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-semibold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-thin.ttc


-- 
In my defence, I have been left unsupervised.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2023/07/25 04:15:04

Modified files:
net/toot   : Makefile distinfo 
net/toot/pkg   : PLIST 

Log message:
update to 0.38.1

OK sthen

update toot to 0.38.1

[Florian Obser]

I want to use toot to backup my mute and block lists from cron so I
contributed code upstream. It landed in 0.38.

I've not used toot before, tests from people who actually use it would
be appreciated.

Also I'm just smashing stones together here like an animal, I've no idea
if the diff is correct. It generates a working package though...

Tests, hand holding, OKs?

diff --git Makefile Makefile
index eb0cc6c6702..9c3077c93cb 100644
--- Makefile
+++ Makefile
@@ -1,6 +1,6 @@
 COMMENT =  CLI and TUI tool to interact with Mastodon instances
 
-MODPY_EGG_VERSION =0.36.0
+MODPY_EGG_VERSION =0.38.1
 DISTNAME = toot-${MODPY_EGG_VERSION}
 
 CATEGORIES =   net
@@ -22,7 +22,8 @@ MODPY_PYTEST_ARGS =   --ignore tests/test_integration.py
 RUN_DEPENDS =  devel/py-wcwidth${MODPY_FLAVOR} \
www/py-beautifulsoup4${MODPY_FLAVOR} \
www/py-requests${MODPY_FLAVOR} \
-   devel/py-urwid${MODPY_FLAVOR}
+   devel/py-urwid${MODPY_FLAVOR} \
+   textproc/py-tomlkit${MODPY_FLAVOR}
 TEST_DEPENDS = devel/py-test-cov${MODPY_FLAVOR}
 
 MAKE_ENV = LC_CTYPE=C.UTF-8
diff --git distinfo distinfo
index 3fb08220da3..c1be292334f 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (toot-0.36.0.tar.gz) = ivXz5Vr4oOdkuy13ONc3sWhVZH5Lx5R1F8zeOTKX6dg=
-SIZE (toot-0.36.0.tar.gz) = 354577
+SHA256 (toot-0.38.1.tar.gz) = vp5UeaIeqPsTz3upjVQtquB/2H+1ayC4kjtp/6UhxrI=
+SIZE (toot-0.38.1.tar.gz) = 312495
diff --git pkg/PLIST pkg/PLIST
index 88484ae0c34..18d00c9221b 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -8,9 +8,12 @@ 
lib/python${MODPY_VERSION}/site-packages/toot-${MODPY_EGG_VERSION}.dist-info/WHE
 
lib/python${MODPY_VERSION}/site-packages/toot-${MODPY_EGG_VERSION}.dist-info/entry_points.txt
 
lib/python${MODPY_VERSION}/site-packages/toot-${MODPY_EGG_VERSION}.dist-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/toot/__init__.py
+lib/python${MODPY_VERSION}/site-packages/toot/__main__.py
 ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}api.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}api.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}auth.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -21,6 +24,8 @@ 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}config.${MODPY_PYC
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}config.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}console.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}console.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}entities.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}entities.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}http.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -29,6 +34,10 @@ 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}logging.${MODPY_PY
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}logging.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}output.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}output.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}settings.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}settings.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}typing_compat.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}typing_compat.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}wcstring.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/toot/${MODPY_PYCACHE}wcstring.${MODPY_PYC_MAGIC_TAG}pyc
 lib/python${MODPY_VERSION}/site-packages/toot/api.py
@@ -36,10 +45,12 @@ 

Re: Nextcloud upgrade path

[Florian Obser]

On 2023-06-08 16:31 +02, Giovanni Bechis  wrote:
> Hi,
> I have a Nextcloud 23.x instance running on OpenBSD 7.3.
> pkg_add(1) suggests to upgrade to 24.x and then to 25.x before next release.
>
> $ doas pkg_add -ui
> [...]
> --- +nextcloud-23.0.12p1 ---
> Nextcloud 23 is EOL upstream, it is advised to update your installation
> to 24 then to 25 to make sure you're on a supported branch by the time
> OpenBSD 7.4 is released.
> $ doas pkg_add -i nextcloud
> quirks-6.121 signed on 2023-06-08T09:49:46Z
> Ambiguous: choose package for nextcloud
> a   0: 
> 1: nextcloud-23.0.12p1
> 2: nextcloud-24.0.12
> 3: nextcloud-25.0.6
> Your choice: 2
> Can't install nextcloud-24.0.12 because of conflicts (nextcloud-23.0.12p1)
> --- nextcloud-24.0.12 ---
> Can't install nextcloud-24.0.12: conflicts
> Couldn't install nextcloud-24.0.12

The correct incantation is
$ doas pkg_add -r nextcloud

No, I don't know why either.

>
> How should a user upgrade (some info on current.html are needed imho) ?
> Can't we add pkgpath entries in order to correctly upgrade between nextcloud 
> versions ?
>
>  Cheers
>   Giovanni
>

-- 
In my defence, I have been left unsupervised.

Re: NEW: IntelOne Mono font

[Florian Obser]

On 2023-06-07 03:02 -06, "Anthony J. Bentley"  wrote:
> Someone reminded me I forgot to actually send this out. Here it is.
> I didn't bother adding the extra bits to fetch and install the license,
> because as with most fonts, the license information is embedded in both
> the OTF and TTF metadata, as can be verified with lcdf-typetools
> (otfinfo -V).
>
> ok?

works for me, OK florian FWIW

>
> -- 
> Anthony J. Bentley
>
>

-- 
In my defence, I have been left unsupervised.

Re: [update] sysutils/grafana to 9.5.1

[Florian Obser]

OK florian fwiw

On 2023-05-27 20:08 UTC, Lucas Raab  wrote:
> On Fri, May 26, 2023 at 11:51:31AM +0200, Florian Obser wrote:
>> On 2023-05-18 02:45 UTC, Lucas Raab  wrote:
>> > On Thu, Apr 27, 2023 at 09:20:11AM +, Lucas Raab wrote:
>> >> Hello,
>> >> 
>> >> Here's an update for grafana to 9.5.1. I've run a couple 9.4.* releases
>> >> between the last update and this one. 9.4.* and 9.5.1 have been running 
>> >> fine.
>> >> 
>> >> Other tests with this one?
>> >> 
>> >> Thanks,
>> >> Lucas
>> >
>> > update attached for 9.5.2
>> >
>> >
>> 
>> This seems to have broken rcctl ls failed.
>> 
>> Adding
>> 
>> pexp="grafana server ${daemon_flags}"
>> 
>> to /etc/rc.d/grafana seems to fix things. It really wants
>> ${daemon_flags} in there, "grafana server" alone does not work.
>> 
>> -- 
>> In my defence, I have been left unsupervised.
>
> aha, thanks! How's this look/work for you? Checking with ls and check now
> report ok
>
>

-- 
In my defence, I have been left unsupervised.

Re: [update] sysutils/grafana to 9.5.1

[Florian Obser]

On 2023-05-18 02:45 UTC, Lucas Raab  wrote:
> On Thu, Apr 27, 2023 at 09:20:11AM +, Lucas Raab wrote:
>> Hello,
>> 
>> Here's an update for grafana to 9.5.1. I've run a couple 9.4.* releases
>> between the last update and this one. 9.4.* and 9.5.1 have been running fine.
>> 
>> Other tests with this one?
>> 
>> Thanks,
>> Lucas
>
> update attached for 9.5.2
>
>

This seems to have broken rcctl ls failed.

Adding

pexp="grafana server ${daemon_flags}"

to /etc/rc.d/grafana seems to fix things. It really wants
${daemon_flags} in there, "grafana server" alone does not work.

-- 
In my defence, I have been left unsupervised.

Re: NEW: IntelOne Mono font

[Florian Obser]

On 2023-05-23 07:56 -06, "Anthony J. Bentley"  wrote:
> Florian Obser writes:
>> They don't seem to be sure what to call the damn thing.
>> - Intel One Mono
>> - IntelOne Mono
>> - intel-one-mono
>>
>> I went with "IntelOne Mono" because that's how you configure the font.
>>
>> There is a sample here: https://github.com/intel/intel-one-mono
>>
>> Comments, OKs?
>
> Looks ok to me, and basically identical to one I made, except mine
> installed ttf.zip as well as otf.zip. Yes, this increases the package
> size, but not a whole lot in this case. Most font ports install both
> ttf and otf when available, and while it would be kind of cool to only
> package otf, some software still doesn't support it. Until we start
> stripping out ttf from all our packages, I think the package should
> have both ttf and otf when both are easily available.
>

Sorry, I seem to have missed your port. Please go ahead with yours then
since I have no idea how I would shoehorn ttf.zip into the port ;)

(I thought after the Atkinson disaster the party line became otf is good
enough, but maybe I missed something.)

-- 
In my defence, I have been left unsupervised.

NEW: IntelOne Mono font

[Florian Obser]

So I'm officially an old fart. I love the Atkinson Hyperlegible, time to
look for a monospace font as well.
I find this slightly easier on the eyes than the source code pro I used
previously, but it takes up more space. I'm not yet sure if I'll stick
with it.

I used atkinson-hyperlegible and literata as inspiration for the port
and then just made things up as I went along.

They don't seem to be sure what to call the damn thing.
- Intel One Mono
- IntelOne Mono
- intel-one-mono

I went with "IntelOne Mono" because that's how you configure the font.

There is a sample here: https://github.com/intel/intel-one-mono

Comments, OKs?



intelone-mono.tgz
Description: Binary data

-- 
In my defence, I have been left unsupervised.

Re: Atkinson Hyperlegible vs. Emacs (and xfontsel and gimp)

[Florian Obser]

This fixes my problem. The font still works in Firefox, too.

OK florian fwiw

On 2023-05-06 19:44 +02, Matthieu Herrb  wrote:
> On Sat, May 06, 2023 at 02:03:48PM +0200, Florian Obser wrote:
>> This is on amd64 -current with
>> Information for inst:atkinson-hyperlegible-2020.0514
>> 
>> This is the first time I'm using this font. Previously I have installed
>> Adobe Source Code Pro, which just works™. I rebooted the machine since
>> installing the font. This is about the extend of my knowledge of fonts
>> and X11, from here on out I'm just smashing stones together like an
>> animal...
>> 
>> When using the font in Emacs the glyphs seem to be empty, I'll attach
>> two screenshots at the end. Note that the configuration in Emacs is
>> correct, if I had typo'ed the font name Emacs would fall back to the
>> default font. The same behaviour is observable in gimp, where one can
>> select the font but text is just white on white.
>> 
>> The font works correctly in Firefox.
>> 
>> The font is not listed in xfontsel.
>
> This is normal. xfontsel only knows about the old server side rendered
> bitmap fonts. 
>> 
>> It shows up in fc-list:
>> 
>
> Apparently the TTF fonts that are installed by the port are somehow
> buggy or at least not understood by Cairo and Gtk.
>
> If one manually installs the OTF versions that are also provided in
> the ZIP distfile the fonts work with emacs or gimp (and as a system
> font in XFCE, which also doesn't work with the ttf version)
>
> ok  ?
>
> Index: Makefile
> ===
> RCS file: /local/cvs/ports/fonts/atkinson-hyperlegible/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -u -r1.1.1.1 Makefile
> --- Makefile  23 Jan 2023 11:09:48 -  1.1.1.1
> +++ Makefile  6 May 2023 17:43:39 -
> @@ -3,6 +3,7 @@ COMMENT = greater legibility and readabi
>  TYPEFACE =   Atkinson-Hyperlegible
>  V =  2020-0514
>  VPDF =   2020-1104
> +REVISION =   0
>  PKGNAME =${TYPEFACE:L}-${V:S/-/./}
>  CATEGORIES = fonts
>  
> @@ -12,6 +13,7 @@ HOMEPAGE =  https://brailleinstitute.org/
>  PERMIT_PACKAGE = Yes
>  
>  MODULES =font
> +FONTTYPES =  otf
>  
>  MASTER_SITES =   
> https://brailleinstitute.org/wp-content/uploads/atkinson-hyperlegible-font/
>  MASTER_SITES0 =  https://brailleinstitute.org/wp-content/uploads/2020/11/
> @@ -24,7 +26,7 @@ NO_BUILD =  Yes
>  NO_TEST =Yes
>  SUBST_VARS +=VPDF
>  
> -FONT_DISTDIR =   ${WRKDIR}/${TYPEFACE}-Font-Print-and-Web-${V}/Web\ 
> Fonts/TTF/
> +FONT_DISTDIR =   ${WRKDIR}/${TYPEFACE}-Font-Print-and-Web-${V}/Print\ 
> Fonts/
>  DOCDIR = ${PREFIX}/share/doc/hyperlegible
>  
>  post-install:
> Index: pkg/PLIST
> ===
> RCS file: /local/cvs/ports/fonts/atkinson-hyperlegible/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -u -r1.1.1.1 PLIST
> --- pkg/PLIST 23 Jan 2023 11:09:48 -  1.1.1.1
> +++ pkg/PLIST 6 May 2023 17:43:39 -
> @@ -2,7 +2,7 @@ share/doc/hyperlegible/
>  share/doc/hyperlegible/Atkinson-Hyperlegible-Font-License-${VPDF}.pdf
>  share/fonts/
>  @fontdir share/fonts/Atkinson-Hyperlegible/
> -share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-Bold-102.ttf
> -share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-BoldItalic-102.ttf
> -share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-Italic-102.ttf
> -share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-Regular-102.ttf
> +share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-Bold-102.otf
> +share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-BoldItalic-102.otf
> +share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-Italic-102.otf
> +share/fonts/Atkinson-Hyperlegible/Atkinson-Hyperlegible-Regular-102.otf
>
> -- 
> Matthieu Herrb
>

-- 
In my defence, I have been left unsupervised.

Re: [rfc] postgresql extensions & pg_upgrade

[Florian Obser]

On 2023-04-18 15:47 +02, Landry Breuil  wrote:
> Le Tue, Apr 18, 2023 at 09:04:00AM +0100, Stuart Henderson a écrit :
>> On 2023/04/18 09:05, Landry Breuil wrote:
>> > What do postgresql users do when upgrading databases with extensions ?
>> > Use the manual dump/restore way ?
>> 
>> That's what I did last time I needed it. I thought the pkg-readme
>> mentioned this but I just checked and I see it doesn't so at least we
>> shoukd add that.
>
> You mean a mention to users of extensions that the pg_upgrade path might
> not work in their case ?
>
>> The main tricky bit with that method is that you need to remember
>> to dump before updating the OS, because new kernels fairly often
>> won't run old binaries, there have been times I've had to mess around
>> with the ports tree to build old postgresql on the new release to
>> recover from that.
>
> I'm now used to dump all dbs prioir to sysupgrade :)

You could also just get the dump out of your multiply redundant
backups. :P

-- 
In my defence, I have been left unsupervised.

Re: prometheus sigbus

[Florian Obser]

This works, thanks!

On 2023-01-13 17:04 +01, Claudio Jeker  wrote:
> On Fri, Jan 13, 2023 at 03:56:10PM +0100, Florian Obser wrote:
>> gdb says this:
>> 
>> Thread 7 received signal SIGBUS, Bus error.
>> [Switching to thread 581635]
>> runtime.memmove () at /usr/local/go/src/runtime/memmove_amd64.s:151
>> 151  MOVBAX, (DI)
>> 
>
> Can you give this a try?
>
> -- 
> :wq Claudio
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/prometheus/Makefile,v
> retrieving revision 1.18
> diff -u -p -r1.18 Makefile
> --- Makefile  9 Dec 2022 14:50:55 -   1.18
> +++ Makefile  9 Dec 2022 14:51:21 -
> @@ -1,6 +1,6 @@
>  COMMENT =systems monitoring and alerting toolkit
>  
> -V =  2.37.4
> +V =  2.37.5
>  GH_ACCOUNT = prometheus
>  GH_PROJECT = prometheus
>  GH_TAGNAME = v${V}
> Index: distinfo
> ===
> RCS file: /cvs/ports/sysutils/prometheus/distinfo,v
> retrieving revision 1.8
> diff -u -p -r1.8 distinfo
> --- distinfo  9 Dec 2022 14:50:55 -   1.8
> +++ distinfo  9 Dec 2022 14:53:21 -
> @@ -1,6 +1,7 @@
> -SHA256 (prometheus-2.37.4.tar.gz) = 
> gIP1R9TjewtfeusIL9ScOyRegGSqzG6g667+bRWKpNI=
> -SHA256 (prometheus-vendor-2.37.4.tar.gz) = 
> UCoi3XIpdjwmUVrAb9wWzvDpMYj41vOXirbrIBPxk0E=
> -SHA256 (prometheus-web-ui-2.37.4.tar.gz) = 
> TA/pT8Q0b46eVUrqrgG4omZ84EKZm5vEG/7VKd2nzDQ=
> -SIZE (prometheus-2.37.4.tar.gz) = 6048871
> -SIZE (prometheus-vendor-2.37.4.tar.gz) = 11625254
> -SIZE (prometheus-web-ui-2.37.4.tar.gz) = 4332951
> +SHA256 (prometheus-2.37.5.tar.gz) = 
> aCh6OeQy/3QP55KYg7WAsgp1SUgopX1FVxmfUNDXJDw=
> +
> +SHA256 (prometheus-vendor-2.37.5.tar.gz) = 
> wd+Sdfp/EPvTRbdtqNqLC/zYTV49Vu+uJKaXW8efrwE=
> +SHA256 (prometheus-web-ui-2.37.5.tar.gz) = 
> G/zuXX/m4xuPLV1xBHMkKk8sDq6+uUYiYL5fCskspVY=
> +SIZE (prometheus-2.37.5.tar.gz) = 6048663
> +SIZE (prometheus-vendor-2.37.5.tar.gz) = 11745105
> +SIZE (prometheus-web-ui-2.37.5.tar.gz) = 4331652
>

-- 
I'm not entirely sure you are real.

Re: prometheus sigbus

[Florian Obser]

gdb says this:

Thread 7 received signal SIGBUS, Bus error.
[Switching to thread 581635]
runtime.memmove () at /usr/local/go/src/runtime/memmove_amd64.s:151
151 MOVBAX, (DI)


ktrace: https://vultr.tlakh.xyz/pub/ktrace.txt

On 2023-01-13 15:35 +01, Florian Obser  wrote:
> This is
> $ pkg_info prometheus
> Information for inst:prometheus-2.37.4
>
> on
> kern.version=OpenBSD 7.2-current (GENERIC.MP) #938: Thu Jan 12 23:53:42 MST 
> 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> # rcctl -d start prometheus
> doing _rc_parse_conf
> prometheus_flags empty, using default >--config.file 
> /etc/prometheus/prometheus.yml --storage.tsdb.path '/var/prometheus'<
> doing rc_check
> prometheus
> doing rc_start
> doing _rc_wait_for_start
> doing rc_check
> No home directory /nonexistent!
> Logging in with home = "/".
> prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:491 level=info 
> msg="No time or size retention was set so using the default time retention" 
> duration=15d
> prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:535 level=info 
> msg="Starting Prometheus Server" mode=server version="(version=, branch=, 
> revision=)"
> prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:540 level=info 
> build_context="(go=go1.19.4, user=, date=)"
> prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:541 level=info 
> host_details=(openbsd)
> prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:542 level=info 
> fd_limits="(soft=1024, hard=1024)"
> prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:543 level=info 
> vm_limits="(soft=4294967296b, hard=4294967296b)"
> prometheus[37800]: unexpected fault address 0x239126950
> prometheus[37800]: fatal error: fault
> prometheus[37800]: [signal SIGBUS: bus error code=0x3 addr=0x239126950 
> pc=0x46d9c2]
> prometheus[37800]:
> prometheus[37800]: goroutine 1 [running]:
> prometheus[37800]: runtime.throw({0x3059866?, 0x1e?})
> prometheus[37800]:/usr/local/go/src/runtime/panic.go:1047 +0x5d 
> fp=0xc000a7f050 sp=0xc000a7f020 pc=0x438b7d
> prometheus[37800]: runtime.sigpanic()
> prometheus[37800]:/usr/local/go/src/runtime/signal_unix.go:832 +0x1ac 
> fp=0xc000a7f0a0 sp=0xc000a7f050 pc=0x44ed8c
> prometheus[37800]: runtime.memmove()
> prometheus[37800]:/usr/local/go/src/runtime/memmove_amd64.s:151 +0x102 
> fp=0xc000a7f0a8 sp=0xc000a7f0a0 pc=0x46d9c2
> prometheus[37800]: 
> github.com/prometheus/prometheus/tsdb/fileutil.(*MmapWriter).Write(0xca6940,
>  {0xc000a7f147, 0x1, 0x39ead80?})
> prometheus[37800]:
> /usr/obj/ports/prometheus-2.37.4/go/src/github.com/prometheus/prometheus/tsdb/fileutil/writer.go:132
>  +0x165 fp=0xc000a7f118 sp=0xc000a7f0a8 pc=0x235da65
> prometheus[37800]: 
> github.com/prometheus/prometheus/promql.NewActiveQueryTracker({0x7f7dc123,
>  0xf}, 0x14, {0x39ead80, 0xc514a0})
> prometheus[37800]:
> /usr/obj/ports/prometheus-2.37.4/go/src/github.com/prometheus/prometheus/promql/query_logger.go:118
>  +0x20e fp=0xc000a7f230 sp=0xc000a7f118 pc=0x243592e
> prometheus[37800]: main.main()
> prometheus[37800]:
> /usr/obj/ports/prometheus-2.37.4/go/src/github.com/prometheus/prometheus/cmd/prometheus/main.go:597
>  +0x66f3 fp=0xc000a7ff80 sp=0xc000a7f230 pc=0x25614f3
> prometheus[37800]: runtime.main()
> prometheus[37800]:/usr/local/go/src/runtime/proc.go:250 +0x1f8 
> fp=0xc000a7ffe0 sp=0xc000a7ff80 pc=0x43b378
> prometheus[37800]: runtime.goexit()
> prometheus[37800]:/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 
> fp=0xc000a7ffe8 sp=0xc000a7ffe0 pc=0x46ca01
> prometheus[37800]:
> prometheus[37800]: goroutine 2 [force gc (idle)]:
> prometheus[37800]: runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
> prometheus[37800]:/usr/local/go/src/runtime/proc.go:363 +0xd6 
> fp=0xc6efb0 sp=0xc6ef90 pc=0x43b736
> prometheus[37800]: runtime.goparkunlock(...)
> prometheus[37800]:/usr/local/go/src/runtime/proc.go:369
> prometheus[37800]: runtime.forcegchelper()
> prometheus[37800]:/usr/local/go/src/runtime/proc.go:302 +0xa5 
> fp=0xc6efe0 sp=0xc6efb0 pc=0x43b5c5
> prometheus[37800]: runtime.goexit()
> prometheus[37800]:/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 
> fp=0xc6efe8 sp=0xc6efe0 pc=0x46ca01
> prometheus[37800]: created by runtime.init.6
> prometheus[37800]:/usr/local/go/src/runtime/proc.go:290 +0x25
> prometheus[37800]:
> prometheus[37800]: goroutine 3 [GC sweep wait]:
> prometheus[37800]: runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
> prometheus[37800]:/usr/local/go/src/runtime/proc.go:363 +0xd6 
> fp=0xc6f790 sp=0xc00

prometheus sigbus

[Florian Obser]

This is
$ pkg_info prometheus
Information for inst:prometheus-2.37.4

on
kern.version=OpenBSD 7.2-current (GENERIC.MP) #938: Thu Jan 12 23:53:42 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

# rcctl -d start prometheus
doing _rc_parse_conf
prometheus_flags empty, using default >--config.file 
/etc/prometheus/prometheus.yml --storage.tsdb.path '/var/prometheus'<
doing rc_check
prometheus
doing rc_start
doing _rc_wait_for_start
doing rc_check
No home directory /nonexistent!
Logging in with home = "/".
prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:491 level=info 
msg="No time or size retention was set so using the default time retention" 
duration=15d
prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:535 level=info 
msg="Starting Prometheus Server" mode=server version="(version=, branch=, 
revision=)"
prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:540 level=info 
build_context="(go=go1.19.4, user=, date=)"
prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:541 level=info 
host_details=(openbsd)
prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:542 level=info 
fd_limits="(soft=1024, hard=1024)"
prometheus[37800]: ts=2023-01-13T14:29:17.619Z caller=main.go:543 level=info 
vm_limits="(soft=4294967296b, hard=4294967296b)"
prometheus[37800]: unexpected fault address 0x239126950
prometheus[37800]: fatal error: fault
prometheus[37800]: [signal SIGBUS: bus error code=0x3 addr=0x239126950 
pc=0x46d9c2]
prometheus[37800]:
prometheus[37800]: goroutine 1 [running]:
prometheus[37800]: runtime.throw({0x3059866?, 0x1e?})
prometheus[37800]:  /usr/local/go/src/runtime/panic.go:1047 +0x5d 
fp=0xc000a7f050 sp=0xc000a7f020 pc=0x438b7d
prometheus[37800]: runtime.sigpanic()
prometheus[37800]:  /usr/local/go/src/runtime/signal_unix.go:832 +0x1ac 
fp=0xc000a7f0a0 sp=0xc000a7f050 pc=0x44ed8c
prometheus[37800]: runtime.memmove()
prometheus[37800]:  /usr/local/go/src/runtime/memmove_amd64.s:151 +0x102 
fp=0xc000a7f0a8 sp=0xc000a7f0a0 pc=0x46d9c2
prometheus[37800]: 
github.com/prometheus/prometheus/tsdb/fileutil.(*MmapWriter).Write(0xca6940,
 {0xc000a7f147, 0x1, 0x39ead80?})
prometheus[37800]:  
/usr/obj/ports/prometheus-2.37.4/go/src/github.com/prometheus/prometheus/tsdb/fileutil/writer.go:132
 +0x165 fp=0xc000a7f118 sp=0xc000a7f0a8 pc=0x235da65
prometheus[37800]: 
github.com/prometheus/prometheus/promql.NewActiveQueryTracker({0x7f7dc123, 
0xf}, 0x14, {0x39ead80, 0xc514a0})
prometheus[37800]:  
/usr/obj/ports/prometheus-2.37.4/go/src/github.com/prometheus/prometheus/promql/query_logger.go:118
 +0x20e fp=0xc000a7f230 sp=0xc000a7f118 pc=0x243592e
prometheus[37800]: main.main()
prometheus[37800]:  
/usr/obj/ports/prometheus-2.37.4/go/src/github.com/prometheus/prometheus/cmd/prometheus/main.go:597
 +0x66f3 fp=0xc000a7ff80 sp=0xc000a7f230 pc=0x25614f3
prometheus[37800]: runtime.main()
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:250 +0x1f8 
fp=0xc000a7ffe0 sp=0xc000a7ff80 pc=0x43b378
prometheus[37800]: runtime.goexit()
prometheus[37800]:  /usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 
fp=0xc000a7ffe8 sp=0xc000a7ffe0 pc=0x46ca01
prometheus[37800]:
prometheus[37800]: goroutine 2 [force gc (idle)]:
prometheus[37800]: runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:363 +0xd6 
fp=0xc6efb0 sp=0xc6ef90 pc=0x43b736
prometheus[37800]: runtime.goparkunlock(...)
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:369
prometheus[37800]: runtime.forcegchelper()
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:302 +0xa5 
fp=0xc6efe0 sp=0xc6efb0 pc=0x43b5c5
prometheus[37800]: runtime.goexit()
prometheus[37800]:  /usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 
fp=0xc6efe8 sp=0xc6efe0 pc=0x46ca01
prometheus[37800]: created by runtime.init.6
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:290 +0x25
prometheus[37800]:
prometheus[37800]: goroutine 3 [GC sweep wait]:
prometheus[37800]: runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:363 +0xd6 
fp=0xc6f790 sp=0xc6f770 pc=0x43b736
prometheus[37800]: runtime.goparkunlock(...)
prometheus[37800]:  /usr/local/go/src/runtime/proc.go:369
prometheus[37800]: runtime.bgsweep(0x0?)
prometheus[37800]:  /usr/local/go/src/runtime/mgcsweep.go:297 +0xd7 
fp=0xc6f7c8 sp=0xc6f790 pc=0x426717
prometheus[37800]: runtime.gcenable.func1()
prometheus[37800]:  /usr/local/go/src/runtime/mgc.go:178 +0x26 
fp=0xc6f7e0 sp=0xc6f7c8 pc=0x41b466
prometheus[37800]: runtime.goexit()
prometheus[37800]:  /usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 
fp=0xc6f7e8 sp=0xc6f7e0 pc=0x46ca01
prometheus[37800]: created by runtime.gcenable
prometheus[37800]:  /usr/local/go/src/runtime/mgc.go:178 +0x6b
prometheus[37800]:
prometheus[37800]: goroutine 4 [GC scavenge wait]:

ephemetoot depends on py3-setuptools?!

[Florian Obser]

Hi there,

after moving ephemetoot to a different server it failed thusly:

Traceback (most recent call last):
  File "/usr/local/bin/ephemetoot", line 5, in 
from ephemetoot.console import main
  File "/usr/local/lib/python3.10/site-packages/ephemetoot/console.py", line 
33, in 
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

Turns out the old server had py3-setuptools installed for unrelated
reasons.

So should this just be a run-dep? I don't have time to figure out *why*
it wants pkg_resources, that seems... odd... for a normal package.

Thanks,
Florian

-- 
I'm not entirely sure you are real.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2022/11/26 09:05:44

Modified files:
net/gelatod: Makefile distinfo 

Log message:
update to 1.4

This brings RFC 8781 support to get the NAT64 prefix from router
advertisements.

OK phessler, kn

gelatod 1.4

[Florian Obser]

I have just released gelatod 1.4:

New features:
 * Implement RFC 8781 to find the NAT64 prefix via router advertisements
   instead of RFC 7050 DNS64 probing.
Bug Fixes:
 * Memory leak fixed
 * Implemented DNS64 re-probing when resolvers change. This fixes
   roaming between networks.
 * Prevent spurious clean shutdowns when two or more pfctl processes are
   running in parallel.

OK?

diff --git Makefile Makefile
index 6e766b744df..25b1fa41fbe 100644
--- Makefile
+++ Makefile
@@ -1,8 +1,7 @@
 COMMENT =  CLAT configuration daemon for OpenBSD
-V =1.3
+V =1.4
 DISTNAME = gelatod-${V}
 CATEGORIES =   net
-REVISION = 1
 
 # BSD 2-clause
 PERMIT_PACKAGE =   Yes
diff --git distinfo distinfo
index d2b2b2da8f2..ab8e079bb0e 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (gelatod-1.3.tar.gz) = vb49p3m/ExbvI0DiOkXmx+qllduXCXa1O9iMPWKTozc=
-SIZE (gelatod-1.3.tar.gz) = 12548
+SHA256 (gelatod-1.4.tar.gz) = rEDK/WDEj5s4OKr8vCEwJPcZy/36nczzm5iBjx9n/Go=
+SIZE (gelatod-1.4.tar.gz) = 17376

-- 
I'm not entirely sure you are real.

powerdns auth: mandatory schema upgrade

[Florian Obser]

Hi,

there is a mandatory schema upgrade when upgrading from 4.6.x to 4.7.0

https://doc.powerdns.com/authoritative/upgrading.html

| The new Catalog Zones feature comes with a mandatory schema change for
| the gsql database backends. See files named
| 4.3.x_to_4.7.0_schema.X.sql

Without it, it fails to start with:

pdns[17775]: Exiting because communicator thread died with error: virtual void 
GSQLBackend::getUpdatedMasters(vector &, 
std::unordered_set &, CatalogHashMap &) unable to retrieve list of 
master domains: Fatal error during prePQpreparepare: select domains.id, 
domains.name, domains.type, domains.notified_serial, domains.options, 
domains.catalog, records.content from records join domains on 
records.domain_id=domains.id and records.name=domains.name where 
records.type='SOA' and records.disabled=false and domains.type in ('MASTER', 
'PRODUCER'): ERROR:  column domains.options does not exist LINE 1: 
...ains.name, domains.type, domains.notified_serial, domains.op...

Unfortunately the upstream tarball is missing
4.3.0_to_4.7.0_schema.pgsql.sql and 4.3.0_to_4.7.0_schema.mysql.sql so
we also don't package it. I have reported this upstream:
https://mailman.powerdns.com/pipermail/pdns-users/2022-October/027898.html 

The files are here:
https://raw.githubusercontent.com/PowerDNS/pdns/master/modules/gpgsqlbackend/4.3.0_to_4.7.0_schema.pgsql.sql
https://raw.githubusercontent.com/PowerDNS/pdns/master/modules/gmysqlbackend/4.3.0_to_4.7.0_schema.mysql.sql

No idea how much effort it would be to carry them as a local patch to
have them installed in /usr/local/share/doc/pdns/

Thanks,
Florian

-- 
I'm not entirely sure you are real.

Re: update salt to 3005.1

[Florian Obser]

+ Cc maintainer

I stopped using salt.

What we currently have in -current broke the saltmaster[sic] when I
upgraded from 7.2 to
OpenBSD 7.2-current (GENERIC) #769: Sat Oct 22 22:02:55 MDT 2022

It dies like this directly on start up, I suspect maybe a python update?
Not sure. I mean the bug is in salt, they just got lucky...

  2022-10-23 15:03:33,042 [tornado.application  :353 
][ERROR   ][32155] Future  exception was never retrieved: Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/salt/ext/tornado/gen.py", line 
309, in wrapper
yielded = next(result)
  File "/usr/local/lib/python3.9/site-packages/salt/utils/process.py", line 
664, in run
self.check_children()
  File "/usr/local/lib/python3.9/site-packages/salt/utils/process.py", line 
689, in check_children
for pid, mapping in self._process_map.items():
RuntimeError: dictionary keys changed during iteration

I then tried your 3005.1 which does not show this problem, but there is
an exciting new problem: The minions just hang after some time, maybe
about 1 hour. They no longer accept commands and rcctl stop salt_minion
times out and does a kill.

At that point I gave up and converted everything (back) to ansible.

-- 
I'm not entirely sure you are real.

Re: rspamd: failed to decode JSON response

[Florian Obser]

On 2022-10-24 17:15 +01, Stuart Henderson  wrote:
> Sendmail and Postfix support milter, which is used with rspamd's
> proxy worker - that all works OK afaik.
>
> OpenSMTPd doesn't use milter but has its own filtering protocol,
> so you'll need to use the external opensmtpd-filter-rspamd rather than
> anything built-in to rspamd, which doesn't work with the changes in
> rspamd 3.3 but which is expected to work again with these changes
> to rspamd.

Oh, got it. I thought you meant there is  a way to make OpenSMTPd also
use the milter.

>
> I don't know what the situation is with Exim, I've never used that
> with rspamd (and only ever used it to test updates).
>

-- 
I'm not entirely sure you are real.

Re: rspamd: failed to decode JSON response

[Florian Obser]

On 2022-10-24 15:25 +01, Stuart Henderson  wrote:
> On 2022/10/24 14:58, Florian Obser wrote:
>> Hi,
>> 
>> rspamd 3.3 brought my incoming mail to a grinding halt.
>> 
>> Oct 24 13:21:22 vultr smtpd[13575]: rspamd: failed to decode JSON response
>> 
>> The internet claims this is the problem:
>> 
>> https://github.com/rspamd/rspamd/issues/4315
>> 
>> and this is the fix:
>> 
>> https://github.com/rspamd/rspamd/commit/ded2e51e60325a0e817362c6df0c341bb00d4b0e
>> 
>> Unfortunately I'm no longer smart enough to patch ports, so I can test
>> this :/
>> 
>> I could probably test a diff for the port though.
>> 
>> Thanks,
>> Florian
>> 
>> -- 
>> I'm not entirely sure you are real.
>> 
>
> This is likely to be fixed with the backports which I have committed
> today, package name will be rspamd-3.3p1.

I've compiled it from source and I think it fixed the problem.
I haven't seen
rspamd: failed to decode JSON response
in over an hour.

Thanks for the quick fix!

>
> This is likely to be a problem with the opensmtpd filter but hasn't
> been an issue with rspamd's built-in milter support (which is what I'm
> using myself).
>

I don't understand what that means. Do you have a pointer for me?
I have read rspamd's pkg-readme which points me at
opensmtpd-filter-rspamd.

-- 
I'm not entirely sure you are real.

rspamd: failed to decode JSON response

[Florian Obser]

Hi,

rspamd 3.3 brought my incoming mail to a grinding halt.

Oct 24 13:21:22 vultr smtpd[13575]: rspamd: failed to decode JSON response

The internet claims this is the problem:

https://github.com/rspamd/rspamd/issues/4315

and this is the fix:

https://github.com/rspamd/rspamd/commit/ded2e51e60325a0e817362c6df0c341bb00d4b0e

Unfortunately I'm no longer smart enough to patch ports, so I can test
this :/

I could probably test a diff for the port though.

Thanks,
Florian

-- 
I'm not entirely sure you are real.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2022/07/14 07:47:42

Modified files:
sysutils/salt  : Makefile distinfo 

Log message:
update to 3003.5 to make it work with py3-jinja2 >= 3.1
OK robert

update salt to 3003.5 to make it compatible with >= 3.1

[Florian Obser]

Just when I thought I was out, they pull me back in...

On startup I'm seeing this:

import salt.utils.jinja
  File "/usr/local/lib/python3.9/site-packages/salt/utils/jinja.py", line 28, 
in 
from jinja2 import BaseLoader, Markup, TemplateNotFound, nodes
ImportError: cannot import name 'Markup' from 'jinja2'
  (/usr/local/lib/python3.9/site-packages/jinja2/__init__.py)


diff --git Makefile Makefile
index 96e1c082663..beb11baee69 100644
--- Makefile
+++ Makefile
@@ -15,7 +15,7 @@
 
 COMMENT =  remote execution and configuration management system
 
-MODPY_EGG_VERSION =3003.4
+MODPY_EGG_VERSION =3003.5
 DISTNAME = salt-${MODPY_EGG_VERSION}
 
 CATEGORIES =   sysutils net devel
diff --git distinfo distinfo
index ac689254523..d562fcb7c1e 100644
--- distinfo
+++ distinfo
@@ -1,2 +1,2 @@
-SHA256 (salt-3003.4.tar.gz) = 53uAjlG0HX5Jae4VWIrAT9DbmzPfonEPVEGNfrOHJM0=
-SIZE (salt-3003.4.tar.gz) = 16031515
+SHA256 (salt-3003.5.tar.gz) = RSnVG1bG1uHLw0+izj2J63OqkTk13Br+qcH7sJtM7qE=
+SIZE (salt-3003.5.tar.gz) = 16056545

-- 
I'm not entirely sure you are real.

Re: sysutils/upobsd removal

[Florian Obser]

Thank you very much for upobsd. I used it for years to automate upgrades
and it was the reason for sysupgrade(8). Great work!

It also was the source of inspiration on how to quickly test
install.sub diffs, that was a huge timesaver.


-- 
I'm not entirely sure you are real.

Re: 464xlat / gelatod

[Florian Obser]

deraadt@ pointed out that ports are running out of uids, so maybe this
is even too niche for ports as well.

Or don't allocate a user for it and let the frontend run as root. I
think the pledge we have is good enough for that.

Or the two users on the planet who are stupid enough to actually run in
such an environment build from source. It's easy enough after all.

More comments inline.

On 2021-11-17 09:32 +01, Bjorn Ketelaars  wrote:
> On Tue 16/11/2021 19:22, Klemens Nanni wrote:
>> On Tue, Nov 16, 2021 at 06:56:53PM +0100, Florian Obser wrote:
>> > So, I had an evening to waste the other day and noticed that I can ping
>> > 9.9.9.9 from my android phone while connected to an IPv6-only network.
>> > I want that on my laptop as well, so I wrote gelatod(*)
>> > 
>> > ---
>> > gelatod is a CLAT (Customer-side transLATor) configuration daemon. It is
>> > part of 464XLAT, an architecture for providing limited IPv4 connectivity
>> > across an IPv6-only network. It detects the presence of a NAT64
>> > translator in IPv6 only networks and configures pf(4) to translate IPv4
>> > packets into IPv6 packets for programs that do not work with DNS64.
>> > ---
>> > 
>> > https://github.com/fobser/gelatod/releases/tag/v1.1
>> > 
>> > I think this is too niche for base and the usage of pair(4) is probably
>> > a terrible hack, so here we are.
>> > 
>> > If someone who bears the burden of knowledge could turn this into a port
>> > I would be very greatful!
>> 
>> So it only needs a reservation in /usr/ports/infrastructure/db/user.list
>> besides the standard port I've attached.
>> 
>> > Please let me know if I need to adjust something in the Makefile to make
>> > porting easier or anything else that I should do. I already jumped
>> > through quite a few hoops to attach a binary asset to the release to
>> > have a proper tar ball.
>> 
>> You could upload a .tar.gz and save the EXTRACT_SUFX line.

Oh, you want tar.gz. Sure, will do.

>> 
>> You could provide versioned dirs in your tarballs as is common pratise,
>> but easily fixed in the port with `WRKSRC = ${WRKDIR}/gelatod'.
>> 
>> Both is really just taste -- whatever floats your boat as upstream.

Nah, I'll fix that. No need to clutter the port

so you want a tar.gz that extracts to gelatod-1.1/frontend.c etc etc.?

>> 
>> 
>> I put `anchor clat' at the top of my pf.conf, reloaded, followed
>> gelatod(8)'s instructions by copying them and started the rc script but
>> `pfctl -sr -a clat' remains empty.
>> 
>> I also tried starting the daemon first and then creating the pairs, but
>> with no avail.
>> 
>> I also got this at some point, so I directly enabled the debug-gelatod
>> package in the port and did
>> `install -d -m 700 -o root -g wheel /var/crash/gelatod' on my box:
>> 
>>  RTM_IFINFO: lost if 29
>>  update_clat: disable clat
>>  RTM_DELADDR: (null)[29]
>>  waiting for children to terminate
>>  frontend terminated; signal 11
>>  terminating
>> 
>> 
>> Still rough around the edges but you can play with it.
>
>
> Some comments:
>
> diff --git Makefile Makefile
> index a04362104f8..2cd7ff34bbf 100644
> --- Makefile
> +++ Makefile
> @@ -1,4 +1,4 @@
> -# $ OpenBSD: $
> +# $OpenBSD: $
>  
>  COMMENT =CLAT configuration daemon for OpenBSD
>  V =  1.1
> @@ -13,7 +13,7 @@ EXTRACT_SUFX =  .tgz
>  
>  DEBUG_PACKAGES = ${BUILD_PACKAGES}
>  
> -WRKSRC = ${WRKDIR}/gelatod
> +WRKDIST =${WRKDIR}/gelatod
>  
>  # uses pledge()
>  WANTLIB =c event util
> diff --git pkg/gelatod.rc pkg/gelatod.rc
> index cc0807a12cb..0ad3a626468 100644
> --- pkg/gelatod.rc
> +++ pkg/gelatod.rc
> @@ -2,7 +2,7 @@
>  #
>  # $OpenBSD: $
>  
> -daemon="/usr/local/sbin/gelatod"
> +daemon="${TRUEPREFIX}/sbin/gelatod"

I thought you lot gave up on that and agreed that everything is
/usr/local? If not the Makefile would also need patching...

>  
>  . /etc/rc.d/rc.subr
>  
>

-- 
I'm not entirely sure you are real.

Re: 464xlat / gelatod

[Florian Obser]

Thanks!
I'll put a new release together. I have an idea where to look for the crash.

It's probably not working for you because your DNS64 resolver is on a link 
local IP?
I ripped the NAT64 detector out of unwind before you fixed link local 
resolvers...


On 16 November 2021 20:22:00 CET, Klemens Nanni  wrote:
>On Tue, Nov 16, 2021 at 06:56:53PM +0100, Florian Obser wrote:
>> So, I had an evening to waste the other day and noticed that I can ping
>> 9.9.9.9 from my android phone while connected to an IPv6-only network.
>> I want that on my laptop as well, so I wrote gelatod(*)
>> 
>> ---
>> gelatod is a CLAT (Customer-side transLATor) configuration daemon. It is
>> part of 464XLAT, an architecture for providing limited IPv4 connectivity
>> across an IPv6-only network. It detects the presence of a NAT64
>> translator in IPv6 only networks and configures pf(4) to translate IPv4
>> packets into IPv6 packets for programs that do not work with DNS64.
>> ---
>> 
>> https://github.com/fobser/gelatod/releases/tag/v1.1
>> 
>> I think this is too niche for base and the usage of pair(4) is probably
>> a terrible hack, so here we are.
>> 
>> If someone who bears the burden of knowledge could turn this into a port
>> I would be very greatful!
>
>So it only needs a reservation in /usr/ports/infrastructure/db/user.list
>besides the standard port I've attached.
>
>> Please let me know if I need to adjust something in the Makefile to make
>> porting easier or anything else that I should do. I already jumped
>> through quite a few hoops to attach a binary asset to the release to
>> have a proper tar ball.
>
>You could upload a .tar.gz and save the EXTRACT_SUFX line.
>
>You could provide versioned dirs in your tarballs as is common pratise,
>but easily fixed in the port with `WRKSRC = ${WRKDIR}/gelatod'.
>
>Both is really just taste -- whatever floats your boat as upstream.
>
>
>I put `anchor clat' at the top of my pf.conf, reloaded, followed
>gelatod(8)'s instructions by copying them and started the rc script but
>`pfctl -sr -a clat' remains empty.
>
>I also tried starting the daemon first and then creating the pairs, but
>with no avail.
>
>I also got this at some point, so I directly enabled the debug-gelatod
>package in the port and did
>`install -d -m 700 -o root -g wheel /var/crash/gelatod' on my box:
>
>   RTM_IFINFO: lost if 29
>   update_clat: disable clat
>   RTM_DELADDR: (null)[29]
>   waiting for children to terminate
>   frontend terminated; signal 11
>   terminating
>
>
>Still rough around the edges but you can play with it.

-- 
Sent from a mobile device. Please excuse poor formatting.

464xlat / gelatod

[Florian Obser]

So, I had an evening to waste the other day and noticed that I can ping
9.9.9.9 from my android phone while connected to an IPv6-only network.
I want that on my laptop as well, so I wrote gelatod(*)

---
gelatod is a CLAT (Customer-side transLATor) configuration daemon. It is
part of 464XLAT, an architecture for providing limited IPv4 connectivity
across an IPv6-only network. It detects the presence of a NAT64
translator in IPv6 only networks and configures pf(4) to translate IPv4
packets into IPv6 packets for programs that do not work with DNS64.
---

https://github.com/fobser/gelatod/releases/tag/v1.1

I think this is too niche for base and the usage of pair(4) is probably
a terrible hack, so here we are.

If someone who bears the burden of knowledge could turn this into a port
I would be very greatful!

Please let me know if I need to adjust something in the Makefile to make
porting easier or anything else that I should do. I already jumped
through quite a few hoops to attach a binary asset to the release to
have a proper tar ball.

Thanks,
Florian

*) If you squint just right it kinda sounds like C-LAT-D, doesn't it?

-- 
I'm not entirely sure you are real.

Re: update: ephemetoot 3.1.2

[Florian Obser]

On 2021-08-23 18:37 +02, Paco Esteban  wrote:
> On Mon, 23 Aug 2021, Florian Obser wrote:
>
>> Hi,
>> 
>> the new version of ephemetoot allows archiving of media_attachments next
>> to the toots (which is kinda my fault).
>> 
>> OK?
>
> Hi Florian.  Your diff is ok, but tests fail now for the port.  This is
> because upstream tries to retrieve a JPG from the internet during the
> test of your new functionality, and we (at least I) use PORTS_PRIVSEP
> and _pbuild is not allowed to access the internet.
>

Sorry about that, I was not paying attention *how* they implemented that
test. I had asked for help with the test because I couldn't figure out
how that monkeypatching works.

> I've created a PR to fix this upstream:
> https://github.com/hughrun/ephemetoot/pull/76
>
> With that all tests pass again.  I think I'll wait a bit to see what
> upstream says about my PR (which probably will need some tweaking).
> If they don't respond, we I can include it as a patch.
>

Working with the maintainer on my PR was pleasent, they just took a few
days to respond.

-- 
I'm not entirely sure you are real.

update: ephemetoot 3.1.2

[Florian Obser]

Hi,

the new version of ephemetoot allows archiving of media_attachments next
to the toots (which is kinda my fault).

OK?

diff --git www/ephemetoot/Makefile www/ephemetoot/Makefile
index a1dcdbfb11a..073b324bc76 100644
--- www/ephemetoot/Makefile
+++ www/ephemetoot/Makefile
@@ -2,9 +2,8 @@
 
 COMMENT =  tool for deleting old Mastodon toots
 
-MODPY_EGG_VERSION =3.1.1
+MODPY_EGG_VERSION =3.1.2
 DISTNAME = ephemetoot-${MODPY_EGG_VERSION}
-REVISION = 0
 
 CATEGORIES =   www
 
diff --git www/ephemetoot/distinfo www/ephemetoot/distinfo
index 8e0f7c80282..7fb7c018ff2 100644
--- www/ephemetoot/distinfo
+++ www/ephemetoot/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ephemetoot-3.1.1.tar.gz) = ONmway0b7DojUV3uV3kPEgb9ZPG9Wgr00ZfVvFsofxI=
-SIZE (ephemetoot-3.1.1.tar.gz) = 25795
+SHA256 (ephemetoot-3.1.2.tar.gz) = p9rmhxGLC8wCejugzqxhox/T4UAfzy4VRyHF9x3/EhA=
+SIZE (ephemetoot-3.1.2.tar.gz) = 26155

-- 
I'm not entirely sure you are real.

Re: fetchmail update, test wanted

[Florian Obser]

fetchmail: 6.4.20 querying pop.gmx.de (protocol POP3) at Thu Jul 29 09:02:15 
2021: poll started
Trying to connect to 212.227.17.185/110...connected.
fetchmail: POP3< +OK POP server ready H migmx020 0MVSXe-1mgVaz2peI-00YxO4
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< STLS
fetchmail: POP3< SASL
fetchmail: POP3< IMPLEMENTATION trinity
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation
fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: T-Systems Enterprise Services GmbH
fetchmail: Issuer CommonName: T-TeleSec GlobalRoot Class 3
fetchmail: Subject CommonName: T-TeleSec GlobalRoot Class 3
fetchmail: SSL verify callback depth 1: preverify_ok == 1, err = 0, ok
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: T-Systems Enterprise Services GmbH
fetchmail: Issuer CommonName: T-TeleSec GlobalRoot Class 3
fetchmail: Subject CommonName: TeleSec ServerPass Extended Validation Class 3 CA
fetchmail: SSL verify callback depth 0: preverify_ok == 1, err = 0, ok
fetchmail: Server certificate:
fetchmail: Issuer Organization: T-Systems International GmbH
fetchmail: Issuer CommonName: TeleSec ServerPass Extended Validation Class 3 CA
fetchmail: Subject CommonName: mail.gmx.net
fetchmail: Subject Alternative Name: mail.gmx.net
fetchmail: Subject Alternative Name: mail.gmx.de
fetchmail: Subject Alternative Name: smtp.gmx.net
fetchmail: Subject Alternative Name: smtp.gmx.de
fetchmail: Subject Alternative Name: imap.gmx.net
fetchmail: Subject Alternative Name: imap.gmx.de
fetchmail: Subject Alternative Name: pop.gmx.net
fetchmail: Subject Alternative Name: pop.gmx.de
fetchmail: pop.gmx.de key fingerprint: 
B1:70:9C:4D:EC:80:2F:9B:81:CB:AE:C1:99:BF:58:E5
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher AEAD-AES256-GCM-SHA384, 
256/256 secret/processed bits
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< IMPLEMENTATION trinity
fetchmail: POP3< .
fetchmail: pop.gmx.de: upgrade to TLS succeeded.
fetchmail: POP3> USER [...]

I think this still works...

On 2021-07-28 22:46 +01, Stuart Henderson  wrote:
> includes a security fix for long log messages, and various others.
> some SSL code was reorganised, does anyone have a working config
> they could test with to make sure the adaptation for that still
> works ok?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/fetchmail/Makefile,v
> retrieving revision 1.161
> diff -u -p -r1.161 Makefile
> --- Makefile  28 Mar 2021 13:32:50 -  1.161
> +++ Makefile  28 Jul 2021 21:44:41 -
> @@ -2,7 +2,7 @@
>  
>  COMMENT= mail retrieval utility for POP2, POP3, KPOP, IMAP and more
>  
> -DISTNAME=fetchmail-6.4.13
> +DISTNAME=fetchmail-6.4.20
>  EXTRACT_SUFX=.tar.xz
>  
>  CATEGORIES=  mail
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/fetchmail/distinfo,v
> retrieving revision 1.39
> diff -u -p -r1.39 distinfo
> --- distinfo  28 Mar 2021 13:32:50 -  1.39
> +++ distinfo  28 Jul 2021 21:44:41 -
> @@ -1,2 +1,2 @@
> -SHA256 (fetchmail-6.4.13.tar.xz) = 
> fSjPBgsGucjsciZ75+3JqZtw9h19Mti2CUWNzt+nS+E=
> -SIZE (fetchmail-6.4.13.tar.xz) = 1308248
> +SHA256 (fetchmail-6.4.20.tar.xz) = 
> yCFBri6PADnOsMXC7aQ8XpOtC/f5xrtigJKzvnQ4YXY=
> +SIZE (fetchmail-6.4.20.tar.xz) = 1317204
> Index: patches/patch-Makefile_in
> ===
> RCS file: /cvs/ports/mail/fetchmail/patches/patch-Makefile_in,v
> retrieving revision 1.23
> diff -u -p -r1.23 patch-Makefile_in
> --- patches/patch-Makefile_in 13 Sep 2020 19:01:23 -  1.23
> +++ patches/patch-Makefile_in 28 Jul 2021 21:44:41 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-Makefile_in,v 1.23 2020/
>  Index: Makefile.in
>  --- Makefile.in.orig
>  +++ Makefile.in
> -@@ -2154,7 +2154,7 @@ info: info-recursive
> +@@ -2197,7 +2197,7 @@ info: info-recursive
>   
>   info-am:
>   
> Index: patches/patch-socket_c
> ===
> RCS file: /cvs/ports/mail/fetchmail/patches/patch-socket_c,v
> retrieving revision 1.13
> diff -u -p -r1.13 patch-socket_c
> --- patches/patch-socket_c14 Sep 2020 15:14:55 -  1.13
> +++ patches/patch-socket_c28 Jul 2021 21:44:41 -
> @@ -3,16 +3,7 @@ $OpenBSD: patch-socket_c,v 1.13 2020/09/
>  Index: socket.c
>  --- socket.c.orig
>  +++ socket.c
> -@@ -902,7 +902,7 @@ static const char *SSLCertGetCN(const char *mycert,
> - return ret;
> - }
> - 
> --#if defined(LIBRESSL_VERSION_NUMBER) || OPENSSL_VERSION_NUMBER < 0x101fL
> -+#if OPENSSL_VERSION_NUMBER < 0x101fL

Re: [root cause] Nextcloud stopped working after upgrade to 6.9 - chunked encoding

[Florian Obser]

On 2021-05-17 09:12 +02, Stefan Sperling  wrote:
> On Fri, May 14, 2021 at 07:07:53PM +0200, Florian Obser wrote:
>> oh, it's 204 no content. I missed that.
>> The demo url (apparently running appache) doesn't return a
>> Content-Lenght, either.
>> 
>> Anyway, trying to chunk encode an empty body is not going to work well.
>> 
>> This is making the spice flow again:
>
> I confirm that this fixes upload from the nextcloud app for me as well.
> There were also some occasional connection issues while browsing my
> nextcloud instance with firefox. I'll have to wait and see if those are
> now fixed. Server is running stock 6.9 with the patch below.
>
> Should we also be including 1xx codes in the check added here?
> In server_abort_http() there is this:
> if ((code >= 100 && code < 200) || code == 204)
>   clenheader = NULL;
> Which matches https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.1
>   A server MUST NOT send a Transfer-Encoding header field in any
>   response with a status code of 1xx (Informational) or 204 (No Content).
>
> In any case, ok stsp@

I had send an improved diff to tech and forgot to post it here, too:
Subject: "httpd(8): don't try to chunk-encode an empty body"

This delays sending of the http headers until we know if the body is
empty or not and then doesn't try to chunk encode an empty body.
I think this should cover all cases as long as the fcgi server is
conforming to specs.

This will also prevent chunk encoding an e.g 200 response with
Content-Lenght: 0, which would not work well either before.

diff --git httpd.h httpd.h
index b3a40b3af68..c4adfba232d 100644
--- httpd.h
+++ httpd.h
@@ -300,6 +300,7 @@ struct fcgi_data {
int  end;
int  status;
int  headersdone;
+   int  headerssent;
 };
 
 struct range {
diff --git server_fcgi.c server_fcgi.c
index 64a0e9d2abb..e1e9704c920 100644
--- server_fcgi.c
+++ server_fcgi.c
@@ -114,6 +114,7 @@ server_fcgi(struct httpd *env, struct client *clt)
clt->clt_fcgi.toread = sizeof(struct fcgi_record_header);
clt->clt_fcgi.status = 200;
clt->clt_fcgi.headersdone = 0;
+   clt->clt_fcgi.headerssent = 0;
 
if (clt->clt_srvevb != NULL)
evbuffer_free(clt->clt_srvevb);
@@ -544,22 +545,20 @@ server_fcgi_read(struct bufferevent *bev, void *arg)
if (!clt->clt_fcgi.headersdone) {
clt->clt_fcgi.headersdone =
server_fcgi_getheaders(clt);
-   if (clt->clt_fcgi.headersdone) {
-   if (server_fcgi_header(clt,
-   clt->clt_fcgi.status)
-   == -1) {
-   server_abort_http(clt,
-   500,
-   "malformed fcgi "
-   "headers");
-   return;
-   }
-   }
if (!EVBUFFER_LENGTH(clt->clt_srvevb))
break;
}
/* FALLTHROUGH */
case FCGI_END_REQUEST:
+   if (clt->clt_fcgi.headersdone &&
+   !clt->clt_fcgi.headerssent) {
+   if (server_fcgi_header(clt,
+   clt->clt_fcgi.status) == -1) {
+   server_abort_http(clt, 500,
+   "malformed fcgi headers");
+   return;
+   }
+   }
if (server_fcgi_writechunk(clt) == -1) {
server_abort_http(clt, 500,
"encoding error");
@@ -600,6 +599,8 @@ server_fcgi_header(struct client *clt, unsigned int code)
char tmbuf[32];
struct kv   *kv, *cl, key;
 
+   clt->clt_fcgi.headerssent = 1;
+
if (desc == NULL || (error = server_httperror_byid(code)) == NULL)
return (-1);
 
@@ -615,6 +616,12 @@ server_fcgi_header(struct client *clt, unsigned in

Re: [root cause] Nextcloud stopped working after upgrade to 6.9 - chunked encoding

[Florian Obser]

On 2021-05-13 22:00 +01, Chris Narkiewicz  wrote:
> I did this when investigating the problem. Nginx returns 204 and no
> Transfer-Encoding header. Httpd returns 204 and
> Transfer-Encoding: chunked and no Content-Length.
>
> Since I'm familiar with the Java/Kotlin code on the client side, and
> stepped through it with a debugger, I know that chunked encoding is
> the root cause, causing the client to return reply without content
> length (signalled as -1).
>
>> Or maybe the answer is just: nginx doesn't do chunked encoding?
>
> You can check by doing curl -v https://demo1.nextcloud.com/index.php/204
> and the same with something that runs on httpd.
>

oh, it's 204 no content. I missed that.
The demo url (apparently running appache) doesn't return a
Content-Lenght, either.

Anyway, trying to chunk encode an empty body is not going to work well.

This is making the spice flow again:

diff --git server_fcgi.c server_fcgi.c
index 8d3b581568f..0ac80c27d11 100644
--- server_fcgi.c
+++ server_fcgi.c
@@ -615,6 +615,10 @@ server_fcgi_header(struct client *clt, unsigned int code)
if (kv_add(>http_headers, "Server", HTTPD_SERVERNAME) == NULL)
return (-1);
 
+   /* we cannot chunk-encode no-content */
+   if (code == 204)
+   clt->clt_fcgi.chunked = 0;
+
/* Set chunked encoding */
if (clt->clt_fcgi.chunked) {
/* XXX Should we keep and handle Content-Length instead? */



> Cheerio,
> Chris
>

-- 
I'm not entirely sure you are real.

Re: Nextcloud stopped working after upgrade to 6.9 - chunked encoding

[Florian Obser]

On 2021-05-11 23:30 +01, Chris Narkiewicz  wrote:
> Hi all,
>
> I'm using Nextcloud and after upgrading to latest OpenBSD 6.9
> it stopped uploading files from Android client.
>
> I did an analysis and it turns out that becuase httpd uses
> Transfer-Encoding: chunked, Content-Length is not available on the
> client side and some code path there excplicitly checks for
> Content-Length == 0.
>
> If you are interested in boring details, here is the upstream bug
> report that I'll be fixing shortly:
>
> https://github.com/nextcloud/android/issues/8384
>
> Funny thing is that this worked on my 6.8 installation, so I thought
> that something might have changed in latest httpd that broke the
> client.

I don't think so, I'm running current and I last updated my nextcloud
server on Apr 30th. Uploads were still working on May 5th and they
stopped working on May 7th. Apparently I did not take pictures on May
7th.

>
> Nevertheless, I thought that I'll ping port maintainers as well, as
> this might sting any OpenBSD users of Nextcloud as well and perhaps it
> is some sort of issue with httpd?

While my timeline suggests that this is triggered by a change in the
mobile app, I'm happy to entertain the idea that httpd is doing
something wrong. Were you able to try with e.g. nginx and is it working
there?

I'd be interested in seeing HTTP request/response headers for httpd(8)
and nginx to see how they are different if this works with nginx. Or
maybe the answer is just: nginx doesn't do chunked encoding?

Thanks,
Florian

>
> Cheers,
> Chris
>

-- 
I'm not entirely sure you are real.

Re: icinga-web2 & httpd(8)

[Florian Obser]

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: icinga-web2 & httpd(8)

[Florian Obser]

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.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2021/04/09 11:41:15

Modified files:
net/icinga/web2: Makefile 
net/icinga/web2/pkg: README 

Log message:
Add an example base httpd(8) configuration example.
This runs icinga-web2 out of the webserver root, so far we have not
found a non-awkward way to have it in /icingaweb2 like the other
examples.
Michael Wilson (mw at 1wilson.org) answered my cry for help, thanks!
OK sthen

Re: icinga-web2 & httpd(8)

[Florian Obser]

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.

Re: icinga-web2 & httpd(8)

[Florian Obser]

On Sat, Apr 03, 2021 at 12:28:56PM +0100, Stuart Henderson wrote:
> On 2021/04/03 11:11, Florian Obser wrote:
> > Nice this works for me, too.
> > Thank you very much.
> > 
> > sthen: OK to add it to the README?
> 
> I'd like to have it working with the same path as the other example
> configurations (/icingaweb2 rather than in the root) so that the
> configs are interchangeable with other servers, can you use this
> instead please?

Makes sense, I missed that.
However, your config doesn't quite work.
For example, requesting /icingaweb2/img/icinga-logo-big-dark.svg
results in http 200 with Content-lenght: 0.

Sprinkling more root and request strips doesn't seem to help :/
I suspect the "not found" isn't working correctly.

I'm out of ideas for now.
Maybe Michael or you have an idea.
It's also possible that httpd(8) just can't do it?

> 
> 
>   location "/icingaweb2/*.php*" {
>   root "/icinga-web2/public"
>   request strip 1
>   fastcgi socket "/run/php-fpm-icingaweb2.sock"
>   fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
>   }
> 
>   location not found "/icingaweb2/*" {
>   
>   request strip 1
>   request rewrite "/icingaweb2/index.php?$QUERY_STRING"   
>  
>   }  
> 
>   location "/icingaweb2/" {  
>   directory index "index.php"   
>   }
> 
> 
> > +An example for httpd (remember to "rcctl reload httpd" after adding),
> > +using the above php-fpm section:
> 
> And please use "base httpd" or "OpenBSD httpd" to distinguish between
> the two unfortunately-similarly-named daemons ;)

There can be only one!

> 
> > +
> > +   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"
> > +   }
> > +
> >  For Apache httpd, configuration files are provided in
> >  ${PREFIX}/conf/modules.sample that can be symlinked to 
> > ${PREFIX}/conf/modules.
> 

-- 
I'm not entirely sure you are real.

Re: icinga-web2 & httpd(8)

[Florian Obser]

Nice this works for me, too.
Thank you very much.

sthen: OK to add it to the README?

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..dc6c13d2ee5 100644
--- pkg/README
+++ pkg/README
@@ -61,6 +61,20 @@ after adding), using the above php-fpm section:
try_files $1 $uri $uri/ /icingaweb2/index.php$is_args$args;
}
 
+An example for httpd (remember to "rcctl reload httpd" after adding),
+using the above php-fpm section:
+
+   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"
+   }
+
 For Apache httpd, configuration files are provided in
 ${PREFIX}/conf/modules.sample that can be symlinked to ${PREFIX}/conf/modules.
 

On Fri, Apr 02, 2021 at 09:23:03PM +0200, Michael Wilson wrote:
> This did the trick for me:
> 
> server "default" {
>listen on * port 80
> 
>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"
>   }
> }
> 
> > Am 25.03.2021 um 10:13 schrieb Florian Obser :
> > 
> > Did anyone get icinga-web2 working with httpd(8)?
> > If so please share a config snippet.
> > 
> > Thanks,
> > Florian
> > 
> > -- 
> > I'm not entirely sure you are real.
> > 
> 

-- 
I'm not entirely sure you are real.

icinga-web2 & httpd(8)

[Florian Obser]

Did anyone get icinga-web2 working with httpd(8)?
If so please share a config snippet.

Thanks,
Florian

-- 
I'm not entirely sure you are real.

Collision in py-sip-4.19.19p0v0->4.19.24v0

[Florian Obser]

I'm seeing this on -current amd64

[root@x1:~]# pkg_add -u
quirks-3.517 signed on 2021-01-22T13:17:10Z
Collision in py-sip-4.19.19p0v0->4.19.24v0: the following files already exist
/usr/local/lib/python2.7/site-packages/PyQt5/sip.pyi 
(py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0)
/usr/local/lib/python2.7/site-packages/PyQt5/sip.so 
(py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0)
Can't install py-qt5-5.13.2p1->5.15.2: can't resolve py-sip-4.19.24v0
Couldn't find updates for py-qt5-5.13.2p1 py-sip-4.19.19p0v0 
py-sip-qt5-4.19.19p0
Couldn't install py-qt5-5.15.2 py-sip-4.19.24v0

I think it ultimately gets dragged in because of calibre.

OpenBSD 6.8-current (GENERIC.MP) #288: Fri Jan 22 13:36:58 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8233394176 (7851MB)
avail mem = 7968538624 (7599MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (61 entries)
bios0: vendor LENOVO version "GRET40WW (1.17 )" date 09/02/2014
bios0: LENOVO 20A7006VUS
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.31 MHz, 06-45-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
dwiic0 at acpi0 I2C1 addr 0xfe105000/0x1000 irq 7
iic0 at dwiic0
"CPLM3218" at iic0 addr 0x48 not configured
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "45N1703" serial  3191 type LiP oem "SMP"
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0: version 2.0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" 

Re: remove sysutils/upobsd

[Florian Obser]

On 17 January 2021 16:53:34 CET, Denis Fondras  wrote:
>Le Sun, Jan 17, 2021 at 12:10:58PM +0100, Sebastien Marie a écrit :
>> I would like to know if someone still needs upobsd or if it is
>> removable ?
>> 
>
>I use it when I upgrade my EdgeRouters. If upobsd is removed, I will
>find
>another way :)

Why not use sysupgrade for those?
Did you forget to switch to the new bootloader a few releases ago?
-- 
Sent from a mobile device. Please excuse poor formating.

Re: nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument

[Florian Obser]

On Wed, Dec 02, 2020 at 05:34:52PM +, Stuart Henderson wrote:
> I didn't manage to track down a fix but I've set nsca-ng back to using
> openssl/1.0.2 for now, my glasses do not permit looking at BIO_* for
> more than a few moments.

Seems reasonable.

Turns out this is also broken client side where I use a literal hostname in 
send_nsca.cfg:
send_nsca: [FATAL] Socket error (xxx.yyy.xyz): Broken pipe
Putting in an ip address fixes things.

> 
> 
> On 2020/12/02 17:23, Florian Obser wrote:
> > Looks like this thing might be legacy IP only.
> > I work around the problem by adding:
> > listen = "0.0.0.0"
> > to /etc/nsca-ng.cfg
> > 
> > Having glanced at the code in src/common/tls.c could this be an
> > openssl update?
> > 
> > Don't think I'll have a lot of time digging into this though.
> > 
> > On Wed, Dec 02, 2020 at 04:44:27PM +0100, Florian Obser wrote:
> > > After the recent nsca-ng update it no longer starts:
> > > 
> > > nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
> > > 
> > > My nsca-ng config is fairly simple:
> > > 
> > > # cat /etc/nsca-ng.cfg
> > > command_file = "/var/icinga/rw/icinga.cmd"
> > > 
> > > authorize "*" {
> > >   password = "XXX"
> > >   hosts = ".*"
> > >   services = ".*"
> > > }
> > > 
> > > I don't recall if the previous version was listening on v4, v6 or
> > > both.
> > > It starts for example with:
> > >   nsca-ng -b 127.0.0.1
> > > 
> > > Thanks,
> > > Florian
> > > 
> > > -- 
> > > I'm not entirely sure you are real.
> > > 
> > 
> > -- 
> > I'm not entirely sure you are real.
> > 
> 

-- 
I'm not entirely sure you are real.

Re: nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument

[Florian Obser]

Looks like this thing might be legacy IP only.
I work around the problem by adding:
listen = "0.0.0.0"
to /etc/nsca-ng.cfg

Having glanced at the code in src/common/tls.c could this be an
openssl update?

Don't think I'll have a lot of time digging into this though.

On Wed, Dec 02, 2020 at 04:44:27PM +0100, Florian Obser wrote:
> After the recent nsca-ng update it no longer starts:
> 
> nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
> 
> My nsca-ng config is fairly simple:
> 
> # cat /etc/nsca-ng.cfg
> command_file = "/var/icinga/rw/icinga.cmd"
> 
> authorize "*" {
>   password = "XXX"
>   hosts = ".*"
>   services = ".*"
> }
> 
> I don't recall if the previous version was listening on v4, v6 or
> both.
> It starts for example with:
>   nsca-ng -b 127.0.0.1
> 
> Thanks,
> Florian
> 
> -- 
> I'm not entirely sure you are real.
> 

-- 
I'm not entirely sure you are real.

nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument

[Florian Obser]

After the recent nsca-ng update it no longer starts:

nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument

My nsca-ng config is fairly simple:

# cat /etc/nsca-ng.cfg
command_file = "/var/icinga/rw/icinga.cmd"

authorize "*" {
password = "XXX"
hosts = ".*"
services = ".*"
}

I don't recall if the previous version was listening on v4, v6 or
both.
It starts for example with:
nsca-ng -b 127.0.0.1

Thanks,
Florian

-- 
I'm not entirely sure you are real.

Re: new: sysutils/mdf2iso

[Florian Obser]

Sounds like you are done here. Again.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2020/07/15 04:29:16

Modified files:
sysutils/salt  : Makefile 
Added files:
sysutils/salt/patches: patch-salt_returners_highstate_return_py 
   patch-salt_returners_nagios_nrdp_return_py 

Log message:
Replace cgi.escape with html.escape. The former has been deprecated since
python 3.2 and removed in 3.8. html.escape is the recommended drop-in
fix.
OK sthen, bket

Re: salt: cgi.escape() has been removed in python 3.8

[Florian Obser]

anyone?

On Thu, Jul 09, 2020 at 01:52:37PM +0200, Florian Obser wrote:
> ... after it was deprecated since 3.2.
> 
> 2020-07-09 08:38:44,604 [salt.utils.schedule  
>  :853 ][ERROR   ][26771] Unhandled exception running stat
> e.highstate
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.8/site-packages/salt/utils/schedule.py", line 
> 844, in handle_func
> self.returners[ret_str](ret)
>   File 
> "/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
> line 480, in returner
> _produce_output(report, failed, setup)
>   File 
> "/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
> line 433, in _produce_output
> _generate_html(report, string_file)
>   File 
> "/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
> line 269, in _generate_html
> _generate_html_table(data, out, 0)
>   File 
> "/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
> line 220, in _generate_html_table
> _generate_html_table(value, out, level + 1, new_extra_style)
>   File 
> "/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
> line 229, in _generate_html_table
> cgi.escape(six.text_type(value)),
> AttributeError: module 'cgi' has no attribute 'escape'
> 
> I only tested the hightstate returner, no idea about nagios, but it's
> mechanical...
> 
> Technically this changes behavior in the highstate returner but I
> think what it did before was actually a bug, called out in the
> deprecation note:
> 
> "Deprecated since version 3.2: This function is unsafe because quote
> is false by default, and therefore deprecated. Use html.escape()
> instead."
> https://docs.python.org/3.7/library/cgi.html#cgi.escape
> 
> OK?
> 
> p.s. I tried to work out how to feed this upstream but I don't fully
> grok the hoopes they want me to jump through.
> 
> diff --git Makefile Makefile
> index 1f38fa8af70..9fcf4d52a38 100644
> --- Makefile
> +++ Makefile
> @@ -19,7 +19,7 @@ COMMENT =   remote execution and configuration 
> management system
>  
>  MODPY_EGG_VERSION =  3001
>  DISTNAME =   salt-${MODPY_EGG_VERSION}
> -REVISION =   3
> +REVISION =   4
>  
>  CATEGORIES = sysutils net devel
>  
> diff --git patches/patch-salt_returners_highstate_return_py 
> patches/patch-salt_returners_highstate_return_py
> new file mode 100644
> index 000..439612ac661
> --- /dev/null
> +++ patches/patch-salt_returners_highstate_return_py
> @@ -0,0 +1,33 @@
> +$OpenBSD$
> +cgi.escape has been deprecated since python 3.2 and removed in 3.8.
> +
> +Index: salt/returners/highstate_return.py
> +--- salt/returners/highstate_return.py.orig
>  salt/returners/highstate_return.py
> +@@ -79,7 +79,7 @@ the time of execution.
> + """
> + from __future__ import absolute_import, print_function, unicode_literals
> + 
> +-import cgi
> ++import html
> + import logging
> + import smtplib
> + from email.mime.text import MIMEText
> +@@ -226,7 +226,7 @@ def _generate_html_table(data, out, level=0, extra_sty
> + "td",
> + [cell_style, second_style, "value", 
> new_extra_style],
> + ),
> +-cgi.escape(six.text_type(value)),
> ++html.escape(six.text_type(value)),
> + ),
> + file=out,
> + )
> +@@ -251,7 +251,7 @@ def _generate_html_table(data, out, level=0, extra_sty
> + _lookup_style(
> + "td", [cell_style, first_style, "value", 
> extra_style]
> + ),
> +-cgi.escape(six.text_type(subdata)),
> ++html.escape(six.text_type(subdata)),
> + ),
> + file=out,
> + )
> diff --git patches/patch-salt_returners_nagios_nrdp_return_py 
> patches/patch-salt_returners_nagios_nrdp_return_py
> new file mode 100644
> index 000..a3406afa892
> --- /dev/null
> +++ patches/patch-salt_returners_nagios_nrdp_return_py
> @@ -0,0 +1,40 @@
> +$OpenBSD$
> +cgi.escape has been deprecated since python 3.2 and removed in 3.8.
> +
> +Index: salt/returners/nagios_nrdp_return.py
> +--- salt/returners/nagios_nrdp_return.py.orig
>  salt/returners/nagios_nrdp_return.py
> +@@ -51,7 +51,7 @@ To override individual configuration items, 

salt: cgi.escape() has been removed in python 3.8

[Florian Obser]

... after it was deprecated since 3.2.

2020-07-09 08:38:44,604 [salt.utils.schedule
   :853 ][ERROR   ][26771] Unhandled exception running stat
e.highstate
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/salt/utils/schedule.py", line 
844, in handle_func
self.returners[ret_str](ret)
  File 
"/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
line 480, in returner
_produce_output(report, failed, setup)
  File 
"/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
line 433, in _produce_output
_generate_html(report, string_file)
  File 
"/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
line 269, in _generate_html
_generate_html_table(data, out, 0)
  File 
"/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
line 220, in _generate_html_table
_generate_html_table(value, out, level + 1, new_extra_style)
  File 
"/usr/local/lib/python3.8/site-packages/salt/returners/highstate_return.py", 
line 229, in _generate_html_table
cgi.escape(six.text_type(value)),
AttributeError: module 'cgi' has no attribute 'escape'

I only tested the hightstate returner, no idea about nagios, but it's
mechanical...

Technically this changes behavior in the highstate returner but I
think what it did before was actually a bug, called out in the
deprecation note:

"Deprecated since version 3.2: This function is unsafe because quote
is false by default, and therefore deprecated. Use html.escape()
instead."
https://docs.python.org/3.7/library/cgi.html#cgi.escape

OK?

p.s. I tried to work out how to feed this upstream but I don't fully
grok the hoopes they want me to jump through.

diff --git Makefile Makefile
index 1f38fa8af70..9fcf4d52a38 100644
--- Makefile
+++ Makefile
@@ -19,7 +19,7 @@ COMMENT = remote execution and configuration 
management system
 
 MODPY_EGG_VERSION =3001
 DISTNAME = salt-${MODPY_EGG_VERSION}
-REVISION = 3
+REVISION = 4
 
 CATEGORIES =   sysutils net devel
 
diff --git patches/patch-salt_returners_highstate_return_py 
patches/patch-salt_returners_highstate_return_py
new file mode 100644
index 000..439612ac661
--- /dev/null
+++ patches/patch-salt_returners_highstate_return_py
@@ -0,0 +1,33 @@
+$OpenBSD$
+cgi.escape has been deprecated since python 3.2 and removed in 3.8.
+
+Index: salt/returners/highstate_return.py
+--- salt/returners/highstate_return.py.orig
 salt/returners/highstate_return.py
+@@ -79,7 +79,7 @@ the time of execution.
+ """
+ from __future__ import absolute_import, print_function, unicode_literals
+ 
+-import cgi
++import html
+ import logging
+ import smtplib
+ from email.mime.text import MIMEText
+@@ -226,7 +226,7 @@ def _generate_html_table(data, out, level=0, extra_sty
+ "td",
+ [cell_style, second_style, "value", 
new_extra_style],
+ ),
+-cgi.escape(six.text_type(value)),
++html.escape(six.text_type(value)),
+ ),
+ file=out,
+ )
+@@ -251,7 +251,7 @@ def _generate_html_table(data, out, level=0, extra_sty
+ _lookup_style(
+ "td", [cell_style, first_style, "value", extra_style]
+ ),
+-cgi.escape(six.text_type(subdata)),
++html.escape(six.text_type(subdata)),
+ ),
+ file=out,
+ )
diff --git patches/patch-salt_returners_nagios_nrdp_return_py 
patches/patch-salt_returners_nagios_nrdp_return_py
new file mode 100644
index 000..a3406afa892
--- /dev/null
+++ patches/patch-salt_returners_nagios_nrdp_return_py
@@ -0,0 +1,40 @@
+$OpenBSD$
+cgi.escape has been deprecated since python 3.2 and removed in 3.8.
+
+Index: salt/returners/nagios_nrdp_return.py
+--- salt/returners/nagios_nrdp_return.py.orig
 salt/returners/nagios_nrdp_return.py
+@@ -51,7 +51,7 @@ To override individual configuration items, append --r
+ from __future__ import absolute_import, print_function, unicode_literals
+ 
+ # Import python libs
+-import cgi
++import html
+ import logging
+ 
+ import salt.ext.six.moves.http_client
+@@ -125,20 +125,20 @@ def _prepare_xml(options=None, state=None):
+ + six.text_type(options["checktype"])
+ + "'>"
+ )
+-xml += "" + cgi.escape(options["hostname"], True) + 
""
+-xml += "" + cgi.escape(options["service"], True) + 
""
++xml += "" + html.escape(options["hostname"]) + ""
++xml += "" + html.escape(options["service"]) + 
""
+ else:
+ xml += (
+ ""
+ )
+-xml += "" + cgi.escape(options["hostname"], True) + 
""
++xml += "" + 

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2020/07/09 02:15:13

Modified files:
sysutils/salt  : Makefile 
Added files:
sysutils/salt/patches: patch-salt_states_sysctl_py 

Log message:
Fix sysctl state.
OK kn, jasper

salt: fix sysctl state

[Florian Obser]

This fixes:

2020-07-09 08:38:42,136 [salt.state 
   :328 ][ERROR   ][26771] An exception occurred in this state: 
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/salt/state.py", line 2153, in 
call
ret = self.states[cdata["full"]](
  File "/usr/local/lib/python3.8/site-packages/salt/loader.py", line 2087, in 
wrapper
return f(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/salt/states/sysctl.py", line 
117, in present
update = __salt__["sysctl.persist"](name, value, config, ignore)
TypeError: persist() takes from 2 to 3 positional arguments but 4 were given


OK?

diff --git Makefile Makefile
index ea0b8d03d59..1f38fa8af70 100644
--- Makefile
+++ Makefile
@@ -19,7 +19,7 @@ COMMENT = remote execution and configuration 
management system
 
 MODPY_EGG_VERSION =3001
 DISTNAME = salt-${MODPY_EGG_VERSION}
-REVISION = 2
+REVISION = 3
 
 CATEGORIES =   sysutils net devel
 
diff --git patches/patch-salt_states_sysctl_py 
patches/patch-salt_states_sysctl_py
new file mode 100644
index 000..1f24dfbedc0
--- /dev/null
+++ patches/patch-salt_states_sysctl_py
@@ -0,0 +1,20 @@
+$OpenBSD$
+"Only run sysctl ignore when configured"
+https://github.com/saltstack/salt/pull/57841
+
+Index: salt/states/sysctl.py
+--- salt/states/sysctl.py.orig
 salt/states/sysctl.py
+@@ -114,7 +114,11 @@ def present(name, value, config=None, ignore=False):
+ return ret
+ 
+ try:
+-update = __salt__["sysctl.persist"](name, value, config, ignore)
++if ignore:
++# ignore is a linux only sysctl setting
++update = __salt__["sysctl.persist"](name, value, config, ignore)
++else:
++update = __salt__["sysctl.persist"](name, value, config)
+ except CommandExecutionError as exc:
+ ret["result"] = False
+ ret["comment"] = "Failed to set {0} to {1}: {2}".format(name, value, 
exc)


-- 
I'm not entirely sure you are real.

Re: salt & openbsd package branch names

[Florian Obser]

On Fri, May 15, 2020 at 09:49:42AM +0100, Stuart Henderson wrote:
> On 2020/05/15 08:46, Florian Obser wrote:
> > pkg_add usually does nothing. Except when a new snapshot is out, then
> > I get a new version of quirks installed.
> 
> that is expected because quirks is "always-update" (same with sqlports,
> portslist, pkglocatedb) so it's correct that it changes every time.
> 

I'm aware of that. The problem is that pkg_add is run by salt in the
first place because salt doesn't understand that nothing needs to be
done.

-- 
I'm not entirely sure you are real.

salt & openbsd package branch names

[Florian Obser]

I'm installing burp 2.1 on my systems thusly with salt:

burp-pkgs:
  pkg.installed:
- pkgs:
- burp%2.1

This works reasonably well, except that salt doesn't understand that
2.1 is already installed.  So on every highstate run it tries to
install it again.
pkg_add usually does nothing. Except when a new snapshot is out, then
I get a new version of quirks installed. This is annoying since I get
an email that salt change something.

It would also upgrade the burp package if there was a newer one and
all hell might break lose. I'd rather do my sysupgrade and pkg_add -u
when I want them, not when salt runs.

Anyway, this teaches salt about branch names, I'm running with this
for about a month now.

diff --git Makefile Makefile
index 8018247174c..55e7d9e44eb 100644
--- Makefile
+++ Makefile
@@ -19,6 +19,7 @@ COMMENT = remote execution and configuration 
management system
 
 MODPY_EGG_VERSION =3000.3
 DISTNAME = salt-${MODPY_EGG_VERSION}
+REVISION = 0
 
 CATEGORIES =   sysutils net devel
 
diff --git patches/patch-salt_states_pkg_py patches/patch-salt_states_pkg_py
new file mode 100644
index 000..f5e67b319ce
--- /dev/null
+++ patches/patch-salt_states_pkg_py
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+Index: salt/states/pkg.py
+--- salt/states/pkg.py.orig
 salt/states/pkg.py
+@@ -713,6 +713,15 @@ def _find_install_targets(name=None,
+ failed_verify = False
+ for package_name, version_string in six.iteritems(desired):
+ cver = cur_pkgs.get(package_name, [])
++if not cver and salt.utils.platform.is_openbsd():
++if "%" in package_name:
++# deal with %branch package names, e.g. python%3.7
++(stem, branch) = package_name.split("%")
++for tver in cur_pkgs.get(stem, []):
++if tver.startswith(branch):
++cver = [tver]
++break
++
+ if resolve_capabilities and not cver and package_name in cur_prov:
+ cver = cur_pkgs.get(cur_prov.get(package_name)[0], [])
+ 


-- 
I'm not entirely sure you are real.

Re: CVS: cvs.openbsd.org: ports

[Florian Obser]

Thank you!

On Fri, May 15, 2020 at 08:26:18AM +0200, Jasper Lievisse Adriaanse wrote:
> I missed this thread but I went ahead and removed the TDEP on py-msql for now 
> as the
> least invasive workaround.
> 
> Upstream’s latest release is from several years ago with a claim that python3 
> support will
> be added in the future. It seems there’s a patch in the issue tracker to 
> resolve the most
> glaring issues but I’d like to run that by the maintainer first.
> 
> Cheers,
> Jasper
> 
> > On 15 May 2020, at 08:12, Antoine Jacoutot  wrote:
> > 
> > On Fri, May 15, 2020 at 08:07:08AM +0200, Florian Obser wrote:
> >> On Fri, May 15, 2020 at 07:52:10AM +0200, Antoine Jacoutot wrote:
> >>> On Thu, May 14, 2020 at 10:47:28AM -0600, Florian Obser wrote:
> >>>> CVSROOT: /cvs
> >>>> Module name: ports
> >>>> Changes by:  flor...@cvs.openbsd.org 2020/05/14 10:47:28
> >>>> 
> >>>> Modified files:
> >>>>  sysutils/salt  : Makefile distinfo 
> >>>>  sysutils/salt/patches: patch-salt_modules_salt_proxy_py 
> >>>> patch-salt_returners_zabbix_return_py 
> >>>>  sysutils/salt/pkg: PLIST 
> >>>> Added files:
> >>>>  sysutils/salt/patches: patch-requirements_crypto_txt 
> >>>> patch-salt_utils_network_py 
> >>>> Removed files:
> >>>>  sysutils/salt/files: pf.py vmctl.py 
> >>>>  sysutils/salt/patches: patch-salt_master_py 
> >>>> patch-salt_modules_openbsd_sysctl_py 
> >>>> patch-salt_modules_openbsdpkg_py 
> >>>> patch-salt_tokens_localfs_py 
> >>>> patch-salt_utils_gitfs_py 
> >>>> patch-salt_utils_verify_py 
> >>>> patch-salt_wheel_config_py 
> >>>> patch-salt_wheel_file_roots_py 
> >>>> 
> >>>> Log message:
> >>>> Update to salt stack 3000.3.
> >>>> 
> >>>> All the heavy lifting for updating from 2018.3 to 3000.1 by robert.
> >>>> Trivial rebasing & updating to 3000.1 -> 3000.3 by me.
> >>>> "Please commit" robert
> >>>> OK robert, jasper
> >>> 
> >>> This breaks databases/sqlports because databases/py-mysql,python3 does not
> >>> exist.
> >>> Please revert or add a python3 FLAVOR to databases/py-mysql.
> >>> 
> >>> Thanks.
> >>> 
> >>> -- 
> >>> Antoine
> >> 
> >> Argh, sorry about that. I swear I will never ever commit to ports
> >> again (after fixing this).
> >> 
> >> Now, I'm not entirely sure how to revert since the version number then
> >> moves backwards. Also I'm not sure about the right cvs incantation...
> > 
> > Moving backwards would me increasing EPOCH (or set it to 0 in your case).
> > 
> >> Anyway, since py-mysql is "only" used for tests, would this be an
> >> acceptable stop-gap?
> > 
> > Sure, that's fine with me :-)
> > OK
> > 
> >> 
> >> diff --git Makefile Makefile
> >> index 8018247174c..02ec0e13596 100644
> >> --- Makefile
> >> +++ Makefile
> >> @@ -19,6 +19,7 @@ COMMENT =remote execution and 
> >> configuration management system
> >> 
> >> MODPY_EGG_VERSION =3000.3
> >> DISTNAME = salt-${MODPY_EGG_VERSION}
> >> +REVISION =0
> >> 
> >> CATEGORIES =   sysutils net devel
> >> 
> >> @@ -57,19 +58,20 @@ RUN_DEPENDS += 
> >> devel/py-progressbar${MODPY_FLAVOR}
> >> RUN_DEPENDS += security/py-M2Crypto${MODPY_FLAVOR}
> >> 
> >> # max openfiles, soft: 3072, hard: 4096; DBus system session running...
> >> -TEST_IS_INTERACTIVE = Yes
> >> -PORTHOME =${WRKDIST}
> >> -TEST_DEPENDS =databases/py-mysql${MODPY_FLAVOR} \
> >> -  devel/git \
> >> -  devel/py-gitpython${MODPY_FLAVOR} \
> >> -  devel/py-pip${MODPY_FLAVOR} \
> >> -  devel/py-six${MODPY_FLAVOR} \
> >> -  devel/py-virtualenv${MODPY_FLAVOR} \
> >> -  devel/subversion \
> >> -  net/py-libcloud

Re: CVS: cvs.openbsd.org: ports

[Florian Obser]

On Fri, May 15, 2020 at 07:52:10AM +0200, Antoine Jacoutot wrote:
> On Thu, May 14, 2020 at 10:47:28AM -0600, Florian Obser wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: flor...@cvs.openbsd.org 2020/05/14 10:47:28
> > 
> > Modified files:
> > sysutils/salt  : Makefile distinfo 
> > sysutils/salt/patches: patch-salt_modules_salt_proxy_py 
> >patch-salt_returners_zabbix_return_py 
> > sysutils/salt/pkg: PLIST 
> > Added files:
> > sysutils/salt/patches: patch-requirements_crypto_txt 
> >patch-salt_utils_network_py 
> > Removed files:
> > sysutils/salt/files: pf.py vmctl.py 
> > sysutils/salt/patches: patch-salt_master_py 
> >patch-salt_modules_openbsd_sysctl_py 
> >patch-salt_modules_openbsdpkg_py 
> >patch-salt_tokens_localfs_py 
> >patch-salt_utils_gitfs_py 
> >patch-salt_utils_verify_py 
> >patch-salt_wheel_config_py 
> >patch-salt_wheel_file_roots_py 
> > 
> > Log message:
> > Update to salt stack 3000.3.
> > 
> > All the heavy lifting for updating from 2018.3 to 3000.1 by robert.
> > Trivial rebasing & updating to 3000.1 -> 3000.3 by me.
> > "Please commit" robert
> > OK robert, jasper
> 
> This breaks databases/sqlports because databases/py-mysql,python3 does not
> exist.
> Please revert or add a python3 FLAVOR to databases/py-mysql.
> 
> Thanks.
> 
> -- 
> Antoine

Argh, sorry about that. I swear I will never ever commit to ports
again (after fixing this).

Now, I'm not entirely sure how to revert since the version number then
moves backwards. Also I'm not sure about the right cvs incantation...

Anyway, since py-mysql is "only" used for tests, would this be an
acceptable stop-gap?

diff --git Makefile Makefile
index 8018247174c..02ec0e13596 100644
--- Makefile
+++ Makefile
@@ -19,6 +19,7 @@ COMMENT = remote execution and configuration 
management system
 
 MODPY_EGG_VERSION =3000.3
 DISTNAME = salt-${MODPY_EGG_VERSION}
+REVISION = 0
 
 CATEGORIES =   sysutils net devel
 
@@ -57,19 +58,20 @@ RUN_DEPENDS +=  
devel/py-progressbar${MODPY_FLAVOR}
 RUN_DEPENDS += security/py-M2Crypto${MODPY_FLAVOR}
 
 # max openfiles, soft: 3072, hard: 4096; DBus system session running...
-TEST_IS_INTERACTIVE =  Yes
-PORTHOME = ${WRKDIST}
-TEST_DEPENDS = databases/py-mysql${MODPY_FLAVOR} \
-   devel/git \
-   devel/py-gitpython${MODPY_FLAVOR} \
-   devel/py-pip${MODPY_FLAVOR} \
-   devel/py-six${MODPY_FLAVOR} \
-   devel/py-virtualenv${MODPY_FLAVOR} \
-   devel/subversion \
-   net/py-libcloud${MODPY_FLAVOR} \
-   net/rabbitmq \
-   sysutils/salt-testing \
-   www/py-CherryPy${MODPY_FLAVOR}
+# XXX needs py-mysql python3 flavour
+#TEST_IS_INTERACTIVE = Yes
+#PORTHOME =${WRKDIST}
+#TEST_DEPENDS =databases/py-mysql${MODPY_FLAVOR} \
+#  devel/git \
+#  devel/py-gitpython${MODPY_FLAVOR} \
+#  devel/py-pip${MODPY_FLAVOR} \
+#  devel/py-six${MODPY_FLAVOR} \
+#  devel/py-virtualenv${MODPY_FLAVOR} \
+#  devel/subversion \
+#  net/py-libcloud${MODPY_FLAVOR} \
+#  net/rabbitmq \
+#  sysutils/salt-testing \
+#  www/py-CherryPy${MODPY_FLAVOR}
 
 pre-configure:
${SUBST_CMD} ${WRKSRC}/salt/returners/zabbix_return.py


-- 
I'm not entirely sure you are real.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2020/05/14 10:47:28

Modified files:
sysutils/salt  : Makefile distinfo 
sysutils/salt/patches: patch-salt_modules_salt_proxy_py 
   patch-salt_returners_zabbix_return_py 
sysutils/salt/pkg: PLIST 
Added files:
sysutils/salt/patches: patch-requirements_crypto_txt 
   patch-salt_utils_network_py 
Removed files:
sysutils/salt/files: pf.py vmctl.py 
sysutils/salt/patches: patch-salt_master_py 
   patch-salt_modules_openbsd_sysctl_py 
   patch-salt_modules_openbsdpkg_py 
   patch-salt_tokens_localfs_py 
   patch-salt_utils_gitfs_py 
   patch-salt_utils_verify_py 
   patch-salt_wheel_config_py 
   patch-salt_wheel_file_roots_py 

Log message:
Update to salt stack 3000.3.

All the heavy lifting for updating from 2018.3 to 3000.1 by robert.
Trivial rebasing & updating to 3000.1 -> 3000.3 by me.
"Please commit" robert
OK robert, jasper

Re: opensmtpd-extras -main & python 2.7

[Florian Obser]

works for me, but I'm only using the -main package and only the passwd
table from that.

Thanks,
Florian

On Sat, Apr 18, 2020 at 10:21:29PM +0200, Giovanni Bechis wrote:
> On Sat, Apr 18, 2020 at 01:38:20AM +0200, Klemens Nanni wrote:
> > On Sat, Apr 18, 2020 at 01:34:47AM +0200, Joerg Jung wrote:
> > > thanks, but please hold-off for a second, as giovanni is already going
> > > to commit a diff to upgrade to latest release 6.7.0 better he merges
> > > the line then into his diff instead of the revision bumps, I believe ...
> > Go ahead with whatever seems fit;  I don't use this port, just wanted to
> > help out florian.
> > 
> diff to 6.7.1 with kn@ fix.
> ok ?
>  Cheers
>   Giovanni
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/opensmtpd-extras/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- Makefile  26 Dec 2019 11:19:28 -  1.32
> +++ Makefile  18 Apr 2020 20:19:21 -
> @@ -6,14 +6,13 @@ COMMENT-pgsql=  postgresql based smtpd t
>  COMMENT-python=  extras with python bindings for smtpd
>  COMMENT-redis=   redis based smtpd table support
>  
> -V=   6.6.0
> +V=   6.7.1
>  DISTNAME=opensmtpd-extras-${V}
>  PKGNAME-main=${DISTNAME}
>  PKGNAME-mysql=   opensmtpd-extras-mysql-${V}
>  PKGNAME-pgsql=   opensmtpd-extras-pgsql-${V}
>  PKGNAME-python=  opensmtpd-extras-python-${V}
>  PKGNAME-redis=   opensmtpd-extras-redis-${V}
> -REVISION=2
>  EPOCH=   0
>  
>  CATEGORIES=  mail
> @@ -36,9 +35,8 @@ WANTLIB-redis=  c crypto event ssl hired
>  
>  MASTER_SITES=${HOMEPAGE}archives/
>  
> -WRKSRC=  ${WRKDIR}/OpenSMTPD-extras-${V}
> -
>  MODULES= lang/python
> +MODPY_RUNDEP=no
>  
>  LIB_DEPENDS-main=databases/sqlite3
>  LIB_DEPENDS-mysql=   databases/mariadb,-main
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/opensmtpd-extras/distinfo,v
> retrieving revision 1.17
> diff -u -p -r1.17 distinfo
> --- distinfo  22 Dec 2019 12:19:20 -  1.17
> +++ distinfo  18 Apr 2020 20:19:21 -
> @@ -1,2 +1,2 @@
> -SHA256 (opensmtpd-extras-6.6.0.tar.gz) = 
> EmsCNgLouyIr8kVDoFbuClSDQ9yG0YRmn/nYLfyh+98=
> -SIZE (opensmtpd-extras-6.6.0.tar.gz) = 124234
> +SHA256 (opensmtpd-extras-6.7.1.tar.gz) = 
> +EOFVZqLs2ay/iXYsfeMEI8HzBWZI1AXFWnXvcLpNaw=
> +SIZE (opensmtpd-extras-6.7.1.tar.gz) = 548792



-- 
I'm not entirely sure you are real.

Re: opensmtpd-extras -main & python 2.7

[Florian Obser]

On Sat, Apr 18, 2020 at 01:38:20AM +0200, Klemens Nanni wrote:
> On Sat, Apr 18, 2020 at 01:34:47AM +0200, Joerg Jung wrote:
> > thanks, but please hold-off for a second, as giovanni is already going
> > to commit a diff to upgrade to latest release 6.7.0 better he merges
> > the line then into his diff instead of the revision bumps, I believe ...
> Go ahead with whatever seems fit;  I don't use this port, just wanted to
> help out florian.
> 

Thanks,
after Klemens' hint I came up with the same diff (but went for the big
revision hammer). It works fine for the -main port. I'm not using the
others.

Florian

-- 
I'm not entirely sure you are real.

opensmtpd-extras -main & python 2.7

[Florian Obser]

Hi,

with Robert's awesome work of updating salt and switching it to
python3 nearly all my servers are python2 free.

Except for one where I have opensmtpd-extras installed:

$ cat /var/db/pkg/python-2.7.17p1/+REQUIRED_BY
opensmtpd-extras-6.6.0p2v0

Note that this is not the -python flavour.

I stared at the ports makefile and can't figure this out.

Any hints would be appreciated.

Thanks,
Florian

-- 
I'm not entirely sure you are real.

Re: py-git2 & salt

[Florian Obser]

On Tue, Apr 14, 2020 at 11:43:59AM +0100, Raf Czlonka wrote:
> It was also me who has sent the quirks diff as py-git2 is now
> Python3-only so there wasn't much point in delaying this as, Salt
> with Git users, we're probably in minority of pygit2 consumers.

Yep, thanks for this. This would have blown up in my face sooner or
later and so much harder to debug. Probably with a lib bump.

> 
> The couple of ways out of this that I can see is either to move to
> using py-GitPython or moving Salt to Python3 (post-6.7 obviously)
> - preferably the latter.

That would be nice. Unfortunately I'm not smart enough to work on
ports. Heck, I can't even compile ports anymore :(

> 
> Regards,
> 
> Raf

-- 
I'm not entirely sure you are real.

py-git2 & salt

[Florian Obser]

FYI, today I updated my salt master from

OpenBSD 6.6-current (GENERIC.MP) #55: Sun Mar 15 02:21:01 MDT 2020

OpenBSD 6.7-beta (GENERIC.MP) #127: Mon Apr 13 21:22:35 MDT 2020

and due to a commit to quirks I got this: 

py-git2-0.28.2->py3-git2-1.0.1p1: ok

salt master is now of course failing:

2020-04-14 09:52:00,947 [salt.utils.gitfs :2541][ERROR  
 ][62659] gitfs is configured but could not be loaded, are pygit2 and libgit2 
installed?
2020-04-14 09:52:00,953 [salt.utils.gitfs 
:2478][CRITICAL][62659] No suitable gitfs provider module is installed.
2020-04-14 09:52:00,989 [salt.loader  :1698][ERROR  
 ][62659] Failed to load function git.envs because its module (git) is not in 
the whitelist: [u'gitfs']
2020-04-14 09:52:00,994 [salt.utils.gitfs 
:2478][CRITICAL][62659] No suitable git_pillar provider module is installed.
2020-04-14 09:52:00,995 [salt.master  :626 
][CRITICAL][62659] Failed to load git_pillar
2020-04-14 09:52:00,996 [salt.master  :627 
][CRITICAL][62659] Master failed pre flight checks, exiting

Turns out py-git2 was updated by jasper@ last year in December but due
to the missing quirks commit (recently done by kn@) I still had an old
package lying around that never got updated.

As a shortterm solution I will investigate how to move away from git.

Longterm I'll probably move away from salt. It causes more trouble
than solving problems.

Thanks,
Florian


-- 
I'm not entirely sure you are real.

Re: py-msgpack 1.0.0 upgrade broke salt

[Florian Obser]

FWIW this one works for me, pkg_add also sees it as an updated.
Thanks,
Florian

On Tue, Mar 10, 2020 at 10:45:08PM +0100, Florian Obser wrote:
> I don't have an opinion on how best to fix this, so don't wait on me ;)
> 
> On 10 March 2020 21:28:42 CET, Bjorn Ketelaars  wrote:
> >On Tue 10/03/2020 19:49, Florian Obser wrote:
> >> The release notes have
> >> 
> >> * Remove encoding option from the Packer and Unpacker.
> >> 
> >> ( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst
> >)
> >> 
> >> $ doas salt-minion  
> >> 
> >
> >I discussed py-msgpack offlist with another user who needed
> >py-msgpack-1.0.0 for an update of a vim plugin. Although the update of
> >py-msgpack has been tested this issue has not been seen.
> >
> >It seems that upstream of salt is still working on a solution [0]. Easy
> >fix therefore is to revert py-msgpack to 0.6.2, and bump its consumers.
> >Downside of course would be that specific vim plugins will start
> >complaining.
> >
> >I had a look at the consumers of py-msgpack, which we have in ports.
> >All of them seem happy with py-msgpack-0.6.2. None of them, except
> >net/synapse, received an update recently. synapse relies on
> >msgpack>=0.5.2 [1]:
> >
> >  RUN_DEPENDS
> >/usr/ports/devel/py-test-expect
> >/usr/ports/devel/py-test-expect,python3
> >/usr/ports/editors/py-neovim
> >/usr/ports/editors/py-neovim,python3
> >/usr/ports/net/synapse
> >/usr/ports/sysutils/salt
> >  TEST_DEPENDS
> >/usr/ports/editors/py-neovim
> >/usr/ports/editors/py-neovim,python3
> >/usr/ports/net/synapse
> >/usr/ports/sysutils/salt
> >
> >Different route would be to support two versions of py-msgpack. For now
> >I propose to make sure that all ports work, thus revert. I will take a
> >look at the alternative route in the near future.
> >
> >Comments/OK?
> >
> >[0] https://github.com/saltstack/salt/issues/56007
> >[1]
> >https://github.com/matrix-org/synapse/blob/master/synapse/python_dependencies.py
> >
> >
> >diff --git devel/py-test-expect/Makefile devel/py-test-expect/Makefile
> >index f19faf3d50b..0768ce54782 100644
> >--- devel/py-test-expect/Makefile
> >+++ devel/py-test-expect/Makefile
> >@@ -6,7 +6,7 @@ MODPY_EGG_VERSION =  1.1.0
> > DISTNAME =  pytest-expect-${MODPY_EGG_VERSION}
> > PKGNAME =   ${DISTNAME:S/py/py-/}
> > CATEGORIES =devel
> >-REVISION =  1
> >+REVISION =  2
> > 
> > HOMEPAGE =  https://github.com/gsnedders/pytest-expect
> > 
> >diff --git editors/py-neovim/Makefile editors/py-neovim/Makefile
> >index ef30c889738..185624959d5 100644
> >--- editors/py-neovim/Makefile
> >+++ editors/py-neovim/Makefile
> >@@ -3,6 +3,7 @@
> > COMMENT =   Python plugin support for Neovim
> > 
> > MODPY_EGG_VERSION = 0.4.0
> >+REVISION =  0
> > DISTNAME =  pynvim-${MODPY_EGG_VERSION}
> > PKGNAME =   py-neovim-${MODPY_EGG_VERSION}
> > 
> >diff --git net/py-msgpack/Makefile net/py-msgpack/Makefile
> >index ea82fc3e07a..c06d478b9de 100644
> >--- net/py-msgpack/Makefile
> >+++ net/py-msgpack/Makefile
> >@@ -2,7 +2,8 @@
> > 
> > COMMENT =   messagepack (de)serializer
> > 
> >-MODPY_EGG_VERSION = 1.0.0
> >+MODPY_EGG_VERSION = 0.6.2
> >+EPOCH = 0
> > DISTNAME =  msgpack-${MODPY_EGG_VERSION}
> > PKGNAME =   py-msgpack-${MODPY_EGG_VERSION}
> > 
> >diff --git net/py-msgpack/distinfo net/py-msgpack/distinfo
> >index 5ec380d7403..8d9bdadf9d3 100644
> >--- net/py-msgpack/distinfo
> >+++ net/py-msgpack/distinfo
> >@@ -1,2 +1,2 @@
> >-SHA256 (msgpack-1.0.0.tar.gz) =
> >lTTVzEgNSv9yAjNBGh92W+kIhXULB993I4CzTBDstcA=
> >-SIZE (msgpack-1.0.0.tar.gz) = 232331
> >+SHA256 (msgpack-0.6.2.tar.gz) =
> >6jwvhZNG/NVfxG6WiFMB2cL3o21FP12PKWeEDvoeGDA=
> >+SIZE (msgpack-0.6.2.tar.gz) = 119062
> >diff --git net/py-msgpack/pkg/PLIST net/py-msgpack/pkg/PLIST
> >index 7d948a0df47..2f24d170108 100644
> >--- net/py-msgpack/pkg/PLIST
> >+++ net/py-msgpack/pkg/PLIST
> >@@ -10,10 +10,8 @@
> >${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE
> >lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
> >lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
> >lib/py

Re: py-msgpack 1.0.0 upgrade broke salt

[Florian Obser]

I don't have an opinion on how best to fix this, so don't wait on me ;)

On 10 March 2020 21:28:42 CET, Bjorn Ketelaars  wrote:
>On Tue 10/03/2020 19:49, Florian Obser wrote:
>> The release notes have
>> 
>> * Remove encoding option from the Packer and Unpacker.
>> 
>> ( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst
>)
>> 
>> $ doas salt-minion  
>> 
>
>I discussed py-msgpack offlist with another user who needed
>py-msgpack-1.0.0 for an update of a vim plugin. Although the update of
>py-msgpack has been tested this issue has not been seen.
>
>It seems that upstream of salt is still working on a solution [0]. Easy
>fix therefore is to revert py-msgpack to 0.6.2, and bump its consumers.
>Downside of course would be that specific vim plugins will start
>complaining.
>
>I had a look at the consumers of py-msgpack, which we have in ports.
>All of them seem happy with py-msgpack-0.6.2. None of them, except
>net/synapse, received an update recently. synapse relies on
>msgpack>=0.5.2 [1]:
>
>  RUN_DEPENDS
>/usr/ports/devel/py-test-expect
>/usr/ports/devel/py-test-expect,python3
>/usr/ports/editors/py-neovim
>/usr/ports/editors/py-neovim,python3
>/usr/ports/net/synapse
>/usr/ports/sysutils/salt
>  TEST_DEPENDS
>/usr/ports/editors/py-neovim
>/usr/ports/editors/py-neovim,python3
>/usr/ports/net/synapse
>/usr/ports/sysutils/salt
>
>Different route would be to support two versions of py-msgpack. For now
>I propose to make sure that all ports work, thus revert. I will take a
>look at the alternative route in the near future.
>
>Comments/OK?
>
>[0] https://github.com/saltstack/salt/issues/56007
>[1]
>https://github.com/matrix-org/synapse/blob/master/synapse/python_dependencies.py
>
>
>diff --git devel/py-test-expect/Makefile devel/py-test-expect/Makefile
>index f19faf3d50b..0768ce54782 100644
>--- devel/py-test-expect/Makefile
>+++ devel/py-test-expect/Makefile
>@@ -6,7 +6,7 @@ MODPY_EGG_VERSION =1.1.0
> DISTNAME =pytest-expect-${MODPY_EGG_VERSION}
> PKGNAME = ${DISTNAME:S/py/py-/}
> CATEGORIES =  devel
>-REVISION =1
>+REVISION =2
> 
> HOMEPAGE =https://github.com/gsnedders/pytest-expect
> 
>diff --git editors/py-neovim/Makefile editors/py-neovim/Makefile
>index ef30c889738..185624959d5 100644
>--- editors/py-neovim/Makefile
>+++ editors/py-neovim/Makefile
>@@ -3,6 +3,7 @@
> COMMENT = Python plugin support for Neovim
> 
> MODPY_EGG_VERSION =   0.4.0
>+REVISION =0
> DISTNAME =pynvim-${MODPY_EGG_VERSION}
> PKGNAME = py-neovim-${MODPY_EGG_VERSION}
> 
>diff --git net/py-msgpack/Makefile net/py-msgpack/Makefile
>index ea82fc3e07a..c06d478b9de 100644
>--- net/py-msgpack/Makefile
>+++ net/py-msgpack/Makefile
>@@ -2,7 +2,8 @@
> 
> COMMENT = messagepack (de)serializer
> 
>-MODPY_EGG_VERSION =   1.0.0
>+MODPY_EGG_VERSION =   0.6.2
>+EPOCH =   0
> DISTNAME =msgpack-${MODPY_EGG_VERSION}
> PKGNAME = py-msgpack-${MODPY_EGG_VERSION}
> 
>diff --git net/py-msgpack/distinfo net/py-msgpack/distinfo
>index 5ec380d7403..8d9bdadf9d3 100644
>--- net/py-msgpack/distinfo
>+++ net/py-msgpack/distinfo
>@@ -1,2 +1,2 @@
>-SHA256 (msgpack-1.0.0.tar.gz) =
>lTTVzEgNSv9yAjNBGh92W+kIhXULB993I4CzTBDstcA=
>-SIZE (msgpack-1.0.0.tar.gz) = 232331
>+SHA256 (msgpack-0.6.2.tar.gz) =
>6jwvhZNG/NVfxG6WiFMB2cL3o21FP12PKWeEDvoeGDA=
>+SIZE (msgpack-0.6.2.tar.gz) = 119062
>diff --git net/py-msgpack/pkg/PLIST net/py-msgpack/pkg/PLIST
>index 7d948a0df47..2f24d170108 100644
>--- net/py-msgpack/pkg/PLIST
>+++ net/py-msgpack/pkg/PLIST
>@@ -10,10 +10,8 @@
>${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}exceptions.${MODPY_PYC_MAGIC_TAG}pyc
>-lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}ext.${MODPY_PYC_MAGIC_TAG}pyc
>lib/python${MODPY_VERSION}/site-packages/msgpack/${MODPY_PYCACHE}fallback.${MODPY_PYC_MAGIC_TAG}pyc
>-${MODPY_COMMENT}@so
>lib/python${MODPY_VERSION}/site-packages/msgpack/_cmsgpack.so
>+@so lib/python${MODPY_VERSION}/site-packages/msgpack/_cmsgpack.so
> lib/python${MODPY_VERSION}/site-packages/msgpack/_version.py
> lib/python${MODPY_VERSION}/site-packages/msgpack/exceptions.py
>-lib/python${MODPY_VERSION}/site-packages/msgpack/ext.py
> lib

py-msgpack 1.0.0 upgrade broke salt

[Florian Obser]

The release notes have

* Remove encoding option from the Packer and Unpacker.

( https://github.com/msgpack/msgpack-python/blob/v1.0.0/ChangeLog.rst )

$ doas salt-minion  

Process Process-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/multiprocessing/process.py", line 267, in 
_bootstrap
self.run()
  File "/usr/local/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python2.7/site-packages/salt/scripts.py", line 146, in 
minion_process
minion.start()
  File "/usr/local/lib/python2.7/site-packages/salt/cli/daemons.py", line 348, 
in start
self.minion.tune_in()
  File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 1026, in 
tune_in
self._bind()
  File "/usr/local/lib/python2.7/site-packages/salt/minion.py", line 940, in 
_bind
self.event = salt.utils.event.get_event('minion', opts=self.opts, 
io_loop=self.io_loop)
  File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line 143, 
in get_event
raise_errors=raise_errors)
  File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line 271, 
in __init__
self.connect_pub()
  File "/usr/local/lib/python2.7/site-packages/salt/utils/event.py", line 383, 
in connect_pub
io_loop=self.io_loop
  File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line 
257, in __new__
client.__singleton_init__(io_loop=io_loop, socket_path=socket_path)
  File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line 
620, in __singleton_init__
socket_path, io_loop=io_loop)
  File "/usr/local/lib/python2.7/site-packages/salt/transport/ipc.py", line 
280, in __singleton_init__
self.unpacker = msgpack.Unpacker(encoding=encoding)
TypeError: __init__() got an unexpected keyword argument 'encoding'

Thanks,
Florian

-- 
I'm not entirely sure you are real.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2020/02/09 02:38:45

Modified files:
databases/postgresql: Makefile 
databases/postgresql/pkg: README-server 

Log message:
Add "cd /var/postgresql" to upgrade instructions so that pg_dumpall
and initdb work even if the current working directory is not
accessible by the _postgresql user.
OK kn, jeremy, pea

Re: postgres: improve upgrade notes slightly

[Florian Obser]

I suck at ports, sorry.
This one probably bumps revision correctly.

diff --git Makefile Makefile
index 8cd12215710..bedd120acd5 100644
--- Makefile
+++ Makefile
@@ -16,7 +16,7 @@ PKGNAME-docs= postgresql-docs-${VERSION}
 PKGNAME-contrib=postgresql-contrib-${VERSION}
 PKGNAME-plpython=postgresql-plpython-${VERSION}
 PKGNAME-pg_upgrade=postgresql-pg_upgrade-${VERSION}
-
+REVISION-server=0
 
 CATEGORIES=databases
 SHARED_LIBS=   ecpg7.10 \
diff --git pkg/README-server pkg/README-server
index 7fa6fef048a..92ef8c3f149 100644
--- pkg/README-server
+++ pkg/README-server
@@ -107,7 +107,8 @@ This will work for any upgrade from any major version of 
PostgreSQL
 to the current version.
 
 1) Backup all your data:
-# su _postgresql -c "pg_dumpall -U postgres > /var/postgresql/full.sqldump"
+# su _postgresql -c "cd /var/postgresql && \
+pg_dumpall -U postgres > /var/postgresql/full.sqldump"
 
 2) Shutdown the server:
 # rcctl stop postgresql
@@ -120,8 +121,8 @@ to the current version.
 
 5) Create a new data directory:
 # su _postgresql -c "mkdir /var/postgresql/data"
-# su _postgresql -c \
-"initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W"
+# su _postgresql -c "cd /var/postgresql && \
+initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W"
 
 6) Restore your old pg_hba.conf and (if used) SSL certificates
 # su _postgresql -c \
@@ -136,7 +137,8 @@ Examine your old file for local changes and apply them to 
the new version.
 # rcctl start postgresql
 
 8) Restore your data:
-# su _postgresql -c "psql -U postgres < /var/postgresql/full.sqldump"
+# su _postgresql -c "cd /var/postgresql && \
+psql -U postgres < /var/postgresql/full.sqldump"
 
 Option 2: pg_upgrade
 
@@ -155,7 +157,7 @@ faster than a dump and reload, especially for large 
databases.
 # mv /var/postgresql/data /var/postgresql/data-${PREV_MAJOR}
 
 4) Create a new data directory:
-# su _postgresql -c "mkdir /var/postgresql/data; \
+# su _postgresql -c "mkdir /var/postgresql/data && cd /var/postgresql && \
 initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W"
 
 (The database environment defaults to UTF-8 if your terminal is already


-- 
I'm not entirely sure you are real.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2020/02/08 09:35:25

Modified files:
net/monitoring-plugins: Makefile 

Log message:
oops, correctly bump revision

postgres: improve upgrade notes slightly

[Florian Obser]

Today I successfully upgraded postgres from 11 to 12 using the
pg_upgrade method.  It went flawelessly, thanks!

I noticed that pg_dumpall and initdb like to examine the current
working directory, for example with current working directory /root:

# su _postgresql -c "pg_dumpall -U postgres > /var/postgresql/full.sqldump"
could not identify current directory: Permission denied
Password for user postgres: 
could not identify current directory: Permission denied
psql: fatal: could not find own program executable

We already have c commands that cd /var/postgresql, this adds it for
the remaining ones where it seems important.

OK?

diff --git Makefile Makefile
index 8cd12215710..11b9abe7daf 100644
--- Makefile
+++ Makefile
@@ -16,7 +16,7 @@ PKGNAME-docs= postgresql-docs-${VERSION}
 PKGNAME-contrib=postgresql-contrib-${VERSION}
 PKGNAME-plpython=postgresql-plpython-${VERSION}
 PKGNAME-pg_upgrade=postgresql-pg_upgrade-${VERSION}
-
+REVISION-main= 0
 
 CATEGORIES=databases
 SHARED_LIBS=   ecpg7.10 \
diff --git pkg/README-server pkg/README-server
index 7fa6fef048a..92ef8c3f149 100644
--- pkg/README-server
+++ pkg/README-server
@@ -107,7 +107,8 @@ This will work for any upgrade from any major version of 
PostgreSQL
 to the current version.
 
 1) Backup all your data:
-# su _postgresql -c "pg_dumpall -U postgres > /var/postgresql/full.sqldump"
+# su _postgresql -c "cd /var/postgresql && \
+pg_dumpall -U postgres > /var/postgresql/full.sqldump"
 
 2) Shutdown the server:
 # rcctl stop postgresql
@@ -120,8 +121,8 @@ to the current version.
 
 5) Create a new data directory:
 # su _postgresql -c "mkdir /var/postgresql/data"
-# su _postgresql -c \
-"initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W"
+# su _postgresql -c "cd /var/postgresql && \
+initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W"
 
 6) Restore your old pg_hba.conf and (if used) SSL certificates
 # su _postgresql -c \
@@ -136,7 +137,8 @@ Examine your old file for local changes and apply them to 
the new version.
 # rcctl start postgresql
 
 8) Restore your data:
-# su _postgresql -c "psql -U postgres < /var/postgresql/full.sqldump"
+# su _postgresql -c "cd /var/postgresql && \
+psql -U postgres < /var/postgresql/full.sqldump"
 
 Option 2: pg_upgrade
 
@@ -155,7 +157,7 @@ faster than a dump and reload, especially for large 
databases.
 # mv /var/postgresql/data /var/postgresql/data-${PREV_MAJOR}
 
 4) Create a new data directory:
-# su _postgresql -c "mkdir /var/postgresql/data; \
+# su _postgresql -c "mkdir /var/postgresql/data && cd /var/postgresql && \
 initdb -D /var/postgresql/data -U postgres -A scram-sha-256 -E UTF8 -W"
 
 (The database environment defaults to UTF-8 if your terminal is already


-- 
I'm not entirely sure you are real.

CVS: cvs.openbsd.org: ports

[Florian Obser]

CVSROOT:/cvs
Module name:ports
Changes by: flor...@cvs.openbsd.org 2020/02/08 03:53:08

Modified files:
net/monitoring-plugins: Makefile 

Log message:
dig and nslookup moved to /usr/bin
OK sthen

Re: [Update] mail/opensmtpd-filters/rspamd

[Florian Obser]

On Sat, Sep 28, 2019 at 07:46:16PM +0200, Florian Obser wrote:
> On Sat, Sep 28, 2019 at 08:18:57AM +, gil...@poolp.org wrote:
> > Hello,
> > 
> > The following diff updates filter-rspamd to 0.1.3:
> > 
> > - fixes a concurrency-related crash which has been observed by patrick@ and 
> > otto@
> > - adds X-Spam-Symbols which was requested by florian@
> 
> Requested it such a strong word. I completely missed how all this
> stuff interconnects. I thougt rspamd itself adds those headers. ;)
> 
> Thank you very much. Unfortunately I haven't gotten any spam yet, the
> rdns filters are just too good :D so I can't tell if it actually works.

nd I got some spam and happy to report that it works:

(I fiddled around with the score values, my rspamd never rejects, but
this is quite an impressively high score)

X-Spam: yes
X-Spam-Score: 39.95 / 6
X-Spam-Symbols: R_SPF_SOFTFAIL,
 RCPT_COUNT_ONE,
 FROM_EQ_ENVFROM,
 ARC_NA,
 RBL_BLOCKLISTDE,
 RBL_SPAMHAUS_XBL_ANY,
 RCVD_NO_TLS_LAST,
 R_DKIM_NA,
 TO_MATCH_ENVRCPT_ALL,
 REPLYTO_EQ_FROM,
 HFILTER_HOSTNAME_5,
 TO_DN_NONE,
 SEM_URIBL,
 VIOLATED_DIRECT_SPF,
 FREEMAIL_REPLYTO,
 MIME_TRACE,
 RECEIVED_BLOCKLISTDE,
 HAS_REPLYTO,
 FREEMAIL_ENVFROM,
 FROM_HAS_DN,
 RBL_SPAMHAUS_CSS,
 RSPAMD_URIBL,
 HTML_SHORT_LINK_IMG_1,
 RECEIVED_SPAMHAUS_CSS,
 MID_RHS_MATCH_FROM,
 PREVIOUSLY_DELIVERED,
 URIBL_SBL,
 URIBL_BLACK,
 FREEMAIL_FROM,
 DBL_SPAM,
 FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN,
 DMARC_POLICY_SOFTFAIL,
 RCVD_COUNT_THREE,
 ASN,
 RBL_SENDERSCORE,
 RECEIVED_SPAMHAUS_PBL,
 MANY_INVISIBLE_PARTS,
 MIME_HTML_ONLY

-- 
I'm not entirely sure you are real.

Re: [Update] mail/opensmtpd-filters/rspamd

[Florian Obser]

On Sat, Sep 28, 2019 at 08:18:57AM +, gil...@poolp.org wrote:
> Hello,
> 
> The following diff updates filter-rspamd to 0.1.3:
> 
> - fixes a concurrency-related crash which has been observed by patrick@ and 
> otto@
> - adds X-Spam-Symbols which was requested by florian@

Requested it such a strong word. I completely missed how all this
stuff interconnects. I thougt rspamd itself adds those headers. ;)

Thank you very much. Unfortunately I haven't gotten any spam yet, the
rdns filters are just too good :D so I can't tell if it actually works.

> - adds support for Rspamd headers addition / removals
> 
> ok ?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/opensmtpd-filters/rspamd/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- Makefile 20 Sep 2019 16:41:53 - 1.2
> +++ Makefile 28 Sep 2019 08:15:01 -
> @@ -2,7 +2,7 @@
> 
> COMMENT = rspamd integration to the OpenSMTPD daemon

the diff is mangled and didn't apply, space vs tab in this line ^

OK florian fwiw

> 
> -V = 0.1.2
> +V = 0.1.3
> FILTER_NAME = rspamd
> DISTNAME = filter-rspamd-${V}
> 
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/opensmtpd-filters/rspamd/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo 20 Sep 2019 16:41:53 - 1.2
> +++ distinfo 28 Sep 2019 08:15:01 -
> @@ -1,2 +1,2 @@
> -SHA256 (filter-rspamd-0.1.2.tar.gz) = 
> CD/0T2Bt0NrLdnEvOgGWCdkZHA6jMzLHs++mQPA+ves=
> -SIZE (filter-rspamd-0.1.2.tar.gz) = 3593
> +SHA256 (filter-rspamd-0.1.3.tar.gz) = 
> horszy5OsVWArs+TWjm/XR3G5G/od2In2ZtEIGVEDmI=
> +SIZE (filter-rspamd-0.1.3.tar.gz) = 4193

-- 
I'm not entirely sure you are real.