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.34 | kergoth | Hmm, should look into adding sublime text highlighting for bitbake files |
03:06.20 | mewyn | I 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.45 | kergoth | me too |
03:28.15 | kergoth | seen 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.20 | kergoth | mutters |
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.24 | nerdboy | tried 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.05 | JaMa | florian: ping |
07:34.46 | florian | JaMa: good guy :) |
07:41.29 | JaMa | .. 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.23 | tasslehoff | Can I use wildcards with bitbake? I want to run cleansstate on all the qt-recipes |
08:05.41 | bluelightning | tasslehoff: I'm afraid not, no |
08:05.41 | tasslehoff | JaMa: I'm trying out the webos-ports recipes to get gles2 working :) |
08:12.00 | bluelightning | morning 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.58 | silvio_l_ | morning all |
08:37.25 | tasslehoff | JaMa: 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.12 | JaMa | tasslehoff: depends on MACHINE, e.g. maguro has only gles2 (from libhybris) qemu* have libGL from mesa |
09:08.04 | tasslehoff | JaMa: my bad. built my testapplication with libGL instead of libGLESv2... |
09:11.50 | ndec | hi, where can i find a description of all variables 'operators' e.g. _prepend, _append, +=, ?=, ??=, .=, ... |
09:12.19 | bluelightning | ndec: the bitbake manual |
09:12.47 | ndec | last time i checked the bitbake manual was not quite integrated with the yocto manuals, any specific reason for that? |
09:13.14 | bluelightning | it wasn't part of the Yocto Project manual set, no |
09:13.22 | bluelightning | it's in the process of being updated though |
09:13.41 | ndec | where is the most up to date (online) version, then/ |
09:13.43 | ndec | then? |
09:13.59 | bluelightning | I don't know that there is an up-to-date online version of it |
09:14.24 | bluelightning | this version whilst old is still 95% valid: http://docs.openembedded.org/bitbake/html/ |
09:14.49 | bluelightning | you can always build your own version from the source |
09:15.40 | JaMa | is always reading source files for that in bitbake repository |
09:15.52 | JaMa | just because git grep works so good :) |
09:16.43 | ndec | repo grep is even better ;-) |
09:17.16 | ndec | is there any difference between FOO_prepend = 'bar' and FOO .= 'bar' |
09:17.43 | ndec | i believe there is a difference, but i am not sure ;-) |
09:23.17 | bluelightning | yep, there is |
09:23.44 | bluelightning | .= takes effect immediately when the line is parsed |
09:24.15 | bluelightning | _prepend is deferred until after parsing |
09:25.24 | *** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it) |
09:25.28 | bluelightning | ndec: also, .= appends; the equivalent for prepending is =. |
09:26.16 | ndec | ok, i got confused by .= and =., but you answered my question! |
09:26.28 | JaMa | bluelightning: do you know any reason why to use _prepend/_apppend in places where .=/=. work? |
09:26.56 | JaMa | bluelightning: in other words why not use .=/=., "by default" and save _prepend/_append only for special cases? |
09:26.56 | bluelightning | JaMa: historical reasons in some cases since .= / =. are quite a bit newer |
09:27.04 | ndec | so, if i really need to make sure that 'nobody' will override my variable, i should use _prepend |
09:27.27 | ndec | in my case i want to ensure some IMAGE_FSTYPES are always set, from distro.conf. |
09:27.28 | bluelightning | JaMa: worth noting as well is that .= / =. can't work in conjunction with overrides whereas _append / _prepend can |
09:27.50 | JaMa | bluelightning: 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.52 | bluelightning | ndec: that should ensure that yes |
09:28.10 | ndec | thanks! |
09:28.15 | bluelightning | JaMa: nigh-on impossible to override yes |
09:29.16 | ndec | i 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.27 | JaMa | bluelightning: at least for DEPENDS_append = "foo" in .bbclasses I'm trying to use intermediate variable DEPENDS_FOO = "foo" which can be overriden |
09:29.38 | ndec | is that possible to have 'conditional' MACHINE_EXTRA_RDPENDS? |
09:30.13 | JaMa | bluelightning: 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.15 | JaMa | ndec: are you sure that 'nobody' won't have valid use-cases when overriding IMAGE_FSTYPES should work? |
09:31.39 | bluelightning | ndec: conditional upon what in particular? |
09:32.21 | JaMa | e.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.35 | bluelightning | ndec: 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.53 | ndec | JaMa: 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.07 | bluelightning | JaMa: 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.30 | JaMa | bluelightning: and I agree with that conclusion |
09:34.37 | bluelightning | yep, so do I |
09:34.38 | ndec | well, i think the problem would be with DISTRO config, which is parsed after MACHINE config. |
09:34.48 | JaMa | ndec: adding is simple, I'm asking about removing |
09:35.22 | ndec | well, it's my distro , i can create my rules, no ;-) |
09:35.33 | JaMa | ndec: 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.13 | ndec | well, 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.15 | JaMa | ndec: true, you can do whatever you want there :) I'm just warning about that :) |
09:37.14 | JaMa | we 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.38 | ndec | yes, 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.21 | ndec | bluelightning: so, i can use ${@base_conditional(..)} in MACHINE_EXTRA_RDEPENDS! nice. how do i query if gstreamer is pulled already? |
09:41.53 | pb_ | hi all |
09:42.03 | bluelightning | hi pb_ |
09:42.20 | bluelightning | ndec: you can't at that level |
09:44.19 | ndec | when MACHINE_EXTRA_RDEPENDS is processed we don't already have access to all the packages that the image will pull? |
09:44.43 | bluelightning | no, way too early for that |
09:45.38 | ndec | can i do RDEPENDS_gstreamer = "my gst plugin" |
09:45.40 | bluelightning | it 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.12 | bluelightning | that *might* work |
09:46.35 | bluelightning | it would have to be RDEPENDS_gstreamer_append = " mygstplugin" |
09:47.12 | ndec | ok. another option would be to .bbappend gstreamer in our BSP layer, and add the RDEPENDS there. |
09:47.14 | ndec | i suppose. |
09:47.20 | ndec | but this isn't quite nice. |
09:47.51 | ndec | don't you believe it's a 'normal' use case to be able to add machine packages based on the image content? |
09:49.06 | bluelightning | well 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.19 | ndec | bluelightning: hmm,but the gst plugins will like RDEPENDS on gstreamer too. would that work ? e.g. circular RDEPENDS? |
09:56.58 | bencoh | I guess (hope) opkg can resolve than kind of circdeps |
09:57.44 | bencoh | (it roughly means that you have to install both, no big stuff) |
09:57.56 | bencoh | (erm, that one can't be installed without the other) |
09:58.50 | ndec | ok, i haven't tried yet, but i will ;-) |
10:00.06 | bluelightning | probably RRECOMMENDS are more appropriate here, but I think the package manager should be able to resolve the situation |
10:00.45 | ndec | given that both RDEPENDS and RRECOMMENDS are always installed, is there any difference between the 2? |
10:01.20 | bluelightning | for your case, the packages being added to RRECOMMENDS will probably always exist so there won't be a lot of difference |
10:01.46 | bluelightning | but 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.24 | bluelightning | whereas 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.56 | ndec | ok. will try both, if they both work, we will use RRECOMENDS. |
10:03.00 | ndec | thank you! |
10:42.13 | tasslehoff | JaMa: eglfs works now, and I'm trying to test wayland. does qtwayland in webos-ports compile for you? |
10:54.00 | JaMa | yes it does |
11:02.26 | tasslehoff | JaMa: hm. which toolchain? I get compile errors. |
11:03.19 | tasslehoff | http://pastebin.com/PKbWGLuF |
11:07.05 | *** join/#oe acidfu (~nib@unaffiliated/acidmen) |
11:09.53 | *** join/#oe eren (~eren@unaffiliated/eren) |
11:11.11 | JaMa | tasslehoff: internal |
11:11.35 | JaMa | the paste shows only warning |
11:19.12 | tasslehoff | JaMa: ah, wrong paste http://pastebin.com/AnpD3uQ2 |
11:19.54 | JaMa | tasslehoff: you need also newer wayland (also in meta-webos-ports) |
11:20.49 | tasslehoff | JaMa: I brought that along, but perhaps I need set fix the preferences |
11:22.33 | tasslehoff | JaMa: "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.33 | tasslehoff | same compile error with wayland 1.2.0, so that is not the issue |
11:52.39 | tasslehoff | JaMa: 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.27 | tasslehoff | denix: 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.16 | tasslehoff | I'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) |