From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6436797916976775168 X-Received: by 10.46.69.7 with SMTP id s7mr7234991lja.18.1499163012531; Tue, 04 Jul 2017 03:10:12 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.148.201 with SMTP id w192ls2013005wmd.4.gmail; Tue, 04 Jul 2017 03:10:12 -0700 (PDT) X-Received: by 10.223.130.73 with SMTP id 67mr5751658wrb.21.1499163012134; Tue, 04 Jul 2017 03:10:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499163012; cv=none; d=google.com; s=arc-20160816; b=bRfojW6tBqrrtX7AdLntpjtahTQXLquGpxfL8hIAkHwZPP2TaiuHJ8f9tsRGPlNBti pc8w/7NxAgpBgQBIgnlm8gAP4W1F/q0SeF3weWODJWK8CrOSwOkuz6CZplZNVkx2Y/aY 2WDOqrC7mnIf3E5kkjCeHfIIuYiij2UNIgwAQvJcmheKdXv9aEMhLyLt4P/2A2gbPhU4 B0L+EopZTpR731VWW1FeAALVbaPhcTu5ZTVOCwpLjjzf5Cjd7ykI+q67HMXPRjDw992A ogF6qRCTCxhQz6FmmQrZcnrYrZ0UYxBJqmnlLeg3kndJ4SxZIeYYfZRB0lmxdaoGhuP4 fYqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=0aRrhlOAv9SAxpm0nem8wNirJlc1Nfp8NsNKx4YWuZc=; b=iKWwjPW5kzdAUnW5c9xZE+b+M6f2OlKgO9i4maR4BQkVwRapETTW6zQt1TOcbGQkmE WAi2p9tBGuTl7vMAbSj8GzJXotRsUQRDhA6FL+O16ZAOEDvAoMZaErKHs127XI08nNuc 7svzkvd6v1MFQNgiS67faYAh/jqGFyoXkLOGX3jktjIwG6+sZ64SEIX36tYuT5XP6DiK WYG3MTBBklIE96Pp9R5Fm4BQXvvyIMRGR+beut03mBh+20OAOJrDNdoTgUBcjyROF3fv PT58Gq8SOSYz+CGIbPmIqcvOB1usLsoYqtIXc0NdtIJ1hMseYeSmZhyNnYyVOwOKbhjT Mwcg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id t16si6505420wmt.3.2017.07.04.03.10.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 03:10:12 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v64AABLd003521 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 4 Jul 2017 12:10:11 +0200 Received: from md1em3qc ([146.254.77.72]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v64AAA7m031158; Tue, 4 Jul 2017 12:10:11 +0200 Date: Tue, 4 Jul 2017 12:11:52 +0200 From: Henning Schild To: "Jan Kiszka" Cc: Subject: Re: Development branch updates Message-ID: <20170704121152.6fcc4b11@md1em3qc> In-Reply-To: <67aae81b-8203-71c2-7637-e12151477bdb@siemens.com> References: <20170628210313.GA3941@yssyq.radix50.net> <71b64d59-76df-61cb-b931-96bee98ce543@siemens.com> <20170629204720.GB4317@yssyq.radix50.net> <67aae81b-8203-71c2-7637-e12151477bdb@siemens.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 0jnhTQB0XeZl Am Fri, 30 Jun 2017 09:26:48 +0200 schrieb "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. 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 >