IRC log for #oe on 20130830

01:05.59*** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti)
01:08.01*** join/#oe zenlinux (~sgarman@c-50-139-96-211.hsd1.or.comcast.net)
01:27.02*** join/#oe W1N9Zr0 (~W1N9Zr0@24-246-93-30.cable.teksavvy.com)
01:33.02*** join/#oe liuyq (~liuyq0307@221.123.128.226)
01:35.48*** join/#oe liuyq (~liuyq0307@221.123.128.226)
01:47.30*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
02:01.55*** join/#oe silviof1 (~silviof@unaffiliated/silviof)
02:06.34kergothHmm, should look into adding sublime text highlighting for bitbake files
03:06.20mewynI keep waffling between ST and vim
03:09.57*** join/#oe GunsNRose (~GunsNRose@125.70.191.216)
03:19.48*** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net)
03:26.29*** join/#oe mwester (~mwester@184-158-81-211.dyn.centurytel.net)
03:26.30*** join/#oe mwester (~mwester@nslu2-linux/mwester)
03:27.45kergothme too
03:28.15kergothseen rsub/rmate? that's what made me really give ST another shot, since i work over ssh most of the time - https://github.com/henrikpersson/rsub
03:28.20kergothmutters
03:30.03*** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl)
03:32.45*** join/#oe KNERD (~KNERD@cpe-66-25-233-146.gt.res.rr.com)
03:36.41*** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net)
04:16.34*** join/#oe SidH_ (~SidH_@61.95.193.238)
04:19.36*** join/#oe mario-goulart (~user@email.parenteses.org)
05:14.23*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
05:25.03*** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti)
05:30.00*** join/#oe SidH_ (~SidH_@61.95.193.239)
05:52.15*** join/#oe kbart (~KBart@213.197.143.19)
05:55.24nerdboytried sublime, waffled a bit, then went back to vim
05:57.08*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
06:07.49*** join/#oe tasslehoff (~tasslehof@77.40.182.98)
06:11.25*** join/#oe zecke (~ich@p5099b351.dip0.t-ipconnect.de)
06:21.33*** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti)
06:42.44*** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net)
06:47.58*** join/#oe roxell (~roxell@c-853670d5.07-21-73746f28.cust.bredbandsbolaget.se)
06:47.59*** join/#oe roxell (~roxell@linaro/roxell)
06:49.03*** join/#oe SidH_ (~SidH_@61.95.193.238)
07:14.37*** join/#oe ant_work (~ant@host54-128-static.10-188-b.business.telecomitalia.it)
07:26.05*** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl)
07:26.12*** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de)
07:26.12*** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian)
07:29.17*** join/#oe shawn196 (~Tiberius@unaffiliated/shawn156)
07:32.05JaMaflorian: ping
07:34.46florianJaMa: good guy :)
07:41.29JaMa.. gets cookie?
07:43.05*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
07:46.32*** join/#oe xmlich02 (~imlich@2001:67c:1220:80c:88:1f9:781:6ae1)
07:47.33*** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti)
07:51.02*** join/#oe bluelightning (~paul@83.217.123.106)
07:51.02*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
07:53.32*** join/#oe ao2 (~ao2@2001:1418:117::1)
07:55.19*** join/#oe lamikr (lamikr@nat/nokia/x-nrxdwknnbkugiefq)
08:05.23tasslehoffCan I use wildcards with bitbake? I want to run cleansstate on all the qt-recipes
08:05.41bluelightningtasslehoff: I'm afraid not, no
08:05.41tasslehoffJaMa: I'm trying out the webos-ports recipes to get gles2 working :)
08:12.00bluelightningmorning all btw
08:14.31*** join/#oe SidH_ (~SidH_@61.95.193.238)
08:20.33*** join/#oe Jay7 (~jay@2.93.117.75)
08:21.02*** join/#oe silvio_l_ (~silvio@93-57-17-124.ip162.fastwebnet.it)
08:25.56*** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk)
08:35.58silvio_l_morning all
08:37.25tasslehoffJaMa: the gles2 images you use, do they have libGL.so? for some reason my testapp wants that.
08:41.50*** join/#oe blitz00 (~stefans@192.198.151.44)
08:41.50*** join/#oe blitz00 (~stefans@unaffiliated/blitz00)
09:02.12JaMatasslehoff: depends on MACHINE, e.g. maguro has only gles2 (from libhybris) qemu* have libGL from mesa
09:08.04tasslehoffJaMa: my bad. built my testapplication with libGL instead of libGLESv2...
09:11.50ndechi, where can i find a description of all variables 'operators' e.g. _prepend, _append, +=, ?=, ??=, .=, ...
09:12.19bluelightningndec: the bitbake manual
09:12.47ndeclast time i checked the bitbake manual was not quite integrated with the yocto manuals, any specific reason for that?
09:13.14bluelightningit wasn't part of the Yocto Project manual set, no
09:13.22bluelightningit's in the process of being updated though
09:13.41ndecwhere is the most up to date (online) version, then/
09:13.43ndecthen?
09:13.59bluelightningI don't know that there is an up-to-date online version of it
09:14.24bluelightningthis version whilst old is still 95% valid: http://docs.openembedded.org/bitbake/html/
09:14.49bluelightningyou can always build your own version from the source
09:15.40JaMais always reading source files for that in bitbake repository
09:15.52JaMajust because git grep works so good :)
09:16.43ndecrepo grep is even better ;-)
09:17.16ndecis there any difference between FOO_prepend = 'bar' and FOO .= 'bar'
09:17.43ndeci believe there is a difference, but i am not sure ;-)
09:23.17bluelightningyep, there is
09:23.44bluelightning.= takes effect immediately when the line is parsed
09:24.15bluelightning_prepend is deferred until after parsing
09:25.24*** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it)
09:25.28bluelightningndec: also, .= appends; the equivalent for prepending is =.
09:26.16ndecok, i got confused by .= and =., but you answered my question!
09:26.28JaMabluelightning: do you know any reason why to use _prepend/_apppend in places where .=/=. work?
09:26.56JaMabluelightning: in other words why not use .=/=., "by default" and save _prepend/_append only for special cases?
09:26.56bluelightningJaMa: historical reasons in some cases since .= / =. are quite a bit newer
09:27.04ndecso, if i really need to make sure that 'nobody' will override my variable, i should use _prepend
09:27.27ndecin my case i want to ensure some IMAGE_FSTYPES are always set, from distro.conf.
09:27.28bluelightningJaMa: worth noting as well is that .= / =. can't work in conjunction with overrides whereas _append / _prepend can
09:27.50JaMabluelightning: ah OK, makes sense, thanks, I was thinking about it because e.g. IMAGE_FSTYPES_append is hard to "override" even with IMAGE_FSTYPES_forcevariable
09:27.52bluelightningndec: that should ensure that yes
09:28.10ndecthanks!
09:28.15bluelightningJaMa: nigh-on impossible to override yes
09:29.16ndeci have another question ;-) in a BSP layer, i want to install a GST plugin (for h/w decode), so we use MACHINE_EXTRA_RDEPENDS and it works. however we would need to include that plugin only if gstreamer is there in the image already. e.g. we build images without gstreamer with the same BSP.
09:29.27JaMabluelightning: at least for DEPENDS_append = "foo" in .bbclasses I'm trying to use intermediate variable DEPENDS_FOO = "foo" which can be overriden
09:29.38ndecis that possible to have 'conditional' MACHINE_EXTRA_RDPENDS?
09:30.13JaMabluelightning: but in this case using .= won't help much, because typical case is that I want to disable extra dependency from .bbclass without overriding the rest of DEPENDS
09:31.15JaMandec: are you sure that 'nobody' won't have valid use-cases when overriding IMAGE_FSTYPES should work?
09:31.39bluelightningndec: conditional upon what in particular?
09:32.21JaMae.g. on CI server which does only build tests and nobody is expected to flash resulting images it's nice to be able to build just .tag even when DISTRO/MACHINE maintainer knows that .ext4 IMAGE_FSTYPE is really needed
09:32.35bluelightningndec: for some situations you can use overrides; otherwise you can use python expressions in the value e.g. ${@base_conditional(...)} or ${@base_contains(...)}
09:33.53ndecJaMa: everybody can add more FSTYPES if they need. but i want to enforce that all my distro users at least generate tar.gz.
09:34.07bluelightningJaMa: quite a long time ago I think there was a discussion on how to set IMAGE_FSTYPES and the outcome was we should always set it in machine configs at least using +=
09:34.30JaMabluelightning: and I agree with that conclusion
09:34.37bluelightningyep, so do I
09:34.38ndecwell, i think the problem would be with DISTRO config, which is parsed after MACHINE config.
09:34.48JaMandec: adding is simple, I'm asking about removing
09:35.22ndecwell, it's my distro , i can create my rules, no ;-)
09:35.33JaMandec: if I have local.conf which adds e.g. tar.bz2 then I really don't need .tar.gz even when your distro thinks otherwise
09:36.13ndecwell, in fact it's even for a bad reason that i need that... but our CI script rely on tar.gz to be there... i should fix the CI scripts instead ;-)
09:36.15JaMandec: true, you can do whatever you want there :) I'm just warning about that :)
09:37.14JaMawe have IMAGE_FSTYPES_append in one BSP and I'm dragging one extra patch in my local checkout just to get rid of that :)
09:38.38ndecyes, i see the problem.. let's say i will do that, but make sure to fix the CI scripts so that i can remove later!
09:41.21ndecbluelightning: so, i can use ${@base_conditional(..)} in MACHINE_EXTRA_RDEPENDS! nice. how do i query if gstreamer is pulled already?
09:41.53pb_hi all
09:42.03bluelightninghi pb_
09:42.20bluelightningndec: you can't at that level
09:44.19ndecwhen MACHINE_EXTRA_RDEPENDS is processed we don't already have access to all the packages that the image will pull?
09:44.43bluelightningno, way too early for that
09:45.38ndeccan i do RDEPENDS_gstreamer = "my gst plugin"
09:45.40bluelightningit may not be obvious but machine/distro configs get parsed really early; then later each recipe is parsed (or loaded from the cache) and then recipes that are actually going to be built are parsed again when it comes time to execute tasks from them
09:46.12bluelightningthat *might* work
09:46.35bluelightningit would have to be RDEPENDS_gstreamer_append = " mygstplugin"
09:47.12ndecok. another option would be to .bbappend gstreamer in our BSP layer, and add the RDEPENDS there.
09:47.14ndeci suppose.
09:47.20ndecbut this isn't quite nice.
09:47.51ndecdon't you believe it's a 'normal' use case to be able to add machine packages based on the image content?
09:49.06bluelightningwell bbappends for recipes are a pretty standard means of affecting a recipe in a layer
09:51.29*** join/#oe anarsoul (~anarsoul@178.124.194.242)
09:56.19ndecbluelightning: hmm,but the gst plugins will like RDEPENDS on gstreamer too. would that work ? e.g. circular RDEPENDS?
09:56.58bencohI guess (hope) opkg can resolve than kind of circdeps
09:57.44bencoh(it roughly means that you have to install both, no big stuff)
09:57.56bencoh(erm, that one can't be installed without the other)
09:58.50ndecok, i haven't tried yet, but i will ;-)
10:00.06bluelightningprobably RRECOMMENDS are more appropriate here, but I think the package manager should be able to resolve the situation
10:00.45ndecgiven that both RDEPENDS and RRECOMMENDS are always installed, is there any difference between the 2?
10:01.20bluelightningfor your case, the packages being added to RRECOMMENDS will probably always exist so there won't be a lot of difference
10:01.46bluelightningbut technically speaking RDEPENDS means "this thing will break without this other thing so it's not possible to install one without the other"
10:02.24bluelightningwhereas RRECOMMENDS is more like "this thing is useful to provide additional functionality, but if it isn't present the package will still work"
10:02.56ndecok. will try both, if they both work, we will use RRECOMENDS.
10:03.00ndecthank you!
10:42.13tasslehoffJaMa: eglfs works now, and I'm trying to test wayland. does qtwayland in webos-ports compile for you?
10:54.00JaMayes it does
11:02.26tasslehoffJaMa: hm. which toolchain? I get compile errors.
11:03.19tasslehoffhttp://pastebin.com/PKbWGLuF
11:07.05*** join/#oe acidfu (~nib@unaffiliated/acidmen)
11:09.53*** join/#oe eren (~eren@unaffiliated/eren)
11:11.11JaMatasslehoff: internal
11:11.35JaMathe paste shows only warning
11:19.12tasslehoffJaMa: ah, wrong paste http://pastebin.com/AnpD3uQ2
11:19.54JaMatasslehoff: you need also newer wayland (also in meta-webos-ports)
11:20.49tasslehoffJaMa: I brought that along, but perhaps I need set fix the preferences
11:22.33tasslehoffJaMa: "bitbake wayland" uses the wayland 1.1.0 recipe
11:31.07*** join/#oe xmlich02 (~imlich@2001:67c:1220:80c:88:1f9:781:6ae1)
11:35.52*** join/#oe roric (~roric@194-237-7-146.customer.telia.com)
11:42.33tasslehoffsame compile error with wayland 1.2.0, so that is not the issue
11:52.39tasslehoffJaMa: this is something it should get from my virtual/egl provider, it seems. in my case that is libgles-omap3, which doesn't have it.
12:00.27tasslehoffdenix: the newer sgx drivers with wayland support still don't work on omap3530, do they?
12:01.35*** join/#oe ldnunes (~ldnunes_@187.23.155.55)
12:03.16tasslehoffI'm on version 4.05.00.03 of omap3-sgx-modules/libgles-omap3
12:14.48*** join/#oe tasslehoff (~tasslehof@77.40.182.98)
12:15.06*** join/#oe hillct (~hillct@c-24-34-200-20.hsd1.ma.comcast.net)
12:16.05*** join/#oe phdeswer_ (~phdeswer@a88-113-104-180.elisa-laajakaista.fi)
12:39.43*** join/#oe acidfu (~nib@24.37.17.210)
12:39.43*** join/#oe acidfu (~nib@unaffiliated/acidmen)
13:01.21*** join/#oe tarnzwerg (~tarnzwerg@a89-182-205-157.net-htp.de)
13:08.16*** join/#oe acidfu (~nib@24.37.17.210)
13:08.16*** join/#oe acidfu (~nib@unaffiliated/acidmen)
13:09.52*** join/#oe tarnzwerg (~tarnzwerg@a89-182-198-167.net-htp.de)
13:13.05*** join/#oe c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter)
13:37.25*** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk)
13:51.56*** join/#oe _chase_ (~a0271661@nat/ti/x-godfvrkuxioutyew)
14:04.58*** join/#oe W1N9Zr0 (~W1N9Zr0@24-246-93-30.cable.teksavvy.com)
14:11.42*** join/#oe ao2 (~ao2@2001:1418:117::1)
14:41.56*** join/#oe tarnzwerg (~tarnzwerg@unaffiliated/tarnzwerg)
14:43.59*** join/#oe _chase_1 (~a0271661@nat/ti/x-ymwayumvrwkmttmd)
14:51.36*** join/#oe _chase_ (~a0271661@nat/ti/x-vydtsjputfajbkxj)
15:03.52*** join/#oe tarnzwerg (~tarnzwerg@a89-182-237-7.net-htp.de)
15:03.52*** join/#oe tarnzwerg (~tarnzwerg@unaffiliated/tarnzwerg)
15:11.33*** join/#oe Stygia (~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk)
15:12.28*** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net)
15:23.48*** join/#oe paulbarker (~pbarker@hermes.betafive.co.uk)
15:44.20*** join/#oe c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter)
15:46.15*** join/#oe zenlinux_ (~sgarman@c-76-115-130-34.hsd1.or.comcast.net)
15:46.29*** join/#oe dos11 (~dos@unaffiliated/dos1)
15:51.06*** join/#oe c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter)
15:54.51*** join/#oe nitink (~nitink@134.134.139.70)
16:29.47*** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029)
16:47.07*** part/#oe _chase_ (~a0271661@nat/ti/x-vydtsjputfajbkxj)
17:19.44*** join/#oe _chase_ (~a0271661@nat/ti/x-aknjzpndlbamvbrt)
17:29.39*** join/#oe acidfu (~nib@24.37.17.210)
17:29.39*** join/#oe acidfu (~nib@unaffiliated/acidmen)
17:51.48*** join/#oe zecke (~ich@91-65-247-193-dynip.superkabel.de)
17:52.03*** join/#oe eren (~eren@unaffiliated/eren)
18:00.43*** join/#oe galak (~galak@67.78.66.82)
18:14.09*** join/#oe NightMonkey (~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net)
18:14.09*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
18:18.01*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
18:42.28*** join/#oe dos11 (~dos@unaffiliated/dos1)
18:43.00*** join/#oe dos11 (~dos@unaffiliated/dos1)
19:03.09*** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net)
19:31.58*** join/#oe erbo (~erik@host.62.65.125.245.bitcom.se)
20:12.14*** join/#oe kristoffer (~kristoffe@c-1ad8e555.010-30-6c6b7012.cust.bredbandsbolaget.se)
20:18.47*** join/#oe ant_home (~andrea@host128-146-dynamic.30-79-r.retail.telecomitalia.it)
20:32.03*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
20:45.09*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
20:47.14*** join/#oe bluelightning (~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com)
20:47.14*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
20:51.00*** join/#oe jmpdelos (~polk@174-22-171-174.clsp.qwest.net)
20:57.22*** part/#oe eval- (~stephan@pool-100-1-110-92.nwrknj.fios.verizon.net)
21:08.31*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
21:22.39*** join/#oe c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter)
21:32.26*** join/#oe espiral (~maze@unaffiliated/espiral)
21:43.29*** join/#oe bazbell (~a0192809@adsl-99-142-27-169.dsl.emhril.sbcglobal.net)
22:21.57*** join/#oe KNERD (~KNERD@cpe-66-25-233-146.gt.res.rr.com)
22:25.42*** join/#oe shawn196 (~Tiberius@unaffiliated/shawn156)
23:03.44*** join/#oe bazbell (~a0192809@adsl-99-142-27-169.dsl.emhril.sbcglobal.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.