[PATCH 1/4] remove chromium appends

[PATCH 1/4] remove chromium appends

[Andreas Müller]

* they were not updated for long time
* they mach neither name nor version of the recipes in meta-browser
* they cause parse-errors

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 .../chromium/chromium-wayland_48.0.2548.0.bbappend | 29 ----------------------
 .../chromium/chromium_52.0.2743.76.bbappend        | 10 --------
 2 files changed, 39 deletions(-)
 delete mode 100644 dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend
 delete mode 100644 dynamic-layers/browser-layer/recipes-browser/chromium/chromium_52.0.2743.76.bbappend

diff --git a/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend b/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend
deleted file mode 100644
index 74237536..00000000
--- a/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend
+++ /dev/null
@@ -1,29 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/chromium:"
-
-include chromium-imx.inc
-
-CHROMIUM_IMX_BRANCH = "master"
-CHROMIUM_IMX_SRCREV = "4a2d15ab899b9944bb3adb2ddd250530da5b2e1a"
-CHROMIUM_IMX_COMMON_PATCHES += "file://${PATCH_BASE_DIR}/common/0001-Enable-share-group-workaround-for-Vivante-GPUs.patch"
-CHROMIUM_ENABLE_WAYLAND = "0"
-
-DEPENDS_append_imxvpu = " imx-vpuwrap"
-
-VPU_PATCHES = "file://${PATCH_BASE_DIR}/common/0002-Add-VPU-video-decode-accelerator-to-Chromium-GPU-.patch"
-
-CHROMIUM_IMX_VPU_PATCHES_imxvpu += "${VPU_PATCHES}"
-
-CHROMIUM_IMX_WAYLAND_PATCHES += "file://${PATCH_BASE_DIR}/wayland/0001-Modify-eglwayland-versions-for-Vivante-GPUs.patch"
-
-# Don't use X if it's running through Wayland
-CHROMIUM_ENABLE_WAYLAND = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '1', \
-                      bb.utils.contains('DISTRO_FEATURES', 'x11', '0', \
-                      '0', d),d)}"
-
-SRC_URI += "\
-        ${@oe.utils.conditional('CHROMIUM_ENABLE_WAYLAND', '1', 'git://github.com/01org/ozone-wayland.git;destsuffix=${OZONE_WAYLAND_GIT_DESTSUFFIX};branch=${OZONE_WAYLAND_GIT_BRANCH};rev=${OZONE_WAYLAND_GIT_SRCREV}', '', d)} \
-        ${@oe.utils.conditional('CHROMIUM_ENABLE_WAYLAND', '1', ' file://chromium.patch', '', d)} \
-"
-
-# Remove packages as Chromium is changed to statically link against ffmpeg.
-PACKAGES_remove = "${PN}-codecs-ffmpeg ${PN}-plugin-pdf"
diff --git a/dynamic-layers/browser-layer/recipes-browser/chromium/chromium_52.0.2743.76.bbappend b/dynamic-layers/browser-layer/recipes-browser/chromium/chromium_52.0.2743.76.bbappend
deleted file mode 100644
index 0fa2e1e5..00000000
--- a/dynamic-layers/browser-layer/recipes-browser/chromium/chromium_52.0.2743.76.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-include chromium-imx.inc
-
-CHROMIUM_IMX_BRANCH = "master"
-CHROMIUM_IMX_SRCREV = "4a2d15ab899b9944bb3adb2ddd250530da5b2e1a"
-CHROMIUM_IMX_COMMON_PATCHES += "file://${PATCH_BASE_DIR}/common/0001-Enable-share-group-workaround-for-Vivante-GPUs.patch"
-
-# Remove packages as Chromium is changed to statically link against ffmpeg.
-PACKAGES_remove = "${PN}-codecs-ffmpeg ${PN}-plugin-pdf"
-- 
2.14.4

[PATCH 2/4] qtwebkit: remove 0001-Fix-to-match-the-uniform-precision-qualifiers-in-ver.patch

[Andreas Müller]

* it does not apply with meta-qt5 master
* it changes (breaks currently) qtwebkit for all boards when adding
  meta-freescale to layers

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 ...h-the-uniform-precision-qualifiers-in-ver.patch | 42 ----------------------
 .../qt5-layer/recipes-qt/qt5/qtwebkit_%.bbappend   |  4 ---
 2 files changed, 46 deletions(-)
 delete mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit/0001-Fix-to-match-the-uniform-precision-qualifiers-in-ver.patch
 delete mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit_%.bbappend

diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit/0001-Fix-to-match-the-uniform-precision-qualifiers-in-ver.patch b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit/0001-Fix-to-match-the-uniform-precision-qualifiers-in-ver.patch
deleted file mode 100644
index 80e55c7f..00000000
--- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit/0001-Fix-to-match-the-uniform-precision-qualifiers-in-ver.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From 66dab98c3f42eb70a4c6761a8694e374b8578e99 Mon Sep 17 00:00:00 2001
-From: Prabhu Sundararaj <prabhu.sundararaj@freescale.com>
-Date: Thu, 8 May 2014 09:27:04 -0700
-Subject: [PATCH] Fix to match the uniform precision qualifiers in vertex and
- fragment shaders
-
-When the vertex and fragment shaders are linked together, then they will
-share a single global uniform name space. Hence, types and precisions of
-uniforms with the same name must match across all shaders that are linked
-into a single executable.
-
-As per GLSL_ES_Specification_3.00.3.pdf
-Page 124 12.3 Numeric Precision
-The fragment language has no default precision qualifier for floating point types.
-Hence for float, floating point vector and matrix variable declarations, either
-the declaration must include a precision qualifier or the default float
-precision must have been previously declared.
-
-Upstream-Status: Submitted [https://bugs.webkit.org/show_bug.cgi?id=124653#c9]
-
-Change-Id: I4eb3363b3bca8bc3c839212ec7c966201a3e65e2
-Signed-off-by: Prabhu Sundararaj <prabhu.sundararaj@freescale.com>
----
- Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp b/Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp
-index f4b9a7e..7e991bf 100644
---- a/Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp
-+++ b/Source/WebCore/platform/graphics/texmap/TextureMapperShaderProgram.cpp
-@@ -208,7 +208,7 @@ static const char* fragmentTemplate =
-     ANTIALIASING_TEX_COORD_DIRECTIVE
-     BLUR_CONSTANTS
-     STRINGIFY(
--        precision mediump float;
-+        precision highp float;
-         uniform SamplerType s_sampler;
-         uniform sampler2D s_contentTexture;
-         uniform float u_opacity;
--- 
-1.9.1
-
diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit_%.bbappend b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit_%.bbappend
deleted file mode 100644
index 5d961e64..00000000
--- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwebkit_%.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI += "file://0001-Fix-to-match-the-uniform-precision-qualifiers-in-ver.patch"
-
-- 
2.14.4

[PATCH 3/4] qtwayland/etnaviv: remove xcomposite-glx

[Andreas Müller]

fixes
| ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition 'features.wayland-client && features.opengl && !features.opengles2 && features.xlib && libs.xcomposite && libs.glx' failed.
|
| ERROR: Feature 'xcomposite-glx' was enabled, but the pre-condition 'features.wayland-server && features.opengl && !features.opengles2 && libs.xcomposite && libs.glx' failed.

FWIW: Have similar for Raspi/VC4 in meta-raspi-light

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 dynamic-layers/qt5-layer/recipes-qt/qt5/qtwayland_%.bbappend | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtwayland_%.bbappend

diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwayland_%.bbappend b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwayland_%.bbappend
new file mode 100644
index 00000000..7f61dc50
--- /dev/null
+++ b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtwayland_%.bbappend
@@ -0,0 +1,2 @@
+# etnaviv mesa does not have glx
+PACKAGECONFIG_remove_use-mainline-bsp = "xcomposite-glx"
-- 
2.14.4

[PATCH 4/4] Fix menuconfig for our kernels

[Andreas Müller]

* See discussion at [1]
* Tested for linux-fslc

[1] http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149912.html

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 ...check-lxdiaglog.sh-Allow-specification-of.patch | 63 ++++++++++++++++++++++
 recipes-kernel/linux/linux-imx.inc                 |  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 recipes-kernel/linux/files/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch

diff --git a/recipes-kernel/linux/files/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch b/recipes-kernel/linux/files/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
new file mode 100644
index 00000000..bc806c05
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
@@ -0,0 +1,63 @@
+From e6ebc8e654bba53f28af5229a1069fc74fa58b7b Mon Sep 17 00:00:00 2001
+From: Jason Wessel <jason.wessel@windriver.com>
+Date: Thu, 25 Sep 2014 11:26:49 -0700
+Subject: [PATCH] menuconfig,check-lxdiaglog.sh: Allow specification of ncurses
+ location
+
+In some cross build environments such as the Yocto Project build
+environment it provides an ncurses library that is compiled
+differently than the host's version.  This causes display corruption
+problems when the host's curses includes are used instead of the
+includes from the provided compiler are overridden.  There is a second
+case where there is no curses libraries at all on the host system and
+menuconfig will just fail entirely.
+
+The solution is simply to allow an override variable in
+check-lxdialog.sh for environments such as the Yocto Project.  Adding
+a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
+compiling and linking against the right headers and libraries.
+
+Upstream-Status: submitted [https://lkml.org/lkml/2013/3/3/103]
+
+Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
+cc: Michal Marek <mmarek@suse.cz>
+cc: linux-kbuild@vger.kernel.org
+Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
+Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
+---
+ scripts/kconfig/lxdialog/check-lxdialog.sh | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+ mode change 100755 => 100644 scripts/kconfig/lxdialog/check-lxdialog.sh
+
+diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/kconfig/lxdialog/check-lxdialog.sh
+old mode 100755
+new mode 100644
+index 5075ebf2d3b9..ba9242101190
+--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
++++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
+@@ -4,6 +4,10 @@
+ # What library to link
+ ldflags()
+ {
++	if [ "$CROSS_CURSES_LIB" != "" ]; then
++		echo "$CROSS_CURSES_LIB"
++		exit
++	fi
+ 	pkg-config --libs ncursesw 2>/dev/null && exit
+ 	pkg-config --libs ncurses 2>/dev/null && exit
+ 	for ext in so a dll.a dylib ; do
+@@ -21,6 +25,10 @@ ldflags()
+ # Where is ncurses.h?
+ ccflags()
+ {
++	if [ x"$CROSS_CURSES_INC" != x ]; then
++		echo "$CROSS_CURSES_INC"
++		exit
++	fi
+ 	if pkg-config --cflags ncursesw 2>/dev/null; then
+ 		echo '-DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1'
+ 	elif pkg-config --cflags ncurses 2>/dev/null; then
+-- 
+2.14.3
+
+
diff --git a/recipes-kernel/linux/linux-imx.inc b/recipes-kernel/linux/linux-imx.inc
index 9a8a035f..f6d5374f 100644
--- a/recipes-kernel/linux/linux-imx.inc
+++ b/recipes-kernel/linux/linux-imx.inc
@@ -13,6 +13,7 @@ SRCBRANCH ?= ""
 
 SRC_URI = "git://source.codeaurora.org/external/imx/linux-imx;protocol=https;branch=${SRCBRANCH} \
            file://defconfig \
+           file://0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch \
 "
 
 S = "${WORKDIR}/git"
-- 
2.14.4

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Otavio Salvador]

On Tue, Aug 28, 2018 at 4:45 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
>
> * See discussion at [1]
> * Tested for linux-fslc
>
> [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149912.html
>
> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>

It is possible to include this in our Linux fork? it avoids the need
of applying it on multiple kernels as patch.

What do you think?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Andreas Müller]

On Fri, Aug 31, 2018 at 3:18 AM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> On Tue, Aug 28, 2018 at 4:45 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
>>
>> * See discussion at [1]
>> * Tested for linux-fslc
>>
>> [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149912.html
>>
>> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
>
> It is possible to include this in our Linux fork? it avoids the need
> of applying it on multiple kernels as patch.
>
> What do you think?
>
Yes - that might help for the derived kernels in
meta-freescale-3rdparty in the long term. Can you give me hints where
to send the patch for both kernels fslc/frrescale?

Andreas

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Otavio Salvador]

On Fri, Aug 31, 2018 at 3:35 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
> On Fri, Aug 31, 2018 at 3:18 AM, Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
> > On Tue, Aug 28, 2018 at 4:45 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
> >>
> >> * See discussion at [1]
> >> * Tested for linux-fslc
> >>
> >> [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149912.html
> >>
> >> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> >
> > It is possible to include this in our Linux fork? it avoids the need
> > of applying it on multiple kernels as patch.
> >
> > What do you think?
> >
> Yes - that might help for the derived kernels in
> meta-freescale-3rdparty in the long term. Can you give me hints where
> to send the patch for both kernels fslc/frrescale?

Send it as a PR to our linux-fslc fork against the desired branch.

Tom, could you ask for this patch to be applied in the internal tree?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Tom Hochstein]

> -----Original Message-----
> From: Otavio Salvador <otavio.salvador@ossystems.com.br>
> Sent: Friday, August 31, 2018 9:03 AM
> To: Andreas Müller <schnitzeltony@gmail.com>; Tom Hochstein
> <tom.hochstein@nxp.com>
> Cc: meta-freescale Mailing List <meta-freescale@yoctoproject.org>
> Subject: Re: [meta-freescale] [PATCH 4/4] Fix menuconfig for our kernels
> 
> On Fri, Aug 31, 2018 at 3:35 AM Andreas Müller <schnitzeltony@gmail.com>
> wrote:
> > On Fri, Aug 31, 2018 at 3:18 AM, Otavio Salvador
> > <otavio.salvador@ossystems.com.br> wrote:
> > > On Tue, Aug 28, 2018 at 4:45 AM Andreas Müller
> <schnitzeltony@gmail.com> wrote:
> > >>
> > >> * See discussion at [1]
> > >> * Tested for linux-fslc
> > >>
> > >> [1]
> > >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl
> > >> ists.openembedded.org%2Fpipermail%2Fopenembedded-
> core%2F2018-April%
> > >>
> 2F149912.html&amp;data=02%7C01%7Ctom.hochstein%40nxp.com%7C4bdd
> ccba
> > >>
> 9e5c4d96e35108d60f4a853f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0
> > >>
> %7C636713210074793698&amp;sdata=B1En4vl%2FrT2RbCNlTu9u%2Fr4Ajcbe
> Bfs
> > >> lDRIjMVNaVxY%3D&amp;reserved=0
> > >>
> > >> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > >
> > > It is possible to include this in our Linux fork? it avoids the need
> > > of applying it on multiple kernels as patch.
> > >
> > > What do you think?
> > >
> > Yes - that might help for the derived kernels in
> > meta-freescale-3rdparty in the long term. Can you give me hints where
> > to send the patch for both kernels fslc/frrescale?
> 
> Send it as a PR to our linux-fslc fork against the desired branch.
> 
> Tom, could you ask for this patch to be applied in the internal tree?

Will do.

Tom

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Andreas Müller]

On Fri, Aug 31, 2018 at 4:03 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> On Fri, Aug 31, 2018 at 3:35 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
>> On Fri, Aug 31, 2018 at 3:18 AM, Otavio Salvador
>> <otavio.salvador@ossystems.com.br> wrote:
>> > On Tue, Aug 28, 2018 at 4:45 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
>> >>
>> >> * See discussion at [1]
>> >> * Tested for linux-fslc
>> >>
>> >> [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149912.html
>> >>
>> >> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
>> >
>> > It is possible to include this in our Linux fork? it avoids the need
>> > of applying it on multiple kernels as patch.
>> >
>> > What do you think?
>> >
>> Yes - that might help for the derived kernels in
>> meta-freescale-3rdparty in the long term. Can you give me hints where
>> to send the patch for both kernels fslc/frrescale?
>
> Send it as a PR to our linux-fslc fork against the desired branch.
Hi Otavio,

* done for 4.17 [1]
* wanted to do same for 4.18 but there were changes meanwhile. So
patch does not apply and worst I have not time to tests. Let't
postpone 4.18 until it is in mata-freescale - maybe it works fine
then.

[1] https://github.com/Freescale/linux-fslc/pull/30

Andreas

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Otavio Salvador]

Applied. Mind to send a bump?
On Tue, Sep 4, 2018 at 10:40 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
>
> On Fri, Aug 31, 2018 at 4:03 PM, Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
> > On Fri, Aug 31, 2018 at 3:35 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
> >> On Fri, Aug 31, 2018 at 3:18 AM, Otavio Salvador
> >> <otavio.salvador@ossystems.com.br> wrote:
> >> > On Tue, Aug 28, 2018 at 4:45 AM Andreas Müller <schnitzeltony@gmail.com> wrote:
> >> >>
> >> >> * See discussion at [1]
> >> >> * Tested for linux-fslc
> >> >>
> >> >> [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149912.html
> >> >>
> >> >> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> >> >
> >> > It is possible to include this in our Linux fork? it avoids the need
> >> > of applying it on multiple kernels as patch.
> >> >
> >> > What do you think?
> >> >
> >> Yes - that might help for the derived kernels in
> >> meta-freescale-3rdparty in the long term. Can you give me hints where
> >> to send the patch for both kernels fslc/frrescale?
> >
> > Send it as a PR to our linux-fslc fork against the desired branch.
> Hi Otavio,
>
> * done for 4.17 [1]
> * wanted to do same for 4.18 but there were changes meanwhile. So
> patch does not apply and worst I have not time to tests. Let't
> postpone 4.18 until it is in mata-freescale - maybe it works fine
> then.
>
> [1] https://github.com/Freescale/linux-fslc/pull/30
>
> Andreas
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale



-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Andreas Müller]

On Tue, Sep 4, 2018 at 8:39 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> Applied. Mind to send a bump?
Don't mind :)

Tomorrow I'll test latest fslc HEAD and - in case of no new issues -
will send out further. In case of issues: We'll see...

Andreas

Re: [PATCH 4/4] Fix menuconfig for our kernels

[Otavio Salvador]

On Tue, Sep 4, 2018 at 6:02 PM Andreas Müller <schnitzeltony@gmail.com> wrote:
>
> On Tue, Sep 4, 2018 at 8:39 PM, Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
> > Applied. Mind to send a bump?
> Don't mind :)
>
> Tomorrow I'll test latest fslc HEAD and - in case of no new issues -
> will send out further. In case of issues: We'll see...

I merged the 4.17.19 stable release on top of the branch. If you can
give it a new go and possibly send a new bump, it would be awesome.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750