**** BEGIN LOGGING AT Mon Feb 05 03:00:02 2018 Feb 05 08:28:54 good morning Feb 05 08:54:00 gm mckoan Feb 05 10:11:45 Hi, anyone here with experience on npm? I found a few issues on npm & OE. One of which I’ve emailed in a patch last night, the next one I’ll email in later. But there is one which -for me- is not so easy to patch: oe fails (with a confusing message) when the npm package name contains capitalized letters. Doing such has been abandoned a long time ago; but the package I need has a (deep) dependency still having it.. Feb 05 12:09:34 what’s the recommended way for maintaining the source for an embedded product using openembedded? is there a template top layer repository or something I should fork? Feb 05 12:12:29 Lightsword: depends a bit on your requirements. Feb 05 12:13:01 we generally do keep local mirrors of the layers we pull in, and add a number of custom ones on top Feb 05 12:13:53 an alternative is to create a custom superset of all your layers, combining them the way poky does it, Feb 05 12:13:59 LetoThe2nd, I guess I’m trying to figure out what the primary repository you would initially clone for the device would look like, the one that references the other layers Feb 05 12:14:50 Lightsword: so you're actually talking more like the build setup stage. the usual suspect these days is repo for that. Feb 05 12:15:14 then there's kis by the bmw it crowd, and a real big lot of homebrew custom scripts. Feb 05 12:15:47 git submodules for a master repo that pulls the others in? or repo? Feb 05 12:15:49 lots of options Feb 05 12:16:08 LetoThe2nd, yeah, I’m trying to figure what best practices for that are and if there’s a good template starting point or example Feb 05 12:16:37 you don't really need an example, just add the layers you want to whatever system you want to use :) Feb 05 12:17:14 https://github.com/rossburton/customdistro is a minimal example i did a while ago using submodules Feb 05 12:18:03 it was mainly about custom local.conf though, the submodule bit was convenient more than anything else Feb 05 12:21:12 ah, ok that makes sense, is there a recommended/standard way for settings up a CI pipeline with OE? Feb 05 12:21:31 buildbot or jenkins both work Feb 05 12:21:53 use whatever you have, or can find, experience with Feb 05 12:21:59 unlike some project, yocto encourages choice Feb 05 12:22:19 s/yocto/oe/, wrong channel ;) Feb 05 12:23:39 I’m also a bit confused about the differences between yocto and oe, is there any particular one I should be using as a base? Feb 05 12:24:27 I’m currently trying to migrate from a hacky custom shell script based build system to something more maintainable :P Feb 05 12:24:41 and add CI Feb 05 12:25:06 Lightsword: i personally would actually vote for poky as a starting base, as you get a coherent package of bitbake + core Feb 05 12:25:32 is there a good example repo that I could fork for that? Feb 05 12:26:15 would I just fork http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/ ? Feb 05 12:26:16 erm.... git clone git://git.yoctoproject.org/poky.git? Feb 05 12:27:04 i mean, what do you expect? a full blown thing that has a directory with a readme inside that says "just drop your app code here, and everything will be magically working"? Feb 05 12:28:36 well no, just trying to figure out where I should start and where I should be putting customizations Feb 05 12:29:11 Lightsword: 1) clone poky 2) add an empty layer 3) put $YOURSSTUFF into $JUSTCREATEDEMPTYLAYER Feb 05 12:38:42 does using repo like xilinx does here make sense? https://github.com/Xilinx/yocto-manifests/tree/rel-v2017.4 Feb 05 12:39:28 i guess it does, otherwise it wouldn't be the default choice for so many people. Feb 05 13:49:38 Lightsword: yocto isn't a thing you download, its an organisation. some of the things yocto helps maintain include bitbake and oe-core Feb 05 14:46:02 armpit_IST, abaco and kwaj are online Feb 05 14:46:27 datacentre planned power outage (new substation to feed it) **** ENDING LOGGING AT Tue Feb 06 03:00:04 2018