Development branch updates

Development branch updates

[Baurzhan Ismagulov]

Hello,

I've updated the following branches for the latest stretch updates:

master
lenormf/uefi_wic_amd64-20170428
lenormf/develop-l20170602-dpkg-cross

multiconfig:qemuamd64:isar-image-base is buildable again.

I'll be cherry-picking amd64, stretch and UEFI from
lenormf/develop-l20170602-dpkg-cross into master.

With kind regards,
Baurzhan.

Re: Development branch updates

[Jan Kiszka]

On 2017-06-28 23:03, Baurzhan Ismagulov wrote:
> Hello,
> 
> I've updated the following branches for the latest stretch updates:
> 
> master
> lenormf/uefi_wic_amd64-20170428
> lenormf/develop-l20170602-dpkg-cross

Thanks!

> 
> multiconfig:qemuamd64:isar-image-base is buildable again.

qemu-amd64

BTW, the machine seems to be QEMU-agnostic -> rename to generic-amd64 or so?

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

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?

Jan

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

Re: Development branch updates

[Baurzhan Ismagulov]

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?

I'm afraid, we'll end up with https://github.com/ilbers/isar/issues/19.


> 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


With kind regards,
Baurzhan.

Re: Development branch updates

[Jan Kiszka]

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

Re: Development branch updates

[Henning Schild]

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
> 

Re: Development branch updates

[Baurzhan Ismagulov]

On Wed, Jun 28, 2017 at 11:03:13PM +0200, Baurzhan Ismagulov wrote:
> I'll be cherry-picking amd64, stretch and UEFI from
> lenormf/develop-l20170602-dpkg-cross into master.

I've started merging in ibr/20170629-1-stretch_amd64_uefi. Amd64 and stretch
work. UEFI in lenormf/develop-l20170602-dpkg-cross requires wic. I couldn't
quickly implement UEFI without wic, so it seems it would be better to make the
leap forward and integrate wic as is, and improve it later.

With kind regards,
Baurzhan.

Re: Development branch updates

[Jan Kiszka]

On 2017-06-30 01:28, Baurzhan Ismagulov wrote:
> On Wed, Jun 28, 2017 at 11:03:13PM +0200, Baurzhan Ismagulov wrote:
>> I'll be cherry-picking amd64, stretch and UEFI from
>> lenormf/develop-l20170602-dpkg-cross into master.
> 
> I've started merging in ibr/20170629-1-stretch_amd64_uefi. Amd64 and stretch
> work. UEFI in lenormf/develop-l20170602-dpkg-cross requires wic. I couldn't
> quickly implement UEFI without wic, so it seems it would be better to make the
> leap forward and integrate wic as is, and improve it later.

I suppose it's orthogonal for other targets anyway. Then this sounds
reasonable to me.

Jan

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

Re: Development branch updates

[Baurzhan Ismagulov]

On Fri, Jun 30, 2017 at 09:27:46AM +0200, Jan Kiszka wrote:
> On 2017-06-30 01:28, Baurzhan Ismagulov wrote:
> > On Wed, Jun 28, 2017 at 11:03:13PM +0200, Baurzhan Ismagulov wrote:
> >> I'll be cherry-picking amd64, stretch and UEFI from
> >> lenormf/develop-l20170602-dpkg-cross into master.
> > 
> > I've started merging in ibr/20170629-1-stretch_amd64_uefi. Amd64 and stretch
> > work. UEFI in lenormf/develop-l20170602-dpkg-cross requires wic. I couldn't
> > quickly implement UEFI without wic, so it seems it would be better to make the
> > leap forward and integrate wic as is, and improve it later.
> 
> I suppose it's orthogonal for other targets anyway. Then this sounds
> reasonable to me.

It isn't orthogonal, so I've skipped rpi support and pushed
ibr/20170629-1-stretch_amd64_uefi. Amd64 + stretch + UEFI builds with bitbake +
wic and works with Tianocore. I'll clean it up and merge to master.

With kind regards,
Baurzhan.