From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6436797916976775168 X-Received: by 10.25.219.67 with SMTP id s64mr4040142lfg.27.1498807610062; Fri, 30 Jun 2017 00:26:50 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.25.76.84 with SMTP id z81ls439715lfa.13.gmail; Fri, 30 Jun 2017 00:26:49 -0700 (PDT) X-Received: by 10.46.20.21 with SMTP id u21mr3428957ljd.22.1498807609649; Fri, 30 Jun 2017 00:26:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498807609; cv=none; d=google.com; s=arc-20160816; b=Gjg7q4biuEwHc0jDS+j6KyINE03BnhOeUuusfjYfN4DDGHVS920/RljCdz3HI+sEkC YQuxN8gz494RgTE6bBp9sa7aPrSXB7mLQMeYw9Srnx+p7LS5YITpVvWV6occSC0u6Mss l8Y/NjvZVS2Dd/uK+pYGpurmoxDz9bAzs4VUQOWDmjaSNZQCoZKVsa3l1LsyImuDNnat IswlI23vgp8ipYMSec02MDHyNE3eZ8dgIGlMd0bVPbZcyyIPtJ6e3TiHcpyVH36ZAN1P /K9J+9z84K2ZnwNFNLhrZktBCTUhp8rYao3M5barZpxDUb1iGUWgNHqDSlo3ZpMQ431j O85A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=8wigU+jh/1D65msRbzb4HgzZFDYzeAEbLoa4X1xPqzY=; b=o/ofpi6+NQgY5uvGyTd8EfC3qMRJT6YlSfR1MD6MzK4UoR1407U9tn6gI9UjSCkwcS RC5ebcBIoScp6902vRxEaQjIyDUnV7bVSJ2V8bPQRZehrTagqPOwQbj4BbfWkX9Mn9is LZ1dxUpaIsqIB8+HVx+XDstyyXggVcjY+wFAVdqW7glLYcADjLQQL6sjn02wwL/bVEkj lMoE2YJAGCJWjMz2yn0YIo1ThIj6y4EHE+3rXSx/Wo5cbj7dB+bf64g7IZQhpiSjT78I JgxUy/zq0MouGE84uYrPcTPHqYPSdD4Xf6Q6MQb0jGfLtu70wb3LIwEZyLssPmhE7vV+ BxUQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id b206si3498575wme.3.2017.06.30.00.26.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 00:26:49 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v5U7QmrF020504 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 30 Jun 2017 09:26:48 +0200 Received: from md1f2u6c.ww002.siemens.net ([146.254.78.65]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v5U7QmBM018597 for ; Fri, 30 Jun 2017 09:26:48 +0200 Subject: Re: Development branch updates To: isar-users@googlegroups.com References: <20170628210313.GA3941@yssyq.radix50.net> <71b64d59-76df-61cb-b931-96bee98ce543@siemens.com> <20170629204720.GB4317@yssyq.radix50.net> From: Jan Kiszka Message-ID: <67aae81b-8203-71c2-7637-e12151477bdb@siemens.com> Date: Fri, 30 Jun 2017 09:26:48 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20170629204720.GB4317@yssyq.radix50.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: kMNRj9j9hbBY 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