Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Riko Ho 

Dear Yocto Team Members,

Here's what I got :

=

#:~/poky$ git branch
  master
* pyro


How can I fix that problem with modern perl in help2man ?

Thanks


On 31/07/17 21:26, Burton, Ross wrote:

Then the branch you checked out.  git branch will tell you.

Ross

On 31 July 2017 at 14:17, Riko Ho > wrote:


Git clone ...

On Jul 31, 2017 9:16 PM, "Burton, Ross" > wrote:

How did you get poky?

Ross

On 31 July 2017 at 14:14, Riko Ho > wrote:

How can I see my branch?

On Jul 31, 2017 9:12 PM, "Burton, Ross"
> wrote:

On 31 July 2017 at 03:33, Riko Ho
> wrote:

Is my auto make disabled with icecc ?

How to make it enable ? thanks.


That's just a debug message.

> | help2man: can't get `--help' info from automake-1.15
> | Try `--no-discard-stderr' if option outputs to stderr
> | Makefile:3687: recipe for target
'doc/automake-1.15.1' failed


That's the error your hitting.

I think you need to update to the latest commit for
the branch you're on, there was a problem with modern
perl in help2man.  What release/branch are you using?

Ross





--
*

/***/
Sent by Ubuntu LTS 16.04,
Kind regards,
Riko Ho
/***/

*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH V2] buildsteps: add bblayers modification step

2017-07-31 Thread Stephano Cetola 
Take a list of pairs of layer substitutions: (current, replacement)
and replace each entry's current layer with the replacement layer.
The replacement parameter may include #YPDIR which will be
substituted for the full path of the poky checkout.

[YOCTO #11745 ]

Signed-off-by: Stephano Cetola 
---
 .../autobuilder/buildsteps/ModBBLayersConf.py  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py
new file mode 100644
index 0..5e9a7f22b
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py
@@ -0,0 +1,40 @@
+'''
+Created on July 24, 2017
+
+__author__ = "Stephano Cetola"
+__copyright__ = "Copyright 2017, Intel Corp."
+__credits__ = ["Stephano Cetola"]
+__license__ = "GPL"
+__version__ = "2.0"
+__maintainer__ = "Stephano Cetola"
+__email__ = "stephano.cet...@linux.intel.com"
+'''
+
+from buildbot.steps.shell import ShellCommand
+from twisted.python import log
+import os
+
+class ModBBLayersConf(ShellCommand):
+haltOnFailure = True
+flunkOnFailure = True
+name = "Modify BBLayers Configuration"
+def __init__(self, factory, argdict=None, **kwargs):
+self.factory = factory
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = "Modify BBLayers Configuration"
+ShellCommand.__init__(self, **kwargs)
+
+def start(self):
+builddir = os.path.join(self.getProperty('builddir'), 'build')
+bblayers = "%s/build/conf/bblayers.conf" % builddir
+cmd = 'echo "Not configured"'
+if self.sub:
+cmd = ""
+for mod in self.sub:
+tgt, rep = mod
+rep = rep.replace("#YPDIR", builddir)
+cmd = cmd + "sed -i 's|.*%s .*|%s |' %s;" % (tgt, rep, 
bblayers)
+
+self.command = cmd
+ShellCommand.start(self)
-- 
2.13.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build problem after upgrade to pyro

2017-07-31 Thread Khem Raj 


On 7/31/17 6:27 AM, Diogo Piçarra wrote:
> Hi,
> 
> I have a recipe to build macchina.io that was working with morty but
> after updating to pyro i get the error "/lib/ld-linux-armhf.so.3: No
> such file or directory".
> It's looking fot the file in the wrong place.
> I already read the release notes and can't anyting that could have
> created this problem.
> How can I fix this?
> 
> Thanks
> Diogo
> 
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | Building V8 for arch arm with flags: library=shared i18nsupport=off
> werror=no snapshot=on  arm_version=7
> | tools/gyp/v8_external_snapshot.target.arm.release.mk:15: warning:
> overriding recipe for target
> '/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/JS/V8/v8-3.28.4/out/arm.release/snapshot_blob.bin'
> | tools/gyp/v8_external_snapshot.host.arm.release.mk:15: warning:
> ignoring old recipe for target
> '/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/JS/V8/v8-3.28.4/out/arm.release/snapshot_blob.bin'
> | ** Compiling src/Wrapper.cpp (release, shared)
> | ** Compiling src/PooledIsolate.cpp (release, shared)
> | ** Compiling src/LoggerWrapper.cpp (release, shared)
> | ** Compiling src/ConsoleWrapper.cpp (release, shared)
> | ** Compiling src/SystemWrapper.cpp (release, shared)
> | ** Compiling src/DateTimeWrapper.cpp (release, shared)
> | ** Compiling src/LocalDateTimeWrapper.cpp (release, shared)
> | ** Compiling src/ConfigurationWrapper.cpp (release, shared)
> | ** Compiling src/ApplicationWrapper.cpp (release, shared)
> | ** Compiling src/URIWrapper.cpp (release, shared)
> | ** Compiling src/TimerWrapper.cpp (release, shared)
> | ** Compiling src/BufferWrapper.cpp (release, shared)
> | ** Compiling src/JSExecutor.cpp (release, shared)
> | ** Compiling src/Module.cpp (release, shared)
> | ** Compiling src/ModuleRegistry.cpp (release, shared)
> | ** Building shared library (release)
> /home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSCore.so.1
> | ** Compiling src/SessionWrapper.cpp (release, shared)
> | ** Compiling src/RecordSetWrapper.cpp (release, shared)
> | ** Building shared library (release)
> /home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSData.so.1
> | ** Compiling src/Serializer.cpp (release, shared)
> | ** Compiling src/Deserializer.cpp (release, shared)
> | ** Compiling src/TaggedBinaryReader.cpp (release, shared)
> | ** Compiling src/BridgeWrapper.cpp (release, shared)
> | ** Building shared library (release)
> /home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSBridge.so.1
> | ** Compiling src/HTTPRequestWrapper.cpp (release, shared)
> | ** Compiling src/HTTPResponseWrapper.cpp (release, shared)
> | ** Compiling src/HTMLFormWrapper.cpp (release, shared)
> | ** Building shared library (release)
> /home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSNet.so.1
> | ** Creating dependency info for src/NetSSLBundleActivator.cpp
> | ** Compiling src/NetSSLBundleActivator.cpp (release, shared)
> | ** Building dynamic library (release, shared)
> /home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/OSP/NetSSL_OpenSSL/bin/Linux/armv7l/poco.net.ssl.so
> | /lib/ld-linux-armhf.so.3: No such file or directory

its possible that its setting up its own compiler variables CC/CXX etc,
with pyro we have recipe specific sysroots instead of a global staging
area. So earlier if you did not specify --sysroot option on
compiler/linker cmdline it was forgiving since build time sysroot and
runtime sysroot for cross compiler were same. This wont happen with
pyro and may be thats the reason for your problem.
Fixes for such issues are generally in letting the packages respect
the CC/CXX varibles coming from environment

> | 
> /home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/build/rules/dylib:60:
> recipe for target
> '/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/OSP/NetSSL_OpenSSL/bin/Linux/armv7l/poco.net.ssl.so'
> failed
> | make[2]: *** 
> [/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/OSP/NetSSL_OpenSSL/bin/Linux/armv7l/poco.net.ssl.so]
> Error 255
> | Makefile:383: recipe for target 'OSP/NetSSL_OpenSSL-libexec' failed
> | make[1]: *** [OSP/NetSSL_OpenSSL-libexec] Error 2
> | Makefile:78: recipe for target 'clean' failed
> | make: *** [clean] Error 2
> | WARNING: exit code 2 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
>

Re: [yocto] local file update vs rebuild

2017-07-31 Thread Khem Raj 


On 7/31/17 4:39 AM, Takashi Matsuzawa wrote:
> Hello.
> I am uncertain about do_clean behavior with local files.
> 
> 
> Say, I have local files referred by my recipe, and I have made changes to the 
> files referred.
> (Note, there is no change in my .bb file itself.)
> 
> 
>> SRC_URI += "file://src/*;subdir=local"
> 
> 
> What makes those changed files reflected to the build?
> Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?
> 
> 
> According to the document
> 
> 
>> do_clean
>> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, 
>> do_install, and do_package).
>> if no changes have been made and the recipe is rebuilt after cleaning, 
>> output files are simply restored from the sstate cache. 
> 
> 
> I want to avoid doing do_cleanall often, and I would like to tell bitbake 
> that my recipe needs rebuild at the same time not rebuilding others.
> But at the same time I want to avoid building my single explicity.
> I just want to build the image name as target.

I think ccleansstate should be good.

> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Reminder: Yocto Project Technical Team Meeting - Tuesday, Aug 1, 2017 8:00 AM US Pacific Time

2017-07-31 Thread Jolley, Stephen K 
Tuesday, August 1, 2017 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features

* Opens - 10 min

* Team Sharing - 10 min



We encourage people attending the meeting to logon the Yocto Project IRC 
channel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html


Conference Details:
Company:   WIND RIVER SYS

- dial into: 1-800-262-0778/404-397-1527

- enter the bridge number: 88748961#


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/monthly-technical-call


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:  (208) 244-4460
* Email:
stephen.k.jol...@intel.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] installing iso images in legacy mode

2017-07-31 Thread Markus Volk 
Iso Images (x86_64) created with the current master fail when trying to install 
using the legacy bios startup. Live boot from usb is fine, but when installing, 
i´m getting an error ... "/usr/share/locale" could not be found. After reboot 
i'm getting dropped to grub-shell, because the kernel could not be loaded.

When setting the bios startup to uefi mode, everything works as expected.

Has legacy pcbios mode been dropped or is this some kind of bug ?

-- 
Markus Volk 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] layer: remove TPM layer depends and other dynamic ones.

2017-07-31 Thread Armin Kuster 
include meta-python for AppArmor changes

Signed-off-by: Armin Kuster 
---
 conf/layer.conf | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 0e524a1..0b066fd 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,8 +9,4 @@ BBFILE_COLLECTIONS += "security"
 BBFILE_PATTERN_security = "^${LAYERDIR}/"
 BBFILE_PRIORITY_security = "6"
 
-LAYERDEPENDS_security = "core openembedded-layer perl-layer"
-LAYERDEPENDS_security += "${@bb.utils.contains("DISTRO_FEATURES", "x11", 
"gnome-layer xfce-layer", "", d)}"
-LAYERDEPENDS_security += "${@bb.utils.contains("MACHINE_FEATURES", "tpm", 
"tpm-layer", "",d)}"
-LAYERDEPENDS_security += "${@bb.utils.contains("MACHINE_FEATURES", "tpm2", 
"tpm-layer", "",d)}"
-LAYERDEPENDS_security += "${@bb.utils.contains("MACHINE_FEATURES", "vtpm", 
"tpm-layer meta-filesystems", "",d)}"
+LAYERDEPENDS_security = "core openembedded-layer perl-layer meta-python"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW31’17

2017-07-31 Thread Jolley, Stephen K 
Current Dev Position: YP 2.4 M2 is in QA, patches are being merged for M3

Next Deadline: YP 2.4 M3 Cut off is Aug. 21, 2017


SWAT team rotation: Armin -> Saul on July 28, 2017.

SWAT team rotation: Saul -> Ross on Aug. 4, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·2.4 M2 rc2 is in QA and about 60% complete: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status

·A good set of updates have been merged into pyro in preparation for 
2.3.2 (thanks Armin!)

·Some key bugfixes for the bitbake server rework were merged. These 
should handle cases where the server errors early on in startup much better in 
ways where the user can see what the issue is. Cleanups to various timeout 
loops and messages were also made. If people are seeing issues with the bitbake 
server rework please do report them as the currently known issues have all be 
fixed as of master today.

·Llvm merged into OE-Core along with mesa support for llvmpipe. The 
mesa support is not currently enabled by default.

·There have been some good changes to the image vm generation and 
compression chaining code which significantly cleaned up the code (and improved 
test coverage, thanks!). These may have some user visible effects so it's worth 
being aware of.

·Much of the key maintainers time is being taken up with patch review, 
testing and tracking down which patch was responsible for which build failure. 
It does sometimes feel that people expect others to test their patches which 
isn’t the case. Test failures mean batches have to be retested and slow the 
merge of code into master so we’d appreciate people’s attention to detail when 
they do send changes.


Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 - Not ready to do an rc2 yet.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Aug 28, 2017

YP 2.3.2 Release by Sept. 8, 2017


Key YP 2.4 Dates are:

YP 2.4 M2 Cut off is July 17, 2017 - In QA now.

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2556 (last week 2488)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:  stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to have Poky automatically login at boot?

2017-07-31 Thread Aaron Schwartz 
Good tip Andre!

Just adding 'auto-serial-console' to IMAGE_INSTALL results in openvt
complaining that VT1 is already in use and then the user is presented with
the regular login.  It looks like I'll be able to make this work once I
figure out how to disable whatever's claiming that vty, though.

Thanks for the help

On Fri, Jul 28, 2017 at 8:32 PM, Andre McCurdy  wrote:

> On Fri, Jul 28, 2017 at 11:29 AM, Aaron Schwartz
>  wrote:
> > Hello,
> >
> > I'm trying to have the busybox getty in Poky login as root automatically
> but
> > I can't seem to get it working.
>
> This may be a possible solution:
>
>   https://git.linaro.org/openembedded/meta-linaro.git/
> tree/meta-linaro/recipes-linaro/auto-serial-console/
> auto-serial-console_0.1.bb
>
> > So far I have a sysvinit-inittab_2.%.bbappend:
> >>
> >> PR := "${PR}.1"
> >> SYSVINIT_ENABLED_GETTYS="1 2 3 4"
> >> do_install() {
> >> install -d ${D}${sysconfdir}
> >> install -m 0644 ${WORKDIR}/inittab ${D}${sysconfdir}/inittab
> >> install -d ${D}${base_bindir}
> >> install -m 0755 ${WORKDIR}/start_getty
> ${D}${base_bindir}/start_getty
> >> set -x
> >> tmp="${SERIAL_CONSOLES}"
> >> for i in $tmp
> >> do
> >> j=`echo ${i} | sed s/\;/\ /g`
> >> l=`echo ${i} | sed -e 's/tty//' -e 's/^.*;//' -e 's/;.*//'`
> >> label=`echo $l | sed 's/.*\(\)/\1/'`
> >> echo "$label:12345:respawn:${base_bindir}/start_getty ${j} vt102" >>
> >> ${D}${sysconfdir}/inittab
> >> done
> >> if [ "${USE_VT}" = "1" ]; then
> >> cat <>${D}${sysconfdir}/inittab
> >> # ${base_sbindir}/getty invocations for the runlevels.
> >> #
> >> # The "id" field MUST be the same as the last
> >> # characters of the device (after "tty").
> >> #
> >> # Format:
> >> #  :::
> >> #
> >> EOF
> >> for n in ${SYSVINIT_ENABLED_GETTYS}
> >> do
> >> echo "$n:12345:respawn:${base_sbindir}/mingetty --autologin
> >> root 38400 tty$n" >> ${D}${sysconfdir}/inittab
> >> done
> >> echo "" >> ${D}${sysconfdir}/inittab
> >> fi
> >> }
> >
> >
> > I have tried a number of flags with the default getty, including using a
> > shell as login.  I tried adding mingetty to my image to see if that would
> > work with it's "--autologin" flag, but I still got the busybox getty
> yelling
> > at me about unrecognized flags.
> >
> > Is the best approach to adjust the ALTERNATIVE_PRIORITY for either the
> > busybox getty or mingetty to have update-alternatives select mingetty,
> or is
> > there an easier modification to my sysvinit-innittab bbappend above that
> > will enable autologin?
> >
> > Thanks for the help!
> > Aaron
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>



-- 

Aaron Schwartz
Production
Logic Supply
Direct: +1 802 861 2300 Ext. 530
Main: +1 802 861 2300
www.logicsupply.com

Google+  | Twitter
 | LinkedIn
 | YouTube

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Understanding dtb generation wrt uboot (with signing)

2017-07-31 Thread Colin Helliwell 

> On 27 July 2017 at 17:48 colin.helliw...@ln-systems.com wrote:
> 
> I'm working on 2.2/Morty, with a custom board.
> Ultimate goal is to create a FIT image with a signed configuration. But I'm
> trying to just work through step by step and understand the relationships
> between u-boot, kernel, dtb, and the fit image - would appreciate any
> guidance!
> So far, I've built and booted a fitImage.
> 
...
> 
> First thing I'm puzzled by is that the dtb *is* in
> tmp/deploy/images/mymachine/ , but is called
> "zImage--4.4-r0-mymachine-20170727160613.dtb". Also with a symlink
> "zImage-mymachine.dtb". (If I'm understanding things right, this is because
> the fitImage contains a compressed kernel...?)
> 
> Then I set UBOOT_SIGN_ENABLE = "1", and re-bitbake the u-boot target. It
> only gets as far as re-building the kernel, which fails on the
> do_assemble_fitimage stage because uboot-mkimage is being told to use
> "u-boot.dtb"
> 

After studying things in more depth, I've now grasped that the relationships 
with the uboot-sign class are, not circular, but a bit to-and-fro between 
kernel and u-boot. Please correct me if I've got any of this wrong:
The 'final' signed dtb, for use by U-Boot, consists of the U-Boot dtb (i.e. the 
traditional U-Boot hardware blob) plus the fitimage dtb tree;
The latter encompasses the kernel and the hardware blob from the *kernel*.
It seems a bit tortured to have two hardware device blobs involved in this, but 
I kinda get the issues of keeping sync between two 
(https://stackoverflow.com/questions/30711327/why-device-tree-structure-dts-file-is-needed-both-in-bootloader-and-kernel-sou).

The first complication I have is that my [manufacturer-dervied] U-Boot doesn't 
seem to compile a dtb - instead the manufacturer just uses the one built with 
the kernel. I don't mind this too much - I don't particularly need a separate 
dtb to be built within U-Boot, and its arguably easier to *not* have to 
maintain two sets of sources. 
However this does aggravate the uboot-sign'ing, since there's no .dtb for 
kernel-fitimage.bbclass to use ("Step #7"). 

Is there some means already hooked into the class(es) whereby I can easily have 
the kernel dtb used in 'Step #7' instead?  
I thought I might be able to do this by setting UBOOT_DTB_IMAGE but it looks 
like the kernel's dtb hasn't yet, at this point in the build sequence, been 
installed into ${DEPLOYDIR}. Should I be aiming to make use of 'EXT_DTB'?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] extensible SDK build failure

2017-07-31 Thread Paul Eggleton 
Hi Russell,

It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK 
variable at the global level, which you really don't want to do if you're going 
to be building buildtools-tarball (which eSDK will build as a dependency). I'd 
suggest moving that setting to your image recipe.

Cheers,
Paul

On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> Hello, all.
> 
> I’m trying to build the eSDK for my platform and I just can’t figure out why 
> dnf can’t find kernel-devsrc.  It’s there, I added it.  The “normal SDK” uses 
> it and builds fine.  Just no luck with the eSDK.
> Any help out there?  Poky is pyro.  aarch64 SoC target platform with an x86 
> build host (CentOS 7.3).  Basically I just bitbake -c do_populate_sdk_ext 
> core-image-full.  I do have a linux kernel recipe that pulls the kernel from 
> the standard kernel.org  repo.
> 
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke dnf. 
> Command 
> '/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/dnf
>  -y -c 
> /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/dnf/dnf.conf
>  
> --setopt=reposdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none/etc/yum.repos.d
>  
> --repofrompath=oe-repo,/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
>  
> --installroot=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/poky/2.3.1/sysroots/none
>  
> --setopt=logdir=/scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp
>  --nogpgcheck install kernel-devsrc' returned 1:
> Added oe-repo repo from 
> file:///scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/oe-rootfs-repo
>  
> 
> Last metadata expiration check: 0:00:01 ago on Sun Jul 30 01:38:48 2017 UTC.
> No package kernel-devsrc available.
> Error: Unable to find a match
>  
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Function failed: 
> do_populate_sdk
> ERROR: Logfile of failure stored in: 
> /scratch/russell/yocto-00dc025f/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.4836
> ERROR: Task 
> (/labhome/russell/src/bf/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk)
>  failed with exit code '1'


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] build problem after upgrade to pyro

2017-07-31 Thread Diogo Piçarra 
Hi,

I have a recipe to build macchina.io that was working with morty but
after updating to pyro i get the error "/lib/ld-linux-armhf.so.3: No
such file or directory".
It's looking fot the file in the wrong place.
I already read the release notes and can't anyting that could have
created this problem.
How can I fix this?

Thanks
Diogo

Log data follows:
| DEBUG: Executing shell function do_compile
| Building V8 for arch arm with flags: library=shared i18nsupport=off
werror=no snapshot=on  arm_version=7
| tools/gyp/v8_external_snapshot.target.arm.release.mk:15: warning:
overriding recipe for target
'/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/JS/V8/v8-3.28.4/out/arm.release/snapshot_blob.bin'
| tools/gyp/v8_external_snapshot.host.arm.release.mk:15: warning:
ignoring old recipe for target
'/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/JS/V8/v8-3.28.4/out/arm.release/snapshot_blob.bin'
| ** Compiling src/Wrapper.cpp (release, shared)
| ** Compiling src/PooledIsolate.cpp (release, shared)
| ** Compiling src/LoggerWrapper.cpp (release, shared)
| ** Compiling src/ConsoleWrapper.cpp (release, shared)
| ** Compiling src/SystemWrapper.cpp (release, shared)
| ** Compiling src/DateTimeWrapper.cpp (release, shared)
| ** Compiling src/LocalDateTimeWrapper.cpp (release, shared)
| ** Compiling src/ConfigurationWrapper.cpp (release, shared)
| ** Compiling src/ApplicationWrapper.cpp (release, shared)
| ** Compiling src/URIWrapper.cpp (release, shared)
| ** Compiling src/TimerWrapper.cpp (release, shared)
| ** Compiling src/BufferWrapper.cpp (release, shared)
| ** Compiling src/JSExecutor.cpp (release, shared)
| ** Compiling src/Module.cpp (release, shared)
| ** Compiling src/ModuleRegistry.cpp (release, shared)
| ** Building shared library (release)
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSCore.so.1
| ** Compiling src/SessionWrapper.cpp (release, shared)
| ** Compiling src/RecordSetWrapper.cpp (release, shared)
| ** Building shared library (release)
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSData.so.1
| ** Compiling src/Serializer.cpp (release, shared)
| ** Compiling src/Deserializer.cpp (release, shared)
| ** Compiling src/TaggedBinaryReader.cpp (release, shared)
| ** Compiling src/BridgeWrapper.cpp (release, shared)
| ** Building shared library (release)
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSBridge.so.1
| ** Compiling src/HTTPRequestWrapper.cpp (release, shared)
| ** Compiling src/HTTPResponseWrapper.cpp (release, shared)
| ** Compiling src/HTMLFormWrapper.cpp (release, shared)
| ** Building shared library (release)
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/recipe-sysroot/lib//libPocoJSNet.so.1
| ** Creating dependency info for src/NetSSLBundleActivator.cpp
| ** Compiling src/NetSSLBundleActivator.cpp (release, shared)
| ** Building dynamic library (release, shared)
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/OSP/NetSSL_OpenSSL/bin/Linux/armv7l/poco.net.ssl.so
| /lib/ld-linux-armhf.so.3: No such file or directory
| 
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/build/rules/dylib:60:
recipe for target
'/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/OSP/NetSSL_OpenSSL/bin/Linux/armv7l/poco.net.ssl.so'
failed
| make[2]: *** 
[/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/git/platform/OSP/NetSSL_OpenSSL/bin/Linux/armv7l/poco.net.ssl.so]
Error 255
| Makefile:383: recipe for target 'OSP/NetSSL_OpenSSL-libexec' failed
| make[1]: *** [OSP/NetSSL_OpenSSL-libexec] Error 2
| Makefile:78: recipe for target 'clean' failed
| make: *** [clean] Error 2
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/home/username/yocto/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/macchina.io/git-r0/temp/log.do_compile.22044)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Burton, Ross 
Then the branch you checked out.  git branch will tell you.

Ross

On 31 July 2017 at 14:17, Riko Ho  wrote:

> Git clone ...
> On Jul 31, 2017 9:16 PM, "Burton, Ross"  wrote:
>
>> How did you get poky?
>>
>> Ross
>>
>> On 31 July 2017 at 14:14, Riko Ho  wrote:
>>
>>> How can I see my branch?
>>> On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:
>>>
 On 31 July 2017 at 03:33, Riko Ho  wrote:

> Is my auto make disabled with icecc ?
>
> How to make it enable ? thanks.
>

 That's just a debug message.

 > | help2man: can't get `--help' info from automake-1.15
 > | Try `--no-discard-stderr' if option outputs to stderr
 > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed


 That's the error your hitting.

 I think you need to update to the latest commit for the branch you're
 on, there was a problem with modern perl in help2man.  What release/branch
 are you using?

 Ross

>>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Riko Ho 
I forgot which one? How can I update?thx
https://www.yoctoproject.org/downloads/yocto-project
On Jul 31, 2017 9:17 PM, "Riko Ho"  wrote:

> Git clone ...
> On Jul 31, 2017 9:16 PM, "Burton, Ross"  wrote:
>
>> How did you get poky?
>>
>> Ross
>>
>> On 31 July 2017 at 14:14, Riko Ho  wrote:
>>
>>> How can I see my branch?
>>> On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:
>>>
 On 31 July 2017 at 03:33, Riko Ho  wrote:

> Is my auto make disabled with icecc ?
>
> How to make it enable ? thanks.
>

 That's just a debug message.

 > | help2man: can't get `--help' info from automake-1.15
 > | Try `--no-discard-stderr' if option outputs to stderr
 > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed


 That's the error your hitting.

 I think you need to update to the latest commit for the branch you're
 on, there was a problem with modern perl in help2man.  What release/branch
 are you using?

 Ross

>>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Riko Ho 
Git clone ...
On Jul 31, 2017 9:16 PM, "Burton, Ross"  wrote:

> How did you get poky?
>
> Ross
>
> On 31 July 2017 at 14:14, Riko Ho  wrote:
>
>> How can I see my branch?
>> On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:
>>
>>> On 31 July 2017 at 03:33, Riko Ho  wrote:
>>>
 Is my auto make disabled with icecc ?

 How to make it enable ? thanks.

>>>
>>> That's just a debug message.
>>>
>>> > | help2man: can't get `--help' info from automake-1.15
>>> > | Try `--no-discard-stderr' if option outputs to stderr
>>> > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
>>>
>>>
>>> That's the error your hitting.
>>>
>>> I think you need to update to the latest commit for the branch you're
>>> on, there was a problem with modern perl in help2man.  What release/branch
>>> are you using?
>>>
>>> Ross
>>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Burton, Ross 
How did you get poky?

Ross

On 31 July 2017 at 14:14, Riko Ho  wrote:

> How can I see my branch?
> On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:
>
>> On 31 July 2017 at 03:33, Riko Ho  wrote:
>>
>>> Is my auto make disabled with icecc ?
>>>
>>> How to make it enable ? thanks.
>>>
>>
>> That's just a debug message.
>>
>> > | help2man: can't get `--help' info from automake-1.15
>> > | Try `--no-discard-stderr' if option outputs to stderr
>> > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
>>
>>
>> That's the error your hitting.
>>
>> I think you need to update to the latest commit for the branch you're on,
>> there was a problem with modern perl in help2man.  What release/branch are
>> you using?
>>
>> Ross
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Riko Ho 
How can I see my branch?
On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:

> On 31 July 2017 at 03:33, Riko Ho  wrote:
>
>> Is my auto make disabled with icecc ?
>>
>> How to make it enable ? thanks.
>>
>
> That's just a debug message.
>
> > | help2man: can't get `--help' info from automake-1.15
> > | Try `--no-discard-stderr' if option outputs to stderr
> > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
>
>
> That's the error your hitting.
>
> I think you need to update to the latest commit for the branch you're on,
> there was a problem with modern perl in help2man.  What release/branch are
> you using?
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

2017-07-31 Thread Burton, Ross 
On 31 July 2017 at 03:33, Riko Ho  wrote:

> Is my auto make disabled with icecc ?
>
> How to make it enable ? thanks.
>

That's just a debug message.

> | help2man: can't get `--help' info from automake-1.15
> | Try `--no-discard-stderr' if option outputs to stderr
> | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed


That's the error your hitting.

I think you need to update to the latest commit for the branch you're on,
there was a problem with modern perl in help2man.  What release/branch are
you using?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] local file update vs rebuild

2017-07-31 Thread Takashi Matsuzawa 
Hello.
I am uncertain about do_clean behavior with local files.


Say, I have local files referred by my recipe, and I have made changes to the 
files referred.
(Note, there is no change in my .bb file itself.)


>SRC_URI += "file://src/*;subdir=local"


What makes those changed files reflected to the build?
Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?


According to the document


> do_clean
> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, do_install, 
> and do_package).
> if no changes have been made and the recipe is rebuilt after cleaning, output 
> files are simply restored from the sstate cache. 


I want to avoid doing do_cleanall often, and I would like to tell bitbake that 
my recipe needs rebuild at the same time not rebuilding others.
But at the same time I want to avoid building my single explicity.
I just want to build the image name as target.


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] swupate.bblcass dependencies not triggering rebuild

2017-07-31 Thread Stefano Babic 
Hi Andreas,

On 31/07/2017 11:31, Andreas Fenkart wrote:
> Hi
> 
> 2017-07-28 15:20 GMT+02:00 Andreas Fenkart :
>> Hi Stefano,
>>
>> 2017-06-14 10:32 GMT+02:00 Stefano Babic :
>>> Hi Andreas,
>>>
>>> On 13/06/2017 14:18, Andreas Fenkart wrote:
 Hi list,

 I want to create a swupdate file, which is a cpio file with rootfs and
 some metadata to control software update. My problem is, that it is not
 rebuilt everytime the rootfs changes. I checked in the cooker log.

 NOTE: recipe swupdate-image-1.0-r4: task do_populate_sysroot_setscene: 
 Succeeded
 NOTE: Running noexec task 5475 of 5478 (ID: 27,
 meta-devel/recipes-core/images/swupdate-image.bb, do_build)

 I generated the dot files with bitbake -g swupdate, and while do_swuimage
 has to run before do_build, do_build does not depend directly on 
 do_swuimage:

 swupdate-image.do_createlink -> swupdate-image.do_swuimage
 swupdate-image.do_install -> swupdate-image.do_createlink
 swupdate-image.do_populate_sysroot -> swupdate-image.do_install
 swupdate-image.do_build" -> swupdate-image.do_populate_sysroot

 $ bitbake-diffsigs -t swupdate-image do_build
 ERROR: No sigdata files found matching swupdate-image do_build

 $ bitbake-diffsigs -t swupdate-image do_populate_sysroot
 Unable to find matching sigdata for 
 recipes-core/images/swupdate-image.bb.do_install with hashes
 c0bc8039e8dbe8d70939dd3db2ceb922 or e9d7b242613f323d4d6adff3d6d4881b

 $ bitbake-diffsigs -t swupdate-image do_install
 ERROR: No sigdata files found matching swupdate-image do_install

 $ bitbake-diffsigs -t swupdate-image do_createlink
 Hash for dependent task imagesswupdate-image.bb.do_swuimage changed
 from cec64d7e21b0375ff641427d5d631254 to
 45510576a402839f4c4d4ac9b9eff578
   Hash for dependent task imagesrootfs.bb.do_build changed from
 876eb436b444f84efd355c0294b871bf to fabbabdd000427cdf5e721b59784d5c4
   Unable to find matching sigdata for
 meta-devel/recipes-core/images/rootfs.bb.do_build with hashes
 876eb436b444f84efd355c0294b871bf or fabbabdd000427cdf5e721b59784d5c4

 The dependency on rootfs is added here:
 https://github.com/sbabic/meta-swupdate/blob/master/classes/swupdate.bbclass#L64
 with IMAGE_DEPENDS="rootfs"

 Is it correct to 'depend' on :do_build? It seems rather uncommon.
>>>
>>> I think that the first attempt to set dependency here was with
>>> do_rootfs, but this just works for rootfs, not for all other images. In
>>> the history. commit b2f47aa9de53a98380b8677eb9e078db608b0ad3 changed
>>> from do_populatesysroot to do_build because it was noted that it runs
>>> too early.
>>>
>>> I am not sure if I have this issue, maybe it was sporadic. I wrote a
>>> patch, really to fix an issue in the transition morty --> pyro, where I
>>> changed the dependency as:
>>> diff --git a/classes/swupdate.bbclass b/classes/swupdate.bbclass
>>> index 44e4546..511f147 100644
>>> --- a/classes/swupdate.bbclass
>>> +++ b/classes/swupdate.bbclass
>>> @@ -61,16 +61,23 @@ def swupdate_getdepends(d):
>>>
>>>  depstr = ""
>>>  for dep in deps:
>>> -depstr += " " + dep + ":do_build"
>>> +if dep.find(":") != -1:
>>> +deptask = ""
>>> +else:
>>> +if (dep == "virtual/kernel") or (dep == "virtual/bootloader"):
>>> +deptask = ":do_deploy"
>>> +else:
>>> +deptask = ":do_image_complete"
>>> +
>>> +depstr += " " + dep + deptask
>>> +
>>>  return depstr
>>>
>>>
>>> So "do_image_complete" instead of "do_build", but I have to check
>>> explicitely for kernel and bootloader because they have no
>>> do_image_complete. But I do not know if this can be a correct solution.
>>>

 I checked the latest swupdate-image.do_populate siginfo in sstate, which is
 pretty large, so adding just the task-dependencies:
 ..
 Tasks this task depends on:
 ['..-devel/recipes-core/images/swupdate-image.bb.do_install']
 This task depends on the checksums of files: []
 Hash for dependent task
 ./meta-devel/recipes-core/images/swupdate-image.bb.do_install is
 e9d7b242613f323d4d6adff3d6d4881b
 Computed Hash is d8b1d389351c25e0c4a519fb8fe9ddda
 ..

 Which makes me wonder, since bitbake-diffsig said do_install has no sigdata

>>>
>>> We have do_install[noexec] = "1" in the class - is this the reason ?
>>
>> I removed all the 'noexec' stamps from swupdate.bbclass, but still the
>> cooker.log says, that none of the swupdate-image tasks needs
>> execution:
>>
>> NOTE: Setscene stamp current for task
>> 5(../recipes-core/images/swupdate-image.bb, do_populate_sysroot)
>> NOTE: Setscene stamp current for task
>> 6(../recipes-core/images/swupdate-image.bb, do_populate_lic)
>> NOTE: Setscene stamp current for task
>>

Re: [yocto] sstate cache not used when adding custom task

2017-07-31 Thread Andreas Fenkart 
Hi,

2017-07-13 11:30 GMT+02:00 Joshua Lock :
> On Thu, 2017-07-13 at 10:52 +0200, Andreas Fenkart wrote:
>> Hi,
>>
>> A custom task in a bbclass causes all recipes including it to be
>> rebuilt every time. Link to full bbclass attached below.
>>
>> I already stripped that task down to this
>>
>>
>> addtask check after do_compile before do_build
>> addons_do_check() {
>> :
>> }
>>
>> If I remove the addtask line, the recipe is not rerun:
>
> The shared state machinery doesn't know how to capture your task. There
> are some guidelines on adding shared state wrapping to a task in the
> Yocto Project reference manual Shared State Cache section:
>
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#shar
> ed-state-cache
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#shar
> ed-state
>
> Joshua

That did the job, thank you

>
>> $ bitbake recipe_name
>> NOTE: Tasks Summary: Attempted 2746 tasks of which 2746 didn't need
>> to
>> be rerun and all succeeded.
>>
>> With the 'addtask check' all task of the recipe from fetch till
>> rm_work_all is executed every time.
>>
>> From the cooker log, do_populate_sysroot is the last task running
>> before do_build was, hence I changed the addtask line to this:
>> addtask check after do_populate_sysroot before do_build
>>
>> Then the recipe will not start from do_fetch on rerun, but will
>> reuse the previous do_populate_sysroot run. Hence only the last 4
>> tasks are run (do_check, do_build, do_rm_work, do_rm_work_all)
>>
>> I experimented with bitbake-diffsig/bitbake-dumpsig, but the hash
>> of the stamp files (do_check) are identical on each run, of
>> course its content too. Only the timestamp of the stamp file
>> changes each run.
>> I'm confused what triggers the rebuild. I looked into bitbake
>> trying to understand how the task dependency is calculated, how
>> the sstate files are used. But it's quite a biest and will take
>> me quite some time to understand.
>>
>> Any hints or regarding the issue or simply where to put a print
>> in bitbake to get me started was welcome.
>>
>> This is still yocto 2.0.2 as we missed a couple of upgrades.
>>
>> The full bbclass with the do_check task
>> https://git.digitalstrom.org/dss-oe/dss-oe/blob/master/yocto/dS/meta-
>> digitalstrom-devel/classes/addons.bbclass#L46
>>
>> /Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] swupate.bblcass dependencies not triggering rebuild

2017-07-31 Thread Andreas Fenkart 
Hi

2017-07-28 15:20 GMT+02:00 Andreas Fenkart :
> Hi Stefano,
>
> 2017-06-14 10:32 GMT+02:00 Stefano Babic :
>> Hi Andreas,
>>
>> On 13/06/2017 14:18, Andreas Fenkart wrote:
>>> Hi list,
>>>
>>> I want to create a swupdate file, which is a cpio file with rootfs and
>>> some metadata to control software update. My problem is, that it is not
>>> rebuilt everytime the rootfs changes. I checked in the cooker log.
>>>
>>> NOTE: recipe swupdate-image-1.0-r4: task do_populate_sysroot_setscene: 
>>> Succeeded
>>> NOTE: Running noexec task 5475 of 5478 (ID: 27,
>>> meta-devel/recipes-core/images/swupdate-image.bb, do_build)
>>>
>>> I generated the dot files with bitbake -g swupdate, and while do_swuimage
>>> has to run before do_build, do_build does not depend directly on 
>>> do_swuimage:
>>>
>>> swupdate-image.do_createlink -> swupdate-image.do_swuimage
>>> swupdate-image.do_install -> swupdate-image.do_createlink
>>> swupdate-image.do_populate_sysroot -> swupdate-image.do_install
>>> swupdate-image.do_build" -> swupdate-image.do_populate_sysroot
>>>
>>> $ bitbake-diffsigs -t swupdate-image do_build
>>> ERROR: No sigdata files found matching swupdate-image do_build
>>>
>>> $ bitbake-diffsigs -t swupdate-image do_populate_sysroot
>>> Unable to find matching sigdata for 
>>> recipes-core/images/swupdate-image.bb.do_install with hashes
>>> c0bc8039e8dbe8d70939dd3db2ceb922 or e9d7b242613f323d4d6adff3d6d4881b
>>>
>>> $ bitbake-diffsigs -t swupdate-image do_install
>>> ERROR: No sigdata files found matching swupdate-image do_install
>>>
>>> $ bitbake-diffsigs -t swupdate-image do_createlink
>>> Hash for dependent task imagesswupdate-image.bb.do_swuimage changed
>>> from cec64d7e21b0375ff641427d5d631254 to
>>> 45510576a402839f4c4d4ac9b9eff578
>>>   Hash for dependent task imagesrootfs.bb.do_build changed from
>>> 876eb436b444f84efd355c0294b871bf to fabbabdd000427cdf5e721b59784d5c4
>>>   Unable to find matching sigdata for
>>> meta-devel/recipes-core/images/rootfs.bb.do_build with hashes
>>> 876eb436b444f84efd355c0294b871bf or fabbabdd000427cdf5e721b59784d5c4
>>>
>>> The dependency on rootfs is added here:
>>> https://github.com/sbabic/meta-swupdate/blob/master/classes/swupdate.bbclass#L64
>>> with IMAGE_DEPENDS="rootfs"
>>>
>>> Is it correct to 'depend' on :do_build? It seems rather uncommon.
>>
>> I think that the first attempt to set dependency here was with
>> do_rootfs, but this just works for rootfs, not for all other images. In
>> the history. commit b2f47aa9de53a98380b8677eb9e078db608b0ad3 changed
>> from do_populatesysroot to do_build because it was noted that it runs
>> too early.
>>
>> I am not sure if I have this issue, maybe it was sporadic. I wrote a
>> patch, really to fix an issue in the transition morty --> pyro, where I
>> changed the dependency as:
>> diff --git a/classes/swupdate.bbclass b/classes/swupdate.bbclass
>> index 44e4546..511f147 100644
>> --- a/classes/swupdate.bbclass
>> +++ b/classes/swupdate.bbclass
>> @@ -61,16 +61,23 @@ def swupdate_getdepends(d):
>>
>>  depstr = ""
>>  for dep in deps:
>> -depstr += " " + dep + ":do_build"
>> +if dep.find(":") != -1:
>> +deptask = ""
>> +else:
>> +if (dep == "virtual/kernel") or (dep == "virtual/bootloader"):
>> +deptask = ":do_deploy"
>> +else:
>> +deptask = ":do_image_complete"
>> +
>> +depstr += " " + dep + deptask
>> +
>>  return depstr
>>
>>
>> So "do_image_complete" instead of "do_build", but I have to check
>> explicitely for kernel and bootloader because they have no
>> do_image_complete. But I do not know if this can be a correct solution.
>>
>>>
>>> I checked the latest swupdate-image.do_populate siginfo in sstate, which is
>>> pretty large, so adding just the task-dependencies:
>>> ..
>>> Tasks this task depends on:
>>> ['..-devel/recipes-core/images/swupdate-image.bb.do_install']
>>> This task depends on the checksums of files: []
>>> Hash for dependent task
>>> ./meta-devel/recipes-core/images/swupdate-image.bb.do_install is
>>> e9d7b242613f323d4d6adff3d6d4881b
>>> Computed Hash is d8b1d389351c25e0c4a519fb8fe9ddda
>>> ..
>>>
>>> Which makes me wonder, since bitbake-diffsig said do_install has no sigdata
>>>
>>
>> We have do_install[noexec] = "1" in the class - is this the reason ?
>
> I removed all the 'noexec' stamps from swupdate.bbclass, but still the
> cooker.log says, that none of the swupdate-image tasks needs
> execution:
>
> NOTE: Setscene stamp current for task
> 5(../recipes-core/images/swupdate-image.bb, do_populate_sysroot)
> NOTE: Setscene stamp current for task
> 6(../recipes-core/images/swupdate-image.bb, do_populate_lic)
> NOTE: Setscene stamp current for task
> 7(../recipes-core/images/swupdate-image.bb, do_packagedata)
> NOTE: Setscene stamp current for task
> 8(../recipes-core/images/swupdate-image.bb, do_package_qa)
> NOTE: Setscene stamp current for task
>