From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 141E2A054F; Tue, 18 Feb 2020 16:08:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 485E11C00D; Tue, 18 Feb 2020 16:08:09 +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 C682C1BFF7 for <dev@dpdk.org>; Tue, 18 Feb 2020 16:08:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582038487; 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=JUSI0HDpfDVY83dcVjAJCcmuL2AvLGnun2PKZKucTo0=; b=J0g5+qQyN9G8NYsABFCbChbUCYQr2UXJa/trB/G0rR6/6aCP1+PWq22lZuOivTEZOrkjKb Hd48oRdfFF2sxnlZWEXzYzZ+H54m0vX2ZpZyN8eZwx1SW6WvcLeVDBIQwPqfmbC5Gk0M1f tzPyUjcXx/Ga+4Wsd/ovjVvgGgh2u9o= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-174-2qTOBTWANqaTYeb1Fp1YSQ-1; Tue, 18 Feb 2020 10:07:57 -0500 Received: by mail-ua1-f71.google.com with SMTP id j16so4027593uak.16 for <dev@dpdk.org>; Tue, 18 Feb 2020 07:07:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nELpXnLZueAOSR4JslFEfU+f9+Jhbcf3wvkD751CaeU=; b=f0CJDz58cKy1IFKKmyt8wQ4VTyibxsyReq09pXYKX5w8oyWhFKhycY9SW+tgk+HaeR kBzDwS1cfm3ZqsEJvM8A0Yv2b4n0F7rSyUev79Ibc8T/HyghzxCLzt9Rvuel3UObuBON W96woWau1/+rtvRyUKCZqHaIU8gYa8nC8VVMi8R9kgkyqtBJCF6CzYeRytsUQG8g04kq bzcP8hvNLP9t6hkDJmQ0j6KPEpHT8241Fo/n21u+NoJLTBI45tJvI2PM6GzAZEsteCcF Ut9lV7E+DH6eJ5X2GXNaSlg8c+aamqk54iI+qAoTkHsAVpnfgDUaBzI7FPo0ncdh8380 dcFw== X-Gm-Message-State: APjAAAVAyacDCXTXHA3hu4WuIORFrpMJlceTY37KmJXXKqKkcXMoFJJX /JdqpkQ1M5dd1kbZ2kkbRJ0PZDL278+N5HNzdQETfI533u8I6mgxiNHwEehy+m1LKEDIrKAStY0 Dqp7ch4bKqJqwaeZQ6lE= X-Received: by 2002:a67:b303:: with SMTP id a3mr11493697vsm.141.1582038476637; Tue, 18 Feb 2020 07:07:56 -0800 (PST) X-Google-Smtp-Source: APXvYqyaT3MCaU40O8RwdEVhc6kvhZSvCgQJ073ZDBm4fZ38kglROYx1Zq3b8kQvQ64b8zdWKa26YEcDUnAjavzFAwE= X-Received: by 2002:a67:b303:: with SMTP id a3mr11493666vsm.141.1582038476124; Tue, 18 Feb 2020 07:07:56 -0800 (PST) MIME-Version: 1.0 References: <20200217135929.30987-1-david.marchand@redhat.com> <f7tftf9uk2y.fsf@dhcp-25.97.bos.redhat.com> <CAJFAV8xNg=La+90vH=Ry1u0KDWcbKSyTNaN6e896=GLwxRnrkQ@mail.gmail.com> <CAJFAV8zu2Vwicrp0CG34ZAxgv9s=u_80-wp7AGyEYrthPWamyQ@mail.gmail.com> <f7timk4j678.fsf@dhcp-25.97.bos.redhat.com> In-Reply-To: <f7timk4j678.fsf@dhcp-25.97.bos.redhat.com> From: David Marchand <david.marchand@redhat.com> Date: Tue, 18 Feb 2020 16:07:45 +0100 Message-ID: <CAJFAV8xq=ho64zgj6MqjiTTqwvwDyeDGAnC1SAKueU39BWU-pw@mail.gmail.com> To: Aaron Conole <aconole@redhat.com> Cc: Thomas Monjalon <thomas@monjalon.net>, dev <dev@dpdk.org>, Christian Ehrhardt <christian.ehrhardt@canonical.com>, Dodji Seketeli <dodji@redhat.com>, Michael Santana <maicolgabriel@hotmail.com> X-MC-Unique: 2qTOBTWANqaTYeb1Fp1YSQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Tue, Feb 18, 2020 at 3:55 PM Aaron Conole <aconole@redhat.com> wrote: > > David Marchand <david.marchand@redhat.com> writes: > > > On Tue, Feb 18, 2020 at 10:40 AM David Marchand > > <david.marchand@redhat.com> wrote: > >> > >> On Mon, Feb 17, 2020 at 7:48 PM Aaron Conole <aconole@redhat.com> wrot= e: > >> > > >> > David Marchand <david.marchand@redhat.com> writes: > >> > > >> > > libabigail 1.2 (at least) reports changes in 'const' property as a= n 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 ch= ecks > >> > > can be kept. > >> > > > >> > > 1: https://travis-ci.com/DPDK/dpdk/jobs/287872118#L2242 > >> > > 2: > >> > > https://sourceware.org/git/gitweb.cgi?p=3Dlibabigail.git;a=3Dcommi= tdiff;h=3D215b7eb4fe8b986fe1cc87d9d8e7412998038392 > >> > > 3: https://bugs.launchpad.net/ubuntu/+source/libabigail/+bug/18636= 07 > >> > > > >> > > Signed-off-by: David Marchand <david.marchand@redhat.com> > >> > > --- > >> > > >> > Does it make sense to base libabigail required ontop of extra packag= es? > >> > 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). > What I had in mind was to convert the extra_packages yaml thing into a string to pass into EXTRA_PACKAGES. But I did not manage. About bumping the value, users are likely to be unaware of this step if they submit a patch touching .travis.yml. Deleting the caches from ovsrobot if .travis.yml has been touched seems sim= pler. On master, I will stick to manual cache invalidation. --=20 David Marchand -- David Marchand