**** BEGIN LOGGING AT Mon May 14 03:00:02 2018 May 14 03:18:34 New news from stackoverflow: Information on how to do git revisioning for yocto May 14 08:47:49 Hello I am having a problem trying to add wayland and weston to my yocto image. Is anyone able to support? May 14 08:51:07 hi May 14 08:51:13 Hello I am having a problem trying to add wayland and weston to my yocto image. Is anyone able to support? May 14 08:52:02 iangelov: maybe if you ask a specific question, including a description of the actual problem that you are seeing. May 14 08:52:19 iangelov: usually people do not step up and say "yes of yourse, how can i help you?" May 14 08:53:27 sorry, for sure I will share May 14 08:54:00 iangelov: if your logs are lengthy, please put them into a pastebin, thank you May 14 08:55:57 so as I said I need to add weston and wayland to my image. I have jethro-11.0-r8139-0. I added in my local.conf file following lines DISTRO_FEATURES_append = " opengl egl mesa cairo wayland" DISTRO_FEATURES_remove = " x11 directfb" CORE_IMAGE_EXTRA_INSTALL += "wayland weston" May 14 08:56:58 sounds ugly and massively outdated. May 14 08:57:33 I am using this board https://www.garz-fricke.com/en/products/embedded-systems/panel-mount-hmi/IA-0015R/# and the sources coming with it May 14 08:59:20 it nevertheless sounds ugly (you should not do everything in local.conf) and massively outdated (jethro is from 2015 and basically EOL) May 14 08:59:48 anyways it *might* work for testing, so what is your actual problem? May 14 09:04:32 so when I try to build everything I fail and in the log file I find CAIRO_EGL no package named wayland_egl is found May 14 09:05:12 iangelov: what layers are in use? you could put a full buildlog including head and error into pastebin? May 14 09:21:58 While working with hg repos, I've made a SRCPV:="AUTOINC-${@get_hgid('${S}',d)}", and get_hgid runs bb.process.run('hg --config trusted.users="*" id -i', shell=True, cwd=dir). I now get the error on bitbake --parse-only: "bb.data_smart.ExpansionError: Failure expanding variable SRCPV[:=], expression was AUTOINC-${@get_hgid('/my/path...',d)} which triggered exception NotFoundError: Execution of 'hg --config May 14 09:22:04 trusted.users="*" id -i' failed: command not found" May 14 09:22:25 Am I missing some dependency here? This has worked before, but I'm not sure what have changed May 14 09:37:01 For the record, SRCPV for hg repos don't work properly, which is the cause for the arrangement May 14 09:44:59 I think I have an idea of the problem: SRCPV is assigned with := and at parsing-time, the recipe repo '${S}' isn't cloned yet, so that won't work. Setting it to = seems to trigger other type errors. It's using ${S} which is ${WORKDIR}/hg, and that creates maximum recursion depth error at parsing May 14 10:51:53 sveinse: the fetcher contains various tweaks o try and help that, it may b better to try and fix the hg fetcher properly? May 14 10:53:01 RP: Yeah, it might. I'm not well versed in bitbake's internals unfortunately May 14 11:25:55 If using ${SRCPV} as-is without setting it, the SRCREV="${AUTOREV}" seems to be the culprit for hg. Once SRCREV it set to a specific revision, it does not fail with "bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception AttributeError: 'FetchData' object has no attribute 'moddir'" May 14 12:25:52 Hi Guys, I need a help, I am building a sdk image based on the image recipe, but I find most of the -dev and -dbg packages of the recipe is not added in the final sdk, I verify this by reading buildhistrory, but the sdk-info.txt shows that I am having SDKIMAGE_FEATURES = dev-pkgs dbg-pks is set May 14 12:27:11 is there a reason why -dbg -dev packages left out in building the sdk. May 14 12:27:19 madhur: bitbake rootfs-image -c populate_sdk ? May 14 12:27:57 welhm: yes, I did "bitbake -c populate_sdk " May 14 12:39:52 is there a way to create an SDK that includes all dev packages? May 14 12:41:50 forget my question, it has just been answered May 14 13:04:49 right now I am adding all the -dbg packages in TOOLCHAIN_TARGET_TASK May 14 13:05:26 this should have been added by default as I have SDKIMAGE_FEATURES is set with dev-pkgs and dbg-pkgs May 14 13:20:34 New news from stackoverflow: How to stream RTP over RTSP with SDP in LInux May 14 13:51:38 Hello fantastic yocto people. I'm back with another question. I have a weird quirk that I suspect is my recipe but I can't track it down. May 14 13:52:32 I get the git error: fatal: remote origin already exists. May 14 13:52:48 For my own repo that I can definitely clone as that user (on that build machine). May 14 13:53:04 I'm guessing it's to do with what the git fetcher is up to, but I'm in the dark apart from that. May 14 13:53:25 All I want is to pull the HEAD of master for a trivial one file, non-compiled config repo. May 14 13:55:04 Any suggestions where I should start looking? May 14 13:59:24 which version of yocto/Git are you using? May 14 13:59:32 Krogoth. May 14 14:00:27 which Git version? May 14 14:00:39 v1.9.1 May 14 14:01:11 kanavin: turns out my irc client dropped from here hours ago and i didn't notice May 14 14:01:53 rburton_: kudos for sorting the ldconfig crash thing May 14 14:02:11 well, just pestering khem really :) May 14 14:03:01 I wonder when khem has time for 'day job' :) May 14 14:03:13 supporting the toolchain is easily a fulltime thing May 14 14:04:21 rburton_: anyway. I'm looking for things to do for the next 4-ish weeks May 14 14:04:39 rburton_: if you have ideas or open bugs etc., let me know May 14 14:04:53 yeah good thinking May 14 14:05:42 rburton_: oh btw, don't forget to drop Peter's rpm open files patches, he'll come up with a better fix May 14 14:05:57 yeah, already punted them from mut thanks May 14 14:06:28 JoeR: you should ask rburton_ probably he knows May 14 14:11:13 Can PROVIDES be used for arbitrary use? And can it be RDEPENDS on? May 14 14:12:21 sveinse: I'd say yes, but if you want to put there things that are not real package names, prefix with virtual/ May 14 14:14:20 kanavin: What is the distinction between PROVIDES and RPROVIDES? When is the latter used over the former? May 14 14:15:18 build time / runtime May 14 14:15:33 identical to depends / rdepends May 14 14:17:43 one of the main problems of yocto/oe/bitbake, too brief keywords. lots ot confusion would go away if naming them eg. runtime_depends, build_depends May 14 14:17:46 My use-case is a recipe which generates three mutually exclusive configuration packages which all shall provide virtual/sp-support. The main app should rdepend on virtual/sp-support. So then the recipe should contain RPROVIDES_${PN}_option1="virtual/sp-support" and so on? May 14 14:23:15 Dear me. The origin as listed in the git config didn't have a .git on the end of the repo name. Specifying it as part of the URL works under git when used "normally" but I'm guessing that the git fetcher does something different than my trivial clone, and thus git gets upset. May 14 14:40:42 malu: not *that* confusing. If it starts with R its runtime, otherwise buildtime. May 14 14:41:48 sveinse: basically our packaging behaves the same way as debian so https://www.debian.org/doc/debian-policy/#replacing-whole-packages-forcing-their-removal is useful May 14 14:43:53 rburton_: maybe not confusing to you and me, but clearly people get confused, the evidence is in the pudding. May 14 14:54:59 how are tasks recognized as cleanly completed? i.e. I have a wrongly packaged binary (executable bit is missing). The PV (incl. AUTOREV) didn't change in months, but somehow I ended up with a ubifs-image that had that executable file non-executable. May 14 14:56:26 I mean is it imaginable, that bitbake was interrupted prior to executing some `chmod`-ish command, but assumed (due to "old"/preexisting completion files) it was properly executed? May 14 15:05:45 is there a possibility to do a RDEPENDS_xx -= ? May 14 15:06:29 if I want to fix a recipe which sets a broken RDEPENDS May 14 15:11:02 lol, client sends a block diagram asking basically to redesign the whole board. May 14 15:11:13 I guess that's good. Means I still have a job. May 14 15:12:19 yay ddg helps a lot May 14 15:21:14 woops wrong channel May 14 15:23:11 majuk, good for you! May 14 15:24:04 Crofton|work: Thanks. :D Hopefully the client is as excited when I tell him these changes will take us from 6 to 8 copper layers. May 14 15:31:06 Hi all, newbie question most likely: I have added the skeleton external kernel module (hello-mod) to my image and added it to MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS, however during stage 2 where hello.mod.c (the wrapper source file) get compiled, I get error regarding __this_module being an incomplete type and KBUILD_MODNAME not being defined. Any thoughts? May 14 15:35:15 I can see command line to make looks correct: -C is set to kernel-source and M= module directory May 14 15:50:19 are you inheriting the correct module classes? May 14 15:52:44 I believe so, hello-mod_0.1.bb inherits module May 14 15:54:03 My defconfig has: CONFIG_MODULES=y and CONFIG_MODULE_*=y May 14 15:57:30 it seems like these errors would stem from module.h not being included, but that's not the case... May 14 15:58:38 is ${THISDIR} implicit/default in FILESEXTRAPATHS, or is it ${THISDIR}/files ? May 14 15:59:39 the compiler complains that __this_module is an incomplete type, but __this_module is the name of the instance, which suggests that module.h isn't being included May 14 15:59:55 or at least that struct module isn't visible May 14 16:06:22 kanavin: kconfig fragment support for u-boot! ;-) May 14 16:07:48 sveinse: neither. filesextrapths is empty by default, and is only used to add extra paths for bbappends May 14 16:08:05 sveinse: if you mean the default for FILESPATH for recipes, THISDIr isn'tincluded, no May 14 16:12:30 kergoth: thanks May 14 16:14:07 Does bitbake automatically build RDEPENDS packages when building a packages? May 14 16:14:28 es May 14 16:14:30 yes May 14 16:14:36 thanks May 14 16:16:39 JaMa: does qemu really need both sdl1 and sdl2 to build? May 14 16:16:59 oh you replied :) May 14 16:17:58 mutually exclusive groups are a bit of a pain with packageconfig May 14 16:21:17 I know in the tune features we have that implemented, do we need something similar in packageconfig? May 14 16:21:36 yeah would be useful May 14 16:21:44 PACKAGECONFIG_CONFLICT[item] = "what it conflicts with" May 14 16:22:18 i was wondering about PACKAGECONFIG[sdl] and PACKAGECONFIG[sdl.1] [sdl2] May 14 16:22:28 IF I remember right (and I may not be in this instance) we didn't do that originally since we figured configure would prevent them.. --but-- that would fail during build vs during parse.. parse is a much better time May 14 16:22:41 so there's nested members and the top-level sdl enable/disable options would apply to all the children May 14 16:24:33 I've got SRC_URI="file://bin" and in do_install() { echo $PWD; install -m 0755 bin/vs2 }. It stops on not finding bin/vs2, yet $PWD prints the correct path and the workdir contains the bin/ directory with the file. What could be wrong? May 14 16:25:08 sveinse: presumably you're passing two arguments to install? May 14 16:25:37 rburton: yeah, sorry, manual copy paste error May 14 16:26:10 easy fix: just use ${WORKDIR}/bin/vs2 in the install command May 14 16:26:26 because of pseudo perhaps? May 14 16:26:33 no May 14 16:26:42 rburton: I can add "toplevel" sdl PACKAGECONFIG which does only the enable/disable without adding any dependency and then sdl[12] which will add the right abi parameter and the dependency May 14 16:27:02 rburton: but then people currently using just sdl will get failures May 14 16:27:14 hm May 14 16:27:40 yeah we need to migrate sdl to be sdl2 really May 14 16:27:45 can we just drop sdl1? May 14 16:27:50 is there any reason to support both? May 14 16:28:19 I don't know May 14 16:29:09 While I'm at it: if I have a in-tree source which I don't want to copy over to workdir, I believe I could use SRC_URI="file://dir;unpack=no" but I see now that it copies it into workdir anyways. Is there a way to do this? May 14 16:29:20 with gtk UI broken as well, that leaves sdl2 the only option of ui May 14 16:29:30 sveinse: why would you want an entry in SRC_URI that isn't in the workdir? May 14 16:29:39 if its not in workdir you can't reach it May 14 16:29:58 if you don't want to reach it, why is it in SRC_URI? May 14 16:31:00 rburton: well, this is perhaps a principal discussion, but because the sources are located together with the recipes, so there is no need to copy them over to workdir May 14 16:31:22 But if recent bitbakes prevents that, then, yeah, must be redesigned then May 14 16:31:46 if unpack=no isn't working, that's a bug May 14 16:31:48 sveinse: in the general case we support per-machine overrides for every file, and bbappends can drop in replacement files May 14 16:32:11 so you shouldn't be grabbing files from where you think they are, but let bitbake put the right files into WORKDIR May 14 16:33:47 JaMa: '[17:31:09] configure will warn that sdl1 is deprecated' May 14 16:33:54 JaMa: sounds like we can just make sdl be sdl2 May 14 16:34:13 yeah this magic of OE is quite PITA in many cases, when you drop in a BSP layer which is doing interesting things by file overrides May 14 16:34:56 I know yocto's stance on this, with the desire to split recipes and sources. But when you're developing an application where the source development and recipe-adjustments go hand in hand, having to constantly committing to two different repos just havent worked in our organization. Got a lot of build errors and confused devs due to this close relationship. This is why we decided to put sources and recipes May 14 16:34:57 rburton: ok, will update it in jansa/thud branch in a sec May 14 16:35:02 together for this layer. May 14 16:35:33 doesn't seem unreasonable to me, it's the way folks do e.g. debian development, just quite different from our usual workflows May 14 16:35:41 sveinse: its a slippery slope which is a bit slow in the beginning May 14 16:35:48 Debian has a concept of native packages, where sources sits together with the metas (the debian/ dir). I actually wish bitbake could have something similar May 14 16:35:51 but if the unpack flag isn't obeyed, you should definitely open a bug May 14 16:36:25 kergoth: yeah, I'll double check this and file one May 14 16:36:43 I think of systems like bsds and android then having all goop in one is what works, not necessarily best May 14 16:36:47 i've personally tested populating local source trees for every recipe used in a minimal image and placing their recipes inside the source trees, doing all builds from that local directory of source trees + metadata, bypassing fetch/unpack/patch across the board May 14 16:36:58 has its advantages and disadvantages May 14 16:37:04 sveinse: it works, it just does a copy you don't really care for May 14 16:37:49 kergoth: with devtool I think we should be able to address developer needs May 14 16:39:16 one issue that always bites with OE's way is CI tools assume the traditional monolithic systems, so one has to script around a bit May 14 16:39:30 devtool is good at extracting a tree and updating ar ecipe from that tree, less so updating the tree when the recipe changes when the layer is updated, iirc May 14 16:40:45 i actually think it'd be interesting to prototype a setup where the metadata is still out of band, just store the source trees of *everything* in git repos we hosted, patches being branches, no fetching from upstream locations, only controlled scm repos May 14 16:40:54 there is devtool sync May 14 16:41:00 Have yocto been considering the ability to share repos among recipes without checking all out all over again? May 14 16:42:21 In mono repo setups, where a large upstream repo might contain sources for multiple recipes. If then the repo can't be subdivided/sliced to isolate the sources for a particular recipes, then there will be a lot of superflous checkouts May 14 16:42:23 kergoth: one strenght of OE is strong component boundaries, not sure if that would remain to strong in such a set up May 14 16:42:59 sveinse: look how kernel and gcc recipes are May 14 16:43:19 it'd sidestep certain corporate concerns and potentially ease aspects of maintenance, but yeah, there'd be tradeoffs i'm sure May 14 16:43:25 hence being a prototype May 14 16:43:42 downside is it'd require project-wide interest, otherwise there wouldnt' be enough use to really determine the effects May 14 16:44:19 rburton: jansa/thud updated, triggering the builds now May 14 16:44:48 kergoth: I think having a traditional view would find more supporters and might ease learning curve a bit May 14 16:44:50 khem: i'll do that -- (even tough I have a suspicion that the recipe setup for either of them falls under the category of "simple") May 14 16:45:25 sveinse: much fun with the kernel/gcc trees being shared but causing annoying races during build May 14 16:45:30 sveinse: what you are asking is also not simple particularly, talking about component boundaries it defies OE May 14 16:45:48 sveinse: we do one proper fetch to DL_DIR and then do local clones, which are relatively fast May 14 16:49:49 rburton: gcc8 branch is updated May 14 16:50:13 rburton: testimage passed for qemux86 and qemumips for sato image May 14 16:50:30 but we need kernel 4.15 May 14 16:51:16 eventually I am sure patches for 4.14 will land too since its LTS but I am not planning to do that all myself May 14 16:51:17 New news from stackoverflow: Yocto: Why is struct module undefined during building an external kernel module May 14 16:52:01 Is there an option to bitbake for not building RDEPENDS when building a recipe? May 14 16:52:22 JaMa: thats just a change to the top commit right May 14 16:52:25 sveinse: no May 14 16:55:02 technically you could override the default rdeptask/etc, but i wouldn't recommend it, it'd potentially break image construction May 14 16:57:52 no worried, I meant it as a means during development, as building some of the RDEPENDS is cluttering my bitbake -v output for this other recipe May 14 16:57:56 *no worries May 14 16:58:33 kergoth: how would it break image construction May 14 16:58:52 is it becuse image recipes are no different than component recipes May 14 16:59:07 and might start ignoring rdeps during build May 14 16:59:57 well obviously you need to ensure the dependent packages exist to build an image, if you remove the bits that build rdeps, you'd be missing packages. though i expect you could drop rdeptask but keep recrdeptask in the image to resolve that.. potentially other issues though May 14 17:00:05 * kergoth shrugs, admittedly haven't had much caffeine yet this morning May 14 17:01:32 I would expect that RDEPENDS are only needed when building images, but they are by definition, not needed when building a recipe. It's only when the package is installed somewhere its RDEPENDS comes into play. May 14 17:02:24 I do understand the co-building of RDEPENDS for the need of package feeds, but more as a function for a temporary development means May 14 17:18:19 Is it correct that ipks don't have any concept of PROVIDES and RPROVIDES? May 14 17:19:24 I have a package where I've set RDEPENDS="virtual/myvirt", but I don't see it in the metadata of that .ipk May 14 17:19:27 rburton: top 2 May 14 17:20:31 forget it, my bad May 14 17:55:39 sveinse: heh, forgot _packagename? :) May 14 18:05:58 kergoth: what, no idea of what you're talking about ;) :D May 14 18:07:42 RDEPENDS is useless you need e.g. RDEPENDS_${PN} May 14 19:17:50 hi guys May 14 19:18:13 im getting this error on linux-yocto:do_patch task May 14 19:18:15 [ERROR]: Application of .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-module-addresses-dur.patch failed. May 14 19:18:57 This patch is add by the bsp/common-pc-64/common-pc-64-standard.scc May 14 19:19:00 feature May 14 19:19:20 someone knows how to fix it? May 14 19:19:49 nope. not with that information. May 14 19:20:22 every single person / sanity / nightly build that runs for qemux86* builds that BSP. so clearly, you have something different in your setup. May 14 19:24:18 yes, I created a machine called dummy-x86-64 and set KMACHINE dummy-x86-64, KTYPE standard and KARCH x86_64 May 14 19:24:57 so I set COMPATIBLE_MACHINE_dummy-x86-64 = "dummy-x86-64" May 14 19:25:13 just it May 14 19:25:55 I used to build my image on dizzy branch May 14 19:26:04 this is on master then ? May 14 19:26:05 now i'm trying to build it on sumo branch May 14 19:26:11 right. same thing. May 14 19:26:30 the processing is different for a while. dizzy is quite old, so you would’nt have seen any of the intermediate changes. May 14 19:26:49 do you have your own BSP .scc file somewhere ? are you including anything on the SRC_URI ? May 14 19:26:56 yes, i just checkout and bitbake May 14 19:27:04 'quite' - released october 2014 May 14 19:27:45 yes, I have a dummy-x86-64-standard.scc that contains KMACHINE, KTYPE and KARCH variables May 14 19:28:03 vulnerable to spectre/meltdown and the wpa exploits too May 14 19:28:07 and that’s it ? It must have an include of the common-pc definition, right ? May 14 19:28:40 yes May 14 19:29:03 I included bsp/common-pc-64/common-pc-64-standard.scc on my dummy-x86-64-standard.scc file May 14 19:29:19 so that will trigger what you are seeing now, a full patch attempt, which will fail. since those patches are already applied to the tree. it wasn’t like that before, but is now to simplify the code. May 14 19:29:41 try changing that line to 'include bsp/common-pc-64/common-pc-64-standard.scc nopatch’ May 14 19:29:42 hummmmm May 14 19:30:14 thank you very mutch sir May 14 19:30:51 assuming that works ;) that path doesn’t get a lot of mileage. if it doesn’t sending a pointer to your layer, etc, to the linux-yocto list will help, so I can just spawn my own build. May 14 19:33:10 ok :D May 14 19:40:52 zeddii_home: it worked sir, thank you! May 14 19:45:35 excellent. thanks for letting me know. May 14 19:52:40 zeddii_home: quick question, are there any plans for updating the puppet and chef recipes in meta-cloud-services? May 14 19:57:45 smurray: eventually yah. most of the uprev/update time so far has been on the openstack bits, but the supporting stuff will cycle to the top as some point. May 14 20:00:10 zeddii_home: okay. I have a customer poking around with it that I suspect will ask for a newer version of one or the other, so I might have updates at some point May 14 20:01:22 zeddii_home: I also have some different hackery I'm using for them for building gems with native extensions that I'm debating whether it's upstreamable or not May 14 20:20:19 smurray: it is definitely worth sending! maybe with some tweaks it’ll be broadly useful. patches will tell the story. I can’t say that the current state is perfect, so anything is possible. May 14 20:21:44 zeddii_home: the hackery done in ruby.bbclass wasn't working for the nokogiri gem (which is a bit of a beast), so I took an approach of patching Ruby's rbconfig.rb to add a hook for cross-compilation May 14 20:22:06 zeddii_home: so it requires patching Ruby, which I figure is a bit overly messy May 14 20:22:45 zeddii_home: I have some idea of what it'd likely take to get rake working as an alternative, but don't have the cycles just ATM to try that May 15 00:09:04 is there a tech meeting for may 15?! one was posted, then canceled with the promise a new one would come soon, but I never saw one **** ENDING LOGGING AT Tue May 15 03:00:02 2018