Re: Development branch updates

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

Am Fri, 30 Jun 2017 09:26:48 +0200
schrieb "Jan Kiszka" <jan.kiszka@siemens.com>:

> On 2017-06-29 22:47, Baurzhan Ismagulov wrote:
> > On Thu, Jun 29, 2017 at 04:33:07PM +0200, Jan Kiszka wrote:  
> >>> multiconfig:qemuamd64:isar-image-base is buildable again.  
> >>
> >> qemu-amd64  
> > 
> > Yes, lenormf/uefi_wic_amd64-20170428 has qemu-amd64, and
> > lenormf/develop-l20170602-dpkg-cross has qemuamd64.
> > 
> > First, the idea was to have nice GNU-like triplets, such as
> > qemu-amd64-stretch. However, when we looked at Yocto's runqemu, we
> > noticed that their machines are in form of qemuamd64.
> > 
> > I tend to move to the former and sacrifice the Yocto style familiar
> > to some people in favor of readable, explicit (and, hopefully,
> > complete) names. I think leaving the machines without the dash and
> > configurations with one wouldn't be good, either.
> > 
> >   
> >> BTW, the machine seems to be QEMU-agnostic -> rename to
> >> generic-amd64 or so?  
> > 
> > That's an interesting idea, never thought of that. Thanks for the
> > fresh view :) . One part of the issue is, the naming reflects how
> > we test it.
> > 
> >   
> >>> I'll be cherry-picking amd64, stretch and UEFI from
> >>> lenormf/develop-l20170602-dpkg-cross into master.  
> >>
> >> This seems to work fine for Internet. Proxies are biting us here
> >> (as usual), but this topic is bigger: I tried to pass http_proxy
> >> env down to multistrap, but there are still many places where it
> >> gets lost.  
> > 
> > Does https://github.com/ilbers/isar/pull/4 help?  
> 
> Nope because a) my host (the docker image) does and shall not contain
> persistent proxy setting (it has to be generic) and b) those settings
> should rather be injected via the environment.

Yes persistent configuration on a tool by tool basis is not the way to
go. Jan sudo often is the reason those env variables get lost, i
suppose you already have

> Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy"

in you sudo config? That does not hurt for roaming scenarios where you
sometimes need them and sometimes not.
The list of variables might be incomplete i.e. docker wants them in
capital letters.

Henning

> > 
> > I'm afraid, we'll end up with
> > https://github.com/ilbers/isar/issues/19.  
> 
> Right, this does not work yet. BB_ENV_WHITELIST is incomplete e.g.
> (also /wrt other means of downloads like ssh). But the environment is
> still lost elsewhere along the chain, definitely via sudo.
> 
> > 
> >   
> >> What I noticed is that I cannot overwrite DISTRO_APT_SOURCE in
> >> local.conf with a local mirror because of
> >>
> >> DISTRO_APT_SOURCE = "..."
> >>
> >> Any reason why we should not make them all
> >>
> >> DISTRO_APT_SOURCE ??= "..."
> >>
> >> ? Or is the plan rather to allow setting a set of mirrors and let
> >> the machinery pull from them when available, without local.conf
> >> overwrites?  
> > 
> > Will have a look. https://github.com/ilbers/isar/issues/20
> >   
> 
> Is there an idea regarding mirror configuration already? I suspect,
> [PRE]MIRROR will already work for fetching that bitbake does. Maybe it
> would be better to teach the multiconf generators to take them into
> account when transferring DISTRO_APT_SOURCE?
> 
> I guess that ticket should be broader then.
> 
> Jan
>