Re: [yocto] [meta-freescale] ERROR: Nothing PROVIDES 'virtual/libgles2'
On Fri, Jan 18, 2019 at 6:46 AM srinivasan wrote: > > Dear Yocto Experts, > > I am seeing the below error when i am trying to integrate freescale > layers into my custom os? Which imx8 MACHINE are you trying? Daiane > > srinishanmugam@ni-bln-07594:~/customBuild_test_rpi/customos/build_customosdistro_imx8$ > bitbake -f -c clean custom-image-debug-imx8 > WARNING: Host distribution "ubuntu-18.04" has not been validated with > this version of the build system; you may possibly experience > unexpected failures. It is recommended that you use a tested > distribution. > WARNING: > /home/srinishanmugam/customBuild_test_rpi/customos/sources/poky/meta/recipes-graphics/drm/libdrm_2.4.91.bb: > Unable to get checksum for libdrm SRC_URI entry drm-update-arm.patch: > file could not be found > | ETA: 0:00:05 > Parsing recipes: 100% > |#| > Time: 0:00:09 > Parsing of 2275 .bb files complete (0 cached, 2275 parsed). 3177 > targets, 382 skipped, 1 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > ERROR: Nothing PROVIDES 'virtual/libgles2' (but > /home/srinishanmugam/customBuild_test_rpi/customos/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb, > /home/srinishanmugam/customBuild_test_rpi/customos/sources/poky/meta/recipes-graphics/cairo/cairo_1.14.12.bb > DEPENDS on or otherwise requires it) > imx-gpu-viv PROVIDES virtual/libgles2 but was skipped: incompatible > with machine imx8mmevk (not in COMPATIBLE_MACHINE) > NOTE: Runtime target 'qtbase' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['qtbase', 'virtual/libgles2'] > ERROR: Required build target 'custom-image-debug-imx8' has no > buildable providers. > Missing or unbuildable dependency chain was: > ['custom-image-debug-imx8', 'qtbase', 'virtual/libgles2'] > > Summary: There were 2 WARNING messages shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > > Could you anyone please provide me some inputs for resolving the above issue? > > Many Thanks in advance > -- > ___ > meta-freescale mailing list > meta-freesc...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: > So if KNOWN_TASKS is defined in a configuration file in oe-core, it > would be OK? > It needs to be extended to check for KNOWN_TASKS == None of course. No, this is too fragile. We then have to maintain two different lists of tasks. If we did that we may as well just remove the generic tasks mechanism and hardcode the tasks list in the metadata. As I mentioned, we need to come up with something which detects the task loops generically. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] apparmor: fix Python install paths when target libdir != native libdir
Signed-off-by: Ross Burton
---
recipes-security/AppArmor/apparmor_2.12.bb | 4 ++--
recipes-security/AppArmor/files/py-libdir.patch | 13 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/recipes-security/AppArmor/apparmor_2.12.bb
b/recipes-security/AppArmor/apparmor_2.12.bb
index 1e3a223..073b62d 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -80,9 +80,9 @@ do_install () {
install -d ${D}/${INIT_D_DIR}
install -d ${D}/lib/apparmor
- oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}" install
+ oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}"
PYLIBDIR=${PYTHON_SITEPACKAGES_DIR} install
oe_runmake -C ${B}/binutils DESTDIR="${D}" install
- oe_runmake -C ${B}/utils DESTDIR="${D}" PYLIBDIR=${libdir} install
+ oe_runmake -C ${B}/utils DESTDIR="${D}"
PYLIBDIR=${PYTHON_SITEPACKAGES_DIR} install
oe_runmake -C ${B}/parser DESTDIR="${D}" install
oe_runmake -C ${B}/profiles DESTDIR="${D}" install
diff --git a/recipes-security/AppArmor/files/py-libdir.patch
b/recipes-security/AppArmor/files/py-libdir.patch
index fc617fb..2b88e54 100644
--- a/recipes-security/AppArmor/files/py-libdir.patch
+++ b/recipes-security/AppArmor/files/py-libdir.patch
@@ -4,6 +4,19 @@ python3-native's idea of $libdir may not match the target's
$libdir.
Upstream-Status: Pending
Signed-off-by: Ross Burton
+diff --git a/libraries/libapparmor/swig/python/Makefile.am
b/libraries/libapparmor/swig/python/Makefile.am
+index 421acba9..d2b842a6 100644
+--- a/libraries/libapparmor/swig/python/Makefile.am
b/libraries/libapparmor/swig/python/Makefile.am
+@@ -14,7 +14,7 @@ all-local: libapparmor_wrap.c setup.py
+ $(PYTHON) setup.py build
+
+ install-exec-local:
+- $(PYTHON) setup.py install --root="/$(DESTDIR)" --prefix="$(prefix)"
++ $(PYTHON) setup.py install --root="/$(DESTDIR)" --prefix="$(prefix)"
--install-lib="$(PYLIBDIR)"
+
+ clean-local:
+ if test -x "$(PYTHON)"; then $(PYTHON) setup.py clean; fi
diff --git a/utils/Makefile b/utils/Makefile
index 68f8c376..025f9da5 100644
--- a/utils/Makefile
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH v2] apparmor: fix Python install paths when target libdir != native libdir
setuptools will install into what python3-native thinks $libdir is, which may
not match the target $libdir. Pass in libdir as appropriate to force the
correct paths.
Signed-off-by: Ross Burton
---
recipes-security/AppArmor/apparmor_2.12.bb | 5 ++--
recipes-security/AppArmor/files/py-libdir.patch | 40 +
2 files changed, 43 insertions(+), 2 deletions(-)
create mode 100644 recipes-security/AppArmor/files/py-libdir.patch
diff --git a/recipes-security/AppArmor/apparmor_2.12.bb
b/recipes-security/AppArmor/apparmor_2.12.bb
index efa93e6..073b62d 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -18,6 +18,7 @@ SRC_URI = " \
file://disable_perl_h_check.patch \
file://crosscompile_perl_bindings.patch \
file://tool-paths.patch \
+ file://py-libdir.patch \
file://apparmor.rc \
file://functions \
file://apparmor \
@@ -79,9 +80,9 @@ do_install () {
install -d ${D}/${INIT_D_DIR}
install -d ${D}/lib/apparmor
- oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}" install
+ oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}"
PYLIBDIR=${PYTHON_SITEPACKAGES_DIR} install
oe_runmake -C ${B}/binutils DESTDIR="${D}" install
- oe_runmake -C ${B}/utils DESTDIR="${D}" install
+ oe_runmake -C ${B}/utils DESTDIR="${D}"
PYLIBDIR=${PYTHON_SITEPACKAGES_DIR} install
oe_runmake -C ${B}/parser DESTDIR="${D}" install
oe_runmake -C ${B}/profiles DESTDIR="${D}" install
diff --git a/recipes-security/AppArmor/files/py-libdir.patch
b/recipes-security/AppArmor/files/py-libdir.patch
new file mode 100644
index 000..2b88e54
--- /dev/null
+++ b/recipes-security/AppArmor/files/py-libdir.patch
@@ -0,0 +1,40 @@
+Let the user override the Python libdir so it goes to the right place, as
+python3-native's idea of $libdir may not match the target's $libdir.
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton
+
+diff --git a/libraries/libapparmor/swig/python/Makefile.am
b/libraries/libapparmor/swig/python/Makefile.am
+index 421acba9..d2b842a6 100644
+--- a/libraries/libapparmor/swig/python/Makefile.am
b/libraries/libapparmor/swig/python/Makefile.am
+@@ -14,7 +14,7 @@ all-local: libapparmor_wrap.c setup.py
+ $(PYTHON) setup.py build
+
+ install-exec-local:
+- $(PYTHON) setup.py install --root="/$(DESTDIR)" --prefix="$(prefix)"
++ $(PYTHON) setup.py install --root="/$(DESTDIR)" --prefix="$(prefix)"
--install-lib="$(PYLIBDIR)"
+
+ clean-local:
+ if test -x "$(PYTHON)"; then $(PYTHON) setup.py clean; fi
+diff --git a/utils/Makefile b/utils/Makefile
+index 68f8c376..025f9da5 100644
+--- a/utils/Makefile
b/utils/Makefile
+@@ -42,6 +42,7 @@ DESTDIR=/
+ BINDIR=${DESTDIR}/usr/sbin
+ CONFDIR=${DESTDIR}/etc/apparmor
+ PYPREFIX=/usr
++PYLIBDIR=$PYPREFIX/lib
+
+ PYFLAKES=pyflakes
+
+@@ -60,7 +61,7 @@ install: ${MANPAGES} ${HTMLMANPAGES}
+ $(MAKE) install_manpages DESTDIR=${DESTDIR}
+ $(MAKE) -C vim install DESTDIR=${DESTDIR}
+ ln -sf aa-status.8 ${DESTDIR}/${MANDIR}/man8/apparmor_status.8
+- ${PYTHON} ${PYSETUP} install --prefix=${PYPREFIX} --root=${DESTDIR}
--version=${VERSION}
++ ${PYTHON} ${PYSETUP} install --prefix=${PYPREFIX}
--install-lib=${PYLIBDIR} --root=${DESTDIR} --version=${VERSION}
+
+ .PHONY: clean
+ ifndef VERBOSE
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fetch from git every bitbake
I try AUTOREV in the recipe app_1.0.bb
SRCREV := "${AUTOREV}"
But it doesn't work.
Which other variables could inhibit AUTOREV?
MZ
Il 17/01/19 15:09, Burton, Ross ha scritto:
> Look up AUTOREV in the manual, that does exactly what you want.
>
> Ross
>
> On Thu, 17 Jan 2019 at 14:08, Mauro Ziliani wrote:
>> Hi all.
>>
>> How can I force the pull from git repository of my app every time I do
>>
>> bitbake app
>>
>>
>> Best regards,
>>
>>MZ
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 18 jan. 2019 kl. 12:29 skrev Richard Purdie > : > >> On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: >> So if KNOWN_TASKS is defined in a configuration file in oe-core, it >> would be OK? >> It needs to be extended to check for KNOWN_TASKS == None of course. > > No, this is too fragile. We then have to maintain two different lists > of tasks. If we did that we may as well just remove the generic tasks > mechanism and hardcode the tasks list in the metadata. > Why do we need two lists? We need to know in what order the generic tasks are executed, that is all. Then we need to see if an addtask is violating that order. If the ”after” or ”before” is not a generic task, the check cannot catch that. If the user decides to not use the generic tasks, and create new ones with the same name, as the generic tasks, but rearranges the order, there will be a problem, but I do not see any other problems. Please enlighten me! > As I mentioned, we need to come up with something which detects the > task loops generically. > > Cheers, > > Richard > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fetch from git every bitbake
> I try AUTOREV in the recipe app_1.0.bb
> SRCREV := "${AUTOREV}"
> But it doesn't work.
> Which other variables could inhibit AUTOREV?
Could you share complete recipe, please?
I would give it a try:
SRCREV = "${AUTOREV}"
Best regards,
Lukasz Zemla
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
On Fri, 2019-01-18 at 15:16 +0100, Ulf Samuelsson wrote: > > 18 jan. 2019 kl. 12:29 skrev Richard Purdie < > > richard.pur...@linuxfoundation.org>: > > > > > On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: > > > So if KNOWN_TASKS is defined in a configuration file in oe-core, > > > it > > > would be OK? > > > It needs to be extended to check for KNOWN_TASKS == None of > > > course. > > > > No, this is too fragile. We then have to maintain two different > > lists > > of tasks. If we did that we may as well just remove the generic > > tasks > > mechanism and hardcode the tasks list in the metadata. > > > Why do we need two lists? If we change one of these "generic" tasks, we then need to remember to also update KNOWN_TASKS. The same information is being encoded in two places. Maintaining the same information in two different places means one of those places inevitably ends up out of date. > We need to know in what order the generic tasks are executed, that is > all. > > Then we need to see if an addtask is violating that order. > If the ”after” or ”before” is not a generic task, the check cannot > catch that. > > If the user decides to not use the generic tasks, and create new ones > with the same name, as the generic tasks, but rearranges the order, > there will be a problem, but I do not see any other problems. > > Please enlighten me! This has the problem that the code will find some subset of the bugs but not all of them. We'll then get users reporting that the tests failed and asking for the checks to be improved. So no, we are not doing this, sorry. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 18 jan. 2019 kl. 15:40 skrev Richard Purdie > : > > On Fri, 2019-01-18 at 15:16 +0100, Ulf Samuelsson wrote: >>> 18 jan. 2019 kl. 12:29 skrev Richard Purdie < >>> richard.pur...@linuxfoundation.org>: >>> On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: So if KNOWN_TASKS is defined in a configuration file in oe-core, it would be OK? It needs to be extended to check for KNOWN_TASKS == None of course. >>> >>> No, this is too fragile. We then have to maintain two different >>> lists >>> of tasks. If we did that we may as well just remove the generic >>> tasks >>> mechanism and hardcode the tasks list in the metadata. >>> >> Why do we need two lists? > > If we change one of these "generic" tasks, we then need to remember to > also update KNOWN_TASKS. The same information is being encoded in two > places. > > Maintaining the same information in two different places means one of > those places inevitably ends up out of date. We could insert a check if the KNOWN_TASKS is valid in a verification test. When building core-image-minimal, the task order within core-image-minimal is analyzed, (dependencies on all other recipes is filtered away). Then you find out if there are tasks added, missing, and/or in the wrong order. Best Regards, Ulf Samuelsson > >> We need to know in what order the generic tasks are executed, that is >> all. >> >> Then we need to see if an addtask is violating that order. >> If the ”after” or ”before” is not a generic task, the check cannot >> catch that. >> >> If the user decides to not use the generic tasks, and create new ones >> with the same name, as the generic tasks, but rearranges the order, >> there will be a problem, but I do not see any other problems. >> >> Please enlighten me! > > This has the problem that the code will find some subset of the bugs > but not all of them. We'll then get users reporting that the tests > failed and asking for the checks to be improved. > > So no, we are not doing this, sorry. > > Cheers, > > Richard > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Rebased Python 3.7.1 patch
I've rebased and made some minor changes to a Python 3.7.1 patch from patchworks. I'd be interested in seeing this patch make it into master if possible. Could anyone provide any guidance on the process of submitting a patch? Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
On Fri, 18 Jan 2019 at 15:08, Ulf Samuelsson wrote: > We could insert a check if the KNOWN_TASKS is valid in a verification test. > When building core-image-minimal, the task order within core-image-minimal is > analyzed, (dependencies on all other recipes is filtered away). > Then you find out if there are tasks added, missing, and/or in the wrong > order. What about people who add new tasks? Do they now need to go and extend KNOWN_TASKS correctly too? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> On 18 Jan 2019, at 16.34, Burton, Ross wrote: > >> On Fri, 18 Jan 2019 at 15:08, Ulf Samuelsson wrote: >> We could insert a check if the KNOWN_TASKS is valid in a verification test. >> When building core-image-minimal, the task order within core-image-minimal >> is analyzed, (dependencies on all other recipes is filtered away). >> Then you find out if there are tasks added, missing, and/or in the wrong >> order. > > What about people who add new tasks? Do they now need to go and > extend KNOWN_TASKS correctly too? I might be missing something, but isn’t the right moment to detect loops when the task graph is fully formed? Then just run generic DFS on it, not a difficult or heavy algorithm. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 18 jan. 2019 kl. 16:56 skrev Alexander Kanavin : > > > >>> On 18 Jan 2019, at 16.34, Burton, Ross wrote: >>> >>> On Fri, 18 Jan 2019 at 15:08, Ulf Samuelsson wrote: >>> We could insert a check if the KNOWN_TASKS is valid in a verification test. >>> When building core-image-minimal, the task order within core-image-minimal >>> is analyzed, (dependencies on all other recipes is filtered away). >>> Then you find out if there are tasks added, missing, and/or in the wrong >>> order. >> >> What about people who add new tasks? Do they now need to go and >> extend KNOWN_TASKS correctly too? > > I might be missing something, but isn’t the right moment to detect loops when > the task graph is fully formed? Then just run generic DFS on it, not a > difficult or heavy algorithm. > > Alex The problem in our system was that the build crashed before that. Best Regards, Ulf Samuelsson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] ref-manual: Update the definition of SDK_VERSION
The definition in poky.conf has been updated.
Signed-off-by: Peter Kjellerstedt
---
This of course assumes that the corresponding patch that I just sent
to the openembedded-core mailing list has been integrated first.
documentation/ref-manual/ref-variables.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index ed65727fc7..4b243a12dd 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -13045,7 +13045,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
/meta-poky/conf/distro/poky.conf)
defines the SDK_VERSION as follows:
- SDK_VERSION :=
"${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+ SDK_VERSION =
"${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
--
2.12.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Rebased Python 3.7.1 patch
You can start by reading the following: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Alex On Fri, 18 Jan 2019 at 16:24, Seth McLean wrote: > > I've rebased and made some minor changes to a Python 3.7.1 patch from > patchworks. I'd be interested in seeing this patch make it into master if > possible. > > Could anyone provide any guidance on the process of submitting a patch? > > Thanks, > > Seth > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fetch from git every bitbake
I try BB_SRCREV_POLICY in conf/local.conf
First I try
BB_SRCREV_POLICY := "clear"
Then I try
BB_SCREV_POLICY_pn-app := "clear"
app_1.0.bb is the recipe with
SRCREV="${AUTOREV}"
SRC_URI += " \
file://git@sourcer/app.git \
"
I'm working with a mixed version of Krogoth/Jethro.
Any Idea?
Il 18/01/19 15:00, Mauro Ziliani ha scritto:
> I try AUTOREV in the recipe app_1.0.bb
>
>
> SRCREV := "${AUTOREV}"
>
> But it doesn't work.
>
> Which other variables could inhibit AUTOREV?
>
>
> MZ
>
> Il 17/01/19 15:09, Burton, Ross ha scritto:
>> Look up AUTOREV in the manual, that does exactly what you want.
>>
>> Ross
>>
>> On Thu, 17 Jan 2019 at 14:08, Mauro Ziliani wrote:
>>> Hi all.
>>>
>>> How can I force the pull from git repository of my app every time I do
>>>
>>> bitbake app
>>>
>>>
>>> Best regards,
>>>
>>>MZ
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] ref-manual: Update the definition of SDK_VERSION
Peter,
Thanks for the patch. See
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-SDK_VERSION
for the update.
Scott
On Fri, Jan 18, 2019 at 8:02 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:
> The definition in poky.conf has been updated.
>
> Signed-off-by: Peter Kjellerstedt
> ---
> This of course assumes that the corresponding patch that I just sent
> to the openembedded-core mailing list has been integrated first.
>
> documentation/ref-manual/ref-variables.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index ed65727fc7..4b243a12dd 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -13045,7 +13045,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
> /meta-poky/conf/distro/poky.conf)
> defines the SDK_VERSION as
> follows:
>
> - SDK_VERSION :=
> "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
> + SDK_VERSION =
> "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
>
>
>
> --
> 2.12.0
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] ipv6
All I am using "rocko" How can we turn off ipv6 altogether? We are not doing anything to startup ipv6. Still I see several lines in the logs which look like: kernel: IPv6: wlan0: IPv6 duplicate address . detected kernel[288]: IPv6: wlan0: IPv6 duplicate address ... detected thanks, srini CONFIDENTIALITY NOTICE: This email message and any attachments are confidential and may be privileged and are meant to be read by the intended recipient only. If you are not the intended recipient, please notify sender immediately and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
