[dpdk-dev] [PATCH] ci: build and use libabigail 1.6
david.marchand at redhat.com
Tue Feb 18 12:18:36 CET 2020
On Tue, Feb 18, 2020 at 10:40 AM David Marchand
<david.marchand at redhat.com> wrote:
> On Mon, Feb 17, 2020 at 7:48 PM Aaron Conole <aconole at redhat.com> wrote:
> > David Marchand <david.marchand at redhat.com> writes:
> > > libabigail 1.2 (at least) reports changes in 'const' property as an ABI
> > > breakage .
> > > This was fixed upstream in libabigail 1.4 , and a bug has been opened
> > > in launchpad .
> > >
> > > But for now, build and use the last version 1.6 so that the ABI checks
> > > can be kept.
> > >
> > > 1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242
> > > 2: https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=commitdiff;h=215b7eb4fe8b986fe1cc87d9d8e7412998038392
> > > 3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607
> > >
> > > Signed-off-by: David Marchand <david.marchand at redhat.com>
> > > ---
> > Does it make sense to base libabigail required ontop of extra packages?
> > Otherwise some libraries won't get built / checked, no?
> The only change I see is the pcap driver being enabled.
> On the principle, I agree that trying to build all possible
> libraries/drivers is better when checking the ABI.
> So I'll keep extra_packages yes.
> I am currently testing that touching extra_packages (well, testing
> Thomas patches) results in Travis treating the job as a new one (i.e.
> with no cache).
Travis bases each job cache on the job description:
I tested Thomas change on extra_packages content, and the job used the
My idea was to try to put *extra_packages in an env variable, but it
does not work (my yaml-fu is lacking).
If there is no easy way, I will invalidate the cache manually.
More information about the dev