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 KEIlNKo2wl5pPAAA0tVLHw (envelope-from ) for ; Mon, 18 May 2020 07:18:02 +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 EFfSL6o2wl4ZOAAAbx9fmQ (envelope-from ) for ; Mon, 18 May 2020 07:18:02 +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 870A094042B for ; Mon, 18 May 2020 07:18:01 +0000 (UTC) Received: from localhost ([::1]:38714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaa2C-0007cC-BY for larch@yhetil.org; Mon, 18 May 2020 03:18:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaa1q-0007bW-7H for guix-devel@gnu.org; Mon, 18 May 2020 03:17:38 -0400 Received: from flashner.co.il ([178.62.234.194]:33522) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaa1o-0003IE-Ai for guix-devel@gnu.org; Mon, 18 May 2020 03:17:37 -0400 Received: from localhost (unknown [188.120.128.132]) by flashner.co.il (Postfix) with ESMTPSA id BD690400D2; Mon, 18 May 2020 07:17:33 +0000 (UTC) Date: Mon, 18 May 2020 10:16:57 +0300 From: Efraim Flashner To: Begley Brothers Inc Subject: Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices Message-ID: <20200518071657.GF18220@E5400> References: <87lflqhgad.fsf@elephly.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oPmsXEqKQNHCSXW7" Content-Disposition: inline In-Reply-To: X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Received-SPF: pass client-ip=178.62.234.194; envelope-from=efraim@flashner.co.il; helo=flashner.co.il X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/18 02:35:55 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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=none; dmarc=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: 0.69 X-TUID: Or8UCFyVu8m2 --oPmsXEqKQNHCSXW7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wrot= e: >=20 > > > > 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` imag= es > > for > > > each. > > > > > > Based on Efraim's post we think the first example is the least fricti= on - > > > "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 a= dd > > that to > > the native inputs, or you can include the config files in your channel > > repository (or later in Guix itself). > > >=20 > 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 >=20 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/bran= ch/master/gn/services/bnw-container.scm > > 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= =2Ey.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. > > >=20 > 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? >=20 > 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. > > >=20 > 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: >=20 > 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 >=20 > > 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 o= ther > > > 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 sugge= st > > defining a procedure that returns a package value. You can then define > > multiple packages in terms of that procedure. > > >=20 > Thanks for that suggestion. It seems the issue to resolve is the best > approach for getting those config files to the users machine. >=20 > Thanks again >=20 >=20 > > -- > > Ricardo > > >=20 >=20 > --=20 > Kind Regards >=20 > Begley Brothers Inc. >=20 >=20 > 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 o= f 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 mis= take > 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 info= rmed > us that the message has been sent to you. In this case, we also ask th= at > 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 messag= e 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 c= heck > the email for threats with proper software, as the sender does not acc= ept > liability for any damage inflicted by viewing the content of this emai= l.* > 4. *The views and opinions included in this email belong to their auth= or > and do not necessarily mirror the views and opinions of the company. O= ur > 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.* --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --oPmsXEqKQNHCSXW7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl7CNmYACgkQQarn3Mo9 g1HzpA/+J/p+R7iowJQ9lLhwVIu5t7EYSo7A3SYjIfcAJmGC3eeq3iUk2ct2sHId KGGwC3O/4sS7xa/kp2gm9C/MCL6Z8+0N3E/M9UkMvBQf7yrYy8/0kwEbbDpb+tQD LIYICNhwzJVr7wTuUHcZQ8sz9mI5jHFn+YgugbzTYW3HDCLrnVW8XQujtf6e724+ LVkE8FDW1EbAgE+cVT2QR3pmFXqCW3ZLxdFuYwmgZHSi3eAws51bRsMhaVsexewE aADkUhFHHdgYs9OGycdXdYYvvST6i2uAMlCrWqyXBwXluqxhn0BL6N29waqlte61 L2an/t1lXnmh3FHX/QuhqGhhaI56mLr9oRr7MmDOQ/MtM8/cTdjkzuRukh+Uvfgl KBnZ5CzfD8+hDaoXkHNJzceL4/7FcHd3/rpTiCTfKv8J0RZQkd9Nn+I/zqqlMd7C x8agW2FaSQeUgInE9DtSgIn85+ngCLMDbJqet1FioAwXnOjE/fm7pPOqNmkvLoVI B/KQ5WiDn85jUwedL2UH+4Lq6N3M61PWgZWap4NV9xO6sk72OJtPbGduhmJ6nexA K/u8mViuUhYnYpqw8bus7NL+UYZUW0WgS0iUF5pHrbVl93Aw43lPF4ildw+dEWjn pzf+6L70mwpBoUfwmV51dkcniv32avdOAuQbKwwslcYdouM4PaI= =IZoL -----END PGP SIGNATURE----- --oPmsXEqKQNHCSXW7--