Replacing Yocto with Guix kernel image builds: best practices

Replacing Yocto with Guix kernel image builds: best practices

[Trevor Lee]

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

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.

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

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.


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

[-- Attachment #2: Type: text/html, Size: 5107 bytes --]

Re: [offtopic] Funny footer (was: Replacing Yocto with Guix kernel image builds: best practices)

[Dmitry Alexandrov]

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

My apologies to Guix devs for offtopic (I hope adding an appropriate tag to subject is enough not to disturb those who do not want to be disturbed), but I could not pass this by:

Trevor Lee <begleybrothers@gmail.com> wrote:
>    1. *The content of this email is confidential and intended for the recipient specified in message only.

Nope, youʼve sent it to a public mailing list. ;-)

And even if put this mistake aside:

>    It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender.

By whom?  Is there anyone, who is capable of ‘strictly forbidding’ me (or anyone else) to do anything?  I would suggest you to revise the wording.

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

While this is undoubtedly formulated better, it contradicts with the normal workflow of most people: they could either reply to the letter (often citing the enough context) and store it in their archive forever along with their reply, or trash it.

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

Are not you repeating yourself?

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

Sure, perfect secrecy / security cannot be achieved.  But, for instance, signing and encrypting your mail sufficiently lower the chances that it would be tampered with and read by adversary third party respectively.

Unfortunately, you neither sign your mail, nor I can find your key to send you an encrypted one: it is not published neither at open keyserver network (for now represented by keyserver.ubuntu.com), neither at proprietary keys.openpgp.org.  And gmail.com, of course, does not provide webkey-directory, let aside DANE.

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

It seems, that you have really decided to scare all your clients off. :-)

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

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

[Efraim Flashner]

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

On Sun, May 17, 2020 at 09:41:00PM +1000, Trevor Lee 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.

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

Something which I very recently learned is a command 'make savedefconfig'
which minimizes the .config to just a minimal number of Y/N/m answers
which, when used to compile a kernel, gives the same outcome as the full
config that spawned it. I've thought again about making a minimal kernel
for my machine and I haven't decided still if I'd go with savedefconfig
and translate it to a generated file or not.

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

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

Re: [offtopic] Funny footer (was: Replacing Yocto with Guix kernel image builds: best practices)

[Josh Marshall]

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

Yeah, I noticed this, too but wasn't going to say anything.  That footer is
outlandish.  I think you ought to nix the whole thing.

On Sun, May 17, 2020, 09:29 Dmitry Alexandrov <dag@gnui.org> wrote:

> My apologies to Guix devs for offtopic (I hope adding an appropriate tag
> to subject is enough not to disturb those who do not want to be disturbed),
> but I could not pass this by:
>
> Trevor Lee <begleybrothers@gmail.com> wrote:
> >    1. *The content of this email is confidential and intended for the
> recipient specified in message only.
>
> Nope, youʼve sent it to a public mailing list. ;-)
>
> And even if put this mistake aside:
>
> >    It is strictly forbidden to share any part of this message with any
> third party, without a written consent of the sender.
>
> By whom?  Is there anyone, who is capable of ‘strictly forbidding’ me (or
> anyone else) to do anything?  I would suggest you to revise the wording.
>
> >    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.*
>
> While this is undoubtedly formulated better, it contradicts with the
> normal workflow of most people: they could either reply to the letter
> (often citing the enough context) and store it in their archive forever
> along with their reply, or trash it.
>
> >    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.*
>
> Are not you repeating yourself?
>
> >    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.
>
> Sure, perfect secrecy / security cannot be achieved.  But, for instance,
> signing and encrypting your mail sufficiently lower the chances that it
> would be tampered with and read by adversary third party respectively.
>
> Unfortunately, you neither sign your mail, nor I can find your key to send
> you an encrypted one: it is not published neither at open keyserver network
> (for now represented by keyserver.ubuntu.com), neither at proprietary
> keys.openpgp.org.  And gmail.com, of course, does not provide
> webkey-directory, let aside DANE.
>
> >    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.*
>
> It seems, that you have really decided to scare all your clients off. :-)
>

[-- Attachment #2: Type: text/html, Size: 3712 bytes --]

Re: [offtopic] Funny footer (was: Replacing Yocto with Guix kernel image builds: best practices)

[Trevor Lee]

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

No doubt there is lots about my life and the things I do that you think I
should change ;)
No offense taken.
Moving on.

On Mon, May 18, 2020 at 2:59 AM Josh Marshall <
joshua.r.marshall.1991@gmail.com> wrote:

> Yeah, I noticed this, too but wasn't going to say anything.  That footer
> is outlandish.  I think you ought to nix the whole thing.
>
> On Sun, May 17, 2020, 09:29 Dmitry Alexandrov <dag@gnui.org> wrote:
>
>> My apologies to Guix devs for offtopic (I hope adding an appropriate tag
>> to subject is enough not to disturb those who do not want to be disturbed),
>> but I could not pass this by:
>>
>> Trevor Lee <begleybrothers@gmail.com> wrote:
>> >    1. *The content of this email is confidential and intended for the
>> recipient specified in message only.
>>
>> Nope, youʼve sent it to a public mailing list. ;-)
>>
>> And even if put this mistake aside:
>>
>> >    It is strictly forbidden to share any part of this message with any
>> third party, without a written consent of the sender.
>>
>> By whom?  Is there anyone, who is capable of ‘strictly forbidding’ me (or
>> anyone else) to do anything?  I would suggest you to revise the wording.
>>
>> >    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.*
>>
>> While this is undoubtedly formulated better, it contradicts with the
>> normal workflow of most people: they could either reply to the letter
>> (often citing the enough context) and store it in their archive forever
>> along with their reply, or trash it.
>>
>> >    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.*
>>
>> Are not you repeating yourself?
>>
>> >    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.
>>
>> Sure, perfect secrecy / security cannot be achieved.  But, for instance,
>> signing and encrypting your mail sufficiently lower the chances that it
>> would be tampered with and read by adversary third party respectively.
>>
>> Unfortunately, you neither sign your mail, nor I can find your key to
>> send you an encrypted one: it is not published neither at open keyserver
>> network (for now represented by keyserver.ubuntu.com), neither at
>> proprietary keys.openpgp.org.  And gmail.com, of course, does not
>> provide webkey-directory, let aside DANE.
>>
>> >    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.*
>>
>> It seems, that you have really decided to scare all your clients off. :-)
>>
>

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

[-- Attachment #2: Type: text/html, Size: 6432 bytes --]

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

[Begley Brothers Inc]

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

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.

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


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

[-- Attachment #2: Type: text/html, Size: 8225 bytes --]

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

[Efraim Flashner]

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

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

[Begley Brothers Inc]

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

On Mon, May 18, 2020 at 1:35 AM Efraim Flashner <efraim@flashner.co.il>
wrote:

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

Yes, that is somthing like what I had in mind, but would prefer to make it
frictionless.
Channels have the disadvantage of requiring the user do somthing that adds
no value - by that I mean we've asked them to do somthing generic, and
haven't saved or gotten any benefit.  For example if in creating the
channel they gave data that allowed us to automagically build x,y and z
when they `guix pull`, and they don't have to remeber to rebuild after
`guix pull` then there has been some value add.
Right now I just don't see the value we could add - but we're still coming
to grips with Guix.

Immediately I can see that our objection is eliminated if we build a
package that adds a channel in the background.
Not sure if that is possible or in the spirit of Guix - we'd be altering
one of their config files.  How would we get their permission? etc. etc.

Thanks for the feedback.

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

[-- Attachment #2: Type: text/html, Size: 6842 bytes --]