**** BEGIN LOGGING AT Wed Mar 20 02:59:57 2019 Mar 20 04:19:03 New news from stackoverflow: Bitbake cannot find the header file of another recipe || In Yocto, how to include header files from another recipes Mar 20 07:47:58 kanavin: are all your qemu patches merged now? or should I use some patchset too if I want to play around with it? Mar 20 08:05:33 how i can force IMAGE_INSTALL_remove Mar 20 08:19:48 New news from stackoverflow: How to add a static library to Yocto SDK package Mar 20 08:22:21 alicef: hi, what do you mean? Mar 20 08:23:50 using IMAGE_INSTALL_remove for removing a recipe dosen't work and the recipe is still there Mar 20 08:24:02 I suppose maybe because of dependency ? Mar 20 08:24:26 and i found this mail https://lists.yoctoproject.org/pipermail/poky/2016-July/010629.html Mar 20 08:24:36 about force exclude a package Mar 20 08:29:10 alicef: it's definitely because of dependency Mar 20 08:34:26 mckoan: threre is a way for force the removal ? Mar 20 08:37:24 alicef: AFAIK no if it's a dependency Mar 20 08:49:54 New news from stackoverflow: How to enable tc command when building a kernel using Yocto recipes Mar 20 09:43:56 Oh, how I wish bitbake would have some mechanism for comments inside multi-line var values Mar 20 10:20:09 New news from stackoverflow: Both libc.so.6 and libc.so exist in rootfs Mar 20 13:25:17 Hi everyone Mar 20 13:26:34 SimoneNascivera: hello Mar 20 13:26:35 I'm getting an error whil building kernel-devsrc: https://pastebin.com/4yxznBJw Mar 20 13:27:14 mckoan: did it ever happened to you? Mar 20 13:27:39 SimoneNascivera: no, but I don't know anything about your configuration Mar 20 13:28:06 mckoan: I'm compiling an image for a tinkerboard system (ARM based) Mar 20 13:28:37 mckoan: and I need kernel-devsrc in order to add a kernel module to the system Mar 20 13:29:10 SimoneNascivera: not sure you need it to do that Mar 20 13:29:41 SimoneNascivera: is the module already built? cross-compilaed? Mar 20 13:29:54 mckoan: it's the first time I'm doing it and I have to compile it Mar 20 13:30:24 SimoneNascivera: lkely you want to cross-compile it and afterward deploy int on the target Mar 20 13:30:32 mckoan: since it's the first time, I thought it would be easier to compile directly on the target Mar 20 13:30:54 SimoneNascivera: using Yocto is not expected to compile on the target Mar 20 13:31:03 mckoan: uh ok, I never thounght that it could be the case Mar 20 13:31:08 SimoneNascivera: Architecture did not match (x86, expected ARM) is the right error Mar 20 13:32:00 mckoan: so should I try to set up the cross compiler and then deploy the mdoule? Mar 20 13:32:12 mckoan: *module Mar 20 13:32:20 SimoneNascivera: I would do that Mar 20 13:32:55 mckoan: ok, thank you so much for your help. I'll try right now. Mar 20 13:32:59 you don't actually have to setup the cross compiler, it is always there, whether you know it or not. Just follow one of the other module recipes and it is a fairly quick thing to put together to build it. Mar 20 13:33:18 http://wiki.koansoftware.com/index.php/Howto_build_a_kernel_module_out_of_the_kernel_tree Mar 20 13:33:48 tz: i always forget my own posts :-D Mar 20 13:33:49 can you make yocto build a host toolchain from source also? it will still need a host gcc as bootstrap compiler of course... Mar 20 13:33:53 :) Mar 20 13:34:06 saved me heaps of time, that one! Mar 20 13:34:18 tz: glad to know Mar 20 13:38:08 ernstp: yocto builds the host toolchain by default :) Mar 20 13:39:51 LetoThe2nd: I don't think so, and that's not the behavior I'm seeing... Mar 20 13:40:04 oh I'm still on yocto 2.4, perhaps it's changed? Mar 20 13:40:29 ernstp: that should have been like it forever. Mar 20 13:41:11 to me it looks like it's only building a target toolchain and uses host OS toolchain for native tools Mar 20 13:44:22 ernstp: hmmm you might actually be right and me mistaken. Mar 20 13:45:19 but I'm guessing it has support for building a native toolchain also Mar 20 14:02:48 mckoan: Once I made all necessary files, should I place them in meta-skeleton/recipes-kernel? Mar 20 14:03:46 SimoneNascivera: best practice is to add your recipe to your custom layer Mar 20 14:03:58 HOSTTOOLS_remove += "gcc g++ cpp" doesn't work, which I guess is logical... Mar 20 14:05:53 ernstp: it doesn't have support for building native toolchain, it always depends on the host to provide usable one Mar 20 14:06:48 ernstp: you can build build-appliance with yocto and then use that for your builds Mar 20 14:06:56 ok, then I know. have a somewhat heterogeneous environment... Mar 20 14:32:41 hi! can anyone give me a qick advise on this problem: i use a layer that provides a .bbappend for a recipe that does not exist. Mar 20 14:32:56 in particular the layer i am using appends to openssl_1.0.2h but the openssl packege from meta is at 1.0.2p Mar 20 14:33:18 so renaming the file solves the problem, but is there as solution that does not require changes of that layer? Mar 20 14:36:37 odda: there are wildcards, like % Mar 20 14:36:44 odda: see the dev manual for details. Mar 20 14:37:16 mckoan: thank you so much. I made my own layer and it actually starts to compile it. I received this error: https://pastebin.com/FEmrHH45 Mar 20 14:38:21 mckoan: I tried to run the make command in my shell, and it gives : make: use-ld=bfd: No such file or directory Mar 20 14:40:43 LetoThe2nd: i know that these exist but the layer that i use has an 'unwildcarded' bbappend and i dont want to introduce changes to that layer an running my own fork Mar 20 14:41:44 odda: then you're out of luck, i'd say, and have to expect the maintainer of that layer to stay properly up to date. Mar 20 14:45:45 SimoneNascivera: are you sure you are building a valid module for your kernel version? Mar 20 14:45:50 LetoThe2nd: alright, thank you ... :/ Mar 20 14:45:57 i was hoping for some kind of magic spell that only the yocto gods know ... Mar 20 14:47:54 mckoan: the kernel module is a usb driver given by the manufacturer. It should support linux-3.3.8 or higher kernel version Mar 20 14:53:30 SimoneNascivera: it *should* Mar 20 14:54:21 SimoneNascivera: it's better to ask to the device manufacturer Mar 20 14:55:18 mckoan: I'll try to ask them and hope they'll answer Mar 20 14:55:47 mckoan: btw thank you for your time Mar 20 15:00:15 SimoneNascivera: yw, ciao Mar 20 15:05:01 my recipe needs to download a couple of single files (not archives) using https. Downloading works fine, but they are all stored in WORKDIR which is messy. I would prefer to have them in a subdirectory e.g. ${WORKDIR}/external. I found the localfilename option, but it seems to effect only the download directory, but not the WORKDIR. The local file fetcher is a subdir option, the git fetcher has a destsuffix option, but how can achieve that with the wget Mar 20 15:05:01 fetcher? Mar 20 15:05:19 odda: if the bbappend is in a layer someone else wrote, perhaps you checked out the wrong branch of it? Mar 20 15:06:31 u1106: one solution would be a custom do_fetch implementation.... Mar 20 15:08:07 ernstp: right. I was thinking of adding such option to wget.py, but honestly I hoped I was just missing something simpler :) Mar 20 15:13:14 u1106: there could be a DL_DIR variable... ? Mar 20 15:14:05 oh wait, that's something else... Mar 20 15:17:31 yeah, the downloadfile option affects the location in DL_DIR, but that's not what I intended to change Mar 20 15:18:38 * kergoth yawns Mar 20 15:19:46 u1106: https://github.com/openembedded/bitbake/blob/master/lib/bb/fetch2/__init__.py#L1485 Mar 20 15:20:36 Nice, kergoth Mar 20 15:32:48 kergoth: thanks that does it. My mistake was to trust to manual that documents that behaviour only for file://. Next mistake was to look around in fetch2/wget.py. Afterwards I could guess wget.py is only responsible for getting the files to DL_DIR and __init__.py is responsible for getting them from DL_DIR to WORKDIR? Mar 20 15:33:25 (need to run now, will check later) Mar 20 15:33:45 unpacking is often common between fetchers. the fetcher in wget inherits from a base class in __init__ that implements a baseline unpack() Mar 20 15:33:54 some fetchers override it, like git, to clone instead of copy, but not all Mar 20 15:58:54 https://medium.com/@jpaulreed/the-737max-and-why-software-engineers-should-pay-attention-a041290994bd Mar 20 16:32:33 hi, I want to build ptests on sumo but not install to images by default. added ptests to DISTRO_FEATURES only but they end up on images too. can't see how though from bitbake -e image. ptests are missing from IMAGE_FEATURES. What did I miss? Mar 20 16:35:16 ptests aren't installed unless you add them to IMAGE_FEATURES.. distro features only enables the emission of the packages, not their installation Mar 20 16:35:38 my guess is some package is incorrectly rdepending on a ptest package, pulling in that package and the ptest runner, but not all the ptests Mar 20 16:39:12 kergoth: ok, thanks. That's what I thought. I'll check deeper into the image dependencies Mar 20 16:42:13 ah, it's actually the popuplate_sdk failing with "nothing provides bash needed by openssl-ptest" Mar 20 16:48:22 nah, it's both do_rootfs and populate_sdk which want to install ptest packages and bash (GPLv3) exclusion fails Mar 20 17:02:25 mckoan: well something is pulling them in. the only thing that *should* is adding ptest-pkgs to IMAGE_FEATURES Mar 20 17:44:14 Anyone else having trouble reaching freedesktop.org? Mar 20 17:44:28 I'm having a bunch of recipes fail "no route to host" Mar 20 17:44:40 cairo, etc Mar 20 17:45:10 Just checking if it's just me Mar 20 17:47:46 Striking7: https://downforeveryoneorjustme.com/freedesktop.org Mar 20 17:48:03 Funny, I just remembered about that site - sorry to bother. Mar 20 17:48:12 no worries :) Mar 20 17:48:30 Looks like I'm going to have to find something else to work on while I wait for freedesktop to figure out whatever's wrong Mar 20 17:49:00 there are source mirrors.. Mar 20 17:49:18 http://sources.openembedded.org for example Mar 20 18:02:01 ... which should be configured by default, so I'm wondering why those wouldn't be helping already Mar 20 18:30:22 hey - how would I go about adding --enable-omx --enable-omx-rpi switches to the ffmpeg recipe in my yocto build? Mar 20 18:50:06 khem: hello Mar 20 18:51:49 khem: RP and I were checking a build failure on new mesa, when it is built using meson. The new mesa release requires LLVM with RTTI enabled. So a couple of questions: 1) is there any problem in enabling RTTI for LLVM? 2) could you cook us a patch for testing? Mar 20 20:44:55 otavio, send patches and see where it goes Mar 20 20:47:48 armpit: I asked RP to give a try on mesa without meson, which does build successfully here without RTTI however I'd like to hear from khem about what are the implications to enable it Mar 20 20:58:39 RP: rburton: did you guys see the systemd patch I sent? Mar 20 20:59:24 armpit: the use of systemd-stable makes it easier to update when bugfixes and security fixes are made Mar 20 20:59:35 armpit: did you see as well? Mar 20 21:03:07 otavio, yes. seems reasonable but we are in M3 so its on RP to make the call Mar 20 21:03:45 is suspect RP is still jet lagged Mar 20 21:04:18 armpit: likely hehe Mar 20 21:08:08 Is there a way to get a .dot of the package dependencies? bitbake -g seems to generate task and recipe depends, but I'm looking for the package hierarchy Mar 20 21:08:12 * RP is feeling weird :( Mar 20 21:16:15 RP, take care Mar 20 21:26:15 bluelightning: khem: something doesn't work on the the sources.oe.org population, e.g. http://sources.openembedded.org/libqmi-1.22.2.tar.xz is missing (also from freedesktop.org) Mar 20 21:26:56 the same with http://sources.openembedded.org/libmbim-1.18.0.tar.xz Mar 20 21:27:10 both are from meta-oe, so should be built during world builds on jenkins Mar 20 21:28:10 doh Mar 20 21:28:38 sveinse: if you enable buildhistory it will record that when generating an image Mar 20 21:33:26 bluelightning: ah, yes there, perfect. thanks Mar 20 21:51:17 JaMa, we do have a selftest for checking sources. maybe adding it as a check may help catch these issues Mar 20 21:52:27 armpit: is selftest being executed for other layers than poky? Mar 20 21:53:31 I have a selftest in meta-oe to check meta-openembedded sources Mar 20 21:54:53 https://git.openembedded.org/meta-openembedded/tree/meta-oe/lib/oeqa/selftest/cases/meta_oe_sources.py Mar 20 21:56:02 but who is executing it? I haven't seen it on jenkins.nas-admin.org nor in bitbake world status e-mails from khem Mar 20 21:56:59 no one. it needs to be added to jenkins, then it could send out an email on failure Mar 20 21:57:20 or launch the sync job Mar 20 21:57:49 or both Mar 20 21:58:00 http://jenkins.nas-admin.org/view/OE/job/oe_world_workspace-rsync/lastBuild/console Mar 20 21:58:59 both were updated some 13 days ago, so should be already built and rsynced Mar 20 21:59:50 k, well the notification is going to #webos-ports-jenkins Mar 20 22:00:19 maybe update that to #oe Mar 20 22:02:00 JaMa, I've been requested to up our Qt to Qt5.12 (in our rocko system), and when looking at the meta-qt5 repo, I see that you have a "jansa/master-5.12" branch. Whould that be a good point to start at, or would it be better to go more newer, like master? Mar 20 22:02:52 sveinse: jansa/master-5.12 was used to prepare 5.12 for master, you should use master now and switch to warrior branch when 5.13 lands in master Mar 20 22:03:11 JaMa: Thanks Mar 20 22:05:33 armpit: I don't know if this rsync job is still relevant, see https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg61779.html Mar 20 22:08:28 otavio: sounds like a good idea and something i'd consider breaking freeze for Mar 20 22:08:34 didn't read the actual patch though yet Mar 20 22:10:10 libqmi-1.22.2.tar.xz was rsynced to milla a while ago in http://jenkins.nas-admin.org/view/OE/job/oe_world_workspace-rsync/558/console but rsync target halstead was talking about in https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg61764.html I don't know, I thought that the directory on milla is what is http://sources.openembedded.org Mar 20 22:13:31 JaMa, Is milla at 23.141.224.193 ? Mar 20 22:14:18 * armpit breaks wind, not freeze Mar 20 22:14:28 JaMa, Looks like yes, milla.nas-admin.org resolves to that IP. sources.oe.org is rsyncing from there hourly. Mar 20 22:14:29 otavio: I actually thought I'd merged that systemd change :/ Mar 20 22:15:20 halstead: do you know why the builds rsync to milla first instead of pushing it directly to sources.oe.org if it's on different box? Mar 20 22:15:55 JaMa, It could be a timing issue. Milla is local sources is far away. Mar 20 22:17:02 ok, for me milla is 10.20.1.193 because I always go there through builders, but 23.141.224.193 is its public IP indeed Mar 20 22:18:25 halstead: can you check that rsync job? I've checked and it's on milla for a while Mar 20 22:18:28 -rw-r--r-- 1 jenkins jenkins 947124 Feb 28 16:21 /home/jenkins/htdocs/oe-sources/libqmi-1.22.2.tar.xz Mar 20 22:22:19 JaMa, It's certainly still there and there is plenty of disk left. Running at the shell to check for errors now. Mar 20 22:22:20 New news from stackoverflow: Trying to build oe image with framebuffer Mar 20 22:24:24 halstead: thanks Mar 20 22:25:35 JaMa, It may have been timing out mirroring "1.5G git2_code.qt.io.qt.qtwebengine-chromium.git.tar.gz" although I'm not sure why it would. Mar 20 22:28:27 halstead: should I temporarily move it out from milla to confirm this idea? Mar 20 22:29:56 JaMa, I'm watching it mirror now to see how it fails. Mar 21 01:36:31 is there a way to install the dependencies of a recipe into an image without installing the actual package itself? Mar 21 01:37:03 other than manually listing them **** ENDING LOGGING AT Thu Mar 21 02:59:57 2019