**** BEGIN LOGGING AT Mon Jul 28 03:00:01 2014 Jul 28 07:30:52 good morning Jul 28 07:55:46 good morning.. I would like to re-ask my question on Friday: hmm, where can I find the x86_64 gdb on the host in the yocto environment that can debug the arm binary of mine on the host? tried to use my own arm gdb, but that does not seem to be compatible with the gdbserver Yocto generates. Jul 28 08:06:08 lpapp: gdb-cross? Jul 28 08:06:36 I do not have that in the output of ls ./tmp/work/armv5te-foo-linux-gnueabi/ Jul 28 08:07:32 packages-split says: gdb gdb-dbg gdb-dev gdb-doc gdb-locale gdb-staticdev gdb.shlibdeps gdbserver gdbserver.shlibdeps Jul 28 08:07:39 this is not an armv5te binary Jul 28 08:07:49 fair enough.. Jul 28 08:07:51 runs on say x86 Jul 28 08:09:30 ant_work: seems that I do not have it in ls ./tmp/work/x86_64-linux/ either, only gdbm there, but I think that is not related. Jul 28 08:10:53 what happens if you bitbake gdb-cross ? Jul 28 08:11:11 yeah, I have just run that. Jul 28 08:11:19 I will let you know, thanks. Jul 28 08:12:45 seems it is getting into the arm directory: ./tmp/work/armv5te-foo-linux-gnueabi/gdb-cross Jul 28 08:13:31 is that a bug? Jul 28 08:13:48 (or is it intentional?) Jul 28 08:18:59 it is ok, is now in your sysroot as arm-...-gdb Jul 28 08:19:09 (sry, on phone call) Jul 28 08:23:57 thanks; as a side note, it would be awesome to get cgdb into Yocto :-) Jul 28 08:24:14 plain gdb is not so nice because you cannot see the code in the console simultaneously. Jul 28 08:36:49 * ajtag is away: Away Jul 28 08:46:59 morning all Jul 28 08:47:16 bluelightning: good morning Jul 28 08:47:24 morning lpapp Jul 28 08:49:28 why, oh why do i have the desire now to crank up "ride the lightning" here at office? Jul 28 08:50:42 haha Jul 28 08:50:55 (no offense meant) Jul 28 08:53:07 LetoThe2nd: none taken :) Jul 28 08:54:25 * LetoThe2nd considers some headbanging now. Jul 28 08:57:01 * ajtag is back (gone 00:20:12) Jul 28 14:12:34 looks like a silent day... Let me break that: why is it so that some do_configure task does not show the "full" configure.log by which I mean, I see it stopped in the middle without further progress and errors... Jul 28 14:14:06 e.g. I see three failing tasks there, but their do_configure task files are like that described above: http://paste.kde.org/pafj3kxgf Jul 28 14:17:33 pastebin the logs that stop? Jul 28 14:29:14 rburton: I will give it in approximately 1-2 hours when the build gets there again. Jul 28 14:55:40 So, I've been in this channel a few times the last two weeks talking about how I'm working up Yocto support the NVidia Tegra "Jetson TK1" board. I gotta' say that Yocto is truly incredible, and that you guys have been very helpful. Jul 28 14:55:57 I can see this being a pretty big source of contracting opportunities in the future. :) Jul 28 14:56:27 The only thing I can't do at this point is get anything cortex-a15'ish to run in Qemu. But that's not a yocto problem. Jul 28 14:57:59 I did have one last question, though! My BSP requires "xserver-xorg-module-libwfb" to function, and I'd like to make this a dependency in my board/bsp layer somehow. Right now, I just add it to IMAGE_INSTALL, but this feels wrong from a design standpoint. Jul 28 14:58:06 Any recommendations? Jul 28 14:59:43 out of curiosity from a noob: why is it wrong? Jul 28 15:01:38 cubicool: wfb? really? well, that dependency should be added to the driver package. Jul 28 15:03:46 rburton: There is binary-only driver from NVidia driver I have to use. Jul 28 15:03:53 rburton: It needs xinerama and libfwb. Jul 28 15:04:03 so in your recipe that packages that up, add those dependenies Jul 28 15:04:20 xinerama was easy to add with a .bbappend file to OE_EXTRACONF... Jul 28 15:04:51 rburton: I added it to the recipe that generates the image, but that feels wrong to me. Jul 28 15:05:00 I feel like it should go in the meta-jetson-tk1 layer I'm making. Jul 28 15:05:08 presumably you have a recipe for the binary driver? Jul 28 15:05:15 (This is all open source, btw; can I submit it to Yocto?) Jul 28 15:05:34 cubicool: (yes) Jul 28 15:05:39 rburton: Not currently, actually. I just have some infrastructure scripts that run their script called: ./flash.sh Jul 28 15:05:59 cubicool: ouch. well, make a recipe that grabs their stuff and puts it in the right places to make a proper package Jul 28 15:06:19 rburton: I started, but the client was pushy. I'm ordering myself a Jetson, and will definitely do that. Jul 28 15:06:27 eg http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.18.bb is the "turn a binary driver into a proper package" for Intel's EMGD driver Jul 28 15:06:38 OH GOD I HATE THAT DRIVER. Jul 28 15:06:40 when you have a proper package, you can add its runtime dependencies Jul 28 15:06:56 good news! emgd on atom is dead. Jul 28 15:07:00 We had some machine with that, what was it called back then... ummm... some tablets... Jul 28 15:07:03 It had another name. Jul 28 15:07:12 That became satanic around the office here. Jul 28 15:07:19 IEGD, EMGD, .... Jul 28 15:07:19 yeah it does that Jul 28 15:07:26 No, no, wait, I must know now! Jul 28 15:07:56 hooray that *most* new atoms are all intel 965 derivs Jul 28 15:08:42 POULSBO! Jul 28 15:08:47 OH MAN! Jul 28 15:08:51 THE DEVIL ITSELF! Jul 28 15:09:16 Manifested in software/firmware form... Jul 28 15:09:35 haha Jul 28 15:10:15 And my Haswell on my Lenovo T440 is actually great. Jul 28 15:10:26 same gpu (sort of) in the current atoms! :) Jul 28 15:10:53 I'll start with pusblishing the OSS bits of this Jetson TK1 file on github. Can you look at it later, rburton? Jul 28 15:11:09 not me, i'm on holiday for 10 days in … two hours. Jul 28 15:11:09 Just to give me reccomedations before proper submissoin. Jul 28 15:11:29 Er, layers I mean. Okay, later then. Jul 28 15:11:35 start with pushing to github and pinging the yocto and oe-devel lists for review Jul 28 15:29:45 hey guy Jul 28 15:29:46 s Jul 28 15:31:19 Sup. Jul 28 15:35:16 I have a problem with installing wine to yocto. I'v written a standard recipe like my other working ones, just with are src file tar.bz2 and nothing fancy, but when I add this layer to my bblayers.conf and add wine with IMAGE_INSTALL_append = " wine" or with CORE_IMAGE_EXTRA_INSTALL +="wine" to my local.conf . there is an error : Nothing RPROVIDES 'wine' , but..... Jul 28 15:35:32 Complete Error: ERROR: Nothing RPROVIDES 'wine' (but /home/user/yocto/poky/meta/recipes-core/images/core-image-base.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'wine' is unbuildable, removing... Missing or unbuildable dependency chain was: ['wine'] Jul 28 15:36:00 is there a basic mistake I make or something more complex ? Jul 28 15:36:12 insufficient information to say Jul 28 15:36:38 motzer: usually thats because your recipe doesn't actually produce the package you're asking for Jul 28 15:37:02 have a look at what packages your wine recipe is actually building Jul 28 15:37:30 I just inherent autotools after setting the loaction of the sources Jul 28 15:37:46 I store them local in files/ Jul 28 15:38:16 presumably wine uses autotools so you're actually configuring/building/installing? Jul 28 15:38:29 again, check what is actually being produced. Jul 28 15:38:51 I like how your username is user. Jul 28 15:38:56 Very meta. Jul 28 15:39:32 where can I check it ? I just added a few recipes the same way just giving the sources and inherent autotools everything worked fine, I do not see the difference between these cases Jul 28 15:40:21 and when my other images were bitbaked it configured compiled and did packages but now it stops after parsing the recipes Jul 28 15:40:28 motzer: the different is maybe wine doesn't actually use autotools. have a look at the wine sources. Jul 28 15:41:25 to see what packages a build produced look in tmp/work/[machine]/wine/[version]/deploy-[package format] Jul 28 15:41:33 nothing in there -> no packages were build Jul 28 15:42:09 also make sure that S actually points to the extracted sources and not an empty directory. both base and autotools are still oddly tolerant of the 'do nothing' case :) Jul 28 15:42:35 they'll happily see that ther'es no makefile and no configure script and just continue on their merry way to the next taks Jul 28 15:42:49 kergoth S is set to the right source Jul 28 15:43:02 but thanks fot the hint that there is no error coming up Jul 28 15:43:32 rburton: I cant find any package Jul 28 15:43:36 so there was nothing build Jul 28 15:44:03 motzer: i bet wine doesn't use autotools Jul 28 15:44:10 so your recipe didnt actually do anything Jul 28 15:44:16 * rburton ->cook dinner for kids Jul 28 15:44:23 okay Jul 28 15:44:27 wine does use autotools Jul 28 15:44:35 i try to find out if it uses autotools Jul 28 15:44:37 assuming you're talking about the windows emulation project Jul 28 15:44:48 yes i Jul 28 15:45:31 have to run a x86 dll for a seed and key thing Jul 28 15:45:42 so i emulate wine in qemu Jul 28 15:46:40 and execute a little commandline tool which gives me the key, not the nice way but right now there was no other way, I got that working with debian, and now I want to build a custom yocto for me Jul 28 15:46:56 qemu is running just with my basic recipe I use all the time with autotools Jul 28 15:47:52 Hi folks - quick question: in the context of a recipe that is compiling, are there environment variables that point to the host and target sysroot directories? Jul 28 15:48:21 read bitbake.conf Jul 28 15:48:38 wotte: specifically STAGING_* Jul 28 15:48:42 the last piece is wine, but it seems that it does not use autotools, so I conclude for me that I have to write my onw do_configure do_compile functions ? Jul 28 15:49:40 I just told you that wine does use autotools Jul 28 15:49:41 bluelightning: what confuses me is that I have to add export STAGING_INCDIR + STAGING_LIBDIR in a lot of cases. I would assume autotools trys will skip the host systems include dirs by default Jul 28 15:49:59 thanke kergoth bluelighting, I'll take a look Jul 28 15:50:10 http://source.winehq.org/git/wine.git/blob/HEAD:/configure.ac Jul 28 15:50:49 kergoth: okay seems to be a good message that wine uses autotools Jul 28 15:51:07 volker-: I'm no expert, but I would imagine having to use those explicitly a lot is probably bad. Is your recipe anywhere public showing the usage? Jul 28 15:51:25 but when I use autotools in my recipe there pops up this error Jul 28 15:51:29 cubicool: nope. internal tool. no ./configure, just make Jul 28 15:51:39 volker-: we explicitly tell autotools where to look, in most cases that's enough Jul 28 15:52:17 volker-: you should make sure the buildsystem in question obeys vars like CFLAGS, LDFLAGS, etc, and then it shouldn't need the explicit staging vars. but if it did, it could be passed in explicitly via EXTRA_OEMAKE rather thane xporting to the environment Jul 28 15:55:05 kergoth: there is a makefile and configure file aswell included in the sources of wine. I used the right checksum for the LICENSE file and S points to the right directory, what else can i change ? Jul 28 15:55:35 motzer: as i just told you, read the task logs and see what it's doing Jul 28 15:57:11 kergoth: how would i do this? EXTRA_OEMAKE='LIBDIR="$STAGING_LIBDIR" INCDIR="STAGING_INCDIR"'? Jul 28 15:58:34 again, if it's obeying our normal variables, there's really no need for it to use the explicit library or include paths directly at all.. but you should look at example uses of EXTRA_OEMAKE. our default value of EXTRA_OEMAKE is what causes the buildsystem to obey our env vars in preference to the vars in the file. if you override the default, you'll have to explicitly pass *everything* in, CC, CFLAGS, LDFLAGS, etc. which may well be for the best. Jul 28 15:58:34 otherwise you can += to it to add additional vars Jul 28 15:58:59 with a pure make based buildsystem you really need to read the makefiles and see what variables it's using for things, to see what/how to make it obey ours Jul 28 15:59:05 not everyone has the same conventions Jul 28 15:59:12 e.g. some might use CCOPTS or something instead of CFLAGS Jul 28 16:02:01 kergoth: the only log I can find just tells me exactly what a saw when bitbaking the image failed with the error I mentioned in the beginning Jul 28 16:02:13 the image is irreelvent Jul 28 16:02:20 look at the lgos of the tasks of your recipe and see what it was doing Jul 28 16:02:29 make sure do_configure actually ran configure, for example Jul 28 16:02:54 bitbake -e wine | grep WORKDIR=. look in workdir under the temp/ directory for the task logs Jul 28 16:03:06 okay Jul 28 16:05:15 ERROR: Nothing PROVIDES 'wine' is the answer of the grep Jul 28 16:06:24 so your recipe isn't even available for bitbake to build at all Jul 28 16:06:41 likely your layer.conf is wrong, or the recipe is in the wrong place, or something Jul 28 16:10:33 hmm layer is in the right place but there was a strange behaviour there was a problem with versions numbers PV, bitbake was not able to find the source file, because PV was set to 1.0 no matter what name my recipe has, so I changed the source name to program-1.0.bb and it worked Jul 28 16:10:49 maybe thats a hint ? Jul 28 16:12:37 sorry the source name to programm-1.0.tar.bz2 because it had no effect when I changed the recipe name Jul 28 16:13:12 sounds like your filename was wrong. the separator is _, not - Jul 28 16:13:15 name_version.bb Jul 28 16:20:46 kergoth: i love you Jul 28 16:20:48 :D Jul 28 16:22:15 damn i mixed up some - and _ that was the reason now it is compiling - thanks for your patience , right now i got an error do_configure : wine: No generic license file exists for: GNU in any provider Jul 28 16:24:48 but thanks so far for you help ! very nice support Jul 28 16:27:40 I'm always surprised by people hitting problems like that. did they never look at another recipe in their life? we only have thousands of examples to go by Jul 28 16:27:40 :) Jul 28 16:33:53 zeddii, reverting that patch helps. I'm collecting logs for you Jul 28 16:35:43 cool Jul 28 16:35:59 btw there is a pending patch about that driver (pci) Jul 28 16:36:51 [PATCH v2] spi/pxa2xx-pci: Add common clock framework support in PCI glue layer Jul 28 16:36:58 * zeddii nods. problematic little bugger. Jul 28 16:37:19 * zeddii sees it. From Friday. Jul 28 16:37:38 and Jul 28 16:37:39 [PATCH] spi/pxa2xx-pci: Enable DMA binding through device name Jul 28 16:37:51 so it is under fire... Jul 28 16:38:28 * zeddii sees that now as well. we should get dvhart to follow along as well. Jul 28 16:38:53 that one disturbs on pxa Jul 28 16:38:58 * dvhart looks up Jul 28 16:39:12 those were added for baytrail minnowmax support Jul 28 16:39:15 just FYI Jul 28 16:39:16 yah. Jul 28 16:39:23 please Cc me on discussion re those Jul 28 16:39:30 there is some additional development ongoing there Jul 28 16:39:32 ant_home. found some issues on pxa and we narrowed it down to the first rev of the patches. Jul 28 16:39:43 I've sent you the good log Jul 28 16:39:56 dvhart: no worries. adding you now. we'll need to refresh to where the -dev lands. Jul 28 16:40:01 reverting 261f5d0 Jul 28 16:40:17 rburton: seems I cannot reproduce it on the CI machine after a log in and doing it manually. :( Jul 28 16:40:40 dvhart, it causes pxa2xx-spi: probe of pxa2xx-spi.1 failed with error -2 Jul 28 16:40:42 guys i require your help: i'm building an image for a target which is based on powerpc MPC641D (e600). Where can i find a convenient tuning configuration? openembedded has tune-ppce600.inc but yocto don't:-! Jul 28 16:41:36 ant_home, on which hardware? Jul 28 16:41:50 on both pxa250 and pxa255 Jul 28 16:42:01 no, which physical board Jul 28 16:42:01 poodle & corgi Jul 28 16:42:10 Sharp Zaurus Jul 28 16:42:42 wow, ok Jul 28 16:42:59 This is PCI mode right? Jul 28 16:43:12 we have no pci... Jul 28 16:43:13 or... no... platform device? Jul 28 16:43:17 yes Jul 28 16:43:21 spi Jul 28 16:43:42 vanilla 3.16-rc7 is ok Jul 28 16:43:58 interesting that this pci-specific clock patch breaks your platform usage.... hrm Jul 28 16:44:01 that patch breaks since 3.14 Jul 28 16:44:06 OK, needs to get fixed, thanks for reporting Jul 28 16:44:09 yw Jul 28 16:44:26 see upstream pending commits Jul 28 16:44:51 zeddii, we need to pull in Andy Shevchenko and Mika Westerberg Jul 28 16:45:42 Mika's latest replaces this patch with a more generic solution Jul 28 16:45:42 k. since we want to switch out the integrated version for the two that ant_home pointed out. and then make sure that both the minnow and pxa cases work. Jul 28 16:45:53 exactly Jul 28 16:46:05 perhaps we don't need to pull them in. Let's just test first Jul 28 16:46:13 I am in touch with ojn upstream I'd show him the patch Jul 28 16:46:35 agreed. ant_home: did you confirm that with those two patches you pointed out that your boards are fine ? Jul 28 16:46:42 so that the pending one will be double-checked Jul 28 16:47:17 I'm doing last counter-probe, building normal yocto-dev Jul 28 16:47:24 w/out reverting Jul 28 16:47:30 k. Jul 28 17:21:43 hello folks, i've been banging my head for a week now trying to get the beagleboard-xM dvi display to work on a simple dora(+meta-ti) checkout building core-image-sato. Anybody facing or did face the same problem? Jul 28 17:33:57 bwonka: HDMI worked fine when I used it, what is the error you see ? is u-boot setting the params correctly Jul 28 17:34:31 omapfb isn't starting up fine Jul 28 17:34:39 probe fails with error '-22' Jul 28 17:34:46 says 'device not found' Jul 28 17:34:59 may be try meta-beagleboard Jul 28 17:35:07 kernel Jul 28 17:35:48 yocto-3.10 Jul 28 17:36:12 is the one I'm using. Jul 28 17:36:59 bwonka: hmmm so mix of meta-yocto and meta-ti ? Jul 28 17:37:02 khem: first error on omapfb init is omapfb omapfb: no driver for display: dvi Jul 28 17:37:15 yeah exactly Jul 28 17:37:22 but why ? Jul 28 17:37:45 just use meta-ti or meta-yocto Jul 28 17:37:47 dont use both Jul 28 17:38:02 that combo is probably not tested at all Jul 28 17:38:14 I see Jul 28 17:39:04 I did try removing meta-ti from bblayers without any luck, maybe I should've used only meta-ti then Jul 28 17:39:42 khem, have you seen my libgcrypt analysis? Is it correct? Jul 28 17:58:45 bwonka: yes Jul 28 17:59:09 ant_home: yes, as I expected that there were some asm files left out to be PIC Jul 28 17:59:22 and I am glad they have fixed it already Jul 28 18:57:50 bwonka: use one or the other, not both Jul 28 19:18:22 Is someone using/working in SDK for Qt? Jul 28 20:10:40 Is there an easy way to generate a list of the package name/version number for all of the recipes in poky? Jul 28 20:11:14 Or is that info published somewhere? I'm interested in current master branch versions. Jul 28 20:12:32 i'd just run bitbake -s Jul 28 20:12:40 but you can use the layer index to inspect it Jul 28 20:12:40 http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/ Jul 28 20:12:51 scroll down to the recipes/machines/classes info Jul 28 20:18:09 kergoth: doh! I forgot about -s :-) Jul 28 20:18:12 thanks Jul 28 20:18:22 np **** ENDING LOGGING AT Tue Jul 29 03:00:00 2014