**** BEGIN LOGGING AT Wed Sep 04 02:59:58 2013 Sep 04 06:08:29 crofton|work: thanks :) Sep 04 06:22:49 How do I deduce the bitbake package name from something like this? virtual:native:/[...]/util-linux/util-linux_2.23.2.bb Sep 04 06:23:23 native recipes don't emit packages Sep 04 06:23:30 so the question doesn't have any meaning Sep 04 06:23:41 it's failing on me with "x86_64-linux-libtool: install: error: relink `libblkid.la' with the above command before installing it" Sep 04 06:24:30 so how do I bitbake that one to debug it? Sep 04 06:27:25 try bitbake util-linux-native Sep 04 06:28:11 thanks, seems to work. Question still remains, how do I deduce the bitbacke package name from a task name like that? Sep 04 06:29:14 what are you trying ti do exactly? Sep 04 06:29:22 *to do even Sep 04 06:30:51 like kergoth said, there aren't any native packages per se, just a native sysroot Sep 04 06:31:17 you can use -c "foo" with the above... Sep 04 06:32:54 i'm not up on the policy for libtool archives, so someone else will need to speak about that... Sep 04 06:33:11 but sometimes they just confuse things Sep 04 06:34:41 gentoo had a special lafile-fixer tool for a while, but it was eventually dumped along with .la files Sep 04 06:41:59 nerdboy, no I can't. "bitbake -c do_install virtual:native:/[...]/util-linux/util-linux_2.23.2.bb" gives "ERROR: Nothing PROVIDES 'virtual:native:/[...]" Sep 04 06:44:39 no, just "bitbake util-linux-native -c whatever" Sep 04 06:47:20 indeed, bitbake accepts a recipe name or provide on its commandline, not a filename or package name Sep 04 06:48:06 so how do I find the matching recipe name? Sep 04 06:49:01 I know this one is util-linux-native (you just told me), but how can I tell without asking here or guessing? Sep 04 06:49:19 the recipe name is still util-linux unless there's a separate *-natve recipe file Sep 04 06:49:40 and virtual:native: means it's always -native? Sep 04 06:50:24 yes Sep 04 06:50:55 some packages have -native bb files but others use the virtual Sep 04 06:52:03 if this one had a -native bb I assume the error would show that file instead. Sep 04 06:53:02 yup Sep 04 06:57:28 How to I completely restart a recipe in a clean work tree? bitbake -f -c unpack ? Sep 04 06:58:30 sorry, to be more precise: the recipe name is util-linux_2.23.1.bb, and it has 2 base provides (util-linux and util-linux-native) plus any others that are defined in the recipe Sep 04 06:59:00 i usually do -c clean Sep 04 06:59:36 there's a cleansstate option but i'm not sure of the exact spelling... Sep 04 07:00:15 do -c clean wipe the work tree, or just run "make clean"? Sep 04 07:02:45 it cleans up work Sep 04 07:03:00 nerdboy, it seems to be spelled -c cleanall Sep 04 07:03:49 that one cleans the state cache? Sep 04 07:04:06 http://www.openembedded.org/wiki/List_of_Executable_tasks says so. Sep 04 07:04:39 "clean $WORKDIR and sstate-cache" Sep 04 07:05:22 hmm.. there is also a cleansstate Sep 04 07:07:48 when would one want to clean only the sstate-cache and leaving the workdir? Sep 04 07:14:38 cleansstate cleans both, keeps only downloaded stuff in DL_DIR Sep 04 07:15:20 florian: ping :) Sep 04 07:17:18 JaMa: yep... thanks. Sep 04 07:19:47 Hm.... odd. Seems this build failed because of broken files in sysroot that it was meant to install. Sep 04 07:55:18 good morning Sep 04 08:05:55 hi Sep 04 08:06:07 have question about using barebox instead u-boot Sep 04 08:06:17 I set PREFERRED_PROVIDER_virtual/bootloader = "barebox" Sep 04 08:06:40 bit bitbake still complains about multiple virtual/bootloader providers Sep 04 08:06:52 should I mask u-boot or is there some other way? Sep 04 08:10:22 morning all Sep 04 08:10:44 mbelisko: PREFERRED_PROVIDER_virtual/bootloader = "something" Sep 04 08:11:58 bluelightning: did that but it doesn't help Sep 04 08:13:01 mbelisko: is it giving you the "one provides something the other doesn't" message? Sep 04 08:13:18 bluelightning: ERROR: Multiple .bb files are due to be built which each provide virtual/bootloader Sep 04 08:13:44 mbelisko: right, a different error than the one I was thinking Sep 04 08:14:17 mbelisko: somewhere you have a dependency that is forcing the provider you haven't selected to be built Sep 04 08:14:38 bluelightning: I add IMAGE_BOOTLOADER = "barebox" to local.conf also as described in https://lists.yoctoproject.org/pipermail/meta-freescale/2013-January/000792.html Sep 04 08:15:00 mbelisko: you can use bitbake -g your-image or bitbake -g -u depexp your-image to find what is depending on it Sep 04 08:16:13 sometimes you can find the answer by using bitbake -e | less and searching for the name of the provider, which will find it if it's mentioned in a global variable somewhere Sep 04 08:22:50 bluelightning: bitbake -g -u depexp gives me table and which dependency should I look for runtime or build? Sep 04 08:23:14 bluelightning: runtime are u-boot-imx and u-boot-imx-dev Sep 04 08:23:33 mbelisko: potentially it could be either Sep 04 08:23:37 mbelisko: what depends on those? Sep 04 08:24:35 bluelightning: u-boot-imx is package and have those 2 dependencies (also reverse depends is u-boot-imx) Sep 04 08:25:10 mbelisko: at this point I'd try looking at the output of bitbake -e Sep 04 08:25:55 bluelightning: should I look for u-boot-imx in output? Sep 04 08:27:35 bluelightning: IMAGE_DEPENDS_sdcard="parted-native dosfstools-native mtools-native virtual/kernel u-boot" Sep 04 08:27:52 bluelightning: could this make problems? Sep 04 08:28:59 mbelisko: for IMAGE_DEPENDS this means sdcard would need to be in IMAGE_FSTYPES Sep 04 08:29:03 mbelisko: if it is, then yes Sep 04 08:30:13 mbelisko: but looking at meta-fsl-arm that value gets in via IMAGE_BOOTLOADER Sep 04 08:30:24 mbelisko: are you sure you set IMAGE_BOOTLOADER and in the right place? Sep 04 08:31:02 (this is specific to meta-fsl-arm for anyone else reading) Sep 04 08:31:16 morning all Sep 04 08:32:13 bluelightning: this is substituted by virtual/kernel ${IMAGE_BOOTLOADER} as u-boot (but I set IMAGE_BOOTLOADER = "barebox") Sep 04 08:33:13 mbelisko: where did you set it? Sep 04 08:33:43 bluelightning: in local.conf Sep 04 08:34:21 morning all Sep 04 08:34:22 mbelisko: seems to me it's being overridden Sep 04 08:34:38 mbelisko: are you using dylan (1.4) or later? Sep 04 08:35:18 bluelightning: and according bitbake -e it's corectly replaced but I found this one: IMAGE_DEPENDS_uboot.mxsboot-sdcard="u-boot-mxsboot-native u-boot" Sep 04 08:35:29 bluelightning: which could make problems Sep 04 08:35:47 mbelisko: again, uboot.mxsboot-sdcard would need to be in IMAGE_FSTYPES, is it? Sep 04 08:37:31 bluelightning: it's in imx-base.inc IMAGE_FSTYPES ?= "tar.bz2 ext3 sdcard" Sep 04 08:38:11 mbelisko: that's "sdcard" not "uboot.mxsboot-sdcard" though Sep 04 08:38:46 mbelisko: frankly this is the point where I think otavio needs to help you unravel this since I'm guessing he wrote this logic in meta-fsl-arm... Sep 04 08:39:05 he's probably asleep atm but will be online later Sep 04 08:39:34 bluelightning: I found also interesting line in imx-base.inc - EXTRA_IMAGEDEPENDS = "u-boot" Sep 04 08:39:51 mbelisko: that may explain it, that will cause u-boot to be built Sep 04 08:39:57 bluelightning: OK will ask otavio Sep 04 08:40:31 mbelisko: and it looks like that's unconditional too... something is wrong there Sep 04 08:42:38 bluelightning: adding EXTRA_IMAGEDEPENDS = "barebox" to my image recipe hide error Sep 04 08:43:01 probably there should be EXTRA_IMAGEDEPEND = ${IMAGE_BOOTLOADER} in imx-base.inc Sep 04 08:43:43 I'm guessing something like that yes Sep 04 08:44:42 bluelightning: OK thanks for help Sep 04 09:47:58 hi. let's say recipe abc_git.bb has DEPENDS += 'virtual/foo', and that PREFERRED_PROVIDER_virtual/foo='myfoo'. will myfoo-dev package be install automatically when building abc or is there a mechanism to indicate that's the -dev package for 'virutal/foo'? Sep 04 10:09:49 ndec: if by "will myfoo-dev package be install automatically when building abc" you mean "will the development headers/libs from myfoo go into the sysroot" then, yes; but in our system that's completely separate from the myfoo-dev package Sep 04 10:11:50 bluelightning: thanks, that's what I meant indeed! Sep 04 12:32:08 morning Sep 04 12:46:51 mbelisko: Hi Sep 04 12:46:58 What I can be of help? Sep 04 12:51:15 otavio: Hi Sep 04 12:51:28 I was trying to build barebox for imx6dlsabresd Sep 04 12:52:33 otavio: I set IMAGE_BOOTLOADER = "barebox" but I got error about multiple virtual/bootloader providers Sep 04 12:53:10 otavio: IMO seems in imx-base.inc line EXTRA_IMAGEDEPENDS = "u-boot" should be changed to EXTRA_IMAGEDEPEND = ${IMAGE_BOOTLOADER} Sep 04 12:53:50 otavio: to resolve issue Sep 04 13:24:45 mbelisko: agreed Sep 04 13:25:02 mbelisko: makes sense indeed Sep 04 13:30:41 otavio: ok should send a patch? Sep 04 13:31:02 mbelisko: please do; but explain all this in the commit log Sep 04 13:35:11 sure Sep 04 13:35:17 otavio: thanks Sep 04 13:43:41 Samsung ARM Chromebook rocks! http://www.embedded.it/?q=content/samsung-arm-chromebook Sep 04 15:41:52 Crofton|work: :-) you're welcome :-D Sep 04 16:12:47 32 Sep 04 18:58:38 OK, layer index update done; I'll be sending out an email soon detailing what's new and improved Sep 04 22:00:19 denix: hi. in meta-ti you have recipes for powervr-driver and also a bunch of recipe for libgles that use the IMG SDK. they seem to 'provide' the same content. why is that duplicated? Sep 04 22:02:22 ndec: powervr-drivers contains omap3-sgx-modules, i.e. kernel modules portion. libgles-omap3 is the user-space GLES portion of SDK Sep 04 22:02:50 oops... i think i looked too quickly ... Sep 04 22:02:52 thx. Sep 04 22:03:19 ndec: that is only true for OMAP3 (OMAP4 was once released the same way) and now Sitara. Sep 04 22:03:45 ndec: are you talking about multiple versions in libgles? Sep 04 22:05:07 no, i was confused... i thought they both provided user space lib. Sep 04 22:05:41 ah, I see Sep 04 22:07:25 denix: and do you know why the user space libs are split up into 'individual' packages instead of 1 big blog? i suspect it's for SDK generation. but not sure. Sep 04 22:08:13 bluelightning: btw. awesome changes on layerindex ;-) and thanks for adding 'multi' release support! Sep 04 22:08:42 ndec: are you talking about x11 vs. raw split or each sgx revision? Sep 04 22:09:54 each sgx + all additional PACKAGES Sep 04 22:10:45 ndec: having them split into individual packages is easy on the user - he gets to decide if he needs x11 or raw, demos or no demos, and which sgx core revision his specific SOC has Sep 04 22:11:31 ndec: np Sep 04 22:11:39 ok. i see. and why the RREPLACES for the mesa packages? there are some hardcoded dependencies left over? Sep 04 22:12:22 ndec: mesa tries to provide gl, gles, libgles1/libgles2, which is part of our SGX SDK Sep 04 22:13:50 ndec: but, it theoretically should be possible to keep mesa just for the SW 3d render - nobody bothered so far Sep 04 22:13:51 yes, but 'normally' whoever needs gles, should require 'virtual/gles2', not the actual mesa package name Sep 04 22:14:09 so i was wondering if you did that because there was a pb in one recipe. Sep 04 22:14:20 that hard code mesa package. Sep 04 22:14:45 btw, i am currently working on recipes for DDK for a non OMAP platform ;-) Sep 04 22:15:31 there were some problems that would pull multiple providers of something... it may be overkill, but was a quick solution to the problem at a time Sep 04 22:16:03 ndec: nice, I do have ddk for omap5 pending, btw... Sep 04 22:16:26 and Sitara, of course Sep 04 22:16:31 i am not doing anything that relates to OMAP anymore ;-) Sep 04 22:16:50 I know :) your DDK is not for TI SOC, is it? Sep 04 22:17:24 nope! Sep 04 22:17:29 ndec: btw, are you in charge of the toolchain portion of meta-linaro? Sep 04 22:17:33 no. Sep 04 22:17:58 for any issue with meta-linaro, you can use linaro-dev@lists.linaro.org Sep 04 22:17:59 ok, would have been nicer if you were... :) Sep 04 22:18:06 I know :) Sep 04 22:18:18 well, i feel much better, not to be ;-) Sep 04 22:18:30 ha! :) why not? Sep 04 22:18:47 i am not a toolchain guy! Sep 04 22:19:44 heh, I wasn't either, but had to become one... :) Sep 04 22:21:49 ndec: anyway, good luck with your ddk efforts! let me know if you need any help Sep 04 22:22:00 sure.thx. Sep 04 22:38:03 ndec: build time virtual/ dependencies/provides aren't going to help already-existing runtime dependencies, if they care about binary packages and installs at runtime, the rprovides/rconflicts still provide value Sep 04 22:41:45 kergoth: ah. right. then that makes sense. it's not a scenario i am considering right now, but i understand why it's done this way now. Sep 04 22:42:40 not all distros prioritize binary packages and upgradability, but of course a bsp layer should work well with all distros Sep 04 22:42:43 * kergoth shrugs Sep 04 22:44:29 hehe, that's right! **** ENDING LOGGING AT Thu Sep 05 02:59:59 2013