**** BEGIN LOGGING AT Fri Mar 15 02:59:57 2019 Mar 15 03:40:43 hello, i'm using devtool modify for trying to work with existing code. but it cannot find the recipe. also if is in the source code Mar 15 03:42:17 the layer have to be added with bitbake layer-add for find the recipe ? Mar 15 03:43:23 I'm by the way reading the user manual but there is almost no explanation on where the recipe have to reside Mar 15 03:45:03 devtool modify $workspace/recipes/sl.bb $workspace/sources/sl/ Mar 15 03:45:14 but it cannot find the recipe Mar 15 03:49:23 it has to reside the same place it would for bitbake to build it. Mar 15 03:49:33 add the layer to bblayers in conf/bblayers.conf as the documentation describes for adding a layer to the build Mar 15 03:50:04 devtool extracts the source and adds a bbappend to adjust the configuration of the recipe to build from those sources. the recipe still has to be available to bitbake as a build Mar 15 03:51:17 kergoth: what if i have many layers to modify? there is no why of automating it ? Mar 15 03:51:25 what do you mean? Mar 15 03:51:44 again, devtool modifies how a recipe builds. bitbake has to be able to build the recipe for devtool to be of any use whatsoever Mar 15 03:51:49 add the layers you need to bblayers Mar 15 03:53:06 kergoth: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11677 add layer management functionality Mar 15 03:53:07 Bug 11677: enhancement, Medium, 2.99, paul.eggleton, NEW , eSDK: add layer management functionality Mar 15 03:53:25 this probably would be useful for my case. Mar 15 03:53:48 first, you said nothing about the esdk Mar 15 03:54:17 kergoth: sorry, i thought devtool was only for esdk Mar 15 03:54:37 i use it every day and never touch esdk. it's a generally useful tool Mar 15 03:54:53 but that issue does sound up your alley, indeed Mar 15 03:55:27 kergoth: thanks you Mar 15 03:56:46 kergoth: using bblayers.conf is a good idea indeed. I could just use the bblayers.conf in the poky-sdk Mar 15 03:57:01 and than modify it using devtool modify Mar 15 03:57:15 bitbake-layers add-layer is really just a convenience around manually changing bblayers, so it should be a viable workaround for now at least Mar 15 03:57:52 how bitbake-layers choose the bblayers file ? Mar 15 03:58:24 i think i have one under poky/ and one under poky-sdk/ Mar 15 03:58:40 probably when i source the poky-sdk enviroment is using that Mar 15 03:58:52 I will do some try with it Mar 15 04:27:46 Is there a way to list tasks dependencies? Like which task preceed or succeed which? Mar 15 08:40:43 New news from stackoverflow: psplash image does not appear (yocto & qemu) Mar 15 08:44:29 Hello, which recipe contains the command line tool "top"? https://layers.openembedded.org/layerindex/branch/sumo/recipes/?q=top does not give a good hint. Mar 15 08:44:58 I don't want the busybox version Mar 15 08:45:32 but the full-featured version of top Mar 15 08:50:28 fbre: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/procps/procps_3.3.15.bb Mar 15 08:51:34 fbre: tip, htop is a package on its own. Mar 15 08:51:56 (and even more bang for the buck, methinks) Mar 15 10:07:44 Hi, I have a question about creating mirrors in Yocto. Mar 15 10:07:46 I set BB_GENERATE_MIRROR_TARBALLS = "1" in local.conf, and git2_*.tar.gz files Mar 15 10:07:46 are created in the download directory. What bothering me is that this tarballs Mar 15 10:07:46 are not versioned. What happen if I bump a recipe version? How Bitbake would Mar 15 10:07:49 recognize that it needs to re-download the Git repository? Mar 15 10:08:21 LetoThe2nd: cool, thanx! I added "procps" to my CORE_IMAGE_EXTRA_INSTALL_append variable Mar 15 10:09:54 lexa_: i believe it downloads if the sha is after isn't in the local copy Mar 15 10:11:30 rburton: And then it will create a new tarball? Mar 15 10:11:42 Is there anyone here who has experience compiling and running Qt apps under qemux86? Foremost to get it to compile, but I'd like to avoid having to run X. Mar 15 10:11:58 lexa_: yes Mar 15 10:13:14 rburton: Thank you for explanation. Mar 15 10:16:19 sveinse: if you just use qtcore, you won't need X Mar 15 10:19:04 fbre: apparently I need to configure Qt to ignore opengl tests, because it failed in my build. Its not enough to remove X11 from distro features Mar 15 10:21:14 sveinse: there is a Qt configure option called "-opengl". Have you tried to remove that? Mar 15 10:25:50 btw, how can I remove a PACKAGECONFIG entry without having to repeat the whole default? Mar 15 10:38:22 sveinse: _remove Mar 15 10:53:35 Just checked PACKAGECONFIG. it parses DISTRO_FEATUREs, and I haven't enabled x11, directfb nor gl. Verified that these PACKAGESCONFIGs are not set, yet the build fails. More digging needed apparently. Mar 15 10:54:57 the distro feature is opengl, you checked that right Mar 15 10:55:44 yeah, I did. Checked both my DISTRO_FEATURES and PACKAGECONFIG for this recipe Mar 15 10:56:00 sounds like the qt recipe is as usual a bit of a monster Mar 15 10:57:00 To be honest, I dislike that Qt is both an application framework as well as a GUI kit. But that is ranting for another time Mar 15 10:57:32 I just can speak for the qt configure stuff of a non-yocto environment. It's the -opengl option there Mar 15 10:58:13 First, it was a GUI kit. They separated the app framework to qtcore in qt4 Mar 15 10:59:04 fbre: I just checked the configure options, and there is no -opengl in it Mar 15 11:02:38 sveinse: Grep for "./configure -debug-and-release -opensource -platform linux-g++ -opengl desktop" for instance on webpage https://stackoverflow.com/questions/14932315/how-to-compile-qt-5-under-windows-or-linux-32-or-64-bit-static-or-dynamic-on-v Mar 15 11:03:14 I think yocto-linux route those options just trough Mar 15 11:05:30 sveinse: if I remember corretly, there's always an opposite option "-no-blabla" in Qt's configure concept Mar 15 11:06:08 The configure is quite extensive: https://bpaste.net/show/dd4716b58cf0 Mar 15 11:07:47 sveinse: Uhm... I cannot see a -opengl option. But maybe that is default. So try to add -no-opengl as the generic switch-off option. But I cannot promise if that will work. Mar 15 11:13:43 fbre: yup, thanks. That took it past configure at least. Bug in the recipe. Mar 15 11:14:13 cool. You're welcome :) Mar 15 11:14:29 Does this imply that noone is really using Qt with qemu? Or is X the main way everyone is going for such a setup? Mar 15 11:15:31 I suppose Qt users usually want to see some widgets. Although I especially like Qt's cool framework and also use it for programming command line tools (without GUI) Mar 15 11:21:24 sveinse: what do you *actually* want to do. Mar 15 11:21:39 sveinse: you have a graphical app using qt that you want to run in a qemu? Mar 15 11:22:23 fbre: we do the latter too, so my inital goal was to compile qt witout any GUI. Mar 15 11:24:07 However I do have another GUI app that would be awfully nice to be able to run within qemu. On our HW we run open gl via directfb (I think), not X. I'm uncertain what would be the simplest approach for qemu for this. I'd like to avoid having to do a major X setup just for displaying a singular fullscreen app. Mar 15 11:24:21 i doubt you run opengl via directgb Mar 15 11:24:37 you might run EGL on framebuffer Mar 15 11:24:38 then its eglfs Mar 15 11:25:04 I admit being a little out of my league here Mar 15 11:25:39 https://doc.qt.io/qt-5/embedded-linux.html#linuxfb <-- qt' eglfs in software Mar 15 11:25:55 should work in qemu Mar 15 11:27:23 rburton: cool, non accel is more than fine. I need to figure out what PACKAGE_CONFIG corresponds to that. Mar 15 11:27:33 this is not directfb, right? Mar 15 11:27:57 no, that's directly to the framebuffer devices Mar 15 11:28:24 sveinse: I'm afraid I can't help with getting opengl work for your special case. I just have used it on Windows for the past years Mar 15 11:28:46 fbre: no worries. thanks for the assist! Mar 15 11:30:00 I'll attept to enable eglfs and see what happens Mar 15 11:42:58 No, the option was -linuxfb and compilation is under way. Excited to see if this works. Thanks rburton Mar 15 12:10:16 sveinse: and if one configures -opengl -linuxfb, he can have Qt rendering 3D stuff into memory buffers, if I get it right? Mar 15 13:04:43 Hi, I was here asking about sato help and got some very nice tips https://pastebin.com/LuhHkixw , however I'm having a hard time finding any documentation that describes how to do this. Are there any usefull guides i might have missed for this? Mar 15 13:12:54 fbre: not sure. I'll try. I do suspect that it needs some libs from the system, but its worth a try. Mar 15 13:27:27 So I've got an image recipe "B" where I copy the output image from recipe "A" into the rootfs of image "B". I've got the copying working, but when I make a change that causes a difference in "A", "B" does not get rebuilt. Mar 15 13:27:55 I'm building "B" in a multiconfig/, and "A" in my "main config" (conf/local.conf). Mar 15 13:28:12 How do I declare that do_rootfs of B depends on do_image_wic of A? Mar 15 13:42:23 Another question: By "bitbake virtual/kernel -c menuconfig", I switched off many things I think I don't need. Is there a thing like telling the kernel configuration to verify the dependencies and to switch on everything I unchecked too much? Mar 15 13:43:21 Currently, I have compile errors because I unchecked an option I rather should keep checked Mar 15 13:43:40 but I don't know which one Mar 15 13:44:15 you can save the config in the kernel config list Mar 15 13:45:41 I still have the old .config file and can compare them side-by-side. But I cannot get the link which change is responsible for the compile error Mar 15 13:46:34 So I thought maybe there is an automatically-solve-the-dependencies thingy Mar 15 13:46:39 and load it using Mar 15 13:46:40 use-kernel-config=exampl_defconfig saved as a afile that is loaded SRC_URI =+file://defconfig Mar 15 13:48:11 I don't get it what you mean, MarcWe Mar 15 13:50:04 fbre: ignore the last thing I described Mar 15 13:50:53 fbre: Best thing that i know is diffing the config files Mar 15 13:51:01 fbre: I think you're on your own with this one. There's nothing automatic to check kernel configs at that level of detail Mar 15 13:51:24 fbre: If you have 1 working and 1 not working Mar 15 13:51:58 The Kconfig files in the kernel source tree do express dependencies but there's always things missing. Too many possible permutations to test everything Mar 15 13:59:53 When I look into of a menuconfig item, it tells me the dependencies to other options. So I thought there is an automatic dependency resolver Mar 15 14:00:29 There is, but the dependencies listed are always incomplete Mar 15 14:01:04 paulbarker: so netns is definitely a unicorn Mar 15 14:01:31 one of the rare recipes that work in a 'cross' environment but fail when the build and target arch are the same Mar 15 14:01:44 marka: I think some of the difficulty is caused by the use of cgo Mar 15 14:01:57 is there a reason you were building static? Mar 15 14:02:16 just curious, I still want to solve this for static build as it should be possible Mar 15 14:02:50 paulbarker: it most certainly is the cgo aspect, along with -static Mar 15 14:03:43 after sleeping on it I have a few ideas I need to poke at this morning Mar 15 14:04:05 first I had to respond to some comments on my other two outstanding RRs Mar 15 14:04:07 marka: Just looking at the git history Mar 15 14:04:26 I copied do_compile from the original runc recipe which also did `oe_runmake static` Mar 15 14:05:08 OK, again I was just curious Mar 15 14:05:45 back in a bit after I try some things out Mar 15 14:06:01 does yocto define dependencies (as mentioned in an ipk's CONTROL file) by detecting the libraries a binary is linked against + having a map which package provides it? Mar 15 14:08:27 Piraty: you would usually need to include these as a DEPENDS in your recipe, and if it is dynamically linked these will essentially become RDEPENDS Mar 15 14:08:50 marka: I have no idea is static is actually needed. Definitely something to look into! Mar 15 14:08:53 in which case the dependency is carried into the package Mar 15 14:09:59 Piraty: I am not an expert on this topic, so you can most likely do a quick test to validate this Mar 15 14:10:19 paulbarker: I still want to get this working as it is a valid thing to do Mar 15 14:10:24 marka: i'm not using yocto yet, just elaborating options and asking things to get a better view Mar 15 14:11:58 Piraty: in my experience the above is correct, for libraries Mar 15 14:12:58 marka: do you mean only packages i add manually to the recipe will end up in the packages's metadata ("depends" field in ipk's CONTROL for example) ? what would be sad Mar 15 14:14:55 if for example you needed to link against libssh, you would need to include it in your recipes DEPENDS Mar 15 14:15:20 this would ensure libssh-dev was installed in the recipe specific sysroot to assist building Mar 15 14:15:37 and would ensure libssh was noted as a dependency in the final packaging Mar 15 14:15:56 but yes, you are required to make the addition in the recipe to DEPENDS Mar 15 14:19:02 Piraty: https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html#automatically-added-runtime-dependencies Mar 15 14:19:33 ah! Mar 15 14:19:39 marka should read it too ;) Mar 15 14:19:49 i took RDEPENDS for revdepends somehow... Mar 15 14:19:55 but it's rundepends Mar 15 14:20:01 It's rarely an issue in practice unless you use dlopen() Mar 15 14:20:22 If you link directly against a library you'll need it in DEPENDS anyway so it's present at build time Mar 15 14:21:24 RDEPENDS is usually the place for commands you run, libs you dlopen(), packages which provide configuration, etc as it's not possible to detect that stuff automatically Mar 15 14:22:06 thanks paulbarker. one more thing about it: is the mapping of "shlib to package" static? as in https://github.com/void-linux/void-packages/blob/master/common/shlibs Mar 15 14:22:06 or is it built during compilation, depending on what i selected to be build, specifically for that buildjob? Mar 15 14:22:24 if your installed package includes scripts with #!/bin/something, the build system will warn you about missing 'something' Mar 15 14:23:11 ok. sounds sane Mar 15 14:23:18 Piraty: It's in the docs... "During the do_package task of each recipe, all shared libraries installed by the recipe are located. For each shared library, the package that contains the shared library is registered as providing the shared library." Mar 15 14:23:38 Piraty: no need to read, what I posted was essentially the distilled version Mar 15 14:24:26 you still need the direct dependency listed in DEPENDS, the rest is automatic as I mentioned Mar 15 14:25:49 "no need to read", I don't remember having ever seen anyone discourage someone from reading documentation before... :p Mar 15 14:26:10 reading is overrated Mar 15 14:26:25 I tell my kids this all the time Mar 15 14:28:36 marka: https://www.youtube.com/watch?v=BwkdGr9JYmE Mar 15 14:29:01 classic Mar 15 14:32:21 :D Mar 15 14:32:23 jofr: thanks, I needed that Mar 15 15:12:40 If I want to append the do_install() of a recipe in a .bbappend file and the original do_install() is a shell function but I want my appended functionality to be written in Python, what's the best way to do that? Mar 15 15:31:32 jtrimbl3: I think you that one of the case that is problematic (or at least I couldn't solve it) you probably need to patch the former one and replace the whole thing with yours Mar 15 15:32:04 or write your's in shell ahah Mar 15 15:32:12 *yours Mar 15 15:32:41 jrtimbl3: You'll need to define a new task for that Mar 15 15:33:20 jtrimble ^^^^. I can't spell Mar 15 15:34:06 paulbarker: but how would you do that then ? You'll call the new task from the former do_install ? Mar 15 15:34:49 https://stackoverflow.com/questions/43386270/how-can-i-add-a-task-after-do-deploy Mar 15 15:35:30 Ok, that makes sens :) thanks Mar 15 15:36:36 When I did it I just patch the first one, even though I knew that it was the wrong way to do it x) Mar 15 15:45:24 I am pretty sure there are examples in existing recipes where there is a chain approach, have the shell function reference a python function Mar 15 15:45:42 don't hold me to it though, its been a while since I looked Mar 15 15:46:05 jtrimbl3: use a postfunc Mar 15 15:46:16 a new task works, but is overkill Mar 15 15:46:27 +1 Mar 15 15:46:28 do_install[postfuncs] += "my_do_install"; python my_do_install () { : } Mar 15 15:50:22 I always forget that postfuncs exist Mar 15 16:03:27 I'm personally not a big fan of recipes adding new tasks, as i'd prefer if recipes were more declarative, less changing how bitbake does its job and more just filling in the metadata for existing tasks and hooks where provided Mar 15 16:05:56 plus you avoid having work split across scripts, logs.... Mar 15 16:07:09 I tend to cheat while debugging a recipe's build. Edit the run.do_compile, and comment out set e, and do_compile, exit..., then source run.do_compile. Quick and easy devshell. Mar 15 16:42:21 New news from stackoverflow: Enable systemd services using yocto Mar 15 17:42:31 New news from stackoverflow: Yocto recipe problem with scons and ws281x on Raspberry Pi 3B+ Mar 15 17:48:54 fbre: You're probably not here any longer, but using -linuxfb and -opengl does not work. "ERROR: Feature 'opengl' was enabled, but the pre-condition 'features.opengl-desktop || features.opengl-dynamic || features.opengles2' failed." So apparently -opengl isn't intended to be used with -linuxfb Mar 15 17:49:21 ^ context is configuring Qt Mar 15 17:58:45 sveinse:yes it is not, for opengl you need driver to implement some form of gl Mar 15 18:03:58 armpit, RP, rburton AB is coming back up and is ready for new work. Mar 15 18:04:16 k, thanks Mar 15 18:11:30 khem: yeah, apparently. We were curious if Qt implemented a opengl renderer for linuxfb, and thus -opengl -linuxfb Mar 15 18:55:35 paulbarker: so I believe I have solved some of the mystery with the netns GO build Mar 15 18:55:44 definitely not 100% yet though Mar 15 18:56:04 it is related to https://plus.google.com/117192131596509381660/posts/eNnNePihYnK Mar 15 18:56:15 and https://github.com/golang/go/issues/9369 Mar 15 18:56:49 when reading these, however, this should be an issue any longer Mar 15 18:57:08 but obviously it is, most likely since we are also mixing in cross compiling Mar 15 18:57:31 at any rate I can workaround the issue by adding a -pkgdir to the go build cmd Mar 15 18:57:58 as described in those links it is related to the build being performed differently than when the go std pkgs were built Mar 15 18:58:59 and like those discussions our situation was mapping to that, as with more verbose building I could see it seeking out runtime/cgo when it should never have been Mar 15 19:15:02 khem: did you want me to expand my GOARM patch to cover more of the exports? or can I go ahead and resend what I have and work on the remainder in future work? Mar 15 19:23:15 * armpit GOARM sound like a sports team chant Mar 15 19:31:57 I have had enough long days after sorting out GO quirks that I might have dreamed about something similar at some point Mar 15 20:11:03 armpit: unfortunately a very un-metal chant. Mar 15 21:40:43 marka: yes finish it once for all Mar 15 21:41:27 armpit: goarm but there might be risk ;) Mar 15 21:49:05 khem, maybe, you got intel on that situation? Mar 15 21:49:29 * armpit maybe more power? Mar 15 21:52:15 * armpit SoC puns.. I am so sad Mar 15 22:07:55 armpit: yeah **** ENDING LOGGING AT Sat Mar 16 02:59:57 2019