**** BEGIN LOGGING AT Mon Apr 04 02:59:58 2016 Apr 04 06:03:37 hi I wrote a recipe for a package trousers, its working but giving a warning Apr 04 06:03:39 trousers-dev-0.3.13 was registered as shlib provider for libtspi.so.1, changing it to trousers-0.3.13 because it was built later Apr 04 07:31:26 good morning Apr 04 09:13:29 I have a use case of referencing SYSTEMD_PACKAGES_${PN} in a do_install script, but ${SYSTEMD_PACKAGES_${PN}} is not valid shell. Does anybody know from the top of their head how to do this? Apr 04 09:16:42 err, SYSTEMD_SERVICE_${PN} Apr 04 09:33:48 Or is there a way to run python snippets from shell? Apr 04 14:00:40 If I am looking to install drivers for a multitouch touchscreen, how do I go about including the driver when building my poky image given that the driver is just an executable? Apr 04 14:01:25 have a recipe that builds a package, install package into image Apr 04 14:01:26 you put it on your distro.conf Apr 04 14:01:35 ops Apr 04 14:02:28 Even if it is just an executable? Apr 04 14:02:35 Do I need the source? Apr 04 14:03:03 if you got given a binary, then make a recipe that simply copies the binary into a package Apr 04 14:04:03 OK, thanks. Apr 04 14:04:56 riz look at do_compile[noexec] for your recipe, and copy the file in do_install Apr 04 14:05:37 The executable file you mean? Apr 04 14:05:48 or inherit bin_package Apr 04 14:06:17 OK, so there are multiple ways. Apr 04 14:06:50 you don't need to do either of those really Apr 04 14:07:03 write a recipe that downloads and installs the binaries Apr 04 14:07:04 simples Apr 04 14:07:46 Will there be any changes I will need to make to the BSP to allow for mutlitouch screens? Apr 04 14:08:14 riz: that depends a lot on what exactly you call "the bsp" and what's in it :P Apr 04 14:08:57 Yeah, that is the confusing part for me. I just consider, for example, meta-intel to be my bsp. Apr 04 14:08:57 BSP is a word with so many meanings in the embedded world that I try not to use it Apr 04 14:09:26 the most common meaning for bsp is "whatever .tar.gz our board provider shipped with the board" Apr 04 14:09:35 I agree. I am finding that it is not as defined when dealing with linux Apr 04 14:09:42 but i've seen it to mean a bsp-layer, or "the sdk" Apr 04 14:10:41 Right. I would separate the SDK out of it. Apr 04 14:11:23 riz: more than likely you will have to enable hid multi touch in the kernel, if it isn't already Apr 04 14:11:31 riz: if the bsp is a yocto layer, you probably can integrate any change needed as a .bbappend in a separate layer, so you wouldn't need to change it Apr 04 14:12:35 .bbappend woould probably be the route given that if I pull any updates for my base kernel I still have my changes Apr 04 14:12:48 So, I guess the best approach is to add a touchscreen layer.. Apr 04 14:15:01 Would this be discussed in the Kernel Development documentation or BSP development docs? Apr 04 14:18:19 igor: when you say put it in your "distro.conf" (e.g. poky.conf) would it be the same as putting it in my bsp.conf (e.g. intel-corei7-64.conf)? Apr 04 14:18:57 make your own distro.conf Apr 04 14:19:17 literally just a case of copying poky.conf if you want to start simple, and delete anything that isn't relevant Apr 04 14:20:28 I see, but lets say I did put it in my bsp.conf, what is the disadvantage to that? Apr 04 14:22:13 why edit meta-intel for no reason Apr 04 14:22:24 if you want to upgrade meta-intel in the future, you'll have to unpick your changes Apr 04 14:22:44 you can create your machine conf Apr 04 14:22:53 and put what you want there Apr 04 14:23:23 Right, so best practice is to try and edit layers furthest from the hardware first? Apr 04 14:23:28 if you driver is a module, so you set the MACHINE_EXTRA_RDEPENDS with the package Apr 04 14:23:44 your* Apr 04 14:24:59 OK Apr 04 14:26:17 I like to separete what is hardware stuffs in a layer and software suffs in another layer Apr 04 14:27:41 there is many ways to do everything, so you can organize it as you wish Apr 04 14:27:43 hehehe Apr 04 14:29:18 Right. I agree, but it seems like sometimes things get a little blurry between the lines. It could also just be my lack of understsnding. Apr 04 14:32:17 Its kind of confusing in the begining, but generally you can find examples on google Apr 04 14:33:00 it helps a lot Apr 04 14:34:16 Yeah, the problem is that you have everyone doing a single thing 5 different ways and not every way works for your application so I am just trying to solidify a method that works for me. Apr 04 14:34:36 kkkk Apr 04 14:34:38 it strue Apr 04 14:34:42 its* Apr 04 16:31:06 Care to confirm a suspicion? Apr 04 16:32:01 Is there a significant difference produced in the installed state of the rootfs using IMAGE_INSTALL_append += "" vs RDEPENDS_${PN} = "" Apr 04 16:32:36 ie, is there a difference in the installation footprint of a package installed using either of these entries? Apr 04 16:33:10 one is direct, one is indirect via the dpes of something else you're already installing, presumably. the metadata of the package will obviously differ, but the final installed package list should not Apr 04 16:33:16 assuming i understand the question Apr 04 16:36:00 I'm sure you do. Just to be specific, I'm running into an issue with python2 vs python3 on a system. Apr 04 16:37:15 Python2 for instance is on the target and installed with the python-core or python-distribute; the core library is what one would expect. Apr 04 16:37:33 Python3 installed on the target is missing key components from the core library. Apr 04 16:38:03 Apologies if this sounds similar to a question asked on Friday, it's part of the same investigative thread. Apr 04 16:39:38 So what you confirm so far what I thought, i.e. that installing the python3-* should produce core library install. But everything from the lib-dynload directory is absent, resulting in an inability to load core modules. Apr 04 16:40:29 So far, I've been able to locate all the required files in the directory used for cross-compiling, on the build host. Apr 04 16:40:48 But those files are then apparently not moved into the package for installation. Apr 04 16:42:03 When I asked a similar question on Friday, I didn't have as specific an idea of the problem. But the advice given at the time was that if the file's signature emitted by a recipe differed from what was expected, the file would simply not be included in the package. Apr 04 16:42:44 This makes some sense, and it seems there's a good possibility that that is what is going on. But as I mentioned the files appear to be in the proper place on the build host. Apr 04 16:43:44 So my challenge is understanding what would prevent the files (that do indeed appear to exist, and do indeed appear to follow the correct signature) from making it into the package?? Apr 04 16:44:22 'signature' has no meaning in this context. are you talking about the file's path on disk? Apr 04 16:46:28 Apologies, yes. For instance, the manifest.inc calls out which files should be in a package, and those files appear to exist on the build host and follow the convention laid out in the manifest. Apr 04 16:50:44 If I may provide a more specific example? Apr 04 16:53:30 exist where on the build host? Apr 04 16:53:42 yes, a specific example would be helpful, this is too much hand waiving Apr 04 16:54:02 Ok Apr 04 16:55:16 Take for instance, the python-math package Apr 04 16:56:04 Here's entry in the python-2.7-manifest.inc: Apr 04 16:56:05 SUMMARY_${PN}-math="Python math support" Apr 04 16:56:05 RDEPENDS_${PN}-math="${PN}-core ${PN}-crypt" Apr 04 16:56:06 FILES_${PN}-math="${libdir}/python2.7/lib-dynload/cmath.so ${libdir}/python2.7/lib-dynload/math.so ${libdir}/python2.7/lib-dynload/_random.so ${libdir}/python2.7/random.* ${libdir}/python2.7/sets.* " Apr 04 16:56:54 Each of the files can be located in a directory on the build host that, if I understand correctly, is used during the cross compile: Apr 04 16:57:58 home/smiller6/gdp9/genivi-demo-platform/gdp-src-build/tmp/work/x86_64-linux/python-native/2.7.9-r1.1/image/home/smiller6/gdp9/genivi-demo-platform/gdp-src-build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/lib-dynload Apr 04 16:58:35 that's a build for your build architecture, not for your target architecture Apr 04 16:58:40 Right Apr 04 16:58:55 IIRC you mentioned that you expected the file on target? Apr 04 16:59:27 find home/smiller6/gdp9/genivi-demo-platform/gdp-src-build/tmp/work/ -maxdepth 2 -type d -iname 'python3' Apr 04 16:59:39 Yes, so for python2, each of the files and dirs that I just mentioned correctly exist on target. Apr 04 16:59:57 But the directory you quoted wasn't the one where they have been built for the target Apr 04 17:00:00 the only path you pasted to irc is lib-dynload, not the contents of it Apr 04 17:00:12 and it was from python-native, not python Apr 04 17:00:14 So looking at this folder tells you nothing about what's going to be on the target Apr 04 17:00:21 * kergoth nods at neverpanic Apr 04 17:00:33 I agree, and I think I'm still with you so far. Apr 04 17:01:26 So, what would prevent something in this mentioned directory from making it to, say the package intended for the target? Apr 04 17:01:34 Give me a moment to locate that directory... Apr 04 17:02:41 smiller6: in the general case, python-native is built for the architecture of your build machine, but python will be built for the architecture of your target Apr 04 17:02:47 home/smiller6/gdp9/genivi-demo-platform/gdp-src-build/tmp/work/corei7-64-poky-linux/python/2.7.9-r1/image/usr/lib/python2.7/lib-dynload Apr 04 17:03:01 so python-native might be x86_64, but python could be an arm architecture if that's what your board runs Apr 04 17:03:09 Ok, yes I think I follow so far. Apr 04 17:03:22 that's the correct location for python Apr 04 17:03:24 comparing them will tell you absolutely nothing. look at python, not python-native Apr 04 17:04:22 Yes, the location just provided is for python, and appears to be correctly populated, and the contents of which make it into the package and onto the target. Apr 04 17:04:29 (Thank you for your patience so far) Apr 04 17:05:13 But this directory: Apr 04 17:05:15 home/smiller6/gdp9/genivi-demo-platform/gdp-src-build/tmp/work/corei7-64-poky-linux/python3/3.3.3-r1.0/image/usr/lib/python3.3/lib-dynload Apr 04 17:05:48 the corresponding one for python3, is not correctly populated with the expected files from the manifest. Apr 04 17:06:35 Apologies if I'm going about this incorrectly. So am I to understand that this means that something has prevented an actually proper build of python3.3 for the target platform>? Apr 04 17:06:42 as i told you last week, you should look at the log of the python build to see why it didn't emit those files Apr 04 17:07:36 Yes, you did mention that. Apr 04 17:09:44 Forgive me, is the log I should be looking for specific to the python3 build or for the whole build run? Apr 04 17:10:26 ie /tmp/buildstats or /tmp/log/cooker/intel-** Apr 04 17:10:29 log files are written for each task of each recipe which is run, in the temp/ subdir of the recipe's workdir Apr 04 17:10:32 neither of those are it Apr 04 17:10:43 tmp/work/*/*/temp/log.do_* Apr 04 17:10:57 Ah, thank you very much, I shall take a look. Apr 04 17:10:57 this is in the yocto project documentation, i'm certain Apr 04 17:11:15 I'm sure you are correct. Apr 04 17:21:53 Thank you for that advice, the files appear to be failing in the do_compile step, preventing them from being built, preventing them from being included in the package. Apr 04 17:22:09 Thanks for pointing me in the right direction. Apr 04 19:00:53 Hmm, think I need to switch bitbake-layers to using an extensible plugin command mechanism like devtool/recipetool. Any objections? Apr 04 22:52:00 bluelightning: any thoughts on something like https://gist.github.com/kergoth/21bd25d49f5d1db8552215774b5a5450 ? worst case if it moves to plugin based, could keep those in a separate layer, but i'm curious about general interest Apr 04 22:54:13 kergoth: most of that looks reasonable Apr 04 22:54:32 it would be nice to have the find-* as one command though if that's practical Apr 04 22:57:12 yeah, i was thinking about that too. just find-layers and args for via name and via path, and possibly default to pulling in deps rather than that being a separate command, not sure Apr 04 22:57:53 okay, thanks for the input, i'll keep at it **** ENDING LOGGING AT Tue Apr 05 02:59:58 2016