>On Sat, Jan 3, 2015 at 8:38 AM, Alexander Bluhm
>wrote:
>> My goal is to make logging via syslog reliable. At least I want
>> to see when a message gets lost.
>>
>> So my idea is to write a kernel log message if sendsyslog(2) cannot
>> deliver a message. Then you see the problem on the console
On Sat, Jan 3, 2015 at 8:38 AM, Alexander Bluhm wrote:
> My goal is to make logging via syslog reliable. At least I want
> to see when a message gets lost.
>
> So my idea is to write a kernel log message if sendsyslog(2) cannot
> deliver a message. Then you see the problem on the console and in
>This is my last post. I'm leaving all of the OpenBSD mailing lists
>because quite frankly I don't want to argue about this anymore,
>especially not with someone who themselves did *exactly the same thing*
>with NetBSD years ago.
Look, forking is a dick move, unless there is real cause.
But to ju
On 01/04/15 19:38, Riley Baird wrote:
On 05/01/15 11:41, Theo de Raadt wrote:
On 05/01/15 11:17, Theo de Raadt wrote:
On Sun, Jan 4, 2015 at 12:52 PM, Riley Baird
wrote:
Even when building with the NOMAN option, "which" will not build without
the manpage whereis.1 being present.
Building fr
On 05/01/15 11:41, Theo de Raadt wrote:
>> On 05/01/15 11:17, Theo de Raadt wrote:
On Sun, Jan 4, 2015 at 12:52 PM, Riley Baird
wrote:
> Even when building with the NOMAN option, "which" will not build without
> the manpage whereis.1 being present.
Building from an inco
>On 05/01/15 11:17, Theo de Raadt wrote:
>>> On Sun, Jan 4, 2015 at 12:52 PM, Riley Baird
>>> wrote:
Even when building with the NOMAN option, "which" will not build without
the manpage whereis.1 being present.
>>>
>>> Building from an incomplete source tree is not supported (deleting
>>
On 05/01/15 11:17, Theo de Raadt wrote:
>> On Sun, Jan 4, 2015 at 12:52 PM, Riley Baird
>> wrote:
>>> Even when building with the NOMAN option, "which" will not build without
>>> the manpage whereis.1 being present.
>>
>> Building from an incomplete source tree is not supported (deleting
>> just t
>On Sun, Jan 4, 2015 at 12:52 PM, Riley Baird
> wrote:
>> Even when building with the NOMAN option, "which" will not build without
>> the manpage whereis.1 being present.
>
>Building from an incomplete source tree is not supported (deleting
>just the manpages!?!?). If you want to waste your own ti
On Sun, Jan 4, 2015 at 12:52 PM, Riley Baird
wrote:
> Even when building with the NOMAN option, "which" will not build without
> the manpage whereis.1 being present.
Building from an incomplete source tree is not supported (deleting
just the manpages!?!?). If you want to waste your own time in t
Theo de Raadt writes:
>>This should make things better on 32 bits archs in a few years.
>>Tested on amd64 by changing the format to "%d".
>>
>>ok?
>>
>>Index: edit.c
>>===
>>RCS file: /cvs/src/usr.bin/chpass/edit.c,v
>>retrieving rev
>This should make things better on 32 bits archs in a few years.
>Tested on amd64 by changing the format to "%d".
>
>ok?
>
>Index: edit.c
>===
>RCS file: /cvs/src/usr.bin/chpass/edit.c,v
>retrieving revision 1.34
>diff -u -p -p -u -r1.
This should make things better on 32 bits archs in a few years.
Tested on amd64 by changing the format to "%d".
ok?
Index: edit.c
===
RCS file: /cvs/src/usr.bin/chpass/edit.c,v
retrieving revision 1.34
diff -u -p -p -u -r1.34 edit.c
Thank you, fixed.
Index: sys/arch/amd64//amd64/identcpu.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.54
diff -u -p -r1.54 identcpu.c
--- sys/arch/amd64//amd64/identcpu.c13 Jul 2014 12:11:01
The undocumented ones are already in the kernel but not marked
as such. Thats why i renamed them because they have the
names of the documented features. To cut a long story short,
the undocumented MSRs have now the name *_UNDOCUMENTED. So that
the real documented MSRs can get there real names accor
Even when building with the NOMAN option, "which" will not build without
the manpage whereis.1 being present.
This patch checks to see whether NOMAN is defined, and if not, does not
do the tests related to path expansion.
Index: usr.bin/which/Makefile
=
On Thu, Nov 27, 2014 at 12:44:54PM +0100, Mages, Simon wrote:
> Hi there,
>
> the temperatures 'sysctl hw.sensors' displays for each CPU
> are wrong for the most modern Intel CPUs.
>
> OpenBSD uses only 100 or 85 degC as TJmax for Intel CPUs, but
> in reality the TJmax value is somewhere around t
I restored the functionality according to the manpage.
That means that read() on bpf is blocking again. If a
timeout is set read() will block until the timeout is
over.
Maybe asynchronous is also broken, i will look into that later.
Index: sys/net/bpf.c
==
There's no ifdef for STARTUP.
Index: Makefile
===
RCS file: /cvs/src/usr.bin/mg/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile31 May 2013 18:03:43 - 1.28
+++ Makefile4 Jan 2015 19:08:47 -0
Nathanael Rensen wrote:
> On Sun, 04 Jan 2015 05:57:38 +, Martin Brandenburg wrote:
> > Since the ability to pass arbitrary arguments to sendmail has been
> > removed from mail(1), I have added a variable and flag to pass a from
> > address to sendmail.
> >
> > I considered making mail take
On Sun, 04 Jan 2015 05:57:38 +, Martin Brandenburg wrote:
> Since the ability to pass arbitrary arguments to sendmail has been
> removed from mail(1), I have added a variable and flag to pass a from
> address to sendmail.
>
> I considered making mail take the same arguments for this as it woul
Moving this discussion over to tech@.
John, the problem is likely to be related to the following line in
your dmesg:
0:20:0: mem address conflict 0xfed0/0x400
Can you send me the output of pcidump -vxx and acpidump -o for this machine?
On Sat, Jan 03, 2015 at 06:18:03PM -0600, Boris Goldberg wrote:
> Hello Otto,
>
> Friday, January 2, 2015, 4:16:50 PM, you wrote:
>
> OM> On Fri, Jan 02, 2015 at 03:28:46PM -0600, Boris Goldberg wrote:
>
> >> What about our second patch?
>
> OM> I'd rather stay in line with FreeBSD and docum
22 matches
Mail list logo
