**** BEGIN LOGGING AT Thu Dec 06 03:00:01 2018
Dec 06 03:32:30 <yocti> New news from stackoverflow: bitbake error does not apply (enforce with -f)? <https://stackoverflow.com/questions/53644090/bitbake-error-does-not-apply-enforce-with-f>
Dec 06 06:03:01 <yocti> New news from stackoverflow: Create a read-only file in yocto <https://stackoverflow.com/questions/53645447/create-a-read-only-file-in-yocto>
Dec 06 07:03:11 <yocti> New news from stackoverflow: How to setup an Yocto recipe to build from a local git source? <https://stackoverflow.com/questions/49535881/how-to-setup-an-yocto-recipe-to-build-from-a-local-git-source>
Dec 06 07:33:17 <yocti> New news from stackoverflow: What is RPROVIDES for uhttpd in core-image-sato? <https://stackoverflow.com/questions/53646370/what-is-rprovides-for-uhttpd-in-core-image-sato>
Dec 06 08:14:53 <afsfs> hello
Dec 06 08:33:45 <nerdboy> i'm getting this e2fsprogs fail on morty:   ../lib/libext2fs.so: error: undefined reference to 'major'
Dec 06 08:34:07 <nerdboy> isn't util-linux supposed to be defining that?
Dec 06 08:38:00 <nerdboy> er, that should be e2fsprogs-native
Dec 06 08:46:31 <JaMa> nerdboy: upgrade to latest morty
Dec 06 08:53:10 <nerdboy> i just cloned latest earlier tonight
Dec 06 08:54:01 <nerdboy> anyways, i just made a patch
Dec 06 08:55:42 <nerdboy> i cant pull until i commit...
Dec 06 08:58:15 <nerdboy> says poky/morty is Already up to date.
Dec 06 10:31:28 <eduardas_m> hello, I am trying to address feedback on my mksh recipe: http://lists.openembedded.org/pipermail/openembedded-devel/2018-December/197780.html
Dec 06 10:31:49 <eduardas_m> how do I define the ISC license to be applicable only when glibc is in use
Dec 06 10:31:56 <eduardas_m> ?
Dec 06 10:37:20 <LetoThe2nd> eduardas_m: probably by using an evaluation in the license statement instead of an assigment? (just guessing!)
Dec 06 10:38:22 <eduardas_m> LetoThe2nd: evaluation statements are possible when setting bitbake variables?
Dec 06 10:43:31 <LetoThe2nd> yeah, should be. equivalent example for INHIBIT_PACKAGE_STRIP: https://patchwork.openembedded.org/patch/80375/
Dec 06 10:55:52 <T_UNIX> hi
Dec 06 10:56:01 <LetoThe2nd> lo
Dec 06 10:58:12 <T_UNIX> has there been any talk/slides on using yocto with a git-flow like approach? I.e. feature integration without having to rebuild *everything* for each branch?
Dec 06 10:59:47 <LetoThe2nd> T_UNIX: not sure if i understand the question
Dec 06 11:00:31 <T_UNIX> assume it's infeasible (due to limited resources) to rebuild an entire image for every feature branch.
Dec 06 11:01:00 <RP> nerdboy: I have a hunch you may need the latest uninative version which morty no longer gets updates for
Dec 06 11:01:03 <LetoThe2nd> T_UNIX: due to sstate, only things that actually are affected of changes should be rebuilt
Dec 06 11:01:38 <RP> nerdboy: assuming you are using uninative and are running on a recent distro which morty wasn't originally tested with
Dec 06 11:01:52 <LetoThe2nd> T_UNIX: so if switching branches triggers a complete rebuild, then you are modifying something with a lot of effects - be in voluntarily or involuntarily
Dec 06 11:02:39 <LetoThe2nd> s/be in/be it/
Dec 06 11:03:09 <T_UNIX> LetoThe2nd: I'm wondering about interference
Dec 06 11:03:38 <LetoThe2nd> T_UNIX: and i'm wondering about half-sentences, to be honest.
Dec 06 11:03:56 <T_UNIX> sorry :-D
Dec 06 11:04:14 <LetoThe2nd> :-)
Dec 06 11:05:56 <T_UNIX> is there a way to assure that one branch's build won't mess up another (simultaneous) branch's build base?
Dec 06 11:06:26 <rburton_> if you build then switch branch and build, then antyhing from the old build that isn't valid will be removed
Dec 06 11:06:43 <T_UNIX> but how about simultaneous builds?
Dec 06 11:06:50 <T_UNIX> parallel
Dec 06 11:06:56 <LetoThe2nd> no, not that i knew of. unless you restrict yourself to the modification of recipes with nothing that depends from it.
Dec 06 11:07:00 <rburton_> you can't do parallel builds on the same build tree, so that's not a problem
Dec 06 11:07:14 <rburton_> note that i'm assuming you're using a recentish release with recipe-specific-sysroots
Dec 06 11:07:33 <T_UNIX> okay.  Can I set some guard variable?
Dec 06 11:08:14 <T_UNIX> I.e.: "if this checksum *would* change, abort before touching anything for real"
Dec 06 11:08:39 <rburton_> so what are you actually trying to do?
Dec 06 11:09:01 <LetoThe2nd> rburton_: yeah, smells of XY-question.
Dec 06 11:09:37 <T_UNIX> I'd like to avoid (unintended) interference between multiple branches (with different progress and features) whilst minimizing the necessary resources.
Dec 06 11:10:24 <rburton_> you can use bitbake-whatchanged to see what is different between the build on disk and what the current metadata says
Dec 06 11:10:34 <T_UNIX> I guess I'll just have to read the docs on sstate. Maybe it already does all that.
Dec 06 11:11:18 <rburton_> well sstate is simple really: given the inputs, it caches the output
Dec 06 11:11:36 <rburton_> if the sources and compiler flags and dependencies are all the same, here's the packages that would be built
Dec 06 11:11:58 <rburton_> you can compare the hashes to identify where changes are, which is what bitbake-whatchanged does
Dec 06 11:12:00 <T_UNIX> but it can be safely shared between multiple parallel builds, right?
Dec 06 11:12:06 <rburton_> sure
Dec 06 11:12:39 <rburton_> there's a race where two parallel builds might end up writing the same object because it doesn't exist when they both go and look for it, but they'll just repeat work
Dec 06 11:13:17 <rburton_> i'm assuming by parallel you mean 'two bitbakes on two tmpdirs, sharing sstate_dir'
Dec 06 11:13:38 <T_UNIX> yes, that's what I mean
Dec 06 11:13:54 <RP> we share the sstate dir between about 30 workers on the autobuilder
Dec 06 11:14:01 <RP> (over nfs)
Dec 06 11:14:07 <RP> so its well tested
Dec 06 11:14:17 <rburton_> i mean, if it can survive nfs, it must work
Dec 06 11:14:23 <RP> exactly!
Dec 06 11:16:36 <T_UNIX> how does sstate map to the packages in tmp/work/ ? I mean how does it avoid confusion of two parallel builds claim to be the (differing) provider of `foo-1.0`?
Dec 06 11:17:05 <rburton_> T_UNIX: it is keyed on the hash
Dec 06 11:17:11 <rburton_> the hash is all inputs
Dec 06 11:17:14 <rburton_> so all sources
Dec 06 11:17:17 <rburton_> all dependencies
Dec 06 11:17:22 <rburton_> all variables that can change and impact the build
Dec 06 11:17:30 <T_UNIX> and sstate provides the result?
Dec 06 11:17:53 <rburton_> yes
Dec 06 11:18:08 <T_UNIX> i.e. create the resulting package in sstate and only copy it to instance specific tmp/work?
Dec 06 11:18:15 <rburton_> when you bitbake foo, when foo finishes the packages are written to sstate with the hash as the filename
Dec 06 11:18:30 <rburton_> sstate is a cache, stuff is fetched from it on demand.
Dec 06 11:18:43 <T_UNIX> okay, thanks :)
Dec 06 11:18:57 <rburton_> hm our autobuilder sstate is 'a bit large'
Dec 06 11:19:31 <rburton_> RP: want to put a bet on how big the ab sstate cache is?
Dec 06 11:19:42 <rburton_> a full du might take about ten minutes or so
Dec 06 11:25:33 <RP> rburton_: Its around 350GB per build, michael and I worked it out
Dec 06 11:27:15 <RP> rburton_: "df" might be faster ;-)
Dec 06 11:27:47 <rburton_> well df says 42T used but that's not just the sstate
Dec 06 11:28:58 <RP> rburton_: I'd guess at about 3/4s of it is
Dec 06 11:34:20 <JaMa> rburton_: we generate about 2TB per week and then it's pruned and starts again, I wish our IT could do 42TB fs..
Dec 06 11:35:34 <JaMa> build-artifacts  4.0T  3.0T  793G  80% /mnt/mirror-write
Dec 06 11:35:45 <JaMa> and it was pruned just few days ago :/
Dec 06 11:37:11 <rburton_> 172.29.10.206:/mnt/tank/yocto/autobuilder  124T   42T   82T  34% /srv/autobuilder
Dec 06 11:37:47 <rburton_> that's one big disk
Dec 06 11:37:57 <JaMa> I should send screenshot to our IT :)
Dec 06 11:38:22 <rburton_> its like motorway widening, the challenge now is to fill it up!
Dec 06 12:29:45 <jofr> I want to include an init-script for a package, but don't want any rc<X>.d symlinks, how would I go about doing that? Bitbake doesn't like INITSCRIPT_PARAMS = "".  :/
Dec 06 12:33:27 <jofr> Nevermind. INITSCRIPT_PARAMS = "start . stop ." did the trick.
Dec 06 12:36:06 <RP> rburton_: michael did shrink the data to allow us to change hardware around (like enclosures)
Dec 06 12:40:22 <eduardas_m> LetoThe2nd: thank you, your advice seems to work
Dec 06 12:40:59 <eduardas_m> how do I approarch fixing this for the mksh recipe I wish to upstream? http://errors.yoctoproject.org/Errors/Details/203419/
Dec 06 12:41:38 <eduardas_m> where can I get the same cortexa7t2hf-neon-vfpv4-yoe-linux-musleabi configuration so I can build with the same settings on my machine?
Dec 06 12:42:16 <eduardas_m> I have built with poky and TCLIBC="musl" successfully, so I am unsure why the recipe breaks on arm
Dec 06 12:42:40 <eduardas_m> I built for qemux86 to test with musl
Dec 06 12:43:48 <jofr> This part: "Removed auto-starting of (init-)firewall and xinetd as those will be started by eth_config." .. don't worry about xinetd. The firewall init-script takes care of it.
Dec 06 12:44:09 <jofr> Aaaaaaand this was not the correct window.
Dec 06 12:46:05 <LetoThe2nd> eduardas_m: at least the log you gave suggests that its not compile thats failing, but install
Dec 06 12:52:38 <eduardas_m> LetoThe2nd: yes, but it seems to package and work on QEMU correctly for me now, so I do not know why it failed for that build
Dec 06 12:53:00 <eduardas_m> would like to be able to reproduce myself
Dec 06 12:55:26 <eduardas_m> what is this "yoe-linux" stuff in log "Target System" label?
Dec 06 12:57:01 <eduardas_m> It appears it is this: https://github.com/YoeDistro/yoe-distro
Dec 06 12:57:29 <eduardas_m> recipes contributed to meta-openembedded need to compile with musl on this specific distro?
Dec 06 13:46:13 <yates> khem, rburton: thank you for responding yesterday.
Dec 06 13:48:38 <yates> the toolchain nomenclature is still unclear to me after all these months: what is the SDK? what is the eSDK? what is the ADT? are one or more of these different names for the same thing?
Dec 06 13:49:38 <yates> basically at one point my boss generated an outside, cross-toolchain (building on the x86 and targeting an arm ) that we put in our /opt/fslc/... directory and build from. this is what i am referring to
Dec 06 13:50:16 <angelo_ts> hi, question: i have recipes of 2 apps that needs to use(link with) 2 different versions of the same library. How can i manage this ?
Dec 06 13:50:36 <yates> we can build (i.e., run our own makes) from there outside yocto (once the toolchain was built and installed)
Dec 06 13:51:05 <yates> of course we had to adjust our make file options to point to the /opt/fslc compiler, linker, etc.
Dec 06 13:52:09 <yates> i should clarify that we build this way sometimes. other times we create a recipe for our app and build it under yocto using bitbake.
Dec 06 13:52:27 <yates> sorry if i'm being long-winded but it seems that i confused everyone and i'm trying to clarify
Dec 06 13:55:01 <eduardas_m> khem: hello, what is the purpose of the yoe/mut branch on https://github.com/YoeDistro/yoe-distro.git ?
Dec 06 13:55:26 <eduardas_m> would like to try and replicate the musl do_install failure for mksh
Dec 06 13:56:17 <eduardas_m> somewhat confused not to see a conf directory when build for raspberrypi3 starts
Dec 06 13:56:30 <eduardas_m> not sure where to set TCLIBC = "musl"
Dec 06 13:56:57 <yates> i should also clarify that i modified our makefile so that when we throw our build into a yocto recipe, it uses the yocto build tools (e.g., $(CXX), etc.) and does not point to the /opt tools. in fact this was the main problem causing the "incompatible ABI" message I was getting from the wx lib at run-time - wx was build using the yocto tools and i had neglected to move the compiler, etc. in our wx app from the /opt
Dec 06 13:56:57 <yates> /fslc toolchain back to the yocto build tools
Dec 06 14:01:59 <yates> is there a name for the toolchain yocto uses when it is bitbaking a recipe? the SDK?
Dec 06 14:11:23 <eduardas_m> never mind, figured out the user needs to create the local.conf file on ones own
Dec 06 14:11:39 <eduardas_m> different from the Yocto builds I'm used to
Dec 06 14:37:09 <eduardas_m> does anyone here have experience using g_mass_storage USB MSC gadget driver and a FAT partition in a commercial product? Can this thing be made reliable enough to not corrupt the FAT partition?
Dec 06 14:37:37 <eduardas_m> I know this is unrelated to Yocto, but since this channel has mostly embedded people, seems like a good place to ask
Dec 06 14:39:09 <rburton_> yates: the toolchain that oe uses by default is just 'the toolchain'
Dec 06 14:39:30 <rburton_> a pre-provided toolchain that provides a cross-gcc etc is called an external toolchain
Dec 06 14:40:10 <rburton_> ADT, application developer toolkit or something, is typically what meta-toolchain builds.  that's just a cross compiler and friends
Dec 06 14:40:32 <rburton_> replaced with a SDK as built by bitbake myimage -c populate_sdk, which is a cross compiler and all the libraries that were in myimage
Dec 06 14:40:54 <rburton_> eSDK is the same thing (-c populate_sdk_ext) but instead of being static its extensible, so you can install more stuff into it
Dec 06 14:41:25 <rburton_> it also can run bitbake and build images so its more powerful but also more complex.
Dec 06 15:10:32 <JPEW> RP: Thanks for looking at the hash-equivalence patches. When you're all through reviewing them, let me know and I'll post a V4
Dec 06 15:25:39 <RP> JPEW: I'm thinking of merging the bits in -next? Any reason they shouldn't work standalone?
Dec 06 15:26:26 <RP> JPEW: My biggest concern right now is the naming as I really don't like the "dependency" reference as it means something quite different to our usual use of the word
Dec 06 15:26:54 <JPEW> RP: Ya, naming is hard. I replied on the mailing list.
Dec 06 15:27:21 <RP> JPEW: I saw thanks. Still pondering as I don't have suggestions which feel 100% right
Dec 06 15:28:22 <RP> JPEW: we need to get it right as its hard to change after we merge it
Dec 06 15:28:37 <JPEW> RP: Yep. I'll keep thinking about it
Dec 06 15:28:50 <RP> JPEW: good news is the AB tests on -next were fine
Dec 06 15:28:58 <JPEW> RP: Woohoo
Dec 06 15:29:30 <RP> JPEW: suggests we don't need the fork pieces, at least for the non sstate equivalence
Dec 06 15:30:56 <JPEW> RP: Quite possibly. I had a lot of strange errors with the persist_data. That might have been something I tried but didn't think about removing after I eliminated the errors
Dec 06 15:31:32 <JPEW> Also, hash equivalence dramatically increases the usage of persist_data, so it can uncover a lot of races
Dec 06 15:31:56 <RP> JPEW: right, not saying we don't need it, I'd just like to explore that
Dec 06 16:17:24 <afsfs> hello
Dec 06 16:49:26 <moto-timo> RP or rburton: oxygen patch also pushed. This makes the first big download come from our mirror. Not sure that is complete fix.
Dec 06 16:49:45 <moto-timo> RP or rburton: can you please kick off an oxygen-master build?
Dec 06 16:50:08 <RP> moto-timo: I will do so now, thanks!
Dec 06 16:50:25 <RP> moto-timo: neon was green btw
Dec 06 16:51:46 <moto-timo> RP: and in record time. 6:58. I can't remember a build less than 10 minutes...
Dec 06 16:53:29 <RP> moto-timo: looks like the previous ones were 8:45 ish but I'll take any speedups :)
Dec 06 16:53:41 <RP> nice :)
Dec 06 16:53:44 <moto-timo> RP: agreed :)
Dec 06 16:54:22 <moto-timo> RP: still not convinced that is the fix, but it is promising (at least for neon)
Dec 06 16:54:50 <moto-timo> RP: oxygen already had the full mirror for everything but UPDATE_SITE, so that is still a head scratcher
Dec 06 16:55:23 <RP> moto-timo: checking things are getting updated on the mirror is probably the next logical step (with halstead)
Dec 06 17:00:57 <halstead> moto-timo, RP The eclipse full mirror is updating daily. There have been some failures and interrupted syncs but all important files have been copied. Errors like "oomph/updates/milestone/latest/org.eclipse.oomph.site.zip failed verification"
Dec 06 17:02:43 <moto-timo> halstead: the oxygen-master builds timing out bug me, because that has been downloading almost everything from our full mirror.
Dec 06 17:03:35 <moto-timo> halstead: I'm writing email with a couple ideas. Today is a train wreck of 100% overbooked for me... :(
Dec 06 17:04:44 <halstead> moto-timo, Working via e-mail sounds good. We can make time for synchronous work tomorrow if needed.
Dec 06 17:05:17 <yocti> New news from stackoverflow: Yocto - fetch private repo using https <https://stackoverflow.com/questions/53656233/yocto-fetch-private-repo-using-https>
Dec 06 17:08:32 <yates> rburton_: that helps - thank you
Dec 06 17:30:14 <cdgarren> Does anyone have recommendations for a virtual keyboard package? It looks like matchbox-keyboard and florence are the most common.
Dec 06 17:57:02 <nerdboy> RP: not entirely sure...
Dec 06 17:57:07 <nerdboy> and i see a moto-timo
Dec 06 18:25:11 <dresserd> Hello, I'm trying to build "core-image-minimal" for a "zcu102-zynqmp" board using "meta-xilinx" and seeing this error "Fetcher failure for URL: 'file://MPC8315ERDB-enable-DHCP.patch'. Unable to fetch URL from any source"  I'm using the thud branch of openembedded and the "rel-v2018.3" branch of meta-xilinx.  Is anyone familiar with that error?  Is this the right place to ask?
Dec 06 18:27:44 <khem> dresserd: can you grep for MPC8315ERDB-enable-DHCP.patch in meta-xilinx ?
Dec 06 18:28:12 <khem> this is an old patch which has been removed in oe-core/u-boot, I think meta-xilinx might have not been updated
Dec 06 18:29:12 <dresserd> Thanks for responding "meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-common_2018.01.inc:    file://MPC8315ERDB-enable-DHCP.patch \" is the only reference.
Dec 06 18:30:04 <khem> delete it
Dec 06 18:30:50 <khem> infact you might have to take the copy of this patch and stick it in meta-xilinx
Dec 06 18:31:37 <dresserd> the file doesn't exist, only that reference to it.
Dec 06 18:31:55 <khem> you might even remove it from SRC_URI since it fixes something for MPC8315ERDB and not impacting board you are interested in
Dec 06 18:32:14 <khem> yes delete the reference
Dec 06 18:32:19 <dresserd> I see
Dec 06 18:34:14 <dresserd> interesting that the patch is versioned "2018.01" while I am building the "2018.3" branch.
Dec 06 18:34:37 <khem> yeah I think it should have been removed
Dec 06 18:35:45 <dresserd> I'm pretty new to Yocto.  My understanding of the "right" way to fix that is to use devtool to "modify" that recipe, which will create a recipe with a bbappend file in one of my layers.  Is that correct?
Dec 06 18:38:15 <khem> yeah but in this case devtool may not be needed.
Dec 06 18:38:44 <khem> in your layer you can add a bbappend manually and add SRC_URI_remove = "file://MPC8315ERDB-enable-DHCP.patch"
Dec 06 18:39:07 <khem> otherwise its better to modify it in meta-xilinx and send a patch to that layer
Dec 06 18:40:03 <dresserd> Ok.  Thanks.  deleting that  got me past that error.  Submitting a patch is a good idea.
Dec 06 18:40:03 <Crofton> also ask on the meta-xilinx list
Dec 06 18:40:25 <Crofton> aehs29, may also care
Dec 06 18:43:28 <dresserd> Thanks for the help.  I subscribed to meta-xilinx.
Dec 06 18:44:18 <kergoth> dresserd: recipetool's newappend command sounds more useful for you
Dec 06 18:44:32 <kergoth> devtool is better for direct source tree modification
Dec 06 18:45:16 <dresserd> now I know there's  a thing called "recipetool"  ;-)
Dec 06 18:46:08 <khem> kergoth: yeah recipetool
Dec 06 18:50:32 <tgoodwin> Has anyone run across a good solution for compiling u-boot-mkimage-native when the host OS has libfdt-devel installed (other than "uninstall libfdt-devel")?
Dec 06 18:52:16 <tgoodwin> Right now it causes a compiler error against fdt64_t.
Dec 06 18:57:26 <khem> tgoodwin: IIRC latest version of u-boot should have this fixed
Dec 06 18:57:40 <tgoodwin> Ah okay, good.
Dec 06 18:57:44 <khem> I ran into it earlier this year
Dec 06 18:57:45 <tgoodwin> I'm back on rocko
Dec 06 18:59:16 <tgoodwin> Hmm...maybe I was looking at your patch.  The u-boot I'm dealing with is xilinx's 2018.1 and I couldn't find the file related to that patch (something like boot/uboot/uboot.mk)
Dec 06 19:00:56 <dresserd> khem: I discovered that there are two meta-xilinx repositories.  One at git.yoctoproject.org and one at github.   The one at yoctoproject.org looks like the one I want.  It has branches for each yocto release, but the latest branch is sumo.  Guess I'll try that.
Dec 06 19:11:04 <tgoodwin> khem: Yep.  Turning this into a patch against tools/Makefile did the trick: http://lists.busybox.net/pipermail/buildroot/2018-March/215419.html
Dec 06 19:11:29 <tgoodwin> Thanks for reminding me of seeing that.
Dec 06 19:18:45 <khem> dresserd: the one of gh is a mirror usually
Dec 06 19:48:25 <dqx> hello everyone good morning (international irc time!), what would be the best way to define a directory variable like pkgconfig's bindir, libdir, etc., but for my layer? I wanted to install everything to a common prefix but only for this layer. I'd appreciate any pointers. thanks in advance.
Dec 06 19:49:10 <dqx> I'm considering using `require myclass` and writing a simple `init` if needed, not sure though, I'm new to Yocto
Dec 06 19:50:12 <neverpanic> so you want to change prefix for recipes in your layer only?
Dec 06 19:51:29 <dqx> yup
Dec 06 19:51:32 <dqx> basically
Dec 06 19:51:53 <dqx> didn't want to write string literals like "/usr/..."
Dec 06 19:52:15 <dqx> I'd rather write ${myprefix}
Dec 06 19:52:30 <neverpanic> well, you could write a bbclass that sets prefix and inherit that?
Dec 06 19:52:47 <dqx> yup, that's what I was considering indeed
Dec 06 19:53:32 <neverpanic> You could try putting that into layer.conf, too, if I remember correctly that would affect other recipes as well
Dec 06 19:54:01 <dqx> bitbake.conf would be another way to go maybe? I just found it too much to define that
Dec 06 19:54:20 <neverpanic> If you change it in bitbake.conf, you'll move your entire system
Dec 06 19:54:36 <dqx> oh, write
Dec 06 19:54:39 <dqx> oh, right rs
Dec 06 19:54:44 <dqx> sorry
Dec 06 19:55:17 <dqx> thanks neverpanic. it helped to confirm and this other pointer is also possible. gonna do this now :D cheers
Dec 06 19:55:35 <neverpanic> It may be a stupid question, but why do you want to do this?
Dec 06 19:55:59 <neverpanic> If your software sticks to the filesystem hierarchy standard it's usually fine to install it in the "normal" places
Dec 06 19:56:53 <dqx> neverpanic: oh, it's not stupid. I just realized I have another doubt actually. I didn't want to overwrite the other layers binaries upon do_install(), that's my primary issue. am I safe just by defining the layer priority?
Dec 06 19:58:30 <neverpanic> You'll get a conflict whenever you do this anyway, so it's a non-issue.
Dec 06 19:58:32 <khem> layer.conf should not be used to sweep under the rug IMO
Dec 06 19:59:34 <khem> probably we should write a tool to call out layers on doing dangerous ops in layer.conf
Dec 06 20:00:08 <khem> writing a new bbclass to override common variable from bitbake.conf is a good approach here
Dec 06 20:01:50 <neverpanic> But really, if you're only considering to switch prefix to avoid overwriting existing files, don't. It's not necessary.
Dec 06 20:03:24 <dqx> khem: ack and noted :) thx
Dec 06 20:06:52 <rburton_> dqx: you'll need to write a class or config file that sets prefix, and include it in every recipe you want to move
Dec 06 20:06:56 <rburton_> layer.conf will be global
Dec 06 20:54:05 <aehs29> dresserd: meta-xilinx is still not updated to thud
Dec 06 20:54:28 <aehs29> dresserd: not on 2018.3, 2019.1 will work with thud
Dec 06 20:54:38 <aehs29> Crofton: thanks
Dec 06 20:55:24 <Crofton> sad
Dec 06 21:50:02 <opello> is it reasonable/possible to depend on an tmp/deploy/images/ output file in another recipe for repackaging that image?
Dec 06 21:52:25 <aehs29> khem: are you planning on upgrading meta-openwrt ot thud? do you have some WIP or are you accepting patches?
Dec 06 21:55:34 <dqx> rburton_: thanks bro
Dec 06 21:56:59 <dqx> how do I specify a CFLAGS or LDFLAGS for a package so that whoever depends on this package will append it to its flags? if possible. I could do the other way around also, but I needed to have the pkgconfig directories somehow.
Dec 06 21:59:17 <khem> aehs29: patches are welcome
Dec 06 21:59:46 <khem> I dont plan to do major updates myself as of yet
Dec 06 22:00:10 <neverpanic> dqx: That's generally done using pkg-config or CMake config files
Dec 06 22:02:14 <dqx> neverpanic: will use `inherit pkgconfig`, was just lazy to read the code :D
Dec 06 22:03:16 <neverpanic> dqx: That alone will not do it. The build system of your component needs to install a suitable pkg-config file and the build systems of your dependent components will need to use $(pkg-config --cflags) and $(pkg-config --ldflags) to get those.
Dec 06 22:04:31 <aehs29> khem: yesh I was just playing around with it and theres a couple of patches, busybox, netifd and I think the mirror for xtables-addons is not working
Dec 06 22:06:24 <yocti> New news from stackoverflow: Is it possible to use Embedded OS prepared for i.MX6solo over i.MX6UL...? [on hold] <https://stackoverflow.com/questions/53638232/is-it-possible-to-use-embedded-os-prepared-for-i-mx6solo-over-i-mx6ul>
**** ENDING LOGGING AT Fri Dec 07 03:00:01 2018