Re: Replacing Yocto with Guix kernel image builds: best practices

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]

On Mon, May 18, 2020 at 07:23:12AM +1000, Begley Brothers Inc wrote:
> On Sun, May 17, 2020 at 11:21 PM Efraim Flashner <efraim@flashner.co.il>
> wrote:
> 
> > On Sun, May 17, 2020 at 09:41:00PM +1000, Begley Brothers Inc wrote:
> > > Hi,
> > > 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.
> > >
> > > However, being new to Guix we are still coming grips with the best
> > > practice(s) for what we would like to do.
> > > We've looked at Guix's linux.scm, and
> > > Efraim Flashner's post[1] is our primary reference - many thanks Efraim.
> >
> > I'd like to embarrassingly mention that I never actually booted any of
> > my custom kernels. My machine was a bit too slow to regularly compile
> > for some guess-and-check.
> >
> 
> No worries. Something is better than nothing and that was very useful
> outline of possible alternatives.
> 
> <snip>
> 
> > 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?
> > > 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?
> >
> > I would probably start with one package each and then see how they could
> > be made to inherit from one another or grouped together. The way the
> > current make-linux-libre procedures work has grown quite a bit but they
> > should still mostly work as a starting point to add/remove bits for
> > customizing for your needs.
> >
> > I don't think I'd go with different branches. If you keep everything in
> > one branch then it's easier to deduplicate work between the different
> > variants.
> >
> 
> That was our thought too.
> We're just wondering how best to get that branch content down to the users
> machine without them having to do anything.
> 
> Thanks again.
> 

One option would be to include a channels file in the repo that's setup
so that you can add to the README "this is where our customizations
live. In order to build an image, run 'git pull; guix pull
--channels=our-channel-file.scm --profile
~/.config/begley/current; ~/.config/begley/current/bin/guix
system build image.scm'". Then you can distribute the channels file you
need to crate the image together with the code. I would assume they'd be
willing to download the git repo with the code as part of building the
image.

> > Appreciate any comments suggestions or tips.
> > >
> > > [1]:
> > >
> > https://guix.gnu.org/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/
> > > [2]: https://guix.gnu.org/manual/en/guix.html#Channels
> > >
> > > --
> > > Kind Regards
> > >
> > > Begley Brothers Inc.
> > >
> > >

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]