Image specific configuration files

Image specific configuration files

[Damien LEFEVRE]

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

Hi,

For the same MACHINE I create the following images:
- myimage-production
- myimage-rnd
- myimage-retail

The production one has production assisted tools for flashing peripheral
HW, testing vital HW components, writing some serial numbers, etc.

The rnd one has more packages than the retail one just to help rnd work and
debugging in device, but none of the rnd image extra packages.

The retail one has the final product image.

I'm using web and FTP servers. I would like for the rnd version of the
image to have a different nginx configuration to set the root directory to
a development folder, or set an alias.

Furthermore, I'll have different variant of the device where only the
device SW changes but the platform is identical. So I'll end up with
- myimage2-production
- myimage2-rnd
- myimage2-retail

I know how to make MACHINE based configuration. How could I do this in
my nginx.bbappend based on image name?

Thanks,
-Damien

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

Re: Image specific configuration files

[Iván Castell]

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

I fixed this issue defining different distro.conf files in my custom layer,
adding a custom variable DISTRO_STAGE with the name of my distro
(production, rnd, retail, and so on), Then you setup DISTRO in your
local.conf to the proper value you want to use. Finally you can use that
DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
proper configuration files you want to install in your final image. That
works as expected. Hope this helps!




2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:

> Hi,
>
> For the same MACHINE I create the following images:
> - myimage-production
> - myimage-rnd
> - myimage-retail
>
> The production one has production assisted tools for flashing peripheral
> HW, testing vital HW components, writing some serial numbers, etc.
>
> The rnd one has more packages than the retail one just to help rnd work
> and debugging in device, but none of the rnd image extra packages.
>
> The retail one has the final product image.
>
> I'm using web and FTP servers. I would like for the rnd version of the
> image to have a different nginx configuration to set the root directory to
> a development folder, or set an alias.
>
> Furthermore, I'll have different variant of the device where only the
> device SW changes but the platform is identical. So I'll end up with
> - myimage2-production
> - myimage2-rnd
> - myimage2-retail
>
> I know how to make MACHINE based configuration. How could I do this in
> my nginx.bbappend based on image name?
>
> Thanks,
> -Damien
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: info@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
has adopted the necessary measures to ensure the confidential treatment of
personal information. We also inform you that you can exercise your access,
rectification, cancellation and opposition rights by send us a mail to:
info@nayarsystems.com

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

Re: Image specific configuration files

[Alan Martinovic]

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

Hey,
would really like to see your example.
Am struggling to get creation of these types of images for a while now.

So far have avoided diving into multiple distros because would like to have
the option
of building all the images at the same time (so they are basically the same
distro).

On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com>
wrote:

> I fixed this issue defining different distro.conf files in my custom
> layer, adding a custom variable DISTRO_STAGE with the name of my distro
> (production, rnd, retail, and so on), Then you setup DISTRO in your
> local.conf to the proper value you want to use. Finally you can use that
> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
> proper configuration files you want to install in your final image. That
> works as expected. Hope this helps!
>
>
>
>
> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>
>> Hi,
>>
>> For the same MACHINE I create the following images:
>> - myimage-production
>> - myimage-rnd
>> - myimage-retail
>>
>> The production one has production assisted tools for flashing peripheral
>> HW, testing vital HW components, writing some serial numbers, etc.
>>
>> The rnd one has more packages than the retail one just to help rnd work
>> and debugging in device, but none of the rnd image extra packages.
>>
>> The retail one has the final product image.
>>
>> I'm using web and FTP servers. I would like for the rnd version of the
>> image to have a different nginx configuration to set the root directory to
>> a development folder, or set an alias.
>>
>> Furthermore, I'll have different variant of the device where only the
>> device SW changes but the platform is identical. So I'll end up with
>> - myimage2-production
>> - myimage2-rnd
>> - myimage2-retail
>>
>> I know how to make MACHINE based configuration. How could I do this in
>> my nginx.bbappend based on image name?
>>
>> Thanks,
>> -Damien
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
>
> --
>
>
>
>
> *NOTA LEGAL*
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
> o impresión total o parcial. Si ha recibido este correo electrónico por
> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
> original juntamente con sus ficheros anexos. Gracias.
>
> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
> la adopción de las medidas necesarias para asegurar el tratamiento
> confidencial de los datos de carácter personal. Así mismo le informamos de
> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
> derechos de acceso, rectificación, cancelación y oposición mediante un
> escrito a la siguiente dirección: info@nayarsystems.com
>
> *LEGAL NOTE*
> This email and any attachments to it contains is confidential information
> exclusively intended for the recipients. Any divulgation, copy or
> distribution to third parties is prohibited without written permission of
> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
> the sender immediately. In accordance with Law 15/1999 of 13 December on
> the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
> has adopted the necessary measures to ensure the confidential treatment of
> personal information. We also inform you that you can exercise your access,
> rectification, cancellation and opposition rights by send us a mail to:
> info@nayarsystems.com
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

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

Re: Image specific configuration files

[Iván Castell]

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

I can provide more details. My custom layer has these files related with
distro:

    my_layer/conf/distro/include/common.conf
    my_layer/conf/distro/develop.conf
    my_layer/conf/distro/production.conf
    my_layer/conf/distro/integration.conf

As an example of the previous files,
my_layer/conf/distro/include/develop.conf has this content:

    require conf/distro/include/common.conf
    DISTRO = "my-distro-development"
    DISTRO_NAME = "OS Development"
    DISTRO_STAGE = "development"
    # And here more customizations as setting root password, PRSERV_HOST,
or PACKAGE_FEED_URIS

In common.conf I define all features common to all my distros
(PACKAGE_CLASSES and so on)

I have custom iptables rules, then I have different files for that rules:

    my/layer/recipes-extended/iptables/files/iptables.rules.development
    my/layer/recipes-extended/iptables/files/iptables.rules.production
    my/layer/recipes-extended/iptables/files/iptables.rules.integration

I use a bbappend recipe for iptables, modifiying do_install_append task
like this:

    install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
${D}/etc/iptables/iptables.rules

I use a single image recipe to define all packages installed in my final
image (all of them have the same set if packages, but with different
customizations)

Finally, I wrote a setup-build-env.sh script in my custom layer to
configure the build easily. That script creates
build-${DISTRO_STAGE}/conf/bblayers.conf
and build-${DISTRO_STAGE}/conf/local.conf files with the proper setup,
setting MACHINE, DISTRO and DL_DIR (shared by all distros) properly.

Hope this helps!





2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:

> Hey,
> would really like to see your example.
> Am struggling to get creation of these types of images for a while now.
>
> So far have avoided diving into multiple distros because would like to
> have the option
> of building all the images at the same time (so they are basically the
> same distro).
>
> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com>
> wrote:
>
>> I fixed this issue defining different distro.conf files in my custom
>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
>> (production, rnd, retail, and so on), Then you setup DISTRO in your
>> local.conf to the proper value you want to use. Finally you can use that
>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
>> proper configuration files you want to install in your final image. That
>> works as expected. Hope this helps!
>>
>>
>>
>>
>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>
>>> Hi,
>>>
>>> For the same MACHINE I create the following images:
>>> - myimage-production
>>> - myimage-rnd
>>> - myimage-retail
>>>
>>> The production one has production assisted tools for flashing peripheral
>>> HW, testing vital HW components, writing some serial numbers, etc.
>>>
>>> The rnd one has more packages than the retail one just to help rnd work
>>> and debugging in device, but none of the rnd image extra packages.
>>>
>>> The retail one has the final product image.
>>>
>>> I'm using web and FTP servers. I would like for the rnd version of the
>>> image to have a different nginx configuration to set the root directory to
>>> a development folder, or set an alias.
>>>
>>> Furthermore, I'll have different variant of the device where only the
>>> device SW changes but the platform is identical. So I'll end up with
>>> - myimage2-production
>>> - myimage2-rnd
>>> - myimage2-retail
>>>
>>> I know how to make MACHINE based configuration. How could I do this in
>>> my nginx.bbappend based on image name?
>>>
>>> Thanks,
>>> -Damien
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>>
>> --
>>
>>
>>
>>
>> *NOTA LEGAL*
>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
>> contiene información de carácter confidencial exclusivamente dirigida a su
>> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
>> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
>> o impresión total o parcial. Si ha recibido este correo electrónico por
>> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
>> original juntamente con sus ficheros anexos. Gracias.
>>
>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
>> la adopción de las medidas necesarias para asegurar el tratamiento
>> confidencial de los datos de carácter personal. Así mismo le informamos de
>> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
>> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
>> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
>> derechos de acceso, rectificación, cancelación y oposición mediante un
>> escrito a la siguiente dirección: info@nayarsystems.com
>>
>> *LEGAL NOTE*
>> This email and any attachments to it contains is confidential information
>> exclusively intended for the recipients. Any divulgation, copy or
>> distribution to third parties is prohibited without written permission of
>> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
>> the sender immediately. In accordance with Law 15/1999 of 13 December on
>> the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
>> has adopted the necessary measures to ensure the confidential treatment of
>> personal information. We also inform you that you can exercise your access,
>> rectification, cancellation and opposition rights by send us a mail to:
>> info@nayarsystems.com
>>
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>


-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: info@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
has adopted the necessary measures to ensure the confidential treatment of
personal information. We also inform you that you can exercise your access,
rectification, cancellation and opposition rights by send us a mail to:
info@nayarsystems.com

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

Re: Image specific configuration files

[Alan Martinovic]

Thanks for the replay Iván,
am I reading correctly that this means that you create a single image
file per build
(which can be any of the given types)?
You're setup doesn't allow for building the "developent" and
"production" image at the same time?

Be Well,
Alan



On Fri, Jun 1, 2018 at 11:04 AM, Iván Castell <icastell@nayarsystems.com> wrote:
> I can provide more details. My custom layer has these files related with
> distro:
>
>     my_layer/conf/distro/include/common.conf
>     my_layer/conf/distro/develop.conf
>     my_layer/conf/distro/production.conf
>     my_layer/conf/distro/integration.conf
>
> As an example of the previous files,
> my_layer/conf/distro/include/develop.conf has this content:
>
>     require conf/distro/include/common.conf
>     DISTRO = "my-distro-development"
>     DISTRO_NAME = "OS Development"
>     DISTRO_STAGE = "development"
>     # And here more customizations as setting root password, PRSERV_HOST, or
> PACKAGE_FEED_URIS
>
> In common.conf I define all features common to all my distros
> (PACKAGE_CLASSES and so on)
>
> I have custom iptables rules, then I have different files for that rules:
>
>     my/layer/recipes-extended/iptables/files/iptables.rules.development
>     my/layer/recipes-extended/iptables/files/iptables.rules.production
>     my/layer/recipes-extended/iptables/files/iptables.rules.integration
>
> I use a bbappend recipe for iptables, modifiying do_install_append task like
> this:
>
>     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
> ${D}/etc/iptables/iptables.rules
>
> I use a single image recipe to define all packages installed in my final
> image (all of them have the same set if packages, but with different
> customizations)
>
> Finally, I wrote a setup-build-env.sh script in my custom layer to configure
> the build easily. That script creates
> build-${DISTRO_STAGE}/conf/bblayers.conf and
> build-${DISTRO_STAGE}/conf/local.conf files with the proper setup, setting
> MACHINE, DISTRO and DL_DIR (shared by all distros) properly.
>
> Hope this helps!
>
>
>
>
>
> 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
>>
>> Hey,
>> would really like to see your example.
>> Am struggling to get creation of these types of images for a while now.
>>
>> So far have avoided diving into multiple distros because would like to
>> have the option
>> of building all the images at the same time (so they are basically the
>> same distro).
>>
>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com>
>> wrote:
>>>
>>> I fixed this issue defining different distro.conf files in my custom
>>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
>>> (production, rnd, retail, and so on), Then you setup DISTRO in your
>>> local.conf to the proper value you want to use. Finally you can use that
>>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
>>> proper configuration files you want to install in your final image. That
>>> works as expected. Hope this helps!
>>>
>>>
>>>
>>>
>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> For the same MACHINE I create the following images:
>>>> - myimage-production
>>>> - myimage-rnd
>>>> - myimage-retail
>>>>
>>>> The production one has production assisted tools for flashing peripheral
>>>> HW, testing vital HW components, writing some serial numbers, etc.
>>>>
>>>> The rnd one has more packages than the retail one just to help rnd work
>>>> and debugging in device, but none of the rnd image extra packages.
>>>>
>>>> The retail one has the final product image.
>>>>
>>>> I'm using web and FTP servers. I would like for the rnd version of the
>>>> image to have a different nginx configuration to set the root directory to a
>>>> development folder, or set an alias.
>>>>
>>>> Furthermore, I'll have different variant of the device where only the
>>>> device SW changes but the platform is identical. So I'll end up with
>>>> - myimage2-production
>>>> - myimage2-rnd
>>>> - myimage2-retail
>>>>
>>>> I know how to make MACHINE based configuration. How could I do this in
>>>> my nginx.bbappend based on image name?
>>>>
>>>> Thanks,
>>>> -Damien
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> NOTA LEGAL
>>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
>>> contiene información de carácter confidencial exclusivamente dirigida a su
>>> destinatario y se encuentra protegido por Ley. Cualquier persona distinta de
>>> su destinataria tiene prohibida su reproducción, uso, divulgación, copia o
>>> impresión total o parcial. Si ha recibido este correo electrónico por error,
>>> se ruega lo notifique de inmediato al remitente borrando el mensaje original
>>> juntamente con sus ficheros anexos. Gracias.
>>>
>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
>>> la adopción de las medidas necesarias para asegurar el tratamiento
>>> confidencial de los datos de carácter personal. Así mismo le informamos de
>>> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
>>> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
>>> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
>>> derechos de acceso, rectificación, cancelación y oposición mediante un
>>> escrito a la siguiente dirección: info@nayarsystems.com
>>>
>>> LEGAL NOTE
>>> This email and any attachments to it contains is confidential information
>>> exclusively intended for the recipients. Any divulgation, copy or
>>> distribution to third parties is prohibited without written permission of
>>> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
>>> the sender immediately. In accordance with Law 15/1999 of 13 December on the
>>> Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it has
>>> adopted the necessary measures to ensure the confidential treatment of
>>> personal information. We also inform you that you can exercise your access,
>>> rectification, cancellation and opposition rights by send us a mail to:
>>> info@nayarsystems.com
>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>
>
>
> --
>
>
>
>
> NOTA LEGAL
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario y se encuentra protegido por Ley. Cualquier persona distinta de
> su destinataria tiene prohibida su reproducción, uso, divulgación, copia o
> impresión total o parcial. Si ha recibido este correo electrónico por error,
> se ruega lo notifique de inmediato al remitente borrando el mensaje original
> juntamente con sus ficheros anexos. Gracias.
>
> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
> adopción de las medidas necesarias para asegurar el tratamiento confidencial
> de los datos de carácter personal. Así mismo le informamos de la inclusión
> de sus datos en un fichero bajo la responsabilidad de NAYAR SYSTEMS SL, con
> la finalidad de poder atender los compromisos derivados de la relación que
> mantenemos con usted. Si lo desea, puede ejercer sus derechos de acceso,
> rectificación, cancelación y oposición mediante un escrito a la siguiente
> dirección: info@nayarsystems.com
>
> LEGAL NOTE
> This email and any attachments to it contains is confidential information
> exclusively intended for the recipients. Any divulgation, copy or
> distribution to third parties is prohibited without written permission of
> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
> the sender immediately. In accordance with Law 15/1999 of 13 December on the
> Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it has
> adopted the necessary measures to ensure the confidential treatment of
> personal information. We also inform you that you can exercise your access,
> rectification, cancellation and opposition rights by send us a mail to:
> info@nayarsystems.com
>

Re: Image specific configuration files

[Iván Castell]

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

You are right, my setup is not able to generate two different images at the
same time. To do that, I setup two different builds sharing the download
directory between them.

2018-06-01 11:11 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:

> Thanks for the replay Iván,
> am I reading correctly that this means that you create a single image
> file per build
> (which can be any of the given types)?
> You're setup doesn't allow for building the "developent" and
> "production" image at the same time?
>
> Be Well,
> Alan
>
>
>
> On Fri, Jun 1, 2018 at 11:04 AM, Iván Castell <icastell@nayarsystems.com>
> wrote:
> > I can provide more details. My custom layer has these files related with
> > distro:
> >
> >     my_layer/conf/distro/include/common.conf
> >     my_layer/conf/distro/develop.conf
> >     my_layer/conf/distro/production.conf
> >     my_layer/conf/distro/integration.conf
> >
> > As an example of the previous files,
> > my_layer/conf/distro/include/develop.conf has this content:
> >
> >     require conf/distro/include/common.conf
> >     DISTRO = "my-distro-development"
> >     DISTRO_NAME = "OS Development"
> >     DISTRO_STAGE = "development"
> >     # And here more customizations as setting root password,
> PRSERV_HOST, or
> > PACKAGE_FEED_URIS
> >
> > In common.conf I define all features common to all my distros
> > (PACKAGE_CLASSES and so on)
> >
> > I have custom iptables rules, then I have different files for that rules:
> >
> >     my/layer/recipes-extended/iptables/files/iptables.rules.development
> >     my/layer/recipes-extended/iptables/files/iptables.rules.production
> >     my/layer/recipes-extended/iptables/files/iptables.rules.integration
> >
> > I use a bbappend recipe for iptables, modifiying do_install_append task
> like
> > this:
> >
> >     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
> > ${D}/etc/iptables/iptables.rules
> >
> > I use a single image recipe to define all packages installed in my final
> > image (all of them have the same set if packages, but with different
> > customizations)
> >
> > Finally, I wrote a setup-build-env.sh script in my custom layer to
> configure
> > the build easily. That script creates
> > build-${DISTRO_STAGE}/conf/bblayers.conf and
> > build-${DISTRO_STAGE}/conf/local.conf files with the proper setup,
> setting
> > MACHINE, DISTRO and DL_DIR (shared by all distros) properly.
> >
> > Hope this helps!
> >
> >
> >
> >
> >
> > 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
> >>
> >> Hey,
> >> would really like to see your example.
> >> Am struggling to get creation of these types of images for a while now.
> >>
> >> So far have avoided diving into multiple distros because would like to
> >> have the option
> >> of building all the images at the same time (so they are basically the
> >> same distro).
> >>
> >> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com
> >
> >> wrote:
> >>>
> >>> I fixed this issue defining different distro.conf files in my custom
> >>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
> >>> (production, rnd, retail, and so on), Then you setup DISTRO in your
> >>> local.conf to the proper value you want to use. Finally you can use
> that
> >>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to
> decide the
> >>> proper configuration files you want to install in your final image.
> That
> >>> works as expected. Hope this helps!
> >>>
> >>>
> >>>
> >>>
> >>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> For the same MACHINE I create the following images:
> >>>> - myimage-production
> >>>> - myimage-rnd
> >>>> - myimage-retail
> >>>>
> >>>> The production one has production assisted tools for flashing
> peripheral
> >>>> HW, testing vital HW components, writing some serial numbers, etc.
> >>>>
> >>>> The rnd one has more packages than the retail one just to help rnd
> work
> >>>> and debugging in device, but none of the rnd image extra packages.
> >>>>
> >>>> The retail one has the final product image.
> >>>>
> >>>> I'm using web and FTP servers. I would like for the rnd version of the
> >>>> image to have a different nginx configuration to set the root
> directory to a
> >>>> development folder, or set an alias.
> >>>>
> >>>> Furthermore, I'll have different variant of the device where only the
> >>>> device SW changes but the platform is identical. So I'll end up with
> >>>> - myimage2-production
> >>>> - myimage2-rnd
> >>>> - myimage2-retail
> >>>>
> >>>> I know how to make MACHINE based configuration. How could I do this in
> >>>> my nginx.bbappend based on image name?
> >>>>
> >>>> Thanks,
> >>>> -Damien
> >>>>
> >>>> --
> >>>> _______________________________________________
> >>>> yocto mailing list
> >>>> yocto@yoctoproject.org
> >>>> https://lists.yoctoproject.org/listinfo/yocto
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>>
> >>>
> >>> NOTA LEGAL
> >>> Este correo electrónico y, en su caso, cualquier fichero anexo al
> mismo,
> >>> contiene información de carácter confidencial exclusivamente dirigida
> a su
> >>> destinatario y se encuentra protegido por Ley. Cualquier persona
> distinta de
> >>> su destinataria tiene prohibida su reproducción, uso, divulgación,
> copia o
> >>> impresión total o parcial. Si ha recibido este correo electrónico por
> error,
> >>> se ruega lo notifique de inmediato al remitente borrando el mensaje
> original
> >>> juntamente con sus ficheros anexos. Gracias.
> >>>
> >>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL
> garantiza
> >>> la adopción de las medidas necesarias para asegurar el tratamiento
> >>> confidencial de los datos de carácter personal. Así mismo le
> informamos de
> >>> la inclusión de sus datos en un fichero bajo la responsabilidad de
> NAYAR
> >>> SYSTEMS SL, con la finalidad de poder atender los compromisos
> derivados de
> >>> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
> >>> derechos de acceso, rectificación, cancelación y oposición mediante un
> >>> escrito a la siguiente dirección: info@nayarsystems.com
> >>>
> >>> LEGAL NOTE
> >>> This email and any attachments to it contains is confidential
> information
> >>> exclusively intended for the recipients. Any divulgation, copy or
> >>> distribution to third parties is prohibited without written permission
> of
> >>> NAYAR SYSTEMS SL. If you have received this e-mail in error, please
> notify
> >>> the sender immediately. In accordance with Law 15/1999 of 13 December
> on the
> >>> Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
> has
> >>> adopted the necessary measures to ensure the confidential treatment of
> >>> personal information. We also inform you that you can exercise your
> access,
> >>> rectification, cancellation and opposition rights by send us a mail to:
> >>> info@nayarsystems.com
> >>>
> >>>
> >>> --
> >>> _______________________________________________
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >>>
> >>
> >
> >
> >
> > --
> >
> >
> >
> >
> > NOTA LEGAL
> > Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> > contiene información de carácter confidencial exclusivamente dirigida a
> su
> > destinatario y se encuentra protegido por Ley. Cualquier persona
> distinta de
> > su destinataria tiene prohibida su reproducción, uso, divulgación, copia
> o
> > impresión total o parcial. Si ha recibido este correo electrónico por
> error,
> > se ruega lo notifique de inmediato al remitente borrando el mensaje
> original
> > juntamente con sus ficheros anexos. Gracias.
> >
> > De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
> la
> > adopción de las medidas necesarias para asegurar el tratamiento
> confidencial
> > de los datos de carácter personal. Así mismo le informamos de la
> inclusión
> > de sus datos en un fichero bajo la responsabilidad de NAYAR SYSTEMS SL,
> con
> > la finalidad de poder atender los compromisos derivados de la relación
> que
> > mantenemos con usted. Si lo desea, puede ejercer sus derechos de acceso,
> > rectificación, cancelación y oposición mediante un escrito a la siguiente
> > dirección: info@nayarsystems.com
> >
> > LEGAL NOTE
> > This email and any attachments to it contains is confidential information
> > exclusively intended for the recipients. Any divulgation, copy or
> > distribution to third parties is prohibited without written permission of
> > NAYAR SYSTEMS SL. If you have received this e-mail in error, please
> notify
> > the sender immediately. In accordance with Law 15/1999 of 13 December on
> the
> > Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it has
> > adopted the necessary measures to ensure the confidential treatment of
> > personal information. We also inform you that you can exercise your
> access,
> > rectification, cancellation and opposition rights by send us a mail to:
> > info@nayarsystems.com
> >
>



-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: info@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
has adopted the necessary measures to ensure the confidential treatment of
personal information. We also inform you that you can exercise your access,
rectification, cancellation and opposition rights by send us a mail to:
info@nayarsystems.com

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

Re: Image specific configuration files

[Alexander Kanavin]

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

I have to say defining multiple distros and then tweaking recipes according
to those definitions is not a good practice, as recipes should generally
only access DISTRO_FEATURES and otherwise be distro-agnostic. The above
iptables scenario should be handled with different image recipes, which
pull in (via packages) or create different configurations.

Alex

2018-06-01 12:04 GMT+03:00 Iván Castell <icastell@nayarsystems.com>:

> I can provide more details. My custom layer has these files related with
> distro:
>
>     my_layer/conf/distro/include/common.conf
>     my_layer/conf/distro/develop.conf
>     my_layer/conf/distro/production.conf
>     my_layer/conf/distro/integration.conf
>
> As an example of the previous files, my_layer/conf/distro/include/develop.conf
> has this content:
>
>     require conf/distro/include/common.conf
>     DISTRO = "my-distro-development"
>     DISTRO_NAME = "OS Development"
>     DISTRO_STAGE = "development"
>     # And here more customizations as setting root password, PRSERV_HOST,
> or PACKAGE_FEED_URIS
>
> In common.conf I define all features common to all my distros
> (PACKAGE_CLASSES and so on)
>
> I have custom iptables rules, then I have different files for that rules:
>
>     my/layer/recipes-extended/iptables/files/iptables.rules.development
>     my/layer/recipes-extended/iptables/files/iptables.rules.production
>     my/layer/recipes-extended/iptables/files/iptables.rules.integration
>
> I use a bbappend recipe for iptables, modifiying do_install_append task
> like this:
>
>     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
> ${D}/etc/iptables/iptables.rules
>
> I use a single image recipe to define all packages installed in my final
> image (all of them have the same set if packages, but with different
> customizations)
>
> Finally, I wrote a setup-build-env.sh script in my custom layer to
> configure the build easily. That script creates
> build-${DISTRO_STAGE}/conf/bblayers.conf and build-${DISTRO_STAGE}/conf/
> local.conf files with the proper setup, setting MACHINE, DISTRO and
> DL_DIR (shared by all distros) properly.
>
> Hope this helps!
>
>
>
>
>
> 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
>
>> Hey,
>> would really like to see your example.
>> Am struggling to get creation of these types of images for a while now.
>>
>> So far have avoided diving into multiple distros because would like to
>> have the option
>> of building all the images at the same time (so they are basically the
>> same distro).
>>
>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com>
>> wrote:
>>
>>> I fixed this issue defining different distro.conf files in my custom
>>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
>>> (production, rnd, retail, and so on), Then you setup DISTRO in your
>>> local.conf to the proper value you want to use. Finally you can use that
>>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
>>> proper configuration files you want to install in your final image. That
>>> works as expected. Hope this helps!
>>>
>>>
>>>
>>>
>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> For the same MACHINE I create the following images:
>>>> - myimage-production
>>>> - myimage-rnd
>>>> - myimage-retail
>>>>
>>>> The production one has production assisted tools for flashing
>>>> peripheral HW, testing vital HW components, writing some serial numbers,
>>>> etc.
>>>>
>>>> The rnd one has more packages than the retail one just to help rnd work
>>>> and debugging in device, but none of the rnd image extra packages.
>>>>
>>>> The retail one has the final product image.
>>>>
>>>> I'm using web and FTP servers. I would like for the rnd version of the
>>>> image to have a different nginx configuration to set the root directory to
>>>> a development folder, or set an alias.
>>>>
>>>> Furthermore, I'll have different variant of the device where only the
>>>> device SW changes but the platform is identical. So I'll end up with
>>>> - myimage2-production
>>>> - myimage2-rnd
>>>> - myimage2-retail
>>>>
>>>> I know how to make MACHINE based configuration. How could I do this in
>>>> my nginx.bbappend based on image name?
>>>>
>>>> Thanks,
>>>> -Damien
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> *NOTA LEGAL*
>>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
>>> contiene información de carácter confidencial exclusivamente dirigida a su
>>> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
>>> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
>>> o impresión total o parcial. Si ha recibido este correo electrónico por
>>> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
>>> original juntamente con sus ficheros anexos. Gracias.
>>>
>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
>>> la adopción de las medidas necesarias para asegurar el tratamiento
>>> confidencial de los datos de carácter personal. Así mismo le informamos de
>>> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
>>> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
>>> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
>>> derechos de acceso, rectificación, cancelación y oposición mediante un
>>> escrito a la siguiente dirección: info@nayarsystems.com
>>>
>>> *LEGAL NOTE*
>>> This email and any attachments to it contains is confidential
>>> information exclusively intended for the recipients. Any divulgation, copy
>>> or distribution to third parties is prohibited without written permission
>>> of NAYAR SYSTEMS SL. If you have received this e-mail in error, please
>>> notify the sender immediately. In accordance with Law 15/1999 of 13
>>> December on the Protection of Personal Data, the NAYAR SYSTEMS SL
>>> guarantees that it has adopted the necessary measures to ensure the
>>> confidential treatment of personal information. We also inform you that you
>>> can exercise your access, rectification, cancellation and opposition rights
>>> by send us a mail to: info@nayarsystems.com
>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>
>
> --
>
>
>
>
> *NOTA LEGAL*
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
> o impresión total o parcial. Si ha recibido este correo electrónico por
> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
> original juntamente con sus ficheros anexos. Gracias.
>
> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
> la adopción de las medidas necesarias para asegurar el tratamiento
> confidencial de los datos de carácter personal. Así mismo le informamos de
> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
> derechos de acceso, rectificación, cancelación y oposición mediante un
> escrito a la siguiente dirección: info@nayarsystems.com
>
> *LEGAL NOTE*
> This email and any attachments to it contains is confidential information
> exclusively intended for the recipients. Any divulgation, copy or
> distribution to third parties is prohibited without written permission of
> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
> the sender immediately. In accordance with Law 15/1999 of 13 December on
> the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
> has adopted the necessary measures to ensure the confidential treatment of
> personal information. We also inform you that you can exercise your access,
> rectification, cancellation and opposition rights by send us a mail to:
> info@nayarsystems.com
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

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

Re: Image specific configuration files

[Alan Martinovic]

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

Hey Alexander,
you seem to have a good understanding on the concepts.
Would you say that:

> A build always builds a single distro

is somewhat of a rule?




On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> I have to say defining multiple distros and then tweaking recipes
> according to those definitions is not a good practice, as recipes should
> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
> above iptables scenario should be handled with different image recipes,
> which pull in (via packages) or create different configurations.
>
> Alex
>
> 2018-06-01 12:04 GMT+03:00 Iván Castell <icastell@nayarsystems.com>:
>
>> I can provide more details. My custom layer has these files related with
>> distro:
>>
>>     my_layer/conf/distro/include/common.conf
>>     my_layer/conf/distro/develop.conf
>>     my_layer/conf/distro/production.conf
>>     my_layer/conf/distro/integration.conf
>>
>> As an example of the previous files, my_layer/conf/distro/include/develop.conf
>> has this content:
>>
>>     require conf/distro/include/common.conf
>>     DISTRO = "my-distro-development"
>>     DISTRO_NAME = "OS Development"
>>     DISTRO_STAGE = "development"
>>     # And here more customizations as setting root password, PRSERV_HOST,
>> or PACKAGE_FEED_URIS
>>
>> In common.conf I define all features common to all my distros
>> (PACKAGE_CLASSES and so on)
>>
>> I have custom iptables rules, then I have different files for that rules:
>>
>>     my/layer/recipes-extended/iptables/files/iptables.rules.development
>>     my/layer/recipes-extended/iptables/files/iptables.rules.production
>>     my/layer/recipes-extended/iptables/files/iptables.rules.integration
>>
>> I use a bbappend recipe for iptables, modifiying do_install_append task
>> like this:
>>
>>     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
>> ${D}/etc/iptables/iptables.rules
>>
>> I use a single image recipe to define all packages installed in my final
>> image (all of them have the same set if packages, but with different
>> customizations)
>>
>> Finally, I wrote a setup-build-env.sh script in my custom layer to
>> configure the build easily. That script creates
>> build-${DISTRO_STAGE}/conf/bblayers.conf and build-${DISTRO_STAGE}/conf/
>> local.conf files with the proper setup, setting MACHINE, DISTRO and
>> DL_DIR (shared by all distros) properly.
>>
>> Hope this helps!
>>
>>
>>
>>
>>
>> 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
>>
>>> Hey,
>>> would really like to see your example.
>>> Am struggling to get creation of these types of images for a while now.
>>>
>>> So far have avoided diving into multiple distros because would like to
>>> have the option
>>> of building all the images at the same time (so they are basically the
>>> same distro).
>>>
>>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com>
>>> wrote:
>>>
>>>> I fixed this issue defining different distro.conf files in my custom
>>>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
>>>> (production, rnd, retail, and so on), Then you setup DISTRO in your
>>>> local.conf to the proper value you want to use. Finally you can use that
>>>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
>>>> proper configuration files you want to install in your final image. That
>>>> works as expected. Hope this helps!
>>>>
>>>>
>>>>
>>>>
>>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> For the same MACHINE I create the following images:
>>>>> - myimage-production
>>>>> - myimage-rnd
>>>>> - myimage-retail
>>>>>
>>>>> The production one has production assisted tools for flashing
>>>>> peripheral HW, testing vital HW components, writing some serial numbers,
>>>>> etc.
>>>>>
>>>>> The rnd one has more packages than the retail one just to help rnd
>>>>> work and debugging in device, but none of the rnd image extra packages.
>>>>>
>>>>> The retail one has the final product image.
>>>>>
>>>>> I'm using web and FTP servers. I would like for the rnd version of the
>>>>> image to have a different nginx configuration to set the root directory to
>>>>> a development folder, or set an alias.
>>>>>
>>>>> Furthermore, I'll have different variant of the device where only the
>>>>> device SW changes but the platform is identical. So I'll end up with
>>>>> - myimage2-production
>>>>> - myimage2-rnd
>>>>> - myimage2-retail
>>>>>
>>>>> I know how to make MACHINE based configuration. How could I do this in
>>>>> my nginx.bbappend based on image name?
>>>>>
>>>>> Thanks,
>>>>> -Damien
>>>>>
>>>>> --
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> *NOTA LEGAL*
>>>> Este correo electrónico y, en su caso, cualquier fichero anexo al
>>>> mismo, contiene información de carácter confidencial exclusivamente
>>>> dirigida a su destinatario y se encuentra protegido por Ley. Cualquier
>>>> persona distinta de su destinataria tiene prohibida su reproducción, uso,
>>>> divulgación, copia o impresión total o parcial. Si ha recibido este correo
>>>> electrónico por error, se ruega lo notifique de inmediato al remitente
>>>> borrando el mensaje original juntamente con sus ficheros anexos. Gracias.
>>>>
>>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL
>>>> garantiza la adopción de las medidas necesarias para asegurar el
>>>> tratamiento confidencial de los datos de carácter personal. Así mismo le
>>>> informamos de la inclusión de sus datos en un fichero bajo la
>>>> responsabilidad de NAYAR SYSTEMS SL, con la finalidad de poder atender los
>>>> compromisos derivados de la relación que mantenemos con usted. Si lo desea,
>>>> puede ejercer sus derechos de acceso, rectificación, cancelación y
>>>> oposición mediante un escrito a la siguiente dirección:
>>>> info@nayarsystems.com
>>>>
>>>> *LEGAL NOTE*
>>>> This email and any attachments to it contains is confidential
>>>> information exclusively intended for the recipients. Any divulgation, copy
>>>> or distribution to third parties is prohibited without written permission
>>>> of NAYAR SYSTEMS SL. If you have received this e-mail in error, please
>>>> notify the sender immediately. In accordance with Law 15/1999 of 13
>>>> December on the Protection of Personal Data, the NAYAR SYSTEMS SL
>>>> guarantees that it has adopted the necessary measures to ensure the
>>>> confidential treatment of personal information. We also inform you that you
>>>> can exercise your access, rectification, cancellation and opposition rights
>>>> by send us a mail to: info@nayarsystems.com
>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>
>>
>>
>> --
>>
>>
>>
>>
>> *NOTA LEGAL*
>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
>> contiene información de carácter confidencial exclusivamente dirigida a su
>> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
>> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
>> o impresión total o parcial. Si ha recibido este correo electrónico por
>> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
>> original juntamente con sus ficheros anexos. Gracias.
>>
>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
>> la adopción de las medidas necesarias para asegurar el tratamiento
>> confidencial de los datos de carácter personal. Así mismo le informamos de
>> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
>> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
>> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
>> derechos de acceso, rectificación, cancelación y oposición mediante un
>> escrito a la siguiente dirección: info@nayarsystems.com
>>
>> *LEGAL NOTE*
>> This email and any attachments to it contains is confidential information
>> exclusively intended for the recipients. Any divulgation, copy or
>> distribution to third parties is prohibited without written permission of
>> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
>> the sender immediately. In accordance with Law 15/1999 of 13 December on
>> the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
>> has adopted the necessary measures to ensure the confidential treatment of
>> personal information. We also inform you that you can exercise your access,
>> rectification, cancellation and opposition rights by send us a mail to:
>> info@nayarsystems.com
>>
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>

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

Re: Image specific configuration files

[Alexander Kanavin]

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

If a build is 'a single bitbake invocation', then yes - it builds for a
single distro and for a specific target machine, but it can build multiple
recipes (which includes multiple images, as images are defined with
recipes).

Alex


2018-06-01 13:07 GMT+03:00 Alan Martinovic <alan.martinovic@senic.com>:

> Hey Alexander,
> you seem to have a good understanding on the concepts.
> Would you say that:
>
> > A build always builds a single distro
>
> is somewhat of a rule?
>
>
>
>
> On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin <alex.kanavin@gmail.com
> > wrote:
>
>> I have to say defining multiple distros and then tweaking recipes
>> according to those definitions is not a good practice, as recipes should
>> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
>> above iptables scenario should be handled with different image recipes,
>> which pull in (via packages) or create different configurations.
>>
>> Alex
>>
>> 2018-06-01 12:04 GMT+03:00 Iván Castell <icastell@nayarsystems.com>:
>>
>>> I can provide more details. My custom layer has these files related with
>>> distro:
>>>
>>>     my_layer/conf/distro/include/common.conf
>>>     my_layer/conf/distro/develop.conf
>>>     my_layer/conf/distro/production.conf
>>>     my_layer/conf/distro/integration.conf
>>>
>>> As an example of the previous files, my_layer/conf/distro/include/develop.conf
>>> has this content:
>>>
>>>     require conf/distro/include/common.conf
>>>     DISTRO = "my-distro-development"
>>>     DISTRO_NAME = "OS Development"
>>>     DISTRO_STAGE = "development"
>>>     # And here more customizations as setting root password,
>>> PRSERV_HOST, or PACKAGE_FEED_URIS
>>>
>>> In common.conf I define all features common to all my distros
>>> (PACKAGE_CLASSES and so on)
>>>
>>> I have custom iptables rules, then I have different files for that rules:
>>>
>>>     my/layer/recipes-extended/iptables/files/iptables.rules.development
>>>     my/layer/recipes-extended/iptables/files/iptables.rules.production
>>>     my/layer/recipes-extended/iptables/files/iptables.rules.integration
>>>
>>> I use a bbappend recipe for iptables, modifiying do_install_append task
>>> like this:
>>>
>>>     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
>>> ${D}/etc/iptables/iptables.rules
>>>
>>> I use a single image recipe to define all packages installed in my final
>>> image (all of them have the same set if packages, but with different
>>> customizations)
>>>
>>> Finally, I wrote a setup-build-env.sh script in my custom layer to
>>> configure the build easily. That script creates
>>> build-${DISTRO_STAGE}/conf/bblayers.conf and build-${DISTRO_STAGE}/conf/
>>> local.conf files with the proper setup, setting MACHINE, DISTRO and
>>> DL_DIR (shared by all distros) properly.
>>>
>>> Hope this helps!
>>>
>>>
>>>
>>>
>>>
>>> 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
>>>
>>>> Hey,
>>>> would really like to see your example.
>>>> Am struggling to get creation of these types of images for a while now.
>>>>
>>>> So far have avoided diving into multiple distros because would like to
>>>> have the option
>>>> of building all the images at the same time (so they are basically the
>>>> same distro).
>>>>
>>>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com
>>>> > wrote:
>>>>
>>>>> I fixed this issue defining different distro.conf files in my custom
>>>>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
>>>>> (production, rnd, retail, and so on), Then you setup DISTRO in your
>>>>> local.conf to the proper value you want to use. Finally you can use that
>>>>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
>>>>> proper configuration files you want to install in your final image. That
>>>>> works as expected. Hope this helps!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> For the same MACHINE I create the following images:
>>>>>> - myimage-production
>>>>>> - myimage-rnd
>>>>>> - myimage-retail
>>>>>>
>>>>>> The production one has production assisted tools for flashing
>>>>>> peripheral HW, testing vital HW components, writing some serial numbers,
>>>>>> etc.
>>>>>>
>>>>>> The rnd one has more packages than the retail one just to help rnd
>>>>>> work and debugging in device, but none of the rnd image extra packages.
>>>>>>
>>>>>> The retail one has the final product image.
>>>>>>
>>>>>> I'm using web and FTP servers. I would like for the rnd version of
>>>>>> the image to have a different nginx configuration to set the root directory
>>>>>> to a development folder, or set an alias.
>>>>>>
>>>>>> Furthermore, I'll have different variant of the device where only the
>>>>>> device SW changes but the platform is identical. So I'll end up with
>>>>>> - myimage2-production
>>>>>> - myimage2-rnd
>>>>>> - myimage2-retail
>>>>>>
>>>>>> I know how to make MACHINE based configuration. How could I do this
>>>>>> in my nginx.bbappend based on image name?
>>>>>>
>>>>>> Thanks,
>>>>>> -Damien
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *NOTA LEGAL*
>>>>> Este correo electrónico y, en su caso, cualquier fichero anexo al
>>>>> mismo, contiene información de carácter confidencial exclusivamente
>>>>> dirigida a su destinatario y se encuentra protegido por Ley. Cualquier
>>>>> persona distinta de su destinataria tiene prohibida su reproducción, uso,
>>>>> divulgación, copia o impresión total o parcial. Si ha recibido este correo
>>>>> electrónico por error, se ruega lo notifique de inmediato al remitente
>>>>> borrando el mensaje original juntamente con sus ficheros anexos. Gracias.
>>>>>
>>>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL
>>>>> garantiza la adopción de las medidas necesarias para asegurar el
>>>>> tratamiento confidencial de los datos de carácter personal. Así mismo le
>>>>> informamos de la inclusión de sus datos en un fichero bajo la
>>>>> responsabilidad de NAYAR SYSTEMS SL, con la finalidad de poder atender los
>>>>> compromisos derivados de la relación que mantenemos con usted. Si lo desea,
>>>>> puede ejercer sus derechos de acceso, rectificación, cancelación y
>>>>> oposición mediante un escrito a la siguiente dirección:
>>>>> info@nayarsystems.com
>>>>>
>>>>> *LEGAL NOTE*
>>>>> This email and any attachments to it contains is confidential
>>>>> information exclusively intended for the recipients. Any divulgation, copy
>>>>> or distribution to third parties is prohibited without written permission
>>>>> of NAYAR SYSTEMS SL. If you have received this e-mail in error, please
>>>>> notify the sender immediately. In accordance with Law 15/1999 of 13
>>>>> December on the Protection of Personal Data, the NAYAR SYSTEMS SL
>>>>> guarantees that it has adopted the necessary measures to ensure the
>>>>> confidential treatment of personal information. We also inform you that you
>>>>> can exercise your access, rectification, cancellation and opposition rights
>>>>> by send us a mail to: info@nayarsystems.com
>>>>>
>>>>>
>>>>> --
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> *NOTA LEGAL*
>>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
>>> contiene información de carácter confidencial exclusivamente dirigida a su
>>> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
>>> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
>>> o impresión total o parcial. Si ha recibido este correo electrónico por
>>> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
>>> original juntamente con sus ficheros anexos. Gracias.
>>>
>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
>>> la adopción de las medidas necesarias para asegurar el tratamiento
>>> confidencial de los datos de carácter personal. Así mismo le informamos de
>>> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
>>> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
>>> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
>>> derechos de acceso, rectificación, cancelación y oposición mediante un
>>> escrito a la siguiente dirección: info@nayarsystems.com
>>>
>>> *LEGAL NOTE*
>>> This email and any attachments to it contains is confidential
>>> information exclusively intended for the recipients. Any divulgation, copy
>>> or distribution to third parties is prohibited without written permission
>>> of NAYAR SYSTEMS SL. If you have received this e-mail in error, please
>>> notify the sender immediately. In accordance with Law 15/1999 of 13
>>> December on the Protection of Personal Data, the NAYAR SYSTEMS SL
>>> guarantees that it has adopted the necessary measures to ensure the
>>> confidential treatment of personal information. We also inform you that you
>>> can exercise your access, rectification, cancellation and opposition rights
>>> by send us a mail to: info@nayarsystems.com
>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>

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

Re: Image specific configuration files

[Alan Martinovic]

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

Yes, much better phrasing:

> A single bitbake invocation always builds a single distro for a specific
target machine

Thanks

On Fri, Jun 1, 2018 at 12:18 PM, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> If a build is 'a single bitbake invocation', then yes - it builds for a
> single distro and for a specific target machine, but it can build multiple
> recipes (which includes multiple images, as images are defined with
> recipes).
>
> Alex
>
>
> 2018-06-01 13:07 GMT+03:00 Alan Martinovic <alan.martinovic@senic.com>:
>
>> Hey Alexander,
>> you seem to have a good understanding on the concepts.
>> Would you say that:
>>
>> > A build always builds a single distro
>>
>> is somewhat of a rule?
>>
>>
>>
>>
>> On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin <
>> alex.kanavin@gmail.com> wrote:
>>
>>> I have to say defining multiple distros and then tweaking recipes
>>> according to those definitions is not a good practice, as recipes should
>>> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
>>> above iptables scenario should be handled with different image recipes,
>>> which pull in (via packages) or create different configurations.
>>>
>>> Alex
>>>
>>> 2018-06-01 12:04 GMT+03:00 Iván Castell <icastell@nayarsystems.com>:
>>>
>>>> I can provide more details. My custom layer has these files related
>>>> with distro:
>>>>
>>>>     my_layer/conf/distro/include/common.conf
>>>>     my_layer/conf/distro/develop.conf
>>>>     my_layer/conf/distro/production.conf
>>>>     my_layer/conf/distro/integration.conf
>>>>
>>>> As an example of the previous files, my_layer/conf/distro/include/develop.conf
>>>> has this content:
>>>>
>>>>     require conf/distro/include/common.conf
>>>>     DISTRO = "my-distro-development"
>>>>     DISTRO_NAME = "OS Development"
>>>>     DISTRO_STAGE = "development"
>>>>     # And here more customizations as setting root password,
>>>> PRSERV_HOST, or PACKAGE_FEED_URIS
>>>>
>>>> In common.conf I define all features common to all my distros
>>>> (PACKAGE_CLASSES and so on)
>>>>
>>>> I have custom iptables rules, then I have different files for that
>>>> rules:
>>>>
>>>>     my/layer/recipes-extended/iptables/files/iptables.rules.development
>>>>     my/layer/recipes-extended/iptables/files/iptables.rules.production
>>>>     my/layer/recipes-extended/iptables/files/iptables.rules.integration
>>>>
>>>> I use a bbappend recipe for iptables, modifiying do_install_append task
>>>> like this:
>>>>
>>>>     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
>>>> ${D}/etc/iptables/iptables.rules
>>>>
>>>> I use a single image recipe to define all packages installed in my
>>>> final image (all of them have the same set if packages, but with different
>>>> customizations)
>>>>
>>>> Finally, I wrote a setup-build-env.sh script in my custom layer to
>>>> configure the build easily. That script creates
>>>> build-${DISTRO_STAGE}/conf/bblayers.conf and
>>>> build-${DISTRO_STAGE}/conf/local.conf files with the proper setup,
>>>> setting MACHINE, DISTRO and DL_DIR (shared by all distros) properly.
>>>>
>>>> Hope this helps!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
>>>>
>>>>> Hey,
>>>>> would really like to see your example.
>>>>> Am struggling to get creation of these types of images for a while now.
>>>>>
>>>>> So far have avoided diving into multiple distros because would like to
>>>>> have the option
>>>>> of building all the images at the same time (so they are basically the
>>>>> same distro).
>>>>>
>>>>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <
>>>>> icastell@nayarsystems.com> wrote:
>>>>>
>>>>>> I fixed this issue defining different distro.conf files in my custom
>>>>>> layer, adding a custom variable DISTRO_STAGE with the name of my distro
>>>>>> (production, rnd, retail, and so on), Then you setup DISTRO in your
>>>>>> local.conf to the proper value you want to use. Finally you can use that
>>>>>> DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the
>>>>>> proper configuration files you want to install in your final image. That
>>>>>> works as expected. Hope this helps!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> For the same MACHINE I create the following images:
>>>>>>> - myimage-production
>>>>>>> - myimage-rnd
>>>>>>> - myimage-retail
>>>>>>>
>>>>>>> The production one has production assisted tools for flashing
>>>>>>> peripheral HW, testing vital HW components, writing some serial numbers,
>>>>>>> etc.
>>>>>>>
>>>>>>> The rnd one has more packages than the retail one just to help rnd
>>>>>>> work and debugging in device, but none of the rnd image extra packages.
>>>>>>>
>>>>>>> The retail one has the final product image.
>>>>>>>
>>>>>>> I'm using web and FTP servers. I would like for the rnd version of
>>>>>>> the image to have a different nginx configuration to set the root directory
>>>>>>> to a development folder, or set an alias.
>>>>>>>
>>>>>>> Furthermore, I'll have different variant of the device where only
>>>>>>> the device SW changes but the platform is identical. So I'll end up with
>>>>>>> - myimage2-production
>>>>>>> - myimage2-rnd
>>>>>>> - myimage2-retail
>>>>>>>
>>>>>>> I know how to make MACHINE based configuration. How could I do this
>>>>>>> in my nginx.bbappend based on image name?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Damien
>>>>>>>
>>>>>>> --
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *NOTA LEGAL*
>>>>>> Este correo electrónico y, en su caso, cualquier fichero anexo al
>>>>>> mismo, contiene información de carácter confidencial exclusivamente
>>>>>> dirigida a su destinatario y se encuentra protegido por Ley. Cualquier
>>>>>> persona distinta de su destinataria tiene prohibida su reproducción, uso,
>>>>>> divulgación, copia o impresión total o parcial. Si ha recibido este correo
>>>>>> electrónico por error, se ruega lo notifique de inmediato al remitente
>>>>>> borrando el mensaje original juntamente con sus ficheros anexos. Gracias.
>>>>>>
>>>>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL
>>>>>> garantiza la adopción de las medidas necesarias para asegurar el
>>>>>> tratamiento confidencial de los datos de carácter personal. Así mismo le
>>>>>> informamos de la inclusión de sus datos en un fichero bajo la
>>>>>> responsabilidad de NAYAR SYSTEMS SL, con la finalidad de poder atender los
>>>>>> compromisos derivados de la relación que mantenemos con usted. Si lo desea,
>>>>>> puede ejercer sus derechos de acceso, rectificación, cancelación y
>>>>>> oposición mediante un escrito a la siguiente dirección:
>>>>>> info@nayarsystems.com
>>>>>>
>>>>>> *LEGAL NOTE*
>>>>>> This email and any attachments to it contains is confidential
>>>>>> information exclusively intended for the recipients. Any divulgation, copy
>>>>>> or distribution to third parties is prohibited without written permission
>>>>>> of NAYAR SYSTEMS SL. If you have received this e-mail in error, please
>>>>>> notify the sender immediately. In accordance with Law 15/1999 of 13
>>>>>> December on the Protection of Personal Data, the NAYAR SYSTEMS SL
>>>>>> guarantees that it has adopted the necessary measures to ensure the
>>>>>> confidential treatment of personal information. We also inform you that you
>>>>>> can exercise your access, rectification, cancellation and opposition rights
>>>>>> by send us a mail to: info@nayarsystems.com
>>>>>>
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> *NOTA LEGAL*
>>>> Este correo electrónico y, en su caso, cualquier fichero anexo al
>>>> mismo, contiene información de carácter confidencial exclusivamente
>>>> dirigida a su destinatario y se encuentra protegido por Ley. Cualquier
>>>> persona distinta de su destinataria tiene prohibida su reproducción, uso,
>>>> divulgación, copia o impresión total o parcial. Si ha recibido este correo
>>>> electrónico por error, se ruega lo notifique de inmediato al remitente
>>>> borrando el mensaje original juntamente con sus ficheros anexos. Gracias.
>>>>
>>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL
>>>> garantiza la adopción de las medidas necesarias para asegurar el
>>>> tratamiento confidencial de los datos de carácter personal. Así mismo le
>>>> informamos de la inclusión de sus datos en un fichero bajo la
>>>> responsabilidad de NAYAR SYSTEMS SL, con la finalidad de poder atender los
>>>> compromisos derivados de la relación que mantenemos con usted. Si lo desea,
>>>> puede ejercer sus derechos de acceso, rectificación, cancelación y
>>>> oposición mediante un escrito a la siguiente dirección:
>>>> info@nayarsystems.com
>>>>
>>>> *LEGAL NOTE*
>>>> This email and any attachments to it contains is confidential
>>>> information exclusively intended for the recipients. Any divulgation, copy
>>>> or distribution to third parties is prohibited without written permission
>>>> of NAYAR SYSTEMS SL. If you have received this e-mail in error, please
>>>> notify the sender immediately. In accordance with Law 15/1999 of 13
>>>> December on the Protection of Personal Data, the NAYAR SYSTEMS SL
>>>> guarantees that it has adopted the necessary measures to ensure the
>>>> confidential treatment of personal information. We also inform you that you
>>>> can exercise your access, rectification, cancellation and opposition rights
>>>> by send us a mail to: info@nayarsystems.com
>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>
>>
>

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

Re: Image specific configuration files

[Ulf Samuelsson]

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

In my current project they have defined bbclass files to allow variants of recipes.
The recipe would then contain  do_install_append_XYZ’s for each class.

BBCLASSEXTEND = ”production rnd retail”

would ensure you would get nginx-production, nginx-rnd, nginx-retail ipks.

This way you have one recipe generating three variants in the same build.

Don’t have the source in front of me  so I can’t share the bbclass (right now at least)

Best Regards,
Ulf Samuelsson
+46 722 427 437

> 1 juni 2018 kl. 12:40 skrev Alan Martinovic <alan.martinovic@senic.com>:
> 
> Yes, much better phrasing:
> 
> > A single bitbake invocation always builds a single distro for a specific target machine
> 
> Thanks 
> 
>> On Fri, Jun 1, 2018 at 12:18 PM, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>> If a build is 'a single bitbake invocation', then yes - it builds for a single distro and for a specific target machine, but it can build multiple recipes (which includes multiple images, as images are defined with recipes).
>> 
>> Alex
>> 
>> 
>> 2018-06-01 13:07 GMT+03:00 Alan Martinovic <alan.martinovic@senic.com>:
>>> Hey Alexander,
>>> you seem to have a good understanding on the concepts.
>>> Would you say that:
>>> 
>>> > A build always builds a single distro
>>> 
>>> is somewhat of a rule?
>>> 
>>> 
>>> 
>>> 
>>>> On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>>>> I have to say defining multiple distros and then tweaking recipes according to those definitions is not a good practice, as recipes should generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The above iptables scenario should be handled with different image recipes, which pull in (via packages) or create different configurations.
>>>> 
>>>> Alex
>>>> 
>>>> 2018-06-01 12:04 GMT+03:00 Iván Castell <icastell@nayarsystems.com>:
>>>>> I can provide more details. My custom layer has these files related with distro:
>>>>> 
>>>>>     my_layer/conf/distro/include/common.conf
>>>>>     my_layer/conf/distro/develop.conf
>>>>>     my_layer/conf/distro/production.conf
>>>>>     my_layer/conf/distro/integration.conf
>>>>> 
>>>>> As an example of the previous files, my_layer/conf/distro/include/develop.conf has this content:
>>>>> 
>>>>>     require conf/distro/include/common.conf
>>>>>     DISTRO = "my-distro-development"
>>>>>     DISTRO_NAME = "OS Development"
>>>>>     DISTRO_STAGE = "development"
>>>>>     # And here more customizations as setting root password, PRSERV_HOST, or PACKAGE_FEED_URIS
>>>>> 
>>>>> In common.conf I define all features common to all my distros (PACKAGE_CLASSES and so on)
>>>>> 
>>>>> I have custom iptables rules, then I have different files for that rules:
>>>>> 
>>>>>     my/layer/recipes-extended/iptables/files/iptables.rules.development
>>>>>     my/layer/recipes-extended/iptables/files/iptables.rules.production
>>>>>     my/layer/recipes-extended/iptables/files/iptables.rules.integration
>>>>> 
>>>>> I use a bbappend recipe for iptables, modifiying do_install_append task like this:
>>>>> 
>>>>>     install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE} ${D}/etc/iptables/iptables.rules
>>>>> 
>>>>> I use a single image recipe to define all packages installed in my final image (all of them have the same set if packages, but with different customizations)
>>>>> 
>>>>> Finally, I wrote a setup-build-env.sh script in my custom layer to configure the build easily. That script creates build-${DISTRO_STAGE}/conf/bblayers.conf and build-${DISTRO_STAGE}/conf/local.conf files with the proper setup, setting MACHINE, DISTRO and DL_DIR (shared by all distros) properly.
>>>>> 
>>>>> Hope this helps!
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 2018-06-01 10:21 GMT+02:00 Alan Martinovic <alan.martinovic@senic.com>:
>>>>>> Hey,
>>>>>> would really like to see your example.
>>>>>> Am struggling to get creation of these types of images for a while now.
>>>>>> 
>>>>>> So far have avoided diving into multiple distros because would like to have the option
>>>>>> of building all the images at the same time (so they are basically the same distro).
>>>>>> 
>>>>>>> On Fri, Jun 1, 2018 at 8:13 AM, Iván Castell <icastell@nayarsystems.com> wrote:
>>>>>>> I fixed this issue defining different distro.conf files in my custom layer, adding a custom variable DISTRO_STAGE with the name of my distro (production, rnd, retail, and so on), Then you setup DISTRO in your local.conf to the proper value you want to use. Finally you can use that DISTRO_STAGE variable in your custom .bb or .bbappend recipes to decide the proper configuration files you want to install in your final image. That works as expected. Hope this helps!
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 2018-06-01 7:46 GMT+02:00 Damien LEFEVRE <lefevre.da@gmail.com>:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> For the same MACHINE I create the following images:
>>>>>>>> - myimage-production
>>>>>>>> - myimage-rnd
>>>>>>>> - myimage-retail
>>>>>>>> 
>>>>>>>> The production one has production assisted tools for flashing peripheral HW, testing vital HW components, writing some serial numbers, etc.
>>>>>>>> 
>>>>>>>> The rnd one has more packages than the retail one just to help rnd work and debugging in device, but none of the rnd image extra packages. 
>>>>>>>> 
>>>>>>>> The retail one has the final product image.
>>>>>>>> 
>>>>>>>> I'm using web and FTP servers. I would like for the rnd version of the image to have a different nginx configuration to set the root directory to a development folder, or set an alias.
>>>>>>>> 
>>>>>>>> Furthermore, I'll have different variant of the device where only the device SW changes but the platform is identical. So I'll end up with 
>>>>>>>> - myimage2-production
>>>>>>>> - myimage2-rnd
>>>>>>>> - myimage2-retail
>>>>>>>> 
>>>>>>>> I know how to make MACHINE based configuration. How could I do this in my nginx.bbappend based on image name?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> -Damien
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> _______________________________________________
>>>>>>>> yocto mailing list
>>>>>>>> yocto@yoctoproject.org
>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> NOTA LEGAL
>>>>>>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario y se encuentra protegido por Ley. Cualquier persona distinta de su destinataria tiene prohibida su reproducción, uso, divulgación, copia o impresión total o parcial. Si ha recibido este correo electrónico por error, se ruega lo notifique de inmediato al remitente borrando el mensaje original juntamente con sus ficheros anexos. Gracias.
>>>>>>> 
>>>>>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la adopción de las medidas necesarias para asegurar el tratamiento confidencial de los datos de carácter personal. Así mismo le informamos de la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de la relación que mantenemos con usted. Si lo desea, puede ejercer sus derechos de acceso, rectificación, cancelación y oposición mediante un escrito a la siguiente dirección: info@nayarsystems.com
>>>>>>> 
>>>>>>> LEGAL NOTE
>>>>>>> This email and any attachments to it contains is confidential information exclusively intended for the recipients. Any divulgation, copy or distribution to third parties is prohibited without written permission of NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify the sender immediately. In accordance with Law 15/1999 of 13 December on the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it has adopted the necessary measures to ensure the confidential treatment of personal information. We also inform you that you can exercise your access, rectification, cancellation and opposition rights by send us a mail to: info@nayarsystems.com
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> NOTA LEGAL
>>>>> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario y se encuentra protegido por Ley. Cualquier persona distinta de su destinataria tiene prohibida su reproducción, uso, divulgación, copia o impresión total o parcial. Si ha recibido este correo electrónico por error, se ruega lo notifique de inmediato al remitente borrando el mensaje original juntamente con sus ficheros anexos. Gracias.
>>>>> 
>>>>> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la adopción de las medidas necesarias para asegurar el tratamiento confidencial de los datos de carácter personal. Así mismo le informamos de la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de la relación que mantenemos con usted. Si lo desea, puede ejercer sus derechos de acceso, rectificación, cancelación y oposición mediante un escrito a la siguiente dirección: info@nayarsystems.com
>>>>> 
>>>>> LEGAL NOTE
>>>>> This email and any attachments to it contains is confidential information exclusively intended for the recipients. Any divulgation, copy or distribution to third parties is prohibited without written permission of NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify the sender immediately. In accordance with Law 15/1999 of 13 December on the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it has adopted the necessary measures to ensure the confidential treatment of personal information. We also inform you that you can exercise your access, rectification, cancellation and opposition rights by send us a mail to: info@nayarsystems.com
>>>>> 
>>>>> 
>>>>> -- 
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>> 
>>>> 
>>> 
>> 
> 
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: Image specific configuration files

[Iván Castell]

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

2018-06-01 11:24 GMT+02:00 Alexander Kanavin <alex.kanavin@gmail.com>:

> I have to say defining multiple distros and then tweaking recipes
> according to those definitions is not a good practice, as recipes should
> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
> above iptables scenario should be handled with different image recipes,
> which pull in (via packages) or create different configurations.
>


That has sense. We will refactorize our Yocto repo as suggested. Always
very helpfull with all your comments Mr Alexander. Thank you very much! :)

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

Re: Image specific configuration files

[Damien LEFEVRE]

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

Thanks a lot everyone, this is very helpful =)

On Fri, Jun 1, 2018 at 2:14 PM, Iván Castell <icastell@nayarsystems.com>
wrote:

>
>
> 2018-06-01 11:24 GMT+02:00 Alexander Kanavin <alex.kanavin@gmail.com>:
>
>> I have to say defining multiple distros and then tweaking recipes
>> according to those definitions is not a good practice, as recipes should
>> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
>> above iptables scenario should be handled with different image recipes,
>> which pull in (via packages) or create different configurations.
>>
>
>
> That has sense. We will refactorize our Yocto repo as suggested. Always
> very helpfull with all your comments Mr Alexander. Thank you very much! :)
>
>
>

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

Re: Image specific configuration files

[Ulf Samuelsson]

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

Here is the idea developed at Atlas Copco.

Not my code, but I thought it useful for this problem


define three bbclasses.

production.bbclass, rnd.bbclass, release.bbclass containing:

==========================

# Class for use in BBCLASSEXTEND to make it easier to have a single recipe that
# build and generate packages separately for release and normal images.
#
# Usage:
# BBCLASSEXTEND = "release"

CLASSOVERRIDE .= ":class-release"

python release_virtclass_handler () {
    # Do nothing if this is inherited, as it's for BBCLASSEXTEND
    if "release" not in (d.getVar('BBCLASSEXTEND') or ""):
        bb.error("Don't inherit release, use BBCLASSEXTEND")
        return

    # Restore BPN
    bpn = d.getVar('BPN')
    newbpn = bpn.replace('-release', '')
    d.setVar('BPN', newbpn)

    # Use default FILESPATH searching for patches and files
    filespath = d.getVar('FILESPATH', True)
    newfilespath = filespath.replace('-release', '')
    d.setVar('FILESPATH', newfilespath)
}

addhandler release_virtclass_handler
release_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

==========================

In a bbappend you use the classes:


==========================

SRC_URI_append_class-production = " \
    file://rcS.production \
"

SRC_URI_append_class-rnd = " \
    file://rcS.rnd \
"

SRC_URI_append_class-release = " \
    file://rcS.release \
"

do_install_append_class-production () {
    install -m 755 ${WORKDIR}/rcS.production ${D}${sysconfdir}/init.d/rcS
}

do_install_append_class-rnd () {
    install -m 755 ${WORKDIR}/rcS.rnd ${D}${sysconfdir}/init.d/rcS
}

do_install_append_class-release () {
    install -m 755 ${WORKDIR}/rcS.release ${D}${sysconfdir}/init.d/rcS
}

BBCLASSEXTEND = "production rnd release"


==========================

In your production image you add

IMAGE_INSTALL_append = "busybox-production"


Do something similar for the other two.

BR

Ulf Samuelsson

________________________________
Från: yocto-bounces@yoctoproject.org <yocto-bounces@yoctoproject.org> för Damien LEFEVRE <lefevre.da@gmail.com>
Skickat: den 1 juni 2018 13:17:53
Till: Iván Castell
Kopia: Yocto discussion list
Ämne: Re: [yocto] Image specific configuration files

Thanks a lot everyone, this is very helpful =)

On Fri, Jun 1, 2018 at 2:14 PM, Iván Castell <icastell@nayarsystems.com<mailto:icastell@nayarsystems.com>> wrote:


2018-06-01 11:24 GMT+02:00 Alexander Kanavin <alex.kanavin@gmail.com<mailto:alex.kanavin@gmail.com>>:
I have to say defining multiple distros and then tweaking recipes according to those definitions is not a good practice, as recipes should generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The above iptables scenario should be handled with different image recipes, which pull in (via packages) or create different configurations.


That has sense. We will refactorize our Yocto repo as suggested. Always very helpfull with all your comments Mr Alexander. Thank you very much! :)




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

Re: Image specific configuration files

[Iván Castell]

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

Very useful information!
This is the first time I understand this bbclass and BBCLASSEXTEND
mechanism (I was unable to understand it after reading documentation again
and again).
I managed implementing a custom but working solution.
Thanks a lot for sharing Mr Ulf! :)


2018-06-01 13:44 GMT+02:00 Ulf Samuelsson <
ulf.samuelsson@external.atlascopco.com>:

> Here is the idea developed at Atlas Copco.
>
> Not my code, but I thought it useful for this problem
>
>
> define three bbclasses.
>
> production.bbclass, rnd.bbclass, release.bbclass containing:
>
> ==========================
>
> # Class for use in BBCLASSEXTEND to make it easier to have a single recipe
> that
> # build and generate packages separately for release and normal images.
> #
> # Usage:
> # BBCLASSEXTEND = "release"
>
> CLASSOVERRIDE .= ":class-release"
>
> python release_virtclass_handler () {
>     # Do nothing if this is inherited, as it's for BBCLASSEXTEND
>     if "release" not in (d.getVar('BBCLASSEXTEND') or ""):
>         bb.error("Don't inherit release, use BBCLASSEXTEND")
>         return
>
>     # Restore BPN
>     bpn = d.getVar('BPN')
>     newbpn = bpn.replace('-release', '')
>     d.setVar('BPN', newbpn)
>
>     # Use default FILESPATH searching for patches and files
>     filespath = d.getVar('FILESPATH', True)
>     newfilespath = filespath.replace('-release', '')
>     d.setVar('FILESPATH', newfilespath)
> }
>
> addhandler release_virtclass_handler
> release_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>
> ==========================
> In a bbappend you use the classes:
>
>
> ==========================
>
> SRC_URI_append_class-production = " \
>     file://rcS.production \
> "
>
> SRC_URI_append_class-rnd = " \
>     file://rcS.rnd \
> "
>
> SRC_URI_append_class-release = " \
>     file://rcS.release \
> "
>
> do_install_append_class-production () {
>     install -m 755 ${WORKDIR}/rcS.production ${D}${sysconfdir}/init.d/rcS
> }
>
> do_install_append_class-rnd () {
>     install -m 755 ${WORKDIR}/rcS.rnd ${D}${sysconfdir}/init.d/rcS
> }
>
> do_install_append_class-release () {
>     install -m 755 ${WORKDIR}/rcS.release ${D}${sysconfdir}/init.d/rcS
> }
>
> BBCLASSEXTEND = "production rnd release"
>
> ==========================
>
> In your production image you add
>
> IMAGE_INSTALL_append = "busybox-production"
>
>
> Do something similar for the other two.
>
> BR
>
> Ulf Samuelsson
> ------------------------------
> *Från:* yocto-bounces@yoctoproject.org <yocto-bounces@yoctoproject.org>
> för Damien LEFEVRE <lefevre.da@gmail.com>
> *Skickat:* den 1 juni 2018 13:17:53
> *Till:* Iván Castell
> *Kopia:* Yocto discussion list
> *Ämne:* Re: [yocto] Image specific configuration files
>
> Thanks a lot everyone, this is very helpful =)
>
> On Fri, Jun 1, 2018 at 2:14 PM, Iván Castell <icastell@nayarsystems.com>
> wrote:
>
>
>
> 2018-06-01 11:24 GMT+02:00 Alexander Kanavin <alex.kanavin@gmail.com>:
>
> I have to say defining multiple distros and then tweaking recipes
> according to those definitions is not a good practice, as recipes should
> generally only access DISTRO_FEATURES and otherwise be distro-agnostic. The
> above iptables scenario should be handled with different image recipes,
> which pull in (via packages) or create different configurations.
>
>
>
> That has sense. We will refactorize our Yocto repo as suggested. Always
> very helpfull with all your comments Mr Alexander. Thank you very much! :)
>
>
>
>
>

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

Re: Image specific configuration files

[Ulf Samuelsson]

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

You can create three separate recipes that generate three different nginx configurations and include one if them in each image recipe.


Best Regards,
Ulf Samuelsson

> 1 juni 2018 kl. 07:46 skrev Damien LEFEVRE <lefevre.da@gmail.com>:
> 
> Hi,
> 
> For the same MACHINE I create the following images:
> - myimage-production
> - myimage-rnd
> - myimage-retail
> 
> The production one has production assisted tools for flashing peripheral HW, testing vital HW components, writing some serial numbers, etc.
> 
> The rnd one has more packages than the retail one just to help rnd work and debugging in device, but none of the rnd image extra packages. 
> 
> The retail one has the final product image.
> 
> I'm using web and FTP servers. I would like for the rnd version of the image to have a different nginx configuration to set the root directory to a development folder, or set an alias.
> 
> Furthermore, I'll have different variant of the device where only the device SW changes but the platform is identical. So I'll end up with 
> - myimage2-production
> - myimage2-rnd
> - myimage2-retail
> 
> I know how to make MACHINE based configuration. How could I do this in my nginx.bbappend based on image name?
> 
> Thanks,
> -Damien
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: Image specific configuration files

[Alexander Kanavin]

2018-06-01 8:46 GMT+03:00 Damien LEFEVRE <lefevre.da@gmail.com>:
> For the same MACHINE I create the following images:
> - myimage-production
> - myimage-rnd
> - myimage-retail
>
> The production one has production assisted tools for flashing peripheral HW,
> testing vital HW components, writing some serial numbers, etc.
>
> The rnd one has more packages than the retail one just to help rnd work and
> debugging in device, but none of the rnd image extra packages.
>
> The retail one has the final product image.
>
> I'm using web and FTP servers. I would like for the rnd version of the image
> to have a different nginx configuration to set the root directory to a
> development folder, or set an alias.

Make two separate recipes for the configuration, and list one, or the
other in the image recipes.

Alternatively, do the needed tweaks via ROOTFS_POSTPROCESS_COMMANDS.

> Furthermore, I'll have different variant of the device where only the device
> SW changes but the platform is identical. So I'll end up with
> - myimage2-production
> - myimage2-rnd
> - myimage2-retail
>
> I know how to make MACHINE based configuration. How could I do this in my
> nginx.bbappend based on image name?

You can't. If you are issuing 'bitbake nginx', how would bitbake know
to what image the nginx packages would eventually go?

Alex