Re: numpy failure on netbsd-9, rintl

It looks like this is more ok than I thought. I don't find anything different from 10 to current. Looking at 9 to current and pruning diff noise, there are a number of additional aliases in 10. It seems that there are two strategies for this.Can we pick one and document it? It seems like

Re: numpy failure on netbsd-9, rintl

I extracted defined symbols ending in l from libm.so. Diffing from netbsd-9 amd64 to netbsd-9 earmv7hf-el -__ieee754_sqrtl +_fmal +_frexpl +_rintl -fabsl -nearbyintl -nexttowardl I suspect the + is my local changes and strong vs weak aliases.

numpy failure on netbsd-9, rintl

As background, I am using numpy, not really intentionally, but because homeassistant depends on it indirectly, as does gpsd via py-matplotlib. I have a RPI3, netbsd-9, and pkgsrc 2023Q3. Importing numpy results in the following error (full output at end): ImportError:

Re: new certificate stuff

Taylor R Campbell writes: > The critical part I had missed is that certctl can claim _either_ a > directory it has already claimed, _or_ an empty directory, so it works > for new installations and to update pristine but old installations. Sorry, I should have said that out loud; I was thinking

Re: new certificate stuff

The other alternative is to decide that we are going to do unsafe things and to put it super loudly in the release notes that any sysadmin-configured trust anchors will be blown away. Compared to pkgdb, I expect that most admins both have backups, and have such certs elsewhere, and recovery is

Re: new certificate stuff

Taylor R Campbell writes: > How is using /etc/openssl/certs/.certctl as the token different from > using /etc/openssl/certs.conf as the token? Because normal updates merge etc in various ways, and if certs.conf comes along with that (because it is in etc.tgz) then that is automatic and not an

Re: new certificate stuff

Taylor R Campbell writes: > Currently, if /etc/openssl/certs.conf doesn't exist, `certctl rehash' > (the crux of `postinstall fix opensslcerts') will print an error > message and then exit with status 0. This combination is a bug -- > need to think a bit about it, but probably better to exit

Re: new certificate stuff

Manuel Bouyer writes: >> The etc.tgz set, however, will have /etc/openssl/certs.conf. So if >> you naively unpack etc.tgz, `postinstall fix' will clobber your >> /etc/openssl/certs directory. > > As it will clobber others /etc/ files, so that's fine. Maybe this is too much, but perhaps

Re: [PATCH] HTTPS/TLS CA certificates in base

With the certctl patch on the table, I think it will be possible for anybody who wants to install mozilla-rootcerts change certctl.conf to point to it and get what abs@ wants for updates (which is different that everybody getting it by default). I am now in the "this is not really different

Re: [PATCH] HTTPS/TLS CA certificates in base

Taylor R Campbell writes: > This is exactly what you get if you populate a directory > /usr/local/mycerts with the .pem certificates you want and then add > the line > > path /usr/local/mycerts > > to /etc/openssl/certs.conf, alongside the line > > path /usr/share/certs/mozilla/server > > which

Re: Android-like NetBSD

Chris Hanson writes: > On Aug 5, 2023, at 12:11 PM, Greg Troxel wrote: >> >> As for 'external SDK', that would be "install some other OS and cross >> build", but when you cross build for android or ios, you do that from a >> system which is a full install.

Re: [PATCH] HTTPS/TLS CA certificates in base

Overall I like this. Thank you for listening to the various comments and coming up with a mechanism that is configurable for almost all possible policies that have been expressed. I'd like to see three things handled (which might be already): 1) a way for a user to install a CA cert (as a

Re: epoll exposure

Mouse writes: >> The problem is third-party software assumes epoll == Linux, > > Software that makes stupid assumptions will never go away. > > Is it better to work around it (not ship epoll.h), or to get it fixed > (report it upstream as the bug it is)? I could argue that either way. I don't

Re: epoll exposure

Jonathan Perkin writes: > * On 2023-08-13 at 18:10 BST, Tobias Nygren wrote: > >>On Sat, 12 Aug 2023 19:21:06 -0400 >>Christos Zoulas wrote: >> >>> I really want to understand what's going on here (why do we think that >>> our epoll implementation is broken in a way that will affect

Re: epoll exposure

nia writes: > On Fri, Aug 11, 2023 at 06:52:41PM -, Christos Zoulas wrote: >> I see that you removed with without further discussion which is not the >> way we do things on NetBSD. Do you have an example where the epoll emulation >> breaks, because either forking matters or the

Re: Android-like NetBSD

Bruno Melo writes: > Is it possible install a minimum NetBSD with no manpage, no compilers > and toolchain and provide all these stuff as an external SDK and then > being able to build pkgsrc software using this external SDK? I think > this is what commercial systems like Android and iOS are >

Re: Architecture neutral packages (mozilla-rootcerts-openssl)

David Brownlee writes: Please drop tech-pkg from this. This is a base system issue. > Another unmentioned local elephant is installations which do not use > sysinst (though I'm happy to suggest we specifically exclude those for > the first pass). People who do things manually do things

Re: /etc/services losses

Taylor R Campbell writes: > `smtp(s)' and `submission(s)' are subtly different protocols and > should not be aliases: > > - smtp(s) is for MTA<->MTA exchange of fully formed internet mail > messages with complete headers. > > - submission(s) is for an MUA to submit new messages, which may not

Re: /etc/services losses

Mouse writes: >> I'm also not sure it matters if a TLS session is preceded by the ten >> bytes `STARTTLS\r\n' on the wire or not. > In theory, it matters because the conversation is not conformant to the > protocol otherwise; a receiver-SMTP would be entirely justified in > dropping a

Re: /etc/services losses

Hauke Fath writes: > On Mon, 31 Jul 2023 18:20:40 +0200, Steffen Nurpmeso wrote: >> Greg Troxel wrote in : >> |Hauke Fath writes: >> |> attached is a diff with services that for some reason or other got >> |> dropped from /etc/services - in

Re: /etc/services losses

Hauke Fath writes: > attached is a diff with services that for some reason or other got > dropped from /etc/services - in particular Amanda* and AppleTalk. The really big question here is the relationship between our /etc/services and

Re: ipsec: slight inconsistency

tlaro...@polynum.com writes: > The two functions are said "inverse" from each other but the problem is > that if one gives a delimiter to ipsec_dump_policy(3) that is neither > a blank nor a new line, the string obtained can not be an input > to ipsec_set_policy(3). So there are not really

missing long double functions in netbsd-9

I'm using various things that uses numpy. I have had a problem with long double versions of log functions on x86, and with other functions on arm. I don't actually need these functions, but numpy wraps them and thus the shlib won't load. The numpy package build succeeds. I think it's a bug by

Re: shutdown sequence and UPS poweroff

David Brownlee writes: > If only we had a reliable way to remount filesystems from read-write > to readonly after flushing data, that could be an option on shutdown, > then the ups command could be triggered with no writable filesystems > :-P That is what ought to happen, yes. I am sort of

Re: shutdown sequence and UPS poweroff

David Holland writes: > On Fri, Jan 06, 2023 at 10:13:36AM -0500, Greg Troxel wrote: > > Does it seem reasonably safe that mountall through root will be fast, < > 10s? > > We've been seeing scattered reports of unmounting taking fast amounts > of time, particularly on n

shutdown sequence and UPS poweroff

Currently, pkgsrc/sysutils/ups-nut works well on NetBSD (somewhat shaky testing on some points, but my current belief): UPS is monitored and data is available configuration of UPS params messages on loss of comms and restore messages on transition to battery and return initiation of

Re: mkdir -p, autoconf

ignat...@cs.uni-bonn.de writes: > On Fri, Oct 07, 2022 at 01:25:57PM -0400, Greg Troxel wrote: > >> Sorry, I meant not documented in mkdir(1). > > "Create intermediate directories as required. ... > Do not consider it an error if the argument directory alread

Re: mkdir -p, autoconf

ignat...@cs.uni-bonn.de writes: > hi, > > On Fri, Oct 07, 2022 at 06:40:19AM -0400, Greg Troxel wrote: >> >> 1) Is NetBSD's mkdir -p safe, in that it is immune to >> check for dir >> call mkdir(2) which fails because another mkdir did it in

mkdir -p, autoconf

I am chasing a bug in the postgis install phase, found by a bulk build, while it ran fine on my system -- which happened to have coreutils. There are a lot of moving pieces in postgis's install becaues it's autoconf *and* pgxs, but there's one aspect that I want to bring up here. autoconf has a

Re: [Christos Zoulas] CVS commit: src/usr.bin/ftp

I just sent a big note about the default trust anchor issue to tech-security. Please follow up there about that, vs this specific ftp change.

Re: [Christos Zoulas] CVS commit: src/usr.bin/ftp

Martin Husemann writes: > On Fri, Sep 02, 2022 at 06:23:48PM +0300, Christos Zoulas wrote: >> I think we should be installing the anchors by default. I also think >> that people think that https gets validated by default. > > I agree. The problem is that we need to suply anchors now with new >

Re: [Christos Zoulas] CVS commit: src/usr.bin/ftp

Christos Zoulas writes: >> On Sep 2, 2022, at 3:57 PM, Greg Troxel wrote: >> >> Did I miss discussion on this? I am getting the impression that we now >> have defaults: >> no trust anchors installed >> require verification >> >> whi

[Christos Zoulas] CVS commit: src/usr.bin/ftp

Did I miss discussion on this? I am getting the impression that we now have defaults: no trust anchors installed require verification which really doesn't make sense. If I am following correctly this is a major behavior change in a controversial area, which isn't ok without

Re: fidocrypt(1): `storing' cgd keys on U2F/FIDO keys

Taylor R Campbell writes: >> Date: Sat, 6 Aug 2022 18:47:47 -0400 >> From: Gabriel Rosenkoetter [comments reordered] >> I guess my follow-up Devil's advocacy question would be: why does this >> need to be in base, rather than provided via ports? > > cgdconfig runs early at boot before most

Re: disable HPN in sshd for the -10 branch?

mlel...@serpens.de (Michael van Elst) writes: > Part of the HPN patches is to optionally strip encryption (and now even > integrity checks) for the data transfer. Doesn't fit into what > the OpenSSH people want, not even as an option. I would say that doesn't really fit with what we want

Re: disable HPN in sshd for the -10 branch?

nia writes: > I've heard some reports that the HPN-SSH patches to sshd are > not quite working as well as expected, with some users getting > mildly worse results. They're apparently supposed to improve > performance: > > https://www.psc.edu/hpn-ssh-home/ > > With "HPNDisabled" in sshd_config

Re: sysupgrade in src?

nia writes: > On Fri, Apr 15, 2022 at 01:20:04PM -0400, Greg Troxel wrote: >> Use of RCS IDs seems fragile/unsound in that you can't conclude from >> matching IDs that the files match, or really the other way around, given >> people storing sources in !cvs with local mod

Re: sysupgrade in src?

nia writes: > On Fri, Apr 15, 2022 at 08:05:54AM -0400, Greg Troxel wrote: >> To me, the right behavior is to know if each file in etc has been put >> there as a copy of a file that appeared in etc.tgz, and to change it to >> the new version without prompting if so

Re: sysupgrade in src?

I don't object at all, but I want to point out etcmanage, in pkgsrc, (which needs xz help), and does the same thing. A more or less fatal downside is that it is in perl, but I think it has very good semantics about etc merging. I have not kept up with the other methods, but in the past I found

Re: to bump or note to bump

Brett Lymn writes: > So, the point of all this blather is even though there have been no > interface changes as a result of my work there is the potential for a > significant visual change. Should I mark this with a libcurses major > bump? I don't think it necessary but I am putting it out

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Taylor R Campbell writes: >> Date: Thu, 17 Mar 2022 08:32:40 -0400 >> From: Greg Troxel >> >> Simon Burge writes: >> >> > 5. Move all local mounts to /etc/rc.d/mountcritlocal (ala >> > FreeBSD) and possibly rename this to /etc/rc.d/mo

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Simon Burge writes: > Lots of interesting discussion! Thanks all. As a loud ranter I'll comment briefly but thanks for the summary and I think we're heading for a good place. > Broadly I think I can summarise to the following options: > > 1. The existing critical_filesystems_zfs rc.conf

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Brad Spencer writes: > Martin Husemann writes: > >> On Tue, Mar 15, 2022 at 08:30:11AM -0400, Greg Troxel wrote: >>> I still don't understand and object to this "zfs is special" notion. >> >> It is special because it just does not use /etc/fstab

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

I had another thought, which might very little work and make everybody happy: Add a variable zfs_critical, which if yes: zfs mount -a happens in mountcritlocal no: doesn't happen and maybe not set: zfs mount -a happens if root is zfs I think I prefer the

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Brad Spencer writes: >> But seriously, I think tsorting the filesystems is necessary, and then >> there's putting filesystems into one of >> >> required >> optional >> >> and then some sort of label for >> >> before-starting-networking >> after-networking-before-daemons >> >> and so on.

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Robert Elz writes: > So, add me to the list of people who'd like a "mount if possible" > switch, with nothing more than a boot warning if some of them cannot > be found at all, or have unfixable fsck issues. Agreed - that would be great. > I'd actually prefer even more - for most of those, if

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Brad Spencer writes: > The point is that by need /usr/sources has to be realized in the system > after / and /usr are available and right now those can't be a ZFS pool > themselves (well, /usr COULD be, but I can't really see how / could). > This, at least in my opinion, is not a complicated

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Paul Goyette writes: >> Do we have any valid need to have non-critical local filesystems? > > Well, I have a dedicated filesystem for builds, separate from my > OS. The /build happens to be my nvme SSD. > > Building (or being able to build) is not critical to having the > machine running (and

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

ng into main NetBSD sources soon. Very cool - I had no idea that was about to land. > Later, Greg Troxel wrote: > >> It makes sense to have a boolean "critical" property (the name you >> suggested is fine) for zfs volumes that specify a mount point, so that >> such vol

Re: math.h, copysign, visibility defines

Joerg Sonnenberger writes: > Am Thu, Feb 24, 2022 at 07:59:22AM -0500 schrieb Greg Troxel: >> >> I'm trying to build wip/ocaml on NetBSD 9 amd64 and came across: >> >> gcc -c -O2 -fno-strict-aliasing -fwrapv -pthread -Wall >> -Wdeclaration-after-statement

math.h, copysign, visibility defines

I'm trying to build wip/ocaml on NetBSD 9 amd64 and came across: gcc -c -O2 -fno-strict-aliasing -fwrapv -pthread -Wall -Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard -fno-tree-vrp -fPIC -ffunction-sections -g -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/include

Re: openssl 3

nia writes: > There are likely problems mixing different OpenSSL shared object > versions in pkgsrc, no? If you mean openssl 1.1.1 in base, and (eventually) 3 in pkgsrc, with /usr/lib/libopenssl.so.[1.1.1-version] /usr/pkg/lib/libopenssl.so.[3-version] and things in base linked with base,

Re: openssl 3

Reinoud Zandijk writes: >> My impression is that work to make things build with 3.0.0 is in >> progress, but that the fallout from a (not committed, in testing) switch >> is over 5000 packages. But I expect that will rapidly get better. >> >> >>

Re: openssl 3

chris...@astron.com (Christos Zoulas) writes: > My thoughts are: > - It is too late to put OpenSSL-3.0.0 un current, to become part of NetBSD-10. > - After the NetBSD-10 branch, I will move OpenSSL-1.1.1 to openssl.old and > import OpenSSL-3.0.0 in openssl. Every port will point to

Re: openssl 3

Martin Husemann writes: >> I don't know what you mean exactly. Certainly at some point pkgsrc >> builds on 9 will use pkgsrc openssl. Perhaps long before that. But I >> don't see how e.g. postfix in base is going to use pkgsrc openssl. > > Right, so the admin of an affected machine would

Re: openssl 3

Martin Husemann writes: > On Thu, Sep 30, 2021 at 08:44:22AM -0400, Greg Troxel wrote: >> What are people thinking about >> >> updating openssl to 3.0.0 in current > > Yes, someone(tm) should do that! Early to catch fallout quickly, but > we'd need commitmen

openssl 3

This is a software engineering question, not a security question and hence here. openssl 3.0.0 is out, and it has a lot of compat issues. I hear that openssl 1.1.1 only has two years of maintenance left. history: 8 was released in July 2018 and 9 in february 2020. At that pace, 10 will be

Re: Java servers and rc.d?

Paul Ripke writes: > Another thought: > Should _find_processes in /etc/rc.subr pay attention to a deamon's > configured user? I'm not quite ready to conclude that, but I agree that we should have a way that rc.d scripts for programs that use java can work correctly. > I run unifi from pkgsrc,

Re: inetd Enhancements Followup

James Browning writes: > maintainers at their own discretion. Some of you brought up the concern of > over-automating the system at the potential risk of the configuration system > becoming too opaque and administrators allowing packages to configure inetd > without their knowledge of what is

Re: inetd Enhancements

Mouse writes: > Of course, any setup can ultimately be understood. But the more > complexity there is, the harder that is to do; and the more automation > is provided by someone else, the more it encourages administration > without understanding - in extreme cases it actively obstructs >

Re: inetd Enhancements

Keep in mind as you consider "changing" rather than "extending" that there are many systems with existing files, and the NetBSD way is that if you upgrade the system to a new version, then as little breakage as possible should ensue. Yes, technically you should read all the release notes, and

Re: ssp, __strcpy_ck: just to be sure

tlaro...@polynum.com writes: > On Tue, Nov 17, 2020 at 10:16:47AM -0500, Greg Troxel wrote: >> >> tlaro...@polynum.com writes: >> >> > But then I realized that I have not changed the offending line: the >> > strcpy() call since there was no overflow pro

Re: ssp, __strcpy_ck: just to be sure

tlaro...@polynum.com writes: > But then I realized that I have not changed the offending line: the > strcpy() call since there was no overflow problem: it was doing inplace > rewrite, suppressing a prefix (doing basename(1) essentially). Not sure what "inplace" means, but it sounds like it runs

Re: Proposal to remove catman(8)

Kamil Rytarowski writes: > I wish good luck finding user-base/target-audience (if you like, in any > age) that relies on the slowest of slow hardware and cannot use anything > else to study the system documentation. You are missing the other larger point. It may well be that catpages should

Re: Proposal to remove catman(8)

Kamil Rytarowski writes: > I am surprised that the proposal to remove MK${FOO} is read as removal > of the Makefile conditionals and keep ${FOO} in the base. With that > bizarre interpretation the whole proposal renders into useless idea. > > I would be very surprised to interpret that e.g.

Re: Proposal to remove catman(8)

Kamil Rytarowski writes: > It's not a selling point to any regular user, born after A.D. 2000 to > optimize reading man pages. This ageist comment is offensive and not appropriate on NetBSD lists. It's also remarkably off base; the notion that most NetBSD users are less than 20 years old

Re: Proposal to import window(1) into the base

Tobias Nygren writes: > On Thu, 22 Oct 2020 17:12:39 +0200 > Kamil Rytarowski wrote: > >> I propose to import window(1) into the base. >> >> tmux is a similar program to tmux, but much simpler and traditional in >> the BSD environment. Personally I use tmux as a screen replacement for >>

Re: package build failures on netbsd-8 using nbtar, pax, bsdtar

Greg Troxel writes: > This is about a system with netbsd-8 built with sources updated on > 2020-02-14. > > I updated pkgsrc, and several sphinx packages are failing to build. > With help from adam@, I have narrowed it down to bad extraction from the > upstream tarball. &g

Re: package build failures on netbsd-8 using nbtar, pax, bsdtar

tlaro...@polynum.com writes: >> tar: File extended headers posix ustar archive. Extracting as plain files. >> Following files might be in the wrong directory or have wrong attributes. >> -- 1 root wheel156 Dec 31 1969 ././@PaxHeader >> -rw-r--r-- 1 502 staff

package build failures on netbsd-8 using nbtar, pax, bsdtar

This is about a system with netbsd-8 built with sources updated on 2020-02-14. I updated pkgsrc, and several sphinx packages are failing to build. With help from adam@, I have narrowed it down to bad extraction from the upstream tarball. The package is

Re: Expose max_align_t unconditionally

Kamil Rytarowski writes: > On 09.03.2020 20:05, Martin Husemann wrote: >> This is pretty stupid, but IMHO no big deal. We can >> > [...] >> - just not support (i.e. #error) on older C++ standard compiles > > There are still many programs in pkgsrc that set older C++ release. Some > of them are

Re: Expose max_align_t unconditionally

Michał Górny writes: > Given that Clang defaults to C++14 nowadays, I suppose it could be fixed > by finding old -std= and replacing it. I am not really following the issue, but I don't understand why what the default C++ sublanguage is matters. It would seem that behavior should be correct

Re: Solving the syslogd problem

Piotr Meyer writes: > On Wed, Jan 29, 2020 at 09:32:30PM +, Alexander Nasonov wrote: > [...] > >> I like it when fsck doesn't take ages to check /. With bigger /, >> it's going to be problematic. > > IMVHO moving /usr/bin, /usr/sbin and /usr/lib to / is reasonable, > and it will not lead to

remquo(3) issues

# summary (Note that unless you already understand remquo or you read the docs I am pointing to very carefully, this is not going to make a lot of sense.) While running tests for PROJ 6.3.0 (wip/proj) I got some failures. PROJ includes geodesticlib and has replacement code for C99-required math

wip/proj test failures, possible C99 math trouble

proj is a program/library for geographic coordinate transforms. There is a new version in wip/proj, 6.3.0. (This is not yet in pkgsrc proper because of compat issues with programs that depend on proj, but that's orthogonal to this message.) proj can use extra data files, but test vectors are

Re: stdio.h's P_tmpdir definition - make it /tmp?

u...@stderr.spb.ru (Valery Ushakov) writes: > Greg Troxel wrote: > >> It seems that long long ago, /tmp was small and on /, and /var was often >> bigger, and people used /var/tmp for larger stuff. Also I remember a >> notion of clearing /tmp on boot and not cleari

Re: stdio.h's P_tmpdir definition - make it /tmp?

Thor Lancelot Simon writes: > On Fri, Aug 30, 2019 at 02:40:06PM +1000, matthew green wrote: >> hi folks. >> >> >> a very long time ago in netbsd years tls@ patched GCC to use >> /tmp over /var/tmp, for the compiler temporaries. >> >> i tried to keep these patches, but they got lost at some

Re: More compatibility for refuse

co...@sdf.org writes: I too was not happy about the notion that librefuse should be deprecated. > librefuse is matching the newer FUSE APIs. it's not matching the older. > The filesystems want the older high-level API. I have looked into this slightly. I had the impression from the list that

Re: More compatibility for refuse

m...@netbsd.org (Emmanuel Dreyfus) writes: > wrote: > >> I'm just going to commit code without code review if all the responses >> are going to be "please don't work on X, work on Y instead". >> I am interested in librefuse because that's what gets used. > > Sure, go ahead for the short term,

Re: More compatibility for refuse

Taylor R Campbell writes: >> Date: Wed, 10 Apr 2019 19:50:02 + >> From: co...@sdf.org >> I'm just going to commit code without code review if all the responses >> are going to be "please don't work on X, work on Y instead". >> I am interested in librefuse because that's what gets used. > >

Re: More compatibility for refuse

co...@sdf.org writes: > No, upstream FUSE loves having every downstream filesystem get adjusted > whenever it decides an argument isn't useful any more. So you are proposing to provide more compat than mainstream fuse, and we would add a -D argument to packages that need it, on NetBSD only, and

Re: More compatibility for refuse

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) && (FUSE_USE_VERSION > 22) :-) Don't you need defined(FUSE_USE_VERSION) also?

Re: More compatibility for refuse

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" API). I am unclear on why, but my impression is that there are good

Re: More compatibility for refuse

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. >> >> You know we support vnilla libfuse through libperfuse, right? >> >> --

Re: Pressure sensors

Artturi Alm writes: > On Tue, Jan 01, 2019 at 12:03:31PM -0500, Greg Troxel wrote: >> So, I wonder why you are choosing kPa vs hPa, and if that choice ends >> up being a framework choice for everything. And how the rest of the >> world deals with this issue. > > By a

Re: Pressure sensors

Martin Husemann writes: > On Wed, Jan 02, 2019 at 06:38:21PM +, David Holland wrote: >> Most of the world uses millibars and occasionally labels them hPa. >> Since judging by the patch the framework isn't up to handling both, >> the best course is probably to use and label as millibars and

Re: Proposed modification to seq

Brian Ginsbach writes: > It has been a while since I wrote that code but my recollection is > that it isn't necessarily a bug. That GNU copied and changed the > meaning of -s (again provided my recollection is correct) isn't > surprising either. I'd need to dig back to see what GNU seq had 20 >

Re: Proposed modification to seq

a...@100acres.us writes: > The seq command behaves a little differently than I expect. I needed a comma > separated list of integers, but seq gave me this: > > $seq -s , 1 3 > 1,2,3,$ > > Notice the extra comma and no trailing return. The comma is troublesome for > my >From reading the man

Re: Moving telnet/telnetd from base to pkgsrc

Taylor R Campbell writes: > Given that a large fraction of respondents (though not all) indicated > that their primary use of telnet is to test reachability of a server > or manually enter SMTP or HTTP requests over the internet -- a use > which is adequately served by the much smaller and much

Re: Moving telnet/telnetd from base to pkgsrc

> What's the deal wiht IPSEC? The protoocol is called IPsec (and often miscapitalized), and our kernel option is IPSEC. > I've never used it, but I was under the impression it gives encryption > for free for things that otherwise don't have it. It provides confidentiality and data origin

Re: Moving telnet/telnetd from base to pkgsrc

Robert Elz writes: > It does no harm as it is, if you don't use the client, all it does is > occupy a couple of hundred blocks (nothing), the server is not > enabled by default, and it is even smaller. I agree. I use it often, to see if TCP ports are open and hand-type smtp or http. Another

tr -C and posix

Our tr, at least in 8, does not seem to implement the -C flag. Reading posix: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tr.html I am a bit lost in a twisty maze of "value" vs "character", that I expect has something to do with multibyte characters. Can anyone explain where

Re: Default PAGER -> less

co...@sdf.org writes: > I thought of making the default .profile snippet set PAGER=less. > thoughts? I tend to think we shouldn't have a default .profile at all. (I don't use the default file, and I don't set PAGER in my own files.) But I see that it contains only PATH. In general, I think

Re: Shipping SSL certificates in the base system

Benny Siegert writes: > The question of root certificates for OpenSSL in base came up recently > in pkgsrc. That got me thinking: why does NetBSD not come with a set > of certificates in the base system? The set that mozilla-rootcerts > delivers would be a reasonable thing