Re: [solved]: vi: How to display German umlauts?

2024-07-12 Thread Pontus Stenetorp
On Tue 09 Jul 2024, Страхиња Радић wrote:
> 
>   sourcesize()
>   {
>   find . -name '*.[ch]' -exec wc -l {} \; |
>   awk '{
>   size = $1
>   f = $2
>   sum += size
>   printf "%10d %s\n", size, f
>   }
>   END{
>   printf "%10d total\n", sum
>   }'
>   }
> 
> gives
> 
> 550599 total
> 
> when run in the root of Vim's repository. Aside from being a rough
> estimate (it doesn't distinguish comment lines from real code), that
> includes X11 code and various other features which could be opted out.

Always used:

wc -l $(find vim90 -name '*.[ch]')

Which gives roughly the same *rough* estimate: 516,321.

I take it you have that function for cases where the number of files is very 
large and would not fit the buffer for your shell? You can also group your 
wc(1) calls by using + as your terminator instead of \;.



Re: mirror.bytemark.co.uk appears to have removed all OpenBSD content?

2024-02-28 Thread Pontus Stenetorp
On Wed 28 Feb 2024, Stuart Henderson wrote:
> On 2024-02-28, Pontus Stenetorp  wrote:
> > On Tue 27 Feb 2024, Stuart Henderson wrote:
> >> On 2024-02-27, Stuart Henderson  wrote:
> >> > On 2024-02-27, Peter Kay  wrote:
> >> >>
> >> >> Just been to upgrade a rather old system I keep OpenBSD on for fun all
> >> >> the way up from 6.9, and found bytemark no longer seem to be hosting
> >> >> any OpenBSD content.
> >> >
> >> > That's why they have been removed from the mirrors list since 2022.
> >> 
> >> Oh hmm, seems I readded them as they had started working again, I'll drop 
> >> them again.
> >
> > Since it has crossed my mind that scripting together some sort of "mirror 
> > health" tool would be a fairly easy (yet probably valuable) contribution to 
> > the community, is there currently anything akin to that in use by you or 
> > others when maintaining the mirrors list? A few searches of mine turned up 
> > empty, but it could equally well be that my search skills were lacking.
> 
> No need for another tool, we have mirmon and mirrorcheck.sh. The problem
> is finding time to review results of checks, and making decisions
> about what to include in ftp.html (for parts of the world with low
> connectivity, a mirror which is slightly behind on snapshots can still
> be very useful).

Firstly, thank you of course for all your efforts maintaining the list. Agreed 
about usefulness being very much circumstancial and thank you for pointing me 
in the directions of two tools I have overlooked. mirmon is of course 
net/mirmon in ports, but I have failed to locate mirrorcheck.sh in both ports 
and src (even with a grep -ir), as well as with a web search. Where does it 
live?



Re: mirror.bytemark.co.uk appears to have removed all OpenBSD content?

2024-02-28 Thread Pontus Stenetorp
On Wed 28 Feb 2024, Crystal Kolipe wrote:
> On Wed, Feb 28, 2024 at 09:25:35AM +0000, Pontus Stenetorp wrote:
> > scripting together some sort of "mirror health" tool would be a fairly easy
> > (yet probably valuable)
> 
> In principle it might sound 'fairly easy', but once you start to add code to
> deal with things such as sites going down for planned maintenance, being
> unavailable from certain locations due to network problems and so on, your
> simple tool would quickly start to grow in complexity.
> 
> In any case, the list of mirrors needs to be manually reviewed.  I vaguely
> remember some years ago a previously good mirror started serving a pre-release
> copy of the distribution as if it was the actual release, and was subsequently
> removed.
> 
> A simple mirror health tool likely wouldn't catch that.

Agreed, I do not think the task should be fully automated. Rather, I think it 
would be helpful to have a couple of easy checks that could indicate the health 
of a mirror, rather than fully determine the health of it. I for example was on 
a Japanese mirror last year that "lagged" behind security patches for days, if 
not all the way up to a week, and this is a fairly easy check to automate. I 
would imagine just a list of all the mirrors on the mirrors list coupled with 
say a list of outage events, "lag events", releases available, etc. that could 
be used to get a better overview of the health of a mirror than a sample of a 
single point in time, while still not aiming for any sort of complete 
automation. Hopefully this is just a few hundred lines of Perl feeding data 
into a static page served by httpd(8).



Re: mirror.bytemark.co.uk appears to have removed all OpenBSD content?

2024-02-28 Thread Pontus Stenetorp
On Tue 27 Feb 2024, Stuart Henderson wrote:
> On 2024-02-27, Stuart Henderson  wrote:
> > On 2024-02-27, Peter Kay  wrote:
> >>
> >> Just been to upgrade a rather old system I keep OpenBSD on for fun all
> >> the way up from 6.9, and found bytemark no longer seem to be hosting
> >> any OpenBSD content.
> >
> > That's why they have been removed from the mirrors list since 2022.
> 
> Oh hmm, seems I readded them as they had started working again, I'll drop 
> them again.

Since it has crossed my mind that scripting together some sort of "mirror 
health" tool would be a fairly easy (yet probably valuable) contribution to the 
community, is there currently anything akin to that in use by you or others 
when maintaining the mirrors list? A few searches of mine turned up empty, but 
it could equally well be that my search skills were lacking.



Re: OBS-Studio 26.1.0 and later

2023-12-11 Thread Pontus Stenetorp
On Tue 12 Dec 2023, hammer2_zfs wrote:
> 
> I am scripts' kitty ;-)
> I was using OBS-Studio 26.1.0 for Streaming by OpenBSD 7.1.
> since 7.1 to now...
> 
> recently, My USB device was gone...
> then, I tried install by pkg_add obs-stuido on OpenBSD 7.4...
> but, I couldn't get the OBS-Studio...
> 
> I want to use the OBS-Studio...
> Why, close the support for OBS-Studio...

ffmpeg(1) works perfectly well for streaming and is in ports:

https://trac.ffmpeg.org/wiki/Capture/Desktop

https://trac.ffmpeg.org/wiki/StreamingGuide

It is also way easier to port than OBS, which comes with a whole laundry list 
of dependencies.



Re: sed and tab

2023-08-22 Thread Pontus Stenetorp
On Tue 22 Aug 2023, kasak wrote:
> 
> I'm in trouble with sed!
> 
> I need to insert tab in some places, but no luck :(
> 
> in linux it works:
> 
> [kasak@kasakoff ~]$ echo 'one two three' | sed s/two/\\ttwo/
> one     two three
> 
> in OpenBSD it just add t:
> 
> kasak@OpenBSD:~$ echo 'one two three' | sed s/two/\\ttwo/
> one ttwo three

You can inject "raw" tabs with ctrl+v followed by a tab:

$ echo 'one two three' | sed 's/two/two/'
one two three



Re: Problem with nsd not being reloaded.

2023-08-12 Thread Pontus Stenetorp
On Sat 12 Aug 2023, WATANABE Takeo wrote:
> 
> I am using nsd, which runs by default on OpenBSD 7.2 amd64.
> To update the zone file after changes have been made.
> 
> # rcctl reload nsd
> 
> would result in
> 
> nsd(failed)
> 
> and cannot be updated.
> 
> As far as I could find, restarting the host seems to be
> the only way to update the zone information.
> 
> How can I use the rcctl command to reload the zo information,
> as I am having trouble dealing with this?
> 
> -
> # more rc.conf.local
> 
> nsd_flags=
> smtpd_flags=NO
> sshd_flags=NO
> unbound_flags=

No solution, but I am experiencing the same issue on OpenBSD 7.3. You
do not need a restart though, you can just dig out the NSD PIDs with
grep(1) and ps(1); then pass them to kill(1) and then use rcctl(8). Not
pretty, but it works as I have not had the time to dig into what the
underlying problem is.

etc/rc.conf.local:

nsd_flags=

var/nsd/etc/nsd.conf:

server:
hide-version: yes
verbosity: 1
database: ""

remote-control:
control-enable: yes
control-interface: /var/run/nsd.sock

---8<---



Re: Feedback on redesigned OpenBSD.org

2023-08-12 Thread Pontus Stenetorp
On Sat 12 Aug 2023, Stuart Henderson wrote:
>
> To me, it looks just "different" rather than particularly better
> (except on mobile browsers, where I find the redesigned one a bit worse
> by having the links hidden away down the bottom. Scrolling to read the
> text on mobile browsers with the existing version is a bit of a
> nuisance, but so is scrolling to access the links in this rework).
> 
> And "different" is a bit of a problem, there are at least 7 associated
> websites which intentionally have the same basic design, which now
> no longer match up.
> 
> (I found v1 a lot worse than the existing one, mostly due to overriding
> browser default font/colour choices and disabling underlining for links).

As someone using the current website both on desktop and phone, the
only thing that has ever sprung to mind as a possible improvement would
be to constrain the line length, as I often have to tighten the window a
bit (interestingly, a good line length tends to be around 80
characters [1] and where have we heard that number before?). On
man.openbsd.org there is a fixed line length, just that it is a tiny
bit too wide for reading comfort.

[1]: https://practicaltypography.com/line-length.html

I honestly like the current design. It is functional and stands out
when so many other projects seem to have spent too much time on style
rather than substance.



Unsupported (?) Realtek USB WiFi dongles: RTL8188FTV and RTL8812AU

2023-01-11 Thread Pontus Stenetorp
Hello @misc,

While cleaning over the holidays I found and tried a bunch of USB dongles with 
OpenBSD (most worked just fine), hoping that perhaps I could find something to 
add to `sys/dev/usb/usbdevs` after having watched Stefan Sperling's EuroBSDcon 
2017 talk. The ones I found that were not working with OpenBSD were two WiFi 
dongles with chipsets RTL8188FTV and RTL8812AU.

However, after reading the urtwn(4) source with my near non-existent kernel 
development knowledge, I now believe that it is not as simple as just adding 
the device IDs and hooking them into urtwn(4) to get them working. Am I correct 
in this? It would have been fun to author a patch, test the devices, and 
improve the hardware support for everyone.

For reference, please find the dmesg(8) and `usbdevs -vv` outputs below.

RTL8188FTV:

ugen0 at uhub0 port 7 "Realtek 802.11n" rev 2.00/0.00 addr 4

addr 04: 0bda:f179 Realtek, 802.11n
 high speed, power 500 mA, config 1, rev 0.00, iSerial 1CBFCECE0806
 driver: ugen0

RTL8812AU:

ugen0 at uhub0 port 7 "Realtek 802.11n NIC" rev 2.00/0.00 addr 4

addr 04: 0bda:8812 Realtek, 802.11n NIC
 high speed, power 500 mA, config 1, rev 0.00, iSerial 123456
 driver: ugen0

Best regards,
Pontus Stenetorp



Magewell USB Capture HDMI+ (and HDMI 4K+) on OpenBSD 7.1 crashes with ioctl(VIDIOC_DQBUF): Invalid argument

2022-05-23 Thread Pontus Stenetorp
Hello misc@,

It has been over a decade since I used OpenBSD, but I have such fond
memories that when I recently realised that I really do not need to do
GPGPU programming on my desktop any more, there really was no excuse not
to see if I could not migrate back. But, my hardware stack grew more
complex over the pandemic and I thought it would be prudent to first
check if my external devices would play nice, which lead me to uncover
an issue with both my Magewell USB Capture HDMI+ and HDMI 4K+ USB
capture cards (I also encountered issues with my USB audio interface,
but I will save this for a separate e-mail chain).

To replicate:

1. Boot a clean 7.1 install
2. Enable video recording: `# sysctl kern.video.record=1`
3. Allow user to access device: `# chown $USER /dev/video0`
4. Confirm communication with card: `$ video -q`
5. Run `$ video -v` and observe crash. Black window shows up dies as
soon as “ioctl(VIDIOC_DQBUF): Invalid argument” shows up on stderr.
The process is then – to the best of my effort – un-killable with
even `kill -9`.

Both cards are known to work well with Linux – not that this means
OpenBSD compatibility of course – and require no additional drivers or
firmware as they are to the best of my knowledge USB Video Class (UVC)
devices. I also booted a USB stick with Lubuntu on the same computer to
confirm that it was not just the old laptop I was using for testing that
was acting up. In addition, I have confirmed that my Logitech BRIO USB
webcam is working as expected on the same laptop.

Reading `man` and searching misc@, the only thing I could come up with
was an old e-mail chain describing exactly the same symptoms for a
MacBook webcam [1]. I reached out to the original poster and they were
helpful, but they do not recall being able to resolve the issue.

[1]: https://marc.info/?l=openbsd-misc&m=160088753531879&w=2

At this point, I am sadly reaching the limit of my debugging ability and
any help would be greatly appreciated.

I am attaching `dmesg`, `lsusb -v`, and `video -v` output after my
signature. Do tell me if there is other data that could be useful. Know
that I am more than happy to put in hours to see if I can not get this
to work (even if I am far from a kernel dev…).

Regards,
Pontus

$ dmesg
OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8418754560 (8028MB)
avail mem = 8146309120 (7768MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecf90 (75 entries)
bios0: vendor Dell Inc. version "A07" date 11/24/2016
bios0: Dell Inc. Latitude 3150
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG LPIT UEFI SLIC HPET SSDT SSDT SSDT MSDM 
BGRT
acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) BRCM(S0) 
LID0(S3) PBTN(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz, 2167.08 MHz, 06-37-08
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz, 2166.68 MHz, 06-37-08
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz, 2166.69 MHz, 06-37-08
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz, 2166.69 MHz, 06-37-08
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,

Re: OpenVPN bridge

2006-12-28 Thread Pontus Stenetorp
Stuart Henderson wrote:
> On 2006/12/28 03:20, Pontus Stenetorp wrote:
>> It seems that something fails with the tun/tap, but I am not sure what.
>> The owner of the VPN Server suggested that I'd use tap as an option
>> instead since OpenBSD should have a tap driver. I haven't been able to
>> Google forth any info on this and it seems that the howto;s approach
>> with tun is the correct one since OpenBSD has included tap-functionality
>> under tun.
> 
> You need to use the tun device, with the link0 flag set on it (in
> /etc/hostname.tun0 or via ifconfig).
> 
> 
I have tried to do so, sorry about not mentioning it in the first mail.
I shall try to be more specific. This is my current status.

I am using
dev-type tap
dev tun0
which makes the tun0 device show up as an ethernet device and OpenVPN to
launch as intended.

I have set hostname.tun0 to
link0 up
and bridgename.bridge0 to
add 'int_iface'
add 'tun_iface'
up
I did a reboot in order to activate the bridge, this was stated at the
networking howto at openbsd.org. I haven't been able to launch OpenVPN
on boot however. This shouldn't be the issue, right?

After all this I expected packages from the internal network to flow to
the VPN Server. They do, but only if you specify the VPN Server IP,
otherwise they will use the normal route instead and ignore the tunnel.
I checked this using traceroute.

I couldn't change the default route at the GW but I changed so that the
route for the ip of www.whatismyip.org should be routed through the
OpenVPN server. Doing that caused whatismyip not to respond from my WS.
Leaving me curious why not all the traffic will be bridged and why the
OpenVPN Server won't do what I just think I told it to do.

Now I don't know how to proceed. How should I manage to force all
internet traffic oven the tunnel and do you agree with the OpenVPN
Server supplier that using tun screws this up(in my opinion tun should
work just as well when used properly)?



OpenVPN bridge

2006-12-27 Thread Pontus Stenetorp
Greetings everyone,

I am trying to make the following configuration work.

  |--> Internet <|
  V  V
Internal network <-> GW <-OpenVPN-> VPN Server

The idea is that the GW should access the web normally and that all the
internal network access should be tunneled to the remote VPN Server. The
thing is that most howto;s and guides are VERY Linux oriented. I have
found a few (best one so far has been
http://blog.innerewut.de/articles/2005/07/04/openvpn-2-0-on-openbsd) and
have tried them without success. In the end I aim to bridge the internal
NAT to the tunnel.

It seems that something fails with the tun/tap, but I am not sure what.
The owner of the VPN Server suggested that I'd use tap as an option
instead since OpenBSD should have a tap driver. I haven't been able to
Google forth any info on this and it seems that the howto;s approach
with tun is the correct one since OpenBSD has included tap-functionality
under tun.

Now I am lost and don't know how to approach this problem. Has anyone
done a similar configuration? Or know any better howto;s on this?

Best regards,
Pontus Stenetorp