**** BEGIN LOGGING AT Tue Apr 11 03:00:03 2017
Apr 11 10:00:02 <ndec> RP: Crofton|work : right. i didn't mean that using poky was required. it was just simpler.. i am now able to use yocto-compat-layer without poky and with oe-core + bitbake.. we have bitbake in non standard place, so i had to use BITBAKEDIR.. 
Apr 11 10:00:46 <heeen> was there a way to have do_patch do a git apply instead of patch -p1
Apr 11 10:00:55 <heeen> I remember dimly
Apr 11 10:01:18 <heeen> I think it would be nice to have a class like externalsrc tailored around git
Apr 11 10:02:02 <bluelightning> heeen: PATCHTOOL = "git"
Apr 11 10:02:03 <heeen> do_patch would apply patches and remember the state, and some new task would generate a list of patches to bring into the recipe
Apr 11 10:02:24 <bluelightning> heeen: not quite what you're describing but you've seen devtool modify, right?
Apr 11 10:02:51 <heeen> as in: I patch from the recipe, the patches end up as commits, then I commit on top and a task would write a patch file and output the list of patches to update a recipe with
Apr 11 10:02:59 <heeen> bluelightning: no
Apr 11 10:03:02 <heeen> what is it
Apr 11 10:05:24 <bluelightning> heeen: basically extracts the source for a recipe into a git tree (with any patches as commits) and sets up externalsrc automatically so you can work on the source
Apr 11 10:05:50 <heeen> sounds a lot like what I described
Apr 11 10:06:07 <bluelightning> heeen: you can then modify the tree, test it, update the commits and when you're done it can turn the commits back into updated patches next to the recipe
Apr 11 10:06:45 <bluelightning> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe
Apr 11 10:07:00 <heeen> If you wish, test your changes on the target. There's a "devtool deploy-target" command which will copy the files installed at do_install over to the target machine assuming it has network access, and any dependencies are already present in the image. 
Apr 11 10:07:03 <heeen> holy shit
Apr 11 10:07:05 <heeen> so cool
Apr 11 10:07:27 <heeen> I have been living on externalsrc or S_pn override and scp
Apr 11 10:11:49 <heeen> bluelightning: does it work with both src archives and git checkouts?
Apr 11 10:12:07 <bluelightning> heeen: yes
Apr 11 10:12:23 <heeen> <thumbs up emoji>
Apr 11 10:55:38 <Crofton> ndec, thanks, maybe we can make sure how to use the layer for all cases in the READM.md :)
Apr 11 12:20:21 <ndec> Crofton: somehow i can't parse your sentence ;-)
Apr 11 12:20:33 <ndec> maybe you need to try in French ;-)
Apr 11 12:59:14 <Crofton> lol
Apr 11 12:59:31 <Crofton> ndec,  the compat stuff should work for all users
Apr 11 12:59:43 <Crofton> sounds like you made progress
Apr 11 12:59:53 <ndec> Crofton: yes. sure. and it likely does..
Apr 11 13:00:01 <Crofton> and it should accept README.md as a valid readme
Apr 11 13:00:04 <Crofton> good
Apr 11 13:00:12 <ndec> i was a bit lazzy last night, and went with poky to start with.. but now it works fine with oe-core.
Apr 11 13:00:27 <Crofton> How does it look? 
Apr 11 13:00:29 <ndec> ah, that is more a 'compliance' thingy. 
Apr 11 13:00:52 <Crofton> anything that helps make BSP's easier for people like koen to consume is a good thing :)
Apr 11 13:00:57 <ndec> e.g. not sure what the YP compliance requires.. it might very require 'README'. it's easy to add symlink though..
Apr 11 13:01:17 <Crofton> ndec, We can define compliance
Apr 11 13:01:46 <Crofton> the point of the README is have a consistent place to gte som einfo about the layer
Apr 11 13:02:18 <Crofton> READNE and REAME.md both meet the goal of steering users quickly to one place
Apr 11 13:02:56 <Crofton> I need to run, meeting family for breakfast
Apr 11 13:03:02 <Crofton> thanks a lot for taking a look at this
Apr 11 13:03:21 <Crofton> more eyes on this, the better the tool will be for improving BSP behavior
Apr 11 14:04:45 <ndec> RP: should/could we relax the constraint on the 'README' file name? and allow more than README (e.g. README.md) or do you think it's better to stick to README and create symlink if needed?
Apr 11 14:07:40 <RP> ndec: good question. I'm kind of leaning towards having a master README existing...
Apr 11 15:28:12 <kergoth> I think we should definitely allow README.md and README.rst
Apr 11 15:28:21 <kergoth> i can't remember the last time i had an unsuffixed readme, as i want github to properly render it
Apr 11 15:28:24 * kergoth shrugs
Apr 11 15:28:48 <kergoth> also means my custom lesspipe will use mdless to render it in a console
Apr 11 15:42:16 <ndec> well, i added a symlink in my layer for now.. this isn't too bad.. 
Apr 11 17:10:09 <fabo> khem: can you point me to your systemd bbappend to no create empty machine-id?
Apr 11 17:11:08 <fabo> khem: I'm thinking to use https://github.com/fboudra/meta-96boards/commit/dcfe91f7c80e6b73f80c947f7d33a000b97c675a
Apr 11 17:19:45 <khem> fabo: that looks fine. my solution was an image post process hack 
Apr 11 17:20:02 <fabo> ok
Apr 11 19:23:42 <Crofton> I think github is going to make README.md popular, and what I do not want happening is  README for compliance, then a .md with actual content
Apr 11 19:53:01 <kergoth> Crofton: agreed. i haven't used anything but README.md in a long time
Apr 11 20:24:01 <ndec> fabo: I think it should go to our distro layer instead of bsp. And it should be noop if our distro is not set.
**** ENDING LOGGING AT Wed Apr 12 03:00:01 2017