**** BEGIN LOGGING AT Mon Jul 28 03:00:01 2014
Jul 28 07:30:50 <mckoan> good morning
Jul 28 07:33:16 <woglinde> hi mckoan
Jul 28 07:33:52 <mckoan> hi woglinde 
Jul 28 07:34:16 <hrw> hi guys
Jul 28 07:46:59 <woglinde> hi hrw long time not seen
Jul 28 07:47:08 <hrw> woglinde: 3 weeks of vacations
Jul 28 07:54:46 <woglinde> hi shoragan
Jul 28 07:54:55 <shoragan> hi woglinde :)
Jul 28 08:00:00 <pompomJuice> Hi everyone
Jul 28 08:00:18 <pompomJuice> I was hoping someone would be able to help me with a systemd log output issue
Jul 28 08:01:06 <woglinde> pompomJuice whats up?
Jul 28 08:01:08 <pompomJuice> an in house c program suddenlly started to only produce logs at teardown at the end... 
Jul 28 08:01:24 <woglinde> fix the c program
Jul 28 08:01:31 <pompomJuice> must it flush every time?
Jul 28 08:02:50 <pompomJuice> I broke it when I added bitbake buildvars to the recipy, something that was missing
Jul 28 08:03:18 <woglinde> ?
Jul 28 08:03:18 <pompomJuice> I was wondering what the cause is, -O2?
Jul 28 08:03:28 <woglinde> look at the source
Jul 28 08:03:33 <pompomJuice> we have one c program
Jul 28 08:03:41 <pompomJuice> and between 1.3 and 1.6 it broke badly
Jul 28 08:03:43 <woglinde> all other is like searchin needles in haystacks
Jul 28 08:04:05 <woglinde> pompomJuice are you logging via journald?
Jul 28 08:04:15 <pompomJuice> motly because of going from linaro 4.3.1 4.8
Jul 28 08:04:25 <pompomJuice> The app is started via systemd
Jul 28 08:04:38 <pompomJuice> cplusplus
Jul 28 08:04:59 <pompomJuice> basically what happned
Jul 28 08:05:11 <pompomJuice> I had to upgrade mode
Jul 28 08:05:18 <pompomJuice> I had to upgrade mono*
Jul 28 08:05:27 <pompomJuice> mono required a 4.7 compiler
Jul 28 08:05:31 <pompomJuice> chain reaction
Jul 28 08:05:39 <pompomJuice> yocto 1.3 to 1.6
Jul 28 08:06:01 <pompomJuice> everytihng works like it did before, except our one c++ back end app
Jul 28 08:06:19 <pompomJuice> it got totally screwed
Jul 28 08:06:33 <pompomJuice> cant do shared mem with the DSP no more
Jul 28 08:06:45 <pompomJuice> (fun bus errors)
Jul 28 08:07:08 <pompomJuice> and
Jul 28 08:07:11 <pompomJuice> other strange things
Jul 28 08:07:15 <pompomJuice> such as bus errors
Jul 28 08:07:23 <pompomJuice> but then you touch the variables with dummy ones
Jul 28 08:07:30 <pompomJuice> then everything works
Jul 28 08:07:42 <pompomJuice> I am a developer
Jul 28 08:07:51 <pompomJuice> not python
Jul 28 08:07:59 <pompomJuice> I know what is going on there
Jul 28 08:08:02 <pompomJuice> it got messed up
Jul 28 08:08:15 <pompomJuice> one other thing that messed is the output
Jul 28 08:08:22 <pompomJuice> it only happens when the program dies
Jul 28 08:08:35 <pompomJuice> anyway
Jul 28 08:22:13 <ant_work> there is a recent linux rant against gcc4.9 fwiw
Jul 28 08:23:09 <ant_work> screaming Linus I meant ;)
Jul 28 08:27:32 <koen> ant_work: and it turns out the bug was introduced in 4.5 :)
Jul 28 08:28:24 <ant_work> koen: guess what? linux-yocto 3.16 has some issues on arm not present with vanilla 3.16 :/
Jul 28 08:29:01 <ant_work>  pxa2xx-spi: probe of pxa2xx-spi.1 failed with error -2
Jul 28 08:29:23 <ant_work> only the yocto kernel, same toolchain and same defconfig...
Jul 28 08:30:26 <ant_work> I've built -rc5, -rc6 and -rc7 and all can probe spi
Jul 28 08:32:07 <ant_work> worth rebuilding with gcc4.8 ?
Jul 28 08:34:02 <koen> only one way to find out :)
Jul 28 08:34:23 <ant_work> actually I was thinking about pestering Bruce ;)
Jul 28 08:36:11 <mago__> my recipe has a certain file (a.txt) in its SRC_URI, and this file is provided by the layer that hold my recipe. Is it possible for another layer to replace a.txt? E.g by creating a .bbappend file and specifying a second a.txt? What will happen if SRC_URI contains 2 a.txt entries?
Jul 28 08:36:42 <pompomJuice> oh my
Jul 28 08:36:51 * ajtag is away: Away
Jul 28 08:47:01 <bluelightning> morning all
Jul 28 08:47:24 <mago__> morning bluelightning 
Jul 28 08:47:29 <bluelightning> morning mago__
Jul 28 08:51:19 <woglinde> hi bluelightning
Jul 28 08:52:16 <koen> (sigh*
Jul 28 08:52:22 <koen> fucking morons sending patches
Jul 28 08:53:03 <koen> and worse, the patches get applied
Jul 28 08:53:31 <bluelightning> koen: what's happened?
Jul 28 08:53:34 <ant_work> O.O
Jul 28 08:53:42 <koen> bluelightning: alsa-dev -> alsa-lib-dev
Jul 28 08:53:49 <koen> I don't get why that had to change
Jul 28 08:54:00 <koen> but ignoring that, no upgrade path
Jul 28 08:54:17 <koen> and Jackies reply is infuriating
Jul 28 08:55:08 <dv_> is there a problem if I set gcc to 4.8 again in tcmode-default.inc ?
Jul 28 08:55:12 <dv_> even in the current master?
Jul 28 08:55:32 <dv_> chromium simply does not work with gcc 4.9. chromium 35 crashes all the time, and 37 does not even build. ICEs all over the place.
Jul 28 08:55:46 <bencoh> bleh
Jul 28 08:56:06 <bluelightning> dv_: I wouldn't expect changing that to be a problem; though I don't know if you'd need to throw away your TMPDIR afterwards
Jul 28 08:56:20 <dv_> bluelightning: thats okay, I would do a fresh rebuild anyway
Jul 28 08:57:03 * ajtag is back (gone 00:20:12)
Jul 28 08:58:37 <pompomJuice> anyone have a link to this gcc bug discussion?
Jul 28 08:58:43 <pompomJuice> where do you get this kind of news?
Jul 28 08:59:09 <dv_> I didn't. I have been building it on my box.
Jul 28 08:59:14 <dv_> and thats where I saw the problems.
Jul 28 08:59:25 * dv_ is preparing new chromium 37 recipes as well
Jul 28 09:02:53 <ant_work> pompomJuice: this is the most colorful
Jul 28 09:02:54 <ant_work> https://lkml.org/lkml/2014/7/24/584
Jul 28 09:05:46 <pompomJuice> ha thanks
Jul 28 09:05:46 <ant_work> there is already a patch in 3.16-rc7
Jul 28 09:05:47 <bencoh> aww, true linus rant :)
Jul 28 09:05:47 <ant_work> insane, broken, $hit, it's Linus !
Jul 28 09:05:47 <bencoh> :)
Jul 28 09:05:47 <ant_work> forgot the "hard and harsh"
Jul 28 09:05:57 <ant_work> *I* forgot to mention, words are there
Jul 28 09:06:07 <pompomJuice> that was hilarious
Jul 28 09:06:09 <pompomJuice> he goes off
Jul 28 09:07:30 <ant_work> much more polite in the release-notes of -rc7
Jul 28 09:07:45 <bencoh> :)
Jul 28 09:08:01 <dv_> well he cooled off at this point
Jul 28 09:08:09 <dv_> I wonder if my problems are related to what he reports
Jul 28 09:08:11 <bencoh> anyway, that's a .0 gcc release, so ...
Jul 28 09:08:16 <dv_> yeah
Jul 28 09:08:17 <bencoh> expect troubles :)
Jul 28 09:08:51 <dv_> he mentions its because of the red zone, but also notices that the produced code exceeds that red zone (136 > 128)
Jul 28 09:09:08 <dv_> and that could affect user space stuff as well perhaps
Jul 28 09:09:28 <bluelightning> I understood that bug got fixed in upstream gcc already...
Jul 28 09:15:16 <pompomJuice> how do I get the fix
Jul 28 09:15:30 <pompomJuice> I am on yocto 1.6 on oe
Jul 28 09:15:37 <pompomJuice> can I just oebb update poof
Jul 28 09:15:51 <pompomJuice> btw
Jul 28 09:16:48 <pompomJuice> oe needs a split system for sources.txt so that I can add my company layer without having to cause conflicts in sources.txt. I also remove a lot of layers since we don't use them... those cause more conflicts
Jul 28 09:19:15 <bluelightning> pompomJuice: that script is part of angstrom rather than OE
Jul 28 09:21:06 <pompomJuice> aah
Jul 28 09:21:13 <pompomJuice> I thought it was oe
Jul 28 09:21:17 <pompomJuice> take it slow
Jul 28 09:51:19 <mago__> is it possible to override a SRC_URI file in a recipe using a .bbappend file?
Jul 28 09:54:12 <dv_> you mean, remove or modify an entry in the SRC_URI list?
Jul 28 09:55:17 <mago__> well, i do not want to remove/modify the SRC_URI entry itself, i want to modify the contents of a certain file. And I figured the best way to do that would be to provide a new version of that file, using a .bbappend file somehow
Jul 28 09:56:10 <mago__> basically my problem is this: when my u-boot builds, it needs hardware specific files. The recipie provides generic hardware files, but if someone wants to build a custom design, they need a way to override the generic files and provide their own versions of these files
Jul 28 09:58:05 <bluelightning> yes, you can provide a different version of a local file referred to in SRC_URI in the recipe using a bbappend; or add additional files to SRC_URI
Jul 28 09:58:22 <bluelightning> you just need to prepend to FILESEXTRAPATHS so that the system can find your files
Jul 28 09:58:46 <bluelightning> i.e. FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Jul 28 09:59:21 <bluelightning> and then put your replacement file(s) in a directory named the same as the recipe (the name part of it) next to the bbappend
Jul 28 10:26:18 <mago__> bluelightning, cool! thank you
Jul 28 10:27:15 <bluelightning> np
Jul 28 11:51:29 <ensc|w> when I have SRC_URI = "file:///some-local/path/with/a/file.txt", how can I force bitbake to store 'file.txt' directly into ${WORKDIR}/ instead of ${WORKDIR}/some-local/path/with/a/ ?
Jul 28 11:56:39 <bluelightning> ensc|w: you could try adding a subdir= parameter
Jul 28 11:57:26 <bluelightning> although that's not really a use case we try to support
Jul 28 11:59:35 <ensc|w> bluelightning: 'subdir' is not supported for file:// afais
Jul 28 12:04:49 <ensc|w> gzip'ping the file and forcing 'unpack' operation hence is a quick workaround but hacky
Jul 28 13:21:18 <mago__> what are people using for image deployment? i found this "swupdate" project that comes with OE layers (meta-swupdate), anyone tried it?
Jul 28 14:45:51 <lct_> Does anyone know anything about the curl recipe? I am trying to get it to use cyassl instead of gnutls, but I can't seem to get my bbappend to do what  I need it to...
Jul 28 14:55:56 <kroon> lct_, what kind of problem do you have ?
Jul 28 14:57:05 <lct_> when I do it with the normal curl (gnutls) recipe and compare results using wireshark with the one where I use --with-cyassl, they are identical
Jul 28 14:57:19 <lct_> when I run my image*
Jul 28 14:58:35 <kroon> lct_, have you checked in the log files that youre passing the correct flags to curl's configure script ?
Jul 28 14:59:23 <lct_> I have not. I was using curl_7.36.0.bb which might also have been a problem since there were cyassl problems with that version . 
Jul 28 14:59:59 <lct_> I am not the most well versed in oe recipes, so I would not know much about what the flags mean or which ones to pass...
Jul 28 15:00:29 <kroon> lct_, try looking at the output from "bitbake -e curl". That will dump all OE variables
Jul 28 15:00:54 <kroon> lct_, in particular look at EXTRA_OECONF
Jul 28 15:01:59 <lct_> Ok, thanks, I have a new error now trying to update poky to use the new version of curl. I will check in EXTRA_OECONF output (that is where I was making my edits in the recipe)
Jul 28 17:09:11 <beshelto> q
Jul 28 17:09:12 <beshelto> exit
Jul 28 17:51:58 <dca> hi guys. how to finght with ERROR: Nothing PROVIDES 'wayland-egl' error?
Jul 28 18:00:27 <khem> dca: may be you do not have recipes which provide it or may be the layer is not included in your setup that provides it
Jul 28 18:47:15 <rburton> dca: what depends on that? nothing in oe-core depends or provides that (although mesa builds a libwayland-egl library)
Jul 28 22:25:32 <awozniak> I'm working on a small embedded device, and want to do configuration via web pages.  I'm imagining some static html, and maybe some perl cgi to do the work.  What's the web server of choice for oe these days?
Jul 28 22:50:08 <khem> awozniak: you have choices
Jul 28 22:50:27 <awozniak> khem: of that I am certain. =)
Jul 28 22:51:02 <khem> look into meta-webserver 
Jul 28 22:51:19 <khem> http://layers.openembedded.org/layerindex/branch/master/layer/meta-webserver/
Jul 28 22:51:35 <khem> you have cherokee, nginx also
Jul 28 22:52:24 <khem> and oe-core also had lighttpd
Jul 28 22:52:37 <awozniak> What's your favorite, and why?
Jul 28 22:53:06 <khem> depending on device I like nginx if system is small and limited in resources
Jul 28 22:53:13 <khem> and cherokee as well
Jul 28 22:53:42 <khem> havent used lighttpd much myself but its quite fast and resource frugal as well
Jul 28 22:54:24 <khem> apache is easiest to configure since you will find so much help on web on apache 
Jul 28 22:54:31 <khem> but it needs resources
Jul 28 22:56:39 <awozniak> awesome, thank you.  I've used lighttpd in the past.
**** ENDING LOGGING AT Tue Jul 29 03:00:00 2014