Edgar Fuß writes:
>> If you are mounting /usr from NFS, then it belongs in
>> critical_filesystems_remote.
> It's there by default and starting mdnsd fails because it's started earlier.
I think there are daemons that depend on critical_filesystems_remote and
perhaps this should be adjusted. Tha
Martin Husemann writes:
> On Wed, May 21, 2025 at 05:30:11PM +0200, Edgar Fuß wrote:
>> > If you have /usr on a separate partition, you need to add it to
>> >
>> >critical_filesystems_local
>> >
>> > (see rc.conf(5)).
>> Where exactly does it say that?
>
> Not explecitily, I was more referi
Martin Husemann writes:
>> Note that we sometimes use an explicit compression method elsewhere
>> in the build (eg compressing kernels) that might differ from the
>> compression method for sets.
>
> Indeed, and also some of the compression levels must be high (or used to
> be, maybe the split of
Taylor R Campbell writes:
> What you've done is fine, but what I do -- and what I suggest everyone
> do, though we don't have any mandatory rule -- is:
Yeah, I realize that filing a PR and making the test xfail would be
nicer, but my question -- which you answered was about whether the
corner-cu
Robert Elz writes:
> Date:Tue, 24 Sep 2024 12:56:49 +0200
> From:
> Message-ID:
>
> | The present patch does two things:
> |
> | 1) Set, by default, the maximum of bytes read, in every case, as being
> | LINE_MAX (the maximum number of bytes in a line in a te
I too am ok with ed(1), which is IIRC what you had in Sixth Edition
before the newfangled ex/vi showed up. I actually prefer it as simpler.
These days, I tend to ed(1) for really quick things or bad situations,
and emacs for everything else.
What I find broken is that various programs have EDITO
Roland Illig writes:
> The first commit demonstrates the buggy state by having a test that
> technically succeeds but has lots of FIXME comments in all the places
> that are wrong, already stating what is expected after the bugfix.
>
> The second commit fixes one of the bugs and updates the tests
I have found a serious bug in reqmuo(3), and a fix in FreeBSD, validated
by regression tests in proj and a hand-written test. The problem exists
in current and 10, and surely in 9 but I haven't checked.
We currently have no remquo test. I've written one, stealing from
tests/lib/libm/t_sin, and i
Robert Elz writes:
> Date:Sun, 15 Sep 2024 19:53:54 -0400
> From: Greg Troxel
> Message-ID:
>
> | C99/POSIX define remquo:
> | https://pubs.opengroup.org/onlinepubs/9799919799/functions/remquo.html
>
> I know really nothing about any o
FreeBSD has a change, which resolves the sign of q bug (1 vs -1):
However, it still has q being 0 when it should be -2^n.
The patch at end causes
my remquo test programs
proj's regression tests
to all pass.
The first three hunks are from FreeBSD:
https://cgit.freebsd.org/src/commit/lib/ms
C99/POSIX define remquo:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/remquo.html
The basic idea is that return value r is a remainder, and in q is stored
the low-order k bits of the quotient, but with q having the same sign as
the quotient.
The point is to reduce possibly large
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 t
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.
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:
/usr/pkg/lib/python3.11
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 t
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 not
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 ad
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 non
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 certct
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
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 i
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
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 tr
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 r
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 applications
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 implementation
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
> do
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 manuall
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
>
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 connection
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 particular Aman
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
https://www.iana.org/assignments/service-names-port-numb
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 inverse
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 i
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 surp
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
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 shut
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
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 betwee
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
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.
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
> i
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
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
discussion/consen
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 f
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 either,
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 I
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 loca
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, and i
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 t
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 ther
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
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 vari
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
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 per-mou
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.
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
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 nor
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 r
g on merging 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
>>
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-stat
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 -D_F
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, thi
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.
>>
>>
>> https://us-east.manta.joyent.com/pkgsrc/publi
David Holland writes:
> On Fri, Oct 01, 2021 at 07:54:18PM -0400, Greg Troxel wrote:
> > So, if it happens that way, then it really does not matter from the
> > NetBSD side if pkgsrc moves to 3 this branch, or adds 3 as an option
> > alongside 1.1.1, or doesn'
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 openssl.old.
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 ha
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 comm
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 relea
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,
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 ha
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
> admini
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 you
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
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
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 g
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. prop
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 seems
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
>> detac
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
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 1007
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 /usr/pkgsrc/textproc/py-sphinxcontrib-serial
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
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 for
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 e
# 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
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 wit
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 clearing /va
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
>>
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 fi
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, but
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.
>
>
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
t
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? Or
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 reason
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?
>>
>> --
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
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
Artturi Alm writes:
> my sensor does fill ->value_cur with mPa, so pressure does fit into the
> "everything else"-else{} with ->cur_value / 100.0 for printout in kPa.
Until very recently I had never seen pressure in kPa. For atmospheric
pressure, the standard unit seems to be hPa. I realiz
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
> y
1 - 100 of 111 matches
Mail list logo
