From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B2A0AA054F; Tue, 18 Feb 2020 15:55:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B0271C011; Tue, 18 Feb 2020 15:55:43 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 195591C00F for ; Tue, 18 Feb 2020 15:55:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582037741; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1IHh2rwJkQLrNRRafE7OhcbzGGOVhtuxPPhS70ZYFmU=; b=I/ZeDOm9CRpv6tyoUPn7WM2q8ginPxC0ZA6BGoVY7XWrHGz/h9Kvx+GwCPLCVaCtMKV7PB Fe59iYc/AcOGTVJHvwJDGYVdwVWqHEq1dmbBFDixAUG2B+3Qkkq4JS0cB4ajsyNvMF81a4 4SCoT4bZQh9AgpA9/lNcJmE6XmqOijk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-340-U_-eSlbyPpy4jEFd01j1hw-1; Tue, 18 Feb 2020 09:55:31 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4A0CC113785A; Tue, 18 Feb 2020 14:55:30 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.126]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 683B4100164D; Tue, 18 Feb 2020 14:55:24 +0000 (UTC) From: Aaron Conole To: David Marchand Cc: Thomas Monjalon , dev , Christian Ehrhardt , Dodji Seketeli , Michael Santana References: <20200217135929.30987-1-david.marchand@redhat.com> Date: Tue, 18 Feb 2020 09:55:23 -0500 In-Reply-To: (David Marchand's message of "Tue, 18 Feb 2020 12:18:36 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: U_-eSlbyPpy4jEFd01j1hw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] ci: build and use libabigail 1.6 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" David Marchand writes: > On Tue, Feb 18, 2020 at 10:40 AM David Marchand > wrote: >> >> On Mon, Feb 17, 2020 at 7:48 PM Aaron Conole wrote: >> > >> > David Marchand 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 op= ened >> > > in launchpad [3]. >> > > >> > > But for now, build and use the last version 1.6 so that the ABI chec= ks >> > > can be kept. >> > > >> > > 1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242 >> > > 2: >> > > https://sourceware.org/git/gitweb.cgi?p=3Dlibabigail.git;a=3Dcommitd= iff;h=3D215b7eb4fe8b986fe1cc87d9d8e7412998038392 >> > > 3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/1863607 >> > > >> > > Signed-off-by: David Marchand >> > > --- >> > >> > 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