**** BEGIN LOGGING AT Thu May 07 02:59:57 2020 May 07 05:59:53 seebs, ping May 07 06:45:40 denix: I have a bug opened for the multiconfig SDK that I havent been able to work on in a while May 07 06:48:16 denix: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5421 May 07 06:48:51 denix: I do not know if my last statement holds True still May 07 07:25:23 I am experimenting bbclass customization creating a very trivial task called do_foo() https://pastebin.com/8pkEvnp7 May 07 07:25:32 The problem is that whenever I modify the task source and I run bitbake I have a lot of recipes rebuilt as result. May 07 07:25:53 I wonder if there is anything to set to avoid that? May 07 07:27:22 for example it was do_package[postfuncs] and now I changed it with do_install[postfuncs] and it is rebuilding 551 recipes :-O May 07 07:29:21 mckoan, have you tried specifying the recipe with -b ? May 07 07:29:32 bitbake -b file.bb May 07 07:30:40 that should ignore dependencies from other recipes according to the manual May 07 07:40:06 kroon: seemed a good idea but no, it gives an error Exception: NameError: name 'staging_package_populate_pkgdata_dir' is not defined May 07 07:40:57 I wonder how are usually tested and debugged the tasks in Yocto/OE, this method is crazy May 07 07:41:17 I mean the tasks provided by classes May 07 07:45:45 mckoan, I get the same error May 07 07:50:58 something broke May 07 07:51:22 hi, I've got a 2nd version of my patch for upgrading LIRC in meta-openembedded/meta-oe submitted more than a week ago. I haven't seen any feedback yet and the patch hasn't made it to master-next. May 07 07:51:57 I see other patches are in the same condition. Guess it is just because overload of too many patches to review, right? May 07 07:55:09 leon-anavi, that's for #oe, anyway there has been some issue with patchwork, there aren't patches between 4/24 and 5/1 May 07 07:55:49 ant__, thanks. I'll join #oe. May 07 08:18:11 I see there is a way to specify the version of a package in RDEPENDS, is it possible for DEPENDS as well? (quickly tried with DEPENDS = "ncurses-native (<= 5)" but didn't seem to work :) ) May 07 08:18:56 the use case is that we have some native prebuilt binaries that requires libncurses.so.5 May 07 08:19:32 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/910 :/ May 07 08:19:43 RP: running a build there now :) May 07 08:19:47 Well... technically this should be handled by PREFERRED_VERSION but it's warranted by this prebuilt binary which might get updated at one point in time (hopefully?) May 07 08:19:52 I hoped to have it sorted before you wake up ;) May 07 08:31:13 kanavin_home: fair enough, perhaps I should go back to bed :) May 07 08:31:30 RP: back to bed++ May 07 09:25:30 any further idea about how to test bbclass customization? May 07 09:44:19 mckoan: you can exclude a task from the variable dependencies May 07 09:45:26 mckoan: e.g. do_package[vardepsexclude] += "do_foo" May 07 09:45:44 it will rebuild the first time you do that but not each time you change thereafter May 07 09:48:54 RP: thanks I knew that only you could know :-D May 07 09:51:18 RP: in the end mesa on debian 9 is too old, so I added a virgl test skip there, patch sent May 07 09:51:46 RP: perfect, it works as needed! Thanks May 07 09:57:41 kanavin_home: ok. That means with that master-next is good to merge? May 07 09:57:43 mckoan, I think you can bitbake -g taskexp the image to check what's happening behind May 07 09:58:28 bitbake -g -u taskexp actually May 07 10:15:53 RP: I think so, yes :) May 07 12:06:05 kanavin_home: we're up to date ish then :) May 07 12:18:31 RP: nearly, I still have the three patches that enable virgl by default, in a separate branch May 07 12:22:32 kanavin_home: right, those were still needing some work May 07 12:25:15 RP: also, there is still in OE-core/poky mater-next a multilib fixup commit which would need some love (commit log, separate commits?). Just to make sure it does not get pushed in that state since it's non trivial. (or maybe it's not part of the next master-next merge :) ) May 07 12:28:23 qschulz: right, I simply don't know what to do with those patches May 07 12:30:31 RP: I understand, I wish I could help on that. May 07 12:42:56 RP: they needed a fix in meta-mingw, which is already there (but only in master-next last I checked) May 07 12:43:03 RP: I'll rebase and resend them May 07 13:36:32 Just saw this: https://youtu.be/ZtS9_SlZZyY May 07 13:36:50 Very awesome. May 07 14:22:42 stephano: indeed. do you need if it's published anywhere on social media already? May 07 14:23:44 ndec, Not sure. Got pulled into meetings before I had a chance to look around. :) May 07 14:31:26 stephano: :):):) May 07 14:32:45 alejandrohs, Ciao Alejandro! :) May 07 14:54:53 I get error "error: 'build/tmp/aarch64-tdx-linux/PACKAGE_A/0.1.0/recipe-sysroot/usr/lib/libboost_filesystem-mt.so', needed by 'PACKAGE_B', missing and no known rule to make it" but that .so is in same directory structure of PACKAGE_B, why is it trying to find it in PACKAGE_A? May 07 14:58:08 are you bitbakeing PACKAGE_A or PACKAGE_B May 07 14:58:24 more specifically, what recipe emits that error May 07 14:58:30 B, and it DEPENDS on A, and both DEPENDS on boost May 07 14:59:33 most likely some broken libtool or pkgconfig file that A writes with full work directory paths in May 07 15:00:20 easily found by searching PACKAGE_B's recip-sysroot for PACKAGE_A May 07 15:04:17 hmm nothing looks unusual there, what should I look for? May 07 15:05:05 if you're in recipe-b's build and it is using paths for recipe-a, then there is either a hardcoding of recipe-a in the recipe itself, or the recipe-b sysroot itself May 07 15:05:18 *or* you're actually in recipe-a's build May 07 15:07:10 both recipes are just short "inherit cmake", can error be in cmakelists then? May 07 15:07:55 possibly May 07 15:46:35 I just got "| AnnotationList.c:(.text+0x7ad): undefined reference to `rpl_fprintf'", it's a fresh checkout of poky dunfell branch without any change. Any idea what I could be doing wrong? I happened to be on ubuntu 16.04 (don't ask why..) May 07 15:46:44 got that in bison-native May 07 15:48:15 hi. i need to run `sed` on a file that exists in ${SYSROOT_DESTDIR} such that those changes appear in the image/ of the recipe i'm making. how could I go about that? May 07 15:50:02 or maybe i have a fundamental misunderstanding of the process here. if I write a recipe `myrecipe` and another `myotherecipe` that `DEPEND`s on `myrecipe`, the include/lib paths would look in the /image folder for `myrecipe` assuming the Makefile for `myotherecipe` is configured properly, right? May 07 15:57:09 RP: I was overly optimistic about enabling virgl by default :( doing that makes qemu initialize opengl even if it's not going to be used, and at that point opengl expects to be able to find dri drivers. I need to think what to do about it (so that this doesn't get in the way or break existing workflows), meanwhile you can drop the patches from -next May 07 15:57:13 buildbeef: why not fix the paths during do_install May 07 15:57:27 ndec: I suspect, the tests for normal fprintf are failing, ubuntu does have some differences in enabling features IIRC, check config.log for why configure is falling back to gnulib versions May 07 15:57:42 buildbeef: you're incorrect re image/ though May 07 15:58:51 kanavin_home: I was about to mention there are a few failures there :/ May 07 15:58:56 rburton I guess a more generalized question would be what path from `recipe1` is considered the canonical include path for anything that depends on `recipe1`? Hopefully that makes sense May 07 16:00:17 RP: yeah, and reverting to previous way of falling through to host GL libraries is not an option, this needs to be fully opt-in for now. May 07 16:03:21 buildbeef: you shouldn't need this information :) yocto handles all of that for you May 07 16:04:32 buildbeef: but FYI, it's STAGING_DIR_TARGET/HOST/NATIVE (most likely target) May 07 16:05:12 yeah, that's typically the case but I can't quite just 'set it and forget it' so to speak for the recipe i'm working on May 07 16:05:29 buildbeef: all should already be set either in CC (there is --sysroot passed IIRC), CFLAGS/LDFLAGS. SO if you cmake/makefile does not hardcode it you should be good :) May 07 16:06:14 it's for wxwidgets which spits out a `wx-config` script that tells application code where to find wx headers, which for some god awful reason is hard-coded to be `usr/include`, always. this is what I need to `sed` May 07 16:07:00 I basically need the include path spit out my wx-config to also have the sysroot path in it May 07 16:07:30 buildbeef: I wouldn't use sed but fix the cmake and send a patch upstream so it's fixed (wxwidgets) May 07 16:09:11 Part of me wants to be really lazy and just slap a `-I` as part of my .bb, but wx-config is also kinda meta in that it tells itself where to find it's own headers. real fun. May 07 16:09:40 there's quite a few upstream wx recipes that all deal with this in their own unique way, and none of them seem to be applicable anymore as they're all written for quite old version of wxWidgets. May 07 16:18:29 kanavin_home: Do you still need the meta-mingw patch? May 07 16:18:45 JPEW: yes please May 07 16:19:16 kanavin_home: I don't think it will break anything, but did it happen to get run on the AB? May 07 16:22:35 JPEW: I don't think it did May 07 16:49:25 khem: it fails in do_compile(). I switch to thud (I need to finish something quick for now) and it worked fine there.. so it looks like something is not well with dunfell. May 07 16:49:31 sakoman: ^ May 07 16:53:07 buildbeef: what version of wxwidgets? May 07 16:53:24 rburton: 3.0.4 May 07 16:54:04 buildbeef: can you not use 3.1.3 instead? http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-extended/wxwidgets?id=7227897d5d4eb1af442508689ceb09935449efbb May 07 16:55:00 buildbeef: had this exact discussion with someone here about 9 months ago, who spent an age battling wxconfig's idiocy May 07 16:55:30 so best thing to do might be to mine the irc log for wxwidgets :) May 07 16:55:54 yeah, i've actually seen those exact logs, and it kinda seems like the guy was having my exact issue with my exact wx version, and didn't seem to find a resolution May 07 16:56:17 i can try a recipe for a newer wx, I don't believe there would be any major breaking API changes between 3.0.4 and 3.1.3. May 07 16:56:30 there's one already out there so that's a good motivation to use 3.1.3 May 07 16:59:24 i will check it out. should note though that my current 3.0.4 recipe builds and I can deploy the sample programs to my target board, I just can't use it to build other recipes. thanks May 07 17:00:57 the trick is blasting any workdir paths in the files it installs to the magic symbols that are used to replace the sysroot with May 07 17:28:57 pffft... is anaconda the only reasonable installer for yocto when building an iso ? **** ENDING LOGGING AT Thu May 07 22:58:43 2020 **** BEGIN LOGGING AT Thu May 07 23:00:15 2020 **** ENDING LOGGING AT Fri May 08 02:59:59 2020