On 24 Jun 2016, at 2:44, Paul Jakma wrote:
Hi Martin,
Cheers.
On Fri, 24 Jun 2016, Martin Winter wrote:
I haven’t seen any fixes yet, but the Round 8 breaks on several
points on my CI system:
As a side note, I’m a little bit disappointed that all were all
marked as failed by my CI system, not tested (series of patches are
sometimes missed as finding complete series isn’t perfect) or never
submitted to patchwork or the list
so, this is still a WIP. I'm in the final stages of getting as many
outstnading patches lined up as possible. Also, this is the
'proposed/ff' head - not a tentative 'accepted' head.
I was aware from patchwork some of those patches have CI fails, also
some have comments on issues. This pass is just to get them queued in
some way. After which, I was intending to re-scan the comments as part
of building a summary mail.
Though, still _v useful_ to have them re-checked. Thanks. :)
My bad. I thought that only patches which are in a working stage should
be selected for proposed branch
(the “proposed” would be for code review, functionality etc).
I’m partially a bit frustrated on the guesswork on automatically
testing series of patches - which is the
reason why I’m pushing to try the github pull request model for this.
Patchwork has no concept of series of the patches. At this time, I look
at subject, msg-id and sender
and try to re-assemble the series. But this fails whenever someone
resubmits just a single replacement v2
patch or doesn’t use “git send-email”. So the larger the patch,
the more likely my automated system
fails to detect them.
(and if anyone here notices that their series is missing and got no
automated test report, then feel free
to email me and I’ll manually fix and trigger the series)
Also, if you ever want to find the CI result for a specific Patchwork,
then just go to
https://ci1.netdef.org/browse/label/patchwork_id={patchID}
Ie https://ci1.netdef.org/browse/label/patchwork_id=2006
for patchwork 2006
Doesn’t matter if it’s part of a series or not - it should get you
directly to the test run(s) for
that specific patch.
1) DejaGNU testcli:
[…]
Running ./libzebra.tests/testcli.exp ...
FAIL: testcli
[…]
—> —> The offending commit for this is 0dbe0d2 (“lib:
Consolidate VIEW_NODE to be ENABLE_NODE as well”)
This is Patchwork #1856
Originally failed CI test:
https://ci1.netdef.org/browse/QUAGGA-QPWORK-251
2) DejaGNU testbgpmpattr IPv6-default: IPV6 MP Reach, global nexthop,
2 NLRIs + default -- testbgpmpattr aborted!
Aha, will look.
Would be good to remind everyone that it IS (or should be) a requirement
for
acceptance that it passes “make check” at the time of a patch
submission.
[…]
Running ./bgpd.tests/testbgpmpath.exp ...
Running ./bgpd.tests/testbgpmpattr.exp ...
failed: testbgpmpattr IPv6-default: IPV6 MP Reach, global nexthop,
2 NLRIs
+ default -- testbgpmpattr aborted!
[…]
—> —> The offending commit for this is 82655af (“bgpd, zebra:
Use next hop tracking for connected routes too”)
This is Patchwork #1640
Was never tested by my CI system (it is part of a series of 89
patches which is a challenge for the automated
patchwork testing setup on my CI system)
3) missing htonf on OpenBSD / NetBSD 6/7 / FreeBSD 8/9/10 / OmniOS:
[…]
make all-am
CC network.lo
network.c: In function 'htonf':
network.c:109:2: error: #error "Please supply htonf implementation
for
this platform"
#error "Please supply htonf implementation for this platform"
^
network.c:111:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
*** Error code 1
[…]
Now that's interesting.
The offending commit for this is f8e536e (“lib: consolidate
ntohf/htonf from ospfd/isisd TE to lib/network”)
This is was never seen in Patchwork. No idea where this patch came
from…
That's basically a previous version of something that Olivier then
incorporated into his LLS train. I went back to the other version, so
that the attribution to OSR is visible in the commit logs, as well as
the other credit to Aidan Delaney.
Olivier's recent version in patchwork is:
http://patchwork.quagga.net/patch/1906/
Not sure where the other version is. I don't see a CI error for the
BSDs or Solaris. Do they not have __STDC_IEC_559__ ?
Would appreciate if someone can spend a few cycles on fixing this
BEFORE pushing more commits into this branch as these are multiple
teststoppers.
Will have a look.
Can you do a grep for STDC_IEC_559 on those test hosts?
Doesn’t exist. I send the complete defines in a separate email to the
list (for future reference)
These are based on the default C compilers.
Regards,
- Martin Winter
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
