From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6669723628337102848 X-Received: by 2002:a2e:9116:: with SMTP id m22mr13325212ljg.216.1562670273097; Tue, 09 Jul 2019 04:04:33 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:53a8:: with SMTP id j8ls1504366lfh.11.gmail; Tue, 09 Jul 2019 04:04:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxaEygvusK0xlFIubEAxVNTpuBknoh7WR7TdhuCES47dNfa/09vL4UFynBSprWQeSB2zcuU X-Received: by 2002:a19:4a50:: with SMTP id x77mr11188700lfa.91.1562670272654; Tue, 09 Jul 2019 04:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562670272; cv=none; d=google.com; s=arc-20160816; b=lrLR1n1hNbDpeYMWXpPzAnlpoYFTBoKl2lR3Y8InC+xKH8J7knZA0jZcwrfrZKUL+l nLJZIxxncxXlFgvcdWux/43rVNMqz1k/9nHMvbhqRTzKXMYceereSBD5jzNMuuT1B5HP Ddr8eFUy3DF1lwrGmhOp63WIy7nwelopqkUmSouUwQ2JcmckMVUOtrDEFNeLq8l/A/Ht D2X4UPZpWkZs2fxo3vYyH5h06YRwQEb4BZBwtPwiFmsoR2ZXdsO6/eJTtniXenK0x7GY vaDRFo4Y0VRoAzZhrtJJ83A3QyYF0eLijDBuTabQQWa04233INA4fUmUdTaZNjwo0Y8u tRsg== 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=hJTrwVAQI2XKECdhPj+kMc6a0MkiQ0hF6wDJZYd+kQs=; b=L+b2tMFKhyh5udzfDW6DYnHIO3/ilqxNmaXNdw5o2YkyLuPzMqE8HaQ9bB4d4k9TKr UftewF+yyDpp/S+zGKjcHvULduvXhj1AeqINs5qfYWqxsgHHl2UV0EYTa3otcG+uHOwU H0K1+W8yjaFMbwbkJSKObWXBbt+s68yx3a8LAlAOmsouMn8Oily1yunBieStRhtEaauU ttHwdG7fXkaP3cO6JKUlgv+6ZlaZq+nNV8zj1SaiuzbodsJEllzgZqxfSCz8Juey8krs YG5AXue89d+eO49230PuvvSpE7MwXCvBaBLU+t7BC1LCqp2NYAnz2ge8+5+yXWE44i8A iqFg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id h13si711381lfm.4.2019.07.09.04.04.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 04:04:32 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x69B4VTI023628 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Jul 2019 13:04:32 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.69.153]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x69B4VFJ024072; Tue, 9 Jul 2019 13:04:31 +0200 Date: Tue, 9 Jul 2019 13:04:30 +0200 From: Henning Schild To: Andreas Reichel Cc: "Maxim Yu. Osipov" , Subject: Re: [PATCH v8 0/7] Fix usage of additional apt keys and repos Message-ID: <20190709130430.5e752b23@md1za8fc.ad001.siemens.net> In-Reply-To: <20190415131439.GA4888@iiotirae> References: <20190321151526.12001-1-andreas.reichel.ext@siemens.com> <20190325101939.GA11173@iiotirae> <20190325112835.GA4930@iiotirae> <20190412145228.333bc3f5@md1za8fc.ad001.siemens.net> <20190415131439.GA4888@iiotirae> X-Mailer: Claws Mail 3.17.3 (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: FJIDqhK2bhQu Am Mon, 15 Apr 2019 15:14:39 +0200 schrieb Andreas Reichel : > On Fri, Apr 12, 2019 at 02:52:28PM +0200, Henning Schild wrote: > > Am Mon, 25 Mar 2019 12:39:01 +0100 > > schrieb "Maxim Yu. Osipov" : > > > > > On 3/25/19 12:28 PM, Andreas Reichel wrote: > > > > On Mon, Mar 25, 2019 at 11:35:33AM +0100, Maxim Yu. Osipov > > > > wrote: > > > >> On 3/25/19 11:19 AM, Andreas Reichel wrote: > > > >>>> Not working yet: > > > >>>> qemuarm64-stretch with BASE_REPO_KEY and > > > >>>> do_cache_base_repo > > > >>>> > > > >>>> | gpgme gave error GPGME:54: Unusable secret key > > > >>>> > > > >>>> I have created a keypair inside the build container and > > > >>>> exported the public key to a file "blabla.key". Then I set > > > >>>> > > > >>>> BASE_REPO_KEY = "file:///build/blabla.key" > > > >>>> > > > >>>> Any idea? > > > >>>> > > > >>> There was actually no problem anymore. The KEY had to be in > > > >>> the gpg key ring which was expected by the normal user > > > >>> in /tmp/tmpb6et85_1/.gnupg, not /home/builder/.gnupg. After > > > >>> readding the secrect key for the normal build user, it worked. > > > >>> > > > >>> I have just triggered a CI build on ilbers-ci. After that is > > > >>> green, you can apply my patchset. > > > >> > > > >> Just FYI: > > > >> > > > >> I test patchsets independently before applying them into the > > > >> tree. > > > >> > > > >> Meanwhile I encourage people to use CI build before sending > > > >> patchset to the mailing list (if this is not RFC) to avoid > > > >> unnecessary patchsets iterations. > > > >> > > > >> > > > >> The automated CI test procedure consists actually from the two > > > >> steps: > > > >> > > > >> 1) "fast" CI build/smoke test (by passing the key '-f' to > > > >> corresponding ci_build.sh and vm_smoke_test scripts) - it tests > > > >> cross compilation for three supported stretch QEMU targets and > > > >> one de0-nano-soc target. > > > >> > > > >> 2) "standard" CI build - it tests native build for the almost > > > >> full set of QEMU targets. > > > >> > > > >> > > > >> If the new feature is added to the ISAR it's always desirable > > > >> to add corresponding test case into the CI. > > > >> > > > > In this case it means we/I should add a test case where the > > > > docker upstream repo is added and an image with docker is > > > > built. > > > > > > I hope that your feature is generic enough to add some simpler > > > (not docker) third party repo for testing purposes. > > > > On the repo level they probably all are equally "simple". However, i > > would not trust the docker one to work repeatedly and stable for all > > suites/arches. I know it provides broken init scripts, that suggest > > they do not do much more than "works for me" testing. > > > > This could be a better example: > > https://wiki.x2go.org/doku.php/wiki:repositories:debian > > > > This seems to be a worst-case example :), since the keys are not > provided via URL but via package/key server, where the key-server > protocol is blocked from Siemens intranet. So this has nothing to do > with any apt key URI, but provides a completely new case to be tested > and is out of scope for my patch set. Well another mechanism for this one, meaning that this one was not a good candidate. But meaning that docker should have gone upstream for CI tests! Henning > Andreas > > > Henning > > > > > Regards, > > > Maxim. > > > > > > > > > > Let's say it is a generalization of an existing feature :) > > > > > > > > Regards, > > > > Andreas > > > >> > > > >> Regards, > > > >> Maxim. > > > >> > > > >> > > > >> > > > >>> Regards > > > >>> Andreas > > > >>> > > > >>>> Signed-off-by: Andreas Reichel > > > >>>> > > > >>>> > > > >>>> Andreas Reichel (7): > > > >>>> Revert "isar-bootstrap: Allow to set local keys in > > > >>>> DISTRO_APT_KEYS" Remove duplicate code from apt-keyring > > > >>>> generation Fix fetched key location in apt-keyring generator > > > >>>> Use apt-key to generate keyrings > > > >>>> If we use a custom keyring debootstrap may fall to https > > > >>>> raspbian-jessie: Use DISTRO_BOOTSTRAP_KEYS > > > >>>> docs: Update user_manual.md > > > >>>> > > > >>>> doc/user_manual.md | 7 +- > > > >>>> meta-isar/conf/distro/raspbian-jessie.conf | 2 +- > > > >>>> .../conf/multiconfig/qemuamd64-buster.conf | 1 - > > > >>>> .../conf/multiconfig/qemuamd64-jessie.conf | 1 - > > > >>>> meta/conf/bitbake.conf | 1 + > > > >>>> .../isar-bootstrap/isar-bootstrap-host.bb | 4 +- > > > >>>> .../isar-bootstrap/isar-bootstrap-target.bb | 4 +- > > > >>>> .../isar-bootstrap/isar-bootstrap.inc | 95 > > > >>>> +++++++++++++------ 8 files changed, 79 insertions(+), 36 > > > >>>> deletions(-) > > > >>>> > > > >>>> -- > > > >>>> 2.21.0 > > > >>>> > > > >>> > > > >> > > > >> > > > >> -- > > > >> Maxim Osipov > > > >> ilbers GmbH > > > >> Maria-Merian-Str. 8 > > > >> 85521 Ottobrunn > > > >> Germany > > > >> +49 (151) 6517 6917 > > > >> mosipov@ilbers.de > > > >> http://ilbers.de/ > > > >> Commercial register Munich, HRB 214197 > > > >> General Manager: Baurzhan Ismagulov > > > > > > > > > > > > >