**** BEGIN LOGGING AT Wed Feb 21 03:00:03 2018
Feb 21 07:03:19 <yocti> New news from stackoverflow: Cannot build C project by Eclipse when two c sources are in the project <https://stackoverflow.com/questions/48660406/cannot-build-c-project-by-eclipse-when-two-c-sources-are-in-the-project>
Feb 21 08:33:36 <yocti> New news from stackoverflow: Python is Missing gzip.py in Yocto/Bitbake Build <https://stackoverflow.com/questions/48651331/python-is-missing-gzip-py-in-yocto-bitbake-build>
Feb 21 10:33:57 <yocti> New news from stackoverflow: Python 2.7 is missing gzip.py in Yocto/OpenEmbedded Build <https://stackoverflow.com/questions/48651331/python-2-7-is-missing-gzip-py-in-yocto-openembedded-build>
Feb 21 12:01:28 <adca> hi! stupid question: how do I get  the name/path of recipe used for build when run: bitbake <recipe_name>?
Feb 21 12:05:59 <jvacek_> Hey guys, I'm new to yocto and embedded linux in general. I'm trying to bake an core-image-minimal but with some addes packages such as logrotate and either syslogd or rsyslogd. I understand I need to make a recipe to include these in my image, but I'm trying to figure out where would be a good starting point to read up about this process in general. Any pointers would be appreciated :)
Feb 21 12:07:45 <neverpanic> jvacek_: logrotate and syslogd already have existing recipes, see http://layers.openembedded.org/layerindex/branch/master/recipes/?q=logrotate and http://layers.openembedded.org/layerindex/branch/master/recipes/?q=syslogd
Feb 21 12:08:08 <neverpanic> Also, your can configure your image to come with systemd, which has journald, which may also fulfill your requirements
Feb 21 12:08:16 <LetoThe2nd> jvacek_: look at https://wiki.yoctoproject.org/wiki/images/1/1d/Ypdd-2017.02-ELC-Portland.pdf
Feb 21 12:08:36 <neverpanic> In general, the bitbake user manual is helpful when writing recipes: http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html
Feb 21 12:08:47 <neverpanic> everything else can usually be found in the mega manual at http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html
Feb 21 12:09:07 <jvacek_> ah these aqre of great help already! thanks :)
Feb 21 12:09:10 <LetoThe2nd> jvacek_: pages 76 onwards explain pretty much exactly what you are asking.
Feb 21 13:44:17 <laplante> Having trouble understanding something about the Autobuilder. Does it distribute a single image/recipe build across the cluster? Or does it distribute a set of image builds (i.e. each slave/worker builds a single image)?
Feb 21 13:46:23 <rburton> laplante: each machine runs several workers, each worker is given a job such as nightly-arm which does a lot of building
Feb 21 13:46:43 <rburton> the parallelisation is at the job level, not the task or image
Feb 21 13:48:32 <laplante> rburton: Got it, thanks! Has there been any work or experimentation wrt implementing the latter?
Feb 21 13:48:56 <rburton> use icecc or similar if you want to do that
Feb 21 13:50:10 <rburton> (lots of fixes in master if you actually want to do that)
Feb 21 13:50:58 <laplante> Sweet, I'll take a look at icecc. Though I'm just wondering if there are any opportunities for Yocto/BitBake to take it a step further by analyzing the dependency chain and distributing the build based on that.
Feb 21 13:51:48 <rburton> possibly, if you want to investigate it.  the autobuilder has such a large test matrix that wouldn't achieve anything
Feb 21 13:53:18 <rburton> unless you're building webkit the biggest bottleneck in builds is running configure.ac
Feb 21 13:53:22 <rburton> which can't be parallelised
Feb 21 13:54:04 <rburton> if you build webkit then icecc or backporting the fixes they just landed to half the compile time would help
Feb 21 13:56:01 <laplante> I was thinking of implementing a sort of poor-man's solution now, using multiple workers sharing a common SSTATE_DIR and DL_DIR over NFS.
Feb 21 13:56:21 <laplante> Trouble is there really aren't any leaf-nodes in the dependency graph (since it all converges into the final image), so it would need some clever heuristics and scheduling.
Feb 21 13:57:18 <laplante> You're probably though, icecc would likely outperform it
Feb 21 13:58:01 <laplante> Certainly something I'd like to investigate in the future though
Feb 21 13:59:28 <rburton> if you had access to the sstate then a remote-worker that runs on another machine shouldn't be *that* hard to implement
Feb 21 13:59:42 <rburton> quite invasive though so speak to RP or kergoth first :)
Feb 21 14:01:10 <JPEWhacker> laplante: If you have questions about icecc, I'm the one that made the recent improvments
Feb 21 14:01:51 <laplante> JPEWhacker: might take you up on that :)
Feb 21 14:03:43 <laplante> rburton: Certainly will do :)
Feb 21 14:06:27 <rburton> JPEWhacker: thanks for those :)
Feb 21 14:09:59 <ejoerns> JPEWhacker, great. will test with those, cause current icecc stuff breaks my builds..
Feb 21 14:12:03 <JPEWhacker> rburton: No problem. Are you making use of it?
Feb 21 14:12:18 <rburton> JPEWhacker: nope, just pleased to see someone is :)
Feb 21 14:14:40 <JPEWhacker> ejoerns: Make sure you get the 4 patches from poky-contrib/jpew/master
Feb 21 14:14:47 <JPEWhacker> They aren't in master yet
Feb 21 14:17:27 <ejoerns> JPEWhacker, yes saw 3 of them on oe-core list. thanks for the hint. I'll take all 4 from git
Feb 21 14:19:29 <rburton> JPEWhacker: i believe they're all in ross/mut in the same repo, if you could check?
Feb 21 14:24:41 <JPEWhacker> rburton: Yes they are.
Feb 21 14:27:02 <u1106> I need to make a temporary hack to one of my recipes. I would like to write a warning to the build from the same location, so the hack is not forgotten in the long term. How do I do that?
Feb 21 14:28:25 <rburton> u1106: bb.warn or bbwarn, depending if you're in python or shell
Feb 21 14:29:52 <u1106> rburton: tnx http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#recipe-logging-mechanisms
Feb 21 14:37:23 <slashnull> Is there any docs or understanding of what is considered a long term kernel release for yocto.  I am having trouble understanding how the yocto ecosystem works.
Feb 21 14:38:21 <rburton> slashnull: for the kernels we ship the current LTSI releases for long-term support
Feb 21 14:39:06 <slashnull> I am used to deploying customized Centos7 installations to common x86_64 platforms, so I am used to following the Centos7 kernel (for security patches and long term support).
Feb 21 14:39:35 <slashnull> Does this not make sense in yocto, to follow the 3.10.0 kernel for an ARM distrobution?
Feb 21 14:39:35 <laplante> u1106: If it's just a local modification on your own build machine, you could also use devtool to do it, e.g. with:   devtool modify <recipename>
Feb 21 14:41:17 <rburton> slashnull: eg master currently has 4.15 (stable) and 4.14 (longterm).
Feb 21 14:42:53 <slashnull> So in a centos distro there is a large collection of tools and programs that are kept in sync with their supported kerenel. Is yocto the same way with say the 4.14 longterm?
Feb 21 14:43:45 <slashnull> I guess the real question is how do the two differ as far as kernel and tool support go?
Feb 21 14:44:33 <zeddii> 4.15 will be dropped in the fall release, but 4.14 will persist.
Feb 21 14:44:40 <u1106> laplante: no I think I have to commit my hack to our local git to be used in all our builds for some weeks
Feb 21 14:48:28 <slashnull> Looks like 4.14 LTSi is only 2-3 years.  Any tips or suggestions on longer support?  This is one of the reasons I wanted to track a Centos kernel and toolsets.
Feb 21 14:49:46 <slashnull> I do not know enough about yocto yet but I was thinking perhaps it could get it to crosscompile srpms for the latest Centos release and use that for my package feed.  Am I way off base in my understanding of how this works?
Feb 21 14:49:58 <slashnull> Perhaps I am putting the cart before the horse.
Feb 21 14:50:47 <rburton> slashnull: if you need support for more than 3 years, you should probably pay someone who has support contracts.  obviously you want updates in more than just the kernel...
Feb 21 14:51:04 <pn> Hi all, I have updated the meta-openembedded's NodeJs version in rocko branch (From 8.4.0 to 8.9.4). But this needs a dependent patch in poky repo (which is already in master). Can I cherry-pick the commit and send the patch for rocko branch? Note: Changes are in npm.bbclass
Feb 21 14:51:40 <rburton> pn: generally branches don't get security udpates
Feb 21 14:51:47 <rburton> i mean, branches don't get version upgrades
Feb 21 14:54:12 <slashnull> rburton: not sure I understand, who would I pay and for what? If I track centos, I have the updates I desire.
Feb 21 14:54:53 <pn> rburton: I can put the needed NodeJS version in my project overlay. But, how to update the pocky's rocko branch in this case? Can't be done?
Feb 21 15:02:24 <slashnull> rburton: Thanks for the help you gave.  It was much appreciated.
Feb 21 15:31:15 * armpit hmm auh assumes poky
Feb 21 15:42:40 <silviof> Hi, I have several circular dependencies in my project. What is the best way to understand this big red messages?
Feb 21 15:49:20 <rburton> armpit: huh that's a bug. how?
Feb 21 15:49:49 <rburton> armpit: (popping out, but please do file a bug)
Feb 21 15:49:58 <armpit> k
Feb 21 16:05:05 <yocti> New news from stackoverflow: Bitbake, dynamic lib non-explicite dependency <https://stackoverflow.com/questions/48910042/bitbake-dynamic-lib-non-explicite-dependency>
Feb 21 16:05:14 <silviof> Noone has experiejces with circular dependencies?
Feb 21 16:06:34 <JPEWhacker> silviof: Actual log messages would help (please not in IRC though, use pastebin or something)
Feb 21 16:15:10 <silviof> JPEWhacker: Its more a question about handling of this topic. I get a list of 6 dep loops. every loop has a big list of task with depends on other task. And this list is soooo big noone understand the loop. My first approch is to put all this stuff in a graphic editor (yed) to see the where the problems hit the ground.
Feb 21 16:18:35 <JPEWhacker> What phase of building does the loop occur? Usually they seem to happen during filesystem image creation
Feb 21 16:34:55 <rburton> silviof: if you can, try bitbake master as that has better loop detection.  otherwise its often easier to just pick a point and dig manually with hints from the log
Feb 21 16:35:08 <rburton> silviof: that said pastebin it if you can
Feb 21 16:44:36 <rburton> oh shush autobuider
Feb 21 16:46:27 <stephano> SWAT: rburton is aware of the failures
Feb 21 16:46:39 <rburton> SWAT: ross forgot to drop a patch we know is broken
Feb 21 16:47:15 <stephano> SWAT: ross needs more sleep
Feb 21 16:47:22 <rburton> erm yeah
Feb 21 16:47:29 <stephano> :)
Feb 21 16:47:30 <rburton> finished work at 2am last night
Feb 21 16:47:50 <stephano> there is no finish to work anymore
Feb 21 16:47:53 <stephano> we just ignore it now
Feb 21 16:48:10 <rburton> "luckily" the kids were ill so no 7am wake up for school
Feb 21 16:48:30 <stephano> yay illness?  :)
Feb 21 16:48:49 <rburton> definitely not yay but silver lining :)
Feb 21 16:48:53 <stephano> ha ha ha
Feb 21 16:48:54 <stephano> indeed
Feb 21 16:49:36 <rburton> khem: nightly-arm64 Build: OK \o/ \o/ \o/
Feb 21 17:02:38 <silviof> rburton: JPEWhacker Thanks, I will try that!
Feb 21 17:05:20 <yocti> New news from stackoverflow: can not build Qt5 framework by Yocto project for qemuarm <https://stackoverflow.com/questions/48610858/can-not-build-qt5-framework-by-yocto-project-for-qemuarm>
Feb 21 17:25:51 <armpit> is Juro here?
Feb 21 17:28:08 <armpit> rburton, RP , any in site to the pyro gcc update?
Feb 21 18:20:07 <khem> rburton: ok cool
Feb 21 18:20:20 <khem> hopefully this make 2.30 builds clea
Feb 21 18:20:22 <khem> n
Feb 21 18:20:42 <khem> now I wonder what should we do about 2.27, I looked at reverting
Feb 21 18:21:01 <khem> but it cant be reverted since there is slew of patches to localedata after that change
Feb 21 18:23:27 <rburton> khem: last few jobs on the ab are still running but looks good
Feb 21 18:23:31 <rburton> yeah glibc is annoying
Feb 21 18:23:48 <rburton> would be nice if it would notice the format isn't compatible and just not read it, instead of crashing
Feb 21 18:26:26 <khem> rburton: time and again we are forced to create own distro
Feb 21 18:26:42 <khem> I think we should just use docker templates
Feb 21 18:27:05 <khem> nobody is interested in fixing interworking compatibilities
Feb 21 18:28:15 <scottrif> Are builds working with poky/master?  'bitbake core-image-minimal' getting an OE-Core config sanity checker error.   Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Feb 21 18:30:09 <rburton> scottrif: that means your networking is broken
Feb 21 18:30:33 <rburton> scottrif: maybe you turned on the vpn but don't have proxies setup properly?
Feb 21 18:31:41 <scottrif> rburton: I am using a machine outside of Intel.  No VPN
Feb 21 18:32:16 <rburton> then your networking isn't working right.  we just try to fetch that URL to verify you have something resembling working internet
Feb 21 18:32:36 <scottrif> hmm... ok.  Weird.  maybe a reboot.
Feb 21 18:35:56 <scottrif> rburton: After reboot still getting it.  My internet on all other points seems fine.
Feb 21 19:46:13 <JPEWhacker> armpit: What do you drive that can take 15 people to OEDAM?
Feb 21 19:59:30 <paulbarker> That is a good question
Feb 21 20:14:09 * khem thinks armpit drives others crazy
Feb 21 21:19:30 * armpit yocti is so negative
Feb 21 21:20:48 <kergoth> RP: do we have a way to say 'this task depends on what that other task depends on, but not that other task itself'?
Feb 21 21:21:14 <JPEWhacker> kergoth: I think he said we was out today in an e-mail
Feb 21 21:21:18 <kergoth> ah
Feb 21 21:21:23 <kergoth> thanks
Feb 21 21:25:46 <RP> kergoth: I'm back now just catching up! :)
Feb 21 21:25:58 <RP> kergoth: that is quite hard to do sadly :/
Feb 21 21:26:39 <kergoth> I have a case where i want to wrap another task. i.e. modify metadata and run it, so the wrapper task should dep on the same things the original does
Feb 21 21:27:25 <kergoth> not a big deal, can always pull the flags over, but was curious
Feb 21 21:27:36 <JPEWhacker> Whats the distinction between wrapping the task and overriding it completely?
Feb 21 21:29:18 <kergoth> i'm not replacing it. this is an additional task, run on demand with bitbake -c
Feb 21 21:30:13 <JPEWhacker> Ah, ok makes sense
Feb 21 21:30:33 <RP> kergoth: I don't think we have good API for that
Feb 21 21:30:43 <kergoth> okay, figured. thanks
Feb 21 21:31:59 <kergoth> Hmm, we could use the syntax we have for -c, i.e. foo:do_bar-, and make that valid in other contexts, like depends. obviously incredibly low priority, but that might be cleanest
Feb 21 21:32:09 * kergoth adds to his someday/maybe list
**** ENDING LOGGING AT Thu Feb 22 03:00:04 2018