**** BEGIN LOGGING AT Wed Apr 07 02:59:57 2021 Apr 07 06:34:47 hi, with master branch gitsm fetcher changes considerably but it does not seem to invalidate download cached things. How to invalidate all cached downloads for gitsm fetcher? An extra command "git submodule update --init -recursive" needs to be executed on old cached trees before they can be compiled, but new fetcher code doesn't do that as it expects things to be in cache but they aren't Apr 07 06:52:27 Any help will be appreciated, I am getting this error and I am scratching my head how to debug this problem -  Yocto - tools-profile' in IMAGE_FEATURES (added via EXTRA_IMAGE_FEATURES) is not a valid image feature. In the local.conf, I have added the following. Apr 07 06:52:27 EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile" Apr 07 06:52:39 https://stackoverflow.com/questions/66961280/yocto-tools-profile-in-image-features-added-via-extra-image-features-is-not Apr 07 06:53:25     packagegroup-core-tools-profile.bb Apr 07 06:53:26     meta/recipes-core/packagegroups Apr 07 06:53:30 this looks fine to me. Apr 07 06:56:33 mcfrisk: that sounds a lot like a corner case we've not looked at :/ Apr 07 07:08:21 how to debug this? Apr 07 07:09:14 yo dudX Apr 07 07:12:54 I am talking about this issue - https://stackoverflow.com/questions/66961280/yocto-tools-profile-in-image-features-added-via-extra-i... Apr 07 07:16:43 https://stackoverflow.com/questions/66961280/yocto-tools-profile-in-image-features-added-via-extra-image-features-is-not Apr 07 07:24:40 RP: hmm I'll try to reproduce with plain poky master, maybe something on my side is wrong.. Apr 07 07:32:57 mcfrisk: it could just be older checkouts with the newer code :/ Apr 07 07:38:44 can you elaborate on it like old checkouts with the newer code? Apr 07 07:39:49 Is there any tool  to debug why it cannot find the tools-profile? Where to search for and where it should be for yocto to find? Apr 07 07:42:31 SJ17: i have just kicked off an example build here with tools-profile (qemuarm64, current master) and it happily runs. so chances are that something in your layer stack/machine config disables this image feature. inspect bitbake -e for hints. Apr 07 07:52:18 RP: I'm also porting gitsm and fetcher2 changes from master to sumo to get gitsm working in off line mode, testing both master and sumo currently. I'll check if find a way to be compatible with old download cached things.. Apr 07 08:39:41 RP: good news, I was not able to reproduce problems with gitsm fetcher and old cached files with plain poky, and with some additional backports seem to have fixed gitsm fetcher in sumo too Apr 07 09:58:57 "mornin'" folks :) Apr 07 10:11:11 i really dislike finding bugs in pseudo Apr 07 10:12:01 rburton: who likes finding bugs :D ? Apr 07 10:24:26 Hi. I am working on compute module 4 raspberry pi to get the usb port working. Unable to do it. I am using dunfell. I can see that the overlay necessay for usb has been added in the config.txt after making changes in the local.conf file. but, still unable to get it working. any ideas how to get it working? Apr 07 10:54:42 prajvalsh: what did you set in local.conf to enable it? Apr 07 10:59:20 rburton: "finding" as in "proving they exist" or "finding" as in "spotting the reason, therefore now being responsible to provide a fix"? Apr 07 11:00:28 former Apr 07 11:05:22 what's the right way to add sysctl configuration ? like vm.panic_on_oom=1 - do you override a built in recipe or just add your own file? is there some built in means to do it? :) Apr 07 11:06:23 I see that procps recipe has one Apr 07 11:07:02 mckoan:I have used ENABLE_DWC2_HOST=1 in local.conf. Apr 07 11:18:37 rburton: well i like it better than my customers doing it. Apr 07 11:18:48 * LetoThe2nd is more and more wearing the testing hat around here. Apr 07 11:20:41 prajvalsh: 1 or "1"? Apr 07 11:22:17 LetoThe2nd:"1" Apr 07 11:46:12 I was thinking of just adding an own one in my recipe - https://stackoverflow.com/a/57072810 like that. but is it more correct to override the procps recipe? Apr 07 11:46:44 or some sysctl-related recipe. the disadvantage is that it will probably rebuild the whole thing for a change Apr 07 11:53:46 or is this more accurate? https://stackoverflow.com/a/60758066 I want to add to the sysctl.conf, not override procps' one really Apr 07 11:54:15 prajvalsh: ENABLE_DWC2_HOST = "1" should work Apr 07 11:59:34 mckoan:no it is not working. the config.txt has the overlay that is necessary for the usb port, but it is still not working Apr 07 12:31:33 Hi, I'm having a problem with applying patche: Apr 07 12:31:38 *patches Apr 07 12:32:37 I'm trying to build virtual/kernel, it works if I run the build command multiple times Apr 07 12:33:17 But it aborts on the first build command with the error message: Apr 07 12:33:47 "error: corrupt patch at line 5" Apr 07 12:33:57 the weird thing is that the patches work Apr 07 12:34:29 but "do_patch" only applies one patch at a time Apr 07 12:35:09 I believe this has something to do with the internal scheduling Apr 07 12:36:29 I.e. I have 3 patches for "virtual/kernel" the first one is applied on the first run, the second one is applied on the second run, and the third run succeds with the 3rd patch Apr 07 12:37:39 guest231: patches are applied in the order they appear in SRC_URI Apr 07 12:38:27 in one go obviously. The weird behavior you're describing smells very much like some vendor craziness. Apr 07 12:39:22 guest231: could you tell us more about your layers and the yocto version you're using? Apr 07 12:40:18 I use yocto zeus Apr 07 12:40:25 guest231: also, are you using scc files by any chance? I think it should still be sequential and deterministic order Apr 07 12:40:44 but I'm not really using those mechanisms so can't help for those Apr 07 12:41:02 I'm not aware of any scc files, BB_VERSION is 1.44.0 Apr 07 12:41:49 Also we use a custom BSP for our bespoke hardware Apr 07 12:42:19 Basically, I'd like to fix the vendor craziness Apr 07 12:43:36 is there a way to reference recipe-sysroot inside a CMakeLists.txt? Apr 07 12:45:23 luneff: if you don't override CC, CXX, CFLAGS, LDFLAGS, you should have nothing to do IIRC Apr 07 12:46:17 I know. But I need to add "recipe-sysroot/usr/include/mylib" to includes. I do :-) Apr 07 12:47:56 qschulz here is the recipe for "virtual/kernel": https://0bin.net/paste/7IUnDcg7#ahECohPthTiq7i3tGTPGAc0o7kFrG2RBk++x7y+3nEk Apr 07 12:49:22 it should probably be added in the recipes and not Cmake? In which case, EXTRA_OECMAKE in recipe with -I${STAGING_INCDIR}/mylib ? Apr 07 12:58:48 guest231: the FILESEXTRAPATHS_prepend make no sense in a recipe (bbappend yes, recipe, no), otherwise the rest looks ok Apr 07 13:02:43 qschulz What is the recommended way to organise patches? Should I put the folder name in SRC_URI? Apr 07 13:05:08 guest231: ${PN} is already in FILESPATH, patches dir could be put into a dir already matched by FILESPATH (${PN}/ ${BPN}/ files) and then SRC_URI += "file://patches/name1.patch" if you really want the patches in a subdir Apr 07 13:06:40 guest231: BP and not BPN sorry. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-FILESPATH Apr 07 13:06:58 BP and not PN* Apr 07 13:06:58 qschulz, plain "-I" gets cmake angry. overriding CXX_FLAGS would probably be an error too... Apr 07 13:08:48 luneff: CMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), d.getVar('prefix') + '/')} so does not feel like it's supposed to be supported? Apr 07 13:09:05 luneff: what';s wrong with adding in your sources? Apr 07 13:09:25 (so that you don't need to change the include path of CMake but only of cpp/c files Apr 07 13:09:32 only inside* Apr 07 13:11:03 sources are autogenerated by google protobuf Apr 07 13:13:51 found a solution, STAGING_INCDIR is ok, wondering how to get the same path without usr/include part. probably ${STAGING_DIR} Apr 07 13:15:48 no :-( Apr 07 13:17:30 Is there some subtlety i'm missing here? why would one use: Apr 07 13:17:38 SRC_URI_append += "..." (looks redundant) Apr 07 13:17:50 SRC_URI_append = "..." (why not just SRC_URI +=?) Apr 07 13:18:12 ${STAGING_INCDIR}/../../ works :-D Apr 07 13:39:53 yeah, fixed all. thanks qschulz ! :-) Apr 07 13:53:06 This is the minimal working example which fails: https://0bin.net/paste/aks03hYu#vA20PBlkjJAOZmHu-T53vy/z/UVDOatF0iCIH4zpKAj I have to build "virtual/kernel" twice Apr 07 13:54:32 RP: I have some patches in master-next for meta-mingw for testing on the AB, when you have some time. They are for master, not hardknott Apr 07 13:57:23 errors: https://0bin.net/paste/c-Xjur+G#n0qigRlR2lvC4MI1TIcVJkDoQnyXx+Hvf7Dcu5e22tr Apr 07 14:11:35 luneff: RECIPE_SYSROOT is actually what you're after Apr 07 14:14:01 yes, thank you! :-) Apr 07 14:14:28 luneff: still, feels very wrong :) Apr 07 14:17:59 I know :-D Apr 07 14:24:46 ok: It can't be a problem with the ordering because it fails with a single patch file as well Apr 07 14:42:36 If I have recipe A and recipe B, is it in recipe B possible to say that it should always rebuild if recipe A was rebuilt?.. I guess B depends on A in recipe B makes sure A is up to date if B needs building, but any way to ensure that B gets updated if A gets updated? Apr 07 14:44:09 currently there's a 'do_image[nostamp] = "1"' in recipe B, which I suspect makes it rebuild loads of stuff it doesn't need to Apr 07 14:48:00 DEPENDS = "A" in recipe B does that Apr 07 14:48:12 chrfle: ^ Apr 07 14:48:43 chrfle: what exactly are the recipe A and B you're talking about and what is the exact dependencyy between both? Apr 07 14:50:09 (are we talking two image recipes, two package recipes or one package recipe and one image recipe, etc...) Apr 07 14:51:29 qschulz: recipe A generates a filesystem, recipe B creates dm-verity data for said fs along with an initramfs to mount the fs..... If A changes, I want to re-do B, but if something changes in i.e. the initramfs, I don't want to rebuild A, only B Apr 07 14:53:02 I believe both are image recipes Apr 07 14:55:16 chrfle: the dm-verity data creation is done in its own task isn't it? Apr 07 14:55:56 I believe so yes.. I must admit that I'm a real novice when it comes to yocto... Just hate that it seems to rebuild things that it should not need to Apr 07 14:56:51 chrfle: try to find how the dependency in B recipe to A is set Apr 07 14:57:33 because basically, my understanding is that the dependency is in B on A, not the opposite Apr 07 14:57:34 qschulz: I think this is it: do_image[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}" Apr 07 14:57:52 chrfle: that does make sense yes Apr 07 14:58:24 if it's in B recipe??? Apr 07 14:58:40 not sure, since I would assume DM_VEIRYT_IMAGE is B recipe, so this line is probably in A recipe? Apr 07 15:02:52 with wic, when using part --align 512 --offset 512, will the partition start at 1024? Apr 07 15:03:04 (assuming it's the first one in this example) Apr 07 15:04:05 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/3285 Apr 07 15:06:27 qschulz: This is the file in question: https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-core/images/dm-verity-image-initramfs.bb?h=dunfell#n25 Apr 07 15:07:09 qschulz: it's the nostamp on L25 I'm questioning Apr 07 15:07:50 qschulz: here seems to be the patch it's added in https://lists.yoctoproject.org/g/yocto/message/50461 Apr 07 15:08:48 qschulz: and it seems to me that the entire rootfs is re-generated and the different images are created, then verity data is added.. And I believe it should be enough to re-add the verity data Apr 07 15:11:18 chrfle: the verity data is done in a preprocess command of the image creation so it makes sense from that side at least Apr 07 15:11:23 if it's coprrect, different topic Apr 07 15:12:28 but since you want the verity data within your initramfs, it needs to be added before the image is finalized Apr 07 15:12:41 also that isn't possible to create a partition < 1M with wic, correct? Apr 07 15:13:47 qschulz: this recipe generates the initramfs I believe. So it makes sense to put in the verity information before generating the image.. but building this recipe (as it's nostamp) will that cause the recipes listead in do_image[depends] to be rebuilt as well? Apr 07 15:14:03 qschulz: perhaps my problem with rootfs being rebuilt is somewhere else Apr 07 15:14:24 qschulz: unfortunately need to collect my daughter from kindergarten now. I'll read up later Apr 07 15:23:36 We noticed yesterday that ping doesn't work for a regular user. Unlike a lot of distributions it's not set +s root. (For good reason) However, does the Yocto Project support doing any sort of setcap on the files when creating filesystems? (I've never tried doing any sort of setcap under pseudo) Apr 07 15:39:52 chrfle: do_image[depends] += "recipeX:do_task" means the do_image task of the recipe in which it is defined depends on the do_task of recipeX. Meaning, if do_task of recipeX is re-run, so will do_image. Apr 07 15:58:39 how can I create a partition smaller than 1M with wic? Apr 07 16:08:15 the layerseries thing is borked? Apr 07 16:10:52 ERROR: Layer is not compatible with the core layer which only supports these series: (layer is compatible with hardknott) Apr 07 16:21:58 tlwoerner: does your layer have hardknott in its list? Apr 07 16:22:26 smurray: yes, they all do Apr 07 16:23:41 pulling latest master of openembedded-core causes this to show up Apr 07 16:23:58 tlwoerner: that does seem odd. I don't see any changes wrt that in oe-core recently, though Apr 07 16:24:08 try updating oe-core and building on master Apr 07 16:26:10 smurray: this is the opposite case if his layer doesn't have hardknott in LAYERSERIES_COMPAT then it would say "(layer is compatible with gatesgarth)", what is missing here is "hardknott" after ';' I do see it with current oe-core/master: Apr 07 16:26:12 Hi #yocto! Apr 07 16:26:12 I am trying to figure out which task is taking so long in the build process. Is it possible to add timestamps to the logfiles? Or are there other ways to find out? Apr 07 16:26:18 ERROR: Layer meta-python2 is not compatible with the core layer which only supports these series: hardknott (layer is compatible with dunfell) Apr 07 16:26:58 tlwoerner: does your checkout have? meta/conf/layer.conf:LAYERSERIES_CORENAMES = "hardknott" Apr 07 16:27:27 and isn't your bblayers.conf somehow messed to be missing oe-core? :) Apr 07 16:27:45 devtool sometimes does that Apr 07 16:27:51 when adding workspace layer Apr 07 16:29:31 tlwoerner: yes removing oe-core layer from BBLAYERS produces the same error message as what you have: Apr 07 16:29:34 ERROR: Layer clang-layer is not compatible with the core layer which only supports these series: (layer is compatible with gatesgarth hardknott) Apr 07 16:33:12 JaMa: ah yes, my bblayers was missing oe-core !? thanks Apr 07 16:33:24 weird Apr 07 16:34:42 silviof: look at buildstats.bbclass Apr 07 16:35:49 Ah thanks, JaMa ! Apr 07 16:36:43 JaMa: huh, that's a weird error, should submit a bug for a better error when there's no LAYERSERIES_CORENAMES defined Apr 07 16:37:37 tlwoerner: ^ Apr 07 16:41:41 JaMa: This was EXACTLY what I have searched. And it was already enabled ^^ Thanks! Apr 07 16:41:58 JaMa: okay, on it Apr 07 16:48:47 Hi, I know I'm supposed to add my systemd .service files to SYSTEMD_SERVICE, but what about .target and .mount units? Apr 07 16:49:51 Does anyone have any experience with saltstack on yocto? Apr 07 16:50:22 The recipe is there for that, but it does not seem to work Apr 07 16:54:57 kergoth: JaMa: bug submitted → https://bugzilla.yoctoproject.org/show_bug.cgi?id=14340 Apr 07 17:10:44 Can I convince anyone to send a patch as well? please? :) Apr 07 19:22:27 qschulz: I see, it seems reasonable then.. what about the do_image[nostamp] = "1", does that mean when do task of recipeX is being re-run, the one with depends will always be re-run, even if it seems like it could use a cached one?... Or is it always re-run when a build in invoked? Apr 07 20:41:58 chrfle: that means the task in question will always rerun Apr 07 21:08:53 RP: no matter if any dependecy changed or not? Apr 07 21:19:09 registration is now open for the Yocto Project Summit: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501 Apr 07 21:19:58 don't forget to submit your CfPs (CfP closes April 25) Apr 07 21:24:59 chrfle: if it is set as nostamp it will rerun regardless Apr 07 22:36:10 RP: ok, thanks! Apr 08 00:47:10 Hi guys, is it possible to ask Questions here! i come from Yocto live code **** ENDING LOGGING AT Thu Apr 08 02:59:57 2021