Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Ricardo Wurmus]

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

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

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.

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

-- 
Ricardo

Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Begley Brothers Inc]

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

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

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

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

Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Efraim Flashner]

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

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

> > 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   <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: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Begley Brothers Inc]

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

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

> 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


Thanks for sharing that definition - very interesting.  It seems gexp are
something to be mastered.
We're trying to disentangle ourselves from containers. Guix gets us a big
step in that direction, and that definitions shows some of its power.
Much appreciated.

-- 
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: 6129 bytes --]

Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Ricardo Wurmus]

Begley Brothers Inc <begleybrothers@gmail.com> writes:

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

There are many examples in the Guix repository.  One example is
java-cisd-args4j in gnu/packages/java.scm, which has “build-resources”
as a native-input, which is an SVN origin.

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

No, channel configuration is a user action.  The channel would be the
thing that provides your package in the first place.

But since you want to add your package variants to Guix itself a
discussion of channels isn’t really interesting.

-- 
Ricardo

Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Begley Brothers Inc]

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

On Mon, May 18, 2020 at 5:24 AM Ricardo Wurmus <rekado@elephly.net> wrote:

>
> Begley Brothers Inc <begleybrothers@gmail.com> writes:
>
> > > 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
>
> There are many examples in the Guix repository.  One example is
> java-cisd-args4j in gnu/packages/java.scm, which has “build-resources”
> as a native-input, which is an SVN origin.
>

Thanks Ricardo, That was great - I expected external linkages like that to
be
rejected for inclusion in upstream, so it is nice to see - I think that
approach
gives us a fallback in case our preferred approach does not work out.


> > 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?
>
> No, channel configuration is a user action.  The channel would be the
> thing that provides your package in the first place.
>
> But since you want to add your package variants to Guix itself a
> discussion of channels isn’t really interesting.
>

Agreed.

Thanks again.

-- 
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: 4438 bytes --]

Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Begley Brothers Inc]

Hi,
Thanks for all the thoughtful input.
We think we have worked out a preferred path - ironically from a
closer reading of the linux.scm - once we had some familiarity with
Guile.

We think (with doubts we'll elaborate on):
1. All config files and any such files should go in a folder
`gnu/packages/aux-files/<packagename>`.
2. All patches should go in `gnu/packages/patches` where they all seem
to live at the toplevel.

The doubts are:
Is this is the 'correct' way going forward - it appears only three
packages adopt this location.
Are we able to store patches in `gnu/packages/patches/<packagename>` -
it appears other packages just drop everythin in `patches`

Appreciate any thoughts.

On Tue, May 19, 2020 at 2:09 AM Begley Brothers Inc
<begleybrothers@gmail.com> wrote:
>
> On Mon, May 18, 2020 at 5:24 AM Ricardo Wurmus <rekado@elephly.net> wrote:
>>
>>
>> Begley Brothers Inc <begleybrothers@gmail.com> writes:
>>
>> > > 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
>>
>> There are many examples in the Guix repository.  One example is
>> java-cisd-args4j in gnu/packages/java.scm, which has “build-resources”
>> as a native-input, which is an SVN origin.
>
>
> Thanks Ricardo, That was great - I expected external linkages like that to be
> rejected for inclusion in upstream, so it is nice to see - I think that approach
> gives us a fallback in case our preferred approach does not work out.
>
>>
>> > 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?
>>
>> No, channel configuration is a user action.  The channel would be the
>> thing that provides your package in the first place.
>>
>> But since you want to add your package variants to Guix itself a
>> discussion of channels isn’t really interesting.
>
>
> Agreed.
>
> Thanks again.
>
> --
> Kind Regards
>
> Begley Brothers Inc.
>
> 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.
> 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.
> 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.
> 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.



-- 
Kind Regards

Begley Brothers Inc.

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