On 2024-12-31 17:58, Jeremy Mates wrote:
> On 2024-12-31 17:37:01 -0800, Steve Williams wrote:
>> wgaip 192.168.124.0/24
>> inet 192.168.126.1/24
>
> 126.1 is not really on the 124.0/24 subnet?
Hi,
If you were in close proximity to me, I'd buy you a beer for that one!
It's so funny how the eyeballs don't see what is right in front of them
:(
A simple change of a "4" to a "6" and magically, it all works :)
Thanks very much!!
Happy New years (wherever you are)
Cheers,
Steve W.
Tuesday, December 31, 2024
Re: Troubleshooting OpenBSD Wireguard server & Windows Wireguard client
On 2024-12-31 17:37:01 -0800, Steve Williams wrote:
> wgaip 192.168.124.0/24
> inet 192.168.126.1/24
126.1 is not really on the 124.0/24 subnet?
> wgaip 192.168.124.0/24
> inet 192.168.126.1/24
126.1 is not really on the 124.0/24 subnet?
Troubleshooting OpenBSD Wireguard server & Windows Wireguard client
Hi,
I am trying to configure my OpenBSD server as a Wireguard server for my
my Windows laptop (and eventually my Android phone)
I am using OpenBSD 7.6 (GENERIC.MP) #338: Mon Sep 30 08:55:35 MDT 2024
My Windows PC is using Windows Wireguard client 0.5.3 (downloaded Dec
31, 2024)
The Windows Wireguard client is able to connect to the OpenBSD server
but no traffic seems to make it across the tunnel. The packet counts go
up, but I cannot ping, ssh, etc
The packet counts also go up on the OpenBSD server (ifconfig wg0)
mini# ifconfig wg0
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
index 5 priority 0 llprio 3
wgport 4433
wgpubkey <wgpubkey>
wgpeer <wgpeer>
wgendpoint 192.168.123.2 55331
tx: 9920, rx: 423232
last handshake: 88 seconds ago
wgaip 192.168.124.0/24
groups: wg
inet 192.168.126.1 netmask 0xffffff00 broadcast 192.168.126.255
I have been running Wireshark on Windows and using tcpdump -i wg0 as
well as tcpdump -i pflog0, as well as looking at the blocked (logged)
packets by tcpdump -r /var/log/pflog. I don't seen any blocked packets.
My pf.conf has:
-----------------------
<close to the top>
set skip on wg0
<further down>
# WireGuard
pass in on egress inet proto udp from any to (egress) port 4433
-----------------------
hostname.wg0
-----------------------
wgkey <wgkey>
wgport 4433
wgpeer <wgpeer key>
wgaip 192.168.124.0/24
inet 192.168.126.1/24
up
On the Windows Wireguard client:
[Interface]
PrivateKey = <privateKey>
Address = 192.168.126.2/24
[Peer]
PublicKey = <public key of OpenBSD server>
AllowedIPs = 192.168.126.0/24
Endpoint = <public IP of OpenBSD Server>:4433
The Windows Wireguard client the following so the tunnel seems to be up:
2024-12-31 17:14:58.244: [TUN] [OpenBSD] Sending keepalive packet to
peer 1 (207.6.196.56:4433)
2024-12-31 17:14:58.247: [TUN] [OpenBSD] Receiving keepalive packet from
peer 1 (207.6.196.56:4433)
Wireshark when I'm pinging from the Windows system to the server
1 0.000000 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=37/9472, ttl=128 (no response found!)
2 4.689174 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=38/9728, ttl=128 (no response found!)
3 9.693818 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=39/9984, ttl=128 (no response found!)
4 14.705842 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=40/10240, ttl=128 (no response found!)
There is no traffic received on wg0 (tcpdump -i wg0) when I ping from
the Windows system
tcpdump when I ping from the OpenBSD box to the Windows Client
mini# tcpdump -i wg0
tcpdump: listening on wg0, link-type LOOP
17:23:59.960035 192.168.126.1 > 192.168.126.2: icmp: echo request
17:24:00.962192 192.168.126.1 > 192.168.126.2: icmp: echo request
17:24:01.962181 192.168.126.1 > 192.168.126.2: icmp: echo request
17:24:02.962161 192.168.126.1 > 192.168.126.2: icmp: echo request
mini# ping 192.168.126.2
PING 192.168.126.2 (192.168.126.2): 56 data bytes
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
Network Unreachable... a routing issue?
mini# netstat -rn | grep wg0
192.168.126/24 192.168.126.1 UCn 1 0 - 4 wg0
192.168.126.1 wg0 UHl 0 0 - 1 wg0
192.168.126.2 link#0 UHc 0 4 - 3 wg0
192.168.126.255 192.168.126.1 UHb 0 0 - 1 wg0
** There is nothing seen in Wireshark on the Windows PC
** There are no blocked packets by pf that are logged.
# Default deny everything, log for troubleshooting
block log all
What am I missing? It feels like Wireguard is dropping the packets, but
I have the 192.168.126.0/24 IP address range allowed... (being liberal
here).
What more can I do for troubleshooting?
I can see there is a "debug" command for the OpenBSD wg interface, but I
can't figure out where that debug information ends up :(
Thanks,
Steve W.
I am trying to configure my OpenBSD server as a Wireguard server for my
my Windows laptop (and eventually my Android phone)
I am using OpenBSD 7.6 (GENERIC.MP) #338: Mon Sep 30 08:55:35 MDT 2024
My Windows PC is using Windows Wireguard client 0.5.3 (downloaded Dec
31, 2024)
The Windows Wireguard client is able to connect to the OpenBSD server
but no traffic seems to make it across the tunnel. The packet counts go
up, but I cannot ping, ssh, etc
The packet counts also go up on the OpenBSD server (ifconfig wg0)
mini# ifconfig wg0
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
index 5 priority 0 llprio 3
wgport 4433
wgpubkey <wgpubkey>
wgpeer <wgpeer>
wgendpoint 192.168.123.2 55331
tx: 9920, rx: 423232
last handshake: 88 seconds ago
wgaip 192.168.124.0/24
groups: wg
inet 192.168.126.1 netmask 0xffffff00 broadcast 192.168.126.255
I have been running Wireshark on Windows and using tcpdump -i wg0 as
well as tcpdump -i pflog0, as well as looking at the blocked (logged)
packets by tcpdump -r /var/log/pflog. I don't seen any blocked packets.
My pf.conf has:
-----------------------
<close to the top>
set skip on wg0
<further down>
# WireGuard
pass in on egress inet proto udp from any to (egress) port 4433
-----------------------
hostname.wg0
-----------------------
wgkey <wgkey>
wgport 4433
wgpeer <wgpeer key>
wgaip 192.168.124.0/24
inet 192.168.126.1/24
up
On the Windows Wireguard client:
[Interface]
PrivateKey = <privateKey>
Address = 192.168.126.2/24
[Peer]
PublicKey = <public key of OpenBSD server>
AllowedIPs = 192.168.126.0/24
Endpoint = <public IP of OpenBSD Server>:4433
The Windows Wireguard client the following so the tunnel seems to be up:
2024-12-31 17:14:58.244: [TUN] [OpenBSD] Sending keepalive packet to
peer 1 (207.6.196.56:4433)
2024-12-31 17:14:58.247: [TUN] [OpenBSD] Receiving keepalive packet from
peer 1 (207.6.196.56:4433)
Wireshark when I'm pinging from the Windows system to the server
1 0.000000 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=37/9472, ttl=128 (no response found!)
2 4.689174 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=38/9728, ttl=128 (no response found!)
3 9.693818 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=39/9984, ttl=128 (no response found!)
4 14.705842 192.168.126.2 192.168.126.1 ICMP 60 Echo
(ping) request id=0x0001, seq=40/10240, ttl=128 (no response found!)
There is no traffic received on wg0 (tcpdump -i wg0) when I ping from
the Windows system
tcpdump when I ping from the OpenBSD box to the Windows Client
mini# tcpdump -i wg0
tcpdump: listening on wg0, link-type LOOP
17:23:59.960035 192.168.126.1 > 192.168.126.2: icmp: echo request
17:24:00.962192 192.168.126.1 > 192.168.126.2: icmp: echo request
17:24:01.962181 192.168.126.1 > 192.168.126.2: icmp: echo request
17:24:02.962161 192.168.126.1 > 192.168.126.2: icmp: echo request
mini# ping 192.168.126.2
PING 192.168.126.2 (192.168.126.2): 56 data bytes
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
ping: sendmsg: Network is unreachable
ping: wrote 192.168.126.2 64 chars, ret=-1
Network Unreachable... a routing issue?
mini# netstat -rn | grep wg0
192.168.126/24 192.168.126.1 UCn 1 0 - 4 wg0
192.168.126.1 wg0 UHl 0 0 - 1 wg0
192.168.126.2 link#0 UHc 0 4 - 3 wg0
192.168.126.255 192.168.126.1 UHb 0 0 - 1 wg0
** There is nothing seen in Wireshark on the Windows PC
** There are no blocked packets by pf that are logged.
# Default deny everything, log for troubleshooting
block log all
What am I missing? It feels like Wireguard is dropping the packets, but
I have the 192.168.126.0/24 IP address range allowed... (being liberal
here).
What more can I do for troubleshooting?
I can see there is a "debug" command for the OpenBSD wg interface, but I
can't figure out where that debug information ends up :(
Thanks,
Steve W.
Re: 回复: Fastfetch: new package
On Tue, 31 Dec 2024 17:04:11 -0600
izzy Meyer <izder456@disroot.org> wrote:
> On Tue, 31 Dec 2024 11:53:50 +0000
> Li Carter <zhangsongcui@live.cn> wrote:
>
> > A friendly ping
> >
> > ---
> >
> > Hello all,
> >
> > This is a patch that applies to jasperla/openbsd-wip, which finishes
> > porting of sysutils/fastfetch. This port is officially supported by
> > upstream and has been tested in host.
> >
> > Screenshot: https://github.com/user-attachments/assets/599c0985-711a-4afd-9954-defe4c5f73f7
> >
> > Thanks,
> > Carter
> >
>
> Thanks Li, this looks good to me. OK.
>
> I tested on i386 and amd64. Things worked well. I'll test on macppc
> later too. Much appreciated.
>
Li, Stuart,
I just tested on my powerbook6,8 running 7.6-stable, works 100%. Good
job on the port Li. OK? So far, I tested amd64, i386, & macppc. Seems
quality. OK from me.
Appreciated.
--
iz (they/them)
> i like to say mundane things,
> there are too many uninteresting things
> that go unnoticed.
izder456 (dot) neocities (dot) org
izzy Meyer <izder456@disroot.org> wrote:
> On Tue, 31 Dec 2024 11:53:50 +0000
> Li Carter <zhangsongcui@live.cn> wrote:
>
> > A friendly ping
> >
> > ---
> >
> > Hello all,
> >
> > This is a patch that applies to jasperla/openbsd-wip, which finishes
> > porting of sysutils/fastfetch. This port is officially supported by
> > upstream and has been tested in host.
> >
> > Screenshot: https://github.com/user-attachments/assets/599c0985-711a-4afd-9954-defe4c5f73f7
> >
> > Thanks,
> > Carter
> >
>
> Thanks Li, this looks good to me. OK.
>
> I tested on i386 and amd64. Things worked well. I'll test on macppc
> later too. Much appreciated.
>
Li, Stuart,
I just tested on my powerbook6,8 running 7.6-stable, works 100%. Good
job on the port Li. OK? So far, I tested amd64, i386, & macppc. Seems
quality. OK from me.
Appreciated.
--
iz (they/them)
> i like to say mundane things,
> there are too many uninteresting things
> that go unnoticed.
izder456 (dot) neocities (dot) org
Re: 回复: Fastfetch: new package
On Tue, 31 Dec 2024 11:53:50 +0000
Li Carter <zhangsongcui@live.cn> wrote:
> A friendly ping
>
> ---
>
> Hello all,
>
> This is a patch that applies to jasperla/openbsd-wip, which finishes
> porting of sysutils/fastfetch. This port is officially supported by
> upstream and has been tested in host.
>
> Screenshot: https://github.com/user-attachments/assets/599c0985-711a-4afd-9954-defe4c5f73f7
>
> Thanks,
> Carter
>
Thanks Li, this looks good to me. OK.
I tested on i386 and amd64. Things worked well. I'll test on macppc
later too. Much appreciated.
--
iz (they/them)
> i like to say mundane things,
> there are too many uninteresting things
> that go unnoticed.
izder456 (dot) neocities (dot) org
Li Carter <zhangsongcui@live.cn> wrote:
> A friendly ping
>
> ---
>
> Hello all,
>
> This is a patch that applies to jasperla/openbsd-wip, which finishes
> porting of sysutils/fastfetch. This port is officially supported by
> upstream and has been tested in host.
>
> Screenshot: https://github.com/user-attachments/assets/599c0985-711a-4afd-9954-defe4c5f73f7
>
> Thanks,
> Carter
>
Thanks Li, this looks good to me. OK.
I tested on i386 and amd64. Things worked well. I'll test on macppc
later too. Much appreciated.
--
iz (they/them)
> i like to say mundane things,
> there are too many uninteresting things
> that go unnoticed.
izder456 (dot) neocities (dot) org
support multiply webcam in chromium-based browsers
Robert,
I'd like to adjust one patch on all chrome-based browsers in ports tree.
A few days ago I had commited a fix [1] in uvideo.c which allows user to
select in Firefox between connected webcams.
Thus, the same can be done in Chrome-based browsers, but it needs small
adjustment in the patch.
I had used the same limit of number of possible devices with libwebrtc [2],
and updated unveil files to allow /dev/video0 and /dev/video1 which is
created by default.
I had tested the patch only in ungoogled-chromium which I use at
https://webrtc.github.io/samples/src/content/devices/input-output/
but other browsers used the same patch and I assume that it works.
Ok?
Footnotes:
[1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uvideo.c?rev=1.232&content-type=text/x-cvsweb-markup
[2] https://github.com/mozilla/libwebrtc/blob/1389c76d9c79839a2ca069df1db48aa3f2e6a1ac/modules/video_capture/linux/device_info_v4l2.cc#L40-L63
The diff:
Index: www/chromium/Makefile
===================================================================
RCS file: /home/cvs/ports/www/chromium/Makefile,v
diff -u -p -u -p -r1.820 Makefile
--- www/chromium/Makefile 21 Dec 2024 11:39:11 -0000 1.820
+++ www/chromium/Makefile 31 Dec 2024 19:54:02 -0000
@@ -11,6 +11,7 @@ DPB_PROPERTIES+= lonesome
COMMENT= Chromium browser
V= 131.0.6778.204
+REVISION= 0
DISTNAME= chromium-${V}
Index: www/chromium/files/unveil.main
===================================================================
RCS file: /home/cvs/ports/www/chromium/files/unveil.main,v
diff -u -p -u -p -r1.16 unveil.main
--- www/chromium/files/unveil.main 15 Nov 2024 14:03:20 -0000 1.16
+++ www/chromium/files/unveil.main 31 Dec 2024 19:53:06 -0000
@@ -1,5 +1,6 @@
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
# needed for FIDO authentication
/dev/fido rw
Index: www/chromium/files/unveil.utility_video
===================================================================
RCS file: /home/cvs/ports/www/chromium/files/unveil.utility_video,v
diff -u -p -u -p -r1.2 unveil.utility_video
--- www/chromium/files/unveil.utility_video 11 Mar 2022 20:09:41 -0000 1.2
+++ www/chromium/files/unveil.utility_video 31 Dec 2024 19:53:17 -0000
@@ -5,4 +5,5 @@
/tmp rwc
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
Index: www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
===================================================================
RCS file: /home/cvs/ports/www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc,v
diff -u -p -u -p -r1.3 patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
--- www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 21 Apr 2024 10:14:33 -0000 1.3
+++ www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 31 Dec 2024 20:02:41 -0000
@@ -9,7 +9,7 @@ Index: media/capture/video/linux/video_c
// USB VID and PID are both 4 bytes long.
const size_t kVidPidSize = 4;
const size_t kMaxInterfaceNameSize = 256;
-@@ -70,11 +71,15 @@ std::string ExtractFileNameFromDeviceId(const std::str
+@@ -70,11 +71,24 @@ std::string ExtractFileNameFromDeviceId(const std::str
DCHECK(base::StartsWith(device_id, kDevDir, base::CompareCase::SENSITIVE));
return device_id.substr(strlen(kDevDir), device_id.length());
}
@@ -20,12 +20,21 @@ Index: media/capture/video/linux/video_c
public:
void GetDeviceIds(std::vector<std::string>* target_container) override {
+#if BUILDFLAG(IS_OPENBSD)
-+ target_container->emplace_back("/dev/video");
++ char device[13];
++ int fd;
++ /* unveil(2) limits access to /dev/, try /dev/video[0-63] */
++ for (int n = 0; n < 64; n++) {
++ snprintf(device, sizeof(device), "/dev/video%d", n);
++ if ((fd = open(device, O_RDONLY)) != -1) {
++ close(fd);
++ target_container->emplace_back(device);
++ }
++ }
+#else
const base::FilePath path("/dev/");
base::FileEnumerator enumerator(path, false, base::FileEnumerator::FILES,
"video*");
-@@ -82,9 +87,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -82,9 +96,13 @@ class DevVideoFilePathsDeviceProvider
const base::FileEnumerator::FileInfo info = enumerator.GetInfo();
target_container->emplace_back(path.value() + info.GetName().value());
}
@@ -39,7 +48,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
std::string usb_id;
const std::string vid_path =
-@@ -101,9 +110,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -101,9 +119,13 @@ class DevVideoFilePathsDeviceProvider
}
return usb_id;
@@ -53,7 +62,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
const std::string interface_path =
base::StringPrintf(kInterfacePathTemplate, file_name.c_str());
-@@ -114,6 +127,7 @@ class DevVideoFilePathsDeviceProvider
+@@ -114,6 +136,7 @@ class DevVideoFilePathsDeviceProvider
return std::string();
}
return display_name;
@@ -61,7 +70,7 @@ Index: media/capture/video/linux/video_c
}
};
-@@ -219,7 +233,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
+@@ -219,7 +242,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
std::move(callback).Run(std::move(devices_info));
}
Index: www/iridium/Makefile
===================================================================
RCS file: /home/cvs/ports/www/iridium/Makefile,v
diff -u -p -u -p -r1.214 Makefile
--- www/iridium/Makefile 21 Dec 2024 11:39:11 -0000 1.214
+++ www/iridium/Makefile 31 Dec 2024 19:53:57 -0000
@@ -12,6 +12,7 @@ DPB_PROPERTIES+= lonesome
COMMENT= Iridium browser
V= 2024.11.131.1
+REVISION= 0
DISTNAME= iridium-browser-${V}
PKGNAME= iridium-${V}
Index: www/iridium/files/unveil.main
===================================================================
RCS file: /home/cvs/ports/www/iridium/files/unveil.main,v
diff -u -p -u -p -r1.14 unveil.main
--- www/iridium/files/unveil.main 27 Aug 2023 20:52:48 -0000 1.14
+++ www/iridium/files/unveil.main 31 Dec 2024 19:53:34 -0000
@@ -1,5 +1,6 @@
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
# needed for FIDO authentication
/dev/fido rw
Index: www/iridium/files/unveil.utility_video
===================================================================
RCS file: /home/cvs/ports/www/iridium/files/unveil.utility_video,v
diff -u -p -u -p -r1.2 unveil.utility_video
--- www/iridium/files/unveil.utility_video 11 Mar 2022 20:09:56 -0000 1.2
+++ www/iridium/files/unveil.utility_video 31 Dec 2024 19:53:44 -0000
@@ -5,4 +5,5 @@
/tmp rwc
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
Index: www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
===================================================================
RCS file: /home/cvs/ports/www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc,v
diff -u -p -u -p -r1.3 patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
--- www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 22 Jun 2024 06:03:33 -0000 1.3
+++ www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 31 Dec 2024 20:02:37 -0000
@@ -9,7 +9,7 @@ Index: media/capture/video/linux/video_c
// USB VID and PID are both 4 bytes long.
const size_t kVidPidSize = 4;
const size_t kMaxInterfaceNameSize = 256;
-@@ -70,11 +71,15 @@ std::string ExtractFileNameFromDeviceId(const std::str
+@@ -70,11 +71,24 @@ std::string ExtractFileNameFromDeviceId(const std::str
DCHECK(base::StartsWith(device_id, kDevDir, base::CompareCase::SENSITIVE));
return device_id.substr(strlen(kDevDir), device_id.length());
}
@@ -20,12 +20,21 @@ Index: media/capture/video/linux/video_c
public:
void GetDeviceIds(std::vector<std::string>* target_container) override {
+#if BUILDFLAG(IS_OPENBSD)
-+ target_container->emplace_back("/dev/video");
++ char device[13];
++ int fd;
++ /* unveil(2) limits access to /dev/, try /dev/video[0-63] */
++ for (int n = 0; n < 64; n++) {
++ snprintf(device, sizeof(device), "/dev/video%d", n);
++ if ((fd = open(device, O_RDONLY)) != -1) {
++ close(fd);
++ target_container->emplace_back(device);
++ }
++ }
+#else
const base::FilePath path("/dev/");
base::FileEnumerator enumerator(path, false, base::FileEnumerator::FILES,
"video*");
-@@ -82,9 +87,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -82,9 +96,13 @@ class DevVideoFilePathsDeviceProvider
const base::FileEnumerator::FileInfo info = enumerator.GetInfo();
target_container->emplace_back(path.value() + info.GetName().value());
}
@@ -39,7 +48,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
std::string usb_id;
const std::string vid_path =
-@@ -101,9 +110,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -101,9 +119,13 @@ class DevVideoFilePathsDeviceProvider
}
return usb_id;
@@ -53,7 +62,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
const std::string interface_path =
base::StringPrintf(kInterfacePathTemplate, file_name.c_str());
-@@ -114,6 +127,7 @@ class DevVideoFilePathsDeviceProvider
+@@ -114,6 +136,7 @@ class DevVideoFilePathsDeviceProvider
return std::string();
}
return display_name;
@@ -61,7 +70,7 @@ Index: media/capture/video/linux/video_c
}
};
-@@ -219,7 +233,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
+@@ -219,7 +242,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
std::move(callback).Run(std::move(devices_info));
}
Index: www/ungoogled-chromium/Makefile
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/Makefile,v
diff -u -p -u -p -r1.148 Makefile
--- www/ungoogled-chromium/Makefile 22 Dec 2024 11:05:44 -0000 1.148
+++ www/ungoogled-chromium/Makefile 29 Dec 2024 22:58:39 -0000
@@ -13,6 +13,7 @@ COMMENT= Chromium browser sans integrat
V= 131.0.6778.204
UGV= ${V}-1
+REVISION= 0
DISTNAME= ungoogled-chromium-${V}
Index: www/ungoogled-chromium/files/unveil.main
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/files/unveil.main,v
diff -u -p -u -p -r1.5 unveil.main
--- www/ungoogled-chromium/files/unveil.main 16 Nov 2024 12:12:27 -0000 1.5
+++ www/ungoogled-chromium/files/unveil.main 30 Dec 2024 00:16:47 -0000
@@ -1,5 +1,6 @@
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
# needed for FIDO authentication
/dev/fido rw
Index: www/ungoogled-chromium/files/unveil.utility_video
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/files/unveil.utility_video,v
diff -u -p -u -p -r1.1.1.1 unveil.utility_video
--- www/ungoogled-chromium/files/unveil.utility_video 4 Oct 2022 12:55:55 -0000 1.1.1.1
+++ www/ungoogled-chromium/files/unveil.utility_video 31 Dec 2024 19:45:00 -0000
@@ -5,4 +5,5 @@
/tmp rwc
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
Index: www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc,v
diff -u -p -u -p -r1.3 patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
--- www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 23 Apr 2024 07:27:06 -0000 1.3
+++ www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 31 Dec 2024 19:57:28 -0000
@@ -9,7 +9,7 @@ Index: media/capture/video/linux/video_c
// USB VID and PID are both 4 bytes long.
const size_t kVidPidSize = 4;
const size_t kMaxInterfaceNameSize = 256;
-@@ -70,11 +71,15 @@ std::string ExtractFileNameFromDeviceId(const std::str
+@@ -70,11 +71,24 @@ std::string ExtractFileNameFromDeviceId(const std::str
DCHECK(base::StartsWith(device_id, kDevDir, base::CompareCase::SENSITIVE));
return device_id.substr(strlen(kDevDir), device_id.length());
}
@@ -20,12 +20,21 @@ Index: media/capture/video/linux/video_c
public:
void GetDeviceIds(std::vector<std::string>* target_container) override {
+#if BUILDFLAG(IS_OPENBSD)
-+ target_container->emplace_back("/dev/video");
++ char device[13];
++ int fd;
++ /* unveil(2) limits access to /dev/, try /dev/video[0-63] */
++ for (int n = 0; n < 64; n++) {
++ snprintf(device, sizeof(device), "/dev/video%d", n);
++ if ((fd = open(device, O_RDONLY)) != -1) {
++ close(fd);
++ target_container->emplace_back(device);
++ }
++ }
+#else
const base::FilePath path("/dev/");
base::FileEnumerator enumerator(path, false, base::FileEnumerator::FILES,
"video*");
-@@ -82,9 +87,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -82,9 +96,13 @@ class DevVideoFilePathsDeviceProvider
const base::FileEnumerator::FileInfo info = enumerator.GetInfo();
target_container->emplace_back(path.value() + info.GetName().value());
}
@@ -39,7 +48,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
std::string usb_id;
const std::string vid_path =
-@@ -101,9 +110,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -101,9 +119,13 @@ class DevVideoFilePathsDeviceProvider
}
return usb_id;
@@ -53,7 +62,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
const std::string interface_path =
base::StringPrintf(kInterfacePathTemplate, file_name.c_str());
-@@ -114,6 +127,7 @@ class DevVideoFilePathsDeviceProvider
+@@ -114,6 +136,7 @@ class DevVideoFilePathsDeviceProvider
return std::string();
}
return display_name;
@@ -61,7 +70,7 @@ Index: media/capture/video/linux/video_c
}
};
-@@ -219,7 +233,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
+@@ -219,7 +242,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
std::move(callback).Run(std::move(devices_info));
}
--
wbr, Kirill
I'd like to adjust one patch on all chrome-based browsers in ports tree.
A few days ago I had commited a fix [1] in uvideo.c which allows user to
select in Firefox between connected webcams.
Thus, the same can be done in Chrome-based browsers, but it needs small
adjustment in the patch.
I had used the same limit of number of possible devices with libwebrtc [2],
and updated unveil files to allow /dev/video0 and /dev/video1 which is
created by default.
I had tested the patch only in ungoogled-chromium which I use at
https://webrtc.github.io/samples/src/content/devices/input-output/
but other browsers used the same patch and I assume that it works.
Ok?
Footnotes:
[1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uvideo.c?rev=1.232&content-type=text/x-cvsweb-markup
[2] https://github.com/mozilla/libwebrtc/blob/1389c76d9c79839a2ca069df1db48aa3f2e6a1ac/modules/video_capture/linux/device_info_v4l2.cc#L40-L63
The diff:
Index: www/chromium/Makefile
===================================================================
RCS file: /home/cvs/ports/www/chromium/Makefile,v
diff -u -p -u -p -r1.820 Makefile
--- www/chromium/Makefile 21 Dec 2024 11:39:11 -0000 1.820
+++ www/chromium/Makefile 31 Dec 2024 19:54:02 -0000
@@ -11,6 +11,7 @@ DPB_PROPERTIES+= lonesome
COMMENT= Chromium browser
V= 131.0.6778.204
+REVISION= 0
DISTNAME= chromium-${V}
Index: www/chromium/files/unveil.main
===================================================================
RCS file: /home/cvs/ports/www/chromium/files/unveil.main,v
diff -u -p -u -p -r1.16 unveil.main
--- www/chromium/files/unveil.main 15 Nov 2024 14:03:20 -0000 1.16
+++ www/chromium/files/unveil.main 31 Dec 2024 19:53:06 -0000
@@ -1,5 +1,6 @@
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
# needed for FIDO authentication
/dev/fido rw
Index: www/chromium/files/unveil.utility_video
===================================================================
RCS file: /home/cvs/ports/www/chromium/files/unveil.utility_video,v
diff -u -p -u -p -r1.2 unveil.utility_video
--- www/chromium/files/unveil.utility_video 11 Mar 2022 20:09:41 -0000 1.2
+++ www/chromium/files/unveil.utility_video 31 Dec 2024 19:53:17 -0000
@@ -5,4 +5,5 @@
/tmp rwc
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
Index: www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
===================================================================
RCS file: /home/cvs/ports/www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc,v
diff -u -p -u -p -r1.3 patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
--- www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 21 Apr 2024 10:14:33 -0000 1.3
+++ www/chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 31 Dec 2024 20:02:41 -0000
@@ -9,7 +9,7 @@ Index: media/capture/video/linux/video_c
// USB VID and PID are both 4 bytes long.
const size_t kVidPidSize = 4;
const size_t kMaxInterfaceNameSize = 256;
-@@ -70,11 +71,15 @@ std::string ExtractFileNameFromDeviceId(const std::str
+@@ -70,11 +71,24 @@ std::string ExtractFileNameFromDeviceId(const std::str
DCHECK(base::StartsWith(device_id, kDevDir, base::CompareCase::SENSITIVE));
return device_id.substr(strlen(kDevDir), device_id.length());
}
@@ -20,12 +20,21 @@ Index: media/capture/video/linux/video_c
public:
void GetDeviceIds(std::vector<std::string>* target_container) override {
+#if BUILDFLAG(IS_OPENBSD)
-+ target_container->emplace_back("/dev/video");
++ char device[13];
++ int fd;
++ /* unveil(2) limits access to /dev/, try /dev/video[0-63] */
++ for (int n = 0; n < 64; n++) {
++ snprintf(device, sizeof(device), "/dev/video%d", n);
++ if ((fd = open(device, O_RDONLY)) != -1) {
++ close(fd);
++ target_container->emplace_back(device);
++ }
++ }
+#else
const base::FilePath path("/dev/");
base::FileEnumerator enumerator(path, false, base::FileEnumerator::FILES,
"video*");
-@@ -82,9 +87,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -82,9 +96,13 @@ class DevVideoFilePathsDeviceProvider
const base::FileEnumerator::FileInfo info = enumerator.GetInfo();
target_container->emplace_back(path.value() + info.GetName().value());
}
@@ -39,7 +48,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
std::string usb_id;
const std::string vid_path =
-@@ -101,9 +110,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -101,9 +119,13 @@ class DevVideoFilePathsDeviceProvider
}
return usb_id;
@@ -53,7 +62,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
const std::string interface_path =
base::StringPrintf(kInterfacePathTemplate, file_name.c_str());
-@@ -114,6 +127,7 @@ class DevVideoFilePathsDeviceProvider
+@@ -114,6 +136,7 @@ class DevVideoFilePathsDeviceProvider
return std::string();
}
return display_name;
@@ -61,7 +70,7 @@ Index: media/capture/video/linux/video_c
}
};
-@@ -219,7 +233,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
+@@ -219,7 +242,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
std::move(callback).Run(std::move(devices_info));
}
Index: www/iridium/Makefile
===================================================================
RCS file: /home/cvs/ports/www/iridium/Makefile,v
diff -u -p -u -p -r1.214 Makefile
--- www/iridium/Makefile 21 Dec 2024 11:39:11 -0000 1.214
+++ www/iridium/Makefile 31 Dec 2024 19:53:57 -0000
@@ -12,6 +12,7 @@ DPB_PROPERTIES+= lonesome
COMMENT= Iridium browser
V= 2024.11.131.1
+REVISION= 0
DISTNAME= iridium-browser-${V}
PKGNAME= iridium-${V}
Index: www/iridium/files/unveil.main
===================================================================
RCS file: /home/cvs/ports/www/iridium/files/unveil.main,v
diff -u -p -u -p -r1.14 unveil.main
--- www/iridium/files/unveil.main 27 Aug 2023 20:52:48 -0000 1.14
+++ www/iridium/files/unveil.main 31 Dec 2024 19:53:34 -0000
@@ -1,5 +1,6 @@
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
# needed for FIDO authentication
/dev/fido rw
Index: www/iridium/files/unveil.utility_video
===================================================================
RCS file: /home/cvs/ports/www/iridium/files/unveil.utility_video,v
diff -u -p -u -p -r1.2 unveil.utility_video
--- www/iridium/files/unveil.utility_video 11 Mar 2022 20:09:56 -0000 1.2
+++ www/iridium/files/unveil.utility_video 31 Dec 2024 19:53:44 -0000
@@ -5,4 +5,5 @@
/tmp rwc
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
Index: www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
===================================================================
RCS file: /home/cvs/ports/www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc,v
diff -u -p -u -p -r1.3 patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
--- www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 22 Jun 2024 06:03:33 -0000 1.3
+++ www/iridium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 31 Dec 2024 20:02:37 -0000
@@ -9,7 +9,7 @@ Index: media/capture/video/linux/video_c
// USB VID and PID are both 4 bytes long.
const size_t kVidPidSize = 4;
const size_t kMaxInterfaceNameSize = 256;
-@@ -70,11 +71,15 @@ std::string ExtractFileNameFromDeviceId(const std::str
+@@ -70,11 +71,24 @@ std::string ExtractFileNameFromDeviceId(const std::str
DCHECK(base::StartsWith(device_id, kDevDir, base::CompareCase::SENSITIVE));
return device_id.substr(strlen(kDevDir), device_id.length());
}
@@ -20,12 +20,21 @@ Index: media/capture/video/linux/video_c
public:
void GetDeviceIds(std::vector<std::string>* target_container) override {
+#if BUILDFLAG(IS_OPENBSD)
-+ target_container->emplace_back("/dev/video");
++ char device[13];
++ int fd;
++ /* unveil(2) limits access to /dev/, try /dev/video[0-63] */
++ for (int n = 0; n < 64; n++) {
++ snprintf(device, sizeof(device), "/dev/video%d", n);
++ if ((fd = open(device, O_RDONLY)) != -1) {
++ close(fd);
++ target_container->emplace_back(device);
++ }
++ }
+#else
const base::FilePath path("/dev/");
base::FileEnumerator enumerator(path, false, base::FileEnumerator::FILES,
"video*");
-@@ -82,9 +87,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -82,9 +96,13 @@ class DevVideoFilePathsDeviceProvider
const base::FileEnumerator::FileInfo info = enumerator.GetInfo();
target_container->emplace_back(path.value() + info.GetName().value());
}
@@ -39,7 +48,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
std::string usb_id;
const std::string vid_path =
-@@ -101,9 +110,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -101,9 +119,13 @@ class DevVideoFilePathsDeviceProvider
}
return usb_id;
@@ -53,7 +62,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
const std::string interface_path =
base::StringPrintf(kInterfacePathTemplate, file_name.c_str());
-@@ -114,6 +127,7 @@ class DevVideoFilePathsDeviceProvider
+@@ -114,6 +136,7 @@ class DevVideoFilePathsDeviceProvider
return std::string();
}
return display_name;
@@ -61,7 +70,7 @@ Index: media/capture/video/linux/video_c
}
};
-@@ -219,7 +233,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
+@@ -219,7 +242,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
std::move(callback).Run(std::move(devices_info));
}
Index: www/ungoogled-chromium/Makefile
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/Makefile,v
diff -u -p -u -p -r1.148 Makefile
--- www/ungoogled-chromium/Makefile 22 Dec 2024 11:05:44 -0000 1.148
+++ www/ungoogled-chromium/Makefile 29 Dec 2024 22:58:39 -0000
@@ -13,6 +13,7 @@ COMMENT= Chromium browser sans integrat
V= 131.0.6778.204
UGV= ${V}-1
+REVISION= 0
DISTNAME= ungoogled-chromium-${V}
Index: www/ungoogled-chromium/files/unveil.main
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/files/unveil.main,v
diff -u -p -u -p -r1.5 unveil.main
--- www/ungoogled-chromium/files/unveil.main 16 Nov 2024 12:12:27 -0000 1.5
+++ www/ungoogled-chromium/files/unveil.main 30 Dec 2024 00:16:47 -0000
@@ -1,5 +1,6 @@
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
# needed for FIDO authentication
/dev/fido rw
Index: www/ungoogled-chromium/files/unveil.utility_video
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/files/unveil.utility_video,v
diff -u -p -u -p -r1.1.1.1 unveil.utility_video
--- www/ungoogled-chromium/files/unveil.utility_video 4 Oct 2022 12:55:55 -0000 1.1.1.1
+++ www/ungoogled-chromium/files/unveil.utility_video 31 Dec 2024 19:45:00 -0000
@@ -5,4 +5,5 @@
/tmp rwc
# needed for video(4)
-/dev/video rw
+/dev/video0 rw
+/dev/video1 rw
Index: www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
===================================================================
RCS file: /home/cvs/ports/www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc,v
diff -u -p -u -p -r1.3 patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc
--- www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 23 Apr 2024 07:27:06 -0000 1.3
+++ www/ungoogled-chromium/patches/patch-media_capture_video_linux_video_capture_device_factory_v4l2_cc 31 Dec 2024 19:57:28 -0000
@@ -9,7 +9,7 @@ Index: media/capture/video/linux/video_c
// USB VID and PID are both 4 bytes long.
const size_t kVidPidSize = 4;
const size_t kMaxInterfaceNameSize = 256;
-@@ -70,11 +71,15 @@ std::string ExtractFileNameFromDeviceId(const std::str
+@@ -70,11 +71,24 @@ std::string ExtractFileNameFromDeviceId(const std::str
DCHECK(base::StartsWith(device_id, kDevDir, base::CompareCase::SENSITIVE));
return device_id.substr(strlen(kDevDir), device_id.length());
}
@@ -20,12 +20,21 @@ Index: media/capture/video/linux/video_c
public:
void GetDeviceIds(std::vector<std::string>* target_container) override {
+#if BUILDFLAG(IS_OPENBSD)
-+ target_container->emplace_back("/dev/video");
++ char device[13];
++ int fd;
++ /* unveil(2) limits access to /dev/, try /dev/video[0-63] */
++ for (int n = 0; n < 64; n++) {
++ snprintf(device, sizeof(device), "/dev/video%d", n);
++ if ((fd = open(device, O_RDONLY)) != -1) {
++ close(fd);
++ target_container->emplace_back(device);
++ }
++ }
+#else
const base::FilePath path("/dev/");
base::FileEnumerator enumerator(path, false, base::FileEnumerator::FILES,
"video*");
-@@ -82,9 +87,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -82,9 +96,13 @@ class DevVideoFilePathsDeviceProvider
const base::FileEnumerator::FileInfo info = enumerator.GetInfo();
target_container->emplace_back(path.value() + info.GetName().value());
}
@@ -39,7 +48,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
std::string usb_id;
const std::string vid_path =
-@@ -101,9 +110,13 @@ class DevVideoFilePathsDeviceProvider
+@@ -101,9 +119,13 @@ class DevVideoFilePathsDeviceProvider
}
return usb_id;
@@ -53,7 +62,7 @@ Index: media/capture/video/linux/video_c
const std::string file_name = ExtractFileNameFromDeviceId(device_id);
const std::string interface_path =
base::StringPrintf(kInterfacePathTemplate, file_name.c_str());
-@@ -114,6 +127,7 @@ class DevVideoFilePathsDeviceProvider
+@@ -114,6 +136,7 @@ class DevVideoFilePathsDeviceProvider
return std::string();
}
return display_name;
@@ -61,7 +70,7 @@ Index: media/capture/video/linux/video_c
}
};
-@@ -219,7 +233,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
+@@ -219,7 +242,7 @@ void VideoCaptureDeviceFactoryV4L2::GetDevicesInfo(
std::move(callback).Run(std::move(devices_info));
}
--
wbr, Kirill
Re: update: x11/sakura: 3.8.5 -> 3.8.8
ok
вс, 22 дек. 2024 г. в 09:17, Yifei Zhan <openbsd@zhan.science>:
2 years of minor bugfixes and translation updates, tested on amd64
and it works fine.
also cc.d maintainer but I'm not sure if he's still active...
diff --git a/x11/sakura/Makefile b/x11/sakura/Makefile
index 99998827af0..5184db89ca4 100644
--- a/x11/sakura/Makefile
+++ b/x11/sakura/Makefile
@@ -1,11 +1,9 @@
-V = 3.8.5
+V = 3.8.8
COMMENT = GTK and VTE based terminal emulator
DISTNAME = sakura-${V}
EXTRACT_SUFX = .tar.bz2
CATEGORIES = x11
-REVISION = 0
-
HOMEPAGE = http://www.pleyades.net/david/projects/sakura/
MAINTAINER = Victor Kukshiev <andrey0bolkonsky@gmail.com>
diff --git a/x11/sakura/distinfo b/x11/sakura/distinfo
index 3d094a3a853..33b3c093201 100644
--- a/x11/sakura/distinfo
+++ b/x11/sakura/distinfo
@@ -1,2 +1,2 @@
-SHA256 (sakura-3.8.5.tar.bz2) = 1V/pWepQteXO/GvzDIkOdHGZzJjkQ6IZPmyv5vJUDTQ=
-SIZE (sakura-3.8.5.tar.bz2) = 58270
+SHA256 (sakura-3.8.8.tar.bz2) = tqKf+v1darLs+zQfUyGU4+CH3YHv8OEy75wONQt+/Bs=
+SIZE (sakura-3.8.8.tar.bz2) = 60946
diff --git a/x11/sakura/pkg/PLIST b/x11/sakura/pkg/PLIST
index af23705c533..5227f0b0124 100644
--- a/x11/sakura/pkg/PLIST
+++ b/x11/sakura/pkg/PLIST
@@ -20,6 +20,7 @@ share/locale/pt/LC_MESSAGES/sakura.mo
share/locale/pt_BR/LC_MESSAGES/sakura.mo
share/locale/ru/LC_MESSAGES/sakura.mo
share/locale/sv/LC_MESSAGES/sakura.mo
+share/locale/tr/LC_MESSAGES/sakura.mo
share/locale/uk/LC_MESSAGES/sakura.mo
share/locale/zh_CN/LC_MESSAGES/sakura.mo
share/pixmaps/
Hi, about update Ja2-stracciatella and others games
Hi,
Ty to make games working on OpenBSD.
It is possible to update the port ja2-stracciatella please?
There is a bug on certains games: sector can not be enter but with the new version, bugs are corrected.
It is possible please to make assault cube and sauerbraten on OpenBSD packages?
Thank you very much.
Peace.
Ty to make games working on OpenBSD.
It is possible to update the port ja2-stracciatella please?
There is a bug on certains games: sector can not be enter but with the new version, bugs are corrected.
It is possible please to make assault cube and sauerbraten on OpenBSD packages?
Thank you very much.
Peace.
Re: update x11/pekwm-0.3.2
Timo Myyrä wrote (2024-12-30 08:58 CET):
> On Sun, Dec 29 2024, Stefan Hagen wrote:
>
> > Timo Myyrä wrote (2024-12-29 22:01 CET):
> >> Hi,
> >>
> >> Here's an update for the pekwm window manager to bring it to latest
> >> release. Mostly mechanical update, drops some backported patches.
> >> Very briefly tested on amd64.
> >>
> >> Timo
> >
> >> SITES= https://github.com/pekdon/pekwm/releases/download/release-${V}/
> >
> > I get 404 on this URL.
> >
> > This one works for me:
> > https://github.com/pekwm/pekwm/archive/refs/tags/release-${V}/
> >
> > You could also let DIST_TUPLE figure out the URL.
> >
> > Best regards,
> > Stefan
> >
> > [ --8<--- ]
>
> Ah, I thought I got the SITES right but I guess I had the manually
> downloaded release in distfiles instead.
> The above looks good and works for me.
Except that I forgot to add the remove patches :-)
Committed now (with patches removed).
Thank you,
Stefan
> On Sun, Dec 29 2024, Stefan Hagen wrote:
>
> > Timo Myyrä wrote (2024-12-29 22:01 CET):
> >> Hi,
> >>
> >> Here's an update for the pekwm window manager to bring it to latest
> >> release. Mostly mechanical update, drops some backported patches.
> >> Very briefly tested on amd64.
> >>
> >> Timo
> >
> >> SITES= https://github.com/pekdon/pekwm/releases/download/release-${V}/
> >
> > I get 404 on this URL.
> >
> > This one works for me:
> > https://github.com/pekwm/pekwm/archive/refs/tags/release-${V}/
> >
> > You could also let DIST_TUPLE figure out the URL.
> >
> > Best regards,
> > Stefan
> >
> > [ --8<--- ]
>
> Ah, I thought I got the SITES right but I guess I had the manually
> downloaded release in distfiles instead.
> The above looks good and works for me.
Except that I forgot to add the remove patches :-)
Committed now (with patches removed).
Thank you,
Stefan
Re: devel/automake: import automake-1.17
31.12.2024 15:42, Kirill A. Korinsky пишет:
> Yay, thanks for notice it! Replaced 1.16 to 1.17
OK kn
> Yay, thanks for notice it! Replaced 1.16 to 1.17
OK kn
Re: acme-client challenges
Thanks for the response, Florian,
On Tue, 31 Dec 2024 06:55:26 +0100, Florian Obser wrote:
> On 2024-12-30 19:44 -05, Amelia A Lewis <amyzing@talsever.com> wrote:
>> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
>> comm
>> acme-client: bad exit: netproc(39958): 1
>
> your acme-client.conf is about 5.5 years too old:
> https://cvsweb.openbsd.org/src/etc/examples/acme-client.conf#rev1.2
>
> The correct staging url is
> https://acme-staging-v02.api.letsencrypt.org/directory
I worked that out, with updated results:
$ doas acme-client -vv simmonpatch.com
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: https://staging.api.letsencrypt.org/directory: directories
acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172
acme-client: 172.65.46.172: tls_write: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: 172.65.46.172: tls_read: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: https://staging.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(18286): 1
I think that this is because I experimented with it in 2019 or so
(which would have gotten the created copy that I modified further on
taking it up again Sunday). My /etc/examples/acme-client.conf is, like
yours, pointing at acme-v02.api and acme-staging-v02.api, and this
looks like my major bit of stupidity, overlooking the difference
between what I had and what was in examples.
Here's an updated-just now minimized version, using the specified
hostnames (and not the canonical hostnames, which in a moment of less
fatigue occurs to me could be the reason it gave the response above
last night, so a second bit of working-too-late fatigue).
> If your acme-client is the same vintage you probably need to update, I
> don't think it will be able to talk to a v2 api endpoint.
I think I was stupid again, using the staging.api hostname.
$ doas acme-client -nv simmonpatch.com
doas (amyzing@tserig.simmonpatch.com) password:
authority letsencrypt {
api url "https://acme-v01.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-privkey.pem" rsa
}
authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem" rsa
}
domain simmonpatch.com {
domain name "simmonpatch.com"
alternative names { tserig.simmonpatch.com }
domain key "/etc/ssl/private/leo-simmonpatch.com.key" rsa
domain full chain certificate
"/etc/ssl/leo-simmonpatch.com.fullchain.pem"
sign with "letsencrypt-staging"
}
and this looks more promising, as loads of debugging scrolls past, but
dammit!
One more request for a look: is there anything sus in the above or in
the below output? I'll have to look at it more carefully after coffee,
but I wouldn't mind being given a cheat code.
The original output is very long, so let me snip three lines from the
bottom first, then the whole output in order. The whole thing has a
bunch of lines wrapped (mua wraps them on send), but I figured better
to be complete, and not to try sending an attachment.
Okay, original very long output had three alt names, two of them
'service' style aliases for the A record which is the sole alt name
above (both the domain A record and the machine name A record have been
in DNS for five years or more at that IP; not so the CName-s, which
were changed recently). Same three final lines (different numbers in
'netproc(nnnnnn)'), short form is the latest run of three (domain+3
alts, domain+2 alts, domain+1 alt above and full output below).
-- last three --
acme-client: order.status 2
acme-client: unhandled status: 2
acme-client: bad exit: netproc(68704): 1
-- whole thing (third run, using--
$ doas acme-client -vv simmonpatch.com
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: https://acme-staging-v02.api.letsencrypt.org/directory:
directories
acme-client: acme-staging-v02.api.letsencrypt.org: DNS: 172.65.46.172
acme-client: transfer buffer: [{
"FIupg6fYm1w":
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
"keyChange":
"https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService":
"https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf",
"website": "https://letsencrypt.org/docs/staging-environment/"
},
"newAccount":
"https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
"newNonce":
"https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder":
"https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
"renewalInfo":
"https://acme-staging-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
"revokeCert":
"https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
}] (820 bytes)
acme-client: transfer buffer: [{
"key": {
"kty": "RSA",
"n":
"wSD4AguvgUpDYY5_H14dbVvAVLQMkzNamr8svtf35mKpIT0bNJzRtDPoFg2dq_FyDQVWKbqa5dzCKo50526q9YXNEMS8IpIFxapNByaLo4QByVfghziikPyZYPnrcWS40lXQsNARN7crO89eqneJOdThT0BglDqPowso1K9QWAnOXrieqRAqu_8laG3WtBBb0MIMKI_qeakWwVrno_WCk973O4JiMBheHxsY8ikSmd5P1qtU9wIio9hVWqjzSVgdtpIJL7IaXg0uD2nEaZRf8KMBGz0pnyuMpd1rpsQozKE0o3JAZ-22qXaCFf57kjn7RwiXAEgBv2ZaiUAehroN6al8FzqtXkQdBncmQh8XmqT6FkRoF0kbhRTZw4lhLc8h2GlzDL-ZPcocmYUUyUzLQXdadv4fDXwlZ3WDyC0L3ZFZowYJZBivtgBZyBGRWp2oPMMqbn3i9DNycuZfe51VIjnbdKpdxqj7yPc-ot6hsuCVByHPVr2YPfx4j4YSZAp_XC_wPoDmfFrI4w8Gy6tq1MkG6zFSkpE3MSX-_8hi-r8sj7KXmgpUIeLNft2pXTCAppxbn8XZAjwzpr0QKEQ7P19fp0T8dzhSCWzYh5DAxYdF0S4yWVaT2f7GHiuZmza9TexzDlbV1kbjEyTMzG5WwwNvGzZPs8P5m0M0IO9HiUE",
"e": "AQAB"
},
"createdAt": "2024-12-31T12:27:50Z",
"status": "valid"
}] (808 bytes)
acme-client: transfer buffer: [{
"status": "ready",
"expires": "2025-01-07T12:52:07Z",
"identifiers": [
{
"type": "dns",
"value": "simmonpatch.com"
},
{
"type": "dns",
"value": "tserig.simmonpatch.com"
}
],
"authorizations": [
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944",
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"
],
"finalize":
"https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"
}] (518 bytes)
acme-client:
https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374:
certificate
acme-client: transfer buffer: [{
"status": "processing",
"expires": "2025-01-07T12:52:07Z",
"identifiers": [
{
"type": "dns",
"value": "simmonpatch.com"
},
{
"type": "dns",
"value": "tserig.simmonpatch.com"
}
],
"authorizations": [
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944",
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"
],
"finalize":
"https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"
}] (523 bytes)
acme-client: transfer buffer: [{
"status": "processing",
"expires": "2025-01-07T12:52:07Z",
"identifiers": [
{
"type": "dns",
"value": "simmonpatch.com"
},
{
"type": "dns",
"value": "tserig.simmonpatch.com"
}
],
"authorizations": [
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944",
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"
],
"finalize":
"https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"
}] (523 bytes)
acme-client: order.status 2
acme-client: unhandled status: 2
acme-client: bad exit: netproc(66411): 1
Thanks for the help, and if you've gotten to here, thanks for looking
through the above (all three complete attempts are in scrollback, if
it's more useful to see the sequence, but all three in end in
order.status 2 / unhandled status: 2 / bad exit: netproc following
"finalize"). I can send them if someone needs to see them to diagnose.
Do I just need to wait until the expires timestamp
(2025-01-07T12:52:07Z) or something, perhaps?
Amy!
On Tue, 31 Dec 2024 06:55:26 +0100, Florian Obser wrote:
> On 2024-12-30 19:44 -05, Amelia A Lewis <amyzing@talsever.com> wrote:
>> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
>> comm
>> acme-client: bad exit: netproc(39958): 1
>
> your acme-client.conf is about 5.5 years too old:
> https://cvsweb.openbsd.org/src/etc/examples/acme-client.conf#rev1.2
>
> The correct staging url is
> https://acme-staging-v02.api.letsencrypt.org/directory
I worked that out, with updated results:
$ doas acme-client -vv simmonpatch.com
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: https://staging.api.letsencrypt.org/directory: directories
acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172
acme-client: 172.65.46.172: tls_write: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: 172.65.46.172: tls_read: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: https://staging.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(18286): 1
I think that this is because I experimented with it in 2019 or so
(which would have gotten the created copy that I modified further on
taking it up again Sunday). My /etc/examples/acme-client.conf is, like
yours, pointing at acme-v02.api and acme-staging-v02.api, and this
looks like my major bit of stupidity, overlooking the difference
between what I had and what was in examples.
Here's an updated-just now minimized version, using the specified
hostnames (and not the canonical hostnames, which in a moment of less
fatigue occurs to me could be the reason it gave the response above
last night, so a second bit of working-too-late fatigue).
> If your acme-client is the same vintage you probably need to update, I
> don't think it will be able to talk to a v2 api endpoint.
I think I was stupid again, using the staging.api hostname.
$ doas acme-client -nv simmonpatch.com
doas (amyzing@tserig.simmonpatch.com) password:
authority letsencrypt {
api url "https://acme-v01.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-privkey.pem" rsa
}
authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem" rsa
}
domain simmonpatch.com {
domain name "simmonpatch.com"
alternative names { tserig.simmonpatch.com }
domain key "/etc/ssl/private/leo-simmonpatch.com.key" rsa
domain full chain certificate
"/etc/ssl/leo-simmonpatch.com.fullchain.pem"
sign with "letsencrypt-staging"
}
and this looks more promising, as loads of debugging scrolls past, but
dammit!
One more request for a look: is there anything sus in the above or in
the below output? I'll have to look at it more carefully after coffee,
but I wouldn't mind being given a cheat code.
The original output is very long, so let me snip three lines from the
bottom first, then the whole output in order. The whole thing has a
bunch of lines wrapped (mua wraps them on send), but I figured better
to be complete, and not to try sending an attachment.
Okay, original very long output had three alt names, two of them
'service' style aliases for the A record which is the sole alt name
above (both the domain A record and the machine name A record have been
in DNS for five years or more at that IP; not so the CName-s, which
were changed recently). Same three final lines (different numbers in
'netproc(nnnnnn)'), short form is the latest run of three (domain+3
alts, domain+2 alts, domain+1 alt above and full output below).
-- last three --
acme-client: order.status 2
acme-client: unhandled status: 2
acme-client: bad exit: netproc(68704): 1
-- whole thing (third run, using--
$ doas acme-client -vv simmonpatch.com
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: https://acme-staging-v02.api.letsencrypt.org/directory:
directories
acme-client: acme-staging-v02.api.letsencrypt.org: DNS: 172.65.46.172
acme-client: transfer buffer: [{
"FIupg6fYm1w":
"https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
"keyChange":
"https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService":
"https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf",
"website": "https://letsencrypt.org/docs/staging-environment/"
},
"newAccount":
"https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
"newNonce":
"https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder":
"https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
"renewalInfo":
"https://acme-staging-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
"revokeCert":
"https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
}] (820 bytes)
acme-client: transfer buffer: [{
"key": {
"kty": "RSA",
"n":
"wSD4AguvgUpDYY5_H14dbVvAVLQMkzNamr8svtf35mKpIT0bNJzRtDPoFg2dq_FyDQVWKbqa5dzCKo50526q9YXNEMS8IpIFxapNByaLo4QByVfghziikPyZYPnrcWS40lXQsNARN7crO89eqneJOdThT0BglDqPowso1K9QWAnOXrieqRAqu_8laG3WtBBb0MIMKI_qeakWwVrno_WCk973O4JiMBheHxsY8ikSmd5P1qtU9wIio9hVWqjzSVgdtpIJL7IaXg0uD2nEaZRf8KMBGz0pnyuMpd1rpsQozKE0o3JAZ-22qXaCFf57kjn7RwiXAEgBv2ZaiUAehroN6al8FzqtXkQdBncmQh8XmqT6FkRoF0kbhRTZw4lhLc8h2GlzDL-ZPcocmYUUyUzLQXdadv4fDXwlZ3WDyC0L3ZFZowYJZBivtgBZyBGRWp2oPMMqbn3i9DNycuZfe51VIjnbdKpdxqj7yPc-ot6hsuCVByHPVr2YPfx4j4YSZAp_XC_wPoDmfFrI4w8Gy6tq1MkG6zFSkpE3MSX-_8hi-r8sj7KXmgpUIeLNft2pXTCAppxbn8XZAjwzpr0QKEQ7P19fp0T8dzhSCWzYh5DAxYdF0S4yWVaT2f7GHiuZmza9TexzDlbV1kbjEyTMzG5WwwNvGzZPs8P5m0M0IO9HiUE",
"e": "AQAB"
},
"createdAt": "2024-12-31T12:27:50Z",
"status": "valid"
}] (808 bytes)
acme-client: transfer buffer: [{
"status": "ready",
"expires": "2025-01-07T12:52:07Z",
"identifiers": [
{
"type": "dns",
"value": "simmonpatch.com"
},
{
"type": "dns",
"value": "tserig.simmonpatch.com"
}
],
"authorizations": [
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944",
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"
],
"finalize":
"https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"
}] (518 bytes)
acme-client:
https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374:
certificate
acme-client: transfer buffer: [{
"status": "processing",
"expires": "2025-01-07T12:52:07Z",
"identifiers": [
{
"type": "dns",
"value": "simmonpatch.com"
},
{
"type": "dns",
"value": "tserig.simmonpatch.com"
}
],
"authorizations": [
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944",
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"
],
"finalize":
"https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"
}] (523 bytes)
acme-client: transfer buffer: [{
"status": "processing",
"expires": "2025-01-07T12:52:07Z",
"identifiers": [
{
"type": "dns",
"value": "simmonpatch.com"
},
{
"type": "dns",
"value": "tserig.simmonpatch.com"
}
],
"authorizations": [
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248944",
"https://acme-staging-v02.api.letsencrypt.org/acme/authz/178256864/15553248954"
],
"finalize":
"https://acme-staging-v02.api.letsencrypt.org/acme/finalize/178256864/21691984374"
}] (523 bytes)
acme-client: order.status 2
acme-client: unhandled status: 2
acme-client: bad exit: netproc(66411): 1
Thanks for the help, and if you've gotten to here, thanks for looking
through the above (all three complete attempts are in scrollback, if
it's more useful to see the sequence, but all three in end in
order.status 2 / unhandled status: 2 / bad exit: netproc following
"finalize"). I can send them if someone needs to see them to diagnose.
Do I just need to wait until the expires timestamp
(2025-01-07T12:52:07Z) or something, perhaps?
Amy!
Re: devel/automake: import automake-1.17
On Tue, 31 Dec 2024 13:28:06 +0100,
Stuart Henderson <stu@spacehopper.org> wrote:
>
> On 2024/12/31 00:53, Kirill A. Korinsky wrote:
> > ports@,
> >
> > I just noticed that automake-1.17 was released about 6 months ago.
> > I'd like to import it.
> >
> > Announce and changes:
> > https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html
> >
> > I had tested it with some random ports which uses automake, and haven't find
> > any regression.
> >
> > Anyway, to avoid 'First argument to cross-reference may not be empty' I was
> > forced to add some referces. I used "Top" (see patch-doc_automake_texi), but
> > I don't like it, and I'm looking for any suggestion for better way.
> >
> > Feedback? Tests? Ok?
> >
> > Index: devel/automake/Makefile
> > ===================================================================
> > RCS file: /home/cvs/ports/devel/automake/Makefile,v
> > diff -u -p -u -p -r1.39 Makefile
> > --- devel/automake/Makefile 11 Mar 2022 18:49:41 -0000 1.39
> > +++ devel/automake/Makefile 30 Dec 2024 23:14:52 -0000
> > @@ -9,5 +9,6 @@ SUBDIR += 1.13
> > SUBDIR += 1.14
> > SUBDIR += 1.15
> > SUBDIR += 1.16
> > +SUBDIR += 1.17
> >
> > .include <bsd.port.subdir.mk>
> >
> > --
> > wbr, Kirill
>
> post-install needs updating.
>
Yay, thanks for notice it! Replaced 1.16 to 1.17
--
wbr, Kirill
Stuart Henderson <stu@spacehopper.org> wrote:
>
> On 2024/12/31 00:53, Kirill A. Korinsky wrote:
> > ports@,
> >
> > I just noticed that automake-1.17 was released about 6 months ago.
> > I'd like to import it.
> >
> > Announce and changes:
> > https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html
> >
> > I had tested it with some random ports which uses automake, and haven't find
> > any regression.
> >
> > Anyway, to avoid 'First argument to cross-reference may not be empty' I was
> > forced to add some referces. I used "Top" (see patch-doc_automake_texi), but
> > I don't like it, and I'm looking for any suggestion for better way.
> >
> > Feedback? Tests? Ok?
> >
> > Index: devel/automake/Makefile
> > ===================================================================
> > RCS file: /home/cvs/ports/devel/automake/Makefile,v
> > diff -u -p -u -p -r1.39 Makefile
> > --- devel/automake/Makefile 11 Mar 2022 18:49:41 -0000 1.39
> > +++ devel/automake/Makefile 30 Dec 2024 23:14:52 -0000
> > @@ -9,5 +9,6 @@ SUBDIR += 1.13
> > SUBDIR += 1.14
> > SUBDIR += 1.15
> > SUBDIR += 1.16
> > +SUBDIR += 1.17
> >
> > .include <bsd.port.subdir.mk>
> >
> > --
> > wbr, Kirill
>
> post-install needs updating.
>
Yay, thanks for notice it! Replaced 1.16 to 1.17
--
wbr, Kirill
Re: devel/automake: import automake-1.17
On 2024/12/31 00:53, Kirill A. Korinsky wrote:
> ports@,
>
> I just noticed that automake-1.17 was released about 6 months ago.
> I'd like to import it.
>
> Announce and changes:
> https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html
>
> I had tested it with some random ports which uses automake, and haven't find
> any regression.
>
> Anyway, to avoid 'First argument to cross-reference may not be empty' I was
> forced to add some referces. I used "Top" (see patch-doc_automake_texi), but
> I don't like it, and I'm looking for any suggestion for better way.
>
> Feedback? Tests? Ok?
>
> Index: devel/automake/Makefile
> ===================================================================
> RCS file: /home/cvs/ports/devel/automake/Makefile,v
> diff -u -p -u -p -r1.39 Makefile
> --- devel/automake/Makefile 11 Mar 2022 18:49:41 -0000 1.39
> +++ devel/automake/Makefile 30 Dec 2024 23:14:52 -0000
> @@ -9,5 +9,6 @@ SUBDIR += 1.13
> SUBDIR += 1.14
> SUBDIR += 1.15
> SUBDIR += 1.16
> +SUBDIR += 1.17
>
> .include <bsd.port.subdir.mk>
>
> --
> wbr, Kirill
post-install needs updating.
> ports@,
>
> I just noticed that automake-1.17 was released about 6 months ago.
> I'd like to import it.
>
> Announce and changes:
> https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html
>
> I had tested it with some random ports which uses automake, and haven't find
> any regression.
>
> Anyway, to avoid 'First argument to cross-reference may not be empty' I was
> forced to add some referces. I used "Top" (see patch-doc_automake_texi), but
> I don't like it, and I'm looking for any suggestion for better way.
>
> Feedback? Tests? Ok?
>
> Index: devel/automake/Makefile
> ===================================================================
> RCS file: /home/cvs/ports/devel/automake/Makefile,v
> diff -u -p -u -p -r1.39 Makefile
> --- devel/automake/Makefile 11 Mar 2022 18:49:41 -0000 1.39
> +++ devel/automake/Makefile 30 Dec 2024 23:14:52 -0000
> @@ -9,5 +9,6 @@ SUBDIR += 1.13
> SUBDIR += 1.14
> SUBDIR += 1.15
> SUBDIR += 1.16
> +SUBDIR += 1.17
>
> .include <bsd.port.subdir.mk>
>
> --
> wbr, Kirill
post-install needs updating.
Re: [update] Lagrange to 1.18.4
>Hi,
>
>this is a simple update for Lagrange to 1.18.4.
>
>Some testing done on amd64. No issues found.
>
>portcheck and 'make port-lib-depends-check' are happy.
>
>Changes listed here [1].
>
>Comments?
>
>Thanks!
>
>[1] https://github.com/skyjake/lagrange/releases
>
>
>Index: Makefile
>===================================================================
>RCS file: /daten/openbsdmirror/cvs/mirror/ports/net/lagrange/Makefile,v
>retrieving revision 1.76
>diff -u -p -u -p -r1.76 Makefile
>--- Makefile 14 Dec 2024 15:17:01 -0000 1.76
>+++ Makefile 24 Dec 2024 12:17:07 -0000
>@@ -1,6 +1,5 @@
> COMMENT = SDL multi protocol navigator
>-VERSION = 1.18.3
>-REVISION = 0
>+VERSION = 1.18.4
>
> DISTNAME = lagrange-${VERSION}
>
>Index: distinfo
>===================================================================
>RCS file: /daten/openbsdmirror/cvs/mirror/ports/net/lagrange/distinfo,v
>retrieving revision 1.62
>diff -u -p -u -p -r1.62 distinfo
>--- distinfo 27 Oct 2024 22:43:22 -0000 1.62
>+++ distinfo 24 Dec 2024 12:17:07 -0000
>@@ -1,2 +1,2 @@
>-SHA256 (lagrange-1.18.3.tar.gz) = xDLi9N01ps7g9NWneXRwjsb+12vBPMYwu1BlCs7IfmI=
>-SIZE (lagrange-1.18.3.tar.gz) = 10278835
>+SHA256 (lagrange-1.18.4.tar.gz) = aXJ1Cs/LuDbsM/592s6UFQgbkmNT19Lqt6LPj67mbTA=
>+SIZE (lagrange-1.18.4.tar.gz) = 11314489
>
Hi,
friendly ping.
--
greetings,
Florian Viehweger
>
>this is a simple update for Lagrange to 1.18.4.
>
>Some testing done on amd64. No issues found.
>
>portcheck and 'make port-lib-depends-check' are happy.
>
>Changes listed here [1].
>
>Comments?
>
>Thanks!
>
>[1] https://github.com/skyjake/lagrange/releases
>
>
>Index: Makefile
>===================================================================
>RCS file: /daten/openbsdmirror/cvs/mirror/ports/net/lagrange/Makefile,v
>retrieving revision 1.76
>diff -u -p -u -p -r1.76 Makefile
>--- Makefile 14 Dec 2024 15:17:01 -0000 1.76
>+++ Makefile 24 Dec 2024 12:17:07 -0000
>@@ -1,6 +1,5 @@
> COMMENT = SDL multi protocol navigator
>-VERSION = 1.18.3
>-REVISION = 0
>+VERSION = 1.18.4
>
> DISTNAME = lagrange-${VERSION}
>
>Index: distinfo
>===================================================================
>RCS file: /daten/openbsdmirror/cvs/mirror/ports/net/lagrange/distinfo,v
>retrieving revision 1.62
>diff -u -p -u -p -r1.62 distinfo
>--- distinfo 27 Oct 2024 22:43:22 -0000 1.62
>+++ distinfo 24 Dec 2024 12:17:07 -0000
>@@ -1,2 +1,2 @@
>-SHA256 (lagrange-1.18.3.tar.gz) = xDLi9N01ps7g9NWneXRwjsb+12vBPMYwu1BlCs7IfmI=
>-SIZE (lagrange-1.18.3.tar.gz) = 10278835
>+SHA256 (lagrange-1.18.4.tar.gz) = aXJ1Cs/LuDbsM/592s6UFQgbkmNT19Lqt6LPj67mbTA=
>+SIZE (lagrange-1.18.4.tar.gz) = 11314489
>
Hi,
friendly ping.
--
greetings,
Florian Viehweger
Re: Zeek on OpenBSD: clustering issue and dropping privileges
On Mon, Dec 30, 2024 at 07:53:00PM +0100, Antoine Jacoutot wrote:
> On December 30, 2024 5:39:52 PM GMT+01:00, "Jörgen Maas" <jorgen.maas@gmail.com> wrote:
> >Hi there,
> >
> >I've been trying to get Zeek to work in a very simple cluster setup; the
> >problem is that my workers are not able to grab any data and create the
> >expected log files. The cluster config is a single node (localhost) and
> >monitoring of two interfaces, basically what's in the default node.cfg
> >(manager, proxy, logger, 2 x worker). All processes start, and are
> >listening on localhost for incoming connections. Testing the connectivity
> >with telnet to these ports gets me to a full connection. Nothing is logged
> >in stderr.log, i'm a bit puzzled :S
> >
> >In standalone mode running against a single interface Zeek is working fine.
> >
> >I'm running PF but have the "set skip lo0" set in /etc/pf.conf.
> >Zeek 6.0.5 is from packages on OpenBSD 7.6 / amd64
> >This used to work fine for me "earlier" (older OpenBSD and older version of
> >the pkg).
> >
> >Is anyone out there running this version of Zeek in a cluster setup
> >successfully?
> >
> >Another question is that it seems there's an option to drop privileges but
> >this is not provided "out of the box" by the pkg. Has this ever been
> >explored yet?
> >
> >Thanks in advance!
> >
> >Kind regards,
> >Jörgen
>
> Hi.
>
> It's a known issue, reported multiple times.
> I've looked a few times but wasn't able to find the culprit... :-/
>
> I also tried updating to a newer release but failed. We are lacking stuff available in other OSes.
>
> If one can find the issue I will put the time into bringing the port up to date.
>
>
> --
> Antoine
>
I've been running zeek on and off on a couple of gateway-devices, and the clustering support in zeek
has been working on and off. Currently broken unfortunately.
My plan is to instead span interfaces and run non-clustered, but I have not gotten around to it yet.
It's not ideal, but I rarely saturate the links anyway, so it will hopefully be a good workaround.
Depending on your environment, perhaps that is a solution for your problem as well?
/Magnus
> On December 30, 2024 5:39:52 PM GMT+01:00, "Jörgen Maas" <jorgen.maas@gmail.com> wrote:
> >Hi there,
> >
> >I've been trying to get Zeek to work in a very simple cluster setup; the
> >problem is that my workers are not able to grab any data and create the
> >expected log files. The cluster config is a single node (localhost) and
> >monitoring of two interfaces, basically what's in the default node.cfg
> >(manager, proxy, logger, 2 x worker). All processes start, and are
> >listening on localhost for incoming connections. Testing the connectivity
> >with telnet to these ports gets me to a full connection. Nothing is logged
> >in stderr.log, i'm a bit puzzled :S
> >
> >In standalone mode running against a single interface Zeek is working fine.
> >
> >I'm running PF but have the "set skip lo0" set in /etc/pf.conf.
> >Zeek 6.0.5 is from packages on OpenBSD 7.6 / amd64
> >This used to work fine for me "earlier" (older OpenBSD and older version of
> >the pkg).
> >
> >Is anyone out there running this version of Zeek in a cluster setup
> >successfully?
> >
> >Another question is that it seems there's an option to drop privileges but
> >this is not provided "out of the box" by the pkg. Has this ever been
> >explored yet?
> >
> >Thanks in advance!
> >
> >Kind regards,
> >Jörgen
>
> Hi.
>
> It's a known issue, reported multiple times.
> I've looked a few times but wasn't able to find the culprit... :-/
>
> I also tried updating to a newer release but failed. We are lacking stuff available in other OSes.
>
> If one can find the issue I will put the time into bringing the port up to date.
>
>
> --
> Antoine
>
I've been running zeek on and off on a couple of gateway-devices, and the clustering support in zeek
has been working on and off. Currently broken unfortunately.
My plan is to instead span interfaces and run non-clustered, but I have not gotten around to it yet.
It's not ideal, but I rarely saturate the links anyway, so it will hopefully be a good workaround.
Depending on your environment, perhaps that is a solution for your problem as well?
/Magnus
Monday, December 30, 2024
Re: KDE Plasma menu crashes on text input
On Mon Dec 30, 2024 at 02:43:30PM +0000, Klemens Nanni wrote:
> 12.06.2024 18:50, Klemens Nanni пишет:
> > Today's snap and kde-plasma-extras-6.0.5p0 starts on a T14 gen3 Intel,
> > I can click through the menu in the bottom left corner, but typing to
> > search/filter applications immediately crashes the menu, the background
> > becomes black/white again, X11 keeps running though.
> >
> > First time starting KDE Plasma on this installation, i.e. no ~/.config/
> > or other files from previous attempts:
> >
> > ~/.config/kwinrc contains this as per package readme:
> > [Compositing]
> > Enabled=false
> >
> > ~/.xsession is this as per package readme:
> > #!/bin/sh
> > export XDG_RUNTIME_DIR=/tmp/run/$(id -u)
> > if [ ! -d $XDG_RUNTIME_DIR ]; then
> > mkdir -m 700 -p $XDG_RUNTIME_DIR
> > fi
> > export DESKTOP_SESSION=plasma
> > export QT_FORCE_STDERR_LOGGING=1
> > export QT_LOGGING_RULES="*=true"
> > export XDG_CURRENT_DESKTOP=KDE
> > /usr/local/bin/startplasma-x11 > ~/.startplasma-x11.log 2>&1
>
> Tried yesterday again with a fresh user profile, but nothing changed;
> plasmashell crashes when typing text in menu:
>
> #0 g_log_structured_array (log_level=<optimized out>, fields=<optimized out>, n_fields=<optimized out>) at ../glib-2.82.4/glib/gmessages.c:1867
> #1 0x000005799b41f155 in g_log_default_handler (log_domain=<optimized out>, log_level=17, message=<optimized out>, unused_data=<optimized out>) at ../glib-2.82.4/glib/gmessages.c:3412
> #2 0x000005799b41ecc2 in g_logv (log_domain=0x5799b35c96c "GLib", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=<optimized out>) at ../glib-2.82.4/glib/gmessages.c:1246
> #3 0x000005799b41e825 in g_log (log_domain=0xffffffff00000011 <error: Cannot access memory at address 0xffffffff00000011>, log_level=0, format=0x57949c98e40 "") at ../glib-2.82.4/glib/gmessages.c:1315
> #4 0x000005799b4793b2 in g_wakeup_new () at ../glib-2.82.4/glib/gwakeup.c:162
> #5 0x000005799b4112c0 in g_main_context_new_with_flags (flags=G_MAIN_CONTEXT_FLAGS_NONE) at ../glib-2.82.4/glib/gmain.c:663
> #6 0x00000579a575bfd4 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) () from /usr/local/lib/libQt6Core.so.5.0
> #7 0x00000579a575c258 in QEventDispatcherGlib::QEventDispatcherGlib(QObject*) () from /usr/local/lib/libQt6Core.so.5.0
> #8 0x00000579a56697bb in QThreadPrivate::createEventDispatcher(QThreadData*) () from /usr/local/lib/libQt6Core.so.5.0
> #9 0x00000579a55c96df in QThreadData::createEventDispatcher() () from /usr/local/lib/libQt6Core.so.5.0
> #10 0x00000579a5669968 in QThreadPrivate::start(void*) () from /usr/local/lib/libQt6Core.so.5.0
> #11 0x00000579b770a162 in _rthread_start (v=0x0) at /usr/src/lib/librthread/rthread.c:96
> #12 0x00000579114ad9fa in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:87
>
>
> Logs are flooded:
> $ du -h .startplasma-x11.log
> 3.9G .startplasma-x11.log
> $ wc -l .startplasma-x11.log
> 40444457 .startplasma-x11.log
>
> One line looks relevant:
> (process:951): GLib-ERROR **: 03:52:26.152: Creating pipes for GWakeup: Too many open files
>
> The system/user runs with
> $ sysctl -n kern.maxfiles ; ulimit -n
> 8192
> 512
>
> I did not find anything wrt. increasing limits in package docs/readmes.
>
Could you try it with the "maxpower" ridiculous open profile, to verify
it's a limits issue, please?
/etc/login.conf.d/maxpower
maxpower:\
:datasize=infinity:\
:datasize-max=infinity:\
:datasize-cur=infinity:\
:maxproc=infinity:\
:maxproc-max=infinity:\
:maxproc-cur=infinity:\
:openfiles=infinity:\
:openfiles-max=infinity:\
:openfiles-cur=infinity:\
:stacksize-cur=8M:\
:tc=default:
> 12.06.2024 18:50, Klemens Nanni пишет:
> > Today's snap and kde-plasma-extras-6.0.5p0 starts on a T14 gen3 Intel,
> > I can click through the menu in the bottom left corner, but typing to
> > search/filter applications immediately crashes the menu, the background
> > becomes black/white again, X11 keeps running though.
> >
> > First time starting KDE Plasma on this installation, i.e. no ~/.config/
> > or other files from previous attempts:
> >
> > ~/.config/kwinrc contains this as per package readme:
> > [Compositing]
> > Enabled=false
> >
> > ~/.xsession is this as per package readme:
> > #!/bin/sh
> > export XDG_RUNTIME_DIR=/tmp/run/$(id -u)
> > if [ ! -d $XDG_RUNTIME_DIR ]; then
> > mkdir -m 700 -p $XDG_RUNTIME_DIR
> > fi
> > export DESKTOP_SESSION=plasma
> > export QT_FORCE_STDERR_LOGGING=1
> > export QT_LOGGING_RULES="*=true"
> > export XDG_CURRENT_DESKTOP=KDE
> > /usr/local/bin/startplasma-x11 > ~/.startplasma-x11.log 2>&1
>
> Tried yesterday again with a fresh user profile, but nothing changed;
> plasmashell crashes when typing text in menu:
>
> #0 g_log_structured_array (log_level=<optimized out>, fields=<optimized out>, n_fields=<optimized out>) at ../glib-2.82.4/glib/gmessages.c:1867
> #1 0x000005799b41f155 in g_log_default_handler (log_domain=<optimized out>, log_level=17, message=<optimized out>, unused_data=<optimized out>) at ../glib-2.82.4/glib/gmessages.c:3412
> #2 0x000005799b41ecc2 in g_logv (log_domain=0x5799b35c96c "GLib", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=<optimized out>) at ../glib-2.82.4/glib/gmessages.c:1246
> #3 0x000005799b41e825 in g_log (log_domain=0xffffffff00000011 <error: Cannot access memory at address 0xffffffff00000011>, log_level=0, format=0x57949c98e40 "") at ../glib-2.82.4/glib/gmessages.c:1315
> #4 0x000005799b4793b2 in g_wakeup_new () at ../glib-2.82.4/glib/gwakeup.c:162
> #5 0x000005799b4112c0 in g_main_context_new_with_flags (flags=G_MAIN_CONTEXT_FLAGS_NONE) at ../glib-2.82.4/glib/gmain.c:663
> #6 0x00000579a575bfd4 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) () from /usr/local/lib/libQt6Core.so.5.0
> #7 0x00000579a575c258 in QEventDispatcherGlib::QEventDispatcherGlib(QObject*) () from /usr/local/lib/libQt6Core.so.5.0
> #8 0x00000579a56697bb in QThreadPrivate::createEventDispatcher(QThreadData*) () from /usr/local/lib/libQt6Core.so.5.0
> #9 0x00000579a55c96df in QThreadData::createEventDispatcher() () from /usr/local/lib/libQt6Core.so.5.0
> #10 0x00000579a5669968 in QThreadPrivate::start(void*) () from /usr/local/lib/libQt6Core.so.5.0
> #11 0x00000579b770a162 in _rthread_start (v=0x0) at /usr/src/lib/librthread/rthread.c:96
> #12 0x00000579114ad9fa in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:87
>
>
> Logs are flooded:
> $ du -h .startplasma-x11.log
> 3.9G .startplasma-x11.log
> $ wc -l .startplasma-x11.log
> 40444457 .startplasma-x11.log
>
> One line looks relevant:
> (process:951): GLib-ERROR **: 03:52:26.152: Creating pipes for GWakeup: Too many open files
>
> The system/user runs with
> $ sysctl -n kern.maxfiles ; ulimit -n
> 8192
> 512
>
> I did not find anything wrt. increasing limits in package docs/readmes.
>
Could you try it with the "maxpower" ridiculous open profile, to verify
it's a limits issue, please?
/etc/login.conf.d/maxpower
maxpower:\
:datasize=infinity:\
:datasize-max=infinity:\
:datasize-cur=infinity:\
:maxproc=infinity:\
:maxproc-max=infinity:\
:maxproc-cur=infinity:\
:openfiles=infinity:\
:openfiles-max=infinity:\
:openfiles-cur=infinity:\
:stacksize-cur=8M:\
:tc=default:
update devel/boehm-gc-8.2.8
Hi,
Here's an update for the boehm-gc. This update fixes known issue in
lang/ecl port. Quickly tested with lang/ecl and www/w3m ports on amd64
but could use more thorough testing.
timo
diff /usr/ports
commit - 249cdbc13b64ccbf1b0f4c92f4775e302caa0a15
path + /usr/ports
blob - 273ceaca932897fef8946795e3feef661d57d0aa
file + devel/boehm-gc/Makefile
--- devel/boehm-gc/Makefile
+++ devel/boehm-gc/Makefile
@@ -1,8 +1,8 @@
COMMENT-main= garbage collection and memory leak detection for C and C++
COMMENT-atomic= access to hardware provided atomic memory operations
-VERSION= 8.2.4
-LIBAO_VERSION= 7.8.0
+VERSION= 8.2.8
+LIBAO_VERSION= 7.8.2
# has various machine-dependent parts; updates definitely need
# tests on more than just amd64.
blob - fb84281f509ced39ff52647bf67261bb541c794f
file + devel/boehm-gc/distinfo
--- devel/boehm-gc/distinfo
+++ devel/boehm-gc/distinfo
@@ -1,4 +1,4 @@
-SHA256 (gc-8.2.4.tar.gz) = PQ082+B3QD0xBrtA8Mu1Y0E9bv27Kn4c1ohlld7Ej8I=
-SHA256 (libatomic_ops-7.8.0.tar.gz) = FWdudnThG9paflCnP02efWBFInG4rPb9Oacf79+J+jE=
-SIZE (gc-8.2.4.tar.gz) = 1210929
-SIZE (libatomic_ops-7.8.0.tar.gz) = 526300
+SHA256 (gc-8.2.8.tar.gz) = dkkCBiHLJjJeH7XIdCWQ2S+0jOXCWbUC+vfZ+12rsWA=
+SHA256 (libatomic_ops-7.8.2.tar.gz) = 0wUgf+IH8rP7XLTAGdoStEzj/LxZPf1QgNhnsaJBm1E=
+SIZE (gc-8.2.8.tar.gz) = 1219553
+SIZE (libatomic_ops-7.8.2.tar.gz) = 524637
blob - 2ffba8143bfa1fb25f2b0bb584c20992503c2bcb
file + devel/boehm-gc/patches/patch-os_dep_c
--- devel/boehm-gc/patches/patch-os_dep_c
+++ devel/boehm-gc/patches/patch-os_dep_c
@@ -3,7 +3,7 @@
Index: os_dep.c
--- os_dep.c.orig
+++ os_dep.c
-@@ -887,7 +887,7 @@ GC_INNER size_t GC_page_size = 0;
+@@ -889,7 +889,7 @@ GC_INNER size_t GC_page_size = 0;
# if defined(SUNOS5SIGS) || defined(IRIX5) || defined(OSF1) \
|| defined(HAIKU) || defined(HURD) || defined(FREEBSD) \
Here's an update for the boehm-gc. This update fixes known issue in
lang/ecl port. Quickly tested with lang/ecl and www/w3m ports on amd64
but could use more thorough testing.
timo
diff /usr/ports
commit - 249cdbc13b64ccbf1b0f4c92f4775e302caa0a15
path + /usr/ports
blob - 273ceaca932897fef8946795e3feef661d57d0aa
file + devel/boehm-gc/Makefile
--- devel/boehm-gc/Makefile
+++ devel/boehm-gc/Makefile
@@ -1,8 +1,8 @@
COMMENT-main= garbage collection and memory leak detection for C and C++
COMMENT-atomic= access to hardware provided atomic memory operations
-VERSION= 8.2.4
-LIBAO_VERSION= 7.8.0
+VERSION= 8.2.8
+LIBAO_VERSION= 7.8.2
# has various machine-dependent parts; updates definitely need
# tests on more than just amd64.
blob - fb84281f509ced39ff52647bf67261bb541c794f
file + devel/boehm-gc/distinfo
--- devel/boehm-gc/distinfo
+++ devel/boehm-gc/distinfo
@@ -1,4 +1,4 @@
-SHA256 (gc-8.2.4.tar.gz) = PQ082+B3QD0xBrtA8Mu1Y0E9bv27Kn4c1ohlld7Ej8I=
-SHA256 (libatomic_ops-7.8.0.tar.gz) = FWdudnThG9paflCnP02efWBFInG4rPb9Oacf79+J+jE=
-SIZE (gc-8.2.4.tar.gz) = 1210929
-SIZE (libatomic_ops-7.8.0.tar.gz) = 526300
+SHA256 (gc-8.2.8.tar.gz) = dkkCBiHLJjJeH7XIdCWQ2S+0jOXCWbUC+vfZ+12rsWA=
+SHA256 (libatomic_ops-7.8.2.tar.gz) = 0wUgf+IH8rP7XLTAGdoStEzj/LxZPf1QgNhnsaJBm1E=
+SIZE (gc-8.2.8.tar.gz) = 1219553
+SIZE (libatomic_ops-7.8.2.tar.gz) = 524637
blob - 2ffba8143bfa1fb25f2b0bb584c20992503c2bcb
file + devel/boehm-gc/patches/patch-os_dep_c
--- devel/boehm-gc/patches/patch-os_dep_c
+++ devel/boehm-gc/patches/patch-os_dep_c
@@ -3,7 +3,7 @@
Index: os_dep.c
--- os_dep.c.orig
+++ os_dep.c
-@@ -887,7 +887,7 @@ GC_INNER size_t GC_page_size = 0;
+@@ -889,7 +889,7 @@ GC_INNER size_t GC_page_size = 0;
# if defined(SUNOS5SIGS) || defined(IRIX5) || defined(OSF1) \
|| defined(HAIKU) || defined(HURD) || defined(FREEBSD) \
Re: acme-client challenges
On 2024-12-30 19:44 -05, Amelia A Lewis <amyzing@talsever.com> wrote:
> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
> comm
> acme-client: bad exit: netproc(39958): 1
your acme-client.conf is about 5.5 years too old:
https://cvsweb.openbsd.org/src/etc/examples/acme-client.conf#rev1.2
The correct staging url is
https://acme-staging-v02.api.letsencrypt.org/directory
If your acme-client is the same vintage you probably need to update, I
don't think it will be able to talk to a v2 api endpoint.
--
In my defence, I have been left unsupervised.
> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
> comm
> acme-client: bad exit: netproc(39958): 1
your acme-client.conf is about 5.5 years too old:
https://cvsweb.openbsd.org/src/etc/examples/acme-client.conf#rev1.2
The correct staging url is
https://acme-staging-v02.api.letsencrypt.org/directory
If your acme-client is the same vintage you probably need to update, I
don't think it will be able to talk to a v2 api endpoint.
--
In my defence, I have been left unsupervised.
Re: acme-client challenges
On Mon, Dec 30, 2024 at 07:44:15PM -0500, Amelia A Lewis wrote:
> authority letsencrypt-staging {
> api url "https://acme-staging.api.letsencrypt.org/directory"
> account key "/etc/acme/letsencrypt-staging-privkey.pem"
> }
>
> domain simmonpatch.com {
> alternative names { tserig.simmonpatch.com,
> mail.simmonpatch.com, www.simmonpatch.com }
> domain key "/etc/ssl/private/leo-simmonpatch.com.key"
> domain certificate "/etc/ssl/leo-simmonpatch.com.crt"
> domain full chain certificate
> "/etc/ssl/leo-simmonpatch.com.fullchain.pem"
> sign with letsencrypt-staging
> }
According to /etc/examples/acme-client.conf,
authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
and acme-staging-v02.api.letsencrypt.org does resolve.
> authority letsencrypt-staging {
> api url "https://acme-staging.api.letsencrypt.org/directory"
> account key "/etc/acme/letsencrypt-staging-privkey.pem"
> }
>
> domain simmonpatch.com {
> alternative names { tserig.simmonpatch.com,
> mail.simmonpatch.com, www.simmonpatch.com }
> domain key "/etc/ssl/private/leo-simmonpatch.com.key"
> domain certificate "/etc/ssl/leo-simmonpatch.com.crt"
> domain full chain certificate
> "/etc/ssl/leo-simmonpatch.com.fullchain.pem"
> sign with letsencrypt-staging
> }
According to /etc/examples/acme-client.conf,
authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
and acme-staging-v02.api.letsencrypt.org does resolve.
Re: acme-client challenges
updating with a little more info on most-recent error.
On Mon, 30 Dec 2024 22:54:52 -0500, Amelia A Lewis wrote:
[snip]
> lessee, delete an 'acme-' ...
>
> $ doas acme-client -vv simmonpatch.com
> acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
> key
> acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
> acme-client: https://staging.api.letsencrypt.org/directory: directories
> acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172
> acme-client: 172.65.46.172: tls_write: name
> `staging.api.letsencrypt.org' not present in server certificate
> acme-client: 172.65.46.172: tls_read: name
> `staging.api.letsencrypt.org' not present in server certificate
> acme-client: https://staging.api.letsencrypt.org/directory: bad comm
> acme-client: bad exit: netproc(18286): 1
>
[snip some more; i talk too much]
>
> Thanks for the quick reply and pointers! Have you any idea what the
> tls_write tls_read errors are? They're not triggering off pretend pear
> x1 and bogus broccoli x2 are they?
Call stack for the tls_read/tls_write bit:
netproc.c/nreq() -> http.c/http_get() -> http.c/http_alloc() \
-> http.c/dotlsread() -> http.c/tls_read()
-> http.c/dotlswrite() -> http.c/tls_write()
There are three calls of http_get() in netproc, one directly in nreq()
(most likely?, line 203), and two more in sreq(), which isn't called by
nreq() directly, but is called ten times by various dosomething()
functions, and it's too late for me to continue tracing (prolly easier
to instrument, but reading (somebody else's) code does make it easier
to sleep).
I'm not familiar enough with certificate contents and the protocol's
expectations of contents to decipher which server is supposed to have
staging.api in it and doesn't. Prolly the one delivered by staging.api
to identify itself? which seems ... weird. One would expect a server
providing certificate chains to remember to add its own link to its own
cert chain. Very absent minded to forget such a thing, like getting all
dressed up to go out for dinner, only to realize on arrival that one is
not wearing shoes. Not impossible, but rather unexpected. And with that
horribly strained analogy, I'm out for the night.
Amy!
Amelia A. Lewis amyzing {at} talsever.com
Love?
A joke, that. Love was the problem, not the solution. Being hit by a
car was better than love.
-- Steven Brust, PJF, "Cowboy Feng's Space Bar and Grille"
On Mon, 30 Dec 2024 22:54:52 -0500, Amelia A Lewis wrote:
[snip]
> lessee, delete an 'acme-' ...
>
> $ doas acme-client -vv simmonpatch.com
> acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
> key
> acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
> acme-client: https://staging.api.letsencrypt.org/directory: directories
> acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172
> acme-client: 172.65.46.172: tls_write: name
> `staging.api.letsencrypt.org' not present in server certificate
> acme-client: 172.65.46.172: tls_read: name
> `staging.api.letsencrypt.org' not present in server certificate
> acme-client: https://staging.api.letsencrypt.org/directory: bad comm
> acme-client: bad exit: netproc(18286): 1
>
[snip some more; i talk too much]
>
> Thanks for the quick reply and pointers! Have you any idea what the
> tls_write tls_read errors are? They're not triggering off pretend pear
> x1 and bogus broccoli x2 are they?
Call stack for the tls_read/tls_write bit:
netproc.c/nreq() -> http.c/http_get() -> http.c/http_alloc() \
-> http.c/dotlsread() -> http.c/tls_read()
-> http.c/dotlswrite() -> http.c/tls_write()
There are three calls of http_get() in netproc, one directly in nreq()
(most likely?, line 203), and two more in sreq(), which isn't called by
nreq() directly, but is called ten times by various dosomething()
functions, and it's too late for me to continue tracing (prolly easier
to instrument, but reading (somebody else's) code does make it easier
to sleep).
I'm not familiar enough with certificate contents and the protocol's
expectations of contents to decipher which server is supposed to have
staging.api in it and doesn't. Prolly the one delivered by staging.api
to identify itself? which seems ... weird. One would expect a server
providing certificate chains to remember to add its own link to its own
cert chain. Very absent minded to forget such a thing, like getting all
dressed up to go out for dinner, only to realize on arrival that one is
not wearing shoes. Not impossible, but rather unexpected. And with that
horribly strained analogy, I'm out for the night.
Amy!
Amelia A. Lewis amyzing {at} talsever.com
Love?
A joke, that. Love was the problem, not the solution. Being hit by a
car was better than love.
-- Steven Brust, PJF, "Cowboy Feng's Space Bar and Grille"
Re: acme-client challenges
Quick response, thank you!
On Tue, 31 Dec 2024 03:22:14 +0100, Kirill A. Korinsky wrote:
> On Tue, 31 Dec 2024 01:44:15 +0100,
> Amelia A Lewis <amyzing@talsever.com> wrote:
>>
>> $ doas acme-client -vvv simmonpatch.com
>> acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
>> acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
>> key
>> acme-client: https://acme-staging.api.letsencrypt.org/directory:
>> directories
>> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
>> comm
>> acme-client: bad exit: netproc(39958): 1
>>
>
> can you run host acme-staging.api.letsencrypt.org on the same machine?
$ host acme-staging.api.letsencrypt.org
Host acme-staging.api.letsencrypt.org not found: 3(NXDOMAIN)
Well, that seems dispositive.
$ dig acme-staging.api.letsencrypt.org
; <<>> dig 9.10.8-P1 <<>> acme-staging.api.letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46315
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;acme-staging.api.letsencrypt.org. IN A
;; AUTHORITY SECTION:
letsencrypt.org. 1784 IN SOA owen.ns.cloudflare.com.
dns.cloudflare.com. 2360987238 10000 2400 604800 1800
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 30 21:51:48 EST 2024
;; MSG SIZE rcvd: 123
Hmmmm. okay. That's a confirmation.
> I'm asking because as far as I understand the code at 3:20 am, the only case
> when you see 'bad comm' without additional errors / warnings is DNS related.
Ah. I went looking in netproc.c (after I sent the email; should've
looked first), and localized it to nfreq() < 0, but couldn't focus
enough after a day working to figure which of the return -1's in there
were the bad ones. Which reminds me: I owe the devs an apology (but
"comm" is unnecessarily cryptic; google keeps suggesting that I must
mean "bad community" and while I suspect it ought to mean "bad command"
or "bad communication channel" or something like that, I'm not certain:
"bad connection" [sic]?). But it is an acme-client bit, and it was rude
of me to snark on it. Teach me to check the code before asking
questions.
> I mean that acme-client can't resolve acme-staging.api.letsencrypt.org.
Seems so. Neither acme-staging nor acme.
$ host -t ns letsencrypt.org
letsencrypt.org name server owen.ns.cloudflare.com.
letsencrypt.org name server vera.ns.cloudflare.com.
acme.api.letsencrypt.org is also nxdomain.
host acme{,-staging}.api.letsencrypt.org vera.ns.cloudflare.com ditto.
Pretty much nx-ed. Lemme try a couple things. Same from other server in
colo (they're sharing the same lookup mechanism, not dispositive).
Okay, trying host acme.api.letsencrypt.org $nameserver and substituting
the IP address of a nameserver selected from a list of public resolving
servers in unbound.conf (an older copy has a longer list than new
installs) remains consistent. NXDOMAIN from everywhere I can start
from. Is there a problem at le.o? Just me? But if it's just me, then
directly querying 8.8.8.8 or similar from my home machine _should_
resolve, no? Not understanding how it can be filtered for both my home
machines checking public resolvers and for the servers in colo, but not
the rest of the world.
FWIW, letsencrypt.org responds positively, and I've been trying to
browse their docs since yesterday for something that looked like this
problem. But no one else has reported it? Or at least the available
hits for a search on 'acme-client "directories" "bad comm" -ai' turns
up nothing really pointing at dns (or else I missed it).
But wait! I found some curl commands on the net that someone offered
for debugging, which downloaded json from a staging server, on my
machine.
host acme-staging-v02.api.letsencrypt.org
acme-staging-v02.api.letsencrypt.org is an alias for
staging.api.letsencrypt.org.
staging.api.letsencrypt.org is an alias for
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com.
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has address
172.65.46.172
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has IPv6 address
2606:4700:60:0:f41b:d4fe:4325:6026
Ah, now *that's* encouraging.
$ host staging.api.letsencrypt.org
staging.api.letsencrypt.org is an alias for
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com.
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has address
172.65.46.172
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has IPv6 address
2606:4700:60:0:f41b:d4fe:4325:6026
lessee, delete an 'acme-' ...
$ doas acme-client -vv simmonpatch.com
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: https://staging.api.letsencrypt.org/directory: directories
acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172
acme-client: 172.65.46.172: tls_write: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: 172.65.46.172: tls_read: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: https://staging.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(18286): 1
Progress? At least a different result, if not quite what I hoped for.
Apparently the main url may have changed as well? Because there's this:
$ host acme-v02.api.letsencrypt.org
acme-v02.api.letsencrypt.org is an alias for prod.api.letsencrypt.org.
prod.api.letsencrypt.org is an alias for
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has address
172.65.32.248
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has IPv6 address
2606:4700:60:0:f53d:5624:85c7:3a2c
Or I've triggered their famous throttling? But that ought to be per
requesting privkey (or since those can be deleted, per requesting IP).
I don't want to test against production; that's what staging is for.
It's true that the current production url on
letencrypt.org/getting-started is acme-v02.api.letsencrypt.org, though,
so at least that should prolly be updated in acme-client? And at a
guess, they've made a change to all of those URLs? And it's possible
that acme-client is running against the v1 protocol instead of v2? Have
they shut it down? acme-v01 (as found in /etc/examples and /etc) is
also NXDOMAIN, for me.
Thanks for the quick reply and pointers! Have you any idea what the
tls_write tls_read errors are? They're not triggering off pretend pear
x1 and bogus broccoli x2 are they?
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
Merchant, street girl, beggar, yeoman,
king or common, man or woman,
only two things make us human--
sorrow and love, sorrow and love ....
-- The Last Song of Sirit Byar
On Tue, 31 Dec 2024 03:22:14 +0100, Kirill A. Korinsky wrote:
> On Tue, 31 Dec 2024 01:44:15 +0100,
> Amelia A Lewis <amyzing@talsever.com> wrote:
>>
>> $ doas acme-client -vvv simmonpatch.com
>> acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
>> acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
>> key
>> acme-client: https://acme-staging.api.letsencrypt.org/directory:
>> directories
>> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
>> comm
>> acme-client: bad exit: netproc(39958): 1
>>
>
> can you run host acme-staging.api.letsencrypt.org on the same machine?
$ host acme-staging.api.letsencrypt.org
Host acme-staging.api.letsencrypt.org not found: 3(NXDOMAIN)
Well, that seems dispositive.
$ dig acme-staging.api.letsencrypt.org
; <<>> dig 9.10.8-P1 <<>> acme-staging.api.letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46315
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;acme-staging.api.letsencrypt.org. IN A
;; AUTHORITY SECTION:
letsencrypt.org. 1784 IN SOA owen.ns.cloudflare.com.
dns.cloudflare.com. 2360987238 10000 2400 604800 1800
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 30 21:51:48 EST 2024
;; MSG SIZE rcvd: 123
Hmmmm. okay. That's a confirmation.
> I'm asking because as far as I understand the code at 3:20 am, the only case
> when you see 'bad comm' without additional errors / warnings is DNS related.
Ah. I went looking in netproc.c (after I sent the email; should've
looked first), and localized it to nfreq() < 0, but couldn't focus
enough after a day working to figure which of the return -1's in there
were the bad ones. Which reminds me: I owe the devs an apology (but
"comm" is unnecessarily cryptic; google keeps suggesting that I must
mean "bad community" and while I suspect it ought to mean "bad command"
or "bad communication channel" or something like that, I'm not certain:
"bad connection" [sic]?). But it is an acme-client bit, and it was rude
of me to snark on it. Teach me to check the code before asking
questions.
> I mean that acme-client can't resolve acme-staging.api.letsencrypt.org.
Seems so. Neither acme-staging nor acme.
$ host -t ns letsencrypt.org
letsencrypt.org name server owen.ns.cloudflare.com.
letsencrypt.org name server vera.ns.cloudflare.com.
acme.api.letsencrypt.org is also nxdomain.
host acme{,-staging}.api.letsencrypt.org vera.ns.cloudflare.com ditto.
Pretty much nx-ed. Lemme try a couple things. Same from other server in
colo (they're sharing the same lookup mechanism, not dispositive).
Okay, trying host acme.api.letsencrypt.org $nameserver and substituting
the IP address of a nameserver selected from a list of public resolving
servers in unbound.conf (an older copy has a longer list than new
installs) remains consistent. NXDOMAIN from everywhere I can start
from. Is there a problem at le.o? Just me? But if it's just me, then
directly querying 8.8.8.8 or similar from my home machine _should_
resolve, no? Not understanding how it can be filtered for both my home
machines checking public resolvers and for the servers in colo, but not
the rest of the world.
FWIW, letsencrypt.org responds positively, and I've been trying to
browse their docs since yesterday for something that looked like this
problem. But no one else has reported it? Or at least the available
hits for a search on 'acme-client "directories" "bad comm" -ai' turns
up nothing really pointing at dns (or else I missed it).
But wait! I found some curl commands on the net that someone offered
for debugging, which downloaded json from a staging server, on my
machine.
host acme-staging-v02.api.letsencrypt.org
acme-staging-v02.api.letsencrypt.org is an alias for
staging.api.letsencrypt.org.
staging.api.letsencrypt.org is an alias for
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com.
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has address
172.65.46.172
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has IPv6 address
2606:4700:60:0:f41b:d4fe:4325:6026
Ah, now *that's* encouraging.
$ host staging.api.letsencrypt.org
staging.api.letsencrypt.org is an alias for
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com.
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has address
172.65.46.172
56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com has IPv6 address
2606:4700:60:0:f41b:d4fe:4325:6026
lessee, delete an 'acme-' ...
$ doas acme-client -vv simmonpatch.com
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: https://staging.api.letsencrypt.org/directory: directories
acme-client: staging.api.letsencrypt.org: DNS: 172.65.46.172
acme-client: 172.65.46.172: tls_write: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: 172.65.46.172: tls_read: name
`staging.api.letsencrypt.org' not present in server certificate
acme-client: https://staging.api.letsencrypt.org/directory: bad comm
acme-client: bad exit: netproc(18286): 1
Progress? At least a different result, if not quite what I hoped for.
Apparently the main url may have changed as well? Because there's this:
$ host acme-v02.api.letsencrypt.org
acme-v02.api.letsencrypt.org is an alias for prod.api.letsencrypt.org.
prod.api.letsencrypt.org is an alias for
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has address
172.65.32.248
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com has IPv6 address
2606:4700:60:0:f53d:5624:85c7:3a2c
Or I've triggered their famous throttling? But that ought to be per
requesting privkey (or since those can be deleted, per requesting IP).
I don't want to test against production; that's what staging is for.
It's true that the current production url on
letencrypt.org/getting-started is acme-v02.api.letsencrypt.org, though,
so at least that should prolly be updated in acme-client? And at a
guess, they've made a change to all of those URLs? And it's possible
that acme-client is running against the v1 protocol instead of v2? Have
they shut it down? acme-v01 (as found in /etc/examples and /etc) is
also NXDOMAIN, for me.
Thanks for the quick reply and pointers! Have you any idea what the
tls_write tls_read errors are? They're not triggering off pretend pear
x1 and bogus broccoli x2 are they?
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
Merchant, street girl, beggar, yeoman,
king or common, man or woman,
only two things make us human--
sorrow and love, sorrow and love ....
-- The Last Song of Sirit Byar
Re: remote ssh login fail "Authenticator provider $SSH_SK_PROVIDER did not resolve" (macOS)
Thus said Sylvain Saboua on Sat, 28 Dec 2024 07:07:18 +0100:
> debug1: Connecting to saboua.xyz port 22.
> ssh: connect to host saboua.xyz port 22: Operation timed out
Have you observed with tcpdump what traffic is flowing?
Also, there was a recent discussion about SSH and Mac OS which may be of
interest, though not likely the same cause since you're hitting
timeouts:
https://marc.info/?t=173420235600002&r=1&w=2
Andy
> debug1: Connecting to saboua.xyz port 22.
> ssh: connect to host saboua.xyz port 22: Operation timed out
Have you observed with tcpdump what traffic is flowing?
Also, there was a recent discussion about SSH and Mac OS which may be of
interest, though not likely the same cause since you're hitting
timeouts:
https://marc.info/?t=173420235600002&r=1&w=2
Andy
Re: acme-client challenges
On Tue, 31 Dec 2024 01:44:15 +0100,
Amelia A Lewis <amyzing@talsever.com> wrote:
>
> $ doas acme-client -vvv simmonpatch.com
> acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
> acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
> key
> acme-client: https://acme-staging.api.letsencrypt.org/directory:
> directories
> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
> comm
> acme-client: bad exit: netproc(39958): 1
>
can you run host acme-staging.api.letsencrypt.org on the same machine?
I'm asking because as far as I understand the code at 3:20 am, the only case
when you see 'bad comm' without additional errors / warnings is DNS related.
I mean that acme-client can't resolve acme-staging.api.letsencrypt.org.
--
wbr, Kirill
Amelia A Lewis <amyzing@talsever.com> wrote:
>
> $ doas acme-client -vvv simmonpatch.com
> acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
> acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
> key
> acme-client: https://acme-staging.api.letsencrypt.org/directory:
> directories
> acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
> comm
> acme-client: bad exit: netproc(39958): 1
>
can you run host acme-staging.api.letsencrypt.org on the same machine?
I'm asking because as far as I understand the code at 3:20 am, the only case
when you see 'bad comm' without additional errors / warnings is DNS related.
I mean that acme-client can't resolve acme-staging.api.letsencrypt.org.
--
wbr, Kirill
acme-client challenges
Hey, misclings,
I'm standing up a new domain on a server that's been deployed for a
while. Big thanks to Gilles Chehade for his guide (
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
), as well as for smtpd. As part of this, I'm finally trying to adopt
TLS everywhere. So I have everything that I need running using
self-signed certs (it's a vanity domain, so all the users can be relied
upon to accept self-signed certs), but that's increasingly less
acceptable.
Short form: with httpd working, contents of /var/www/acme reachable
(but not the empty dir) (as-installed perms on everything in /var/www),
stock configuration (and reduced forms of it to simplify), A records
pointing to simmonpatch.com and tserig.simmonpatch.com (the main and
one alternative used in minimal test), default/simplified configuration
of /etc/acme-client.conf and /etc/httpd.conf, using the let's encrypt
staging server, I get this:
$ doas acme-client -vvv simmonpatch.com
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: https://acme-staging.api.letsencrypt.org/directory:
directories
acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
comm
acme-client: bad exit: netproc(39958): 1
This is a later run; in earlier runs I removed keys after every
failure, until I realized that keys (and their names) are cheap. But
this is the same error seen before, multiple times. The extra v (which
has no effect) was there to see if maybe that would help. I can't find
any logs, and there don't seem to be any other switches/knobs to turn
up verbosity more. As it is, it's rather cryptic. 'directories' may be
an error, or just informational (like the two key loading lines, which
are not errors). 'bad comm' is bad error messaging (not from
acme-client, I think, but from the staging server, which is reporting
what it got).
I'm hoping someone is going to point out something that will make me
feel stupid, but that I can't see until it's pointed out.
Minimal httpd.conf and acme-client.conf:
server "simmonpatch.com" {
listen on * port 80
alias "www.simmonpatch.com"
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI"
}
}
(tested with an index.html in /var/www/acme: it's reachable with only
this, though 403 for /.well-known/acme-challenge/, which is probably
the point, so I made sure it was empty when invoking acme-client)
authority letsencrypt-staging {
api url "https://acme-staging.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
domain simmonpatch.com {
alternative names { tserig.simmonpatch.com,
mail.simmonpatch.com, www.simmonpatch.com }
domain key "/etc/ssl/private/leo-simmonpatch.com.key"
domain certificate "/etc/ssl/leo-simmonpatch.com.crt"
domain full chain certificate
"/etc/ssl/leo-simmonpatch.com.fullchain.pem"
sign with letsencrypt-staging
}
(everything else got removed to test; yay /etc/examples!)
No AAAA records (not available from hosting provider), no DNSSEC (I
could do that, but it's said to be not required and to sometimes cause
problems). httpd works with the tls bloc installed pointing at my
self-signed cert. I got a different error once when the request used
the same key+cert name as self-signed.
Also (double-checking logs): there is no attempted connection from
anyone except me (my ip address) trying the acme-challenge url.
Presumably, then, let's encrypt fails before that?
Thanks for reading this far, at least. :-)
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
It's odd that people think of programming as precise and methodical.
*Computers* are precise and methodical.
Hacking is something you do with a gleeful laugh.
-- Paul Graham, "The Word 'Hacker'"
I'm standing up a new domain on a server that's been deployed for a
while. Big thanks to Gilles Chehade for his guide (
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
), as well as for smtpd. As part of this, I'm finally trying to adopt
TLS everywhere. So I have everything that I need running using
self-signed certs (it's a vanity domain, so all the users can be relied
upon to accept self-signed certs), but that's increasingly less
acceptable.
Short form: with httpd working, contents of /var/www/acme reachable
(but not the empty dir) (as-installed perms on everything in /var/www),
stock configuration (and reduced forms of it to simplify), A records
pointing to simmonpatch.com and tserig.simmonpatch.com (the main and
one alternative used in minimal test), default/simplified configuration
of /etc/acme-client.conf and /etc/httpd.conf, using the let's encrypt
staging server, I get this:
$ doas acme-client -vvv simmonpatch.com
acme-client: /etc/ssl/private/leo-simmonpatch.com.key: loaded domain key
acme-client: /etc/acme/letsencrypt-staging-privkey.pem: loaded account
key
acme-client: https://acme-staging.api.letsencrypt.org/directory:
directories
acme-client: https://acme-staging.api.letsencrypt.org/directory: bad
comm
acme-client: bad exit: netproc(39958): 1
This is a later run; in earlier runs I removed keys after every
failure, until I realized that keys (and their names) are cheap. But
this is the same error seen before, multiple times. The extra v (which
has no effect) was there to see if maybe that would help. I can't find
any logs, and there don't seem to be any other switches/knobs to turn
up verbosity more. As it is, it's rather cryptic. 'directories' may be
an error, or just informational (like the two key loading lines, which
are not errors). 'bad comm' is bad error messaging (not from
acme-client, I think, but from the staging server, which is reporting
what it got).
I'm hoping someone is going to point out something that will make me
feel stupid, but that I can't see until it's pointed out.
Minimal httpd.conf and acme-client.conf:
server "simmonpatch.com" {
listen on * port 80
alias "www.simmonpatch.com"
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI"
}
}
(tested with an index.html in /var/www/acme: it's reachable with only
this, though 403 for /.well-known/acme-challenge/, which is probably
the point, so I made sure it was empty when invoking acme-client)
authority letsencrypt-staging {
api url "https://acme-staging.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
domain simmonpatch.com {
alternative names { tserig.simmonpatch.com,
mail.simmonpatch.com, www.simmonpatch.com }
domain key "/etc/ssl/private/leo-simmonpatch.com.key"
domain certificate "/etc/ssl/leo-simmonpatch.com.crt"
domain full chain certificate
"/etc/ssl/leo-simmonpatch.com.fullchain.pem"
sign with letsencrypt-staging
}
(everything else got removed to test; yay /etc/examples!)
No AAAA records (not available from hosting provider), no DNSSEC (I
could do that, but it's said to be not required and to sometimes cause
problems). httpd works with the tls bloc installed pointing at my
self-signed cert. I got a different error once when the request used
the same key+cert name as self-signed.
Also (double-checking logs): there is no attempted connection from
anyone except me (my ip address) trying the acme-challenge url.
Presumably, then, let's encrypt fails before that?
Thanks for reading this far, at least. :-)
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
It's odd that people think of programming as precise and methodical.
*Computers* are precise and methodical.
Hacking is something you do with a gleeful laugh.
-- Paul Graham, "The Word 'Hacker'"
new security/pkcs11-helper, net/openvpn: enable PKCS#11
OpenVPN can use smart cards instead of --key/cert which works great for me
via --pkcs11-id '...' with values from 'openvpn --show-pkcs11-ids | grep id:'
on the client and no further config; the server needs no changes.
See openvpn(8) "PKCS#11 / SmartCard options" for more.
New dependency:
Information for inst:pkcs11-helper-1.30.0
Comment:
library with PKCS
Required by:
openvpn-2.6.12p0
Description:
pkcs11-helper allows using multiple PKCS#11 providers at the same
time, enumerating available token certificates, or selecting a
certificate directly by serialized id, handling card removal and
card insert events, handling card re-insert to a different
slot, supporting session expiration and much more all using a
simple API.
pkcs11-helper is not designed to manage card content, since object
attributes are usually vendor specific, and 99% of application need
to access existing objects in order to perform signature and
decryption.
Maintainer: Klemens Nanni <kn@openbsd.org>
WWW: https://github.com/OpenSC/pkcs11-helper
It can use different TLS implementations - I explictly enabled LibreSSL
alone and left OpenVPN's FLAVOR=mbedtls unchanged as I don't use that.
Feedback? OK?
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/openvpn/Makefile,v
diff -u -p -r1.130 Makefile
--- Makefile 21 Dec 2024 11:38:33 -0000 1.130
+++ Makefile 30 Dec 2024 23:16:33 -0000
@@ -26,6 +26,8 @@ CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/
LDFLAGS="-L${LOCALBASE}/lib ${LDFLAGS}"
CONFIGURE_ARGS+=--with-openssl-engine=no
+SEPARATE_BUILD= Yes
+
DEBUG_PACKAGES= ${BUILD_PACKAGES}
FLAVORS= mbedtls
@@ -36,7 +38,14 @@ LIB_DEPENDS+= security/polarssl
CONFIGURE_ARGS+= --with-crypto-library=mbedtls
WANTLIB += mbedcrypto mbedtls mbedx509 pthread
.else
-WANTLIB += crypto ssl
+REVISION= 0
+LIB_DEPENDS+= security/pkcs11-helper
+# dlopen()s p11-kit-proxy.so
+BUILD_DEPENDS+= security/p11-kit
+RUN_DEPENDS+= security/p11-kit
+CONFIGURE_ARGS+= --enable-pkcs11
+WANTLIB += pthread pkcs11-helper
+WANTLIB += crypto ssl pkcs11-helper
.endif
SAMPLES_DIR= ${PREFIX}/share/examples/openvpn
via --pkcs11-id '...' with values from 'openvpn --show-pkcs11-ids | grep id:'
on the client and no further config; the server needs no changes.
See openvpn(8) "PKCS#11 / SmartCard options" for more.
New dependency:
Information for inst:pkcs11-helper-1.30.0
Comment:
library with PKCS
Required by:
openvpn-2.6.12p0
Description:
pkcs11-helper allows using multiple PKCS#11 providers at the same
time, enumerating available token certificates, or selecting a
certificate directly by serialized id, handling card removal and
card insert events, handling card re-insert to a different
slot, supporting session expiration and much more all using a
simple API.
pkcs11-helper is not designed to manage card content, since object
attributes are usually vendor specific, and 99% of application need
to access existing objects in order to perform signature and
decryption.
Maintainer: Klemens Nanni <kn@openbsd.org>
WWW: https://github.com/OpenSC/pkcs11-helper
It can use different TLS implementations - I explictly enabled LibreSSL
alone and left OpenVPN's FLAVOR=mbedtls unchanged as I don't use that.
Feedback? OK?
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/openvpn/Makefile,v
diff -u -p -r1.130 Makefile
--- Makefile 21 Dec 2024 11:38:33 -0000 1.130
+++ Makefile 30 Dec 2024 23:16:33 -0000
@@ -26,6 +26,8 @@ CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/
LDFLAGS="-L${LOCALBASE}/lib ${LDFLAGS}"
CONFIGURE_ARGS+=--with-openssl-engine=no
+SEPARATE_BUILD= Yes
+
DEBUG_PACKAGES= ${BUILD_PACKAGES}
FLAVORS= mbedtls
@@ -36,7 +38,14 @@ LIB_DEPENDS+= security/polarssl
CONFIGURE_ARGS+= --with-crypto-library=mbedtls
WANTLIB += mbedcrypto mbedtls mbedx509 pthread
.else
-WANTLIB += crypto ssl
+REVISION= 0
+LIB_DEPENDS+= security/pkcs11-helper
+# dlopen()s p11-kit-proxy.so
+BUILD_DEPENDS+= security/p11-kit
+RUN_DEPENDS+= security/p11-kit
+CONFIGURE_ARGS+= --enable-pkcs11
+WANTLIB += pthread pkcs11-helper
+WANTLIB += crypto ssl pkcs11-helper
.endif
SAMPLES_DIR= ${PREFIX}/share/examples/openvpn
devel/automake: import automake-1.17
ports@,
I just noticed that automake-1.17 was released about 6 months ago.
I'd like to import it.
Announce and changes:
https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html
I had tested it with some random ports which uses automake, and haven't find
any regression.
Anyway, to avoid 'First argument to cross-reference may not be empty' I was
forced to add some referces. I used "Top" (see patch-doc_automake_texi), but
I don't like it, and I'm looking for any suggestion for better way.
Feedback? Tests? Ok?
Index: devel/automake/Makefile
===================================================================
RCS file: /home/cvs/ports/devel/automake/Makefile,v
diff -u -p -u -p -r1.39 Makefile
--- devel/automake/Makefile 11 Mar 2022 18:49:41 -0000 1.39
+++ devel/automake/Makefile 30 Dec 2024 23:14:52 -0000
@@ -9,5 +9,6 @@ SUBDIR += 1.13
SUBDIR += 1.14
SUBDIR += 1.15
SUBDIR += 1.16
+SUBDIR += 1.17
.include <bsd.port.subdir.mk>
--
wbr, Kirill
I just noticed that automake-1.17 was released about 6 months ago.
I'd like to import it.
Announce and changes:
https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html
I had tested it with some random ports which uses automake, and haven't find
any regression.
Anyway, to avoid 'First argument to cross-reference may not be empty' I was
forced to add some referces. I used "Top" (see patch-doc_automake_texi), but
I don't like it, and I'm looking for any suggestion for better way.
Feedback? Tests? Ok?
Index: devel/automake/Makefile
===================================================================
RCS file: /home/cvs/ports/devel/automake/Makefile,v
diff -u -p -u -p -r1.39 Makefile
--- devel/automake/Makefile 11 Mar 2022 18:49:41 -0000 1.39
+++ devel/automake/Makefile 30 Dec 2024 23:14:52 -0000
@@ -9,5 +9,6 @@ SUBDIR += 1.13
SUBDIR += 1.14
SUBDIR += 1.15
SUBDIR += 1.16
+SUBDIR += 1.17
.include <bsd.port.subdir.mk>
--
wbr, Kirill
Re: Zeek on OpenBSD: clustering issue and dropping privileges
On December 30, 2024 5:39:52 PM GMT+01:00, "Jörgen Maas" <jorgen.maas@gmail.com> wrote:
>Hi there,
>
>I've been trying to get Zeek to work in a very simple cluster setup; the
>problem is that my workers are not able to grab any data and create the
>expected log files. The cluster config is a single node (localhost) and
>monitoring of two interfaces, basically what's in the default node.cfg
>(manager, proxy, logger, 2 x worker). All processes start, and are
>listening on localhost for incoming connections. Testing the connectivity
>with telnet to these ports gets me to a full connection. Nothing is logged
>in stderr.log, i'm a bit puzzled :S
>
>In standalone mode running against a single interface Zeek is working fine.
>
>I'm running PF but have the "set skip lo0" set in /etc/pf.conf.
>Zeek 6.0.5 is from packages on OpenBSD 7.6 / amd64
>This used to work fine for me "earlier" (older OpenBSD and older version of
>the pkg).
>
>Is anyone out there running this version of Zeek in a cluster setup
>successfully?
>
>Another question is that it seems there's an option to drop privileges but
>this is not provided "out of the box" by the pkg. Has this ever been
>explored yet?
>
>Thanks in advance!
>
>Kind regards,
>Jörgen
Hi.
It's a known issue, reported multiple times.
I've looked a few times but wasn't able to find the culprit... :-/
I also tried updating to a newer release but failed. We are lacking stuff available in other OSes.
If one can find the issue I will put the time into bringing the port up to date.
--
Antoine
>Hi there,
>
>I've been trying to get Zeek to work in a very simple cluster setup; the
>problem is that my workers are not able to grab any data and create the
>expected log files. The cluster config is a single node (localhost) and
>monitoring of two interfaces, basically what's in the default node.cfg
>(manager, proxy, logger, 2 x worker). All processes start, and are
>listening on localhost for incoming connections. Testing the connectivity
>with telnet to these ports gets me to a full connection. Nothing is logged
>in stderr.log, i'm a bit puzzled :S
>
>In standalone mode running against a single interface Zeek is working fine.
>
>I'm running PF but have the "set skip lo0" set in /etc/pf.conf.
>Zeek 6.0.5 is from packages on OpenBSD 7.6 / amd64
>This used to work fine for me "earlier" (older OpenBSD and older version of
>the pkg).
>
>Is anyone out there running this version of Zeek in a cluster setup
>successfully?
>
>Another question is that it seems there's an option to drop privileges but
>this is not provided "out of the box" by the pkg. Has this ever been
>explored yet?
>
>Thanks in advance!
>
>Kind regards,
>Jörgen
Hi.
It's a known issue, reported multiple times.
I've looked a few times but wasn't able to find the culprit... :-/
I also tried updating to a newer release but failed. We are lacking stuff available in other OSes.
If one can find the issue I will put the time into bringing the port up to date.
--
Antoine
Re: update x11/dunst-1.12.1
On Mon, Dec 30 2024, Stuart Henderson wrote:
> On 2024/12/30 10:12, Timo Myyrä wrote:
>> # dmenu path.
>> - dmenu = /usr/bin/dmenu -p dunst:
>> -+ dmenu = ${LOCALBASE}/bin/dmenu -p dunst:
>> ++ dmenu = ${PREFIX}/bin/dmenu -p dunst:
>>
>> # Browser for opening urls in context menu.
>> - browser = /usr/bin/xdg-open
>> -+ browser = ${LOCALBASE}/bin/xdg-open
>> ++ browser = ${PREFIX}/bin/xdg-open
>
> PREFIX is "comes from this port", those come from other ports
> so LOCALBASE was already correct.
>
>> share/dunst/
>> -@sample ${SYSCONFDIR}/dunst/
>> share/dunst/dunstrc
>> -@sample ${SYSCONFDIR}/dunst/dunstrc
>
> why remove those @samples?
>
>> +share/examples/bash-completion/
>> +share/examples/bash-completion/completions/
>> +share/examples/bash-completion/completions/dunst
>> +share/examples/bash-completion/completions/dunstctl
>> share/examples/dbus-1/
>> share/examples/dbus-1/services/
>> share/examples/dbus-1/services/org.knopwob.dunst.service
>> +share/examples/fish/
>> +share/examples/fish/vendor_completions.d/
>> +share/examples/fish/vendor_completions.d/dunst.fish
>> +share/examples/fish/vendor_completions.d/dunstctl.fish
>> +share/examples/fish/vendor_completions.d/dunstify.fish
>> +share/examples/zsh/
>> +share/examples/zsh/site-functions/
>> +share/examples/zsh/site-functions/_dunst
>> +share/examples/zsh/site-functions/_dunstctl
>
> the completion scripts should go to share/bash-completion,
> share/fish/vendor_completions.d, share/zsh/site-functions rather
> than under share/examples
Good points, here's an updated diff.
timo
diff /usr/ports
commit - 249cdbc13b64ccbf1b0f4c92f4775e302caa0a15
path + /usr/ports
blob - eac7443cb23f53d564d0d50c9e3a4c894a1fda82
file + x11/dunst/Makefile
--- x11/dunst/Makefile
+++ x11/dunst/Makefile
@@ -2,8 +2,7 @@ COMMENT = customizable and lightweight notification-da
GH_ACCOUNT = dunst-project
GH_PROJECT = dunst
-GH_TAGNAME = v1.9.2
-REVISION = 0
+GH_TAGNAME = v1.12.1
CATEGORIES = x11
@@ -44,7 +43,10 @@ MAKE_FLAGS = WAYLAND=0
FAKE_FLAGS = PREFIX="${PREFIX}" \
MANPREFIX="${PREFIX}/man" \
DATADIR="${PREFIX}/share/examples" \
- SYSCONFDIR="/etc"
+ SYSCONFDIR="/etc" \
+ BASHCOMPLETIONDIR="${LOCALBASE}/share/bash-completion" \
+ FISHCOMPLETIONDIR="${LOCALBASE}/share/fish/vendor_completions.d" \
+ ZSHCOMPLETIONDIR="${LOCALBASE}/share/zsh/site-functions"
pre-configure:
${SUBST_CMD} ${WRKSRC}/docs/dunst.1.pod \
blob - 093bbc84211d476e0f7fa34991e242f0a06f73da
file + x11/dunst/distinfo
--- x11/dunst/distinfo
+++ x11/dunst/distinfo
@@ -1,2 +1,2 @@
-SHA256 (dunst-1.9.2.tar.gz) = +mzkXAr0uuGIsNZ5pbqS+Pm35DAbsbtHboLfJrzp5xo=
-SIZE (dunst-1.9.2.tar.gz) = 4614703
+SHA256 (dunst-1.12.1.tar.gz) = NAsQw47lGadbFAQPZVBdcoF4VzWM56b+IxkKtoeC+JI=
+SIZE (dunst-1.12.1.tar.gz) = 4654978
blob - 958ea4261737f9be45def56356d55fbd23c4dccb
file + x11/dunst/patches/patch-config_mk
--- x11/dunst/patches/patch-config_mk
+++ x11/dunst/patches/patch-config_mk
@@ -1,13 +1,13 @@
Index: config.mk
--- config.mk.orig
+++ config.mk
-@@ -42,8 +42,8 @@ endif
+@@ -52,8 +52,8 @@ endif
# flags
- DEFAULT_CPPFLAGS = -Wno-gnu-zero-variadic-macro-arguments -D_DEFAULT_SOURCE -DVERSION=\"${VERSION}\" -DSYSCONFDIR=\"${SYSCONFDIR}\"
--DEFAULT_CFLAGS = -g -std=gnu99 -pedantic -Wall -Wno-overlength-strings -Os ${ENABLE_WAYLAND} ${EXTRA_CFLAGS}
+ DEFAULT_CPPFLAGS = -Wno-gnu-zero-variadic-macro-arguments -D_DEFAULT_SOURCE -DVERSION=\"${VERSION}\" -DSYSCONFDIR=\"${SYSCONFDIR}\" ${ENABLE_WAYLAND} ${ENABLE_X11}
+-DEFAULT_CFLAGS = -g -std=gnu11 -pedantic -Wall -Wno-overlength-strings -Os ${EXTRA_CFLAGS}
-DEFAULT_LDFLAGS = -lm -lrt
-+DEFAULT_CFLAGS = -g -std=gnu99 -pedantic -Wall -Wno-overlength-strings ${ENABLE_WAYLAND} ${EXTRA_CFLAGS}
++DEFAULT_CFLAGS = -g -std=gnu11 -pedantic -Wall -Wno-overlength-strings ${EXTRA_CFLAGS}
+DEFAULT_LDFLAGS = -lm
CPPFLAGS_DEBUG := -DDEBUG_BUILD
blob - e6662fa63eda43c029f8bf0b8060abd06724b7e1
file + x11/dunst/patches/patch-docs_dunst_1_pod
--- x11/dunst/patches/patch-docs_dunst_1_pod
+++ x11/dunst/patches/patch-docs_dunst_1_pod
@@ -1,12 +1,12 @@
Index: docs/dunst.1.pod
--- docs/dunst.1.pod.orig
+++ docs/dunst.1.pod
-@@ -61,7 +61,7 @@ Display a notification on startup.
+@@ -94,7 +94,7 @@ Set notification timeout time.
A default configuration file is included (usually ##SYSCONFDIR##/dunst/dunstrc)
and serves as the least important configuration file. Note: this was previously
-/usr/share/dunst/dunstrc. You can edit this file to change the system-wide
-+${PREFIX}/share/dunst/dunstrc. You can edit this file to change the system-wide
++${LOCALBASE}/share/dunst/dunstrc. You can edit this file to change the system-wide
defaults or copy it to a more important location to override its settings. See
the FILES section for more details on where dunst searches for its
configuration files and how settings get applied.
blob - 76eb300d292dd84ed65eb1f6f5a8a1deb9d9a797
file + x11/dunst/patches/patch-docs_dunst_5_pod
--- x11/dunst/patches/patch-docs_dunst_5_pod
+++ x11/dunst/patches/patch-docs_dunst_5_pod
@@ -1,25 +1,25 @@
Index: docs/dunst.5.pod
--- docs/dunst.5.pod.orig
+++ docs/dunst.5.pod
-@@ -409,7 +409,7 @@ Hide the count of stacked duplicate notifications.
+@@ -463,7 +463,7 @@ Hide the count of stacked duplicate notifications.
Show an indicator if a notification contains actions and/or open-able URLs. See
ACTIONS below for further details.
-=item B<icon_path> (default: "/usr/share/icons/gnome/16x16/status/:/usr/share/icons/gnome/16x16/devices/")
-+=item B<icon_path> (default: "${PREFIX}/share/icons/gnome/16x16/status/:${PREFIX}/share/icons/gnome/16x16/devices/")
++=item B<icon_path> (default: "${LOCALBASE}/share/icons/gnome/16x16/status/:${LOCALBASE}/share/icons/gnome/16x16/devices/")
Can be set to a colon-separated list of paths to search for icons to use with
notifications.
-@@ -423,7 +423,7 @@ replace this and will need new settings.
- Comma-separated of names of the the themes to use for looking up icons. This has
- to be the name of the directory in which the theme is located, not the
+@@ -477,7 +477,7 @@ replace icon_path search.
+ Comma-separated list of names of the themes to use for looking up icons. This
+ has to be the name of the directory in which the theme is located, not the
human-friendly name of the theme. So for example, the theme B<Breeze Dark> is
-located in F</usr/share/icons/breeze-dark>. In this case you have to set the
-+located in F<${PREFIX}/share/icons/breeze-dark>. In this case you have to set the
++located in F<${LOCALBASE}/share/icons/breeze-dark>. In this case you have to set the
theme to B<breeze-dark>.
The first theme in the list is the most important. Only if the icon cannot be
-@@ -461,12 +461,12 @@ Maximum number of notifications that will be kept in h
+@@ -515,12 +515,12 @@ Maximum number of notifications that will be kept in h
is reached, older notifications will be deleted once a new one arrives. See
HISTORY.
blob - fed4e50ecba2ae7b194f97a5556806372857a133
file + x11/dunst/patches/patch-dunstrc
--- x11/dunst/patches/patch-dunstrc
+++ x11/dunst/patches/patch-dunstrc
@@ -1,16 +1,16 @@
Index: dunstrc
--- dunstrc.orig
+++ dunstrc
-@@ -217,7 +217,7 @@
+@@ -238,7 +238,7 @@
max_icon_size = 128
- # Paths to default icons (only neccesary when not using recursive icon lookup)
+ # Paths to default icons (only necessary when not using recursive icon lookup)
- icon_path = /usr/share/icons/gnome/16x16/status/:/usr/share/icons/gnome/16x16/devices/
+ icon_path = ${LOCALBASE}/share/icons/gnome/16x16/status/:${LOCALBASE}/share/icons/gnome/16x16/devices/
### History ###
-@@ -231,10 +231,10 @@
+@@ -252,10 +252,10 @@
### Misc/Advanced ###
# dmenu path.
blob - cba0c845fee96e3f439ac82f300a16f0427e3bb9
file + x11/dunst/patches/patch-src_dunst_c
--- x11/dunst/patches/patch-src_dunst_c
+++ x11/dunst/patches/patch-src_dunst_c
@@ -1,12 +1,12 @@
Index: src/dunst.c
--- src/dunst.c.orig
+++ src/dunst.c
-@@ -100,7 +100,7 @@ static gboolean run(void *data)
+@@ -164,7 +164,7 @@ static gboolean run(void *data)
gint64 sleep = timeout_at - now;
sleep = MAX(sleep, 1000); // Sleep at least 1ms
- LOG_D("Sleeping for %li ms", sleep/1000);
+ LOG_D("Sleeping for %lli ms", (long long)sleep/1000);
- if (sleep >= 0) {
- if (reason == 0 || next_timeout < now || timeout_at < next_timeout) {
+ next_timeout_id = g_timeout_add(sleep/1000, run, NULL);
+ }
blob - f49421b7619b5443f71067d2824793187f223852
file + /dev/null
--- x11/dunst/patches/patch-src_input_c
+++ /dev/null
@@ -1,13 +0,0 @@
-Index: src/input.c
---- src/input.c.orig
-+++ src/input.c
-@@ -4,7 +4,9 @@
- #include "settings.h"
- #include "queues.h"
- #include <stddef.h>
-+#ifdef __linux__
- #include <linux/input-event-codes.h>
-+
> On 2024/12/30 10:12, Timo Myyrä wrote:
>> # dmenu path.
>> - dmenu = /usr/bin/dmenu -p dunst:
>> -+ dmenu = ${LOCALBASE}/bin/dmenu -p dunst:
>> ++ dmenu = ${PREFIX}/bin/dmenu -p dunst:
>>
>> # Browser for opening urls in context menu.
>> - browser = /usr/bin/xdg-open
>> -+ browser = ${LOCALBASE}/bin/xdg-open
>> ++ browser = ${PREFIX}/bin/xdg-open
>
> PREFIX is "comes from this port", those come from other ports
> so LOCALBASE was already correct.
>
>> share/dunst/
>> -@sample ${SYSCONFDIR}/dunst/
>> share/dunst/dunstrc
>> -@sample ${SYSCONFDIR}/dunst/dunstrc
>
> why remove those @samples?
>
>> +share/examples/bash-completion/
>> +share/examples/bash-completion/completions/
>> +share/examples/bash-completion/completions/dunst
>> +share/examples/bash-completion/completions/dunstctl
>> share/examples/dbus-1/
>> share/examples/dbus-1/services/
>> share/examples/dbus-1/services/org.knopwob.dunst.service
>> +share/examples/fish/
>> +share/examples/fish/vendor_completions.d/
>> +share/examples/fish/vendor_completions.d/dunst.fish
>> +share/examples/fish/vendor_completions.d/dunstctl.fish
>> +share/examples/fish/vendor_completions.d/dunstify.fish
>> +share/examples/zsh/
>> +share/examples/zsh/site-functions/
>> +share/examples/zsh/site-functions/_dunst
>> +share/examples/zsh/site-functions/_dunstctl
>
> the completion scripts should go to share/bash-completion,
> share/fish/vendor_completions.d, share/zsh/site-functions rather
> than under share/examples
Good points, here's an updated diff.
timo
diff /usr/ports
commit - 249cdbc13b64ccbf1b0f4c92f4775e302caa0a15
path + /usr/ports
blob - eac7443cb23f53d564d0d50c9e3a4c894a1fda82
file + x11/dunst/Makefile
--- x11/dunst/Makefile
+++ x11/dunst/Makefile
@@ -2,8 +2,7 @@ COMMENT = customizable and lightweight notification-da
GH_ACCOUNT = dunst-project
GH_PROJECT = dunst
-GH_TAGNAME = v1.9.2
-REVISION = 0
+GH_TAGNAME = v1.12.1
CATEGORIES = x11
@@ -44,7 +43,10 @@ MAKE_FLAGS = WAYLAND=0
FAKE_FLAGS = PREFIX="${PREFIX}" \
MANPREFIX="${PREFIX}/man" \
DATADIR="${PREFIX}/share/examples" \
- SYSCONFDIR="/etc"
+ SYSCONFDIR="/etc" \
+ BASHCOMPLETIONDIR="${LOCALBASE}/share/bash-completion" \
+ FISHCOMPLETIONDIR="${LOCALBASE}/share/fish/vendor_completions.d" \
+ ZSHCOMPLETIONDIR="${LOCALBASE}/share/zsh/site-functions"
pre-configure:
${SUBST_CMD} ${WRKSRC}/docs/dunst.1.pod \
blob - 093bbc84211d476e0f7fa34991e242f0a06f73da
file + x11/dunst/distinfo
--- x11/dunst/distinfo
+++ x11/dunst/distinfo
@@ -1,2 +1,2 @@
-SHA256 (dunst-1.9.2.tar.gz) = +mzkXAr0uuGIsNZ5pbqS+Pm35DAbsbtHboLfJrzp5xo=
-SIZE (dunst-1.9.2.tar.gz) = 4614703
+SHA256 (dunst-1.12.1.tar.gz) = NAsQw47lGadbFAQPZVBdcoF4VzWM56b+IxkKtoeC+JI=
+SIZE (dunst-1.12.1.tar.gz) = 4654978
blob - 958ea4261737f9be45def56356d55fbd23c4dccb
file + x11/dunst/patches/patch-config_mk
--- x11/dunst/patches/patch-config_mk
+++ x11/dunst/patches/patch-config_mk
@@ -1,13 +1,13 @@
Index: config.mk
--- config.mk.orig
+++ config.mk
-@@ -42,8 +42,8 @@ endif
+@@ -52,8 +52,8 @@ endif
# flags
- DEFAULT_CPPFLAGS = -Wno-gnu-zero-variadic-macro-arguments -D_DEFAULT_SOURCE -DVERSION=\"${VERSION}\" -DSYSCONFDIR=\"${SYSCONFDIR}\"
--DEFAULT_CFLAGS = -g -std=gnu99 -pedantic -Wall -Wno-overlength-strings -Os ${ENABLE_WAYLAND} ${EXTRA_CFLAGS}
+ DEFAULT_CPPFLAGS = -Wno-gnu-zero-variadic-macro-arguments -D_DEFAULT_SOURCE -DVERSION=\"${VERSION}\" -DSYSCONFDIR=\"${SYSCONFDIR}\" ${ENABLE_WAYLAND} ${ENABLE_X11}
+-DEFAULT_CFLAGS = -g -std=gnu11 -pedantic -Wall -Wno-overlength-strings -Os ${EXTRA_CFLAGS}
-DEFAULT_LDFLAGS = -lm -lrt
-+DEFAULT_CFLAGS = -g -std=gnu99 -pedantic -Wall -Wno-overlength-strings ${ENABLE_WAYLAND} ${EXTRA_CFLAGS}
++DEFAULT_CFLAGS = -g -std=gnu11 -pedantic -Wall -Wno-overlength-strings ${EXTRA_CFLAGS}
+DEFAULT_LDFLAGS = -lm
CPPFLAGS_DEBUG := -DDEBUG_BUILD
blob - e6662fa63eda43c029f8bf0b8060abd06724b7e1
file + x11/dunst/patches/patch-docs_dunst_1_pod
--- x11/dunst/patches/patch-docs_dunst_1_pod
+++ x11/dunst/patches/patch-docs_dunst_1_pod
@@ -1,12 +1,12 @@
Index: docs/dunst.1.pod
--- docs/dunst.1.pod.orig
+++ docs/dunst.1.pod
-@@ -61,7 +61,7 @@ Display a notification on startup.
+@@ -94,7 +94,7 @@ Set notification timeout time.
A default configuration file is included (usually ##SYSCONFDIR##/dunst/dunstrc)
and serves as the least important configuration file. Note: this was previously
-/usr/share/dunst/dunstrc. You can edit this file to change the system-wide
-+${PREFIX}/share/dunst/dunstrc. You can edit this file to change the system-wide
++${LOCALBASE}/share/dunst/dunstrc. You can edit this file to change the system-wide
defaults or copy it to a more important location to override its settings. See
the FILES section for more details on where dunst searches for its
configuration files and how settings get applied.
blob - 76eb300d292dd84ed65eb1f6f5a8a1deb9d9a797
file + x11/dunst/patches/patch-docs_dunst_5_pod
--- x11/dunst/patches/patch-docs_dunst_5_pod
+++ x11/dunst/patches/patch-docs_dunst_5_pod
@@ -1,25 +1,25 @@
Index: docs/dunst.5.pod
--- docs/dunst.5.pod.orig
+++ docs/dunst.5.pod
-@@ -409,7 +409,7 @@ Hide the count of stacked duplicate notifications.
+@@ -463,7 +463,7 @@ Hide the count of stacked duplicate notifications.
Show an indicator if a notification contains actions and/or open-able URLs. See
ACTIONS below for further details.
-=item B<icon_path> (default: "/usr/share/icons/gnome/16x16/status/:/usr/share/icons/gnome/16x16/devices/")
-+=item B<icon_path> (default: "${PREFIX}/share/icons/gnome/16x16/status/:${PREFIX}/share/icons/gnome/16x16/devices/")
++=item B<icon_path> (default: "${LOCALBASE}/share/icons/gnome/16x16/status/:${LOCALBASE}/share/icons/gnome/16x16/devices/")
Can be set to a colon-separated list of paths to search for icons to use with
notifications.
-@@ -423,7 +423,7 @@ replace this and will need new settings.
- Comma-separated of names of the the themes to use for looking up icons. This has
- to be the name of the directory in which the theme is located, not the
+@@ -477,7 +477,7 @@ replace icon_path search.
+ Comma-separated list of names of the themes to use for looking up icons. This
+ has to be the name of the directory in which the theme is located, not the
human-friendly name of the theme. So for example, the theme B<Breeze Dark> is
-located in F</usr/share/icons/breeze-dark>. In this case you have to set the
-+located in F<${PREFIX}/share/icons/breeze-dark>. In this case you have to set the
++located in F<${LOCALBASE}/share/icons/breeze-dark>. In this case you have to set the
theme to B<breeze-dark>.
The first theme in the list is the most important. Only if the icon cannot be
-@@ -461,12 +461,12 @@ Maximum number of notifications that will be kept in h
+@@ -515,12 +515,12 @@ Maximum number of notifications that will be kept in h
is reached, older notifications will be deleted once a new one arrives. See
HISTORY.
blob - fed4e50ecba2ae7b194f97a5556806372857a133
file + x11/dunst/patches/patch-dunstrc
--- x11/dunst/patches/patch-dunstrc
+++ x11/dunst/patches/patch-dunstrc
@@ -1,16 +1,16 @@
Index: dunstrc
--- dunstrc.orig
+++ dunstrc
-@@ -217,7 +217,7 @@
+@@ -238,7 +238,7 @@
max_icon_size = 128
- # Paths to default icons (only neccesary when not using recursive icon lookup)
+ # Paths to default icons (only necessary when not using recursive icon lookup)
- icon_path = /usr/share/icons/gnome/16x16/status/:/usr/share/icons/gnome/16x16/devices/
+ icon_path = ${LOCALBASE}/share/icons/gnome/16x16/status/:${LOCALBASE}/share/icons/gnome/16x16/devices/
### History ###
-@@ -231,10 +231,10 @@
+@@ -252,10 +252,10 @@
### Misc/Advanced ###
# dmenu path.
blob - cba0c845fee96e3f439ac82f300a16f0427e3bb9
file + x11/dunst/patches/patch-src_dunst_c
--- x11/dunst/patches/patch-src_dunst_c
+++ x11/dunst/patches/patch-src_dunst_c
@@ -1,12 +1,12 @@
Index: src/dunst.c
--- src/dunst.c.orig
+++ src/dunst.c
-@@ -100,7 +100,7 @@ static gboolean run(void *data)
+@@ -164,7 +164,7 @@ static gboolean run(void *data)
gint64 sleep = timeout_at - now;
sleep = MAX(sleep, 1000); // Sleep at least 1ms
- LOG_D("Sleeping for %li ms", sleep/1000);
+ LOG_D("Sleeping for %lli ms", (long long)sleep/1000);
- if (sleep >= 0) {
- if (reason == 0 || next_timeout < now || timeout_at < next_timeout) {
+ next_timeout_id = g_timeout_add(sleep/1000, run, NULL);
+ }
blob - f49421b7619b5443f71067d2824793187f223852
file + /dev/null
--- x11/dunst/patches/patch-src_input_c
+++ /dev/null
@@ -1,13 +0,0 @@
-Index: src/input.c
---- src/input.c.orig
-+++ src/input.c
-@@ -4,7 +4,9 @@
- #include "settings.h"
- #include "queues.h"
- #include <stddef.h>
-+#ifdef __linux__
- #include <linux/input-event-codes.h>
-+
Zeek on OpenBSD: clustering issue and dropping privileges
Hi there,
I've been trying to get Zeek to work in a very simple cluster setup; the problem is that my workers are not able to grab any data and create the expected log files. The cluster config is a single node (localhost) and monitoring of two interfaces, basically what's in the default node.cfg (manager, proxy, logger, 2 x worker). All processes start, and are listening on localhost for incoming connections. Testing the connectivity with telnet to these ports gets me to a full connection. Nothing is logged in stderr.log, i'm a bit puzzled :S
In standalone mode running against a single interface Zeek is working fine.
I'm running PF but have the "set skip lo0" set in /etc/pf.conf.
Zeek 6.0.5 is from packages on OpenBSD 7.6 / amd64
This used to work fine for me "earlier" (older OpenBSD and older version of the pkg).
Is anyone out there running this version of Zeek in a cluster setup successfully?
Another question is that it seems there's an option to drop privileges but this is not provided "out of the box" by the pkg. Has this ever been explored yet?
Thanks in advance!
Kind regards,
Jörgen
Subscribe to:
Posts (Atom)