**** BEGIN LOGGING AT Tue Jun 25 03:00:38 2019
Jun 25 08:54:59 <zkrx> my build failed because of one non-important recipe. I want to remove the recipe and finish the build (without rebuilding everything). How do I do this?
Jun 25 08:56:28 <zkrx> I added IMAGE_INSTALL_remove += "recipe" into my image.bb but relaunching bitbake still tries to build the offending recipe
Jun 25 09:15:27 <yocti> New news from stackoverflow: Yocto - Prevent external source from re-executing all action in every build <https://stackoverflow.com/questions/56750277/yocto-prevent-external-source-from-re-executing-all-action-in-every-build>
Jun 25 09:18:36 <qschulz> zkrx: is the package referenced in any RDEPENDS or DEPENDS of any package in the image (or pulled by any package that have an (R)DEPENDS on the latter)?
Jun 25 09:22:57 <zkrx> qschulz: it is psplash which seems to be pulled-in by poky/meta. I had a psplash.bbappend which caused the error. I renamed it to psplash.bbappend.bkp and it seems to build fine now.
Jun 25 09:23:12 <zkrx> qschulz: is there any way to disable a recipe without renaming it like I just did?
Jun 25 09:23:52 <qschulz> zkrx: well, tbh, I don't know.
Jun 25 09:24:07 <qschulz> if it is pulled by DEPENDS/RDEPENDS
Jun 25 09:24:27 <qschulz> you have to backtrack the dependencies and find out who pulled it to disable this package from the image
Jun 25 09:24:41 <qschulz> but that might not be easy, even impossible sometimes
Jun 25 09:25:12 <qschulz> if it's just in IMAGE_INSTALL, CORE_EXTRA_IMAGE_INSTALL or similar, you can remove it from there (though, if it's pulled by another package, that's not enough)
Jun 25 09:25:26 <qschulz> you also have RRECOMMENDS mechanism, in which case you can play with BAD_RECOMMENDATIONS
Jun 25 09:26:50 <zkrx> qschulz: nice, thanks for the precisions
Jun 25 09:27:43 <qschulz> zkrx: there may exist other mechanisms I'm not aware of. I'm only a user of Yocto, so that's everything that's going through my mind right now
Jun 25 09:30:47 <zkrx> qschulz: sure, I'm just starting out so I had to ingest a lot of information at once.
Jun 25 09:31:33 <qschulz> zkrx: it's normal don't worry, the learning curve is quite steep at the beginning since there are so much flexibility in Yocto
Jun 25 09:45:34 <yocti> New news from stackoverflow: Yocto Image does not boot from HDD <https://stackoverflow.com/questions/56750800/yocto-image-does-not-boot-from-hdd>
Jun 25 09:46:15 <kayterina[m]> to build an rpi3 image for qemu, the correct options is $MACHINE=qemuarm or $MACHINE=qemux86-64 ?
Jun 25 10:04:38 <Chaser> Hello, any ideas why bitbake fails if I sshfs mount my entire workspace onto a different machine ? I sshfs entire workspace to a different machine and did the setup.sh and I get "unable to connect to bitbake server or start one"
Jun 25 10:04:53 <Chaser> How do you guys usually mount your source tree on to a different machine to run bitbake stuff ?
Jun 25 10:30:02 <Chaser> hmm I realized that you can't create domain socket files on sshfs mounted filesystem.
Jun 25 11:13:47 <kanavin> RP: AUH seems very slow, should I ping Michael about it? e.g: 0: python3-native-3.7.3-r0 do_populate_sysroot - 22m11s (pid 29827)
Jun 25 11:17:18 <RP> kanavin: michael is the person to ask, yes
Jun 25 11:19:21 <kanavin> he's not online right now though?
Jun 25 11:20:44 <Crofton> Still 0420 for him
Jun 25 11:20:51 <kanavin> halstead, AUH seems very slow, e.g. 0: python3-native-3.7.3-r0 do_populate_sysroot - 22m11s (pid 29827)
Jun 25 11:21:16 <kanavin> auh.yoctoproject.org that is
Jun 25 11:25:14 <qschulz> kayterina[m]: quemux86-64 is for 64b Intel platforms AFAIK. So definitely not this one :)
Jun 25 11:27:50 <qschulz> Question: what is the LICENSE variable in a packagegroup supposed to represent? I can't grasp the concept of having a license on something that is "virtual", it's just a set of software with nothing else added to it and each of the packages in this packagegroup have their own license anyway.
Jun 25 11:28:12 <qschulz> What am I missing/do not know?
Jun 25 11:51:38 <rburton> qschulz: everything needs a license.  the license of a packagegroup is typically MIT (as set by the class), so there's no restrictions on the empty packages it generates
Jun 25 11:56:17 <kanavin> RP: do you have a moment to talk about a useradd issue I am trying to sort? we have recipes that create groups, and dependent recipes that create users that are members of those groups. This works fine when building from scratch. However when sstate is available, the following errors are seen:
Jun 25 11:56:34 <kanavin> NOTE: Executing SetScene Tasks
Jun 25 11:56:34 <kanavin> ERROR: media-system-git-r0 do_package_setscene: media-system: useradd command did not succeed.
Jun 25 11:56:34 <kanavin> WARNING: Logfile for failed setscene task is /home/alexander/development/mbient/build-thud-jetson/tmp/work/aarch64-mbient-linux/media-system/git-r0/temp/log.do_package_setscene.45546
Jun 25 11:56:34 <kanavin> WARNING: Setscene task (/home/alexander/development/mbient/build-thud-jetson/../sources/meta-mbient/meta-mbient/recipes-media/media-system/media-system_git.bb:do_package_setscene) failed with exit code '1' - real task will be run instead
Jun 25 11:58:43 <kanavin> what is the correct way to set things up in this scenario?
Jun 25 12:00:18 <kanavin> basically it seems that things that media-system depends on for group creation do not populate sysroot properly (e.g. beforehands) here
Jun 25 12:01:57 <qschulz> rburton: I understand. But is there any reason to modify the default MIT license then?
Jun 25 12:03:55 <RP> kanavin: is there an open bug for this?
Jun 25 12:04:42 <RP> hmm, think I'm thinking of bug 13279
Jun 25 12:04:43 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13279 normal, Medium+, 2.8 M1, peter.kjellerstedt, NEW , Make sure users/groups exist for package_write_* tasks
Jun 25 12:04:55 <kanavin> RP: I am not sure, it's just something I am seeing in our private builds since component teams started adding users instead of running all things as root
Jun 25 12:09:07 <RP> kanavin: not sure if its related to that bug or not
Jun 25 12:15:03 <kanavin> RP: also, useradd.bbclass has a fix for this, but only for a hardcoded package set:
Jun 25 12:15:04 <kanavin> do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
Jun 25 12:15:04 <kanavin> do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
Jun 25 12:15:04 <kanavin> USERADDSETSCENEDEPS_class-target = "${MLPREFIX}base-passwd:do_populate_sysroot_setscene pseudo-native:do_populate_sysroot_setscene shadow-native:do_populate_sysroot_setscene ${MLPREFIX}shadow-sysroot:do_populate_sysroot_setscene"
Jun 25 12:15:04 <kanavin> USERADDSETSCENEDEPS = ""
Jun 25 12:15:50 <kanavin> basically, this ensures that at least the basic users/groups are properly restored, but I need this for custom packages as well
Jun 25 12:16:00 <RP> kanavin: those are the tools/base files needed. the rest should come from other dependencies
Jun 25 12:17:08 <RP> kanavin: What dependencies exist between your two recipes?
Jun 25 12:18:03 <kanavin> RP: DEPENDS
Jun 25 12:21:42 <rburton> qschulz: no
Jun 25 12:21:51 <RP> kanavin: I've just looked at some old notes and DEPENDS should work, I don't remember how though
Jun 25 12:22:08 <qschulz> rburton: alrighty then. Thanks :)
Jun 25 12:22:09 <kanavin> RP: media-system has "DEPENDS = thriftme" - this works in a clean build, but breaks when running setscene, as the package_setscene for media-system runs before populate_sysroot_setscene for thriftme
Jun 25 12:22:42 <kanavin> RP: NOTE: Running setscene task 1 of 353 (/home/alexander/development/mbient/build-thud-jetson/../sources/poky/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb:do_populate_sysroot_setscene)
Jun 25 12:22:42 <kanavin> NOTE: Running setscene task 2 of 353 (virtual:native:/home/alexander/development/mbient/build-thud-jetson/../sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
Jun 25 12:22:43 <kanavin> NOTE: Running setscene task 3 of 353 (virtual:native:/home/alexander/development/mbient/build-thud-jetson/../sources/poky/meta/recipes-extended/shadow/shadow_4.6.bb:do_populate_sysroot_setscene)
Jun 25 12:22:46 <kanavin> NOTE: Running setscene task 4 of 353 (/home/alexander/development/mbient/build-thud-jetson/../sources/poky/meta/recipes-extended/shadow/shadow-sysroot_4.6.bb:do_populate_sysroot_setscene)
Jun 25 12:22:49 <kanavin> NOTE: recipe shadow-sysroot-4.6-r3: task do_populate_sysroot_setscene: Started
Jun 25 12:22:51 <kanavin> NOTE: recipe base-passwd-3.5.29-r0: task do_populate_sysroot_setscene: Started
Jun 25 12:22:53 <kanavin> NOTE: recipe pseudo-native-1.9.0+gitAUTOINC+3fa7c853e0-r0: task do_populate_sysroot_setscene: Started
Jun 25 12:22:55 <kanavin> NOTE: recipe shadow-native-4.6-r0: task do_populate_sysroot_setscene: Started
Jun 25 12:22:57 <kanavin> NOTE: recipe shadow-sysroot-4.6-r3: task do_populate_sysroot_setscene: Succeeded
Jun 25 12:22:59 <kanavin> NOTE: recipe base-passwd-3.5.29-r0: task do_populate_sysroot_setscene: Succeeded
Jun 25 12:23:01 <kanavin> NOTE: recipe pseudo-native-1.9.0+gitAUTOINC+3fa7c853e0-r0: task do_populate_sysroot_setscene: Succeeded
Jun 25 12:23:03 <kanavin> NOTE: recipe shadow-native-4.6-r0: task do_populate_sysroot_setscene: Succeeded
Jun 25 12:23:05 <kanavin> NOTE: Running setscene task 5 of 353 (/home/alexander/development/mbient/build-thud-jetson/../sources/meta-mbient/meta-mbient/recipes-media/media-system/media-system_git.bb:do_package_setscene)
Jun 25 12:23:08 <kanavin> NOTE: recipe media-system-git-r0: task do_package_setscene: Started
Jun 25 12:23:10 <kanavin> WARNING: Logfile for failed setscene task is /home/alexander/development/mbient/build-thud-jetson/tmp/work/aarch64-mbient-linux/media-system/git-r0/temp/log.do_package_setscene.49638
Jun 25 12:23:15 <kanavin> WARNING: Setscene task (/home/alexander/development/mbient/build-thud-jetson/../sources/meta-mbient/meta-mbient/recipes-media/media-system/media-system_git.bb:do_package_setscene) failed with exit code '1' - real task will be run instead
Jun 25 12:23:15 <RP> kanavin: so its really a setscene ordering issue?
Jun 25 12:23:22 <RP> kanavin: pastebin ;-)
Jun 25 12:23:36 <kanavin> sorry :) yes, it seems a setscene ordering problem
Jun 25 12:24:20 <kanavin> thriftme needs to come before media-system, together with all those 'base' recipes at the top
Jun 25 12:28:43 <RP> kanavin: I had a testcae for something like this locally. Just dusted it off but its behaving oddly :/
Jun 25 12:30:47 <kanavin> RP: I also added explicit dependencies to see if that helps, like this:
Jun 25 12:30:49 <kanavin> do_package_setscene[depends] += "thriftme:do_populate_sysroot_setscene"
Jun 25 12:30:49 <kanavin> do_populate_sysroot_setscene[depends] += "thriftme:do_populate_sysroot_setscene"
Jun 25 12:33:47 <kanavin> RP: nope, same issue, and thriftme task still does not run before media-system
Jun 25 12:35:23 <RP> kanavin: I think I'm not seeing this due to only having one group for my test and that group matches my local user's gid
Jun 25 12:41:50 <RP> kanavin: am I right in thinking that media-system also adds users/groups?
Jun 25 12:42:24 <kanavin> it does, yes, like this: USERADD_PACKAGES = "${PN}"
Jun 25 12:42:24 <kanavin> # USERADD_PARAM specifies command line options to pass to the useradd
Jun 25 12:42:24 <kanavin> # command. GROUPADD_PARAM works the same way for groupadd command.
Jun 25 12:42:24 <kanavin> GROUPADD_PARAM_${PN} = "${PLAYER_GROUP} ; ${CLIENT_GROUP}"
Jun 25 12:42:24 <kanavin> USERADD_PARAM_${PN} = "--no-create-home --gid ${PLAYER_GROUP} --shell /bin/false -G ${SUPPLEMENTARY_GROUPS} ${PLAYER_USER}"
Jun 25 12:42:45 <kanavin> it is the SUPPLEMENTARY_GROUPS where the issue happens, as they have to exist, or useradd will fail
Jun 25 12:42:56 <kanavin> SUPPLEMENTARY_GROUPS = "trace,thriftme,audio"
Jun 25 12:43:19 <RP> kanavin: right, that is the key thing to reproduce it I think
Jun 25 12:43:45 <RP> kanavin: PN A which has user creation dependent on groups from PN B
Jun 25 12:44:22 <RP> kanavin: bingo, reproduced
Jun 25 12:46:36 <kanavin> RP: cheers!
Jun 25 12:47:30 <RP> kanavin: did you try do_package_setscene[depends] += "thriftme:do_package_setscene" ?
Jun 25 12:48:03 <rburton> RP: what's going on with the perf machines?  charts are all over the place
Jun 25 12:48:17 <RP> rburton: no idea, not looked :(
Jun 25 12:49:28 <RP> rburton: which ones? they don't look too bad to me?
Jun 25 12:50:25 <rburton> oh!
Jun 25 12:50:30 <rburton> you know i failed to look at my calendar
Jun 25 12:50:31 <rburton> we can :)
Jun 25 12:50:41 <kanavin> RP: will try now
Jun 25 12:51:08 <RP> rburton: wrong window :)
Jun 25 12:51:14 <rburton> yeah i noticed ;)
Jun 25 12:52:01 <rburton> luckily we didn't make public the secret cabal that controls OE on public irc
Jun 25 12:54:16 <RP> rburton: narrow escape :)
Jun 25 12:54:27 <rburton> *phew*
Jun 25 12:55:04 <RP> kanavin: I think this setscene dependency doesn't work because of some logic somewhere which says do_package dependencies aren't important
Jun 25 12:55:10 <RP> kanavin: where we put that, I don't remember
Jun 25 12:56:08 <RP> kanavin: ah, setscene_depvalid() in sstate.bbclass
Jun 25 12:56:30 <kanavin> RP: is this related by any chance? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/sstate.bbclass#n1014
Jun 25 12:56:30 <RP> kanavin: "do_package doesn't need do_package"
Jun 25 12:56:56 <RP> kanavin: also see the useradd comment which I think is most relavent
Jun 25 12:57:37 <RP> kanavin: so yes, there is a bug and we hacked this in the past to get the basics working :/
Jun 25 13:02:21 <kanavin> RP: I am struggling to find a workaround for this though :-(
Jun 25 13:03:03 <kanavin> RP: adding task dependencies manually just does not seem to have any effect at all
Jun 25 13:05:41 <RP> kanavin: see the code in sstate.bbclass, that will overrule them
Jun 25 13:06:06 <RP> kanavin: its going to be an awkward one to fix :(
Jun 25 13:08:21 <kanavin> RP: I vaguely remember that adding manual dependecies used to work in older yocto releases, like morty or something like this
Jun 25 13:09:25 <kanavin> RP: I did this fix for one of them and it worked: USERADDSETSCENEDEPS_append_class-target = " ${MLPREFIX}populate-system-users-groups:do_populate_sysroot_setscene"
Jun 25 13:09:32 <kanavin> no longer the case :(
Jun 25 13:09:52 <kanavin> (USERADDSETSCENEDEPS is then picked up by useradd.bbclass)
Jun 25 13:56:20 <JPEW> Is there a way to mark a QA test as "manual" (e.g. won't run on the autobuilder, but will run if explicitly requested?)
Jun 25 14:17:22 <JPEW> nm, I figured out a better way
Jun 25 14:47:57 <RP> armpit: ahhrg. I was just about to do some debugging with the autobuilder! :/
Jun 25 14:48:27 <armpit> RP, you can kill it
Jun 25 14:48:46 <RP> armpit: may as well let it run now, I'll do other things
Jun 25 14:49:31 <RP> armpit: I was going to try getting a profile for stopping a build, see if we could spot the performance bottleneck
Jun 25 14:49:55 * zeddii seems to have written some anonymous python that self basehash corrupts!
Jun 25 14:50:10 <zeddii> I've only ever triggered that before when I edit a recipe while it is building :D
Jun 25 14:50:48 <armpit> so much for patching while building ; )
Jun 25 14:50:56 <zeddii> that's fun too!
Jun 25 14:51:38 <RP> zeddii: nice. with memres bitbake it could now detect the changed files and abort the build
Jun 25 14:55:22 <RP> armpit: I may be able to test this in parallel with your build. Apologies in advance if I do break things ;-)
Jun 25 14:58:52 <zeddii> RP: Cool. At least it is currently telling me that I'm being evil. I may just have to abort on the "feature" I was trying to add for an optional post-install rule. Since it is definitely not happy with me assigning it in the python
Jun 25 14:59:05 * zeddii has a conflict and can't make the Yocto meeting in 1 minute.
Jun 25 15:00:03 <LetoThe2nd> zeddii: hooray for being evil!
Jun 25 15:09:33 <elcapbrown> Does anyone know if there's a bsp layer I can get for the imx 1052?
Jun 25 15:11:45 <LetoThe2nd> elcapbrown: http://layers.openembedded.org/layerindex/branch/master/machines/?page=1&q=imx&search=1 is your best bet, but probably no
Jun 25 15:15:05 <elcapbrown> Looking now... I mean I have the kernel configs and dts files etc that are needed for the kernel to run on the board but I need a framework to start from.  Too many options I'm unfamiliar with like DEFAULTTUNE TUNE_PKGARCH.  I don't know what groupings I would need.
Jun 25 15:15:18 <armpit> RP, the thud-nmut has the latest uniative changes
Jun 25 15:15:35 <RP> armpit: cool
Jun 25 15:16:26 <armpit> thats what is building now
Jun 25 15:16:35 <yocti> New news from stackoverflow: Yocto Warrior Custom Bitbake Recipe for Custom Python Wheel file cannot install because pip3 not found <https://stackoverflow.com/questions/56757032/yocto-warrior-custom-bitbake-recipe-for-custom-python-wheel-file-cannot-install>
Jun 25 15:19:21 <LetoThe2nd> elcapbrown: in that case, just grab some bsp where the layer has as little magic as possible and inject or pwn
Jun 25 15:19:42 <LetoThe2nd> elcapbrown: linux-yocto-custom is usually a good starting point, as well as the dev manual
Jun 25 15:20:40 <elcapbrown> LetoThe2nd:  Thanks.  I'd like to do just that.  I just need to start with something close enough.  I'll try with one of the machines on that link you gave...
Jun 25 15:22:43 <LetoThe2nd> elcapbrown: you don't even need one of those, that was just for the imx thing. pick something from the machines that just looks simple
Jun 25 15:26:09 <elcapbrown> LetoThe2nd: Thanks again, I'll give it a try.
Jun 25 15:40:17 <tgoodwin> Has anyone seen the quilt-native recipe fail on thud for being unable to import the oe.patch module?  The host is CentOS 7, python3 3.4.9.  I can't replicate it on Ubuntu 18.04.
Jun 25 15:46:13 <moto-timo> tgoodwin: just a hunch, but you need to install python36 instead of python34
Jun 25 15:46:31 <moto-timo> tgoodwin: python 3.5+ is generally required
Jun 25 15:47:00 <moto-timo> err. but I forget what is required on thud... I live on master 99.99% of the time
Jun 25 15:47:28 <tgoodwin> moto-timo: interesting; the mega-manual for 2.6.2 shows installing python34-pip.
Jun 25 15:47:48 <moto-timo> tgoodwin: yeah, might be a red herring. sorry
Jun 25 15:48:16 <tgoodwin> No problem; I'm going to see if I can replicate this on a fresh VM.  The user's environment might just be messed up.
Jun 25 15:48:43 <moto-timo> have them run bitbake -DDDD so they get lots of debug info ;)
Jun 25 15:49:02 <moto-timo> and tee that to a log file so you have something to work with
Jun 25 15:55:23 <halstead> kanavin, There is another guest on that hypervisor that is competing for resources. I'll move it off and see if that helps.
Jun 25 15:59:47 <kanavin> halstead, thanks - things are running, but it is rather slow
Jun 25 16:00:42 <tgoodwin> moto-timo: thanks for the suggestion.  It ended up being that his bblayers defined the poky layers with a relative path (i.e., each began with ../<something>).  Once those were absolute, it worked fine.
Jun 25 16:16:45 <yocti> New news from stackoverflow: Branching a meta layer according to Yocto branches <https://stackoverflow.com/questions/56757873/branching-a-meta-layer-according-to-yocto-branches>
Jun 25 16:27:59 <kanavin> RP: I found a workaround for the useradd sstate failure: things seem to work if the groups are re-created from the dependent recipe (the creation is skipped if those groups already exist)
Jun 25 16:28:20 <kanavin> e.g. adding them to GROUPADD_PARAM seems to solve the issue
Jun 25 16:36:38 <RP> kanavin: not ideal but probably would work relatively harmlessly
Jun 25 16:36:48 <RP> kanavin: we should have a bug so we don't forget this
Jun 25 16:46:01 <kanavin> RP: yes, I will take care of all this tomorrow :)
Jun 25 16:47:12 <RP> kanavin: thanks
Jun 25 16:53:28 <litb> hello all
Jun 25 16:54:00 <litb> currently our debian-embedded-system can update itself by using apt-get update, and update our applications file-based to /ourcompany-software   within the embedded device
Jun 25 16:56:47 <litb> i understand that with yocto, "devtool deploy  <imagerecipe>" is not supported, probably also won't work
Jun 25 16:57:11 <litb> is it possible to do the same in a different way? I.e update the root-fs, copying only the files that changed?
Jun 25 17:18:07 <RP> armpit: you're seeing the same pigz thread errors in thud as we're seeing on master  :(
Jun 25 17:18:23 <RP> armpit: we're increasing open file limits to see if that helps.
Jun 25 17:19:02 <armpit> yeah, when pigz fly
Jun 25 17:20:10 <armpit> is it the selftest or one of the others?
Jun 25 17:22:12 <armpit> found it
Jun 25 17:34:08 <litb> hm, how can I make the eSDK keep the .git directories for <sdk install path>/layers  ?
Jun 25 17:34:38 <litb> because when I change recipes, "devtool finish" them, i want to push the changes i made to them to our layer repositories. but I found that <sdk install path>/layers aren't git repositories anymore
Jun 25 18:17:05 <yocti> New news from stackoverflow: How can I push changes to yocto recipes in eSDK back into layers? <https://stackoverflow.com/questions/56759815/how-can-i-push-changes-to-yocto-recipes-in-esdk-back-into-layers>
Jun 25 20:26:24 <Kobboi> my custom kernel is stored in a subdirectory of a git repo, not in the root. which variables do i change in the .bbappend to make this work?
Jun 25 20:37:26 <bluelightning> Kobboi: you can include ;subpath=subdirname in the SRC_URI entry pointing to the repo
Jun 25 20:37:45 <bluelightning> Kobboi: note that subdirname should *not* start with /
Jun 25 20:38:18 <Kobboi> bluelightning: do note that i think the toplevel directories are needed when actually compiling (it's a crappy delivery)
Jun 25 20:38:37 <Kobboi> bluelightning: am i correct to assume that your include will just "limit" the clone?
Jun 25 20:38:38 <bluelightning> hmm, ok
Jun 25 20:38:46 <bluelightning> yes it will, so that won't work for this
Jun 25 20:38:57 <Kobboi> bluelightning: np, thanks for trying to help out
Jun 25 20:39:05 <bluelightning> there is an alternative, one sec
Jun 25 20:39:28 <bluelightning> Kobboi: I think you'd just set S = "${WORKDIR}/git/subdirname" then
Jun 25 20:39:37 <Kobboi> and keep B to the default?
Jun 25 20:39:55 <bluelightning> I *think* so
Jun 25 20:40:35 <Kobboi> the default B was B = "${WORKDIR}/linux-${PACKAGE_ARCH}_${LINUX_KERNEL_TYPE}, so I tried setting it to B = "${WORKDIR}/linux-${PACKAGE_ARCH}_${LINUX_KERNEL_TYPE/my/path but it looks like I'm confusing some of these variables
Jun 25 20:41:01 <Kobboi> I will try your suggestion, if you have some interesting docs to read (or code even), feel free to point me to them
Jun 25 20:41:26 <Kobboi> very new to all of this (I *am* a Gentoo user, so the whole recipe thing does feel very familiar)
Jun 25 20:41:31 <bluelightning> B is set to build in a separate directory for the kernel, unless that doesn't work for whatever you're building it's best to leave it at that
Jun 25 20:41:51 <bluelightning> right yes the recipe syntax was based on ebuild format (a long time ago)
Jun 25 20:42:05 * bluelightning was also a gentoo user back in the day
Jun 25 20:42:37 * Kobboi never tried anything else since 2004 (and boy was it a steep ladder to climb, being unfamiliar with anything Linux)
Jun 25 20:43:27 <Kobboi> where is the default for S set?
Jun 25 20:44:36 <Kobboi> or are there some verbosity/debugging tricks you can teach me?
Jun 25 20:44:37 <bluelightning> bitbake -e virtual/kernel | less and then search for S=
Jun 25 20:45:15 <bluelightning> so looking at that there might be some trouble given that we try to unpack the source to a shared location
Jun 25 20:45:55 <Kobboi> i'm not even allowed to set S in the .bb file (unparsed line: 'S = ${WORKDIR}/git/kernel/linux-4.1')
Jun 25 20:46:46 <bluelightning> Kobboi: the value needs quotes around it ;)
Jun 25 20:47:05 <Kobboi> oops, sorry for making basic mistakes :/
Jun 25 20:47:08 <bluelightning> np
Jun 25 20:47:56 <bluelightning> actually I think there is some logic that will allow setting S this way, so it should work
Jun 25 20:48:05 <bluelightning> regardless of shared source tree stuff
Jun 25 20:53:22 <Kobboi> bluelightning: doesn't seem to work, I get a python FileNotFound exception triggered by do_unpack for the directory I am appending to S
Jun 25 21:01:16 <bluelightning> Kobboi: hmm... have a look under ${WORKDIR}/git and see if things match what you expect
Jun 25 21:02:31 <Kobboi> bluelightning: just to be sure, does it matter that i'm on morty?
Jun 25 21:02:50 <bluelightning> don't think so, I don't think any of this is recent
Jun 25 21:03:07 <bluelightning> (changed recently, I mean)
Jun 25 21:11:01 <Kobboi> Mylene: btw, thx for your talk on youtube, gave me the courage to try this
Jun 25 21:17:35 <yocti> New news from stackoverflow: InfluxDB recipe for Yocto Fails with devtool workflow in Rocko <https://stackoverflow.com/questions/56761899/influxdb-recipe-for-yocto-fails-with-devtool-workflow-in-rocko>
Jun 26 02:11:17 <sathish25071992> Hi,
Jun 26 02:15:41 <sathish25071992> We have a yocto bud system which is of version thud. We need to add a vendor layer which only supports morty. This vendor layer is required in order to build image for one of our custom board. So what is the best way to handle this situation? Will running 2 different yocto version is correct way or another method or procedure is there to handle the
Jun 26 02:15:41 <sathish25071992> se kind of situation? . We are pretty new to yocto so please help us on the same
Jun 26 02:48:24 <yocti> New news from stackoverflow: systemd ignores services from overlayFS <https://stackoverflow.com/questions/49697614/systemd-ignores-services-from-overlayfs>
**** ENDING LOGGING AT Wed Jun 26 02:59:57 2019