**** BEGIN LOGGING AT Tue Apr 16 02:59:57 2019
Apr 16 07:05:28 <mckoan> good morning
Apr 16 09:42:53 <yocti> New news from stackoverflow: Multiple configuration build in yocto <https://stackoverflow.com/questions/55705022/multiple-configuration-build-in-yocto>
Apr 16 10:13:03 <yocti> New news from stackoverflow: Yocto - Files/directories were installed but not shipped in any package <https://stackoverflow.com/questions/49748528/yocto-files-directories-were-installed-but-not-shipped-in-any-package>
Apr 16 11:08:47 <JaMa> armpit: please backport "libyaml: update SRC_URI[md5sum] and SRC_URI[sha256sum]
Apr 16 11:08:54 <JaMa> to warrior when you can
Apr 16 11:09:16 <JaMa> I think now you cannot share the same premirror and downloads directory between warrior and master which is quite pita
Apr 16 11:11:00 <JaMa> and thud uses the same version, will need the same
Apr 16 11:43:13 <yocti> New news from stackoverflow: do_compile is not getting called when an image class is inherited in Yocto <https://stackoverflow.com/questions/55707303/do-compile-is-not-getting-called-when-an-image-class-is-inherited-in-yocto>
Apr 16 12:23:01 <armpit> JaMa, ok
Apr 16 12:23:06 <vladzouth> Hi, is anyone experienced systemd services. I add some services in my custom build but that are not started at boot time https://pastebin.com/ubp0aX4D.
Apr 16 12:23:50 <vladzouth> i try to add SYSTEMD_AUTO_ENABLE_${PN} = "enable" but this does not change anything
Apr 16 12:44:16 <nirfr> hi, im looking for an example how to add initial iptables rules
Apr 16 13:08:35 * armpit hmm, my builds went to hell??
Apr 16 14:56:54 <armpit> YPTM armin is one
Apr 16 14:58:40 * armpit one??? on more like it
Apr 16 15:02:05 <RP> armpit: are you waiting for the meeting to start?
Apr 16 15:02:25 <armpit> RP, there are 5 of us
Apr 16 15:02:49 <JPEW_> YPTM: Joshua Watt here
Apr 16 15:02:50 * RP has the wrong number
Apr 16 15:02:53 <JPEW_> 6 now :)
Apr 16 15:03:13 <armpit> dial 011 to call USA
Apr 16 15:04:17 <armpit> https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/edit
Apr 16 15:11:01 <tlwoerner> YPTM: tlwoerner is on
Apr 16 15:11:53 <moto-timo> YPTM: moto-timo joining
Apr 16 15:13:51 <yocti> New news from stackoverflow: Yocto Rocko ld: cannot find -lgcc in glibc 2.23 do_compile <https://stackoverflow.com/questions/53323504/yocto-rocko-ld-cannot-find-lgcc-in-glibc-2-23-do-compile>
Apr 16 15:21:57 <halstead> moto-timo, I don't think there is a bug for failing patchtest but I have spent a few days looking at it.
Apr 16 15:26:47 <moto-timo> I mentioned this on IRC the other day, but interesting tool for mining data: https://github.com/chaoss/grimoirelab-perceval/tree/master/perceval/backends/core
Apr 16 15:27:32 <moto-timo> it is pluggable, e.g. https://github.com/chaoss/grimoirelab-perceval-mozilla/tree/master/perceval/backends/mozilla
Apr 16 15:27:54 <RP> https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc2/testresults/
Apr 16 15:29:18 <armpit> https://autobuilder.yocto.io/pub/non-release/20190324-12/testresults/testresult-report.txt
Apr 16 15:33:08 <halstead> I'm switching to another meeting now.
Apr 16 16:04:08 <JPEW_> moto-timo: Something like this might be a good and easy first step for python dependencies: https://github.com/bndr/pipreqs
Apr 16 16:04:31 <JPEW_> It is pretty simple, it just parses the python code looking for "import" statements
Apr 16 16:24:35 <moto-timo> JPEW_: thanks for the link.
Apr 16 16:25:12 <moto-timo> JPEW_: I've found that tools that only scan the code don't always catch everything, perl modules are especially bad at documenting run-time dependencies
Apr 16 16:25:44 <moto-timo> JPEW_: hence the reason for wanting to use QEMU to do some basic run-time testing during build/development workflow
Apr 16 17:22:10 <JPEW> moto-timo: Sure... I wonder if it is really going to be much worse than actually running the module though (and it is certainly much easier).
Apr 16 17:23:17 <JPEW> moto-timo: Even the ELF parser we use to detect RDEPENDS in compiled code doesn't catch everything (e.g. dlopen()). The expectation there is that you need to add the correct RDEPENDS for them
Apr 16 17:56:08 <moto-timo> JPEW: in the case of libmodule-build-perl I spent about 8 hours cycling through builds and fixing run-time dependencies... :/
Apr 16 17:56:47 <moto-timo> JPEW: and then I could finally run ptest only to find out it wants to run with blib (developer mode)...
Apr 16 17:58:34 <JPEW> moto-timo: Ya that sounds painful
Apr 16 19:57:18 <likewise_> I am using Yocto to build a rootfs with Intel graphics (9th gen), but I would like to remove dependencies on X11 and Wayland. My aim would be OpenGL for purely offscreen rendering to 8K. I don't think this is possible with OpenGL but might be possible with GLES2. Is my assumption correct?
Apr 16 20:06:26 <likewise_> sorry wrong channel, moving over to #intel-gfx
Apr 16 20:21:25 <keith> PACKAGECONFIG = "libevent"
Apr 16 20:21:25 <keith> PACKAGECONFIG[libevent] = "--enable-openssl"
Apr 16 20:21:51 <keith> i thought this would work to configure libevent w/ openssl, but it looks like its applying to other packages too, any ideas?
Apr 16 20:22:34 <JPEW> keith: Where are you putting that?
Apr 16 20:22:39 <keith> in local.conf
Apr 16 20:23:10 <JPEW> PACAKGECONFIG[libevent] = "--enable-openssl" belong in the openssl recipe (and has the wrong format I think)
Apr 16 20:23:39 <keith> hrm, so i would have to fork the recipe?
Apr 16 20:23:50 <keith> i dont know what i'm doing, apologies for the dumb questions :)
Apr 16 20:23:51 <JPEW> to activate it in local.conf, you would to add the pn override: PACKAGECONFIG_pn-openssl = "libevent"
Apr 16 20:24:12 <JPEW> keith: Its fine
Apr 16 20:24:21 <JPEW> You could fork, or add it in .bbappend
Apr 16 20:24:35 <JPEW> Oh, sorry
Apr 16 20:24:58 <JPEW> I got that backwards, I though you were trying to enable libevent in openssl, not the other way around :)
Apr 16 20:25:20 <keith> oh ok, glad we're on the same page :)
Apr 16 20:25:47 <keith> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/libevent/libevent_2.1.8.bb?h=master
Apr 16 20:25:58 <keith> it lists as options: "PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
Apr 16 20:26:13 <JPEW> Ah, right good. You don't need to fork anything
Apr 16 20:26:25 <keith> so if i do PACKAGECONFIG_pn-libevent = "--enable-openssl' it should work?
Apr 16 20:26:30 <JPEW> Add PACKAGECONFIG_pn-libevent = "openssl" to local.conf
Apr 16 20:26:35 <keith> great!
Apr 16 20:27:18 <keith> also, any ideas why when packaging with openssl, I don't have the openssl headers in the SDK?
Apr 16 20:27:27 <JPEW> You enable package config options by their "key" e.g. PACKAGECONFIG = "foo bar" activates PACKAGECONFIG[foo] and PACKAGECONFIG[bar]
Apr 16 20:27:29 <keith> also, libssl is only in the host and not in the crosscompiler
Apr 16 20:27:39 <keith> ok perfect, thx!
Apr 16 20:28:18 <JPEW> I think you need to clarify "packaging" and "SDK"
Apr 16 20:28:25 <JPEW> I don't follow
Apr 16 20:29:27 <keith> I've enabled openssl in my image, and done 'core-image-base -c populate_sdk' and installed the .sh but i dont have openssl headers to cross compile, nor do i have libssl
Apr 16 20:30:22 <JPEW> How did you enable openssl?
Apr 16 20:31:15 <keith> CORE_IMAGE_EXTRA_INSTALL += "openssh alsa-lib opencore-amr alsa-plugins e2fsprogs openssl libevent libopus"
Apr 16 20:31:21 <keith> for right now, eventually plan on building a layer
Apr 16 20:32:04 <JPEW> Hmm, I'm not sure
Apr 16 20:32:33 <JPEW> Are the headers for libevent and libopus present?
Apr 16 20:33:30 <keith> not sure, switching from VM to bare metal, so this is a new install again (but saved my local.conf) and shut down the VM for now
Apr 16 20:34:56 <JPEW> Building in a  VM is painful
Apr 16 20:35:18 <keith> yeah was trying to make it easier to be portable, but wont do that again :)
Apr 16 20:36:10 <JPEW> yocto has some built in support to make it more portable (uninative), or if your really worried I would recommend a container (docker, lxc, etc.)
Apr 16 20:36:40 <keith> yeah, docker is what i should of went with
Apr 16 20:36:51 <keith> but ill just use bare metal for now
Apr 16 20:47:36 <keith> ohh maybe i'm supposed to use: TOOLCHAIN_TARGET_TASK_append="openssl-dev"
Apr 16 20:48:50 <keith> or TOOLCHAIN_TARGET_TASK
Apr 16 20:54:41 <JPEW> That *shouldn't* be necessary if the packages are in your image. bitbake should include the corresponding -dev package for any package in the image
Apr 16 20:55:08 <JPEW> TOOLCHAIN_TARGET_TASK is more for adding things to the SDK that aren't in the image (I think)
Apr 16 21:59:16 <keith> JPEW: its not though..
Apr 16 21:59:41 <JPEW> Are the libraries in your actual image?
Apr 16 22:00:00 <keith> yes
Apr 16 22:00:05 <keith> libcrypto is there
Apr 16 22:01:24 <JPEW> What image are you building?
Apr 16 22:02:22 <keith> core-image-base
Apr 16 22:03:39 <keith> guess could try like core-image-sato and see if it has 'em
Apr 16 22:03:54 <JPEW> keith: core-image-minimal is what I usually use FWIW
Apr 16 22:04:09 <keith> if base doesnt have it, i doubt minimal will :)
Apr 16 22:04:17 <JPEW> ya
Apr 17 00:17:06 <keith> JPEW: well it worked using TOOLCHAIN_TARGET_TASK :P
**** ENDING LOGGING AT Wed Apr 17 02:59:57 2019