From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7023151278367703040 X-Received: by 2002:ac2:52a1:: with SMTP id r1mr23256300lfm.473.1635282951954; Tue, 26 Oct 2021 14:15:51 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:3499:: with SMTP id v25ls1108745lfr.0.gmail; Tue, 26 Oct 2021 14:15:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMS3uLNzKo1N5cycP5vNGgk6rCWuSQBR8YBVfeRnus0NZorjydRvzxFFGSiJpqec4uzDZR X-Received: by 2002:a05:6512:e9d:: with SMTP id bi29mr19151967lfb.201.1635282950852; Tue, 26 Oct 2021 14:15:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635282950; cv=none; d=google.com; s=arc-20160816; b=V0CkDqXBQjQKGvXy4rLz2sjmFjboWcKouQgs9dZh0CR9dB2dfNJGHtv4KMkppdT/3e GuzwX4zgtn5iZNfVLGMCTG4aqIhx3Wl/k/gsJEEGzkD/ssH3s5fAw1Rdel4m/nQsxmQo aUCqgsejfd7B60GWwsWOR3R2gFQH4SUFHxJhiTYFkFYXIM54BeQ3L4sOXzz9FPBpwjSK gJEdVckv7ELTroup3F2JLZmFwfrsE74xxWa7v/Pe20HdWPwFujx+FfRbb/B9LceR7AR9 EPpDCOevlC2ccNMS/us/rXKvlR+kmI471oXd1fYsTxLJFXkYI3oHV+vHLtaGAzoaiOjv Fr0w== 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; bh=Ct3qbwxFSOykophZxQVe/H6VZH25Yh8wSDJLWa6PRUM=; b=olKx7tj2wxdggBlOAhpjeJvBKgKOcrglG3szLOzU/EHOF1gvh0N/sGoWJLBV4ZbWte viLGO1TKJbqorPkRjmr2KkMw5PIyAVEh7W2SwyLSd325EI+fxEl1gerGaZ7X4GFQwpcD BUlsOyWuUxy2NWs5ufw1+N1/+OjctxQEHCiNiv/CDigYF2B2z2EgTt8aOKia7TI7FYcq 16yhEArxgziYKe2hJq7u1+wS0jGtxqwyo55ouhvyWn8ltqmJIbNB6zZTJDSGqYzGhakB aBIcrKRWGEMyk1K0bc/9VSyN51ZXe4/6p5IaUGHY+9AgIePd2ATqBXp0JE4v66AUXY1I sYlQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id t12si1508205ljh.0.2021.10.26.14.15.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Oct 2021 14:15:50 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 19QLFnJB003930 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Oct 2021 23:15:49 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.32.154]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 19QLFmr2028332; Tue, 26 Oct 2021 23:15:49 +0200 Date: Tue, 26 Oct 2021 23:15:45 +0200 From: Henning Schild To: ydirson@free.fr Cc: Anton Mikanovich , isar-users@googlegroups.com Subject: Re: isar-bootstrap Message-ID: <20211026231545.74e85f5d@md1za8fc.ad001.siemens.net> In-Reply-To: <849250711.1347880253.1635281333166.JavaMail.root@zimbra39-e7> References: <20211026214408.22030b2f@md1za8fc.ad001.siemens.net> <849250711.1347880253.1635281333166.JavaMail.root@zimbra39-e7> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: lIWiCRXMDXQy Am Tue, 26 Oct 2021 22:48:53 +0200 (CEST) schrieb ydirson@free.fr: > > For the download Isar goes the pragmatic way and lets debian fetch > > what > > it wants. With a few exceptions ... i.e. there is only one "global > > apt-get update" so you have to hope that you can apt-get install > > what that initial run created your external database for. In > > practice that does not fail too ofter ... or you have to clean > > build again. > > > > If you really need to pin debian down to what it fetches, because > > for some reason (like repro build) you need your own mirror. In > > fact Isar spits out a partial debian mirror after an "online" build > > (base-apt). That can be used for consecutive offline builds, or as > > a base for consecutive "online" builds with custom > > DISTRO_APT_SOURCES. > > > > While snapshots.debian.org can be used as DISTRO_APT_SOURCES mirror > > in > > theory ... in practice it has rate-limiting in place. So you might > > succeed in a manual build that you retry over and over (or a small > > image), but in CI without caching ... you will never get a big image > > to > > build. That rate-limiting issue will need to be discussed with > > snapshots, we are not the first ones to have issues with it. > > But i personally would tell people to simply not freeze if they can, > > and the ones that need to freeze i would in fact tell to get a full > > debian mirror of their own, instead of a partial one produced by > > isars > > base-apt. > > As an OSS project you might see less of a need of freezing, tracking > > in > > fact is a security feature ... and debian will not do much more than > > security on their stable distros. > > This is more of a concern for reproducibility of the build process > at package level. Probably this was not published very widely, but > there has been work on Debian package reproducibility in the context > of Qubes already, including a solution to the snapshots.d.o problem: > > https://forum.qubes-os.org/t/reproducible-builds-for-debian-a-big-step-forward/6800 Cool stuff! I will give that service a try and look into where the tool debrebuild comes into play. A tool that might in itself add some value. But to me it all seems like a workaround of the rate-limiting on snapshots. A problem that can maybe be solved with funding, in case it is a cost-problem. In Siemens people end up with their own implementations of snapshots, which in sum likely costs more than funding the real one for public non-limited use (together with other stakeholders). Still getting funding right and stable might be harder than any costly workaround downstream. I think i also heard trust arguments against snapshots, but those might just be pointless. Even if it is not-Debian (is it?) there will be gpg in place, but then you still need to trust that you get what you asked for because if a snapshot holds back a security update gpg would not be able to tell. But yes, good stuff! I bet that can be used in Isar somehow, but maybe only in your layers. You might not want the load from others on your infra. And the amd64 limitation is kind of severe. We have arm64 becoming more and more relevant and even riscv working for early prototypes. And i686 and arm32 floating around in places for some time to be maintained. Henning > Best regards,