On 2018/08/01 23:18, Florian Obser wrote:
> I'm chasing a bug in IPv6 where ndp reports an entry as (incomplete)
> but when you try to reach that target no neighbor solicitation is
> send.
Not sure if it's related or not but I've seen weird v6 behaviour on
my workstation for a while which I've
this one's better
- use the correct unveil pattern, pointed out by brynet@
- argv[0] vs. argv[i], pointed out by Matthew Martin and Mario Campos
diff --git ifconfig.c ifconfig.c
index 9bfb1751aab..20154059394 100644
--- ifconfig.c
+++ ifconfig.c
@@ -676,10 +676,15 @@ main(int argc, char *argv[])
On Thu, Aug 02, 2018 at 05:16:18PM +0200, Ingo Schwarze wrote:
> Hi,
>
> the first paragraph of the DESCRIPTION is all fluff.
> Let's just wipe it away completely, we always want
> the DESCRIPTION to be concise and get to the point.
>
> Instead, provide some real HISTORY.
>
> DESCRIPTION: minus
I have been told that this is going to fall into snaps soon. If you
are doing weird (or normal) things with ifconfig, please test.
In particular if you use rulefile.
Thanks!
diff --git ifconfig.c ifconfig.c
index 9bfb1751aab..873aed5bcc7 100644
--- ifconfig.c
+++ ifconfig.c
@@ -676,10 +676,13
Is argv[0] a typo? Shouldn't it be argv[i]?
On Thu, Aug 2, 2018, 12:05 PM Florian Obser wrote:
> I have been told that this is going to fall into snaps soon. If you
> are doing weird (or normal) things with ifconfig, please test.
>
> In particular if you use rulefile.
>
> Thanks!
>
> diff --git
- Original Message -
> From: "Rob Pierce"
> To: "Bryan Steele"
> Cc: "tech"
> Sent: Thursday, August 2, 2018 1:30:15 PM
> Subject: Re: please test: unveil for ifconfig
> - Original Message -
> > From: "Bryan Steele"
> > To: "tech"
> > Sent: Thursday, August 2, 2018 1:24:48 PM
On Thu, Aug 02, 2018 at 07:41:01PM +0200, Ingo Schwarze wrote:
> Hi Jason,
>
> Jason McIntyre wrote on Thu, Aug 02, 2018 at 05:41:22PM +0100:
>
> > ok by me.
>
> Thanks for checking, committed.
>
> > you might get away with removing the last sentence of BUGS
> > now, since HISTORY almost
Hi,
the first paragraph of the DESCRIPTION is all fluff.
Let's just wipe it away completely, we always want
the DESCRIPTION to be concise and get to the point.
Instead, provide some real HISTORY.
DESCRIPTION: minus five lines, same amount of information.
HISTORY: plus three lines, but now
Note that the neighbor entry is in state S (stale).
Whatever that means...
On Thu, Aug 02, 2018 at 04:44:57PM +0100, Stuart Henderson wrote:
> On 2018/08/01 23:18, Florian Obser wrote:
> > I'm chasing a bug in IPv6 where ndp reports an entry as (incomplete)
> > but when you try to reach that
On Thu, Aug 02, 2018 at 07:04:31PM +0200, Florian Obser wrote:
> I have been told that this is going to fall into snaps soon. If you
> are doing weird (or normal) things with ifconfig, please test.
>
> In particular if you use rulefile.
>
> Thanks!
>
> diff --git ifconfig.c ifconfig.c
> index
On 01/08/18(Wed) 01:53, Mark Kettenis wrote:
> > Date: Tue, 31 Jul 2018 14:55:45 -0300
> > From: Martin Pieuchot
> >
> > On 26/06/18(Tue) 12:31, Martin Pieuchot wrote:
> > > These syscalls do two operations: they allocate FDs and some buffers.
> > > Thanks to the work done for sockets the
Hi Jason,
Jason McIntyre wrote on Thu, Aug 02, 2018 at 05:41:22PM +0100:
> ok by me.
Thanks for checking, committed.
> you might get away with removing the last sentence of BUGS
> now, since HISTORY almost provides the same.
Maybe, but i don't know enough about ufs and vfs to judge whether
it
On Wed, 1 Aug 2018, Philip Guenther wrote:
> This smells like some compatibility issue with the eager-FPU change. One
> thought is whether the Xen presents the guest with a correctly reset FPU
> state on all CPUs, or if there's some odd state that we're not clearing.
>
> I made a later commit in
Hi,
I've updated to the recent -current on my Lenovo T450 and get a kernel
panic at the following point:
starting local daemons: apmd cron xenodm.
Thu Aug 2 23:44:13 CEST 2018
-> at this point it is starting X but fall back to panic.
This is the output directly after the panic message:
On Fri, Aug 03, 2018 at 12:02:17AM +0200, Felix Maschek wrote:
> Hi,
>
> I've updated to the recent -current on my Lenovo T450 and get a kernel panic
> panic: unveil_nipledge_lookup: unexpected pledge bits: 8589934592
this panic is from my diff I recently sent to tech@. it seems it has
been put
On Thu, Aug 02, 2018 at 01:58:38PM +, Rob Pierce wrote:
> A little less wordy when introducing the namieidata structure.
>
> Ok?
>
> Index: namei.9
> ===
> RCS file: /cvs/src/share/man/man9/namei.9,v
> retrieving revision 1.18
>
ouch!
and ok benno@
(still pondering the sofreconfig in reshuffle diff ;))
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.08.02 14:32:23 +0200:
> Currently if anyone uses the example bgpd filter rules all neighbors will
> do a full softreconfiguration even when no rule have been changed. This
On Thu, Aug 02, 2018 at 03:15:14PM +0100, Jason McIntyre wrote:
> On Thu, Aug 02, 2018 at 01:58:38PM +, Rob Pierce wrote:
> > A little less wordy when introducing the namieidata structure.
> >
> > Ok?
> >
> > Index: namei.9
> >
Rob Pierce(r...@2keys.ca) on 2018.08.02 14:26:54 +:
> On Thu, Aug 02, 2018 at 03:15:14PM +0100, Jason McIntyre wrote:
> > On Thu, Aug 02, 2018 at 01:58:38PM +, Rob Pierce wrote:
> > > A little less wordy when introducing the namieidata structure.
> > >
> > > Ok?
> > >
> > > Index:
On 2018/08/02 14:32, Claudio Jeker wrote:
> Currently if anyone uses the example bgpd filter rules all neighbors will
> do a full softreconfiguration even when no rule have been changed. This is
> because the skip logic was wrongly implemented and so rules like 'pass to
> ebgp' will result in non
On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote:
> Hi,
>
> After issuing a "make clean=build" on a port, I am unable to build
> again.
>
> "make" failed in 'configure' stage:
>
> $ make
> ...
> /bin/sh: cannot create
>
On Wed, Aug 01, 2018 at 11:03:39AM +0200, Sebastien Marie wrote:
> Hi,
>
> After issuing a "make clean=build" on a port, I am unable to build
> again.
>
> "make" failed in 'configure' stage:
>
> $ make
> ...
> /bin/sh: cannot create
>
Hi,
This driver supports Microchip LAN75xx/LAN78xx USB Gigabit Ethernet devices.
I tested with Z-TEK ZE582 [1] and Microchip EVB-LAN7800LC evaluation board [2]
on i386 and amd64.
[1] http://www.z-tek.com.cn/USBzhuanhuanxian/275.html
[2]
All 3 are OK with me, if there are no objections I can commit them later
(but would be happy if someone beats me to it :)
On 2018/08/02 14:49, Ross L Richardson wrote:
>
> This is the first of several diffs containing separate bits of the
> earlier combined diff.
>
> "X509" to "X.509" for
Hi,
It seems that switchd(8) suffers from the same issue I reported yesterday about
eigrpd(8), the daemon when it's shutdown never deletes the unix control socket
because that is being done from a chrooted process.
This one nevertheless took a little bit more effort since I had to disentangle
2
Hi,
ntpd(8) also doesn't seem to delete its unix control socket, but in this case
it's not a matter of calling control_cleanup() from a chrooted process
but instead not calling it at all.
OK?
Index: ntpd.c
===
RCS file:
On Mon, Jul 30, 2018 at 07:55:35AM -0600, Bob Beck wrote:
> yeah the latter will be the way to go
>
new diff with direct lookup using an indirection table.
first reorders PLEDGE flags to have:
- PLEDGE promises that could occurs in ni_pledge and are used for
unveil(2)
- PLEDGE promises
A little less wordy when introducing the namieidata structure.
Ok?
Index: namei.9
===
RCS file: /cvs/src/share/man/man9/namei.9,v
retrieving revision 1.18
diff -u -p -r1.18 namei.9
--- namei.9 23 Nov 2015 17:53:57 -
Please find below a better version and not so intrusive based on
httpd(8)
Index: control.c
===
RCS file: /cvs/src/usr.sbin/switchd/control.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 control.c
--- control.c 17 Jan 2017 22:10:56
29 matches
Mail list logo
