On Thu, 7 Jul 2016, Lou Berger wrote:
Nope, but dropping this fixes another issue: normal updates are also
taking 1-2 *minutes*. Also, adjacencies are taking longer than normal
to come up
Weird.
The version approach allows all to see the changes that go in on top of
what was sent to the lis
On 7/7/2016 12:58 PM, Paul Jakma wrote:
> On Thu, 7 Jul 2016, Lou Berger wrote:
>
>> Looks like this fixes the exit problem. Two issues I see immediately
>> are:
>> ==12640== {
>>
>> Memcheck:Leak
>> fun:calloc
>> fun:zcalloc
>> fun:bnc_new
>> fun:bgp_find_or_add_nexthop
>> fun
On Thu, 7 Jul 2016, Lou Berger wrote:
Looks like this fixes the exit problem. Two issues I see immediately
are:
==12640== {
Memcheck:Leak
fun:calloc
fun:zcalloc
fun:bnc_new
fun:bgp_find_or_add_nexthop
fun:bgp_start
fun:bgp_event
fun:bgp_start_timer
fun:thread_call
fu
On 7/7/2016 8:43 AM, Paul Jakma wrote:
> On Thu, 7 Jul 2016, Paul Jakma wrote:
>
>> Unfortunately, that means the ff, nits and pushback tracking heads are going
>> to get non-fast-forward updated.
> I've fixed the issue and updated {pushback,nits}/{a,b} and ff.
Looks like this fixes the exit pro
On Thu, 7 Jul 2016, David Lamparter wrote:
Because *everyone* can convert old patchwork patches into current
mails by simply remailing them.
Though, that need not be helpful.
I really feel like we just need to get the ball rolling... on stuff
that's *currently* coming in.
So start the col
On Tue, Jul 05, 2016 at 06:11:19AM -0400, Lou Berger wrote:
> On July 5, 2016 3:10:34 AM Vincent JARDIN wrote:
> > Le 5 juil. 2016 05:50, "Lou Berger" a écrit :
> >>
> >> So in thinking about this a bit, perhaps there's something useful that
> >> we can try in parallel with the single-person focu
On Thu, 7 Jul 2016, Paul Jakma wrote:
Unfortunately, that means the ff, nits and pushback tracking heads are going
to get non-fast-forward updated.
I've fixed the issue and updated {pushback,nits}/{a,b} and ff.
Unfortunately, the new refs are not fast-forward-mergable. In the longer
run, if
On July 7, 2016 6:00:15 AM Paul Jakma wrote:
On Thu, 7 Jul 2016, Paul Jakma wrote:
Ah, it's my bad. 'lib: keep hash of node's commands to detect
duplicate installs' I missed adding the basic commands to other nodes
besides VIEW and ENABLE.
How did 'exit' get into your config file though?
On Thu, 7 Jul 2016, Paul Jakma wrote:
Ah, it's my bad. 'lib: keep hash of node's commands to detect
duplicate installs' I missed adding the basic commands to other nodes
besides VIEW and ENABLE.
How did 'exit' get into your config file though?
Though we did accept it, it's not something we e
On Wed, 6 Jul 2016, Lou Berger wrote:
I'm guessing that if the problme is that 'exit' that it is due to:
'lib, vtysh: Add support for marking a file with appropriate end of
context'
nope, is due to changes in lib/command.c in 8/ff
Ah, it's my bad. 'lib: keep hash of node's commands to det
On 7 Jul 2016, at 1:24, Paul Jakma wrote:
On Wed, 6 Jul 2016, Martin Winter wrote:
This time you managed to break the Github mirror. My update scripts
correctly detect the savannah as the newer and try to push to github,
but the github git doesn’t accept it.
The volatile/... ref updates are
On Wed, 6 Jul 2016, Martin Winter wrote:
This time you managed to break the Github mirror. My update scripts
correctly detect the savannah as the newer and try to push to github,
but the github git doesn’t accept it.
The volatile/... ref updates are not fast-forwards and I guess Github
disal
Ok, fixed.
the issue was that you created a proposed/nits, then deleted it again
and created a proposed/nits/a and proposed/nits/b
So it failed to push the nits/a because nits existed.
- Martin
On 6 Jul 2016, at 15:31, Martin Winter wrote:
This time you managed to break the Github mirror. My
13 matches
Mail list logo
