**** BEGIN LOGGING AT Thu Feb 11 02:59:57 2021 Feb 11 06:40:13 Hi, I have downloaded meta-java layer and added to the bblayers.conf then added jamvm into local.conf file, but I get this error as ERROR: Nothing RPROVIDES 'jamvm' (but /home/bl-docker/rity/src/poky/../meta-mediatek-bsp/recipes-core/images/mtk-image.bb RDEPENDS on or otherwise requires it) Feb 11 06:40:13 jamvm was skipped: incompatible with machine i500-pumpkin (not in COMPATIBLE_MACHINE) Feb 11 06:41:13 Does my board really doesn't support or did I miss anything? Feb 11 06:52:50 Hi, I have a .bbappend recipe, where I define "SRC_URI_foo += "file://foo.patch" and "FILESEXTRAPATHS_prepend := "${THISDIR}/files" is this correct? Feb 11 06:54:08 I add to overrides "foo" in the local.conf Feb 11 06:54:49 But Yocto can't find the patch! Feb 11 06:55:20 If I remove _foo and write just "SRC_URI += "file://foo.patch"" everything works Feb 11 07:05:59 SRC_URI_foo += is most likely wrong, it will override the default SRC_URI from the recipe while usually you want to append to it when foo override is active which would be SRC_URI_append_foo = " file:...." Feb 11 07:15:12 It works with _append, but I do want to override the default SRC_URI Feb 11 07:16:34 then use bitbake -e to see what happend Feb 11 07:19:49 Hi, I have downloaded meta-java layer and added to the bblayers.conf then added jamvm into local.conf file, but I get this error as ERROR: Nothing RPROVIDES 'jamvm' (but /home/bl-docker/rity/src/poky/../meta-mediatek-bsp/recipes-core/images/mtk-image.bb RDEPENDS on or otherwise requires it) jamvm was skipped: incompatible with machine i500-pumpkin Feb 11 07:19:49 (not in COMPATIBLE_MACHINE) Does my board really doesn't support or did I miss anything? Feb 11 07:21:43 hi Feb 11 07:22:05 JaMa I don't understand the behaviour of "base_set_filepath" Feb 11 07:29:18 https://0bin.net/paste/9KVQpZ85#t7qdDV5hZ0kUzraZI5muf3fgfJSzx2CjskNqpWdUXp9 Feb 11 07:40:12 The combination of "SRC_URI += """ with "SRC_URI_append_foo = "file://foo.patch"" works, but this seems to be unintended Feb 11 07:48:55 guest231: see the FILESPATH variable it constructs and you will notice that your FILESEXTRAPATHS_prepend is missing trailing ':' and your SRC_URI_append_foo is missing leading space Feb 11 07:50:51 Ah, the missing leading space was the issue, thank you! It also explains why it works with "SRC_URI += """ Feb 11 08:22:46 where can I get the list of the software-license pairs installed into the image? Feb 11 08:29:25 dvorkindmitry: poky/build/tmp/deploy/licenses/ ? Feb 11 08:29:59 yocton, oh, thanks Feb 11 08:30:34 you're welcome :) Feb 11 09:50:03 I am new to yocto. Is there any online bitbake kind of platform, where I can learn yocto hands on, without installing anything in my computer. ? Feb 11 09:53:04 JosephAntony: AFAIK no Feb 11 09:53:48 okay Feb 11 10:08:41 there is a web interface, only used it once though. You still need to install everything, it's just instead of editing files by hand https://www.yoctoproject.org/software-item/toaster/ Feb 11 10:30:05 yo dudX Feb 11 10:30:47 hello everyone Feb 11 10:31:04 o/ Feb 11 10:31:16 malinus: I wouldn't suggest use of Toaster though https://wiki.koansoftware.com/index.php/Toaster_setup_and_usage Feb 11 10:31:40 hello LetoThe2nd, everybody Feb 11 10:35:18 mckoan: why? Might be less intermidating than editing files manually Feb 11 10:37:28 malinus: it depends on the overall usecase, but de facto toaster hasn't really done a good job as dev frontend so far. and espeically not when you're targetting a form of reproductibility or CI/CD Feb 11 10:43:16 LetoThe2nd: I see. I'm not a user o toaster, I just tried it and thought it was pretty neat Feb 11 10:44:05 malinus: yeah. its primary use in real life is actually build inspection, as far as I can tell. Feb 11 10:45:02 LetoThe2nd: I also found it neat how easy it was to browse around and add stuff to a toy-build Feb 11 10:46:18 malinus: the real problem with any form of frontend to YP/OE tech is that its impossible to really grasp all the possibilities and options that the text configuration offers. so you would always have to leave a lot out, which makes the frontend basically unusable because there will always be the next guy who needs the thing you decided to leave out for simplicity. Feb 11 10:47:18 malinus: yes it does that nicely. but once you get out of the toy build phase you quickly need to learn how to do things right. and once you know that, you're not going back to toying. this is basically why toaster is not being used as a build frontend. Feb 11 10:47:57 LetoThe2nd: you could use that argument on every GUI ront end ever created, whatever it's GIT or GDB, there will always be something missing Feb 11 10:48:21 malinus: hummm not exactly. Feb 11 10:48:34 malinus: it depends very much on the use case of the options. Feb 11 10:49:23 malinus: if you have a system that is very very complex, but is usually operated through only a very limited subset of options, then a gui or frontend is highly effective. best example: google. Feb 11 10:50:21 malinus: however if you have a complex system where finetuning a lot of options is actually the standard case, then a frontend becomes really complicated. Feb 11 10:52:20 malinus: imagine a 1000pcs puzzle. limiting yourself to only 10 of them is somewhat counterproductive. to get the correct result, you need access to all pieces. and thats a lot like building a linux system, actually. you need to get all pieces right and working together. Feb 11 10:52:40 LetoThe2nd: sure I agree completly. I personally find myself switching between GUI frontends and working directly with the tools. Obviously the GUI wrapper needs to add some value, for that to be worth it. Feb 11 10:53:07 malinus: exactly. there are good usecases for both situations. Feb 11 10:53:21 But I can see how most yocto builds could probably only have a few % done in toaster Feb 11 10:54:54 malinus: i can assure you, the feeling is wrong. for anything that is not a toy build targetting a super popular board, you need to configure so many bits and pieces that toaster falls flat. plus, how do you automated and reproduce the build on your infrastructre, then? Feb 11 10:55:56 LetoThe2nd: yeah exactly Feb 11 11:00:33 @LethoThe2nd: Oida! There are no "good" use cases for GUI apps ;) Feb 11 11:01:01 RobertBerger: disagreed. OIDA! Feb 11 11:14:36 I'm upgrading Yocto from Sumo to Dunfell, and I'm about to start working on our kernel patches. When I run 'devtool modify linux' it complains about a non-existing defconfig, but if I build the kernel using 'bitbake linux' it works just fine. Feb 11 11:14:57 any ideas why devtool cannot find the defconfig, while bitbake can? Feb 11 11:18:57 @LetoThe2nd: Troll ;) Feb 11 11:19:34 iceaway: don't use devtool for kernel hacking Feb 11 11:20:31 iceaway: and find the defconfig in the WORKDIR : bitbake -e virtual/kernel | grep ^WORKDIR= Feb 11 11:20:42 RobertBerger: soiba. Feb 11 11:24:23 qschulz: would you recommend using the "traditional" approach as described in the kernel dev manual? Feb 11 11:27:54 iceaway: yup Feb 11 11:28:48 qschulz: cool, never tried that, will give it a go. Thanks! Feb 11 11:34:53 iceaway: the issue being that devtool does not handle work-shared recipes well (gcc and kernel recipes are two of those using said mechanism) Feb 11 11:35:26 RP: ndec: wondering if we should remove the recommendation of using devtool for kernel dev with Yocto in the kernel dev manual? Feb 11 11:37:25 qschulz: why? Feb 11 11:37:54 because... it does not work? Feb 11 11:38:16 qschulz: it is supposed to and has code at least for the kernel case Feb 11 11:38:18 qschulz: LOL Feb 11 11:39:13 RP: might have to test again on newer versions of Yocto then but on thud, out-of-tree kernel modules can't build with a devtool'ed kernel IIRC Feb 11 11:39:41 which technically isn't really the kernel recipe, that I can admit :) Feb 11 11:39:51 qschulz: perhaps we need to document the known problems. Is there an open bug for that? Feb 11 11:40:06 qschulz: RP: on newer versions it works https://wiki.koansoftware.com/index.php/Using_devtool_to_modify_recipes_in_Yocto Feb 11 11:40:11 RP: I'm guilty of never opening bugs and not reading the Bugzilla :( Feb 11 11:41:04 mckoan: very specific use case Feb 11 11:41:11 you're not actually rebuilding the image as a whole Feb 11 11:41:19 just the recipe itself Feb 11 11:41:40 which means anything using the work-shared won't have the issue since you'll rebuild the image only when devtool update-recipe has been run Feb 11 11:41:42 IIUC Feb 11 11:47:02 ERROR:ParseError at /home/mckoala/poky/meta-openembedded/meta-networking/recipes-support/openipmi/openipmi_2.0.31.bb:41: Could not inherit file classes/python3targetconfig.bbclass Feb 11 11:47:23 Googling got me 1 search result which didn't help either Feb 11 11:49:09 wait it works now... I commented out something in sanity.conf (because of an another earlier error that I got) Feb 11 11:49:18 so I uncommented that and tried again Feb 11 11:49:47 someone on internet wrote to remove that error I had to comment that one out (which removed that error but introduced the above error) :') Feb 11 11:50:24 I have download meta-java layer and added to the conf/bblayer.conf file, then added jamvm to conf/local.conf file and ran bitbake command, but I got this error as "Nothing RPROVIDES 'jamvm' (but /home/bl-docker/rity/src/poky/../meta-mediatek-bsp/recipes-core/images/mtk-image.bb RDEPENDS on or otherwise requires it) jamvm was skipped: incompatible Feb 11 11:50:24 with machine i500-pumpkin (not in COMPATIBLE_MACHINE)" Feb 11 11:50:24 Recipe file path is under /src/meta-java/recipes-core/jamvm/jamvm_git.bb. Did I miss anything or does my target board has any compatibility issue? Feb 11 11:51:55 mckoala has joined Feb 11 11:53:28 it started but I get a similar error... Feb 11 11:53:28 ERROR: ParseError at /home/mckoala/poky/meta-openembedded/meta-oe/recipes-dbs/postgresql/postgresql.inc:39: Could not inherit file classes/python3targetconfig.bbclass Feb 11 11:56:02 mckoala: make sure your layers are using the exact same branch Feb 11 11:56:21 COMPATIBLE_MACHINE_aarch64 = "-" what does '-' mean? Feb 11 11:59:25 qschulz I checked out poky on tag 3.2.1, then I cloned meta-openembedded (which is on the master branch) Feb 11 12:00:30 git tag on meta-openembedded doesn't return anything Feb 11 12:07:42 mckoan: 3.2 is gatesgarth? or dunfell? checkout that branch on meta-openembedded. Feb 11 12:07:53 meh mckoala Feb 11 12:22:57 qschulz + LetoThe2nd, thanks it worked! Feb 11 12:34:46 \o/ Feb 11 13:02:47 Hello everyone, i am new to the channel. Can anyone describe me his workflow? I mean, how do you have a stable version of recipes, a stable build-folder, a development one etc...? Feb 11 13:03:10 If this question does make sense to you Feb 11 13:07:30 qschulz: any particular reason you don't want to file a bug? Feb 11 13:07:39 flash27: are you talking about the system build, or your application? Feb 11 13:08:12 system build Feb 11 13:09:09 LetoThe2nd system build Feb 11 13:10:33 flash27: then i admit i don't really understand the question. i mean, if you have to maintain a stable branch and development one, then you will probably need two seperate builds. they can and probably should share downloads and sstate, though. Feb 11 13:34:37 RP: laziness, my nemesis Feb 11 13:58:49 hello,  facing a strange problem: Error: Unable to find a match: glm,  now the bblayer contains /poky/meta-openembedded/meta-oe and the layer.conf at /poky/meta-openembedded/meta-oe/conf contains the usual that will look into subdirectories for bb files etc .. so everything seems to be in place and yet I get this error ... Feb 11 14:00:27 intera91: have you added /poky/meta-openembedded/meta-oe to your bblayers.conf? Feb 11 14:00:55 (meta-openembedded is a git repo with multiple layers in it, so you need to add them one by one, at least the ones you want) Feb 11 14:01:08 qschulz: yes here is the line Feb 11 14:01:45 poky/meta-openembedded/meta-oe \ Feb 11 14:01:52 so it's there Feb 11 14:02:10 i mean it has a complete path obviously Feb 11 14:02:19 intera91: is your error really "Error: Unable to find a match: glm"? Feb 11 14:02:25 yes Feb 11 14:02:36 verbatim, copied and pasted here Feb 11 14:02:56 intera91: ... what exactly are you doing? where did you add glm? to which variable? Feb 11 14:03:28 it's usually "Nothing PROVIDES" or "Nothing RPROVIDES" and then the name of the package, I've enever seen the error you mention before :/ Feb 11 14:03:29 ok in local.conf to IMAGE_INSTALL_append Feb 11 14:03:53 and glm is one among many Feb 11 14:04:07 but the error only mentions glm Feb 11 14:04:45 this is as a response to bitbake core-image-sato Feb 11 14:05:38 but the error only mentions glm Feb 11 14:05:44 DNF version: 4.2.23 Feb 11 14:05:45 cachedir: /home/patrick/workspace/poky/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/var/cache/dnf Feb 11 14:05:45 Added oe-repo repo from /home/patrick/workspace/poky/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo Feb 11 14:05:46 User-Agent: falling back to 'libdnf': could not detect OS or basearch Feb 11 14:05:46 repo: using cache for: oe-repo Feb 11 14:05:47 oe-repo: using metadata from Thu 11 Feb 2021 01:46:06 PM UTC. Feb 11 14:05:47 Last metadata expiration check: 0:00:01 ago on Thu 11 Feb 2021 01:46:06 PM UTC. Feb 11 14:05:48 No match for argument: glm Feb 11 14:05:48 Error: Unable to find a match: glm Feb 11 14:10:18 I used to use toaster and the line : INHERIT+="toaster buildhistory" was added at the end of local.conf in the build /conf am using now, might have something to do with that so i commented the line and trying bitbake again Feb 11 14:10:37 * RP wonders why master-next is segfaulting tar but only on opensuse151 Feb 11 14:10:38 ok no luck same error Feb 11 14:12:34 intera91: start from scratch. Remove all layers, build dirs, tmp dirs, everything Feb 11 14:12:42 intera91: add the layers one by one Feb 11 14:12:47 then `bitbake glm` Feb 11 14:12:52 if it works Feb 11 14:13:06 add your custom stuff one by one and test `bitbake glm` Feb 11 14:13:20 well, actually before starting from scratch, try `bitbake glm` Feb 11 14:13:38 but since it's a dnf issue... I guess it'd only happen during the rootfs creation :/ Feb 11 14:13:49 it;s/it seems to be/ Feb 11 14:13:54 ok will try that do I rm -Rf  poky/build/tmp/ ??? Feb 11 14:15:08 intera91: or start in another directory if you want, where you have no git repo cloned Feb 11 14:15:15 triple check that all layers are at the same branch too Feb 11 14:15:27 all layers are the same branch Feb 11 14:15:36 I made ultra-sure of that Feb 11 14:15:43 RP: when does the segfault happens exactly? Feb 11 14:15:48 *happen Feb 11 14:24:04 qschulz: that was fast, deleted poke/build/tmp and tried bitbake glm which succeded Feb 11 14:26:03 however in deply-rpm there is only a -dev -dbg and -doc rpms I will assume this is normal as there was no error Feb 11 14:26:10 attempting the whole image now Feb 11 14:30:05 intera91: no, you should have a "normal" package too Feb 11 14:31:43 intera91: stop, I found the issue Feb 11 14:31:59 ok am listening as the error just came back Feb 11 14:32:21 kanavin_home: I just found a weird pigz binary along with a "uninative-rp" in /usr/local and its this binary which is faulting. Was installed June 2019. I have no memory of any of this, it if was me... Feb 11 14:32:56 RP: right, I was worried it might be the tar version update Feb 11 14:33:13 removing it seems to make the builds happier. Why it breaks suddenly now and what this is about, I don't know Feb 11 14:33:16 intera91: DESCRIPTION = "OpenGL Mathematics (GLM) is a header only C++ \ Feb 11 14:33:18 mathematics library for graphics software based on the OpenGL \ Feb 11 14:33:18 kanavin_home: so was I :/ Feb 11 14:33:20 Shading Language (GLSL) specifications." Feb 11 14:33:32 intera91: **header only**. So there'll only be a glm-dev package Feb 11 14:33:44 intera91: What exactly do you want glm for? Feb 11 14:33:52 ok will correct to glm-dev Feb 11 14:34:22 qschulz: Our software uses OpenGL, vulkan and the likes Feb 11 14:49:13 intera91: why do you need the headers in the system is what I meant Feb 11 14:49:42 those are usually only needed at compile time, so glm in DEPENDS would be enough and the correct way to do it Feb 11 15:14:11 JPEW: quick question, do you know the best way to do reproducibility tests against oe recipes, the selftest? I'd like more detail, but need to be able to kick it off locally against a recipe in a non-public layer Feb 11 15:14:30 looks like the selftest just shows changed packages, hmm Feb 11 15:15:43 kergoth: I usually modify the test to only do the packages I'm interested instead of the image recipes Feb 11 15:15:58 kergoth: from memory I think you can change the list of recipes the selftest tests so the idea would be to do that and use the same test (or subclass it to do that) Feb 11 15:16:01 yeah, did that. do you know how to gather file level information when comparing packages? Feb 11 15:16:33 hmm, i bet debian has that tooling Feb 11 15:16:42 * kergoth obviously hasn't done much reproducibility stuff yet Feb 11 15:16:43 kergoth: we have diffoscope integrated Feb 11 15:16:47 kergoth: You can enable diffoscope output Feb 11 15:16:50 ah Feb 11 15:17:09 i had to kill use of relative paths to call configure in gcc-rutnime & friends to fix debug-prefix-map, but now i need to make sure i didn't break reproduciibility :) Feb 11 15:17:39 kergoth: set the envvar OEQA_DEBUGGING_SAVED_OUTPUT and the test will dump the output there Feb 11 15:17:44 kergoth: the autobuilder enables diffoscope and dumps the output into a directory the webserver knows about Feb 11 15:17:46 thanks, appreciate it Feb 11 15:18:18 kergoth: result is https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/diff-html/ and friends Feb 11 15:18:46 wonder if we should use a variable for the recipe list for that test case Feb 11 15:18:49 cool, thanks again Feb 11 15:18:58 is this documented anywhere, out of curiosity? Feb 11 15:19:14 kergoth: Probably not :( Feb 11 15:19:18 k Feb 11 15:19:25 I got so far with the testing manual but that probably isn't in there Feb 11 15:20:26 guessing debian probably has a lot of material on actually fixing reproducibility issues, so could link to that once we show how to test and diffoscope the user's recipe Feb 11 16:03:35 RP, had to drop for another call. if you have any questions on the two bugs I opened, let me know Feb 11 16:33:13 armpit: they make sense, thanks Feb 11 16:33:26 armpit: I fixed your commit message and put in -next ;-) Feb 11 17:02:07 is there a way to enable all systemd features (PACKAGECONFIG) at once for testing? basically every systemd-*d components. Feb 11 17:52:12 vdl: there is nothing like PACKAGECONFIG = "all" sort of thing, so you have to manually add all opts to PACKAGECONFIG Feb 11 19:27:13 fontconfig, xorg etc put MIT-style into LICENSE, but there is not MIT-style license in poky/meta/files/common-licenses, only MIT exists there. Isn't this a bug? Feb 11 19:42:50 MIT-style is not generic thats the problem, so you cant have a template, although name is generic Feb 11 19:44:22 maybe all X related should carry X11 License for LICENSE which is more appropriate SPDX naming Feb 11 19:51:08 /beginrant feels like when a packagegroup has been changed on disk it should rebuild /endrant Feb 11 19:51:31 ? usually it does.. Feb 11 19:51:36 nope Feb 11 19:51:50 it happily pulls from sstate Feb 11 19:52:29 unless I'm just completely bonkers Feb 11 20:04:15 neither the packagegroup nor core-image-full-cmdline rebuilt, so -c clean Feb 11 20:05:02 did the has equiv compare the dependencies and say they were the same and "lop" the dep tree? Feb 11 20:05:07 hash equiv Feb 11 21:03:51 is it best to have systemd tweaks in the distro conf or in a bbappend recipe? Feb 11 21:05:09 if you have your own distro and a custom layer then use either place Feb 11 21:23:13 moto-timo: what changed in this case? Feb 11 21:23:34 moto-timo: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7298 ? Feb 11 21:24:21 we could make it rebuild in those cases, we once did but its just a different set of problems Feb 11 21:28:40 @RP: I added a kernel module to RDEPENDS_${PN} in the packagegroup recipe Feb 11 21:31:18 moto-timo: that should cause a rebuild :/ Feb 11 21:38:34 @RP: it's weird that neither the packagroup nor the image rebuild... it's happened before but I didn't rant about it Feb 11 21:39:02 ironically the kernel module wasn't needed... but that's a different story Feb 11 21:39:51 @RP: this behaviour is nothing new... I certainly saw it several months ago Feb 11 21:39:51 moto-timo: is there a test case I could try and reproduce ? Feb 11 21:40:51 @RP: I should probably create a stripped down test case so you don't have to build everything in my kubernetes image Feb 11 21:41:09 moto-timo: please, I don't plan to do that Feb 11 21:41:14 lol Feb 11 21:41:21 nor would I expect you to! Feb 11 21:50:02 kergoth: whats immediate task after do_install in sequence Feb 11 21:50:13 is it do_package ? Feb 11 21:55:36 Guest94181: do_package and do_populate_sysroot together usually but the sequence can be changed Feb 11 21:56:33 ah so if a function is inserted between do_install and do_package it can race with do_populate_sysroot ? Feb 11 22:46:27 RP: we found an issue in gatesgarth, affecting newer kernels then 5.4.. The fix is already in master, but would a backport be allowed since it only affects people providing their own kernel versions? Feb 11 22:46:37 (affects kernel.bbclass, or we could just patch it with a bbappend) Feb 11 22:51:38 fray: depends on what the fix is really, how invasive/risky Feb 11 22:54:11 sec.. let me find the two commits.. small changes Feb 11 22:57:17 (oe-core commits) cb940d8af359fa370254bd4c2b36ba26708bb54b & cb940d8af359fa370254bd4c2b36ba26708bb54b Feb 11 22:57:24 oops, lets try that AGAIN Feb 11 22:57:49 0fc66a0b64953aae38d0124b57615fffaec8de52 & cb940d8af359fa370254bd4c2b36ba26708bb54b Feb 11 22:58:16 2 actual lines of change.. it does enabled unsupported kernels (newer then 5.4) but it shouldn't cause any issues Feb 11 23:11:59 they look fine for a backport imo Feb 11 23:18:00 I think it's reasonable, but we need to figure out if we need a local backport or if we can get it into gatesgarth and wait a few days for a backport Feb 11 23:20:56 what I meant to say backportable to gatesgarth upstream and acceptable Feb 11 23:47:14 fray: they're probably ok, you'd have to convince anuj :) Feb 12 01:23:03 Hi guys Feb 12 01:23:30 Can you help me how to rebuild after a distro feature addition? Feb 12 01:23:49 Is there any way not to rebuild everything? **** ENDING LOGGING AT Fri Feb 12 02:59:56 2021