Re: Web documentation available offline by default?
On Fri, Feb 28, 2020 at 07:24:50AM +0100, Ingo Schwarze wrote: Hi Frank, Frank Beuth wrote on Fri, Feb 28, 2020 at 04:22:27AM +: Is the web documentation (FAQ etc) included in the base system by default anywhere, No it isn't. I offered some years ago to translate the FAQ from HTML to mdoc(7) and to include it in /usr/share/man/faq/ such that it would become available for both -current and -stable both online and offline without additional maintenance effort just like any other documentation and such that it would automatically be included in apropos(1) searches, but the proposal was rejected because the developers who actually maintain the content of the FAQ consider it easier to maintain in HTML than in mdoc(7) format. We don't want to lose the valued contributions of those developers who actually spend all the work maintaining the FAQ or make their work any harder than it is now. Thanks. Too bad the mdoc idea failed!
Re: Web documentation available offline by default?
Hi Frank, Frank Beuth wrote on Fri, Feb 28, 2020 at 04:22:27AM +: > Is the web documentation (FAQ etc) included in the base system by > default anywhere, No it isn't. I offered some years ago to translate the FAQ from HTML to mdoc(7) and to include it in /usr/share/man/faq/ such that it would become available for both -current and -stable both online and offline without additional maintenance effort just like any other documentation and such that it would automatically be included in apropos(1) searches, but the proposal was rejected because the developers who actually maintain the content of the FAQ consider it easier to maintain in HTML than in mdoc(7) format. We don't want to lose the valued contributions of those developers who actually spend all the work maintaining the FAQ or make their work any harder than it is now. > or do we have to pull it from CVS manually? That would be one simple option, yes. Yours, Ingo
Web documentation available offline by default?
Is the web documentation (FAQ etc) included in the base system by default anywhere, or do we have to pull it from CVS manually?
Re: Same result (Re: build error on octeon, 6.6)
On 2020-02-26 21:50, Pekka Niiranen wrote: Hi misc, I got the same libLLVM error message I had re-tried a few weeks ago, also with bigger USB stick and NFS out of the way. And was still getting the error, too. I got distracted by work things, so I didn't post it. regards, chris "c++: error: unable to execute command: Segmentation fault" after about 3 days since "make build". I tried twice and did not use any external drives. I have 16GB USB stick inside with - 512 MB / - 512 MB swap - 1GB /tmp - 1GB /var - 10GB /usr - the rest is for /home At the time of the failure the /usr was about 50% full, I have had no problems in building the kernel and patches. -pekka- On 16.11.2019 2.22, Christian Groessler wrote: Hi, On 2019-11-11 12:18, Christian Groessler wrote: Now I'm going to rebuild again, capturing the "make" output, and try to replicate the problem manually. Interestingly, this time the build fails at a later stage. c++ -O2 -pipe -fomit-frame-pointer -std=c++11 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wdelete-non-virtual-dtor -Wno-comment -MD -MP -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/lib/Target/AMDGPU -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Analysis -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Analysis -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/BinaryFormat -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Bitcode -I/include/llvm/CodeGen -I/include/llvm/CodeGen/PBQP -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/IR -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms/Coroutines -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/ProfileData/Coverage -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/CodeView -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/DWARF -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/MSF -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/DebugInfo/PDB -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Demangle -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/ExecutionEngine -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/IRReader -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms/InstCombine -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/obj/../include/llvm/Transforms/InstCombine -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Transforms -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/LTO -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/Linker -I/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM/../../../llvm/include/llvm/MC
Re: What TERM fixes Emacs?
On 26/2/20 9:46 pm, Marc Espie wrote: > (these days, new OS versions will all use the same termcap source, so you're > probably safe on anything released over the past 5 years) Just thinking… a suitable work-around for such OSes would be to set the following in ~/.ssh/config: Host my.old.host SetEnv TERM=vt220 Note I haven't tested this to see if it works, just read `man ssh_config`. Obviously this doesn't help with other use cases like `telnet`. For those, one could do `TERM=vt100 telnet foo.example.com 1234`. If newer OSes already understand TERM=pccon, perhaps in the medium term it might be worth reviewing this default setting. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: What TERM fixes Emacs?
On 25/2/20 5:09 pm, Maurice McCarthy wrote: > On 25/02/2020, Emilia wrote: >> It is impossible to use Emacs on OpenBSD Terminal (no X). >> > > OpenBSD does not do non-X versions of ported software so even if you > dont use X as such it still needs to be in the base install. > > HTH > (I've had my backside reamed over this more than once!) > I find OpenBSD without X installed works well enough. If you're sticking to largely base applications and GUI-less ports, you can get away without X installed. Not sure if it's possible for the selected package sets to install a "virtual" package in the pkg_* tools' database that the packages can depend on; so pkg_add squawks if you try to install a GUI application without the relevant base package. That said, there's only so much free time someone can devote to testing such a set-up, so the current arrangement of "sure, omit X but dependencies on it are your problem" is workable. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: spamDB - blacklist mode
Op Thu, 27 Feb 2020 00:19:59 +0100 schreef : Questions: Does the spamDB play a role at all in pure Black listing mode ? No, that DB is used for bookkeeping and decision-making. In blacklist-only mode, there is none of that. Does the spamDB only get created/configured when running in Normal/Grey mode ? It should. Does is require Manual creation ? No. Issue: When Attempting to review SPAMDB entries i get an error: spamdb: cannot open /var/db/spamd for reading: No such file or directory What kind of entries did you expect to find? Setup: [...] -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
RE: size of size_t (diff angle)
Haai,
"Claudio Jeker" wrote:
>>> Now if SIZE_MAX is the highest address is a different thing.
>>> On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
>>> it covers actually more then what is possible). The highest valid
>>> address is in most cases less than SIZE_MAX.
>>
>> Yes, the {,in}famous halfway split... for calculations involving
>> already valid {addresse,offset,size}s that hardly matters, however.
>>
>> What *does* matter, is the potential lack of equivalence of the types.
>> Which, as you pointed out, does not affect OpenBSD (at this time), yet
>> might be a portability issue. Hence me raising it.
>
> The times of non ILP32 or I32LP64 UNIX systems is over (at least when it
> comes to userland processes).
This just adds fuel to me argument that we should ditch size_t,
uintptr_t, et al., in favour of a simple 'char *' (by that or any other
name (such as caddr_t)).
> If you want a UNIX-like OS where code will
> work then those are your only options. The ecosystem is not able to handle
> anything else anymore. All the other discussions are theortical and will
> not result in anything that is usable to run UNIX software.
Then me'd say that it's high time the relevant standards are updated to
reflect that reality.
The latter is, of course, outside the purview of OpenBSD. (But we can
set a good example.)
Thank you.
Baai,
--zeurkous.
--
Friggin' Machines!
Re: size of size_t (diff angle)
On Thu, Feb 27, 2020 at 02:07:36PM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Claudio Jeker" wrote:
> > This has not much to do with OpenBSD.
>
> On the contrary: these issues touch the fundaments of UNIX programming.
>
> > As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
> > Any other type of machine that is not covered by these two types will
> > not run OpenBSD.
>
> Oh yes, this is not NetBSD, me's well aware... And yet, metries hard to
> satisfy basic portability when feasible. This is consistent with OpenBSD
> practice, at least if the manual pages are anything to go by.
>
> > In both cases size_t is defined as unsigned long which is the same as
> > uintptr_t and the same size as pointer.
>
> Of course, in practice that's the case. You'll really get no argument
> from me there.
>
> > Now if SIZE_MAX is the highest address is a different thing.
> > On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
> > it covers actually more then what is possible). The highest valid
> > address is in most cases less than SIZE_MAX.
>
> Yes, the {,in}famous halfway split... for calculations involving
> already valid {addresse,offset,size}s that hardly matters, however.
>
> What *does* matter, is the potential lack of equivalence of the types.
> Which, as you pointed out, does not affect OpenBSD (at this time), yet
> might be a portability issue. Hence me raising it.
The times of non ILP32 or I32LP64 UNIX systems is over (at least when it
comes to userland processes). If you want a UNIX-like OS where code will
work then those are your only options. The ecosystem is not able to handle
anything else anymore. All the other discussions are theortical and will
not result in anything that is usable to run UNIX software.
--
:wq Claudio
Re: PPTP NAT passthrough
On 2020-02-26, Edgar Pettijohn wrote: > This appears to be actively maintained. > > https://sourceforge.net/projects/pptpclient/ Gábor is looking a proxy / "nat helper" not a client. > On 02/25/20 12:15, Szél Gábor wrote: >> Dear @misc >> >> Our customer need more parallel outgoing PPTP session. >> I know PPTP is no security VPN, but our client not have any options. >> (our customer remote partner accept only PPTP VPN ...) >> >> OpenBSD PF can't use parallel PPTP session. First session is NAT-ed, >> but second session is broken. >> I know OpenBSD not supported PPTP NAT passthrough. >> >> I found two, very old PPTP proxy for openbsd: >> >> * https://github.com/crvv/pptp-proxy >> This is ftp-proxy fork(?) >> * https://sourceforge.net/projects/frickin/ >> >> frickin 1.x working only fix remote PPTP address, not good for me. >> frickin 2.x (beta) not compiled on oBSD 6.6. >> >> pptp-proxy is compiled, and started, but not working. >> We tested very simple pf.conf (NAT, and some rules) >> >> pass in quick log on $int_if proto gre from any to ! $int_if:0 rdr-to >> 127.0.0.1 >> pass in quick log on $int_if proto tcp from any to ! $int_if:0 port >> 1723 rdr-to 127.0.0.1 port 2317 >> >> pptp-proxy is accepted session, but not working. >> (in tcpdump only 2 outgoing, 1 inbound packet found) >> >> Does anyone know a working solution for PPTP NAT passthrough? I haven't heard of other implementations for PF. There was one named pptp-proxy discussed on tech@ about 10 years ago which needed kernel patches as well, this might be some modified version of that but it may have been converted to userland-only as well, I haven't looked closely. It doesn't appear to rewrite call-id so it wouldn't work for connections from multiple natted clients going to the same server. >> In openbsd based securityrouter.org firewall a found PPTP-Proxy support: >> https://securityrouter.org/wiki/Comparison >> But I don't know what to use. Likely some variant of this same pptp-proxy .. A lot of securityrouter.org things are closed source afaik. If you want to run this on OpenBSD then probably you will need to either write code or fix code.
RE: size of size_t (diff angle)
Haai,
"Claudio Jeker" wrote:
> This has not much to do with OpenBSD.
On the contrary: these issues touch the fundaments of UNIX programming.
> As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
> Any other type of machine that is not covered by these two types will
> not run OpenBSD.
Oh yes, this is not NetBSD, me's well aware... And yet, metries hard to
satisfy basic portability when feasible. This is consistent with OpenBSD
practice, at least if the manual pages are anything to go by.
> In both cases size_t is defined as unsigned long which is the same as
> uintptr_t and the same size as pointer.
Of course, in practice that's the case. You'll really get no argument
from me there.
> Now if SIZE_MAX is the highest address is a different thing.
> On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
> it covers actually more then what is possible). The highest valid
> address is in most cases less than SIZE_MAX.
Yes, the {,in}famous halfway split... for calculations involving
already valid {addresse,offset,size}s that hardly matters, however.
What *does* matter, is the potential lack of equivalence of the types.
Which, as you pointed out, does not affect OpenBSD (at this time), yet
might be a portability issue. Hence me raising it.
Baai,
--zeurkous.
--
Friggin' Machines!
Re: size of size_t (diff angle)
This has not much to do with OpenBSD.
As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
Any other type of machine that is not covered by these two types will
not run OpenBSD.
In both cases size_t is defined as unsigned long which is the same as
uintptr_t and the same size as pointer.
Now if SIZE_MAX is the highest address is a different thing.
On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
it covers actually more then what is possible). The highest valid
address is in most cases less than SIZE_MAX.
--
:wq Claudio
On Thu, Feb 27, 2020 at 01:36:39AM +0100, zeurk...@volny.cz wrote:
> Haai,
>
> "Marc Espie" wrote:
> >>> You're looking at the wrong type. size_t is very good for what it does.
> >>
> >> Yes; meproblem is with the 'what it does' part.
> >
> > It represents memory sizes. It works on anything with a sane
> > memory model.
>
> The way meunderstands it, it's just an offset, plain and simple. Which
> on a sane machine is indeed of the same type as an address[0].
>
> Unfortunately, C99 does not appear to reflect that. Now, to what degree
> (if!) we should respect C99, or take it much seriously at all, is
> another matter...
>
> >>> Try uintptr_t
> >>
> >> Are you proposing a change to struct iovec?
> >
> > Why should I ? readv works with sizes, so size_t is adequate.
>
> Yes, why should you? That was me implied question. You told me to use
> uintptr_t, but that will hardly solve things on the exact problem mewas
> working on (medidn't specify what it was, and you didn't ask), unless we
> change struct iovec (cue an 'over my dead body' response from theo, and
> with respect to compat, he'd be damn right).
>
> > You were mentionning caddr_t earlier. intptr_t and uintptr_t are
> > the adequate types for working with addresses. size_t is the adequate
> > family for working with sizes.
>
> Me's found that such statements emerge from a shallow understanding of
> the nature of C. C doesn't know sizes: indeed, it barely knows indices
> and offsets. If sizeof() would have been defined to return the index
> of the final byte, instead of the count of bytes, then the C99
> definition for size_t would've been pre-empted.
>
> > POSIX kind-of implies readv, which means that both realms tend of
> > mesh.
>
> Yes, that's an obvious layer error. C as a language should not be
> confused with libc, or UNIX in general. In fact, C and UNIX appear to
> only have two concrete things in common: ASCII, and the byte as the
> fundamental type. That's it.
>
> > If you're on something where they don't, you're fucked.
>
> Me's never been the type to play it safe. The path forward is not blind
> obedience to the ravings of committees, especially those that pretend to
> set a universal standard.
>
> > Good luck.
>
> Thanks. Me's decided to ditch the {read,write}v compat wrappers and take
> the performance hit. It's all preperation for a real OS, after all:
> me'll do it right in there.
>
> > What are you doing asking questions on an OpenBSD list, btw ?
>
> nnx runs on OpenBSD. You must be confusing it with NetNIX, which is the
> OS that will eventually emerge.
>
> NetNIX will not have size_t.
>
> Baai,
>
> --zeurkous.
>
> [0] Except, of course, it's an 'offset + 1'. Oops. But that's the least
> of the problems if SIZE_MAX is not guaranteed to be the highest
> address...
>
> --
> Friggin' Machines!
>
Re: IEEE 754 floating point, POSIX, C: Why are OpenBSD's logb and logbf wrong?
Continuing on the bugs list, so respond there if appropriate. Regards, Neven Sajko
Re: How to make unveiled-Firefox as default browser ?
On 2020-02-27, dmitry.sensei wrote: > Hi! > > How to make unveiled-Firefox as default browser ? > xterm > $firefox > > xterm output Guessing but something along these lines: - see the pkg-readme about copying files to override pledge defaults - edit at least unveil.main, maybe unveil.content: - add "$XDG_CONFIG_HOME r" - change "$XDG_CONFIG_HOME/mimeapps.list" from "r" to "rwc" Try again, it might work, if not then look for more errors in output. Either remove the copy of unveil.* files after setting this up, or be sure to merge in changes from the original files when you update - these files are *not* copied with the @sample "config file" mechanism so you will not be warned at pkg_add -u time if they have changed. (It is annoying that /etc/firefox/unveil.* files set the default rather than just add to it, same for chromium, they are hard to work with as-is).
How to make unveiled-Firefox as default browser ?
Hi! How to make unveiled-Firefox as default browser ? xterm $firefox xterm output ** (firefox:98470): WARNING **: 14:36:29.641: Cannot set application as default for URI scheme (http): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.641: Cannot set application as default for URI scheme (https): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.641: Cannot set application as default for URI scheme (ftp): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.641: Cannot set application as default for URI scheme (chrome): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.642: Cannot set application as default for MIME type (text/html): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.642: Cannot set application as default for extension (htm): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.642: Cannot set application as default for MIME type (application/xhtml+xml): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory ** (firefox:98470): WARNING **: 14:36:29.642: Cannot set application as default for extension (xhtml): Can’t create user MIME configuration folder /home/dmitriy.o/.config: No such file or directory -- Dmitry Orlov
