**** BEGIN LOGGING AT Wed Jun 13 03:00:02 2018
Jun 13 06:11:39 <erbo_> anujm: you were right about wic images. I just retried and it works just fine, I wonder how I managed to not get it working the first time, maybe I messed something up trying to use _remove instead of just overriding it.
Jun 13 06:11:49 <erbo_> so thank you!
Jun 13 07:07:12 <yocti> New news from stackoverflow: how to build debian rootfs for imx6d <https://stackoverflow.com/questions/50830755/how-to-build-debian-rootfs-for-imx6d> || Issue when integrating different bsp-layers on a single bblayers.conf [closed] <https://stackoverflow.com/questions/50744231/issue-when-integrating-different-bsp-layers-on-a-single-bblayers-conf>
Jun 13 07:37:20 <yocti> New news from stackoverflow: test can yocto image <https://stackoverflow.com/questions/50569257/test-can-yocto-image>
Jun 13 07:55:54 <sveinse> Hi, JaMa, what is the relationship between meta-qt5 on github and the Qt meta-qt5 repo: http://code.qt.io/cgit/yocto/meta-qt5.git/ ?
Jun 13 08:04:38 <JaMa> sveinse: the later is fork by Qt
Jun 13 08:08:19 <sveinse> JaMa: Is their commits fed back into the the github meta-qt5?
Jun 13 08:09:09 <sveinse> I'm specifically working on getting Qt 5.11 up and running in our system, and there are a couple of bug fixes that they have made that isn't yet in the github repo
Jun 13 08:15:40 <JaMa> sveinse: sometimes they submit something, but you need to ask them
Jun 13 08:20:21 <sveinse> JaMa: ok, thanks
Jun 13 08:37:36 <yocti> New news from stackoverflow: Gnome Shell closed unexpectidely <https://stackoverflow.com/questions/50832633/gnome-shell-closed-unexpectidely>
Jun 13 09:13:55 <kir> Hey guys. I have a tricky question. I'm running Linux subsystem for Windows 10, and try to execute a binary compiled as a part of Poky SDK for the same architecture, but under bare metal. It says: bash:./program cannot execute binary file: Exec format error.
Jun 13 09:14:08 <kir>  At the same time the output of file is x86_64-poky-linux-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /opt/poky/2.0.3/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32
Jun 13 09:14:19 <kir> uname -a is Linux ... 4.4.0-17134-Microsoft #1-Microsoft Tue Apr 10 18:04:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
Jun 13 09:22:38 <erbo_> kir: I guess you might run in to all sort of issue, but what I would try is to make sure that /opt/poky/2.0.3/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 is a symlink to /lib/ld-linux.so.2
Jun 13 09:23:05 <erbo_> since it appear that you don't have any Poky SDK installed in /opt/poky, right?
Jun 13 09:23:18 <kir> erbo_, I have
Jun 13 09:23:59 <kir> ./program here stands for any program from SDK, including x86_64-poky-linux-gcc/g++, etc
Jun 13 09:25:02 <kir> so I'm basically failing with this issue running the fresh installation of SDK, made via the sdk installer, built under other computer
Jun 13 09:25:24 <kir> basically I didn't have problems like that just running the sdk-installer on a random ubuntu machine
Jun 13 09:29:24 <StefanoVR> Hi all, I'm going crazy on something trivial, but I could not find anything on the documentation, I need to include in my work-shared/kernel-build-artifacts the Makefile and a link to the source, I see that this is possible because a build made from an hardware supplier distribuition do this, but I am unable to find the way to do this
Jun 13 09:29:53 <StefanoVR> and I am not able to do this on my own build
Jun 13 09:45:31 <hattzy> kir: I have the same issue, but we have had it working earlier. In my specific case it fails when i source the SDK with ".../sysroots/x86_64-heartOSsdk-linux/usr/bin/qt5/qmake: cannot execute binary file: Exec format error"
Jun 13 09:46:02 <nayfe> Hi, do you know when gcc8 (host) support will be available?
Jun 13 09:55:17 <kir> hattzy, had it working earlier? Wow
Jun 13 09:56:10 <kir> did you fix it somehow?
Jun 13 09:58:11 <rburton> nayfe: gcc8 on host should work with sumo/2.5 iirc
Jun 13 09:58:24 <rburton> morning arfoll!
Jun 13 10:00:18 <ant_work> rburton, hi there
Jun 13 10:00:27 <hattzy> kir: not yet but trying to. We had it working until begining of may, since then my toolchain does not work. Trying to debug it but so far our workaround is to run ubuntu in a VM
Jun 13 10:00:35 <nayfe> rburton: mornin :) in fact I tried sumo on fedora 28 and it fails on linux-yocto for instance, i saw some patches from Khem on ML
Jun 13 10:01:03 <rburton> nayfe: surely the kernel is using the cross-compiler
Jun 13 10:01:10 <rburton> unless that's a bit of host-built tooling
Jun 13 10:01:12 <kir> hattzy, I see, I do the same
Jun 13 10:02:41 <rburton> RP: did a buildhistory-diff on the two hashes in the report.  kernel modules all grow a little but there's obviously been a change to debug info as the staticdevs and dbg packages all grow a lot
Jun 13 10:02:51 <kir> hattzy, did you try other distro's available in Windows store?
Jun 13 10:03:07 <rburton> RP: ie libgcrypt-dbg grows from 7M to 8M
Jun 13 10:03:30 <hattzy> kir: no
Jun 13 10:03:35 <rburton> RP: libstdc++-staticdev goes from 28 to 52M!
Jun 13 10:05:48 <nayfe> rburton: with machine=qemu, it selects host gcc?
Jun 13 10:15:19 <rburton> nayfe: no, it will always use the compiler we built to cross-build
Jun 13 10:15:23 <rburton> nayfe: can you pastebin the logs?
Jun 13 10:16:01 <RP> rburton: ouch!
Jun 13 10:19:49 <nayfe> rburton: i applied this patch https://patchwork.openembedded.org/patch/151488/ for 'objtool, perf: Fix GCC 8 -Wrestrict error' patch
Jun 13 10:20:20 <nayfe> rburton: I'll remove it and pastebin
Jun 13 10:27:05 <rburton> RP: m1 on the new ab cluster?
Jun 13 10:27:14 <rburton> (ie can i fire on yocto.io)
Jun 13 10:28:13 <RP> rburton: you can fire, M1 is completing on .io
Jun 13 10:28:22 <RP> rburton: the other cluster is a mess atm, sorry :/
Jun 13 10:28:47 <nayfe> rburton: it is described here https://patchwork.openembedded.org/patch/151479/
Jun 13 10:28:51 <RP> rburton: just two bits left
Jun 13 10:29:56 <RP> rburton, nayfe: objtool may be host compiled
Jun 13 10:32:26 <nayfe> btw, i'll prolly switch back to supported distro for further devs as I suppose a lot of layers will fail on similar gcc8 errors
Jun 13 10:32:39 <rburton> ah fair enough
Jun 13 10:32:46 <nayfe> :D
Jun 13 11:08:09 <yocti> New news from stackoverflow: How to build customer added *.bb files on Yocto project? <https://stackoverflow.com/questions/39343921/how-to-build-customer-added-bb-files-on-yocto-project>
Jun 13 11:38:14 <yocti> New news from stackoverflow: cmake error in falcon compilation in yocto-krogoth <https://stackoverflow.com/questions/50350572/cmake-error-in-falcon-compilation-in-yocto-krogoth>
Jun 13 11:38:42 <nayfe> Hi back, do you know any doc about Intel bootloaders stuff, like grub grub-efi, uefi, u-boot maybe? etc...
Jun 13 12:05:54 <RP> rburton: this may make adding 1804 to the cluster interesting for older releases :/
Jun 13 12:43:57 <yates> i can understand what this error is; https://paste.fedoraproject.org/paste/xuD9SNuqqR0z2ig9y7s0kQ
Jun 13 12:44:10 <yates> can't
Jun 13 12:46:01 <yates> i'm trying to buld something using morty run f27 - are there any known "tweaks" to get things to run right on f27?
Jun 13 12:46:18 <yates> s/using morty run/using morty on/
Jun 13 12:51:08 <yates> rburton: any thoughts?
Jun 13 12:52:44 <nayfe> can't you update yocto?
Jun 13 12:55:34 <rburton> basic answer is don't run morty on f27
Jun 13 12:55:37 <rburton> it doesn't support it
Jun 13 12:56:10 <rburton> help2man: can't get `--help' info from automake-1.15
Jun 13 12:56:23 <rburton> there's a patch in newer stable branches to fix that
Jun 13 12:57:21 <rburton> but you'll just break somewhere else, so its up to you: use a supported host distro (in a container) or work through all the errors, looking at a release which does support f27 for potential fixes
Jun 13 12:57:29 <yates> what is the lastest version that DOES run on f27?
Jun 13 12:58:17 <rburton> latest release, probably
Jun 13 12:59:03 <rburton> considering the age of morty i think we'd all encourage you to upgrade
Jun 13 12:59:12 <yates> since "yocto" isn't a package installed as an RPM package, how do you upgrade?
Jun 13 12:59:45 <yates> i've been scouring your site, but it doesn't jump at me
Jun 13 13:00:08 <rburton> change oe-core from morty to sumo, read release notes for relevant changes, make changes
Jun 13 13:00:30 <rburton> repeat for every layer you use
Jun 13 13:00:50 <yates> that's a PITA
Jun 13 13:01:07 <LetoThe2nd> mhhhh... pita.... </greekmode>
Jun 13 13:01:12 <rburton> if you have a better way, please say
Jun 13 13:01:16 <yates> update very layer? you mean every meta-xyz?
Jun 13 13:01:20 <rburton> yes
Jun 13 13:01:35 <yates> LetoThe2nd: Pain In The Ass
Jun 13 13:01:49 <yates> not the bread
Jun 13 13:01:50 <rburton> unlikely that eg meta-qt5 from morty will even build with oe-core sumo
Jun 13 13:01:57 <LetoThe2nd> yates: don't worry, i got you.
Jun 13 13:02:34 <yates> hokay.
Jun 13 13:02:45 <rburton> LetoThe2nd: local cafe does sweet chilli/rocket/halloumi toasted flatbreads
Jun 13 13:03:30 <LetoThe2nd> rburton: if it wasn't just after my lunch break, i'd say go and get me one.
Jun 13 13:03:32 <rburton> yates: because new oe-core will have new gcc which old software will fail to build with
Jun 13 13:04:20 <yates> rburton: i don't see why that would happen. if you issue -std=c++xy ...
Jun 13 13:04:26 <yates> vice-versa, yes
Jun 13 13:04:29 <rburton> lols
Jun 13 13:04:42 <rburton> yates: it took us a month to get gcc8 ready to merge
Jun 13 13:05:31 <yates> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Jun 13 13:05:32 <yates> Copyright (C) 2015 Free Software Foundation, Inc.
Jun 13 13:05:32 <yates> This is free software; see the source for copying conditions.  There is NO
Jun 13 13:05:32 <yates> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Jun 13 13:05:36 <LetoThe2nd> yates: actually i guess you're seriously underestimating the amount of magic that bitbake hides from you.
Jun 13 13:07:15 <rburton> yates: random example as something i fixed up http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=dfe68bd9642d65c7157dbfea62795ba3a848d530
Jun 13 13:08:07 <yates> you're talking about the python compiler?
Jun 13 13:09:06 <rburton> that was a gcc8 fix for the python runtime yes
Jun 13 13:09:10 <boucman_work> yates: honestly, the only sane way to develop an embedded system is to have both host and yocto always be on latest version of whatever distro you are using
Jun 13 13:09:31 <boucman_work> anything else will be a huge mess when you release your product and CVE will have piled up to the sky
Jun 13 13:09:45 <boucman_work> seriously, I've been through that previously, don't do it.
Jun 13 13:09:49 <LetoThe2nd> boucman_work: disagreed. the only sane way is to have them in a consistent state that matches your requirements.
Jun 13 13:09:53 <yates> it was the latest version when we started.
Jun 13 13:10:06 <boucman_work> yes, but not anymore, that's my point...
Jun 13 13:10:18 <rburton> yates: i hope you've been tracking the morty branch for the two years of security fixes
Jun 13 13:10:19 <boucman_work> LetoThe2nd: not sure what you mean by that, please explain
Jun 13 13:10:58 <LetoThe2nd> boucman_work: there are more than enough examples for embedded systems that do not have connectivity to the outside world. in that case, CVEs are perfectly pointless, for example.
Jun 13 13:11:25 <LetoThe2nd> boucman_work: if that is your requirement, then there is absolutely no reason to invest the time and effort into staying at HEAD
Jun 13 13:11:35 <yates> rburton: are you referring to the security of the generated linux image?
Jun 13 13:12:03 <yates> but no, i have not tracked.
Jun 13 13:12:30 <yates> LetoThe2nd: what's "CVE"?
Jun 13 13:12:34 <boucman_work> ah, agreed...
Jun 13 13:12:46 <LetoThe2nd> boucman_work: or, if you have to certify certain build processes, etc.
Jun 13 13:13:10 <boucman_work> it's just... I have had my head in the embedded+connected mess for so long it kinda went out of my radar
Jun 13 13:13:21 <LetoThe2nd> boucman_work: i'm willing to agree that your position holds true for *MANY* usecases. but its certainly not the only sane way, as you named it so bluntly.
Jun 13 13:13:35 <boucman_work> yates: it's a database of every security vulnerability
Jun 13 13:13:43 <LetoThe2nd> yates: feel free to ask the search engine of your least distrust about "CVE"
Jun 13 13:13:56 <boucman_work> LetoThe2nd: ok, I was a bit radical...
Jun 13 13:14:15 <rburton> yates: you really should at least switch to latest morty point release
Jun 13 13:14:36 <LetoThe2nd> boucman_work: :)
Jun 13 13:14:39 <yates> rburton: i don't even know what you mean. what is a morty "point" release?
Jun 13 13:14:39 <cornel> hello
Jun 13 13:14:54 <cornel> sstate found an absolute path symlink ...
Jun 13 13:14:58 <boucman_work> but the most common reason embedded system stay on old release in the R&D phase is "we are too afraid to upgrade" so I tend to jump the guns...
Jun 13 13:15:02 <cornel> is this error fixed somewhere?
Jun 13 13:15:14 <yates> i get a bunch of hits about "Rick and Morty"...
Jun 13 13:15:46 <cornel> or: is it fixed in poky? openembedded? or elsewhere?
Jun 13 13:15:48 <LetoThe2nd> boucman_work: like i said, "it depends"
Jun 13 13:18:23 <boucman_work> :)
Jun 13 13:18:30 <yates> rburton: what did you mean by "in a container">
Jun 13 13:18:33 <yates> ?
Jun 13 13:18:47 <LetoThe2nd> yates: a point release means, that its a minor release just carrying bugfixes and security fixes, but no new features. hence, a point after the main version. like 1.0 -> 1.1 -> 1.2
Jun 13 13:19:05 <LetoThe2nd> yates: your definition might vary, but that a largely agreed-on one.
Jun 13 13:19:44 <yates> LetoThe2nd: right, thanks. i should've figured thatout
Jun 13 13:19:58 <LetoThe2nd> cornel: "this" error probably refers to a specific recipe or such?
Jun 13 13:20:16 <cornel> java
Jun 13 13:20:20 <cornel> LetoThe2nd: ^
Jun 13 13:20:51 <LetoThe2nd> cornel: well then look at the upstream of said recipe providing layer :)
Jun 13 13:21:10 <cornel> LetoThe2nd: i see things like this: https://lists.yoctoproject.org/pipermail/yocto/2017-October/038616.html
Jun 13 13:21:24 <cornel> but after cloning the rgit repo i don't find the coommit
Jun 13 13:22:19 <yates> is there a link to a cross-reference of yoxto versions and compatible linux distroes/releases?
Jun 13 13:23:03 <LetoThe2nd> cornel: because: https://lists.yoctoproject.org/pipermail/yocto/2017-October/038617.html
Jun 13 13:24:18 <yates> i sse this: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ubuntu-packages
Jun 13 13:24:45 <cornel> thank you LetoThe2nd
Jun 13 13:25:07 <cornel> unfortunately i'm stupid enough to not understand if this change was merged or not and in what branch
Jun 13 13:25:23 <khem> yates: https://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#detailed-supported-distros
Jun 13 13:25:41 <LetoThe2nd> yates: https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan
Jun 13 13:25:56 <khem> rburton: I see you mentioning size increases in static packages is that new after yesterday ?
Jun 13 13:26:07 <yates> it states in section 1.1, "Currently, the Yocto Project is supported on the following distributions: ", but what is "the Yocto project"? morty?
Jun 13 13:27:41 <LetoThe2nd> cornel: the log suggests that it has not been merged: http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/log/recipes-devtools/oracle-java/oracle-jse-jdk.inc
Jun 13 13:28:32 <cornel> thank you LetoThe2nd
Jun 13 13:28:48 <cornel> i'll try to find ways to fix this
Jun 13 13:29:32 <LetoThe2nd> cornel: how about just applying that two lines to your local checkout, for a first try?
Jun 13 13:30:23 <cornel> i'll try right now
Jun 13 13:30:47 <nayfe> rburton: regarding this patch https://patchwork.openembedded.org/patch/150795/ as you mentioned it, will it be merged in sumo?
Jun 13 13:31:09 <khem> yates: norty is codename for yocto project 2.2 release for more see https://wiki.yoctoproject.org/wiki/Releases
Jun 13 13:32:44 <khem> nayfe: send a request to mailing list for backport or sending a patch would be even better
Jun 13 13:33:44 <rburton> khem: yeah, static and dbg packages got a lot bigger with gcc8
Jun 13 13:37:21 <khem> rburton: OK, I think it is kind of expected to grow a bit since It includes column information in addition to just filenames and line numbers in DWARF debugging information now
Jun 13 13:37:49 <yates> khem: thanks.
Jun 13 13:38:08 <khem> and secondly it is keeping language-specific information in debug info so that LTO can work better
Jun 13 13:38:42 <yocti> New news from stackoverflow: Gumstix Overo SSD1306 OLED <https://stackoverflow.com/questions/50838656/gumstix-overo-ssd1306-oled>
Jun 13 13:40:00 <rburton> khem: would that explain 40M->50M for libstdc++-staticdev?
Jun 13 13:48:25 <cornel> LetoThe2nd: other errors prevent me from reporting today if this is working fine or not :(
Jun 13 13:48:32 <cornel> i'll report more tomorrow
Jun 13 13:48:35 <cornel> thank you very much
Jun 13 13:49:18 <nayfe> khem: for backport, i just apply your patch and send it to ML with sumo tag?
Jun 13 14:08:42 <khem> nayfe: yes after you have validated that it works on sumo
Jun 13 14:08:53 <khem> rburton: I think so
Jun 13 14:09:32 <khem> rburton: you can try with -g -fno-gcolumn-info
Jun 13 14:09:59 <khem> and see if reduces to somewhere near gcc7 sizes, although I still expect it to be a bit more
Jun 13 14:13:43 <varjag> :)
Jun 13 14:38:53 <yocti> New news from stackoverflow: Yocto and the generation of images when using repository of signed rpm packages <https://stackoverflow.com/questions/50042523/yocto-and-the-generation-of-images-when-using-repository-of-signed-rpm-packages>
Jun 13 15:39:06 <yocti> New news from stackoverflow: Auditd in Yocto <https://stackoverflow.com/questions/50840889/auditd-in-yocto>
Jun 13 15:41:23 <khem> rburton, RP we need a new uninative tarball to include the fontforge-native fix
Jun 13 15:41:53 <khem> right now we have the fix but default uninative tarball is older than that fix
Jun 13 16:03:04 <rburton> khem: also gcc8 is 5 minutes slower for a test sato build
Jun 13 16:06:00 <khem> rburton: is that full system test timing or single test
Jun 13 16:06:11 <rburton> khem: bitbake core-image-sato
Jun 13 16:06:40 <khem> rburton: so full test. I wonder if we have time stamps
Jun 13 16:08:20 <rburton> Biggest increase in cputime
Jun 13 16:08:20 <rburton> gcc-cross-initial-i586.do_compile	+234 s
Jun 13 16:08:20 <rburton> gcc-cross-i586.do_compile	+220 s
Jun 13 16:08:20 <rburton> linux-yocto.do_compile_kernelmodules	+156 s
Jun 13 16:08:22 <rburton> linux-yocto.do_compile	+152 s
Jun 13 16:08:22 <rburton> mesa.do_compile	+117 s
Jun 13 16:10:51 <rburton> khem: https://wiki.yoctoproject.org/charts/build_perf/latest/ypperf-ubuntu16_master_qemux86.html
Jun 13 16:11:39 <rburton> khem: i'm guessing we just have to say 'yep'
Jun 13 16:15:39 <kergoth> rburton: i have a few pending bits in meta-mentor surrounding optional deps or rdeps which are gplv3. I currently have them checking to see if those would be incompatible, and if so, dropping the dep implicitly rather than having the recipe unbuildable (i.e. perf, lvm2), with a utility function wrapping incompatible_license_contains(). thoughts on that going into meta-gplv2? on the one hand, just implicitly dropping the deps isn't great, but not being
Jun 13 16:15:39 <kergoth> able to build the recipes even though they're usable without the deps isn't ideal either
Jun 13 16:15:43 <kergoth> thoughts?
Jun 13 16:15:54 <rburton> kergoth: sounds neat, actually
Jun 13 16:16:45 <rburton> there's one recipe in core that changes its depends based license iirc
Jun 13 16:17:50 <kergoth> okay, thanks, I'll see about adding the utility function (wraps incompatible_license_contains() to also check WHITELIST_<license> for the recipes in question) to oe.license in oe-core and submit the appends to use it to meta-gplv2
Jun 13 16:18:04 <kergoth> just wnated to make sure it didn't sound completely insane before submitting it
Jun 13 16:39:17 <yocti> New news from stackoverflow: meta-virtualization rocko branch unable to locate docker package <https://stackoverflow.com/questions/49517065/meta-virtualization-rocko-branch-unable-to-locate-docker-package>
Jun 13 16:47:31 <kergoth> hrmph. man-db is gplv2, but depends on libpipeline, which is gplv3 as a whole even though its code is gplv2, since it incorporates gnulib
Jun 13 16:47:37 <kergoth> gotta love gnulib...
Jun 13 16:49:45 <rburton> kergoth: gnulib is an abomination
Jun 13 16:49:46 <RP> khem: everything we need for the new uninative has already merged?
Jun 13 16:49:54 <RP> khem: shouldn't be hard to roll a new release
Jun 13 16:50:01 <RP> rburton: do you want to ask Tracy?
Jun 13 16:52:46 <rburton> sure
Jun 13 16:53:25 <rburton> RP: from latest release tag?
Jun 13 16:55:12 <RP> rburton: Since that is M1, that would be good
Jun 13 16:55:33 <rburton> i couldn't remember if the sumo tag had enough in
Jun 13 16:57:39 <rburton> no, it doesn't
Jun 13 16:59:51 <ikkysleepy> Hey guys, what's the best way to have user find a local server, i.e. (eddy.local) works if I know the static ip, say 10.0.0.1 and use /etc/hosts to point eddy.local with Adhoc but seems to fail with using DHCP and no Adhoc wifi setup. I am wondering if there are other settings or ways to insure eddy.local or maybe eddylocalrealdomain.com will always work.
Jun 13 17:04:11 <kergoth> ikkysleepy: install avahi
Jun 13 17:04:52 <ikkysleepy> I have dnsmasq, will that do the same, looking into avahi
Jun 13 17:05:48 <kergoth> no, dnsmasq serves a completely different purpose
Jun 13 17:08:18 <ikkysleepy> great, i'll package it up and test it. Thanks!
Jun 13 18:05:10 <rburton> ikkysleepy: its in oe-core already
Jun 13 18:05:56 <kergoth> wow, our chkconfig is old. 1.3.58/1.3.59 vs 1.10
Jun 13 18:07:24 <rburton> can we drop it yet
Jun 13 18:09:18 <kergoth> i think lsb still requires it.. though there's an argument to be made that either we don't care or that belongs in its own layer..
Jun 13 18:16:55 <linuxjacques> Hi, I need to add --disable-relro to the binutils configuration - where's the correct place to add it ?
Jun 13 18:27:09 <rburton> kergoth: we've kicked plenty out ignoring LSB
Jun 13 18:32:52 <rburton> yeah its just lsb that depends on it
Jun 13 18:33:03 <rburton> i'd definitely kick it to meta-oe
Jun 13 18:33:21 <Crofton|work> Hey, we don't want your junk :)
Jun 13 18:38:38 <JaMa> Crofton|work: +
Jun 13 18:41:26 <igor> Hi guys, since the commit 4880d0f9c808fd50f3eba0d87a804b4dce1334fa that updates llvm recipe, is breaking the llvm build
Jun 13 18:42:09 <igor> on do_package_qa it is complaining about compile-host-path
Jun 13 18:42:30 <igor> I saw the do_compile log and it is using libxml2 from my host
Jun 13 18:43:03 <igor> someone get this error?
Jun 13 18:43:11 <igor> and know how to fix it?
Jun 13 19:02:16 <khem> RP: yes the changes are merged
Jun 13 19:03:12 <RP> khem: https://autobuilder.yocto.io/pub/uninative/2.1/ if you want to test it before its published! :)
Jun 13 19:03:14 <khem> linuxjacques: you need to write a bbappend for binutils in your layer
Jun 13 19:04:09 <linuxjacques> khem, thanks, I was very slowly coming to that conclusion :-)
Jun 13 19:05:55 <khem> linuxjacques: I am curious why you need that option
Jun 13 19:13:43 <linuxjacques> khem, I'm on ppc64be and with recent binutils, no binary is smaller that 60kiB unless I --disable-relro
Jun 13 19:14:42 <linuxjacques> and I'm on an embedded device with limited flash, and it just annoys the heck out of me so see binaries which should be 8kiB be 60kiB
Jun 13 19:15:29 <ikkysleepy> The bblayer is added and bitbake avahi worked but I get an error * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'avahi'.
Jun 13 19:24:38 <kergoth> the recipe is avahi, the packages are named differently. grep oe-core for avahi and you'll see
Jun 13 19:31:26 <altker128> kergoth: Ping
Jun 13 19:39:30 <rburton> anyone got a beaglebone and happy to test something for me?
Jun 13 19:40:38 <khem> rburton: I have pi3 if you need something I can help, bbb I need to flash and bring up
Jun 13 19:44:07 <khem> RP: fontforge-native works with the uninative tarball you pointed to. So go ahead and release it
Jun 13 19:55:44 <ikkysleepy> I see, the package name was "avahi-daemon" thanks
Jun 13 21:22:16 <RP> khem: thanks
Jun 13 22:16:21 <noway96> how do I get the pendulum python library for yocto? poky doesn't have it. Normally I would have RDEPENDS += python-pendulum. But right now that doesn't work because python-pendulum recipe doesn't exist. How do I create it so that it has python pendulum package and it's dependencies?
Jun 13 22:16:58 <noway96> I have the source code + non stdlib dependencies on disk.
Jun 13 22:17:42 <neverpanic> noway96: writing a recipe for a python component is pretty easy. Read the pypi bbclass and a couple of other python recipes and you should be able to figure it out from there
**** ENDING LOGGING AT Thu Jun 14 03:00:04 2018