**** BEGIN LOGGING AT Mon Dec 17 03:00:01 2018 Dec 17 07:44:42 Hi, Dec 17 07:44:42 I am getting self deadlock in libGLESv2.so.2 Dec 17 07:44:42 I have created debug build Dec 17 07:44:42 but I am not able to see call stack Dec 17 07:44:42 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Dec 17 07:44:43 CALL STACK : Dec 17 07:44:45 ----------------------------- Dec 17 07:44:47 (gdb) bt Dec 17 07:44:51 #0 0x0000ffffa0a12564 in __lll_lock_wait (futex=futex@entry=0xaaaadde686a0, private=0) at /usr/src/debug/glibc/2.26-r0/git/nptl/lowlevellock.c:46 Dec 17 07:44:54 #1 0x0000ffffa0a0b7f8 in __GI___pthread_mutex_lock (mutex=0xaaaadde686a0) at /usr/src/debug/glibc/2.26-r0/git/nptl/pthread_mutex_lock.c:80 Dec 17 07:44:57 #2 0x0000ffff9f9d2074 in ?? () from /home/user/sdk/usr/lib/libGLESv2.so.2 Dec 17 07:44:59 #3 0x0000000000000001 in ?? () Dec 17 07:45:01 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Dec 17 07:45:03 ------------------------------------------ Dec 17 07:45:05 Can anyone suggest me some resources and tips to get more information about deadlock ? Dec 17 07:47:08 webreformer: we've already seen it in #yocto. First, please put such things into a pastebin. Second, if nobody answers right away, well then... nobody answers. Consider using the mailing list. Tird, corrupted stack are always a PITA. I'd suggest to slim it down to a reproductible minimal use case, and show that. Yet my guess is that you are just recursing endlessly somewhere. Dec 17 08:12:54 good morning Dec 17 16:33:57 I'm having an issue where the final do_rootfs's dnf command fails because "nothing provides av2d-systemd needed by packagegroup-av2-1.0-r0.noarch", even though av2d-systemd exists and `bitbake av2d-systemd` works. The "noarch" part seems interesting, because we're building for aarch64. Any idea what could be going on? Dec 17 16:48:21 mort: and you've verified that there's a *package* called av2d-systemd in the deploy directory? Dec 17 16:56:30 rburton: there's a tmp/deploy/rpm/aarch64/av2d-systemd-dbg-1.0-r0.aarch64.rpm and tmp/deploy/rpm/aarch64/av2d-systemd-dev-1.0-r0.aarch64.rpm, I don't know why there's no version without -dev or -dbg Dec 17 16:57:05 because the package is empty, so it wasn't created Dec 17 16:57:33 so your problem is either a) package should have had something in it, what went wrong or b) why does packagegroup-av2 depend on a package that doesn't exist Dec 17 16:59:23 the do_install script does put a file in image/lib/systemd/system though Dec 17 17:02:52 well, if the recipe also inherits systemd but the systemd distro feature is off, then that will be deleted :) Dec 17 17:08:48 that is indeed the reason; that makes sense, but the error message could've been a bit nicer, haha Dec 17 17:09:21 wel the error message was clear: the package doesn't exit Dec 17 17:09:23 exist Dec 17 17:10:19 it doesn't mention that anything about packages, it just says "av2d-systemd" doesn't exist Dec 17 17:11:37 Hmm, do we have a package qa check to error out if ${D} was empty and its not a packagegrup\ or image, rather than this typical case of producing empty dbg/dev packages and no main package? Dec 17 17:11:59 mort: sure, the name could have been RPROVIDED by another package too Dec 17 17:12:22 mort: all the package manager can say is that it was asked to install 'foo' and it can't find anything that is called foo Dec 17 17:12:48 kergoth: that would have quite a lot of false positives i'd say Dec 17 17:13:00 rburton: yeah, it makes sense that dnf prints the message it does Dec 17 17:13:48 but it could at least have been a warning which notifies you that bitbake deleted the package because it was empty Dec 17 17:13:54 mort: oh god so many Dec 17 17:14:10 are there that many empty packages? Dec 17 17:14:30 empty-and-not-present, yes Dec 17 17:14:52 every PN-doc package for packages with documentation for a start Dec 17 17:15:09 i'd love to see PN-dev disappear but for tedious reasons we need that to be empty right now Dec 17 17:15:19 alright Dec 17 17:15:23 PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}" Dec 17 17:15:23 ^ does every recipe have every one of those? Dec 17 17:16:11 there's a small case to be made for a sanity warning if PN disappeared, after all its bad form Dec 17 17:17:32 if there was some bitbake-specific tool instead of dnf used, then it could've output a nicer error message, and maybe said something like "note: the av2d-systemd package exists, but is empty" - but that's the classic issue of clean separation of layers vs practical concerns isn't it Dec 17 17:18:01 it doesn't exist though Dec 17 17:18:12 if it was empty then that would be different Dec 17 17:19:10 the recipe which should've provided the package exists, and the package's image directory exists and is non-empty Dec 17 17:19:49 all of which is most likely gone when image creation happens Dec 17 17:20:05 i have rm_work, so the image directory is gone Dec 17 17:20:17 just written a hack to see how many packages don't ship a PN Dec 17 17:21:12 probably quite a few that add a ton of individual packages to PACKAGES and then don't ship the main one anymore Dec 17 17:21:17 I'm not saying anything should be done, I'm just saying it would've been possible to provide a nice error message, because all the necessary information existed at one point in time Dec 17 17:21:20 even if it is bad form Dec 17 17:21:51 I think it makes complete sense to leave it as it is, using existing packaging infrastructure has its own advantages Dec 17 17:22:25 kergoth: i do dislike packages which split into tens of packages and then remove PN, always get newbies saying 'i can't install mysql' or similar because its mysql-client mysql-server etc and no mysql meta-package Dec 17 17:22:45 yeah exactly. always better to at the very least keep the pn one and make it depend on the rest Dec 17 17:22:58 yes Dec 17 17:24:18 kergoth: silly gstreamer packages have an empty PN but then have a gst-meta package Dec 17 17:43:21 ok written a quick hack for PN==pkg && no contents && allow-empty==0 Dec 17 17:52:14 header-only libraries triggering it so far Dec 17 21:31:15 hmm... Dec 17 21:32:24 can anybody confirm the VideoCore IV (vc4) on the RPi is the same IP as on bcm7425 (mipsel STB)? Dec 17 21:33:23 is there any non-proprietary framebuffer or only bcm closed sources? Dec 17 21:34:32 bmips seems being mainlined, what is missing? userspace gl*? Dec 17 22:54:33 I read around "broadcom/vc4: Drop libdrm_vc4 requirement" Dec 17 22:54:50 ah, JaMa has gone Dec 18 00:53:36 yes I think framebuffer is customized Dec 18 00:53:54 vc4 is primarily arm thing Dec 18 00:54:06 interesting if it will work with other socs **** ENDING LOGGING AT Tue Dec 18 03:00:00 2018