Indeed. fixed.
Penned by Ian Mcwilliam on 20140722 21:18.12, we have:
| XETCLIST=`mktemp /tmp/_xetcsum.XX` || exit 1; sort
distrib/sets/lists/xetc/{mi,md.amd64} > ${XETCLIST}; cd /usr/xf4-dest &&
xargs sha256 -h /usr/xf4-dest/usr/share/sysmerge/xetcsum < ${XETCLIST} ||
XETCLIST=`mktemp /tmp/_xetcsum.XX` || exit 1; sort
distrib/sets/lists/xetc/{mi,md.amd64} > ${XETCLIST}; cd /usr/xf4-dest &&
xargs sha256 -h /usr/xf4-dest/usr/share/sysmerge/xetcsum < ${XETCLIST} || true;
rm -f ${XETCLIST}
cd distrib/sets && env MACHINE=amd64 ksh ./maketars 56 5.6 &&
Was just investigating a little issue with a long running (stuck)
process. I logged in at 9:20PM:
10002 0.0 0.0 3740 2420 ?? S 9:20PM0:00.02 sshd
So you can imagine my surprise to see a cron job running in the future:
24292 0.0 0.0 776 616 ?? Is 9:25PM0:08.51 /bin/sh
On Wed, Jul 23, 2014 at 00:02, Mark Kettenis wrote:
> Hmm, I believe, quite strongly, that we should always panic when a
> arithmetic overflow is detected.
>
> The M_CANFAIL flag is really there to allow for failure in certain
> low-memory conditions, not to recover from programming bugs.
The cu
> Date: Tue, 22 Jul 2014 21:21:39 +
> From: Doug Hogan
>
> On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
> > That is misleading in the M_CANFAIL case.
> >
> > I'm not terribly good at wording things, but I suggest something
> > more like this instead:
>
> Hmm I thin
>On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote:
>> On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
>>> That is misleading in the M_CANFAIL case.
>>>
>>> I'm not terribly good at wording things, but I suggest something
>>> more like this instead:
>>
>> Hmm I think it's only
On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote:
> On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
>> That is misleading in the M_CANFAIL case.
>>
>> I'm not terribly good at wording things, but I suggest something
>> more like this instead:
>
> Hmm I think it's only mislead
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
> That is misleading in the M_CANFAIL case.
>
> I'm not terribly good at wording things, but I suggest something
> more like this instead:
Hmm I think it's only misleading in the M_CANFAIL case. I think this
diff makes it a l
di_size is u_int64_t in both struct ufs1_dinode and ufs2_dinode, and
strlen returns size_t. Adjust link_len and len declarations to match
and drop now-redundant unsigned cost from bcopy.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work
Simplify if-conditions by removing explicit != 0.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work/cvsroot/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.24
diff -p -u -r1.24 ufs.c
--- sys/lib/libsa/ufs.c 22 Jul 2014 18:03:03 -
Martin Natano writes:
> FSTAB has been deprecated in favor of _PATH_FSTAB in 4.4BSD. It's time
> to let go of it. Below the diff I committed to Bitrig.
>
> cheers,
> natano
Committed, thanks.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
current used one is too simple :-( below
i must add some static root to this configuration but< i didnt do it >
, still somehow working on integration with pf and unbound (and other
less interesting stuff)
( please do not break the client ip insertion in pf table )
I am not sure it is even suppor
Next, use NULL instead of casting 0 to pointer types.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work/cvsroot/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.22
diff -p -u -r1.22 ufs.c
--- sys/lib/libsa/ufs.c 30 May 2013 19:19:09 -
On Tue, Jul 22, 2014 at 3:52 AM, Grégoire Duchêne wrote:
> Hello everybody,
>
> I'm currently working on revamping dhcpd(8)'s configuration parser and
> now that my work is almost complete, I would like to test it against
> some configuration files to make sure that my parser and the one we have
>
Hi,
Before I send a diff for pfctl to disable "once" on "match" rules,
I've decided to try and see how much work is it to make it actually
work. Turns out that I need to extend pf_rule_item by 3 pointers
to track the match rule ruleset, anchor rule and the ruleset it
belongs to.
Here's what this
Sorry, let me split this into smaller diffs to ease review.
First up, the diff below removes a redundant cast: buf is declared a
char * so there's no need to cast it to a char *. I noticed the same
issue in ufs.c, too, so fix it in both places.
Index: ufs.c
==
On 21 July 2014, Liviu Daia wrote:
> On 12 July 2014, Stuart Henderson wrote:
> > trace ->
> >
> > stopped at uao_reference+0x88: movq %rcx,0x8(%rax)
> >
> > uao_reference at ..+0x88
> > uao_set_swslot at ..+0x55
> > uvmpd_scan_inactive at ..+0x681
> > uvmpd_scan at ..+0x23c
> > uvm_pageout at
Here's the last piece of information I'd like to *always* have in the
routing table in order to be able to replace the RB-tree.
This diff adds the configured broadcast addresses to the routing table
permanently. Actually these addresses are handled like lladdr and are
removed when their timeout e
Martin Natano writes:
> FSTAB has been deprecated in favor of _PATH_FSTAB in 4.4BSD. It's time
> to let go of it. Below the diff I committed to Bitrig.
Make sense and looks innocuous to me, I'll commit it tomorrow unless
I hear objections.
Thanks,
> cheers,
> natano
>
>
> Replace deprecated FS
When I added p2p_rtrequest() the RTF_LOCAL flag was not yet available, so
I used RTF_LLINFO to say that a route should be used for local trafic.
The diff below removes this hack and correctly check for RTF_LOCAL in
all the custom *_rtrequest() functions able to change the ifp of a route.
ok?
Ind
Hello everybody,
I'm currently working on revamping dhcpd(8)'s configuration parser and
now that my work is almost complete, I would like to test it against
some configuration files to make sure that my parser and the one we have
in the tree do the same things. The weirder, the better!
Cheers,
-
Hi,
This diff finally implements what's stated in the man page regarding
parent anchors for "once" rules: "In case this is the only rule in
the anchor, the anchor will be destroyed automatically after the
rule is matched." Previous code was largely incorrect, sorry for that.
The additional arule
Hi,
This is a second diff and it makes sure that pf_step_into_anchor always
saves a pointer to the rule that owns the anchor on the pf anchor stack.
There's no reason why we should check for depth here. As a side effect
this makes sure that the correct nested anchor gets it's counter bumped
inste
Hi,
Here's the first diff in a series of three to finish the "once"
feature.
This one was prompted by the discussion with Alexandr Nedvedicky
.
Apart from some minor code reshuffling the big change is that we
start with a ruleset pointer assigned to pf_main_ruleset so that
pf_purge_rule doesn't
On 22/07/14(Tue) 12:00, Claudio Jeker wrote:
> On Tue, Jul 22, 2014 at 10:06:35AM +0100, Stuart Henderson wrote:
> > On 2014/07/22 11:01, Martin Pieuchot wrote:
> > > Anybody is using the "-sa" modifier of route(8)? A sockaddr in hexa,
> > > really? What's your use case?
> >
> > That only seems
On Tue, Jul 22, 2014 at 10:06:35AM +0100, Stuart Henderson wrote:
> On 2014/07/22 11:01, Martin Pieuchot wrote:
> > Anybody is using the "-sa" modifier of route(8)? A sockaddr in hexa,
> > really? What's your use case?
>
> That only seems useful in situations where modifying route(8) would
> be
On 2014/07/22 11:01, Martin Pieuchot wrote:
> Anybody is using the "-sa" modifier of route(8)? A sockaddr in hexa,
> really? What's your use case?
That only seems useful in situations where modifying route(8) would
be a better choice..
> Otherwise, ok to kill it?
Obviously wait for other feed
Anybody is using the "-sa" modifier of route(8)? A sockaddr in hexa,
really? What's your use case?
Otherwise, ok to kill it?
Index: keywords.h
===
RCS file: /home/ncvs/src/sbin/route/keywords.h,v
retrieving revision 1.28
diff -u -
28 matches
Mail list logo
