**** BEGIN LOGGING AT Wed Dec 10 02:59:59 2014 Dec 10 08:01:27 good morning Dec 10 08:03:39 hi mckoan Dec 10 08:11:48 hi woglinde Dec 10 08:45:57 morning all Dec 10 08:46:24 hi bluelightning Dec 10 08:47:17 hi bluelightning Dec 10 08:47:24 hi mckoan, woglinde Dec 10 09:05:16 hello ! Dec 10 09:11:14 morning everyone Dec 10 15:01:56 JaMa, you did apply the other patches I posted with the first pyqt update? Dec 10 15:04:31 yes Dec 10 15:05:50 wasn't it caused by missing sip dependency? Dec 10 15:14:50 what I sent should depend on sip and sip-native Dec 10 15:15:00 my qemu-arm build worked Dec 10 15:15:06 I need to nuke tmp etc and try again Dec 10 15:44:13 moin Dec 10 15:45:13 * nerdboy back on beaglebone after developing a Python course/module for HourOfCode... Dec 10 16:24:06 I need to support multiple boards (with different BSP layers), and each one is going to have its own /etc/fstab. I'm not sure how to express this in bitbake recipes. Dec 10 16:24:36 The base-files recipe in poky will install /etc/fstab, and there's no easy way to remove that without forking the recipe. Dec 10 16:25:35 I can do a .bbappend to get it to use *my* fstab in the BSP layer, but then I can't have more than one BSP layer enabled at one time. Dec 10 16:26:04 Any ideas on how to solve this? Dec 10 16:26:07 dunno what poky does to break that, but oe-core's base-files with multiple bbappends works just fine Dec 10 16:27:35 koen: Ok, so each BSP layer does a .bbappend -- how do I make sure that the right one goes into the image? Dec 10 16:27:47 koen: or is the "best practice" to only have _one_ bsp layer ever enabled? Dec 10 16:28:03 no Dec 10 16:28:11 just use machine overrides in every bbappend Dec 10 16:29:21 which you should be doing anyway in BSP bbappends Dec 10 16:30:06 koen: so the .ipk that gets output -- it gets a machine-specific arch because of: Dec 10 16:30:09 PACKAGE_ARCH = "${MACHINE_ARCH}" Dec 10 16:30:15 in the base-files recipe? Dec 10 16:30:33 or if there are overrides in SRC_URI Dec 10 16:30:43 e.g. base-files/mymachine/fstab Dec 10 16:32:54 koen: OK, I don't have a full grasp on how to use machine overrides. Dec 10 16:33:15 koen: I'll go find some doc or examples. Thanks! Dec 10 16:35:42 files dir is still machine-specific, right? Dec 10 16:37:41 nerdboy: not in itself Dec 10 16:37:55 ie, recipes-core/base-files/base-files/raspberrypi/fstab, recipes-core/base-files/base-files/beaglebone/fstab Dec 10 16:37:57 nerdboy: only if you add a subdir names after a machine Dec 10 16:38:18 right, that one is machine specific Dec 10 16:38:23 that's what i meant, just didn't say it very well... Dec 10 16:39:17 one .bbappend, many $machine/fstab variations Dec 10 16:40:12 or one bbappend per BSP Dec 10 16:40:16 it doesn't really matter Dec 10 16:40:27 you only get into problems if your BSP is being anti-social Dec 10 16:40:40 i have several BSPs with an "overlay" layer Dec 10 16:40:43 e.g. recipes-core/base-files/base-files/fstab Dec 10 16:48:29 gabrbedd: SRC_URI_append_mymachine += "file://fstab" Dec 10 16:48:40 that will only override fstab if MACHINE=mymachine Dec 10 16:51:36 it will still be antisocial if you have a recipes-core/base-files/base-files/fstab in your BSP Dec 10 16:51:48 and the file is already in the original SRC_URI Dec 10 16:52:24 doing recipes-core/base-files/base-files/beaglebone/fstab and mangling FILES_EXTRAPATH in the .bbappend should be all you need Dec 10 16:52:41 antisocial? Dec 10 16:53:17 antisocial like breaking all other machines when including your BSP Dec 10 16:54:10 oh, that kind of antisocial Dec 10 16:58:39 Thanks, guys. If anyone has a link to docs/examples... that would be greeeeeeeat.... :-) Dec 10 16:58:43 * gabrbedd searches... Dec 10 17:01:38 http://www.yoctoproject.org/docs/1.7/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp Dec 10 17:16:08 koen: about antisocial behaviour, do you know of a good way to do per-image customizations to packages? if I add a bbappend that adds a busybox or kernel config fragment, and i'd like that to only apply for a certain image, but not affect others. What would you do? cause if I just add a busybox_%.bbappend, it'll affect all images as soon as i include my layer Dec 10 17:20:06 mago_: I've been doing it with MACHINE_FEATURES Dec 10 17:20:22 mago_: but that doesn't _exactly_ solve your "per-image" problem. Dec 10 17:20:43 if anything, it would be a IMAGE_FEATURE i guess Dec 10 17:22:17 yeah Dec 10 17:28:08 you'd need to write your own code to handle a random IMAGE_FEATURE Dec 10 17:47:28 is it good practise to set MACHINE_FEATURES on a per-image basis? (is it even possible) Dec 10 17:49:27 mago_: not at all. Dec 10 17:49:36 it's even wrong. Dec 10 17:50:13 MACHINE FEATURES is meant to be the same across all recipes. if you change it in an image recipe (which is just a .bb file like any other recipe) you might get into troubles Dec 10 17:51:07 mago_, that would be an image feature then :) Dec 10 17:51:30 Crofton|work: yeah, but does a particular kernel config fragment qualify as a IMAGE_FEATURE? Dec 10 17:51:43 no Dec 10 17:52:09 mago_: i think that was a joke from Crofton|work ;-) Dec 10 17:52:23 oh :) a little too tired! Dec 10 17:52:28 only a little joke, I believe we ahve image features? Dec 10 17:52:34 in an image recipe you can only choose which binary package you pull in. Dec 10 17:52:42 yes. Dec 10 17:53:04 right, you can't actually affect how those packages are built Dec 10 17:53:14 (not from the image recipe, at any rate) Dec 10 17:53:18 ndec: so how would you do it, if you want per-image customization of an application Dec 10 17:53:36 it depends on the customization.. Dec 10 17:53:52 a change to busybox config, a change to kernel config Dec 10 17:54:16 again, images are simple recipes to assemble pre-built binary packages. you can't change all the binary packages are built from an image recipe context Dec 10 17:55:34 i guess i could fork the recipe itself, like busybox. But then I'd also have to somehow replace the image dependencies, so instead of depending on busybox, it depends on busybox-with-customization Dec 10 17:57:36 well. it could be an XY problem.. maybe you can try to explain better what you need to achieve? Dec 10 18:01:01 well, product X needs some features from busybox, while product Y needs a completely different set. We could create a superset config, but then we'd gradually move towards having every single feature enabled. So when product Z wants to build something really small, it'll be a problem. A very specific case is that product X needs to enable certain device drivers, and they cannot compile it as kernel modules since Dec 10 18:01:03 these drivers control a peripheral device that needs to be initialized as soon as possible after power-on. We simply can't wait for the kernel to power up, boot into userspace and insmod the proper module Dec 10 18:01:24 product Y however has no interest whatsoever in this kernel module Dec 10 18:02:16 we could of course separate these products into two layers, and have them append the appropriate stuff to the kernel recipe. but i guess they would then become "antisocial" layers (as koen puts it) Dec 10 18:03:56 that's a good practical use case... not sure how to best solve it. Dec 10 18:04:10 any good examples of packaging a machine specific conf file Dec 10 18:06:28 Crofton|work: so the kernel module case would be a MACHINE_FEATURE? Dec 10 18:07:43 hmm Dec 10 18:07:44 I think you'd really need separate distro configs to support this in our model Dec 10 18:08:06 where are the machine features defiend Dec 10 18:08:09 (which implies separate build directories) Dec 10 18:08:11 particularly when it comes to building two separate kernels Dec 10 18:08:32 MACHINE_FEATURES should be set in the machine configuration Dec 10 18:08:49 bluelightning: the way we do it right now is that each product gets its own layer. And they can override the hell out of our core layers. But if you ever try to put 2 product layers into the same tree, it will blow Dec 10 18:08:51 yeah, I am trying to remember what file converts them to package info Dec 10 18:09:36 mago_: it should be possible to do it in the same layer with different distro configs (or different machine configs) Dec 10 18:09:50 I was thinking machine configs Dec 10 18:10:02 bluelightning: so 1 machine per product, even though they run on the same MACHINE? Dec 10 18:10:17 that would be one way of handling it Dec 10 18:10:26 it all depends on how different those two products end up being Dec 10 18:11:02 pretty much the only thing they have in common is that they run on the same SoC :) Dec 10 18:11:21 right, then that probably is two different machines Dec 10 18:11:49 at least that will give you quite a bit of flexibility Dec 10 18:11:50 imagine doing products on raspberry pi, and then try to package each type of raspberry pi-based idea in an image, within the same layer Dec 10 18:12:48 in what does a separate DISTRO help me? Dec 10 18:12:55 well, that's not exactly the same situation - you could still be choosing between different sets of packages in several images in that case Dec 10 18:13:12 a separate distro just gives you a place to specify different configuration Dec 10 18:13:34 PREFERRED_PROVIDER_virtual/kernel for example Dec 10 18:13:48 oh, so i would also need to fork the kernel for each product? Dec 10 18:14:12 i really don't need to change the source-code of the kernel, just its configuration Dec 10 18:14:20 "fork" is a strong word, but you are talking about different kernel build configurations Dec 10 18:14:39 you can still keep the same source between the two Dec 10 18:15:02 oh, you mean I have 2 kernel recipes, sharing same SRC_URI, but applies different defconfigs? Dec 10 18:15:11 (and/or cfg fragments) Dec 10 18:15:13 right, yes Dec 10 18:15:44 okay, yeah, i guess that would work. I will test out some of these ideas and see what my product guys thinks about it Dec 10 18:16:07 thanks for the input bluelightning Crofton|work ndec koen et al :) Dec 10 18:16:41 np Dec 10 18:16:44 last thing, do you know of any OE-based products that have their "product" layer available online? Dec 10 18:17:02 poky ;-) Dec 10 18:17:18 https://github.com/EttusResearch/meta-ettus Dec 10 18:20:17 thanks Dec 10 18:57:03 can someone remind me how to make a machine spcific conf file and a regular main package? Dec 10 18:57:15 jama used some words, but I lost them Dec 10 20:16:11 are there any special quirks when installing files to subdirs of ${D}${localstatedir} ? I'm trying to install a file into ${D}${localstatedir}/run, and the TMPDIR/../image/ directory of my package looks good, but when i look into my TMPDIR/../package, the run directory has been moved outside of /var and instead a run symlink to itself has been created? Dec 10 20:17:24 so of course, the some files are not shipped and I get a warning Dec 10 20:22:37 it would seem something automatically breaks out /var/run stuff into /run Dec 10 20:25:36 oh, i see. /run is mounted on tmpfs on the running device. curious that OE knows this and tries to adapt during buildtime.. Dec 10 20:26:11 is anyone in here? Dec 10 20:26:27 no Dec 10 20:27:25 Can someone please help me adding a package to IMAGE_INSTALL in the con/local.conf file. when i build it using angstrom-lxdd-image the build will fail, however when i build the package by itself using bitable it is fine Dec 10 20:37:45 anyone got any advice for me to get this issue solved? I'm new and need some help! Dec 10 20:41:15 how does it fail? Dec 10 20:43:17 by saying package not found Dec 10 20:43:41 ok, so it doesn't find the package Dec 10 20:44:05 have you double checked the package name? and that the package was created? Dec 10 20:44:30 i am not understanding something, the package is called alvar, and I can type "bitable alvar" and it will build it with no errors Dec 10 20:44:54 but as soon as I add it to IMAGE_INSTALL it spits out a giant error message and at the end it says "alvar not found" Dec 10 20:46:08 when I do the regular command "bitbake alvar" I can see the package, and it downloaded the source correctly and was able to compile it. Dec 10 20:52:51 I can show you my recipe, or my conf/local.conf file please let me know if anything will help you Dec 10 20:55:01 http://layers.openembedded.org/layerindex/recipe/27294/ Dec 10 20:55:09 this recipe? Dec 10 20:56:06 no i wrote the recipe for alvar, that is for the ROS version of alvar I am not using ros Dec 10 20:56:53 so check the packages it actually makes Dec 10 20:57:11 tmp.../deploy/ipks or something along those lines Dec 10 20:58:29 when i use "bitbake alvar" or when i use "bitbate angstrom-lxde-image Dec 10 21:01:44 the packages should be there after you bitbake alvar Dec 10 21:02:02 then you need to add the package names, not he recipe name, to the image recipe Dec 10 21:05:28 i am adding the recipie name, i will rebuild it and try to add the package name thank you for you help so far Crofton Dec 11 00:58:18 anyone have any advice to help me get a package i created working? the package is called Alvar, and I was able to use the command "bitbake alvar" without any errors, when I add it to the image using IMAGE_INSTALL += "alvar" I get the error "opkg_install_cmd: Cannot install package alvar." the alvar package appears to be there, any advice would help me Dec 11 00:59:21 also if i look at the log i see this "Unknown package 'alvar'." Dec 11 01:00:41 crofton you still here? I just finished building the whole image to look at what you recommended Dec 11 01:14:19 matt123456789: sounds like your do_install didn't install anything, so no package was created. Dec 11 01:29:22 ker: thanks for the response, I'm very confused by this most recipes don't have any do_install, do i have to have it? If i was to install alvar normaly i would use cmake to generate a make file, the do sudo make install Dec 11 01:36:42 cmake.bbclass should handle it automatically assuming you inherit cmake Dec 11 01:47:49 i do use inherit pkgconfg and cmake Dec 11 01:48:06 is there anyway I can see why it fails? and why bitbake alvar works without any errors? **** ENDING LOGGING AT Thu Dec 11 02:59:58 2014