David Marchand <david.march...@redhat.com> writes: > 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.
We don't actually use the EXTRA_PACKAGES variable for anything, so I guess it's probably okay to change the value and that should invalidate the cache. Most of the variables, in fact, could be checked for non-zero value rather than a specific positive value, and then it's easy to invalidate the cache by just bumping them. It's a thought (and kindof a hack). Or we can just use the travis CLI tool and delete the caches (we'll have to do that for the ovsrobot as well, I think). > > -- > David Marchand
