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. Ideally we'd > > > like our effort to be accepted by upstream guix. > > […] > > > 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 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 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 > 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/branch/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.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 other > > > 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’d 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 > > > > > -- > 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.* -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted