Re: self-hosted man.openbsd.org script?
Hello,
A very good explanation. All crystal clear now, i thank you for your time.
I had a strange idea in the late night about replacing something with
something else, but i see it is not the case and there is no need to
elaborate.
Thank you.
On Thu, Dec 28, 2023 at 3:46 AM Ingo Schwarze wrote:
>
> Hi Mihai,
>
> Mihai Popescu wrote on Thu, Dec 28, 2023 at 01:32:34AM +0200:
>
> > [ removed elaborate instruction about going html from almost txt with
> > man pages ]
> >
> > All this to jump in html boat? Or I got it wrong?
> > Are old man pages deprecated?
>
> Manual pages are not restricted to a specific output format.
>
> THE traditional output format, as far as such a thing exists, is
> black markings on dead trees. That output format later evolved into
> PostScript format and still later into PDF format. Let's call all
> these output modes "typeset output".
>
> Another very old output format is video terminal (CRT) output.
> That's still used a lot, though mostly via virtual terminals nowadays
> rather than on CRTs. But all that is clearly younger than typeset
> output mode.
>
> It has already been explained why nowdays (meaning: during the
> last three decades) it has become convenient to also be able to
> access information remotely via the WWW. The simplest format to
> facilitate that has always been HTML.
>
> Even more recently (as in: during the last decade) source code
> management platforms have become popular that require documentation
> in Markdown format. So that's just another output mode for manual
> pages, see for example
>
> https://github.com/Tairokiya/rfind
> (even though using manual page format isn't widespread on that
>particular platform yet, and this example is of poor quality
>in several respects)
>
> or
>
> https://codeberg.org/fobser/gelatod
> (even though the software used by Codeberg, Forgejo, is currently
>haunted by a bug that prevents correct rendering of the
>standard-conforming Markdown (specifically, CommonMark) code
>generated from manual pages, as you can see - but that bug is
>already fixed and will be gone from the next Forgejo release)
>
>
> So, if the output format is *not* what defines manual pages, then is it
> that defines them?
>
> 1. The idea of having one self-contained document ("manual page")
> for each interface (specifically, CLI command in sections 1 and 8,
> system call in section 2, API function in section 3, kernel driver
> in section 4, configuration file in section 5, domain specific
> language in section 7, kernel function in section 9)
>
> 2. Each of these documents being complete but concise, i.e. not
> mixing in explanations of required prior knowledge about the
> foundations the interface is built on, nor containing tutorial-
> style instructions
>
> 3. A common structure consisting of
> - a one-line description (name section)
> - an informal (i.e. non-BNF), human readable syntax display
>(synopsis section)
> - a description of the arguments and behaviour (description section)
> - various standardized auxiliary sections like "return values",
>"environment", "files", "exit status", "errors", "see also",
>"standards" and so on, to help quickly locate information
>that often needs to be looked up
>
> 4. Universal tygographic conventions helping readability of the
> page for anyone familiar with other manual pages, no matter
> who wrote the particular page currently being looked at
>
> Using HTML output format for reading manual pages allows taking full
> advantage of these concepts just like any other output format does.
> So there is really no need to bash HTML as a manual page output
> format. Also remeber that HTML output format may be particularly
> convenient for people having specific accessibility requirements,
> for example blind people.
>
>
> Maybe what you had in mind is that some software authors abuse HTML as
> an *input* format for documentation, that they write documentation for
> their software directly in HTML format (instead of writing manual pages,
> which can then trivially be convented to HTML if desired, and additionally
> to many other formats). *Maintaining* documentation in HTML format is
> indeed a very bad idea. That usually results in documentation that is
> disorganized, sprawling rather than concise, hinders locating information,
> is riddled with idiosyncratic formatting choices, and next to impossible
> to convert to any other format.
>
> Yours,
> Ingo
Re: Firefox, Chrome, Libreoffice bogus syscall on -current
b...@fea.st wrote: > On Thu, Dec 28, 2023, at 00:41, Ax0n wrote: > > I had been running #1471 since December 5th without issue, and this week > > upgraded to the latest snapshot (#1567) after which some apps such as > > Firefox won't run. They display "msyscall a8000 error" followed by a > > core dump. dmesg(1) shows a bogus syscall. I did ensure that I had properly > > sysmerged and updated packages.I waited until the next snapshot hit > > mirrors, and verified that this issue persists with build #1572 and fresh > > packages as well. Lenovo X1 Carbon Gen 8. dmesg in body. I can put core > > dumps somewhere if it helps. > > I'm on #1576 and both ungoogled-chromium and firefox work fine. The problem occurs when a package uses a library which has a DT_NEEDED reference to an older libc library, but the snapshot has moved to a new library major/minor version. Then ld.so loads both libraries, and that won't work. This DT_NEEDED stuff is very much designed to discourage any trend other than ossification.
Re: Firefox, Chrome, Libreoffice bogus syscall on -current
On Thu, Dec 28, 2023, at 00:41, Ax0n wrote: > I had been running #1471 since December 5th without issue, and this week > upgraded to the latest snapshot (#1567) after which some apps such as > Firefox won't run. They display "msyscall a8000 error" followed by a > core dump. dmesg(1) shows a bogus syscall. I did ensure that I had properly > sysmerged and updated packages.I waited until the next snapshot hit > mirrors, and verified that this issue persists with build #1572 and fresh > packages as well. Lenovo X1 Carbon Gen 8. dmesg in body. I can put core > dumps somewhere if it helps. I'm on #1576 and both ungoogled-chromium and firefox work fine.
Re: self-hosted man.openbsd.org script?
Hi Mihai,
Mihai Popescu wrote on Thu, Dec 28, 2023 at 01:32:34AM +0200:
> [ removed elaborate instruction about going html from almost txt with
> man pages ]
>
> All this to jump in html boat? Or I got it wrong?
> Are old man pages deprecated?
Manual pages are not restricted to a specific output format.
THE traditional output format, as far as such a thing exists, is
black markings on dead trees. That output format later evolved into
PostScript format and still later into PDF format. Let's call all
these output modes "typeset output".
Another very old output format is video terminal (CRT) output.
That's still used a lot, though mostly via virtual terminals nowadays
rather than on CRTs. But all that is clearly younger than typeset
output mode.
It has already been explained why nowdays (meaning: during the
last three decades) it has become convenient to also be able to
access information remotely via the WWW. The simplest format to
facilitate that has always been HTML.
Even more recently (as in: during the last decade) source code
management platforms have become popular that require documentation
in Markdown format. So that's just another output mode for manual
pages, see for example
https://github.com/Tairokiya/rfind
(even though using manual page format isn't widespread on that
particular platform yet, and this example is of poor quality
in several respects)
or
https://codeberg.org/fobser/gelatod
(even though the software used by Codeberg, Forgejo, is currently
haunted by a bug that prevents correct rendering of the
standard-conforming Markdown (specifically, CommonMark) code
generated from manual pages, as you can see - but that bug is
already fixed and will be gone from the next Forgejo release)
So, if the output format is *not* what defines manual pages, then is it
that defines them?
1. The idea of having one self-contained document ("manual page")
for each interface (specifically, CLI command in sections 1 and 8,
system call in section 2, API function in section 3, kernel driver
in section 4, configuration file in section 5, domain specific
language in section 7, kernel function in section 9)
2. Each of these documents being complete but concise, i.e. not
mixing in explanations of required prior knowledge about the
foundations the interface is built on, nor containing tutorial-
style instructions
3. A common structure consisting of
- a one-line description (name section)
- an informal (i.e. non-BNF), human readable syntax display
(synopsis section)
- a description of the arguments and behaviour (description section)
- various standardized auxiliary sections like "return values",
"environment", "files", "exit status", "errors", "see also",
"standards" and so on, to help quickly locate information
that often needs to be looked up
4. Universal tygographic conventions helping readability of the
page for anyone familiar with other manual pages, no matter
who wrote the particular page currently being looked at
Using HTML output format for reading manual pages allows taking full
advantage of these concepts just like any other output format does.
So there is really no need to bash HTML as a manual page output
format. Also remeber that HTML output format may be particularly
convenient for people having specific accessibility requirements,
for example blind people.
Maybe what you had in mind is that some software authors abuse HTML as
an *input* format for documentation, that they write documentation for
their software directly in HTML format (instead of writing manual pages,
which can then trivially be convented to HTML if desired, and additionally
to many other formats). *Maintaining* documentation in HTML format is
indeed a very bad idea. That usually results in documentation that is
disorganized, sprawling rather than concise, hinders locating information,
is riddled with idiosyncratic formatting choices, and next to impossible
to convert to any other format.
Yours,
Ingo
EUROPE IS THE LAND OF FAGGOTS
EUROPE IS THE LAND OF FAGGOTS
Theo is a FAGGOT
Theo is a FAGGOT
TED CRUZ IS A MANURE EATING FAGGOT
TED CRUZ IS A MANURE EATING FAGGOT TED CRUZ IS A MANURE EATING FAGGOT
Re: self-hosted man.openbsd.org script?
Mihai Popescu writes: [ removed elaborate instruction about going html from almost txt with man pages ] All this to jump in html boat? Or I got it wrong? Are old man pages deprecated? It can be convenient to have Web-based access to the man pages for systems or software that one isn't currently using (or that isn't already installed). Gentoo is my daily driver, and as it turns out, the OpenBSD man pages are available as a package in the GURU repo, so i have that package installed to allow me to read those man pages on my Gentoo box: $ man cat will get me the man page for GNU coreutils 'cat', but: $ man 1bsd cat will get me the man page for OpenBSD's 'cat'. In the absence of such packaging, a Web-based UI for reading the man pages of other systems can be really helpful (e.g. for checking what functionality is and isn't implemented in a given system's implementation of a particular program, for portability reasons). Alexis.
Firefox, Chrome, Libreoffice bogus syscall on -current
I had been running #1471 since December 5th without issue, and this week upgraded to the latest snapshot (#1567) after which some apps such as Firefox won't run. They display "msyscall a8000 error" followed by a core dump. dmesg(1) shows a bogus syscall. I did ensure that I had properly sysmerged and updated packages.I waited until the next snapshot hit mirrors, and verified that this issue persists with build #1572 and fresh packages as well. Lenovo X1 Carbon Gen 8. dmesg in body. I can put core dumps somewhere if it helps. OpenBSD 7.4-current (GENERIC.MP) #1572: Wed Dec 27 03:22:15 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16758042624 (15981MB) avail mem = 16230166528 (15478MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x6cbac000 (70 entries) bios0: vendor LENOVO version "N2WET36W (1.26 )" date 03/25/2022 bios0: LENOVO 20U9S1QP00 efi0 at bios0: UEFI 2.7 efi0: Lenovo rev 0x1260 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT NHLT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR ASF! UEFI FPDT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1880.50 MHz, 06-8e-0c, patch 00f8 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1795.08 MHz, 06-8e-0c, patch 00f8 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1791.52 MHz, 06-8e-0c, patch 00f8 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1791.22 MHz, 06-8e-0c, patch 00f8 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CT
Re: self-hosted man.openbsd.org script?
[ removed elaborate instruction about going html from almost txt with man pages ] All this to jump in html boat? Or I got it wrong? Are old man pages deprecated?
Re: Keyboard/trackpad issues on HP Chromebook 11 G5 Setzer
On Mon, Dec 25, 2023 at 09:13:40PM +, jrmu wrote: > >Synopsis:Keyboard/trackpad issues on HP Chromebook 11 G5 Setzer > >Category:amd64 > >Environment: > System : OpenBSD 7.4 > Details : OpenBSD 7.4 (GENERIC.MP) #1382: Wed Sep 27 10:51:31 MDT > 2023 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > > I installed MrChromebox firmware > (https://mrchromebox.tech/static/fwscript.html) on an HP Chromebook 11 > G5 Setzer, then proceeded to install OpenBSD 7.4 snapshots. I was able > to get OpenBSD to boot, built-in wifi is working but trackpad and > keyboard are malfunctional. This sounds very similar to what I reported in: https://marc.info/?l=openbsd-bugs&m=169030217301737&w=2 > > I see this error after the login prompt: > > pckbc: command timeout > pckbc: command timeout > pckbc: command timeout > > The trackpad itself is not detected at all. It neither senses clicks nor > mouse movements. But in my case I didn't observe timeout errors and I didn't try to use the trackpad. It could be MrChromebox firmware is buggy or it only works in combination with Linux distros. Since I don't have enough context to investigate how is that firmware built I ended using that laptop as a headless server (machdep.lidaction=0) -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche
Re: certbot with cloudflare dns-01 challenge
Hmmm, I don't believe "inconvenience" for an OpenBSD user motivates folks who create OpenBSD packages. Look at this another way, you could create py3-certbot-dns-cloudflare package, and submit it to OpenBSD ports list for inclusion as a supported package, with you as the developer. Then you would be contributing to OpenBSD. 73 diana On December 27, 2023 3:49:59 AM MST, hammer2_zfs wrote: >hi, dears;-) > >I'm using the OpenBSD 7.4 and snapshots. >recently, I was trying the pkg_add certbot certbot-dns-cloudflare. >pkg_add certbot was ok. but, pkg_add certbot-dns-cloudflare was fail. >(it was need a pip. it must be pkg_add py3-certbot-dns-cloudflare. but same >things. ) > >I was more trying. pkg_add py3-pip py3-cryptography_vectors rust. >And run: >pip freeze > requirements.txt_orig >cat requirements.txt_orig|grep certbot|sed >"s/==/-dns-cloudflare==/g">>requirements.txt >python3 -m venv _any_ && . ./_any_/bin/activate; >pip3 install --upgrade pip && pip install -r requirements.txt >it was getting done. I could run certbot certonly -dns-cloudflare ...any. >but, so terrible job. >(ofcouse any programer will get a success, but many users could not get a >success.) > >Why "OpenBSD packages" did not have a py3-certbot-dns-cloudflare. >It's a very inconvenient.
certbot with cloudflare dns-01 challenge
hi, dears;-) I'm using the OpenBSD 7.4 and snapshots. recently, I was trying the pkg_add certbot certbot-dns-cloudflare. pkg_add certbot was ok. but, pkg_add certbot-dns-cloudflare was fail. (it was need a pip. it must be pkg_add py3-certbot-dns-cloudflare. but same things. ) I was more trying. pkg_add py3-pip py3-cryptography_vectors rust. And run: pip freeze > requirements.txt_orig cat requirements.txt_orig|grep certbot|sed "s/==/-dns-cloudflare==/g">>requirements.txt python3 -m venv _any_ && . ./_any_/bin/activate; pip3 install --upgrade pip && pip install -r requirements.txt it was getting done. I could run certbot certonly -dns-cloudflare ...any. but, so terrible job. (ofcouse any programer will get a success, but many users could not get a success.) Why "OpenBSD packages" did not have a py3-certbot-dns-cloudflare. It's a very inconvenient.
Re: sec interface and rdomain
hi no the main reason for the question was that i try rdomain and tunneldomain than i got an error messages , i think at the tunneldomain option. in general , without rdomain sec interface and ipsec works , in my case i had trouble with an second sec interface, sometime he use allways the sec0 interface instead of sec1 , this i fix it with use of iked. my wish is to use sec interface like , as example vxlan , with tunneldomain. vxlan interface is in my internal rdomain 10 and the tunneldomain 0 is where my wan if is and the iked listen. Holger On 26.12.23 08:36, David Gwynne wrote: which bit doesnt work? the "tunneldomain" command or actual packets moving? sec transport is provided entirely by the ipsec stack, ie, you configure the ipsec SAs associated with the interface to operate in a specific rdomain, sec doesn't support configuration that with tunneldomain. if you tcpdump on the enc and sec interfaces, do you see the packets you're expecting? dlg On 24 Dec 2023, at 19:21, Holger Glaess wrote: hi i try to use the new sec0 if in this manner. --- cat /etc/hostname.sec0 rdomain 10 inet 172.16.0.1 255.255.255.252 172.16.0.2 tunneldomain 0 up --- but it will not work . can sec work with rdomain ? happy christmas to all. Holger
