**** BEGIN LOGGING AT Wed Oct 03 03:00:01 2018
Oct 03 09:36:22 <kuzulis> Hi guys, how I can remove 'matchbox-terminal' and 'matchbox-wm' from an image? It is in sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
Oct 03 09:36:57 <kuzulis> I want to create an own customised image from my layer
Oct 03 09:37:20 <kuzulis> So, I don't midify that sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
Oct 03 09:38:39 <kuzulis> Previously U have removed 'xinput-calibrator' using RDEPENDS_packagegroup-core-x11-utils_remove_pn-packagegroup-core-x11 = "xinput-calibrator"
Oct 03 09:38:46 <kuzulis> but it is magic for me
Oct 03 09:45:08 <abelal> kuzulis: you can use the same syntax to remove things from packagegroup-core-x11-base
Oct 03 09:46:01 <abelal> you'll have to use RDEPENDS_pn-packagegroup-core-x11-base_remove = "matchbox-terminal matchbox-wm"
Oct 03 09:47:19 <abelal> you'll have to do this in your local.conf or otherwise create an append in your layer for packagegroup-core-x11-base
Oct 03 09:47:40 <abelal> then use RDEPENDS_${PN}_remove = "matchbox-terminal matchbox-wm"
Oct 03 09:47:47 <abelal> inside the append
Oct 03 09:51:04 <kuzulis> I tried this: RDEPENDS_packagegroup-core-x11-base_remove_pn-packagegroup-core-x11-base = "matchbox-terminal" seems it work
Oct 03 09:51:39 <rburton> kuzulis: all those packagegroups are there to be modified, copied, or just ignored.
Oct 03 09:51:55 <kuzulis> abelal: What is more right way? use local.conf of .bbapend?
Oct 03 09:52:00 <rburton> bbappend
Oct 03 09:52:16 <kuzulis> ok, many thanks, I will try
Oct 03 09:55:51 <kuzulis> If I want to use .bbapend.. What is recipe name I need? recipes-graphics/packagegroups/packagegroup-core-x11-base/packagegroup-core-x11-base.bbapend ?
Oct 03 09:57:27 <kuzulis> or: /recipes-graphics/packagegroups/packagegroup-core-x11-base.bbappend ?
Oct 03 09:57:50 <rburton> latter
Oct 03 09:58:10 <kuzulis> ok, many thanks :)
Oct 03 09:59:04 <kuzulis> So, as I understand, this path should reflect the source *.bb path? E.g. for example if source path is: sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
Oct 03 09:59:23 <kuzulis> then overriding path should be : recipes-graphics/packagegroups/packagegroup-core-x11-base.bbappend ?
Oct 03 09:59:38 <rburton> path is actually irrelevant, its filename that counts
Oct 03 10:00:28 <kuzulis> do you mean that only 'packagegroup-core-x11-base.bbappend' makes sense?
Oct 03 10:01:20 <kuzulis> that it should be same as source 'packagegroup-core-x11-base.bb' ?
Oct 03 10:01:20 <rburton> i mean as long as it has that filename, it can be anywhere
Oct 03 10:04:56 <kuzulis> so, is it enough just add .bbapend instead of .bb with same file name, and to plase a resulting .bbapend file to any location?
Oct 03 10:05:09 <kuzulis> s/apend/append
Oct 03 10:05:29 <kuzulis> of my layer
Oct 03 10:05:30 <kuzulis> ?
Oct 03 10:05:52 <kuzulis> s/plase/place
Oct 03 10:09:20 <lukma> I do have a recipe, which provides
Oct 03 10:09:39 <lukma> foo, foo-test, foo-123
Oct 03 10:10:08 <lukma> And then I would like to use the "foo, foo-test and foo-123" with OVERRIDES
Oct 03 10:10:27 <lukma> unfortunately when I call bitbake foo or bitbake foo-123
Oct 03 10:10:37 <lukma> I only have pn-foo in OVERRIDES
Oct 03 10:11:02 <lukma> is there a neat way to extend OVERRIDES with exact recipe name (foo, foo-123) passed to bitbake ?
Oct 03 10:11:07 <lukma> Is it recommended?
Oct 03 10:12:27 <lukma> (The alternative would be to create a special machine, but this seems to me as an overkill)
Oct 03 10:13:53 <rburton> lukma: the override is the real recipe name, not the provides
Oct 03 10:15:10 <lukma> rburton: But is there a way to "tie" provide "name" with the OVERRIDES?
Oct 03 10:15:39 <lukma> rburton: And maybe the most important question - is it recommended (or do I something totally wrong)
Oct 03 10:17:20 <rburton> you might want to step back and explain what you're trying to solve where the solution is being able to use PROVIDES in overrides
Oct 03 10:17:32 <lukma> rburton
Oct 03 10:17:54 <lukma> rburton: The problem is that I do have a recipe for u-boot
Oct 03 10:18:19 <lukma> this recipe uses SCR_URI_append_123 ..... for (123 version)
Oct 03 10:18:30 <lukma> SRC_URI = (default u-boot)
Oct 03 10:18:46 <lukma> and SRC_URI_append_foo ..... for foo
Oct 03 10:19:02 <lukma> according to SRC_URI it applies different set of patches in do_patch
Oct 03 10:19:17 <rburton> why not have different recipes that include the main one and then extend the SRC_URI
Oct 03 10:19:33 <rburton> three actual recipes instead of one and a maze of overrides
Oct 03 10:19:53 <lukma> rburton: Hmm......
Oct 03 10:20:43 <lukma> rburton: It may work...... yes :)
Oct 03 10:21:13 <kuzulis> rburton: I have created  recipes-graphics/packagegroups/packagegroup-core-x11-base.bbappend and add there RDEPENDS_${PN}_remove = "matchbox-terminal matchbox-wm".. But it does not work
Oct 03 10:21:38 <lukma> rburton: Thanks for help :)
Oct 03 10:27:30 <kuzulis> rburton: Ah.. I need in addition to add in my image.bb this: IMAGE_INSTALL += "... packagegroup-core-x11-base "
Oct 03 11:06:15 <kuzulis> Guys, anouther question. How I can add symlink: ln -s /lib/ld-linux-armhf.so.3 ${D}/lib/ld-linux.so.3 ?
Oct 03 11:06:55 <kuzulis> I have created /recipes-core/glibc/glibc_%.bbappend with this content
Oct 03 11:07:04 <kuzulis> do_install_append() {
Oct 03 11:07:05 <kuzulis>     ln -s /lib/ld-linux-armhf.so.3 ${D}/lib/ld-linux.so.3
Oct 03 11:07:05 <kuzulis> }
Oct 03 11:07:31 <kuzulis> What I should do next?
Oct 03 11:08:17 <kuzulis> Or I do wrong?
Oct 03 11:20:04 <tgoodwin> kuzulis: I'm just walking into this but it looks like you're trying to setup a link into the host /lib rather than your recipe's work area (i.e., like ${S}/lib/ld-linux-armhf.so.3)
Oct 03 11:20:45 <tgoodwin> all, is there something funny about trying to DEPENDS against base-files?  My recipe-sysroot isn't being populated with its files.  (rocko, 2.4.3)
Oct 03 11:27:55 <yocti> New news from stackoverflow: Yocto development image with bbappend in multiple layers <https://stackoverflow.com/questions/52625668/yocto-development-image-with-bbappend-in-multiple-layers>
Oct 03 11:42:37 <derRichard> hey!
Oct 03 11:43:53 <derRichard> one of my packages fetches the latest source via git and the build script is using git describe to generate a version string. but it seems like bitbake fetches the git tree but then builds from a non-git copy.
Oct 03 11:44:11 <derRichard> is there a way to build _within_ the git tree such that git describe can work?
Oct 03 11:46:59 <rburton> are you using inherit autotools?
Oct 03 11:48:46 <angelo_ts> mistery: in a custom kernel_custom.bb recipe, in do_install() i do "${OBJCOPY} -O binary vmlinux linux.bin". The linux.bin comes half of the expected size. If execute the same objcopy command in the build dir, i get the proper linux.bin size.
Oct 03 11:50:18 <derRichard> rburton: no, cmake
Oct 03 11:52:45 <derRichard> rburton: hmm, looks like cmake does not find git within bitbake ;-\
Oct 03 11:52:47 <derRichard> grrrrr
Oct 03 11:52:59 <derRichard> then i start -c devshell git is here (hosttools)
Oct 03 11:53:03 <rburton> derRichard: cmake also does a build inside a separate directory (out of tree build)
Oct 03 11:53:20 <rburton> i suspect the git call is just broken
Oct 03 11:53:53 <rburton> try doing an out-of-tree build yourself outside of OE where the build directory is *above* the clone
Oct 03 11:53:59 <derRichard> rburton: yes, i fear you are right :)
Oct 03 11:54:22 <rburton> if the cmakelists is going to call git to find the version of the repo it should tell git where the clone is
Oct 03 12:09:00 <derRichard> rburton: ok, the cmakelists is b0rked. but dunno why. find_package(Git) fails when i build with bitbake
Oct 03 12:12:02 <rburton> git is in hosttools, so that's a question for cmake
Oct 03 12:15:51 <kuzulis> tgoodwin: No, seems it is not work nor with {S} nor with {D}..
Oct 03 12:16:38 <kuzulis> Guys, how I can know that my custom do_install_append() was called?
Oct 03 12:16:51 <derRichard> rburton: FWIW, OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH" did the trick
Oct 03 12:19:57 <tgoodwin> kuzulis: where does that file exist?
Oct 03 12:20:59 <kuzulis> tgoodwin: In: meta-my-layer/recipes-core/glibc/glibc_%.bbappend
Oct 03 12:21:42 <kuzulis> tgoodwin: I use similar approach from: https://stackoverflow.com/questions/36897000/yocto-cross-compiling-creating-symbolic-link-for-ld-linux-armhf-so-3
Oct 03 12:21:46 <tgoodwin> kuzulis: no I mean the actual library you're trying to link (ld-linux-armhf.so.3).  Is it a product of your do_compile?
Oct 03 12:24:01 <tgoodwin> kuzulis: that linking command in the reference and how you're using it is saying to link from your host operating system's /lib into your do_install destination (D).  That's very likely what you do not want to do since your host OS lib will not exist on the target.  I'm pretty sure a bitbake QA will pick that up and complain about contamination or something.
Oct 03 12:24:18 <kuzulis> tgoodwin: ld-linux-armhf.so.3 is a symlink to ld-2.25.so
Oct 03 12:27:06 <kuzulis> tgoodwin: On a target the ld-linux-armhf.so.3 (symlink) and ld-2.25.so (shared lib) are present
Oct 03 12:27:09 <angelo_ts> about the mistery above, finally found the u-boot layer compress the image (into half of the size) before the objcopy, btw, not clear why.
Oct 03 12:27:57 <kuzulis> tgoodwin: But I need in additional symlink ld-linux.so.3 to  ld-linux-armhf.so.3 (aka ld-2.25.so)
Oct 03 12:29:43 <kuzulis> tgoodwin: I don't know how to do it at all
Oct 03 12:29:47 <tgoodwin> kuzulis: I think what you're really trying to do is "ln -s ${D}/lib/ld-linux.so.3 ${D}/lib/ld-linux-armhf.so.3".
Oct 03 12:31:15 <tgoodwin> kuzulis: sorry, I think I have that backwards if I'm understanding you right.  The real link you're trying to link to is the first argument, the new link you're trying to create is the second.
Oct 03 12:32:02 <kuzulis> tgoodwin: Yes, "ln -s <file> <symlink>"
Oct 03 12:32:47 <kuzulis> tgoodwin: But it does not work... :(
Oct 03 12:33:12 <kuzulis> tgoodwin: How I can see that my do_install_image() were called at all?
Oct 03 12:33:25 <tgoodwin> kuzulis: but the fundamental thing is that you definitely do not want to link to _just_ /anything from your recipe since that leading / goes back to your host OS.
Oct 03 12:33:41 <kuzulis> tgoodwin: s/do_install_image()/do_install_append()
Oct 03 12:34:14 <tgoodwin> kuzulis: check your package's working directory for "temp".  The logs are in there (you can also find the path probably in the error messages you're seeing).
Oct 03 12:34:42 <kuzulis> tgoodwin: ok, many thanks, I'll try
Oct 03 12:34:47 <tgoodwin> kuzulis: so just to clarify, the line should be: ln -s ${D}/lib/ld-linux-armhf.so.3 ${D}/lib/ld-linux.so.3
Oct 03 12:35:15 <tgoodwin> I just tried it out in my glibc working area and it was fine.
Oct 03 12:36:56 <tgoodwin> Does anyone know of a reason why do_prepare_recipe_sysroot would skip unpacking a package in DEPENDS?
Oct 03 12:37:08 <tgoodwin> kuzulis: you're welcome :) hope it works
Oct 03 12:45:23 <tgoodwin> I have a recipe that only depends on base-files but only /etc/skel is being installed into the recipe-sysroot.
Oct 03 13:12:03 <tgoodwin> Ah.  Found it.  Does anyone know the reasoning for why SYSROOT_DIRS wouldn't include sysconfdir by default?
Oct 03 13:31:02 <rburton> tgoodwin: erm, no.  using D in the target is exactly the opposite of what you want
Oct 03 13:31:16 <rburton> that will put a symlink on target to /the/path/to/the/build/paths
Oct 03 13:32:13 <tgoodwin> kuzulis: ^^
Oct 03 13:33:01 <tgoodwin> my mistake
Oct 03 13:34:47 <JPEW> hmm, populate-volatiles is *slow*.....
Oct 03 13:34:52 <tgoodwin> I'm off in the weeds trying to figure out why adding my own base-files file to the recipe SYSROOT_DIRS didn't result in it being staged
Oct 03 13:39:53 <tgoodwin> rburton: for kuzulis' sake, would it be better for him to have created that extra link as relative instead?
Oct 03 13:40:22 <Crofton> JPEW, a watched build never finishes
Oct 03 14:11:21 <RP> JPEW: that sounds odd and something we should perhaps look at fixing
Oct 03 14:14:53 <JPEW> Rp: Yes, I traced it down: the requirements check (checking that the groups and users exist) against each volatile file is very expensive. When you have a lot of volatiles files and read-only rootfs you pay the penalty every boot.
Oct 03 14:15:46 <JPEW> I was able to make it 80% faster by concatenating all the volatiles together into a single file
Oct 03 14:41:36 <RP> JPEW: ah, sounds like a good improvement
Oct 03 14:47:33 * zeddii finally has his plane ticket to Edinburgh 
Oct 03 14:58:37 <yocti> New news from stackoverflow: Yocto sumo, meta-virtualization with vmdk <https://stackoverflow.com/questions/51078231/yocto-sumo-meta-virtualization-with-vmdk>
Oct 03 14:59:33 <kuzulis> Guys, why I can't remove 'xinput-calibrator' via my packagegroup-code-x11.bbappend.. It ignores at all.. But RDEPENDS_packagegroup-core-x11-utils_remove_pn-packagegroup-core-x11 = "xinput-calibrator"
Oct 03 14:59:33 <kuzulis>  does work.
Oct 03 15:00:29 <kuzulis> I have created /recipes-graphics/packagegroups/packagegroup-core-x11.bbappend and add there +RDEPENDS_${PN}_remove = "xinput-calibrator"
Oct 03 15:01:02 <RP> kuzulis: packagegroup-core-x11-utils != PN
Oct 03 15:01:03 <kuzulis> and then register my .bbappend as IMAGE_INSTALL += ' packagegroup-core-x11 '
Oct 03 15:01:23 <RP> and don't do that, you don't register bbappends
Oct 03 15:02:08 <kuzulis> RP: So, how I can remove "xinput-calibrator" in right way?
Oct 03 15:03:54 <kuzulis> Previously in this chat I was told that the ..bbappend is a right way to remove the packages..
Oct 03 15:04:54 <kuzulis> RP: What do you mean about " and don't do that, you don't register bbappends" ?
Oct 03 15:07:36 <RP> kuzulis: using a bbappend is fine but you don't "register" it like that
Oct 03 15:07:57 <RP> I don't know what "registering" a bbappend means
Oct 03 15:08:31 <RP> kuzulis: keep in mind that each recipe has multiple packages, e.g. the packagegroup-core-x11 recipe has packagegroup-core-x11-utils and packagegroup-core-x11 packages
Oct 03 15:09:03 <kuzulis> RP: Ok. But, how to remove 'xinput-calibrator' ? :)
Oct 03 15:11:07 <RP> RDEPENDS_packagegroup-core-x11-utils_remove = "xinput-calibrator" in the bbappend?
Oct 03 15:12:00 <kuzulis> RP: What is name of .bbappend then?
Oct 03 15:12:26 <kuzulis> RP: packagegroup-core-x11.bbappend?
Oct 03 15:12:30 <RP> yes
Oct 03 15:12:41 <kuzulis> RP: It is magic...
Oct 03 15:12:48 <kuzulis> RP: for me
Oct 03 15:13:08 <kuzulis> RP: yocto is a 'blackbox'
Oct 03 15:13:36 <RP> kuzulis: not entirely, it does have documentation, source code and a lot written about it...
Oct 03 15:13:48 <kergoth> bbappends are applied if your layer is in bblayers and its path is listed in the layer's bbfiles
Oct 03 15:15:22 <kuzulis> RP: I did not found a short/brief wiki how to append/remove required packages... :(
Oct 03 15:16:12 <kuzulis> there are a lot of conflicting information..
Oct 03 15:16:38 <kuzulis> but, many thanks anyway :)
Oct 03 15:20:32 <kuzulis> kergoth: My layer is in BBLAYERS, but my .bbappend ignored, until I did'nt  IMAGE_INSTALL += ' packagegroup-foo '
Oct 03 15:20:51 <kergoth> IMAGE_INSTALL is irrelevent
Oct 03 15:21:01 <kergoth> that controls what packages are installed in your image, not whether a bbappend is applied or not
Oct 03 15:21:45 <kuzulis> kergoth: Then I has not any idea why .bbappend did not work
Oct 03 15:24:09 <kuzulis> kergoth: Should bitbake "pick-up" any changes in .bbappend files and etc?
Oct 03 15:25:01 <kuzulis> kergoth: Or I need to cleanup the build-bla-bla directory before?
Oct 03 15:25:10 <kergoth> yes. again, make sure the layer is in bblayers and the bbappend path matches the pattern listed in bbfiles in conf/layer.conf in your layer. beyond that, use bitbake -e packagegroup-core-x11|grep '^RDEPENDS' to check if the change was applied
Oct 03 15:25:18 <kergoth> no, no need to clean anything when changing recipes or appends
Oct 03 15:25:27 <Crofton> try bitbake-layers show-appends
Oct 03 15:25:35 <Crofton> may need to run help to find exact syntax
Oct 03 15:25:45 <kergoth> yeah, good idea
Oct 03 15:29:41 <kuzulis> ahh... many thanks :)
Oct 03 15:31:01 <khem> RP: you have older version of mesa/musl patch staged into master-next
Oct 03 15:32:16 <RP> khem: well spotted, the v3 is way way better too!
Oct 03 15:32:24 <RP> khem: fixed, thanks (you can blame rburton for it)
Oct 03 15:32:42 <rburton> khem: huh, sorry!
Oct 03 15:32:52 <rburton> glad you noticed ,that's my pick script going wrong
Oct 03 15:33:33 <RP> khem: looking forward to getting rid of another orange box on the autobuilder :)
Oct 03 15:56:45 <kuzulis> Guys, how I can remove the packages like 'sudo', 'rsync' and etc from '/packagegroup-self-hosted'? Because  bitbake -e packagegroup-self-hosted | grep '^RDEPENDS' says that nothing provides..
Oct 03 15:59:31 <rburton> kuzulis: easy fix: don't install that package group?
Oct 03 16:00:27 <kuzulis> rburton: I did not install that group :)
Oct 03 16:01:41 <kuzulis> rburton: How I can ignore this group?
Oct 03 16:01:57 <rburton> well rsync is at meta/recipes-devtools/rsync/rsync_3.1.3.bb
Oct 03 16:02:09 <rburton> sudo is meta/recipes-extended/sudo/sudo_1.8.23.bb
Oct 03 16:02:12 <rburton> so they do exist
Oct 03 16:02:17 <rburton> so i don't see what the problem is
Oct 03 16:02:39 <kergoth> kuzulis: if you aren't installing the package group, what packages it includes is irrelevent
Oct 03 16:02:40 <kuzulis> rburton: Do you mean a problem to remove them?
Oct 03 16:02:55 <rburton> kuzulis: no i mean what *your problem* is
Oct 03 16:03:47 <kuzulis> rburton: I want to minimize an image
Oct 03 16:04:42 <rburton> so why is the content of packagegroup-self-hosted relevant?
Oct 03 16:04:49 <kergoth> a minimal image shouldn't be including self-hosted anyway
Oct 03 16:04:57 <kuzulis> So, what I need to do to remove the sudo and rsync from an image? because currently this utilities are present in image
Oct 03 16:04:59 <kergoth> just create yourself a new image with only what you need installed
Oct 03 16:05:13 <rburton> kuzulis: find out where they're being pulled in from, instead of guessing.  it won't be self-hosted.
Oct 03 16:06:21 <kergoth> bitbake -g your-image; oe-depends-dot -w -k sudo recipe-depends.dot
Oct 03 16:06:28 <kergoth> should do, iirc
Oct 03 16:06:49 <kuzulis> ohhh..
Oct 03 16:06:53 <rburton> kergoth: need an easy way of getting that data from the pacakge manager
Oct 03 16:08:26 <kuzulis> What is 'oe-depends-dot' ?
Oct 03 16:08:51 <rburton> $ oe-depends-dot --help
Oct 03 16:08:52 <rburton> usage: oe-depends-dot [-h] [-k KEY] [-d] [-w] [-r] dotfile
Oct 03 16:08:53 <rburton> Analyse recipe-depends.dot generated by bitbake -g
Oct 03 16:08:53 <kergoth> a script in oe-core/poky
Oct 03 16:09:13 <kuzulis> Hmm.. in my case I have not this script
Oct 03 16:09:23 <kuzulis> oe-depends-dot: command not found
Oct 03 16:11:44 <kuzulis> I got: "miatech-embedded-qt5-x11-image" -> "sudo"
Oct 03 16:11:44 <kuzulis> "packagegroup-core-x11-base" -> "sudo"
Oct 03 16:11:44 <kuzulis> "mini-x-session" -> "sudo"
Oct 03 16:12:51 <kuzulis> So, hould I remove 'sudo' e.g. from packagegroup-core-x11-base.bbappend ?
Oct 03 16:13:33 <kuzulis> like RDEPENDS_${PN}_remove = "sudo" ?
Oct 03 16:15:45 <rburton> are you building miatech-embedded-qt5-x11-image?
Oct 03 16:16:36 <kuzulis> rburton: Yes
Oct 03 16:16:46 <kuzulis> But there are no any 'sudo' mention
Oct 03 16:17:11 <kuzulis> and nowhere in my layer
Oct 03 16:17:38 <kuzulis> no any explicitly mention
Oct 03 16:19:20 <kergoth> kuzulis: the info you just pasted indicates it's mini-x-session pulling it in directly
Oct 03 16:19:25 <kergoth> the .dot shows both direct and indirect dependency
Oct 03 16:19:29 <kergoth> so bbappend mini-x-session
Oct 03 16:19:41 <kergoth> a quick grep shows that indeed, mini-x-session pulls it in
Oct 03 16:19:44 <kergoth> 16:RDEPENDS_${PN} = "sudo"
Oct 03 16:20:01 <kergoth> so either remove sudo there or stop using mini-x-session by removing that from the packagegroup
Oct 03 16:20:07 <kergoth> or better yet ,just create a custom image with exactly waht you want.
Oct 03 16:20:11 <kergoth> as mentioned before
Oct 03 16:20:33 <kuzulis> ok, many thanks for your time
Oct 03 16:54:34 <JaMa> ~
Oct 03 17:07:23 <armpit> RP, email sent to AB
Oct 03 19:00:34 <tgoodwin> Is anyone else using systemd 234? (rocko) I'm having this weird problem where a service is only occasionally showing up in the startup list.  It's setup to come before local-fs.target on an initrd and it's very inconsistent.
Oct 03 19:01:52 <tgoodwin> There are usually a series of messages about "found ordering cycle" and then it ends with deleting a job (not mine or local-fs.target) on the runs when my service fails to run.
Oct 03 19:41:22 <RP> armpit: thanks
Oct 03 22:52:45 <lukma> Is it possible to trick the do_fetch and use provided in DL_DIR repository ?
Oct 03 22:53:02 <lukma> I've found solution as in : https://stackoverflow.com/questions/41058204/how-to-do-fetch-by-hand-in-a-yocto-project
Oct 03 22:53:13 <lukma> But the solution doesn't seem correct..... :)
Oct 03 23:20:58 <kergoth> you don't generally need to do that. rather than digging into the internal sturcture of DL_DIR, just do a —runall=fetch with your other path as a premirror, so it'll fetch from the local path into the DL_DIR and create the done stamp appropriately
Oct 03 23:30:37 <khem> oh so thats what rain looks iike ...
Oct 04 00:30:22 <yocti> New news from stackoverflow: User application gets killed when string is passed to kernel device driver <https://stackoverflow.com/questions/52637261/user-application-gets-killed-when-string-is-passed-to-kernel-device-driver>
**** ENDING LOGGING AT Thu Oct 04 03:00:02 2018