DPDK CI discussions
 help / color / Atom feed
* [dpdk-ci] Failures reported by Intel CI for series 10551
@ 2020-06-23  7:07 David Marchand
  2020-06-24 14:19 ` Lincoln Lavoie
  2020-06-26  3:03 ` Chen, Zhaoyan
  0 siblings, 2 replies; 8+ messages in thread
From: David Marchand @ 2020-06-23  7:07 UTC (permalink / raw)
  To: Chen, Zhaoyan; +Cc: ci, sys_stv

Hello,

(It looks like I have no luck with CI those days... :-)).

All patches of a series of mine
(https://patchwork.dpdk.org/project/dpdk/list/?series=10551) are
marked as failing all compilation in Intel CI.

- Is it normal to see all patches with the exact same test report?
Patch 1: http://mails.dpdk.org/archives/test-report/2020-June/137872.html
Patch 9: http://mails.dpdk.org/archives/test-report/2020-June/137880.html

UNH and ovsrobot only report once when testing a full series.
It makes more sense if Intel CI only tests full series.


- Putting the first point aside, and focusing on patch 9 error:
http://mails.dpdk.org/archives/test-report/2020-June/137880.html

../drivers/mempool/bucket/rte_mempool_bucket.c: In function ‘bucket_get_count’:
../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit
declaration of function ‘rte_lcore_iterate’; did you mean
‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]
  rte_lcore_iterate(count_per_lcore, &ctx);
  ^~~~~~~~~~~~~~~~~
  rte_lcore_is_enabled
../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested
extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]
cc1: all warnings being treated as errors


This function is defined in rte_lcore.h which does seem to be
included, seeing how the compiler suggests another
rte_lcore_is_enabled function.
The v2 revision passed fine
(http://mails.dpdk.org/archives/test-report/2020-June/137552.html) and
I see no change in v3 that would break like this.

I am a bit puzzled...
One thing that comes to mind, do we have dpdk headers installed
system-wide on the Intel CI server(s)?


-- 
David Marchand


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-23  7:07 [dpdk-ci] Failures reported by Intel CI for series 10551 David Marchand
@ 2020-06-24 14:19 ` Lincoln Lavoie
  2020-06-25 14:20   ` David Marchand
  2020-06-26  3:03 ` Chen, Zhaoyan
  1 sibling, 1 reply; 8+ messages in thread
From: Lincoln Lavoie @ 2020-06-24 14:19 UTC (permalink / raw)
  To: David Marchand; +Cc: Chen, Zhaoyan, ci, sys_stv

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

Hi David,

Did you get any response to this from the Intel folks?  Should we add a bug
to track this for discussion / review at our meeting next week?

Cheers,
Lincoln

On Tue, Jun 23, 2020 at 3:07 AM David Marchand <david.marchand@redhat.com>
wrote:

> Hello,
>
> (It looks like I have no luck with CI those days... :-)).
>
> All patches of a series of mine
> (https://patchwork.dpdk.org/project/dpdk/list/?series=10551) are
> marked as failing all compilation in Intel CI.
>
> - Is it normal to see all patches with the exact same test report?
> Patch 1: http://mails.dpdk.org/archives/test-report/2020-June/137872.html
> Patch 9: http://mails.dpdk.org/archives/test-report/2020-June/137880.html
>
> UNH and ovsrobot only report once when testing a full series.
> It makes more sense if Intel CI only tests full series.
>
>
> - Putting the first point aside, and focusing on patch 9 error:
> http://mails.dpdk.org/archives/test-report/2020-June/137880.html
>
> ../drivers/mempool/bucket/rte_mempool_bucket.c: In function
> ‘bucket_get_count’:
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit
> declaration of function ‘rte_lcore_iterate’; did you mean
> ‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]
>   rte_lcore_iterate(count_per_lcore, &ctx);
>   ^~~~~~~~~~~~~~~~~
>   rte_lcore_is_enabled
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested
> extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]
> cc1: all warnings being treated as errors
>
>
> This function is defined in rte_lcore.h which does seem to be
> included, seeing how the compiler suggests another
> rte_lcore_is_enabled function.
> The v2 revision passed fine
> (http://mails.dpdk.org/archives/test-report/2020-June/137552.html) and
> I see no change in v3 that would break like this.
>
> I am a bit puzzled...
> One thing that comes to mind, do we have dpdk headers installed
> system-wide on the Intel CI server(s)?
>
>
> --
> David Marchand
>
>

-- 
*Lincoln Lavoie*
Senior Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylavoie@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu/>

[-- Attachment #2: Type: text/html, Size: 4083 bytes --]

<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi David,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Did you get any response to this from the Intel folks?  Should we add a bug to track this for discussion / review at our meeting next week?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,<br>Lincoln</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 23, 2020 at 3:07 AM David Marchand &lt;<a href="mailto:david.marchand@redhat.com">david.marchand@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
(It looks like I have no luck with CI those days... :-)).<br>
<br>
All patches of a series of mine<br>
(<a href="https://patchwork.dpdk.org/project/dpdk/list/?series=10551" rel="noreferrer" target="_blank">https://patchwork.dpdk.org/project/dpdk/list/?series=10551</a>) are<br>
marked as failing all compilation in Intel CI.<br>
<br>
- Is it normal to see all patches with the exact same test report?<br>
Patch 1: <a href="http://mails.dpdk.org/archives/test-report/2020-June/137872.html" rel="noreferrer" target="_blank">http://mails.dpdk.org/archives/test-report/2020-June/137872.html</a><br>
Patch 9: <a href="http://mails.dpdk.org/archives/test-report/2020-June/137880.html" rel="noreferrer" target="_blank">http://mails.dpdk.org/archives/test-report/2020-June/137880.html</a><br>
<br>
UNH and ovsrobot only report once when testing a full series.<br>
It makes more sense if Intel CI only tests full series.<br>
<br>
<br>
- Putting the first point aside, and focusing on patch 9 error:<br>
<a href="http://mails.dpdk.org/archives/test-report/2020-June/137880.html" rel="noreferrer" target="_blank">http://mails.dpdk.org/archives/test-report/2020-June/137880.html</a><br>
<br>
../drivers/mempool/bucket/rte_mempool_bucket.c: In function ‘bucket_get_count’:<br>
../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit<br>
declaration of function ‘rte_lcore_iterate’; did you mean<br>
‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]<br>
  rte_lcore_iterate(count_per_lcore, &amp;ctx);<br>
  ^~~~~~~~~~~~~~~~~<br>
  rte_lcore_is_enabled<br>
../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested<br>
extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]<br>
cc1: all warnings being treated as errors<br>
<br>
<br>
This function is defined in rte_lcore.h which does seem to be<br>
included, seeing how the compiler suggests another<br>
rte_lcore_is_enabled function.<br>
The v2 revision passed fine<br>
(<a href="http://mails.dpdk.org/archives/test-report/2020-June/137552.html" rel="noreferrer" target="_blank">http://mails.dpdk.org/archives/test-report/2020-June/137552.html</a>) and<br>
I see no change in v3 that would break like this.<br>
<br>
I am a bit puzzled...<br>
One thing that comes to mind, do we have dpdk headers installed<br>
system-wide on the Intel CI server(s)?<br>
<br>
<br>
-- <br>
David Marchand<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b>Lincoln Lavoie</b><br></div><div>Senior Engineer, Broadband Technologies</div><div>21 Madbury Rd., Ste. 100, Durham, NH 03824</div><div><a href="mailto:lylavoie@iol.unh.edu" target="_blank">lylavoie@iol.unh.edu</a></div><div><a href="https://www.iol.unh.edu" target="_blank">https://www.iol.unh.edu</a></div><div>+1-603-674-2755 (m)<br></div><div><a href="https://www.iol.unh.edu/" target="_blank"><img src="http://homeautomation.lavoieholdings.com/_/rsrc/1390068882701/unh-iol-logo.png"></a></div></div></div></div></div></div></div></div></div></div></div></div>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-24 14:19 ` Lincoln Lavoie
@ 2020-06-25 14:20   ` David Marchand
  0 siblings, 0 replies; 8+ messages in thread
From: David Marchand @ 2020-06-25 14:20 UTC (permalink / raw)
  To: Lincoln Lavoie; +Cc: Chen, Zhaoyan, ci, sys_stv

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Wed, Jun 24, 2020 at 4:20 PM Lincoln Lavoie <lylavoie@iol.unh.edu> wrote:

> Hi David,
>
> Did you get any response to this from the Intel folks?  Should we add a
> bug to track this for discussion / review at our meeting next week?
>

I received no response yet, so you can create a bz to track this.
Thanks.


-- 
David Marchand

[-- Attachment #2: Type: text/html, Size: 930 bytes --]

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 24, 2020 at 4:20 PM Lincoln Lavoie &lt;<a href="mailto:lylavoie@iol.unh.edu">lylavoie@iol.unh.edu</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small">Hi David,</div><div style="font-size:small"><br></div><div style="font-size:small">Did you get any response to this from the Intel folks?  Should we add a bug to track this for discussion / review at our meeting next week?</div></div></blockquote><div><br></div><div>I received no response yet, so you can create a bz to track this.</div><div>Thanks.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">-- <br></div><div class="gmail_quote">David Marchand<br></div></div>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-23  7:07 [dpdk-ci] Failures reported by Intel CI for series 10551 David Marchand
  2020-06-24 14:19 ` Lincoln Lavoie
@ 2020-06-26  3:03 ` Chen, Zhaoyan
  2020-06-26  7:43   ` David Marchand
  1 sibling, 1 reply; 8+ messages in thread
From: Chen, Zhaoyan @ 2020-06-26  3:03 UTC (permalink / raw)
  To: David Marchand; +Cc: ci, sys_stv, Chen, Zhaoyan

Hi, David,

For your question, "Is it normal to see all patches with the exact same test report?"
Yes, we always test a series, rather than a single patch. You can see the exact same report 
on any patch in a series. (it's convenient, you don't need backward to search 
the header of the series, then check result)

" One thing that comes to mind, do we have dpdk headers installed system-
> wide on the Intel CI server(s)?"

Sure, we do. We don't see any problem on other patch compilation, so far. but it's strange 
that your V2 and V3 is same, but v3 test is failed. (code base is same). So I will try to re-run
your series(v3), and check what's changed on CI system between the 2 days. Is that helpful? 

Regards,
Zhaoyan Chen

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Tuesday, June 23, 2020 3:08 PM
> To: Chen, Zhaoyan <zhaoyan.chen@intel.com>
> Cc: ci@dpdk.org; sys_stv <sys_stv@intel.com>
> Subject: Failures reported by Intel CI for series 10551
> 
> Hello,
> 
> (It looks like I have no luck with CI those days... :-)).
> 
> All patches of a series of mine
> (https://patchwork.dpdk.org/project/dpdk/list/?series=10551) are marked
> as failing all compilation in Intel CI.
> 
> - Is it normal to see all patches with the exact same test report?
> Patch 1: http://mails.dpdk.org/archives/test-report/2020-
> June/137872.html
> Patch 9: http://mails.dpdk.org/archives/test-report/2020-
> June/137880.html
> 
> UNH and ovsrobot only report once when testing a full series.
> It makes more sense if Intel CI only tests full series.
> 
> 
> - Putting the first point aside, and focusing on patch 9 error:
> http://mails.dpdk.org/archives/test-report/2020-June/137880.html
> 
> ../drivers/mempool/bucket/rte_mempool_bucket.c: In function
> ‘bucket_get_count’:
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit
> declaration of function ‘rte_lcore_iterate’; did you mean
> ‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]
>   rte_lcore_iterate(count_per_lcore, &ctx);
>   ^~~~~~~~~~~~~~~~~
>   rte_lcore_is_enabled
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested
> extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]
> cc1: all warnings being treated as errors
> 
> 
> This function is defined in rte_lcore.h which does seem to be included,
> seeing how the compiler suggests another rte_lcore_is_enabled function.
> The v2 revision passed fine
> (http://mails.dpdk.org/archives/test-report/2020-June/137552.html) and I
> see no change in v3 that would break like this.
> 
> I am a bit puzzled...
> One thing that comes to mind, do we have dpdk headers installed system-
> wide on the Intel CI server(s)?
> 
> 
> --
> David Marchand


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-26  3:03 ` Chen, Zhaoyan
@ 2020-06-26  7:43   ` David Marchand
  2020-06-26 10:23     ` Thomas Monjalon
  0 siblings, 1 reply; 8+ messages in thread
From: David Marchand @ 2020-06-26  7:43 UTC (permalink / raw)
  To: Chen, Zhaoyan; +Cc: ci, sys_stv

On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan <zhaoyan.chen@intel.com> wrote:
>
> Hi, David,
>
> For your question, "Is it normal to see all patches with the exact same test report?"
> Yes, we always test a series, rather than a single patch. You can see the exact same report
> on any patch in a series. (it's convenient, you don't need backward to search
> the header of the series, then check result)

Convenience is subject to interpretation :-).
Other CI systems send a single report which is more sane for me.


>
> " One thing that comes to mind, do we have dpdk headers installed system-
> > wide on the Intel CI server(s)?"
>
> Sure, we do. We don't see any problem on other patch compilation, so far. but it's strange
> that your V2 and V3 is same, but v3 test is failed. (code base is same). So I will try to re-run
> your series(v3), and check what's changed on CI system between the 2 days. Is that helpful?

Just to be sure.
By this, you mean that you have some dpdk headers installed on the CI
system in /usr?

Having those headers most likely exacerbates races with dpdk headers
copy in the building directory.
This could be where my series failed.


-- 
David Marchand


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-26  7:43   ` David Marchand
@ 2020-06-26 10:23     ` Thomas Monjalon
  2020-06-30  5:59       ` Chen, Zhaoyan
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2020-06-26 10:23 UTC (permalink / raw)
  To: Chen, Zhaoyan; +Cc: ci, sys_stv, David Marchand

26/06/2020 09:43, David Marchand:
> On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan <zhaoyan.chen@intel.com> wrote:
> >
> > Hi, David,
> >
> > For your question, "Is it normal to see all patches with the exact same test report?"
> > Yes, we always test a series, rather than a single patch. You can see the exact same report
> > on any patch in a series. (it's convenient, you don't need backward to search
> > the header of the series, then check result)
> 
> Convenience is subject to interpretation :-).
> Other CI systems send a single report which is more sane for me.

I think these tests have 2 purposes:
	- sending quick error feedback to the author
	- check that all is green before merging
In both cases we don't need to have the same report duplicated,
because we check for failures in all patches anyway.

I suggest sending the series report only on the last patch of the series.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-26 10:23     ` Thomas Monjalon
@ 2020-06-30  5:59       ` Chen, Zhaoyan
  2020-06-30  7:13         ` Thomas Monjalon
  0 siblings, 1 reply; 8+ messages in thread
From: Chen, Zhaoyan @ 2020-06-30  5:59 UTC (permalink / raw)
  To: Thomas Monjalon, David Marchand, ci; +Cc: sys_stv, Chen, Zhaoyan

Hi all,

I have updated the info for this issue in bugzilla.


We have re-built the patchset. It was passed. The root cause is that patches in the  series are disorder by patchid. (patch 7/9 and patch 8/9). Usually, we apply patches by the order of patch id in a series. 

Why the issue is exposed this time?

Meet 2 conditions,
- the patches are disorder in the series
- the disordered patches are modified same file

Solution
- Change applying patch order by patch date, rather than patch id in patchwork.
But we don't know if patch date is unique and ordered for each patch in the series. 
We need patchwork document to confirm. So far, its good.


For Thomas' suggestion, "sending the series report only on the last patch of the series", currently, I find all reports iol-* are sent to the first patch in the series. Shall we align? and shall we get feedback from all maintainers or developers in the community?



Regards,
Zhaoyan Chen

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, June 26, 2020 6:24 PM
> To: Chen, Zhaoyan <zhaoyan.chen@intel.com>
> Cc: ci@dpdk.org; sys_stv <sys_stv@intel.com>; David Marchand
> <david.marchand@redhat.com>
> Subject: Re: [dpdk-ci] Failures reported by Intel CI for series 10551
> 
> 26/06/2020 09:43, David Marchand:
> > On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan
> <zhaoyan.chen@intel.com> wrote:
> > >
> > > Hi, David,
> > >
> > > For your question, "Is it normal to see all patches with the exact same
> test report?"
> > > Yes, we always test a series, rather than a single patch. You can
> > > see the exact same report on any patch in a series. (it's
> > > convenient, you don't need backward to search the header of the
> > > series, then check result)
> >
> > Convenience is subject to interpretation :-).
> > Other CI systems send a single report which is more sane for me.
> 
> I think these tests have 2 purposes:
> 	- sending quick error feedback to the author
> 	- check that all is green before merging In both cases we don't
> need to have the same report duplicated, because we check for failures in
> all patches anyway.
> 
> I suggest sending the series report only on the last patch of the series.
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-ci] Failures reported by Intel CI for series 10551
  2020-06-30  5:59       ` Chen, Zhaoyan
@ 2020-06-30  7:13         ` Thomas Monjalon
  0 siblings, 0 replies; 8+ messages in thread
From: Thomas Monjalon @ 2020-06-30  7:13 UTC (permalink / raw)
  To: Chen, Zhaoyan; +Cc: David Marchand, ci, sys_stv

I replied in Bugzilla.
Let's not duplicate the discussion please.
At this point, we should continue in Bugzilla.
Thanks

30/06/2020 07:59, Chen, Zhaoyan:
> Hi all,
> 
> I have updated the info for this issue in bugzilla.
> 
> 
> We have re-built the patchset. It was passed. The root cause is that patches in the  series are disorder by patchid. (patch 7/9 and patch 8/9). Usually, we apply patches by the order of patch id in a series. 
> 
> Why the issue is exposed this time?
> 
> Meet 2 conditions,
> - the patches are disorder in the series
> - the disordered patches are modified same file
> 
> Solution
> - Change applying patch order by patch date, rather than patch id in patchwork.
> But we don't know if patch date is unique and ordered for each patch in the series. 
> We need patchwork document to confirm. So far, its good.
> 
> 
> For Thomas' suggestion, "sending the series report only on the last patch of the series", currently, I find all reports iol-* are sent to the first patch in the series. Shall we align? and shall we get feedback from all maintainers or developers in the community?
> 
> 
> 
> Regards,
> Zhaoyan Chen
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Friday, June 26, 2020 6:24 PM
> > To: Chen, Zhaoyan <zhaoyan.chen@intel.com>
> > Cc: ci@dpdk.org; sys_stv <sys_stv@intel.com>; David Marchand
> > <david.marchand@redhat.com>
> > Subject: Re: [dpdk-ci] Failures reported by Intel CI for series 10551
> > 
> > 26/06/2020 09:43, David Marchand:
> > > On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan
> > <zhaoyan.chen@intel.com> wrote:
> > > >
> > > > Hi, David,
> > > >
> > > > For your question, "Is it normal to see all patches with the exact same
> > test report?"
> > > > Yes, we always test a series, rather than a single patch. You can
> > > > see the exact same report on any patch in a series. (it's
> > > > convenient, you don't need backward to search the header of the
> > > > series, then check result)
> > >
> > > Convenience is subject to interpretation :-).
> > > Other CI systems send a single report which is more sane for me.
> > 
> > I think these tests have 2 purposes:
> > 	- sending quick error feedback to the author
> > 	- check that all is green before merging In both cases we don't
> > need to have the same report duplicated, because we check for failures in
> > all patches anyway.
> > 
> > I suggest sending the series report only on the last patch of the series.
> > 
> 
> 






^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-23  7:07 [dpdk-ci] Failures reported by Intel CI for series 10551 David Marchand
2020-06-24 14:19 ` Lincoln Lavoie
2020-06-25 14:20   ` David Marchand
2020-06-26  3:03 ` Chen, Zhaoyan
2020-06-26  7:43   ` David Marchand
2020-06-26 10:23     ` Thomas Monjalon
2020-06-30  5:59       ` Chen, Zhaoyan
2020-06-30  7:13         ` Thomas Monjalon

DPDK CI discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/ci/0 ci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ci ci/ http://inbox.dpdk.org/ci \
		ci@dpdk.org
	public-inbox-index ci


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.ci


AGPL code for this site: git clone https://public-inbox.org/ public-inbox