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 <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 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