hebrew charset encoding iso-8859-8-i

Hi folks. I like to read my email. I don't like needing to use python scripts to parse it. So this diff worked for me. Index: i18n/esdb/ISO-8859/ISO-8859.alias === RCS file: /cvsroot/src/share/i18n/esdb/ISO-8859/ISO-8859.alias,v retr

Re: hebrew charset encoding iso-8859-8-i

On Thu, Jun 07, 2018 at 09:56:52PM +0200, Joerg Sonnenberger wrote: > On Thu, Jun 07, 2018 at 05:54:57PM +, co...@sdf.org wrote: > > I like to read my email. I don't like needing to use python scripts to > > parse it. So this diff worked for me. > > Are you really sure that they are the same t

_XOPEN_SOURCE, _POSIX_C_SOURCE

Hi folks, I am under the impression that _XOPEN_SOURCE is a supserset of _POSIX_C_SOURCE. glibc documents the following happens: Macro: _XOPEN_SOURCE Macro: _XOPEN_SOURCE_EXTENDED If you define this macro, functionality described in the X/Open Portability Guide is included. This is a super

g77 references

Hi folks, I wanted to package a fortran library to use bmake. I don't think g77 is a thing any more. How about the attached diff? Index: bsd.own.mk === RCS file: /cvsroot/src/share/mk/bsd.own.mk,v retrieving revision 1.1072 diff -u -r

Definitions of types also as macros

we do this in stdint.h and some other headers: #ifndef uint32_t typedef __uint32_t uint32_t; #define uint32_t__uint32_t #endif then, if a package does something like this: #include #define function(name, type) int name##_##type() { return 3; } #define useless_wrapper(name, type)

Re: Definitions of types also as macros

I wanna do this, looks good? Index: stdint.h === RCS file: /cvsroot/src/sys/sys/stdint.h,v retrieving revision 1.7 diff -u -r1.7 stdint.h --- stdint.h22 Apr 2013 21:26:48 - 1.7 +++ stdint.h4 Nov 2018 09:35:54 - @@

Re: Definitions of types also as macros

On Tue, Nov 06, 2018 at 08:11:03AM -0800, John Nemeth wrote: > On Nov 6, 3:07pm, co...@sdf.org wrote: > } > } I wanna do this, looks good? > > No. > > } Index: stdint.h > } === > } RCS file: /cvsroot/src/sys/sys/stdint.h,v > }

Moving telnet/telnetd from base to pkgsrc

Hi, telnet: 1. terrible code, with many abstraction violations 2. something people expect to talk to their legacy machines, which nobody but them has access to. 3. common use case is served by netcat, already in base. 4. too much superfluous functionality. Let's pull it out as a package, the alte

Re: Moving telnet/telnetd from base to pkgsrc

The maintenance burden is as follows: - Y'all seem to think it's totally reasonable to telnet in the open internet This means it begs for a rewrite - You'd want some esoteric functionality preserved This means rewriting it isn't going to happen

Re: Moving telnet/telnetd from base to pkgsrc

You know I'm writing this as telnet on netbsd is vulnerable to remote exploits, and everyone that can MITM you can do that to you whenever you 'telnet to see if ports are open'?

Re: Moving telnet/telnetd from base to pkgsrc

It won't be hard to write a telnet client that does all of that, but it's not going to have 100% compatibility with the existing client in netbsd and it will never be tested against ancient telnet servers, so it won't be accepted as a replacement.

find and limits

hi folks, I understand the need for correctness, but the limits for find ... -exec are really low, and it's quite unclear why things fail when they do. cd /cvs/pkgsrc/fonts/urbanrenewal-ttf/ make patch mkdir -p work/.destdir/usr/pkg/share/fonts/X11/TTF find /cvs/pkgsrc/fonts/urbanrenewal-ttf/work

Re: find and limits

Thanks. I committed that. I'm slightly horrified by this being the problem.

Re: find and limits

On Sat, Apr 06, 2019 at 03:18:10PM +0700, Robert Elz wrote: > Date:Sat, 6 Apr 2019 07:02:34 + > From:co...@sdf.org > Message-ID: <20190406070234.ga5...@sdf.org> > > | Thanks. I committed that. > | I'm slightly horrified by this being the problem. > > I hope it

More compatibility for refuse

hi folks, this adds the version of fuse_mount, fuse_new, fuse_unmount between FUSE 2.2 and FUSE 3.0 as compat shims. This is used by fuse-ntfs-3g, fuse-encfs. This also adds fuse_version. This is used by fuse-ext2 that is being patched in pkgsrc. Tell me what you think. I will commit it soon ot

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote: > > +#if FUSE_USE_VERSION < 30 > +#define fuse_unmount fuse_unmount_compat30 > +#endif Open to (FUSE_USE_VERSION < 30) && (FUSE_USE_VERSION > 22) :-)

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 02:22:22PM +, Emmanuel Dreyfus wrote: > On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote: > > Tell me what you think. I will commit it soon otherwise. > > You know we support vnilla libfuse through libperfuse, right? > > -- > Emmanuel Dreyfus > m...@netbs

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 12:23:28PM -0400, Greg Troxel wrote: > co...@sdf.org writes: > > > On Wed, Apr 10, 2019 at 02:22:22PM +, Emmanuel Dreyfus wrote: > >> On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote: > >> > Tell me what you think. I will commit it soon otherwise. > >> > >

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 12:46:57PM -0400, Greg Troxel wrote: > co...@sdf.org writes: > > > On Wed, Apr 10, 2019 at 02:16:30PM +, co...@sdf.org wrote: > >> > >> +#if FUSE_USE_VERSION < 30 > >> +#define fuse_unmount fuse_unmount_compat30 > >> +#endif > > > > Open to (FUSE_USE_VERSION < 30) &&

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 12:44:44PM -0400, Greg Troxel wrote: > co...@sdf.org writes: > > > If anything we should get rid of perfuse. > > Certainly not. It is there because gluster uses /dev/fuse directly, or > via some "low level" API, rather than using the standard FUSE API (the > "high level"

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 08:55:05PM +0200, Emmanuel Dreyfus wrote: > wrote: > > > If anything we should get rid of perfuse. > > FUSE has thee API: kernel level, low level and high level. > > refuse only implements the high level API > > perfuse implements the kernel API, libfuse runs on top of

Re: More compatibility for refuse

On Wed, Apr 10, 2019 at 10:19:38PM +, Taylor R Campbell wrote: > > Date: Wed, 10 Apr 2019 19:50:02 + > > From: co...@sdf.org > > > > On Wed, Apr 10, 2019 at 08:55:05PM +0200, Emmanuel Dreyfus wrote: > > > wrote: > > > > > > > If anything we should get rid of perfuse. > > > > > > FUSE ha

combining signbitl.c

hi, i386, m68k, sparc64, x86_64 have their own version of signbitl.c I don't believe this is necessary. It is an exact copy. 80 bit and 128 bit differences are handled under the struct ieee_ext. ok to make all users use signbitl_ieee754.c? Index: arch/x86_64/gen/Makefile.inc ===

Re: More compatibility for refuse

I'm merely upset that the people who are currently calling for librefuse to be deleted ignore all the complaints about things being dysfunctional until the very moment I decide to do something about librefuse, because I didn't pick their preferred way of doing things. (Even now, nobody seems to car

restoring old jemalloc patches

hi folks, while skimming jemalloc, noticed a comment about our old code being better. there's a while loop trying to get aligned allocations, so it probably does matter (pages_map_slow). Any good benchmarks to use? Bring in code from old jemalloc customized for netbsd. There's a loop calling os_p

Re: restoring old jemalloc patches

On Thu, Jul 11, 2019 at 10:30:52PM +, co...@sdf.org wrote: > hi folks, while skimming jemalloc, noticed a comment about our old code > being better. * Ideally, there would be a way to specify alignment to mmap() (like * NetBSD has), but in the absence of such a feature, we ha

Re: restoring old jemalloc patches

I have patches against upstream jemalloc here: https://github.com/coypoop/jemalloc

stdbool.h #define bool _Bool

hi folks, while building an updated Mono, I came across a familiar issue: icall.c:9175:35: error: ‘ICALL_SIG_TYPE__Bool’ undeclared here (not in a function); did you mean ‘ICALL_SIG_TYPE_bool’? #define ICALL_SIG_TYPES_1(a) ICALL_SIG_TYPE_ ## a, I've had this issue before with macros, but

Proposal: drop ldconfig from /rescue

ldconfig in netbsd is purely for a.out support. I don't think a.out support is important in /rescue, no platform we have uses it (since long ago). it's the majority of the machine-dependent logic in /rescue. I'd like to remove ldconfig and mark it machine-independent obsolete. I will commit this

Re: Proposal: drop ldconfig from /rescue

On Mon, Sep 30, 2019 at 08:04:52PM +, co...@sdf.org wrote: > it's the majority of the machine-dependent logic in /rescue. The majority of the machine-dependent set lists, rather. I'd like to make a rescue set, so I need to move stuff around a bit :-)

sysconf(_SC_RTSIG_MAX)

Patch attached. Needed this for sudo update. Please tell me how I am wrong. Thanks. Index: sys/sys/unistd.h === RCS file: /cvsroot/src/sys/sys/unistd.h,v retrieving revision 1.61 diff -u -r1.61 unistd.h --- sys/sys/unistd.h4 Aug 2

Re: sysconf(_SC_RTSIG_MAX)

On Wed, Oct 16, 2019 at 06:16:57PM +, Niclas Rosenvik wrote: > On Mon, 14 Oct 2019 20:40:10 + > co...@sdf.org wrote: > > > Patch attached. Needed this for sudo update. > > > > Please tell me how I am wrong. > > Thanks. > > According to the opengroup docs on sysconf _SC_RTSIG_MAX is to re

[PATCH] make man -p return zero exit code

man -p returns 1 error code, because the control flow of the program keeps looking at the remaining arguments (empty list) and it doesn't find a matching manual page. Fish (shell) has gone through this flow process: 1. Append its own weirdo-shell manual pages to the MANPATH, but only if you are u

Re: [PATCH] make man -p return zero exit code (committed)

Committed.

[PATCH] Avoid defining _NETBSD_SOURCE for strict C++

_NETBSD_SOURCE defines some extra functions, which may use reserved names. The following patch avoids this problem. OK? Index: sys/featuretest.h === RCS file: /cvsroot/src/sys/sys/featuretest.h,v retrieving revision 1.10 diff -u -r

[PATCH] Make more of stdlib.h visible if _NETBSD_SOURCE isn't defined

... This is some progress towards the previous patch being viable, however I'll have to patch libstdc++ and a bunch of other things, too. Move the big "if _NETBSD_SOURCE" chunk to the "Implementation defined" section. Makes "at_quick_exit" and others visible for strict C/C++. Index: stdlib

Re: [PATCH] Avoid defining _NETBSD_SOURCE for strict C++

On Sun, Aug 30, 2020 at 10:42:14AM +, co...@sdf.org wrote: > _NETBSD_SOURCE defines some extra functions, which may use reserved > names. The following patch avoids this problem. > > OK? I immediately regret my decision. Things are very broken this way.

Web UI for NPF as a GSoC project

xed on this plan at all, willing to change any part given it is done at the beginning. Thanks for reading! coypu

Re: Web UI for NPF as a GSoC project

On Sun, Mar 13, 2016 at 04:34:09PM +, Christos Zoulas wrote: > > This looks good, but I am wondering if it is not going to be easier > and better for you to use one of the existing web-ui frameworks so > you can have more time to spend on functionality. > > christos > Qualifying again that

Revised Web UI for NPF as a GSoC project

After feedback and some thought, I've come up with a revised plan. Mostly chosen some tools, namely purecss for front-end (I would like to mostly avoid angularJS because I don't want to require JavaScript), nginx+Lapis for Lua framework, etc. I get the impression that we want something that offer

Re: honor to join NetBSD community

Hi Charles! I'm also doing a summer of code project in netbsd, although in a very different area (I'm doing the web interface for NPF/blacklistd). On Wed, Apr 27, 2016 at 06:11:28PM -0700, Charles Cui wrote: > 2. How do you work in netbsd, do you use GUI (like xwindow, or gnome)? > If so, which >

computer-friendly way of accessing ifconfig

hi, I'd like to write code that works with the input or output typically done with ifconfig. as an example, I would like to know, say, which interfaces are wireless and which are wired, as they tend to be controlled differently, and whether they are up. my options currently seem to be: 1. parse t

Useless programs in base.tgz - bpm, ekermit...

Hi, There's a lot of programs sticking around since a long time, and are less useful today. at the very least, they do not need to be in base.tgz, which means they take up space even in minimal installs. Examples: ekermit in rescue, base.tgz bpm in base.tgz atf tests utilities in base.tgz I want

Re: Useless programs in base.tgz - bpm, ekermit...

On Fri, Jun 24, 2016 at 10:27:01AM -0400, Thor Lancelot Simon wrote: > I added kermit (gkermit, which was later replaced with ekermit). I added > it because it is: > > A) Tiny > B) Essential for recovering damaged systems with only serial > console access. > > It's repeatedl

non-IEEE754 float

Hi, IBM has its own float format with FLT_RADIX=16. Only in 1998 they started offering IEEE754 float on the same hardware. Does NetBSD intend/does support this? is this something to keep in mind? Thanks.

Re: libm

If people think an upstream is useful, I suggest deleting our libm completely and replacing it with musl's.

complex functions

Hi, so as per PR/51427, a lot of our complex functions don't correctly handle edge cases. I've added tests for it based on annex G. while trying to figure out issues I've noted a common fault, the use of multiplication on complex numbers unnecessarily - I * number will be expanded as (0+i)*number,

Re: complex functions

FreeBSD's catrig.c is here: https://grok.dragonflybsd.org/xref/freebsd/lib/msun/src/catrig.c

Random build failures (rump)

Hi, There are sometimes build failures that seem to be from race conditions, I've seen rump do it, maybe others too. e.g. http://releng.netbsd.org/builds/netbsd-6/201610160430Z/ews4800mips.build.failed http://releng.netbsd.org/builds/netbsd-6-1/201610122020Z/evbmips-mips64el.build.failed It see

Re: Random build failures (rump)

However, I'm not sure if the failures I mentioned are related.

Re: Random build failures (rump)

Interestingly, some stuff within src/lib/librumpuser uses $RANDOM and assumes that it does what it says, deleting old content in new supposedly random directory. (lib/librumpuser/build-aux/install-sh, newest version still does it, though.) That wouldn't work too well for us - I wonder if that has

Trouble with ASan

Hi, I wanted to run our tests with asan/ubsan. I've used the following: cd /usr/src ./build.sh ... -O /usr/amd64 release cd /usr/src/lib/libm env USETOOLS=never CFLAGS="-fsanitize=undefined -fsanitize=address -U_FORTIFY_SOURCE" LDFLAGS="-lasan -pthread -lubsan" make -j20 cd /usr/tests/lib/libm

Re: Trouble with ASan

On Tue, Feb 07, 2017 at 11:16:20AM +, co...@sdf.org wrote: > env LD_PRELOAD="/usr/amd64/ .. The crazy LD_PRELOAD command is because of this: ==15831==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==15831==P

Re: Trouble with ASan

Apparently as an alternative to preloading a separate ld.elf_so and others, I can disable ASLR. Still unsure what to do with the pthread stuff. I get the impression I should be compiling everything with asan, but it's unclear to me how to start to build all of netbsd this way.

Re: Trouble with ASan

On Sun, Mar 05, 2017 at 05:58:06PM +0100, Rhialto wrote: > On Tue 07 Feb 2017 at 21:40:21 +, co...@sdf.org wrote: > > I get the impression I should be compiling everything with asan, > > but it's unclear to me how to start to build all of netbsd this > > way. > > Which version of clang were yo

KASSERT and clang static analyzer

Hi, I'm trying clang static analyzer. It seems to assume that KASSERT(a != 0) => test what happens if a == 0 in the rest of the function any idea how to convince it to stop doing that? example output: http://i.imgur.com/AqTm9mq.png I'm building kernel with 'scan-build make -j20' Thanks.

non-root ntpd

Hi, we've been able to run ntpd as non-root for a while. this is not the default if you innocently ntpd=yes in rc.conf. it requires /dev/clockctl, and most things have it, even one of the sun2 kernels. can I change this to become the default, for better default security? Index: rc.conf =

Re: non-root ntpd

On Thu, Jun 29, 2017 at 01:06:35AM +, Taylor R Campbell wrote: > > Date: Thu, 29 Jun 2017 00:02:24 + > > From: co...@sdf.org > > > > we've been able to run ntpd as non-root for a while. this is not the > > default if you innocently ntpd=yes in rc.conf. it requires > > /dev/clockctl, and mo

Re: non-root ntpd

It sounds like it is going to be a really unexpected and nasty surprised for non-dhcpcd users. configure network, ntpd enabled, change ip 100 days later -> why is my machine off by a few seconds?? I'm running ntpd!

Default PAGER -> less

Hi! I like good defaults. 'more' as PAGER means that when I scroll to the bottom of a man page, it closes the man page. Apparently that is 'normal more behaviour'. I can change just mdocml to fallback to less, but that would be awkward, because other things may default otherwise(?). I thought of

Re: Default PAGER -> less

Hi kre, the reason I am proposing changing the defaults is for the sake of people like myself that don't know that they need to set PAGER to have this behaviour. I don't relate the word 'pager' to this use, and didn't know the difference between 'more' and 'less'. I'm assuming changes to ~/.prof

Re: Default PAGER -> less

hi greg, your use case will be unaffected. when we create a new user, we populate the home dir with some dotfiles. it'd be nice if they were good dotfiles. you can always replace them, and these changes won't affect existing users. I agree it would be nice if they were the 'actual defaults' rath

lgamma non-standard extension

hi folks, we have a small compatible extension to lgamma, a standard C function. we provide the sign of gamma(x) result in signgam, in a global. we also have a reentry safe version, lgamma_r, where signgam is passed as an argument. because this is a standard C function, I assume the compiler is

Re: lgamma non-standard extension (nvm, i was wrong)

apologies, should've read POSIX first. netbsd is not alone in having 'extern int signgam', that is part of POSIX. so at least we won't be the only ones to have an issue if compilers decide to replace lgamma.

Removing header * man page of isinff

Hi, In the next major bump we should get rid of the non-standard: isnanf, isinff (need to provide 'hidden' isnanf and provide a type-generic macro for it per the standard) Any objections for getting rid of the declaration of isinff and isnanf in math.h, as well as getting rid of the man page?

tgmath

Hi folks, warning, if you like C for its simplicity, do not read the below post. while looking at the stdatomic nonsense versions, I noticed we are using tgmath.h from gcc, but no tgmath.h from clang, if the set lists are to believed. randomly poking it turned out that in C99 you probably had to

Re: tgmath

On Tue, Sep 26, 2017 at 10:28:23PM +0200, Kamil Rytarowski wrote: > Can we just import as-is the FreeBSD version? No. > Can we please reuse the template license header for new code? > Public-domain might be problematic for strict people (it does not work > for all countries). Absolutely not.

Re: tgmath

Apparently we do have our own version we do not install. https://nxr.netbsd.org/xref/src/include/tgmath.h

Re: Removing header * man page of isinff

On Wed, Sep 27, 2017 at 08:32:35AM +, David Holland wrote: > Is there any reason these shouldn't exist anyway? They can always be > stuck within a suitable *_SOURCE block. It's not a problem that we have them, but you would approximately never want to use them: - portability - compilers optimi

GNU shellery

Hi reversing lines currently: BSDs: tail -r GNU: tac Anyone writing portable code: sed '1!G;h;$!d' (Yes that actually works) Attached diff adds a hard link tac (need set lists adjusted though, and I have a man page). it doesn't add any of the GNU tac options. Cost: a hard link. Index: Makefile

Re: gnu shellery

minus using optind uninitialized

Re: gnu shellery

adjusted per comments from uwe, to match head (and gnu) code copied matching head. add options to tail: -q (never print header of filename) -v (always print header of filename) same as head, same as gnu tail add tac which is like tail -rq Index: Makefile

Re: gethostbyname_r

Another case, tcl was using gethostbyname_r as well, resulting in a runtime crash in code not frequently used: http://core.tcl.tk/tcl/info/91466985995db6b5

disabling virecover by default

Hi, The way virecover currently works is problematic for security (see the recent nvi commits). I do believe it's possible to achieve the same with much lower risk by rewriting it, but as I don't plan on making these changes, I'd like to propose an alternative: disabling virecover by default. Th

Re: disabling virecover by default

i could use it to delete any file in /, and the hang is at boot.

Re: disabling virecover by default

as an alternative: virecover currently does the right thing if it is run unprivileged. adding a default .profile thing to execute it will achieve the same functionality without requiring any root privileges. additionally we will want to move recover dir to somewhere user-controlled.

Moving virecover to ~/

This is missing: - Moving virecover to /usr/bin - Regen'ing autoconf - Adding it to default ~/.profile - Removing virecover rc script ? test ? testcase Index: dist/common/options.c === RCS file: /cvsroot/src/external/bsd/nvi/dist/commo

Re: Moving virecover to ~/

I can make it a one time message (I thought it did this already, but guess not). I lose vi files by SSH problems, and I don't reboot the server, so I only found out about ancient virecover'd files a few months later.

locale aliases, and new gettext.m4

Hi folks. An up to date gettext.m4 is failing for lacking _nl_expand_alias. This means NLS is being disabled on netbsd for many packages, and not on illumos or linux, which is very annoying to handle in pkgsrc. I have no strong opinions on locale aliases, but we may want to do something about thi

redundant namespacing of standard c functions

Hi, we produce suboptimal code because e.g. isinf and isnan are namespace guarded, we define a __isnan instead, and use macros to rename. this disallows compilers from optimizing the function with a builtin, which saves at least the function call. can we as a policy have symbols for all the stand

Re: redundant namespacing of standard c functions

most of libm is type-generic, though I guess isinf/isnan are the ones people actually use as such.

Re: redundant namespacing of standard c functions

OK, I see your point. it would take really long to find out you are using the wrong isnan. I guess I could provide an inline implementation using the builtin.

hiding sh stderr

what's the way to do this? I forgot and didn't re-find the conversation. $ nonexistent 2>/dev/null nonexistent: not found (I'd like to apply PR 52684 but this is making it annoying)