**** BEGIN LOGGING AT Thu Nov 19 02:59:58 2015 Nov 19 08:07:22 good morning Nov 19 09:42:29 is an increasing PR important in any way at system build time, or is it purely for the package manager on the target to know when important changes have been introduced? Nov 19 10:08:05 Ulfalizer: the latter, and if you enable the PR service it happens for you Nov 19 10:08:11 manual PR bumps are historical now Nov 19 10:43:34 rburton: ok, ty Nov 19 11:40:51 Hi, has anyone installed perf to target? It depends on binutils and nothing provides it for the rootfs, I just find packages for build time and (native) sdk. Nov 19 11:45:47 ah gplv3 issue in bitbake, sorry Nov 19 12:05:08 if I have a recipe with a src uri that has a pv tag on the git url, but PV is not explicitly set in the recipe what does it default to? Nov 19 12:09:57 CTtpollard: it's taken from the recipe file name Nov 19 12:10:21 joseppc: ty Nov 19 14:05:25 Is there any guidance on building initramfs images with the oe build system? Nov 19 14:06:33 I have found the OE layer for it, and there's some mention of initramfs kernels in the yocto development manual Nov 19 14:16:44 Is it possible to build multiple versions of a package for a single rootfs ? Nov 19 14:17:58 milan_: I would think so Nov 19 14:19:06 CTtpollard: How can we achieve it ? since only one version of a particular recipe can be built at at a time Nov 19 14:24:32 I guess what I'm trying to achieve is the same as building a "live" image - is adding "live" to the IMAGE_FSTYPES all that should be required to build a live image? Nov 19 14:24:39 That can't be right ... Nov 19 14:28:19 Does anyone know how the "live" images are achieved in yocto? Nov 19 14:28:39 (As in, what filesystem overlay software is used? Union, aufs, overlayfs, etc?) Nov 19 14:29:51 milan_: you'd need to have the version in the recipe name, like there's gcc-5.2 and gcc-4.9 Nov 19 14:30:12 and then ensure that they don't conflict Nov 19 14:30:19 (or libpng and libpng12, or glib and glib-2.0) Nov 19 14:30:32 basically you just need to make sure that PN is unique Nov 19 14:32:42 rbutton: Ok. Thanks! Going to try that now. Nov 19 14:33:06 rburton: Ok. Thanks! Going to try that now Nov 19 14:52:47 I'm sorry if this is a stupid question but I am extremely new to yocto. How would I install python3 on a yocto linux without access to the internet? Nov 19 14:57:29 Yocto is built from scratch, so the correct way to install it is to include it in the build Nov 19 14:57:43 but I'm assuming you've got an installed yocto linux system that you want to add python3 to Nov 19 14:57:51 correct Nov 19 14:58:33 What else is available in your system? You can always build python3 from source if you have dev tools on your target Nov 19 14:59:42 Which kind of tools would be available on yocto to install packages (except building from source?) Nov 19 15:00:20 PTBD: depends on what is in your image Nov 19 15:00:31 there's no such thing as a "standard yocto image" Nov 19 15:00:36 that's pretty much the point Nov 19 15:01:00 rburton1: I understand that but I don't know what to start looking for on my image. I did not create that image and I am not familiar with any tools that yocto uses to acomplish what I need Nov 19 15:02:14 In your case, I think your best bet right out of the gate is to download the python3 source distribution, transfer it to your target, and try to build it from source Nov 19 15:02:24 following the instructions from python.org Nov 19 15:02:43 you can do a quick check for tools like make, gcc, etc to see if that's feasible first, to save yourself some time. Nov 19 15:02:49 What is your target system? Nov 19 15:03:16 or more to the point where did your image come from, and can the people who provided it give you python3 packages. Nov 19 15:03:31 Yeah, that Nov 19 15:05:13 make is available but it looks like gcc is not. Nov 19 15:05:53 @rburton1 is right - you're best off going to the maintainers of the image you're running, and seeing if they provide python3 package files Nov 19 15:06:01 I see Nov 19 15:06:15 Whats your target? (Curiosity, here) Nov 19 15:06:32 a router with a guest os Nov 19 15:06:42 Ah yeah. Nov 19 15:07:04 Is this a custom installed image, or did it come from the manufacturer? Nov 19 15:07:21 The guest os came with the router preinstalled Nov 19 15:07:36 Yick Nov 19 15:07:58 there was a short tutorial on how to install (for example) python. they used a ubuntu virtual machine as a rpm server from which they used 'smart install ...' Nov 19 15:08:50 But I wouldn't know how to apply that. Would the command 'smart install' have to build the rpm? Or do rpms come precompiled for a architecture? Nov 19 15:09:25 I think you're clear out of yocto territory here and into your vendor specific software for package management Nov 19 15:10:33 I don't think "smart install" maps to anything anyone here is familiar with. Best to go with your vendors documentation, or if that fails, get in touch with them. Nov 19 15:10:58 you mean you don't know what smart install is? Nov 19 15:11:12 Yeah, that's not a yocto thing Nov 19 15:11:16 (to my knowledge) Nov 19 15:11:28 That's probably something provided by your vendor for package management. Nov 19 15:11:38 oh, I thought it is the default package manger on yocto. Nov 19 15:11:59 There's essentially no default *anything* on yocto Nov 19 15:12:00 https://www.yoctoproject.org/blogs/khem/2013/get-smart-smart-package-manager or am I terribly misunderstanding something here Nov 19 15:12:20 oh! I can totally be mistaken, then! Nov 19 15:12:45 Welp! I've never used it, so you're at least out of *my* depths Nov 19 15:13:41 ok Nov 19 15:13:44 But stick around and maybe someone else here can help. Nov 19 15:14:18 <__b4ub> Got an issue with the same iptables command not behaving in the same way on yocto and on my desktop pc (mainly --dport and -p, silently not working on yocto). Any idea about where I could find the information related to what's working ? Nov 19 15:15:17 ryansturmer: thank you Nov 19 15:20:00 ryansturmer: may I ask an stupid question again? the routers architecture is i686, wouldn't I be able to use a precompiled package? Nov 19 15:39:21 Hi guys! quick question: can you build systems with yocto in any architecture? or only in x86? Nov 19 15:50:55 pedroalvarez, do you mean like an ARM host system building for say a powerpc target deployment image, or .... ? Nov 19 15:51:29 yes, for example Nov 19 15:52:06 yes Nov 19 15:52:28 x86 host is the most tested as its the fastest, but there's no reason why arm host shouldn't work Nov 19 15:53:40 good, thanks :) Nov 19 16:32:44 @PTBD You may be able to use a precompiled package Nov 19 16:33:03 you can always grab an rpm or something and try it out Nov 19 16:33:28 Guys I've convinced my yocto build process to build an initramfs image to run a "live" installation Nov 19 16:33:48 but I'm having difficulty with my boot process getting the kernel to use that image. Nov 19 16:34:45 Does anyone know if, when I build with "live" in my IMAGE_FSTYPES is the image built into the kernel? Or is it stored externally such that I have to tell the kernel where to find it. Nov 19 16:34:56 I can see in my installation that it's placed at /boot/initrd Nov 19 16:35:25 but passing initrd=/boot/initrd to my kernel command line doesn't seem to work. Nov 19 16:35:35 (I am booting with u-boot) Nov 19 16:47:51 Hi, can anyone tell me if it is possible to have two *.inc files in different layers? Nov 19 16:49:36 I need to change the SRC_URI in meta-fsl-arm/.../linux-ls1.inc from the Freescale repository to my own clone Nov 19 17:25:43 benjamirc: ping Nov 19 17:35:36 jes vmrod Nov 19 17:42:22 What do I need to clean with bitbake to get a rebuild of the kernel? Nov 19 17:43:32 I have changed CONFIG_INITRAMFS_SOURCE in my image .bb file, but this hasn't provoked a kernel rebuild, so I want to clean whatever is appropriate to trigger a rebuild Nov 19 17:44:36 ryansturmer: so our manual claims that CONFIG_INITRAMFS_SOURCE is a variable you can set, but searching around I don't think that it is Nov 19 17:44:57 so I don't think any cleaning will help Nov 19 17:45:04 what are you attempting to do exactly Nov 19 17:45:04 Ha! Nov 19 17:45:05 ? Nov 19 17:45:17 Well, I thought it was suspicious that that happened also to be the name of a kernel config parameter Nov 19 17:45:23 Thought bitbake was doing something clever for me. Nov 19 17:45:41 Do you have any experience with building a 'live' image? Nov 19 17:46:00 I feel like what I want to do is simple, but it's really fighting me Nov 19 17:46:50 a little Nov 19 17:49:08 Well, so I want a "live" distribution, which I understand is achieved the way most live distros are, where in an initrd you mount the rootfs read only, then do a tmpfs (or similar) overlay with union,aufs, or overlayfs Nov 19 17:49:33 so I added "live" to my IMAGE_FSTYPES variable, which according to the manual, is supposed to do most of the work Nov 19 17:50:04 it did indeed build a core-image-minimal-initramfs-machine.cpio.gz image for me Nov 19 17:50:30 and that image does indeed land in my final distribution, in /boot alongside my linux kernel image Nov 19 17:51:10 however, nothing I pass to the kernel by way of parameters seems to be able to convince it to use the initrd Nov 19 17:52:33 it seems like a lot of kids these days are just building the initramfs into the kernel image itself to simplify things - but I'm not sure how to tell it "hey, go here for this image, and build it in as your initrd" - that's what that kernel parameter is all about, I just don't know how to hook it up. Nov 19 17:53:03 Although, I kind of like the idea of the initramfs being a separate file - so I can tinker with it if I want (and I almost certainly will want) without repackaging my kernel. Nov 19 17:53:08 So that's my life story, basically. Nov 19 17:53:14 it's supposed to do that for you by way of INITRAMFS_IMAGE being set to point to the image recipe Nov 19 17:53:36 supposed to build it into the kernel Nov 19 17:53:41 if you "git grep CONFIG_INITRAMFS_SOURCE" you can see how it does that Nov 19 17:54:22 by including "live" though in that FSTYPES variable, that should be happening for me, you're saying? Nov 19 17:55:23 (And of course by not obliterating INITRAMFS_IMAGE myself somewhere else Nov 19 17:55:30 yes Nov 19 18:02:26 Well, my system doesn't appear to be doing the initramfs thing, because I see no evidence of it in the log, at startup or in the kernel message buffer Nov 19 18:08:34 Is there a place I can see the kernel configuration after it's been all fused with configuration fragments etc? Nov 19 18:09:23 because I should be able to see that configuration parameter in there, right? if INITRAMFS_IMAGE is doing its job? Nov 19 18:09:44 ryansturmer: yes, there should be a .config file in a build- subdirectory under the workdir for the kernel Nov 19 18:09:53 yes, it should show up there Nov 19 18:16:10 Man there's a lot of directories Nov 19 18:16:13 which is the workdir for the kernel Nov 19 18:16:45 if I'm in tmp/ Nov 19 18:16:51 benjamirc: I was thinking if yocto could be benefict from autoGFDO Nov 19 18:17:23 ryansturmer: bitbake -e virtual/kernel | grep ^WORKDIR= will point you to the kernel's workdir Nov 19 18:17:44 right, what challinan said ;) Nov 19 18:21:07 There's a defconfig here, and it doesn't contain the CONFIG_INITRD_SOURCE (it's set to empty string) Nov 19 18:21:32 INITRAMFS_SOURCE excuse me Nov 19 18:23:26 hmm Nov 19 18:23:31 is it possible I Have a recipe that's just overwriting the kernel configuration Nov 19 18:23:33 is INITRAMFS_IMAGE actually set? Nov 19 18:23:51 how do I check that? Nov 19 18:24:03 bitbake -e virtual/kernel | less then search for INITRAMFS_IMAGE with / Nov 19 18:25:37 No, it appears never to be set. Nov 19 18:25:52 INITRAMFS_IMAGE does not appear in the output of bitbake -e virtual/kernel at all Nov 19 18:27:09 ah, I guess it's doing it through INITRD_IMAGE Nov 19 18:27:42 which is something subtly different Nov 19 18:29:57 In meta-python, how do I use a different version of a package? Nov 19 18:30:02 (what is $PV?) Nov 19 18:31:20 kratsg: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PV Nov 19 18:31:53 kratsg: PREFERRED_VERSION_ is how you select between different versions if the one built by default isn't the one you want Nov 19 18:32:10 Trying to build on Ubuntu 15.10 and running into this problem with qemu-native: http://patchwork.openembedded.org/patch/106579/ Nov 19 18:32:14 Is there a workaround? Nov 19 18:32:14 What if there is only one version? I'm looking at python-twisted right now. Nov 19 18:32:27 It has only 13.2.0 -- so I think I need to make a new recipe in there, update the hash and version. Nov 19 18:32:32 kratsg: er, then you wouldn't need to select one... ? Nov 19 18:32:43 kratsg: ah right now I understand Nov 19 18:32:43 I need a later version of twisted. Nov 19 18:32:54 kratsg: right yes, you'd need to create a recipe for that version Nov 19 18:32:56 [pip install on the board doesn't work] Nov 19 18:33:26 Should there be a pull request to the github repo with the new version added? It's not clear what people normally do. Nov 19 18:33:43 tastycactus: yes - see https://bugzilla.yoctoproject.org/show_bug.cgi?id=8553 Nov 19 18:33:44 Bug 8553: normal, Medium+, 2.1, eduard.bartosh, IN PROGRESS REVIEW , qemu-native to build on Ubuntu 15.10 Nov 19 18:34:18 kratsg: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Nov 19 18:35:33 bluelightning, thanks Nov 19 18:35:35 gotcha. Nov 19 18:40:57 bluelightning: now that I've written the recipe for the new version Nov 19 18:41:03 what's the straightforward way of making sure it's right? Nov 19 18:44:27 Hrmm, it can't find it. I tried "15.4.0_python-twisted" Nov 19 18:45:41 kratsg: bitbake python-twisted should be building the new version if you've put it in a place that bitbake can find it Nov 19 18:46:10 Right, it looks like `bitbake -s` reports the new version Nov 19 18:46:32 if I wanted to select the older version (13.2.0) I would have to do `13.2.0_python-twisted` instead? Nov 19 18:47:08 or, you mean edit the local.conf and add the PREFERRED_VERSION_python-twisted = 13.2.0 ? Nov 19 18:47:24 bluelightning FWIW INITRD_IMAGE doesn't appear in the bitbake -e virtual/kernel output either. Nov 19 18:48:56 ryansturmer: INITRD_IMAGE is handled at the image level Nov 19 18:49:04 rather than the kernel Nov 19 18:49:20 so again, though that's not something I should have to specify, right? Nov 19 18:49:36 kratsg: you can't build a specific version on the command line - you can set PREFERRED_VERSION_python-twisted though Nov 19 18:50:05 kratsg: it should pick the latest version (assuming you haven't put it in a layer that has a lower priority than the one with the older version) Nov 19 18:50:11 Oh, I see. This makes sense. Nov 19 18:50:18 I'm running into the license file checksum not matching. Nov 19 18:51:03 and the kernel .config in the workdir should be turning up with the CONFIG_INITRAMFS_SOURCE by way of the live-image class? Nov 19 18:51:56 i think I got it. Thanks. I'll see if I can do a PR successfully later. Nov 19 18:52:09 But I might create my own meta specifically for the series of python packages I need for sure. Nov 19 18:52:15 so that I can install/roll my own. Nov 19 18:52:38 since I have a custom pypi python package I wrote that depends on the twisted version, etc. Nov 19 18:53:54 errr, so I have the warning that files/directories were installed but not shipped Nov 19 18:54:04 I should probably update the recipe to include/ship them. Nov 19 18:54:18 Do you have a good link explaining how to write that portion of the recipe? Nov 19 19:14:46 kratsg: here's the section talking about that warning FWIW: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-installed-vs-shipped Nov 19 19:37:38 thanks! Nov 19 19:41:39 when a recipe does something like "inherit core-image" Nov 19 19:41:41 where is core-image? Nov 19 19:43:02 kratsg: since it is used with "inherit", it is a class. You can usually find classes in the toplevel directory of layers. The suffix is .bbclass Nov 19 19:43:28 Oh I see, this makes sense. Nov 19 19:43:51 I'm trying to build crda from meta-openembedded, and it keeps complainin about "No module named _m2crypto" during the build. The crda_3.18.bb file does have a DEPENDS that includes python-m2crypto-native, so I'm not sure what is going on here Nov 19 19:44:19 kratsg: I mean, you can usually find a "class" directory in the toplevel directory of layers. Nov 19 19:44:27 from some googling, it sounds like __m2crypto (2 underscores) is a shared library it builds, but I haven't seen anything about the 1 underscore version Nov 19 19:44:42 kratsg: that particular one is openembedded-core/meta/classes/core-image.bbclass Nov 19 19:45:10 yep, I found it -- thanks. Nov 19 19:45:18 Still trying to get the hang of how it finds everything, but coo. Nov 19 19:45:39 When I write a recipe for an image (that bitbake uses) - do I let bitbake handle dependency resolution? Nov 19 19:45:46 (image features) Nov 19 19:47:08 would that recipe be also where I do something like `PREFERRED_VERSION_ = x.y.z` as well? Nov 19 19:47:14 or does that go in the local.conf file? Nov 19 19:47:38 err* layer.conf Nov 19 19:48:51 You usually specify build (DEPENDS) and runtime dependencies (RDEPENDS). Nov 19 19:49:45 So, I'm creating a new layer that specifies a bunch of recipes - since I'll need to maintain it more often than say the meta-python one. Nov 19 19:50:09 so it's here: https://github.com/kratsg/meta-l1calo Nov 19 19:50:24 In particular, I have recipes-core/python/python-twisted_15.4.0.bb Nov 19 19:50:50 nominally, I would need to make sure the image in recipes-core/images/zynq-base.bb enforces that we want 15.4.0? Nov 19 19:51:14 Where to put PREFERRED_VERSION_ depends on the recipe, I'd say. For BSP-related recipes, I think the best place is the machine configuration file. Some core recipes may have their versions specified in distro configuration files. Other specific uses can go to regular recipes and/or include files. Nov 19 19:52:13 local.conf is not a good place for such configurations, IMO. I don't tend to keep local.conf under version control. But maybe that's just my workflow. Nov 19 19:53:03 I'm not really creating a BSP. Nov 19 19:53:24 meta-xilinx is a BSP-specific recipe, so I need to have a recipe that basically defines the specific image features Nov 19 19:53:40 and one of the features is python-twisted, 13.2.0 is in meta-python, but i should ensure, in zynq-base.bb, that i have 15.4.0 Nov 19 19:54:17 if that makes sense. Nov 19 19:59:14 It makes sense. The confusing bit is that you are talking about "image features" which has a special meaning: http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-features-image I suppose that's not what you are talking about. Nov 19 19:59:40 on my m2crypto issue: it looks like _m2crypto.py should be a swig generated python file, but it isn't being installed Nov 19 20:00:13 kratsg: If I understand correctly, you just want to add a package at a particular version to your image, right? Nov 19 20:00:27 right, but it won't be just one python package Nov 19 20:00:46 I'll be adding a few specific python packages (xmltodict, construct, twisted) with specific minimal versions Nov 19 20:03:10 and now after a cleanall and retry, it is there >.> Nov 19 20:16:38 mario-goulart: https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/images/zynq-base.bb Nov 19 20:16:50 this is an example of a recipe -- the IMAGE_FEATURES is there. Nov 19 20:18:27 So while I don't need it hardware specific, it seems like people add a PREFERRED_VERSION into their local.conf file when bitbaking. Maybe that should be enough and hope it picks up the later version. Nov 19 20:18:43 I'm still trying to get it to produce a uramdisk image so I don't need to do it. Nov 19 20:42:28 awkward, "python-modules" is not a valid image feature. Nov 19 20:42:46 kratsg: those don't look like valid IMAGE_FEATURES. Nov 19 20:43:29 You probably want something like CORE_IMAGE_EXTRA_INSTALL Nov 19 20:44:03 http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-features-image lists the valid image features. Nov 19 20:44:22 mario-goulart: Those were valid. I used it before. Nov 19 20:47:09 kratsg: unless you have taken steps to define python-modules as a feature, it never has been Nov 19 20:47:37 kratsg: it's the name of a package, so you'd add it to IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL to add it to the image Nov 19 20:48:11 bluelightning: where is the package? I can't find it. Nov 19 20:48:31 it's produced by the main python recipe Nov 19 20:48:43 bitbake doesn't list it, but it's in some other recipes, so I'm not sure how I don't have it. Nov 19 20:49:27 packages (i.e. what you install into an image) and recipes aren't mapped 1-1... most recipes produce more than one package Nov 19 20:49:49 how are you determining you don't have it? Nov 19 20:50:00 bitbake complains. Nov 19 20:50:07 complains when you add it where? Nov 19 20:50:12 so it must be some weird misconfiguration of the layer I'm making. Nov 19 20:50:32 I added it to https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/images/zynq-base.bb Nov 19 20:50:54 that's because you added it to IMAGE_FEATURES, as I said it's not an image feature Nov 19 20:51:05 add it to IMAGE_INSTALL instead Nov 19 20:51:30 (none of the other things you are adding are features either, they're all packages) Nov 19 20:52:05 how does a recipe produce more than one package? Nov 19 20:52:46 kratsg: during do_package, the set of files installed during do_install are almost always split into multiple packages Nov 19 20:53:51 in the simplest case, the files for the recipe (e.g. libraries, executables) go into the main package (named the same as the recipe); docs go into the *-doc package, debug symbols go into the *-dbg package, headers and other development files go into the *-dev package, etc. Nov 19 20:54:27 so if I have something like recipes-core/package.bb Nov 19 20:54:40 then I need recipes-core/package/ as well as recipes-core/package-docs/ and so on? Nov 19 20:54:43 a recipe can add or change the packages it produces by adjusting the PACKAGES and FILES variables (which control which packages are generated and which files go into each package, respectively) Nov 19 20:55:42 kratsg: no - you're conflating packages and recipes... there's only one recipe required, PACKAGES set within it (or the default value) specifies which packages it generates Nov 19 20:56:06 so everything the recipe produces goes into whatever package it makes? Nov 19 20:57:00 whatever packages yes Nov 19 20:57:20 (or it should, otherwise you'll get the "installed-vs-shipped" warning we talked about earlier) Nov 19 20:57:33 so i'm looking at python-twisted Nov 19 20:57:38 I had to remove `lore` completely. Nov 19 20:57:45 Why is it making like 18 different packages? Nov 19 20:57:52 shouldn't it all go under a `twisted` folder? Nov 19 20:58:13 inside of python2.7/site-packages? Nov 19 20:58:41 (also not sure what RDEPENDS is doing here) Nov 19 20:59:58 kratsg: it's been split that way so you have some control over what pieces you install into your image Nov 19 21:00:11 kratsg: in the embedded context usually you want to tune what goes into your image to save space Nov 19 21:00:34 so.. how does one tune that? Nov 19 21:00:51 what is a person actually doing to get, twisted-core and nothing else? Nov 19 21:00:57 (python-twisted seems to get everything) Nov 19 21:01:00 simply by only adding the packages you want to IMAGE_INSTALL Nov 19 21:01:18 so it's called python-twisted-core instead of python-twisted if they just want core? Nov 19 21:01:39 I see, well, i have to completely change this twisted though, since 15.4.0 got rid of like 90% of the files that were in 13.2.0 Nov 19 21:01:42 right, the RDEPENDS_${PN} line in there specifies that the main package (${PN} which will translate to python-twisted) depends on all of the listed packages, so it will pull all of those in Nov 19 21:02:04 I see. Nov 19 21:02:38 assuming you'll be sending this as an update it would be nice to preserve some flexibility about which components to install if it's practical to do so Nov 19 21:02:54 I'll try. but i have to remove portions. Nov 19 21:03:01 fair enough Nov 19 21:03:01 since they don't exist anymore. Nov 19 21:03:15 Do you have to do this manually for any python package you want? Nov 19 21:04:11 the package splitting ? Nov 19 21:04:34 well, defining all the files and so on. Nov 19 21:04:45 i'm not entirely sure if twisted can be split like this anymore though. Nov 19 21:05:14 it depends whether it's practical and really necessary... if you look at some other python recipes you'll see they don't bother doing this kind of thing Nov 19 21:05:18 (I used it in 13.X and now 15.4 and it's entirely different) Nov 19 21:05:24 (interface-wise) Nov 19 21:06:26 oh, wait, so that means if twisted depends on zope.interface (which it does), I need to write a bb recipe for installing that as well? Nov 19 21:07:54 assuming one doesn't exist already Nov 19 21:08:08 oh, hrmm. Nov 19 21:08:16 http://layers.openembedded.org/layerindex/branch/master/recipes/ is the place to find that out Nov 19 21:09:02 I just noticed... this recipe uses ${libdir}/${PYTHON_DIR}/site-packages everywhere, but there is a variable PYTHON_SITEPACKAGES_DIR you can use to save typing all of that Nov 19 21:09:05 oh that's cool that python-construct exists.. actually. Nov 19 21:09:20 so Nov 19 21:09:27 i need to make sure all dependencies are resolved? Nov 19 21:09:53 if I have package A->B->C Nov 19 21:10:10 I have to make sure A (depending on B) and B (depending on C) and C -- have all their dependencies resolved. Nov 19 21:10:15 yes Nov 19 21:10:38 I see, ok. I guess I ahve a bit of work to do, but that's fine. Nov 19 21:10:42 note that sometimes recipes (such as python-construct) are in layers that aren't the most convenient place for re-use Nov 19 21:11:30 what does that mean specifically? Nov 19 21:11:36 if you're using 2.0 / master, I'd suggest using "devtool add" (or "recipetool create") to create new python recipes, it will figure out a lot of the dependencies for you and take out a lot of the drudgery of writing the recipe Nov 19 21:11:55 Oh, that would be nice. Nov 19 21:12:02 I have an overall python package that I'm writing Nov 19 21:12:12 https://pypi.python.org/pypi/ironman Nov 19 21:12:26 kratsg: well, python-construct seems to be in meta-netmodule-extras; that appears to be a layer someone has thrown together for their own purposes rather than one that is meant to be generally used by others Nov 19 21:12:28 so my focus is revolving around making sure that works (and this depends on twisted, construct, xmltodict, etc) Nov 19 21:12:56 ah ok, cool Nov 19 21:13:02 I don't intend for my python-ironman recipe to be general use, so I'm ok with building my own little metalayer that encapsulates whatever I can't normally grab. Nov 19 21:13:07 might be a candidate to add to meta-python? Nov 19 21:13:34 moto-timo: indeed Nov 19 21:13:43 which, construct? Nov 19 21:13:45 yes Nov 19 21:13:49 that would be great. Nov 19 21:13:52 Super useful package. Nov 19 21:14:05 I'll look into it, unless you beat me to it Nov 19 21:15:01 I noticed people suggest something like a .bbappend Nov 19 21:15:08 when you're making changes to an existing recipe Nov 19 21:15:14 this isn't true when you need an entirely new version, right? Nov 19 21:18:46 ok, everything looks good. i'll see about getting devtool add working Nov 19 21:18:59 kratsg: right... bbappends are generally where you want to customise the recipe in a way that is specific to your usage (as opposed to being something that would be generally usefull to others and ought to be upstreamed) Nov 19 21:20:01 you can use bbappends for doing any modifications though, upstreamable or otherwise - but updating to a newer version is often a bit awkward within a bbappend Nov 19 21:20:21 ok, so i was able to actually just update twisted, preliminarily. Nov 19 21:20:22 to 15.4.0 Nov 19 21:20:29 (a bunch of files it tries to copy don't exist, but ok) Nov 19 21:20:38 and then `pip install ironman` on the board seems to get everything working normally! Nov 19 21:20:49 so I've got a '/var/log' symlink in my filesystem/sysroot. oe-pkgdata-util claims that no package produces the path /var/log. How can I figure out what is going on here? Nov 19 21:21:59 ah, looks like links created by fs-perms.txt don't show up as owned by any package, and I hadn't placed my override of fs-perms.txt early enough in the BBLAYERS list. Nov 19 21:24:27 bluelightning: how do you use devtool add? Nov 19 21:24:28 latest python-construct on pypi is 2.5.2 vs. 2.5.1 in meta-netmodule-extras Nov 19 21:25:01 I'll give the maintainer of that layer a heads up and get it into meta-python Nov 19 21:25:39 also, where do I find the python-modules package? it seems like a virtual package, no actual recipe exists for it? Nov 19 21:26:01 kratsg: as I mentioned earlier, python-modules is produced by the main python recipe Nov 19 21:27:04 the main python recipe? is that in openembedded-core? Nov 19 21:27:19 see line 159 in http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python_2.7.9.bb Nov 19 21:27:36 kratsg: yes, what moto-timo said ^ Nov 19 21:27:48 kratsg: basically devtool add name-of-recipe sourcepath (where name-of-recipe is just the name portion e.g. python-modulename, and sourcepath is a local path) - you can also add -f http://some/url/to/file to fetch a remote source tarball or git repo and unpack it to the specified location Nov 19 21:29:34 meh, the actual python-modules is defined in python-2.7-manifest.inc Nov 19 21:29:43 yeah, i was going to ask Nov 19 21:29:48 see line 284 in http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python-2.7-manifest.inc Nov 19 21:29:54 it looks like `python-modules` depends on `python-misc` in the first file Nov 19 21:30:10 ahhh, so there it is. huh. Nov 19 21:30:40 bluelightning: let me try the devtool right now Nov 19 21:30:45 using a pypi tarball for ironman. Nov 19 21:31:06 that manifest is generated by a script: http://git.openembedded.org/openembedded-core/tree/scripts/contrib/python/generate-manifest-2.7.py Nov 19 21:32:07 oh wow. Nov 19 21:32:11 that seems really convoluted. Nov 19 21:32:19 necessary evil Nov 19 21:32:26 it's a pain to maintain otherwise Nov 19 21:32:38 Ok, so the devtool add command needs a git commit? Nov 19 21:33:25 oh, i guess `--no-git` Nov 19 21:34:48 ok, do most people do recipes-*/python/python-package_version.bb ? Nov 19 21:35:03 instead of recipes-*/python/python-package/python-package_version.bb ? Nov 19 21:35:34 that's a personal preference... when we set-up meta-python JaMa preferred a flatter structure Nov 19 21:35:49 i think i prefer a flatter structure. Nov 19 21:36:32 I mostly agree... Nov 19 21:36:33 lol Nov 19 21:36:42 so i ran the devtool add. Nov 19 21:36:52 I noticed a `PACKAGECONFIG[testing] = ",,,python-pytest"` Nov 19 21:37:02 not entirely sure what that does. Nov 19 21:37:27 it also doesn't seem to need to do any FILES or PACKAGES. Nov 19 21:38:08 but I imagine I need to do that, so I'll have to set that up manually. Nov 19 21:38:23 it's a semi-smart skeleton Nov 19 21:38:34 so there will often be manual tweaks Nov 19 21:38:48 I see. Nov 19 21:39:01 I definitely need to get twisted updated to remove the extra stuff that's not needed. Nov 19 21:39:33 https://github.com/netmodule/meta-netmodule-extras/blob/master/recipes-devtools/python/python-construct_2.5.1.bb Nov 19 21:39:41 looks like i'll be making something similar to python-construct :) Nov 19 21:39:51 as for ptest.. see e.g. https://wiki.yoctoproject.org/wiki/Ptest Nov 19 21:40:11 ahh, yeah, so I won't need pytest. Nov 19 21:40:17 The testing can be done with travis CI. Nov 19 21:40:30 also: http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#testing-packages-with-ptest Nov 19 21:40:32 it just needs to run on the board, so the test directory can be omitted hopefully. Nov 19 21:40:40 depends on whether you want to run tests on your target Nov 19 21:41:07 for QA purposes, it's best to have the ptest included Nov 19 21:41:13 but we don't require it Nov 19 21:41:53 the more packages you maintain, the happier you will be that you have ptest Nov 19 21:41:54 lol Nov 19 21:42:21 but ptest has to have access to the target? Nov 19 21:42:38 I have to take the generated image and do more with it that bitbake can't do easily before I can get it on the target. Nov 19 21:42:46 when you build an image with ptest, it installs on the target Nov 19 21:42:59 What would be the fastest way to clean up kernel-module-* ? I am htting one of these after changing the assigned kernel 4.3.0-rc3 does not match kernel-abiversion (4.2.6) Nov 19 21:44:23 What would be the fastest way to clean up kernel-module-* ? I am htting one of these after changing the assigned kernel 4.3.0-rc3 does not match kernel-abiversion (4.2.6)/bu11 Nov 19 21:44:28 kratsg: like an emmc flasher or what? Nov 19 21:44:29 sorry :/ Nov 19 21:44:58 well, I have to put it through mkimage first Nov 19 21:45:13 and then walk over and boot from SDCard. Nov 19 21:46:16 (also python-core versus python-lang? I think python-core is the more reasonable dependency) Nov 19 21:46:49 you might want to look into 'wic' which helps with creating flash images, etc. Nov 19 21:47:13 I'd start with python-core, yes Nov 19 21:47:29 So I have to pass it through mkimage first. Nov 19 21:47:44 mkimage -A arm -T ramdisk -C gzip -d inputFile.cpio.gz uramdisk.image.gz Nov 19 21:48:00 presumably, this would be part of a local.conf setting for a post execute Nov 19 21:48:05 but that does require u-boot-tools on the computer Nov 19 21:48:23 http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#creating-partitioned-images Nov 19 21:50:02 moto-timo: I don't get it? Nov 19 21:50:17 see, that's not the only thing I have to do though. Nov 19 21:50:33 since I need to take the kernel image and pass it through xilinx's SDK to produce a special boot.bin Nov 19 21:50:41 just a suggestion, YMMV Nov 19 21:50:50 ah Nov 19 21:50:59 It's not the easiest procedure. Nov 19 21:51:11 Once I have the uramdisk image, I still need to recompile and generate some stuff based on it. Nov 19 21:52:17 so right now, i'm focusing on a nice workflow that is sensible, and then will try and clean things up later. Nov 19 21:52:36 yes Nov 19 21:52:53 so the automated testing is a nice feature, but i at least have that done with travis + landscape + coverage, so things are ok. Nov 19 21:53:38 depends on your QA requirements, ultimately :) Nov 19 21:54:10 but certainly you sound like you have some reason to be confident :) Nov 19 21:54:46 https://github.com/kratsg/ironman#ironman Nov 19 21:54:56 i like to think all my automation here is covering whatever I add in the meantime Nov 19 21:56:47 Ok, i think I have most everyhing settled for right now, thanks. Nov 19 21:56:50 The last question is with layers. Nov 19 21:57:08 When someone sets up a poky, and then sources oe -- do you just instruct them on adding all the necessary layers they need? Nov 19 21:57:49 EG: I'm making a layer: `meta-l1calo` which depends on `meta-python` and `meta-oe`. I can just tell them to get `meta-l1calo` and bitbake will let them know how to get the other layers it depends on? Nov 19 22:01:21 Toaster can take care of that if meta-l1calo appears in the layer index (you should submit it when it's usable by others) Nov 19 22:01:57 also that's the idea behind bitbake-layers layerindex-add although that has some minor usability issues that need working out Nov 19 22:03:53 huh. layerindex-add? Nov 19 22:04:11 bitbake-layers layerindex-add --help Nov 19 22:04:26 er Nov 19 22:04:27 sorry Nov 19 22:04:30 layerindex-fetch Nov 19 22:04:50 oh, that's very cool Nov 19 22:04:55 basically like pip for layers. Nov 19 22:05:04 pretty much yeah Nov 19 22:05:12 so much better than 5 years ago :) Nov 19 22:05:14 but it has to be from that centralized index? Nov 19 22:05:22 i'm surprised you can't pass in a custom layer location Nov 19 22:05:30 since my layer depends only on layers that exist in the index. Nov 19 22:05:39 if you want the dependency resolution yes Nov 19 22:06:02 i feel like I don't want to pollute the layer index with my layer... Nov 19 22:06:33 for now, I'll just develop with this layer Nov 19 22:06:42 and any of the python packages I build, I can patch request to meta-python. Nov 19 22:06:44 the layer index is open to anyone who wants to share their layer, FWIW, but it's entirely optional Nov 19 22:06:48 right, makes sense Nov 19 22:07:10 alright, thanks. I've got more packages to write apparently. Nov 19 22:07:15 it's possible we could add something to handle the situation you describe i.e. resolve dependencies for a local layer, but the code for that hasn't been written Nov 19 22:07:23 right. Nov 19 22:07:28 I looked at the python-construct bb file Nov 19 22:07:32 it doesn't do anything with FILES Nov 19 22:07:34 should it? Nov 19 22:08:02 if the defaults work (as they should for the simple cases, most of the time) then there's no need to set FILES or PACKAGES Nov 19 22:15:55 ok, looking at dependency resolution Nov 19 22:16:10 it looks like construct doesn't need all the packages it lists, just python-six [and maybe python-core] Nov 19 22:18:22 for right now this is what I got: https://github.com/kratsg/meta-l1calo/tree/master/recipes-core/python Nov 19 22:19:23 setup.py only lists six, it's possible other deps are hidden and show up when you run it Nov 19 22:20:35 I used `pip show <>` to resolve dependencies. Nov 19 22:23:51 python-core is needed for binascii Nov 19 22:24:02 so that looks like that's it Nov 19 22:24:03 :) Nov 19 22:27:56 Hrmm, why is my LICENSE file missing? Nov 19 22:29:14 (pypi seems to not include it) Nov 19 22:32:57 welp, duh, fixed it Nov 19 22:34:43 So I'm currently building the kernel with dtb and a ubifs rootfs image. What's the easiest way to either add the kernel and dtb to /boot of the rootfs ubifs image or create a new ubifs image containing the kernel and dtb? Nov 19 22:35:15 Should I do that from a bitbake recipe or an external script? Nov 19 22:38:52 thanks for all the help. gonna keep working on this! Nov 19 22:47:17 Hey, I just did the entire chain moto-timo Nov 19 22:47:26 looks like I'm running into a "no module named cgi" error with twisted. Nov 19 22:54:14 kratsg: I think that's one of the standard modules Nov 19 22:54:30 does `python-core` not include it? Nov 19 22:54:34 I think `python-lang` is needed then. Nov 19 22:54:57 I think it's in python-netserver Nov 19 22:56:01 python-netserver? Nov 19 22:56:16 yes, it's a package produced by the standard python recipe Nov 19 22:56:27 this sort of thing is what devtool add / recipetool create should figure out for you Nov 19 22:57:25 hello i am having a dependency issue that maybe someone can help me with. i made a recipe to build exiv2 and expose to pkg-config via the pkg-config class. i have another recipe which wants to include some of the hpp's from the first recipe when building Nov 19 22:57:50 devtool add doesn't figure that out for twisted. Nov 19 22:57:53 i thought DEPENDS="recipe1" would expose hpp's in recipe1 to recipe2 Nov 19 22:58:15 kratsg: hmm, that's interesting... should probably look into that Nov 19 22:58:30 but it can't seem to find them (however pkg-config from recipe2 can see the a pc made be recipe1) Nov 19 22:58:52 bluelightning: how do I easily find those "dynamic" packages? Nov 19 22:59:06 if i'm exploring the space, it's not easy to look in every file to find something Nov 19 22:59:21 i *don't* see the hpp's in /tmp/sysroots/.... Nov 19 22:59:28 and i think i am supposed to? Nov 19 22:59:35 since i added that dependency Nov 19 23:00:21 peacetoall: in that case they may not be being installed into the correct location Nov 19 23:01:18 kratsg: oe-pkgdata-util can be used if the recipe has been built Nov 19 23:01:28 kratsg: e.g. oe-pkgdata-util find-path */cgi.py Nov 19 23:02:01 oh, that's actually convenient. Nov 19 23:02:17 bluelightning: i don't have any install_append now, only FILES_${PN}. so it sounds like i should write an install append and install them to ${D}/${libdir}? Nov 19 23:02:19 kratsg: also oe-pkgdata-util list-pkgs -p python Nov 19 23:02:21 but that's assuming one had built python-netserver itself? Nov 19 23:02:33 peacetoall: that might be what's needed yes Nov 19 23:02:46 kratsg: assuming you had built python, yes Nov 19 23:04:07 lemme try the devtool add again Nov 19 23:06:20 oh wow Nov 19 23:06:24 it works much better on 15.4.0 Nov 19 23:06:26 then it did on 13.2.0 Nov 19 23:08:39 one thing to note is that how good devtool add / recipetool create are at figuring out the depencies will depend on what's been built beforehand Nov 19 23:08:58 if it's not yet built then it may not be able to see it Nov 19 23:09:27 i see. Nov 19 23:09:34 lemme gist one of the standard outputs Nov 19 23:10:05 https://gist.github.com/c17b9e429545a6f47ed7 Nov 19 23:10:09 here's what devtool add generated Nov 19 23:10:51 that list looks a lot better imo Nov 19 23:10:58 but there's a section of comments Nov 19 23:11:02 and im not sure if I need to handle that. Nov 19 23:14:57 many of those packages in the comments probably haven't been built yet Nov 19 23:15:22 and some are not going to be neededd Nov 19 23:16:44 so how would I know what's needed or not? when I develop the 15.4.0 recipe for twisted, it should be good enough to submit a patch to meta-python Nov 19 23:16:49 so clearly, i don't want to half-ass it. Nov 19 23:17:25 there is a reason the 13.2.0 recipe is so long and complicated Nov 19 23:17:54 so you need to compare the autogenerated 15.4.0 recipe to the 13.2.0 recipe and manually merge Nov 19 23:18:07 that's probably what I'll do Nov 19 23:18:16 unfortunately, the entire interface changed, so Nov 19 23:18:26 i'll do my best to maintain the... separation of pieces Nov 19 23:19:59 also, notice how the 13.2.0 recipe breaks it up into a bunch of sub-packages Nov 19 23:20:35 that helps keep your final images smaller, since you might not need the entire beast Nov 19 23:21:30 twisted isn't that big anymore! Nov 19 23:21:34 but i'll keep that in mind Nov 19 23:21:46 I'll split it up by top-level folder under `twisted` Nov 19 23:21:51 and try to figure out the dependencies somehow Nov 19 23:24:07 how do know where i *should* install header files? ${D}/usr/lib/SOMENAME/ ? Nov 19 23:34:37 ${D}${includedir}/SOMENAME Nov 20 02:24:15 hey I’m having a hard time translating/creating a recipe for a (potentially hacked, specialized) webkitgtk. This is for purposes of providing webkitgtk for another project which has it’s own build of webkitgtk that doesn’t assume Yocto. And that is working up to a point, but then libtool fails with “cannot ind the library `/usr/lib/libgobject-2.0.la” which some cusory ready shows that’s a common problem with autotools based Nov 20 02:24:15 configuration, which should be taken care of automatically by the autotools classes, but is apparenty disabled by defiining a custom do_configure. On the other hand there is a meta-webkit layer that I can simply use, but that’s even more opaque because it a bunch of variables/patches and who knows where all that comes from? Looking for some guidance. The docs (though lenghty) don’t spend much time how to get the most out of configure or Nov 20 02:24:16 to change the behavior form the default. Especially in this case. **** ENDING LOGGING AT Fri Nov 20 02:59:58 2015