**** BEGIN LOGGING AT Tue May 15 03:00:02 2018
May 15 07:02:02 <ivan_> Hello I am trying to add wayland and weston to my yocto image, unfortunatelly I get error that libwayland-egl is missing. I am new to yocto project so I have no idea how to debug it.
May 15 07:02:19 <JoeR> Hey All, how do I find out who the maintainer of the Python-3.5 stuff within Krogoth is? I'd like to suggest a patch.
May 15 07:03:05 <LetoThe2nd> ivan_: well, you did already ask yesterday. and when i asked for information on which layers you are using, in which revisions, there was no answer anymore
May 15 07:03:28 <LetoThe2nd> ivan_: so please, provide a full failing buildlog including head and error message on a pastebin,
May 15 07:09:20 <ivan_> Leto : I am running a build at the moment, it will take some time. After finish I will try to share logs (pastebin is not accessable from my workplace so I have to find other way).
May 15 07:10:49 <LetoThe2nd> please do so. after the build failed, you can always start it a second time, then it should be considerably shorter as it just fails again. that log should be enough.
May 15 07:11:31 <ivan_> Leto : Meanwhile I have seen that the cairo complained about mising wayland-egl library it didn't found the wayland-egl.rc file so in configure.ac I've added explicit export of PKG_CONFIG_PATH
May 15 07:12:01 <LetoThe2nd> ivan_: thats a bad idea. please do not randomly tinker stuff, but find the real source of the problem.
May 15 07:12:10 <ivan_> Leto : This solves the issue but now weston is not compiling due to missing libwayland-egl, it seems it is not build at all
May 15 07:12:40 <LetoThe2nd> it does not solve the issue, its a band aid that just pushes your problem to another point.
May 15 07:12:55 <LetoThe2nd> as you already see :)
May 15 07:13:14 <ivan_> Well I am really sure how to debug that, thats why I am asking for help
May 15 07:13:24 <ivan_> I am not*
May 15 07:13:30 <LetoThe2nd> and thats why i'm asking for the logs :)
May 15 07:13:56 <ivan_> sure, just to finish the build
May 15 07:46:37 <interruptguy> Hi.
May 15 07:48:12 <interruptguy> Is there a recommendation about yocto recipes file hierarchy. More precise I would like to know if there is a recommendation what should go in recipe-core, recipe-apps...
May 15 07:49:25 <TafThorne> I think there is a loose one given somewhere... You tend to end up with a structure based on what has to happen.
May 15 07:50:23 <LetoThe2nd> put stuff where it fits best :-) in your own layers your free to name the structure at will anyways.
May 15 07:58:27 <interruptguy> Thanks guys. I do feel that maybe some indication should not hurt. Just to be easier to read some layers. I admit that it's not a  must
May 15 08:00:30 <rburton> interruptguy: recipe-* is entirely for convenience and logical grouping. oe-core has totally recipe grouping to say meta-networking.
May 15 08:00:36 <interruptguy> Something like "recipe-core - should contain components that are mandatory/required"
May 15 08:01:18 <LetoThe2nd> interruptguy: who says that i even need a recipe-core?
May 15 08:02:04 <interruptguy> rburton, makes sense. I just wanted to raise this because there are some common names used (recipe-core, recipe-apps,...)
May 15 08:03:05 <LetoThe2nd> interruptguy: my advice would be to not think of them as some defined things, but just read recipe-"WORD" at face value of "WORD"
May 15 08:04:48 <interruptguy> LetoThe2nd, nothing, I agree. I just want to say that if I see a layer without a recipe-core should I understand something (based on what I said above maybe I should understand that this layer has nothing mandatory in it)
May 15 08:05:05 <rburton> no, theyre just logical groupings that only make sense for *that layer*
May 15 08:05:27 <LetoThe2nd> interruptguy: i think you try to see definition or implications where there aren't any.
May 15 08:05:33 <rburton> recipes-core is probably core functionality but there's no implication beyond that
May 15 08:05:43 <interruptguy> LetoThe2nd, My only issue was that WORD is sometimes common. Maybe some layers use it in some way others in other ways
May 15 08:05:49 <LetoThe2nd> interruptguy: it *could* have been defined like that years ago, but it just wasn't
May 15 08:07:24 <LetoThe2nd> i could have a directory called recipes-eroc thats meant to be the opposite of core :)
May 15 08:07:55 <interruptguy> Thanks :). I'm porting some apps to some layers and just wanted to know if there is a rule about this. I would just use the logical grouping advice local to the layer
May 15 08:08:19 <interruptguy> LetoThe2nd, wouldn't that be sepicer-eroc? :)
May 15 08:08:37 <LetoThe2nd> interruptguy: no. look at conf.layer.conf to see why :)
May 15 08:08:45 <interruptguy> :D
May 15 08:08:46 <interruptguy> ok
May 15 08:08:58 <TafThorne> Does the directory name matter when you are applying patches to an existing recipie?
May 15 08:09:13 <interruptguy> you can change the layer-conf :D
May 15 08:09:41 <LetoThe2nd> interruptguy: but thats outside the scope of the discussion, we were talking about recipe-* :)
May 15 08:09:42 <TafThorne> It could be eroc+sepicer?
May 15 08:09:47 <LetoThe2nd> but technically right, yes.
May 15 08:10:05 <interruptguy> LetoThe2nd, :)
May 15 08:10:27 <LetoThe2nd> i'm not sure on special characters, and spaces will certainly will break stuff. but theres fun to be had.
May 15 08:24:24 <yocti> New news from stackoverflow: Listing SRC_URI of all packages/files needed to build Yocto image <https://stackoverflow.com/questions/50345536/listing-src-uri-of-all-packages-files-needed-to-build-yocto-image> || Yocto recipe : how to install in specific folder <https://stackoverflow.com/questions/31293420/yocto-recipe-how-to-install-in-specific-folder>
May 15 08:42:38 <T_UNIX> has anybody ever ended up with corrupted permissions in a final image? I.e. interrupted and continued job leading to that?
May 15 08:43:45 <T_UNIX> It's a rather serious issue, because the log output of two machines (same source base) looks almost identical (no relevant differences). Yet I have to extract the ubifs just to verify some permissions :-/
May 15 08:44:02 <T_UNIX> I.e. the built image cannot be trusted to be correct
May 15 08:58:57 <ivan_> Let: Finally build finished
May 15 08:59:19 <ivan_> Leto: Logs from tmp/log/cooker/imx6guf/20180515114636.log : https://www.codepile.net/pile/GkNdDr0b
May 15 08:59:38 <ivan_> and for the error : /yocto/GUF-Yocto-jethro-11.0-r8139-0/build-imx6guf/tmp/work/cortexa9hf-vfp-neon-mx6qdl-guf-linux-gnueabi/weston/1.9.0-r0/temp/log.do_configure.128767 : https://www.codepile.net/pile/e7ky5mAd
May 15 09:01:14 <ivan_> As mentioned yesterday the only modification I've done is in local.conf file adding DISTRO_FEATURES_append = " mesa cairo wayland weston" CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
May 15 09:01:47 <LetoThe2nd> that layer list is awful
May 15 09:02:09 <LetoThe2nd> and it looks like that you got all those as a monolithic blob?
May 15 09:02:51 <ivan_> Yes, whole pack is from here
May 15 09:02:52 <ivan_> http://support.garz-fricke.com/projects/Santaro/Linux-Yocto/Releases/yocto-jethro-santaro-overview.html
May 15 09:03:14 <ivan_> Its for this HW https://www.garz-fricke.com/en/products/embedded-systems/panel-mount-hmi/IA-0015R/#
May 15 09:03:41 <LetoThe2nd> really tell tehm to screw themselves and hand out a proper bsp instead of some cobbled up tarball
May 15 09:04:33 <LetoThe2nd> there's no way for us to see which upstream state it refers, or what is going on inside
May 15 09:04:34 <ivan_> even that I wish to, I don't think this is a conciderable option for the moment
May 15 09:05:12 <LetoThe2nd> then your only proper option is, IMHO, to extract a proper BSP from that horror and use it with a clean upstream state
May 15 09:06:54 <LetoThe2nd> rip out bootloader, kernel and MACHINE definition into a small layer of your own. then use that on top of a standard poky and meta-openembedded. proceed from there
May 15 09:08:27 <TafThorne> I could kind of do with knowing the answer to that last Stack Overflow question too.  I did a crude check of the ports I need open on a firewall by calling  rgrep -ho '\w*://' | sort | uniq -c  on an unbuilt work area.  IT might be happier if I could show them a list of URLs I needed the FPT ports open for.
May 15 09:35:07 <sveinse> How is the mechanism for checking for changes in the sources? Where can I find more about it?
May 15 09:35:31 <LetoThe2nd> sveinse: "in the sources"?
May 15 09:36:32 <sveinse> It does not check if EXTERNALSRC is used, right? So if one wants to use EXTERNALSRC, one needs to add an SRC_URI. So is the source checker bound to SRC_URI?
May 15 09:37:26 <sveinse> Yeah, if one uses SRCREV="${AUTOREV}" is is able to detect changes to the sources and determine a rebuild when necessary
May 15 09:37:46 <sveinse> Is it solely based on the hash by the scm?
May 15 09:38:39 <sveinse> It's this mechanism I would like to know better
May 15 09:39:09 <LetoThe2nd> ah. sorry, no idea.
May 15 09:41:54 <sveinse> I have a in-layer sources and I need to figure out how to set it up properly wrt SRCREV and rebuilds. It's not straight forward
May 15 10:28:24 <acrap> Hi, folks! I am looking for task dependencies theme. You know, for do_patch we need to have a quilt-native. How does it work?
May 15 10:29:39 <acrap> I am interested in what is "populate_sysroot dependencies" (https://patchwork.openembedded.org/patch/136198/)
May 15 10:35:29 <RP> acrap: that is a pretty huge topic, can you be more specific. I assume you're looked at the manuals?
May 15 10:36:26 <acrap> RP: looks like I've found something here: BitBake manual 3.9.5. Inter-Task Dependencies
May 15 10:36:34 <acrap> https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies
May 15 10:38:45 <RP> acrap: right, there are the DEPENDS and RDEPENDS variables and the [depends] task flag
May 15 10:39:30 <RP> acrap: addtask [before X] [after Y] is the other main ordering mechanism
May 15 10:40:25 <acrap> RP: yep, thanks. I've found what I was searching for.
May 15 10:57:16 <sveinse> How can I set SRCPV with SRCREV in a in-meta source recipe?
May 15 10:59:20 <sveinse> I.e. how can I find the SRCREV for the current meta layer?
May 15 11:36:24 <sveinse> How do I ensure a in-meta source recipe is build when it should, yet still not built excessively, like on every incovation?
May 15 12:31:50 <TafThorne> Doesn't it fingerprint the source files and no change = no build?
May 15 12:36:02 <sveinse> TafThorne: How? Through what variable?
May 15 12:46:48 <sveinse> Through SRC_URI it seems
May 15 12:55:21 <yocti> New news from stackoverflow: cmake error in falcom compilation in yocto-krogoth <https://stackoverflow.com/questions/50350572/cmake-error-in-falcom-compilation-in-yocto-krogoth>
May 15 13:03:42 <sveinse> Can I control where bb unpacks/copies the SRC_URI sources? Setting S isn't enough apparently
May 15 13:04:32 <sveinse> I'd like them in ${WORKDIR}/src rather than just in ${WORKDIR} where it might clobber all of bbs directories
May 15 13:14:26 <JPEW> Is there a YPTM today?
May 15 13:15:08 <T_UNIX> could anybody point me to documentation about how bitbake avoid race conditions/multiple instances?
May 15 13:15:52 <T_UNIX> and how it does its bookkeeping about where to continue a package (its tasks)?
May 15 13:28:45 <TafThorne> T_UNIX: Do you want to know what to do in recipies to avoid it or did you want to know the nuts and bolts of how bitbake does it?
May 15 13:29:51 <TafThorne> The BitBake User Manual's Execution chapter goes over things in a high level.  Mentions the way it seperates tasks into stages which each get time-stamped, only redoing later stages if an earlier one has a later timestamp etc.
May 15 13:30:31 <TafThorne> Then it goes on to say you should look at the task schedualer if you want to know more about it or change the behavpour.  BB_SCHEDULER and CC_SCHEDULERS.
May 15 13:35:24 <T_UNIX> TafThorne: I'm seeing odd behavior in combination with ci runners :-/
May 15 13:35:59 <TafThorne> Have you got a basic setup or shared download and cache areas?
May 15 13:36:33 <TafThorne> I use to have a Yocto build setup by repo running under Jenkins OK.
May 15 13:37:51 <T_UNIX> TafThorne: I have a shared downloads and sstate directory
May 15 13:38:20 <TafThorne> Ah, well I never had anything that fancy setup.
May 15 13:39:16 <JoeR> Interesting question, as I am, right this moment, trying to get the same thing going. It seems to play ball ok with a shared downloads dir, but I've never quite understood/trusted the shared cache amongst multiple runners.
May 15 13:39:36 <T_UNIX> TafThorne: thanks, I'll read the docs :)
May 15 13:39:57 <T_UNIX> JoeR: yeah, what's a horror is that it does *not* warn about any failed job
May 15 13:40:39 <T_UNIX> I believe it must have been a second runner executing the very same machine setup concurrently
May 15 13:41:25 <T_UNIX> leading to some kind of race-condition
May 15 13:41:51 <T_UNIX> since the executable in question's recipe and source didn't change for months :-/
May 15 13:43:03 <JoeR> I'll live without sharing the cache at the moment, going for clean nightlies instead. Not perfect, but it shouldn't be dev work at that point, merely releasable artifacts. I'm interested if you sort it out though! :-)
May 15 13:43:05 <T_UNIX> JoeR: I guess you'll *really* want to make sure, that under no condition there's a second runner accessing the same information/paths (e.g. bitbake's `tmp`)
May 15 13:44:29 <TafThorne> I thought that the shared cache stuff done via SSTATE_DIR  was more about having multiple work areas and projects on a single machine share files.  So only 1 job is accessing the cache at a time but you can re-use the stuff in it.
May 15 13:45:15 <TafThorne> So if I build for 4 targets and have 4 seperate yocto work areas (not just seperate build directories) I can still share cache.
May 15 13:45:26 <T_UNIX> TafThorne: I think you're right about that.
May 15 13:45:49 <TafThorne> But the downloads stuff is safe to share between multiple machines to share a building's internet connection.
May 15 13:46:12 <TafThorne> As I have used neither before, I would not trust my memory much.
May 15 13:46:13 <T_UNIX> but, apparently, bitbake does not install locks or whatever to prevent a second instance from running the same setup
May 15 13:46:52 <TafThorne> adding locking would be slow.  It is (runtime) quick to tell developers do not do that, it will probably fail.
May 15 13:47:12 <JoeR> It's a shame, 'cos the cache is the biggest time and storage saver. Sharing it amongst multiple machines would be nice.
May 15 13:49:36 <TafThorne> If it saves enough time, is it worth serialising your jobs?
May 15 13:49:42 <T_UNIX> TafThorne: I'm talking about an initial lock. Like the usual pid thing you do in `/run` for any daemon.
May 15 13:50:15 <TafThorne> Or I've heard of doing a nightly build and copying the cache from that onto all the other machines as a seed.
May 15 13:51:26 <JoeR> That's quite a neat idea.
May 15 13:52:57 <sveinse> We share sstate cache over a http server from the main build server to all the devs. That works brilliantly and saves a ton of time for them
May 15 13:55:30 <yocti> New news from stackoverflow: QtWebEngine: ERR_SSL_PROTOCOL_ERROR on custom Yocto image <https://stackoverflow.com/questions/50352025/qtwebengine-err-ssl-protocol-error-on-custom-yocto-image>
May 15 14:22:28 <vishnu_nk> Hi All,
May 15 14:22:28 <vishnu_nk> I want to upload the prebuilt binaries of gcc-cross to a common server.
May 15 14:22:29 <vishnu_nk> But when the prebuilt binaries are used to run build, I'm getting error from cc1, saying limpc.so.3 not found.
May 15 14:22:29 <vishnu_nk> Is there a way to configure the toolchain so that the prebuilt binaries can be used in other machines also?
May 15 14:22:29 <vishnu_nk> Please help.
May 15 14:22:34 <vishnu_nk> Can anyone please help?
May 15 14:25:47 <LetoThe2nd> vishnu_nk: a particular reason why you are not using the sdk mechanisms that are meant to do exactly that?
May 15 14:26:37 <vishnu_nk> Did you mean populate_sdk() task?
May 15 14:49:44 <fberg> hello guys,. Does anybody know how to show the actual DISTRO_FEATURES used by bitbake ?
May 15 14:50:13 <fberg> Is it also passible to show which recipe set a particular DISTRO_FEATURE ?
May 15 14:50:36 <Tartarus> fberg: In the first, bitbake -e is your friend
May 15 14:50:45 <Tartarus> ie: bitbake -e busybox | grep -E ^DISTRO_FEATURES=
May 15 14:51:21 <LetoThe2nd> vishnu_nk: yeah, exactly. that produces a cross toolchain which is meant to be transportable to another host
May 15 14:52:02 <fberg> Tartarus: thanks, but I need quite the opposite. I need to know which recipe sets wayland as DISTRO_FEATURE
May 15 14:52:09 <fberg> i'm going crazy
May 15 14:52:28 <Tartarus> fberg: recipes shouldn't be adding to that, only checking for it
May 15 14:52:34 <Tartarus> it should be your distro.conf
May 15 14:52:47 <Tartarus> if you $PAGER bitbake -e rather than grep you'll get some hints about where things are coming in from
May 15 14:52:50 <fberg> Tartarus, thanks that's agoo hint
May 15 14:52:54 <LetoThe2nd> fberg: there should be a complete modification history in bitbake -e
May 15 14:54:02 <fberg> thanks guys
May 15 14:57:08 <fberg> mmm waylend is in POKY_DEFAULT_DISTRO_FEATURES
May 15 14:57:13 <fberg> wayland*
May 15 14:58:02 <fberg> this feature is parsed here: https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-graphics/userland/userland_git.bb
May 15 14:59:05 <JoeR> I add it to my DISTRO_FEATURES_remove in my local.conf. I dunno if that's the right way to do it mind you...
May 15 14:59:07 <fberg> my yocto image uses gstreamer1.0-omx and when it is called launch this error:  0x577040 ERROR                    omx gstomx.c:159:gst_omx_core_acquire: Failed to load module '/r/lib/libopenmaxil.so': /usr/lib/libbrcmEGL.so: undefined symbol: wl_callback_interface
May 15 14:59:58 <vmeson> YPTM: Randy is on hold and wondering if the meeting is a go...
May 15 15:00:06 <fberg> if i do a: #nm -D /usr/lib/libbrcmEGL.so get
May 15 15:01:03 <sjolley> YPTM: Starting Call   - dial into: 1-800-262-0778/404-397-1527   - enter the bridge number: 88748961#
May 15 15:01:10 <sjolley> YPTM: Stephen Joined
May 15 15:01:23 <stephano> YPTM: Stephano joined
May 15 15:01:25 <arbrindle_> YPTM: Amanda joined
May 15 15:01:27 <RP> sjolley: https://docs.google.com/document/d/1Lr8KgkmmCZ84RF_ThIwnT3WWxMv_tUsHkpRV5PXTd0s/edit#heading=h.7gautn3hmzga
May 15 15:01:33 <vmeson> YPTM: Randy joined -- first post, err join.
May 15 15:01:55 <fberg> U wl_callback_interface
May 15 15:02:46 <wmills> YPTM here (BIll MIlls TI)
May 15 15:02:58 <Tartarus> YPTM: Tom Rini joined
May 15 15:03:14 <kanavin> YPTM Alexander
May 15 15:03:34 <fberg> wl_callback i think is related to some wayland library: libwayland-server.so
May 15 15:03:56 <fberg> and libwayland-client.so
May 15 15:04:28 <fberg> both of the are in my image /usr/lib/ folder
May 15 15:04:33 <JPEW_> YPTM: Joshua Watt here
May 15 15:04:44 <fberg> wtf's happening ?
May 15 15:05:02 <npongratz> YPTM Nick
May 15 15:05:25 <JoeR> fberg: It's the monthly technical call.
May 15 15:05:31 <leon-anavi> hi, I'm Leon Anavi
May 15 15:05:50 <leon-anavi> I've also joined the monthly tech call for the first time in my career.
May 15 15:06:15 <sveinse> YPTM: sveinse (Svein) joined
May 15 15:06:53 <vmeson> YP 2.6 'big ideas list':  https://docs.google.com/document/d/1Lr8KgkmmCZ84RF_ThIwnT3WWxMv_tUsHkpRV5PXTd0s/edit#heading=h.7gautn3hmzga
May 15 15:07:49 <rburton> YPTM ross  joined finally, was foolishly dialing into the intel bridge
May 15 15:08:57 <Tartarus> rburton: My 2 cents on status of secure stuff since last call is we're waiting for that conf that's later this month to happen before moving forward as it sounds like stuff will be made more visible there.
May 15 15:09:00 <Tartarus> Sound about right to you?
May 15 15:09:47 <rburton> Tartarus: that conf would be a good milestone to keep  an eye on
May 15 15:10:47 <fray> YPTM: Mark joined...
May 15 15:11:38 <wmills> can I get the link here again?
May 15 15:11:52 <vmeson> YP 2.6 'big ideas list':  https://docs.google.com/document/d/1Lr8KgkmmCZ84RF_ThIwnT3WWxMv_tUsHkpRV5PXTd0s/edit#heading=h.7gautn3hmzga
May 15 15:12:01 <vmeson> wmills: ^^^ that one?
May 15 15:12:19 <rburton> wmills: or https://www.yoctoproject.org/monthly-technical-call/
May 15 15:12:24 <wmills> yep thanks
May 15 15:15:15 <neverpanic> fberg: That looks normal to me, libbrcmEGL.so should link against the library that provides wl_callback_interface.
May 15 15:15:29 <JaMa> YPTM: JaMa joined
May 15 15:15:48 <fberg> neverpanic, I think it too
May 15 15:16:00 <fberg> but I have both the libraries in /usr/lib
May 15 15:16:58 <fberg> I expected that once called libbrcmEGL would use libwayland-server.so
May 15 15:17:19 <fberg> I'm not an expert on these topics so don't be rude with me :)
May 15 15:19:41 <sveinse> I've been working on Intel Altera Cyclone V Hard CPU FPGAs, but ditched it, because of its maturity
May 15 15:20:19 <sveinse> Got Yocto up and running, but wasn't able to get too far due to driver issues
May 15 15:20:25 <neverpanic> I don't want to write a lot of stuff while the meeting is going on to avoid disturbing everybody, but from the output you provided it is not clear that's not what has happened.
May 15 15:23:05 <sveinse> There are added complexities with using FPGA-based systems, e.g. like the set of peripherals and access are configurable, so you'll need a sceheme for plugging the DTB into the kernel
May 15 15:25:56 <yocti> New news from stackoverflow: Yocto: Adding Kernel Module to Image <https://stackoverflow.com/questions/50353474/yocto-adding-kernel-module-to-image>
May 15 15:28:04 <khem> YPTM: khem joined
May 15 15:30:11 <moto-timo> YPTM: moto-timo joined
May 15 15:30:42 * moto-timo thought it was at 8:30 for some reason
May 15 15:33:51 <tlwoerner> it's nice to see there was a technical call today, it would have been nicer if an invite had gone out (or are these meetings invite-only?)
May 15 15:34:38 <sveinse> tlwoerner: it's still on-going
May 15 15:35:29 <stephano> tlwoerner: https://lists.yoctoproject.org/pipermail/yocto/2018-May/041159.html
May 15 15:35:56 <stephano> tlwoerner: we should probably find a better way to track these meetings than sending out an invite to the whole list
May 15 15:36:04 <stephano> perhaps a google calendar or something of the sort.
May 15 15:36:44 <tlwoerner> YPTM: tlwoerner is on! :-D
May 15 15:36:46 <tlwoerner> stephano: thanks
May 15 15:37:30 <tlwoerner> stephano: +1 a google calendar would be nice :-)
May 15 15:37:37 <tlwoerner> (or something of that sort)
May 15 15:37:49 <stephano> Yeah, the mailing list invites are easy to miss.
May 15 15:38:20 <tlwoerner> stephano: there was an invite sent, then a cancel was sent with a promise of a new invite, but i never saw the new invite
May 15 15:38:47 <sjolley> The new invite came from me, not stephano.
May 15 15:39:22 <tlwoerner> sjolley: ah
May 15 15:44:56 <kergoth> hmm, dont think i saw the new invite either, must have been lost in the inbox
May 15 15:47:31 <wmills> still don't have edit access to notes so here is the "preflight" bug ID https://bugzilla.yoctoproject.org/show_bug.cgi?id=12749
May 15 15:47:32 <yocti> Bug 12749: enhancement, Undecided, ---, richard.purdie, NEW , Add ability to do "preflight" by using sstate
May 15 15:48:49 <tlwoerner> kergoth: by searching the yocto list for Stephen Jolly explicitly i was able to find it (from 5 days ago), but yea, it got lost in there somewhere :-)
May 15 15:49:09 <RP> wmills: refresh as I approved you
May 15 15:56:02 <yocti> New news from stackoverflow: How to apply a patch to a file in the root file system in yocto recipe <https://stackoverflow.com/questions/50354297/how-to-apply-a-patch-to-a-file-in-the-root-file-system-in-yocto-recipe>
May 15 16:00:53 <sjolley> YPTM: Stephen has to drop.
May 15 16:05:06 <khem> YPTM: Khem has to drop for another call
May 15 16:08:13 <vmeson> tlwoerner: have you looked at: https://github.com/jiazhang0/meta-secure-core as well?
May 15 16:09:30 <tlwoerner> vmeson: i haven't, does it complement meta-security/meta-measured, or is it a replacement?
May 15 16:13:40 <tlwoerner> hmm... the layer index seems to get confused by meta-secure-core
May 15 16:14:46 <tlwoerner> i guess it's because meta-secure-core is a layer of layers repository
May 15 16:18:19 <wmills> GStreamer dependency on rust was new to me. any more info?
May 15 16:18:50 <wmills> FOSDEM 2018 presetation I found says" No plans to make it a hard dep in core components."
May 15 16:18:50 <vmeson> tlwoerner: I'm sure there is overlap, a former co-worker is the repo owner.
May 15 16:20:08 <tlwoerner> vmeson: okay, thanks.
May 15 16:20:33 <tlwoerner> i'm starting a spreadsheet to list the contents of meta-measured, meta-security, meta-secure-core, and their versions to see the landscape
May 15 16:20:53 <tlwoerner> i'll post a link to the oe-architecture list when i'm done
May 15 16:20:58 <vmeson> tlwoerner: that's a good start. thx!
May 15 16:20:58 <fray> cool
May 15 16:23:48 <RP> wmills: kanavin or rburton or maxin may be able to elaborate
May 15 16:29:03 <rburton> wmills: gstreamer was a hunch based on maintainer interest.  librsvg has already ported, it's less fundamental than gstreamer so we're managing so far
May 15 16:29:07 <vmeson> wmills: it does still seem to be externally maintained: https://gstreamer.freedesktop.org/releases/1.14/
May 15 16:45:07 <wmills> rburton: vmeson:  Thanks.  I am sure Rust will come up again anyway
May 15 16:47:00 <rburton> yes pretty sure
May 15 17:06:40 <smurray> hopefully it's stabilizing some, iirc the meta-sota folks broke down and rewrote the client side in C++ to avoid needing rust because it was hard to keep up with upstream...
May 15 17:12:29 <elektro> hi folks, i have problem on toaster web page lists are always empty. Any suggestion ?
May 15 17:13:43 <dreyna> Hi Electro, if you are using thenew  default Suma release then you should know that it will be a while before the layer owners will update their content to Sumo
May 15 17:14:14 <dreyna> You can use "master" or "rocko" in the meantime
May 15 17:14:31 <vmeson> smurray: rust never sleeps :-P
May 15 17:14:33 <elektro> i am using rocko branch
May 15 17:15:23 <dreyna> electro, I have a meeting at the moment, I can come back later  and debug it,
May 15 17:15:31 <dreyna> (but it was workign for me)
May 15 17:16:09 <elektro> c ya dreyna
May 15 17:46:34 <elektro> i have sam issue https://stackoverflow.com/questions/49518731/yocto-toaster-compatible-image-recipes-is-zero-empty-where-all-recipes
May 15 17:46:52 <elektro> any suggestions ?
May 15 17:58:52 <dreyna> elektro: I know why Rocko is broken. There was a commit that missed being pushed (it did get added to Sumo). I will find the bug and its workaround
May 15 18:22:24 <khem> rburton: Please pick http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu for next integration cycle
May 15 18:24:29 <dreyna> electro: bug entered as "Bug 12751 - Rocko needs backport of custom.xml issue". You will find a quick workaround there are well: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12751
May 15 18:24:31 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=12751 normal, Undecided, ---, david.reyna, NEW , Rocko needs backport of custom.xml issue (bug 12554)
May 15 18:24:32 <yocti> Bug 12751: normal, Undecided, ---, david.reyna, NEW , Rocko needs backport of custom.xml issue (bug 12554)
May 15 19:10:52 <desert> I have a strange problem with network usage
May 15 19:10:59 <desert> openssh, mosquitto, mostly everything works
May 15 19:11:15 <desert> but using a software that needs 9010
May 15 19:11:25 <desert> I found I cant open ports
May 15 19:11:36 <desert> tested with nc (busybox) and netcat
May 15 19:11:59 <desert> nc -lv 8521   (or whatever) seems to wait forever and never open the port
May 15 19:12:39 <desert> it never appears on   netstat -tunap
May 15 19:12:48 <desert> and the port never opens
May 15 19:13:07 <desert> however I *do* use ssh, dnsmasq and several others
May 15 19:15:04 <kergoth> i'd gdb or strace to see exactly what syscall is blocking
May 15 19:15:44 <desert> on OLAD found this: https://imgur.com/mYLHNjy
May 15 19:15:53 <desert> but im 100% sure the port is open
May 15 19:15:58 <khem> there is a kernel option IIRC to enable nc as well
May 15 19:18:10 <khem> kergoth: I am looking for a way to recurse into a specific function of all recipes needed for an image is there an easy way
May 15 19:18:38 <khem> kergoth: usecase is e.g. I want to run static analysis but not really build/compile the image
May 15 19:18:50 <elektro> dreyna: thanks
May 15 19:19:13 <desert> khem: you mean I need to enable that option, can you point me a hint on how to google about it?
May 15 19:19:32 <desert> why ssh, mosquitto, dnsmasq work, and not olad,nc ?
May 15 19:19:44 <dreyna> elektro: let me know if you have any additional issues. Thank you for the error report.
May 15 19:20:01 <khem> so I have cooked up a class which adds a new task do_scanbuild but now I am looking to stitch together dep tree such that do_scanbuild for dependend recipes also get executed
May 15 19:21:25 <khem> desert: is there firewall on the system
May 15 19:21:33 <desert> no
May 15 19:21:48 <elektro> dreyna: ok :)
May 15 19:22:05 <desert> khem:  iptables -nL gives me empty chains
May 15 19:23:57 <khem> and no selinux
May 15 19:26:29 <desert> I used nodejs example bound to the same 9010 port
May 15 19:26:31 <desert> and it works
May 15 19:26:42 <desert> why netcat and olad do not ?
May 15 19:26:46 <desert> this is perplexing
May 15 19:28:48 <nayfe> maybe nftables is conflicting?
May 15 19:29:16 <desert> whats nftables?
May 15 19:30:06 <desert> this is my manifest http://pastebin.ca/4027605
May 15 19:30:13 <desert> I dont see nftables
May 15 19:36:30 <desert>  netcat -lv 127.0.0.1 9009 does not even work on 127.0.0.1
May 15 19:36:43 <desert> but nodejs does
May 15 19:37:45 <desert> please take a look http://pastebin.ca/4027617
May 15 19:57:56 <elektro> dreyna: hi again patch for bug12571 solve my problem, fyi
May 15 20:07:29 <nayfe> desert: maybe an implementation issue; did you look at https://stackoverflow.com/questions/3886506/why-would-connect-give-eaddrnotavail ?
May 16 00:30:12 <desert> nayfe: but why netcat hangs in _newselect(4, [3], NULL, NULL, NULL....
May 16 00:30:25 <desert> https://pastebin.ca/4027617
May 16 01:27:54 <yocti> New news from stackoverflow: grpc 1.4.3 patch & installation <https://stackoverflow.com/questions/50361091/grpc-1-4-3-patch-installation>
May 16 02:43:25 <khem> desert: whats your architecture/libc/kernel versions
**** ENDING LOGGING AT Wed May 16 03:00:11 2018