[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Angelo Compagnucci]

This patch adds an easy way to select the CIP project SLTS
kernel within the kernel menu.

Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
---
 Config.in       | 20 ++++++++++++++++++++
 linux/Config.in |  4 ++++
 linux/linux.mk  |  3 +++
 3 files changed, 27 insertions(+)

diff --git a/Config.in b/Config.in
index bd8f0d1..b089ed8 100644
--- a/Config.in
+++ b/Config.in
@@ -261,6 +261,26 @@ config BR2_KERNEL_MIRROR
 	     http://www.XX.kernel.org/pub (XX = country code)
 	     http://mirror.aarnet.edu.au/pub/ftp.kernel.org
 
+config BR2_CIP_KERNEL_REPO_URL
+	string "CIP SLTS (SuperLong Term Support) kernel url"
+	default "git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git"
+	help
+	  CIP launched in the spring of 2016 to address the needs of
+	  organizations in industries such as power generation and
+	  distribution, water, oil and gas, transportation, building
+	  automation and more for reliable and secure Linux-based
+	  embedded systems that can be sustained over a period of
+	  10 to as many as 60 years.
+	  The project's goal is to provide an open source base layer
+	  of industrial-grade software that permits the use and
+	  implementation of software building blocks that meet
+	  these requirements.
+
+	  The CIP community plans to maintain 4.4 for security and
+	  bug fixes for more than 10 years.
+
+	  https://www.cip-project.org
+
 config BR2_GNU_MIRROR
 	string "GNU Software mirror"
 	default "http://ftpmirror.gnu.org"
diff --git a/linux/Config.in b/linux/Config.in
index 890b848..478cb18 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -28,6 +28,9 @@ choice
 config BR2_LINUX_KERNEL_LATEST_VERSION
 	bool "Latest version (4.10)"
 
+config BR2_LINUX_KERNEL_LATEST_CIP_VERSION
+	bool "Latest CIP SLTS (Super Long Term Support) version (4.4.y)"
+
 config BR2_LINUX_KERNEL_CUSTOM_VERSION
 	bool "Custom version"
 	help
@@ -98,6 +101,7 @@ endif
 config BR2_LINUX_KERNEL_VERSION
 	string
 	default "4.10" if BR2_LINUX_KERNEL_LATEST_VERSION
+	default "linux-4.4.y-cip" if BR2_LINUX_KERNEL_LATEST_CIP_VERSION
 	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \
 		if BR2_LINUX_KERNEL_CUSTOM_VERSION
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
diff --git a/linux/linux.mk b/linux/linux.mk
index 7f4432e..0dd8ff0 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -30,6 +30,9 @@ LINUX_SITE_METHOD = hg
 else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_SVN),y)
 LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
 LINUX_SITE_METHOD = svn
+else ifeq ($(BR2_LINUX_KERNEL_LATEST_CIP_VERSION),y)
+LINUX_SITE = $(call qstrip,$(BR2_CIP_KERNEL_REPO_URL))
+LINUX_SITE_METHOD = git
 else
 LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz
 ifeq ($(BR2_LINUX_KERNEL_CUSTOM_VERSION),y)
-- 
2.7.4

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Thomas Petazzoni]

Hello,

On Fri,  3 Mar 2017 22:50:16 +0100, Angelo Compagnucci wrote:
> This patch adds an easy way to select the CIP project SLTS
> kernel within the kernel menu.
> 
> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>

I personally don't think we should have explicit support for kernels
other than the vanilla Linux kernel. Our kernel options already allow
to select any arbitrary tarball or Git repository, which makes it
possible to use this linux-cip Git repository as your kernel source if
you like it.

Supporting explicitly additional kernel trees is a never-ending story.
Everyone will want its own kernel tree listed in Buildroot.

And this linux-cip thing is in fact probably a lot less popular than
other non-vanilla kernel trees (like the one for RaspberryPi, for
BeagleoBone, the PREEMPT_RT tree, etc.).

So I apologize, but I'm personally not in favor of this patch.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Arnout Vandecappelle]

On 03-03-17 23:46, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri,  3 Mar 2017 22:50:16 +0100, Angelo Compagnucci wrote:
>> This patch adds an easy way to select the CIP project SLTS
>> kernel within the kernel menu.
>>
>> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
> 
> I personally don't think we should have explicit support for kernels
> other than the vanilla Linux kernel. Our kernel options already allow
> to select any arbitrary tarball or Git repository, which makes it
> possible to use this linux-cip Git repository as your kernel source if
> you like it.
> 
> Supporting explicitly additional kernel trees is a never-ending story.
> Everyone will want its own kernel tree listed in Buildroot.
> 
> And this linux-cip thing is in fact probably a lot less popular than
> other non-vanilla kernel trees (like the one for RaspberryPi, for
> BeagleoBone, the PREEMPT_RT tree, etc.).

 In addition, I have yet to meet an actual embedded system product that uses an
unpatched kernel. In practice, the CIP kernel is going to be the _base_ of a
product, and not used directly.

 That said, it would be useful to add a defconfig that makes use of that kernel.
I guess they must have some kind of flagship board to run on, no?

 Regards,
 Arnout

> 
> So I apologize, but I'm personally not in favor of this patch.
> 
> Best regards,
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Thomas Petazzoni]

Hello,

On Fri, 3 Mar 2017 23:50:54 +0100, Arnout Vandecappelle wrote:

>  In addition, I have yet to meet an actual embedded system product that uses an
> unpatched kernel. In practice, the CIP kernel is going to be the _base_ of a
> product, and not used directly.
> 
>  That said, it would be useful to add a defconfig that makes use of that kernel.

I don't really see how that would be useful. What would it bring
exactly?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Arnout Vandecappelle]

On 04-03-17 00:02, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 3 Mar 2017 23:50:54 +0100, Arnout Vandecappelle wrote:
> 
>>  In addition, I have yet to meet an actual embedded system product that uses an
>> unpatched kernel. In practice, the CIP kernel is going to be the _base_ of a
>> product, and not used directly.
>>
>>  That said, it would be useful to add a defconfig that makes use of that kernel.
> 
> I don't really see how that would be useful. What would it bring
> exactly?

 Advertising that this repository exists and show how it can be used with
Buildroot. The latter part is of course trivial for us but still useful for
newcomers I think.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Thomas Petazzoni]

Hello,

On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote:

> > I don't really see how that would be useful. What would it bring
> > exactly?  
> 
>  Advertising that this repository exists and show how it can be used with
> Buildroot. The latter part is of course trivial for us but still useful for
> newcomers I think.

But is this repository any more useful than hundreds of other vendor
kernel trees? Why would this one have a defconfig, while it's not tied
to handling a particular HW platform?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Angelo Compagnucci]

Dear Thomas Petazzoni, Arnout Vandecappelle

2017-03-04 11:11 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote:
>
>> > I don't really see how that would be useful. What would it bring
>> > exactly?
>>
>>  Advertising that this repository exists and show how it can be used with
>> Buildroot. The latter part is of course trivial for us but still useful for
>> newcomers I think.
>
> But is this repository any more useful than hundreds of other vendor
> kernel trees? Why would this one have a defconfig, while it's not tied
> to handling a particular HW platform?

Probably there's some missing informations here ...

From the CIP website:

"Development will begin shortly on SLTS kernel version 4.4. Until the
announcement of the next version of the SLTS kernel, which the CIP
community anticipates will happen in two to three years, feature
backports from the upstream Linux kernel may be merged with the CIP
kernel. The CIP community plans to maintain 4.4 for security and bug
fixes for more than 10 years."

So, it's a vanilla kernel? Yes
It's security patched? Yes
It's a join effort project from the Linux Foundation and other big
players? Yes [1]
It's tied to a special development platform or board? No, it's a
vanilla kernel after all.

So in the end I think this kernel should have a mention in buildroot.

Buildroot users are usually corporations that want to build software
for their products.
If I were a corp right now, I will base my Linux product on an SLTS
kernel, because it assures me that I don't have to rewrite all my
kernel code for at least 10 years and the testing I do isn't trashed
every time a new kernel revision is out [2].

Ironically, we could base most of our configs (the ones that use a
vanilla kernel) on CIP SLTS kernel and never think again to kernel
bumps for another 10 years!

I think that we should support this vanilla super long term support
kernel for the benefits of our users. Choosing the right kernel for a
product is a tough decision and knowing that there is a kernel I can
trust for 10 years is surely something to not underestimate.

Sincerely, Angelo


[1] https://www.linuxfoundation.org/news-media/announcements/2016/04/linux-foundation-launches-first-linux-based-civil-infrastructure
[2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Arnout Vandecappelle]

On 04-03-17 12:31, Angelo Compagnucci wrote:
> Dear Thomas Petazzoni, Arnout Vandecappelle
> 
> 2017-03-04 11:11 GMT+01:00 Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>:
>> Hello,
>>
>> On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote:
>>
>>>> I don't really see how that would be useful. What would it bring
>>>> exactly?
>>>
>>>  Advertising that this repository exists and show how it can be used with
>>> Buildroot. The latter part is of course trivial for us but still useful for
>>> newcomers I think.
>>
>> But is this repository any more useful than hundreds of other vendor
>> kernel trees? Why would this one have a defconfig, while it's not tied
>> to handling a particular HW platform?
> 
> Probably there's some missing informations here ...
> 
> From the CIP website:
> 
> "Development will begin shortly on SLTS kernel version 4.4. Until the
> announcement of the next version of the SLTS kernel, which the CIP
> community anticipates will happen in two to three years, feature
> backports from the upstream Linux kernel may be merged with the CIP
> kernel. The CIP community plans to maintain 4.4 for security and bug
> fixes for more than 10 years."
> 
> So, it's a vanilla kernel? Yes
> It's security patched? Yes
> It's a join effort project from the Linux Foundation and other big
> players? Yes [1]
> It's tied to a special development platform or board? No, it's a
> vanilla kernel after all.
> 
> So in the end I think this kernel should have a mention in buildroot.
> 
> Buildroot users are usually corporations that want to build software
> for their products.
> If I were a corp right now, I will base my Linux product on an SLTS
> kernel, because it assures me that I don't have to rewrite all my
> kernel code for at least 10 years and the testing I do isn't trashed
> every time a new kernel revision is out [2].
> 
> Ironically, we could base most of our configs (the ones that use a
> vanilla kernel) on CIP SLTS kernel and never think again to kernel
> bumps for another 10 years!

 Well, we still would have to bump the kernel of course. If the code doesn't
change, there is no point to use that repository over any other!

> 
> I think that we should support this vanilla super long term support
> kernel for the benefits of our users. Choosing the right kernel for a
> product is a tough decision and knowing that there is a kernel I can
> trust for 10 years is surely something to not underestimate.

 And this is indeed what I meant: this project is useful for our users, so it
would be nice if we advertised it somehow.

 Actually, looking back to the original patch, I'm kind of warming up to it. We
currently have a version selection for all maintained stable versions for
linux-headers, but not for linux itself - why not? Probably because it is too
much work to maintain that and most people will anyway not use an upstream
kernel directly in their product. But with the SLTS kernel there is in fact a
higher chance that you can use it directly in your product.

 Note that the original patch did have a few issues:
- It should use a tag/sha rather than a branch;
- It should use a tarball from https://gitlab.com/cip-project/cip-kernel-4.4
rather than a git clone.
- Configuration of BR2_CIP_KERNEL_REPO_URL is pointless, since anything else is
wrong.


 Regards,
 Arnout



-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Angelo Compagnucci]

Dear Arnout Vandecappelle,

2017-03-04 13:17 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 04-03-17 12:31, Angelo Compagnucci wrote:
>> Dear Thomas Petazzoni, Arnout Vandecappelle
>>
>> 2017-03-04 11:11 GMT+01:00 Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com>:
>>> Hello,
>>>
>>> On Sat, 4 Mar 2017 00:43:20 +0100, Arnout Vandecappelle wrote:
>>>
>>>>> I don't really see how that would be useful. What would it bring
>>>>> exactly?
>>>>
>>>>  Advertising that this repository exists and show how it can be used with
>>>> Buildroot. The latter part is of course trivial for us but still useful for
>>>> newcomers I think.
>>>
>>> But is this repository any more useful than hundreds of other vendor
>>> kernel trees? Why would this one have a defconfig, while it's not tied
>>> to handling a particular HW platform?
>>
>> Probably there's some missing informations here ...
>>
>> From the CIP website:
>>
>> "Development will begin shortly on SLTS kernel version 4.4. Until the
>> announcement of the next version of the SLTS kernel, which the CIP
>> community anticipates will happen in two to three years, feature
>> backports from the upstream Linux kernel may be merged with the CIP
>> kernel. The CIP community plans to maintain 4.4 for security and bug
>> fixes for more than 10 years."
>>
>> So, it's a vanilla kernel? Yes
>> It's security patched? Yes
>> It's a join effort project from the Linux Foundation and other big
>> players? Yes [1]
>> It's tied to a special development platform or board? No, it's a
>> vanilla kernel after all.
>>
>> So in the end I think this kernel should have a mention in buildroot.
>>
>> Buildroot users are usually corporations that want to build software
>> for their products.
>> If I were a corp right now, I will base my Linux product on an SLTS
>> kernel, because it assures me that I don't have to rewrite all my
>> kernel code for at least 10 years and the testing I do isn't trashed
>> every time a new kernel revision is out [2].
>>
>> Ironically, we could base most of our configs (the ones that use a
>> vanilla kernel) on CIP SLTS kernel and never think again to kernel
>> bumps for another 10 years!
>
>  Well, we still would have to bump the kernel of course. If the code doesn't
> change, there is no point to use that repository over any other!

Nope, cause we point to a branch rather than a hash or a tag.

>> I think that we should support this vanilla super long term support
>> kernel for the benefits of our users. Choosing the right kernel for a
>> product is a tough decision and knowing that there is a kernel I can
>> trust for 10 years is surely something to not underestimate.
>
>  And this is indeed what I meant: this project is useful for our users, so it
> would be nice if we advertised it somehow.
>
>  Actually, looking back to the original patch, I'm kind of warming up to it.

Iuppi!

> We
> currently have a version selection for all maintained stable versions for
> linux-headers, but not for linux itself - why not? Probably because it is too
> much work to maintain that and most people will anyway not use an upstream
> kernel directly in their product. But with the SLTS kernel there is in fact a
> higher chance that you can use it directly in your product.
>
>  Note that the original patch did have a few issues:
> - It should use a tag/sha rather than a branch;

Using a tag/sha will defeat the purpose of using this kernel. A
developer should ever use the latest release of this kernel each time
he compiles a buildroot image. It's the CIP team behind it that
guarantees that the kernel will work as intended. Btw the major
version is fixed.

> - It should use a tarball from https://gitlab.com/cip-project/cip-kernel-4.4
> rather than a git clone.

This is indeed a good idea!

> - Configuration of BR2_CIP_KERNEL_REPO_URL is pointless, since anything else is
> wrong.

And where I should store the tarball url?


Sincerely, Angelo.

>
>
>  Regards,
>  Arnout
>
>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Thomas Petazzoni]

Hello,

On Sat, 4 Mar 2017 15:08:06 +0100, Angelo Compagnucci wrote:
> >  Note that the original patch did have a few issues:
> > - It should use a tag/sha rather than a branch;  
> 
> Using a tag/sha will defeat the purpose of using this kernel. A
> developer should ever use the latest release of this kernel each time
> he compiles a buildroot image.

Clearly *NOT*. We want Buildroot builds to be reproducible. So if you
take a given Buildroot version and configuration, it should *always*
provide exactly the same output. So we need to use fixed versions of
all the components.

Doing otherwise would be absolutely horrible. You do a build one day,
it works. The next day, your colleague takes your Buildroot version and
configuration, does a build, and the build fails? Or the build works,
but it no longer boots/works on the target?

So no, we clearly do not want this to use the "latest release each time
a Buildroot image is compiled".

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Angelo Compagnucci]

Dear Thomas Petazzoni,

2017-03-04 15:12 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Sat, 4 Mar 2017 15:08:06 +0100, Angelo Compagnucci wrote:
>> >  Note that the original patch did have a few issues:
>> > - It should use a tag/sha rather than a branch;
>>
>> Using a tag/sha will defeat the purpose of using this kernel. A
>> developer should ever use the latest release of this kernel each time
>> he compiles a buildroot image.
>
> Clearly *NOT*. We want Buildroot builds to be reproducible. So if you
> take a given Buildroot version and configuration, it should *always*
> provide exactly the same output. So we need to use fixed versions of
> all the components.

Obviously, I know. We could exclude the CIP kernel from the
reproducibility thing.

> Doing otherwise would be absolutely horrible. You do a build one day,
> it works. The next day, your colleague takes your Buildroot version and
> configuration, does a build, and the build fails? Or the build works,
> but it no longer boots/works on the target?

This should not happens, or if this happens, there's fault in the CIP
project. Btw the project doesn't involves only a Linux kernel but all
the necessary infrastructure to be sure that a new minor release
doesn't brake everything.

> So no, we clearly do not want this to use the "latest release each time
> a Buildroot image is compiled".

This is plain wrong with CIP. What an CIP user wants is to have the
latest patched version without thinking. It doesn't have any sense to
say to a developer "hey, we provide CIP but our setting is useless
cause it points to an older unpatched release. If you want to use it,
you should manually change to the latest release."

Yes, it's thinking in another way, like a super long term support
rolling release.

Sincerely, Angelo

>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Thomas Petazzoni]

Hello,

On Sat, 4 Mar 2017 15:38:13 +0100, Angelo Compagnucci wrote:

> > Clearly *NOT*. We want Buildroot builds to be reproducible. So if you
> > take a given Buildroot version and configuration, it should *always*
> > provide exactly the same output. So we need to use fixed versions of
> > all the components.  
> 
> Obviously, I know. We could exclude the CIP kernel from the
> reproducibility thing.

There is nothing like "excluding feature <foo>" from the
reproducibility thing.

> This should not happens, or if this happens, there's fault in the CIP
> project. Btw the project doesn't involves only a Linux kernel but all
> the necessary infrastructure to be sure that a new minor release
> doesn't brake everything.

Right, but that's not the point. The point is that a given Buildroot
version+configuration should always build the same thing, period.
That's a very strong principle in Buildroot.

If you want to upgrade your kernel to a newer version, you change your
configuration.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH] linux: Add CIP SLTS easy selection option

[Angelo Compagnucci]

Dear Thomas Petazzoni ,

2017-03-04 15:42 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Sat, 4 Mar 2017 15:38:13 +0100, Angelo Compagnucci wrote:
>
>> > Clearly *NOT*. We want Buildroot builds to be reproducible. So if you
>> > take a given Buildroot version and configuration, it should *always*
>> > provide exactly the same output. So we need to use fixed versions of
>> > all the components.
>>
>> Obviously, I know. We could exclude the CIP kernel from the
>> reproducibility thing.
>
> There is nothing like "excluding feature <foo>" from the
> reproducibility thing.
>
>> This should not happens, or if this happens, there's fault in the CIP
>> project. Btw the project doesn't involves only a Linux kernel but all
>> the necessary infrastructure to be sure that a new minor release
>> doesn't brake everything.
>
> Right, but that's not the point. The point is that a given Buildroot
> version+configuration should always build the same thing, period.
> That's a very strong principle in Buildroot.
>
> If you want to upgrade your kernel to a newer version, you change your
> configuration.

If this is an insurmountable thing, than this patch could be
discarded. Obviously we can use a tag (there is v4.4.48-cip2 at this
moment) but what's the point? We should educate our users about
checking manually the latest release cause the one shipped with
buildroot could be older and unpatched. It's nonsense.

This problem is somewhat related to the standard kernel where we say
"Latest version (4.9.13)" (buildroot 2017.02) when indeed the latest
version at the time of writing is 4.10.1. Latest should be latest
imho.

Sincerely, Angelo.

>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo