On Tue, 9 Aug 2016, Chris Turner wrote:
> However, in OpenSMTPD 6.0, mails are delivered as:
>
> From: Charlie Root
> To: root < >
>
I've noticed that for mail sent by any user on the local machine to another
local user. In addition smtpd does not append a message id to headers in this
case.
On Tue, 9 Aug 2016, Mark Kettenis wrote:
> Early ARM CPUs had the exception vector table at address 0. That's a
> terrible idea, since that overlaps with the address space most kernels
> use for userland. This was fixed in later versions of the architecture
> which allows for putting them some
This teaches readelf and objdump about PT_OPENBSD_BOOTDATA (seen in at
least the sparc64 kernel) and teaches ld about that and PT_GNU_RELRO, so
that the symbol names can be used in linker scripts.
ok?
Philip Guenther
Index: include/elf/common.h
===
On Tue, Aug 09, 2016 at 11:01:09AM +0200, Stefan Sperling wrote:
>
> On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote:
> > Hi all,
> >
> > The following patch adds RT5390/RT5392 support to ral(4).
> >
> > Ported from FreeBSD r278551 and r36.
> >
> > Running smoothly with RT309
Hello -
Just installed a 6.0 snapshot (from yesterday, though then rebuilt),
and noticed what seemed to be a possible regression (or otherwise PEBCAK)
in smtpd for my specific dumb-host configuration -
Basically, configuration is as follows:
- configuration:
- Host is test VM behind private
>
> > Which daemons do you use on this machine?
>
> # rcctl ls on
> check_quotas
> cron
> dnscrypt_proxy_one
> dnscrypt_proxy_second
> messagebus
> pf
> pflogd
> relayd
> sndiod
> syslogd
> unbound
> # rcctl ls started
> cron
> dnscrypt_proxy_one
> dnscrypt_proxy_second
> messagebus
>
On 08/09/16 20:47, Lampshade wrote:
> It happened again. I have:
That's bad.
> Tail of dmesg under kernel debugger:
> $ dmesg
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> __assert() at assert+0x25
> pf_state_key_unref() at pf_state_key_unref+0xc6
> pf_pkt_unlink_state_key() at pf_pkt_un
It happened again. I have:
$ sysctl kern.version
kern.version=OpenBSD 6.0-current (GENERIC.MP) #2325: Fri Aug 5 23:28:36 MDT
2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Command I issued before kernel panic still the same (by openbox menu):
$ sudo halt -p
Tail
Early ARM CPUs had the exception vector table at address 0. That's a
terrible idea, since that overlaps with the address space most kernels
use for userland. This was fixed in later versions of the
architecture which allows for putting them somewhere high up in the
address space (where the kernel
> Date: Tue, 9 Aug 2016 16:47:45 +0200
> From: Marcus Glocker
>
> This diff fixes the serial console hang which I face on the sunxi CHIP
> board by fixing '/* XXX sc_initialize? */' in sxiuart_param() and align
> the sc_initialize/speed check same as com(4) does it.
>
> As long we don't have a r
This diff fixes the serial console hang which I face on the sunxi CHIP
board by fixing '/* XXX sc_initialize? */' in sxiuart_param() and align
the sc_initialize/speed check same as com(4) does it.
As long we don't have a replacement for sxiuart yet, ok to get this in?
Index: sxiuart.c
==
Hi,
Alexander Hall wrote on Tue, Aug 09, 2016 at 12:03:39PM +0200:
> On Mon, Aug 08, 2016 at 07:12:34PM +0200, Ingo Schwarze wrote:
>> The search-history description does not say anything that the escape
>> key could be used to leave search mode, nor do i see such a statement
>> anywhere else; in
On Tue, Aug 09, 2016 at 11:30:34AM +0200, Martin Natano wrote:
> On Mon, Aug 08, 2016 at 07:12:34PM +0200, Ingo Schwarze wrote:
> >
> > According to the documentation, typing the escape key alone is not
> > a supported method of exiting the search prompt. The ksh(1) manual
> > says:
> >
> >
On Mon, Aug 08, 2016 at 07:12:34PM +0200, Ingo Schwarze wrote:
>
> According to the documentation, typing the escape key alone is not
> a supported method of exiting the search prompt. The ksh(1) manual
> says:
>
> search-history: ^R
> Enter incremental search mode. [...]
>
On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote:
> Hi all,
>
> The following patch adds RT5390/RT5392 support to ral(4).
>
> Ported from FreeBSD r278551 and r36.
>
> Running smoothly with RT3090 and various RT5390 cards.
Thank you for working on this, James.
I'll review your
15 matches
Mail list logo