On Tue, May 12, 2009 at 09:57:33PM +, Jacob Meuser wrote:
> here's a patch to power down unused widgets. should be safe, but my
> devices don't support this (about half of all azalia codecs support power
> modes on the individual widgets) so please test that this doesn't somehow
> break the ab
On Thu, May 14, 2009 at 04:10:02AM +, Jacob Meuser wrote:
> On Wed, May 13, 2009 at 07:02:32PM -0400, Dan Harnett wrote:
> > On Tue, May 12, 2009 at 09:57:33PM +, Jacob Meuser wrote:
> > > here's a patch to power down unused widgets. should be safe, but my
> >
On Sat, Jun 06, 2009 at 10:23:34PM -0600, g...@gwk.ca wrote:
> And it works better if you send the actual diff you would like tested
> sorry about this, but please test this one.
It appears to be fine running on a ThinkPad T61 and X61s. The max speed
is listed a little funny. There is the max an
On Tue, Jun 23, 2009 at 01:28:25AM +0200, Dariusz Swiderski wrote:
> On Thu, 18 Jun 2009, sfi...@kefir.sfires.net wrote:
>
>> hi,
>>
>> sorry for my last post, i will not use Mail again :)
>
> hi, this diff incudes Mark Kettenis remarks in respect to KNF
> no functional change
I've been running yo
If for some reason top is killed, then the cursor is left mixed in with
the last output of top. It's been a minor annoyance when rebooting a
remote box.
Index: top.c
===
RCS file: /home/cvs/openbsd/src/usr.bin/top/top.c,v
retrieving
On Tue, Sep 07, 2010 at 12:21:56PM -0500, Todd T. Fries wrote:
> Neither of the above solutions provide the same output.
>
> Sorry, the requirement is to `notice' we are on a new line if an error occurs,
> and only do the final echo if we are not on a new line at the end.
Another shot at this usi
On Tue, Sep 07, 2010 at 12:21:56PM -0500, Todd T. Fries wrote:
> Neither of the above solutions provide the same output.
>
> Sorry, the requirement is to `notice' we are on a new line if an error occurs,
> and only do the final echo if we are not on a new line at the end.
Another loop that should
On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote:
> I got this after a while:
>
> panic: softraid0: sr_crypto_finish_io
I see the same panic in the latest amd64 snapshot.
panic: softraid0: sr_crypto_finish_io
Stopped at Debugger+0x5: leave
ddb{0}> trace
Debugger() at Debugger+
On Fri, Oct 22, 2010 at 09:29:59PM +0200, Dawe wrote:
> No issues for me on amd64 after one day of using the crypto
> discipline.
Just a "me too".
This allows the location of the etag-state file to be configured in
httpd.conf rather than hardcoded to "logs/etag-state".
Index: conf/httpd.conf
===
RCS file: /home/danh/.cvs/openbsd/src/usr.sbin/httpd/conf/httpd.conf,v
retrieving re
On Mon, Feb 21, 2011 at 04:54:40PM +0100, Alexander Schrijver wrote:
> On Mon, Feb 21, 2011 at 01:34:51PM +0100, Pascal Stumpf wrote:
> grep(1) only prints the filename when it receives more then 1 filename as
> arguments. Thus, when you do this:
>
> $ find . -name '*.c' -exec grep bla {} \;
>
>
> The following substitutes '~' for $HOME in the \W prompt case, taken
> from \w. This matches bash's behavior for \W.
This has bugged me too, and I have a very similar patch in my tree. The
exception is the middle conditional.
> + } else if (strncmp(p, str_val(globa
On Tue, Mar 08, 2011 at 11:01:38AM -0500, Okan Demirmen wrote:
> On Tue 2011.03.08 at 09:44 -0500, Dan Harnett wrote:
> > This doesn't belong there. This effective turns \W into \w if the path
> > is somewhere in the user's home directory. Without that conditional, it
The sendmail daemon can be in a state where it is rejecting new messages
and sets the proc title accordingly. The current rc.d script ignores
sendmail if it is in this state.
$ pgrep -lf sendmail
459 sendmail: rejecting new messages: min free: 100
I don't believe the wildcard following '(acc
n 2012/01/17 07:40, Dan Harnett wrote:
> > The sendmail daemon can be in a state where it is rejecting new messages
> > and sets the proc title accordingly. The current rc.d script ignores
> > sendmail if it is in this state.
> >
> > $ pgrep -lf sendmail
> >
On Mon, Jul 23, 2012 at 11:51:05PM -0400, Ted Unangst wrote:
> I bring more love to everybody's favorite rm option.
>
> So I'm wiping a file from a fairly slow USB stick and it's taking
> forever. I don't really give a shit about some guy with a quantum
> tachyon microscope taking it apart, I jus
16 matches
Mail list logo