**** BEGIN LOGGING AT Fri Jan 09 02:59:58 2015 Jan 09 07:18:11 hmmm Jan 09 07:18:20 gcc-source went into dizzy-stable Jan 09 07:18:43 wouldn't have thought that qualified as a 'backport', since it breaks toolchains in external layers Jan 09 07:20:43 koen: oh noes, that effects me... but only for gcc 4.8 :| Jan 09 08:13:23 good morning Jan 09 08:25:02 morning Jan 09 08:39:55 gm Jan 09 08:53:43 hi mago_, woglinde Jan 09 10:15:31 hello everybody Jan 09 10:15:44 here I am agains with a question :) Jan 09 10:16:39 I am bit older version of poky but when when get the kernel for qemuarm it basically checkout the lastest branch for project Jan 09 10:17:23 it does not go to the particular commit that is mentioned in the kernel recipe which is SRCREV_machine_qemuarm ?= "127b621f2a4d3b1111e24423c12fac001e047c1c" Jan 09 10:17:47 I just did bitbake -c kernel_checkout virtual/kernel Jan 09 10:18:04 and did git log where sources has been checked out Jan 09 10:18:22 it is giving me 6166316d47b859aa38bfecc61f4808828af03937 Jan 09 10:18:38 which is the top commit of KBRANCH_qemuarm ?= "standard/arm-versatile-926ejs" Jan 09 10:18:57 does anybody face the same issue? Jan 09 10:32:29 sorry got it .... kernel_checkout brings you to the top of the git repo and validate_branches brings you to appropriate commit Jan 09 12:45:44 when crosscompiling a project that needs a bunch of native tools to compile, and these tools are part of the project, how would you write the recipe? i.e compile all tools for host first, and then cross-compile the application. From the same source tree. I guess one option would be to make 1 recipe for each tool, have them all check out the same code, but only compile the corresponding tool? Jan 09 12:48:16 that's one way Jan 09 12:48:28 you could make 2 recipes Jan 09 12:48:30 foo-native Jan 09 12:48:31 and foo Jan 09 12:50:10 koen: 2 recipes to enable compilation of the tool both as a native and a cross-compiled tool? (even though there is no use for the tool on target) Jan 09 12:53:10 koen: or do you mean foo-native would chunk all native tools required for foo, into one recipe? Jan 09 14:05:05 mago_: yes, one recipe for all the tools Jan 09 14:06:05 koen: and what about versioning? the tools have no formal version, so i guess for foo_1.0.bb, there should be a foo-native_1.0.bb ? or what is the recommended way of dealing with it Jan 09 14:07:35 generally you pick the same version as the app Jan 09 14:16:03 Hello , I had some trouble with gst-ffmpeg with oe Jan 09 14:16:09 If someone could help me Jan 09 14:16:53 ~ask Jan 09 14:16:54 Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. Jan 09 14:18:37 During building with Yocto , I have a cross-compilation error for gst-ffmpeg_0.10.13.bb Jan 09 14:19:18 How to identify the issue and if someone could help me to fix it Jan 09 14:19:26 I have the error log Jan 09 14:28:16 Samouy which version? Jan 09 14:30:21 woglinde, 0.10.13 i think Jan 09 15:00:25 Samouy the version of yocto of course Jan 09 15:00:39 sorry Jan 09 15:02:35 It should be the latest version Jan 09 15:03:19 I work on yocto tizen Jan 09 15:03:47 bitbake tells you all Jan 09 15:03:51 at the beginning Jan 09 15:06:22 BB VERSION ? Jan 09 15:07:05 (sorry this is the first time i debug yocto..) Jan 09 15:07:59 just run bitbake Jan 09 15:08:12 bitbake tells you all versions and all layers you are using Jan 09 15:14:32 1.24.0 Jan 09 15:15:06 yes thats the bitbake version Jan 09 15:15:31 and the version of openembedded-core and meta-openembedded Jan 09 15:17:13 These metas are included in the distro i just have a "master:..." for all the metas Jan 09 15:40:17 I have this error : "../meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb do_compile error" Jan 09 15:40:31 read the compile log file it pointed you to Jan 09 15:40:56 I did it Jan 09 15:41:26 "recipe for target 'libgstffmepg_la-gstffmpegutils.lo' failed" Jan 09 15:41:44 "recipe for target 'libffmpeg_la-gstffmpegcodecmap.lo' failed" Jan 09 15:42:14 that doesn't tell us much of anything either, look further Jan 09 15:42:51 I can put the log file on pastebin if you want Jan 09 15:44:36 pastebin.com/2ZGDapsL Jan 09 15:51:58 I don't know what to do with that :-/ Jan 09 15:53:13 gst-ffmpeg/0.10.13-r8/gst-ffmpeg-0.10.13/ext/ffmpeg/gstffmpeg.h:63:8: error: unknown type name 'URLProtocol' seems to be the first error, i'd google that Jan 09 16:05:59 kergoth, got this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720796 Jan 09 16:06:03 but nothing else .. Jan 09 16:06:18 but it's not the same version of gst-ffmpeg Jan 09 16:39:48 Samouy why are using master versions instead of a release branch? Jan 09 16:43:48 woglinde, The master is the github master for the hole project . I think the meta-oe use a release branch Jan 09 16:44:48 samoy so where did you clone it from? Jan 09 16:45:07 but bitbake don't tell me the branch Jan 09 16:45:07 or the version Jan 09 16:46:00 Here Jan 09 16:46:01 https://github.com/eurogiciel-oss/tizen-Distro Jan 09 16:46:19 This is the repo of the hole yocto distro with meta included Jan 09 16:47:35 hm yes I see Jan 09 16:48:02 so the tizen guys decided themself which git commit points to a stable revision of each layer Jan 09 16:48:25 I think so Jan 09 16:49:21 so the other question is now why you need gstreamer 0.10 which is not maintained anymore Jan 09 16:50:34 proably the elf in tizen is to old Jan 09 16:50:48 https://coaxion.net/blog/2014/01/efl-and-enlightenment-gstreamer-1-x-support/ Jan 09 16:54:06 gah, ICE building qemu-native Jan 09 16:54:44 kergoth haha nice Jan 09 17:00:19 what can I do to fix that ? Jan 09 17:11:09 Or if I can avoid to build it with bitbake Jan 09 17:11:18 I don't need gstreamer Jan 09 17:53:47 hmm, if I ahve a do_install_append in a recipe and in a bbappend, what order are they run in? Jan 09 17:55:53 Crofton|work: recipe first, bbappend(s) second Jan 09 17:56:00 wew Jan 09 17:56:02 :) Jan 09 17:56:13 the other way around wouldn't make a lot of sense :) Jan 09 17:56:16 that is sensible, just wanted to check Jan 09 17:56:55 this is OE, sometimes things make no sense :) Jan 09 17:57:29 Crofton|work: _append are run in parse order, and appends are appended, not prepended, so.. :) Jan 09 17:58:00 Hmm, wonder how much work it'd be to get XDG_RUNTIME_DIR setup on the mac Jan 09 18:12:07 I thought adding machine overried would force the package to become machine specific Jan 09 18:13:26 nope, don't think that ever got implemented. machine specific FILESPATH entry, yes, overrides, no Jan 09 18:14:02 ah Jan 09 18:14:40 SRC_URI? Jan 09 18:15:37 I have a SRC_URI_append_ettus-e300 = "file:/ Jan 09 18:15:43 in a bbappend for acpid Jan 09 18:15:54 but work is still in armv7... Jan 09 18:16:11 but I ahve another recipe with a SR_URI line and it is in the machine area Jan 09 23:02:49 Looks like meta-ti's libdrm has been broken for the past month or so Jan 09 23:02:56 to go along with the kernel issues Jan 09 23:15:06 kergoth: sorry, I'll check master breakage hopefully soon, haven't had time yet Jan 09 23:15:30 * kergoth nods, know how that is, busy busy Jan 09 23:15:57 * kergoth can't say he's particularly happy about the kernel build changes, but also haven't dug deeply into those threads Jan 09 23:16:32 kergoth: yeah, internal release it consuming all my time now. I'm aware of the breakage and kernel related changes, just need to get some time Jan 09 23:18:19 * Crofton|work noticed a bunch of stuff on the meta-ti list Jan 09 23:18:44 what kind of "stuff"? Jan 09 23:19:39 emails :) Jan 09 23:20:04 well, it's mailing list, after all... :) Jan 09 23:22:45 I just noticed activity jumped quite a bit in the new year, so it was onvious you are busy Jan 09 23:30:05 or maybe because all the holidays and vacations are over? :) **** ENDING LOGGING AT Sat Jan 10 02:59:59 2015