On Tue, Feb 18, 2020 at 10:40 AM David Marchand <david.march...@redhat.com> wrote: > > On Mon, Feb 17, 2020 at 7:48 PM Aaron Conole <acon...@redhat.com> wrote: > > > > David Marchand <david.march...@redhat.com> writes: > > > > > libabigail 1.2 (at least) reports changes in 'const' property as an ABI > > > breakage [1]. > > > This was fixed upstream in libabigail 1.4 [2], and a bug has been opened > > > in launchpad [3]. > > > > > > 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.march...@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: https://docs.travis-ci.com/user/caching/ I tested Thomas change on extra_packages content, and the job used the old cache. 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. -- David Marchand
