[cip-dev] Supported kernel and Debian versions in Isar

[cip-dev] Supported kernel and Debian versions in Isar

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Jan,

Do you have any policies about the version combinations of CIP kernel and Debian supported in Isar?

Currently, Isar seems to support 4.4 CIP + stretch/buster:
https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-started

isar-cip-core additionally supports 4.19:
https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/recipes-kernel/linux
but "linux-cip" is default to 4.4.
https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03ec994d8282de4851293687116a7f311

Do you any plans to provide the kernel recipes for all CIP versions (4.4, 4.19, ...) in master branch
and validate them with all Debian versions?
I guess that the supported combinations would be limited to practical ones.
For examples:
	4.4 + stretch => SUPPORTED
	4.4 + buster => NOT SUPPORTED
	4.4 + bullseye => NOT SUPPORTED
	4.19 + stretch => SUPPORTED
	4.19 + buster => NOT SUPPORTED
	4.19 + bullseye => SUPPORTED(?)
	...

As the background, please refer to the following discussion if you need:
https://lists.cip-project.org/pipermail/cip-dev/2019-April/002074.html

Regards,
Kazu

[cip-dev] Supported kernel and Debian versions in Isar

[kazuhiro3.hayashi at toshiba.co.jp]

> 	4.19 + buster => NOT SUPPORTED
Sorry I would like to correct the examples:

	4.4 + stretch => SUPPORTED
	4.4 + buster => NOT SUPPORTED
	4.4 + bullseye => NOT SUPPORTED
	4.19 + stretch => SUPPORTED
	4.19 + buster => SUPPORTED
	4.19 + bullseye => SUPPORTED(?)
	...

> -----Original Message-----
> From: cip-dev-bounces at lists.cip-project.org
> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of
> kazuhiro3.hayashi at toshiba.co.jp
> Sent: Thursday, April 11, 2019 5:33 PM
> To: jan.kiszka at siemens.com
> Cc: cip-dev at lists.cip-project.org
> Subject: [cip-dev] Supported kernel and Debian versions in Isar
> 
> Hello Jan,
> 
> Do you have any policies about the version combinations of CIP kernel and
> Debian supported in Isar?
> 
> Currently, Isar seems to support 4.4 CIP + stretch/buster:
> https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/li
> nux/linux-cip_4.4.166-cip29.bb
> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-
> started
> 
> isar-cip-core additionally supports 4.19:
> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
> pes-kernel/linux
> but "linux-cip" is default to 4.4.
> https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03
> ec994d8282de4851293687116a7f311
> 
> Do you any plans to provide the kernel recipes for all CIP versions (4.4,
> 4.19, ...) in master branch
> and validate them with all Debian versions?
> I guess that the supported combinations would be limited to practical ones.
> For examples:
> 	4.4 + stretch => SUPPORTED
> 	4.4 + buster => NOT SUPPORTED
> 	4.4 + bullseye => NOT SUPPORTED
> 	4.19 + stretch => SUPPORTED
> 	4.19 + buster => NOT SUPPORTED
> 	4.19 + bullseye => SUPPORTED(?)
> 	...
> 
> As the background, please refer to the following discussion if you need:
> https://lists.cip-project.org/pipermail/cip-dev/2019-April/002074.html
> 
> Regards,
> Kazu
> 
> 
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] Supported kernel and Debian versions in Isar

[Jan Kiszka]

On 11.04.19 10:33, kazuhiro3.hayashi at toshiba.co.jp wrote:
> Hello Jan,
> 
> Do you have any policies about the version combinations of CIP kernel and Debian supported in Isar?
> 
> Currently, Isar seems to support 4.4 CIP + stretch/buster:
> https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb

That's just an example for a custom kernel recipe.

> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-started
> 
> isar-cip-core additionally supports 4.19:
> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/recipes-kernel/linux
> but "linux-cip" is default to 4.4.
> https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03ec994d8282de4851293687116a7f311

Yes, that was a conservative choice we should change.

> 
> Do you any plans to provide the kernel recipes for all CIP versions (4.4, 4.19, ...) in master branch
> and validate them with all Debian versions?

All (released) versions exist already, validation is the key now. We do not have isar-cip-core hooked up with our test labs yet. I only started artifact generation, but only for the combinations 4.4-rt with BBB and IPC227E. We should add 4.19 as well, and then we need tests. I'm low on bandwidth to look into the test hook-up myself ATM, unfortunately, but I will at least try to finish the uploading (more variants, upload of rootfs as well, not only bootable image - or can the latter be used for LAVA as well?)

> I guess that the supported combinations would be limited to practical ones.
> For examples:
> 	4.4 + stretch => SUPPORTED
> 	4.4 + buster => NOT SUPPORTED
> 	4.4 + bullseye => NOT SUPPORTED
> 	4.19 + stretch => SUPPORTED
> 	4.19 + buster => NOT SUPPORTED
> 	4.19 + bullseye => SUPPORTED(?)

You meant
	4.19 + buster => SUPPORTED
	4.19 + bullseye => SUPPORTED(?)

Yes for buster, specifically when it is released. I don't think we need to rush with the next release then.

Enabling buster should be straightforward, Isar works with it already.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] Supported kernel and Debian versions in Isar

[kazuhiro3.hayashi at toshiba.co.jp]

Hi,

> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Thursday, April 11, 2019 6:02 PM
> To: hayashi kazuhiro(? ?? ????????)
> <kazuhiro3.hayashi@toshiba.co.jp>
> Cc: cip-dev at lists.cip-project.org
> Subject: Re: Supported kernel and Debian versions in Isar
> 
> On 11.04.19 10:33, kazuhiro3.hayashi at toshiba.co.jp wrote:
> > Hello Jan,
> >
> > Do you have any policies about the version combinations of CIP kernel
> and Debian supported in Isar?
> >
> > Currently, Isar seems to support 4.4 CIP + stretch/buster:
> >
> https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/li
> nux/linux-cip_4.4.166-cip29.bb
> 
> That's just an example for a custom kernel recipe.
> 
> >
> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-
> started
> >
> > isar-cip-core additionally supports 4.19:
> >
> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
> pes-kernel/linux
> > but "linux-cip" is default to 4.4.
> >
> https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03
> ec994d8282de4851293687116a7f311
> 
> Yes, that was a conservative choice we should change.

OK.
I would like to confirm the meaning of "change" (override or add) in the following questions.

> 
> >
> > Do you any plans to provide the kernel recipes for all CIP versions (4.4,
> 4.19, ...) in master branch
> > and validate them with all Debian versions?
> 
> All (released) versions exist already, validation is the key now. We do
> not have isar-cip-core hooked up with our test labs yet. I only started
> artifact generation, but only for the combinations 4.4-rt with BBB and
> IPC227E. We should add 4.19 as well, and then we need tests. I'm low on
> bandwidth to look into the test hook-up myself ATM, unfortunately, but I
> will at least try to finish the uploading (more variants, upload of rootfs
> as well, not only bootable image - or can the latter be used for LAVA as
> well?)

Thank you for the information.
The current Debian version used in the above testing is stretch?
After the buster released, are you planning to validate all of the followings with isar-cip-core?

4.4-rt + stretch + BBB/ IPC227E
4.19-rt + stretch + BBB/ IPC227E
4.4-rt + buster + BBB/ IPC227E
4.19-rt + buster + BBB/ IPC227E

> 
> > I guess that the supported combinations would be limited to practical
> ones.
> > For examples:
> > 	4.4 + stretch => SUPPORTED
> > 	4.4 + buster => NOT SUPPORTED
> > 	4.4 + bullseye => NOT SUPPORTED
> > 	4.19 + stretch => SUPPORTED
> > 	4.19 + buster => NOT SUPPORTED
> > 	4.19 + bullseye => SUPPORTED(?)
> 
> You meant
> 	4.19 + buster => SUPPORTED
> 	4.19 + bullseye => SUPPORTED(?)
> 
> Yes for buster, specifically when it is released. I don't think we need
> to rush with the next release then.

OK.
What do you think about the targets of validation in future?

In Isar, we can choose any Debian versions available in
https://github.com/ilbers/isar/tree/master/meta/conf/distro (now stretch & buster)
In isar-cip-core, we can choose any kernel versions available in
https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/recipes-kernel/linux
but now isar-cip-core only provides one version combination specified by 
https://gitlab.com/cip-project/cip-core/isar-cip-core/blob/master/conf/distro/cip-core.conf
When the new CIP kernel version or Debian version released,
will isar-cip-core overriede "distro/cip-core.conf" for the specific version combination and validate?
e.g. 4.4 + stretch => 4.19 + buster => 5.xx + bullseye => ...
or, will add new files like "cip-core_2.conf", "cip-core_3.conf", ... to provide multiple version combinations?
e.g.
	cip-core.conf: 4.4 + stretch
	cip-core_2.conf: 4.19 + buster
	cip-core_3.conf: 5.xx + bullseye
	...

> 
> Enabling buster should be straightforward, Isar works with it already.

Great, how can I know that the buster is officially enabled in isar-cip-core?

Kazu

> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

[cip-dev] Supported kernel and Debian versions in Isar

[Jan Kiszka]

On 11.04.19 13:39, kazuhiro3.hayashi at toshiba.co.jp wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
>> Sent: Thursday, April 11, 2019 6:02 PM
>> To: hayashi kazuhiro(? ?? ????????)
>> <kazuhiro3.hayashi@toshiba.co.jp>
>> Cc: cip-dev at lists.cip-project.org
>> Subject: Re: Supported kernel and Debian versions in Isar
>>
>> On 11.04.19 10:33, kazuhiro3.hayashi at toshiba.co.jp wrote:
>>> Hello Jan,
>>>
>>> Do you have any policies about the version combinations of CIP kernel
>> and Debian supported in Isar?
>>>
>>> Currently, Isar seems to support 4.4 CIP + stretch/buster:
>>>
>> https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/li
>> nux/linux-cip_4.4.166-cip29.bb
>>
>> That's just an example for a custom kernel recipe.
>>
>>>
>> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-
>> started
>>>
>>> isar-cip-core additionally supports 4.19:
>>>
>> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
>> pes-kernel/linux
>>> but "linux-cip" is default to 4.4.
>>>
>> https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03
>> ec994d8282de4851293687116a7f311
>>
>> Yes, that was a conservative choice we should change.
> 
> OK.
> I would like to confirm the meaning of "change" (override or add) in the following questions.
> 

I mean: Set the default to 4.19, leave an option (e.g. a kas config fragment) to switch back to 4.4.

>>
>>>
>>> Do you any plans to provide the kernel recipes for all CIP versions (4.4,
>> 4.19, ...) in master branch
>>> and validate them with all Debian versions?
>>
>> All (released) versions exist already, validation is the key now. We do
>> not have isar-cip-core hooked up with our test labs yet. I only started
>> artifact generation, but only for the combinations 4.4-rt with BBB and
>> IPC227E. We should add 4.19 as well, and then we need tests. I'm low on
>> bandwidth to look into the test hook-up myself ATM, unfortunately, but I
>> will at least try to finish the uploading (more variants, upload of rootfs
>> as well, not only bootable image - or can the latter be used for LAVA as
>> well?)
> 
> Thank you for the information.
> The current Debian version used in the above testing is stretch?
> After the buster released, are you planning to validate all of the followings with isar-cip-core?
> 
> 4.4-rt + stretch + BBB/ IPC227E
> 4.19-rt + stretch + BBB/ IPC227E
> 4.4-rt + buster + BBB/ IPC227E
> 4.19-rt + buster + BBB/ IPC227E

That would be the plan. Of course, the more variables we add, the more we need to think about designing our test matrix, rather than just fully populating it.

> 
>>
>>> I guess that the supported combinations would be limited to practical
>> ones.
>>> For examples:
>>> 	4.4 + stretch => SUPPORTED
>>> 	4.4 + buster => NOT SUPPORTED
>>> 	4.4 + bullseye => NOT SUPPORTED
>>> 	4.19 + stretch => SUPPORTED
>>> 	4.19 + buster => NOT SUPPORTED
>>> 	4.19 + bullseye => SUPPORTED(?)
>>
>> You meant
>> 	4.19 + buster => SUPPORTED
>> 	4.19 + bullseye => SUPPORTED(?)
>>
>> Yes for buster, specifically when it is released. I don't think we need
>> to rush with the next release then.
> 
> OK.
> What do you think about the targets of validation in future?
> 
> In Isar, we can choose any Debian versions available in
> https://github.com/ilbers/isar/tree/master/meta/conf/distro (now stretch & buster)
> In isar-cip-core, we can choose any kernel versions available in
> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/recipes-kernel/linux
> but now isar-cip-core only provides one version combination specified by
> https://gitlab.com/cip-project/cip-core/isar-cip-core/blob/master/conf/distro/cip-core.conf
> When the new CIP kernel version or Debian version released,
> will isar-cip-core overriede "distro/cip-core.conf" for the specific version combination and validate?
> e.g. 4.4 + stretch => 4.19 + buster => 5.xx + bullseye => ...
> or, will add new files like "cip-core_2.conf", "cip-core_3.conf", ... to provide multiple version combinations?
> e.g.
> 	cip-core.conf: 4.4 + stretch
> 	cip-core_2.conf: 4.19 + buster
> 	cip-core_3.conf: 5.xx + bullseye
> 	...
> 

As I said above, we will soon hit a point we will have to reduce our test matrix again and rely on some version being indirectly tested via a similar combination. E.g. if you test all generic features of a kernel version against a specific Debian version on a specific board, the chances are fairly high that those will also work on other boards. So the need to test all Debian versions on all boards is rather low.

>>
>> Enabling buster should be straightforward, Isar works with it already.
> 
> Great, how can I know that the buster is officially enabled in isar-cip-core?

When someone writes the patch(es) :). It's kas magic, I don't think we need more.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] Supported kernel and Debian versions in Isar

[kazuhiro3.hayashi at toshiba.co.jp]

> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Thursday, April 11, 2019 9:15 PM
> To: hayashi kazuhiro(? ?? ????????)
> <kazuhiro3.hayashi@toshiba.co.jp>
> Cc: cip-dev at lists.cip-project.org
> Subject: Re: Supported kernel and Debian versions in Isar
> 
> On 11.04.19 13:39, kazuhiro3.hayashi at toshiba.co.jp wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> >> Sent: Thursday, April 11, 2019 6:02 PM
> >> To: hayashi kazuhiro(? ?? ????????)
> >> <kazuhiro3.hayashi@toshiba.co.jp>
> >> Cc: cip-dev at lists.cip-project.org
> >> Subject: Re: Supported kernel and Debian versions in Isar
> >>
> >> On 11.04.19 10:33, kazuhiro3.hayashi at toshiba.co.jp wrote:
> >>> Hello Jan,
> >>>
> >>> Do you have any policies about the version combinations of CIP kernel
> >> and Debian supported in Isar?
> >>>
> >>> Currently, Isar seems to support 4.4 CIP + stretch/buster:
> >>>
> >>
> https://github.com/ilbers/isar/blob/master/meta-isar/recipes-kernel/li
> >> nux/linux-cip_4.4.166-cip29.bb
> >>
> >> That's just an example for a custom kernel recipe.
> >>
> >>>
> >>
> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#getting-
> >> started
> >>>
> >>> isar-cip-core additionally supports 4.19:
> >>>
> >>
> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
> >> pes-kernel/linux
> >>> but "linux-cip" is default to 4.4.
> >>>
> >>
> https://gitlab.com/cip-project/cip-core/isar-cip-core/commit/02fdfbd03
> >> ec994d8282de4851293687116a7f311
> >>
> >> Yes, that was a conservative choice we should change.
> >
> > OK.
> > I would like to confirm the meaning of "change" (override or add) in the
> following questions.
> >
> 
> I mean: Set the default to 4.19, leave an option (e.g. a kas config fragment)
> to switch back to 4.4.
> 
> >>
> >>>
> >>> Do you any plans to provide the kernel recipes for all CIP versions
> (4.4,
> >> 4.19, ...) in master branch
> >>> and validate them with all Debian versions?
> >>
> >> All (released) versions exist already, validation is the key now. We
> do
> >> not have isar-cip-core hooked up with our test labs yet. I only started
> >> artifact generation, but only for the combinations 4.4-rt with BBB and
> >> IPC227E. We should add 4.19 as well, and then we need tests. I'm low
> on
> >> bandwidth to look into the test hook-up myself ATM, unfortunately, but
> I
> >> will at least try to finish the uploading (more variants, upload of rootfs
> >> as well, not only bootable image - or can the latter be used for LAVA
> as
> >> well?)
> >
> > Thank you for the information.
> > The current Debian version used in the above testing is stretch?
> > After the buster released, are you planning to validate all of the
> followings with isar-cip-core?
> >
> > 4.4-rt + stretch + BBB/ IPC227E
> > 4.19-rt + stretch + BBB/ IPC227E
> > 4.4-rt + buster + BBB/ IPC227E
> > 4.19-rt + buster + BBB/ IPC227E
> 
> That would be the plan. Of course, the more variables we add, the more we
> need to think about designing our test matrix, rather than just fully
> populating it.

I also want to consider the test matrix (for the both generic and tiny profiles) and
share the current state with CIP developers so that we can easily understand
which combinations are now tested and which ones we can contribute.
I would like to summarize such information later.

> 
> >
> >>
> >>> I guess that the supported combinations would be limited to practical
> >> ones.
> >>> For examples:
> >>> 	4.4 + stretch => SUPPORTED
> >>> 	4.4 + buster => NOT SUPPORTED
> >>> 	4.4 + bullseye => NOT SUPPORTED
> >>> 	4.19 + stretch => SUPPORTED
> >>> 	4.19 + buster => NOT SUPPORTED
> >>> 	4.19 + bullseye => SUPPORTED(?)
> >>
> >> You meant
> >> 	4.19 + buster => SUPPORTED
> >> 	4.19 + bullseye => SUPPORTED(?)
> >>
> >> Yes for buster, specifically when it is released. I don't think we need
> >> to rush with the next release then.
> >
> > OK.
> > What do you think about the targets of validation in future?
> >
> > In Isar, we can choose any Debian versions available in
> > https://github.com/ilbers/isar/tree/master/meta/conf/distro (now
> stretch & buster)
> > In isar-cip-core, we can choose any kernel versions available in
> >
> https://gitlab.com/cip-project/cip-core/isar-cip-core/tree/master/reci
> pes-kernel/linux
> > but now isar-cip-core only provides one version combination specified
> by
> >
> https://gitlab.com/cip-project/cip-core/isar-cip-core/blob/master/conf
> /distro/cip-core.conf
> > When the new CIP kernel version or Debian version released,
> > will isar-cip-core overriede "distro/cip-core.conf" for the specific
> version combination and validate?
> > e.g. 4.4 + stretch => 4.19 + buster => 5.xx + bullseye => ...
> > or, will add new files like "cip-core_2.conf", "cip-core_3.conf", ...
> to provide multiple version combinations?
> > e.g.
> > 	cip-core.conf: 4.4 + stretch
> > 	cip-core_2.conf: 4.19 + buster
> > 	cip-core_3.conf: 5.xx + bullseye
> > 	...
> >
> 
> As I said above, we will soon hit a point we will have to reduce our test
> matrix again and rely on some version being indirectly tested via a similar
> combination. E.g. if you test all generic features of a kernel version
> against a specific Debian version on a specific board, the chances are fairly
> high that those will also work on other boards. So the need to test all
> Debian versions on all boards is rather low.

Agreed.
It would be nice if the verified version combinations + target board
and what kind of test cases are used for these verifications.
For example, if I've tested LTP with 4.19+buster+BBB,
people who see the test matrix might be able to know at least
the basic APIs of 4.19+buster has been verified for other boards.

> 
> >>
> >> Enabling buster should be straightforward, Isar works with it already.
> >
> > Great, how can I know that the buster is officially enabled in
> isar-cip-core?
> 
> When someone writes the patch(es) :). It's kas magic, I don't think we need
> more.

I'm interested in what kind of variables is appropriate to provide the "options" with kas.
The most simple way I can guess is that:

* Provide another distro conf (e.g. cip-core_4.19_buster.conf) with the followings
	require conf/distro/debian-buster.conf
	...
	PREFERRED_VERSION_linux-cip ?= "4.19.%"
	PREFERRED_VERSION_linux-cip-rt ?= "4.19.%"
	...
* Change the default "distro" in kas.yml
	-distro: cip-core
	+distro: cip-core_4.19_buster
* The current combination (4.4 + stretch) still available by setting
	KAS_DISTRO="cip-core" (or should be renamed to "cip-core_4.4_stretch" ?)

If no objections or other ideas, I would like to create a simple patch to do that.

In addition, I'm also interested in the appropriate name for "distro"
because I'm just considering the branch name for the tiny profile (deby).
My first idea is the above. After it's decided,,
we can share the common names for specifying the version combinations between the both profiles.

Kazu

> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

[cip-dev] Supported kernel and Debian versions in Isar

[Jan Kiszka]

On 12.04.19 08:05, kazuhiro3.hayashi at toshiba.co.jp wrote:
>>>> Enabling buster should be straightforward, Isar works with it already.
>>>
>>> Great, how can I know that the buster is officially enabled in
>> isar-cip-core?
>>
>> When someone writes the patch(es) :). It's kas magic, I don't think we need
>> more.
> 
> I'm interested in what kind of variables is appropriate to provide the "options" with kas.
> The most simple way I can guess is that:
> 
> * Provide another distro conf (e.g. cip-core_4.19_buster.conf) with the followings
> 	require conf/distro/debian-buster.conf
> 	...
> 	PREFERRED_VERSION_linux-cip ?= "4.19.%"
> 	PREFERRED_VERSION_linux-cip-rt ?= "4.19.%"
> 	...
> * Change the default "distro" in kas.yml
> 	-distro: cip-core
> 	+distro: cip-core_4.19_buster
> * The current combination (4.4 + stretch) still available by setting
> 	KAS_DISTRO="cip-core" (or should be renamed to "cip-core_4.4_stretch" ?)
> 
> If no objections or other ideas, I would like to create a simple patch to do that.

I would do the following:

- define distro/cip-core_stretch.conf and distro/cip-core_buster.conf
- maybe redefine distro/cip-core.conf as link to stretch today that is going to move to
  buster once that was released and validated (similar to the default kernel story)
- define PREFERRED_VERSION_linux-cip to 4.19, maybe in a cip-core-common.conf
- allow override via kas fragments:
   - distro: cip-core_buster
   - PREFERRED_VERSION_linux-cip[-rt] = "4.4.%"

> 
> In addition, I'm also interested in the appropriate name for "distro"
> because I'm just considering the branch name for the tiny profile (deby).
> My first idea is the above. After it's decided,,
> we can share the common names for specifying the version combinations between the both profiles.

I think appending the distro version name to the "cip-core" like above is a reasonable approach.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] Supported kernel and Debian versions in Isar

[kazuhiro3.hayashi at toshiba.co.jp]

Hi Jan,

> > I'm interested in what kind of variables is appropriate to provide the "options" with kas.
> > The most simple way I can guess is that:
> >
> > * Provide another distro conf (e.g. cip-core_4.19_buster.conf) with the followings
> > 	require conf/distro/debian-buster.conf
> > 	...
> > 	PREFERRED_VERSION_linux-cip ?= "4.19.%"
> > 	PREFERRED_VERSION_linux-cip-rt ?= "4.19.%"
> > 	...
> > * Change the default "distro" in kas.yml
> > 	-distro: cip-core
> > 	+distro: cip-core_4.19_buster
> > * The current combination (4.4 + stretch) still available by setting
> > 	KAS_DISTRO="cip-core" (or should be renamed to "cip-core_4.4_stretch" ?)
> >
> > If no objections or other ideas, I would like to create a simple patch to do that.
> 
> I would do the following:
> 
> - define distro/cip-core_stretch.conf and distro/cip-core_buster.conf
> - maybe redefine distro/cip-core.conf as link to stretch today that is going to move to
>   buster once that was released and validated (similar to the default kernel story)
> - define PREFERRED_VERSION_linux-cip to 4.19, maybe in a cip-core-common.conf
> - allow override via kas fragments:
>    - distro: cip-core_buster
>    - PREFERRED_VERSION_linux-cip[-rt] = "4.4.%"

Thank you for your opinion.
I've already created a patch following your proposal and
tried the following three patterns with Isar.
Everything works fine with qemux86-64.

(1) 4.19 + stretch (default)

    $ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml
    $ ./start-qemu.sh x86
    ...
    (login as root)
    # poweroff

(2) 4.19 + buster

    $ cat <<EOF > buster.yml
    header:
      version: 8
    distro: cip-core_buster
    EOF
    $ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:buster.yml
    <***>
    $ ./start-qemu.sh x86
    ...
    (login as root)
    # poweroff

NOTE: The following replace is required at <***>:
-IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/cip-core-image-cip-core-qemu-${DISTRO_ARCH}"
+IMAGE_PREFIX="$(dirname $0)/build/tmp/deploy/images/qemu-${DISTRO_ARCH}/cip-core-image-cip-core_buster-qemu-${DISTRO_ARCH}"

(3) 4.4 + stretch

    $ cat <<EOF > cip-4.4.yml
    header:
      version: 8
    local_conf_header:
      standard: |
        PREFERRED_VERSION_linux-cip = "4.4.%"
        PREFERRED_VERSION_linux-cip-rt = "4.4.%"
    EOF
    $ ./kas-docker --isar build kas.yml:board-qemu-amd64.yml:cip-4.4.yml
    $ ./start-qemu.sh x86
    ...
    (login as root)
    # poweroff

Currently, there is no variable that includes the distro name in start-qemu.sh.
I'm not sure which is better approach:

1. Always use the same image name independent from the Debian version:
   cip-core-image-cip-core-qemu-${DISTRO_ARCH}
2. Add a variable to control Debian version like:
   [ -z "${DISTRO_CODENAME}" ] || DISTR_NAME = "cip-core_${DISTRO_CODENAME}"
   (and use cip-core-image-${DISRO_NAME}-qemu-${DISTRO_ARCH}

I can create the final patch if start-qemu.sh is fixed.

> 
> >
> > In addition, I'm also interested in the appropriate name for "distro"
> > because I'm just considering the branch name for the tiny profile (deby).
> > My first idea is the above. After it's decided,,
> > we can share the common names for specifying the version combinations between the both profiles.
> 
> I think appending the distro version name to the "cip-core" like above is a reasonable approach.

OK, I would like to use the common naming in the tiny profile as well.

Kazu

> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

[cip-dev] Supported kernel and Debian versions in Isar

[Ben Hutchings]

On Thu, 2019-04-11 at 08:33 +0000, kazuhiro3.hayashi at toshiba.co.jp wrote:
[...]
> Do you any plans to provide the kernel recipes for all CIP versions (4.4, 4.19, ...) in master branch
> and validate them with all Debian versions?
> I guess that the supported combinations would be limited to practical ones.
> For examples:
> 	4.4 + stretch => SUPPORTED
> 	4.4 + buster => NOT SUPPORTED
> 	4.4 + bullseye => NOT SUPPORTED

That makes sense to me.

> 	4.19 + stretch => SUPPORTED
> 	4.19 + buster => NOT SUPPORTED

That should be supported as Debian's official kernel packages for
buster are based on 4.19.

> 	4.19 + bullseye => SUPPORTED(?)
[...]

That should be supportable - Debian generally tries to support partial
upgrades including upgrading all of userland without the kernel, so
bullseye userland should be compatible with 4.19.

Ben.

-- 
Ben Hutchings, Software Developer                ?        Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

[cip-dev] Supported kernel and Debian versions in Isar

[kazuhiro3.hayashi at toshiba.co.jp]

Hi Ben,

> -----Original Message-----
> From: Ben Hutchings [mailto:ben.hutchings at codethink.co.uk]
> Sent: Friday, April 12, 2019 8:40 PM
> To: hayashi kazuhiro(? ?? ????????) <kazuhiro3.hayashi@toshiba.co.jp>; jan.kiszka at siemens.com
> Cc: cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] Supported kernel and Debian versions in Isar
> 
> On Thu, 2019-04-11 at 08:33 +0000, kazuhiro3.hayashi at toshiba.co.jp wrote:
> [...]
> > Do you any plans to provide the kernel recipes for all CIP versions (4.4, 4.19, ...) in master branch
> > and validate them with all Debian versions?
> > I guess that the supported combinations would be limited to practical ones.
> > For examples:
> > 	4.4 + stretch => SUPPORTED
> > 	4.4 + buster => NOT SUPPORTED
> > 	4.4 + bullseye => NOT SUPPORTED
> 
> That makes sense to me.

Thank you for your opinion, I got it.

> 
> > 	4.19 + stretch => SUPPORTED
> > 	4.19 + buster => NOT SUPPORTED
> 
> That should be supported as Debian's official kernel packages for
> buster are based on 4.19.

Sorry, the above line (4.19 + buster => NOT SUPPORTED) is just my mistake
and It was originally intended: 4.19 + buster => SUPPORTED
https://lists.cip-project.org/pipermail/cip-dev/2019-April/002076.html

> 
> > 	4.19 + bullseye => SUPPORTED(?)
> [...]
> 
> That should be supportable - Debian generally tries to support partial
> upgrades including upgrading all of userland without the kernel, so
> bullseye userland should be compatible with 4.19.

Thank you for the information.
It would be better to consider providing this 'option' (4.19 + bullseye etc.) in CIP core as well
as long as the kernel version is supported in the previous Debian version.
(4.4 is not supported in Debian, so 4.4 + buster might not be supported)

I would like to summarize the list again:

	4.4 + stretch => SUPPORTED (necessary)
	4.4 + buster => NOT SUPPORTED
	4.4 + bullseye => NOT SUPPORTED
	4.19 + stretch => SUPPORTED (optional)
	4.19 + buster => SUPPORTED (necessary)
	4.19 + bullseye => SUPPORTED (optional: 4.19 should be compatible with bullseye userland)
	...

Kazu

> 
> Ben.
> 
> --
> Ben Hutchings, Software Developer                ?        Codethink Ltd
> https://www.codethink.co.uk/                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United Kingdom