**** BEGIN LOGGING AT Sun Jan 26 02:59:58 2020 Jan 26 13:53:31 Hey, can someone help me with understanding if devtool is the tool for the job... Jan 26 13:54:33 So far I understood that devtool is cool if one wants to update a version of a recipe, or create a new recipe without having to write a lot a boilerplate code... Jan 26 13:55:18 But am trying to understand if it was designed to help with creating .bbappend files for existing recipes Jan 26 13:55:52 For example, I want to modify this particular task: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/os-release/os-release.bb#n32 Jan 26 13:57:14 I start with `devtool modify os-release`, it creates the `workspace` layer and throws an error that there are no sources available for that recipe. Jan 26 13:58:19 ls Jan 26 13:59:30 (ups :p ) The workspace dir is empty. What is the expected flow form here? Jan 26 14:07:03 I can see the original .bb file with `devtool edit-recipe os-release`. Can even make changes that are persistent (can see the changes I made every next run of `devtool modify os-release`)... Jan 26 14:07:43 But if I do `devtool build os-release` an error occurs: `ERROR: No recipe named 'os-release' in your workspace` Jan 26 14:10:15 MeanEngi: as fasr as i understood, you're supposed to use 'devtool modify' only once and then commit your changes to the newly created git repo within the workspace Jan 26 14:10:59 once you're done you can create a set of patches using 'devtool update-recipe' Jan 26 14:13:02 i am not sure about the build thing in your case. from the first view, the command itself looks generally ok. Jan 26 14:14:07 MeanEngi: i gave you're task a try at my local workspace. first thing i noticed was that running 'devtool modify os-release' gave me an error: 'ERROR: The os-release recipe has do_unpack disabled, unable to extract source' Jan 26 14:14:17 did you get the same error in the first place? Jan 26 14:14:29 so there might be something specific to that recipe Jan 26 14:14:47 creich: Thanks for the response. Yes, I got that error also. Jan 26 14:14:57 try to use your own layer and manually create an .bbappend file with your changes Jan 26 14:15:30 The `os-release` doesn't have a source like "regular" recipes. It just creates a file with the versions. Jan 26 14:15:57 > try to use your own layer and manually create an .bbappend file with your changes Jan 26 14:16:05 Without devtool? Jan 26 14:16:13 yep Jan 26 14:16:19 you can use bitbake-layers Jan 26 14:16:23 to create a new layer Jan 26 14:16:28 if you don't have one already Jan 26 14:17:05 I know about that approach, thanks. But am trying to see if I'm missing something with `devtool`. Jan 26 14:17:06 bitbake-layers create-layer -p Jan 26 14:17:37 i am not sure, but it looks like the problem is related to that specific kind of recipe without sources Jan 26 14:17:51 generally your approach looks right i'd say Jan 26 14:18:17 but i am not an expert ^^ Jan 26 14:19:21 Thanks. I guess I was hoping `devtool` wouldn't care about the sources and would provide an environment where I can easily see the results of the changes I'm making Jan 26 14:20:10 (I know it's possible to do it manually with `bitbake` and examining the directory for that recipe in the `work` dir) Jan 26 14:21:00 MeanEngi: found that in the devtool --help --> modify Modify the source for an existing recipe Jan 26 14:21:27 so i tlitterally states that it modifies the SOURCE of a recipe ^^ Jan 26 14:22:08 again, i think your approach is right in general. just not suiting that specific kind of recipe Jan 26 14:22:28 True :) But there is also the `edit-recipe Edit a recipe file` Jan 26 14:23:11 Working on a recipe in the workspace: Jan 26 14:23:21 And `edit-recipe` also works well, it loads the correct sources Jan 26 14:23:35 "sources" - the bb files Jan 26 14:23:51 hmm, ok. did you try it on your os-release recipe? Jan 26 14:24:06 And it even saves the changes somewhere, but it doesn't seem to be in the workspace layer Jan 26 14:24:12 i thought maybe the only thing working for you might be 'devtool create-workspace' Jan 26 14:24:25 hmm, that's weired Jan 26 14:24:30 Just checked git status Jan 26 14:24:38 i can give it a try Jan 26 14:24:47 It's modifying the recipe directly in `meta/recipes-core/os-release/os-release.bb` Jan 26 14:24:51 so you did 'devtool edit-recipe os-release' Jan 26 14:24:52 ? Jan 26 14:24:56 Yup Jan 26 14:25:02 i see Jan 26 14:25:24 maybe try creating a new empty workspace and then edit Jan 26 14:30:45 i tried some of the devtool options and don't find anything suitable to your needs (as fasr as i understood them) Jan 26 14:31:14 Tried, doesn't seem to be it's flow. Thanks for the attempt :) Jan 26 14:31:15 so looks like the cleanest way still is creating a new layer (or temp workspace if you like) and manually create a bbappend there Jan 26 14:31:26 you're welcome :) Jan 26 14:31:54 agrees, doesn't seem to be the flow ^^ Jan 26 14:33:21 s/agrees/agreed/ Jan 26 14:52:07 Hello my friends. Yesterday I got a problem. I can solve half of my problem but only one thing left. I use systemd_%.bbappend for call can0.service. Not start automatically can0 afterboot first time. If I command `$systemctl --now enable can0` after every boot start auto. But I dont want write this command once. So if I call `��● can0.service Jan 26 14:52:07 - can0 interface setup Loaded: loaded (/lib/systemd/system/can0.service; disabled; vendor preset: enabled) Active: inactive (dead)` Is any idea? Jan 26 14:53:16 above log came if I command '$systemctl status can0' Jan 26 15:07:19 beratiks: have you tried this already?: https://stackoverflow.com/questions/32902003/enable-systemd-service-in-yocto-build Jan 26 15:07:35 expecially the last comment in the answer Jan 26 15:12:02 creich: I didn't try. I am looking and I will try add. Thanks. After try I will back. Jan 26 19:18:38 RP: the patches in master-next are a bit stale Jan 26 19:18:55 RP: the latest is in kraj/pu on poky-contrib Jan 26 19:28:21 RP: I have now sent it all in a consolidated pull request as well Jan 26 22:23:08 khem: which ones? :/ Jan 26 22:26:40 khem: basically means I now throw away the testing and start again as I have no idea what has changed :( Jan 26 22:30:07 khem: not sure they are that out of date according to diff... Jan 27 02:29:39 RP: glibc patches are still same, but ruby patch and libucontext patch are updated Jan 27 02:29:52 but I can rebase on top of what you merge Jan 27 02:29:54 so no worrries Jan 27 02:29:59 I can send another round **** ENDING LOGGING AT Mon Jan 27 02:59:58 2020