[Buildroot] [PATCH 1/2] package/monolite: bump to version 1050001000

[Buildroot] [PATCH 1/2] package/monolite: bump to version 1050001000

[Angelo Compagnucci]

The latest version of mono carries a bit of changes in the monolite
package: the version string changes and from now on, monolite should
be installed in a subdirectory with the exact version string as a name.

Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
---
 package/monolite/monolite.hash | 2 +-
 package/monolite/monolite.mk   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/monolite/monolite.hash b/package/monolite/monolite.hash
index 09f9554..7638ce2 100644
--- a/package/monolite/monolite.hash
+++ b/package/monolite/monolite.hash
@@ -1,2 +1,2 @@
 # sha256 locally computed
-sha256 2cdf6cff1d82d76412461a4c8a3616bb2aa1e835fb55479941662dec3799c924  monolite-156-latest.tar.gz
+sha256 365dc589e6d336530ef8efaa491e932c15163f449632daef6c41bed770d9fe53  monolite-1050001000-latest.tar.gz
diff --git a/package/monolite/monolite.mk b/package/monolite/monolite.mk
index 73f2352..2cc08df 100644
--- a/package/monolite/monolite.mk
+++ b/package/monolite/monolite.mk
@@ -4,14 +4,14 @@
 #
 ################################################################################
 
-MONOLITE_VERSION = 156
+MONOLITE_VERSION = 1050001000
 MONOLITE_SITE = http://download.mono-project.com/monolite/
 MONOLITE_SOURCE = monolite-$(MONOLITE_VERSION)-latest.tar.gz
 MONOLITE_LICENSE = LGPL-2.0 or commercial
 
 define HOST_MONOLITE_INSTALL_CMDS
-	mkdir -p $(HOST_DIR)/usr/lib/monolite
-	cp $(@D)/* $(HOST_DIR)/usr/lib/monolite
+	mkdir -p $(HOST_DIR)/usr/lib/monolite/$(MONOLITE_VERSION)
+	cp -r $(@D)/* $(HOST_DIR)/usr/lib/monolite/$(MONOLITE_VERSION)
 endef
 
 $(eval $(host-generic-package))
-- 
2.7.4

[Buildroot] [PATCH 2/2] package/mono: bump to version 5.0.1.1

[Angelo Compagnucci]

This patch bumps to mono 5.0.1.1 and updates the unit tests patch
accordingly.

Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
---
 .../0006-Remove-unit-tests-from-mono-compilation.patch     | 14 +++++++-------
 package/mono/mono.hash                                     |  2 +-
 package/mono/mono.mk                                       |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/package/mono/0006-Remove-unit-tests-from-mono-compilation.patch b/package/mono/0006-Remove-unit-tests-from-mono-compilation.patch
index 6adbd81..a3e88e7 100644
--- a/package/mono/0006-Remove-unit-tests-from-mono-compilation.patch
+++ b/package/mono/0006-Remove-unit-tests-from-mono-compilation.patch
@@ -1,6 +1,6 @@
-From 357bea890354acda52aa6dfaec7fa232fa0b8208 Mon Sep 17 00:00:00 2001
+From 26e31fc54af591bdd88d6a4a79b7fa91c57f4b0c Mon Sep 17 00:00:00 2001
 From: Angelo Compagnucci <angelo.compagnucci@gmail.com>
-Date: Tue, 23 May 2017 11:19:58 +0200
+Date: Thu, 10 Aug 2017 23:30:05 +0200
 Subject: [PATCH] Remove unit-tests from mono compilation
 
 This patch fixes compiling errors with unit-tests under linux.
@@ -15,15 +15,15 @@ index 8c9c2cb..7af36ec 100644
 --- a/mono/Makefile.am
 +++ b/mono/Makefile.am
 @@ -34,7 +34,7 @@ monotouch-do-clean:
-          (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$target); \
+ 	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$target); \
      done;
  else
--SUBDIRS = $(btls_dirs) arch utils io-layer cil metadata $(sgen_dirs) mini dis tests unit-tests benchmark profiler
-+SUBDIRS = $(btls_dirs) arch utils io-layer cil metadata $(sgen_dirs) mini dis tests benchmark profiler
+-SUBDIRS = $(btls_dirs) arch utils cil metadata $(sgen_dirs) mini dis tests unit-tests benchmark profiler
++SUBDIRS = $(btls_dirs) arch utils cil metadata $(sgen_dirs) mini dis tests benchmark profiler
  endif
  endif
--DIST_SUBDIRS = btls arch utils io-layer cil metadata $(sgen_dirs) mini dis tests unit-tests benchmark profiler
-+DIST_SUBDIRS = btls arch utils io-layer cil metadata $(sgen_dirs) mini dis tests benchmark profiler
+-DIST_SUBDIRS = btls arch utils cil metadata $(sgen_dirs) mini dis tests unit-tests benchmark profiler
++DIST_SUBDIRS = btls arch utils cil metadata $(sgen_dirs) mini dis tests benchmark profiler
 -- 
 2.7.4
 
diff --git a/package/mono/mono.hash b/package/mono/mono.hash
index 89b8ed0..5d14a52 100644
--- a/package/mono/mono.hash
+++ b/package/mono/mono.hash
@@ -1,2 +1,2 @@
 # sha256 locally computed
-sha256 18cb38a670e51609c36c687ed90ad42cfedabeffd0a2dc5f7f0c46249eb8dbef  mono-4.8.1.0.tar.bz2
+sha256 48d6ae71d593cd01bf0f499de569359d45856cda325575e1bacb5fabaa7e9718  mono-5.0.1.1.tar.bz2
diff --git a/package/mono/mono.mk b/package/mono/mono.mk
index 0fafc97..e1f16b4 100644
--- a/package/mono/mono.mk
+++ b/package/mono/mono.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-MONO_VERSION = 4.8.1.0
+MONO_VERSION = 5.0.1.1
 MONO_SITE = http://download.mono-project.com/sources/mono
 MONO_SOURCE = mono-$(MONO_VERSION).tar.bz2
 MONO_LICENSE = GPL-2.0 or MIT (compiler, tools), MIT (libs) or commercial
-- 
2.7.4

[Buildroot] [PATCH 1/2] package/monolite: bump to version 1050001000

[Arnout Vandecappelle]

On 11-08-17 10:14, Angelo Compagnucci wrote:
> The latest version of mono carries a bit of changes in the monolite
> package: the version string changes and from now on, monolite should
> be installed in a subdirectory with the exact version string as a name.

 And does this work independently of the version bump of mono itself? I.e., if
we apply just this patch, will mono still build?

 If not, then the two patches should be squashed. If you don't have time we can
do that while applying.

 Regards,
 Arnout

> 
> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
> ---
>  package/monolite/monolite.hash | 2 +-
>  package/monolite/monolite.mk   | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/package/monolite/monolite.hash b/package/monolite/monolite.hash
> index 09f9554..7638ce2 100644
> --- a/package/monolite/monolite.hash
> +++ b/package/monolite/monolite.hash
> @@ -1,2 +1,2 @@
>  # sha256 locally computed
> -sha256 2cdf6cff1d82d76412461a4c8a3616bb2aa1e835fb55479941662dec3799c924  monolite-156-latest.tar.gz
> +sha256 365dc589e6d336530ef8efaa491e932c15163f449632daef6c41bed770d9fe53  monolite-1050001000-latest.tar.gz
> diff --git a/package/monolite/monolite.mk b/package/monolite/monolite.mk
> index 73f2352..2cc08df 100644
> --- a/package/monolite/monolite.mk
> +++ b/package/monolite/monolite.mk
> @@ -4,14 +4,14 @@
>  #
>  ################################################################################
>  
> -MONOLITE_VERSION = 156
> +MONOLITE_VERSION = 1050001000
>  MONOLITE_SITE = http://download.mono-project.com/monolite/
>  MONOLITE_SOURCE = monolite-$(MONOLITE_VERSION)-latest.tar.gz
>  MONOLITE_LICENSE = LGPL-2.0 or commercial
>  
>  define HOST_MONOLITE_INSTALL_CMDS
> -	mkdir -p $(HOST_DIR)/usr/lib/monolite
> -	cp $(@D)/* $(HOST_DIR)/usr/lib/monolite
> +	mkdir -p $(HOST_DIR)/usr/lib/monolite/$(MONOLITE_VERSION)
> +	cp -r $(@D)/* $(HOST_DIR)/usr/lib/monolite/$(MONOLITE_VERSION)
>  endef
>  
>  $(eval $(host-generic-package))
> 

-- 
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 2/2] package/mono: bump to version 5.0.1.1

[Arnout Vandecappelle]

On 11-08-17 10:14, Angelo Compagnucci wrote:
> This patch bumps to mono 5.0.1.1 and updates the unit tests patch
> accordingly.
> 
> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
> ---
>  .../0006-Remove-unit-tests-from-mono-compilation.patch     | 14 +++++++-------

 What is the upstream status of all the patches? Most of the other patches look
like they could be applicable for upstream, can you send them?

 Also, patch 4 says:

Patch is upstream:

   https://github.com/mono/mono/commit/40c171799b671718969ee28a02f92884d7fd181e

so why is this one not removed? Could you mention that explicitly in the commit log?


 It would also be nice to rewrite patch 6 and 8 so they are upstreamable, but I
can imagine that that's more complicated.

 Regards,
 Arnout


[snip]

-- 
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 1/2] package/monolite: bump to version 1050001000

[Angelo Compagnucci]

Dear Arnout Vandecappelle,

2017-08-11 11:56 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 11-08-17 10:14, Angelo Compagnucci wrote:
>> The latest version of mono carries a bit of changes in the monolite
>> package: the version string changes and from now on, monolite should
>> be installed in a subdirectory with the exact version string as a name.
>
>  And does this work independently of the version bump of mono itself? I.e., if
> we apply just this patch, will mono still build?

Nope. The patches are sent in a series for the purpose to be both applied.

>  If not, then the two patches should be squashed. If you don't have time we can
> do that while applying.

Sorry for the noise, but this is not how the things worked in the
past. I was suggested several times in the past to send a patch for
each modification/package.

Sincerely, Angelo.

>  Regards,
>  Arnout
>
>>
>> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
>> ---
>>  package/monolite/monolite.hash | 2 +-
>>  package/monolite/monolite.mk   | 6 +++---
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/package/monolite/monolite.hash b/package/monolite/monolite.hash
>> index 09f9554..7638ce2 100644
>> --- a/package/monolite/monolite.hash
>> +++ b/package/monolite/monolite.hash
>> @@ -1,2 +1,2 @@
>>  # sha256 locally computed
>> -sha256 2cdf6cff1d82d76412461a4c8a3616bb2aa1e835fb55479941662dec3799c924  monolite-156-latest.tar.gz
>> +sha256 365dc589e6d336530ef8efaa491e932c15163f449632daef6c41bed770d9fe53  monolite-1050001000-latest.tar.gz
>> diff --git a/package/monolite/monolite.mk b/package/monolite/monolite.mk
>> index 73f2352..2cc08df 100644
>> --- a/package/monolite/monolite.mk
>> +++ b/package/monolite/monolite.mk
>> @@ -4,14 +4,14 @@
>>  #
>>  ################################################################################
>>
>> -MONOLITE_VERSION = 156
>> +MONOLITE_VERSION = 1050001000
>>  MONOLITE_SITE = http://download.mono-project.com/monolite/
>>  MONOLITE_SOURCE = monolite-$(MONOLITE_VERSION)-latest.tar.gz
>>  MONOLITE_LICENSE = LGPL-2.0 or commercial
>>
>>  define HOST_MONOLITE_INSTALL_CMDS
>> -     mkdir -p $(HOST_DIR)/usr/lib/monolite
>> -     cp $(@D)/* $(HOST_DIR)/usr/lib/monolite
>> +     mkdir -p $(HOST_DIR)/usr/lib/monolite/$(MONOLITE_VERSION)
>> +     cp -r $(@D)/* $(HOST_DIR)/usr/lib/monolite/$(MONOLITE_VERSION)
>>  endef
>>
>>  $(eval $(host-generic-package))
>>
>
> --
> 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 2/2] package/mono: bump to version 5.0.1.1

[Angelo Compagnucci]

Dear Arnout Vandecappelle,

2017-08-11 12:00 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 11-08-17 10:14, Angelo Compagnucci wrote:
>> This patch bumps to mono 5.0.1.1 and updates the unit tests patch
>> accordingly.
>>
>> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
>> ---
>>  .../0006-Remove-unit-tests-from-mono-compilation.patch     | 14 +++++++-------
>
>  What is the upstream status of all the patches? Most of the other patches look
> like they could be applicable for upstream, can you send them?

All upstremeable patches are already be sent. Mono has a really long
release cycle and the patches, also if applied, are not released in
stable branches immediately.

>  Also, patch 4 says:
>
> Patch is upstream:
>
>    https://github.com/mono/mono/commit/40c171799b671718969ee28a02f92884d7fd181e
>
> so why is this one not removed? Could you mention that explicitly in the commit log?

Cause the patch is present from the tag mono-5.4.0.135 (future
release) the stable release is now at 5.0.1.1 .
I usually do care to remove patches upstreamed.

>  It would also be nice to rewrite patch 6 and 8 so they are upstreamable, but I
> can imagine that that's more complicated.

Patch 8 is not upstremeable cause the way buildroot handles paths.
Buildroot sets $(mono_libdir) to the full host path, instead mono here
expects something related to the / of the target.

For patch 6 I've not tried cause it's a bit of a corner case: running
mono unit-tests during compilation is not advisable cause it takes
time but also cause they expects a certain environment that buildroot
screws up. To make the unit-tests running in buildroot mono should be
patched, but I originally though it was not necessary.

>
>  Regards,
>  Arnout
>
>
> [snip]
>
> --
> 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 1/2] package/monolite: bump to version 1050001000

[Arnout Vandecappelle]

On 11-08-17 12:40, Angelo Compagnucci wrote:
> Dear Arnout Vandecappelle,
> 
> 2017-08-11 11:56 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>
>>
>> On 11-08-17 10:14, Angelo Compagnucci wrote:
>>> The latest version of mono carries a bit of changes in the monolite
>>> package: the version string changes and from now on, monolite should
>>> be installed in a subdirectory with the exact version string as a name.
>>
>>  And does this work independently of the version bump of mono itself? I.e., if
>> we apply just this patch, will mono still build?
> 
> Nope. The patches are sent in a series for the purpose to be both applied.
> 
>>  If not, then the two patches should be squashed. If you don't have time we can
>> do that while applying.
> 
> Sorry for the noise, but this is not how the things worked in the
> past. I was suggested several times in the past to send a patch for
> each modification/package.

 Yes, but only if they indeed work separately. Don't worry, I'll squash while
applying.

 Regards,
 Arnout

[snip]

-- 
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 2/2] package/mono: bump to version 5.0.1.1

[Arnout Vandecappelle]

On 11-08-17 12:57, Angelo Compagnucci wrote:
> Dear Arnout Vandecappelle,
> 
> 2017-08-11 12:00 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>
>>
>> On 11-08-17 10:14, Angelo Compagnucci wrote:
>>> This patch bumps to mono 5.0.1.1 and updates the unit tests patch
>>> accordingly.
>>>
>>> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
>>> ---
>>>  .../0006-Remove-unit-tests-from-mono-compilation.patch     | 14 +++++++-------
>>
>>  What is the upstream status of all the patches? Most of the other patches look
>> like they could be applicable for upstream, can you send them?
> 
> All upstremeable patches are already be sent. Mono has a really long
> release cycle and the patches, also if applied, are not released in
> stable branches immediately.

 OK, thanks for the info.

> 
>>  Also, patch 4 says:
>>
>> Patch is upstream:
>>
>>    https://github.com/mono/mono/commit/40c171799b671718969ee28a02f92884d7fd181e
>>
>> so why is this one not removed? Could you mention that explicitly in the commit log?
> 
> Cause the patch is present from the tag mono-5.4.0.135 (future
> release) the stable release is now at 5.0.1.1 .

 Wow, they look far into the future apparently...

> I usually do care to remove patches upstreamed.
> 
>>  It would also be nice to rewrite patch 6 and 8 so they are upstreamable, but I
>> can imagine that that's more complicated.
> 
> Patch 8 is not upstremeable cause the way buildroot handles paths.
> Buildroot sets $(mono_libdir) to the full host path, instead mono here
> expects something related to the / of the target.
> 
> For patch 6 I've not tried cause it's a bit of a corner case: running
> mono unit-tests during compilation is not advisable cause it takes
> time but also cause they expects a certain environment that buildroot
> screws up. To make the unit-tests running in buildroot mono should be
> patched, but I originally though it was not necessary.

 Understood!

 By the way, I took a look now in more detail at how we build mono, and you
really solved that complicated build system very elegantly.

 Thanks for keeping mono up to date!


 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 1/2] package/monolite: bump to version 1050001000

[Arnout Vandecappelle]

On 11-08-17 10:14, Angelo Compagnucci wrote:
> The latest version of mono carries a bit of changes in the monolite
> package: the version string changes and from now on, monolite should
> be installed in a subdirectory with the exact version string as a name.
> 
> Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>

 I've squashed both, modified the commit message a little, and applied to next,
thanks!

 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 1/2] package/monolite: bump to version 1050001000

[Angelo Compagnucci]

Dear Arnout Vandecappelle ,

2017-08-11 15:38 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 11-08-17 12:40, Angelo Compagnucci wrote:
>> Dear Arnout Vandecappelle,
>>
>> 2017-08-11 11:56 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>>
>>>
>>> On 11-08-17 10:14, Angelo Compagnucci wrote:
>>>> The latest version of mono carries a bit of changes in the monolite
>>>> package: the version string changes and from now on, monolite should
>>>> be installed in a subdirectory with the exact version string as a name.
>>>
>>>  And does this work independently of the version bump of mono itself? I.e., if
>>> we apply just this patch, will mono still build?
>>
>> Nope. The patches are sent in a series for the purpose to be both applied.
>>
>>>  If not, then the two patches should be squashed. If you don't have time we can
>>> do that while applying.
>>
>> Sorry for the noise, but this is not how the things worked in the
>> past. I was suggested several times in the past to send a patch for
>> each modification/package.
>
>  Yes, but only if they indeed work separately. Don't worry, I'll squash while
> applying.

I searched the history for the mono package just to be sure and such a
way of squashing commits for separate packages was never been done.
I'm a bit puzzled ...

Right now I'm working updating sysdig and it requires som bumps to
other packages, should I send a squashed patch?!

Thanks!

>
>  Regards,
>  Arnout
>
> [snip]
>
> --
> 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 1/2] package/monolite: bump to version 1050001000

[Thomas Petazzoni]

Hello,

On Fri, 11 Aug 2017 17:07:18 +0200, Angelo Compagnucci wrote:

> >> Sorry for the noise, but this is not how the things worked in the
> >> past. I was suggested several times in the past to send a patch for
> >> each modification/package.  
> >
> >  Yes, but only if they indeed work separately. Don't worry, I'll squash while
> > applying.  
> 
> I searched the history for the mono package just to be sure and such a
> way of squashing commits for separate packages was never been done.
> I'm a bit puzzled ...

Yes, I used to apply them separately. Theoretically, if the bumps are
really both needed for the whole thing to work, Arnout is right that
both bumps should be done in the same patch.

I simply don't apply an absolutely strict rule of "everything should be
bisectable" in Buildroot, so I'm a bit more relaxed than Arnout on
this. I'm not saying Arnout isn't right, just that it wasn't something
that I thought was important enough.

> Right now I'm working updating sysdig and it requires som bumps to
> other packages, should I send a squashed patch?!

No, because the patch series is bisectable: if we apply only PATCH 1/3,
it works. If we apply patches 1/3 and 2/3, it works. And if we apply
1/3, 2/3 and 3/3, it works.

The question is not whether patches are independent, but whether the
patch series is bisectable. I.e what happens if you apply only M
patches on the total of N patches in the series.

Best regards,

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

[Buildroot] [PATCH 1/2] package/monolite: bump to version 1050001000

[Arnout Vandecappelle]

On 11-08-17 17:07, Angelo Compagnucci wrote:
> Dear Arnout Vandecappelle ,
> 
> 2017-08-11 15:38 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>
>>
>> On 11-08-17 12:40, Angelo Compagnucci wrote:
>>> Dear Arnout Vandecappelle,
>>>
>>> 2017-08-11 11:56 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>>>>
>>>>
>>>> On 11-08-17 10:14, Angelo Compagnucci wrote:
>>>>> The latest version of mono carries a bit of changes in the monolite
>>>>> package: the version string changes and from now on, monolite should
>>>>> be installed in a subdirectory with the exact version string as a name.
>>>>
>>>>  And does this work independently of the version bump of mono itself? I.e., if
>>>> we apply just this patch, will mono still build?
>>>
>>> Nope. The patches are sent in a series for the purpose to be both applied.
>>>
>>>>  If not, then the two patches should be squashed. If you don't have time we can
>>>> do that while applying.
>>>
>>> Sorry for the noise, but this is not how the things worked in the
>>> past. I was suggested several times in the past to send a patch for
>>> each modification/package.
>>
>>  Yes, but only if they indeed work separately. Don't worry, I'll squash while
>> applying.
> 
> I searched the history for the mono package just to be sure and such a
> way of squashing commits for separate packages was never been done.
> I'm a bit puzzled ...
> 
> Right now I'm working updating sysdig and it requires som bumps to
> other packages, should I send a squashed patch?!

 Usually it should be one patch per package. But in this case, the bump of
monolite as such would break mono. I assume that normally that's not the case,
i.e. monolite 156 can still be used for building mono 4.6.2.16. So normally they
don't have to be updated together. It's only now that they have to be squashed.

 Now, it's not really *that* important. It's only important for being able to
trace back when something broke, and that's not needed very often. But since I
saw this potential issue and could easily "fix" it, I did.

 If in doubt, make separate patches. Squashing after the fact is easy, splitting
is not.

 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