From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id EKZjJ3qBw16JQQAA0tVLHw (envelope-from ) for ; Tue, 19 May 2020 06:49:30 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 2L1BI3qBw17oewAA1q6Kng (envelope-from ) for ; Tue, 19 May 2020 06:49:30 +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 3D9E3940363 for ; Tue, 19 May 2020 06:49:30 +0000 (UTC) Received: from localhost ([::1]:34712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaw49-0002BN-23 for larch@yhetil.org; Tue, 19 May 2020 02:49:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41370) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaw40-0002BD-1T for guix-devel@gnu.org; Tue, 19 May 2020 02:49:20 -0400 Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]:37918) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaw3y-00016x-FW for guix-devel@gnu.org; Tue, 19 May 2020 02:49:19 -0400 Received: by mail-lj1-x244.google.com with SMTP id m18so4083921ljo.5 for ; Mon, 18 May 2020 23:49:17 -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=v1C3EOGDKaf8sLY7opT6rPn4BXop+y2/tOsq8/HbE08=; b=LWtbeaWsKTb8/+JYthaO2W9H5M+hDunn2VqJo2OY+Opui6pRGgoJ2VOc4UuiChrKgC iv4+Gf9zI1rOwpc44HiIqQZQxuPi/svzUDGW6d1nxVQt7LMHW0FJzABy9/W6RtGFIk7C YRUkqYQf5dNtia3AFWIeiE53RQ/5mj+WAmXwSL0b3F+yyFy8Qz28vJ4efU0psnOltWvp 49ZIFIdTjMTVFcQ8izNC+/m46suqbzZM8U6LqjWW8fwMa90fECwV7G4oA/ft6HyiuStE FNgQDZWNVpoKTyepLjk7N/Nb8JZqu3HkrkMJO9Jjyoh5vX++wpt71PiLO06pXB6Haje0 xjbg== 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=v1C3EOGDKaf8sLY7opT6rPn4BXop+y2/tOsq8/HbE08=; b=r8CRl69cipm0N8AyfKXS7KXr5kEnCCJ62Y0KC8Fzk2E84dP44CuDyxk7uQaBQ0Yt2G AVInGE2CzVEu4qFEObcCdS6IRR3jp93eHGwlAOg38r0+gCQqolfqwi6uzFfu6sCW9vb9 cudARYYtCOe2BZtPw4W2FXn9G0286FFXmvZFRRHgej/drl7gydzhsXvOl+2rordSKOJ0 AWEuasCaDNzE4IWhIGqBR4qL8wjCCvOt+MO188gykUXq5/SH248jtYrB1xvIQeHmHIoo XDkfVsOrk9EWrpu3+eyFJ6p9fsS+Rm4Czn4h7MluqimbCe3ZZNNHh/l0VZKEn0fV6quu s2iA== X-Gm-Message-State: AOAM5311KouvKWthtIMCC4uIsuZkXp0qpoQIZhqhPkFqIS6spElJj6vi St9TWtEt8aDJu6dVp6Z62p2IWp2PRP386PjAKLk= X-Google-Smtp-Source: ABdhPJxY2im67hYHQrJbC5CvHIBpnl/rqCuGxeNk5EokfZCzbZypWour/sra7p8BaIImpG1cT5BjT8/c19uQ5ZtDe3s= X-Received: by 2002:a2e:5451:: with SMTP id y17mr12877859ljd.6.1589870956448; Mon, 18 May 2020 23:49:16 -0700 (PDT) MIME-Version: 1.0 References: <87lflqhgad.fsf@elephly.net> <20200518071657.GF18220@E5400> In-Reply-To: <20200518071657.GF18220@E5400> From: Begley Brothers Inc Date: Tue, 19 May 2020 01:48:39 -0500 Message-ID: Subject: Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices To: Efraim Flashner Content-Type: multipart/alternative; boundary="000000000000990ceb05a5faadeb" Received-SPF: pass client-ip=2a00:1450:4864:20::244; envelope-from=begleybrothers@gmail.com; helo=mail-lj1-x244.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=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=LWtbeaWs; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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.09 X-TUID: jgBf+DKJo0/G --000000000000990ceb05a5faadeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 18, 2020 at 2:17 AM Efraim Flashner wrote: > On Mon, May 18, 2020 at 07:40:53AM +1000, Begley Brothers Inc wrote: > > On Sun, May 17, 2020 at 10:55 PM Ricardo Wurmus > wrote: > > > > > > > > Hi, > > > > > > [+guix-devel, -gnu-linux-libre] > > > > > > > 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. Ideall= y > we'd > > > > like our effort to be accepted by upstream guix. > > > [=E2=80=A6] > > > > We'd appreciate any pointers to package definition(s) that > demonstrate > > > best > > > > practices to do what we'd like: > > > > > > > > - We'd like to build custom configured kernels for each patch serie= s > in > > > the > > > > LTS 4.14.72+, 4.19+ and 5.4+. > > > > - Currently we have two `base` kernel configs that each 'variant' > > > > configuration is applied to for each of a machine 'type' (3 machine > > > types) > > > > and one of two 'arch'. > > > > - Currently we can generate a full kernel `.config` for a > > > > kernel+base+variant+arch (we are working on the best way to handle > > > > different machines if we are not using Yocto.) > > > > - We'd ideally like to generate `vmlinux`, `initrd` and `rootfs` > images > > > for > > > > each. > > > > > > > > Based on Efraim's post we think the first example is the least > friction - > > > > "including an actual .config file as a native input to our custom > > > kernel". > > > > Assume we resolve the machine definition issue. However we're > puzzled > > > > about how to best distribute the configuration file such that a > build of > > > > kernel x.y.z can be updated with fixes. > > > > > > You can either put your config files in a separate git repository and > add > > > that to > > > the native inputs, or you can include the config files in your channe= l > > > repository (or later in Guix itself). > > > > > > > Thanks for the suggestion. That gives some assurance. > > Could you point to an existing guix (upstream) package that is a best > > practice > > example of each of those two approaches? > > - accessing files from a separate repo > > - a guix (upstream) package using other files > > > > Do you mean something like this? It's a container instead of a full disk > image but it seems close enough. The 'gn' namespace is local to that > repo and 'gnu' and 'guix' are from the upstream guix repo. > > http://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics/src/br= anch/master/gn/services/bnw-container.scm Thanks for sharing that definition - very interesting. It seems gexp are something to be mastered. We're trying to disentangle ourselves from containers. Guix gets us a big step in that direction, and that definitions shows some of its power. Much appreciated. --=20 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 a= ny 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 mista= ke 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 yo= u receive this message by mistake, we would be most grateful if you inform= ed 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 b= e ensured as, despite our efforts, the data included in emails could be infected, intercepted, or corrupted. Therefore, the recipient should che= ck the email for threats with proper software, as the sender does not accep= t 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 n= ot take any liability for such statements included in emails. In case of an= y damages or other liabilities arising, employees are fully responsible fo= r the content of their emails.* --000000000000990ceb05a5faadeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 18, 2020 at 2:17 AM Efrai= m Flashner <efraim@flashner.co.= il> wrote:
On Mon, May 18, 2020 at 07:40:5= 3AM +1000, Begley Brothers Inc wrote:
> On Sun, May 17, 2020 at 10:55 PM Ricardo Wurmus <rekado@elephly.net> wrote:
>
> >
> > Hi,
> >
> > [+guix-devel, -gnu-linux-libre]
> >
> > > 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.
> > [=E2=80=A6]
> > > We'd appreciate any pointers to package definition(s) th= at demonstrate
> > best
> > > practices to do what we'd like:
> > >
> > > - We'd like to build custom configured kernels for each = patch series in
> > the
> > > LTS 4.14.72+, 4.19+ and 5.4+.
> > > - Currently we have two `base` kernel configs that each '= ;variant'
> > > configuration is applied to for each of a machine 'type&= #39; (3 machine
> > types)
> > > and one of two 'arch'.
> > > - Currently we can generate a full kernel `.config` for a > > > kernel+base+variant+arch (we are working on the best way to = handle
> > > different machines if we are not using Yocto.)
> > > - We'd ideally like to generate `vmlinux`, `initrd` and = `rootfs` images
> > for
> > > each.
> > >
> > > Based on Efraim's post we think the first example is the= least friction -
> > > "including an actual .config file as a native input to = our custom
> > kernel".
> > > Assume we resolve the machine definition issue.=C2=A0 Howeve= r we're puzzled
> > > about how to best distribute the configuration file such tha= t a build of
> > > kernel x.y.z can be updated with fixes.
> >
> > You can either put your config files in a separate git repository= and add
> > that to
> > the native inputs, or you can include the config files in your ch= annel
> > repository (or later in Guix itself).
> >
>
> Thanks for the suggestion.=C2=A0 That gives some assurance.
> Could you point to an existing guix (upstream) package that is a best<= br> > practice
> example of each of those two approaches?
> - accessing files from a separate repo
> - a guix (upstream) package using other files
>

Do you mean something like this? It's a container instead of a full dis= k
image but it seems close enough. The 'gn' namespace is local to tha= t
repo and 'gnu' and 'guix' are from the upstream guix repo.<= br> http://git.genenetwork.org/guix-bioinformatics/guix-bioinform= atics/src/branch/master/gn/services/bnw-container.scm
=
Thanks for sharing that definition - very interesting.=C2=A0= It seems gexp are something to be mastered.
We're trying to = disentangle ourselves from containers. Guix gets us a big step in that dire= ction, and that definitions shows some of its power.
Much appreci= ated.

--
Kind Regards

Begley Brothers Inc.=

  1. The content of this email is confidential and= intended 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.
--000000000000990ceb05a5faadeb--