Re: [PATCH v8 0/7] Fix usage of additional apt keys and repos

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 15 Apr 2019 15:14:39 +0200
schrieb Andreas Reichel <andreas.reichel.ext@siemens.com>:

> 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" <mosipov@ilbers.de>:
> >   
> > > 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.ext@siemens.com>
> > > >>>>
> > > >>>> 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    
> > > >     
> > > 
> > >   
> >   
>