**** BEGIN LOGGING AT Thu Nov 20 02:59:58 2014 Nov 20 07:31:55 Hello, Im wondering what's the current status of x11 support on freescale layer, is there a support for acceleration with vivante GPU ? Nov 20 09:17:02 Morning all. Has anyone ever done much full build profiling? In my (full) build I have quite a few periods where the CPU's aren't hit hard so I assume I must be pretty much IO bound but not sure exactly what so can't see yet what to look at to improve performance. I don't think I have a CPU problem as I just upgraded but the build time didn't improve in a proportional manner. Nov 20 09:48:56 Also - wondering about improving performance, I've seen the docs about bringing an external toolchain in to yocto, but how can one generate an appropriate toolchain tarball *from* yocto that you can import again. i.e. Improve performance by making the repeated toolchain build a pre-built external element? Nov 20 09:52:32 hi, where am i supposed to find my build artifacts? i cannot find them? Nov 20 09:52:52 cp: cannot stat ‘/lu/buildbot/yocto-autobuilder/yocto-worker/nightly-a10-openjdk/build/build/tmp/deploy/images/a10/*a10*’: No such file or directory Nov 20 09:53:14 this is the output in the last step "Publishing Artifacts" from my buildbot :( Nov 20 09:59:54 morning all Nov 20 10:01:55 pev_: that's not really supported; if your aim is simply to improve build times we have shared state to solve that which handles more than just the toolchain Nov 20 10:02:14 bluelightning: Morning! Nov 20 10:02:39 bluelightning: Yeah, I've been using sstate but quite often my build gets into inconsistent states for no apparent reason and a 100% clean build is the only solution Nov 20 10:02:51 so I dont wholly trust it... Nov 20 10:03:14 so that's something we should try to fix... what do you mean by "inconsistent states" ? Nov 20 10:03:16 Although ccache would be another solution... Nov 20 10:03:58 bluelightning: Well, something goes horribly broken in the image or build process which I can't explain in the changes I've been making, so I do a full clean build and it goes away Nov 20 10:04:20 It's never solidly reproducable so not an easy one to try and explain Nov 20 10:04:29 and it's always something oblique... Nov 20 10:04:52 I can't stress enough how we really need people to report this kind of problem Nov 20 10:05:05 if we don't get the reports there is no hope of us fixing any underlying issue... Nov 20 10:05:41 bluelightning: Yeah, I know, I would report if I had anything even remotely useful to work with in regards to process to reproduce Nov 20 10:05:46 (unless we detect it during our reasonably comprehensive testing, of course, but that can't cover every situation) Nov 20 10:05:55 (I like reporting / fixing bugs) Nov 20 10:07:05 ok, thanks Nov 20 10:16:19 Hi, It is possible to build qt5 with directfb for an imx6 based board without of the opengl things like eglfs egl etc? yocto1.6.1 here. Nov 20 10:22:19 bluelightning: Still, it would be nice to have a way to avoid building the full toolchain every time I do a sanity-check...! Currently my process is that I clean all the sstate then bitbake gcc-cross on its own in a clean source tree. I then archive the sstate-cache for this and then when things go wrong I can transplant that sstate-cache back in and the full rebuild is way faster Nov 20 10:22:38 and that seems to work well but it's a bit clunky as a mechanism :-) Nov 20 10:23:57 personally I'd love it if there was a philosophical split between host and target recipes and there was a way to just clean out target code (+sstate) only which I think would help in the same way Nov 20 10:25:17 silviof: I assume you've tried just taking opengl out of DISTRO_FEATURES right? Nov 20 10:25:36 silviof: or are you asking if opengl is a dependency of directfb itself? Nov 20 10:33:43 pev_: I'm check if it is possible. So you say - yes you can use qt5 with a directfb layer on imx6 without opengl? Nov 20 10:33:58 pev_: I will try this then. Nov 20 10:34:23 pev_: I have to add directfb to DISTRO_FEATURES? Nov 20 10:55:33 hi guys Nov 20 10:56:27 I have an interesting problem. Existing recipe has a dead link in 'SRC_URI'. Now I would like to fix it locally, do I just append another link to SRC_URI variable? Nov 20 10:56:59 silviof: directfb is basically framebuffer access so opengl is not necessary Nov 20 10:57:06 It will look weird, since SRC_URI will look like 'address.com/file patch1 patch2 diffaddress.com/file' Nov 20 10:57:28 I'm not sure SRC_URI is supposed to choke two different addresses for the same file Nov 20 11:00:44 Xz: You can just use SRC_URI= and it will replace the old version? Nov 20 11:01:06 pev_: but then it will get rid o patches Nov 20 11:01:29 Xz: Well you can include their names in your bbappend also? Nov 20 11:01:57 pev_: well, i can, but I thought that is not the cleanest solution in the world Nov 20 11:02:09 pev_: is it the only? Nov 20 11:02:15 i.e. the .bb has SRC_URI="wronglink patch1 patch2". In your bbapend you can do SRC_URI="rightlink patch1 patch2" Nov 20 11:02:43 Xz: Sure, but the "clean" way is to fix the original recipe with a non-dead link surely? Anything else is a bodge? Nov 20 11:03:20 pev_: it's just the fact, that bbappend will refer to patches from other layer - that creates a dependency Nov 20 11:03:35 whereas whole Yocto layering system was created in a way to avoid dependencies Nov 20 11:04:23 Original link can be indeed replaced, but the project is based on older Yocto version Nov 20 11:04:26 not bleeding edge Nov 20 11:06:39 pev_: thx Nov 20 11:06:41 Xz: Of course, but in the same way with any other bug you'd still need to fix locally even if you can't submit back? Nov 20 11:07:24 Xz: What's the recipe with the dead link? Nov 20 11:07:34 it's a 'dtc' Nov 20 11:07:48 I didn't even check yet whether it was fixed on master Nov 20 11:09:01 I presume it was, otherwise autobuilder would fail Nov 20 11:09:29 Well, you could manully download the target into your local dldir and it won't try to fetch from the dead link? Nov 20 11:10:16 pev_: but you see, we have a small IOT project and we give people whole layer to play with Nov 20 11:10:22 I'd still fix the recipe locally instead of bodging though :-D Would you try and fix any other kind of bug by adapting your own layer instead of fixing the layer where the bug is? Nov 20 11:10:24 which is based right now on 1.4 Nov 20 11:11:02 ok, so fixing recipe and asking for backport to 1.4 would be the winner here, I guess? Nov 20 11:11:37 Xz: IMHO I'd have thought the correct solution then is to duplicate the whole recipe in your layer but uprev the minor local version. Then it's a whole new correct copy but it's also clear what version it is derived from Nov 20 11:11:58 Yes, or copying wholesale with minor version uprev Nov 20 11:12:13 Fixing bugs is always a winner ;-) Nov 20 11:13:34 pev_: You are right, it's just I didn't think for a while, that we can do backports to 1.4 as well Nov 20 11:15:16 Xz: Well, the dylan branch in GIT is still being committed to so you'd have to point customers at downloading from the git branch rather than a nice versioned tarball Nov 20 11:15:28 https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dylan Nov 20 11:15:35 Xz: use MIRRORS for this kind of thing Nov 20 11:15:59 bluelightning: I was reading MIRRORS description, but that looked like overkill for a moment Nov 20 11:16:04 bluelightning: But you'd still need to change the original recipe to add the mirrors right? Nov 20 11:16:20 as its not one of the standard software sources? Nov 20 11:17:06 pev_: MIRRORS is just a regex match; but even if you prefer to make it specific to the recipe you could do MIRRORS_append_pn-xyz = "..." Nov 20 11:17:32 Xz: MIRRORS is designed exactly for the situation where an upstream source goes missing Nov 20 11:17:59 bluelightning: Ah, that's nice - id not spotted that in the documentation, that's a good solution. Nov 20 11:18:02 Xz: which recipe is this btw? Nov 20 11:18:07 bluelightning: yeah, but I thought it was more like a regular mirror with 1000+ files, not just one :) Nov 20 11:18:22 Xz: it can be any kind of alternative source of files Nov 20 11:18:35 bluelightning: that's very cool then Nov 20 11:18:53 bluelightning: so looking at the order and knowing that its broken, in this case would not PREMIRROR be appropriate? Nov 20 11:19:09 as we know the upstream source is dead Nov 20 11:21:03 pev_: you could use PREMIRRORS yes, although PREMIRRORS is more intended for local source mirrors Nov 20 11:46:29 hi, i'm building core-image-weston with qt5. In my sysroot there is /usr/lib/qt5/plugins/platforms/libqwayland-egl.so but in the image it does not exist. Has anybody an idea what the problem could be or what file/process decides what the image contains? Nov 20 11:51:44 jheiber: .so files usually land in an 'xxx-dev' package rather than the main 'xxx' package Nov 20 11:52:11 to clarify, unversioned .so symlinks, yes Nov 20 11:52:24 typically library dependencies are brought in automatically, where they have a dynamic link established at compile time Nov 20 11:53:00 I'm not familiar with libqwayland-egl.so; if that's a symlink then it would not be expected to be on the target unless the dev package is installed Nov 20 11:53:50 on the other hand if it isn't, then it suggests to me perhaps that it's a plugin and thus there's almost certainly dlopened at runtime in which case the build system has no means of implicitly adding a dependency on it Nov 20 11:54:33 which would mean you'd need to explicitly include the package that contains it in your image (or in the RDEPENDS of a package / packagegroup that is in the image) Nov 20 11:55:38 bluelightning: it is not a symlink. QT apps find these .so files and a command line parameter decides which will be used Nov 20 11:56:25 bluelightning: and i dont understand why those files are in sysroot, but only some of them in the image and not all Nov 20 11:56:53 jhieber: it's because of the difference between build-time (i.e. recipe level) and runtime (i.e. package level) dependencies Nov 20 11:57:13 they aren't exactly equal Nov 20 11:57:31 bluelightning: ok so there are deps missing somewhere Nov 20 11:58:47 I'm not entirely sure where the correct place would be to add such a dependency though Nov 20 11:59:01 other than the image, that is Nov 20 12:00:00 since it should only be brought in if you are installing a Qt application and you are using Wayland Nov 20 12:00:30 i greped all files in my tmp folder for "qwayland-egl", maybe there is something that helps Nov 20 12:03:36 the first question would be which package does that end up going into? you can tell by looking at packages-split under the workdir for the recipe which builds the file Nov 20 12:05:08 bluelightning: thanks, good idea, i just found a few packages like this: qtwayland-plugins-5.3.....rpm, when i check the packages for that .so file i know what to include in IMAGE_INSTALL Nov 20 12:13:36 bluelightning: yeah, thanks for your help, by searching though the rpm files i found "qtwayland-plugins" Nov 20 12:15:42 jhieber: no worries Nov 20 12:30:57 if I am modifying kernel using menuconfig virtual/kernel and bitbake -c -clean image-type + bitbake image-type, Will modification take effect or I should do smth extra? Nov 20 12:54:03 Can someone tell me where to look for the documentation of SRCREV_FORMAT? How does it work? Nov 20 13:06:38 hi all Nov 20 13:10:37 frsc: have you already read its entry in http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html ? Nov 20 13:14:19 JaMa, thanks! I was looking in the wrong version of the manual. Nov 20 13:43:42 <_valle_> After changing to dizzy, PACKAGECONFIG_append_pn-qtmultimedia = " gstreamer010" breaks the build Nov 20 13:44:55 <_valle_> Removing the patches in qtmultimedia.inc makes the build work again Nov 20 13:45:38 <_valle_> However when running a Qt application and a sound should be played I get the following output: using null output device, none available Nov 20 13:46:09 _valle_: http://patches.openembedded.org/patch/79531/ Nov 20 14:32:26 <_valle_> JaMa: Thanks for the help, but the patch didn't solve the build problem Nov 20 14:47:11 then the patch was even less tested then it looked :) Nov 20 16:42:59 how to force to take bitbake into consideration changes in menuconfig virtual/kernel when rebuilding, not 1st build? Nov 20 16:47:40 I was wondering how can I increase udhcpc wait time for DHCP answer. Right now it try 3 time on boot and sometimes it is enough sometimes fails. Nov 20 17:12:07 Still got a bit confused about native. I am building yocto for beaglebone black am335x and lets say I want to append package - A. I look through packages, there is A, A-native. Which one to take? Nov 20 17:50:35 native is built for the build machine you're running on, not the board Nov 20 17:50:52 to build tools which are used to build other things Nov 20 20:43:33 paulbarker: good news: your new opkg patches didn't break on the AB Nov 20 20:43:45 paulbarker: the ab still broke, but it broke differently in ways that i don't think are your fault ;) Nov 20 21:57:49 Anyone seen glibc-locale do_package fail to compile a specific locale, but be fine for the others, and the log shows absolutely nothing useful? Nov 20 23:31:54 quick question... can someone enlighten me where task-core-boot has gone? Nov 20 23:37:47 ajtag: renamed to packagegroup Nov 20 23:38:30 packagegroup-core-boot.bb? Nov 20 23:38:52 genius, thanks I have just spent an hr looking for that **** ENDING LOGGING AT Fri Nov 21 02:59:58 2014