**** BEGIN LOGGING AT Fri Apr 12 02:59:57 2019 Apr 12 04:06:19 https://www.irccloud.com/pastebin/Bf8SkMtM/ Apr 12 04:06:29 er, sorry. Apr 12 04:06:36 https://www.irccloud.com/pastebin/9iJkzJn1/ Apr 12 04:06:36 Anyone used meta-python lately in OE? Apr 12 07:33:56 Is anyone using grub2 ? I can't find any place in oe-core's image generation code where grub-* tools are called.. Apr 12 13:13:13 is it possible that layer submission at http://layers.openembedded.org is broken? When I enter a gitlab url, a wrong webinterface type ("(custom)") is selected, uris are incorrect and can can not be changed Apr 12 13:22:44 why are dots (.) prohibited in layer names there? Apr 12 13:49:20 I have a do_deploy() that uses files from SRC_URI. Those files seem to get wiped by rm_work inbetween rebuilds I think. Is there a way I should mark those files, so that they get re-populated by setscene tasks, or something like that ? Apr 12 14:20:00 hopefully easy question - I'm writing a tool using tinfoil and I want to make sure BB_SRCREV_POLICY is set to 'cache'. Does anyone know a programmatic way of doing this? Apr 12 14:24:59 nvm, looks like I can create a temporary post.conf with "BB_SRCREV_POLICY = 'cache'", then create a TinfoilConfigParameters with postfile=["post.conf"] which I pass to tinfoil.prepare() Apr 12 15:47:48 laplante: just parse the config, setVar() the value the way you want it, then parse whatever recipes you need after that Apr 12 15:47:56 but yes, that'd work too Apr 12 16:00:07 kergoth: OK, thanks for the tip. Apr 12 16:53:18 kergoth: if I wanted to do it your way, on which object do I call setVar? the Tinfoil itself? Apr 12 16:58:33 kergoth: nvm again, looks like tinfoil.config_data.setVar. Sorry for spam. Apr 12 17:01:34 yep, on the config metadata Apr 12 17:01:37 np Apr 12 17:11:51 kergoth: loving this API :) really powerful Apr 12 17:33:13 kergoth: actually, I think it's not possible to do what I want with BB_SRCREV_POLICY without resorting to a temporary file like I initially described. Tinfoil.prepare(config_only=True) ends up calling bb.fetch.fetcher_init, and since BB_SRCREV_POLICY isn't set yet it defaults to clear. So by the time I try to set BB_SRCREV_POLICY to cache, it's too late - the cache is gone. Apr 12 17:42:39 ah, that's interesting Apr 12 18:21:48 kergoth: would you be interested in a patch that added a new flag to bitbake (and transitively BitBakeConfigParameters and TinfoilConfigParameters), "--cache-srcrevs", which ensures BB_SRCREV_POLICY = "cache" is set from the get-go? Apr 12 18:42:58 hmm, possibly? I'd suggest emailing the bitbake-devel list iwth a RFC Apr 12 18:47:32 kergoth: OK, will think about it. Thanks Apr 12 18:49:54 obviously doesn't harm anything, just wondering how common the use case will be Apr 12 18:54:56 laplante: personally, I use it in a continuous integration environment where I am building images for multiple target machines. I want to ensure common components between the machines are built from the same upstream revisions (we use AUTOREV a lot), and so BB_SRCREV_POLICY is how I ensure that. In the future, when multiconfig because more mature, I'll use that instead. Apr 12 18:55:27 oops didn't mean to use my own nick Apr 12 19:00:32 ah, that makes sense. lock it down for the duration of the CI job. Apr 12 19:00:44 i could see it being accepted with that use case in mind specifically Apr 12 19:01:56 kergoth: sweet, now I just hope I can find time to work on the patch and RFC :) Apr 12 19:07:09 we use SRCREV_POLICY at metnor for product releases. mentor embedded linux installers include sources, set cache, and include a autorevs.conf emitted by buildhistory-collect-srcrevs to fix BB_NO_NETWORK operation for AUTOREV recipes Apr 12 19:18:56 kergoth: gotcha - that's very similar to what we're doing. Up until today actually, we were essentially using a homemade autorevs.conf generator (which I wrote at a time I didn't understand buildhistory). It became too ugly and broken, so I am in the process right now of moving us over to buildhistory-collect-srcrevs. Apr 12 19:19:34 we tried to tell the devs to just stop using AUTOREVS, but yeah.. not going to happen :) Apr 12 19:20:50 Unfortunately (or fortunately, which is IMO my stance) we use AUTOREV everywhere for our internal recipes. devtool is basically our entire development workflow. I also parameterize every SRC_URI with a "BRANCH" variable, to make it easy to not only override SRCREV but also the branch from local.conf or whatever. Apr 12 19:21:30 I have tweaks to devtool I'd like to upstream that respect the BRANCH automatically (instead of having to pass -b every time) Apr 12 19:22:07 Additonally I'm working on extending buildhistory-collect-srcrevs (via the external Python script I'm working as we type) that exports the BRANCH variable alongside SRCREVs. Apr 12 19:39:12 sounds useful given how picky the fetcher is about srcrev being in a specified branch Apr 12 19:40:27 glad you think so; I look forward to upstreaming it :) **** ENDING LOGGING AT Sat Apr 13 02:59:57 2019