**** BEGIN LOGGING AT Tue Feb 17 02:59:58 2015
Feb 17 07:36:54 <Achel00s> hello
Feb 17 07:37:08 <Achel00s> I have downloaded a layer for browsers here :https://github.com/OSSystems/meta-browser
Feb 17 07:37:48 <Achel00s> but I don't know how to include it in my build with hob
Feb 17 07:38:39 <Achel00s> I build core-image-x11
Feb 17 08:42:52 <JEEBsv> hmm, is this the correct way to make an image that has systemd as the init system? http://up-cat.net/p/05afbfe7
Feb 17 08:43:46 <nrossi> JEEBsv: looks right
Feb 17 08:43:54 <JEEBsv> alrighty
Feb 17 08:44:43 <JEEBsv> cleaned my buildroot so it shouldn't be that, either, in case it fails
Feb 17 08:45:29 <JEEBsv> (this is the meta-hoge/recipes-hoge/images/core-hoge.bb)
Feb 17 08:49:34 <abelloni> I'm not sure changing DISTRO_FEATURES in recipe is working as expected
Feb 17 08:50:19 <nrossi> JEEBsv: oh completely missed that, you have to define those values in the distro.conf or in your local.conf
Feb 17 08:50:38 <JEEBsv> ah
Feb 17 08:50:43 <JEEBsv> so distro.conf
Feb 17 08:51:25 <nrossi> JEEBsv: if you have a customer distro, otherwise put it in the local.conf
Feb 17 08:51:30 <nrossi> custom*
Feb 17 08:52:19 <JEEBsv> yeah, I'm trying to build a meta layer that contains an image type that I can just build with bitbake image-name without poking local.conf
Feb 17 08:53:54 <nrossi> JEEBsv: you can sort of do that, as long as the distro has 'systemd' in the DISTRO_FEATURES
Feb 17 08:54:28 <JEEBsv> yeah
Feb 17 08:57:57 <nrossi> JEEBsv: Have a look at the base packagegroup for core boot: https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
Feb 17 08:58:15 <nrossi> JEEBsv: any variables in there can be overrided as the image recipe level
Feb 17 08:59:14 <nrossi> JEEBsv: but you wont be able to use the packagegroup-core-boot, you will have to implement your own dependencies like the packagegroup-core-boot for you image
Feb 17 09:12:49 <sujith_h> Hi all. This is the snapshot of SRC_URI and SRC_REV I have in my recipe: http://pastebin.ubuntu.com/10270255/. The problem I face here is after the download of source from github, lets say p1_tls. The configure script is missing in the download directory. Where as its present in the orignal git://github.com/processone/tls
Feb 17 09:13:24 <sujith_h> any clue why the configure script would be missing. And this is not just for p1_tls, but for few others I had noticed the same.
Feb 17 09:20:15 <JEEBsv> nrossi: thanks. I'll have to look at it later, I ended up just using local.conf for now...
Feb 17 09:23:02 <bluelightning> morning all
Feb 17 09:26:37 <sujith_h> bluelightning: good morning :)
Feb 17 09:28:34 <sujith_h> bluelightning: http://pastebin.ubuntu.com/10270255/ is a snapshot of my recipe. I had inherited autotools-brokensep in the recipe. And after the do_patch, in the p1_tls folder I am not able to see the configure script. Is it because the autotools_do_configure removes the configure script?
Feb 17 09:33:16 <sujith_h> i think yes. autotools_do_configure is the one which is deleting the configure script :(
Feb 17 09:33:59 * sujith_h wonder how to stop deleting the configure script of the downloaded sources from github
Feb 17 09:36:13 <bluelightning> sujith_h: we run autoreconf, that is supposed to re-generate the configure script
Feb 17 09:36:33 <bluelightning> this is a good thing to do in most cases to avoid autotools compatibility problems
Feb 17 09:37:54 <bluelightning> this large number of repositories in SRC_URI is a concern - you might consider using separate recipes if these don't have to be built in the same tree
Feb 17 09:38:44 <bluelightning> sujith_h: in any case, do_patch is *before* do_configure, so that's before autotools_do_configure gets a chance to run - so that's not the issue
Feb 17 09:39:55 <bluelightning> configure is not generally recursive - you probably ought to split this recipe up
Feb 17 09:42:32 <sujith_h> bluelightning: You mean separating githubs mentioned in the SRC_URI to separate recipes right?
Feb 17 09:42:38 <bluelightning> sujith_h: yes
Feb 17 09:44:04 <sujith_h> bluelightning: Thats a good point. I will try to implement it. Let me check if by doing so, will it affect the work flow of the main recipe or not.
Feb 17 10:10:33 <sujith_h> bluelightning: I created a recipe for p1_tls. But it didn't surprised me that, the build failed because it was missing an executable rebar, which comes from ejabebrd !!!
Feb 17 10:10:55 <sujith_h> bluelightning: so these sources will have to be build under same tree :(
Feb 17 10:11:02 <bluelightning> sujith_h: not necessarily
Feb 17 10:11:13 <bluelightning> sujith_h: the proper way to handle this would be to ensure that binary is installed into the sysroot for the p1_tls recipe to use
Feb 17 10:14:11 <sujith_h> bluelightning: I didn't got that point. The binary/executable is part of the source of ejabber. And I used the SRC_URI with githubs to override the downloads that were happening during the do_compile.
Feb 17 10:15:09 <bluelightning> sujith_h: I see... well maybe you have no choice if that is the way that ejabberd is set up to build
Feb 17 10:15:32 <sujith_h> bluelightning: yah its bit complicated ( atleast for me :) )
Feb 17 10:16:12 <sujith_h> bluelightning: in most of the make file or configure they have reference for rebar executable and which is part of ejabberd source :(
Feb 17 10:17:21 <bluelightning> that in itself is not a problem - we have a lot of recipes that install binaries into the sysroot for other recipes to use
Feb 17 10:17:58 <bluelightning> the problem here is that ejabberd expects to build these subcomponents as part of its build, I'm assuming doing it afterwards would be difficult
Feb 17 10:18:22 <sujith_h> bluelightning: yah it expects it to be part of the build
Feb 17 13:36:44 <_qwerty_> Hi All, I have a question about DS1307 intregation, I follow a guide to integrate rtc on beaglebone and now all work. But I have to add a systemd service to enable so how I can add it
Feb 17 14:04:24 <LocutusOfBorg1> _qwerty_,
Feb 17 14:04:27 <LocutusOfBorg1> conf/local.conf:DISTRO_FEATURES_append = " systemd"
Feb 17 14:04:27 <LocutusOfBorg1> conf/local.conf:VIRTUAL-RUNTIME_init_manager = "systemd"
Feb 17 14:05:38 <_qwerty_> LocutusOfBorg1: systemd it seems is already enable I have to add a new custom service
Feb 17 14:07:46 <LocutusOfBorg1> ops, sorry
Feb 17 14:09:00 <LocutusOfBorg1> inherit systemd SYSTEMD_SERVICE_${PN} = "name.service" ?
Feb 17 14:09:39 <LocutusOfBorg1> and I guess you have also to install them with do_install_append
Feb 17 14:09:46 <_qwerty_> yes
Feb 17 14:10:03 <LocutusOfBorg1> if you want to know how to write a service file I can't help you :p
Feb 17 14:12:47 <_qwerty_> no already have it
Feb 17 14:13:21 <_qwerty_> So I have to write a new .bb file to install service... it is right?
Feb 17 14:35:51 <LocutusOfBorg1> yes _qwerty_
Feb 17 14:36:15 <LocutusOfBorg1> or you can bbappend your service into another recipe
Feb 17 15:16:12 <abelloni> JaMa, otavio: I got some help from someone at the QT company and it builds
Feb 17 15:16:24 <abelloni> I still have a few QA issues though
Feb 17 15:16:56 <abelloni> /usr/lib/libQt5Qml.so.5.3.2 contains probably-redundant RPATH /usr/lib [useless-rpaths]
Feb 17 15:17:13 <abelloni> I'm not sure how to integrate the changes
Feb 17 15:23:34 <JaMa> abelloni: what was the issue? are you going to send patch?
Feb 17 15:24:11 <abelloni> I'm still trying to compile various configurations
Feb 17 15:24:26 <abelloni> but the issue is in qmake_base.class
Feb 17 15:25:00 <abelloni> https://github.com/meta-qt5/meta-qt5/blob/master/classes/qmake5_base.bbclass#L163
Feb 17 15:25:12 <abelloni> removing -r here solves it
Feb 17 15:29:03 <ionte> hi. i have support for a few different boards (olinuxino, raspberry pi, beaglebone black) and for each I've added some custom kernel patches etc. so i have one linux-fslc.bbappend, one linux-raspberry.bbappend, etc. now, my problem is that when i build for one platform i don't want to require the bsp's of the other platforms.
Feb 17 15:29:41 <ionte> but bitbake stops with an error that there is no linux-fslc recipe when building for raspberry, etc...
Feb 17 15:29:54 <ionte> what is the correct way to handle this?
Feb 17 15:30:40 <abelloni> add that in your layer.conf:
Feb 17 15:30:42 <abelloni> https://github.com/Freescale/meta-fsl-arm/blob/master/conf/layer.conf#L20
Feb 17 15:31:50 <abelloni> then move your bbappend in directories named as the layer they depend on
Feb 17 15:33:39 <ionte> ok, will try something like that, thanks!
Feb 17 15:34:01 <LocutusOfBorg1> mmm I'm wondering if the log_check can be made a little bit smarter
Feb 17 15:34:11 <LocutusOfBorg1> actually the build was failing because of
Feb 17 15:34:14 <LocutusOfBorg1> WARNING: log_check: Matched keyword: [ERR]
Feb 17 15:34:24 <LocutusOfBorg1> the problem is that ERR was in the PATH name :)
Feb 17 15:34:26 <LocutusOfBorg1> lolol
Feb 17 15:34:39 <LocutusOfBorg1> like /home/TERRA/yocto
Feb 17 15:34:47 <LocutusOfBorg1> and log_check grepped it
Feb 17 15:57:56 <gxenusmil> Hello !
Feb 17 15:59:28 <gxenusmil> I am having a little trouble building the nativesdk-packagegroup-qt5-toolchain-host package. Can anybody help me ?
Feb 17 16:03:44 <gxenusmil> I do not know why but the gcc-crosssdk-initial-x86_64 has as preferred gcc package the version gcc-4.9.1 instead of gcc-linaro-4.9
Feb 17 16:04:35 <gxenusmil> I have tried to change it setting GCCVERSION="linaro-4.9" on local.conf but it is ignored.
Feb 17 16:14:36 <Matulis> hello, I am trying to boot a kernel and I am getting the following error: Unhandled fault: alignment exception (0x001)
Feb 17 16:17:34 <Matulis> I am seeing people say that the kernel needs to be built with CFLAGS=-mno-unaligned-access, just wondering if anyone has come across this before?
Feb 17 16:18:49 <abelloni> it should not be unless you don't have an mmu
Feb 17 16:19:55 <abelloni> and the kernel makefile handles that for you
Feb 17 16:20:22 <Matulis> what if I have an older kernel from a custom bsp? It looks like they were using an older version of gcc
Feb 17 16:21:20 <kergoth> i've seen that before with old gcc
Feb 17 16:21:24 <kergoth> don't recall the details, though
Feb 17 16:21:51 <Matulis> okay, I will poke around
Feb 17 16:44:22 <Matulis> so how would I add cflags arguments to my kernel compilation?
Feb 17 16:44:44 <Matulis> KCFLAGS?
Feb 17 16:46:14 <zeddii> Matulis: the kernel doesn't take CFLAGS from external variables, it really knows best and sets its own. typically you need to patch the kernel to make a compilation flag change, or bury it in a compiler wrapper. but almost always .. it's a bad idea.
Feb 17 16:46:54 <Matulis> i was looking through my boards bsp release notes, and it looks like they had to compile it with mno-unaligned-access for newer versions of gcc
Feb 17 16:52:39 <Matulis> zeddii should I patch the makefile for my arch then?
Feb 17 16:59:29 <zeddii> That's what I'd do. There's no simple way to flow CFLAGS down into the kernel, since it avoids that by design.
Feb 17 17:00:29 <bluelightning> zeddii: so, I'm back to trying to get externalsrc to work with the kernel - is this something you've tested recently?
Feb 17 17:05:16 <zeddii> nope.
Feb 17 17:05:32 <zeddii> but I was going to look at it once 3.19 is done.
Feb 17 17:11:29 <bluelightning> ok... actually I think maybe I got a bit further
Feb 17 17:27:23 <kimo_> hi all, how do we change yocto distro name string that is showed at boot time ?
Feb 17 17:27:59 <kimo_> I mean the "Poky  (Yocto Project Reference Distro ...)" part
Feb 17 17:29:04 <bluelightning> kimo_: that's set in DISTRO_NAME
Feb 17 17:29:10 <jmd> I think its in /etc/issue
Feb 17 17:29:13 <bluelightning> kimo_: you should set that in your own custom distro config
Feb 17 17:29:52 <bluelightning> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution
Feb 17 17:30:30 <kimo_> bluelightning:  :) thanks
Feb 17 18:15:00 <JaMa> bluelightning: any idea? this happens after last master update where I've noticed some oe-pkgdata-util changes http://pastebin.com/3X9qdETV
Feb 17 18:15:57 <bluelightning> JaMa: are you using an old copy of a class that calls oe-pkgdata-util? e.g. buildhistory
Feb 17 18:16:14 <abelloni> JaMa: and now fixing qtdeclarative breaks building my qt application
Feb 17 18:16:30 <bluelightning> JaMa: AFAIK I fixed all calls in OE-Core itself
Feb 17 18:23:18 <JaMa> bluelightning: ah right, sorry, probably have local buildhistory copy
Feb 17 18:25:50 <bluelightning> JaMa: do you really still need that?
Feb 17 18:28:15 <JaMa> unfortunately yes
Feb 17 18:30:03 <bluelightning> ok... well I guess you'll need to patch it in the same way I have done with the current version
Feb 17 18:48:25 <JaMa> bluelightning: yes already backporting 4 last buildhistory commits from master
Feb 17 19:07:50 <bluelightning> zeddii: ok I have some fixes for externalsrc + the kernel, should be able to send them out tomorrow
Feb 17 19:08:05 <bluelightning> (nothing major)
Feb 17 19:10:10 <bluelightning> bbl
Feb 17 20:19:56 <r23s> Is it possible to apply a patch in one layer to a package/recipe in another?  Say apply patch layer-a/recipes-kernel/linux/linux-yocto/0001-fix.patch to recipe layer-b/recipes-kernel/linux/linux-yocto_3.17.bb?
Feb 17 20:31:55 <bluelightning> r23s: yes
Feb 17 20:32:51 <bluelightning> r23s: you'd just create a bbappend called linux-yocto_3.17.bbappend and place it in your layer
Feb 17 20:33:25 <bluelightning> for the kernel specifically, check this out: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#modifying-an-existing-recipe
Feb 17 20:33:31 <r23s> bluelightning:  Great.  What about .cfg files?
Feb 17 20:34:01 <bluelightning> r23s: yep, that's also covered in the manual I just linked
Feb 17 20:34:14 <r23s> bluelightning:  Awesome, this looks like just what I need
Feb 17 20:34:21 <r23s> Thanks!
Feb 17 20:36:02 <bluelightning> no worries
Feb 17 20:55:59 <ionte> hi. i have a git question: in the yocto "getting started" guide, it is recommended to get the source code with two git commands: "git clone <url>" followed by "git checkout -b dizzy origin/dizzy". what is the difference to using a single command: "git clone <url> -b dizzy"?
Feb 17 21:01:15 <neverpanic> ionte: none. The former works with older versions of git, the latter does not.
Feb 17 21:01:20 <kergoth> no difference, except that the latter should be faster due to not doing two checkouts
Feb 17 21:03:07 <ionte> ok, thanks!
Feb 17 21:03:38 <rewitt> looks like "-b" was added Aug 2009 if you're curious :)
Feb 17 21:31:21 <Crofton> zeddii, you realize meta-openstack and meta-oe have a recipe for python-lxml
Feb 17 21:31:48 <Crofton> and you depend on meta-oe
Feb 17 21:32:00 <Crofton> and I am looking at updating the meta-oe recipe to the latest
Feb 17 21:35:08 <ulf`> khem: ping
Feb 17 21:35:32 <ulf`> khem: I can't get clang to build using poky 1.7.1
Feb 17 21:41:09 <ionte> is there any way to make a layer optional? i've added meta-raspberrypi layer to bblayers.conf, which is required for raspberrypi-builds. but for other machines it should not require that layer to exist...
Feb 17 21:42:49 <kergoth> why don't you just create multiple build directories?
Feb 17 21:48:59 <zeddii> Crofton: I've pointed out to a few people that the openstack components have severe version dependencies, so I pretty much introduce and keep packages contained in that layer.
Feb 17 21:49:19 <zeddii> and that I'm not necessarily a fan of "grouping by type" versus "grouping by function"
Feb 17 21:49:28 * zeddii has to head out
Feb 17 21:49:29 <Crofton> but what happens when I bump the version in meta-oe
Feb 17 21:49:39 <zeddii> I'll pin my versions
Feb 17 21:49:43 <Crofton> ok
Feb 17 21:49:49 <Crofton> just warning you :)
Feb 17 21:49:54 <zeddii> in this case, I'm not sure which came first.
Feb 17 21:50:06 <ionte> kergoth: sure, but i try to make this a bit generic. so i have a layer with a bblayers.conf.sample and use TEMPLATECONF when initiating the build environment. i would rather not have more than one of these.
Feb 17 21:52:13 <ionte> not sure if that's the best way to achieve this, but it's better than adding layers by hand when creating new build environments...
Feb 17 21:57:39 <kergoth> hmm, lots of ways of doing it, many folks do their own thing in that regard, i think. angstrom tends to add all the layers and keep them in bblayers.conf. at mentor, we only include what's needed for the configuration in question, but ended up creating our own setup scripts as a result, which will automatically pull in the layers for a specified machine
Feb 17 22:03:22 <r23s> bluelightning: I followed the guide you sent but didn't have any luck.  Does layer priority matter?  I'm assuming the .patch or .cfg layer has to be higher than the layer with the main recipe.
Feb 17 22:04:04 <ionte> hm. ok. perhaps a setup script would work better...
Feb 17 22:04:18 <r23s> For the record, I'm trying to enable CONFIG_MD_RAID456=y to enable software RAID modes.  If there is a better way to do this than a .cfg patch let me know...
Feb 17 22:09:26 <bluelightning> r23s: priority should not matter, no...
Feb 17 22:09:30 <bluelightning> zeddii: ^
Feb 17 22:18:01 <r23s> bluelightning:  Do I need to add anything to bblayers.conf or either layer.conf file to associate the layers?  Would cleaning linux-yocto (bitbake -c clean linux-yocto) have fouled things up?  Excuse me if those ideas are nonsensical, I'm grasping at straws here...
Feb 17 22:19:02 <bluelightning> r23s: well, your layer would need to be added to bblayers.conf, but I assume you already did that
Feb 17 22:19:18 <bluelightning> r23s: see if your bbappend shows up in: bitbake-layers show-appends
Feb 17 22:21:00 <r23s> bluelightning: That's useful, didn't know about that switch.  I'm not seeing the append, but I do get the following: "WARNING: linux-yocto_3.17.bb: missing append for preferred version"
Feb 17 22:22:30 <r23s> You know what, I think I found my problem
Feb 17 22:22:57 <r23s> I'm not adding .bbappends to BBFILES in my layer.conf
Feb 17 22:23:03 <r23s> I just have BBFILES += "${LAYERDIR}/common/recipes-*/*/*.bb"
Feb 17 22:28:51 <bluelightning> ah right, that would do it...
Feb 17 22:29:27 <bluelightning> where did you pick up that example from? (just in case it's somewhere we ought to add some kind of note)
Feb 17 22:30:07 <rewitt> If you run "yocto-layer" it sets the bbappends up as well
Feb 17 22:30:50 <r23s> bluelightning:  Yep, that did the trick.  Looks great now.
Feb 17 22:30:51 <r23s> Example?
Feb 17 22:31:52 <rewitt> The simplest would be "yocto-layer create mylayer"
Feb 17 22:32:10 <rewitt> It's not super sophisticated, but it does put he boilerplate stuff in for you
Feb 17 22:32:35 <r23s> rewitt:  Good to know.  I did it by hand this time so I'll keep that in mind going forward.
Feb 17 22:33:02 <rewitt> https://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#creating-a-general-layer-using-the-yocto-layer-script
Feb 17 22:41:08 <abelloni> bluelightning: I4m wondering whether we should document the "for layer in BBFILE_COLLECTIONS.split()" trick somewhere
Feb 17 22:41:32 <abelloni> or event include it in yocto-layer create
Feb 17 22:41:35 <abelloni> even
Feb 17 22:41:54 <abelloni> I see more and more people asking about that
Feb 17 22:43:36 <bluelightning> abelloni: for use in what context?
Feb 17 22:43:42 <abelloni> that one:
Feb 17 22:43:44 <abelloni> https://github.com/Freescale/meta-fsl-arm/blob/master/conf/layer.conf#L20
Feb 17 22:44:56 <abelloni> I see mentor is also using it
Feb 17 22:44:59 <abelloni> https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/layer.conf#L5
Feb 17 22:45:10 <abelloni> I've also included it in meta-atmel
Feb 17 22:45:25 <abelloni> to remove the hard dependency on meta-qt5
Feb 17 22:46:03 <bluelightning> ah right
Feb 17 22:46:16 <bluelightning> yes it would be worth documenting it somewhere, although it is a little bit ugly
Feb 17 22:46:40 <bluelightning> it could be that the whole collections/layers thing needs a bit of a rethink at some point
Feb 17 22:47:02 <kergoth> I still don't really like that under the hood is still the old bbpath/bbfiles crap :)
Feb 17 22:47:23 <kergoth> BBPATH/BBFILES was created by me intentionally as a temporary method, and we never really did anything about it, other than gluing more layers on top of it
Feb 17 22:47:27 <kergoth> heh
Feb 17 22:50:00 <bluelightning> yeah, it's a bit painful
Feb 17 22:50:18 <bluelightning> I mean it's super-flexible and all, but nobody really uses the flexibility it provides
Feb 17 22:50:22 * kergoth nods
Feb 17 22:51:05 <Crofton> careful, or kergoth will want to rewrite everything :)
Feb 17 22:51:09 <bluelightning> heh
Feb 17 22:51:11 * kergoth rolls eyes
Feb 17 22:51:21 <kergoth> oh hell no, i've tried to go down that rabbit hole before
Feb 17 22:51:21 <Crofton> kergoth, will you be able to make ELC/OEDAM?
Feb 17 22:51:26 <bluelightning> I guess I've been too conservative to change it up to now, but I have been thinking about it recently perhaps for the next dev cycle
Feb 17 22:51:30 <kergoth> probably, would like to
Feb 17 22:53:13 <Crofton> kergoth, I remember this from days gone by
Feb 17 22:54:34 <kergoth> I do want to try replacing bb.fetch with a standalone fetch/unpack tool at some point. that could be done piecemeal, and it'd be potentially useful even outside of bitbake, but we'll see if i ever find the gumption to actually do so :)
Feb 18 01:18:00 <Hans__> Hello
Feb 18 01:31:57 <Hans__> Hello
Feb 18 01:38:53 <HansSanitizer> Hello
**** ENDING LOGGING AT Wed Feb 18 03:00:00 2015