**** BEGIN LOGGING AT Tue Nov 14 03:00:01 2017
Nov 14 10:36:10 <Tamis> Hello. For building a java project using ant I show that ant-native recipe exists.
Nov 14 10:36:27 <Tamis> Is there anything similar for maven?
Nov 14 10:36:55 <Tamis> Or I can also invoke maven from host machine?
Nov 14 10:53:46 <xtron> hi everyone, I'm making a test-layer with example recipe in it, I added the layer to bblayers.conf file, now when I bitbake the example recipe it gives me error <function fail: do_package_qa error>.. how to solve this?
Nov 14 10:54:41 <xtron> previously I fixed this with do_package_qa [noexec] = "1", but that is a work around... what it really means and it's fix?
Nov 14 10:55:14 <ranran> after kernel build as part of image build, I go to ../work/../linux/git but I don't see .config ....
Nov 14 10:57:28 <Tamis> ranran: you should do to the build dir
Nov 14 10:57:46 <Tamis> ranran: .../linux/.../build
Nov 14 11:01:14 <xtron> ping
Nov 14 11:03:12 <LetoThe2nd> xtron: find out which QA fails. usually the message is considerably more verbose than what you gave us.
Nov 14 11:08:24 <xtron> LetoThe2nd: maybe because the default recipe don't have do_package_qa,
Nov 14 11:09:00 <LetoThe2nd> xtron: i've never had to add that explicitly.
Nov 14 11:09:41 <Tamis> xtron: I think all recipes have this task by default
Nov 14 11:10:05 <Tamis> or the majority of them.
Nov 14 11:11:19 <xtron> LetoThe2nd: https://pastebin.com/DhhW9SRz here is the error message if you can take a look
Nov 14 11:11:58 <xtron> I don't know, I'm using <yocto-layer create> script
Nov 14 11:13:57 <xtron> Tamis: this can be related to yocto version, I'm using version 2.2 Morty
Nov 14 11:14:27 <xtron> Tamis: as newer version has additional scripts
Nov 14 11:15:42 <Tamis> xtron: I am using the same branch as you.
Nov 14 11:16:14 <rburton> all recipes have do_package_qa unless they delete it
Nov 14 11:16:24 <Tamis> xtron: From the error I guess you forgot the enviroments LDFLAGS to your linking
Nov 14 11:17:59 <LetoThe2nd> xtron: the real failure is: QA Issue: No GNU_HASH in the elf binary:
Nov 14 11:18:22 <xtron> Tamis: so if you execute <yocto-layers create meta-test> it has do_package_qa, what is weird ...
Nov 14 11:19:19 <LetoThe2nd> xtron: the QA check is perfectly fine, it just triggers because something in your recipe is broken
Nov 14 11:19:20 <xtron> LetoThe2nd: I assume the example reicpe "example_0.1.bb should work out of the box
Nov 14 11:20:08 <LetoThe2nd> xtron: thats correct. but i've already had my share of assumptions from your side, to be honest
Nov 14 11:20:27 <Tamis> xtron: let me test that
Nov 14 11:20:28 <LetoThe2nd> xtron: so if you don't mind, i'll give the example recipe my own test and then report back, ok?
Nov 14 11:20:44 <xtron> LetoThe2nd: ok
Nov 14 11:20:59 <LetoThe2nd> xtron: your release is what?
Nov 14 11:21:20 <rburton> that warning normally happens if you didn't pass LDFLAGS to the linker
Nov 14 11:21:37 <rburton> ah the example was broken back then
Nov 14 11:21:37 <xtron> LetoThe2nd: Yocto Morty 2.2
Nov 14 11:22:09 <xtron> rburton: how to pass LDFLAGS and where?
Nov 14 11:23:57 <rburton> xtron: http://git.yoctoproject.org/cgit.cgi/poky/commit/scripts/lib/bsp/substrate/target/arch/layer/recipes-example/example/example-recipe-0.1.bb?h=rocko&id=9d4a69fd0de8fc52fa80ea14a437ad5d0e368d84
Nov 14 11:24:17 <rburton> its only a thing for hand-crafted recipes, and nobody was ever using the tool, so nobody noticed
Nov 14 11:25:08 <Tamis> yeah its broken
Nov 14 11:25:24 <Tamis> It is still broken. I just tested on morty
Nov 14 11:25:33 <Tamis> was not back ported
Nov 14 11:27:55 <xtron> rburton: I modified the recipe and it working. thanks
Nov 14 11:28:18 <rburton> its a very dumb example recipe, i recommend deleting it
Nov 14 11:28:57 <LetoThe2nd> rburton: yeah, it leads to headaches like this: https://stackoverflow.com/questions/47204368/yocto-multifile-compilation
Nov 14 11:29:26 <LetoThe2nd> maybe we should add gnu hello to meta-yocto or such
Nov 14 11:30:30 <rburton> NOOOOOOO
Nov 14 11:30:46 <rburton> LetoThe2nd: actually look at gnu hello
Nov 14 11:31:19 <rburton> its part of the docs for devtool and causes pain as it won't build out of the box
Nov 14 11:31:26 <rburton> but mainly because its everything wrong with GNU
Nov 14 11:33:00 <rburton> $ du -s hello/
Nov 14 11:33:00 <rburton> 122M	hello/
Nov 14 11:33:01 <rburton> HAHAHAHA
Nov 14 11:33:15 <rburton> that's a configured but not built checkout of gnu hello :)
Nov 14 11:34:08 <xtron> LetoThe2nd: rburton if possible it should be updated at least, annoying for new guys
Nov 14 11:35:11 <LetoThe2nd> xtron: ok, mea culpa
Nov 14 11:35:20 <LetoThe2nd> ah dang, rburton ^^^
Nov 14 11:35:38 <rburton> LetoThe2nd: its also got a build race so won't always build
Nov 14 11:36:37 <LetoThe2nd> rburton: i see. but i think it would be worthwhile to have a simplish autotoolized (or cmaked, whatever) helloworld-example
Nov 14 11:36:48 <rburton> LetoThe2nd: well, devtool kind of makes that redundant
Nov 14 11:36:58 <rburton> pick an upstream, point devtool at it
Nov 14 11:37:04 <rburton> (thus, gnu hello in the docs)
Nov 14 11:37:53 <LetoThe2nd> rburton: as much as i like devtool for some tasks, i don't think that this is a good way for newbies.
Nov 14 11:38:19 <rburton> its definitely the way to start for newbies, that's the entire point.  it writes the boring bits.
Nov 14 11:39:03 <Tamis> I never used it. But I think I have to switch to it. I always use devshell
Nov 14 11:39:46 <LetoThe2nd> rburton: i see the point, but i'm just not convinced that it works for that case.
Nov 14 11:40:02 <LetoThe2nd> rburton: maybe if the yocto-create layer tool was gone completely.
Nov 14 11:40:35 <rburton> yeah its gone :)
Nov 14 11:40:48 <rburton> yocto-kernel, yocto-layer, yocto-bsp, all deleted in master
Nov 14 11:40:49 <LetoThe2nd> is it?
Nov 14 11:41:12 <LetoThe2nd> ok, then i officially contradict all my former statements hereby!
Nov 14 11:44:16 <Tamis> Ok let me repeat me previous question. For ant I show at meta-java that ant-native exists
Nov 14 11:44:35 <Tamis> do you know if yocto has something also for maven?
Nov 14 11:46:03 <rburton> Tamis: http://layers.openembedded.org/ says that there's a recipe in meta-iot-cloud
Nov 14 11:46:13 <rburton> no doubt it should be reviewed and moved to meta-java
Nov 14 11:48:31 <Tamis> thanks a lot. I was using wrong google terms
Nov 14 11:48:44 <Tamis> to search for it. Now I found it
Nov 14 11:49:03 <rburton> always use layers.openembedded.org to find recipes
Nov 14 11:49:40 <ranran> after kernel build as part of image build, I go to ../work/../linux/git but I don't see .config . Anyone knows why ?
Nov 14 11:50:11 <Tamis> rburton: yeah. I know that. ty again
Nov 14 11:50:22 <rburton> ranran: probably because you're not looking in the build directory but the source directory
Nov 14 11:50:46 <Tamis> ranran: did you check the build folder also?
Nov 14 11:53:00 <open-nandra> hi, I bumped our project to use poky rocko but I started seeing issues with metadata hash for some task
Nov 14 11:53:06 <open-nandra> is there some option how to debug that?
Nov 14 11:53:15 <ranran> This is the build folder, Right ? /fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/4.9.11-r0/git
Nov 14 11:54:14 <ranran> How can I verify that this is the build folder ?
Nov 14 11:56:05 <Tamis> ranran: no. just try one folder back. you should see a build folder also
Nov 14 11:56:14 <Smit-Tay> I'm trying to make sense of where Yocto is placing ipk files.  It looks to me like duplicates of every ipk exist as a result of every build I make
Nov 14 11:56:32 <Tamis> ranran: the git folder is just a symbolic link
Nov 14 11:56:46 <Smit-Tay> tmp/deploy/ipk/corei7-64/libz1_1.2.8-r0_corei7-64.ipk and tmp/work/corei7-64-poky-linux/zlib/1.2.8-r0/deploy-ipks/corei7-64/libz1_1.2.8-r0_corei7-64.ipk
Nov 14 11:56:55 <Smit-Tay> for example
Nov 14 11:57:30 <Smit-Tay> These two files are produces from bitbake even though I only specified a single build target, my release build
Nov 14 11:58:10 <Smit-Tay> *ALSO*, when I look in the manifest for the build, I notice that zlib is named as a package, but in fact, the package is not named zlib
Nov 14 11:58:22 <Tamis> Smit-Tay: no it does not duplicate anything. Most of them are hard links
Nov 14 11:58:26 <Smit-Tay> it's named libz1
Nov 14 11:59:23 <ranran> Tamis, Thank you. I now see it. by the way, is there a way to find the build folder for each package ? something like bitbake -e <pkg> | grep ^D=
Nov 14 12:00:15 <Tamis> Smit-Tay: the one at the work dir is the first created. The other you see is just a hard link
Nov 14 12:00:43 <Tamis> ranran: I do not know that.
Nov 14 12:01:03 <ranran> Thanks Tamis.
Nov 14 12:01:04 <Smit-Tay> Tamis:  Why are the inodes different ?
Nov 14 12:02:49 <rburton> tmp/deploy is the final resting place for stuff that is built
Nov 14 12:03:12 <rburton> tmp/work/blaa/blaa/deploy-ipkgs is just a staging area, and if you inherit rm_work, will be deleted for you
Nov 14 12:03:35 <rburton> as to the also, my default debian.bbclass is inherited, which renames packages that only contain libraries to match their soname
Nov 14 12:03:40 <rburton> so zlib->libz
Nov 14 12:03:46 <rburton> glibc->libc6
Nov 14 12:03:47 <rburton> etc
Nov 14 12:04:34 <Smit-Tay> So, how do I make sense of what's in the manifest ?  It shows the name of the "Package" which doesn't match the name of the ipk file
Nov 14 12:05:44 <rburton> what manifest in particular?
Nov 14 12:06:14 <Smit-Tay> license.manifest
Nov 14 12:07:19 <Smit-Tay> found in /tmp/deploy/licenses
Nov 14 12:18:54 <tront_> hi everybody
Nov 14 12:19:36 <tront_> I have a question about the e2fsprogs package
Nov 14 12:20:35 <tront_> is there a particular reason why the fsck.extX binaries from this package are standalone binaries rather than having them be symlinks to e2fsck?
Nov 14 12:22:04 <RP> tront_: they're hardlinked
Nov 14 12:31:48 <tront_> right, thanks
Nov 14 12:41:43 <ranran> If we change sdk path (copy the entire sdk to somewhere else), is it sufficient to change the path in the environment setup script ?
Nov 14 13:16:35 <Smit-Tay> PK, I'm even more confused.  What is package.manifest, and why are its contents so different than license.manifest ?  License.manifest indicates the combination of package and version that *mostly* can be found as ipk files.  Whereas package.manifest contains a bare name (no version) of packages - which, at least has the redeeming feature that renamed packages like zlib->libz1 show up with the right (renamed) package name.  What's the purpose of two
Nov 14 13:16:35 <Smit-Tay> files, and why is the "core" data (i.e. the package name) different ?
Nov 14 13:26:05 <rburton> still not sure where you're finding license.manifest and package.manifest
Nov 14 13:26:26 <rburton> when i say the manifest, i mean the <rootfs>.manifest in tmp/deploy/images
Nov 14 13:26:52 <rburton> which uses real package names, such as libz1
Nov 14 13:27:09 <rburton> (and versions)
Nov 14 13:27:14 <rburton> eg libz1 core2_64 1.2.11
Nov 14 13:34:31 <rburton> ah there they are, generated by the license class
Nov 14 13:35:13 <rburton> Smit-Tay: clearly they need to be merged and fixed.  if you just want a manifest, use the one in the images directory
Nov 14 14:01:12 <Smit-Tay> OK, that appears to solve my problem.  Thanks again rburton
Nov 14 14:02:33 <Smit-Tay> rbuton, what is the second element in the row communicating ?
Nov 14 14:04:14 <Smit-Tay> I see at least three different values (corei7-64, all, hpad_al_54_uefi)
Nov 14 14:04:19 <Smit-Tay> in the same file
Nov 14 14:24:52 <xtron> can I use example recipe for both helloworld.c compiling and image creation using <inherit core-image> ?
Nov 14 14:25:23 <rburton> no
Nov 14 14:25:29 <rburton> packages != images
Nov 14 14:26:00 <rburton> if you want a custom image, copy/paste one of the existing images  that is close to what you want
Nov 14 14:28:46 <xtron> rburton: right,
Nov 14 14:40:36 <Adam_> Are EGL implementations of video drivers (ie, TI's DDK) agnostic to windowing system (ie X11 or Weston)?
Nov 14 14:45:47 <rburton> theoretically yes
Nov 14 14:46:00 <rburton> there are extensions the drivers need to support for eg wayland to work
Nov 14 14:47:15 <Adam_> Ok. On a Wayland/Weston system, to bind a legacy X11/EGL application to Xwayland would simply need X11-EGL extension. Correct?
Nov 14 14:49:03 <CTtpollard> is there a reason why the recipe for gpgme was removed between morty & pyro, but the rest of the config left?
Nov 14 14:49:27 <rburton> what configuration specifically?
Nov 14 14:49:51 <CTtpollard> wait ignore that, just typo'd an ls....
Nov 14 14:52:25 <CTtpollard> rburton: I'm trying to move an sdk from morty to pyro, it's complaining that nothing rprovides gpgme-pthread. Trying to see what's changed between recipe versions/configs
Nov 14 14:59:01 <CTtpollard> presumably from this commit http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6075e4978d344faabede03829ebacd82dcfd392b
Nov 14 15:03:02 <CTtpollard> so I need to change the rdpends to handle it..
Nov 14 15:13:52 <CTtpollard> rburton: same scenario but this time the removal of sgml-common?
Nov 14 15:16:45 <CTtpollard> ah..... http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=671780de49f93ec1cc28f5ad2a7eebe211918b85
Nov 14 15:18:13 <kanavin> CTtpollard: obviously we don't commit to maintaining stuff for all eternity :)
Nov 14 15:24:58 <diembed> Hi all
Nov 14 15:25:52 <diembed> Can someone tell me how to undo the forced flag ?
Nov 14 15:26:51 <diembed> I ran bitbake -f -c configure systemd. Now each time I run bitbake I have this message "systemd_232.bb.do_configure is tainted from a forced run", please.
Nov 14 15:27:45 <LetoThe2nd> diembed: -c clean it doesn't do the trick?
Nov 14 15:29:07 <CTtpollard> kanavin: understandable, git revert is fine for my needs here :)
Nov 14 15:30:15 <kanavin> CTtpollard: why do you need sgml stuff? has been obsolete for years
Nov 14 15:32:46 <berton> zeddii (IRC): ping
Nov 14 15:34:22 <diembed> LetoThe2nd: Thank you. I will try it when current build will be finished
Nov 14 15:36:47 <Smit-Tay> Newbie question.   I see version information that looks like this:  "1:2.44.1-r0"   What's the "1:" part called / indicating ?
Nov 14 15:37:12 <kanavin> Smit-Tay: package epoch
Nov 14 15:37:18 <diembed> I also have the flag forced for an image (let's say core-image-minimal), if I run "bitbake -c clean core-image-minimal", does all packages will be recompiled at next execution of "bitbake core-image-minimal" ?
Nov 14 15:37:48 <kanavin> diembed: no
Nov 14 15:37:51 <LetoThe2nd> diembed: nope, the command clears only the state for the given recipe
Nov 14 15:38:15 <LetoThe2nd> so if the caches are hot AND valid, only the image will be recreated
Nov 14 15:38:25 <diembed> kanavin and LetoThe2nd: Cool, thanks a lot
Nov 14 15:39:33 <kanavin> Smit-Tay: it's indicating whether the package previously used one versioning scheme, and then switched to another versioning scheme. to avoid confusing the two, package epoch clearly separates moving from one to another
Nov 14 15:40:21 <kanavin> Smit-Tay: or if we need to downgrade a package version for whatever reason
Nov 14 15:42:08 <kanavin> rburton: was the meson patchset ever given to AB?
Nov 14 15:42:34 <kanavin> (don't do it if it wasn't; I'm preparing a new version, and want to see any failures that happened)
Nov 14 15:43:00 <diembed> I have an other question : I created a systemd_%.bbappend file with these two lines:
Nov 14 15:43:02 <diembed> PACKAGECONFIG += " networkd resolved timedated timesyncd"
Nov 14 15:43:06 <diembed> EXTRA_OECONF_append = " --with-ntp-servers=0.pool.ntp.org --with-dns-servers= "
Nov 14 15:44:17 <diembed> I tried to move them to my machine configuration file but it does not work. Here the two lines added in file "machine/myboard.conf":
Nov 14 15:44:37 <diembed> #PACKAGECONFIG_systemd += " networkd resolved timedated timesyncd"
Nov 14 15:44:41 <diembed> EXTRA_OECONF_systemd_append = " --with-ntp-servers=0.pool.ntp.org --with-dns-servers= "
Nov 14 15:44:54 <LetoThe2nd> diembed: PACKAGECONFIG_on-systemd += "..."
Nov 14 15:45:04 <LetoThe2nd> dang, typo PACKAGECONFIG_pn-systemd += "..."
Nov 14 15:45:04 <diembed> (without # for PACKAGECONFIG_systemd, of course)
Nov 14 15:45:06 <Smit-Tay> SO, why is epcoh removed from the actual ipk file name ??  (And included in the manifest ??)
Nov 14 15:45:27 <kanavin> Smit-Tay: no idea. I'm a rpm specialist :)
Nov 14 15:45:43 <diembed> And Is EXTRA_OECONF OK ?
Nov 14 15:45:46 <kanavin> Smit-Tay: if you find the place in code where the filename is formed, you might see some clues
Nov 14 15:46:11 <LetoThe2nd> diembed: no idea if it works for EXTRA_OECONF too, but if, it will need the _pn- syntax too
Nov 14 15:46:34 <kanavin> diembed: you probably want these in your distro config, not your machine config, if you need to support several boards in the future
Nov 14 15:46:51 <diembed> LetoThe2nd: Thank you. I appreciate your help very much.
Nov 14 15:47:07 <LetoThe2nd> diembed: :-)
Nov 14 15:47:12 <LetoThe2nd> diembed: and what kanavin said
Nov 14 15:47:35 <Smit-Tay> libglib-2.0-0, is an example.  the manifest says it's version 1:2.44.1-r0, but the ipk file is named "libglib-2.0-0_2.44.1-r0_corei7-64.ipk"  (missing the epoch)
Nov 14 15:47:54 <diembed> kanavin: I put it in Machine as all futures machines will not necessarily need these options
Nov 14 15:48:52 <kanavin> diembed: still, it belongs in the distro - machine config should only have stuff related to hardware
Nov 14 15:49:21 <kanavin> diembed: if you need different settings, define another distro
Nov 14 15:49:32 <diembed> kanavin: and as you see I am not very familiar with all Yocto stuff. So I will do that later ;)
Nov 14 15:49:51 <diembed> kanavin: Thank you for advises
Nov 14 15:55:14 <diembed> PACKAGECONFIG_pn-systemd += "..." and EXTRA_OECONF_pn-systemd += "..." in machine file work perfectly (with bbappend disabled)
Nov 14 15:56:00 <kergoth> _pn += will erase any existing value, rather than appending to it
Nov 14 15:56:04 <kergoth> you want _append_pn- instead
Nov 14 15:56:51 <LetoThe2nd> kergoth: ah interesting, thx
Nov 14 15:57:04 <kergoth> note that _append won't add the space separator for you
Nov 14 16:00:00 <kergoth> https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples mentions the _append_foo vs _foo_append / _foo +=, though possibly not as clearly as i'd like given such a common point of confusion
Nov 14 16:01:02 <kanavin> kergoth: yeah, "try various ways until it works"
Nov 14 16:01:43 <kergoth> that's not generally a good way to proceed, that's how you end up with files riddled with bad stuff that others then copy and paste into their own files, and wrong stuff gets spread around to new layers
Nov 14 16:01:50 <kergoth> then it takes ages to fix them all
Nov 14 16:02:10 <kanavin> kergoth: yes, but that's how people tend to do things
Nov 14 16:02:16 <kergoth> sadly yes
Nov 14 16:02:19 <kanavin> kergoth: exhibit a: autotools
Nov 14 16:02:21 <kergoth> which is why layer quality is as bad as it is
Nov 14 16:02:23 <kergoth> that too
Nov 14 16:02:40 <kergoth> autotools shows the sad lack of configuration management and build engineering expertise in open source projects
Nov 14 16:02:44 <kergoth> too much emphasis on just the code
Nov 14 16:04:29 <kergoth> the yocto project is thankfully an exception to that, though
Nov 14 16:05:47 * kergoth ponders
Nov 14 16:06:06 <kanavin> kergoth: no one ever wants to be an expert in configuration management or build engineering. It's boring! :) People want to hack the code, and make it do exciting stuff, so those things are largely seen as necessary evil.
Nov 14 16:11:04 <kergoth> unfortunate, but true. configuration management is important, but not exciting
Nov 14 16:11:23 <diembed> kergoth: Indeed, since my modification xsltproc is no more found while compiling systemd, Thank you
Nov 14 16:14:56 <diembed> kergoth: I read a lot of docs for Yocto (including official one, for course) but I worked several years with LITB and I had to "learn" very fast Yocto to start a new project. I am the first to say that documentation must be read and the command "man" is my best friend but sometimes, it is not enough to understand all the underlaying stuff ;)
Nov 14 16:15:38 <kergoth> yeah, not blaming you there, there's a substantial learning curve, and this is a common area of confusion
Nov 14 16:15:45 <ranran> Which of the directory is applied with the patches, the source or the destination ?
Nov 14 16:16:22 <kergoth> ranran: what do you mean?
Nov 14 16:16:34 <LetoThe2nd> ranran: what good would it do to path the destination/build directory?
Nov 14 16:17:55 <ranran> I understand there is source directory ${S} and destination directory ${D}.
Nov 14 16:18:30 <kergoth> SRC_URI is sources by definition.
Nov 14 16:18:39 <kergoth> the whole point of patches in SRCURI is to patch the source tree
Nov 14 16:18:39 <ranran> If I understand correctly: fetch is into source, then it is also patched (in source) ?
Nov 14 16:19:05 <kergoth> sources are downloaded from upstream to DL_DIR in do_fetch, then unpacked from DL_DIR into WORKDIR in do_unpack, then patches are applied to S in do_patch
Nov 14 16:19:58 <ranran> kergoth, thank you very much, that's make sense now. !!
Nov 14 16:20:02 <kergoth> np
Nov 14 16:20:58 <kergoth> D is only ever written to directly in do_install
Nov 14 16:21:19 <kergoth> then the contents of D are split up into individual packages in do_package, and then written to binary package files in the do_package_write_* tasks
Nov 14 16:21:50 <LetoThe2nd> kergoth: hey don't burst my bubble "its all magic!"
Nov 14 16:21:53 <kergoth> iirc the behavior of the main tasks is covered by the yocto project docs as well as the yocto chapter of the architecture of open source systems book
Nov 14 16:22:02 <kergoth> in case you want to read more
Nov 14 16:23:31 <kergoth> of course, if you're really curious, you can just read base.bbclass, patch.bbclass, staging.bbclass, package.bbclass, and read the definitions of the tasks, but most dont' want that deep a dive :)
Nov 14 16:24:57 <ranran> Thanks, I had to understand the basic , before diving, and I understand now better, with the help of this group. Thanks a lot
Nov 14 16:27:51 * kergoth nods, no problem
Nov 14 16:41:58 <MWelchUK> joshuagl: o/
Nov 14 16:42:43 <xtron> With fresh copy of poky.morty, bitbake core-image-minimal throwing error of "changing ownership of... operation not permitted"
Nov 14 16:45:10 <xtron> ping
Nov 14 16:45:50 <MWelchUK> Are there any examples of IMAGE_QA_COMMANDS in Yocto, or is this some infrastructure that hasn't got any tests yet?
Nov 14 16:49:26 <yocti> New news from stackoverflow: GStreamer understanding (gst-pligins-base,... gst-plugin-vspfilter, element, pipeline) [on hold] <https://stackoverflow.com/questions/47207193/gstreamer-understanding-gst-pligins-base-gst-plugin-vspfilter-element-pip>
Nov 14 16:50:35 <rburton> kanavin: can't recall, please rebase and ping when you have a moment
Nov 14 17:01:41 <diembed> Is there any further informations about SRC_URI than this one http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SRC_URI ? I need to clone a git repository with submodules. I don't known if the recipe does it the right way : https://git.yoctoproject.org/cgit/cgit.cgi/meta-tlk/tree/common/recipes-support/sbsigntool/sbsigntool-native_git.bb?id=863590f9bc7104fef698ce6b89ec24dfce542df1
Nov 14 17:02:55 <diembed> (I already create other recipes with git repository and understand all the variable but the is the first I have to write for a project with submodule.
Nov 14 17:04:07 <diembed> So I don't know if git submodule init/update will do done automatically (I doubt it) or if I have to specify all submodules revision
Nov 14 17:04:57 <diembed> (like in sbsigntoll) or if there is an intermediate declaration of git+submodules repositories
Nov 14 17:06:58 <diembed> without the need of declaring each submodules' destination directory ?
Nov 14 17:30:46 <diembed> I will ask again tomorrow ;) Bye and thanks
Nov 14 17:36:58 <ranran> Hello, I see 2 source directory for linux, what's the difference between them ?  build/tmp/work-shared/lec-imx6/kernel-source/  & build/tmp/work/lec_imx6-poky-linux-gnueabi/linux-imx/4.1.15-r0/git
Nov 14 17:49:39 <yocti> New news from stackoverflow: GStreamer understanding (gst-pligins-base,... gst-plugin-vspfilter, element, pipeline) [closed] <https://stackoverflow.com/questions/47207193/gstreamer-understanding-gst-pligins-base-gst-plugin-vspfilter-element-pip>
Nov 14 18:06:25 <Tamis> has anyone built openjdk-8-native in morty branch. It seems to fail at icedtea-native
Nov 14 18:08:31 <Tamis> plus the build prints a lot of warnings: ....exception IndexError: string index out of range
Nov 14 18:35:50 <uglyoldbob> has devtool been updated since fido to allow it to work with linux-yocto?
Nov 14 18:50:31 <otavio> rburton: i sent the u-boot update
Nov 14 20:05:10 <ranran> Does anyone knows why there are 2 source folders for linux: build/tmp/work-shared/lec-imx6/kernel-source/ build/tmp/work/lec_imx6-poky-linux-gnueabi/linux-imx/4.1.15-r0/git ?
Nov 14 20:05:40 <fray> the 'work-shared' is the source for the kernel that is shared between all users of that source (as there are multiple users)
Nov 14 20:05:59 <fray> the copy on the w'owkr' directory (assuming it's using STANDARD tooling) is specific instance for that build..
Nov 14 20:06:15 <fray> often a BSP vendor will do their own thing, so the work-shared version is never really shared..
Nov 14 20:09:03 <ranran> thank fray
Nov 14 20:09:07 <ranran> thanks
Nov 14 20:18:18 <maciejjo> hi, i've got a question: is it possible to build several image recipes with one bitbake target?
Nov 14 20:19:04 <kergoth> ?
Nov 14 20:19:08 <maciejjo> I would like to build rootfs and additionally small ramdisk image
Nov 14 20:19:20 <kergoth> the bitbake command accepts any arbitrary number of targets on the commandline, is that insufficient?
Nov 14 20:20:36 <maciejjo> didn't thought about it that way, should be ok
Nov 14 20:21:55 <diembed> Hi again :)
Nov 14 20:22:35 <kergoth> diembed: just use gitsm:// instead of git:// to let the bitbake fetcher handle a remote git repo with submodules
Nov 14 20:22:38 <kergoth> nothing else you need to do
Nov 14 20:24:41 <diembed> kergoth: Thank you. I found this in a stackoverflow's post (or similar) but I was not sure it was the best way (and tought it was obsolete as it is not in docs)
Nov 14 20:27:03 <diembed> A last question: I try to populate a custom license (for vim recipe imported to my layer from official meta-oe layer) but I have this warning "The license listed vim was not in the licenses collected for recipe vim"
Nov 14 20:27:28 <diembed> I added "LICENSE_PATH += "${LAYERDIR}/files/custom-licenses"" to mylayer/conf/layer.conf
Nov 14 20:28:18 <diembed> *to meta-mylayer/conf/layer.conf
Nov 14 20:28:38 <diembed> I added the vim license file to meta-mylayer/files/custom-licenses
Nov 14 20:29:42 <diembed> and in meta-mylayer/repices-oe/vim/vim_8.0.0427.bb there is this line : LICENSE = "vim"
Nov 14 20:29:54 <diembed> Do you any lead for me, please ?
Nov 14 20:32:07 <diembed> I used http://www.yoctoproject.org/docs/2.1/bsp-guide/bsp-guide.html and I don't see what is wrong
Nov 14 21:17:01 <joshuagl> MWelchUK: \o I added that so that we could implement things like: http://git.yoctoproject.org/clean/cgit.cgi/meta-swupd/tree/classes/swupd-image.bbclass#n572
Nov 14 21:54:56 <diembed> Bye and thanks for help
Nov 15 00:08:44 <Guest93429> Hi, If I add tools-sdk to Image features, I get  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Nov 15 00:08:52 <Guest93429> Any Ideas?
Nov 15 00:17:31 <bluelightning> Guest93429: you think you're adding but most likely you are setting and that is overriding the default value set with ?=
Nov 15 00:17:46 <bluelightning> Guest93429: I assume you are doing this from local.conf?
Nov 15 00:18:27 <Guest93429> yes!, but I usually have this line in local.conf anyways
Nov 15 00:18:29 <Guest93429> XTRA_IMAGE_FEATURES = "debug-tweaks"
Nov 15 00:19:18 <bluelightning> Guest93429: so you are just putting tools-sdk in the end of that? or doing it separately?
Nov 15 00:19:29 <Guest93429> end of that
Nov 15 00:19:40 <Guest93429> and I take it out and it boots fine
Nov 15 00:20:11 <bluelightning> well, that's odd.. I can't immediately see how that would have such an effect
Nov 15 00:20:31 <bluelightning> which target machine is this for?
Nov 15 00:20:42 <Guest93429> Only thing I can think is maybe its too big for initramfs? if I compare logs before and after its 170M vs 50M
Nov 15 00:20:51 <Guest93429> a zynq machine
Nov 15 00:20:52 <bluelightning> oh, right
Nov 15 00:21:08 <bluelightning> yeah, so, this is a prime example of why you shouldn't set this kind of thing from local.conf
Nov 15 00:21:14 <bluelightning> create yourself a proper image recipe and set it there
Nov 15 00:21:26 <bluelightning> then it won't interfere with your initramfs image
Nov 15 00:22:04 <bluelightning> (usually: take a copy of some base image, give it the name you want, and then modify it as desired)
Nov 15 00:22:45 <Guest93429> Ohh I see.. does that make a difference?
Nov 15 00:23:11 <bluelightning> Guest93429: well, if you set an image variable from local.conf, it affects any image you build, and that includes the image recipe used to generate the initramfs
Nov 15 00:23:56 <bluelightning> we really ought to tweak our documentation in this area
Nov 15 00:24:28 <Guest93429> ah I kind of see
Nov 15 00:24:31 <Guest93429> I will try this
Nov 15 00:24:32 <Guest93429> thank you
Nov 15 00:39:26 <Guest93429> @bluelightning, seeing the same error unfortunately
Nov 15 00:39:57 <bluelightning> Crofton|work: any suggestions? ^
Nov 15 00:40:30 <bluelightning> Guest93429: you did remove the feature from the line in local.conf right?
Nov 15 00:40:37 <Guest93429> made a asdf.bb where I require the image.bb, then set tools-sdk in there then build asdf
Nov 15 00:40:40 <Guest93429> and yes
Nov 15 00:40:45 <Guest93429> removed from local.conf
Nov 15 00:41:14 <bluelightning> ok, I'm stumped then I'm afraid... I haven't had any experience with the zynq boards unfortunately
Nov 15 00:41:23 <bluelightning> it may be image size related perhaps, but that's a guess
Nov 15 00:42:14 <Guest93429> Ok appreciate the help
Nov 15 01:19:34 <Crofton|work> sorry working on dinner
**** ENDING LOGGING AT Wed Nov 15 03:00:01 2017