Re: UPDATE: usr.bin/less

2011-08-31 Thread william dunand
>> The version of less is in base is under a BSD equivalent license, the one >> you're updating us to is.. GPLv3. > Ah, nevermind. It's actually under a dual BSD-alike and GPLv3 license. Hmm. The version in base is actually dual licensed as well, (but GPLv2).

hide kernel threads in ps?

2011-08-31 Thread Uwe Stuehler
"Help! My Nagios checks failed." :) This fixes them by hiding kernel threads from ps output. I'd also like to show the main process ID in the PID column as otherwise there is no way of knowing which threads belong together. Likely struct kinfo_proc would need a change for that... Maybe in another

Re: hide kernel threads in ps?

2011-08-31 Thread Uwe Stuehler
- I missed usage(), pointed out by jmc - Sq macro in man page Index: bin/ps/ps.1 === RCS file: /cvs/src/bin/ps/ps.1,v retrieving revision 1.76 diff -u -p -r1.76 ps.1 --- bin/ps/ps.1 6 Jul 2011 21:42:11 - 1.76 +++ bin/ps/ps.1

Re: ksh history corruption

2011-08-31 Thread LEVAI Daniel
On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote: > On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote: > > I have had enough of corrupt ksh history so I had a look at the code to > > try to fix it. The magical code was very magical so I basically deleted > > most of it a

Re: dd(1) human-readable output

2011-08-31 Thread Thomas Pfaff
On Tue, 23 Aug 2011 19:36:53 + Grumpy wrote: [...] > > I'm unsure if we want to throw this into the wild, since this > > output behaviour is _old_. > > That's the point, exactly. People (well, scripts written by people) > depend on the dd report output format. > > > Now, a -h button or simil

Re: ksh history corruption

2011-08-31 Thread Marco Peereboom
On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote: > On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote: > > On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote: > > > I have had enough of corrupt ksh history so I had a look at the code to > > > try to fix it. The

Re: ksh history corruption

2011-08-31 Thread LEVAI Daniel
On Wed, Aug 31, 2011 at 06:57:34 -0500, Marco Peereboom wrote: > On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote: > > On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote: > > > On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote: > > > > I have had enough of corru

Re: ksh history corruption

2011-08-31 Thread Marco Peereboom
On Wed, Aug 31, 2011 at 02:13:19PM +0200, LEVAI Daniel wrote: > On Wed, Aug 31, 2011 at 06:57:34 -0500, Marco Peereboom wrote: > > On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote: > > > On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote: > > > > On Tue, Aug 30, 2011 at 11:11

Re: passing vlan priority tag through bridge

2011-08-31 Thread Peter Hallin
On 2011-08-28 02:16, Christiano F. Haesbaert wrote: > Heya, > > So here is a crude diff, the shiffting can be improved and if we wan't > this in the future we'll need a knob to enable "don't touch the > vlanprio thingy". > > Please it would be great if you can give this a spin Peter. I did some

cwm: WM_TRANSIENT_FOR hint support

2011-08-31 Thread Alexander Polakov
This diff moves dialogs, toolbars and such to the group of the main application window. Index: client.c === RCS file: /cvs/xenocara/app/cwm/client.c,v retrieving revision 1.86 diff -u -p -r1.86 client.c --- client.c14 Jul 2011 11:

Re: pflog shows 0.0.0.0.0 > 0.0.0.0.0

2011-08-31 Thread Henning Brauer
* Alexander Bluhm [2011-08-30 20:59]: > When pf_test_rule() is called for fragments that have not been > reassembled, the address copy is not done anymore. good catch, new diff below. > I think pf_setup_pdesc() should not call pf_test_rule() at all and > just fill the pd struct. indeed, the tes

Re: pflog shows 0.0.0.0.0 > 0.0.0.0.0

2011-08-31 Thread Alexander Bluhm
On Wed, Aug 31, 2011 at 05:02:01PM +0200, Henning Brauer wrote: > @@ -5679,6 +5665,13 @@ pf_setup_pdesc(sa_family_t af, int dir, > m, *off, pd, a, ruleset, *hdrlen); > if (*action != PF_PASS) > REASON_SET(reason,

Re: CVS: cvs.openbsd.org: src

2011-08-31 Thread Gilles Chehade
On Wed, Aug 31, 2011 at 12:56:30PM -0600, Gilles Chehade wrote: > > Log message: > add support for per-line DATA callbacks, this allows filters to take their > decisions *while* the message is being received by the client. > Until filters are enabled, this should not impact anyone ... however it

Re: ksh history corruption

2011-08-31 Thread Marco Peereboom
On Wed, Aug 31, 2011 at 07:20:42AM -0500, Marco Peereboom wrote: > On Wed, Aug 31, 2011 at 02:13:19PM +0200, LEVAI Daniel wrote: > > On Wed, Aug 31, 2011 at 06:57:34 -0500, Marco Peereboom wrote: > > > On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote: > > > > On Tue, Aug 30, 2011 at 13:

Re: hide kernel threads in ps?

2011-08-31 Thread Ted Unangst
On Wed, Aug 31, 2011, Uwe Stuehler wrote: > "Help! My Nagios checks failed." :) > > This fixes them by hiding kernel threads from ps output. > > I'd also like to show the main process ID in the PID column as > otherwise there is no way of knowing which threads belong together. > Likely struct kin

Re: ksh history corruption

2011-08-31 Thread Geoff Steckel
On 08/31/2011 03:42 PM, Marco Peereboom wrote: Version 4 fixes all reported bugs. Some folks have expressed doubt about the simplistic way of updating the history file. Specifically the rewriting of all entries. I am sensitive to that and know a couple of optimizations that can easily be appli

Re: hide kernel threads in ps?

2011-08-31 Thread Mark Kettenis
> Date: Wed, 31 Aug 2011 16:38:41 -0400 > From: Ted Unangst > > On Wed, Aug 31, 2011, Uwe Stuehler wrote: > > "Help! My Nagios checks failed." :) > > > > This fixes them by hiding kernel threads from ps output. > > > > I'd also like to show the main process ID in the PID column as > > otherwise

Re: ksh history corruption

2011-08-31 Thread Marco Peereboom
On Wed, Aug 31, 2011 at 04:41:07PM -0400, Geoff Steckel wrote: > On 08/31/2011 03:42 PM, Marco Peereboom wrote: > >Version 4 fixes all reported bugs. > > > >Some folks have expressed doubt about the simplistic way of updating the > >history file. Specifically the rewriting of all entries. I am >

Re: hide kernel threads in ps?

2011-08-31 Thread Philip Guenther
On Wed, Aug 31, 2011 at 2:23 PM, Mark Kettenis wrote: >> Is H the best letter? maybe t? > > It's what FreeBSD uses. And t and T are already taken. As is -L, which is used for threads ("LWPs") by Solaris and FreeBSD. Part of me would be tempted to reuse -k, changing it from unsuppressing P_SY

Re: hide kernel threads in ps?

2011-08-31 Thread Uwe Stuehler
On Wed, Aug 31, 2011 at 11:50 PM, Philip Guenther wrote: > As is -L, which is used for threads ("LWPs") by Solaris and FreeBSD. B > > Part of me would be tempted to reuse -k, changing it from > unsuppressing P_SYSTEM procs to unsuppressing P_THREAD procs. B Then > process 0 would show up by defau

Re: hide kernel threads in ps?

2011-08-31 Thread john slee
On 1 September 2011 10:21, Uwe Stuehler wrote: > If -k would become free for other uses, just for consideration: > - in FreeBSD and Solaris, -k is unused > - in NetBSD, -k specifies the sort order > - in Linux' procps, "k" specifies the sort order -k in AIX /usr/bin/ps is documented as "Lists ker

systrace(1,4) support for *at(2)

2011-08-31 Thread Matthew Dempsky
Diff below adds support to systrace(1) for the new *at(2) system calls. (I'll send a followup diff for the ports tree.) It's received some light testing from jasper@ and myself, so it could now use some wider testing as well as an extra set of eyes to review the code. Index: sys/dev/systrace.h =

Re: systrace(1,4) support for *at(2)

2011-08-31 Thread Matthew Dempsky
On Wed, Aug 31, 2011 at 06:26:58PM -0700, Matthew Dempsky wrote: > Diff below adds support to systrace(1) for the new *at(2) system > calls. (I'll send a followup diff for the ports tree.) And the promised ports systrace.filter diff: Index: infrastructure/db/systrace.filter =

Re: ksh history corruption

2011-08-31 Thread LEVAI Daniel
On Wed, Aug 31, 2011 at 14:42:26 -0500, Marco Peereboom wrote: > Version 4 fixes all reported bugs. > > Some folks have expressed doubt about the simplistic way of updating the > history file. Specifically the rewriting of all entries. I am > sensitive to that and know a couple of optimizations