**** BEGIN LOGGING AT Fri Nov 21 02:59:58 2014 Nov 21 09:04:36 (Angstrom 2013.12) Hi guys, I have a question. When i compile my kernel "bitbake -c virtual/kernel" i have a kernel directory. I can modify it and etc. But when i try to compile my image it completly ruins my kernel git directory and clens everything. Is it an option to compile whole image, use my kernel changes and not clean kernel directory? Nov 21 09:05:28 disable rm_work Nov 21 09:10:59 So you mean to override it in my kernel recipe? Nov 21 09:14:29 if you only want to keep the kernel, yes Nov 21 09:14:48 thx, i will try it. :) Nov 21 10:10:53 morning all Nov 21 10:12:01 hi bluelightning Nov 21 10:12:11 hi woglinde Nov 21 10:39:23 bluelightning: https://www.dropbox.com/sh/pgi8l77k6kzb2qn/AABKUv-zgkgU-opMRx5Lm6qEa?dl=0 Nov 21 10:39:30 bluelightning: can you take a look? Nov 21 10:46:41 otavio: sorry I didn't reply yesterday, let me take a look now Nov 21 10:54:47 hi bluelightning Nov 21 11:00:02 Do anybody know from which recipe I can obtain libGLcore? I would like to use mesa, but i cannot see this library in mesa-gl package. As far I'm concerned i need this library to run mesa-demos. Nov 21 11:01:31 Do anybody know from which recipe I can obtain libGLcore? I would like to use mesa, but i cannot see this library in mesa-gl package. As far I'm concerned i need this library to run mesa-demos. Nov 21 11:09:19 otavio: near as I can tell, rpm requires that version numbers do not have dashes in them, according to the docs of both rpm4 and rpm5 Nov 21 11:10:27 I wonder if we stopped filtering them out or something like that? Nov 21 11:13:16 otavio: doesn't seem like we did looking over the commits in dizzy... Nov 21 11:13:45 bluelightning: well this have been working forever Nov 21 11:13:52 bluelightning: so we have a regression Nov 21 11:14:01 bluelightning: don't know how Nov 21 11:14:04 would you be able to try to identify where the regression happened? Nov 21 11:15:04 bluelightning: Poky at df87cb27efeaea1455f20692f9f1397c6fcab254 worked Nov 21 11:15:12 bluelightning: http://ci.ossystems.com.br/job/fsl-community-bsp-dizzy/26/consoleFull Nov 21 11:17:47 otavio: ok, when did it first not work? Nov 21 11:19:10 bluelightning: Poky at df87cb27efeaea1455f20692f9f1397c6fcab254 (failure); http://ci.ossystems.com.br/job/fsl-community-bsp-dizzy/27/consoleFull Nov 21 11:19:20 er Nov 21 11:19:36 I'm confused, you just said that was the revision that worked Nov 21 11:20:09 I guess I can look at the repo manifest... Nov 21 11:20:31 no, it's the same there too Nov 21 11:21:11 bluelightning: it seems it is due update in fsl-arm than Nov 21 11:21:17 but am wondering why Nov 21 11:21:38 did the version perhaps change from one which didn't contain '-' to one that did? Nov 21 11:22:02 The file was removed D recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.10.17-1.0.1-hfp.bb Nov 21 11:22:05 The file was removed D recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.10.17-1.0.1-sfp.bb Nov 21 11:22:08 The file was added A recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.10.17-1.0.2-hfp.bb Nov 21 11:22:11 The file was added A recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.10.17-1.0.2-sfp.bb Nov 21 11:22:14 both has Nov 21 11:23:10 ok, unless the dependency in the piglit specfile somehow wasn't there before and now is I can't imagine how it would have worked and then not... Nov 21 11:29:53 otavio: in any case I think there ought to be enough to file a bug at this point, and I'll try to draw fray's attention to it Nov 21 11:33:05 bluelightning: how do you think I can debug it? Nov 21 11:33:17 bluelightning: the nice thng is all machines uses same code Nov 21 11:33:19 hheehhe Nov 21 11:34:10 you could find out when the last time piglit do_package_write_rpm executed successfully, and then compare the specfile to the one that breaks Nov 21 12:02:54 bluelightning: proved; reverting it fixes the build failur Nov 21 12:03:16 otavio: reverting which sorry? Nov 21 12:03:19 bluelightning: should the filter be fixed to handle the - on the version Nov 21 12:03:26 bluelightning: the gpu update for 1.0.2 Nov 21 12:03:34 ah okj Nov 21 12:04:11 well we should definitely either replace them in the value or error out earlier with a sensible message Nov 21 12:04:25 (when using the RPM backend) Nov 21 12:14:13 where in the code this should be done? Nov 21 12:14:32 and when it generates the rpm it does not leave the spec around Nov 21 12:19:26 bluelightning: so I failed to be able to compare both Nov 21 12:20:16 hmm OK I thought it left the file there Nov 21 12:20:32 if it's a replacement in the name, probably in package_rpm.bbclass where it writes out the spec file Nov 21 12:20:49 er, actually no that would probably be too late Nov 21 12:21:07 it would need to be somewhere where you can set PKGV Nov 21 12:21:23 probably still in package_rpm, just not sure where exactly Nov 21 13:21:36 anyone know how I can change the name of the output wic image file name? Nov 21 13:46:19 Crofton|work: it doesn't look like there's an option for that... Nov 21 13:54:47 this is annoying Nov 21 13:54:54 machine isn't in the image name Nov 21 13:55:15 I'm puting them in different output dirs, but want the filename to indicate machine info :) Nov 21 14:01:10 I suppose I should open a bug Nov 21 14:01:16 Crofton|work: or send a patch ;) Nov 21 14:01:24 I can solve sort term problem with a wilcard copy :) Nov 21 14:01:56 I do not want to get into the mode of thinking I can make a patch and then forgetting about the problem Nov 21 14:34:32 bluelightning: any guess where it removes the generated spec? I'd like to diff them Nov 21 14:38:34 otavio: somewhere in package_rpm.bbclass or meta/lib/oe/package_manager.py probably Nov 21 14:56:11 Hi guys, once more question. If i have a prebuild .ipkg package, how can i force bitbake to install it in my image? Nov 21 14:58:31 spaszkoPL: I don't think we really support that very well Nov 21 14:59:21 anything mentioned in IMAGE_INSTALL has to be provided by something within the build system Nov 21 14:59:21 Hmm.. you mean that i have to run my image and then install it using opkg? Any other option? Nov 21 15:00:53 the only workaround I can think of is to do the same thing but in a postprocessing command as part of the image construction Nov 21 15:01:52 At the moment i have a problem that one missing package i have on angstrom feeds prebuild as .ipk. I don'y have recipe for this package and i have to run my image, download it and install using opkg. I was thinking if it's possible that bitbake will do it for me? Nov 21 15:02:22 er, if it's in the angstrom feeds there must be a recipe somewhere that produced it Nov 21 15:02:30 AFAIK Nov 21 15:02:48 what package is it? Nov 21 15:03:14 From my searches i cannot found this recipe in my sources directory. Nov 21 15:04:30 this packages are mesa-driver-swrast and xserver-xorg-extension-glx Nov 21 15:04:59 if all else fails, opkg info on the file should show a "Recipe:" field which says which recipe produced it Nov 21 15:05:09 hmm Nov 21 15:05:35 wait a moment i will look Nov 21 15:10:52 Hmm Nov 21 15:11:03 opkg info is showing recipe info ? Nov 21 15:11:47 i don't see it. Nov 21 15:15:53 Unfortunately i don't know how to check which recipe provides ipk file. Even for packages i've build. Nov 21 15:18:06 I thought it was supposed to be saved into the package itself for opkg, I haven't looked recently Nov 21 15:19:52 ah, the field is called "Source" not "Recipe" Nov 21 15:20:08 wait, that's not it Nov 21 15:20:32 it's called simply "OE" Nov 21 15:20:34 hmm Nov 21 15:20:43 is opkg info reporting an "OE" field?? Nov 21 15:21:20 checking... Nov 21 15:21:49 nope. Nov 21 15:22:04 opkg info is giving a lot of info but grep saids that no OE. Nov 21 15:22:18 well, that is very strange, because when it writes it out it does so unconditionally Nov 21 15:22:58 So you see OE, yes? Maybe sth is wrong with my opkg or sth is missing. Nov 21 15:23:20 I can see where it writes it in the code, at least for ipk files that the build system produces Nov 21 15:26:56 Nope. I don't see anything. Nov 21 15:27:23 Even when i open ipk files by vim i don't see OE or oe. Nov 21 15:28:05 Maybe it's my bitbake configuration not writing this data. Nov 21 15:28:37 the control file? Nov 21 15:28:59 I've just looked at a random angstrom IPK (alsa-state in this case) and I can see it in the control file Nov 21 15:35:20 spaszkoPL: can you link to this package in the angstrom feeds? what version of angstrom is this from? Nov 21 15:40:05 spaszkoPL: you can also look at the BUILD_FROM_FEEDS feature, which will let you build an image out of different feeds. The feature is still a bit rough around the edges, but I have been using it successfully Nov 21 15:40:26 adelcast: right there is that, but I'm convinced that's not the right solution here Nov 21 15:40:40 it's not as if the source and recipe for this package doesn't exist somewhere Nov 21 15:41:55 right, if there is a recipe, you might be better off getting it and adding it to your build. In my case, there is no recipe (and the ipks come from a very different build system, with different export structure, etc) Nov 21 15:43:36 adelcast: so apparently there is no mesa-driver-swrast package anymore because there is no such split driver in mesa anymore, it was replaced by a "megadriver" Nov 21 15:44:30 ^ sorry that was meant for spaszkoPL Nov 21 15:44:47 spaszkoPL: the package providing that is called mesa-megadriver Nov 21 15:57:17 hmm Nov 21 15:57:26 I was abroad for a while. Nov 21 15:57:27 :) Nov 21 15:57:32 spaszkoPL: as for xserver-xorg-extension-glx, that is produced by the xserver-xorg recipe Nov 21 15:58:04 if you aren't getting an xserver-xorg-extension-glx, perhaps building that extension is being disabled for some reason Nov 21 15:59:20 I'm building xserver-xorg but as you said i don't have erver-xorg-extension-glx. Nov 21 16:01:08 might be worth looking at the log.do_configure for xserver-xorg to see if there's anything glx-related in there Nov 21 16:02:22 Anyway from my point of view i don't see any megadriver recipe in my angstrom sources. Maybe i don't have this layer in my layers.txt. Nov 21 16:02:34 it's not a layer Nov 21 16:02:42 the OE-Core mesa recipe produces it Nov 21 16:03:01 at least, since the upgrade to 10.1.3 Nov 21 16:03:05 (of mesa) Nov 21 16:03:43 ok, so it's probably in mesa WORKDIR, isn't it? Nov 21 16:03:52 you should have a mesa-megadriver package Nov 21 16:04:07 you would find evidence of it in the mesa workdir yes but you should also have an ipk Nov 21 16:04:23 assuming you are in fact building mesa 10.1.3 or later Nov 21 16:06:52 No. I have mesa_9.1.6.bb recipe. Nov 21 16:09:43 ah ok then in which case it probably ought to be providing a mesa-driver-swrast package, if not, perhaps check the configure log there as well Nov 21 16:11:24 ok thx Nov 21 16:11:28 i will check it Nov 21 16:11:28 . Nov 21 16:11:38 Have a nice weekend! Bye. Nov 21 16:12:25 this is sort of exciting, I've been able to grossly simplify the pyqt recipe Nov 21 16:12:35 hopefully it works Nov 21 16:14:59 Crofton|work: buildhistory should help confirm it... Nov 21 16:15:26 well, the old recipe made a package that didn't work very well Nov 21 16:15:44 the test is see if I can run a gnuradio companion flowgraph Nov 21 16:16:09 so if buildhistory is the same, that is bad :) Nov 21 16:17:08 well buildhistory may be different, but not unexpectedly so :) Nov 21 16:17:13 you should check it in any case Nov 21 16:38:49 bluelightning: Oh Nov 21 16:38:52 bluelightning: http://privatepaste.com/16d2aec7cea Nov 21 16:38:55 bluelightning: http://privatepaste.com/16d2aec7ce Nov 21 16:39:22 bluelightning: So the new package triggers a different versioning Nov 21 16:39:31 bluelightning: Any idea /why/? Nov 21 16:41:29 otavio: is that coming from PV or PKGV of libegl-mx6? Nov 21 16:42:25 PV is the same pattern. Nov 21 16:42:29 bluelightning: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=dizzy&id=0f510a593a8aae8ca5b83574915bf736fa4dbe5c Nov 21 16:42:38 bluelightning: this is the patch which breaking it Nov 21 16:43:49 hmm, no clues there... formatting has not changed Nov 21 16:44:31 does the libegl-mx6 package itself end up with + or - in its name? Nov 21 16:48:04 bluelightning: let me check; I don't think so Nov 21 16:49:13 generating the broken one so we can debug it Nov 21 16:59:46 otavio: actually I think I have a clue as to why this might have broken Nov 21 16:59:54 Really? Nov 21 17:00:30 yes, I found the code in package_rpm.bbclass that does the replacement, and it relies on pkgdata Nov 21 17:00:49 if that was somehow messed up, I think it might pass through without doing the right thing to PKGV Nov 21 17:01:18 bluelightning: I am in a tmpdir with it broken; want me to check anything? Nov 21 17:03:14 otavio: is there a PKGV value in the libegl-mx6 pkgdata file? Nov 21 17:12:06 bluelightning: http://privatepaste.com/171b112391 Nov 21 17:13:38 aha Nov 21 17:13:44 the version is different there Nov 21 17:13:50 hence it doesn't match Nov 21 17:14:11 now why it's different, I couldn't say... Nov 21 17:15:01 (well, hence it doesn't match and thus never gets replaced in the dependency's version specification string) Nov 21 17:16:58 is there a proper build-time dependency between piglit and gpu-viv-bin-mx6q ? Nov 21 17:25:09 yes Nov 21 17:25:13 bluelightning: using virtual Nov 21 17:25:28 ok Nov 21 17:25:31 odd then Nov 21 17:25:38 DEPENDS="autoconf-native automake-native libtool-native libtool-cross gnu-config-native cmake-native virtual/arm-poky-linux-gnueabi-gcc virtual/arm-poky-linux-gnueabi-compilerlibs virtual/libc virtual/libx11 libxrender waffle virtual/libgl libglu python-mako-native python-numpy-native python-native " Nov 21 17:25:52 somehow when piglit buildt it got the old version Nov 21 17:26:31 bluelightning: but what does not match? Nov 21 17:26:42 bluelightning: it has PKGV: 3.10.17-1.0.2-hfp Nov 21 17:26:49 bluelightning: gpu-viv is PKGV: 3.10.17-1.0.2-hfp Nov 21 17:27:24 yes but piglit's spec file has: Requires: libegl-mx6 >= 3.10.17-1.0.1-hfp Nov 21 17:27:28 1.0.1 vs 1.0.2 Nov 21 17:27:36 bluelightning: but /why/? Nov 21 17:27:39 I don't know Nov 21 17:27:42 that is one problem Nov 21 17:28:03 the other problem is that it didn't error out when the replacement couldn't be done Nov 21 17:28:23 (that's a secondary issue though) Nov 21 17:29:49 bluelightning: ahhh Nov 21 17:30:00 bluelightning: it does not has a depedency Nov 21 17:30:12 bluelightning: sl does not provides libgl Nov 21 17:30:24 oh, only libegl? Nov 21 17:30:28 yds Nov 21 17:30:33 ah, right Nov 21 17:30:44 and piglit does not figured it out Nov 21 17:32:30 well, I don't know if that's exactly the issue, it could be that tasks were executing in such an order that the version was 1.0.1 when piglit's do_compile happened, but by the time do_package_write_rpm ran the 1.0.2 package was created Nov 21 17:33:28 our new QA checks ought to pick this sort of thing up (unless they were on in your current builds and didn't?) Nov 21 17:35:13 bluelightning: it did not Nov 21 17:35:20 but on dizzy Nov 21 17:35:22 http://privatepaste.com/2980f0921e Nov 21 17:35:25 seems to fix it Nov 21 17:37:29 ok, dizzy does have those QA checks and they should be active unless they're not in your values of WARN_QA / ERROR_QA Nov 21 17:50:53 bluelightning: we are using poky Nov 21 17:51:00 bluelightning: so it is the default Nov 21 17:53:14 what are some good repo collections for opkg general use (specifically for installing python) and how do I add them to opkg? Nov 21 17:54:54 the8thbit|work: there aren't really any generic feeds around, you'd ideally look for one to be provided by whatever distro you have installed Nov 21 17:55:44 bluelightning: unfortunately it was developed in house and we don't have anything like that Nov 21 17:57:32 the8thbit|work: ok, in which case you should probably build them out yourself, it would just be a case of having the appropriate recipes to do so Nov 21 17:58:59 bluelightning: hm, yeah thats what it seems like. Unfortunately, I'm very new to this whole thing. I'm not really familiar with what a recipe (other than in very vague terms as a list of instructions for building for a particular architecture) or how I would get an appropriate one. Nov 21 17:59:21 ok, no worries Nov 21 18:00:15 basically OE maintains an index of the layers that are out there and the recipes that they provide here: http://layers.openembedded.org Nov 21 18:01:00 So Im looking for "meta-python"? Nov 21 18:01:10 that's one place where a bunch of python recipes can be found yes Nov 21 18:01:31 we ship quite a few in OE-Core as well Nov 21 18:01:49 OE-core being more general purpose? Nov 21 18:02:23 OE-Core is the core set of recipes, it's basically required when you use our build system (effectively it is the build system, or at least the bit that tells bitbake how to be our build system) Nov 21 18:05:43 bluelightning: Okay, so where do I go from here? Do I pull down oe-core from git or something..? Nov 21 18:06:19 so our getting started page is here: http://www.openembedded.org/wiki/Getting_started Nov 21 18:06:31 thank you Nov 21 18:07:17 my personal recommendation is to start with the Yocto Project quick start guide (poky, the Yocto Project's reference build system, uses OE-Core); but then I am somewhat biased on that front Nov 21 18:07:21 bluelightning: "host machine" means not the embeded device, but the machine I'm sshing into the device with, right? Nov 21 18:07:47 the8thbit|work: the machine you'd be running the builds on Nov 21 18:08:01 oh, so the embeded device? Nov 21 18:08:11 well, no, that's the target Nov 21 18:08:15 oh, ok Nov 21 21:49:09 http://sydneypadua.com/2dgoggles/ <= embedded humor? **** ENDING LOGGING AT Sat Nov 22 03:00:00 2014