> > If we do not hear from you, we will assume that you have no objection.
>
> So, they will claim that, by not responding, the recipient agreed.
>
> Some jurisdictions I am aware of accept verbal contracts or this kind
> of written contracts, since civil proceedings will not be held up to a
> hi
> So did anyone who replied with "NO" get a followup to "reconsider"?
So far, everyone who says no is getting a mail from Rich Salz.
So did anyone who replied with "NO" get a followup to "reconsider"?
I only "contributed" some doc fixes, so my "vote" doesn't really
mean much.
I am mailing tech@openbsd.org (and thereby, the greater community
who's email addresses may have changed) to inquire whether it is OK to
change the version of gcc 4.2.1 in our source tree to from GPL to the
ISC license.
This licence improvement will remove the last bits of ambiguity about
access t
...
> If we do not hear from you, we will assume that you have no objection.
So, they will claim that, by not responding, the recipient agreed.
Some jurisdictions I am aware of accept verbal contracts or this kind
of written contracts, since civil proceedings will not be held up to a
high standa
On Thu, Mar 23, 2017 at 17:48 Bob Beck wrote:
> Honestly, anyone who gets one of these should say no
>
> what would you all think if people quietly took derived works of software
> licensed under one license and took silence as assent to relicense
>
> Does this mean that with an unanswered email
Honestly, anyone who gets one of these should say no
what would you all think if people quietly took derived works of software
licensed under one license and took silence as assent to relicense
Does this mean that with an unanswered email i can now release my re
licensed as ISC version of gcc? o
So the diff below is my take on improving the arm64 pmap. It assumes
we'll only ever run on CPUs that implement the full 16-bit ASID size.
In that case we have 64k of ASIDs available, hich is way larger than
the number of processes, and therefore pmaps, that can exist on an
OpenBSD system. Our am
On Thu, Mar 23, 2017 at 10:07:43AM -0600, Todd C. Miller wrote:
> From FreeBSD, POSIX has identical wording.
>
> Alternately, we could add an extra EACCESS entry similar to what
> exists in open(2). I'm happy with either approach.
OK natano@. I think using one entry is fine in this case as both
On Wed, Mar 22, 2017 at 01:32:09PM +0100, Patrick Wildt wrote:
>
> apparently the "create_size" option does currently not work. This is
> because the strsuftoll() function uses "long long" compares which limits
> the positive maximum to LLONG_MAX. Unfortunately the maximum is always
> set to ULL
> > The start suggests they want to privately collect sufficient consensus
> > to pass their agenda. They appear to be considering all actions in
> > the tree (including mine) on equal grounds.
>
> I already sent them a clear "NO, i explicitly object to relicensing
> any of my contributions."
>
Have Atheros AR9280+AR7010 USB stick athn(4).
Long ago I tested it with OpenBSD 5.6 in Host AP mode 5GHz band, it does
not work as AP but successful in BSS in both supported bands.
On OpenBSD 6.0 situation is different. It is relatively stable in AP
mode, but don't work BSS in 2.4GHz band. On Open
> > The last sentence suggests they don't care at all about the rights of
> > the authors.
>
> I also sent them a separate mail stating that i strongly suspect
> that last sentence to be grossly illegal in almost any jurisdiction.
Of course: Lack of consent is not equal to consent.
Hi Theo,
Theo de Raadt wrote on Thu, Mar 23, 2017 at 10:18:26AM -0600:
> Lots of people have been receiving emails like the one below.
>
> They have never asked the community of authors what they want.
>
> I think OpenSSL are using a github "garbage-in / garbage-out" style of
> process. Feel f
Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650
chipset with run driver on OpenBSD 6.0-stable with all the latest source
tree patches installed.
Just after I've added MT7650 by patching files listed below and
recompiled the kernel the USB stick shows its identities as:
run0
Lots of people have been receiving emails like the one below.
They have never asked the community of authors what they want.
I think OpenSSL are using a github "garbage-in / garbage-out" style of
process. Feel free to dig into what they think I am author of, and
why.
The start suggests they wan
>From FreeBSD, POSIX has identical wording.
Alternately, we could add an extra EACCESS entry similar to what
exists in open(2). I'm happy with either approach.
- todd
Index: lib/libc/sys/mkdir.2
===
RCS file: /cvs/src/lib/libc/sys
Hi,
on some machines i saw some unknown enhanced capabilities. After
looking into it i saw that
on some intel chipsets there actually is a capability with id 0x0.
This capability contains some
registers of the Advanced Error Reporting Capability but not all of
them. I guess intel choose
0x0 instea
i never was happy with that anyway. ok
Florian Obser(flor...@openbsd.org) on 2017.03.23 12:04:56 +:
>
> Prosody starts up as _prosody so key and cert are owned by
> that user, which is perfectly valid.
> Also "current user" will always be root anyway.
>
> OK?
>
> diff --git parse.y parse.y
ok
Florian Obser(flor...@openbsd.org) on 2017.03.23 12:02:52 +:
> ... the parser will bomb out anyway
>
> OK?
>
> diff --git main.c main.c
> index dde8e8b638e..4f977451bbc 100644
> --- main.c
> +++ main.c
> @@ -85,6 +85,9 @@ main(int argc, char *argv[])
> goto usage;
>
Prosody starts up as _prosody so key and cert are owned by
that user, which is perfectly valid.
Also "current user" will always be root anyway.
OK?
diff --git parse.y parse.y
index 1595b52a752..6ee026c2427 100644
--- parse.y
+++ parse.y
@@ -1034,10 +1034,6 @@ conf_check_file(char *s, int dontsta
... the parser will bomb out anyway
OK?
diff --git main.c main.c
index dde8e8b638e..4f977451bbc 100644
--- main.c
+++ main.c
@@ -85,6 +85,9 @@ main(int argc, char *argv[])
goto usage;
}
+ if (getuid() != 0)
+ errx(EXIT_FAILURE, "must b
> Date: Thu, 23 Mar 2017 14:34:48 +1100
> From: Jonathan Gray
>
> Backport a change to add "(compatible with GNU linkers)" to the lld
> version output to avoid having to regenerate a large number of configure
> scripts.
>
> https://reviews.llvm.org/D31199?id=
> http://llvm.org/viewvc/llvm-projec
23 matches
Mail list logo
