**** BEGIN LOGGING AT Mon Oct 12 02:59:59 2015 Oct 12 05:20:22 hello guys Oct 12 07:11:20 good morning Oct 12 07:34:27 register Gridlock_123 Oct 12 08:19:42 any meta-intel maintainer hanging around? I think the common directory should be rename into meta and conf directory moved inside it Oct 12 08:20:22 now the meta-intel layer kind of breaks when you want to override scripts, have to use "common/recipes-..." path instead of just "recipes-" Oct 12 08:38:30 dolphin: meta-intel maintainer hangs on #at91 Oct 12 08:39:03 dolphin: oops, sorry, misunderstood Oct 12 08:39:25 * mckoan hates jet lag Oct 12 08:51:10 clopez: ping Oct 12 09:29:24 I need to support several hardware variations. This would involve a couple of different configuration files in the rootfs and a different device tree. Would that justify a different MACHINE? Seems kind of painful to use for such minor differences (which do need to be kept track of during package upgrades) Oct 12 10:27:34 Hello ! I have a strange error with some python packages, don't know if it is related to the debug-tweaks... I get : Oct 12 10:27:40 ERROR: Function failed: write_specfile Oct 12 10:27:59 http://hastebin.com/ebocoqenel.pas Oct 12 10:29:10 I doubt it's related to debug-tweaks Oct 12 10:29:25 odd that there's absolutely nothing in the way of error detail Oct 12 10:30:05 bluelightning: cleanall and redoing the bitbake on the package is ok Oct 12 10:30:11 and then another one fails Oct 12 10:46:00 <[Sno]> JaMa: why should udev not be MACHINE_ARCH? Oct 12 10:48:21 stuff should only be machine-arch if absolutely needed, as then everything that depends on it (quite a lot) is also machine-arch Oct 12 10:48:36 because many recipes depend on udev and they would effectively became MACHINE_ARCH as well Oct 12 10:50:21 a neat way of saying "this may be machine arch but honestly it doesn't change any any meaningful way" would be useful, afaik SIGGEN_EXCLUDERECIPES_ABISAFE is too broad a hammer for that? Oct 12 10:51:04 but that's a 2.1 discussion and right now we're trying to get 2.0 out :) Oct 12 11:00:15 yes SIGGEN_EXCLUDERECIPES_ABISAFE is all or nothing, when set depending recipes won't rebuild even when udev intentionally changes API & ABI Oct 12 11:01:24 <[Sno]> JaMa: understood - and agreed, I rework the udev patch than Oct 12 11:01:28 as discussed in https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 we need something to remove just some variables from sstate signature of dependent recipes Oct 12 11:01:30 Bug 5970: enhancement, Medium, 1.9, richard.purdie, VERIFIED FIXED, sstate signature generator issues Oct 12 11:01:45 JaMa: remove package_arch? Oct 12 11:03:05 rburton: in this case? to remove MACHINE_FEATURES, lsusb, pciutils and usbutils Oct 12 11:03:21 when looking at udev signature e.g. when buildng xserver-xorg recipe Oct 12 11:03:44 in other words to be able to say, that the udev ABI is the same when it was built with or without usb and pci support Oct 12 11:28:10 <[Sno]> is there a sane way to have different DISTRO_FEATURES for different machines? or isn't that recognized? Oct 12 11:29:16 [Sno]: I think you'll want to have MACHINE_FEATURES and DISTRO_FEATURES, then look at the COMBINED_FEATURES code Oct 12 11:29:16 distro and machine are meant to be orthogonal, so the system isn't really meant to work in that way Oct 12 11:30:01 at oe-core/meta/conf/bitbake.conf Oct 12 11:30:13 <[Sno]> JaMa: in that case there should be a better solution for udev than moving the responsibility to DISTRO_FEATURES when it's not sane Oct 12 11:31:01 <[Sno]> I understand the price is high - but wrong and quick solutions aren't the answer to avoid high costs, are they? Oct 12 11:32:05 changing udev to be machine arch is also wrong and quick ;) Oct 12 11:32:28 <[Sno]> rburton: I understand that - and searching for a better way Oct 12 11:33:57 <[Sno]> stupid [Sno] - JaMa suggested PACKAGECONFIG and not DISTRO_FEATURES - this can be handled in local.conf or own distro/my.conf Oct 12 11:38:33 default PACKAGECONFIG value can be set based on DISTRO_FEATURES Oct 12 11:39:02 but that leaves you option to easily change it if it doesn't match with expectations Oct 12 11:54:55 hello guys Oct 12 11:55:13 is there a way to set PATH variable without user's login? Oct 12 12:13:07 0x4 /etc/rc.local Oct 12 12:17:32 mckoan: I don't see such file there Oct 12 13:04:45 Ox4: you have to create it, try google-ing Oct 12 13:05:32 mckoan: yes, I googled it already, but it is for tiny system, no? Oct 12 13:06:55 mckoan: and I don't see it in the mega manual Oct 12 13:14:30 also how can I modify rcS script in the etc/init.d directory to build an image? Oct 12 13:37:46 I think it will be better to patch rcS in sysvinit package Oct 12 15:20:12 oh yocto gods, any tips for how to debug when a task doesn't work when launching bitbake but works when inside the devshell? Oct 12 15:20:28 I am starting to despair Oct 12 15:21:29 more context would be useful Oct 12 15:21:42 rburton: doesn't right-clicking help? Oct 12 15:21:45 reading the run.[task] in the work directory might be useful Oct 12 15:23:30 it's a vendor kernel (the story starts promising) Oct 12 15:24:23 if I do `bitbake vendorkernel` it fails at do_configure, saying "no such target 'oldconfig'" Oct 12 15:24:41 if I go into the devshell and call the run.do_configure, everything goes well Oct 12 15:25:18 rburton: thanks, I tried that. It looks good to me and gives good results when I run it Oct 12 15:26:10 fredcadete: sounds like the directory its running in is wrong Oct 12 15:26:27 rburton: It's a possibility Oct 12 15:26:33 throw a echo `pwd` at the beginning and see Oct 12 15:26:59 adding that echo with a do_configure_prepend? I'll try that Oct 12 15:27:19 that will work Oct 12 15:30:16 rburton: indeed. it's running in an empty directory. I think it can be related to work-shared Oct 12 15:30:21 I have a direction, thanks A LOT Oct 12 15:30:56 that's five minutes of consultancy time, rounded up to 30 minutes, at my standard rate of £100/hour. I'll send the invoice this evening Oct 12 15:30:57 :) Oct 12 15:32:04 Hm is there a good method for tracking one set of branches in one image, and another set in another image? Including stuff in the BSP layer? I guess I could create multiple configs but that seems a bit extreme for what I'm trying to do. Oct 12 15:32:24 rburton: sure, I'll send it to my HR department and let them sort it out Oct 12 15:33:43 fredcadete: if you're running oe-core master there were some changes to what directory it builds in, so if the bsp hasn't been tested i'm not surprised it failed. Oct 12 15:34:43 Basically trying to come up with one full image that follows our current release, and another 'dev' image that follows our various bleeding edge branches. Oct 12 15:49:57 rburton, the record: Got it. The vendor kernel's recipe was overriding do_configure and calling `oe_runmake`. But with a poky upgrade, it now has to call `oe_runmake_call -C ${S} O=${B} Oct 12 15:50:00 jbrianceau: pong ? Oct 12 15:52:41 clopez: hi, your name showed up in the meta-browser git history Oct 12 15:53:03 clopez: about the chromium recipe, I'm wondering if the license is correct Oct 12 15:53:38 clopez: it's declared as BSD, which is fine for chromium-src code, however there are also many 3rd party libs in the google archives, that are not BSD Oct 12 15:56:26 clopez: for instance ffmpeg in src/third_party/ffmpeg is LGPL-2.1 and is used by chromium Oct 12 15:57:55 jbrianceau: yes, also the render engine (blink now, webkit before) is bsd/lgplv2 mixed Oct 12 16:00:02 clopez: correct. Is there a way to declare this in a yocto recipe ? I think I've already seen licenses with logical operators like | & Oct 12 16:00:17 you can check the debian copyright file, they tend to pay more attention to licenses than others Oct 12 16:00:20 http://metadata.ftp-master.debian.org/changelogs//main/c/chromium-browser/chromium-browser_45.0.2454.85-1~deb8u1_copyright Oct 12 16:01:24 clopez: very interesting, thanks for the link Oct 12 16:01:25 jbrianceau, yes .. check the recipe for webkitgtk_2.8.5 on oe-core/poky (master) Oct 12 16:01:42 clopez: will do, thanks a lot for the info Oct 12 16:02:19 you are welcome :) Oct 12 16:12:17 clopez: Do you guys use a custom do_fetch / do_unpack for that? Oct 12 16:12:40 Use a webrtc recipe at work, and it's... an unwieldy nightmare to say the least. Oct 12 16:31:55 if I want to over the default init system ... PREFERRED_PROVIDER_virtual/runtime_init_manager = "sysvinit" Oct 12 16:31:56 ? Oct 12 16:32:28 raykinsella78: https://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#selecting-an-initialization-manager Oct 12 16:42:48 cool and the gang Oct 12 16:45:29 xulfer: i don't think.. we only list the different licenses and hashes on the LIC_FILES_CHKSUM variable Oct 12 16:47:41 clopez: How do you deal with depot_tools checkout then? Oct 12 16:49:09 That's our whole issue right now. Oct 12 16:53:50 xulfer: i don't deal with that... the chromium tarball should already include all third_party deps inside Oct 12 16:53:57 ex: http://gsdview.appspot.com/chromium-browser-official/chromium-40.0.2214.91.tar.xz Oct 12 16:54:38 Oh. Hmm... I might look into that. Because I could just extract webrtc from there. Oct 12 16:57:57 xulfer: why don't you add the webrtc git repository as SRC_URI ? Oct 12 16:58:20 It has a bunch of third party deps, and stuff that only gets pulled down via fetch / gclient Oct 12 16:58:51 I thought about trying to parse the chromium + webrtc DEPS tree to make a version that I could adapt to our webrtc layer Oct 12 16:59:06 but seems like more work than maintaining the monstrosity that is our current recipe Oct 12 16:59:28 I mean it works now, but it overwrites so many hooks in yocto that dependency checking doesn't even work for it Oct 12 17:15:22 signing off Oct 12 17:39:52 bluelightning: hey, are you there by any chance? Oct 12 17:39:56 or anyone :) Oct 12 17:40:20 what is the preferred way of downloading some proprietary software which has to go through the usual username and password authentication? Oct 12 17:40:57 I can sure use wget, too, but then what is the point of mentioning the source, etc... these are the confusions that I have got. Oct 12 17:42:26 there is nothing built-in for that that I know of Oct 12 17:46:43 bluelightning: so I just put the nasty wget and decompression stuff into do_install as I understand then? Oct 12 17:56:51 bluelightning: actually, do_fetch instead? Oct 12 17:59:44 can't yoiu just use an http uri in SRC_URI and use a .netrc to supply the authentication? Oct 12 17:59:53 that's what i usually do when i need https rather than ssh for our git repositories Oct 12 18:02:56 lpapp: you could always just append to FETCHCMD_wget Oct 12 18:03:11 I <3 environment-setup.d for the sdk Oct 12 18:03:40 also, if you don't want to put a real private url in the recipe, you can use a fake one coupled with PREMIRRORS Oct 12 18:03:45 * kergoth yawns Oct 12 18:03:49 xulfer: maybe you can pull all the stuff via gclient, create a tarball (without the .git directories to trim the size) and upload it somewhere, then make the recipe pull that tarball Oct 12 18:03:54 kergoth: interesting idea Oct 12 18:04:08 I've done that before :) Oct 12 18:05:03 have also written a custom fetcher supplied by a layer that used an external fetch tool to handle the customer's authentication / access to the files for a case where there was a standalone fetch tool Oct 12 18:05:23 bluelightning: hmm, FETCHCMD_wget expects the parameters that I would pass to wget? Oct 12 18:05:42 lpapp: yes... see the default value in meta/conf/bitbake.conf Oct 12 18:05:45 clopez: Yeah I've been thinking about that as well. Oct 12 18:09:05 bluelightning: ok Oct 12 18:09:14 kergoth: yeah, the recipe will remain private, too Oct 12 18:09:23 ah Oct 12 18:09:36 at the YP Dev Days David Reyna presenting some things on using mirrors for private urls.. Oct 12 18:10:01 heh :) Oct 12 18:10:22 bluelightning: btw, it seems I need to use two wget commands, one for the login to store the cookie and then another for the actual download using the cookie from the previous command, so I assume that for this, I will need my own custom do_fetch? Oct 12 18:10:26 clopez: another option is to run gclient in do_unpack[postfuncs] ... the chromium recipe does something similar for fetching the ozone-wayland layer when its enabled Oct 12 18:10:32 or they can somehow be combined? I am not quite a wget pro user. Oct 12 18:10:53 xulfer, clopez: depending on how in depth you want to get, this could be a candidate for a custom bitbake fetcher. Oct 12 18:10:59 what I exactly mean is: wget --save-cookies cookies.txt --keep-session-cookies --post-data 'username=foo&password=bar' https://foo.com/login Oct 12 18:11:21 wget --load-cookies cookies.txt https://foo.com/binary.tar.xz Oct 12 18:12:08 ahh, right Oct 12 18:12:09 or maybe add an extra step between do_unpack and and do_patch Oct 12 18:12:17 that makes sense, FETCHCMD_wget does indeed sound ideal for that case Oct 12 18:14:29 lpapp: I'm going through open issues in meta-sourcery, do you know if the issues you had with it are still outstanding? Oct 12 18:14:39 I think they are resolved now, thanks. Oct 12 18:14:46 kergoth: I'm interested, but not familiar enough to know if it's worth me working on. Oct 12 18:14:54 * kergoth nods at xulfer Oct 12 18:15:04 In the sense that I'm only allotted so much time by work to work on stuff like that. Oct 12 18:15:05 so I would put the parameters for the first wget run into FETCHCMD_wget and then the second to? Oct 12 18:16:10 I think you'd have a few options: run the --save-cookies before the bitbake, have a separate recipe do it with FETCHCMD_wget saving the cookies into a known path, or do a second wget in the main recipe before do_fetch, e.g. with an additional task Oct 12 18:18:07 ok, I will need to look it up again how to create a custom in-between task. Oct 12 18:24:04 addtask fetch_login before do_fetch; do_fetch_login () {} Oct 12 18:24:05 or so Oct 12 18:24:41 of course, you'll presumably be hardcoding a password in a recipe with that approach, unless you have it pull that from somewhere external Oct 12 18:24:42 * kergoth yawns Oct 12 18:27:51 yes, I will hard-code it for now. Oct 12 18:30:01 It'd be nice for the fetchers to better support supplying authentication, handing it off to the commands they run via whatever mechanism is appropriate, rather than us having to directly feed it into the processes it runs (e.g. running ssh agent, netrc, ..) Oct 12 18:30:14 though that'd have its own downsides, i guess... but today it's a really leaky abstraction :) Oct 12 18:31:38 i often use git over ssh with a forwarded ssh agent to do my builds on a remote VM, but then i detach the session and come back later and my build has failed since detaching and disconnecting means no more access to my forwarded ssh agent :) Oct 12 18:32:01 course, i could use a local key instead, probably should at some point Oct 12 18:32:39 is there a recipe naming convention for nativesdk recipes that only install a script into environment-setup.d? Oct 12 18:32:46 i'm doing nativesdk-env- at the moment Oct 12 18:34:08 meta-sourcery arranges to install one of those now, to avoid having to ship a multilib suffix symlink: https://github.com/MentorEmbedded/meta-sourcery/pull/100/files Oct 12 18:52:22 ERROR: Function failed: Unpack failure for URL:... Oct 12 18:52:32 but actually, my source is not compressed... it is just *.bin. Oct 12 18:52:47 do I need to override do_unpack with empty content in this case? Oct 12 18:53:53 the default do_unpack should just do nothing for a .bin. there's no handling for *.bin in bitbake Oct 12 18:54:08 but you can explicitly set unpack=no as a url parameter as well Oct 12 18:55:55 hmm, in that case, I am not sure why the do_unpack task fails. Oct 12 18:56:53 might be my mistake in the url where I used .../$(PV)/$(PN)-$(PV)... Oct 12 18:57:08 perhasp ${} instead of $() Oct 12 18:57:26 ah, that woudl spawn a bunch of subshells for the first shell it tries to run using that :) Oct 12 18:57:44 so it tries to run a command "PV" in a subshell Oct 12 18:58:38 yeah, thanks Oct 12 18:58:54 not sure what to do with LIC_FILES_CHKSUM in case of propietary binary software. Oct 12 18:59:04 I already have LICENSE = "Proprietary". Oct 12 19:01:22 oh, I have to use CLOSED instead of Proprietary Oct 12 19:01:24 Proprietary will still require license terms, afaik. CLOSED however is a generic closed source all rights reserved type thing, doesn't require a license file Oct 12 19:01:25 yeah Oct 12 19:02:10 thanks Oct 12 19:02:51 wtf, my mac is ignoring a /etc/hosts file entry in favor of something it looked up Oct 12 19:02:57 the dns server does *not* know better than my hosts file Oct 12 19:03:29 then change the order. Hosts first. Oct 12 19:03:40 instead of asking DNS forst. Oct 12 19:04:59 hmm, sh ./mybinary.bin does not seem to work as it cannot find the binary file, even though it is in the ${WORKDIR} Oct 12 19:05:07 perhaps I need to be explicit with that. Oct 12 19:07:35 also, the binary in WORKDIR seems to be 4 KB, so I assume the wget session did not work out as I wished. Oct 12 19:08:56 kergoth: remember anything in /etc is considered legacy on OSX if you've a modern app Oct 12 19:09:30 I assume that I need to enable the task history to see what wget commands are executed, etc? Oct 12 19:09:55 rburton: true Oct 12 19:10:04 can one package in a recipe depend on another package in the same recipe? Oct 12 19:10:12 yes Oct 12 19:10:13 lpapp: rdepend? of course. Oct 12 19:10:18 Snert_: yeah, just need to figure out *how* :) not exactly as trivial as nsswitch.conf on a mac, sadly, and it differs between versions Oct 12 19:10:19 * kergoth rolls eyes Oct 12 19:11:15 rburton: yes, so that package bar requires package foo, but foo and bar packages are built from recipe foobar_0.1.bb Oct 12 19:11:49 sure Oct 12 19:11:58 PN-dev depends on PN Oct 12 19:12:16 so it happens in almost every recipe already Oct 12 19:12:53 :))) Oct 12 19:12:55 cool! Oct 12 19:13:19 so if I say REPDENDS_${PN}-bar = "FILES_${PN}-foo", it ought to work, yeah? Oct 12 19:13:23 no Oct 12 19:13:39 RDEPENDS_${PN}-bar = ${PN}-foo Oct 12 19:13:50 erm, with quotes as appropriate Oct 12 19:13:59 ah, sorry, yes. Oct 12 19:14:02 you are right, thanks. Oct 12 19:41:01 hmm, if I say FILES_${PN}-foo = "....../etc/", then I can say " FILES_${PN}-foo_exclude = "....../etc/exception" ? Oct 12 19:42:37 _remove exists Oct 12 19:42:40 but ewww Oct 12 19:42:46 just fiddle the order of PACKAGES Oct 12 19:42:55 the file matches are applied in order of PACKAGES Oct 12 19:43:19 so -bar can package /etc/exception and then -foo can package /etc/*, assuming -bar is listed before -foo in PACKAGES Oct 12 19:43:48 _remove though only removes from a variable.. since the FILES_pkg is shell globbed.. remove won't do anything -- runs before any such globbing Oct 12 19:44:01 but as rburton says.. the right way is adjust the PACKAGES order Oct 12 19:44:28 erm, yeah, not sure why i wasn't parsing that right in my head! Oct 12 19:44:39 * rburton blames the Rebel Gold he just opened Oct 12 19:48:07 rburton: yeah, this is a new context, so I have one package, but I do not wish to grab everything Oct 12 19:48:27 it would also be cumbersome to match one-by-one, excluding would be ideal. Thank you for _remove. Oct 12 19:49:36 if you only have one package, and have a bunch of files that won't be packaged at all, you'd be better off just rmeoving the files you don't want in packages in do_install, otherwise you'll get installed-but-not-shipped QA failures anyway Oct 12 19:49:51 if you do want them packaged, just in a different package, then rburton's suggestion about PACKAGES order is the best solutjion Oct 12 19:50:15 yeah, it is a quick hack :) Oct 12 19:50:29 I am trying to separate packages in one recipe into two. Oct 12 19:50:58 as was just mentioned, _remove is unlikely to work for you here. lit's used to remove words from a variable. If FILES includes e.g. /etc/ or /etc/*, you can't _remove /etc/foo and expect that to do anything Oct 12 19:51:01 and instead of doing everything in one go, I just copied the original recipe, and I am removing the packages from that recipe that are supposed to be in the other recipe. Oct 12 19:51:04 and vice versa Oct 12 19:51:11 but currently, they both build from the same repository Oct 12 19:51:26 the fastest way to add a new package that grabs something instead of the main apckage is to prepend it to packages, as rburton just said..; Oct 12 19:51:33 much simpler than mangling FILES_${PN} Oct 12 19:51:41 the reason for this move is that we grabbed some upstream proprietary dependency into our software's recipe and they really ought to run for their own versions. Oct 12 19:51:52 and as far as I know, all the packages in a recipe will run under the same version. Oct 12 19:53:06 I am happy to ignore the QA warnings for today. Oct 12 19:53:15 will fine-tune it another day. Oct 12 19:53:31 my boss wants me to get something working ASAP :) Oct 12 19:55:05 PACKAGES =+ "newpackage"; FILES_newpackage = "/etc/foo"; RDEPENDS_${PN} += "newpackage". done. Oct 12 19:55:06 :) Oct 12 19:55:09 * kergoth gets food Oct 12 19:55:12 as the last resort, being explicit about every file might bring me to somewhere. Oct 12 19:55:24 but yes, you are right, I will get the warnings. Oct 12 19:57:52 man, nothing screws up my day like an unexpected rebuild from scratch of every freaking recipe Oct 12 19:58:04 go from a 5 minute build time to a couple hour build time in seconds :( Oct 12 19:58:31 yeah, that can be undesired. Oct 12 19:58:54 I try not to multi-task too much so as to avoid losing track of where i'm at, but that's tough when you're stuck waiting on a bunch of long-ass compiles Oct 12 19:59:02 :| Oct 12 20:23:23 so I have a new package now coming from the new recipe, but I guess there will be problems at the upgrade process... as a package is replaced by another now. Oct 12 20:23:48 what is the best way to solve this? Is there some variable to set in the new recipe for the new package to replace the "old" package from the "old" recipe? Oct 12 20:24:06 so that the upgrade process remains smooth. Oct 12 20:24:09 RREPLACES+RCONFLICTS+RPROVIDES generally Oct 12 20:24:34 https://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-RREPLACES Oct 12 20:25:14 well, rreplaces+rconflicts, rprovides is only needed in certain cases Oct 12 20:25:17 depends Oct 12 20:25:35 yeah, we use CONFLICTS on Archlinux in PKGBUILD iirc, but I might be wrong. Oct 12 20:27:01 cool, so the new package bar will replace foo if I say this in bar's recipe for instance: RREPLACES_${PN} = "foo (>= 1.2)" Oct 12 20:27:56 yeah, but foo will stay installed unless you also add it to RCONFLICTS Oct 12 20:29:00 ah, so the triumvirate is the best to be specified in my case that you mentioned :) Oct 12 20:29:03 thanks again. Oct 12 20:29:46 np Oct 12 20:29:56 iirc the debian policy manual has a section on this too Oct 12 22:41:17 kergoth: Have any docs regarding writing a custom fetcher, or know where I could begin looking? Oct 12 22:42:21 only the bitbake code, really. bitbake/lib/bb/fetch2/*.py Oct 12 23:48:11 what's up with the duplication between OECORE_TARGET_SYSROOT and SDKTARGETSYSROOT? Oct 12 23:49:03 hey all, I have a strange dependency issue: I need to build python-imaging with tk support to run a script we use, the problem is python-imaging uses the python-native executable during its compile step, but if I add tk-native as a DEPENDS to python-native I get a dependency loop Oct 12 23:49:05 http://pastebin.com/5e7Kvm3p Oct 12 23:50:21 I've already put a day into getting tk-native to build correctly (the recipe as is in 1.7.2 is pretty broken)....and the dependency loop looks ugly...not sure if its worth the effort Oct 12 23:51:45 I don't see why you'd need tk-native to be a dep of python-native. just have python-imaging depend on tk-native. Oct 12 23:52:30 python-native detects the presence of tk and builds/deploys a lib called _tkinter if it finds it Oct 12 23:53:39 otherwise you get this: Oct 12 23:53:45 Python build finished, but the necessary bits to build these modules were not found: Oct 12 23:53:45 _bsddb _tkinter bsddb185 Oct 12 23:53:45 dl imageop nis Oct 12 23:54:05 that't from the python-native do_install log Oct 12 23:54:39 I don't see a trivial way to resolve that without splitting the python-native recipe/build into two pieces, unless you can find a way to avoid python-native being pulled in by tk-native Oct 12 23:56:35 I'll spend some time trying to break the dependency tree....thanks kergoth **** ENDING LOGGING AT Tue Oct 13 02:59:59 2015