**** BEGIN LOGGING AT Thu Nov 26 02:59:57 2020 Nov 26 05:49:30 on Dec 3 the first running of a new conference targeted at embedded (linux) development will occur: https://liveembedded.virtualconference.com/ Nov 26 05:50:14 my understanding is that the conference is organized by a group of embedded companies including Bootlin (for example) Nov 26 05:50:32 there are several OE/Yocto talks: https://liveembedded.virtualconference.com/#/agenda Nov 26 05:51:13 the conference schedule mostly aligns with European timezones Nov 26 07:13:55 Is it possible to make a "install dependency" on a recepie? Such as, in order to install the recepie, another must also be installed? Nov 26 07:14:46 I have a recepie that adds a small script and it uses netcat. Can I add something to that recepie so that I get an error during build if I dont add netcat too? Nov 26 07:18:30 blauskaerm: depending on where `netcat` is needed, where would the small script run Nov 26 07:18:31 blauskaerm: Can you add the required package to DEPENDS? Nov 26 07:20:08 mihai: It runs just after boot in multi-user mode Nov 26 07:20:37 iceaway: That could be a solution? Is DEPENDS used to give dependacy during build or can it be used for my situation too? Nov 26 07:20:49 dependency* Nov 26 07:21:13 blauskaerm: then you can add netcat to RDEPENDS variable, which will require netcat to be installed on the target when your script is also installed Nov 26 07:22:24 Looks like what I'm looking for! Nov 26 07:22:33 Thank you very much mihai :) Nov 26 07:22:45 blauskaerm: np Nov 26 07:23:27 blauskaerm: the complete variable specification to use is RDEPENDS_${PN} Nov 26 07:23:33 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-RDEPENDS Nov 26 07:24:55 I asked here a few days ago when I was having great difficulties installing lib32-libgdiplus in my image, but libgdiplus was fine. I have been digging into the details, and the issue seems to be that lib32-libgdiplus has a postinstall script that tries to use "lib32-qemuwrapper", but the PATH variable in the environment where the postinstall script runs does not include the "lib32-recipe-sysroot" only the Nov 26 07:25:01 "recipe-sysroot". If I make a hack and change the path in the "update_gio_module_cache" script before running qemuwrapper to include the lib32-recipe-sysroot it works fine. Any idea why, or how I can change it, so that the postinstall script also searches the lib32-recipe-sysroot path? Nov 26 07:26:38 This seems to run in the context of the image recipe, so the recipe-sysroot is for the image recipe, not the package recipe. (it's actually not libgdiplus that is the issue, it is libglib-2.0 which is a dependency). Nov 26 07:56:45 Hey! Having a weird compile problem I cannot seem to resolve no matter what I do Nov 26 07:57:09 WARNING: lz4-native-1_1.9.2-r0 do_fetch: Failed to fetch URL git://github.com/lz4/lz4.git, attempting MIRRORS if available Nov 26 08:00:14 I can get this repo no problem manually Nov 26 08:05:07 wertigon: what's the compile problem? that's a fetch warning :) Nov 26 08:05:17 maybe you can pastebin it somewhere Nov 26 08:06:04 Ok, it's a fetch warning; it then complains about no other mirrors having the expected commit hash Nov 26 08:06:29 And then proceeds to say there is no source at all Nov 26 08:06:58 good morning Nov 26 08:07:23 'morning Nov 26 08:08:04 wertigon: maybe you're trying to use a commit from another branch, in which case you need to also specify the branch Nov 26 08:08:38 https://pastebin.com/3erq28vY <-- Full pastebin of error Nov 26 08:08:54 Yeah, maybe Nov 26 08:09:30 Thing is this worked perfectly before... Hmmmm... Nov 26 08:10:04 Could it be that upstream changed name of master branch? Nov 26 08:12:12 ... Yes, this actually seems to be the reason! Nov 26 08:13:22 https://github.com/lz4/lz4/branches/all Nov 26 08:13:35 master branch deleted, dev branch is now default Nov 26 08:15:55 *lesigh* Nov 26 08:16:59 wertigon: care to report a bug if this is still present on dunfell and/or master? Nov 26 08:18:13 I think it is present on dunfell Nov 26 08:18:27 wertigon: can you file a bug then? Nov 26 08:19:57 Absolutely, either this was introduced recently or lz4 is not used that often Nov 26 08:20:05 mcfrisk: howdy! do you maybe have a couple of minutes in private to discuss some BSP crazyness that came to my mind? Nov 26 08:21:03 wertigon: its much more likely that they renamed the branch a couple of days ago, and nobody caught it because we're all working with hot download caches. i can confirm that on monday dunfell still built fine. (though i'm not sure if my build included lz4) Nov 26 08:23:53 Yeah, this was broken a couple of days ago Nov 26 08:24:22 I did a clean rebuild a couple of days ago because it's what you must do Nov 26 08:25:04 Every month or so we do clean rebuilds to catch errors like these, I mean Nov 26 08:26:35 LetoThe2nd: sure, I could have a chat Nov 26 08:28:41 Should the bug be filed under meta-yocto, oe-core or other? Nov 26 08:37:38 wertigon: oe-core Nov 26 09:02:27 LetoThe2nd: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14135 Nov 26 09:03:19 wertigon: great, thank you very much! Nov 26 09:06:33 LetoThe2nd: I also included the quick fix for it :) Nov 26 09:08:19 wertigon: for additional brownie points, send a patch to the oe-core ML :) Nov 26 09:46:25 So this is a stupid problem, but I pressed CTRL+C immediately after "bitbake target" (twice) and now I can't run bitbake anymore at all. It just gets stuck Nov 26 09:46:27 What can I do? Nov 26 09:47:25 thecomet: Easiest is to just delete tmp-glibc and re-run Nov 26 09:47:36 It'll cost you a bit of time Nov 26 09:48:03 Will my workspace/sources directory still be in tact or will I have to run devtool modify again? Nov 26 09:48:03 No idea if there is a more elegant solution out there :) Nov 26 09:48:29 Yes, only delete tmp-glibc in the build folder Nov 26 09:49:08 I think there is a bitbake command in there somewhere, but no idea where, how or when. Nov 26 09:49:31 the bitbake server is a python process, isn't it? Nov 26 09:50:08 think I recall killing a python process to force a hung bitbake process Nov 26 09:52:04 I deleted build/bitbake.lock and that seems to have fixed it Nov 26 09:52:45 I should have probably checked for python processes first though, oops Nov 26 09:55:19 kanavin_home: should I stop that f33 reproducible build? Nov 26 10:03:02 RP: it seems like diffoscope chokes on large items, let me take a look Nov 26 10:04:45 RP: yes you can stop. I think any failing packages are already saved so I can look at it - seems like llvm wasn't quite fixed fully Nov 26 10:10:24 hello. what are the possible unwanted side effects of having a very high BBFILE_PRIORITY on your custom layer? Nov 26 10:11:14 I'm trying to replace a psplash image from oe, that has already been bbappend'ded by another layer, and what I really want is my image to be used from meta-mylayer Nov 26 10:11:45 and log.do_unpack picks other layer's bbappend due to my layer priority. Nov 26 10:12:42 cengiz_io: highest prio will be applied last provided the paths in SRC_URI are identical Nov 26 10:13:15 SRC_URI's are identical Nov 26 10:13:28 cengiz_io: triple check your paths, quadruple check your FILESEXTRAPATHS_prepend := Nov 26 10:14:00 cengiz_io: and check that your bbappend is actually applied (there's a bitbake-layers command for that IIRC) Nov 26 10:14:13 qschulz I did copy the exact bbappend and files. didn't even rename them. Nov 26 10:15:12 qschulz it's definitely being added to search path, as I see it in do_unpack logs. Nov 26 10:15:40 cengiz_io: shouldn't do_unpack only list the paths it failed to find a file in? Nov 26 10:16:05 hmm Nov 26 10:16:16 here's a snippet of it. Nov 26 10:18:40 DEBUG: Searching for psplash-poky-img.h in paths: | ... ... Nov 26 10:19:06 if the order is relevant to priority, my layer is skipped Nov 26 10:19:19 NOTE: Unpacking /yocto/meta-agl/meta-agl-profile-core/recipes-core/psplash/files/psplash-poky-img.h Nov 26 10:20:11 meta-agl-profile-core has priority of 80, meta-mylayer has 20 Nov 26 10:24:49 cengiz_io: there you go: https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-BBFILE_PRIORITY Nov 26 10:25:02 meta-mylayer has lower prio Nov 26 10:26:02 yeah I've changed it to 80 will see if my PV will let me override it Nov 26 10:33:35 qschulz equalizing the priority and adding SRCREV = "${AUTOREV}" \n PV = "1.00+git${SRCPV}" did the trick Nov 26 10:34:08 qschulz with too high priority it wasn't compiling. Nov 26 10:36:05 cengiz_io: don't use AUTOREV for production ;) Nov 26 10:36:17 qschulz don't really care Nov 26 10:36:42 cengiz_io: if the order or priority breaks your build, your layer needs to be reworked Nov 26 10:36:49 (or AGL's) Nov 26 10:39:30 qschulz you're probably right but I'm out of willpower and time Nov 26 10:40:12 btw what's wrong with AUTOREV? I already commit each change to my layer Nov 26 10:40:43 and what else do you suggest? hardcoded rev? Nov 26 10:41:10 is there an yocto example to install python packages from the source and without pypi? Nov 26 10:43:09 I meant recipe example Nov 26 10:46:47 rcrudo did you check openembedded recipe search? Nov 26 10:47:08 python recipes are very scarce though Nov 26 10:48:08 cengiz_io: yes, they all seems to use pypi Nov 26 10:50:29 cengiz_io: the point of a build system is to be able to rebuild an image years after it was originally built Nov 26 10:50:42 AUTOREV means that yoiu'll never be able to do that because it'll always fetch the last commit Nov 26 10:52:22 rcrudo: I know bmap-tools isn't published on pypi so you may be able to find a recipe for that Nov 26 10:52:24 qschulz indeed. but I'm not frozen my build yet. Nov 26 10:53:08 rcrudo: If your python source has a `setup.py` file it's usually pretty simple to make a recipe for it Nov 26 10:55:15 paulbarker: bmap-tools looks like a good example, thanks Nov 26 10:58:12 what's intended the distribution layer for? https://imgur.com/lqQreTs.png Nov 26 11:00:40 wyre: in a nutshell, the DISTRO layer defines the ABI/API of the resulting distribution, and therefore the facilities that "higher" applications can use. Nov 26 11:02:52 kanavin_home: ok. I figured it was stuck in diffoscope :/ Nov 26 11:09:03 anyone seen this before? ` error: 'POKY_IMG_WIDTH' undeclared (first use in this function); did you mean 'BAR_IMG_WIDTH'?` Nov 26 11:09:34 for the record, I'vve generated image header with https://git.yoctoproject.org/cgit/cgit.cgi/psplash/plain/make-image-header.sh script Nov 26 11:11:00 yikes. that script requires a second argument... Nov 26 11:11:09 nevermind me. Nov 26 11:27:09 I'm trying to find where in bitbake the PATH variable is set up when doing various recipe tasks (do_rootfs in particular). Any suggestions? Nov 26 11:32:00 RP: I do wonder if diffoscope somehow has a bug, because one of the selftests passed fine through the diffoscope step, with the same set of non-reproducible packages Nov 26 11:32:10 and in any case, it should not run for this long Nov 26 11:34:18 iceaway: bitbake -e not being helpful? Nov 26 11:34:27 kanavin_home: that was the one which built the original packages so they would match Nov 26 11:34:34 (maybe?) Nov 26 11:45:48 RP: not sure I understand your explanation? the passing selftest was this one https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1580 Nov 26 11:46:11 one other selftest from a-full failed, and two others got stuck in diffoscope Nov 26 11:47:16 RP: ah nevermind Nov 26 11:47:43 I get it now: the passing selftest built packages from scratch and that matched Nov 26 11:47:58 when one of them comes from sstate, it may be mis-matching Nov 26 11:48:27 RP: the mystery is I guess why one other selftest failed, and two others got stuck Nov 26 11:52:04 kanavin_home: right, I'd guess it just depends which builders built the objects in sstate Nov 26 11:53:08 RP: the packages are all saved here for failing and cancelled ones Nov 26 11:53:08 https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201125-u6roxed2/packages/reproducibleA/tmp/deploy/ipk/core2-64/ Nov 26 11:53:08 https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20201125-dnr1qh6w/packages/reproducibleA/tmp/deploy/ipk/core2-64/ Nov 26 11:53:35 I'll take a look what is different there, I guess diffoscope cannot handle enormously big items like llvm Nov 26 11:56:26 kanavin_home: right, it seems to have a problem when things get really large :/ Nov 26 12:26:56 @qschulz: yesterday you suggested to me, that I should just cherry-pick the most necessary stuff from ADI like kernel, u-boot etc. I would like to hear how you make sure that these components keep up to date with the vendor "upstream". Do you still include their meta-layer and work with layer preferences (if I recall correctly there was some option of this sorts) or do you just hard copy the recipes from their layer to your own. If Nov 26 12:33:50 (found it: laking about the BBFILE_PRIORITY setting in the layer config) Nov 26 12:33:55 *talking Nov 26 12:47:55 LetoThe2nd: I was thinking more of in which script the PATH is configured, but maybe I can dig that out of bitbake -e? Nov 26 12:48:34 iceaway: if it is something that is dynamically set, then you can, yes. Nov 26 12:52:05 JaBen: I do not include their meta-layer and we do not keep up to date Nov 26 12:52:19 IoT industry does not care about upgrade sadly Nov 26 12:52:40 but you'd manually monitor changes to source git repos or layer git repos Nov 26 12:54:50 BSP component recipes rarely change so much that you can't just change SRCREV manually though Nov 26 12:55:11 @qschulz: hm ok... wouldn't it be easier to use their meta-layer and just add your own layer on top with a higher priority? this way you could still automatically pull updates from the few recipes you use from their layer Nov 26 13:03:04 ok, I just noticed this wouldn't work too well for 2. reasons. 1: the BBFILE_PRIORITY is set within the layer itself and 2: the layer compatibility still would stop us from using their layer with dunfell. unless this can be overwritten within the local.conf? Nov 26 13:05:10 JaBen: in which case you want to BBMASK everything you don't need AND make sure it's still ok to build later on Nov 26 13:06:08 JaBen: it can be overwritten in local or layer.conf (even one that isn't the layer's, but that's uuhhh.. not guaranteed, it's not intended, it works but nothing tells us it won't be modified later) Nov 26 13:06:32 (we use the layer.conf method for meta-qt5 IIRC ;) ) Nov 26 13:10:49 ok, so assuming this doesn't get modified, taking meta-qt5 as an example I could try setting BBFILE_PRIORITY_meta-qt5 = X and LAYERSERIES_COMPAT_meta-qt5 or is it minus the "meta-"? Nov 26 13:10:51 JaBen: I'd rather spend time on debugging my own recipes based on vendor's BSP components than debugging their layers Nov 26 13:11:07 specifically, we add a shit ton of patches on top, so we anyway fork off the vendor;s Nov 26 13:11:29 JaBen: priority probably not but LAYERSERIES_COMPAT yeah Nov 26 13:11:49 though it's probably not meta-qt5 but the name of the BBCOLLECTIONS (qt5-layer maybe? don't remember) Nov 26 13:14:59 @qschulz: I get where you are coming from with "not wanting debugging their layer", however I am hoping to be able to automatically build two versions using KAS: using the latest known-working refspec and bleeding-edge. so I naively assumed, that debugging their changes might be less of a pain if we just test their changes fast enough :D Nov 26 13:17:14 How can set my yocto image to use python3 as default? I want to fix this: QA Issue: /usr/bin/hexmerge.py contained in package python3-intelhex requires /usr/bin/python Nov 26 13:19:29 @qschulz I'm just a bit scarred by our status quo, where we have some 5 year old forks of OSS projects within our firmware, which are a maintainability nightmare as my colleagues also added their own stuff on top... so really painful to keep up to date :/ Nov 26 13:20:40 rcrudo: shebang at the top of you script needs to have python3 in it Nov 26 13:20:54 rcrudo: and migrate the script to python3 if it was written for python2 Nov 26 13:21:41 JaBen: I might be biased as I really don't trust vendors (well technically, we're vendors too and our layers aren't that much better, but it's only our fault :p) Nov 26 13:22:13 JaBen: and if I had the choice I'd go 100% upstream Nov 26 13:22:22 but yeah, you see the maintenance burden Nov 26 13:32:55 @qschulz: Ok, so the ADI layer defines `LAYERSERIES_COMPAT_adsp-sc5xx = "thud"` and I tried setting `LAYERSERIES_COMPAT_adsp-sc5xx_append = " dunfell"` in local.conf without any luck. :/ Nov 26 13:33:20 in bitbake/lib/bb/fetch2/ most logging is done through bb.fetch2.logger, but there is a handful of bb.note calls - how harmless is that ? Nov 26 13:35:53 JaBen: then in any other layer.coinf Nov 26 13:36:03 ok Nov 26 13:37:11 that seems to work :) Nov 26 13:37:39 subject to breakage ;) Nov 26 13:44:21 @qschulz: lets hope not :D I mean being able to set the layer priority from outside the layer in question sounds like something you would want to be able to do. especially when relying a lot on upstream Nov 26 13:45:45 JaBen: you can always work around priorities by splitting your layers into higher and lower prio compared to upstream layers you depend on Nov 26 13:47:20 true, but say you want to put an upstream layer at a higher priority than a second upstream layer Nov 26 13:48:56 JaBen: if they have same prio, the order in which they are included in bblayers.conf is the way to order your layers Nov 26 13:49:48 how to shitfix vendor layers 101: overwrite their compatibility setting and bbmask stuff until it builds! :D Nov 26 13:50:54 @qschulz: assuming they have the same prio... but good to know that the order makes a difference. So the last one to add is is highest prio? Nov 26 13:52:42 JaBen: IIRC yes Nov 26 13:52:50 but not for classes and conf files :p Nov 26 13:52:54 (the opposite) Nov 26 13:56:02 @qschulz well thats not confusing at all :P Nov 26 13:57:52 JaBen: classes and conf files are parsed in order of BBPATH, which by default is appended to by each layer and the priority does not matter for that one Nov 26 14:27:07 qschulz: that is not my script. it's coming from pypi installation Nov 26 14:35:43 nvm, fixed with do_install_append Nov 26 14:37:11 rcrudo: care to tell us what you did? (IRC messages are archived and publicly available so if anyone has the issue,m they may fall on this archive :) ) Nov 26 14:38:19 I used do_install_append with a sed -> sed -i 's|#!/usr/bin/python|#!/usr/bin/python3|g' ${D}/usr/bin/*.py Nov 26 14:40:40 rcrudo: is it an exact match? Nov 26 14:41:02 because if your package is updated upstream one day, you might replace #!/usr/bin/python3 with #!/usr/bin/python33 Nov 26 14:44:09 qschulz: good point! thanks for the code review ;) Nov 26 14:47:22 Hey :) Nov 26 14:47:27 What are .in files in Yocto? Nov 26 14:48:38 oppostite of .out! Nov 26 14:48:53 Ah, I thought it might have been related to .inc lol Nov 26 14:50:34 well that would be .inc files :) nah seriously, if it was a typo and you mean .inc, then its actually nothing with deeper meaning other than it being a file that is included somewhere. if it wasn't a typo, no idea. never seen any .in files. Nov 26 14:54:26 I think those are files that are supposed to be handled in Yocto to replace some variables? Nov 26 14:54:41 or sometimes by autotools or whatever Nov 26 14:57:10 You guys are great, didn't expect a quick response, or 270~ users to be here lol. Nov 26 14:58:39 huh? Nov 26 14:59:37 well sure autotools have Makefile.in somewhere in their processing stage for example, but where do they surface in yocto context? (serious question, never witnessed that) Nov 26 15:00:04 So, I still don't really know what a .in file is, I can't really find it in the docs explained. Nov 26 15:00:29 matthewcroughan_: it would be useful if you just would show the file, respectively path where it can be found. Nov 26 15:00:32 The first mention of .in is here in the megamanual. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-a-patch-for-the-fix Nov 26 15:00:39 (e.g.: you're missing context at the moment) Nov 26 15:01:04 ah. Nov 26 15:01:33 thats no "yocto" context, rather just "some generic whatever file somewhere in the package that has to be patched" Nov 26 15:02:31 or alternatively, "jsut some generic file that is used in some way in the package". Nov 26 15:02:55 but in no meaning it relates to the yocto build process - it is something package-internal. Nov 26 15:04:10 you can have a file "fooboobar.xyzzy" that comes with your recipe and is being packaged. bitbake itself doesn't care what it is, it just carries out what the recipe defines to be done with it. Nov 26 15:06:58 LetoThe2nd: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#example-obtaining-bitbake Nov 26 15:07:05 What would the purpose of MANIFEST.in be here then? Nov 26 15:07:50 I just see these files around and wonder "Why does it have that extension? Nov 26 15:10:33 i have to admit, i see that question and wonder why would anybody on earth even think of that. :) but seriously, i have no idea. it is definitively a bitbake source internal. if you absolutely and totally must know, then get in touch with one of its maintainers. but i can assure you that you will have a long and happy yocto career without ever seeing that file again. Nov 26 15:13:55 today i learned: https://packaging.python.org/guides/using-manifest-in/ Nov 26 15:14:13 matthewcroughan_: here you go ^^^^ just like i said. bitbake source internal. Nov 26 15:14:52 (please note that this in no way correlates to the example in the manual that you mentioned.) Nov 26 15:17:06 oh okay so this has nothing to do with recipes then in that context Nov 26 15:17:36 absolutely and totally not. Nov 26 15:18:43 what if you had a file like recipes-core/utils/ostree/ostree/ostree-daemon.in ? Nov 26 15:19:10 do you need context for this sort of thing? Do extensions mean anything to bitbake if they're not .bb or .bbappend? Nov 26 15:20:24 those are files included in recipes Nov 26 15:21:29 qschulz: note the second "ostree" in the path Nov 26 15:22:24 matthewcroughan_: this is an example of the case you mentioned in the manual. this is a file that is in some way ingested by the recipe. look at its SRC_URI, it is probably there. and then look at the recipe what it is being used for. Nov 26 15:22:37 e.g.: doesn't relate to yocto Nov 26 15:23:41 Okay, what *is* the recipe and what *is not* the recipe? Nov 26 15:23:48 matthewcroughan_: and it really helps if you refer to things that we can also see. this seems to be nothing that we can inspect. Nov 26 15:23:56 matthewcroughan_: recipe: .bb Nov 26 15:25:20 matthewcroughan_: if inside the recipe things are "included" or "required", then they effectively also become part of it. everything else is *not* the recipe. Nov 26 15:26:15 So, if a file without .in is present, it is not in the recipe? Nov 26 15:26:27 By not putting .in on the end of a file, you are excluding it? Nov 26 15:26:32 LetoThe2nd: I saw it, hence my remark ;) (recipes-*/*/*.bb is the default so one too many subdir :) ) Nov 26 15:27:03 qschulz: which in turn means that it is in the default FILES searching path. Nov 26 15:27:25 matthewcroughan_: a .in file is nothing to yocto, it makes sense only for a software built by Yocto Nov 26 15:27:35 it's something you add to the sources of whatever you want to build Nov 26 15:28:01 matthewcroughan_: i have no idea how i shall word it in any other way than i already it. this file is something that the author of the recipe added/needs for something the recipe does. we know nothing of it, yocto knows nothing of it. Nov 26 15:28:02 Well the exact case I'm trying to understand seems to be here. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-a-patch-for-the-fix Nov 26 15:28:13 * LetoThe2nd facepalms and is silent now. Nov 26 15:28:25 neard.service.in Nov 26 15:28:43 what purpose does .in serve? Is it literally just convention? or does it serve a literal purpose? Nov 26 15:29:10 it's an automake concept. nothing to do with yocto. Nov 26 15:29:26 just like "Makefile" means nothing to oe/yocto. Nov 26 15:34:51 zeddii: Awesome. Nov 26 15:35:03 So similarly, .patch means nothing? It just hints at the contents and purpose of the file? Nov 26 15:35:36 matthewcroughan_: hehehe no. .patch files will be applied to the source in order of their declaration in SRC_URI Nov 26 15:35:54 okay, so bitbake *does* care about more than just .bb and .bbappend files? Nov 26 15:35:54 same for .diff Nov 26 15:36:16 Is there a list of file extensions that are special to bitbake? :D Nov 26 15:36:38 matthewcroughan_: they're actually not special to bitbake, they're special to recipes built by bitbake Nov 26 15:36:46 .patch, .diff are applied by default Nov 26 15:36:58 some tarball extensions are automatically unpacked too Nov 26 15:37:03 Is this behavior somewhere in the bitbake manual then? What should I search for? Nov 26 15:37:23 matthewcroughan_: if you want to understand everything that bitbake does, you're in for a long journey Nov 26 15:37:43 I haven't read thebitbake manuals even once Nov 26 15:37:46 though i should Nov 26 15:37:57 i've read the Yocto manuals though Nov 26 15:38:08 just start working on something simple and build your knowledge from there Nov 26 15:38:27 That always works. Though I'm really not sure where the starting point is. Nov 26 15:42:29 qschulz: What determines if a function is executed in a bitbake file? Nov 26 15:42:36 By being defined, is it always ran? Nov 26 15:43:23 do_something() do_something_else(), how do I conditionally *not* run the latter function? Or have I misunderstood bitbake? Nov 26 15:47:45 Additionally, is there an importance to the `do_` in `do_thing` or is this again just naming convention? Nov 26 15:48:24 matthewcroughan_: tasks should start with do_, that's a convention Nov 26 15:48:37 right, but it doesn't have any literal effect like vars do? Nov 26 15:48:39 you can have "normal" python or shell functions which aren't tasks too Nov 26 15:48:55 SOMEVAR_append has a real usage, and it does stuff, but do_ doesn't magically do anything on your behalf right? Nov 26 15:48:57 tasks aren't run (except the anonymous one) except asked Nov 26 15:49:27 "asked" can be by the user or through recipe or task dependencies Nov 26 15:56:03 is example.com down? bitbake is telling me I don't have internet connection but I have. It seems it connects to example.com and if it doesn't respond it exits Nov 26 16:04:22 has there been a change on how to SRC_URI a folder since thud? Trying to set SRC_URI += "file://feature/" throws an "ERROR. input file "feature/cfg/nfs.cfg" does not exist", although path /mnt/lnxdsp-adi-meta/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi/ is searched and /mnt/lnxdsp-adi-meta/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi/feature/cfg/nfs.cfg exists Nov 26 16:04:37 stkw0: https://downforeveryoneorjustme.com/example.com Nov 26 16:08:18 LetoThe2nd: thanks, something is wrong with my computer, it doesn't resolve that domain specifically :( Nov 26 16:10:36 This is the file in question btw: https://github.com/analogdevicesinc/lnxdsp-adi-meta/blob/develop/yocto-1.0.1/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi_4.19.bb Nov 26 16:12:15 @stkw0 assuming unix-like, try setting a different dns server in /etc/resolv.conf for testing purposes ( e.g. 1.1.1.1) and see if the issue still persists. Nov 26 16:13:07 JaBen: I did it, same problem. I also tried to use the phone and connect to example.com and chrome gives a DNS_PROBE_FINISHED_NXDOMAIN, I guess the ISP is doing something Nov 26 16:15:48 @stkw0: you could try running `dig example.com` and see which server is answering the request Nov 26 16:16:48 using dnscrypt-proxy ""fix"" the issue Nov 26 16:17:10 JaBen: yeah, that is what I was trying, using dig with different dns servers, but none worked Nov 26 16:17:10 gotta love ISPs Nov 26 16:32:53 JaBen: i'm surprised file://feature/ would throw such a specific error (a file namely) Nov 26 16:36:57 @qschulz: interestingly enough, the folder (and files) are actually added to build/tmp/work/adsp_sc573_ezkit-poky-linux-gnueabi/linux-adi/4.19-r0/feature/. So this appears to be a bug within yocto or bitbake? Nov 26 16:48:57 JaBen: when does the error happen (which task?) Nov 26 16:49:12 JaBen: always blame the vendor before upstream :) Nov 26 16:51:19 @qschulz: I'd agree, but I don't see how this could be a vendor issue. I'm running `bitbake linux-adi` which this recipe: https://github.com/analogdevicesinc/lnxdsp-adi-meta/blob/develop/yocto-1.0.1/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi_4.19.bb Nov 26 16:54:02 the task failing is "do_kernel_metadata" Nov 26 16:57:59 @qschulz: complete log is here: https://paste.it-works-jbo.de/?ba6a4fc7f76e59b3#3LaUkCJTyreu5QX49PgtzAomCWBnTcXuw9GKezSUydF1 Nov 26 17:02:20 JaBen: first one in the list has a full path, not the others Nov 26 17:04:35 JaBen: just being curious, but what about adding all config fragments by hand (and not use features/ only) Nov 26 17:09:14 @qschulz: so I tried setting SRC_URI += "file://feature/cfg/nfs.cfg", same issue. Only adding FILESEXTRAPATHS_prepend := ${THISDIR}/${BPN}/feature/cfg/:" and SRC_URI to "file://nfs.cfg" worked Nov 26 17:09:46 @qschulz so I assume the parser at some point tries to interpret "feature/cfg/nfs.cfg" as a filename Nov 26 17:11:10 I see there has been a lot of change to do_kernel_metadata since thud Nov 26 17:12:47 I'm trying to integrate our yarn fetcher by monkey-patching (like meta-rust) to avoid touching the poky repo, and stumbled on a strange issue: when doing that, SRCPV stops being defined (that YarnFetcher is still derived from gitsm) Nov 26 17:13:27 looks like SRCPV is only set if the URI scheme matches a hardcoded list :( Nov 26 17:14:14 any reason needsrcrev is not defined by the fetcher ? Nov 26 17:33:31 JaBen: I'm clueless sorry Nov 26 17:33:43 might want to send a mail or open a bug on bugzilla Nov 26 17:34:05 (try to reproduce on linux-yocto from gatesgarth though before) Nov 26 17:45:13 @qschulz: I am afraid you were right and it seems to be a vendor issue. no idea how, though... I'm not able to reproduce on a basic poky image Nov 26 17:45:44 how can I use recipetool setvar recipename.bb "-option" ? Looks like the dash gives an error Nov 26 17:46:09 and setvar recipename.bb -option doesn't work Nov 26 18:00:59 @qschulz: ok, so the issue actually comes from these lines: https://github.com/analogdevicesinc/lnxdsp-adi-meta/blob/ad2203c11723b07727589a8eebe33f3129cc236a/meta-adi-adsp-sc5xx/recipes-kernel/linux/linux-adi_4.19.bb#L21-L24. So the error message is definitely misleading... Nov 26 18:35:52 @qschulz: eeeehhh... stupid question: shouldn't the files be added to the ${S} (${WORKDIR}/git) directory? because in my case they end up in ${WORKDIR} Nov 26 18:36:41 No, stuff from SRC_URI has always been placed in WORKDIR, unless you manually specified a different destination Nov 26 18:52:45 JaBen: idiom is that SRC_URI files are put in WORKDIR, and then anything that is an archive unpacked. S is WORKDIR/BPN-PV, so if your SRC_URI is a typical tarball, S points into the unpacked tarball Nov 26 21:12:39 Hey everyone, one of my recipes inherits setuptools3 to build a python package. I would like to pass something to it's setup.py. Best would be an environment variable. How can I set a variable so that it can be accessed by the setup.py? **** ENDING LOGGING AT Fri Nov 27 02:59:56 2020