Hello -
netstat -P now requires kern.allowkmem to be set.
Index: netstat.1
===
RCS file: /cvs/src/usr.bin/netstat/netstat.1,v
retrieving revision 1.79
diff -u -p -r1.79 netstat.1
--- netstat.1 1 Sep 2016 14:20:13 - 1.79
On Wed, Oct 12, 2016 at 01:03:10AM +0200, Theo Buehler wrote:
> $ .include \ > Makefile
> $ ktrace make -t obj
> touch _SUBDIRUSE
> Abort trap (core dumped)
> $ kdump | tail -4
> 89292 make CALL utimes(0x199a52c6c90,0)
> 89292 make PLDG utimes, "fattr", errno 1 Operation
$ .include \ > Makefile
$ ktrace make -t obj
touch _SUBDIRUSE
Abort trap (core dumped)
$ kdump | tail -4
89292 make CALL utimes(0x199a52c6c90,0)
89292 make PLDG utimes, "fattr", errno 1 Operation not permitted
89292 make PSIG SIGABRT SIG_DFL code <1852990836>
89292
Hi,
Theo de Raadt wrote on Tue, Oct 11, 2016 at 01:35:34PM -0600:
> jca@ wrote:
>> Jan Stary writes:
>>> The diff below makes head(1) recognize `-'
>>> as a name for the standard input,
>>> as many other utilities do.
>> Makes sense to me. The following points could be improved
On Oct 06 12:46:21, s...@stsp.name wrote:
> Disable the detailed fatal firmware error log in iwn(4) by default.
These are my iwm errors of today
on a Dell Latitude E5570.
Oct 11 16:26:56 dell /bsd: iwm0: fatal firmware error
Oct 11 16:26:56 dell /bsd: iwm0: device timeout
Oct 11 16:26:56 dell
On Oct 11 13:35:34, dera...@openbsd.org wrote:
> This is command used in scripts. Scripts are often portable. If one
> operating system has an extension, but others don't, then those
> scripts become unportable to use use of these extensions.
GNU head(1) has it, Solaris does not.
(I don't have
On Oct 11 21:27:54, j...@wxcvbn.org wrote:
> Jan Stary writes:
>
> > The diff below makes head(1) recognize `-'
> > as a name for the standard input,
> > as many other utilities do.
>
> Makes sense to me. The following points could be improved IMO:
Updated diff below.
> -
On Fri, Oct 07, 2016 at 06:02:35PM +0200, Mark Kettenis wrote:
> > It seems there are still some leftovers from the zaurus port removal.
> >
> > Comments? OK?
>
> Not ok. This is support for the zaurus as a usb device attached to an
My mistake, thanks for the clarification.
> OpenBSD
> On 2016/10/11 13:35, Theo de Raadt wrote:
> > > Jan Stary writes:
> > >
> > > > The diff below makes head(1) recognize `-'
> > > > as a name for the standard input,
> > > > as many other utilities do.
> > >
> > > Makes sense to me. The following points could be improved IMO:
>
On 2016/10/11 13:35, Theo de Raadt wrote:
> > Jan Stary writes:
> >
> > > The diff below makes head(1) recognize `-'
> > > as a name for the standard input,
> > > as many other utilities do.
> >
> > Makes sense to me. The following points could be improved IMO:
> > - using
> Theo de Raadt:
> > You might not like it. But the ship sailed. It's too bad you didn't
> > invent this stuff.
>
> As I said, it's convenient for me. Maybe also for someone else. This is
> all I care about.
You'll break other people's compatility without a thought.
You only care about
Theo de Raadt:
> You might not like it. But the ship sailed. It's too bad you didn't
> invent this stuff.
As I said, it's convenient for me. Maybe also for someone else. This is
all I care about.
--
Ivan Markin
> >> > Yeap, there is a problem with verifying uncommented signatures on
> >> > current signify(1). I don't care. And it's okay if someone does - I've
> >> > just put my two cents.
> > they don't need to be verified. They are informational.
>
> Okay, I meant signified files without a comment
> Theo de Raadt:
> >> > Yeap, there is a problem with verifying uncommented signatures on
> >> > current signify(1). I don't care. And it's okay if someone does - I've
> >> > just put my two cents.
> > they don't need to be verified. They are informational.
>
> Okay, I meant signified files
Theo de Raadt:
>> > Yeap, there is a problem with verifying uncommented signatures on
>> > current signify(1). I don't care. And it's okay if someone does - I've
>> > just put my two cents.
> they don't need to be verified. They are informational.
Okay, I meant signified files without a comment
> Theo de Raadt:
> > I've pointed out that people identify the purpose of the file in
> various ways.
> > You wish to basically throw that out?
>
> All I say is that file(1) is unreliable by design.
You didn't continue reading. And you persist in not going back.
> > Well I don't see any need
Theo de Raadt:
> I've pointed out that people identify the purpose of the file in
various ways.
> You wish to basically throw that out?
All I say is that file(1) is unreliable by design. And I don't think one
needs to care about it too much just because someone got used to it.
Personally I
> Jan Stary writes:
>
> > The diff below makes head(1) recognize `-'
> > as a name for the standard input,
> > as many other utilities do.
>
> Makes sense to me. The following points could be improved IMO:
> - using strcmp sounds cleaner than those char comparisons
> - I don't
Hi Theo,
Theo de Raadt:
> This seems misguided. We have a horrible program called "file", but
> in general people identify what a file is what what purpose it serves
> not just by the filename, but also by how it starts. The "untrusted
> comment" has become the way to identify a signify file.
Lawrence Teo writes:
> This imports pcap_set_immediate_mode() from mainline libpcap, which allows
> a libpcap-based program to process packets as soon as they arrive.
>
> ok?
Looks fine to me, ok jca@
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524
Hi,
Jan Stary wrote on Tue, Oct 11, 2016 at 11:12:00AM +0200:
> As /var/tmp is a link to /tmp,
> can we have /tmp as the default in sort(1)?
That's OK schwarze@ if somebody wants to commit.
POSIX doesn't restrict us here.
Yours,
Ingo
> Index: file.c
>
On Oct 11 15:37:03, schwa...@usta.de wrote:
> > and change /var/tmp to /tmp.
>
> No, according to file.c, the program still writes to /var/tmp,
> not to /tmp. Before changing that in the manual, we would have
> to change it in the code.
I sent that in a separate email;
this is a leftover,
>
>
>
> Here they manually encode the opcodes of five special debugging
> instructions for the MSIM MIPS simulator (these instructions are not
> part of the standard MIPS ISA, thus the assembler does not know them)."
>
> How the OpenBSD developers solve problems that are not resolved by
>
On Tue, Oct 11, 2016 at 04:29:24PM +0200, Imre Vadasz wrote:
> Hi,
>
> The sc->sc_uc.uc_intr flag isn't getting reset to 0 in
> iwm_load_firmware_8000(), so the
> /* wait for the firmware to load */
> for (w = 0; !sc->sc_uc.uc_intr && w < 10; w++) {
> err =
It has come to my attention the following:
"The only case where you have to resort to writing hex code manually
is when the assembler cannot output the desired code for some reason.
If I recall correctly, there is only one such case in the HelenOS
sources:
#define ___traceon() asm volatile (
Hi,
The sc->sc_uc.uc_intr flag isn't getting reset to 0 in
iwm_load_firmware_8000(), so the
/* wait for the firmware to load */
for (w = 0; !sc->sc_uc.uc_intr && w < 10; w++) {
err = tsleep(>sc_uc, 0, "iwmuc", hz/10);
}
loop is immediately aborting on
Hi,
Jan Stary wrote on Mon, Oct 10, 2016 at 10:10:00PM +0200:
> With the embedded cp.c and rm.c,
> the pathnames of "/bin/cp" and "/bin/rm" are not needed.
True.
I tested the following patch with "make build" and "make release"
on amd64, to make sure that no reacharound or miniroot magic
peeks
On Mon, Oct 10, 2016 at 09:53:55PM +0200, Martijn van Duren wrote:
> Hello tech@,
>
> As reported and fixed by pfg@freebsd.
> Fixes the following case:
> % echo z | gsed -n -e 's/^a*/b/2p'
> # empty -- correct
> % echo z | sed -n -e 's/^a*/b/2p'
> z # incorrect
>
> Fix in FreeBSD r302973
>
>
Hi,
Jan Stary wrote on Tue, Oct 11, 2016 at 11:26:50AM +0200:
> Feeling encouraged by Ingo's ok to remove locale from cp/rm,
> here's a diff that removes the locale stuff we don't actually do
> from the code and documentation of sort(1). Leave just LC_CTYPE
You removed that too, but that's OK
The diff below makes head(1) recognize `-'
as a name for the standard input,
as many other utilities do.
Jan
Index: head.1
===
RCS file: /cvs/src/usr.bin/head/head.1,v
retrieving revision 1.23
diff -u -p -r1.23 head.1
---
On Tue, Oct 11, 2016 at 12:33:59PM +0200, Otto Moerbeek wrote:
> On Sat, Oct 08, 2016 at 06:40:00PM +0200, Otto Moerbeek wrote:
>
> > Hi,
> >
> > avoid recomping the offset by storing it in the chunk info, ok?
>
> anyone?
Makes sense and I've been running this on my main laptop since Saturday.
Hello tech@,
As reported and fixed by pfg@freebsd.
Fixes the following case:
% echo z | gsed -n -e 's/^a*/b/2p'
# empty -- correct
% echo z | sed -n -e 's/^a*/b/2p'
z # incorrect
Fix in FreeBSD r302973
OK?
martijn@
Index: process.c
The -q flag for the command in a crontab(5) entry was introduced in revision
1.8 of src/usr.sbin/cron/entry.c back in 2001, but never documented.
(Sorry, I'm no hero with mdoc, so not sure if the markup is correct.)
Wouter
Index: usr.sbin/cron/crontab.5
On Tue, Oct 11, 2016 at 12:06:46AM +0200, Mike Belopuhov wrote:
> On Fri, Oct 07, 2016 at 20:48 +1000, David Gwynne wrote:
> > On Thu, Oct 06, 2016 at 12:13:20PM +0200, Mike Belopuhov wrote:
> > > m_pullup will always get a new mbuf and on
> > > strict alignment architectures you will always do a
On Sat, Oct 08, 2016 at 06:40:00PM +0200, Otto Moerbeek wrote:
> Hi,
>
> avoid recomping the offset by storing it in the chunk info, ok?
anyone?
>
> -Otto
>
> Index: stdlib/malloc.c
> ===
> RCS file:
Feeling encouraged by Ingo's ok to remove locale from cp/rm,
here's a diff that removes the locale stuff we don't actually do
from the code and documentation of sort(1). Leave just LC_CTYPE
which determines isblank() and case conversions.
Annotate a missed -z flag while there,
and change /var/tmp
On Oct 11 10:31:38, schwa...@usta.de wrote:
> > cp(1) and rm(1) call setlocale(LC_ALL, "") but mv(1) does not.
> > Why do they do that, and why mv doesn't?
>
> That is useless and wasteful.
>
> I think it comes from a time when people still thought that doing
> more and more and more might bring
Hi,
Jan Stary wrote on Tue, Oct 11, 2016 at 07:53:23AM +0200:
> cp(1) and rm(1) call setlocale(LC_ALL, "") but mv(1) does not.
> Why do they do that, and why mv doesn't?
That is useless and wasteful.
I think it comes from a time when people still thought that doing
more and more and more might
mv's copies of cp.c and rm.c were imported about 10 months ago
so that mv can avoid the fork+exec; instead, mv just calls
the relevant cp/rm code itself.
What was the motivation for that? Was that a step needed
to have a stricter pledge() for mv (no forking and execing)?
Currently, mv does not
39 matches
Mail list logo