| Message ID | 1533817887-8771-2-git-send-email-angelo@amarulasolutions.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/2] package/mono: bump to version 5.14.0.177 | expand |
Hello, On Thu, 9 Aug 2018 14:31:27 +0200, Angelo Compagnucci wrote: > This reverts commit 0f96073561badde3c7abdf338abca7d00dba56dd cause the > newly released mono version (5.14.0.177) fixed the bug upstream. > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> I can't apply this one right now, because disabling Mono on MIPS was done on master after 2018.08-rc1 was tagged, and the next branch is based on 2018.08-rc1. I'm not sure if Peter prefers: - that we wait until 2018.08 is released to merge back next into master before applying this patch - that we cherry-pick just 0f96073561badde3c7abdf338abca7d00dba56dd from master to next and then apply your patch to next - that we merge master into next right now and apply your patch Peter ? I don't like option (1) because it leaves a patch waiting in patchwork. Thanks, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes: > Hello, > On Thu, 9 Aug 2018 14:31:27 +0200, Angelo Compagnucci wrote: >> This reverts commit 0f96073561badde3c7abdf338abca7d00dba56dd cause the >> newly released mono version (5.14.0.177) fixed the bug upstream. >> >> Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> > I can't apply this one right now, because disabling Mono on MIPS was > done on master after 2018.08-rc1 was tagged, and the next branch is > based on 2018.08-rc1. > I'm not sure if Peter prefers: > - that we wait until 2018.08 is released to merge back next into > master before applying this patch > - that we cherry-pick just > 0f96073561badde3c7abdf338abca7d00dba56dd from master to next and > then apply your patch to next > - that we merge master into next right now and apply your patch > Peter ? > I don't like option (1) because it leaves a patch waiting in patchwork. I guess option 2 should be fine and not really cause any issues when merging next into master, right?
Hello, On Thu, 09 Aug 2018 23:18:51 +0200, Peter Korsgaard wrote: > > I'm not sure if Peter prefers: > > > - that we wait until 2018.08 is released to merge back next into > > master before applying this patch > > > - that we cherry-pick just > > 0f96073561badde3c7abdf338abca7d00dba56dd from master to next and > > then apply your patch to next > > > - that we merge master into next right now and apply your patch > > > Peter ? > > > I don't like option (1) because it leaves a patch waiting in patchwork. > > I guess option 2 should be fine and not really cause any issues when > merging next into master, right? I guess during the merge, Git will notice that the commit has already been cherry-picked, and will simply skip it. Thomas
Hello, On Thu, 9 Aug 2018 14:31:27 +0200, Angelo Compagnucci wrote: > This reverts commit 0f96073561badde3c7abdf338abca7d00dba56dd cause the > newly released mono version (5.14.0.177) fixed the bug upstream. > > Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> > --- > package/mono/Config.in | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to next, thanks. Thomas
diff --git a/package/mono/Config.in b/package/mono/Config.in index a375a98..63208fe 100644 --- a/package/mono/Config.in +++ b/package/mono/Config.in @@ -5,8 +5,8 @@ config BR2_PACKAGE_HOST_MONO_ARCH_SUPPORTS config BR2_PACKAGE_MONO_ARCH_SUPPORTS bool - default y if (BR2_arm || BR2_armeb || BR2_i386 || \ - BR2_powerpc || BR2_x86_64) + default y if (BR2_arm || BR2_armeb || BR2_i386 || BR2_mips || \ + BR2_mipsel || BR2_powerpc || BR2_x86_64) depends on BR2_PACKAGE_HOST_MONO_ARCH_SUPPORTS config BR2_PACKAGE_MONO
This reverts commit 0f96073561badde3c7abdf338abca7d00dba56dd cause the newly released mono version (5.14.0.177) fixed the bug upstream. Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> --- package/mono/Config.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)