Re: Idea to replicate OpenBSD events under quovadiz.org
I'm coming back with a maybee better solution (already online): https://events.bsdload.com NB: the page will never list the complete spec of the events but only the title of the more actual ones, and it ends with a link reminding the official events page. Let me know :D > N0\/\/@r€Z > -- > /\/\@rk€T Feb 9, 2024 21:45:52 Nowarez Market : > Hello, > > I just pop with this idea to replicate the OpenBSD events under > https://openbsd.quovadiz.org (ops, subdomain doesn't exists yet, > try https://quovadiz.org to understand): basic php page with > attractive graphics. > > I'm here to ask your opinion and eventually to state that I could care > directly about its content or pass login info to the elected person > (credentials > are indipedent). And maybe If someone has a *cool* high res artwork to rent > me for the page it could approciated, time saved. > > The hosting is that one of 5 Mode, actually Finland with a fare > web response from China too. > > Let me know ;D > > > >> N0\/\/@r€Z >> -- >> /\/\@rk€T
Re: TIP: wildcard in opening files
Thanks a lot for the clarification.. > N0\/\/@r€Z > -- > /\/\@rk€T Feb 11, 2024 07:06:34 Jeremy Baxter : > On Sun Feb 11, 2024 at 4:43 PM NZDT, Nowarez Market wrote: >> For anyone late like me, I now found really liberatory (saving me from >> typos and missing brackets mistakes) the possibility to use the wildcard >> opening files by nano and vi as well, eg: >> >> having date-uuid-blog101.txt >> >> "nano *blog101.txt" is my shortcut. > > That's a part of the shell you're using, meaning that your shell performs > this expansion, not nano or vi. You can use wildcards anywhere in shell > commands.
Re: TIP: wildcard in opening files
On Sun Feb 11, 2024 at 4:43 PM NZDT, Nowarez Market wrote: > For anyone late like me, I now found really liberatory (saving me from > typos and missing brackets mistakes) the possibility to use the wildcard > opening files by nano and vi as well, eg: > > having date-uuid-blog101.txt > > "nano *blog101.txt" is my shortcut. That's a part of the shell you're using, meaning that your shell performs this expansion, not nano or vi. You can use wildcards anywhere in shell commands.
How to set up dev environment for ESP32 MCUs?
Hello, Has anyone set up the ESP-IDF for programming ESP32 MCUs? Should I install dependencies like libmpc using pkg_add, and then install the ESP-IDF from their GitHub or put things together using xtensa-esp32-elf/* ports and use CMake without the ESP-IDF? Appreciate some pointers in the right direction by someone doing ESP32 dev on OpenBSD. -- Sadeep Madurange PGP: 103BF9E3E750BF7E
TIP: wildcard in opening files
Hello, For anyone late like me, I now found really liberatory (saving me from typos and missing brackets mistakes) the possibility to use the wildcard opening files by nano and vi as well, eg: having date-uuid-blog101.txt "nano *blog101.txt" is my shortcut. Hope this helps. > N0\/\/@r€Z > -- > /\/\@rk€T Pay check by visiting https://bsdload.com
Re: Screenshotting using PrtScr in cwm?
On Sat, Feb 10, 2024 at 05:46:27PM +0100, b...@fea.st wrote: > I did this now: > > ~$ mv .xsession .xsession.old > > > ~$ mv .cwmrc .cwmrc.old > > > ~$ doas reboot > > This landed me in fvwm. Even here, xev doesn't see the keypress. > I then did 'echo exec cwm > .xsession' and restarted X. > Here too, xev did not detect the keypress. > I tried it on my T420 laptop (kern.version=OpenBSD 7.4-current (GENERIC.MP) #1669). .xsession: setxkbmap de exec cwm The Print key works fine with the laptop keyboard. If I attach an external USB keyboard, the Print key doesn't show up in xev. cheers, Carsten
httpd generating: read_errdoc entries in syslog
Hi, I have a custom error template that I use for the error documents for httpd, as described in: man httpd.conf In /var/www I have created: /errroot:daemon chmod 0755 Within /var/www/err I have created: err.htmlwww:www chmod 0444 In my httpd.conf I have a global configuration that points to this: /etc/httpd.conf . . . errdocs "/err" When I cause an error with httpd, the error document template I have created gets rendered to the client, but I get entries in syslog like the following: serv1 httpd[23368]: read_errdoc: open: No such file or directory This also happens if a create a copy of err.html and name it 404.html. How can I modify my configuration to stop the: read_errdoc entries in syslog ? Thanks, - J
Re: Problem sound
El Sat, 10 Feb 2024 20:40:31 +0100 Manfred Koch escribió: > Hello, > > thank you for the tip, I have disabled the kern.*.record., don't need > it. Unfortunally the speakers of my monitor are still without sound. > > Manfred > OpenBSD don't have HDMI audio support. Try with a speakers or headphones. -- * Dios en su cielo, todo bien en la Tierra
Re: Problem sound
Hello, thank you for the tip, I have disabled the kern.*.record., don't need it. Unfortunally the speakers of my monitor are still without sound. Manfred On 2/10/24 11:03, hahahahacker2...@airmail.cc wrote: On 2024-02-05 19:36, Manfred Koch wrote: About you enable kern.audio.record and kern.video.record Well, I think you are following random instruction on the internet. The sysctl "record" word is clear enough, they enable audio and video recording. They are disabled by default for privacy. If you are not recording anything you should disable them. and don't follow such random instruction. Hi, partly it works! after I have set kern.audio.record=1 kern.video.record=1 and was playing a little with sndioctl, on the headphones is coming sound. output.level=0.784 output.mute=0 Nothing to hear on the speakers of my monitor. OK at least something. Thanks Manfred On 2/4/24 17:42, Todd wrote: Make sure the device is not muted. https://man.openbsd.org/sndioctl.1 On Fri, Feb 2, 2024, 9:02 AM Manfred Koch wrote: Hi all, I'm a newbie in openbsd. I use the xfce Desktop but without sound. I have enabled sndiod_enable=YES in /etc/rc.conf.local. Further I tried pulseaudio without success. What's about dbus-daemon? Perhaps you can help me, to find a solution? Are you knowing a mailinglist for newbies in openbsd? I would appreciate for any tips. Thank you Manfred Koch
what do people use for a sip proxy?
Hi, I'm back from my hiatus. what I'm looking for is something like a kamailio but much much easier and straight forward and perhaps a BSD license instead of GPL. I have about 4 weeks after next week of free time (god willing) and I'm thinking of expanding on a software of mine for a sip proxy. But if it'll save time to have a straight forward software that's already written plus the config writing and understanding, then I need not code it. The software should be able to answer a VOIP call for sip:callpeter.tel or whatever I put on https://callpeter.tel. It should also be able to do sips:// or tls'ed sip. It should register or be registerable to an already existing AVM sip server. And it should be security conscious. Thanks for feedback, -peter -- Over thirty years experience on UNIX-like Operating Systems starting with QNX.
Re: ksh horizontal line scrolling
On Sun Feb 11, 2024 at 12:34 AM NZDT, Alexander Arkhipov wrote: > I assume, the logic is similar for the emacs mode. So, unless I missed > something, disabling both the vi and emacs modes is the only way to get > rid of the behaviour. Makes sense, I might try to fiddle around with the code to see if I can make some sort of improvement to it... thanks for the explanation. -Jeremy
Re: Screenshotting using PrtScr in cwm?
On my two stations I can just reconfirm it now. I'm not using .xsession and a very simple rc that launch xconsole, and I confirm the same situation for my environment (same installation origin by stick). When in Xfce I go in Settings -> Keyboard -> Application shortcuts PrtScn is not bindable, when I press it nothing happens. The problem persists dispite the machine, appearing machine indipendent, althought I'm used to have the same two Dell keyboards since then. > N0\/\/@r€Z > -- > /\/\@rk€T Feb 10, 2024 17:27:27 Omar Polo : Also, xev doesn't detect the keypress. >>> >>> That's odd, because I just used xev to find out. >> >> Yep. Also I have this: >> >> ~$ xmodmap -pke | grep Print >> keycode 111 = Print Sys_Req Print Sys_Req
Re: Screenshotting using PrtScr in cwm?
On Sat, Feb 10, 2024, at 17:24, Omar Polo wrote: > If xev doesn't report the keypress there's a chance something else has > bound that key. Double-check that you don't have other bind directives > in your cwmrc file and that no running application may have bound that > key. > > Running a test with xev using an empty .cwmrc and a .xsession consisting > of only `exec cwm' could help in ruling out whether the key is really > not available for other reason or is 'just' a configuration error > somewhere in your .xsession or .cwmrc. I did this now: ~$ mv .xsession .xsession.old ~$ mv .cwmrc .cwmrc.old ~$ doas reboot This landed me in fvwm. Even here, xev doesn't see the keypress. I then did 'echo exec cwm > .xsession' and restarted X. Here too, xev did not detect the keypress.
Re: Screenshotting using PrtScr in cwm?
On 2024/02/10 16:34:30 +0100, b...@fea.st wrote: > On Sat, Feb 10, 2024, at 16:00, Christian Weisgerber wrote: > > > It would make more sense to use the dedicated PrtScr key, but I > > > can't work out what it's called; I've tried to brute force the name. > > > > Print > > Thanks. Not working unfortunately. > > > > Also, xev doesn't detect the keypress. > > > > That's odd, because I just used xev to find out. > > Yep. Also I have this: > > ~$ xmodmap -pke | grep Print > keycode 111 = Print Sys_Req Print Sys_Req > > Seems to me it should totally be bindable like any other key, > but it seems something eats the keypress as xev can't see it either. If xev doesn't report the keypress there's a chance something else has bound that key. Double-check that you don't have other bind directives in your cwmrc file and that no running application may have bound that key. Running a test with xev using an empty .cwmrc and a .xsession consisting of only `exec cwm' could help in ruling out whether the key is really not available for other reason or is 'just' a configuration error somewhere in your .xsession or .cwmrc.
Re: Screenshotting using PrtScr in cwm?
Sorry, I'm 3m far away from my keyboard and in lazy mode eating fruit.. I can confirm that in Xfce after 12 years passing for minipc and laptops (using same two Dell business keyboards) the Prt Scr button not functioning remained more than a problem a curiousity.. > N0\/\/@r€Z > -- > /\/\@rk€T Feb 10, 2024 16:38:59 b...@fea.st: > Seems to me it should totally be bindable like any other key, > but it seems something eats the keypress as xev can't see it either.
Re: Screenshotting using PrtScr in cwm?
On Sat, Feb 10, 2024, at 16:00, Christian Weisgerber wrote: > > It would make more sense to use the dedicated PrtScr key, but I > > can't work out what it's called; I've tried to brute force the name. > > Print Thanks. Not working unfortunately. > > Also, xev doesn't detect the keypress. > > That's odd, because I just used xev to find out. Yep. Also I have this: ~$ xmodmap -pke | grep Print keycode 111 = Print Sys_Req Print Sys_Req Seems to me it should totally be bindable like any other key, but it seems something eats the keypress as xev can't see it either. --- On Sat, Feb 10, 2024, at 15:34, PM wrote: > This works for me using my laptop keyboard.(T460s) > > bind-key Print "bin/screenshot" > > Does not work when using an external keyboard on my Docking station. This is intriguing. My computer is a 'desktop' so I'm using an external keyboard; wireless if that matters.
Re: Screenshotting using PrtScr in cwm?
This works for me using my laptop keyboard.(T460s) bind-key Print "bin/screenshot" Does not work when using an external keyboard on my Docking station. On Sat, Feb 10, 2024 at 9:08 AM wrote: > So, this work for me in .cwmrc: > > bind-key 4-F11"bin/screenshot" > > It would make more sense to use the dedicated PrtScr key, but I > can't work out what it's called; I've tried to brute force the name. > > Also, xev doesn't detect the keypress. > >
Screenshotting using PrtScr in cwm?
So, this work for me in .cwmrc: bind-key 4-F11"bin/screenshot" It would make more sense to use the dedicated PrtScr key, but I can't work out what it's called; I've tried to brute force the name. Also, xev doesn't detect the keypress.
Touchpad (with multipoint) from Lenovo Ideapad Idepad (81WQ) not working at all
Hi OpenBSD ! Recently when using Xenocara, i'm against an issue from /dev/wsmouse where Xenocara try to open it i caught a "Device busy" ( like wsmouse not seems working either) And when i check it out the `dmesg | grep ihidev` ``` ihidev0 at iic1 addr 0x15 gpio 18, vendor 0x4f3 product 0x3140, MSFT0001 ihidev0: 93 report ids imt0 at ihidev0: clickpad, 5 contacts wsmouse0 at imt0 mux 0 ims0 at ihidev0 reportid 1: 2 buttons, Z and W dir wsmouse1 at ims0 mux 0 hid at ihidev0 reportid 5 not configured hid at ihidev0 reportid 6 not configured hid at ihidev0 reportid 7 not configured hid at ihidev0 reportid 11 not configured hid at ihidev0 reportid 12 not configured hid at ihidev0 reportid 13 not configured ims1 at ihidev0 reportid 93: 0 buttons wsmouse2 at ims1 mux 0 ``` i had 3 wsmouse one with imt0, ims0/ims1 for one touchpad Does it seems like at lack of support for this touchpad ? If is it should I make a patch/commit ? If not ? needing configuration for Xenocara ? OpenBSD 7.4-current (GENERIC.MP) #1669: Fri Feb 9 01:41:16 MST 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3774521344 (3599MB) avail mem = 3639468032 (3470MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x6414b000 (53 entries) bios0: vendor LENOVO version "DVCN21WW" date 07/22/2021 bios0: LENOVO 81WQ efi0 at bios0: UEFI 2.6 efi0: INSYDE Corp. rev 0x58062021 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI UEFI SSDT TPM2 MSDM BDAT HPET LPIT APIC MCFG NPKT PRAM WSMT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT FPDT DBGP DBG2 DMAR WDAT BGRT acpi0: wakeup devices RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) RP03(S3) RP04(S3) PXSX(S3) RP05(S3) PXSX(S3) RP06(S3) PXSX(S3) XHC_(S3) HDAS(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) N4020 CPU @ 1.10GHz, 1093.01 MHz, 06-7a-08, patch 0022 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) N4020 CPU @ 1.10GHz, 1094.31 MHz, 06-7a-08, patch 0022 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpiprt5 at acpi0: bus -1 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpiec0 at acpi0 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpibat0 at acpi0: BAT0 model "L16M2PB2" serial 14175 type LiP oem "SMP" "VPC2004" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "FS4304" at acpi0 not configured "MSFT0001" at acpi0 not configured acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB "PNP0C14" at acpi0 not configured "LHK2019" at acpi0 not configured "PNP0C14" at acpi0 not configured acpicmos0 at acpi0 glkgpio0 at acpi0 GPO1 uid 1 addr 0xd0c4/0xcef irq 14, 80 pins glkgpio1 at acpi0 GPO0 uid 2 addr 0xd0c5/0xaff irq 14, 80 pins glkgpio2 at acpi0 GPO2 uid 3 addr 0xd0c9/0x7bf irq 15, 20 pins glkgpio3 at acpi0 GPO3 uid 4 addr 0xd0c8/0x82f irq 14, 35 pins "INT0E0C" at acpi0 not configured "INT33A1" at acpi0 not configured tpm0 at acpi0 TPM_ 2.0 (CRB) addr 0xfed4/0x5000, device
Re: ksh horizontal line scrolling
"Jeremy Baxter" wrote:
> Hi all, I'm trying to disable the horizontal line scrolling feature in ksh,
> enabled through `set -o vi' or `set -o emacs'. ksh(1) says this about it:
>
> In these editing modes, if a line is longer than the screen width (see
> the COLUMNS parameter), a `>', `+', or `<' character is displayed in
> the last column indicating that there are more characters after, before
> and after, or before the current position, respectively. The line is
> scrolled horizontally as necessary.
>
> Is it possible to completely disable this feature at the moment? Setting
> COLUMNS to a large number "disables" it for the most part but brings in
> other weird behaviours like massive gaps between lines when pressing
> ctrl-u and random newlines showing up when scrolling through history.
Hi, Jeremy,
The display() function in /usr/src/bin/ksh/vi.c goes something like
this:
static void
display(char *wb1, char *wb2, int leftside)
{
...
int moreright;
...
moreright = 0;
...
if (col < winwidth) {
...
} else
moreright++;
...
/* Update the "more character". */
if (es->winleft > 0 && moreright)
/* POSIX says to use * for this but that is a globbing
* character and may confuse people; + is more innocuous
*/
mc = '+';
else if (es->winleft > 0)
mc = '<';
else if (moreright)
mc = '>';
else
mc = ' ';
if (mc != morec) {
ed_mov_opt(pwidth + winwidth + 1, wb1);
x_putc(mc);
cur_col++;
morec = mc;
lastb = -1;
}
...
}
I assume, the logic is similar for the emacs mode. So, unless I missed
something, disabling both the vi and emacs modes is the only way to get
rid of the behaviour.
--
Alexander
