From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6647450695491387392 X-Received: by 2002:a2e:300d:: with SMTP id w13-v6mr319715ljw.16.1548267223338; Wed, 23 Jan 2019 10:13:43 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:8681:: with SMTP id l1-v6ls462255lji.0.gmail; Wed, 23 Jan 2019 10:13:42 -0800 (PST) X-Google-Smtp-Source: ALg8bN5icukQjtRVG/TxAG5admcEtGapYeEWRbEo064gdYr2Q9CAx0YbrmXrlI+UosvEsLSh6VH7 X-Received: by 2002:a2e:844d:: with SMTP id u13-v6mr316095ljh.17.1548267222729; Wed, 23 Jan 2019 10:13:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548267222; cv=none; d=google.com; s=arc-20160816; b=FKzTo9UnjAcYuEbys/kn37VCmt32stDp/4GnSWuZMFBCYwdE020s3XyYtSXTkLQ1U4 ICanpo/YVeQEHJIX2Ey+g4cm/9CXXd9iNl1LoEopjk0AFLDs6j1rEQ5utjFOOdVt6iOZ 5FIs/i+eb/5m3K0gx+TpvbLYmUT0a3koUXS++KS+gZe+FcUAG/hjoFFwQKNl1o2xh9y3 zV0UhkUS0RZd1FiWg4rAHTuGW/Ho3MtsdsclF/uJ2xdbWm3GB9u6XS+eJjE4/sZMuuzJ +C9uMCCgHIw1w0hhfxuusZyIyIokbcVZRwBJtcZAizOvRIyoFCNG0Jag7TBhx7ueedaf s+Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=UOq0O8Ho1CFphMB2r3xsxG5kIgMbRl6RnsBKBAhYX48=; b=ki7kGgpj9KLRpvurV2tfwbUgYROqRGsHz/T/7p/OF7Y3LRhjNNc5ya2WIJ+WbkMMmH YVHuB3JaEKiO8fWDxgQ1rG3ISZnnknBbG77wDZrnk2YQc4j6xQQiEsoCb2aQWsQD0Dij 2aodPSsibbbQ1wvMxi3uu+UZkQitR3hFwlo8Yn2HPVZUWprkhfpZOVvBcR7lkCE6igr1 kQGvmxcTN4hqurLzpMqoETNUrm3t0MytYDdlPgMGl64PMC9W3MB0MuDommKx0YfcKaOU dbW3Qux79RGU/2J7BiDxNn7oV5jhFyMRW6vmuv2PeRd6gPmBxrIthQMNvNYnGQoz3/Pq Shgg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id 81-v6si117759ljc.2.2019.01.23.10.13.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 10:13:42 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x0NIDffe015956 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 23 Jan 2019 19:13:41 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.0.45]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x0NIDf2a014167; Wed, 23 Jan 2019 19:13:41 +0100 Date: Wed, 23 Jan 2019 19:13:41 +0100 From: Henning Schild To: Jan Kiszka Cc: isar-users Subject: Re: [PATCH] linux-custom: skip linux-libc-dev deployment on downgrade Message-ID: <20190123191341.683395ab@md1za8fc.ad001.siemens.net> In-Reply-To: <20190123190323.5e346a25@md1za8fc.ad001.siemens.net> References: <20190117130342.15743-1-henning.schild@siemens.com> <20190123182303.4795f660@md1za8fc.ad001.siemens.net> <14dc306a-4db0-a8d4-6839-a2369369f372@siemens.com> <20190123183039.6b102065@md1za8fc.ad001.siemens.net> <471e7120-1541-5f07-1374-be86fc62d872@siemens.com> <20190123190323.5e346a25@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 5SPkxH95ZWU6 Am Wed, 23 Jan 2019 19:03:23 +0100 schrieb "[ext] Henning Schild" : > Am Wed, 23 Jan 2019 18:43:08 +0100 > schrieb Jan Kiszka : > > > On 23.01.19 18:30, Henning Schild wrote: > > > Am Wed, 23 Jan 2019 18:26:08 +0100 > > > schrieb Jan Kiszka : > > > > > >> On 23.01.19 18:23, [ext] Henning Schild wrote: > > >>> Ping > > >>> > > >> > > >> Looks good to me - what scenarios did you test? > > > > > > I know the breakages of buildchroot from layers, and the not > > > deploying the kernel downgrade helped fix the issues. > > > In this repo i honestly only tested the logic and whether the > > > warning will pop up. Tested a qemuamd64 with the cip kernel inside > > > Isar. > > > > OK, but we also have a "should upgrade" kernel recipe in Isar: > > linux-mainline_4.19.0. > > I just tested the "gt" operator of the comparator against the 4.9 that > we get in debian 9. It worked there so there is no reason to think it > will not work for 4.19. > > > > > One question on second thought: > > > > > + > > > +# linux-libc-dev causes dependency problems if we downgrade > > > +# remove it after the build so the downgraded version does not > > > get deployed +LINUX_LIBC_DEV_V=`dpkg-query --show --showformat > > > '${Version}' linux-libc-dev` +if dpkg --compare-versions > > > $LINUX_LIBC_DEV_V gt $PV; then > > > + rm -f linux-libc-dev_${PV}*.deb > > > +fi > > > > Isn't this assuming we have linux-libc-dev from Debian installed? Is > > that always valid? Wouldn't it be better to query the Debian repo > > specifically? > > Assuming you are installing only one kernel in your image, the command > will operate on linux-libc-dev from all repos but ours ... debian. > I guess if we are looking at images with multiple kernels, or > incremental builds that downgrade against their own upgrade ... things > could get tricky. Or actually not, in this case we want to get > notified about the downgrade in our repo. > > Say your debian official kernel is 4.9, your layer adds 4.14.42 and > you go back to 4.14.40 in an incremental build step. The upgrade from > 4.9 to 4.14.42 will be done as usual, and you should now receive the > warning about a downgrade that will not be performed. ... Not > tested ... In fact that might not be true. reprepro will probably drop the 4.14.42 so it will not be seen at install time of 4.14.40. But still we will always detect if we fall below the greatest version coming from a repo we do not manage ... the debian default or your other mirror. Henning > So i am guessing the logic is correct. For the multiple kernel case > (does that even exist?) one might have to ignore the warning or > enforce an install order with artificial dependencies. > > > Also: $(...) - `...` is old-style. > > Ok will fix. > > Henning > > > Jan > > >