**** BEGIN LOGGING AT Thu Oct 04 03:00:02 2018
Oct 04 06:01:20 <yocti> New news from stackoverflow: Yocto: meta-debian errors for cl-som-imx7 <https://stackoverflow.com/questions/52639702/yocto-meta-debian-errors-for-cl-som-imx7>
Oct 04 09:01:54 <yocti> New news from stackoverflow: YOCTO (MORTY) activate bash completion <https://stackoverflow.com/questions/52642864/yocto-morty-activate-bash-completion>
Oct 04 09:32:00 <yocti> New news from stackoverflow: Write a recipe in yocto for a python application <https://stackoverflow.com/questions/50436413/write-a-recipe-in-yocto-for-a-python-application>
Oct 04 10:32:55 <jofr> Do native recipe-names have to end with "-native"? i.e. is it a keyword or a convention?
Oct 04 10:33:22 <rburton> effectively, keyword
Oct 04 10:33:39 <rburton> easiest to make a general-purpose recipe foo.bb and use BBCLASSEXTEND=native
Oct 04 10:34:24 <jofr> Ok. I named it <foobar>-native_<version>.bb and inherited native.. is that wrong?
Oct 04 10:34:45 <rburton> that's the alternative if you'll never need a target or nativesdk version
Oct 04 10:35:30 <rburton> the usual case is that there's a chance you'll need a nativesdk or target variant at some point
Oct 04 10:36:32 <jofr> Nice. I won't.  :)  It's for a tool that generates boot-images, which require the deployed image-artifacts (tmp/deploy/images/<machine> stuff)
Oct 04 10:36:43 <jofr> s/I won't/It won't/
Oct 04 10:54:06 <kuzulis> Hi guys. I have created own layer 'foo'. And I want to create an image foo-image.bb which requires from the image of another layer 'bar'. So, I have added this line required recipes-qt/images/bar-image.bb to my foo-image.bb.
Oct 04 10:54:48 <kuzulis> But I got an error like: foo-image.bb: unparsed line: required recipes-qt/images/bar-image.bb
Oct 04 10:54:56 <kuzulis> why?
Oct 04 10:55:27 <kuzulis> All my layers are listed with bitbake-layers show-layers
Oct 04 10:57:33 <kuzulis> A bar-image.bb path is in: meta-bar-distro/recipes-qt/images/bar-image.bb
Oct 04 10:58:10 <rburton> did you really put 'required'?
Oct 04 10:58:30 <kuzulis> A foo-image.bb path is in: meta-foo/recipes-images/images/foo-image.bb
Oct 04 10:58:38 <rburton> the keyword is 'require'
Oct 04 10:59:31 <kuzulis> rburton: oops.. sorry. you are right.. many thanks :))
Oct 04 11:06:58 <sagner> Is a shared DL_DIR (running multiple independent bitbake at the same time with the same DL_DIR) safe?
Oct 04 11:07:11 <sagner> Looking through ML history seems to suggest so...
Oct 04 11:07:35 <sagner> We currently see issues with a particular git repo, and it seems quite reproducible...
Oct 04 11:08:21 <sagner> From what I read is that the lockfile should make sure that downloads are synchronized. But reading lib/bb/fetch2/ seems to suggest that not all fetchers use locking.../?
Oct 04 11:22:47 <kuzulis> Guys, is it possible to use a custom build systems to compile a recipes? e.g. I need to compile my application using QBS (from Qt).. Is it possible?
Oct 04 11:28:31 <LetoThe2nd> kuzulis: it certainly is, but be aware of cross-compilation issues and pollution
Oct 04 11:31:02 <kuzulis> As I understand, I need to add my custom /recipes-dev-tools/qbs, and then to build my application recipe, just write: inherit qbs ?
Oct 04 11:31:07 <kuzulis> Is it?
Oct 04 11:32:18 <LetoThe2nd> kuzulis: nah, this is no direct inheritance situation.
Oct 04 11:32:58 <kuzulis> LetoThe2nd: Is any guide/wiki to read about?
Oct 04 11:33:35 <kuzulis> LetoThe2nd: I mean how to create and use a custom build systems
Oct 04 11:33:53 <LetoThe2nd> kuzulis: if you just want to resort to two recipes, then need 1) the one for qbs, and make sure that it is native enabled. so it can run on the buildhost. and 2) the application recipe, which would DEPEND on qbs-native
Oct 04 11:35:42 <kuzulis> LetoThe2nd: What do you mean about 'depend on qbs-native' ? What is it?
Oct 04 11:36:56 <LetoThe2nd> kuzulis: hum, do you know what a DEPEND (the uppercase is intentional) in a recipe is?
Oct 04 11:39:23 <kuzulis> LetoThe2nd: Do you mean DEPENDS?
Oct 04 11:40:09 <kuzulis> LetoThe2nd: Do I need to add: DEPENDS = 'qbs-native' to my foo application recipe?
Oct 04 11:40:34 <LetoThe2nd> exatly. that tells bitbake that it needs to build qbs for the build host so your recipe can use it.
Oct 04 11:41:53 <kuzulis> LetoThe2nd: And, how then tell to my app to use the qbs? Do I need to write a some script in do_compile() of my foo application then?
Oct 04 11:42:09 <LetoThe2nd> kuzulis: exactly, thats what you need to do.
Oct 04 11:42:34 <kuzulis> LetoThe2nd: Ok, many thanks
Oct 04 11:44:06 <LetoThe2nd> kuzulis: here should be plenty of documentation: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-writing-a-new-recipe
Oct 04 11:45:08 <kuzulis> LetoThe2nd: Ok, thanks
Oct 04 12:40:01 <jofr> How can I define a recipe that depends on the built artifacts from another recipe(package)?
Oct 04 12:40:37 <jofr> do_install[depends] += "other_package"?
Oct 04 12:41:09 <jofr> or rather do_compile[depends] actually...
Oct 04 12:47:18 <zeddii> that's what DEPENDS in the recipe does
Oct 04 12:49:11 <jofr> Ok, I've tried that. Added both "virtual/bootloader" and "u-boot" (not at the same time) to DEPENDS, but I can't figure out how I can get those artifacts for my recipe to use them.. (u-boot.elf more specificially)
Oct 04 12:53:37 <zeddii> aha. so yes, it does depend on how you are using them.
Oct 04 12:53:53 <zeddii> if it is a library/build dependency, DEPENDS takes care of that.
Oct 04 12:54:36 <RP> jofr: its more likely that only certain kinds of build artefacts make it into the sysroot, headers libraries etc
Oct 04 12:54:37 <jofr> Ahh, I see. But if I have an exact file dependancy?
Oct 04 12:54:51 <RP> jofr: for u-boot you may want the output of its do_deploy task
Oct 04 12:55:00 <zeddii> if it is something else, you may have to populate the sysroot and have a different depends line
Oct 04 12:55:14 * zeddii lagged the answer there :D
Oct 04 12:55:20 <RP> do_compile[depends] += "u-boot:do_deploy"
Oct 04 12:55:36 <RP> or if its not a deploy artefact what zeddii said
Oct 04 12:55:43 <zeddii> kind of like we do in make-mod-scripts as another reference
Oct 04 12:55:45 <zeddii> recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb:do_configure[depends] += "virtual/kernel:do_shared_workdir openssl-native:do_populate_sysroot"
Oct 04 12:55:51 <RP> zeddii: FWIW DEPENDS works on do_configure, not compile ;-)
Oct 04 12:56:18 <zeddii> but will be in place for compile, since configure is first. which is what I was thinking :D
Oct 04 12:56:30 <RP> zeddii: indeed
Oct 04 13:02:22 <jofr> Ok. But I don't get any u-boot artifacts to the packages WORKDIR.. Do I reference those files (in the case the u-boot-files) differently?
Oct 04 13:02:53 <jofr> s/in the case/in this case/
Oct 04 13:04:04 <RP> jofr: it depends which task you're depending upon. do_deploy would put them in DEPLOY_DIR_xxx and the populate_sysroot would put them in ${WORKDIR}/recipe-sysroot or recipe-sysroot-native
Oct 04 13:16:15 <jofr> I see. In my case, ${DEPLOY_DIR_u-boot} resolves to "boot" .. that's not something my package can reference, can it? From my packages perspacitve this is WORKDIR/../../u-boot/1_2018.01-r0/image/boot or WORKDIR/../../u-boot/1_2018.01-r0/package/boot..
Oct 04 13:20:51 <jofr> This is interesting. DEPLOY_DIR_u-boot and DEPLOYDIR_u-boot are both "boot". But DEPLOYDIR and DEPLOY_DIR are not at all the same path. DEPLOY_DIR is actually my tmp/deploy directory. So I should be able to use ${DEPLOY_DIR}/images/u-boot.elf
Oct 04 13:22:51 <jofr> Sorry. ${DEPLOY_DIR}/images/${MACHINE}/u-boot.elf. Or is that horrible?
Oct 04 13:46:36 <JPEW> jofr: ${DEPLOY_DIR_IMAGE} is probably a better choice, but FWIW I've written recipes that pull things out of there before.
Oct 04 13:49:57 <tgoodwin> Anyone familiar with systemd-initramfs? I've installed it into my initrd image as well as an /etc/initramfs-release (per the docs, required for initrd detection), but systemd doesn't switchroot; instead it drops to a prompt like it reached multi-user.
Oct 04 13:53:42 <jofr> JPEW: Good point. Then I don't have to formulate the path myself with by adding the images/${MACHINE} myself. And it's good to know that there are other people who have pulled stuff from there  ;)
Oct 04 13:55:02 <JPEW> jofr: I can't comment that it is really the "right" way to do things, but it seems to work OK for us, as long as you add the do_<task>[depends] += "u-boot:do_deploy"
Oct 04 13:55:32 <jofr> "If it works, it ain't stupid."  ;)
Oct 04 13:55:39 <jofr> But I know what you mean.
Oct 04 15:21:01 <kuzulis> Guys, I'm try to add my custom recipe with Git access.. A Git URL in our private repo, like: "git@<host>:<user>/<project-name>.git". But when I add this as SRC_URI = "git://git@<host>:<user>/<project-name>.git;branch=${BRANCH};protocol=ssh" then bitbake fails with: ssh: Could not resolve hostname <host>:<user>: Name or service not known
Oct 04 15:21:05 <kuzulis> why?
Oct 04 15:21:26 <kuzulis> If I run same URL from the server's command line then it fine
Oct 04 15:21:50 <kuzulis> like: git clone git@<host>:<user>/<project-name>.git
Oct 04 15:25:51 <JPEW> kuzulis: Are you using SSH when you clone locally: git clone ssh://git@<host>:<user>/<project-name>.git ?
Oct 04 15:26:27 <kuzulis> JREW: Ahh.. I found out why it fails
Oct 04 15:27:23 <kuzulis> JREW: Need: SRC_URI = "git://git@<host>/<user>/irp-touch.git;branch=${BRANCH};protocol=ssh" .. i.e. replace : with /
Oct 04 15:27:58 <JPEW> kuzulis: Ah, that would do it :)
Oct 04 15:33:15 <yocti> New news from stackoverflow: Is Ubuntu 18.04.1 LTS compatible with Yocto Sumo 2.5.1? <https://stackoverflow.com/questions/52650016/is-ubuntu-18-04-1-lts-compatible-with-yocto-sumo-2-5-1>
Oct 04 16:10:40 <khem> RP: whats tools do you use to merge bitbake and oe-core to form poky
Oct 04 16:16:29 <rburton> khem: combo-layer
Oct 04 16:18:38 * armpit aren't we all tools ?
Oct 04 16:19:04 <fray> armpit, some of us are finely crafted...
Oct 04 16:19:04 <kergoth> ha, today's free packt ebook is about yocto - https://www.packtpub.com/packt/offers/free-learning
Oct 04 16:20:21 <RP> khem: as rburton says, combo-layer
Oct 04 16:20:50 <rburton> kergoth: "updated for morty"
Oct 04 16:21:10 * Crofton has grown to not hate submodules
Oct 04 16:23:41 <kergoth> rburton: ha
Oct 04 16:52:21 <JaMa> Crofton_: looks like you've sent whole sip patch as one line :)
Oct 04 16:52:25 <khem> rburton: my distro uses gitsm
Oct 04 16:52:30 <khem> and it works fine
Oct 04 16:57:09 <JaMa> kergoth: thanks! sent to colleagues to fetch it while it's free :)
Oct 04 17:15:33 <Crofton> JaMa, git send email?
Oct 04 17:15:37 <Crofton> cut and paste from readme
Oct 04 17:16:39 <Crofton> JaMa, seems ok to me
Oct 04 17:32:22 <JaMa> Crofton: "[oe] [meta-oe][PATCH 2/2] sip: Add python3 version of the sip recipe." looks OK, but "[oe] [meta-oe][PATCH 1/2] sip: Update to 4.19.13.
Oct 04 17:32:47 <JaMa> " has the patch as attachment and the whole body is shown as one really big line in gmail (looks ok in mutt)
Oct 04 17:34:24 <JaMa> Crofton: both are text/plain, not sure what caused gmail to mess it so badly
Oct 04 17:35:53 <Crofton> one has a huge patch
Oct 04 17:36:10 <Crofton> that was basically updating versus their Hg
Oct 04 17:38:03 <Crofton> Now back on real release that builds without silly patching :)
Oct 04 17:38:15 <Crofton> the ptyhon3 API var confuses me
Oct 04 18:03:47 <yocti> New news from stackoverflow: Yocto - can not execute debug package <https://stackoverflow.com/questions/52652580/yocto-can-not-execute-debug-package>
Oct 04 20:49:43 <derRichard> is linux-dummy.bb broken in openembedded-core sumo? it fails with ...make-mod-scripts_1.0.bb depends upon non-existent task do_compile_kernelmodules...
Oct 04 20:50:02 <derRichard> adding a dummy do_compile_kernelmodules task to linux-dummy.bb solves the problem
Oct 04 21:58:40 <lukma> If I may ask
Oct 04 21:59:01 <lukma> What is the scope of PACKAGE_EXCLUDE when used inside a recipe (to build image)
Oct 04 21:59:29 <lukma> do I need to add PACKAGE_EXCLUDE_pn-${PN} = "foo" to not pollute the name space?
Oct 04 21:59:38 <lukma> when I do want to exclude "foo" ?
Oct 04 22:58:21 <peniwize> Step 5 in section 3.30.13. "Debugging With the GNU Project Debugger (GDB) Remotely" in the Yocyo mega manual says "source the correct environment file".  Does anyone know where that file is or where I might start looking?
**** ENDING LOGGING AT Fri Oct 05 03:00:01 2018