From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2OuHHT+ywV5kegAA0tVLHw (envelope-from ) for ; Sun, 17 May 2020 21:53:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id SBwlGT+ywV69PAAAbx9fmQ (envelope-from ) for ; Sun, 17 May 2020 21:53:03 +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 A1D4C940368 for ; Sun, 17 May 2020 21:53:02 +0000 (UTC) Received: from localhost ([::1]:40384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaRDR-0007uZ-EL for larch@yhetil.org; Sun, 17 May 2020 17:53:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaR2b-0004Uk-87 for guix-devel@gnu.org; Sun, 17 May 2020 17:41:56 -0400 Received: from mail-lj1-x242.google.com ([2a00:1450:4864:20::242]:46933) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaR2P-0001XQ-0H for guix-devel@gnu.org; Sun, 17 May 2020 17:41:48 -0400 Received: by mail-lj1-x242.google.com with SMTP id f18so7746190lja.13 for ; Sun, 17 May 2020 14:41:31 -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=2e5kJbBj52vDnAoNlufb40Ul1NWkyZ83MhnyDWRn63M=; b=D0JMPcNYDsjuSHIlks9CxVKZt9J+YkGvJt79YHX/WDdYF6n6I1PpYeoxEuJqnfeZsa ftOX6TnUr3w+MrLN/mUKIQRlIqeUlBJF7k8Ltp+CrDPqLi7xY05PBWK9VNOiMOtZxxOT KaOWQsKJETqKVBMTkCoBc87ax4FFW/L3FxBpFSL1X3cR6bBOVTLW5k3a7R7I66lFM/Sp l2ZVctDixRy59wGHCFw1+jxd7BevGxOXCuBUIw8X4ThI8sOwp4x0V7VpU1nisZyF1ooj qq0gFOcsB+h4JPnIBqaY+TG9FmbA+JaltlUC+rApbZAr9L2YgO5Zb9s11jsupA61U6bG j2Gw== 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=2e5kJbBj52vDnAoNlufb40Ul1NWkyZ83MhnyDWRn63M=; b=BJrL+zTDioCwLBeVKYgPwjEbZ9WjGFpE85GUnftpi5e+kDUv+O97r6glw/Gyyqshwq l3KlJRjbRX1lzBOaw3IhoUQwQTocmXxeBgligaelrzOw04/bp9RznDgKoek9cN1QVzLW d48GdDUK72XctpGWGs9ny13iMwtiO5HNpb2eSm+ruExPAPiI/HF0fhitnnxejLQeeolL ILY8+ptuiCkJHitg6/DkEPVyVoXHb5BF85ZS7rj7sfKKp7w3McoAWF48pnwn8K3LiCQU Hroh45qCATmkhD9R5Ty9O7vailVY9+nRvhME17V0oT+RSicNajw4Xu1oqthAIo6RHpKx StJw== X-Gm-Message-State: AOAM530qWmou3DvVGU7nPIRYCQ0kzysSsIYR81gNx5gK10B7rE+6tZ+F j+KNojOsuViNOSP26kvU27m3tdZeNq7AV+zOh/Tn2WzeMSs= X-Google-Smtp-Source: ABdhPJzPFWNbWMwE/MbrJp9sp/+S3q8JvopEofBikDFWUMS4zAfeJzcXDoVIgaNyn1fCWi/UtyLnXNs8yUhl2EyA98c= X-Received: by 2002:a2e:8246:: with SMTP id j6mr683904ljh.54.1589751690438; Sun, 17 May 2020 14:41:30 -0700 (PDT) MIME-Version: 1.0 References: <87lflqhgad.fsf@elephly.net> In-Reply-To: <87lflqhgad.fsf@elephly.net> From: Begley Brothers Inc Date: Mon, 18 May 2020 07:40:53 +1000 Message-ID: Subject: Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices To: Ricardo Wurmus Content-Type: multipart/alternative; boundary="000000000000ca2be105a5dee819" Received-SPF: pass client-ip=2a00:1450:4864:20::242; envelope-from=begleybrothers@gmail.com; helo=mail-lj1-x242.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=D0JMPcNY; 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: W/KCAshA9uqk --000000000000ca2be105a5dee819 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Ideally 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 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' (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 o= f > > 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 channel > 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 > The constraint of users being able to use the std guix commands rather > than > > telling them to download a config file or clone a git repo and copy a > > config file is what is puzzling. Some options we thought about seem > > inelegant - hence too embarassing to mention - so we'll skip them ;) > > Leaving.... > > > > 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? > > Channels handle all the gnarly bits of interacting with git. Users who > would like to add your channel providing alternative kernels would only > need to add it to their ~/.config/guix/channels.scm file. > Can "add it to their ~/.config/guix/channels.scm file" be scripted as part of the package? Is there an example of a guix (upstream) package that does this? But since your stated goal is to add these definitions to Guix itself > you can simply add the kernel variants to linux.scm and include the > config files in the repository. > Current guix/linux.scm seems to take a different approach and cater to a different use cases - but our understanding of the code is limited and no doubt flawed. We think a three step process: 1. Get a package definition working and publicly available. 2. Make any changes to get it accepted as a separate package by guix. 3. Consider whether merging with guix/linux.scm is what linux-libre folks want > 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 oth= er > > partitioning. We'd likely want to script the package definition then - > > correct? > > If the main differences between kernel variants are not in the package > definition but the sources and the configuration file I=E2=80=99d suggest > defining a procedure that returns a package value. You can then define > multiple packages in terms of that procedure. > Thanks for that suggestion. It seems the issue to resolve is the best approach for getting those config files to the users machine. Thanks again > -- > Ricardo > --=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.* --000000000000ca2be105a5dee819 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.= =C2=A0 We
> can't see any reason why the builds wouldn't be linux-libre. I= deally we'd
> like our effort to be accepted by upstream guix.
[=E2=80=A6]
> We'd appreciate any pointers to package definition(s) that demonst= rate best
> practices to do what we'd like:
>
> - We'd like to build custom configured kernels for each patch seri= es in the
> LTS 4.14.72+, 4.19+ and 5.4+.
> - Currently we have two `base` kernel configs that each 'variant&#= 39;
> configuration is applied to for each of a machine 'type' (3 ma= chine 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` i= mages for
> each.
>
> Based on Efraim's post we think the first example is the least fri= ction -
> "including an actual .config file as a native input to our custom= kernel".
> Assume we resolve the machine definition issue.=C2=A0 However we'r= e 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 t= hat to
the native inputs, or you can include the config files in your channel
repository (or later in Guix itself).

T= hanks for the suggestion.=C2=A0 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 file= s from a separate repo
- a guix (upstream) package using other fi= les

> The constraint of users being able to use the std guix commands rather= than
> telling them to download a config file or clone a git repo and copy a<= br> > config file is what is puzzling. Some options we thought about seem > inelegant - hence too embarassing to mention - so we'll skip them = ;)
> Leaving....
>
> 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?

Channels handle all the gnarly bits of interacting with git.=C2=A0 Users wh= o
would like to add your channel providing alternative kernels would only
need to add it to their ~/.config/guix/channels.scm file.
<= div>
Can "add it to their ~/.config/guix/channels.scm fi= le" be scripted as part of the
package?
Is there a= n example of a guix (upstream) package that does this?

<= /div>
But since your stated goal is to add these definitions to Guix itself
you can simply add the kernel variants to linux.scm and include the
config files in the repository.
=C2=A0
Curre= nt guix/linux.scm seems to take a different approach and cater to a
different use cases - but our understanding of the code is limited and = no
doubt flawed.
We think a three step process:
=

1. Get a package definition working and publicly = available.
2. Make any changes to get it accepted as a separate p= ackage by guix.
3. Consider whether merging with guix/linux.s= cm is what linux-libre folks
=C2=A0=C2=A0=C2=A0 want

> 2) Should we be aiming to provide a single package with multiple param= eters
> or is it better to provide a package for each kernel x.y.z, or some ot= her
> partitioning. We'd likely want to script the package definition th= en -
> correct?

If the main differences between kernel variants are not in the package
definition but the sources and the configuration file I=E2=80=99d suggest defining a procedure that returns a package value.=C2=A0 You can then defin= e
multiple packages in terms of that procedure.

Thanks for that suggestion.=C2=A0 It seems the issue to resolve is t= he best
approach for getting those config files to the users mac= hine.

Thanks again


--
Ricardo


--
Kind Regards

Begley Brot= hers Inc.

  1. The content of this email is confiden= tial 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 been= sent as a part of discussion between Begley Brothers Inc. and the addresse= e 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 be= long 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.
--000000000000ca2be105a5dee819--