**** BEGIN LOGGING AT Thu Mar 07 02:59:58 2013 Mar 07 10:16:15 morning all Mar 07 10:35:49 hi all Mar 07 10:36:32 can i put PREFERRED_VERSION_package in a recipe file ? or it is mandatory to put in in local.conf ? Mar 07 10:38:34 b737_800: it can't be done at a recipe level Mar 07 10:38:52 it needs to be set in local.conf or more appropriately in a custom distro config Mar 07 10:39:13 thank you for your answer Mar 07 10:39:42 if pu in a bb file it will be simply ignored right ? Mar 07 10:40:18 b737_800: Mar 07 10:40:21 b737_800: yes Mar 07 10:40:26 ok thanks Mar 07 10:40:36 b737_800: however, you could make the desired version of the other recipe PROVIDES something like recipe_ver_123 or api_v1 and then add that to DEPENDS in the recipe Mar 07 10:40:52 yes that what i did Mar 07 10:41:08 another question regarding package version Mar 07 10:42:40 if i have a bb named as package_V00.0.1.bb and package_V00.0.2.bb does bitbake understand that V00.0.2 is newer that V00.0.1 ? Mar 07 10:43:46 i mean inclusing the "V" in the package version Mar 07 10:48:36 that's fien Mar 07 10:49:25 i expect it won't know that 0.3 is newer than V00.0.2 though, so you'll have to keep that scheme going (or use epochs, but they're nasty) Mar 07 10:51:12 i'v tested and seems that bitbake always takes the newer version using the shceme (VX.YY.ZZ) but i wanted to be completely sure about that Mar 07 11:53:29 Hi all Mar 07 11:55:04 I tested prebuilt yocto images for qemux86 and it works fine. But when I tried with the kernel compiled by me. I am getting error in NFS mount Mar 07 12:03:25 I find some options available in yocto kernel config is not available in the kernel Mar 07 16:27:16 i hate it when bitbake inexplicably decides to rerun setstates for recipes i haven't touched Mar 07 16:27:25 setstates which have already been run in this tmpdir.. Mar 07 16:28:34 kergoth: try that cool new bitbake-whatchanged :) Mar 07 16:29:40 kergoth: have you been using -C / -f ? Mar 07 16:29:56 in this case all i did was added a recipe to CORE_IMAGE_EXTRA_INSTALL Mar 07 16:29:58 * kergoth rolls eyes Mar 07 16:31:31 kergoth: .... Mar 07 16:54:20 I'm curious. There has to be some thought in field upgrading. What's the best method to move a fielded system to a more recent poky distribution? Mar 07 16:56:45 some use the package managers Mar 07 16:57:00 some download a new rootfs and have a rescue partition that handles the upgrade Mar 07 16:57:21 same as with any distro, really. poky/yocto doesn't have anything magic *yet* Mar 07 17:11:11 those were the two methods I was considering, but both are have some downsides. The managers can have issues when packages like glibc are upgraded, as basically everything has to be upgraded. The replace the image has the fun of being a big disk change of once, which takes longer and makes a brick if interrupted without a lot of care. Mar 07 17:13:39 It'd be cool to see something like Nix for embedded. where every piece of software gets its own install prefix, and the rootfs can be reconstructed from that at any time, making it easy to install new versions of things and test new filesystems with rollback, particularly if you have some form of COW Mar 07 17:14:03 an alternative would be to use a unionfs implementation, install the package upgrades into the rw filesystem, and after validation, push that to the usually-mounted-ro / Mar 07 17:14:15 then you can still reset at any time by wiping the rw partition Mar 07 17:14:20 * kergoth shrugs, lots of possibilities Mar 07 17:16:16 blloyd_: sugar/olpc iirc used this technique where it had two main root filesystems and an update one, so there's always the current rootfs and the one you can update and when it's suceeded, swap them. Mar 07 17:16:24 (i think chromebooks do similar) Mar 07 17:19:50 that's a nice simple way of doing it, not a lot of pieces that can break :) Mar 07 18:26:49 thanks everyone on feedback. Hadn't considered 3 partitions so always have one root partition that isn't being updated. I had considered 2 where the running partition updated the other partition. Mar 07 19:48:13 rp: i've made some changes to the bb.fetch2.URI class, that among other things, addresses the issues we discussed during ELC. but otoh perhaps the whole idea was a bit naive on my part, perhaps too much work to use urlparse. Mar 07 19:48:56 will send it to the mailing list for comments, tomorrow or so. Mar 07 20:17:57 disabling the external toolchain causes my -natives to rebuild? Mar 07 20:17:58 ugh Mar 07 20:18:00 * kergoth adds todo Mar 07 20:47:11 ok, I've relaized I just need to install this eclipse thing Mar 07 20:47:38 now, I am trying to working out how to configure the sdk plugin to use the toolcahin in /usr/local Mar 07 21:00:52 * walters reads the comments in boost.inc and laughs Mar 07 21:04:15 those come fro the oe-classic recipe Mar 07 21:31:31 Suppose that I'm generating an SDK using bitbake -c populate_sdk . How do I engineer a recipe to get included in the generated SDK? Mar 07 21:33:46 I tried adding a line 'BBCLASSEXTEND = "nativesdk"' to my recipe, but the files associated with that package didn't get included in the SDK Mar 07 21:34:03 walters: haha... nice stuff :) Mar 07 21:37:26 (and my package inherits 'native') Mar 07 21:39:11 arg, why isn't eclipse using the cross compiler Mar 07 21:50:45 walters: lets just say there's a lot of legacy. i found myself cleaning up a fontconfig recipe that was full of crazy, introduced by my misguided and innocent self 6 years ago Mar 07 21:56:32 Garibald1: bbclassextend just makes a nativesdk version available, it won't magically also add that new recipe's packages to the sdk. populate_sdk operates based on the image target you select. you could set a variable, i forget what it's called, to adjust the package set just for the sdk, or you could just create a new image. the whole point of populate_sdk is to create an sdk corresopnding to an image, so its packages are governed primarily by that Mar 07 21:58:41 kergoth: so I have a target that pulls in a native package, and some of my recipes are able to successfully use the content provided by the native package, but when I do 'bitbake -c populate_sdk ' the same content doesn't appear in the generated sdk. Mar 07 21:59:15 Garibald1: and "pulls in" means what exactly? Mar 07 21:59:38 kergoth: meaning the native package is installed Mar 07 22:00:06 gets put in temp/sysroots/x86_64-linux Mar 07 22:00:10 s/temp/tmp/ Mar 07 22:01:17 again, populate_sdk has meaning when run based on an image, not a random recipe Mar 07 22:01:52 hum... let me see if I can explain more clealry Mar 07 22:04:25 I have a recipe core-image-foo that DEPENDS on my-package-native. 'bitbake core-image-foo' generates an image, using the tools provided by 'my-package-native'; 'my-package-native' files appear in tmp/sysroots/x86_64-linux. 'bitbake -c populate_sdk core-image-foo' generates an SDK, but that SDK doesn't include the 'my-package-native' content. Mar 07 22:06:06 so my application of populate_sdk is on an image Mar 07 22:06:28 no? Mar 07 22:09:15 ah, I should also mention that 'my-package-native' content also appears in tmp/work/x86_64-linux/my-package-native-1.0-r0/sysroot-destdir/absolute/path/to/where/tmp/sysroots/x86_64-linux/is/path/to/content Mar 07 22:09:17 DEPENDS isn't what you want. populate_sdk populates an sdk based on *what goes into the image* Mar 07 22:09:22 the sysroots aren't relevant Mar 07 22:09:45 e.g. if you want bash-nativesdk in populate_sdk, one way to get it is to add bash to IMAGE_INSTALL for tha timage. Mar 07 22:10:25 i think there's another variable to control it directly, but i can't recall it offhand, i'd suggest reading image.bbclass for details Mar 07 22:21:40 then I'm very confused. Mar 07 22:21:59 I thought the SDK was the toolchain used on the host to build apps for the distro Mar 07 22:22:22 nope. the sdk is the production of a *standalone* development environment and toolchain which you use to build stuff outside of yocto Mar 07 22:22:32 yeah, exactly Mar 07 22:22:51 and that environment by default is produced based on what goes into the root filesystem of an image, as mentioned earlier Mar 07 22:23:00 (if you use populate_sdk, rather than an sdk recipe) Mar 07 22:23:02 so if I have a distro for ARM, but I'm building on x86_64, I need a cross-compiler compiled for x86_64 that can compile images for arm Mar 07 22:23:23 doesn't make sense that the SDK would include stuff that went into the arm distro Mar 07 22:23:28 assuming you want to do builds outside of yocto, sure. the toolchain built internally to build recipes is separate from the sdk Mar 07 22:23:42 no, let me try to explain again Mar 07 22:24:05 lets say someone wants a rootfs that includes ncurses. doesn't it also makme sense they'd want to be able to link against ncurses to compile their software on the host? Mar 07 22:24:14 yep Mar 07 22:24:19 so thats what i'm talking about. Mar 07 22:24:28 poulate_sdk populates an sdk based on what's in the rootfs for the image Mar 07 22:24:34 only they're nativesdk versions of the recipes Mar 07 22:24:59 that's my understanding of it, anyway. I've only rarely built with populate_sdk personally Mar 07 22:25:12 but suppose someone wants a rootfs for a ARM processor. Doesn't it make sense they'd need a native compiler that could produce ARM binaries. Wouldn't that also go in the SDK? Mar 07 22:25:51 and the distro might not even have a compiler Mar 07 22:26:14 yes, the sdk also builds a toolchain, the packages for the toolchain are in the aforementioned separate variables to control what else goes into the sdk other than what went into the image Mar 07 22:26:21 as i said, see image.bbclass for the exact variable names Mar 07 22:26:31 ok, will do Mar 07 22:27:10 specifically, line 8 of image.bbclass and line 10 of populate_sdk_base.bbclass Mar 07 22:27:15 (WRT the libs, isn't that why you also need a copy of the rootfs? Doesn't the native tools pick up the libs from that rootfs and not from within the SDK itself?) Mar 07 22:27:22 the former being the target packages, the latter being the host packages Mar 07 22:27:26 ? Mar 07 22:27:40 you mentioned ncurses Mar 07 22:27:42 unless you're using montavista or something, no crosscompiler/sdk you find is going to include a rootfs Mar 07 22:27:50 the toolchain has its own sysroot(s) Mar 07 22:27:58 wouldn't the ncurses libs be on the rootfs, not on the sdk? Mar 07 22:28:04 s/on the sdk/in the sdk/ Mar 07 22:28:25 yes, it will be in the rootfs, and populate_sdk will also add it to the sdk, because the crosscompiler isn't going to magically look in a rootfs running on a remote device somewhere to find the lib Mar 07 22:28:28 the sdk doesn't include the rootfs, you download it separately Mar 07 22:28:41 the rootfs goe son the device. the crosscompiler has *zero* knowledge of it Mar 07 22:28:53 the fact hat ncruses is in the rootfs isn't going to magically make you able to link against ncurses with the crosscompiler Mar 07 22:29:03 libncurses would have to go into the sdk for that Mar 07 22:29:07 which is what populate_sdk *does* Mar 07 22:30:04 the rootfs goes on the device, no doubt, but you can also use a copy of that on the host for libs and the like. The Yocto ADT plugin for eclipse, for example, requires you to give it a path to a rootfs Mar 07 22:30:28 don't know or care about the adt, personally. the sdk created by populate_sdk works with or without the adt Mar 07 22:30:33 and works without a rootfs Mar 07 22:31:12 but regardless, the sdk creation process has multiple aspects. it builds nativesdk packages for the host, and it adds target packages to the sdk sysroot based on what goes into the image (IMAEG_INSTALL/PACKAGE_INSTALL) Mar 07 22:31:22 well, I'll the variables you pointed me to Mar 07 22:31:28 the former is likely what you want, which means you likely want to add to the variabel i pointed you to earlier in populate_sdk_base Mar 07 22:31:34 yeah, agreed Mar 07 22:32:08 thanks for the suggestions Mar 07 22:33:58 | Computing transaction...error: Can't install gst-plugins-gl-meta-0.10.3-r2@armv7a_vfp_neon: no package provides gst-plugins-gl-apps Mar 07 22:34:45 My do_rootfs for my image used to work, any ideas on what this means? Mar 07 22:36:18 np Mar 07 23:16:14 i don't understand why sometimes bitbake create packages different then PACKAGES variable Mar 07 23:16:20 why does that happens? Mar 07 23:16:57 PACKAGES_DYNAMIC holds patterns of what packages other than PACKAGES may be created Mar 07 23:17:08 it's used to handle creation of packages dynamically based on what comes out of the build Mar 07 23:17:15 it's used for locales, etc Mar 07 23:18:14 the problem is that it's not creating the ones that I want to.. is there anyway to disable that? Mar 07 23:18:27 what do you mean by that? Mar 07 23:19:05 every package listed in PACKAGES will be created unless no files will go into it (unless ALLOW_EMPTY_ is defined, in which case it gets created even if empty) Mar 07 23:19:47 i have a recipe which has several libraries (pre-built) I want to create a package for each library, i do it but the deploy- direcotry inside the ${WORKDIR} lists one package, which in fact it's not in PACKAGES. Mar 07 23:20:20 another example, im appending the qt-mobility-x11 recipes Mar 07 23:21:39 I have a PACKAGES += "${PN}-publishsubscribe" and I do a FILE_${PN}-publishsubscribe += "..." but it doesn't create it Mar 07 23:22:08 although it creates a libqtpublishsubscribe1 package.. Mar 07 23:22:25 which is definitely not what i want.. Mar 07 23:22:40 is there any way to disable this dynamic package creation? Mar 07 23:22:49 for a specific recipe Mar 07 23:23:03 it's likely you're just encountering teh automatic package renaming based on shlibs Mar 07 23:23:10 the same packages are emitted, just with different names. Mar 07 23:23:13 see debian.bbclass Mar 07 23:23:40 :q Mar 07 23:24:10 in my case is rpm Mar 07 23:24:18 package manager is irrelevent Mar 07 23:24:44 kergoth: but still.. its not the case.. the contents are different.. and when I saw the do_package_write_rpm log Mar 07 23:24:51 it looks like it changes the ${PN} Mar 07 23:25:06 NOTE: Creating RPM package for libqtpublishsubscribe1 Mar 07 23:25:09 first of all, its FILES_, not FILE_ Mar 07 23:25:24 NOTE: Not creating empty RPM package for libqtpublishsubscribe-publishsubscribe Mar 07 23:25:25 second, bitbake only emits the binary packages listed in packages and those created dynamically with do_split_packages, it doesn't pull them out of thin air Mar 07 23:25:43 yes, that means your FILES doesn't match reality, as i said earlier, it doesn't create empty packages unless you set ALLOW_EMPTY Mar 07 23:25:56 you just need to use bitbake -e to make sure the variables are set to what you think they are Mar 07 23:26:07 kergoth: i know.. but when I do bitbake -e and I check the variables, they are correct Mar 07 23:26:41 well, bitbake isn't going to emit an empty package. fix your do_install, or fix your FILES variables. Mar 07 23:26:48 this is a lot simpler than you seem to think Mar 07 23:27:10 ok.. i will make sure of something Mar 07 23:27:54 whenever i see something seemingly inexplicable happening, it's almost always a mismatch between my expectations and reality, and bitbake -e and other similar mechanimss are invaluable for checking those assumptions Mar 07 23:30:39 if you're really curious about what's going on, you can always read the tasks in the bbclasses and see exactly what's going on. its easier if you know python, but you'll probably get the gist even without that Mar 07 23:32:05 kergoth: this is what is inside image/ http://paste.kde.org/689966/ Mar 07 23:32:36 yeah, that's what do_install puts there. what about it? Mar 07 23:33:07 i wnat to show you that the paths are correct Mar 07 23:33:19 again, debian.bbclass renames packages based on the shared library the package includes. if your package includes libqtpublishsubscribe, then yes, it will rename it to libqtpublishsubscribe1. Mar 07 23:33:21 the packages shouldn't be empty Mar 07 23:33:34 i just told you, either do_install is wrong *OR* the fiels variables are wrong Mar 07 23:33:40 i didn't say i was going to figure out which wa sthe case for you Mar 07 23:34:23 bitbake -e http://paste.kde.org/689972/ Mar 07 23:34:28 im not asking that Mar 07 23:34:35 im just trying to understand why this is not working Mar 07 23:49:37 ftonello: the libqtpublishsubscribe1 thing sounds like the debian package rename hook Mar 07 23:50:05 ftonello: meaning, it _is_ your ${PN}-publishsubscribe package Mar 07 23:50:13 ftonello: but the hook changed the file name Mar 07 23:50:40 evanp: I tink the hook changed the ${PN} package file name Mar 07 23:50:50 see the from the do_package_write_rpm Mar 07 23:50:53 ftonello: yes, exactly Mar 07 23:51:17 NOTE: Not creating empty RPM package for libqtpublishsubscribe-publishsubscribe Mar 07 23:51:34 but thats the thing Mar 07 23:51:53 I don't want that behavior.. is there anyway to disable that? Mar 07 23:53:14 you mean you want it to create an empty package? like kergoth said, ALLOW_EMPTY Mar 07 23:54:59 or do you mean you want your package to be named libqt-publishsubscribe? you'll have to figure out a way to change the debian rename hook to do that. disabling it globally'll probably break other stuff. Mar 08 00:09:39 evanp: ok.. thanks Mar 08 00:14:17 ftonello: I'd think about whether it really matters before bothering, though Mar 08 00:40:35 hello Mar 08 00:40:36 again Mar 08 00:40:37 :) Mar 08 00:53:44 hello guys , I'm doing something wrong and I can't understand what exactly Mar 08 00:54:04 i got yocto from git and is master branch Mar 08 00:54:19 and then I got raspberrypi meta layer Mar 08 00:54:53 in the rasberrypi metas there is a recipe that brings the hardware up Mar 08 00:54:59 ( and it works in qemu ) Mar 08 00:55:18 attempted to add python to the recipe Mar 08 00:55:45 IMAGE_FEATURES+= ... Mar 08 00:55:57 then after i build the image ... there is no python there Mar 08 00:56:17 if i try to make the python recipe .. it builds and work .. Mar 08 00:57:18 feydrautha80: there is no python IMAGE_FEATURE Mar 08 00:57:58 this means that I understood something wrong.. Mar 08 00:58:14 i thought if i want to add packes to the image .. i need to add them there Mar 08 00:58:20 IMAGE_FEATURES is used to install groups of packages, not individual packages Mar 08 00:58:22 you want IMAGE_INSTALL Mar 08 00:58:37 or, from local.conf, CORE_IMAGE_EXTRA_INSTALL Mar 08 00:58:43 you need to add python to CORE_IMAGE_EXTRA_INSTALL Mar 08 00:59:03 aww .. Mar 08 00:59:08 ok thanks Mar 08 00:59:32 this should be somewhere in the bitbake documentation right ? Mar 08 01:00:03 http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-CORE_IMAGE_EXTRA_INSTALL Mar 08 01:00:33 feydrautha80: read the quick start and developer manuals Mar 08 01:01:39 kergoth: it seems that AUTO_LIBNAME_PKGS = "" does the job Mar 08 01:03:08 thank ftoneelo and thank you kergoth Mar 08 01:04:14 ftonello: cool, so it was debian.bbclass causing the confusion. glad to hear you found a workaround Mar 08 01:07:05 kergoth: yes.. debian.bbclass checks for this AUTO_LIBNAME_PKGS.. and by default AUTO_LIBNAME_PKGS="${PACKAGES}" Mar 08 01:07:08 zenlinux: ping Mar 08 01:09:14 I really don't see what the problem with it is though. It doesn't hurt having it renamed, and IMAGE_INSTALL, etc can use the pre-rename names Mar 08 01:09:29 but either way Mar 08 01:33:59 so if i want to add python to a image :)) do i need to add "nativesdk-python" ? Mar 08 01:34:05 or Mar 08 01:34:22 where can I ask around about the recipes ? Mar 08 01:34:29 or read :) Mar 08 01:37:18 kergoth: becasuse its doing it wrong. its renaming the main package for something that I don't want.. im trying to split the package like the qt4 recipes does.. Mar 08 01:37:37 so I did a allow_empty to the main package, and just added RDEPENDS to it Mar 08 01:37:42 it seems its working Mar 08 01:37:55 actually its not a problem with debian.bbclass its just that I don't want to use it Mar 08 01:38:18 feydrautha80: you were just told, add python to CORE_IMAGE_EXTRA_INSTALL. Mar 08 01:38:26 feydrautha80: nativesdk is for sdks, not images/rootfs Mar 08 01:38:50 i added "python" to CORE_IMAGE_EXTRA_INSTALL Mar 08 01:39:42 but when i try to build the image fails because says : | Error: python not found in the base feeds (raspberrypi armv6-vfp armv6 armv5e-vfp armv5e armv5-vfp armv5 armv4 arm noarch any all). Mar 08 01:39:59 therefore i thought python might be called diffently Mar 08 01:40:10 try python-core instead Mar 08 01:40:18 aha :) Mar 08 01:40:19 see also bitbake -e python | grep \^PACKAGES= Mar 08 01:40:20 thanks Mar 08 01:40:23 * kergoth forgot about that Mar 08 01:40:25 np Mar 08 01:40:35 i found python with bitbake -s Mar 08 01:40:50 bitbake -s shows recipes, not packages. recipes can emit any number of packages :) Mar 08 01:42:16 ... i see .. and shouldn't "python" recipe .. contain all i need to basic python .. and even more ? Mar 08 01:42:44 it does. but you dont add recipes to IMAGE_INSTALL, you add packages. Mar 08 01:42:57 python is broken up into highly granular packages so we can keep images small Mar 08 01:43:05 so you can add just the packages/modules you want Mar 08 01:43:08 rather than the whole standard library Mar 08 01:44:12 so .. if i would need aaalll python .. i should add the packed with everythong to IMAGE_INSTALL Mar 08 01:45:00 if i want only the core .. i should add python-core to CORE_IMAGE_EXTRA_INSTALL Mar 08 01:45:21 i can't recall offhand if there's a meta-package to install all the individual python packages or not. check the bitbake -e command i gave, and also check for packagegroup- recipes Mar 08 01:45:57 i'll do that :) can't for the moment because the build dir is locked Mar 08 01:46:05 (building ) Mar 08 01:53:30 * kergoth nods Mar 08 01:55:15 a wait .. tasks have been renamed packages Mar 08 01:57:02 tasks were renamed to packagegroups, yes Mar 08 02:25:26 hey :) it finished .. ( with python-core in CORE_IMAGE_EXTRA_INSTALL ) Mar 08 02:25:49 thank your sir .. **** ENDING LOGGING AT Fri Mar 08 02:59:58 2013