**** BEGIN LOGGING AT Tue Mar 23 02:59:56 2021 Mar 23 07:04:26 RP: linker is crashing see https://errors.yoctoproject.org/Errors/Details/574353/ Mar 23 07:58:33 good morning Mar 23 07:59:31 JPEW: I said AFAIK. Could you share any wks configuration file to study it? and which YP version were you using? Mar 23 08:32:44 mornin' folks Mar 23 08:34:17 good morning Mar 23 08:38:44 g'mornin' Mar 23 09:31:19 khem: interesting. so a gold issue? Mar 23 10:04:36 Right now I have psplash stopping (QUIT message from psplash-systemd) too early, I'd like to extend it all the way to default.target, how would I go about it? Mar 23 10:10:57 systemd1 manager gives Progress: 1.0 way too early into the boot IMHO. Do you know if it even takes multi-user.target into account? Mar 23 11:45:09 alimon: ptest-runner fixes look good :) Mar 23 11:48:36 oobitots51: Looks like the run-postinsts change on list caused failures in master-next. Do you want to reply about that? Mar 23 11:50:15 Added to already existing but now moving to separate bug Mar 23 11:51:59 oobitots51: it doesn't really need a bug since it isn't merged, just a reply on the list showing the failures the patch caused Mar 23 12:04:21 Yocto is showing error Mar 23 12:04:22 ERROR: Nothing PROVIDES 'gstreamer'. Close matches: Mar 23 12:04:23   gstreamer1.0 Mar 23 12:04:23   gstreamer1.0-omx Mar 23 12:04:23 I need to know which of the above recipe is actually used by my final Image. How to easily find that ? Mar 23 12:09:20 JosephAntony: gstreamer1.0 is what you're looking for Mar 23 12:13:15 Yeah. My actual doubt was how to find out which of the above recipes are actually dependant on my final Image Mar 23 12:13:41 how can we find that in yocto using bitbake ? Mar 23 12:14:54 JosephAntony: the image recipe can depend on gstreamer, not the opposite, so not quite sure to understand the question? Mar 23 12:15:12 well, not depend actually, install or include gstreamer package is a better wording Mar 23 12:15:40 the error is from a recipe incorrectly specifying "gstreamer" in DEPENDS, I believe there's more output from bitbake for that error that indicates which recipe it is Mar 23 12:24:53 qschulz Yeah. I told it the wrong way. Image recipe depends on gstreamer. So refarming my question...  how can I get to know, which all recipes my final image depends on ? Is there any bitbake command to know that Mar 23 12:25:06 reframing* Mar 23 12:25:40 JosephAntony: smurray said the right thing, you should have a few lines above this error which recipe DEPENDS on gstreamer Mar 23 13:22:01 What is the correct way to use a non-standard Python module inside a recipe Python task function? Should I do DEPENDS+="python-something-native" or rather pip install something? The first seems cleaner, because it doesn't pollute host's Python installation. But it installs the modules into native Python while the task function is executed with host Mar 23 13:22:02 Python, which is problematic for some modules. Mar 23 13:22:17 mckoan: http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/wic/rk3399-boot.wks Mar 23 13:23:01 mckoan: AFAIK, GPT is the default and you have add an option to make it use MBR Mar 23 13:24:10 mckoan: I'm actively testing this with 3.1 and later, but I'm pretty sure it works on older versions also (likely also 3.0 and 2.7) Mar 23 13:26:17 Hi! I have multiple packages that RPROVIDES some virtual package, and I would like to have them conflict with each others when installing them with opkg. Is there a way to do that avoids listings all the other packages in the RCONFLICTS of each packages ? (I have quite a few of them) Mar 23 13:39:38 RP: good, i will wait a couple of days to see if someone replies Mar 23 13:45:47 I'm trying to find out why the LICENSE_FLAGS = "commercial" is there in ffmpeg.bb, but can't find any explanation. Commit 4acdab05e just mentions, while moving the libav recipe from meta-oe, that it adds this declaration. Surely there must be a reason, should it be stated in clear in the recipe near the flag setting ? Mar 23 13:46:14 "shouldn't", I meant Mar 23 13:50:10 yann: ffmpeg is full of patented code Mar 23 13:51:05 rburton: you mean "code for patented algorithms", right ? Mar 23 13:56:25 right Mar 23 14:00:46 so this is a blanket flag rather than checking all individual codecs ? Mar 23 14:02:20 yeah Mar 23 14:02:23 patches welcome Mar 23 14:02:57 yann: Ya, I think the idea is that OE doesn't want to accidently include something you can't use, so you need to manually evaluate and set the flag if your specific usage is allowed Mar 23 14:06:17 JPEW: i supposed as much. But then that forces reevaluation of the flag setting each time someone tweeks their PACKAGECONFIG. All-or-nothing flag may provide liability protection for OE, but as OE users it falls somewhat short :} Mar 23 14:12:59 khem: one more thing for meta-clang, what about replacing recipes-devtools/clang/clang/0029-llvm-Recognize-yoe-and-poky-as-OE-distro.patch with a sed call (or something similar) which will add whatever is in TARGET_VENDOR variable instead of supporting only "oe", "yoe", "poky" and "wrs"? Mar 23 14:18:31 rburton: the only direction I can see for a patch, would be to tie the "commercial" flag to individual codecs, ie. to PACKAGECONFIG items. Maybe adding a "commercial_$foo" flag for each $foo feature, so we could still use LICENSE_FLAGS_WHITELIST="commercial" for ignore all restrictions, or whitelist individually-evaluated algorithms without a need to worry ? Mar 23 14:19:41 yann: Ya. I did that recently for a different recipe.... Mar 23 14:19:44 * JPEW looks Mar 23 14:20:17 yann: libomxil Mar 23 14:21:49 JPEW: thx Mar 23 14:31:20 * zeddii mutters that when people try to undo your commits, they should cc' you directly on patches. Mar 23 14:31:57 * paulg reverts zeddii and doesn't Cc him. Mar 23 14:38:03 rburton, JPEW: something like https://pastebin.com/50WPh6h3 ? I'm not that happy with the embedded split() calls, I guess python should be able to call them just once, but eh... Mar 23 14:55:46 am I wrong in thinking that gstreamer1.0-libav itself does not need the "commercial" flag, since ffmpeg.bb takes care of it ? Mar 23 14:59:43 also, is it a good idea to have "gpl" in the default ffmpeg PACKAGECONFIG ? Mar 23 15:14:37 is there a way to see a varible's value in bitbake? i'd like to see the list of AVAILTUNES Mar 23 15:18:42 yates: bitbake -e recipe Mar 23 15:20:49 yann: thanks for that. i only get this: AVAILTUNES=" x86 x86-64 x86-64-x32 i586 i686 core2-32 core2-64 core2-64-x32" Mar 23 15:21:27 i expected a whole lot more than that. is this within a specific processor type, like intel? Mar 23 15:22:01 Above that line you should see a history of how this value was constructed. Mar 23 15:22:18 yates: any example of what you expected ? Mar 23 15:22:24 could be affected by your $MACHINE, $DISTRO and other configurations Mar 23 15:22:52 how about all the arms? cortex a7, a8, a9, arch64, blah etc. Mar 23 15:23:10 neverpanic: really? ok Mar 23 15:30:04 it looks like they're defined in poky/meta/conf/machine/include/ Mar 23 15:32:50 what i am trying to accomplish is what i consider step 1a of setting up yocto to build for a new architecture/ machine: csky:ck810: https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=bfd/cpu-csky.c;hb=HEAD Mar 23 15:33:26 and get the populate_sysroot working with a good cross-tools Mar 23 15:35:08 there are so many freaking variables/configurations/files scattered about i'm tearing my hair out Mar 23 15:36:05 (at least if i had hair, i'd be tearing it out...) Mar 23 15:41:53 * yates begs for help Mar 23 15:42:02 * yates would pay for help Mar 23 15:51:22 yates: is that an arm cpu ? Mar 23 15:52:08 oh, nm :) Mar 23 15:55:37 yates: I'd suggest you worry about tunes later and first just setup the toolchain - maybe look at riscv support for inspiration as a less complicated ecosystem than arm ? Mar 23 16:06:25 yann: aren't the TUNE values used at some level to select (e.g.) the specific binutils that will be built for? Mar 23 16:07:02 right, it is NOT an arm Mar 23 16:11:20 IIRC that's the distinctive thing about TUNE: not requiring to rebuild the toolchain and only play with toolchain flags - others will correct me if I'm wrong Mar 23 16:11:24 yates: I notice that they have a page indicating buildroot support, probably have to pick that apart as a starting point Mar 23 16:12:02 yann: one thing that comes to mind would maybe be to look at the commits in oe-core that added initial risc-v support for comparison Mar 23 16:12:32 oops, that last one was for yates ^ Mar 23 16:12:53 autocomplete fail ;) Mar 23 17:38:16 ok thanks for the hints guys. Mar 23 17:38:59 smurray: what buildroot page did you see? Mar 23 17:39:37 yates: just a min, I closed the tab, will need to try to find it again Mar 23 17:39:48 ok, thank you Mar 23 17:40:43 yates: https://github.com/c-sky/buildroot Mar 23 17:41:50 thanks Mar 23 18:48:56 As long as I use the same machine include file (e.g. cortexa8) and the same distro libc, I can share TMPDIR between multiconfig, correct? Mar 23 18:50:38 vdl: JPEW can perhaps comment from experience, but in theory yes Mar 23 18:50:48 vdl: you can always share the tmpdir, it will rebuilt everything it needs. if its a different architecture it should rebuild everything afaik Mar 23 18:51:34 but i also think shareing State cache is more important? Mar 23 18:52:03 same arch with different libc blew up the last time I tried it, but admittedly that was quite a while ago now Mar 23 18:52:05 GeneralStupid: I thought that you should never share the TMPDIR between different distro? (in fact different libc) and same for difference target hardware? Mar 23 18:53:24 I'm in the boring step of CI, dug into Jenkins and trying to figure what is really safe to share to speed builds up. Beside DL_DIR, I'm not convinced anything is safe to share :/ Mar 23 19:01:05 SSTATE_DIR is sharable Mar 23 19:01:20 TMPDIR can be considered transient in CI, have a fresh one each build Mar 23 19:01:28 just cache and persist DL_DIR and SSTATE_DIR Mar 23 19:02:04 latest bitbake most likely will be fine with shared tmpdir but in a CI environment why bother Mar 23 19:03:16 (the yocto autobuilder shares sstate and downloads via NFS across 20+ workers building all the combinations you could think of. tmpdir is fresh each build) Mar 23 19:12:48 When constructing an eSDK (with PR service enabled) where does the export PR service data end up? Mar 23 19:13:37 I don't see in the cache directory the PR services info, the local.conf doesn't seem to have the PR service enablign stuff either.. Mar 23 19:20:26 rburton: thank you, will share sstate and downloads between builds. Do I need to worry about using the same vs. different tmpdir when using various multiconfig then? Mar 23 19:21:01 i'd use a different tmp for each multiconfig Mar 23 19:24:49 I've yet to be able to share a tmp across multiconfigs, but otherwise it's working well Mar 23 19:28:38 problem is automating the upload of built artefacts, e.g. build/tmp/deploy/. Maybe a simple rule like build/tmp-*/deploy/** would do the job. Mar 23 19:43:53 rburton: do you move SSTATE_DIR and DL_DIR out of TOPDIR? Mar 23 19:57:55 I guess having sstate-cache/, downloads/ and build/ next to each other is simpler since you can remove build (and thus build/tmp*) directly) to start a fresh build. Mar 23 20:48:35 yann: did you mean this? https://github.com/riscv/meta-riscv Mar 23 21:03:07 vdl: they're on another volume entirely in my CI Mar 23 21:03:19 on my build machine they're on a separate disk Mar 23 21:18:04 rburton: would the best be to add a shared/ folder containing sstate-cache, downloads and any cloned layer repositories used by bblayers.conf? Mar 23 21:18:23 that works Mar 23 21:18:40 putting layers in there means you can't use different revisions in different builds Mar 23 21:19:07 unless you pull to the layer and then local clone for the build Mar 23 21:19:09 so we can only place this shared/ directory as a single volume in container using tools such as kas to download and build images Mar 23 21:20:22 when yocto executes the do_populate_sysroot task, is one of the first, fundamental tasks to fetch binutils (probably from https://sourceware.org/git/binutils-gdb.git) and build cross-binutils for the processor architecture involved in the image/recipe? Mar 23 21:20:56 rburton: I see what you mean. Hum the tool must be extended to clone the repositories and then add worktrees for each revisions being used I think. Mar 23 21:21:17 no need for work trees and if you use kas then it has magic to do that already iirc Mar 23 21:21:36 but the cost of downloading meta-oe isn't exactly huge Mar 23 21:22:35 rburton: kas currently clones and checks out the given refspec. So it'll work for building multiple project with different revisions, but only one build at once... Mar 23 21:23:48 rburton: yeah it's just that a project can easily have 5-7 layer repositories so it makes no sense to clone them everytime. Mar 23 21:23:51 I meant https://kas.readthedocs.io/en/2.4/command-line.html#environment-variables KAS_REPO_REF_DIR Mar 23 21:26:35 just have a CI step to update the referenced repos first Mar 23 21:31:33 rburton: they have to be clone manually first, correct? That seems weird. (I'd expect such tool to populate this repo ref dir itself, especially given the required naming convention) Mar 23 21:32:26 yates: I meant the riscv material in poky/meta/conf/machine/: though meta-riscv builts on it with definitions for concrete board you'll find the basic CPU declarations in poky Mar 23 21:32:46 vdl: yes looks like kas expects the directories to already exist Mar 23 21:33:00 which yes is silly given 1) naming requirements and 2) it knows the URLs Mar 23 21:33:06 hey, easy enough to write a plugin Mar 23 21:33:12 shame you can't have external plugins anymore though Mar 23 21:33:30 if you write a plugin, send it to me, as I might use it in our builds :) Mar 23 21:33:56 Let me fill an issue to request this feature Mar 23 21:34:35 CC me please. rossburton on GitHub. Mar 23 21:36:26 yann: ok thanks Mar 23 21:38:17 rburton: sure **** ENDING LOGGING AT Wed Mar 24 02:59:57 2021