Re: Salt master on -stable and communication with minions on -current 3006.7 version

2024-03-07 Thread Mikolaj Kucharski
Hi,

I saw this thread progressed. I didn't had a time to test the diff.
However, I see positive feedback about the fix. I don't run -current
on my -stable Salt master. Would it be possible to backport Salt
version 3006.7 with the fix to OpenBSD -stable?


On Tue, Mar 05, 2024 at 03:29:55PM +, Mikolaj Kucharski wrote:
> Hi Robert.
> 
> I've notived this problem on my Debian Bookworm machines, which recently
> got upgraded to 3006.7 and now I also see this on my OpenBSD -current,
> which also started to run 3006.7 minions. I have Salt master running
> on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7
> lost communication to the master:
> 
> openbsd-current-minion# tail -n10 /var/log/salt/minion
> The master public key can be found at:
> /etc/salt/pki/minion/minion_master.pub
> 2024-03-05 15:13:22,252 [salt.minion:1157][ERROR   ][44088] Error while 
> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
> responding? The error message was Unable to sign_in to master: Invalid master 
> key
> 2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR   ][44088] The master key has 
> changed, the salt master could have been subverted, verify salt master's 
> public key
> 2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master 
> server's public key did not authenticate!
> The master may need to be updated if it is a version of Salt lower than 
> 3006.7, or
> If you are confident that you are connecting to a valid Salt Master, then 
> remove the master public key and restart the Salt Minion.
> The master public key can be found at:
> /etc/salt/pki/minion/minion_master.pub
> 2024-03-05 15:13:32,727 [salt.minion:1157][ERROR   ][44088] Error while 
> bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
> responding? The error message was Unable to sign_in to master: Invalid master 
> key
> 
> I didn't check does upgrade to 3006.7 on master help. I don't want
> to touch my -stable machines. I could setup Salt master on -current
> and test, but all this problem started on Debian and OpenBSD after
> minion upgrade to 3006.7. I do follow -stable packages and syspatch
> on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD,
> I suspect compatibility issue on Salt side.
> 
> openbsd-salt-master# sysctl -n kern.version
> OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024
> 
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> 
> openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail
> drwxr-xr-x  2 0  0   512B Jan 17 23:23 brotli-1.0.9p0
> drwxr-xr-x  2 0  0   512B Jan 17 23:23 taskd-1.1.0p5
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 ngtcp2-0.19.1
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp3-0.15.0
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp2-1.57.0
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 git-2.42.0
> drwxr-xr-x  2 0  0   512B Feb  7 02:50 curl-8.6.0
> drwxr-xr-x  2 0  0   512B Feb 14 00:47 libunbound-1.19.1
> drwxr-xr-x  2 0  0   512B Feb 14 00:47 gnutls-3.8.3
> drwxr-xr-x  2 0  0   512B Feb 24 17:56 quirks-6.160
> 
> 
> openbsd-current-minion# sysctl -n kern.version
> OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar  3 22:36:54 MST 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> 
> Are you aware of this problem? Ports mailing list, did you notice this,
> by any chance?
> 

-- 
Regards,
 Mikolaj



Salt master on -stable and communication with minions on -current 3006.7 version

2024-03-05 Thread Mikolaj Kucharski
Hi Robert.

I've notived this problem on my Debian Bookworm machines, which recently
got upgraded to 3006.7 and now I also see this on my OpenBSD -current,
which also started to run 3006.7 minions. I have Salt master running
on OpenBSD -stable with salt-3006.3 and minions after upgrade to 3006.7
lost communication to the master:

openbsd-current-minion# tail -n10 /var/log/salt/minion
The master public key can be found at:
/etc/salt/pki/minion/minion_master.pub
2024-03-05 15:13:22,252 [salt.minion:1157][ERROR   ][44088] Error while 
bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
responding? The error message was Unable to sign_in to master: Invalid master 
key
2024-03-05 15:13:32,719 [salt.crypt:1188][ERROR   ][44088] The master key has 
changed, the salt master could have been subverted, verify salt master's public 
key
2024-03-05 15:13:32,721 [salt.crypt:803 ][CRITICAL][44088] The Salt Master 
server's public key did not authenticate!
The master may need to be updated if it is a version of Salt lower than 3006.7, 
or
If you are confident that you are connecting to a valid Salt Master, then 
remove the master public key and restart the Salt Minion.
The master public key can be found at:
/etc/salt/pki/minion/minion_master.pub
2024-03-05 15:13:32,727 [salt.minion:1157][ERROR   ][44088] Error while 
bringing up minion for multi-master. Is master at fde4:f456:48c2:13c0::1 
responding? The error message was Unable to sign_in to master: Invalid master 
key

I didn't check does upgrade to 3006.7 on master help. I don't want
to touch my -stable machines. I could setup Salt master on -current
and test, but all this problem started on Debian and OpenBSD after
minion upgrade to 3006.7. I do follow -stable packages and syspatch
on my 7.4-stable machines, but giving upgrade on Debian and OpenBSD,
I suspect compatibility issue on Salt side.

openbsd-salt-master# sysctl -n kern.version
OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024

r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


openbsd-salt-master# ls -lhtnr /var/db/pkg/ | tail
drwxr-xr-x  2 0  0   512B Jan 17 23:23 brotli-1.0.9p0
drwxr-xr-x  2 0  0   512B Jan 17 23:23 taskd-1.1.0p5
drwxr-xr-x  2 0  0   512B Feb  7 02:50 ngtcp2-0.19.1
drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp3-0.15.0
drwxr-xr-x  2 0  0   512B Feb  7 02:50 nghttp2-1.57.0
drwxr-xr-x  2 0  0   512B Feb  7 02:50 git-2.42.0
drwxr-xr-x  2 0  0   512B Feb  7 02:50 curl-8.6.0
drwxr-xr-x  2 0  0   512B Feb 14 00:47 libunbound-1.19.1
drwxr-xr-x  2 0  0   512B Feb 14 00:47 gnutls-3.8.3
drwxr-xr-x  2 0  0   512B Feb 24 17:56 quirks-6.160


openbsd-current-minion# sysctl -n kern.version
OpenBSD 7.5 (GENERIC.MP) #53: Sun Mar  3 22:36:54 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


Are you aware of this problem? Ports mailing list, did you notice this,
by any chance?

-- 
Regards,
 Mikolaj



zigbee2mqtt, anyone?

2023-12-27 Thread Mikolaj Kucharski
Hi.

- Does anyone has work in progress zigbee2mqtt port?

- Does it make sense to try to use it on OpenBSD?

- Any hands on experience with zigbee2mqtt on OpenBSD?

- If you are using it, are you happy, unhappy, gonna stick to it or not?

I have zero experience with Zigbee or any home automation,
that's why I am asking.


-- 
Regards,
 Mikolaj



Re: salt-3006.3, py3-setproctitle and rc.d(8) on -stable

2023-11-21 Thread Mikolaj Kucharski
Hi.

Same seems to be for salt-master. I don't have usage for other salt
daemons, like salt_api, salt_proxy or salt_syndic, so I didn't test
them.

ks2# pgrep -lf salt-master
46264 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer MWorker-4
72386 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer MWorker-3
88457 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer MWorker-2
4147 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer MWorker-1
80424 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer MWorker-0
80969 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer MWorkerQueue
50108 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
FileServerUpdate
16955 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
ReqServer ReqServer_ProcessManager
79792 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
Maintenance
79559 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
EventPublisher
58072 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
PubServerChannel._publish_daemon
6693 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-master -d 
MainProcess



On Tue, Nov 21, 2023 at 09:45:49AM +, Mikolaj Kucharski wrote:
> Hi all,
> 
> What I am reporting here, was tested on -stable and on -current. Below
> details are from -stable, because I discovered it first there and have
> the notes from that machine.
> 
> One of my OpenBSD 7.4 machines, because of package unrelated to salt,
> had py3-setproctitle installed on that machine and that resuled in
> following problem:
> 
> ks3# rcctl check salt_minion
> salt_minion(failed)
> 
> It seems that pexp from /etc/rc.d/salt_minion doesn't match the process
> when salt minion is started with py3-setproctitle package available.
> 
> Here are more details:
> 
> ks3# sysctl -n kern.version
> OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023
> 
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> ks3# cat /etc/installurl
> https://cdn.openbsd.org/pub/OpenBSD/
> 
> ks3# pkg_info -qI salt
> salt-3006.3
> 
> No py3-setproctitle installed:
> 
> ks3# ls -1 /var/db/pkg/ | grep -ci proc
> 0
> 
> ks3# pkg_add -a -i py3-setproctitle
> quirks-6.160 signed on 2023-11-19T13:55:25Z
> py3-setproctitle-1.3.2p1: ok
> 
> ks3# rcctl restart salt_minion
> salt_minion(ok)
> salt_minion(ok)
> 
> ks3# pgrep -lf salt
> 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 
> MainProcess
> 
> ks3# rcctl check salt_minion
> salt_minion(failed)
> 
> If we wait for random_startup_delay:
> 
> ks3# grep -e ^random_startup_delay /etc/salt/minion
> random_startup_delay: 180
> 
> then proc title changes again:
> 
> ks3# pgrep -lf salt
> 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 
> MultiMinionProcessManager MinionProcessManager
> 
> ks3# pkg_delete -c py3-setproctitle
> py3-setproctitle-1.3.2p1: ok
> Read shared items: ok
> 
> ks3# rcctl restart salt_minion
> salt_minion(ok)
> 
> ks3# pgrep -lf salt
> 78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d
> 8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 
> MultiMinionProcessManager MinionProcessManager
> 
> We see above orphaned previous instance of salt-minion which had
> setproctitle loaded.
> 
> ks3# kill 8102
> ks3# pgrep -lf salt
> 78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d
> 
> ks3# rcctl check salt_minion
> salt_minion(ok)
> 

-- 
Regards,
 Mikolaj



salt-3006.3, py3-setproctitle and rc.d(8) on -stable

2023-11-21 Thread Mikolaj Kucharski
Hi all,

What I am reporting here, was tested on -stable and on -current. Below
details are from -stable, because I discovered it first there and have
the notes from that machine.

One of my OpenBSD 7.4 machines, because of package unrelated to salt,
had py3-setproctitle installed on that machine and that resuled in
following problem:

ks3# rcctl check salt_minion
salt_minion(failed)

It seems that pexp from /etc/rc.d/salt_minion doesn't match the process
when salt minion is started with py3-setproctitle package available.

Here are more details:

ks3# sysctl -n kern.version
OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023

r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

ks3# cat /etc/installurl
https://cdn.openbsd.org/pub/OpenBSD/

ks3# pkg_info -qI salt
salt-3006.3

No py3-setproctitle installed:

ks3# ls -1 /var/db/pkg/ | grep -ci proc
0

ks3# pkg_add -a -i py3-setproctitle
quirks-6.160 signed on 2023-11-19T13:55:25Z
py3-setproctitle-1.3.2p1: ok

ks3# rcctl restart salt_minion
salt_minion(ok)
salt_minion(ok)

ks3# pgrep -lf salt
8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 
MainProcess

ks3# rcctl check salt_minion
salt_minion(failed)

If we wait for random_startup_delay:

ks3# grep -e ^random_startup_delay /etc/salt/minion
random_startup_delay: 180

then proc title changes again:

ks3# pgrep -lf salt
8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 
MultiMinionProcessManager MinionProcessManager

ks3# pkg_delete -c py3-setproctitle
py3-setproctitle-1.3.2p1: ok
Read shared items: ok

ks3# rcctl restart salt_minion
salt_minion(ok)

ks3# pgrep -lf salt
78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d
8102 python3.10: /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d 
MultiMinionProcessManager MinionProcessManager

We see above orphaned previous instance of salt-minion which had
setproctitle loaded.

ks3# kill 8102
ks3# pgrep -lf salt
78929 /usr/local/bin/python3.10 /usr/local/bin/salt-minion -d

ks3# rcctl check salt_minion
salt_minion(ok)

-- 
Regards,
 Mikolaj



py3-black fails with no module named typing_extensions on snapshot 2023-11-07T11:37:49Z

2023-11-08 Thread Mikolaj Kucharski
Hi.

I've noticed it today. Sorry for the lack of a diff :/

$ black foo.py
Traceback (most recent call last):
  File "/usr/local/bin/black", line 5, in 
from black import patched_main
  File "/usr/local/lib/python3.10/site-packages/black/__init__.py", line
37, in 
from black.cache import Cache
  File "/usr/local/lib/python3.10/site-packages/black/cache.py", line
19, in 
from typing_extensions import Self
ModuleNotFoundError: No module named 'typing_extensions'

# pkg_info -qI py3-black
py3-black-23.9.1

-- 
Regards,
 Mikolaj



Re: [UPDATE] security/rbw 1.8.3

2023-09-07 Thread Mikolaj Kucharski
On Wed, Sep 06, 2023 at 02:52:28PM +0100, Raf Czlonka wrote:
> Hello,
> 
> Inlined below is a diff that updates rbw to version 1.8.3.
> 
> Regards,
> 
> Raf
> 
> P.S. I'm not subscribed to ports@ mailing list so please CC me if
> need be.
> 

I would add home page, based on my diff from:

https://marc.info/?l=openbsd-ports=169324108125072=2


Index: Makefile
===
RCS file: /cvs/ports/security/rbw/Makefile,v
retrieving revision 1.17
diff -u -p -u -r1.17 Makefile
--- Makefile6 Sep 2023 17:36:47 -   1.17
+++ Makefile7 Sep 2023 06:21:50 -
@@ -4,8 +4,11 @@ NOT_FOR_ARCHS =powerpc64 riscv64 sparc6
 COMMENT =  command line BitWarden client
 
 DISTNAME = rbw-1.8.3
+REVISION = 0
 
 CATEGORIES =   security
+
+HOMEPAGE = https://git.tozt.net/rbw/about/
 
 MASTER_SITES = https://git.tozt.net/rbw/snapshot/


-- 
Regards,
 Mikolaj



PATCH: rbw-1.8.3

2023-08-28 Thread Mikolaj Kucharski
Hi,

I wanted to update to latest version, but it doesn't work for
organization which I am part of after upgrade to v1.8.3 :/

I also tested 1.8.2 and also doesn't work for me here.

I suspect it may be related to settings related to the org.

The organization is using https://vault.bitwarden.com/ as backend.

Sending, in case it is useful for someone else.

$ rbw -V
rbw 1.8.3

$ rbw stop-agent
$ rbw login
rbw login: failed to parse message from agent: EOF while parsing a value at 
line 1 column 0

I think I could use local copy of secrets with rbw-1.6.0p0.tgz from
ports, but I don't think sync worked. I suspect I just has stale
entries in my local cache.


Index: Makefile
===
RCS file: /cvs/ports/security/rbw/Makefile,v
retrieving revision 1.15
diff -u -p -u -r1.15 Makefile
--- Makefile10 Jul 2023 19:35:13 -  1.15
+++ Makefile28 Aug 2023 15:37:17 -
@@ -3,10 +3,11 @@ NOT_FOR_ARCHS =   powerpc64 riscv64 sparc6
 
 COMMENT =  command line BitWarden client
 
-DISTNAME = rbw-1.6.0
-REVISION = 0
+DISTNAME = rbw-1.8.3
 
 CATEGORIES =   security
+
+HOMEPAGE = https://git.tozt.net/rbw
 
 MASTER_SITES = https://git.tozt.net/rbw/snapshot/
 
Index: crates.inc
===
RCS file: /cvs/ports/security/rbw/crates.inc,v
retrieving revision 1.3
diff -u -p -u -r1.3 crates.inc
--- crates.inc  15 Mar 2023 00:35:38 -  1.3
+++ crates.inc  28 Aug 2023 15:37:17 -
@@ -1,57 +1,79 @@
-MODCARGO_CRATES += aes 0.8.2   # MIT OR Apache-2.0
+MODCARGO_CRATES += addr2line   0.20.0  # Apache-2.0 OR MIT
+MODCARGO_CRATES += adler   1.0.2   # 0BSD OR MIT OR Apache-2.0
+MODCARGO_CRATES += aes 0.8.3   # MIT OR Apache-2.0
 MODCARGO_CRATES += ahash   0.7.6   # MIT OR Apache-2.0
-MODCARGO_CRATES += aho-corasick0.7.20  # Unlicense OR MIT
-MODCARGO_CRATES += anyhow  1.0.69  # MIT OR Apache-2.0
-MODCARGO_CRATES += arrayvec0.7.2   # MIT OR Apache-2.0
-MODCARGO_CRATES += async-trait 0.1.66  # MIT OR Apache-2.0
+MODCARGO_CRATES += aho-corasick1.0.2   # Unlicense OR MIT
+MODCARGO_CRATES += anstream0.3.2   # MIT OR Apache-2.0
+MODCARGO_CRATES += anstyle 1.0.1   # MIT OR Apache-2.0
+MODCARGO_CRATES += anstyle-parse   0.2.1   # MIT OR Apache-2.0
+MODCARGO_CRATES += anstyle-query   1.0.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += anstyle-wincon  1.0.1   # MIT OR Apache-2.0
+MODCARGO_CRATES += anyhow  1.0.72  # MIT OR Apache-2.0
+MODCARGO_CRATES += argon2  0.5.1   # MIT OR Apache-2.0
+MODCARGO_CRATES += arrayvec0.7.4   # MIT OR Apache-2.0
+MODCARGO_CRATES += async-trait 0.1.71  # MIT OR Apache-2.0
 MODCARGO_CRATES += autocfg 1.1.0   # Apache-2.0 OR MIT
+MODCARGO_CRATES += backtrace   0.3.68  # MIT OR Apache-2.0
 MODCARGO_CRATES += base32  0.4.0   # MIT OR Apache-2.0
-MODCARGO_CRATES += base64  0.21.0  # MIT OR Apache-2.0
+MODCARGO_CRATES += base64  0.21.2  # MIT OR Apache-2.0
 MODCARGO_CRATES += base64ct1.6.0   # Apache-2.0 OR MIT
 MODCARGO_CRATES += bitflags1.3.2   # MIT/Apache-2.0
+MODCARGO_CRATES += blake2  0.10.6  # MIT OR Apache-2.0
+MODCARGO_CRATES += block   0.1.6   # MIT
 MODCARGO_CRATES += block-buffer0.10.4  # MIT OR Apache-2.0
-MODCARGO_CRATES += block-padding   0.3.2   # MIT OR Apache-2.0
-MODCARGO_CRATES += bumpalo 3.12.0  # MIT/Apache-2.0
+MODCARGO_CRATES += block-padding   0.3.3   # MIT OR Apache-2.0
+MODCARGO_CRATES += bumpalo 3.13.0  # MIT/Apache-2.0
 MODCARGO_CRATES += byteorder   1.4.3   # Unlicense OR MIT
 MODCARGO_CRATES += bytes   1.4.0   # MIT
 MODCARGO_CRATES += cbc 0.1.2   # MIT OR Apache-2.0
 MODCARGO_CRATES += cc  1.0.79  # MIT OR Apache-2.0
 MODCARGO_CRATES += cfg-if  1.0.0   # MIT/Apache-2.0
 MODCARGO_CRATES += cipher  0.4.4   # MIT OR Apache-2.0
-MODCARGO_CRATES += clap4.1.8   # MIT OR Apache-2.0
-MODCARGO_CRATES += clap_complete   4.1.4   # MIT OR Apache-2.0
-MODCARGO_CRATES += clap_derive 4.1.8   # MIT OR Apache-2.0
-MODCARGO_CRATES += clap_lex0.3.2   # MIT OR Apache-2.0
-MODCARGO_CRATES += const-oid   0.9.2   # Apache-2.0 OR MIT
+MODCARGO_CRATES += clap4.3.15  # MIT OR Apache-2.0
+MODCARGO_CRATES += clap_builder4.3.15  # MIT OR Apache-2.0
+MODCARGO_CRATES += clap_complete   4.3.2   # MIT OR Apache-2.0
+MODCARGO_CRATES += clap_derive 4.3.12  # MIT OR Apache-2.0
+MODCARGO_CRATES += clap_lex0.5.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += clipboard-win   3.1.1   # MIT
+MODCARGO_CRATES += colorchoice 1.0.0   # MIT OR Apache-2.0
+MODCARGO_CRATES += const-oid   0.9.4   # Apache-2.0 OR MIT
+MODCARGO_CRATES += copypasta   0.8.2   # MIT / Apache-2.0
 MODCARGO_CRATES += core-foundation 0.9.3   # MIT / Apache-2.0

Re: Port Request

2023-07-01 Thread Mikolaj Kucharski
On Sat, Jul 01, 2023 at 02:03:26PM +0200, Solène Rapenne wrote:
> On Sat, 2023-07-01 at 11:48 +, Umgeher Torgersen wrote:
> > On Fri, Jun 30, 2023 at 09:24:54AM +, luffy20201 wrote:
> > > Hello OpenBSD Devs! I want to make a request, can you guys please
> > > try to port ytfzf to OBSD. I used it a lot on GNU/linux, and I would
> > > greatly appreciate if you guys could. Thank You
> > 
> > sure! with fries?
> > 
> > thank you for your order!
> > 
> 
> there is no need to be condescending for free, at best, just don't
> reply.
> 
> The program actually looks interesting, it only requires curl and jq as
> dependencies. However, it may be so trivial to install it locally, I'm
> not sure this deserve to be packaged. I'll give it a try.
> 

It also seems to depend on fzf:

$ sh ytfzf -m music
Scraping YouTube (with https://invidious.flokinet.to) (music, pg: 1)
[ERROR]: fzf not installed, cannot use the default menu

-- 
Regards,
 Mikolaj



PATCH: security/py-hvac from 0.11.2 to 1.1.0

2023-05-19 Thread Mikolaj Kucharski
te. GH-848
- Update kubernetes authentication example. GH-827

### 藺 Miscellaneous

- .gitignore: Add vscode config directory. GH-867
- Add stock version-resolver cfg for release-drafter. GH-836
- Release drafter tweaks. GH-835
- Add commitish to release-drafter.yml. GH-832
- Bump dependencies. GH-826
- Readding 3.6 support. GH-823
- Add support for Python 3.10. GH-821
- Fix CI. GH-812

## 0.11.2 (September 23rd, 2021)

Breakfix release to revert some unintended post-1.0 requirements changes.

###  Bug Fixes

- Revert `six` & `requests` Requirements Changes. GH-768

## 0.11.1 (September 22nd, 2021)
...


Index: Makefile
===
RCS file: /cvs/ports/security/py-hvac/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile25 Nov 2022 19:30:37 -  1.4
+++ Makefile19 May 2023 10:48:48 -
@@ -1,9 +1,8 @@
 COMMENT =  Python client library for Hashicorp Vault
 
-MODPY_EGG_VERSION =0.11.2
+MODPY_EGG_VERSION =1.1.0
 DISTNAME = hvac-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
-REVISION = 1
 
 MAINTAINER =       Mikolaj Kucharski 
 
@@ -15,7 +14,7 @@ HOMEPAGE =https://github.com/hvac/hvac
 PERMIT_PACKAGE =   Yes
 
 MODULES =  lang/python
-MODPY_PYBUILD =setuptools
+MODPY_PYBUILD =poetry-core
 MODPY_PI = Yes
 
 RUN_DEPENDS =  devel/py-six${MODPY_FLAVOR} \
Index: distinfo
===
RCS file: /cvs/ports/security/py-hvac/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 distinfo
--- distinfo20 Nov 2021 08:22:34 -  1.1.1.1
+++ distinfo19 May 2023 10:48:48 -
@@ -1,2 +1,2 @@
-SHA256 (hvac-0.11.2.tar.gz) = +QXFnTLYjT9nVx/lqKeN5GWeBHmK2AneQ59mckfRNiY=
-SIZE (hvac-0.11.2.tar.gz) = 113064
+SHA256 (hvac-1.1.0.tar.gz) = B53KWIVt7mZG7VovIoOAnBbS3u3eHp6WFbKRAySkuWk=
+SIZE (hvac-1.1.0.tar.gz) = 106777
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/py-hvac/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -u -r1.3 PLIST
--- pkg/PLIST   25 Nov 2022 19:30:37 -  1.3
+++ pkg/PLIST   19 May 2023 10:48:48 -
@@ -4,7 +4,6 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/hvac-${MODPY_EGG_VERSION}.dist-info/METADATA
 
lib/python${MODPY_VERSION}/site-packages/hvac-${MODPY_EGG_VERSION}.dist-info/RECORD
 
lib/python${MODPY_VERSION}/site-packages/hvac-${MODPY_EGG_VERSION}.dist-info/WHEEL
-lib/python${MODPY_VERSION}/site-packages/hvac-${MODPY_EGG_VERSION}.dist-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/hvac/__init__.py
 ${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/hvac/${MODPY_PYCACHE}/
 
lib/python${MODPY_VERSION}/site-packages/hvac/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -50,6 +49,8 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}kubernetes.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}ldap.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}ldap.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}legacy_mfa.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}legacy_mfa.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}mfa.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}mfa.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/${MODPY_PYCACHE}oidc.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -71,6 +72,7 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/jwt.py
 lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/kubernetes.py
 lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/ldap.py
+lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/legacy_mfa.py
 lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/mfa.py
 lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/oidc.py
 lib/python${MODPY_VERSION}/site-packages/hvac/api/auth_methods/okta.py
@@ -106,6 +108,8 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/secrets_engines/${MODPY_PYCACHE}pki.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/secrets_engines/${MODPY_PYCACHE}rabbitmq.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
 
lib/python${MODPY_VERSION}/site-packages/hvac/api/secrets_engines/${MODPY_PYCACH

man borg - unexpected output with borgbackup-1.1.18p3

2023-04-29 Thread Mikolaj Kucharski
Hi,

I just wanted to have a quick look at `man borg` and it doesn't look
right.

Do you guys see the same?


OpenBSD 7.3-current (GENERIC.MP) #1139: Fri Apr 14 10:12:49 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

-- 
Regards,
 Mikolaj



Re: NEW: devel/p5-OpenAI-API

2023-03-15 Thread Mikolaj Kucharski
Hi all,

On Tue, Mar 14, 2023 at 04:56:48AM -0500, Todd T. Fries wrote:
> I missed the update, thanks!
> 
> A single line added to the Makefile seems useful of 'make test' is to succeed:
> 
>   TEST_DEPENDS=   devel/p5-Test-RequiresInternet
> 
> Otherwise, still works with https://github.com/toddfries/coai so ..
> 
> New version p5-OpenAI-API,4.tgz attached.
> 
> Thanks,
> 

- include above change from Todd
- bump version to OpenAI::API to 0.27
- regen distinfo
- regen plist

New version p5-OpenAI-API,5.tgz attached.

-- 
Regards,
 Mikolaj


p5-OpenAI-API,5.tgz
Description: application/tar-gz


Re: NEW: devel/p5-OpenAI-API

2023-03-12 Thread Mikolaj Kucharski
Hi,

I took p5-OpenAI-API,2.tgz from Stuart and update OpenAI::API to 0.25
which I saw in CPAN.

Port changes:
- version bumped to 0.25
- new dependencies added
- plist updated
- checksums regenerated via makesum

New version p5-OpenAI-API,3.tgz attached.

I did simple test via:


---8<---
#!/usr/bin/perl

use warnings;
use strict;
use OpenAI::API;

use Data::Dumper;
$Data::Dumper::Terse = 1;
$Data::Dumper::Indent = 1;
$Data::Dumper::Sortkeys = 1;

open(my $fh, '<', 'key.conf') or die $!;
my $key = <$fh>;
close($fh) or die $!;

chomp $key;

my $ai = OpenAI::API->new(api_key => $key);
print Dumper($ai->models());

print Dumper($ai->chat(model => 'gpt-3.5-turbo',
messages => [ { 'role' => 'user', 'content' => 'What is 
OpenBSD?' }, ]));
--->8---


and I got some data back. Didn't had time to look into it more, but I guess
it works?



On Mon, Feb 27, 2023 at 12:01:00PM +, Stuart Henderson wrote:
> On 2023/02/25 17:36, Todd T. Fries wrote:
> > Penned by Stuart Henderson on 20230221  9:37.50, we have:
> > | On 2023/02/20 15:14, Todd T. Fries wrote:
> > | > This is not used by anything, yet.
> > | > 
> > | > Comment:
> > | > A Perl module for accessing the OpenAI API
> > | 
> > | s/A //
> > | 
> > | > Feedback?  If OK, please commit, I don't have commit access since
> > | > I fell off the radar.
> > | 
> > | There's no attachment.
> > 
> > Getting back into the swing is hard. Or probably I just goofed. Here ya go, 
> > with the above
> > suggestion!
> > -- 
> > Todd T. Fries . http://todd.fries.net/pgp.txt . @unix2mars . 
> > github:toddfries
> 
> Tweaked version (tar attached) is OK with me if someone would like to
> commit. (I've only built and run "make test", I have no interest in
> signing up for an api key). I'll comment on the changes inline:
> 
> : diff --git devel/p5-OpenAI-API/Makefile devel/p5-OpenAI-API/Makefile
> : index 9d33fb2..9025886 100644
> : --- devel/p5-OpenAI-API/Makefile
> : +++ devel/p5-OpenAI-API/Makefile
> : @@ -1,24 +1,16 @@
> : -# : Makefile,v 1.2 2005/12/01 22:37:28 steven Exp $
> : -
> 
> the main part of the ports tree is not using RCS IDs any more (only
> for infrastructure)
> 
> :  COMMENT=   Perl module for accessing the OpenAI API
> :  
> :  MODULES=   cpan
> : -VER=   0.07
> : -DISTNAME=  OpenAI-API-${VER}
> : -PKGNAME=   p5-${DISTNAME}
> : -CATEGORIES=devel perl5
> : +DISTNAME=  OpenAI-API-0.07
> : +CATEGORIES=devel
> 
> simplify, the p5- prefix and 'perl' CATEGORIES are added automatically
> by MODULES=cpan.
> 
> :  CPAN_AUTHOR=   NFERRAZ
> :  
> :  MAINTAINER=Todd T. Fries 
> :  
> :  # Artistic
> : -PERMIT_PACKAGE=Yes
> : -PERMIT_DISTFILES=   Yes
> : +PERMIT_PACKAGE=Yes
> 
> PERMIT_DISTFILES is defaulted to Yes if PERMIT_PACKAGE is set.
> 
> : -RUN_DEPENDS+= ${BUILD_DEPENDS}
> : -BUILD_DEPENDS+=www/p5-libwww \
> : +RUN_DEPENDS=   www/p5-libwww \
> : converters/p5-JSON-MaybeXS
> 
> although in this case it makes no difference, often there are some
> 'hidden' build dependencies (for example, Module::Build for a perl port
> using CONFIGURE_STYLE=modbuild, or autoconf etc for some other ports),
> so avoid setting it this way round.
> 
> if you need this, do it the other way round instead,
> BUILD_DEPENDS=${RUN_DEPENDS}, this is less likely to pollute the run deps.
> but in this port the build dep isn't doing much; just avoids a warning
> at build time. if it were a port with a more complex set of dependencies
> I might argue to keep listing them as BUILD_DEPENDS to make it easier
> to check updates, but in this case it's a short list and easy to check
> by hand.
> 
> :  
> : -CONFIGURE_STYLE= perl
> : -
> 
> already set by MODULES=cpan
> 
> :  .include 
> : diff --git devel/p5-OpenAI-API/pkg/DESCR devel/p5-OpenAI-API/pkg/DESCR
> : index 004d87e..413129c 100644
> : --- devel/p5-OpenAI-API/pkg/DESCR
> : +++ devel/p5-OpenAI-API/pkg/DESCR
> : @@ -1 +1,7 @@
> : -Perl module for accessing the OpenAI API
> : +OpenAI::API is a Perl module that provides an interface to the OpenAI
> : +API, which allows you to generate text, translate languages, summarize
> : +text, and perform other tasks using the language models developed by
> : +OpenAI.
> : +
> : +To use the OpenAI::API module, you will need an API key, which you can
> : +obtain by signing up for an account on the OpenAI website.
> 
> if possible DESCR should have a bit more in than just a copy of COMMENT.
> 

-- 
Regards,
 Mikolaj


p5-OpenAI-API,3.tgz
Description: application/tar-gz


Re: Heads ups, perl upgraded, wait for mirror package sync / v5.36.0

2023-02-18 Thread Mikolaj Kucharski
On Wed, Feb 15, 2023 at 08:20:10PM +, Mikolaj Kucharski wrote:
> # perl -e 'print "$]\n";'
> 5.036000
> 
> # perl -MBSD::arc4random -e 'print "okay\n"'
> arc4rnd_xs.c: loadable library and perl binaries are mismatched (got first 
> handshake key 0xec0, needed 0xeb8)

Cool, it seems mirror which I am using has rebuilt amd64 packages now:

# perl -MBSD::arc4random -e 'print "$]\n"'
5.036000

-- 
Regards,
 Mikolaj



Heads ups, perl upgraded, wait for mirror package sync / v5.36.0

2023-02-15 Thread Mikolaj Kucharski
# perl -e 'print "$]\n";'
5.036000

# perl -MBSD::arc4random -e 'print "okay\n"'
arc4rnd_xs.c: loadable library and perl binaries are mismatched (got first 
handshake key 0xec0, needed 0xeb8)

-- 
Regards,
 Mikolaj



Re: youtube-dl python issue, SyntaxError: (unicode error)

2022-12-17 Thread Mikolaj Kucharski
On Sat, Dec 17, 2022 at 11:40:35AM +, Stuart Henderson wrote:
> On 2022/12/17 11:18, Mikolaj Kucharski wrote:
> > $ youtube-dl -F https://youtu.be/YGdYhvk6xyw
> > Traceback (most recent call last):
> ..
> > from ..compat import compat_os_name
> >   File "/usr/local/lib/python3.10/site-packages/youtube_dl/compat.py", line 
> > 2368, in 
> > import http.server as compat_http_server
> >   File "/usr/local/lib/python3.10/http/server.py", line 102, in 
> > import socketserver
> >   File "/usr/local/lib/python3.10/socketserver.py", line 119
> > """
> >^
> > SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xee in 
> > position 2: invalid continuation byte
> > 
> 
> No such problem here. Is there anything strange about the contents of
> /usr/local/lib/python3.10/socketserver.py on your machine? If it looks
> corrupt, try reinstalling Python (pkg_add -r -D installed python%3.10)
> 

Hm... Yeah, thanks, that seems to be the problem O_o


$ cksum -a sha256 -b - < /usr/local/lib/python3.10/socketserver.py
lODUo6wOKmwvv4ONuJGtrMMI4YT7LPtwiY0TujxOQE8=

# time pkg_check
Packing-list sanity: ok
Direct dependencies: ok
Reverse dependencies: ok
Files from packages: ok
--- python-3.10.8p4 ---
checksum for /usr/local/lib/python3.10/socketserver.py does not match
5m02.54s real 2m37.04s user 1m10.34s system

# pkg_add -r -D installed python%3.10
quirks-6.88 signed on 2022-12-15T21:12:19Z
quirks-6.88->6.88: ok
python-3.10.8p4->3.10.8p4: ok
Read shared items: ok

$ cksum -a sha256 -b - < /usr/local/lib/python3.10/socketserver.py
lODUo6wOKmwvv4ONuJGtrMMI4YT7LPtwiY0TujxOQE8=

# pkg_add -r -D installed -D donttie python%3.10
quirks-6.88 signed on 2022-12-15T21:12:19Z
quirks-6.88->6.88: ok
python-3.10.8p4->3.10.8p4: ok
Read shared items: ok

$ cksum -a sha256 -b - < /usr/local/lib/python3.10/socketserver.py
WQB5Fs8vVAGFv0fzvjVkjVFBucD0ZoshSQDEw1A3F54=

# time pkg_check
Packing-list sanity: ok
Direct dependencies: ok
Reverse dependencies: ok
Files from packages: ok
3m48.36s real 2m33.37s user 0m49.87s system

$ hexdump -vC /tmp/bad > /tmp/socketserver.py.bad
$ hexdump -vC /tmp/good > /tmp/socketserver.py.good
$ diff -u /tmp/socketserver.py.*
--- /tmp/socketserver.py.badSat Dec 17 12:18:02 2022
+++ /tmp/socketserver.py.good   Sat Dec 17 12:18:08 2022
@@ -1,4 +1,4 @@
-  22 22 22 47 65 ee 65 72  69 63 20 73 6f 63 6b 65  |"""Ge.eric socke|
+  22 22 22 47 65 6e 65 72  69 63 20 73 6f 63 6b 65  |"""Generic socke|
 0010  74 20 73 65 72 76 65 72  20 63 6c 61 73 73 65 73  |t server classes|
 0020  2e 0a 0a 54 68 69 73 20  6d 6f 64 75 6c 65 20 74  |...This module t|
 0030  72 69 65 73 20 74 6f 20  63 61 70 74 75 72 65 20  |ries to capture |

$ echo "ibase=16;obase=2;E" | bc
1110
$ echo "ibase=16;obase=2;6" | bc
110

-- 
Regards,
 Mikolaj



youtube-dl python issue, SyntaxError: (unicode error)

2022-12-17 Thread Mikolaj Kucharski
Hi,

Do you guys see the same by any chance?

$ pkg_info -qI youtube-dl
youtube-dl-2021.12.17p1

$ sysctl -n kern.version
OpenBSD 7.2-current (GENERIC.MP) #859: Sat Nov 26 11:10:04 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ pkg_info -f quirks | grep -e '^@digital-signature'
@digital-signature signify2:2022-12-12T02:36:47Z:external


$ youtube-dl -F https://youtu.be/YGdYhvk6xyw
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl", line 5, in 
from youtube_dl import main
  File "/usr/local/lib/python3.10/site-packages/youtube_dl/__init__.py", line 
15, in 
from .options import (
  File "/usr/local/lib/python3.10/site-packages/youtube_dl/options.py", line 8, 
in 
from .downloader.external import list_external_downloaders
  File 
"/usr/local/lib/python3.10/site-packages/youtube_dl/downloader/__init__.py", 
line 3, in 
from .common import FileDownloader
  File 
"/usr/local/lib/python3.10/site-packages/youtube_dl/downloader/common.py", line 
9, in 
from ..compat import compat_os_name
  File "/usr/local/lib/python3.10/site-packages/youtube_dl/compat.py", line 
2368, in 
import http.server as compat_http_server
  File "/usr/local/lib/python3.10/http/server.py", line 102, in 
import socketserver
  File "/usr/local/lib/python3.10/socketserver.py", line 119
"""
   ^
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xee in position 
2: invalid continuation byte

-- 
Regards,
 Mikolaj



desmume, any special reqs to run it?

2022-12-04 Thread Mikolaj Kucharski
Hi,

I just wanted to see how Nintendo 3DS emulators work on OpenBSD. Never
played with them before.

$ desmume some-game-decrypted.3ds
mprotect failed: Operation not permitted
Abort trap (core dumped) 

I tried with few 3DS files and one CIA file, always the same output
like above. Any tips?


OpenBSD 7.2-current (GENERIC.MP) #859: Sat Nov 26 11:10:04 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


# pkg_info -qI desmume
desmume-0.9.11p10

-- 
Regards,
 Mikolaj



Does dovecot on openbsd7.2 -stable support TLSv1.3?

2022-11-16 Thread Mikolaj Kucharski
Hi,

Just making sure I didn't miss anything on my end. I have working
Dovecot setup for few OpenBSD releases now. Today I wanted to bump
minimal TLS version on the Dovecot end:

-ssl_min_protocol = TLSv1.2
+ssl_min_protocol = TLSv1.3

After restarting Dovecot, I see that I can connect to host:993 via:

$ openssl s_client -connect imap.example.com:993 -showcerts \
/dev/null | sed -ne '/^Server certificate/,$p'
Server certificate
subject=/CN=imap.example.com
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 4233 bytes and written 374 bytes
---
New, TLSv1/SSLv3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_CHACHA20_POLY1305_SHA256
Session-ID: 
Session-ID-ctx: 
Master-Key: 
Start Time: 1668617217
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---


However on Andorid, Google Mail app doesn't connect any more and on the
server I see following lines in maillog:

2022-11-16T16:32:02.837Z obsd4321 dovecot: imap-login: Disconnected: Connection 
closed: SSL_accept() failed: error:1402610B:SSL 
routines:ACCEPT_SR_CLNT_HELLO:wrong version number (no auth attempts in 0 
secs): user=<>, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS handshaking: 
SSL_accept() failed: error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong 
version number, session=


No feedback from the Android app that doesn't work, emails are just not
refreshing. Anyway, does anyone have Dovecot with TLSv1.3 as
ssl_min_protocol?


This is on:

OpenBSD 7.2 (GENERIC.MP) #0: Wed Oct 26 12:01:47 MDT 2022

r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


$ pkg_info -qI dovecot dovecot-fts-flatcurve
dovecot-2.3.19.1p0v0
dovecot-fts-flatcurve-0.3.1

-- 
Regards,
 Mikolaj



cups, libusb1, Backend returned status -139 (crashed), /usb.core

2022-09-13 Thread Mikolaj Kucharski
Hi,

I configured cups as network printer around beginning of 2022. Few
months later I've noticed coredump at /usb.core. Then it took me a while
to collect what I have so far. I don't know when this started, but I
assume from day one, when I've setup cups as a remote.

I imagine it will take me a while to troubleshoot this and I will
probably need some guidenance. I know we are pre-release, I'm not
in rush to fix this, but I finally collected enough into to write
this email.

Any clue what could be the problem here?


pce-0035# pkg_info -qI cups cups-libs cups-filters libusb1 debug-cups 
debug-cups-libs debug-cups-filters debug-libusb1
cups-2.4.2p0
cups-libs-2.4.2
cups-filters-1.28.16
libusb1-1.0.23p2-debug
debug-cups-2.4.2p0
debug-cups-libs-2.4.2
debug-cups-filters-1.28.16
debug-libusb1-1.0.23p2-debug

pce-0035# ls -l /usb.core
-rw---  1 root  wheel  2405480 Sep 13 16:09 /usb.core

pce-0035# ls -l /usr/local/libexec/cups/backend/usb
-rwxr--r--  1 root  bin  38702 Aug 31 11:36 /usr/local/libexec/cups/backend/usb

pce-0035# egdb /usr/local/libexec/cups/backend/usb /usb.core
GNU gdb (GDB) 9.2
...

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/libexec/cups/backend/usb...
Reading symbols from /usr/local/libexec/cups/backend/.debug/usb.dbg...
[New process 244617]
[New process 426606]
Core was generated by `usb'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0118371b4360 in list_del (entry=) at ./libusbi.h:163
163 ./libusbi.h: No such file or directory.
[Current thread is 1 (process 244617)]
(gdb) bt
#0  0x0118371b4360 in list_del (entry=) at ./libusbi.h:163
#1  remove_from_flying_list (transfer=0x118a9179600) at io.c:1465
#2  libusb_submit_transfer (transfer=0x118a9179650) at io.c:1559
#3  0x0118371b64cd in do_sync_bulk_transfer (dev_handle=, 
endpoint=129 '\201', buffer=0x1190a6a5850 "", length=512, 
transferred=0x1190a6a5a5c, timeout=6, type=2 '\002') at sync.c:193
#4  0x0118371b63fe in libusb_bulk_transfer (dev_handle=0x1184e1f8b40, 
endpoint=129 '\201', data=0x2 , 
length=0, transferred=0x0, timeout=1236779248) at sync.c:281
#5  0x01162dd39d28 in read_thread (reference=) at 
./usb-libusb.c:1734
#6  0x0118b7ebc801 in _rthread_start (v=) at 
/usr/src/lib/librthread/rthread.c:96
#7  0x011849b5cdaa in __tfork_thread () at 
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
(gdb) thread apply all bt

Thread 2 (process 426606):
#0  0x0118371afbcd in libusb_close (dev_handle=0x1184e1dc280) at core.c:1530
#1  0x01162dd39c33 in close_device (printer=0x1162dd3d798 
) at ./usb-libusb.c:762
#2  0x01162dd391d5 in print_device (uri=, 
hostname=, resource=, options=, 
print_fd=0, copies=, argc=, argv=0x7f7fa3b8) 
at ./usb-libusb.c:645
#3  0x01162dd39f90 in main (argc=6, argv=0x7f7fa3b8) at usb.c:235

Thread 1 (process 244617):
#0  0x0118371b4360 in list_del (entry=) at ./libusbi.h:163
#1  remove_from_flying_list (transfer=0x118a9179600) at io.c:1465
#2  libusb_submit_transfer (transfer=0x118a9179650) at io.c:1559
#3  0x0118371b64cd in do_sync_bulk_transfer (dev_handle=, 
endpoint=129 '\201', buffer=0x1190a6a5850 "", length=512, 
transferred=0x1190a6a5a5c, timeout=6, type=2 '\002') at sync.c:193
#4  0x0118371b63fe in libusb_bulk_transfer (dev_handle=0x1184e1f8b40, 
endpoint=129 '\201', data=0x2 , 
length=0, transferred=0x0, timeout=1236779248) at sync.c:281
#5  0x01162dd39d28 in read_thread (reference=) at 
./usb-libusb.c:1734
#6  0x0118b7ebc801 in _rthread_start (v=) at 
/usr/src/lib/librthread/rthread.c:96
#7  0x011849b5cdaa in __tfork_thread () at 
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
(gdb)


# /var/log/cups/access_log
192.168.5.107 - - [13/Sep/2022:16:08:08 +] "POST /printers/Samsung-M2070 
HTTP/1.1" 200 697 Validate-Job successful-ok
192.168.5.107 - - [13/Sep/2022:16:08:08 +] "POST /printers/Samsung-M2070 
HTTP/1.1" 200 437096 Print-Job successful-ok


# /var/log/cups/error_log
W [13/Sep/2022:16:09:10 +] [Job 93] Backend returned status -139 (crashed)
E [13/Sep/2022:16:09:10 +] [Job 93] Job aborted due to backend errors; 
please consult the /var/log/cups/error_log file for details.
D [13/Sep/2022:16:09:10 +] [Job 93] The following messages were recorded 
from 16:08:21 to 16:09:10
D [13/Sep/2022:16:09:10 +] [Job 93] [11.195487] [0006826e] libusb: debug 
[handle_events] poll() 1 fds with timeout in 48846ms
D [13/Sep/2022:16:09:10 +] [Job 93] [11.195525] [0006826e] libusb: debug 
[handle_events] poll() returned 1
D [13/Sep/2022:16:09:10 +] [Job 93] [11.195537] [0006826e] libusb: debug 
[handle_events] caught a fish on the event pipe
D [13/Sep/2022:16:09:10 +] [Job 93] [11.195550] [0006826e] libusb: debug 
[usbi_handle_transfer_completion] transfer 0x118c17e0e50 has callback 
0x118371b62e0
D [13/Sep/2022:16:09:10 +] [Job 93] [11.195593] [0006826e] libusb: debug 
[sync_transfer_cb] 

Re: mirror removal: games/teeworlds and security/shhlockout without MASTER_SITES

2022-09-12 Thread Mikolaj Kucharski
On Mon, Sep 12, 2022 at 01:53:50PM +0200, Solène Rapenne wrote:
> security/sshlockout

Some of my machines use it, so I would be sad to see this go.

-- 
Regards,
 Mikolaj



Re: Web WhatsApp and Chromium or Firefox, does not finish loading

2022-09-11 Thread Mikolaj Kucharski
On Sun, Sep 11, 2022 at 06:19:50PM +0200, Caspar Schutijser wrote:
> On Sat, Sep 10, 2022 at 08:32:27AM +0000, Mikolaj Kucharski wrote:
> > Hi,
> > 
> > I've noticed this problem many weeks before, but didn't report at the
> > time, as I thought it was random cookie problem, but then I started to
> > open new instances of Chroimum or Firefox, like scripts show at the very
> > end of this email. WhatsApp never finishes loading for me. Can anyone of
> > you reproduce the problem?
> 
> That has to do with WebAssembly. See
> https://marc.info/?l=openbsd-misc=165209716832707=2 for an earlier
> thread about similar issues.
> 
> Caspar
> 

Thanks! Exporting ENABLE_WASM=1 per above thread made Web WhatsApp work
on dedicated Chromium instance.

-- 
Regards,
 Mikolaj



Web WhatsApp and Chromium or Firefox, does not finish loading

2022-09-10 Thread Mikolaj Kucharski
Hi,

I've noticed this problem many weeks before, but didn't report at the
time, as I thought it was random cookie problem, but then I started to
open new instances of Chroimum or Firefox, like scripts show at the very
end of this email. WhatsApp never finishes loading for me. Can anyone of
you reproduce the problem?


Chromium

--->8---
#!/bin/sh

umask 077

temp=`mktemp -d "${TMPDIR:=/tmp}/chrome."` || exit 1
trap 'rm -rfP -- "$temp"' EXIT
trap 'exit 1' HUP INT QUIT TRAP PIPE TERM INFO USR1 USR2

if cd "$temp"
then
chrome \
--user-data-dir="$temp/${0##*/}" \
--incognito "$@"
exit $?
fi
---8<---


Firefox

--->8---
#!/bin/sh

umask 077

temp=`mktemp -d "${TMPDIR:=/tmp}/firefox."` || exit 1
trap 'rm -rfP -- "$temp"' EXIT
trap 'exit 1' HUP INT QUIT TRAP PIPE TERM INFO USR1 USR2

if cd "$temp"
then
if ! mkdir -m 0700 "$temp/${0##*/}"
then
exit 5
fi
/usr/local/bin/firefox \
--new-instance --private-window \
--profile "$temp/${0##*/}" "$@"
exit $?
fi
---8<---

-- 
Regards,
 Mikolaj



Did anyone have worked in the past on OSquery port?

2022-09-02 Thread Mikolaj Kucharski
Hi,

I didn't see anything in the archives, but maybe in some (public) repo,
not visible at first sight there is a stab at it?

https://osquery.io/

Description from FreshPorts:

osquery exposes an operating system as a high-performance relational
database. This allows you to write SQL-based queries to explore
operating system data. With osquery, SQL tables represent abstract
concepts such as running processes, loaded kernel modules, open network
connections, browser plugins, hardware events or file hashes.

-- 
Regards,
 Mikolaj



Re: CVS: cvs.openbsd.org: ports

2022-08-30 Thread Mikolaj Kucharski
On Tue, Aug 30, 2022 at 08:05:27AM +0100, Stuart Henderson wrote:
> On 2022/08/29 20:11, Daniel Jakots wrote:
> > On Mon, 29 Aug 2022 08:55:31 -0600 (MDT), Stuart Henderson
> >  wrote:
> > 
> > > CVSROOT:  /cvs
> > > Module name:  ports
> > > Changes by:   st...@cvs.openbsd.org   2022/08/29 08:55:31
> > > 
> > > Modified files:
> > >   devel/github-cli: Makefile distinfo modules.inc 
> > >   devel/github-cli/pkg: PLIST 
> > > 
> > > Log message:
> > > update to github-cli-2.14.7, from Mikolaj Kucharski
> > > 
> > 
> > MODGO_VERSION is now defined twice.
> > 
> > Index: modules.inc
> 
> Thanks - OK.

Ah, shoot! Sorry, didn't notice this :/


> > ===
> > RCS file: /cvs/ports/devel/github-cli/modules.inc,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 modules.inc
> > --- modules.inc 29 Aug 2022 14:55:31 -  1.9
> > +++ modules.inc 29 Aug 2022 23:42:25 -
> > @@ -1,5 +1,3 @@
> > -MODGO_VERSION =v2.14.7
> > -
> >  MODGO_MODULES =\
> > cloud.google.com/go  v0.65.0 \
> > cloud.google.com/go/bigquery v1.8.0 \
> > 
> > 
> 

-- 
Regards,
 Mikolaj



Update github-cli to v2.14.7

2022-08-29 Thread Mikolaj Kucharski
Hi,

>From https://github.com/cli/cli/releases it looks we are few months
behind.

This seems to be to include here:
https://github.com/cli/cli/compare/v2.6.0...v2.14.7

I'm updating as I would like to be able to use `gh search issues` which
current in ports tree cli doesn't support yet.

Still testing this update.


Index: Makefile
===
RCS file: /cvs/ports/devel/github-cli/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- Makefile20 Mar 2022 15:20:34 -  1.11
+++ Makefile29 Aug 2022 11:08:02 -
@@ -1,6 +1,6 @@
 COMMENT =  command-line access to github pull requests, issues and more
 
-V =2.6.0
+V =2.14.7
 MODGO_MODNAME =github.com/cli/cli/v2
 MODGO_VERSION =v${V}
 
Index: distinfo
===
RCS file: /cvs/ports/devel/github-cli/distinfo,v
retrieving revision 1.7
diff -u -p -u -r1.7 distinfo
--- distinfo20 Mar 2022 15:20:34 -  1.7
+++ distinfo29 Aug 2022 11:08:02 -
@@ -1,4 +1,4 @@
-SHA256 (cli-v2.6.0.zip) = Z8dd+WmK4PEzpQTGblvhEvkAgfzqvjzngSzig2yOHWs=
+SHA256 (cli-v2.14.7.zip) = W7E1veGsFjAAKnBbBo60SJR1qm7CFdgk4CHTVwdEGd4=
 SHA256 (go_modules/cloud.google.com/go/@v/v0.26.0.mod) = 
IhijTyC5cbwZUhbUGV9XUgoqy9hd5/wxrPxEAmZwTBE=
 SHA256 (go_modules/cloud.google.com/go/@v/v0.34.0.mod) = 
IhijTyC5cbwZUhbUGV9XUgoqy9hd5/wxrPxEAmZwTBE=
 SHA256 (go_modules/cloud.google.com/go/@v/v0.38.0.mod) = 
IRVe7cPkx6CccZziPHA/vxTDSspC7QDcCHdN5uu+gAc=
@@ -38,16 +38,16 @@ SHA256 (go_modules/cloud.google.com/go/s
 SHA256 (go_modules/cloud.google.com/go/storage/@v/v1.8.0.mod) = 
UAjocNysCFV4giSP2IjSizFIH41AmKkZHeRz2Q4yS2A=
 SHA256 
(go_modules/dmitri.shuralyov.com/gpu/mtl/@v/v0.0.0-20190408044501-666a987793e9.mod)
 = +sTF2PaC+eyXchsvyf1TBiqxcLLSt/q4/8EK4YOhlR4=
 SHA256 
(go_modules/dmitri.shuralyov.com/gpu/mtl/@v/v0.0.0-20190408044501-666a987793e9.zip)
 = ylMwkB/NqD0JVTrDYldtGWxTEVe8nFAudrI3zKJitAA=
-SHA256 (go_modules/github.com/!alec!aivazis/survey/v2/@v/v2.3.2.mod) = 
CPbyIkAvmLIsiJoijc352+sAxsfAHzeMyv66XscIVMo=
-SHA256 (go_modules/github.com/!alec!aivazis/survey/v2/@v/v2.3.2.zip) = 
4k1s7BbGJMn5zUi+k8rJVumbxYoJCAan5xGUkCaBKMw=
+SHA256 (go_modules/github.com/!alec!aivazis/survey/v2/@v/v2.3.5.mod) = 
IfBnKj3f1+lRUWC+0HQUIMpm+uOiV+shRU53U15D1OE=
+SHA256 (go_modules/github.com/!alec!aivazis/survey/v2/@v/v2.3.5.zip) = 
Tj6t/oBldvpn8Rxc3I1N/jj4cJ8GLaNUKKBa9oyUvAI=
 SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = 
KAIbQYClnDmTYHqVsY4jDdC8a+pSQv/o6ou/tPT3tNc=
 SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.zip) = 
gVxuWUdF8tiEL/mksFacZpXmzf1eB+Wz2Y0GtyykHjw=
 SHA256 
(go_modules/github.com/!burnt!sushi/xgb/@v/v0.0.0-20160522181843-27f122750802.mod)
 = luveICsJL29NHzkwvAfPGKVpmZjd6lG5T+hYETspqNg=
 SHA256 
(go_modules/github.com/!burnt!sushi/xgb/@v/v0.0.0-20160522181843-27f122750802.zip)
 = 9Slix/vsqB6op3fR+LHx0lgD3EN/u0kPJTNEIyiEMo4=
 SHA256 (go_modules/github.com/!make!now!just/heredoc/@v/v1.0.0.mod) = 
3B2EuzNucehpa5me7KXAvVzWtAhwpM3HGtEYhz4BAUo=
 SHA256 (go_modules/github.com/!make!now!just/heredoc/@v/v1.0.0.zip) = 
Bir+bhGqPDrAA10IkHuA1eW3VjkFYDOR7ndL2kQKvxY=
-SHA256 
(go_modules/github.com/!netflix/go-expect/@v/v0.0.0-20180615182759-c93bf25de8e8.mod)
 = 4IU/KkreIKKuMEW7e+qFj3sOSnWqpVyl6RfPe+vZBWE=
-SHA256 
(go_modules/github.com/!netflix/go-expect/@v/v0.0.0-20180615182759-c93bf25de8e8.zip)
 = ++ey9Y7LDhBnpmcLvPBxjVTsQHqrgXkMyeWNuaZ3R3U=
+SHA256 
(go_modules/github.com/!netflix/go-expect/@v/v0.0.0-20220104043353-73e0943537d2.mod)
 = fmpOLc8t9YpYy4EELw0O2ZUG+Mh2Z6ibEURRFuYQC5A=
+SHA256 
(go_modules/github.com/!netflix/go-expect/@v/v0.0.0-20220104043353-73e0943537d2.zip)
 = BAumlRCZXwKFnFZR9dIvc6q4fcW0G8DArmPe4IZQxIw=
 SHA256 (go_modules/github.com/alecthomas/chroma/@v/v0.10.0.mod) = 
uqwNpEiEBPS1GVoyc+pRgDQwFeCE4gv5dD3efZjL6jo=
 SHA256 (go_modules/github.com/alecthomas/chroma/@v/v0.10.0.zip) = 
vrB7mW7jO8BS/gOck9HAcm5hvMSBnKOfe/YzBPKujEk=
 SHA256 (go_modules/github.com/aymerick/douceur/@v/v0.2.0.mod) = 
XgRUJBwle0xPnb3chOeOmeKcUnWzz67or9K7R25ySJc=
@@ -56,8 +56,10 @@ SHA256 (go_modules/github.com/briandowns
 SHA256 (go_modules/github.com/briandowns/spinner/@v/v1.18.1.zip) = 
sARZfGe3P7SPLbqENCRmvDYjXau8JqnxHhRpbqU+idI=
 SHA256 
(go_modules/github.com/census-instrumentation/opencensus-proto/@v/v0.2.1.mod) = 
2uZGOSlkAiNbVVh9FNJkBhXrNzb6hA5DJ9PBXbY8w0U=
 SHA256 
(go_modules/github.com/census-instrumentation/opencensus-proto/@v/v0.2.1.zip) = 
s8CfPmNdR7QThpWlR9HyxxOPOCy+WotYZbZqjggjNGE=
-SHA256 (go_modules/github.com/charmbracelet/glamour/@v/v0.4.0.mod) = 
K0GXlbbjOOAmRoRfwY6dEThcsJv/uc4gknLGHtvaajg=
-SHA256 (go_modules/github.com/charmbracelet/glamour/@v/v0.4.0.zip) = 
kR7iPfesbC7hMonXoEPuUILMTTSpN/+LrSvg4zwiHmg=
+SHA256 (go_modules/github.com/charmbracelet/glamour/@v/v0.5.0.mod) = 
K0GXlbbjOOAmRoRfwY6dEThcsJv/uc4gknLGHtvaajg=
+SHA256 (go_modules/github.com/charmbracelet/glamour/@v/v0.5.0.zip) = 

Does p5-Net-ICal work for you?

2022-07-12 Thread Mikolaj Kucharski
Hi,

I see this on my end:

OpenBSD 7.1-current (GENERIC.MP) #610: Sat Jul  9 09:19:43 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ perl -MNet::ICal -e ''
UNIVERSAL does not export anything at 
/usr/local/libdata/perl5/site_perl/Class/MethodMapper.pm line 67.
BEGIN failed--compilation aborted at 
/usr/local/libdata/perl5/site_perl/Class/MethodMapper.pm line 67.
Compilation failed in require at /usr/libdata/perl5/base.pm line 137.
...propagated at /usr/libdata/perl5/base.pm line 159.
BEGIN failed--compilation aborted at 
/usr/local/libdata/perl5/site_perl/Net/ICal/Component.pm line 27.
Compilation failed in require at /usr/libdata/perl5/base.pm line 137.
...propagated at /usr/libdata/perl5/base.pm line 159.
BEGIN failed--compilation aborted at 
/usr/local/libdata/perl5/site_perl/Net/ICal/Alarm.pm line 27.
Compilation failed in require at /usr/local/libdata/perl5/site_perl/Net/ICal.pm 
line 17.
BEGIN failed--compilation aborted at 
/usr/local/libdata/perl5/site_perl/Net/ICal.pm line 17.
Compilation failed in require.
BEGIN failed--compilation aborted.

Do you see the same?

-- 
Regards,
 Mikolaj



Dropping RCS tags from the repo

2022-03-09 Thread Mikolaj Kucharski
Hi,

In recent years I don't have that much time to follow OpenBSD that
closely, but was wondering what is the background of dropping the
RCS IDs from the repo.

Does that mean all files under ports repo should have RCS tags to
be removed or only specific files?

-- 
Regards,
 Mikolaj



debug-cups-filters moves into a manual-installation during upgrade

2022-03-02 Thread Mikolaj Kucharski
Hi,

I have following packages installed via pkg_add -a:

debug-cups-2.4.1
debug-cups-filters-1.28.12
debug-cups-libs-2.4.1

I do periodic snapshot upgrades via sysupgrade(8) -s and upgrade.site(5).

I like to have above packages marked as non-manual. It helps me track
whan is a temporary setup for me.

During below command debug-cups-libs gets marked as manually installed.

# grep -ce ^.opt /var/db/pkg/debug-cups-*/+C*
/var/db/pkg/debug-cups-2.4.1/+CONTENTS:0
/var/db/pkg/debug-cups-filters-1.28.12/+CONTENTS:0
/var/db/pkg/debug-cups-libs-2.4.1/+CONTENTS:0

$ pkg_add -Dupdate -Dupdatedepends -Drepair -u -U -V
quirks-4.108 signed on 2022-03-01T15:51:16Z
cups-filters-1.28.11->1.28.12 forward dependencies:
| Dependency of debug-cups-filters-1.28.11 on cups-filters-1.28.11 doesn't match
Merging debug-cups-filters-1.28.11->1.28.12 ()
...

I don't have working example of above grep but debug-cups-filter gets
@option manual-installation added to the plist.

>From my testing it looks that it happens only when cups-filters is
upgraded.

I manually fix that via pkg_add -aa debug-cups-filters, but wanted to
report this behaviour here.

OpenBSD 7.1-beta (GENERIC.MP) #395: Tue Mar  1 10:06:37 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

-- 
Regards,
 Mikolaj



Anyone else with cups/backend/usb crashed on signal 11

2022-02-27 Thread Mikolaj Kucharski
I've noticed this recently, and didn't dive into it yet. Was wondering
did anyone else see this?

This is triggered by network print via Android phone, with service
discovery by avahi.

OpenBSD 7.1-beta (GENERIC.MP) #387: Sat Feb 26 17:21:00 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


# pkg_info -qI | grep cups
cups-2.4.1
cups-filters-1.28.12
cups-libs-2.4.1
debug-cups-2.4.1
debug-cups-filters-1.28.12
debug-cups-libs-2.4.1


# egdb /usr/local/libexec/cups/backend/usb /usb.core
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/libexec/cups/backend/usb...
Reading symbols from /usr/local/libexec/cups/backend/.debug/usb.dbg...
[New process 501399]
[New process 303223]
Core was generated by `usb'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0e413e79c530 in libusb_submit_transfer () from 
/usr/local/lib/libusb-1.0.so.1.2
[Current thread is 1 (process 501399)]
(gdb) bt
#0  0x0e413e79c530 in libusb_submit_transfer () from 
/usr/local/lib/libusb-1.0.so.1.2
#1  0x0e413e79e6ad in do_sync_bulk_transfer () from 
/usr/local/lib/libusb-1.0.so.1.2
#2  0x0e413e79e5de in libusb_bulk_transfer () from 
/usr/local/lib/libusb-1.0.so.1.2
#3  0x0e3f0092cd28 in read_thread (reference=) at 
./usb-libusb.c:1734
#4  0x0e41e0311621 in _rthread_start (v=) at 
/usr/src/lib/librthread/rthread.c:96
#5  0x0e41f8542b3a in __tfork_thread () at 
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
(gdb)


from /var/log/cups/error_log
...
D [27/Feb/2022:09:02:50 +] [Job 39] Read 7848 bytes of print data...
D [27/Feb/2022:09:02:50 +] [Job 39] kid4 exited with status 0
D [27/Feb/2022:09:02:50 +] [Job 39] kid3 finished
D [27/Feb/2022:09:02:50 +] [Job 39] Kid3 exit status: 0
D [27/Feb/2022:09:02:50 +] [Job 39] Closing foomatic-rip.
D [27/Feb/2022:09:02:50 +] [Job 39] Wrote 7848 bytes of print data...
D [27/Feb/2022:09:02:50 +] [Job 39] Sent 286376 bytes...
D [27/Feb/2022:09:02:50 +] [Job 39] Waiting for read thread to exit...
D [27/Feb/2022:09:02:50 +] [Job 39] PID 17625 
(/usr/local/libexec/cups/filter/foomatic-rip) exited with no errors.
D [27/Feb/2022:09:02:50 +] [Job 39] Read thread still active, aborting the 
pending read...
D [27/Feb/2022:09:02:50 +] [Job 39] Device reset failed, error code: -12
D [27/Feb/2022:09:02:50 +] [Job 39] PID 55597 
(/usr/local/libexec/cups/backend/usb) crashed on signal 11.
D [27/Feb/2022:09:02:50 +] [Job 39] Hint: Try setting the LogLevel to 
"debug" to find out more.
D [27/Feb/2022:09:02:50 +] [Job 39] time-at-completed=1645952570
D [27/Feb/2022:09:02:50 +] [Job 39] End of messages
D [27/Feb/2022:09:02:50 +] [Job 39] printer-state=3(idle)
D [27/Feb/2022:09:02:50 +] [Job 39] printer-state-message="Backend failed"
D [27/Feb/2022:09:02:50 +] [Job 39] printer-state-reasons=none


# usbdevs -vvv
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub0
 port 01: .02a0 power Rx.detect
 port 02: .02a0 power Rx.detect
 port 03: .0503 connect enabled recovery
 port 04: .02a0 power Rx.detect
addr 02: 04e8:3469 Samsung Electronics Co., Ltd., M2070 Series
 high speed, self powered, config 1, rev 1.00, iSerial ZF46B8KM2D02Z1A
 driver: ugen0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub1
 port 01: .0503 connect enabled power
 port 02: .0500 power
addr 02: 0438:7900 Advanced Micro Devices, Hub
 high speed, self powered, config 1, rev 0.18
 driver: uhub2
 port 01: .0100 power
 port 02: .0100 power
 port 03: .0503 connect enabled power
 port 04: .0100 power
addr 03: 1199:9071 Sierra Wireless, Incorporated, Sierra Wireless MC7455 
Qualcomm\M-. Snapdragon? X7 LTE-A
 high speed, power 500 mA, config 1, rev 0.06, iSerial LQ80634656021021
 driver: umb0
 driver: ugen1


# lsusb -vvv -d 04e8:3469

Bus 000 Device 002: ID 04e8:3469 Samsung Electronics Co., Ltd 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB  

Re: ansible run dep on netaddr python module

2022-01-13 Thread Mikolaj Kucharski
Hi Pavel,

On Thu, Jan 13, 2022 at 01:04:40PM +0300, Pavel Korovin wrote:
> On 01/12, Mikolaj Kucharski wrote:
> > Hi,
> > 
> > I had fresh install of OpenBSD-current with ansible added via packages:
> > 
> >   pkg_add -i ansible
> > 
> > Running it on some of my playbooks failed with AnsibleFilterError:
> > 
> >   The reduce_on_network filter requires python's netaddr be installed 
> > on the ansible controller
> > 
> > Via pkg_add py3-netaddr problem was fixed. I was wondering, could
> > net/py-netaddr be added to ansible/ansible-core package?
> 
> 
> Hi Mikolaj,
> 
> There are lots of modules which provide additional functionality for specific
> use cases, e.g. py-jmespath for JSON parsing or py-napalm for managing
> network devices, but these are not required for basic ansible functionality 
> and
> should be added by the user. The same is about py-netaddr.
> 

I am very aware of that. I asked about netaddr because it doesn't feel
to me as a heavy dependency, but I guess not everyone has the same
level of heaviness.

-- 
Regards,
 Mikolaj



ansible run dep on netaddr python module

2022-01-12 Thread Mikolaj Kucharski
Hi,

I had fresh install of OpenBSD-current with ansible added via packages:

  pkg_add -i ansible

Running it on some of my playbooks failed with AnsibleFilterError:

  The reduce_on_network filter requires python's netaddr be installed on 
the ansible controller

Via pkg_add py3-netaddr problem was fixed. I was wondering, could
net/py-netaddr be added to ansible/ansible-core package?

-- 
Regards,
 Mikolaj



Re: Update p5-CGI-Fast to 2.16

2021-12-14 Thread Mikolaj Kucharski
Ping

On Mon, Nov 22, 2021 at 09:39:37PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> Update addresses https://github.com/leejo/cgi-fast/issues/20 and should
> not affect OpenBSD:
> 
> https://github.com/leejo/cgi-fast/compare/v2.15...v2.16
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/p5-CGI-Fast/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 Makefile
> --- Makefile  3 Jul 2020 21:45:55 -   1.5
> +++ Makefile  22 Nov 2021 21:37:59 -
> @@ -1,9 +1,8 @@
>  # $OpenBSD: Makefile,v 1.5 2020/07/03 21:45:55 sthen Exp $
>  
>  COMMENT =CGI interface for FastCGI
> -DISTNAME =   CGI-Fast-2.15
> +DISTNAME =   CGI-Fast-2.16
>  CATEGORIES = www
> -REVISION =   0
>  
>  MAINTAINER = Mikolaj Kucharski 
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/www/p5-CGI-Fast/distinfo,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 distinfo
> --- distinfo  10 May 2019 15:42:08 -  1.3
> +++ distinfo  22 Nov 2021 21:37:59 -
> @@ -1,2 +1,2 @@
> -SHA256 (CGI-Fast-2.15.tar.gz) = 5TQt89xZPt+3JMev6FCxoO51P01zP1GT4DewRjPf7s4=
> -SIZE (CGI-Fast-2.15.tar.gz) = 9277
> +SHA256 (CGI-Fast-2.16.tar.gz) = AiPX+RuAA3ud/183NgZAtx9dyNvZiaBZPV0i8/c8s9Q=
> +SIZE (CGI-Fast-2.16.tar.gz) = 9310
> 

-- 
Regards,
 Mikolaj



Update p5-CGI-Fast to 2.16

2021-11-22 Thread Mikolaj Kucharski
Hi,

Update addresses https://github.com/leejo/cgi-fast/issues/20 and should
not affect OpenBSD:

https://github.com/leejo/cgi-fast/compare/v2.15...v2.16


Index: Makefile
===
RCS file: /cvs/ports/www/p5-CGI-Fast/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile3 Jul 2020 21:45:55 -   1.5
+++ Makefile22 Nov 2021 21:37:59 -
@@ -1,9 +1,8 @@
 # $OpenBSD: Makefile,v 1.5 2020/07/03 21:45:55 sthen Exp $
 
 COMMENT =  CGI interface for FastCGI
-DISTNAME = CGI-Fast-2.15
+DISTNAME = CGI-Fast-2.16
 CATEGORIES =   www
-REVISION = 0
 
 MAINTAINER =   Mikolaj Kucharski 
 
Index: distinfo
===
RCS file: /cvs/ports/www/p5-CGI-Fast/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo10 May 2019 15:42:08 -  1.3
+++ distinfo22 Nov 2021 21:37:59 -
@@ -1,2 +1,2 @@
-SHA256 (CGI-Fast-2.15.tar.gz) = 5TQt89xZPt+3JMev6FCxoO51P01zP1GT4DewRjPf7s4=
-SIZE (CGI-Fast-2.15.tar.gz) = 9277
+SHA256 (CGI-Fast-2.16.tar.gz) = AiPX+RuAA3ud/183NgZAtx9dyNvZiaBZPV0i8/c8s9Q=
+SIZE (CGI-Fast-2.16.tar.gz) = 9310

-- 
Regards,
 Mikolaj



Update py-tenacity to 8.0.1

2021-11-22 Thread Mikolaj Kucharski
I created port of this, as I was using it in my own project,
but I cannot find it on my hard drive any more :|

https://github.com/jd/tenacity/compare/6.2.0...8.0.1

Index: Makefile
===
RCS file: /cvs/ports/devel/py-tenacity/Makefile,v
retrieving revision 1.2
diff -u -p -u -r1.2 Makefile
--- Makefile2 Nov 2021 00:01:02 -   1.2
+++ Makefile22 Nov 2021 15:02:06 -
@@ -2,10 +2,9 @@
 
 COMMENT =  Python module to retry code until it succeeds
 
-MODPY_EGG_VERSION =6.2.0
+MODPY_EGG_VERSION =8.0.1
 DISTNAME = tenacity-${MODPY_EGG_VERSION}
 PKGNAME =  py-${DISTNAME}
-REVISION = 0
 
 MAINTAINER =   Mikolaj Kucharski 
 
@@ -23,7 +22,7 @@ MODPY_PI =Yes
 
 BUILD_DEPENDS =devel/py-setuptools_scm${MODPY_FLAVOR}
 
-# depends on typeguard, currently no in ports
+# depends on typeguard, currently not in ports
 TEST_DEPENDS = www/py-tornado${MODPY_FLAVOR}
 
 FLAVORS =  python3
Index: distinfo
===
RCS file: /cvs/ports/devel/py-tenacity/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 distinfo
--- distinfo14 Nov 2020 18:21:53 -  1.1.1.1
+++ distinfo22 Nov 2021 15:02:06 -
@@ -1,2 +1,2 @@
-SHA256 (tenacity-6.2.0.tar.gz) = Ka6Q5/r0iKhihDIVS7NKzhzKWCRMbqOZ/TPwZqxxM5o=
-SIZE (tenacity-6.2.0.tar.gz) = 35213
+SHA256 (tenacity-8.0.1.tar.gz) = QyQqIOPnMpGii8vKz9bgALAtOFepqf/1ayl6J6/cky8=
+SIZE (tenacity-8.0.1.tar.gz) = 37492
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-tenacity/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 PLIST
--- pkg/PLIST   14 Nov 2020 18:21:53 -  1.1.1.1
+++ pkg/PLIST   22 Nov 2021 15:02:06 -
@@ -4,6 +4,7 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/tenacity-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
 
lib/python${MODPY_VERSION}/site-packages/tenacity-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
 
lib/python${MODPY_VERSION}/site-packages/tenacity-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/tenacity-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/pbr.json
 
lib/python${MODPY_VERSION}/site-packages/tenacity-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
 
lib/python${MODPY_VERSION}/site-packages/tenacity-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
 lib/python${MODPY_VERSION}/site-packages/tenacity/__init__.py
@@ -14,7 +15,6 @@ lib/python${MODPY_VERSION}/site-packages
 
lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}after.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}before.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}before_sleep.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}nap.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}retry.${MODPY_PYC_MAGIC_TAG}pyc
 
lib/python${MODPY_VERSION}/site-packages/tenacity/${MODPY_PYCACHE}stop.${MODPY_PYC_MAGIC_TAG}pyc
@@ -25,7 +25,6 @@ lib/python${MODPY_VERSION}/site-packages
 lib/python${MODPY_VERSION}/site-packages/tenacity/after.py
 lib/python${MODPY_VERSION}/site-packages/tenacity/before.py
 lib/python${MODPY_VERSION}/site-packages/tenacity/before_sleep.py
-lib/python${MODPY_VERSION}/site-packages/tenacity/compat.py
 lib/python${MODPY_VERSION}/site-packages/tenacity/nap.py
 lib/python${MODPY_VERSION}/site-packages/tenacity/py.typed
 lib/python${MODPY_VERSION}/site-packages/tenacity/retry.py

-- 
Regards,
 Mikolaj



NEW: security/py-hvac 0.11.2

2021-11-19 Thread Mikolaj Kucharski
Hi,

I use this module with Ansible and also some simple Python scripts.

-->8--
Python client library for Hashicorp Vault

HVAC allows accessing secrets stored in a Vault directly from
Python code.

An access token must be created first, using a separate tool
like vault or vault-client.
--8<--

I've posted this before. Here is old thread:

https://marc.info/?t=16095211171=1=2

-- 
Regards,
 Mikolaj


py-hvac-0.11.2-port.tgz
Description: application/tar-gz


freshclam doesn't use DNS any more for updates check

2021-10-29 Thread Mikolaj Kucharski
Hi Stuart,

Sorry I didn't look deeply into it and not providing a solution. I only
managed open a bug upstream:

https://github.com/Cisco-Talos/clamav/issues/340

It seems, what I didn't know, ClamAV 0.104.0 migrated to cmake. On above
GitHub issue, per comment from @micahsnyder:

> My guess is that HAVE_RESOLV_H is not defined and that either the new
> CMake build system doesn't know how to find /usr/include/resolv.h or [...]

Currently I don't spend almost any time on OpenBSD ports, but wanted to
report what I saw so far.

-- 
Regards,
 Mikolaj



Re: NEW: security/py-hvac 0.10.6

2021-09-03 Thread Mikolaj Kucharski
On Tue, Aug 24, 2021 at 07:48:45AM +, Mikolaj Kucharski wrote:
> On Mon, Aug 16, 2021 at 10:07:58AM +0000, Mikolaj Kucharski wrote:
> > On Mon, Aug 09, 2021 at 06:41:02PM +, Mikolaj Kucharski wrote:
> > > On Tue, Mar 23, 2021 at 10:53:08PM +, Mikolaj Kucharski wrote:
> > > > On Tue, Mar 23, 2021 at 10:25:13PM +, Stuart Henderson wrote:
> > > > > 
> > > > > There don't seem to be any tests in the distribution, so TEST_DEPENDS
> > > > > doesn't make much sense?
> > > > > 
> > > > > Port looks good to me but I have no way to test it.
> > > > > 
> > > > 
> > > > Dropped TEST_DEPENDS. I've used it with Ansible:
> > > > 
> > > >   bindpw: "{{ lookup('hashi_vault', 'secret=secret/... }}"
> > > > 
> > > > to fetch secrets from Vault.
> > > > 
> > > 
> > > Updated to 0.11.0
> > > 
> > > 
> > > Information for inst:py3-hvac-0.11.0
> > > 
> > > Comment:
> > > Python client library for Hashicorp Vault
> > > 
> > > Description:
> > > HVAC allows accessing secrets stored in a Vault directly from
> > > Python code.
> > > 
> > > An access token must be created first, using a separate tool
> > > like vault or vault-client.
> > > 
> > > Maintainer: Mikolaj Kucharski 
> > > 
> > > WWW: https://github.com/hvac/hvac
> > > 
> > 
> > Kind reminder. I've tested it with my own client script. It works here.
> > 
> 
> Ping. Port attached for convenience.
> 
> Thread at https://marc.info/?t=16095211171=1=2
> 

Kind reminder. Port attached.

-- 
Regards,
 Mikolaj


py-hvac-0.11.0.port.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-08-24 Thread Mikolaj Kucharski
On Mon, Aug 16, 2021 at 10:07:58AM +, Mikolaj Kucharski wrote:
> On Mon, Aug 09, 2021 at 06:41:02PM +0000, Mikolaj Kucharski wrote:
> > On Tue, Mar 23, 2021 at 10:53:08PM +, Mikolaj Kucharski wrote:
> > > On Tue, Mar 23, 2021 at 10:25:13PM +, Stuart Henderson wrote:
> > > > 
> > > > There don't seem to be any tests in the distribution, so TEST_DEPENDS
> > > > doesn't make much sense?
> > > > 
> > > > Port looks good to me but I have no way to test it.
> > > > 
> > > 
> > > Dropped TEST_DEPENDS. I've used it with Ansible:
> > > 
> > >   bindpw: "{{ lookup('hashi_vault', 'secret=secret/... }}"
> > > 
> > > to fetch secrets from Vault.
> > > 
> > 
> > Updated to 0.11.0
> > 
> > 
> > Information for inst:py3-hvac-0.11.0
> > 
> > Comment:
> > Python client library for Hashicorp Vault
> > 
> > Description:
> > HVAC allows accessing secrets stored in a Vault directly from
> > Python code.
> > 
> > An access token must be created first, using a separate tool
> > like vault or vault-client.
> > 
> > Maintainer: Mikolaj Kucharski 
> > 
> > WWW: https://github.com/hvac/hvac
> > 
> 
> Kind reminder. I've tested it with my own client script. It works here.
> 

Ping. Port attached for convenience.

Thread at https://marc.info/?t=16095211171=1=2

-- 
Regards,
 Mikolaj


py-hvac-0.11.0.port.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-08-16 Thread Mikolaj Kucharski
On Mon, Aug 09, 2021 at 06:41:02PM +, Mikolaj Kucharski wrote:
> On Tue, Mar 23, 2021 at 10:53:08PM +0000, Mikolaj Kucharski wrote:
> > On Tue, Mar 23, 2021 at 10:25:13PM +, Stuart Henderson wrote:
> > > 
> > > There don't seem to be any tests in the distribution, so TEST_DEPENDS
> > > doesn't make much sense?
> > > 
> > > Port looks good to me but I have no way to test it.
> > > 
> > 
> > Dropped TEST_DEPENDS. I've used it with Ansible:
> > 
> >   bindpw: "{{ lookup('hashi_vault', 'secret=secret/... }}"
> > 
> > to fetch secrets from Vault.
> > 
> 
> Updated to 0.11.0
> 
> 
> Information for inst:py3-hvac-0.11.0
> 
> Comment:
> Python client library for Hashicorp Vault
> 
> Description:
> HVAC allows accessing secrets stored in a Vault directly from
> Python code.
> 
> An access token must be created first, using a separate tool
> like vault or vault-client.
> 
> Maintainer: Mikolaj Kucharski 
> 
> WWW: https://github.com/hvac/hvac
> 

Kind reminder. I've tested it with my own client script. It works here.

-- 
Regards,
 Mikolaj


py-hvac-0.11.0.port.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-08-09 Thread Mikolaj Kucharski
On Tue, Mar 23, 2021 at 10:53:08PM +, Mikolaj Kucharski wrote:
> On Tue, Mar 23, 2021 at 10:25:13PM +, Stuart Henderson wrote:
> > 
> > There don't seem to be any tests in the distribution, so TEST_DEPENDS
> > doesn't make much sense?
> > 
> > Port looks good to me but I have no way to test it.
> > 
> 
> Dropped TEST_DEPENDS. I've used it with Ansible:
> 
>   bindpw: "{{ lookup('hashi_vault', 'secret=secret/... }}"
> 
> to fetch secrets from Vault.
> 

Updated to 0.11.0


Information for inst:py3-hvac-0.11.0

Comment:
Python client library for Hashicorp Vault

Description:
HVAC allows accessing secrets stored in a Vault directly from
Python code.

An access token must be created first, using a separate tool
like vault or vault-client.

Maintainer: Mikolaj Kucharski 

WWW: https://github.com/hvac/hvac

-- 
Regards,
 Mikolaj


py-hvac-0.11.0.port.tgz
Description: application/tar-gz


Re: unbreak games/supertux [Was: Re: games/supertux startup error]

2021-04-17 Thread Mikolaj Kucharski
On Sat, Apr 17, 2021 at 06:08:39AM -0700, Nam Nguyen wrote:
> --- distinfo  4 Feb 2019 10:02:07 -   1.4
> +++ distinfo  17 Apr 2021 12:34:44 -
> @@ -1,2 +1,4 @@
>  SHA256 (SuperTux-v0.6.0-Source.tar.gz) = 
> xMPl+m+Q6HuMWtayKheempg5v5l+fyGeIrvNHJciOsA=
> +SHA256 (tux-statue.tar.gz) = pklNyse27KSCvf8xR41Y4DQ8OCJQu36Z2PtooYJ1Ad4=
>  SIZE (SuperTux-v0.6.0-Source.tar.gz) = 131203604
> +SIZE (tux-statue.tar.gz) = 10385

I would make this filename more unique with a date, version
number or an ID of GitHub issue.

-- 
Regards,
 Mikolaj



speedtest-cli - ValueError: invalid literal for int() with base 10

2021-04-09 Thread Mikolaj Kucharski
Hi,

This should go upsteam, but I just noticed this on multiple -current
machines. I see that v2.1.3 was released yesterday and at first glance
last commit in repo looks like could fix below issue. Sorry, didn't dive
deeper and I'm not sure will I be able until next weekend :/

$ speedtest-cli
Retrieving speedtest.net configuration...
Traceback (most recent call last):
  File "/usr/local/bin/speedtest-cli", line 11, in 
load_entry_point('speedtest-cli==2.1.2', 'console_scripts', 
'speedtest-cli')()
  File "/usr/local/lib/python3.8/site-packages/speedtest.py", line 1986, in main
shell()
  File "/usr/local/lib/python3.8/site-packages/speedtest.py", line 1872, in 
shell
speedtest = Speedtest(
  File "/usr/local/lib/python3.8/site-packages/speedtest.py", line 1091, in 
__init__
self.get_config()
  File "/usr/local/lib/python3.8/site-packages/speedtest.py", line 1173, in 
get_config
ignore_servers = list(
ValueError: invalid literal for int() with base 10: ''

-- 
Regards,
 Mikolaj



Re: NEW: graphics/promplot

2021-03-27 Thread Mikolaj Kucharski
Hi,

On Fri, Mar 26, 2021 at 08:28:05AM -0600, Aaron Bieber wrote:
> 
> Mikolaj Kucharski writes:
> 
> > Kind reminder.
> >
> > On Mon, Jan 25, 2021 at 03:51:16PM +, Mikolaj Kucharski wrote:
> >> Hi,
> >> 
> >> I was looking for a tool which can easily generate a screenshot
> >> from Prometheus metrics and I found:
> >> 
> >>https://github.com/qvl/promplot
> >> 
> >> > Comment:
> >> > create plots from Prometheus metrics
> >> >
> >> > Description:
> >> > promplot is an opinionated tool to create plots from Prometheus
> >> > metrics and automatically sends them to Slack or saves the image
> >> > to a file or stdout.
> >> 
> >> With help from Aaron Bieber I've created attached port. It compiles and
> >> I can generate PNG files with Prometheus metrics via the tool.
> >> 
> 
> 
> No need for $V:
> 
> 
> # $OpenBSD$
> 
> COMMENT =   create plots from Prometheus metrics
> 
> MODGO_MODNAME = qvl.io/promplot
> MODGO_VERSION = v0.17.0
> 
> DISTNAME =  promplot-${MODGO_VERSION}
> 
> CATEGORIES =graphics
> 
> 
> is sufficient. go.port.mk handles the package name stuff.
> 
> With the above change OK abieber@ for import. If someone wants to commit
> it :D

Updated port, per above request, attached.

-- 
Regards,
 Mikolaj


promplot-0.17.0.port-v2.tgz
Description: application/tar-gz


Re: Interest check: gh (github's cli)

2021-03-23 Thread Mikolaj Kucharski
On Tue, Mar 23, 2021 at 10:18:07PM +, Stuart Henderson wrote:
> 
> OK sthen with these added
> 
> BROKEN-aarch64=   old kr/pty doesn't support OpenBSD arm arches; needs 
> creack/pty@v1.1.11
> BROKEN-armv7= old kr/pty doesn't support OpenBSD arm arches; needs 
> creack/pty@v1.1.11
> 

Port updated with broken markers for aarch64 and armv7 added.

-- 
Regards,
 Mikolaj


github-cli-1.7.0.port-v2.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-03-23 Thread Mikolaj Kucharski
On Tue, Mar 23, 2021 at 10:25:13PM +, Stuart Henderson wrote:
> 
> There don't seem to be any tests in the distribution, so TEST_DEPENDS
> doesn't make much sense?
> 
> Port looks good to me but I have no way to test it.
> 

Dropped TEST_DEPENDS. I've used it with Ansible:

  bindpw: "{{ lookup('hashi_vault', 'secret=secret/... }}"

to fetch secrets from Vault.

-- 
Regards,
 Mikolaj


py-hvac-0.10.8.port-v2.tgz
Description: application/tar-gz


Re: Interest check: gh (github's cli)

2021-03-23 Thread Mikolaj Kucharski
On Wed, Mar 10, 2021 at 07:31:50PM +, Mikolaj Kucharski wrote:
> On Sun, Jan 24, 2021 at 02:25:14PM +0000, Mikolaj Kucharski wrote:
> > 
> > See new port version attached. It contains 1.5.0, which I didn't had a
> > chance to properly test, as I've updated the port today.
> > 
> > From port perspective comparing to github-cli,2.tgz from Stuart
> > Henderson, I've:
> > 
> > - updated $V to 1.5.0
> > - make makesum
> > - ran make modgo-gen-modules
> > - update Makefile with new MODGO_MODULES and MODGO_MODFILES
> > - make makesum again
> > - updated plist
> > - added MODGO_LDFLAGS so gh version prints proper version
> > - make package
> > - gh version works as expected, and prints 1.5.0 instead of DEV
> > 
> 
> Updated port to 1.7.0 version attached.
> 

Tested lightly, but regularly, as I don't use a lot of API codepaths.
Create or list issues, create pull requests. Works for me.

-- 
Regards,
 Mikolaj


github-cli-1.7.0.port.tgz
Description: application/tar-gz


Re: NEW: graphics/promplot

2021-03-23 Thread Mikolaj Kucharski
Kind reminder.

On Mon, Jan 25, 2021 at 03:51:16PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> I was looking for a tool which can easily generate a screenshot
> from Prometheus metrics and I found:
> 
>   https://github.com/qvl/promplot
> 
> > Comment:
> > create plots from Prometheus metrics
> >
> > Description:
> > promplot is an opinionated tool to create plots from Prometheus
> > metrics and automatically sends them to Slack or saves the image
> > to a file or stdout.
> 
> With help from Aaron Bieber I've created attached port. It compiles and
> I can generate PNG files with Prometheus metrics via the tool.
> 

-- 
Regards,
 Mikolaj


promplot-0.17.0-port.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-03-23 Thread Mikolaj Kucharski
Kind reminder.

On Tue, Mar 09, 2021 at 09:23:02PM +, Mikolaj Kucharski wrote:
> Updated the port to 0.10.8
> 
> On Sun, Jan 24, 2021 at 12:54:17PM +, Mikolaj Kucharski wrote:
> > Hi,
> > 
> > Kind reminder. Port reattached for convenience.
> > 
> > On Fri, Jan 01, 2021 at 05:08:59PM +, Mikolaj Kucharski wrote:
> > > 
> > > I'm using py3-hvac Python module to fetch Vault secrets from Ansible via
> > > its hashi_vault lookup plugin.
> > > 
> > > > Comment:
> > > > Python client library for Hashicorp Vault
> > > >
> > > > Description:
> > > > HVAC allows accessing secrets stored in a Vault directly from
> > > > Python code.
> > > >
> > > > An access token must be created first, using a separate tool
> > > > like vault or vault-client.
> > > 
> > > I've made it Python3-only port. Comments?
> > > 

-- 
Regards,
 Mikolaj


py-hvac-0.10.8.port.tgz
Description: application/tar-gz


Re: go-module(5): problematic ALL_TARGET and cmd directory handling

2021-03-18 Thread Mikolaj Kucharski
On Wed, Mar 17, 2021 at 11:56:12PM -0400, Josh Rickmar wrote:
> Here is an ugly hack, but it solves an issue I hit while testing
> portgen(1).
> 
> A project I was testing a port for uses a repo structure where the
> project's primary executable package is contained in the root of the
> repo, with some optional and auxiliary executables found under a "cmd"
> directory.
> 
> go.port.mk does not work well with this project layout, because the
> do-build target notices the cmd directory exists and will only install
> "${ALL_TARGET}/cmd/...".  The port builds, but is missing the
> executable that should be installed by the port.  Even if I modify my
> ALL_TARGET, it will still never build the right thing.
> 
> The only workaround is to redefine do-build, and I think we can do
> better than that.
> 
> The 'go list' command can be used to tell if any packages defined in
> ALL_TARGET are a main package.  The patch below will run an additional
> 'go install' command to build ALL_TARGET if this is the case.
> 
> The patch also tries to keep the existing "cmd" behavior.  In addition
> to building ALL_TARGET if it has main packages, if the cmd directory
> exists, ./cmd/... will also be built.  Note that this is no longer
> concatenating ALL_TARGET to 'cmd/...', as this will obviously break if
> ALL_TARGET is multiple words (many packages can be listed together,
> separated by spaces), or ALL_TARGET itself ends in '...'.
> 
> Personally, I am not a fan of the "cmd" behavior being done here, and
> would prefer each port Makefile to set ALL_TARGET to ./cmd/... if that
> is what should be built.  If this were to change though, then all
> ports relying on this behavior would need updates, and it's not
> immediately obvious which ports would be broken by this change.
> 
> On to the patch itself, you will see that I'm grepping the output of
> 'go list' to find if there are any main packages.  The search pattern
> used here should be '^main$', but this was causing a variable
> expansion and an unquoted string, so the patch is only using ^main for
> now.  I'm definitely open to suggestions on how to better deal with
> this.
> 
> diff 6eaf30816f4def2f40cb2b765a3aa33ae11ae4a8 /usr/ports
> blob - 3c137447b5e134aea6cbb3f9ad5d8dccfd27e234
> file + lang/go/go.port.mk
> --- lang/go/go.port.mk
> +++ lang/go/go.port.mk
> @@ -52,11 +52,13 @@ MAKE_ENV +=   GOCACHE="${MODGO_GOCACHE}"
>  
>  MODGO_CMD ?= ${SETENV} ${MAKE_ENV} go
>  MODGO_BUILD_CMD =${MODGO_CMD} install ${MODGO_FLAGS}
> +MODGO_LIST_CMD = ${MODGO_CMD} list ${MODGO_FLAGS}
>  MODGO_TEST_CMD = ${MODGO_CMD} test ${MODGO_FLAGS} ${MODGO_TEST_FLAGS}
>  MODGO_BINDIR ?=  bin
>  
>  .if ! empty(MODGO_LDFLAGS)
>  MODGO_BUILD_CMD +=   -ldflags="${MODGO_LDFLAGS}"
> +MODGO_LIST_CMD +=-ldflags="${MODGO_LDFLAGS}"
>  MODGO_TEST_CMD +=-ldflags="${MODGO_LDFLAGS}"
>  .endif
>  
> @@ -153,12 +155,13 @@ do-build:
>   cd ${WRKSRC} && \
>   ${MODGO_BUILD_TARGET}
>  .else
> + cd ${WRKSRC} && \
> + ${MODGO_LIST_CMD} -f '{{.Name}}' ${ALL_TARGET} 2>/dev/null \
> + | grep ^main >/dev/null && \

Not tested, but does below help?

| grep -qe '^main$$' && \


> + ${MODGO_BUILD_CMD} ${ALL_TARGET} ; \
>   if [ -d ${WRKSRC}/cmd ]; then \
>   cd ${WRKSRC} && \
> - ${MODGO_BUILD_CMD} ${ALL_TARGET}/cmd/... ; \
> - else \
> - cd ${WRKSRC} && \
> - ${MODGO_BUILD_CMD} ${ALL_TARGET} ; \
> + ${MODGO_BUILD_CMD} ./cmd/... ; \
>   fi;
>  .endif
>  .  endif
> 

-- 
Regards,
 Mikolaj



Re: Interest check: gh (github's cli)

2021-03-10 Thread Mikolaj Kucharski
On Sun, Jan 24, 2021 at 02:25:14PM +, Mikolaj Kucharski wrote:
> 
> See new port version attached. It contains 1.5.0, which I didn't had a
> chance to properly test, as I've updated the port today.
> 
> From port perspective comparing to github-cli,2.tgz from Stuart
> Henderson, I've:
> 
> - updated $V to 1.5.0
> - make makesum
> - ran make modgo-gen-modules
> - update Makefile with new MODGO_MODULES and MODGO_MODFILES
> - make makesum again
> - updated plist
> - added MODGO_LDFLAGS so gh version prints proper version
> - make package
> - gh version works as expected, and prints 1.5.0 instead of DEV
> 

Updated port to 1.7.0 version attached.

-- 
Regards,
 Mikolaj


github-cli-1.7.0.port.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-03-09 Thread Mikolaj Kucharski
Updated the port to 0.10.8

On Sun, Jan 24, 2021 at 12:54:17PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> Kind reminder. Port reattached for convenience.
> 
> On Fri, Jan 01, 2021 at 05:08:59PM +, Mikolaj Kucharski wrote:
> > 
> > I'm using py3-hvac Python module to fetch Vault secrets from Ansible via
> > its hashi_vault lookup plugin.
> > 
> > > Comment:
> > > Python client library for Hashicorp Vault
> > >
> > > Description:
> > > HVAC allows accessing secrets stored in a Vault directly from
> > > Python code.
> > >
> > > An access token must be created first, using a separate tool
> > > like vault or vault-client.
> > 
> > I've made it Python3-only port. Comments?
> > 

-- 
Regards,
 Mikolaj


py-hvac-0.10.8.port.tgz
Description: application/tar-gz


Re: quirks botched commit

2021-02-25 Thread Mikolaj Kucharski
On Thu, Feb 25, 2021 at 10:16:03AM +, Mikolaj Kucharski wrote:
> On Thu, Feb 25, 2021 at 11:04:06AM +0100, Marc Espie wrote:
> > On Thu, Feb 25, 2021 at 09:53:04AM +0100, Marc Espie wrote:
> > > next time, please remember to build it.
> > > there's a reason do-build checks the syntax of those perl files.
> > 
> > morning brainfart, of course it built. Which begs the question how come the
> > syntax check didn't get it
> > 
> 
> $ find files/ -type f -name \*.pm -print -exec /usr/bin/false \;
> files/Quirks.pm
> files/Quirks/ghc.pm
> 
> $ echo $?
> 0
> 

Below gives expected result of failure.

$ find files/ -type f -name \*.pm -print0 | xargs -r0t -I% perl -c %
perl -c files/Quirks/ghc.pm
files/Quirks/ghc.pm syntax OK
perl -c files/Quirks.pm
String found where operator expected at files/Quirks.pm line 2196, near 
""Upstrem moved to unversioned tarballs, use the plan9port (same upstream) 
package instead""
(Missing semicolon on previous line?)
syntax error at files/Quirks.pm line 2196, near ""Upstrem moved to unversioned 
tarballs, use the plan9port (same upstream) package instead""
files/Quirks.pm had compilation errors.
xargs: perl exited with status 255

$ echo $?
124

-- 
Regards,
 Mikolaj



Re: quirks botched commit

2021-02-25 Thread Mikolaj Kucharski
On Thu, Feb 25, 2021 at 11:04:06AM +0100, Marc Espie wrote:
> On Thu, Feb 25, 2021 at 09:53:04AM +0100, Marc Espie wrote:
> > next time, please remember to build it.
> > there's a reason do-build checks the syntax of those perl files.
> 
> morning brainfart, of course it built. Which begs the question how come the
> syntax check didn't get it
> 

$ find files/ -type f -name \*.pm -print -exec /usr/bin/false \;
files/Quirks.pm
files/Quirks/ghc.pm

$ echo $?
0

-- 
Regards,
 Mikolaj



Re: Creating package debug... Fatal error: can't parse comment is too long

2021-02-04 Thread Mikolaj Kucharski
Marc, Stuart,

Does that mean it's okay to commit below change?

Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1542
diff -u -p -u -r1.1542 bsd.port.mk
--- bsd.port.mk 26 Jun 2020 11:51:16 -  1.1542
+++ bsd.port.mk 1 Jan 2021 19:48:31 -
@@ -1201,7 +1201,7 @@ _pkg_cookie${_S} = ${_PACKAGE_COOKIE${_S
 .  if ${DEBUG_PACKAGES:M${_S}}
 _DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
 _DBG_PKG_ARGS${_S} += 
-P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
-_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
+_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${PKGSTEM${_S}}"
 _DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
 # XXX revisit that fullpkgpath later ?
 _DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}


Full thread at https://marc.info/?t=16095308942=1=2

On Tue, Feb 02, 2021 at 01:05:14PM +0100, Marc Espie wrote:
> On Tue, Feb 02, 2021 at 11:45:24AM +, Stuart Henderson wrote:
> > On 2021/02/02 10:05, Marc Espie wrote:
> > > On Sun, Jan 24, 2021 at 09:50:50PM +, Stuart Henderson wrote:
> > > > You are correct that it will require bumping every port that has
> > > > debug packages. It might be better to only change the comment
> > > > if it's too long (so that existing ones aren't changed).
> > > 
> > > Actually, I'm not sure it's strictly required. In fact it's not.
> > > 
> > > See, debug packages don't go through register-plist, so changes
> > > are not really a problem with them.
> > 
> > Oh, that's a bit of luck!
> 
> More of a design property actually :)
> 
> There's an explicit test in the packaging loop to avoid registering
> debug-packages, for several reasons
> - their packing-lists don't exist independently of normal packages
> - I don't think you'd fancy twice that many files in the plist directory
> - it allowed for rapid development while in-tree, as the generating code
> has had to evolve several times.
> 

-- 
Regards,
 Mikolaj



PDFs preview in Chrome on Slack.com not working

2021-02-04 Thread Mikolaj Kucharski
Hi,

It started couple of weeks ago I think, and it definitely worked in the
past. When there is PDF uploaded on a Slack channel I can see preview
generated inline on the channel, but when I click to view, there is no
view of the PDF content, just broken in half grey image symbolizing that
something went wrong.

Anyone else seeing this?

>From that preview when I click three dots and then Open in new window,
Chromium's built-in PDF preview works and I can see PDF content, but I
would like to also see working preview in Slack itself and not sure is
this local or general problem.

# pkg_info -qI chromium
chromium-88.0.4324.96p0

# sysctl -n kern.version
OpenBSD 6.8-current (GENERIC.MP) #302: Sat Jan 30 21:51:53 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

-- 
Regards,
 Mikolaj



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

2021-02-01 Thread Mikolaj Kucharski
Hi,

This happens for a while, but recently I don't have good chunk of time
to dive and provide a diff. Decided to finally sent an email.

(I do have some not committed port on my machine)

# pkg_add -Dupdate -Dupdatedepends -Drepair -u -U -V
quirks-3.524 signed on 2021-01-30T16:42:18Z
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+py3-sip-qt5-5.5.0->py-qt5-5.15.2+py3-sip-qt5-5.5.0p0: can't 
resolve py-sip-4.19.24v0
Couldn't find updates for github-cli-1.5.0 promplot-0.17.0 py-qt5-5.13.2p1 
py-sip-4.19.19p0v0 py-sip-qt5-4.19.19p0 py3-hvac-0.10.6pre0 py3-sip-qt5-5.5.0
Couldn't install py-qt5-5.15.2 py-sip-4.19.24v0 py3-sip-qt5-5.5.0p0

-- 
Regards,
 Mikolaj



Re: libusb patches merged - add comments to github commits

2021-01-27 Thread Mikolaj Kucharski
This is mintor, but maybe worth committing?

On Fri, Jan 15, 2021 at 04:42:16PM +, Mikolaj Kucharski wrote:
> Hi
> 
> Below patches are merged into master on libusb repo. There is only one
> last patch left for libusb/libusb.h file, but not sure is that patch
> really needed today.
> 
> Index: patch-libusb_core_c
> ===
> RCS file: /cvs/ports/devel/libusb1/patches/patch-libusb_core_c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 patch-libusb_core_c
> --- patch-libusb_core_c   27 Nov 2019 20:15:17 -  1.6
> +++ patch-libusb_core_c   15 Jan 2021 16:37:32 -
> @@ -3,6 +3,8 @@ $OpenBSD: patch-libusb_core_c,v 1.6 2019
>  On OpenBSD USB controllers are shown as normal devices, making the
>  itinial limit too small. On a recent machine this value is almost
>  always exceeded, so bump it.
> +https://github.com/libusb/libusb/pull/835
> +https://github.com/libusb/libusb/commit/1f25bb7ff06e3864e8238ec118958d23800d7865
>  
>  Index: libusb/core.c
>  --- libusb/core.c.orig
> Index: patch-libusb_os_openbsd_usb_c
> ===
> RCS file: /cvs/ports/devel/libusb1/patches/patch-libusb_os_openbsd_usb_c,v
> retrieving revision 1.10
> diff -u -p -u -r1.10 patch-libusb_os_openbsd_usb_c
> --- patch-libusb_os_openbsd_usb_c 5 Aug 2020 13:59:36 -   1.10
> +++ patch-libusb_os_openbsd_usb_c 15 Jan 2021 16:37:32 -
> @@ -2,11 +2,13 @@ $OpenBSD: patch-libusb_os_openbsd_usb_c,
>  
>  Export port number, fix github #314.
>  https://github.com/libusb/libusb/pull/764
> +https://github.com/libusb/libusb/commit/96898a25ccfde6e87737991000a41695ed6b3812
>  
>  Fix an OpenBSD backend bug where an existing open file descriptor is
>  overwritten if a libusb user attempts to open the same ugen(4) device
>  multiple times. This was observed with sane-backends and broke scanning.
>  https://github.com/libusb/libusb/pull/763
> +https://github.com/libusb/libusb/commit/94519df868e59a7ea133b12c92823733645f8877
>  
>  Index: libusb/os/openbsd_usb.c
>  --- libusb/os/openbsd_usb.c.orig
> 

-- 
Regards,
 Mikolaj



Re: promplot - assistance with golang port

2021-01-25 Thread Mikolaj Kucharski
On Mon, Jan 25, 2021 at 09:04:03AM -0700, Aaron Bieber wrote:
> 
> > Thank you! <3
> >
> > Do you see something like this on your end by any chance?
> >
> > $ make modgo-gen-modules
> > malformed JSON string, neither array, object, number, string or atom, at 
> > character offset 0 (before "(end of string)") at 
> > /home/mkucharski/openbsd/ports/infrastructure/bin/../lib/OpenBSD/PortGen/Port.pm
> >  line 58.
> > *** Error 255 in /home/mkucharski/openbsd/mystuff/graphics/promplot 
> > (/home/mkucharski/openbsd/ports/lang/go/go.port.mk:183 'modgo-gen-modules')
> >
> > I know your port had MODGO_MODULES and MODGO_MODFILES generated, but I
> > just run above make command as a test and it failed.
> 
> Ya. There are a combo of things happening:
> 
> 1. https://proxy.golang.org/qvl.io/promplot/@v/v0.16.0.mod shows no
>dependencies
> 2. The version comparison check in the portgen code is incorrect and the
>versions listed on https://proxy.golang.org/qvl.io/promplot/@v/list
>are not being correctly chosen.
> 
> I have a in-tree diff that isn't ready yet, but fixes the issues. I am
> not sure why v0.16.0.mod shows no dependencies. It could be that
> upstream pushed it before actually having the deps filled out.. I
> haven't looked yet.

I see. Thanks again for helping me with creating the port.

-- 
Regards,
 Mikolaj



NEW: graphics/promplot

2021-01-25 Thread Mikolaj Kucharski
Hi,

I was looking for a tool which can easily generate a screenshot
from Prometheus metrics and I found:

https://github.com/qvl/promplot

> Comment:
> create plots from Prometheus metrics
>
> Description:
> promplot is an opinionated tool to create plots from Prometheus
> metrics and automatically sends them to Slack or saves the image
> to a file or stdout.

With help from Aaron Bieber I've created attached port. It compiles and
I can generate PNG files with Prometheus metrics via the tool.

-- 
Regards,
 Mikolaj


promplot-0.17.0-port.tgz
Description: application/tar-gz


Re: promplot - assistance with golang port

2021-01-25 Thread Mikolaj Kucharski
On Mon, Jan 25, 2021 at 07:48:09AM -0700, Aaron Bieber wrote:
> On Mon, 25 Jan 2021 at 07:40:56 -0700, Aaron Bieber wrote:
> > On Sun, 24 Jan 2021 at 14:38:01 +, Mikolaj Kucharski wrote:
> > > If some kind soul could push me in the right direction, I would greatly
> > > appreciate it. See reattached port, what I have so far.
> > > 
> > > On Fri, Jan 01, 2021 at 02:17:31PM +, Mikolaj Kucharski wrote:
> > > > 
> > > > I looking for a tool which can easily generate a screenshot from
> > > > Prometheus metrics and I found https://github.com/qvl/promplot
> > > > 
> > > > I have work in progress port, but it fails to build with:
> > > > 
> > > > ...
> > > >  go install -modcacherw -v -p 1 github.com/qvl/promplot ;  fi;
> > > > cannot find module providing package github.com/qvl/promplot: working 
> > > > directory is not part of a module
> > > > *** Error 1 in . (/home/mkucharski/openbsd/ports/lang/go/go.port.mk:153 
> > > > 'do-build')
> > > > 
> > > > Any idea what I'm doing wrong?
> > 
> > MODGO_MODNAME needs to be set to the actual Go module name. Not a git repo.
> > 
> > The module name will be the first like in the 'go.mod' file. In this case 
> > it's
> > "qvl.io/promplot".
> > 
> > Normally, I would recommend creating the initial port with portgen, but it
> > seems that this program hits a few bugs. I'll poke at it and see if I can 
> > come
> > up with a fix.
> > 
> 
> Attached is a portgen'd version (found the bug, but I need to do more 
> testing).
> 
> This should be enough to get ya going!
> 

Thank you! <3

Do you see something like this on your end by any chance?

$ make modgo-gen-modules
malformed JSON string, neither array, object, number, string or atom, at 
character offset 0 (before "(end of string)") at 
/home/mkucharski/openbsd/ports/infrastructure/bin/../lib/OpenBSD/PortGen/Port.pm
 line 58.
*** Error 255 in /home/mkucharski/openbsd/mystuff/graphics/promplot 
(/home/mkucharski/openbsd/ports/lang/go/go.port.mk:183 'modgo-gen-modules')

I know your port had MODGO_MODULES and MODGO_MODFILES generated, but I
just run above make command as a test and it failed.

-- 
Regards,
 Mikolaj



Re: Creating package debug... Fatal error: can't parse comment is too long

2021-01-24 Thread Mikolaj Kucharski
I didn't receive any feedback. Would like to hear your thoughts. As
below diff helps me in certain way, I would like to have this change
incorporated into OpenBSD ports tree.

On Fri, Jan 01, 2021 at 07:53:42PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> I often generate my own distfiles from git checkout when I debug code
> from OpenBSD ports tree. Some of the ports have already debug packages
> defined. Sample debug package looks as follows:
> 
> # pkg_info -I debug-sane-backends
> debug-sane-backends-1.0.31p1 debug info for sane-backends-1.0.31p1
> debug-sane-backends-1.0.31p1-snmp debug info for sane-backends-1.0.31p1-snmp
> 
> As you can see package version ends up inside the COMMENT. When I
> generate my debugging distfiles, they are usually generated from
> git repos as most projects are currently hosted on GitHub and that's
> git. Here is example distfile:
> 
> sane-backends-1.0.31.0.20201130.120702.git.e3e397556.tar.gz
> 
> and I generate it something a long the lines of:
> 
> git archive --format=tar --prefix="$prefix.0.$date.git.$sha/" $hash | gzip 
> -9nf
> 
> I find that naming convention useful to me. However with that long
> versioning it goes over the limit of 60 characters in COMMENT, per code
> in OpenBSD/PkgCreate.pm, function add_description().
> 
> Looking at current code in bsd.port.mk:
> 
> 1201.  if ${DEBUG_PACKAGES:M${_S}}
> 1202_DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
> 1203_DBG_PKG_ARGS${_S} += 
> -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
> 1204_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
> 1205_DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
> 1206# XXX revisit that fullpkgpath later ?
> 1207_DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
> 1208_DBG_PKG_ARGS${_S} += -f ${_WRKDEBUG}/${PLIST${_S}:T}
> 1209_EXCLUDE_DEBUG_PLISTS += ${_WRKDEBUG}/${PLIST${_S}:T}
> 1210_pkg${_S} += ${_DBG_PKGFILE${_S}}
> 1211_pkg_cookie${_S} += ${_DBG_PACKAGE_COOKIE${_S}}
> 1212.  endif
> 
> We see that version information is also inside description of the
> package:
> 
> # pkg_info debug-sane-backends-- | grep -A1 -E '^(Comment|Description)'
> Comment:
> debug info for sane-backends-1.0.31p1
> Description:
> debug info for sane-backends-1.0.31p1
> 
> So my proposition is to just drop the version part from the comment:
> 
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1542
> diff -u -p -u -r1.1542 bsd.port.mk
> --- bsd.port.mk   26 Jun 2020 11:51:16 -  1.1542
> +++ bsd.port.mk   1 Jan 2021 19:48:31 -
> @@ -1201,7 +1201,7 @@ _pkg_cookie${_S} = ${_PACKAGE_COOKIE${_S
>  .  if ${DEBUG_PACKAGES:M${_S}}
>  _DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
>  _DBG_PKG_ARGS${_S} += 
> -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
> -_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
> +_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${PKGSTEM${_S}}"
>  _DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
>  # XXX revisit that fullpkgpath later ?
>  _DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
> 
> However I think that would require to bump all debug packages across the
> entire OpenBSD ports tree, right? Anyway, I would love to see above diff
> committed. Comments?
> 

-- 
Regards,
 Mikolaj



Re: promplot - assistance with golang port

2021-01-24 Thread Mikolaj Kucharski
If some kind soul could push me in the right direction, I would greatly
appreciate it. See reattached port, what I have so far.

On Fri, Jan 01, 2021 at 02:17:31PM +, Mikolaj Kucharski wrote:
> 
> I looking for a tool which can easily generate a screenshot from
> Prometheus metrics and I found https://github.com/qvl/promplot
> 
> I have work in progress port, but it fails to build with:
> 
> ...
>  go install -modcacherw -v -p 1 github.com/qvl/promplot ;  fi;
> cannot find module providing package github.com/qvl/promplot: working 
> directory is not part of a module
> *** Error 1 in . (/home/mkucharski/openbsd/ports/lang/go/go.port.mk:153 
> 'do-build')
> 
> Any idea what I'm doing wrong?
> 

-- 
Regards,
 Mikolaj


promplot-0.16.0-port.tgz
Description: application/tar-gz


Re: NEW: security/py-hvac 0.10.6

2021-01-24 Thread Mikolaj Kucharski
Hi,

Kind reminder. Port reattached for convenience.

On Fri, Jan 01, 2021 at 05:08:59PM +, Mikolaj Kucharski wrote:
> 
> I'm using py3-hvac Python module to fetch Vault secrets from Ansible via
> its hashi_vault lookup plugin.
> 
> > Comment:
> > Python client library for Hashicorp Vault
> >
> > Description:
> > HVAC allows accessing secrets stored in a Vault directly from
> > Python code.
> >
> > An access token must be created first, using a separate tool
> > like vault or vault-client.
> 
> I've made it Python3-only port. Comments?
> 

-- 
Regards,
 Mikolaj


py-hvac-0.10.6.port.tgz
Description: application/tar-gz


Re: remove sysutils/upobsd

2021-01-17 Thread Mikolaj Kucharski
On Sun, Jan 17, 2021 at 09:06:05AM -0500, Daniel Jakots wrote:
> On Sun, 17 Jan 2021 12:10:58 +0100, Sebastien Marie 
> wrote:
> 
> > I would like to know if someone still needs upobsd or if it is
> > removable ?
> 
> I would like it to stay for the (I)nstallation part. Of course for the
> (U)pgrade part, people should indeed use sysupgrade.
> 
> I use the install part because some providers don't provide a
> pleasant-to-use console. Since I never use the default partitioning, I
> just craft a special bsd.rd with upobsd, put in /bsd, and reboot.

My use case is the same. I don't reinstall that often, as I usually I
stick to a provider for long time, but that's how I've used upobsd in
the past.

> If you still want to remove it, can you send me the latest sources?
> I'll sort it out next time I need it.
> 

-- 
Regards,
 Mikolaj



libusb patches merged - add comments to github commits

2021-01-15 Thread Mikolaj Kucharski
Hi

Below patches are merged into master on libusb repo. There is only one
last patch left for libusb/libusb.h file, but not sure is that patch
really needed today.

Index: patch-libusb_core_c
===
RCS file: /cvs/ports/devel/libusb1/patches/patch-libusb_core_c,v
retrieving revision 1.6
diff -u -p -u -r1.6 patch-libusb_core_c
--- patch-libusb_core_c 27 Nov 2019 20:15:17 -  1.6
+++ patch-libusb_core_c 15 Jan 2021 16:37:32 -
@@ -3,6 +3,8 @@ $OpenBSD: patch-libusb_core_c,v 1.6 2019
 On OpenBSD USB controllers are shown as normal devices, making the
 itinial limit too small. On a recent machine this value is almost
 always exceeded, so bump it.
+https://github.com/libusb/libusb/pull/835
+https://github.com/libusb/libusb/commit/1f25bb7ff06e3864e8238ec118958d23800d7865
 
 Index: libusb/core.c
 --- libusb/core.c.orig
Index: patch-libusb_os_openbsd_usb_c
===
RCS file: /cvs/ports/devel/libusb1/patches/patch-libusb_os_openbsd_usb_c,v
retrieving revision 1.10
diff -u -p -u -r1.10 patch-libusb_os_openbsd_usb_c
--- patch-libusb_os_openbsd_usb_c   5 Aug 2020 13:59:36 -   1.10
+++ patch-libusb_os_openbsd_usb_c   15 Jan 2021 16:37:32 -
@@ -2,11 +2,13 @@ $OpenBSD: patch-libusb_os_openbsd_usb_c,
 
 Export port number, fix github #314.
 https://github.com/libusb/libusb/pull/764
+https://github.com/libusb/libusb/commit/96898a25ccfde6e87737991000a41695ed6b3812
 
 Fix an OpenBSD backend bug where an existing open file descriptor is
 overwritten if a libusb user attempts to open the same ugen(4) device
 multiple times. This was observed with sane-backends and broke scanning.
 https://github.com/libusb/libusb/pull/763
+https://github.com/libusb/libusb/commit/94519df868e59a7ea133b12c92823733645f8877
 
 Index: libusb/os/openbsd_usb.c
 --- libusb/os/openbsd_usb.c.orig

-- 
Regards,
 Mikolaj



Creating package debug... Fatal error: can't parse comment is too long

2021-01-01 Thread Mikolaj Kucharski
Hi,

I often generate my own distfiles from git checkout when I debug code
from OpenBSD ports tree. Some of the ports have already debug packages
defined. Sample debug package looks as follows:

# pkg_info -I debug-sane-backends
debug-sane-backends-1.0.31p1 debug info for sane-backends-1.0.31p1
debug-sane-backends-1.0.31p1-snmp debug info for sane-backends-1.0.31p1-snmp

As you can see package version ends up inside the COMMENT. When I
generate my debugging distfiles, they are usually generated from
git repos as most projects are currently hosted on GitHub and that's
git. Here is example distfile:

sane-backends-1.0.31.0.20201130.120702.git.e3e397556.tar.gz

and I generate it something a long the lines of:

git archive --format=tar --prefix="$prefix.0.$date.git.$sha/" $hash | gzip -9nf

I find that naming convention useful to me. However with that long
versioning it goes over the limit of 60 characters in COMMENT, per code
in OpenBSD/PkgCreate.pm, function add_description().

Looking at current code in bsd.port.mk:

1201.  if ${DEBUG_PACKAGES:M${_S}}
1202_DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
1203_DBG_PKG_ARGS${_S} += 
-P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
1204_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
1205_DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
1206# XXX revisit that fullpkgpath later ?
1207_DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
1208_DBG_PKG_ARGS${_S} += -f ${_WRKDEBUG}/${PLIST${_S}:T}
1209_EXCLUDE_DEBUG_PLISTS += ${_WRKDEBUG}/${PLIST${_S}:T}
1210_pkg${_S} += ${_DBG_PKGFILE${_S}}
1211_pkg_cookie${_S} += ${_DBG_PACKAGE_COOKIE${_S}}
1212.  endif

We see that version information is also inside description of the
package:

# pkg_info debug-sane-backends-- | grep -A1 -E '^(Comment|Description)'
Comment:
debug info for sane-backends-1.0.31p1
Description:
debug info for sane-backends-1.0.31p1

So my proposition is to just drop the version part from the comment:

Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1542
diff -u -p -u -r1.1542 bsd.port.mk
--- bsd.port.mk 26 Jun 2020 11:51:16 -  1.1542
+++ bsd.port.mk 1 Jan 2021 19:48:31 -
@@ -1201,7 +1201,7 @@ _pkg_cookie${_S} = ${_PACKAGE_COOKIE${_S
 .  if ${DEBUG_PACKAGES:M${_S}}
 _DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
 _DBG_PKG_ARGS${_S} += 
-P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
-_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
+_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${PKGSTEM${_S}}"
 _DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
 # XXX revisit that fullpkgpath later ?
 _DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}

However I think that would require to bump all debug packages across the
entire OpenBSD ports tree, right? Anyway, I would love to see above diff
committed. Comments?

-- 
Regards,
 Mikolaj



NEW: security/py-hvac 0.10.6

2021-01-01 Thread Mikolaj Kucharski
Hi,

I'm using py3-hvac Python module to fetch Vault secrets from Ansible via
its hashi_vault lookup plugin.

> Comment:
> Python client library for Hashicorp Vault
>
> Description:
> HVAC allows accessing secrets stored in a Vault directly from
> Python code.
>
> An access token must be created first, using a separate tool
> like vault or vault-client.

I've made it Python3-only port. Comments?

-- 
Regards,
 Mikolaj


py-hvac-0.10.6.port.tgz
Description: application/tar-gz


promplot - assistance with golang port

2021-01-01 Thread Mikolaj Kucharski
Hi,

I looking for a tool which can easily generate a screenshot from
Prometheus metrics and I found https://github.com/qvl/promplot

I have work in progress port, but it fails to build with:

...
 go install -modcacherw -v -p 1 github.com/qvl/promplot ;  fi;
cannot find module providing package github.com/qvl/promplot: working directory 
is not part of a module
*** Error 1 in . (/home/mkucharski/openbsd/ports/lang/go/go.port.mk:153 
'do-build')

Any idea what I'm doing wrong?

-- 
Regards,
 Mikolaj


promplot-0.16.0-port.tgz
Description: application/tar-gz


Re: Interest check: gh (github's cli)

2021-01-01 Thread Mikolaj Kucharski
On Wed, Oct 07, 2020 at 08:13:36PM +0100, Stuart Henderson wrote:
> On 2020/10/07 19:36, Stuart Henderson wrote:
> > > go: github.com/enescakir/emoji@v1.0.0: reading 
> > > file:///home/mkucharski/openbsd/ports/distfiles/go_modules/github.com/enescakir/emoji/@v/v1.0.0.mod:
> > >  no such file or directory
> > 
> > Oh man go.port.mk is worse than I thought. It must be fetching any old files
> > from distfiles, not just the ones specified in the port Makefile.
> > 
> > I would take a look now but the kernel on my workstation started hanging
> > again :(
> 
> fsck done and not _too_ much corruption... Could you try this one please,
> I have built it after removing /usr/ports/distfiles/go_modules and it
> seems OK so I think it will work now.
> 

Sorry for so long delay. This version here is github-cli-1.1.0 and it
works for me. I'm reattaching Stuart's version in this email.

Current version of github-cli at https://github.com/cli/cli is 1.4.0,
but I think committing 1.1.0 from attached port is fine as step one. I
didn't look to update to 1.4.0 myself yet.

-- 
Regards,
 Mikolaj


github-cli,2.tgz
Description: application/tar-gz


Re: [new] x11/xpra

2020-12-16 Thread Mikolaj Kucharski
Hi,

On Wed, Dec 16, 2020 at 10:57:43AM +0100, Renaud Allard wrote:
> Hello,
> 
> Here is my first attempt at making xpra available on OpenBSD.
> Suggestions/corrections/tests are welcome.
> 
> xpra is a kind of tmux/screen for X11
> 
> Regards

I've glanced through patches directory in your port and what caught my
attention is patch-xpra_buffers_memalign_c diff.

I had my local xpra port couple of years back, but I don't use it any
more and back then I had different patch for  include.

Here is my old port:
 https://marc.info/?l=openbsd-ports=153207856621524=2

And per message:
 https://marc.info/?l=openbsd-ports=153301067923054=2

There was also openbsd-wip port at:
 https://github.com/jasperla/openbsd-wip/tree/master/x11/xpra

See below diff:

--- xpra/buffers/memalign.c.origMon Apr 18 12:03:12 2016
+++ xpra/buffers/memalign.c Fri May 20 00:37:58 2016
@@ -13,7 +13,7 @@
 #ifdef _WIN32
 #define _STDINT_H
 #endif
-#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__DragonFly__)
+#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__DragonFly__) && 
!defined(__OpenBSD__)
 #include 
 #endif

-- 
Regards,
 Mikolaj



Re: NEW: sysutils/watch (not the procps-ng one)

2020-12-13 Thread Mikolaj Kucharski
On Sun, Dec 13, 2020 at 06:37:27PM +, Stuart Henderson wrote:
> 
> I agree with the other feedback about category, multimedia would seem the
> natural choice.
> 

mwatch name would probably fit for a multimedia app?

-- 
Regards,
 Mikolaj



ports default location /usr/ports and partition sizing

2020-12-13 Thread Mikolaj Kucharski
Hi,

This is a quote from Stuart Henderson  from couple of
months ago:

> I would really recommend people just make a partition for /usr/ports and
> save the hassle and potential problems of moving it elsewhere via
> environment/ mk.conf/attempts with symlinks...

He mentions that kind of sentiment few times on the mailing list. When I
look at couple of my machines which do have ports checked out, they're
never in default /usr/ports location.

I wanted to finally have at least one machine with default location and
then ralized, no good quide what size to assign to the partition. Should
that be just part of /usr partition? I'm not sure, does the installer or
actually disklabel and its automatic disk allocation takes ports
development into account with sizing? What are your setups? Are
you having /usr/ports on /usr partition or do you create separate
partition for /usr/ports? What would be its size?

I've glanced at main Porter's Handbook page[1] and didn't find
anything about disk slicing and disk requirements.

I've looked at FAQ's Disk Partitioning[2], hier(7) and ports(7), but I
don't see any info about partition allocation and sizing. I think from
my perspective that lack of information is main contributor, why I
don't use default location for ports.

[1] https://www.openbsd.org/faq/ports/index.html
[2] https://www.openbsd.org/faq/faq4.html#Partitioning

-- 
Regards,
 Mikolaj



sane-backends, libusb and LIBUSB_ERROR_NOT_SUPPORTED in obsd_cancel_transfer()

2020-11-30 Thread Mikolaj Kucharski
Hi,

I have very unreliable results when I use my Canon MG3250 all-in-one
printer, scanner for scanning.

Most of the scanning attempts with scanimage fail:

scanimage: sane_read: Error during device I/O

I spent some time with it and from what I can see scanning fails when
libusb_cancel_transfer() from libusb returns code -12. Here is example
of failed scan:

  export LIBUSB_DEBUG=4
  scanimage --device-name pixma:04A91762_860FE4 \
--format png --mode gray --resolution 300 \
--output-file scan.png


[ 2.024756] [0008d272] libusb: debug [libusb_alloc_transfer] transfer 
0xbc317170e50
[ 2.024768] [0008d272] libusb: debug [libusb_submit_transfer] transfer 
0xbc317170e50
[ 2.024814] [0008d272] libusb: debug [obsd_submit_transfer] 
[ 2.024887] [0008d272] libusb: debug [_access_endpoint] endpoint 9 mode 0
[ 3.033570] [0008d272] libusb: debug [libusb_get_next_timeout] first timeout 
already expired
[ 3.033620] [0008d272] libusb: debug [libusb_cancel_transfer] transfer 
0xbc317170e50
[ 3.033634] [0008d272] libusb: debug [obsd_cancel_transfer] 
[ 3.033645] [0008d272] libusb: error [libusb_cancel_transfer] cancel transfer 
failed error -12
[ 3.033658] [0008d272] libusb: warning [handle_timeout] async cancel failed -12 
errno=6
[ 3.033690] [0008d272] libusb: debug [libusb_get_next_timeout] no URB with 
timeout or all handled by OS; no timeout!
[ 3.033730] [0008d272] libusb: debug [libusb_handle_events_timeout_completed] 
doing our own event handling
[ 3.033799] [0008d272] libusb: debug [handle_events] poll() 1 fds with timeout 
in 6ms
[ 3.033822] [0008d272] libusb: debug [handle_events] poll() returned 1
[ 3.033858] [0008d272] libusb: debug [handle_events] caught a fish on the event 
pipe
[ 3.033872] [0008d272] libusb: debug [usbi_handle_transfer_completion] transfer 
0xbc317170e50 has callback 0xbc2c960d550
[ 3.033899] [0008d272] libusb: debug [sync_transfer_cb] actual_length=0
[ 3.033947] [0008d272] libusb: debug [libusb_free_transfer] transfer 
0xbc317170e50


Here is the same command like above, but scanning succeeds:

[ 1.974116] [0003cf01] libusb: debug [libusb_alloc_transfer] transfer 
0x9aeef9a1550
[ 1.974138] [0003cf01] libusb: debug [libusb_submit_transfer] transfer 
0x9aeef9a1550
[ 1.974153] [0003cf01] libusb: debug [obsd_submit_transfer] 
[ 1.974190] [0003cf01] libusb: debug [_access_endpoint] endpoint 9 mode 0
[ 2.384033] [0003cf01] libusb: debug [libusb_get_next_timeout] next timeout in 
0.590119s
[ 2.384079] [0003cf01] libusb: debug [libusb_handle_events_timeout_completed] 
doing our own event handling
[ 2.384111] [0003cf01] libusb: debug [handle_events] poll() 1 fds with timeout 
in 591ms
[ 2.384131] [0003cf01] libusb: debug [handle_events] poll() returned 1
[ 2.384141] [0003cf01] libusb: debug [handle_events] caught a fish on the event 
pipe
[ 2.384152] [0003cf01] libusb: debug [usbi_handle_transfer_completion] transfer 
0x9aeef9a1550 has callback 0x9aec4f75550
[ 2.384190] [0003cf01] libusb: debug [sync_transfer_cb] actual_length=32
[ 2.384261] [0003cf01] libusb: debug [libusb_free_transfer] transfer 
0x9aeef9a1550


In failed scenario, actual_length=0 which then SANE interpreters
as SANE_STATUS_EOF (file sanei/sanei_usb.c, function
sanei_usb_read_int(), condition read_size == 0).

In successful scenario, actual_length=32 and SANE moves along and
scanning finishes successfully.

I'm kinda stuck here, as I'm not sure how to handle this. In practical
terms, scanning is extremely unrelaible and code most of the time hits
cancel transfer failed error -12 (LIBUSB_ERROR_NOT_SUPPORTED) condition.

Any tips how to tackle this?

-- 
Regards,
 Mikolaj



Re: make clean=depends to clean also test-deps

2020-11-15 Thread Mikolaj Kucharski
On Sun, Nov 15, 2020 at 01:19:47AM +0100, Marc Espie wrote:
> On Sat, Nov 14, 2020 at 07:36:31PM +0000, Mikolaj Kucharski wrote:
> > Hi,
> > 
> > Before I dig into this, would it be okay, if make clean=depends also
> > cleaned up test dependencies? I often use clean-depends to clean up all
> > dependencies, but that leaves behind ports in test dependencies.
> > 
> > Would it be okay to include test deps during make clean-depends?
> 
> That would be okay but this will be complicated.

Okay.

> Specifically, because test-depends are somewhat outside of the normal
> depends, and clean=depends uses all-dir-depends, which does not have
> test-depends.

Okay.

> and all-dir-depends shouldn't get test depends because of the way it's
> generally used.

I don't know. Would need to dig into this.
 
> So this means more variables and more targets...
> 
> The other issue is: what semantics.
> make clean=depends will clean build/run depends recursively

Yes, it does clean recursively.

> if you include test-depends, you might clean up a lot of things...
> specifically because test-depends are *outside* the normal build.

This is *exactlty* what I want. I want it to clean it all, recursively.

> So, what recursive semantics do you want for test depends ?... probably none ?

I don't understand this question.

-- 
Regards,
 Mikolaj



make clean=depends to clean also test-deps

2020-11-14 Thread Mikolaj Kucharski
Hi,

Before I dig into this, would it be okay, if make clean=depends also
cleaned up test dependencies? I often use clean-depends to clean up all
dependencies, but that leaves behind ports in test dependencies.

Would it be okay to include test deps during make clean-depends?

-- 
Regards,
 Mikolaj



Re: NEW: py-tenacity 6.2.0

2020-11-14 Thread Mikolaj Kucharski
On Sat, Nov 14, 2020 at 07:02:28PM +0100, Martin Reindl wrote:
> Am 14.11.20 um 09:31 schrieb Mikolaj Kucharski:
> > Hi,
> > 
> > : Python module to retry code until it succeeds
> > :
> > : Tenacity is a general-purpose retrying library, written in Python,
> > : to simplify the task of adding retry behavior to just about anything.
> > 
> > Regress test fails only on one test, because Python `typeguard` module
> > is not available, as a test dependency.
> > 
> > I've put it into CATEGORIES = sysutils devel, but not sure is this good
> > fit.
> > 
> > I think COMMENT could be tweaked for better English.
> > 
> > Other than that, it works here. I've made it Python3-only, I'm not sure
> > will it ever work on Python2.
> > 
> > Comments, okays?
> > 
> 
> Needs py-setuptools_scm as BDEP. I think this should go into devel, not
> sure about sysutils as it contains no executable. Please also add a
> comment about missing typeguard for TDEP, so there is a reminder if a
> py-typeguard port ever makes it into the tree.
> 
> With this OK martin@

Something like this? Updated port attached.

--- MakefileSat Nov 14 08:22:29 2020
+++ MakefileSat Nov 14 18:08:08 2020
@@ -8,7 +8,7 @@
 
 MAINTAINER =   Mikolaj Kucharski 
 
-CATEGORIES =   sysutils devel
+CATEGORIES =   devel
 
 HOMEPAGE = https://github.com/jd/tenacity
 
@@ -21,6 +21,9 @@
 MODPY_SETUPTOOLS = Yes
 MODPY_PYTEST = Yes
 
+BUILD_DEPENDS =devel/py-setuptools_scm${MODPY_FLAVOR}
+
+# depends on typeguard, currently not in ports
 TEST_DEPENDS = www/py-tornado${MODPY_FLAVOR}
 
 FLAVORS =  python3

-- 
Regards,
 Mikolaj


py-tenacity-6.2.0-port-v2.tgz
Description: application/tar-gz


NEW: py-tenacity 6.2.0

2020-11-14 Thread Mikolaj Kucharski
Hi,

: Python module to retry code until it succeeds
:
: Tenacity is a general-purpose retrying library, written in Python,
: to simplify the task of adding retry behavior to just about anything.

Regress test fails only on one test, because Python `typeguard` module
is not available, as a test dependency.

I've put it into CATEGORIES = sysutils devel, but not sure is this good
fit.

I think COMMENT could be tweaked for better English.

Other than that, it works here. I've made it Python3-only, I'm not sure
will it ever work on Python2.

Comments, okays?

-- 
Regards,
 Mikolaj


py-tenacity-6.2.0-port.tgz
Description: application/tar-gz


Re: upcoming textproc/groff-1.23.0

2020-11-13 Thread Mikolaj Kucharski
Hi Ingo,

On Fri, Nov 13, 2020 at 08:14:55PM +0100, Ingo Schwarze wrote:
> -DISTNAME =   groff-${VERSION}
> -REVISION =   4
> +DISTNAME =   groff-${VERSION}.rc1
> +PKGNAME =groff-${VERSION}

I think you could set:

PKGNAME = groff-${VERSION}rc1

That would allow upgrade the package naturally later, when
final release is commited to the ports tree.



Re: machines running GNOME dying

2020-11-05 Thread Mikolaj Kucharski
I've started experiencing this recently as well. X11 with cwm (no GNOME)
with Chromium running. Everything frezes, except caps lock LED works and
I can type `boot reboot` or `call cpu_reset` and system reboots.

Today's hand (I think it was) on:

OpenBSD 6.8-current (GENERIC.MP) #152: Thu Oct 29 15:48:34 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

2020-10-30T14:03:48.738Z mbx-0013 /bsd: WARNING: / was not properly unmounted
2020-10-30T14:22:50.934Z mbx-0013 /bsd: WARNING: / was not properly unmounted
2020-11-04T14:35:17.126Z mbx-0013 /bsd: WARNING: / was not properly unmounted
2020-11-05T13:50:58.049Z mbx-0013 /bsd: WARNING: / was not properly unmounted

Issues happend so far I think 4 times, around above timeframe, based on
reboots just after the hang.

When freeze happens I see only X11 output frozen, no output of panic
message or if I type (blindly, in ddb I think) bt, show panic, boot
reboot no output of those commands, so I cannot provide anything useful.

Any tips how I can capture bt, show panic or any other info?

Most annying part of this hang is, it affects Chromium in a way that I
loose last session information. Browser asks to restore session but my
tabs are gone and browser starts with no tabs or only few are restored.

My current dmesg is:

OpenBSD 6.8-current (GENERIC.MP) #161: Wed Nov  4 10:14:02 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8302006272 (7917MB)
avail mem = 8035102720 (7662MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f114000 (64 entries)
bios0: vendor HUAWEI version "2.00" date 11/07/2017
bios0: HUAWEI HUAWEI MateBook X
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI UEFI ECDT SSDT MSDM SSDT SSDT SSDT ASPT BOOT HPET 
APIC MCFG SSDT WSMT SSDT DBGP DBG2 SSDT SSDT DMAR NHLT FPDT BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) 
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2595.04 MHz, 06-8e-09
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,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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2592.98 MHz, 06-8e-09
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,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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2593.96 MHz, 06-8e-09
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,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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2593.96 MHz, 06-8e-09
cpu3: 

Re: Interest check: gh (github's cli)

2020-10-07 Thread Mikolaj Kucharski
On Wed, Oct 07, 2020 at 06:30:58PM +0100, Stuart Henderson wrote:
> On 2020/10/05 20:40, Mikolaj Kucharski wrote:
> > On Mon, Oct 05, 2020 at 05:00:48PM +0100, Stuart Henderson wrote:
> > > Still horrible but now with 100% more manpages (but the formatting is
> > > not very pleasant to the eye...)
> > 
> > I don't want to push discussion into bikeshedding, but I would go for
> > sysutils/github-cli as pkgpath and github-cli as package name.
> 
> Good call, other OS are either using "gh" or "github-cli" so it makes
> sense to follow one of them.
> 
> Updated version attached, as the version update in muesli/termenv has
> removed the need for the really nasty hack I will accept OKs for this
> one if someone wants me to import it ;)
> 

Reads fine, however category still points to devel and I've put the port
into sysutils. Not sure what exactly was your intent, to keep it in
devel or move it to sysutils. I would move it to sysutils.

make package failed for me with:

go: github.com/enescakir/emoji@v1.0.0: reading 
file:///home/mkucharski/openbsd/ports/distfiles/go_modules/github.com/enescakir/emoji/@v/v1.0.0.mod:
 no such file or directory

I don't know how to (re)generate the Makefile.

-- 
Regards,
 Mikolaj



Re: NEW: jpeginfo-1.6.1

2020-10-07 Thread Mikolaj Kucharski
On Sat, Oct 03, 2020 at 02:02:33PM +0100, Stuart Henderson wrote:
> On 2020/10/03 00:14, Mikolaj Kucharski wrote:
> > Kind reminder.
> > 
> > On Wed, Aug 19, 2020 at 09:08:06AM +0000, Mikolaj Kucharski wrote:
> > > Hi,
> > > 
> > > Simple new port attached. I wanted something to check JPEG files
> > > integrity (-c option to the tool).
> > > 
> > > $ jpeginfo -c DSC00470.JPG
> > > DSC00470.JPG 6000 x 4000 24bit Exif  N 10715136  [OK]
> > > 
> > > Comment:
> > > prints information and tests integrity of JPEG files
> > > 
> > > Description:
> > > Jpeginfo is an utility to generate informative listings from JPEG files,
> > > and to check JPEG files for errors. Program also supports automagic
> > > deletion of broken JPEGs.
> > > 
> > > WWW: https://www.kokkonen.net/tjko/projects.html
> > > 
> > > Comments?
> > > 
> > 
...
> 
> OK sthen@

Any other okays? I don't have r/w access, so import with another okay
would be appreciated.

-- 
Regards,
 Mikolaj



Re: Interest check: gh (github's cli)

2020-10-05 Thread Mikolaj Kucharski
On Mon, Oct 05, 2020 at 05:00:48PM +0100, Stuart Henderson wrote:
> Still horrible but now with 100% more manpages (but the formatting is
> not very pleasant to the eye...)

I don't want to push discussion into bikeshedding, but I would go for
sysutils/github-cli as pkgpath and github-cli as package name.

-- 
Regards,
 Mikolaj



Re: Interest check: gh (github's cli)

2020-10-05 Thread Mikolaj Kucharski
On Mon, Oct 05, 2020 at 02:50:35PM +0100, Ricardo wrote:
> Hey ports@
> 
> Github released a cli application (gh) written in go and I would like to
> know if there any interest on having it under OpenBSD.

Yes, very much yes please. I had a stab at github-cli, but hit some
issues in portgen(1) and didn't had time to dig into protgen(1) itself.

-- 
Regards,
 Mikolaj



Re: mysql_waitpid: broken symbolic link to '/usr/local/bin/mariadb-waitpid'

2020-10-02 Thread Mikolaj Kucharski
On Fri, Oct 02, 2020 at 10:54:05PM +, Mikolaj Kucharski wrote:
> On Thu, Oct 01, 2020 at 09:09:16PM -0400, Brad Smith wrote:
> > 
> > It should go the other way around. Try something like this.
> > 
> 
> I see thanks. Your diff also has the issue which I hit with my diff:
> 
>Can't install mariadb-server-10.5.5p0v1 because of conflicts 
> (mariadb-client-10.5.5p0v1)
> 
> I think it needs to be like sthen@ mentioned:
> 
> @conflict mariadb-server-<10.5.5p0v1
> 
> It's interesting that three people didn't notice that problem, when
> preparing the diff or when reviwing it.
> 
> I'm really curious about rationale of this unexpected behaviour of
> conflict marker. I find it confusing.
> 
> I'm testing Brad's diff with conflict marker fix. Will reply when I'm
> done with final diff.
> 

Below diff works as intended. This is Brad's diff with conflict fix.

Index: Makefile
===
RCS file: /cvs/ports/databases/mariadb/Makefile,v
retrieving revision 1.96
diff -u -p -u -r1.96 Makefile
--- Makefile12 Aug 2020 14:43:54 -  1.96
+++ Makefile3 Oct 2020 00:48:12 -
@@ -9,8 +9,9 @@ DISTNAME=   mariadb-${VERSION}
 PKGNAME-main=  mariadb-client-${VERSION}
 PKGNAME-server=mariadb-server-${VERSION}
 PKGNAME-tests= mariadb-tests-${VERSION}
+REVISION-main= 0
+REVISION-server= 0
 EPOCH= 1
-
 CATEGORIES=databases
 MASTER_SITES=  https://downloads.mariadb.com/MariaDB/${DISTNAME}/source/ \
https://ftp.osuosl.org/pub/mariadb/${DISTNAME}/source/
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/databases/mariadb/pkg/PLIST-main,v
retrieving revision 1.21
diff -u -p -u -r1.21 PLIST-main
--- pkg/PLIST-main  26 Jun 2020 08:46:42 -  1.21
+++ pkg/PLIST-main  3 Oct 2020 00:48:12 -
@@ -1,5 +1,5 @@
 @comment $OpenBSD: PLIST-main,v 1.21 2020/06/26 08:46:42 sthen Exp $
-@conflict mariadb-server-<=10.4.12v1
+@conflict mariadb-server-<10.5.5p0v1
 @conflict mytop-*
 @pkgpath databases/mytop
 @bin bin/mariadb
@@ -18,6 +18,7 @@ bin/mariadb-hotcopy
 bin/mariadb-setpermission
 @bin bin/mariadb-show
 @bin bin/mariadb-slap
+@bin bin/mariadb-waitpid
 @bin bin/mariadb_config
 bin/msql2mysql
 bin/mysql
@@ -88,6 +89,7 @@ lib/pkgconfig/mariadb.pc
 @man man/man1/mariadb-setpermission.1
 @man man/man1/mariadb-show.1
 @man man/man1/mariadb-slap.1
+@man man/man1/mariadb-waitpid.1
 @man man/man1/mariadb.1
 @man man/man1/mariadb_config.1
 @man man/man1/mbstream.1
Index: pkg/PLIST-server
===
RCS file: /cvs/ports/databases/mariadb/pkg/PLIST-server,v
retrieving revision 1.35
diff -u -p -u -r1.35 PLIST-server
--- pkg/PLIST-server12 Aug 2020 14:43:54 -  1.35
+++ pkg/PLIST-server3 Oct 2020 00:48:12 -
@@ -18,7 +18,6 @@ bin/mariadb-install-db
 bin/mariadb-secure-installation
 @bin bin/mariadb-tzinfo-to-sql
 @bin bin/mariadb-upgrade
-@bin bin/mariadb-waitpid
 bin/mariadbd-multi
 bin/mariadbd-safe
 @bin bin/mariadbd-safe-helper
@@ -522,7 +521,6 @@ libexec/mysqld
 @man man/man1/mariadb-secure-installation.1
 @man man/man1/mariadb-tzinfo-to-sql.1
 @man man/man1/mariadb-upgrade.1
-@man man/man1/mariadb-waitpid.1
 @man man/man1/mariadbd-multi.1
 @man man/man1/mariadbd-safe-helper.1
 @man man/man1/mariadbd-safe.1

-- 
Regards,
 Mikolaj



Re: NEW: jpeginfo-1.6.1

2020-10-02 Thread Mikolaj Kucharski
Kind reminder.

On Wed, Aug 19, 2020 at 09:08:06AM +, Mikolaj Kucharski wrote:
> Hi,
> 
> Simple new port attached. I wanted something to check JPEG files
> integrity (-c option to the tool).
> 
> $ jpeginfo -c DSC00470.JPG
> DSC00470.JPG 6000 x 4000 24bit Exif  N 10715136  [OK]
> 
> Comment:
> prints information and tests integrity of JPEG files
> 
> Description:
> Jpeginfo is an utility to generate informative listings from JPEG files,
> and to check JPEG files for errors. Program also supports automagic
> deletion of broken JPEGs.
> 
> WWW: https://www.kokkonen.net/tjko/projects.html
> 
> Comments?
> 

-- 
Regards,
 Mikolaj


jpeginfo-1.6.1-port-v1.tgz
Description: application/tar-gz


Re: mysql_waitpid: broken symbolic link to '/usr/local/bin/mariadb-waitpid'

2020-10-02 Thread Mikolaj Kucharski
On Thu, Oct 01, 2020 at 09:09:16PM -0400, Brad Smith wrote:
> 
> It should go the other way around. Try something like this.
> 

I see thanks. Your diff also has the issue which I hit with my diff:

   Can't install mariadb-server-10.5.5p0v1 because of conflicts 
(mariadb-client-10.5.5p0v1)

I think it needs to be like sthen@ mentioned:

@conflict mariadb-server-<10.5.5p0v1

It's interesting that three people didn't notice that problem, when
preparing the diff or when reviwing it.

I'm really curious about rationale of this unexpected behaviour of
conflict marker. I find it confusing.

I'm testing Brad's diff with conflict marker fix. Will reply when I'm
done with final diff.


> Index: Makefile
> ===
> RCS file: /home/cvs/ports/databases/mariadb/Makefile,v
> retrieving revision 1.96
> diff -u -p -u -p -r1.96 Makefile
> --- Makefile  12 Aug 2020 14:43:54 -  1.96
> +++ Makefile  30 Sep 2020 20:21:27 -
> @@ -9,8 +9,9 @@ DISTNAME= mariadb-${VERSION}
>  PKGNAME-main=mariadb-client-${VERSION}
>  PKGNAME-server=  mariadb-server-${VERSION}
>  PKGNAME-tests=   mariadb-tests-${VERSION}
> +REVISION-main=   0
> +REVISION-server= 0
>  EPOCH=   1
> -
>  CATEGORIES=  databases
>  MASTER_SITES=
> https://downloads.mariadb.com/MariaDB/${DISTNAME}/source/ \
>   https://ftp.osuosl.org/pub/mariadb/${DISTNAME}/source/
> Index: pkg/PLIST-main
> ===
> RCS file: /home/cvs/ports/databases/mariadb/pkg/PLIST-main,v
> retrieving revision 1.21
> diff -u -p -u -p -r1.21 PLIST-main
> --- pkg/PLIST-main26 Jun 2020 08:46:42 -  1.21
> +++ pkg/PLIST-main30 Sep 2020 21:02:22 -
> @@ -1,5 +1,6 @@
>  @comment $OpenBSD: PLIST-main,v 1.21 2020/06/26 08:46:42 sthen Exp $
>  @conflict mariadb-server-<=10.4.12v1
> +@conflict mariadb-server-<=10.5.5v1
>  @conflict mytop-*
>  @pkgpath databases/mytop
>  @bin bin/mariadb
> @@ -18,6 +19,7 @@ bin/mariadb-hotcopy
>  bin/mariadb-setpermission
>  @bin bin/mariadb-show
>  @bin bin/mariadb-slap
> +@bin bin/mariadb-waitpid
>  @bin bin/mariadb_config
>  bin/msql2mysql
>  bin/mysql
> @@ -88,6 +90,7 @@ lib/pkgconfig/mariadb.pc
>  @man man/man1/mariadb-setpermission.1
>  @man man/man1/mariadb-show.1
>  @man man/man1/mariadb-slap.1
> +@man man/man1/mariadb-waitpid.1
>  @man man/man1/mariadb.1
>  @man man/man1/mariadb_config.1
>  @man man/man1/mbstream.1
> Index: pkg/PLIST-server
> ===
> RCS file: /home/cvs/ports/databases/mariadb/pkg/PLIST-server,v
> retrieving revision 1.35
> diff -u -p -u -p -r1.35 PLIST-server
> --- pkg/PLIST-server  12 Aug 2020 14:43:54 -  1.35
> +++ pkg/PLIST-server  30 Sep 2020 20:19:23 -
> @@ -18,7 +18,6 @@ bin/mariadb-install-db
>  bin/mariadb-secure-installation
>  @bin bin/mariadb-tzinfo-to-sql
>  @bin bin/mariadb-upgrade
> -@bin bin/mariadb-waitpid
>  bin/mariadbd-multi
>  bin/mariadbd-safe
>  @bin bin/mariadbd-safe-helper
> @@ -522,7 +521,6 @@ libexec/mysqld
>  @man man/man1/mariadb-secure-installation.1
>  @man man/man1/mariadb-tzinfo-to-sql.1
>  @man man/man1/mariadb-upgrade.1
> -@man man/man1/mariadb-waitpid.1
>  @man man/man1/mariadbd-multi.1
>  @man man/man1/mariadbd-safe-helper.1
>  @man man/man1/mariadbd-safe.1

-- 
Regards,
 Mikolaj



Re: mysql_waitpid: broken symbolic link to '/usr/local/bin/mariadb-waitpid'

2020-09-30 Thread Mikolaj Kucharski
On Mon, Sep 28, 2020 at 02:01:00PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> I've noticed that I have mysql_waitpid installed which is broken
> symlink to mariadb-waitpid.
> 
> I think that symlink should be moved to -server package. I come up with
> following diff, which I'm still building and didn't test it yet.

New version after feedback from sthen@

Something is not right with conflict lines. Is this PEBCAK or
pkg_add bug?

This is on a machine without prior mariadb-client, mariadb-server or
mariadb-tests package installed. Those packages are NOT installed.

OpenBSD 6.8 (GENERIC.MP) #94: Tue Sep 29 00:13:21 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

# env PKG_PATH=https://cdn.openbsd.org/%m \
TRUSTED_PKG_PATH=/root/mariadb \
pkg_add -Dsnap -i mariadb-client mariadb-server mariadb-tests
quirks-3.439 signed on 2020-09-30T05:15:47Z
mariadb-client-10.5.5p0v1: ok
mariadb-server-10.5.5p0v1:p5-Clone-0.41p0: ok
mariadb-server-10.5.5p0v1:p5-Math-Base-Convert-0.11p0: ok
mariadb-server-10.5.5p0v1:p5-Params-Util-1.07p2: ok
mariadb-server-10.5.5p0v1:p5-Module-Runtime-0.016p0: ok
mariadb-server-10.5.5p0v1:p5-SQL-Statement-1.412p0: ok
mariadb-server-10.5.5p0v1:p5-Net-Daemon-0.48p1: ok
mariadb-server-10.5.5p0v1:p5-PlRPC-0.2020p0: ok
mariadb-server-10.5.5p0v1:p5-FreezeThaw-0.5001p0: ok
mariadb-server-10.5.5p0v1:p5-MLDBM-2.05p0: ok
mariadb-server-10.5.5p0v1:p5-DBI-1.641: ok
mariadb-server-10.5.5p0v1:p5-DBD-MariaDB-1.21p2: ok
mariadb-server-10.5.5p0v1:snappy-1.1.8: ok
Can't install mariadb-server-10.5.5p0v1 because of conflicts 
(mariadb-client-10.5.5p0v1)
mariadb-tests-10.5.5v1: ok
--- mariadb-server-10.5.5p0v1 ---
Can't install mariadb-server-10.5.5p0v1: conflicts
Couldn't install mariadb-server-10.5.5p0v1

# env PKG_PATH=https://cdn.openbsd.org/%m \
TRUSTED_PKG_PATH=/root/mariadb \
pkg_info -Dsnap -f mariadb-client mariadb-server mariadb-tests | \
grep -E '^(Information|@conflict)'
Information for inst:mariadb-client-10.5.5p0v1
@conflict mariadb-server-<=10.4.12v1
@conflict mytop-*
Information for file:/root/mariadb/mariadb-server-10.5.5p0v1.tgz
@conflict mariadb-client-<=10.5.5v1
Information for inst:mariadb-tests-10.5.5v1
# _

# ls -lhA /root/mariadb/
total 168160
-rw-r--r--  1 root  wheel  10.3M Sep 29 10:35 mariadb-client-10.5.5p0v1.tgz
-rw-r--r--  1 root  wheel  42.5M Sep 29 10:36 mariadb-server-10.5.5p0v1.tgz
-rw-r--r--  1 root  wheel  29.2M Sep 29 10:36 mariadb-tests-10.5.5v1.tgz


Index: Makefile
===
RCS file: /cvs/ports/databases/mariadb/Makefile,v
retrieving revision 1.96
diff -u -p -u -r1.96 Makefile
--- Makefile12 Aug 2020 14:43:54 -  1.96
+++ Makefile30 Sep 2020 20:02:46 -
@@ -9,6 +9,8 @@ DISTNAME=   mariadb-${VERSION}
 PKGNAME-main=  mariadb-client-${VERSION}
 PKGNAME-server=mariadb-server-${VERSION}
 PKGNAME-tests= mariadb-tests-${VERSION}
+REVISION-main =0
+REVISION-server =  0
 EPOCH= 1
 
 CATEGORIES=databases
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/databases/mariadb/pkg/PLIST-main,v
retrieving revision 1.21
diff -u -p -u -r1.21 PLIST-main
--- pkg/PLIST-main  26 Jun 2020 08:46:42 -  1.21
+++ pkg/PLIST-main  30 Sep 2020 20:02:46 -
@@ -23,7 +23,6 @@ bin/msql2mysql
 bin/mysql
 bin/mysql_config
 bin/mysql_find_rows
-bin/mysql_waitpid
 bin/mysqlaccess
 bin/mysqladmin
 bin/mysqlbinlog
Index: pkg/PLIST-server
===
RCS file: /cvs/ports/databases/mariadb/pkg/PLIST-server,v
retrieving revision 1.35
diff -u -p -u -r1.35 PLIST-server
--- pkg/PLIST-server12 Aug 2020 14:43:54 -  1.35
+++ pkg/PLIST-server30 Sep 2020 20:02:47 -
@@ -1,5 +1,5 @@
 @comment $OpenBSD: PLIST-server,v 1.35 2020/08/12 14:43:54 sthen Exp $
-@conflict mariadb-client-<=10.4.12v1
+@conflict mariadb-client-<=10.5.5v1
 @newgroup _mysql:502
 @newuser _mysql:502:_mysql:daemon:MySQL Account:/nonexistent:/sbin/nologin
 @rcscript ${RCDIR}/mysqld
@@ -36,6 +36,7 @@ bin/mysql_secure_installation
 bin/mysql_setpermission
 bin/mysql_tzinfo_to_sql
 bin/mysql_upgrade
+bin/mysql_waitpid
 bin/mysqld_multi
 bin/mysqld_safe
 bin/mysqld_safe_helper

-- 
Regards,
 Mikolaj



UPDATE: youtube-dl 2020.09.20

2020-09-30 Thread Mikolaj Kucharski
Hi,

I actually didn't have any issues with youtube-dl. I think this can wait
after unlock.

ChangeLog at:

https://github.com/ytdl-org/youtube-dl/compare/2020.07.28...2020.09.20#diff-02f0b547c2779d25cff89672135f20e3


Index: Makefile
===
RCS file: /cvs/ports/www/youtube-dl/Makefile,v
retrieving revision 1.211
diff -u -p -u -r1.211 Makefile
--- Makefile28 Jul 2020 15:14:33 -  1.211
+++ Makefile30 Sep 2020 19:59:12 -
@@ -2,7 +2,7 @@
 
 COMMENT =  CLI program to download videos from YouTube and other sites
 
-VERSION =  2020.07.28
+VERSION =  2020.09.20
 MODPY_EGG_VERSION =${VERSION:S/.0/./g}
 
 DISTNAME = youtube-dl-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/youtube-dl/distinfo,v
retrieving revision 1.192
diff -u -p -u -r1.192 distinfo
--- distinfo28 Jul 2020 15:14:33 -  1.192
+++ distinfo30 Sep 2020 19:59:12 -
@@ -1,2 +1,2 @@
-SHA256 (youtube-dl-2020.07.28.tar.gz) = 
H7PjTYBABGTlWu62ElbDZGgRatnv6CVDtDend6Lvx8U=
-SIZE (youtube-dl-2020.07.28.tar.gz) = 3179686
+SHA256 (youtube-dl-2020.09.20.tar.gz) = 
rBp5nPloNFvykIntLlxdT0oyAxYl2Ag2nmG2Ni0cfN4=
+SIZE (youtube-dl-2020.09.20.tar.gz) = 3188480

-- 
Regards,
 Mikolaj



Re: mysql_waitpid: broken symbolic link to '/usr/local/bin/mariadb-waitpid'

2020-09-28 Thread Mikolaj Kucharski
On Mon, Sep 28, 2020 at 08:09:28PM +0100, Stuart Henderson wrote:
> On 2020/09/28 19:01, Mikolaj Kucharski wrote:
> > On Mon, Sep 28, 2020 at 07:54:01PM +0100, Stuart Henderson wrote:
> > > > --- pkg/PLIST-main  26 Jun 2020 08:46:42 -  1.21
> > > > +++ pkg/PLIST-main  28 Sep 2020 13:57:54 -
> > > > @@ -1,5 +1,5 @@
> > > >  @comment $OpenBSD: PLIST-main,v 1.21 2020/06/26 08:46:42 sthen Exp $
> > > > -@conflict mariadb-server-<=10.4.12v1
> > > > +@conflict mariadb-server-<=10.5.5v1
> > > 
> > > This line does not need to change
> > > 
> > 
> > Are you sure? I didn't had a chance to test various install or upgrade
> > scenarios, but conflict is there because file exists in old -main and
> > new -server package, so I'm tryig to avoid situation when old -main and
> > new -server will somehow end up installed and fail.
> > 
> > Dunno, maybe I'm missing something in my mental picture.
> 
> You already avoided that situation with the @conflict marker in the new
> -server version.
> 

Ah, thank you!

-- 
Regards,
 Mikolaj



Re: mysql_waitpid: broken symbolic link to '/usr/local/bin/mariadb-waitpid'

2020-09-28 Thread Mikolaj Kucharski
On Mon, Sep 28, 2020 at 07:54:01PM +0100, Stuart Henderson wrote:
> > --- pkg/PLIST-main  26 Jun 2020 08:46:42 -  1.21
> > +++ pkg/PLIST-main  28 Sep 2020 13:57:54 -
> > @@ -1,5 +1,5 @@
> >  @comment $OpenBSD: PLIST-main,v 1.21 2020/06/26 08:46:42 sthen Exp $
> > -@conflict mariadb-server-<=10.4.12v1
> > +@conflict mariadb-server-<=10.5.5v1
> 
> This line does not need to change
> 

Are you sure? I didn't had a chance to test various install or upgrade
scenarios, but conflict is there because file exists in old -main and
new -server package, so I'm tryig to avoid situation when old -main and
new -server will somehow end up installed and fail.

Dunno, maybe I'm missing something in my mental picture.

-- 
Regards,
 Mikolaj



mysql_waitpid: broken symbolic link to '/usr/local/bin/mariadb-waitpid'

2020-09-28 Thread Mikolaj Kucharski
Hi,

I've noticed that I have mysql_waitpid installed which is broken
symlink to mariadb-waitpid.

I think that symlink should be moved to -server package. I come up with
following diff, which I'm still building and didn't test it yet.


Index: Makefile
===
RCS file: /cvs/ports/databases/mariadb/Makefile,v
retrieving revision 1.96
diff -u -p -u -r1.96 Makefile
--- Makefile12 Aug 2020 14:43:54 -  1.96
+++ Makefile28 Sep 2020 13:57:54 -
@@ -9,6 +9,8 @@ DISTNAME=   mariadb-${VERSION}
 PKGNAME-main=  mariadb-client-${VERSION}
 PKGNAME-server=mariadb-server-${VERSION}
 PKGNAME-tests= mariadb-tests-${VERSION}
+REVISION-main =0
+REVISION-server =  0
 EPOCH= 1
 
 CATEGORIES=databases
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/databases/mariadb/pkg/PLIST-main,v
retrieving revision 1.21
diff -u -p -u -r1.21 PLIST-main
--- pkg/PLIST-main  26 Jun 2020 08:46:42 -  1.21
+++ pkg/PLIST-main  28 Sep 2020 13:57:54 -
@@ -1,5 +1,5 @@
 @comment $OpenBSD: PLIST-main,v 1.21 2020/06/26 08:46:42 sthen Exp $
-@conflict mariadb-server-<=10.4.12v1
+@conflict mariadb-server-<=10.5.5v1
 @conflict mytop-*
 @pkgpath databases/mytop
 @bin bin/mariadb
@@ -23,7 +23,6 @@ bin/msql2mysql
 bin/mysql
 bin/mysql_config
 bin/mysql_find_rows
-bin/mysql_waitpid
 bin/mysqlaccess
 bin/mysqladmin
 bin/mysqlbinlog
Index: pkg/PLIST-server
===
RCS file: /cvs/ports/databases/mariadb/pkg/PLIST-server,v
retrieving revision 1.35
diff -u -p -u -r1.35 PLIST-server
--- pkg/PLIST-server12 Aug 2020 14:43:54 -  1.35
+++ pkg/PLIST-server28 Sep 2020 13:57:54 -
@@ -1,5 +1,5 @@
 @comment $OpenBSD: PLIST-server,v 1.35 2020/08/12 14:43:54 sthen Exp $
-@conflict mariadb-client-<=10.4.12v1
+@conflict mariadb-client-<=10.5.5v1
 @newgroup _mysql:502
 @newuser _mysql:502:_mysql:daemon:MySQL Account:/nonexistent:/sbin/nologin
 @rcscript ${RCDIR}/mysqld
@@ -36,6 +36,7 @@ bin/mysql_secure_installation
 bin/mysql_setpermission
 bin/mysql_tzinfo_to_sql
 bin/mysql_upgrade
+bin/mysql_waitpid
 bin/mysqld_multi
 bin/mysqld_safe
 bin/mysqld_safe_helper

-- 
Regards,
 Mikolaj



Re: NEW: jpeginfo-1.6.1

2020-09-24 Thread Mikolaj Kucharski
Kind reminder.

On Sat, Sep 19, 2020 at 08:12:01AM +, Mikolaj Kucharski wrote:
> Thanks Ricardo.
> 
> Any other comments or okays?
> 
> File reattached for convenience.
> 
> On Thu, Sep 10, 2020 at 07:39:01PM +0100, Ricardo wrote:
> > Hi Mikolaj,
> > 
> > I tested it briefly and seems to be working on amd64.
> > 
> > Take care.
> > Ricardo
> > 
> > On 9/10/20 8:31 AM, Mikolaj Kucharski wrote:
> > > Ping.
> > > 
> > > On Wed, Aug 19, 2020 at 09:08:06AM +, Mikolaj Kucharski wrote:
> > > > Hi,
> > > > 
> > > > Simple new port attached. I wanted something to check JPEG files
> > > > integrity (-c option to the tool).
> > > > 
> > > > $ jpeginfo -c DSC00470.JPG
> > > > DSC00470.JPG 6000 x 4000 24bit Exif  N 10715136  [OK]
> > > > 
> > > > Comment:
> > > > prints information and tests integrity of JPEG files
> > > > 
> > > > Description:
> > > > Jpeginfo is an utility to generate informative listings from JPEG files,
> > > > and to check JPEG files for errors. Program also supports automagic
> > > > deletion of broken JPEGs.
> > > > 
> > > > WWW: https://www.kokkonen.net/tjko/projects.html
> > > > 
> > > > Comments?
> > > > 
> > > Same file reattached for convenience.
> > > 

-- 
Regards,
 Mikolaj


jpeginfo-1.6.1-port-v1.tgz
Description: application/tar-gz


Re: NEW: jpeginfo-1.6.1

2020-09-19 Thread Mikolaj Kucharski
Thanks Ricardo.

Any other comments or okays?

File reattached for convenience.

On Thu, Sep 10, 2020 at 07:39:01PM +0100, Ricardo wrote:
> Hi Mikolaj,
> 
> I tested it briefly and seems to be working on amd64.
> 
> Take care.
> Ricardo
> 
> On 9/10/20 8:31 AM, Mikolaj Kucharski wrote:
> > Ping.
> > 
> > On Wed, Aug 19, 2020 at 09:08:06AM +, Mikolaj Kucharski wrote:
> > > Hi,
> > > 
> > > Simple new port attached. I wanted something to check JPEG files
> > > integrity (-c option to the tool).
> > > 
> > > $ jpeginfo -c DSC00470.JPG
> > > DSC00470.JPG 6000 x 4000 24bit Exif  N 10715136  [OK]
> > > 
> > > Comment:
> > > prints information and tests integrity of JPEG files
> > > 
> > > Description:
> > > Jpeginfo is an utility to generate informative listings from JPEG files,
> > > and to check JPEG files for errors. Program also supports automagic
> > > deletion of broken JPEGs.
> > > 
> > > WWW: https://www.kokkonen.net/tjko/projects.html
> > > 
> > > Comments?
> > > 
> > Same file reattached for convenience.
> > 

-- 
Regards,
 Mikolaj


jpeginfo-1.6.1-port-v1.tgz
Description: application/tar-gz


Re: PATCH: hw-probe add lspci and lsusb to run-deps

2020-09-10 Thread Mikolaj Kucharski
Hi,

Kind reminder.

On Fri, Aug 21, 2020 at 07:54:59PM +, Mikolaj Kucharski wrote:
> Hi David,
> 
> I see that hw-proble is using lspci and lsusb, so to have more complete
> information in hardware database, I think it would be useful to add
> those tools as run dep.
> 
> While at it, I sorted RUN_DEPENDS.
> 

Below inlined the same patch for convenience.

Index: Makefile
===
RCS file: /cvs/ports/sysutils/hw-probe/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 Makefile
--- Makefile11 Aug 2020 14:54:11 -  1.1.1.1
+++ Makefile21 Aug 2020 19:51:03 -
@@ -4,6 +4,7 @@ COMMENT =   hardware probe tool
 CATEGORIES =   sysutils
 
 PKGNAME =  hw-probe-1.6beta
+REVISION = 0
 
 GH_ACCOUNT =   linuxhw
 GH_PROJECT =   hw-probe
@@ -14,11 +15,13 @@ MAINTAINER =David Dahlberg 

Re: NEW: jpeginfo-1.6.1

2020-09-10 Thread Mikolaj Kucharski
Ping.

On Wed, Aug 19, 2020 at 09:08:06AM +, Mikolaj Kucharski wrote:
> Hi,
> 
> Simple new port attached. I wanted something to check JPEG files
> integrity (-c option to the tool).
> 
> $ jpeginfo -c DSC00470.JPG
> DSC00470.JPG 6000 x 4000 24bit Exif  N 10715136  [OK]
> 
> Comment:
> prints information and tests integrity of JPEG files
> 
> Description:
> Jpeginfo is an utility to generate informative listings from JPEG files,
> and to check JPEG files for errors. Program also supports automagic
> deletion of broken JPEGs.
> 
> WWW: https://www.kokkonen.net/tjko/projects.html
> 
> Comments?
> 

Same file reattached for convenience.

-- 
Regards,
 Mikolaj


jpeginfo-1.6.1-port-v1.tgz
Description: application/tar-gz


Re: something broke net/syncthing

2020-08-21 Thread Mikolaj Kucharski
Hi,

On Sat, Aug 22, 2020 at 12:03:38AM +0100, Edd Barrett wrote:
>  
> -V =  1.5.0
> -DISTNAME =   syncthing-${V}
> -DISTFILES =  syncthing-source-v${V}${EXTRACT_SUFX}
> +# Release candidate used so as to fix critical quic-go problem.
> +V =  1.9.0
> +DISTNAME =   syncthing-${V}-rc4
> +DISTFILES =  syncthing-source-v${V}-rc.4${EXTRACT_SUFX}
>  

$ make show=PKGNAMES
syncthing-1.9.0-rc4

I don't use syncthing, but that package name looks incorrect. String rc4
is conflicting with flavor naming pattern. You need to drop the dash, so
final package name is syncthing-1.9.0rc4

-- 
Regards,
 Mikolaj



PATCH: hw-probe add lspci and lsusb to run-deps

2020-08-21 Thread Mikolaj Kucharski
Hi David,

I see that hw-proble is using lspci and lsusb, so to have more complete
information in hardware database, I think it would be useful to add
those tools as run dep.

While at it, I sorted RUN_DEPENDS.


Index: Makefile
===
RCS file: /cvs/ports/sysutils/hw-probe/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 Makefile
--- Makefile11 Aug 2020 14:54:11 -  1.1.1.1
+++ Makefile21 Aug 2020 19:51:03 -
@@ -4,6 +4,7 @@ COMMENT =   hardware probe tool
 CATEGORIES =   sysutils
 
 PKGNAME =  hw-probe-1.6beta
+REVISION = 0
 
 GH_ACCOUNT =   linuxhw
 GH_PROJECT =   hw-probe
@@ -14,11 +15,13 @@ MAINTAINER =David Dahlberg 

Re: portgen go - how to?

2020-08-21 Thread Mikolaj Kucharski
On Fri, Aug 21, 2020 at 04:22:46AM -0600, Aaron Bieber wrote:
> 
> On Fri, Aug 21, 2020, at 3:41 AM, Mikolaj Kucharski wrote:
> > 
> > $ env PORTSDIR=/home/mkucharski/openbsd \
> > /home/mkucharski/openbsd/ports/infrastructure/bin/portgen go 
> > github.com/cli/cli
> 
> I am not 100% sure setting PORTSDIR via env will work. Can you set it via 
> mk.conf to see if it gets further?
> 

I should mention that I already had PORTSDIR in mk.conf, before I
executed portgen. Here is my entire mk.conf file:

# /etc/mk.conf
PORTSDIR = /home/mkucharski/openbsd/ports
PORTSDIR_PATH = ${PORTSDIR}:/home/mkucharski/openbsd/mystuff
SUDO = doas

I've looked at mail archives and I think I'm executing portgen with
correct arguments, so I guess I need to dive into the code.

portgen go github.com/cli/cli

Above is correct execution, putting aside my issue, right?

-- 
Regards,
 Mikolaj



portgen go - how to?

2020-08-21 Thread Mikolaj Kucharski
Hi,

I've looked at github.com/cli/cli and wanted to give it a go, but I'm
not familar how to create a port in golang ecosystem.

I've looked at portgen and not sure how to do it with it either :/

I've ran portgen and it failed as follows:

$ env PORTSDIR=/home/mkucharski/openbsd \
/home/mkucharski/openbsd/ports/infrastructure/bin/portgen go 
github.com/cli/cli
make: don't know how to make makesum
Stop in /home/mkucharski/openbsd/mystuff/go/cli
make: don't know how to make checksum
Stop in /home/mkucharski/openbsd/mystuff/go/cli
make: don't know how to make clean
Stop in /home/mkucharski/openbsd/mystuff/go/cli
make: don't know how to make extract
Stop in /home/mkucharski/openbsd/mystuff/go/cli
make: no target to make.
Can't stat : No such file or directory
 at 
/home/mkucharski/openbsd/ports/infrastructure/bin/../lib/OpenBSD/PortGen/Port.pm
 line 251.
make: no target to make.
make: don't know how to make fake
Stop in /home/mkucharski/openbsd/mystuff/go/cli
make: don't know how to make update-plist
Stop in /home/mkucharski/openbsd/mystuff/go/cli
/home/mkucharski/openbsd/mystuff/go/cli

However, I'm not exactly sure am I executing it correctly. Any clues?

-- 
Regards,
 Mikolaj



  1   2   3   4   5   6   7   8   >