Re: Development branch updates

[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.

> 
> 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

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux