**** BEGIN LOGGING AT Mon Jan 15 03:00:01 2018
Jan 15 09:54:01 <sveinse> Anyone with python knowledge here? I have a py-based service which runs "from dbus.mainloop.glib import DBusGMainLoop" and "from gi.repository import GObject as gobject". This fails on rocko, but works on pyro. I suppose there is a dependency missing, but diffing the manifests does not give me any clues. Familiar to anyone?
Jan 15 09:54:52 <sveinse> It fails on ImportError: cannot import name GObject
Jan 15 10:04:03 <eduardas_m> hello, I have a cmake project that compiles well both on Ubuntu 16.04 and MSYS2, but fails to compile via bitbake recipe because it can not find the most usual of headers, like <stdio.h> or <chrono>
Jan 15 10:04:26 <eduardas_m> fatal error: stdio.h: No such file or directory
Jan 15 10:04:45 <hnje> eduardas_m: #include_next or ordinary #incldue that fails?
Jan 15 10:06:00 <kanavin> sveinse: you need to depended python3-pygobject I think
Jan 15 10:06:25 <eduardas_m> hnje: ordinary include... here is my recipe: https://pastebin.com/RNU3YqwB
Jan 15 10:08:29 <eduardas_m> hnje: here is the compile failure log: https://pastebin.com/TKaL6N9Q
Jan 15 10:08:29 <xtron> any selinux guy here?
Jan 15 10:08:59 <eduardas_m> hnje: note the "fatal error: stdio.h: No such file or directory"
Jan 15 10:39:34 <sveinse> kanavin: yeah, I have that (on both versions)
Jan 15 10:44:53 <kanavin> sveinse: then you need to see why the imported modules fail to import. are they installed?
Jan 15 10:46:16 <sveinse> kanavin: yes. I suspect there is some secondary dependency missing. Dbus and glib is tricky whis way
Jan 15 10:48:34 <kanavin> sveinse: running with strace may help
Jan 15 10:58:33 <luneff> how interesting: "nothing provides capnproto = 0.6.1-r0 needed by capnproto-dev-0.6.1-r0.cortexa7hf-neon-vfpv4". so Yocto knows about -dev package, but not about the main package. I'm trying to include -staticdev version into the image and SDK
Jan 15 10:59:49 <luneff> hm. capnproto RPROVIDES capnproto-dev
Jan 15 11:00:14 <rburton> sounds like that recipe is pretty messed up
Jan 15 11:18:16 <ttllkk> ERROR: greengrass-1.1.0-r0 do_package_qa: QA Issue: /greengrass/ggc/packages/1.1.0/lambda/arn contained in package greengrass requires aws:lambda:::function:GGShadowSyncManager/syncmanager_greengrass:, but no providers found in RDEPENDS_greengrass? [file-rdeps]
Jan 15 11:18:32 <ttllkk> Any idea about how could I look at what could provide aws::lambda.. ?
Jan 15 11:20:29 <luneff> rburton, I think I'll go by with SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs", testing if that lib gets into te toolchain
Jan 15 11:20:31 <luneff> *the
Jan 15 11:23:34 <isaac_> Is there any have to have all meta-* layers inside a dedicate "layer" directory without breaking the poky repository?
Jan 15 11:25:50 <LetoThe2nd> isaac_: hum, waht do you mean? having all layers inside the poky dir is a rather bad idea. having them all in a seperate "layers" dir besides the poky dir - sure, why not.
Jan 15 11:30:11 <luneff> rburton, no luck, .a files not added to the toolchain. https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-devtools/capnproto/capnproto_0.6.1.bb :-(
Jan 15 11:30:28 <rburton> isaac_: layers can go anywhere, and poky is just oe-core + bitbake, so its absolutely possible to have the layout you want with your distro
Jan 15 11:48:21 <isaac_> @rburton: That's correct. But I cannot do "git pull" to update my recipes to upstream as the files have been moved
Jan 15 11:48:37 <rburton> isaac_: don't use pok
Jan 15 11:48:39 <rburton> poky
Jan 15 11:48:50 <rburton> make your own merged repo
Jan 15 11:49:37 <luneff> hm. getting ERROR: Nothing PROVIDES 'capnproto-staticdev' while capnproto RPROVIDES capnproto-staticdev; capnproto recipe indeed produces all the packages I need, it looks like the recipe just doesn't know that for sure :-)
Jan 15 11:54:39 <isaac_> rburton: What distro do you recommend? We have various modules (Toradex, Ka-Ro, etc) and want to have a common denominator so that most of recipes works without any modification
Jan 15 11:55:32 <luneff> PROVIDES_append = "capnproto-staticdev capnproto-dev" seems to work, btw
Jan 15 11:55:34 <isaac_> rburton: Having all products on the same distro helps to reduce configuration headaches
Jan 15 11:55:39 <rburton> isaac_: your own distro, that's the point.
Jan 15 11:55:56 <rburton> poky is a vehicle for QA, we don't expect anyone to use it in production
Jan 15 11:57:58 <isaac_> rburton: I see. So we should have our customized layer over poky as the base for other meta layers
Jan 15 11:58:19 <rburton> isaac_: not over poky, you fetch bitbake + oe-core + all other layers, and arrange them how you want
Jan 15 11:58:52 <rburton> poky is just bitbake + oe-core + meta-poky (the poky distro config) + meta-yocto-bsp (reference BSPs for QA purposes)
Jan 15 11:59:16 <rburton> yourdistro is bitbake + oe-core + meta-networking + meta-mylayer, or whatever
Jan 15 12:00:47 <luneff> argh. still nothing provides capnproto = 0.6.1-r0 needed by capnproto-dev-0.6.1-r0.cortexa7hf-neon-vfpv4
Jan 15 12:01:12 <luneff> even with PROVIDES_append = " capnproto capnproto-compiler capnproto-dbg capnproto-dev capnproto-staticdev "
Jan 15 12:04:38 <isaac_> rburton: Got it. I thought poky is something critical to yocto build. Apparently it's just a sample set of other meta layers
Jan 15 12:04:40 <luneff> and actually there isn't any "capnproto" package O_o
Jan 15 12:04:52 <luneff> just -dev, -staticdev, -compiler and -dbg
Jan 15 12:06:05 <rburton> does capnproto even ship a shared library?
Jan 15 12:06:14 <rburton> you may be looking for a package that doesn't exist for good reason
Jan 15 12:07:29 <luneff> I'm ok there isn't just a "capnproto", it is -dev version that seeks for 'capnproto'. and it contains headers etc, and it can't be installed
Jan 15 12:07:38 <rburton> as i said, sound like the recipe is broken
Jan 15 12:08:20 <luneff> how do I fix it? I think, I just need to remove ${PN} dependency from -dev version
Jan 15 12:09:20 <luneff> DEPENDS_${PN}-dev_remove = " ${PN} " ?
Jan 15 12:12:40 <isaac_> rburton: Thanks rburton! That was very informative
Jan 15 12:16:50 <rburton> luneff: if there's meant to be no shared library instealled, then yes.  no need for bonus whitespace inside the _remove though
Jan 15 12:20:09 <luneff> hm, that's not what I've meant to do... interesting
Jan 15 12:29:24 <BubuIIC> Is there an easy way to use latest kernel.org stable kernel inside yocto?
Jan 15 12:52:54 <BubuIIC> I guess I have to go through the create your own custom kernel recipe section...
Jan 15 13:21:41 <learningc> Is there a way to completely remove opengl from yocto?
Jan 15 13:22:32 <LetoThe2nd> learningc: why do you even add it?
Jan 15 13:22:58 <LetoThe2nd> learningc: none of my projects comes with opengl, so the answer is certainly "yes"
Jan 15 13:23:00 <learningc> I did not add. There is a package that compiles something against it
Jan 15 13:23:17 <LetoThe2nd> learningc: so you did not add it directly, but indirectly as a dependency
Jan 15 13:23:52 <learningc> AC_TRY_COMPILE([
Jan 15 13:23:52 <learningc> #include"SDL_opengl.h"
Jan 15 13:23:52 <learningc> ],[
Jan 15 13:23:52 <learningc> GLuint texture;
Jan 15 13:23:52 <learningc> ],[
Jan 15 13:23:53 <learningc> have_opengl=yes
Jan 15 13:23:54 <LetoThe2nd> but the question is "can i build package XYZ without opengl", not if you can remove it from the build.
Jan 15 13:23:55 <learningc> ])
Jan 15 13:25:22 <LetoThe2nd> either tell the package to explicitly not use opengl, or... patch it to not use it. such auto-detected dependencies during the configure run are an absolutely major pita.
Jan 15 13:40:48 <rburton> learningc: remove opengl from DISTRO_FEATURES, and anything that does use opengl is buggy and you should be able to fix
Jan 15 13:47:45 <learningc> LetoThe2nd, Absolutely. Now it pains so much that I cannot sleep
Jan 15 13:49:29 <learningc> Can I put  DISTRO_FEATURES_remove in my local.conf?
Jan 15 13:50:52 <rburton> learningc: yes, but you should put it in your own distro configuration in the long term
Jan 15 13:51:12 <learningc> ok
Jan 15 14:13:50 <learningc> Where can I check if yocto has detected opengl in the process?
Jan 15 14:29:12 <rburton> learningc: yocto doesn't care.  you mean how to check if a specific recipe has looked for opengl?
Jan 15 14:29:33 <rburton> well one easy way would be to make whatever your opengl provider is (mesa, etc) abort if it gets built with opengl disabled
Jan 15 14:30:08 <rburton> libx11 does this for this reason: if you turned off x11 you don't want any X, so force it by refusing to build
Jan 15 14:33:40 <learningc> I see
Jan 15 14:49:58 <yocti> New news from stackoverflow: Cant get Java to run on Ostro <https://stackoverflow.com/questions/48265197/cant-get-java-to-run-on-ostro>
Jan 15 14:59:12 <acrap> Hi, guys! Where can i get information how to add new MACHINE through BSP with custom linux kernel (4.14 linux-mti)?
Jan 15 14:59:53 <acrap> i got the following error
Jan 15 14:59:56 <acrap> ERROR: Nothing PROVIDES 'kern-tools-native'
Jan 15 14:59:57 <acrap> ERROR: kern-tools-native was skipped: incompatible with machine boston_i6400 (not in COMPATIBLE_MACHINE)
Jan 15 14:59:59 <acrap> ERROR: Required build target 'linux-yocto-boston' has no buildable providers.
Jan 15 15:00:00 <acrap> Missing or unbuildable dependency chain was: ['linux-yocto-boston', 'kern-tools-native']
Jan 15 15:00:52 <acrap> sometimes it is another packet, like pseudo-native or smth like that
Jan 15 15:37:08 <xthunderawayx> Morning - I'm creating a recipe to build a package from dbus-cxx but get stuck @ do_configure
Jan 15 15:37:51 <xthunderawayx> The step doesn't appear to fail, it just doesn't actually configure anything.  I get this in the log:
Jan 15 15:38:00 <xthunderawayx> DEBUG: Executing shell function do_configure
Jan 15 15:38:01 <xthunderawayx> NOTE: nothing to configure
Jan 15 15:38:01 <xthunderawayx> DEBUG: Shell function do_configure finished
Jan 15 15:38:49 <xthunderawayx> I followed the example in Rudolf Streif's book for an autotools recipe.
Jan 15 15:39:45 <xthunderawayx> I can't see anything wrong.  I originally had a malformed recipe name but have corrected that ...
Jan 15 15:39:50 <xthunderawayx> Any clues?
Jan 15 15:41:05 <LetoThe2nd> xthunderawayx: can you put the recipe-so-far into a pastebin?
Jan 15 15:41:40 <xthunderawayx> Sure ... take a second to set up.
Jan 15 15:42:13 <xthunderawayx> I used to have pastebin but haven't used it in ages.
Jan 15 15:44:07 <LetoThe2nd> xthunderawayx: just some random pastebin website and copypaste it there :)
Jan 15 15:45:06 <xthunderawayx> yep ... just as a guest on pastebin. One sec while I get the recipe from a remote machine ...
Jan 15 15:49:22 <xthunderawayx> Sorry dood ... how bout this: https://pastebin.com/iJvttdvP
Jan 15 15:49:51 <xthunderawayx> It is dirt simple: SRCURI, inherit autotools.
Jan 15 15:50:24 <xthunderawayx> I left out the depends because I know they are already satisfied. Just dbus and libsigc
Jan 15 15:51:34 <xthunderawayx> The code gets fetch properly and the I've built natively on ubuntu no sweat before ...
Jan 15 15:53:21 <LetoThe2nd> xthunderawayx: ah. you're probably missing something along the lines of S=${W}/git or such. you're pulling a specific revision by git, so the automatic directory setup doesn't help you.
Jan 15 15:54:32 <xthunderawayx> Aw ... rog that.  I'll adjust and try again.  I thought it might be something along those lines when I realized the code was fetching to a weird place.
Jan 15 15:54:35 <LetoThe2nd> sorry, it is S = "${WORKDIR}/git"
Jan 15 15:55:04 <xthunderawayx> I had a malformed recipe name with a "-" instead of a "_" between package and version.
Jan 15 15:55:39 <LetoThe2nd> thats another bummer, yes.
Jan 15 15:56:08 <xthunderawayx> When I found that I thought "that's it" but after I was baffled.  Thax for the tip!!
Jan 15 15:59:37 <rburton> xthunderawayx: please submit it to meta-oe when you're done, as this recipe comes up every few months and nobody ever submits it
Jan 15 16:00:28 <xthunderawayx> Will do. I was *very* surprised it wasn't already available.
Jan 15 16:03:14 <rburton> pretty sure if you dig in the meta-oe list you'll find a recipe i was reviewing a while ago but the submitter never submitted a v2
Jan 15 16:05:56 <xthunderawayx> I currently have it fetching from a fork I put on gitlab, but I'll set it up to pull from the original repo before I submit it.
Jan 15 16:17:02 <xthunderawayx> LetoThe2nd: Yep that got me going. Still issues, but it did try to configure with the change. Again many thx.
Jan 15 16:18:16 <LetoThe2nd> xthunderawayx: good luck
Jan 15 16:20:16 <yocti> New news from stackoverflow: How to use '&' character in Yocto SRC_URI svn:// <https://stackoverflow.com/questions/43629945/how-to-use-character-in-yocto-src-uri-svn>
Jan 15 17:34:42 <sveinse> I have big problems getting python-pygobject to work in rocko, when it works fine in pyro. I've been stracing and injecting debug prints into the py libraries all day, but I simply don't know what to do :(
Jan 15 17:50:14 <xthunderawayx> How do I translate "$ svn checkout svn://svn.code.sf.net/p/dbus-cxx/code/trunk dbus-cxx-code" into an SRCURI suitable for Bitbake? I tried: "SRC_URI = "svn://svn.code.sf.net/p/dbus-cxx/code/trunk;module=dbus-cxx-code""
Jan 15 17:50:28 <xthunderawayx> But I was brutally rebuffed.
Jan 15 17:51:04 <xthunderawayx> Maybe it needs ";protocol=http" ??
Jan 15 17:53:05 <neverpanic> See http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#svn-fetcher
Jan 15 17:53:39 <neverpanic> I think module will be appended to the URL, so you were trying to check out code/trunk/dbus-cxx-code. Maybe you want module=trunk;path_spec=dbus-cxx-code
Jan 15 17:58:43 <xthunderawayx> neverpanic: I did read that section but musta misunderstood the module directive because I've not used subversion much. "dbus-cxx-code" is the "path" where svn puts stuff locally maybe?  Anyway I'll try it your way and come back if I flop.
Jan 15 17:59:20 <ttllkk> Why could it be that the 'recipe-depends.dot' shows a dependency like '"libqmi" -> "bash"' but in the libqmi recipe I see no 'DEPENDS += bash' or similar?
Jan 15 18:03:19 <xthunderawayx> neverpanic: Yep ... that helped. Many thx!
Jan 15 18:32:44 <sveinse> Have anyone tested python-pygobject on rocko?
Jan 15 18:33:24 <sveinse> It fails on import, both on GObject and GLib
Jan 15 18:58:53 <batman_> Hi, I want to include a build fragment produced by  a recipe to the recipe specific sysroot and then later consume the build fragment in another recipe
Jan 15 19:00:08 <batman_> I have SYSROOT_DIRS += "${output_dir}" in the recipe producing build fragement
Jan 15 19:00:41 <batman_> But, what should be the source dir in the recipe consuming the build fragment?
Jan 15 19:24:16 <xthunderawayx> I'm getting this from do_configure: WARNING: using cross tools not prefixed with host triplet
Jan 15 19:24:30 <xthunderawayx> which appears to complete otherwise.
Jan 15 19:25:24 <xthunderawayx> However, the subsequent do_compile yacks all over when trying to run m4 on a load of headers.
Jan 15 19:25:58 <xthunderawayx> Is it possible that I need to tell configure which system I'm targeting?
Jan 15 19:28:03 <xthunderawayx> help /NICK
Jan 15 19:28:27 <xthunderawayx> oh for pitty's sake ...
Jan 15 19:33:41 <rburton> xthunderawayx: the cross tools thing, iirc, is not relevant
Jan 15 19:36:48 <xthunderawayx> Ok ... thx.  One less rabbit hole to explore :)
Jan 15 20:05:17 <xthunderworkx> I'm working on a recipe for dbus-cxx and I finally got it to compile apparently, but only with 'manual intervention'
Jan 15 20:05:38 <xthunderworkx> Do my fetch gets everything from the upstream svn repo
Jan 15 20:05:45 <xthunderworkx> No problem.
Jan 15 20:06:10 <xthunderworkx> Code ends up underneath DL_DIR
Jan 15 20:06:57 <xthunderworkx> Then I guess unpack somehow moves it into my WORKDIR.
Jan 15 20:07:25 <xthunderworkx> configure finds it and does it's thing
Jan 15 20:08:16 <xthunderworkx> But then compile starts to work in a directory 'build' under WORKDIR where it looks like things get copied again
Jan 15 20:09:04 <xthunderworkx> The thing is, there is a file in the source called template.macros.m4 that doesn't make it under 'build'
Jan 15 20:09:18 <xthunderworkx> So do_compile get very angry.
Jan 15 20:09:41 <xthunderworkx> If I copy it over manually, the do_compile completes.
Jan 15 20:10:33 <xthunderworkx> What am I missing?
Jan 15 20:11:03 <rburton> xthunderworkx: sounds like the autotools setup is broken and doesn't handle out-of-tree builds (upstream bug, trivial to fix).  work around it with inherit autotools-buildsep instead of just inherit autotools
Jan 15 20:11:55 <rburton> erm, autotools-brokensep, sorry
Jan 15 20:13:59 <xthunderworkx> Ok got it: autotools-brokensep. I'll give that a go.  Thx!
Jan 15 20:14:30 <rburton> if that fixes it, should be trivial to fix upstream, file a bug
Jan 15 20:15:08 <ranran> does filesystem libaries version depends on kernel version ?
Jan 15 20:15:31 <ranran> Do
Jan 15 20:16:32 <rburton> no
Jan 15 20:20:22 <ranran_> rburton, but syscalls might be modified in new kernel versions, doesn't it has any affect on libraries dependencies (on kernel) ?
Jan 15 20:20:36 <rburton> no, because apps don't call syscalls, glibc does
Jan 15 20:20:40 <rburton> and syscalls don't renumber
Jan 15 20:22:02 <ranran_> I wander if same syscall might change its API (with added arguments) between kernel versions?
Jan 15 20:22:27 <rburton> you'll never need to care
Jan 15 20:22:36 <rburton> glibc handles that for you
Jan 15 20:22:50 <rburton> (no, syscalls don't get api changes)
Jan 15 20:22:57 <ranran_> I mean, if I stay with old kernel, and move to newer yocto (with newer glibc), can it be problematic ?
Jan 15 20:23:00 <rburton> no
Jan 15 20:23:31 <rburton> well only if you want to use software that depends on the new kernel, and obviously don't ever ship a product using an old unsupported kernel which is full of root exploits
Jan 15 20:26:47 <ranran_> I mean, if new kernel might have new syscall that glibc and certian libararies are calling, than obviously these calls will fail.
Jan 15 20:27:11 <ranran_> will fail with the older kernel
Jan 15 20:27:51 <zeddii_home> nope. glibc actually checks for them for the most part. only inline, hand crafed calls would fail.
Jan 15 20:28:18 <zeddii_home> moral of the story. kernel version -> syscall -> glibc is all handled gracefully and has been for over a decade.
Jan 15 20:28:32 <zeddii_home> there aren’t really new problems in that space.
Jan 15 20:29:15 <ranran_> Ok, thanks a lot rburton & zeddii, that's real good news for me. I don't like too much dependencies...
Jan 15 20:41:10 <xthunderworkx> rburton: Yep. Fixed it up apparently. I'll submit a bug.
Jan 15 21:18:19 <ticktock> Hi, can someone tell me if it's possible to override an "IMAGE_INSTALL_remove"?  One layer contains an image recipe that removes a package using 'IMAGE_INSTALL_remove = "<package"', but I want to override that and re-add the package in my own image recipe
Jan 15 21:19:14 <ticktock> If I try to use 'IMAGE_INSTALL_append="<package>"', the package is not added (presumably because the other layer removed it)
Jan 15 21:20:39 <ticktock> If I run bitbake with the "-e" flag to show how it's building IMAGE_INSTALL, I can see that the other layer is removing it, and my layer is adding it after that, but it still does not end up in my image
Jan 15 21:21:44 <ticktock> the only thing that seems to work is commenting out the "IMAGE_INSTALL_remove" from the other layer, but ideally I do not want to have to alter someone else's layer
Jan 15 21:22:31 <rburton> ticktock: no.  just write your own image recipe
Jan 15 21:23:06 <ticktock> so I have to write a new image recipe?  I can't use a .bbappend image recipe?
Jan 15 21:23:25 <rburton> you can, but why cant you just write your own image?  it's your image, not someone elses.
Jan 15 21:23:53 <rburton> people seem very hesitant to do things the way it was designed: write your own distro config, write your own image recipes. etc.
Jan 15 21:23:56 <ticktock> there are several layers that modify the image recipe, so I would have to replicate all of those modifications
Jan 15 21:24:08 <rburton> well that's a bit crazy :)
Jan 15 21:24:20 <ticktock> yeah, it is kind of crazy :)
Jan 15 21:25:16 <kergoth> layers should not bbappend images, bad, bad. too common..
Jan 15 21:25:41 <ticktock> then it should not be allowed
Jan 15 21:26:03 <rburton> images are just recipes, impossible to stop
Jan 15 21:27:10 <rburton> (without breaking abstractions)
Jan 15 21:27:18 <kergoth> technically not impossible, if we were to leverage internal bitbake variables, anyway, but it'd piss a lot of people off, and goes against our general philosophy of high flexibility
Jan 15 21:27:21 * kergoth nods
Jan 15 21:27:25 <rburton> i knew you'd say that ;)
Jan 15 21:27:28 <kergoth> :)
Jan 15 21:27:43 <kergoth> was thinking about it yesterday, actually, we have a couple internal layers doing it, and it's annoying me
Jan 15 21:28:10 <kergoth> should have a sanityc heck or yocto compliance script warn about it, if nothing else
Jan 15 21:28:28 <kergoth> course, compliance should fail anyway if it changes it unconditionally, so maybe it's a nonissue going forward
Jan 15 21:29:52 <zarzar1> is it possible to pull all the code for yocto without running a build? i have a yocto settup for bbb but i don;t want to run the build, i just want to pull all the code
Jan 15 21:30:26 <rburton> you mean eg glibc source, kernel source
Jan 15 21:30:53 <rburton> bitbake <whatever image you wanted to build> -c fetchall
Jan 15 21:31:11 <rburton> or bitbake world -c fetchall to get the source for every recipe bitbake knows about
Jan 15 21:31:53 <zarzar1> rburton: the second option, sounds like it pulls in code that might not be used
Jan 15 21:40:05 <zarzar1> what's the trick for the fetcher failure "URL www.example.com doesn't work"
Jan 15 21:44:11 <zarzar1> sanity.conf
Jan 15 22:20:42 <xthunderworkx> My dbus-cxx recipe doesn't seem to append the correct version numbers to the libraries it creates.
Jan 15 22:21:06 <xthunderworkx> It seems to use the right version for the package files etc ...
Jan 15 22:21:38 <xthunderworkx> Is there a build variable I'm missing?
Jan 15 22:21:41 <kergoth> the recipe doesn't append anything, that's up to the build system of dbus-cxx
Jan 15 22:22:39 <xthunderworkx> Ok
Jan 15 22:23:28 <xthunderworkx> But I should end up with something like libdbus.cxx.so.0.9.0 and not libdbus.cxx.so.0.0.0 right?
Jan 15 22:23:44 <xthunderworkx> i.e. I'm doing something wrong/
Jan 15 22:24:11 <xthunderworkx> In the rootfs I mean
Jan 15 22:25:29 <xthunderworkx> "libdbus-cxx.so.0.9.0" I mean
Jan 15 22:29:45 <xthunderworkx> Oh ... sure. I see your point. Of course the recipe doesn't literally "append" anything. But it does tell the build system how to construct the target package.
Jan 15 22:31:38 <xthunderworkx> So my question is improper, but I'm not certain how to reform it.
Jan 15 22:31:52 <kergoth> that means they didn't set SONAME when linking it
Jan 15 22:32:03 <kergoth> if it's 0.0.0, that is
Jan 15 22:32:13 <kergoth> the recipe doesn't delve down into that detail when calling into the underlying buildsystem
Jan 15 22:33:09 <xthunderworkx> They would be me right?  The recipe author should set SONAME based on PV?
Jan 15 22:33:25 <kergoth> no
Jan 15 22:33:44 <kergoth> soname and library versioning has nothing to do with us, that's up to the upstream project
Jan 15 22:34:29 <xthunderworkx> Aw ... I see. So its an autoconf thing?
Jan 15 22:35:57 <kergoth> automake, technically, but that's the sort of thing, yes
Jan 15 22:36:26 <xthunderworkx> Got it. Thx!
Jan 15 22:40:53 <kergoth> build it outside of oe, it'll emit .0.0.0 there too :)
Jan 15 23:21:43 <rburton> zarzar1: set your proxies
Jan 15 23:22:32 <rburton> sounds like dbus-cxx is an awesome project if they don't version the libraries
**** ENDING LOGGING AT Tue Jan 16 03:00:03 2018