From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id HzjzFsB8w15nDgAA0tVLHw (envelope-from ) for ; Tue, 19 May 2020 06:29:20 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id GJpKEsB8w15IDAAAB5/wlQ (envelope-from ) for ; Tue, 19 May 2020 06:29:20 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8F4A4940309 for ; Tue, 19 May 2020 06:29:19 +0000 (UTC) Received: from localhost ([::1]:51982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1javkc-0003im-Ho for larch@yhetil.org; Tue, 19 May 2020 02:29:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1javkT-0003i4-O4 for guix-devel@gnu.org; Tue, 19 May 2020 02:29:09 -0400 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:42902) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1javkS-000538-C4 for guix-devel@gnu.org; Tue, 19 May 2020 02:29:09 -0400 Received: by mail-lj1-x22f.google.com with SMTP id d21so12410026ljg.9 for ; Mon, 18 May 2020 23:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O919wCkC86CS0kAMlSXyb3Q7q7vQXGRiAgEEeNO+rEg=; b=saTBjpgvUicj26G4jdf1fMaGsXsnqKQVHYXuvrCojvFD0fzfESyJycI2KNzt4VzMdi BHg0G/V/CClz7J+woNx7rlcTGlgIgwwXVbKuUR9aN5JL0GcflEIdgBaA4w/qtvxJ/9ck 2gHDJjN0pGzMlhrjoHoiRRuFhlo/duJk2+oRfsBLMqDYMIaPPec8yhm7DYl9XjhJ2KxD MhPAz+lhSG4vw+FAXE0JTqke4ehs4QmpKy+NuYnPjf4yjilACZ8Z7s6dggNdaKHby2ZR csaDgDAJ88bZZdZ0K8KVPbR7pt++cJww32rv1S6GPk0o9NSHMQZdhWQRt7HFcsbf6d1+ i7TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O919wCkC86CS0kAMlSXyb3Q7q7vQXGRiAgEEeNO+rEg=; b=R/xe1NidmQELPW4JsUJCVuWz4pVRPqSk1eD5PqnsNOjN0saiAB4a//eAArezEmPUg+ UPJOjxo//5oMZK48tTvqctSDy3z3tQep9WFKUDRpZkZinzWhYSTEM8IL1ugFhuAftM1w KZbW6ypSFXE8H4QccB5XLuiD7Vt5nHMzzLDKUBKyAQA8pAMlVKmwmuJMF/YZgmCzUyFp yK/AWHG8jHa6VGtN0KUzlGEbi0C+ZRhsgkYz/a/YHrRy/lq7wR/pihqiMHFjNBvPJ7Pd 6PIPULAnoCciVDjmAo59CcuziXreCjJeaDtJiiZbqnSI9WQkgNxGGXw7N8+miT1KkUJU 2H3Q== X-Gm-Message-State: AOAM53257zekxsWxq1mLyJlwRL7osLDigWb/LCTTOt5SVEIa2OXUTJSh ElbN+0/iiUfNZphAkoYraO+vmNXVxzhBCGTDSnU= X-Google-Smtp-Source: ABdhPJz9E5xpEp+Qw3FZKOzl2VAN0VJ65Majk/qMw1Q1NJgQ+T/QVQcQfGVcDtCsiyHCfQ0pg3HPzdw6uZRavnTaIkE= X-Received: by 2002:a2e:b5d1:: with SMTP id g17mr6744211ljn.59.1589869746100; Mon, 18 May 2020 23:29:06 -0700 (PDT) MIME-Version: 1.0 References: <20200517132043.GE31833@E5400> <20200518063519.GB18220@E5400> In-Reply-To: <20200518063519.GB18220@E5400> From: Begley Brothers Inc Date: Tue, 19 May 2020 01:28:28 -0500 Message-ID: Subject: Re: Replacing Yocto with Guix kernel image builds: best practices To: Efraim Flashner Content-Type: multipart/alternative; boundary="00000000000074a0d105a5fa65dc" Received-SPF: pass client-ip=2a00:1450:4864:20::22f; envelope-from=begleybrothers@gmail.com; helo=mail-lj1-x22f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=saTBjpgv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: ilkZnEG/fc1G --00000000000074a0d105a5fa65dc Content-Type: text/plain; charset="UTF-8" On Mon, May 18, 2020 at 1:35 AM Efraim Flashner wrote: > On Mon, May 18, 2020 at 07:23:12AM +1000, Begley Brothers Inc wrote: > > On Sun, May 17, 2020 at 11:21 PM Efraim Flashner > > wrote: > > > > > On Sun, May 17, 2020 at 09:41:00PM +1000, Begley Brothers Inc wrote: > > > > Hi, > > > > We are now looking to build Linux kernels using Guix instead of > Yocto. > > > We > > > > can't see any reason why the builds wouldn't be linux-libre. Ideally > we'd > > > > like our effort to be accepted by upstream guix. > > > > > > > > However, being new to Guix we are still coming grips with the best > > > > practice(s) for what we would like to do. > > > > We've looked at Guix's linux.scm, and > > > > Efraim Flashner's post[1] is our primary reference - many thanks > Efraim. > > > > > > I'd like to embarrassingly mention that I never actually booted any of > > > my custom kernels. My machine was a bit too slow to regularly compile > > > for some guess-and-check. > > > > > > > No worries. Something is better than nothing and that was very useful > > outline of possible alternatives. > > > > > > > > > 1) We did wonder if channels[2] were the way to go with each kernel > x.y.z > > > > in its own branch and config files therein. Could anyone point us to > > > > packages that setup and use package specific channels? > > > > 2) Should we be aiming to provide a single package with multiple > > > parameters > > > > or is it better to provide a package for each kernel x.y.z, or some > other > > > > partitioning. We'd likely want to script the package definition then > - > > > > correct? > > > > > > I would probably start with one package each and then see how they > could > > > be made to inherit from one another or grouped together. The way the > > > current make-linux-libre procedures work has grown quite a bit but they > > > should still mostly work as a starting point to add/remove bits for > > > customizing for your needs. > > > > > > I don't think I'd go with different branches. If you keep everything in > > > one branch then it's easier to deduplicate work between the different > > > variants. > > > > > > > That was our thought too. > > We're just wondering how best to get that branch content down to the > users > > machine without them having to do anything. > > > > Thanks again. > > > > One option would be to include a channels file in the repo that's setup > so that you can add to the README "this is where our customizations > live. In order to build an image, run 'git pull; guix pull > --channels=our-channel-file.scm --profile > ~/.config/begley/current; ~/.config/begley/current/bin/guix > system build image.scm'". Then you can distribute the channels file you > Yes, that is somthing like what I had in mind, but would prefer to make it frictionless. Channels have the disadvantage of requiring the user do somthing that adds no value - by that I mean we've asked them to do somthing generic, and haven't saved or gotten any benefit. For example if in creating the channel they gave data that allowed us to automagically build x,y and z when they `guix pull`, and they don't have to remeber to rebuild after `guix pull` then there has been some value add. Right now I just don't see the value we could add - but we're still coming to grips with Guix. Immediately I can see that our objection is eliminated if we build a package that adds a channel in the background. Not sure if that is possible or in the spirit of Guix - we'd be altering one of their config files. How would we get their permission? etc. etc. Thanks for the feedback. -- Kind Regards Begley Brothers Inc. 1. *The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.* 2. *This message has been sent as a part of discussion between Begley Brothers Inc. and the addressee whose name is specified above. Should you receive this message by mistake, we would be most grateful if you informed us that the message has been sent to you. In this case, we also ask that you delete this message from your mailbox, and do not forward it or any part of it to anyone else. Thank you for your cooperation and understanding.* 3. *Begley Brothers Inc. puts the security of the client at a high priority. Therefore, we have put efforts into ensuring that the message is error and virus-free. Unfortunately, full security of the email cannot be ensured as, despite our efforts, the data included in emails could be infected, intercepted, or corrupted. Therefore, the recipient should check the email for threats with proper software, as the sender does not accept liability for any damage inflicted by viewing the content of this email.* 4. *The views and opinions included in this email belong to their author and do not necessarily mirror the views and opinions of the company. Our employees are obliged not to make any defamatory clauses, infringe, or authorize infringement of any legal right. Therefore, the company will not take any liability for such statements included in emails. In case of any damages or other liabilities arising, employees are fully responsible for the content of their emails.* --00000000000074a0d105a5fa65dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, May 18, 2020 at 1:35 AM Efraim Fl= ashner <efraim@flashner.co.il> wrote:
On Mon, May 18, 2020 at 07:23:12AM = +1000, Begley Brothers Inc wrote:
> On Sun, May 17, 2020 at 11:21 PM Efraim Flashner <efraim@flashner.co.il>
> wrote:
>
> > On Sun, May 17, 2020 at 09:41:00PM +1000, Begley Brothers Inc wro= te:
> > > Hi,
> > > We are now looking to build Linux kernels using Guix instead= of Yocto.
> > We
> > > can't see any reason why the builds wouldn't be linu= x-libre. Ideally we'd
> > > like our effort to be accepted by upstream guix.
> > >
> > > However, being new to Guix we are still coming grips with th= e best
> > > practice(s) for what we would like to do.
> > > We've looked at Guix's linux.scm, and
> > > Efraim Flashner's post[1] is our primary reference - man= y thanks Efraim.
> >
> > I'd like to embarrassingly mention that I never actually boot= ed any of
> > my custom kernels. My machine was a bit too slow to regularly com= pile
> > for some guess-and-check.
> >
>
> No worries. Something is better than nothing and that was very useful<= br> > outline of possible alternatives.
>
> <snip>
>
> > 1) We did wonder if channels[2] were the way to go with each kern= el x.y.z
> > > in its own branch and config files therein. Could anyone poi= nt us to
> > > packages that setup and use package specific channels?
> > > 2) Should we be aiming to provide a single package with mult= iple
> > parameters
> > > or is it better to provide a package for each kernel x.y.z, = or some other
> > > partitioning. We'd likely want to script the package def= inition then -
> > > correct?
> >
> > I would probably start with one package each and then see how the= y could
> > be made to inherit from one another or grouped together. The way = the
> > current make-linux-libre procedures work has grown quite a bit bu= t they
> > should still mostly work as a starting point to add/remove bits f= or
> > customizing for your needs.
> >
> > I don't think I'd go with different branches. If you keep= everything in
> > one branch then it's easier to deduplicate work between the d= ifferent
> > variants.
> >
>
> That was our thought too.
> We're just wondering how best to get that branch content down to t= he users
> machine without them having to do anything.
>
> Thanks again.
>

One option would be to include a channels file in the repo that's setup=
so that you can add to the README "this is where our customizations live. In order to build an image, run 'git pull; guix pull
--channels=3Dour-channel-file.scm --profile
~/.config/begley/current; ~/.config/begley/current/bin/guix
system build image.scm'". Then you can distribute the channels fil= e you

Yes, that is somthing like what I had in m= ind, but would prefer to make it frictionless.
Channels have the = disadvantage of requiring the user do somthing that adds no value - by=C2= =A0that I mean we've asked them to do somthing generic, and haven't= saved or gotten any benefit.=C2=A0 For example if in creating the channel = they gave data that allowed us to automagically build x,y and z when they `= guix pull`, and they don't have to remeber to rebuild after `guix pull`= then there has been some value add.
Right now I just don't s= ee the value we could add - but we're still coming to grips with Guix.<= /div>

Immediately I can see that our objection is elimin= ated if we build a package that adds a channel in the background.
Not sure if that is possible or in the spirit of Guix - we'd be alteri= ng one of their config files.=C2=A0 How would we get their permission? etc.= etc.
=C2=A0
Thanks for the feedback.

--=C2=A0
=
Kind Regards

Begley Brothers Inc.
  1. The content of this email is confidential and intend= ed for the=20 recipient specified in message only. It is strictly forbidden to share=20 any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
  2. This message has be= en sent as a part of discussion between Begley Brothers Inc. and the addres= see whose name is specified above. Should=20 you receive this message by mistake, we would be most grateful if you=20 informed us that the message has been sent to you. In this case, we also ask that you delete this message from your mailbox, and do not forward=20 it or any part of it to anyone else. Thank you for your cooperation and=20 understanding.
  3. Begley Brothers Inc. = puts the security of the client at a high priority.=20 Therefore, we have put efforts into ensuring that the message is error=20 and virus-free. Unfortunately, full security of the email cannot be=20 ensured as, despite our efforts, the data included in emails could be=20 infected, intercepted, or corrupted. Therefore, the recipient should=20 check the email for threats with proper software, as the sender does not accept liability for any damage inflicted by viewing the content of=20 this email.
  4. The views and opinions included in this email = belong to their author and do not necessarily mirror the views and opinions of the company.=20 Our employees are obliged not to make any defamatory clauses, infringe,=20 or authorize infringement of any legal right. Therefore, the company=20 will not take any liability for such statements included in emails. In=20 case of any damages or other liabilities arising, employees are fully=20 responsible for the content of their emails.
--00000000000074a0d105a5fa65dc--